From xen-devel-bounces@lists.xenproject.org Mon Sep 01 03:22:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 03:22:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104024.1455219 (Exim 4.92) (envelope-from ) id 1usv7I-0002A6-Ch; Mon, 01 Sep 2025 03:22:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104024.1455219; Mon, 01 Sep 2025 03:22: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 1usv7I-00029r-6y; Mon, 01 Sep 2025 03:22:00 +0000 Received: by outflank-mailman (input) for mailman id 1104024; Mon, 01 Sep 2025 03:21: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 1usv7G-00029l-OS for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 03:21:58 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2062b.outbound.protection.outlook.com [2a01:111:f403:200a::62b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cf2b301b-86e2-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 05:21:56 +0200 (CEST) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) 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.9052.16; Mon, 1 Sep 2025 03:21: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%7]) with mapi id 15.20.9052.019; Mon, 1 Sep 2025 03:21:51 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cf2b301b-86e2-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c6rUv7pHIBKTUvgc0cbFlJ1+AYiiRozFYWoF2JoMgQENIUSJk91DCE8kTDyZAOF+FgRear1ZhGZwmEa3MqgG9kAjWDw9IRcqKAs0lPEefCXotRkubwhjywy3FVn+T2jTOxQTHzIV44trOCpFlaENoQeti7QArHAr4zwlmIEC6jY4bB0AKV1x0Ya8N4jYuywNk3xsPE3WSVH0OJwjuHt4RKvR/7THp4R+sZC7ldJVmTKZkD39SZjtofRS1C9pEm7Ck/abw6LBfEo78Xt4+QdQZpnestlmI9oSODAtPY6lGVHjfk4v1Izo0ZMJUgnFiDtbJNyOp+lhBYQOckYqxutRuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MswoHzAN+UDOiDVkyv5bZcvgdrW3uhYxVgTIWlU2M1k=; b=A5fsQkviacVHJumLrJDNGNeIo0xEBPZcPd8WN71nIpp4KB2eqCPIsJ85LiiCOyZfvxFYd8jxiD25YIjOlUe1DJH+wyaWNh2oUW+c69cCQzp4o9TvmBZFhELH6mCCs+IrzSz9GpamR/BjNQyLBxQYdOwayShAoS3iCFtvuf/f1A6QgnroU/IlSWwfHM56KlRVosxOGm7B0frwqgCmMS5s5U++P5H+7tIlK0MvrPoVCbZi0DlCmJwjJORk2egKnOgrGJDaTjGggF35oyL7mfZF+b3Kh0P7WDfHY69Jk4COZ1tMe6D8JSuXLCFZ+viD0IFUCYliJ8gODol/w3vvtI/oNA== 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=MswoHzAN+UDOiDVkyv5bZcvgdrW3uhYxVgTIWlU2M1k=; b=UEgbWo1zv9+4FJrbWxDuWQC7u8VISqK74Ym4xIE97DVsTnSzHCedQ/aj473o1kGjNiA2hfMWByVRlArqSucxrAAWJqNYW1y1SfjNgu5aoSy6j13HOBbn5aiLYdxndIc41XQJpr6gY1d04pXhvBm0hWOlm/z4mV9fCaaoABGSs6w= 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" , "Andryuk, Jason" Subject: RE: [PATCH v8 3/8] xen/cpufreq: implement amd-cppc driver for CPPC in passive mode Thread-Topic: [PATCH v8 3/8] xen/cpufreq: implement amd-cppc driver for CPPC in passive mode Thread-Index: AQHcGAMPJXzUCwqDQEuHduiQbQ8QbbR37ByAgAEJOqCAADI8AIAEhAsQ Date: Mon, 1 Sep 2025 03:21:51 +0000 Message-ID: References: <20250828100306.1776031-1-Penny.Zheng@amd.com> <20250828100306.1776031-4-Penny.Zheng@amd.com> <1ad85430-2aa7-4834-be56-67515ca51310@suse.com> In-Reply-To: <1ad85430-2aa7-4834-be56-67515ca51310@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-09-01T03:21:42.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_|BN7PPF28614436A:EE_ x-ms-office365-filtering-correlation-id: 6cc82468-9bb5-42e4-ea7c-08dde906b180 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?aCtNVGhzUFBKaUcxT25KRjhISktibm84MnJtRnR4ZnhHanBScUJkRXpVNWdp?= =?utf-8?B?eXJiV1JJQjU3RG5SNFJBVENXUUhXbG5wRjRUQVlucEF6MVFmOUZKYldSV0dx?= =?utf-8?B?V0JISUFxZkMvbXRBd2F3UUwwMUszSkR2NFZrenI2L09SNWxRSUFFalArOGpT?= =?utf-8?B?UU1XbjlQNDJBcEtaNDdGYWE3enpHVmc2R1loMDNUNEVvSExNVlBzbUh3NWhE?= =?utf-8?B?MkhoelRWL1c5VGZqdWVRSWJkRFcwTDN1cTJrckpiYjV2bXl6TUhyQXlSZmdj?= =?utf-8?B?emRBUk1OUXZOak03N3d6aU9mU3dSRElvZWFJeThNdnZzVGVDZm5PcStIb3Rz?= =?utf-8?B?TlBDTHNEdVhQOFlNMUlxQWY3cVpxQlVHdjVYcE1UUGM5aXBOUzJqeGdKQUNt?= =?utf-8?B?KzcyNFZJK1MxdDBqQ05EUDNMaE1kVnRmeUY0L2YyR09SaFNaRDh6M3ZtQUpW?= =?utf-8?B?bUpBSjZOdUVJZWVnellyOCtEWjVyUkFFMUZGbURGcWRHSWMyY1NKRm5tcW00?= =?utf-8?B?OHMvcGFCR0pkaTAya2J3UVdudHVHclBpZ0NheXVNdW1FY2dLREwyWEVBeFk2?= =?utf-8?B?NUI0WjFucjZYZEMwVG8yRG5IV1ZOdzZ6RlkyeDV1ajI3cGEyMksxZGM4K1A0?= =?utf-8?B?UThQRDgwVktNdE5vY1Fsd25oMG5mYlFuaGM4VENkcDZuYXZIelpPVTQ2NU9X?= =?utf-8?B?ZENxTFRsaXdLTmgyZmZDTEpPcjRtNU9sZDBrSytUTUUvc0dPRzNUTFdQSGp3?= =?utf-8?B?MzZpeDl6ZjF5MEFLSTRHMFZldkI5WklpZjBFMHRDR1k4ZTFtdTJ2MFhFakFM?= =?utf-8?B?ckhISG9hYTQwdjVzN0pHZ3IzMnlUcVNHMkhRc1NELzVzcjI1YkF3OU92TVVE?= =?utf-8?B?dldqcmF1RnVrWGRQMzQwbXZIOTM2QW9CT2lRSWVDaEJMbjJOT2hXellZSmxP?= =?utf-8?B?QlRjYWdJaDJXUHRjaGlrRG9qZmJYWnI1SlUzV2h6L1FYTDRBdUQxVlY3cDFK?= =?utf-8?B?eTlGck1Fd0crVkhxeG9LeEVjZzI3TEFvYmwra3MvaktYU3B3TWVTdXFOaWM2?= =?utf-8?B?MUtibUEzVlo0MHhVcmpOZmpFM3RSZzdvMnR6NUtOeDhYbGVjcTI5ZVZTMXdG?= =?utf-8?B?MEpSbDJUdXpQSURicDlPN1BnWVZnRndTVzlYWCtFQU9MT2VhNlVsNnNyVkhZ?= =?utf-8?B?cEZsZDhSd0ltTm4zVlFsVUZFelF1SFQ0MWJ6bGxxaURYcXo0YlEvSFFFSVYx?= =?utf-8?B?UTdoclRCdzErQWZYdjN5WnR0Q2x2K3dLNzBSL0hvY3V0VGQ0dERCamNzdlFP?= =?utf-8?B?enc5WG9YZFZKRGttK21nQW9ZMlU3dHg4c3Eva3NYeU82Y2czZDB1bjVscGFo?= =?utf-8?B?UmhzRDFrMFB2Y29SN2FHdTd2SWdFTjFYY0gwY2xQVG9JcWpRbFJBdTZHOE8v?= =?utf-8?B?RHBiY1c5bEVNNVdPK1BTeXh3S3ZacGk2cnRsbEZBMkF0RkJJS0ZPdlk0VWFl?= =?utf-8?B?MjUwZk0rT3V5ME9MY05GSUdod2RNV2Z2Y1hiTmY4c0g0NE1WNFVJLzhGRVdL?= =?utf-8?B?Nk5oUU5hd2UxOUlUUWxvRjRnT1J2b0J0RTRPMDF6UUZPekxWK1NMY1l1c3lr?= =?utf-8?B?NStZcFlQNXVBTzN5cTBFd3BUTXNIb0pmZzFzUS9SYXdwWldWRUE2aEJQK0kz?= =?utf-8?B?QU9SeDRHOVNPSkpNY1JXNmNMdTBhSmZVUzFyd0s0V1lEUE4vbSszNjlEUmxO?= =?utf-8?B?c0RGMnF0KzJqR1VYWUNRY1ExajI5ZE5XNmdzRmtBMHMxNExKc2tyWHZocTd5?= =?utf-8?B?SHdJeWhTQWtHWUhIanJsWnJ6emU3VVc4MU5wNFN2QmVTMUhHTmV6Mk41VmR0?= =?utf-8?B?MmUyUDUxNGNwTC94QURnZWtQK2k5MThCUVdJQkFRdEVqUm53TUFuN2RDeTRT?= =?utf-8?B?dWxmSzVTaEcwMkhMVUlvUW9NOTFKaXd0L2tlOVpuMXplcnFpV1dBbWlGN0Fu?= =?utf-8?B?dzRMREh3cjdnPT0=?= 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?V3p4VS94UVFEbWtuRzJyb3RhdDJyTjRqWTgyZXNWbXVXcVg0bktDbGNpQlVF?= =?utf-8?B?eE8raUp6bWIwbmY3K2lBbzlBd0VaRUEwUkRKcVVqK3c0a2pPK0gvZkx5SDBL?= =?utf-8?B?Y25vTEZiNThpWmQ0bDZFRWROQ0cwUGkvRVN1M1FsWm40LzhPSnRiWHpGbVFI?= =?utf-8?B?U3BHNjV2ZXIrdXE3QWxBVlYyMmJBVjlEV3FLRVhDNng5bWs1R3JmOFNCZENG?= =?utf-8?B?aE0xVDc3QlRDZmtkMXp2REhkYlBQc3JYbWVROVJHM0RHanZDS042RWswanV2?= =?utf-8?B?bDNJMmRzZTJoMzk2d3M4NjhDUENUaG1ET1Z4b0hwTDFrTStjVHJPU2xEVjZ1?= =?utf-8?B?czdLbU5uY0xHYUZPUjN3NGlaM0ViSWxCVTRWa28veGlIL0RwV2U4eElVRXIz?= =?utf-8?B?SSs2N2YzUFo0OTJZaDBPUmJLQWFtanlOdXZNV3QxY0M5N2hNKy94YnIydnl5?= =?utf-8?B?STdUYWduQ3REbjNSWk9IN05Ra3VJZjBMQUJxMkRiSUJPN1Q2aEh6dVhUdnY0?= =?utf-8?B?S01WU0J0YkQ0T0szYk9EYU5BZXVteGtPQUxzeTVRamZTeURNV0o2OGFHSzNP?= =?utf-8?B?ejVkaUVZOXNVdU9zNzc5RVM1QUN6THAxTjRZNUtvc3ZiTlZva2N2eUhnejc1?= =?utf-8?B?b1B3RkdmdGpEcDNLZTkySzZJTHA5b3FrSGsxTk4vYVM4QWlTVTZxMDdOV0Rk?= =?utf-8?B?M2IzeE82a1M3NklzaTVlM1hmRTI2ZHpPUzNOdHNxbkFmTDk4UmlmK3JXMWgz?= =?utf-8?B?ZWFNSjVwMzI4YWpCRDVyTjBMMmhsVnk1elAvdUhycElFM2dGT3V4UXVGcGJ3?= =?utf-8?B?UjA2R3hZU3BJZzZoaXF5SW1ac0t5QTRwQXA2b3F0WEdVVDFyMkF2ZlNycWlQ?= =?utf-8?B?eTgyZHhWUkRGanhKdGpxN0NLZjBQemtVcGU5eEZOKzZ3dUtEQUNpdVBESW5k?= =?utf-8?B?dFlLNDB4OE5uYnJjQ2w5WWVkOFo3cnUvOGdqOHZXTTZoeXZlQTArQnNBcjd1?= =?utf-8?B?Umx4ZU9HT2x5eXdTZkNMT2lGUk9NSkVORXhYSFVzdEcwclo0U25uWnpnUjI3?= =?utf-8?B?TERkbmp1REhRenR5aVVnZUFpQnc2VHJWUFV2RUM5N0poamc2VlJjSkVtZXp1?= =?utf-8?B?RUsxOU5ueHJINUd0Ni9RdGpJN0psRTIrK0ZlL3ZCYUZPZithRXVWZWY0RFJT?= =?utf-8?B?ZUZkcVE0QmRlRnRURzhCUVFBNVRKbkpXRUdFL1NnaHlmOFIyTVgwZmlwUHp4?= =?utf-8?B?MndMV2k1cDE5bXBNWmYrVitjb2dTdDQvSGl5eGpNbmJTMTBIeXZqOWZTUDQ3?= =?utf-8?B?UTdPN0ZONWp1emhiellGMDhvYkN2SElUMUJmTGhrNHBSZjcyNmE5OVVlZk5t?= =?utf-8?B?SDZONXUrWTZxbFpNL3lDOXZhbjFpSi9iWGowVndhQThRT1lwVEZ3N3BCakl1?= =?utf-8?B?M2o2WGlyZ09ST251R1JGbEY1VXgyc3hzMUdYR0JRbUlSazUzZ3ZndnEzNjA1?= =?utf-8?B?aVd4RkhFTmVSSEdZeHZqTUl5NlBPMkROak5VaHBIRXhtOUJmTkVhb0tmUCty?= =?utf-8?B?cDlYdUluMWNHY3locWluWVgrekNKcHZ5UnNsK1FFVjdxY3hqZHpVUDJPODky?= =?utf-8?B?MzY3enAycllPUytpblNSSVVZT1RiVU8wTkM3MVdFSGZ2WE1wWmlaTGNmWC9Y?= =?utf-8?B?NUQ2bE9hanBXcnpwSnczZXAvSUp4SmNxdlVjT1N6cWFLNG5oeVRyTEt0eTZm?= =?utf-8?B?aVVvbzk0VU16STJ6ZldiV21hWU14NGpQbjV5Z3FweGVrbVJ5Kzl1WWIrMmpS?= =?utf-8?B?ZjZ5WS93YUxWQTlRL3ZTSXNOTkloRFNVUFo5d1Npa2phYjJkRWhzRXJOZWht?= =?utf-8?B?a3RvL29WN1RpWFEwbHVUbGRxK0lIU2haZkN3MjNwMm1KNjBRVkZ2YTlDSnhX?= =?utf-8?B?bE8xT3RiWFRrWVV2N09tbWcwd1QvR25DejdmazdNc1JrZ3R0OW9VWHo5S1Br?= =?utf-8?B?UW5paFJZeU9ZemZjdDg0Z1VmalVUcEcrU1RPd2JVcHdpdGxIcjNqdUZKQ0ZK?= =?utf-8?B?b3kwMVdXckdvRUJXRjNaN1V0cUhULzhaQnBRd0NaYmJ2bGhmbUNBR1BOZ0Nt?= =?utf-8?Q?c280=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: 6cc82468-9bb5-42e4-ea7c-08dde906b180 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 03:21:51.3527 (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: ZQvziCRBFwNikfuqiJ6ZoRcdRGURPnK1tCwujkQQLLYipQF/HbhmI7+qWemLLDL99soiYoLwc462m6ZrfFS3Bg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF28614436A W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDI5LCAyMDI1 IDI6MTIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6 IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3 LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu Y29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+OyBPcnpl bCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8anVsaWVu QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+ OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc7IEFuZHJ5dWssIEphc29uDQo+IDxKYXNv bi5BbmRyeXVrQGFtZC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjggMy84XSB4ZW4vY3B1 ZnJlcTogaW1wbGVtZW50IGFtZC1jcHBjIGRyaXZlciBmb3IgQ1BQQyBpbg0KPiBwYXNzaXZlIG1v ZGUNCj4NCj4gT24gMjkuMDguMjAyNSAwNTozMCwgUGVubnksIFpoZW5nIHdyb3RlOg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxp Y2hAc3VzZS5jb20+DQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjgsIDIwMjUgNzoyMyBQ TQ0KPiA+Pg0KPiA+PiBPbiAyOC4wOC4yMDI1IDEyOjAzLCBQZW5ueSBaaGVuZyB3cm90ZToNCj4g Pj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGFtZF9jcHBjX2NwdWZyZXFfdGFyZ2V0KHN0cnVjdCBj cHVmcmVxX3BvbGljeSAqcG9saWN5LA0KPiA+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHRhcmdldF9mcmVxLA0KPiA+Pj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHJlbGF0 aW9uKSB7DQo+ID4+PiArICAgIHVuc2lnbmVkIGludCBjcHUgPSBwb2xpY3ktPmNwdTsNCj4gPj4+ ICsgICAgY29uc3Qgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhID0NCj4gPj4+ICtwZXJf Y3B1KGFtZF9jcHBjX2Rydl9kYXRhLCBjcHUpOw0KPiA+Pg0KPiA+PiBJIGZlYXIgdGhlcmUncyBh IHByb2JsZW0gaGVyZSB0aGF0IEkgc28gZmFyIG92ZXJsb29rZWQuIEFzIGl0DQo+ID4+IGhhcHBl bnMsIGp1c3QgeWVzdGVyZGF5IEkgbWFkZSBhIHBhdGNoIHRvIGVsaW1pbmF0ZQ0KPiA+PiBjcHVm cmVxX2Rydl9kYXRhW10gZ2xvYmFsLiBJbiB0aGUgY291cnNlIG9mIGRvaW5nIHNvIGl0IGJlY2Ft ZSBjbGVhcg0KPiA+PiB0aGF0IGluIHByaW5jaXBsZSB0aGUgQ1BVIGRlbm90ZWQgYnkNCj4gPj4g cG9saWN5LT5jcHUgY2FuIGJlIG9mZmxpbmUuIEhlbmNlIGl0cyBwZXItQ1BVIGRhdGEgaXMgYWxz byB1bmF2YWlsYWJsZS4NCj4gPj4gcG9saWN5LT5TZWUNCj4gPj4gY3B1ZnJlcV9hZGRfY3B1KCkn cyBpbnZvY2F0aW9uIG9mIC5pbml0KCkgYW5kIGNwdWZyZXFfZGVsX2NwdSgpJ3MNCj4gPj4gaW52 b2NhdGlvbiBvZiAuZXhpdCgpLiBJcyB0aGVyZSBhbnl0aGluZyB3ZWxsLWhpZGRlbiAoYW5kIGxp a2VseQ0KPiA+PiBsYWNraW5nIHNvbWUgc3VpdGFibGUNCj4gPj4gY29tbWVudCkgd2hpY2ggZ3Vh cmFudGVlcyB0aGF0IG5vIHR3byBDUFVzICh0aHJlYWRzKSB3aWxsIGJlIGluIHRoZQ0KPiA+PiBz YW1lIGRvbWFpbj8gSWYgbm90LCBJIGZlYXIgeW91IHNpbXBseSBjYW4ndCB1c2UgcGVyLUNQVSBk YXRhIGhlcmUuDQo+ID4+DQo+ID4NCj4gPiBDb3JyZWN0IG1lIGlmIEkgdW5kZXJzdGFuZCB5b3Ug d3JvbmdseToNCj4gPiBObywgbXkgZW52IGlzIGFsd2F5cyBwZXIgcGNwdSBwZXIgY3B1ZnJlcSBk b21haW4uIFNvIGl0IG5ldmVyIG9jY3VycmVkIHRvIG1lDQo+IHRoYXQgY3B1cywgb3RoZXIgdGhh biB0aGUgZmlyc3Qgb25lIGluIGRvbWFpbiwgd2lsbCBuZXZlciBjYWxsIC5pbml0KCksIGFuZCBv ZiBjb3Vyc2UsIG5vDQo+IHBlcl9jcHUoYW1kX2NwcGNfZHJ2X2RhdGEpIGV2ZXIgZ2V0cyBhbGxv Y2F0ZWQgdGhlbi4NCj4NCj4gV2VsbCwgdGhlIHF1ZXN0aW9uIGlzIGhvdyBkb21haW5zIGFyZSBv cmdhbml6ZWQgd2hlbiB1c2luZyB0aGUgQ1BQQyBkcml2ZXIuDQo+IEFpdWkgdGhhdCdzIHN0aWxs IGRyaXZlbiBieSBkYXRhIHBhc3NlZCBpbiBieSBEb20wLCBzbyBpbiB0dXJuIHRoZSBxdWVzdGlv biBpcyB3aGV0aGVyDQo+IHRoZXJlIGFyZSBhbnkgY29uc3RyYWludHMgb24gd2hhdCBBQ1BJIG1h eSBzdXJmYWNlLiBJZiB0aGVyZSBhcmUsIGFsbCB0aGF0IG1heSBiZQ0KPiBuZWNlc3NhcnkgaXMg YWRkaW5nIGEgY2hlY2suIElmIHRoZXJlIGFyZW4ndCwgLi4uDQo+DQoNCkFjY29yZGluZyB0byBB Q1BJIHNwZWMsIF9QU0QgY29udHJvbHMgYm90aCBQLXN0YXRlIG9yIENQUEMsIHNvIGluIG15IGlt cGxlbWVudGF0aW9uIG9mIGdldHRpbmcgQ1BQQyBkYXRhIHBhc3NlZCBieSBEb20wKHNldF9jcHBj X3BtaW5mbygpKSwgSSBkZW1hbmQgYm90aCBlbnRyeSBleGlzdCwgX1BTRCBhbmQgX0NQQy4NCmBg YA0KICAgICAgICBpZiAoIGNwcGNfZGF0YS0+ZmxhZ3MgPT0gKFhFTl9DUFBDX1BTRCB8IFhFTl9D UFBDX0NQQykgKQ0KICAgICAgICB7DQogICAgICAgICAgICAgICAgLi4uDQogICAgICAgICAgICAg ICAgcG1faW5mby0+aW5pdCA9IFhFTl9DUFBDX0lOSVQ7DQogICAgICAgICAgICAgICAgcmV0ID0g Y3B1ZnJlcV9jcHVfaW5pdChjcHVpZCk7DQogICAgICAgICAgICAgICAgLi4uDQogICAgICAgIH0N CmBgYA0KDQo+ID4+IFNpbmNlIGluaXRpYWxseSBJIHdhcyB0aGlua2luZyBvZiB1c2luZyBwZXIt Q1BVIGRhdGEgYWxzbyBpbiBteQ0KPiA+PiBwYXRjaCwgSSdtIHJlcHJvZHVjaW5nIHRoaXMgaW4g cmF3IGZvcm0gYmVsb3csIGZvciB5b3VyIHJlZmVyZW5jZS4NCj4gPj4gSXQncyBnZW5lcmFsbHkg b25seQ0KPiA+PiA0LjIyIG1hdGVyaWFsIG5vdywgb2YgY291cnNlLiBZZXQgaW4gdHVybiBmb3Ig eW91ciBkcml2ZXIgdGhlIG5ldw0KPiA+PiBkcnZfZGF0YSBmaWVsZCBtYXkgd2FudCB0byBiZWNv bWUgYSB1bmlvbiwgd2l0aCBhbiAiYWNwaSIgYW5kIGEgImNwcGMiIHN1Yi0NCj4gc3RydWN0Lg0K PiA+DQo+ID4gSG93IGFib3V0IEkgZW1iZWQgbXkgbmV3IGRyaXZlciBkYXRhICIgc3RydWN0IGFt ZF9jcHBjX2Rydl9kYXRhICogIiBpbnRvDQo+IGNwdWZyZXEgcG9saWN5LCBtYXliZSBwb2ludGVy IGlzIGVub3VnaD8NCj4gPiBMYXRlciwgbWF5YmUsIGFsbCAiY3BwYyIsICJhY3BpIiBhbmQgImh3 cCIgY291bGQgY29uc3RpdHV0ZSBhbiB1bmlvbiBpbiBwb2xpY3kuDQo+DQo+IC4uLiBJJ2QgcHJl ZmVyIHRvIGdvIHRoZSB1bmlvbiBhcHByb2FjaCByaWdodCBhd2F5LiBXaGV0aGVyIHRoZW4gdG8g dGFrZSBteSBwYXRjaCBhcw0KPiBhIHByZXJlcSBpcyB0YmQ7IHRoYXQgbGFyZ2VseSBkZXBlbmRz IG9uIHdoYXQgKGlmIGFueXRoaW5nKSBpcyBuZWVkZWQgb24gdGhlIEhXUA0KPiBzaWRlLiBJZiBI V1AgbmVlZHMgZml4aW5nLCB0aGF0IHdhbnRzIHRvIHRvIGNvbWUgZmlyc3QsIGFzIGl0IHdvdWxk IHdhbnQgYmFja3BvcnRpbmcuDQo+DQo+IEphbg0K From xen-devel-bounces@lists.xenproject.org Mon Sep 01 06:38:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 06:38:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104070.1455229 (Exim 4.92) (envelope-from ) id 1usyBP-00073S-Ai; Mon, 01 Sep 2025 06:38:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104070.1455229; Mon, 01 Sep 2025 06: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 1usyBP-00073L-79; Mon, 01 Sep 2025 06:38:27 +0000 Received: by outflank-mailman (input) for mailman id 1104070; Mon, 01 Sep 2025 06:38:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1usyBN-00073F-NU for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 06:38:25 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3e00abc5-86fe-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 08:38:17 +0200 (CEST) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-61e425434bbso1286990a12.2 for ; Sun, 31 Aug 2025 23:38: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 4fb4d7f45d1cf-61cfc4bbca5sm6516001a12.31.2025.08.31.23.38.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Aug 2025 23:38: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: 3e00abc5-86fe-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756708696; x=1757313496; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/bbYtzZZq1q4hIl2v+vqBxOpKtDezo41+4YySzDYONw=; b=Ovy4Sr3xX1AGzah/SiObI388xQtFjE+t9lFl9ukz9GJ4BStka8re2t4mlsq56pX+PM 2fL3xDLqmEIWIMWyXBNAFoviDpJjp6FsEzRfWqOP0VWiIs8RrEu9foukXNLr3g4DIFZW 4PvYnjxpbpzcltpudHh9YniTgNM/N+WRMAcA3tAwV71Mk3CoPTQbwLOiac/FO9fTeLLs H2kmEVQjYyVAPwiaVtEng+UhTEffmIJBZJP5EgCBd/cZ3rovpjNnORIsjFXrljgZp2Dm D4r3vL4Hd/HzxVEQfSTaM7ruIa1XcmxHPTFVqvdJZ6sViw6WEijmlWht1Sl+g6Ixb+G1 aDtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756708696; x=1757313496; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/bbYtzZZq1q4hIl2v+vqBxOpKtDezo41+4YySzDYONw=; b=shuLzGVimPy087px5wTtwqLNzCY9eU071iOjtCpS9hTjlxGpOLD4PuTJB1HcfbjmpV 6OQQWptA2Gv0quhAMAOJHiuliu0zW24U0hJqFoYa1St4Vq9Cwq9PQwfHaQhRlp5nBX5H R4SLTn8ic05pUrLxSwaDBc2L/AxN+4IRqDitbPP3KrMldqjVvUf6SRZMtqwtlMg13wTv 39kEVYPCSvRvDiHK2RQOuWmv5Vh9HRt2zUdvzuSH9ivcn2y9mgjBrqvt/LG9UJL8erW4 HjdbhK3ysiMapm0f5XOIvk9pEwDzKw0vx82yIm0yl3QDRUNb41pT1QYabyzxFacnPMN3 iRnw== X-Gm-Message-State: AOJu0YwOnQlrpLZfpC2qIOwLpssCOAORJ0ezNR4mlQ2VFQa1gE4pEVXq UwU/sCAXz7CQd0HjpoJJDxYn4qV1dHBEnCebSnUe7XqyTeyJgNP5xdzkCEzDKZavUA== X-Gm-Gg: ASbGncu8rfPEFLNDBx3Hblc43ludQ56nUSF3pAs+k1148Ky/S3UyC36GKhFeyeSW3oQ DN6hd8+tYLU40dUP54wHSN7F3m5wj4HEfEZ1wW/xMWYNeYTJFVOc4ucs10vRJwbR24k6s4EbQub 9yBljIau/gjNfZS4cjH2toE9HMtU2d23L+EowNMqJXmM3YVm6aRjlMhcjWJ73GYctk235AbX0GP J9IIq6XdmPyItpEAo6j+589bUhpOzCNVXy7H1ZZ1ggnrinpJ5p892e7HeqD5BLkVt9nSDd2/E6a uJh4t9FtM56cRO701bEye/WPQOionhbsv1jW/FVQYYniL1B/fRb1KjiVOZ6DqXcOXoTez1T1LPf tgMOGDGDBYH0ZCmjm3157rq77Z8yWjjdacupA1g3bhhm4o1W5Wiixn1Go46ViZy5ybqJ8EtA30S IqCJALrf4= X-Google-Smtp-Source: AGHT+IGHPXTNOQ5+vamsmwnm/8nFONdlt1vv50kuKhqtut74Bf9G+yD4Dtse5BsqtQivNXOgz2M9Ow== X-Received: by 2002:a05:6402:5207:b0:61c:5cac:293f with SMTP id 4fb4d7f45d1cf-61d26869f4fmr6458639a12.6.1756708696454; Sun, 31 Aug 2025 23:38:16 -0700 (PDT) Message-ID: <4d39fe27-18ef-4e00-9c92-96bf6e76b8b3@suse.com> Date: Mon, 1 Sep 2025 08:38:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] symbols: add minimal self-test 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: <879646dd-b55e-4b42-b637-d3b14570b880@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 29.08.2025 16:24, Roger Pau Monné wrote: > On Wed, Apr 02, 2025 at 03:57:57PM +0200, Jan Beulich wrote: >> ... before making changes to the involved logic. >> >> Signed-off-by: Jan Beulich >> --- >> While Andrew validly suggests cf_check isn't a requirement for selecting >> which function(s) to use (with the non-upstream gcc patch that we're >> using in CI), that's only because of how the non-upstream patch works. >> Going function-pointer -> unsigned long -> function-pointer without it >> being diagnosed that the cf_check is missing is a shortcoming there, and >> might conceivably be fixed at some point. (Imo any address-taking on a >> function should require it to be cf_check.) Hence I'd like to stick to >> using cf_check functions only for passing to test_lookup(). >> >> With this FAST_SYMBOL_LOOKUP may make sense to permit enabling even >> when LIVEPATCH=n. Thoughts? (In this case "symbols: centralize and re- >> arrange $(all_symbols) calculation" would want pulling ahead.) >> >> --- a/xen/common/symbols.c >> +++ b/xen/common/symbols.c >> @@ -260,6 +260,41 @@ unsigned long symbols_lookup_by_name(con >> return 0; >> } >> >> +#ifdef CONFIG_SELF_TESTS >> + >> +static void __init test_lookup(unsigned long addr, const char *expected) >> +{ >> + char buf[KSYM_NAME_LEN + 1]; >> + const char *name, *symname; >> + unsigned long size, offs; >> + >> + name = symbols_lookup(addr, &size, &offs, buf); >> + if ( !name ) >> + panic("%s: address not found\n", expected); >> + if ( offs ) >> + panic("%s: non-zero offset (%#lx) unexpected\n", expected, offs); > > If there's a non-zero offset returned, could you also print the > returned name? (so use %s+%#lx) there's a change the returned name > doesn't match what we expect if there's a non-zero offset. Hmm, perhaps we could, even if that's not the main goal of the test. Note though that the patch has gone in already, with Jason's R-b. > The rest LGTM: > > Acked-by: Roger Pau Monné Nevertheless, thanks. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 07:52:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 07:52:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104096.1455239 (Exim 4.92) (envelope-from ) id 1uszKp-0007xr-Sj; Mon, 01 Sep 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 1104096.1455239; Mon, 01 Sep 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 1uszKp-0007xk-PQ; Mon, 01 Sep 2025 07:52:15 +0000 Received: by outflank-mailman (input) for mailman id 1104096; Mon, 01 Sep 2025 07:52: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 1uszKo-0007xe-67 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 07:52:14 +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 91fb39d6-8708-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 09:52:12 +0200 (CEST) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-61cf0901a72so5614296a12.1 for ; Mon, 01 Sep 2025 00:52: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 4fb4d7f45d1cf-61ded4749aesm2528521a12.32.2025.09.01.00.52.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 00:52: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: 91fb39d6-8708-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756713132; x=1757317932; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=OhHt4UHlmSfKD3CpMl2L+yj0zfhifc+csgHlsFFcPww=; b=gyLmh1KMCRa173mQTfliKSg4DR3PE0yPJomUx1X5ErLgRod+YS7n+UpAWM8MZYaJ0t +DvkmZW2x6wSvrK4j+Q3YA+TIeE2j+tcGvqiuYLnLh1X6EY2T4SlfSB+tmr47wPxLVij 0fvbAM1RKjCqta6mS7s7+BudMgZiBgZObaOsXcOcnxOfZYsUxpZvsHP6qneq01kmZobs wFLLtQ2mTRprzpdwhsff+zULs3xUEBJ0f/fzif3L6GGJ9A5733JFCUI623wVWNSGBjbB VSjkcn2LdQTamTfugdke2NGx8NTwNTVgVFtXgR7ZWvhG6xBg26Pr5uaC8F1J3ZdAi2Sc WgUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756713132; x=1757317932; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OhHt4UHlmSfKD3CpMl2L+yj0zfhifc+csgHlsFFcPww=; b=Umzhw+r13qWyWjYf9OVSRZzu9YJVMC4oopdtWUuidxpBwYxkYVkFx/XNjBCwQWIK0P TtJxwVQG05jCKs0C3PER814W3BVoKATMdf7CQPGDlXI+HIXXF1f+n/NrYJHalzQy+Sjw JjglhpzC0uS8L62XhOsKyPPfRSlNHjXpZzZxTclmiZyt1LatUpTyOJ/C0F/y2QJo5baK 2vgUf4f+8q0h3AEmoP4H4T6Q9n9eynSa+J9ketP77i5resu0CiG0pe7CVy6k3Sc2cQsw rXVFkfY23Bu1jApJ/QAAZw++zL+823n0jWT67LxlxAPZzW49JUjFIgyIFcJ/py74kdyb xNoQ== X-Forwarded-Encrypted: i=1; AJvYcCV2V5xH0mzOEYDcwjzPZI4AsZE4hvC7URG3HEUgUyVZ8yXKDgSrvZapqeEb9t8h5WraHCdZ8S4/nVQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YzIp1AVhg24SS077tSg968cPbJAqDrjFZbI+kz+okZLc6Czy4Wm 413ZAJ1IzHmtNVfvhtHTgCVi7zIGM+S19bE0X0BTJsS9ruwMQRWXOv6rWNwI2e4sgg== X-Gm-Gg: ASbGncsx0JDCfCKhFIx3T00KU2XRhjFHAY5GF6UpI4uczJgIQRpRq9QPZErYIGFt+fJ aOVcgj4OFzpeixEWaKPpslDtTosEjTLO0hDP7SCBLDUt/wAOImyNpjgugtk78WWXMCgwlfW9PIJ QlUlPGAyGaJ8WCnFI8i0Sv592Krbvk51qIR+13USEtL4NVKeN8B5AIjVHH+RmkOEUWDDWO4CSmA I7OY33WvjbSjP3MPC2cz/6iUWz7gwB+uDwUixS/03fNzVBPpCg0ND+DP5B+XHj8xgXPp/H/+kzo I3K8alFZIb2wQLtWQ5u+CmwV5NxzA4+a/qby2PyhdAHnBBAbf1GhHNcvQQ4rZwFiUfIVa8Ryur1 twWbrQYxr2bYSpeQ73tSaOEa4kjVN8iFnSf5druSHHio6oScerzTBFWZTK4j77BiaufGLeHPF7L SI+WlzcWw8X8lPVhTC2g6eyIe5TqLe X-Google-Smtp-Source: AGHT+IEI9fAsBoOnMM8dfOls3p79YvVT6iLwVBUPGftQyEF8U1QtMa87tZ33qUqVvAy7UMcut0fiEA== X-Received: by 2002:a05:6402:35d5:b0:618:19d2:7251 with SMTP id 4fb4d7f45d1cf-61ea14dffd0mr1653787a12.10.1756713132339; Mon, 01 Sep 2025 00:52:12 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 09:52:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v1] xen/flask: limit sidtable size To: Sergiy Kibrik Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20250822095123.998313-1-Sergiy_Kibrik@epam.com> <1797679c-582f-4b75-a036-ad3bb00bad4d@suse.com> <1d34d0ae-f3f3-4b25-ae67-6c4f6be2e2bb@epam.com> <59e884d4-e111-474c-9794-dcb190de8eab@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 30.08.2025 17:23, Sergiy Kibrik wrote: > 29.08.25 14:44, Jan Beulich: >> On 29.08.2025 13:33, Sergiy Kibrik wrote: >>> 25.08.25 15:00, Jan Beulich: >>>> On 22.08.2025 11:51, Sergiy Kibrik wrote: >>>>> --- a/xen/common/Kconfig >>>>> +++ b/xen/common/Kconfig >>>> >>>> I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig >>>> file there. >>> >>> you mean something like Kconfig.xsm in the same common/ directory? Or >>> move this Kconfig out into xsm/ directory with the rest of flask code? >> >> The latter would be preferable imo. > > then it probably will have to be moved outside Common Features menu and > into the main configuration menu, while having 6-7 items. Is it ok to > keep such small submenu for that? I think so. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 07:58:49 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 07:58:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104108.1455248 (Exim 4.92) (envelope-from ) id 1uszR6-0000BG-MG; Mon, 01 Sep 2025 07:58:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104108.1455248; Mon, 01 Sep 2025 07: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 1uszR6-0000B9-Je; Mon, 01 Sep 2025 07:58:44 +0000 Received: by outflank-mailman (input) for mailman id 1104108; Mon, 01 Sep 2025 07: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 1uszR4-0000B1-Jw for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 07:58:42 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 79adbb7d-8709-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 09:58:41 +0200 (CEST) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6188b7550c0so4794340a12.2 for ; Mon, 01 Sep 2025 00:58: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 a640c23a62f3a-b0431832a98sm133994266b.80.2025.09.01.00.58.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 00:58:40 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79adbb7d-8709-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756713521; x=1757318321; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=xdIUtIQmXUoYqJt3tM/kewKZM5sAxU84JgTSFymboaU=; b=Dx1+mTjp63pV5/Hw+xyBaSka7haVZKaD82WXuLrqlviDKqdYywnrqAOUmtkKA5vpoJ lRJQdCfgLmIGV+WnyA6pXKiA7r/mzV8vvVWFAWRpfCis0ktznqxWyJz1EdwRbyrHWi0F PUsTCZaj264lvcGXrWiFFyEOqFSO1gqi8dkQ/HXbO5QuoJqksJn5SvC2RkLFMr0j4RgC ahFFtTjbcz6+5ZQb8J9y8Wrg48o6oSMl0y45OC0q7OgbJE9G8AWjvL+rWWLjsG657Hsw aWZwYe04uVdgoD40z4RLQQbfpcTkzPo2x+4gAav9qGLnz5VcCnNJrorNJ8zLkXGJs0zq wSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756713521; x=1757318321; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xdIUtIQmXUoYqJt3tM/kewKZM5sAxU84JgTSFymboaU=; b=hIe4820svqMRoMnp/BGrJ1xtePkjc2o/7oWJ+w+u5nZfzMrMakdYREhwMh+VLsq/Kb mh3MuZ3M35syCVSkSWWcg7EpF+kbyAQwVQ0qhur/7Jcsixw0nodiDtpf2eXU3TNf5qfP 8RVx/t8Z5cnXnFhQYJTgWqhb1S4BGciIjIyOIOVHLVFJfxENpIM1jCH/jD48Zq0z7I7c ztSnfSfn5zn8K8Dil1T8ZVsJYvqPYyJjWyBh1bDJvA1k3uF+VMtFMH5ToC1FPa5TiRCo fZXgpJVqa4ojp6nwVR5rxvynvr8NSvNcvGZ4C3T8Ph7DBtX4LAUV90LBCxaW2PdodZiS OUhQ== X-Forwarded-Encrypted: i=1; AJvYcCVef4zsXUl2oa78oDgd3IgN5TelfoIGSH6xni0eCsYGnLiI7owpg6VYkdB1nj5G1OfT5G7DEwsdWCw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzYd7H0l9dGqPx6MUaiYRsgQ7gYPAMMIB0kcIYHiREnLxD9AuHP yiCjerAHei+N6G7EZzbqDT/wqoAih/Xp/6jltRNy8isjCa92B5E2HeDOp5Y6m5ndBw== X-Gm-Gg: ASbGncsHILW54RidZObi02YudpoXP93lfyj7Ol1YwcJY8AWnK77af42/r66Zlz/add7 jGJC1S0JO1Xu1Pn0ozmGDSEYU94ddvKhAFuC98D4PxcCOavrs7fP6wM+S83X5DgCINHDfhHAPmY G0mIr4trt1/EtxbaQRBL4dd3RJo4y1G3SGLDdsCS6dfjThdefEKAOsQW5D8ancTkI0BMKJbn2x2 Bsf5/nqK6HflXo8MgjB+hY+ZIoawHXNG1fzyaJtWFRlUIzZ07das01BjwZ0dRRXdcX7WBgJ+OKQ ueXiYxBJ1lIJYjbWEmhbO/ISq5BzqBv6RbVddrCWTsy7k87p+8su4iZjvV7aE1rvyPbEwg5g3mG B7OQLyRSeb8EeuOalNGJQUNgS6dzGEr4TuDBKD6MvyzlCTxvcNinqO9G9HKbntY7dPkAlrVgpTf E2CSag5Ln8gsK43MFGcgwrZ3IYHUvk X-Google-Smtp-Source: AGHT+IF59r9hGGFlmOyLRZDcXBrdwW6KX8FBY3CnlMdkjGFOaLxEjhpzTkXEoM5O5eAI4h7QsZoLZA== X-Received: by 2002:a17:906:9f92:b0:afe:a615:39ef with SMTP id a640c23a62f3a-b01d8a2667emr663142966b.9.1756713521006; Mon, 01 Sep 2025 00:58:41 -0700 (PDT) Message-ID: <16bd9d1c-66da-4526-8489-8b075678c4bb@suse.com> Date: Mon, 1 Sep 2025 09:58:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 3/8] xen/cpufreq: implement amd-cppc driver for CPPC in passive mode 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" , "Andryuk, Jason" References: <20250828100306.1776031-1-Penny.Zheng@amd.com> <20250828100306.1776031-4-Penny.Zheng@amd.com> <1ad85430-2aa7-4834-be56-67515ca51310@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 01.09.2025 05:21, Penny, Zheng wrote: > [Public] > >> -----Original Message----- >> From: Jan Beulich >> Sent: Friday, August 29, 2025 2:12 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; Andryuk, Jason >> >> Subject: Re: [PATCH v8 3/8] xen/cpufreq: implement amd-cppc driver for CPPC in >> passive mode >> >> On 29.08.2025 05:30, Penny, Zheng wrote: >>>> -----Original Message----- >>>> From: Jan Beulich >>>> Sent: Thursday, August 28, 2025 7:23 PM >>>> >>>> On 28.08.2025 12:03, Penny Zheng wrote: >>>>> +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); >>>> >>>> I fear there's a problem here that I so far overlooked. As it >>>> happens, just yesterday I made a patch to eliminate >>>> cpufreq_drv_data[] global. In the course of doing so it became clear >>>> that in principle the CPU denoted by >>>> policy->cpu can be offline. Hence its per-CPU data is also unavailable. >>>> policy->See >>>> cpufreq_add_cpu()'s invocation of .init() and cpufreq_del_cpu()'s >>>> invocation of .exit(). Is there anything well-hidden (and likely >>>> lacking some suitable >>>> comment) which guarantees that no two CPUs (threads) will be in the >>>> same domain? If not, I fear you simply can't use per-CPU data here. >>>> >>> >>> Correct me if I understand you wrongly: >>> No, my env is always per pcpu per cpufreq domain. So it never occurred to me >> that cpus, other than the first one in domain, will never call .init(), and of course, no >> per_cpu(amd_cppc_drv_data) ever gets allocated then. >> >> Well, the question is how domains are organized when using the CPPC driver. >> Aiui that's still driven by data passed in by Dom0, so in turn the question is whether >> there are any constraints on what ACPI may surface. If there are, all that may be >> necessary is adding a check. If there aren't, ... >> > > According to ACPI spec, _PSD controls both P-state or CPPC, so in my implementation of getting CPPC data passed by Dom0(set_cppc_pminfo()), I demand both entry exist, _PSD and _CPC. > ``` > if ( cppc_data->flags == (XEN_CPPC_PSD | XEN_CPPC_CPC) ) > { > ... > pm_info->init = XEN_CPPC_INIT; > ret = cpufreq_cpu_init(cpuid); > ... > } > ``` That's only about presence of the data though. My remark, otoh, was about its content. It could in principle be specified somewhere that no domain may cover more than a single CPU / thread. In the absence of such, the case needs handling correctly. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 08:14:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 08:14:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104122.1455258 (Exim 4.92) (envelope-from ) id 1uszgA-0003Rx-1I; Mon, 01 Sep 2025 08:14:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104122.1455258; Mon, 01 Sep 2025 08: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 1uszg9-0003Rq-Ur; Mon, 01 Sep 2025 08:14:17 +0000 Received: by outflank-mailman (input) for mailman id 1104122; Mon, 01 Sep 2025 08:14: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 1uszg8-0003Ri-U9 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 08:14:16 +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 a12eb794-870b-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 10:14:06 +0200 (CEST) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-61cb9e039d9so7977709a12.1 for ; Mon, 01 Sep 2025 01:14: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 4fb4d7f45d1cf-61cfc1c7ed1sm6740456a12.1.2025.09.01.01.14.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 01:14: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: a12eb794-870b-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756714446; x=1757319246; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=LnTjTlkxSTo+O8IMNavi+odu+EOnDJITVeZaSR4UGi0=; b=DFaqBW0gDzUBbx8GjSMRt0w+v/sYKt1sVl1uzTpTocK/NKGYEuj0QyiQ5sBPbp4a9R rKSGSYRgNdODz++gwaOkhBL8mJqWHgI2kNjsJXYZjBqXT1etM8OtTcbiUkXeHwm3VSd6 Mp3A+mbKkL1tjQgaXIjNMITZEUViT3jXu7J7I6cuHKBAVkXcYld3UQjfnSH2p/pOiXUK qJQMnqOGPidb3JLt/yx26r5VTbSoIyppvaiHJSBAta6fTUiAc4RfnmdNmjN0BsBTQkva EuZGysg1XMGZyU6ryIUlZwZsNvb4PPQPe95AP+9nNc/HbY0VewXv1J4dmlzD6BGMrpw6 latQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756714446; x=1757319246; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LnTjTlkxSTo+O8IMNavi+odu+EOnDJITVeZaSR4UGi0=; b=XRsnYf+FjgbUouW4qTAsLNzigAYqQ+nKW8lMo519kU9n6vTw4koVVW/LmcNqtZJK94 81nrj1vAwqPylqy2Xe3jfDnReC09DPOzZZhGTef+HYOBORbaX3D2oS4pfBGbNk07nQMO kBEVofMhLxSWZEv3unYGvWuYDsUpgM3fU30FfVeYBfxI/NjnXw3eXlzunPbwe3vUhSmI KqhOnuig2tlV1brPBv+wbbq1DZ81nr32j40cwcWpOYBEAZePFX1mF1xFkRpBBOSqTajx s++ETz95pJFaAJ5si3VMSvp59XkTaL9ufrf0l9Ia/kBS88PLIAIWI2OgrO6KdDKSKcgE 4hPw== X-Gm-Message-State: AOJu0Yw3E7OJqqGJMmSTTyrpu57KPBYbqaGzsspM3B+rSrt/HJ22o2pd zwyrXS3sDAdfiIbOeoDLIMSlX25GDt/seX9t8wZ5OfZmfsVbUpVyFMH/nX07ArrSjA== X-Gm-Gg: ASbGncusKvpvt4VzK+fWyTy5T0y/8vEo4Sge6UXiIbxrkBKiVxQtWcSkMEXKN98xXLQ wy4h03Dqd0wJt5/qeurHav8uj3UHTo4fimFGd2VTY/JcwVQUlz4OalzstM82v5mYmLsq5J20c6j xqEqBEXGVngAcY5DNPNSkjhRccl0iBGyfx9xFuCeSdZr06TaBxApg8SSqdGcHaZdeLVHBGRCRJj cgESCIEC8API5z7UWvAyPYFVGjZBnyE9Y0r/RUEsIG0QH5AKkZW/avIcsiNiMoRUuHNXz5Ua4dP fbQ5aS2RI4+8LTHNyRrSwI3Szb7Vpt6kNEmsmUIdXr9MCtv+jaDT/NnaXISTI+jICX+pAOR3lGt 0dXfF+GT84g+VMXUxC662hqqAosDw+HzJImO9c5jWF+/bzXQ1SNcuKNxikHzulMcGDcHLZ7JW9S zltTM7F4g= X-Google-Smtp-Source: AGHT+IFiEgu6xSz7DpSTXM0ahWBr1zkYJU4a358sdzlU7a2z8pbLSb6JNQ8LYYzE34Bshe3eMauFqg== X-Received: by 2002:a05:6402:304f:b0:61c:5756:c2b8 with SMTP id 4fb4d7f45d1cf-61d269a7bc7mr5345308a12.9.1756714446261; Mon, 01 Sep 2025 01:14:06 -0700 (PDT) Message-ID: <37f4c1af-29e3-44eb-a238-a3e2e4641f10@suse.com> Date: Mon, 1 Sep 2025 10:14:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 01/15] emul/vuart: introduce framework for UART emulators To: Stefano Stabellini 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, dmukhin@xen.org References: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.08.2025 21:27, Stefano Stabellini wrote: > On Thu, 28 Aug 2025, dmukhin@xen.org wrote: >> --- /dev/null >> +++ b/xen/common/emul/vuart/vuart.c >> @@ -0,0 +1,156 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * UART emulator framework. >> + * >> + * Copyright 2025 Ford Motor Company >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +#define for_each_emulator(e) \ >> + for ( e = vuart_array_start; e < vuart_array_end; e++ ) >> + >> +extern const struct vuart_emulator vuart_array_start[]; >> +extern const struct vuart_emulator vuart_array_end[]; >> + >> +static const struct vuart_emulator * >> +vuart_match_by_compatible(struct domain *d, const char *compat) >> +{ >> + const struct vuart_emulator *emulator; >> + >> + if ( d->console.vuart ) >> + return NULL; >> + >> + for_each_emulator(emulator) >> + if ( emulator->compatible && >> + !strncmp(emulator->compatible, compat, >> + strlen(emulator->compatible)) ) > > strncmp will continue until the given count even if compat is shorter Not really, one string having a nul char and the other not having one is a difference, at which point comparison will stop. There would be a problem if "compat" didn't point to a nul-terminated string, though (and I didn't check that aspect, not the least because then "shorter" doesn't really make much sense without a length passed in). Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 08:20:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 08:20:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104140.1455269 (Exim 4.92) (envelope-from ) id 1uszld-00043D-KO; Mon, 01 Sep 2025 08:19:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104140.1455269; Mon, 01 Sep 2025 08: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 1uszld-000436-GM; Mon, 01 Sep 2025 08:19:57 +0000 Received: by outflank-mailman (input) for mailman id 1104140; Mon, 01 Sep 2025 08:19: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 1uszlc-000430-Q8 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 08:19:56 +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 70b3e366-870c-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 10:19:55 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-61e930b27bcso992368a12.0 for ; Mon, 01 Sep 2025 01:19: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 4fb4d7f45d1cf-61cfc21542asm6521577a12.18.2025.09.01.01.19.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 01:19: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: 70b3e366-870c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756714794; x=1757319594; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/Ntv9uhtttoRB/Uk0kOrGp5s8MDYYihLI8Ig8hc7xww=; b=CnPE+fd6xo08I10k+2CDWol1M9iSYSVrM1srkGEBRE0tTEksETuf++7xFowmSCWcJ7 fNKjtjMzy6qrij0/FxicjS/B1av/jSqKrT8jQjpWMZELD6ygA1fQ/VgX/FLwEAj3B8Ev PCQXVMp+VvWZmEl1eqrYOQXvRfd6WvZ8eIC5hG+JxS0dbTivd0HWvmGsU4+iCaMDGVFP PI+ydHtI8I3v8eV6oN4Gzquf70Kw/ldIPgkcHdMi5ScdwQMOzJIevKOcvIqrgdca/IeA 9U03AYzKchqDtD8x6fpRLUeGp6I2JBsdJRf2d57OlBgAl0m3a0Wnx9JOIe4X+p1ORqd/ Clog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756714794; x=1757319594; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/Ntv9uhtttoRB/Uk0kOrGp5s8MDYYihLI8Ig8hc7xww=; b=w6cftrebZw7YHdXO/78HFTYlbzmMorbOnx98lVwb0AagLRGkfEdbAQ93Kq9h15kprQ jAH74r2tWHuiGqAZTDAqX6QTKbrRLOEsVnRw90iqE5p6Ut1rfHklz/bXXd5pIeV2N77W R0a7oaAhVuRSAgRTiCNa1mGXWeyUN+SybVYF/30qoSJzOLbVQ+NbKiTXMfBlh8hwjP7W 3RaNMUe9pTFG4+aDPuHSmRMzSwB+92c22emTEJEFj/9qq+qD28lHmVeAgY2vCWUvogya N0BwCLjfRatkyxjnW3opR0B3UBpmcUNTgNSt6cgY0YrwkuN4zs/v8D4mtDFKcEtef+LM j31A== X-Forwarded-Encrypted: i=1; AJvYcCXunNJewkENAvQgoEHZq8Y0vM73gZV1pslIiiyEOcR5dhuxD0Z3bFjBcsIkmkhCbWx/JVuHBbSpVjg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwZcUr8AFbTUi2jWK+YpmEdzeoWNiM5VNXYY4GQOvyEwRC1sUry ry5r00rJ9H3p09xWdpPKBYqFn/sZHdxTrQu54Cq2mtsnK91R6LsqkK4PcUOwaIRp+w== X-Gm-Gg: ASbGncsfXdtDLCxHlvoJGtaAv//mHZaz/6xOEXYNDeOtjgAxt4deIZo+bgHZGQqZvJE KtyE11qYHERFPudPEVRwxF/TaXW1JiobqZilo+eeX1Scn4OPRGFCar3zu+LrPtmYHySLRrPJ3cK JEAklOO+T5N1JQ7qcuPbehYjCIn8hWk2pZZrW/JWrlpYNpGINI65f6u1fcv0xMBo+csqcppVYsc ICz+LH8Lc73oPha1NpA/0FcFE5nk/PcE9YlgD9TAlgZfb2S6sWiM33H4+l90hQloluICuiuPK4Y zSw4lPn2R3ltj+8aKEKv9yT3b+tbVP4nofZ98P2qhcROEwiRyT3/3ByyIOV4Cl351aSGbwG1q3h sgSW7KD7BTQgQei3nnX55eHMViEQCCmEGnuv4D9cVOAPodaSCB9a9Arx3zS3JlnzeqkKKXqf+mU 0bgREPZ10= X-Google-Smtp-Source: AGHT+IGo/hOvPVUkuNCT1cCLjOXwjV+SqRx3dA1ygpYVdQpy6xs9Sf71w5x/yaBvGpvt/sabV3et1A== X-Received: by 2002:a05:6402:2110:b0:61c:d606:9ce5 with SMTP id 4fb4d7f45d1cf-61d268724d3mr6121205a12.4.1756714794317; Mon, 01 Sep 2025 01:19:54 -0700 (PDT) Message-ID: <9b72e0a6-9c7a-4788-abc7-ea20fc8db0e5@suse.com> Date: Mon, 1 Sep 2025 10:19:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/gen-cpuid: Fix debugging for cycle detection To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250829192939.1090358-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: <20250829192939.1090358-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.08.2025 21:29, Andrew Cooper wrote: > Jan reports the following exception when using the cycle debugging: > > Feature IBRSB, seen [IBRSB, STIBP, INTEL_PSFD, EIBRS, IPRED_CTRL, RRSBA_CTRL, RRSBA, BHI_CTRL], to_process [SSBD] > Traceback (most recent call last): > File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 594, in > sys.exit(main()) > ^^^^^^ > File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 588, in main > crunch_numbers(state) > File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 366, in crunch_numbers > (state.names[feat], repl(seen), repl(to_process))) > ^^^^^^^^^^^^^^^^ > File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in repl > return "[" + ", ".join((state.names[x] for x in l)) + "]" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in > return "[" + ", ".join((state.names[x] for x in l)) + "]" > ~~~~~~~~~~~^^^ > KeyError: 534 > make[2]: *** [/local/xen.git/xen/include/xen/lib/x86/Makefile:9: cpuid-autogen.h] Error 1 > > This is caused by commit ce8c930851a5 ("x86/cpu-policy: MSR_ARCH_CAPS feature > names") being rather lazy and marking dependenices on unknown features. > > Introduce a helper to pick the known features in a range, and use it for > ARCH_CAPS. > > Additionally, remove trailing whitepsace from the debug print. > > Reported-by: Jan Beulich > Fixes: ce8c930851a5 ("x86/cpu-policy: MSR_ARCH_CAPS feature names") > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 01 08:33:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 08:33:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104156.1455278 (Exim 4.92) (envelope-from ) id 1uszyr-0006rE-NH; Mon, 01 Sep 2025 08:33:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104156.1455278; Mon, 01 Sep 2025 08:33: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 1uszyr-0006r7-Ke; Mon, 01 Sep 2025 08:33:37 +0000 Received: by outflank-mailman (input) for mailman id 1104156; Mon, 01 Sep 2025 08: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 1uszyq-0006r1-0S for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 08:33:36 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5966b956-870e-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 10:33:34 +0200 (CEST) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-61e8fe26614so1753174a12.1 for ; Mon, 01 Sep 2025 01:33: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 4fb4d7f45d1cf-61cfc4bbca5sm6705038a12.31.2025.09.01.01.33.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 01: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: 5966b956-870e-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756715614; x=1757320414; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=iks5sK8Sh5KQ31mxOltV9v6WGyZAVIDFYE/aBLCLUlY=; b=Ac9kD6QO/TN3cLnw0TRsyaMkpjnPKY7pnOJ8reHGA4qFViqzoHax3/akoIMkK9SpM2 lMFX51Ga5APYadbb90seToebFbO4lV0YVQrdwr2qHC7oBYxZLTpnMQN8cWyVAckhDSdz tOLdFP+DFd+X8XB0JAGJYcf8GvtBO3lzyiKZq9TSvIRJDvz93Eo6mgHCxJ/IMaICB17Q jYKYhFvkyF5nDHShONv7CFcc9eHchCqvbGM3+nFruWHlVdimWlHEKS8LQcwLK7JXqPOJ l+jQUDWPqWLUTl7dTQDZRsRcT9ZXmWMyPzVF9ByNY/4RAb7Gr5NDkK/AzumFFTXfqlXS LKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756715614; x=1757320414; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iks5sK8Sh5KQ31mxOltV9v6WGyZAVIDFYE/aBLCLUlY=; b=G49dHx9uqnZ9lHg39OQKE1J179liEpFHrBhobmp0EWW3gcroAVHjjOKn3wRW1MDeyI JGNidZyD61f/OGhiakBTu01t26tLktqxwkuZe+1zVwRw+yhdIoFOElIStWeQrKo15rhu 9t6+RAImzhqeEyELj86Je67mLJJBvliQtQoPpjMHDDcaBIZ1nK6+E57adOJ5C26qBR1F RncT2XDGXNz4AtgfWPfV6Z8iEOxKmRzrxTOsQLo8FpgCT1pla8YgG0SdMW4/g1N6lYJn APrCDyCDIlZCgNR/74CMfNmgGJ3eg4FiDqH+QgXUiLdcQZV9ibzPierQMjqPy4vzm3AZ vpIw== X-Forwarded-Encrypted: i=1; AJvYcCUvu0xk2P2POwFW+Wq5FDzxMW9+bOIIlG0QMSTpFCh1IgDwRiE9MSQFZd7xA+vh++n4plqw4a0y8DM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx201O9aSRNd2zQ+5RI6ki+n/grFrzXaEiCluAWGr+nmDqkxkVu TyfbzQZvu5NoUiNv3aUFGtS/oZf+wxcL4qb0P55Em2oGGgEreuCLsCKv9JnUOszOEDNQm6erAeq TPX4= X-Gm-Gg: ASbGncvFa/tW1K3/gAHQ7eRb8FPn7sp52zHSsdWNOXQGnhYSWVvF5fQe2wwgU/7Xeil 0f9vhuazMBweDKMOVql9sg7WaIw9YwFqb464/QHrluYZ07j6KU2nk7MCpmB9lm8wDe9wktbSH/Z P087xUdB9awtQCQbnYOKeF2fNMTNqf9iG4C0rOr/aD7IXixREUhZIPHyIXv6NIcVxslJzK3l9q1 pImrDO2JYdlUFDY7rVDvaDbO9rfw0MhWZI9m7Mq8LcFuWnKZWXCD9msvdbEIUrsdkWgBQveRLJ5 eMz/Jm+bCrg894bouvrckJ5GFlpMPiXnwXx4mERPP1Y42RELSIqoDAb9/cj+2W19Ws5IhXqq4M8 pm1LKgeHVKi0NVcGtEfyc+1Vf1j1Ps+qESIHFFpQ/BPdcite3SzMWFeFWS277+R9kOUNR44tx/u j7kbFNDB7Sf+pNmO7bQtYHNXQpQaTb X-Google-Smtp-Source: AGHT+IGtRp0J/f83iu3DxWcmmrZZkXNCmkN0WTGCpW+/6ntjkB+PNLkJ3SBH4z5m3u6b3pRIgTXK/A== X-Received: by 2002:a17:906:c102:b0:b04:3e15:7289 with SMTP id a640c23a62f3a-b043e1579b0mr64572366b.33.1756715608328; Mon, 01 Sep 2025 01:33:28 -0700 (PDT) Message-ID: <7d1bf3ca-b7fd-4c42-a9af-157120828d6c@suse.com> Date: Mon, 1 Sep 2025 10:33:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/apic: Get rid of get_physical_broadcast() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250829161710.1056772-1-andrew.cooper3@citrix.com> <20250829161710.1056772-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: <20250829161710.1056772-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.08.2025 18:17, Andrew Cooper wrote: > This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of > get_physical_broadcast()") to Xen. Thomas Gleixner notes: > > There is no point for this function. The only case where this is used is > when there is no XAPIC available, which means the broadcast address is 0xF. > > In Linux, users of get_physical_broadcast() have already been hidden behind > CONFIG_X86_32 suggesting we can drop all of this, but that's a task for some > other time. > > In Xen as with Linux, setup_ioapic_ids_from_mpc() and io_apic_get_unique_id() > are only called in pre-xAPIC cases, so can use a broadcast ID of 0xf. The > only other user is __print_IO_APIC() for diagnostics, which can simply drop > the check. For setup_ioapic_ids_from_mpc() in Linux that's partly because it gained an Intel && !APIC_XAPIC() check which we don't have. Without that extra bit of data it's not quite obvious, as the check right now is solely "!acpi_ioapic". (Which iirc we said we would want to get rid of as well.) The non-Intel pre-xAPIC case is left somewhat unclear there, though. > No functional change. > > Link: https://lore.kernel.org/r/20240212154639.057209154@linutronix.de > Signed-off-by: Andrew Cooper Irrespective of the above: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 08:34:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 08:34:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104170.1455289 (Exim 4.92) (envelope-from ) id 1uszzY-0007OK-32; Mon, 01 Sep 2025 08:34:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104170.1455289; Mon, 01 Sep 2025 08:34: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 1uszzY-0007OB-0R; Mon, 01 Sep 2025 08:34:20 +0000 Received: by outflank-mailman (input) for mailman id 1104170; Mon, 01 Sep 2025 08:34: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 1uszzW-0006r1-64 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 08:34:18 +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 72cb20ca-870e-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 10:34:17 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b0225483ca0so273338266b.2 for ; Mon, 01 Sep 2025 01:34: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 a640c23a62f3a-b04252103f2sm237629466b.50.2025.09.01.01.34.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 01:34: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: 72cb20ca-870e-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756715657; x=1757320457; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Bzs3DliRmIjLErCH2j6BVqbwr8WkQ89CfiGMPQYpA5Q=; b=cXn+m5DUGYTN7NY6BWIMkOXmCHgD+bVNn1NUQRgwtE52Qxu+IuHF7PEVE+fn4aRbXs r/Ab/QcZpJGwH/wWS0LVuagOdibxHi6qQl/bw+vpxztZYOjVIufXkViowwowMuGsDXzb jdMu2yy94d6Hej29ioHeK7eFyEzUT8svVsnPcqR97tj0wkP/FuCAQU3o52y3O7bjmAWu pnp2oFlKa+NzCjpmXJEmVEszW6EEC+J5Oik2UuWZkPNYtThFljEtit5wBFducy/zB/4N gHOde9k8Gy7mzyvGoXVtKJRgqsE8UaWyT2hW+aDzDCDCXIVOB6CML/rKrbVES996tBAk 4nFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756715657; x=1757320457; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Bzs3DliRmIjLErCH2j6BVqbwr8WkQ89CfiGMPQYpA5Q=; b=LqYzeoLX9uuGntyQTWlVIgWngkmZLHCOccgyCWQmWY/BkX7wm/o3dKfB3NxvzMLCBx 4t5etvBMT2XJL/tOcT5akG1N02qDR/i/jPBkYICyJF0x+vibrsmuoZbNJtrVEBq54oy4 zviodWe+hy5IdPdkQJxG06mPpewu7byJC1VRsT+tr+POIaDQHp2yehUnieV1zQKJINcS nfPWIVJrIfQnE8kClUXwGCCGJmN2UG4yrN3ZJV/0bo+Y9pC9jRV6m1Bcj5NwE/LE1u+K xL3mKzkVZFAMZ4za0HAru+DoW10kIYYsjF2DdnB5RmZJnZ7OdIlrd4jkq4swqJvT+LSc m6xg== X-Forwarded-Encrypted: i=1; AJvYcCWz7HfRsUIFDCBiv1aaLlW+cgDkSN/F3pa76QvP+98CqPd+dcMkgwnXlLZA7+6oSaDCdrkh86CMbpg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yycy9kcM5DqtI9FQXDpTQwp+Jkm316fYiILRNgJrdheHOUAD7q+ KkS0kmI5fPXnrAko7Y0m99vcl7Grdzt1HOa6ybHrQsy6Wz0Ar5lXwtdIY5TEmi/0qkJQoUikbSv 4G0A= X-Gm-Gg: ASbGncshjCGrGwkl6eD+xwM+yV665/EsmEEsSypKzDtxm/ubgA/iJ5j0yWBnjWoYbjx CFnrUNssPRVIGgBHi5KsobaEEoX5U4RHMLBh9VKuCoOrWxcVsi2HU3QFIjWY75Umq8gT0T2QGL5 7vuikDRLOWbPE8RlZWxvBXtqAnuvIEe7D18Gr+EyL45qZOQeFoeImg/cJ3QEujQeboObDeJIA4x ohXymwWQ9nfku3GRUBe7sDK2JMjBH2mkKF9wsGtDck8/lMaN5qMAs7NaHIi+yZVUJ5PqHSavaw7 m3R2Ue35KkUVvPbvjJdfNAO3KjH/OrgqhPNw7wa3D63DDwnUIsl15nlkJ++toRGZ4uDAyCOO6iA f4jCESu/aqWYR9dwotEHGaGTzm9sIKAlHZIk56MAfK4nWtDo5FyPjBWgX4IC/pmYM+lbhG0iO0y vwhNOv+pk= X-Google-Smtp-Source: AGHT+IFiCDQ8wy24nd+Fc3RoVP5bZKib55cVbT9gGqmzQHeF/yT9Stk8YoT81s9/oGDNxtXXmpkl2A== X-Received: by 2002:a17:906:2819:b0:b04:27de:12ec with SMTP id a640c23a62f3a-b0427de140emr288313266b.4.1756715656853; Mon, 01 Sep 2025 01:34:16 -0700 (PDT) Message-ID: <8dcb1c27-d638-4334-a4d1-943d1a5d0d64@suse.com> Date: Mon, 1 Sep 2025 10:34:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/apic: Drop sync_Arb_IDs() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250829161710.1056772-1-andrew.cooper3@citrix.com> <20250829161710.1056772-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: <20250829161710.1056772-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.08.2025 18:17, Andrew Cooper wrote: > It is not obvious at first glance, but this is dead logic. > > On Intel, xAPIC (which is what modern_apic() is really checking for) predates > 64bit support, while the Family 0xf check on AMD is the K8 processor. > > Simply drop the logic, rather than trying to adjust vendor/family logic. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 01 08:57:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 08:57:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104184.1455300 (Exim 4.92) (envelope-from ) id 1ut0LR-0001wi-Sz; Mon, 01 Sep 2025 08:56:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104184.1455300; Mon, 01 Sep 2025 08:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut0LR-0001wb-PC; Mon, 01 Sep 2025 08:56:57 +0000 Received: by outflank-mailman (input) for mailman id 1104184; Mon, 01 Sep 2025 08:56: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 1ut0LQ-0001wV-AC for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 08:56:56 +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 9b78469e-8711-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 10:56:54 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b0411b83aafso210699166b.1 for ; Mon, 01 Sep 2025 01:56: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 a640c23a62f3a-aff15fccad1sm627989566b.108.2025.09.01.01.56.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 01:56: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: 9b78469e-8711-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756717014; x=1757321814; 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=N9SDNFNNmkHRjQNNVUzXHvawpqEnyUdSDygomNw7bmY=; b=P17YsNH7GpMASb/7eVWFtwFwPG68w9Lwgii9WbnISW48lftAK0r0o88w8IXSjhk/PJ gfBfU+a3FnuGGXPVqf4KZgQLlsZOvUlSeQ7IiWlRF+o+eATWTb3yAzFT9YU0ZyZmpBmL gNVJS8Gsp8IWEe3P4mKZG1Ya4qL9tCtGZoxSYW7CSouXHP5CSWisfP8HaSnF1ultP9N0 eYpVxh4mfKln8CNrAU2AHlLpDZ+58MCoKmMgyLfnciumNt0nbeP3APWHHY30HoLF0dR1 ZnPov1xz3nSqYU9m21HiwqA3ryEogdHmpaks0hR47gF+oiTk5tHByWqn8nm+kBeAoHAP bB2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756717014; x=1757321814; 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=N9SDNFNNmkHRjQNNVUzXHvawpqEnyUdSDygomNw7bmY=; b=p7sYQQ+HCv0G/G+8Ls4jkGsV2yubWnwJgP6T0dn+jxqY5t4yx+NC94kUU/zXf1zSvQ 4jcd/tBgJlezCSycoOl6KhDyQUitNmE5hON4ME27pHKPK9ybC6WAb0sB5JSiG4mEn5lY 4XFZjKaLzbj3UZ4H4ydWo9epQWprkPckvbpFcgD00oA85X8d9YBw/liztOrTcM9yAyIr nrk75ktvYCAB4lAiprfCJc895aiXIZ/uBt6PWJv0CinB8RVuoocXLSGnU7L10HpS2Ske vXuEMbrL4z7CPlEVix+fC5zXnDhd8jXkIYZyrRmBsT/299fwQewd14dvseuzUV+Oqhkz RwYA== X-Gm-Message-State: AOJu0Yzn0CYHcy409rAuKF11K0dazAid8Xgi0GRVDX/WHXKWqS6XWAyE XlziuUkW1+Zb56R1fKvQN4xZFTKOZjg1fgsqsAT+FKSAKXq9eDMcpsc6X9bbcLlLtmQSQSms9Ev 7zqM= X-Gm-Gg: ASbGncvaUBlihGAkc9TzXxBas2Ah0rftG2Rb0Ydzr/tptwZoxF4Oy9DHZ4e1JgwUA71 RlD+ewgsQujMwfjVgP/UbKzJL1col6Fyl3oI++J4e92ppOukZPUVx+gshu8acUgCgI2/PXqvaRt qCWyRHsg0+d/hFMVIRAh1dnCTVUwHvOXo9y3G5EYPAP0r2N+2aJMVkURnsIKpzotvdMslNR/tzE KQ30+/IztMeXRAMz7VMem+rQ7e1sr8NW3mPN+B5KvuGCw37qCQ5m/PguqRHtozfwt8uvOBQgRyv yTAOsuyQ9oT1qUDgoCDhnMsh7Vg48/4ECcC8yYhcnVu+DUHuAldvbSV5NwaiqeCz6Ei22BgzocF z5XrNCmVE9p1v17fSgiPQaAPMnXuF5gw9YRl5yhj80syQygArustZwsfZHMY0QwGnjtfR0gsoE/ 0pYUC1x10= X-Google-Smtp-Source: AGHT+IHx+eZb5Ns66uHXiuh9bYCarqdoK0NWtQ7X43CRFoR3TLSpYHoaWMFt6J6DWm6fxy+6Ghu8mw== X-Received: by 2002:a17:907:720f:b0:afe:c1e4:5561 with SMTP id a640c23a62f3a-b01d8c802bcmr716634066b.25.1756717013650; Mon, 01 Sep 2025 01:56:53 -0700 (PDT) Message-ID: <41ba214a-6137-4d8f-9f4f-3a362940d8a8@suse.com> Date: Mon, 1 Sep 2025 10:56:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v2] x86/gen-cpuid: correct cycle detection 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 With the processing done linearly (rather than recursively), checking whether any of the features was previously seen is wrong: That would e.g. trigger for this simple set of dependencies X: [A, B] A: [C] B: [C] (observed in reality when making AMX-AVX512 dependent upon both AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list of dependents). But checking the whole accumulated set also isn't necessary - just checking the feature we're processing dependents of is sufficient. We may detect a cycle later that way, but we still will detect it. What we need to avoid is adding a feature again when we've already seen it. As a result, seeding "seen[]" with "feat" isn't necessary anymore. Fixes: fe4408d180f4 ("xen/x86: Generate deep dependencies of features") Signed-off-by: Jan Beulich --- Doing AMX-AVX512's dependencies like mentioned above still isn't quite right; we really need AVX512F || AVX10, which can't be expressed right now. I'm now handling this by some custom code in the AVX10 series. This contextually collides with patch 2 of "x86/cpu-policy: minor adjustments", posted almost 2 years ago and still pending (afair) any kind of feedback. --- v2: Adjust an error message. Reduce diff / indentation some. --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -366,7 +366,7 @@ def crunch_numbers(state): for feat in deep_features: - seen = [feat] + seen = [] to_process = list(deps[feat]) while len(to_process): @@ -379,14 +379,17 @@ def crunch_numbers(state): f = to_process.pop(0) + if f == feat: + raise Fail("ERROR: Cycle found when processing %s" % \ + (state.names[f], )) + if f in seen: - raise Fail("ERROR: Cycle found with %s when processing %s" - % (state.names[f], state.names[feat])) + continue seen.append(f) to_process = list(set(to_process + deps.get(f, []))) - state.deep_deps[feat] = seen[1:] + state.deep_deps[feat] = seen state.deep_features = deps.keys() state.nr_deep_deps = len(state.deep_deps.keys()) From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:00:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:00:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104196.1455309 (Exim 4.92) (envelope-from ) id 1ut0Om-0003Rf-9n; Mon, 01 Sep 2025 09:00:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104196.1455309; Mon, 01 Sep 2025 09: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 1ut0Om-0003RY-6V; Mon, 01 Sep 2025 09:00:24 +0000 Received: by outflank-mailman (input) for mailman id 1104196; Mon, 01 Sep 2025 09:00: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 1ut0Ok-0003RS-Ux for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:00:22 +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 168aa82d-8712-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 11:00:20 +0200 (CEST) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b03fa5c5a89so211439866b.2 for ; Mon, 01 Sep 2025 02: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 a640c23a62f3a-b042fcae813sm157722266b.40.2025.09.01.02.00.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02: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: 168aa82d-8712-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756717220; x=1757322020; 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=q2J8zmsIOb81RGVTk4ElRHWcQuRIoi5c75HY0w93Vhc=; b=S0oxBwSiQ43I3YvG35RXPCGmE94TOFip3nTPYy2bkRJE39lnh4E8EItPh4GiS7az2Y u0KgCPV/mVmxCeu/DIQ7N8wyg2aJSKnvoK8Xl4uuKRUpBzKIldTfey50FNeyMddU+gdF RQs7ex/yEraB2gc7Fo16zh7WZx/tdG8rCcRuNe+dwDllNr3vLQfBId5t5GApd04OsdV7 m5ARpaqXqB4OVLXlKPwxLuo4gHMzp/40L58nqhmJ8V9KuKouwdF+KJmI8gqsFkfoDmU4 t3zlyMspEnTPeug+Jei3jjiZaG8VRkWf7qYNOHb8s2yQdRPguRgAmF7j+WSbC37cKAxY 39wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756717220; x=1757322020; 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=q2J8zmsIOb81RGVTk4ElRHWcQuRIoi5c75HY0w93Vhc=; b=EeJGbAnHrQ8K/aji0SZaftMlUDOWGlShp3NI9vqBv49qPCNGtpqS175vPa4Rj3fSJR WQUbmRACVFozgjgQhT3vFEhVGIuhNwTNUujOehblNy8OY2EeLrXmhEmWSAP7JyMtoYU4 voUxkNakJi42O2DMcw4y3Wd4z1EREMH1w6UlZ5m+h8HxnM7AEsexTxSXcyyiKZ9p3lfj cAXM/gbb5PbcSnYmXGUOQs+KE16kbkoHvHBhdqnb7l6EbStE3BxnjJEt0YgdZGQuRq/q FX75risWQAdZvBi4lawcegHElAdM1YMMep04UbBfAhTYnuoTpvjkf2hNAI47TA4Y61AY X6iQ== X-Gm-Message-State: AOJu0YzRn33WGjY3OiOiiaOy6V7HEcZQRM5i0chIFCUpuwNcgsp8yEoS p0P4guFhk7gbKIuMGRKpLCsuqHsu31ZQ8Ry0Y0g7JoFBkp14z7DMcndrP7dheaSaDEv9DxtYXep Oa/A= X-Gm-Gg: ASbGnctjSnDpEpISlxdgIjNelZFiD3KSvB0ODPTlloM66EFic6uX4xwnkLLePDQj+EH dYLsIG2tmlXFHSzgsk9mzyA8iZ+OiEVWUGEJyX+lUow8xgMcfgBfTGYpEhtZwi4PTPT4H+/PUdq 0I0peILtutyrXqghJNOh20zxCM/GJQkOJcwMmRXMTH+LUnGD/PnlHZx3hrEm+xhL9rjaazryUFo Qc62FJ7/+FCYZY+EUNrUwOx7HF9SqnQtk0JMzuV41rFbtQ9Tme6ZDXdwRXX3AX8btfGwg1dFIlk qJS7B7hbCAotPXCUBDB88gz1qhMYcGzIhYKLqDXJl6Xktjts7gxVEc4G8wvYGUfBBs9XD0NQn58 wq6Jqkz60wUV8OCpMbph5KHFZs0zGpHs4dyXVbiL29wUElzERz2DseWu7zdB4WW7XZsbMmeCbem /mvVOCgy4= X-Google-Smtp-Source: AGHT+IG1ObEOlVvLkfSbZfcw3G1Qcs2onSpzkaIW2ICoZ9H2F1fRpjVflyzR4WV7wehg/U0HV70KFg== X-Received: by 2002:a17:906:f59d:b0:afe:ae99:9d23 with SMTP id a640c23a62f3a-b01ec52d58dmr642708066b.61.1756717219977; Mon, 01 Sep 2025 02:00:19 -0700 (PDT) Message-ID: <92b2d76e-2434-4606-94b6-93774a74fc87@suse.com> Date: Mon, 1 Sep 2025 11:00:19 +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] docs/sending-patches: document "Amends:" tag Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 On rare occasions Fixes: isn't quite appropriate to use, yet another commit still wants making a connection to in a formalized way. Such could e.g. happen if a pretty obvious optimization was left out (which isn't a bug, but still a shortcoming). Formalize Amends: as a tage to use in such a situation. Requested-by: Roger Pau Monné Signed-off-by: Jan Beulich --- a/docs/process/sending-patches.pandoc +++ b/docs/process/sending-patches.pandoc @@ -42,7 +42,7 @@ should be mentioned. When referencing other patches (e.g. `similar to patch xy ...`) those patches should be referenced via their commit id (at least 12 digits) -and the patch subject, if the very same patch isn't referenced by the +and the patch subject, if the very same patch isn't referenced by e.g. a `Fixes:` tag, too: Similar to commit 67d01cdb5518 ("x86: infrastructure to allow converting @@ -106,6 +106,12 @@ If git was configured as explained earli ``git log --pretty=fixes`` otherwise ``git log --abbrev=12 --oneline`` will give the proper tag and commit-id. +### Amends: + +If your patch doesn't quite fix a bug, but still amends a specific commit, +e.g. because an omission was found, please consider using an `Amends:` tag. +See the `Fixes:` tag description above for how to use it. + ### Resolves: If your patch addresses an issue logged in a GitLab ticket, use the `Resolves:` From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:22:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:22:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104219.1455318 (Exim 4.92) (envelope-from ) id 1ut0jb-0006Lf-UJ; Mon, 01 Sep 2025 09:21:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104219.1455318; Mon, 01 Sep 2025 09:21:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut0jb-0006LY-Rc; Mon, 01 Sep 2025 09:21:55 +0000 Received: by outflank-mailman (input) for mailman id 1104219; Mon, 01 Sep 2025 09:21:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut0ja-0006LS-NX for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:21:54 +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 188de9ab-8715-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 11:21:52 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by DU0PR03MB9228.eurprd03.prod.outlook.com (2603:10a6:10:474::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.25; Mon, 1 Sep 2025 09:21: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%6]) with mapi id 15.20.9052.014; Mon, 1 Sep 2025 09:21: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: 188de9ab-8715-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sH+8k5I+370VHsvNBoYtJehtkExQJPWhwAdBXlvpxfFv2JaCLX3i8CKkSGjPDFhfkhLYBkD/5k7OtU8F2HHBaq4Masag1tCDCADWiRC1ZJxBNm9W2HBDsDv/MlmBlQ+dKdXp05/cnqU70TxACgb+9IApgGbKivrTPd4V59EfnCzgQR/KfxKCNvYl839ayvEkHwx03wb6g7zcxrF9jFXFwUoyFU4APID0H+juHVwUBfqsHLNUA5GlV/FbrhDze/G7ECn9GfVwVS/G4KFITsyvl3gobZ/L/MmBd4VqRcpDQx8RrMskrCaNUlFVBHwhslhyBzusBDS91+zgVyTxhbiL+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M81vvacvluQ0coWkon1ZgmP0Z4MEETESMymFI/cSbm4=; b=aw525kBEw4PqdY0CqESOo7Zf7qJeVm9c+BsXhN3OWV5T0F7U552qT17+9Hqrt2UDADsmUcG1gwHqaJk8jehkNi0nG+3Ss2gfasZYRQbDWJCSHoH5fRmKfTL/2fda9BXL3f+3Kwp776pc1riapcKPoVHJAPq8zWJi6OoPdM0JaZItErRnV2KGN2Latdg3xULNq+2NfBx8fczYQBeeZP2XnsNGpZ5eDdVp6V5+B2U+FVARHUIYV30ulP3MuhlQWuMPSgbcGZChWv/B39PIStgdUKuEMEReoRYhNhg3rVwmnOEdoH34QvNMEjUzxYgc40IdmUN1QQiMa26/Z4L387mxXg== 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=M81vvacvluQ0coWkon1ZgmP0Z4MEETESMymFI/cSbm4=; b=K2+tFfP/AWyD1dwHWzUAooBmPYBurNGseNqFI19VkkYPplFk0Mbk0IfK2edcy5usxpx9HK7F9pG5FeK/UCgRv/Rmpgf77ZhZ9V3jay2hZHCUrz2CTItEPREVJeOcm1MULyXvW0mojLSM9U/WOOsXUFe/9Y9Lorsi9jBNgOsDZn+jK4AvKPngzEDG1BUziop5rPLRezU5zdi9V+SAkdZ65LVp6ByiZvNiaAJkl5ev1svJLqY3O8WgccMsArvqUBd5uwECvPSQX6dlhCF2TcyNt1XU2LvTNWCJc6Y4cEHnm6So1I66hwsxD4FiH9b0kfAU4sWYaydYXwurv30NEg62pg== From: Oleksii Moisieiev To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v6 2/4] xen/arm: scmi-smc: update to be used under sci subsystem Thread-Topic: [PATCH v6 2/4] xen/arm: scmi-smc: update to be used under sci subsystem Thread-Index: AQHcGDp0dNGz8RLSIkyOshrRMf8UObR5tdYAgARdXwA= Date: Mon, 1 Sep 2025 09:21:46 +0000 Message-ID: References: <8e7e9dcdd643b6681a6127d56b68536b987141af.1756399156.git.oleksii_moisieiev@epam.com> <4eb6782d-2b5c-47e9-a81b-8bbeb17b83e6@gmail.com> In-Reply-To: <4eb6782d-2b5c-47e9-a81b-8bbeb17b83e6@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_|DU0PR03MB9228:EE_ x-ms-office365-filtering-correlation-id: e598969d-fdb7-42a6-8068-08dde938f994 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7416014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?WjE5b1IvR1FLM3ZTd2RRcTdjaXdNTysxRmorMk8vK01VZi8zQTNKcGNkMytw?= =?utf-8?B?TWtOaEpReHo1RGdpYms0YXJZcTBubDJtbERIeDQ2a3FxOGIwanJqdERyYXFq?= =?utf-8?B?dSs3dkhpajcwcEFvV1dUOTBkYUZCSGI1OGR0YmwrS1FveFZvT2RLcDcwRG83?= =?utf-8?B?MFpIci8vSFNhODZNN2ZRc2hXS1dOam9SSHZHUVJySVVsU09RRkdpUTdaVURK?= =?utf-8?B?VjBZOUxOTTlwNDR5N21oRHIxL004NDJnbFJHN2ljbUF3TjkxRERBNHNYZzgz?= =?utf-8?B?Q3JpamR1RVB0WGwzaWc2aVVIZzVxanZndVdkTm9EcE8rRlJ0eGo2RjJtV3JY?= =?utf-8?B?bkxzT05peUFhNEFOWStLSEFrMEZnNUx6UkFia2pGNGlLQVEveHl5ZVFnazlq?= =?utf-8?B?Q00zWlhtN0puU2pOZUJWdHFvOVZjdXRZMmd0WWNoYlliTGdsZ1NicmN2bTVl?= =?utf-8?B?U1AzR0pIc0ZTUnh3MHp5UHFLVm9pREh1Yk9XVG55UkNIQk9xcVN4aVprVVNP?= =?utf-8?B?UmNsRlpQc3NXdjJ0TERzNC9qd0RaVm1CbkxnWlFJcklYVjFXNnYwU0pWc011?= =?utf-8?B?QlJZb1JHeE13c1kvcVUvYnQ0UkQ5TDVLU3k4NTh4UldzVGE3QStRcEVRS2hz?= =?utf-8?B?ZmdTV3F1Tmw0bGJVNW1IWWxvQW50QUpESHFkZ2dSWnRJYkRBNE9XdlVqUzd2?= =?utf-8?B?RmFWRDFVR0plekM0VHFHYlM4ZlhONVNYdTBwL2l3cnkxbE81Sm56TFhhMldu?= =?utf-8?B?Qnd3aG15WDcrYkhUQ0krWTRJU2dsWDY1SmxYN1BhY2ErSWg5aUhlSnoyUEpi?= =?utf-8?B?VDZIWUxVTVdTUkdrVi9jem5LcHltODJ5citNNEZjTFdOc05aKytCNUgrdTJO?= =?utf-8?B?bjlQQm9VSkNyUWg5aUxtT3hLbFdCQndOL21lN0wxNm9qVlNhZTg3TGpGQTlS?= =?utf-8?B?RkdvNlRrRWVxTk4vSVBoK25pZVhpOHByYmZsYlNMWi83aDlLeXR4ejU3dWc5?= =?utf-8?B?elFHRHNQbktZL29rR09jSzJqWjdWY1JpdDE5bXFMVEVnVll4N1Vqd0luVUda?= =?utf-8?B?bSs5YUpiY3daRHVoME14TzBVcVpITU4ydEFKZTdCMDFlUlRYMUo0bFVLVzIy?= =?utf-8?B?NTZWT3Y1cFdiaEFCUnM4cTF6TUJ0bXNGSlJYZG9rcXVSTU5vTWsxdDJGd2w3?= =?utf-8?B?MFV1cUhTekNWTFZ3RTJEQTdJcmhEekJ5bTU5cW5Tcld2Q2dPeDZZVnVXbFBk?= =?utf-8?B?bWgvdVJNNElaRW5DTkUrRXAyem1xRnFvc2w1bTdpOGtpWUVGMWlTbGF6enli?= =?utf-8?B?Ulp2b2VWQnc0dS9GZHgwc1VrbWh4M2RrcTRPSmc4UVhENS9wS1hEN3RWb05l?= =?utf-8?B?NXovZDdkUldwSm1DQjFCNGZvS0RpbVFxZHltK0NkS1NKWVM2VklMV0FUcTQ5?= =?utf-8?B?UU1QRStlQ3lpdWtQRzc3cGdlVnpFZnhkc1FpaEROT0Zidmcwd3Q3TzZ1QUxQ?= =?utf-8?B?THZCOVpESlRwWEtzREJ6dzVQcnNCcUFHcmdRVDBjN2hkS1hqQkVQdzBsQVJL?= =?utf-8?B?SWx0RUtPbFpObjJ3RFVPRk5iMkpPQkJQakEwT2plM1RDYnFva3NuL1l3QnBn?= =?utf-8?B?SGpWc0hPMEhmSURRRjBOOEx2Tk9HODJ3Q2oxMVNMNXRoejFFU0R3OFNYRUtJ?= =?utf-8?B?WGhiSFcwKzAwZWUyTS96MUxDR2daY0dNWUp1L0FUSGViQXdGZDJRMm9zQW0w?= =?utf-8?B?Z2haODlOQkNXT21OTlZ4aTdGVW1PN3hTTm5Xcmc4ejJzOHJQc2tXY04rVFRx?= =?utf-8?B?dDlyZ01nWFMzalNuS05HOEx4UmQ3cis0V3dmNU8zZG9BbFFkZXZEK0d2MllN?= =?utf-8?B?eXZCd21ud251ZS83UmhMb3RiUGRrbXNteVZ0ZSs3U0NSSW5TejZsRHlkT2FU?= =?utf-8?B?cWt5UW40UlBJTkEwdTNhc21hWElIYnNjdHRQOUFyU2V6VjBXMzh6UTBsU0lF?= =?utf-8?Q?iM6NaS2A2QzGMPFvOe5YdDtaqHERQs=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)(1800799024)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UWwwSmtOTytxSzM3QjZqaXg2WlhoVXF5eGpTUjBNNGhWK3QvbGxFZFdrd2ZH?= =?utf-8?B?R29WYzRGSVlnM1BkYzBkUUZMQWVKbjI4RCthWmdwcDJQam84UU95aEJNZDB3?= =?utf-8?B?a3lISUlwbUxoR0dwUDlDSHJ2clJrNFhGWHRKN0ZZVW9Yb1lhTDFiRUQraGJD?= =?utf-8?B?bklPc1ZEcWxIOG5aK3RHeVlWT01KVnR5V0NYL3hUNFRMUXp4TVIrencvVEMx?= =?utf-8?B?MzkvN1R6M1o3VXUxemJrL0YyMWVJdE8xWXEvRzJzTTFCcDhUN0NmQ0tTbmcx?= =?utf-8?B?b2h2VGQvbzZWcDdGNm4wZTNncVhJemduSFlDRi9MRFl4V1lXeEhXWk5nVlFN?= =?utf-8?B?S0lHN1FWeXk3MGVQWWJTc2VlYW1vY2VaaTk0VzhubDJVS210MDBLVEJTMTYv?= =?utf-8?B?MWVCMjhSRkNtdUl4c2VRS05Rdjg4emhCUXlsamJqRTRNR0E2UWVnbXRjb1lV?= =?utf-8?B?MjV1RmNMR05raUJ6VmhvRjJLaGdqaloydFZueFZEVWU5V2JlYktRRVV6ejBm?= =?utf-8?B?VkVuQkkrS1dVcnp6OW14L01YYjNEd2ZUQUJ3Sm9Mb2VDYm5yQi8zdlVrQ0x1?= =?utf-8?B?L0h1eXhYRjBQbWp3V2pQSFpBcGQxS2R3aEJaUmNGTUtiRjhtY1dZaXBleWJr?= =?utf-8?B?Q2M0bU1XSFdJTG9HZXV4R3pYaXBBdkxubXB4aldTUjE2a1IvbWgwZTFNUVU4?= =?utf-8?B?Z0dPQXNxMkc4WEZqMnlZRmlrcE94MmN3V1g1RjdaaHRLcmNVT2pjVUg4VmFh?= =?utf-8?B?QUd0T01ycVRWR2FSMWoxZXFrNzhvNmdtdmxaU2l1NjlJMnVQZWdpeFhqTVZZ?= =?utf-8?B?enRSbHBwc1ZwbExDRENKUkIwMTJwOHd2S21MMXgyb1lDSjZhVTFZT2pWeFhZ?= =?utf-8?B?YTIyc0xucGdqbC9ycUFCQ0UrT3Y5ek1Dc3RYZk1xb3c3RE5XdmNGVEpFbHJ2?= =?utf-8?B?RnB0S251aTlPczlhc3hjZG1XNHEwelh5MlA1d2g4UE9LYm9nSTBpbDJvdTJp?= =?utf-8?B?UUh5aXNVakJJVFRrNHhIWm52RSt1TnhmaVRERzRIQ0RQc095YlNlY2hpeXNh?= =?utf-8?B?Vy84UEdSSGxzaldKMjg2b09md0tUOG9HT0czV0ZPYThCbkFkaWZIcjFmeXFB?= =?utf-8?B?M2Jib216cVZ4cXNnd1VWMHZzTnZyMHIvTTJpazNtZkM0RnZrd2FDM09VVEFh?= =?utf-8?B?MlhjU21MYlR4dzVWS3lBaEZLektBNk5IM0dGVGhIN2JUUWllaUd3ZGVZMm5n?= =?utf-8?B?dUU2MmF0M0pKMmQwdHE2WnBmUjVRRFNpQWUxQUppTzBCdmJjeVJhMVpMbVZl?= =?utf-8?B?WEJDMzNyckZGVDdObGNLS25CMTZacityVitOdEN2bi85OGRMaDZZNDNhT3pQ?= =?utf-8?B?Sk94SCtQdTRCdDZmMzV4K3NzOGtCcXhmcTRQbFFnMk9yZDFOMWRvb0JqWU13?= =?utf-8?B?WXIrWGVpNTVHZnlmODJVRHB0WlI5cm1LeEhpTy9LYXc4eVBteE5ja3pqVDgx?= =?utf-8?B?SE5UV0NMWXAxRHJQSUVFSW5DdUp2SThJZ3VaQnNVS3hqTWcxcEVnRmZGd0hT?= =?utf-8?B?N3pEbDJTUjVMdXB3OWxDZHQvcGVpUnBpYUhmL1BoRGlLWUY2eXVLRjBCOERp?= =?utf-8?B?QjU0TE1FQjBVbDgzU1JKRGRsSWtMajNnSFU2dVhkMXpKOUNLK0RKbzBQRlFW?= =?utf-8?B?MjJKSndRYWdZSG9BY000ZkJtYmMzcXpxb0FZajdDWGlyNVhjUW11a1Y0VVEw?= =?utf-8?B?MkZJTGJwM3NBQlozeFBqT2ZrMXpBSzNYOWJ1WVkxZ28xVm44ZkxVajllRktX?= =?utf-8?B?K2NGZGI5dVMyaW11ajkyb241RU5OWnMxeG90NGQ2amhENy93b0k5K0RoazVs?= =?utf-8?B?ZTMra1ozdkovTktJdW05QnZPTitoaW9LWHgwTUVhdm51clA0aENYOFdWT3ZY?= =?utf-8?B?MEIvQ2tXVnVOZDYvcm9jSWdNOCt6NW5XckZtYjhJVGE3eEY0SDFLM0docGRu?= =?utf-8?B?dVB5WnNiQS9VdlAwVDJWVVA3a3F3dXdWNlpRYkdKdEJnQ0lOWkt4bURKTksy?= =?utf-8?B?T3c2M1ErWU9DZCtZWWtNbzhsdGhhYjJQUldjd0ZaOTl4NVVRNmt4cnZRVmJz?= =?utf-8?B?cVB5TEhEeDlOdzl0WkZCdWtIcWdzVGp6QjJtK01wUU54VWNQc01oLzZFL2xy?= =?utf-8?B?Y2c9PQ==?= Content-Type: text/plain; charset="utf-8" Content-ID: <66AB92F9037E3E46A888E711FC9D92FE@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: e598969d-fdb7-42a6-8068-08dde938f994 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 09:21:47.0340 (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: JpM/1tSnpmAEbQUg6Rm/MMf1q+B9BeqwHiprCW8hL8U3L/FcUiOKhRHQTP3Vuj7GLyvy0O7nyIIJ9SmKBeqte1jM3By+PniTyiIL/QkGyns= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9228 DQoNCk9uIDI5LzA4LzIwMjUgMTc6NDIsIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdyb3RlOg0KPg0K Pg0KPiBPbiAyOC4wOC4yNSAxOTo0MCwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+DQo+DQo+ IEhlbGxvIE9sZWtzaWkNCj4NCj4gdGhlIHBhdGNoIGxndG0sIGp1c3Qgc29tZSBjb21tZW50cw0K Pg0KPj4gRnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29t Pg0KPj4NCj4+IFRoZSBpbnRyb2R1Y2VkIFNDSSAoU3lzdGVtIENvbnRyb2wgSW50ZXJmYWNlKSBz dWJzeXN0ZW0gcHJvdmlkZXMgdW5pZmllZA0KPj4gaW50ZXJmYWNlIHRvIGludGVncmF0ZSBpbiBY ZW4gU0NJIGRyaXZlcnMgd2hpY2ggYWRkcyBzdXBwb3J0IGZvciBBUk0NCj4+IGZpcm13YXJlIChF TDMsIFNDUCkgYmFzZWQgc29mdHdhcmUgaW50ZXJmYWNlcyAobGlrZSBTQ01JKSB0aGF0IGFyZSAN Cj4+IHVzZWQgaW4NCj4+IHN5c3RlbSBtYW5hZ2VtZW50LiBUaGUgU0NJIHN1YnN5c3RlbSBhbGxv d3MgdG8gYWRkIGRyaXZlcnMgZm9yIA0KPj4gZGlmZmVyZW50IEZXDQo+PiBpbnRlcmZhY2VzIG9y IGhhdmUgZGlmZmVyZW50IGRyaXZlcnMgZm9yIHRoZSBzYW1lIEZXIGludGVyZmFjZSAoZm9yIA0K Pj4gZXhhbXBsZSwNCj4+IFNDTUkgd2l0aCBkaWZmZXJlbnQgdHJhbnNwb3J0cykuDQo+Pg0KPj4g VGhpcyBwYXRjaCB1cGRhdGVzIFNDTUkgb3ZlciBTTUMgY2FsbHMgaGFuZGxpbmcgbGF5ZXIsIGlu dHJvZHVjZWQgYnkNCj4+IGNvbW1pdCAzZTMyMmJlZjhiYzAgKCJ4ZW4vYXJtOiBmaXJtd2FyZTog QWRkIFNDTUkgb3ZlciBTTUMgY2FsbHMgDQo+PiBoYW5kbGluZw0KPj4gbGF5ZXIiKSwgdG8gYmUg U0NJIGRyaXZlcjoNCj4+IC0gY29udmVydCB0byBEVCBkZXZpY2U7DQo+PiAtIGNvbnZlcnQgdG8g U0NJIFhlbiBpbnRlcmZhY2UuDQo+Pg0KPj4gVGhlcmUgYXJlIG5vIGZ1bmN0aW9uYWwgY2hhbmdl cyBpbiBnZW5lcmFsLCB0aGUgZHJpdmVyIGlzIGp1c3QgYWRvcHRlZA0KPj4gdG8gdGhlIFNDSSBp bnRlcmZhY2UuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdv cmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KPj4gUmV2aWV3ZWQtYnk6IFN0ZWZhbm8gU3RhYmVsbGlu aSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4NCj4+IC0tLQ0KPj4NCj4+IENoYW5nZXMgaW4gdjY6 DQo+PiAtIGFkZCBSLWIgdGFnDQo+Pg0KPj4gwqAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25m aWfCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCAxMyArKy0NCj4+IMKgIHhlbi9hcmNo L2FybS9maXJtd2FyZS9zY21pLXNtYy5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgOTMgKysr KysrKysrKystLS0tLS0tLS0NCj4+IMKgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2Fy ZS9zY21pLXNtYy5oIHwgNDEgLS0tLS0tLS0tDQo+PiDCoCB4ZW4vYXJjaC9hcm0vdnNtYy5jwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDUgKy0N Cj4+IMKgIHhlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5owqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHzCoCAxICsNCj4+IMKgIDUgZmlsZXMgY2hhbmdlZCwgNjQgaW5zZXJ0aW9ucygr KSwgODkgZGVsZXRpb25zKC0pDQo+PiDCoCBkZWxldGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJt L2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjbWktc21jLmgNCj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVu L2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcgDQo+PiBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9L Y29uZmlnDQo+PiBpbmRleCBmYzc5MThjN2ZjLi5iYmY4OGZiYjlhIDEwMDY0NA0KPj4gLS0tIGEv eGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJt d2FyZS9LY29uZmlnDQo+PiBAQCAtOCw5ICs4LDE4IEBAIGNvbmZpZyBBUk1fU0NJDQo+PiDCoCDC oCBtZW51ICJGaXJtd2FyZSBEcml2ZXJzIg0KPj4gwqAgK2Nob2ljZQ0KPj4gK8KgwqDCoCBwcm9t cHQgIkFSTSBTQ0kgZHJpdmVyIHR5cGUiDQo+PiArwqDCoMKgIGRlZmF1bHQgU0NNSV9TTUMNCj4+ ICvCoMKgwqAgaGVscA0KPj4gK8KgwqDCoCBDaG9vc2Ugd2hpY2ggQVJNIFNDSSBkcml2ZXIgdG8g ZW5hYmxlLg0KPj4gKw0KPj4gK2NvbmZpZyBBUk1fU0NJX05PTkUNCj4+ICvCoMKgwqAgYm9vbCAi bm9uZSINCj4+ICsNCj4+IMKgIGNvbmZpZyBTQ01JX1NNQw0KPj4gwqDCoMKgwqDCoCBib29sICJG b3J3YXJkIFNDTUkgb3ZlciBTTUMgY2FsbHMgZnJvbSBod2RvbSB0byBFTDMgZmlybXdhcmUiDQo+ PiAtwqDCoMKgIGRlZmF1bHQgeQ0KPj4gK8KgwqDCoCBzZWxlY3QgQVJNX1NDSQ0KPj4gwqDCoMKg wqDCoCBoZWxwDQo+PiDCoMKgwqDCoMKgwqDCoCBUaGlzIG9wdGlvbiBlbmFibGVzIGJhc2ljIGF3 YXJlbmVzcyBmb3IgU0NNSSBjYWxscyB1c2luZyBTTUMgYXMNCj4+IMKgwqDCoMKgwqDCoMKgIGRv b3JiZWxsIG1lY2hhbmlzbSBhbmQgU2hhcmVkIE1lbW9yeSBmb3IgdHJhbnNwb3J0IA0KPj4gKCJh cm0sc2NtaS1zbWMiDQo+PiBAQCAtMTgsNCArMjcsNiBAQCBjb25maWcgU0NNSV9TTUMNCj4+IMKg wqDCoMKgwqDCoMKgIGZpcm13YXJlIG5vZGUgaXMgdXNlZCB0byB0cmFwIGFuZCBmb3J3YXJkIGNv cnJlc3BvbmRpbmcgU0NNSSANCj4+IFNNQ3MNCj4+IMKgwqDCoMKgwqDCoMKgIHRvIGZpcm13YXJl IHJ1bm5pbmcgYXQgRUwzLCBmb3IgY2FsbHMgY29taW5nIGZyb20gdGhlIA0KPj4gaGFyZHdhcmUg ZG9tYWluLg0KPj4gwqAgK2VuZGNob2ljZQ0KPj4gKw0KPj4gwqAgZW5kbWVudQ0KPj4gZGlmZiAt LWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy5jIA0KPj4gYi94ZW4vYXJjaC9h cm0vZmlybXdhcmUvc2NtaS1zbWMuYw0KPj4gaW5kZXggMzM0NzNjMDRiMS4uMTNkMTEzNzU5MiAx MDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy5jDQo+PiArKysg Yi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMuYw0KPj4gQEAgLTksNiArOSw3IEBADQo+ PiDCoMKgICogQ29weXJpZ2h0IDIwMjQgTlhQDQo+PiDCoMKgICovDQo+PiDCoCArI2luY2x1ZGUg PGFzbS9kZXZpY2UuaD4NCltzbmlwXQ0KPj4gKw0KPj4gwqAgLyogSW5pdGlhbGl6ZSB0aGUgU0NN SSBsYXllciBiYXNlZCBvbiBTTUNzIGFuZCBEZXZpY2UtdHJlZSAqLw0KPj4gLXN0YXRpYyBpbnQg X19pbml0IHNjbWlfaW5pdCh2b2lkKQ0KPj4gK3N0YXRpYyBpbnQgX19pbml0IHNjbWlfZG9tMF9p bml0KHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2LCBjb25zdCANCj4+IHZvaWQgKmRhdGEpDQo+ PiDCoCB7DQo+PiDCoMKgwqDCoMKgIGludCByZXQ7DQo+PiDCoCBAQCAtMTM0LDIyICsxMjcsMzYg QEAgc3RhdGljIGludCBfX2luaXQgc2NtaV9pbml0KHZvaWQpDQo+PiDCoMKgwqDCoMKgIGlmICgg cmV0ICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gcmV0Ow0KPj4gwqAgLcKgwqDCoCBy ZXQgPSBzY21pX2R0X2luaXRfc21jY2MoKTsNCj4+IC3CoMKgwqAgaWYgKCByZXQgPT0gLUVPUE5P VFNVUFAgKQ0KPj4gLcKgwqDCoMKgwqDCoMKgIHJldHVybiByZXQ7DQo+PiArwqDCoMKgIHJldCA9 IGR0X3Byb3BlcnR5X3JlYWRfdTMyKGRldiwgU0NNSV9TTUNfSURfUFJPUCwgJnNjbWlfc21jX2lk KTsNCj4+ICvCoMKgwqAgaWYgKCAhcmV0ICkNCj4+ICvCoMKgwqAgew0KPj4gK8KgwqDCoMKgwqDC oMKgIHByaW50ayhYRU5MT0dfRVJSICJTQ01JOiBObyB2YWxpZCBcIiVzXCIgcHJvcGVydHkgaW4g XCIlc1wiIA0KPj4gRFQgbm9kZVxuIiwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFNDTUlfU01DX0lEX1BST1AsIGR0X25vZGVfZnVsbF9uYW1lKGRldikpOw0KPj4gK8KgwqDCoMKg wqDCoMKgIHJldHVybiAtRU5PRU5UOw0KPj4gK8KgwqDCoCB9DQo+DQo+IEkga25vdyB0aGF0IHlv dSBhcmUganVzdCBtb3ZpbmcgdGhlIGNvZGUsIGJ1dCBJIHdvbmRlciB3aGV0aGVyIGl0IA0KPiBt YWtlcyBzZW5zZSB0byB2YWxpZGF0ZSB0aGF0IHJldHJpZXZlZCB2YWx1ZSBhdCBsZWFzdCBjb3Jy ZXNwb25kcyB0byANCj4gU2lQIFNlcnZpY2UgQ2FsbHMgKGZvciB0aGUgZnV0dXJlIGhhcmRlbmlu Zyk/DQo+DQo+DQpJIGRvbid0IHNlZSBhbnkgcmVhc29uIGZvciB0aGF0LiBJIGNvdWxkbid0IGZp bmQgYW55IHJlcXVpcmVtZW50IGFib3V0IA0KU2lQIGNhbGwgaW4gWzFdDQpBbHNvLCBhY2NvcmRp bmcgdG8gREVOMDAyOEQgWzBdIDB4MDUwMDAwMDAgbWFzayBjYW4gYmUgdXNlZCBhcyBsb25nIGFz IA0KMHgwMjAwMDAwMA0KDQpbMF0gREVOMDAyOEQgDQpodHRwczovL2RvY3VtZW50YXRpb24tc2Vy dmljZS5hcm0uY29tL3N0YXRpYy82MDEzZTVmYWVlZTUyMzY5ODBkMDg2MTk/dG9rZW49DQpbMV0g REVOMDA1NiBodHRwczovL2RldmVsb3Blci5hcm0uY29tL2RvY3VtZW50YXRpb24vZGVuMDA1Ni9s YXRlc3QvDQo+PiArDQo+PiArwqDCoMKgIHJldCA9IHNjaV9yZWdpc3Rlcigmc2NtaV9zbWNfb3Bz KTsNCj4+IMKgwqDCoMKgwqAgaWYgKCByZXQgKQ0KPj4gLcKgwqDCoMKgwqDCoMKgIGdvdG8gZXJy Ow0KPj4gK8KgwqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19FUlIgIlND TUk6IG1lZGlhdG9yIGFscmVhZHkgcmVnaXN0ZXJlZCAocmV0ID0gDQo+PiAlZClcbiIsDQo+PiAr wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIHJl dHVybiByZXQ7DQo+PiArwqDCoMKgIH0NCj4+IMKgIMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19J TkZPICJVc2luZyBTQ01JIHdpdGggU01DIElEOiAweCV4XG4iLCANCj4+IHNjbWlfc21jX2lkKTsN Cj4+IMKgIMKgwqDCoMKgwqAgcmV0dXJuIDA7DQo+PiAtDQo+PiAtIGVycjoNCj4+IC3CoMKgwqAg cHJpbnRrKFhFTkxPR19FUlIgIlNDTUk6IEluaXRpYWxpemF0aW9uIGZhaWxlZCAocmV0ID0gJWQp XG4iLCByZXQpOw0KPj4gLcKgwqDCoCByZXR1cm4gcmV0Ow0KPj4gwqAgfQ0KPj4gwqAgLV9faW5p dGNhbGwoc2NtaV9pbml0KTsNCj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IGR0X2RldmljZV9tYXRj aCBzY21pX3NtY19tYXRjaFtdIF9faW5pdGNvbnN0ID0gew0KPj4gK8KgwqDCoCBEVF9NQVRDSF9D T01QQVRJQkxFKCJhcm0sc2NtaS1zbWMiKSwNCj4+ICvCoMKgwqAgeyAvKiBzZW50aW5lbCAqLyB9 LA0KPj4gK307DQo+PiArDQo+PiArRFRfREVWSUNFX1NUQVJUKHNjbWlfc21jLCAiU0NNSSBTTUMg RE9NMCIsIERFVklDRV9GSVJNV0FSRSkNCj4+ICvCoMKgwqAgLmR0X21hdGNoID0gc2NtaV9zbWNf bWF0Y2gsDQo+PiArwqDCoMKgIC5pbml0ID0gc2NtaV9kb20wX2luaXQsDQo+PiArRFRfREVWSUNF X0VORA0KPj4gwqAgwqAgLyoNCj4+IMKgwqAgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiBkaWZmIC0t Z2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjbWktc21jLmggDQo+PiBi L3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY21pLXNtYy5oDQo+PiBkZWxldGVk IGZpbGUgbW9kZSAxMDA2NDQNCj4+IGluZGV4IDZiMWExNjRhNDAuLjAwMDAwMDAwMDANCj4+IC0t LSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY21pLXNtYy5oDQo+PiArKysg L2Rldi9udWxsDQo+PiBAQCAtMSw0MSArMCwwIEBADQo+PiAtLyogU1BEWC1MaWNlbnNlLUlkZW50 aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPj4gLS8qDQo+PiAtICogeGVuL2FyY2gvYXJtL2luY2x1 ZGUvYXNtL2Zpcm13YXJlL3NjbWktc21jLmgNCj4+IC0gKg0KPj4gLSAqIEFSTSBTeXN0ZW0gQ29u dHJvbCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UgKFNDTUkpIG92ZXIgU01DDQo+PiAtICogR2Vu ZXJpYyBoYW5kbGluZyBsYXllcg0KPj4gLSAqDQo+PiAtICogQW5kcmVpIENoZXJlY2hlc3UgPGFu ZHJlaS5jaGVyZWNoZXN1QG54cC5jb20+DQo+PiAtICogQ29weXJpZ2h0IDIwMjQgTlhQDQo+PiAt ICovDQo+PiAtDQo+PiAtI2lmbmRlZiBfX0FTTV9TQ01JX1NNQ19IX18NCj4+IC0jZGVmaW5lIF9f QVNNX1NDTUlfU01DX0hfXw0KPj4gLQ0KPj4gLSNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4NCj4+IC0N Cj4+IC1zdHJ1Y3QgY3B1X3VzZXJfcmVnczsNCj4+IC0NCj4+IC0jaWZkZWYgQ09ORklHX1NDTUlf U01DDQo+PiAtDQo+PiAtYm9vbCBzY21pX2hhbmRsZV9zbWMoc3RydWN0IGNwdV91c2VyX3JlZ3Mg KnJlZ3MpOw0KPj4gLQ0KPj4gLSNlbHNlDQo+PiAtDQo+PiAtc3RhdGljIGlubGluZSBib29sIHNj bWlfaGFuZGxlX3NtYyhzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+IC17DQo+PiAtwqDC oMKgIHJldHVybiBmYWxzZTsNCj4+IC19DQo+PiAtDQo+PiAtI2VuZGlmIC8qIENPTkZJR19TQ01J X1NNQyAqLw0KPj4gLQ0KPj4gLSNlbmRpZiAvKiBfX0FTTV9TQ01JX0hfXyAqLw0KPj4gLQ0KPj4g LS8qDQo+PiAtICogTG9jYWwgdmFyaWFibGVzOg0KPj4gLSAqIG1vZGU6IEMNCj4+IC0gKiBjLWZp bGUtc3R5bGU6ICJCU0QiDQo+PiAtICogYy1iYXNpYy1vZmZzZXQ6IDQNCj4+IC0gKiBpbmRlbnQt dGFicy1tb2RlOiBuaWwNCj4+IC0gKiBFbmQ6DQo+PiAtICovDQo+PiBkaWZmIC0tZ2l0IGEveGVu L2FyY2gvYXJtL3ZzbWMuYyBiL3hlbi9hcmNoL2FybS92c21jLmMNCj4+IGluZGV4IDI0Njk3Mzhm Y2MuLjc4ZDViZGY1NmYgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdnNtYy5jDQo+PiAr KysgYi94ZW4vYXJjaC9hcm0vdnNtYy5jDQo+PiBAQCAtMjEsNyArMjEsNiBAQA0KPj4gwqAgI2lu Y2x1ZGUgPGFzbS90cmFwcy5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS92cHNjaS5oPg0KPj4gwqAg I2luY2x1ZGUgPGFzbS9wbGF0Zm9ybS5oPg0KPj4gLSNpbmNsdWRlIDxhc20vZmlybXdhcmUvc2Nt aS1zbWMuaD4NCj4+IMKgIMKgIC8qIE51bWJlciBvZiBmdW5jdGlvbnMgY3VycmVudGx5IHN1cHBv cnRlZCBieSBIeXBlcnZpc29yIFNlcnZpY2UuICovDQo+PiDCoCAjZGVmaW5lIFhFTl9TTUNDQ19G VU5DVElPTl9DT1VOVCAzDQo+PiBAQCAtMjMzLDcgKzIzMiw3IEBAIHN0YXRpYyBib29sIGhhbmRs ZV9zaXAoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+PiDCoMKgwqDCoMKgIGlmICggcGxh dGZvcm1fc21jKHJlZ3MpICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gdHJ1ZTsNCj4+ IMKgIC3CoMKgwqAgcmV0dXJuIHNjbWlfaGFuZGxlX3NtYyhyZWdzKTsNCj4+ICvCoMKgwqAgcmV0 dXJuIHNjaV9oYW5kbGVfY2FsbChyZWdzKTsNCj4+IMKgIH0NCj4+IMKgIMKgIC8qDQo+PiBAQCAt MzAxLDggKzMwMCw2IEBAIHN0YXRpYyBib29sIHZzbWNjY19oYW5kbGVfY2FsbChzdHJ1Y3QgDQo+ PiBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYnJl YWs7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgY2FzZSBBUk1fU01DQ0NfT1dORVJfU0lQOg0KPj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaGFuZGxlZCA9IGhhbmRsZV9zaXAocmVncyk7DQo+ PiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoICFoYW5kbGVkICkNCj4+IC3CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgaGFuZGxlZCA9IHNjaV9oYW5kbGVfY2FsbChyZWdzKTsNCj4N Cj4gVGhlc2UgdHdvIGxpbmVzIHdoZXJlIGFkZGVkIGJ5IFtQQVRDSCB2NiAxLzRdIHhlbi9hcm06 IGFkZCBnZW5lcmljIFNDSSANCj4gc3Vic3lzdGVtLCBidXQgaGVyZSB0aGV5IGFyZSByZW1vdmVk LiBUaGlzIGlzIG5vdCBhIHJlcXVlc3QgZm9yIGFuIA0KPiBleHRyYSB3b3JrIHJpZ2h0IG5vdywg YnV0IGlkZWFsbHkgdGhlIHNlcmllcyBzaG91bGQgYmUgc3BsaXR0ZWQgDQo+IHdpdGhvdXQgYW4g ZXh0cmEgdGVtcG9yYXJpbHkgY2hhbmdlcy4NCj4NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGJyZWFrOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGNhc2UgQVJNX1NNQ0NDX09XTkVSX1RS VVNURURfQVBQIC4uLiANCj4+IEFSTV9TTUNDQ19PV05FUl9UUlVTVEVEX0FQUF9FTkQ6DQo+PiDC oMKgwqDCoMKgwqDCoMKgwqAgY2FzZSBBUk1fU01DQ0NfT1dORVJfVFJVU1RFRF9PUyAuLi4gDQo+ PiBBUk1fU01DQ0NfT1dORVJfVFJVU1RFRF9PU19FTkQ6DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2lu Y2x1ZGUvcHVibGljL2FyY2gtYXJtLmggDQo+PiBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFy bS5oDQo+PiBpbmRleCA1NWVlZDk5OTJjLi4wOTViMWEyM2UzIDEwMDY0NA0KPj4gLS0tIGEveGVu L2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCj4+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9h cmNoLWFybS5oDQo+PiBAQCAtMzI4LDYgKzMyOCw3IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExF KHZjcHVfZ3Vlc3RfY29udGV4dF90KTsNCj4+IMKgICNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdf VEVFX0ZGQcKgwqDCoMKgwqDCoCAyDQo+PiDCoCDCoCAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklH X0FSTV9TQ0lfTk9ORcKgwqDCoMKgwqAgMA0KPj4gKyNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdf QVJNX1NDSV9TQ01JX1NNQ8KgIDENCj4+IMKgIMKgIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25m aWcgew0KPj4gwqDCoMKgwqDCoCAvKiBJTi9PVVQgKi8NCj4NCg== From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:23:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:23:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104235.1455328 (Exim 4.92) (envelope-from ) id 1ut0kp-0006uL-DE; Mon, 01 Sep 2025 09:23:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104235.1455328; Mon, 01 Sep 2025 09: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 1ut0kp-0006uE-AS; Mon, 01 Sep 2025 09:23:11 +0000 Received: by outflank-mailman (input) for mailman id 1104235; Mon, 01 Sep 2025 09: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 1ut0ko-0006dF-1S for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:23:10 +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 4628383b-8715-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 11:23:09 +0200 (CEST) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-afcb7a16441so635875966b.2 for ; Mon, 01 Sep 2025 02:23:09 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b043fd772bcsm26952666b.14.2025.09.01.02.23.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02: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: 4628383b-8715-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756718588; x=1757323388; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=rm0yRkOu7F19gNlA4SI+/jJ7K1ooBbhgF7qek1U8JXs=; b=eUPMNfM9/KXuQb5E97BCFyESNhoEWfsY37RKJ2NwAoiJfGGYAWRD8nJ+her1+QKn2m WmOl1VBWpVcUldLNr0IBfiYtdXTz8BQEMnCp52OZIJDJAj3FRL3RfWKCCG9pjyFfifEm 217E8cLrkUSMdRw3XFkk4cu+3flZ7pP5ou1HhSz7Nz5Wbcw3x8XtHqMMdUR5iu2dpJNT yQTDshEkIX0EvpYLWXHxhEB4PIGbcmqlEKiKcOnx5NRLhrFRWxKW1XmY4D+q8WVr5i5z K4hQHYloJBSWetU230rAvEYRkoKoChb/TPliviHvNPi19FmhHQ+KbvH898DIr1L9oMN3 gilQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756718588; x=1757323388; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rm0yRkOu7F19gNlA4SI+/jJ7K1ooBbhgF7qek1U8JXs=; b=h0BaQETJW4Jus38IWKoAXL1+5jU0Jn48OpruqQ6tJc4z/GubVb7JzsFgEX2EbfFVLA Kk6yAQBRTsa1FVytYu6nTpBeIx11XmGmHHc3aXlgrzycfkRedezXa9lZ3AWnSrECvTYN PJiGItOZJ+k+ERpVzCcaSaSsRYMuj+Yqirmp55SOdeQ1leu0K7rJNDo2BlWnSn4SlhCz X60Xb502Hsw6d/c9ofu5E8hhwCYAxdJSayvvy/YD+YLTQLNjLF3AfLSekhrA3C4u4Tmi 28xhDhLHn1hMJT6twpwy4QfvUq2HQjCmuVpsJCgbkcZ5vKu9N34flPvVt7ijiVbUh7SM gj/Q== X-Forwarded-Encrypted: i=1; AJvYcCVgvBGRey09wr4onRxSFKH1lwsqCrCACqgUGmAHPaGA5PX7PxvfeAU+ZhWqmfnnj3XG4zv9I1znfxE=@lists.xenproject.org X-Gm-Message-State: AOJu0YwvXV073vkVRtnbSMTW9QPY9XwK+KSm/b6VOGL/a2ejiouMbdhQ Ip/Jd0981cSQz0sjh8lVlnwXtJSZ5iyOzrKJfLL2kcknc7YoW32z607txyXDFhR2OA== X-Gm-Gg: ASbGncti4mn/X34Elj9WtnvrI/4BJ6c9QkAXrpdXYwgKKUf8w1sP4HL3zXKSaHUVtb3 R7HpR0iSYLiqd7tY5XRS8RoSlPIIST/Q21Cq+xBF0RC7veb/OvpqIKWh5+A0w/UR1L76E2sluWc bgq+L5t1lPGn+9mgcZcJ0up0r9z0AaViyvx6XlAjc4DSQMP/5k5C4bHXExP9QhcVX75+UtvkkTV EoSkYj4VeUyPEZfsUyd3r4UCK5X1FQQtafAPvPUZW5NQk8BNFaTyBkNYaMkt5m8pkO66mu4cX+M VTi8qIdzj9+e3EVOkS2rTyZYMs1v73xEElf+EQf3MZaE9S4HmxowJhvMFLlt/vftp3nepVJ11g3 jlny/plzbuhZ4dI24IK922HAmHeTqWmtO0H4vwl6nIg+C8tRenDqp5fmI4vz03q6VqyaZ+fUvee z36B7vsg0= X-Google-Smtp-Source: AGHT+IEg7K2iFBsU1Ou05wLpiyhA1jEp9yRxo034LDIm+RtYNGyqKEWnPrA3ntu013LFJ9xpMD66Mg== X-Received: by 2002:a17:907:3f28:b0:afc:cc64:86da with SMTP id a640c23a62f3a-b01d8c9073amr628813766b.26.1756718588462; Mon, 01 Sep 2025 02:23:08 -0700 (PDT) Message-ID: <2ae92f1c-da23-42d0-a1cc-70dff04310cd@suse.com> Date: Mon, 1 Sep 2025 11:23:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/23] x86/traps: Set MSR_PL0_SSP in load_system_tables() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-7-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250828150409.901315-7-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.08.2025 17:03, Andrew Cooper wrote: > FRED and IDT differ by a Supervisor Token on the base of the shstk. This > means that the value they load into MSR_PL0_SSP differs by 8. > > s3_resume() in particular has logic which is otherwise invariant of FRED mode, > and must not clobber a FRED MSR_PL0_SSP with an IDT one. > > This also simplifies the AP path too. Updating reinit_bsp_stack() is deferred > until later. This last sentence looks to be ... > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v2: > * Extend comment about clearing the busy bit. > * Move reinit_bsp_stack() hunk into this patch. ... stale, according to this. Other than that: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:26:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:26:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104246.1455338 (Exim 4.92) (envelope-from ) id 1ut0nw-0007Tg-R1; Mon, 01 Sep 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 1104246.1455338; Mon, 01 Sep 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 1ut0nw-0007TZ-O4; Mon, 01 Sep 2025 09:26:24 +0000 Received: by outflank-mailman (input) for mailman id 1104246; Mon, 01 Sep 2025 09:26: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 1ut0nv-0007TT-9r for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:26:23 +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 b8bed9bc-8715-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 11:26:21 +0200 (CEST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-55f68d7a98aso2538014e87.3 for ; Mon, 01 Sep 2025 02:26: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: b8bed9bc-8715-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756718781; x=1757323581; 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=JGeHWtWNgO705oxiOYsA+gyhdLCj4bABvxrJX/jN1iE=; b=SGhdvh0CFU1+RYkJkXP8mMeKdPp0RUfYxkRbPWyWl5TWhK6YHUXnerhYsYRPKYAZYU q1gLTn5tO9O6HjE4JCdi+W0BMpnM4Sy3vEgAtb5WBOy4PNTuKKMm4VUKZQ6pzB9UMGar 3olpmfXjx7qZoo1HpCPCTk5AQMFZHLRn4AtV6R+/RrrT3JTKOME1FAjDcCfw7Fp0AQ8v oZ/+SuQL4J7zutYG5EocvsTQLBuCryOuGDPJF8HqX0nYUs5qvoY0ND1mDkdzZIdVfDrG 1tGBWpMlCTGpqDBOfjZCZ0uJ5crLmV59TujJPqgJneFiNfO4ZsVjj/zgdvxPU/FqxKJb KWpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756718781; x=1757323581; 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=JGeHWtWNgO705oxiOYsA+gyhdLCj4bABvxrJX/jN1iE=; b=io1GmJP93Pdw3ctQyeeDefmKCbwtBH4sus61SNSAOZ1VqTCF++zqjF3YmFUDJ+4GSS 1GekbEaVMOwc/zLzdfiRnqv0IA1bUH57XBA758WvLp9ole5FnZDnkv6t7XaUnUEqU7CB WCraWGRS1F0rjRDBTFz8mexocApySwVfUZmk1qLVNI5V1ulmHNIVhJKzwOEkltJ/yo03 aeOy2MmGWafll6plvSwvZnbIqRdz/JCCeM5sFBWvEw6Ko12Sw+YNEgpd3ffVDc7wFhRt 6TN6Wkt4IBd1fNGyGGcMpKiCfJmCMV/Sto7TRzzYuy7SBF5HfvcLpS8eg3331r2Ojnug n2TQ== X-Gm-Message-State: AOJu0YwMRLme/E1gE4jzP+hRkkTwEs0263jzUz7ULwdpzwAoSo/FfYA5 7p4PwDRWMmYCmtF7LkrqSnU+csuldLMgDtERgA0i21ZWHZizJLyQ+pyfDGM1alGNwgtaORhu+XI 1yn2tkq+bCJ+QN1UtB9HiPDYRaJRTwDI= X-Gm-Gg: ASbGncsS49+PI/qvtVUd7CC1SUKILwklP59Ek6EhrsM50WsdZjk5kIMe5UftxVzBLXL 8VprGb6dKSUdQSKymH1kvK2LE2qoY364FdT57i9OLqQ+m54JBydBQyJ29xlZmqZnEMm5Ui34i3t +RV8x/UJIbpNZtGoynkw6PMT+8ka5I0w6JfDbxA6eA7GIvvmGU69ZMOYoSljZnmgx1dbNlUOFtM KPC+w== X-Google-Smtp-Source: AGHT+IHvj0G5XcfwMnlDShmploLpRGYG/6mk1osr+cYNn99IYvrY68a8j5nnANOO0I8Sx3cAkD7ozSig6dJKZQq+gXM= X-Received: by 2002:a05:6512:4002:b0:55f:3e8f:ac10 with SMTP id 2adb3069b0e04-55f709886f7mr2136762e87.49.1756718780307; Mon, 01 Sep 2025 02:26:20 -0700 (PDT) MIME-Version: 1.0 References: <24567cc1630b1577c33939ff71d67fb2ebe5572f.1754491424.git.dmytro_firsov@epam.com> In-Reply-To: <24567cc1630b1577c33939ff71d67fb2ebe5572f.1754491424.git.dmytro_firsov@epam.com> From: Mykola Kvach Date: Mon, 1 Sep 2025 12:26:08 +0300 X-Gm-Features: Ac12FXzz9oOK_kMxsFAmUfOYLAVi4KEd0wCbmt5TdL3flZ47esYmFJvD2IcE-N4 Message-ID: Subject: Re: [PATCH] xen/arm: smmuv3: Add cache maintenance for non-coherent SMMU queues To: Dmytro Firsov Cc: "xen-devel@lists.xenproject.org" , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dmytro, On Wed, Aug 6, 2025 at 5:59=E2=80=AFPM Dmytro Firsov wrote: > > According to the Arm SMMUv3 spec (ARM IHI 0070), a system may have > SMMU(s) that is/are non-coherent to the PE (processing element). In such > cases, memory accesses from the PE should be either non-cached or be > augmented with manual cache maintenance. SMMU cache coherency is reported > by bit 4 (COHACC) of the SMMU_IDR0 register and is already present in the > Xen driver. However, the current implementation is not aware of cache > maintenance for memory that is shared between the PE and non-coherent > SMMUs. It contains dmam_alloc_coherent() function, that is added during > Linux driver porting. But it is actually a wrapper for _xzalloc(), that > returns normal writeback memory (which is OK for coherent SMMUs). > > During Xen bring-up on a system with non-coherent SMMUs, the driver did > not work properly - the SMMU was not functional and halted initialization > at the very beginning due to a timeout while waiting for CMD_SYNC > completion: > > (XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout > (XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout Thank you for your patch. I have encountered the same issue while testing other Xen functionality on the Orange Pi 5 board (SoC RK3588S): (XEN) [ 0.040350] SMMUv3: /iommu@fc900000: ias 48-bit, oas 48-bit (features 0x00001c0f) (XEN) [ 0.043164] SMMUv3: /iommu@fc900000: allocated 524288 entries for cmd= q (XEN) [ 0.048505] SMMUv3: /iommu@fc900000: allocated 524288 entries for evt= q (XEN) [ 1.099335] SMMUv3: /iommu@fc900000: CMD_SYNC timeout This patch resolves the problem. Tested-by: Mykola Kvach > > To properly handle such scenarios, add the non_coherent flag to the > arm_smmu_queue struct. It is initialized using features reported by the > SMMU HW and will be used for triggering cache clean/invalidate operations= . > This flag is not queue-specific (it is applicable to the whole SMMU), but > adding it to arm_smmu_queue allows us to not change function signatures > and simplify the patch (smmu->features, which contains the required flag, > are not available in code parts that require cache maintenance). > > Signed-off-by: Dmytro Firsov > --- > xen/drivers/passthrough/arm/smmu-v3.c | 27 +++++++++++++++++++++++---- > xen/drivers/passthrough/arm/smmu-v3.h | 7 +++++++ > 2 files changed, 30 insertions(+), 4 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthro= ugh/arm/smmu-v3.c > index 5e9e3e048e..bf153227db 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -346,10 +346,14 @@ static void queue_write(__le64 *dst, u64 *src, size= _t n_dwords) > > static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent) > { > + __le64 *q_addr =3D Q_ENT(q, q->llq.prod); > + > if (queue_full(&q->llq)) > return -ENOSPC; > > - queue_write(Q_ENT(q, q->llq.prod), ent, q->ent_dwords); > + queue_write(q_addr, ent, q->ent_dwords); > + if (q->non_coherent) > + clean_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_a= ddr)); > queue_inc_prod(&q->llq); > queue_sync_prod_out(q); > return 0; > @@ -365,10 +369,15 @@ static void queue_read(u64 *dst, __le64 *src, size_= t n_dwords) > > static int queue_remove_raw(struct arm_smmu_queue *q, u64 *ent) > { > + __le64 *q_addr =3D Q_ENT(q, q->llq.cons); > + > if (queue_empty(&q->llq)) > return -EAGAIN; > > - queue_read(ent, Q_ENT(q, q->llq.cons), q->ent_dwords); > + if (q->non_coherent) > + invalidate_dcache_va_range(q_addr, q->ent_dwords * sizeof= (*q_addr)); > + > + queue_read(ent, q_addr, q->ent_dwords); > queue_inc_cons(&q->llq); > queue_sync_cons_out(q); > return 0; > @@ -463,6 +472,7 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_de= vice *smmu) > struct arm_smmu_queue *q =3D &smmu->cmdq.q; > u32 cons =3D readl_relaxed(q->cons_reg); > u32 idx =3D FIELD_GET(CMDQ_CONS_ERR, cons); > + __le64 *q_addr =3D Q_ENT(q, cons); > struct arm_smmu_cmdq_ent cmd_sync =3D { > .opcode =3D CMDQ_OP_CMD_SYNC, > }; > @@ -489,11 +499,14 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_= device *smmu) > break; > } > > + if (q->non_coherent) > + invalidate_dcache_va_range(q_addr, q->ent_dwords * sizeof= (*q_addr)); > + > /* > * We may have concurrent producers, so we need to be careful > * not to touch any of the shadow cmdq state. > */ > - queue_read(cmd, Q_ENT(q, cons), q->ent_dwords); > + queue_read(cmd, q_addr, q->ent_dwords); > dev_err(smmu->dev, "skipping command in error state:\n"); > for (i =3D 0; i < ARRAY_SIZE(cmd); ++i) > dev_err(smmu->dev, "\t0x%016llx\n", (unsigned long long)c= md[i]); > @@ -504,7 +517,10 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_d= evice *smmu) > return; > } > > - queue_write(Q_ENT(q, cons), cmd, q->ent_dwords); > + queue_write(q_addr, cmd, q->ent_dwords); > + > + if (q->non_coherent) > + clean_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_a= ddr)); > } > > static void arm_smmu_cmdq_insert_cmd(struct arm_smmu_device *smmu, u64 *= cmd) > @@ -1634,6 +1650,9 @@ static int __init arm_smmu_init_one_queue(struct ar= m_smmu_device *smmu, > q->q_base |=3D FIELD_PREP(Q_BASE_LOG2SIZE, q->llq.max_n_shift); > > q->llq.prod =3D q->llq.cons =3D 0; > + > + q->non_coherent =3D !(smmu->features & ARM_SMMU_FEAT_COHERENCY); > + > return 0; > } > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthro= ugh/arm/smmu-v3.h > index f09048812c..db936b9bd4 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.h > +++ b/xen/drivers/passthrough/arm/smmu-v3.h > @@ -522,6 +522,13 @@ struct arm_smmu_queue { > > u32 __iomem *prod_reg; > u32 __iomem *cons_reg; > + > + /* > + * According to SMMU spec section 3.16, some systems may have > + * SMMUs, that are non-coherent to PE (processing elements). > + * In such case manual cache management is needed. > + */ > + bool non_coherent; > }; > > struct arm_smmu_cmdq { > -- > 2.50.1 > Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:26:51 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:26:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104254.1455349 (Exim 4.92) (envelope-from ) id 1ut0oN-0007ws-2z; Mon, 01 Sep 2025 09:26:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104254.1455349; Mon, 01 Sep 2025 09:26:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut0oM-0007wj-VX; Mon, 01 Sep 2025 09:26:50 +0000 Received: by outflank-mailman (input) for mailman id 1104254; Mon, 01 Sep 2025 09:26: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 1ut0oM-0007TT-8d for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:26:50 +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 c8e68c78-8715-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 11:26:48 +0200 (CEST) Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5) by AS8PR03MB6741.eurprd03.prod.outlook.com (2603:10a6:20b:23c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 09:26:46 +0000 Received: from GV2PR03MB9572.eurprd03.prod.outlook.com ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com ([fe80::edd1:842f:9b14:509e%3]) with mapi id 15.20.9073.021; Mon, 1 Sep 2025 09:26: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: c8e68c78-8715-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=o70lf2BFNXlVQ9ds0ZXZrW6nNqO+dq3muTlKV1yrJyM1f/9ZE9MPosg5uaAFgieC6TngT25N/fwHSn1TYKZT59LsHwlAOjxemIjExpaXy3w9/tQuraf2LalZf8f++uSbvatG3NUojNi7Bkzdf7aiMNhdwTcFTQdtVtA1+x7aB0hGB0L1U8huQi5l0Six9fi+DN02Qlc06F5oKy90slQK+vjEFs5r4Wfm6pp7j1YDsIj2nqipH9QkDm7kY95IT5wAF9tCSUM6rgXN3v/qMsM/Erup2caHsAqlC1AqWBpE7gFoprsM8pKYBtkllICwlsYEqYYdHG5g6LniSYGPmlf6Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CEWDpgFAqkk98uKrndfkSlsjqAdBOfj7hKp97yeBNbs=; b=aGjl26cAdORAyD6HlbcW4arPvoV5x9DJfQIDJ4oItr6zSyEawIbP6pvasgE6qQSq373QWg8W9DmlWCkrS2O4xw5gPnjPEQe9EwINTQ2254TBYE/WFr8JSWWFdzVASCnF4e18INH4U86kugrHC5l4fZ1PguDr8nKpCpQ+Akq5DoZw2yUXTSc2nvqUAB32x1A+xEjcfcFhiXsSOsrj18e4Uk3meSmY1v1J5VY48O8co0DkwKLK06Fbllq3LQTpQiMDI1P3nF98Wx7nuwX8s7xQ8NSQl+0qcMN/W9pB6AjXM7/Vx9biDictxFQ5jaMJue2UWq4dVXcjrrOMK7pr2M2sQg== 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=CEWDpgFAqkk98uKrndfkSlsjqAdBOfj7hKp97yeBNbs=; b=im7DTCLdKy+J/jSlP40EOSf09FT/rgp+jQhJx7bloEXfLHylOr3GCV1+jLxuz45ziDCE6wRkjv5UG4QfIJymufKh15xsotf/0sYss/112FBRn/57DkeEbuJVHj7iX5WKcl4iN8r2GkTHzEuSQuctlx4QYhUAlJ0mDemswulAU2f3iNsXxp/Fs1Z8kbSMuoaGnqhqrcpBpFj3lkRAFJQik1nEwmut3ql/XjeT0n+MU80phQixlV7q1po9LZf5FnRiuUD4nh7p/fQNF0GYz5n+0P2kHlgFvLBwvKuC8cO6qYGjxsXP+Fpxnt7hfPSmmRt6YE/cHj6TkhhA7kJIjHEABw== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: [PATCH v3] device-tree: fix infinite loop issue in 'assign_shared_memory()' Thread-Topic: [PATCH v3] device-tree: fix infinite loop issue in 'assign_shared_memory()' Thread-Index: AQHcGyKJ90rw+TS90UqWTJ4b0NemJA== Date: Mon, 1 Sep 2025 09:26:45 +0000 Message-ID: <41cbf42c319a95c92517b6042414de6d13dda077.1756718656.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: GV2PR03MB9572:EE_|AS8PR03MB6741:EE_ x-ms-office365-filtering-correlation-id: 58193171-2b36-4bfb-0a8e-08dde939abc8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|42112799006|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?EEtmG3cvnOwk4IWz6FS67SGSVQGzSyJcDkyzlsnrrb9yDPA6YLEwkIr4jm?= =?iso-8859-1?Q?bFzPwu3Yv5N0Ps02a9hKSW2rok3REOQrUZin4LATx8SqTC/qr5Jwwl6g0T?= =?iso-8859-1?Q?IFxpwKgJ3z38PJuucCuPIEgw0ReNIoFCHQYFMYH8UUDt+eDIhS3AI6IM/X?= =?iso-8859-1?Q?goGJWSBhOP6HmVsjLPsC4EKPzOr8J9RDx6oi29MmBhtrkMixFKSCMz3LHy?= =?iso-8859-1?Q?f2nrX6lve7cTBRisPnr3PmF3v+UZ+EsAIwDJe2KUgsv2mwxA9uSJqDUTyx?= =?iso-8859-1?Q?0R4TYBel4TxpblKP0z6CXbTWMKWEzijMiXpXzL7ndHucrHULdIj0b8Hqs1?= =?iso-8859-1?Q?R3ODWf5cH1voEZVtaNnlm+VTXNYdtpWM81J20rwluXFbVgigfT4hOkFFI2?= =?iso-8859-1?Q?NR+e8us2XkwxT5fehvR5Y04odSfqfV/6ideiRp57tIVHWkTDpFJ2Juth9d?= =?iso-8859-1?Q?hkx0y4dfNx2MHFxYtjRXKtGIBFLLPTpczlOMQlDvgeEmF9Yc2sBWBwLJne?= =?iso-8859-1?Q?MRpU+PBWjFfETYoaPNUGdSZ6Svr0ILYFp3Vy8OzzSNgDGIAcCOH6PnoxGZ?= =?iso-8859-1?Q?8QmVeetiqt0we7gIRc/OKXJxmf/jqBskzYZ3KDezkQdNkDolxXEZk4O5QX?= =?iso-8859-1?Q?zc4CiLBN0GNNqY096ovLsCfM3jYysZkwfCIhybV0tPpUPo2ck7WLK36Ji7?= =?iso-8859-1?Q?cO6rdRYG6hKEf6YYMGwbb05y1I8JYtsrkIxLGMcfu8IWFdXXeXIjHZP5v7?= =?iso-8859-1?Q?FzZ0VT241gMRGwE+8USeZzYViFmUlH/QsyO8LAwE3oA/cZFEUeN5qlLJ4P?= =?iso-8859-1?Q?qPxUnCkRgsezRdU2pmebBd63XxGiMpldGaZhlgjmAMolkCxEoHq2IL7xGn?= =?iso-8859-1?Q?V+FpnbSPVzyt8jSIagU+eVdmDLQDw9ck17f10giFhesW4qVmmYemxSOSfD?= =?iso-8859-1?Q?emyYujYMYb8yKEH/6tpjDJUW2ZVY9gu0jm5kKUfkTMi+I1WrdYv4AAA+XG?= =?iso-8859-1?Q?X9hOlIezpn2D5e0Z519tjSiS4E6R9dVHHs8xkx1RW8+c0uOG0tfUUlxtV1?= =?iso-8859-1?Q?AN3lYKR9gK5u7uUjQc/GxVDBK/OPQdQcRP777MQUqWtGOACObxd/Lye3Ut?= =?iso-8859-1?Q?TDydHvnKRHAG7G6z9DYejETbWwwZ3EkTrSduWgdihSM5HbKTzcIBEnGLvd?= =?iso-8859-1?Q?1WSDInkeryszwPf3TvQe8XvtMngyzh7GoYKsBGFLv54xsgnkzgEucQBtWa?= =?iso-8859-1?Q?FDEFV+gg8OWyHpqy7UA7k+gwzeCcQTzEuwex2Iqd+N4PnQdC6vSt5E6Z/C?= =?iso-8859-1?Q?59L4JZK0+aVN8selqY+sA0xbjFXkbAGJEiv/kkDTDU5kGIKrxWIp7402K1?= =?iso-8859-1?Q?vgskubAbPpwPVeIvO5SbZA5eVFLDKtGUZAvBDHyDo5XB6ePXl55S4MruMy?= =?iso-8859-1?Q?f2VCNByLSynq2//pa4JgbJeiAkQlutt7nSd41lvJol4wam5df3z7ondGwl?= =?iso-8859-1?Q?c=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(42112799006)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fF6ts1ODi12tOTaAutl77fDzZ1mmHgO/v50Qy1QJyT4A+dDvnp+UItLCBS?= =?iso-8859-1?Q?7okUR4F22tbkW/nJZtAGiQbN7pujH/WbJ4Q/xUww0Us8S/dtIF0nsTbdIn?= =?iso-8859-1?Q?gVR084GS/pZ7baltSfgSe+gAEbHwfAeYfwrTQZ85Wzxn41Qw+jxDot6IWD?= =?iso-8859-1?Q?5RCZICcxAs4miBdhnDnrkBGkAbcijb+nZiY0IH3d2TPgqKHTCO5jI6YTmd?= =?iso-8859-1?Q?B2xni5ALyZgQ9U9vx6eKI+5Ux2BEn0bwSlk5K7wvHUHcNzhh/kgLHRsQhl?= =?iso-8859-1?Q?4A71enKDIxI1/KrmucDp3J5/ceb3POD0CZjYUNJv2IaooavdeMi73+9XE/?= =?iso-8859-1?Q?GGZvsbpX3pbC/sabPi143zWucickdPSbqF/K7w+pT8nZ9iBQ9ow5DTSaeM?= =?iso-8859-1?Q?rBkFgK/aJDMDRzolNi7UnWbAWUQj1oy8dMH25l/U8mWbwhHx5BlZRfULsm?= =?iso-8859-1?Q?bL96kp+3ZBD2fvHHWU7XzykIfQ9Oqnq10lXUuiRL1IHtUy5hxQozW3PWJX?= =?iso-8859-1?Q?Agyqd1Jgwpam1NFlAdWGAvYF+0z+b/vP8ZYk7u4pC0ifcf4uJLNQF4lo8g?= =?iso-8859-1?Q?UjHgHrpagPDCG3nErMZXJa8ckhteiLkzby/Foglgk3JwX7ao0asavVk85y?= =?iso-8859-1?Q?pVs5lD0gguzspHBlJ+2D6+TSIPQgRMymLLCTZBA2ajV0LzkT94opNq2XAg?= =?iso-8859-1?Q?h5ojZGvGAYXIobK42+vpJtLBEDppKboWcFsoeHUxCSXaHqQwDuQcpD/2sV?= =?iso-8859-1?Q?DJfNv3DZoisGMXx9rKO7b1z9WFIV6lhLh5BefuvxeWTCvbE5rAR7aKRM2q?= =?iso-8859-1?Q?4iOEDuDW0YiocjWdSKOG+PUunV+3Dkp4x4GvPaUjKixwGwslGz3Hi2/gv9?= =?iso-8859-1?Q?Sh+NEdVPdkxa2ca5i83A/kTlICSaf6++7DPkUZtXj9rHOo2Y3dq+XT1RpF?= =?iso-8859-1?Q?mgSakvYTpKX1B3Wg9rY1ec5f7jHWRX4s5q769Bq91nn6rztHLcnm3JJQyc?= =?iso-8859-1?Q?qbwUedd4psP4i2ltf3GJukBRGjgnPRaPIw7qJj/XnnvZj81mVQVR+9rmnx?= =?iso-8859-1?Q?kzBn8cGH6G/36ze771UJrf4/p6LaPE2ecqgkViBy68dbWmlAa3k7wiy4OW?= =?iso-8859-1?Q?dcxWeNi3mIsNEnl8dPXxNjj5fm76JndUvl2zbPXfz+UuSogfuPp/8uA9hZ?= =?iso-8859-1?Q?r7fb7KjO/oaX2/rYlx/sA+K+BQY9VtvDGoF+6XhreW9qSsp8ugBezDXD2U?= =?iso-8859-1?Q?Lxj3bKj0FLafTz+qd5yOwW3/19hTjxkQk135ziAOBGhauTF4693drbecfU?= =?iso-8859-1?Q?ZslY3pRMB/F86TM4oYWCoRisPa0S1ME0ZJSu+CnODVWIpRcwHHkKwKiHdj?= =?iso-8859-1?Q?nKoe0QmML52E0+KIEVrDs9+nuYdy/04DlucnLEZothjJ65ebLFJ6kZ9UEz?= =?iso-8859-1?Q?nASa4Dmfo49AJsh0cd97HYwFv6rwwr7wa1r6TbEakrjozqyKNTwRQxLASF?= =?iso-8859-1?Q?6B5jaJkrXLf6EFsl77Lsj9gdA/6NPTvvyItDkErjJ+whUy36zba6PZGRCa?= =?iso-8859-1?Q?ATdKfenSUcCm8JmAa98nbif9Z44idyoIlcH+3zfQslZmQ2frreCeVJp3By?= =?iso-8859-1?Q?M0qgMiNjryEHscbutiyhZIj5/jofD+NxBysGThYVcffPnp5b+gbmESwQ?= =?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: GV2PR03MB9572.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58193171-2b36-4bfb-0a8e-08dde939abc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 09:26:46.0784 (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: ptF1M9Jz8mjJ2Hk35WEIrzGj5s+M/L5PwFjVOffthhaGCa8APr31vwhfEtuJbebteJmhRE1guh2dGCznLs5M3bXdbXiUQfxPN+9bSN77WmI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6741 Fix an issue in the 'fail:' cleanup path of the 'assign_shared_memory()' function where the use of an unsigned long 'i' with the condition '--i >=3D 0' caused an infinite loop. Update the loop to use 'i--', ensuring correct loop termination. This change adheres to MISRA C Rule 14.3: "Controlling expressions shall not be invariant." Fixes: 041957bad382 ("xen/arm: Add additional reference to owner domain whe= n the owner is allocated") Signed-off-by: Dmytro Prokopchuk --- Changes in v3: - inserted right Fixes tag, pointed by Andrew Cooper Link to v2: https://patchew.org/Xen/0e562f695e5db87ab80dde69cbcc0cfa14f94b21.1756373770= .git.dmytro._5Fprokopchuk1@epam.com/ --- xen/common/device-tree/static-shmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/device-tree/static-shmem.c b/xen/common/device-tree= /static-shmem.c index 8023c0a484..79f23caa77 100644 --- a/xen/common/device-tree/static-shmem.c +++ b/xen/common/device-tree/static-shmem.c @@ -185,7 +185,7 @@ static int __init assign_shared_memory(struct domain *d= , paddr_t gbase, return 0; =20 fail: - while ( --i >=3D 0 ) + while ( i-- ) put_page_nr(page + i, nr_borrowers); return ret; } --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:28:16 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:28:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104270.1455359 (Exim 4.92) (envelope-from ) id 1ut0ph-0008Vo-Cn; Mon, 01 Sep 2025 09:28:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104270.1455359; Mon, 01 Sep 2025 09: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 1ut0ph-0008Vf-8q; Mon, 01 Sep 2025 09:28:13 +0000 Received: by outflank-mailman (input) for mailman id 1104270; Mon, 01 Sep 2025 09: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 1ut0pf-0008VV-M7 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:28:11 +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 fa153280-8715-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 11:28:10 +0200 (CEST) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b042eb09948so113555366b.3 for ; Mon, 01 Sep 2025 02:28: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 a640c23a62f3a-b040f1cf4b9sm421247666b.29.2025.09.01.02.28.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02:28: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: fa153280-8715-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756718890; x=1757323690; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+OjBGQlc7KunvXiwW1dw+QKH2gYgV2aEjow/wpDnEig=; b=MVtek3W00XLpx7Ey/IrcJLmAlz3mYTVjEM0uT5hW6N+bdPo8dOvh8wqRUJWvE3LFZM eVXqlc/Y1ymbDV6H3cVHVdCGqnAppE3J3Zh0D1gzg4Kx9uU7n7C/gb3NbJA9742sGlbU erWT664P13nJ6lYORZLTTTwT6cVoPWC65hjMNMBYsPBX2JPJi+oO/Wg9LUJoSCAMTR3g GSPJjhDsJAfrt596nijiq+sJbquoPo7rsn+4IZHzQ2IOHOug3H+NrPUknSCHAr19HHc6 QsJyRR0vFWTk66lVJzapS0mzCwRjNcA/ov3R33chFEJGn8LNt5maXtHpmg6t5dZ1mmco Gp0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756718890; x=1757323690; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+OjBGQlc7KunvXiwW1dw+QKH2gYgV2aEjow/wpDnEig=; b=JFmGYwk0AIAKPsB+DufN2O1v+GMFYPL537COf2fYL/lCIJo76xnvJCgkJ1Z5iB8zLo o11X5Pg6ZFouke0PDsfCoq25ASnq6yabPzXLxTsQwyEZwG+9R/Rpr3zZb/EuRAS1N3UC TqX1MytmyQDvDNPoQcO3PsRnJuuJ7K4BmQvvbzcICc7LC47TFIyV4obV82qod+NH7ywU Fr2Tof9oSLjL7pkhuFcE+AH0F6R8qzDlcJ4k/3BDB5zws9u62ZRWjdq3mMw8oRFQxvQm D4ER/FHq9bti5nrFZFZ3Dq8MVks/jphj4qKHBlmeOqh5Sg9jCDhhWBm6ImWE+zmkMI+x vr4w== X-Forwarded-Encrypted: i=1; AJvYcCWMLRy4fVTrrEwE3p4QxQ9PswQ1mBTaCZj0Iq43xz1KphF6hQyy0jMh3zrkmJFx6JBNaywvy7CCLdA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzpQzQoYTemyUlRa/PioYcqfz4nmZluuifn1wW8rixPxgsgVluW Jo4Lz1ajG3aM0SBgabEO3kOxYPbJd7UoSWiIiR3peYh99D3Jd6/8ON4n8OLNM6QWlA== X-Gm-Gg: ASbGncsFU4+kQuuuSlm0nYzIJd5trU4NgMI+tbsBBgZ5iYPoSkadn8NzdX9cvdUfHJx hxPh9eQ0hmgeQLfVe6m1+ck/W2doA480zUZ3/HQamjt+hp/VY3Wj5EcqRWZJEL6rDDB+nk6n8HR jyoHf12fqTHKl8vZySZWzcPsXfnSsEXUXr/Z7O/BESCxot1qVFw4lYkorYx/s+t2JUc9p98ebC2 KxRvckj5c4x/5XC7qFzK5XPK52HdDkrC1HI76ARqXbSg2+Fpu7zSB6a4CHJIJ5y6rCh/cZSI+4A g+Gb9doazY0//Fd8QYOaMnCiHKA/fsVRovrg7OS9Qboci99jEpareBGiSRmuokj7lrhK+vSIrPn TyLR8iseHTI6m79Ab9yubEHvRolJFEnTa+plfAn+ytTfRRxouFAQk0iWI5mIkZEVdBziWzrFL9D uB0kvIf1I= X-Google-Smtp-Source: AGHT+IHiQ/0Lm+im6vjpmQ9jvZnfAn6DrtVUTVGU4Mr+trbWHg/8R4sAx/dhKeJSvsfWmZnDCd2veA== X-Received: by 2002:a17:907:9724:b0:b04:2727:1658 with SMTP id a640c23a62f3a-b0427273a1dmr363276766b.58.1756718890350; Mon, 01 Sep 2025 02:28:10 -0700 (PDT) Message-ID: <9322056d-9f09-4f5b-801b-6f0fdad5ead9@suse.com> Date: Mon, 1 Sep 2025 11:28:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/23] x86/boot: Use RSTORSSP to establish SSP To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-8-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: <20250828150409.901315-8-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void) > if ( cpu_has_xen_shstk ) > { > wrmsrl(MSR_S_CET, xen_msr_s_cet_value()); > - asm volatile ("setssbsy" ::: "memory"); > + > + /* > + * IDT and FRED differ by a Supervisor Token on the shadow stack, and > + * therefore by the value in MSR_PL0_SSP. Beside not being overly relevant here afaict, is this last part of the sentence actually correct? Patch 06 doesn't write different values into the MSR. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:30:52 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:30:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104285.1455369 (Exim 4.92) (envelope-from ) id 1ut0sF-0001dy-SE; Mon, 01 Sep 2025 09:30:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104285.1455369; Mon, 01 Sep 2025 09: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 1ut0sF-0001d7-Oz; Mon, 01 Sep 2025 09:30:51 +0000 Received: by outflank-mailman (input) for mailman id 1104285; Mon, 01 Sep 2025 09:30: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 1ut0sE-0001ce-7p for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:30:50 +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 5792df01-8716-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 11:30:47 +0200 (CEST) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-61cd3748c6dso8641455a12.3 for ; Mon, 01 Sep 2025 02:30: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 4fb4d7f45d1cf-61cfc1c77f9sm6754337a12.8.2025.09.01.02.30.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02:30: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: 5792df01-8716-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756719047; x=1757323847; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=IaXcjmf/0Q+GdMKnTc3tL7O2r66m6vT3aabUK3ohqn8=; b=AnT8H/zTD2OJuV+PPPnV3iXyXPnJhKzt6JLkFtF5B9EFp1A6fg7G1pr0EaJXxSAMg5 0IdQESB/pobbZ9WHtTqTl4aSQCV8UV7m0p4oml41W92d0kaQCZw644tzxFldiHRcJemI weJRTkbymGRruSsPRa8aT81hxlr1LOcAGiwFqGpOLSxBB51dTe/nR2YNjgCVP84Wo0Zq /k51XO1jiz7adv0rtIYsBSHXaeZvXni3J/XCtNdrC7KsG4Yq/hcPzEp8V6v8U0rT6elE kkhZdjTO7/aChWXDM89Vnq1vfku8H/8c8mFd1RuweiXXnIe7A5CoCdAmpaCfnPQtuZUC r2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756719047; x=1757323847; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IaXcjmf/0Q+GdMKnTc3tL7O2r66m6vT3aabUK3ohqn8=; b=d0/so/X+HPmzt8QmwOQErL6kpMXBN8lCVHvNTcRhYsovLpuZBXUvIFva6rJtNr9+on opgoePOwK2SBThQZ3ITrjRhXTE7OIERqjoSVsBTKchHaOarWHRL3OwENdIoahuRz6bSO gfTOjFmkeZM3Ns0HrxoPuBrFDb9DMDpIvC8CZBU3pp4XAMIPnxkwh1Zv35CaVYvCtGSV W/K+vL1ivGkRn9I2f5txKejdwADuXFctzFYKN8cLxsw32KeVL7FVm98MJrSyT5WJhaxr MvmzadYiTK06pzEfV/C4CkYjmIDNlotcYvx7K7pZgXRHtR4LcbEGtialfeASDYCmp6ip uktQ== X-Forwarded-Encrypted: i=1; AJvYcCU4mTX7s91RMPvciwyf5k2t6ArGlXVcYNF38jdz80L74F6Q4N51IWtZN3zUIP5qaiW0aMBPp7UdDDc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzhevjc11O+pzYo/iNSz1CN6MPZXB9oATf9Re+qB1j82MCFaVx/ hSG3i1NqCoFgVN6Yx8cK55KbIwuDahmVxrbPLeDuQvqeVQ8iCJeX9Ql/gBr0UhOXTQ== X-Gm-Gg: ASbGncuTPQHUoZj5tSd0C5UgYF9U3JUj4rd+Fvfffp9KcDj9Vb5Jzr/foyItfdVCQ0e lYzl4c0cDM/8yJDfOXuzEehRkaLNW5YPuVN1w/W3W7ljGA7+x77Qzi4akudz3iakp5cCxsQNdGo OcQOve8zRp3yqxl/1aqBWyEvMMCWParkI8oiVmtTIyTbUBfxqebZtzaKHaBqmJoGIr3vEG/zazf OIwQ+tgQDnx3dOADY+3pRyfWGvKcAHfx0zmD/0DA25j39jb5VMdu4rPfCSAE3zL5l0OAbrUGB9P KtAUOvZ9TEKetM7AgQEZplDD0jdGF63fGhz1Lw81kGnVfQrT/li/bcZebFqW0E/k0Zq3AILa6pw I5Xr0uKU5dPqWVomqiu9pWIVtbK9LGo1IfCz5wxW85gxLOWcjs9/a/CD9QKr3SRd5bIkD3NwEDU A1TmnHY+Y= X-Google-Smtp-Source: AGHT+IGZCQsOBUFGOYg3lNuz28258vHjy+8N9irWKsxr3M9Dh5h7RKiXzF1NXQJFDsmtSFNWzwRYqg== X-Received: by 2002:a05:6402:4308:b0:61c:7a9b:21d4 with SMTP id 4fb4d7f45d1cf-61d26c52672mr7197659a12.18.1756719047181; Mon, 01 Sep 2025 02:30:47 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 11:30:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/23] x86/traps: Alter switch_stack_and_jump() for FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-9-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250828150409.901315-9-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > FRED and IDT differ by a Supervisor Token on the base of the shstk. This > means that switch_stack_and_jump() needs to discard one extra word when FRED > is active. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich However, I'd much prefer if ... > --- a/xen/arch/x86/include/asm/current.h > +++ b/xen/arch/x86/include/asm/current.h > @@ -154,7 +154,9 @@ unsigned long get_stack_dump_bottom (unsigned long sp); > "rdsspd %[ssp];" \ > "cmp $1, %[ssp];" \ > "je .L_shstk_done.%=;" /* CET not active? Skip. */ \ > - "mov $%c[skstk_base], %[val];" \ > + ALTERNATIVE("mov $%c[skstk_base], %[val];", \ > + "mov $%c[skstk_base] + 8, %[val];", \ ... the unnecessarily complicated $%c here could be replaced by plain %. Jan > + X86_FEATURE_XEN_FRED) \ > "and $%c[stack_mask], %[ssp];" \ > "sub %[ssp], %[val];" \ > "shr $3, %[val];" \ From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:38:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:38:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104297.1455379 (Exim 4.92) (envelope-from ) id 1ut0zy-0002PT-Jw; Mon, 01 Sep 2025 09:38:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104297.1455379; Mon, 01 Sep 2025 09: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 1ut0zy-0002PM-HC; Mon, 01 Sep 2025 09:38:50 +0000 Received: by outflank-mailman (input) for mailman id 1104297; Mon, 01 Sep 2025 09:38: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 1ut0zx-0002PG-9T for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:38:49 +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 75f3a5f2-8717-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 11:38:48 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-61c26f3cf0dso6292835a12.1 for ; Mon, 01 Sep 2025 02:38: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 4fb4d7f45d1cf-61cfc4bbc9asm6800364a12.25.2025.09.01.02.38.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02:38: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: 75f3a5f2-8717-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756719528; x=1757324328; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=X8LlKiSqE8EFYbpZWwoVUZhPsnuckq0t875M4ppmnB8=; b=KtSzmaixTF/LWDvjC223kAa6xGyPVDlUIZDjkI0fnnQBAQbXIqeE8sJRvOdBD6nPOR ZLWcBoPGukfK3FtQc16tLtav3wZ8onWPPrbHLuHu/PBu6b/NnGLeWLJo/XhgKV4V2Wth DStpBrtocs5FQMfvq8jwEzuJtbHvsGTObNPgxbTi4L4Lp7DyJW+LPOGCqvUa6d3ltv0p SmY1wIQmmWI3Ps1cXpo1WR3/77o8PwuIxdPXWrKESqf6gxT9Em6fgNs+bMRu0UvhU8z9 d8FJnajgNG7v1alFFW1lZB7qiq2ltzFu3xWOxBDxC4hAHaPu9Hk98WLPb7Wkur9UNit6 Zrww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756719528; x=1757324328; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X8LlKiSqE8EFYbpZWwoVUZhPsnuckq0t875M4ppmnB8=; b=MGtGojR1ess5rCk7ZWJrZQmtwgDMejalLav8dHjcsvp/E9jyDQjRbA95Tk680XCwVo IWxlP71m+XEQgWczwiYW44bz13SJMLfeHvd9ZAo5gupD9hn0unwow1GokG/WgBf4z2bP IgK/LiWmOnNHmAbvYU0472eYfB85i8WDqTG4NN9tj3T0gmVwCCvf8BAmLVg60KX67LF0 MpGNRvDbsoZMgOIoNEH/FTa1RYrVP/OqePEK3a9fZ3BhIRBvFMv+ilOTjIz++hONKz/G w6heLWSZbFkaOhdfoWk2ZI2Ptq/YRNAZOL4mkGDsbvArGQKLHac8A3Bywv6yOfsZMPtv +keA== X-Forwarded-Encrypted: i=1; AJvYcCXxaqmCfw0UQQQAFh0eTtcDyJcpFwgHJICweZ8QTkZg7tQFTEDeR9owQW/2tnAJHFOTnom8n02YawA=@lists.xenproject.org X-Gm-Message-State: AOJu0YyIrZ8RRpb2ES63uDzrUeONLwbYCz2RFk3+feDct+0R48Qf/C08 87c/bloe+8O6fktP6rxVRP6/sPLFNDlKSsG7im6hVpHDodtTWD5c+7Dx2MDms1Jjtg== X-Gm-Gg: ASbGncspxVMZiHEq8329cweE9vbSRP04BJjIN9rjioxksmwE9TWcIExbdXgO2EkFmJX hFMzLmkYS7dkPhngWaEIbMzn+lRjJat0H4XR1Kp0osWk8bPCO/9xR6zAsm9yuFwvK/ozfOBBvuP gW16dAxIulwPoeEaYZfST3Z9W2UgSWZlAQPb8Th2pNzbmvoEZT5EpDR5PiU6G0Y4mg9Wt1aw01i iucH/EBIkjMaORKfMfK2jTlx5v8oNS9rvbju0ZKhyUigjmtcr6c5v6W3wJzZjYfWrvMzu9NvfBs 5ihBSMY1dUA3GrCYHXmdLcZjr8oaZ2IhyTlL3jMTpQoH4z7pShomqoVCOMqAsugpS2BuxAuqJOK cXhACVSnLIV5+rxS48ySxBfNyWiv6QYFcZ5GE05xu9oiktaA/nmq7TfVxkv0nVuY3tc6LNJ8y6p QSxdZQ4iw= X-Google-Smtp-Source: AGHT+IFmOz5s08wc9COxAKyznPeHwoEn51QwTGvYprLxJ/D2/8c9EMEeVxC3+7T5PfrmM7xMz3XEoQ== X-Received: by 2002:a05:6402:1e8f:b0:61c:931a:6cc1 with SMTP id 4fb4d7f45d1cf-61d2689312bmr7288086a12.13.1756719522533; Mon, 01 Sep 2025 02:38:42 -0700 (PDT) Message-ID: <77fd4eae-042f-40be-80d2-952b0f532dd9@suse.com> Date: Mon, 1 Sep 2025 11:38:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/23] x86/traps: Skip Supervisor Shadow Stack tokens in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-10-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250828150409.901315-10-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > FRED doesn't use Supervisor Shadow Stack tokens. Skip setting them up. > > Signed-off-by: Andrew Cooper In principle Reviewed-by: Jan Beulich However, ... > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1920,10 +1920,6 @@ void asmlinkage __init noreturn __start_xen(void) > > system_state = SYS_STATE_boot; > > - bsp_stack = cpu_alloc_stack(0); > - if ( !bsp_stack ) > - panic("No memory for BSP stack\n"); > - > console_init_ring(); > vesa_init(); > > @@ -2077,6 +2073,10 @@ void asmlinkage __init noreturn __start_xen(void) > > traps_init(); /* Needs stubs allocated. */ > > + bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ > + if ( !bsp_stack ) > + panic("No memory for BSP stack\n"); ... while this is the earliest possible point now, can we please consider moving it yet further down? E.g. next to the setting of system_state to SYS_STATE_smp_boot, i.e. in particular past IRQ and spin-debug enabling? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:41:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:41:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104308.1455388 (Exim 4.92) (envelope-from ) id 1ut12h-00045j-0G; Mon, 01 Sep 2025 09:41:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104308.1455388; Mon, 01 Sep 2025 09: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 1ut12g-00045c-Te; Mon, 01 Sep 2025 09:41:38 +0000 Received: by outflank-mailman (input) for mailman id 1104308; Mon, 01 Sep 2025 09:41: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 1ut12g-00045W-B4 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:41:38 +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 dab64b64-8717-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 11:41:37 +0200 (CEST) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-afcb7ae31caso793060966b.3 for ; Mon, 01 Sep 2025 02:41: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 a640c23a62f3a-b040a410817sm471886466b.101.2025.09.01.02.41.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02:41: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: dab64b64-8717-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756719697; x=1757324497; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=4+BM3Xhn1MZ492LnnsElsyd9BhW7vSGWsjJA7PcFLak=; b=RvTm5Dn27oB4nk+P4UPJrua25ud2csw6ceSVLD9VSWwhBtNpT8Atd/RaW40wzhiWoe Cfv5zkKAK4nxRR2C3REIpHPvZRgYv71lGhwdmC6SCXcLIo9MYNaDcq/dIqpe0WnfPQ+z B42ClVLZeiGZdegE5pzhkh3+skGbCSKcQpOp21/u+HHdklw+ZvSWeAOvgNoyf3duYNN9 g4TJ6iv6LFKNuoAWc+zxkVau7rtzUtu698CXU8sWukulPhB+9oqpw4uAu9MOeUCY1YOJ k7Thhy2ozbaKfyLT1DS56p5rH4EVw9HG23b9ikUewvTn5Up1HCE38bDTv0RLGLPmN3zD 3ozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756719697; x=1757324497; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4+BM3Xhn1MZ492LnnsElsyd9BhW7vSGWsjJA7PcFLak=; b=xF9OLs8eG6G84xO18zVg6qHQ6PEtDTdhjefp08oMYS0MmrUxzsTuq2Ztf3oZ7hxRKN vQ6v7tTLPuamcQ/6AmWfPV1ZAkwfNY3dvolpzsZHAUUOKP2DnyX3YebN2dvn8ej5CtwY VEDV26sWrw77QHUvfIOH4hp7jnxBM/38fJfbJsYKm0R6W8O3jrTcjjwS//f8TviSby4P GpBX8j2FfMjnvH33rJ1EK4+mA+rfcH4sWrJQ8vY6vdneVMTfIHETUxYNJgXblC9gSDwq 31ZTZzp2KEVGRFJmYzZ2btVLk0SRSKtORD2cXb40ZGt+Txops/0Yuw0DBLja6n/UUvZZ Lo7Q== X-Forwarded-Encrypted: i=1; AJvYcCXytbaQVOADsueGZIsEXTeC+U6M2dX9wBENNnFRrnXPXgZB7C2hEAVW2/3QnTcFHnNbnk0ofT8TEOs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyemssz9fM99SZ7x0m/yD060epzbQXyHMo69XTSIST0KOFDH62s xVOS3z0gdRcUYrGhhA4O6U7D0Uj35kfVz57YBlgn2hH7GuUMMgV0M9sE0rVjN8hxRQ== X-Gm-Gg: ASbGncupHSiJ7n8LWPhIfxTM/98O7aglmcMRZP80KFAvOIxoT4FM9Vu/fkY/HqhAEHk Y5253FYQS9JbF+x0TZIOom3bXu44TtcAlsN4El5XyyENX+YqfQx30iJoK04/b4BegE1L9Yfr8T7 loxENvbUqOiySfTqsyh/7qOv2J4OL0GfqVj2vjPFm0p/ELguX1BUbzwDzUSHVgPYU/tTsDOHGJD OY+Fx84+DwQ85tcLEldmehobtmaigXfpKBBKXc1fsFOZzTP/Kt0I+28mJUEEcRyaOtA5qkKNLjV m0TolkUT6zVr/lprBFMF9/Adan841av+O/sxqHDLWauX5Ocr33//fTZnhyyWpTVQSV9Yz+1U7GH hX+2YyFTkfxfYTSPgmXIEry+iFlIiu/EJT6k3UpyLp2+YL6dwbEKUOJsOsx0a4/T8lXrAE6fC1X swS5btzR7MXbS81ZHPog== X-Google-Smtp-Source: AGHT+IEEuXg2lLbJFkKz8+oBt/XPgCrpzq2VIfhpdTMd4tcNtC3jBqZim2TzIv98B+Q8+J0K86H3cw== X-Received: by 2002:a17:907:3f8d:b0:afe:b827:ca0b with SMTP id a640c23a62f3a-b01d8a25c5emr757780366b.10.1756719696662; Mon, 01 Sep 2025 02:41:36 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 11:41:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/23] x86/traps: Make an IDT-specific #DB helper To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-11-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: <20250828150409.901315-11-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > FRED provides PENDING_DBG in the the stack frame, avoiding the need to read > %dr6 manually. > > Rename do_debug() to handle_DB(), and update it to take a dbg field using > positive polarity. > > Introduce a new handle_DB_IDT() which reads %dr6. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:47:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:47:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104320.1455400 (Exim 4.92) (envelope-from ) id 1ut17s-0004fP-Kb; Mon, 01 Sep 2025 09:47:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104320.1455400; Mon, 01 Sep 2025 09:47:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut17s-0004fI-GA; Mon, 01 Sep 2025 09:47:00 +0000 Received: by outflank-mailman (input) for mailman id 1104320; Mon, 01 Sep 2025 09:46: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 1ut17r-0004fC-Gf for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:46:59 +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 9a39f5d0-8718-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 11:46:58 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b042cc3953cso88966266b.2 for ; Mon, 01 Sep 2025 02:46: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 a640c23a62f3a-aff138a8d76sm647187766b.104.2025.09.01.02.46.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02:46: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: 9a39f5d0-8718-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756720018; x=1757324818; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=BJ6F+aQyVrvB/LlVapH5CK/OgUF5efu6JGzji+l4emg=; b=MGaujecAORP0G3YzR4L3JOYBhGTiVBBdDnzWby7Crwrp/YcO3V69FX3RFo7ukFthQV VjEwJH4iONw+/+Cr7sgmAw0EwJiPEz8BE2GUwt/+k6/aJNcc7cYf6f2UmUZSXggRXqWt EJe6O4lEJVGGr4tOhj03KAM5+oJNiO03kmJe7CUk7q26BxPp8J37AwhP7pyTV+8ARr2L YugH+OaEc2itjQkv8lbsCuf1OOJQG2WPJ9ae1HHbc4ZNa1inkH9en4PyhMGJTjAR4ZgO QC9z2A890P3Is81VU++WlkbWoikAlTLRDSAb2baSor5cRpr4xRpdRHmMbQ3391gcSOiq rfDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756720018; x=1757324818; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BJ6F+aQyVrvB/LlVapH5CK/OgUF5efu6JGzji+l4emg=; b=pitHVQfTQvqO8lz/2hp+plihEidQvmF2OSd/PyQswsOaQBzpm/dfdZtknVvX+suYdV pWeMozPB9YurD7WAyXWewfAnISeAvWOPyfsGxm5GvTm7KH8RuAhI7klN8RP5rTl6OCWG Vhckm6l01PCg/i6Bl0L0U1MeByhlAK2/MPv1a4rdc+sfdKeb2awDwHqrdxLHMS7a8mCn SYRxcG5/6IvQA2KE7hetFWUaCWE2xbiv5vvhqi0vzGSq1CqNVzXvKXU67voZ7F6x9GbO tcAvnDSRT8pFfcKgS9P638818NfpiE+xB3DH9CN7/IBW3dgoknZF5eoecawv7SLOMtZN HS/w== X-Forwarded-Encrypted: i=1; AJvYcCV2FlZv5JNe7MBQh5wUYir3SO6AtAFjc0cL6WCicPr/Efo+5WywOSs0RZn0gBm8Inhnz0qcGptg8Eg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzbGU0HN89KgVnoUD0XTTXH243ICtqbRGr161EMFb9xkWnKv55O x32DBie6ag2032JWlzFXk/Id4+5XEQinbmSvPHQXfo5cEAO9eMxLpmDFjvnDa5CfM9YLJeAe/+P o654= X-Gm-Gg: ASbGnctnP6RmQIAp/HoGLN2on77Sdsur9R0WQjkgAhJVkVa66vLkFPV5cGtKEWFfXnx lUuTYXbJ4vtEYHxY4b+OJ92eQ7nj86nbk2DvS2S21RxvxAC2hiEX7+R3+5KuJI+qWN1PBmmkn21 o1KbDcwyJfCYX7VBsVz5PZN5q9x64W+gteGquWAgRr5RCzLFexzd3CiPwwNw08wE3sJddP1gAgq tZSktKJNPqX4WX/R6gTMRmlXlvlymyna3i0FM8Ue8C4merPAnyvc2x/oSU/imiUjey4bce0AqLp zfd9hv05mgKnTIKjQwONGS4uE0DhsBPbzWya8zOyYTeoEikTvR8ZX6vu8q9qUNWjGOp7WdgWdq6 Oi1KEO/sdsSh1I9gG4wu10lT50px+9EY8BlnVitHaSEVxRJQ9EXpxjxKOWZLD3jOt5IlM6IOYbU 9HkmbTmEIG7tDzJcxfGQ== X-Google-Smtp-Source: AGHT+IH8eX6qnIh209AHzFZ3trUjBXKVMsxN9lYxZIjEyfq2IwOrd1qwbTCWFSQiMHckd1LD7djbPQ== X-Received: by 2002:a17:906:c142:b0:afe:bb6d:1caf with SMTP id a640c23a62f3a-b01f20fbb68mr777004266b.62.1756720017988; Mon, 01 Sep 2025 02:46:57 -0700 (PDT) Message-ID: <5c0cb015-b2e7-467d-9c1f-2314bcb66ad6@suse.com> Date: Mon, 1 Sep 2025 11:46:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/23] x86/traps: Make an IDT-specific #PF helper To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-12-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: <20250828150409.901315-12-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2 > manually. > > Rename do_page_fault() to handle_PF(), and update it to take cr2, still named > addr for consistency. > > Introduce a new handle_PF_IDT() which reads %cr2 and conditionally re-enables > interrupts. Why does this IRQ-re-enabling move to the IDT-specific function? Do you intend to do the re-enabling yet earlier in FRED mode? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 09:57:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 09:57:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104331.1455409 (Exim 4.92) (envelope-from ) id 1ut1II-0006V8-Fl; Mon, 01 Sep 2025 09:57:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104331.1455409; Mon, 01 Sep 2025 09:57:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut1II-0006V1-C3; Mon, 01 Sep 2025 09:57:46 +0000 Received: by outflank-mailman (input) for mailman id 1104331; Mon, 01 Sep 2025 09:57:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut1IH-0006Uv-6j for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 09:57:45 +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 19b821ae-871a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 11:57:42 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-61d7b2ec241so1429836a12.0 for ; Mon, 01 Sep 2025 02:57: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 a640c23a62f3a-b042523ee7bsm258182866b.109.2025.09.01.02.57.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 02:57: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: 19b821ae-871a-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756720661; x=1757325461; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=pU65rmAaobHA8x69X+0kKwQR+vRAMw8j3gzJNvgCIdQ=; b=PUSWLrt2QAmMR6GUZhngzNpgI5xXb1vuyFqWaGxM5K/M07zVMfewmPMoCcriT6riZU I5NMisOj865NF3pOi6u9T3Q3n8MTpqj+sLUe9ExTYJnp0KiZI8fEKlF2mMps6tyy4KDn eBVJRt1fIR0755oA0PuPGaCNF2f6wgdPxwFFQGTFMXAJyJ7zLMJNhOvrwIqIRivfKHAW HsIgADKOXuiIC5/ULrR1mdp06XVGGYmHjHDuM1xKbIXb/G9ZvGa1PSl+rOqxcrsFGIGj VvCAndFYeaULnJyVnTE498a6zrg4yEVtZ/CYhCDcx+nNnk1rxRX+T1T3A/w4SGQ56U++ k8pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756720661; x=1757325461; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pU65rmAaobHA8x69X+0kKwQR+vRAMw8j3gzJNvgCIdQ=; b=WbX5jkBCBOuHV/NjTRetpMELORe+FpA2zOkjWOFU7GtgM0OWCi0lw0MMCNp5Yph66k hjoKv5onQ0CzLf5HsrZIDX43lcTiLwFrg78E6AoLcrqZMpvEFrpwxoW6FcU0+LVnHa2i W0JEVIWfosHery1AAKGbi7BXvN3/rt07V1KFuM921zic7cnw26UOBpVwf6NevzQ9uHz2 l+ipqRkFT8yrsUc2m6i6RZmPsQCHVedLcmKGKVUQUQHmxaez3GdKUJsnGax1dCOI4MlA zygMaBYmBb3Ia6FJ5xRTxFL4LvdfNkczbEIk+IhjpgfEBuealfPMdjylPljxkIzUk4Gt +GoQ== X-Forwarded-Encrypted: i=1; AJvYcCUJ0Ek0qpZHwcZhuFnzqe43kbgIH3NxvkGV0uJOEVl/9gqigIeXx/GyvhLHABIvppq7i10Ie5/hFHg=@lists.xenproject.org X-Gm-Message-State: AOJu0YypQbccqu4juHUMQHGQ2MSu3dxZx9Ztvn6ITAKCCp7lUzm15HrS fvqcPy+9ExP69l66H5zU8Np+5TlsHSmVVSf3uEWY426fgnk73S4fXxVeksBf8TSChg== X-Gm-Gg: ASbGncvjakvUumyH6LTlbcx19TaP58Z3mLsuakE/uU8w2OikG8W0OGzsAqU2SGoWCw+ DEWal2Z53ejB42DjDcy5o0EqJs01my2gG+IQui2MsB/LxVL+7Q8N/yNX3jkq1lK3SFJa8hvWHmu fnzffMK4dp7RcflYhCkOpCwOEQqclWrJwDG+NoDAmlcHMK115A3XVCy6AGWp5UefrWCOyJFTR6A m9wLr2ftx3ncezwk3L+DDUg/0yzne7yjwBaLuuQ9IkJ+lNNIOPQs6eZ8GsF0sr0PaN6fTg/9yd0 elCp/COi9vqSB84b4v5TOrSqtzKE+dhSmbh12olChw8Yb77MB9gvQLVs8SDdyqg74FcYVffGLt/ mk+bgZCtdSlkxcMGG2gUn9BKb/laEoCIyXrvxz31hrNzjeSY30zzxjykPbkUy7xCHJPdeQLFN31 PE6IoY/Bs= X-Google-Smtp-Source: AGHT+IH9y266uEc0OQSIklQ1ZdCiFKtfc1GGMGPzcTpVt/My/pk0tjiMMdeUQYFQgDodt6cyHKwuCw== X-Received: by 2002:a17:907:7250:b0:b04:35c3:40b3 with SMTP id a640c23a62f3a-b0435c3438amr168607166b.15.1756720661409; Mon, 01 Sep 2025 02:57:41 -0700 (PDT) Message-ID: <705a9429-4266-41a1-a5a7-0e3a58bf895d@suse.com> Date: Mon, 1 Sep 2025 11:57:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/23] x86/fsgsbase: Make gskern accesses safe under FRED To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-13-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: <20250828150409.901315-13-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > In principle, the following can also be used for read_registers() > > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c > index 5799770a2f71..0b0fdf2c5ac4 100644 > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -125,16 +125,21 @@ static void read_registers(struct extra_state *state) > state->cr3 = read_cr3(); > state->cr4 = read_cr4(); > > - if ( !(state->cr4 & X86_CR4_FRED) && (state->cr4 & X86_CR4_FSGSBASE) ) > + if ( state->cr4 & X86_CR4_FSGSBASE ) > { > state->fsb = __rdfsbase(); > state->gsb = __rdgsbase(); > + > + if ( state->cr4 & X86_CR4_FRED ) > + goto gskern_fred; > + > state->gss = __rdgskern(); I'm irritated by this patch context here vs ... > --- a/xen/arch/x86/include/asm/fsgsbase.h > +++ b/xen/arch/x86/include/asm/fsgsbase.h > @@ -79,7 +79,9 @@ static inline unsigned long read_gs_base(void) > > static inline unsigned long read_gs_shadow(void) > { > - if ( read_cr4() & X86_CR4_FSGSBASE ) > + unsigned long cr4 = read_cr4(); > + > + if ( !(cr4 & X86_CR4_FRED) && (cr4 & X86_CR4_FSGSBASE) ) > return __rdgs_shadow(); ... the one here. Was the former (and the subject of the patch) not updated yet (kern => shadow)? On the assumption that that's what has happened, and hence preferably with the subject also adjusted Reviewed-by: Jan Beulich As to the alternative, I in particular don't overly like the goto there. I would consider that an option only if in turn a simplification elsewhere resulted. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 10:27:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 10:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104354.1455420 (Exim 4.92) (envelope-from ) id 1ut1kZ-0002VP-QM; Mon, 01 Sep 2025 10:26:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104354.1455420; Mon, 01 Sep 2025 10:26: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 1ut1kZ-0002VI-MK; Mon, 01 Sep 2025 10:26:59 +0000 Received: by outflank-mailman (input) for mailman id 1104354; Mon, 01 Sep 2025 10:26: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 1ut1kX-0002V7-SX for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 10:26:57 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2f1a14b4-871e-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 12:26:56 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-61e8fdfd9b4so1889428a12.1 for ; Mon, 01 Sep 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 4fb4d7f45d1cf-61cfc52ade4sm6828255a12.45.2025.09.01.03.26.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 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: 2f1a14b4-871e-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756722415; x=1757327215; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=dS1NCKWWtcvvZHGl5IR+vSVQ2+EnVmtty+0c30l9Cgg=; b=Lo1PU8yLenMCCMa6vuH/sJptntDSdeQrc6Klnxg3zl3vgD+772goQ4i0HF1bhq9wgz 8an8eQO4EHfJAd2oYaKfmjTPtGQtfic41DqHrf5uzlkSBGJGlZ+LVtOf4lXdxZg1AxNU BAC+0Z3q3krb3YphlvN/HlBybONnjQQLyys64QPhJX5Jmf5m0qxVUdn7cldV2G9D3snd LHkU/YDuj1Qll5WRtxoXznK2ftH8TFFdPSCPbdiXwwFofaxgMTg8nb3XocfZj5bSZ90J XClniP263pAX2yCqlqxib5oWb8b0RipLZkKZZez6eTIQRlyTDsGprXjrwrr7OhfKJ4vc 7vnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756722415; x=1757327215; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dS1NCKWWtcvvZHGl5IR+vSVQ2+EnVmtty+0c30l9Cgg=; b=oSy/pkywy7I4Zo2Wh+mgp9BY6v5JjSV16h6uWG29i5oFacQ4MAY58OeEmvwEgRif9c tNFW9SVjv4hX4XQLGOWSftHm3lITmSp99NVkmO5Dtl0OGI8eQVdVtdO3Bmk2RERzUvax m/NJarrH1ubBjgjMLzR0emSsxeMxaujFNfdHa46mGcfmLn9htbsox9bK2jCNSXwzZIj5 y2RbqVbl91IjQjtLRALH8P9vDyHJo+u1hZPwKzN853UoBN5n8uX7mZTd/1ti571YUIID 166wXxHL3wqM+pq9WdDIi3ALzkjjN8AdUlQHi2zzSty7Qtr6WXhlm6TkID5A2kbJPuAW rxZg== X-Forwarded-Encrypted: i=1; AJvYcCXEdeSpMd7Cr4vS9r4r9BaRZHHdMVzandOduig+uhXG7Wv0cot8jHAAdQJN7Mt3ayl6qf6vO0ciPyw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzlBCDYGFD9BcsPYxaC4C2FSB7cuF5S9O5ucviu6V7FkQ1eTYFN CvfgdcH2Xx6+3afaQAtADJI7zpD17+r7smRvOqfJU9rQTECnIXfxqHHILoSVSjAeD+fgBNKQdIi hLM0= X-Gm-Gg: ASbGncvXd/IZYzGjaTSPvNQIM+kWlDB8uPBkEdsZ62mWESUGUWVVeZwhCE9PxqDR3Ar g+6xEhZdZ8CIbOF6XfB+t68qvbfMbuUrAiX6eeyPiXx/kq1WAXovuvZeICAb46xNyjbHo6ha14t +6tzMiTn/Ljux5xopvo7WUILU+r3LlUQj+SXwuk3dpgdaXsPnHoudeb7Ld64nY9Lv9v50O5dklc ylf9EAcfyt1YjeEjJndrQmQnreNZJtNvYJZfnYpCvQy6dRLs2qAEsjVtZN7LzYRWDXnKTh3Uzor tzZYtwmCvj49x1o9ebm/P9XAr3AMELhRISkII21vOUnA2/aaBEyITDM8f+23+JRYuCEBD4qM7BM 6CzeVeG2oBWloAka0tu34gxaEE5+E609fkOia6+NTNcQm2fTRQXOGzbtOO92yC7Ojxh4t7R6BYv QHaMgvtl5Zl9PJJtoJ6g== X-Google-Smtp-Source: AGHT+IFGdLcKcOZbOrvQRX/+x15X7GNdCt8kzppE6eEBhyatVDokfCm83RELqL67XUWLH+XhaYm9wA== X-Received: by 2002:a05:6402:848:b0:61c:e28a:aa9b with SMTP id 4fb4d7f45d1cf-61d2699a122mr6896754a12.7.1756722415176; Mon, 01 Sep 2025 03:26:55 -0700 (PDT) Message-ID: <2482792a-f4c6-47d4-87ee-d400549a1f1c@suse.com> Date: Mon, 1 Sep 2025 12:26:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 13/23] x86/traps: Introduce FRED entrypoints To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-14-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250828150409.901315-14-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > Under FRED, there's one entrypoint from Ring 3, and one from Ring 0. > > FRED gives us a good stack (even for SYSCALL/SYSENTER), and a unified event > frame on the stack, meaing that all software needs to do is spill the GPRs > with a line of PUSHes. Introduce PUSH_AND_CLEAR_GPRS and POP_GPRS for this > purpose. > > Introduce entry_FRED_R0() which to a first appoximation is complete for all > event handling within Xen. > > entry_FRED_R0() needs deriving from entry_FRED_R3(), so introduce a basic > handler. There is more work required to make the return-to-guest path work > under FRED, so leave a BUG clearly in place. > > Also introduce entry_from_{xen,pv}() to be the C level handlers. By simply > copying regs->fred_ss.vector into regs->entry_vector, we can reuse all the > existing fault handlers. > > Extend fatal_trap() to render the event type, including by name, when FRED is > active. This is slightly complicated, because X86_ET_OTHER must not use > vector_name() or SYSCALL and SYSENTER get rendered as #BP and #DB. Also, > {read,write}_gs_shadow() needs modifying to avoid the SWAPGS instruction, > which is disallowed in FRED mode. This last sentence looks to be stale now. > --- a/xen/arch/x86/include/asm/asm_defns.h > +++ b/xen/arch/x86/include/asm/asm_defns.h > @@ -315,6 +315,71 @@ static always_inline void stac(void) > subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp > .endm > > +/* > + * Push and clear GPRs > + */ > +.macro PUSH_AND_CLEAR_GPRS > + push %rdi > + xor %edi, %edi > + push %rsi > + xor %esi, %esi > + push %rdx > + xor %edx, %edx > + push %rcx > + xor %ecx, %ecx > + push %rax > + xor %eax, %eax > + push %r8 > + xor %r8d, %r8d > + push %r9 > + xor %r9d, %r9d > + push %r10 > + xor %r10d, %r10d > + push %r11 > + xor %r11d, %r11d > + push %rbx > + xor %ebx, %ebx > + push %rbp > +#ifdef CONFIG_FRAME_POINTER > +/* Indicate special exception stack frame by inverting the frame pointer. */ > + mov %rsp, %rbp > + notq %rbp > +#else > + xor %ebp, %ebp > +#endif > + push %r12 > + xor %r12d, %r12d > + push %r13 > + xor %r13d, %r13d > + push %r14 > + xor %r14d, %r14d > + push %r15 > + xor %r15d, %r15d > +.endm > + > +/* > + * POP GPRs from a UREGS_* frame on the stack. Does not modify flags. > + * > + * @rax: Alternative destination for the %rax value on the stack. > + */ > +.macro POP_GPRS rax=%rax The parameter isn't really needed, at least not just yet. Do you have firm plans for using it (presumably in the SVM code ahead of VMRUN)? Else I'd suggest to omit it, as it's fragile anyway: One can't use an arbitrary register for it; only ... > + pop %r15 > + pop %r14 > + pop %r13 > + pop %r12 > + pop %rbp > + pop %rbx > + pop %r11 > + pop %r10 > + pop %r9 > + pop %r8 > + pop \rax > + pop %rcx > + pop %rdx > + pop %rsi > + pop %rdi ... the ones POPed later are candidates. Their order isn't really visible at use sites of the macro, though. (A possibility would be to indicate via argument only _that_ the %rax slot wants discarding, without indicating by use of which register.) > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -89,6 +89,13 @@ const unsigned int nmi_cpu; > #define stack_words_per_line 4 > #define ESP_BEFORE_EXCEPTION(regs) ((unsigned long *)(regs)->rsp) > > +/* Only valid to use when FRED is active. */ > +static inline struct fred_info *cpu_regs_fred_info(struct cpu_user_regs *regs) > +{ > + ASSERT(read_cr4() & X86_CR4_FRED); > + return (void *)(regs + 1); Maybe better &container_of(regs, struct cpu_info, guest_cpu_user_regs)->_fred; ? > @@ -1101,9 +1134,41 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote) > } > } > > - panic("FATAL TRAP: vec %u, %s[%04x]%s\n", > - trapnr, vector_name(trapnr), regs->error_code, > - (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT"); > + if ( read_cr4() & X86_CR4_FRED ) > + { > + bool render_ec = false; > + const char *vec_name = NULL; > + > + switch ( regs->fred_ss.type ) > + { > + case X86_ET_HW_EXC: > + case X86_ET_PRIV_SW_EXC: > + case X86_ET_SW_EXC: > + render_ec = true; > + vec_name = vector_name(regs->fred_ss.vector); > + break; > + > + case X86_ET_OTHER: > + vec_name = x86_et_other_name(regs->fred_ss.vector); > + break; > + } > + > + if ( render_ec ) > + panic("Fatal TRAP: type %u, %s, vec %u, %s[%04x]%s\n", Is it deliberate that here and ... > + regs->fred_ss.type, x86_et_name(regs->fred_ss.type), > + regs->fred_ss.vector, vec_name ?: "", > + regs->error_code, > + (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT"); > + else > + panic("Fatal TRAP: type %u, %s, vec %u, %s%s\n", .. here it's "Fatal", when .... > + regs->fred_ss.type, x86_et_name(regs->fred_ss.type), > + regs->fred_ss.vector, vec_name ?: "", > + (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT"); > + } > + else > + panic("FATAL TRAP: vec %u, %s[%04x]%s\n", ... here it's "FATAL"? (Personally I prefer the all capitals form.) > + trapnr, vector_name(trapnr), regs->error_code, > + (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT"); Just as a remark (the "else" thing still needs sorting) - without "else" this would be a smaller diff. > @@ -2198,6 +2263,94 @@ void asmlinkage check_ist_exit(const struct cpu_user_regs *regs, bool ist_exit) > } > #endif > > +void asmlinkage entry_from_pv(struct cpu_user_regs *regs) > +{ > + /* Copy fred_ss.vector into entry_vector as IDT delivery would have done. */ > + regs->entry_vector = regs->fred_ss.vector; > + > + fatal_trap(regs, false); > +} > + > +void asmlinkage entry_from_xen(struct cpu_user_regs *regs) > +{ > + struct fred_info *fi = cpu_regs_fred_info(regs); > + uint8_t type = regs->fred_ss.type; > + > + /* Copy fred_ss.vector into entry_vector as IDT delivery would have done. */ > + regs->entry_vector = regs->fred_ss.vector; > + > + /* > + * First, handle the asynchronous or fatal events. These are either > + * unrelated to the interrupted context, or may not have valid context > + * recorded, and all have special rules on how/whether to re-enable IRQs. > + */ > + switch ( type ) > + { > + case X86_ET_EXT_INTR: > + return do_IRQ(regs); > + > + case X86_ET_NMI: > + return do_nmi(regs); > + > + case X86_ET_HW_EXC: > + switch ( regs->fred_ss.vector ) > + { > + case X86_EXC_DF: return do_double_fault(regs); > + case X86_EXC_MC: return do_machine_check(regs); > + } > + break; > + } > + > + /* > + * With the asynchronous events handled, what remains are the synchronous > + * ones. If we interrupted an IRQs-on region, we should re-enable IRQs > + * now; for #PF and #DB, %cr2 and %dr6 are on the stack in edata. > + */ > + if ( regs->eflags & X86_EFLAGS_IF ) > + local_irq_enable(); Ah yes, here we go (as to my question on an earlier patch). > + switch ( type ) > + { > + case X86_ET_HW_EXC: > + case X86_ET_PRIV_SW_EXC: > + case X86_ET_SW_EXC: > + switch ( regs->fred_ss.vector ) > + { > + case X86_EXC_PF: handle_PF(regs, fi->edata); break; > + case X86_EXC_GP: do_general_protection(regs); break; > + case X86_EXC_UD: do_invalid_op(regs); break; > + case X86_EXC_NM: do_device_not_available(regs); break; > + case X86_EXC_BP: do_int3(regs); break; > + case X86_EXC_DB: handle_DB(regs, fi->edata); break; > + > + case X86_EXC_DE: > + case X86_EXC_OF: > + case X86_EXC_BR: > + case X86_EXC_NP: > + case X86_EXC_SS: > + case X86_EXC_MF: > + case X86_EXC_AC: > + case X86_EXC_XM: > + do_trap(regs); > + break; > + > + case X86_EXC_CP: do_entry_CP(regs); break; Any reason this isn't grouped with the other single-line cases? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 10:31:52 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 10:31:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104366.1455429 (Exim 4.92) (envelope-from ) id 1ut1pH-00046W-AG; Mon, 01 Sep 2025 10:31:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104366.1455429; Mon, 01 Sep 2025 10: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 1ut1pH-00046P-7H; Mon, 01 Sep 2025 10:31:51 +0000 Received: by outflank-mailman (input) for mailman id 1104366; Mon, 01 Sep 2025 10:31: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 1ut1pF-00046H-VD for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 10:31:49 +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 dc1741ae-871e-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 12:31:46 +0200 (CEST) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-45b8b25296fso7410575e9.2 for ; Mon, 01 Sep 2025 03:31:46 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d1007c0dc8sm12972951f8f.53.2025.09.01.03.31.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 03:31: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: dc1741ae-871e-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756722705; x=1757327505; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=j4fbMJxhEnVLNeXUWTq3A4N+0cy9j/7NLgsbma3pM/s=; b=bH/FGuL0ygc6vJSRBd2LlxO+UbfJzWSN0VqqDBQzD70ETg8UegajPwJJq1N74ScGL2 gZKjlzAviQkY9KKxqOXxWkv7anZhLn2X3cFu/2uNkE3lHpwRk2pYjzpkK1OVn5p1a6fR 4a0O3Z3eYXDb4g72E5xTw1FGl/5l+mmZD5c7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756722705; x=1757327505; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j4fbMJxhEnVLNeXUWTq3A4N+0cy9j/7NLgsbma3pM/s=; b=X2S6nqzB++MSiI72/cJFzjgHMTVnAAJFoRoE4vK0Gxqcvp8+qL1azz6jxtNheguo3f KMgVlIPAiLFRKBStCHf2B2S7huBIuxrumslLmZGJDIAvs+d9koQQDHuuNsb0CRX2FppH X7b05UYCcXu7QH89LMVprK57csWmolbl+RSaRPxTdeAZI4WFNdfz2/D8fY2Z4KvGjihk cOPbi9ZK/BAWNPyVfZIqjZSOMGQ/xbWn9NB6u1qig6cKchDlwXb8J3/PqhpTZOHZFu9X 9t6M7QXfaO5BvfHbCA+yyuQpGzMWcnJHdQATarJ7JUiEOs+rdO3jwOFTCKejsje80j+Q oybQ== X-Forwarded-Encrypted: i=1; AJvYcCUI+K+j15UKMoxpJ9usae2CpyClnmWfjCeYYf/SihS58sAoeLbc4Kzxt3lLVfoKT2to2dOOly25eA8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzmITBW/r3mR4RZqlZvB3mf5Gf2jybQpsxbax65rkBGVv51zjYO 9cDKGHkTv6StJJntolDylH+UeAyFXXMPIYQJb3eEbIVQ8F1PE+8n/j7OQt6Am7FYC2I= X-Gm-Gg: ASbGncuUdgVZvlxpGDNXjhJ5KX0TwFC/qFeR8OsXlKLwTEQYtyid4Bb+lF1o3g6eOta s8HlEVQRi5wKkdQag9NWHdLMSDUVL69OB0RdH8XbAvMhQK+0I5S7t3EkOLqsYhqsLZKqj56oiqo Rz0x0GKwCjZ8FnPvZKFwnLOqVq1q7JfS+PMUqlHA9Dzfyagf54W77PWOlt9fG06mMNU26PzC4JZ qLK+m2DwZ0L5FqPpE8TTSj/i18U46f7gFVQqAoBt7j62WsMdJ1Mn3lx8GDZXbrH+kKWUzULyAb6 l+5ARcKROcF9lMcJ4nl1iHiu/ECmnuYA6xRJoLv0/ATTuUftSxlolF9Z7oRU5apNPK79bvjfDnH NL1EAzRAnve4DFzJrWH0pdk4qhOq2j264a3MLT2Hm2BEPlw39LzHkm00N6+nDmfClufQO X-Google-Smtp-Source: AGHT+IEzkC3+e8h3gsYFdQl39t76m67r0oye+atJroen5P18oppKpf41P+GDIdmhtiLHSUaafNaPqA== X-Received: by 2002:a05:600c:4747:b0:45b:8f11:8de0 with SMTP id 5b1f17b1804b1-45b8f118f42mr14993405e9.5.1756722705405; Mon, 01 Sep 2025 03:31:45 -0700 (PDT) Message-ID: <327eb40c-8fcb-42dc-a0b2-3b756a566b23@citrix.com> Date: Mon, 1 Sep 2025 11:31:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/gen-cpuid: correct cycle detection To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <41ba214a-6137-4d8f-9f4f-3a362940d8a8@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: <41ba214a-6137-4d8f-9f4f-3a362940d8a8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/09/2025 9:56 am, Jan Beulich wrote: > With the processing done linearly (rather than recursively), checking > whether any of the features was previously seen is wrong: That would > e.g. trigger for this simple set of dependencies > > X: [A, B] > A: [C] > B: [C] > > (observed in reality when making AMX-AVX512 dependent upon both > AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list > of dependents). But checking the whole accumulated set also isn't > necessary - just checking the feature we're processing dependents of is > sufficient. We may detect a cycle later that way, but we still will > detect it. What we need to avoid is adding a feature again when we've > already seen it. > > As a result, seeding "seen[]" with "feat" isn't necessary anymore. > > Fixes: fe4408d180f4 ("xen/x86: Generate deep dependencies of features") > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper , with one further minor adjustment. > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -379,14 +379,17 @@ def crunch_numbers(state): > > f = to_process.pop(0) > > + if f == feat: > + raise Fail("ERROR: Cycle found when processing %s" % \ No need for the \ here. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 10:44:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 10:44:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104377.1455439 (Exim 4.92) (envelope-from ) id 1ut20v-0005lW-AP; Mon, 01 Sep 2025 10:43:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104377.1455439; Mon, 01 Sep 2025 10:43: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 1ut20v-0005lP-7G; Mon, 01 Sep 2025 10:43:53 +0000 Received: by outflank-mailman (input) for mailman id 1104377; Mon, 01 Sep 2025 10:43: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 1ut20t-0005lF-I2 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 10:43:51 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20603.outbound.protection.outlook.com [2a01:111:f403:2418::603]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8a9cf831-8720-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 12:43:49 +0200 (CEST) Received: from SJ0PR03CA0073.namprd03.prod.outlook.com (2603:10b6:a03:331::18) by IA0PR12MB8838.namprd12.prod.outlook.com (2603:10b6:208:483::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 10:43:44 +0000 Received: from SJ5PEPF00000208.namprd05.prod.outlook.com (2603:10b6:a03:331:cafe::75) by SJ0PR03CA0073.outlook.office365.com (2603:10b6:a03:331::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Mon, 1 Sep 2025 10:43:44 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF00000208.mail.protection.outlook.com (10.167.244.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Mon, 1 Sep 2025 10:43:43 +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, 1 Sep 2025 05:43:43 -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, 1 Sep 2025 05:43: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; Mon, 1 Sep 2025 05:43: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: 8a9cf831-8720-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oj7sykvF0xLMBJ26mQMmafupPJXedVk8RG08m8szZap3CGSh5IDK5iQjTQLQubz6/yU4rqW7y5y0tNr+zPyALliOhfcQrnTxxE26I0cUGqkUHYPHHo4Q5pPmOkwx3j+JgZBbYAoykmttPx97gfGBrGbQQ8mhoG9nIzTll9eEHuvTEGrGJVg4NH3rKxclK1PEhHtFruve0vx0L9mLp3Pv7LBT2RFx5zH2uzKv60Nt46WoDUaOfL7P2xscXVvfeWkbn0wMQoFhY8qCNS/z1K5nmf4QDrB+HRnEmvzf2PfyZ8lRoI6UXWVuCXPwXexaJN/sHLah3otn1XabLvKXg8Cqiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tx7ZavVeNdWWSvvu3rYjzhhUoflye+ydUcxwgk7J/DQ=; b=SaH+3qc4Lqo5Fm7o64e3DfTVABchOoLZ9HlYAxNX0cfS4oKg72ysFJvabyYT5Aze5IoqbSl+DSKr1lCR4GB0VWW50VtHg3KuNrWwEFdbLZN1YSIAQY0pE7a2p8YR0R3KvDcLjS7yEYjUKco8U6kj+YJsBLqkjHdlRiRbgt0IDCJb1Xz2HzOSx+ScxQaosc7jSC17Z9qHNDnjjRPSUVeErWyJY2xXSriZXzRr/vDhG1W1LULiz+TR6xzvmPcr5APO/1HEi2G+4Kz7TWpUPtSFUmBEvZp8WEEFty2Q140y8xC1HS/ccHYahQZJmdjOCNo5GEfz4XVmm+o12qcluUSQuQ== 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=tx7ZavVeNdWWSvvu3rYjzhhUoflye+ydUcxwgk7J/DQ=; b=P73NeK+OmK5/DzkQiITW6gygAzi5BfimA8LgBJvkQqvzk13IS2oZjE/wFP56M5XjmebD2Z6wwzqRe5HlCv940/tZ6cW3Yr5ATuO2fqIyJ8RfNaW/0MP4umD44Ln+Ifp518YbmXgFtJJJT5W8sMS0e1MvzqCsNQ0MzoSCJ2FoG5g= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86: Fix AMD_SVM and INTEL_VMX dependency Date: Mon, 1 Sep 2025 12:43:28 +0200 Message-ID: <20250901104329.25693-1-michal.orzel@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000208:EE_|IA0PR12MB8838:EE_ X-MS-Office365-Filtering-Correlation-Id: dc221514-e384-43ee-1149-08dde9446c37 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?h/Y/hzhTgqDm/ptyQRlmWIa/GW+t0xK0xvi81euE8EeMPmEZbWcy5EKUVhiU?= =?us-ascii?Q?biECAfoeiGBkjBJZ1UiV6E62Vsh9wwcdK0xh4ZUMcb0tLgpPxEW6qdlBiWxf?= =?us-ascii?Q?nQiFIh11CaL4vtZl8+EWB5l4av0T8AktF9rx+efwM+2wvfi0Xe9zF00/sDP8?= =?us-ascii?Q?rreARD9fMw6/d/Ppusw4Sj5ESDwiwK39PGn3U2ik+15C29dlw7ei728djQTU?= =?us-ascii?Q?Gybs1EWjoVc0AEVT5g7CoU9Z5w2MsbY6joMYcs+lEaWU+dy3LhZY9EnGgi3j?= =?us-ascii?Q?tTbhLP3bC3LVPGJriWjDVPjqfrS6XsnLY0ceAI0g+rLgLrjWriyX3WMj3yxe?= =?us-ascii?Q?86xhxeUCdA+gj1IQsMds1wwQyRKdaQHqz0oX8BFJukAvuXo6nK13M/D2M4zH?= =?us-ascii?Q?NL5lpEPGuQ/C4JdRAmHD71GWykqufXokocsSXfLNy4oTqKhsMwJUhaNJHDf2?= =?us-ascii?Q?06Bx4mxon7YspPJx4qh6z5kXNYidQbxf/Z1n8/eAIy0J+Uac1kwLfK5oXtpf?= =?us-ascii?Q?K3SrqNLXaY/3TDxw/H8B5XMrkterfjrkF8+fUQijnrXLW7570XOK5jw+XiJz?= =?us-ascii?Q?zf3+awJnx93fBChKJx0SX6vT96ap8GEkPBV8/qTb82LKQNRgxsEA4+iXdYHb?= =?us-ascii?Q?DSA0jS6iq+vMnCDpPAJKxekmmtVGvAh+4kcA+AzgqXjcDJktDh6Uizm1NGIQ?= =?us-ascii?Q?QxDXVy4ORKV+pGF0EO5sYLpTLZPhF3fe/jHetsR8YI3oSE1Zpi52IIF+i3Wr?= =?us-ascii?Q?VKbIwKodh24y49f368OUyEF+YoriP9DDT2trIgtYi5fTG9s0oOlIqz4yqVjW?= =?us-ascii?Q?FNmaHkZMsNWmFMT2bwA8EEhCQp1nGAn7zC3m/iZlOXHAG26HdpXcmCb3IIN5?= =?us-ascii?Q?BnAdbO81+rn+ZwchJL2JEIs1Nd3dNsGvkGOkhUL6j9QSEVyp/pTABQ96igqX?= =?us-ascii?Q?Aiwwz50RD7X9hKlEYTdbRDoU0lhNQ2egmpXwHZTpXIgdLvxWdHEEQCGQbBCI?= =?us-ascii?Q?w3Fzzt813y6+sAv5B/1uT0QJqrGmLENlYOhE17Yxc7X1k8KijJFc+uT2j+us?= =?us-ascii?Q?le3Q/xNMiHnURbNNPRc9kiDXaXShZESHtObqbr9rlXFPZuJ/bmiHgtfOqRlO?= =?us-ascii?Q?6fZuD09nn/jzV5gT2rrZieEEZ5glfgoLLS25bN5ahfrAJypmrNuT415UESbk?= =?us-ascii?Q?+SxTxM+pta39Wg5LoJ76tYdrWpA2jNrr0RLzNB+vNS1/hYJY3HgrUB0DhxIO?= =?us-ascii?Q?qONhR94amq551VaBZaFuhLsA0Lx/TqshGxdndutVs86A4Ye5XRMPlv9lFozI?= =?us-ascii?Q?zb24/z1L0DxU6wRxcdnCg6FrWlziAgKu+uYTRGyfUqx3vZexYRh1cHvWanp2?= =?us-ascii?Q?hGPYMo9FvkT/U97xnMrAeIC0EXgYbwzeUhcd49OigIxOsZTUuamlUhQrMPAb?= =?us-ascii?Q?DBEGlRuMLx7Wy9+W8IHZ7OUNjaymep0bWNFD2TLT3Nbxan4Vk4MQCi7MCedv?= =?us-ascii?Q?1eYCxpwI5EJB+YUobJflWaSsW6+OSeux99fN?= 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: 01 Sep 2025 10:43:43.7745 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dc221514-e384-43ee-1149-08dde9446c37 X-MS-Exchange-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: SJ5PEPF00000208.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8838 Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and INTEL_VMX on INTEL. Such dependency should be done using 'depends on' and not 'if' next to prompt that deals only with the visibility of the given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX when INTEL is disabled (option is hidden). Fixes: e3ed540f2e9f ("x86/hvm: add HVM-specific Kconfig") Signed-off-by: Michal Orzel --- xen/arch/x86/hvm/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig index b903764bda0d..c85889ea8642 100644 --- a/xen/arch/x86/hvm/Kconfig +++ b/xen/arch/x86/hvm/Kconfig @@ -16,7 +16,8 @@ menuconfig HVM if HVM config AMD_SVM - bool "AMD-V" if AMD && EXPERT + bool "AMD-V" if EXPERT + depends on AMD default y help Enables virtual machine extensions on platforms that implement the @@ -25,7 +26,8 @@ config AMD_SVM If in doubt, say Y. config INTEL_VMX - bool "Intel VT-x" if INTEL && EXPERT + bool "Intel VT-x" if EXPERT + depends on INTEL default y select ARCH_VCPU_IOREQ_COMPLETION help -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 10:50:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 10:50:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104394.1455449 (Exim 4.92) (envelope-from ) id 1ut27L-0007Mx-3N; Mon, 01 Sep 2025 10:50:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104394.1455449; Mon, 01 Sep 2025 10:50: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 1ut27L-0007Mq-0n; Mon, 01 Sep 2025 10:50:31 +0000 Received: by outflank-mailman (input) for mailman id 1104394; Mon, 01 Sep 2025 10: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 1ut27J-0007MC-Du for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 10:50:29 +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 7885196c-8721-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 12:50:27 +0200 (CEST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b0415e03e25so152174066b.0 for ; Mon, 01 Sep 2025 03:50:27 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aff0681aefdsm774185966b.8.2025.09.01.03.50.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 03:50: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: 7885196c-8721-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756723827; x=1757328627; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6d9FTwOsIjtgog//yAxgk5Yz4RZ5ywhBqfV+xhi/VNU=; b=gVycCv4qL9LnmoXlb81VjX7XpOjTJONXmP56IvQNja5/Hip/ZRIthEpaBbn+SFbTuN PZ2WDK6UdykQ/eFJf5ZapvNoiiNwrAMDlezvsBoLBrxtAkh8XwckW+Ou3bSVRpT9M6Yq sCg0GPrnN0Hh7w8GmjGl9NbUdOLlNfep5f9/pIzlR8IYvsiuwbXlMXhfj1tIToVOQ0ov WjGhdglTPnUZeQuYNu5JV0UcYYVynfofijhY0OIK32Z/5z8wnBuLiQ7nhGEeX3TAjkCt 3gUbWP5bUk34fiMjSL6jf8NBYBVNmFLLwV5O6lFbwP+y9p9QrBKiKftU3wXnDEpP/RIS SRsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756723827; x=1757328627; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6d9FTwOsIjtgog//yAxgk5Yz4RZ5ywhBqfV+xhi/VNU=; b=kajPcrHpUw5ZwkN//+ufwCZ6d81rPS+4c3Kr4d9b+pW9g7RKMGBJKFmQKea243VviP LVB8RqUl+8I3s4XCJnmQWA1LZa0MbBugg4E1YVYjPy2Dt+j1Z/fQE0QLSryX4hU/nVUG cpT2XVgNcSs+fqIh6ijtXilq/YRfdv9Xf2vY3L6ZMl8NmQfnqHuILayDFSidyVHeQ7JF CM+wzQ+UkrAHxxxhrGPMPteaealxW35Se/dMVv/sL/xnWqUGV6oXakeB5Tzqg4e3EBqe hRaTaBPMe9hyCW4xYyr/wyMiLXPQK7lQSOFuU2VRRoRM8/dKiEHe/zv/N4M4mUmjeyIG pq8g== X-Forwarded-Encrypted: i=1; AJvYcCXHyvMirNk3Pfm7xryuYJ4EUMdX5tTXeBn3jDD+jwscwJNzkGhVpJE/3EB1KHIXIksC0iVM4yNu7wU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw5DY2V66J6+Ldc1JbrtzOvquMBXS30cw4PAhSaKwOuz4v9lGzK tetUi9n54zk/klp3QAvYU7O/JZ0+6/969QdZoc8BFY9RtnI2KZ7USzwkB13/W7M3Uw== X-Gm-Gg: ASbGnct4A6fnecD8zN5I/3tp3KHoBzZHV0kY7xPrLgHjVN8G39O6CgTj41SG25DQ/ib s/u4RzJCVWt5CHX9nVr4HInPMbRI7DIsRdRXf9eED9TPGi+vF5uKORjVqkHGkgushxNBa53NOXo FbjmIf6/eMONaV205popjLHSCV82VGz0U28AsgcoVDJZ72mbwqY/21LtZZmeaVbvlXzlJQzr2EU r2YQeLK9MLfURth3AFwa6+nN8toozCY7aLfuXcVgBwjzdolKjW+ncpWQu065Pa/ZoxYz0TpZuzO DyxDJbxFuC0ExnfQFgdadqbuOZu/guGMmAQCXkqf2cR0cvDa5p88CcY6ERJBAxbNzEAEqWsa/co mxudgqvSRc8C2z4+UDvppKn6CnFPcs4T0Zp3Q05aOaiv8mrgfE8X5MUloP/0LU1vKzym8XG8E45 ifJtbJAOB8Hzbc6sTA0Q== X-Google-Smtp-Source: AGHT+IHkx3ELT9yqKVJK86Q6A2sjt0uicsn9i3Lbek1FfZ7AGMAuO0px/S4yr6ge3eqEaYjHyCAxsw== X-Received: by 2002:a17:907:97c7:b0:afe:b3be:90f3 with SMTP id a640c23a62f3a-b01d8a2fdc5mr781327266b.10.1756723826767; Mon, 01 Sep 2025 03:50:26 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 12:50:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 14/23] x86/traps: Enable FRED when requested To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-15-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250828150409.901315-15-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > With the shadow stack and exception handling adjustements in place, we can now > activate FRED when appropriate. Note that opt_fred is still disabled by > default. > > Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses > MSR_STAR (entries from Ring3 only), and MSR_FRED_SSP_SL0 aliases MSR_PL0_SSP > when CET-SS is active. Otherwise, they're all new MSRs. > > With init_fred() existing, load_system_tables() and legacy_syscall_init() > should only be used when setting up IDT delivery. Insert ASSERT()s to this > effect, and adjust the various *_init() functions to make this property true. > > Per the documentation, ap_early_traps_init() is responsible for switching off > the boot GDT, which needs doing even in FRED mode. > > Finally, set CR4.FRED in {bsp,ap}_early_traps_init(). Nit: That's {bsp,percpu}_traps_init() now, aiui. > --- a/xen/arch/x86/include/asm/traps.h > +++ b/xen/arch/x86/include/asm/traps.h > @@ -16,6 +16,8 @@ void traps_init(void); > void bsp_traps_reinit(void); > void percpu_traps_init(void); > > +void nocall entry_FRED_R3(void); Can't we constrain this decl to the sole C file needing it? > @@ -268,6 +272,52 @@ static void __init init_ler(void) > setup_force_cpu_cap(X86_FEATURE_XEN_LBR); > } > > +/* > + * Set up all MSRs relevant for FRED event delivery. > + * > + * Xen does not use any of the optional config in MSR_FRED_CONFIG, so all that > + * is needed is the entrypoint. > + * > + * Because FRED always provides a good stack, NMI and #DB do not need any > + * special treatment. Only #DF needs another stack level, and #MC for the > + * offchance that Xen's main stack suffers an uncorrectable error. > + * > + * This makes Stack Level 1 unused, but we use #DB's stacks, and with the > + * regular and shadow stacks reversed as posion to guarantee that any use > + * escalates to #DF. > + * > + * FRED reuses MSR_STAR to provide the segment selector values to load on > + * entry from Ring3. Entry from Ring0 leave %cs and %ss unmodified. > + */ > +static void init_fred(void) > +{ > + unsigned long stack_top = get_stack_bottom() & ~(STACK_SIZE - 1); > + > + ASSERT(opt_fred == 1); > + > + wrmsrns(MSR_STAR, XEN_MSR_STAR); > + wrmsrns(MSR_FRED_CONFIG, (unsigned long)entry_FRED_R3); > + > + /* > + * MSR_FRED_RSP_* all come with an 64-byte alignment check, avoiding the > + * need for an explicit BUG_ON(). > + */ > + wrmsrns(MSR_FRED_RSP_SL0, (unsigned long)(&get_cpu_info()->_fred + 1)); > + wrmsrns(MSR_FRED_RSP_SL1, stack_top + (IST_DB * IST_SHSTK_SIZE)); /* Poison */ So the use of IST_SHSTK_SIZE here (and PAGE_SIZE below) is to have the SL1 stacks "the wrong way round". I first thought this was a mistake, not the least also due to the typo below. I think this wants commenting upon. > + wrmsrns(MSR_FRED_RSP_SL2, stack_top + (1 + IST_MCE) * PAGE_SIZE); > + wrmsrns(MSR_FRED_RSP_SL3, stack_top + (1 + IST_DF) * PAGE_SIZE); > + wrmsrns(MSR_FRED_STK_LVLS, ((2UL << (X86_EXC_MC * 2)) | > + (3UL << (X86_EXC_DF * 2)))); > + > + if ( cpu_has_xen_shstk ) > + { > + wrmsrns(MSR_FRED_SSP_SL0, stack_top + (PRIMARY_SHSTK_SLOT + 1) * PAGE_SIZE); > + wrmsrns(MSR_FRED_RSP_SL1, stack_top + (1 + IST_DF) * PAGE_SIZE); /* Poison */ MSR_FRED_SSP_SL1 and presumably IST_DB? Also (nit) both of these lines are too long; the double blank ahead of * on the latter one probably also wants dropping. > + wrmsrns(MSR_FRED_SSP_SL2, stack_top + (IST_MCE * IST_SHSTK_SIZE)); > + wrmsrns(MSR_FRED_SSP_SL3, stack_top + (IST_DF * IST_SHSTK_SIZE)); > + } > +} Because of the intentional asymmetry for SL1, maybe the writing of MSR_FRED_STK_LVLS would better move below here? > @@ -356,8 +410,13 @@ void __init traps_init(void) > */ > void __init bsp_traps_reinit(void) > { > - load_system_tables(); > - percpu_traps_init(); > + if ( opt_fred ) > + init_fred(); > + else > + { > + load_system_tables(); > + percpu_traps_init(); Doesn't this need to stay outside of the if/else, ... > + } > } > > /* > @@ -366,7 +425,8 @@ void __init bsp_traps_reinit(void) > */ > void percpu_traps_init(void) > { > - legacy_syscall_init(); > + if ( !opt_fred ) > + legacy_syscall_init(); > > if ( cpu_has_xen_lbr ) > wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR); ... for this to still be done? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 10:51:33 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 10:51:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104405.1455459 (Exim 4.92) (envelope-from ) id 1ut28L-0007xb-Bx; Mon, 01 Sep 2025 10:51:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104405.1455459; Mon, 01 Sep 2025 10: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 1ut28L-0007xU-9B; Mon, 01 Sep 2025 10:51:33 +0000 Received: by outflank-mailman (input) for mailman id 1104405; Mon, 01 Sep 2025 10:51: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 1ut28J-0007MC-Fm for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 10:51:31 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2060e.outbound.protection.outlook.com [2a01:111:f403:2409::60e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9ceb9303-8721-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 12:51:29 +0200 (CEST) Received: from SJ0PR13CA0075.namprd13.prod.outlook.com (2603:10b6:a03:2c4::20) by DM4PR12MB6111.namprd12.prod.outlook.com (2603:10b6:8:ac::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.24; Mon, 1 Sep 2025 10:51:24 +0000 Received: from CY4PEPF0000EDD0.namprd03.prod.outlook.com (2603:10b6:a03:2c4:cafe::e3) by SJ0PR13CA0075.outlook.office365.com (2603:10b6:a03:2c4::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.14 via Frontend Transport; Mon, 1 Sep 2025 10:51:21 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000EDD0.mail.protection.outlook.com (10.167.241.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9073.11 via Frontend Transport; Mon, 1 Sep 2025 10:51: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; Mon, 1 Sep 2025 05:51:20 -0500 Received: from [10.252.147.171] (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, 1 Sep 2025 05:51: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: 9ceb9303-8721-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=P2+qwlO2ejaTL5JkaafZkvPpwpzIKc8Rw/Kk5iWMt6aDhGoRX++HoLXFHn0ps366onzcxixKlwQrdn1h1DoFAYURnAdavHwpbjmgZxRMTC7aIoql/lx/O+YYaHW2ivHMjlH4m66Zk46YgAlEDl73XMsGjq0ag712Edoa33oWIETwKzEdLIiKuhguybFns9G54xfHWevyariQNUqpwKL6sWDm9bvYMlWis2YCK57EfMpFuvWuo/mB2ERk9QyNEi008SSPx6MC7ugmjgt2YtEskATnAyEsxMRoKic2VNsIUbTiNrparKNEoZcH6lX4MPP5WU9XplA15HtLBw9858yHHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p+Yxk7jc3b5WPUKFLYqIYBiG+mHtJeAvRcajD3ti/Xo=; b=em6tY4iTJxpft5lO5Jx1FyNGWgSJxrb0PNzEZEXG36f9MVT1Sx4n3CaKlosCLwEm7ih6+dTk20KcwjlyGVNbgwElwGMwFQQUeDC6bLsgf0Ax4np++POqagRLww1NYnaSZjN1BwnA+r0gbGdNYuR9XsRWtIXCTHJmEVTE00vKo8OEP2y8Ov5rS/MqIeGrHfWu10l0uqj9N086VdsdLZr+st/3ssXCbof715yAtlx78HBqKpDmn6I8pR1GQDh8IrinfX3uMhi5IqIxgRfASTVUL8CbWDL3G0DnsFLuaniTdVGcdx3L7ZVcK2vNT+2pzGxnyHga3/NICJlGQDNPTuNR9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p+Yxk7jc3b5WPUKFLYqIYBiG+mHtJeAvRcajD3ti/Xo=; b=s0c18v/j/RwKztZxjR4MyaB62aGsnv9HJcIqdBeHOzQggM5Ik41K45D4tw24xA1GGleuRHsC+JJvPJPTAdbvP+SeTHXqOsyL/2bUvk+i1lNLrZULwtU2O4ihxeT3RhJkoPILvzrXOGjfmxpH6HYl6PIIJPSaLCxEylYBuVeAwy8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 1 Sep 2025 12:51:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] device-tree: fix infinite loop issue in 'assign_shared_memory()' To: Dmytro Prokopchuk1 , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis References: <41cbf42c319a95c92517b6042414de6d13dda077.1756718656.git.dmytro_prokopchuk1@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <41cbf42c319a95c92517b6042414de6d13dda077.1756718656.git.dmytro_prokopchuk1@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD0:EE_|DM4PR12MB6111:EE_ X-MS-Office365-Filtering-Correlation-Id: f9f4bd05-8330-4864-e191-08dde9457e76 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?ei9Gd3lOSXJNSFBMeUZKZUZBcGdKMEViaVVoWmY5Sm5mMlVkcUs4N1czaVNh?= =?utf-8?B?VktWMGNOZ29PdmJ6bitZdjZqWk5uTlR3b2dQNWlka3lJS0l1Y0J1eVBXbHNj?= =?utf-8?B?K05hMXpOL3RyYk51aEk3WDFxdGU4cmc5N3VZbTBidlVNMmJLTFIxZDlxMm0v?= =?utf-8?B?Szl4aVI1V3JEYzZPUVJ3ZWJHOTZIZ2U2ekxXOGtWbnpHNUFGd3MwTlh0dEV5?= =?utf-8?B?WTFnQ0ZmaEVPMElyVWpGQVhLUk0yZjFVY3VlWWE0czZFNy92ZThDYkRxVXZm?= =?utf-8?B?OWFuTXFkZml6c2J2TFAyLzZ4cUVVTVVjTWQreGtrOGhxdkplWXVtZ2N0UFV2?= =?utf-8?B?cjFuaWkxcGtNZVFUNGpZTUFkVGlTWkpLS1RIa0ViRnV6OW41QmtJUjJQNEky?= =?utf-8?B?WTFnV200N2NvMm9ueVFHVXBTNmpqOUxuSXUvWVdIUU1PVk5OUzkybXJPSW5t?= =?utf-8?B?aDNJeXpvVUZnUmdCNEJFZjVjWDBhYkNZSHJLOFJKMzFpOUJ6STRNVDgrTjhJ?= =?utf-8?B?cUZLMmFpQmdTcXVNdnliMk93TXZWaStpOGpVd1dQaHg3V2tSSCtrdUFRQ0k0?= =?utf-8?B?U00yd0hldll5TVNCSkVUMGMrMHdwbHEyU0E1SGticmJhR1dUL3lLaCt4K1Fx?= =?utf-8?B?YXNaQUtLMUtYaUZyc25oMVJOejdsaEpsa3ByRUNaSElxUGZEV2ZhR1lLNmJC?= =?utf-8?B?SjdtVTdhTVZTbXRMeTlHcmhjVVMzeVgwWUJlSUVYeEROTloyMzJTTHZhZEpJ?= =?utf-8?B?SUhSR0NyU0RmSXZZa3VLMGFSU0lNSTU3eDhtRFo5RWllL0hrVGp6VW43cWFQ?= =?utf-8?B?MklrYk9OdFRIcjFVUDJ3K1BFVjA0b21Pc1N5RHRnVkxUZzlDVWpCQlNaT3JU?= =?utf-8?B?aWMvbDcwQU9pMXNWazM1aXpOajg2Y0VxbUtTeVc4Y2xuNC9lT3dZa3VyT1l2?= =?utf-8?B?djBvNnAxVHE5SmpNT3d1UkpyckJ5UHhxYnNycmFhVExJUjNMNktjbFFROUNz?= =?utf-8?B?dDRnVVBnOStIUGJSZVFrTmdSSHNwYjR2eE9SZStFUCs2NjViRjhEbHFNb1BT?= =?utf-8?B?eGtrYTQ3MVVZRXVId1R1ZmpjeFo3OW9iRUtraFE0VDF1NUVMZXhMYzlkVXFs?= =?utf-8?B?S3BmVkgzR1pzNUVsWjl4ajNYV2xoMTZwc0lhUGwvaUpUb2JXeXJoK1lnaTBM?= =?utf-8?B?d1pMTWdLajR1YUtqeEwxbmhIVHdISTF0NzFKeC9wSExNQ1EyMm15bWxxQkVM?= =?utf-8?B?SE9HdCtCSGZTYWordUpEbnQyejB1YWx5WmdqZ3QyQ3RpSE9BZDRQbTRjNjVE?= =?utf-8?B?MGx0aG5xRllncVMxa2ozN0wzTHVRNXBIZnhCTG44cjFWSGFTT1FsODF5cmVk?= =?utf-8?B?RGZTTVl4elRrYk56ZnY4a3BCWGpHeW0xZGdhem5CVmcwS0NSSU5UT3hxNENH?= =?utf-8?B?WHJJdXBaTnF1WnB6Qm5yTzluVWlNaEtGTy9iU01wQzRxRml5NUFmM3NVelNv?= =?utf-8?B?TnIxYTZLeGtyM0xiRmRHeHVic3I4bEJFYkNubXhMZzNQdHJMZTRNaFVUYk1k?= =?utf-8?B?ZHRqcUFueC96aitSVGRLZzJZWE8wbGxDMXJFSzA1WThRSVN2QnU5TTN2YjlR?= =?utf-8?B?SmRGNXlTczIxbGxVYUJwR3VqWTMzU2JjNk82eStYUUF4SmRxSEIxMUVwZFRw?= =?utf-8?B?ajZIYm05WnJaZ0w3dWlmRVRBZ2JWUlFVNlBoQWRvNW9tOTdFQ2V3YVNoa1JF?= =?utf-8?B?aWQyR1pYT0tHUnRFMytrdTBreWtsa2wra1I0WERjUWdMZityUUpYa050eFFa?= =?utf-8?B?MFlTTGdsZ0EwWnVFVDRRY3cwTGZ3NGxvSXpBSkdTYWF1S0RHNW94WE5ETXBT?= =?utf-8?B?U3FOY1NYcTc2ekpKUi8weWxPY3d6bVdVUWJFZ2lBMlgwWHlkN1UxZmlOUEtU?= =?utf-8?B?T1RwWHRzQzVaOFZyTHJ5eUo3RHN1R3VJeDByaUxmMmNLQm02ZkJJSzFqMUxD?= =?utf-8?B?NHNHRE5uWXF4dFUzVUFvSFRxaWJvSWhwSUlwazlwTVRZV2c1T2xqanlhUFdI?= =?utf-8?Q?l6mpgL?= 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: 01 Sep 2025 10:51:23.9321 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f9f4bd05-8330-4864-e191-08dde9457e76 X-MS-Exchange-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: CY4PEPF0000EDD0.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6111 On 01/09/2025 11:26, Dmytro Prokopchuk1 wrote: > Fix an issue in the 'fail:' cleanup path of the 'assign_shared_memory()' > function where the use of an unsigned long 'i' with the condition > '--i >= 0' caused an infinite loop. Update the loop to use 'i--', > ensuring correct loop termination. > > This change adheres to MISRA C Rule 14.3: "Controlling expressions shall > not be invariant." > > Fixes: 041957bad382 ("xen/arm: Add additional reference to owner domain when the owner is allocated") > Signed-off-by: Dmytro Prokopchuk Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 01 10:52:47 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 10:52:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104414.1455469 (Exim 4.92) (envelope-from ) id 1ut29W-0008Tk-Lr; Mon, 01 Sep 2025 10:52:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104414.1455469; Mon, 01 Sep 2025 10:52:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut29W-0008Td-Ik; Mon, 01 Sep 2025 10:52:46 +0000 Received: by outflank-mailman (input) for mailman id 1104414; Mon, 01 Sep 2025 10:52: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 1ut29U-0008TR-KQ for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 10:52:44 +0000 Received: from fforwardh-b2-smtp.messagingengine.com (fforwardh-b2-smtp.messagingengine.com [202.12.124.197]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c6761398-8721-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 12:52:39 +0200 (CEST) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfforwardh.stl.internal (Postfix) with ESMTP id 7AA4B840142; Mon, 1 Sep 2025 06:52:37 -0400 (EDT) Received: from phl-frontend-02 ([10.202.2.161]) by phl-compute-06.internal (MEProxy); Mon, 01 Sep 2025 06:52:37 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 1 Sep 2025 06:52: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: c6761398-8721-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1756723957; x=1756810357; bh=ZTcXzXlcyIMXC6e8cE1gniYmaVssyBubXl2 kVFtTX1g=; b=E2NrmMRF4mi9KNTH1hz7s5aHpyZPqFZNZUvOihH0215fbrmK+eO qM8wqzKEykbmvOU/oDRor/kSf9ToXxHbtQVkTwJjvCPxD0hjQiezm40MQOirbyKx Rc3HzqNpn60foMP/sts8AuNfZbex5shY9hhTgOSuK+HZVHNhdPUDbDORQqX3zU/y KEVRAK0Ckeb632/zoLVkGR0Vxqixx/ekhVfTkViScu4rsZmKRG4iggkeWkVt6chu ah/neyjqKRbt0osHrZc20InHAqkpafE9b6/MMU3FrRDnfUFixzy6+lVahHzsaquz hKxinM7P048f1/r2TmMc2bepo3d+ReK9xIA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduleduleehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgggfestdekredtredttdenucfhrhhomhepufgvrhhgihihucfm ihgsrhhikhcuoefuvghrghhihigpmfhisghrihhksegvphgrmhdrtghomheqnecuggftrf grthhtvghrnhepgedvfeefhfduvdetkeegleeggfelheekveeiuddufeehtdehleelhfek iedvvedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghkihgssegurghrkhhsthgrrhdr shhithgvpdhnsggprhgtphhtthhopedutddpmhhouggvpehsmhhtphhouhhtpdhrtghpth htohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhr tghpthhtohepshgvrhhgihihpghkihgsrhhikhesvghprghmrdgtohhmpdhrtghpthhtoh eprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegr nhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitg hhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghn rdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtg hpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhr tghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: ife053c87:Fastmail From: Sergiy Kibrik To: xen-devel@lists.xenproject.org Cc: Sergiy Kibrik , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Daniel P. Smith" , Stefano Stabellini , Jan Beulich Subject: [XEN PATCH v2] xen/flask: limit sidtable size Date: Mon, 1 Sep 2025 13:52:31 +0300 Message-Id: <20250901105231.1570041-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. Since the policy is generally not known in advance the size of sidtable in Xen has a rather high limit of UINT_MAX entries. 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 and predictable amounts. This patch provides a configuration option to impose such a limit. Signed-off-by: Sergiy Kibrik CC: Jan Beulich --- changes in v2: - use one config option instead of 2 - use base 2 exponent patch v1 here: https://lore.kernel.org/xen-devel/20250822095123.998313-1-Sergiy_Kibrik@epam.com/ -Sergiy --- xen/common/Kconfig | 11 +++++++++++ xen/xsm/flask/ss/sidtab.c | 4 +++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 76f9ce705f..83bc9870dc 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS If unsure, say Y. +config XSM_FLASK_SIDTABLE_ORDER + int "Maximum number of security identifiers (base-2 exponent)" if EXPERT + range 4 32 + default 32 + depends on XSM_FLASK + help + Limit the number of security identifiers allocated and operated by Xen. + The value is a base-2 exponent. This will set the max number of SIDs + and hence the max number of security contexts and heap memory + allocated for SID table entries. + config XSM_FLASK_POLICY bool "Compile Xen with a built-in FLASK security policy" default y if "$(XEN_HAS_CHECKPOLICY)" = "y" diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c index 69fc3389b3..0081abdc86 100644 --- a/xen/xsm/flask/ss/sidtab.c +++ b/xen/xsm/flask/ss/sidtab.c @@ -14,6 +14,8 @@ #include "security.h" #include "sidtab.h" +#define SID_LIMIT ((1UL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1) + #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) #define INIT_SIDTAB_LOCK(s) spin_lock_init(&(s)->lock) @@ -228,7 +230,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 == SID_LIMIT || s->shutdown ) { ret = -ENOMEM; goto unlock_out; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:03:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:03:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104424.1455478 (Exim 4.92) (envelope-from ) id 1ut2JK-0001sr-G7; Mon, 01 Sep 2025 11:02:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104424.1455478; Mon, 01 Sep 2025 11: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 1ut2JK-0001sk-DM; Mon, 01 Sep 2025 11:02:54 +0000 Received: by outflank-mailman (input) for mailman id 1104424; Mon, 01 Sep 2025 11: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 1ut2JJ-0001se-ML for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:02:53 +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 348d978f-8723-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:02:52 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-61e4254271dso1788096a12.2 for ; Mon, 01 Sep 2025 04: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 4fb4d7f45d1cf-61cfc20f344sm6955606a12.12.2025.09.01.04.02.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04: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: 348d978f-8723-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756724572; x=1757329372; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Je2hAMcn+Cc++2y5wyFumW2JLMrw3iDNSbgaGoeT9aU=; b=L1Y+RTi18umcqf8QCejI5sTV71cxXa6ToWd8NGFlbr/3lg3Dr8h6Qp9VmKWRALvE45 NTNBIo3EN/l65ZS+2cpHP1brLbfADXNeXZvPgjVlys5rM9v0WmICzr6zhFExjlSG59Rt C+MHnqJVF9Shv8M0oQqrkpCxTeUWlyV/ufbGLOPr1d9WeoSt4NYfB9pbqlS/I33GBMOw QYLujMuBEhmPfUaejfyIslruPpSjp1OxROBQHbZz64geZ3IFLsKYNkb1nAkCZL/A5SK6 zEacA4zt0vCLLLWlJ41HnXq3bUVNBSMIGkWs4hXx4gNOEPMWuCQfEcTNpcY+OYlJCT1C G64w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756724572; x=1757329372; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Je2hAMcn+Cc++2y5wyFumW2JLMrw3iDNSbgaGoeT9aU=; b=NiBmP+t/3VUD04znLDdKADXI4KiUlE+ma41RvEoxlM3JCA3y0ZMlxKklvINgj9b5xH pAny1niiMZ7V/3E0jBZN9yZMBfUdWuc1MDXvbdCyEFWT29nHp6ss8La3jfwWyY+XrXqX hj0uSVxe8gFvFNXRWTOmSeC7tEtUKADvJXidbc+cMtQlwaWBIX7JoS/djKCMlglgpKLv 09lnBo5yyMqLOfmMLBmEnH4i1epz0f/ZYiF7GCfJ2qUiy8Ci68mqwuk4NSd2ud6v4vlt b3enrCa2dGQnnII0sh0H5C7N+4lNdRcZ+bRU+nJZLp5b/cQzMUN2X7MEjPfXaLgH6W9J UNaQ== X-Forwarded-Encrypted: i=1; AJvYcCUqCp7cz1/tyn/TjW1YdsvgBVKJygm6xL7hRBmj4wRbKX4C8cNC3hrXrQZ2lZiEKglJuqGAA4QM3Lk=@lists.xenproject.org X-Gm-Message-State: AOJu0YxIIzEt74Q1A8QKsh0FwaHNUigBvnirwMMcCLnbCjgODsdvV46Q 0JN6FdDwNU6W1TAKK9MPJR8K1yWpZUrzQO9o9VyC8jWNazPICV+UrfXEJbqiV02UFw== X-Gm-Gg: ASbGnct8zza/S6ctsV5klXnJoNnDTja3I/I2ZwK2hj9xcgnqR9qqrNug7rEaSQ9CREJ +9ztl7EydYK/FXtcNk6WLsmes6Z/os4z4693F6/pbLxZJs3H5gd6QYEcWmfKyMCbfWnfwOrrvEB /mvxeaJ8T8tZynRM9SoK0E3ddXj3ELi8lRP0e127sTnCVzQqbWWreZ/l2Kr9SX2J+sGH6m5POTP zW1FGKrRFPIHLWVirAAKPsAUn3cPAdzRn8XgDh4PN4sQ79N0NqV008ejgooo1DGkCWbEFM6Ar7U +G8BrxVLiWyJQzRmgBECDxuoYyMQIRJwSeuzz3UIjPPSeH/a7J98tjsCge79GHGYo16kgjTxSgA zw8MkEj4SRK8twdzSDnLJ8IhJjHlnNNP8hTlMeIhLoPMK08Tzi+TyzFRlOm2QJb4lOP4tnKke5/ dSY50o0qE= X-Google-Smtp-Source: AGHT+IH18A1HsiI9y2GFdapEXC0+onUGXNkvdRvfeVgCDM1oAtHBuHO0L1cRcMy39CsbuR7QiOfKiA== X-Received: by 2002:a05:6402:42ce:b0:615:c5a9:4cab with SMTP id 4fb4d7f45d1cf-61d26891bb7mr7850374a12.13.1756724571713; Mon, 01 Sep 2025 04:02:51 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 13:02:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/gen-cpuid: correct cycle detection To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <41ba214a-6137-4d8f-9f4f-3a362940d8a8@suse.com> <327eb40c-8fcb-42dc-a0b2-3b756a566b23@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: <327eb40c-8fcb-42dc-a0b2-3b756a566b23@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.09.2025 12:31, Andrew Cooper wrote: > On 01/09/2025 9:56 am, Jan Beulich wrote: >> With the processing done linearly (rather than recursively), checking >> whether any of the features was previously seen is wrong: That would >> e.g. trigger for this simple set of dependencies >> >> X: [A, B] >> A: [C] >> B: [C] >> >> (observed in reality when making AMX-AVX512 dependent upon both >> AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list >> of dependents). But checking the whole accumulated set also isn't >> necessary - just checking the feature we're processing dependents of is >> sufficient. We may detect a cycle later that way, but we still will >> detect it. What we need to avoid is adding a feature again when we've >> already seen it. >> >> As a result, seeding "seen[]" with "feat" isn't necessary anymore. >> >> Fixes: fe4408d180f4 ("xen/x86: Generate deep dependencies of features") >> Signed-off-by: Jan Beulich > > Acked-by: Andrew Cooper , with one further > minor adjustment. Thanks. >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -379,14 +379,17 @@ def crunch_numbers(state): >> >> f = to_process.pop(0) >> >> + if f == feat: >> + raise Fail("ERROR: Cycle found when processing %s" % \ > > No need for the \ here. Okay, but then why is there one in the commented out code you touch in the other patch? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:03:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:03:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104426.1455489 (Exim 4.92) (envelope-from ) id 1ut2JZ-0002BB-Rt; Mon, 01 Sep 2025 11:03:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104426.1455489; Mon, 01 Sep 2025 11: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 1ut2JZ-0002B4-P1; Mon, 01 Sep 2025 11:03:09 +0000 Received: by outflank-mailman (input) for mailman id 1104426; Mon, 01 Sep 2025 11:03: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 1ut2JZ-0001se-4N for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:03:09 +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 3e201230-8723-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:03:08 +0200 (CEST) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-45b83ae1734so14627315e9.0 for ; Mon, 01 Sep 2025 04:03:08 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e7ef7cfsm152172945e9.6.2025.09.01.04.03.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:03: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: 3e201230-8723-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756724588; x=1757329388; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hRxxRlc8f7vs7NUAtup/ZJTAGg+HDAk3DXtmybgTsfo=; b=rzK6nFqHC92R2VfL8a+DloxJqeSBoRriLAczID21m4mf7YO81b4J+Wakt1QKHccXUQ WVbD+3ZQA0DdNeeHRCLFRx/YusqvxYjJf6WvzU9L05bElr0JboHoRrAIuhkM7itAlE4p YcNL8PxLPMpwNZAiJnTax2RaEBBss0bOPjq0c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756724588; x=1757329388; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hRxxRlc8f7vs7NUAtup/ZJTAGg+HDAk3DXtmybgTsfo=; b=jrrUhnxSLhMsdyZ1k/Jbigfi3QG1WITwCA4sTi8d8O81SuuaIbhPj4XZxdUxHkCLkI NJIotFvhhtCY4xQvhCsNtrNDWQXeQt4qOGVu29VzqcsazGvvhjSB6XyaFowvG/LIvAMt 6p/6d8bw5uCp0/4GRpmH4xzyRs0M67pCVR8aucHyuV8tTa70O6Dor7WqYwx1xlrn/fgK tOHBxk+v38pV2GKDYUkeKw+0EzWIvysInxyqJA0Ioa4ebC5om1MaudErIxKn9bEYfRgL OKUgO9WFlDbKKLM60iFeZZy+E42SgCdm7BSw17355E4W2bCtrxYp33Y/gzJd20MJJ7G1 NRog== X-Forwarded-Encrypted: i=1; AJvYcCXTYNIFGqaAxUFifsfeB7p5OgcU8TJ3sCLbK+LtghyLGOrx8ZoZZCZPtSryhJyU2niFNEvQY3QjhtA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy/4iaPe3aYOI2m57i+Emd+26VavoCZjCR751dKojuU2pXAsvEZ mBPCb1V5oJiYGn9mrr1qK788DV6igVXwS9mKQl2LOPIXfacMM9yXBZ+/HKsUh6rlYBw= X-Gm-Gg: ASbGncvqIligd6Xrxv/FPvsAHH06WrpWw09W7jQPnWOQbGD6sgcUtRskKQ3Q4BnKahP eIqNUVpsV/1OuGC+JBIU8tz0yryFMwSqVlUeU2gsu1uFSYgLxiMBbIL+5pA+81O3lAMePwV6A2Z ZqlfCcADBHpIFElqy4XAwnzoGaQoAY2imtn9XvcXd9uPwpC6e8bCEFWjAUTwVsJk47qRg35l//y K0fdtuMyjAlm/39ghDwcO6hei6Be2vIiN8kPzqhgTteRiVvZlgA8/FhhPxmWWkqhwgQqSDUWBgm AxTqLa0zBpcwBG+8XcJJh2bazNAY6bqMdlwgrakDUBQbv286w2rheL598Llsj/ZDrEPioU6EkXR A3JYGKMrTFbjvI2lSztEf6OggMrCfxy4rLPJduM29I6XO22hYzotAeWApBY8ncvzdWYiDsVh5nU zSu0Q= X-Google-Smtp-Source: AGHT+IFNTSEjme0s9CaqKVt6iDXPKQNaxTGx36RHeg0Amss0+ggzDbKkcHQ1CHKEArX34ZN0L+Soew== X-Received: by 2002:a05:600c:4f89:b0:45b:8f11:8de3 with SMTP id 5b1f17b1804b1-45b8f118fc2mr17946925e9.16.1756724587830; Mon, 01 Sep 2025 04:03:07 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 12:03:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/apic: Get rid of get_physical_broadcast() To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250829161710.1056772-1-andrew.cooper3@citrix.com> <20250829161710.1056772-2-andrew.cooper3@citrix.com> <7d1bf3ca-b7fd-4c42-a9af-157120828d6c@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: <7d1bf3ca-b7fd-4c42-a9af-157120828d6c@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/09/2025 9:33 am, Jan Beulich wrote: > On 29.08.2025 18:17, Andrew Cooper wrote: >> This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of >> get_physical_broadcast()") to Xen. Thomas Gleixner notes: >> >> There is no point for this function. The only case where this is used is >> when there is no XAPIC available, which means the broadcast address is 0xF. >> >> In Linux, users of get_physical_broadcast() have already been hidden behind >> CONFIG_X86_32 suggesting we can drop all of this, but that's a task for some >> other time. >> >> In Xen as with Linux, setup_ioapic_ids_from_mpc() and io_apic_get_unique_id() >> are only called in pre-xAPIC cases, so can use a broadcast ID of 0xf. The >> only other user is __print_IO_APIC() for diagnostics, which can simply drop >> the check. > For setup_ioapic_ids_from_mpc() in Linux that's partly because it gained an > Intel && !APIC_XAPIC() check which we don't have. In Xen, setup_ioapic_ids_from_mpc() has a comment and an xAPIC check at the start of the function. We're lacking Linux commit a38c5380ef9f "x86: io_apic: Split setup_ioapic_ids_from_mpc()" which moved the check to the caller. Perhaps I should s/called/used/ in the commit message? ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:06:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:06:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104450.1455498 (Exim 4.92) (envelope-from ) id 1ut2Me-0002zP-8E; Mon, 01 Sep 2025 11:06:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104450.1455498; Mon, 01 Sep 2025 11: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 1ut2Me-0002zI-5Y; Mon, 01 Sep 2025 11:06:20 +0000 Received: by outflank-mailman (input) for mailman id 1104450; Mon, 01 Sep 2025 11:06: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 1ut2Md-0002zB-68 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:06:19 +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 ae8ff5f8-8723-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 13:06:17 +0200 (CEST) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-45b7d497ab9so36303875e9.0 for ; Mon, 01 Sep 2025 04:06:17 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d0b9402299sm13918384f8f.18.2025.09.01.04.06.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:06: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: ae8ff5f8-8723-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756724777; x=1757329577; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yjy4r8CxSau9HWpgnwP6xnZso1qjHrdX2I5alpTzcQI=; b=I9/vbXwyV4336w3offsjXt/E0uBAuXXjgjTHymHcBQ6n2iY/0AUnj0LLBONsANhXEX +s2gn2aqcaqZDBpl6zw7WaYEQI/5979rbmPyL2vtQhC/R1rUs9X+I/UtoWLZnEASRqhB mEZ8tQV0kdtTK5IygFbaEeVP9hCwrgSRomXL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756724777; x=1757329577; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yjy4r8CxSau9HWpgnwP6xnZso1qjHrdX2I5alpTzcQI=; b=ailEy8l5jM4c+h/whB0cIAG/SI3rRncYyUl2yVKbUSN8NdjYvl1wFt9uY2OIJMfRl3 yuz5m9SO63ZDOe9oYTG7zc/fxSTV4mgZ981mjRAEhnoj1kcEf0nUmt68PgxUsAn6B2sM MMawAkJwA0nyyRYsjrX+hE84y9D4j36AcU1rL8S2a650hXrKuvN59x+zC0HbnTPZ8M6I OhZ5AMz6+WiP2PCM+WZA0fUH9tnsNnW62HqJiVAF8LWIWAL3B99pfwtL3/fBiVbmg3VM icu/FJgB54DQe1yVsdfQm0JHbgs/pu1FhNjGZ/BxmsrPF6OU8L/XVdT9wDEOUH9M6tLC R0gQ== X-Forwarded-Encrypted: i=1; AJvYcCUcr96eCCajbXN90D2auDNSujI0aKkxGksiJlgbnGsIn+zZEr4uhLBiA43wn5L9zoBFvD+na/1cYeg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwqHSyyecoIN9V6XH1sH5V+fe/LysbqgRjPwCXHERB3g8dcRdgO esf3Jt+bnVWzsFL8bLa36a+hlmN4FVoBH7qDLpyipP9XsCExoVKMgGWJht+btuNrh7g= X-Gm-Gg: ASbGncudijkrT2TK/Z25S8JygSoVbbRPNKqFp+mKj3tfzmsJoFjW8VdKp1af/HvTMZj FpqBPb66ihuLKqDXTag8MyZjOMIo/buCUCeYJGScE7PxJpSjCNjxWyK2isFChwiTD3qPrvlmp7i ENHSZPYnL9y/Oz+jCvFfZw2wZNO2vW8OjWekXTryh0ffDSfqysLz4qDrLhjnVn2xs0Aq550OO+M XyrY6PzpaOSoCE25mqXvlCPYFwpF/0C0EsWNaXyqturpkExY90yyrs3Wo2/98ERKTJwsbSM+RkS 6f9HAI0ugxiQEGx3PBMFvmz68tEB6ZFDntabGxK9OYTILlSTU7x/CKkQlzT7u9OWTniuQsA9auo Jgpk6ynnZgesz2Su+2RRWW9de5PV39mCvr8XJzG6ru+LS1cB4vHRg6R3oGfUo9s6sBkuOCVXm1M FkPoI= X-Google-Smtp-Source: AGHT+IEplDcJAkQVkk7Z/wNtbk8hnX050Ak0zbsjhu8/2pr0ZoTKCrvgrrF7OtivxAlrSTla9JtjrQ== X-Received: by 2002:a05:600c:1e87:b0:45b:47e1:ef68 with SMTP id 5b1f17b1804b1-45b855bec6emr58422695e9.35.1756724776573; Mon, 01 Sep 2025 04:06:16 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 12:06:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/gen-cpuid: correct cycle detection To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <41ba214a-6137-4d8f-9f4f-3a362940d8a8@suse.com> <327eb40c-8fcb-42dc-a0b2-3b756a566b23@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 01/09/2025 12:02 pm, Jan Beulich wrote: > On 01.09.2025 12:31, Andrew Cooper wrote: >> On 01/09/2025 9:56 am, Jan Beulich wrote: >>> With the processing done linearly (rather than recursively), checking >>> whether any of the features was previously seen is wrong: That would >>> e.g. trigger for this simple set of dependencies >>> >>> X: [A, B] >>> A: [C] >>> B: [C] >>> >>> (observed in reality when making AMX-AVX512 dependent upon both >>> AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list >>> of dependents). But checking the whole accumulated set also isn't >>> necessary - just checking the feature we're processing dependents of is >>> sufficient. We may detect a cycle later that way, but we still will >>> detect it. What we need to avoid is adding a feature again when we've >>> already seen it. >>> >>> As a result, seeding "seen[]" with "feat" isn't necessary anymore. >>> >>> Fixes: fe4408d180f4 ("xen/x86: Generate deep dependencies of features") >>> Signed-off-by: Jan Beulich >> Acked-by: Andrew Cooper , with one further >> minor adjustment. > Thanks. > >>> --- a/xen/tools/gen-cpuid.py >>> +++ b/xen/tools/gen-cpuid.py >>> @@ -379,14 +379,17 @@ def crunch_numbers(state): >>> >>> f = to_process.pop(0) >>> >>> + if f == feat: >>> + raise Fail("ERROR: Cycle found when processing %s" % \ >> No need for the \ here. > Okay, but then why is there one in the commented out code you touch in the > other patch? Oh, that's wrong too. That will have originally been a print statement (no brackets in py2, thus needing the line continuation) which I refactored to sys.stderr.write() (has brackets) and didn't clean up correctly. I'll adjust it in my patch, as I'm dropping the trailing whitespace as well. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:06:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:06:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104453.1455509 (Exim 4.92) (envelope-from ) id 1ut2Mu-0003NJ-G9; Mon, 01 Sep 2025 11:06:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104453.1455509; Mon, 01 Sep 2025 11:06:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut2Mu-0003NC-Cg; Mon, 01 Sep 2025 11:06:36 +0000 Received: by outflank-mailman (input) for mailman id 1104453; Mon, 01 Sep 2025 11:06: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 1ut2Ms-0003JX-K3 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:06:34 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b8052a6a-8723-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:06:33 +0200 (CEST) Received: from PA4PR03MB7136.eurprd03.prod.outlook.com (2603:10a6:102:ea::23) by AS8PR03MB8104.eurprd03.prod.outlook.com (2603:10a6:20b:447::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 11:06:30 +0000 Received: from PA4PR03MB7136.eurprd03.prod.outlook.com ([fe80::36fa:728b:e216:6f6f]) by PA4PR03MB7136.eurprd03.prod.outlook.com ([fe80::36fa:728b:e216:6f6f%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 11:06: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: b8052a6a-8723-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bMasfdw8axzPYbBUTuO09ZMw+yTyXsuihNW5hXlInwW3CKZeDwYORoOnte6+V1fqRaojcRV7isCtzIg3cnZN8UdwU5icGILaAHd+J8aM6+gZeL9eghHhy7qkRwBNhHfFT79bEQdfv+Lo3QZxhdwTOc96m0xXo3fAhM/Nzdrc26J41uTe/o8k94Adliaho66MULs5MSg4FpAPP5hgk71rHrfsmQ4l5JIlLB/VnHNo1swV21miBsLqL52vQbtmL4ly9IojV8sY8BnbVUT6oPtYlAMSpmvtTPxVK7IbW/7nNH2JoybFD8i8TSTwSh0onXISzx6+96Jrr+mkFP/AHoPzwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iPmehvgRoVJseIJoPkT6z5iM1lJIxRKBTRbybEsV81I=; b=SqJcWH88ySZPw1mzEoVGxd3UN2d1cd01dlmKa0nMyJAWCtGJSNbzayVvrNdKQ+lr3gCtbERe6M4y79Ri8w+1fUl9gEePK/SO6hjr0ZsuvlnLGeXjwPbi+I2QmMH72iPRqKlJuuPBCZm+PkMA6ez8q4745VBgLwr4kDG11DAeMo/KfzhBxjXk+kasYbnQV+vMupa5iPg0MVF4oLhmxTJRkJ+m1M9oezmZ/rUpzExH2d/ZHbKNLQXqrME6nklDSPNYzfzX/SjiiKO43yi4Hg2Mn2VxD2GTSFry8qHRgfwdOu2v1vYhrnMMCeSlw5XOVI8XqJPwSznljOK/vpb//d5DDA== 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=iPmehvgRoVJseIJoPkT6z5iM1lJIxRKBTRbybEsV81I=; b=X2J/FtqERS+Hi+SX6hrm/f1vmmSAwsiSMe0Sa5pTq51PJWy9G9z27b+nY4MGj1Oijy55ITKveMDaD0fh7W6kudYaoNz/Jc+E5lZv35N156/d5ZYNYLM06a++hxzlmOukAs3+AfWFg3KXr9kdx6t1ySfpLIK2YHxnGDZvIJzOxWI39KFRK7Rbms2oaf28rOTxtnqUaNqUPaoxFsnVrxz91aiDKvaBBnGcPFcMZuSVhLAWdzEeOe+8Rip1vKNo8LLhN8mtWtnEMQEFnU6mAulGpH8C7kxIDh0+wbq9DjLVQSL54+p0U4J7og9H69Xob38FLOuyMzWUUYpmWzf94x6pnw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <65727710-0a88-4fff-bb5b-9cf34106833c@epam.com> Date: Mon, 1 Sep 2025 13:06:26 +0200 User-Agent: Mozilla Thunderbird From: Milan Djokic Subject: Re: [PATCH 00/20] Add SMMUv3 Stage 1 Support for XEN guests To: Volodymyr Babchuk Cc: Julien Grall , Julien Grall , "xen-devel@lists.xenproject.org" , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Michal Orzel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Nick Rosbrook , George Dunlap , Juergen Gross , Andrew Cooper References: <12ba4388-ee23-4e17-910f-9702271865ad@epam.com> <87v7m93bo0.fsf@epam.com> <6c80a929-8139-4461-b11c-e6ac67c3d2e4@epam.com> <875xe6ytyk.fsf@epam.com> Content-Language: en-US In-Reply-To: <875xe6ytyk.fsf@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1PR0102CA0030.eurprd01.prod.exchangelabs.com (2603:10a6:802::43) To PA4PR03MB7136.eurprd03.prod.outlook.com (2603:10a6:102:ea::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA4PR03MB7136:EE_|AS8PR03MB8104:EE_ X-MS-Office365-Filtering-Correlation-Id: 58c41796-1ce4-472d-5927-08dde94799b2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZzgzNTBySGJ4NTBFakwwMVFkYUxUYkRkWExKTitzZW5FRXVXMjlPRGUxYXAz?= =?utf-8?B?QnZGY0JoOGFsOTgwU0lLbm4vYWhPaUhEZmdJdldMbGxqS1Zqd3cxL0l4enNa?= =?utf-8?B?UDErTlJMU1FqWEU2OGlMcUtOemRKVUhKQXR5RHcvOGc3b2JFTENpN1lFcWdQ?= =?utf-8?B?YTYrOWJlQkpUOHNRYnJyQnlJdmpIcDNXai9UeVZjbVhHdS95cmlzNzVSZmpr?= =?utf-8?B?RllCT2grT0FlS1lCN1hRY2wrdHJ0QW1oQzEzTm5HMld4OHB2Q2FJN3hGcFF0?= =?utf-8?B?NnJWd3djRVRwVjJ6cGREV1U1VXlpMHVOTm45N2dMaTFFUEg4RGxjcnlPbDBx?= =?utf-8?B?bWo3bkljQ1ZpU285d2F2Qm9UdXhRZmZUeTJqRGdwTFNBSHJyOGpBL2g3WC9P?= =?utf-8?B?OW1GMnhGMkNHaVhjN09MVUtvbnNmN01KTmN5ZlpuZ2lrbytUZFkxQ2VsR3U5?= =?utf-8?B?UklCSURJMHBHNkprZ0pGbnllbjZ1VFd0SVRDMndVenlsVG96UWxZS1Jheld2?= =?utf-8?B?ZlFjUVpxYjNMdlY4cmtBUU9nT1J2Wjd5WHpka29teFgyS0hJRVdpWC9Pb0RJ?= =?utf-8?B?UEkrL28rZVNrK1NlaFh6dlA5ZjVzUnEyOWFxanpWZ1JBZzFwRzNpVzl5N1FE?= =?utf-8?B?QmM2Y0Z6dGVrWS94QkhjYzVkcGdkSUNma2t6R3MxY0RYVjRxSjk1Yis0dTU1?= =?utf-8?B?SGdXSisyOEVkU2RBZ0FlM01wNFBZTzh1dmZXVFdFeWFpeGtKeEZIMzF6M01H?= =?utf-8?B?SHY4YkhEVkl6Vk5pdWQvMEtDRzdMUzU3Zmg0c3RYb1pEbXRQM1RrRXYzdlBY?= =?utf-8?B?TTl4MDV1NlA0ekE0K0I2dFR2eGpIam9DVXBKRXdpM0YyOWdLQ2IzTDVsYmNs?= =?utf-8?B?NEN2YXJBZjNBR1Z0TGtuTU9kL3NTcWVyTXpqZHBoak80WjZJSGJwNEYxZnYy?= =?utf-8?B?UGRna2NXU2J6ZTB4Nm85eFRUa2VHVUpuQ05sMEZ4UWI3a1hHMEpwWHZ0YTE2?= =?utf-8?B?b2t1U1dtVDNzWnpHN0hveHZZQWZscjJSb05VcVNmREkzaC9UeTdUTkdzR1pk?= =?utf-8?B?ZUw0c2FzYlNEUnJmcFgwaGRNVWdOUnRxbHI0QzU2VWRYb0Uwam8veDZvRW54?= =?utf-8?B?U3ZxTzg3Z0ZFWFZBQ1BEWjI5OGY5aGQyNlZ0dW5KaS90ZllvRG8yL3EvcUls?= =?utf-8?B?cFhYSTFYNnp6QnFGb09ONzUvcndnRkZsbXdkLytyZDZySVVWM1IvQ2Y3Yjdn?= =?utf-8?B?ZmR2ZUxYMktyYk0xQ1BuMTQ2SVdLK1Z4M2ZmTTQ4T1dNem0xSlNWTExlUEU0?= =?utf-8?B?ODMxNDUrTUM2NFg0NllCWWF4QzJ2TW1hTmhaUnRJSGFXaEtkQ3g5VjdOSDZi?= =?utf-8?B?OTRBUzk0dXFXdkdnaUtwOWllVWdtcFZ1WEh3ZkRRTHBhTWhFWERJSGVjMFRm?= =?utf-8?B?dk1oWmRJclZZZWpQVFNPUkZleThqUmJCdkdkZ2d5dnlXb3Q0M0RLbDlNeml1?= =?utf-8?B?WTMrTXJYWldkK2wrVDVKNnI5bHBJSkpqbVU0S2pXaHVSR1IvdHkwRDVERmtQ?= =?utf-8?B?UlJ2L2lJMjNuMTVQWVlXMDZXZk8xN2ZwdkRwL2JqVDd3ZXJWcnRaU3g1Z2NW?= =?utf-8?B?MlBaR1QrTU40UUJLaXd1ODRoTGRIeU1rbmlhUi9jTjVFSmdzUWkwQUgzbjQ4?= =?utf-8?B?Um5JalR0cFMyWjdKekVYOFNXcXZFSmJhK3JCbmQyRWpHRFcwcG15WlBwTkJX?= =?utf-8?B?Q244V1h1bDdsR3h4TXlFVzAvVk1pSnA4T1hocWlhaVV2OThlbC9VQ2l2RHU2?= =?utf-8?B?ME9KaUJPaCtYS0RuWkhaUmt6aW91NXdGVkd1WFRNTk5ybWx2ejhJMHM2WUMw?= =?utf-8?B?NHBCMHZKZTl2Snd5cis0Z2ZNeGFVZVJpeldUZU0rWElXTzdDTGd6d3JybG45?= =?utf-8?Q?SpCHrYe4XcQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR03MB7136.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VW9oNU02aE9BK2MveWtST2Y2S3J4aTdWV3FSSEwySkVDZmdYZGlhYXhhY01Y?= =?utf-8?B?NzM4NEFBWU5QMmtvWlNNWExuR29rbXJaS3NSeURNbFB1VnlqWlk0cWVPSzYr?= =?utf-8?B?Kzl5andFcE4wN2RwRzF1STZUdEJ4OUFOQUsxbkh1V0lpYklvY1RiemhuemF1?= =?utf-8?B?bEx2UFBsZEo4akdsZU5UcW5xSlJiWkdFUjd5WDdreW9TVkJXWlR2dSsxMzAy?= =?utf-8?B?Rm5KSE1LbkZwcjl6cThFWjlUemZvZTB6SmhOY3phSGMySFloU0R3Q3IvZitX?= =?utf-8?B?djMweVFpQkdRU2hVY1VQTElQS1JqOE1DWGEwZ1JBdTlZQnBidU51ejZxU2Ur?= =?utf-8?B?Z01LdnRhYm41a0lNU05rcEd5VnRMbUtDN3dSTU9oSy9IbFpYMFlpOGhHWWRX?= =?utf-8?B?OXFGcFM5ZW9IQy9HeTBQTWt3Q044KzlqNlBQL2NzV1ZXWmpIakQ3NFZieUNC?= =?utf-8?B?a1cxbmdNUjZHZVE1WG5rRGhJdmdNdm03VW9VWkZlOHZXMzdLMUFRcmNhazV4?= =?utf-8?B?OFJOSDQ0eUVoUXlDNXJabXRuYkpheFBJVkJJaFZ3QjJEb3oyRitkd3NTVlNv?= =?utf-8?B?SzdyOVN1YkNSbHlZOXJRcjJxUlBuR1ZJcTRVUHlxZmNDMVp5UTl1RGNBMGRI?= =?utf-8?B?VGw5ZzRRalp4V3czWnVieExpS3lUbEkreWViZjJlQWd3cE9GZXE5WWM5eE9k?= =?utf-8?B?VWVXWFY4ZE0zdUNlamxXM2FSL212NFMyTGp3NWp1d0FMREJDS3lDbFNGS0Q1?= =?utf-8?B?TzhBVE9GMW9YaUVKeC9sOGxMeWRpK2IzQ25ZQkU2YXRmUEErazZJNUROajFZ?= =?utf-8?B?MDZyVmVTSjF1VXJwc2Uxc3FFa3dGUXdtc3dJOFNNeFlubndid2RIcjZmTDBO?= =?utf-8?B?T2NWMi9tRDBFSGIvZ1J0VlpvSmN5VXFWUktDS2FFbTd5eWFia25jTS9VeVo0?= =?utf-8?B?TTJzMkI1RlhaUDFldEtscUQwdURyMTY3Yzgwa1hnYXZLYkg4Mlh1ZC9iWDlQ?= =?utf-8?B?dFIralZ6OGlqQmhMekpXek5acGhBbm9Lb09pU01NeXRVNmM5U2JNZUlKZmc4?= =?utf-8?B?MzRhL0laS3BOaW9ST211T2xhZ2FNQ1QxaE9qdFVpVXlydVBBVEU3YnJYMEp2?= =?utf-8?B?NEhNTHBUS01yMU90U3gxSEovR1pkZy8rbWRDUEYyV2NhT0NDZW1vaFprQWtn?= =?utf-8?B?SDhBRkZSZU9GeEVmdk5LTm1IT0t5Uy95eDl0dUZ6c3pkOE5OeDhwbDBFdkFI?= =?utf-8?B?MFRDVnVtV0E0RnVXZTFiQTg5eHVIcGgvL0lhQ1E5c05FZmFUNzAzZ0hhMnJj?= =?utf-8?B?c2xQQVR3V2xWdFBxRWcvUy9MOEcxall3TStIZVZ6TWFZRVlMZjBWMHlHRXNZ?= =?utf-8?B?UFRyVzErQ1hTbWcwamppdUJlK1Y2ajNxRTNINjlCcldCdWR3VkZyd25OVGRn?= =?utf-8?B?NGdUV1dEOXBjV1ovNnJIK1VuRmtxbDYyb05zN082eGNWNEFobXkzbE9sdGlC?= =?utf-8?B?NTI0UzFLaG5ucXEvQlJyRVFoRXhyT0tETlJvbktDK2FQVUdRclZ4Wk9FSUZ6?= =?utf-8?B?b2hwQTNBUjFXaW55aVhyY3FGY3lhRnBxbVg3bWFvZUw0Y0JiaEFRYm9CUTdi?= =?utf-8?B?dFhoN2JTVXJBdW9IVkxBQXZLZHg5SVlNM3ZOKzNFRUErU2pEMzFCRkpBb2xG?= =?utf-8?B?UWtNRmJ1SFpxRzdYRmxrajNEcGNkbE1vNEdCWXVKZlQveVB5VElYWVJWYkdG?= =?utf-8?B?QUxodTB2SXNmZHhuUFNIU2w5K0tjUHo4NTlTbi9lMThnbVpQdFRVL0lNM1Fs?= =?utf-8?B?RDlKMVJtaUlvdFU0REhROXRBWFVva25ubWFKWTAvTTVtcnMycG5ZQTI1OW1D?= =?utf-8?B?MzdpcDR0RTMxVC83VlhXaHRlOGIyRG1zRUpMNmhXYldMTVRwaHlFSVBXZ3hu?= =?utf-8?B?VmR6bmtncENKYTJRM21JOHprSGRTT2xydCt3bUhxc0t3WkxlUHZyWHFIZVJr?= =?utf-8?B?WVBoekkxMjY5aS95TXBzSTgwQmFTY0hpSGQ2VStNSUZDcnliYU81ZzBIck5N?= =?utf-8?B?VmJaaTZESDVHaHNGQitYa1JrQldMVzUwMi80ZXFVU3IvbXZTdGNUb2R5Um9j?= =?utf-8?Q?baizcSSVGgdy/Ih1IDJ8W2xjA?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58c41796-1ce4-472d-5927-08dde94799b2 X-MS-Exchange-CrossTenant-AuthSource: PA4PR03MB7136.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2025 11:06:29.4470 (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: uCnsOFBJi3RaaumqQfCS1+VYsq2a4EItog7V369Jy8Eq79VQxAEzY2Lb8ImVtgmYwMFqr4Z+q2dMzHHeSkZkvw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8104 Hi Volodymyr, On 8/29/25 18:27, Volodymyr Babchuk wrote: > Hi Milan, > > Thanks, "Security Considerations" sections looks really good. But I have > more questions. > > Milan Djokic writes: > >> Hello Julien, Volodymyr >> >> On 8/27/25 01:28, Volodymyr Babchuk wrote: >>> Hi Milan, >>> Milan Djokic writes: >>> >>>> Hello Julien, >>>> >>>> On 8/13/25 14:11, Julien Grall wrote: >>>>> On 13/08/2025 11:04, Milan Djokic wrote: >>>>>> Hello Julien, >>>>> Hi Milan, >>>>> >>>>>> >>>>>> We have prepared a design document and it will be part of the updated >>>>>> patch series (added in docs/design). I'll also extend cover letter with >>>>>> details on implementation structure to make review easier. >>>>> I would suggest to just iterate on the design document for now. >>>>> >>>>>> Following is the design document content which will be provided in >>>>>> updated patch series: >>>>>> >>>>>> Design Proposal: Add SMMUv3 Stage-1 Support for XEN Guests >>>>>> ========================================================== >>>>>> >>>>>> Author: Milan Djokic >>>>>> Date:   2025-08-07 >>>>>> Status: Draft >>>>>> >>>>>> Introduction >>>>>> ------------ >>>>>> >>>>>> The SMMUv3 supports two stages of translation. Each stage of translation >>>>>> can be independently enabled. An incoming address is logically >>>>>> translated from VA to IPA in stage 1, then the IPA is input to stage 2 >>>>>> which translates the IPA to the output PA. Stage 1 translation support >>>>>> is required to provide isolation between different devices within the OS. >>>>>> >>>>>> Xen already supports Stage 2 translation but there is no support for >>>>>> Stage 1 translation. This design proposal outlines the introduction of >>>>>> Stage-1 SMMUv3 support in Xen for ARM guests. >>>>>> >>>>>> Motivation >>>>>> ---------- >>>>>> >>>>>> ARM systems utilizing SMMUv3 require Stage-1 address translation to >>>>>> ensure correct and secure DMA behavior inside guests. >>>>> Can you clarify what you mean by "correct"? DMA would still work >>>>> without >>>>> stage-1. >>>> >>>> Correct in terms of working with guest managed I/O space. I'll >>>> rephrase this statement, it seems ambiguous. >>>> >>>>>> >>>>>> This feature enables: >>>>>> - Stage-1 translation in guest domain >>>>>> - Safe device passthrough under secure memory translation >>>>>> >>>>>> Design Overview >>>>>> --------------- >>>>>> >>>>>> These changes provide emulated SMMUv3 support: >>>>>> >>>>>> - SMMUv3 Stage-1 Translation: stage-1 and nested translation support in >>>>>>   SMMUv3 driver >>>>>> - vIOMMU Abstraction: virtual IOMMU framework for guest Stage-1 handling >>>>> So what are you planning to expose to a guest? Is it one vIOMMU per >>>>> pIOMMU? Or a single one? >>>> >>>> Single vIOMMU model is used in this design. >>>> >>>>> Have you considered the pros/cons for both? >>>>>> - Register/Command Emulation: SMMUv3 register emulation and command >>>>>>   queue handling >>>>> >>>> >>>> That's a point for consideration. >>>> single vIOMMU prevails in terms of less complex implementation and a >>>> simple guest iommmu model - single vIOMMU node, one interrupt path, >>>> event queue, single set of trap handlers for emulation, etc. >>>> Cons for a single vIOMMU model could be less accurate hw >>>> representation and a potential bottleneck with one emulated queue and >>>> interrupt path. >>>> On the other hand, vIOMMU per pIOMMU provides more accurate hw >>>> modeling and offers better scalability in case of many IOMMUs in the >>>> system, but this comes with more complex emulation logic and device >>>> tree, also handling multiple vIOMMUs on guest side. >>>> IMO, single vIOMMU model seems like a better option mostly because >>>> it's less complex, easier to maintain and debug. Of course, this >>>> decision can and should be discussed. >>>> >>> Well, I am not sure that this is possible, because of StreamID >>> allocation. The biggest offender is of course PCI, as each Root PCI >>> bridge will require own SMMU instance with own StreamID space. But even >>> without PCI you'll need some mechanism to map vStremID to >>> , because there will be overlaps in SID space. >>> Actually, PCI/vPCI with vSMMU is its own can of worms... >>> >>>>> For each pSMMU, we have a single command queue that will receive command >>>>> from all the guests. How do you plan to prevent a guest hogging the >>>>> command queue? >>>>> In addition to that, AFAIU, the size of the virtual command queue is >>>>> fixed by the guest rather than Xen. If a guest is filling up the queue >>>>> with commands before notifying Xen, how do you plan to ensure we don't >>>>> spend too much time in Xen (which is not preemptible)? >>>>> >>>> >>>> We'll have to do a detailed analysis on these scenarios, they are not >>>> covered by the design (as well as some others which is clear after >>>> your comments). I'll come back with an updated design. >>> I think that can be handled akin to hypercall continuation, which is >>> used in similar places, like P2M code >>> [...] >>> >> >> I have updated vIOMMU design document with additional security topics >> covered and performance impact results. Also added some additional >> explanations for vIOMMU components following your comments. >> Updated document content: >> >> =============================================== >> Design Proposal: Add SMMUv3 Stage-1 Support for XEN Guests >> =============================================== >> >> :Author: Milan Djokic >> :Date: 2025-08-07 >> :Status: Draft >> >> Introduction >> ======== >> >> The SMMUv3 supports two stages of translation. Each stage of >> translation can be >> independently enabled. An incoming address is logically translated >> from VA to >> IPA in stage 1, then the IPA is input to stage 2 which translates the IPA to >> the output PA. Stage 1 translation support is required to provide >> isolation between different >> devices within OS. XEN already supports Stage 2 translation but there is no >> support for Stage 1 translation. >> This design proposal outlines the introduction of Stage-1 SMMUv3 >> support in Xen for ARM guests. >> >> Motivation >> ========== >> >> ARM systems utilizing SMMUv3 require stage-1 address translation to >> ensure secure DMA and guest managed I/O memory mappings. > > It is unclear for my what you mean by "guest manged IO memory mappings", > could you please provide an example? > Basically enabling stage-1 translation means that the guest is responsible for managing IOVA to IPA mappings through its own IOMMU driver. Guest manages its own stage-1 page tables and TLB. For example, when a guest driver wants to perform DMA mapping (e.g. with dma_map_single()), it will request mapping of its buffer physical address to IOVA through guest IOMMU driver. Guest IOMMU driver will further issue mapping commands emulated by Xen which translate it into stage-2 mappings. >> This feature enables: >> >> - Stage-1 translation in guest domain >> - Safe device passthrough under secure memory translation >> > > As I see it, ARM specs use "secure" mostly when referring to Secure mode > (S-EL1, S-EL2, EL3) and associated secure counterparts of architectural > devices, like secure GIC, secure Timer, etc. So I'd probably don't use > this word here to reduce confusion > Sure, secure in terms of isolation is the topic here. I'll rephrase this >> Design Overview >> =============== >> >> These changes provide emulated SMMUv3 support: >> >> - **SMMUv3 Stage-1 Translation**: stage-1 and nested translation >> support in SMMUv3 driver. > > "Nested translation" as in "nested virtualization"? Or is this something else? > No, this refers to 2-stage translation IOVA->IPA->PA as a nested translation. Although with this feature, nested virtualization is also enabled since guest can emulate its own IOMMU e.g. when kvm is run in guest. >> - **vIOMMU Abstraction**: Virtual IOMMU framework for guest stage-1 >> handling. > > I think, this is the big topic. You see, apart from SMMU, there is > at least Renesas IP-MMU, which uses completely different API. And > probably there are other IO-MMU implementations possible. Right now > vIOMMU framework handles only SMMU, which is okay, but probably we > should design it in a such way, that other IO-MMUs will be supported as > well. Maybe even IO-MMUs for other architectures (RISC V maybe?). > I think that it is already designed in such manner. We have a generic vIOMMU framework and a backend implementation for target IOMMU as separate components. And the backend implements supported commands/mechanisms which are specific for target IOMMU type. At this point, only SMMUv3 is supported, but it is possible to implement other IOMMU types support under the same generic framework. AFAIK, RISC-V IOMMU stage-2 is still in early development stage, but I do believe that it will be also compatible with vIOMMU framework. >> - **Register/Command Emulation**: SMMUv3 register emulation and >> command queue handling. > > Continuing previous paragraph: what about other IO-MMUs? For example, if > platform provides only Renesas IO-MMU, will vIOMMU framework still > emulate SMMUv3 registers and queue handling? > Yes, this is not supported in current implementation. To support other IOMMU than SMMUv3, stage-1 emulation backend needs to be implemented for target IOMMU and probably Xen driver for target IOMMU has to be updated to handle stage-1 configuration. I will elaborate this part in the design, to make clear that we have a generic vIOMMU framework, but only SMMUv3 backend exists atm. >> - **Device Tree Extensions**: Adds `iommus` and virtual SMMUv3 nodes >> to device trees for dom0 and dom0less scenarios. >> - **Runtime Configuration**: Introduces a `viommu` boot parameter for >> dynamic enablement. >> >> vIOMMU is exposed to guest as a single device with predefined >> capabilities and commands supported. Single vIOMMU model abstracts the >> details of an actual IOMMU hardware, simplifying usage from the guest >> point of view. Guest OS handles only a single IOMMU, even if multiple >> IOMMU units are available on the host system. > > In the previous email I asked how are you planning to handle potential > SID overlaps, especially in PCI use case. I want to return to this > topic. I am not saying that this is impossible, but I'd like to see this > covered in the design document. > Sorry, I've missed this part in the previous mail. This is a valid point, SID overlapping would be an issue for a single vIOMMU model. To prevent it, design will have to be extended with SID namespace virtualization, introducing a remapping layer which will make sure that guest virtual SIDs are unique and maintain proper mappings of vSIDs to pSIDs. For PCI case, we need to have an extended remapping logic where iommu-map property will be also patched in the guest device tree since we need a range of unique vSIDs for every RC assigned to guest. Alternative approach would be to switch to vIOMMU per pIOMMU model. Since both approaches require major updates, I'll have to do a detailed analysis and come back with an updated design which would address this issue. >> >> Security Considerations >> ======================= >> >> **viommu security benefits:** >> >> - Stage-1 translation ensures guest devices cannot perform unauthorized DMA. >> - Emulated IOMMU removes guest dependency on IOMMU hardware while >> maintaining domains isolation. > > I am not sure that I got this paragraph. > First one refers to guest controlled DMA access. Only IOVA->IPA mappings created by guest are usable by the device when stage-1 is enabled. On the other hand, with stage-2 only enabled, device could access to complete IOVA->PA mapping created by Xen for guest. Since the guest has no control over device IOVA accesses, a malicious guest kernel could potentially access memory regions it shouldn't be allowed to, e.g. if stage-2 mappings are stale. With stage-1 enabled, guest device driver has to explicitly map IOVAs and this request is propagated through emulated IOMMU, making sure that IOVA mappings are valid all the time. Second claim means that with emulated IOMMU, guests don’t need direct access to physical IOMMU hardware. The hypervisor emulates IOMMU behavior for the guest, while still ensuring that memory access by devices remains properly isolated between guests, just like it would with real IOMMU hardware. >> >> >> 1. Observation: >> --------------- >> Support for Stage-1 translation in SMMUv3 introduces new data >> structures (`s1_cfg` alongside `s2_cfg`) and logic to write both >> Stage-1 and Stage-2 entries in the Stream Table Entry (STE), including >> an `abort` field to handle partial configuration states. >> >> **Risk:** >> Without proper handling, a partially applied Stage-1 configuration >> might leave guest DMA mappings in an inconsistent state, potentially >> enabling unauthorized access or causing cross-domain interference. >> >> **Mitigation:** *(Handled by design)* >> This feature introduces logic that writes both `s1_cfg` and `s2_cfg` >> to STE and manages the `abort` field-only considering Stage-1 >> configuration if fully attached. This ensures incomplete or invalid >> guest configurations are safely ignored by the hypervisor. >> >> 2. Observation: >> --------------- >> Guests can now invalidate Stage-1 caches; invalidation needs >> forwarding to SMMUv3 hardware to maintain coherence. >> >> **Risk:** >> Failing to propagate cache invalidation could allow stale mappings, >> enabling access to old mappings and possibly data leakage or >> misrouting. >> >> **Mitigation:** *(Handled by design)* >> This feature ensures that guest-initiated invalidations are correctly >> forwarded to the hardware, preserving IOMMU coherency. >> >> 3. Observation: >> --------------- >> This design introduces substantial new functionality, including the >> `vIOMMU` framework, virtual SMMUv3 devices (`vsmmuv3`), command >> queues, event queues, domain management, and Device Tree modifications >> (e.g., `iommus` nodes and `libxl` integration). >> >> **Risk:** >> Large feature expansions increase the attack surface—potential for >> race conditions, unchecked command inputs, or Device Tree-based >> misconfigurations. >> >> **Mitigation:** >> >> - Sanity checks and error-handling improvements have been introduced >> in this feature. >> - Further audits have to be performed for this feature and its >> dependencies in this area. Currently, feature is marked as *Tech >> Preview* and is self-contained, reducing the risk to unrelated >> components. >> >> 4. Observation: >> --------------- >> The code includes transformations to handle nested translation versus >> standard modes and uses guest-configured command queues (e.g., >> `CMD_CFGI_STE`) and event notifications. >> >> **Risk:** >> Malicious or malformed queue commands from guests could bypass >> validation, manipulate SMMUv3 state, or cause Dom0 instability. > > Only Dom0? > This is a mistake, the whole system could be affected. I'll fix this. >> >> **Mitigation:** *(Handled by design)* >> Built-in validation of command queue entries and sanitization >> mechanisms ensure only permitted configurations are applied. This is >> supported via additions in `vsmmuv3` and `cmdqueue` handling code. >> >> 5. Observation: >> --------------- >> Device Tree modifications enable device assignment and >> configuration—guest DT fragments (e.g., `iommus`) are added via >> `libxl`. >> >> **Risk:** >> Erroneous or malicious Device Tree injection could result in device >> misbinding or guest access to unauthorized hardware. >> >> **Mitigation:** >> >> - `libxl` perform checks of guest configuration and parse only >> predefined dt fragments and nodes, reducing risc. >> - The system integrator must ensure correct resource mapping in the >> guest Device Tree (DT) fragments. >> >> 6. Observation: >> --------------- >> Introducing optional per-guest enabled features (`viommu` argument in >> xl guest config) means some guests may opt-out. >> >> **Risk:** >> Differences between guests with and without `viommu` may cause >> unexpected behavior or privilege drift. >> >> **Mitigation:** >> Verify that downgrade paths are safe and well-isolated; ensure missing >> support doesn't cause security issues. Additional audits on emulation >> paths and domains interference need to be performed in a multi-guest >> environment. >> >> 7. Observation: >> --------------- >> Guests have the ability to issue Stage-1 IOMMU commands like cache >> invalidation, stream table entries configuration, etc. An adversarial >> guest may issue a high volume of commands in rapid succession. >> >> **Risk** >> Excessive commands requests can cause high hypervisor CPU consumption >> and disrupt scheduling, leading to degraded system responsiveness and >> potential denial-of-service scenarios. >> >> **Mitigation** >> >> - Xen credit scheduler limits guest vCPU execution time, securing >> basic guest rate-limiting. > > I don't thing that this feature available only in credit schedulers, > AFAIK, all schedulers except null scheduler will limit vCPU execution time. > I was not aware of that. I'll rephrase this part. >> - Batch multiple commands of same type to reduce overhead on the >> virtual SMMUv3 hardware emulation. >> - Implement vIOMMU commands execution restart and continuation support > > So, something like "hypercall continuation"? > Yes >> >> 8. Observation: >> --------------- >> Some guest commands issued towards vIOMMU are propagated to pIOMMU >> command queue (e.g. TLB invalidate). For each pIOMMU, only one command >> queue is >> available for all domains. >> >> **Risk** >> Excessive commands requests from abusive guest can cause flooding of >> physical IOMMU command queue, leading to degraded pIOMMU responsivness >> on commands issued from other guests. >> >> **Mitigation** >> >> - Xen credit scheduler limits guest vCPU execution time, securing >> basic guest rate-limiting. >> - Batch commands which should be propagated towards pIOMMU cmd queue >> and enable support for batch execution pause/continuation >> - If possible, implement domain penalization by adding a per-domain >> cost counter for vIOMMU/pIOMMU usage. >> >> 9. Observation: >> --------------- >> vIOMMU feature includes event queue used for forwarding IOMMU events >> to guest (e.g. translation faults, invalid stream IDs, permission >> errors). A malicious guest can misconfigure its SMMU state or >> intentionally trigger faults with high frequency. >> >> **Risk** >> Occurance of IOMMU events with high frequency can cause Xen to flood >> the event queue and disrupt scheduling with high hypervisor CPU load >> for events handling. >> >> **Mitigation** >> >> - Implement fail-safe state by disabling events forwarding when faults >> are occured with high frequency and not processed by guest. >> - Batch multiple events of same type to reduce overhead on the virtual >> SMMUv3 hardware emulation. >> - Consider disabling event queue for untrusted guests >> >> Performance Impact >> ================== >> >> With iommu stage-1 and nested translation inclusion, performance >> overhead is introduced comparing to existing, stage-2 only usage in >> Xen. >> Once mappings are established, translations should not introduce >> significant overhead. >> Emulated paths may introduce moderate overhead, primarily affecting >> device initialization and event handling. >> Performance impact highly depends on target CPU capabilities. Testing >> is performed on cortex-a53 based platform. > > Which platform exactly? While QEMU emulates SMMU to some extent, we are > observing somewhat different SMMU behavior on real HW platforms (mostly > due to cache coherence problems). Also, according to MMU-600 errata, it > can have lower than expected performance in some use-cases. > Performance measurement are done on QEMU emulated Renesas platform. I'll add some details for this. >> Performance is mostly impacted by emulated vIOMMU operations, results >> shown in the following table. >> >> +-------------------------------+---------------------------------+ >> | vIOMMU Operation | Execution time in guest | >> +===============================+=================================+ >> | Reg read | median: 30μs, worst-case: 250μs | >> +-------------------------------+---------------------------------+ >> | Reg write | median: 35μs, worst-case: 280μs | >> +-------------------------------+---------------------------------+ >> | Invalidate TLB | median: 90μs, worst-case: 1ms+ | >> +-------------------------------+---------------------------------+ >> | Invalidate STE | median: 450μs worst_case: 7ms+ | >> +-------------------------------+---------------------------------+ >> >> With vIOMMU exposed to guest, guest OS has to initialize IOMMU device >> and configure stage-1 mappings for devices attached to it. >> Following table shows initialization stages which impact stage-1 >> enabled guest boot time and compares it with stage-1 disabled guest. >> >> "NOTE: Device probe execution time varies significantly depending on >> device complexity. virtio-gpu was selected as a test case due to its >> extensive use of dynamic DMA allocations and IOMMU mappings, making it >> a suitable candidate for benchmarking stage-1 vIOMMU behavior." >> >> +---------------------+-----------------------+------------------------+ >> | Stage | Stage-1 Enabled Guest | Stage-1 Disabled Guest | >> +=====================+=======================+========================+ >> | IOMMU Init | ~25ms | / | >> +---------------------+-----------------------+------------------------+ >> | Dev Attach / Mapping| ~220ms | ~200ms | >> +---------------------+-----------------------+------------------------+ >> >> For devices configured with dynamic DMA mappings, DMA >> allocate/map/unmap operations performance is also impacted on stage-1 >> enabled guests. >> Dynamic DMA mapping operation issues emulated IOMMU functions like >> mmio write/read and TLB invalidations. >> As a reference, following table shows performance results for runtime >> dma operations for virtio-gpu device. >> >> +---------------+-------------------------+----------------------------+ >> | DMA Op | Stage-1 Enabled Guest | Stage-1 Disabled Guest | >> +===============+=========================+============================+ >> | dma_alloc | median: 27μs, worst: 7ms| median: 2.5μs, worst: 360μs| >> +---------------+-------------------------+----------------------------+ >> | dma_free | median: 1ms, worst: 14ms| median: 2.2μs, worst: 85μs | >> +---------------+-------------------------+----------------------------+ >> | dma_map | median: 25μs, worst: 7ms| median: 1.5μs, worst: 336μs| >> +---------------+-------------------------+----------------------------+ >> | dma_unmap | median: 1ms, worst: 13ms| median: 1.3μs, worst: 65μs | >> +---------------+-------------------------+----------------------------+ >> >> Testing >> ============ >> >> - QEMU-based ARM system tests for Stage-1 translation and nested >> virtualization. >> - Actual hardware validation on platforms such as Renesas to ensure >> compatibility with real SMMUv3 implementations. >> - Unit/Functional tests validating correct translations (not implemented). >> >> Migration and Compatibility >> =========================== >> >> This optional feature defaults to disabled (`viommu=""`) for backward >> compatibility. >> > BR, Milan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:09:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:09:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104478.1455518 (Exim 4.92) (envelope-from ) id 1ut2PN-00047D-06; Mon, 01 Sep 2025 11:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104478.1455518; Mon, 01 Sep 2025 11: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 1ut2PM-000476-Tj; Mon, 01 Sep 2025 11:09:08 +0000 Received: by outflank-mailman (input) for mailman id 1104478; Mon, 01 Sep 2025 11:09: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 1ut2PK-000470-Tk for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:09:06 +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 134c895b-8724-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:09:06 +0200 (CEST) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-45b7d497abaso26843625e9.0 for ; Mon, 01 Sep 2025 04:09:06 -0700 (PDT) Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-45b7e7d1319sm161755635e9.5.2025.09.01.04.09.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 04:09: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: 134c895b-8724-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756724945; x=1757329745; 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=6rgR++lWLMqzeZslHsvt4I1kEBGOXcv7wE/eP36c0Gk=; b=YlgYa50fojCoFnCZHWQukPBXmNtXEjNGuud4vB2aMPx23WAg4uS0jiYgW5YlyTFcQ/ y/QInvtrG7Q//lg49DoRakmn+inGzwUIaZW/+eyyv4tCDP+CNzn/zqkwDzDkipAFOIWM Avl3mqiIoqUYjcLt23nbuniAEosLPodDX0OAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756724945; x=1757329745; 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=6rgR++lWLMqzeZslHsvt4I1kEBGOXcv7wE/eP36c0Gk=; b=LLdn8VEO9va9tI76QMgxtnC7xVTqWlWjgL/ZUjxrEwmCsyrjCAmogeeKhjPrqhI3qv bNiVFtR99A8kszD+TiGSkN82c/xqzOV6jyVFe/G2MkREbXE77lH5avgZlYKk7LeEqwje ThtETWvjlxZHhVU3RwKNuDzOHsjlMwol/5Ln41dTj5kagIIg2gEqUB5YB6Ngf/bmRc2U YaITjYXDTkKjjVooUxVUd0QANRKgAgpdfn8cl0/Cm42Avi+UzlcXyUUoH5QHcIdiBxA+ Izoz5GZ29WkUjdWmYFB+63oHAaT/ZS1IFlKGMD93ick/pHKrHIBpi/mXyYPT5nfAaRYw 1oGg== X-Forwarded-Encrypted: i=1; AJvYcCUtq74W+U0FDlhjSFhIzZ8/V7UbTFMnYCeVfPwzG8tVCRl7WVXQwdfFp+IyXb9vEmYOeubBeUkrJWA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzVNiZeCslnL/yIp8rQgGNjBh0o2j1c7gZaSCghuZgMpjp9XVY2 BYl+Mgdf1GgNYk/BOG3EUHM/uQ/M/TXPAELkGw2calf85pSRfcxfLIq36CEaHlnHsAw= X-Gm-Gg: ASbGncvRWKXgXo9K5CGMoZ3dbSqGcvU4pGsl+LnjxcLzD35cY26tiyH4oztxlZn+8YA reB5yOsEn4J6udcV/m5meHp3TkpGbMsxQrLEIbmvqtT7J3EaY3kqJ3e8W/3hKR/bnFkF83wJShw WpswSVDJXp7Q6ZTIwhvVDbLGB4PLKW2woRyFSokx6Nnt70OHk59RqpU8sBqJadSqfM6d8MIvC+P pdQfyaSXT+GyZtAcjWmcCAaeJvhbWPNiK5fPiNaeCByMskSJJX6+a+hq8fPbffbc1st8s+OZR0f UeT7Op7Gj3dfiPezsHMRD1SpVz9e5NrWgpiAtmb3pcL+cd2CG90nSxlFuqFPvzD8FxgHMnp4HHD EH6JiKfCn9/RAqh5Hn9HcF+uP4MbuSJjLmmcfkAFrl4h7jNpJq43MNDOY76ebsVDWJTEf8WLU6n 5L X-Google-Smtp-Source: AGHT+IHIUhdmQPaDN1SX580Lte6re6U34Y6Wbe8vElCsZ77g8+RA42qi3FtSDq25kKAwMRts/+GXzA== X-Received: by 2002:a05:600c:4f41:b0:45b:8b34:3482 with SMTP id 5b1f17b1804b1-45b8b3437c0mr32312625e9.20.1756724945482; Mon, 01 Sep 2025 04:09:05 -0700 (PDT) Date: Mon, 1 Sep 2025 13:09:04 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Mark Syms Cc: jgross@suse.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] Clarify the cases where BLKIF_RSP_EOPNOTSUPP can be returned. Message-ID: References: <20250828093821.372024-1-mark.syms@cloud.com> <20250829085627.407307-1-mark.syms@cloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250829085627.407307-1-mark.syms@cloud.com> On Fri, Aug 29, 2025 at 09:56:27AM +0100, Mark Syms wrote: > Previously this said it would only happen on barrier writes. Except > the documentation blocks for > * feature-flush-cache > * feature-discard I cannot parse what "documentation blocks" means in this context. I would maybe write this as: "Previously this said it would only happen on barrier writes. However Linux blkback and possibly other backends already return it when the type of the requests is unknown. Fix the comment to clarify the return code can be used as a reply to any request types not understood by the backend, not just barrier writes." > > Also say that they can return this error. > > Signed-off-by: Mark Syms Possibly with the commit message adjusted: Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:12:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:12:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104489.1455529 (Exim 4.92) (envelope-from ) id 1ut2SV-0005zV-E9; Mon, 01 Sep 2025 11:12:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104489.1455529; Mon, 01 Sep 2025 11: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 1ut2SV-0005zO-Ay; Mon, 01 Sep 2025 11:12:23 +0000 Received: by outflank-mailman (input) for mailman id 1104489; Mon, 01 Sep 2025 11:12:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut2SU-0005zH-OW for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:12:22 +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 87f914b1-8724-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:12:22 +0200 (CEST) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61cd3748c6dso8836059a12.3 for ; Mon, 01 Sep 2025 04:12: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 a640c23a62f3a-b041f6fb232sm335866266b.87.2025.09.01.04.12.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:12: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: 87f914b1-8724-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756725141; x=1757329941; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3VsKv5+bqdM1NYUoHhmZMJgSPIEF0pw9EVn3rOUL28U=; b=PtAWexmW7UACWQuThdIeSwK/dQ1KhXSQ5+zNW2DFRlKAbdqhHQw6zYKsViESklBmrp ajDiH116ycb7X5BtpouGSFb3v96i9SjPhu0fHCpejCluFtVK5Hr9qsSSspe6rYQKxpJS QJh1XPbzVfauH0Wj91v1CY8AhGyLk45LFBWzEXBShCHTnpSJimYbotnAY2bXL+42vCaQ l2WHgJlsyPhN8dKNQ+5qSsNhfc4NMsRo93SCbOaVbIbnCd63cpS+NGXm0sS+Gbpn/Yty TA5ftxOSvs8ow+D2NOuT+rGijvFGXgGTvLQi4pyafKr/s8h58EYH8V2fS1nqbI5UglSm s7kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756725141; x=1757329941; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3VsKv5+bqdM1NYUoHhmZMJgSPIEF0pw9EVn3rOUL28U=; b=mDboZQABxXnIffE7TDxsIW60kZcW76ri/s3Szq8ZmWPQo7wZn/al3FnczlmFW62sev a1jnjvdTUyYrxvewgXruIxzy6k4kwJPlLt97in7OD2GC1XaZQwoacdl5QRG/u6dGCq4Y hB1xyzBF/EMbW4wvFN2PyPewNEH807RZ8YZvSEzke/EsAQ/D4kUL81kQSNlZ/GhnHFO5 vC3x3wGU6WQVYEdDBhDEm+KyRMdMy26WvMEYAkslnv0hd7rNqome1TF51KMk0qpYkMZm jpDRMj0Z0y+KCX//nIePFwBuV38HAdGbMRJWGoeQCf8wisnD86zCrpUVF3KF/PEVsw/8 pEdw== X-Forwarded-Encrypted: i=1; AJvYcCVRIpVwpJWtFxatdyELJ9jc6oayIlAxst87gadLp2EGPaMXBIU1SmXl45VtGRvLqfXbaSymeE8QvfA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz3AbdxqHnm6NtRZMYH/KLvsmLvMgdyiWtHPe29IVEaaAOnlucB a7tzIgfr1usvwaZcjKIfMuCaORv4HOEkLR0c/hhcjQFw1mWzJ/Aj6eTuH47MKmQ3HM3f4aY+vBu ocCU= X-Gm-Gg: ASbGncv8J1788vDL6Qnk3km03Sk69SgBfEVwTHbGlqaUXS1Gtktuxjpb8Sl2RZ8GgdO 76T9ffOGa5Hii008hmkhTGSMXCvSaKfPx8QcwCycCs76H3PKewYxhNPq9oFOTbZo0OAGxv1Kc2u LV68F4DWRoN7cRImRBNMTsPqfNBrEm5HwhYByZpz20+q9GpjpztudqjBwozADV7rbMgzyW466TC yJmGGM6gZ/ddOgUIgHtWnxK0z0rJuAEdBRo9mzHS6ipu8Tll/l7HLDVfF2f5pm8P9E59A5UEbwh A3AOZICFrobFpc/W7y6/R3hkxggejElWhAFtwTeh8OSJKNbq36YN4WKJNynlLfcL+ARHn+qyXWE E9fV5337NPP+P5gOYCJt2fTHZ/JOV71UgnK5LWWQJWp5Meo7LtoR7Yc5BRaVUgg2DAjc+xNr6kD xLGr/gV/4dCOcablKn5w== X-Google-Smtp-Source: AGHT+IGMtKyiuByAuWAMrQmuNfif/jrQ9K1rVc6WtPtMFgzFKNILUlWPSbfEgtMAXDCQqGMBvZ9ygw== X-Received: by 2002:a17:907:9629:b0:afd:d993:9f29 with SMTP id a640c23a62f3a-b01f20bfbf2mr830734066b.63.1756725141326; Mon, 01 Sep 2025 04:12:21 -0700 (PDT) Message-ID: <1f6c189d-95b2-4600-9cea-73ef85cae873@suse.com> Date: Mon, 1 Sep 2025 13:12:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/apic: Get rid of get_physical_broadcast() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250829161710.1056772-1-andrew.cooper3@citrix.com> <20250829161710.1056772-2-andrew.cooper3@citrix.com> <7d1bf3ca-b7fd-4c42-a9af-157120828d6c@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 01.09.2025 13:03, Andrew Cooper wrote: > On 01/09/2025 9:33 am, Jan Beulich wrote: >> On 29.08.2025 18:17, Andrew Cooper wrote: >>> This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of >>> get_physical_broadcast()") to Xen. Thomas Gleixner notes: >>> >>> There is no point for this function. The only case where this is used is >>> when there is no XAPIC available, which means the broadcast address is 0xF. >>> >>> In Linux, users of get_physical_broadcast() have already been hidden behind >>> CONFIG_X86_32 suggesting we can drop all of this, but that's a task for some >>> other time. >>> >>> In Xen as with Linux, setup_ioapic_ids_from_mpc() and io_apic_get_unique_id() >>> are only called in pre-xAPIC cases, so can use a broadcast ID of 0xf. The >>> only other user is __print_IO_APIC() for diagnostics, which can simply drop >>> the check. >> For setup_ioapic_ids_from_mpc() in Linux that's partly because it gained an >> Intel && !APIC_XAPIC() check which we don't have. > > In Xen, setup_ioapic_ids_from_mpc() has a comment and an xAPIC check at > the start of the function. > > We're lacking Linux commit a38c5380ef9f "x86: io_apic: Split > setup_ioapic_ids_from_mpc()" which moved the check to the caller. > > Perhaps I should s/called/used/ in the commit message? Maybe, but I wouldn't insist. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:19:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:19:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104500.1455539 (Exim 4.92) (envelope-from ) id 1ut2ZK-0006Zr-2r; Mon, 01 Sep 2025 11:19:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104500.1455539; Mon, 01 Sep 2025 11:19: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 1ut2ZJ-0006Zk-Vf; Mon, 01 Sep 2025 11:19:25 +0000 Received: by outflank-mailman (input) for mailman id 1104500; Mon, 01 Sep 2025 11:19: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 1ut2ZJ-0006Ze-CE for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:19:25 +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 8318963f-8725-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 13:19:23 +0200 (CEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-afefc7be9d4so457308366b.1 for ; Mon, 01 Sep 2025 04:19: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-b040b1cf3c9sm490536966b.5.2025.09.01.04.19.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:19: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: 8318963f-8725-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756725563; x=1757330363; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Gex2yXvgrD5HtPtsvpELTv/Gti4vtgegLIi5pNIK3O4=; b=d59zDxF3aBJMm+uXCU7ufGBL45hmTqM4jc7LWdKLx01K+oRNrnoMzWMdNYWktv7p7Q 5KKv8bB0BgOiLaAQqf4majNL7D+orKzWm+tnZMBiEy/RQuoxbcmn/5+d+mZa/FjV+TDh rwGBdVQ5vm+sh/jMsp2Xn2qS8OZcsESVOBKr/vqcLDzt9tqy5DtKLn7FrOyEILgk+NE5 P81kFiFpswN+hu0xkO9YhuJltwCcy3ixunuAHxeaF3WjzFRhHGq1dZ/eNj3J/z01ZAxz 6WnLnLEnLx4esuA/9j7ppaUBfd6ZsMrDkK38Y854/h1FzYubOU/jMnZwIQKa5UQjFGmE hGNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756725563; x=1757330363; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Gex2yXvgrD5HtPtsvpELTv/Gti4vtgegLIi5pNIK3O4=; b=ekvfIesTy9luggF3kOGHvLEkJUqKcZdGKvib1RUgVK1+QbpSgnhNkNIZbvpJtmM3pX MwTEjUu/b6RnVeqMDrlBHEPA22zG80F44sN+3YUX2Xh0jjCmOqm42Z/6W3AB+BWRhFwq F2OK1o7kadyJn2zt/UsvIMT7bYcXit8CrTN1DpfaOtkxn2k38sOHC6+nqilmNFeyPZRF RAbPtwN2SYeAFI9af/vi379uaLC6j2/OnnpCASRa3C7hSq6VBKwBIrjJoOwZEZuufkzh TKNjhafz9HqrEFpFXloq7IwJ4JlgWobRgz3oQGRsKHrsWZeKzTwT/aaMllTmM4CXlssv 1UTg== X-Forwarded-Encrypted: i=1; AJvYcCUDHqS7u6PvgecX/pk2+0Mk9i/i3oZjVkwnZ6uIjiKznJAhmgJh14WPCFz0LgAAzzT34xRW6UVsssM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxvcK2YK1dbRNnxjpx6UY09fx8Pd3yrtzdbPjJv50IDh2zqLdF7 Eb2c/7s7dwdgTskm2W5p+mjxg4fjLhEA5n7Vj81Rv/PNhGh+V1XRm1GNj9JGrJee2w== X-Gm-Gg: ASbGncuXQoVBkL7V0ysWcS5v5AaFZhrWkZtMhquM686wppf1NsoBBd25b+h93HayHK+ XGTHsqCXb2vMgI1jTC1dT1kMYhzwnYafsiC95e4HWmagyOcCif0oxa5RhEgoeQ8Sg6jsuMNw4s3 r03nv3TBEeD8QrK9wGPNnv3Yp3Mn2cLoPikPZnZn7bEnT8SeCXhsPHs1sB039Y5jcy6r1IDJhXW WWtI13n+8K8OiveV/UqiTRWwYr2h/E1KmlMjB0SqgAgV2u3gJeTVJh4z+BG91r2gmHFwUnao74m CQBFzkyirDHb4yWOLg90pO/RaxpzrTP5lKvcOKeKv9wWViG567ZtnPPQ6iI6as6yu322WaeK30x h8WdJzQst6L+qQeJKsNh4IPkoIGL7e7HivBpCci44DCQz7D59bvSkGeKkfbv3qGJ3Isf9KCAe0O bI5Yfxu8SuB2SgAMdydA== X-Google-Smtp-Source: AGHT+IH8LkR4yOxpn299cAOVAdwb5WNRrjjagcs6zb0mdXNkoJFyT+s2hOLBBoCxfJuTAnOi+sMd4A== X-Received: by 2002:a17:907:3d0b:b0:adb:428f:f748 with SMTP id a640c23a62f3a-b01d8a72fddmr682364266b.21.1756725562611; Mon, 01 Sep 2025 04:19:22 -0700 (PDT) Message-ID: <4012a431-0d1d-400e-a0f4-b2ece3439441@suse.com> Date: Mon, 1 Sep 2025 13:19:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Fix AMD_SVM and INTEL_VMX dependency To: Michal Orzel Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20250901104329.25693-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: <20250901104329.25693-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.09.2025 12:43, Michal Orzel wrote: > Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and > INTEL_VMX on INTEL. Such dependency should be done using 'depends on' > and not 'if' next to prompt that deals only with the visibility of the > given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX > when INTEL is disabled (option is hidden). Hmm, yes, just that ... > --- a/xen/arch/x86/hvm/Kconfig > +++ b/xen/arch/x86/hvm/Kconfig > @@ -16,7 +16,8 @@ menuconfig HVM > if HVM > > config AMD_SVM > - bool "AMD-V" if AMD && EXPERT > + bool "AMD-V" if EXPERT > + depends on AMD > default y > help > Enables virtual machine extensions on platforms that implement the > @@ -25,7 +26,8 @@ config AMD_SVM > If in doubt, say Y. > > config INTEL_VMX > - bool "Intel VT-x" if INTEL && EXPERT > + bool "Intel VT-x" if EXPERT > + depends on INTEL > default y > select ARCH_VCPU_IOREQ_COMPLETION > help ... now it becomes impossible to _enable_ INTEL_VMX when INTEL is disabled, yet which may be of interest if you target some other vendor's VMX implementation. Perhaps really we should have config INTEL_VMX bool "Intel VT-x" if EXPERT default INTEL ? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:22:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:22:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104517.1455548 (Exim 4.92) (envelope-from ) id 1ut2cS-0008Q7-Ff; Mon, 01 Sep 2025 11:22:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104517.1455548; Mon, 01 Sep 2025 11:22:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut2cS-0008Q0-D2; Mon, 01 Sep 2025 11:22:40 +0000 Received: by outflank-mailman (input) for mailman id 1104517; Mon, 01 Sep 2025 11:22: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 1ut2cR-0008Pu-0M for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:22:39 +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 f6a2ed2f-8725-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 13:22:37 +0200 (CEST) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61cb4370e7bso6308793a12.3 for ; Mon, 01 Sep 2025 04:22: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 4fb4d7f45d1cf-61cfc4e50fbsm6801912a12.38.2025.09.01.04.22.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04: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: f6a2ed2f-8725-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756725756; x=1757330556; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=HBPITbBt8/h6jGGj8e5YrH8gDaO/mzRHB+KUqz/EVL0=; b=TeFDvlnaf/ufcDsOx96aMFtZSAb/SHUGGS+Wbikt8+RNv+ANLMts1AYDA6rOVptcfE NRonvtUUl3hCuwgVmhhQh0zY37D9FFcU7MTQbnXTZ4q2kffYso0Bc+SqYWSrd+1ChVP0 2s4nJpIvIRh8XN2VnfzrCF6YaDtE8ETgiROCTw0Dp6nZetoWnQQx6zoygsv9MOdjMAJP HxM/m6YNHyJ3KOKEKKb2Wbxa84iwHy8AOj8YM2b9Lm54lyqqCA+VJgCXBrwMno74JD+C OZgapfbP1myHIQIraCPxm/NC0l1eaQYNVPPYDTLxQ0BKOJ4gkRFyDyzWNQGo0RY69bpy Eesg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756725756; x=1757330556; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HBPITbBt8/h6jGGj8e5YrH8gDaO/mzRHB+KUqz/EVL0=; b=PtQc7Hf28fPpLDuPX74LhDRUNS/iSXNLDwiJVCFxTqJRKgfWSoErmYTWqr77s24eZw Z7ehlw28nWjsLxTJyFCFMrMqEPgpabGpNz6Akv7muXufF1ltl0Kfv31nOZW6vlIrLc4O NnQpY+zuNp0MRrnMEnuQSeZIZ4qCr98rIig432qNHqF7WtX+U9QbJ4or/0IXmLP7K/JW OVvslxNr8rbyYijw2Np7kfrEGAd5o7r1/kLEhiCizxq/KVHLDvsJecUSWWR4OdmdNqmo YvXdzVxV9q+jwTMt55nBGgw3J3Hvgl5XKGizb/Y5ffpCXGZTXhZaGQtHhdSy6x4Imhds olCw== X-Forwarded-Encrypted: i=1; AJvYcCUR4msIac2IyHiI2EIKyMfZl9Il4XD2XeE5HAH5TRxr5SLt2oHyaBQlj4MY4R59w9Ji+qWBch4VrbE=@lists.xenproject.org X-Gm-Message-State: AOJu0YzFil2NmY2hA7Clj7XD1UsaQ028MBfb83EUGIJGYHbWvk9u8mKk YQe3YY43IdrAuuHmsE6QldtLBMaG0j/KImfQrD26YPjrzaqxesqZd4+EGznzRXzyPg== X-Gm-Gg: ASbGncu1eNcZNcpKXce7e5yN11iijM+aZ8VFaKwoxBrC+1rPFdbMt5uU76VvGjhSal1 s8mwEX4ssIRp6EuZWTlXGs3kXhc0ZF4DKZqePgeaXCR4dDndke0xBV9cVH4vSbZDKbMfjgJITft QrkHi+r6au+gm5Qd1+JUzOyiP2eGy+4SgCuOG3AfIz5C698a7HwJkxDiTF7rAZoFFf0d+nTwi1P qoll4tfsITOxQA48Dh/UQUbnmFL6iAQd1SoicvaryUccyJPVBxtF0Y5g/CNZBDvvIku/4f/55Tn 0hBO6+lrhgO4t1AVtpEBh9C7YzU0wtp9MWTJv1pBlasABpStXaIUiPvU2IxD+O6GoFhCpjJUwjk 6kQO2uyV7kFPpF8IQK/K8Gd0SKJsVZSkwwEhoQRtew8zdpjGn/nLR08n9uCBuXBCg6WQieQDDo0 h+b/kTmF9iCbt3D9gPXA== X-Google-Smtp-Source: AGHT+IEKpRahnbTItiJC/2uLP4UOpmNKBpVTG2Qqbqa/ODlaFBSrjFqQ/AYCNh9Dx5AMEXhiayOEIQ== X-Received: by 2002:a05:6402:84e:b0:61d:976:81a1 with SMTP id 4fb4d7f45d1cf-61d26d78d31mr5736846a12.20.1756725756533; Mon, 01 Sep 2025 04:22:36 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 13:22:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 15/23] x86/pv: Deduplicate is_canonical_address() in do_set_segment_base() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-16-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: <20250828150409.901315-16-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.08.2025 17:04, Andrew Cooper wrote: > This is really a rearrangement to make adding FRED support easier. > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v2: > * New > > There is a marginal code size improvement: > > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-46 (-46) > Function old new delta > do_set_segment_base 496 450 -46 While this is quite nice, the nested switch()es aren't as much. Still Acked-by: Jan Beulich with possibly a default case added to the new inner switch(), just to please Misra. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:25:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:25:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104527.1455559 (Exim 4.92) (envelope-from ) id 1ut2fB-0000W3-SM; Mon, 01 Sep 2025 11:25:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104527.1455559; Mon, 01 Sep 2025 11:25:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut2fB-0000Vw-Od; Mon, 01 Sep 2025 11:25:29 +0000 Received: by outflank-mailman (input) for mailman id 1104527; Mon, 01 Sep 2025 11:25:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut2f9-0000Vq-UV for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:25:28 +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 5b18d703-8726-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:25:26 +0200 (CEST) Received: from SJ0PR05CA0098.namprd05.prod.outlook.com (2603:10b6:a03:334::13) by IA0PR12MB8304.namprd12.prod.outlook.com (2603:10b6:208:3dc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.25; Mon, 1 Sep 2025 11:25:22 +0000 Received: from CO1PEPF000044F7.namprd21.prod.outlook.com (2603:10b6:a03:334:cafe::3c) by SJ0PR05CA0098.outlook.office365.com (2603:10b6:a03:334::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.14 via Frontend Transport; Mon, 1 Sep 2025 11:25:20 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CO1PEPF000044F7.mail.protection.outlook.com (10.167.241.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9115.0 via Frontend Transport; Mon, 1 Sep 2025 11:25:20 +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, 1 Sep 2025 06:25: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; Mon, 1 Sep 2025 06:25:14 -0500 Received: from [10.252.147.171] (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, 1 Sep 2025 06:25: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: 5b18d703-8726-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xSDrvNHkseGd5OgwAQaULKhskN+oALDUMws1Bry+7JRMGznF+Au8F/X3ye8vfBWcIxRDyZm+e1kGo/4LLBDFAOv1tq9DVNXGOMNWj1YPftxCimtE+woUKaM0zcUtTU1iDLqNKwhifmn65lvB9mwW0J7pc81AMAQJ0bbG8S2Gys6c0f1+sZCqhPyPoIlM3OcRmYv/nv50R3ONppHpw5Tx/doYId8SDAUSrlB3yrPUUebjjiXWEdSk60NJpCMeRM7Pu1cjgfNrLxS4meSVAJMmnCj+A9Z2E+z/EWkSux91SOvWJQqy7g2oLCTIh2O5qZEKIHSfVnPgGRJOKt6cwdLlOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1lY+PfkKFnxrCbnL2IIXOubHGUZpoEuEuP7kTOb4ktw=; b=t9wH5y36+izy8TLN9gSfqh4YDcFYibkR5nnlfcXfrkUcfFj9bfyhEYCwu6QexEcUEyJObMfRTD9DW5tdxwTT6yGJZlVLWnZ5NmVx5c7+ipulP0Za1alz058NXZLz58CT9FNvwamdue2wnGG+46MQqakAHwm0G07+hq5oNexLKKukVlJGadgzFh8FFpFzs1H1zgDHSd5O0Pgwhc0UdKUkBRp+bcx7kiPIzW0G22Jsv6yba3wpo6/KItQQQPuQP8cp9RKMLHS/t3Trf8YbziJiUmpywBD0yv8RGAptHy+KqSeyVzLQvhwY34euSKL5qr2WWIgfCvetcSZp8qXaJTWJvw== 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=1lY+PfkKFnxrCbnL2IIXOubHGUZpoEuEuP7kTOb4ktw=; b=AOe06Mgwc5YLdRZRdV8sdgVJ2He1kJ4D0B0WiGGmo9bztR9cN+IHVxbQQy6i49ra6tr3odyqFjXh809bCY0lqNeM89s+g9e1irTF3EqjIbD2mut4JLtQYpKaLxSiZa6ywL+FOGwR3PMPxXh85kf2TUsggmHeAV6E68s2NVMKOKw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <4f59cfd8-dff6-4ac0-beda-13ccd161d628@amd.com> Date: Mon, 1 Sep 2025 13:25:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Fix AMD_SVM and INTEL_VMX dependency To: Jan Beulich CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , References: <20250901104329.25693-1-michal.orzel@amd.com> <4012a431-0d1d-400e-a0f4-b2ece3439441@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <4012a431-0d1d-400e-a0f4-b2ece3439441@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000044F7:EE_|IA0PR12MB8304:EE_ X-MS-Office365-Filtering-Correlation-Id: da757508-db03-434f-459e-08dde94a3c54 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RXVYY0t0bHM4Z0JpYWJhZkxuTlorMjNwclk0Y05tUTkrMVV6WGpMeDdQSWp0?= =?utf-8?B?c1VoTXpVZjYzQ3JvV0QzS3pxNDBjS0lvdUEweHpPSHFPd2lxSW4yMStYZWI1?= =?utf-8?B?bFFrZGNJdW9sVjR6dzhCZjhHQmc3di81dG50NEx5ZmNrdFgwK3Q5NWtBWTZp?= =?utf-8?B?YU8vSmJTR2ROejE5YU4rczE4VmNDUXp2TFp5RUZQQTJEYWoyUWlEbWFrVHAx?= =?utf-8?B?RzFFNkVSdHl4N1hYQnRTYXBQa2ZJL3dIL0pxOER1NGZkVmdkdytPanlCOTVQ?= =?utf-8?B?MlI1RXl4Y3RWMnJyeHdOWEVUWEoxMTAwRnQ0N1FaL3BMd05ZREgwMWpTaEw1?= =?utf-8?B?aHBXeGIrVkhXU1BQZ3M2Q0xZYWNkVFBzanBqU3BINHRsaTFJSTNOdzU1TGcz?= =?utf-8?B?QnBLMnFud2doSnJkSDErUXQvaUl0UzdVUGZPeE8wZ2NLMlR2QkxyVUJsOS9j?= =?utf-8?B?NXFPdDdOQ0E1T25jV2dmY3dWYWVibGVucFdiRnVmYnZld0JhdTFUM1F5Sng4?= =?utf-8?B?Vm1SK3h5SVVhdm5DSGJtaFVWb3ZISzNFd0h3SUlmLzRXU0F6OXBIOEJYTERy?= =?utf-8?B?ZHRib2NnZ1hlM21jc1BMaHYvVlFibEhnaTd3OEp1bEhERDlsMDk4dXFGeWdj?= =?utf-8?B?N0VHMG1YelR4QVdvL2VSNG5seThiVVNwMnBZcCtOKzhLZUJlVk9TRk5tbnZj?= =?utf-8?B?OW1XVkJmSnpnUWZ4OGxXS2tkUFVNM0FvcGd2Y3BhN3g1TCtjUDhiU3FzNXV2?= =?utf-8?B?ZWNLZm13K0NGdzltU3FCcGZSZFVpcDBQYnVMTFRaNkhyNHc1LzZ1OUt4b1BG?= =?utf-8?B?UzFCWGxEVlVMZE11MGNORW9zS0hxSk9UZEczNSsvQS94V2l0cDgrSEN2SjNz?= =?utf-8?B?TUR3SUMwcC93aE9rcjhXTlRaMFdZd2RDTmY3QUNpRC9LdjVaZGR2RndGOTFG?= =?utf-8?B?WjJva01OakZDREhnenNjZHJUcjdkd3J0TFVSc3IwRUdQUWtGdWorV05ydkFy?= =?utf-8?B?ZlZ1QVR6d1VwaVQ2T09hU3U1YXBMLytNWVhVa2RKRTA5MW5FU0tIeENSZDV2?= =?utf-8?B?dnl3cVFRaFZ2Y2hybmFUdDdWUkFINTZBVkZYaHUrQUhTQUppWXBBNlBURU4w?= =?utf-8?B?ZGxjMFhXdTBEQVVRaXpjSTRRV1JFenJUVEwyYWVpdHJHWjMvTmdOM210SHl6?= =?utf-8?B?ZklvaDYyVGExcFc5bEpBeXlHQlRSVjJmUU5wSzJEUktESFRnNms5TXlSNFRs?= =?utf-8?B?TmY2TE5sK050Vk0yLzJZVEJKUmYxOTArV3hPelJTT1RERURPUThTS2JMMk5X?= =?utf-8?B?Y2FwZHdVN1hQWGV0clhFb0VpbUpYZU1zVjNZRW5MQ1NyYm1xK3gwb080Njdk?= =?utf-8?B?eE9zZTBsSmxmNlZtaGRvSkFWTmZsci9aNEVGZStwR2haYmU1Tkc4WStWRmMz?= =?utf-8?B?ZkVOTU5uQlZEMUZ1eDc3bmlzQ3llNThQRjJOOGk5aGxreWYyQW15UHppTFV4?= =?utf-8?B?QnRiL3JWQ2dWek84YkJRNlRRSFdud01hWHdFOW05VTM1ZDNQb2NmeENLd2da?= =?utf-8?B?aGZnNUhXRVllemZQRWxEdjlyN21yUElNTU1PaTlRS0F4cEdrTWI1emhMa3pR?= =?utf-8?B?ejF6V3Zxc0NqeGhpVG5scGlNeEFuSG1IczQwLzQ1Tis4N2NrQTBxQThFUWUx?= =?utf-8?B?OWRFWFdQZnVtdmsrN3p1YlUzc01GaFFLUzVobElodGZKalVWR252MGQxbTZO?= =?utf-8?B?TjhSR2lVQ1BFa2NpZWJmSnIvUEszZ0ttdlZyL05jMlpZaWxmdGZDSEtDL0FY?= =?utf-8?B?OTRPdHh1ZUpiR1ZmbC9ZT2pVK2g1RFlRSnFjZnRJUHpMdkhEeVAxVkpoUUpG?= =?utf-8?B?eHVZOEU3VjFyUHh0Zkk3d0VYd2MyTktvTXBnTWcrRjQrV3lwUDFSd1JWN1Jm?= =?utf-8?B?T25EdDZNK3dKSEJZY1pxWWlrY0VyQUhEWXhLVDlLbzIybk90T28xWnBsRlFu?= =?utf-8?B?NHpCU2doMkRSMThQRE5rUkE2OEY3dDYvbDRiaGFwM1FIRDNBb29IYWRxdlFz?= =?utf-8?Q?K5sRQ/?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2025 11:25:20.4760 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: da757508-db03-434f-459e-08dde94a3c54 X-MS-Exchange-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: CO1PEPF000044F7.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8304 On 01/09/2025 13:19, Jan Beulich wrote: > On 01.09.2025 12:43, Michal Orzel wrote: >> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and >> INTEL_VMX on INTEL. Such dependency should be done using 'depends on' >> and not 'if' next to prompt that deals only with the visibility of the >> given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX >> when INTEL is disabled (option is hidden). > > Hmm, yes, just that ... > >> --- a/xen/arch/x86/hvm/Kconfig >> +++ b/xen/arch/x86/hvm/Kconfig >> @@ -16,7 +16,8 @@ menuconfig HVM >> if HVM >> >> config AMD_SVM >> - bool "AMD-V" if AMD && EXPERT >> + bool "AMD-V" if EXPERT >> + depends on AMD >> default y >> help >> Enables virtual machine extensions on platforms that implement the >> @@ -25,7 +26,8 @@ config AMD_SVM >> If in doubt, say Y. >> >> config INTEL_VMX >> - bool "Intel VT-x" if INTEL && EXPERT >> + bool "Intel VT-x" if EXPERT >> + depends on INTEL >> default y >> select ARCH_VCPU_IOREQ_COMPLETION >> help > > ... now it becomes impossible to _enable_ INTEL_VMX when INTEL is disabled, > yet which may be of interest if you target some other vendor's VMX > implementation. Perhaps really we should have > > config INTEL_VMX > bool "Intel VT-x" if EXPERT > default INTEL I did not think such configuration makes sense (VMX without INTEL) which is in line with the last sentence from the mentioned commit. I'm ok either way. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:41:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:41:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104542.1455569 (Exim 4.92) (envelope-from ) id 1ut2uj-0003oy-9Z; Mon, 01 Sep 2025 11:41:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104542.1455569; Mon, 01 Sep 2025 11:41:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut2uj-0003or-5Z; Mon, 01 Sep 2025 11:41:33 +0000 Received: by outflank-mailman (input) for mailman id 1104542; Mon, 01 Sep 2025 11:41: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 1ut2ui-0003nz-2s for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:41:32 +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 99d3c8dd-8728-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:41:29 +0200 (CEST) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b042cc397dcso105626866b.1 for ; Mon, 01 Sep 2025 04:41:29 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aff15fccb15sm654552566b.98.2025.09.01.04.41.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:41: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: 99d3c8dd-8728-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756726889; x=1757331689; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=9gF53h55/t81qctesrJN23RtwDJtucTO++o6vR9AyGM=; b=DwquACM0pORBgTNYGabh7Jv5uP9uYsMltQfYJMOfwWspVIpyZthxub/vk1ohDEWfHL GIwAmbvk/ArVdz0EIxZmcNoXrK6Ijma4Oc37Zjza/kzhJZhqS/HO6kQ68APmg6zaFIhZ KdYTSu9vRzUwdS9Gq37WTTy8Vt+wne83r8L3mP+CIn5mULOPoixwenbwXHQp0yylD72x n+HswDZklq4pqhWDmMTL53U8LthTf36X0+zHbYFfSk/2MwUijuLdfyCmb7fZ+ALP2SNW GXv8w+xBcSORs6agqku9s0IiU1D4RSZOjFeM5cIq1uzVLoiRH97f04Yc/Nuu7TvwEPcx mb0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756726889; x=1757331689; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9gF53h55/t81qctesrJN23RtwDJtucTO++o6vR9AyGM=; b=GpXBmDSmaKUqLdX0TMve1Bjv3ftYfKECJIMcDFy7+aIicbeysxMxSW4ebsxFIfzGMj G5gxsQmAbgFzF8X6D+B2oKCEedhy6fUWwIT5AxMGcIDBTCfT1zm5RLxp7n2pNhb2MUON IsXKSR/jm1vD959J9SZYY59CZ2mqs3Qn3p3F4tVUwLIORCYUyC2s6uI4o1cCFS7ZjHzJ kWrULP9za7/hVifFUzv6yczkp5IBGCWv4ziOu9zXtspY8ahrWEaBsDIgz+lbQDBVB0Zf 7bVuZvAjp9bSmfFjqXItkgT3mjOWA4tXiKZqIhQG8XtqZTkCVOsUJ/81qLMpftAChP++ hB7w== X-Forwarded-Encrypted: i=1; AJvYcCXKlQSWLiQ9eAN+L+apvE2kaLUrN3gQqbGJWS4XFZUk0ZjEzOZLhJnwaPr3JgCizdwzG8OPBlJdR3Q=@lists.xenproject.org X-Gm-Message-State: AOJu0Yznmw11x3AQWXhf3HLik4QlI1PhrGGmG8965PC92PHjpB8NTBBP PlOPm2KIsohcQgpUCjW40fwNTVD6VAtSrUNafOPLjZ0nfv5SGDTk89iDMz6XNM7QpQ== X-Gm-Gg: ASbGncsC0JXetu5eOO+pqhreRv4ocEVCELvSvtksEgYK81tnB3tnD1G2/4NNEQlv3Ly k5HcdoHffX/7TxgvnewYQqlwNEfCoOLaaLjNHNCrniCtID6RY32bOlIIvqgfQ1V14s60GR1uff6 jhPg2BMJMBPELm1UC7+U9Kb1TlAUzzzKeBn94wIhzaiCrWt7SSkQguXXuJ695sJgV13O8RXWlM8 4bPGnS8GnJVXQOkCcNQpNHhQ7uJKY1nMUrp9ITslI2LboeYCZyTiIhVR9TkNL0Ng40alfSsJAp0 ZT+GJ0igXoMUs568YnkP6e6wAjB49Wrs6V9BXgOEE2UpvZ2txBO5tqUjVX4YkK0SrNpKHSAET51 lhsB845EXqCep2CX/Y/kFwXnPgSdRWyxexbkQ8P8FbkYTpA0zC38cP2zEH5sR4rxEFyx0euZRSb +zngUimKw= X-Google-Smtp-Source: AGHT+IGceUg7TElhbBGWipz6AfH8kUzoM8OjhtVo+6udC/h+FRDMiR/HvMaRzQNu5ljSVz9UNvQQZw== X-Received: by 2002:a17:906:48d2:b0:b04:2214:9499 with SMTP id a640c23a62f3a-b04221497cfmr380016066b.8.1756726889171; Mon, 01 Sep 2025 04:41:29 -0700 (PDT) Message-ID: <7675f3d9-add2-4ed3-a2ce-ec9b676850ab@suse.com> Date: Mon, 1 Sep 2025 13:41:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/23] x86/entry: Alter how IRET faults are recognised To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-17-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: <20250828150409.901315-17-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > Right now we have two IRET instructions that can fault for guest reasons, and > the pre exception table gives handle_exception as the fixup for both. > > Instead, we can have compat_restore_all_guest() use restore_all_guest()'s IRET > which gives us just a single position to handle specially. > > In exception_with_ints_disabled(), remove search_pre_exception_table() and use > a simpler check. And, peeking ahead, a similar check will then appear for ERETU. Probably indeed a fair exchange seeing that in the next patch you drop the pre-exception stuff altogether. > Explain how the recovery works, because this isn't the first > time I've had to figure it out. > > The reference to iret_to_guest highlights that any checking here is specific > to CONFIG_PV, so exclude it in !PV builds. > > Later in exception_with_ints_disabled(), it suffices to load %ecx rather than > %rcx, and remove a stray semi-colon from the rep movsq. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:44:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:44:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104552.1455579 (Exim 4.92) (envelope-from ) id 1ut2xE-0004Lf-LD; Mon, 01 Sep 2025 11:44:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104552.1455579; Mon, 01 Sep 2025 11: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 1ut2xE-0004LY-Hl; Mon, 01 Sep 2025 11:44:08 +0000 Received: by outflank-mailman (input) for mailman id 1104552; Mon, 01 Sep 2025 11: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 1ut2xE-0004LS-7M for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:44:08 +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 f7b2451f-8728-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 13:44:07 +0200 (CEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b0411b83aafso233304766b.1 for ; Mon, 01 Sep 2025 04:44:07 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0424cc1698sm282617866b.21.2025.09.01.04.44.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:44: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: f7b2451f-8728-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756727047; x=1757331847; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=YYOniGEgcJohxqUkIJcHzCC/FI6aGs5q7b2FmE7WcAY=; b=FGiacuYDa1EK/hrttoGSW0fQOsUXVD1V13C1Nd83VToA+irgc8AWPeKMkErrJ6FkVh se/w+HjwNOhEQWNv6gWYb+2Ku4ZBHE8rN6xkrB2Y69wZ6skFZYvtda9hpiBM/S2Qj303 1nxIjrJwJmPIdTpGWPXhhN5W4L33I5z+y1BTnp04Ua7arHFbXTwSHRb/AbWF1qWN5bXe Pzsng68Ez4Xkz3udfub1QSZifyoaVuVWxGWQsRLE5jUfP+f2dEy7oUJzxrtpxriaJsvj DwdCXBzKeSFS2b7nEGyCQH8v7ksmtDCkSnQ2k0NDJLzQnG38+iTzjjSHmHOY9k+BZKSQ BVUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756727047; x=1757331847; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YYOniGEgcJohxqUkIJcHzCC/FI6aGs5q7b2FmE7WcAY=; b=bS2A07A3kaYgMEWwkqALXShvh+tXamO7b+RdA6Lpf9umKhb8NtRuDhfer3ziG79UAZ QfIIERK1g87514t5STkkpXq7/oHbu4TEs2siTL94HMjt0qQkq1i5eLKzgEfVVjLdVrDs 8hfqX5NySFwZnc7EfNcMKbdzQ0NdJAMylOVeQUJ/oMIpfDXDjPAQgxuhAoRUbHug8Vp2 csvJk5Jolj6mk5wz6qrnYJU1slzZciCvSBo6dXUI5Yzzc3hALyNmARmznvHbt3kA1eou emZ7QabpBxVZ9kbUq7DuiKUsuJz2EYmlX2x4FR8LcGTRJNxVMUYPNjixpAMy54llPLCn xjpg== X-Forwarded-Encrypted: i=1; AJvYcCXolUgLwW7sxAd+2dZe+AyDjdjv51uajnSAECvxDqH6K9PmMeI7M1KkCe+G+PiBDR9t3D7RycNRkMw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw1AnNnGDbiBoSbq3O+P56x1M4ihEBiwEe77CTDKq3SeWgLVTvP 84+DPdu3cko3slGJpTo14QMBw8fFAmjp/UmldKDHvTyLqj96kPnPkxOLn1RsbRermA== X-Gm-Gg: ASbGnct/477UJ0qgSl5b9x7Iwjch9h2qMJ+3hwu7N7q7b4n597RSQW+5KJe4BWpZspb ahX0otZidMIuaEGBluLYngAjSkzyfTJBb7pFyosDSm5hJbjBRGO8PNfCJbse1q109U+V9YkHBqB N2aKZ+8OP9xwRxRND3vKAi8M/u3jESmGfGa11GotCunqNOrx1JHde+1mSy7G+3K5KEQ0LoHtSjp iwFCz6iWLhPsM2W5w5Qz3cMr4TP5SnzsRlwqlwL0tQuy3xHXobiixd/I9wbApVJozzm3vsM6fZF 7DbEc7dG7alqRiYT7X9T+SJPaH/NSPhoFwhLMZlmlXSlbRP/U3a/M9tvZO/AGjtKVxUGzgn+4+P AeQEYilGpO1tpodL4Aw6Pq0wL0f1UqDceEG5qYP3s9FwUP3c6qsF/yYM0NWt0C3wdypQdNML+d0 kcr8ophQ0= X-Google-Smtp-Source: AGHT+IGY1Kt/D6voeF9Ad8ogPhOYR2ctCzoyAeSJ0pRbvqHN4CiASdP2kb3ZYVKe9mlbQlw1V0hy7Q== X-Received: by 2002:a17:907:97ce:b0:afe:63ae:c337 with SMTP id a640c23a62f3a-b01e6e63ebemr891759966b.57.1756727046692; Mon, 01 Sep 2025 04:44:06 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 13:44:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Fix AMD_SVM and INTEL_VMX dependency To: "Orzel, Michal" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20250901104329.25693-1-michal.orzel@amd.com> <4012a431-0d1d-400e-a0f4-b2ece3439441@suse.com> <4f59cfd8-dff6-4ac0-beda-13ccd161d628@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: <4f59cfd8-dff6-4ac0-beda-13ccd161d628@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.09.2025 13:25, Orzel, Michal wrote: > > > On 01/09/2025 13:19, Jan Beulich wrote: >> On 01.09.2025 12:43, Michal Orzel wrote: >>> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and >>> INTEL_VMX on INTEL. Such dependency should be done using 'depends on' >>> and not 'if' next to prompt that deals only with the visibility of the >>> given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX >>> when INTEL is disabled (option is hidden). >> >> Hmm, yes, just that ... >> >>> --- a/xen/arch/x86/hvm/Kconfig >>> +++ b/xen/arch/x86/hvm/Kconfig >>> @@ -16,7 +16,8 @@ menuconfig HVM >>> if HVM >>> >>> config AMD_SVM >>> - bool "AMD-V" if AMD && EXPERT >>> + bool "AMD-V" if EXPERT >>> + depends on AMD >>> default y >>> help >>> Enables virtual machine extensions on platforms that implement the >>> @@ -25,7 +26,8 @@ config AMD_SVM >>> If in doubt, say Y. >>> >>> config INTEL_VMX >>> - bool "Intel VT-x" if INTEL && EXPERT >>> + bool "Intel VT-x" if EXPERT >>> + depends on INTEL >>> default y >>> select ARCH_VCPU_IOREQ_COMPLETION >>> help >> >> ... now it becomes impossible to _enable_ INTEL_VMX when INTEL is disabled, >> yet which may be of interest if you target some other vendor's VMX >> implementation. Perhaps really we should have >> >> config INTEL_VMX >> bool "Intel VT-x" if EXPERT >> default INTEL > I did not think such configuration makes sense (VMX without INTEL) > which is in line with the last sentence from the mentioned commit. Just like Hygon CPUs support AMD's SVM (which we cover), VIA's and Shanghai iirc support VMX (which we don't cover very well, but which we also shouldn't break knowingly). Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:45:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:45:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104563.1455588 (Exim 4.92) (envelope-from ) id 1ut2yP-0004rk-Tq; Mon, 01 Sep 2025 11:45:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104563.1455588; Mon, 01 Sep 2025 11: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 1ut2yP-0004rd-RB; Mon, 01 Sep 2025 11:45:21 +0000 Received: by outflank-mailman (input) for mailman id 1104563; Mon, 01 Sep 2025 11: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 1ut2yO-0004r3-MT for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:45:20 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 223a24cf-8729-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 13:45:18 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-6188b5ae1e8so4297456a12.0 for ; Mon, 01 Sep 2025 04: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 4fb4d7f45d1cf-61cfc5622f0sm6814288a12.51.2025.09.01.04.45.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:45: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: 223a24cf-8729-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756727118; x=1757331918; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=y0RE+KMoWVJaWXr9LRXrkNGli/wYAY1F5lv9soN2lcM=; b=gK+HmZdV2e7XP2C/HCH7K59g1LTTUiSxiq5h0+u+dMe14x2HLzZLNLvceOKmBAz8gB okQIZc2Ho/niYUrLgctQse2juFLHCIBcA9mxCbbQdoOPWAZslfemPHbWeYDW1Z9BPwZR a2XyCKRwoZ3WQDgMGLFp38qoqacHyIFLe2jkdinyt1LzHID72TrdqQjA0Yszy+9yqpVa dJV3yc5v7FBXcSxqqyY5opqP1PZsw+ehLm+HZv2EogQhQpHcfUjHv8QDjSM+0RWpYDE1 kzQzCglDK1zergzndc4pE7u1woN/52/AiKlDPJyOfbxbfdQNTvrHAmk58ZDfHunIic2k g5Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756727118; x=1757331918; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=y0RE+KMoWVJaWXr9LRXrkNGli/wYAY1F5lv9soN2lcM=; b=dXtx89GMVsTc1fTzbM4L0KqwHHJQ7VxGF6CxlJYzaw4/7V9y8klwxWoVSQ7r4+ZLDW 8Hlo1RJ6Rv7bJSFK4vdU/dscIcRuxpvPNAoAdK4e2JK5zCbVRFSnWVkAkpMiVpI3BkMa SNU6dgvLfzjM2/JQ/xbIBx6fMpbtH/AkYck15dYegN/0S/j+gWgvUXkoN+TSUROMu71t 6Bo3F+NPwz5eesQFSvOtF+Y2ojz+FhkeQhr4+5VsFlnaGkErcIQ237sN1y3FUR4BY9oM 210z7AMM7rT8CTIkOf3ta+jnyxn5FfWkcqoBNlBnCye4iFuAQe6IrfBCKBOrtgnCNCAN 8pFA== X-Forwarded-Encrypted: i=1; AJvYcCWAudGB4AN/IWHzhGHFKmGNVlLf2qscQUT3Ctzt9bOxLKoj/XYBVxD40IyRq93AIyyTaXgDFPuJ+1w=@lists.xenproject.org X-Gm-Message-State: AOJu0YygsLAAcX2LHD/BSuXhbVM9pFCZYAa7Le4cTyvXjWiMlpg+U1ZJ u1YR3/LarlGHYIDz8raFELHBpZODl302zuFrzRTQGsLLk2NgH5yDZvf2DSOpzX5yLg== X-Gm-Gg: ASbGnctB8G7+PHaYHwKei2CM0R1ucVi7WC3FsfwWr5TMuUc0Ow66HgC2ilmR8+1zgS3 DdfArjhezyN/1MEc+y61CxEDG3owm5Mi+8Xyv/tLZeuLNI8BfvD8eVnO7Hme8Mzr+rgDgxVivOL PWWXmMJ5wb+qAvzoQmhWHTqlw1vOHIydtlDAukd0eQG685mYcWTT1DhbrN51vsu2Dd8I39s5vXC /AgAA8anu6AoPskoD287QOH8TfE0l0ii7i+J1L7bBA7MZGmmWadwaHSjvp/2KY4sL6DNa+2TG8y lMEg7/f71c3uvSzW5C6LmskiG6cBWULPlyXWelh61ZSz95oVRt30o2NZ8OPkO7pYl5jvvdeGIPa JLufSUPh2iahTgcBirZHZsO8Yh7VLGun6vpjuRbM0VHwJcW32YpKTBmVNIXTBsfMcq7dtFrPkhQ 41QVEsaEE= X-Google-Smtp-Source: AGHT+IE6aVeEiyJDq2dQQK8mjNLoz7wuab65QYIPgkYHNrQsj5bhB0TyMNUwP/jPUcO0250SeA/oDg== X-Received: by 2002:a05:6402:5419:b0:61c:87da:4bff with SMTP id 4fb4d7f45d1cf-61d26d7801dmr6190566a12.26.1756727118066; Mon, 01 Sep 2025 04:45:18 -0700 (PDT) Message-ID: <8d5aa0f0-9c27-4d59-b5c9-02d0b6018bbf@suse.com> Date: Mon, 1 Sep 2025 13:45:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 17/23] x86/entry: Drop the pre exception table infrastructure To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-18-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: <20250828150409.901315-18-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > It is no longer used. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 01 11:52:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 11:52:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104573.1455599 (Exim 4.92) (envelope-from ) id 1ut35d-0006hb-LG; Mon, 01 Sep 2025 11:52:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104573.1455599; Mon, 01 Sep 2025 11:52:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut35d-0006hU-Ht; Mon, 01 Sep 2025 11:52:49 +0000 Received: by outflank-mailman (input) for mailman id 1104573; Mon, 01 Sep 2025 11:52: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 1ut35c-0006hO-8n for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 11:52: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 2cf04710-872a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 13:52:46 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b0439098469so86373966b.1 for ; Mon, 01 Sep 2025 04:52: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-b040f1cf4b9sm447428466b.29.2025.09.01.04.52.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 04:52: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: 2cf04710-872a-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756727566; x=1757332366; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=qmV104QBEjNpqw2Ys6Gsfd+M4EUQ+4vG2xNg/PcZzUo=; b=OYl2g/lOtzjBIvhWe3gXSa0mUd+IA7HeHH+kCXsHkbHlYK8/Z3NUwESx8cmXz5DzFS 3yHMdGoScFCSWTR5mq5sgVThCLvZ0W2Bh22OnpjVBi9FDY2HLzZQYp87y81DxFyIoIro v7TRYdJOBDvQrK9ZcNnOKmIyHCNZMhlC5st5nCWTIX1o0v3K3k1YPRsnj26dXOxA+p4n 5/1PjFUQovTI+3kPKPpGQC0q3Bjf2gi4g3OQp5jTQz7/1pLoyNSxBOTvW1Rl9Rz6xQB+ UCjITLQblsfloUUvOaJu8b0C1h/R231vMPR2Rz10XDhdATPaDtoOeY3FreLS8ZsCO5xO aSWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756727566; x=1757332366; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qmV104QBEjNpqw2Ys6Gsfd+M4EUQ+4vG2xNg/PcZzUo=; b=DCLxcIzeeUBYnXzzZjUS6x/GxWJF4XG4HpigUjXk6N2Xny4RvNc2KX6xcIcVYJU1TW bEgx8sNynH6xggSI1MrYS6uBKS3UXlmZ+R+6PMMWQZXfVhYvMTnGTnWA9YuOtmX9Np+m iav2/cRL8vS+F2MD+8mQpSZUDR7honx5VTaO3e/aSCSuiCsUurxT3h765OFHm71lJonB BQEpSNParl3im9faBIT3kGXKHllK/hVGIA5teqnIk+WlhxtlgKfrBUNO7h/+r1BGJqg2 m1Wxh/tmp36Tso1xykFsTG7a57/ZGTjasXR7j39eMoO4pwcYxEJebs4BiLk93soGYNwp U2Hg== X-Forwarded-Encrypted: i=1; AJvYcCUXaZlL7sLxm1VwFkzD5hvYgzf+J0oTgjqjZqKxa3ZL51krlCx7fhq91coHU5tb0APnbiRvikWroZo=@lists.xenproject.org X-Gm-Message-State: AOJu0YxOR70tv4JF01lsqJsISbcLN749TtIi0gim/hbXHyJsR61nGYlF MvJHddowXDdteiAkmfGRD0AP5ntVeWg0u0Nf/plaNFx275OAOBS3bfPeiFn2iFuETw== X-Gm-Gg: ASbGncsWy1HD2aQ+UJUCzY34pf3LevppWgiuh1a+S3x1L4GME3jzau2lbXPGvTjDVzx 4Hs4DZRKXDEfYq61wrhCHzb8RINP7/cWuoNHq4zrNg0JkgSgm6dC1T3+MJlyr2ulf47G2w9Njoa sqfFO1FapFgGXuRLlNTdFmgUwdcN6/6GTpcgQKpmO7JWZQ6+TFJr1IVaFlWof0qwCcR+kVnHwZy VqpkGRO5psDINYtrUk6T+Wf/AiW86WUhBeBJtdaGqCj89iSfpM38HyxDCZpYKuOaWsBN27mgVWl 4TnbJFYcdfo9PT3y1kbKrliuAy9k5QgsJ8U2Fmdzig9U1+Vqbyqk6mo05PbEnoQQxTE/HA9WIHe hid/Wg8i04A802u0cz8oTi5dzh72lA5YKF/NjzYnAU0azFHADa/n2RPfAFZlj1/EgqSuLwLAU+N cpo8Gl7jEuDv1A+sRUYg== X-Google-Smtp-Source: AGHT+IHidb1/bgEztXlrecNbEfIoFcZsaFfK4vrTi5lLMoEobHp94F7X2nndyt05PkocqnNyd688cg== X-Received: by 2002:a17:906:6a1a:b0:ae8:4776:fbb1 with SMTP id a640c23a62f3a-b01d8a30b9dmr676952666b.11.1756727565617; Mon, 01 Sep 2025 04:52:45 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 13:52:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/23] x86/entry: Rework the comment about SYSCALL and DF To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-19-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: <20250828150409.901315-19-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > It's soon going to be needed in a second location. > > Right now it's misleading saying that nothing else would be cleared. It's > missing the more important point that SYSCALLs are treated like all other > interrupts and exceptions, and undergo normal flags handling there. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:02:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:02:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104587.1455609 (Exim 4.92) (envelope-from ) id 1ut3Ez-00009K-JW; Mon, 01 Sep 2025 12:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104587.1455609; Mon, 01 Sep 2025 12: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 1ut3Ez-00009D-Gg; Mon, 01 Sep 2025 12:02:29 +0000 Received: by outflank-mailman (input) for mailman id 1104587; Mon, 01 Sep 2025 12: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 1ut3Ey-000096-34 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:02:28 +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 87100700-872b-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 14:02:27 +0200 (CEST) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61ce4c32a36so6688253a12.3 for ; Mon, 01 Sep 2025 05:02:26 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-61cfc4e50fbsm6863232a12.38.2025.09.01.05.02.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 05:02: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: 87100700-872b-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756728146; x=1757332946; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vjx+MKORnvHcLe3MJL0fXFwxrVK0y8ZaI+76AKe8Daw=; b=ZD4qgCTTgNYiRf8pigfVHryKh2GE5IP0bmB1LFQD9OlX5JbuujqfvGJdxKhtk+DTGO KgH7J+5iWW8LmTK9jYPd+tiLG0s8UFiKCGI/4mH/qvgKqMgSvmQOLC6ZBOiL5j9Ik/Dn CepkLNkOrAtCqmtcVpqyhEW7OqXcYNsOrze81w0NgtqtuGUtZnC7yYPUIOZetoCS7OqJ 1sOLhCvkcrlaAoS+dMkWsoMQ950Jr1CvYqgLJ+Z22iTmCuWQIuyehQL/ISgR16RdYBSA oSdJvLJwePxXvXTTmRhGbSTCU6MoAZoHrdPmATgsVKop02vHmNOH+8lbMNE5Hmz6BGQp Xbyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756728146; x=1757332946; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vjx+MKORnvHcLe3MJL0fXFwxrVK0y8ZaI+76AKe8Daw=; b=pbj9wgAc1/I92arom7L/AaRVKsnT0DB4rcIfn0w1wWGWkZmDgA5EfeXM+93OmkDUrO Prp+g9k39amV/BnKHNY9UGWHUeZBHtdgwaXEx1bd+GmrWJng1Vg3I+1GOmxaR5GoOSba L0nuGkxkLFLVrKI5+zNIzWqby//80fXIpesIeDQ5g5mzdJdzVqEaV4Y5/q4WbHUaYmoi LVQoL9SQpYP486CyeEHCU3uJ3hA2aToXWLqjHHgK1WE7DHbplMgup13oZlsUYO1i/Cdk 3EdvICw8W1GTkchgp1Qs0sL1REcXDk7D6GKqThk5B2EJ7G2F/CbO8oecewaulBOLMB1p 9C0A== X-Forwarded-Encrypted: i=1; AJvYcCUSmkw/tomqKQso0zvw3uDrjeKD9wEHh25kRNYqUs2n0/5JqDTA/03cnD51rQdMwZUr4owhZ8JnUb8=@lists.xenproject.org X-Gm-Message-State: AOJu0YysDs8jj+5DmCS/LTlMXj2slaI+oSDXymhy+P4Bg8Hn+YbcwByM xmLt/fNp0KNr6lWWn09OxuOB2ig1dr7XFAA33eQYZrnfOW2WYd9VNcsohuoTdXRXYQ3AJXWSIBP tW60= X-Gm-Gg: ASbGnctiiV7n6UI6GlD5vjxYADOdVoh9lvzmkAOCx9igNFW+NnG+zL4+PB0BbAVrt1X cNCsCE6biHS2vYbRVv0V/yP5MIdeYYtmyqzEhl7/5CT3d1iWOkdxWWY616h3JJNtbtqXmP7yQpj 9IFDSbFUHUsGT5/IClpUdz+aXr1XIcOONM8MdpmhGPU4A+3TnyC2TzXsVW4lQTU50O7hNniQhRw 7i55X0gzXlR6q25q5OzpCz47h3yBniTqfw6zuqaKuXj7PU7qPH6Je7X/k6rem7cV2YXKS6gH0wH 5Jt0ZAyD0k3eN2/KtYRiPFqsqWXuXn6ulTz3NomvsKkn9IICWFNVkS6GYmokmZKyrlJtMfR8Bx5 eoqH2dACwyriFJI8+PbN1pSZlygGpW47IyJoLxgpj6kZwOqR2CGM/1Yzlt5lKhs3+zc42+DKoHP lyyANFvcY= X-Google-Smtp-Source: AGHT+IHUHCCzy05tioZ0/lis6yrJgnt6U0BBsb+xKQs7Foxnrw4rImjDUOxm/zP8VgIdTU2P7PLv4A== X-Received: by 2002:a05:6402:26c3:b0:61e:ae59:5f02 with SMTP id 4fb4d7f45d1cf-61eae59726emr411767a12.31.1756728146203; Mon, 01 Sep 2025 05:02:26 -0700 (PDT) Message-ID: <12aa8c7f-30e4-423d-9c9b-222435f91760@suse.com> Date: Mon, 1 Sep 2025 14:02:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/23] x86/pv: Adjust GS handling for FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-20-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: <20250828150409.901315-20-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.08.2025 17:04, Andrew Cooper wrote: > When FRED is active, hardware automatically swaps GS when changing privilege, > and the SWAPGS instruction is disallowed. > > For native OSes using GS as the thread local pointer this is a massive > improvement on the pre-FRED architecture, but under Xen it makes handling PV > guests more complicated. Specifically, it means that GS_BASE and GS_SHADOW > are the opposite way around in FRED mode, as opposed to IDT mode. > > This leads to the following changes: > > * In load_segments(), we have to load both GSes. Account for this in the > SWAP() condition and avoid the path with SWAGS. > > * In save_segments(), we need to read GS_KERN rather than GS_BASE. GS_SHADOW in our terminology, that is. (Also again in code comments, and there's also a variable named gs_kern.) > * In toggle_guest_mode(), we need to emulate SWAPGS. > > * In do_set_segment_base(), merge the SEGBASE_GS_{USER,KERNEL} cases and > take FRED into account when choosing which base to update. > > SEGBASE_GS_USER_SEL was already an LKGS invocation (decades before FRED) > so under FRED needs to be a simple MOV %gs. Simply skip the SWAPGSes. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v2: > * New > > I think this functions, but it's not ideal. The conditions are asymmetric and > awkward. It's not as bad as I expect it to be after reading this remark. Preferably with the naming adjusted: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:09:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:09:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104598.1455619 (Exim 4.92) (envelope-from ) id 1ut3LB-0000jm-7L; Mon, 01 Sep 2025 12:08:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104598.1455619; Mon, 01 Sep 2025 12:08:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut3LB-0000jf-41; Mon, 01 Sep 2025 12:08:53 +0000 Received: by outflank-mailman (input) for mailman id 1104598; Mon, 01 Sep 2025 12: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 1ut3L9-0000jW-Ns for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:08:51 +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 6b9fff4e-872c-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 14:08: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-out2.suse.de (Postfix) with ESMTPS id C70151F385; Mon, 1 Sep 2025 12:08: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 12585136ED; Mon, 1 Sep 2025 12:08: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 12W0AdGMtWgYIgAAD6G6ig (envelope-from ); Mon, 01 Sep 2025 12:08: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: 6b9fff4e-872c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756728529; 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=5JiO/ZByNqgku8n8EFNDr482NB/6/DdZdxtztU+Ixyk=; b=fsUNqwfwkvb4ljML52YltuiOiWHLXXu1c9ID1QfvaqRMhTVAjzXHzhWdBaH8Vj07xGS07h wPaC4dihsR01gAnh6l8gKF9BB2AreSD1Qn74pljHOpCW/HnLWve1YAzbdHHEAyIr0uMm1d kZeip5eSX8Frr4E9NKwFX2EqRmpt9V8= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756728529; 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=5JiO/ZByNqgku8n8EFNDr482NB/6/DdZdxtztU+Ixyk=; b=fsUNqwfwkvb4ljML52YltuiOiWHLXXu1c9ID1QfvaqRMhTVAjzXHzhWdBaH8Vj07xGS07h wPaC4dihsR01gAnh6l8gKF9BB2AreSD1Qn74pljHOpCW/HnLWve1YAzbdHHEAyIr0uMm1d kZeip5eSX8Frr4E9NKwFX2EqRmpt9V8= Message-ID: Date: Mon, 1 Sep 2025 14:08:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/xen: select HIBERNATE_CALLBACKS more directly To: Lukas Bulwahn , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , xen-devel@lists.xenproject.org Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Lukas Bulwahn References: <20250829070402.159390-1-lukas.bulwahn@redhat.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: <20250829070402.159390-1-lukas.bulwahn@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------q6O1OSHHaS07ejBKry005jRA" X-Spamd-Result: default: False [-5.20 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-0.992]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; FUZZY_RATELIMITED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; ARC_NA(0.00)[]; RCPT_COUNT_TWELVE(0.00)[12]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email] X-Spam-Flag: NO X-Spam-Level: X-Spam-Score: -5.20 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------q6O1OSHHaS07ejBKry005jRA Content-Type: multipart/mixed; boundary="------------cwOZ2of9v9qbRi0XLyhmwFSH"; protected-headers="v1" From: Juergen Gross To: Lukas Bulwahn , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , xen-devel@lists.xenproject.org Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Lukas Bulwahn Message-ID: Subject: Re: [PATCH] x86/xen: select HIBERNATE_CALLBACKS more directly References: <20250829070402.159390-1-lukas.bulwahn@redhat.com> In-Reply-To: <20250829070402.159390-1-lukas.bulwahn@redhat.com> --------------cwOZ2of9v9qbRi0XLyhmwFSH Content-Type: multipart/mixed; boundary="------------l251v2qxl1xEzXUYm2iYAaAt" --------------l251v2qxl1xEzXUYm2iYAaAt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjkuMDguMjUgMDk6MDQsIEx1a2FzIEJ1bHdhaG4gd3JvdGU6DQo+IEZyb206IEx1a2Fz IEJ1bHdhaG4gPGx1a2FzLmJ1bHdhaG5AcmVkaGF0LmNvbT4NCj4gDQo+IFRoZSBjb25maWcg WEVOX1NBVkVfUkVTVE9SRSdzIG9ubHkgcHVycG9zZSBpcyB0byBzZWxlY3QNCj4gSElCRVJO QVRFX0NBTExCQUNLUywgd2hlbiBjb25maWcgWEVOIGlzIHNldC4gVGhlIFhFTiBjb25maWcg ZGVmaW5pdGlvbiBjYW4NCj4gc2ltcGx5IHNlbGVjdCBISUJFUk5BVEVfQ0FMTEJBQ0tTLCB0 aG91Z2gsIGFuZCB0aGUgZGVmaW5pdGlvbiBvZg0KPiBYRU5fU0FWRV9SRVNUT1JFIGNhbiBi ZSBkcm9wcGVkLg0KPiANCj4gU28sIHJlbW92ZSB0aGlzIGluZGlyZWN0aW9uIHRocm91Z2gg WEVOX1NBVkVfUkVTVE9SRSBhbmQgc2VsZWN0DQo+IEhJQkVSTkFURV9DQUxMQkFDS1MgZGly ZWN0bHkuIEFsc28sIGRyb3AgdGhlIFhFTl9TQVZFX1JFU1RPUkUgZnJvbSB0aGUgeDg2DQo+ IHhlbiBjb25maWcgZnJhZ21lbnQuDQo+IA0KPiBObyBmdW5jdGlvbmFsIGNoYW5nZSBpbnRl bmRlZCB3aXRoIHRoaXMgY2xlYW4tdXAuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBMdWthcyBC dWx3YWhuIDxsdWthcy5idWx3YWhuQHJlZGhhdC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------l251v2qxl1xEzXUYm2iYAaAt 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----- --------------l251v2qxl1xEzXUYm2iYAaAt-- --------------cwOZ2of9v9qbRi0XLyhmwFSH-- --------------q6O1OSHHaS07ejBKry005jRA 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/Ey8FAmi1jNAFAwAAAAAACgkQsN6d1ii/Ey84 ngf+L4H9mCfMyo62hSj6cQ8Z0RNPumMoZ3SABKC7YzKF0u2m9DZba6NCAm+Srxg9U7CVAXQLaE9p IohbGuZaneP90ukzck53SSfkTJWT4iX6ad9HVcJR1fhVkLHxfSWAgmHrnKWI8iOkb4nTpeYtYWBi SxFMzp8o2yVIau72l9qSzJmMMePwSdbBJIjc/Ys9vtp9s9DTmca/8ZD3PbiqjOja19taJxxcTs5I BM74jWb4r66pAYaPTSJ/7G0EFrwDS5OsLiRfZrsN9qnPgg1oGPZuYw3I2whgAcPwjbVv9C8Fh8Zx R/LGdr77VYd6zkDqNhOC4ic8vztlYOr7hvgTFGKP7g== =HOhM -----END PGP SIGNATURE----- --------------q6O1OSHHaS07ejBKry005jRA-- From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:09:52 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:09:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104607.1455629 (Exim 4.92) (envelope-from ) id 1ut3M8-0001DW-G9; Mon, 01 Sep 2025 12:09:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104607.1455629; Mon, 01 Sep 2025 12: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 1ut3M8-0001DP-Ca; Mon, 01 Sep 2025 12:09:52 +0000 Received: by outflank-mailman (input) for mailman id 1104607; Mon, 01 Sep 2025 12:09: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 1ut3M6-0001DD-77 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:09:50 +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 8ed58a5e-872c-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 14:09:49 +0200 (CEST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b043a33b060so71522066b.1 for ; Mon, 01 Sep 2025 05:09:49 -0700 (PDT) Received: from ?IPV6:2003:e5:872d:6400:8c05:37ee:9cf6:6840? (p200300e5872d64008c0537ee9cf66840.dip0.t-ipconnect.de. [2003:e5:872d:6400:8c05:37ee:9cf6:6840]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0425ce98f1sm273772766b.67.2025.09.01.05.09.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 05: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: 8ed58a5e-872c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756728589; x=1757333389; 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=yCAxQL96obxbVkBrFpSZueJA0eDgS+0ZZivMDruOJ4M=; b=awKfMh/7JiuqjrEcyrehVJvR83MLhu1C9RdAetBeqTpCSY6ztvpdGmErp09K5w9yn2 SOBx3biOih6xwyvtwVRJiK1uoAIZDiSKpi2Hej/X7S9Dxcrc/Q/nXDxDihnkV6WuyUAg suR+LYouReMyXpxn62vNGQbAX06vwqdPugRlTZOiYHPKNbNcoI1zovpIgkgLsRj1LBAq CFnw8h8oyuzgp0MyuVk5PZXyFup8LaQmpd1G2tihRz5DTPU/oG+potTjckLbYmDKKsmp RJTBPDoqc40XZ/PmzzbilIhHHczeojRSrmsj6dVZKaplBUgfBSjNNEIfCoZaVU0SIagx Bv0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756728589; x=1757333389; 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=yCAxQL96obxbVkBrFpSZueJA0eDgS+0ZZivMDruOJ4M=; b=RBiUP7vb2d/vB2Acq0GVYprYluwRWm/zl2G2ZoPv7EiusOyh6RcHi2A+IcTvletN+c Pkn7PnXvfCvChb2YoU5qz5R2pjB6nPcjdQr+KDQWVWYmY7VH0+wMdtzKWwhNPHFM9eZT Q0pRPpJSPcpO9GgVAaZxloJdtyINmvISUy81kv/GsYwn1WcHoRegR+XFcVBS+FNuWwLo qh2Am2Itg0WjTSqflzDL1lfviF4j1nqLrMzSpfCn7y4ANJ8zANPh+/qbbyCQzMo9NY8B WZbgk28XuIUuw8mWtPTDPU8VoLdcRHGrm6vsdeq1lp5N3RZsUuKcH4cdudF1dQc/kh8o GxqA== X-Forwarded-Encrypted: i=1; AJvYcCVT5B6r/13LlaTvIleEYDOWPuWr+xzYcbzyOS7FSeXavQ40WpXjhMTpeiCG8EtwhGCh9noKLP/J4C8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWnsbvPkM1hNlwc/uYeRumyKq3dvva7XIrjpGem3GmBYyFLIXl vPteAwhj14iXJWQRgw6OU+/16hMTripzopzhx9x9uN8YqJyD2pGzlb9ZWUGw+bwO+jI= X-Gm-Gg: ASbGncvmu5bLqO+vHa3Py/G07qEjokTUk/QZjghFqtOoRsFqNEFFRZgWHHp+rUnZnc4 htLG/KJ/cJh8Lok5i99ppwKJYECADscklqhYGxbKtoFLQ0mHUORQ29jDNMsARPs4gmpu/T4pXqS gtNRCI+pR1Gz3Zj437pttIR2VF7/LltiF4PuHnTpKK7c5YKz4K98JRwbgq81X/7vMObnUvAMusa NdiVfViFwFzQcg9zJvmSNLmC9bdVQn8ZGXjNwsYQw9VhRIVxHlzZrt0tG4srbb4xnr9KH42LP/e KVAXXg95lSOZk1g0TwLwwD/4drraOjkBnjzXgHgbAXQv5TdRokopqa3PEXcpW+j5vGuCdV3py3D a9SJ/W6Vs1n1PrtxH2bB4hZ6UbCtc8o57qhk9BtUsPrihSttxwlDuZdvaY0GwX6AXc3rRvlyfVt kt5S7btTlQNCrKjeyOH8ojqPgtGVVf92daN84wQs7r4ySCn3cNwO5QY5Xjdg== X-Google-Smtp-Source: AGHT+IE1o9sx7Llhurfs0VCkuXqa4ubmx1QoJwH0Py508CsSg45Tex5LOarXjPBXfNHph1KTZXisxA== X-Received: by 2002:a17:907:3daa:b0:afe:6648:a24c with SMTP id a640c23a62f3a-b01d9774b47mr745995366b.52.1756728588793; Mon, 01 Sep 2025 05:09:48 -0700 (PDT) Message-ID: <46d27fea-d2e2-4c4d-8e0a-824f5ed6a407@suse.com> Date: Mon, 1 Sep 2025 14:09:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] Clarify the cases where BLKIF_RSP_EOPNOTSUPP can be returned. To: Mark Syms , roger.pau@citrix.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <20250828093821.372024-1-mark.syms@cloud.com> <20250829085627.407307-1-mark.syms@cloud.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: <20250829085627.407307-1-mark.syms@cloud.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------byMyp4gA4Kx9HzFtsQ58OKNy" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------byMyp4gA4Kx9HzFtsQ58OKNy Content-Type: multipart/mixed; boundary="------------tIaR4mUckT2d0V2rQ8Bs0WkR"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Mark Syms , roger.pau@citrix.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Message-ID: <46d27fea-d2e2-4c4d-8e0a-824f5ed6a407@suse.com> Subject: Re: [PATCH v2] Clarify the cases where BLKIF_RSP_EOPNOTSUPP can be returned. References: <20250828093821.372024-1-mark.syms@cloud.com> <20250829085627.407307-1-mark.syms@cloud.com> In-Reply-To: <20250829085627.407307-1-mark.syms@cloud.com> --------------tIaR4mUckT2d0V2rQ8Bs0WkR Content-Type: multipart/mixed; boundary="------------MigJa9CsFUblyYR2Gz7A6IRI" --------------MigJa9CsFUblyYR2Gz7A6IRI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjkuMDguMjUgMTA6NTYsIE1hcmsgU3ltcyB3cm90ZToNCj4gUHJldmlvdXNseSB0aGlz IHNhaWQgaXQgd291bGQgb25seSBoYXBwZW4gb24gYmFycmllciB3cml0ZXMuIEV4Y2VwdA0K PiB0aGUgZG9jdW1lbnRhdGlvbiBibG9ja3MgZm9yDQo+ICAgKiBmZWF0dXJlLWZsdXNoLWNh Y2hlDQo+ICAgKiBmZWF0dXJlLWRpc2NhcmQNCj4gDQo+IEFsc28gc2F5IHRoYXQgdGhleSBj YW4gcmV0dXJuIHRoaXMgZXJyb3IuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBNYXJrIFN5bXMg PG1hcmsuc3ltc0BjbG91ZC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxq Z3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------MigJa9CsFUblyYR2Gz7A6IRI 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----- --------------MigJa9CsFUblyYR2Gz7A6IRI-- --------------tIaR4mUckT2d0V2rQ8Bs0WkR-- --------------byMyp4gA4Kx9HzFtsQ58OKNy 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/Ey8FAmi1jQsFAwAAAAAACgkQsN6d1ii/Ey92 pQgAgXwkelNF8iU8ozztxX3W3t1wMtRPjox6/VhgSzOIIHFdvopu0DZcn+NcGseHg1LYea6xtLdm PDKVxLhbxuje3lBp/Yv0IAbEdsIEh8GkpBdFB6JP2PB23N6tGzmsCOElVM5at+6g50vUmD/w85DT s+ymEJdZROVzE7AoSYe/suQflGQgi/pyiQhcvH+551HmjOSslLIb2jnvtWGylZNF9EDlXboinKIx s/xva/5bdM/7GuNQ9s0gYO+eE7PomD4M63r4QK4I2UEV8tF29RAtqIzXdFPWpM2IV5DWMbjji1g6 waiu5bE4b9YBlA+Z2Nd71StyE6WGpnhV7rjVmrBNdg== =oXuT -----END PGP SIGNATURE----- --------------byMyp4gA4Kx9HzFtsQ58OKNy-- From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:12:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:12:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104629.1455662 (Exim 4.92) (envelope-from ) id 1ut3OC-0003DM-7B; Mon, 01 Sep 2025 12:12:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104629.1455662; Mon, 01 Sep 2025 12:12: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 1ut3OC-0003DF-4e; Mon, 01 Sep 2025 12:12:00 +0000 Received: by outflank-mailman (input) for mailman id 1104629; Mon, 01 Sep 2025 12:11:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut3OA-0003Cx-7p for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:11:58 +0000 Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazlp170130006.outbound.protection.outlook.com [2a01:111:f403:c201::6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d338dd0a-872c-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 14:11:44 +0200 (CEST) Received: from DU5PR03MB10441.eurprd03.prod.outlook.com (2603:10a6:10:516::14) by DU2PR03MB7975.eurprd03.prod.outlook.com (2603:10a6:10:2dc::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 12:11:41 +0000 Received: from DU5PR03MB10441.eurprd03.prod.outlook.com ([fe80::eeb8:470:6260:e5f4]) by DU5PR03MB10441.eurprd03.prod.outlook.com ([fe80::eeb8:470:6260:e5f4%7]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 12:11: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: d338dd0a-872c-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dFnHDe/yA6TtzA/19Ze99P5VltJixiTCsfP4Bu4UFA+8HXWScQvHrkWF9ipcWYO8kaD6BpeWAw1INxIIhXM8v+fhKJ7IfXUMSKF3o271xUvCIj9wmlAISo+BIpFL/NLm5VYHZK18N2PQ6iaRJmI03vt6EVhXXAAyYNqeLtjjScCCPeIuzgoXhU7h0+PddKg9HI68ooN4JtJp8i9GgnTnoURxGm91WUGHndRe17uhxzJh9dKzp14fPzjG01J7ZBXKYBltYplvtH63XwP+ZF04VMBB4N8SoIVh/+fkUhkBtId/Wlwoo/FvcZItjIRN7OylcTngsZ5GGRWo0GIh8Jo0bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qW+cw7U9MmbRqGza+0IxsuBpODCbeF/Y30etSfD5ICs=; b=vqvlAwLdgylE5U28xKd6kx6neowMymhE0RjH9jItGSFsYLBP/YzoNSgxO+fxLj2wBL36/aTn2mkiTgpl3PG2BWJ4MJEEUZl9nkybhBzHT910zivuw+rRIPs5Zm7VHf32dtHktumUjDdEyU1J6j0wz1Hz3/xfHnw420yhKBDAzGqrfnS0R9cjEsD5znz+d8rdPZuPtcTXGAyssTzQD+2ojZa0apm6fxfIdlcGBkdxfWsADrCA7bVrc9OHItb/HTpaQykgnfCms2g7XzAU4Ij0sA/wg6d9HmHCehjlR3VHNV2CnqeNxBUxUiwpH4UV0r/LAYe7Nlo7m9KTpDbwV/KJvA== 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=qW+cw7U9MmbRqGza+0IxsuBpODCbeF/Y30etSfD5ICs=; b=cTNM4XRiatFTsvCn16BtQkD33FJg1dNsyq23NRU/FEZpLntKiDu9Lfvfd1IfrZhSznyyHSPwWJE7IE7g3gQA8FMX0X1bJ+ya6GSbPAHJ2Ijq8x2+O9eH60Fs8AIhfsfLVfFPSw9nkl7vm2ZnHHMkrumu+SP9I05aJkIfNyq+exyD+2ACvWrDFKmc38UmEz9cd6tCAGgVHHOwwp0MRTmJA1BB6/xQW6pjKa2D8eewug/88gct4wpim3KNPDgTLzXC9xdgWnBKNA7szNZMwMeAoLD0gzCn5R0Ez4QxPoZPqYvZVzitlqToLxXNP2SL/rqdoekP7lamLTCabndi6X5MzA== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Shawn Anastasio , Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests Thread-Topic: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests Thread-Index: AQHcGfsZ6tgpa6Gn3ku7sSsKqfCAiA== Date: Mon, 1 Sep 2025 12:11:40 +0000 Message-ID: <87seh6wex0.fsf@epam.com> References: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> In-Reply-To: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Sun, 31 Aug 2025 01:10:28 +0300") 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: DU5PR03MB10441:EE_|DU2PR03MB7975:EE_ x-ms-office365-filtering-correlation-id: 15bfa4d9-427b-4f85-42b5-08dde950b55e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|42112799006|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?1UNkaQn0T/RaiCXFwLtGw/PkeqKes7o1OwEEARFLeZ8apf7t5VHumHqLcu?= =?iso-8859-1?Q?0N8byIvfkozKggqwE9e7jVAiGKvltgSGa5EccW/v+Q5qb48HsamLx4Tmm3?= =?iso-8859-1?Q?+8qxhZZqd7iYIns3M2bxbUakszfKksgR/uIb/1DfT4SIfsuiVJQ5wCK/1a?= =?iso-8859-1?Q?4u1nVmumAJP6EvGB7xImVqFRAWoV08R5A2mneKhK2qqloUzX3+mqBHC2xM?= =?iso-8859-1?Q?3OnEgEDhzDuuquQ8WwVbSzU47tIb5Rj1Lfn0zl3S1N0bFE+wGl13XmkVPM?= =?iso-8859-1?Q?ktaNd+o60/VBL2kd4izezts4Fm603V9uv9ZGMbQipilM+x/yhsnI2w2f9q?= =?iso-8859-1?Q?KnxcJZDPlKZaN9XHbW9o4MHQa/qu57vhV5/Q8jjElGDaHesJnCnN/HDeMk?= =?iso-8859-1?Q?dOxXrP36hX5nKNogq29jinaBDgD68q0DhATgph44oDFKuZY4Vqyzqcs+g8?= =?iso-8859-1?Q?W1v8x7fvbCXZUcagaAkjOb3fOeGAhdli66DRCJRmm+zN/U/6dCIUW6QI46?= =?iso-8859-1?Q?jLsJJsl0Iik4o/nfiHkQijGROWt0Q0x971pfwo5VZhQ898W9yLGySACpjD?= =?iso-8859-1?Q?W66LsgmDI0EuVqD+QHgSDsKwYdYrOgU8CzaMb90p0RMGPAfhJGg4Tr4NPk?= =?iso-8859-1?Q?c8a65vnIZbQ8lhvxkbHNCQEyeqhzKNmJnx7oU8TElev/1H93b8xqT5bi1c?= =?iso-8859-1?Q?HqGiDGD1YlLK9lA1qmEm4dYA5fyc3/pD5G2rwGXeHo37KAjWZbgbaogFIV?= =?iso-8859-1?Q?W9WlUh++yATNZdVkxAiEy0A5gi/Fdi+JuvkE4NTLQ2Td2nWAva+6ld/Emf?= =?iso-8859-1?Q?zgDoVMzZKdw38kiaJv9s3maKwlkAi9yRWdLAURUFYJblDeeP6zLmYz7R/8?= =?iso-8859-1?Q?HkomRhRqAogmogHqc83xFF4u/Y2Yf1yR5mwqVQvInPfjz1COre5wZqhwSt?= =?iso-8859-1?Q?gYe4zDaHAOoapaumOBW4MEN/h/YIK68HHcOAltSiwyK5jBk2kP+LNj+z9Q?= =?iso-8859-1?Q?2ThVS2qtYjE9ELWe33hPC/KBrAjgzpyzjJViCz0CKVsDKhmS1hvS9XjiFw?= =?iso-8859-1?Q?bQdJ+2lJrMz8u+Ou1bTFbee2z0FDr9a7EES5/zUa4ODe6sYNvmpAReU6e4?= =?iso-8859-1?Q?l7FBRCLILJdh+8r3b4hwd3YfkessiyT+aW+wtYIL0qloW0cwcegpMWR9Y3?= =?iso-8859-1?Q?bg56zIxPAR4l7jp1K0CofVzRRCsq1haQq4VCUqcFSYzXJDe5tCHpXBUr05?= =?iso-8859-1?Q?SrSEiI32/E2q233dEqo8XZG0JHyFlLjGcmIsBwcx3VUjbSkfj9SztsM+sc?= =?iso-8859-1?Q?ihW0eMNz4U99YXhj6DzKpFMYWIU5RGzih3j36Vtool5IQt+VIgiINliUAt?= =?iso-8859-1?Q?MBv0/AzDzXLWZ/d3asPHo8b8Ace+4Gu+jdqiVXCztJUE0O3fh76bTikAe7?= =?iso-8859-1?Q?vJv9hnO7gSOc8lEt1Gsj6Fs4iMe9AqrM14I5pSFAQQ90OmwtYZndxomFV4?= =?iso-8859-1?Q?HQHdBHzczbeJRtv0TCucAfTBkvs0p0hbltbN+I+BF8vw=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10441.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(42112799006)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?pF8bMIseLZvZsZ5MsRAWWhwVWpBcoNM/zjHH5vSMEj8RFCpiamPwB3D4P5?= =?iso-8859-1?Q?s8uyWhyHZzuGcvr1B3GsBODoBuVd8TBESzjP1bCYie8r23zG6mAbBBOZC7?= =?iso-8859-1?Q?/2QRp4zbEjXbnbnLEDmzE9+AACLd792Xnj5G1lAyyjUQ7JAzd7d/8meMM+?= =?iso-8859-1?Q?AvX8ZpjlRmlxzK65fj28QJzjtxec42kUkuQQvJqayVa7INeZlAkeF807rA?= =?iso-8859-1?Q?i1MYMfhXJ6ACwDQj9wQ6ZfZ23LkKN0H21UM1ZhnO8YrMZ6Uyot9HFG2kNb?= =?iso-8859-1?Q?z0y/xkEE5EPGzKoY0WFgzRQRjWmcHExesrdZqsIsw8p11lzPT4kT2OsWNL?= =?iso-8859-1?Q?/tVNx+YKs85X5Wwjy8EtXZuAnq3SCOs7bnQuCCBS7SOBrtDVWAFDbPu+KW?= =?iso-8859-1?Q?N7dpp4ABnRzy2z10wpIzv7q2QrENoaOwk9tStUgavfcgaAX3MaV8EN5siI?= =?iso-8859-1?Q?ItR70MhAJ/9K1LWGwKixjTZMJX9zp0BiqYWNZ0Hyq5BWnP+qaKxPb7ulmj?= =?iso-8859-1?Q?ZHA1Mtuyvfhz02mlrgtJiBeHJi2cfbfHuH19wAQWlnqJ6rWoQZ5coX/3L9?= =?iso-8859-1?Q?OANbDqYNH48jFI9ypCcobTu+S4W+J3+KJ6yxcR0s04IlJbT/8GFKfem3i0?= =?iso-8859-1?Q?LrL4V4WDFS67Exgd+wcXoN7IOgNkWTIiovw7+4FlE7ZqQoQ7YNtT/avcaS?= =?iso-8859-1?Q?3IoBOVgy6cfbqt9ect1Bxs25RX+RW4T6gVH3CqYfhpp8MdMxanx7Uq4Kwe?= =?iso-8859-1?Q?Sh4DHocWWOJ8TZED32aQKvXbr/SDMEVNw348IlHdlLxnQIRepF54aQtEul?= =?iso-8859-1?Q?mGydhgf0BCeVJo2MF2UsGUH9OYdQ0/nZccXk/oOuYrYSrss6RkEcW2BXYE?= =?iso-8859-1?Q?wbs1klEyHNFPrI1OTWS3J3vQTF3ZqgT2GG99mXRFGF9OwyH2GqIjvP+4dQ?= =?iso-8859-1?Q?ctvUKnStV6xQDunDsz9lu4l4RGOB1z3HuJWSK8spAfHhFwYsfUyeJ5Xvif?= =?iso-8859-1?Q?Nldiel42ZvQjm93EbVf7gXGGFPooutwpCv6LvVCTlc+yVYtecrJCrber1H?= =?iso-8859-1?Q?0o64Bubgyapwd6Z7fn6QD2/SVVEdFLycVLmPlh6irlUvKy8LVGTB0OqNs+?= =?iso-8859-1?Q?44DKT27Nsua4LelqNkOkxJKcb21AzzVGZAgw8N1HNFtB355gd2hZEEm/hC?= =?iso-8859-1?Q?lI2+89kL103AXeM2dHQ33rFJNUM+Ws144MMhvXMtK7U3XSGf32E3j1TKzQ?= =?iso-8859-1?Q?GYsCFnkjw46JRMZ60/Poa1sXEmAjGHJHZgo3Q5/agU0de0WLDodvG+XICv?= =?iso-8859-1?Q?S0nowWbfPCG9x8gcHg6b3dSWgUMyWHT+z29z3VwtBEXP2Rvz6Xs+KmeNaX?= =?iso-8859-1?Q?FJLCsU9euVg2gzogXdDZXYx6//6F/6YdPbbXRwuI9Qk3HB/OhCOpkrMmCm?= =?iso-8859-1?Q?gX29RJ0wJ5vhFWsNbfGUNXRwTQMNVRL50fe2zXPyRmpyeHiSfPeLNZAOYr?= =?iso-8859-1?Q?M2bMnDV+4sKTzZsS1ivoMWrd3foRBpqoi93qn3mCgWmsijzxs/hKN68C3J?= =?iso-8859-1?Q?IB4VSfDSJFwkCghNX4tUJLDtCBtJyu9dQLC+oSN+GGIXXB/5t0PFQUpKET?= =?iso-8859-1?Q?XAxPIs4wZ4NgVDj6qnDcf4wJ2nkzNeJ6Ru7VVTWQvF8SJir4CrO5p3Ug?= =?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: DU5PR03MB10441.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15bfa4d9-427b-4f85-42b5-08dde950b55e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 12:11:40.5481 (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: s33s/G2x0EkfH+GnQ2xnKIyx06GCaqPkgM/Lnl/5WEXZhRlkD7yk69Dfu5mbmqQpLYrK2E6o/5qEvB/PsIZpuqoGSaxwIh8R4uy11zkaF80= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB7975 Hi Mykola, Mykola Kvach writes: > From: Mykola Kvach > > Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface, > allowing guests to request suspend via the PSCI v1.0 SYSTEM_SUSPEND call > (both 32-bit and 64-bit variants). > > Implementation details: > - Add SYSTEM_SUSPEND function IDs to PSCI definitions > - Trap and handle SYSTEM_SUSPEND in vPSCI > - Allow only non-hardware domains to invoke SYSTEM_SUSPEND; return > PSCI_NOT_SUPPORTED for the hardware domain to avoid halting the system > in hwdom_shutdown() via domain_shutdown > - Require all secondary VCPUs of the calling domain to be offline before > suspend, as mandated by the PSCI specification > > The arch_domain_resume() function is an architecture-specific hook that i= s > invoked during domain resume to perform any necessary setup or restoratio= n > steps required by the platform. > > The new vpsci_vcpu_up_prepare() helper is called on the resume path to se= t up > the vCPU context (such as entry point, some system regs and context ID) b= efore > resuming a suspended guest. This keeps ARM/vPSCI-specific logic out of co= mmon > code and avoids intrusive changes to the generic resume flow. > > 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 Reviewed-by: Volodymyr Babchuk > --- > Changes in v12: > - Use the input vCPU from vpsci_vcpu_up_prepare function argument instead= of current. > - Add a check for the wake_cpu pointer on resume. > - Call arch_domain_resume() under shutdown_lock. > - Drop redundant vgic_clear_pending_irqs() call from vpsci_vcpu_up_prepar= e(). > - Cosmetic fixes. > > Changes in V11: > - introduce arch_domain_resume() and vpsci_vcpu_up_prepare(), which are n= ow > called on the resume path to avoid extra modifications to common code. > The vCPU context is now updated during domain resume. > > Changes in V10: > - small changes to the commit message reflect updates introduced in this > version of the patch. > - Comments are improved, clarified, and expanded, especially regarding PS= CI > requirements and context handling. > - An ARM-specific helper (domain_resume_nopause_helper) > - gprintk() and PRIregister are used for logging in vPSCI code. > - An isb() is added before p2m_save_state > - The is_64bit_domain check is dropped when masking the upper part of ent= ry > point and cid for SMC32 SYSTEM_SUSPEND PSCI calls > > Changes in V9: > - no functional changes > - cosmetic chnages after review > - enhance commit message and add extra comment to the code after review > > Changes in V8: > - GIC and virtual timer context must be saved when the domain suspends > - rework locking > - minor changes after code review > > Changes in V7: > - add proper locking > - minor changes after code review > > Changes in V6: > - skip execution of ctxt_switch_from for vcpu that is in paused domain > - add implementation of domain_resume without domain_pause > - add helper function to determine if vcpu is suspended or not > - ignore upper 32 bits of argument values when the domain is 64-bit > and calls the SMC32 SYSTEM_SUSPEND function > - cosmetic changes after review > > 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 functio= ns > > 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 susp= end, > 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, susp= end > 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_shutd= own > 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/domain.c | 37 ++++++++ > xen/arch/arm/include/asm/domain.h | 6 ++ > xen/arch/arm/include/asm/perfc_defn.h | 1 + > xen/arch/arm/include/asm/psci.h | 2 + > xen/arch/arm/include/asm/vpsci.h | 5 +- > xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- > xen/arch/ppc/stubs.c | 5 ++ > xen/arch/riscv/stubs.c | 5 ++ > xen/arch/x86/domain.c | 5 ++ > xen/common/domain.c | 9 ++ > xen/include/xen/domain.h | 2 + > 11 files changed, 171 insertions(+), 22 deletions(-) > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 863ae18157..7d7358abe5 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -12,6 +12,8 @@ > #include > #include > =20 > +#include > + > #include > #include > #include > @@ -27,6 +29,7 @@ > #include > #include > #include > +#include > #include > =20 > #include "vpci.h" > @@ -880,6 +883,40 @@ void arch_domain_creation_finished(struct domain *d) > p2m_domain_creation_finished(d); > } > =20 > +int arch_domain_resume(struct domain *d) > +{ > + int rc; > + typeof(d->arch.resume_ctx) *ctx =3D &d->arch.resume_ctx; > + > + if ( !d->is_shutting_down || d->shutdown_code !=3D SHUTDOWN_suspend = ) > + { > + dprintk(XENLOG_WARNING, > + "%pd: Invalid domain state for resume: is_shutting_down= =3D%d, shutdown_code=3D%d\n", > + d, d->is_shutting_down, d->shutdown_code); > + return -EINVAL; > + } > + > + /* > + * It is still possible to call domain_shutdown() with a suspend rea= son > + * via some hypercalls, such as SCHEDOP_shutdown or SCHEDOP_remote_s= hutdown. > + * In these cases, the resume context will be empty. > + * This is not expected to cause any issues, so we just warn about t= he > + * situation and return without error, allowing the existing logic t= o > + * proceed as expected. > + */ > + if ( !ctx->wake_cpu ) > + { > + dprintk(XENLOG_WARNING, "%pd: Invalid wake CPU pointer for resum= e\n", > + d); > + return 0; > + } > + > + rc =3D vpsci_vcpu_up_prepare(ctx->wake_cpu , ctx->ep, ctx->cid); > + memset(ctx, 0, sizeof(*ctx)); > + > + return rc; > +} > + > static int is_guest_pv32_psr(uint32_t psr) > { > switch (psr & PSR_MODE_MASK) > diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm= /domain.h > index a3487ca713..68185fc4d6 100644 > --- a/xen/arch/arm/include/asm/domain.h > +++ b/xen/arch/arm/include/asm/domain.h > @@ -121,6 +121,12 @@ struct arch_domain > void *tee; > #endif > =20 > + struct resume_info { > + register_t ep; > + register_t cid; > + struct vcpu *wake_cpu; > + } resume_ctx; > + > } __cacheline_aligned; > =20 > struct arch_vcpu > 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_r= eset") > 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") > =20 > PERFCOUNTER(vcpu_kick, "vcpu: notify other vcpu") > =20 > diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/p= sci.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) > =20 > #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) > =20 > /* 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..d790ab3715 100644 > --- a/xen/arch/arm/include/asm/vpsci.h > +++ b/xen/arch/arm/include/asm/vpsci.h > @@ -23,12 +23,15 @@ > #include > =20 > /* Number of function implemented by virtual PSCI (only 0.2 or later) */ > -#define VPSCI_NR_FUNCS 12 > +#define VPSCI_NR_FUNCS 14 > =20 > /* Functions handle PSCI calls from the guests */ > bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid); > bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid); > =20 > +int vpsci_vcpu_up_prepare(struct vcpu *v, register_t entry_point, > + register_t context_id); > + > #endif /* __ASM_VPSCI_H__ */ > =20 > /* > diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c > index 7ba9ccd94b..22c3a5f544 100644 > --- a/xen/arch/arm/vpsci.c > +++ b/xen/arch/arm/vpsci.c > @@ -10,32 +10,16 @@ > =20 > #include > =20 > -static int do_common_cpu_on(register_t target_cpu, register_t entry_poin= t, > - register_t context_id) > +int vpsci_vcpu_up_prepare(struct vcpu *v, register_t entry_point, > + register_t context_id) > { > - struct vcpu *v; > - struct domain *d =3D current->domain; > - struct vcpu_guest_context *ctxt; > int rc; > + struct domain *d =3D v->domain; > bool is_thumb =3D entry_point & 1; > - register_t vcpuid; > - > - vcpuid =3D vaffinity_to_vcpuid(target_cpu); > - > - if ( (v =3D domain_vcpu(d, vcpuid)) =3D=3D 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; > + struct vcpu_guest_context *ctxt; > =20 > if ( (ctxt =3D alloc_vcpu_guest_context()) =3D=3D NULL ) > - return PSCI_DENIED; > - > - vgic_clear_pending_irqs(v); > + return -ENOMEM; > =20 > memset(ctxt, 0, sizeof(*ctxt)); > ctxt->user_regs.pc64 =3D (u64) entry_point; > @@ -76,8 +60,37 @@ static int do_common_cpu_on(register_t target_cpu, reg= ister_t entry_point, > free_vcpu_guest_context(ctxt); > =20 > if ( rc < 0 ) > + return rc; > + > + return 0; > +} > + > +static int do_common_cpu_on(register_t target_cpu, register_t entry_poin= t, > + register_t context_id) > +{ > + struct vcpu *v; > + struct domain *d =3D current->domain; > + int rc; > + bool is_thumb =3D entry_point & 1; > + register_t vcpuid; > + > + vcpuid =3D vaffinity_to_vcpuid(target_cpu); > + > + if ( (v =3D domain_vcpu(d, vcpuid)) =3D=3D 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; > + > + rc =3D vpsci_vcpu_up_prepare(v, entry_point, context_id); > + if ( rc ) > return PSCI_DENIED; > =20 > + vgic_clear_pending_irqs(v); > vcpu_wake(v); > =20 > return PSCI_SUCCESS; > @@ -197,6 +210,48 @@ static void do_psci_0_2_system_reset(void) > domain_shutdown(d,SHUTDOWN_reboot); > } > =20 > +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t = cid) > +{ > + int32_t rc; > + struct vcpu *v; > + struct domain *d =3D current->domain; > + bool is_thumb =3D epoint & 1; > + > + /* THUMB set is not allowed with 64-bit domain */ > + if ( is_64bit_domain(d) && is_thumb ) > + return PSCI_INVALID_ADDRESS; > + > + /* SYSTEM_SUSPEND is not supported for the hardware domain yet */ > + if ( is_hardware_domain(d) ) > + return PSCI_NOT_SUPPORTED; > + > + /* Ensure that all CPUs other than the calling one are offline */ > + domain_lock(d); > + for_each_vcpu ( d, v ) > + { > + if ( v !=3D current && is_vcpu_online(v) ) > + { > + domain_unlock(d); > + return PSCI_DENIED; > + } > + } > + domain_unlock(d); > + > + rc =3D domain_shutdown(d, SHUTDOWN_suspend); > + if ( rc ) > + return PSCI_DENIED; > + > + d->arch.resume_ctx.ep =3D epoint; > + d->arch.resume_ctx.cid =3D cid; > + d->arch.resume_ctx.wake_cpu =3D current; > + > + gprintk(XENLOG_DEBUG, > + "SYSTEM_SUSPEND requested, epoint=3D0x%"PRIregister", cid=3D= 0x%"PRIregister"\n", > + epoint, cid); > + > + return rc; > +} > + > static int32_t do_psci_1_0_features(uint32_t psci_func_id) > { > /* /!\ Ordered by function ID and not name */ > @@ -214,6 +269,8 @@ static int32_t do_psci_1_0_features(uint32_t psci_fun= c_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 +401,23 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, u= int32_t fid) > return true; > } > =20 > + case PSCI_1_0_FN32_SYSTEM_SUSPEND: > + case PSCI_1_0_FN64_SYSTEM_SUSPEND: > + { > + register_t epoint =3D PSCI_ARG(regs, 1); > + register_t cid =3D PSCI_ARG(regs, 2); > + > + if ( fid =3D=3D PSCI_1_0_FN32_SYSTEM_SUSPEND ) > + { > + epoint &=3D GENMASK(31, 0); > + cid &=3D GENMASK(31, 0); > + } > + > + perfc_incr(vpsci_system_suspend); > + PSCI_SET_RESULT(regs, do_psci_1_0_system_suspend(epoint, cid)); > + return true; > + } > + > default: > return false; > } > diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c > index bdaf474c5c..0db0627b5c 100644 > --- a/xen/arch/ppc/stubs.c > +++ b/xen/arch/ppc/stubs.c > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *d) > BUG_ON("unimplemented"); > } > =20 > +int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > + > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > { > BUG_ON("unimplemented"); > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > index 1a8c86cd8d..52532ae14d 100644 > --- a/xen/arch/riscv/stubs.c > +++ b/xen/arch/riscv/stubs.c > @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain *d) > BUG_ON("unimplemented"); > } > =20 > +int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > + > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > { > BUG_ON("unimplemented"); > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index 19fd86ce88..94a06bc697 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct domain *= d) > hvm_domain_creation_finished(d); > } > =20 > +int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > + > #ifdef CONFIG_COMPAT > #define xen_vcpu_guest_context vcpu_guest_context > #define fpu_ctxt fpu_ctxt.x > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 104e917f07..667017c5e1 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -1352,6 +1352,7 @@ int domain_shutdown(struct domain *d, u8 reason) > void domain_resume(struct domain *d) > { > struct vcpu *v; > + int rc; > =20 > /* > * Some code paths assume that shutdown status does not get reset un= der > @@ -1361,6 +1362,13 @@ void domain_resume(struct domain *d) > =20 > spin_lock(&d->shutdown_lock); > =20 > + rc =3D arch_domain_resume(d); > + if ( rc ) > + { > + printk("%pd: Failed to resume domain (ret %d)\n", d, rc); > + goto fail; > + } > + > d->is_shutting_down =3D d->is_shut_down =3D 0; > d->shutdown_code =3D SHUTDOWN_CODE_INVALID; > =20 > @@ -1371,6 +1379,7 @@ void domain_resume(struct domain *d) > v->paused_for_shutdown =3D 0; > } > =20 > + fail: > spin_unlock(&d->shutdown_lock); > =20 > domain_unpause(d); > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h > index e10baf2615..5f77ffadf1 100644 > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -109,6 +109,8 @@ int arch_domain_soft_reset(struct domain *d); > =20 > void arch_domain_creation_finished(struct domain *d); > =20 > +int arch_domain_resume(struct domain *d); > + > void arch_p2m_set_access_required(struct domain *d, bool access_required= ); > =20 > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c); --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:24:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:24:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104646.1455689 (Exim 4.92) (envelope-from ) id 1ut3Zo-00058V-Eh; Mon, 01 Sep 2025 12:24:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104646.1455689; Mon, 01 Sep 2025 12:24:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut3Zo-00058O-Bu; Mon, 01 Sep 2025 12:24:00 +0000 Received: by outflank-mailman (input) for mailman id 1104646; Mon, 01 Sep 2025 12: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 1ut3Zm-00058I-CD for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:23:58 +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 8776f9f6-872e-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 14:23:56 +0200 (CEST) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-afede1b3d05so719600766b.2 for ; Mon, 01 Sep 2025 05:23: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-aff104fcdd5sm700706966b.55.2025.09.01.05.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 05:23: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: 8776f9f6-872e-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756729435; x=1757334235; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=9ICf4Z1OI9cz3RcvcYspDyjxfK1HZRvacT3ENaDNmmE=; b=PRIlMvCWv1w2PxSKgTka+7cWxwuQVGWiKokJzucjqDJhITgSR06e4w5o/d3UTOvmoI Xe8cAX3CifuXS6zk8MY8XUBguxFA6Hu5dfJb0Xulp80LQ6DV0Wds2RTuRXWmk5miwDPj cv5VnF4xco9V350z3AHqHqJbpn1Y9GbddB1RXKgXRRoYRDDsObCyPsjQll66uOXA+baf 7EOmlt321NZKWb1NwWONmbE4lrM5HCBShKMlIS8J2Vc8ovWcGaAxZ/ZARtG09EWJuS9f kA/XQJbRRYsKRQiE53Pbzl7kHkIA8KzK5IQQXKxMuCOl2i3LQN08eINg5irwSZ+5OrTB 8YIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756729435; x=1757334235; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9ICf4Z1OI9cz3RcvcYspDyjxfK1HZRvacT3ENaDNmmE=; b=WM2kDJhFcbg3A/nAZo7j9Rpr4LRyQeaQQ3hcjI70ndAwpKKjGcTpGA24R+EqKdSGhm GfJVQnu6n1pueGXegig52JOIMR6kskVd4dCPCXIAa1lulBZWoMF11tTz/fAKfkvoNBM5 hG0eJHAuoPSvemf70Urwf1mrE8kgcZM8i662CO7Xd9I5RnBD3qn2cj3o557gNhjsh9OP Mc3ggwgpGuIgI6EPUwHXrXwK/4kJ7yTte0lGYnHccLkrpmFBOW7oxPgEvvv6oHG/4gnC osQcvHQUNvAdi8y6EJLuf2SwSmwE81/3KFl0QuoFJALOuk6okSo5MQuLeTP2pBkr+F4M 4M8A== X-Forwarded-Encrypted: i=1; AJvYcCUHpPtZbgn6i/63Xh+2AW5K9TL5+w+Vjcw1F6rxd12/CGrw/dC2FOsNsrTvvl+0hqvVyj54Xq5ZaWk=@lists.xenproject.org X-Gm-Message-State: AOJu0YyniuwKUeJq3j95942U2xNQnZQvkOhlL1fbY2tpU8efE65IPg6p d1yy2M7DJ4pCZcy9Vnhr7jeLNfd6z37J232SGdmsWJNNDI3fMhZkWT6viiZmTt7q/ZyXm7LXX8N RbHw= X-Gm-Gg: ASbGncvXHDl4u5d/vaQCKKjLRzOWUQAZZN/W2uEYVj62EX1psHRThCAPD5IC/9oW3Po IuuiCF/JjAyPi8ehW5j9UApwQJdsfKn4qO5I4C6leEk7eEaiifAAXzNYAyx/I3ttoqW6HKGFHDF bGd62hWA1mohmcPf4/uqR+xFG1cGVaQC7WQUY9C08yA6du3uLFyCxK86+Ilc3uOlP/GGryqeanv KPTQa1lUo9F57oeypZPQUyNBhZ4oJ7LYZPd16TVH7shlM9aVerlBiN1SLnZEzUSkaqrdNYfIHgA lI8Go2pJClPSGIwdMlsjUxNh2pTd+j4iawq5lv8DKHaNkOa7LgvcGA9zteLejwH/QlO+xqyrpVX stPlZE6O50czqkes8jmdxSxur36FZ/rcW9MfzYIioCQfT9+nn0t37c0sF0b8H7Dd6k2EZ/8h8dC /MIK+ZJ30= X-Google-Smtp-Source: AGHT+IFNOY2tOo4qDEdbgY+RWjV4ljJE/6u98kg+2/jQo2uGXNX9X61XahggRZK9mRfoLWnPJrOvHg== X-Received: by 2002:a17:906:6a20:b0:afe:dbfb:b123 with SMTP id a640c23a62f3a-b01f20c7034mr749593766b.64.1756729435440; Mon, 01 Sep 2025 05:23:55 -0700 (PDT) Message-ID: <107e57a0-6f13-4827-8548-ef17d10136e5@suse.com> Date: Mon, 1 Sep 2025 14:23:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 20/23] x86/pv: Exception handling in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-21-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: <20250828150409.901315-21-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct cpu_user_regs *regs, bool ist_exit) > > void asmlinkage entry_from_pv(struct cpu_user_regs *regs) > { > + struct fred_info *fi = cpu_regs_fred_info(regs); > + uint8_t type = regs->fred_ss.type; > + uint8_t vec = regs->fred_ss.vector; > + > /* Copy fred_ss.vector into entry_vector as IDT delivery would have done. */ > - regs->entry_vector = regs->fred_ss.vector; > + regs->entry_vector = vec; > + > + if ( !IS_ENABLED(CONFIG_PV) ) > + goto fatal; > + > + /* > + * First, handle the asynchronous or fatal events. These are either > + * unrelated to the interrupted context, or may not have valid context > + * recorded, and all have special rules on how/whether to re-enable IRQs. > + */ > + switch ( type ) > + { > + case X86_ET_EXT_INTR: > + return do_IRQ(regs); > > + case X86_ET_NMI: > + return do_nmi(regs); > + > + case X86_ET_HW_EXC: > + switch ( vec ) > + { > + case X86_EXC_DF: return do_double_fault(regs); > + case X86_EXC_MC: return do_machine_check(regs); > + } > + break; > + } This switch() is identical to entry_from_xen()'s. Fold into a helper? > + /* > + * With the asynchronous events handled, what remains are the synchronous > + * ones. Guest context always had interrupts enabled. > + */ > + local_irq_enable(); In the comment, maybe s/Guest/PV guest/? > + switch ( type ) > + { > + case X86_ET_HW_EXC: > + case X86_ET_PRIV_SW_EXC: > + case X86_ET_SW_EXC: > + switch ( vec ) > + { > + case X86_EXC_PF: handle_PF(regs, fi->edata); break; > + case X86_EXC_GP: do_general_protection(regs); break; > + case X86_EXC_UD: do_invalid_op(regs); break; > + case X86_EXC_NM: do_device_not_available(regs); break; > + case X86_EXC_BP: do_int3(regs); break; > + case X86_EXC_DB: handle_DB(regs, fi->edata); break; > + > + case X86_EXC_DE: > + case X86_EXC_OF: > + case X86_EXC_BR: > + case X86_EXC_NP: > + case X86_EXC_SS: > + case X86_EXC_MF: > + case X86_EXC_AC: > + case X86_EXC_XM: > + do_trap(regs); > + break; > + > + case X86_EXC_CP: do_entry_CP(regs); break; > + > + default: > + goto fatal; > + } > + break; This again looks identical to when entry_from_xen() has. Maybe, instead of a helper for each switch(), we could have a common always-inline function (with all necessary parametrization) that both invoke? > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -63,7 +63,7 @@ UNLIKELY_END(syscall_no_callback) > /* Conditionally clear DF */ > and %esi, UREGS_eflags(%rsp) > /* %rbx: struct vcpu */ > -test_all_events: > +LABEL(test_all_events, 0) > ASSERT_NOT_IN_ATOMIC > cli # tests must not race interrupts > /*test_softirqs:*/ > @@ -152,6 +152,8 @@ END(switch_to_kernel) > FUNC_LOCAL(restore_all_guest) > ASSERT_INTERRUPTS_DISABLED > > + ALTERNATIVE "", "jmp eretu_exit_to_guest", X86_FEATURE_XEN_FRED > + > /* Stash guest SPEC_CTRL value while we can read struct vcpu. */ > mov VCPU_arch_msrs(%rbx), %rdx I assume it's deliberate that you don't "consume" this insn into the alternative, but without the description saying anything it's not quite clear why. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:31:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:31:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104668.1455699 (Exim 4.92) (envelope-from ) id 1ut3h3-0006uf-Bc; Mon, 01 Sep 2025 12:31:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104668.1455699; Mon, 01 Sep 2025 12: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 1ut3h3-0006uY-8C; Mon, 01 Sep 2025 12:31:29 +0000 Received: by outflank-mailman (input) for mailman id 1104668; Mon, 01 Sep 2025 12: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 1ut3h1-0006uS-Mk for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:31:27 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20601.outbound.protection.outlook.com [2a01:111:f403:2009::601]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 929f6354-872f-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 14:31:25 +0200 (CEST) Received: from MW4PR04CA0139.namprd04.prod.outlook.com (2603:10b6:303:84::24) by DS0PR12MB7557.namprd12.prod.outlook.com (2603:10b6:8:130::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.24; Mon, 1 Sep 2025 12:31:20 +0000 Received: from SJ5PEPF000001F4.namprd05.prod.outlook.com (2603:10b6:303:84:cafe::d4) by MW4PR04CA0139.outlook.office365.com (2603:10b6:303:84::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Mon, 1 Sep 2025 12:31:19 +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.9094.14 via Frontend Transport; Mon, 1 Sep 2025 12:31:19 +0000 Received: from satlexmb07.amd.com (10.181.42.216) 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, 1 Sep 2025 07:31:18 -0500 Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Mon, 1 Sep 2025 05:31:18 -0700 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; Mon, 1 Sep 2025 07:31: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: 929f6354-872f-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PFKkVpVgr2XTVtSAAqL573ZNe7lSimJRG3taNV0kWoY4DHzl/rRKaYMgfY3xUnIuF0lR1m2LBStNE4e5A218G1jc8xXBcpw9rQRyCvNzDjHtMj8o9xIwB0G6xJpnitCpcNYDwI+I1GNopxTxnqF26Y1D65tc+6BH0SbFJhn0x0hPUc0WzWv/LIwNo12h61iuyt0qZPYd8z3n7LcNewL6uLGc3c/G0SdqsrfewlQu2YFe8Ldm0q8z0OWql5Lcc6SWm4kL2BtZqyOj4aFkaW/AZPa4QP9GqppJvc4125zhuRKMSRbvYZ0W0Jd871+r0Ga8VE+1oUg8btmyqY/VeZRrSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZINCsSVfi528h5fUVouY6U4yEbjaaOkc6p5bmzSrQsY=; b=RYIPpE83wJ1WPYUexb3iXSjemkAmIcOWaKhapE3sxX6AbDaq813+dZANU/f0SpsoJiEIEHCZ7F8IE8yzVgMakt77byygR/gLg+4SsGXueoejSfWqgQO/iUxI0r18MQ5E9fC9LV3ZXBuA39XcRkQ3FlPpdZPqwtS+Y06kXyAQhWGSJLQNES5B5Cb5TX6c0Z5UaOZK2FMabQfdXXbjV1JLYghrzTm0yJvWs2kCtR79j3KBEDqADasK76Z/G3cvqNN58s91WfIEfMmCogcLyF9TsuScNFijhapMlmFUAvPbkNopB24Y264tBBxs9Vyd4W4rWUvzQnkiLQvdkAwaDaglvw== 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=ZINCsSVfi528h5fUVouY6U4yEbjaaOkc6p5bmzSrQsY=; b=SE5Ml0EpY7d3S+3u04jORFIq8uXTWNVyPL1YdF2I8otoTzeVC3iaFbMeHnDepK5Tkd6jb20ixhW9jtEFMwd3Xn/xhvsEGASWhG3eJaZMlv7Gpa3Q60leQEe4aO05efE+9YBW2zvac/dhI33LCv20eoQC5ob6/BB06Enf0BGF56Q= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 Subject: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of device tree Date: Mon, 1 Sep 2025 13:31:03 +0100 Message-ID: <20250901123103.11418-1-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F4:EE_|DS0PR12MB7557:EE_ X-MS-Office365-Filtering-Correlation-Id: 93d8869b-bedb-4074-d30c-08dde95373dd 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?QWJua0QwSVl0UDJ3K0NRWVhQYWFSRXFRdENWZVpPMzRWRXJxb3RSVGFWNHc1?= =?utf-8?B?KzZsZngzNnJOU2F4QTdiQXp6all0cFZMZFVUenZjTnFtMmJVMkE4WUhaRmts?= =?utf-8?B?UklINVREOG9lL1dOcm4vYStKbEpPbnByUHhyVGtZNXNVTVY5d0tZUVI2L2xN?= =?utf-8?B?WEljZG8rZUNmbXVYa3JRSlpvM09VQkREVzJCVkd3THF0NUFRRHNPMkp6YlFl?= =?utf-8?B?Z0lIeURpYWdHNHcxemNmb0Jxc0t4YWNBNVYvMmRJL05HOEdWV2dOQ1NnY2dk?= =?utf-8?B?TGVnWE5RYm9ZS3prM2lnS2FldlJFR1JJN01YMXo1eEc1Q1NpSURFZTZ1N3F2?= =?utf-8?B?NlpwNUJmQTM1R1pBUGlxc2JBRGNGam1hYU42VjhXWEV3a005YVF6Z0c0ekdJ?= =?utf-8?B?QTNVMzJxOGFqMnhiY0VhazQvMFhHRDRIMnBDMHdxdHBEM3haTHdvMzE2Y3lm?= =?utf-8?B?dUdvUXNIUlJmOXlmNWN0VmZtUXpCR3RVb1JoNE44aWNVUERNUndpZG5yeGpV?= =?utf-8?B?WGxPcmhaZ3dYUEtUVUNMS05HNSsxNEVBVlZrSFhiZy91Y0NmZU9DL1dNT0Mr?= =?utf-8?B?R1Vqb2QwZGMyUm5oaWVUQ2Jvd3FEdjdBdGFmcXlmWnB2b2lMWjBhWmZ6NXlu?= =?utf-8?B?ZVloZmVlUUx6U2FRemtIV2lOM3d6MnJqZW1DcmExSVhPK0YrU2l0SkkxSHFN?= =?utf-8?B?VnhWY3VBckFjdmh5OGEwSk1YMWhVVTFQaS83VktoVjJMUEJIZjFiQzQ1VkRN?= =?utf-8?B?cUdRQVFFeVk5TnhUcXN6b1pjanJLTUFMT0RmM1h1VzNJcGRHdWQ4Q1ZHbXhE?= =?utf-8?B?UHk2R2VxRDNPOFZwSWJGNmt5N1A5SUx2M3BaYW5OOFJTRytHZmxrL3lFZzNH?= =?utf-8?B?czVtREVNMzhvUW5WbmRzbzdVZjA4ajhUMTJjNXhHMnkwZnhRT25GOElKYWNs?= =?utf-8?B?NDRpWnRWQ0JnK2FiNnVobFlnZ2J3b2djYjZteXY1aWR6NkFCNDBFbnBwMHRL?= =?utf-8?B?Nmx6NFZIekpyRUIyVnVZakZ2aGdUYkYzSkU2WDNIOXRrdW80YmdoZkFaWUdZ?= =?utf-8?B?MWp0QUVxamNhWjE4WlJHUDV3UWxxTzlqZktQbDVkRXByT3B4WnhvKzBKa3Ux?= =?utf-8?B?akEzS1pYc2Y5UTg4MTR5c3ZZNEZYdWNGYzVUVmhvaGxibC8vbk1oSWdJVTZk?= =?utf-8?B?WFkzbWxjOHY1UkVlbzIxU0hKdlJIUGhoeXNnNGRTOFk5RnA4a2wxV1grQWpQ?= =?utf-8?B?Y3RTZWNSdlM4UHRxd3hIRW0rZVFrUHp1dUI5OU84eXZqeVc4YktuYUxJQkdG?= =?utf-8?B?YjcxbDRnRk91RE9UU1ZTS1llMmZmUVF6VEN0MDFqY3dTVE5mb0VnaE85SC82?= =?utf-8?B?YnlZcDY0Q0l6alJBVnY5Q090blR1V1pqbC9LbE9qVmRUZjRrUk9LS3laeFo5?= =?utf-8?B?UFdiT1daWlVNd3ppZ3p6U21uSU5qeitMV2Y0WkdzZUlPWUZUdFV1MnZyajhP?= =?utf-8?B?U2FKUWFycUZMS3dpMkZ2LzBIazgzRDFuaUdIN3liR1oxd0U1cXFJVnY0STJD?= =?utf-8?B?anNXQm9qYUtFclNsSzB2RnhuUmcwN0d0ZC9QN2lmQVhwOVdoeVVHck40MUQz?= =?utf-8?B?dHh5ZjFiMFgvMCtYTVRFU3ZMMkNKMzd6dGpreFdvYUNTK2NpZlBtK252UVBz?= =?utf-8?B?QnA1Rm1TamlaM2QrM240bHByNlFiY1VpTU5uVkNTZXhMR09aTDNvVWFoT3Ar?= =?utf-8?B?Q20ybDY3N2F6cktFdURXNEtPYWNnWlQvb0R4OEFWNHA2NzdwWDEyWHVrUGg5?= =?utf-8?B?SjJkbDJkOWpxRlpCM3dLalpYcktEQXl5OTNsaUNNKzgxRDArdTdZN3M2R1Z1?= =?utf-8?B?TThjVHhzTTlSSFVScytmZUt2UlF3ZkRvYjFOeEl1WjUwb290WCtzZm9oeWpV?= =?utf-8?B?TUZTVzY1UWRqTmpHeHJhZTFXUzNEQWNNa0N4NXBsK2FRUmsvRnQzaGx3b3g2?= =?utf-8?B?enhZbTRGdlpBZi9xMVZFY21GZ3NiYkRKSWJIYWpPalM3L2w2ZUN1ampvVHND?= =?utf-8?Q?mj6NDm?= 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: 01 Sep 2025 12:31:19.0611 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 93d8869b-bedb-4074-d30c-08dde95373dd X-MS-Exchange-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: DS0PR12MB7557 Xen gives a panic if certain nodes are not present in the device tree. In order to prevent this panic, scripts/dt_sanity.py is written so that it checks if the node/s are present. If the node/s are not present, the script gives an error. User is expected to run the script against the device tree before booting Xen with dtb. Signed-off-by: Ayan Kumar Halder --- Hi, In some of the discussions with the safety experts and upstream folks, one issue that kept coming up is there are lots of ‘faulty system configuration’ and ‘impossible conditions’ checks in Xen. While these conditions can rarely occur, Xen would panic if any of such condition does occur. For example, during bootup, Xen parses the device tree . It checks if the device tree nodes are present for timer, interrupt-controller, memory, cpu, etc. If these nodes are not present, Xen panics. As part of safety certification, we have 3 aims :- 1. We want to reduce the instances where Xen can panic. This is to improve the robustness. 2. We need to define a safe state when a fault is triggered in Xen. As faults (like the one mentioned here) are triggered during boot time and it is due to incorrect system configuration in device tree, it is hard to define a safe state. 3. Avoid validating all the instances of system configuration errors. By having an external tool, we push the responsibility to the system integrator. The system integrator needs to run the tool to validate all the properties that Xen checks for. This can be a justification for the coverage gap for those checks in Xen. Thus, I have come up with the attached python script. In the script, we parse the device tree to check if the nodes with the compatible properties (as specified in config file) are present. If not, the script will throw an error. README.md | 13 +++++++++++++ scripts/dt_sanity.py | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 scripts/dt_sanity.py diff --git a/README.md b/README.md index 7b68cf5..413de3f 100644 --- a/README.md +++ b/README.md @@ -456,3 +456,16 @@ This section defines config file debug options - DBG_FDT_PRINT_CHOSEN specifies that U-Boot script command to print DT "chosen" node will be added to the boot script. + +## dt_sanity.py + +This script parses xen device tree source and checks if the required nodes are +present. If not, the script gives an error. + +To use it, first write a config file like `config` where you can keep the +compatible strings to be checked: + +``` +arm,gic-v3 +arm,armv8-timer +``` diff --git a/scripts/dt_sanity.py b/scripts/dt_sanity.py new file mode 100644 index 0000000..171947f --- /dev/null +++ b/scripts/dt_sanity.py @@ -0,0 +1,33 @@ +import argparse +from pydevicetree import Devicetree +import sys + +def load_compatible_strings(config_path): + with open(config_path, 'r') as file: + return [line.strip() for line in file if line.strip()] + +def check_compatible_nodes(dts_path): + # Parse the DTS file + tree = Devicetree.parseFile(dts_path) + + # Search nodes for compatible properties in the global array + for compatible in compatible_strings: + nodes = tree.match(compatible) + if len(nodes) == 0: + print(f"Error: Node with compatible '{compatible}' not found.") + sys.exit(1) + +if __name__ == "__main__": + # Set up argument parser + parser = argparse.ArgumentParser(description="Check for Xen specific nodes in a DTS file.") + parser.add_argument("dts_file", help="Path to the DTS file") + parser.add_argument("config_file", help="Path to the configuration file with compatible strings") + + # Parse arguments + args = parser.parse_args() + + # Load compatible strings from the config file + compatible_strings = load_compatible_strings(args.config_file) + + # Use the provided DTS file path + check_compatible_nodes(args.dts_file) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:38:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:38:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104679.1455708 (Exim 4.92) (envelope-from ) id 1ut3oE-0007We-25; Mon, 01 Sep 2025 12:38:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104679.1455708; Mon, 01 Sep 2025 12:38: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 1ut3oD-0007WX-Vi; Mon, 01 Sep 2025 12:38:53 +0000 Received: by outflank-mailman (input) for mailman id 1104679; Mon, 01 Sep 2025 12:38: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 1ut3oC-0007WR-R8 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:38:53 +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 9cd7aab8-8730-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 14:38:51 +0200 (CEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55f687fd3bdso3909652e87.1 for ; Mon, 01 Sep 2025 05:38:50 -0700 (PDT) Received: from [192.168.0.110] ([91.123.151.69]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55f676dd3desm2902402e87.25.2025.09.01.05.38.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 05:38: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: 9cd7aab8-8730-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756730330; x=1757335130; 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=W5KZDGAU6uHsI56YAmTJsS6NA4BS5GthUdRh1R6Wor0=; b=JJfZQhZ5DTtzJBRdZy+7LZoQ1AuZc5lX5GUspWJQQ4hXsiw22T5Vr+FivDS7ofC2+m tA9H8tiINoKXTOsHqQxNy9ogdi9ui0AAVVlZPhUe4uE0HkVt1i73EQ5RrqLoUVQ5baRO HET7jzFA7jeKAys3ERkQNJJ/rw03AMeOjVONuEwz9NCt0QeQ1TASP6DcgqifiB4LeV0K 5EJy2WemoyfA8fFwBzewjn2PU4evqFMnZPF6Idma315kUSrSMcRgzt1CkgnYoNiDzRlI vZ9Sl57FLvlaF82GfXVyyQtT3fBUYi3lHU5eCyQm8SphxmL7T+pn0xJhcRhZ76/CmqwS /SGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756730330; x=1757335130; 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=W5KZDGAU6uHsI56YAmTJsS6NA4BS5GthUdRh1R6Wor0=; b=a162tcPR9UNT3ULyRlo8VBhstq15Sst7fdJHIYpUtktYIeE1adCOL1R+vGqy56zLvG ORZ6i8vD8CqoLKKftcnoqoL0vk+BbdDLVXn2aCatZ8LQ/RTvvS8UCw5PO/6Ib9omaj0A CtFeIwyk5bbmvUWU/Nv6pV8KG89+5uMwz+tPpAmaJILwUAXfr17kocJ/vc0hFgUShlU5 BFlq8mgT2d3CriF1KFXMOr0JDELu2D44lM61uICVn2knDxuD02uM6XjBdY0z2RklsP45 ZbsmgPvqyHgfyDhlBvEKX6cHkPkQfBRHpRcLJumdQc1j2VOEDEvlkJ6RhDfxa2VdREcN pSTw== X-Forwarded-Encrypted: i=1; AJvYcCWFZqzPHvoNFWmIYZKJkvhimrUNOiXlSq3HQLYewRgLIK76esqy8zpPVYvnDFW/lJgR5slIvnQvi4U=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw+jFFSNgbTie5PFQG0QoM00y06ZurtY9A/xDhzZ0I/YW/vDx67 o0cTBY6000l9SWDW8gFw8jbcMW7PhkFNXGWg7cRWTXtFbcLdsSGhhCu+ X-Gm-Gg: ASbGncuRfAIXMYWCc9QG7lBVQGnffRR73sIzJQmfUPysl7Clk6BjcjP5AGbKQOU6+4u KdvMJROwhFSdfy0LpDg89D6labKvrvhb+U+Wh+qtH5E65rRlGRnWiAT+bk34Y/kXKQVA4YD034b 14ydjhcq6byMCoEpn5W/57E0nPu4RFyxrVVOpD7mrgkcs8nujJPwyhxnzya/VVhxI5mKtpn1vyn RuJd4s8srQqslC4vuTuyB7D+XPC7dwn0C5o0KP3z3mINyYYgtN7QRAjiolY29Yrvo/q/eGsm13m SrWb5AQegKd3sAYq1Zhd+ev/2t1BFl/ltN+GWhbQ2KS3tzgRZlNuNhqTnMXQM+6K79cZvF8e2wB e0H8M7YfY9Fo6qETWBHleolmLlg== X-Google-Smtp-Source: AGHT+IHA5cb7okNZqRUj5D753WyAv/0lvyTfAMafRDwdW1I0uhD/gq1TDtceAvHvxHOSQNtcLVhkGQ== X-Received: by 2002:a05:6512:671c:b0:55f:6c08:a15a with SMTP id 2adb3069b0e04-55f70905fe3mr1748753e87.32.1756730329785; Mon, 01 Sep 2025 05:38:49 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 15:38:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 29.08.25 19:06, Leonid Komarianskyi wrote: Hello Leonid > Implemented support for GICv3.1 extended SPI registers for vGICv3, > allowing the emulation of eSPI-specific behavior for guest domains. > The implementation includes read and write emulation for eSPI-related > registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others), > following a similar approach to the handling of regular SPIs. > > The eSPI registers, previously located in reserved address ranges, > are now adjusted to support MMIO read and write operations correctly > when CONFIG_GICV3_ESPI is enabled. > > The availability of eSPIs and the number of emulated extended SPIs > for guest domains is reported by setting the appropriate bits in the > GICD_TYPER register, based on the number of eSPIs requested by the > domain and supported by the hardware. In cases where the configuration > option is disabled, the hardware does not support eSPIs, or the domain > does not request such interrupts, the functionality remains unchanged. > > Signed-off-by: Leonid Komarianskyi > > --- > Changes in V5: > - since eSPI-specific defines and macros are now available even when the > appropriate config is disabled, this allows us to remove many > #ifdef guards and reuse the existing code for regular SPIs for eSPIs as > well, as eSPIs are processed similarly. This improves code readability > and consolidates the register ranges for SPIs and eSPIs in a single > place, simplifying future changes or fixes for SPIs and their > counterparts from the extended range > - moved vgic_ext_rank_offset() from > [08/12] xen/arm: vgic: add resource management for extended SPIs > as the function was unused before this patch > - added stub implementation of vgic_ext_rank_offset() when CONFIG_GICV3_ESPI=n > - removed unnecessary defines for reserved ranges, which were introduced in > V4 to reduce the number of #ifdefs. The issue is now resolved by > allowing the use of SPI-specific offsets and reworking the logic Looks very good now, thanks. Just one NIT and one question below ... > > Changes in V4: > - added missing RAZ and write ignore eSPI-specific registers ranges: > GICD_NSACRnE and GICD_IGRPMODRnE > - changed previously reserved range to cover GICD_NSACRnE and > GICD_IGRPMODRnE > - introduced GICD_RESERVED_RANGE_START/END defines to remove > hardcoded values and reduce the number of ifdefs > - fixed reserved ranges with eSPI option enabled: added missing range > 0x0F30-0x0F7C > - updated the logic for domains that do not support eSPI, but Xen is > compiled with the eSPI option. Now, prior to other MMIO checks, we > verify whether eSPI is available for the domain or not. If not, it > behaves as it does currently - RAZ and WI > - fixed print for GICD_ICACTIVERnE > - fixed new lines formatting for switch-case > > Changes in V3: > - changed vgic_store_irouter parameters - instead of offset virq is > used, to remove the additional bool espi parameter and simplify > checks. Also, adjusted parameters for regular SPI. Since the offset > parameter was used only for calculating virq number and then reused for > finding rank offset, it will not affect functionality. > - fixed formatting for goto lables - added newlines after condition > - fixed logs for GICD_ISACTIVERnE and GICD_ICACTIVERnE handlers > - removed #ifdefs in 2 places where they were adjacent and could be merged > > Changes in V2: > - add missing rank index conversion for pending and inflight irqs > --- > xen/arch/arm/include/asm/vgic.h | 4 + > xen/arch/arm/vgic-v3.c | 198 ++++++++++++++++++++++++++------ > xen/arch/arm/vgic.c | 23 ++++ > 3 files changed, 192 insertions(+), 33 deletions(-) > > diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h > index 3aa22114ba..103bc3c74b 100644 > --- a/xen/arch/arm/include/asm/vgic.h > +++ b/xen/arch/arm/include/asm/vgic.h > @@ -314,6 +314,10 @@ extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, > unsigned int b, > unsigned int n, > unsigned int s); > +extern struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, > + unsigned int b, > + unsigned int n, > + unsigned int s); > extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq); > extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, unsigned int n); > extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsigned int n); > diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c > index 4369c55177..b5d766c98f 100644 > --- a/xen/arch/arm/vgic-v3.c > +++ b/xen/arch/arm/vgic-v3.c > @@ -111,13 +111,10 @@ static uint64_t vgic_fetch_irouter(struct vgic_irq_rank *rank, > * Note the offset will be aligned to the appropriate boundary. > */ > static void vgic_store_irouter(struct domain *d, struct vgic_irq_rank *rank, > - unsigned int offset, uint64_t irouter) > + unsigned int virq, uint64_t irouter) > { > struct vcpu *new_vcpu, *old_vcpu; > - unsigned int virq; > - > - /* There is 1 vIRQ per IROUTER */ > - virq = offset / NR_BYTES_PER_IROUTER; > + unsigned int offset; > > /* > * The IROUTER0-31, used for SGIs/PPIs, are reserved and should > @@ -685,13 +682,20 @@ static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu *v, > { > case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN): > case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN): > + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN): > + case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN): > /* We do not implement security extensions for guests, read zero */ > if ( dabt.size != DABT_WORD ) goto bad_width; > goto read_as_zero; > > case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN): > + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); > + if ( reg >= GICD_ISENABLERnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE, > + DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); > if ( rank == NULL ) goto read_as_zero; > vgic_lock_rank(v, rank, flags); > *r = vreg_reg32_extract(rank->ienable, info); > @@ -699,8 +703,13 @@ static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu *v, > return 1; > > case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN): > + case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD); > + if ( reg >= GICD_ICENABLERnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ICENABLERnE, > + DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD); > if ( rank == NULL ) goto read_as_zero; > vgic_lock_rank(v, rank, flags); > *r = vreg_reg32_extract(rank->ienable, info); > @@ -710,20 +719,29 @@ static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu *v, > /* Read the pending status of an IRQ via GICD/GICR is not supported */ > case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN): > case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN): > + case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN): > + case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN): > goto read_as_zero; > > /* Read the active status of an IRQ via GICD/GICR is not supported */ > case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN): > case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN): > + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN): > + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN): > goto read_as_zero; > > case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN): > + case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN): > { > uint32_t ipriorityr; > uint8_t rank_index; > > if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD); > + if ( reg >= GICD_IPRIORITYRnE ) > + rank = vgic_ext_rank_offset(v, 8, reg - GICD_IPRIORITYRnE, > + DABT_WORD); > + else > + rank = vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD); > if ( rank == NULL ) goto read_as_zero; > rank_index = REG_RANK_INDEX(8, reg - GICD_IPRIORITYR, DABT_WORD); > > @@ -737,11 +755,15 @@ static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu *v, > } > > case VRANGE32(GICD_ICFGR, GICD_ICFGRN): > + case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN): > { > uint32_t icfgr; > > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD); > + if ( reg >= GICD_ICFGRnE ) > + rank = vgic_ext_rank_offset(v, 2, reg - GICD_ICFGRnE, DABT_WORD); > + else > + rank = vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD); > if ( rank == NULL ) goto read_as_zero; > vgic_lock_rank(v, rank, flags); > icfgr = rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR, DABT_WORD)]; > @@ -782,46 +804,81 @@ static int __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v, > { > case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN): > case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN): > + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN): > + case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN): > /* We do not implement security extensions for guests, write ignore */ > goto write_ignore_32; > > case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN): > + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); > + if ( reg >= GICD_ISENABLERnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE, > + DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); > if ( rank == NULL ) goto write_ignore; > vgic_lock_rank(v, rank, flags); > tr = rank->ienable; > vreg_reg32_setbits(&rank->ienable, r, info); > - vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); > + if ( reg >= GICD_ISENABLERnE ) > + vgic_enable_irqs(v, (rank->ienable) & (~tr), > + EXT_RANK_IDX2NUM(rank->index)); > + else > + vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); > vgic_unlock_rank(v, rank, flags); > return 1; > > case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN): > + case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD); > + if ( reg >= GICD_ICENABLERnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ICENABLERnE, > + DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD); > if ( rank == NULL ) goto write_ignore; > vgic_lock_rank(v, rank, flags); > tr = rank->ienable; > vreg_reg32_clearbits(&rank->ienable, r, info); > - vgic_disable_irqs(v, (~rank->ienable) & tr, rank->index); > + if ( reg >= GICD_ICENABLERnE ) > + vgic_disable_irqs(v, (~rank->ienable) & tr, > + EXT_RANK_IDX2NUM(rank->index)); > + else > + vgic_disable_irqs(v, (~rank->ienable) & tr, rank->index); > vgic_unlock_rank(v, rank, flags); > return 1; > > case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN): > + case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ISPENDR, DABT_WORD); > + if ( reg >= GICD_ISPENDRnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISPENDRnE, DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ISPENDR, DABT_WORD); > if ( rank == NULL ) goto write_ignore; > > - vgic_set_irqs_pending(v, r, rank->index); > + if ( reg >= GICD_ISPENDRnE ) > + vgic_set_irqs_pending(v, r, EXT_RANK_IDX2NUM(rank->index)); > + else > + vgic_set_irqs_pending(v, r, rank->index); > > return 1; > > case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN): > + case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ICPENDR, DABT_WORD); > + if ( reg >= GICD_ICPENDRnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ICPENDRnE, DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ICPENDR, DABT_WORD); > if ( rank == NULL ) goto write_ignore; > > - vgic_check_inflight_irqs_pending(v, rank->index, r); > + if ( reg >= GICD_ICPENDRnE ) > + vgic_check_inflight_irqs_pending(v, > + EXT_RANK_IDX2NUM(rank->index), r); > + else > + vgic_check_inflight_irqs_pending(v, rank->index, r); > > goto write_ignore; > > @@ -838,16 +895,38 @@ static int __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v, > v, name, r, reg - GICD_ICACTIVER); > goto write_ignore_32; > > + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN): > + if ( dabt.size != DABT_WORD ) > + goto bad_width; > + printk(XENLOG_G_ERR > + "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER%dE\n", > + v, name, r, reg - GICD_ISACTIVERnE); > + return 0; > + > + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN): > + printk(XENLOG_G_ERR > + "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER%dE\n", > + v, name, r, reg - GICD_ICACTIVERnE); > + goto write_ignore_32; NIT: I would group with regular SPI ranges (taking into account that all other ranges were already grouped including the read accesses), something like that (non tested): case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN): + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN): if ( dabt.size != DABT_WORD ) goto bad_width; - printk(XENLOG_G_ERR - "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER%d\n", - v, name, r, reg - GICD_ISACTIVER); + if ( reg >= GICD_ISACTIVERnE ) + printk(XENLOG_G_ERR + "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER%dE\n", + v, name, r, reg - GICD_ISACTIVERnE); + else + printk(XENLOG_G_ERR + "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER%d\n", + v, name, r, reg - GICD_ISACTIVER); return 0; case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN): - printk(XENLOG_G_ERR - "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER%d\n", - v, name, r, reg - GICD_ICACTIVER); + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN): + if ( reg >= GICD_ICACTIVERnE ) + printk(XENLOG_G_ERR + "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER%dE\n", + v, name, r, reg - GICD_ICACTIVERnE); + else + printk(XENLOG_G_ERR + "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER%d\n", + v, name, r, reg - GICD_ICACTIVER); goto write_ignore_32; > + > case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN): > + case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN): > { > - uint32_t *ipriorityr, priority; > + uint32_t *ipriorityr, priority, offset; > > if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD); > + if ( reg >= GICD_IPRIORITYRnE ) { > + offset = reg - GICD_IPRIORITYRnE; > + rank = vgic_ext_rank_offset(v, 8, offset, DABT_WORD); > + } > + else > + { > + offset = reg - GICD_IPRIORITYR; > + rank = vgic_rank_offset(v, 8, offset, DABT_WORD); > + } > if ( rank == NULL ) goto write_ignore; > vgic_lock_rank(v, rank, flags); > - ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8, reg - GICD_IPRIORITYR, > - DABT_WORD)]; > + ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8, offset, DABT_WORD)]; Here > priority = ACCESS_ONCE(*ipriorityr); > vreg_reg32_update(&priority, r, info); > ACCESS_ONCE(*ipriorityr) = priority; > @@ -859,10 +938,14 @@ static int __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v, > goto write_ignore_32; > > case VRANGE32(GICD_ICFGR + 4, GICD_ICFGRN): /* PPI + SPIs */ > + case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN): > /* ICFGR1 for PPI's, which is implementation defined > if ICFGR1 is programmable or not. We chose to program */ > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD); > + if ( reg >= GICD_ICFGRnE ) > + rank = vgic_ext_rank_offset(v, 2, reg - GICD_ICFGRnE, DABT_WORD); > + else > + rank = vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD); > if ( rank == NULL ) goto write_ignore; > vgic_lock_rank(v, rank, flags); > vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR, > @@ -1129,6 +1212,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info, > typer |= GICD_TYPE_LPIS; > > typer |= (v->domain->arch.vgic.intid_bits - 1) << GICD_TYPE_ID_BITS_SHIFT; > +#ifdef CONFIG_GICV3_ESPI > + if ( v->domain->arch.vgic.nr_espis > 0 ) > + { > + /* Set eSPI support bit for the domain */ > + typer |= GICD_TYPER_ESPI; > + /* Set ESPI range bits */ > + typer |= (DIV_ROUND_UP(v->domain->arch.vgic.nr_espis, 32) - 1) > + << GICD_TYPER_ESPI_RANGE_SHIFT; > + } > +#endif > > *r = vreg_reg32_extract(typer, info); > > @@ -1194,6 +1287,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info, > case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN): > case VRANGE32(GICD_ICFGR, GICD_ICFGRN): > case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN): > + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN): > + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN): > + case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN): > + case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN): > + case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN): > + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN): > + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN): > + case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN): > + case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN): > + case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN): > /* > * Above all register are common with GICR and GICD > * Manage in common > @@ -1201,6 +1304,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info, > return __vgic_v3_distr_common_mmio_read("vGICD", v, info, gicd_reg, r); > > case VRANGE32(GICD_NSACR, GICD_NSACRN): > + case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN): > /* We do not implement security extensions for guests, read zero */ > goto read_as_zero_32; > > @@ -1216,16 +1320,21 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info, > /* Replaced with GICR_ISPENDR0. So ignore write */ > goto read_as_zero_32; > > - case VRANGE32(0x0F30, 0x60FC): > + case VRANGE32(0x0F30, 0x0FFC): > goto read_reserved; > > case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019): > + case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN): > { > uint64_t irouter; > > if ( !vgic_reg64_check_access(dabt) ) goto bad_width; > - rank = vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER, > - DABT_DOUBLE_WORD); > + if ( gicd_reg >= GICD_IROUTERnE ) > + rank = vgic_ext_rank_offset(v, 64, gicd_reg - GICD_IROUTERnE, > + DABT_DOUBLE_WORD); > + else > + rank = vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER, > + DABT_DOUBLE_WORD); > if ( rank == NULL ) goto read_as_zero; > vgic_lock_rank(v, rank, flags); > irouter = vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER); Here you use the same offset for regular and extended SPI ranges (gicd_reg - GICD_IROUTER) ... > @@ -1235,8 +1344,8 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info, > > return 1; > } > - > - case VRANGE32(0x7FE0, 0xBFFC): > + case VRANGE32(0x3700, 0x60FC): > + case VRANGE32(0xA004, 0xBFFC): > goto read_reserved; > > case VRANGE32(0xC000, 0xFFCC): > @@ -1382,12 +1491,23 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v, mmio_info_t *info, > case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN): > case VRANGE32(GICD_ICFGR, GICD_ICFGRN): > case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN): > + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN): > + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN): > + case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN): > + case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN): > + case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN): > + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN): > + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN): > + case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN): > + case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN): > + case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN): > /* Above registers are common with GICR and GICD > * Manage in common */ > return __vgic_v3_distr_common_mmio_write("vGICD", v, info, > gicd_reg, r); > > case VRANGE32(GICD_NSACR, GICD_NSACRN): > + case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN): > /* We do not implement security extensions for guests, write ignore */ > goto write_ignore_32; > > @@ -1405,26 +1525,38 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v, mmio_info_t *info, > if ( dabt.size != DABT_WORD ) goto bad_width; > return 0; > > - case VRANGE32(0x0F30, 0x60FC): > + case VRANGE32(0x0F30, 0x0FFC): > goto write_reserved; > > case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019): > + case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN): > { > uint64_t irouter; > + unsigned int offset, virq; > > if ( !vgic_reg64_check_access(dabt) ) goto bad_width; > - rank = vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER, > - DABT_DOUBLE_WORD); > + if ( gicd_reg >= GICD_IROUTERnE ) { > + offset = gicd_reg - GICD_IROUTERnE; > + rank = vgic_ext_rank_offset(v, 64, offset, DABT_DOUBLE_WORD); > + } else { > + offset = gicd_reg - GICD_IROUTER; > + rank = vgic_rank_offset(v, 64, offset, DABT_DOUBLE_WORD); > + } > if ( rank == NULL ) goto write_ignore; > vgic_lock_rank(v, rank, flags); > - irouter = vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER); > + irouter = vgic_fetch_irouter(rank, offset); ... But here you use different offsets for regular and extended SPI ranges (gicd_reg - GICD_IROUTER vs gicd_reg - GICD_IROUTERnE). Could you please clarify why (what did I miss)? > vreg_reg64_update(&irouter, r, info); > - vgic_store_irouter(v->domain, rank, gicd_reg - GICD_IROUTER, irouter); > + if ( gicd_reg >= GICD_IROUTERnE ) > + virq = ESPI_IDX2INTID(offset / NR_BYTES_PER_IROUTER); > + else > + virq = offset / NR_BYTES_PER_IROUTER; > + vgic_store_irouter(v->domain, rank, virq, irouter); > vgic_unlock_rank(v, rank, flags); > return 1; > } > > - case VRANGE32(0x7FE0, 0xBFFC): > + case VRANGE32(0x3700, 0x60FC): > + case VRANGE32(0xA004, 0xBFFC): > goto write_reserved; > > case VRANGE32(0xC000, 0xFFCC): > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index c9b9528c66..27ffdf316c 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -193,6 +193,18 @@ int domain_vgic_register(struct domain *d, unsigned int *mmio_count) > } > > #ifdef CONFIG_GICV3_ESPI > +/* > + * The function behavior is the same as for regular SPIs (vgic_rank_offset), > + * but it operates with extended SPI ranks. > + */ > +struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b, > + unsigned int n, unsigned int s) > +{ > + unsigned int rank = REG_RANK_NR(b, (n >> s)); > + > + return vgic_get_rank(v, rank + EXT_RANK_MIN); > +} > + > static unsigned int vgic_num_spi_lines(struct domain *d) > { > return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis; > @@ -241,6 +253,17 @@ struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) > { > return NULL; > } > + > +/* > + * It is expected that, in the case of CONFIG_GICV3_ESPI=n, the function will > + * return NULL. In this scenario, mmio_read/mmio_write will be treated as > + * RAZ/WI, as expected. > + */ > +struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b, > + unsigned int n, unsigned int s) > +{ > + return NULL; > +} > #endif > > static unsigned int vgic_num_alloc_irqs(struct domain *d) From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:58:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:58:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104696.1455718 (Exim 4.92) (envelope-from ) id 1ut46g-00028U-JI; Mon, 01 Sep 2025 12:57:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104696.1455718; Mon, 01 Sep 2025 12:57: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 1ut46g-00028N-GY; Mon, 01 Sep 2025 12:57:58 +0000 Received: by outflank-mailman (input) for mailman id 1104696; Mon, 01 Sep 2025 12:57: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 1ut46f-00028H-GW for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:57:57 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 46e355e5-8733-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 14:57:55 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-61cc281171cso7356766a12.0 for ; Mon, 01 Sep 2025 05:57: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 4fb4d7f45d1cf-61cfc4bbbd1sm7182251a12.34.2025.09.01.05.57.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 05:57: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: 46e355e5-8733-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756731475; x=1757336275; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=pm3N569WsBs5aGMe2i6gJDw1Vplh6X00fnZ76aUICsg=; b=O264KnusR4JLKheBexgsGGC6BeFW+mPKMTQf7Q9PFFzCWgC2HPcGXMkcHtrgAvJBku AIazVs41UKmGQuHg6eE2d01oDrcdHgQhB8ZaSlXEBld6bApF3WHxh0w/+INXWxrGcGe5 oodQCQ98/uAxADofB1k5MtterYcn3sKShdAqUbnf/8MB6HhHus11KNr4Ac2tV7+CPWMX 4BGnORad+dj/5dioo0O5Lvq1D8vgoQnOdLWPWtG6z2rvpKysOd+wmeaToh8Q+TLkWPCf cFg87mUgzo6O7NeMhPbdFaP7HllDv8+3/UgWqoxMhqlUg1KgD4n7lo2aRN8gkckYDn97 MSpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756731475; x=1757336275; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pm3N569WsBs5aGMe2i6gJDw1Vplh6X00fnZ76aUICsg=; b=ZFT7nvEBnehvo87grogscjqxq0XhiLxYPgT/ljdkqYHBLyCks0OjQXJ13xHptCcRCv hVFOOarBP5SH0SRAYEBk3iv5JR+HGj6QTpje1dLVRYc+Wdf3Ud4QZ6v9BAuHaog62JB9 KsKf8wruUtzDKdJoCxyKhpeHKnSMytNDXgGz1zE4ybQkwK8GJpb1WXPe+Rjmz/k4WJQz AtaPPQAhaMMub2Atf9RlkyR6xTyqhhvXvQpSeYDql/JFJylGvMsFip1+5GCgiXJZfTZq enuRl/yoRuYDM69xdEqhLsH4LHR8SL67EBlRDYsVlFUY1VmFMmLZtV4GL2ewVRGaJpOd jDog== X-Forwarded-Encrypted: i=1; AJvYcCW5msg7HRpalSbApGnDS+ZnMoUNnuYQCAshwsCEONkNE5iPxb7GVIH/FsTL8wf5V4737o9ATlhbTO4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxoSkqR2gNf00Xe8ZkVSw/l/NDnukPeGx7kyxDgkkh3uJXuTRfq MSp9lFgh4FubLsiDKqOpIjr4mhn3SLMf/evCo5MgTAWgpUue2wJX5hhXNeptdJ75tQ== X-Gm-Gg: ASbGncvBH4f1ZzSJVNhmrQ+utOVvWQMFfRfFAp+zeniiv9Kbe7ZxNC0vMCCH4vZTKIz CVq4FNfxX2hCprlZm0aX5ewIrd3N0IxgkopN0XR+6p//kcPFyEJRDErlxu0RfOe5TsiaEEpYz21 WK+/pMm3crrzKdFq2UWZ/y/4kOdf2In+uRK6ItFKUD1h/eWxIJhprM2vaG3U7QCc2VrKesgjAhT uIznapzOBCiZcgNnfd+WFr3AYgTSb6y/+2sZHl+vo/nSCD5rL2Aohel9QtI7lQhwL9ebBYqiRhn DNuENIt9pN1GXOS5aFWv+Qt9u5iEuKCLrRo01Xj3LVGswAxDBbCQIqHhxfRSx5D1zDzGNn9krsV MhLSuprJCx14kz5KcgQ9rYyjuUQYMuP0YyIZVelM6OWPJBas7rSxEanAW68OC5iIXuy91q7WTPo 3Mr3k6myOd9JmVG+W3Kw== X-Google-Smtp-Source: AGHT+IEgmXFcicdsXwnsS7WShACTSHNXO33DMXdHeh2zCuw8+AvhSf1su6vGhe1cm/J6G3QDtEIQsA== X-Received: by 2002:a05:6402:505c:b0:61c:e1d6:6bf6 with SMTP id 4fb4d7f45d1cf-61d26998f14mr7159411a12.7.1756731474598; Mon, 01 Sep 2025 05:57:54 -0700 (PDT) Message-ID: <1800ea68-eee1-4433-aa22-954dcd226fe5@suse.com> Date: Mon, 1 Sep 2025 14:57:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 20/23] x86/pv: Exception handling in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-21-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: <20250828150409.901315-21-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct cpu_user_regs *regs, bool ist_exit) > > void asmlinkage entry_from_pv(struct cpu_user_regs *regs) > { > + struct fred_info *fi = cpu_regs_fred_info(regs); > + uint8_t type = regs->fred_ss.type; > + uint8_t vec = regs->fred_ss.vector; > + > /* Copy fred_ss.vector into entry_vector as IDT delivery would have done. */ > - regs->entry_vector = regs->fred_ss.vector; > + regs->entry_vector = vec; > + > + if ( !IS_ENABLED(CONFIG_PV) ) > + goto fatal; > + > + /* > + * First, handle the asynchronous or fatal events. These are either > + * unrelated to the interrupted context, or may not have valid context > + * recorded, and all have special rules on how/whether to re-enable IRQs. > + */ > + switch ( type ) > + { > + case X86_ET_EXT_INTR: > + return do_IRQ(regs); > > + case X86_ET_NMI: > + return do_nmi(regs); > + > + case X86_ET_HW_EXC: > + switch ( vec ) > + { > + case X86_EXC_DF: return do_double_fault(regs); > + case X86_EXC_MC: return do_machine_check(regs); Looking at patch 21, I came to wonder where it is that we're moving back to SL0 in the #MC case (which may not be fatal), for ERETU to not fault. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 12:58:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 12:58:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104706.1455729 (Exim 4.92) (envelope-from ) id 1ut47Q-0002bb-RV; Mon, 01 Sep 2025 12:58:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104706.1455729; Mon, 01 Sep 2025 12: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 1ut47Q-0002bU-Ol; Mon, 01 Sep 2025 12:58:44 +0000 Received: by outflank-mailman (input) for mailman id 1104706; Mon, 01 Sep 2025 12:58: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 1ut47P-0002az-9C for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 12:58:43 +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 627d5949-8733-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 14:58:41 +0200 (CEST) Received: from PA4PR03MB7038.eurprd03.prod.outlook.com (2603:10a6:102:e1::6) by PA4PR03MB8223.eurprd03.prod.outlook.com (2603:10a6:102:26d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.15; Mon, 1 Sep 2025 12:58:38 +0000 Received: from PA4PR03MB7038.eurprd03.prod.outlook.com ([fe80::62a8:3ed7:1b8e:677b]) by PA4PR03MB7038.eurprd03.prod.outlook.com ([fe80::62a8:3ed7:1b8e:677b%4]) with mapi id 15.20.9073.026; Mon, 1 Sep 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: 627d5949-8733-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OJ9jq0lTFevuC2sr5Fve4nLEtQU/phmAJs7Gvic2J2BIvT+uMx8yDcLEnc4LfFnUOgTx+Re8blcp3e9cfz0Fh1gNwulUF2mVPknTd3qTYjFwytC2WFfJQ+YnxK56bptzhfx2kjDPA07V9TmZn4PFRNGP1HPOlCYJ7KbH6Yt73JMMFftIHjaUy2tqt4MKZwlvr59CG/Q3m74xJkFHY7/E7KGnOAI5r/L+li7JgNLu5ij8pvQPiCfMJemVLh8htHKSp+1OD2s8S41Hs28ctD1M0H1zMZuuGr7lRF3lIUASxcXs/bBWSwFpZYAbmXGTNvdA2ueMo16nHDZmnQwfuFWTxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2o3P77ttyvIZEdJdklFoIAX7E+qAs5JkosERNNnEuiw=; b=ykvSSJF6QSBOloH3iwKHX2ZbEdjsd7ANlTRC2MOqi58x0NITVKhntkdCISpGqZWbG804mf1bq5QWkVWAWmm2t1Owi7sJlM32GN+Zku3GSpy7fEFBlWwQpgiIfHezTWAuh5UwSaeAOluLNYksmN0CE3CbvQu/ATi5xQ1kBW5T5R3M2xETRi2fAuNXnIYG2liyeaKp+nPl4S3IXxKGbYh2+IyWG56TVmC2SlqXETidG7CDNEFk3W7EZX33MWm18ADedh9XaWAnr8UfWgQ90eQ/dfPZvu4AlHTUCpF78hfP5o/fyHQYAP799Cp2+yeWzy/VbLi1HDJSGupsZNqfCtV5aA== 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=2o3P77ttyvIZEdJdklFoIAX7E+qAs5JkosERNNnEuiw=; b=oYV4v/AsrqX9a8/redwRRPulEiv+JVvSH8ckKTcWENlLYLYlZtoe12eQjpIe3tle1wwXehLFDaB3Y2LlOzXHpmugFGzmJMKIQbAI7hviqAUOd1un2nmC4qtgCKhAZzW0K+RLtlqY3lFMslWQk/T+JJDpeNGzm9SjEUUgYHgBs7M1MsnbyZsWjrhzruMflVZoLkoDZvhCoC0yxakMuYqeJktrGACtMAI0DbdsIHb47wpa1UaiGPq9wZoycLOMe67lWI60AMAa8d4r0UUqHDWFToT+aVCNjncl8FmvBMNzNd7ZABwFMc//EFDBQq19Ll/LGSz7Y/OYhyKOCKngQrbOCg== From: Oleksandr Tyshchenko To: "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH] xen/public: arch-arm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Topic: [PATCH] xen/public: arch-arm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Index: AQHcG0Ai/cd/D2azrkCw2pxNjrn41Q== Date: Mon, 1 Sep 2025 12:58:38 +0000 Message-ID: <20250901125837.1271101-1-oleksandr_tyshchenko@epam.com> Accept-Language: en-US, 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: PA4PR03MB7038:EE_|PA4PR03MB8223:EE_ x-ms-office365-filtering-correlation-id: 291420a3-475a-4d06-e12b-08dde95744db x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|42112799006|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?/kwponZ8ODe5zSC2am+xP+seMvncKtTfdx/PjqwlpvYIYPDnWabVQfoPCC?= =?iso-8859-1?Q?WoDbh/Ff95UkxRIBf8OfANbSYhO1zmpTyQ0vhXiaFd3Yw2hFoZyuzE0rPV?= =?iso-8859-1?Q?bTWCyvkVeiDz1oAuRvoLxbeyZ4nzWX4h71v2L67UXlxUz3c/7S7myosKkl?= =?iso-8859-1?Q?O2IrqlPHFv793bg/zkYxtg6nvts6RXiGuqo2f4v25AfLvi/deDswm9KYxb?= =?iso-8859-1?Q?YG06g6mvg6MkQp76jtW2PAc3Rp2gIW9R2l+3PV/qY2K6kWeOuroxcA763i?= =?iso-8859-1?Q?Vw9BfNJ/wx+7VWmibUy9QSt9z4+Q+9Ua4JhH2vmD8aTrWXxGIA9o1pLSHV?= =?iso-8859-1?Q?3lQ6JIevRC7/3JqiQcxCABZVc1bkBVvaaDhWJrdctMLrOVhoJn3KAFy/Xf?= =?iso-8859-1?Q?23rZRgm7o54fJK6GlsX0vPaqhBZteErU1BFh5bktgNZ/2aGBb6NIz52kDB?= =?iso-8859-1?Q?lScX1D9H6pM1Nmc7Ztw+Q6o1MhBl2pYDLfGk0vn9eC6PnVTzNd5uTANYnS?= =?iso-8859-1?Q?Is0HPFWlnpmmQgNcvP5kC8sEQt22mn/TAqVIIqNXqEz4YPQGvfiWoUDz1d?= =?iso-8859-1?Q?2obLD34m9Y6mZjbO9sYa/zRsocP5RrZKy/vsttzCjv6xh3yQLrX5qpLqCI?= =?iso-8859-1?Q?Bphaew5mhiQIOugEEBJRHF5xlctNPDDKaxu0QHStqv9e01bVevoHoqJAtc?= =?iso-8859-1?Q?AYK13LWGOaLoM9bblOTUpUXLTn20t6F6qzoM+NudpWZUw2GxnJr5kzfpH8?= =?iso-8859-1?Q?PyaT3gLa6gJPm5DOXIVb1Qp+bNZD69oJ77nB1ArUWRCS4Di6zolKWAGFnA?= =?iso-8859-1?Q?0viIWR8vvMJ3n0DdVsMsKvKfA73cFXBCcmqhaYlMu18o8s5V5a90mUiuzy?= =?iso-8859-1?Q?A9wtbRUXCwpw3VXbYR8LDZlf82/XJbhdPZxCkWxAy32voWQNIgSXVyb0j+?= =?iso-8859-1?Q?yszloa6nIqZ9hW5vA+nfvnxBlXjHzhB4nHr1A6MoPnl01YX0lqqKamD+P/?= =?iso-8859-1?Q?2V5jmcTl20zdQdOr1dCDuMOAwyIszGLVczoLcjfQjXOAQFLU1G+LT4oJti?= =?iso-8859-1?Q?KDgv+8B6Aj9jcLKFekt7jl/p9l9W72XBqaTSPOJ2crh1sSG754tJVjA+w4?= =?iso-8859-1?Q?3qHmyvF4kQFnIoz0/4RjryZYWV/SKnC3QkTUWdeNZX1Ie9jGVJk9z8o7oH?= =?iso-8859-1?Q?Q8LwzmDi4dpsouAnILXrYQ8vfWQsa8TJPmBiHp3bneAsMhAMnpDk+vNs7p?= =?iso-8859-1?Q?A8aO1EBrG4bebN3bWKWFo2bGz72IViBqvb41fUWb2b+/bXj0D4/hJw+BeI?= =?iso-8859-1?Q?R5658Tlxezaswt+v0F+M3ihtUWLqEIAAQg94yZm20exR5WimoqAeGdO7FW?= =?iso-8859-1?Q?U/9G5gko6RTfezMDScyBmn4YOqx7y19nyLc0gh4D81NivDir6XugQo7NMD?= =?iso-8859-1?Q?bQtO6Eq86P6o0Ygc+Cs4N9/sSvRW9f9yKG1BIuPgoR5Vsho7v2gSBuEud3?= =?iso-8859-1?Q?wHbzUgHa6hRIT6WPcyPl3wuVfdulPKffnCXnm7NpBiTw=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR03MB7038.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(42112799006)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?JXWbxKvzOPfNVGooOhlwFSi/w1W/jiFaNgEyn+jAfqcgg4cK4PaLrWK8I6?= =?iso-8859-1?Q?Am9jU9R47DU7HDzPBx/+EdR/sc++A5YIThzxUCF9m/g2lZmYbHtUEpPUg9?= =?iso-8859-1?Q?cd4TBpQ9N3r2QHPC1GZi912+OeGXyJbVPB2KZlZXBO75ytf+6+lz4jScED?= =?iso-8859-1?Q?IRHa2hLy5iX1z+1CH7IokXIvVr5Exc8UNauAKR/hO4m2iYdYcEuwnwRkdV?= =?iso-8859-1?Q?oZ9bHfJpvsJTF7+n2X7ZgXQC3e+KE+TCJ/WSPEX5uMZXu8LcIZoBS9aQ72?= =?iso-8859-1?Q?TNgpsl47bHX2dNi70mPFVE3BBqTlEPE9aof2hbaeABIEQNOyJYbJJgp8oA?= =?iso-8859-1?Q?c41iu7mZIjK7RfM/PVOsnL/UcvjgF4ujz0QzznL+5XyJe9zAZKsk+EqiWy?= =?iso-8859-1?Q?pdVU70Y5Kux06i4X/XNWlKcP6kqQhqfoYxMopAtxARTt2IEEMdCwgsu3Z6?= =?iso-8859-1?Q?a85c279DpfTDV/ohqeVPHwc9bL14xiK1XDZWEEl5ER6y+/Ht3VRhLK4iOG?= =?iso-8859-1?Q?w+r1g7x3tbtPsyUHw/a6L0M25NQzZtDZEp6Btu36OZHO4lP4emtnvT+Grl?= =?iso-8859-1?Q?nnhKvEucYGcSwPwDe7/LeGWIV56pxraPzxL/vZHWlp8HhhImljAbFFcQ+W?= =?iso-8859-1?Q?ohEokl1h39/SK5acTMlbnoENPi0F0ziTbc7cH1rGo3l5sXsBrHGLYKXhae?= =?iso-8859-1?Q?lWuviznw8vzlDVARZmoCzkqZdJ4JVdzUKCZlYd9/7wm1xAw+jtp9uC3St8?= =?iso-8859-1?Q?oZEGRjhzQjLtGwZWobBzgLz0FjaQVH7h2TPO7+ek+GjojhN2RZAWyDluBJ?= =?iso-8859-1?Q?2vAdL3nUSUJS01ogvxC4rySt0gzjzHVTAp0MlwCS4YoWnogUsl4mw5+exG?= =?iso-8859-1?Q?sTsQd6OBUdSuihHe5SpdzyF0hOIyHVAWluSbd7cgouq2NPjgne1agauhjJ?= =?iso-8859-1?Q?1TNXbjWh3gcBB93MWijTQZu9zVHZ8xWAbBsEbYytfvbGf4HwDbouCD9N95?= =?iso-8859-1?Q?plxFSG49eQlMMHo5gXS8kvsemLvX1kldvbbXD42QOGFHdSxEPaiY2wq2o2?= =?iso-8859-1?Q?rh5Yk1GY4ZUSUje2bOdMowzZDWBtR36jALcZ+QraWv3vxRV039LClWvvVT?= =?iso-8859-1?Q?rI6sNPKO0I82h/UuebkfyuRxLlEb3eHF+lEkVdi9ztIbS2ClA+7uwBEhJV?= =?iso-8859-1?Q?Htw2ZfqCLNlH10xfeMOJQ8qaCSnL3+QAUc/dQOO+0t2otHCkFFaVmuDDra?= =?iso-8859-1?Q?OxUcHSXc4ktSmDWdDhHHbCSojNYlGgIS8pm2Eg2ZPBjYIPN98hDNR+SmaW?= =?iso-8859-1?Q?rY4Sh9TCN3/nlvhsZUC62WXPEHJN7BWA6eIcMO7luDFeaDexNFXoddtE0o?= =?iso-8859-1?Q?P50TyoIdN9aJQXwPs//6VY18dWhGB4c4LVAEM2iqZ5EBmpadjE779rtLk2?= =?iso-8859-1?Q?Ec8YuBB+s5axQn3NZUAwjzrf80HCOWTfCsDB93epI0bQKsHzQCLDfYNqkm?= =?iso-8859-1?Q?JyBIIQVdpRQYtxMgB0oxPf0o02TTzuFRxUJDPPELFdNWGqE0nIRR0ErpwU?= =?iso-8859-1?Q?c3sVKe9k2h6fFlx3DocDHjginzZEd1IBPb9hd3gHWuCs3ExbtXs/blgrdS?= =?iso-8859-1?Q?M9HLbw9z2ToDsXGUX9azKjtBrBl5wxaFpsJPX23IsgmmQRVwEIpQwHbzRw?= =?iso-8859-1?Q?ThsIFzES95CPcu9hN6Q=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: PA4PR03MB7038.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 291420a3-475a-4d06-e12b-08dde95744db X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 12:58:38.2855 (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: WEqm1pbQo8bId71Bgu1Sa25g6EwIuAOELqt4ZzV+sEEINmYMA2y/ydRX1pY4o18WFrnZhD3qy7sEo8FgWSn5LnJb2Jo43LwoRxCc3M9mB3A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB8223 The said sub-op is not supported on Arm64, since it: - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn cannot be returned), please refer to ioreq_server_create() - does not support "legacy" mechanism of mapping IOREQ Server magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please refer to arch_ioreq_server_map_pages(). On Arm64, only the Acquire Resource infrastructure is used to query and map the IOREQ Server pages. Signed-off-by: Oleksandr Tyshchenko --- xen/include/public/arch-arm.h | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index e2412a1747..023cc2f468 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -130,7 +130,6 @@ * HYPERVISOR_dm_op * Exactly these sub-operations are supported: * * XEN_DMOP_create_ioreq_server - * * XEN_DMOP_get_ioreq_server_info * * XEN_DMOP_map_io_range_to_ioreq_server * * XEN_DMOP_unmap_io_range_from_ioreq_server * * XEN_DMOP_set_ioreq_server_state --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:03:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:03:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104718.1455739 (Exim 4.92) (envelope-from ) id 1ut4C4-0004Ki-Au; Mon, 01 Sep 2025 13:03:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104718.1455739; Mon, 01 Sep 2025 13: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 1ut4C4-0004Kb-82; Mon, 01 Sep 2025 13:03:32 +0000 Received: by outflank-mailman (input) for mailman id 1104718; Mon, 01 Sep 2025 13:03: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 1ut4C2-0004KV-Rs for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:03:30 +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 0e31af17-8734-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:03:29 +0200 (CEST) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-45b804ed966so11777305e9.2 for ; Mon, 01 Sep 2025 06:03:29 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d64ba4ff83sm4876871f8f.4.2025.09.01.06.03.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:03: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: 0e31af17-8734-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756731809; x=1757336609; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=QE3Qc9cg8PEzoK8zgrJVZfJw67jf3EWpZOGJxKNeCSE=; b=u26dZ+Q/PCwwKRCTBpp6Mrz46xQ5ZPzWUduKG33/gZWgyCl6DY+W/6sMZ/fx3BD6e9 fLc+LSU0tfeH5KgLqmb/YWPQ/Mi+/plAgj5+oYNsxooq50YtoMVa2l6IUfdE8qKZif8m TFxvukxgsNxCK1SMgC3arV2MJEr23mZnX2eys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756731809; x=1757336609; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QE3Qc9cg8PEzoK8zgrJVZfJw67jf3EWpZOGJxKNeCSE=; b=lxpJpd/Wkwp+VibJlFbNDkdiLvKMlan5c/wnBi+g8PXBkLzDKsoqSEDijUF6/zqhAz cjv5GHczPDtFzJKds7y+QiRMUcGB4IN3vIm3Dj8HGglt9208FvIF6vYUejRGUrsQVLcq k6wZ0D7JakUVF/YFzxUrTOgmEuE79EPakl1d79ByZkILBAdTy5bQJVIc6TuF7mkd09sz jHT2ynfYLcv2YY5rslVuCwpoRiMrwpfKAx41MK/yC8qGo4WeQcx0ScRkC9OhtcsX9hwS 2+PAUY0OQwzLYlq0ZKi2MQbCMCwfQZ9EWmE0RDCQK56BbMcKgaTMhTqXBHKdhDcLovqp 1UUQ== X-Forwarded-Encrypted: i=1; AJvYcCXcQCnGGVf5CPrrLvI9qA3l5fdc4ekMcQS/RXUg0e6Ii4miJ9VvHZx3XG4BJuHB69epaAz76BYru6w=@lists.xenproject.org X-Gm-Message-State: AOJu0YyVWWiSsVnobHmATPYWPL8/4Md2fuQK0wWdC0dN1pg8DJoVcjsG myUDH/4ZriFQHJCWwb4EwUMjN4aRtALoxlHEiK63tBiyy3GrHLeiTwsVMlpW28TEARo= X-Gm-Gg: ASbGncu4fm9gWbGiA/P1X3ybHyBsgY5fRZ0y6/Aja0qH23N7qBYRaf5pwBOOvAmEyK2 Xcr0BIMHz9ZlPZ40Ga0LgnU+bDRd5LqzGVy8PqoWMDrSzx+K2DRIBOiiQm3bLaEz+8WdQGQ+1N3 O3faxqHtT69IiDaxSRlGoCklaILsTlHdcCxh1BWwLQqhdcsAzE5CYZDfah2CUqlAGSIhvWyzWwb wyEnktCoYgvhyWKXgoTolU6AJp5ZRI8quMxNqRwyJ0gA5ejyd3Ch/BV3NYNkseeMsujNDttFFlk SEN8t92BKEn6uGDTNKbA7xvhUEH/KcmnnRAERCiJvEULfy0yWq2v37qqLrQUF69FXW4Imjrku5a BkGRlYFgd/C685/lNk2V22pOfuAhRtQYDobXRHpM7ZwcTUkqleHMeuaAadkzVLYJGB9IO X-Google-Smtp-Source: AGHT+IFBbLI8EKBAuFCpAu3TabfhlRlfwfA332aoovLqJNHIQ6B8KpvtdCS4v598kffBy8im/PEoKQ== X-Received: by 2002:a05:600c:458b:b0:45b:88a2:d01f with SMTP id 5b1f17b1804b1-45b88a2d12cmr53876655e9.3.1756731808805; Mon, 01 Sep 2025 06:03:28 -0700 (PDT) Message-ID: <10436acb-bf5c-4fde-950b-62cf54f07025@citrix.com> Date: Mon, 1 Sep 2025 14:03:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of device tree To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com, volodymyr_babchuk@epam.com, mark.brown@parrylabs.com, matthew.l.weber3@boeing.com, sookyung.ahn@boeing.com References: <20250901123103.11418-1-ayan.kumar.halder@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: <20250901123103.11418-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/09/2025 1:31 pm, Ayan Kumar Halder wrote: > diff --git a/scripts/dt_sanity.py b/scripts/dt_sanity.py > new file mode 100644 > index 0000000..171947f > --- /dev/null > +++ b/scripts/dt_sanity.py > @@ -0,0 +1,33 @@ Shebang > +import argparse > +from pydevicetree import Devicetree pydevicetree isn't part of the standard library.  Readme should note the external dependency.  Also it should be separate from stdlib imports. > sys > + > +def load_compatible_strings(config_path): > + with open(config_path, 'r') as file: > + return [line.strip() for line in file if line.strip()] You should choose a different name from file as it shadows a keyword. Also, you want something more like this with open() as f:     for l in f.readlines():         l.strip()         if l:             yield l but you really ought to also consider supporting comments in this config file. > + > +def check_compatible_nodes(dts_path): > + # Parse the DTS file > + tree = Devicetree.parseFile(dts_path) > + > + # Search nodes for compatible properties in the global array > + for compatible in compatible_strings: > + nodes = tree.match(compatible) > + if len(nodes) == 0: if not nodes: > + print(f"Error: Node with compatible '{compatible}' not found.") f-strings are not supported in our minimum version of python.  Use % or .format(). ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:13:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:13:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104742.1455789 (Exim 4.92) (envelope-from ) id 1ut4LS-0006PM-Ks; Mon, 01 Sep 2025 13:13:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104742.1455789; Mon, 01 Sep 2025 13:13:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4LS-0006PF-Hb; Mon, 01 Sep 2025 13:13:14 +0000 Received: by outflank-mailman (input) for mailman id 1104742; Mon, 01 Sep 2025 13:13:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4LR-0006P9-EL for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:13:13 +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 69850299-8735-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:13:12 +0200 (CEST) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-afcb78ead12so703331466b.1 for ; Mon, 01 Sep 2025 06:13:12 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0421939da1sm321263766b.27.2025.09.01.06.13.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:13:11 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 69850299-8735-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756732392; x=1757337192; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zmP/0ptYzR7dKdtH5ZrLLoZGHqV9Yo6We6i71YTkul4=; b=Jf7uq2YFV2PYNdQkK8a4KiZzxDPGPc4aYhIc1kCxhuQzUPIgnd7NqG8J2CJ0JrDB96 mctnDLbMD4YpBwP3eXdt8d+OW76lLSTOyKFDbvZptrLmqX6G4HGBBEFPoVsRIpKREhy9 qTiqFosOVo5b9Nx5acGoqcnvpLihDJPc1cjbgQsTVAqMy3rBoKiHUmhvu0T8R6iBHPmz Qi5TZlzQjB4H+ApXg8W5Zxauqv2oSDz4JprWFE6kU8N188aEdluGDUHM81xbFFB/hQSX bD9EiMDLZYLOekYkPqblpD+G8JtS/cu6oJW2K8FzZ40sDCzYUk3jXgjo5d0hp8PsjsKx UwaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756732392; x=1757337192; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zmP/0ptYzR7dKdtH5ZrLLoZGHqV9Yo6We6i71YTkul4=; b=R9Culi3JZkPksn2vfD9gPHUiz2eV7SykyNP5mkxCcq9TV/FjxvAbczQLwpVgy0czL5 umhMzD32KM8pmrOZf6SRUH3romxJuQdMgVbrmOCTbk+9wg+n3JvayEEGT2Um7BPTlmzL AXKGz9LIVlBU0c3nX2BbA4TZ9vLFIQ5aa8SO1tVwfXkfdPdY9TKq8kATZLoLjtd+TB+k 5Kzi3PvFIKemsE7KRhyGH2pK0Sd7GqebkWILugdb+01thxA2ZSew7rz7y3vw/sYBgYWt b9ygGQfn026ivEK1cm73DRnbwk1+83K4k7O8uM580Cfc+KajlHtDwWY8+ytLyS+lZ3WK gIsQ== X-Forwarded-Encrypted: i=1; AJvYcCWGX12DUmiTEY6PJuDGltMyg4WvAAv4Vk9RpeL0HRH94tp+8kasQjdxE6k0HnqVzW3sdkKabURhets=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy625mF54tBiKlaUvSyF3jnlnjFBogJxbGwBs94DyQsVTdTP3nE qqUSwidVx2CX2UfcsVSxiPD+ubQps5Bws0g3YgtT6upsOazKwcAFqmWCUNv8XQvhKA== X-Gm-Gg: ASbGnctoDu2n+9/R842J6UDsMjVCc8Pf6KRgB/bs/3YD8s7hkW6A24o3RsHShNBKcFK olCHjfZRQpMqkkhP8kj56Bf8PJ/qA3OE4Nw0/PtS705MN8fF/lNsLZojXBfE2lNk3Z7BEb9HXG2 rEHOnlwZ6j5din7F0Sa+Tx8UiM0bWqeTqauaQyYT13NLTrcq+1gtZmqn7ZYb25bwRlNI8fCSHCO uqJPAqzEEC0n3Tsn3zimKcoU1YRBgBruUi6BSZNtmHlYOvHNiwA5wWfaEC2OBoFe88bdI7bYkYy yldE2wdToK4cv3S501RB6T5vlkq1aji2YeyXetOY9OBwnm+LhnFc5k40jMKCtqjzqqCfvAMlF38 sLbFNVpjGINF7Py6tn5XZhTMUV4EcRTMcRXs9eL+GxXrG3k2OgeGfDC1dNUX075GHmzxWzYSfaA 5771sHSN08BFafCMp+OExgq7QgV2hN X-Google-Smtp-Source: AGHT+IE0979SlahFyoIQx28WEhEhaRVmqgi0822/kIuqmYC9rzNX0SWX6aho9TF9qwxdvGKJbrGAyQ== X-Received: by 2002:a17:907:170c:b0:b04:1f42:5de1 with SMTP id a640c23a62f3a-b041f42615emr388275666b.42.1756732391644; Mon, 01 Sep 2025 06:13:11 -0700 (PDT) Message-ID: <6dcd709e-088b-4c8a-bca8-1794639d5427@suse.com> Date: Mon, 1 Sep 2025 15:13:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 21/23] x86/pv: ERETU error handling To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-22-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: <20250828150409.901315-22-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -2345,6 +2345,113 @@ void asmlinkage entry_from_pv(struct cpu_user_regs *regs) > fatal_trap(regs, false); > } > > +void nocall eretu_error_dom_crash(void); > + > +/* > + * Classify an event at the ERETU instruction, and handle if possible. > + * Returns @true if handled, @false if the event should continue down the > + * normal handlers. > + */ > +static bool handle_eretu_event(struct cpu_user_regs *regs) > +{ > + unsigned long recover; > + > + /* > + * WARNING: The GPRs in gregs overlaps with regs. Only gregs->error_code > + * and later are legitimate to access. > + */ > + struct cpu_user_regs *gregs = > + _p(regs->rsp - offsetof(struct cpu_user_regs, error_code)); > + > + /* > + * The asynchronous or fatal events (INTR, NMI, #MC, #DF) have been dealt > + * with, meaning we only have syncrhonous ones to consider. Anything > + * which isn't a hardware exception wants handling normally. > + */ > + if ( regs->fred_ss.type != X86_ET_HW_EXC ) > + return false; > + > + /* > + * Guests are permitted to write non-present GDT/LDT entries. Therefore > + * #NP[sel] (%cs) and #SS[sel] (%ss) must be handled as guest errors. The > + * only other source of #SS is for a bad %ss-relative memory access in > + * Xen, and if the stack is that bad, we'll have escalated to #DF. > + * > + * #PF can happen from ERETU accessing the GDT/LDT. Xen may translate > + * these into #GP for the guest, so must be handled as guest errors. In > + * theory we can get #PF for a bad instruction fetch or bad stack access, > + * but either of these will be fatal and not end up here. > + */ > + switch ( regs->fred_ss.vector ) > + { > + case X86_EXC_GP: > + /* > + * #GP[0] can occur because of a NULL %cs or %ss (which are a guest > + * error), but some #GP[0]'s are errors in Xen (ERETU at SL != 0), or > + * errors of Xen handling guest state (bad metadata). These magic > + * numbers came from the FRED Spec; they check that ERETU is trying to > + * return to Ring 3, and that reserved or inapplicable bits are 0. > + */ > + if ( regs->error_code == 0 && (gregs->cs & ~3) && (gregs->ss & ~3) && > + (regs->fred_cs.sl != 0 || > + (gregs->csx & 0xffffffffffff0003UL) != 3 || > + (gregs->rflags & 0xffffffffffc2b02aUL) != 2 || > + (gregs->ssx & 0xfff80003UL) != 3) ) I understand that for ->csx and ->ssx sensible alternatives to using such magic constants don't really exist. For ->rflags, though, I think it would be nice if we could use constants we have. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:15:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:15:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104757.1455799 (Exim 4.92) (envelope-from ) id 1ut4NV-000703-4k; Mon, 01 Sep 2025 13:15:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104757.1455799; Mon, 01 Sep 2025 13:15: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 1ut4NV-0006zw-1o; Mon, 01 Sep 2025 13:15:21 +0000 Received: by outflank-mailman (input) for mailman id 1104757; Mon, 01 Sep 2025 13: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 1ut4NT-0006zn-FG for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:15:19 +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 b4b26432-8735-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:15:18 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b0411b83aafso246964066b.1 for ; Mon, 01 Sep 2025 06:15: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-aff0d9b1b53sm741761866b.96.2025.09.01.06.15.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:15: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: b4b26432-8735-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756732518; x=1757337318; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=eV3UJ52v/5RTKbIh6wnLIN6iSdIYD4/QpbMRN6+8CPU=; b=Gno6iDLsQh8oD3s/y1zdKUiCghrDNVydCRH+ZrO4N1lwBsTqJ2MCNNWMq8gV4nEY/d TjTJGP77OF+sikcUvD1YpMRaoB/MvWJyLjmZuIryAB+wXYsxcAvEzMSU/tL8xPlqmd7K xlw+FYUH/TaamNu9wNLKOVDC4cjMwDLjWPKPtU4AtY8jyAe1cxuf4soWyMqewaJxyGzf wkYvuTR4vXqaSWhcL/yzGYX6zzwoBSG+bGkNCNJ+opzNDMfF9OjEDUhhwG8tvfqdrPrO L0IHM1QCVdw6KqqlO6B/Yjcxw7XiJyDGdeeURaKv6v9UrQe/BMBIPpsECVIhSOlWGvPI MGbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756732518; x=1757337318; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eV3UJ52v/5RTKbIh6wnLIN6iSdIYD4/QpbMRN6+8CPU=; b=wD6K8hiPHs2bxO6+FjAJEq8pjOlBeIq40+Gue1CYFYtGLYRHBXmGkpWXcuOEisUddH jE781/5qSoiIjEm9BgSIzuJFW3GTdE9lk0TrP4feqVewAmL+tiXs265WcFxsPnFDY8zJ nNlZx9DgjQ3bQ7cvlhHbz4sCW2MWaWcNq47pX7gLOn3BStIW9YIq6AWXg7+W+uMnq8zS HwYOJy25CpG4V56etr5SN0TerOiM3jy5L2E9Cye9q/PtXix0icDJ5Q4vylVdAVnD/Kzz 6nnfRvLTXZTDpMACJKBQdrGGeIVwy4Px7Hpb9ACeOk6v6GbK/X/nOoyRh5FvNHvGm/l6 XUGA== X-Forwarded-Encrypted: i=1; AJvYcCWxguU7COJjXYI260ESMJtk5jab+CoQcDEWzM5bxOtnlDd9fcAL4OiZ//8djiZ+B17I++/LTVr+THo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy5IUQhEy2hkigNeYjHc586mNQHrerHxQmWXJSlqZ5cSJWlDxjc RuJX+kvPBHXXRsEPZvMsU0aI4/EpxKZX8IPU/M84hBzyzyOKzhsof05d8izOx79LgQ== X-Gm-Gg: ASbGnctyRV0nEvAgLuKrcIU5cGbAJ3D3DT8jjBW2XlS8egffkMx6qrVeJB69eDdDOxJ 6DI7JxDT5X4+NpgRZdqtIgv4nuza+vz/UGD8ZtyFdSST+IdjWV2wkh1kx+MtaLH3ug9SVVwJrkd FZTiu97+9Og7UUeYWoZLNPJN5CRVtgwDFxaUoNd+rG3eHIICOMeryjsWsJ4KrP1pK7mNx8mYVpc bD+0e9IY0/op9HW6U29wPQXx77kGaK+sR3H22GOZ7jkWwQpHryY2r16NhQ/EmH9eN+gVJ0eiv4j /QKjGHgJU0dlOhO/vHzJ/j70s2s4zUR4+lPfCEMdLpdCn+D9ErDB4d/Fvv28BoBCyfnPPOlPZ5M urfu7ocFgCFUGC4ZjRRSRrCk88P6ouDChzJ0SAAb8UKwQkafTEGsF8360KzVOwQIuYiDNvcyVd0 Vyh8rGc2U= X-Google-Smtp-Source: AGHT+IH9TD/9JZy9lZOw0+aAjFP30H4uRCdqXXmolB04FhjBTODbFnhJyoZAS+gFdAk5gU58IluTwA== X-Received: by 2002:a17:906:3757:b0:b04:1249:2b24 with SMTP id a640c23a62f3a-b04124939a7mr486049166b.37.1756732517890; Mon, 01 Sep 2025 06:15:17 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 15:15:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/23] x86/traps: Introduce opt_fred To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-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: <20250828150409.901315-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:03, Andrew Cooper wrote: > @@ -20,6 +22,9 @@ unsigned int __ro_after_init ler_msr; > static bool __initdata opt_ler; > boolean_param("ler", opt_ler); > > +int8_t __ro_after_init opt_fred = 0; Can't this be __initdata now that we have ... > @@ -299,6 +304,37 @@ void __init traps_init(void) > /* Replace early pagefault with real pagefault handler. */ > _update_gate_addr_lower(&bsp_idt[X86_EXC_PF], entry_PF); > > + /* > + * Xen doesn't use GS like most software does, and doesn't need the LKGS > + * instruction in order to manage PV guests. No need to check for it. > + */ > + if ( !cpu_has_fred ) > + { > + if ( opt_fred == 1 ) > + printk(XENLOG_WARNING "FRED not available, ignoring\n"); > + opt_fred = 0; > + } > + > + if ( opt_fred == -1 ) > + opt_fred = !pv_shim; > + > + if ( opt_fred ) > + { > +#ifdef CONFIG_PV32 > + if ( opt_pv32 ) > + { > + opt_pv32 = 0; > + printk(XENLOG_INFO "Disabling PV32 due to FRED\n"); > + } > +#endif > + setup_force_cpu_cap(X86_FEATURE_XEN_FRED); ... this? All non-__init uses could use the synthetic feature bit. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:17:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:17:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104767.1455809 (Exim 4.92) (envelope-from ) id 1ut4PU-0007ZJ-G2; Mon, 01 Sep 2025 13:17:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104767.1455809; Mon, 01 Sep 2025 13: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 1ut4PU-0007ZC-DN; Mon, 01 Sep 2025 13:17:24 +0000 Received: by outflank-mailman (input) for mailman id 1104767; Mon, 01 Sep 2025 13:17:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4PS-0007Z3-Vp for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:17:23 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20627.outbound.protection.outlook.com [2a01:111:f403:2412::627]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fd7014c5-8735-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:17:20 +0200 (CEST) Received: from BY3PR05CA0003.namprd05.prod.outlook.com (2603:10b6:a03:254::8) by SJ5PPF75EAF8F39.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::999) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.25; Mon, 1 Sep 2025 13:17:15 +0000 Received: from MWH0EPF000A672E.namprd04.prod.outlook.com (2603:10b6:a03:254:cafe::bd) by BY3PR05CA0003.outlook.office365.com (2603:10b6:a03:254::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.15 via Frontend Transport; Mon, 1 Sep 2025 13:17:15 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by MWH0EPF000A672E.mail.protection.outlook.com (10.167.249.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Mon, 1 Sep 2025 13:17:14 +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, 1 Sep 2025 08:17:13 -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; Mon, 1 Sep 2025 08:17:13 -0500 Received: from [10.252.147.171] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Mon, 1 Sep 2025 08:17: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: fd7014c5-8735-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZPX0FaIHbwS50xg8Cm+sufucZpuYsOkZwDabBurdznP52DMpdZD2B6K0rtOKxi8hJm16JEzkWS4mSEyENqkHwB+ui7LEvmJvX9/Bw0EUzc+iA8RA0f8t675yMlm5f30Sh7CwapruFJMB46kGZIWhNumutOlwhWg3+UPYKOk9VbgaFEMVGs3PTXkZL33/mQTqAxsey8lF7RwJBvi/JhJyGYGEz0XWEaOjogG2QMAc1zA46rGoM2pi1zLPIhg/3ZHF4MAib1cH45B4NxSwYA9SDvQ20QPpB/0tebf2qA/1aGEAg8YEIUaunsX0iZIoj/yhgaiNfSfhDdN3V+kb4f+WXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rx3fOCSwsGtXm6ZBrmsvbB7eQMtANgtB6v4VWy1ncdE=; b=mFCqh33QrWKPVGvm8ueyxIlC9MjmbTfhuVZ507DwAMMt5BiSKi+OGZafQzAK6F4Upn97ea7a9pzAX0kb43KHKInzNARl9nVBHfB+V9ezzEBBrsioiDmT5jTLYQk48jQC39rJv3U9cLJQycZ//VW0M3sxKcHkkBT+GLY4wgncHLjo666dRnogdzaf02y089cG9/OwkGJqwqj62mwxu+LNmC4S02Tl67fjfHU8X4CVY/gWMlUo5TzzEM0L9AMBZiOMUj9b8uiCvqhWs6TGReD8C0STfcLp14EALla/OSswjm+JECaRU3rzoJmIaGe0wBeiFLhS1KpmbN3doHi9iHGOIg== 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=rx3fOCSwsGtXm6ZBrmsvbB7eQMtANgtB6v4VWy1ncdE=; b=Z/3MYDgM4GC9QQQhpZIgB+JAYhjkpBszxzvXdO3Vo1LVLwWx7sCu9/UN2dsyr+qPxsJA1AorVgC1BNSyj14pwGmPNtwfN0XQ7mzyis1LO5nnSjLp8F+mvBd35b04plAyMZEKCDjTt3uzC171MnxqdI61ZiBd+L5c3DI3Vrq3mfM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <20f5b553-75a6-43b3-9b2f-1cf73b9589c3@amd.com> Date: Mon, 1 Sep 2025 15:17:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of device tree To: Ayan Kumar Halder , CC: , , , , , References: <20250901123103.11418-1-ayan.kumar.halder@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250901123103.11418-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A672E:EE_|SJ5PPF75EAF8F39:EE_ X-MS-Office365-Filtering-Correlation-Id: 1d07605d-06e7-495f-74af-08dde959de48 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?b1lscFRUV2pYRVRtWmVsejVyazB6aTBBR2tycFBxZ3orMFdHN3lDcEJ6M3JB?= =?utf-8?B?eGZhRitQclZPMm5rMkNneGlodkYycHpOUUpEMTVQbk5LT01PSUhBSlBGKytI?= =?utf-8?B?ZURRZmwzTlJIK1o0Tk1hOHJPR05XOVN6Y2J1ZXdkeFRkK3FLU0dyRlVVdll0?= =?utf-8?B?WENNSDBXYUlBRmt2Y2NsZ21mVnp5NFFTbklDLy9pcWNnQXBVTVVETnNRQkdj?= =?utf-8?B?ektwL2hHTmNuYTdrK09ZRUtlZ0hZK0dsQWROd1EzbHJvOU1zd29xOW5Yb3g3?= =?utf-8?B?Yk45akVMTUl2bjBpZWtPUFBFQndjRWZ3Z3hmU0tQRFBCcEx1NWdXYnVqbi9P?= =?utf-8?B?Z1IvenUvV0Z3eEpmOE92WnBZSGFJT2tiNkxTNGN1ME1jbUJTb3RPZi9NSWhh?= =?utf-8?B?YzJXcFNXYjBqUTkxT2hUVzVzdDVnSnhtOG9wSmM0eFVlTmcvWjRiNm4xSng0?= =?utf-8?B?OG9VTHhleWhSU2VzSU8yM2swL2M0QURNcnJzYjhqU3BWRjY4RWg1SE5zVWtx?= =?utf-8?B?MXhJMUk5ekl5dTRBdTl6NHF0QkpNb3VhcVI1d0U5Z3F0ekVIMlVlZWYrNEFU?= =?utf-8?B?aG8yVFR3b1pJbVh6TTRkSFQweFg4N3VxcWNvMmpEQ2NxcFFKQnhjTnkzblNC?= =?utf-8?B?OWQ4VWdNWEZFS3Q2MTJGT1d6Y2FkcWJHays5ajJRVEFvemFoRSs3eG9uYnky?= =?utf-8?B?SWRia1dkU25ldnpjcGgxLytCUW8yTUdwQWZxQk1UN052SjdTMkllZXFkazRD?= =?utf-8?B?T28zdmc1YzVEc3owK3dNRGY2VStJdmVyVUQ3bHJpckhoakN6TU52STlzQ3lq?= =?utf-8?B?Ti9tOTRHZndPS2p2U1NJYy8rdVd2SDBMNnF6WWduQjhYRWhRNklNR0d1a3py?= =?utf-8?B?cjVzVkpWQW1rL2VuVlZZZzJ0T1piNkFuWnJJRW9sK1JFQ0RFU3Z1RlhQUERQ?= =?utf-8?B?ci9YN0NCWTMyVWh1dm1QNkQrWjBxT0VZZnJGeUQ5L3B2aE1jQ1E4OVFPWHFy?= =?utf-8?B?Qm5nbUZPaUU0WVowUEw5d2EyN0l4N1NNWllDWWNDaXNOMTdSemVkallYRm16?= =?utf-8?B?SXVrK2ExdVEvclJId2hTckJ0cTRRNmUrNkVPNlVWR2o3MU5oeUlWMkZDZHAw?= =?utf-8?B?RDR0U0E4RkNmc0E5SGFKMVl4c2pkTGJSNkM2a09NMzcybkd4cnJ6cVZxWWwx?= =?utf-8?B?aE14ZW5FTDVaeU40TVNSZWpXTnZCdjArb0ZFSmZKa2dUU2FyelgyTDF0MW8y?= =?utf-8?B?YVNJZkhZUlpFM2c2YW9qODhVdzI3ZVFsU1V5dWIyeGs5bFNaSWRvZmowMGth?= =?utf-8?B?bWJwQlJZV1VvYk5rZDlJUWZVN1ZOYlk3bE1HWEp4OThacVRMR1c5UlY4VUtY?= =?utf-8?B?eEtuNHRwNk15Z1BXeXMySnBJM1VEOVlBRVBmRmdUY0htRVBlUDdJZzZTSldN?= =?utf-8?B?d2xjK0xIa0pxQVk3YTdrSmdEOXgzcXJJazBzQ0xVNGZwcUkyOUFpY1FpeFhx?= =?utf-8?B?ditXMkxwUi9iN0VqTDM0NXJIaHF5elFrdTRDZG93amQ0Z3k4bmd2bGxNU05o?= =?utf-8?B?OHR0UUtzbTNSV0YvUGhOWCsvVTV0RHFwRS8zSHV0VjNEays2QW5aN2hITnFl?= =?utf-8?B?QWdNTThLQ3Budlp6bHFOWVA5SnpDQ3BuMjVSaVZsRmkxTy91NlRjNnBpSm1a?= =?utf-8?B?djN3TGFWWnoxaGU0V1hnak1zeHlJSmVRVHVCK0NRbGdlSkk5c2oyZm0vVzBT?= =?utf-8?B?VlJZYUhXaE9iWkZDUG5pWk15NVVaQmFQWmw5UmxydUVmUE0yNGxsZGVwSDZ0?= =?utf-8?B?TmFZL3YyaGh5d3pqaWtld0pGN1hmNC80Y2lqK3U3RWlYMklUdGxHblhLVXZU?= =?utf-8?B?dDdPTFEvaENreVpLbkYwRDkxd0g2S0pQL2hpOWRGc1ZhOFZFZzY4RlFaWEdW?= =?utf-8?B?bHFFc1o5ZWV4eUpRa1cxWVhQNWNhYm9OME9KQi9yTjkvQlcyemRUOXVSTHZB?= =?utf-8?B?TzdjV0t4NDBqb0JiYmdza1d6TGdWcE1nUFhUNFdqelZVZ3FQcTBVNFlGOGkv?= =?utf-8?Q?JbEl7u?= 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: 01 Sep 2025 13:17:14.5790 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1d07605d-06e7-495f-74af-08dde959de48 X-MS-Exchange-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: MWH0EPF000A672E.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF75EAF8F39 On 01/09/2025 14:31, Ayan Kumar Halder wrote: > Xen gives a panic if certain nodes are not present in the device tree. In order > to prevent this panic, scripts/dt_sanity.py is written so that it checks if the > node/s are present. If the node/s are not present, the script gives an error. > > User is expected to run the script against the device tree before booting Xen > with dtb. I would expect the script to know what to look for in a passed dtb. Otherwise it's just a script that searches for the list of specified compatibilities by the user. In other words, a simple grep would also do the job. Compatibility is not everything, there are other things that would prevent Xen from booting. Also, often times the dtb is modified by the bootloader before passing control over to Xen (i.e. it may differ from the base dtb). ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:27:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:27:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104783.1455819 (Exim 4.92) (envelope-from ) id 1ut4Z5-0000vJ-CJ; Mon, 01 Sep 2025 13:27:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104783.1455819; Mon, 01 Sep 2025 13:27:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4Z5-0000vC-9M; Mon, 01 Sep 2025 13:27:19 +0000 Received: by outflank-mailman (input) for mailman id 1104783; Mon, 01 Sep 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 1ut4Z4-0000v4-1J for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:27:18 +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 60fee254-8737-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:27:17 +0200 (CEST) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3ceb830dd58so2339283f8f.0 for ; Mon, 01 Sep 2025 06:27:17 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d540843a2csm6651684f8f.22.2025.09.01.06.27.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 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: 60fee254-8737-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756733236; x=1757338036; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gvbf806z1YTJkAoFI2g50YQgUWKaxjjGYjfQIW29zBM=; b=JNpskKmmwsydl2qm78zoCZjRvB5B+2c2ZSY2/ZQx/Db5yiEC1MSqmDSaU+GerBw6OA xjr3eG+6XmMQt5+KfKKlLtGGrrCLeLwityJDQIZoUYOI8sYJosFiIfi/5zycNU1eXKd+ 9RfNFF0VsgWaW+DWq6w1rMI3cQ/4QMXLata+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756733236; x=1757338036; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gvbf806z1YTJkAoFI2g50YQgUWKaxjjGYjfQIW29zBM=; b=cBecyQBlwT/2UlqHbNmMcI/9A6lCxkbhjdY2kH2YTHu6q8LUU0WPCff1Aii8/87F00 +61QuXc6r8a5lNvAFY7ZGFxa0Qj8gyPLbHhFIFiovsOyiI4Sm+GbaJAewzFohJqgAK8v 4bjUEXHf+pYAyGtWnynD4SHb/+y7jug119nttSeJzfVGX6Opm5yJuOPeYzw9CrYgyfUR 0t7fN+qNAJXMDTaxU6IfD4o2Z/h4tw2Gg4syU47ixS4SSPEtBbbBkTg72VDHmSNyqolU iD39sDmGjDVjWrDFd97Zb9gHot96CnugG3Vfl0gT32fOZE78gf/evbRjFEWy1NKasgku 4Drw== X-Forwarded-Encrypted: i=1; AJvYcCXor8tSqn4tj99HNlny6ZoELxtgplfpPXB1hhLnBK/eXMg0sCC86XVixRYsje7Shdeb549SqGSZs+I=@lists.xenproject.org X-Gm-Message-State: AOJu0YyZswgb/BcMJ1bI+NtLdbOYWGYR9M+TxWw+ELdKXrzn+tG9S07m 6zhSAcTtsz1rR77XslS2hLJZzd6yH4WDf1VyhTYGcWUFfumbeUy74DW8j54NCjnL5EU= X-Gm-Gg: ASbGncskmbK/RJpZc70332oGu1SngEJD3UV2XuuvKzaiKdRjliCiRXA6XshByHsCI8v ReOGjkWCWpK3VOhMcoTBv6F1OMRFcR354WQsWEoLCT9IMz4FPj0OKwagCyQHM8p9p7NdUUJSjUg xQa9gL1prPkElw9vaz7m4/YUYeb3ehwOPdWU1fm4zZjbdlA3UfKwh8t8tPWzv/OiHkBmLcZbuMV IT8T1LmtGDDPLeS1gx9k3tpNBVHDAV9R59dKoIvtoe/Hh1M3sxl4AlXLyH6TJXq3BSIF1rEHeM/ WhbRlFSLdhV5r0lQ3qlvHNvfgqwBfomcpNglWn846LoM/pDezNCZOsIoimb1i7yhtrsxTgYisnJ oZpmsmhvtkZKhVevs4YLje3g6UNCXhlSumVPUYijC/RJTt87VXwYs0TMS22YJRokrQqpBNy13mG Budu4= X-Google-Smtp-Source: AGHT+IGmLZFJrWr+E43gbEu3gZNFrvKDiSGNPzx8rF4EupiVVwzmB4+zY4KjlkHTbAdX8WPlhlVWmw== X-Received: by 2002:a05:6000:40dd:b0:3d4:13c4:af73 with SMTP id ffacd0b85a97d-3d413c4b319mr5518148f8f.12.1756733236366; Mon, 01 Sep 2025 06:27:16 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 14:27:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 20/23] x86/pv: Exception handling in FRED mode To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-21-andrew.cooper3@citrix.com> <1800ea68-eee1-4433-aa22-954dcd226fe5@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: <1800ea68-eee1-4433-aa22-954dcd226fe5@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/09/2025 1:57 pm, Jan Beulich wrote: > On 28.08.2025 17:04, Andrew Cooper wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct cpu_user_regs *regs, bool ist_exit) >> >> void asmlinkage entry_from_pv(struct cpu_user_regs *regs) >> { >> + struct fred_info *fi = cpu_regs_fred_info(regs); >> + uint8_t type = regs->fred_ss.type; >> + uint8_t vec = regs->fred_ss.vector; >> + >> /* Copy fred_ss.vector into entry_vector as IDT delivery would have done. */ >> - regs->entry_vector = regs->fred_ss.vector; >> + regs->entry_vector = vec; >> + >> + if ( !IS_ENABLED(CONFIG_PV) ) >> + goto fatal; >> + >> + /* >> + * First, handle the asynchronous or fatal events. These are either >> + * unrelated to the interrupted context, or may not have valid context >> + * recorded, and all have special rules on how/whether to re-enable IRQs. >> + */ >> + switch ( type ) >> + { >> + case X86_ET_EXT_INTR: >> + return do_IRQ(regs); >> >> + case X86_ET_NMI: >> + return do_nmi(regs); >> + >> + case X86_ET_HW_EXC: >> + switch ( vec ) >> + { >> + case X86_EXC_DF: return do_double_fault(regs); >> + case X86_EXC_MC: return do_machine_check(regs); > Looking at patch 21, I came to wonder where it is that we're moving back to > SL0 in the #MC case (which may not be fatal), for ERETU to not fault. (Almost) any event taken in Ring3 enters Ring0 at SL0, even those with custom STK_LVLS configuration. See 5.1.2 Determining the New Values for Stack Level, RSP, and SSP Nested exceptions (i.e contributory fault) and #DF can end up at SL > 0 with a Ring 3 frame.  In principle you'd need to do recovery based on regs->fred_ss.nested but Xen doesn't have any contributory exceptions configured like this. Under FRED, there are far fewer ways to take a contributory fault.  Pagetable corruption for the entrypoint or stack, or hitting a stack guard page.  Hitting the guard page will #DF; others will triple fault. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:34:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:34:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104793.1455829 (Exim 4.92) (envelope-from ) id 1ut4gO-0002dm-2z; Mon, 01 Sep 2025 13:34:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104793.1455829; Mon, 01 Sep 2025 13:34:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4gN-0002df-WF; Mon, 01 Sep 2025 13:34:52 +0000 Received: by outflank-mailman (input) for mailman id 1104793; Mon, 01 Sep 2025 13:34: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 1ut4gM-0002dZ-PW for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:34:50 +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 6e3c4ff3-8738-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:34:48 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b0411b83aafso250023066b.1 for ; Mon, 01 Sep 2025 06:34:48 -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-b0421939da1sm325247266b.27.2025.09.01.06.34.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:34: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: 6e3c4ff3-8738-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756733688; x=1757338488; 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=AcZq/b2ed7pzoBGIlt8Bibb6w3RcGPDodW5v11XHdWk=; b=bLVg5qRe6f9Ev/jdHIQ9Gdw6GS5FKdYkA2MBCvmyp0W8opEjn0TrUghW0ENL+EJh+A fOy9BHWWiqxQpOg6WwoD6U0cYf7GCq8hwaMNlQFSMF5HyF2J2vIYxCbDNC+fpRWZniBx oqmICEiLUgRFKIRZ0VUyPXzja7pZIflVFNjpHEWGIOi/v6sF1UX0NfNMVs/9F7KiDCmu 4RHaBBBv1yK+RITc+Yp9t0zpXA9HUZ5/8MsfeOmxr1XttwoMe8YWgXR0QVvb3eqC9PoJ uT87aPsEE9G8RGwbW7tr9MtmDQnbTKV92qrbGSFkSGC7Mokjp8i/mTSR89JGQYmP0cFw 3gXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756733688; x=1757338488; 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=AcZq/b2ed7pzoBGIlt8Bibb6w3RcGPDodW5v11XHdWk=; b=muSo17o4piZ4cN7Gu6CqZkoxDrWV6efBBlOaC0JDAK9JxhhGoft8SwAnn8BjbSS23G 1zi+mPAg9fVKiOYzxPk9oM3fTz4RI2AdTm6pDVK8JsXfspfrKDvz4O1M7fUlVdfDP+PV 5yxzVNf6ZP4aLfaNYMVZAZVcXXD2UuvadEiTlseN/WvSJUcycDo5LBLEam9BS+JxGinC TqCz14Lm4FDjGC1iZ6xX8dchzi5eGmN2ujcvkNPn3ForcEkAlo5J3nSNjDXSrJlsxnzE QpELqURXAqamHshHlArprSRTXBvMJh3T2ApHokskxwfPvfKGldX0SrYfgXGBBkyE7qHk HvkA== X-Forwarded-Encrypted: i=1; AJvYcCVWZ5Wx6RtnmNYJ8pj3UToxv2JK0lg+GXozowKXbdkBkEG6rElANHYfWEyMneXYwWAjru6K6ix6GeM=@lists.xenproject.org X-Gm-Message-State: AOJu0YyjPFwX8AKVkL8Ut0LvhEe9cVv79PCy9ix/1BHhB7cPUu8ojK+U VYTJnv7XoBYX68PlUeB6TgofDRnQvoLF0onFaciP7QOLfCUPOM63kDnU X-Gm-Gg: ASbGncvhxDKPvg5ZjJK2F8Sci4gUIqSrUR1judCGWN2kltbpR5sYHYLyGHV68Mgy7uX ARGfGrr62D1RqPXXC8BYNsTbaF/smnF0BXfiXPJm/mhXugec+++VVWZ1sVbOuW6JzvZQYUh+HUv fxecVS3b0QaCOmMqq/O1AdOlEl3Ucyx53TXWQffISql5JZZP7YsAS43TJBa9zNMxIz2momFiBGZ udipinjj8NIfifl+Q9YTZq/TWyl0frUJjJ22oCAPhZNA1TbN+Z+qXUPao2z9HLQy+Jus6vH4x+z iq29vU2x6m2CvZBtFa97GG06Hc5psOlPSORu+Aev7NGmC0kcBpPeQc3fQFo7aSKfeTLuhB4wfDO nxMmTBFoZxfrjTHOg6GXx1SynPUoz6DAvgd76wQREk5nOhNZs/JYrS9Hu0Ukg7bdZHG07lZI= X-Google-Smtp-Source: AGHT+IGZqvtTDV14xsHPjWFEFz8V7RnAOGKikzXl84UW5RCrNGk3M7agEjYEI0TZzmtSw1XqCN5DHg== X-Received: by 2002:a17:906:f59d:b0:afe:ae99:9d23 with SMTP id a640c23a62f3a-b01ec52d58dmr727181066b.61.1756733687631; Mon, 01 Sep 2025 06:34:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------cySU0ii2DAaFMPoTVcCZBC9V" Message-ID: <394c7670-7106-4329-a8ac-d31057c8f2a2@gmail.com> Date: Mon, 1 Sep 2025 15:34:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 1/3] xen: Define xen_domain_handle_t encoding and formatting To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------cySU0ii2DAaFMPoTVcCZBC9V Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/29/25 11:58 AM, Teddy Astie wrote: > xen_domain_handle_t is defined as a opaque 16-bytes blob, but is > commonly used by toolstack and guest as a big-endian encoded and > formatted UUID (alike RFC 9562). > > Clarify the definition of the type to ensure the guest and toolstack > interprets this value correctly in a way consistent with existing users > (at least with XAPI, xl, libvirt, hvmloader and Linux). > > Fixes: 30ce2a9295a5 ("Store an opaque handle (tools uuid) in the domain structure") > Suggested-by: Andrew Cooper > Signed-off-by: Teddy Astie LGTM: Acked-by: Oleksii Kurochko Thanks. ~ Oleksii > --- > v2: > - introduced > --- > CHANGELOG.md | 1 + > xen/include/public/xen.h | 7 +++++++ > 2 files changed, 8 insertions(+) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index cd34ea87b8..8c4435c181 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -11,6 +11,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11 > - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25 > - Linux based device model stubdomains are now fully supported. > + - Clarify guest UUIDs as being big-endian encoded. > > - On x86: > - Restrict the cache flushing done as a result of guest physical memory map > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index 82b9c05a76..a219ef870f 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -973,6 +973,13 @@ typedef struct dom0_vga_console_info { > #define xen_vga_console_info dom0_vga_console_info > #define xen_vga_console_info_t dom0_vga_console_info_t > > +/* > + * The domain handle is chosen by the toolstack, and intended to hold a UUID > + * conforming to RFC 9562 (i.e. big endian). > + * > + * Certain cases (e.g. SMBios) transform it to a Microsoft GUID (little > + * endian) for presentation to the guest. > + */ > typedef uint8_t xen_domain_handle_t[16]; > > __DEFINE_XEN_GUEST_HANDLE(uint8, uint8_t); --------------cySU0ii2DAaFMPoTVcCZBC9V Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 8/29/25 11:58 AM, Teddy Astie wrote:
xen_domain_handle_t is defined as a opaque 16-bytes blob, but is
commonly used by toolstack and guest as a big-endian encoded and
formatted UUID (alike RFC 9562).

Clarify the definition of the type to ensure the guest and toolstack
interprets this value correctly in a way consistent with existing users
(at least with XAPI, xl, libvirt, hvmloader and Linux).

Fixes: 30ce2a9295a5 ("Store an opaque handle (tools uuid) in the domain structure")
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
LGTM: Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

---
v2:
 - introduced
---
 CHANGELOG.md             | 1 +
 xen/include/public/xen.h | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index cd34ea87b8..8c4435c181 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
  - Linux based device model stubdomains are now fully supported.
+ - Clarify guest UUIDs as being big-endian encoded.
 
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 82b9c05a76..a219ef870f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -973,6 +973,13 @@ typedef struct dom0_vga_console_info {
 #define xen_vga_console_info dom0_vga_console_info
 #define xen_vga_console_info_t dom0_vga_console_info_t
 
+/*
+ * The domain handle is chosen by the toolstack, and intended to hold a UUID
+ * conforming to RFC 9562 (i.e. big endian).
+ *
+ * Certain cases (e.g. SMBios) transform it to a Microsoft GUID (little
+ * endian) for presentation to the guest.
+ */
 typedef uint8_t xen_domain_handle_t[16];
 
 __DEFINE_XEN_GUEST_HANDLE(uint8,  uint8_t);
--------------cySU0ii2DAaFMPoTVcCZBC9V-- From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:42:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:42:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104809.1455838 (Exim 4.92) (envelope-from ) id 1ut4no-0004Oj-Sv; Mon, 01 Sep 2025 13:42:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104809.1455838; Mon, 01 Sep 2025 13:42: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 1ut4no-0004Oc-QK; Mon, 01 Sep 2025 13:42:32 +0000 Received: by outflank-mailman (input) for mailman id 1104809; Mon, 01 Sep 2025 13:42: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 1ut4nn-0004OW-Ia for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:42:31 +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 814f798e-8739-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:42:30 +0200 (CEST) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61cc281171cso7427823a12.0 for ; Mon, 01 Sep 2025 06:42: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 4fb4d7f45d1cf-61cfc214bacsm7423614a12.16.2025.09.01.06.42.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:42: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: 814f798e-8739-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756734150; x=1757338950; 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=Hhw3UBPRNy0F2MJaz1C8wYQ0dbUgJQ39KZSUREKvcBE=; b=FevgZD7CIyQUl/N2XIagUCgfvJwgEFz1QiE6vJ8CIVHtSI7fjbklBw479nUBuv7+/N 3tRgE9wQMJsLBj9MUM/cT4mTg7RAYn2sp5veI+XCrQ1u/nGJybWaV21rnQJTppfU5QfM GUD+9POyxpXNa+VNv7BV4/D+HiVhyNaqIPbc1iLb6pcCS553qmB6s7sM+GToilH1Ah4a q9elKAm/mtJnxFlkv5Cer62HxpvkHTtKo2wd1Kkve3b2CVCwsygVgc4INGnytWExm3+e 8gr1BjGKe6qshCT5zsWERgQNzMKPyb2zgcwt0jDYmYKewv1MBZy3WwCxe5z/YV3CV7b2 fing== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756734150; x=1757338950; 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=Hhw3UBPRNy0F2MJaz1C8wYQ0dbUgJQ39KZSUREKvcBE=; b=TF/Ci0ZRaVcPj4Thkso98ObkkipH3/fHFpTU6TQI5vB+zKnXQWSyOrGLzT7tfRraMz mCtn0YNx0dzcDLRg5iCcDaBGjG2xGaj7roasKJ9M0noKP0Vcpd/twQ/WiusmHy5sJptg IVGfoXwNEzCttuT9E7sxNbzpq6qTbQqdidLtB0Ht82YiKzKQpS9i2LHz/763qYtU1g/p 2dRkjjnuf0kPwgPsZvIfxhH/4a+34+NCsc6Utj/akPnal2tXI2uWhss6wMN3qec5NuIC 5LLcboK1jNWbdMrXZWHIRs2c9oCx7dkQebMxKBL0Ll2tsgR6pMRmFOGZeohQG4/rPN9F S+2g== X-Forwarded-Encrypted: i=1; AJvYcCXVokITA4hiUQRW8uQqovLPoBTgltodvJ5blcDBZ1TOBDImRWAeHfEB+LVpXByXI7zRsaX3PhtwJEo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx5xyNMIP63m3rb5P7mPhrbx61viPKkJS89YVznE4XusPdzxe1z SFcMEw+5nCbszkYexdw+8sQe1VDJWewRXv5f/l5B5obKvTQ74Q6TYWDXlkmYMQ== X-Gm-Gg: ASbGncuoalvwwTh2anJlpNfvTB70mvvDKToCehQaRVFRwU7QSCRmDt/kUqQcD2ae6cG D7PSxIJNmlwZFHswbX506WiOenzEv3033UfnhFdw6cfz0CF2oLexjdhEQ+i9MY32bkrhvo3o4ey RYciwNUnJ6d1CDiUUu7LQ9+E2Iqg3vKGkq131x0CYMvpeyxOXm5Rp8lY6oaYtjXHiyApMs6HydI tzma3s5fNM/zhJ7OSsBPyGMO1dcor+O5HBCurM2RFUCrBYLQ86Krqd4kLSGegleHrKeKhExWabP 8kp753IPeCSVGihVJp3mepjDImTzitKyUGpv6SiK4hU8i9UaAebXP2utOvcx/vejDbLxr0eeQJw xLHh6182Jgl+zlkncj9ZdSjJCX6C/z0ObSNFgLcgRXhONWW/Htz4NkpFRmpyNwNFOcO45wF4= X-Google-Smtp-Source: AGHT+IHGN5E9Cd8W03pN+9DDfJF2+EhUQT82qjoCdzi4TFPP3vq5jQyKsVP/h3zqSVQXQRMeRDLJNQ== X-Received: by 2002:a05:6402:504b:b0:618:aed3:38a with SMTP id 4fb4d7f45d1cf-61d26ebbf9fmr6551311a12.31.1756734149542; Mon, 01 Sep 2025 06:42:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------nupsem2UgoMYGXQO7druMN0S" Message-ID: Date: Mon, 1 Sep 2025 15:42:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 3/3] CHANGELOG.md: Add SMBIOS 2.6 update statement To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Community Manager References: <301a84287488629932950c1cefef3a97c3d9ba0d.1756460430.git.teddy.astie@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <301a84287488629932950c1cefef3a97c3d9ba0d.1756460430.git.teddy.astie@vates.tech> This is a multi-part message in MIME format. --------------nupsem2UgoMYGXQO7druMN0S Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/29/25 11:58 AM, Teddy Astie wrote: > Signed-off-by: Teddy Astie > --- > v2: > - introduced > --- > CHANGELOG.md | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 8c4435c181..80a8273d7e 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -34,6 +34,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port > Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device), > and 28 (Temperature Probe). > + - Updated SMBIOS version to 2.6. Generally looks good to me, but I think it would be nice to add a short explanation why it was done. Something like: - Update SMBIOS to 2.6 to fix UUID endianness mismatch with OVMF and ensure consistent Linux guest UUIDs. Does it make sense? ~ Oleksii > > - On Arm: > - Ability to enable stack protector --------------nupsem2UgoMYGXQO7druMN0S Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 8/29/25 11:58 AM, Teddy Astie wrote:
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
v2:
 - introduced
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8c4435c181..80a8273d7e 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -34,6 +34,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
      Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
      and 28 (Temperature Probe).
+   - Updated SMBIOS version to 2.6.
Generally looks good to me, but I think it would be nice to add a short explanation why it was done.
Something like:
 - Update SMBIOS to 2.6 to fix UUID endianness mismatch with OVMF and ensure consistent
   Linux guest UUIDs.
Does it make sense?

~ Oleksii




 
  - On Arm:
     - Ability to enable stack protector
--------------nupsem2UgoMYGXQO7druMN0S-- From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:49:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:49:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104819.1455850 (Exim 4.92) (envelope-from ) id 1ut4ur-0004zg-Lk; Mon, 01 Sep 2025 13:49:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104819.1455850; Mon, 01 Sep 2025 13:49: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 1ut4ur-0004zZ-GU; Mon, 01 Sep 2025 13:49:49 +0000 Received: by outflank-mailman (input) for mailman id 1104819; Mon, 01 Sep 2025 13:49: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 1ut4uq-0004zT-0b for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:49:48 +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 857e38a6-873a-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:49:46 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-61caf8fc422so7725946a12.2 for ; Mon, 01 Sep 2025 06:49: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 4fb4d7f45d1cf-61cfc52a886sm7176639a12.43.2025.09.01.06.49.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:49: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: 857e38a6-873a-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756734586; x=1757339386; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=7nzHZ8KlngdM0RWEOsenfwm0FrS/YZ7bF5tbv2VnsXg=; b=gax4zTBZsbtoLWrw5KVNdQ3iKjiLa6GGwQw6/bA+jm9llFOIErJMEd6DVZUhMdey9I g4o3UlKGjI635Geb3lX6FyFrEzrCyQAd/sXsCTMol9uB3LSR3CfcEi6aUpJ0yqGMGIAJ q8TN4b2/lk8Zuq4dH24z/0OAybfwEQfKEZ6Lu/8u86p0WG6W8YX4GAJqwxzgZJJ3rqQb e/51zJQ6yk3FshCzQXSxCQj4Yd7wVryvu5yRGQFfu9lCrfvUMOgb34TohwnTN1vvsxCf X3Nu34z4urx44C4V/bn7Heq+87Ptg1/X4EXcFnzja2S/lpeKMbJIYXdfog8Tz2XY+zxt NLqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756734586; x=1757339386; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7nzHZ8KlngdM0RWEOsenfwm0FrS/YZ7bF5tbv2VnsXg=; b=cXDhUyt/6CFjHf1FtAJenClIEQr8V+wrUEH68F9aNMU6kks/92Y1wU+EuORLjRVeqZ 36crU1tgiF0NybO20/dlACDa6Wb+qlnEBuGjAlMIWmoVMPd1JyIvnfbUeA1tcoea+ypA WUJSmproDRjVQojwWnO6y/4hiurMhlhZOINh6kEtHUL/SO+yHxafL+Suxgf2/8E/M8BR hhH1Zz4nQWBOVJAToXGrw9BUntAffLS+nTKrQR0aCSStKUi4WdElPIFhzYUa28DzJwTj gtodxnu1dTxYcWAkY+ijpUsFnEMTjOqXTVSfrYG4T8wv+H1vM5MGf+2uDq9kZHcDBIhx sEFg== X-Forwarded-Encrypted: i=1; AJvYcCVzy60irPq0PSaW+wGBlEJi+MlILEe1QATHvJN+bLrt4RqV+HeOtZJVlwYinENdifW6c7RbGFYFIsU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy7hu56kNj5StFylB9htIHsQ5tzJOYjf319fq0nkptnZi5ZL2D3 hp+h8IjIUdoq6fooD7ZWkwb3uxLkRPz3h3jiPukyh/ONudugZNI2f1XjcOTub9UxWg== X-Gm-Gg: ASbGncvev61nDWANBab2eNwQFvThbm1EsNSCUCv/xBXtG/jMsXVl4TxvxZ3HRYVPlVH hMaJsCKoNBTM/XYOLT4sP7ZI5RIIAocLW6EhkViuPENrRl4VoMbO2vdKzxanBCPYm3S6yVAecJn uOh87j+DCm31UI/5vwWU+OD4JKqnyZhybwZRPfoCeaLw0fC1dcTqROr7WZ7z5qSEvAVEpUm9GGU rhPvq8rcjRXvY93V1h7IQ08WJEE48TAqayLSflftfLYR/MvXjCKUx1ixhHrekDEGL2beGPPIZFs mIFjGZlGZflxatIEe9H35LbT+QCaPuXwvf++Goa7Q5B0wg6p4JWO2cPvQKp4lPGSyBaSIWF/Ru4 JXc0btrYZRQ/bZCE8kg4rkZUfmwASBB0wYCCUjc9fo8e6yzp8WT/jqTKWxDWBTf0yxICuNoHT3F Mehe5KSM4= X-Google-Smtp-Source: AGHT+IFzEMxRO3/i033QEtuafE2mbILLeCKx+jGUyEtkyOcvNaL7vHXPCe5cTjNiWkKJytiD1fLVxg== X-Received: by 2002:a05:6402:348c:b0:61d:396b:74ca with SMTP id 4fb4d7f45d1cf-61d396b79ddmr7080918a12.23.1756734586064; Mon, 01 Sep 2025 06:49:46 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 15:49:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/23] x86/pv: System call handling in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-23-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: <20250828150409.901315-23-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.08.2025 17:04, Andrew Cooper wrote: > Under FRED, entry_from_pv() handles everything, even system calls. This means > more of our logic is written in C now, rather than assembly. > > In order to facilitate this, introduce pv_inject_callback(), which reuses > struct trap_bounce infrastructure to inject the syscall/sysenter callbacks. > This in turns requires some !PV compatibility for pv_inject_callback() and > pv_hypercall() which can both be ASSERT_UNREACHABLE(). > > For each of INT $N, SYSCALL and SYSENTER, FRED gives us interrupted context > which was previously lost. As the guest can't see FRED, Xen has to lose state > in the same way to maintain the prior behaviour. In principle we could expose a new capability to the guest allowing it to request that we preserve state. Question of course is whether that would be of any practical use. > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -712,11 +712,16 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx); > > #ifdef CONFIG_PV > void pv_inject_event(const struct x86_event *event); > +void pv_inject_callback(unsigned int type); > #else > static inline void pv_inject_event(const struct x86_event *event) > { > ASSERT_UNREACHABLE(); > } > +static inline void pv_inject_callback(unsigned int type) > +{ > + ASSERT_UNREACHABLE(); > +} > #endif We don't really need this, nor ... > --- a/xen/arch/x86/include/asm/hypercall.h > +++ b/xen/arch/x86/include/asm/hypercall.h > @@ -20,6 +20,11 @@ > > #ifdef CONFIG_PV > void pv_hypercall(struct cpu_user_regs *regs); > +#else > +static inline void pv_hypercall(struct cpu_user_regs *regs) > +{ > + ASSERT_UNREACHABLE(); > +} > #endif ... this, do we? If you expose the decls outside of the #ifdef, I can't help the impression that all call sites will simply be DCE-ed (thanks to the !IS_ENABLED(CONFIG_PV) check at the top of entry_from_pv()). > --- a/xen/arch/x86/pv/traps.c > +++ b/xen/arch/x86/pv/traps.c > @@ -19,6 +19,8 @@ > #include > #include > > +#include > + > void pv_inject_event(const struct x86_event *event) > { > struct vcpu *curr = current; > @@ -95,6 +97,37 @@ void pv_inject_event(const struct x86_event *event) > } > } > > +void pv_inject_callback(unsigned int type) > +{ > + struct vcpu *curr = current; > + struct trap_bounce *tb = &curr->arch.pv.trap_bounce; > + unsigned long rip = 0; > + bool irq = false; Move the latter two initializers into a default: case, after an ASSERT_UNREACHABLE()? > + ASSERT(is_pv_64bit_vcpu(curr)); I was first wondering why you check this here, but yes, PV32 is disabled when FRED is enabled. IOW if a new use for this function turned up, this could validly be relaxed. > @@ -2305,6 +2309,27 @@ void asmlinkage entry_from_pv(struct cpu_user_regs *regs) > > switch ( type ) > { > + case X86_ET_SW_INT: > + /* > + * INT $3/4 are indistinguishable from INT3/INTO under IDT, and are Didn't we discuss this the other day? They are distinguishable, as long as you set their gates' DPL to 0. Just that we use DPL 3. Hence I think this wants wording a little differently, to make clear it's our (possibly wrong) choice. > + * permitted by Xen without the guest kernel having a choice. Let Doesn't the guest have a choice by using TI_SET_DPL() suitably? > + * them fall through into X86_ET_HW_EXC, as #BP in particular needs > + * handling by do_int3() in case an external debugger is attached. > + */ I don't understand this, though. An external debugger would better not place breakpoints using CD 03, so I think we'd better wire such the normal INT nn way. And for #OF I also don't think we need to make an exception. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:51:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:51:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104831.1455859 (Exim 4.92) (envelope-from ) id 1ut4wW-0006bu-Tu; Mon, 01 Sep 2025 13:51:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104831.1455859; Mon, 01 Sep 2025 13:51: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 1ut4wW-0006bn-Qb; Mon, 01 Sep 2025 13:51:32 +0000 Received: by outflank-mailman (input) for mailman id 1104831; Mon, 01 Sep 2025 13:51: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 1ut4wV-0006av-KH for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:51:31 +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 c14e5ef3-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:51:28 +0200 (CEST) Received: from BN9PR03CA0689.namprd03.prod.outlook.com (2603:10b6:408:10e::34) by LV3PR12MB9260.namprd12.prod.outlook.com (2603:10b6:408:1b4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 13:51:24 +0000 Received: from BN2PEPF0000449D.namprd02.prod.outlook.com (2603:10b6:408:10e:cafe::bd) by BN9PR03CA0689.outlook.office365.com (2603:10b6:408:10e::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Mon, 1 Sep 2025 13:51:24 +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.9094.14 via Frontend Transport; Mon, 1 Sep 2025 13:51:23 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) 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, 1 Sep 2025 08:51:22 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Mon, 1 Sep 2025 06:51:21 -0700 Received: from [10.71.195.192] (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, 1 Sep 2025 08:51: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: c14e5ef3-873a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SeGd8r2qjaWjWm8hL3eVmwrBMmAecegU3A1ncA2Zpr29EH9jzMgmQf1P0N1SJZnwdv07DPKqqDG70iLexM6IPi3fCIyOSOc97zKAw8NFlgSHQk7eev/1fK/z8p5Ks7OBEaVzjv8k+c07O/IIj8H0s2w+jhWNEEHMCUy8rPgEMi+c1x+d8sa+mfyrD4p4k4/HdGRJhEeEsEtuabgdH7Fz6brbEqeN2gnh9OB7/6THnxnRsO7i+QjvSNL1pHJtwzA1WIpxgn7Vb3xst0zEh6G9eM0GSw+Bc/vA0wIP53L2PazTG2Ev8Wjop6SCsRVcahbR19XDsdAQ6WMCp7pcRAQUCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nL3KT1SD5+QBSix2hix7cYoptDSWF5/XQfJQkOiUMaQ=; b=DYc/IVwjb48/ru27GJLPBRHtOH0HquJi1hpBGbe91tzhLxLggIpNOW0V3mC9hRQWbw0zr4QJB25WnxIpaKvSuiv2RumFUXWQtX/Pd/whmcPyY8s5DBGuBMCt64wED0D6+I4LRGHnRAbZRZSatEsaL/fNMjJ6BcEEndRVRc0SjBEbnpMDXmyLZCwMxtumg/mtFjWfBoUMnD6AqtjaQ8UdSkqUE0jYJroqhSl5BqCM+Ze+3BO1bXzr4qwO4kLerbWwBhtkWlG8OcsbYDyygAh8ClEUwERHyM6G3JHKOP07j9QDurcwj1iQWAewRH7fuzRBLQ92e9GVCKHF0S0SAVPtHw== 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=nL3KT1SD5+QBSix2hix7cYoptDSWF5/XQfJQkOiUMaQ=; b=SGM8aIUaLzWMl5RHJmAdhKMBt+lhf7yrCOVWt/DjYReMNd7BcrXFcBWc4C6jB5SHPU6jaW0KXPSQeZ03jBjK+XCgyrmqbi9/bSRc9wwgxo7wnpVEws/Qb4w6MFJ2onk1B5bQCKRP+/bISrU/skjYTJhQlfZgMzckM+1QGH9CYpw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 1 Sep 2025 14:51:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of device tree Content-Language: en-GB To: "Orzel, Michal" , Ayan Kumar Halder , CC: , , , , , References: <20250901123103.11418-1-ayan.kumar.halder@amd.com> <20f5b553-75a6-43b3-9b2f-1cf73b9589c3@amd.com> From: Ayan Kumar Halder In-Reply-To: <20f5b553-75a6-43b3-9b2f-1cf73b9589c3@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF0000449D:EE_|LV3PR12MB9260:EE_ X-MS-Office365-Filtering-Correlation-Id: 6c45d097-d8fd-4e41-0a54-08dde95ea36a 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?M3lxaG4waHVaVlBpd0xxTk1RTXR4eFhSMjlVK2hpZ1VXRDZBWlFNZTFRM29l?= =?utf-8?B?WCtBeWdTczQyUDVtSWVTRFhsWjg3VDFBQ1FiYUhrUzlwalU1Y0ZjdGE4aGEz?= =?utf-8?B?bW94amNCRHg1ZERxVjRiL29UMEpUaHZwTFlpMkNaNGxid0Y3TVB6a3g3YVcy?= =?utf-8?B?RC94K2NGMlNpMEdueWZKUjZZcDQxQXdtOU05dWlwWGNkeWZkREtJUlRqRVNm?= =?utf-8?B?b3d5ZGZ5WE96dnBWTktNcW5LZ3JXL1ZlYzNNNHhlVGlEbHEyUWk3TGoxNHdn?= =?utf-8?B?VER2RTYxdHg3M1FTeEcwRko1RmM2a3FSbDM0RElqNzBNNHptQ0pMMUpJbWc2?= =?utf-8?B?NVhUM2FpbHlwYi9DaFNkdjIrbTJkcTBMZUpIRDJVRWlUMDIrSlNjOVlDUEtN?= =?utf-8?B?OXgxWHRWKzNiOTRRREpPWDNuRWtFajJhaFlqK28rdUJHeDAzZGFiclhWY2dT?= =?utf-8?B?ZWM5dzVvZFJPNGM5YVNwSm9mbzVRSk1kL3hkU2xqZnhWa2VnMDJZNm1XLzdC?= =?utf-8?B?azZhQUMzYXpJc3V5ZkV2S2ZUV2ZDeHAzZlZJYzVRZU9QUlpCeUxqYmxhcnp2?= =?utf-8?B?S0p1YWJwRXVOMGxhTnliQnU3UXpoMnNTMmtuUmRydjBZSTU0UjB2NE9PR2dw?= =?utf-8?B?WFFaSnB1QmNSbUFLYVVDRjJST0dpQy9PQ2RKamQ1YnUxMHlHUzdBd3ppenlJ?= =?utf-8?B?ZTQvanJVWXBDdk05ZXgwc0prSll5TER2c1lWMXIrWk1nY3BZck9JSWd4TjBJ?= =?utf-8?B?YXp1R0RscDJRNmk0MXpUL1JTVm41VzgvM0RlaGNPZUZpd082NVdDSFpWV0dO?= =?utf-8?B?M2JUdGZ3UTNvbnlCUSs4OERzM0ZkTUhNVndOeE53UDJQandOMU9xZEl4TnU2?= =?utf-8?B?ekl1bTNLQXRnVkVEVG9YRlc4M1ZNNmZJZXhiQjg0R1FsUmhyUElmODRrSGFy?= =?utf-8?B?Vm5jNDliUnM0ZUozOTNFSkhaVEE0dThldDA5M2MzclRrcmNPTEpGanVMN2tB?= =?utf-8?B?dXhtaHJ1a1dXWlFteHp6QTVuUG14ZmdBekZLMWM0WHpiU2Q2Zk5DQ1pJRmls?= =?utf-8?B?NXRLMXpTblROdC9zK2luLzBaTENiaS9FT1QrMStxdDdlcDMyQWhOSFR0bFhD?= =?utf-8?B?NkhXa0gzSzh1Ti9IMWg2aVRrMEZYUEdiRTFkOXVKM0JiUCtzcVFDOFJqOTRT?= =?utf-8?B?TkxRd1RMaGttMjdDZ2lVRVNGZDE0bmNuVTd5S1VVd1VsZ25jL0xFcno5Tno4?= =?utf-8?B?blpBNkwzNmRBbCtaYzkwUnNmcko5Z2hDNVVqWjFydVlZdXJ2WWI2amNZSWRU?= =?utf-8?B?Vi9ucnprYlUwSmsyWWcyZGY4ZE9jYWV3ek40RW1MdTVoeXEvZXRjcDkvYzF0?= =?utf-8?B?ZkJFbUhoK3dLTlVwT2NaUzQyTllwWTVwK0dMNkw4OXVZZk5HWDg5RzRDMk55?= =?utf-8?B?dElZM0s5Y0ptTG1aOFYrcFVvSVQwNm15Vjk4Y1hYSjJoSlZjREx5SXE1SXU5?= =?utf-8?B?NGNqNEUzVWpKZ2piWnZScEVFOGtyb2NqbWwrOWczOVN0ZEg0OXVwWEV1ZUdB?= =?utf-8?B?SXlaY3E1ZWhGWTJ3K3cvdmhsWjQ0eFhTbzM4Z1o2b29JVXMxRm12QTBkdUJX?= =?utf-8?B?aTQwZG4zeEYxSG82ZnU1cW4rTkF3QkVYTDFkUy93c3Q0S3orQVJuQ2RPY081?= =?utf-8?B?WXN0blNoRzJ3dVFYOVhLRFlwTGRXOGh0bFlIWnhZQW9LZkpRZWd1T1c1citY?= =?utf-8?B?M3ZhMDZJbUZrWE40MjJ2QXRHdXRTSXd0NjIzQjVJbUZ0VXFvaWkvR3lOOFpV?= =?utf-8?B?cmlONWZlVnNVTXJKWjJpeWhVTDEwaE1jZHV6bkV2VDRBR0xjWDVkT1JOZW8r?= =?utf-8?B?N2Z0alZMR2F0dzQzd05mbHIyUi9mMmExOGlGdU9LZG5CcWRDcmhaVlRCcm1V?= =?utf-8?B?L1BkOWswMnlzYW5YZGpGVUpJNXVoem1nTXlEZFFRaFphUzVnRnZZZHFFYWZI?= =?utf-8?B?dWJsK3ZlN2FzR1RxeXJySUdKdDNRQUpOaGdUaGEzUjN5RkJ4Y2VLVld1VkdY?= =?utf-8?Q?9Cy1yC?= 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: 01 Sep 2025 13:51:23.3884 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6c45d097-d8fd-4e41-0a54-08dde95ea36a X-MS-Exchange-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: LV3PR12MB9260 Hi Michal, On 01/09/2025 14:17, Orzel, Michal wrote: > > On 01/09/2025 14:31, Ayan Kumar Halder wrote: >> Xen gives a panic if certain nodes are not present in the device tree. In order >> to prevent this panic, scripts/dt_sanity.py is written so that it checks if the >> node/s are present. If the node/s are not present, the script gives an error. >> >> User is expected to run the script against the device tree before booting Xen >> with dtb. > I would expect the script to know what to look for in a passed dtb. Otherwise > it's just a script that searches for the list of specified compatibilities by > the user. In other words, a simple grep would also do the job. I agree. The main idea is to check that a dt node with 'compatible="arm,gic-v3"' property is present. We can enhance the script as we go forward. > Compatibility is > not everything, there are other things that would prevent Xen from booting. Agreed. The rationale here is to shift the responsibility to the system integrator to run some validation so that Xen does not catch these errors. We wish to provide some sample tools to achieve this aim. Another category of errors are the unsupported register configurations. For eg gicv3_info.nr_lrs can be supported with a max value of 16. So if we have a baremetal program that user can execute before running Xen, then the user can catch these errors. If we are able to catch these errors outside of Xen, then we can claim such panic() will not be triggered in Xen. There will be certain assumptions to make like .... > Also, often times the dtb is modified by the bootloader before passing control > over to Xen (i.e. it may differ from the base dtb). bootloader is not expected to modify the nodes which are sanitised by the external tool. - Ayan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:52:16 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:52:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104841.1455869 (Exim 4.92) (envelope-from ) id 1ut4xE-00076T-4w; Mon, 01 Sep 2025 13:52:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104841.1455869; Mon, 01 Sep 2025 13: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 1ut4xE-00076M-2I; Mon, 01 Sep 2025 13:52:16 +0000 Received: by outflank-mailman (input) for mailman id 1104841; Mon, 01 Sep 2025 13: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 1ut4xC-0006av-Ve for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:52:15 +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 dcb2c5d3-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:52:13 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB8345.eurprd03.prod.outlook.com (2603:10a6:20b:509::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Mon, 1 Sep 2025 13:52: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%6]) with mapi id 15.20.9052.014; Mon, 1 Sep 2025 13:52:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dcb2c5d3-873a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gUUPJM7SBXDf6RD/2TXkInnuk1J8GM0QUrEHb9SDMAqMDEd1CC7YLxBTRO1SFAS7dpqZW8Ozz8Pt3lUnJm5s3JJegVuB+6cxYP1jsoohbn6x92IFAJnrCcI3EKpJyFMIEH/tVkAkTtPcIFhAPptjFh59/s9/BxZxd/BigL7zPETe2tJtv7lxg2kjCbVo6IjDjT7ILHrAvhppLkhdOfLj1vaWbyt4vjO96Nim7aURdRBL4LTplbm6m6xxjWSFqgf+9Y2X3/+jOngrCS6cgM7mmAMJ4I7KdgIMWvvhXei8TbvEkDLGRAcXEg9FVZEXiNO29Ixwp0TTEC7aFK28KvnVKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vqn8KHmf08y6X1smKB3qqJnD8bCqb7hVgN7Y4e44yUo=; b=crjGLcaqUydpBCxcEsPoIYrV/SlK1apyic5wsHoU99jm1SG4pkQcAhK81F8iJtQ1e9NzRTfjtW1fyQ4lGaEgpiSNmqauqIBLniXNyPs9NEhniRtaIdGXJxDzHpxfTHJVybKqGK9ih540ojlVMtgDcSNUY/NoiX6jMsakClo7TPyd30IeGr0MnfGFAjVoB/Di489R8yM90gt6prKybYU5DoZhxmohVjSc9QMusgrZBRN2KZBePW/4/J4rIzAC32WQO1LHYByW6rNIpKFykeyGzak1t1gTg0GR/HHAYHe3XyDRIUmOT4HrP/WILosnM+i0kVnA5OLTj5x1ROD19Uinvg== 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=Vqn8KHmf08y6X1smKB3qqJnD8bCqb7hVgN7Y4e44yUo=; b=kVpEGIBpKJldd+m9BQl5PoseCZGrsjQFT96/UNgKpPjDJJPgNuyDwwQ/H1a/nGNuei8yigdmyVNLbXOgLIdimHjZmcybeQ136gky+45if+cap8Ir7W7MbeBAr2uhgwTa3pft/Tt1QABA+revwnWbVaiGELsCtlw8uDdrNJoX0Ccyu8Ws+7n76E6qH6WMmqENsgQrvyUTOSfHVfFq3eMglbfUMhoc96Vnipv+mJewqTBv1gGiiYaGucw9N9o7r1Mwrj6tdpNnF0cJqJF2t2ngC6ma2jmLCSRcPBWLJcl8zcSIvWxtMz9TBeW4V3/mnJYr/60wCzRezBzfFexViYMOQQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 2/4] xen/arm: scmi-smc: update to be used under sci subsystem Thread-Topic: [PATCH v7 2/4] xen/arm: scmi-smc: update to be used under sci subsystem Thread-Index: AQHcG0ec/HNOZvfKOkCNWjMavHIF7A== Date: Mon, 1 Sep 2025 13:52:10 +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: PAVPR03MB8946:EE_|AS8PR03MB8345:EE_ x-ms-office365-filtering-correlation-id: 6856b965-041e-427d-6c81-08dde95ebf35 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: =?iso-8859-1?Q?0q8UVWvsO+Wj4ULbLEa8iZh2a8OkG975JhxmXD6KoEkv2K3d87V0+OkZYy?= =?iso-8859-1?Q?C+Lyz0PYOvYmQ9gE573hdWsIp3o5ealOhluUbXT8FjGTHdXkQCffQ9dNps?= =?iso-8859-1?Q?qKHScNvzsxJKm8oj+tROjHVm3o/Nq18ym/p+1EfaP9TPi7HNkaZVQ/NCls?= =?iso-8859-1?Q?NCrlLaRQdUTyf7ZbM2dl5y+4qIsTNIAiF9kqHP8WvMBl4u38uk9R4Q0uY9?= =?iso-8859-1?Q?irPugw+KrqbmxxMMojkZFVdnQVLj2bw4mAOoGKwOm6pjqytLil8x+GgHKW?= =?iso-8859-1?Q?UpP6M7FG3tn1aO4AU3nJmWnpDqXiGK8Jqxsfeip0pkZ/81Boaa0Kxc/fEF?= =?iso-8859-1?Q?J1WdVeBoruIge9KFtXy3x6n1SJ/u7KbANbgLfYuOOUhthSD1sMjotMUgvZ?= =?iso-8859-1?Q?WV1guHE37gts0oJdMByaxH6iQ73Gnf5Pg+Y7PGpBfXicuGagVuFKqB5He0?= =?iso-8859-1?Q?nNrfgpX5RVWlHlMzf/Gh1B2qCxyRiq3KWW8flDdsiQujF2A2yDD+vyLUz4?= =?iso-8859-1?Q?F0pU0xVPF58eWM42jPhBT8/P+YSW1zZc3DSCs2YN0jX9bhnKP7jS2nX2wY?= =?iso-8859-1?Q?TfpeC4tPS9BX+I/1/oaBoBFP1+JDOsw/rPxcK4pR5fnfiNZdYvi+dDttih?= =?iso-8859-1?Q?I6VGPmVnz0jcbuVDuCejW1Vbw7+ZmMd145co3jiWhdnPz8/va7BRU5OgLA?= =?iso-8859-1?Q?hMFl9igdWRj3yi6EpX3tP+YnEPTMZLtD3NxEw79OzwFEzo4xaT3kg9a19B?= =?iso-8859-1?Q?BXdVUSW9zok++5uqVVklpr+FYrnSuSNqfxkGen+W2b0LclfJf2Gmzs872H?= =?iso-8859-1?Q?TbyxNeOk/d2mcc15y8GSCKv4uTSBWqRkEkn2APKHQeqjaauULoL7oFciux?= =?iso-8859-1?Q?5ocjFa1Hk7n5EgynZctqffyUrlNs1hSSYgYB7E7NX6bYwNxn09TXZoScpu?= =?iso-8859-1?Q?1BG0wPxPsZ7Ho3p/N1Wb4tbVwPRRp/EQr9prKNUypVjywER0QcBSr/mwON?= =?iso-8859-1?Q?MxjKPmiHIIP84xpE5G8ULymxlzD2fohm9ItBcrY7HOwlkXDHwdmjmxxG0m?= =?iso-8859-1?Q?SUilZizxO/UEhqBS0bfuxDCXL1mOgNNN8Fp4oxL0Ms0ii13A3zpcK5fhXH?= =?iso-8859-1?Q?Kjo2/yWduupbB0M8R02d5KUPg0bRsi7vvM7KFhqzdk8CU+/K2o9qjD6sr1?= =?iso-8859-1?Q?O0zM2HG8bAH/ERg0YCYLdoZmL7R3WLphZ/2qE2PzG71o9Zjd27D0HDL4HH?= =?iso-8859-1?Q?2rvvGPv35VQDhStzVgJ3G429S8xh6x1vuIaV/I03+kVcioQOw6//SNjJeL?= =?iso-8859-1?Q?8cjMaSy2ZDzbavVUCe62dYCpNmIWc9Wlt+zMpwdAgwHqCiVfYGCATZuUof?= =?iso-8859-1?Q?l/5IIGvzyF/+G8uK2OjMr5bvOQL8p6uDmbD4+Z7M9IJ7slHrqJJ1Q0wJJ7?= =?iso-8859-1?Q?GPNt/lbVpeJ2ClUZjyeEAfy6IWOwgomKN43kbUto0ftbPCDQeoCZLMM/M3?= =?iso-8859-1?Q?t+mR/8qzjaySAtETlOdOHRcc4ifycEy+tIyOJUfYXorw=3D=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: =?iso-8859-1?Q?DGVUU7mP/yBZQ9d8O1gi+xImab4yK2Q4ZLw3yZgid2aRsa0tUkM44dRaCv?= =?iso-8859-1?Q?bodVI3N4vxSCDHOnKvm3myHjCqpN4YD2L0mZKeWiYTmJd7P3lwXap2g3iw?= =?iso-8859-1?Q?AYE3fL1RbcmRWhjoI/eQq4lE9Y1iaPWRQnlfGu9TXKiKlSIn1JVUfVdyYB?= =?iso-8859-1?Q?qO23xbjuVT5GSIm9XeL4eIx6xf3ao7Lza+FqVXNqj7jtQvpXj/f2Bv+qyu?= =?iso-8859-1?Q?hzsoX0Pnt8AbpLBkelXGoiIqdW55cGib2xxQ3FM2gGXQZqrZK1rh50dS9Y?= =?iso-8859-1?Q?/oQPaRuJZdcAU8MfUhQ3erPxlYzF3cr9FZwcv67fcEyagiKS1ht2GXgqI4?= =?iso-8859-1?Q?UohArbdBkK994V+ucyIgX0kvcWPy5qWah+UReqxlMfpQvoUCpKUbLNW9ed?= =?iso-8859-1?Q?0C/1guyK6HkNJcDAth9+zmisEgccE6hz6rMwF3/h4PTgzEH7DCwV4+g2lj?= =?iso-8859-1?Q?1CFXDCTZ5+hjq7G79OTPugyHGkEeLefiMxZHlw8UJaC+EO8THU33NNLuGv?= =?iso-8859-1?Q?w1cTyhUzvQ6sZgUqftsnczEoM3bR1z6hBjcpW/9wMLU22o7Q94R/AvSnNc?= =?iso-8859-1?Q?BDadovgXg/OROJKWCHTLVlSfS1E5voYmOrbuvpX21bI9XnMWRBWo9YAaNs?= =?iso-8859-1?Q?i2HyUJt6afuUb3x+vjQBfSi86RQnJEfeOuG+BEFpF87MzlDvjaWBmEiTqj?= =?iso-8859-1?Q?RXK8eNblwPC++FdbxKYENB9XTmn4qBBJtTw+7JFpQx2vbUcy82b7VXkEbi?= =?iso-8859-1?Q?vBTI7uQQV/fcuuBlYAzIUzkKHsBO5rKcufPK6fTaL8vQVWeyVuKFz6tafM?= =?iso-8859-1?Q?/BrbsitJtotCWisMJfS1VS6DSCA9MtPwgrsG5mvrlc+Bb6iRhdLg0FcpoD?= =?iso-8859-1?Q?uaBvypRMRYLKOZP1+UKngDOtjf0osUZzOcIHeM+YfknaoosMqly/LUaFmh?= =?iso-8859-1?Q?1scWYVHjJ5pmJWtXA/fjQksWkcnSCWRHj+IMhpCaTUcl68MJBDRdB86rrA?= =?iso-8859-1?Q?L9StXcnElVKJrO0XIh6ZtSuvH+0TzGlHDGu2RPjqpLhJCEE4I50+38CH3c?= =?iso-8859-1?Q?TZgE0h6HygdofyaqKWH8gXXToByOwvpgHo+dj215rZ0PKXWno3lcUuDO0g?= =?iso-8859-1?Q?CBGmR1WNTE+Ik0Rq+jtlwMuc0/kaqqkfSZQrrmFchritixmgOfNj8V/fBV?= =?iso-8859-1?Q?+t3H7WT1pqdlu0kAqLip63LseQuv0q6Lz1Gu9cUeB7NcNo7FgamaGGQ9ro?= =?iso-8859-1?Q?ukzrAmsKCj3MhsIpbX1Xx/QPDCBZ8GnHfr7koiw9vNhPJOSNA9NN5mu/Vq?= =?iso-8859-1?Q?M3SyBMIjoj0/aUuCZ+jgCjmEtbL3i3Oaivcj583FvIw3QIamSs1/0lGKwo?= =?iso-8859-1?Q?yAjW8vUkzJL/HRMVwJf4Qn2NiXZmhhXyMfXuET4XLT5XPZXrbgiiz2z9wL?= =?iso-8859-1?Q?bM6xdlgARfl7Wf6MUReSowwgW8lV8Fs0F/n+C1YP19ACHZ6LMnaWGXhUu+?= =?iso-8859-1?Q?Ub5C1dQvv2Fywh0fCQXBKMHU5ZP8nfRGwumwDqBg9ELvCVuRR7/VMorKLq?= =?iso-8859-1?Q?IGJaESFiW5SwTXAO/WI4E1Ex6pLRMdSAuo7nEp+0osr6V4aISujqkaNXMQ?= =?iso-8859-1?Q?rbUu+aAABsdCL/+3erJM43HM6MDBk3l44MH51DPn6Uj7f9KF8MgGpLzg?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6856b965-041e-427d-6c81-08dde95ebf35 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 13:52:10.0448 (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: AMHfP4JH7bQ5iT5SJLIb+i3MXEBVGYrgDIOcHs/VeR2fLeHCzDKIyPwtvwgkJWnCgsp8/jrtdZf1QHiy0n6jVd+zUnj3N3Q2F08w3SA49DY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8345 From: Grygorii Strashko The introduced SCI (System Control Interface) subsystem provides unified interface to integrate in Xen SCI drivers which adds support for ARM firmware (EL3, SCP) based software interfaces (like SCMI) that are used in system management. The SCI subsystem allows to add drivers for different FW interfaces or have different drivers for the same FW interface (for example= , SCMI with different transports). This patch updates SCMI over SMC calls handling layer, introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling layer"), to be SCI driver: - convert to DT device; - convert to SCI Xen interface. There are no functional changes in general, the driver is just adopted to the SCI interface. Signed-off-by: Grygorii Strashko Reviewed-by: Stefano Stabellini --- Changes in v7: - sort headers in scmi-smc.c file Changes in v6: - add R-b tag xen/arch/arm/firmware/Kconfig | 13 ++- xen/arch/arm/firmware/scmi-smc.c | 93 +++++++++++--------- xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 --------- xen/arch/arm/vsmc.c | 3 +- xen/include/public/arch-arm.h | 1 + 5 files changed, 64 insertions(+), 87 deletions(-) delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index fc7918c7fc..bbf88fbb9a 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -8,9 +8,18 @@ config ARM_SCI =20 menu "Firmware Drivers" =20 +choice + prompt "ARM SCI driver type" + default SCMI_SMC + help + Choose which ARM SCI driver to enable. + +config ARM_SCI_NONE + bool "none" + config SCMI_SMC bool "Forward SCMI over SMC calls from hwdom to EL3 firmware" - default y + select ARM_SCI help This option enables basic awareness for SCMI calls using SMC as doorbell mechanism and Shared Memory for transport ("arm,scmi-smc" @@ -18,4 +27,6 @@ config SCMI_SMC firmware node is used to trap and forward corresponding SCMI SMCs to firmware running at EL3, for calls coming from the hardware domain. =20 +endchoice + endmenu diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-= smc.c index 33473c04b1..4c5df714c2 100644 --- a/xen/arch/arm/firmware/scmi-smc.c +++ b/xen/arch/arm/firmware/scmi-smc.c @@ -16,12 +16,12 @@ #include #include =20 +#include +#include #include -#include =20 #define SCMI_SMC_ID_PROP "arm,smc-id" =20 -static bool __ro_after_init scmi_enabled; static uint32_t __ro_after_init scmi_smc_id; =20 /* @@ -41,14 +41,11 @@ static bool scmi_is_valid_smc_id(uint32_t fid) * * Returns true if SMC was handled (regardless of response), false otherwi= se. */ -bool scmi_handle_smc(struct cpu_user_regs *regs) +static bool scmi_handle_smc(struct cpu_user_regs *regs) { uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); struct arm_smccc_res res; =20 - if ( !scmi_enabled ) - return false; - if ( !scmi_is_valid_smc_id(fid) ) return false; =20 @@ -78,49 +75,45 @@ bool scmi_handle_smc(struct cpu_user_regs *regs) return true; } =20 -static int __init scmi_check_smccc_ver(void) +static int scmi_smc_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) { - if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) - { - printk(XENLOG_WARNING - "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); - return -ENOSYS; - } + if ( !is_hardware_domain(d) ) + return 0; =20 + d->arch.sci_enabled =3D true; + printk(XENLOG_DEBUG "SCMI: %pd init\n", d); return 0; } =20 -static int __init scmi_dt_init_smccc(void) +static void scmi_smc_domain_destroy(struct domain *d) { - static const struct dt_device_match scmi_ids[] __initconst =3D - { - /* We only support "arm,scmi-smc" binding for now */ - DT_MATCH_COMPATIBLE("arm,scmi-smc"), - { /* sentinel */ }, - }; - const struct dt_device_node *scmi_node; - int ret; + if ( !is_hardware_domain(d) ) + return; =20 - /* If no SCMI firmware node found, fail silently as it's not mandatory= */ - scmi_node =3D dt_find_matching_node(NULL, scmi_ids); - if ( !scmi_node ) - return -EOPNOTSUPP; + printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d); +} =20 - ret =3D dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id= ); - if ( !ret ) +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) { - printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod= e\n", - SCMI_SMC_ID_PROP, scmi_node->full_name); - return -ENOENT; + printk(XENLOG_WARNING + "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; } =20 - scmi_enabled =3D true; - return 0; } =20 +static const struct sci_mediator_ops scmi_smc_ops =3D { + .handle_call =3D scmi_handle_smc, + .domain_init =3D scmi_smc_domain_init, + .domain_destroy =3D scmi_smc_domain_destroy, +}; + /* Initialize the SCMI layer based on SMCs and Device-tree */ -static int __init scmi_init(void) +static int __init scmi_dom0_init(struct dt_device_node *dev, const void *d= ata) { int ret; =20 @@ -134,22 +127,36 @@ static int __init scmi_init(void) if ( ret ) return ret; =20 - ret =3D scmi_dt_init_smccc(); - if ( ret =3D=3D -EOPNOTSUPP ) - return ret; + ret =3D dt_property_read_u32(dev, SCMI_SMC_ID_PROP, &scmi_smc_id); + if ( !ret ) + { + printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod= e\n", + SCMI_SMC_ID_PROP, dt_node_full_name(dev)); + return -ENOENT; + } + + ret =3D sci_register(&scmi_smc_ops); if ( ret ) - goto err; + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + return ret; + } =20 printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id); =20 return 0; - - err: - printk(XENLOG_ERR "SCMI: Initialization failed (ret =3D %d)\n", ret); - return ret; } =20 -__initcall(scmi_init); +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc, "SCMI SMC DOM0", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_dom0_init, +DT_DEVICE_END =20 /* * Local variables: diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/in= clude/asm/firmware/scmi-smc.h deleted file mode 100644 index 6b1a164a40..0000000000 --- a/xen/arch/arm/include/asm/firmware/scmi-smc.h +++ /dev/null @@ -1,41 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * xen/arch/arm/include/asm/firmware/scmi-smc.h - * - * ARM System Control and Management Interface (SCMI) over SMC - * Generic handling layer - * - * Andrei Cherechesu - * Copyright 2024 NXP - */ - -#ifndef __ASM_SCMI_SMC_H__ -#define __ASM_SCMI_SMC_H__ - -#include - -struct cpu_user_regs; - -#ifdef CONFIG_SCMI_SMC - -bool scmi_handle_smc(struct cpu_user_regs *regs); - -#else - -static inline bool scmi_handle_smc(struct cpu_user_regs *regs) -{ - return false; -} - -#endif /* CONFIG_SCMI_SMC */ - -#endif /* __ASM_SCMI_H__ */ - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c index 4095171533..78d5bdf56f 100644 --- a/xen/arch/arm/vsmc.c +++ b/xen/arch/arm/vsmc.c @@ -21,7 +21,6 @@ #include #include #include -#include =20 /* Number of functions currently supported by Hypervisor Service. */ #define XEN_SMCCC_FUNCTION_COUNT 3 @@ -233,7 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs) if ( platform_smc(regs) ) return true; =20 - return (scmi_handle_smc(regs)) ? true : sci_handle_call(regs); + return sci_handle_call(regs); } =20 /* diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 55eed9992c..095b1a23e3 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -328,6 +328,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); #define XEN_DOMCTL_CONFIG_TEE_FFA 2 =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 =20 struct xen_arch_domainconfig { /* IN/OUT */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:52:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:52:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104842.1455879 (Exim 4.92) (envelope-from ) id 1ut4xG-0007La-Gc; Mon, 01 Sep 2025 13:52:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104842.1455879; Mon, 01 Sep 2025 13:52:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4xG-0007LR-D0; Mon, 01 Sep 2025 13:52:18 +0000 Received: by outflank-mailman (input) for mailman id 1104842; Mon, 01 Sep 2025 13:52: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 1ut4xE-0006av-RG for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:52:17 +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 dde3dcd1-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:52:15 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB8345.eurprd03.prod.outlook.com (2603:10a6:20b:509::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Mon, 1 Sep 2025 13:52: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%6]) with mapi id 15.20.9052.014; Mon, 1 Sep 2025 13:52: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: dde3dcd1-873a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TC2zlMcK+F094JTxi0+3KPIGFRQAkwUNEqJQRqL/XCTQZvx7/ROCn8SKbRYb2vaadmGs0mutPhseOWNLYrsq/9mtsLORvByYArlHi0V62DnzRpSYX5vN43tmxREDbkJZF/jLi+efYasYnPNWoGN9V4QJlp+sSR0KsR/7tEbkkfZdZDwwW0D6l1MMuE5vmyluhStkq5S+2OQH/7pK4/LN/xdgp/LdCePldyqcejcrF0HHnZqDZ/F2RoFOwR9myayoiSa0IDMMOpFdr1MxVDGfaEu6F/YWcDlJbctNSkCao0XudPnQyTfR0LpaQjAgF++RGTqJfcWKcWhs9/7WahLRsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=20T5ISGy8h7E4wQRZxZEgundHszIygrbBdCU0Wjq894=; b=pBBfMrf2Pi+zYe2D5Lda2mZtZbkGfc+gZ35fHi4ZaU0XoUJ5ShGkEbuqQBcl/xDFMpnNlrkz9tvx6V9whF4f024j/ih/oN8FAmkbW2TcnYjVyghdK1zX3CujKPQ1vnwrgwkgk0DIwyiCZk4iPltEYZ/Opknf32+Qw8Gc2ElECi7cJMvQ197UdLechFmcQSnZbZ9C+Vsj15Hmj07+p7PBRsc/D9eRNd/RPOjarKtW6cjgNsCXT2OV6w+3vMr3G/W25/JXHwE5e74nJ+VaBMdOQ+quDMTZeZh+MYUTvBeanc0e5Esfm3VBlKBigc4dZl2JlDwtwHWBvzZ3LoXPMQqtbg== 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=20T5ISGy8h7E4wQRZxZEgundHszIygrbBdCU0Wjq894=; b=rGFBla3hI8pUPypZWpZ8zmyorN2C0sIviCpdAPGalS6cmc84VSy/hVPYtMKf6soJ0Xikkm3Y6t9y5eADonyviczET/dlng9RdmHBhs8zxX5GhAQ9QsxPGc8L4WG8ggSAs1umJUIZ3PAAfb+lkJwwXCh0tK/D0BLMGuIs7lMrD699Ozl3ZHZ+w17TM1p5xuyWZrr0lD6fE8IAn8hNcQUk+YVGkAAzXGtVZZ1o5dhIWyiE6BEBc1ZOQ/ZIoH+ThSIdpOlmESkiKANp9QmJZN4IT9Rd5M7j/p0Y39SoRDBT39i72vy5RUeBXg/WZs8/Y5MTX+FYmcrlsejcT2kFFdOdKw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 1/4] xen/arm: add generic SCI subsystem Thread-Topic: [PATCH v7 1/4] xen/arm: add generic SCI subsystem Thread-Index: AQHcG0ecscQZ4aZyyUGW7Lpq7NOpDA== Date: Mon, 1 Sep 2025 13:52:09 +0000 Message-ID: <04ae6dd2cd4a7e1617a564db5315f293812fcee2.1756734682.git.oleksii_moisieiev@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: PAVPR03MB8946:EE_|AS8PR03MB8345:EE_ x-ms-office365-filtering-correlation-id: 40fd31c0-7c85-4a83-a68f-08dde95ebee8 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: =?iso-8859-1?Q?n4lAt1aVYk55fKdQ+lq5l+Btvr7Yw0/t3687E/BymZ/8FXV7pJf/4LT/E7?= =?iso-8859-1?Q?s96MRR2UU9gYtIr15yd5BcCaeS42LIpPoKNNlBQiuD1q72P4YDP4MKUNbB?= =?iso-8859-1?Q?uH1/VSbGIQGgP+b+e/5EEccKuNthuDfmOmwq5NSSekJgK3BigdNcObkHjC?= =?iso-8859-1?Q?bqv5VqGRpO7yQrZx8MF4ET5JQ+KacU3URhvQERAPfj2dNhUWUsXx0W4UX7?= =?iso-8859-1?Q?gx3tsgbdYzD2bE0TkHZ4pJFpK9SpwKYrByBBMdlok8XIxbp3Tjj4WqpQkN?= =?iso-8859-1?Q?G9GdEI//hsgvOBgTYtlFUD/I4eyQthkhs1z/6l2qv2mLsDlH/EgiXGACXu?= =?iso-8859-1?Q?L8iPHwU5TjPt8TaYMGjlHOuJ25DaX0FuuQJ96vMhcybqPAvhlcMSaXczGu?= =?iso-8859-1?Q?Wu65w9qD4drNLtEhhkKCqVm9lU6wvsVPPFrtLTr0RqAreGt+rcF+SxRSh2?= =?iso-8859-1?Q?Oa0UHe6Hym9iGGGAoHN6G2rVGc1d0lFCiNOnPcq+sYfLbWjYsjBRtOsglW?= =?iso-8859-1?Q?iTBvh7qBuu9bviNFqy+P13182t/C1//CLzJFL7+EuOA69847F0AvkNXNfc?= =?iso-8859-1?Q?Ly300BmUIW0mLq6L6revz0FGP6jy+esFpGcccK5qi1kKhAfTA9CKvkujLt?= =?iso-8859-1?Q?1VUUn0wCz5VVZ0QKOLEEgNrkOrM5YDaEdyAaq5rN0iQEUyKuQgpjjqoeOG?= =?iso-8859-1?Q?bVvTMrQV/zuDsN8wLbd0Q0BcCTCQfFP8pqYcQzppapd0NHrL6JyXLDIUrU?= =?iso-8859-1?Q?fx2gdrr8khSWAI52mN44XgnQmOYHZwnlTLkKpf56OaBAuojIJM0Z0o9sNM?= =?iso-8859-1?Q?kG3sZ4z92RxwHwLpWTTjL/aJzTjI7tY/3RCO1V6sEzQs1d5/GK5c+fWPyg?= =?iso-8859-1?Q?vp+h+YmhrDywZFAyOatBaUQHtTsVvIXYc5gcsKLSzyQus2kupDfRG8Mero?= =?iso-8859-1?Q?4kNo83PvQfZm4kJeUWen9/4TKmfHTFXBMWZ9FEikroYDcAKWJY4m/B4+Kz?= =?iso-8859-1?Q?qBXVGW+k4F53nU17i4GCWUoucmfOB8sXGqCoWYGcW1C5ELm2yID5wcWqNJ?= =?iso-8859-1?Q?piujo6iM0kSpD5Y/rAbp+DJy0k4i0EG1n77A3mW8oXajQ6S9WKCXqw1X/m?= =?iso-8859-1?Q?LMY8wMHS88kU8UxSV9NRJq5F/sDyJFoAeJp5sLFIKNbW6Sy7cdVcm9UA6N?= =?iso-8859-1?Q?6zeIMFR3JnlCINyQLlHai5yOuAgBjrF4uzLv19IiMeoqbybG2FDo6dRb+N?= =?iso-8859-1?Q?8bU29EoE34p8jh6XIg1s8/9iiIMssd4C4kiebQG9sC9qxUTGH19SD/4PfA?= =?iso-8859-1?Q?ST/nK6TrwRILCSIwvLovA/W6W7qQ0tW8G24oATeqOKaZ61kNVr2xGZUVwA?= =?iso-8859-1?Q?n2Dn1hQFNV64+FlktljoQwb/ildZRt4weKpsyH7/nMmXknYeOxssc6P2bu?= =?iso-8859-1?Q?1CJWDFCQt/oITqAA+r58bJ0+BLthf2ibs1XlZlVn4/rbyQl+//IqDHH/t/?= =?iso-8859-1?Q?uxvq3vZCZ9Dc40QSRdJRdifJLEzMfGar2aU8xdGPz8rg=3D=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: =?iso-8859-1?Q?Neqlts2X8j7P1zN+GS6hJ/v6+bJ7ZMm6Ir2ZTPS+xVTUs+t1HwDshdVjsA?= =?iso-8859-1?Q?3hZ2suAmufVdqJMSQcoL15l9g6mtG16iq94L6BTN5OIVSZ0fBGOb3pXd0G?= =?iso-8859-1?Q?k3SJOLKmNnlrN+PVyZ7qMr7kB37l5P+s411e8yc2RJFrptzUVxsrg5BuAE?= =?iso-8859-1?Q?ua14VHC2o+/INK9/fHahQJbtjlHW2RSdBxKSRD81cSvKl6zyPqvOwNXygg?= =?iso-8859-1?Q?7UNQicZHoefe9ek/8iJClU2XU2boPfZtZk1D1buNBH6lwXxiIfhC0Mxb2E?= =?iso-8859-1?Q?s4GQdP5UCK4SFiOz5ab/RN7o1/geAf9/9TRnGnMXJlnbByd/f9CTaV4hGw?= =?iso-8859-1?Q?Xg7IGTx3pzswlTJQszRVRkxpMdwP7KjiETQPuxnpTTqzlHUrL+1a7zOseV?= =?iso-8859-1?Q?3TEy4VGdWeE5IHbr0SZs1kT1q86tQooBBjsF80QRAur7SfHhaUXWfv/uMt?= =?iso-8859-1?Q?ONJZjgQm9LqHi1bedyntv59C3hYBc8sh20G0x8gmAyL9Z/bf0j3ciIugm5?= =?iso-8859-1?Q?1oEm/BnG0/hifVTTQO6FeRmb/EElJZ8ydEu6wUSlyQkgJeG2Z/58+bqzHv?= =?iso-8859-1?Q?b3YF4OCXdHY9lNffJIqZ2a0wbkC+qiE71jfhlJYoZx8k6LhdxkQgZKfva3?= =?iso-8859-1?Q?ExjppMqGBGvxWS5UnV408/GizOjjxc5rCcjh9qRuVOHvGhRZTozSDUlKG7?= =?iso-8859-1?Q?2NH55lmXazYQaXcWrEaaUhEV6q32ffr13DSfZgs1byyvuosGA0GHRDmbeW?= =?iso-8859-1?Q?uQXYA2hSgW/a+2wKtR57UXBFNIo0F7mmsQtEBhAlB40EAxuMawNH12mMED?= =?iso-8859-1?Q?iUf2mn11ktlKZurpR+tb6flLBB6fJ8bMbPyvv5T+GdfZa++lhoVJqnYEcM?= =?iso-8859-1?Q?gDyMIlFmm5LX5xUI5oE/99FWfI4cuLJnqVta+GuWMdfqS1tNUQ8ykYQLEM?= =?iso-8859-1?Q?LScT7sjXwihDuHHHS3GTTu7qVtSo4SShOWCvvSF3wgUXyxqHNZDq4lU78Q?= =?iso-8859-1?Q?zeQ3caQjGYp2LG5tKKGmVDqVnZGQQh09UVtjsWhGvAGGDjTpTZSvoCxp/f?= =?iso-8859-1?Q?H3Cuy/bOZ6lgLKcn3LxqIk9LQKYKardStKxREPSDXoRkPkkdUrvSxkZ1A5?= =?iso-8859-1?Q?eAWr0aXB754j1HgCJiJtRU1M4r2KKrZy3zTsKVi4lHjprzYNZOVB7emTRD?= =?iso-8859-1?Q?vv41OTGu2Ry5Q7KbwMH48xZYh0XN+FiHl2or7RyhdofwOHDJC2xP9Z9B58?= =?iso-8859-1?Q?opOTb7GQ0Mzql3RCxY4JCgqHS10t1FKawA+aBAMUHoE+TnWMS6iomasJjv?= =?iso-8859-1?Q?Guw347Kep6MrSdjXk3j+1GAnc/DN2FhAkt8feRmHzGuulpJWt+lHir9oFG?= =?iso-8859-1?Q?1OJ0RmWJ7JY72yx8+aDaYaV18X5NhO7LmQUWKargILsLYfSHGXvIkNsOAQ?= =?iso-8859-1?Q?nQXYn7/nz3KO+f9HDB4n1yb06pCyzrxaoSWtIZk2nX5K/DbY/0kZ43hedd?= =?iso-8859-1?Q?PZgSeznM5a0xaZ5qWYxEvNxAPf79Cq+hm9hBYTxXahMLbo5g1kC1/EGCl8?= =?iso-8859-1?Q?y7t0ZF9aFPi3vvAGwX1U0qdOVRNtifcGG9do1r8JwU8t6TXk0eGCCk0lGT?= =?iso-8859-1?Q?FtcO2gHUjRYj77X9FwGdjdhobtKheTTF4Bl3ndAmdybsYW8WiYBpZzjA?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40fd31c0-7c85-4a83-a68f-08dde95ebee8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 13:52:09.5067 (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: LyGGFpleyHScvKByd/KgRhpMGroE+m/MhWb6jwfy1Pffr5lkw2MsSgqN7AVdRNOYMHfSDWJZdn4IrNP0I9A6CIFJjPD8qQMAmEMcms+1gTU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8345 This patch adds the basic framework for ARM SCI mediator. SCI is System Control Interface, which is designed to redirect requests from the Domains to ARM specific Firmware (for example SCMI). This will allow the devices, passed-through to the different Domains, to access to the System resources (such as clocks/resets etc) by sending requests to the firmware. ARM SCI subsystem allows to implement different SCI drivers to handle specific ARM firmware interfaces (like ARM SCMI) and mediate requests -between the Domains and the Firmware. Also it allows SCI drivers to perfor= m proper action during Domain creation/destruction which is vital for handling use cases like Domain reboot. This patch introduces new DEVICE_FIRMWARE device subclass for probing SCI drivers basing on device tree, SCI drivers register itself with DT_DEVICE_START/END macro. On init - the SCI drivers should register its SCI ops with sci_register(). Only one SCI driver can be supported. At run-time, the following SCI API calls are introduced: - sci_domain_sanitise_config() called from arch_sanitise_domain_config() - sci_domain_init() called from arch_domain_create() - sci_relinquish_resources() called from domain_relinquish_resources() - sci_domain_destroy() called from arch_domain_destroy() - sci_handle_call() called from vsmccc_handle_call() - sci_dt_handle_node() - sci_dt_finalize() called from handle_node() (Dom0 DT) Signed-off-by: Oleksii Moisieiev Signed-off-by: Grygorii Strashko Reviewed-by: Stefano Stabellini --- Changes in v7: - fix sci_handl_call to make changes more readable - fix build error when DOM0LESS_BUILD is disabled (removed arch_handle_passthrough_prop from the header) - sort headers in alphabetical order in sci.h Changes in v6: - rebase on top of the latest master - fix return value of sci_dt_finalize() call Changes in v5: - update Maintainers file. Set role as a Reviewer - rebased on the latest master branch - Introduce arch_handle_passthrough_prop call to handle arm specific nodes Changes in v4: - fix SPDX-License - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE - move XEN_DOMCTL_assign_device code in separate patch - Add documentation for SCI SCMI drivers MAINTAINERS | 6 + xen/arch/arm/device.c | 5 + xen/arch/arm/dom0less-build.c | 8 + xen/arch/arm/domain.c | 12 +- xen/arch/arm/domain_build.c | 8 + xen/arch/arm/firmware/Kconfig | 8 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/sci.c | 154 ++++++++++++++++++ xen/arch/arm/include/asm/domain.h | 5 + xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++++++++ xen/arch/arm/vsmc.c | 3 +- xen/common/device-tree/dom0less-build.c | 4 + xen/include/asm-generic/device.h | 1 + xen/include/public/arch-arm.h | 4 + xen/include/xen/dom0less-build.h | 3 + 15 files changed, 420 insertions(+), 2 deletions(-) create mode 100644 xen/arch/arm/firmware/sci.c create mode 100644 xen/arch/arm/include/asm/firmware/sci.h diff --git a/MAINTAINERS b/MAINTAINERS index c4886c1159..31dbba54bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -509,6 +509,12 @@ R: George Dunlap S: Supported F: xen/common/sched/ =20 +SCI MEDIATORS +R: Oleksii Moisieiev +S: Supported +F: xen/arch/arm/firmware/sci.c +F: xen/arch/arm/include/asm/firmware/sci.h + SEABIOS UPSTREAM M: Wei Liu S: Supported diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c index 11523750ae..74b54cad34 100644 --- a/xen/arch/arm/device.c +++ b/xen/arch/arm/device.c @@ -13,6 +13,7 @@ #include #include =20 +#include #include =20 int map_irq_to_domain(struct domain *d, unsigned int irq, @@ -303,6 +304,10 @@ int handle_device(struct domain *d, struct dt_device_n= ode *dev, p2m_type_t p2mt, return res; } } + + res =3D sci_assign_dt_device(d, dev); + if ( res ) + return res; } =20 res =3D map_device_irqs_to_domain(d, dev, own_device, irq_ranges); diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index c8d07213e2..0094cf9e40 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -22,6 +22,7 @@ =20 #include #include +#include #include #include =20 @@ -272,6 +273,12 @@ int __init init_vuart(struct domain *d, struct kernel_= info *kinfo, return rc; } =20 +int __init arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node) +{ + return sci_assign_dt_device(kinfo->bd.d, node); +} + int __init arch_parse_dom0less_node(struct dt_device_node *node, struct boot_domain *bd) { @@ -281,6 +288,7 @@ int __init arch_parse_dom0less_node(struct dt_device_no= de *node, =20 d_cfg->arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; =20 if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) { diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 863ae18157..1a8585d02b 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -699,7 +700,7 @@ int arch_sanitise_domain_config(struct xen_domctl_creat= edomain *config) return -EINVAL; } =20 - return 0; + return sci_domain_sanitise_config(config); } =20 int arch_domain_create(struct domain *d, @@ -791,6 +792,9 @@ int arch_domain_create(struct domain *d, d->arch.sve_vl =3D config->arch.sve_vl; #endif =20 + if ( (rc =3D sci_domain_init(d, config)) !=3D 0 ) + goto fail; + return 0; =20 fail: @@ -851,6 +855,7 @@ void arch_domain_destroy(struct domain *d) domain_vgic_free(d); domain_vuart_free(d); free_xenheap_page(d->shared_info); + sci_domain_destroy(d); #ifdef CONFIG_ACPI free_xenheap_pages(d->arch.efi_acpi_table, get_order_from_bytes(d->arch.efi_acpi_len)); @@ -1044,6 +1049,7 @@ enum { PROG_p2m_root, PROG_p2m, PROG_p2m_pool, + PROG_sci, PROG_done, }; =20 @@ -1103,6 +1109,10 @@ int domain_relinquish_resources(struct domain *d) ret =3D relinquish_p2m_mapping(d); if ( ret ) return ret; + PROGRESS(sci): + ret =3D sci_relinquish_resources(d); + if ( ret ) + return ret; =20 PROGRESS(p2m_root): /* diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index a9e4153e3c..039aa71439 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -1640,6 +1641,9 @@ static int __init handle_node(struct domain *d, struc= t kernel_info *kinfo, return 0; } =20 + if ( sci_dt_handle_node(d, node) ) + return 0; + /* * The vGIC does not support routing hardware PPIs to guest. So * we need to skip any node using PPIs. @@ -1740,6 +1744,10 @@ static int __init handle_node(struct domain *d, stru= ct kernel_info *kinfo, if ( res ) return res; =20 + res =3D sci_dt_finalize(d, kinfo->fdt); + if ( res ) + return res; + /* * Create a second memory node to store the ranges covering * reserved-memory regions. diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 817da745fd..fc7918c7fc 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -1,3 +1,11 @@ +config ARM_SCI + bool + depends on ARM + help + This option enables generic Arm SCI (System Control Interface) mediator= s + support. It allows domains to control system resources via one of + Arm SCI mediators drivers implemented in XEN, like SCMI. + menu "Firmware Drivers" =20 config SCMI_SMC diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index a5e4542666..71bdefc24a 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1 +1,2 @@ +obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c new file mode 100644 index 0000000000..e1522e10e2 --- /dev/null +++ b/xen/arch/arm/firmware/sci.c @@ -0,0 +1,154 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Generic part of the SCI (System Control Interface) subsystem. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include +#include +#include +#include +#include + +#include + +static const struct sci_mediator_ops __read_mostly *cur_mediator; + +int sci_register(const struct sci_mediator_ops *ops) +{ + if ( cur_mediator ) + return -EEXIST; + + if ( !ops->domain_init || !ops->domain_destroy || !ops->handle_call ) + return -EINVAL; + + cur_mediator =3D ops; + + return 0; +}; + +bool sci_handle_call(struct cpu_user_regs *args) +{ + if ( unlikely(!cur_mediator) ) + return false; + + return cur_mediator->handle_call(args); +} + +int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf= ig) +{ + if ( !cur_mediator ) + return 0; + + return cur_mediator->domain_init(d, config); +} + +int sci_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->domain_sanitise_config ) + return 0; + + return cur_mediator->domain_sanitise_config(config); +} + +void sci_domain_destroy(struct domain *d) +{ + if ( !cur_mediator ) + return; + + cur_mediator->domain_destroy(d); +} + +int sci_relinquish_resources(struct domain *d) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->relinquish_resources ) + return 0; + + return cur_mediator->relinquish_resources(d); +} + +bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->dom0_dt_handle_node ) + return 0; + + return cur_mediator->dom0_dt_handle_node(d, node); +} + +int sci_dt_finalize(struct domain *d, void *fdt) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->dom0_dt_finalize ) + return 0; + + return cur_mediator->dom0_dt_finalize(d, fdt); +} + +int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) +{ + struct dt_phandle_args ac_spec; + int index =3D 0; + int ret; + + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->assign_dt_device ) + return 0; + + while ( !dt_parse_phandle_with_args(dev, "access-controllers", + "#access-controller-cells", index, + &ac_spec) ) + { + printk(XENLOG_DEBUG "sci: assign device %s to %pd\n", + dt_node_full_name(dev), d); + + ret =3D cur_mediator->assign_dt_device(d, &ac_spec); + if ( ret ) + return ret; + + index++; + } + + return 0; +} + +static int __init sci_init(void) +{ + struct dt_device_node *np; + unsigned int num_sci =3D 0; + int rc; + + dt_for_each_device_node(dt_host, np) + { + rc =3D device_init(np, DEVICE_FIRMWARE, NULL); + if ( !rc && num_sci ) + { + printk(XENLOG_ERR + "SCMI: Only one SCI controller is supported. found seco= nd %s\n", + np->name); + return -EOPNOTSUPP; + } + else if ( !rc ) + num_sci++; + else if ( rc !=3D -EBADF && rc !=3D -ENODEV ) + return rc; + } + + return 0; +} + +__initcall(sci_init); diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d= omain.h index a3487ca713..af3e168374 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -120,6 +120,11 @@ struct arch_domain #ifdef CONFIG_TEE void *tee; #endif +#ifdef CONFIG_ARM_SCI + bool sci_enabled; + /* ARM SCI driver's specific data */ + void *sci_data; +#endif =20 } __cacheline_aligned; =20 diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include= /asm/firmware/sci.h new file mode 100644 index 0000000000..66c88cec3c --- /dev/null +++ b/xen/arch/arm/include/asm/firmware/sci.h @@ -0,0 +1,200 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Generic ARM SCI (System Control Interface) subsystem. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef __ASM_ARM_SCI_H +#define __ASM_ARM_SCI_H + +#include +#include +#include +#include +#include + +#ifdef CONFIG_ARM_SCI + +struct sci_mediator_ops { + /* + * Called during domain construction. If it is requested to enable + * SCI support, so SCI driver can create own structures for the new do= main + * and inform firmware about new domain (if required). + * Mandatory. + */ + int (*domain_init)(struct domain *d, + struct xen_domctl_createdomain *config); + + /* + * Called during domain construction. The SCI driver uses + * it to sanitize domain SCI configuration parameters. + * Optional. + */ + int (*domain_sanitise_config)(struct xen_domctl_createdomain *config); + + /* + * Called during domain destruction, releases all resources, that + * were allocated for domain. + * Mandatory. + */ + void (*domain_destroy)(struct domain *d); + + /* + * Called during domain destruction to relinquish resources used + * by SCI driver itself and request resources releasing from firmware. + * Optional. + */ + int (*relinquish_resources)(struct domain *d); + + /* SMC/HVC Handle callback */ + bool (*handle_call)(struct cpu_user_regs *regs); + + /* + * Dom0 DT nodes handling callback so SCI driver can detect DT nodes i= t + * need to handle and decide if those nodes need to be provided to Dom= 0. + * Optional. + */ + bool (*dom0_dt_handle_node)(struct domain *d, struct dt_device_node *n= ode); + + /* + * SCI driver callback called at the end of Dom0 DT generation, so + * it can perform steps to modify DT to enable/disable SCI + * functionality for Dom0. + */ + int (*dom0_dt_finalize)(struct domain *d, void *fdt); + + /* + * SCI driver callback called when DT device is passed through to gues= t, + * so SCI driver can enable device access to the domain if SCI FW prov= ides + * Device specific access control functionality. + * Optional. + */ + int (*assign_dt_device)(struct domain *d, struct dt_phandle_args *ac_s= pec); +}; + + +static inline bool sci_domain_is_enabled(struct domain *d) +{ + return d->arch.sci_enabled; +} + +/* + * Register SCI subsystem ops. + * + * Register SCI drivers operation and so enable SCI functionality. + * Only one SCI driver is supported. + */ +int sci_register(const struct sci_mediator_ops *ops); + +/* + * Initialize SCI functionality for domain if configured. + * + * Initialization routine to enable SCI functionality for the domain. + * The SCI configuration data and decision about enabling SCI functionalit= y + * for the domain is SCI driver specific. + */ +int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf= ig); + +/* + * Sanitise domain configuration parameters. + * + */ +int sci_domain_sanitise_config(struct xen_domctl_createdomain *config); + +/* + * Destroy SCI domain instance. + */ +void sci_domain_destroy(struct domain *d); + +/* + * Free resources assigned to the certain domain. + */ +int sci_relinquish_resources(struct domain *d); + +/* + * SMC/HVC Handle callback. + * + * SCI driver acts as SMC/HVC server for the registered domains and + * does redirection of the domain calls to the SCI firmware, + * such as ARM TF-A or similar. + */ +bool sci_handle_call(struct cpu_user_regs *regs); + +/* + * Dom0 DT nodes handling function. + * + * Allows SCI driver to detect DT nodes it need to handle and decide if + * those nodes need to be provided to Dom0. + */ +bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node); + +/* + * Dom0 DT generation finalize. + * + * Called at the end of Dom0 DT generation, so SCI driver can perform step= s + * to modify DT to enable/disable SCI functionality for Dom0. + */ +int sci_dt_finalize(struct domain *d, void *fdt); + +/* + * Assign DT device to domain. + * + * Called when DT device is passed through to guest, so SCI driver can ena= ble + * device access to the domain if SCI FW provides "Device specific access + * control" functionality. + */ +int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev); +#else + +static inline bool sci_domain_is_enabled(struct domain *d) +{ + return false; +} + +static inline int sci_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + return 0; +} + +static inline int +sci_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + return 0; +} + +static inline void sci_domain_destroy(struct domain *d) +{} + +static inline int sci_relinquish_resources(struct domain *d) +{ + return 0; +} + +static inline bool sci_handle_call(struct cpu_user_regs *args) +{ + return false; +} + +static inline bool sci_dt_handle_node(struct domain *d, + struct dt_device_node *node) +{ + return false; +} + +static inline int sci_dt_finalize(struct domain *d, void *fdt) +{ + return 0; +} + +static inline int sci_assign_dt_device(struct domain *d, + struct dt_device_node *dev) +{ + return 0; +} + +#endif /* CONFIG_ARM_SCI */ + +#endif /* __ASM_ARM_SCI_H */ diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c index 6081f14ed0..4095171533 100644 --- a/xen/arch/arm/vsmc.c +++ b/xen/arch/arm/vsmc.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -232,7 +233,7 @@ static bool handle_sip(struct cpu_user_regs *regs) if ( platform_smc(regs) ) return true; =20 - return scmi_handle_smc(regs); + return (scmi_handle_smc(regs)) ? true : sci_handle_call(regs); } =20 /* diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr= ee/dom0less-build.c index badc227031..aaa5e9b22c 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -228,6 +228,10 @@ static int __init handle_passthrough_prop(struct kerne= l_info *kinfo, if ( res < 0 ) return res; =20 + res =3D arch_handle_passthrough_prop(kinfo, node); + if ( res ) + return res; + /* If xen_force, we allow assignment of devices without IOMMU protecti= on. */ if ( xen_force && !dt_device_is_protected(node) ) return 0; diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/dev= ice.h index 3bd97e33c5..cb13f7faea 100644 --- a/xen/include/asm-generic/device.h +++ b/xen/include/asm-generic/device.h @@ -18,6 +18,7 @@ enum device_class DEVICE_IOMMU, DEVICE_INTERRUPT_CONTROLLER, DEVICE_PCI_HOSTBRIDGE, + DEVICE_FIRMWARE, /* Use for error */ DEVICE_UNKNOWN, }; diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 24840eeaa6..55eed9992c 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -327,6 +327,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); #define XEN_DOMCTL_CONFIG_TEE_OPTEE 1 #define XEN_DOMCTL_CONFIG_TEE_FFA 2 =20 +#define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 + struct xen_arch_domainconfig { /* IN/OUT */ uint8_t gic_version; @@ -350,6 +352,8 @@ struct xen_arch_domainconfig { * */ uint32_t clock_frequency; + /* IN */ + uint8_t arm_sci_type; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-bu= ild.h index 408859e325..faaf660424 100644 --- a/xen/include/xen/dom0less-build.h +++ b/xen/include/xen/dom0less-build.h @@ -62,6 +62,9 @@ void set_domain_type(struct domain *d, struct kernel_info= *kinfo); int init_intc_phandle(struct kernel_info *kinfo, const char *name, const int node_next, const void *pfdt); =20 +int arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node); + #else /* !CONFIG_DOM0LESS_BOOT */ =20 static inline void create_domUs(void) {} --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:52:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:52:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104843.1455889 (Exim 4.92) (envelope-from ) id 1ut4xH-0007bB-TB; Mon, 01 Sep 2025 13:52:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104843.1455889; Mon, 01 Sep 2025 13:52:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4xH-0007ax-PX; Mon, 01 Sep 2025 13:52:19 +0000 Received: by outflank-mailman (input) for mailman id 1104843; Mon, 01 Sep 2025 13:52:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut4xG-0006av-B2 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:52:18 +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 defd040d-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:52:16 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB8345.eurprd03.prod.outlook.com (2603:10a6:20b:509::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Mon, 1 Sep 2025 13:52: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%6]) with mapi id 15.20.9052.014; Mon, 1 Sep 2025 13:52: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: defd040d-873a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ufV1vh22QzNBZooJmDcZhXw4ltTasjg8jveipCB7H/TdLkd7gqoGv33ZWIizcvTmu82xSPFIx7z3+AiK9HVthDWZAX607h2kAWzdauWVpeXPtxsQhY1u1cMVjx/8WJlrT8dNK6AaZoTeg9ALZU3mZ9AvzmIxW9bVCiSf9aXmy1burh/RMiAl7ykz5dVT/5rF4o0+zDsDXa6MUrBaN22qmjjyZxL0VGi4Fj0BZsLuAn8gvQ9Sz4Yf4gQ45heBwx4RRugljCfkruxDa9sAgY7fW4XQ+tJRDgjQSgmYkzzb+9ZpPAHxe2Kp11aOaEYhSl6kP99Stvo2XfjzBLdv97DEvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3mH/Q+UIe71a21ipIJ6DBTYyhkE/5yqBk24pjbzPWL0=; b=EgFbRRZbeJldyLcmf72PnTy9GSoc19T2UMrzdQoVCSsukGsL76mR2YuutX9A9qzFNVqh4En2/dIY5wJfQVrNo6hq6+vWdr5q3EBeuO3/ZOnx78aAWJ2tZ8dwADKjXAdkXbnporjjYxgJ/vSKA0ODOXkTRAY3TUIxJkSonJvWk3EUEe3tC0aGA6tQU1sey0Lh4XdrPF3xYc2jei1JrJX60JwAhCstl+WT5ct14eqY2yVey3lDwHVHPLU68/P5I9dPofZtbkuVXc8oQ1dULEpjKZLuMKtHOLfLqCdihHH5sWFPNqmbJ6g4qqdK8Q35mDRZ1g8y8YQK/58lQK4EamSlvw== 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=3mH/Q+UIe71a21ipIJ6DBTYyhkE/5yqBk24pjbzPWL0=; b=AiN9hlgv96W7NpvyvLSJ1PuI2lp4xJ6nrJ5DrfxhutDwHH19Ajz5r4vh+PQkVYjbyqRBVSAotvcSBDjBhbE3poEy8fIIKHGaXPkLdzYVv3ZdsqrWL27czAvqUG1YJihBC7E88wKOmr9Qh7CZPAIBXT+OAv25MskucIABvbdHNScFMkTI08n7u4PgLm2cq2U4ArmCD2cnAy2tyJkDamfJdyhipIK40e4oFbvkpfQpznmiuSeEu/yE9GnmMaqYtFnjGnpdAOKZcUA3ACCajSIkPdVgZElwQrIwXN9pT7Dzm1HIV/S5H9ZrdVnMRcA9bfbdj1H6qgm8I2RLlRGnDJQMDg== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support Thread-Topic: [PATCH v7 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support Thread-Index: AQHcG0ebYanbJEa5qUWsxxb4FhV7ug== Date: Mon, 1 Sep 2025 13:52:08 +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: PAVPR03MB8946:EE_|AS8PR03MB8345:EE_ x-ms-office365-filtering-correlation-id: 4f53a574-5e2b-426c-7b6c-08dde95ebe82 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: =?iso-8859-1?Q?pzqLBh44GP13ZjR3r1SR+ZzR/WJKvOJcKQLprBsgnUtdyG2F885d1py8tA?= =?iso-8859-1?Q?FMvQXHjALTXK3aclAm+7oP38YI58s9vgN3+M4XDXj/4Zxi7WAA4Rz4N4eS?= =?iso-8859-1?Q?8298AbCtmL3+jgKafhvGIAjxWwbI/tVIx3OeVaxS09+MXcPfBab1tH4CD2?= =?iso-8859-1?Q?ifeSiCzy4NS9/HoHt/RN66qP/Zhl0SJz3K+seEusAjiImaeJoih1PUvwuz?= =?iso-8859-1?Q?fnKfOZfbMkqiedWIZD6Zdxf5sszUhqvk0zJ3gq20iwxR+v2JAcgdocFyws?= =?iso-8859-1?Q?2hQKZxy/Dvyop5+EMzBunjdQfuzNPF63rdh8ImTqjGhSnZBEh6lQuedkIs?= =?iso-8859-1?Q?tGuan5fY/KYQXqmWZqTLJG4uSQ0rMLpE2Te2Y0thJBHkk2AxokoUXU88ZQ?= =?iso-8859-1?Q?Na4Nt0xGzw3thrlzafNuEh48s2o0ntxNh8Y7f9lDAJHLTmS+rCQb7UWGub?= =?iso-8859-1?Q?Qk5uFYFPWs/cdLwIKn6akVmyxEW2IC1SVVHuSxWeBMPoSuSTB5xlKPGFDO?= =?iso-8859-1?Q?z8cPCuM7GksdCLf7LkwLbMWMTm0Vz+ipmCtDdTvA8WPONiTjLd+yYrO3Cb?= =?iso-8859-1?Q?S63qDOeAUpqUXbJCn093IQ4PNn9zrRlrjf8U8vNiehka8Fs89YOlwBQfaY?= =?iso-8859-1?Q?pU72A15jRZL34G40eau8XRA3H5wrkve4/MPPPTgnMEf7liLBNwXQq1Hbz3?= =?iso-8859-1?Q?W733AUFYOawxMQ+4/cc7LJW4zRiGVV3vlbbjzZY5gg3+zUxJYtgGMSWKE5?= =?iso-8859-1?Q?bPZnzRj7IeeMarueuvCPBihL0I+BFBUhRRKYlrltcoNt47qZOivwQLxROw?= =?iso-8859-1?Q?Xg6tsVu1Ox6j5VhiP6ADePIYViliN1+bBswIhtyfJXwGSaXgfZ7hVnxhsx?= =?iso-8859-1?Q?/KKL67mfHkOMyRzF4e9rT5+Rrd7XAnvpEnXqwV/iHen4rQeOpdRkzcQhvb?= =?iso-8859-1?Q?TcHBlCy5T7GEJPsIcf+LqpkHwdjh8I6CQlA4aQYlebv92oQnpsKiogTeE1?= =?iso-8859-1?Q?5ENOHFqbNvBV7Oic3Ecfq51ApDe8OP1+H9alZKNKQYKTxy8Cj2//fRuJn4?= =?iso-8859-1?Q?yka+wNbr9v5bfoPgf2MCoShDgvtniwWfr+woXE2MIXTOdKeE5phFoaCqDn?= =?iso-8859-1?Q?Y4LwX7gSMw7wiSm97OwExqx80L3Uyk8EJRjaS5w9qM8pKz/imVVvv4s33/?= =?iso-8859-1?Q?4TevXolEPKyhCYnAzgPO4BtjNUY8pfZE5ga1f95yzFmDK7KZHwSlLLqaLO?= =?iso-8859-1?Q?tt27gyC6SAfK+TsYaiMoZ1FGTR25eT3yJ6+XuMHl5D8swhu+dB5XlvHwxn?= =?iso-8859-1?Q?0ZCxBTwgl8902vHwPY76FAuMubUlpjuDhuzWPDLmt3KZRXmKHx8xbeOLdk?= =?iso-8859-1?Q?UrYG8fKhePPp33Pe7yLB69QIq06ja25JRdJzQ5fTap+Tb9mb1CF82o4rN1?= =?iso-8859-1?Q?XwGRE1FOXXtSopH71vpb9ZauwAMj/CSAgG/NN1Jh+Xs8mOCvetBEy9P2V2?= =?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: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: =?iso-8859-1?Q?sydxVOt9hOjDQ94HWJSDe5iRt8Q6CJ/wfAHEW7pE1SoHnaX7ItxvpubtX4?= =?iso-8859-1?Q?1/8seUtZonVeMEAnjt7tmDNXlAUJXTv5/Uy7+Sy3AC13iW5sYtDGebxoqZ?= =?iso-8859-1?Q?65NkSeNEas3bfe6rvS1t9BTQcOiWDpxRxDFtqDlJmKuyWBg5R3k9qLWo23?= =?iso-8859-1?Q?Xf4OsdTwwJe9gSnGCGxL5o5UCsXvIzigDuEJ/qzfuRhk3sNp1A3OfkYCe1?= =?iso-8859-1?Q?8pn4eyhXLuo76fxSUQuZj2C+S43Xb7B7eUUxGRpCJFPDU+JkzsvaGiuq+4?= =?iso-8859-1?Q?svhAl05FEund+Wi6jkZ/wMia4SfncvU4q/+ZLLps86JBfPO9/Wz0cAqAee?= =?iso-8859-1?Q?L0eMqDeH5+5HbJ432N+yD0f4/y69hbEQPsDTCO21UFVRaO6ElOWM+GXjZk?= =?iso-8859-1?Q?niYBJP0iiK+K+fBP65TACR3GbmG2i7YNb4nZfgi3l/+dA0xn5RKdSx757G?= =?iso-8859-1?Q?LzrWg2+Mn2rlsT/hRzyQ/QhCuam11u6CoCiXnl5W+AvFtKhH0kpfOoNzoC?= =?iso-8859-1?Q?yM8X0bJ7AGZwq0bJAjwjGC2mhob3Wl3jqTvAbNUCeVtneFMitGT3tINCzO?= =?iso-8859-1?Q?rzflksUM+oaBj5XKyl7lFypei5KUAM1sZuO1VAzXkeiRvtdom4963sAsOb?= =?iso-8859-1?Q?xKilqQZ6GTkF91dkl4G7ogOOZFFoVWumyziMl5iKbXheeekrTPdStlb+X5?= =?iso-8859-1?Q?5La7A8cEIjeQyhKUPNBpg134FSz2KRx7nasQQaNJA/CkCjkwvz0k4Mtykv?= =?iso-8859-1?Q?B5WsoxUcULxs5ICZRzay/z5avJ4AyQZQN368SmpKAVyD3o8jzVOBppgkkX?= =?iso-8859-1?Q?4oLAPKlX84S4dpE/Jnb9y8rS1KOpF7W5CwgAOsvQjkMdYIPyffHijeDHzM?= =?iso-8859-1?Q?o5zQoRyThYKDt1JMzJyV2gT7H27YrbWRQ6fnmT2eKjy35+lZNB24EOigua?= =?iso-8859-1?Q?ynV9U2WGkxQKzQA41ys3mnYYDRt+pSVBlIvo+ELhXdp/8Dja/A/PGX7vdA?= =?iso-8859-1?Q?3dS/k64sSX8fDZYSRj/FN6ZKRSj65DfFq32LsPe3KoZ2IADFCRf1mrRmrA?= =?iso-8859-1?Q?xdaMD5LhQXCWeJK8Ip23jGg/T3o293AmZIgWLOgkEimavj2dXIbMsUK/DU?= =?iso-8859-1?Q?RQKCm28zUakKRqq6o+ikOOk8bWk+RPIII3lRcMzS9ZmAMOyYbNkXRwP7co?= =?iso-8859-1?Q?E/TkAu/tDMUFG0jFEMJlAAF9yLhiqpc5h4sQGfbXSJsGyYeqyihCvdwcnm?= =?iso-8859-1?Q?mft++QsxAJGRs+3lKi8Yckuo9pj3DFAGcnEtgsdi6ZWLIIYt+MRv1bEiBP?= =?iso-8859-1?Q?MDPjhcl9tDYZ1L5Poo0/ZpdONf20hVD0Pt63byfXoP+0l+rm2P9w2WGiaf?= =?iso-8859-1?Q?8vw3p9Ga480Cqsz1wWqoAqEyUf2wJ48WTu7ncmoDfldRec4gDRmLjvAc8F?= =?iso-8859-1?Q?wxy1eob0dzxy+Ezqw9UZFAx8rvFfC7WYLhYol//YNV1+On8qp8LZBNdUjW?= =?iso-8859-1?Q?IdwA/Z8kmLqZckRjhOi+Hc2SfGiNqwpDZIjeLFq+Dji2w8InpbQivBe48V?= =?iso-8859-1?Q?AUPJVoYgVtgF7DUlQwmxQjdFh+RxlslzbL08Pps02W0mPaiT7fUVeToccn?= =?iso-8859-1?Q?GrPP9INEcYnO1JrIumRoLAV1hR14rZJaKlmgtoqhv8jLSLJa2kZlzCXQ?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f53a574-5e2b-426c-7b6c-08dde95ebe82 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 13:52:08.8597 (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: PHpA/HVaDeQqOyB9YYgQfQkSEdD0EJ25vVthiwLv/u5qGz5fDGyneDhL27cTfn+VJ4YArzoIjBJPXznnEl7QJI8ECaTvz7rkPFjGZLyoNSU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8345 Inroducing V7 patch series on top of the Xen version 4.20-rc2 which includes implementation of the SCI SCMI SMC single-agent support. This patch series is the first chunk of the "xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can be found at [0] SCMI-multiagent support will be provided as the followup patch series. [0] https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieie= v@epam.com/ Patch 1 "xen/arm: add generic SCI subsystem" - rebased and refactored - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probin= g instead of custom, linker sections based implementation. - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch dom0 code directly. - RFC changes in XEN_DOMCTL_assign_device OP processing - Introduce arch_handle_passthrough_prop call to handle arm specific nodes Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem" - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add = SCMI over SMC calls handling layer") be used under sci subsystem. - no functional changes in general Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain This is new change which allows passthrough SCMI SMC, single agent interfac= e to guest domain cover use case "thin Dom0 with guest domain, which serves as Driver domain"= . See patch commit message for full description. Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding driver - add documentation section for Simple Arm SCMI over SMC calls forwarding driver. Code can be found at: https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5 [1] RFC v2: http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.ol= eksii_moisieiev@epam.com/ [2] RFC v3: https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927= -1-grygorii_strashko@epam.com SCMI spec: https://developer.arm.com/documentation/den0056/e/?lang=3Den SCMI bindings: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /Documentation/devicetree/bindings/firmware/arm,scmi.yaml https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /Documentation/devicetree/bindings/access-controllers/access-controllers.ya= ml Reference EL3 FW: RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/ Renesas v4h: https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4= x-scmi_upd/ base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21) Changes in v7: - fix sci_handl_call to make changes more readable - fix build error when DOM0LESS_BUILD is disabled (removed arch_handle_passthrough_prop from the header) - sort headers in alphabetical order in sci.h - sort headers in scmi-smc.c file - Fix commit description. - Move scmi-smc-passthrough definition to match alphaberical order - remove unneeded initialization with NULL - changed u64 to uint64_t - Send warning if iomem permit access was failed - fixed typos Changes in v6: - rebase on top of the latest master - fix return value of sci_dt_finalize() call - add R-b tag - added generated helpers and types go files - rename cmdline parameter to scmi-smc-passthrough - fix goto tag in parse_arm_sci_config - add link to the scmi bindings used in the doc - remove mentions about HVC calls from doc - rename cmdline parameter to scmi-smc-passthrough Changes in v5: - update Maintainers file. Set role as a Reviewer - rebased on the latest master branch - Introduce arch_handle_passthrough_prop call to handle arm specific nodes - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough - rename dom0_scmi_smc_passthrough in documentation Changes in v4: - fix SPDX-License - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE - move XEN_DOMCTL_assign_device code in separate patch - Add documentation for SCI SCMI drivers - xl.cfg doc - fix comments from Stefano Stabellini - fix toolstack code as sugested by Anthony PERARD - use MATCH_OPTION() - move arm_sci struct and cfg params in "arch_arm" - add SCMI passthrough for dom0less case Grygorii Strashko (3): xen/arm: scmi-smc: update to be used under sci subsystem xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent docs: arm: add docs for SCMI over SMC calls forwarding driver Oleksii Moisieiev (1): xen/arm: add generic SCI subsystem MAINTAINERS | 6 + .../arm/firmware/arm-scmi.rst | 180 ++++++++++++++++ docs/hypervisor-guide/arm/index.rst | 9 + docs/hypervisor-guide/index.rst | 1 + docs/man/xl.cfg.5.pod.in | 34 +++ docs/misc/arm/device-tree/booting.txt | 15 ++ docs/misc/xen-command-line.pandoc | 9 + tools/golang/xenlight/helpers.gen.go | 41 ++++ tools/golang/xenlight/types.gen.go | 12 ++ tools/include/libxl.h | 5 + tools/libs/light/libxl_arm.c | 14 ++ tools/libs/light/libxl_types.idl | 10 + tools/xl/xl_parse.c | 36 ++++ xen/arch/arm/device.c | 5 + xen/arch/arm/dom0less-build.c | 40 ++++ xen/arch/arm/domain.c | 12 +- xen/arch/arm/domain_build.c | 8 + xen/arch/arm/firmware/Kconfig | 25 ++- xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/sci.c | 154 ++++++++++++++ xen/arch/arm/firmware/scmi-smc.c | 194 +++++++++++++---- xen/arch/arm/include/asm/domain.h | 5 + xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++ xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 ---- xen/arch/arm/vsmc.c | 4 +- xen/common/device-tree/dom0less-build.c | 4 + xen/include/asm-generic/device.h | 1 + xen/include/public/arch-arm.h | 5 + xen/include/xen/dom0less-build.h | 3 + 29 files changed, 989 insertions(+), 85 deletions(-) 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/include/asm/firmware/sci.h delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:52:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:52:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104844.1455899 (Exim 4.92) (envelope-from ) id 1ut4xK-0007re-51; Mon, 01 Sep 2025 13:52:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104844.1455899; Mon, 01 Sep 2025 13:52: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 1ut4xK-0007rP-1w; Mon, 01 Sep 2025 13:52:22 +0000 Received: by outflank-mailman (input) for mailman id 1104844; Mon, 01 Sep 2025 13: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 1ut4xI-0006av-6q for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:52:20 +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 dfe1f3b6-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:52:18 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB8345.eurprd03.prod.outlook.com (2603:10a6:20b:509::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Mon, 1 Sep 2025 13:52: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%6]) with mapi id 15.20.9052.014; Mon, 1 Sep 2025 13:52:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dfe1f3b6-873a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nfb9GFWj1tX9EkdKlOGwaKXNGftUblTU3p2tx7+jF1tG5crXZBrXlsD3biCm3OkKxIc7FrAvFitMK2l8viZ/7QOYDetFDFtnlgbBhqeqVj7YHa2GLX+IBb1M2sVQfnMCzagkw0fL0hSFcdULq/0ZJgx1jYB1Km4DdyZ9xL9D9LSW84v+RovgmxDyYXloT165XUejJeUFU9E78pIJIgmqpNVFnNZCmi8AKZyg9zqUH9vRAw445cxjx/gYrQ5ez/ETr7VOLalGuJGUdc4slSe+j3fxbx0fi3rjfvUeeCByT6+nBKAJ2kfdYWv9vzRjYPo0JLRXP37hY7MYBN9ZYTD0Ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=codE/M9BZfx2wZ1eY5XZLijzGUb3OAHOETTlUuob1no=; b=WbOd7T0pOeDv71vsZhzJsnlNfeF1Wk9tnwjDsjZVLBqFWfPYsMJ2/YZvXgxdpqCf74Vv64tDrh+7AR4nocc4X8M9AdPSyiK8xvsIxbHfGJPSwzDUUFMoNCHHsC0IfjIFvFehZR/hj4/KpTKOTj41WCfoDDAG4bvy4xXfn8AMl2OSdhmRXqhBbMKyS6+myVOml2rnDaiiVdP8p9M442MQ+E1JhfDkfe3vCCA7Wjdca8bzfO1BlEpWAw2WSCILeoCix5iiwwjx7VTrjXBLIHMhB0BDwxfZUOavOkSxYoODE5Zs8WH3z5aNv/rdb5FzQlp0SXqGeb46OXwrTr4F4FHyIQ== 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=codE/M9BZfx2wZ1eY5XZLijzGUb3OAHOETTlUuob1no=; b=BOkwL8X+7QM69SzVa2/2nRk1UYAX+bfL0G4hy3YAxCb+3Gp8N83vDJJWhCf5qYfyVjZvMUbAdapAU+mf9szVms4srNp2DJ+6fyclXnJZpYkezGAWpo5fq62tP7/lBCBfPbE+8IseAqKzT2/4FbaBEgnw+HdyI5Kwpg3n9ou9b171ePiijkFM1iX1HaZjKv6mqEYlSegamGa+vx52Vb8cUyXaXcHRyNieQP6CmnJfyRMsF3Newt+AeDBamwIPrN6W7HOv3Wa1/s4neSz9DrAgsTp8ClUvaWqhn3lyY9PJQx8CgJbYenOFcOguHKc+So6bAcaDv6SIidrElQn2H+TEUw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent Thread-Topic: [PATCH v7 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent Thread-Index: AQHcG0edtrrTJzILaEKKgodM8hUt0w== Date: Mon, 1 Sep 2025 13:52:10 +0000 Message-ID: <712ece45055667a8261956e68ad349fe503b40fe.1756734682.git.oleksii_moisieiev@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: PAVPR03MB8946:EE_|AS8PR03MB8345:EE_ x-ms-office365-filtering-correlation-id: e211ff00-19a7-48aa-d115-08dde95ebf8f 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: =?iso-8859-1?Q?4drwo8RtuJXpao7yvCw3WsSFNx00NVi2n7KyF6o+C1uwLphOf6vTBvJj4N?= =?iso-8859-1?Q?9qMUdt7oHx56X0Pb6BaEJ2BqJJigyAQIxXcijl/UMdHr0WFb6RLxnk2GHh?= =?iso-8859-1?Q?QIWJE8NFQ+ioVnZTA9o9mgCY/T0lXVp7JJp6m19a/UNQ1fJcrpnBBrgqIl?= =?iso-8859-1?Q?eKfA9qEDFXaXxF77rjp+rDMwFLclhSkUQfC3rOLrbgkitTdUsy2x506MQn?= =?iso-8859-1?Q?5zW3myHP2JR07WSSy8REgqUG8cQ7/z1ujulcqiTE69FpwgNu9SoeaB2clY?= =?iso-8859-1?Q?4syU7zeZO+kZbHYbEYKQ7vZgv5IhmFgDpJ1JV76SGHQZbSEwPV+ZxMFXhe?= =?iso-8859-1?Q?OOM3p59Ckhu/ZPhux8wTIDmRdTC6STgygfRlXvp95zhXoxqV1awFsOuvjR?= =?iso-8859-1?Q?PZpDGqCqnw2XHEL/j4eU+lgn66IohBdP9B+fXUv0+jtZxDwt6KCR2XaXlG?= =?iso-8859-1?Q?U/ZQS3zAXfL+yjNBBs4QRSYhEQr9xIhbsV5SdfNfgJsKJBJGwGxcX1qecK?= =?iso-8859-1?Q?a5JVnqe2Bx4HlISQ3govBH3neZCmkB0DTYvd0TUzvWgoLvmiy6i+BUA+Yu?= =?iso-8859-1?Q?8DllMz4cDuH9RVH6oegrnkwUT38OG3GCnKzym59uLuA593VNIdn/3blu9+?= =?iso-8859-1?Q?wx0FTQ7gahvn60K4lwQyRuzgPXS+OHVp4+mIwOnRyjBaacEIYg0VdHZosg?= =?iso-8859-1?Q?y9y9i3rBBa7SXxrGUwuvGk6ZNA8RI3JQW2nAGIKmyANrSCTLmPS4RIoRau?= =?iso-8859-1?Q?26O8v4Uyr+OKuB556JV8zumYpTG6endyOGM082qVpwkUcneRosTV64D4Hq?= =?iso-8859-1?Q?Zf3NYzUTtaPpscXyCmG85AVno5QKu7l8U0tFdT8uSAxZ4Azv4yBPgBpQkS?= =?iso-8859-1?Q?Z/KHlrocOIH8ukT7ijcjSlX9AyiRka2cg1hj1p2tlLxPd6i0DLNZ1WAeYG?= =?iso-8859-1?Q?BFTMDb8AB6arLK0kLDqCfVeXbgYaiJFT2DJWGmtcWggneacIMAh6jseMuZ?= =?iso-8859-1?Q?MH0VFPCW/MP1wCngiMN58PmTNBiKV1kjXOxODTZRYHsqyPrvzUHovDD9qM?= =?iso-8859-1?Q?yHjST+E5Da8FswgMxfhVDkrMOwE3dfYe0/gw+ZwEYSSO4l9PeNzpX/MPKf?= =?iso-8859-1?Q?tazjdRHKUq2xeFVjybO9QnlN4/4FMqj5DbNxryHX4Y6kmp4AsHwXvyH6qN?= =?iso-8859-1?Q?uLZAhaJf7f5dJeoOmnfwmXtCUxuC76xS3/PDJXg0UvfSjrOzJghwsE5hbd?= =?iso-8859-1?Q?ylj8VnNFOTOiL0A8nDtbq5LrGx7vwC7gJqKrRsXfaoxNfElKdZoCyD/BIA?= =?iso-8859-1?Q?9OFn7xiYaDe3XGubKvMVq5nBNUpjfpyWCJ6148CHx10Do4QfYpaxLTAuRz?= =?iso-8859-1?Q?8UnFdNZbYaRkM2Bi2tZRpl/cv36mr8M/Els8EzFiMf82iSjSwX2lbYS89C?= =?iso-8859-1?Q?Ag8/jmJ5qTDRISog/AvutPB008xzSy3+0U/21kAb9Y5X1D7v6yzeNgac/Z?= =?iso-8859-1?Q?nuexQ+0T74C0fBmDmd9IvK9+TQLgFcyUuG/WD6jrZLgQ=3D=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: =?iso-8859-1?Q?FnFKvPXjySx5GsiBiEZuOakZj9jAXXAgOX+h6dKHSQY1xbF2ZcfRpajXjg?= =?iso-8859-1?Q?oa41sGSQakNdj3ZnfX32g+sQM/mc0gRUy2bi2sDRfvHCVv5JON02HnYMV3?= =?iso-8859-1?Q?B3h2dwTlNIgLG9AEbj/CLTA6b73vrfbtLKCTPWCmezm/ivnKoGxjOSsHs/?= =?iso-8859-1?Q?KiU3G8uTe71VnYnTPy15ZX+bzc5Eun5+/12ht/egQm6NGLuMsC5BPTR4Vu?= =?iso-8859-1?Q?qAsqcynQyR7GR20ZQf1pwHmHklipf+Wvh8GjW4Zl+exkGNzyyrEGhXOvsX?= =?iso-8859-1?Q?ywSvggdRAxrKl/gwgRp+u7SjGZr8iNMNyGpFmJXKvab8KQAXb2kj3GTnEF?= =?iso-8859-1?Q?rh7u5lsF2SCc7z1Pd5em2IBLCCvQ9dTOFfyahNFxqGnEOQZa5yVvZnFwMR?= =?iso-8859-1?Q?rkIGUqxTZ2S5suonFQEc8NAfQkcqb2+4Lieyx0vABRJjR6kGf22mM5//vW?= =?iso-8859-1?Q?BsMi/LsnGmBdE8WHxjdq+m2JbzmuPw87ooCyY3LWINAftESMNtfXwGlHeU?= =?iso-8859-1?Q?FLCTp3Vnpz44hL2gnwFAShExU9YWrxcC2a4KlYdzRfee/xj7fSY9JrSzbI?= =?iso-8859-1?Q?FBkdYS0CrcWPDNAp7t/2PLfNWPeVnW3AJfQ5kJlLoHgR69g7ckiz4x7Lal?= =?iso-8859-1?Q?61eEpAYnmqAEd3E/fs4iZkbeNcRG1b7sk/ntkNsRUW01VZK1wcTCiKxxMm?= =?iso-8859-1?Q?ATLtrU3SyAI7bdcDRvECM5PFYvc0WQTy4jEwwvm09YCzxhbMVE7OU34LgU?= =?iso-8859-1?Q?8uVQSI1WwhxV0ep/jrzCSOOg9DMDDQHTs6uBnFhlCtXfwpQeoNyToM6b6i?= =?iso-8859-1?Q?chl8o8qGYxCZ5J8xFdZVl6uwWxPCptIwxvpo8bH9MnWy5/ZkYsB+BuNEV5?= =?iso-8859-1?Q?ywc6QcQzoUzfRccJ4Cyf3RYmmLkaB+PCiuyJ6rVsLJlFiH/WnderMc/KHL?= =?iso-8859-1?Q?ZA+N3RC322tB5SVqK8B5LwS5Ic1696wNK3HtO1kD4Ge7r/B9DkUnDn/UDL?= =?iso-8859-1?Q?DEg0YYO4TqM7GOJqHulgEvkKOltojmkHdv+/vJUz4CCUKph1TVaDKXTju/?= =?iso-8859-1?Q?OvDJ1T1iqhi18VkL0ebb8Xn6g8EJJNfRoafJ2tUUM1J43RIpPNMPFebA7v?= =?iso-8859-1?Q?cw0mWiycTkZX7C4UPtuXcFEShY7FczOmQjEHj85EOeN/gHDeY4+jeh4E80?= =?iso-8859-1?Q?myR0fg0k+BbHzTRM9MZ7qI+kksmSzA/jYT5001mh7yzV0jU/BxXErKAtUP?= =?iso-8859-1?Q?2kQyNj5oJmvLcrTXX3Bp1L1thWMmDuSxG0u6/86AUz0hVujZKYkybtefDl?= =?iso-8859-1?Q?MRCdmXD8ENd3zOA2ByZ6H9YZE23eDdFp8MTU4/fHEpMYXKdFnScO5O9t9g?= =?iso-8859-1?Q?DSEKf6XKb4AcExnDp9HbSrnyJDUlUXrAHoCEYbCsdg2cJo2fyi9FRK4CAC?= =?iso-8859-1?Q?BeszGz408GOLY6yo5mzkbjm2pMo8tKth6M5afGeDizQbdgFNM2Y2zJxO8U?= =?iso-8859-1?Q?H1EbYsJk8UBFK3Oa+rla1YYjmoazrgt/uQDcFiNFSKlDCedssZ5Qlod9P2?= =?iso-8859-1?Q?Xk5G3PDyvoXsagzAdOlJTlZCQIVVe2KkEHLXP7OBLyIRyHgvZGr4oX6qtY?= =?iso-8859-1?Q?AF8Qykcd0YqZMcN7G2rXFHCGv8FdgDKSrYC96XcsycG4pKv+3IJRyOBA?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e211ff00-19a7-48aa-d115-08dde95ebf8f X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 13:52:10.5795 (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: 6Wvd0kN81I0qWO4jXLFRLlldd+b1qQ+1xcdR0tkzQ3cv1qEBWYqY9XoYT8crSZpJXmjr/0DTh4sn9838Mn6A/DUMaDNsInbZ6HsT4wl5BIQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8345 From: Grygorii Strashko The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling layer") introduces simple driver which forwards SCMI over SMC calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent support. While it is working gracefully for hwdom/dom0 use case it doesn't cover "thin Dom0 with guest domain, which serves as Driver domain" use-case. In this case HW need to be enable in Driver domain and dom0 is performing only control functions. The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is pretty generic case for the default vendors SDK and new platforms. This patch enables passthrough of SCMI SMC single agent interface to the one guest domain serving as Driver domain. Configure Dom0 to enable SCMI passthrough: - dom0: add scmi-smc-passthrough to the Xen Command Line Enabled SCMI passthrough for guest using toolstack in the following way: - domD: xl.cfg add "arm_sci" option as below arm_sci =3D "type=3Dscmi_smc" - domD: xl.cfg enable access to the "arm,scmi-shmem" iomem =3D [ "47ff0,1@22001", ] - domD: add SCMI nodes to the Driver domain partial device tree as in the below example: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; shmem =3D <&scmi_shm_0>; ... } } } dom0less case configuration: - add "xen,sci_type" property for required DomU ("xen,domain") node xen,sci_type=3D"scmi_smc" - add scmi nodes to the Driver domain partial device tree the same way as above and enable access to the "arm,scmi-shmem" according to dom0less documentation. For example: scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x00 0x22001000 0x00 0x1000>; -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; The SCMI SMC single agent interface can be enabled for one and only one domain. In general, the configuration is similar to any other HW passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option. Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from dom0/hwdom DT when "scmi-smc-passthrough" cmdline parameter was provided. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev Acked-by: Anthony PERARD # tools --- Changes in v7: - Fix commit description. - Move scmi-smc-passthrough definition to match alphaberical order - remove unneeded initialization with NULL - changed u64 to uint64_t - Send warning if iomem permit access was failed Changes in v6: - added generated helpers and types go files - rename cmdline parameter to scmi-smc-passthrough - fix goto tag in parse_arm_sci_config Changes in v5: - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough Changes in v4: - xl.cfg doc - fix comments from Stefano Stabellini - fix toolstack code as sugested by Anthony PERARD - use MATCH_OPTION() - move arm_sci struct and cfg params in "arch_arm" - add SCMI passthrough for dom0less case docs/man/xl.cfg.5.pod.in | 34 ++++++++ docs/misc/arm/device-tree/booting.txt | 15 ++++ docs/misc/xen-command-line.pandoc | 9 ++ tools/golang/xenlight/helpers.gen.go | 41 +++++++++ tools/golang/xenlight/types.gen.go | 12 +++ tools/include/libxl.h | 5 ++ tools/libs/light/libxl_arm.c | 14 ++++ tools/libs/light/libxl_types.idl | 10 +++ tools/xl/xl_parse.c | 36 ++++++++ xen/arch/arm/dom0less-build.c | 34 +++++++- xen/arch/arm/firmware/Kconfig | 4 +- xen/arch/arm/firmware/scmi-smc.c | 115 +++++++++++++++++++++++++- 12 files changed, 324 insertions(+), 5 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index acff45d308..3b18bcc095 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3123,6 +3123,40 @@ writes will be ignored. =20 This option is only implemented for Arm where the default is enabled. =20 +=3Ditem B + +Set ARM_SCI specific options for the guest. ARM SCI is System +Control Protocol allows domain to manage various functions that are provid= ed +by HW platform firmware. + +B is a comma separated list of C settings, +from the following list: + +=3Dover 4 + +=3Ditem B + +Specifies an ARM SCI type for the guest. + +=3Dover 4 + +=3Ditem B + +Don't allow guest to use ARM SCI if present on the platform. This is the +default value. + +=3Ditem B + +Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC calls +forwarding from domain to the EL3 firmware (like Trusted Firmware-A) with = a +single SCMI OSPM agent support. +Should be used together with B Xen command line +option. + +=3Dback + +=3Dback + =3Dback =20 =3Dhead3 x86 diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index 07acc7ba64..977b428608 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -307,6 +307,21 @@ with the following properties: passed through. This option is the default if this property is missing and the user does not provide the device partial device tree for the d= omain. =20 +- xen,sci_type + + A string property specifying an ARM SCI type for the guest. + + - "none" + Don't allow guest to use ARM SCI if present on the platform. This is t= he + default value. + + - "scmi_smc" + Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC c= alls + forwarding from domain to the EL3 firmware (like Trusted Firmware-A) w= ith a + single SCMI OSPM agent support. + Should be used together with scmi-smc-passthrough Xen command line + option. + Under the "xen,domain" compatible node, one or more sub-nodes are present for the DomU kernel and ramdisk. =20 diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line= .pandoc index 4adcd7e762..518e42d965 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2382,6 +2382,15 @@ sockets, &c. This will reduce performance somewhat,= particularly on systems with hyperthreading enabled, but should reduce power by enabling more sockets and cores to go into deeper sleep states. =20 +### scmi-smc-passthrough (ARM) +> `=3D ` + +The option is available when `CONFIG_SCMI_SMC` is compiled in, and allows = to +enable SCMI SMC single agent interface for any, but only one guest domain, +which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom an= d +SCMI nodes removed from Dom0/hwdom device tree. +(for example, thin Dom0 with Driver domain use-case). + ### scrub-domheap > `=3D ` =20 diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/h= elpers.gen.go index 667030cbd7..3937653dab 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -938,6 +938,35 @@ return fmt.Errorf("converting field Vcpus: %v", err) return nil } =20 +// NewArmSci returns an instance of ArmSci initialized with defaults. +func NewArmSci() (*ArmSci, error) { +var ( +x ArmSci +xc C.libxl_arm_sci) + +C.libxl_arm_sci_init(&xc) +defer C.libxl_arm_sci_dispose(&xc) + +if err :=3D x.fromC(&xc); err !=3D nil { +return nil, err } + +return &x, nil} + +func (x *ArmSci) fromC(xc *C.libxl_arm_sci) error { + x.Type =3D ArmSciType(xc._type) + + return nil} + +func (x *ArmSci) toC(xc *C.libxl_arm_sci) (err error){defer func(){ +if err !=3D nil{ +C.libxl_arm_sci_dispose(xc)} +}() + +xc._type =3D C.libxl_arm_sci_type(x.Type) + + return nil + } + // NewRdmReserve returns an instance of RdmReserve initialized with defaul= ts. func NewRdmReserve() (*RdmReserve, error) { var ( @@ -1113,6 +1142,9 @@ x.Kernel =3D C.GoString(xc.kernel) x.Cmdline =3D C.GoString(xc.cmdline) x.Ramdisk =3D C.GoString(xc.ramdisk) x.DeviceTree =3D C.GoString(xc.device_tree) +if err :=3D x.DtPassthroughNodes.fromC(&xc.dt_passthrough_nodes);err !=3D = nil { +return fmt.Errorf("converting field DtPassthroughNodes: %v", err) +} if err :=3D x.Acpi.fromC(&xc.acpi);err !=3D nil { return fmt.Errorf("converting field Acpi: %v", err) } @@ -1163,6 +1195,9 @@ x.ArchArm.GicVersion =3D GicVersion(xc.arch_arm.gic_v= ersion) x.ArchArm.Vuart =3D VuartType(xc.arch_arm.vuart) x.ArchArm.SveVl =3D SveType(xc.arch_arm.sve_vl) x.ArchArm.NrSpis =3D uint32(xc.arch_arm.nr_spis) +if err :=3D x.ArchArm.ArmSci.fromC(&xc.arch_arm.arm_sci);err !=3D nil { +return fmt.Errorf("converting field ArchArm.ArmSci: %v", err) +} if err :=3D x.ArchX86.MsrRelaxed.fromC(&xc.arch_x86.msr_relaxed);err !=3D = nil { return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err) } @@ -1489,6 +1524,9 @@ if x.Ramdisk !=3D "" { xc.ramdisk =3D C.CString(x.Ramdisk)} if x.DeviceTree !=3D "" { xc.device_tree =3D C.CString(x.DeviceTree)} +if err :=3D x.DtPassthroughNodes.toC(&xc.dt_passthrough_nodes); err !=3D n= il { +return fmt.Errorf("converting field DtPassthroughNodes: %v", err) +} if err :=3D x.Acpi.toC(&xc.acpi); err !=3D nil { return fmt.Errorf("converting field Acpi: %v", err) } @@ -1699,6 +1737,9 @@ xc.arch_arm.gic_version =3D C.libxl_gic_version(x.Arc= hArm.GicVersion) xc.arch_arm.vuart =3D C.libxl_vuart_type(x.ArchArm.Vuart) xc.arch_arm.sve_vl =3D C.libxl_sve_type(x.ArchArm.SveVl) xc.arch_arm.nr_spis =3D C.uint32_t(x.ArchArm.NrSpis) +if err :=3D x.ArchArm.ArmSci.toC(&xc.arch_arm.arm_sci); err !=3D nil { +return fmt.Errorf("converting field ArchArm.ArmSci: %v", err) +} if err :=3D x.ArchX86.MsrRelaxed.toC(&xc.arch_x86.msr_relaxed); err !=3D n= il { return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err) } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/typ= es.gen.go index e26b3cdfc7..328afe0d94 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -520,6 +520,16 @@ SveType1920 SveType =3D 1920 SveType2048 SveType =3D 2048 ) =20 +type ArmSciType int +const( +ArmSciTypeNone ArmSciType =3D 0 +ArmSciTypeScmiSmc ArmSciType =3D 1 +) + +type ArmSci struct { +Type ArmSciType +} + type RdmReserve struct { Strategy RdmReserveStrategy Policy RdmReservePolicy @@ -582,6 +592,7 @@ Kernel string Cmdline string Ramdisk string DeviceTree string +DtPassthroughNodes StringList Acpi Defbool Bootloader string BootloaderArgs StringList @@ -599,6 +610,7 @@ GicVersion GicVersion Vuart VuartType SveVl SveType NrSpis uint32 +ArmSci ArmSci } ArchX86 struct { MsrRelaxed Defbool diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 185f74d8a8..bc35e412da 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -313,6 +313,11 @@ */ #define LIBXL_HAVE_BUILDINFO_ARCH_NR_SPIS 1 =20 +/* + * libxl_domain_build_info has the arch_arm.sci* fields. + */ +#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 1 + /* * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing * 'soft reset' for domains and there is 'soft_reset' shutdown reason diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index ec258bdc16..e4407d6e3f 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -233,6 +233,20 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, config->arch.sve_vl =3D d_config->b_info.arch_arm.sve_vl / 128U; } =20 + switch (d_config->b_info.arch_arm.arm_sci.type) { + case LIBXL_ARM_SCI_TYPE_NONE: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; + break; + default: + LOG(ERROR, "Unknown ARM_SCI type %d", + d_config->b_info.arch_arm.arm_sci.type); + return ERROR_FAIL; + } + LOG(DEBUG, " - SCI type=3D%u", config->arch.arm_sci_type); + return 0; } =20 diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index faef3d63a1..c8e3f77947 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -551,6 +551,15 @@ libxl_sve_type =3D Enumeration("sve_type", [ (2048, "2048") ], init_val =3D "LIBXL_SVE_TYPE_DISABLED") =20 +libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ + (0, "none"), + (1, "scmi_smc") + ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") + +libxl_arm_sci =3D Struct("arm_sci", [ + ("type", libxl_arm_sci_type), + ]) + libxl_rdm_reserve =3D Struct("rdm_reserve", [ ("strategy", libxl_rdm_reserve_strategy), ("policy", libxl_rdm_reserve_policy), @@ -726,6 +735,7 @@ libxl_domain_build_info =3D Struct("domain_build_info",= [ ("vuart", libxl_vuart_type), ("sve_vl", libxl_sve_type), ("nr_spis", uint32, {'init_val': 'LIBXL_NR_= SPIS_DEFAULT'}), + ("arm_sci", libxl_arm_sci), ])), ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool), ])), diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 61660a02da..1cc41f1bff 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1284,6 +1284,36 @@ out: if (rc) exit(EXIT_FAILURE); } =20 +static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci, + const char *str) +{ + int ret =3D 0; + char *buf2, *ptr; + char *oparg; + + if (NULL =3D=3D (buf2 =3D ptr =3D strdup(str))) + return ERROR_NOMEM; + + ptr =3D strtok(buf2, ","); + while (ptr !=3D NULL) + { + if (MATCH_OPTION("type", ptr, oparg)) { + ret =3D libxl_arm_sci_type_from_string(oparg, &arm_sci->type); + if (ret) { + fprintf(stderr, "Unknown ARM_SCI type: %s\n", oparg); + ret =3D ERROR_INVAL; + goto out; + } + } + + ptr =3D strtok(NULL, ","); + } + +out: + free(buf2); + return ret; +} + void parse_config_data(const char *config_source, const char *config_data, int config_len, @@ -2996,6 +3026,12 @@ skip_usbdev: xlu_cfg_get_defbool(config, "trap_unmapped_accesses", &b_info->trap_unmapped_accesses, 0); =20 + if (!xlu_cfg_get_string(config, "arm_sci", &buf, 1)) { + if (parse_arm_sci_config(config, &b_info->arch_arm.arm_sci, buf)) = { + exit(EXIT_FAILURE); + } + } + parse_vkb_list(config, d_config); =20 d_config->virtios =3D NULL; diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 0094cf9e40..418657eed0 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -279,6 +279,36 @@ int __init arch_handle_passthrough_prop(struct kernel_= info *kinfo, return sci_assign_dt_device(kinfo->bd.d, node); } =20 +int __init domu_dt_sci_parse(struct dt_device_node *node, + struct xen_domctl_createdomain *d_cfg) +{ + const char *sci_type; + int ret; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + + if ( !IS_ENABLED(CONFIG_ARM_SCI) || + !dt_property_read_bool(node, "xen,sci_type") ) + return 0; + + ret =3D dt_property_read_string(node, "xen,sci_type", &sci_type); + if ( ret ) + return ret; + + if ( !strcmp(sci_type, "none") ) + 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 + { + printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , + sci_type, dt_node_name(node)); + return -EINVAL; + } + + return 0; +} + int __init arch_parse_dom0less_node(struct dt_device_node *node, struct boot_domain *bd) { @@ -288,7 +318,9 @@ int __init arch_parse_dom0less_node(struct dt_device_no= de *node, =20 d_cfg->arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; - d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + + if ( domu_dt_sci_parse(node, d_cfg) ) + panic("Error getting SCI configuration\n"); =20 if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) { diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index bbf88fbb9a..5c5f0880c4 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -25,7 +25,9 @@ config SCMI_SMC doorbell mechanism and Shared Memory for transport ("arm,scmi-smc" compatible only). The value of "arm,smc-id" DT property from SCMI firmware node is used to trap and forward corresponding SCMI SMCs - to firmware running at EL3, for calls coming from the hardware domain. + to firmware running at EL3, for calls coming from the hardware domain o= r + driver domain. + Use with EL3 firmware which supports only single SCMI OSPM agent. =20 endchoice =20 diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-= smc.c index 4c5df714c2..0835ddeeec 100644 --- a/xen/arch/arm/firmware/scmi-smc.c +++ b/xen/arch/arm/firmware/scmi-smc.c @@ -13,6 +13,8 @@ #include #include #include +#include +#include #include #include =20 @@ -22,7 +24,11 @@ =20 #define SCMI_SMC_ID_PROP "arm,smc-id" =20 +static bool __ro_after_init opt_scmi_smc_passthrough; +boolean_param("scmi-smc-passthrough", opt_scmi_smc_passthrough); + static uint32_t __ro_after_init scmi_smc_id; +static struct domain __read_mostly *scmi_dom; =20 /* * Check if provided SMC Function Identifier matches the one known by the = SCMI @@ -50,7 +56,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) return false; =20 /* Only the hardware domain should use SCMI calls */ - if ( !is_hardware_domain(current->domain) ) + if ( scmi_dom !=3D current->domain ) { gdprintk(XENLOG_WARNING, "SCMI: Unprivileged access attempt\n"); return false; @@ -75,12 +81,45 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) return true; } =20 +static int +scmi_smc_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= ) + return -EINVAL; + + return 0; +} + static int scmi_smc_domain_init(struct domain *d, struct xen_domctl_createdomain *config) { - if ( !is_hardware_domain(d) ) + /* + * scmi_passthrough is not enabled: + * - proceed only for hw_domain + * - fail if guest domain has SCMI enabled. + */ + if ( !opt_scmi_smc_passthrough && !is_hardware_domain(d) ) + { + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_SC= MI_SMC ) + return -EINVAL; + else + return 0; + } + /* + * scmi_passthrough is enabled: + * - ignore hw_domain + * - proceed only for domain with SCMI enabled. + */ + if ( opt_scmi_smc_passthrough && + (config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE = || + is_hardware_domain(d)) ) return 0; =20 + if ( scmi_dom ) + return -EEXIST; + + scmi_dom =3D d; d->arch.sci_enabled =3D true; printk(XENLOG_DEBUG "SCMI: %pd init\n", d); return 0; @@ -88,12 +127,80 @@ static int scmi_smc_domain_init(struct domain *d, =20 static void scmi_smc_domain_destroy(struct domain *d) { - if ( !is_hardware_domain(d) ) + if ( scmi_dom && scmi_dom !=3D d ) return; =20 + scmi_dom =3D NULL; + d->arch.sci_enabled =3D false; printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d); } =20 +/* + * Handle Dom0 SCMI SMC specific DT nodes + * + * if scmi_smc_passthrough=3Dfalse: + * - Copy SCMI nodes into Dom0 device tree. + * if scmi_smc_passthrough=3Dtrue: + * - skip SCMI nodes from Dom0 DT + * - give dom0 control access to SCMI shmem MMIO, so SCMI can be passed + * through to guest. + */ +static bool scmi_smc_dt_handle_node(struct domain *d, + struct dt_device_node *node) +{ + static const struct dt_device_match shmem_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 */ }, + }; + + /* skip scmi shmem node for dom0 if scmi not enabled */ + if ( dt_match_node(shmem_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk("Skip scmi shmem node\n"); + return true; + } + + /* + * skip scmi node for dom0 if scmi not enabled, but give dom0 control + * access to SCMI shmem + */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + struct dt_device_node *shmem_node; + const __be32 *prop; + uint64_t paddr, size; + int ret; + + /* give dom0 control access to SCMI shmem */ + prop =3D dt_get_property(node, "shmem", NULL); + if ( !prop ) + return true; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( !shmem_node ) + return true; + + ret =3D dt_device_get_address(shmem_node, 0, &paddr, &size); + if ( ret ) + return true; + + ret =3D iomem_permit_access(d, paddr_to_pfn(paddr), + paddr_to_pfn(paddr + size - 1)); + if ( ret ) + printk(XENLOG_WARNING + "SCMI: Failed to give access to SCMI shmem with code:= %d\n", ret); + + dt_dprintk("Skip scmi node\n"); + return true; + } + + return false; +} + static int __init scmi_check_smccc_ver(void) { if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) @@ -108,8 +215,10 @@ static int __init scmi_check_smccc_ver(void) =20 static const struct sci_mediator_ops scmi_smc_ops =3D { .handle_call =3D scmi_handle_smc, + .domain_sanitise_config =3D scmi_smc_domain_sanitise_config, .domain_init =3D scmi_smc_domain_init, .domain_destroy =3D scmi_smc_domain_destroy, + .dom0_dt_handle_node =3D scmi_smc_dt_handle_node, }; =20 /* Initialize the SCMI layer based on SMCs and Device-tree */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:52:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:52:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104845.1455907 (Exim 4.92) (envelope-from ) id 1ut4xK-0007zO-Nx; Mon, 01 Sep 2025 13:52:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104845.1455907; Mon, 01 Sep 2025 13:52: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 1ut4xK-0007xU-GS; Mon, 01 Sep 2025 13:52:22 +0000 Received: by outflank-mailman (input) for mailman id 1104845; Mon, 01 Sep 2025 13: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 1ut4xJ-0006av-OW for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:52:21 +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 e0fdcb51-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:52:20 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB8345.eurprd03.prod.outlook.com (2603:10a6:20b:509::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Mon, 1 Sep 2025 13:52: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%6]) with mapi id 15.20.9052.014; Mon, 1 Sep 2025 13:52: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: e0fdcb51-873a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FxZi3xByIMAAuFY+pTL0CsVxmWHYf0ywvfSEDvwXzAy+gdXnP4Gyg+lXaBoi9R/jwCL47xH1EeHRu7c0cydm8TXndcp5c2i8lmwBYynkCHMR6TvOnkc/TbA0y7G8mWKVbmpLqfdBeyiH0dXJ5xYKGmnJ56ownCXuOPi2AGcpWoax2HUmxrX3ehS61/oSAZPqtQ9+HoPe/QGxazKNWGxPiO1CevcCiqzUSy1YLp1rkGVeN8+21cusO3IR3zqa0RkPf3QzGBDjFXqt3SxoZE4zwRPMQsB6arei7/Nifng7pOVglbXugi1pzHYCNIfh9uyHaxvYQhjzfy+NaRgO0t5Ozg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QJkWdY351yDwfZ1ygAfzEu2QpGdp7Nht2cn/64+c/iA=; b=jYNet9XUXP48hw8TliNmHuqhC4/b4tb9A50bH3NwzLdHMWpkxEhYZfM9CVH1OJSJNQBptFv9W/208KG2GfPOLkvZW06BZEoIt7532Wj6Z4qNll6YV93L3B8YmkSzQr32hsxkMUhocxVrNV1DSJiFMemDG8EVwlosoeJSaq+06lKvGXknzi/CDUiserweniAUcY8tAIiHMlryFnswQRa92xoK3ufSRbFRMrWL9lb/iANGaSnpfsEeq0hUJxRal0PM9fevQ5HAdsRUoBlDM5JPmYWYZaGY4e7RWHKsO3/cMgYNGzh7o1AHD9hs1iaTHFv4O+95vMnHqTnBkuSGQafBHg== 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=QJkWdY351yDwfZ1ygAfzEu2QpGdp7Nht2cn/64+c/iA=; b=sBFTCGzn5Egtf4pyJQy/oofWQQgKgcGsXjuDnDbx6NUp2n35SPlhvCUunEf0VxxWehIT9OBFHsfpQmW7D3KAkKhIDKWwalBwc6tONxgCsPBJ7zhKYqM4b5hYo8ssxLg09qxfxvJGmvfEjoKkHj/m5YbBwGQmJntm2x7pZ43xbrfB4VrDEJvXCn0SHNVUKTmvqOp+XTBMBx9hD/O3D2yjnw+owfM5lC4yzTKXM2mKbv6Pb5VlmhTDrVZWrn3JbNWJu/vwBlt7k/M2LmFgcOJbvolfx7ZXICEfB2e6uPSKDqg+HLnZEwzKvdjFBV+DNQJeUjguFnfv/5WpjJSADu5GNw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 4/4] docs: arm: add docs for SCMI over SMC calls forwarding driver Thread-Topic: [PATCH v7 4/4] docs: arm: add docs for SCMI over SMC calls forwarding driver Thread-Index: AQHcG0edxinH4Zt33EOMOmbXy/hnDg== Date: Mon, 1 Sep 2025 13:52:11 +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: PAVPR03MB8946:EE_|AS8PR03MB8345:EE_ x-ms-office365-filtering-correlation-id: 8d4b8cef-7cf4-41cb-ad71-08dde95ebfde 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: =?iso-8859-1?Q?hRRkC0f9f2e4FqR0FGdUAHAqXzrdarBo/oHU513aRtDshrctYI4ksjJokY?= =?iso-8859-1?Q?HmoW0HAHQDIE98n/20hF/0n5YbkIcesOecBy5ZEbc8y4fSXXHX/aE0mL4p?= =?iso-8859-1?Q?gVU4Amn+a47h+AN+DsairPE9+ezPUOcnDMCt/GStV3on/CmGIY2JFGIEQ0?= =?iso-8859-1?Q?r1gk5u26XPTjgdkaIQ5o9GHgHRDGlwXmNJBr7cFxaKwLq9gJeMYH0wUXIy?= =?iso-8859-1?Q?0zkT0d4iOk/AIGLZw80Bkv48G42wyKGmzdx2NDGDNfCMm/0DyrrcNl5xWh?= =?iso-8859-1?Q?pF9jtcQfisnS98WrwAP2A6YvkVZrQNFTmRQ+6QJZo+qAY09Fe3QGO7MATv?= =?iso-8859-1?Q?VMR9wmck6xskJ7uopqFS1wMIxayuMGkNXsipNwMa3sC2/SrnLKfzqlncUu?= =?iso-8859-1?Q?yDa2TerdRUK3XeIWrUqY2rpnBHlrLVaHqlnLu0di51KfJX5N9p3aM0DlZp?= =?iso-8859-1?Q?On3poRPsVrIBO7fuBwsBJRn2OPis0NPnSgGuYwqRkHXd0m6b0D1u3iWn1P?= =?iso-8859-1?Q?4UNvPsn+01z1PKM0SPZx5cZk9p4HvySHQe8SNLJrW1OG0KeTlqfOT5oG+j?= =?iso-8859-1?Q?MLLncF5lkZ7DekRj2D/zifz0NhnUo5RxMiPMeo8GVU2jcjLFM7J8RT3Ovl?= =?iso-8859-1?Q?uhuPEZ0bnVfc0l9HvQRb5A+mSSXgncoYymi971BiObgfCtKfCPC89gconm?= =?iso-8859-1?Q?in7zFPsCd8DwHYeVXqeZ6InoSD40UY0K3TnSfVJq/uhwP5gF5hpBbrK4+T?= =?iso-8859-1?Q?9MzxrnMkNcMAWeDAjnl3DWyiFW7SeEKSjU3OjYWyZ2s++9IgFZY1FEwrkf?= =?iso-8859-1?Q?Ll4H7DkLUjrjDeKLgwR5RZ5E4NyCHrpwu5ugaVyVuRxbPQYytyTrepshZH?= =?iso-8859-1?Q?UTD9TGEBP7JIXmQbIBZ/73Rm0btd1+5q5uOjIyApnTVweNNhcHqfvBFttY?= =?iso-8859-1?Q?qgMlnb/0OC4WzN82A9UFMkwzZ+KvV9I+EOdOV8S23rp0UAtmOw9nognSrD?= =?iso-8859-1?Q?DSmjkmk4g2sr68FC4sOl8ptrgi3v+xvAygExU+7s4C4OdHLTTVMsLV+v1w?= =?iso-8859-1?Q?KPRRAMBqQQt1y9683IJEXNKIiXWX7c4GCmM3wPoldDG49BUCuBgGsefIxV?= =?iso-8859-1?Q?B39351TCY1FI0YMA/LOmkTl5AlYJ75llOaJ6RY9fUscettjsCApL0zIzbi?= =?iso-8859-1?Q?0ylcA/FwveeNUKvDp7iBdLveHftsBbcvm4aJNdQtb65dTBWBEMFmE/E8sz?= =?iso-8859-1?Q?amIWzqfyx/jDJ5xY+73mkeD54eTegsMtGlYSnWCMvr5H2QRDoNJNgV8piT?= =?iso-8859-1?Q?U939VlgLOdI4Yag9lCNcmIKRSm3usbhf+03y5HGP8aQoflDDORNLqvdKFT?= =?iso-8859-1?Q?1o5qNkuFIBsAcl5l/2OYh2C24HvPYONd8va+KoP16d+BP1ESx/QVhHbOJ/?= =?iso-8859-1?Q?lauZPDIXnR9kNgW5/q6EyO3wEa9h4VluweHYCWQwvoUoCxcGZk80EMOv+Y?= =?iso-8859-1?Q?M=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: =?iso-8859-1?Q?bjIZ0gEKvVIDFMAi8Ax+pcATgGFDUfNjMWIcLhQf7jSPPX7FAIfc3TCTOe?= =?iso-8859-1?Q?8qQv7pyu9HEWXTRsAdYLHmMLwdM50F+Iq3bM1c0MielHTT7IfOryFUi5AF?= =?iso-8859-1?Q?/6zXmOy3ay2PEkK+EKvh5bWIgdnJbwdLwLoBudGHe0hxYLQSI8xNfY8jWy?= =?iso-8859-1?Q?9J8dmm9a/MvBJ4kygcWN1yj6fKS8qCcZTXvRHZJSgNnWHi9PZQbQDllle/?= =?iso-8859-1?Q?8rXsdl1iElSFZ6Vydb+OiA1F1zC14ORywMGdgdE/wCTZfbORFc9FAw46k4?= =?iso-8859-1?Q?Ao/wQNJ/Zl8brL4PYRmjYteyol4LqV198iuu6gI38fTtoa+jYma7Uok8t+?= =?iso-8859-1?Q?3NgKZR5WtP0afKpdHo0dS1bq716JHaDFTw0ShyoKe5dnRtSkefffntoXbl?= =?iso-8859-1?Q?LXRs+gTU0qa3GtZslGBAAzLn+s7Ha9CDDzkIETbuhpFeNj6ZSwbkBKaKvU?= =?iso-8859-1?Q?JPXuC1pwgCvO9SbS4y9S9NPs+yiv4F1kBs0/VhKWIsEXjbtWGw1pPAJ2IF?= =?iso-8859-1?Q?6Bp2swKy2Q0trDtmwhNnuYu0LvBtoJZnRaMcqpj1qA4jefdSmlPSPKtS9S?= =?iso-8859-1?Q?79prMUM6e3osAfqkrNJxRoa3W7/G+vNK24e2a1LTp9pHAXG0qLfGGZvB+3?= =?iso-8859-1?Q?58a1C++B1BtpoIBfStzx3Xuyo6IaWfNs5Uq/Xeg2M7FVF3f2Ro6evXuHpO?= =?iso-8859-1?Q?CdbzQdBTBACJEekkqjM5rBY0HXRffCtfavLrc6NPmCQEZkKriQeS3ctaFt?= =?iso-8859-1?Q?IunGVu4BA7fIj/QikJnY10Ac8kX3a0ozDGvjWxO0otHVDo4JdXLP9D3H/R?= =?iso-8859-1?Q?NfbV1iZqbKFGEIil16u26YrYXCEd2UmbKbSgEdAoHm4jsZsfRZ7w9qwFYy?= =?iso-8859-1?Q?R7LVO42QWg9CUX7+QNIsxRouS9IHMv1iHAH/V2BOD4YG9ZWu+CzW6nXA0N?= =?iso-8859-1?Q?07pZHc2ZIXNAwwX1vlpAIhgZANUoacsbPecfBXH2NiID9B8GWq9tJLciQC?= =?iso-8859-1?Q?TBnaro4XQpU+iq25P/K3X/nE/OlWovnM0/w0hWccp9nwYgk2cOvJVtF5TA?= =?iso-8859-1?Q?JvbeHBC7/vfn/cui89wsNd2oaTk8Y6QzqJbYKbrCTusgyImFKjHlhs/lSM?= =?iso-8859-1?Q?O/ibUnLHe1UKJHCfUeBDVy6rp2GrHvH+Oh4BM/s7hke6iHoC6Vd3paY1/r?= =?iso-8859-1?Q?QHaACbIotGeYpCPneJtjW+M2U3nELRds39fPVIZX8hpYOaaTbU5Es4EBzo?= =?iso-8859-1?Q?y9TYotznIJrCdDDNaMH09LvGQROds8URnvF/isA6GLd8+En+epQjRiPaVX?= =?iso-8859-1?Q?GGNxA8EsovU/BxA7aKGPaIFitwlK0WJS2L+zNkPuRA/Rs6wQSX6N1yixGO?= =?iso-8859-1?Q?ozkfUdm8PoJQd53D5TbR8Teycwu5veDZAXtcq2TKGRVLOAnA+yfZHEeh6U?= =?iso-8859-1?Q?UUIkriGlshqXzCpYSbpCcYH5pKqtvlUbl8d8TJlLbvnViD23DyRn5MzSxc?= =?iso-8859-1?Q?vrASFMMpXSEemXbwtz0louTNUhgWVp/n65YTnaKvSEJL5bPr5QHNquKFe3?= =?iso-8859-1?Q?tx78YWytgUbS/i79/cBfS9Yhwr++dBS6X0PbHxbJUZum8+oB8cvL68lQ1x?= =?iso-8859-1?Q?2RNJPNwqpyV6HPq5SQcnz8K4seQL6dDUyJ39fqMIA3PycfrVe14zYY2Q?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d4b8cef-7cf4-41cb-ad71-08dde95ebfde X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 13:52:11.0470 (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: Efq5fBZZ80rAN//fQpBX2N3wx6zZJL5YpLh0Jim8s2JN9e8tbKs/IEbyUNcrHM28dGsivPg29w+IjxPZpFA7iHtQa5sUnAgMZYddLStBLJc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8345 From: Grygorii Strashko Add documentation section for Simple Arm SCMI over SMC calls forwarding driver (EL3). Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v7: - fixed typos Changes in v6: - add link to the scmi bindings used in the doc - remove mentions about HVC calls from doc - rename cmdline parameter to scmi-smc-passthrough Changes in v5: - rename dom0_scmi_smc_passthrough in documentation .../arm/firmware/arm-scmi.rst | 180 ++++++++++++++++++ docs/hypervisor-guide/arm/index.rst | 9 + docs/hypervisor-guide/index.rst | 1 + 3 files changed, 190 insertions(+) create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi.rst create mode 100644 docs/hypervisor-guide/arm/index.rst diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst new file mode 100644 index 0000000000..d65ce35acb --- /dev/null +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -0,0 +1,180 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +ARM System Control and Management Interface (SCMI) +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D + +The System Control and Management Interface (SCMI) [1], which is a set of = operating +system-independent software interfaces that are used in system management.= SCMI currently +provides interfaces for: + +- Discovery and self-description of the interfaces it supports +- Power domain management +- Clock management +- Reset domain management +- Voltage domain management +- Sensor management +- Performance management +- Power capping and monitoring +- Pin control protocol. + +The SCMI compliant firmware could run: + +- as part of EL3 secure world software (like Trusted Firmware-A) with + ARM SMC shared-memory transport; +- on dedicated System Control Processor (SCP) with HW mailbox shared-memor= y transport + +The major purpose of enabling SCMI support in Xen is to enable guest domai= ns access to the SCMI +interfaces for performing management actions on passed-through devices (su= ch as clocks/resets etc) +without accessing directly to the System control HW (like clock controller= s) which in most cases +can't be shared/split between domains. Or, at minimum, allow SCMI access f= or dom0/hwdom (or guest +domain serving as Driver domain). + +The below sections describe SCMI support options available for Xen. + +| [1] `Arm SCMI `= _ +| [2] `System Control and Management Interface (SCMI) bindings `_ + +Simple SCMI over SMC calls forwarding driver (EL3) +------------------------------------------------------ + +The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is pret= ty generic case for +the default vendors SDK and new platforms with SCMI support. Such EL3 SCMI= firmware supports only +single SCMI OSPM transport (agent) with Shared memory based transport and = SMC calls as doorbell. + +The SCMI over SMC calls forwarding driver solves major problem for this ca= se by allowing +SMC calls to be forwarded from guest to the EL3 SCMI firmware. + +By default, the SCMI over SMC calls forwarding is enabled for Dom0/hwdom. + +:: + + +--------------------------+ + | | + | EL3 SCMI FW (TF-A) | + ++-------+--^--------------+ + |shmem | | smc-id + +----^--+ | + | | + +----|-+---+---+----------+ + | | | FWD | Xen | + | | +---^---+ | + +----|-----|--------------+ + | | smc-id + +----v-----+--+ +---------+ + | | | | + | Dom0/hwdom | | DomU | + | | | | + | | | | + +-------------+ +---------+ + + +The SCMI messages are passed directly through SCMI shared-memory (zero-cop= y) and driver only +forwards SMC calls. + +Compiling +^^^^^^^^^ + +To build with the SCMI over SMC calls forwarding enabled support, enable K= config option + +:: + + SCMI_SMC + +The ``CONFIG_SCMI_SMC`` is enabled by default. + +Pass-through SCMI SMC to domain which serves as Driver domain +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This section describes how to configure the SCMI over SMC calls forwarding= driver to handle use +case "thin Dom0 with guest domain, which serves as Driver domain". In this= case HW need to be +enabled in Driver domain and dom0 is performing only control functions (wi= thout accessing FW) and so, +the SCMI need to be enabled in Driver domain. + +:: + + +--------------------------+ + |EL3 SCMI FW (TF-A) | + | | + +-------------^--+-------+-+ + smc-id| |shmem0 | + | +----^--+ + +-------------++------+|----+ + |Xen | FWD || | + | +--^----+| | + +----------------|-----|----+ + smc-id | | + +-----------+ +--+-----v-----+ + | | | | + | Dom0 | | Driver | + | Control | | domain | + | | | | + +-----------+ +--------------+ + +The SCMI can be enabled for one and only one guest domain. + +First, configure Dom0 to enable SCMI pass-through using Xen Command Line +**"scmi-smc-passthrough"** option. This will disable SCMI for Dom0/hwdom a= nd SCMI nodes will +be removed from Dom0/hwdom device tree. + +**Configure SCMI pass-through for guest domain with toolstack** + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" + +:: + + iomem =3D [ + "47ff0,1@22001", + ] + +.. note:: It's up to the user to select guest IPA for mapping SCMI shared-= memory. + +* Add SCMI nodes to the Driver domain partial device tree as in the below = example: + +.. code:: + + passthrough { + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x22001000 0x0 0x1000>; + }; + + firmware { + compatible =3D "simple-bus"; + scmi: scmi { + compatible =3D "arm,scmi-smc"; + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +Please refer to [2] for details of SCMI DT bindings. + +In general, the configuration is similar to any other HW pass-through, exc= ept explicitly +enabling SCMI with "arm_sci" xl.cfg option. + +**Configure SCMI pass-through for predefined domain (dom0less)** + +* add "xen,sci_type" property for required DomU ("xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc" + +* add scmi nodes to the Driver domain partial device tree the same way as = above and enable access + to the "arm,scmi-shmem" according to dom0less documentation. For exampl= e: + +.. code:: + + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x00 0x22001000 0x00 0x1000>; + -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; + -> xen,force-assign-without-iommu; + }; diff --git a/docs/hypervisor-guide/arm/index.rst b/docs/hypervisor-guide/ar= m/index.rst new file mode 100644 index 0000000000..7aae4a0a03 --- /dev/null +++ b/docs/hypervisor-guide/arm/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +ARM +=3D=3D=3D + +.. toctree:: + :maxdepth: 2 + + firmware/arm-scmi diff --git a/docs/hypervisor-guide/index.rst b/docs/hypervisor-guide/index.= rst index e4393b0697..520fe01554 100644 --- a/docs/hypervisor-guide/index.rst +++ b/docs/hypervisor-guide/index.rst @@ -9,3 +9,4 @@ Hypervisor documentation code-coverage =20 x86/index + arm/index \ No newline at end of file --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 13:55:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 13:55:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104883.1455919 (Exim 4.92) (envelope-from ) id 1ut508-0001Ra-4d; Mon, 01 Sep 2025 13:55:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104883.1455919; Mon, 01 Sep 2025 13: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 1ut508-0001RT-1F; Mon, 01 Sep 2025 13:55:16 +0000 Received: by outflank-mailman (input) for mailman id 1104883; Mon, 01 Sep 2025 13: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 1ut506-0001RN-Ea for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:55:14 +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 47c4b394-873b-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 15:55:12 +0200 (CEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b0411b83aafso253091366b.1 for ; Mon, 01 Sep 2025 06:55: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 a640c23a62f3a-b042523ee7bsm306417466b.109.2025.09.01.06.55.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06:55: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: 47c4b394-873b-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756734912; x=1757339712; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cn5mtr8lg8zIS/w3Ymeb58ZYdKxBWGGjPDpLEOsUKmw=; b=GcGzZd0Zyb+UwF/yrSRhFJmp1QpPSTQ83tyAJdO2lzIQGXrWED+4iKvAuLRgRNp8vL RdPsuPoVeGJW5YTkCSjPcgVVgzIBgmkCBrHih5F1Gf+njWLJHb3oKNclLNBXPIpd9reP VGU4YuCl2Z3gp6wOBEnCd6GyU2TZNT14ej1c7BHNehgOabOamyuqbmfNVCgGAhem3yyP /J0vXhwy1xjunFnuA+IYlH/OAl2vumsvBOpqsYysJ5lTWN1wBM4GaywJW3Kwqnjq0Ps1 8+qF8NWGEzZoFjn1NcB6lrTZ0u/W4vveGJvocPcvJAwuE+0CreiDNEHzODTwjEI1j5et U1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756734912; x=1757339712; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cn5mtr8lg8zIS/w3Ymeb58ZYdKxBWGGjPDpLEOsUKmw=; b=P/FevrefK7tJOEiWm5FRUOxoSeI1l1qnGW7C3SCMqrveNw/eGymz5+yqZWhU+Satr7 zLgyu3R0XQVfL9pEtnj/i9f7FNluBfW+x2A0r5ghByfGK0uEixpglJUkyvSmDpOJDXV5 6oB67CltjU/3PBuyXDOSj8quRLkt6LTQbURrgLr/LsJKjZ9QI+wsP2yJyagVZFA8oyZ0 Vxhc0bYMgviBUE1ZaNY6m25EghBN5K6kTzYqYo1A4kzYCsiJYMke7R29MREHNXhy/CLF 8idBM4MiKhxnhssZtXBuWR1EjJ+D2ZJvw1PSf+X5F8+Q8nVJxzNrJTODXh4mrQoIh7o+ 4ZEg== X-Forwarded-Encrypted: i=1; AJvYcCXHgEDTy42nHMRSilARICfS6oq6HAld9m8TGVoRCoLG0K2wpplgQhjP16hEfg6Dm9siQ4jfqdk2FCI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyzjJxBiCqsS4Ua7vPeZDAYLzmVvSoqXqRwvBLGDPqDbQ7k/n/1 K3G+0jOsenmOK8qGDrP4xFU68k0pXKzMkWHDVhXZ4MrAzOFEcnVrcy4aifYcYBa7zreonN2wA0s mu5s= X-Gm-Gg: ASbGncuLlWnNDkGLYSuxyx+nAi0vZMWt3usx1v0AWpxdZl4iv6quDt7g/JGLNapcDIG Zh1FXamLUhUZYJPSB/+7PpWfulqTk6CccaNec0FwJPH5noT9KTaqQmxCimm1rY6p4PqRTnIE0bJ OIrifnrhqClvk8p9qrAOAn0Doygwj3crNwb0cuuu57cH/Ijdbf+HFFqaDMosvJFil3r5rGV4nAr N4sCgSEBKTl8e+0leL82jyiCx2JEVCQ3ixsLHhmOfX+hYVIiprqtKixPsAd2S2sP1b191oSMPME UC9qvdWOaXxafA0vTliYsi5B7s2efJhmT0/lIQ30t6QNVFcs9cLGaWFlU+4JOxpPQlw9aPSPhVY 2rUP4YgExLj4h4ZQr3rccNa/vJeM0NoNTisxifuaV0yqR4Sk5JCp+148Mw3EZ+7x5hXWBXcfQsq QoWt4jzgg= X-Google-Smtp-Source: AGHT+IEu0tpd2qKYcgcGJVmUGcEgddc9UlUpu90Ol2F0i3IsBuXEUKtDcFeAFf/spw5ALDA7nrLlhw== X-Received: by 2002:a17:906:f59d:b0:afe:ae99:9d23 with SMTP id a640c23a62f3a-b01ec52d58dmr734253266b.61.1756734912123; Mon, 01 Sep 2025 06:55:12 -0700 (PDT) Message-ID: <4f9ae860-ca4e-479e-be87-85326c89d9e6@suse.com> Date: Mon, 1 Sep 2025 15:55:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 20/23] x86/pv: Exception handling in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-21-andrew.cooper3@citrix.com> <1800ea68-eee1-4433-aa22-954dcd226fe5@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 01.09.2025 15:27, Andrew Cooper wrote: > On 01/09/2025 1:57 pm, Jan Beulich wrote: >> On 28.08.2025 17:04, Andrew Cooper wrote: >>> --- a/xen/arch/x86/traps.c >>> +++ b/xen/arch/x86/traps.c >>> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct cpu_user_regs *regs, bool ist_exit) >>> >>> void asmlinkage entry_from_pv(struct cpu_user_regs *regs) >>> { >>> + struct fred_info *fi = cpu_regs_fred_info(regs); >>> + uint8_t type = regs->fred_ss.type; >>> + uint8_t vec = regs->fred_ss.vector; >>> + >>> /* Copy fred_ss.vector into entry_vector as IDT delivery would have done. */ >>> - regs->entry_vector = regs->fred_ss.vector; >>> + regs->entry_vector = vec; >>> + >>> + if ( !IS_ENABLED(CONFIG_PV) ) >>> + goto fatal; >>> + >>> + /* >>> + * First, handle the asynchronous or fatal events. These are either >>> + * unrelated to the interrupted context, or may not have valid context >>> + * recorded, and all have special rules on how/whether to re-enable IRQs. >>> + */ >>> + switch ( type ) >>> + { >>> + case X86_ET_EXT_INTR: >>> + return do_IRQ(regs); >>> >>> + case X86_ET_NMI: >>> + return do_nmi(regs); >>> + >>> + case X86_ET_HW_EXC: >>> + switch ( vec ) >>> + { >>> + case X86_EXC_DF: return do_double_fault(regs); >>> + case X86_EXC_MC: return do_machine_check(regs); >> Looking at patch 21, I came to wonder where it is that we're moving back to >> SL0 in the #MC case (which may not be fatal), for ERETU to not fault. > > (Almost) any event taken in Ring3 enters Ring0 at SL0, even those with > custom STK_LVLS configuration. > > See 5.1.2 Determining the New Values for Stack Level, RSP, and SSP Oh, right - that's something I still need to properly settle in a corner of my brain. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:02:46 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:02:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104912.1455928 (Exim 4.92) (envelope-from ) id 1ut57J-0003EA-QV; Mon, 01 Sep 2025 14:02:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104912.1455928; Mon, 01 Sep 2025 14: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 1ut57J-0003E3-Nm; Mon, 01 Sep 2025 14:02:41 +0000 Received: by outflank-mailman (input) for mailman id 1104912; Mon, 01 Sep 2025 14:02: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 1ut57I-0003Dx-GE for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:02:40 +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 513cd045-873c-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 16:02:38 +0200 (CEST) Received: from PA4PR03MB7038.eurprd03.prod.outlook.com (2603:10a6:102:e1::6) 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.9073.21; Mon, 1 Sep 2025 14:02:32 +0000 Received: from PA4PR03MB7038.eurprd03.prod.outlook.com ([fe80::62a8:3ed7:1b8e:677b]) by PA4PR03MB7038.eurprd03.prod.outlook.com ([fe80::62a8:3ed7:1b8e:677b%4]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 14:02: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: 513cd045-873c-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=q/jtqrcNx7Uos3GBXRtj0DETlRmRItZfGhqCD1Ksol8t8BZY2GrVGMpVAqCQt6bH3tNn2n7FV3aYmr4ekelSayMT3hQjR+/npzK2N6mS1OsWofPewTBH0AID8O7UncphJGGTaKe6hL7jtUGlQ11U3qUJpPGl6e3dfPrlTPszFWJj5sAntmmPpyPMpW6LfGb3t4UOGMjmZ08ss5OpkGQhg2dKLvWv4JwaMrDYHgMrrZCClwGt+s1poIsKXeV0udECqAY5Jhj822V6IWgUuMeiRjfAEgd0xG/nhuMV/A4Z54ByzZHxjZUVloEoDh7noS+BITtzWz5C9ivxqqTgVF8Dcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=B0kqapVvPaKhbnW+HIkL0/A0sxyvBcPC+2xYi+c0WuU=; b=wTxhdi9/pAQXZk1XS3O7bJdCcRtqNalwTuNKqP8PBeS1opPm8GFcjpsoxRMnLpyHsaoWdM+0Wm9fhKY4/ZWDcykXb9IkMMVr+P3dSOOxpMHWQ6dcg/uSU5fLRxA+OxBNo/bGiPo9URRdz/pVSOTOU87ix1eR0stLu+ANaZ179jT/YcRzCoFXXZk2TAWC/oenW/QsCoNqbk5Rd9t4n7jwol3trj2gQIdjWqtNkWymdWO1OBRGLjY+rGNV7kpYIn+haOnC968AQWCXAMghRdeYbv9ksMoTLw4wbQYQzL/sa/PJf3ZShrwagi5BoDweJOqv5d1lmsvQ/onbufDzEusMoA== 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=B0kqapVvPaKhbnW+HIkL0/A0sxyvBcPC+2xYi+c0WuU=; b=kcCz6AsVnA6KBhRfdeotLn3jwmOHvfKbcbRmyyaWyZyAKCN9nR+kNP/JeQxDWkOZ+OV7Q+TmjX6lFDKogA90+ry1mBeunnJdrY1QTr5hy3LVYZBPlJ7/mklo0M30AHVmbuzzJkJfneAk++MIQRgM5DvO7I6v18LVWntVckBHYMs8VJ9dcexytJWbByfR6n8Pmf7HhKtOdSScTHelxWwt5gD10p6oVDa6V2909NIzFoMUhtAvGC9uUlq4N1oICd2pLNwhFGLIh710CTJDgbWr64LS54rYbQlKkZYy+bdK+JqhXeEznHRmh/mCqjL56nEX7/2lw2lVdTsz/uIcadyKMA== From: Oleksandr Tyshchenko To: "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH] xen/arm: platform: Select GICV3 dependency for RCAR4 Thread-Topic: [PATCH] xen/arm: platform: Select GICV3 dependency for RCAR4 Thread-Index: AQHcG0kPDoyzfEe8LUCSfOma0fVaUg== Date: Mon, 1 Sep 2025 14:02:32 +0000 Message-ID: <20250901140231.1322170-1-oleksandr_tyshchenko@epam.com> Accept-Language: en-US, 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: PA4PR03MB7038:EE_|PA4PR03MB6782:EE_ x-ms-office365-filtering-correlation-id: e7a45d58-4967-4692-1754-08dde9603255 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|42112799006|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?Ep1uFyrqeiMUL6r7fxQQiBCOL2JjpFmdZ+O481Ui/7kMGYnOf2zMEtVNXk?= =?iso-8859-1?Q?WPcqdbOf3Gm547r7hmGuLLxYFL2nu+5X0Rqq00bZcYgQvCk9b/QYED128/?= =?iso-8859-1?Q?ZAVzKc2JBwIbuTgHMBSwlPluxH9ytIhRwWfHlVX0+pfM1vpfCDQYzjzIfU?= =?iso-8859-1?Q?eyFu9WmB0i10To16MnBWrLTQ8g1uwcHF7a5h1JlwdbPtZn/UilT8QAGXy7?= =?iso-8859-1?Q?K2EJ11jzHmW8HfakpEACdikcCihBavL6ycNEx4kkL3YZErzxN6/1zyj26u?= =?iso-8859-1?Q?CWE5xyjhDdafPFnR3BJYvrstSygQmxmETlkHQWsfZodsuSQBvdAv8wzM0r?= =?iso-8859-1?Q?FOWoSryjEIu06FwBx8j1xalzEuaWMUtp+g1z0JQ0Evxkjj6T6TJ2cs1JQv?= =?iso-8859-1?Q?i6DKOTBJ0KD+5k/xP8xGO6OLQ1KhCnfqTsBvJefG6qtfbvwD5tnJ3y9PY5?= =?iso-8859-1?Q?I4ErdmiBdmeDQnzIT7tQOm+WMj2XLYrIbs1OOXoApoUVJz4lQT8g1PPO9v?= =?iso-8859-1?Q?koiaK+5uyOEbfOqz8ceJZeV+ei3CcQGtwGwuaZY8rDZFfOJd20DtcunrpH?= =?iso-8859-1?Q?hMZsCQp/glkFOxaYJAQk21BVAXaNzQcSdYAWlye/B2CgXTBM6C5/1VFJQr?= =?iso-8859-1?Q?Z5lWNg76I5F5x/SMu81CTcuKb5PtMHEtuXWNwWO9i4mhhm3H7oTqjaYBcq?= =?iso-8859-1?Q?NuaSdLF3dwCkgBDqKuRuofjLo+0Kiqk/l1qvbQacog1/sOLdAZNaxUA+uy?= =?iso-8859-1?Q?uojGQw3kQ/AhmfM98ecAV4vy5mKwedY5UPLgGBns0NAbWaHKynkRnjrxnR?= =?iso-8859-1?Q?5tn3nadQrPOr9LO9WdgMkJ6d+DXyWZfhUcqjoYnP4GxVBsEt1SGRky+jSo?= =?iso-8859-1?Q?SVGWw/ycFwGCyrUXb80ewiQXqclVhettMGkIgSL89/TDAIXPVkSKkA3cwg?= =?iso-8859-1?Q?nhxINDD9O1Ep5J8wZXYRz+vMFumF6y5d/ksiy+NdU+Ylp23oUi1wSICU2w?= =?iso-8859-1?Q?Rq8DvbFkq+MRxClEW0UkHqm8tWQtMz3moovUAFX+JB/aGX5RWHP7MUCugu?= =?iso-8859-1?Q?qtZPJxRpW7ExXh76A3ioun+gGEmI1njtP5b5ANuT1jnEyMy5TBes4AmKXk?= =?iso-8859-1?Q?+v7vvgWeoU/13ZbnbVSljBvBgH+H9AVKk4LoQldjXZ8pfKkh0hiqWyw6GU?= =?iso-8859-1?Q?QYlWvuvPtO2hLH/iUzi8G6WkrUqE8EiuEc7JqQpmTvpG+7Hz7dPU5ZHSIg?= =?iso-8859-1?Q?CGuEQCwIQuYoi5STIhsevdqpUR2uX0REKd0WqKF4BaWayqMFrZWS4LCk48?= =?iso-8859-1?Q?y5lsUR0TuQt6JFQDw5c1i4h0LLNMOiD0M+y1cSpWMIMIToe3gCTXWlSxB5?= =?iso-8859-1?Q?zjtDrd4cnqX7AKh6ln7j75cj9w/ocJCrXMjN5aVOtVSJz52ziUTPw7qvQL?= =?iso-8859-1?Q?NzlvM268zX5+1PvRABjgf4N4NhnmAejAmNebtuJ7TvcNY69BqZTIiPuD0/?= =?iso-8859-1?Q?LAOTeFRUeELKiiCPfvo17EZ1E/E03MZLfpjgwjZzxG0w=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR03MB7038.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(42112799006)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?QI+APgQg0nfP3i+HVP3WBtvtVuZk/Dm4BGnhxG63jQARY2IUbX8l8Yw/0T?= =?iso-8859-1?Q?gnuy6awMTXFGrSj0wyWJH/0Q4RPIC/anqyLkNZmT4CRlWAgOB2pLs+Lrcf?= =?iso-8859-1?Q?jRA5H5PTx5ZxfLHxQYr34gOWYq4wVlu/RHmfD0/N2jwT0+abdalxNgGQy4?= =?iso-8859-1?Q?xfrhtgxvG6rQVObOpeIT978RiNq9ykzapYyAJodxh03otKTfdzLiX49zhD?= =?iso-8859-1?Q?dVETjcC9lAt7+BY08jhoJofFokSZSuaEI5B2N1V+ly6y2WngXp0kSdWD9j?= =?iso-8859-1?Q?V2f+TmY1Siq2EbQ/gRIquZS+S3U7vzJsU45i55O0HEZ8ILIik3o+MxFgxH?= =?iso-8859-1?Q?WQwUTSA5cxokRGuK8BQwuqoYe9xbMn68APZuMgIx49zQFWKb+951u72Huc?= =?iso-8859-1?Q?Zex+USK8XJ02kP3FIIoBcc65ZQqcKNq6tTITT78nMx5LpI3AUoi9isrjVX?= =?iso-8859-1?Q?0B+LUPDC9OlXQiOyxABHh1UrRcRHHSh0JXI3KPxwxdzmJoDKcuCD2wm+I3?= =?iso-8859-1?Q?oqrLMQRJ6AlY9tQINA1MnVEziiPwm+GUug16Itm/EsYPlfVf1AfrpcHWCV?= =?iso-8859-1?Q?WuJl5TyFqq+kxeF3Zr1ATYmGjeBJx60QbvnXMsyz57VpNVbN3u10n1x+LW?= =?iso-8859-1?Q?8nblS7Is7NpiVyDvjvdN7FgHB4Ht2xOy0GyJo6CPEhzv2S5ukQedN2FlNL?= =?iso-8859-1?Q?tpcl2LDZK7yV/ZSRbV1ZfSHoPC2yIQ9+NfqYRGU4SBH4wqr1jFd8wJ+5j2?= =?iso-8859-1?Q?NMzejnFmf41XM1/BeOmFqsiNXsKzEFpqtnbGeAMcLzmhzP+9TJggcqVSad?= =?iso-8859-1?Q?24PMHmEYfFEbdE5P0xB7Ok7XF9MKpa7mbeogHU1RbbnDYXgq4qowWymK7m?= =?iso-8859-1?Q?SaKu8/rhsWPBORaXUIM/6Kjxd/O5yX97ZwYIruFJZtvUomiBTUcK20cYLN?= =?iso-8859-1?Q?Za+IhbSS8s7iGQkNoQtTcRlg9MH0ocHfSJDWLDbkLErs7+XE3boOD5qEdS?= =?iso-8859-1?Q?Wfn86wcvQ2DKNMaWBvFh86MdRSW7Nk1CUFkazSKhWR0/icZ2DNxFcKP2no?= =?iso-8859-1?Q?Gzu04NvZp1obqyRiPt+D6zpfNTSZv+PJ6VP02c7JuAkeNse2Kkfde8U+5W?= =?iso-8859-1?Q?vEE68wgay9A+45duo9nR58g+odnIecVEvm1oQJZykT2bo2JtImFC7539Oc?= =?iso-8859-1?Q?Y/9kB2ntmdLyK9OF9uJrJVcAjFk9qnBoGbReVNt6qjoA7KRmjCw6gsDpZE?= =?iso-8859-1?Q?dX3ZTxYoWsXmzzHNZjsW1+Ba06eK7PxyW+Ubhv+d8qwd3JvJOnFHYL1pmy?= =?iso-8859-1?Q?TpO2FOuEJi8PI9vC3qY4QEWFzA7BOBiHWJ6GAJPK/xBHCe2GQI5joSSH7C?= =?iso-8859-1?Q?pgOehHPZAcE/dqVGqShmzHuDJNFxYHvVfaC2v/hx2n6PSH4rbA7f7AyBsG?= =?iso-8859-1?Q?Mvk9kdCYTxvPadXAYuFpxz+7I7EPGkE5i9lavDWBFUszvzyqPSw0abFxqI?= =?iso-8859-1?Q?7hZntqNaeD6H/tGM5VxSkQuVyYT+f/IU//74/NsmgChZO7CgqsbCfuwwW8?= =?iso-8859-1?Q?MK4tgE1Nw92tgHQgFtFoPZ1syXhkl4yXI0Z9KoYw5PuGbXH7TaBYmVBARj?= =?iso-8859-1?Q?C+skCSIo0rekpM14kB3IJR0NtKMJ3lZml2n1NQy1cPckta9iWDpDxbYIDE?= =?iso-8859-1?Q?0Q4ezR17VX8Z9VvFFFI=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: PA4PR03MB7038.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7a45d58-4967-4692-1754-08dde9603255 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 14:02:32.6702 (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: xgqVOskkBkkQPpW7D1DtqPKfPLs1N8NYQJF8m8YQR15Dfg4sBfRGy4Z0mdSi7b3ADwbcGl/joEnby8bv1JqoWg2GDBdFvxvLwnlmznHCs98= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6782 The Renesas R-Car Gen4 platform requires the GICv3 driver, including support for the Interrupt Translation Service (ITS). Without explicitly selecting GICV3, it was possible to create a configuration with RCAR4=3Dy and GICV3=3Dn, leading to a build failure due to unmet dependencies. GICv3 driver (GICV3) [Y/n/?] (NEW) n WARNING: unmet direct dependencies detected for HAS_ITS Depends on [n]: GICV3 [=3Dn] && !NEW_VGIC [=3Dn] && !ARM_32 [=3Dn] Selected by [y]: - RCAR4 [=3Dy] && && ARM_64 [=3Dy] ... arch/arm/gic-v3-its.c: In function 'gicv3_its_map_guest_device': arch/arm/gic-v3-its.c:729:41: error: 'struct vgic_dist' has no member named= 'its_devices' 729 | struct rb_node **new =3D &d->arch.vgic.its_devices.rb_node, *pa= rent =3D NULL; | ^ arch/arm/gic-v3-its.c:755:28: error: 'struct vgic_dist' has no member named= 'its_devices_lock' 755 | spin_lock(&d->arch.vgic.its_devices_lock); | ^ arch/arm/gic-v3-its.c:768:54: error: 'struct vgic_dist' has no member named= 'its_devices' 768 | rb_erase(&temp->rbnode, &d->arch.vgic.its_devices); | ^ In file included from ./include/xen/sched.h:6, from ./include/xen/iocap.h:10, from arch/arm/gic-v3-its.c:13: ... Fix this by adding "select GICV3" to the RCAR4 Kconfig entry. Fixes: 336fc7a19b49 ("xen/arm: platform: Add support for R-Car Gen4") Signed-off-by: Oleksandr Tyshchenko --- xen/arch/arm/platforms/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfi= g index c8bc0bfae3..888d0b85d5 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -33,6 +33,7 @@ config RCAR3 config RCAR4 bool "Renesas R-Car Gen4 support" depends on ARM_64 + select GICV3 select HAS_SCIF select HAS_ITS select IPMMU_VMSA --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:03:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:03:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104927.1455939 (Exim 4.92) (envelope-from ) id 1ut580-0003mX-6t; Mon, 01 Sep 2025 14:03:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104927.1455939; Mon, 01 Sep 2025 14:03:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut580-0003mQ-3t; Mon, 01 Sep 2025 14:03:24 +0000 Received: by outflank-mailman (input) for mailman id 1104927; Mon, 01 Sep 2025 14:03: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 1ut4xp-0006av-1p for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 13:52: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 f37f1b5c-873a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 15:52:51 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-b04271cfc3eso148101866b.3 for ; Mon, 01 Sep 2025 06: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 a640c23a62f3a-b0413782b94sm441257966b.35.2025.09.01.06.52.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 06: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: f37f1b5c-873a-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756734771; x=1757339571; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3y9mL5hrwYwKk2Rj4802Pv1GSH/ciYwuHCdvajLR05M=; b=cbRxZfCJbcH/bl6Mv3kGf+CUJ3T0sb9FsuPLElZECtNMnkAXEZ7qnCIUmryl1n7U6B MFC3AuSGbhbLpScc/YdFtzDJBLCErPO7zXTyElTSGkNLhfAGQOQph1cEwKQt4KX6W2+p 5rjqaT1tRw738JU0pUN6WRaYcZqBxwRKFbSlRaakQ22279i2PW38I/EaPCRQ3sIOPyqd dUFzRJ5rq1nRAi24k3qFcHzKoaRgwItxZR9wrzFgcAlqIcE4Evv+tLl+6+5l47fBKvLe TZ23AvFpuy3VuDLai1I39MI54KyOTl4lLtC93hIbz71RUPC7KhrixBoYmBKH3Zn+tUKB GKrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756734771; x=1757339571; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3y9mL5hrwYwKk2Rj4802Pv1GSH/ciYwuHCdvajLR05M=; b=sy/+SyLI4p7QV4PqSSwtXV+vDs1LZjm1su26J4ReZb1+ApuzGpLeGRGPwnRfWfDSte n+/hnoXi9O4ADudaBT8KSEsga3i+KruUXoyU0+cKSnUX1CqmiDmjYbya7wwuemLD8h+C 2xMXzyxqE3zj8ULKKaPe3NFB9cbZXbRgA+sAujNbhfhd7DCsb9qACgLb5FpFiE2talz0 idSqRDc6M9ksmcFxRWIXgj6qeClAX8Y06UBY04alb1xkXzvYI8wGFZb2u/q+bcUQcKxZ BMBn1YX7TDg1GNaDzrvy5nO25A7Hfasy9cu4BvOp7plvQOphQDUV7pwlW59gzzL5Fsx9 6VTw== X-Forwarded-Encrypted: i=1; AJvYcCW35eQPm31W2Fy71KEvxGbRnpHnZHfqqDzdy4ExBiDiZPT3jSJA5KfjZzmn1XADTbasr1lirj7ALnM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzqjKgwUW4NLyQnXRqxbxq3Cm8tVOfALW4WivHiUTL3F1JYjuGB iX5V9kJopMVX+A02IR65gmMAxdLyWtzenyws1XWkgOgbwfW2m3RVCOO+BgPVuKxILg== X-Gm-Gg: ASbGnctFQjMqBlrQzF10ANR+STgHdX77XG/gFtdfDgwzq2Px7+o53UCl67w08xTYRGo PPNDl/TRS27eYzCvWOjTVoEIMja1Xfi7cTgAbzIi3w64X88eDbClzgH30oNHOMWsShW9AkdNd5Q ZUd2/5lqjATZAPax0+FGZr5bs5cAya2FBvvbvTIpvk1/fCb7kQF9oBnOveldtDlF+hYwx77NOQg S8et6ko7AlGFosCvttcK8lUBITP38j/a1+/BTucDKafuc7oti1LCoLQmRrjFOYaoa83DW0rDREM WRe1NGU6lUm2/UhAPdxTRm0iUrINI7wBuzogsc9B7QLcbLseKpFo2dvKbtXFAwRvarsdMUqUeJS 1VmkwaBvehlt5Bi7wW/jBbLja+dRpB7ET1G1kpEm9e3kTk2op7txWnRtVb20/NnhPIYV0GqUQpO QWv9V+F2U= X-Google-Smtp-Source: AGHT+IFzlLV8pp5YtAnjigJIfJCwJETHKdO/Aoi8tP6NniwigTBQYVuM/BvYQgRYEedYNRnf3IKKRQ== X-Received: by 2002:a17:907:7289:b0:ade:c108:c5bf with SMTP id a640c23a62f3a-b01d976d963mr873351266b.43.1756734770656; Mon, 01 Sep 2025 06:52:50 -0700 (PDT) Message-ID: <027f25f0-4871-4e2a-abca-ea83bcda267b@suse.com> Date: Mon, 1 Sep 2025 15:52:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 3/3] CHANGELOG.md: Add SMBIOS 2.6 update statement To: Teddy Astie Cc: Oleksii Kurochko , Community Manager , xen-devel@lists.xenproject.org References: <301a84287488629932950c1cefef3a97c3d9ba0d.1756460430.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: <301a84287488629932950c1cefef3a97c3d9ba0d.1756460430.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.08.2025 11:58, Teddy Astie wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -34,6 +34,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port > Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device), > and 28 (Temperature Probe). > + - Updated SMBIOS version to 2.6. Like the earlier SMBIOS related entry, this should be more specific. At the very least it needs to similarly mention this is about hvmloader. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:18:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:18:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104946.1455948 (Exim 4.92) (envelope-from ) id 1ut5Lx-0005zH-DU; Mon, 01 Sep 2025 14:17:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104946.1455948; Mon, 01 Sep 2025 14:17:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5Lx-0005zA-AQ; Mon, 01 Sep 2025 14:17:49 +0000 Received: by outflank-mailman (input) for mailman id 1104946; Mon, 01 Sep 2025 14:17: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 1ut5Lw-0005z4-1G for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:17:48 +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 6d4bacbc-873e-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 16:17:44 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-afcb7a16441so682661166b.2 for ; Mon, 01 Sep 2025 07:17: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 a640c23a62f3a-b04312fc8eesm206241566b.59.2025.09.01.07.17.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07:17: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: 6d4bacbc-873e-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756736263; x=1757341063; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=MYp/6n2FjRcTOZTBHgjlU3II5P2L4FoA2cfXoLeKOEo=; b=PHuS0yf0Vb8bEHtA4zuvmnm8Q0yHgsXAtFplxw+raupYs568RIbh9ndTb8gGGuwmSv e2894QNucSDc6WMpkKY/N8SUbA8luRBmbIPgRaHXAQF2vPbnK8eCwQnzMf7nbqIBvgBo gZz3HfIDfb2FeKp4+vw20iOdHDeFQPcgM7WHn1G3+7BNgCq/u87DT9GDx3urC0ZOW2+O TeegVkE8jYZdNWKEzMA8duyd+rontDq4MxQGjTcGnnFS4x7I/rshNveA8GtWCZD/gd9x kmIYHwTVQ6qYVkYvMeYqfLEV+D0MMnXdWUs6EuiehrYQPi0+5c58R0waJDj+N1HPi5Ws o1rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756736263; x=1757341063; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MYp/6n2FjRcTOZTBHgjlU3II5P2L4FoA2cfXoLeKOEo=; b=Wu5iYC/oTLHO6Qtw3Zke9wI8es2Q9aSRZKvI607EU8fzb4Uka3NJS7rNN7z28xNWte ZBX+6njJGWBrD59VNx1CY6gUdH4yUIkTAIY6hwcMV0XhTvAAZvfx9S6ZMmjgMs7qljqi CJndZ1Fl6UY1N0SuaYpxUhN7fd+GNCche/AiECBaunTDGFGKcxS2XTt3+hhXY6vx/8S2 3QyfwtdiWJ/MC7UDWx8uokcJEWMlDsKQSNTPNLXqVfhekGO92o/merhUoGQm8Aedcdxy /yLQ8L1OYPTxynNOSACJvXfegilVu9YSmSwuz5hrXuqoD+HhDHi0Bj6ESHRu5hwNotxp wiAA== X-Forwarded-Encrypted: i=1; AJvYcCWmyqYmDt8xpL+PBAZuZRiWnoTkjLrJSiIbwTtNIwYd/IZj1WsinfMHFSZ1JGQ6IKLlyJnmU67TPYY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzJp0XY5xCWtCBDD4W+ESoHl6CwUENG1DrI0pgaWwN+fMHPtUay eLnhz6i2o6w+Kc9tRweXbkD7o9g6+wEBmxYpEhcUPnvtfFiGHxwK5Q/7X9gkoyPNFzWzClTIEHR dN0c= X-Gm-Gg: ASbGnct1dAPq21vctyAwxAE+ZCO/MQXaygBng3u/wrQF9gv9wRw9J0pXOpEcrH+UOFs clfg0miWS9vrr48t9qewUqDOuEzOTPEmnctafUjY7NkcUJAE2rK926vqnTDCS1akq8LquIw5NvW f6cF3jcLbgawDF8uhvaFGUFfYEibPghIjApe+oiuiE+QEh/QrnVc2l4bfYxGhtxNaJcuXNXY9Gc bnBgE9yGcYE53Yoks36+PF2P2cWJFaIYCy15/A/DE015jDF/acBd16DYdAzApobk7uSRol1qCYi 7oDxyokuAjQx2dWuc0Q/xyUL0zed/v4PChOW/U8giVX4Hz2bZjcC2ikfG8cL0VJiD8kGYxrOWle Ft/Pf9EjudL/8m0OOc6oD/lLHw823QBN5FiHSPCCbrpxcihRPjeavSzB9eqp0J3uAZ8hqIag9R1 2V9FXBSuEjSmr8WpVcog== X-Google-Smtp-Source: AGHT+IHzhjs/1H45IS3BGqVfo7ynlzuAVR+M4B1TH4b/4tLxq2Qa+Z7ZGUE5gvdh+aFe7Pd6cA9P4A== X-Received: by 2002:a17:907:2d27:b0:b04:27a9:cfe1 with SMTP id a640c23a62f3a-b0427a9df6dmr327800066b.47.1756736263378; Mon, 01 Sep 2025 07:17:43 -0700 (PDT) Message-ID: <02689181-5d1a-453b-9abb-c0d7664758b7@suse.com> Date: Mon, 1 Sep 2025 16:17:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 23/23] x86/pv: Adjust eflags handling for FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-24-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: <20250828150409.901315-24-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.08.2025 17:04, Andrew Cooper wrote: > ERETU, unlike IRET, requires the sticky-1 bit (bit 2) be set, and reserved > bits to be clear. Notably this means that dom0_construct() must set > X86_EFLAGS_MBS it in order for a PV dom0 to start. > > Adjust arch_set_info_guest*() and hypercall_iret() which consume flags to > clamp the reserved bits. > > This is a minor ABI change, but by the same argument as commit > 9f892f84c279 ("x86/domctl: Stop using XLAT_cpu_user_regs()"), this change will > happen naturally when the vCPU schedules. It's no that similar, is it? MBS will be observed set once guest context is entered, irrespective of any scheduling. So it's entirely benign if we set it up-front, except of course for a back-to-back set/get. > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v2: > * New > > The handling of VM is complicated. > > It turns out that it's simply ignored by IRET in Long Mode (i.e. clearing it > commit 0e47f92b0725 ("x86: force EFLAGS.IF on when exiting to PV guests") > wasn't actually necessary) but ERETU does care. > > But, it's unclear how to handle this in in arch_set_info(). We must preserve > it for HVM guests (whih can use vm86 mode). PV32 has special handling but > only in hypercall_iret(), not in arch_set_info(). I think we need to either reject or clear VM, NT, IOPL, and whatever else would make ERETU unhappy (for IOPL we already do so). It simply is of no use to ... > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1273,7 +1273,7 @@ int arch_set_info_guest( > v->arch.user_regs.rax = c.nat->user_regs.rax; > v->arch.user_regs.rip = c.nat->user_regs.rip; > v->arch.user_regs.cs = c.nat->user_regs.cs; > - v->arch.user_regs.rflags = c.nat->user_regs.rflags; > + v->arch.user_regs.rflags = (c.nat->user_regs.rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; > v->arch.user_regs.rsp = c.nat->user_regs.rsp; > v->arch.user_regs.ss = c.nat->user_regs.ss; > v->arch.pv.es = c.nat->user_regs.es; > @@ -1297,7 +1297,7 @@ int arch_set_info_guest( > v->arch.user_regs.eax = c.cmp->user_regs.eax; > v->arch.user_regs.eip = c.cmp->user_regs.eip; > v->arch.user_regs.cs = c.cmp->user_regs.cs; > - v->arch.user_regs.eflags = c.cmp->user_regs.eflags; > + v->arch.user_regs.eflags = (c.cmp->user_regs.eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; > v->arch.user_regs.esp = c.cmp->user_regs.esp; > v->arch.user_regs.ss = c.cmp->user_regs.ss; > v->arch.pv.es = c.cmp->user_regs.es; ... accept the bits here, just for the first exit to guest mode to fault on the ERETU. The guest would have a hard time to recover from that, I expect. Yet perhaps we should do this only conditionally when FRED is active. Then again a VM migrating from a pre-FRED host to a FRED one might observe the (minor) behavioral change later on. > --- a/xen/arch/x86/hvm/domain.c > +++ b/xen/arch/x86/hvm/domain.c > @@ -194,7 +194,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) > uregs->rsi = regs->esi; > uregs->rdi = regs->edi; > uregs->rip = regs->eip; > - uregs->rflags = regs->eflags; > + uregs->rflags = (regs->eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; > > v->arch.hvm.guest_cr[0] = regs->cr0; > v->arch.hvm.guest_cr[3] = regs->cr3; > @@ -245,7 +245,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) > uregs->rsi = regs->rsi; > uregs->rdi = regs->rdi; > uregs->rip = regs->rip; > - uregs->rflags = regs->rflags; > + uregs->rflags = (regs->rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; Why would the HVM code need changing at all? We never ERETU there. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:21:47 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:21:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104957.1455958 (Exim 4.92) (envelope-from ) id 1ut5Pl-0007oa-Sg; Mon, 01 Sep 2025 14:21:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104957.1455958; Mon, 01 Sep 2025 14: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 1ut5Pl-0007oT-Pc; Mon, 01 Sep 2025 14:21:45 +0000 Received: by outflank-mailman (input) for mailman id 1104957; Mon, 01 Sep 2025 14:21:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5Pk-0007oN-4P for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:21:44 +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 fabf5d49-873e-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 16:21:43 +0200 (CEST) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-45b88bff3ebso9281175e9.3 for ; Mon, 01 Sep 2025 07:21:41 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7df3ff72sm99621875e9.1.2025.09.01.07.21.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07:21: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: fabf5d49-873e-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756736501; x=1757341301; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=TGEFM4rXYhommHBQGhO2DWsW76qP+gCE1d6nVDVF9io=; b=CNT9zcgNnVb+mz+kk+fVpcwprC16SpE59xayVCWSpVhjEB+bTxUOuvzINwm5ctIhjW BkjlL92vArSGHBFs9hMgH1lMbNQB/1/CuVhwYuFPQ8tB1UYwaLhys1gUVWYXQhiVCIzN +aLRK+RpeAQPfxlBkCOzyd6sLP9+8NVNvkyuE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756736501; x=1757341301; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TGEFM4rXYhommHBQGhO2DWsW76qP+gCE1d6nVDVF9io=; b=PH8RbiblNGrIcmQ7jURUXepiTBnC6MS9HIQ/d823oj7r/hqvosMSUUL1tMiqIlMt15 ijMKsk/066RHUbL3WWECuCbj6y8oX8LQ5NxKZP+at6RCDNqZnOiKZxcZjP/4xlSv1JAe av8GOINLGXw7TR0i0OmnKtb0IKiibN9hfya4elVs3QufmkkE3zf0+1tk7vUxX0QOtczU iRmfoI0dCICwTsWv/WPx0vyluTP/Uw1zFptPrmNBbZGwOP1dcP49bjU3FJBXgnvWstqy wwhu/ev9CNHDI1Bh/FT5xtDQVs6innp64M7gEEQD2beIgvqc4xuwhWmpDK4NmUsuO8Gq i8cg== X-Forwarded-Encrypted: i=1; AJvYcCWUV04gdGrvwtOEaSjtK2GxMMWarHxQVAqeWPgOw6uanf/zvEZjbDERn7IAH4cHeWFG1K34o1ZfB40=@lists.xenproject.org X-Gm-Message-State: AOJu0YxFpa5FoidVoE0iwYBkSsTTMTNnd7kTmYGAlzXMERyxdGRb0Tlm g1nHjSetzMMo2BUJnFeJaWOmH+A07m2THULH59nJ9CB8rCyAKjkRWRp0ZtvmRKbH5CU= X-Gm-Gg: ASbGncvA7FTZR+D2MLr6x+v4G0lvFw3TJpLyh4zPRe5CSToLgHt+XCG9eLSTn2vfBMB 4ZsxbHr3x8RG3r9b8yXRZpgARfKys7BQ1FEdH/tophoUD+SuBUvifynWS84iuHGKkiPghnqrxTT 0Wi2yBrmc2YKb0rTzYH0zSjrH8E61ADf9f0B9O3CyskNR1gtyplf2ItgY9S0hZxMy19zL2caUOz bLwexVyO8EIKPFdF6FttLp9UIA1dB1H8HtST7azQ5EHWC4U/wq8aWkYffdDt8oVPpII/mJSUYde ldjZPk7Y/3FFp/U4AjvGr67alqBSkv1PnzqbQ2YqK8ulKwpjNw78PuD0RoYjqlxDo5D3O3zCBlg OfuToGfI9kQDdUJwrFK4hVm1AV5ywYkFStwPhIu7Gk/lJNgIym1AwTtR+PO1/QGINl2LG1LNd3Q qdCVw= X-Google-Smtp-Source: AGHT+IEBoBaJgxZopqGWqbE+aqWDNEnoPYd2EP2YOEQnTg51Nv1jG56BXdgGcLjy5jxSspkyRr3SkA== X-Received: by 2002:a05:600c:3ba8:b0:445:1984:247d with SMTP id 5b1f17b1804b1-45b8552853amr68672335e9.7.1756736500872; Mon, 01 Sep 2025 07:21:40 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 15:21:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/bitops: Optimise arch_ffs{,l}() some more on AMD To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250527222930.1452674-1-andrew.cooper3@citrix.com> <20250826174135.605220-1-andrew.cooper3@citrix.com> <3ec7b53e-aef6-4a00-acb3-19cbbe6543c9@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: <3ec7b53e-aef6-4a00-acb3-19cbbe6543c9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27/08/2025 8:52 am, Jan Beulich wrote: > On 26.08.2025 19:41, Andrew Cooper wrote: >> --- a/xen/common/bitops.c >> +++ b/xen/common/bitops.c >> @@ -97,14 +97,14 @@ static void __init test_for_each_set_bit(void) >> if ( ui != ui_res ) >> panic("for_each_set_bit(uint) expected %#x, got %#x\n", ui, ui_res); >> >> - ul = HIDE(1UL << (BITS_PER_LONG - 1) | 1); >> + ul = HIDE(1UL << (BITS_PER_LONG - 1) | 0x11); >> for_each_set_bit ( i, ul ) >> ul_res |= 1UL << i; >> >> if ( ul != ul_res ) >> panic("for_each_set_bit(ulong) expected %#lx, got %#lx\n", ul, ul_res); >> >> - ull = HIDE(0x8000000180000001ULL); >> + ull = HIDE(0x8000000180000011ULL); >> for_each_set_bit ( i, ull ) >> ull_res |= 1ULL << i; > How do these changes make a difference? Apart from ffs() using TZCNT, ... > >> @@ -127,6 +127,79 @@ static void __init test_for_each_set_bit(void) >> panic("for_each_set_bit(break) expected 0x1008, got %#x\n", ui_res); >> } >> >> +/* >> + * A type-generic fls() which picks the appropriate fls{,l,64}() based on it's >> + * argument. >> + */ >> +#define fls_g(x) \ >> + (sizeof(x) <= sizeof(int) ? fls(x) : \ >> + sizeof(x) <= sizeof(long) ? flsl(x) : \ >> + sizeof(x) <= sizeof(uint64_t) ? fls64(x) : \ >> + ({ BUILD_ERROR("fls_g() Bad input type"); 0; })) >> + >> +/* >> + * for_each_set_bit_reverse() - Iterate over all set bits in a scalar value, >> + * from MSB to LSB. >> + * >> + * @iter An iterator name. Scoped is within the loop only. >> + * @val A scalar value to iterate over. >> + * >> + * A copy of @val is taken internally. >> + */ >> +#define for_each_set_bit_reverse(iter, val) \ >> + for ( typeof(val) __v = (val); __v; __v = 0 ) \ >> + for ( unsigned int (iter); \ >> + __v && ((iter) = fls_g(__v) - 1, true); \ >> + __clear_bit(iter, &__v) ) >> + >> +/* >> + * Xen doesn't have need of for_each_set_bit_reverse() at present, but the >> + * construct does exercise a case of arch_fls*() not covered anywhere else by >> + * these tests. >> + */ >> +static void __init test_for_each_set_bit_reverse(void) >> +{ >> + unsigned int ui, ui_res = 0, tmp; >> + unsigned long ul, ul_res = 0; >> + uint64_t ull, ull_res = 0; >> + >> + ui = HIDE(0x80008001U); >> + for_each_set_bit_reverse ( i, ui ) >> + ui_res |= 1U << i; >> + >> + if ( ui != ui_res ) >> + panic("for_each_set_bit_reverse(uint) expected %#x, got %#x\n", ui, ui_res); >> + >> + ul = HIDE(1UL << (BITS_PER_LONG - 1) | 0x11); >> + for_each_set_bit_reverse ( i, ul ) >> + ul_res |= 1UL << i; >> + >> + if ( ul != ul_res ) >> + panic("for_each_set_bit_reverse(ulong) expected %#lx, got %#lx\n", ul, ul_res); >> + >> + ull = HIDE(0x8000000180000011ULL); >> + for_each_set_bit_reverse ( i, ull ) >> + ull_res |= 1ULL << i; > ... even here the need for the extra setting of bit 4 remains unclear to > me: The thing that was missing was the testing of the reverse for-each. > You mention the need for an asymmetric input in the description, but isn't > that covered already by the first test using 0x80008001U? The first test covers {arch_,}f[fl]s() only.  It happens to be safe to count-from-the-wrong-end bugs, but that was by chance. The second test covers {arch_,}f[fs]sl() only.  They are unsafe WRT symmetry, and disjoint (coverage wise) from the first test. The third test, while the same as the second test on x86, isn't the same on arm32. Just because one test happens to be safe (symmetry wise) and passes, doesn't make the other variants tested. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:26:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:26:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104969.1455969 (Exim 4.92) (envelope-from ) id 1ut5Tx-0008Mk-Br; Mon, 01 Sep 2025 14:26:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104969.1455969; Mon, 01 Sep 2025 14:26:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5Tx-0008Md-94; Mon, 01 Sep 2025 14:26:05 +0000 Received: by outflank-mailman (input) for mailman id 1104969; Mon, 01 Sep 2025 14:26: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 1ut5Tv-0008MX-VD for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:26: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 9669d4fd-873f-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 16:26:02 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-afec5651966so173606366b.2 for ; Mon, 01 Sep 2025 07:26: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-b0423ed35e4sm315315866b.25.2025.09.01.07.26.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07:26: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: 9669d4fd-873f-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756736762; x=1757341562; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=UpGPCVo0O2UxfenHY1cBlPDMbjb8GNJeXc8iIh5vx2U=; b=ENhqS4USUT3wHKC4NOxmF7c4v/nu3+qPGv/mejAVRiuHphowDVHYKE6fODC6Z1mM1l 0kECFKJBFEhUWn5X272rrMpbCwlxRJXFDF7/9r44k9fDF0aSyN3T37rsjbO5PcJxMsBk AqpWoXr966K1dOT2QLGiKRA/BGKoX1LrPELfj2JbEoJmcSBV3nCjz1TRNpEG9/SufxVc xQh3db+cC3QoUOAk06KvjIEdPk/hH4klN3GkF0HDaRI5reg2+3TCzwsETUq86+2wa9s2 TYeag5fvlVgTvNHuOav8ZA30MxGWnahySF5Wb9YxXjgOF3wHkt/JeBI2GcuMHD63sU8P moQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756736762; x=1757341562; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UpGPCVo0O2UxfenHY1cBlPDMbjb8GNJeXc8iIh5vx2U=; b=c5X66se02g/WRabNElpgNVTdJlh44SJnqCGOkZB84WsGZiNPY9kfxvtw1uLOZ+J/m5 s1NjLneU6v4bB+gs/L0jrDNK8OJ4IZm+oe7HYJcMebLtdr36/SqtjG4YAQ5R/JrxrPGK PLsoeN9qGGUPmGlRvKxxwBxTTEl/8uI2pLwCG8CYEKdjYzBbWzafMOJCKMug1ERkPxvP rtbOU1DvV/CxyowLSb/SlLILOowr9z8c/xuCyUmlQ3MIGYvhnUqyX0ZwGSUPUXviJZlp 7jLm6ctcW/Xz6ojp3YGp4esqwcr+18lLwrRsqWH1xu5xAO/tseCtaYWigcrtQivvawad QqUA== X-Forwarded-Encrypted: i=1; AJvYcCWfyjYZEZBO5R51xpBRSg1v5ZYPwRSkolP66gyRnNoNcoq2911ZiGV6u+D+Wkm+PrlbUurxEx6/ohw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzyvw9IZyJt0TEMz+hNWMcyuSsm/nvrUWFo+7B3Im/vp8TZ2pyz 8UwF1Swjss3ai3uBhTtQHshL1SiWI1xrHzCbgldMb/ibCSVLm9eY2kl1mpZofjkXVw== X-Gm-Gg: ASbGnctmDsDOqLtXGhcQW8ZOKmP0jHUbKjGFFhUR3kh3L26VY4Q1+ZIgkXE0tNylU5K 84lasuuSJpuyU4LgjtRrUmiPtw1wWw69Vo1DnWzfiuwVG1b5acTy58LhcBP25ZCbXJEWmMHMgAT ExqRfboXZdV47eBfXU3tDzSs4k05pUuhlTt7ZYA24Ke1DE2nnsvFsaS6VxWXhIvCbOF0VHB5FvB 2Hsgyn4kZ60kdT/Ef7tvSRtX1PWI2L3PJ2T7F+67uOHbGqRjy42tFPE9siop7lhyDhi6mWZTjWZ ZRlQ91f5PKIHJOHG8TEpu3kUkarwUDoQbqd1FlvxF+diWw9aYOV361Pdw2uaJ7NOnuvjX5Sz3xH dm7FfmsOo4y+Qtw1cU6yjSzizZgxT1dysgs3yQ1lsMIDbAF34+pchNiHq0fNf/gawg7jmoWRkVZ 7oj2+1Ns8= X-Google-Smtp-Source: AGHT+IH1KgVa6W8gM056VpZ8Dk48jp72aIfF/qMDLeQwX93u36FLT1uAUXCpqo4cQAL9ylaRR/bkyQ== X-Received: by 2002:a17:907:6095:b0:afe:bbbf:f002 with SMTP id a640c23a62f3a-b01f20bfbffmr952566366b.62.1756736762147; Mon, 01 Sep 2025 07:26:02 -0700 (PDT) Message-ID: <8e7293e9-6479-4904-8072-8eec9f1d5751@suse.com> Date: Mon, 1 Sep 2025 16:26:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/bitops: Optimise arch_ffs{,l}() 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> <20250826174135.605220-1-andrew.cooper3@citrix.com> <3ec7b53e-aef6-4a00-acb3-19cbbe6543c9@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 01.09.2025 16:21, Andrew Cooper wrote: > On 27/08/2025 8:52 am, Jan Beulich wrote: >> On 26.08.2025 19:41, Andrew Cooper wrote: >>> --- a/xen/common/bitops.c >>> +++ b/xen/common/bitops.c >>> @@ -97,14 +97,14 @@ static void __init test_for_each_set_bit(void) >>> if ( ui != ui_res ) >>> panic("for_each_set_bit(uint) expected %#x, got %#x\n", ui, ui_res); >>> >>> - ul = HIDE(1UL << (BITS_PER_LONG - 1) | 1); >>> + ul = HIDE(1UL << (BITS_PER_LONG - 1) | 0x11); >>> for_each_set_bit ( i, ul ) >>> ul_res |= 1UL << i; >>> >>> if ( ul != ul_res ) >>> panic("for_each_set_bit(ulong) expected %#lx, got %#lx\n", ul, ul_res); >>> >>> - ull = HIDE(0x8000000180000001ULL); >>> + ull = HIDE(0x8000000180000011ULL); >>> for_each_set_bit ( i, ull ) >>> ull_res |= 1ULL << i; >> How do these changes make a difference? Apart from ffs() using TZCNT, ... >> >>> @@ -127,6 +127,79 @@ static void __init test_for_each_set_bit(void) >>> panic("for_each_set_bit(break) expected 0x1008, got %#x\n", ui_res); >>> } >>> >>> +/* >>> + * A type-generic fls() which picks the appropriate fls{,l,64}() based on it's >>> + * argument. >>> + */ >>> +#define fls_g(x) \ >>> + (sizeof(x) <= sizeof(int) ? fls(x) : \ >>> + sizeof(x) <= sizeof(long) ? flsl(x) : \ >>> + sizeof(x) <= sizeof(uint64_t) ? fls64(x) : \ >>> + ({ BUILD_ERROR("fls_g() Bad input type"); 0; })) >>> + >>> +/* >>> + * for_each_set_bit_reverse() - Iterate over all set bits in a scalar value, >>> + * from MSB to LSB. >>> + * >>> + * @iter An iterator name. Scoped is within the loop only. >>> + * @val A scalar value to iterate over. >>> + * >>> + * A copy of @val is taken internally. >>> + */ >>> +#define for_each_set_bit_reverse(iter, val) \ >>> + for ( typeof(val) __v = (val); __v; __v = 0 ) \ >>> + for ( unsigned int (iter); \ >>> + __v && ((iter) = fls_g(__v) - 1, true); \ >>> + __clear_bit(iter, &__v) ) >>> + >>> +/* >>> + * Xen doesn't have need of for_each_set_bit_reverse() at present, but the >>> + * construct does exercise a case of arch_fls*() not covered anywhere else by >>> + * these tests. >>> + */ >>> +static void __init test_for_each_set_bit_reverse(void) >>> +{ >>> + unsigned int ui, ui_res = 0, tmp; >>> + unsigned long ul, ul_res = 0; >>> + uint64_t ull, ull_res = 0; >>> + >>> + ui = HIDE(0x80008001U); >>> + for_each_set_bit_reverse ( i, ui ) >>> + ui_res |= 1U << i; >>> + >>> + if ( ui != ui_res ) >>> + panic("for_each_set_bit_reverse(uint) expected %#x, got %#x\n", ui, ui_res); >>> + >>> + ul = HIDE(1UL << (BITS_PER_LONG - 1) | 0x11); >>> + for_each_set_bit_reverse ( i, ul ) >>> + ul_res |= 1UL << i; >>> + >>> + if ( ul != ul_res ) >>> + panic("for_each_set_bit_reverse(ulong) expected %#lx, got %#lx\n", ul, ul_res); >>> + >>> + ull = HIDE(0x8000000180000011ULL); >>> + for_each_set_bit_reverse ( i, ull ) >>> + ull_res |= 1ULL << i; >> ... even here the need for the extra setting of bit 4 remains unclear to >> me: The thing that was missing was the testing of the reverse for-each. >> You mention the need for an asymmetric input in the description, but isn't >> that covered already by the first test using 0x80008001U? > > The first test covers {arch_,}f[fl]s() only.  It happens to be safe to > count-from-the-wrong-end bugs, but that was by chance. > > The second test covers {arch_,}f[fs]sl() only.  They are unsafe WRT > symmetry, and disjoint (coverage wise) from the first test. > > The third test, while the same as the second test on x86, isn't the same > on arm32. > > > Just because one test happens to be safe (symmetry wise) and passes, > doesn't make the other variants tested. Hmm, okay, it is of course in principle possible that one flavor is screwed while the other isn't. Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:29:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:29:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104983.1455978 (Exim 4.92) (envelope-from ) id 1ut5Ww-0000Xu-Rg; Mon, 01 Sep 2025 14:29:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104983.1455978; Mon, 01 Sep 2025 14:29:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5Ww-0000Xn-P8; Mon, 01 Sep 2025 14:29:10 +0000 Received: by outflank-mailman (input) for mailman id 1104983; Mon, 01 Sep 2025 14:29: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 1ut5Wv-0000Xh-1Z for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:29:09 +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 0443ecb8-8740-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 16:29:06 +0200 (CEST) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-61e8fe26614so2394227a12.1 for ; Mon, 01 Sep 2025 07: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 4fb4d7f45d1cf-61cfc1c7caesm7206122a12.9.2025.09.01.07.29.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07: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: 0443ecb8-8740-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756736946; x=1757341746; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=TzOk6SAA6p957knAbsW86a3TWL0WMTG76ApNaL0LRxg=; b=gq7yCcNKfmmugQmIUA88/yUDHuRR2w2BE0GZEFmwWomucVQjMnKE2iQWm+Jmkqlt8F wDQ3ne17yvWp0k76N1mAf2xDwznMswtyPwNAyjlBzT38VrBlOnngFyuw5aKq3hi6+C+q HZGqfqxmsUzy9kYEK6adFGyFCt/utkw93DuCh2vNZSvoa78XutwzcdhfqA5fF6sZpzy0 JyBpZvvwD7/uFKjCV8Dp88HUPu9jw3WV9Z3JyBZWZsFpCU0+BB+/QrhzWSvfZD+mUNad NXrT7IYIoLAGI5CMQ6AnFqQL/J0IA3bEXUFF6awv4RF5Blf85he0UUKTCW+0Q2BIoLzM +bAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756736946; x=1757341746; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TzOk6SAA6p957knAbsW86a3TWL0WMTG76ApNaL0LRxg=; b=CZueo4pujn0lSb0tdczm3cEtjyXuDhHluw3WL3VNKVWnAM+SAeiymdOxoVhoQGnr9j RugRlqMrJhbJUIcRZ4yVoH1/k5NBMlWYja1HfHXM7tYjazSyVe/g/4t/DhNx+3tuqNir jLdcQFdDszzE2qY0zZr8jSyf1e4oCAoFkPPf4ozNFoQZVLix6kZ1tJhV6VTGypXKiM56 Urd5Wpv+drC88AVZM3TXrP4SKyJzw5G2UJHZiC0qODwIVLQxGBBAZVWfHnQJ4aY6Vg2X kH+AzwTCjnI4674ewxewXQInk2wz55JTtQZO6evpV+ASta3r6PHTOUonIM1v1tRvDq+A z6dA== X-Forwarded-Encrypted: i=1; AJvYcCVXHRjXwQ0nSWfLzEPhPq/Pi72bVPKhEpVgxdfPqh0IyEd6ntN/LiWx4VCmk4h7yvWohXLFL5PnyEg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yypp8KNE45i9fGhYf55/irEyZmMjtZmh9Dyxok+8Alf8u6Lvv61 LLN+dGbAjZNg6pCmJLazZaVAl/uZkSzOSoXCIYqh5DNVxpPCw82PAyaaeMqpDyJGsg== X-Gm-Gg: ASbGncstfXtJcs92fbHU/grCOEIBAterpeKOaVf4YyeNmI90EX72xMQTxUTS1o1jw2s Ef5/rK6VQM5A57ayjfgyFFqAMK99urjQAvoWJ1Fwqc62ZfZQihWMp+J3qre7P/qajPy1v86SxtI cNSRZ53pXLSI2IK+mQwjuhFjZ4E+hn9NveMMJeT3hWChfHlTH8PV+G7hQ1+DbZgHNE/5SQklUVl oCJ+6vRn3InqCB2BorW2KoExzLqbYfCclndvlthoIAf4fwpNBtY9x8kanX0dFp3O1aUlsraUd8M ctZhjiB8bNvl6ek868Jb2jkJhG2UU3EBQ9H9jX8uE2PoT+qk6Bn7zMqWOkVXBMKXat+FBEsJ0kT Bn+1ZPDc+IbHK+WBVaap6lHyQBsoqPSf/vctgV2KOGBG5LQFE1f+A+LIp6+23/tWCBr96u7Qlsf aAQexhBaevcSf/x4hwNg== X-Google-Smtp-Source: AGHT+IHomgltNeSgGJ37rb5UidC9NcBbWlBsPq4xhYChXEAovcS5A9yVCJ8PstwNTvYWlvkt32ODjw== X-Received: by 2002:a05:6402:2714:b0:61d:feb:67fb with SMTP id 4fb4d7f45d1cf-61d26d9c672mr6071722a12.34.1756736946254; Mon, 01 Sep 2025 07:29:06 -0700 (PDT) Message-ID: <80c8dbfe-5240-441d-84fc-603e9c5f9812@suse.com> Date: Mon, 1 Sep 2025 16:29:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Mykola Kvach Cc: Mykola Kvach , 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: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.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: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 31.08.2025 00:10, Mykola Kvach wrote: > --- a/xen/arch/ppc/stubs.c > +++ b/xen/arch/ppc/stubs.c > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *d) > BUG_ON("unimplemented"); > } > > +int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > + > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > { > BUG_ON("unimplemented"); > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > index 1a8c86cd8d..52532ae14d 100644 > --- a/xen/arch/riscv/stubs.c > +++ b/xen/arch/riscv/stubs.c > @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain *d) > BUG_ON("unimplemented"); > } > > +int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > + > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > { > BUG_ON("unimplemented"); > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index 19fd86ce88..94a06bc697 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct domain *d) > hvm_domain_creation_finished(d); > } > > +int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > + > #ifdef CONFIG_COMPAT > #define xen_vcpu_guest_context vcpu_guest_context > #define fpu_ctxt fpu_ctxt.x I definitely don't like this redundancy, and even less so that you introduce out- of-line calls. > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -109,6 +109,8 @@ int arch_domain_soft_reset(struct domain *d); > > void arch_domain_creation_finished(struct domain *d); > > +int arch_domain_resume(struct domain *d); I think this wants to move to a per-arch header, presence of which is checked by has_include(), with an inline fallback define once centrally here. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:31:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:31:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1104995.1455988 (Exim 4.92) (envelope-from ) id 1ut5ZT-0002LW-7z; Mon, 01 Sep 2025 14:31:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1104995.1455988; Mon, 01 Sep 2025 14:31: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 1ut5ZT-0002LP-5Q; Mon, 01 Sep 2025 14:31:47 +0000 Received: by outflank-mailman (input) for mailman id 1104995; Mon, 01 Sep 2025 14:31: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 1ut5ZS-0002LJ-Ll for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:31:46 +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 62e9f547-8740-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 16:31:45 +0200 (CEST) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-45b7c01a8c1so34786255e9.2 for ; Mon, 01 Sep 2025 07:31:45 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b88007a60sm52753145e9.8.2025.09.01.07.31.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07:31: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: 62e9f547-8740-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756737105; x=1757341905; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=bFmh8a9chimW6esJdhdUgmC0isdOeT0nddV4vpZ7LOE=; b=GGuSWQsEUgFyqKvw1i5S8Hj4BNbCuLFnXY+xPL+5HTDs7aXjthDSSlRJ9eTqC2VWyh U3ZyEDZpuxVKZH9yxjH3YdyqTTOvulXJIoOVJjFd3FhdyWw+PEsOtITpEiJNTwN/HZX5 KxHMeIGv/ZBmEY9v97xzmBYqcFRNLoJCCTLiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756737105; x=1757341905; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bFmh8a9chimW6esJdhdUgmC0isdOeT0nddV4vpZ7LOE=; b=MTo2bZ1er4zsQK6zeyptX1mTy3gERofPQe+5zUE6sfhnYlJcQyHk88htiwrmX7UclM 0gqoq8rPSMg4ma07DWWxzJ0l06jT4iGElqTHzUW7sn6Pmcw19WKOYePDfaQYwZwuGWE2 Kd7wjUZDni93mpNNCbTWzMM710oQIhU2JwIJfDYYQ2ZpIff4SbK5SBevrfQEaF8VMLJa hd7JT+6CKtAdwNWs4hwJ6u0KPNd1qVxSFl/hBD8r4YEn0WgiSblCeMdf1dhN2lFoehla 0q47d26tzt88/NaWxNKhISSuHapWAlWi6CTldQUYoOTer+FkHA3/cD667CZUcPKArcKp lpBg== X-Forwarded-Encrypted: i=1; AJvYcCUAYBHLQyy6khmm6+hBem2bJAGGS3+zp+ZHK5EMIewxv/K5sZq88DJSlic5RHYzYCC5MNJpq/hmhUo=@lists.xenproject.org X-Gm-Message-State: AOJu0YyXLRfV5nJcEfPnh1rhYJjFBB7kP9IIU/V5iMVXiA4ejMQwyEHh 1aR2cOYQKptJQ7wbVqjz2vlCJ06c1jxJ5oNcwXoEMbZRzccf518IRMxtevA+EJID7yA= X-Gm-Gg: ASbGncvsAXxqJVx5YcxQXs3rGiBAGxiZXdnDT6Rb+wZYU1Hz36GWzk1fhh+SGumlvwt QhR7bNgy690bYpf586MD192kGYCLYGZRmVqP+ggsIYD94YRvl7fnHk1WsS5wYq7weNb0H4yj4Wk KV1Lf4STMfFx+olDqiwFKZKaw9ozHlyk5IBFSAlqyMxgrhGZP8qfqR4kHjRdo7kpO3S1VKmh9gX fL7K3nZI6KhE3eEbZm5JDlEMUAuhuB8HCe5yMhSkxte75xv4HrKRzNVTH6HXsbKQC3KOQgmHkQ+ Sg/2Qn9U7ECQfI2oanU9LT9Cg3t7YxnE5vUfeFt2MRl3uvWF+0wnIAwIR8ohVOYEzxvl6LFwgiU nLv0Jtn+ohONhmuz8tzG1n/XGm9T2S0gl7UWrS3QpZNsyH41kgit/i/dPBDBniqjMSiQDjd7kJD 9n4rg= X-Google-Smtp-Source: AGHT+IHWx7+ri0j42pnbBodsFJv42PJMV2M4HVqdzhsAnG7Wi/ZLfcR3NQd3U1Kr/S4gyrWYindzZw== X-Received: by 2002:a05:600c:c4a1:b0:45b:84b1:f638 with SMTP id 5b1f17b1804b1-45b8559babbmr54701115e9.20.1756737105182; Mon, 01 Sep 2025 07:31:45 -0700 (PDT) Message-ID: <33ad597d-82e1-4e74-971b-0afee9307a55@citrix.com> Date: Mon, 1 Sep 2025 15:31:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/bitops: Optimise arch_ffs{,l}() some more on AMD To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250527222930.1452674-1-andrew.cooper3@citrix.com> <20250826174135.605220-1-andrew.cooper3@citrix.com> <3ec7b53e-aef6-4a00-acb3-19cbbe6543c9@suse.com> <8e7293e9-6479-4904-8072-8eec9f1d5751@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: <8e7293e9-6479-4904-8072-8eec9f1d5751@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/09/2025 3:26 pm, Jan Beulich wrote: > On 01.09.2025 16:21, Andrew Cooper wrote: >> On 27/08/2025 8:52 am, Jan Beulich wrote: >>> On 26.08.2025 19:41, Andrew Cooper wrote: >>>> --- a/xen/common/bitops.c >>>> +++ b/xen/common/bitops.c >>>> @@ -97,14 +97,14 @@ static void __init test_for_each_set_bit(void) >>>> if ( ui != ui_res ) >>>> panic("for_each_set_bit(uint) expected %#x, got %#x\n", ui, ui_res); >>>> >>>> - ul = HIDE(1UL << (BITS_PER_LONG - 1) | 1); >>>> + ul = HIDE(1UL << (BITS_PER_LONG - 1) | 0x11); >>>> for_each_set_bit ( i, ul ) >>>> ul_res |= 1UL << i; >>>> >>>> if ( ul != ul_res ) >>>> panic("for_each_set_bit(ulong) expected %#lx, got %#lx\n", ul, ul_res); >>>> >>>> - ull = HIDE(0x8000000180000001ULL); >>>> + ull = HIDE(0x8000000180000011ULL); >>>> for_each_set_bit ( i, ull ) >>>> ull_res |= 1ULL << i; >>> How do these changes make a difference? Apart from ffs() using TZCNT, ... >>> >>>> @@ -127,6 +127,79 @@ static void __init test_for_each_set_bit(void) >>>> panic("for_each_set_bit(break) expected 0x1008, got %#x\n", ui_res); >>>> } >>>> >>>> +/* >>>> + * A type-generic fls() which picks the appropriate fls{,l,64}() based on it's >>>> + * argument. >>>> + */ >>>> +#define fls_g(x) \ >>>> + (sizeof(x) <= sizeof(int) ? fls(x) : \ >>>> + sizeof(x) <= sizeof(long) ? flsl(x) : \ >>>> + sizeof(x) <= sizeof(uint64_t) ? fls64(x) : \ >>>> + ({ BUILD_ERROR("fls_g() Bad input type"); 0; })) >>>> + >>>> +/* >>>> + * for_each_set_bit_reverse() - Iterate over all set bits in a scalar value, >>>> + * from MSB to LSB. >>>> + * >>>> + * @iter An iterator name. Scoped is within the loop only. >>>> + * @val A scalar value to iterate over. >>>> + * >>>> + * A copy of @val is taken internally. >>>> + */ >>>> +#define for_each_set_bit_reverse(iter, val) \ >>>> + for ( typeof(val) __v = (val); __v; __v = 0 ) \ >>>> + for ( unsigned int (iter); \ >>>> + __v && ((iter) = fls_g(__v) - 1, true); \ >>>> + __clear_bit(iter, &__v) ) >>>> + >>>> +/* >>>> + * Xen doesn't have need of for_each_set_bit_reverse() at present, but the >>>> + * construct does exercise a case of arch_fls*() not covered anywhere else by >>>> + * these tests. >>>> + */ >>>> +static void __init test_for_each_set_bit_reverse(void) >>>> +{ >>>> + unsigned int ui, ui_res = 0, tmp; >>>> + unsigned long ul, ul_res = 0; >>>> + uint64_t ull, ull_res = 0; >>>> + >>>> + ui = HIDE(0x80008001U); >>>> + for_each_set_bit_reverse ( i, ui ) >>>> + ui_res |= 1U << i; >>>> + >>>> + if ( ui != ui_res ) >>>> + panic("for_each_set_bit_reverse(uint) expected %#x, got %#x\n", ui, ui_res); >>>> + >>>> + ul = HIDE(1UL << (BITS_PER_LONG - 1) | 0x11); >>>> + for_each_set_bit_reverse ( i, ul ) >>>> + ul_res |= 1UL << i; >>>> + >>>> + if ( ul != ul_res ) >>>> + panic("for_each_set_bit_reverse(ulong) expected %#lx, got %#lx\n", ul, ul_res); >>>> + >>>> + ull = HIDE(0x8000000180000011ULL); >>>> + for_each_set_bit_reverse ( i, ull ) >>>> + ull_res |= 1ULL << i; >>> ... even here the need for the extra setting of bit 4 remains unclear to >>> me: The thing that was missing was the testing of the reverse for-each. >>> You mention the need for an asymmetric input in the description, but isn't >>> that covered already by the first test using 0x80008001U? >> The first test covers {arch_,}f[fl]s() only.  It happens to be safe to >> count-from-the-wrong-end bugs, but that was by chance. >> >> The second test covers {arch_,}f[fs]sl() only.  They are unsafe WRT >> symmetry, and disjoint (coverage wise) from the first test. >> >> The third test, while the same as the second test on x86, isn't the same >> on arm32. >> >> >> Just because one test happens to be safe (symmetry wise) and passes, >> doesn't make the other variants tested. > Hmm, okay, it is of course in principle possible that one flavor is screwed > while the other isn't. > > Acked-by: Jan Beulich Thanks, but I now have both R-by and A-by you on this patch.  Which would you prefer? ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:34:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:34:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105009.1455998 (Exim 4.92) (envelope-from ) id 1ut5bb-0002rx-JY; Mon, 01 Sep 2025 14:33:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105009.1455998; Mon, 01 Sep 2025 14: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 1ut5bb-0002rq-Gt; Mon, 01 Sep 2025 14:33:59 +0000 Received: by outflank-mailman (input) for mailman id 1105009; Mon, 01 Sep 2025 14: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 1ut5ba-0002ri-Mq for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:33:58 +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 b1723494-8740-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 16:33:57 +0200 (CEST) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-61cc281171cso7508754a12.0 for ; Mon, 01 Sep 2025 07:33: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 4fb4d7f45d1cf-61cfc1c7848sm7593361a12.2.2025.09.01.07.33.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07: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: b1723494-8740-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756737237; x=1757342037; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=a7lB359ETCGiG9kQCfcmnUl1OXWX0fwwbYZJASA5IX0=; b=ZFS1qpw1tAWWw1HcUjxYuzBaQCqi71mlt2gsuLwSbCVIedgZx6SwgUi6J1Q9L9as9M SsdLRuGcM9HF4hR2goiNDvNSiKYGotMMBjnYbiSdcQrTx7KrAB41cG4ojWucfU89X4dr nDQ2BCCYpzKiLp2WffAYz4/O8NKSpNhi/EVGSPQ6F67YOz0Gx97TTjHuanQ3V2vOd7/U 6VE504DagyOhHXMwXpefaoWRXMUrF+kRy8cNlliftAMluIA/BwLn/4SIlq5Ado2b5U6A c6Npb6GLiAloLh3p8Qua+FkDK6bg+qrUEpzVwMbntwTZMKLCGiJ9mIvwCu0iAMbg9cOc WBaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756737237; x=1757342037; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a7lB359ETCGiG9kQCfcmnUl1OXWX0fwwbYZJASA5IX0=; b=RHAOOCKuBmze2asTNdWnxT9UBHRGCUDA9A73Mbq5i/LMxmQyN3fiLuUt09Lby208AH jV6ZQBlbBn0P45d2w32rzfunz+s5is0GVP78X6Sc6K7ZEmwgUk2Xq4J8fhKuL05pABAt 1XRQl+Pp4uLFUHMSzwgubEL8/FxnU4P6OPKiBMzEREDrR7ALeNdx2VYEYVhIAyp1+O1r YXwbAnU8zgdRGNCslwO5G7Ka7m6312S+jbPce6H1n7YrCK52Je/FJ18ZOgSrjZys/3BD 3thoxnwU+ykhdl/glEGJtnvzzDlZuEwDIkEZzo8D4GB7ZAFg2IjFfFPWIoNquJYsJ3NA +R6g== X-Forwarded-Encrypted: i=1; AJvYcCWdIeMzkTD+bv6TdL69DrcSDmHT3bQ9TtgpB7Meu/ikz4OHUcjyE5Z1wMHcTTYM2BBUyp4YOtkQkP8=@lists.xenproject.org X-Gm-Message-State: AOJu0YytEpskHYPeo7QqUdurAdvFoptqfdje7Nva0xNrASqajythBn6K D8VcRvAtFQxNv445BbuW5nOD2PV1TJNE8Wit3Uf6uvB3M7XHNs4mDJvt1PUTWuCx+g== X-Gm-Gg: ASbGncusnw8oDgTt7Uwr+yI/KUX8Fak6UlD+49GNkMRCtZBetsB8MQUs5bP8m0Z6099 MbGXH/zCRl6zIAos06u/oWzi+Q7v77Qzf5tKne03pG30pnSlINoneApn6bgsHKF9HdZzVHTQFz+ CNhCieVZ/5bf95fRAXVA6Dgu+hr4N0YMuRoA+CzpQKs4tN7ooq52GitgCwNhKU+ePdZwsLckEFZ qbSIGcW0IbNxY0Emyl1N2JSs17H/NU8BVfcqbj7VQytVWPC3eu31a3QQcLycrNwR0uyR/Lr1Hgx 4rGutHWJIfukKUReV+TM2Oy6ndZv/3Fi9c92/+7XnY35ocdT5BqMFRKfQG5JeDytbUKtByyXp5F xqOxoaSEC6NxB0K2flJNvijCbboL1MudPcXvpr51hlm9bMSyu9RgnNnF7P+PVmjdxerGaiCUK1/ LehJ9Vl7uibmITYaApxQ== X-Google-Smtp-Source: AGHT+IGvf8w1reX8IyfP+pyiLLuey9HpirPMXoN8K5vaDD6ZyHpdiLS5XzBeq904yNOBZA31nchdUA== X-Received: by 2002:a05:6402:d0d:b0:608:f493:871c with SMTP id 4fb4d7f45d1cf-61d26aa2be2mr6781682a12.14.1756737237004; Mon, 01 Sep 2025 07:33:57 -0700 (PDT) Message-ID: <3ab662ea-295d-4796-9bf9-d16b5ec0cb46@suse.com> Date: Mon, 1 Sep 2025 16:33:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 3/3] x86/hvm: Introduce Xen-wide ASID allocator To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Vaishali Thakkar , Oleksii Kurochko , xen-devel@lists.xenproject.org References: <81169a40fdc8c124b1656e451ac2e81f4e8edd2d.1750770621.git.teddy.astie@vates.tech> <7d9fd72a-39b7-43b0-875f-859a7a45c4fb@suse.com> <2c16b9f8-580e-4df2-9790-1c3e327b349d@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: <2c16b9f8-580e-4df2-9790-1c3e327b349d@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29.08.2025 16:13, Teddy Astie wrote: > Le 28/08/2025 à 15:05, Jan Beulich a écrit : >> On 26.06.2025 16:01, Teddy Astie wrote: >>> 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. >> >> No, how would two entities be able to run on a single pCPU at any single >> point in time? >> > > It was more concerning regarding having 2 vCPUs of the same domain (thus > sharing the same ASID) running consecutively, e.g having on the same core > dom1.vcpu1 -> dom1.vcpu2 > > without a appropriate TLB flush; because the address space may not be > consistent between 2 vCPUs. > > I found a approach to fix it by tracking per domain which vCPU last ran > on each pCPU so that in case of mismatch, we need to TLB flush. Along > with explictely flush the TLB when the vCPU is migrated, because in the > case too the TLB can be inconsistent for the ASID. Yet that wants constraining to the case where the address spaces are indeed at risk of being different, i.e. when distinct P2Ms are in use on the two vCPU-s. >>> 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 >> >> For these last two points - maybe we really need a mixed model? >> > > Mixed model would not allow future support for broadcast TLB > invalidation (even for hypervisor use) with e.g AMD INVLPGB or (future) > Intel Remote Action Request. Why? For a VM using the traditional model we wouldn't be able to leverage those, but for others we could. And imo it's better to be able to run a VM at all, even if not with all possible accelerations, than to refuse running it. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:35:42 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:35:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105020.1456009 (Exim 4.92) (envelope-from ) id 1ut5dE-0003O6-UL; Mon, 01 Sep 2025 14:35:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105020.1456009; Mon, 01 Sep 2025 14:35:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5dE-0003Nz-Rc; Mon, 01 Sep 2025 14:35:40 +0000 Received: by outflank-mailman (input) for mailman id 1105020; Mon, 01 Sep 2025 14: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 1ut5dD-0003Np-DE for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:35:39 +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 ed262057-8740-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 16:35:37 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-b0431c12df3so141402266b.1 for ; Mon, 01 Sep 2025 07:35: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 a640c23a62f3a-b0416e878a2sm420837566b.95.2025.09.01.07.35.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 07:35: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: ed262057-8740-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756737337; x=1757342137; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=W8Vq3X22cq1z0AO8Qpb5DTb9Jg/EwQI2gYZ3eSHW/1k=; b=EiRZruzwbOhXGVizEyVAmrGfEqddbE3rB/cfSTs15aVRebQy19jKfKdlwrWGcY9UM+ RoeEI/J8hIEY1iIIESgOen6wflkzojIa+0FUYyKwYsy3VwRxojlFgyOjiGSN5G4zPgS4 90oYYctYrs8Dt/XNhsWo9D7U+zfWIBc51IcLd6Oa9JubCBdT8t75Ol6anv+jruVwudxC EuI+ys4/jOhzO/dPxcFE1Awu0+7fagYPVeGVZCAYicb9lZTndAYS/SORN+KERGYu8H1R ot5MBAoeyc/XSbf/ldFcvWJDS49GfTFdFI5rvtz5fqax18Aj501IbMODtf8dBzli7JPc qK6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756737337; x=1757342137; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=W8Vq3X22cq1z0AO8Qpb5DTb9Jg/EwQI2gYZ3eSHW/1k=; b=UbSwMutfXsBR/LKrPndZdSu0G4zlWJLnkzMpzuoD0DctsnuNdaaoIKvYg75jK7GRCP x1aT7kr3zY0NdSlrmPhGsLJ8N45MSmD1pueUuH4S4j0wUwaBamuUy6zDbf0ik8SEgIjW n5gw+Qgr5jK7E48C1wTC+CIC0haSioRtQWzGIrFLxa2DtgEquAdXcak3/VHsihiJEH9l j3X4cdnafGDlTkHw31RsOyIa/xiC9xLm7TinrqhA8rN9oHc/Mo0xUzDPj519ka+ANneL UQ8Chiepz5kkxBr/8CevhfhvO0A5gjNzQ4MQvT+yY3TpijSfCwhMuOMbg8kECTlNeXnx T+1g== X-Forwarded-Encrypted: i=1; AJvYcCVUkIKD7yeEpOVwj8kj5fyncZ1G1mFhExE0mRoHdqsuMbGnxolXhte9DBuaK6b+PLjoG5VYpXUloQc=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywcl0YA/Cmue/a1GyyEMnsz109IGwfbEkAt9bq8tHB+MdiURYgT vaOwDRZikzPTy3pwBxrI2qcGAU3fDWy1lWWzb1nepOvYKXwOARWISu3l4dXP5vGH2Q== X-Gm-Gg: ASbGncssshnvGbm3D+RA0HFOs8QMK9pLeUQbo2mti7zZUGlka6ZkZKLBV9tAMfuu7oB D4ObzNaih1Y9dIMm9nSMYE5RDq5JRa4qpA6QD10r7nnP9aFv9BgELiycNR9jzKnisQu1xJdULCV idaq+AsJ1HXrEg8FxfK3Mp1xKe5DLUIEE/jtQxV2R6nUi5wQa8a/t5avSm/1sqJCaPCWL/EdDx/ NMopRcG6U4ygk4C6BdqUgAnvSXOgMZYlgl5UzE4xhXmgVB/tMmkHtgjBHCdMnKBHAiHQnEZRv/G MKvuMct0sJqrdDzEonqSdmm8e5RF5AjGN19qQkI3BVAmQrRda0bL1J9W5zT1IoodGxLK3u5TCf3 PKYKBVaEPlq/3xbQBERfx4kmmPsPYbsWVTUtKJbcJyxKfNe9xZ2ahVSPUimle5w6N09TcEXP8kT F4T5BoDG1OddfM2WYu+A== X-Google-Smtp-Source: AGHT+IGFCSfGNeTKZ90u4o1CV7D2UIcbc1x9pjjyayilYfz/BHb+rxWVZ0H5/Hp+0diyH0ATo8PVfw== X-Received: by 2002:a17:906:1c4b:b0:b04:20c0:b1f9 with SMTP id a640c23a62f3a-b0420c0b498mr404263166b.52.1756737337013; Mon, 01 Sep 2025 07:35:37 -0700 (PDT) Message-ID: <82d2264f-8d44-471b-875b-4b6f432a6f81@suse.com> Date: Mon, 1 Sep 2025 16:35:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/bitops: Optimise arch_ffs{,l}() 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> <20250826174135.605220-1-andrew.cooper3@citrix.com> <3ec7b53e-aef6-4a00-acb3-19cbbe6543c9@suse.com> <8e7293e9-6479-4904-8072-8eec9f1d5751@suse.com> <33ad597d-82e1-4e74-971b-0afee9307a55@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: <33ad597d-82e1-4e74-971b-0afee9307a55@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01.09.2025 16:31, Andrew Cooper wrote: > On 01/09/2025 3:26 pm, Jan Beulich wrote: >> Hmm, okay, it is of course in principle possible that one flavor is screwed >> while the other isn't. >> >> Acked-by: Jan Beulich > > Thanks, but I now have both R-by and A-by you on this patch.  Which > would you prefer? Oh, sorry, I checked whether I sent an ack to v2, not paying attention to v2 already having a tag. Please keep the R-b. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:36:29 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:36:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105030.1456019 (Exim 4.92) (envelope-from ) id 1ut5e1-0003uB-8i; Mon, 01 Sep 2025 14:36:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105030.1456019; Mon, 01 Sep 2025 14:36:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5e1-0003u4-5z; Mon, 01 Sep 2025 14:36:29 +0000 Received: by outflank-mailman (input) for mailman id 1105030; Mon, 01 Sep 2025 14:36: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 1ut5dz-0003ql-Gh for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:36:27 +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 09e5f06a-8741-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 16:36:25 +0200 (CEST) Received: from DU0PR03MB8669.eurprd03.prod.outlook.com (2603:10a6:10:3e9::19) by PA6PR03MB10405.eurprd03.prod.outlook.com (2603:10a6:102:3d4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 14:36:23 +0000 Received: from DU0PR03MB8669.eurprd03.prod.outlook.com ([fe80::ab7f:f6b5:4bb:3c43]) by DU0PR03MB8669.eurprd03.prod.outlook.com ([fe80::ab7f:f6b5:4bb:3c43%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 14:36:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09e5f06a-8741-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nv/KSRhzfDxUsxTWzGEyhAo0QFedyBGoiKMPa9u/vzvQwkV0f/XKa9rGDPE9Tpl9qwrfB0KGpE7QZpHhYIGXqAK4cCkAoTGpK2yu5mfkHkVbXiXhzxN3ijEPVOcnA2fdHg7XOn/6QoZ8xNP1fTpKInBzqmQNNixY3473Cskp67T7w1QmLV716V8YylVd16rF+jNPKh5nlwiNvZVD0SMFwaPnhlRXZPS2THeokxz8J1CCx0CqlYCLGg8FBZ3jNUGoyhKzfOJ2gNymLI+7+ClKZtadg2umpiU2dci5APggFhr7eHP6t66CCvfQ/sG7bmSEMFwgOV+3cBcK3gwmiL/J/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=BpHA77FoA/dMp3dtVdpxgHuimALEQLiUBFMnYv30Xkk=; b=VYcYfPAJFeWxctL11fUkIwswbcQXAtaSxloPRf3LQXQ6lRerDbWAhByXByl0D+4ochygWkwl6b+XWSkrkn9vYE6u8ieJNfYZU9pmc3Yuzp35qUV/LeMtBwM45NlX8yYl4S5u0REG5uUsPMWU3XZSTm9SX0m8Gk7Bjty3EbYfa7KWlEe2UykWW6E7W1F462bDTq/atmFwvkPxlNiF86IS5b9IIBPs7xgy5/J9nFhX+yNsOSsSGRzDMEbdJDUL8BfGcZFfGVOQeBwutrOSLrfRgONk+DWGunqGLS8AtRMKLxbbuzq4NYdmrpcp79u7NzOtesRel6QNP44SX8jmIfen1g== 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=BpHA77FoA/dMp3dtVdpxgHuimALEQLiUBFMnYv30Xkk=; b=IHhhs8H0RITFz+nW1FiJ7GelFwXPp5mmTTXrUzjC7R+ykUgQd3OEBB4guiRhOtwaPlsWF9CFREBkPaAjZGG2usw5nmJfEQwUGetsSS5iSsShVAtllMdL3+MKBQinXjTbAE+anrJcAkig1YSN7YZKT5xLguTc+5hRA+wkr9NgTPwpquKkpoON9kaHUDN85XuvRsRPEBvjxoHLIjOtMPNsTMDJA82RMsm8jfdQ1MdRtNSm6SYte36kY57Nd+Zdl/SH6jPjWIoCHqyR98N9z45XHudAujKRbdvpD+hR/xwy1aWAkEeKk5YB/SrbeTlAPPTuE9XLTdo0T/ABxXMvypYhQQ== From: Leonid Komarianskyi To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Julien Grall Subject: Re: [PATCH v5 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for common operations Thread-Topic: [PATCH v5 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for common operations Thread-Index: AQHcGP7VA43rYFd/50W5xNx+fBJnNrR8t04AgAGyRwA= Date: Mon, 1 Sep 2025 14:36:23 +0000 Message-ID: <72a5f0b9-2fef-4619-b8d9-0adb347bd35f@epam.com> References: <7da58b5a27d61f75eaebb749a7ab4c72655a12cb.1756481577.git.leonid_komarianskyi@epam.com> <5b4de10b-a69b-47bc-8ab7-d9e3ce514027@gmail.com> In-Reply-To: <5b4de10b-a69b-47bc-8ab7-d9e3ce514027@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: DU0PR03MB8669:EE_|PA6PR03MB10405:EE_ x-ms-office365-filtering-correlation-id: 5c1018a9-8f1a-4d88-2723-08dde964ecb6 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?c3EySXZjUTYvdzhxbXJ1WC9ZMzFNeFdvMXF1bGRpeEhKNlhwWkk1eS9od2g0?= =?utf-8?B?MDh4cXlQZUNOdmMxVFp2dXBHVnJ3Zjc5ZThjbEJvQU1zY3ovZjZpaHlXN1Q1?= =?utf-8?B?Nm14dk9XNFpjMmIxQ0YrVGkzVzI4QU5nRXhtbFdxaG1JM3dBdm5tejVlQ2hr?= =?utf-8?B?ZVo2b0xvUVpQZDlRc09KMXFkbHRoVTZzM1JMTHVLbnNNVXJwRWNDcWo4TUE3?= =?utf-8?B?SXJ0TVYvREJ4ZVh4UTNodjI2YjhuSXFPS1FKb1c0ZnkwbG13cWVaWE5hKzlT?= =?utf-8?B?Y0huVGJFdUkwdUNVbllWMW1wK3Uva0hHcGlZNlIxemxHNGUzdXhKeXBEa1hS?= =?utf-8?B?cjFvaTVhVWREM2s1R09wQUFzbS9mYk1yS0pSYjQ4WnRoaUNhblcvU1lSVnRz?= =?utf-8?B?NFhmdnF5V3dXTUN0bWNkV0FjQ2FvSGR1d1RYYUhVbXBMdVluR00ySDk0a3Jl?= =?utf-8?B?MXNYNjY4c21yRWFBZDZuMzFKQksyT2VkQmJZV3ZVZk1xUTJlbWVzaHBQY1Qr?= =?utf-8?B?Z1JiQ2Q1SnlobXg5SldlOFN3OGZhZ3QvMXJMdUplTmpxMlIrTkJhUTNFYUMw?= =?utf-8?B?NnpoS0JDZHBzUkpyR0xRa3I4TXcyTEZway8rM0N3bmoydjQ0eGNrYzRVbTlj?= =?utf-8?B?ditVREsvc3pSaGZaQ0l2YTl3bmhIZWo4SktHMUFFZVFwbllwcHFMTTZBbEw5?= =?utf-8?B?R2tzRithdTBnd2NmT1FIWHFzT2htbXhqUXU1YlU4cm5Qd2ZuSWw0Z3EyWWw5?= =?utf-8?B?eVpGblN5eTV6KzVZbDlBcHJsQWhScm0yMzlYb0ZJRTFzTkJFOWI1ZXpiQ1k4?= =?utf-8?B?Y3U0NnhTUld5ZU1XaWgzR2ZwTXlMWE56RTJwaExGNzdRb3Q3MWd3Q0k3c01x?= =?utf-8?B?a1hJOTJ4RGprZGdycUlDTnFLb1EycU4zZk9UV3BaQ3B5cTFueTdRTjBhTkJ3?= =?utf-8?B?ei90d2t6VnAxRzBPMnFVNDlCTzdScHNKK1lTelhiUCtRTXRwRjZhcWNVeEk5?= =?utf-8?B?MzVBRllscnhzRTFNRFhiRjVpcFhqaXNYV3F1aitHZTV0NVFIamdwbDBFOG9Q?= =?utf-8?B?T04zQnlKc1RLc3ROdjNmSWhHWW50RDFRSEpQQkxRdExUb05vV2RuOEdCcEhF?= =?utf-8?B?OXhVN25TV0R2UXcySDlnMkRBcE5vZldqQkJyeTBuSTdTY25wcnlPOU11RHlK?= =?utf-8?B?MmEzOEExelZ2QmlsU1RVYW9IdlBBMUZ4UC9kdVhIVGlET3pmRXViWUpTU29C?= =?utf-8?B?VzE1R1dVc1kvWU9yNDhuV29BZkFGSnFsMXFzdUhqR3BtcXduR2xEMkFPaWRv?= =?utf-8?B?RThRMVRwbTNZNjEzRE5MZWwzdk5aVXUvY3NOQ3kxam9vcUVqSmpqTll2ZWh0?= =?utf-8?B?cExZbHVNamI5ZlU0UTQ4ZGNBQnA5NDZFcWk4dndzeUQzOUxodUV3Y2tKK2Qw?= =?utf-8?B?YXdFdVl0d2JYNHVldllURkd3REtUUWJWTllRay9XUHpqVmpvTzV2dG5xazFC?= =?utf-8?B?ZjBtWjhXYnpoZnUrejA4WmpEWnEwZE5FN3Q5TStCekpjamRqOFk2a041dEk2?= =?utf-8?B?Zno0QlEwTXZXMWt0MHM3T3ArNklDdHFkeU5rOHF1SkFld3hRalFBUG5rSXVj?= =?utf-8?B?T2lzemluMFdVNklrUmI5MHhqRlRyYU5SMCt2V2ZLVHRNRG9jOWVlZFNjQTBG?= =?utf-8?B?clNVcW4yUlROVW4zM2dLT3phcVVJUWdSNkxUU2NzZ0xyaXVrRVVGak13akZy?= =?utf-8?B?R3hCQS96VGFmSkd2Qkd6bUd4NnpFWVlhd0VwR3VnTFA3SWorWnJsYW9vT2Zu?= =?utf-8?B?VlAwT3Vic2dCbWNOMWt0RTFQOXVrdzlITlF2ZDFuMkJjRFo0c1RVMHhseDZz?= =?utf-8?B?Y3BjYmYrVittaEV4UVdHRnRWZldmSVMrK29WSC8zVVFVTFdTdG9CaG1wQkc1?= =?utf-8?B?TUJldE1Rbmlva25JN3NQSE9ROGRtdktwT1htOHQ4NXE1Q0tZZkNybjFPZ3FF?= =?utf-8?B?bDFMZVZ3LzVBPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8669.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Rzc0b0hQbWU1am9Ra0RMTzFRSVhIeXZRcVZXdjg3VmdreVQ1Y0d5aDl0Rkpz?= =?utf-8?B?N1pmdEM3eUdaa3hjbTQ5USt0NU1EWFMvMWE2SnMwS3lhWGtpNGwzazFKcXl0?= =?utf-8?B?cC9SOS9QdFNRZzU4azJnOU1aK3pHUU44NnYvbmV2aUlrVVZybHB0THR0Qm10?= =?utf-8?B?SFdUcEpSZHBuOUhoZEZwems1Ty9TK1MrVnZkL29vdFVOUHo3UXNmaDJaNmpF?= =?utf-8?B?OU8zWFF3aHpzcFk5eDErTUJxVlh0S0UvbVpMVk5tM3QrSWpyVS9sVEhCaEQw?= =?utf-8?B?R0hVVm41a2Q4T2JEWkcwbHFLWWs5R0xFMFoxalZTcjdSbjZNMjU0Zmg3VXk5?= =?utf-8?B?NjJleTMzUk5ONys4NDdOUGNFRUIzd25CRVB1WEE4bjJzVXcyZHZ1amJSaFJo?= =?utf-8?B?MTJIUG9mMkVpSUE5bU50eStDbTVuK1BDdTZlOVN5ZU1JU0J3aFBUQ0tBaVVX?= =?utf-8?B?UFZMMTVYWWlNai9HTHFTY3ZOYVRQZ3MxWnhjU2JkNFFSamRJcVJyV0ZUQTdj?= =?utf-8?B?RzhxUkNqNTAzLzF6WitvSmpjSkg3Tm1KYm15WlZxU29tV2ZXN1lJdkdpUDBy?= =?utf-8?B?UXRRVDZUVE80MFYrVUt4NGJzeWJ3RlQ3UEVUWHo5MDFFMlJva1NxT09XT2Iy?= =?utf-8?B?NENoSzVsY01tTzk5elFncWx1N1prVEx5NmNWZUtXV3h0NHdOQ0hzUlN3aWs0?= =?utf-8?B?YmpLL1ZBTEh2YnNhYlVLeUpjelU2QVljcjVrdGhJMjh3NWw2dlgrdVJMMllo?= =?utf-8?B?NkI1UHhlbHQ2K2NETGl5M1pKV0thaGxDL21jUGRYS1cxcXlTcW9sZGdDV1d1?= =?utf-8?B?SWFVeFNxM0VHZTR5cjVseDJwM3h2L3BaMWVCY1l6VjdEcngvNWwwMXNLV0RP?= =?utf-8?B?d0g3MGh2K0t1S3RvVC9SYmlVVEVFSTF0MXJwZ1N4NDZaeWJmSVRaY0ZtbGpL?= =?utf-8?B?RnAvNXo3T1VGYUhjbm9oZUkxR000UHFudzMza0MrYVRqTmRPWXhLWU10cndF?= =?utf-8?B?aVBpVVZmUC9xYU5yNHUzMEVKTnhlY1lCdGY4eGJwcXdIbkY5ZmxoTGtkRk53?= =?utf-8?B?SWY3WHNaUjBlOXovSWtSbTZmd29HT05SSGlXZklpZldtaWlKaXJ6aXl4UmNB?= =?utf-8?B?YXM5bG5ZdG5YN1luNDhlalJMOHRNcGptY0VLaWYxc2kvZHAxT2x2SHU5eUkw?= =?utf-8?B?elV2Z3hCNnBBdjk0VWsycFNmZTVuQmtBY1FXUVhMVjF0ZlBxUTlyQW45MGYw?= =?utf-8?B?N1hCdlA5bjVHWDV1V0t2Y0RBbWhPTm1aTWJkVmFHTDZDL0lmV1dpZWlzZ25q?= =?utf-8?B?T21XSjU0L1JuaGIwbkFBbkdlVWFQbEtoRVRFeFdHampJSThwdGREL3JLRVk5?= =?utf-8?B?ajZFSlRNdDVobXlQUEhnMmtUWXg3NklwbnVMODV5WmtnQjFnR0dsY0ZCMmhP?= =?utf-8?B?WHhkUjM1R0FVTHVQdXZKY1piV25rUlhwM1JuMUIzb2h0bmFaZEdSRG1uMlNm?= =?utf-8?B?SkV6YW9xSFBaUGtvOWdmdDJtQ0IwcVRzaC9LUE9tVHY4U1ZHeWJSMkVFNWw3?= =?utf-8?B?NUZuaUZkbUpzY0g3Q3pneXpSaUI2TTRnZytUNUhWT1gvanlXT0VsRlVKZzVs?= =?utf-8?B?NldGcjNFL3padFBGQVBCMy9NT1VHZ3J3RHpGZmFxcDlHVURhR3VnZEc4amJj?= =?utf-8?B?a01sZVFJSVBJNnp4ZlViUlpqQ0VxZ0czelVqNnhRSGZBYUJWaW9NdWRMbnEy?= =?utf-8?B?MWlUVks4dUNGK09XdFhDdTI3Ujd5bXJQNUNFTEhiYTVTeitRWUYwZWJsWEhL?= =?utf-8?B?dmkyTTlLc2xzdUNYV3hhczg4SWRWeFJQWmxKY1lZeUJscWh5cWpaaWs3aDVM?= =?utf-8?B?S2ZxUEd1OVRWVVdCTGR5UnhBenNOWTJVVlROK2RNYzJWL2o0bGN4cTlHODQw?= =?utf-8?B?RXJhTlViTVFHT1NrN3JTWmMyYkQ3T21idTNYNjVLUHp0alpRcUtLcXBqMXE0?= =?utf-8?B?dFlucy9xekhMU3NWU1J0N1ozSHJvcm5Ed2NCWlVGT29IOFJQb2dPekptRGNz?= =?utf-8?B?akZFYjZjc0xac2hSSi9OQW0zWU91ME16N1FuZFZIa0pheU85VTlxSnRXSFhi?= =?utf-8?B?VUdVcmhLdUxWdmp4RlducTdvWVBmVFgydjlvdTg4RUxsaWptamRTTlBQbkRO?= =?utf-8?Q?yLL1IKxR8ej0Lash4vaLxHQ=3D?= 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: DU0PR03MB8669.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c1018a9-8f1a-4d88-2723-08dde964ecb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 14:36:23.3738 (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: XdowijPOmLsJFcFh0jcTe6e8yxDyCM0U8tW3t/QERMdCzM8DIXW4RyaiTgAgYKXeBdcE/3izZ4kGdqNzi9232sSEhZXBqcKZ+Fo0izV3gIk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR03MB10405 SGVsbG8gT2xla3NhbmRyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudCBhbmQgUkIuDQoN Ck9uIDMxLjA4LjI1IDE1OjQyLCBPbGVrc2FuZHIgVHlzaGNoZW5rbyB3cm90ZToNCj4gDQo+IA0K PiBPbiAyOS4wOC4yNSAxOTowNiwgTGVvbmlkIEtvbWFyaWFuc2t5aSB3cm90ZToNCj4gDQo+IEhl bGxvIExlb25pZA0KPiANCj4gDQo+PiBDdXJyZW50bHksIG1hbnkgY29tbW9uIGZ1bmN0aW9ucyBw ZXJmb3JtIHRoZSBzYW1lIG9wZXJhdGlvbnMgdG8gY2FsY3VsYXRlDQo+PiBHSUMgcmVnaXN0ZXIg YWRkcmVzc2VzLiBUaGlzIHBhdGNoIGNvbnNvbGlkYXRlcyB0aGUgc2ltaWxhciBjb2RlIGludG8N Cj4+IGEgc2VwYXJhdGUgaGVscGVyIGZ1bmN0aW9uIHRvIGltcHJvdmUgbWFpbnRhaW5hYmlsaXR5 IGFuZCByZWR1Y2UgDQo+PiBkdXBsaWNhdGlvbi4NCj4+IFRoaXMgcmVmYWN0b3JpbmcgYWxzbyBz aW1wbGlmaWVzIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBlU1BJIHN1cHBvcnQgaW4gDQo+PiBmdXR1 cmUNCj4+IGNoYW5nZXMuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogTGVvbmlkIEtvbWFyaWFuc2t5 aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4NCj4+IFJldmlld2VkLWJ5OiBWb2xvZHlt eXIgQmFiY2h1ayA8dm9sb2R5bXlyX2JhYmNodWtAZXBhbS5jb20+DQo+PiBBY2tlZC1ieTogSnVs aWVuIEdyYWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4NCj4gDQo+IFJldmlld2VkLWJ5OiBPbGVrc2Fu ZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5c2hjaGVua29AZXBhbS5jb20+DQo+IA0KPiB3aXRo IG9uZSBOSVQgLi4uDQo+IA0KPj4NCj4+IC0tLQ0KPj4gQ2hhbmdlcyBpbiBWNToNCj4+IC0gZml4 ZWQgYSBtaW5vciBuaXQ6IGNoYW5nZWQgJWQgdG8gJXUgaW4gdGhlIHdhcm5pbmcgbWVzc2FnZSBi ZWNhdXNlIHRoZQ0KPj4gwqDCoCBJUlEgbnVtYmVyIGNhbm5vdCBiZSBsZXNzIHRoYW4gemVybw0K Pj4gLSBhZGRlZCBhY2tlZC1ieSBmcm9tIEp1bGllbiBHcmFsbA0KPj4NCj4+IENoYW5nZXMgaW4g VjQ6DQo+PiAtIG5vIGNoYW5nZXMNCj4+DQo+PiBDaGFuZ2VzIGluIFYzOg0KPj4gLSBjaGFuZ2Vk IHBhbmljKCkgaW4gZ2V0X2FkZHJfYnlfb2Zmc2V0KCkgdG8gcHJpbnRpbmcgd2FybmluZyBhbmQN Cj4+IMKgwqAgQVNTRVJUX1VOUkVBQ0hBQkxFKCkNCj4+IC0gYWRkZWQgdmVyaWZpY2F0aW9uIG9m IHJldHVybiBwb2ludGVyIGZyb20gZ2V0X2FkZHJfYnlfb2Zmc2V0KCkgaW4gdGhlDQo+PiDCoMKg IGNhbGxlcnMNCj4+IC0gbW92ZWQgaW52b2NhdGlvbiBvZiBnZXRfYWRkcl9ieV9vZmZzZXQoKSBm cm9tIHNwaW5sb2NrIGd1YXJkcywgc2luY2UNCj4+IMKgwqAgaXQgaXMgbm90IG5lY2Vzc2FycnkN Cj4+IC0gYWRkZWQgUkIgZnJvbSBWb2xvZHlteXIgQmFiY2h1aw0KPj4NCj4+IENoYW5nZXMgaW4g VjI6DQo+PiAtIG5vIGNoYW5nZXMNCj4+IC0tLQ0KPj4gwqAgeGVuL2FyY2gvYXJtL2dpYy12My5j wqDCoMKgwqDCoMKgwqDCoMKgIHwgMTE0ICsrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t LQ0KPj4gwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oIHzCoMKgIDEgKw0KPj4gwqAg MiBmaWxlcyBjaGFuZ2VkLCA4MSBpbnNlcnRpb25zKCspLCAzNCBkZWxldGlvbnMoLSkNCj4+DQo+ PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2dpYy12My5jIGIveGVuL2FyY2gvYXJtL2dpYy12 My5jDQo+PiBpbmRleCBjZDNlMWFjZjc5Li4yOWI3ZjY4Y2JhIDEwMDY0NA0KPj4gLS0tIGEveGVu L2FyY2gvYXJtL2dpYy12My5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZ2ljLXYzLmMNCj4+IEBA IC00NDUsMTcgKzQ0NSw2NyBAQCBzdGF0aWMgdm9pZCBnaWN2M19kdW1wX3N0YXRlKGNvbnN0IHN0 cnVjdCB2Y3B1ICp2KQ0KPj4gwqDCoMKgwqDCoCB9DQo+PiDCoCB9DQo+PiArc3RhdGljIHZvaWQg X19pb21lbSAqZ2V0X2FkZHJfYnlfb2Zmc2V0KHN0cnVjdCBpcnFfZGVzYyAqaXJxZCwgdTMyIA0K Pj4gb2Zmc2V0KQ0KPiANCj4gIMKgLi4uIHBsZWFzZSB1c2UgdWludDMyX3QgZm9yIG5ldyBjb2Rl DQo+IA0KPiAoY291bGQgcHJvYmFibHkgdXBkYXRlZCBvbiBjb21taXQpDQo+IA0KPiANCg0KSSB3 aWxsIGZpeCB0aGF0IGluIFY2IGFuZCByZXZpZXcgdGhlIG90aGVyIHBhdGNoZXMgdG8gYXZvaWQg dGhlIHVzZSBvZiANCnUzMi91NjQuDQoNCj4+ICt7DQo+PiArwqDCoMKgIHN3aXRjaCAoIGlycWQt PmlycSApDQo+PiArwqDCoMKgIHsNCj4+ICvCoMKgwqAgY2FzZSAwIC4uLiAoTlJfR0lDX0xPQ0FM X0lSUVMgLSAxKToNCj4+ICvCoMKgwqDCoMKgwqDCoCBzd2l0Y2ggKCBvZmZzZXQgKQ0KPj4gK8Kg wqDCoMKgwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVNFTkFCTEVSOg0K Pj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9JQ0VOQUJMRVI6DQo+PiArwqDCoMKgwqDCoMKg wqAgY2FzZSBHSUNEX0lTUEVORFI6DQo+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lDUEVO RFI6DQo+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lTQUNUSVZFUjoNCj4+ICvCoMKgwqDC oMKgwqDCoCBjYXNlIEdJQ0RfSUNBQ1RJVkVSOg0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAg cmV0dXJuIChHSUNEX1JESVNUX1NHSV9CQVNFICsgb2Zmc2V0KTsNCj4+ICvCoMKgwqDCoMKgwqDC oCBjYXNlIEdJQ0RfSUNGR1I6DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJ Q0RfUkRJU1RfU0dJX0JBU0UgKyBHSUNSX0lDRkdSMSk7DQo+PiArwqDCoMKgwqDCoMKgwqAgY2Fz ZSBHSUNEX0lQUklPUklUWVI6DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJ Q0RfUkRJU1RfU0dJX0JBU0UgKyBHSUNSX0lQUklPUklUWVIwICsgaXJxZC0+aXJxKTsNCj4+ICvC oMKgwqDCoMKgwqDCoCBkZWZhdWx0Og0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYnJlYWs7 DQo+PiArwqDCoMKgwqDCoMKgwqAgfQ0KPj4gK8KgwqDCoCBjYXNlIE5SX0dJQ19MT0NBTF9JUlFT IC4uLiBTUElfTUFYX0lOVElEOg0KPj4gK8KgwqDCoMKgwqDCoMKgIHN3aXRjaCAoIG9mZnNldCAp DQo+PiArwqDCoMKgwqDCoMKgwqAgew0KPj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9JU0VO QUJMRVI6DQo+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lDRU5BQkxFUjoNCj4+ICvCoMKg wqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVNQRU5EUjoNCj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJ Q0RfSUNQRU5EUjoNCj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVNBQ1RJVkVSOg0KPj4g K8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9JQ0FDVElWRVI6DQo+PiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBvZmZzZXQgKyAoaXJxZC0+aXJxIC8gMzIpICogNCk7DQo+ PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lDRkdSOg0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqAgcmV0dXJuIChHSUNEICsgR0lDRF9JQ0ZHUiArIChpcnFkLT5pcnEgLyAxNikgKiA0KTsN Cj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVJPVVRFUjoNCj4+ICvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHJldHVybiAoR0lDRCArIEdJQ0RfSVJPVVRFUiArIGlycWQtPmlycSAqIDgpOw0K Pj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9JUFJJT1JJVFlSOg0KPj4gK8KgwqDCoMKgwqDC oMKgwqDCoMKgwqAgcmV0dXJuIChHSUNEICsgR0lDRF9JUFJJT1JJVFlSICsgaXJxZC0+aXJxKTsN Cj4+ICvCoMKgwqDCoMKgwqDCoCBkZWZhdWx0Og0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAg YnJlYWs7DQo+PiArwqDCoMKgwqDCoMKgwqAgfQ0KPj4gK8KgwqDCoCBkZWZhdWx0Og0KPj4gK8Kg wqDCoMKgwqDCoMKgIGJyZWFrOw0KPj4gK8KgwqDCoCB9DQo+PiArDQo+PiArwqDCoMKgIC8qIFNv bWV0aGluZyB3ZW50IHdyb25nLCB3ZSBzaG91bGRuJ3QgYmUgYWJsZSB0byByZWFjaCBoZXJlICov DQo+PiArwqDCoMKgIHByaW50ayhYRU5MT0dfV0FSTklORyAiR0lDdjM6IFdBUk5JTkc6IEludmFs aWQgb2Zmc2V0IDB4JXggZm9yIA0KPj4gSVJRIyV1IiwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC oCBvZmZzZXQsIGlycWQtPmlycSk7DQo+PiArwqDCoMKgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0K Pj4gKw0KPj4gK8KgwqDCoCByZXR1cm4gTlVMTDsNCj4+ICt9DQo+PiArDQo+PiDCoCBzdGF0aWMg dm9pZCBnaWN2M19wb2tlX2lycShzdHJ1Y3QgaXJxX2Rlc2MgKmlycWQsIHUzMiBvZmZzZXQsIGJv b2wgDQo+PiB3YWl0X2Zvcl9yd3ApDQo+PiDCoCB7DQo+PiDCoMKgwqDCoMKgIHUzMiBtYXNrID0g MVUgPDwgKGlycWQtPmlycSAlIDMyKTsNCj4+IC3CoMKgwqAgdm9pZCBfX2lvbWVtICpiYXNlOw0K Pj4gK8KgwqDCoCB2b2lkIF9faW9tZW0gKmFkZHIgPSBnZXRfYWRkcl9ieV9vZmZzZXQoaXJxZCwg b2Zmc2V0KTsNCj4+IC3CoMKgwqAgaWYgKCBpcnFkLT5pcnEgPCBOUl9HSUNfTE9DQUxfSVJRUyAp DQo+PiAtwqDCoMKgwqDCoMKgwqAgYmFzZSA9IEdJQ0RfUkRJU1RfU0dJX0JBU0U7DQo+PiAtwqDC oMKgIGVsc2UNCj4+IC3CoMKgwqDCoMKgwqDCoCBiYXNlID0gR0lDRDsNCj4+ICvCoMKgwqAgaWYg KCBhZGRyID09IE5VTEwgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybjsNCj4+IC3CoMKgwqAg d3JpdGVsX3JlbGF4ZWQobWFzaywgYmFzZSArIG9mZnNldCArIChpcnFkLT5pcnEgLyAzMikgKiA0 KTsNCj4+ICvCoMKgwqAgd3JpdGVsX3JlbGF4ZWQobWFzaywgYWRkcik7DQo+PiDCoMKgwqDCoMKg IGlmICggd2FpdF9mb3JfcndwICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBnaWN2M193YWl0X2Zv cl9yd3AoaXJxZC0+aXJxKTsNCj4+IEBAIC00NjMsMTUgKzUxMywxMiBAQCBzdGF0aWMgdm9pZCBn aWN2M19wb2tlX2lycShzdHJ1Y3QgaXJxX2Rlc2MgDQo+PiAqaXJxZCwgdTMyIG9mZnNldCwgYm9v bCB3YWl0X2Zvcl9yd3ApDQo+PiDCoCBzdGF0aWMgYm9vbCBnaWN2M19wZWVrX2lycShzdHJ1Y3Qg aXJxX2Rlc2MgKmlycWQsIHUzMiBvZmZzZXQpDQo+PiDCoCB7DQo+PiAtwqDCoMKgIHZvaWQgX19p b21lbSAqYmFzZTsNCj4+IC3CoMKgwqAgdW5zaWduZWQgaW50IGlycSA9IGlycWQtPmlycTsNCj4+ ICvCoMKgwqAgdm9pZCBfX2lvbWVtICphZGRyID0gZ2V0X2FkZHJfYnlfb2Zmc2V0KGlycWQsIG9m ZnNldCk7DQo+PiAtwqDCoMKgIGlmICggaXJxID49IE5SX0dJQ19MT0NBTF9JUlFTKQ0KPj4gLcKg wqDCoMKgwqDCoMKgIGJhc2UgPSBHSUNEICsgKGlycSAvIDMyKSAqIDQ7DQo+PiAtwqDCoMKgIGVs c2UNCj4+IC3CoMKgwqDCoMKgwqDCoCBiYXNlID0gR0lDRF9SRElTVF9TR0lfQkFTRTsNCj4+ICvC oMKgwqAgaWYgKCBhZGRyID09IE5VTEwgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiBmYWxz ZTsNCj4+IC3CoMKgwqAgcmV0dXJuICEhKHJlYWRsKGJhc2UgKyBvZmZzZXQpICYgKDFVIDw8IChp cnEgJSAzMikpKTsNCj4+ICvCoMKgwqAgcmV0dXJuICEhKHJlYWRsKGFkZHIpICYgKDFVIDw8IChp cnFkLT5pcnEgJSAzMikpKTsNCj4+IMKgIH0NCj4+IMKgIHN0YXRpYyB2b2lkIGdpY3YzX3VubWFz a19pcnEoc3RydWN0IGlycV9kZXNjICppcnFkKQ0KPj4gQEAgLTU1OCwzMCArNjA1LDI4IEBAIHN0 YXRpYyBpbmxpbmUgdWludDY0X3QgDQo+PiBnaWN2M19tcGlkcl90b19hZmZpbml0eShpbnQgY3B1 KQ0KPj4gwqAgc3RhdGljIHZvaWQgZ2ljdjNfc2V0X2lycV90eXBlKHN0cnVjdCBpcnFfZGVzYyAq ZGVzYywgdW5zaWduZWQgaW50IA0KPj4gdHlwZSkNCj4+IMKgIHsNCj4+IMKgwqDCoMKgwqAgdWlu dDMyX3QgY2ZnLCBhY3R1YWwsIGVkZ2ViaXQ7DQo+PiAtwqDCoMKgIHZvaWQgX19pb21lbSAqYmFz ZTsNCj4+IC3CoMKgwqAgdW5zaWduZWQgaW50IGlycSA9IGRlc2MtPmlycTsNCj4+ICvCoMKgwqAg dm9pZCBfX2lvbWVtICphZGRyOw0KPj4gwqDCoMKgwqDCoCAvKiBTR0kncyBhcmUgYWx3YXlzIGVk Z2UtdHJpZ2dlcmVkIG5vdCBuZWVkIHRvIGNhbGwgR0lDRF9JQ0ZHUjAgKi8NCj4+IC3CoMKgwqAg QVNTRVJUKGlycSA+PSBOUl9HSUNfU0dJKTsNCj4+ICvCoMKgwqAgQVNTRVJUKGRlc2MtPmlycSA+ PSBOUl9HSUNfU0dJKTsNCj4+IC3CoMKgwqAgc3Bpbl9sb2NrKCZnaWN2My5sb2NrKTsNCj4+ICvC oMKgwqAgYWRkciA9IGdldF9hZGRyX2J5X29mZnNldChkZXNjLCBHSUNEX0lDRkdSKTsNCj4+ICvC oMKgwqAgaWYgKCBhZGRyID09IE5VTEwgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybjsNCj4+ IC3CoMKgwqAgaWYgKCBpcnEgPj0gTlJfR0lDX0xPQ0FMX0lSUVMpDQo+PiAtwqDCoMKgwqDCoMKg wqAgYmFzZSA9IEdJQ0QgKyBHSUNEX0lDRkdSICsgKGlycSAvIDE2KSAqIDQ7DQo+PiAtwqDCoMKg IGVsc2UNCj4+IC3CoMKgwqDCoMKgwqDCoCBiYXNlID0gR0lDRF9SRElTVF9TR0lfQkFTRSArIEdJ Q1JfSUNGR1IxOw0KPj4gK8KgwqDCoCBzcGluX2xvY2soJmdpY3YzLmxvY2spOw0KPj4gLcKgwqDC oCBjZmcgPSByZWFkbF9yZWxheGVkKGJhc2UpOw0KPj4gK8KgwqDCoCBjZmcgPSByZWFkbF9yZWxh eGVkKGFkZHIpOw0KPj4gLcKgwqDCoCBlZGdlYml0ID0gMnUgPDwgKDIgKiAoaXJxICUgMTYpKTsN Cj4+ICvCoMKgwqAgZWRnZWJpdCA9IDJ1IDw8ICgyICogKGRlc2MtPmlycSAlIDE2KSk7DQo+PiDC oMKgwqDCoMKgIGlmICggdHlwZSAmIElSUV9UWVBFX0xFVkVMX01BU0sgKQ0KPj4gwqDCoMKgwqDC oMKgwqDCoMKgIGNmZyAmPSB+ZWRnZWJpdDsNCj4+IMKgwqDCoMKgwqAgZWxzZSBpZiAoIHR5cGUg JiBJUlFfVFlQRV9FREdFX0JPVEggKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGNmZyB8PSBlZGdl Yml0Ow0KPj4gLcKgwqDCoCB3cml0ZWxfcmVsYXhlZChjZmcsIGJhc2UpOw0KPj4gK8KgwqDCoCB3 cml0ZWxfcmVsYXhlZChjZmcsIGFkZHIpOw0KPj4gLcKgwqDCoCBhY3R1YWwgPSByZWFkbF9yZWxh eGVkKGJhc2UpOw0KPj4gK8KgwqDCoCBhY3R1YWwgPSByZWFkbF9yZWxheGVkKGFkZHIpOw0KPj4g wqDCoMKgwqDCoCBpZiAoICggY2ZnICYgZWRnZWJpdCApIF4gKCBhY3R1YWwgJiBlZGdlYml0ICkg KQ0KPj4gwqDCoMKgwqDCoCB7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19X QVJOSU5HICJHSUN2MzogV0FSTklORzogIg0KPj4gQEAgLTYwMCwxNiArNjQ1LDEzIEBAIHN0YXRp YyB2b2lkIGdpY3YzX3NldF9pcnFfdHlwZShzdHJ1Y3QgaXJxX2Rlc2MgDQo+PiAqZGVzYywgdW5z aWduZWQgaW50IHR5cGUpDQo+PiDCoCBzdGF0aWMgdm9pZCBnaWN2M19zZXRfaXJxX3ByaW9yaXR5 KHN0cnVjdCBpcnFfZGVzYyAqZGVzYywNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQg cHJpb3JpdHkpDQo+PiDCoCB7DQo+PiAtwqDCoMKgIHVuc2lnbmVkIGludCBpcnEgPSBkZXNjLT5p cnE7DQo+PiArwqDCoMKgIHZvaWQgX19pb21lbSAqYWRkciA9IGdldF9hZGRyX2J5X29mZnNldChk ZXNjLCBHSUNEX0lQUklPUklUWVIpOw0KPj4gLcKgwqDCoCBzcGluX2xvY2soJmdpY3YzLmxvY2sp Ow0KPj4gLQ0KPj4gLcKgwqDCoCAvKiBTZXQgcHJpb3JpdHkgKi8NCj4+IC3CoMKgwqAgaWYgKCBp cnEgPCBOUl9HSUNfTE9DQUxfSVJRUyApDQo+PiAtwqDCoMKgwqDCoMKgwqAgd3JpdGViX3JlbGF4 ZWQocHJpb3JpdHksIEdJQ0RfUkRJU1RfU0dJX0JBU0UgKyANCj4+IEdJQ1JfSVBSSU9SSVRZUjAg KyBpcnEpOw0KPj4gLcKgwqDCoCBlbHNlDQo+PiAtwqDCoMKgwqDCoMKgwqAgd3JpdGViX3JlbGF4 ZWQocHJpb3JpdHksIEdJQ0QgKyBHSUNEX0lQUklPUklUWVIgKyBpcnEpOw0KPj4gK8KgwqDCoCBp ZiAoIGFkZHIgPT0gTlVMTCApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuOw0KPj4gK8KgwqDC oCBzcGluX2xvY2soJmdpY3YzLmxvY2spOw0KPj4gK8KgwqDCoCB3cml0ZWJfcmVsYXhlZChwcmlv cml0eSwgYWRkcik7DQo+PiDCoMKgwqDCoMKgIHNwaW5fdW5sb2NrKCZnaWN2My5sb2NrKTsNCj4+ IMKgIH0NCj4+IEBAIC0xMjczLDYgKzEzMTUsMTAgQEAgc3RhdGljIHZvaWQgZ2ljdjNfaXJxX3Nl dF9hZmZpbml0eShzdHJ1Y3QgDQo+PiBpcnFfZGVzYyAqZGVzYywgY29uc3QgY3B1bWFza190ICpt YXNrKQ0KPj4gwqAgew0KPj4gwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgY3B1Ow0KPj4gwqDCoMKg wqDCoCB1aW50NjRfdCBhZmZpbml0eTsNCj4+ICvCoMKgwqAgdm9pZCBfX2lvbWVtICphZGRyID0g Z2V0X2FkZHJfYnlfb2Zmc2V0KGRlc2MsIEdJQ0RfSVJPVVRFUik7DQo+PiArDQo+PiArwqDCoMKg IGlmICggYWRkciA9PSBOVUxMICkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm47DQo+PiDCoMKg wqDCoMKgIEFTU0VSVCghY3B1bWFza19lbXB0eShtYXNrKSk7DQo+PiBAQCAtMTI4NCw3ICsxMzMw LDcgQEAgc3RhdGljIHZvaWQgZ2ljdjNfaXJxX3NldF9hZmZpbml0eShzdHJ1Y3QgDQo+PiBpcnFf ZGVzYyAqZGVzYywgY29uc3QgY3B1bWFza190ICptYXNrKQ0KPj4gwqDCoMKgwqDCoCBhZmZpbml0 eSAmPSB+R0lDRF9JUk9VVEVSX1NQSV9NT0RFX0FOWTsNCj4+IMKgwqDCoMKgwqAgaWYgKCBkZXNj LT5pcnEgPj0gTlJfR0lDX0xPQ0FMX0lSUVMgKQ0KPj4gLcKgwqDCoMKgwqDCoMKgIHdyaXRlcV9y ZWxheGVkX25vbl9hdG9taWMoYWZmaW5pdHksIChHSUNEICsgR0lDRF9JUk9VVEVSICsgDQo+PiBk ZXNjLT5pcnEgKiA4KSk7DQo+PiArwqDCoMKgwqDCoMKgwqAgd3JpdGVxX3JlbGF4ZWRfbm9uX2F0 b21pYyhhZmZpbml0eSwgYWRkcik7DQo+PiDCoMKgwqDCoMKgIHNwaW5fdW5sb2NrKCZnaWN2My5s b2NrKTsNCj4+IMKgIH0NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v aXJxLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS8gDQo+PiBhc20vaXJxLmgNCj4+IGluZGV4IGZj ZTdlNDJhMzMuLjViYzY0NzVlYjQgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVk ZS9hc20vaXJxLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEuaA0KPj4g QEAgLTI5LDYgKzI5LDcgQEAgc3RydWN0IGFyY2hfaXJxX2Rlc2Mgew0KPj4gwqDCoCAqLw0KPj4g wqAgI2RlZmluZSBOUl9JUlFTwqDCoMKgwqDCoMKgwqAgMTAyNA0KPj4gKyNkZWZpbmUgU1BJX01B WF9JTlRJRMKgwqAgMTAxOQ0KPj4gwqAgI2RlZmluZSBMUElfT0ZGU0VUwqDCoMKgwqDCoCA4MTky DQo+PiDCoCAvKiBMUElzIGFyZSBhbHdheXMgbnVtYmVyZWQgc3RhcnRpbmcgYXQgODE5Miwgc28g MCBpcyBhIGdvb2QgaW52YWxpZCANCj4+IGNhc2UuICovDQo+IA0KDQpCZXN0IHJlZ2FyZHMsDQpM ZW9uaWQNCg== From xen-devel-bounces@lists.xenproject.org Mon Sep 01 14:42:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 14:42:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105047.1456030 (Exim 4.92) (envelope-from ) id 1ut5jf-0005qf-S8; Mon, 01 Sep 2025 14:42:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105047.1456030; Mon, 01 Sep 2025 14: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 1ut5jf-0005qX-O3; Mon, 01 Sep 2025 14:42:19 +0000 Received: by outflank-mailman (input) for mailman id 1105047; Mon, 01 Sep 2025 14:42:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut5jd-0005qR-SA for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 14:42:17 +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 da5d43cc-8741-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 16:42:15 +0200 (CEST) Received: from DU0PR03MB8669.eurprd03.prod.outlook.com (2603:10a6:10:3e9::19) by AS4PR03MB8697.eurprd03.prod.outlook.com (2603:10a6:20b:58c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Mon, 1 Sep 2025 14:42:11 +0000 Received: from DU0PR03MB8669.eurprd03.prod.outlook.com ([fe80::ab7f:f6b5:4bb:3c43]) by DU0PR03MB8669.eurprd03.prod.outlook.com ([fe80::ab7f:f6b5:4bb:3c43%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 14:42: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: da5d43cc-8741-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bx6cQ1jo14H0WDufM0EGEiSzEIiy8xVJfQ8cHYW1JKkXqAZnSQ8d4oZ5D7E3xz1aGAZtK8/GBGzxBUTKn94T1brrmjsAJiuhlas34J49VtfMCkEVzshUZLt24U3tBHfhkfMg3KF1ausp5yf9M6GxC6fXqWIOZz17bKcl6PnDL+IxsnlWRqJPqDxAmp+zBgHBhOqTorKnoc6M5NMRXZ6uwLizBdmZjx45Uw8S6TEe5jqlgJ+JE94w19gi9J5vfaXz/cbZxCrb+F5IMhZ+u51OiiXWvBNTv6J5MFsZ7qwvY1TESkgKYUSaECFTEvAlpkilp9rhNfpj6UHy3kpzr0GrAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PG320cY/H2Iu95tMFjeSa3Oyl2PdNLYp9yyKqCEkhLE=; b=Hu1j47bHNb/IOK6baip7pBcUVRIO5HXTAn0dLNeqE3yX6l0ZsUw13HwVf35kdUYQctv3tAeHlrrx7h9gvzyy9eVq84KrDwRyAIqaJt/vf/Fw3Gpfsil7AyktpkdRYqIjxTwobawvTez/XpMyDnNKpVYlRWOuxpI5qqD4NJ7Y+uQhOARzpBG7oPxmXnQnJmLZexVtp6vEBmhtmWw8PALewhtPT904U5spkFlZyIDzOUvY8ytOp7X8LYeJ4fkxC4VZtHUeYpVpEijOPet6EOa3oTNY4bJK80kiLJ2Pcc+IzuzoYoSp5/OZRkGkkiY41iLFtI4YnmR1+KEkhOOfw/vXiQ== 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=PG320cY/H2Iu95tMFjeSa3Oyl2PdNLYp9yyKqCEkhLE=; b=lNJCqV21JXqLsTz4ale0p+Y9zI9EPUIDbHiHrItON1GgDrAg8ru0D7FUBK7Z8+NuC59ufUEI7RI276sTWcWyTSYtBxeZ+fk/Y/EsCzR/JRRPSZ/h1ppeyfwSiBA0JBOCNR964VsbYwL+MyVv9O7rUPhvfJGMf8jeyD38AlqrSReM7nh45ZdU6ZpwNsh/8g2+D5PkoPtslx52lFgU1jmHQfPM/FF2pbFMa/6K9BK+plkh6pIWTVEf971S/2C5mp0DcVaMtZSSkRMikWvre5MD7H+hc5oo47c/OYO34zK9mzecipJ83f5qZ+OAWXorsRRRwx0+G2B62bO6wRp2LWzxPg== From: Leonid Komarianskyi To: Oleksandr Tyshchenko CC: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Thread-Topic: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Thread-Index: AQHcGP7bBiDA5fxWR0+DupelLQbe97R8z4uAgAGbqoA= Date: Mon, 1 Sep 2025 14:42:11 +0000 Message-ID: <399bdb41-7938-4ed3-887a-c9bf6e0636ec@epam.com> References: <87tt1pykqz.fsf@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: DU0PR03MB8669:EE_|AS4PR03MB8697:EE_ x-ms-office365-filtering-correlation-id: c270ba93-2cad-4b9b-8134-08dde965bc31 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?SVpLZ21ZeVRUZTRHK29ISWFXTzFDbHNTQkpBeW96djVFeGp1QndxN3JZUjM0?= =?utf-8?B?aU5QUkE4NzBlUWMxZUJNWUgvR1lnenRnNmZtd2VzMVJtc3JrZFlZVStWNTJU?= =?utf-8?B?R0FZQWJCWXY0S3Q0dVA5NkxLNWMxU2JFMG9QTmYxdFFidkM1RUl0d0Jjd0VD?= =?utf-8?B?YXdZSUhjYnZaK1Btek1OaDNSeU1DQVlLVGYyRkVTT1kxNU1NQmY4TU55RW5P?= =?utf-8?B?TmpLNzBWV1NqZWJmNTVMWXpEOExkNy9GOVZJRkRGS1puSDJjd29aNlI1eWxn?= =?utf-8?B?Wk9JbG8yZkxma3E0N0MwMkNtR2grVXArVFRiNWYrUzhjS0lVVjFWS2N3UWpC?= =?utf-8?B?T3dibUM3WTYrTGNZd29jeU1sVm1DTXM4ZHJ5WWs2QXRzR01BTzBnSSt5ZURh?= =?utf-8?B?NjdXM2dyL3RVRTNuYS9Gc09RN2pZVW1VY081SjAwdGxaRHVJZWhLWmE3Zjll?= =?utf-8?B?WGJtNnRTOVNYYnNwZGdaSlRhUFBWQTRTOUtwYkpQZmxYOXRNL0Z1NDc5ZVM2?= =?utf-8?B?S0R2NXAxL25sZ21ZNWlzZzRTZml3QTcyejJ0ekpRemI3a1FCYm9iY3Fndmxz?= =?utf-8?B?UzU1T2tkTVNxbXdOczU3MlNOYzRsNEhpOGt0ejJodEM4eDU1TXpqKzBzNXRz?= =?utf-8?B?QU1OR1VueHJGZFpaQ1JCREljTC9rdUJGTkE0UEpEMW8rcTROUm5QbWhBRFFB?= =?utf-8?B?ZnJ2ak1OclF3c3BRWjN4aUZMd3FiOWNDK2E0UnZhZ09vWlhHT0s0MFZIeDdm?= =?utf-8?B?ZENPek12eU9IQkxqSGl1UVQzNmhOWXBHbCsrQ0xTcm1mRWt2RE1ZUzRMVWlr?= =?utf-8?B?OG1ReDQ3ZmQ5bzB2dFhOd3dCbFdsOFlzTVlJUTZyellqclFuOEl5WkJ1aEtk?= =?utf-8?B?am94MGVSQzV2czd6blFYN2k1TFd4Z25WZ3ZJMm1SalZNNWovWjVFWmFJN3RS?= =?utf-8?B?Rlk2UVhwR2VXeC9nOWY4WGVmVDllekhLWG1uUURQNkZSZFcwaVdKOG5IblA4?= =?utf-8?B?d1BhVCtsdUpWVVJzY1Z1bmNTNWhKWmdRVitWNU0vQ1BvVzVWOWpqTHJBOGFE?= =?utf-8?B?aVRoWERBLzVZQ2FJM3lJMmdxWEhsRDExcU96Tkg5Wnh1V0F2NEY5VWg2VmFY?= =?utf-8?B?R0JZQjFDQXlUemdkZklicmxtekVCbWxGVWo5d2w5NlJNK1NKSnhlVStvd2wv?= =?utf-8?B?T3NQTTNGRXRFWTdBSjYxZWs2c2Q4SGVnTzhnTE9zTVNhQlJnaHIySCtscTBM?= =?utf-8?B?RlpkUVByb3N1RHFDOXhPSFpTZit6cXJoa1NKaGcxTjc0d2xvNzNxLzU4RExj?= =?utf-8?B?TlZYRGRiWWovaWE3b2dYRzI1aXhlTEtlRFUrZUlScmdjRVZBSGFLL2tmdHJR?= =?utf-8?B?UTVZUWNXV21YR3l4SWtad2hSUHltVTZWNW5XTDNPWFAyZlVwN1VWdmNTd2wv?= =?utf-8?B?a3A4eE40N1YrdDR2dzVxTEtVbDhYRGRNUEN3ZGJJNUY5ODBQcVFOb3U1RFpa?= =?utf-8?B?VXFJTFd3WjNoSW9sMWZZUTRpUXk1VVdmM2I0TFZ6a2lySE5pdWxUcFZLM2Vn?= =?utf-8?B?c1NTRnFoK201dHA5REVmamJFaFdySjIxaytwbnJvbHFSQktWQ2I2Q0MxWWZQ?= =?utf-8?B?c0MxU05NeWJ1LzdIbHMvUS9HYUVLdWZUZmw1cmVlcXNhT2QrbWg4TWlnZEhK?= =?utf-8?B?OHVUamF6eDAzZHhnVVdGOE92eitFVWVTMkZNcnpjaWRYV0c3NVlrQWZWTmp6?= =?utf-8?B?aFdRdVB0ekxsS2lUTWh1TXJSRzZRVkxhWGdYaWdLWmI2cWNoWFd4S0ExS2dL?= =?utf-8?B?c3R5S0gzM2RybUxTcVBCQUR2Q21IazVHYm9xeTJZVmZvV0Z0YU5mVXhaaHh2?= =?utf-8?B?ckh6ZlNWNjhPYTBBOTg0bFNTSXFicVZmVWJUTXZSVDJTbW5abzVuR01sWURn?= =?utf-8?B?M1FJRGJ3U0d4bENUaGZnVEovT2dDOHVIMzhCZnpEWS9weWlXRm5XRmhvSjRs?= =?utf-8?B?VlBSaE91ZVVnPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8669.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bktvN3BHSVdESWFBdUhTaml0Qm43Zkx6eUJLMUNvemh0QUFGdURjczRUWVRt?= =?utf-8?B?OUVzYVNQSkhVMmlnUDVtUy9YOWYvcGFPUEJDQzdwcGZTS0Via2tuTzZtQTJk?= =?utf-8?B?ak54UWNLeko3NjZXK0EvTFhnaGIwLzhnQkQxcHRGL2o5SDd1T1RBWTNRZWFG?= =?utf-8?B?a2hTalVTWU9DSEVZbzRNSTIwTEh3ei9HQjlMZW5ZUXR1Uk5NUXlWbWNwM21q?= =?utf-8?B?cEp6ZU5WZk1HczRoSktmUWgvT05mMDA2eUlPOXJxTGJ0OFhmZ0JSWFA5ZWNp?= =?utf-8?B?ZDZNeUFHUU9VUU1oa0lZVVRKNi9lVWh4UGFzWFpETTZ2UXRoWGplbFI5OG1q?= =?utf-8?B?RERpdXZzcEplQ21DRjBBK2laQnNoNW0xV1ZGdWhya3JkQ3hEMlBsNHBjaFQw?= =?utf-8?B?WklnOVdtM3BNSTdEUlEyZW9jdDMvUEZnUUk2Y3ZkelJ1UG1XMHptT2N3SFBN?= =?utf-8?B?clhwTEVzVU45SWV1ajNGRGN0cGpJNnZGVEhJb1A3dWxTa2dQcVlyZXJ4Zkxu?= =?utf-8?B?bnc1dzR3VlMzbFZEd1pCcE5zMHplUXN3ZGcrUUxXbS9pWkpHSk1vUmdDbWow?= =?utf-8?B?YUYxODY0MHRMcG5ibVlSV3Z0UUhjV3Y0Ymh3a1VGYm1aSmYyTE9xZWFOMG8w?= =?utf-8?B?Y25pN1FEbXNaaEpiMzMwelBadnhjOHpNMm9wT29kTVMvM0FmU2s0TzlFcjZm?= =?utf-8?B?V0lkdzVPNEwvSVluQmRKN3V0UXZWNnQ2eWJnVWJPaEFoVnlFUVZSVlMrdHBo?= =?utf-8?B?M3cvVVhIRUJzOVUrMkVMOXMza2dzRUN1elNtd1Avd1kvR0Q2N3M2UklvMTBh?= =?utf-8?B?K1VVNFhSNmpCZFFPRjlrMzUveHhTZXZHcnRpYUVBRWlkZDh0bTFWNS96Z3Fa?= =?utf-8?B?R0V6TjY1K2gxMzhUR3hrNFc1T3g5WlpvV2hkVm9ycUdFZHRYU25JRDBTY3pQ?= =?utf-8?B?cnozM2dzMURpYmphTmE3VjdlMjk4R1BaajU4Ym05TEpNaGFlWDBoV3VIQ3FZ?= =?utf-8?B?bGcyQnZPVHN2Yk5Va3VwcDMvRG5MU2VmL0JqR1BxQ2gzbDl6Y2JJR2QwckYr?= =?utf-8?B?SmlyUGpBRlJHZjh0aXZsM2o3MVJjcjlkWUpMUVRDWEsvaHJoWDVGMFlpb3dW?= =?utf-8?B?M2J0aXVFVDAzR2FIaXovTmhBYXk5Vnd3VWNaKzFuUGZOT2Yxa1YzZXBaL1Bm?= =?utf-8?B?ZnFnSDdjSEx6NHVGZkJkWjhSenNHOG5iaXQ4aTNKL0FsUGhmVmRCa21TbitY?= =?utf-8?B?UVdTYXJGR2FDZTY3ZWIwY29aMnVRMndITThNMWFkUzBUenBUQUVUVUozTmNz?= =?utf-8?B?cWRubldjNlR2OUpaRWg0SDZXTlMyeXNJTS9vSmkvaHdGV2RZZ2V3YU9aYUlr?= =?utf-8?B?NkxWZE5JTlV2ZU5VL2JEaUE0MmEvdnpHZ1lydW9nMEtBTmNGcUVza2ZEWUxv?= =?utf-8?B?S2RQUzc1Tll1bjdESHEycVdTWFd3N2E5elRqNGNwSE05RXFmOEg3ZTgrM3pF?= =?utf-8?B?dWpEYjBqMmM3TnpJVlZBNkNzR1gyenpwNnU4OEhoUUxZS2E0WitBcHdXLzdu?= =?utf-8?B?NityZ2pmZzRlc2NCcHYvTlRUS2VsOVNtaWs2YzZIaWc5c2RvZ0xQTmhpaXA1?= =?utf-8?B?dWUvRm8yWS80bHNoS1pWbmFCazM3aCtCK2RpOEN6V1BoRFluUXhDclNRS1VC?= =?utf-8?B?UGJnT09VenpoV0VyMElTN2wwUTVlTTRSY1l1RDgyeFVEV0ZrYjEvU0dDNCtz?= =?utf-8?B?RlFSWFdHRmVxZ3diZW84T2JHTkY0UmlKZ0tvTjhYRHBYcTExU0lXelNTSlFq?= =?utf-8?B?S094YlRmTHlpcGxicnl6MDRkRWplaTZWVVpjNU4vdUtvSGpRTUUzbXlISldV?= =?utf-8?B?Ti9PbkJFTUxJU1pXTUwrM1AwejVPSDRXSzNzYnp6VS9vWTNCSlk0ZWtjQ1NE?= =?utf-8?B?QlhweFpmZFllbTR4bkdENXBoM0kvTHI1UjM1cm0xZVBPVlNDZDhQY1BHRWEw?= =?utf-8?B?ZThIREt2R3hqTUxUem1YZERhY0l0bEk0V0dBSVZtMmw3UDNnU1psaFZUMUlm?= =?utf-8?B?dXZKbkwxUFY3ZG1VakhQTm5icnYzNTBnYklRMnF1blBFWVM2UnB2ZWU1b2N5?= =?utf-8?B?bU5ZYktEdGJISWJxNzlZc1pTcldQTTBXdlpxQzBGUndwTGVWQjNENWFXQll6?= =?utf-8?Q?ugyB2qGNWJbNv75qq0BDRbU=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <3B9C2CCA6163B64690BC29F295E3111E@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: DU0PR03MB8669.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c270ba93-2cad-4b9b-8134-08dde965bc31 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 14:42:11.4752 (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: C1sK0uUlizwGxQq0YCaA55msUrzzhbICJf3jMWui3YHedBoDLGU7DQkQ0QS3/PSvm+f++/ucsblBL5A5VkW4Ds4oy+fi3JIwsOD9hg1/2Yo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8697 SGVsbG8gT2xla3NhbmRyIGFuZCBWb2xvZHlteXIsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBjb21t ZW50cy4NCg0KT24gMzEuMDguMjUgMTc6MDgsIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdyb3RlOg0K PiANCj4gDQo+IE9uIDI5LjA4LjI1IDIyOjQ1LCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4+ DQo+PiBIaSBMZW9uaWQsDQo+IA0KPiBIZWxsbyBMZW9uaWQNCj4gDQo+Pg0KPj4gTGVvbmlkIEtv bWFyaWFuc2t5aSA8TGVvbmlkX0tvbWFyaWFuc2t5aUBlcGFtLmNvbT4gd3JpdGVzOg0KPj4NCj4+ PiBDdXJyZW50bHksIFhlbiBkb2VzIG5vdCBzdXBwb3J0IGVTUEkgaW50ZXJydXB0cywgbGVhZGlu Zw0KPj4+IHRvIGEgZGF0YSBhYm9ydCB3aGVuIHN1Y2ggaW50ZXJydXB0cyBhcmUgZGVmaW5lZCBp biB0aGUgRFRTLg0KPj4+DQo+Pj4gVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGEgc2VwYXJhdGUgYXJy YXkgdG8gaW5pdGlhbGl6ZSB1cCB0bw0KPj4+IDEwMjQgaW50ZXJydXB0IGRlc2NyaXB0b3JzIGlu IHRoZSBlU1BJIHJhbmdlIGFuZCBhZGRzIHRoZQ0KPj4+IG5lY2Vzc2FyeSBkZWZpbmVzIGFuZCBo ZWxwZXIgZnVuY3Rpb24uIFRoZXNlIGNoYW5nZXMgbGF5IHRoZQ0KPj4+IGdyb3VuZHdvcmsgZm9y IGZ1dHVyZSBpbXBsZW1lbnRhdGlvbiBvZiBmdWxsIGVTUEkgaW50ZXJydXB0DQo+Pj4gc3VwcG9y dC4gQXMgdGhpcyBHSUN2My4xIGZlYXR1cmUgaXMgbm90IHJlcXVpcmVkIGJ5IGFsbCB2ZW5kb3Jz LA0KPj4+IGFsbCBjaGFuZ2VzIGFyZSBndWFyZGVkIGJ5IGlmZGVmcywgZGVwZW5kaW5nIG9uIHRo ZSBjb3JyZXNwb25kaW5nDQo+Pj4gS2NvbmZpZyBvcHRpb24uDQo+Pj4NCj4+PiBTaWduZWQtb2Zm LWJ5OiBMZW9uaWQgS29tYXJpYW5za3lpIDxsZW9uaWRfa29tYXJpYW5za3lpQGVwYW0uY29tPg0K Pj4+DQo+Pj4gLS0tDQo+Pj4gQ2hhbmdlcyBpbiBWNToNCj4+PiAtIG5vIGZ1bmN0aW9uYWwgY2hh bmdlcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgdmVyc2lvbiBjb21wYXJlZCB3aXRoIFY0LCANCj4+PiBv bmx5DQo+Pj4gwqDCoCBtaW5vciBmaXhlcyBhbmQgcmVtb3ZhbCBvZiBpZmRlZnMgZm9yIG1hY3Jv c2VzDQo+Pj4gLSBhZGRlZCBUT0RPIGNvbW1lbnQsIHN1Z2dlc3RlZCBieSBPbGVrc2FuZHIgVHlz aGNoZW5rbw0KPj4+IC0gY2hhbmdlZCBpbnQgdG8gdW5zaWduZWQgaW50IGZvciBpcnFzDQo+Pj4g LSByZW1vdmVkIGlmZGVmcyBmb3IgZVNQSS1zcGVjaWZpYyBkZWZpbmVzIGFuZCBtYWNyb3MgdG8g cmVkdWNlIHRoZQ0KPj4+IMKgwqAgbnVtYmVyIG9mIGlmZGVmcyBhbmQgY29kZSBkdXBsaWNhdGlv biBpbiBmdXJ0aGVyIGNoYW5nZXMNCj4+PiAtIHJlbW92ZWQgcmV2aWV3ZWQtYnkgYXMgbW92aW5n IGRlZmluZXMgZnJvbSBpZmRlZnMgcmVxdWlyZXMgYWRkaXRpb25hbA0KPj4+IMKgwqAgY29uZmly bWF0aW9uIGZyb20gcmV2aWV3ZXJzDQo+IA0KPiANCj4gUmV2aWV3ZWQtYnk6IE9sZWtzYW5kciBU eXNoY2hlbmtvIDxvbGVrc2FuZHJfdHlzaGNoZW5rb0BlcGFtLmNvbT4NCj4gDQo+IHdpdGggdGhl IGZvbGxvd2luZyBhZGRyZXNzZWQgLi4uDQo+IA0KPiANCj4+Pg0KPj4+IENoYW5nZXMgaW4gVjQ6 DQo+Pj4gLSByZW1vdmVkIHJlZHVuZGFudCBsaW5lIHdpdGggJ2RlZmF1bHQgbicgaW4gS2NvbmZp ZywgYXMgaXQgaXMgZGlzYWJsZWQNCj4+PiDCoMKgIGJ5IGRlZmF1bHQsIHdpdGhvdXQgZXhwbGlj aXQgc3BlY2lmaWNhdGlvbg0KPj4+IC0gYWRkZWQgcmV2aWV3ZWQtYnkgZnJvbSBWb2xvZHlteXIg QmFiY2h1aw0KPj4+DQo+Pj4gQ2hhbmdlcyBpbiBWMzoNCj4+PiAtIGludHJvZHVjZWQgYSBuZXcg ZGVmaW5lIE5SX0VTUElfSVJRUyB0byBhdm9pZCBjb25mdXNpb24sIGxpa2UgaW4gdGhlDQo+Pj4g wqDCoCBjYXNlIG9mIHVzaW5nIE5SX0lSUVMgZm9yIGVzcGlfZGVzYyBhcnJheQ0KPj4+IC0gaW1w bGVtZW50ZWQgaGVscGVyIGZ1bmN0aW9ucyBlc3BpX3RvX2Rlc2MgYW5kIGluaXRfZXNwaV9kYXRh IHRvIG1ha2UNCj4+PiDCoMKgIGl0IHBvc3NpYmxlIHRvIGFkZCBzdHVicyB3aXRoIHRoZSBzYW1l IG5hbWUsIGFuZCBhcyBhIHJlc3VsdCwgcmVkdWNlDQo+Pj4gwqDCoCB0aGUgbnVtYmVyIG9mICNp ZmRlZnMNCj4+PiAtIGRpc2FibGUgQ09ORklHX0dJQ1YzX0VTUEkgZGVmYXVsdCB2YWx1ZSB0byBu DQo+Pj4NCj4+PiBDaGFuZ2VzIGluIFYyOg0KPj4+IC0gdXNlIChFU1BJX01BWF9JTlRJRCArIDEp IGluc3RlYWQgb2YgKEVTUElfQkFTRV9JTlRJRCArIE5SX0lSUVMpDQo+Pj4gLSByZW1vdmUgdW5u ZWNlc3NhcnkgY29tbWVudCBmb3IgbnJfaXJxcyBpbml0aWFsaXphdGlvbg0KPj4+IC0tLQ0KPj4+ IMKgIHhlbi9hcmNoL2FybS9LY29uZmlnwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDggKysrKysN Cj4+PiDCoCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaXJxLmggfCAyNCArKysrKysrKysrKysr KysNCj4+PiDCoCB4ZW4vYXJjaC9hcm0vaXJxLmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCA1 NiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystDQo+Pj4gwqAgMyBmaWxlcyBjaGFu Z2VkLCA4NyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+Pj4NCj4+PiBkaWZmIC0tZ2l0 IGEveGVuL2FyY2gvYXJtL0tjb25maWcgYi94ZW4vYXJjaC9hcm0vS2NvbmZpZw0KPj4+IGluZGV4 IDE3ZGYxNDdiMjUuLjQzYjA1NTMzYjEgMTAwNjQ0DQo+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL0tj b25maWcNCj4+PiArKysgYi94ZW4vYXJjaC9hcm0vS2NvbmZpZw0KPj4+IEBAIC0xMzUsNiArMTM1 LDE0IEBAIGNvbmZpZyBHSUNWMw0KPj4+IMKgwqDCoMKgwqDCoMKgIERyaXZlciBmb3IgdGhlIEFS TSBHZW5lcmljIEludGVycnVwdCBDb250cm9sbGVyIHYzLg0KPj4+IMKgwqDCoMKgwqDCoMKgIElm IHVuc3VyZSwgdXNlIHRoZSBkZWZhdWx0IHNldHRpbmcuDQo+Pj4gK2NvbmZpZyBHSUNWM19FU1BJ DQo+Pj4gK8KgwqDCoCBib29sICJFeHRlbmRlZCBTUEkgcmFuZ2Ugc3VwcG9ydCINCj4+PiArwqDC oMKgIGRlcGVuZHMgb24gR0lDVjMgJiYgIU5FV19WR0lDDQo+Pj4gK8KgwqDCoCBoZWxwDQo+Pj4g K8KgwqDCoMKgwqAgQWxsb3cgWGVuIGFuZCBkb21haW5zIHRvIHVzZSBpbnRlcnJ1cHQgbnVtYmVy cyBmcm9tIHRoZSANCj4+PiBleHRlbmRlZCBTUEkNCj4+PiArwqDCoMKgwqDCoCByYW5nZSwgZnJv bSA0MDk2IHRvIDUxMTkuIFRoaXMgZmVhdHVyZSBpcyBpbnRyb2R1Y2VkIGluIEdJQ3YzLjENCj4+ PiArwqDCoMKgwqDCoCBhcmNoaXRlY3R1cmUuDQo+Pj4gKw0KPj4+IMKgIGNvbmZpZyBIQVNfSVRT DQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIGJvb2wgIkdJQ3YzIElUUyBNU0kgY29udHJvbGxlciBz dXBwb3J0IChVTlNVUFBPUlRFRCkiIGlmIA0KPj4+IFVOU1VQUE9SVEVEDQo+Pj4gwqDCoMKgwqDC oMKgwqDCoMKgIGRlcGVuZHMgb24gR0lDVjMgJiYgIU5FV19WR0lDICYmICFBUk1fMzINCj4+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oIGIveGVuL2FyY2gvYXJt L2luY2x1ZGUvIA0KPj4+IGFzbS9pcnEuaA0KPj4+IGluZGV4IDViYzY0NzVlYjQuLjQ0NDM3OTk2 NDggMTAwNjQ0DQo+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oDQo+Pj4g KysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oDQo+Pj4gQEAgLTMyLDYgKzMyLDEz IEBAIHN0cnVjdCBhcmNoX2lycV9kZXNjIHsNCj4+PiDCoCAjZGVmaW5lIFNQSV9NQVhfSU5USUTC oMKgIDEwMTkNCj4+PiDCoCAjZGVmaW5lIExQSV9PRkZTRVTCoMKgwqDCoMKgIDgxOTINCj4+PiAr I2RlZmluZSBFU1BJX0JBU0VfSU5USUQgNDA5Ng0KPj4+ICsjZGVmaW5lIEVTUElfTUFYX0lOVElE wqAgNTExOQ0KPj4+ICsjZGVmaW5lIE5SX0VTUElfSVJRU8KgwqDCoCAxMDI0DQo+Pj4gKw0KPj4+ ICsjZGVmaW5lIEVTUElfSU5USUQySURYKGludGlkKSAoKGludGlkKSAtIEVTUElfQkFTRV9JTlRJ RCkNCj4+PiArI2RlZmluZSBFU1BJX0lEWDJJTlRJRChpZHgpwqDCoCAoKGlkeCkgKyBFU1BJX0JB U0VfSU5USUQpDQo+Pj4gKw0KPj4+IMKgIC8qIExQSXMgYXJlIGFsd2F5cyBudW1iZXJlZCBzdGFy dGluZyBhdCA4MTkyLCBzbyAwIGlzIGEgZ29vZCANCj4+PiBpbnZhbGlkIGNhc2UuICovDQo+Pj4g wqAgI2RlZmluZSBJTlZBTElEX0xQScKgwqDCoMKgIDANCj4+PiBAQCAtMzksNyArNDYsMTUgQEAg c3RydWN0IGFyY2hfaXJxX2Rlc2Mgew0KPj4+IMKgICNkZWZpbmUgSU5WQUxJRF9JUlHCoMKgwqDC oCAxMDIzDQo+Pj4gwqAgZXh0ZXJuIGNvbnN0IHVuc2lnbmVkIGludCBucl9pcnFzOw0KPj4+ICsj aWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+PiArLyoNCj4+PiArICogVGhpcyB3aWxsIGFsc28g Y292ZXIgdGhlIGVTUEkgcmFuZ2UsIGFzIHNvbWUgY3JpdGljYWwgZGV2aWNlcw0KPj4+ICsgKiBm b3IgYm9vdGluZyBYZW4gKGUuZy4sIHNlcmlhbCkgbWF5IHVzZSB0aGlzIHR5cGUgb2YgaW50ZXJy dXB0cy4NCj4+PiArICovDQo+Pj4gKyNkZWZpbmUgbnJfc3RhdGljX2lycXMgKEVTUElfTUFYX0lO VElEICsgMSkNCj4+PiArI2Vsc2UNCj4+PiDCoCAjZGVmaW5lIG5yX3N0YXRpY19pcnFzIE5SX0lS UVMNCj4+PiArI2VuZGlmDQo+Pj4gwqAgc3RydWN0IGlycV9kZXNjOw0KPj4+IMKgIHN0cnVjdCBp cnFhY3Rpb247DQo+Pj4gQEAgLTU1LDYgKzcwLDE1IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBpc19s cGkodW5zaWduZWQgaW50IGlycSkNCj4+PiDCoMKgwqDCoMKgIHJldHVybiBpcnEgPj0gTFBJX09G RlNFVDsNCj4+PiDCoCB9DQo+Pj4gK3N0YXRpYyBpbmxpbmUgYm9vbCBpc19lc3BpKHVuc2lnbmVk IGludCBpcnEpDQo+Pj4gK3sNCj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+Pg0KPj4g VGFraW5nIGludG8gYWNjb3VudCB0aGF0IHdpdGggQ09ORklHX0dJQ1YzX0VTUEk9biB3ZSBzaG91 bGQgbmV2ZXIgaGF2ZQ0KPj4gImlycSIgaW4gZVNQSSByYW5nZSwgZG8geW91IHJlYWxseSBuZWVk IHRoaXMgI2lmZGVmPyBJIHRoaW5rIHRoYXQNCj4+IEFTU0VSVF9VTlJFQUNIQUJMRSBpbiBlc3Bp X3RvX2Rlc2MoKSBpcyBzdWZmaWNpZW50IGd1YXJkLg0KPj4NCj4+IEFsc28sIElSUSBsaW5lIG51 bWJlciBiZWxvbmdzIHRvIGVTUEkgcmFuZ2UgcmVnYXJkbGVzcyBvZiANCj4+IENPTkZJR19HSUNW M19FU1BJLA0KPj4gdmFsdWUsIHNvIGluIG15IG9waW5pb24gaXNfZXNwaSgpIHNob3VsZCBhbHdh eXMgcmV0dXJuIGNvcnJlY3QgdmFsdWUgZm9yDQo+PiBhIGdpdmVuICJpcnEiLg0KPiANCj4gIMKg Li4uIEkgYWdyZWUgd2l0aCBWb2xvZHlteXIncyBzdWdnZXN0aW9uIGZvciBpc19lc3BpKCkgdG8g YWx3YXlzIHJldHVybiANCj4gY29ycmVjdCB2YWx1ZSBmb3IgYSBnaXZlbiAiaXJxIi4NCj4gDQo+ IA0KDQpJIHdpbGwgZml4IHRoYXQgaW4gVjYuDQoNCj4+DQo+Pj4gK8KgwqDCoCByZXR1cm4gKGly cSA+PSBFU1BJX0JBU0VfSU5USUQgJiYgaXJxIDw9IEVTUElfTUFYX0lOVElEKTsNCj4+DQo+PiBB bHNvLCB5b3UgZG9uJ3QgbmVlZCBwYXJlbnRoZXNlcyBoZXJlLg0KDQpJIHdpbGwgcmVtb3ZlIHRo ZSByZWR1bmRhbnQgcGFyZW50aGVzZXMgaW4gVjYgYXMgd2VsbC4NCg0KPj4NCj4+PiArI2Vsc2UN Cj4+PiArwqDCoMKgIHJldHVybiBmYWxzZTsNCj4+PiArI2VuZGlmDQo+Pj4gK30NCj4+PiArDQo+ Pj4gwqAgI2RlZmluZSBkb21haW5fcGlycV90b19pcnEoZCwgcGlycSkgKHBpcnEpDQo+Pj4gwqAg Ym9vbCBpc19hc3NpZ25hYmxlX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsNCj4+PiBkaWZmIC0tZ2l0 IGEveGVuL2FyY2gvYXJtL2lycS5jIGIveGVuL2FyY2gvYXJtL2lycS5jDQo+Pj4gaW5kZXggYjhl Y2NmYzkyNC4uNjFjOTE1YzNmOSAxMDA2NDQNCj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaXJxLmMN Cj4+PiArKysgYi94ZW4vYXJjaC9hcm0vaXJxLmMNCj4+PiBAQCAtMTksNyArMTksMTEgQEANCj4+ PiDCoCAjaW5jbHVkZSA8YXNtL2dpYy5oPg0KPj4+IMKgICNpbmNsdWRlIDxhc20vdmdpYy5oPg0K Pj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+PiArY29uc3QgdW5zaWduZWQgaW50IG5y X2lycXMgPSBFU1BJX01BWF9JTlRJRCArIDE7DQo+Pj4gKyNlbHNlDQo+Pj4gwqAgY29uc3QgdW5z aWduZWQgaW50IG5yX2lycXMgPSBOUl9JUlFTOw0KPj4+ICsjZW5kaWYNCj4+PiDCoCBzdGF0aWMg dW5zaWduZWQgaW50IGxvY2FsX2lycXNfdHlwZVtOUl9MT0NBTF9JUlFTXTsNCj4+PiDCoCBzdGF0 aWMgREVGSU5FX1NQSU5MT0NLKGxvY2FsX2lycXNfdHlwZV9sb2NrKTsNCj4+PiBAQCAtNDYsNiAr NTAsNTMgQEAgdm9pZCBpcnFfZW5kX25vbmUoc3RydWN0IGlycV9kZXNjICppcnEpDQo+Pj4gwqAg fQ0KPj4+IMKgIHN0YXRpYyBpcnFfZGVzY190IGlycV9kZXNjW05SX0lSUVMgLSBOUl9MT0NBTF9J UlFTXTsNCj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+Pj4gKy8qDQo+Pj4gKyAqIFRP RE86IENvbnNpZGVyIGFsbG9jYXRpbmcgYW4gYXJyYXkgZHluYW1pY2FsbHkgaWYNCj4+PiArICog dGhlcmUgaXMgYSBuZWVkIHRvIGVuYWJsZSBHSUNWM19FU1BJIGJ5IGRlZmF1bHQuDQo+Pj4gKyAq Lw0KPj4+ICtzdGF0aWMgaXJxX2Rlc2NfdCBlc3BpX2Rlc2NbTlJfRVNQSV9JUlFTXTsNCj4+PiAr DQo+Pj4gK3N0YXRpYyBzdHJ1Y3QgaXJxX2Rlc2MgKmVzcGlfdG9fZGVzYyh1bnNpZ25lZCBpbnQg aXJxKQ0KPj4+ICt7DQo+Pj4gK8KgwqDCoCByZXR1cm4gJmVzcGlfZGVzY1tFU1BJX0lOVElEMklE WChpcnEpXTsNCj4+PiArfQ0KPj4+ICsNCj4+PiArc3RhdGljIGludCBfX2luaXQgaW5pdF9lc3Bp X2RhdGEodm9pZCkNCj4+PiArew0KPj4+ICvCoMKgwqAgdW5zaWduZWQgaW50IGlycTsNCj4+PiAr DQo+Pj4gK8KgwqDCoCBmb3IgKCBpcnEgPSBFU1BJX0JBU0VfSU5USUQ7IGlycSA8PSBFU1BJX01B WF9JTlRJRDsgaXJxKysgKQ0KPj4+ICvCoMKgwqAgew0KPj4+ICvCoMKgwqDCoMKgwqDCoCBzdHJ1 Y3QgaXJxX2Rlc2MgKmRlc2MgPSBpcnFfdG9fZGVzYyhpcnEpOw0KPj4+ICvCoMKgwqDCoMKgwqDC oCBpbnQgcmMgPSBpbml0X29uZV9pcnFfZGVzYyhkZXNjKTsNCj4+PiArDQo+Pj4gK8KgwqDCoMKg wqDCoMKgIGlmICggcmMgKQ0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByYzsN Cj4+PiArDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGRlc2MtPmlycSA9IGlycTsNCj4+PiArwqDCoMKg wqDCoMKgwqAgZGVzYy0+YWN0aW9uwqAgPSBOVUxMOw0KPj4+ICvCoMKgwqAgfQ0KPj4+ICsNCj4+ PiArwqDCoMKgIHJldHVybiAwOw0KPj4+ICt9DQo+Pj4gKyNlbHNlDQo+Pj4gKy8qDQo+Pj4gKyAq IFRoaXMgZnVuY3Rpb24gaXMgc3R1YiBhbmQgd2lsbCBub3QgYmUgY2FsbGVkIGlmIENPTkZJR19H SUNWM19FU1BJPW4sDQo+Pj4gKyAqIGJlY2F1c2UgaW4gdGhpcyBjYXNlLCBpc19lc3BpIHdpbGwg YWx3YXlzIHJldHVybiBmYWxzZS4NCj4gDQo+ICDCoFRoaXMgY29tbWVudCBzaG91bGQgYWxzbyBi ZSB1cGRhdGVkLg0KPiANCg0KU3VyZSwgSSB3aWxsIHVwZGF0ZSB0aGUgY29tbWVudCBhY2NvcmRp bmdseS4NCg0KPj4+ICsgKi8NCj4+PiArc3RhdGljIHN0cnVjdCBpcnFfZGVzYyAqZXNwaV90b19k ZXNjKHVuc2lnbmVkIGludCBpcnEpDQo+Pj4gK3sNCj4+PiArwqDCoMKgIEFTU0VSVF9VTlJFQUNI QUJMRSgpOw0KPj4+ICvCoMKgwqAgcmV0dXJuIE5VTEw7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0 YXRpYyBpbnQgX19pbml0IGluaXRfZXNwaV9kYXRhKHZvaWQpDQo+Pj4gK3sNCj4+PiArwqDCoMKg IHJldHVybiAwOw0KPj4+ICt9DQo+Pj4gKyNlbmRpZg0KPj4+ICsNCj4+PiDCoCBzdGF0aWMgREVG SU5FX1BFUl9DUFUoaXJxX2Rlc2NfdFtOUl9MT0NBTF9JUlFTXSwgbG9jYWxfaXJxX2Rlc2MpOw0K Pj4+IMKgIHN0cnVjdCBpcnFfZGVzYyAqX19pcnFfdG9fZGVzYyh1bnNpZ25lZCBpbnQgaXJxKQ0K Pj4+IEBAIC01Myw2ICsxMDQsOSBAQCBzdHJ1Y3QgaXJxX2Rlc2MgKl9faXJxX3RvX2Rlc2ModW5z aWduZWQgaW50IGlycSkNCj4+PiDCoMKgwqDCoMKgIGlmICggaXJxIDwgTlJfTE9DQUxfSVJRUyAp DQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAmdGhpc19jcHUobG9jYWxfaXJxX2Rlc2Mp W2lycV07DQo+Pj4gK8KgwqDCoCBpZiAoIGlzX2VzcGkoaXJxKSApDQo+Pj4gK8KgwqDCoMKgwqDC oMKgIHJldHVybiBlc3BpX3RvX2Rlc2MoaXJxKTsNCj4+PiArDQo+Pj4gwqDCoMKgwqDCoCByZXR1 cm4gJmlycV9kZXNjW2lycS1OUl9MT0NBTF9JUlFTXTsNCj4+PiDCoCB9DQo+Pj4gQEAgLTc5LDcg KzEzMyw3IEBAIHN0YXRpYyBpbnQgX19pbml0IGluaXRfaXJxX2RhdGEodm9pZCkNCj4+PiDCoMKg wqDCoMKgwqDCoMKgwqAgZGVzYy0+YWN0aW9uwqAgPSBOVUxMOw0KPj4+IMKgwqDCoMKgwqAgfQ0K Pj4+IC3CoMKgwqAgcmV0dXJuIDA7DQo+Pj4gK8KgwqDCoCByZXR1cm4gaW5pdF9lc3BpX2RhdGEo KTsNCj4+PiDCoCB9DQo+Pj4gwqAgc3RhdGljIGludCBpbml0X2xvY2FsX2lycV9kYXRhKHVuc2ln bmVkIGludCBjcHUpDQo+Pg0KPiANCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo= From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:32:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:32:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105072.1456039 (Exim 4.92) (envelope-from ) id 1ut6VX-00046j-FM; Mon, 01 Sep 2025 15:31:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105072.1456039; Mon, 01 Sep 2025 15:31: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 1ut6VX-00046c-Cg; Mon, 01 Sep 2025 15:31:47 +0000 Received: by outflank-mailman (input) for mailman id 1105072; Mon, 01 Sep 2025 15:31: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 1ut6VW-00046W-19 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:31:46 +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 c4315227-8748-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 17:31:44 +0200 (CEST) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-45b7ebe667cso27437205e9.3 for ; Mon, 01 Sep 2025 08:31:44 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e8ab093sm166520455e9.22.2025.09.01.08.31.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08:31:43 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c4315227-8748-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756740704; x=1757345504; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/LCK3BYblwS3dsjFLWuWr7rz3GUXXMtWjPl9RMAgLf0=; b=UR2FT+icR83dTcjOgYHfVgR7dOtHAvNizDlauOcMsUCauz/o0DC02s2FWbowM3Yw5B CPUmL5lGenKorgoaN01d1eLQ8tFurNIngXkNlD1cEm29+GbZ71tSyfjztY/U8MVZgC1x vaG70lk77ISBOxHpng1p9gsjUzCbaAya7cgdg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756740704; x=1757345504; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/LCK3BYblwS3dsjFLWuWr7rz3GUXXMtWjPl9RMAgLf0=; b=tpQoBrGnC7QfNHb967uE6xob/4rndH5cXg5UwUZIoVBNjBiHZ6wgEGtW6FfEzwbL+M HYb1Pm7N4Z8KDZOz6jQ5xy+u4MYrnrwx/vwYTgkGuOJ+Qjq/aaaLkDe9mZD7LViEfY/A rqVCaPYVupowcOf9PGBe/lmTzEEtArLu8FOrEbAuNo0M1ecd0YmBSghYrqxMf3C+mkJH 1OSLL5ZaGXfRx0lSWAvOqIjQyHX4yiD8JLAlSiBYZpFIR1szp1cvp14oIstV/jLBxSPQ S2RBxHwP7cIVvmwZCaILPyK6bxZPMglYXHTLtb7BS4bHFPvM2egm/9LGV9ix2qzkLYS0 m5kw== X-Forwarded-Encrypted: i=1; AJvYcCWXrfxg2ioizP2+QQMJo5lHjzGWsdS76xpGgt7TEDOOSinmaBff6gcen/lt2ajiOXp/Ru6GXoLVeIg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwY4uzAGzSZtHbVFx+Y6/sQQFCDqs4gbbFMlQ/pH6DZ+GyHxtlm 2qiPSM9DS89pXa+rmbdHYPqbov2X+3GQpaYNgjWibSWodrkGy/paciMHItvijP/UYPo= X-Gm-Gg: ASbGncsxbm2EPMg/zRmKOY3o2eeLYdml+k5o29yq4x7Tt88Q7hGL0OG+vxadkMHW2Og MAKibHX+ZKpOXDLUz+5DBBu5h7hR675xRKCm89pIOnwiLTiGOllMxqltOs5B8rGipvF74uMZY3+ hljiTEXvz6JHWSJkZrHN6m6tyKXe7k+jUECPPahwQ5AFKPjlguGLeQKJYg1UFvmik+u/Jw+k3yB wkFbdCEy1pg1hRkZyUR0sYADuVTTBpaBPoKpF5OnP0KDQFJDNejr6gFeP7gjJ5U+2HoVEldv17L N5PIUFtHCyMTp29DmFNNON7AzSSyNk1J+rfb9I/r3kmtwK8g26QyP/FtZWi74OuTIVFnTZ2cUOb gb7PWob4ENkebyh1M/02aCrgAE4nMzXED8KIesuo+Q37Zbfdi5f5h0zj05R1SF6L0dd89MOsGq5 z3q/U= X-Google-Smtp-Source: AGHT+IFY+lKnQqiijWQO976vlEf/aScdW0PLwWCX2h63TfumaSkKsvmwXGy4fzJl41KaVXv4USystQ== X-Received: by 2002:a05:600c:1d07:b0:453:2066:4a26 with SMTP id 5b1f17b1804b1-45b8553417fmr85561705e9.16.1756740704281; Mon, 01 Sep 2025 08:31:44 -0700 (PDT) Message-ID: <677b8273-af33-4652-b81d-cf0748722515@citrix.com> Date: Mon, 1 Sep 2025 16:31:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/23] x86/traps: Set MSR_PL0_SSP in load_system_tables() To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-7-andrew.cooper3@citrix.com> <2ae92f1c-da23-42d0-a1cc-70dff04310cd@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: <2ae92f1c-da23-42d0-a1cc-70dff04310cd@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/09/2025 10:23 am, Jan Beulich wrote: > On 28.08.2025 17:03, Andrew Cooper wrote: >> FRED and IDT differ by a Supervisor Token on the base of the shstk. This >> means that the value they load into MSR_PL0_SSP differs by 8. >> >> s3_resume() in particular has logic which is otherwise invariant of FRED mode, >> and must not clobber a FRED MSR_PL0_SSP with an IDT one. >> >> This also simplifies the AP path too. Updating reinit_bsp_stack() is deferred >> until later. > This last sentence looks to be ... > >> No functional change. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> >> v2: >> * Extend comment about clearing the busy bit. >> * Move reinit_bsp_stack() hunk into this patch. > ... stale, according to this. Other than that: > Reviewed-by: Jan Beulich Oops yes.  I'll drop. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:33:42 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:33:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105082.1456048 (Exim 4.92) (envelope-from ) id 1ut6XM-0004c4-Q9; Mon, 01 Sep 2025 15:33:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105082.1456048; Mon, 01 Sep 2025 15:33:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut6XM-0004bx-Nf; Mon, 01 Sep 2025 15:33:40 +0000 Received: by outflank-mailman (input) for mailman id 1105082; Mon, 01 Sep 2025 15:33: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 1ut6XL-0004bp-26 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:33:39 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 07a39ec5-8749-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 17:33:38 +0200 (CEST) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3d87cea889dso422616f8f.1 for ; Mon, 01 Sep 2025 08:33:38 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3cf33add7f2sm16754817f8f.32.2025.09.01.08.33.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08:33: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: 07a39ec5-8749-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756740817; x=1757345617; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zx2QQAvvVcXJNlgzbTF7FYeXSqopqU3LUDHZrsk1Pcg=; b=D8pWEnwCAuR2bdfTJC7AmQ4Yh97i6q9RYuCJVYM3RHlyCREKBDBvUPDkT084IRfn9r uVFV/k8FghakBtGXkqx+FgAEnboI1YGfU1lva12IBYhmW0500B94JGEZltmRxrk7UqvN TqzP/4NT0Yr6kFnAssvo6Nu2OL0aI4iqG5p9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756740817; x=1757345617; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zx2QQAvvVcXJNlgzbTF7FYeXSqopqU3LUDHZrsk1Pcg=; b=kSeYX4J/ZLpIX2fyyLvfR282Jx1809XaY0gPBIJTY5RGs7Q2jNbskbCi4KwjJ45JTu 4/Cfldnqh/OUixQPmj99HKAOfr+G4eAI7eeadA1+cf3T5A6lM7wt3zfoSgGjYsoN5EZ/ kA6xCO1gNLEzYeQTSNsjaOF5HDEyHL8zAwZAwI1DuEtPdt/rkzD661ErWyxZ0lYbmcBr qeSe5tIn8XxJuSINJY77L3WmYA9xov66JC8eFUtJI/v6jPLc1bSNLYw01BqTi3ON9U79 wDCP/hdaLzHwsKSvkYcRQT+NL56dx6+/bIEAL7xB/VFjKb9cY08ZL0nClWux5YfalRpc xvrw== X-Forwarded-Encrypted: i=1; AJvYcCVHs8LqB7woLnIXkwJ95YSQN/47pzat3vid+uHEODTj4XO28HfHGwJ1Pb5/u7TegntrkeddW9EWy0Q=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz7Ltby616X5lt3oSNqeSq8v3fVmefQ2K9ZIRTNnR7MfJs0YrB+ kv9MaWuXMGVv8OG5dfI+shsK9+wAtorFZ150odjnXOqMe2ImSYcqqNa9a67yfWFeg5U= X-Gm-Gg: ASbGncu3lPrAH7lMxhm642Oqa1Mksve1JjGy5XLbuaB+/hwdp3H0j9PeEsZf0QR2Eae Hc+gAohZWbl032dVl+BDo5kCvc3sjFvwfo6mnnAWI4t17h4oAhsOYArULc+TbCYq1R+zmngUCgX FuExBU4BFr8K4vveRVT920IeecfwwOeRzEBv6RpT7GR8IBNpuwRoHJCD2U1wZ8mqtU0W++MZ8Vv ESfFd7rImDdSVgCZEnEyjBQ48HQ2Yy16WR09UrIDkPDJp+6uWwspvkjKkJ6tGLmSyXWmkyTVL1u kfqALpEkmEp3S6T21QqskzEBgk1Wftw/xPI114PyaLDQtFKwJS5yG/zoSPjQilK1eabmLzriKjq +el1ngHd6hNAU1EzHM9dOUY1EhVd9GJyC77Q8Yar92jOYfH9iBuKgzyYe5Xw2kblA4nBD005sIF ssR1E= X-Google-Smtp-Source: AGHT+IGOs+VZ+3Xdy9SE4ld36dNFPa9ZUwIp26qwrn9Ax5EVfBBoSD4ayc5003AnRO6SyvNX0MJVQg== X-Received: by 2002:a05:6000:400d:b0:3d7:7def:8437 with SMTP id ffacd0b85a97d-3d77def8d1bmr2277215f8f.38.1756740817398; Mon, 01 Sep 2025 08:33:37 -0700 (PDT) Message-ID: <18e139ce-36a5-4a0c-8a9c-440ef1c1e29f@citrix.com> Date: Mon, 1 Sep 2025 16:33:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/23] x86/boot: Use RSTORSSP to establish SSP To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-8-andrew.cooper3@citrix.com> <9322056d-9f09-4f5b-801b-6f0fdad5ead9@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: <9322056d-9f09-4f5b-801b-6f0fdad5ead9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/09/2025 10:28 am, Jan Beulich wrote: > On 28.08.2025 17:03, Andrew Cooper wrote: >> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void) >> if ( cpu_has_xen_shstk ) >> { >> wrmsrl(MSR_S_CET, xen_msr_s_cet_value()); >> - asm volatile ("setssbsy" ::: "memory"); >> + >> + /* >> + * IDT and FRED differ by a Supervisor Token on the shadow stack, and >> + * therefore by the value in MSR_PL0_SSP. > Beside not being overly relevant here afaict, is this last part of the sentence > actually correct? Patch 06 doesn't write different values into the MSR. It is correct, but also well hidden. #define MSR_FRED_SSP_SL0                    MSR_PL0_SSP I suppose I should should write MSR_PL0_SSP/MSR_FRED_SSP_SL0 here to highlight the logically different names for the two modes. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:34:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:34:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105087.1456060 (Exim 4.92) (envelope-from ) id 1ut6Xl-00052w-3M; Mon, 01 Sep 2025 15:34:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105087.1456060; Mon, 01 Sep 2025 15: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 1ut6Xk-00052p-Vh; Mon, 01 Sep 2025 15:34:04 +0000 Received: by outflank-mailman (input) for mailman id 1105087; Mon, 01 Sep 2025 15:34: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 1ut6Xj-0004tM-0C for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:34:03 +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 1592f918-8749-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 17:34:01 +0200 (CEST) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-6188b6f7f15so4776103a12.2 for ; Mon, 01 Sep 2025 08:34:01 -0700 (PDT) Received: from eddie5.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-61cfc4ea764sm7373058a12.40.2025.09.01.08.33.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 08:33: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: 1592f918-8749-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1756740841; x=1757345641; 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=SkV/EWqlMjB6eYN3RFARVl3XHpdsHdYCpFF8G2sSD/0=; b=acc4fHSSwLAsa+jVN1aLA23kRi0DEkPXR3KmuIKaKddsu5McO7TsqtWz/irxuDlMgU RcieCTXgnC6HEbk32VExSyRGRb0ogJbt4Lleyd2Yp6AzRQOQXRKlFvfqsB8YCU5r4uH9 6jEKXYlcKmZaZugJ35+1cn6pFx73RdsHWgCAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756740841; x=1757345641; 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=SkV/EWqlMjB6eYN3RFARVl3XHpdsHdYCpFF8G2sSD/0=; b=sAZ9zBzEK73/MroO//gxVi+rEqaVuJqW6wy8jTv9H+VlGtTugP7uFIpaa3re2HNXfc hUQoG4d4TLl0c9kaVzYEVleHkJ/ryIV6bHnfIrFS2YkyCOVLPexyK39rrmU14X3zZOeQ RK5ZrFMYUSaJBv2FvD5PNlwHfriLTIyqRzyNbILClwHMhgm3irXhRKXFTTy3BlXKfEFl +6obmqJcwjRNspSVn1QBFlQhGmXaPo3QFgoWEvQClTl4Kcb/gL0ll5law24waqhW7+br kJpF4ibWAsyAjbHTUWXJwfsChuI71yMXVb5dj1gZ48dDA9MBgVQU00CaXl5IYCBCMwV3 iyPg== X-Gm-Message-State: AOJu0YzesiXAzZT8zk9wBiv0dp9+GzzcwQVeNThRVsSPpvuzOin7MFRl oO0XH3lSr09IP8xhlBPQgb40VFwt3jTqW1rWVbByGzdpcYHYD2PD3xJDNbFrufzt9LSySdjT1Oq Scgjblpg= X-Gm-Gg: ASbGncsvqg+8eEoWgYJLzgrDF9FPQPF9W2++MMrXUOLK6O3dobZiot6I52Uf/pePyQt TvNWNc4G5a4iMlZ6tFm9lcY8+fUqUMgicWi8RcZYkMPXDdgrg9tdSCewvxohQ6W+rFC0cxM+YLl YHjIw++AZSKgocwZI3rmEt7mZwj1yvhJnflv9CFVcqh1GletqXBdneOQgTsllGn+vGlpwKUBLoC NrRDdbEsrdlydDQUFBZQQosiJuZd2W0WL54qhUBkt/CsiVy2d8Nz/bDXuAUts+imPzPgS46Ud2P gqyPXvN1V7beiNS4hCCDeb3gRbQZXX0SVYOK4ZNjeKnECewcuezs/3bwze0IaAuQOB61GAMhTcn 4TQRDEvIg+t+RLvd5wiGKjoFZkEGKIuCABjQAqFbq9OojgQ== X-Google-Smtp-Source: AGHT+IGNxLLbzDRvItyf0MI5zZUTSid+3QYnAt+zpw2eo9IzjWrJ0+/nueqa7YlRfyvr0BRQ9H2p8w== X-Received: by 2002:a05:6402:44d4:b0:61a:8e5c:f4ef with SMTP id 4fb4d7f45d1cf-61d26c33dd5mr6712403a12.18.1756740840603; Mon, 01 Sep 2025 08:34:00 -0700 (PDT) From: Gerald Elder-Vass To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Gerald Elder-Vass , Kevin Lampis , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich Subject: [XEN PATCH] efi: Use Shim's LoadImage to verify the Dom0 kernel Date: Mon, 1 Sep 2025 15:33:54 +0000 Message-ID: <766be642204043b779cef688ec0ca2f1d64313ad.1756740104.git.gerald.elder-vass@cloud.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The existing Verify functionality of the Shim lock protocol is deprecated and will be removed, instead we must use the LoadImage interface to perform the verification. When the loading is successful we won't be using the newly loaded image (as of yet) so we must then immediately unload the image to clean up. Signed-off-by: Gerald Elder-Vass Signed-off-by: Kevin Lampis --- xen/common/efi/boot.c | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 453b1ba099cd..67e7220d8fa3 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -36,8 +36,8 @@ #define SMBIOS3_TABLE_GUID \ { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} } -#define SHIM_LOCK_PROTOCOL_GUID \ - { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} } +#define SHIM_IMAGE_LOADER_GUID \ + { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} } #define APPLE_PROPERTIES_PROTOCOL_GUID \ { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} } #define EFI_SYSTEM_RESOURCE_TABLE_GUID \ @@ -66,9 +66,12 @@ typedef EFI_STATUS IN const VOID *Buffer, IN UINT32 Size); -typedef struct { - EFI_SHIM_LOCK_VERIFY Verify; -} EFI_SHIM_LOCK_PROTOCOL; +typedef struct _SHIM_IMAGE_LOADER { + EFI_IMAGE_LOAD LoadImage; + EFI_IMAGE_START StartImage; + EFI_EXIT Exit; + EFI_IMAGE_UNLOAD UnloadImage; +} SHIM_IMAGE_LOADER; struct _EFI_APPLE_PROPERTIES; @@ -1333,13 +1336,13 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL; - static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; EFI_LOADED_IMAGE *loaded_image; EFI_STATUS status; + EFI_HANDLE loaded_kernel; unsigned int i; CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL; UINTN gop_mode = ~0; - EFI_SHIM_LOCK_PROTOCOL *shim_lock; + SHIM_IMAGE_LOADER *shim_loader; EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL; union string section = { NULL }, name; bool base_video = false; @@ -1590,12 +1593,24 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, * device tree through the efi_check_dt_boot function, in this stage * 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 ) + if ( kernel.ptr && !kernel_verified ) + { PrintErrMesg(L"Dom0 kernel image could not be verified", status); + status = efi_bs->LocateProtocol(&((EFI_GUID) SHIM_IMAGE_LOADER_GUID), + NULL, (void **)&shim_loader); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"Error LocateProtocol IMAGE_LOADER", status); + + if ( kernel.ptr ) { + status = shim_loader->LoadImage(false, ImageHandle, NULL, (void *)kernel.ptr, kernel.size, &loaded_kernel); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"LoadImage failed", status); + + // LoadImage performs verification, now unload it to clean up + status = shim_loader->UnloadImage(loaded_kernel); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"UnloadImage failed", status); + } efi_arch_edd(); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:36:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:36:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105103.1456068 (Exim 4.92) (envelope-from ) id 1ut6a5-0005fI-CY; Mon, 01 Sep 2025 15:36:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105103.1456068; Mon, 01 Sep 2025 15:36:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut6a5-0005fB-9x; Mon, 01 Sep 2025 15:36:29 +0000 Received: by outflank-mailman (input) for mailman id 1105103; Mon, 01 Sep 2025 15:36: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 1ut6a3-0005f5-RK for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:36:27 +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 6badfe43-8749-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 17:36:25 +0200 (CEST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3cf48ec9fa4so2276437f8f.0 for ; Mon, 01 Sep 2025 08:36:25 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3cf270fc496sm15946333f8f.1.2025.09.01.08.36.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08: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: 6badfe43-8749-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756740985; x=1757345785; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=qa/Hedt3Y8zuBYIdTot2jnq+2kQydTcFXmUh1zEBTEs=; b=iIsHKqG2zqSAgd27kCPc0KIIhlA2aBAYwQYEJSKhehFWfAsW5Cuz4K08el3jI72xPV XsgF7Yknw5oP2qCbyN7neCyNUIbMGZItZqLpV3wOBhDGDiqepEbuPiq32nxE+Fxp2rcC RlzQSgZmG3gz6AuBx9xPs2wUnd+nzdf0qfyfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756740985; x=1757345785; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qa/Hedt3Y8zuBYIdTot2jnq+2kQydTcFXmUh1zEBTEs=; b=Xu/4YZJhbZwTQ8Vyt/1K/BLyW6OTaxR5usRcibbfVZe7G9Lp/oI0B/eGh4RKeiic0L 77tHwoiwH8Z8iO+7W7iPsVHVGLmuXS1ZT7kNMiW/dQorHPGaYOTR1/mCxChbFERd7Yu1 O/idILgsn8vcw6BcAHgHsNlrgJee9mf/hP5+P2Zex3OtRggY+hcCQ1rbGaLJPUiUzHfo lCl0pnoS2U0XdfANEKMqTIVPj6bz6rpR/qA3I0wrnMb6O61biV4qeUGVmnx7068rL76c bTLZ1LuBpRTnE9sD4tNpQGmcfO6ExEAuyXXuF/SsYtqI9lOsbHoccvmLATOOSI5N+1Hp cB9g== X-Forwarded-Encrypted: i=1; AJvYcCXRotPU2BgRmdwanSutc494rSCfHVu5UvEzGdrssXsagimSYNB9q4VeRkLvGU0uphMJbqNmm7kARUs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwLc1dz966v2btEsu3EnCp28JhO1cqCxcnRx7bLruv5PzzxzE5r xAEV6YCgkJzuzuPz99cpw2cUUzzINfoGBhg/V+vWOzLVg1UiCgi5SeV1TaKTo07FQ0doylfT586 OoVK8 X-Gm-Gg: ASbGncv8w3+ede2e1ghUTmveLnTguI9Nb20W6WEXuU4nRsczbZ1l9+UrMtS8lq83SrA ieFAV1M24B86kwMLXtFSYSbPpwuKX71olLCIVcbFGdqD4RcgD7sS2bARbq9rsx+wdIDwQIF1wkc qVgtBYyPLkdYF5uk2Jv5rwrP/xXfoDEluD4WaVaDbyuT3arNRAkDMyth7JUSE8IqfDNrUEgRhrz GxhsARS5WDUvysNDRK4I3Mw7UT6kl4x/S+qbkSB9aOKZ4CNLF+LctBmnCXn+KAFAl8+c/Kj2B7P XPGPiy4IHRyFg6TbDUSgRBWpkbKmttZisROqa3dKeeydRv1Y/0puAcm1A5AYZw6K5BLo/a09478 mSuoEL/DG7Ku8ZCEHOgTXBzsiJIlM/QuzqtMuvM2Td+aLH9a4U10WFcYeWpVfMotpglut X-Google-Smtp-Source: AGHT+IHGTt2wR4EiP5O1Cc3QdCgxuLmSpcMi+zAjU3yrs+h0FBBdwM6ig6rltchyXJYWTQYFqsIm2A== X-Received: by 2002:a05:6000:25ee:b0:3d6:92ed:cae8 with SMTP id ffacd0b85a97d-3d692edce86mr4181226f8f.34.1756740985253; Mon, 01 Sep 2025 08:36:25 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 16:36:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/23] x86/traps: Make an IDT-specific #PF helper To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-12-andrew.cooper3@citrix.com> <5c0cb015-b2e7-467d-9c1f-2314bcb66ad6@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: <5c0cb015-b2e7-467d-9c1f-2314bcb66ad6@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/09/2025 10:46 am, Jan Beulich wrote: > On 28.08.2025 17:03, Andrew Cooper wrote: >> FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2 >> manually. >> >> Rename do_page_fault() to handle_PF(), and update it to take cr2, still named >> addr for consistency. >> >> Introduce a new handle_PF_IDT() which reads %cr2 and conditionally re-enables >> interrupts. > Why does this IRQ-re-enabling move to the IDT-specific function? Do you intend > to do the re-enabling yet earlier in FRED mode? It is updated in a common path under FRED. #PF (and #DB but that didn't get updated recently) are the weird cases IDT mode. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:41:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:41:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105119.1456080 (Exim 4.92) (envelope-from ) id 1ut6f1-0007Lv-1t; Mon, 01 Sep 2025 15:41:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105119.1456080; Mon, 01 Sep 2025 15:41: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 1ut6f0-0007Lo-U3; Mon, 01 Sep 2025 15:41:34 +0000 Received: by outflank-mailman (input) for mailman id 1105119; Mon, 01 Sep 2025 15: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 1ut6ez-0007Li-PC for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:41:33 +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 22016f03-874a-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 17:41:31 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b0439098469so126492466b.1 for ; Mon, 01 Sep 2025 08:41: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 a640c23a62f3a-afefcbd9090sm880311066b.69.2025.09.01.08.41.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08: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: 22016f03-874a-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756741291; x=1757346091; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=BoC7DuQfIrzZ2uAuJOP6ZRGrjvn0NPG7Yk/TUsrJuNw=; b=KKsL1ZAD+UdqsTKJ5MMqhwjLx8iXpq1HLZ7w8yd8W4D9KusBdCa+jIkmO1WpZ/ZKJW esJ6qyD1WzbjgG+TViR/pZc7LILpVnOSX6oUQCNW99xhmBMYVMKvnQRJYf2LixPHEljz yzwxeqQ5JKh3utoMcAOniaBYp6X7L5jTRmtYra9knRFhzMXDfT8aEH75hOU9o0mMMqHO OV2gsSBE0v8iIEiNGqnEGcCQd22R+Wbc7m2Af48sIdrGk1uavOcCoKSR2MLt6wJZmb0w 9zQ27n+IPgM0AYFlnjUpl5P0uSj2qcXLd5wiTJVOitVaPWXLbMUeiTGd7mI9AGLhcAs9 uAog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756741291; x=1757346091; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BoC7DuQfIrzZ2uAuJOP6ZRGrjvn0NPG7Yk/TUsrJuNw=; b=aoWFMJ+Q9okxrvpl/iJDJjFKmcbXDd0bVX68+7ljBtAxNvlvnsrn7zNLUyFpIMUydM viVL0HJQWEAYr+KK9IHew+GU5OQQuPm9ykoLUIwm1AWOqyAigVPbgTkRjS/i3e9vXngE +rcJ9qjM9nxaX2tOlKUEBE+b2BDwebgacACR+WsQiEPQKmd6aWG7n+tuqqobowzEWh5g ddf0HHPYbyLi5B5BsGQWEKfr7W/uB0KtIzs7XqF4o/y/QK+NKh+iOUgyWgQm8KhkOKzm LkYyVul25+D3/lOWIdDogvUNDbArWtFJeA4Meo/bUZgPy4Wb4uvq/NjYeeVEg85+BYL2 x6BA== X-Forwarded-Encrypted: i=1; AJvYcCWGTNKJcA5Om4WGD2YpwxsxGSyYfWHfWtk8h3mSUgShyO605PFTET+Lzhx6PYkrfJyn6KwIIpnSPQs=@lists.xenproject.org X-Gm-Message-State: AOJu0YyJhYNBEfMYXj4BaTeQWVCHlZ+afdZDUOJNZdLCYcIqAZgbKrcq r6BLtUQgHGaMdG0TiJBfyhJrC5wyCQNYX9TZN2ppgNjqz1v+SiEBIvczE2K1kJNgOQ== X-Gm-Gg: ASbGncsLx90kzv19RwG7lS/M7vkJZUiBtrAFmiqUvt7+Y0xWYgXNE87XnwT6x7piA98 ISLGL5SlLp5aOuqICshuHxDyvi2WodjkclBZ0G+hg3b5R7EIfU1Qfy8upfB243CZByymJRUCYED AlohOrg+vy32zMzXzO5/g1InHSwniJflL6U5T9iAy73L1Z4l7uAdkLOrjuEloiZvnlOyyKrGIFZ 4Df1o8uCNZG3+CkduMKlW4dleJxizgRQh5NyUlrJlpHXF+VQ9E0ch2jRGJOFg0bCWYWVh4IqzEE kLTNVVp64McauRPG47hYmKOlFtrj3J4nIhUS7z3ejWb9UXQBjDiMKf2ORmSZ1/d3+KCDCho061n byvdF74yWwvPwZYno6WsuCCLJtBio5PMyRkPMy2/BZcMfs2kUB8zU7TbkWlheIMrnl7jqFMIE0A ojadGRPc8= X-Google-Smtp-Source: AGHT+IGnfOtKS908xhNyz6cgFpiKlHaYjl6FYJcJJCvkVHb3nUF+T2Zh0ZMTY8AwaaG0bBdS+9+tEA== X-Received: by 2002:a17:907:7209:b0:afc:d3f2:6061 with SMTP id a640c23a62f3a-b01d8a6b819mr849626466b.14.1756741289736; Mon, 01 Sep 2025 08:41:29 -0700 (PDT) Message-ID: <595a24ff-9eb8-40f3-9108-dca02e5a7a2c@suse.com> Date: Mon, 1 Sep 2025 17:41:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/23] x86/boot: Use RSTORSSP to establish SSP To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-8-andrew.cooper3@citrix.com> <9322056d-9f09-4f5b-801b-6f0fdad5ead9@suse.com> <18e139ce-36a5-4a0c-8a9c-440ef1c1e29f@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: <18e139ce-36a5-4a0c-8a9c-440ef1c1e29f@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01.09.2025 17:33, Andrew Cooper wrote: > On 01/09/2025 10:28 am, Jan Beulich wrote: >> On 28.08.2025 17:03, Andrew Cooper wrote: >>> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void) >>> if ( cpu_has_xen_shstk ) >>> { >>> wrmsrl(MSR_S_CET, xen_msr_s_cet_value()); >>> - asm volatile ("setssbsy" ::: "memory"); >>> + >>> + /* >>> + * IDT and FRED differ by a Supervisor Token on the shadow stack, and >>> + * therefore by the value in MSR_PL0_SSP. >> Beside not being overly relevant here afaict, is this last part of the sentence >> actually correct? Patch 06 doesn't write different values into the MSR. > > It is correct, but also well hidden. > > #define MSR_FRED_SSP_SL0                    MSR_PL0_SSP > > I suppose I should should write MSR_PL0_SSP/MSR_FRED_SSP_SL0 here to > highlight the logically different names for the two modes. But the code following the comment doesn't access any MSR. That's what first tripped me up. It was only then that I wasn't able to spot the two different writes. Now that you point out the aliasing it becomes clear that until patch 14 it is simply impossible to find that other write. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:42:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:42:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105129.1456089 (Exim 4.92) (envelope-from ) id 1ut6gC-0007ra-9W; Mon, 01 Sep 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 1105129.1456089; Mon, 01 Sep 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 1ut6gC-0007rT-6t; Mon, 01 Sep 2025 15:42:48 +0000 Received: by outflank-mailman (input) for mailman id 1105129; Mon, 01 Sep 2025 15:42: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 1ut6gA-0007rL-Re for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:42: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 4e0b18f8-874a-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 17:42:45 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b0428b537e5so192677566b.3 for ; Mon, 01 Sep 2025 08:42:45 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b017e4b9ed7sm620198766b.90.2025.09.01.08.42.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 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: 4e0b18f8-874a-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756741365; x=1757346165; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=GYS3R48iHHv/+Et7qrkRueo6Lxdbvk4EmUuf6L//XdE=; b=bGYuXJSJ6Sp7N9B/Wbv/DxMPlkYk8ZiaagOJ5TBiPXSO41FI9sIcKFcimPqMweHpJT cZXuRD6LRYIdw6xV+w/bL0iWTZgvwxWrb0eqEvyGT/GF4z4pltGUUcNDxzG9/NaiS2X6 V1aqy7fwr27juf8V4eo+WuvmWUXUqfR+MTYj/XAOIl6kVilNTQwu9bRbqpvZz0UDvov2 nwabBmtnpAXMQG+a0f2piS7ICu+57bzAVjQDz6Z367RM0w/dH3savNVAlkLZ6AA25Yfr l/cPJS13r74jx9QSa8MYVhUnjgzffyJGwfRyk0eTW4pyueofIGKjB6xp+7aHkA5pFJor tViw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756741365; x=1757346165; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GYS3R48iHHv/+Et7qrkRueo6Lxdbvk4EmUuf6L//XdE=; b=Y1VMqVN75ssv1dZP+1kptm5M4gr7kEDSs9yxxD6vCda8PuToRABVYr4LPkQhtvbakl SPvBdHB66wSGxL547h7CktWGxydv5WROF9GnYP9ZTZBbtAk4I/axC2OovwynbQvXhGad OI2rclKmdEbBL9X4gNSrBX6S3Rpk6y+hfjTfBahT1yLt+aIZUFaIX83BMkgI/8la8dSh LoxhZiDQGm1UJxePfT0wWSpnJ7RSFort6Iag0uQG8rC0yS9brRon95UzLqwwkZY06cpw bW1xiTP45xrjg1F+fHgKVWEpwOOaAnABkgkEtU9H93Cfz9s29+ikUrYrA9X+deG041AE h2Jw== X-Forwarded-Encrypted: i=1; AJvYcCWHaKiq6c8p5sehrzGKdYs78gi5mt/mRZQ0Pj4/3HPeGQW5oxmNIZBD/a0A8ij0s4Ng+WQRpGif/qg=@lists.xenproject.org X-Gm-Message-State: AOJu0YxrBI67xzwd1XAIUqlJghqFhw9XOloszEWdklAiUlLQQS5WNNB5 Qr+5YR/F3QODuvUvmo9xqsNW49ZhCQncTLdIpKYcMmfypLPXyur7UQQwVDguPJ8pAA== X-Gm-Gg: ASbGncutOW9namjjwnMraiUoQoB212C3Bkr0LooAA/EvscYvSgiOlpjgf0GiUez2ytf MSik2FQMLHBr/rA2nRBiHyzc2sUoAVv38Vk58z7I+Phid2YEqniw+3IOpMuhDylHPh2S+jiJ+Lt veqhGcB7EFyAonhKMsp6GN1zPVaxKrdBb1g+rUj76+NAtve8ph3IfACt5zG4H68tdjrgIgmDqX+ 9o45B0yQU3yW9xkHpP4Qe6ChwGOubGQuKxOtWfKuhVsUlVjxdQTIfYTL+ytqNBpTp26Xc5rWHmg /IfQvGa3IGvwYBDJD+RpL73metgGkf8bcdiQ7dQQtnJphKPr/3SqYeAP/2ebMq/R1bieNgpRbnc FoBMcJbjxjvEmSo0sn5bG9Wg8rCjA7a5tHKS2prRLny07dgIEHtDxNrqnQPEXD/5JCKqTyNRevu 0cnSrgxATNeCegpGuX7w== X-Google-Smtp-Source: AGHT+IHZH3MbCLPqITuA/UyF9K4gcbiQz8hy22imFWRImz80dntjTlAT8fyuVl0ZiW2AqMw2FESY8g== X-Received: by 2002:a17:907:970e:b0:b04:3f61:aeda with SMTP id a640c23a62f3a-b043f61b010mr219212266b.63.1756741365091; Mon, 01 Sep 2025 08:42:45 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 17:42:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/23] x86/traps: Make an IDT-specific #PF helper To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-12-andrew.cooper3@citrix.com> <5c0cb015-b2e7-467d-9c1f-2314bcb66ad6@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 01.09.2025 17:36, Andrew Cooper wrote: > On 01/09/2025 10:46 am, Jan Beulich wrote: >> On 28.08.2025 17:03, Andrew Cooper wrote: >>> FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2 >>> manually. >>> >>> Rename do_page_fault() to handle_PF(), and update it to take cr2, still named >>> addr for consistency. >>> >>> Introduce a new handle_PF_IDT() which reads %cr2 and conditionally re-enables >>> interrupts. >> Why does this IRQ-re-enabling move to the IDT-specific function? Do you intend >> to do the re-enabling yet earlier in FRED mode? > > It is updated in a common path under FRED. Right, having spotted it the meantime: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:48:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:48:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105141.1456099 (Exim 4.92) (envelope-from ) id 1ut6ll-00009C-Sm; Mon, 01 Sep 2025 15:48:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105141.1456099; Mon, 01 Sep 2025 15:48:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut6ll-000095-QC; Mon, 01 Sep 2025 15:48:33 +0000 Received: by outflank-mailman (input) for mailman id 1105141; Mon, 01 Sep 2025 15:48:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut6lk-00008z-Up for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:48:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1ut6lj-001Dx9-2w; Mon, 01 Sep 2025 15:48:32 +0000 Received: from [2a02:8012:3a1:0:e5e9:9db0:73a2:cd65] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ut6lj-00C1vy-2x; Mon, 01 Sep 2025 15:48:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=hxVyG9pbLdUUXgWg15ovBtoL5TWNVgLUFEmlpQnGCv0=; b=LlqbTri3OKtQNSpprY01QKU1qg EY2mznl5MsskIXV/lu5jY01C8PkbnoOKUN2aR9fMjibnVSOBV9Gq/NxXqaDsEUApDYU3awPOUSaTk BjCN7tea8txFhSF2p1Xs+IPXwm6xc/J+nR1iKZ7Fz3o16r1pF9urRsdk5RyB1FbSG3JE=; Message-ID: <93768b97-a8d4-4b2e-ac59-a2175fcd46be@xen.org> Date: Mon, 1 Sep 2025 16:48:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for common operations To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <5f511d386c7f20b09106aa0202e0989477eff498.1756317702.git.leonid_komarianskyi@epam.com> <69bdbdac-4876-47de-b8db-ce6f3e1b7a24@xen.org> <8ad7cf86-ff85-4d56-b6b1-33fcb0dc0c54@epam.com> Content-Language: en-GB From: Julien Grall In-Reply-To: <8ad7cf86-ff85-4d56-b6b1-33fcb0dc0c54@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Leonid, On 28/08/2025 17:17, Leonid Komarianskyi wrote: > On 28.08.25 15:00, Julien Grall wrote: >> Hi Leonid, >> >> On 27/08/2025 19:24, Leonid Komarianskyi wrote: >>> Currently, many common functions perform the same operations to calculate >>> GIC register addresses. This patch consolidates the similar code into >>> a separate helper function to improve maintainability and reduce >>> duplication. >>> This refactoring also simplifies the implementation of eSPI support in >>> future >>> changes. >>> >>> Signed-off-by: Leonid Komarianskyi >>> Reviewed-by: Volodymyr Babchuk >>> >>> --- >>> Changes in V4: >>> - no changes >>> >>> Changes in V3: >>> - changed panic() in get_addr_by_offset() to printing warning and >>>    ASSERT_UNREACHABLE() >>> - added verification of return pointer from get_addr_by_offset() in the >>>    callers >>> - moved invocation of get_addr_by_offset() from spinlock guards, since >>>    it is not necessarry >>> - added RB from Volodymyr Babchuk >> >> Procces remark, here you said the Reviewed-by from Volodymyr was added >> in v3. However, given the changes you made this should have been >> invalidated (reviewed-by means the person read the code and confirmed it >> is correct). >> >> I see Volodymyr confirmed his reviewed-by on v3. So no issue, but this >> should have been clarified in the changelog. >> > > Thank you for your explanation. > Just to clarify: would it be okay to leave the RB tag (with appropriate > text in the changelog) if I fix some minor nit from another reviewer in > the next version, like in this patch? It depends on the change. In general, typoes or coding style changes (I include s/uX/uint_X) are fine to keep the review by. Anything else may need a review again. Acked-by are different because they don't carry a full review. So for slightly bigger change it would be fine to keep. But if the logic is fully rewritten, then they would need to be dropped. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:49:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:49:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105148.1456108 (Exim 4.92) (envelope-from ) id 1ut6mL-0000ca-3h; Mon, 01 Sep 2025 15:49:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105148.1456108; Mon, 01 Sep 2025 15:49: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 1ut6mL-0000cT-0q; Mon, 01 Sep 2025 15:49:09 +0000 Received: by outflank-mailman (input) for mailman id 1105148; Mon, 01 Sep 2025 15:49: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 1ut6mJ-0000c9-6o for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:49:07 +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 2ca4fd5b-874b-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 17:48:59 +0200 (CEST) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b0431c12df3so153055866b.1 for ; Mon, 01 Sep 2025 08:48: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 a640c23a62f3a-b02d8812161sm599091866b.73.2025.09.01.08.48.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08:48: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: 2ca4fd5b-874b-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756741738; x=1757346538; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+hPA0mW/bm6dUbRMya6CeQQl1OcdMHsjeOFXQMYk/+c=; b=e4ay2zBeCyjV3fixgNtm9FHX53lY8Xw8WXqLwy9PbGRzXi0DeyabR/jSZt4r6vNm9g vyidTmIOFoi8yHrKtE+lcy+BGaLZJz4zsmVAhXWjGhUF5tMWcWCt6ptkRVN1kTPti0w+ NKysu6ZmH9BqmwPbO0MyoG6tspkljKwTPlgscI2fqL3fZnzi0dlmFfXdtJpgLOVnK0Er LmnbCXFP+GDXiAptKP0YNQMDwmHspqk8qhAnwSLvjRKNzDDygFrGasVey2WOZdIx6ZP4 vCw2Vitlqh2V3RT/TXL+dvFObKEPOzkATNFwwNWS80EfS72oLXPReELcJBBAUO0eDybm 5Jmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756741738; x=1757346538; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+hPA0mW/bm6dUbRMya6CeQQl1OcdMHsjeOFXQMYk/+c=; b=RvzDVvvsYJO5vcVbblowK/im567kBEYonnjd0v8mB/GIUbZk7JNrt+JEs2dFY6EWUZ 9nld242yGBOnwKN2nFbSBwuGmzi8fOjQUuEVi6Fp8hn4DKFujdeR1Pk+x7kdI8LKDrcy Beu4SOgk0VWRky97L2qw4Qttx8fgcNb3YsyxQsxYNDPSP8vKlkrzuxgQKYYe3QrvvwBv REhNjP6B7asZPQNxIi89CukCVcozsFiHVFlNOUNlq+pSiEJMrbcuHTbEOtSHbvIn6qan 3hm9g6E6jGJqS6X2XtD7sGAHvMgCXudeNzLR6A64Jl46i8vJAmEZ9+ZPrjRrvgQX8aPT Pr1g== X-Forwarded-Encrypted: i=1; AJvYcCUsN+8AiJ9U6bkr6cs9dsNA9QcuG/hryAplBpO412TzjCm0WRibe5a4BMNYEiYr85CO+im3WNfsaDc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxX+3/dH++hxGwjvwcNZ/RN9f4tkaNyRxln9ldyBjyw0t/khoOW gfygdToOTTkZ3RUIUc3YR+LhJoc1vVprlgXzhYW3HetgEdfMMT5X3WG2eJICfwb2QA== X-Gm-Gg: ASbGnctylVKV1jCefrcLSin2XTQzGod+OKWA3uAbAvSkQxx65dbz7eLordpQaYYXrGR TOoIhoAR/f1FNiXnk0zIpfbrPPG/CI+Qzvtiz3b/MsruaMlf0opHk64sHApPpOBFBZ2jXl7E0vS 1rpvdY97KcM8K0QTn/YGqsmn1D6gB8rTvYFvRcVtA9GQUVTRsG+f92g5C18Rl2m3HYsPAG8Dk3O WmnRG4jtlR/7m87lSxPnvzsXsr7jn92nk4IDkduSpXKC65R1/NuAPDhN9W5/lZ++kav2goovBbi TDqQJRle06htMjIdUSSYKRRGkej8Y8TrgRvXJJLt25CZ82kPLlu1Vfh8Fb/VzRiFB+WvvyIKp78 niyCehNDOmGV/uMDJnP8IJbKCCi1KoA/qMuWsiACn8oOPZ6jiEmf6Chw8Wln5V95n+/abcRSKPt aFR7UvnpKEDPDGCnQZSg== X-Google-Smtp-Source: AGHT+IFu+oWE/Hh4nPjOIM6dPr4n/hwOkU9PeQYgS8C92nSRqtsBpidK+7wDtCDUDqLSvp3dDSfStA== X-Received: by 2002:a17:907:944c:b0:afe:d49d:2888 with SMTP id a640c23a62f3a-b01f20e0d46mr805705366b.65.1756741738527; Mon, 01 Sep 2025 08:48:58 -0700 (PDT) Message-ID: <0fa33a24-a6a4-40d9-88a8-af48350e1f4f@suse.com> Date: Mon, 1 Sep 2025 17:48:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 4/9] hvm: Introduce "fixed memory layout" feature To: Teddy Astie Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , xen-devel@lists.xenproject.org References: <640223e5e7ee18a73f62152dd27883bf5978fbfe.1755785258.git.teddy.astie@vates.tech> <5ba550db-5e36-4d98-bce7-cbb3e2d874b9@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 29.08.2025 15:32, Teddy Astie wrote: > Le 28/08/2025 à 14:30, Jan Beulich a écrit : >> On 21.08.2025 17:25, Teddy Astie wrote: >>> @@ -686,10 +691,31 @@ static int domain_construct_memmap(libxl__gc *gc, >>> /* We always own at least one lowmem entry. */ >>> unsigned int e820_entries = 1; >>> struct e820entry *e820 = NULL; >>> + uint64_t highmem_start = ((uint64_t)1 << 32); >>> uint64_t highmem_size = >>> dom->highmem_end ? dom->highmem_end - (1ull << 32) : 0; >>> uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 0; >>> unsigned page_size = XC_DOM_PAGE_SIZE(dom); >>> + /* Special region starts at the first 1G boundary after the highmem */ >>> + uint64_t special_region_start = >>> + (highmem_start + highmem_size + GB(1) - 1) & ~(GB(1) - 1); >> >> That is, inaccessible before entering PAE mode? > > Yes, I expect this to be only used by newer guests which hopefully > aren't limited to 4G range (i.e supports PAE or long mode). The issue of > trying to put that below 4G is that much of the space is already taken > for the MMIO hole, so that area would quite complicated with more > special regions. Which excludes any boot loaders simple enough to not even require entering paging mode. >>> --- a/xen/include/public/arch-x86/hvm/start_info.h >>> +++ b/xen/include/public/arch-x86/hvm/start_info.h >>> @@ -99,6 +99,13 @@ >>> #define XEN_HVM_MEMMAP_TYPE_DISABLED 6 >>> #define XEN_HVM_MEMMAP_TYPE_PMEM 7 >>> >>> +/* Xen-specific types (OEM-specific range of the ACPI spec) */ >>> +#define XEN_HVM_MEMMAP_TYPE_SHARED_INFO 0xF0000001 /* Shared info page */ >>> +#define XEN_HVM_MEMMAP_TYPE_GRANT_TABLE 0xF0000002 /* Grant table pages */ >>> +#define XEN_HVM_MEMMAP_TYPE_GNTTAB_STATUS 0xF0000003 /* Grant table status page (v2) */ >>> +#define XEN_HVM_MEMMAP_TYPE_FOREIGN_REG 0xF0000004 /* Suitable region for grant mappings */ >>> + /* and foreign mappings */ >> >> I question it being legitimate for us to introduce new E820 types. > > These E820 types are (at least in ACPI specification) in the OEM-defined > range which seems appropriate for me to use for Xen-specific mappings. Just that we're not an OEM. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:52:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:52:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105163.1456119 (Exim 4.92) (envelope-from ) id 1ut6pf-0002OP-IJ; Mon, 01 Sep 2025 15:52:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105163.1456119; Mon, 01 Sep 2025 15:52:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut6pf-0002OI-Eq; Mon, 01 Sep 2025 15:52:35 +0000 Received: by outflank-mailman (input) for mailman id 1105163; Mon, 01 Sep 2025 15: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 1ut6pd-0002OC-FX for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:52:33 +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 ab3d8fa5-874b-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 17:52:31 +0200 (CEST) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-61e8fe26614so2533114a12.1 for ; Mon, 01 Sep 2025 08:52: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-61cfc1c775fsm7582253a12.4.2025.09.01.08.52.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08:52: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: ab3d8fa5-874b-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756741951; x=1757346751; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=rYLyisd9bmPMm7TCrLfdkb3IkCPhuSy+bd/S5yno8yc=; b=Nn+4zdbmK3xkKDH5ZZhLU0d8U5vsImmagzG3dNsLWdqam6UQRJeflBWCFK/JpNXyf/ Gs52gvse4lGhemsV4Gs9a+LvVkp7sPzbfdZF2vfk+sIiYUIt6+Y0ZeBogfy2LbBGUdL3 t3FOvj65n+xMagJdHvgg6q17HVnekm/146d0uU2gv6/QRqEUF2nsQZKVOwMq03OItf80 r7mttqlaR+HA+dTPOYG5IO7eRatIz00y9cNPtaFHRxe61LrxVnAB85twN1oziBGg6G3D eyG6YDzGHGn7wm4Z1tjw5roYJ5QncIo6f98WYU4ML4Xjbj6npb1wNu2A0lbyri3ZVpbq FlYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756741951; x=1757346751; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rYLyisd9bmPMm7TCrLfdkb3IkCPhuSy+bd/S5yno8yc=; b=rmMqNREqPEFj3OE1xeQRvd9X7SxlaEPovjFcQUjIbJw0fUmzoab1LoJecXSDOVArEr zFSOC00B5a9ErEdJx+rqOM25YMuK3yCWFEIXGtTQTXT/i/QII+Y53lEpquZnbN0AiiH6 tMD24Jul/N1H+whPaaMg7zyj6ZC1RV0s8HMJ+/N41DtA42cD6SMuSvIMEQScIq8SaAap WMmohdPtt39FyP+pf7m7aHmYkzhqAo4TNrzZwrzydO2DPL0+3lwutrFwKNe3BS8rSzkJ fbwG3dfGd40t+eojMDAwAgp1gYjbaOfBhKBipbGjrdAttgiSjFfXgkRKYL8A+L5q8hQK iRUg== X-Forwarded-Encrypted: i=1; AJvYcCXfJZqp6QJ37jcgdpEoLg60LQBEIpufmWZAotR+1Nvi0LUXVListloUloeQbELJ/FBi2tVSsPZ43EA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzWsOeJB1qNLDex5Ffm4rNNp333IowQxoyqajkeT+ksZqk1+8cL O+3ancETa6UCVD8SgpbB9e/WFEdv12lDOoQIm1j1A18fKA7bHqu0g4yK+IYYiTEMAw== X-Gm-Gg: ASbGncvMI/d6qwr5hNg84JzaDJxEcgRX4wCiHq474V1nFfdIT23kkLLt6YMWV6DRH8e cg0FADYBIV5sgpAYttpnli5soSl/ady5VyiQL+tkkeYoYruhKHwqiEfqCWWnxYkF3nd7d4DmcFy V8KyF9fpRGflz3fhKdjfbg/qutqKI8nZlQNg/OB3AHqP4ahHy5kJ/wcNOmUcJswiR4H+qSH+4kz 21UaeLtRvrR4+AzSKnwExqYM41PoFHpDBF7uKfqNceWPjOm8vDqbDz7z51EzQXLWjD2J7eIemL7 bTOxYsF4oWdQNaVnpuJY1FLxhVA2fPPZnNHZeoWKyvE/sAOnsHseh8h3kpgTxG5nY0Xdle3bKir DHW6luV26J6lVBHLr8BOctK7ka7udfULRs3mmqzqxnbKuw9/Fu0ZCajsFrLHlbfNkIWxStAKVMR 77psbbNiU= X-Google-Smtp-Source: AGHT+IHRawh4zG+e4nfwX3uF1okGQnJjaQq4t9rpRDxT/TXijxTm1iO4ny3U+6tbR+9/1eubElm4ug== X-Received: by 2002:a05:6402:5210:b0:61c:9852:bbb0 with SMTP id 4fb4d7f45d1cf-61d26c3e514mr6521655a12.19.1756741950871; Mon, 01 Sep 2025 08:52:30 -0700 (PDT) Message-ID: <9695f099-456c-4ec0-9eaf-847134823353@suse.com> Date: Mon, 1 Sep 2025 17:52:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 5/9] docs/x86: Introduce FastABI To: Teddy Astie 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: <64800d22220f31bf052713ce61ecedeaa8a36b6f.1755785258.git.teddy.astie@vates.tech> <2fcdb264-15a3-47f7-915d-83d1c1e06765@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 29.08.2025 15:59, Teddy Astie wrote: > Le 28/08/2025 à 14:35, Jan Beulich a écrit : >> On 21.08.2025 17:25, Teddy Astie wrote: >>> FastABI is a alternative ABI designed with performance and coco-enabled >>> guest in mind. It is register-oriented instead of refering to C structures >>> in the guest memory (through a virtual memory pointer). >>> >>> It only focuses on kernel-side hypercalls, it doesn't aim to provide toolstack >>> operations. >> >> And even there it excludes certain pretty relevant ones, like many of the >> gnttabop sub-ops. As alluded to by a reply to an earlier patch, I don't >> think having an ABI for just a subset of the hypercalls is going to help. >> > > Many hypercalls are missing in current RFC, including the grant > map/unmap ones. Yet the built-in batching that these come with would make it particularly interesting to see how you envision to support them without needing to access guest memory. (I simply can't see how that could work.) Jan > But a part of the idea is to still having some > hypercalls out of scope (mainly legacy and toolstack-specific ones) to > reduce the complexity. > > Teddy Astie | Vates XCP-ng Developer > > XCP-ng & Xen Orchestra - Vates solutions > > web: https://vates.tech > > From xen-devel-bounces@lists.xenproject.org Mon Sep 01 15:55:51 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 15:55:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105177.1456130 (Exim 4.92) (envelope-from ) id 1ut6sk-0002zK-4v; Mon, 01 Sep 2025 15:55:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105177.1456130; Mon, 01 Sep 2025 15:55: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 1ut6sk-0002zD-0F; Mon, 01 Sep 2025 15:55:46 +0000 Received: by outflank-mailman (input) for mailman id 1105177; Mon, 01 Sep 2025 15:55: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 1ut6sj-0002z7-JF for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 15:55:45 +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 1e37465c-874c-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 17:55:44 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b043da5a55fso93288066b.0 for ; Mon, 01 Sep 2025 08:55: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 a640c23a62f3a-b042a4b3110sm280325466b.49.2025.09.01.08.55.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 08:55: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: 1e37465c-874c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756742144; x=1757346944; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wc1IbT75z30hfNaM4eYm7WwvCn86qqWn0tIobmwcmDU=; b=Zb+9Fj1cl6sxR1npZsgDL/RXabfau8fw0nfpPjBA40HAwMFIN2w7hlmrwQELfZlS7J fHRq4s5FDdTX66pV609pFCKSEkBquAx9cGet/XTnYqryAPDUfSIZGpZV84IhapPJM2aM 7plH3WosqrUdB7MBfJSwPlv6ckdEuRCgMRSu5F+3vO3sQv3oeK/xX0Xyu+SF7NyXvOGU aeg+8aonguDk2H77Ozi4upS67jYxJ3fADDzh33URZFfreuPNiAtFE8RpwiATq5d5Gomh GBsqCM+iLOlTYJ+35qG9wdNZeeUbq4BTzgI4sLyFP3HJV5tepRzOjq9QRFvQdkCmehal zTlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756742144; x=1757346944; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wc1IbT75z30hfNaM4eYm7WwvCn86qqWn0tIobmwcmDU=; b=PPHhJbZd5q5Qr/QoYc45tsLvIx0EZTr1k/H9U03AOy/FWOJxMCsUmzt512VDPJxo8U UFexs88Tk3602yv+RojjRisTFpAeuMr0dTFZZqlLKGhJIunTA4LrYGzDn7fm7mLxpNZR qN2mZCfPQzbhOhn9Ozmkke5HQbh/h6LOpXQog2UAQAfYHNSXEstfX751LNdEmCjkOIhm DKEidz0a+ScDuVls0ExcnpjtTqDdRlsx0j13wFHHzXIi4PftWWNubY9kW0H1bhcE7GER Dby0oT+L3SKwEsM/UABD2IUTNoE9Da1LTDJd72aj/dQFnZyzs3jP9IhsclK4jmj9fD+O kTDw== X-Forwarded-Encrypted: i=1; AJvYcCXAo4G8gaIq0JQYu2swY1xMJzY1n2EdW/ugTYW20cPVws13mlAmDesPUj9mJR9qExh5ZLr0Uy+d2N0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzt0pfKRDy1k0MPwAPrsIIRbzYX/oWBmZIYEAOyuHOi8n6pqbu/ 85J0/Eggrlt6RyllOJ8vsoNZ54Owzpieh8JqLpxza6eK8oBOR0EscsITm1Jan4KA5g== X-Gm-Gg: ASbGncsI1xrH8Z7C0aKj6hGhI88G6cR4pF+UfAlg+CsbM6DXXYDipDg+0kSxeZ3OJ0r Xg3bhrIYqPCOHQFUMt5/7XIqUttuYdvRwBFndGz9D9YpWdHZgxrVrYD0n0pi+bXCjvX3tRQ7ipA xA/XGceKl1qdQTNh+AGoPK4HUB8zDqW1fUfqjaiEUTnRMChWpPLSCEulxOBzyxvgE2iF7oCDOB5 Pm4wEg+xAK7AliMCqbU0jxm3d5sIJsG6L+XRhyLqR2LjEQdSmTTAhDtplgeZa8TEEuaJ7tsekRn bpD7KBSVAHli65xfxpONe2B8Z9wlf6RGjpVdkQH2qW0fNrLd+2lNu5qu3ergNBuHUE73eAqUDP2 32ccq84W7qVpexzyWDoc7bfUwl7J4YfNNd1B8K4Mp7d+WwxgPXehVQP+JXNMGCKx5PQXM/BnuDW W9PBSo3Lc= X-Google-Smtp-Source: AGHT+IFO5bSXwMTfEORZKm7GOoDf5t74C32F2t948i4P9mlKdH/mSSYWcXlP3Kk8Su7WE3RNlAPUfQ== X-Received: by 2002:a17:907:fd15:b0:afe:ef48:ee41 with SMTP id a640c23a62f3a-b01da23e859mr889305666b.58.1756742143856; Mon, 01 Sep 2025 08:55:43 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 17:55:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 1/3] xen: Define xen_domain_handle_t encoding and formatting To: Teddy Astie Cc: Oleksii Kurochko , Community Manager , 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 29.08.2025 11:58, Teddy Astie wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -11,6 +11,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11 > - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25 > - Linux based device model stubdomains are now fully supported. > + - Clarify guest UUIDs as being big-endian encoded. Is something like this really in need of having a ChangeLog entry? Jan > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -973,6 +973,13 @@ typedef struct dom0_vga_console_info { > #define xen_vga_console_info dom0_vga_console_info > #define xen_vga_console_info_t dom0_vga_console_info_t > > +/* > + * The domain handle is chosen by the toolstack, and intended to hold a UUID > + * conforming to RFC 9562 (i.e. big endian). > + * > + * Certain cases (e.g. SMBios) transform it to a Microsoft GUID (little > + * endian) for presentation to the guest. > + */ > typedef uint8_t xen_domain_handle_t[16]; > > __DEFINE_XEN_GUEST_HANDLE(uint8, uint8_t); From xen-devel-bounces@lists.xenproject.org Mon Sep 01 16:11:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 16:11:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105189.1456139 (Exim 4.92) (envelope-from ) id 1ut77o-0006VX-AZ; Mon, 01 Sep 2025 16:11:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105189.1456139; Mon, 01 Sep 2025 16:11:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut77o-0006VQ-7q; Mon, 01 Sep 2025 16:11:20 +0000 Received: by outflank-mailman (input) for mailman id 1105189; Mon, 01 Sep 2025 16:11:19 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut77n-0006VK-2K for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 16:11:19 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1ut77m-001Etf-0g; Mon, 01 Sep 2025 16:11:18 +0000 Received: from [2a02:8012:3a1:0:e5e9:9db0:73a2:cd65] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ut77m-00C2kZ-0h; Mon, 01 Sep 2025 16:11:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=O+uwXkWmJIqFCYhYk0EbVwGCQFr0La7xSx8HvhWQliI=; b=WFk02pcSrGWctjTxspPH/zgIF0 28om3MKX0+9oj051PDvkRCfG5E2s57FAmYojFxlxlIWTKmyVnb9oxroOkinUtQrbAsMyUostUNngh Cha6wTTquG82l7PODzu+DeXzEso5ImLb0oR7AFDxbGP8XzbPIaM8v3OJwcfHJo5oSgJI=; Message-ID: <2e91a95a-3109-46ae-b796-1a1c50a9ac2d@xen.org> Date: Mon, 1 Sep 2025 17:11:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Leonid, On 29/08/2025 17:06, Leonid Komarianskyi wrote: > Currently, Xen does not support eSPI interrupts, leading > to a data abort when such interrupts are defined in the DTS. > > This patch introduces a separate array to initialize up to > 1024 interrupt descriptors in the eSPI range and adds the > necessary defines and helper function. These changes lay the > groundwork for future implementation of full eSPI interrupt > support. As this GICv3.1 feature is not required by all vendors, > all changes are guarded by ifdefs, depending on the corresponding > Kconfig option. > > Signed-off-by: Leonid Komarianskyi > > --- > Changes in V5: > - no functional changes introduced by this version compared with V4, only > minor fixes and removal of ifdefs for macroses > - added TODO comment, suggested by Oleksandr Tyshchenko > - changed int to unsigned int for irqs > - removed ifdefs for eSPI-specific defines and macros to reduce the > number of ifdefs and code duplication in further changes > - removed reviewed-by as moving defines from ifdefs requires additional > confirmation from reviewers > > Changes in V4: > - removed redundant line with 'default n' in Kconfig, as it is disabled > by default, without explicit specification > - added reviewed-by from Volodymyr Babchuk > > Changes in V3: > - introduced a new define NR_ESPI_IRQS to avoid confusion, like in the > case of using NR_IRQS for espi_desc array > - implemented helper functions espi_to_desc and init_espi_data to make > it possible to add stubs with the same name, and as a result, reduce > the number of #ifdefs > - disable CONFIG_GICV3_ESPI default value to n > > Changes in V2: > - use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS) > - remove unnecessary comment for nr_irqs initialization > --- > xen/arch/arm/Kconfig | 8 +++++ > xen/arch/arm/include/asm/irq.h | 24 +++++++++++++++ > xen/arch/arm/irq.c | 56 +++++++++++++++++++++++++++++++++- > 3 files changed, 87 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 17df147b25..43b05533b1 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -135,6 +135,14 @@ config GICV3 > Driver for the ARM Generic Interrupt Controller v3. > If unsure, use the default setting. > > +config GICV3_ESPI > + bool "Extended SPI range support" > + depends on GICV3 && !NEW_VGIC > + help > + Allow Xen and domains to use interrupt numbers from the extended SPI > + range, from 4096 to 5119. This feature is introduced in GICv3.1 > + architecture. > + > config HAS_ITS > bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED > depends on GICV3 && !NEW_VGIC && !ARM_32 > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > index 5bc6475eb4..4443799648 100644 > --- a/xen/arch/arm/include/asm/irq.h > +++ b/xen/arch/arm/include/asm/irq.h > @@ -32,6 +32,13 @@ struct arch_irq_desc { > #define SPI_MAX_INTID 1019 > #define LPI_OFFSET 8192 > > +#define ESPI_BASE_INTID 4096 > +#define ESPI_MAX_INTID 5119 > +#define NR_ESPI_IRQS 1024 > + > +#define ESPI_INTID2IDX(intid) ((intid) - ESPI_BASE_INTID) > +#define ESPI_IDX2INTID(idx) ((idx) + ESPI_BASE_INTID) NIT: I would consider adding sanity check (i.e. ASSERT()) to confirm that both ``intid`` and ``idx`` are within the bounds. > + > /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */ > #define INVALID_LPI 0 > > @@ -39,7 +46,15 @@ struct arch_irq_desc { > #define INVALID_IRQ 1023 > > extern const unsigned int nr_irqs; > +#ifdef CONFIG_GICV3_ESPI > +/* > + * This will also cover the eSPI range, as some critical devices > + * for booting Xen (e.g., serial) may use this type of interrupts. > + */ Reading this again, I still don't quite understand why we are mentioning Xen devices. Looking at the code, for Arm, we only seem to use nr_static_irqs to configure nr_pirqs and XSM. Both are ony used by domains. So I think this needs to be clarified. > +#define nr_static_irqs (ESPI_MAX_INTID + 1) > +#else > #define nr_static_irqs NR_IRQS > +#endif > > struct irq_desc; > struct irqaction; > @@ -55,6 +70,15 @@ static inline bool is_lpi(unsigned int irq) > return irq >= LPI_OFFSET; > } > > +static inline bool is_espi(unsigned int irq) > +{ > +#ifdef CONFIG_GICV3_ESPI > + return (irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID); > +#else > + return false; > +#endif > +} > + > #define domain_pirq_to_irq(d, pirq) (pirq) > > bool is_assignable_irq(unsigned int irq); > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index b8eccfc924..61c915c3f9 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -19,7 +19,11 @@ > #include > #incl#ude > > +#ifdef CONFIG_GICV3_ESPI > +const unsigned int nr_irqs = ESPI_MAX_INTID + 1; > +#else > const unsigned int nr_irqs = NR_IRQS; > +#endif NIT: I think you can use: const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI)? (ESPI_MAX_INTID + 1) : NR_IRQS; That said, I think we need to rethink about the use of nr_irqs and nr_static_irqs because they don't entirely make sense for Arm as we don't support PIRQs. I would at least try to get rid of one of the variable (maybe nr_irqs) if not both. This could be done as a follow-up. > > static unsigned int local_irqs_type[NR_LOCAL_IRQS]; > static DEFINE_SPINLOCK(local_irqs_type_lock); > @@ -46,6 +50,53 @@ void irq_end_none(struct irq_desc *irq) > } > > static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS]; > +#ifdef CONFIG_GICV3_ESPI > +/* > + * TODO: Consider allocating an array dynamically if > + * there is a need to enable GICV3_ESPI by default. > + */ I know this was suggested by Oleksandr, however most likely distro will want to enable this feature so they can be booted on a wide range of platform. So I think "if there is a need to enable GICV3_ESPI by default" should be removed. > +static irq_desc_t espi_desc[NR_ESPI_IRQS];> + > +static struct irq_desc *espi_to_desc(unsigned int irq) > +{ > + return &espi_desc[ESPI_INTID2IDX(irq)]; > +} > + > +static int __init init_espi_data(void) > +{ > + unsigned int irq; > + > + for ( irq = ESPI_BASE_INTID; irq <= ESPI_MAX_INTID; irq++ ) > + { > + struct irq_desc *desc = irq_to_desc(irq); > + int rc = init_one_irq_desc(desc); > + > + if ( rc ) > + return rc; > + > + desc->irq = irq; > + desc->action = NULL; > + } > + > + return 0; > +} > +#else > +/* > + * This function is stub and will not be called if CONFIG_GICV3_ESPI=n, > + * because in this case, is_espi will always return false. > + */ Is this is not mean to be called, then can we only define the prototype like we do for __bad_atomic_read()? > +static struct irq_desc *espi_to_desc(unsigned int irq) > +{ > + ASSERT_UNREACHABLE(); > + return NULL; > +} > + > +static int __init init_espi_data(void) > +{ > + return 0; > +} > +#endif > + > static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc); > > struct irq_desc *__irq_to_desc(unsigned int irq) > @@ -53,6 +104,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq) > if ( irq < NR_LOCAL_IRQS ) > return &this_cpu(local_irq_desc)[irq]; > > + if ( is_espi(irq) ) > + return espi_to_desc(irq); > + > return &irq_desc[irq-NR_LOCAL_IRQS]; > } > > @@ -79,7 +133,7 @@ static int __init init_irq_data(void) > desc->action = NULL; > } > > - return 0; > + return init_espi_data(); > } > > static int init_local_irq_data(unsigned int cpu) Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Sep 01 16:16:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 16:16:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105200.1456148 (Exim 4.92) (envelope-from ) id 1ut7D3-00077r-Ux; Mon, 01 Sep 2025 16:16:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105200.1456148; Mon, 01 Sep 2025 16: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 1ut7D3-00077k-RW; Mon, 01 Sep 2025 16:16:45 +0000 Received: by outflank-mailman (input) for mailman id 1105200; Mon, 01 Sep 2025 16:16:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut7D2-00077e-Hj for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 16:16:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1ut7D1-001F0a-03; Mon, 01 Sep 2025 16:16:43 +0000 Received: from [2a02:8012:3a1:0:e5e9:9db0:73a2:cd65] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ut7D1-00C2vz-07; Mon, 01 Sep 2025 16:16: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=784FlA7NSyJ0bdLjMwAPjShNutqQit3xLCgXDKwaExw=; b=urKYFlyBzPHuGTejPkUH1g2CTH Yjq9aaeVh69fwqGQsq/YTrv39CuGh4pCLIXcvO75YfLdSuyDJFf08RtUsOXzLhj3kzeriLr4tLJXE Y0pP8npmY/UUziqsYjmnUvf0N27Sl+sjRk/py5h3R6F3KVI9v6Xt+ZmydWmAzYHU8Jck=; Message-ID: <14f057e5-eb1e-4d10-87f9-98619fc30eb1@xen.org> Date: Mon, 1 Sep 2025 17:16:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Content-Language: en-GB To: Leonid Komarianskyi , Oleksandr Tyshchenko Cc: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel References: <87tt1pykqz.fsf@epam.com> <399bdb41-7938-4ed3-887a-c9bf6e0636ec@epam.com> From: Julien Grall In-Reply-To: <399bdb41-7938-4ed3-887a-c9bf6e0636ec@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 01/09/2025 15:42, Leonid Komarianskyi wrote: >>> Taking into account that with CONFIG_GICV3_ESPI=n we should never have >>> "irq" in eSPI range, do you really need this #ifdef? I think that >>> ASSERT_UNREACHABLE in espi_to_desc() is sufficient guard. >>> >>> Also, IRQ line number belongs to eSPI range regardless of >>> CONFIG_GICV3_ESPI, >>> value, so in my opinion is_espi() should always return correct value for >>> a given "irq". >> >>  ... I agree with Volodymyr's suggestion for is_espi() to always return >> correct value for a given "irq". >> >> > > I will fix that in V6. I am not sure about this. If is_espi() is not returning false with CONFIG_GICV3_EPSI, then the compiler would not be able to optimize code like: if (is_espi(...)) { return espi_to_desc(irq); } return &irq_desc[irq-NR_LOCAL_IRQS]; irq_to_desc() is called fairly often, so I would like to keep the code fairly optimized. An alternative would be to use #ifdef CONFIG_*. I don't like it, but it could be a compromise if Oleksandr and Volodymyr wants to push to remove #ifdef from CONFIG_IS_ESPI. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Sep 01 17:02:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 17:02:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105218.1456159 (Exim 4.92) (envelope-from ) id 1ut7vW-00053W-2q; Mon, 01 Sep 2025 17:02:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105218.1456159; Mon, 01 Sep 2025 17:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut7vV-00053P-W8; Mon, 01 Sep 2025 17:02:41 +0000 Received: by outflank-mailman (input) for mailman id 1105218; Mon, 01 Sep 2025 17:02: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 1ut7vU-00053J-7e for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 17:02:40 +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 76a88707-8755-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 19:02:38 +0200 (CEST) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-55f6b0049fbso3417973e87.0 for ; Mon, 01 Sep 2025 10:02: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: 76a88707-8755-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756746158; x=1757350958; 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=2yXguVzHvh08yNIktYepZOCHpmrKoT08r2kRg4ANyfY=; b=AzHm9vEfS93auHl8oBFu1tFjykKWCwZLtjKi6Zh0Fy6D6vTQGShUkUenbTOeOlB++y MvuxDGBE+qyXH8ETr72pKw7SvtAaHd4CQ+AULEo5g2mPBcutywVlBdYFeh6D5vV4LsG2 vl8+TFx4fvNbV28gt8IeaSqG8u4/wDtH5AxoDOU0KQdyE5/0xb90dB7FHy1haU8rED6h hbZj1iyrFuR5LLRKcnS8H+nNp7n2ptkY+wd94tJC/BIg/X+0BSqc16nZ3Fr3NPfprtH3 8EXdVkqHwFAyZUzVsr3lTV9PwwY+gnB3D61cjxG+E9XPl4YQbUG/KFsVvtUEj7vUCVSN FaMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756746158; x=1757350958; 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=2yXguVzHvh08yNIktYepZOCHpmrKoT08r2kRg4ANyfY=; b=q//cLwf49YpSW5FoaefJVSlmmC/qJhqELD/mFIayXvTfKGk+e9y5pVZQ95129db4Cr vy/phs0wD9NaU/zMf9WZ4+SNpBEFnim7CXuA2d2xpFXFnj6EfAkNAIk38BEMEiY98TxC 58qy7t6VLWUgLLL9rdlyG8yCJK5N80UsmYHBeJ+p0fuV+pk0RpEaAmZ++VgXLb/dnFDU ft6CFwbERosBrbrM5YdK7eMRKi7AT76EcvZ7KoRTUs/tDSBE5MYwwwD1O4STnhRo+iq7 gy57DMFyEN4g3Duz3NOJQJZnZz1tffd1ZUFYPl8BKRrFxDhnwR7x30PxSXzC5i0deovl 0ZYQ== X-Forwarded-Encrypted: i=1; AJvYcCW1XVbWsJBNaqtRo7HaBbJib3tsDFBT+28RjP8Lb5svH6UnGl+vyj5lrRVBsgP53oUA2P4ae5bxvy4=@lists.xenproject.org X-Gm-Message-State: AOJu0YyxSEZ2tgcPUwVqBPmO0qnnCM0LqABAaQbIkNAkUH45w1Txs6HE +D4kJ2lbklfmGGhbkUWU3cjE6n3SYLjhRKsaBPOEJGjzp3Nnl/Gf6N4JVxC0DEh2tZxEz8VHxaL OEg8B849F7ouTlL+64GMoMaIcM6csIy8= X-Gm-Gg: ASbGncs6Fvlw5Fuji2YcXv/BzST3wLo69ib39ywZj8Hx94ZWSnybqviRDTll2tQT4IX a13ferbN6adUsYe0fDxq2wP4Yb3OWDqQ2U/2PfCXh4BbbY4vIMMDYzBqaKBPIbCOjGdW1qKFOLm deZC6toUoDKOJdw4/oWu5Ga9PpDrPwfqgH2iSLf8rU3U/DIqUHhvpKd2SmBh7OuxmI5N3FZm7oF hb7yO5Mtjq0hu7/ X-Google-Smtp-Source: AGHT+IFpq5oh5tAc/zFSmTvNrjz0pfHuaJHfvXC0RE+QFOJBI3zTI9ALRmwdshv+2PgTOMDY0chO5NkX25EdJGToljw= X-Received: by 2002:a05:6512:258c:b0:55f:43ba:9410 with SMTP id 2adb3069b0e04-55f708b4592mr2396976e87.15.1756746157242; Mon, 01 Sep 2025 10:02:37 -0700 (PDT) MIME-Version: 1.0 References: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@suse.com> In-Reply-To: <80c8dbfe-5240-441d-84fc-603e9c5f9812@suse.com> From: Mykola Kvach Date: Mon, 1 Sep 2025 20:02:26 +0300 X-Gm-Features: Ac12FXzP5QZzLRXppI3dJsIHJTUoFU8UMfgp-ZGQtjm2zgTsgrGh6wCnBOYW_Po Message-ID: Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Jan Beulich Cc: Mykola Kvach , 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, On Mon, Sep 1, 2025 at 5:29=E2=80=AFPM Jan Beulich wrot= e: > > On 31.08.2025 00:10, Mykola Kvach wrote: > > --- a/xen/arch/ppc/stubs.c > > +++ b/xen/arch/ppc/stubs.c > > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *= d) > > BUG_ON("unimplemented"); > > } > > > > +int arch_domain_resume(struct domain *d) > > +{ > > + return 0; > > +} > > + > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > > { > > BUG_ON("unimplemented"); > > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > > index 1a8c86cd8d..52532ae14d 100644 > > --- a/xen/arch/riscv/stubs.c > > +++ b/xen/arch/riscv/stubs.c > > @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain *= d) > > BUG_ON("unimplemented"); > > } > > > > +int arch_domain_resume(struct domain *d) > > +{ > > + return 0; > > +} > > + > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > > { > > BUG_ON("unimplemented"); > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > index 19fd86ce88..94a06bc697 100644 > > --- a/xen/arch/x86/domain.c > > +++ b/xen/arch/x86/domain.c > > @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct domain= *d) > > hvm_domain_creation_finished(d); > > } > > > > +int arch_domain_resume(struct domain *d) > > +{ > > + return 0; > > +} > > + > > #ifdef CONFIG_COMPAT > > #define xen_vcpu_guest_context vcpu_guest_context > > #define fpu_ctxt fpu_ctxt.x > > I definitely don't like this redundancy, and even less so that you introd= uce out- > of-line calls. Thank you for your feedback. I followed the existing pattern used in other architecture stubs. > > > --- a/xen/include/xen/domain.h > > +++ b/xen/include/xen/domain.h > > @@ -109,6 +109,8 @@ int arch_domain_soft_reset(struct domain *d); > > > > void arch_domain_creation_finished(struct domain *d); > > > > +int arch_domain_resume(struct domain *d); > > I think this wants to move to a per-arch header, presence of which is che= cked by > has_include(), with an inline fallback define once centrally here. Would it be acceptable to use a weak function as the default implementation instead? This way, architectures needing a real implementation could override it, while others would use the weak default. > > Jan Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Mon Sep 01 17:17:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 17:17:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105229.1456170 (Exim 4.92) (envelope-from ) id 1ut8A0-0006kV-9s; Mon, 01 Sep 2025 17:17:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105229.1456170; Mon, 01 Sep 2025 17: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 1ut8A0-0006kO-5R; Mon, 01 Sep 2025 17:17:40 +0000 Received: by outflank-mailman (input) for mailman id 1105229; Mon, 01 Sep 2025 17:17:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut89y-0006kI-Rq for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 17:17:38 +0000 Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [2a00:1450:4864:20::22c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8e8f28a1-8757-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 19:17:37 +0200 (CEST) Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-336b908cbaaso28185851fa.1 for ; Mon, 01 Sep 2025 10:17: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: 8e8f28a1-8757-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756747057; x=1757351857; 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=UkIp5FBOplvRNED16mH/L/IUQT2gNT5m6KSv0hGQEeo=; b=Lv/q/6e3IgjSITHgUiL2eBoXWfwmzEFFAwzDQUvuhMYlHi3f7j1sOZRFCarVFkP7VH Dq+7SarVJ95AX4wSb6eCxPKZrLtLb/YoGQdDK6yEfoZdv0hcMe0ReUQBMNpYlEjJAgjS 4nAT0YdHumOj57B+YgVVK8O4JzqTPBiUqQDP19a7tOST73qdXtbnOA8M3g7tjLiU2Gvs +E/zrZqHfsQJGm7aVRJxg5zmLuGm7LiCkLK8JkAmrOkfi37GD7weyMmCfGiRagW8786j Ws7+N9NjfNQpXrwhPmKp8Ob/gHcKLHERXcirI1oC09F9hyDuPflojza7/tAN14Cq5Oes pthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756747057; x=1757351857; 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=UkIp5FBOplvRNED16mH/L/IUQT2gNT5m6KSv0hGQEeo=; b=GUTvdHqCkhuS61CVASrcKt05v+Mxro1CVS8C/BT3ycB/0RFWJA7vw5N6oP2HaxAHy1 A3MENJQC6n7VWGN04AGPGo3/pN8JQAH4GOA3zuH4paXslMX0BQ5ruRa3y5mXLdZ5lZlJ 2qLlU6xfpr/H/TvK2e9fUDho4NAiHRg6NANN3v3fWXnTZWU3hkWeMR67t3UhwOva0ES5 Gq3vt61UAUx5NBCJpUndiR9HJG5L0zuVGyyFtAV8zCQ9qOa9mfLO2IBCbe4vHlv+/w4k Nqj0dmL2369/BxJIF3dsX8g6nz3jm215KU1zby7PErKVNT16CERP3Ltfgh8d4LKvbEa9 noHw== X-Forwarded-Encrypted: i=1; AJvYcCU7lnIBkHIn7D2mFJp8k7PYddnXYnb3IdKQGgl8DmApN5s609LJPof8XSiU1lRdsMIS6+ymvyyQwLc=@lists.xenproject.org X-Gm-Message-State: AOJu0YwhJ7jFQuOskGFOO1Vec4RP0/ZNTzkYoqeZ66FGLQawAv3AdcSj 0VNnMnrUDZAXhbDJu+g0nArRXhVM/tqe+QyYuZAQ+TDEJbP2uMnDe4U8Q+GzhjBzXbD6IkqCDR+ EbBjMbQR7Vz7ZJOYfIr3xlpEEmJw4dFo= X-Gm-Gg: ASbGncv5Wq1v7yeDhgUCbQ4s/hsZo74zYmPzDk1VpxZgD9mV4XZ8/S8pai3t+9cuZqw ehhfgbi3aRcoxL7vTHVsrOKqWV9S0yuNdHRBKhPErCRSnBG7ov3dznMufvaLA8YIQyHzHHo2475 rCKE2CWHSAqvMlWBqG8hPtxzWW98ci/jEtuzVrnNjk24oK4bEdatjc2LjfB/2MMGW1FrzAD/SGi RqICw== X-Google-Smtp-Source: AGHT+IFo9af4hG7bQ4c7ZfB7Owzw2fmDVXcUkqMJrewTn3jGnI1yHdArdYdS4N+ZGnTQZofHZ+UDgDphVu3A0a/kLuk= X-Received: by 2002:a05:651c:2122:b0:336:dfab:51b6 with SMTP id 38308e7fff4ca-336dfab5cc3mr14866691fa.23.1756747056475; Mon, 01 Sep 2025 10:17:36 -0700 (PDT) MIME-Version: 1.0 References: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@suse.com> In-Reply-To: From: Mykola Kvach Date: Mon, 1 Sep 2025 20:17:23 +0300 X-Gm-Features: Ac12FXy_C9A6C8odzYjv7qIFykvGdYAWymZh3JegwkbsWtenB7H_YSK-3NhE1v8 Message-ID: Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Jan Beulich Cc: Mykola Kvach , 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 On Mon, Sep 1, 2025 at 8:02=E2=80=AFPM Mykola Kvach wrote: > > Hi Jan, > > On Mon, Sep 1, 2025 at 5:29=E2=80=AFPM Jan Beulich wr= ote: > > > > On 31.08.2025 00:10, Mykola Kvach wrote: > > > --- a/xen/arch/ppc/stubs.c > > > +++ b/xen/arch/ppc/stubs.c > > > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain= *d) > > > BUG_ON("unimplemented"); > > > } > > > > > > +int arch_domain_resume(struct domain *d) > > > +{ > > > + return 0; > > > +} > > > + > > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > > > { > > > BUG_ON("unimplemented"); > > > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > > > index 1a8c86cd8d..52532ae14d 100644 > > > --- a/xen/arch/riscv/stubs.c > > > +++ b/xen/arch/riscv/stubs.c > > > @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain= *d) > > > BUG_ON("unimplemented"); > > > } > > > > > > +int arch_domain_resume(struct domain *d) > > > +{ > > > + return 0; > > > +} > > > + > > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > > > { > > > BUG_ON("unimplemented"); > > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > > index 19fd86ce88..94a06bc697 100644 > > > --- a/xen/arch/x86/domain.c > > > +++ b/xen/arch/x86/domain.c > > > @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct doma= in *d) > > > hvm_domain_creation_finished(d); > > > } > > > > > > +int arch_domain_resume(struct domain *d) > > > +{ > > > + return 0; > > > +} > > > + > > > #ifdef CONFIG_COMPAT > > > #define xen_vcpu_guest_context vcpu_guest_context > > > #define fpu_ctxt fpu_ctxt.x > > > > I definitely don't like this redundancy, and even less so that you intr= oduce out- > > of-line calls. > > Thank you for your feedback. > I followed the existing pattern used in other architecture stubs. ... while I understand your concern about redundancy and out-of-line calls, I would appreciate more specific technical reasoning for why this approach is undesirable. Code review is most effective when it is based on objective criteria and project guidelines, rather than personal preferences. This helps contributors understand the rationale and make improvements that benefit the whole project. > > > > > > --- a/xen/include/xen/domain.h > > > +++ b/xen/include/xen/domain.h > > > @@ -109,6 +109,8 @@ int arch_domain_soft_reset(struct domain *d); > > > > > > void arch_domain_creation_finished(struct domain *d); > > > > > > +int arch_domain_resume(struct domain *d); > > > > I think this wants to move to a per-arch header, presence of which is c= hecked by > > has_include(), with an inline fallback define once centrally here. > > Would it be acceptable to use a weak function as the default > implementation instead? This way, architectures needing a real > implementation could override it, while others would use the weak > default. > > > > > Jan > > Best regards, > Mykola From xen-devel-bounces@lists.xenproject.org Mon Sep 01 17:30:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 17:30:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105248.1456179 (Exim 4.92) (envelope-from ) id 1ut8MB-0000zl-En; Mon, 01 Sep 2025 17:30:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105248.1456179; Mon, 01 Sep 2025 17: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 1ut8MB-0000ze-BE; Mon, 01 Sep 2025 17:30:15 +0000 Received: by outflank-mailman (input) for mailman id 1105248; Mon, 01 Sep 2025 17: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 1ut8MA-0000zY-Co for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 17:30:14 +0000 Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c202::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 50df6cce-8759-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 19:30:12 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by DB5PR03MB9908.eurprd03.prod.outlook.com (2603:10a6:10:48b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 17:30:07 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 17:30: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: 50df6cce-8759-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lJNTB3p4kdTtKua9wAalYtDuk6Nwe6432znXNfvy5jobF3lR9KCaTHMbQ1iuuBVxJ04u3Bvp+pbw2O8u/2aErsm+fvsp0M+Kp0fUHxjKp1sa6Wzlvt0trop6mfgQVyHxZ8HiaMEH9376LLAO6+OqVlb2bsgAhBPX1WlGrAonqGHQlVIsmW8LgNWVVif7mTQlUsSTim62SNyYkNlV9UH1rLPAlSGDXfHAQbIb+WEQzDFK9Ut7juDoNlRGDK+nl/cjks27g+i5s0uSpaMASiEwzXDONXJubKat9bLVE+/koDqMlZdoPdpceMVY2WC6SFvGCGtlOi85VyRs/Skpy61xVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mW71wZXru/eZ4p8nNe9KpiR/OmraqBpFO/2m0C4528g=; b=NUb/GOESTPPjW0xM1HkNcxQbqVRvJTYuB3mfQgYq/zkSdwM3s+tJ948OS1/EHJJRCPpl0PCQqi/oWp+3Vy+ymhKU0ZrLtwZP/w+3crRFtp3evH12m3fJJRPV1juRPsz2w3Ydjd88y1V8Wsc/mCT2eiX35Vnaekw4bMFGw/KYxLR8K1623Z0yrISzLZwjgIKFJoC/UPhD1utiHUS4oCnqkmKKWUR8UGkIVv5o2Gyn5/PmeZMokk50b6SriaEMVi6Ow7ihc9edUnCIyLPkTxwlbFVuWOJNp5LhzUI4Wws84P+eBtMh4Q8kM9PmMW5i8lzvQmoctarQznzrarRc+Ze7fw== 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=mW71wZXru/eZ4p8nNe9KpiR/OmraqBpFO/2m0C4528g=; b=s3GYoH7pT4OzbPVKOaim61v03469JQcjCDK7dpRX0DdmEl9FSg3BuvxLsSiYyasZMOBEc7zAdhc0UhPXrQmfzkZf/urjsODd00rK8B12o/PhRHHXuSaBJDXY+2mgKDKaxz1HcMyYZKxEQYliS+XjTrZTKJxKWM5IrzeOEofj+5MhIhLlhFkOXZGles0CwdXPV4+8+U5dAr9MukcmOK5Kc6ugLw96XDwE3gHH+l0stQQErrfjEG9QbI7CFTfAq9tOFf5jOL1xUECzlWqO/mLDcQZrLvNe/6EoUSMkscoezDPIBapoupuLgDAjCW+NtopyfrAIQv1o+uXTeZcOCX897w== From: Leonid Komarianskyi To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , "olekstysh@gmail.com" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 05/12] xen/arm: gicv3: implement handling of GICv3.1 eSPI Thread-Topic: [PATCH v5 05/12] xen/arm: gicv3: implement handling of GICv3.1 eSPI Thread-Index: AQHcGP7dC7+WoEN69k6endDrwJ322rR+mh0A Date: Mon, 1 Sep 2025 17:30:07 +0000 Message-ID: References: <87iki5yka9.fsf@epam.com> In-Reply-To: <87iki5yka9.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|DB5PR03MB9908:EE_ x-ms-office365-filtering-correlation-id: 29d47afb-fa0e-4e92-d210-08dde97d31fe 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?cWtodWRTNVF6Tkdld3ptK0pyN0JNaXpaS0k0R09KVjdmOFRTOXR2cUFtQUdS?= =?utf-8?B?ZG5vMUd1VmhXaFl6U3kxamFieFJGaU1VVG91NnU0aEV0VEpndXV4QllYZG51?= =?utf-8?B?U3Vxb0RRTStqcWJKR2lpS2FFdFVUOE1BNmpyRWt5U0pRSlo0WmdqVXZlU3Bi?= =?utf-8?B?WVZoQTlhdVR1NVMrb2ZyYkw1cWpuZU1rRENVdlBpRGY1K3BnUVhQL2paTEtF?= =?utf-8?B?UGI1UmNIK3FFZkxEanlneS83Z1FBMnlnVFRac1plWVRGSW1oTUkwWU05dHB6?= =?utf-8?B?S0U3c08xNUV0Zjh1SzR6ZENhcnNIK3NGTXZDNWJPcTNtdTdzZ2xPYUtXbW5D?= =?utf-8?B?Z2VNaGFuYWtla3h0ZnZvQXVEZTR2UnNtNmdXWVAvalBzdFY2TE85WEYzU0Y0?= =?utf-8?B?ek5mZnFSRWM1dHRJQ1pxMDRwRG9qSEl5dW5BdDNHbnBhdUNwSWlYN0NjTnJp?= =?utf-8?B?UDI2azlLNENsNlBlckVOSTVERk5HMSs2N1cxa0JQcndwV0dJVWZucXMrWnFr?= =?utf-8?B?eU5aei9ZM2p6aGJLbXV1TjY2cEhRZTFscVg2Uy9NV2U2cGs0ZDlER0FEeGwr?= =?utf-8?B?dTE4MTRBSldlQWdaaWZENHVtaTlmV2pSU0NraXVIMEcrOW5PWHBoTkxkd2J5?= =?utf-8?B?NXFQK2VHYXNTcFZ1VEFIdW5haG9FT3FNRy9wRi9FN0drZk9XelpHeDRWUjF4?= =?utf-8?B?RlpReE9vSFNOTzh5TE1udVpxMnBsQ2lvdS9YY0pOMlMvcVFxWW9XRVA5TkJI?= =?utf-8?B?bXJDenhVMFNmWVlmbmU1M09CRXBJV1U0MHZjaFpMdE1uWjNTYllMMUpIZVRo?= =?utf-8?B?L3lHcTBjYkZRSGJ1bGFSeExKTExSU3c4eS94Mmc2V1BpRFZNS3M1Wk9Xd0p2?= =?utf-8?B?RXBTRm9sY0NvV3ZYbURQQ1Y2ZG9IZmtRLzhJNFJYaks5T0hLdUh4T0tNdSt5?= =?utf-8?B?YlBOVlVyRmJNSDJFNXdQYUtHa0xic3ZCZng4YUpad1FCd2pGb3RoN1lnRjlG?= =?utf-8?B?bFgzUE1KQWdHUTlscDJQTE5PY0QzS3QxSmdYdnhZYTFNRFJ6dHZCbmtHdE5Q?= =?utf-8?B?L0plSitTMDVXWVF2MFRBd2Q0MkRXYU95ek50SktiNEdpaitRU2ZXRGJVdzk0?= =?utf-8?B?b0hWTDlkbktXcXZvdkFGQjd5akkvNllFN0NSVVdBbDRyL0VJcmVraFdUN1A4?= =?utf-8?B?bTI3NU1iMVVUR0ZycFcyeEwyaDNRbGErMEVzMnEzaEZNT29oZ2QydmdVcEpH?= =?utf-8?B?akdRNjJiakdIY05uR3pxUWllWElEVDBNMHVncEJCeFZ2Rk1EZ3J0ejRXQkRi?= =?utf-8?B?dEIyTTRQVStvUjVJSnpkVWJRdWFrVTdTNWxtd1FtVXJ0aVYzMHRIbTlKcXR1?= =?utf-8?B?UDRVZ0xHSit1b3pSUHRmWnJJZHhoSUp1dlNidThGOEFkZTNBaHBYWEt6S2tr?= =?utf-8?B?V09GMGc3VjJoaDBrRDNtTVdMd3FFVEJ2WUVkWUhZU1ZraStaODQ2SDk1ekQy?= =?utf-8?B?RlBkZnpnU0cyeWxMMS84VDJuN0tsblN2RHpTMy9mWmtzK2FRMmEra3YyLzZS?= =?utf-8?B?SEhnUDVKdHZ0VGdkdmcrNC91Nk1pUGdJbS9yMTlMMDM3OVZaaWpWc0h3SmRL?= =?utf-8?B?VGZxeXpMcVJBTG1ZMXRsRVdEWU5VTEZHTExETzJmSTJ1WGNqdnJ5Y1dZdEFD?= =?utf-8?B?ZnJwSlB0SWc4RVlsSCtFVzNjUnJnYTd5OHJZNG5FcUFzUEViWjV3OVo3SDdK?= =?utf-8?B?dmxlWTB4UU1qRHR3ZjI0UTlWTXFmRVZ3S0ttL3Q5Z2JHZTVpcEsrUTErY2hl?= =?utf-8?B?STJRUWNsVDArTlBlVDN1QTluakw4Wi9GbUpmamZkVlRWKzJHaVg3VWxLcjlG?= =?utf-8?B?NVFuNDk4NkVYSko1RlhxenRWUk4xSVZnaU5wY3d5ZWpQUVovc0Q4N2pxeXM3?= =?utf-8?B?MEJsUG9qQVpLNzlCRjZ2L2E3aXhWelQ3TnU2UkRSaTArSGE5VjQ0SWVMYUo4?= =?utf-8?B?eGZ5dVlYdG5BPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bmFJbjZsT3h3czJ6NW5oWUhwamRsVm9nL0Y0cDZRdC9JeXhEM3Fkbzk2Yysx?= =?utf-8?B?SmpaR21tMThjSDRnVWI4dFEzZ1FoWVpHWXR5Q1dhRFJ6RzZmYklYWUFGc21J?= =?utf-8?B?d1EwRWJZVVhveEp0S3YreE5VOEo4a0lDNHd1dUVZQVdscjdaS0orbGQrWWxp?= =?utf-8?B?Tk8wdGJpbS9mY0p5NkNuUkJaSkdFUCthUXEycUR2M08yTEpiMHlhRUtHSzhu?= =?utf-8?B?ellpQ3pHdFdJOUU4WjVvcVVmQ3ZCU2did2RZNTM0UXY3VndrL2t1SE82aHRt?= =?utf-8?B?Mi8xMzA3Tys4a29nWmtMS3ZIUU5Vd0lIZ3NNa2hQMi9ickp1U3ZTaHBSVndo?= =?utf-8?B?YWQ2U1VNYlg1blNpeExNaVhoSlB0SXBTZHN2bWFJYU5TWnNWZ0VKRjRBdFlm?= =?utf-8?B?Ky9WdTY2SU9jNjVSZWp1UnF3NXhEbVVVemxFb2g1Qk5HdE42UkhTdEErTmFl?= =?utf-8?B?RHYyaEVZSkFLT0REK1pFcGJIMUNNeGxsOEFmRWVtWE1TRHp0K0tneUJDTjJJ?= =?utf-8?B?V1l6ZDRlV2hsKzVtM2xRTUZxNkJzTU52VHJMc04zRDlwc3NMVzk1UnB4dHF0?= =?utf-8?B?ekJGWlNVMlNMRkdpd084cm1aVjQvbHhFYXN3WWFmVG8vaEowb3JSbjNCVFFh?= =?utf-8?B?MDFrT01ZRTdVdUhJdzNBQmNsMlJaYVY1ZEVxTHZocXRrSTNlZGFIWW81Q040?= =?utf-8?B?QzQvMHNCT0lEdE9tbmhuNERlcnUyWWpvNEl3dkgrUEVISlBxZEJkaExaV0Zm?= =?utf-8?B?MzNRNUVMYjU1elFxYjZQcWFaK1l1bnBHSlFBOXgzdXEvaDhhS0UyNkdyd2hm?= =?utf-8?B?QkZ5SGxlQWwxTWs1cmRMNUQyb1FvaHlmZVFnRVRyNEJ6bUFMVzY0QkZ6RmxF?= =?utf-8?B?UHBzK1ZGVFZ4a3BDZ2dySThDcE1wMFlOM3phUDlabk1tQ2lYMUJyU1J6S2pG?= =?utf-8?B?WTVLMDlPb1pVWjUrb2lNK2lJRmsxNEhMM1RrV3RMaGE2Qk01c1NsWmdDNnZ3?= =?utf-8?B?V0h2K2JDbDFhenJIOWFWSkVlVHVwYS9hMlREcjFqWXF4bVFkcXZvOVorUG54?= =?utf-8?B?TjhQYzIwTGhPbHNwOVJPdlNBRXVpbWRSdW9OT3ZqRGZxVktRbUF3a3JWWUVn?= =?utf-8?B?RmJoTlUvVXZsajlzM3pnM1pHdEVnR2ZIb3RrRXFpcEd2dXEyV2RYcmZUUTVm?= =?utf-8?B?UkR6eGFPZXNlTGRHVitWakpUZXk4RmtrWHlndDRibDRlS1RJOGRuN0VodFhI?= =?utf-8?B?ZzIva0tjTnZHVjNZcS96U1J2VStuc2xueFpWRHc4aW1PSFY0Wm9QV0wzRGlj?= =?utf-8?B?a05COFZvaWVSWWdDanJDeGREN0hLa3VNMFZoOCtrTGlld25KalY0NHM2UlRJ?= =?utf-8?B?czRZb1NObEd6VGFWd1hqa01IWVZPTy8zTGVKUm1zbTVFK3dJd3dCOXhKTzRI?= =?utf-8?B?QXh3YTJBOE04RUNxaG5od3ZXSTFRay84aE9zTFpuOGJiTXhoSmx3K1FsUDFx?= =?utf-8?B?RXEvVFluZlYveTJ2eGY4TjcxSmlzTXJPNCtPcjVZNlJKU052eHI5V0VRb2lL?= =?utf-8?B?dEM0cW5aQ1lFNmpxdWRla3VoMHNiMWhiUjU3TkNsYTVodzV0cHVqNjlTSzZE?= =?utf-8?B?WUZCWER4TGpDZDc2ME5ESWpmV3VqRk9zaXdNK3JMU0xrSTBQRFRZLy93M1ll?= =?utf-8?B?RDJCeGcva2FOOVZwcUFGY1NMT2RTRzFDSlRQdHozemxZNFNDZ3gxSjlOVWkw?= =?utf-8?B?WVpCQUthb1F6S1IwZVpvZTl0emFJMHhvaEtucFpHOWZVWVhrQ05lYlQrckxQ?= =?utf-8?B?WitPMHNxZ3V0aTk5Q2VMSytML2dmaXBJWGpaamdySVRhU0lFOFdVTWRlYUVM?= =?utf-8?B?cFdkR01hZDRoV3pBZHlJRTh1TGJOQ0swTXVUT3lYamlQQmtpdlBPQzdHdEo1?= =?utf-8?B?cDN3WmY5Zm5pSmU2WnhiSXZ5UUZ3bzA5TzByQUtFNmVHMUx6bGFBZlZPSGxG?= =?utf-8?B?aUZZVnM5em9BQ1RGL1FsOWlCSytuQldjVlpqOCsyamRCTUpqR3RMcUs2dk1u?= =?utf-8?B?YmRGSW9JbmNqcmZ3NHhsT2V6NVNqYlpqUlZveGpGcjR2ZHFCREtSWmx3UHhZ?= =?utf-8?B?NWQ1SW96WW1kczNkVkZUeWNxWU9LbS9LdXgyMnZuSGJxWXVxSHQrYXAyQ1dJ?= =?utf-8?Q?OF6SfLLvBf7LIMClDAw8l9Y=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <370319F183E5BE42833B87890021EA55@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29d47afb-fa0e-4e92-d210-08dde97d31fe X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 17:30:07.5293 (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: WWHTeS2XnzfPR/LqF6WlHpBhT1j/aH+MoGYeJ4cb1JNY1rMtvMVRSkiRthhb8PVqzLMeSKIHGa3klqNslF2DaGDqnBmbq38++360MYWE+/U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB9908 SGkgVm9sb2R5bXlyLA0KDQpUaGFuayB0b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAyOS4wOC4y NSAyMjo1NSwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+IA0KPiBIaSBMZW9uaWQsDQo+IA0K PiBMZW9uaWQgS29tYXJpYW5za3lpIDxMZW9uaWRfS29tYXJpYW5za3lpQGVwYW0uY29tPiB3cml0 ZXM6DQo+IA0KPj4gSW50cm9kdWNlZCBhcHByb3ByaWF0ZSByZWdpc3RlciBkZWZpbml0aW9ucywg aGVscGVyIG1hY3JvcywNCj4+IGFuZCBpbml0aWFsaXphdGlvbiBvZiByZXF1aXJlZCBHSUN2My4x IGRpc3RyaWJ1dG9yIHJlZ2lzdGVycw0KPj4gdG8gc3VwcG9ydCBlU1BJLiBUaGlzIHR5cGUgb2Yg aW50ZXJydXB0IGlzIGhhbmRsZWQgaW4gdGhlDQo+PiBzYW1lIHdheSBhcyByZWd1bGFyIFNQSSBp bnRlcnJ1cHRzLCB3aXRoIHRoZSBmb2xsb3dpbmcNCj4+IGRpZmZlcmVuY2VzOg0KPj4NCj4+IDEp IGVTUElzIGNhbiBoYXZlIHVwIHRvIDEwMjQgaW50ZXJydXB0cywgc3RhcnRpbmcgZnJvbSB0aGUN Cj4+IGJlZ2lubmluZyBvZiB0aGUgcmFuZ2UsIHdoZXJlYXMgcmVndWxhciBTUElzIHVzZSBJTlRJ RHMgZnJvbQ0KPj4gMzIgdG8gMTAxOSwgdG90YWxpbmcgOTg4IGludGVycnVwdHM7DQo+PiAyKSBl U1BJcyBzdGFydCBhdCBJTlRJRCA0MDk2LCBuZWNlc3NpdGF0aW5nIGFkZGl0aW9uYWwgaW50ZXJy dXB0DQo+PiBpbmRleCBjb252ZXJzaW9uIGR1cmluZyByZWdpc3RlciBvcGVyYXRpb25zLg0KPj4N Cj4+IEluIGNhc2UgaWYgYXBwcm9wcmlhdGUgY29uZmlnIGlzIGRpc2FibGVkLCBvciBHSUMgSFcg ZG9lc24ndA0KPj4gc3VwcG9ydCBlU1BJLCB0aGUgZXhpc3RpbmcgZnVuY3Rpb25hbGl0eSB3aWxs IHJlbWFpbiB0aGUgc2FtZS4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBMZW9uaWQgS29tYXJpYW5z a3lpIDxsZW9uaWRfa29tYXJpYW5za3lpQGVwYW0uY29tPg0KPj4NCj4+IC0tLQ0KPj4gQ2hhbmdl cyBpbiBWNToNCj4+IC0gZml4ZWQgbWlub3Igbml0cywgbm8gZnVuY3Rpb25hbCBjaGFuZ2VzOiBj aGFuZ2VkIHUzMiB0byB1aW50MzJfdCBhbmQNCj4+ICAgIGFkZGVkIGEgY29tbWVudCBub3Rpbmcg dGhhdCB0aGUgY29uZmlndXJhdGlvbiBmb3IgZVNQSXMgaXMgdGhlIHNhbWUgYXMNCj4+ICAgIGZv ciByZWd1bGFyIFNQSXMNCj4+IC0gcmVtb3ZlZCBpZmRlZnMgZm9yIGVTUEktc3BlY2lmaWMgb2Zm c2V0cyB0byByZWR1Y2UgdGhlIG51bWJlciBvZg0KPj4gICAgaWZkZWZzIGFuZCBjb2RlIGR1cGxp Y2F0aW9uIGluIGZ1cnRoZXIgY2hhbmdlcw0KPj4gLSByZW1vdmVkIHJldmlld2VkLWJ5IGFzIG1v dmluZyBvZmZzZXQgZnJvbSBpZmRlZnMgcmVxdWlyZXMgYWRkaXRpb25hbA0KPj4gICAgY29uZmly bWF0aW9uIGZyb20gcmV2aWV3ZXJzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWNDoNCj4+IC0gYWRkZWQg b2Zmc2V0cyBmb3IgR0lDRF9JR1JQTU9EUm5FIGFuZCBHSUNEX05TQUNSbkUgdGhhdCBhcmUgcmVx dWlyZWQNCj4+ICAgIGZvciB2R0lDIGVtdWxhdGlvbg0KPj4gLSBhZGRlZCBhIGxvZyBiYW5uZXIg d2l0aCBlU1BJIGluZm9ybWF0aW9uLCBzaW1pbGFyIHRvIHRoZSBvbmUgZm9yDQo+PiAgICByZWd1 bGFyIFNQSQ0KPj4gLSBhZGRlZCBuZXdsaW5lIGFmdGVyIGlmZGVmIGFuZCBiZWZvcmUgZ2ljX2lz X3ZhbGlkX2xpbmUNCj4+IC0gYWRkZWQgcmV2aWV3ZWQtYnkgZnJvbSBWb2xvZHlteXIgQmFiY2h1 aw0KPj4NCj4+IENoYW5nZXMgaW4gVjM6DQo+PiAtIGFkZCBfX2luaXQgYXR0cmlidXRlIHRvIGdp Y3YzX2Rpc3RfZXNwaV9jb21tb25faW5pdA0KPj4gLSBjaGFuZ2Ugb3Blbi1jb2RkZWQgZVNQSSBy ZWdpc3RlciBpbml0aWFsaXphdGlvbiB0byB0aGUgYXBwcm9wcmlhdGUNCj4+ICAgIGdlbi1tYXNr IG1hY3JvDQo+PiAtIGZpeGVkIGZvcm1hdHRpbmcgZm9yIGxpbmVzIHdpdGggbW9yZSB0aGFuIDgw IHN5bWJvbHMNCj4+IC0gaW50cm9kdWNlZCBnaWN2M19kaXN0X2VzcGlfaW5pdF9hZmYgdG8gYmUg YWJsZSB0byB1c2Ugc3R1YnMgaW4gY2FzZSBvZg0KPj4gICAgQ09ORklHX0dJQ1YzX0VTUEkgZGlz YWJsZWQNCj4+IC0gcmVuYW1lZCBwYXJhbWV0ZXIgaW4gdGhlIEdJQ0RfVFlQRVJfRVNQSV9SQU5H RSBtYWNybyB0byBlc3BpX3JhbmdlDQo+PiAgICAobmFtZSB3YXMgdGFrZW4gZnJvbSBHSUMgc3Bl Y2lmaWNhdGlvbikgdG8gYXZvaWQgY29uZnVzaW9uDQo+PiAtIGNoYW5nZWQgdHlwZSBmb3IgaSB2 YXJpYWJsZSB0byB1bnNpZ25lZCBpbnQgc2luY2UgaXQgY2Fubm90IGJlDQo+PiAgICBuZWdhdGl2 ZQ0KPj4NCj4+IENoYW5nZXMgaW4gVjI6DQo+PiAtIG1vdmUgZ2ljX251bWJlcl9lc3BpcyBmdW5j dGlvbiBmcm9tDQo+PiAgICBbUEFUQ0ggMDgvMTBdIHhlbi9hcm06IHZnaWM6IGFkZCByZXNvdXJj ZSBtYW5hZ2VtZW50IGZvciBleHRlbmRlZCBTUElzDQo+PiAgICB0byB1c2UgaXQgaW4gdGhlIG5l d2x5IGludHJvZHVjZWQgZ2ljX2lzX3ZhbGlkX2VzcGkNCj4+IC0gYWRkIGdpY19pc192YWxpZF9l c3BpIHdoaWNoIGNoZWNrcyBpZiBJUlEgbnVtYmVyIGlzIGluIHN1cHBvcnRlZA0KPj4gICAgYnkg SFcgZVNQSSByYW5nZQ0KPj4gLSB1cGRhdGUgZ2ljX2lzX3ZhbGlkX2lycSBjb25kaXRpb25zIHRv IGFsbG93IG9wZXJhdGlvbnMgd2l0aCBlU1BJcw0KPj4gLS0tDQo+PiAgIHhlbi9hcmNoL2FybS9n aWMtdjMuYyAgICAgICAgICAgICAgICAgIHwgODMgKysrKysrKysrKysrKysrKysrKysrKysrKysN Cj4+ICAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpYy5oICAgICAgICAgfCAyMiArKysrKysr DQo+PiAgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9naWNfdjNfZGVmcy5oIHwgMzggKysrKysr KysrKysrDQo+PiAgIDMgZmlsZXMgY2hhbmdlZCwgMTQzIGluc2VydGlvbnMoKykNCj4+DQo+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2dpYy12My5jIGIveGVuL2FyY2gvYXJtL2dpYy12My5j DQo+PiBpbmRleCAyOWI3ZjY4Y2JhLi40YTdjZTEyZjI2IDEwMDY0NA0KPj4gLS0tIGEveGVuL2Fy Y2gvYXJtL2dpYy12My5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZ2ljLXYzLmMNCj4+IEBAIC00 ODUsNiArNDg1LDM2IEBAIHN0YXRpYyB2b2lkIF9faW9tZW0gKmdldF9hZGRyX2J5X29mZnNldChz dHJ1Y3QgaXJxX2Rlc2MgKmlycWQsIHUzMiBvZmZzZXQpDQo+PiAgICAgICAgICAgZGVmYXVsdDoN Cj4+ICAgICAgICAgICAgICAgYnJlYWs7DQo+PiAgICAgICAgICAgfQ0KPj4gKyNpZmRlZiBDT05G SUdfR0lDVjNfRVNQSQ0KPj4gKyAgICBjYXNlIEVTUElfQkFTRV9JTlRJRCAuLi4gRVNQSV9NQVhf SU5USUQ6DQo+PiArICAgIHsNCj4+ICsgICAgICAgIHVpbnQzMl90IGlycV9pbmRleCA9IEVTUElf SU5USUQySURYKGlycWQtPmlycSk7DQo+PiArDQo+PiArICAgICAgICBzd2l0Y2ggKCBvZmZzZXQg KQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgY2FzZSBHSUNEX0lTRU5BQkxFUjoNCj4+ICsg ICAgICAgICAgICByZXR1cm4gKEdJQ0QgKyBHSUNEX0lTRU5BQkxFUm5FICsgKGlycV9pbmRleCAv IDMyKSAqIDQpOw0KPj4gKyAgICAgICAgY2FzZSBHSUNEX0lDRU5BQkxFUjoNCj4+ICsgICAgICAg ICAgICByZXR1cm4gKEdJQ0QgKyBHSUNEX0lDRU5BQkxFUm5FICsgKGlycV9pbmRleCAvIDMyKSAq IDQpOw0KPj4gKyAgICAgICAgY2FzZSBHSUNEX0lTUEVORFI6DQo+PiArICAgICAgICAgICAgcmV0 dXJuIChHSUNEICsgR0lDRF9JU1BFTkRSbkUgKyAoaXJxX2luZGV4IC8gMzIpICogNCk7DQo+PiAr ICAgICAgICBjYXNlIEdJQ0RfSUNQRU5EUjoNCj4+ICsgICAgICAgICAgICByZXR1cm4gKEdJQ0Qg KyBHSUNEX0lDUEVORFJuRSArIChpcnFfaW5kZXggLyAzMikgKiA0KTsNCj4+ICsgICAgICAgIGNh c2UgR0lDRF9JU0FDVElWRVI6DQo+PiArICAgICAgICAgICAgcmV0dXJuIChHSUNEICsgR0lDRF9J U0FDVElWRVJuRSArIChpcnFfaW5kZXggLyAzMikgKiA0KTsNCj4+ICsgICAgICAgIGNhc2UgR0lD RF9JQ0FDVElWRVI6DQo+PiArICAgICAgICAgICAgcmV0dXJuIChHSUNEICsgR0lDRF9JQ0FDVElW RVJuRSArIChpcnFfaW5kZXggLyAzMikgKiA0KTsNCj4+ICsgICAgICAgIGNhc2UgR0lDRF9JQ0ZH UjoNCj4+ICsgICAgICAgICAgICByZXR1cm4gKEdJQ0QgKyBHSUNEX0lDRkdSbkUgKyAoaXJxX2lu ZGV4IC8gMTYpICogNCk7DQo+PiArICAgICAgICBjYXNlIEdJQ0RfSVJPVVRFUjoNCj4+ICsgICAg ICAgICAgICByZXR1cm4gKEdJQ0QgKyBHSUNEX0lST1VURVJuRSArIGlycV9pbmRleCAqIDgpOw0K Pj4gKyAgICAgICAgY2FzZSBHSUNEX0lQUklPUklUWVI6DQo+PiArICAgICAgICAgICAgcmV0dXJu IChHSUNEICsgR0lDRF9JUFJJT1JJVFlSbkUgKyBpcnFfaW5kZXgpOw0KPj4gKyAgICAgICAgZGVm YXVsdDoNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAgIH0NCj4+ICsgICAgfQ0K Pj4gKyNlbmRpZg0KPj4gICAgICAgZGVmYXVsdDoNCj4+ICAgICAgICAgICBicmVhazsNCj4+ICAg ICAgIH0NCj4+IEBAIC02NTUsNiArNjg1LDU1IEBAIHN0YXRpYyB2b2lkIGdpY3YzX3NldF9pcnFf cHJpb3JpdHkoc3RydWN0IGlycV9kZXNjICpkZXNjLA0KPj4gICAgICAgc3Bpbl91bmxvY2soJmdp Y3YzLmxvY2spOw0KPj4gICB9DQo+PiAgIA0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0K Pj4gK3Vuc2lnbmVkIGludCBnaWNfbnVtYmVyX2VzcGlzKHZvaWQpDQo+PiArew0KPj4gKyAgICBy ZXR1cm4gZ2ljX2h3X29wcy0+aW5mby0+bnJfZXNwaTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGlj IHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9jb21tb25faW5pdCh1aW50MzJfdCB0eXBlKQ0K Pj4gK3sNCj4+ICsgICAgdW5zaWduZWQgaW50IGVzcGlfbnIsIGk7DQo+PiArDQo+PiArICAgIGVz cGlfbnIgPSBtaW4oMTAyNFUsIEdJQ0RfVFlQRVJfRVNQSVNfTlVNKHR5cGUpKTsNCj4+ICsgICAg Z2ljdjNfaW5mby5ucl9lc3BpID0gZXNwaV9ucjsNCj4+ICsgICAgLyogVGhlIEdJQyBIVyBkb2Vz bid0IHN1cHBvcnQgZVNQSSwgc28gd2UgY2FuIGxlYXZlIGZyb20gaGVyZSAqLw0KPj4gKyAgICBp ZiAoIGdpY3YzX2luZm8ubnJfZXNwaSA9PSAwICkNCj4+ICsgICAgICAgIHJldHVybjsNCj4+ICsN Cj4+ICsgICAgcHJpbnRrKCJHSUN2MzogJWQgZVNQSSBsaW5lc1xuIiwgZ2ljdjNfaW5mby5ucl9l c3BpKTsNCj4+ICsNCj4+ICsgICAgLyogVGhlIGNvbmZpZ3VyYXRpb24gZm9yIGVTUElzIGlzIHNp bWlsYXIgdG8gdGhhdCBmb3IgcmVndWxhciBTUElzICovDQo+PiArICAgIGZvciAoIGkgPSAwOyBp IDwgZXNwaV9ucjsgaSArPSAxNiApDQo+PiArICAgICAgICB3cml0ZWxfcmVsYXhlZCgwLCBHSUNE ICsgR0lDRF9JQ0ZHUm5FICsgKGkgLyAxNikgKiA0KTsNCj4+ICsNCj4+ICsgICAgZm9yICggaSA9 IDA7IGkgPCBlc3BpX25yOyBpICs9IDQgKQ0KPj4gKyAgICAgICAgd3JpdGVsX3JlbGF4ZWQoR0lD X1BSSV9JUlFfQUxMLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgR0lDRCArIEdJQ0RfSVBS SU9SSVRZUm5FICsgKGkgLyA0KSAqIDQpOw0KPj4gKw0KPj4gKyAgICBmb3IgKCBpID0gMDsgaSA8 IGVzcGlfbnI7IGkgKz0gMzIgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB3cml0ZWxfcmVsYXhl ZChHRU5NQVNLKDMxLCAwKSwgR0lDRCArIEdJQ0RfSUNFTkFCTEVSbkUgKyAoaSAvIDMyKSAqIDQp Ow0KPj4gKyAgICAgICAgd3JpdGVsX3JlbGF4ZWQoR0VOTUFTSygzMSwgMCksIEdJQ0QgKyBHSUNE X0lDQUNUSVZFUm5FICsgKGkgLyAzMikgKiA0KTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBm b3IgKCBpID0gMDsgaSA8IGVzcGlfbnI7IGkgKz0gMzIgKQ0KPj4gKyAgICAgICAgd3JpdGVsX3Jl bGF4ZWQoR0VOTUFTSygzMSwgMCksIEdJQ0QgKyBHSUNEX0lHUk9VUFJuRSArIChpIC8gMzIpICog NCk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIF9faW5pdCBnaWN2M19kaXN0X2VzcGlf aW5pdF9hZmYodWludDY0X3QgYWZmaW5pdHkpDQo+PiArew0KPj4gKyAgICB1bnNpZ25lZCBpbnQg aTsNCj4+ICsNCj4+ICsgICAgZm9yICggaSA9IDA7IGkgPCBnaWN2M19pbmZvLm5yX2VzcGk7IGkr KyApDQo+PiArICAgICAgICB3cml0ZXFfcmVsYXhlZF9ub25fYXRvbWljKGFmZmluaXR5LCBHSUNE ICsgR0lDRF9JUk9VVEVSbkUgKyBpICogOCk7DQo+PiArfQ0KPj4gKyNlbHNlDQo+PiArc3RhdGlj IHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9jb21tb25faW5pdCh1aW50MzJfdCB0eXBlKSB7 IH0NCj4+ICsNCj4+ICtzdGF0aWMgdm9pZCBfX2luaXQgZ2ljdjNfZGlzdF9lc3BpX2luaXRfYWZm KHVpbnQ2NF90IGFmZmluaXR5KSB7IH0NCj4+ICsjZW5kaWYNCj4+ICsNCj4+ICAgc3RhdGljIHZv aWQgX19pbml0IGdpY3YzX2Rpc3RfaW5pdCh2b2lkKQ0KPj4gICB7DQo+PiAgICAgICB1aW50MzJf dCB0eXBlOw0KPj4gQEAgLTcwMCw2ICs3NzksOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgZ2ljdjNf ZGlzdF9pbml0KHZvaWQpDQo+PiAgICAgICBmb3IgKCBpID0gTlJfR0lDX0xPQ0FMX0lSUVM7IGkg PCBucl9saW5lczsgaSArPSAzMiApDQo+PiAgICAgICAgICAgd3JpdGVsX3JlbGF4ZWQoR0VOTUFT SygzMSwgMCksIEdJQ0QgKyBHSUNEX0lHUk9VUFIgKyAoaSAvIDMyKSAqIDQpOw0KPj4gICANCj4+ ICsgICAgZ2ljdjNfZGlzdF9lc3BpX2NvbW1vbl9pbml0KHR5cGUpOw0KPj4gKw0KPj4gICAgICAg Z2ljdjNfZGlzdF93YWl0X2Zvcl9yd3AoKTsNCj4+ICAgDQo+PiAgICAgICAvKiBUdXJuIG9uIHRo ZSBkaXN0cmlidXRvciAqLw0KPj4gQEAgLTcxMyw2ICs3OTQsOCBAQCBzdGF0aWMgdm9pZCBfX2lu aXQgZ2ljdjNfZGlzdF9pbml0KHZvaWQpDQo+PiAgIA0KPj4gICAgICAgZm9yICggaSA9IE5SX0dJ Q19MT0NBTF9JUlFTOyBpIDwgbnJfbGluZXM7IGkrKyApDQo+PiAgICAgICAgICAgd3JpdGVxX3Jl bGF4ZWRfbm9uX2F0b21pYyhhZmZpbml0eSwgR0lDRCArIEdJQ0RfSVJPVVRFUiArIGkgKiA4KTsN Cj4+ICsNCj4+ICsgICAgZ2ljdjNfZGlzdF9lc3BpX2luaXRfYWZmKGFmZmluaXR5KTsNCj4+ICAg fQ0KPj4gICANCj4+ICAgc3RhdGljIGludCBnaWN2M19lbmFibGVfcmVkaXN0KHZvaWQpDQo+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpYy5oIGIveGVuL2FyY2gvYXJt L2luY2x1ZGUvYXNtL2dpYy5oDQo+PiBpbmRleCAzZmNlZTQyNjc1Li4xZTc0N2RjZDk5IDEwMDY0 NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpYy5oDQo+PiArKysgYi94ZW4v YXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljLmgNCj4+IEBAIC0zMDYsOCArMzA2LDI2IEBAIGV4dGVy biB2b2lkIGdpY19kdW1wX3ZnaWNfaW5mbyhzdHJ1Y3QgdmNwdSAqdik7DQo+PiAgIA0KPj4gICAv KiBOdW1iZXIgb2YgaW50ZXJydXB0IGxpbmVzICovDQo+PiAgIGV4dGVybiB1bnNpZ25lZCBpbnQg Z2ljX251bWJlcl9saW5lcyh2b2lkKTsNCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ ICtleHRlcm4gdW5zaWduZWQgaW50IGdpY19udW1iZXJfZXNwaXModm9pZCk7DQo+PiArDQo+PiAr c3RhdGljIGlubGluZSBib29sIGdpY19pc192YWxpZF9lc3BpKHVuc2lnbmVkIGludCBpcnEpDQo+ PiArew0KPj4gKyAgICByZXR1cm4gKGlycSA+PSBFU1BJX0JBU0VfSU5USUQgJiYNCj4+ICsgICAg ICAgICAgICBpcnEgPCBFU1BJX0lEWDJJTlRJRChnaWNfbnVtYmVyX2VzcGlzKCkpKTsNCj4gDQo+ IFlvdSBkb24ndCBuZWVkIGV4dGVybmFsICgpIGhlcmUuDQo+IA0KDQpPaCwgSSBtaXNzZWQgdGhh dCwgc29ycnk6KCBJIHdpbGwgcmVtb3ZlIHRoZW0gaW4gVjYgYW5kIHJlY2hlY2sgdGhlIA0Kb3Ro ZXIgcGF0Y2hlcyBmb3Igc3VjaCBpc3Nlcy4NCg0KPj4gK30NCj4+ICsjZWxzZQ0KPj4gK3N0YXRp YyBpbmxpbmUgYm9vbCBnaWNfaXNfdmFsaWRfZXNwaSh1bnNpZ25lZCBpbnQgaXJxKQ0KPj4gK3sN Cj4+ICsgICAgcmV0dXJuIGZhbHNlOw0KPj4gK30NCj4+ICsjZW5kaWYNCj4+ICsNCj4+ICAgc3Rh dGljIGlubGluZSBib29sIGdpY19pc192YWxpZF9saW5lKHVuc2lnbmVkIGludCBpcnEpDQo+PiAg IHsNCj4+ICsgICAgaWYgKCBnaWNfaXNfdmFsaWRfZXNwaShpcnEpICkNCj4+ICsgICAgICAgIHJl dHVybiB0cnVlOw0KPj4gKw0KPj4gICAgICAgcmV0dXJuIGlycSA8IGdpY19udW1iZXJfbGluZXMo KTsNCj4+ICAgfQ0KPiANCj4gQXMgeW91IGFyZSBnb2luZyB0byByZXdvcmsgdGhpcyBwYXRjaCBh bnl3YXlzLCBteSBJIGFzayB0byByZXdyaXRlIHRoaXMNCj4gZnVuY3Rpb24gaW4gdGhlIGZvbGxv d2luZyB3YXk/DQo+IA0KPiBzdGF0aWMgaW5saW5lIGJvb2wgZ2ljX2lzX3ZhbGlkX2xpbmUodW5z aWduZWQgaW50IGlycSkNCj4gew0KPiAgICAgICByZXR1cm4gaXJxIDwgZ2ljX251bWJlcl9saW5l cygpIHx8IGdpY19pc192YWxpZF9lc3BpKGlycSk7DQo+IH0NCj4gDQo+IE15IGp1c3RpZmljYXRp b24gaXMgdGhhdCAoaXJxIDwgZ2ljX251bWJlcl9saW5lcygpKSBjYXNlIGlzIG1vcmUgbGlrZWx5 LA0KPiBzbyBpdCBpcyBiZXR0ZXIgdG8gZXZhbHVhdGUgaXQgZmlyc3QsIG9ubHkgdGhlbiBjaGVj ayBmb3IgZVNQSXMuDQo+IA0KPiBJIGFtIHNvcnJ5LCBJIHNob3VsZCBhc2tlZCBpdCBlYXJsaWVy LCBidXQgb25seSBhZnRlciByZW1vdmluZyAjaWZkZWYgSQ0KPiBzYXcgdGhhdCB0aGlzIHBhcnQg Y291bGQgYmUgbW9yZSBvcHRpbWFsLg0KPiANCg0KVGhhbmsgeW91IGZvciBwb2ludGluZyB0aGlz IG91dDopIEl0IGlzIHJlYWxseSBtYWtlIHNlbmNlLCBzbyBJIHdpbGwgZml4IA0KdGhpcyBpbiBW Ni4NCg0KPj4gICANCj4+IEBAIC0zMjUsNiArMzQzLDEwIEBAIHN0cnVjdCBnaWNfaW5mbyB7DQo+ PiAgICAgICBlbnVtIGdpY192ZXJzaW9uIGh3X3ZlcnNpb247DQo+PiAgICAgICAvKiBOdW1iZXIg b2YgR0lDIGxpbmVzIHN1cHBvcnRlZCAqLw0KPj4gICAgICAgdW5zaWduZWQgaW50IG5yX2xpbmVz Ow0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gKyAgICAvKiBOdW1iZXIgb2YgR0lD IGVTUEkgc3VwcG9ydGVkICovDQo+PiArICAgIHVuc2lnbmVkIGludCBucl9lc3BpOw0KPj4gKyNl bmRpZg0KPj4gICAgICAgLyogTnVtYmVyIG9mIExSIHJlZ2lzdGVycyAqLw0KPj4gICAgICAgdWlu dDhfdCBucl9scnM7DQo+PiAgICAgICAvKiBNYWludGVuYW5jZSBpcnEgbnVtYmVyICovDQo+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpY192M19kZWZzLmggYi94ZW4v YXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3YzX2RlZnMuaA0KPj4gaW5kZXggMmFmMDkzZTc3NC4u MzM3MGI0Y2Q1MiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9naWNf djNfZGVmcy5oDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3YzX2RlZnMu aA0KPj4gQEAgLTM3LDYgKzM3LDQ0IEBADQo+PiAgICNkZWZpbmUgR0lDRF9JUk9VVEVSMTAxOSAg ICAgICAgICAgICAoMHg3RkQ4KQ0KPj4gICAjZGVmaW5lIEdJQ0RfUElEUjIgICAgICAgICAgICAg ICAgICAgKDB4RkZFOCkNCj4+ICAgDQo+PiArLyogQWRkaXRpb25hbCByZWdpc3RlcnMgZm9yIEdJ Q3YzLjEgKi8NCj4+ICsjZGVmaW5lIEdJQ0RfSUdST1VQUm5FICAgICAgICAgICAgICAgKDB4MTAw MCkNCj4+ICsjZGVmaW5lIEdJQ0RfSUdST1VQUm5FTiAgICAgICAgICAgICAgKDB4MTA3QykNCj4+ ICsjZGVmaW5lIEdJQ0RfSVNFTkFCTEVSbkUgICAgICAgICAgICAgKDB4MTIwMCkNCj4+ICsjZGVm aW5lIEdJQ0RfSVNFTkFCTEVSbkVOICAgICAgICAgICAgKDB4MTI3QykNCj4+ICsjZGVmaW5lIEdJ Q0RfSUNFTkFCTEVSbkUgICAgICAgICAgICAgKDB4MTQwMCkNCj4+ICsjZGVmaW5lIEdJQ0RfSUNF TkFCTEVSbkVOICAgICAgICAgICAgKDB4MTQ3QykNCj4+ICsjZGVmaW5lIEdJQ0RfSVNQRU5EUm5F ICAgICAgICAgICAgICAgKDB4MTYwMCkNCj4+ICsjZGVmaW5lIEdJQ0RfSVNQRU5EUm5FTiAgICAg ICAgICAgICAgKDB4MTY3QykNCj4+ICsjZGVmaW5lIEdJQ0RfSUNQRU5EUm5FICAgICAgICAgICAg ICAgKDB4MTgwMCkNCj4+ICsjZGVmaW5lIEdJQ0RfSUNQRU5EUm5FTiAgICAgICAgICAgICAgKDB4 MTg3QykNCj4+ICsjZGVmaW5lIEdJQ0RfSVNBQ1RJVkVSbkUgICAgICAgICAgICAgKDB4MUEwMCkN Cj4+ICsjZGVmaW5lIEdJQ0RfSVNBQ1RJVkVSbkVOICAgICAgICAgICAgKDB4MUE3QykNCj4+ICsj ZGVmaW5lIEdJQ0RfSUNBQ1RJVkVSbkUgICAgICAgICAgICAgKDB4MUMwMCkNCj4+ICsjZGVmaW5l IEdJQ0RfSUNBQ1RJVkVSbkVOICAgICAgICAgICAgKDB4MUM3QykNCj4+ICsjZGVmaW5lIEdJQ0Rf SVBSSU9SSVRZUm5FICAgICAgICAgICAgKDB4MjAwMCkNCj4+ICsjZGVmaW5lIEdJQ0RfSVBSSU9S SVRZUm5FTiAgICAgICAgICAgKDB4MjNGQykNCj4+ICsjZGVmaW5lIEdJQ0RfSUNGR1JuRSAgICAg ICAgICAgICAgICAgKDB4MzAwMCkNCj4+ICsjZGVmaW5lIEdJQ0RfSUNGR1JuRU4gICAgICAgICAg ICAgICAgKDB4MzBGQykNCj4+ICsjZGVmaW5lIEdJQ0RfSUdSUE1PRFJuRSAgICAgICAgICAgICAg KDB4MzQwMCkNCj4+ICsjZGVmaW5lIEdJQ0RfSUdSUE1PRFJuRU4gICAgICAgICAgICAgKDB4MzQ3 QykNCj4+ICsjZGVmaW5lIEdJQ0RfTlNBQ1JuRSAgICAgICAgICAgICAgICAgKDB4MzYwMCkNCj4+ ICsjZGVmaW5lIEdJQ0RfTlNBQ1JuRU4gICAgICAgICAgICAgICAgKDB4MzZGQykNCj4+ICsjZGVm aW5lIEdJQ0RfSVJPVVRFUm5FICAgICAgICAgICAgICAgKDB4ODAwMCkNCj4+ICsjZGVmaW5lIEdJ Q0RfSVJPVVRFUm5FTiAgICAgICAgICAgICAgKDB4OUZGQykNCj4+ICsNCj4+ICsjaWZkZWYgQ09O RklHX0dJQ1YzX0VTUEkNCj4+ICsjZGVmaW5lIEdJQ0RfVFlQRVJfRVNQSV9TSElGVCAgICAgICAg OA0KPj4gKyNkZWZpbmUgR0lDRF9UWVBFUl9FU1BJX1JBTkdFX1NISUZUICAyNw0KPj4gKyNkZWZp bmUgR0lDRF9UWVBFUl9FU1BJX1JBTkdFX01BU0sgICAoMHgxRikNCj4+ICsjZGVmaW5lIEdJQ0Rf VFlQRVJfRVNQSSAgICAgICAgICAgICAgKDFVIDw8IEdJQ0RfVFlQRVJfRVNQSV9TSElGVCkNCj4+ ICsjZGVmaW5lIEdJQ0RfVFlQRVJfRVNQSV9SQU5HRShlc3BpX3JhbmdlKSAoKCgoZXNwaV9yYW5n ZSkgJiBcDQo+PiArICAgICAgICBHSUNEX1RZUEVSX0VTUElfUkFOR0VfTUFTSykgKyAxKSAqIDMy KQ0KPj4gKyNkZWZpbmUgR0lDRF9UWVBFUl9FU1BJU19OVU0odHlwZXIpICAgIFwNCj4+ICsgICAg ICAgICgoKHR5cGVyKSAmIEdJQ0RfVFlQRVJfRVNQSSkgPyBcDQo+PiArICAgICAgICBHSUNEX1RZ UEVSX0VTUElfUkFOR0UoKHR5cGVyKSA+PiBHSUNEX1RZUEVSX0VTUElfUkFOR0VfU0hJRlQpIDog MCkNCj4+ICsjZW5kaWYNCj4+ICsNCj4+ICAgLyogQ29tbW9uIGJldHdlZW4gR0lDRF9QSURSMiBh bmQgR0lDUl9QSURSMiAqLw0KPj4gICAjZGVmaW5lIEdJQ19QSURSMl9BUkNIX01BU0sgICAgICAg ICAoMHhmMCkNCj4+ICAgI2RlZmluZSBHSUNfUElEUjJfQVJDSF9HSUN2MyAgICAgICAgKDB4MzAp DQo+IA0KDQpCZXN0IHJlZ2FyZHMsDQpMZW9uaWQNCg== From xen-devel-bounces@lists.xenproject.org Mon Sep 01 17:38:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 17:38:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105259.1456189 (Exim 4.92) (envelope-from ) id 1ut8U5-0001iP-6I; Mon, 01 Sep 2025 17:38:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105259.1456189; Mon, 01 Sep 2025 17:38: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 1ut8U5-0001iI-3C; Mon, 01 Sep 2025 17:38:25 +0000 Received: by outflank-mailman (input) for mailman id 1105259; Mon, 01 Sep 2025 17:38: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 1ut8U3-0001iC-RG for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 17:38:24 +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 742d7885-875a-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 19:38:21 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by DU0PR03MB9102.eurprd03.prod.outlook.com (2603:10a6:10:465::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 17:38:19 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 17:38: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: 742d7885-875a-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d+wKXiTAWiJEwAWw/HbGBkiRSI7IxtrPROklvwAV48vzRgrELHSfA6M6B3D6h2unPbRU1/KYtIrrwwYXWHUfPW1gzEbV4DapYbVPRyD311eOVFBvyOQKRyO6zJ16jfcWh9aSrImxhaKZmPenNKoLH0hcldqwGUD0EO2EBz33KcdKz+3Wf2YrgYYYzPA8dCVAZW3SJ0NxAqthHpkzX8LZzHAX7hlelyDoE68+ldAAAZ1I4Qvr3OYLFaleZnGmP/icvg8C3TbSL061OFM81oSkufGEvbesfG08BMK3u1t/m37YNmOQyG4XlXLY8n38CBdw3M8PU7UTk/rH/ZOd79QOLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9CJlyexNKamfoVyPWGkuyXqGL6K0DJXaqlUrgOKL3uw=; b=JFYXPAEwj0c4uz+/Sb0GDiDVmOaq9dxdxK/jd30NspxdD6vQn4SbZqLNU/Gkvb2RkXuLHaU4f8bOVj7iXJvP8oYvc2xXGbeHuRz+EKOHEbYBZJ7gLtshI/4rktILiKj1FECNRL121rcWHxgjvHtVlVvJ7u7L60cOrJfEuy4p0TyRLoi7iessdCAUEEonx+BZzsEps/Rtt87blgzqb3w/uDiEiyrLAqiBtVfB1U5v7Vk8+XetwEeDZKHyFqOCHdknqFxIVf2EZo1nG7KczxfH7cjsk7nwlXz7ca2VNP8EUPjI1irPHqe5x9ktCSBh/efVBPOJxXr7OHkYzXolDOpzHg== 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=9CJlyexNKamfoVyPWGkuyXqGL6K0DJXaqlUrgOKL3uw=; b=htIr1r3M+LYk09IgyCO27xcaSE4JbbLOI6XdgcaH42tQ+9043lPPatyL0IFKMmn77Rh37Qstf3ufL71+sMqOcY9No4ovHg6vxM2Mt+kpBvvZOXtU9DnmmHNgjBk4LDiuOvOmAwbGhcVhBtSnLehcM/pDArGHGtr7CQ/Zr0/93r2+nhSU9Iwuo/1Wf0ReYvx681CwPXkL5iOBdxW9jCq244ed86aKY81LMhNA9n0GakuURj2mRQfWYuXOQp8e2xZ3ZUUZTDikP+1i0j4jIsz4Kyccs070A3nwX2HonjJGw4YoiOi55JRBJ0aHtDL0FQvXx8CyqvI37TNCtiei5+IIag== From: Leonid Komarianskyi To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , "olekstysh@gmail.com" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Thread-Topic: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Thread-Index: AQHcGP7gzxYtqJZFyUiPTlrb5XV2MbR+nGkA Date: Mon, 1 Sep 2025 17:38:18 +0000 Message-ID: <14c88dc5-8727-4cbb-964f-1e017beb617d@epam.com> References: <4b13dea924eabf1370d3f31030f3eef48371de06.1756481577.git.leonid_komarianskyi@epam.com> <87y0r1x3g2.fsf@epam.com> In-Reply-To: <87y0r1x3g2.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|DU0PR03MB9102:EE_ x-ms-office365-filtering-correlation-id: b8895864-4bb0-44c5-0980-08dde97e56e7 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?eFQySmZ5Z2JGd0djQkExSUtiVXV5Z0Y0YkRQNnd1U0ErQWEwcE5NZ1JyNDdB?= =?utf-8?B?VCtIM3gwZUdFV0lzV3JJanhDMW9vQ1d6S3NiTnk0ZVJsWkwrQXJHeFoyaWIw?= =?utf-8?B?MWtOSVkvVWRmNWtRbWl3S01lVzN6RHg3Z21MOHJpNjNsNVdjd2tpcUwxUHZm?= =?utf-8?B?Y01zOEpnYXc3eVVmMTNtaHRHMzZnK2lzK0VZbldWdENHcWFzWlVpWFJCcGxJ?= =?utf-8?B?RzJLNGVWZGYwcTZ2VTRLUXdYcnhqZVpIbnBlTmdzTm1tMStmNXZLdTJ1UEpD?= =?utf-8?B?bDEvVDRkZmpkNTQzYS94VkZDSFNIWmJWWnM2UGFGckJBejlPWk55OWFieHdu?= =?utf-8?B?RlM5ckJnU3c5aW5EMmw4ZXBNRlZRNGM5VnVidkFIT2dtbFQ0SCt0N2J5em1r?= =?utf-8?B?azBKMGF2NWNISll0blpBVUlZUEsxZllxNVpvenltYkRLdXplTWlwcEZXblFu?= =?utf-8?B?NnVrdmJmTkUvc1prd2QyUExzL2k1Q0wvNk16enVJNERpejNyak9yckd5eTNI?= =?utf-8?B?N0RrZCs5ZjdJbTh5SUJPcnpOWEkwNmJLTmg0amMrQkVNN2dwR1FCNVBjdVdz?= =?utf-8?B?ZmpwOFRzYW5ZWTVWOG95UHF5Sk1aRTZPL3ZVQTdvNCtiSjBjWFFhMnd3ayt4?= =?utf-8?B?eUlrNXZXaTRyWXh1Rzk0d0MyKy82Ym10ejhGME1xcDN5S0lZVE1HdkdibmEy?= =?utf-8?B?aThRbDBGRStCT3FoVmRjRUdONTd5OHZ3SjJGM2RyeDdmRk92WUUrbDh1RHJx?= =?utf-8?B?T3hBcmRZQ2tDK1B1U3JqZFBMcGRKZUZ5dkxYZUVwTzUvcVFaSVJlVFlKdXgz?= =?utf-8?B?T1VBcExwYVo3OFBsTklBaDZtdFc5dXduVyt3V2pxNzExTW5HcmozVVp0UWhY?= =?utf-8?B?VFVRMGQydm5rRmxVYitBcDRSNjIwR1NPeWdYNXBCL2VDZDlNbkIwZ3paeFpn?= =?utf-8?B?cXhKYnZkZzlKNWF5d2UvRUtQbUYyN0U4bWw2SzFkcUgwT1FQamh5YVVwUUV1?= =?utf-8?B?eko2ZWFoTVJtWVlNbytmSXZFcHJoOVJEbHRTWTd6NEdIa202OWwwWlhCVWp5?= =?utf-8?B?RjA2NHpoQTV1cGZ1dVRhY2JiMGpMY0dCYUdvWlFOSndpdlNGK3hJR0E5alo2?= =?utf-8?B?ODBoOUw4VTZQN2FrWUticVBFTmdXRGs5THlkN21ycEg3ajFZSEx4VFQ2QjNV?= =?utf-8?B?RllLTXlyV2JsQkhTK3V3MDlYd0FpQmx3R3Z4ZGkweXNKenZGUDhwYXpjbS9h?= =?utf-8?B?bWdiZld2aDQ0VkhGdGxCSVZkNkRPLzkvdWZqKzZ6bE83ZGpDMGxmNVpSa3Jj?= =?utf-8?B?T2hNNy9uaVByUDRDaXpXMWVkMkcvMEg2N0YzRnZIaERDc3NqS0cxSTFtdG1K?= =?utf-8?B?Tm5peXVSUHRUbk9BTTBzVlpwN0x1ejYySVlnUnk0bGVZVGhLMmVXMUplVk41?= =?utf-8?B?Z1pvbHNOQkhjcG5EdzNNcitKaVFieG1hOHpTNDc1ckJpVGxLSTNjQWJobmxV?= =?utf-8?B?Uzk4eFNwMGxuSC90czgrYVJuODZGd3MwZGpJREFBVzBaWmE0dnlpVHFFbU4y?= =?utf-8?B?ekhMaHJYS3grSVQ3ZmNiL3M1MVljZXZ5WmFSYXo0MnhmZVBScGFYNmJVS1pF?= =?utf-8?B?dDVpS041Z1E4dHM1eWtKdFhHU2FJZ2dNc1d2OGNyMUNNMmoycGFhYnQyRWsw?= =?utf-8?B?aUd5OUJpZ29uWlowNFNQdEJ2NWNKOVBpcmNSeDFmY0Y1VDRFdVRFb1lxOFFD?= =?utf-8?B?Tm56SE5QQXZRVlNEM1JZWThjam4zaUh4WFRyN1VqbHFqZWF2TFk0cGxleEtJ?= =?utf-8?B?Wk03WmFMM05kREpHN29ubFJqY3VEKzhjVy80Mmc2Tk1CYmlRbUFYeEREUkEw?= =?utf-8?B?Mys3eERMWWM2UXc5U1Z5cTdxRnBMUW96aU5sdmxzRktoc0ZEUno3T0VxQTB0?= =?utf-8?B?K1hOaVl2UUNXQmtTd09xZmFwZzF4TGVrOUl4R2I1NkFxSWU0Tk5LbHc0TVJm?= =?utf-8?B?cDcwUkdVMWp3PT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZTJwL0szSEpRNHFKYWlmdXpJbWFrRmtHOFNNdlBuTHNFVkNmcjJuYWlYOFVD?= =?utf-8?B?SlBJSkVUdFpFLzdVazM0OVUrRGFmWE9mVm5sM1JPOTNtd2NsR1lCTm1KTE0y?= =?utf-8?B?eUlaV0xPa1AyRUFOWXFFQmVnNm82Q2xlNWJnaXZ6OWRhVFBHYjdVNStOZE85?= =?utf-8?B?R3huVFhXTllpMFdoWFBLRURoblVUOU50K2NWNVAzR3QzN3F2SEFueXRSYk15?= =?utf-8?B?YmpBaUo2aUZ2SEdZLytNYU5nSWdBam1aZEFVaHFGcjFkRUQ1ZHJjT25tYlFp?= =?utf-8?B?VTNJRWFDRTk1U3JWZlRrL3MyeENhK2RFazFBLy84RUxLTVYvc0RMcGwwUm5B?= =?utf-8?B?cTN2YVJNMytiRnpSWDYzcUUvOSsreUhsMlZtZHBCc08yeXRNdGlHaldOZkhj?= =?utf-8?B?eHo3b2dRRHZ0dmxHa3Q1dUFJKzJoWEViUklDeXJHb2duRlBSMW14dVU4WitO?= =?utf-8?B?ajQvS2dnQ1ZQeDEzbkJ2QUVlMFM2N2dBRHdpRjJxbmI1NjFBZ005bWZwbFVW?= =?utf-8?B?MlBZdzg4bnora3ZjTGg0aUUzdWd6TEdPTkJVNmREcFpZdHNOc0JJSnlDUDFh?= =?utf-8?B?VEM4eGczZWtPcmNybC9KNzZGaTk2RVpXSjdvM2N2VWIwWWg0dmVGcERmNDNs?= =?utf-8?B?ZWxWbmw3a3VBMWRwTHlDOGQ1RVBQNTNwWlJxM0RpQlQySVJNUG14STl5MGRZ?= =?utf-8?B?dFlGdnhTYVRzRTJiUDh5K0lpcnZGVE1JeXhrYm1UQ01OempKOXpNMlJxcHpa?= =?utf-8?B?Z0NLaDVXdW9JTW5Nblpjd1gvUVZBSUNxWllEVklxU0p6R1c2MHpObDl5MVEx?= =?utf-8?B?SFVxWVhnQzJwUWlmMlpZb0xmNkNMRTZmOUhXS0JmQ0pHeDhZOVJ3Y2ZRK290?= =?utf-8?B?bG9meU15MytFNzJkWVl5NEt3WVVYOTVXT0RvRWNnK3NiYmsrbHoxVzVzSXBD?= =?utf-8?B?ZE5YUlBwZGwxcEV2WjZvamZydGlBVjRNeURKK1BkQkp0eENBUHJWMmppdmw0?= =?utf-8?B?Rzg2NTRYbFNRUG1hQ0l0Nyt6ZEMxU1R6UHlHb1FjYkNIbXdIbHNVZ1M1MkRv?= =?utf-8?B?TzBnYThDZUFQWWdvdDYza0JqQVJQUlNyV1lSR0w5RC9SQUl6WVdWNUNiODgv?= =?utf-8?B?S0NhN2FNQmtwaWxLT2ZrY1pqNnhVd1Q2Qi9XNEY5L1N4Qi80UXlRY2FtUzM1?= =?utf-8?B?alB5UGZtVk00UUF3c1cwMWMzSWk2ZTRJcnZHSSs0NENxekhNUHJXUXdiSWlE?= =?utf-8?B?c3k1anh2ZER3a0MzQVBvU0Eza1FPa2RGSlJWajZnRVJtSjRmUnE4bnZUUFZB?= =?utf-8?B?MzBlTE9nL0lxTHhoTzlCTDJMb2NKcERLOUk2QnV5UnJVSldnTlhEc21RV2FT?= =?utf-8?B?a0pza1FRcndpcG8ySGQrRUV3d1A3Um1mMDVTaWhmMTRJNnRYOEtmdWxrTERC?= =?utf-8?B?aVhybHhNK1d2amNSbHN6bEs2MHI0L01WNXJrWE5udTRQbmZIOTBIbStONTZr?= =?utf-8?B?cm5meVlMdGJaRWNmS3ltZjZsZnFzMnJJOGlWQ2JTTStUemFPSE9hVG1neGlw?= =?utf-8?B?VGluOUozK3lYQWxnV3V3bnY0WXkxaWdWME5USnZmVHZnZkI0UGZHNjVJcmpO?= =?utf-8?B?K0VHR2c4WWFWRUdMOFBweUJKZDFIMnhMa0d6UjBvWWdqTVU4ZCs0QnJleTZ6?= =?utf-8?B?UHRsdkx5SU5OMVRidXdYMFI2aTI1N2hoUlhaWVJzNWdwdENZWCsvcE9lUWM5?= =?utf-8?B?aUdmbGxxMFJBTWVySDFUSjllbWZVSHc2dm5KNzNvOVRqMlRBS3BTUUNVL2VV?= =?utf-8?B?SEV2UlIrUk95UHNoNDlhdFAvdi9BSzIrM1lwZjAvYmVFek5TTGVYeVJOdUNM?= =?utf-8?B?b1Mzc3poMEkwdkxvL0sxNVRzQVhyOWVvazluMVNsRy9HZzRMWVJaT3h6MlFU?= =?utf-8?B?SGhORjNCTlo0ZDVwN3h5UDhTM0pqTEtTb2FXYndBWWpvUHpFSU9JR1BlLy80?= =?utf-8?B?OUZzbFh0Q1VHZUExeklwUVRtK01ZbWRjOXBpOXY2U1pJZkhzK2RvSDVoRVBu?= =?utf-8?B?Y0JNTjFqMGYxdHpBNHJZSmZHM1BNdzNlamljUWRpMm1KRDRmR3BFQzFtR0FO?= =?utf-8?B?UlhNRVk3S25XYUZlaFlURWRacnFaNXJOUHhMYVVYTkRYRDFLampsbXd6QW10?= =?utf-8?Q?VsRsvMDTnnSkZ2E9c3oDcGA=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <59E139587ED4D04AB26E64A69F32A689@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8895864-4bb0-44c5-0980-08dde97e56e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 17:38:18.8790 (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: 2cmn7rXTBGHCmmNJkVcXR71+tXnHvm3A5CpD6LWgID7b6ILQ/GrLlmYRjL+HZJvTbNBirj3LI7C+qY8EVqtpcUNitv6P8RwJMosSrxsDSBU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9102 SGVsbG8gVm9sb2R5bXlyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY2xvc2UgcmV2aWV3IGFuZCBz dWdnZXN0aW9ucy4NCg0KT24gMjkuMDguMjUgMjM6NDUsIFZvbG9keW15ciBCYWJjaHVrIHdyb3Rl Og0KPiANCj4gSGkgTGVvbmlkLA0KPiANCj4gTGVvbmlkIEtvbWFyaWFuc2t5aSA8TGVvbmlkX0tv bWFyaWFuc2t5aUBlcGFtLmNvbT4gd3JpdGVzOg0KPiANCj4+IFRoaXMgY2hhbmdlIGludHJvZHVj ZXMgcmVzb3VyY2UgbWFuYWdlbWVudCBpbiB0aGUgVkdJQyB0byBoYW5kbGUNCj4+IGV4dGVuZGVk IFNQSXMgaW50cm9kdWNlZCBpbiBHSUN2My4xLiBUaGUgcGVuZGluZ19pcnFzIGFuZA0KPj4gYWxs b2NhdGVkX2lycXMgYXJyYXlzIGFyZSByZXNpemVkIHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVkDQo+ PiBudW1iZXIgb2YgZVNQSXMsIGJhc2VkIG9uIHdoYXQgaXMgc3VwcG9ydGVkIGJ5IHRoZSBoYXJk d2FyZSBhbmQNCj4+IHJlcXVlc3RlZCBieSB0aGUgZ3Vlc3QuIEEgbmV3IGZpZWxkLCBleHRfc2hh cmVkX2lycXMsIGlzIGFkZGVkDQo+PiB0byB0aGUgVkdJQyBzdHJ1Y3R1cmUgdG8gc3RvcmUgaW5m b3JtYXRpb24gYWJvdXQgZVNQSXMsIHNpbWlsYXINCj4+IHRvIGhvdyBzaGFyZWRfaXJxcyBpcyB1 c2VkIGZvciByZWd1bGFyIFNQSXMuDQo+Pg0KPj4gU2luY2UgdGhlIGVTUEkgcmFuZ2Ugc3RhcnRz IGF0IElOVElEIDQwOTYgYW5kIElOVElEcyBiZXR3ZWVuIDEwMjUNCj4+IGFuZCA0MDk1IGFyZSBy ZXNlcnZlZCwgaGVscGVyIG1hY3JvcyBhcmUgaW50cm9kdWNlZCB0byBzaW1wbGlmeSB0aGUNCj4+ IHRyYW5zZm9ybWF0aW9uIG9mIGluZGljZXMgYW5kIHRvIGVuYWJsZSBlYXNpZXIgYWNjZXNzIHRv IGVTUEktc3BlY2lmaWMNCj4+IHJlc291cmNlcy4gVGhlc2UgY2hhbmdlcyBwcmVwYXJlIHRoZSBW R0lDIGZvciBwcm9jZXNzaW5nIGVTUElzIGFzDQo+PiByZXF1aXJlZCBieSBmdXR1cmUgZnVuY3Rp b25hbGl0eS4NCj4+DQo+PiBUaGUgaW5pdGlhbGl6YXRpb24gYW5kIGRlaW5pdGlhbGl6YXRpb24g cGF0aHMgZm9yIHZnaWMgaGF2ZSBiZWVuIHVwZGF0ZWQNCj4+IHRvIGFsbG9jYXRlIGFuZCBmcmVl IHRoZXNlIHJlc291cmNlcyBhcHByb3ByaWF0ZWx5LiBBZGRpdGlvbmFsbHksDQo+PiB1cGRhdGVk IGhhbmRsaW5nIG9mIElOVElEcyBncmVhdGVyIHRoYW4gMTAyNCwgcGFzc2VkIGZyb20gdGhlIHRv b2xzdGFjaw0KPj4gZHVyaW5nIGRvbWFpbiBjcmVhdGlvbiwgYW5kIHZlcmlmaWNhdGlvbiBsb2dp YyBlbnN1cmVzIG9ubHkgdmFsaWQgU1BJIG9yDQo+PiBlU1BJIElOVElEcyBhcmUgdXNlZC4NCj4+ DQo+PiBUaGUgZXhpc3RpbmcgU1BJIGJlaGF2aW9yIHJlbWFpbnMgdW5hZmZlY3RlZCB3aGVuIGd1 ZXN0cyBkbyBub3QgcmVxdWVzdA0KPj4gZVNQSXMsIEdJQyBoYXJkd2FyZSBkb2VzIG5vdCBzdXBw b3J0IHRoZW0sIG9yIHRoZSBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gb3B0aW9uIGlzIGRpc2FibGVk Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IExlb25pZCBLb21hcmlhbnNreWkgPGxlb25pZF9rb21h cmlhbnNreWlAZXBhbS5jb20+DQo+Pg0KPj4gLS0tDQo+PiBDaGFuZ2VzIGluIFY1Og0KPj4gLSBy ZW1vdmVkIHRoZSBoYXNfZXNwaSBmaWVsZCBiZWNhdXNlIGl0IGNhbiBiZSBkZXRlcm1pbmVkIGJ5 IGNoZWNraW5nDQo+PiAgICB3aGV0aGVyIGRvbWFpbi0+YXJjaC52Z2ljLm5yX2VzcGlzIGlzIHpl cm8gb3Igbm90DQo+PiAtIHNpbmNlIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0IGlzIG5vdCB1c2VkIGlu IHRoaXMgcGF0Y2gsIGl0IGhhcyBiZWVuDQo+PiAgICBtb3ZlZCB0byB0aGUgYXBwcm9wcmlhdGUg cGF0Y2ggaW4gdGhlIHBhdGNoIHNlcmllcywgd2hpY2ggaW1wbGVtZW50cw0KPj4gICAgdmdpYyBl U1BJIHJlZ2lzdGVycyBlbXVsYXRpb24gYW5kIHJlcXVpcmVzIHRoaXMgZnVuY3Rpb24NCj4+IC0g cmVtb3ZlZCBpZmRlZnMgZm9yIGVTUEktc3BlY2lmaWMgbWFjcm9zIHRvIHJlZHVjZSB0aGUgbnVt YmVyIG9mIGlmZGVmcw0KPj4gICAgYW5kIGNvZGUgZHVwbGljYXRpb24gaW4gZnVydGhlciBjaGFu Z2VzDQo+PiAtIGZpeGVkIG1pbm9yIG5pdDogdXNlZCAlcGQgZm9yIHByaW50aW5nIGRvbWFpbiB3 aXRoIGl0cyBJRA0KPj4NCj4+IENoYW5nZXMgaW4gVjQ6DQo+PiAtIGFkZGVkIGhhc19lc3BpIGZp ZWxkIHRvIHNpbXBsaWZ5IGRldGVybWluaW5nIHdoZXRoZXIgYSBkb21haW4gaXMgYWJsZQ0KPj4g ICAgdG8gb3BlcmF0ZSB3aXRoIGVTUEkNCj4+IC0gZml4ZWQgZm9ybWF0dGluZyBpc3N1ZXMgYW5k IG1pc3NwZWxsaW5ncw0KPj4NCj4+IENoYW5nZXMgaW4gVjM6DQo+PiAtIGZpeGVkIGZvcm1hdHRp bmcgZm9yIGxpbmVzIHdpdGggbW9yZSB0aGFuIDgwIHN5bWJvbHMNCj4+IC0gaW50cm9kdWNlZCBo ZWxwZXIgZnVuY3Rpb25zIHRvIGJlIGFibGUgdG8gdXNlIHN0dWJzIGluIGNhc2Ugb2YNCj4+ICAg IENPTkZJR19HSUNWM19FU1BJIGRpc2FibGVkLCBhbmQgYXMgYSByZXN1bHQsIHJlZHVjZSB0aGUg bnVtYmVyIG9mDQo+PiAgICAjaWZkZWZzDQo+PiAtIGZpeGVkIGNoZWNrcyBmb3IgbnJfc3BpcyBp biBkb21haW5fdmdpY19pbml0DQo+PiAtIHVwZGF0ZWQgY29tbWVudCBhYm91dCBucl9zcGlzIGFk anVzdG1lbnRzIHdpdGggZG9tMGxlc3MgbWVudGlvbg0KPj4gLSBtb3ZlZCBjb21tZW50IHdpdGgg YWRkaXRpb25hbCBleHBsYW5hdGlvbnMgYmVmb3JlIGNoZWNrcw0KPj4gLSB1c2VkIHVuc2lnbmVk IGludCBmb3IgaW5kZXhlcyBzaW5jZSB0aGV5IGNhbm5vdCBiZSBuZWdhdGl2ZQ0KPj4gLSByZW1v dmVkIHVubmVjZXNzYXJ5IHBhcmVudGhlc2VzDQo+PiAtIG1vdmUgdmdpY19leHRfcmFua19vZmZz ZXQgdG8gdGhlIGJlbG93IGlmZGVmIGd1YXJkLCB0byByZWR1Y2UgdGhlDQo+PiAgICBudW1iZXIg b2YgaWZkZWZzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMjoNCj4+IC0gY2hhbmdlIGlzX2VzcGlfcmFu ayB0byBpc192YWxpZF9lc3BpX3JhbmsgdG8gdmVyaWZ5IHdoZXRoZXIgdGhlIGFycmF5DQo+PiAg ICBlbGVtZW50IGV4dF9zaGFyZWRfaXJxcyBleGlzdHMuIFRoZSBwcmV2aW91cyB2ZXJzaW9uLCBp c19lc3BpX3JhbmssDQo+PiAgICBvbmx5IGNoZWNrZWQgaWYgdGhlIHJhbmsgaW5kZXggd2FzIGxl c3MgdGhhbiB0aGUgbWF4aW11bSBwb3NzaWJsZSBlU1BJDQo+PiAgICByYW5rIGluZGV4LCBidXQg dGhpcyBjb3VsZCBwb3RlbnRpYWxseSByZXN1bHQgaW4gYWNjZXNzaW5nIGENCj4+ICAgIG5vbi1l eGlzdGluZyBhcnJheSBlbGVtZW50LiBUbyBhZGRyZXNzIHRoaXMsIGlzX3ZhbGlkX2VzcGlfcmFu ayB3YXMNCj4+ICAgIGludHJvZHVjZWQsIHdoaWNoIGVuc3VyZXMgdGhhdCB0aGUgcmVxdWlyZWQg ZVNQSSByYW5rIGV4aXN0cw0KPj4gLSBtb3ZlIGdpY19udW1iZXJfZXNwaXMgdG8NCj4+ICAgIHhl bi9hcm06IGdpY3YzOiBpbXBsZW1lbnQgaGFuZGxpbmcgb2YgR0lDdjMuMSBlU1BJDQo+PiAtIHVw ZGF0ZSB2Z2ljX2lzX3ZhbGlkX2lycSBjaGVja3MgdG8gYWxsb3cgb3BlcmF0aW5nIHdpdGggZVNQ SXMNCj4+IC0gcmVtb3ZlIHJlZHVuZGFudCBuZXdsaW5lIGluIHZnaWNfYWxsb2NhdGVfdmlycQ0K Pj4gLS0tDQo+PiAgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmggfCAgMTIgKysNCj4+ ICAgeGVuL2FyY2gvYXJtL3ZnaWMuYyAgICAgICAgICAgICB8IDE5OSArKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrLQ0KPj4gICAyIGZpbGVzIGNoYW5nZWQsIDIwOCBpbnNlcnRpb25zKCsp LCAzIGRlbGV0aW9ucygtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVk ZS9hc20vdmdpYy5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaA0KPj4gaW5kZXgg M2U3Y2JiYjE5Ni4uOTEyZDViNzY5NCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNs dWRlL2FzbS92Z2ljLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgN Cj4+IEBAIC0xNDYsNiArMTQ2LDEwIEBAIHN0cnVjdCB2Z2ljX2Rpc3Qgew0KPj4gICAgICAgaW50 IG5yX3NwaXM7IC8qIE51bWJlciBvZiBTUElzICovDQo+PiAgICAgICB1bnNpZ25lZCBsb25nICph bGxvY2F0ZWRfaXJxczsgLyogYml0bWFwIG9mIElSUXMgYWxsb2NhdGVkICovDQo+PiAgICAgICBz dHJ1Y3QgdmdpY19pcnFfcmFuayAqc2hhcmVkX2lycXM7DQo+PiArI2lmZGVmIENPTkZJR19HSUNW M19FU1BJDQo+PiArICAgIHN0cnVjdCB2Z2ljX2lycV9yYW5rICpleHRfc2hhcmVkX2lycXM7DQo+ PiArICAgIGludCBucl9lc3BpczsgLyogTnVtYmVyIG9mIGV4dGVuZGVkIFNQSXMgKi8NCj4+ICsj ZW5kaWYNCj4+ICAgICAgIC8qDQo+PiAgICAgICAgKiBTUElzIGFyZSBkb21haW4gZ2xvYmFsLCBT R0lzIGFuZCBQUElzIGFyZSBwZXItVkNQVSBhbmQgc3RvcmVkIGluDQo+PiAgICAgICAgKiBzdHJ1 Y3QgYXJjaF92Y3B1Lg0KPj4gQEAgLTI0Myw2ICsyNDcsMTQgQEAgc3RydWN0IHZnaWNfb3BzIHsN Cj4+ICAgLyogTnVtYmVyIG9mIHJhbmtzIG9mIGludGVycnVwdCByZWdpc3RlcnMgZm9yIGEgZG9t YWluICovDQo+PiAgICNkZWZpbmUgRE9NQUlOX05SX1JBTktTKGQpICgoKGQpLT5hcmNoLnZnaWMu bnJfc3BpcyszMSkvMzIpDQo+PiAgIA0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4g KyNkZWZpbmUgRE9NQUlOX05SX0VYVF9SQU5LUyhkKSAoKChkKS0+YXJjaC52Z2ljLm5yX2VzcGlz KzMxKS8zMikNCj4+ICsjZW5kaWYNCj4+ICsjZGVmaW5lIEVYVF9SQU5LX01JTiAoRVNQSV9CQVNF X0lOVElELzMyKQ0KPj4gKyNkZWZpbmUgRVhUX1JBTktfTUFYICgoRVNQSV9NQVhfSU5USUQrMzEp LzMyKQ0KPj4gKyNkZWZpbmUgRVhUX1JBTktfTlVNMklEWChudW0pICgobnVtKS1FWFRfUkFOS19N SU4pDQo+PiArI2RlZmluZSBFWFRfUkFOS19JRFgyTlVNKGlkeCkgKChpZHgpK0VYVF9SQU5LX01J TikNCj4+ICsNCj4+ICAgI2RlZmluZSB2Z2ljX2xvY2sodikgICBzcGluX2xvY2tfaXJxKCYodikt PmRvbWFpbi0+YXJjaC52Z2ljLmxvY2spDQo+PiAgICNkZWZpbmUgdmdpY191bmxvY2sodikgc3Bp bl91bmxvY2tfaXJxKCYodiktPmRvbWFpbi0+YXJjaC52Z2ljLmxvY2spDQo+PiAgIA0KPj4gZGlm ZiAtLWdpdCBhL3hlbi9hcmNoL2FybS92Z2ljLmMgYi94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiBp bmRleCAyYmJmNGQ5OWFhLi5jOWI5NTI4YzY2IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJt L3ZnaWMuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3ZnaWMuYw0KPj4gQEAgLTI3LDkgKzI3LDgy IEBADQo+PiAgIA0KPj4gICBib29sIHZnaWNfaXNfdmFsaWRfbGluZShzdHJ1Y3QgZG9tYWluICpk LCB1bnNpZ25lZCBpbnQgdmlycSkNCj4+ICAgew0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQ SQ0KPj4gKyAgICBpZiAoIHZpcnEgPj0gRVNQSV9CQVNFX0lOVElEICYmDQo+PiArICAgICAgICAg dmlycSA8IEVTUElfSURYMklOVElEKGQtPmFyY2gudmdpYy5ucl9lc3BpcykgKQ0KPj4gKyAgICAg ICAgcmV0dXJuIHRydWU7DQo+PiArI2VuZGlmDQo+PiArDQo+PiAgICAgICByZXR1cm4gdmlycSA8 IHZnaWNfbnVtX2lycXMoZCk7DQo+PiAgIH0NCj4+ICAgDQo+PiArI2lmZGVmIENPTkZJR19HSUNW M19FU1BJDQo+PiArLyoNCj4+ICsgKiBTaW5jZSBlU1BJIGluZGV4ZXMgc3RhcnQgZnJvbSA0MDk2 IGFuZCBudW1iZXJzIGZyb20gMTAyNCB0bw0KPj4gKyAqIDQwOTUgYXJlIGZvcmJpZGRlbiwgd2Ug bmVlZCB0byBjaGVjayBib3RoIGxvd2VyIGFuZCB1cHBlcg0KPj4gKyAqIGxpbWl0cyBmb3IgcmFu a3MuDQo+PiArICovDQo+PiArc3RhdGljIGlubGluZSBib29sIGlzX3ZhbGlkX2VzcGlfcmFuayhz dHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgcmFuaykNCj4+ICt7DQo+PiArICAgIHJldHVy biByYW5rID49IEVYVF9SQU5LX01JTiAmJg0KPj4gKyAgICAgICAgICAgRVhUX1JBTktfTlVNMklE WChyYW5rKSA8IERPTUFJTl9OUl9FWFRfUkFOS1MoZCk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRp YyBpbmxpbmUgc3RydWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfZ2V0X2VzcGlfcmFuayhzdHJ1Y3Qg dmNwdSAqdiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdW5zaWduZWQgaW50IHJhbmspDQo+PiArew0KPj4gKyAgICByZXR1cm4gJnYt PmRvbWFpbi0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxc1tFWFRfUkFOS19OVU0ySURYKHJhbmsp XTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGlubGluZSBib29sIHZnaWNfcmVzZXJ2ZV9lc3Bp X3ZpcnEoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IHZpcnEpDQo+PiArew0KPj4gKyAg ICByZXR1cm4gIXRlc3RfYW5kX3NldF9iaXQoRVNQSV9JTlRJRDJJRFgodmlycSkgKyB2Z2ljX251 bV9pcnFzKGQpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+YXJjaC52Z2lj LmFsbG9jYXRlZF9pcnFzKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZvaWQgYXJjaF9tb3Zl X2VzcGlzKHN0cnVjdCB2Y3B1ICp2KQ0KPiANCj4gSSBkb24ndCBuZWVkIHlvdSBuZWVkIGEgY29w eSBvZiBhcmNoX21vdmVfaXJxcygpLiBTZSBiZWxvdyBmb3IgbW9yZSBpbmZvLg0KPiANCj4+ICt7 DQo+PiArICAgIGNvbnN0IGNwdW1hc2tfdCAqY3B1X21hc2sgPSBjcHVtYXNrX29mKHYtPnByb2Nl c3Nvcik7DQo+PiArICAgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21haW47DQo+PiArICAgIHN0 cnVjdCBwZW5kaW5nX2lycSAqcDsNCj4+ICsgICAgc3RydWN0IHZjcHUgKnZfdGFyZ2V0Ow0KPj4g KyAgICB1bnNpZ25lZCBpbnQgaTsNCj4+ICsNCj4+ICsgICAgZm9yICggaSA9IEVTUElfQkFTRV9J TlRJRDsNCj4+ICsgICAgICAgICAgaSA8IEVYVF9SQU5LX0lEWDJOVU0oZC0+YXJjaC52Z2ljLm5y X2VzcGlzKTsgaSsrICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgdl90YXJnZXQgPSB2Z2ljX2dl dF90YXJnZXRfdmNwdSh2LCBpKTsNCj4+ICsgICAgICAgIHAgPSBpcnFfdG9fcGVuZGluZyh2X3Rh cmdldCwgaSk7DQo+PiArDQo+PiArICAgICAgICBpZiAoIHZfdGFyZ2V0ID09IHYgJiYgIXRlc3Rf Yml0KEdJQ19JUlFfR1VFU1RfTUlHUkFUSU5HLCAmcC0+c3RhdHVzKSApDQo+PiArICAgICAgICAg ICAgaXJxX3NldF9hZmZpbml0eShwLT5kZXNjLCBjcHVfbWFzayk7DQo+PiArICAgIH0NCj4+ICt9 DQo+PiArI2Vsc2UNCj4+ICtzdGF0aWMgaW5saW5lIGJvb2wgaXNfdmFsaWRfZXNwaV9yYW5rKHN0 cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCByYW5rKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJu IGZhbHNlOw0KPj4gK30NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIFRoaXMgZnVuY3Rpb24gaXMgc3R1 YiBhbmQgd2lsbCBub3QgYmUgY2FsbGVkIGlmIENPTkZJR19HSUNWM19FU1BJPW4sDQo+PiArICog YmVjYXVzZSBpbiB0aGlzIGNhc2UsIGlzX3ZhbGlkX2VzcGlfcmFuayB3aWxsIGFsd2F5cyByZXR1 cm4gZmFsc2UuDQo+PiArICovDQo+PiArc3RhdGljIGlubGluZSBzdHJ1Y3QgdmdpY19pcnFfcmFu ayAqdmdpY19nZXRfZXNwaV9yYW5rKHN0cnVjdCB2Y3B1ICp2LA0KPj4gKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgcmFu aykNCj4+ICt7DQo+PiArICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KPj4gKyAgICByZXR1cm4g TlVMTDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGlubGluZSBib29sIHZnaWNfcmVzZXJ2ZV9l c3BpX3ZpcnEoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IHZpcnEpDQo+PiArew0KPj4g KyAgICByZXR1cm4gZmFsc2U7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGFyY2hfbW92 ZV9lc3BpcyhzdHJ1Y3QgdmNwdSAqdikgeyB9DQo+PiArI2VuZGlmDQo+PiArDQo+PiAgIHN0YXRp YyBpbmxpbmUgc3RydWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfZ2V0X3Jhbmsoc3RydWN0IHZjcHUg KnYsDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdW5zaWduZWQgaW50IHJhbmspDQo+PiAgIHsNCj4+IEBAIC0zNyw2ICsxMTAsOCBAQCBzdGF0 aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9yYW5rKHN0cnVjdCB2Y3B1 ICp2LA0KPj4gICAgICAgICAgIHJldHVybiB2LT5hcmNoLnZnaWMucHJpdmF0ZV9pcnFzOw0KPj4g ICAgICAgZWxzZSBpZiAoIHJhbmsgPD0gRE9NQUlOX05SX1JBTktTKHYtPmRvbWFpbikgKQ0KPj4g ICAgICAgICAgIHJldHVybiAmdi0+ZG9tYWluLT5hcmNoLnZnaWMuc2hhcmVkX2lycXNbcmFuayAt IDFdOw0KPj4gKyAgICBlbHNlIGlmICggaXNfdmFsaWRfZXNwaV9yYW5rKHYtPmRvbWFpbiwgcmFu aykgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHZnaWNfZ2V0X2VzcGlfcmFuayh2LCByYW5rKTsNCj4+ ICAgICAgIGVsc2UNCj4+ICAgICAgICAgICByZXR1cm4gTlVMTDsNCj4+ICAgfQ0KPj4gQEAgLTEx Nyw2ICsxOTIsNjIgQEAgaW50IGRvbWFpbl92Z2ljX3JlZ2lzdGVyKHN0cnVjdCBkb21haW4gKmQs IHVuc2lnbmVkIGludCAqbW1pb19jb3VudCkNCj4+ICAgICAgIHJldHVybiAwOw0KPj4gICB9DQo+ PiAgIA0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gK3N0YXRpYyB1bnNpZ25lZCBp bnQgdmdpY19udW1fc3BpX2xpbmVzKHN0cnVjdCBkb21haW4gKmQpDQo+PiArew0KPj4gKyAgICBy ZXR1cm4gZC0+YXJjaC52Z2ljLm5yX3NwaXMgKyBkLT5hcmNoLnZnaWMubnJfZXNwaXM7DQo+PiAr fQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgaW5pdF92Z2ljX2VzcGkoc3RydWN0IGRvbWFpbiAqZCkN Cj4+ICt7DQo+PiArICAgIHVuc2lnbmVkIGludCBpLCBpZHg7DQo+PiArDQo+PiArICAgIGlmICgg ZC0+YXJjaC52Z2ljLm5yX2VzcGlzID09IDAgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiAr DQo+PiArICAgIGQtPmFyY2gudmdpYy5leHRfc2hhcmVkX2lycXMgPQ0KPj4gKyAgICAgICAgeHph bGxvY19hcnJheShzdHJ1Y3QgdmdpY19pcnFfcmFuaywgRE9NQUlOX05SX0VYVF9SQU5LUyhkKSk7 DQo+PiArICAgIGlmICggZC0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxcyA9PSBOVUxMICkNCj4+ ICsgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPj4gKw0KPj4gKyAgICBmb3IgKCBpID0gZC0+YXJj aC52Z2ljLm5yX3NwaXMsIGlkeCA9IDA7DQo+PiArICAgICAgICAgIGkgPCB2Z2ljX251bV9zcGlf bGluZXMoZCk7IGkrKywgaWR4KysgKQ0KPj4gKyAgICAgICAgdmdpY19pbml0X3BlbmRpbmdfaXJx KCZkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFzW2ldLA0KPj4gKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEVTUElfSURYMklOVElEKGlkeCkpOw0KPj4gKw0KPj4gKyAgICBmb3IgKCBpID0g MDsgaSA8IERPTUFJTl9OUl9FWFRfUkFOS1MoZCk7IGkrKyApDQo+PiArICAgICAgICB2Z2ljX3Jh bmtfaW5pdCgmZC0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxc1tpXSwgaSwgMCk7DQo+PiArDQo+ PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdHJ1Y3QgcGVuZGluZ19pcnEgKmVz cGlfdG9fcGVuZGluZyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgaXJxKQ0KPiANCj4g SSBrbm93IHRoYXQgSSBzaG91bGQgbWFkZSB0aGlzIG9ic2VydmF0aW9uIGluIHByZXZpb3VzIHZl cnNpb24sIGJ1dCBJDQo+IGRpZG4ndCwgc29ycnkgZm9yIHRoYXQuIEFueXdheXMsIEkgZG9uJ3Qg dGhpbmsgdGhhdCB0aGlzIGlzIGEgZ29vZCBpZGVhDQo+IHRvIGludHJvZHVjZSB0aGlzIGZ1bmN0 aW9uIGFuZCB2Z2ljX3Jlc2VydmVfZXNwaV92aXJxKCksIGFzIHdlbGwgYXMNCj4gYXJjaF9tb3Zl X2VzcGlzKCksIGFjdHVhbGx5LCBiZWNhdXNlIGluIGVhY2ggY2FzZSB0aGlzIGlzIGEgY29kZQ0K PiBkdXBsaWNhdGlvbiwgd2hpY2ggaXMgbm90IGdvb2QuDQo+IA0KPiBJIHRoaW5rIHRoYXQgaW5z dGVhZCB5b3UgbmVlZCB0byBpbnRyb2R1Y2UgYSBwYWlyIG9mIGhlbHBlcnMgdGhhdCB3aWxsDQo+ IG1hcCBhbnkgKGUpU1BJIG51bWJlciB0byBwZW5kaW5nX2lycVtdL2FsbG9jYXRlX2lycXMgaW5k ZXggYW5kIGJhY2suDQo+IA0KPiBzb21ldGhpbmsgbGlrZQ0KPiANCj4gc3RhdGljIGlubGluZSB1 bnNpZ25lZCB2aXJxX3RvX2luZGV4KGludCB2aXJxKQ0KPiB7DQo+ICAgICBpZiAoaXNfZXNwaSh2 aXJxKSkNCj4gICAgICAgICByZXR1cm4gRVNQSV9JTlRJRDJJRFgoaXJxKSArIGQtPmFyY2gudmdp Yy5ucl9zcGlzOw0KPiAgICAgcmV0dXJuIHZpcnE7DQo+IH0NCj4gDQo+IFNlZSBiZWxvdyBmb3Ig ZXhhbXBsZXMuDQo+IA0KDQpZb3UgZG8gbm90IG5lZWQgdG8gc2F5IHNvcnJ5IGZvciB0aGF0IDop IFlvdSBwcm92aWRlZCBhIHZlcnkgZ29vZCANCnNvbHV0aW9uIHdpdGggdGhpcyBoZWxwZXIgZnVu Y3Rpb24uIFNvIHRoYW5rIHlvdSBhZ2FpbiBmb3IgdGhhdCAtIEkgd2lsbCANCmFkZCB0aGUgaGVs cGVyIGZ1bmN0aW9uIGluIFY2IHRvIGNvbnNvbGlkYXRlIHNpbWlsYXIgY29kZSBpbnRvIGl0IGFu ZCwgDQphcyBhIHJlc3VsdCwgcmV1c2UgZXhpc3RpbmcgY29kZSB3aXRob3V0IGR1cGxpY2F0aW9u Lg0KDQo+PiArew0KPj4gKyAgICBpcnEgPSBFU1BJX0lOVElEMklEWChpcnEpICsgZC0+YXJjaC52 Z2ljLm5yX3NwaXM7DQo+PiArICAgIHJldHVybiAmZC0+YXJjaC52Z2ljLnBlbmRpbmdfaXJxc1tp cnFdOw0KPj4gK30NCj4+ICsjZWxzZQ0KPj4gK3N0YXRpYyB1bnNpZ25lZCBpbnQgaW5pdF92Z2lj X2VzcGkoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArICAgIHJldHVybiAwOw0KPj4gK30N Cj4+ICsNCj4+ICtzdGF0aWMgdW5zaWduZWQgaW50IHZnaWNfbnVtX3NwaV9saW5lcyhzdHJ1Y3Qg ZG9tYWluICpkKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJuIGQtPmFyY2gudmdpYy5ucl9zcGlzOw0K Pj4gK30NCj4+ICsNCj4+ICtzdHJ1Y3QgcGVuZGluZ19pcnEgKmVzcGlfdG9fcGVuZGluZyhzdHJ1 Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJuIE5V TEw7DQo+PiArfQ0KPj4gKyNlbmRpZg0KPj4gKw0KPj4gK3N0YXRpYyB1bnNpZ25lZCBpbnQgdmdp Y19udW1fYWxsb2NfaXJxcyhzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJu IHZnaWNfbnVtX3NwaV9saW5lcyhkKSArIE5SX0xPQ0FMX0lSUVM7DQo+PiArfQ0KPj4gKw0KPj4g ICBpbnQgZG9tYWluX3ZnaWNfaW5pdChzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgbnJf c3BpcykNCj4+ICAgew0KPj4gICAgICAgaW50IGk7DQo+PiBAQCAtMTMxLDYgKzI2MiwzNiBAQCBp bnQgZG9tYWluX3ZnaWNfaW5pdChzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgbnJfc3Bp cykNCj4+ICAgICAgICAqLw0KPj4gICAgICAgbnJfc3BpcyA9IFJPVU5EVVAobnJfc3BpcywgMzIp Ow0KPj4gICANCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICsgICAgLyoNCj4+ICsg ICAgICogRHVyaW5nIGRvbWFpbiBjcmVhdGlvbiwgdGhlIGRvbTBsZXNzIERvbVVzIGNvZGUgb3Ig dG9vbHN0YWNrIHNwZWNpZmllcw0KPj4gKyAgICAgKiB0aGUgbWF4aW11bSBJTlRJRCwgd2hpY2gg aXMgZGVmaW5lZCBpbiB0aGUgZG9tYWluIGNvbmZpZyBzdWJ0cmFjdGVkIGJ5DQo+PiArICAgICAq IDMyIHRvIGNvdmVyIHRoZSBsb2NhbCBJUlFzIChwbGVhc2Ugc2VlIHRoZSBjb21tZW50IHRvIFZH SUNfREVGX05SX1NQSVMpLg0KPj4gKyAgICAgKiBUbyBjb21wdXRlIHRoZSBhY3R1YWwgbnVtYmVy IG9mIGVTUEkgdGhhdCB3aWxsIGJlIHVzYWJsZSBmb3IsDQo+PiArICAgICAqIGFkZCBiYWNrIDMy Lg0KPj4gKyAgICAgKi8NCj4+ICsgICAgaWYgKCBucl9zcGlzICsgMzIgPiBFU1BJX0lEWDJJTlRJ RChOUl9FU1BJX0lSUVMpICkNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4g KyAgICBpZiAoIG5yX3NwaXMgKyAzMiA+PSBFU1BJX0JBU0VfSU5USUQgKQ0KPj4gKyAgICB7DQo+ PiArICAgICAgICBkLT5hcmNoLnZnaWMubnJfZXNwaXMgPSBtaW4obnJfc3BpcyAtIEVTUElfQkFT RV9JTlRJRCArIDMyLCAxMDI0VSk7DQo+PiArICAgICAgICAvKiBWZXJpZnkgaWYgR0lDIEhXIGNh biBoYW5kbGUgcHJvdmlkZWQgSU5USUQgKi8NCj4+ICsgICAgICAgIGlmICggZC0+YXJjaC52Z2lj Lm5yX2VzcGlzID4gZ2ljX251bWJlcl9lc3BpcygpICkNCj4+ICsgICAgICAgICAgICByZXR1cm4g LUVJTlZBTDsNCj4+ICsgICAgICAgIC8qDQo+PiArICAgICAgICAgKiBTZXQgdGhlIG1heGltdW0g YXZhaWxhYmxlIG51bWJlciBmb3IgcmVndWxhcg0KPj4gKyAgICAgICAgICogU1BJIHRvIHBhc3Mg dGhlIG5leHQgY2hlY2sNCj4+ICsgICAgICAgICAqLw0KPj4gKyAgICAgICAgbnJfc3BpcyA9IFZH SUNfREVGX05SX1NQSVM7DQo+PiArICAgIH0NCj4+ICsgICAgZWxzZQ0KPj4gKyAgICB7DQo+PiAr ICAgICAgICAvKiBEb21haW4gd2lsbCB1c2UgdGhlIHJlZ3VsYXIgU1BJIHJhbmdlICovDQo+PiAr ICAgICAgICBkLT5hcmNoLnZnaWMubnJfZXNwaXMgPSAwOw0KPj4gKyAgICB9DQo+PiArI2VuZGlm DQo+PiArDQo+PiAgICAgICAvKiBMaW1pdCB0aGUgbnVtYmVyIG9mIHZpcnR1YWwgU1BJcyBzdXBw b3J0ZWQgdG8gKDEwMjAgLSAzMikgPSA5ODggICovDQo+PiAgICAgICBpZiAoIG5yX3NwaXMgPiAo MTAyMCAtIE5SX0xPQ0FMX0lSUVMpICkNCj4+ICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ IEBAIC0xNDUsNyArMzA2LDcgQEAgaW50IGRvbWFpbl92Z2ljX2luaXQoc3RydWN0IGRvbWFpbiAq ZCwgdW5zaWduZWQgaW50IG5yX3NwaXMpDQo+PiAgICAgICAgICAgcmV0dXJuIC1FTk9NRU07DQo+ PiAgIA0KPj4gICAgICAgZC0+YXJjaC52Z2ljLnBlbmRpbmdfaXJxcyA9DQo+PiAtICAgICAgICB4 emFsbG9jX2FycmF5KHN0cnVjdCBwZW5kaW5nX2lycSwgZC0+YXJjaC52Z2ljLm5yX3NwaXMpOw0K Pj4gKyAgICAgICAgeHphbGxvY19hcnJheShzdHJ1Y3QgcGVuZGluZ19pcnEsIHZnaWNfbnVtX3Nw aV9saW5lcyhkKSk7DQo+PiAgICAgICBpZiAoIGQtPmFyY2gudmdpYy5wZW5kaW5nX2lycXMgPT0g TlVMTCApDQo+PiAgICAgICAgICAgcmV0dXJuIC1FTk9NRU07DQo+PiAgIA0KPj4gQEAgLTE1Niwx MiArMzE3LDE2IEBAIGludCBkb21haW5fdmdpY19pbml0KHN0cnVjdCBkb21haW4gKmQsIHVuc2ln bmVkIGludCBucl9zcGlzKQ0KPj4gICAgICAgZm9yICggaSA9IDA7IGkgPCBET01BSU5fTlJfUkFO S1MoZCk7IGkrKyApDQo+PiAgICAgICAgICAgdmdpY19yYW5rX2luaXQoJmQtPmFyY2gudmdpYy5z aGFyZWRfaXJxc1tpXSwgaSArIDEsIDApOw0KPj4gICANCj4+ICsgICAgcmV0ID0gaW5pdF92Z2lj X2VzcGkoZCk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+ PiArDQo+PiAgICAgICByZXQgPSBkLT5hcmNoLnZnaWMuaGFuZGxlci0+ZG9tYWluX2luaXQoZCk7 DQo+PiAgICAgICBpZiAoIHJldCApDQo+PiAgICAgICAgICAgcmV0dXJuIHJldDsNCj4+ICAgDQo+ PiAgICAgICBkLT5hcmNoLnZnaWMuYWxsb2NhdGVkX2lycXMgPQ0KPj4gLSAgICAgICAgeHphbGxv Y19hcnJheSh1bnNpZ25lZCBsb25nLCBCSVRTX1RPX0xPTkdTKHZnaWNfbnVtX2lycXMoZCkpKTsN Cj4+ICsgICAgICAgIHh6YWxsb2NfYXJyYXkodW5zaWduZWQgbG9uZywgQklUU19UT19MT05HUyh2 Z2ljX251bV9hbGxvY19pcnFzKGQpKSk7DQo+PiAgICAgICBpZiAoICFkLT5hcmNoLnZnaWMuYWxs b2NhdGVkX2lycXMgKQ0KPj4gICAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPj4gICANCj4+IEBA IC0xOTUsOSArMzYwLDI3IEBAIHZvaWQgZG9tYWluX3ZnaWNfZnJlZShzdHJ1Y3QgZG9tYWluICpk KQ0KPj4gICAgICAgICAgIH0NCj4+ICAgICAgIH0NCj4+ICAgDQo+PiArI2lmZGVmIENPTkZJR19H SUNWM19FU1BJDQo+PiArICAgIGZvciAoIGkgPSAwOyBpIDwgZC0+YXJjaC52Z2ljLm5yX2VzcGlz OyBpKysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBzdHJ1Y3QgcGVuZGluZ19pcnEgKnAgPSBz cGlfdG9fcGVuZGluZyhkLCBFU1BJX0lEWDJJTlRJRChpKSk7DQo+PiArDQo+PiArICAgICAgICBp ZiAoIHAtPmRlc2MgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHJldCA9IHJlbGVh c2VfZ3Vlc3RfaXJxKGQsIHAtPmlycSk7DQo+PiArICAgICAgICAgICAgaWYgKCByZXQgKQ0KPj4g KyAgICAgICAgICAgICAgICBkcHJpbnRrKFhFTkxPR19HX1dBUk5JTkcsICIlcGQ6IEZhaWxlZCB0 byByZWxlYXNlIHZpcnEgJXUgcmV0ID0gJWRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgICAg ICAgZCwgcC0+aXJxLCByZXQpOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICB9DQo+PiArI2VuZGlm DQo+PiArDQo+PiAgICAgICBpZiAoIGQtPmFyY2gudmdpYy5oYW5kbGVyICkNCj4+ICAgICAgICAg ICBkLT5hcmNoLnZnaWMuaGFuZGxlci0+ZG9tYWluX2ZyZWUoZCk7DQo+PiAgICAgICB4ZnJlZShk LT5hcmNoLnZnaWMuc2hhcmVkX2lycXMpOw0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0K Pj4gKyAgICB4ZnJlZShkLT5hcmNoLnZnaWMuZXh0X3NoYXJlZF9pcnFzKTsNCj4+ICsjZW5kaWYN Cj4+ICAgICAgIHhmcmVlKGQtPmFyY2gudmdpYy5wZW5kaW5nX2lycXMpOw0KPj4gICAgICAgeGZy ZWUoZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzKTsNCj4+ICAgfQ0KPj4gQEAgLTMzMSw2ICs1 MTQsOCBAQCB2b2lkIGFyY2hfbW92ZV9pcnFzKHN0cnVjdCB2Y3B1ICp2KQ0KPj4gICAgICAgICAg IGlmICggdl90YXJnZXQgPT0gdiAmJiAhdGVzdF9iaXQoR0lDX0lSUV9HVUVTVF9NSUdSQVRJTkcs ICZwLT5zdGF0dXMpICkNCj4+ICAgICAgICAgICAgICAgaXJxX3NldF9hZmZpbml0eShwLT5kZXNj LCBjcHVfbWFzayk7DQo+PiAgICAgICB9DQo+PiArDQo+PiArICAgIGFyY2hfbW92ZV9lc3Bpcyh2 KTsNCj4+ICAgfQ0KPj4gICANCj4+ICAgdm9pZCB2Z2ljX2Rpc2FibGVfaXJxcyhzdHJ1Y3QgdmNw dSAqdiwgdWludDMyX3QgciwgdW5zaWduZWQgaW50IG4pDQo+PiBAQCAtNTM4LDYgKzcyMyw4IEBA IHN0cnVjdCBwZW5kaW5nX2lycSAqaXJxX3RvX3BlbmRpbmcoc3RydWN0IHZjcHUgKnYsIHVuc2ln bmVkIGludCBpcnEpDQo+PiAgICAgICAgICAgbiA9ICZ2LT5hcmNoLnZnaWMucGVuZGluZ19pcnFz W2lycV07DQo+PiAgICAgICBlbHNlIGlmICggaXNfbHBpKGlycSkgKQ0KPj4gICAgICAgICAgIG4g PSB2LT5kb21haW4tPmFyY2gudmdpYy5oYW5kbGVyLT5scGlfdG9fcGVuZGluZyh2LT5kb21haW4s IGlycSk7DQo+PiArICAgIGVsc2UgaWYgKCBpc19lc3BpKGlycSkgKQ0KPj4gKyAgICAgICAgbiA9 IGVzcGlfdG9fcGVuZGluZyh2LT5kb21haW4sIGlycSk7DQo+PiAgICAgICBlbHNlDQo+PiAgICAg ICAgICAgbiA9ICZ2LT5kb21haW4tPmFyY2gudmdpYy5wZW5kaW5nX2lycXNbaXJxIC0gMzJdOw0K Pj4gICAgICAgcmV0dXJuIG47DQo+PiBAQCAtNTQ3LDYgKzczNCw5IEBAIHN0cnVjdCBwZW5kaW5n X2lycSAqc3BpX3RvX3BlbmRpbmcoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IGlycSkN Cj4+ICAgew0KPj4gICAgICAgQVNTRVJUKGlycSA+PSBOUl9MT0NBTF9JUlFTKTsNCj4+ICAgDQo+ PiArICAgIGlmICggaXNfZXNwaShpcnEpICkNCj4+ICsgICAgICAgIHJldHVybiBlc3BpX3RvX3Bl bmRpbmcoZCwgaXJxKTsNCj4+ICsNCj4gDQo+IGhlcmUgeW91IGNhbiBqdXN0IGRvDQo+IA0KPiBp ZHggPSB2aXJxX3RvX2lkeCh2aXJxKTsNCj4gDQo+PiAgICAgICByZXR1cm4gJmQtPmFyY2gudmdp Yy5wZW5kaW5nX2lycXNbaXJxIC0gMzJdOw0KPiANCj4gYW5kDQo+IA0KPiByZXR1cm4gJmQtPmFy Y2gudmdpYy5wZW5kaW5nX2lycXNbaWR4XTsNCj4gDQo+IGluc3RlYWQNCj4gDQo+PiAgIH0NCj4+ ICAgDQo+PiBAQCAtNjY4LDYgKzg1OCw5IEBAIGJvb2wgdmdpY19yZXNlcnZlX3ZpcnEoc3RydWN0 IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IHZpcnEpDQo+PiAgICAgICBpZiAoICF2Z2ljX2lzX3Zh bGlkX2xpbmUoZCwgdmlycSkgKQ0KPj4gICAgICAgICAgIHJldHVybiBmYWxzZTsNCj4+ICAgDQo+ PiArICAgIGlmICggaXNfZXNwaSh2aXJxKSApDQo+PiArICAgICAgICByZXR1cm4gdmdpY19yZXNl cnZlX2VzcGlfdmlycShkLCB2aXJxKTsNCj4+ICsNCj4gDQo+IGhlcmUgeW91IGNhbiBqdXN0IGRv DQo+IA0KPiBpZHggPSB2aXJxX3RvX2lkeCh2aXJxKQ0KPiANCj4+ICAgICAgIHJldHVybiAhdGVz dF9hbmRfc2V0X2JpdCh2aXJxLCBkLT5hcmNoLnZnaWMuYWxsb2NhdGVkX2lycXMpOw0KPiANCj4g YW5kIHRoZW4ganVzdA0KPiANCj4gcmV0dXJuICF0ZXN0X2FuZF9zZXRfYml0KGlkeCwgZC0+YXJj aC52Z2ljLmFsbG9jYXRlZF9pcnFzKTsNCj4gDQo+IA0KPj4gICB9DQo+PiAgIA0KPj4gQEAgLTY4 NSw3ICs4NzgsNyBAQCBpbnQgdmdpY19hbGxvY2F0ZV92aXJxKHN0cnVjdCBkb21haW4gKmQsIGJv b2wgc3BpKQ0KPj4gICAgICAgZWxzZQ0KPj4gICAgICAgew0KPj4gICAgICAgICAgIGZpcnN0ID0g MzI7DQo+PiAtICAgICAgICBlbmQgPSB2Z2ljX251bV9pcnFzKGQpOw0KPj4gKyAgICAgICAgZW5k ID0gdmdpY19udW1fYWxsb2NfaXJxcyhkKTsNCj4+ICAgICAgIH0NCj4gDQo+IEkgdGhpbmogeW91 IG5lZWQgdG8gcmVjYWxjdWxhdGUgInZpcnEiIHZhbHVlIGF0IHRoZSBlbmQgb2YgdGhpcw0KPiBm dW5jdGlvbi4gWW91J2xsIHJldHVybiBpbmRleCBpbiBiaXRmaWVsZCwgYnV0IHRoaXMgaXMgbm90 IHRoZSBzYW1lIGlzDQo+IElSUSBudW1iZXIgaW4gY2FzZSBvZiBlU1BJcy4gVGhlIGhlbHBlcnMg SSBtZW50aW9uZWQgYmVmb3JlIGNhbiBoZWxwIGhlcmUuDQo+IA0KDQpPaCwgSSBtaXNzZWQgdGhp cy4gSXQgZGVmaW5pdGVseSBuZWVkcyB0byBiZSByZWNhbGN1bGF0ZWQgZm9yIGVTUElzLiBJIA0K d2lsbCBhZGQgYSBmaXggZm9yIHRoaXMgaW4gVjYuDQoNCj4+ICAgDQo+PiAgICAgICAvKg0KPiAN Cj4gTGFzdGx5LCBJIHRoaW5rIHRoYXQgaXQgaXMgdmVyeSB3YXN0ZWZ1bCB0byBhbGxvY2F0ZSBw ZW5kaW5nX2lycXMgYXMNCj4gY29udGludW91cyBhcnJheSwgYmVjYXVzZSBpdCB3aWxsIGNvbnNp c3QgbW9zdGx5IG9mIHVudXNlZCBlbnRyaWVzLA0KPiBlc3BlY2lhbGx5IHdpdGggZVNQSXMgZW5h YmxlLiBQcm9iYWJseSwgYmV0dGVyIGFwcHJvYWNoIHdpbGwgYmUgdG8gdXNlIHJhZGl4DQo+IHRy ZWUuIEFzIGEgYm9udXMsIHlvdSBjYW4gdXNlIElSUSBsaW5lIG51bWJlciBhcyBhIGtleSwgYW5k IGdldCByaWQgb2YNCj4gYWxsIHRoZXNlIGlzX2VzcGkoKSBjaGVja3MgYW5kIG1hcHBpbmdzIGJl dHdlZW4gSVJRIG51bWJlciBhbmQgaW5kZXggaW4NCj4gdGhlIGFycmF5LiAgQnV0IHRoaXMgaXMg YSBtdWNoIG1vcmUgZHJhc3RpYyBjaGFuZ2UsIGFuZCBJIGRvbid0IHRoaW5rIHRoYXQgaXQNCj4g c2hvdWxkIGJlIGRvbmUgaW4gdGhpcyBwYXRjaCBzZXJpZXMuLi4NCj4gDQoNClllcywgSSBhZ3Jl ZSB3aXRoIHRoYXQuIEl0IGNhbiBiZSBpbXByb3ZlZCwgYnV0IGZpcnN0LCBJIG5lZWQgdG8gcHJl cGFyZSANCnRoZSBzb2x1dGlvbiB3aXRoIGR5bmFtaWMgYWxsb2NhdGlvbiBmb3IgSVJRIGRlc2Ny aXB0b3JzLCBhcyBJIHByb21pc2VkIA0KcHJldmlvdXNseS4gT2YgY291cnNlLCBhZnRlciBtZXJn aW5nIHRoZSBjdXJyZW50IGVTUEkgcGF0Y2ggc2VyaWVzLg0KDQpCZXN0IHJlZ2FyZHMsDQpMZW9u aWQNCg== From xen-devel-bounces@lists.xenproject.org Mon Sep 01 17:41:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 17:41:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105274.1456199 (Exim 4.92) (envelope-from ) id 1ut8Wr-0003GZ-OM; Mon, 01 Sep 2025 17:41:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105274.1456199; Mon, 01 Sep 2025 17: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 1ut8Wr-0003GS-K0; Mon, 01 Sep 2025 17:41:17 +0000 Received: by outflank-mailman (input) for mailman id 1105274; Mon, 01 Sep 2025 17:41: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 1ut8Wq-0003GL-A6 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 17:41:16 +0000 Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d7e3bb11-875a-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 19:41:09 +0200 (CEST) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 02B7C7A028B; Mon, 1 Sep 2025 13:41:07 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Mon, 01 Sep 2025 13:41:08 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 1 Sep 2025 13:41: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: d7e3bb11-875a-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1756748467; x=1756834867; bh=wWR4mlZntfDuqG+/ioo66gHv6xU4Ml0wEsxTSXc+XDM=; b= MbyyxlX4ROoOd+1rXVKcx6khHI1yaBGhYhrJzqzFxnpQ1HJ2X4phh6ctSGzHd895 EzWONAYnuLu20wIHRo+FVtPWbsfKuQph0JKBtd+1WjIYMkPkTpBIYXCSVbejj3ni RB4aQJWjywkX/tQE/iJg61Qn2pvLXuyIYwikRVOD106xfEHLSLHVyKH6jVAIJguc KqWyhgwDoeZfTLW4LNKJbRSWvDBlLfIaVuycu5baWHh/oenVVw+t4CwXHKDAjUPu 4EJgUXvpuLw9CvSqomQs0drQDU489kyvLb4nwoH6y5RxvjcgJGr1EKw0qi/mS3rG oU2ZJ1jThSTq7Ypm5DFDUw== 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= 1756748467; x=1756834867; bh=wWR4mlZntfDuqG+/ioo66gHv6xU4Ml0wEsx TSXc+XDM=; b=gS+9t3ehRylqGT7w1l6XUJ5FjQF+CQ7yAo4Hge0lgHL0NdbvAmd 0lcMz8RJ8kmeVE7GSDwFkx8g0rLnr5tWpdQXMS6mR+2EIAFYxi2mf1T6es/Tu4Gn csLds+w+Sa7jlhsXwkQRh6+oUh53CeY9Ir1pyypL4NfgEoj8pj09xeNdd2IhajZ/ u+3xPMLDSfJbMgCQeWFvAwRZMSbDSHf6dDYjBtq8TOzL6zdIf0/u2HrUghGlpkbt K+2qKqbP98fBoBN2ERoW/x+9bB8mPiGl6ltV8RdPnOrAO9DN8ow+YRHeMaufYBFm qgc3aIvGktRT5tdhwjNgUOg0im0SqMnzC8A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduledvjeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddupd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgr shhssegtlhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtsh drgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgv rhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrug esvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgu rdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtoheprh hoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhl ihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepkhgvvhhinhdrlhgrmhhpihhsse gtlhhouhgurdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 1 Sep 2025 19:41:03 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Gerald Elder-Vass Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , Kevin Lampis , "Daniel P. Smith" , Jan Beulich Subject: Re: [XEN PATCH] efi: Use Shim's LoadImage to verify the Dom0 kernel Message-ID: References: <766be642204043b779cef688ec0ca2f1d64313ad.1756740104.git.gerald.elder-vass@cloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AD1kqb47YP3xYDSX" Content-Disposition: inline In-Reply-To: <766be642204043b779cef688ec0ca2f1d64313ad.1756740104.git.gerald.elder-vass@cloud.com> --AD1kqb47YP3xYDSX Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Sep 2025 19:41:03 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Gerald Elder-Vass Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , Kevin Lampis , "Daniel P. Smith" , Jan Beulich Subject: Re: [XEN PATCH] efi: Use Shim's LoadImage to verify the Dom0 kernel On Mon, Sep 01, 2025 at 03:33:54PM +0000, Gerald Elder-Vass wrote: > The existing Verify functionality of the Shim lock protocol is > deprecated and will be removed, instead we must use the LoadImage > interface to perform the verification. But IIUC shim lock protocol isn't removed yet, and some people may still rely on it. Better to try locating new protocol first, but keep using old one if new is not found. IMO removal of old protocol support should only follow removal it from shim and maybe even a bit longer, like wait for expiration of old shim versions (like revocation of old versions via SBAT, or maybe expiration of old MS 3rd party cert). >=20 > When the loading is successful we won't be using the newly loaded image > (as of yet) so we must then immediately unload the image to clean up. >=20 > Signed-off-by: Gerald Elder-Vass > Signed-off-by: Kevin Lampis > --- > xen/common/efi/boot.c | 39 +++++++++++++++++++++++++++------------ > 1 file changed, 27 insertions(+), 12 deletions(-) >=20 > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 453b1ba099cd..67e7220d8fa3 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -36,8 +36,8 @@ > =20 > #define SMBIOS3_TABLE_GUID \ > { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0x= e3, 0x94} } > -#define SHIM_LOCK_PROTOCOL_GUID \ > - { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x= 8b, 0x23} } > +#define SHIM_IMAGE_LOADER_GUID \ > + { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x= 55, 0xab} } > #define APPLE_PROPERTIES_PROTOCOL_GUID \ > { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x= 3a, 0xe0} } > #define EFI_SYSTEM_RESOURCE_TABLE_GUID \ > @@ -66,9 +66,12 @@ typedef EFI_STATUS > IN const VOID *Buffer, > IN UINT32 Size); > =20 > -typedef struct { > - EFI_SHIM_LOCK_VERIFY Verify; > -} EFI_SHIM_LOCK_PROTOCOL; > +typedef struct _SHIM_IMAGE_LOADER { > + EFI_IMAGE_LOAD LoadImage; > + EFI_IMAGE_START StartImage; > + EFI_EXIT Exit; > + EFI_IMAGE_UNLOAD UnloadImage; > +} SHIM_IMAGE_LOADER; > =20 > struct _EFI_APPLE_PROPERTIES; > =20 > @@ -1333,13 +1336,13 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE = ImageHandle, > EFI_SYSTEM_TABLE *SystemTable) > { > static EFI_GUID __initdata loaded_image_guid =3D LOADED_IMAGE_PROTOC= OL; > - static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_GUI= D; > EFI_LOADED_IMAGE *loaded_image; > EFI_STATUS status; > + EFI_HANDLE loaded_kernel; > unsigned int i; > CHAR16 *file_name, *cfg_file_name =3D NULL, *options =3D NULL; > UINTN gop_mode =3D ~0; > - EFI_SHIM_LOCK_PROTOCOL *shim_lock; > + SHIM_IMAGE_LOADER *shim_loader; > EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL; > union string section =3D { NULL }, name; > bool base_video =3D false; > @@ -1590,12 +1593,24 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE = ImageHandle, > * device tree through the efi_check_dt_boot function, in this stage > * 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 ) > + if ( kernel.ptr && !kernel_verified ) > + { > PrintErrMesg(L"Dom0 kernel image could not be verified", status); > + status =3D efi_bs->LocateProtocol(&((EFI_GUID) SHIM_IMAGE_LOADER_GUI= D), > + NULL, (void **)&shim_loader); Something is wrong with indentation / brackets here - it's all under "if ( kernel.ptr && !kernel_verified )". Rebase fail? > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"Error LocateProtocol IMAGE_LOADER", status); > + > + if ( kernel.ptr ) { > + status =3D shim_loader->LoadImage(false, ImageHandle, NULL, (voi= d *)kernel.ptr, kernel.size, &loaded_kernel); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"LoadImage failed", status); > + > + // LoadImage performs verification, now unload it to clean up > + status =3D shim_loader->UnloadImage(loaded_kernel); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"UnloadImage failed", status); > + } > =20 > efi_arch_edd(); > =20 > --=20 > 2.47.3 >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --AD1kqb47YP3xYDSX Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi12q8ACgkQ24/THMrX 1yyGnAf+NZXlQaOYGOSnYztOphBVH1BLcSCBZjL1tMCemWxulqFWazf18YIkmGM5 zI82vFkFsLbL1mHr2QiK12c2YKUBRQvZ+u++CmoG7J//HstR/Z8RiecTxGmv6jKV VdbRZf3SpbwZJsGxpI8PPuxgWjvMNoQEFba+Suj5aD4tDar5oV4FikVZJBNBQ9K6 p9lO4ZhMw73lHK36vt4Pz0sg4S2CV91Wy+I8j/S6bJ68Gd8zPYt2dWW2QxY3LfJs u98WgS36JZgc5SJFf4u5sTGY7/snPzj9nfCgtDCmscEYaFwtbTvPCra7rh6CkFyt 8vU7vqZ97HtT1igVxFelpFDvJECgNA== =3GyR -----END PGP SIGNATURE----- --AD1kqb47YP3xYDSX-- From xen-devel-bounces@lists.xenproject.org Mon Sep 01 18:01:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 18:01:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105285.1456209 (Exim 4.92) (envelope-from ) id 1ut8q0-0006EE-5i; Mon, 01 Sep 2025 18:01:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105285.1456209; Mon, 01 Sep 2025 18: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 1ut8q0-0006E7-2m; Mon, 01 Sep 2025 18:01:04 +0000 Received: by outflank-mailman (input) for mailman id 1105285; Mon, 01 Sep 2025 18: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 1ut8py-0006E1-H2 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 18:01:02 +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 9dc20593-875d-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 20:01:00 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by PAXPR03MB7684.eurprd03.prod.outlook.com (2603:10a6:102:204::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.25; Mon, 1 Sep 2025 18:00:57 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 18: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: 9dc20593-875d-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LIPw5WAOHEPR426Q+xSjHq44Qf53M1Km000ldjEaFsvUloZE+i0BMA0Fk3kbvzF8qRrCxeKQ/p5IVo4g702qnOwLxXTCcI5S0cnazdcSSOwHdWlShNAy4eyfXGOOToB7A+BHk7w67ZTsRybP0b/Byx7vroBwg4VzuTKZyc3N4sQ/DsezSy1ezjNY8YYrckahzSoMCVnWc9t5Rg8NWI0xB0L4qUlJGCH1XZnbM8PF0P/EoIHTzprj92Ec0JE7OMry+XpXgHsAkCg9bE30bJuZKtIWQ4RFPR+YKriqCjk+CnNQvkbEfLnQ0CaUZqB/CAM8TVLRUodiUF88/vZ+RuDz0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pOzJHDcpZqzXhutYzuL9w6HdOdaet1d2JKYO0+iRPi4=; b=DwU278zZTbPpFNxpgT6gTBFgLSrI1HvZPGWe1NfEpRFcNFASM2TE1+bUR+Drz6AcuORf75iu5kmnMfiAjHsC4C3R1MkuFPLoF2UhiXqxjZGLa9VIssB5XHUhbzKLLd0CjBeASkisZ5UQIoJ18VopD3oCQGTB/+JhLdsahcwM1UM+eQTFFB9hCgBMl3kYKXNZVKQigBjnswKoYhPAj8WOAHBPLHzd/LbwLzsbVjIztDaS7QO3X/bMhrLFADwo+lRDNI+v2+tZQX+uN9HcKtc0uvFgf45CiI0NUEzmSZlnRUFcho2knA39IFBAkQdsqXKV6EzFJFf9uQcoV49VuFwoRA== 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=pOzJHDcpZqzXhutYzuL9w6HdOdaet1d2JKYO0+iRPi4=; b=r/uHgWRVmGled/BhRceYkdyhODNQN8UIlKNedmbrz40E9+Jb7J2LoaJ4VAd0RqpJextsLOUeHZcOMjySmInsf4FSFev19NvDhMk7pvbRsh0X3f/+fBze782hWLO/DnaPvAIbniUvbKUiNezcwMPVZWGVKyzKSuL+UiqVBbBJUhQGCRaAgGPy3MjGoj2nOilQHeeoWM5t4VyN0aCOIGtfcbG+Z1PHIB8DRCtTijhWy0yFWop8J/PxdGPQGCg1kH+2P5rChcFEaNvdia4POl899uQm3bhNC+U9/A0pe09CmSb1Hr5piWDErMyGNNHkMkJ3dLTYKJdwg7PI4rA4m97bHA== From: Leonid Komarianskyi To: Oleksandr Tyshchenko , Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Thread-Topic: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Thread-Index: AQHcGP7gzxYtqJZFyUiPTlrb5XV2MbR87jaAgAG0hgA= Date: Mon, 1 Sep 2025 18:00:57 +0000 Message-ID: <0e9e5b72-2bf1-46a8-867d-8e6d306fe956@epam.com> References: <4b13dea924eabf1370d3f31030f3eef48371de06.1756481577.git.leonid_komarianskyi@epam.com> <87y0r1x3g2.fsf@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: GV2PR03MB8678:EE_|PAXPR03MB7684:EE_ x-ms-office365-filtering-correlation-id: 3249f2cd-e04f-40c5-d4a4-08dde981807e 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?THNhWlVvSDdyZjlTTkJFd1c4dEhURjVTelQ4eDg1Sys3NTluK3RUL0hNWVll?= =?utf-8?B?WXRsUzdSdlQzU1cxODQvUnE1N0FaTHVSRnBWRS82dUFYU3h5NWR0L25OV002?= =?utf-8?B?aWlxRmxPeTRiSmhKRTJzWkRpa3BUaklLVU85S3h6YzMwOTMwV1Fkb0RqR3BE?= =?utf-8?B?bEgrV1ZuM1o1eU9RcUp1SXhzTWVPd3Z4N3V1TGhOb0NOWTBnYStrazBYUml5?= =?utf-8?B?VVdjYlJMNmlvUWJhS29HR2tpQXRhMnl5bExmYmp6K1pSWnA3a2JHdDRJdzhP?= =?utf-8?B?UCtaalQvcEIwWkdzVmJDcjNRWTVXaytMd29vRVM3WHRFbXZDZzg0aks1Q3dk?= =?utf-8?B?K2dIMkxCTERJeVZ6UGl2UXl0bHg1VnZvd1lPNC8xbmpVSllqTHhYdEhWTEc4?= =?utf-8?B?a1BHeGY1ZGRieTZ4NFFQYU9LTVZQQTliWEJXTXFleXlNUG9ZUFZ2SXFjTEtN?= =?utf-8?B?aytwOXhkTEFudGZWT1N3eEw4N2dTYWlBd1lNQTYyU3Jxb3lzRGJnWEE0clFV?= =?utf-8?B?RlRvaDFMNUJJKzU5UTdCRnNpbVkwRklGV1ZTcHNmTDc3THhQZElvNHpVZTNX?= =?utf-8?B?NUpUWUJKRDdqM1ZTUHh4K2hYTmN2b1RHenFEMkgwRzdJU0Z4STZMQXZ2NE4w?= =?utf-8?B?TSs2TERhbHBITnEramMrdlI0ZzhxL1JkSHN5Qm15bmVvb3JaZ3BnazEvakwr?= =?utf-8?B?ZEZiak56d0MvMFZtTHNMdzd5U2RMOXI2ZFc2OHp0dEw0QVJuZHp3L2grbWpS?= =?utf-8?B?dWM3QllydVVSS3lwNHVmMmFPVnR3ME9lTlNDUFcyQnpoeE9SVFFCa0VmRDg1?= =?utf-8?B?QTVMSS9yZElTR2FoaGl4V3N6MDRkTHAwVDE4SWM5clVic1VnRFM1dENWWDZO?= =?utf-8?B?ZThHdFJtaVdYNGNoL1habmVMMDZ4dllBTjkrZlEvUzB4Y1pjQSt2MVpYUzVY?= =?utf-8?B?ckdwbVR2a0lNb1dqc2JpRG1uS1o3Z1FmaXZvKzRUNXpLQUsyQlk1UXdHdUky?= =?utf-8?B?MUtEYk82RCtSdjhtczJVQjl4ekNCTGMvMWxhY29YclFpUEVIK05yMVhzVXFM?= =?utf-8?B?dFMwc0ZKbHEzaXVyUXZ2UGlKeUFXUE9FNVpQL3pIcTZoOTVPeUpJaXVzYXhr?= =?utf-8?B?ejE4c1NNMlgybkhyL24wQlo4ZVBSZE1Id1hlaGJISzlqWThmL2NJQXNVWnRL?= =?utf-8?B?YkVCM3U3SitGUWhQbmlsbmVxSXQrS1B5U3V1cHdyS0wvWEdwRXpvWHJDUi9r?= =?utf-8?B?RlluZTJtRUc4MXpsalVSWVB6UlBWWnovWGt1UHdaaHVYL1l2RUR2TVh2ZDhZ?= =?utf-8?B?V0I5SDNlYSsxdFMvSHF1S2dhd0RTc0RsWFF6MnFzRW1YNjhlVU5kNEpWOE5C?= =?utf-8?B?ZXkrUTh5UERma0dhWkY0alJ4TnN5T1QwZU9ubmd0aHBkOWJDaFJBS3pLem5p?= =?utf-8?B?Ny94YmZpYjF2SEM2cGxhSEpxV1RsZWRXQitlQ1I2Qmc1YVUxOFJKbHR3Rjky?= =?utf-8?B?ZkxUdzhqQThlaEs5UkM2Y0JZWGhJdENTTnE0RHhFaURlUkxHR2ZSeGIzbERq?= =?utf-8?B?YStOUDdHUHg5b0lhVGx2MGtyZXRWeUNNU1A3NWFWelBWMFZMd2w4VUpLQ3lt?= =?utf-8?B?M3htK1BZUFpuTkJMcTdzdk8vQkpFWEhkcDRXUDJLdlkzVHByMytxMFJaSURs?= =?utf-8?B?ZVY0UlVaNHFSUThvN3JYaTc3eTJvdDhTRjZEa2lOYXMzVEU5M3MxNGV3UVQr?= =?utf-8?B?NjJ0bFM3YTU2MXdjanlBdnVvQkIxcWJkaURheWJGdHBraC9UOWdHSy8wV3Er?= =?utf-8?B?eEJGajJ4VmNackRMazB1L3Vuam1BYmZqUzk1RnJYQlVCRmUvTzdTSzQwUmFE?= =?utf-8?B?T01OSzYxNGJrVkx5TDRCazZVeFBjdVR2SGRVRUVSa2xvdUF6Z3czL2RXbzFs?= =?utf-8?B?U1JsU0x3allLOEJoUmZ2SzhuSzltSHV3UVNLOEdhUUpIYXV6ZUs1RFZCOTZO?= =?utf-8?B?Wk1rOVZLRjl3PT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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?KytMYWxQWVZ3Wk90S2hMWVlDM2F2aTUzWnJPMFAwb2pSem9yM1pSSkgvZXg2?= =?utf-8?B?dG1qaS8rVnRkRDJLWjFpMUJhdCtiRmplZUl2N2ZrRE8xZWp4ZTU2V3Rpb1N4?= =?utf-8?B?bDAwMXdJelkyT2RSQkxUOXZ0a0hKbmVzbVAvd3lzTzkxMzhSSHRpMzBHN0JH?= =?utf-8?B?eVo4M1dPR3Jwamw5elFSbzJhR2R0QVpQQytVaFhpZzR0dXgwR1l4Sy9GSGxG?= =?utf-8?B?TGlwTDFic0xETjhtTzd5VkRldkxwOHBBeUpMTnUzQ3pNOTFaaG83eGNoZ28w?= =?utf-8?B?cjBORUNWT0RjUnJyNm9Qa0xEcXArMUpFbVdHeWtBb3hzQmp1dHdJa1JCYjJq?= =?utf-8?B?c1NBNFZWR0NaR1pBd0ZhUjNkNlFqU1NKZ0VzZDhUY0gySm4vb1VueGgvUzZW?= =?utf-8?B?UlhGM0VucGpYTVVpYXlQbHRPTVNtbkxRS0FUK2NPNHFaU1hGWHUxZnBGNlN1?= =?utf-8?B?Rnp1TmRYRDZSNkFjTmhuTnVrWXpaZExIaWg1dU53RERiUk5FQ3VJVE9LQ0dn?= =?utf-8?B?cEc1ckwyaVdVRjdCanZMM002amlWQWNRYTRscjlpRHBZOEg4Y2ViRjMrbTlP?= =?utf-8?B?M0Yyd0tUTFpyRi9uZUs5dTdqelgxeXlsWXZ0OUNkUm1WYnI2Q21ySHMwckRZ?= =?utf-8?B?VmpERVZpYktZd3JlejlTQnVNdXVmTE53TDEvZkpGczJQTVNETThlYUVPUy9u?= =?utf-8?B?OVZyd3MzejFvRHlKZTRKeDRxSmhWTStFVnk0MURGVVRScTAyWklMRTZQZmtR?= =?utf-8?B?K3hZTGF6THFOeFlwd0dVTmNiMGQ0cWlmQzVBTFlBZGc2a3JQeTd1aHUwcmtq?= =?utf-8?B?M2Q2ckxOQjJSeTJOWDV3ek5sdlE5RlRxbzVlcEdKcGN3OVloeE55b1VCTVFT?= =?utf-8?B?aXdOb1BOUkFHMzhwOURsbWp0Si9BMEFxYjVESExvL0diL05GZlBKdXIyNnZa?= =?utf-8?B?dWQ2U1ZPbGhYT1Vab1JjSE1Ec01NZWlIUndlc1hxbW9XekF5MGtVUnZ3THBU?= =?utf-8?B?SXByNmZTWXBBbFFMOVVPOExUdGY1dmJOOGtqQkhGSmRWdlc0cTE5T1U5b25L?= =?utf-8?B?bCt3SWZPUXlJeHBQalR4aCtYS0lOWU5sSzJpM3ZrbTVJOEZOcTQyOHpqV3Qz?= =?utf-8?B?Qkt3YkRxbmFJcTlJZkdMUG84bHA3VHViYXE5SmFJdC9mY1BUZEhUbUFidTdu?= =?utf-8?B?RlM2VVh6N3dod2pZTm93TEVJMkJqRTBPWnB4VkxDd1V1d2pjYWhCblJpamdD?= =?utf-8?B?WWJoMkkxYnVpcEZVa1FxREpCYTFSb2o5YXNNaVNsNmdkWStKS2ZkNThmajFl?= =?utf-8?B?SnF2cStDNk1aRUdtL29tUzI5SU4zRkIxRUZOS0YrUjV3NUhaYkhVNzdVMkhv?= =?utf-8?B?eTA5bWJsQllqY0NBL2VvSTVLQjAyRDBVOU5GNzR4YzlMOFl4STBISmxQQSt0?= =?utf-8?B?bkNNNUFQRUdzMjFNd3ZValpEZ21RZmEyQUV4akkvdE1iZWwrMTBCcGE5UVRx?= =?utf-8?B?a3JUTmhBNlVnNU85SjhzcGdadUhtNW1qTjlGRHc1Z0xXVUpObmtsb1BEYjN5?= =?utf-8?B?NWNBWnQ2SDJwTmVBU29SYy9Oc0tMZTR4cC90dTlrZGxDUDIraTdueVFRc1pL?= =?utf-8?B?MG91dTE1ZjlmdWVDT1FTV0RYK3c3R1lxQ2tHcG9OdUxsTmYyeWJvV2d0QVEy?= =?utf-8?B?TzZocGxXdGFLcnZKeTQ2bWEyZ0NsbEhoNDBvSXZvbXhIVm8ybEZyYmdDSUZQ?= =?utf-8?B?WXI0M0FxQ25PelY3L1g2SjRlSnRXNXNHWEtBeEFid2tnZWptQ2FCcy8xRzBF?= =?utf-8?B?MHQ2VU9obmcrV3o1WllJWitPTHd0cFZ3a1ZXYUxWeUF0eG1CTXJOeksvbE5W?= =?utf-8?B?Qi91M3BxR1dteDBjWW9LSGMzL0Z6eDZ0eFFyZGc4aExiZHBzU0ZrYVkwa0sv?= =?utf-8?B?bk1adUV1RUc1SGt4b0tkMmw1czFrVjZtOTR5NzM5WnZDaGFKeVVDbFIwcXZ1?= =?utf-8?B?bGxzR3B4M0VsK1hVTE1nd2VoN3kxNWg1dTRNWTRDS0RVRG9XUDhmdHBxdmdT?= =?utf-8?B?VFFVaUlmZTRwSVdaemxwaHYxeDF0Q1NxaTNZVkg3MWxNMU8vMTdZN3dWUzZW?= =?utf-8?B?ZTdoT3IyZ0QzNnI5OVN4blgxRzkzeWkxeWhCb1FZWmtMWE1JZkFVU0luaGRa?= =?utf-8?Q?+HKIurj+XOE4jeDB1jwB+J0=3D?= 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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3249f2cd-e04f-40c5-d4a4-08dde981807e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 18:00:57.2202 (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: z9dQ4ZAx/jjr3jRdHH2G/0GEJwJhK5nWViat3P+06rvl4jaJUyaFGw1yMUs5nIi1TVj1M1u+kmqFR0wOmSmVC7RolyvCBJidMrPR9FaT7r8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB7684 SGVsbG8gT2xla3NhbmRyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAzMS4w OC4yNSAxODo1OCwgT2xla3NhbmRyIFR5c2hjaGVua28gd3JvdGU6DQo+IA0KPiANCj4gT24gMjku MDguMjUgMjM6NDUsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPiANCj4gSGVsbG8gTGVvbmlk LCBWb2xvZHlteXINCj4gDQo+Pg0KPj4gSGkgTGVvbmlkLA0KPj4NCj4+IExlb25pZCBLb21hcmlh bnNreWkgPExlb25pZF9Lb21hcmlhbnNreWlAZXBhbS5jb20+IHdyaXRlczoNCj4+DQo+Pj4gVGhp cyBjaGFuZ2UgaW50cm9kdWNlcyByZXNvdXJjZSBtYW5hZ2VtZW50IGluIHRoZSBWR0lDIHRvIGhh bmRsZQ0KPj4+IGV4dGVuZGVkIFNQSXMgaW50cm9kdWNlZCBpbiBHSUN2My4xLiBUaGUgcGVuZGlu Z19pcnFzIGFuZA0KPj4+IGFsbG9jYXRlZF9pcnFzIGFycmF5cyBhcmUgcmVzaXplZCB0byBzdXBw b3J0IHRoZSByZXF1aXJlZA0KPj4+IG51bWJlciBvZiBlU1BJcywgYmFzZWQgb24gd2hhdCBpcyBz dXBwb3J0ZWQgYnkgdGhlIGhhcmR3YXJlIGFuZA0KPj4+IHJlcXVlc3RlZCBieSB0aGUgZ3Vlc3Qu IEEgbmV3IGZpZWxkLCBleHRfc2hhcmVkX2lycXMsIGlzIGFkZGVkDQo+Pj4gdG8gdGhlIFZHSUMg c3RydWN0dXJlIHRvIHN0b3JlIGluZm9ybWF0aW9uIGFib3V0IGVTUElzLCBzaW1pbGFyDQo+Pj4g dG8gaG93IHNoYXJlZF9pcnFzIGlzIHVzZWQgZm9yIHJlZ3VsYXIgU1BJcy4NCj4+Pg0KPj4+IFNp bmNlIHRoZSBlU1BJIHJhbmdlIHN0YXJ0cyBhdCBJTlRJRCA0MDk2IGFuZCBJTlRJRHMgYmV0d2Vl biAxMDI1DQo+Pj4gYW5kIDQwOTUgYXJlIHJlc2VydmVkLCBoZWxwZXIgbWFjcm9zIGFyZSBpbnRy b2R1Y2VkIHRvIHNpbXBsaWZ5IHRoZQ0KPj4+IHRyYW5zZm9ybWF0aW9uIG9mIGluZGljZXMgYW5k IHRvIGVuYWJsZSBlYXNpZXIgYWNjZXNzIHRvIGVTUEktc3BlY2lmaWMNCj4+PiByZXNvdXJjZXMu IFRoZXNlIGNoYW5nZXMgcHJlcGFyZSB0aGUgVkdJQyBmb3IgcHJvY2Vzc2luZyBlU1BJcyBhcw0K Pj4+IHJlcXVpcmVkIGJ5IGZ1dHVyZSBmdW5jdGlvbmFsaXR5Lg0KPj4+DQo+Pj4gVGhlIGluaXRp YWxpemF0aW9uIGFuZCBkZWluaXRpYWxpemF0aW9uIHBhdGhzIGZvciB2Z2ljIGhhdmUgYmVlbiB1 cGRhdGVkDQo+Pj4gdG8gYWxsb2NhdGUgYW5kIGZyZWUgdGhlc2UgcmVzb3VyY2VzIGFwcHJvcHJp YXRlbHkuIEFkZGl0aW9uYWxseSwNCj4+PiB1cGRhdGVkIGhhbmRsaW5nIG9mIElOVElEcyBncmVh dGVyIHRoYW4gMTAyNCwgcGFzc2VkIGZyb20gdGhlIHRvb2xzdGFjaw0KPj4+IGR1cmluZyBkb21h aW4gY3JlYXRpb24sIGFuZCB2ZXJpZmljYXRpb24gbG9naWMgZW5zdXJlcyBvbmx5IHZhbGlkIFNQ SSBvcg0KPj4+IGVTUEkgSU5USURzIGFyZSB1c2VkLg0KPj4+DQo+Pj4gVGhlIGV4aXN0aW5nIFNQ SSBiZWhhdmlvciByZW1haW5zIHVuYWZmZWN0ZWQgd2hlbiBndWVzdHMgZG8gbm90IHJlcXVlc3QN Cj4+PiBlU1BJcywgR0lDIGhhcmR3YXJlIGRvZXMgbm90IHN1cHBvcnQgdGhlbSwgb3IgdGhlIENP TkZJR19HSUNWM19FU1BJDQo+Pj4gb3B0aW9uIGlzIGRpc2FibGVkLg0KPj4+DQo+Pj4gU2lnbmVk LW9mZi1ieTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNv bT4NCj4+Pg0KPj4+IC0tLQ0KPj4+IENoYW5nZXMgaW4gVjU6DQo+Pj4gLSByZW1vdmVkIHRoZSBo YXNfZXNwaSBmaWVsZCBiZWNhdXNlIGl0IGNhbiBiZSBkZXRlcm1pbmVkIGJ5IGNoZWNraW5nDQo+ Pj4gwqDCoCB3aGV0aGVyIGRvbWFpbi0+YXJjaC52Z2ljLm5yX2VzcGlzIGlzIHplcm8gb3Igbm90 DQo+Pj4gLSBzaW5jZSB2Z2ljX2V4dF9yYW5rX29mZnNldCBpcyBub3QgdXNlZCBpbiB0aGlzIHBh dGNoLCBpdCBoYXMgYmVlbg0KPj4+IMKgwqAgbW92ZWQgdG8gdGhlIGFwcHJvcHJpYXRlIHBhdGNo IGluIHRoZSBwYXRjaCBzZXJpZXMsIHdoaWNoIGltcGxlbWVudHMNCj4+PiDCoMKgIHZnaWMgZVNQ SSByZWdpc3RlcnMgZW11bGF0aW9uIGFuZCByZXF1aXJlcyB0aGlzIGZ1bmN0aW9uDQo+Pj4gLSBy ZW1vdmVkIGlmZGVmcyBmb3IgZVNQSS1zcGVjaWZpYyBtYWNyb3MgdG8gcmVkdWNlIHRoZSBudW1i ZXIgb2YgaWZkZWZzDQo+Pj4gwqDCoCBhbmQgY29kZSBkdXBsaWNhdGlvbiBpbiBmdXJ0aGVyIGNo YW5nZXMNCj4+PiAtIGZpeGVkIG1pbm9yIG5pdDogdXNlZCAlcGQgZm9yIHByaW50aW5nIGRvbWFp biB3aXRoIGl0cyBJRA0KPiANCj4gQExlb25pZCwgdGhhbmtzIGZvciBvcHRpbWl6aW5nIHRoZSBz ZXJpZXMsIG5vdyBpdCBsb29rcyBtdWNoIGJldHRlciAodGhlIA0KPiBudW1iZXIgb2YgI2lmZGVm LXMgaXMgcmVkdWNlZCwgY29kZSBpcyByZXVzZWQpLg0KPiANCj4NCg0KSSBhbSBkb2luZyBteSBi ZXN0LCBhbmQgeW91IGFuZCB0aGUgb3RoZXIgcmV2aWV3ZXJzIGFyZSBoZWxwaW5nIG1lIA0KaW1w cm92ZSB0aGUgY29kZS4gVGhhbmsgeW91IGZvciB0aGF0IQ0KDQo+Pj4NCj4+PiBDaGFuZ2VzIGlu IFY0Og0KPj4+IC0gYWRkZWQgaGFzX2VzcGkgZmllbGQgdG8gc2ltcGxpZnkgZGV0ZXJtaW5pbmcg d2hldGhlciBhIGRvbWFpbiBpcyBhYmxlDQo+Pj4gwqDCoCB0byBvcGVyYXRlIHdpdGggZVNQSQ0K Pj4+IC0gZml4ZWQgZm9ybWF0dGluZyBpc3N1ZXMgYW5kIG1pc3NwZWxsaW5ncw0KPj4+DQo+Pj4g Q2hhbmdlcyBpbiBWMzoNCj4+PiAtIGZpeGVkIGZvcm1hdHRpbmcgZm9yIGxpbmVzIHdpdGggbW9y ZSB0aGFuIDgwIHN5bWJvbHMNCj4+PiAtIGludHJvZHVjZWQgaGVscGVyIGZ1bmN0aW9ucyB0byBi ZSBhYmxlIHRvIHVzZSBzdHVicyBpbiBjYXNlIG9mDQo+Pj4gwqDCoCBDT05GSUdfR0lDVjNfRVNQ SSBkaXNhYmxlZCwgYW5kIGFzIGEgcmVzdWx0LCByZWR1Y2UgdGhlIG51bWJlciBvZg0KPj4+IMKg wqAgI2lmZGVmcw0KPj4+IC0gZml4ZWQgY2hlY2tzIGZvciBucl9zcGlzIGluIGRvbWFpbl92Z2lj X2luaXQNCj4+PiAtIHVwZGF0ZWQgY29tbWVudCBhYm91dCBucl9zcGlzIGFkanVzdG1lbnRzIHdp dGggZG9tMGxlc3MgbWVudGlvbg0KPj4+IC0gbW92ZWQgY29tbWVudCB3aXRoIGFkZGl0aW9uYWwg ZXhwbGFuYXRpb25zIGJlZm9yZSBjaGVja3MNCj4+PiAtIHVzZWQgdW5zaWduZWQgaW50IGZvciBp bmRleGVzIHNpbmNlIHRoZXkgY2Fubm90IGJlIG5lZ2F0aXZlDQo+Pj4gLSByZW1vdmVkIHVubmVj ZXNzYXJ5IHBhcmVudGhlc2VzDQo+Pj4gLSBtb3ZlIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0IHRvIHRo ZSBiZWxvdyBpZmRlZiBndWFyZCwgdG8gcmVkdWNlIHRoZQ0KPj4+IMKgwqAgbnVtYmVyIG9mIGlm ZGVmcw0KPj4+DQo+Pj4gQ2hhbmdlcyBpbiBWMjoNCj4+PiAtIGNoYW5nZSBpc19lc3BpX3Jhbmsg dG8gaXNfdmFsaWRfZXNwaV9yYW5rIHRvIHZlcmlmeSB3aGV0aGVyIHRoZSBhcnJheQ0KPj4+IMKg wqAgZWxlbWVudCBleHRfc2hhcmVkX2lycXMgZXhpc3RzLiBUaGUgcHJldmlvdXMgdmVyc2lvbiwg aXNfZXNwaV9yYW5rLA0KPj4+IMKgwqAgb25seSBjaGVja2VkIGlmIHRoZSByYW5rIGluZGV4IHdh cyBsZXNzIHRoYW4gdGhlIG1heGltdW0gcG9zc2libGUgDQo+Pj4gZVNQSQ0KPj4+IMKgwqAgcmFu ayBpbmRleCwgYnV0IHRoaXMgY291bGQgcG90ZW50aWFsbHkgcmVzdWx0IGluIGFjY2Vzc2luZyBh DQo+Pj4gwqDCoCBub24tZXhpc3RpbmcgYXJyYXkgZWxlbWVudC4gVG8gYWRkcmVzcyB0aGlzLCBp c192YWxpZF9lc3BpX3Jhbmsgd2FzDQo+Pj4gwqDCoCBpbnRyb2R1Y2VkLCB3aGljaCBlbnN1cmVz IHRoYXQgdGhlIHJlcXVpcmVkIGVTUEkgcmFuayBleGlzdHMNCj4+PiAtIG1vdmUgZ2ljX251bWJl cl9lc3BpcyB0bw0KPj4+IMKgwqAgeGVuL2FybTogZ2ljdjM6IGltcGxlbWVudCBoYW5kbGluZyBv ZiBHSUN2My4xIGVTUEkNCj4+PiAtIHVwZGF0ZSB2Z2ljX2lzX3ZhbGlkX2lycSBjaGVja3MgdG8g YWxsb3cgb3BlcmF0aW5nIHdpdGggZVNQSXMNCj4+PiAtIHJlbW92ZSByZWR1bmRhbnQgbmV3bGlu ZSBpbiB2Z2ljX2FsbG9jYXRlX3ZpcnENCj4+PiAtLS0NCj4+PiDCoCB4ZW4vYXJjaC9hcm0vaW5j bHVkZS9hc20vdmdpYy5oIHzCoCAxMiArKw0KPj4+IMKgIHhlbi9hcmNoL2FybS92Z2ljLmPCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfCAxOTkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr Ky0NCj4+PiDCoCAyIGZpbGVzIGNoYW5nZWQsIDIwOCBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9u cygtKQ0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2lj LmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS8gDQo+Pj4gYXNtL3ZnaWMuaA0KPj4+IGluZGV4IDNl N2NiYmIxOTYuLjkxMmQ1Yjc2OTQgMTAwNjQ0DQo+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1 ZGUvYXNtL3ZnaWMuaA0KPj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgN Cj4+PiBAQCAtMTQ2LDYgKzE0NiwxMCBAQCBzdHJ1Y3QgdmdpY19kaXN0IHsNCj4+PiDCoMKgwqDC oMKgIGludCBucl9zcGlzOyAvKiBOdW1iZXIgb2YgU1BJcyAqLw0KPj4+IMKgwqDCoMKgwqAgdW5z aWduZWQgbG9uZyAqYWxsb2NhdGVkX2lycXM7IC8qIGJpdG1hcCBvZiBJUlFzIGFsbG9jYXRlZCAq Lw0KPj4+IMKgwqDCoMKgwqAgc3RydWN0IHZnaWNfaXJxX3JhbmsgKnNoYXJlZF9pcnFzOw0KPj4+ ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+PiArwqDCoMKgIHN0cnVjdCB2Z2ljX2lycV9y YW5rICpleHRfc2hhcmVkX2lycXM7DQo+Pj4gK8KgwqDCoCBpbnQgbnJfZXNwaXM7IC8qIE51bWJl ciBvZiBleHRlbmRlZCBTUElzICovDQo+IA0KPiBJdCBzZWVtcyB5b3UgaGF2ZSBhZ3JlZWQgKFY0 KSB0aGF0IG5yX2VzcGlzIGNvdWxkIG5vdCBiZSBuZWdhdGl2ZS4NCj4gDQoNCkkgYXBwb2xvZ2l6 ZSBmb3IgdGhhdCwgSSBtaXNzZWQgdGhpcyBjaGFuZ2UuIEkgd2lsbCBmaXggaXQgaW4gVjYuDQoN Cj4+PiArI2VuZGlmDQo+Pj4gwqDCoMKgwqDCoCAvKg0KPj4+IMKgwqDCoMKgwqDCoCAqIFNQSXMg YXJlIGRvbWFpbiBnbG9iYWwsIFNHSXMgYW5kIFBQSXMgYXJlIHBlci1WQ1BVIGFuZCANCj4+PiBz dG9yZWQgaW4NCj4+PiDCoMKgwqDCoMKgwqAgKiBzdHJ1Y3QgYXJjaF92Y3B1Lg0KPj4+IEBAIC0y NDMsNiArMjQ3LDE0IEBAIHN0cnVjdCB2Z2ljX29wcyB7DQo+Pj4gwqAgLyogTnVtYmVyIG9mIHJh bmtzIG9mIGludGVycnVwdCByZWdpc3RlcnMgZm9yIGEgZG9tYWluICovDQo+Pj4gwqAgI2RlZmlu ZSBET01BSU5fTlJfUkFOS1MoZCkgKCgoZCktPmFyY2gudmdpYy5ucl9zcGlzKzMxKS8zMikNCj4+ PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+Pj4gKyNkZWZpbmUgRE9NQUlOX05SX0VYVF9S QU5LUyhkKSAoKChkKS0+YXJjaC52Z2ljLm5yX2VzcGlzKzMxKS8zMikNCj4+PiArI2VuZGlmDQo+ Pj4gKyNkZWZpbmUgRVhUX1JBTktfTUlOIChFU1BJX0JBU0VfSU5USUQvMzIpDQo+Pj4gKyNkZWZp bmUgRVhUX1JBTktfTUFYICgoRVNQSV9NQVhfSU5USUQrMzEpLzMyKQ0KPj4+ICsjZGVmaW5lIEVY VF9SQU5LX05VTTJJRFgobnVtKSAoKG51bSktRVhUX1JBTktfTUlOKQ0KPj4+ICsjZGVmaW5lIEVY VF9SQU5LX0lEWDJOVU0oaWR4KSAoKGlkeCkrRVhUX1JBTktfTUlOKQ0KPj4+ICsNCj4+PiDCoCAj ZGVmaW5lIHZnaWNfbG9jayh2KcKgwqAgc3Bpbl9sb2NrX2lycSgmKHYpLT5kb21haW4tPmFyY2gu dmdpYy5sb2NrKQ0KPj4+IMKgICNkZWZpbmUgdmdpY191bmxvY2sodikgc3Bpbl91bmxvY2tfaXJx KCYodiktPmRvbWFpbi0+YXJjaC52Z2ljLmxvY2spDQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo L2FybS92Z2ljLmMgYi94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+Pj4gaW5kZXggMmJiZjRkOTlhYS4u YzliOTUyOGM2NiAxMDA2NDQNCj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+Pj4gKysr IGIveGVuL2FyY2gvYXJtL3ZnaWMuYw0KPj4+IEBAIC0yNyw5ICsyNyw4MiBAQA0KPj4+IMKgIGJv b2wgdmdpY19pc192YWxpZF9saW5lKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCB2aXJx KQ0KPj4+IMKgIHsNCj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+Pj4gK8KgwqDCoCBp ZiAoIHZpcnEgPj0gRVNQSV9CQVNFX0lOVElEICYmDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqAgdmly cSA8IEVTUElfSURYMklOVElEKGQtPmFyY2gudmdpYy5ucl9lc3BpcykgKQ0KPj4+ICvCoMKgwqDC oMKgwqDCoCByZXR1cm4gdHJ1ZTsNCj4+PiArI2VuZGlmDQo+Pj4gKw0KPj4+IMKgwqDCoMKgwqAg cmV0dXJuIHZpcnEgPCB2Z2ljX251bV9pcnFzKGQpOw0KPj4+IMKgIH0NCj4+PiArI2lmZGVmIENP TkZJR19HSUNWM19FU1BJDQo+Pj4gKy8qDQo+Pj4gKyAqIFNpbmNlIGVTUEkgaW5kZXhlcyBzdGFy dCBmcm9tIDQwOTYgYW5kIG51bWJlcnMgZnJvbSAxMDI0IHRvDQo+Pj4gKyAqIDQwOTUgYXJlIGZv cmJpZGRlbiwgd2UgbmVlZCB0byBjaGVjayBib3RoIGxvd2VyIGFuZCB1cHBlcg0KPj4+ICsgKiBs aW1pdHMgZm9yIHJhbmtzLg0KPj4+ICsgKi8NCj4+PiArc3RhdGljIGlubGluZSBib29sIGlzX3Zh bGlkX2VzcGlfcmFuayhzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgDQo+Pj4gcmFuaykN Cj4+PiArew0KPj4+ICvCoMKgwqAgcmV0dXJuIHJhbmsgPj0gRVhUX1JBTktfTUlOICYmDQo+Pj4g K8KgwqDCoMKgwqDCoMKgwqDCoMKgIEVYVF9SQU5LX05VTTJJRFgocmFuaykgPCBET01BSU5fTlJf RVhUX1JBTktTKGQpOw0KPj4+ICt9DQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW5saW5lIHN0cnVjdCB2 Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9lc3BpX3Jhbmsoc3RydWN0IHZjcHUgKnYsDQo+Pj4gK8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25l ZCBpbnQgDQo+Pj4gcmFuaykNCj4+PiArew0KPj4+ICvCoMKgwqAgcmV0dXJuICZ2LT5kb21haW4t IA0KPj4+ID5hcmNoLnZnaWMuZXh0X3NoYXJlZF9pcnFzW0VYVF9SQU5LX05VTTJJRFgocmFuayld Ow0KPj4+ICt9DQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW5saW5lIGJvb2wgdmdpY19yZXNlcnZlX2Vz cGlfdmlycShzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCANCj4+PiBpbnQgdmlycSkNCj4+PiAr ew0KPj4+ICvCoMKgwqAgcmV0dXJuICF0ZXN0X2FuZF9zZXRfYml0KEVTUElfSU5USUQySURYKHZp cnEpICsgdmdpY19udW1faXJxcyhkKSwNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFz KTsNCj4+PiArfQ0KPj4+ICsNCj4+PiArc3RhdGljIHZvaWQgYXJjaF9tb3ZlX2VzcGlzKHN0cnVj dCB2Y3B1ICp2KQ0KPj4NCj4+IEkgZG9uJ3QgbmVlZCB5b3UgbmVlZCBhIGNvcHkgb2YgYXJjaF9t b3ZlX2lycXMoKS4gU2UgYmVsb3cgZm9yIG1vcmUgaW5mby4NCj4+DQo+Pj4gK3sNCj4+PiArwqDC oMKgIGNvbnN0IGNwdW1hc2tfdCAqY3B1X21hc2sgPSBjcHVtYXNrX29mKHYtPnByb2Nlc3Nvcik7 DQo+Pj4gK8KgwqDCoCBzdHJ1Y3QgZG9tYWluICpkID0gdi0+ZG9tYWluOw0KPj4+ICvCoMKgwqAg c3RydWN0IHBlbmRpbmdfaXJxICpwOw0KPj4+ICvCoMKgwqAgc3RydWN0IHZjcHUgKnZfdGFyZ2V0 Ow0KPj4+ICvCoMKgwqAgdW5zaWduZWQgaW50IGk7DQo+Pj4gKw0KPj4+ICvCoMKgwqAgZm9yICgg aSA9IEVTUElfQkFTRV9JTlRJRDsNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgIGkgPCBFWFRfUkFO S19JRFgyTlVNKGQtPmFyY2gudmdpYy5ucl9lc3Bpcyk7IGkrKyApDQo+Pj4gK8KgwqDCoCB7DQo+ Pj4gK8KgwqDCoMKgwqDCoMKgIHZfdGFyZ2V0ID0gdmdpY19nZXRfdGFyZ2V0X3ZjcHUodiwgaSk7 DQo+Pj4gK8KgwqDCoMKgwqDCoMKgIHAgPSBpcnFfdG9fcGVuZGluZyh2X3RhcmdldCwgaSk7DQo+ Pj4gKw0KPj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIHZfdGFyZ2V0ID09IHYgJiYgIXRlc3RfYml0 KEdJQ19JUlFfR1VFU1RfTUlHUkFUSU5HLCAmcC0gDQo+Pj4gPnN0YXR1cykgKQ0KPj4+ICvCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGlycV9zZXRfYWZmaW5pdHkocC0+ZGVzYywgY3B1X21hc2spOw0K Pj4+ICvCoMKgwqAgfQ0KPj4+ICt9DQo+Pj4gKyNlbHNlDQo+Pj4gK3N0YXRpYyBpbmxpbmUgYm9v bCBpc192YWxpZF9lc3BpX3Jhbmsoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IA0KPj4+ IHJhbmspDQo+Pj4gK3sNCj4+PiArwqDCoMKgIHJldHVybiBmYWxzZTsNCj4+PiArfQ0KPj4+ICsN Cj4+PiArLyoNCj4+PiArICogVGhpcyBmdW5jdGlvbiBpcyBzdHViIGFuZCB3aWxsIG5vdCBiZSBj YWxsZWQgaWYgQ09ORklHX0dJQ1YzX0VTUEk9biwNCj4+PiArICogYmVjYXVzZSBpbiB0aGlzIGNh c2UsIGlzX3ZhbGlkX2VzcGlfcmFuayB3aWxsIGFsd2F5cyByZXR1cm4gZmFsc2UuDQo+Pj4gKyAq Lw0KPj4+ICtzdGF0aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9lc3Bp X3Jhbmsoc3RydWN0IHZjcHUgKnYsDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgDQo+Pj4gcmFuaykNCj4+PiArew0K Pj4+ICvCoMKgwqAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7DQo+Pj4gK8KgwqDCoCByZXR1cm4gTlVM TDsNCj4+PiArfQ0KPj4+ICsNCj4+PiArc3RhdGljIGlubGluZSBib29sIHZnaWNfcmVzZXJ2ZV9l c3BpX3ZpcnEoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgDQo+Pj4gaW50IHZpcnEpDQo+Pj4g K3sNCj4+PiArwqDCoMKgIHJldHVybiBmYWxzZTsNCj4+PiArfQ0KPj4+ICsNCj4+PiArc3RhdGlj IHZvaWQgYXJjaF9tb3ZlX2VzcGlzKHN0cnVjdCB2Y3B1ICp2KSB7IH0NCj4+PiArI2VuZGlmDQo+ Pj4gKw0KPj4+IMKgIHN0YXRpYyBpbmxpbmUgc3RydWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfZ2V0 X3Jhbmsoc3RydWN0IHZjcHUgKnYsDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCByYW5rKQ0KPj4+IMKgIHsNCj4+PiBAQCAtMzcs NiArMTEwLDggQEAgc3RhdGljIGlubGluZSBzdHJ1Y3QgdmdpY19pcnFfcmFuayANCj4+PiAqdmdp Y19nZXRfcmFuayhzdHJ1Y3QgdmNwdSAqdiwNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJu IHYtPmFyY2gudmdpYy5wcml2YXRlX2lycXM7DQo+Pj4gwqDCoMKgwqDCoCBlbHNlIGlmICggcmFu ayA8PSBET01BSU5fTlJfUkFOS1Modi0+ZG9tYWluKSApDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKg IHJldHVybiAmdi0+ZG9tYWluLT5hcmNoLnZnaWMuc2hhcmVkX2lycXNbcmFuayAtIDFdOw0KPj4+ ICvCoMKgwqAgZWxzZSBpZiAoIGlzX3ZhbGlkX2VzcGlfcmFuayh2LT5kb21haW4sIHJhbmspICkN Cj4+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIHZnaWNfZ2V0X2VzcGlfcmFuayh2LCByYW5rKTsN Cj4+PiDCoMKgwqDCoMKgIGVsc2UNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIE5VTEw7 DQo+Pj4gwqAgfQ0KPj4+IEBAIC0xMTcsNiArMTkyLDYyIEBAIGludCBkb21haW5fdmdpY19yZWdp c3RlcihzdHJ1Y3QgZG9tYWluICpkLCANCj4+PiB1bnNpZ25lZCBpbnQgKm1taW9fY291bnQpDQo+ Pj4gwqDCoMKgwqDCoCByZXR1cm4gMDsNCj4+PiDCoCB9DQo+Pj4gKyNpZmRlZiBDT05GSUdfR0lD VjNfRVNQSQ0KPj4+ICtzdGF0aWMgdW5zaWduZWQgaW50IHZnaWNfbnVtX3NwaV9saW5lcyhzdHJ1 Y3QgZG9tYWluICpkKQ0KPj4+ICt7DQo+Pj4gK8KgwqDCoCByZXR1cm4gZC0+YXJjaC52Z2ljLm5y X3NwaXMgKyBkLT5hcmNoLnZnaWMubnJfZXNwaXM7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRp YyBpbnQgaW5pdF92Z2ljX2VzcGkoc3RydWN0IGRvbWFpbiAqZCkNCj4+PiArew0KPj4+ICvCoMKg wqAgdW5zaWduZWQgaW50IGksIGlkeDsNCj4+PiArDQo+Pj4gK8KgwqDCoCBpZiAoIGQtPmFyY2gu dmdpYy5ucl9lc3BpcyA9PSAwICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIDA7DQo+Pj4g Kw0KPj4+ICvCoMKgwqAgZC0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxcyA9DQo+Pj4gK8KgwqDC oMKgwqDCoMKgIHh6YWxsb2NfYXJyYXkoc3RydWN0IHZnaWNfaXJxX3JhbmssIERPTUFJTl9OUl9F WFRfUkFOS1MoZCkpOw0KPj4+ICvCoMKgwqAgaWYgKCBkLT5hcmNoLnZnaWMuZXh0X3NoYXJlZF9p cnFzID09IE5VTEwgKQ0KPj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVOT01FTTsNCj4+PiAr DQo+Pj4gK8KgwqDCoCBmb3IgKCBpID0gZC0+YXJjaC52Z2ljLm5yX3NwaXMsIGlkeCA9IDA7DQo+ Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoCBpIDwgdmdpY19udW1fc3BpX2xpbmVzKGQpOyBpKyssIGlk eCsrICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgdmdpY19pbml0X3BlbmRpbmdfaXJxKCZkLT5hcmNo LnZnaWMucGVuZGluZ19pcnFzW2ldLA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEVTUElfSURYMklOVElEKGlkeCkpOw0KPj4+ ICsNCj4+PiArwqDCoMKgIGZvciAoIGkgPSAwOyBpIDwgRE9NQUlOX05SX0VYVF9SQU5LUyhkKTsg aSsrICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgdmdpY19yYW5rX2luaXQoJmQtPmFyY2gudmdpYy5l eHRfc2hhcmVkX2lycXNbaV0sIGksIDApOw0KPj4+ICsNCj4+PiArwqDCoMKgIHJldHVybiAwOw0K Pj4+ICt9DQo+Pj4gKw0KPj4+ICtzdHJ1Y3QgcGVuZGluZ19pcnEgKmVzcGlfdG9fcGVuZGluZyhz dHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4NCj4+IEkga25vdyB0aGF0IEkg c2hvdWxkIG1hZGUgdGhpcyBvYnNlcnZhdGlvbiBpbiBwcmV2aW91cyB2ZXJzaW9uLCBidXQgSQ0K Pj4gZGlkbid0LCBzb3JyeSBmb3IgdGhhdC4gQW55d2F5cywgSSBkb24ndCB0aGluayB0aGF0IHRo aXMgaXMgYSBnb29kIGlkZWENCj4+IHRvIGludHJvZHVjZSB0aGlzIGZ1bmN0aW9uIGFuZCB2Z2lj X3Jlc2VydmVfZXNwaV92aXJxKCksIGFzIHdlbGwgYXMNCj4+IGFyY2hfbW92ZV9lc3BpcygpLCBh Y3R1YWxseSwgYmVjYXVzZSBpbiBlYWNoIGNhc2UgdGhpcyBpcyBhIGNvZGUNCj4+IGR1cGxpY2F0 aW9uLCB3aGljaCBpcyBub3QgZ29vZC4NCj4+DQo+PiBJIHRoaW5rIHRoYXQgaW5zdGVhZCB5b3Ug bmVlZCB0byBpbnRyb2R1Y2UgYSBwYWlyIG9mIGhlbHBlcnMgdGhhdCB3aWxsDQo+PiBtYXAgYW55 IChlKVNQSSBudW1iZXIgdG8gcGVuZGluZ19pcnFbXS9hbGxvY2F0ZV9pcnFzIGluZGV4IGFuZCBi YWNrLg0KPj4NCj4+IHNvbWV0aGluayBsaWtlDQo+Pg0KPj4gc3RhdGljIGlubGluZSB1bnNpZ25l ZCB2aXJxX3RvX2luZGV4KGludCB2aXJxKQ0KPj4gew0KPj4gwqDCoMKgIGlmIChpc19lc3BpKHZp cnEpKQ0KPj4gwqDCoMKgwqDCoMKgwqAgcmV0dXJuIEVTUElfSU5USUQySURYKGlycSkgKyBkLT5h cmNoLnZnaWMubnJfc3BpczsNCj4+IMKgwqDCoCByZXR1cm4gdmlycTsNCj4+IH0NCj4+DQo+PiBT ZWUgYmVsb3cgZm9yIGV4YW1wbGVzLg0KPj4NCj4+PiArew0KPj4+ICvCoMKgwqAgaXJxID0gRVNQ SV9JTlRJRDJJRFgoaXJxKSArIGQtPmFyY2gudmdpYy5ucl9zcGlzOw0KPj4+ICvCoMKgwqAgcmV0 dXJuICZkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFzW2lycV07DQo+Pj4gK30NCj4+PiArI2Vsc2UN Cj4+PiArc3RhdGljIHVuc2lnbmVkIGludCBpbml0X3ZnaWNfZXNwaShzdHJ1Y3QgZG9tYWluICpk KQ0KPj4+ICt7DQo+Pj4gK8KgwqDCoCByZXR1cm4gMDsNCj4+PiArfQ0KPj4+ICsNCj4+PiArc3Rh dGljIHVuc2lnbmVkIGludCB2Z2ljX251bV9zcGlfbGluZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ PiArew0KPj4+ICvCoMKgwqAgcmV0dXJuIGQtPmFyY2gudmdpYy5ucl9zcGlzOw0KPj4+ICt9DQo+ Pj4gKw0KPj4+ICtzdHJ1Y3QgcGVuZGluZ19pcnEgKmVzcGlfdG9fcGVuZGluZyhzdHJ1Y3QgZG9t YWluICpkLCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4+ICt7DQo+Pj4gK8KgwqDCoCByZXR1cm4gTlVM TDsNCj4+PiArfQ0KPj4+ICsjZW5kaWYNCj4+PiArDQo+Pj4gK3N0YXRpYyB1bnNpZ25lZCBpbnQg dmdpY19udW1fYWxsb2NfaXJxcyhzdHJ1Y3QgZG9tYWluICpkKQ0KPj4+ICt7DQo+Pj4gK8KgwqDC oCByZXR1cm4gdmdpY19udW1fc3BpX2xpbmVzKGQpICsgTlJfTE9DQUxfSVJRUzsNCj4+PiArfQ0K PiANCj4gSSBkbyBub3Qga25vdyB3aGVyZSBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHV0IGEgY29t bWVudCByZWxhdGVkIHRvIG5vbi0gDQo+IHZpc2libGUgaW4gdGhlIHBhdGNoIGNvbnRleHQgcm91 dGVfaXJxX3RvX2d1ZXN0KCksIGJ1dCBwdXQgaXQgaGVyZS4NCj4gDQo+IEkgYW0gYWZyYWlkLCB0 aGUgdmdpY19udW1faXJxcyhkKSBwcmludGVkIGluIHRoZSBmb2xsb3dpbmcgZXJyb3IgbWVzc2Fn ZSANCj4gaXMgbm90IGVudGlyZWx5IGNvcnJlY3Qgd2l0aCB5b3VyIGNoYW5nZXM6DQo+IA0KPiBy b3V0ZV9pcnFfdG9fZ3Vlc3QoKToNCj4gDQo+IC4uLg0KPiANCj4gIMKgwqDCoCBpZiAoICF2Z2lj X2lzX3ZhbGlkX2xpbmUoZCwgdmlycSkgKQ0KPiAgwqDCoMKgIHsNCj4gIMKgwqDCoMKgwqDCoMKg IHByaW50ayhYRU5MT0dfR19FUlINCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgInRo ZSB2SVJRIG51bWJlciAldSBpcyB0b28gaGlnaCBmb3IgZG9tYWluICV1IChtYXggPSANCj4gJXUp XG4iLA0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpcnEsIGQtPmRvbWFpbl9pZCwg dmdpY19udW1faXJxcyhkKSk7DQo+ICDCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVJTlZBTDsNCj4g IMKgwqDCoCB9DQo+IA0KPiANCg0KV291bGQgaXQgYmUgb2theSB0byBjaGFuZ2UgdGhlIGVycm9y IG1lc3NhZ2UgdG8gc29tZXRoaW5nIGxpa2U6DQoiaW52YWxpZCB2SVJRIG51bWJlciAldSBmb3Ig ZG9tYWluICVwZFxuIg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBhIG1vcmUgZ2VuZXJpYyBl cnJvciBtZXNzYWdlLCBidXQgSSB0aGluayBpdCANCm1pZ2h0IGJlY29tZSBvdmVybHkgY29tcGxp Y2F0ZWQgaWYgSSBhZGQgbW9yZSBpbmZvcm1hdGlvbiBzdGF0aW5nIHRoYXQgDQp0aGUgSVJRIHNo b3VsZCBiZSB3aXRoaW4gdGhlIHJhbmdlIDAuLi52Z2ljX251bV9pcnFzKGQpIG9yIA0KNDA5Ni4u LkVTUElfSURYMklOVElEKGQtPmFyY2gudmdpYy5ucl9lc3BpcykuDQoNCj4+PiArDQo+Pj4gwqAg aW50IGRvbWFpbl92Z2ljX2luaXQoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IG5yX3Nw aXMpDQo+Pj4gwqAgew0KPj4+IMKgwqDCoMKgwqAgaW50IGk7DQo+Pj4gQEAgLTEzMSw2ICsyNjIs MzYgQEAgaW50IGRvbWFpbl92Z2ljX2luaXQoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgDQo+ Pj4gaW50IG5yX3NwaXMpDQo+Pj4gwqDCoMKgwqDCoMKgICovDQo+Pj4gwqDCoMKgwqDCoCBucl9z cGlzID0gUk9VTkRVUChucl9zcGlzLCAzMik7DQo+Pj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQ SQ0KPj4+ICvCoMKgwqAgLyoNCj4+PiArwqDCoMKgwqAgKiBEdXJpbmcgZG9tYWluIGNyZWF0aW9u LCB0aGUgZG9tMGxlc3MgRG9tVXMgY29kZSBvciB0b29sc3RhY2sgDQo+Pj4gc3BlY2lmaWVzDQo+ Pj4gK8KgwqDCoMKgICogdGhlIG1heGltdW0gSU5USUQsIHdoaWNoIGlzIGRlZmluZWQgaW4gdGhl IGRvbWFpbiBjb25maWcgDQo+Pj4gc3VidHJhY3RlZCBieQ0KPj4+ICvCoMKgwqDCoCAqIDMyIHRv IGNvdmVyIHRoZSBsb2NhbCBJUlFzIChwbGVhc2Ugc2VlIHRoZSBjb21tZW50IHRvIA0KPj4+IFZH SUNfREVGX05SX1NQSVMpLg0KPj4+ICvCoMKgwqDCoCAqIFRvIGNvbXB1dGUgdGhlIGFjdHVhbCBu dW1iZXIgb2YgZVNQSSB0aGF0IHdpbGwgYmUgdXNhYmxlIGZvciwNCj4+PiArwqDCoMKgwqAgKiBh ZGQgYmFjayAzMi4NCj4+PiArwqDCoMKgwqAgKi8NCj4+PiArwqDCoMKgIGlmICggbnJfc3BpcyAr IDMyID4gRVNQSV9JRFgySU5USUQoTlJfRVNQSV9JUlFTKSApDQo+Pj4gK8KgwqDCoMKgwqDCoMKg IHJldHVybiAtRUlOVkFMOw0KPj4+ICsNCj4+PiArwqDCoMKgIGlmICggbnJfc3BpcyArIDMyID49 IEVTUElfQkFTRV9JTlRJRCApDQo+Pj4gK8KgwqDCoCB7DQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGQt PmFyY2gudmdpYy5ucl9lc3BpcyA9IG1pbihucl9zcGlzIC0gRVNQSV9CQVNFX0lOVElEICsgMzIs IA0KPj4+IDEwMjRVKTsNCj4+PiArwqDCoMKgwqDCoMKgwqAgLyogVmVyaWZ5IGlmIEdJQyBIVyBj YW4gaGFuZGxlIHByb3ZpZGVkIElOVElEICovDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGlmICggZC0+ YXJjaC52Z2ljLm5yX2VzcGlzID4gZ2ljX251bWJlcl9lc3BpcygpICkNCj4+PiArwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCByZXR1cm4gLUVJTlZBTDsNCj4+PiArwqDCoMKgwqDCoMKgwqAgLyoNCj4+ PiArwqDCoMKgwqDCoMKgwqDCoCAqIFNldCB0aGUgbWF4aW11bSBhdmFpbGFibGUgbnVtYmVyIGZv ciByZWd1bGFyDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqAgKiBTUEkgdG8gcGFzcyB0aGUgbmV4dCBj aGVjaw0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgICovDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIG5yX3Nw aXMgPSBWR0lDX0RFRl9OUl9TUElTOw0KPj4+ICvCoMKgwqAgfQ0KPj4+ICvCoMKgwqAgZWxzZQ0K Pj4+ICvCoMKgwqAgew0KPj4+ICvCoMKgwqDCoMKgwqDCoCAvKiBEb21haW4gd2lsbCB1c2UgdGhl IHJlZ3VsYXIgU1BJIHJhbmdlICovDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGQtPmFyY2gudmdpYy5u cl9lc3BpcyA9IDA7DQo+Pj4gK8KgwqDCoCB9DQo+Pj4gKyNlbmRpZg0KPj4+ICsNCj4+PiDCoMKg wqDCoMKgIC8qIExpbWl0IHRoZSBudW1iZXIgb2YgdmlydHVhbCBTUElzIHN1cHBvcnRlZCB0byAo MTAyMCAtIDMyKSA9IA0KPj4+IDk4OMKgICovDQo+Pj4gwqDCoMKgwqDCoCBpZiAoIG5yX3NwaXMg PiAoMTAyMCAtIE5SX0xPQ0FMX0lSUVMpICkNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJu IC1FSU5WQUw7DQo+Pj4gQEAgLTE0NSw3ICszMDYsNyBAQCBpbnQgZG9tYWluX3ZnaWNfaW5pdChz dHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCANCj4+PiBpbnQgbnJfc3BpcykNCj4+PiDCoMKgwqDC oMKgwqDCoMKgwqAgcmV0dXJuIC1FTk9NRU07DQo+Pj4gwqDCoMKgwqDCoCBkLT5hcmNoLnZnaWMu cGVuZGluZ19pcnFzID0NCj4+PiAtwqDCoMKgwqDCoMKgwqAgeHphbGxvY19hcnJheShzdHJ1Y3Qg cGVuZGluZ19pcnEsIGQtPmFyY2gudmdpYy5ucl9zcGlzKTsNCj4+PiArwqDCoMKgwqDCoMKgwqAg eHphbGxvY19hcnJheShzdHJ1Y3QgcGVuZGluZ19pcnEsIHZnaWNfbnVtX3NwaV9saW5lcyhkKSk7 DQo+Pj4gwqDCoMKgwqDCoCBpZiAoIGQtPmFyY2gudmdpYy5wZW5kaW5nX2lycXMgPT0gTlVMTCAp DQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAtRU5PTUVNOw0KPj4+IEBAIC0xNTYsMTIg KzMxNywxNiBAQCBpbnQgZG9tYWluX3ZnaWNfaW5pdChzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25l ZCANCj4+PiBpbnQgbnJfc3BpcykNCj4+PiDCoMKgwqDCoMKgIGZvciAoIGkgPSAwOyBpIDwgRE9N QUlOX05SX1JBTktTKGQpOyBpKysgKQ0KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB2Z2ljX3Jhbmtf aW5pdCgmZC0+YXJjaC52Z2ljLnNoYXJlZF9pcnFzW2ldLCBpICsgMSwgMCk7DQo+Pj4gK8KgwqDC oCByZXQgPSBpbml0X3ZnaWNfZXNwaShkKTsNCj4+PiArwqDCoMKgIGlmICggcmV0ICkNCj4+PiAr wqDCoMKgwqDCoMKgwqAgcmV0dXJuIHJldDsNCj4+PiArDQo+Pj4gwqDCoMKgwqDCoCByZXQgPSBk LT5hcmNoLnZnaWMuaGFuZGxlci0+ZG9tYWluX2luaXQoZCk7DQo+Pj4gwqDCoMKgwqDCoCBpZiAo IHJldCApDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByZXQ7DQo+Pj4gwqDCoMKgwqDC oCBkLT5hcmNoLnZnaWMuYWxsb2NhdGVkX2lycXMgPQ0KPj4+IC3CoMKgwqDCoMKgwqDCoCB4emFs bG9jX2FycmF5KHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9fTE9OR1ModmdpY19udW1faXJxcyhkKSkp Ow0KPj4+ICvCoMKgwqDCoMKgwqDCoCB4emFsbG9jX2FycmF5KHVuc2lnbmVkIGxvbmcsIA0KPj4+ IEJJVFNfVE9fTE9OR1ModmdpY19udW1fYWxsb2NfaXJxcyhkKSkpOw0KPj4+IMKgwqDCoMKgwqAg aWYgKCAhZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzICkNCj4+PiDCoMKgwqDCoMKgwqDCoMKg wqAgcmV0dXJuIC1FTk9NRU07DQo+Pj4gQEAgLTE5NSw5ICszNjAsMjcgQEAgdm9pZCBkb21haW5f dmdpY19mcmVlKHN0cnVjdCBkb21haW4gKmQpDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIH0NCj4+ PiDCoMKgwqDCoMKgIH0NCj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+Pj4gK8KgwqDC oCBmb3IgKCBpID0gMDsgaSA8IGQtPmFyY2gudmdpYy5ucl9lc3BpczsgaSsrICkNCj4+PiArwqDC oMKgIHsNCj4+PiArwqDCoMKgwqDCoMKgwqAgc3RydWN0IHBlbmRpbmdfaXJxICpwID0gc3BpX3Rv X3BlbmRpbmcoZCwgRVNQSV9JRFgySU5USUQoaSkpOw0KPj4+ICsNCj4+PiArwqDCoMKgwqDCoMKg wqAgaWYgKCBwLT5kZXNjICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgew0KPj4+ICvCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHJldCA9IHJlbGVhc2VfZ3Vlc3RfaXJxKGQsIHAtPmlycSk7DQo+Pj4gK8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCByZXQgKQ0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgZHByaW50ayhYRU5MT0dfR19XQVJOSU5HLCAiJXBkOiBGYWlsZWQgdG8gcmVs ZWFzZSANCj4+PiB2aXJxICV1IHJldCA9ICVkXG4iLA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGQsIHAtPmlycSwgcmV0KTsNCj4+PiArwqDCoMKg wqDCoMKgwqAgfQ0KPj4+ICvCoMKgwqAgfQ0KPj4+ICsjZW5kaWYNCj4+PiArDQo+Pj4gwqDCoMKg wqDCoCBpZiAoIGQtPmFyY2gudmdpYy5oYW5kbGVyICkNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqAg ZC0+YXJjaC52Z2ljLmhhbmRsZXItPmRvbWFpbl9mcmVlKGQpOw0KPj4+IMKgwqDCoMKgwqAgeGZy ZWUoZC0+YXJjaC52Z2ljLnNoYXJlZF9pcnFzKTsNCj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19F U1BJDQo+Pj4gK8KgwqDCoCB4ZnJlZShkLT5hcmNoLnZnaWMuZXh0X3NoYXJlZF9pcnFzKTsNCj4+ PiArI2VuZGlmDQo+Pj4gwqDCoMKgwqDCoCB4ZnJlZShkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFz KTsNCj4+PiDCoMKgwqDCoMKgIHhmcmVlKGQtPmFyY2gudmdpYy5hbGxvY2F0ZWRfaXJxcyk7DQo+ Pj4gwqAgfQ0KPj4+IEBAIC0zMzEsNiArNTE0LDggQEAgdm9pZCBhcmNoX21vdmVfaXJxcyhzdHJ1 Y3QgdmNwdSAqdikNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCB2X3RhcmdldCA9PSB2ICYm ICF0ZXN0X2JpdChHSUNfSVJRX0dVRVNUX01JR1JBVElORywgDQo+Pj4gJnAtPnN0YXR1cykgKQ0K Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlycV9zZXRfYWZmaW5pdHkocC0+ZGVzYywg Y3B1X21hc2spOw0KPj4+IMKgwqDCoMKgwqAgfQ0KPj4+ICsNCj4+PiArwqDCoMKgIGFyY2hfbW92 ZV9lc3Bpcyh2KTsNCj4+PiDCoCB9DQo+Pj4gwqAgdm9pZCB2Z2ljX2Rpc2FibGVfaXJxcyhzdHJ1 Y3QgdmNwdSAqdiwgdWludDMyX3QgciwgdW5zaWduZWQgaW50IG4pDQo+Pj4gQEAgLTUzOCw2ICs3 MjMsOCBAQCBzdHJ1Y3QgcGVuZGluZ19pcnEgKmlycV90b19wZW5kaW5nKHN0cnVjdCB2Y3B1IA0K Pj4+ICp2LCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBuID0gJnYt PmFyY2gudmdpYy5wZW5kaW5nX2lycXNbaXJxXTsNCj4+PiDCoMKgwqDCoMKgIGVsc2UgaWYgKCBp c19scGkoaXJxKSApDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIG4gPSB2LT5kb21haW4tPmFyY2gu dmdpYy5oYW5kbGVyLT5scGlfdG9fcGVuZGluZyh2LT5kb21haW4sIA0KPj4+IGlycSk7DQo+Pj4g K8KgwqDCoCBlbHNlIGlmICggaXNfZXNwaShpcnEpICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgbiA9 IGVzcGlfdG9fcGVuZGluZyh2LT5kb21haW4sIGlycSk7DQo+Pj4gwqDCoMKgwqDCoCBlbHNlDQo+ Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIG4gPSAmdi0+ZG9tYWluLT5hcmNoLnZnaWMucGVuZGluZ19p cnFzW2lycSAtIDMyXTsNCj4+PiDCoMKgwqDCoMKgIHJldHVybiBuOw0KPj4+IEBAIC01NDcsNiAr NzM0LDkgQEAgc3RydWN0IHBlbmRpbmdfaXJxICpzcGlfdG9fcGVuZGluZyhzdHJ1Y3QgZG9tYWlu IA0KPj4+ICpkLCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4+IMKgIHsNCj4+PiDCoMKgwqDCoMKgIEFT U0VSVChpcnEgPj0gTlJfTE9DQUxfSVJRUyk7DQo+Pj4gK8KgwqDCoCBpZiAoIGlzX2VzcGkoaXJx KSApDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiBlc3BpX3RvX3BlbmRpbmcoZCwgaXJxKTsN Cj4+PiArDQo+Pg0KPj4gaGVyZSB5b3UgY2FuIGp1c3QgZG8NCj4+DQo+PiBpZHggPSB2aXJxX3Rv X2lkeCh2aXJxKTsNCj4+DQo+Pj4gwqDCoMKgwqDCoCByZXR1cm4gJmQtPmFyY2gudmdpYy5wZW5k aW5nX2lycXNbaXJxIC0gMzJdOw0KPj4NCj4+IGFuZA0KPj4NCj4+IHJldHVybiAmZC0+YXJjaC52 Z2ljLnBlbmRpbmdfaXJxc1tpZHhdOw0KPj4NCj4+IGluc3RlYWQNCj4+DQo+Pj4gwqAgfQ0KPj4+ IEBAIC02NjgsNiArODU4LDkgQEAgYm9vbCB2Z2ljX3Jlc2VydmVfdmlycShzdHJ1Y3QgZG9tYWlu ICpkLCB1bnNpZ25lZCANCj4+PiBpbnQgdmlycSkNCj4+PiDCoMKgwqDCoMKgIGlmICggIXZnaWNf aXNfdmFsaWRfbGluZShkLCB2aXJxKSApDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiBm YWxzZTsNCj4+PiArwqDCoMKgIGlmICggaXNfZXNwaSh2aXJxKSApDQo+Pj4gK8KgwqDCoMKgwqDC oMKgIHJldHVybiB2Z2ljX3Jlc2VydmVfZXNwaV92aXJxKGQsIHZpcnEpOw0KPj4+ICsNCj4+DQo+ PiBoZXJlIHlvdSBjYW4ganVzdCBkbw0KPj4NCj4+IGlkeCA9IHZpcnFfdG9faWR4KHZpcnEpDQo+ Pg0KPj4+IMKgwqDCoMKgwqAgcmV0dXJuICF0ZXN0X2FuZF9zZXRfYml0KHZpcnEsIGQtPmFyY2gu dmdpYy5hbGxvY2F0ZWRfaXJxcyk7DQo+Pg0KPj4gYW5kIHRoZW4ganVzdA0KPj4NCj4+IHJldHVy biAhdGVzdF9hbmRfc2V0X2JpdChpZHgsIGQtPmFyY2gudmdpYy5hbGxvY2F0ZWRfaXJxcyk7DQo+ Pg0KPj4NCj4+PiDCoCB9DQo+Pj4gQEAgLTY4NSw3ICs4NzgsNyBAQCBpbnQgdmdpY19hbGxvY2F0 ZV92aXJxKHN0cnVjdCBkb21haW4gKmQsIGJvb2wgc3BpKQ0KPj4+IMKgwqDCoMKgwqAgZWxzZQ0K Pj4+IMKgwqDCoMKgwqAgew0KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBmaXJzdCA9IDMyOw0KPj4+ IC3CoMKgwqDCoMKgwqDCoCBlbmQgPSB2Z2ljX251bV9pcnFzKGQpOw0KPj4+ICvCoMKgwqDCoMKg wqDCoCBlbmQgPSB2Z2ljX251bV9hbGxvY19pcnFzKGQpOw0KPj4+IMKgwqDCoMKgwqAgfQ0KPj4N Cj4+IEkgdGhpbmogeW91IG5lZWQgdG8gcmVjYWxjdWxhdGUgInZpcnEiIHZhbHVlIGF0IHRoZSBl bmQgb2YgdGhpcw0KPj4gZnVuY3Rpb24uIFlvdSdsbCByZXR1cm4gaW5kZXggaW4gYml0ZmllbGQs IGJ1dCB0aGlzIGlzIG5vdCB0aGUgc2FtZSBpcw0KPj4gSVJRIG51bWJlciBpbiBjYXNlIG9mIGVT UElzLg0KPiANCj4gKzENCj4gDQo+ICDCoFRoZSBoZWxwZXJzIEkgbWVudGlvbmVkIGJlZm9yZSBj YW4gaGVscCBoZXJlLg0KPj4NCj4+PiDCoMKgwqDCoMKgIC8qDQo+Pg0KPj4gTGFzdGx5LCBJIHRo aW5rIHRoYXQgaXQgaXMgdmVyeSB3YXN0ZWZ1bCB0byBhbGxvY2F0ZSBwZW5kaW5nX2lycXMgYXMN Cj4+IGNvbnRpbnVvdXMgYXJyYXksIGJlY2F1c2UgaXQgd2lsbCBjb25zaXN0IG1vc3RseSBvZiB1 bnVzZWQgZW50cmllcywNCj4+IGVzcGVjaWFsbHkgd2l0aCBlU1BJcyBlbmFibGUuIFByb2JhYmx5 LCBiZXR0ZXIgYXBwcm9hY2ggd2lsbCBiZSB0byB1c2UgDQo+PiByYWRpeA0KPj4gdHJlZS4gQXMg YSBib251cywgeW91IGNhbiB1c2UgSVJRIGxpbmUgbnVtYmVyIGFzIGEga2V5LCBhbmQgZ2V0IHJp ZCBvZg0KPj4gYWxsIHRoZXNlIGlzX2VzcGkoKSBjaGVja3MgYW5kIG1hcHBpbmdzIGJldHdlZW4g SVJRIG51bWJlciBhbmQgaW5kZXggaW4NCj4+IHRoZSBhcnJheS7CoCBCdXQgdGhpcyBpcyBhIG11 Y2ggbW9yZSBkcmFzdGljIGNoYW5nZSwgYW5kIEkgZG9uJ3QgdGhpbmsgDQo+PiB0aGF0IGl0DQo+ PiBzaG91bGQgYmUgZG9uZSBpbiB0aGlzIHBhdGNoIHNlcmllcy4uLg0KPj4NCj4gDQoNCkJlc3Qg cmVnYXJkcywNCkxlb25pZA0K From xen-devel-bounces@lists.xenproject.org Mon Sep 01 18:08:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 18:08:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105300.1456218 (Exim 4.92) (envelope-from ) id 1ut8x1-00073D-V8; Mon, 01 Sep 2025 18:08:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105300.1456218; Mon, 01 Sep 2025 18:08: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 1ut8x1-000736-SH; Mon, 01 Sep 2025 18:08:19 +0000 Received: by outflank-mailman (input) for mailman id 1105300; Mon, 01 Sep 2025 18:08: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 1ut8x0-000730-VJ for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 18:08:18 +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 a2d8de06-875e-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 20:08:17 +0200 (CEST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3cf48ec9fa4so2360539f8f.0 for ; Mon, 01 Sep 2025 11:08:17 -0700 (PDT) Received: from localhost.localdomain (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d1007c0dc8sm14514934f8f.53.2025.09.01.11.08.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 11:08: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: a2d8de06-875e-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756750097; x=1757354897; 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=twGw8qz9N+4L4pIFCsrwtC7rtAZFVGA9AgxXiRKdruY=; b=jNPTG9L+pXh6RT1zPZVkXzob4Pu5eFVyi7wV6/2L8xuALFXif+JVblQ7sfd0x1qiYa mFS7H9EXfa4rl5T1IQtDalrxfkcKN8fFue+zqqc7UUjSbLNr/vuxcoRFJzhfGFfsy87J 01qE89ypg1srbcHyBaqDceyC7YtuDieHYo72U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756750097; x=1757354897; 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=twGw8qz9N+4L4pIFCsrwtC7rtAZFVGA9AgxXiRKdruY=; b=boSZ8G04dplIt/ImIuSJRCPVI1a+Xv/pl6g8yjgk24lhaGAr47ukC0Az7k6K6BDR7Y UGMBC+TwQgFDpTjRJA8aFISjIG3WHdecSwOYSMEM/0FXn9LJZeHF8uOtb96L8kwA/eHD LYR2lnKJzJIEWMh8CMmqwn+BAPcEXIi5ZBTlDmWOA+VNa/4RbCXYwkzLcSqoqhoFCygf AgbHC3pCkyM4UufV7e4s+BseDLu/cSvPA2WWVEWzRIAkPwO2LhpK5bgOfPaFQl6lRvWe 0y5MilOtRsVI6JxWivhNGrHqaQrJJKs8Kx3JepjPV3towna7H4eZm8DR4J30MhN24myu 2CEg== X-Gm-Message-State: AOJu0Yztck26UqU/fidT3GDpP9lDzo1dlAugFXG6nPjs4UXZZB9ylsT7 1DZEHZaGFBv/Ugue0kU13Usi1sChU6QUPgLi/O+SgDHZGyX0InV+34d+jEu3eQl57CLKTtcJfzQ uWSti X-Gm-Gg: ASbGnctBxvJ7oAL9GVbXfepVSkWdD7j5f6c1OHfxFjnv9BceWgxgUZbMQjdXY/jSqQZ SsGCmmvMH3QWXRPZA6CJnvs0m/cksbbm8UTmlgjdSm717J8gPp3uJIO5tkTjLmmJ8utWOHzNUAw KlMUXx2xEq79vr+SYYl3HaPMOuGnH/bY3tZz7edta7F+x+1jvAvV2jIOnu/yO7nA0/jL8UJbxRw xQoA7SGTG/aKD+iGRbSEUdhFNIfh/h3XcDUofnqinOW3O4gNroJ9AKsyjBlnBaovOCk1Wg7YWig adAVBKrFfZIaGvnkpeB+/wPZDxl6N9ZWU5W049FhUUjXyWyeoX7/zq4bppg45e/eBQ/7Lj/5hPy 7agb2BSudEqA1pEJnpRNHQIdt5F1Ea0p0M7Gu3pJevY3nVXqRa3JEXyNKcoqjd7/FjWxYExGkAh Xt X-Google-Smtp-Source: AGHT+IFNYhW9S9yHVcmvvSiwNapuGJBfFXTWhOdg+wQH9cVUbAeMGBk04VIVS7VGwaF1EVd35xLisA== X-Received: by 2002:a05:6000:2dc2:b0:3d1:6748:65fd with SMTP id ffacd0b85a97d-3d1df34f1e8mr6491403f8f.58.1756750096928; Mon, 01 Sep 2025 11:08:16 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich Subject: [PATCH] x86/hvm: Rationalise CS limit handling in arch_set_info_hvm_guest() Date: Mon, 1 Sep 2025 19:08:14 +0100 Message-Id: <20250901180814.1366701-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 Ever since it's introduction in commit 192df6f9122d ("x86: allow HVM guests to use hypercalls to bring up vCPUs"), %cs.g/limit has been handled differently to all other segments. The hypercall takes full 32bit, and hvm_set_segment_register() fixes up all segments .g to match the limit being 2^20 or more. Therefore, treating %cs only as having architectural (20-bit) limit field is weird and unexpected. Remove the custom handling for %cs. This is a guest ABI change, but all callers are expected to be setting up flat segmentation, at which point limit will be ~0U and there will be no change in practice whether .g is set or not. Reported-by: Roger Pau Monné Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné Slightly RFC as this is an ABI change, but I don't anticipate any breakge from this change. --- xen/arch/x86/hvm/domain.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c index 048f29ae4911..4e9aaca39fe6 100644 --- a/xen/arch/x86/hvm/domain.c +++ b/xen/arch/x86/hvm/domain.c @@ -120,7 +120,6 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) case VCPU_HVM_MODE_32B: { const struct vcpu_hvm_x86_32 *regs = &ctx->cpu_regs.x86_32; - uint32_t limit; if ( ctx->cpu_regs.x86_32.pad1 != 0 || ctx->cpu_regs.x86_32.pad2[0] != 0 || @@ -147,13 +146,10 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) return rc; /* Basic sanity checks. */ - limit = cs.limit; - if ( cs.g ) - limit = (limit << 12) | 0xfff; - if ( regs->eip > limit ) + if ( regs->eip > cs.limit ) { gprintk(XENLOG_ERR, "EIP (%#08x) outside CS limit (%#08x)\n", - regs->eip, limit); + regs->eip, cs.limit); return -EINVAL; } base-commit: 3999ff0d307a9a901ad1b5ad56e0dde657fec558 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 18:27:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 18:27:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105311.1456229 (Exim 4.92) (envelope-from ) id 1ut9Fe-0001ZT-Gt; Mon, 01 Sep 2025 18:27:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105311.1456229; Mon, 01 Sep 2025 18:27: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 1ut9Fe-0001ZM-CI; Mon, 01 Sep 2025 18:27:34 +0000 Received: by outflank-mailman (input) for mailman id 1105311; Mon, 01 Sep 2025 18:27:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ut9Fc-0001ZG-Qj for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 18:27:33 +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 4ed3ab8a-8761-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 20:27:25 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by DB4PR03MB8707.eurprd03.prod.outlook.com (2603:10a6:10:381::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.25; Mon, 1 Sep 2025 18:27:22 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 18:27: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: 4ed3ab8a-8761-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=n0fmogA45P7pHNKk1ayJZ0UwG1acQRnb8m2ZF8UhEubNBy72ImMoyQ8stwJesavGvFPzKn5+UxO0ml34sTM2elMX2le/e23w+GW/Cf1GFIYigFTMsvlUDXfKUqi+1dLaRA6jSIAUy36PKH2UP8t9m0oEypf6wIIsptTgQa4ChJ9Kl+Tbw9Iny3MIToguZLh5Mxl15++idntNrmjqNv++f2iTRWztk1LwiYolioefz3zYi1uGcUZ3xrZvK0Vf58u7VNSBPvWz23PvhDqP4NzB4MRbqKM0z8gJ2HOeKwywq3u7gehdjsCsEuXuOGrrXhJCycuNMX0Xmc95zBwEns9u6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UudT9y55FF2JgrPsq/otEnv/ox6sd+JgamZMe0Iab4g=; b=YfI+FA3hY/SzEPx2Dpq+z0JRMhk6FaOk8YcQ+c1Ha3J8z65qxDGHDTloTpVSjEDkfJsCmdhSxYcuH877Oi+NkNnQC2+Dn2Tra7gsqMcSDSL5SspxiBE8u985xOxeduBVr1xSIjF3BQnPys8fVrKJ4y9FpZmHyuvB+XX1qTF6/ToiKXT4hUA+dVcTrgFGfsElOMII1eiypRFqRXXX0jx6wmp269+lI3HskPtbVwDntkf4h7bgRct/KwYkX+Iu1L7/uZL5wTxXjIMGp48Hzy+KgPOsFr9Rh7XF8GN6kw+aF5EwPjgPo+urI58jDmiUemGPFAhyd1Ci0e94ADR17dy++w== 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=UudT9y55FF2JgrPsq/otEnv/ox6sd+JgamZMe0Iab4g=; b=aqgavwqDq35Sy0o7YYoTXtm/62/pwojiPV1+VRSxS+7KtufoWiXRO0sfiKU1prlYPVJvka72cDwthkyOUDgaJEtTv/5wSC0kf/WkIhoYrsfiDDVKI3McIE/mYuO6dBpqZF2gFGmGimnG00AbytAUKkl42RgTkewdGq+YTdT4h5QSELboiz4KOY6lpL/6vMO6zNIDHvC3Qs59C62kU3PEAIwF5rhKmF0iAIQr6MJk+B3KDoYIkcBUgRUIXwv3RMQwTrCmcA//b81MmkHYU7WyzAkoBJSRf+frlBYEfNjgahNau/QK2iUvMlcJ+GhxCHWLsXSSjpcQI86P4V5+KZHT2Q== From: Leonid Komarianskyi To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Topic: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Index: AQHcGP7lSnKp01vKiUyg8GCh+goOA7R+SLaAgABhaIA= Date: Mon, 1 Sep 2025 18:27:22 +0000 Message-ID: <0cf51cc3-9f45-4ddb-b03a-d170f34d559a@epam.com> References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DB4PR03MB8707:EE_ x-ms-office365-filtering-correlation-id: 9fdb991f-036f-4088-7945-08dde9853173 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?YytoNlFHMDB1Umt3VVI5K2o0eDBrd05Ia1BmbWwvcmRxWmlYaVg2WDJ4SHhG?= =?utf-8?B?SlpuWXNpNGU4aUVRTUNPUE12Qm5sTW9JTGtaaHpjTWRsWk9La044YlFTOW94?= =?utf-8?B?RkMyUzJ5OEo4ME9uTVF5c2FhMnpHV2JRRWc3OW9YYUo4SHdzeXdLeW9IQjVp?= =?utf-8?B?bnV3QTJiaVdrOVE4U2k4QURFblUwQmk2UlNwZEFHNzF2YWxQc3RydzlhVS9C?= =?utf-8?B?cDlTSGJ2R0xJdW41NWovbjRBWHRvcnR1M3dDV0d0cTBSTkVqVVoyYmxqaGo1?= =?utf-8?B?NzVYbVhleGVLZnJtTUR5eHZGanE0M3lrMVJMUnprSDJ4eHlPVmVmZW5Gc2l6?= =?utf-8?B?RklIS1AxanE4VXVtQmxJM1N1c1AzcktPVjJJa3lHKzhsU2Rybm9SQ3hXYmMr?= =?utf-8?B?Q1ZJY2F3eGE3eXhkcVZPYi9FQkIrY3NSb2lpWUdpeHhTaHdvd2xvVGt1Y3F3?= =?utf-8?B?WVJ5WDB4aWpsaFkreGZWRml1djgzRmQrc0VmRGZ2VENlUmRFNEoyS2owQ0Ni?= =?utf-8?B?d091aHBPbEYzc0QzWld3djk1eDU1U2xLekFaMUp0NlF6K0QzS0xMYzViT3Vu?= =?utf-8?B?T3d5NEl4NjVQWFhMSWFuOTVyajJ5ZXRkWGJ4N290NnVkRmU4em8yYlB5Q24x?= =?utf-8?B?M3pEdEFXNmJLUU8wdWRUcUVHcEZIUDg3cmE0dDNtUks2VERMVXE5RDlqSHpx?= =?utf-8?B?SVplRU8rakV6Sy9qWnVHclRVMWlhZnZpYnp5WDhJdjlOV1lPMS8vbnoyTVJx?= =?utf-8?B?WW5DeEVpQjdUOVlGRjFNOUkwcHpRVTJNYmQwY0JWeHd6SDlrUjZCSWVsbnBp?= =?utf-8?B?dUozSFIxVXBTWU5VaXdyVTZuYkJla1p1eGQzS1VQK21YVEN6NkdJMDVVT3h0?= =?utf-8?B?SG5ieXEwNU9COXd1azA5dWdVU29lTXAzNXAvdmV4MzNIOWsvangyODlmbzJ0?= =?utf-8?B?Z3htWHE5NDlMdWZ6VVVBOHIyRVQ3WmxpcktKM1IvdTRXRTkxUzcvNTUraGhK?= =?utf-8?B?b0V6ckFRM0NUUmFnWUt4Tm4vZEp0b2pTdURNTDZ5cm94L3hqRERjakdadEtK?= =?utf-8?B?UUNES0tLRzJXb08zSjhteXFqU3JQc29PTkc5S29kZjM4bzJFNmxFVDk4MUdh?= =?utf-8?B?MkJlSWdPOFhxSnlDZTB2bms1YVlpYWNvZGFqVTVudmEzU2lpeHVEYjBGc09j?= =?utf-8?B?cnV1UnJoS0g0eUwzdisxd2hFaldqNHpwWDdGcmcrbXNoOE1PUko3TmNGVnZG?= =?utf-8?B?aTBJd0Y3ZG9OU1dSZlZ5SWRIZVVobmhLUDhYMEN3aVJTWXhIOEVRUjE3K241?= =?utf-8?B?elEzcmNZUXZiVkFLQ0krRWhJdzI2N1MzeStPay9BbzluQXJCQ0VCYk8rY2xi?= =?utf-8?B?dDJBZ21yVE9IVEtucmtHUWkralJnNmpGVnJhZTJNUkIrQWlNNnNWWjNLOVN3?= =?utf-8?B?eE4xamJrd1plYWczT1UyMFlKMUt0VTBXTnNUYldPYzk0WmtlbnpmM3Rqd0cr?= =?utf-8?B?eGJaazB2Mk5SWDBnMG56MERBQUFHT0wyU2FnTzNGSXNLT0ExYkRYNHcvMHlj?= =?utf-8?B?TmYrbDFEQlFlREVGdHVibitjclJBa2lOTWY5TzBYbVl4YkpnMC9CMktxNU8w?= =?utf-8?B?STNBQTRSSCtrYkZnVi90MVNxSE92RnE0UWJkUlBkdWMzMXgyMFBZTm43YitZ?= =?utf-8?B?eWFWL3hSbFRXNnp6dkUzVkZGWXBhODN3Y0tsVW9HL2kvRGQvUUlQUTRxNDE2?= =?utf-8?B?UWNVV1FIMnB0TGhZenp3SUxTdjFxL0h6NG9XaTB4NWJRdFZ2dkUrWTBxQjdQ?= =?utf-8?B?K1NVak1LT2JvRUtpMjB1b3ZSYkJrcldxdDMxMkU0d1FiQWluY3hwakFFZ2NM?= =?utf-8?B?dFovUU9iSnJlazVVN3BLSUtmanhyZSszRnQzYVpKVHpsUHZtSnljNWIyTkNB?= =?utf-8?B?STBTRVZ6RWhSSjh1UHpyWnZ2QXY3djZIcVRhY0FsbTVTTHhoTTJNclB4OG9X?= =?utf-8?B?aDlhY3FtS3l3PT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dmtYdmVuQnNKQ3ZMNFA0dXZmUlhUaUhtQ0NmUzJSYTRwaVJyV0Fpclg2YzF4?= =?utf-8?B?amxPUzZ1WnZlVXdVZEN2MTY3eHFjb1ZsMXNXQkFselh4SXluTDJCb01kZWlK?= =?utf-8?B?UXVpdXFtcGtKd1pnK2VwdEFjNzU5WUx1RnZCTXVhcHZnWk0vcmlVNzBmUzhj?= =?utf-8?B?bHdlbklnZHdJNTNIOWJMVDNETnNsNVdqQ1MvaHBCSVVKaFVWS1l1YXBrUGpl?= =?utf-8?B?Ylcra3RrS1BRdEdvVE9ZQlhKSjIrbDkrWkJzWEtZN2xjQ1pmblJsd2pMM0cr?= =?utf-8?B?NjVPeGMwc004WkFpaTVTSFd1Y2owRVF0d3NrSElVT1VtbkZuSXE2enhiQVlw?= =?utf-8?B?ZzJqeElYclUvTktMRG90TDJlamYzMmMyMVN1ZGM4ZEo2TEcrdmR1UElYT1dI?= =?utf-8?B?SkFRSG1hcVU5anVFdXZ6Y0IrTmdpK0tmWGFRTVc0emVqMjIxWGRwTEhuOEhh?= =?utf-8?B?eTZrRkJVVllyK1RENW9pVmw5ZmFVaVdTditwU3ZWSmJWNUUveEFMNnJTTmox?= =?utf-8?B?V09QTEZDZTRIbXhBNUFubHhxMlhka21zMDYrMDAwWXpHbTZuVjVVcnpZOVI5?= =?utf-8?B?RFhmQ05RZ2FsRlhzUjk2R2VsRW5taFpKQkVzaXdYanlscnEyTG9SSkU1STRS?= =?utf-8?B?VE0rYTRvZHFWd2FXZFUzTHl1RHFnVVdPRHFQN0luaGFrMXJCaDBZVUkzejMv?= =?utf-8?B?ZVNrTURTdXhaWU1rTitCOXNlTjMxK0hmRGJENm1OVklrTjliS0J0Mk9pUnNz?= =?utf-8?B?SGdKcTVySm5Ielk4NTJZbG1GQ3JFMlJ2aWpzYWJpVFFTY0ViY1JGN09VVkVt?= =?utf-8?B?c3hYSmRqeXBBd3hXYzRRSnFmaHpmekw3cmtsd2pZRUZOdFBnek5tQnpnT2w1?= =?utf-8?B?eGJ6Z252VVFON213SHJ5L2YydTJud2ZWYzZncnNObUVLOEpXV0lWSjdVbks5?= =?utf-8?B?cDNITi9ZVE8xZzBENitQMWoyWUNyMm92RGJTUlV3NlZZMTY2Y2xoaTNNM3Jm?= =?utf-8?B?cUNWOUF4emUxS2RPd2NQTjQvUXJzZG9vZHE4MHdRSGlYYUJYOURLQW84alIr?= =?utf-8?B?SUlKZ3NMZGlyYVdWTW5LVTM5SjJaU09YZVY2aWhSbzV3cm9pZmh2bXlsQ3or?= =?utf-8?B?Zlp0eVpnWWhwREhCblJIcmpXMytBRExidHh3dHJGN1J4NXBaZ1RvVnhwRW9q?= =?utf-8?B?bkxndW13enNkYUI5QlFaTTF5dUd2cVRQczdxaHhmYk8xelRXczJpVU5GdE0y?= =?utf-8?B?OXErVXVkeGoyeXZIc1BZTUZNZUNZSUxsbVoxN2lBQnRmUTFESzE0MVR3VGVy?= =?utf-8?B?N2t3eXJydFdIRnh5V2Eva0pEWGMyOFMzcjBVTVhsZnpxMmw2OXAyeGFGeHRh?= =?utf-8?B?dE9lSXphbmhmVElKbGZkNzc0NmhYbThVdlZ4OTA4NEhNWjhrUWJvcEM2R3RB?= =?utf-8?B?ajZOR1hrTXZ4aDBEUVNzWDIrb2c2b09sN3F4YlcvaVZ6Vnh6bzZKalJuNlRr?= =?utf-8?B?REtQTlpCUmpxcEpOMnRUanJWTE9zTk5kU04wcEI3OEFqZWxYTjBBMUtqVlhV?= =?utf-8?B?Zm16b1Z4TVU4RGpPR2hqN3hoYU5vbndiS20yYWx3RitLYXFxZTV2eWNRRzhZ?= =?utf-8?B?c3hNd0hnKzJJWSsvcGc3cDV5c25kSXZlNE1mdnI5OS9XUkRDaS9saEVNMUhl?= =?utf-8?B?cjUvclhQWENDcEx2SjV3NUI1VVFYVHplNXRUSHV6R0ZYcjBjTGRVUnowcnZq?= =?utf-8?B?ZEk1ZkhRWkl3b0dtZFNhR292RHdxM01FU0x0UE0xWkJDekx0M0d1eWJBVER0?= =?utf-8?B?UllZNjY5Z20wSElCN1VLWVArUFQvd3RUSVNlcmJtM2R3NlZYRnNwNksvcDVY?= =?utf-8?B?NEppVTMzcTdUQW1NOTdoZ1BsSTk2UFlXOHlONk1wTWgzOTB2ZEN6RDcwRFo5?= =?utf-8?B?UTdweWJmV0p0cnE2SktVb3AxNFZ6QmhuV0xkKzlnYXo3d3JoQ2gzdXVQM2d4?= =?utf-8?B?WHloS015amJmaFhvZW5yaElMVlVzNHU4TTRuV0d1YVZMY1ZkUlV0Q2hSQS9a?= =?utf-8?B?cmkyTmtlWVNOdTc5R2piK0VuZzUyd2tRTUcvRGd5NFZvVzc0Z1JZUDh5b0RT?= =?utf-8?B?M1JScjZCMHdwU0Fqalg3bEl6SkJWczc5WjByY1B1d3FtdVRxNWRyNlpwUUY0?= =?utf-8?Q?+YrPXBf3g/O0V0tkdU+N5Ng=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <4BD4196309A09A41AC2F54F5C807C856@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9fdb991f-036f-4088-7945-08dde9853173 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 18:27:22.5904 (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: rkxCoYt2wmIzd3zTqUDpZx/drAomYvG9jR77KamZHmAda06cjwC8LNlmHCnvLT+66DYx1ES/6wJtHea3s5WmefPy7bJa18xDHmeBpdk9SeM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB8707 SGVsbG8gT2xla3NhbmRyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCB5b3VyIGdv b2QgcWVzdGlvbi4NCg0KT24gMDEuMDkuMjUgMTU6MzgsIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdy b3RlOg0KPiANCj4gDQo+IE9uIDI5LjA4LjI1IDE5OjA2LCBMZW9uaWQgS29tYXJpYW5za3lpIHdy b3RlOg0KPiANCj4gDQo+IEhlbGxvIExlb25pZA0KPiANCj4+IEltcGxlbWVudGVkIHN1cHBvcnQg Zm9yIEdJQ3YzLjEgZXh0ZW5kZWQgU1BJIHJlZ2lzdGVycyBmb3IgdkdJQ3YzLA0KPj4gYWxsb3dp bmcgdGhlIGVtdWxhdGlvbiBvZiBlU1BJLXNwZWNpZmljIGJlaGF2aW9yIGZvciBndWVzdCBkb21h aW5zLg0KPj4gVGhlIGltcGxlbWVudGF0aW9uIGluY2x1ZGVzIHJlYWQgYW5kIHdyaXRlIGVtdWxh dGlvbiBmb3IgZVNQSS1yZWxhdGVkDQo+PiByZWdpc3RlcnMgKGUuZy4sIEdJQ0RfSVNFTkFCTEVS bkUsIEdJQ0RfSVJPVVRFUm5FLCBhbmQgb3RoZXJzKSwNCj4+IGZvbGxvd2luZyBhIHNpbWlsYXIg YXBwcm9hY2ggdG8gdGhlIGhhbmRsaW5nIG9mIHJlZ3VsYXIgU1BJcy4NCj4+DQo+PiBUaGUgZVNQ SSByZWdpc3RlcnMsIHByZXZpb3VzbHkgbG9jYXRlZCBpbiByZXNlcnZlZCBhZGRyZXNzIHJhbmdl cywNCj4+IGFyZSBub3cgYWRqdXN0ZWQgdG8gc3VwcG9ydCBNTUlPIHJlYWQgYW5kIHdyaXRlIG9w ZXJhdGlvbnMgY29ycmVjdGx5DQo+PiB3aGVuIENPTkZJR19HSUNWM19FU1BJIGlzIGVuYWJsZWQu DQo+Pg0KPj4gVGhlIGF2YWlsYWJpbGl0eSBvZiBlU1BJcyBhbmQgdGhlIG51bWJlciBvZiBlbXVs YXRlZCBleHRlbmRlZCBTUElzDQo+PiBmb3IgZ3Vlc3QgZG9tYWlucyBpcyByZXBvcnRlZCBieSBz ZXR0aW5nIHRoZSBhcHByb3ByaWF0ZSBiaXRzIGluIHRoZQ0KPj4gR0lDRF9UWVBFUiByZWdpc3Rl ciwgYmFzZWQgb24gdGhlIG51bWJlciBvZiBlU1BJcyByZXF1ZXN0ZWQgYnkgdGhlDQo+PiBkb21h aW4gYW5kIHN1cHBvcnRlZCBieSB0aGUgaGFyZHdhcmUuIEluIGNhc2VzIHdoZXJlIHRoZSBjb25m aWd1cmF0aW9uDQo+PiBvcHRpb24gaXMgZGlzYWJsZWQsIHRoZSBoYXJkd2FyZSBkb2VzIG5vdCBz dXBwb3J0IGVTUElzLCBvciB0aGUgZG9tYWluDQo+PiBkb2VzIG5vdCByZXF1ZXN0IHN1Y2ggaW50 ZXJydXB0cywgdGhlIGZ1bmN0aW9uYWxpdHkgcmVtYWlucyB1bmNoYW5nZWQuDQo+Pg0KPj4gU2ln bmVkLW9mZi1ieTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFt LmNvbT4NCj4+DQo+PiAtLS0NCj4+IENoYW5nZXMgaW4gVjU6DQo+PiAtIHNpbmNlIGVTUEktc3Bl Y2lmaWMgZGVmaW5lcyBhbmQgbWFjcm9zIGFyZSBub3cgYXZhaWxhYmxlIGV2ZW4gd2hlbiB0aGUN Cj4+IMKgwqAgYXBwcm9wcmlhdGUgY29uZmlnIGlzIGRpc2FibGVkLCB0aGlzIGFsbG93cyB1cyB0 byByZW1vdmUgbWFueQ0KPj4gwqDCoCAjaWZkZWYgZ3VhcmRzIGFuZCByZXVzZSB0aGUgZXhpc3Rp bmcgY29kZSBmb3IgcmVndWxhciBTUElzIGZvciANCj4+IGVTUElzIGFzDQo+PiDCoMKgIHdlbGws IGFzIGVTUElzIGFyZSBwcm9jZXNzZWQgc2ltaWxhcmx5LiBUaGlzIGltcHJvdmVzIGNvZGUgcmVh ZGFiaWxpdHkNCj4+IMKgwqAgYW5kIGNvbnNvbGlkYXRlcyB0aGUgcmVnaXN0ZXIgcmFuZ2VzIGZv ciBTUElzIGFuZCBlU1BJcyBpbiBhIHNpbmdsZQ0KPj4gwqDCoCBwbGFjZSwgc2ltcGxpZnlpbmcg ZnV0dXJlIGNoYW5nZXMgb3IgZml4ZXMgZm9yIFNQSXMgYW5kIHRoZWlyDQo+PiDCoMKgIGNvdW50 ZXJwYXJ0cyBmcm9tIHRoZSBleHRlbmRlZCByYW5nZQ0KPj4gLSBtb3ZlZCB2Z2ljX2V4dF9yYW5r X29mZnNldCgpIGZyb20NCj4+IMKgwqAgWzA4LzEyXSB4ZW4vYXJtOiB2Z2ljOiBhZGQgcmVzb3Vy Y2UgbWFuYWdlbWVudCBmb3IgZXh0ZW5kZWQgU1BJcw0KPj4gwqDCoCBhcyB0aGUgZnVuY3Rpb24g d2FzIHVudXNlZCBiZWZvcmUgdGhpcyBwYXRjaA0KPj4gLSBhZGRlZCBzdHViIGltcGxlbWVudGF0 aW9uIG9mIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0KCkgd2hlbiANCj4+IENPTkZJR19HSUNWM19FU1BJ PW4NCj4+IC0gcmVtb3ZlZCB1bm5lY2Vzc2FyeSBkZWZpbmVzIGZvciByZXNlcnZlZCByYW5nZXMs IHdoaWNoIHdlcmUgDQo+PiBpbnRyb2R1Y2VkIGluDQo+PiDCoMKgIFY0IHRvIHJlZHVjZSB0aGUg bnVtYmVyIG9mICNpZmRlZnMuIFRoZSBpc3N1ZSBpcyBub3cgcmVzb2x2ZWQgYnkNCj4+IMKgwqAg YWxsb3dpbmcgdGhlIHVzZSBvZiBTUEktc3BlY2lmaWMgb2Zmc2V0cyBhbmQgcmV3b3JraW5nIHRo ZSBsb2dpYw0KPiANCj4gDQo+IExvb2tzIHZlcnkgZ29vZCBub3csIHRoYW5rcy4gSnVzdCBvbmUg TklUIGFuZCBvbmUgcXVlc3Rpb24gYmVsb3cgLi4uDQo+IA0KPj4NCj4+IENoYW5nZXMgaW4gVjQ6 DQo+PiAtIGFkZGVkIG1pc3NpbmcgUkFaIGFuZCB3cml0ZSBpZ25vcmUgZVNQSS1zcGVjaWZpYyBy ZWdpc3RlcnMgcmFuZ2VzOg0KPj4gwqDCoCBHSUNEX05TQUNSbkUgYW5kIEdJQ0RfSUdSUE1PRFJu RQ0KPj4gLSBjaGFuZ2VkIHByZXZpb3VzbHkgcmVzZXJ2ZWQgcmFuZ2UgdG8gY292ZXIgR0lDRF9O U0FDUm5FIGFuZA0KPj4gwqDCoCBHSUNEX0lHUlBNT0RSbkUNCj4+IC0gaW50cm9kdWNlZCBHSUNE X1JFU0VSVkVEX1JBTkdFPG4+X1NUQVJUL0VORCBkZWZpbmVzIHRvIHJlbW92ZQ0KPj4gwqDCoCBo YXJkY29kZWQgdmFsdWVzIGFuZCByZWR1Y2UgdGhlIG51bWJlciBvZiBpZmRlZnMNCj4+IC0gZml4 ZWQgcmVzZXJ2ZWQgcmFuZ2VzIHdpdGggZVNQSSBvcHRpb24gZW5hYmxlZDogYWRkZWQgbWlzc2lu ZyByYW5nZQ0KPj4gwqDCoCAweDBGMzAtMHgwRjdDDQo+PiAtIHVwZGF0ZWQgdGhlIGxvZ2ljIGZv ciBkb21haW5zIHRoYXQgZG8gbm90IHN1cHBvcnQgZVNQSSwgYnV0IFhlbiBpcw0KPj4gwqDCoCBj b21waWxlZCB3aXRoIHRoZSBlU1BJIG9wdGlvbi4gTm93LCBwcmlvciB0byBvdGhlciBNTUlPIGNo ZWNrcywgd2UNCj4+IMKgwqAgdmVyaWZ5IHdoZXRoZXIgZVNQSSBpcyBhdmFpbGFibGUgZm9yIHRo ZSBkb21haW4gb3Igbm90LiBJZiBub3QsIGl0DQo+PiDCoMKgIGJlaGF2ZXMgYXMgaXQgZG9lcyBj dXJyZW50bHkgLSBSQVogYW5kIFdJDQo+PiAtIGZpeGVkIHByaW50IGZvciBHSUNEX0lDQUNUSVZF Um5FDQo+PiAtIGZpeGVkIG5ldyBsaW5lcyBmb3JtYXR0aW5nIGZvciBzd2l0Y2gtY2FzZQ0KPj4N Cj4+IENoYW5nZXMgaW4gVjM6DQo+PiAtIGNoYW5nZWQgdmdpY19zdG9yZV9pcm91dGVyIHBhcmFt ZXRlcnMgLSBpbnN0ZWFkIG9mIG9mZnNldCB2aXJxIGlzDQo+PiDCoMKgIHVzZWQsIHRvIHJlbW92 ZSB0aGUgYWRkaXRpb25hbCBib29sIGVzcGkgcGFyYW1ldGVyIGFuZCBzaW1wbGlmeQ0KPj4gwqDC oCBjaGVja3MuIEFsc28sIGFkanVzdGVkIHBhcmFtZXRlcnMgZm9yIHJlZ3VsYXIgU1BJLiBTaW5j ZSB0aGUgb2Zmc2V0DQo+PiDCoMKgIHBhcmFtZXRlciB3YXMgdXNlZCBvbmx5IGZvciBjYWxjdWxh dGluZyB2aXJxIG51bWJlciBhbmQgdGhlbiByZXVzZWQgDQo+PiBmb3INCj4+IMKgwqAgZmluZGlu ZyByYW5rIG9mZnNldCwgaXQgd2lsbCBub3QgYWZmZWN0IGZ1bmN0aW9uYWxpdHkuDQo+PiAtIGZp eGVkIGZvcm1hdHRpbmcgZm9yIGdvdG8gbGFibGVzIC0gYWRkZWQgbmV3bGluZXMgYWZ0ZXIgY29u ZGl0aW9uDQo+PiAtIGZpeGVkIGxvZ3MgZm9yIEdJQ0RfSVNBQ1RJVkVSbkUgYW5kIEdJQ0RfSUNB Q1RJVkVSbkUgaGFuZGxlcnMNCj4+IC0gcmVtb3ZlZCAjaWZkZWZzIGluIDIgcGxhY2VzIHdoZXJl IHRoZXkgd2VyZSBhZGphY2VudCBhbmQgY291bGQgYmUgDQo+PiBtZXJnZWQNCj4+DQo+PiBDaGFu Z2VzIGluIFYyOg0KPj4gLSBhZGQgbWlzc2luZyByYW5rIGluZGV4IGNvbnZlcnNpb24gZm9yIHBl bmRpbmcgYW5kIGluZmxpZ2h0IGlycXMNCj4+IC0tLQ0KPj4gwqAgeGVuL2FyY2gvYXJtL2luY2x1 ZGUvYXNtL3ZnaWMuaCB8wqDCoCA0ICsNCj4+IMKgIHhlbi9hcmNoL2FybS92Z2ljLXYzLmPCoMKg wqDCoMKgwqDCoMKgwqAgfCAxOTggKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0NCj4+ IMKgIHhlbi9hcmNoL2FybS92Z2ljLmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDIzICsr KysNCj4+IMKgIDMgZmlsZXMgY2hhbmdlZCwgMTkyIGluc2VydGlvbnMoKyksIDMzIGRlbGV0aW9u cygtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5o IGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvIA0KPj4gYXNtL3ZnaWMuaA0KPj4gaW5kZXggM2FhMjIx MTRiYS4uMTAzYmMzYzc0YiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2Fz bS92Z2ljLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgNCj4+IEBA IC0zMTQsNiArMzE0LDEwIEBAIGV4dGVybiBzdHJ1Y3QgdmdpY19pcnFfcmFuayANCj4+ICp2Z2lj X3Jhbmtfb2Zmc2V0KHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgYiwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgdW5zaWduZWQgaW50IG4sDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBzKTsNCj4+ICtleHRlcm4gc3RydWN0IHZnaWNf aXJxX3JhbmsgKnZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHN0cnVjdCB2Y3B1ICp2LA0KPj4gK8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBiLA0KPj4g K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBu LA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVk IGludCBzKTsNCj4+IMKgIGV4dGVybiBzdHJ1Y3QgdmdpY19pcnFfcmFuayAqdmdpY19yYW5rX2ly cShzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgDQo+PiBpbnQgaXJxKTsNCj4+IMKgIGV4dGVybiB2 b2lkIHZnaWNfZGlzYWJsZV9pcnFzKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCByLCB1bnNpZ25l ZCANCj4+IGludCBuKTsNCj4+IMKgIGV4dGVybiB2b2lkIHZnaWNfZW5hYmxlX2lycXMoc3RydWN0 IHZjcHUgKnYsIHVpbnQzMl90IHIsIHVuc2lnbmVkIA0KPj4gaW50IG4pOw0KPj4gZGlmZiAtLWdp dCBhL3hlbi9hcmNoL2FybS92Z2ljLXYzLmMgYi94ZW4vYXJjaC9hcm0vdmdpYy12My5jDQo+PiBp bmRleCA0MzY5YzU1MTc3Li5iNWQ3NjZjOThmIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJt L3ZnaWMtdjMuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3ZnaWMtdjMuYw0KPj4gQEAgLTExMSwx MyArMTExLDEwIEBAIHN0YXRpYyB1aW50NjRfdCB2Z2ljX2ZldGNoX2lyb3V0ZXIoc3RydWN0IA0K Pj4gdmdpY19pcnFfcmFuayAqcmFuaywNCj4+IMKgwqAgKiBOb3RlIHRoZSBvZmZzZXQgd2lsbCBi ZSBhbGlnbmVkIHRvIHRoZSBhcHByb3ByaWF0ZSBib3VuZGFyeS4NCj4+IMKgwqAgKi8NCj4+IMKg IHN0YXRpYyB2b2lkIHZnaWNfc3RvcmVfaXJvdXRlcihzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg DQo+PiB2Z2ljX2lycV9yYW5rICpyYW5rLA0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgb2Zmc2V0LCB1 aW50NjRfdCBpcm91dGVyKQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgdmlycSwgdWludDY0X3QgaXJv dXRlcikNCj4+IMKgIHsNCj4+IMKgwqDCoMKgwqAgc3RydWN0IHZjcHUgKm5ld192Y3B1LCAqb2xk X3ZjcHU7DQo+PiAtwqDCoMKgIHVuc2lnbmVkIGludCB2aXJxOw0KPj4gLQ0KPj4gLcKgwqDCoCAv KiBUaGVyZSBpcyAxIHZJUlEgcGVyIElST1VURVIgKi8NCj4+IC3CoMKgwqAgdmlycSA9IG9mZnNl dCAvIE5SX0JZVEVTX1BFUl9JUk9VVEVSOw0KPj4gK8KgwqDCoCB1bnNpZ25lZCBpbnQgb2Zmc2V0 Ow0KPj4gwqDCoMKgwqDCoCAvKg0KPj4gwqDCoMKgwqDCoMKgICogVGhlIElST1VURVIwLTMxLCB1 c2VkIGZvciBTR0lzL1BQSXMsIGFyZSByZXNlcnZlZCBhbmQgc2hvdWxkDQo+PiBAQCAtNjg1LDEz ICs2ODIsMjAgQEAgc3RhdGljIGludCANCj4+IF9fdmdpY192M19kaXN0cl9jb21tb25fbW1pb19y ZWFkKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoCB7DQo+ PiDCoMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSLCBHSUNEX0lHUk9VUFJOKToN Cj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBNT0RSLCBHSUNEX0lHUlBNT0RS Tik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSbkUsIEdJQ0RfSUdST1VQ Um5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JQTU9EUm5FLCBHSUNEX0lH UlBNT0RSbkVOKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAvKiBXZSBkbyBub3QgaW1wbGVtZW50 IHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIGd1ZXN0cywgcmVhZCANCj4+IHplcm8gKi8NCj4+IMKg wqDCoMKgwqDCoMKgwqDCoCBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93 aWR0aDsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBnb3RvIHJlYWRfYXNfemVybzsNCj4+IMKgwqDC oMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUiwgR0lDRF9JU0VOQUJMRVJOKToNCj4+ ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUm5FLCBHSUNEX0lTRU5BQkxFUm5F Tik6DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkg Z290byBiYWRfd2lkdGg7DQo+PiAtwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFua19vZmZz ZXQodiwgMSwgcmVnIC0gR0lDRF9JU0VOQUJMRVIsIERBQlRfV09SRCk7DQo+PiArwqDCoMKgwqDC oMKgwqAgaWYgKCByZWcgPj0gR0lDRF9JU0VOQUJMRVJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU0VO QUJMRVJuRSwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgREFCVF9XT1JEKTsNCj4+ICvCoMKg wqDCoMKgwqDCoCBlbHNlDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19y YW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTRU5BQkxFUiwgDQo+PiBEQUJUX1dPUkQpOw0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIGlmICggcmFuayA9PSBOVUxMICkgZ290byByZWFkX2FzX3pl cm87DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgdmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3Mp Ow0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgICpyID0gdnJlZ19yZWczMl9leHRyYWN0KHJhbmstPmll bmFibGUsIGluZm8pOw0KPj4gQEAgLTY5OSw4ICs3MDMsMTMgQEAgc3RhdGljIGludCBfX3ZnaWNf djNfZGlzdHJfY29tbW9uX21taW9fcmVhZChjb25zdCANCj4+IGNoYXIgKm5hbWUsIHN0cnVjdCB2 Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAxOw0KPj4gwqDCoMKgwqDCoCBj YXNlIFZSQU5HRTMyKEdJQ0RfSUNFTkFCTEVSLCBHSUNEX0lDRU5BQkxFUk4pOg0KPj4gK8KgwqDC oCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNFTkFCTEVSbkUsIEdJQ0RfSUNFTkFCTEVSbkVOKToNCj4+ IMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJh ZF93aWR0aDsNCj4+IC3CoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAx LCByZWcgLSBHSUNEX0lDRU5BQkxFUiwgREFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBp ZiAoIHJlZyA+PSBHSUNEX0lDRU5BQkxFUm5FICkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHJhbmsgPSB2Z2ljX2V4dF9yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lDRU5BQkxFUm5F LA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEQUJUX1dPUkQpOw0KPj4gK8KgwqDCoMKgwqDC oMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zm c2V0KHYsIDEsIHJlZyAtIEdJQ0RfSUNFTkFCTEVSLCANCj4+IERBQlRfV09SRCk7DQo+PiDCoMKg wqDCoMKgwqDCoMKgwqAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHJlYWRfYXNfemVybzsNCj4+ IMKgwqDCoMKgwqDCoMKgwqDCoCB2Z2ljX2xvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+PiDC oMKgwqDCoMKgwqDCoMKgwqAgKnIgPSB2cmVnX3JlZzMyX2V4dHJhY3QocmFuay0+aWVuYWJsZSwg aW5mbyk7DQo+PiBAQCAtNzEwLDIwICs3MTksMjkgQEAgc3RhdGljIGludCANCj4+IF9fdmdpY192 M19kaXN0cl9jb21tb25fbW1pb19yZWFkKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2 LA0KPj4gwqDCoMKgwqDCoCAvKiBSZWFkIHRoZSBwZW5kaW5nIHN0YXR1cyBvZiBhbiBJUlEgdmlh IEdJQ0QvR0lDUiBpcyBub3QgDQo+PiBzdXBwb3J0ZWQgKi8NCj4+IMKgwqDCoMKgwqAgY2FzZSBW UkFOR0UzMihHSUNEX0lTUEVORFIsIEdJQ0RfSVNQRU5EUk4pOg0KPj4gwqDCoMKgwqDCoCBjYXNl IFZSQU5HRTMyKEdJQ0RfSUNQRU5EUiwgR0lDRF9JQ1BFTkRSTik6DQo+PiArwqDCoMKgIGNhc2Ug VlJBTkdFMzIoR0lDRF9JU1BFTkRSbkUsIEdJQ0RfSVNQRU5EUm5FTik6DQo+PiArwqDCoMKgIGNh c2UgVlJBTkdFMzIoR0lDRF9JQ1BFTkRSbkUsIEdJQ0RfSUNQRU5EUm5FTik6DQo+PiDCoMKgwqDC oMKgwqDCoMKgwqAgZ290byByZWFkX2FzX3plcm87DQo+PiDCoMKgwqDCoMKgIC8qIFJlYWQgdGhl IGFjdGl2ZSBzdGF0dXMgb2YgYW4gSVJRIHZpYSBHSUNEL0dJQ1IgaXMgbm90IA0KPj4gc3VwcG9y dGVkICovDQo+PiDCoMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0FDVElWRVIsIEdJQ0Rf SVNBQ1RJVkVSTik6DQo+PiDCoMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0FDVElWRVIs IEdJQ0RfSUNBQ1RJVkVSTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0FDVElW RVJuRSwgR0lDRF9JU0FDVElWRVJuRU4pOg0KPj4gK8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0Rf SUNBQ1RJVkVSbkUsIEdJQ0RfSUNBQ1RJVkVSbkVOKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBn b3RvIHJlYWRfYXNfemVybzsNCj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lQUklP UklUWVIsIEdJQ0RfSVBSSU9SSVRZUk4pOg0KPj4gK8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0Rf SVBSSU9SSVRZUm5FLCBHSUNEX0lQUklPUklUWVJuRU4pOg0KPj4gwqDCoMKgwqDCoCB7DQo+PiDC oMKgwqDCoMKgwqDCoMKgwqAgdWludDMyX3QgaXByaW9yaXR5cjsNCj4+IMKgwqDCoMKgwqDCoMKg wqDCoCB1aW50OF90IHJhbmtfaW5kZXg7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCBkYWJ0 LnNpemUgIT0gREFCVF9CWVRFICYmIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIA0KPj4g YmFkX3dpZHRoOw0KPj4gLcKgwqDCoMKgwqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYs IDgsIHJlZyAtIEdJQ0RfSVBSSU9SSVRZUiwgREFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDC oCBpZiAoIHJlZyA+PSBHSUNEX0lQUklPUklUWVJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgOCwgcmVnIC0gR0lDRF9JUFJJT1JJ VFlSbkUsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERBQlRfV09SRCk7DQo+PiArwqDCoMKg wqDCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFu a19vZmZzZXQodiwgOCwgcmVnIC0gR0lDRF9JUFJJT1JJVFlSLCANCj4+IERBQlRfV09SRCk7DQo+ PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHJlYWRfYXNfemVy bzsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rX2luZGV4ID0gUkVHX1JBTktfSU5ERVgoOCwg cmVnIC0gR0lDRF9JUFJJT1JJVFlSLCANCj4+IERBQlRfV09SRCk7DQo+PiBAQCAtNzM3LDExICs3 NTUsMTUgQEAgc3RhdGljIGludCANCj4+IF9fdmdpY192M19kaXN0cl9jb21tb25fbW1pb19yZWFk KGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoCB9DQo+PiDC oMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0ZHUiwgR0lDRF9JQ0ZHUk4pOg0KPj4gK8Kg wqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNGR1JuRSwgR0lDRF9JQ0ZHUm5FTik6DQo+PiDCoMKg wqDCoMKgIHsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB1aW50MzJfdCBpY2ZncjsNCj4+IMKgwqDC oMKgwqDCoMKgwqDCoCBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0 aDsNCj4+IC3CoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAyLCByZWcg LSBHSUNEX0lDRkdSLCBEQUJUX1dPUkQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGlmICggcmVnID49 IEdJQ0RfSUNGR1JuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19l eHRfcmFua19vZmZzZXQodiwgMiwgcmVnIC0gR0lDRF9JQ0ZHUm5FLCANCj4+IERBQlRfV09SRCk7 DQo+PiArwqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmFu ayA9IHZnaWNfcmFua19vZmZzZXQodiwgMiwgcmVnIC0gR0lDRF9JQ0ZHUiwgREFCVF9XT1JEKTsN Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8gcmVhZF9hc196 ZXJvOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdz KTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBpY2ZnciA9IHJhbmstPmljZmdbUkVHX1JBTktfSU5E RVgoMiwgcmVnIC0gR0lDRF9JQ0ZHUiwgDQo+PiBEQUJUX1dPUkQpXTsNCj4+IEBAIC03ODIsNDYg KzgwNCw4MSBAQCBzdGF0aWMgaW50IA0KPj4gX192Z2ljX3YzX2Rpc3RyX2NvbW1vbl9tbWlvX3dy aXRlKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoCB7DQo+ PiDCoMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSLCBHSUNEX0lHUk9VUFJOKToN Cj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBNT0RSLCBHSUNEX0lHUlBNT0RS Tik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSbkUsIEdJQ0RfSUdST1VQ Um5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JQTU9EUm5FLCBHSUNEX0lH UlBNT0RSbkVOKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAvKiBXZSBkbyBub3QgaW1wbGVtZW50 IHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIGd1ZXN0cywgd3JpdGUgDQo+PiBpZ25vcmUgKi8NCj4+ IMKgwqDCoMKgwqDCoMKgwqDCoCBnb3RvIHdyaXRlX2lnbm9yZV8zMjsNCj4+IMKgwqDCoMKgwqAg Y2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUiwgR0lDRF9JU0VOQUJMRVJOKToNCj4+ICvCoMKg wqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUm5FLCBHSUNEX0lTRU5BQkxFUm5FTik6DQo+ PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBi YWRfd2lkdGg7DQo+PiAtwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwg MSwgcmVnIC0gR0lDRF9JU0VOQUJMRVIsIERBQlRfV09SRCk7DQo+PiArwqDCoMKgwqDCoMKgwqAg aWYgKCByZWcgPj0gR0lDRF9JU0VOQUJMRVJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU0VOQUJMRVJu RSwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgREFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKg wqDCoCBlbHNlDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29m ZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTRU5BQkxFUiwgDQo+PiBEQUJUX1dPUkQpOw0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3cml0ZV9pZ25vcmU7DQo+ PiDCoMKgwqDCoMKgwqDCoMKgwqAgdmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3MpOw0KPj4g wqDCoMKgwqDCoMKgwqDCoMKgIHRyID0gcmFuay0+aWVuYWJsZTsNCj4+IMKgwqDCoMKgwqDCoMKg wqDCoCB2cmVnX3JlZzMyX3NldGJpdHMoJnJhbmstPmllbmFibGUsIHIsIGluZm8pOw0KPj4gLcKg wqDCoMKgwqDCoMKgIHZnaWNfZW5hYmxlX2lycXModiwgKHJhbmstPmllbmFibGUpICYgKH50ciks IHJhbmstPmluZGV4KTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIHJlZyA+PSBHSUNEX0lTRU5B QkxFUm5FICkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfZW5hYmxlX2lycXModiwg KHJhbmstPmllbmFibGUpICYgKH50ciksDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRVhUX1JBTktfSURYMk5VTShyYW5rLT5pbmRl eCkpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHZnaWNfZW5hYmxlX2lycXModiwgKHJhbmstPmllbmFibGUpICYgKH50ciksIHJhbmstPmluZGV4 KTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB2Z2ljX3VubG9ja19yYW5rKHYsIHJhbmssIGZsYWdz KTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gMTsNCj4+IMKgwqDCoMKgwqAgY2FzZSBW UkFOR0UzMihHSUNEX0lDRU5BQkxFUiwgR0lDRF9JQ0VOQUJMRVJOKToNCj4+ICvCoMKgwqAgY2Fz ZSBWUkFOR0UzMihHSUNEX0lDRU5BQkxFUm5FLCBHSUNEX0lDRU5BQkxFUm5FTik6DQo+PiDCoMKg wqDCoMKgwqDCoMKgwqAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lk dGg7DQo+PiAtwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwgMSwgcmVn IC0gR0lDRF9JQ0VOQUJMRVIsIERBQlRfV09SRCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCBy ZWcgPj0gR0lDRF9JQ0VOQUJMRVJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5r ID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JQ0VOQUJMRVJuRSwNCj4+ ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgREFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBl bHNlDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2 LCAxLCByZWcgLSBHSUNEX0lDRU5BQkxFUiwgDQo+PiBEQUJUX1dPUkQpOw0KPj4gwqDCoMKgwqDC oMKgwqDCoMKgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3cml0ZV9pZ25vcmU7DQo+PiDCoMKg wqDCoMKgwqDCoMKgwqAgdmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3MpOw0KPj4gwqDCoMKg wqDCoMKgwqDCoMKgIHRyID0gcmFuay0+aWVuYWJsZTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB2 cmVnX3JlZzMyX2NsZWFyYml0cygmcmFuay0+aWVuYWJsZSwgciwgaW5mbyk7DQo+PiAtwqDCoMKg wqDCoMKgwqAgdmdpY19kaXNhYmxlX2lycXModiwgKH5yYW5rLT5pZW5hYmxlKSAmIHRyLCByYW5r LT5pbmRleCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCByZWcgPj0gR0lDRF9JQ0VOQUJMRVJu RSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2Z2ljX2Rpc2FibGVfaXJxcyh2LCAofnJh bmstPmllbmFibGUpICYgdHIsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBFWFRfUkFOS19JRFgyTlVNKHJhbmstPmluZGV4KSk7 DQo+PiArwqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdmdp Y19kaXNhYmxlX2lycXModiwgKH5yYW5rLT5pZW5hYmxlKSAmIHRyLCByYW5rLT5pbmRleCk7DQo+ PiDCoMKgwqDCoMKgwqDCoMKgwqAgdmdpY191bmxvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+ PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIDE7DQo+PiDCoMKgwqDCoMKgIGNhc2UgVlJBTkdF MzIoR0lDRF9JU1BFTkRSLCBHSUNEX0lTUEVORFJOKToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0Uz MihHSUNEX0lTUEVORFJuRSwgR0lDRF9JU1BFTkRSbkVOKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCj4+IC3CoMKg wqDCoMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTUEVO RFIsIERBQlRfV09SRCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCByZWcgPj0gR0lDRF9JU1BF TkRSbkUgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfZXh0X3Jhbmtf b2Zmc2V0KHYsIDEsIHJlZyAtIEdJQ0RfSVNQRU5EUm5FLCANCj4+IERBQlRfV09SRCk7DQo+PiAr wqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZn aWNfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU1BFTkRSLCANCj4+IERBQlRfV09SRCk7 DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHdyaXRlX2ln bm9yZTsNCj4+IC3CoMKgwqDCoMKgwqDCoCB2Z2ljX3NldF9pcnFzX3BlbmRpbmcodiwgciwgcmFu ay0+aW5kZXgpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGlmICggcmVnID49IEdJQ0RfSVNQRU5EUm5F ICkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfc2V0X2lycXNfcGVuZGluZyh2LCBy LCBFWFRfUkFOS19JRFgyTlVNKHJhbmstPmluZGV4KSk7DQo+PiArwqDCoMKgwqDCoMKgwqAgZWxz ZQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdmdpY19zZXRfaXJxc19wZW5kaW5nKHYsIHIs IHJhbmstPmluZGV4KTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gMTsNCj4+IMKgwqDC oMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lDUEVORFIsIEdJQ0RfSUNQRU5EUk4pOg0KPj4gK8Kg wqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNQRU5EUm5FLCBHSUNEX0lDUEVORFJuRU4pOg0KPj4g wqDCoMKgwqDCoMKgwqDCoMKgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFk X3dpZHRoOw0KPj4gLcKgwqDCoMKgwqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDEs IHJlZyAtIEdJQ0RfSUNQRU5EUiwgREFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAo IHJlZyA+PSBHSUNEX0lDUEVORFJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5r ID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JQ1BFTkRSbkUsIA0KPj4g REFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBlbHNlDQo+PiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lDUEVORFIs IA0KPj4gREFCVF9XT1JEKTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIHJhbmsgPT0gTlVM TCApIGdvdG8gd3JpdGVfaWdub3JlOw0KPj4gLcKgwqDCoMKgwqDCoMKgIHZnaWNfY2hlY2tfaW5m bGlnaHRfaXJxc19wZW5kaW5nKHYsIHJhbmstPmluZGV4LCByKTsNCj4+ICvCoMKgwqDCoMKgwqDC oCBpZiAoIHJlZyA+PSBHSUNEX0lDUEVORFJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB2Z2ljX2NoZWNrX2luZmxpZ2h0X2lycXNfcGVuZGluZyh2LA0KPj4gK8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgRVhUX1JBTktfSURYMk5VTShyYW5rLSANCj4+ID5pbmRleCksIHIp Ow0KPj4gK8KgwqDCoMKgwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZn aWNfY2hlY2tfaW5mbGlnaHRfaXJxc19wZW5kaW5nKHYsIHJhbmstPmluZGV4LCByKTsNCj4+IMKg wqDCoMKgwqDCoMKgwqDCoCBnb3RvIHdyaXRlX2lnbm9yZTsNCj4+IEBAIC04MzgsMTYgKzg5NSwz OCBAQCBzdGF0aWMgaW50IA0KPj4gX192Z2ljX3YzX2Rpc3RyX2NvbW1vbl9tbWlvX3dyaXRlKGNv bnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgdiwgbmFtZSwgciwgcmVnIC0gR0lDRF9JQ0FDVElWRVIpOw0KPj4gwqDCoMKg wqDCoMKgwqDCoMKgIGdvdG8gd3JpdGVfaWdub3JlXzMyOw0KPj4gK8KgwqDCoCBjYXNlIFZSQU5H RTMyKEdJQ0RfSVNBQ1RJVkVSbkUsIEdJQ0RfSVNBQ1RJVkVSbkVOKToNCj4+ICvCoMKgwqDCoMKg wqDCoCBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqAgZ290byBiYWRfd2lkdGg7DQo+PiArwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19H X0VSUg0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIiVwdjogJXM6IHVuaGFuZGxl ZCB3b3JkIHdyaXRlICUjIlBSSXJlZ2lzdGVyIiB0byANCj4+IElTQUNUSVZFUiVkRVxuIiwNCj4+ ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHYsIG5hbWUsIHIsIHJlZyAtIEdJQ0RfSVNB Q1RJVkVSbkUpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiAwOw0KPj4gKw0KPj4gK8KgwqDC oCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNBQ1RJVkVSbkUsIEdJQ0RfSUNBQ1RJVkVSbkVOKToNCj4+ ICvCoMKgwqDCoMKgwqDCoCBwcmludGsoWEVOTE9HX0dfRVJSDQo+PiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCAiJXB2OiAlczogdW5oYW5kbGVkIHdvcmQgd3JpdGUgJSMiUFJJcmVnaXN0 ZXIiIHRvIA0KPj4gSUNBQ1RJVkVSJWRFXG4iLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgdiwgbmFtZSwgciwgcmVnIC0gR0lDRF9JQ0FDVElWRVJuRSk7DQo+PiArwqDCoMKgwqDC oMKgwqAgZ290byB3cml0ZV9pZ25vcmVfMzI7DQo+IA0KPiANCj4gTklUOiBJIHdvdWxkIGdyb3Vw IHdpdGggcmVndWxhciBTUEkgcmFuZ2VzICh0YWtpbmcgaW50byBhY2NvdW50IHRoYXQgYWxsIA0K PiBvdGhlciByYW5nZXMgd2VyZSBhbHJlYWR5IGdyb3VwZWQgaW5jbHVkaW5nIHRoZSByZWFkIGFj Y2Vzc2VzKSwgDQo+IHNvbWV0aGluZyBsaWtlIHRoYXQgKG5vbiB0ZXN0ZWQpOg0KPiANCj4gIMKg wqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0FDVElWRVIsIEdJQ0RfSVNBQ1RJVkVSTik6DQo+ ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTQUNUSVZFUm5FLCBHSUNEX0lTQUNUSVZFUm5F Tik6DQo+ICDCoMKgwqDCoMKgwqDCoMKgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdv dG8gYmFkX3dpZHRoOw0KPiAtwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19HX0VSUg0KPiAt wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiJXB2OiAlczogdW5oYW5kbGVkIHdvcmQgd3Jp dGUgJSMiUFJJcmVnaXN0ZXIiIHRvIA0KPiBJU0FDVElWRVIlZFxuIiwNCj4gLcKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgdiwgbmFtZSwgciwgcmVnIC0gR0lDRF9JU0FDVElWRVIpOw0KPiAr wqDCoMKgwqDCoMKgwqAgaWYgKCByZWcgPj0gR0lDRF9JU0FDVElWRVJuRSApDQo+ICvCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHByaW50ayhYRU5MT0dfR19FUlINCj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAiJXB2OiAlczogdW5oYW5kbGVkIHdvcmQgd3JpdGUgJSMiUFJJ cmVnaXN0ZXIiIHRvIA0KPiBJU0FDVElWRVIlZEVcbiIsDQo+ICvCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgdiwgbmFtZSwgciwgcmVnIC0gR0lDRF9JU0FDVElWRVJuRSk7DQo+ ICvCoMKgwqDCoMKgwqDCoCBlbHNlDQo+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHByaW50ayhY RU5MT0dfR19FUlINCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiJXB2 OiAlczogdW5oYW5kbGVkIHdvcmQgd3JpdGUgJSMiUFJJcmVnaXN0ZXIiIHRvIA0KPiBJU0FDVElW RVIlZFxuIiwNCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2LCBuYW1l LCByLCByZWcgLSBHSUNEX0lTQUNUSVZFUik7DQo+ICDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAw Ow0KPiANCj4gIMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0FDVElWRVIsIEdJQ0RfSUNB Q1RJVkVSTik6DQo+IC3CoMKgwqDCoMKgwqDCoCBwcmludGsoWEVOTE9HX0dfRVJSDQo+IC3CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICIlcHY6ICVzOiB1bmhhbmRsZWQgd29yZCB3cml0ZSAl IyJQUklyZWdpc3RlciIgdG8gDQo+IElDQUNUSVZFUiVkXG4iLA0KPiAtwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB2LCBuYW1lLCByLCByZWcgLSBHSUNEX0lDQUNUSVZFUik7DQo+ICvCoMKg wqAgY2FzZSBWUkFOR0UzMihHSUNEX0lDQUNUSVZFUm5FLCBHSUNEX0lDQUNUSVZFUm5FTik6DQo+ ICvCoMKgwqDCoMKgwqDCoCBpZiAoIHJlZyA+PSBHSUNEX0lDQUNUSVZFUm5FICkNCj4gK8KgwqDC oMKgwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19HX0VSUg0KPiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgICIlcHY6ICVzOiB1bmhhbmRsZWQgd29yZCB3cml0ZSAlIyJQ UklyZWdpc3RlciIgdG8gDQo+IElDQUNUSVZFUiVkRVxuIiwNCj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB2LCBuYW1lLCByLCByZWcgLSBHSUNEX0lDQUNUSVZFUm5FKTsN Cj4gK8KgwqDCoMKgwqDCoMKgIGVsc2UNCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcHJpbnRr KFhFTkxPR19HX0VSUg0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICIl cHY6ICVzOiB1bmhhbmRsZWQgd29yZCB3cml0ZSAlIyJQUklyZWdpc3RlciIgdG8gDQo+IElDQUNU SVZFUiVkXG4iLA0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHYsIG5h bWUsIHIsIHJlZyAtIEdJQ0RfSUNBQ1RJVkVSKTsNCj4gIMKgwqDCoMKgwqDCoMKgwqAgZ290byB3 cml0ZV9pZ25vcmVfMzI7DQo+IA0KPiANCg0KSSBhZ3JlZSB3aXRoIHRoYXQuIFdpdGggc3VjaCBj aGFuZ2VzLCBpdCB3aWxsIGJlIG11Y2ggZWFzaWVyIHRvIG1vZGlmeSANCnRoZSBjb2RlIGZvciBT UEkgYW5kIGVTUEkgY291bnRlcnBhcnRzIGlmIG5lZWRlZC4gSSB3aWxsIHJlZ3JvdXAgdGhlbSBp biBWNi4NCg0KPj4gKw0KPj4gwqDCoMKgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSVBSSU9SSVRZ UiwgR0lDRF9JUFJJT1JJVFlSTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JUFJJ T1JJVFlSbkUsIEdJQ0RfSVBSSU9SSVRZUm5FTik6DQo+PiDCoMKgwqDCoMKgIHsNCj4+IC3CoMKg wqDCoMKgwqDCoCB1aW50MzJfdCAqaXByaW9yaXR5ciwgcHJpb3JpdHk7DQo+PiArwqDCoMKgwqDC oMKgwqAgdWludDMyX3QgKmlwcmlvcml0eXIsIHByaW9yaXR5LCBvZmZzZXQ7DQo+PiDCoMKgwqDC oMKgwqDCoMKgwqAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9CWVRFICYmIGRhYnQuc2l6ZSAhPSBE QUJUX1dPUkQgKSBnb3RvIA0KPj4gYmFkX3dpZHRoOw0KPj4gLcKgwqDCoMKgwqDCoMKgIHJhbmsg PSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDgsIHJlZyAtIEdJQ0RfSVBSSU9SSVRZUiwgREFCVF9XT1JE KTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIHJlZyA+PSBHSUNEX0lQUklPUklUWVJuRSApIHsN Cj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG9mZnNldCA9IHJlZyAtIEdJQ0RfSVBSSU9SSVRZ Um5FOw0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfZXh0X3Jhbmtfb2Zm c2V0KHYsIDgsIG9mZnNldCwgREFCVF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCB9DQo+PiAr wqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIG9mZnNldCA9IHJlZyAtIEdJQ0RfSVBSSU9SSVRZUjsNCj4+ICvCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDgsIG9mZnNldCwgREFC VF9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCB9DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYg KCByYW5rID09IE5VTEwgKSBnb3RvIHdyaXRlX2lnbm9yZTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCB2Z2ljX2xvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+PiAtwqDCoMKgwqDCoMKgwqAgaXBy aW9yaXR5ciA9ICZyYW5rLT5pcHJpb3JpdHlyW1JFR19SQU5LX0lOREVYKDgsIHJlZyAtIA0KPj4g R0lDRF9JUFJJT1JJVFlSLA0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgREFCVF9XT1JEKV07DQo+PiArwqDCoMKgwqDCoMKgwqAgaXByaW9yaXR5 ciA9ICZyYW5rLT5pcHJpb3JpdHlyW1JFR19SQU5LX0lOREVYKDgsIG9mZnNldCwgDQo+PiBEQUJU X1dPUkQpXTsNCj4gDQo+IEhlcmUNCj4gDQo+IA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHByaW9y aXR5ID0gQUNDRVNTX09OQ0UoKmlwcmlvcml0eXIpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZy ZWdfcmVnMzJfdXBkYXRlKCZwcmlvcml0eSwgciwgaW5mbyk7DQo+PiDCoMKgwqDCoMKgwqDCoMKg wqAgQUNDRVNTX09OQ0UoKmlwcmlvcml0eXIpID0gcHJpb3JpdHk7DQo+PiBAQCAtODU5LDEwICs5 MzgsMTQgQEAgc3RhdGljIGludCANCj4+IF9fdmdpY192M19kaXN0cl9jb21tb25fbW1pb193cml0 ZShjb25zdCBjaGFyICpuYW1lLCBzdHJ1Y3QgdmNwdSAqdiwNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCBnb3RvIHdyaXRlX2lnbm9yZV8zMjsNCj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNE X0lDRkdSICsgNCwgR0lDRF9JQ0ZHUk4pOiAvKiBQUEkgKyBTUElzICovDQo+PiArwqDCoMKgIGNh c2UgVlJBTkdFMzIoR0lDRF9JQ0ZHUm5FLCBHSUNEX0lDRkdSbkVOKToNCj4+IMKgwqDCoMKgwqDC oMKgwqDCoCAvKiBJQ0ZHUjEgZm9yIFBQSSdzLCB3aGljaCBpcyBpbXBsZW1lbnRhdGlvbiBkZWZp bmVkDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgSUNGR1IxIGlzIHByb2dyYW1tYWJs ZSBvciBub3QuIFdlIGNob3NlIHRvIHByb2dyYW0gKi8NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBp ZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCj4+IC3CoMKgwqDC oMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAyLCByZWcgLSBHSUNEX0lDRkdSLCBE QUJUX1dPUkQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGlmICggcmVnID49IEdJQ0RfSUNGR1JuRSAp DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQo diwgMiwgcmVnIC0gR0lDRF9JQ0ZHUm5FLCANCj4+IERBQlRfV09SRCk7DQo+PiArwqDCoMKgwqDC oMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFua19v ZmZzZXQodiwgMiwgcmVnIC0gR0lDRF9JQ0ZHUiwgREFCVF9XT1JEKTsNCj4+IMKgwqDCoMKgwqDC oMKgwqDCoCBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8gd3JpdGVfaWdub3JlOw0KPj4gwqDCoMKg wqDCoMKgwqDCoMKgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdzKTsNCj4+IMKgwqDCoMKg wqDCoMKgwqDCoCB2cmVnX3JlZzMyX3VwZGF0ZSgmcmFuay0+aWNmZ1tSRUdfUkFOS19JTkRFWCgy LCByZWcgLSANCj4+IEdJQ0RfSUNGR1IsDQo+PiBAQCAtMTEyOSw2ICsxMjEyLDE2IEBAIHN0YXRp YyBpbnQgdmdpY192M19kaXN0cl9tbWlvX3JlYWQoc3RydWN0IHZjcHUgDQo+PiAqdiwgbW1pb19p bmZvX3QgKmluZm8sDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlciB8PSBHSUNE X1RZUEVfTFBJUzsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlciB8PSAodi0+ZG9tYWluLT5h cmNoLnZnaWMuaW50aWRfYml0cyAtIDEpIDw8IA0KPj4gR0lDRF9UWVBFX0lEX0JJVFNfU0hJRlQ7 DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCB2 LT5kb21haW4tPmFyY2gudmdpYy5ucl9lc3BpcyA+IDAgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHsN Cj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC8qIFNldCBlU1BJIHN1cHBvcnQgYml0IGZvciB0 aGUgZG9tYWluICovDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlciB8PSBHSUNEX1RZ UEVSX0VTUEk7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAvKiBTZXQgRVNQSSByYW5nZSBi aXRzICovDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlciB8PSAoRElWX1JPVU5EX1VQ KHYtPmRvbWFpbi0+YXJjaC52Z2ljLm5yX2VzcGlzLCAzMikgDQo+PiAtIDEpDQo+PiArwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPDwgR0lDRF9UWVBFUl9FU1BJ X1JBTkdFX1NISUZUOw0KPj4gK8KgwqDCoMKgwqDCoMKgIH0NCj4+ICsjZW5kaWYNCj4+IMKgwqDC oMKgwqDCoMKgwqDCoCAqciA9IHZyZWdfcmVnMzJfZXh0cmFjdCh0eXBlciwgaW5mbyk7DQo+PiBA QCAtMTE5NCw2ICsxMjg3LDE2IEBAIHN0YXRpYyBpbnQgdmdpY192M19kaXN0cl9tbWlvX3JlYWQo c3RydWN0IHZjcHUgDQo+PiAqdiwgbW1pb19pbmZvX3QgKmluZm8sDQo+PiDCoMKgwqDCoMKgIGNh c2UgVlJBTkdFMzIoR0lDRF9JUFJJT1JJVFlSLCBHSUNEX0lQUklPUklUWVJOKToNCj4+IMKgwqDC oMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lDRkdSLCBHSUNEX0lDRkdSTik6DQo+PiDCoMKgwqDC oMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JQTU9EUiwgR0lDRF9JR1JQTU9EUk4pOg0KPj4gK8Kg wqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUdST1VQUm5FLCBHSUNEX0lHUk9VUFJuRU4pOg0KPj4g K8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSVNFTkFCTEVSbkUsIEdJQ0RfSVNFTkFCTEVSbkVO KToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lDRU5BQkxFUm5FLCBHSUNEX0lDRU5B QkxFUm5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU1BFTkRSbkUsIEdJQ0Rf SVNQRU5EUm5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ1BFTkRSbkUsIEdJ Q0RfSUNQRU5EUm5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0FDVElWRVJu RSwgR0lDRF9JU0FDVElWRVJuRU4pOg0KPj4gK8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNB Q1RJVkVSbkUsIEdJQ0RfSUNBQ1RJVkVSbkVOKToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihH SUNEX0lQUklPUklUWVJuRSwgR0lDRF9JUFJJT1JJVFlSbkVOKToNCj4+ICvCoMKgwqAgY2FzZSBW UkFOR0UzMihHSUNEX0lDRkdSbkUsIEdJQ0RfSUNGR1JuRU4pOg0KPj4gK8KgwqDCoCBjYXNlIFZS QU5HRTMyKEdJQ0RfSUdSUE1PRFJuRSwgR0lDRF9JR1JQTU9EUm5FTik6DQo+PiDCoMKgwqDCoMKg wqDCoMKgwqAgLyoNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgICogQWJvdmUgYWxsIHJlZ2lzdGVy IGFyZSBjb21tb24gd2l0aCBHSUNSIGFuZCBHSUNEDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoCAq IE1hbmFnZSBpbiBjb21tb24NCj4+IEBAIC0xMjAxLDYgKzEzMDQsNyBAQCBzdGF0aWMgaW50IHZn aWNfdjNfZGlzdHJfbW1pb19yZWFkKHN0cnVjdCB2Y3B1IA0KPj4gKnYsIG1taW9faW5mb190ICpp bmZvLA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiBfX3ZnaWNfdjNfZGlzdHJfY29tbW9u X21taW9fcmVhZCgidkdJQ0QiLCB2LCBpbmZvLCANCj4+IGdpY2RfcmVnLCByKTsNCj4+IMKgwqDC oMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX05TQUNSLCBHSUNEX05TQUNSTik6DQo+PiArwqDCoMKg IGNhc2UgVlJBTkdFMzIoR0lDRF9OU0FDUm5FLCBHSUNEX05TQUNSbkVOKToNCj4+IMKgwqDCoMKg wqDCoMKgwqDCoCAvKiBXZSBkbyBub3QgaW1wbGVtZW50IHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9y IGd1ZXN0cywgcmVhZCANCj4+IHplcm8gKi8NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBnb3RvIHJl YWRfYXNfemVyb18zMjsNCj4+IEBAIC0xMjE2LDE2ICsxMzIwLDIxIEBAIHN0YXRpYyBpbnQgdmdp Y192M19kaXN0cl9tbWlvX3JlYWQoc3RydWN0IHZjcHUgDQo+PiAqdiwgbW1pb19pbmZvX3QgKmlu Zm8sDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgLyogUmVwbGFjZWQgd2l0aCBHSUNSX0lTUEVORFIw LiBTbyBpZ25vcmUgd3JpdGUgKi8NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBnb3RvIHJlYWRfYXNf emVyb18zMjsNCj4+IC3CoMKgwqAgY2FzZSBWUkFOR0UzMigweDBGMzAsIDB4NjBGQyk6DQo+PiAr wqDCoMKgIGNhc2UgVlJBTkdFMzIoMHgwRjMwLCAweDBGRkMpOg0KPj4gwqDCoMKgwqDCoMKgwqDC oMKgIGdvdG8gcmVhZF9yZXNlcnZlZDsNCj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0U2NChHSUNE X0lST1VURVIzMiwgR0lDRF9JUk9VVEVSMTAxOSk6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFNjQo R0lDRF9JUk9VVEVSbkUsIEdJQ0RfSVJPVVRFUm5FTik6DQo+PiDCoMKgwqDCoMKgIHsNCj4+IMKg wqDCoMKgwqDCoMKgwqDCoCB1aW50NjRfdCBpcm91dGVyOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKg IGlmICggIXZnaWNfcmVnNjRfY2hlY2tfYWNjZXNzKGRhYnQpICkgZ290byBiYWRfd2lkdGg7DQo+ PiAtwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwgNjQsIGdpY2RfcmVn IC0gR0lDRF9JUk9VVEVSLA0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERBQlRfRE9VQkxFX1dPUkQpOw0KPj4gK8KgwqDC oMKgwqDCoMKgIGlmICggZ2ljZF9yZWcgPj0gR0lDRF9JUk9VVEVSbkUgKQ0KPj4gK8KgwqDCoMKg wqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHYsIDY0LCBnaWNkX3Jl ZyAtIA0KPj4gR0lDRF9JUk9VVEVSbkUsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERBQlRf RE9VQkxFX1dPUkQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDY0LCBnaWNkX3JlZyAtIEdJQ0Rf SVJPVVRFUiwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERBQlRfRE9VQkxFX1dPUkQpOw0KPj4gwqDCoMKg wqDCoMKgwqDCoMKgIGlmICggcmFuayA9PSBOVUxMICkgZ290byByZWFkX2FzX3plcm87DQo+PiDC oMKgwqDCoMKgwqDCoMKgwqAgdmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3MpOw0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgIGlyb3V0ZXIgPSB2Z2ljX2ZldGNoX2lyb3V0ZXIocmFuaywgZ2ljZF9y ZWcgLSBHSUNEX0lST1VURVIpOw0KPiANCj4gSGVyZSB5b3UgdXNlIHRoZSBzYW1lIG9mZnNldCBm b3IgcmVndWxhciBhbmQgZXh0ZW5kZWQgU1BJIHJhbmdlcyANCj4gKGdpY2RfcmVnIC0gR0lDRF9J Uk9VVEVSKSAuLi4NCj4gDQo+IA0KDQpPaCwgdGhpcyBpcyBhbiBlcnJvciwgYW5kIGl0IG9ubHkg d29ya3MgYmVjYXVzZSBHSUNEX0lST1VURVIgaGFzIGFuIA0Kb2Zmc2V0IG9mIDB4NjAwMCwgR0lD RF9JUk9VVEVSbkUgaGFzIDB4ODAwMCwgYW5kIHZnaWNfZmV0Y2hfaXJvdXRlciANCmFwcGxpZXMg dGhlIG1hc2sgSU5URVJSVVBUX1JBTktfTUFTSyAoMHgxRik6DQoNCiAgICAgLyogVGhlcmUgaXMg ZXhhY3RseSAxIHZJUlEgcGVyIElST1VURVIgKi8NCiAgICAgb2Zmc2V0IC89IE5SX0JZVEVTX1BF Ul9JUk9VVEVSOw0KDQogICAgIC8qIEdldCB0aGUgaW5kZXggaW4gdGhlIHJhbmsgKi8NCiAgICAg b2Zmc2V0ICY9IElOVEVSUlVQVF9SQU5LX01BU0s7DQoNCkFmdGVyIGFwcGx5aW5nIHRoZSBtYXNr LCB0aGUgJ2FkZGl0aW9uYWwnIGRpZmZlcmVuY2Ugb2YgMHgyMDAwLzggd2FzIA0KcmVtb3ZlZC4u DQoNClRoZSBvZmZzZXQgc2hvdWxkIGJlIHJlY2FsY3VsYXRlZCBhY2NvcmRpbmcgdG8gdGhlIHJl Z2lzdGVyIGJlaW5nIA0KcHJvY2Vzc2VkLCBhcyBpbiB0aGUgY29kZSBiZWxvdy4NCg0KSSB3aWxs IGZpeCB0aGlzIGFuZCByZXZpZXcgb3RoZXIgcGxhY2VzIHdpdGggc2ltaWxhciBjb2RlLg0KDQo+ PiBAQCAtMTIzNSw4ICsxMzQ0LDggQEAgc3RhdGljIGludCB2Z2ljX3YzX2Rpc3RyX21taW9fcmVh ZChzdHJ1Y3QgdmNwdSANCj4+ICp2LCBtbWlvX2luZm9fdCAqaW5mbywNCj4+IMKgwqDCoMKgwqDC oMKgwqDCoCByZXR1cm4gMTsNCj4+IMKgwqDCoMKgwqAgfQ0KPj4gLQ0KPj4gLcKgwqDCoCBjYXNl IFZSQU5HRTMyKDB4N0ZFMCwgMHhCRkZDKToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMigweDM3 MDAsIDB4NjBGQyk6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoMHhBMDA0LCAweEJGRkMpOg0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIGdvdG8gcmVhZF9yZXNlcnZlZDsNCj4+IMKgwqDCoMKgwqAg Y2FzZSBWUkFOR0UzMigweEMwMDAsIDB4RkZDQyk6DQo+PiBAQCAtMTM4MiwxMiArMTQ5MSwyMyBA QCBzdGF0aWMgaW50IHZnaWNfdjNfZGlzdHJfbW1pb193cml0ZShzdHJ1Y3QgDQo+PiB2Y3B1ICp2 LCBtbWlvX2luZm9fdCAqaW5mbywNCj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lQ UklPUklUWVIsIEdJQ0RfSVBSSU9SSVRZUk4pOg0KPj4gwqDCoMKgwqDCoCBjYXNlIFZSQU5HRTMy KEdJQ0RfSUNGR1IsIEdJQ0RfSUNGR1JOKToNCj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihH SUNEX0lHUlBNT0RSLCBHSUNEX0lHUlBNT0RSTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIo R0lDRF9JR1JPVVBSbkUsIEdJQ0RfSUdST1VQUm5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdF MzIoR0lDRF9JU0VOQUJMRVJuRSwgR0lDRF9JU0VOQUJMRVJuRU4pOg0KPj4gK8KgwqDCoCBjYXNl IFZSQU5HRTMyKEdJQ0RfSUNFTkFCTEVSbkUsIEdJQ0RfSUNFTkFCTEVSbkVOKToNCj4+ICvCoMKg wqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTUEVORFJuRSwgR0lDRF9JU1BFTkRSbkVOKToNCj4+ICvC oMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lDUEVORFJuRSwgR0lDRF9JQ1BFTkRSbkVOKToNCj4+ ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTQUNUSVZFUm5FLCBHSUNEX0lTQUNUSVZFUm5F Tik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0FDVElWRVJuRSwgR0lDRF9JQ0FD VElWRVJuRU4pOg0KPj4gK8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSVBSSU9SSVRZUm5FLCBH SUNEX0lQUklPUklUWVJuRU4pOg0KPj4gK8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNGR1Ju RSwgR0lDRF9JQ0ZHUm5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JQTU9E Um5FLCBHSUNEX0lHUlBNT0RSbkVOKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAvKiBBYm92ZSBy ZWdpc3RlcnMgYXJlIGNvbW1vbiB3aXRoIEdJQ1IgYW5kIEdJQ0QNCj4+IMKgwqDCoMKgwqDCoMKg wqDCoMKgICogTWFuYWdlIGluIGNvbW1vbiAqLw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVy biBfX3ZnaWNfdjNfZGlzdHJfY29tbW9uX21taW9fd3JpdGUoInZHSUNEIiwgdiwgaW5mbywNCj4+ IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZ2ljZF9yZWcsIHIp Ow0KPj4gwqDCoMKgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfTlNBQ1IsIEdJQ0RfTlNBQ1JOKToN Cj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX05TQUNSbkUsIEdJQ0RfTlNBQ1JuRU4pOg0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIC8qIFdlIGRvIG5vdCBpbXBsZW1lbnQgc2VjdXJpdHkgZXh0 ZW5zaW9ucyBmb3IgZ3Vlc3RzLCB3cml0ZSANCj4+IGlnbm9yZSAqLw0KPj4gwqDCoMKgwqDCoMKg wqDCoMKgIGdvdG8gd3JpdGVfaWdub3JlXzMyOw0KPj4gQEAgLTE0MDUsMjYgKzE1MjUsMzggQEAg c3RhdGljIGludCB2Z2ljX3YzX2Rpc3RyX21taW9fd3JpdGUoc3RydWN0IA0KPj4gdmNwdSAqdiwg bW1pb19pbmZvX3QgKmluZm8sDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCBkYWJ0LnNpemUg IT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0 dXJuIDA7DQo+PiAtwqDCoMKgIGNhc2UgVlJBTkdFMzIoMHgwRjMwLCAweDYwRkMpOg0KPj4gK8Kg wqDCoCBjYXNlIFZSQU5HRTMyKDB4MEYzMCwgMHgwRkZDKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCBnb3RvIHdyaXRlX3Jlc2VydmVkOw0KPj4gwqDCoMKgwqDCoCBjYXNlIFZSQU5HRTY0KEdJQ0Rf SVJPVVRFUjMyLCBHSUNEX0lST1VURVIxMDE5KToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0U2NChH SUNEX0lST1VURVJuRSwgR0lDRF9JUk9VVEVSbkVOKToNCj4+IMKgwqDCoMKgwqAgew0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgIHVpbnQ2NF90IGlyb3V0ZXI7DQo+PiArwqDCoMKgwqDCoMKgwqAgdW5z aWduZWQgaW50IG9mZnNldCwgdmlycTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoICF2Z2lj X3JlZzY0X2NoZWNrX2FjY2VzcyhkYWJ0KSApIGdvdG8gYmFkX3dpZHRoOw0KPj4gLcKgwqDCoMKg wqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDY0LCBnaWNkX3JlZyAtIEdJQ0RfSVJP VVRFUiwNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBEQUJUX0RPVUJMRV9XT1JEKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBp ZiAoIGdpY2RfcmVnID49IEdJQ0RfSVJPVVRFUm5FICkgew0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqAgb2Zmc2V0ID0gZ2ljZF9yZWcgLSBHSUNEX0lST1VURVJuRTsNCj4+ICvCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHJhbmsgPSB2Z2ljX2V4dF9yYW5rX29mZnNldCh2LCA2NCwgb2Zmc2V0LCAN Cj4+IERBQlRfRE9VQkxFX1dPUkQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIH0gZWxzZSB7DQo+PiAr wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBvZmZzZXQgPSBnaWNkX3JlZyAtIEdJQ0RfSVJPVVRFUjsN Cj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDY0 LCBvZmZzZXQsIERBQlRfRE9VQkxFX1dPUkQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIH0NCj4+IMKg wqDCoMKgwqDCoMKgwqDCoCBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8gd3JpdGVfaWdub3JlOw0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdzKTsNCj4+ IC3CoMKgwqDCoMKgwqDCoCBpcm91dGVyID0gdmdpY19mZXRjaF9pcm91dGVyKHJhbmssIGdpY2Rf cmVnIC0gR0lDRF9JUk9VVEVSKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpcm91dGVyID0gdmdpY19m ZXRjaF9pcm91dGVyKHJhbmssIG9mZnNldCk7DQo+IA0KPiAgwqAuLi4gQnV0IGhlcmUgeW91IHVz ZSBkaWZmZXJlbnQgb2Zmc2V0cyBmb3IgcmVndWxhciBhbmQgZXh0ZW5kZWQgU1BJIA0KPiByYW5n ZXMgKGdpY2RfcmVnIC0gR0lDRF9JUk9VVEVSIHZzIGdpY2RfcmVnIC0gR0lDRF9JUk9VVEVSbkUp LiBDb3VsZCB5b3UgDQo+IHBsZWFzZSBjbGFyaWZ5IHdoeSAod2hhdCBkaWQgSSBtaXNzKT8NCj4g DQo+IA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZyZWdfcmVnNjRfdXBkYXRlKCZpcm91dGVyLCBy LCBpbmZvKTsNCj4+IC3CoMKgwqDCoMKgwqDCoCB2Z2ljX3N0b3JlX2lyb3V0ZXIodi0+ZG9tYWlu LCByYW5rLCBnaWNkX3JlZyAtIEdJQ0RfSVJPVVRFUiwgDQo+PiBpcm91dGVyKTsNCj4+ICvCoMKg wqDCoMKgwqDCoCBpZiAoIGdpY2RfcmVnID49IEdJQ0RfSVJPVVRFUm5FICkNCj4+ICvCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHZpcnEgPSBFU1BJX0lEWDJJTlRJRChvZmZzZXQgLyBOUl9CWVRFU19Q RVJfSVJPVVRFUik7DQo+PiArwqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoMKgwqDCoMKg wqDCoMKgwqAgdmlycSA9IG9mZnNldCAvIE5SX0JZVEVTX1BFUl9JUk9VVEVSOw0KPj4gK8KgwqDC oMKgwqDCoMKgIHZnaWNfc3RvcmVfaXJvdXRlcih2LT5kb21haW4sIHJhbmssIHZpcnEsIGlyb3V0 ZXIpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfdW5sb2NrX3JhbmsodiwgcmFuaywgZmxh Z3MpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAxOw0KPj4gwqDCoMKgwqDCoCB9DQo+ PiAtwqDCoMKgIGNhc2UgVlJBTkdFMzIoMHg3RkUwLCAweEJGRkMpOg0KPj4gK8KgwqDCoCBjYXNl IFZSQU5HRTMyKDB4MzcwMCwgMHg2MEZDKToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMigweEEw MDQsIDB4QkZGQyk6DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgZ290byB3cml0ZV9yZXNlcnZlZDsN Cj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMigweEMwMDAsIDB4RkZDQyk6DQo+PiBkaWZmIC0t Z2l0IGEveGVuL2FyY2gvYXJtL3ZnaWMuYyBiL3hlbi9hcmNoL2FybS92Z2ljLmMNCj4+IGluZGV4 IGM5Yjk1MjhjNjYuLjI3ZmZkZjMxNmMgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdmdp Yy5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiBAQCAtMTkzLDYgKzE5MywxOCBA QCBpbnQgZG9tYWluX3ZnaWNfcmVnaXN0ZXIoc3RydWN0IGRvbWFpbiAqZCwgDQo+PiB1bnNpZ25l ZCBpbnQgKm1taW9fY291bnQpDQo+PiDCoCB9DQo+PiDCoCAjaWZkZWYgQ09ORklHX0dJQ1YzX0VT UEkNCj4+ICsvKg0KPj4gKyAqIFRoZSBmdW5jdGlvbiBiZWhhdmlvciBpcyB0aGUgc2FtZSBhcyBm b3IgcmVndWxhciBTUElzIA0KPj4gKHZnaWNfcmFua19vZmZzZXQpLA0KPj4gKyAqIGJ1dCBpdCBv cGVyYXRlcyB3aXRoIGV4dGVuZGVkIFNQSSByYW5rcy4NCj4+ICsgKi8NCj4+ICtzdHJ1Y3Qgdmdp Y19pcnFfcmFuayAqdmdpY19leHRfcmFua19vZmZzZXQoc3RydWN0IHZjcHUgKnYsIHVuc2lnbmVk IA0KPj4gaW50IGIsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGlu dCBuLCB1bnNpZ25lZCANCj4+IGludCBzKQ0KPj4gK3sNCj4+ICvCoMKgwqAgdW5zaWduZWQgaW50 IHJhbmsgPSBSRUdfUkFOS19OUihiLCAobiA+PiBzKSk7DQo+PiArDQo+PiArwqDCoMKgIHJldHVy biB2Z2ljX2dldF9yYW5rKHYsIHJhbmsgKyBFWFRfUkFOS19NSU4pOw0KPj4gK30NCj4+ICsNCj4+ IMKgIHN0YXRpYyB1bnNpZ25lZCBpbnQgdmdpY19udW1fc3BpX2xpbmVzKHN0cnVjdCBkb21haW4g KmQpDQo+PiDCoCB7DQo+PiDCoMKgwqDCoMKgIHJldHVybiBkLT5hcmNoLnZnaWMubnJfc3BpcyAr IGQtPmFyY2gudmdpYy5ucl9lc3BpczsNCj4+IEBAIC0yNDEsNiArMjUzLDE3IEBAIHN0cnVjdCBw ZW5kaW5nX2lycSAqZXNwaV90b19wZW5kaW5nKHN0cnVjdCBkb21haW4gDQo+PiAqZCwgdW5zaWdu ZWQgaW50IGlycSkNCj4+IMKgIHsNCj4+IMKgwqDCoMKgwqAgcmV0dXJuIE5VTEw7DQo+PiDCoCB9 DQo+PiArDQo+PiArLyoNCj4+ICsgKiBJdCBpcyBleHBlY3RlZCB0aGF0LCBpbiB0aGUgY2FzZSBv ZiBDT05GSUdfR0lDVjNfRVNQST1uLCB0aGUgDQo+PiBmdW5jdGlvbiB3aWxsDQo+PiArICogcmV0 dXJuIE5VTEwuIEluIHRoaXMgc2NlbmFyaW8sIG1taW9fcmVhZC9tbWlvX3dyaXRlIHdpbGwgYmUg DQo+PiB0cmVhdGVkIGFzDQo+PiArICogUkFaL1dJLCBhcyBleHBlY3RlZC4NCj4+ICsgKi8NCj4+ ICtzdHJ1Y3QgdmdpY19pcnFfcmFuayAqdmdpY19leHRfcmFua19vZmZzZXQoc3RydWN0IHZjcHUg KnYsIHVuc2lnbmVkIA0KPj4gaW50IGIsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHVuc2lnbmVkIGludCBuLCB1bnNpZ25lZCANCj4+IGludCBzKQ0KPj4gK3sNCj4+ICvCoMKgwqAg cmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gwqAgI2VuZGlmDQo+PiDCoCBzdGF0aWMgdW5zaWduZWQg aW50IHZnaWNfbnVtX2FsbG9jX2lycXMoc3RydWN0IGRvbWFpbiAqZCkNCj4gDQoNCkJlc3QgcmVn YXJkcywNCkxlb25pZA0K From xen-devel-bounces@lists.xenproject.org Mon Sep 01 18:32:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 18:32:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105326.1456239 (Exim 4.92) (envelope-from ) id 1ut9Kk-0003G0-77; Mon, 01 Sep 2025 18:32:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105326.1456239; Mon, 01 Sep 2025 18:32: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 1ut9Kk-0003Ft-3A; Mon, 01 Sep 2025 18:32:50 +0000 Received: by outflank-mailman (input) for mailman id 1105326; Mon, 01 Sep 2025 18:32: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 1ut9Ki-0003Fn-Cf for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 18:32:48 +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 0e29b762-8762-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 20:32:46 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by PAXPR03MB8297.eurprd03.prod.outlook.com (2603:10a6:102:23f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 18:32:43 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 18:32: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: 0e29b762-8762-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yrusMKSaCQaW0WyGbDKTlwfL5HWs8oFgf4DwvQ5FyxvMYJ2BHaf79CJDonYDhXR8HH4wIweColG0j3AKYvsa3rxrDekr8n1my2bpPN6g8KaJrNXlULBNBMLpbFOvPCXSAgp2C/gXG4fGxksk2Xj//acLu5GdNePjk7A988M1dy0T3Es9bVAEaQ+6XHQEhxhccSdECAOJm7tlJeixEh0D/MGOSAA0VrTcNSnjpAkprWanPUDHIvs4C+u4p1rG5/DWJwNCVeGfxwI9nwTRkp4AZMEu3tVLWLB9s38VFc8zq7x5Mg3NKi/ghSLwaycEbCh8vd7wsDVF/2O1RfpIFuzE6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fG4DW6QXV4f9ec8hzl0RcBZ8WAnvdnhwnF3AKctNzeo=; b=NvjneIwV0VT2Bun/RIuC0/GCJ+QQIWEZdeu6UPxJH72SNRLgz9983Fjyb9TkZQMpx+wp9rhYSKUEfjhs01ygmcgSPtg2wZw3FaAZMLnNRRSerkmEWdiy0kJyynz+ICrK3U+LY81QooUN8h6uPkIoQwyM7O/HbS9wYQHICmqvuzxjuiifBWkTzjg19SAk/hK9thFTCwGsvQRN4bCRBB7SaaaeGNc0dx3nBZ13AHvuWjNoQRddtRU9RMWhrBjMia+lt0SYZFKU5FrGnIdu3q/894xCR2aX3/m5V5g1z5eUqDwt098o/XFu8PuSoHFRHg8vrMBAWKrtRwDs9ANxz8mW3w== 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=fG4DW6QXV4f9ec8hzl0RcBZ8WAnvdnhwnF3AKctNzeo=; b=roOYSmPGRt4hqsNSwfed4cs6T8DjKKlQ43xo7FsHmSviM3RAAd2Uu0YvL/DsVe/NapIZHf2RrTfHeLMDmt1owKvajXUKnROCbJuozNXOdB268YO6b6M6cnYR4mQ6bDF+34XJMAuTFDEzf7HQ9SYpahMwiGuuWn9KBVsb3LFtoKC3D3v8ON6cH76eTnbYbHdVRuxBv4+/0E4jx9Kpkknc1J7awA7CVLjlWcEZnc0Exf7XYCmJMMYINh2BDlA/Ox6P6EutYD4a+/2D3jSaioHq7NM06UscE21RKJUMllci11Q4oqp5+iFfgOk+SVKPiPQuyqlpPTWnKZFd3eOsvkDXQQ== From: Leonid Komarianskyi To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , "olekstysh@gmail.com" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Topic: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Index: AQHcGP7lSnKp01vKiUyg8GCh+goOA7R+q5uA Date: Mon, 1 Sep 2025 18:32:42 +0000 Message-ID: References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> <87cy8dyjj8.fsf@epam.com> In-Reply-To: <87cy8dyjj8.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|PAXPR03MB8297:EE_ x-ms-office365-filtering-correlation-id: d8b63eef-c031-49d2-72bf-08dde985f020 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?MDRxQ2hiNkdEWmlJam9VenR3cUl6bDN0VmhPdEZuZldOb1JtelFPbjhRay82?= =?utf-8?B?VXpScnR5ZVVWcmcyOEZvR3hDUW9hWE5FTVNHMEl5ZkIvUm5nS0N5aXpqOWcr?= =?utf-8?B?Zi9Ub1UwUklJdE43OWxWU01xd0J2ajBoSk8yWkwvZklQdGF2UkVwd1diQjlJ?= =?utf-8?B?ZjNXVjVkenFTQ0pzRjhSMkk3UHpheVBJUE9WTTZOdkNaNURSSVFjeGdabWNh?= =?utf-8?B?cnIwNjlHNXRjVkkyYnR5bzB2YUlTT2NKNm9RNmRLYXBFRTA3SnAxU0FDd1Uv?= =?utf-8?B?OTVFNm1TWlExSy9oeWZiVU5hZHVMNGx2ejJwZWlTWUtxa2t6YmtEVFB0LzVX?= =?utf-8?B?U1hIbFBOVkJ6MWZkZVNDUGI0bHJUNzdOdG5xd09VakNIZ2g0RHorRWhRdlBq?= =?utf-8?B?M29TTmdxUk1JM0FmZlJOc1lSMS9WZEtxY1dUdXdPVGZVY1dtU0RzNjkyTlVr?= =?utf-8?B?UnpIcU9oQ2cvaDZQdW5YSmI0Z3U2SnVvUndlVXVyUk4rUExhRzhoZFRTb3ov?= =?utf-8?B?WEwvNWIyaDZWV084djZha2VNVW9pd2tQa0xwSFlOa0p5MnRQdXFqckZUMytl?= =?utf-8?B?cGc2YUhlc0VaS3dmMUUwZ3ZNanUrRDN3MmNNQmRGR1Nmb29sSjNRVVBKeTJv?= =?utf-8?B?M09NV0VNNHdXYUtTZWVLdno1UDB5ZHZLbExydTFxVjdkb0pFV1JJUnFrdExq?= =?utf-8?B?VTBrbUEwZjcvVzQ2WjdPWHltb2ZXZVhhN0NwY3BxaFhhenM0RTRobkxBNGd0?= =?utf-8?B?OGdtYlZIWkZsSzVmejhhb2kwckIvdksyRyttd3JvT09KdVZjd2svdDdVb2Rt?= =?utf-8?B?Sk1jUnYyMmZ3UkdzdXdxdnc3bmRGVERSQ3pna1FoV3VTRmpBdzExc2Fzd1Jm?= =?utf-8?B?K1VZaGVaaE1hMXJqVjVFNGxmalZNMUkrbVdMVFZuNnY0cmV5NDNId2hiUk5p?= =?utf-8?B?amRDOU95elQxaElPZitXV25PQ1dwMjB5WW0zbXVEUmxzTWp6Qkp6QWVlbHUv?= =?utf-8?B?Qkh0NmdLRWcyT2w2OVFwUElMbkp3T29pZVd5ZTVoalpNeDl5U3FKemg5WnBn?= =?utf-8?B?dGUxSktDVTEyaWdZUFR2d2locmNtSVlTbHkrT3YzdkhJcVVkV1lPblUvTXJX?= =?utf-8?B?Q0tvL0ZSeEZ2TmJ6K3l4b0owZlVtT3k2eDYzd3FQNTZoZWY4bk82Mnd4K2E0?= =?utf-8?B?c1dMem4wZ0htNGZ3VURMWllYckVTSElyQlRMVDlXQUZ1TnQ4YnJxdFpjT3ZX?= =?utf-8?B?aXFXYnFYeWoxUWVjTkpJekVHRUlkZldOc25oWHovbGIzNThQL2ZtUmdJQ2Rz?= =?utf-8?B?TkdsdE1qaDhZYkNGT0dMQ29qQnRVRDZPTVVuVXZTTm5aZy8zN1NIampQSzNO?= =?utf-8?B?eGVIQ09oNHZDZlZtTStyeXllb2xjLyt3K3VxLzFpWGRrdDY5c3Rjb1E1c1ZP?= =?utf-8?B?MmhJdWVkN2ZXUFBZUFlSZ0pZd2hCZVhZcDhIZC9WOU1La2NoVTFMYU1rZGZU?= =?utf-8?B?aDE0ZExVUzVXZmpzWCtOSGIzZHNQUFZPWk5JbkdtYWduR3cwUGVBaENWRk16?= =?utf-8?B?T2FLZUZmUG9hSklhQXM4bEJkNk5pRktFSDBiRlV2N1FiZWFqdFQzY3JnVnlm?= =?utf-8?B?SlJObEVkY2R2OW9idkZFYXBnYi9CYXBJajhBdVIzS0JwNGZPVXRBeFhrNDFC?= =?utf-8?B?RTdHWlVXWjVZbjljWWN6cytvQXlqM0dnNnJTeE9uY3pqY3JzZ1NQQ0VZNlRr?= =?utf-8?B?K3pwMEp1MXF6RnBZa2lpS1poYWlGa0ttK2dnakJKL0Y1QmJCWnFCWUpjSlp6?= =?utf-8?B?eWJLcUE3RHVndEVCeHZIL1ZRbE1Va3ZjS1hONmpDMTUrd3ZQRWJKZ3hLdDgw?= =?utf-8?B?UFIwUWFub0JuU1NId1J3akFxbmk4anFOeURtaWxvNEpVQ2FlT2VFWFZkMzhC?= =?utf-8?B?WGRzUitWMy95MENIaldkSFdDL3lITnZsVEYwcHI1NGw2TW1XQlNxUGhrRXBG?= =?utf-8?B?WC9ITi9EN2tBPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RHhUajRXUCtZM2hTZWRMbktYaUcwRUVKMkFsWUUxQXAxYTAxNzh4VS9mZ2ts?= =?utf-8?B?V0FTbkxoTkdQMjEwckJGTFpTWG9RM0xiQ04yUG1mRlVJaVRxZ0tzNE9CRENH?= =?utf-8?B?b3pWeXFyeWNxNWM4a2tLOTBYN0JrWkhWNXhhSUxYeitVU1NyUThrWThKTGJr?= =?utf-8?B?RWdvK1NPQ3ZjTkhSU0ZNaFR4ci9BYnRxUjlWUjRZTWV2bFE0VnQ0OENLY1l6?= =?utf-8?B?aXl1ZE1MZ3FGTkNyaS9oSzYrM0Y4WU55dTVOUldRQkR6bkhKODRKWm53Y3Zn?= =?utf-8?B?L1NZd1ZNSHhmMmhVVmFPRmQzZEtSRnlxOFdjNEZIT214MXJjVjVsNmF2QVNH?= =?utf-8?B?NUN1c3JBYW1pUksrNElEQjk0OCtLb21xWnAzdkdwakZSa1kxL1B4NWZhcjNT?= =?utf-8?B?OXk5bVprNElBTTJ4aW5OV2QwR2g3WVBiY1d1YXJBcm1VZEJvbjAzNFhkV2xO?= =?utf-8?B?d0lEaGhOaHdYWTFzenhDQUZ1NVVTL1l6YXU5cmN0OU5zN3dTeEl1U25HL3BE?= =?utf-8?B?TWJGVHFVT0pGSytxYjlRbjNVN0o1RmFRcW44NTQzdVgrbVhEa25kK0l3SUlF?= =?utf-8?B?ZzVEeVBoTWZBWWcwZ3FGQm5Ca1ZkNnIyUDVLOVNiek1iMGVZN29jWjROSWxC?= =?utf-8?B?NFdvd3ZOTGdQMStTSXhwLzg4Y2ZGU1RNb3JYRFFBT0xwMThmTlcrNnhIa0pw?= =?utf-8?B?M1lSQ2I3R3ZTNWxSTzNra1dVZGJ5VXhTbTlDZHZBRFFiSER1TWFxS05BSmJE?= =?utf-8?B?RlZPQ3pjd0UyOEdrem5HZWNSRHhwLzlvVFdMY2t2RzVpSnhWNmd2clY4dnZY?= =?utf-8?B?bEIrWGw5eU1paWVlcFN4S3hydktBak5lQzdBdkpBUktmWmk1MmlVamJOUVFy?= =?utf-8?B?L2FzcVNyeUtoZFQwN2tNY2JTeUdoMWlWb09mcUx5ZFdJNW51MmpMSzZ4ZHpn?= =?utf-8?B?bjZHTHN6Q0Y2TkJ4dVZpWGZUYUZYQ1dkc2IvemtMMXRFVXk2L01oVnlkSnRk?= =?utf-8?B?ZWtFbnFGcG1OQjVKVnRaWEF1ejU0K3VYZlZlM1ZScVFqNDg0R2xQdE85VjFl?= =?utf-8?B?TGlXNmNuamUybDZEVERGWlMvdFViTXFLbFJ1dCtQd0hNS0dUZ0JwbHJFS2pR?= =?utf-8?B?a2laNUpDaVhCUkRRcGc0Q0JqVzhYc2VLbWxtaDIwUTZVcVdoQnF3R2Fya3Az?= =?utf-8?B?OExDZ1NQR21xT3R3czV2SDcyWEdvMC9xZHJJdGR6YmpxWVNsTVhrU1lmYkZD?= =?utf-8?B?RmR3V1Q4Mm9QVW9hbzlHcGkwSXNFYk45bmRYeEo3Y0lYbG4yK09iQVoxdkpw?= =?utf-8?B?ZU42ZkNFV0srTDJtOHduVnB5OHk1ZDBiTDIyTFhJS2ZJZlF5SHBZMFVVeG95?= =?utf-8?B?MjFxRCtoWnpnMFlxQWxTNDVGenFITzhnUmgveE5pakp4a2ZBVTd4WndHL2s4?= =?utf-8?B?NFhNZ1NmWDRqRnFOVVJWamVlRnhhaWpKZzNiMFNzS1NncjZ1MW5LY2tJdUJX?= =?utf-8?B?V2JRclcvUU55Y213TTU2WWEzZkJHOGJkNVdJTkxraHh3VDNXM2xwY0JVOXF2?= =?utf-8?B?U3BkMkNTSjJSSVRTZDJYaEFRUm1zQW1TRS9PeUZvS3VVUHIyY2tqdmtlZ1pZ?= =?utf-8?B?N043Z0lMakd0MzduYjR0elRUdGdPY1k4Q0hMQVRleGpWb0l4bHVEdHVoQzlv?= =?utf-8?B?SlJlM3A4amJnWXd2REp1UEl2Rmovc29KbW5NK2VLc0IrR2NVc2FQdFltVnVI?= =?utf-8?B?djQ1K0UzQ3N4NDJQVWRFZGxQc1lEVHV5M2Jvbkh3cDVtdzRVVzFMYUkwQzN1?= =?utf-8?B?SFl1ZlU5UmY5SWhzTE5XV1daQlpWSXJjVVd1KzJlZVhGanJ5TGRPTWlGZ25z?= =?utf-8?B?MWdOa2o5NjVhSzROQXpUTFlsMFo4d005S0pmSGhTK3lNYWdhZUhqZWdnZVNN?= =?utf-8?B?UDFaK3pOYVBwTnVvaitOR2Zsemw0S0VYMlFUbElMNHJ3bkdqb1pDUy9iMS9J?= =?utf-8?B?Rnp3NnZrN1Yvb2lhNnIzcHRVYlQzQUNabUZtV0dlTElwUG82M2lVRHRHTWRo?= =?utf-8?B?Njg1c1RMME1Fb0VOak1uNU1sdS9hbk9EaDFjZ1ZuckFvN0NMZG0xOEhUQ3VL?= =?utf-8?B?dUlDTzJ0dkp4VFo3VUVGb3drdUFrTTFpUVZXb01FTlorWnpGRTVzV1Q1Zndj?= =?utf-8?Q?FA6asZE64q29u1v35INkSFM=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <0729443B6A4DA8448382AD998622083D@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8b63eef-c031-49d2-72bf-08dde985f020 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2025 18:32:42.4528 (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: LWDLj1jBm2DnY4QKV573CknW8i+QO6zFaknwxfm2QNl8snqFxVNknkx+myqiqdk+l4D6+MSJ0eq89xV04TPKaax498KNkjLd9XoYx3f2WIY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB8297 SGkgVm9sb2R5bXlyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBSQi4NClVuZm9y dHVuYXRlbHksIHRoZSBjb2RlIGNvbnRhaW5zIGFuIGVycm9yIHJlbGF0ZWQgdG8gb2Zmc2V0IGNh bGN1bGF0aW9uIA0KZm9yIEdJQ0RfSVJPVVRFUm5FLCB3aGljaCB3YXMgb2JzZXJ2ZWQgYnkgT2xl a3NhbmRyLiBJIHdpbGwgZml4IGl0IGluIA0KVjYsIGFsb25nIHdpdGggdGhlIGZvcm1hdHRpbmcg aXNzdWVzIHlvdSBkaXNjb3ZlcmVkLiBJIGFwb2xvZ2l6ZSBmb3IgdGhhdC4NCg0KT24gMjkuMDgu MjUgMjM6MTIsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPiBIaSBMZW9uaWQsDQo+IA0KPiBM ZW9uaWQgS29tYXJpYW5za3lpIDxMZW9uaWRfS29tYXJpYW5za3lpQGVwYW0uY29tPiB3cml0ZXM6 DQo+IA0KPj4gSW1wbGVtZW50ZWQgc3VwcG9ydCBmb3IgR0lDdjMuMSBleHRlbmRlZCBTUEkgcmVn aXN0ZXJzIGZvciB2R0lDdjMsDQo+PiBhbGxvd2luZyB0aGUgZW11bGF0aW9uIG9mIGVTUEktc3Bl Y2lmaWMgYmVoYXZpb3IgZm9yIGd1ZXN0IGRvbWFpbnMuDQo+PiBUaGUgaW1wbGVtZW50YXRpb24g aW5jbHVkZXMgcmVhZCBhbmQgd3JpdGUgZW11bGF0aW9uIGZvciBlU1BJLXJlbGF0ZWQNCj4+IHJl Z2lzdGVycyAoZS5nLiwgR0lDRF9JU0VOQUJMRVJuRSwgR0lDRF9JUk9VVEVSbkUsIGFuZCBvdGhl cnMpLA0KPj4gZm9sbG93aW5nIGEgc2ltaWxhciBhcHByb2FjaCB0byB0aGUgaGFuZGxpbmcgb2Yg cmVndWxhciBTUElzLg0KPj4NCj4+IFRoZSBlU1BJIHJlZ2lzdGVycywgcHJldmlvdXNseSBsb2Nh dGVkIGluIHJlc2VydmVkIGFkZHJlc3MgcmFuZ2VzLA0KPj4gYXJlIG5vdyBhZGp1c3RlZCB0byBz dXBwb3J0IE1NSU8gcmVhZCBhbmQgd3JpdGUgb3BlcmF0aW9ucyBjb3JyZWN0bHkNCj4+IHdoZW4g Q09ORklHX0dJQ1YzX0VTUEkgaXMgZW5hYmxlZC4NCj4+DQo+PiBUaGUgYXZhaWxhYmlsaXR5IG9m IGVTUElzIGFuZCB0aGUgbnVtYmVyIG9mIGVtdWxhdGVkIGV4dGVuZGVkIFNQSXMNCj4+IGZvciBn dWVzdCBkb21haW5zIGlzIHJlcG9ydGVkIGJ5IHNldHRpbmcgdGhlIGFwcHJvcHJpYXRlIGJpdHMg aW4gdGhlDQo+PiBHSUNEX1RZUEVSIHJlZ2lzdGVyLCBiYXNlZCBvbiB0aGUgbnVtYmVyIG9mIGVT UElzIHJlcXVlc3RlZCBieSB0aGUNCj4+IGRvbWFpbiBhbmQgc3VwcG9ydGVkIGJ5IHRoZSBoYXJk d2FyZS4gSW4gY2FzZXMgd2hlcmUgdGhlIGNvbmZpZ3VyYXRpb24NCj4+IG9wdGlvbiBpcyBkaXNh YmxlZCwgdGhlIGhhcmR3YXJlIGRvZXMgbm90IHN1cHBvcnQgZVNQSXMsIG9yIHRoZSBkb21haW4N Cj4+IGRvZXMgbm90IHJlcXVlc3Qgc3VjaCBpbnRlcnJ1cHRzLCB0aGUgZnVuY3Rpb25hbGl0eSBy ZW1haW5zIHVuY2hhbmdlZC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBMZW9uaWQgS29tYXJpYW5z a3lpIDxsZW9uaWRfa29tYXJpYW5za3lpQGVwYW0uY29tPg0KPiANCj4gSSBoYXZlIGEgY291cGxl IG9mIGNvbW1lbnRzIGFib3V0IGNvZGluZyBzdHlsZSwgYnV0IGFwYXJ0IGZyb20gdGhhdCBpdA0K PiBsb29rcyByZWFsbHkgZ29vZC4gV2l0aCB0aGVzZSBpc3N1ZXMgZml4ZWQ6DQo+IA0KPiBSZXZp ZXdlZC1ieTogVm9sb2R5bXlyIEJhYmNodWsgPHZvbG9keW15cl9iYWJjaHVrQGVwYW0uY29tPg0K PiANCj4+DQo+PiAtLS0NCj4+IENoYW5nZXMgaW4gVjU6DQo+PiAtIHNpbmNlIGVTUEktc3BlY2lm aWMgZGVmaW5lcyBhbmQgbWFjcm9zIGFyZSBub3cgYXZhaWxhYmxlIGV2ZW4gd2hlbiB0aGUNCj4+ ICAgIGFwcHJvcHJpYXRlIGNvbmZpZyBpcyBkaXNhYmxlZCwgdGhpcyBhbGxvd3MgdXMgdG8gcmVt b3ZlIG1hbnkNCj4+ICAgICNpZmRlZiBndWFyZHMgYW5kIHJldXNlIHRoZSBleGlzdGluZyBjb2Rl IGZvciByZWd1bGFyIFNQSXMgZm9yIGVTUElzIGFzDQo+PiAgICB3ZWxsLCBhcyBlU1BJcyBhcmUg cHJvY2Vzc2VkIHNpbWlsYXJseS4gVGhpcyBpbXByb3ZlcyBjb2RlIHJlYWRhYmlsaXR5DQo+PiAg ICBhbmQgY29uc29saWRhdGVzIHRoZSByZWdpc3RlciByYW5nZXMgZm9yIFNQSXMgYW5kIGVTUElz IGluIGEgc2luZ2xlDQo+PiAgICBwbGFjZSwgc2ltcGxpZnlpbmcgZnV0dXJlIGNoYW5nZXMgb3Ig Zml4ZXMgZm9yIFNQSXMgYW5kIHRoZWlyDQo+PiAgICBjb3VudGVycGFydHMgZnJvbSB0aGUgZXh0 ZW5kZWQgcmFuZ2UNCj4+IC0gbW92ZWQgdmdpY19leHRfcmFua19vZmZzZXQoKSBmcm9tDQo+PiAg ICBbMDgvMTJdIHhlbi9hcm06IHZnaWM6IGFkZCByZXNvdXJjZSBtYW5hZ2VtZW50IGZvciBleHRl bmRlZCBTUElzDQo+PiAgICBhcyB0aGUgZnVuY3Rpb24gd2FzIHVudXNlZCBiZWZvcmUgdGhpcyBw YXRjaA0KPj4gLSBhZGRlZCBzdHViIGltcGxlbWVudGF0aW9uIG9mIHZnaWNfZXh0X3Jhbmtfb2Zm c2V0KCkgd2hlbiBDT05GSUdfR0lDVjNfRVNQST1uDQo+PiAtIHJlbW92ZWQgdW5uZWNlc3Nhcnkg ZGVmaW5lcyBmb3IgcmVzZXJ2ZWQgcmFuZ2VzLCB3aGljaCB3ZXJlIGludHJvZHVjZWQgaW4NCj4+ ICAgIFY0IHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mICNpZmRlZnMuIFRoZSBpc3N1ZSBpcyBub3cg cmVzb2x2ZWQgYnkNCj4+ICAgIGFsbG93aW5nIHRoZSB1c2Ugb2YgU1BJLXNwZWNpZmljIG9mZnNl dHMgYW5kIHJld29ya2luZyB0aGUgbG9naWMNCj4+DQo+PiBDaGFuZ2VzIGluIFY0Og0KPj4gLSBh ZGRlZCBtaXNzaW5nIFJBWiBhbmQgd3JpdGUgaWdub3JlIGVTUEktc3BlY2lmaWMgcmVnaXN0ZXJz IHJhbmdlczoNCj4+ICAgIEdJQ0RfTlNBQ1JuRSBhbmQgR0lDRF9JR1JQTU9EUm5FDQo+PiAtIGNo YW5nZWQgcHJldmlvdXNseSByZXNlcnZlZCByYW5nZSB0byBjb3ZlciBHSUNEX05TQUNSbkUgYW5k DQo+PiAgICBHSUNEX0lHUlBNT0RSbkUNCj4+IC0gaW50cm9kdWNlZCBHSUNEX1JFU0VSVkVEX1JB TkdFPG4+X1NUQVJUL0VORCBkZWZpbmVzIHRvIHJlbW92ZQ0KPj4gICAgaGFyZGNvZGVkIHZhbHVl cyBhbmQgcmVkdWNlIHRoZSBudW1iZXIgb2YgaWZkZWZzDQo+PiAtIGZpeGVkIHJlc2VydmVkIHJh bmdlcyB3aXRoIGVTUEkgb3B0aW9uIGVuYWJsZWQ6IGFkZGVkIG1pc3NpbmcgcmFuZ2UNCj4+ICAg IDB4MEYzMC0weDBGN0MNCj4+IC0gdXBkYXRlZCB0aGUgbG9naWMgZm9yIGRvbWFpbnMgdGhhdCBk byBub3Qgc3VwcG9ydCBlU1BJLCBidXQgWGVuIGlzDQo+PiAgICBjb21waWxlZCB3aXRoIHRoZSBl U1BJIG9wdGlvbi4gTm93LCBwcmlvciB0byBvdGhlciBNTUlPIGNoZWNrcywgd2UNCj4+ICAgIHZl cmlmeSB3aGV0aGVyIGVTUEkgaXMgYXZhaWxhYmxlIGZvciB0aGUgZG9tYWluIG9yIG5vdC4gSWYg bm90LCBpdA0KPj4gICAgYmVoYXZlcyBhcyBpdCBkb2VzIGN1cnJlbnRseSAtIFJBWiBhbmQgV0kN Cj4+IC0gZml4ZWQgcHJpbnQgZm9yIEdJQ0RfSUNBQ1RJVkVSbkUNCj4+IC0gZml4ZWQgbmV3IGxp bmVzIGZvcm1hdHRpbmcgZm9yIHN3aXRjaC1jYXNlDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMzoNCj4+ IC0gY2hhbmdlZCB2Z2ljX3N0b3JlX2lyb3V0ZXIgcGFyYW1ldGVycyAtIGluc3RlYWQgb2Ygb2Zm c2V0IHZpcnEgaXMNCj4+ICAgIHVzZWQsIHRvIHJlbW92ZSB0aGUgYWRkaXRpb25hbCBib29sIGVz cGkgcGFyYW1ldGVyIGFuZCBzaW1wbGlmeQ0KPj4gICAgY2hlY2tzLiBBbHNvLCBhZGp1c3RlZCBw YXJhbWV0ZXJzIGZvciByZWd1bGFyIFNQSS4gU2luY2UgdGhlIG9mZnNldA0KPj4gICAgcGFyYW1l dGVyIHdhcyB1c2VkIG9ubHkgZm9yIGNhbGN1bGF0aW5nIHZpcnEgbnVtYmVyIGFuZCB0aGVuIHJl dXNlZCBmb3INCj4+ICAgIGZpbmRpbmcgcmFuayBvZmZzZXQsIGl0IHdpbGwgbm90IGFmZmVjdCBm dW5jdGlvbmFsaXR5Lg0KPj4gLSBmaXhlZCBmb3JtYXR0aW5nIGZvciBnb3RvIGxhYmxlcyAtIGFk ZGVkIG5ld2xpbmVzIGFmdGVyIGNvbmRpdGlvbg0KPj4gLSBmaXhlZCBsb2dzIGZvciBHSUNEX0lT QUNUSVZFUm5FIGFuZCBHSUNEX0lDQUNUSVZFUm5FIGhhbmRsZXJzDQo+PiAtIHJlbW92ZWQgI2lm ZGVmcyBpbiAyIHBsYWNlcyB3aGVyZSB0aGV5IHdlcmUgYWRqYWNlbnQgYW5kIGNvdWxkIGJlIG1l cmdlZA0KPj4NCj4+IENoYW5nZXMgaW4gVjI6DQo+PiAtIGFkZCBtaXNzaW5nIHJhbmsgaW5kZXgg Y29udmVyc2lvbiBmb3IgcGVuZGluZyBhbmQgaW5mbGlnaHQgaXJxcw0KPj4gLS0tDQo+PiAgIHhl bi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmggfCAgIDQgKw0KPj4gICB4ZW4vYXJjaC9hcm0v dmdpYy12My5jICAgICAgICAgIHwgMTk4ICsrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0t DQo+PiAgIHhlbi9hcmNoL2FybS92Z2ljLmMgICAgICAgICAgICAgfCAgMjMgKysrKw0KPj4gICAz IGZpbGVzIGNoYW5nZWQsIDE5MiBpbnNlcnRpb25zKCspLCAzMyBkZWxldGlvbnMoLSkNCj4+DQo+ PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaCBiL3hlbi9hcmNo L2FybS9pbmNsdWRlL2FzbS92Z2ljLmgNCj4+IGluZGV4IDNhYTIyMTE0YmEuLjEwM2JjM2M3NGIg MTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oDQo+PiArKysg Yi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oDQo+PiBAQCAtMzE0LDYgKzMxNCwxMCBA QCBleHRlcm4gc3RydWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfcmFua19vZmZzZXQoc3RydWN0IHZj cHUgKnYsDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB1bnNpZ25lZCBpbnQgYiwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHVuc2lnbmVkIGludCBuLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHMpOw0KPj4gK2V4dGVybiBzdHJ1 Y3QgdmdpY19pcnFfcmFuayAqdmdpY19leHRfcmFua19vZmZzZXQoc3RydWN0IHZjcHUgKnYsDQo+ PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNp Z25lZCBpbnQgYiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVuc2lnbmVkIGludCBuLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHMpOw0KPj4gICBleHRlcm4gc3Ry dWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfcmFua19pcnEoc3RydWN0IHZjcHUgKnYsIHVuc2lnbmVk IGludCBpcnEpOw0KPj4gICBleHRlcm4gdm9pZCB2Z2ljX2Rpc2FibGVfaXJxcyhzdHJ1Y3QgdmNw dSAqdiwgdWludDMyX3QgciwgdW5zaWduZWQgaW50IG4pOw0KPj4gICBleHRlcm4gdm9pZCB2Z2lj X2VuYWJsZV9pcnFzKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCByLCB1bnNpZ25lZCBpbnQgbik7 DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3ZnaWMtdjMuYyBiL3hlbi9hcmNoL2FybS92 Z2ljLXYzLmMNCj4+IGluZGV4IDQzNjljNTUxNzcuLmI1ZDc2NmM5OGYgMTAwNjQ0DQo+PiAtLS0g YS94ZW4vYXJjaC9hcm0vdmdpYy12My5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdmdpYy12My5j DQo+PiBAQCAtMTExLDEzICsxMTEsMTAgQEAgc3RhdGljIHVpbnQ2NF90IHZnaWNfZmV0Y2hfaXJv dXRlcihzdHJ1Y3QgdmdpY19pcnFfcmFuayAqcmFuaywNCj4+ICAgICogTm90ZSB0aGUgb2Zmc2V0 IHdpbGwgYmUgYWxpZ25lZCB0byB0aGUgYXBwcm9wcmlhdGUgYm91bmRhcnkuDQo+PiAgICAqLw0K Pj4gICBzdGF0aWMgdm9pZCB2Z2ljX3N0b3JlX2lyb3V0ZXIoc3RydWN0IGRvbWFpbiAqZCwgc3Ry dWN0IHZnaWNfaXJxX3JhbmsgKnJhbmssDQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVuc2lnbmVkIGludCBvZmZzZXQsIHVpbnQ2NF90IGlyb3V0ZXIpDQo+PiArICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCB2aXJxLCB1aW50NjRfdCBpcm91dGVy KQ0KPj4gICB7DQo+PiAgICAgICBzdHJ1Y3QgdmNwdSAqbmV3X3ZjcHUsICpvbGRfdmNwdTsNCj4+ IC0gICAgdW5zaWduZWQgaW50IHZpcnE7DQo+PiAtDQo+PiAtICAgIC8qIFRoZXJlIGlzIDEgdklS USBwZXIgSVJPVVRFUiAqLw0KPj4gLSAgICB2aXJxID0gb2Zmc2V0IC8gTlJfQllURVNfUEVSX0lS T1VURVI7DQo+PiArICAgIHVuc2lnbmVkIGludCBvZmZzZXQ7DQo+PiAgIA0KPj4gICAgICAgLyoN Cj4+ICAgICAgICAqIFRoZSBJUk9VVEVSMC0zMSwgdXNlZCBmb3IgU0dJcy9QUElzLCBhcmUgcmVz ZXJ2ZWQgYW5kIHNob3VsZA0KPj4gQEAgLTY4NSwxMyArNjgyLDIwIEBAIHN0YXRpYyBpbnQgX192 Z2ljX3YzX2Rpc3RyX2NvbW1vbl9tbWlvX3JlYWQoY29uc3QgY2hhciAqbmFtZSwgc3RydWN0IHZj cHUgKnYsDQo+PiAgICAgICB7DQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUdST1VQUiwg R0lDRF9JR1JPVVBSTik6DQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUdSUE1PRFIsIEdJ Q0RfSUdSUE1PRFJOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUk9VUFJuRSwgR0lD RF9JR1JPVVBSbkVOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBNT0RSbkUsIEdJ Q0RfSUdSUE1PRFJuRU4pOg0KPj4gICAgICAgICAgIC8qIFdlIGRvIG5vdCBpbXBsZW1lbnQgc2Vj dXJpdHkgZXh0ZW5zaW9ucyBmb3IgZ3Vlc3RzLCByZWFkIHplcm8gKi8NCj4+ICAgICAgICAgICBp ZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCj4+ICAgICAgICAg ICBnb3RvIHJlYWRfYXNfemVybzsNCj4+ICAgDQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0Rf SVNFTkFCTEVSLCBHSUNEX0lTRU5BQkxFUk4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0Rf SVNFTkFCTEVSbkUsIEdJQ0RfSVNFTkFCTEVSbkVOKToNCj4+ICAgICAgICAgICBpZiAoIGRhYnQu c2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCj4+IC0gICAgICAgIHJhbmsgPSB2 Z2ljX3Jhbmtfb2Zmc2V0KHYsIDEsIHJlZyAtIEdJQ0RfSVNFTkFCTEVSLCBEQUJUX1dPUkQpOw0K Pj4gKyAgICAgICAgaWYgKCByZWcgPj0gR0lDRF9JU0VOQUJMRVJuRSApDQo+PiArICAgICAgICAg ICAgcmFuayA9IHZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHYsIDEsIHJlZyAtIEdJQ0RfSVNFTkFCTEVS bkUsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERBQlRfV09S RCk7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAgcmFuayA9IHZnaWNfcmFua19v ZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU0VOQUJMRVIsIERBQlRfV09SRCk7DQo+PiAgICAgICAg ICAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHJlYWRfYXNfemVybzsNCj4+ICAgICAgICAgICB2 Z2ljX2xvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+PiAgICAgICAgICAgKnIgPSB2cmVnX3Jl ZzMyX2V4dHJhY3QocmFuay0+aWVuYWJsZSwgaW5mbyk7DQo+PiBAQCAtNjk5LDggKzcwMywxMyBA QCBzdGF0aWMgaW50IF9fdmdpY192M19kaXN0cl9jb21tb25fbW1pb19yZWFkKGNvbnN0IGNoYXIg Km5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gICAgICAgICAgIHJldHVybiAxOw0KPj4gICANCj4+ ICAgICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0VOQUJMRVIsIEdJQ0RfSUNFTkFCTEVSTik6DQo+ PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0VOQUJMRVJuRSwgR0lDRF9JQ0VOQUJMRVJuRU4p Og0KPj4gICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dp ZHRoOw0KPj4gLSAgICAgICAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lD RF9JQ0VOQUJMRVIsIERBQlRfV09SRCk7DQo+PiArICAgICAgICBpZiAoIHJlZyA+PSBHSUNEX0lD RU5BQkxFUm5FICkNCj4+ICsgICAgICAgICAgICByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQo diwgMSwgcmVnIC0gR0lDRF9JQ0VOQUJMRVJuRSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgREFCVF9XT1JEKTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAg ICAgICAgICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lDRU5BQkxF UiwgREFCVF9XT1JEKTsNCj4+ICAgICAgICAgICBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8gcmVh ZF9hc196ZXJvOw0KPj4gICAgICAgICAgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdzKTsN Cj4+ICAgICAgICAgICAqciA9IHZyZWdfcmVnMzJfZXh0cmFjdChyYW5rLT5pZW5hYmxlLCBpbmZv KTsNCj4+IEBAIC03MTAsMjAgKzcxOSwyOSBAQCBzdGF0aWMgaW50IF9fdmdpY192M19kaXN0cl9j b21tb25fbW1pb19yZWFkKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gICAg ICAgLyogUmVhZCB0aGUgcGVuZGluZyBzdGF0dXMgb2YgYW4gSVJRIHZpYSBHSUNEL0dJQ1IgaXMg bm90IHN1cHBvcnRlZCAqLw0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lTUEVORFIsIEdJ Q0RfSVNQRU5EUk4pOg0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lDUEVORFIsIEdJQ0Rf SUNQRU5EUk4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSVNQRU5EUm5FLCBHSUNEX0lT UEVORFJuRU4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNQRU5EUm5FLCBHSUNEX0lD UEVORFJuRU4pOg0KPj4gICAgICAgICAgIGdvdG8gcmVhZF9hc196ZXJvOw0KPj4gICANCj4+ICAg ICAgIC8qIFJlYWQgdGhlIGFjdGl2ZSBzdGF0dXMgb2YgYW4gSVJRIHZpYSBHSUNEL0dJQ1IgaXMg bm90IHN1cHBvcnRlZCAqLw0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lTQUNUSVZFUiwg R0lDRF9JU0FDVElWRVJOKToNCj4+ICAgICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0FDVElWRVIs IEdJQ0RfSUNBQ1RJVkVSTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0FDVElWRVJu RSwgR0lDRF9JU0FDVElWRVJuRU4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNBQ1RJ VkVSbkUsIEdJQ0RfSUNBQ1RJVkVSbkVOKToNCj4+ICAgICAgICAgICBnb3RvIHJlYWRfYXNfemVy bzsNCj4+ICAgDQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSVBSSU9SSVRZUiwgR0lDRF9J UFJJT1JJVFlSTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JUFJJT1JJVFlSbkUsIEdJ Q0RfSVBSSU9SSVRZUm5FTik6DQo+PiAgICAgICB7DQo+PiAgICAgICAgICAgdWludDMyX3QgaXBy aW9yaXR5cjsNCj4+ICAgICAgICAgICB1aW50OF90IHJhbmtfaW5kZXg7DQo+PiAgIA0KPj4gICAg ICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfQllURSAmJiBkYWJ0LnNpemUgIT0gREFCVF9X T1JEICkgZ290byBiYWRfd2lkdGg7DQo+PiAtICAgICAgICByYW5rID0gdmdpY19yYW5rX29mZnNl dCh2LCA4LCByZWcgLSBHSUNEX0lQUklPUklUWVIsIERBQlRfV09SRCk7DQo+PiArICAgICAgICBp ZiAoIHJlZyA+PSBHSUNEX0lQUklPUklUWVJuRSApDQo+PiArICAgICAgICAgICAgcmFuayA9IHZn aWNfZXh0X3Jhbmtfb2Zmc2V0KHYsIDgsIHJlZyAtIEdJQ0RfSVBSSU9SSVRZUm5FLA0KPj4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEQUJUX1dPUkQpOw0KPj4gKyAg ICAgICAgZWxzZQ0KPj4gKyAgICAgICAgICAgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDgs IHJlZyAtIEdJQ0RfSVBSSU9SSVRZUiwgREFCVF9XT1JEKTsNCj4+ICAgICAgICAgICBpZiAoIHJh bmsgPT0gTlVMTCApIGdvdG8gcmVhZF9hc196ZXJvOw0KPj4gICAgICAgICAgIHJhbmtfaW5kZXgg PSBSRUdfUkFOS19JTkRFWCg4LCByZWcgLSBHSUNEX0lQUklPUklUWVIsIERBQlRfV09SRCk7DQo+ PiAgIA0KPj4gQEAgLTczNywxMSArNzU1LDE1IEBAIHN0YXRpYyBpbnQgX192Z2ljX3YzX2Rpc3Ry X2NvbW1vbl9tbWlvX3JlYWQoY29uc3QgY2hhciAqbmFtZSwgc3RydWN0IHZjcHUgKnYsDQo+PiAg ICAgICB9DQo+PiAgIA0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lDRkdSLCBHSUNEX0lD RkdSTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0ZHUm5FLCBHSUNEX0lDRkdSbkVO KToNCj4+ICAgICAgIHsNCj4+ICAgICAgICAgICB1aW50MzJfdCBpY2ZncjsNCj4+ICAgDQo+PiAg ICAgICAgICAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQo+ PiAtICAgICAgICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAyLCByZWcgLSBHSUNEX0lDRkdS LCBEQUJUX1dPUkQpOw0KPj4gKyAgICAgICAgaWYgKCByZWcgPj0gR0lDRF9JQ0ZHUm5FICkNCj4+ ICsgICAgICAgICAgICByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgMiwgcmVnIC0gR0lD RF9JQ0ZHUm5FLCBEQUJUX1dPUkQpOw0KPj4gKyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAgICAg IHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDIsIHJlZyAtIEdJQ0RfSUNGR1IsIERBQlRfV09S RCk7DQo+PiAgICAgICAgICAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHJlYWRfYXNfemVybzsN Cj4+ICAgICAgICAgICB2Z2ljX2xvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+PiAgICAgICAg ICAgaWNmZ3IgPSByYW5rLT5pY2ZnW1JFR19SQU5LX0lOREVYKDIsIHJlZyAtIEdJQ0RfSUNGR1Is IERBQlRfV09SRCldOw0KPj4gQEAgLTc4Miw0NiArODA0LDgxIEBAIHN0YXRpYyBpbnQgX192Z2lj X3YzX2Rpc3RyX2NvbW1vbl9tbWlvX3dyaXRlKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1 ICp2LA0KPj4gICAgICAgew0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUk9VUFIsIEdJ Q0RfSUdST1VQUk4pOg0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBNT0RSLCBHSUNE X0lHUlBNT0RSTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSbkUsIEdJQ0Rf SUdST1VQUm5FTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JQTU9EUm5FLCBHSUNE X0lHUlBNT0RSbkVOKToNCj4+ICAgICAgICAgICAvKiBXZSBkbyBub3QgaW1wbGVtZW50IHNlY3Vy aXR5IGV4dGVuc2lvbnMgZm9yIGd1ZXN0cywgd3JpdGUgaWdub3JlICovDQo+PiAgICAgICAgICAg Z290byB3cml0ZV9pZ25vcmVfMzI7DQo+PiAgIA0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNE X0lTRU5BQkxFUiwgR0lDRF9JU0VOQUJMRVJOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNE X0lTRU5BQkxFUm5FLCBHSUNEX0lTRU5BQkxFUm5FTik6DQo+PiAgICAgICAgICAgaWYgKCBkYWJ0 LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQo+PiAtICAgICAgICByYW5rID0g dmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTRU5BQkxFUiwgREFCVF9XT1JEKTsN Cj4+ICsgICAgICAgIGlmICggcmVnID49IEdJQ0RfSVNFTkFCTEVSbkUgKQ0KPj4gKyAgICAgICAg ICAgIHJhbmsgPSB2Z2ljX2V4dF9yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTRU5BQkxF Um5FLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEQUJUX1dP UkQpOw0KPj4gKyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAgICAgIHJhbmsgPSB2Z2ljX3Jhbmtf b2Zmc2V0KHYsIDEsIHJlZyAtIEdJQ0RfSVNFTkFCTEVSLCBEQUJUX1dPUkQpOw0KPj4gICAgICAg ICAgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3cml0ZV9pZ25vcmU7DQo+PiAgICAgICAgICAg dmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3MpOw0KPj4gICAgICAgICAgIHRyID0gcmFuay0+ aWVuYWJsZTsNCj4+ICAgICAgICAgICB2cmVnX3JlZzMyX3NldGJpdHMoJnJhbmstPmllbmFibGUs IHIsIGluZm8pOw0KPj4gLSAgICAgICAgdmdpY19lbmFibGVfaXJxcyh2LCAocmFuay0+aWVuYWJs ZSkgJiAofnRyKSwgcmFuay0+aW5kZXgpOw0KPj4gKyAgICAgICAgaWYgKCByZWcgPj0gR0lDRF9J U0VOQUJMRVJuRSApDQo+PiArICAgICAgICAgICAgdmdpY19lbmFibGVfaXJxcyh2LCAocmFuay0+ aWVuYWJsZSkgJiAofnRyKSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVYVF9S QU5LX0lEWDJOVU0ocmFuay0+aW5kZXgpKTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAg ICAgICB2Z2ljX2VuYWJsZV9pcnFzKHYsIChyYW5rLT5pZW5hYmxlKSAmICh+dHIpLCByYW5rLT5p bmRleCk7DQo+PiAgICAgICAgICAgdmdpY191bmxvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+ PiAgICAgICAgICAgcmV0dXJuIDE7DQo+PiAgIA0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNE X0lDRU5BQkxFUiwgR0lDRF9JQ0VOQUJMRVJOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNE X0lDRU5BQkxFUm5FLCBHSUNEX0lDRU5BQkxFUm5FTik6DQo+PiAgICAgICAgICAgaWYgKCBkYWJ0 LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQo+PiAtICAgICAgICByYW5rID0g dmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lDRU5BQkxFUiwgREFCVF9XT1JEKTsN Cj4+ICsgICAgICAgIGlmICggcmVnID49IEdJQ0RfSUNFTkFCTEVSbkUgKQ0KPj4gKyAgICAgICAg ICAgIHJhbmsgPSB2Z2ljX2V4dF9yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lDRU5BQkxF Um5FLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEQUJUX1dP UkQpOw0KPj4gKyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAgICAgIHJhbmsgPSB2Z2ljX3Jhbmtf b2Zmc2V0KHYsIDEsIHJlZyAtIEdJQ0RfSUNFTkFCTEVSLCBEQUJUX1dPUkQpOw0KPj4gICAgICAg ICAgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3cml0ZV9pZ25vcmU7DQo+PiAgICAgICAgICAg dmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3MpOw0KPj4gICAgICAgICAgIHRyID0gcmFuay0+ aWVuYWJsZTsNCj4+ICAgICAgICAgICB2cmVnX3JlZzMyX2NsZWFyYml0cygmcmFuay0+aWVuYWJs ZSwgciwgaW5mbyk7DQo+PiAtICAgICAgICB2Z2ljX2Rpc2FibGVfaXJxcyh2LCAofnJhbmstPmll bmFibGUpICYgdHIsIHJhbmstPmluZGV4KTsNCj4+ICsgICAgICAgIGlmICggcmVnID49IEdJQ0Rf SUNFTkFCTEVSbkUgKQ0KPj4gKyAgICAgICAgICAgIHZnaWNfZGlzYWJsZV9pcnFzKHYsICh+cmFu ay0+aWVuYWJsZSkgJiB0ciwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFWFRf UkFOS19JRFgyTlVNKHJhbmstPmluZGV4KSk7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAg ICAgICAgdmdpY19kaXNhYmxlX2lycXModiwgKH5yYW5rLT5pZW5hYmxlKSAmIHRyLCByYW5rLT5p bmRleCk7DQo+PiAgICAgICAgICAgdmdpY191bmxvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+ PiAgICAgICAgICAgcmV0dXJuIDE7DQo+PiAgIA0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNE X0lTUEVORFIsIEdJQ0RfSVNQRU5EUk4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSVNQ RU5EUm5FLCBHSUNEX0lTUEVORFJuRU4pOg0KPj4gICAgICAgICAgIGlmICggZGFidC5zaXplICE9 IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KPj4gLSAgICAgICAgcmFuayA9IHZnaWNfcmFu a19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU1BFTkRSLCBEQUJUX1dPUkQpOw0KPj4gKyAgICAg ICAgaWYgKCByZWcgPj0gR0lDRF9JU1BFTkRSbkUgKQ0KPj4gKyAgICAgICAgICAgIHJhbmsgPSB2 Z2ljX2V4dF9yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTUEVORFJuRSwgREFCVF9XT1JE KTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAgICAgICByYW5rID0gdmdpY19yYW5rX29m ZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTUEVORFIsIERBQlRfV09SRCk7DQo+PiAgICAgICAgICAg aWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHdyaXRlX2lnbm9yZTsNCj4+ICAgDQo+PiAtICAgICAg ICB2Z2ljX3NldF9pcnFzX3BlbmRpbmcodiwgciwgcmFuay0+aW5kZXgpOw0KPj4gKyAgICAgICAg aWYgKCByZWcgPj0gR0lDRF9JU1BFTkRSbkUgKQ0KPj4gKyAgICAgICAgICAgIHZnaWNfc2V0X2ly cXNfcGVuZGluZyh2LCByLCBFWFRfUkFOS19JRFgyTlVNKHJhbmstPmluZGV4KSk7DQo+PiArICAg ICAgICBlbHNlDQo+PiArICAgICAgICAgICAgdmdpY19zZXRfaXJxc19wZW5kaW5nKHYsIHIsIHJh bmstPmluZGV4KTsNCj4+ICAgDQo+PiAgICAgICAgICAgcmV0dXJuIDE7DQo+PiAgIA0KPj4gICAg ICAgY2FzZSBWUkFOR0UzMihHSUNEX0lDUEVORFIsIEdJQ0RfSUNQRU5EUk4pOg0KPj4gKyAgICBj YXNlIFZSQU5HRTMyKEdJQ0RfSUNQRU5EUm5FLCBHSUNEX0lDUEVORFJuRU4pOg0KPj4gICAgICAg ICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KPj4gLSAg ICAgICAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JQ1BFTkRSLCBE QUJUX1dPUkQpOw0KPj4gKyAgICAgICAgaWYgKCByZWcgPj0gR0lDRF9JQ1BFTkRSbkUgKQ0KPj4g KyAgICAgICAgICAgIHJhbmsgPSB2Z2ljX2V4dF9yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNE X0lDUEVORFJuRSwgREFCVF9XT1JEKTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAgICAg ICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lDUEVORFIsIERBQlRf V09SRCk7DQo+PiAgICAgICAgICAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHdyaXRlX2lnbm9y ZTsNCj4+ICAgDQo+PiAtICAgICAgICB2Z2ljX2NoZWNrX2luZmxpZ2h0X2lycXNfcGVuZGluZyh2 LCByYW5rLT5pbmRleCwgcik7DQo+PiArICAgICAgICBpZiAoIHJlZyA+PSBHSUNEX0lDUEVORFJu RSApDQo+PiArICAgICAgICAgICAgdmdpY19jaGVja19pbmZsaWdodF9pcnFzX3BlbmRpbmcodiwN Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFWFRfUkFO S19JRFgyTlVNKHJhbmstPmluZGV4KSwgcik7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAg ICAgICAgdmdpY19jaGVja19pbmZsaWdodF9pcnFzX3BlbmRpbmcodiwgcmFuay0+aW5kZXgsIHIp Ow0KPj4gICANCj4+ICAgICAgICAgICBnb3RvIHdyaXRlX2lnbm9yZTsNCj4+ICAgDQo+PiBAQCAt ODM4LDE2ICs4OTUsMzggQEAgc3RhdGljIGludCBfX3ZnaWNfdjNfZGlzdHJfY29tbW9uX21taW9f d3JpdGUoY29uc3QgY2hhciAqbmFtZSwgc3RydWN0IHZjcHUgKnYsDQo+PiAgICAgICAgICAgICAg ICAgIHYsIG5hbWUsIHIsIHJlZyAtIEdJQ0RfSUNBQ1RJVkVSKTsNCj4+ICAgICAgICAgICBnb3Rv IHdyaXRlX2lnbm9yZV8zMjsNCj4+ICAgDQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0FD VElWRVJuRSwgR0lDRF9JU0FDVElWRVJuRU4pOg0KPj4gKyAgICAgICAgaWYgKCBkYWJ0LnNpemUg IT0gREFCVF9XT1JEICkNCj4+ICsgICAgICAgICAgICBnb3RvIGJhZF93aWR0aDsNCj4+ICsgICAg ICAgIHByaW50ayhYRU5MT0dfR19FUlINCj4+ICsgICAgICAgICAgICAgICAiJXB2OiAlczogdW5o YW5kbGVkIHdvcmQgd3JpdGUgJSMiUFJJcmVnaXN0ZXIiIHRvIElTQUNUSVZFUiVkRVxuIiwNCj4+ ICsgICAgICAgICAgICAgICB2LCBuYW1lLCByLCByZWcgLSBHSUNEX0lTQUNUSVZFUm5FKTsNCj4+ ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNB Q1RJVkVSbkUsIEdJQ0RfSUNBQ1RJVkVSbkVOKToNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0df R19FUlINCj4+ICsgICAgICAgICAgICAgICAiJXB2OiAlczogdW5oYW5kbGVkIHdvcmQgd3JpdGUg JSMiUFJJcmVnaXN0ZXIiIHRvIElDQUNUSVZFUiVkRVxuIiwNCj4+ICsgICAgICAgICAgICAgICB2 LCBuYW1lLCByLCByZWcgLSBHSUNEX0lDQUNUSVZFUm5FKTsNCj4+ICsgICAgICAgIGdvdG8gd3Jp dGVfaWdub3JlXzMyOw0KPj4gKw0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lQUklPUklU WVIsIEdJQ0RfSVBSSU9SSVRZUk4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSVBSSU9S SVRZUm5FLCBHSUNEX0lQUklPUklUWVJuRU4pOg0KPj4gICAgICAgew0KPj4gLSAgICAgICAgdWlu dDMyX3QgKmlwcmlvcml0eXIsIHByaW9yaXR5Ow0KPj4gKyAgICAgICAgdWludDMyX3QgKmlwcmlv cml0eXIsIHByaW9yaXR5LCBvZmZzZXQ7DQo+PiAgIA0KPj4gICAgICAgICAgIGlmICggZGFidC5z aXplICE9IERBQlRfQllURSAmJiBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lk dGg7DQo+PiAtICAgICAgICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCA4LCByZWcgLSBHSUNE X0lQUklPUklUWVIsIERBQlRfV09SRCk7DQo+PiArICAgICAgICBpZiAoIHJlZyA+PSBHSUNEX0lQ UklPUklUWVJuRSApIHsNCj4gDQo+IEJyYWNlIHNob3VsZCBnbyBvbiBuZXcgbGluZQ0KPiANCj4+ ICsgICAgICAgICAgICBvZmZzZXQgPSByZWcgLSBHSUNEX0lQUklPUklUWVJuRTsNCj4+ICsgICAg ICAgICAgICByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgOCwgb2Zmc2V0LCBEQUJUX1dP UkQpOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAgew0KPj4g KyAgICAgICAgICAgIG9mZnNldCA9IHJlZyAtIEdJQ0RfSVBSSU9SSVRZUjsNCj4+ICsgICAgICAg ICAgICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCA4LCBvZmZzZXQsIERBQlRfV09SRCk7DQo+ PiArICAgICAgICB9DQo+PiAgICAgICAgICAgaWYgKCByYW5rID09IE5VTEwgKSBnb3RvIHdyaXRl X2lnbm9yZTsNCj4+ICAgICAgICAgICB2Z2ljX2xvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7DQo+ PiAtICAgICAgICBpcHJpb3JpdHlyID0gJnJhbmstPmlwcmlvcml0eXJbUkVHX1JBTktfSU5ERVgo OCwgcmVnIC0gR0lDRF9JUFJJT1JJVFlSLA0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIERBQlRfV09SRCldOw0KPj4gKyAgICAgICAgaXBy aW9yaXR5ciA9ICZyYW5rLT5pcHJpb3JpdHlyW1JFR19SQU5LX0lOREVYKDgsIG9mZnNldCwgREFC VF9XT1JEKV07DQo+PiAgICAgICAgICAgcHJpb3JpdHkgPSBBQ0NFU1NfT05DRSgqaXByaW9yaXR5 cik7DQo+PiAgICAgICAgICAgdnJlZ19yZWczMl91cGRhdGUoJnByaW9yaXR5LCByLCBpbmZvKTsN Cj4+ICAgICAgICAgICBBQ0NFU1NfT05DRSgqaXByaW9yaXR5cikgPSBwcmlvcml0eTsNCj4+IEBA IC04NTksMTAgKzkzOCwxNCBAQCBzdGF0aWMgaW50IF9fdmdpY192M19kaXN0cl9jb21tb25fbW1p b193cml0ZShjb25zdCBjaGFyICpuYW1lLCBzdHJ1Y3QgdmNwdSAqdiwNCj4+ICAgICAgICAgICBn b3RvIHdyaXRlX2lnbm9yZV8zMjsNCj4+ICAgDQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0Rf SUNGR1IgKyA0LCBHSUNEX0lDRkdSTik6IC8qIFBQSSArIFNQSXMgKi8NCj4+ICsgICAgY2FzZSBW UkFOR0UzMihHSUNEX0lDRkdSbkUsIEdJQ0RfSUNGR1JuRU4pOg0KPj4gICAgICAgICAgIC8qIElD RkdSMSBmb3IgUFBJJ3MsIHdoaWNoIGlzIGltcGxlbWVudGF0aW9uIGRlZmluZWQNCj4+ICAgICAg ICAgICAgICBpZiBJQ0ZHUjEgaXMgcHJvZ3JhbW1hYmxlIG9yIG5vdC4gV2UgY2hvc2UgdG8gcHJv Z3JhbSAqLw0KPj4gICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8g YmFkX3dpZHRoOw0KPj4gLSAgICAgICAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwgMiwgcmVn IC0gR0lDRF9JQ0ZHUiwgREFCVF9XT1JEKTsNCj4+ICsgICAgICAgIGlmICggcmVnID49IEdJQ0Rf SUNGR1JuRSApDQo+PiArICAgICAgICAgICAgcmFuayA9IHZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHYs IDIsIHJlZyAtIEdJQ0RfSUNGR1JuRSwgREFCVF9XT1JEKTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ ICsgICAgICAgICAgICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAyLCByZWcgLSBHSUNEX0lD RkdSLCBEQUJUX1dPUkQpOw0KPj4gICAgICAgICAgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3 cml0ZV9pZ25vcmU7DQo+PiAgICAgICAgICAgdmdpY19sb2NrX3JhbmsodiwgcmFuaywgZmxhZ3Mp Ow0KPj4gICAgICAgICAgIHZyZWdfcmVnMzJfdXBkYXRlKCZyYW5rLT5pY2ZnW1JFR19SQU5LX0lO REVYKDIsIHJlZyAtIEdJQ0RfSUNGR1IsDQo+PiBAQCAtMTEyOSw2ICsxMjEyLDE2IEBAIHN0YXRp YyBpbnQgdmdpY192M19kaXN0cl9tbWlvX3JlYWQoc3RydWN0IHZjcHUgKnYsIG1taW9faW5mb190 ICppbmZvLA0KPj4gICAgICAgICAgICAgICB0eXBlciB8PSBHSUNEX1RZUEVfTFBJUzsNCj4+ICAg DQo+PiAgICAgICAgICAgdHlwZXIgfD0gKHYtPmRvbWFpbi0+YXJjaC52Z2ljLmludGlkX2JpdHMg LSAxKSA8PCBHSUNEX1RZUEVfSURfQklUU19TSElGVDsNCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1Yz X0VTUEkNCj4+ICsgICAgICAgIGlmICggdi0+ZG9tYWluLT5hcmNoLnZnaWMubnJfZXNwaXMgPiAw ICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICAvKiBTZXQgZVNQSSBzdXBwb3J0IGJp dCBmb3IgdGhlIGRvbWFpbiAqLw0KPj4gKyAgICAgICAgICAgIHR5cGVyIHw9IEdJQ0RfVFlQRVJf RVNQSTsNCj4+ICsgICAgICAgICAgICAvKiBTZXQgRVNQSSByYW5nZSBiaXRzICovDQo+PiArICAg ICAgICAgICAgdHlwZXIgfD0gKERJVl9ST1VORF9VUCh2LT5kb21haW4tPmFyY2gudmdpYy5ucl9l c3BpcywgMzIpIC0gMSkNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgIDw8IEdJQ0RfVFlQRVJf RVNQSV9SQU5HRV9TSElGVDsNCj4+ICsgICAgICAgIH0NCj4+ICsjZW5kaWYNCj4+ICAgDQo+PiAg ICAgICAgICAgKnIgPSB2cmVnX3JlZzMyX2V4dHJhY3QodHlwZXIsIGluZm8pOw0KPj4gICANCj4+ IEBAIC0xMTk0LDYgKzEyODcsMTYgQEAgc3RhdGljIGludCB2Z2ljX3YzX2Rpc3RyX21taW9fcmVh ZChzdHJ1Y3QgdmNwdSAqdiwgbW1pb19pbmZvX3QgKmluZm8sDQo+PiAgICAgICBjYXNlIFZSQU5H RTMyKEdJQ0RfSVBSSU9SSVRZUiwgR0lDRF9JUFJJT1JJVFlSTik6DQo+PiAgICAgICBjYXNlIFZS QU5HRTMyKEdJQ0RfSUNGR1IsIEdJQ0RfSUNGR1JOKToNCj4+ICAgICAgIGNhc2UgVlJBTkdFMzIo R0lDRF9JR1JQTU9EUiwgR0lDRF9JR1JQTU9EUk4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJ Q0RfSUdST1VQUm5FLCBHSUNEX0lHUk9VUFJuRU4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJ Q0RfSVNFTkFCTEVSbkUsIEdJQ0RfSVNFTkFCTEVSbkVOKToNCj4+ICsgICAgY2FzZSBWUkFOR0Uz MihHSUNEX0lDRU5BQkxFUm5FLCBHSUNEX0lDRU5BQkxFUm5FTik6DQo+PiArICAgIGNhc2UgVlJB TkdFMzIoR0lDRF9JU1BFTkRSbkUsIEdJQ0RfSVNQRU5EUm5FTik6DQo+PiArICAgIGNhc2UgVlJB TkdFMzIoR0lDRF9JQ1BFTkRSbkUsIEdJQ0RfSUNQRU5EUm5FTik6DQo+PiArICAgIGNhc2UgVlJB TkdFMzIoR0lDRF9JU0FDVElWRVJuRSwgR0lDRF9JU0FDVElWRVJuRU4pOg0KPj4gKyAgICBjYXNl IFZSQU5HRTMyKEdJQ0RfSUNBQ1RJVkVSbkUsIEdJQ0RfSUNBQ1RJVkVSbkVOKToNCj4+ICsgICAg Y2FzZSBWUkFOR0UzMihHSUNEX0lQUklPUklUWVJuRSwgR0lDRF9JUFJJT1JJVFlSbkVOKToNCj4+ ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lDRkdSbkUsIEdJQ0RfSUNGR1JuRU4pOg0KPj4gKyAg ICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUdSUE1PRFJuRSwgR0lDRF9JR1JQTU9EUm5FTik6DQo+PiAg ICAgICAgICAgLyoNCj4+ICAgICAgICAgICAgKiBBYm92ZSBhbGwgcmVnaXN0ZXIgYXJlIGNvbW1v biB3aXRoIEdJQ1IgYW5kIEdJQ0QNCj4+ICAgICAgICAgICAgKiBNYW5hZ2UgaW4gY29tbW9uDQo+ PiBAQCAtMTIwMSw2ICsxMzA0LDcgQEAgc3RhdGljIGludCB2Z2ljX3YzX2Rpc3RyX21taW9fcmVh ZChzdHJ1Y3QgdmNwdSAqdiwgbW1pb19pbmZvX3QgKmluZm8sDQo+PiAgICAgICAgICAgcmV0dXJu IF9fdmdpY192M19kaXN0cl9jb21tb25fbW1pb19yZWFkKCJ2R0lDRCIsIHYsIGluZm8sIGdpY2Rf cmVnLCByKTsNCj4+ICAgDQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfTlNBQ1IsIEdJQ0Rf TlNBQ1JOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX05TQUNSbkUsIEdJQ0RfTlNBQ1Ju RU4pOg0KPj4gICAgICAgICAgIC8qIFdlIGRvIG5vdCBpbXBsZW1lbnQgc2VjdXJpdHkgZXh0ZW5z aW9ucyBmb3IgZ3Vlc3RzLCByZWFkIHplcm8gKi8NCj4+ICAgICAgICAgICBnb3RvIHJlYWRfYXNf emVyb18zMjsNCj4+ICAgDQo+PiBAQCAtMTIxNiwxNiArMTMyMCwyMSBAQCBzdGF0aWMgaW50IHZn aWNfdjNfZGlzdHJfbW1pb19yZWFkKHN0cnVjdCB2Y3B1ICp2LCBtbWlvX2luZm9fdCAqaW5mbywN Cj4+ICAgICAgICAgICAvKiBSZXBsYWNlZCB3aXRoIEdJQ1JfSVNQRU5EUjAuIFNvIGlnbm9yZSB3 cml0ZSAqLw0KPj4gICAgICAgICAgIGdvdG8gcmVhZF9hc196ZXJvXzMyOw0KPj4gICANCj4+IC0g ICAgY2FzZSBWUkFOR0UzMigweDBGMzAsIDB4NjBGQyk6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIo MHgwRjMwLCAweDBGRkMpOg0KPj4gICAgICAgICAgIGdvdG8gcmVhZF9yZXNlcnZlZDsNCj4+ICAg DQo+PiAgICAgICBjYXNlIFZSQU5HRTY0KEdJQ0RfSVJPVVRFUjMyLCBHSUNEX0lST1VURVIxMDE5 KToNCj4+ICsgICAgY2FzZSBWUkFOR0U2NChHSUNEX0lST1VURVJuRSwgR0lDRF9JUk9VVEVSbkVO KToNCj4+ICAgICAgIHsNCj4+ICAgICAgICAgICB1aW50NjRfdCBpcm91dGVyOw0KPj4gICANCj4+ ICAgICAgICAgICBpZiAoICF2Z2ljX3JlZzY0X2NoZWNrX2FjY2VzcyhkYWJ0KSApIGdvdG8gYmFk X3dpZHRoOw0KPj4gLSAgICAgICAgcmFuayA9IHZnaWNfcmFua19vZmZzZXQodiwgNjQsIGdpY2Rf cmVnIC0gR0lDRF9JUk9VVEVSLA0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg REFCVF9ET1VCTEVfV09SRCk7DQo+PiArICAgICAgICBpZiAoIGdpY2RfcmVnID49IEdJQ0RfSVJP VVRFUm5FICkNCj4+ICsgICAgICAgICAgICByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwg NjQsIGdpY2RfcmVnIC0gR0lDRF9JUk9VVEVSbkUsDQo+PiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIERBQlRfRE9VQkxFX1dPUkQpOw0KPj4gKyAgICAgICAgZWxzZQ0K Pj4gKyAgICAgICAgICAgIHJhbmsgPSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDY0LCBnaWNkX3JlZyAt IEdJQ0RfSVJPVVRFUiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBE QUJUX0RPVUJMRV9XT1JEKTsNCj4+ICAgICAgICAgICBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8g cmVhZF9hc196ZXJvOw0KPj4gICAgICAgICAgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdz KTsNCj4+ICAgICAgICAgICBpcm91dGVyID0gdmdpY19mZXRjaF9pcm91dGVyKHJhbmssIGdpY2Rf cmVnIC0gR0lDRF9JUk9VVEVSKTsNCj4+IEBAIC0xMjM1LDggKzEzNDQsOCBAQCBzdGF0aWMgaW50 IHZnaWNfdjNfZGlzdHJfbW1pb19yZWFkKHN0cnVjdCB2Y3B1ICp2LCBtbWlvX2luZm9fdCAqaW5m bywNCj4+ICAgDQo+PiAgICAgICAgICAgcmV0dXJuIDE7DQo+PiAgICAgICB9DQo+PiAtDQo+PiAt ICAgIGNhc2UgVlJBTkdFMzIoMHg3RkUwLCAweEJGRkMpOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMy KDB4MzcwMCwgMHg2MEZDKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMigweEEwMDQsIDB4QkZGQyk6 DQo+PiAgICAgICAgICAgZ290byByZWFkX3Jlc2VydmVkOw0KPj4gICANCj4+ICAgICAgIGNhc2Ug VlJBTkdFMzIoMHhDMDAwLCAweEZGQ0MpOg0KPj4gQEAgLTEzODIsMTIgKzE0OTEsMjMgQEAgc3Rh dGljIGludCB2Z2ljX3YzX2Rpc3RyX21taW9fd3JpdGUoc3RydWN0IHZjcHUgKnYsIG1taW9faW5m b190ICppbmZvLA0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lQUklPUklUWVIsIEdJQ0Rf SVBSSU9SSVRZUk4pOg0KPj4gICAgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lDRkdSLCBHSUNEX0lD RkdSTik6DQo+PiAgICAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUdSUE1PRFIsIEdJQ0RfSUdSUE1P RFJOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUk9VUFJuRSwgR0lDRF9JR1JPVVBS bkVOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUm5FLCBHSUNEX0lTRU5B QkxFUm5FTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JQ0VOQUJMRVJuRSwgR0lDRF9J Q0VOQUJMRVJuRU4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSVNQRU5EUm5FLCBHSUNE X0lTUEVORFJuRU4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSUNQRU5EUm5FLCBHSUNE X0lDUEVORFJuRU4pOg0KPj4gKyAgICBjYXNlIFZSQU5HRTMyKEdJQ0RfSVNBQ1RJVkVSbkUsIEdJ Q0RfSVNBQ1RJVkVSbkVOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lDQUNUSVZFUm5F LCBHSUNEX0lDQUNUSVZFUm5FTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9JUFJJT1JJ VFlSbkUsIEdJQ0RfSVBSSU9SSVRZUm5FTik6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoR0lDRF9J Q0ZHUm5FLCBHSUNEX0lDRkdSbkVOKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBN T0RSbkUsIEdJQ0RfSUdSUE1PRFJuRU4pOg0KPj4gICAgICAgICAgIC8qIEFib3ZlIHJlZ2lzdGVy cyBhcmUgY29tbW9uIHdpdGggR0lDUiBhbmQgR0lDRA0KPj4gICAgICAgICAgICAqIE1hbmFnZSBp biBjb21tb24gKi8NCj4+ICAgICAgICAgICByZXR1cm4gX192Z2ljX3YzX2Rpc3RyX2NvbW1vbl9t bWlvX3dyaXRlKCJ2R0lDRCIsIHYsIGluZm8sDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBnaWNkX3JlZywgcik7DQo+PiAgIA0KPj4gICAgICAg Y2FzZSBWUkFOR0UzMihHSUNEX05TQUNSLCBHSUNEX05TQUNSTik6DQo+PiArICAgIGNhc2UgVlJB TkdFMzIoR0lDRF9OU0FDUm5FLCBHSUNEX05TQUNSbkVOKToNCj4+ICAgICAgICAgICAvKiBXZSBk byBub3QgaW1wbGVtZW50IHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIGd1ZXN0cywgd3JpdGUgaWdu b3JlICovDQo+PiAgICAgICAgICAgZ290byB3cml0ZV9pZ25vcmVfMzI7DQo+PiAgIA0KPj4gQEAg LTE0MDUsMjYgKzE1MjUsMzggQEAgc3RhdGljIGludCB2Z2ljX3YzX2Rpc3RyX21taW9fd3JpdGUo c3RydWN0IHZjcHUgKnYsIG1taW9faW5mb190ICppbmZvLA0KPj4gICAgICAgICAgIGlmICggZGFi dC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KPj4gICAgICAgICAgIHJldHVy biAwOw0KPj4gICANCj4+IC0gICAgY2FzZSBWUkFOR0UzMigweDBGMzAsIDB4NjBGQyk6DQo+PiAr ICAgIGNhc2UgVlJBTkdFMzIoMHgwRjMwLCAweDBGRkMpOg0KPj4gICAgICAgICAgIGdvdG8gd3Jp dGVfcmVzZXJ2ZWQ7DQo+PiAgIA0KPj4gICAgICAgY2FzZSBWUkFOR0U2NChHSUNEX0lST1VURVIz MiwgR0lDRF9JUk9VVEVSMTAxOSk6DQo+PiArICAgIGNhc2UgVlJBTkdFNjQoR0lDRF9JUk9VVEVS bkUsIEdJQ0RfSVJPVVRFUm5FTik6DQo+PiAgICAgICB7DQo+PiAgICAgICAgICAgdWludDY0X3Qg aXJvdXRlcjsNCj4+ICsgICAgICAgIHVuc2lnbmVkIGludCBvZmZzZXQsIHZpcnE7DQo+PiAgIA0K Pj4gICAgICAgICAgIGlmICggIXZnaWNfcmVnNjRfY2hlY2tfYWNjZXNzKGRhYnQpICkgZ290byBi YWRfd2lkdGg7DQo+PiAtICAgICAgICByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCA2NCwgZ2lj ZF9yZWcgLSBHSUNEX0lST1VURVIsDQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBEQUJUX0RPVUJMRV9XT1JEKTsNCj4+ICsgICAgICAgIGlmICggZ2ljZF9yZWcgPj0gR0lDRF9J Uk9VVEVSbkUgKSB7DQo+IA0KPiBCcmFjZXMgc2hvdWxkIGdvIGludG8gc2VwYXJhdGUgbGluZQ0K PiANCj4+ICsgICAgICAgICAgICBvZmZzZXQgPSBnaWNkX3JlZyAtIEdJQ0RfSVJPVVRFUm5FOw0K Pj4gKyAgICAgICAgICAgIHJhbmsgPSB2Z2ljX2V4dF9yYW5rX29mZnNldCh2LCA2NCwgb2Zmc2V0 LCBEQUJUX0RPVUJMRV9XT1JEKTsNCj4+ICsgICAgICAgIH0gZWxzZSB7DQo+IA0KPiAuLi4gc28g ImVsc2UiIGFsc28gc2hvdWxkIGJlIG9uIGEgc2VwYXJhdGUgbGluZQ0KPiANCj4+ICsgICAgICAg ICAgICBvZmZzZXQgPSBnaWNkX3JlZyAtIEdJQ0RfSVJPVVRFUjsNCj4+ICsgICAgICAgICAgICBy YW5rID0gdmdpY19yYW5rX29mZnNldCh2LCA2NCwgb2Zmc2V0LCBEQUJUX0RPVUJMRV9XT1JEKTsN Cj4+ICsgICAgICAgIH0NCj4+ICAgICAgICAgICBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8gd3Jp dGVfaWdub3JlOw0KPj4gICAgICAgICAgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdzKTsN Cj4+IC0gICAgICAgIGlyb3V0ZXIgPSB2Z2ljX2ZldGNoX2lyb3V0ZXIocmFuaywgZ2ljZF9yZWcg LSBHSUNEX0lST1VURVIpOw0KPj4gKyAgICAgICAgaXJvdXRlciA9IHZnaWNfZmV0Y2hfaXJvdXRl cihyYW5rLCBvZmZzZXQpOw0KPj4gICAgICAgICAgIHZyZWdfcmVnNjRfdXBkYXRlKCZpcm91dGVy LCByLCBpbmZvKTsNCj4+IC0gICAgICAgIHZnaWNfc3RvcmVfaXJvdXRlcih2LT5kb21haW4sIHJh bmssIGdpY2RfcmVnIC0gR0lDRF9JUk9VVEVSLCBpcm91dGVyKTsNCj4+ICsgICAgICAgIGlmICgg Z2ljZF9yZWcgPj0gR0lDRF9JUk9VVEVSbkUgKQ0KPj4gKyAgICAgICAgICAgIHZpcnEgPSBFU1BJ X0lEWDJJTlRJRChvZmZzZXQgLyBOUl9CWVRFU19QRVJfSVJPVVRFUik7DQo+PiArICAgICAgICBl bHNlDQo+PiArICAgICAgICAgICAgdmlycSA9IG9mZnNldCAvIE5SX0JZVEVTX1BFUl9JUk9VVEVS Ow0KPj4gKyAgICAgICAgdmdpY19zdG9yZV9pcm91dGVyKHYtPmRvbWFpbiwgcmFuaywgdmlycSwg aXJvdXRlcik7DQo+PiAgICAgICAgICAgdmdpY191bmxvY2tfcmFuayh2LCByYW5rLCBmbGFncyk7 DQo+PiAgICAgICAgICAgcmV0dXJuIDE7DQo+PiAgICAgICB9DQo+PiAgIA0KPj4gLSAgICBjYXNl IFZSQU5HRTMyKDB4N0ZFMCwgMHhCRkZDKToNCj4+ICsgICAgY2FzZSBWUkFOR0UzMigweDM3MDAs IDB4NjBGQyk6DQo+PiArICAgIGNhc2UgVlJBTkdFMzIoMHhBMDA0LCAweEJGRkMpOg0KPj4gICAg ICAgICAgIGdvdG8gd3JpdGVfcmVzZXJ2ZWQ7DQo+PiAgIA0KPj4gICAgICAgY2FzZSBWUkFOR0Uz MigweEMwMDAsIDB4RkZDQyk6DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3ZnaWMuYyBi L3hlbi9hcmNoL2FybS92Z2ljLmMNCj4+IGluZGV4IGM5Yjk1MjhjNjYuLjI3ZmZkZjMxNmMgMTAw NjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0v dmdpYy5jDQo+PiBAQCAtMTkzLDYgKzE5MywxOCBAQCBpbnQgZG9tYWluX3ZnaWNfcmVnaXN0ZXIo c3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50ICptbWlvX2NvdW50KQ0KPj4gICB9DQo+PiAg IA0KPj4gICAjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICsvKg0KPj4gKyAqIFRoZSBmdW5j dGlvbiBiZWhhdmlvciBpcyB0aGUgc2FtZSBhcyBmb3IgcmVndWxhciBTUElzICh2Z2ljX3Jhbmtf b2Zmc2V0KSwNCj4+ICsgKiBidXQgaXQgb3BlcmF0ZXMgd2l0aCBleHRlbmRlZCBTUEkgcmFua3Mu DQo+PiArICovDQo+PiArc3RydWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfZXh0X3Jhbmtfb2Zmc2V0 KHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQgYiwNCj4+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IG4sIHVuc2lnbmVkIGludCBzKQ0K Pj4gK3sNCj4+ICsgICAgdW5zaWduZWQgaW50IHJhbmsgPSBSRUdfUkFOS19OUihiLCAobiA+PiBz KSk7DQo+PiArDQo+PiArICAgIHJldHVybiB2Z2ljX2dldF9yYW5rKHYsIHJhbmsgKyBFWFRfUkFO S19NSU4pOw0KPj4gK30NCj4+ICsNCj4+ICAgc3RhdGljIHVuc2lnbmVkIGludCB2Z2ljX251bV9z cGlfbGluZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICAgew0KPj4gICAgICAgcmV0dXJuIGQtPmFy Y2gudmdpYy5ucl9zcGlzICsgZC0+YXJjaC52Z2ljLm5yX2VzcGlzOw0KPj4gQEAgLTI0MSw2ICsy NTMsMTcgQEAgc3RydWN0IHBlbmRpbmdfaXJxICplc3BpX3RvX3BlbmRpbmcoc3RydWN0IGRvbWFp biAqZCwgdW5zaWduZWQgaW50IGlycSkNCj4+ICAgew0KPj4gICAgICAgcmV0dXJuIE5VTEw7DQo+ PiAgIH0NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIEl0IGlzIGV4cGVjdGVkIHRoYXQsIGluIHRoZSBj YXNlIG9mIENPTkZJR19HSUNWM19FU1BJPW4sIHRoZSBmdW5jdGlvbiB3aWxsDQo+PiArICogcmV0 dXJuIE5VTEwuIEluIHRoaXMgc2NlbmFyaW8sIG1taW9fcmVhZC9tbWlvX3dyaXRlIHdpbGwgYmUg dHJlYXRlZCBhcw0KPj4gKyAqIFJBWi9XSSwgYXMgZXhwZWN0ZWQuDQo+PiArICovDQo+PiArc3Ry dWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHN0cnVjdCB2Y3B1ICp2LCB1 bnNpZ25lZCBpbnQgYiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdW5zaWduZWQgaW50IG4sIHVuc2lnbmVkIGludCBzKQ0KPj4gK3sNCj4+ICsgICAgcmV0 dXJuIE5VTEw7DQo+PiArfQ0KPj4gICAjZW5kaWYNCj4+ICAgDQo+PiAgIHN0YXRpYyB1bnNpZ25l ZCBpbnQgdmdpY19udW1fYWxsb2NfaXJxcyhzdHJ1Y3QgZG9tYWluICpkKQ0KPiANCg0KQmVzdCBy ZWdhcmRzLA0KTGVvbmlkDQo= From xen-devel-bounces@lists.xenproject.org Mon Sep 01 18:54:08 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 18:54:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105345.1456249 (Exim 4.92) (envelope-from ) id 1ut9fG-0006CN-QD; Mon, 01 Sep 2025 18:54:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105345.1456249; Mon, 01 Sep 2025 18:54: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 1ut9fG-0006CG-Mz; Mon, 01 Sep 2025 18:54:02 +0000 Received: by outflank-mailman (input) for mailman id 1105345; Mon, 01 Sep 2025 18:54: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 1ut9fG-0006CA-1m for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 18:54:02 +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 05865fd3-8765-11f0-8adc-4578a1afcccb; Mon, 01 Sep 2025 20:54:00 +0200 (CEST) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-45b804ed966so13531755e9.2 for ; Mon, 01 Sep 2025 11:54:00 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3cf270fbd01sm16712581f8f.13.2025.09.01.11.53.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 11:53: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: 05865fd3-8765-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756752840; x=1757357640; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ouFIbD5mcmQxPlqhU+hFCwx0s9hFhtNs2O1nZiItwY0=; b=vD43XnZ4OUhymZRqiq4jhuaCVLWVCdViJTEenMVkrM5WOv08ZVZTfYRQeQYAHKr38j rVtFfwTJXa4rIabbcsu2Ek0mGFEGFFKAYVMe/cIR+kaO1Nic9CPU0U5RiL8vayJBwelu WrvKgXLktXDATeV2+KYQgSLra/TzJqwcldMKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756752840; x=1757357640; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ouFIbD5mcmQxPlqhU+hFCwx0s9hFhtNs2O1nZiItwY0=; b=YrHk65wdQCmVO0VnVhWAlTJ1lHXt0qJpc+WT/vDnIJhkAxL8mWlzuuT3+3OxFES0tc iqQJLGooyfjoc8umDB7ubBijZduDlSpc7IiXxJF1dRAOubvaQHxWchwB3XS1ObMslFqe xrZWvEOII8A0uZQNdqgXdmMdSYXnHbfgUJt1rvsZ5vKfo2NlU8dCxTa4Fr6ncuFk9BRw dHi4VYIfGJSw1UBLgXCXlLNwLkVzViR1DH+b92g/MZqWiZwBQGbPala4K8xDglWBCNZi oswuGRWhCZtvxkMdI3b+NUe0uw541YlSyCmzO1HgrcCy9jtlvbGzcMESrrTW5Jqcf+7t nW/g== X-Forwarded-Encrypted: i=1; AJvYcCVLOLAvzfufDSokAYUJWz6hBG6lNAZk5LUtt7G1TKQ4YqCrlJ30+EiuDeOo9+5BfEZd4WecDvAqYCI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyvubc+8AKWn2puxNDkQIjxAMoiyOKpgAONwx10mRHXjM2YcsJt xUluSyiuyW1WzxWExyUyZ4T+mqoiKbe7Gl9fCjSehNyM5WB8y/eiYKmJwkM4FR9Aiu8= X-Gm-Gg: ASbGncvOpFe8d4pFWPn4LSAHyIda87j/VvZ2aaEMTNfkVbmVIDVCdUGZOLSqT2VKhJ3 aWLLdObkj9riPYwIkBItQCqpca0Sj6S8qH+Eznh09byof8xQU/6I0qXy0KGYq1fke1RU93lMq6Z sU9v+Okf2uTN0NKBc/h61nDe+sBpDxgdAJtzQCnRL/QR7Uz04YJFxlfkHxKkXAi96gr2ou2PpNq 4v51Bp7S09oQ0MAekPyX4IWT/r48iOeCVIi/ocgONs9mDkJtBLuZRajnMIxUFhkFt4tf69wOij7 nS5gkNWlsZnZeeD56LcXAlB5L0mNyNxO89q4b7kH3kSXM8IPS/rbnpdrgI1m74AP14VvIlqZCBF //ObVNIcP2QoP5OJC7N8uq1zs5pz/JRbEzuJVKe4GMPi4TT65kUhc1d54oY+06/tkZ5073+0yDN XSHD0= X-Google-Smtp-Source: AGHT+IH6AagXuTt4W1eGSarw1rXBz3sqMlrmj5WO8yWJE1dF7Gwdumi22/tBzemnqJkQhRS4+a162Q== X-Received: by 2002:a05:600c:35ca:b0:45b:8939:8b19 with SMTP id 5b1f17b1804b1-45b89398d7amr57002895e9.8.1756752839713; Mon, 01 Sep 2025 11:53:59 -0700 (PDT) Message-ID: <935c5307-86c4-48ae-80da-a4454f28398d@citrix.com> Date: Mon, 1 Sep 2025 19:53:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/23] x86/boot: Use RSTORSSP to establish SSP To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-8-andrew.cooper3@citrix.com> <9322056d-9f09-4f5b-801b-6f0fdad5ead9@suse.com> <18e139ce-36a5-4a0c-8a9c-440ef1c1e29f@citrix.com> <595a24ff-9eb8-40f3-9108-dca02e5a7a2c@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: <595a24ff-9eb8-40f3-9108-dca02e5a7a2c@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/09/2025 4:41 pm, Jan Beulich wrote: > On 01.09.2025 17:33, Andrew Cooper wrote: >> On 01/09/2025 10:28 am, Jan Beulich wrote: >>> On 28.08.2025 17:03, Andrew Cooper wrote: >>>> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void) >>>> if ( cpu_has_xen_shstk ) >>>> { >>>> wrmsrl(MSR_S_CET, xen_msr_s_cet_value()); >>>> - asm volatile ("setssbsy" ::: "memory"); >>>> + >>>> + /* >>>> + * IDT and FRED differ by a Supervisor Token on the shadow stack, and >>>> + * therefore by the value in MSR_PL0_SSP. >>> Beside not being overly relevant here afaict, is this last part of the sentence >>> actually correct? Patch 06 doesn't write different values into the MSR. >> It is correct, but also well hidden. >> >> #define MSR_FRED_SSP_SL0                    MSR_PL0_SSP >> >> I suppose I should should write MSR_PL0_SSP/MSR_FRED_SSP_SL0 here to >> highlight the logically different names for the two modes. > But the code following the comment doesn't access any MSR. That's what > first tripped me up. It was only then that I wasn't able to spot the two > different writes. Now that you point out the aliasing it becomes clear > that until patch 14 it is simply impossible to find that other write. I suppose the MSR value isn't relevant now that neither paths write the value.  The first iteration had both writes here. I guess I can drop that paragraph, and just have the second? ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 01 21:48:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 21:48:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105375.1456299 (Exim 4.92) (envelope-from ) id 1utCNp-0000er-3U; Mon, 01 Sep 2025 21:48:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105375.1456299; Mon, 01 Sep 2025 21: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 1utCNp-0000ek-0q; Mon, 01 Sep 2025 21:48:13 +0000 Received: by outflank-mailman (input) for mailman id 1105375; Mon, 01 Sep 2025 21:48: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 1utCNn-0000ec-Es for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 21:48:11 +0000 Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 56e75c51-877d-11f0-8dd7-1b34d833f44b; Mon, 01 Sep 2025 23:48:06 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20250901214803euoutp02d79d0cf4cda6546a5817575ed420314a~hRuYkNP0O2070420704euoutp02b; Mon, 1 Sep 2025 21:48:03 +0000 (GMT) Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20250901214802eucas1p2e3b4b360d054bc640a8654e364047c28~hRuXfQpr52428424284eucas1p2C; Mon, 1 Sep 2025 21:48:02 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250901214759eusmtip26af756ba90f133971e3a66f9c5275b48~hRuUiYUac1463914639eusmtip2j; Mon, 1 Sep 2025 21:47:59 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 56e75c51-877d-11f0-8dd7-1b34d833f44b DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250901214803euoutp02d79d0cf4cda6546a5817575ed420314a~hRuYkNP0O2070420704euoutp02b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1756763283; bh=nDcHitW6y2xbmXlK2jIcbndjdtco2y22djXFkarI+Kk=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=FxjRf7+Ccpl7snsYCn9LacCiGJXvASl2Bcyshcc3MWcU7wbky050oQOcx4xKJlMqc EH1xZePjtKif6niNm/ZZNmDVZoJ/hrllrH2T7muDX2gjk12tpAmaQkZRCflGuSDB6/ tvmSX006Ss83xwBwmshU6YU5Q3rwG2epCzq8Yjqg= Message-ID: <26bd901a-0812-492d-9736-4a7bb2e6d6b4@samsung.com> Date: Mon, 1 Sep 2025 23:47:59 +0200 MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based API To: Leon Romanovsky Cc: Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Content-Language: en-US From: Marek Szyprowski In-Reply-To: <20250828115729.GA10073@unreal> Content-Transfer-Encoding: 8bit X-CMS-MailID: 20250901214802eucas1p2e3b4b360d054bc640a8654e364047c28 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250828115738eucas1p24f3c17326b318c95a5569a2c9651ff92 X-EPHeader: CA X-CMS-RootMailID: 20250828115738eucas1p24f3c17326b318c95a5569a2c9651ff92 References: <20250828115729.GA10073@unreal> On 28.08.2025 13:57, Leon Romanovsky wrote: > On Tue, Aug 19, 2025 at 08:36:44PM +0300, Leon Romanovsky wrote: >> Changelog: >> v4: >> * Fixed kbuild error with mismatch in kmsan function declaration due to >> rebase error. >> v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org >> * Fixed typo in "cacheable" word >> * Simplified kmsan patch a lot to be simple argument refactoring >> v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org >> * Used commit messages and cover letter from Jason >> * Moved setting IOMMU_MMIO flag to dma_info_to_prot function >> * Micro-optimized the code >> * Rebased code on v6.17-rc1 >> v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org >> * Added new DMA_ATTR_MMIO attribute to indicate >> PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path. >> * Rewrote dma_map_* functions to use thus new attribute >> v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/ >> ------------------------------------------------------------------------ >> >> This series refactors the DMA mapping to use physical addresses >> as the primary interface instead of page+offset parameters. This >> change aligns the DMA API with the underlying hardware reality where >> DMA operations work with physical addresses, not page structures. >> >> The series maintains export symbol backward compatibility by keeping >> the old page-based API as wrapper functions around the new physical >> address-based implementations. >> >> This series refactors the DMA mapping API to provide a phys_addr_t >> based, and struct-page free, external API that can handle all the >> mapping cases we want in modern systems: >> >> - struct page based cachable DRAM >> - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cachable >> MMIO >> - struct page-less PCI peer to peer non-cachable MMIO >> - struct page-less "resource" MMIO >> >> Overall this gets much closer to Matthew's long term wish for >> struct-pageless IO to cachable DRAM. The remaining primary work would >> be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on >> phys_addr_t without a struct page. >> >> The general design is to remove struct page usage entirely from the >> DMA API inner layers. For flows that need to have a KVA for the >> physical address they can use kmap_local_pfn() or phys_to_virt(). This >> isolates the struct page requirements to MM code only. Long term all >> removals of struct page usage are supporting Matthew's memdesc >> project which seeks to substantially transform how struct page works. >> >> Instead make the DMA API internals work on phys_addr_t. Internally >> there are still dedicated 'page' and 'resource' flows, except they are >> now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both >> flows use the same phys_addr_t. >> >> When DMA_ATTR_MMIO is specified things work similar to the existing >> 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), >> pfn_valid(), etc are never called on the phys_addr_t. This requires >> rejecting any configuration that would need swiotlb. CPU cache >> flushing is not required, and avoided, as ATTR_MMIO also indicates the >> address have no cachable mappings. This effectively removes any >> DMA API side requirement to have struct page when DMA_ATTR_MMIO is >> used. >> >> In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, >> except on the common path of no cache flush, no swiotlb it never >> touches a struct page. When cache flushing or swiotlb copying >> kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU >> usage. This was already the case on the unmap side, now the map side >> is symmetric. >> >> Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users >> must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA >> path must also set it. This corrects some existing bugs where iommu >> mappings for P2P MMIO were improperly marked IOMMU_CACHE. >> >> Since ATTR_MMIO is made to work with all the existing DMA map entry >> points, particularly dma_iova_link(), this finally allows a way to use >> the new DMA API to map PCI P2P MMIO without creating struct page. The >> VFIO DMABUF series demonstrates how this works. This is intended to >> replace the incorrect driver use of dma_map_resource() on PCI BAR >> addresses. >> >> This series does the core code and modern flows. A followup series >> will give the same treatment to the legacy dma_ops implementation. >> >> Thanks >> >> Leon Romanovsky (16): >> dma-mapping: introduce new DMA attribute to indicate MMIO memory >> iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link(). >> dma-debug: refactor to use physical addresses for page mapping >> dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys >> iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys >> iommu/dma: extend iommu_dma_*map_phys API to handle MMIO memory >> dma-mapping: convert dma_direct_*map_page to be phys_addr_t based >> kmsan: convert kmsan_handle_dma to use physical addresses >> dma-mapping: handle MMIO flow in dma_map|unmap_page >> xen: swiotlb: Open code map_resource callback >> dma-mapping: export new dma_*map_phys() interface >> mm/hmm: migrate to physical address-based DMA mapping API >> mm/hmm: properly take MMIO path >> block-dma: migrate to dma_map_phys instead of map_page >> block-dma: properly take MMIO path >> nvme-pci: unmap MMIO pages with appropriate interface >> >> Documentation/core-api/dma-api.rst | 4 +- >> Documentation/core-api/dma-attributes.rst | 18 ++++ >> arch/powerpc/kernel/dma-iommu.c | 4 +- >> block/blk-mq-dma.c | 15 ++- >> drivers/iommu/dma-iommu.c | 61 +++++------ >> drivers/nvme/host/pci.c | 18 +++- >> drivers/virtio/virtio_ring.c | 4 +- >> drivers/xen/swiotlb-xen.c | 21 +++- >> include/linux/blk-mq-dma.h | 6 +- >> include/linux/blk_types.h | 2 + >> include/linux/dma-direct.h | 2 - >> include/linux/dma-map-ops.h | 8 +- >> include/linux/dma-mapping.h | 33 ++++++ >> include/linux/iommu-dma.h | 11 +- >> include/linux/kmsan.h | 9 +- >> include/trace/events/dma.h | 9 +- >> kernel/dma/debug.c | 71 ++++--------- >> kernel/dma/debug.h | 37 ++----- >> kernel/dma/direct.c | 22 +--- >> kernel/dma/direct.h | 52 ++++++---- >> kernel/dma/mapping.c | 117 +++++++++++++--------- >> kernel/dma/ops_helpers.c | 6 +- >> mm/hmm.c | 19 ++-- >> mm/kmsan/hooks.c | 5 +- >> rust/kernel/dma.rs | 3 + >> tools/virtio/linux/kmsan.h | 2 +- >> 26 files changed, 305 insertions(+), 254 deletions(-) > Marek, > > So what are the next steps here? This series is pre-requirement for the > VFIO MMIO patches. I waited a bit with a hope to get a comment from Robin. It looks that there is no other alternative for the phys addr in the struct page removal process. I would like to give those patches a try in linux-next, but in meantime I tested it on my test farm and found a regression in dma_map_resource() handling. Namely the dma_map_resource() is no longer possible with size not aligned to kmalloc()'ed buffer, as dma_direct_map_phys() calls dma_kmalloc_needs_bounce(), which in turn calls dma_kmalloc_size_aligned(). It looks that the check for !(attrs & DMA_ATTR_MMIO) should be moved one level up in dma_direct_map_phys(). Here is the log: ------------[ cut here ]------------ dma-pl330 fe550000.dma-controller: DMA addr 0x00000000fe410024+4 overflow (mask ffffffff, bus limit 0). WARNING: kernel/dma/direct.h:116 at dma_map_phys+0x3a4/0x3ec, CPU#1: speaker-test/405 Modules linked in: ... CPU: 1 UID: 0 PID: 405 Comm: speaker-test Not tainted 6.17.0-rc4-next-20250901+ #10958 PREEMPT Hardware name: Hardkernel ODROID-M1 (DT) pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dma_map_phys+0x3a4/0x3ec lr : dma_map_phys+0x3a4/0x3ec ... Call trace:  dma_map_phys+0x3a4/0x3ec (P)  dma_map_resource+0x14/0x20  pl330_prep_slave_fifo+0x78/0xd0  pl330_prep_dma_cyclic+0x70/0x2b0  snd_dmaengine_pcm_trigger+0xec/0x8bc [snd_pcm_dmaengine]  dmaengine_pcm_trigger+0x18/0x24 [snd_soc_core]  snd_soc_pcm_component_trigger+0x164/0x208 [snd_soc_core]  soc_pcm_trigger+0xe4/0x1ec [snd_soc_core]  snd_pcm_do_start+0x44/0x70 [snd_pcm]  snd_pcm_action_single+0x48/0xa4 [snd_pcm]  snd_pcm_action+0x7c/0x98 [snd_pcm]  snd_pcm_action_lock_irq+0x48/0xb4 [snd_pcm]  snd_pcm_common_ioctl+0xf00/0x1f1c [snd_pcm]  snd_pcm_ioctl+0x30/0x48 [snd_pcm]  __arm64_sys_ioctl+0xac/0x104  invoke_syscall+0x48/0x110  el0_svc_common.constprop.0+0x40/0xe8  do_el0_svc+0x20/0x2c  el0_svc+0x4c/0x160  el0t_64_sync_handler+0xa0/0xe4  el0t_64_sync+0x198/0x19c irq event stamp: 6596 hardirqs last  enabled at (6595): [] _raw_spin_unlock_irqrestore+0x74/0x78 hardirqs last disabled at (6596): [] _raw_spin_lock_irq+0x78/0x7c softirqs last  enabled at (6076): [] handle_softirqs+0x4c4/0x4dc softirqs last disabled at (6071): [] __do_softirq+0x14/0x20 ---[ end trace 0000000000000000 ]--- rockchip-i2s-tdm fe410000.i2s: ASoC error (-12): at soc_component_trigger() on fe410000.i2s Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From xen-devel-bounces@lists.xenproject.org Mon Sep 01 21:55:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 21:55:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105386.1456309 (Exim 4.92) (envelope-from ) id 1utCVC-0002L0-R2; Mon, 01 Sep 2025 21:55:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105386.1456309; Mon, 01 Sep 2025 21: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 1utCVC-0002Kt-OQ; Mon, 01 Sep 2025 21:55:50 +0000 Received: by outflank-mailman (input) for mailman id 1105386; Mon, 01 Sep 2025 21:55:49 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCVB-0002Kn-Rf for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 21:55:49 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utCV7-001M9z-2X; Mon, 01 Sep 2025 21:55:46 +0000 Received: from [19.12.91.86] (helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utCV7-00COLF-2A; Mon, 01 Sep 2025 21:55: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID :Subject:Cc:To:Date:From; bh=vxCpnRsJ25qmn+AFxDqD1rYc2ebQPzUWXUR5bwmZLxw=; b= IF+5XOyZjsI/sDXLAN3sTVQr+eWyQ6FPGePfDRV3BVjAaM0mDaqmgXC1EhOWIqhDnQRJZ8I+0aUKK d6Azg6L7Mh/hZSbS5R71QmGUt8RAINhBJTxUS4l6AUKQCmwsvZD0ixY7Rgqg5kR2F/RZMkRfN0f4z GCgBwWMV+1xc4Zjzg=; From: dmukhin@xen.org Date: Mon, 1 Sep 2025 14:55:44 -0700 To: Stefano Stabellini Cc: dmkhn@proton.me, 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 v11] xen/console: introduce domain_console struct Message-ID: References: <20250807005649.551704-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 29, 2025 at 03:06:27PM -0700, Stefano Stabellini wrote: > On Thu, 7 Aug 2025, 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. > > > > Ensure accesses to domain_console pointer are valid in console_switch_input(). > > > > Bump the domain console buffer allocation size to 256. No extra symbol for the > > value since it is used only once during data structure declaration. All size > > checks use ARRAY_SIZE(). > > > > Allocate domain_console from the heap so that the parent domain struct size > > stays below PAGE_SIZE boundary to account for more console-related fields > > added in the future. > > > > Finally, update the domain_console allocation and initialization code. Make > > sure domain_console is not allocated for system domains. > > > > No functional change. > > > > Signed-off-by: Denis Mukhin > > Reviewed-by: Stefano Stabellini Thank you From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105397.1456318 (Exim 4.92) (envelope-from ) id 1utCjJ-000568-SX; Mon, 01 Sep 2025 22:10:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105397.1456318; Mon, 01 Sep 2025 22: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 1utCjJ-000561-Pe; Mon, 01 Sep 2025 22:10:25 +0000 Received: by outflank-mailman (input) for mailman id 1105397; Mon, 01 Sep 2025 22:10: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 1utCjI-00055o-GB for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:24 +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 742fcd6f-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:22 +0200 (CEST) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-55f7b6e4145so1330644e87.1 for ; Mon, 01 Sep 2025 15:10:22 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15: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: 742fcd6f-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764621; x=1757369421; 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=P0ROChEhFSQ6tMRvQy04P3RZc8I7Rkyakj4KgtEzBVg=; b=MsJSEfATCfIV22pSWyvdlBsHLHEp+jX/ShN5/X1pIMN6qqa2geMWEui18x4iePX6eZ QKmO7/LQGajkVx2KF9P1qkfimwUOC6AVuaDvbeQm7gAgi7MoO5FqVh/Lpj5698w/P9EZ RRlLj3I37HdW5ctb4cBsSRm1sW9WY/jMU7oO1D1D2eIWo5m150Oe0t5Qs3qOfx0ZnK8V CFmtgkWH99bjCgXRadz7yHQn8RPth9iyw7EMycj+C93zL+z3qG0yXVRB00IpLr7rKx7r 8rNkRKe8pvK4E1z+OUOXlC2bwKFBrwWrdC/FE/VfWcMYNLseUALmGRSfLoI+8k0Oqc1v H0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764621; x=1757369421; 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=P0ROChEhFSQ6tMRvQy04P3RZc8I7Rkyakj4KgtEzBVg=; b=XQ+tceXC+iZqL7FHEuUb68/LWAsN35L90z8q4jva8taNcJL/x+eX12EBoINKrCvvll sdgkm50g6ZZ7ezBnCAkyDe9tV6k4i4ttJ7FCL/5VIiOKnuHhR+glqdptS8e1EHT1+yAW wNWI1shKClT1A/QuOiYZKhr7fpAZ4hCIixKFRwtS+C8wTrp9Knoos75nSt7Dk3FK5mq9 t4SbrDbimfvNdRAwLJkpXwNoZPNJ8UpERWSGPghUqC3/kpA/ngJchVAgxfyQa5RCgMIq xg5noAoZ+mrPUA0wrtkjN89AUAfxh6keZ+qJnuFQcQKPsl7l78XGJFzo6ItJqK+WdRzv 0ALw== X-Gm-Message-State: AOJu0YyKCKoAjAqBNW7aO9IBp+Qm/Z8xVpcw7yMXBh/nqrERpNRy6Tth FGw8wv1KzRqPqIoXULJWlZU1PyvtW3Yc+F2cp1rSOdAmAqd2E0ojMg7Z4ivkHqB/ X-Gm-Gg: ASbGnctB/LTmwkdWNnl/4p6PMBJA5Z9G0ffL29SDjad331h0kmSIKs5HCbBjzMNoJDi OmryY48wn/O5VsU+KuAK7iybZ2F9dx4i9lPBheYtCjnAE7h4k9BnFKY2/zQmq8ofITc2tV46oe1 npgeIHTlFSKEG6ID9RbTqQJxxfPCW2JVDNyFjDKzdI90gYnv9loe29djxvbbwa+pPJpcM1VfVgY e6CNY+lW9N8OcezOY+Fag/4ws6U5/qyq/ikoXWHJ70vZbaSmQ5pv6T+xQtZUhI1zrHNGOBoD6k4 w6yBpKGonsIfTL+V4tO3kiOv2lonopa7oJpRcp1cOVTscRR9okExeftODLZPThXYH+Rv1+FTUwy 3yITw3VOK2Eg4sXVcf7VSkRVfbWlrKDRR8tBROflRST0fKKVO6qijzw/7tk2SZQ== X-Google-Smtp-Source: AGHT+IGbjvMD0r9yNJ8/BpcCQjITDXNh1n6xrczamQXqodO0WmvR2poWjszQoodP64wEuUIk/MlbSw== X-Received: by 2002:a05:6512:4608:b0:55f:67d5:938e with SMTP id 2adb3069b0e04-55f7094f818mr2235255e87.39.1756764621091; Mon, 01 Sep 2025 15:10:21 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Rahul Singh Subject: [PATCH v6 00/13] Add initial Xen Suspend-to-RAM support on ARM64 Date: Tue, 2 Sep 2025 01:10:04 +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 5 of the ARM Xen system suspend/resume patch series, based on earlier work by Mirela Simonovic and Mykyta Poturai. The first part is here: https://marc.info/?l=xen-devel&m=175659181415965&w=2 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. 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, GICv2/GICv3 and IPMMU-VMSA - 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/GICv3 suspend and resume, including memory-backed context save/restore with error handling - Added time and IRQ suspend/resume hooks, ensuring correct timer/interrupt state across suspend cycles - Implemented proper PSCI SYSTEM_SUSPEND invocation and version checks - Improved state management and recovery in error cases during suspend/resume - Added support for IPMMU-VMSA context save/restore - Added support for GICv3 eSPI registers context save/restore --- TODOs: - Test system suspend with llc_coloring_enabled set and verify functionality - Implement SMMUv3 suspend/resume handlers - Enable "xl suspend" support on ARM - Properly disable Xen timer watchdog from relevant services (only init.d left) - Add suspend/resume CI test for ARM (QEMU if feasible) - Investigate feasibility and need for implementing system suspend on ARM32 --- Changelog for v6: - Add suspend/resume support for GICv3 eSPI registers (to be applied after the main eSPI series). - Drop redundant iommu_enabled check from host system suspend. - Switch from continue_hypercall_on_cpu to a dedicated tasklet for system suspend, avoiding user register modification and decoupling guest/system suspend status. - Refactor IOMMU register context code. - Improve IRQ handling: call handler->disable(), move system state checks, and skip IRQ release during suspend inside release_irq(). - Remove redundant GICv3 save/restore state logic now handled during vCPU context switch. - Clarify and unify error/warning messages, comments, and documentation. - Correct loops for saving/restoring priorities and merge loops where possible. - Add explicit error for unimplemented ITS suspend support. - Add missing GICD_CTLR_DS bit definition and clarify GICR_WAKER comments. - Cleanup active and enable registers before restoring. - Minor comment improvements and code cleanups. Changes introduced in V5: - Add support for IPMMU-VMSA context save/restore - Add support for GICv3 context save/restore - Select HAS_SYSTEM_SUSPEND in ARM_64 instead of ARM - Check llc_coloring_enabled instead of LLC_COLORING during the selection of HAS_SYSTEM_SUSPEND config - Call host_system_suspend from guest PSCI system suspend instead of arch_domain_shutdown, reducing the complexity of the new code 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. 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 Mirela Simonovic (6): xen/arm: Add suspend and resume timer helpers xen/arm: gic-v2: Implement GIC suspend/resume functions 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 xen/arm: Add support for system suspend triggered by hardware domain Mykola Kvach (5): xen/arm: gic-v3: Implement GICv3 suspend/resume functions xen/arm: Don't release IRQs 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/arm: gic-v3: Add suspend/resume support for eSPI registers Oleksandr Tyshchenko (2): iommu/ipmmu-vmsa: Implement suspend/resume callbacks xen/arm: Suspend/resume IOMMU on Xen suspend/resume xen/arch/arm/Kconfig | 1 + xen/arch/arm/Makefile | 1 + xen/arch/arm/arm64/head.S | 112 +++++++++ xen/arch/arm/gic-v2.c | 143 +++++++++++ xen/arch/arm/gic-v3-lpi.c | 3 + xen/arch/arm/gic-v3.c | 288 +++++++++++++++++++++++ xen/arch/arm/gic.c | 32 +++ xen/arch/arm/include/asm/gic.h | 12 + xen/arch/arm/include/asm/gic_v3_defs.h | 1 + xen/arch/arm/include/asm/mm.h | 2 + xen/arch/arm/include/asm/psci.h | 1 + xen/arch/arm/include/asm/suspend.h | 46 ++++ xen/arch/arm/include/asm/time.h | 5 + xen/arch/arm/irq.c | 46 ++++ xen/arch/arm/mmu/smpboot.c | 2 +- xen/arch/arm/psci.c | 23 +- xen/arch/arm/suspend.c | 175 ++++++++++++++ xen/arch/arm/tee/ffa_notif.c | 2 +- xen/arch/arm/time.c | 49 +++- xen/arch/arm/vpsci.c | 9 +- xen/common/domain.c | 4 + xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 ++++++++++++++++++++ xen/drivers/passthrough/arm/smmu-v3.c | 10 + xen/drivers/passthrough/arm/smmu.c | 10 + 24 files changed, 1220 insertions(+), 14 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 Sep 01 22:10:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105399.1456339 (Exim 4.92) (envelope-from ) id 1utCjN-0005Ys-DK; Mon, 01 Sep 2025 22:10:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105399.1456339; Mon, 01 Sep 2025 22:10:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjN-0005Yj-AX; Mon, 01 Sep 2025 22:10:29 +0000 Received: by outflank-mailman (input) for mailman id 1105399; Mon, 01 Sep 2025 22:10: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 1utCjL-00055o-KS for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:27 +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 7647d278-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:25 +0200 (CEST) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55f6186cc17so3747152e87.2 for ; Mon, 01 Sep 2025 15:10:25 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7647d278-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764625; x=1757369425; darn=lists.xenproject.org; h=content-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=GL9EWkohjo8a/Dn92rOcdmsDJxHtlTsb7OJVk0QSUJM=; b=DuO4koIctpb21IVOdjzP5KU4+SUc96C9z7oZb+Yd6UASzoYMx38LPEb6LGRmO9Rc+r qtRxihrKEthqPb1Z+gHeFN4TGv0xKsqVcBHTPOjKge9LAn49BEl7HQBmfXHf+8L7fIWb LT7vtUIJl4R0c/POeFxMIFamgohmyuL4UJLjH2c+pndAJbfM3OAtTAlUaTgI+18pnSZQ VYxhhCcRVuhM3rSvqYNsATa7WKg1es8Jwqa82jvGlw5YsLXvakZw153TRRDdZosD9nEl VTQ8/0rQHBrj54rOU+gqM0uUZkIlUtyUAceVrH/KAhImhXfa22FAGyTD640pRHhqJ7xL P8/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764625; x=1757369425; 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=GL9EWkohjo8a/Dn92rOcdmsDJxHtlTsb7OJVk0QSUJM=; b=aD4YICYeLw2AzxsdloPLu0USEFit6vhd2XkVV/J5mRThHJqKfRFpD61Rziwz5CA8GW 3dycvD/gd485I/hvKciO+qQWHDYb8HTC1AJPFjOdb2UBiw01OlK6gwYXxwZ/xTb2GaYC Gzr++xialMPFXy1FC+zcCp4wyy2AIGxtXkGmeO1SaACPMG6gMlYh6rXw/xiPCHHt4hLb UTouSqDfErWVGnyhvifdCU7sEEJK+oWxvP9+SuJgrZ8sa4WiNMz6hwT/E2MqbAGPcTYe WiyIRBNqE0NZctQzOFFihh6Ovp0ml/XsLDDwMTdIda13odjvc9m0wMdd1noZFkqJSKyo IHIg== X-Gm-Message-State: AOJu0YwfU8H1Z5YxHVrxNvAXv5gJxs06zyypp7M9wtKC/yZPXUn+/g/o C0JWH/JmZTvnr2F+4ThFuIhNHtvwSmhRgNRUWdUMn+FRJniKBVybAGHlkuYjqsP8 X-Gm-Gg: ASbGncsPEIXA6oKR75+8PM0bPqL1jHtjuHDexZbFdTsIeHezKPeuydGZoBovoGVURfb fAhN77Ru7ZBB0bBhlTpiSzrgdXRoueiWqB8gpToczsc40pO0JNTf3PbjGVtW++ayiTj84x8gHbI U8UJma2ZroFnm5a2ftWs20jXsyKrABgM0cgb3a8QGBWzzEyC63Gt926oIJz4UdiLWpd2VUUylJ3 ollMI+EDFbxwpBbGzWTnpaTuGXoJfbZRUwp5tkrqv1GJx0/+MWCblb4O/PdeT2/32aT1XCY2MEw 8aIuhW2Cefw8d6UyeFpJIgHdoneXnTZL0xuxfOJCuNgW1pHmn3OadXTzbp+U8ObAPuVmaoKp2DZ zMJS5F++kYm9S3u7G3Q/Yy+RWH4tpd85IIiTJq4AvvVBNAwIxU70aFTKlG6mEKMFTTgqkcbKu X-Google-Smtp-Source: AGHT+IGHO6vPuMNSviLACKBC72hu/IH8PKVE6FIUQK3U79KxMfeWob9GsNWWKppkqNO3yp5F/sT2uA== X-Received: by 2002:a05:6512:4608:b0:55f:3996:4f82 with SMTP id 2adb3069b0e04-55f708a2cb5mr2329558e87.1.1756764624937; Mon, 01 Sep 2025 15:10:24 -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 v6 03/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions Date: Tue, 2 Sep 2025 01:10:07 +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 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. Signed-off-by: Mykola Kvach --- Changes in V6: - Drop gicv3_save/restore_state since it is already handled during vCPU context switch. - The comment about systems without SPIs is clarified for readability. - Error and warning messages related to suspend context allocation are unified and now use printk() with XENLOG_ERR for consistency. - The check for suspend context allocation in gicv3_resume() is removed, as it is handled earlier in the suspend path. - The loop for saving and restoring PPI/SGI priorities is corrected to use the proper increment. - The gicv3_suspend() function now prints an explicit error if ITS suspend support is not implemented, and returns ENOSYS in this case. - The GICD_CTLR_DS bit definition is added to gic_v3_defs.h. - The comment for GICR_WAKER access is expanded to reference the relevant ARM specification section and clarify the RAZ/WI behavior for Non-secure accesses. - Cleanup active and enable registers before restoring. --- xen/arch/arm/gic-v3-lpi.c | 3 + xen/arch/arm/gic-v3.c | 235 +++++++++++++++++++++++++ xen/arch/arm/include/asm/gic_v3_defs.h | 1 + 3 files changed, 239 insertions(+) diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index de5052e5cf..61a6e18303 100644 --- a/xen/arch/arm/gic-v3-lpi.c +++ b/xen/arch/arm/gic-v3-lpi.c @@ -391,6 +391,9 @@ static int cpu_callback(struct notifier_block *nfb, unsigned long action, switch ( action ) { case CPU_UP_PREPARE: + if ( system_state == SYS_STATE_resume ) + break; + rc = gicv3_lpi_allocate_pendtable(cpu); if ( rc ) printk(XENLOG_ERR "Unable to allocate the pendtable for CPU%lu\n", diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index cd3e1acf79..9f1be7e905 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1776,6 +1776,233 @@ static bool gic_dist_supports_lpis(void) return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS); } +#ifdef CONFIG_SYSTEM_SUSPEND + +/* GICv3 registers to be saved/restored on system suspend/resume */ +struct gicv3_ctx { + struct dist_ctx { + uint32_t ctlr; + /* + * This struct represent block of 32 IRQs + * TODO: store extended SPI configuration (GICv3.1+) + */ + struct irq_regs { + uint32_t icfgr[2]; + uint32_t ipriorityr[8]; + uint64_t irouter[32]; + uint32_t isactiver; + uint32_t isenabler; + } *irqs; + } dist; + + /* have only one rdist structure for last running CPU during suspend */ + struct redist_ctx { + uint32_t ctlr; + /* TODO: handle case when we have more than 16 PPIs (GICv3.1+) */ + uint32_t icfgr[2]; + uint32_t igroupr; + uint32_t ipriorityr[8]; + uint32_t isactiver; + uint32_t isenabler; + } rdist; + + struct cpu_ctx { + uint32_t ctlr; + uint32_t pmr; + uint32_t bpr; + uint32_t sre_el2; + uint32_t grpen; + } cpu; +}; + +static struct gicv3_ctx gicv3_ctx; + +static void __init gicv3_alloc_context(void) +{ + uint32_t blocks = DIV_ROUND_UP(gicv3_info.nr_lines, 32); + + /* We don't have ITS support for suspend */ + if ( gicv3_its_host_has_its() ) + return; + + /* The spec allows for systems without any SPIs */ + if ( blocks > 1 ) + { + gicv3_ctx.dist.irqs = xzalloc_array(typeof(*gicv3_ctx.dist.irqs), + blocks - 1); + if ( !gicv3_ctx.dist.irqs ) + printk(XENLOG_ERR "Failed to allocate memory for GICv3 suspend context\n"); + } +} + +static void gicv3_disable_redist(void) +{ + void __iomem* waker = GICD_RDIST_BASE + GICR_WAKER; + + /* + * Avoid infinite loop if Non-secure does not have access to GICR_WAKER. + * See Arm IHI 0069H.b, 12.11.42 GICR_WAKER: + * When GICD_CTLR.DS == 0 and an access is Non-secure accesses to this + * register are RAZ/WI. + */ + if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) ) + return; + + writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, waker); + while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) == 0 ); +} + +static int gicv3_suspend(void) +{ + unsigned int i; + void __iomem *base; + typeof(gicv3_ctx.rdist)* rdist = &gicv3_ctx.rdist; + + /* TODO: implement support for ITS */ + if ( gicv3_its_host_has_its() ) + { + printk(XENLOG_ERR "GICv3: ITS suspend support is not implemented\n"); + return -ENOSYS; + } + + if ( !gicv3_ctx.dist.irqs && gicv3_info.nr_lines > NR_GIC_LOCAL_IRQS ) + { + printk(XENLOG_ERR "GICv3: suspend context is not allocated!\n"); + return -ENOMEM; + } + + /* Save GICC configuration */ + gicv3_ctx.cpu.ctlr = READ_SYSREG(ICC_CTLR_EL1); + gicv3_ctx.cpu.pmr = READ_SYSREG(ICC_PMR_EL1); + gicv3_ctx.cpu.bpr = READ_SYSREG(ICC_BPR1_EL1); + gicv3_ctx.cpu.sre_el2 = READ_SYSREG(ICC_SRE_EL2); + gicv3_ctx.cpu.grpen = READ_SYSREG(ICC_IGRPEN1_EL1); + + gicv3_disable_interface(); + gicv3_disable_redist(); + + /* Save GICR configuration */ + gicv3_redist_wait_for_rwp(); + + base = GICD_RDIST_SGI_BASE; + + rdist->ctlr = readl_relaxed(base + GICR_CTLR); + + /* Save priority on PPI and SGI interrupts */ + for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) + rdist->ipriorityr[i] = readl_relaxed(base + GICR_IPRIORITYR0 + 4 * i); + + rdist->isactiver = readl_relaxed(base + GICR_ISACTIVER0); + rdist->isenabler = readl_relaxed(base + GICR_ISENABLER0); + rdist->igroupr = readl_relaxed(base + GICR_IGROUPR0); + rdist->icfgr[0] = readl_relaxed(base + GICR_ICFGR0); + rdist->icfgr[1] = readl_relaxed(base + GICR_ICFGR1); + + /* Save GICD configuration */ + gicv3_dist_wait_for_rwp(); + gicv3_ctx.dist.ctlr = readl_relaxed(GICD + GICD_CTLR); + + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + { + typeof(gicv3_ctx.dist.irqs) irqs = gicv3_ctx.dist.irqs + i - 1; + unsigned int irq; + + base = GICD + GICD_ICFGR + 8 * i; + irqs->icfgr[0] = readl_relaxed(base); + irqs->icfgr[1] = readl_relaxed(base + 4); + + base = GICD + GICD_IPRIORITYR + 32 * i; + for ( irq = 0; irq < 8; irq++ ) + irqs->ipriorityr[irq] = readl_relaxed(base + 4 * irq); + + base = GICD + GICD_IROUTER + 32 * i; + for ( irq = 0; irq < 32; irq++ ) + irqs->irouter[irq] = readq_relaxed_non_atomic(base + 8 * irq); + + irqs->isactiver = readl_relaxed(GICD + GICD_ISACTIVER + 4 * i); + irqs->isenabler = readl_relaxed(GICD + GICD_ISENABLER + 4 * i); + } + + return 0; +} + +static void gicv3_resume(void) +{ + unsigned int i; + void __iomem *base; + typeof(gicv3_ctx.rdist)* rdist = &gicv3_ctx.rdist; + + writel_relaxed(0, GICD + GICD_CTLR); + + for ( i = NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i += 32 ) + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4); + + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + { + typeof(gicv3_ctx.dist.irqs) irqs = gicv3_ctx.dist.irqs + i - 1; + unsigned int irq; + + base = GICD + GICD_ICFGR + 8 * i; + writel_relaxed(irqs->icfgr[0], base); + writel_relaxed(irqs->icfgr[1], base + 4); + + base = GICD + GICD_IPRIORITYR + 32 * i; + for ( irq = 0; irq < 8; irq++ ) + writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); + + base = GICD + GICD_IROUTER + 32 * i; + for ( irq = 0; irq < 32; irq++ ) + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); + + writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLER + i * 4); + writel_relaxed(irqs->isenabler, GICD + GICD_ISENABLER + i * 4); + + writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVER + i * 4); + writel_relaxed(irqs->isactiver, GICD + GICD_ISACTIVER + i * 4); + } + + writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); + gicv3_dist_wait_for_rwp(); + + /* Restore GICR (Redistributor) configuration */ + gicv3_enable_redist(); + + base = GICD_RDIST_SGI_BASE; + + writel_relaxed(0xffffffff, base + GICR_ICENABLER0); + gicv3_redist_wait_for_rwp(); + + for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) + writel_relaxed(rdist->ipriorityr[i], base + GICR_IPRIORITYR0 + i * 4); + + writel_relaxed(rdist->isactiver, base + GICR_ISACTIVER0); + + writel_relaxed(rdist->igroupr, base + GICR_IGROUPR0); + writel_relaxed(rdist->icfgr[0], base + GICR_ICFGR0); + writel_relaxed(rdist->icfgr[1], base + GICR_ICFGR1); + + gicv3_redist_wait_for_rwp(); + + writel_relaxed(rdist->isenabler, base + GICR_ISENABLER0); + writel_relaxed(rdist->ctlr, GICD_RDIST_BASE + GICR_CTLR); + + gicv3_redist_wait_for_rwp(); + + WRITE_SYSREG(gicv3_ctx.cpu.sre_el2, ICC_SRE_EL2); + isb(); + + /* Restore CPU interface (System registers) */ + WRITE_SYSREG(gicv3_ctx.cpu.pmr, ICC_PMR_EL1); + WRITE_SYSREG(gicv3_ctx.cpu.bpr, ICC_BPR1_EL1); + WRITE_SYSREG(gicv3_ctx.cpu.ctlr, ICC_CTLR_EL1); + WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1); + isb(); + + gicv3_hyp_init(); +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ + /* Set up the GIC */ static int __init gicv3_init(void) { @@ -1850,6 +2077,10 @@ static int __init gicv3_init(void) gicv3_hyp_init(); +#ifdef CONFIG_SYSTEM_SUSPEND + gicv3_alloc_context(); +#endif + out: spin_unlock(&gicv3.lock); @@ -1889,6 +2120,10 @@ static const struct gic_hw_operations gicv3_ops = { #endif .iomem_deny_access = gicv3_iomem_deny_access, .do_LPI = gicv3_do_LPI, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = gicv3_suspend, + .resume = gicv3_resume, +#endif }; static int __init gicv3_dt_preinit(struct dt_device_node *node, const void *data) diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h index 2af093e774..7e86309acb 100644 --- a/xen/arch/arm/include/asm/gic_v3_defs.h +++ b/xen/arch/arm/include/asm/gic_v3_defs.h @@ -56,6 +56,7 @@ #define GICD_TYPE_LPIS (1U << 17) #define GICD_CTLR_RWP (1UL << 31) +#define GICD_CTLR_DS (1U << 6) #define GICD_CTLR_ARE_NS (1U << 4) #define GICD_CTLR_ENABLE_G1A (1U << 1) #define GICD_CTLR_ENABLE_G1 (1U << 0) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105398.1456325 (Exim 4.92) (envelope-from ) id 1utCjK-00059O-4Z; Mon, 01 Sep 2025 22:10:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105398.1456325; Mon, 01 Sep 2025 22: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 1utCjK-00059E-0I; Mon, 01 Sep 2025 22:10:26 +0000 Received: by outflank-mailman (input) for mailman id 1105398; Mon, 01 Sep 2025 22:10: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 1utCjJ-00055o-3U for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:25 +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 7483f7db-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:23 +0200 (CEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55f69cf4b77so3061750e87.2 for ; Mon, 01 Sep 2025 15:10:23 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7483f7db-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764622; x=1757369422; darn=lists.xenproject.org; h=content-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=fvkpboOPpIPZqSscUPtg/Z76SMQfSVSgyWtvLFMB+e77wAGZNfS1+RTmUkI8Yh0/K0 j/8RJZPDSfXagf4U8b6zMiT8N98eyUnjQZoLSABwSd5BYkUx0lyYWPhVE6HObDMMiU/U DquxnS2pm+5MmI4DXXcx2NE068a1S7ccWaPmwwCuqMnXfGzL7g4RgAzG5r/JNEN+3XHb 3CMSWd6VVlHcEjOjkGbjnPYRFjgwUsNNVBkCLNrYodMqQaaTqjRPJiX+VdFHZcBRzHgn ne5TgdqAhnWGSRtuoQz46IP5nzYsZHHxlexX0kEgrCPG+pZe0qaI+jcV2sx80egOT3oG vSEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764622; x=1757369422; 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=gKqHKcJgQ9rkGKHQxsJqkwwq044hAh4w6MYGhNELLa/Fki/JqckR/TE1rR8M52r9fF oGjtnuzhWwVmBkmELiJzr5gztMB/rthic3K271mRGv8uAswNlkWtwGmfUd5IDUxBHl6H TfR7BYK6r2wgkL7Xtt9XjC/p2m1NclM1y9tnwMwVVGMjadjedUAIOFY49YMyNtw6m74g b6iUYrlBWRCiMTcLjXskhE0Boz8ZoW5JJKyLtLJuwWk3twM/nz4sABs+hGJQEBsH2DKn 6qUuytNe6LgUyGTVV6MxU2MgtN43rnaZuof64mTDCs2Ct3jDR57m/fBwKuBab2wGxWvZ WdRg== X-Gm-Message-State: AOJu0YzMgqrsNEIFjvPTxqrordlfVR9y6/K/eFrC1x56DxibJT2zXhcR D9ms/bMNVfioVUF9/Yo72TVQHCEqstTJkfwpmK0cPcl17cW1sKIJN2oeqtd9EYEm X-Gm-Gg: ASbGncuATfkl59L6zA4qqJSStTS2rg+1iy44bkMROeGKlPHjAoskQus7uZB7vzV3+3h YaJ83Sk5duw7Uf8gikViYZ+8/uQBkCR80Y29GbBDHh3h4xVc48R6XSKofw9kcNl/M4KEZ4DAxbG VdSiuc0wRIUviIOO1oXXK/wP+hxOMXFP8Atk4NOPiS4ujacucEOqNn9WA19E4nm8tWq5AJkpHK5 WqyATTWSipjnlyWar3FRK76YZOOE4ivDYf3fJ1ltJtf6C9TsjKxpS/V0ImnMkNR069JFcysPxmV v7ykoF9IdU7bPhQM2KWK2HrAjmM3NAt1ExBcorlELQA4gW8w6Leea+y61ioU5yRw+D+86DRQR2z MnN6gtR7Los7wtQnv+xLJrvr4ccwTgsBKYPBR/77/9RE2EdFVHAxWQLZ1rG77y6iph2duIqeP X-Google-Smtp-Source: AGHT+IE0nct2I3ZXnzBAVzjS0A2t7RZ46uqQlrsxxAbmvZQR2mhhoN8TLctbHGFrjJ6lWGC/3qLOrw== X-Received: by 2002:a05:6512:1409:b0:55f:6831:6ee7 with SMTP id 2adb3069b0e04-55f708b60e7mr2174676e87.21.1756764622048; Mon, 01 Sep 2025 15:10:22 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykola Kvach Subject: [PATCH v6 01/13] xen/arm: Add suspend and resume timer helpers Date: Tue, 2 Sep 2025 01:10:05 +0300 Message-ID: <781c8e1b3a4d9b269bfde125072a84baae3f9bb3.1756763487.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 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 Sep 01 22:10:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105400.1456344 (Exim 4.92) (envelope-from ) id 1utCjN-0005bs-O3; Mon, 01 Sep 2025 22:10:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105400.1456344; Mon, 01 Sep 2025 22:10:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjN-0005bH-IT; Mon, 01 Sep 2025 22:10:29 +0000 Received: by outflank-mailman (input) for mailman id 1105400; Mon, 01 Sep 2025 22:10:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjM-0005XP-2Y for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:28 +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 76fca5fb-8780-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:10:27 +0200 (CEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55f7039aa1eso2190788e87.1 for ; Mon, 01 Sep 2025 15:10:27 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 76fca5fb-8780-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764626; x=1757369426; darn=lists.xenproject.org; h=content-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=claAnoGUSFMYFARQ+oTnePrqKOC6QAQ+IRoEf91ZFiM=; b=bl/q8yyy9+exPnPGrmq279pz/L584xBgnnBm8a78VPJ1aEh2Ht5A2y2BgaMus3+YJy f5TAcQmYaJ6Xae7tU2lsfgMsh7uoTlNCrV4mRKB0Ub41nmV34sJnghKiYyd6DutS+Q1p Ldh6Zswb/RV+dqo/pu+e7Stqp5NcIItGa/2pej4fMkRfV8oixb+GwHfTCerT0TC8SRTD b+a3R/mnkootOl5E6WPrlE0fsRltHS67Ig+GpjAeQAsmOZwARH+5keKzIcJAKJR/6DRg kJvGvN6GSO3b803ED2mpSyuyqdnTdFHi6NZSYauTrwiFt4AkmgwELx4oUHY5FHLrOgX4 UVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764626; x=1757369426; 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=claAnoGUSFMYFARQ+oTnePrqKOC6QAQ+IRoEf91ZFiM=; b=MURouoznv9hN/Bi09PJTb8xQ3znN325wa8WrL6iSac7XCdi1ZR7fGnj0N6XKd8YRRf zK8qJzRZSqZEpJ8IfIfo/U6KtasIzhznGgJWz3bPLINHHcwnix82tnlYCrsIMohe1eGw Lz9ujVk0UuFE3Lmle7SbxElIxHNolSsH6KQ5cbf35emRBHatwOlbquICnpQ9FVbeLd5u ucD9WA1Km614993lwY5vwwYLHVYGO1ODY2q2j/SB2MAgI/UkupcO90e4Z5A7oPAWMGER qhVPftmMG917DUCI3wTYBBBMNenXXmJ1iz4jD2F8jGF4qTYSxjOxMhXCipkGlAba+nPl bS0g== X-Gm-Message-State: AOJu0YwGpID7Hd0p0G6ma7BrNGj9Uu3VfXxPT37HmROZgrdL8JYabKnv p+h/gNx8iP7Iok9pRZ9/EFyBQSi50vbjObqaR18l4JM/9MRnstd76Ra0fFrFQYj6 X-Gm-Gg: ASbGnctmsCvSdQakgvH4Jc6Q8D8LN3NaOC4muNg968DKCK96mKJFwbyooymT5ABHOfo SbksPtsD+M+f0z1TZcsSj/V7u2iAvP5W/yvAGC3JD9cQzTgTu6Kw3oNRQGS2Ivm6adw3Giehj4y 3MoCPMYvqaBoyaRq8EwQhICaHcqkk6ceNGdbnvVvRTrnQjxAkHJ1byPosRNLS3Fh5sGUEU/7FL7 3xq23yZP0uRFNtTVmBxd3fpyueglHvbgNVsQAwgZV4uRAWskjJC4HwaeSLpRZkTFHQNHIcX6O25 N84+jk+zu/5TxFTcLt2+ff3CldmUGdn2OKinbR+vz1CSMl76IRg7Mu5LNvFAKdzfEcr1Y2sNCxJ 4/S1rgd4Qmz8/aVu6RyddlUb6xU6udGdKHUbk6WPKxcuI3bNw565x2+88np9PQRUZ5GRuAbkA X-Google-Smtp-Source: AGHT+IHlRsA6VSEbFS7n1dHyaPDUYiGqNPk98LgH9nIWFqTNJk8rBvrkVuVXOyy9dbnfiE6iP+ROeQ== X-Received: by 2002:a19:6b18:0:b0:560:827f:9ff6 with SMTP id 2adb3069b0e04-560827fa7cfmr125919e87.57.1756764626205; Mon, 01 Sep 2025 15:10:26 -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 v6 04/13] xen/arm: Don't release IRQs on suspend Date: Tue, 2 Sep 2025 01:10:08 +0300 Message-ID: <293acbb653b5f4d5bf71dc459f9de3e729bff3e1.1756763487.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 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 V6: - skipping of IRQ release during system suspend is now handled inside release_irq(). 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 | 3 +++ xen/arch/arm/irq.c | 3 +++ xen/arch/arm/tee/ffa_notif.c | 2 +- xen/arch/arm/time.c | 11 +++++++---- 4 files changed, 14 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index a018bd7715..c64481faa7 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); } diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 02ca82c089..361496a6d0 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -300,6 +300,9 @@ void release_irq(unsigned int irq, const void *dev_id) unsigned long flags; struct irqaction *action, **action_ptr; + if ( system_state == SYS_STATE_suspend ) + return; + desc = irq_to_desc(irq); spin_lock_irqsave(&desc->lock,flags); diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 86bef6b3b2..4835e25619 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -363,7 +363,7 @@ void ffa_notif_init_interrupt(void) { int ret; - if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI ) + if ( fw_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..8267fa5191 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"); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105401.1456350 (Exim 4.92) (envelope-from ) id 1utCjO-0005kG-6c; Mon, 01 Sep 2025 22:10:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105401.1456350; Mon, 01 Sep 2025 22:10: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 1utCjO-0005iZ-1E; Mon, 01 Sep 2025 22:10:30 +0000 Received: by outflank-mailman (input) for mailman id 1105401; Mon, 01 Sep 2025 22:10:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjM-0005XP-O4 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:28 +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 77a58396-8780-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:10:28 +0200 (CEST) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-55f78f32580so1211845e87.3 for ; Mon, 01 Sep 2025 15:10:28 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 77a58396-8780-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764627; x=1757369427; darn=lists.xenproject.org; h=content-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=Imh9qPLbn5GldmbHLssYKpBvOdimEk2erOhkD1ZB1X8=; b=la9/h4wyXouvgPLBUiIb+PFQZaA45R6xOBbtN4m5II8VC1xAlw/sWb3NjgQtnkD5pD 90aisZLNF9fZnxtDuD5wtofyTWfP9UaJKrHSstT4ja/gVDIl0tLTmwozNQSbfcDg2xRv /MJDalRCcA2Qq/cMxkL1FAV/EmCA+QneMsPIMrOrXHvOcrYmVfPVijrAbcEi9r/bFs5q OR1DJXr7f9W7CHs2kt30rJ1payZaEOsoM1jyZetqqUrFTnxgStnWRUvxu1D15DSXcy+c R+oxUOt8NHtem+mtWuHF5zbzi0XDXDXurm4qOpEzIbmBZJJhyyKmA8KvqHsWMqPanoEt mrog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764627; x=1757369427; 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=Imh9qPLbn5GldmbHLssYKpBvOdimEk2erOhkD1ZB1X8=; b=DTuGhUIXLcToMy6Qgo5XdlwYJkmXTf8XtOuYlG4wiFw5810G5pbGeBy2NjEbSK1XZF LFzrPf7wur0RF/BVWiUsE+2g5mMOuLFf9hci5gjdJt5asmoyvYTxlISovSoWnJa7GmbU 2axd8kn38uSyz2Aqsy1icKuexqacB4KxqBZU9xtkl8z8T6frcuAcQ0iaLka6y7N7xlZ+ w09F3bzcTwZ6JPOB4cUWr/CPpZv4msSaB4SZ+f+IzYBrMvGM/Z5Oq9SZ+S0FT/7yERP4 M+3f1K5o6FCTGteQz5jl9+ykAv3969sWQvOeDBWwPIeVr+ViDi/g7/db/H2wAOZEbybH 4E4w== X-Gm-Message-State: AOJu0Ywd3M5ROClHBIx89fCVlJ6l614G1cUNbwHDCUn6OdwRwvmoIFPE LQRSlSRO/I/aer3jDfnzUL1i0dsC/dJhz8sfM/UymTp4/AGq0jiwh3BKu+0Rum0l X-Gm-Gg: ASbGncuWAQtCPgMwZLfrpEm2fzX9E5YPH9bI5tg4WhEzEhPKS1VH03t5roP6Rw8YDaL EFLo2D1uQ3MpkdrYLdVxMs8QIlEA6skAndZrVJArhiodhh0XKWwZmJ0Pty5vSZOh7P5XJFziasL MHoZAyGCsmqDSzwo4V4NrE1lF6FvgIrsqcXKVX7J978T7MkfaQbvyN7az+dM0AofSBtrTvfB3oa wgD8dWpAFDmmkZAIZ0yYQ5FTmfTyB2KyFH/v81OZJeIrYvzw2FbD5yYBAn+n+hB9wHWZlYi/ECA uUanhG8EA2bd45IIvFkQOHkm5pCRtzR1U5KlZpjVeap5ELlmPmcwxFAPJnyQsrHN/mJlG/pdrgi qFE89X00YVz8tmeoEqWSx3QVGB1rTEbg9Ct6U3oSDi1aqHJknj7Qw1zqBOZJj+878PcRlp0vC X-Google-Smtp-Source: AGHT+IGv4DeyaoILJLzD1OzBQ513bzoPPJ1uc4pXtpi4SvI8+NvOPK8grxlS2JGjHTs+MQgDr7xIIw== X-Received: by 2002:a05:6512:2248:b0:55f:5195:9251 with SMTP id 2adb3069b0e04-55f708ec42bmr2709277e87.28.1756764627392; Mon, 01 Sep 2025 15:10:27 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Volodymyr Babchuk Subject: [PATCH v6 05/13] xen/arm: irq: avoid local IRQ descriptors reinit on system resume Date: Tue, 2 Sep 2025 01:10:09 +0300 Message-ID: <84acac884fa1df0ea64eef2253e75918d4b9245f.1756763487.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 Reviewed-by: Volodymyr Babchuk --- 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 361496a6d0..6c899347ca 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -125,6 +125,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 Sep 01 22:10:32 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105402.1456369 (Exim 4.92) (envelope-from ) id 1utCjQ-0006Ju-GV; Mon, 01 Sep 2025 22:10:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105402.1456369; Mon, 01 Sep 2025 22: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 1utCjQ-0006Jl-CJ; Mon, 01 Sep 2025 22:10:32 +0000 Received: by outflank-mailman (input) for mailman id 1105402; Mon, 01 Sep 2025 22:10: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 1utCjP-00055o-5I for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:31 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 787b9eec-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:29 +0200 (CEST) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-55f720ffe34so2422009e87.1 for ; Mon, 01 Sep 2025 15:10:29 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15: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: 787b9eec-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764629; x=1757369429; darn=lists.xenproject.org; h=content-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=h+LNbMBKwYezbM5EFVtZ7DgCmMZXO6MyvOXCUpxJxe0=; b=bCJownRWF8EZOLTdvoJVuxGdEXwx3yuoi+/VNSQxmVMKJfJrmeNXqFU7OYEolzIZRX EQwvlwdu0UBku8xSb63HPpD5hrl77TKs63OHnZDjBI0WvbALfM4IYOBNALZOc1YVCdxu fXG+zl/fMhEDyYel4+d8E09S0V0nvFekHkgKvfWguEI1v2GXXHaNGrkKkt3fUyEZzHmb fL48eTzwjAIK384Bu0v6ej5uE4nZlk5nsCSICqtbAu4hc7QUd2ZR839EUiLtnKjv7SKM 5v5uLtqpRUCL8y1+WS5P3REYHoEeq8isE5wfKhalXk8tteGwKmU3mMrccfc+Ire3UP+v BEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764629; x=1757369429; 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=h+LNbMBKwYezbM5EFVtZ7DgCmMZXO6MyvOXCUpxJxe0=; b=YYDUWaKos6KSJJMqtP7ktLNif3UiDsHeMQMCC15zBJ9znowBZSXQYtKovCwHJgPpfe d2jVLDTU3p2oNSwg6kx1ugc9tIcpSpODKhO9L8TwBym5K3yuV2MMRYbREdM0gmeCIyRN BOYg0AlTt3969JgzmbSgrHc4U7TcyBRRpo1l12utrdoJxvwy6Jmi7xC8fuCwnhPrO0KB yEBTvIVs+wxJW6SdgonjfMu6i1pU7jCRS/t3j2cTRGQBwXODKXN9UeHH1kmpVHiG91Vp JWNpsWFOj70g02qCHHQc6Ulc7EqwwVAAvGqC4AjyrCpcbEy04ihhN7RgleauDWESeemv HjDA== X-Gm-Message-State: AOJu0YzyNsbX4ZFM0X1y7xdZpYBxsZi0wfJLe0pW/ELoM45zG/0yW3RN DSHvpFv0OtOhyQnk0V4KY3X8PlgwtS/MAs9lx0qI86dym0c/yXSp4d0nZ6PGFGPF X-Gm-Gg: ASbGnctnHwkRWqsMmslDb1PCSHDiUBY+yn31zweN4qCkBeAfsmN27RbplFwfmbPnZaQ 1IPlJukAKC9nB8DLY2HiA+G5tiVEC4BfK0mT6JPPRGdY0tZG4C8r9bxnEEbsHcTxutZb/cnybNx 3ghrR5SLK9C/LTnpGdafWf99Q1ojccX/LSaef3GItazVHpL5OHCKqzwd21xghCdfrM2Ca7z83/R GwWFqp/RHC8uCCsf5BL1BP6aQ3Xljh9lWiNBH6yYry8Y8K6OAeaqzInPI1JtRXC3LCHLI8Fl/6E VXmZ0gKUggoKSQ70BJId0TETYYyaVOWUkh0tiDHL2Kg3nqsZ/TI2NNYw0VL7JyuvtTJEqX7oHeW JnYhHh/IQ9Vdbf0QSGMDDd87LH3mS6KeTjIMSMLI2vp4PJCEkyEHy00jJrPDH/cxH7+6L1SbXd1 fs7zvq3Bc= X-Google-Smtp-Source: AGHT+IEa5RjJ2GSGquDO+Z4AQEB5nVu4GpDaAJNmK102svb69HNEnk3KnmcyEzQrF2S0OM2mun/7QA== X-Received: by 2002:ac2:58e9:0:b0:55f:67c6:be48 with SMTP id 2adb3069b0e04-55f6f6ab662mr1948372e87.1.1756764628474; Mon, 01 Sep 2025 15:10:28 -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 v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume Date: Tue, 2 Sep 2025 01:10:10 +0300 Message-ID: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.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 --- Changes in V6: - Call handler->disable() instead of just setting the _IRQ_DISABLED flag - Move the system state check outside of restore_local_irqs_on_resume() --- xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 6c899347ca..ddd2940554 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -116,6 +116,41 @@ 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; + + 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; + } + + /* Disable the IRQ to avoid assertions in the following calls */ + desc->handler->disable(desc); + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); + 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) { @@ -134,6 +169,10 @@ 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: + if ( system_state == SYS_STATE_resume ) + restore_local_irqs_on_resume(); + break; } return notifier_from_errno(rc); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:33 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105403.1456373 (Exim 4.92) (envelope-from ) id 1utCjQ-0006Nn-Tv; Mon, 01 Sep 2025 22:10:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105403.1456373; Mon, 01 Sep 2025 22: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 1utCjQ-0006MQ-OF; Mon, 01 Sep 2025 22:10:32 +0000 Received: by outflank-mailman (input) for mailman id 1105403; Mon, 01 Sep 2025 22: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 1utCjP-0005XP-Gv for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:31 +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 7927e6f3-8780-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:10:30 +0200 (CEST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-55f7b6e4145so1330704e87.1 for ; Mon, 01 Sep 2025 15:10:30 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7927e6f3-8780-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764630; x=1757369430; darn=lists.xenproject.org; h=content-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=RY9tX/c5T2T5//S4piNjlgD25sf5vU9/GmLRb02Wl1w=; b=XVAO+pdutTd1AVWu2A18pCKhyfR6/QhArEcEJ7X3+UTFtlM/oJ9Cy/qe6lmWvBLSnU W8rfxGND1yHwimQgs/cMVsJMad1BPYGQN9y0Cl3dsFh5OvIkYTmwEJIlNhcbrIDm4UM+ aKw3bTlXu3zlKLUwLYXXgiQaZFhtqrHQ7pDjfKLt7bdnKGCdSncNslurzFXY9dAMXF1i C6jvYlxu8fF1yR32WsIu6GzUgywRGya6P3IkLAfjFll0qjaI+n9/Xrnz1oPKkifMvrwU bn/gXOcj2zsp+NPlUU1Fv8Wif8nU9DcLVpLxXB7atTrJ5qSkKCDH1XymDV5X6pezRbBK gEtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764630; x=1757369430; 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=RY9tX/c5T2T5//S4piNjlgD25sf5vU9/GmLRb02Wl1w=; b=dwpBemIhreX5Y7mic3+KIwzrMMNjTYbu63IQNz+EW8dYauFOEXBpLuwCKxSXqeWpPy Jj8m0hEm5ubw4YVMU8DkYQpd8rzxg31AnuKSq2FgCQjyhA+tGeA84N6cH+Vd+BIbBbZd dNlQyhGwg7jIXv6vKfYhrjNl4riMym6DP1IfU4tX0NPnB+JxVu/nfkydB/kM1KAer1pD h82njPNp2bvsIBa3YZdqrm8jSWLjk5SzJ/d27MisnlUbDnRAQ94mvlwFgOJLMHDXjdfz BNbCOcyzMiet/nBtzDMj5zhSHzMM0g1Ns9OLRgeQ5Ndy6Q5wTutgg3YsHBixkaKFEkZ3 jmEg== X-Gm-Message-State: AOJu0YxcAJX7JeNY3sM6JxdWw/Gd15b4CUWFrNfg3wt0Wo6aATpxJSJb va5DLK7WRlAhcpKRKtc6JjAgs63yif4EC83eJO7+8Rs6bQMMAkpe3DE2hJfUV9fu X-Gm-Gg: ASbGnctGeLmsAG2+gOEXpO+u7BkNVmQyya/6toY8/EqzdwtGEWokrzmUYleOTQUVRsZ JA0TzUy6NIyGQNn9eGA70TiB/85d+XWEDVct6eidFI5NPHhRADVugqEY3fDL8axr2PcrfMw7xwQ SYzm+5plEIX0NnHmOCcO9mhtm90FneLtJ3bfN1GTbs41+E1uAIwKyxpIZb3SuKWnhcjm+7TTy0i n4XaUlulaWlTRO0r/sRYk7+RvxXMZIp8N2PkvA4Z8wHbzegQU18nGExiWgxlus9ocFFilUqjDIb SbPbBv2mUn4uNRngECfZKk3HEsVhAJLESm2QBIipbfSO8ZOB2GUAiFv6XelQ3pzChIJ3RkJF+JX caK9ollVKydjbOMX2XJZ0s/j6Eo9ccJN62fp/ReNaM8xUgM/ZGB6qvFAY5SmAnlFJ0i1GMq2K X-Google-Smtp-Source: AGHT+IEkwBm4cpJTQnKBoX8tD+SaJ/XRbp9ktMXnYGjhR+0nJcJbopep6TTT4iDCLZRyqgZKntvLtQ== X-Received: by 2002:a05:6512:2610:b0:55f:3f03:946d with SMTP id 2adb3069b0e04-55f708b60dcmr2388583e87.23.1756764629748; Mon, 01 Sep 2025 15:10:29 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Mykola Kvach Subject: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Date: Tue, 2 Sep 2025 01:10:11 +0300 Message-ID: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.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: Oleksandr Tyshchenko Store and restore active context and micro-TLB registers. Tested on R-Car H3 Starter Kit. Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Mykola Kvach --- Changes in V6: - refactor code related to hw_register struct, from now it's called ipmmu_reg_ctx --- xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 +++++++++++++++++++++++ 1 file changed, 257 insertions(+) diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c index ea9fa9ddf3..0973559861 100644 --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c @@ -71,6 +71,8 @@ }) #endif +#define dev_dbg(dev, fmt, ...) \ + dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__) #define dev_info(dev, fmt, ...) \ dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__) #define dev_warn(dev, fmt, ...) \ @@ -130,6 +132,24 @@ struct ipmmu_features { unsigned int imuctr_ttsel_mask; }; +#ifdef CONFIG_SYSTEM_SUSPEND + +struct ipmmu_reg_ctx { + unsigned int imttlbr0; + unsigned int imttubr0; + unsigned int imttbcr; + unsigned int imctr; +}; + +struct ipmmu_vmsa_backup { + struct device *dev; + unsigned int *utlbs_val; + unsigned int *asids_val; + struct list_head list; +}; + +#endif + /* Root/Cache IPMMU device's information */ struct ipmmu_vmsa_device { struct device *dev; @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device { struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX]; unsigned int utlb_refcount[IPMMU_UTLB_MAX]; const struct ipmmu_features *features; +#ifdef CONFIG_SYSTEM_SUSPEND + struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX]; +#endif }; /* @@ -547,6 +570,222 @@ static void ipmmu_domain_free_context(struct ipmmu_vmsa_device *mmu, spin_unlock_irqrestore(&mmu->lock, flags); } +#ifdef CONFIG_SYSTEM_SUSPEND + +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock); +static LIST_HEAD(ipmmu_devices_backup); + +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX]; + +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu, + unsigned int utlb) +{ + return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb))); +} + +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu) +{ + struct ipmmu_vmsa_backup *backup_data; + + dev_dbg(mmu->dev, "Handle micro-TLBs backup\n"); + + spin_lock(&ipmmu_devices_backup_lock); + + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) + { + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); + unsigned int i; + + if ( to_ipmmu(backup_data->dev) != mmu ) + continue; + + for ( i = 0; i < fwspec->num_ids; i++ ) + { + unsigned int utlb = fwspec->ids[i]; + + backup_data->asids_val[i] = ipmmu_imuasid_read(mmu, utlb); + backup_data->utlbs_val[i] = ipmmu_imuctr_read(mmu, utlb); + } + } + + spin_unlock(&ipmmu_devices_backup_lock); +} + +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu) +{ + struct ipmmu_vmsa_backup *backup_data; + + dev_dbg(mmu->dev, "Handle micro-TLBs restore\n"); + + spin_lock(&ipmmu_devices_backup_lock); + + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) + { + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); + unsigned int i; + + if ( to_ipmmu(backup_data->dev) != mmu ) + continue; + + for ( i = 0; i < fwspec->num_ids; i++ ) + { + unsigned int utlb = fwspec->ids[i]; + + ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]); + ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]); + } + } + + spin_unlock(&ipmmu_devices_backup_lock); +} + +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *domain) +{ + struct ipmmu_vmsa_device *mmu = domain->mmu->root; + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; + + dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->context_id); + + regs->imttlbr0 = ipmmu_ctx_read_root(domain, IMTTLBR0); + regs->imttubr0 = ipmmu_ctx_read_root(domain, IMTTUBR0); + regs->imttbcr = ipmmu_ctx_read_root(domain, IMTTBCR); + regs->imctr = ipmmu_ctx_read_root(domain, IMCTR); +} + +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *domain) +{ + struct ipmmu_vmsa_device *mmu = domain->mmu->root; + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; + + dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->context_id); + + ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0); + ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0); + ipmmu_ctx_write_root(domain, IMTTBCR, regs->imttbcr); + ipmmu_ctx_write_all(domain, IMCTR, regs->imctr | IMCTR_FLUSH); +} + +/* + * Xen: Unlike Linux implementation, Xen uses a single driver instance + * for handling all IPMMUs. There is no framework for ipmmu_suspend/resume + * callbacks to be invoked for each IPMMU device. So, we need to iterate + * through all registered IPMMUs performing required actions. + * + * Also take care of restoring special settings, such as translation + * table format, etc. + */ +static int __must_check ipmmu_suspend(void) +{ + struct ipmmu_vmsa_device *mmu; + + if ( !iommu_enabled ) + return 0; + + printk(XENLOG_DEBUG "ipmmu: Suspending ...\n"); + + spin_lock(&ipmmu_devices_lock); + + list_for_each_entry( mmu, &ipmmu_devices, list ) + { + if ( ipmmu_is_root(mmu) ) + { + unsigned int i; + + for ( i = 0; i < mmu->num_ctx; i++ ) + { + if ( !mmu->domains[i] ) + continue; + ipmmu_domain_backup_context(mmu->domains[i]); + } + } + else + ipmmu_utlbs_backup(mmu); + } + + spin_unlock(&ipmmu_devices_lock); + + return 0; +} + +static void ipmmu_resume(void) +{ + struct ipmmu_vmsa_device *mmu; + + if ( !iommu_enabled ) + return; + + printk(XENLOG_DEBUG "ipmmu: Resuming ...\n"); + + spin_lock(&ipmmu_devices_lock); + + list_for_each_entry( mmu, &ipmmu_devices, list ) + { + uint32_t reg; + + /* Do not use security group function */ + reg = IMSCTLR + mmu->features->control_offset_base; + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP); + + if ( ipmmu_is_root(mmu) ) + { + unsigned int i; + + /* Use stage 2 translation table format */ + reg = IMSAUXCTLR + mmu->features->control_offset_base; + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2PTE); + + for ( i = 0; i < mmu->num_ctx; i++ ) + { + if ( !mmu->domains[i] ) + continue; + ipmmu_domain_restore_context(mmu->domains[i]); + } + } + else + ipmmu_utlbs_restore(mmu); + } + + spin_unlock(&ipmmu_devices_lock); +} + +static int ipmmu_alloc_ctx_suspend(struct device *dev) +{ + struct ipmmu_vmsa_backup *backup_data; + unsigned int *utlbs_val, *asids_val; + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); + + utlbs_val = xzalloc_array(unsigned int, fwspec->num_ids); + if ( !utlbs_val ) + return -ENOMEM; + + asids_val = xzalloc_array(unsigned int, fwspec->num_ids); + if ( !asids_val ) + { + xfree(utlbs_val); + return -ENOMEM; + } + + backup_data = xzalloc(struct ipmmu_vmsa_backup); + if ( !backup_data ) + { + xfree(utlbs_val); + xfree(asids_val); + return -ENOMEM; + } + + backup_data->dev = dev; + backup_data->utlbs_val = utlbs_val; + backup_data->asids_val = asids_val; + + spin_lock(&ipmmu_devices_backup_lock); + list_add(&backup_data->list, &ipmmu_devices_backup); + spin_unlock(&ipmmu_devices_backup_lock); + + return 0; +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ + static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) { uint64_t ttbr; @@ -559,6 +798,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) return ret; domain->context_id = ret; +#ifdef CONFIG_SYSTEM_SUSPEND + domain->mmu->root->reg_backup[ret] = &root_pgtable[ret]; +#endif /* * TTBR0 @@ -615,6 +857,9 @@ static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain) ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH); ipmmu_tlb_sync(domain); +#ifdef CONFIG_SYSTEM_SUSPEND + domain->mmu->root->reg_backup[domain->context_id] = NULL; +#endif ipmmu_domain_free_context(domain->mmu->root, domain->context_id); } @@ -1427,6 +1672,14 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) } #endif +#ifdef CONFIG_SYSTEM_SUSPEND + if ( ipmmu_alloc_ctx_suspend(dev) ) + { + dev_err(dev, "Failed to allocate context for suspend\n"); + return -ENOMEM; + } +#endif + dev_info(dev, "Added master device (IPMMU %s micro-TLBs %u)\n", dev_name(fwspec->iommu_dev), fwspec->num_ids); @@ -1492,6 +1745,10 @@ static const struct iommu_ops ipmmu_iommu_ops = .unmap_page = arm_iommu_unmap_page, .dt_xlate = ipmmu_dt_xlate, .add_device = ipmmu_add_device, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = ipmmu_suspend, + .resume = ipmmu_resume, +#endif }; static __init int ipmmu_init(struct dt_device_node *node, const void *data) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105404.1456387 (Exim 4.92) (envelope-from ) id 1utCjS-0006lP-Ax; Mon, 01 Sep 2025 22:10:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105404.1456387; Mon, 01 Sep 2025 22:10: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 1utCjS-0006kP-5G; Mon, 01 Sep 2025 22:10:34 +0000 Received: by outflank-mailman (input) for mailman id 1105404; Mon, 01 Sep 2025 22:10: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 1utCjQ-0005XP-Gp for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:32 +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 79e20492-8780-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:10:31 +0200 (CEST) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-55f7ad815ceso1676658e87.3 for ; Mon, 01 Sep 2025 15:10:31 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 79e20492-8780-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764631; x=1757369431; darn=lists.xenproject.org; h=content-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=pux8zQR0d0n5/4MKkffDUfDraLZ/szsPvbUCV13VP9s=; b=PGGhcZ/hfRBGET+34FZXXy8e9qfhTeoJKvb0IdwX+Ak+g0G97wyBa26UM7q0xp43jI gq/fsySj86GTvTPOPUVlgZTyZicgN9pMkqlr85sGakaQeYQdmh9RQBjnJ4nvUUbEB3h0 xaicmoCEs7a8vEPdS/2PG9twkX76E1FY6mSau1bgjeLXHZVjNgqQBeY9GO2gFQB0iLwN pxwUdc2pAQc0qMhab4xCzgs8wmdWf2+OQyKNrc55WRj1JMzriure58cY1J9eEKFZfu8N +YnrwHNmG0lA63ccmbrXAbCoUEhESIXDN4S2HeMYTQ6x4sFKLLzepyfuVIWvcZvEXjU9 5tXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764631; x=1757369431; 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=pux8zQR0d0n5/4MKkffDUfDraLZ/szsPvbUCV13VP9s=; b=uQsueeDGTNzsWjuH/K+YRLhIGDR+jjCoIml4wkolRxMpHMNvGLX3k+C5aXone2kFUu +UqIWI4dfgeEmuau/BnjWUKxTyFYcPigvRe0+dQDBQ2oAPeXKQ/nlCkkl9fWGGMCbUk9 C549kJeWLovTEyee0a6Bpsqs4HkzUaHVo4qzSqusE/4F6qOoVpoSl+9wXSSKeowjTYzb tbhFDxJwNZaWojYrd6vwgVoHEmAd2hJ2BxMrYknyHGZ+ntofIGImnkMNoXIp3i/p7Gfj 9QJQQBLp0tKu2jBiyKJyXzKvrCYaJ06kLx9KEYeAr8KOBeHEOOZfsdyQKlXds7iGN1ts mZWg== X-Gm-Message-State: AOJu0YwIaqPx7/xzKFkBzl5kO6Gd937/V3oa6KsUlwZKnDpqTnZE/fB3 8AfeoVGjfRCLJlBQs0832tvLz39NfrMjQ3h4Fr0vw9a+pvCv5dSKnCJ/iDSzHbDm X-Gm-Gg: ASbGncteqzkOOGFq9iF6sSGTRZ6kyYuDVoLndEqiQ7gyXNsoO5h5vdy1ys7t8GgYqDC TtNZi7CIduHgzSNDVRgbOei47yjXW3JtzqpMvg+mwuTio/BxNkribCwhzMTGMKObpYTFquNmeZJ 3GbpW98AURgh4zRD82lsgc4PHzl0dfCLYZjM8KuNT7O0ijJ4QaYtqnePyNtw80G0Otv33KoJYD3 qxSkH2z6ctMRHunXMRhvLNEx0ohtTizevPLLrd1hRYypGeyahkYK32opul8GUUJUcqbS53Usi6F Ul/G2mqORPHdRUkYuzh/J0TNroyPMkvONugHsaN7GR+pE8QzoGz7c6pX/RfpXy4kbfPMJeXZkl5 uAD8Lh3/YR0zyyTk5yBcr6o1EN/2+0/6LbsclHZEheaa+ZNwlJT0FH7iicqklaV0H0S485yC4 X-Google-Smtp-Source: AGHT+IHac5NYtAevecrJdPsnvQsSQwBeZX1PPUz7eIaje6LakHkn37It/dfRC3WdGHf3MYfBkW7PZQ== X-Received: by 2002:a05:6512:2c94:b0:55f:5b65:a3e3 with SMTP id 2adb3069b0e04-55f7093e96amr2529872e87.35.1756764631025; Mon, 01 Sep 2025 15:10:31 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Subject: [PATCH v6 08/13] xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface) Date: Tue, 2 Sep 2025 01:10:12 +0300 Message-ID: <20b6774cafc2d4d6c92c220d3aa94a666d55c930.1756763487.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 v6: - move calling of call_psci_system_suspend to commit that implements system_suspend call Changes in v4: - select the appropriate PSCI SYSTEM_SUSPEND function ID based on platform - 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 | 22 ++++++++++++++++++++++ xen/arch/arm/psci.c | 23 ++++++++++++++++++++++- 4 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/include/asm/suspend.h 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 new file mode 100644 index 0000000000..7e04c6e915 --- /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 + +void hyp_resume(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/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) ) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:35 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105405.1456394 (Exim 4.92) (envelope-from ) id 1utCjT-0006wl-5L; Mon, 01 Sep 2025 22:10:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105405.1456394; Mon, 01 Sep 2025 22:10: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 1utCjS-0006w4-QJ; Mon, 01 Sep 2025 22:10:34 +0000 Received: by outflank-mailman (input) for mailman id 1105405; Mon, 01 Sep 2025 22:10: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 1utCjR-0005XP-G1 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:33 +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 75835772-8780-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:10:24 +0200 (CEST) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-55f78f32580so1211819e87.3 for ; Mon, 01 Sep 2025 15:10:24 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 75835772-8780-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764624; x=1757369424; darn=lists.xenproject.org; h=content-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=knhQ+S9mPkiwhWSXwrIQ0d+Hly1TQbR8zGjL18AowhY=; b=H+krl55qPWvuR2EzNnszNP6eR9gGVNB5M8OlNOFjTSHP3a96Nn8NB7izJdS3zhwguU 4tR9PmkYV2i7kuFhX4jwTnfGPSYnBPh7mc2iCz57lpMFAgydbaN9/kYEhO6G0CwhRhED jbRFDJh6AXCPvCQVfs7/1AvzKPljBoTUzop1Bo+qWtIJOiSvBxRCs8HzDcVnLfPRE0OP V8etXfmU6kFJElUsF6ez5/R5YeNFaNiUcjuwX8siEi84uWJqRgVnM7gGMWvozabHvadr mNSZ1ImqsgZb8Jt17Slf/eVeTb8FquH0f0NGs7x868S6gHIwYGRICIvlTn+ukJR1CDzR 606A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764624; x=1757369424; 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=knhQ+S9mPkiwhWSXwrIQ0d+Hly1TQbR8zGjL18AowhY=; b=RpLfgxOzHvSOLS+r7wOaby5+KFoB0iCpY2foJVJZpdXSjIM7XqWxkknpYIx7rmQMPW JHlefRpdU9/R5gWcBVsRLM7EE3S5J1wT2ek32mTHuBUt41fI/zEbOrZS1n8sSe2SSOz5 QJ03Q7ZC+qgM/JCC1/cEn4XugFQjod2Fy3KZB15d33MBEqNdNBGG1l0x7SRZxaok8sO4 0nY7v8UPMmWBSpBr75Pl3zOwJKwc8KH9CjbT9sl2zIIsZ9J1sGgkmw0cf92tZV9lwqYE iJHSgHbQDv5oqYVA1C5KbZ6+FiWajeACM/WZtuC7oZVuJuJwERCqOZ+c3ANfiHVvALBz 2a2w== X-Gm-Message-State: AOJu0Yxag8P1u1W80z7PL+xqf9UdlFzHhHUPApg8bf8bY4sJwSXZIosv GeBIxuZRT5uRYsMsNfVrMmgRf9+eO+JeWNOIoNsFITrO185IWRW5Jw0WAxhO2HYj X-Gm-Gg: ASbGncun9mSjhdDZMYGxA/HoIvlChtvayWwpPo5xqyi7EtSwUG2s8brq+a2AdiwU4ea 1SevuhNYnOMbcStP3mIKz6YuTh5QtSfH3bQL9iJ1NAmfrtaqPd9238o7A7hzXWqWuMIXDSKyvBK povstVeDgAS/N2Z6I5haoOMueAHbuQD2CKRKBC5WajL00ezofRU2gzUSIMcsDuKZmdSV8zHq+Ap Ne7usEPA/WBv9NULclJWsyjhkDucTm9cW0eUnvJp/eiEKy8qKmY2p5m3M9B1FayQk9BRtbYbwSd UueG/8nqx3eRf8X9zXbGANt2bFzYLlLdm/2yro1AX6iV/enyzYJjQjl5rAioXVjfYLjE1k+Cyht yB9sl6rojQ5Ty90PduZw4ClTkLRIAS8o8IQNOjzC6Owgzgcc8ShBB5uH4+AnBqv0n7iORDTfK8T L5gtWtnB4= X-Google-Smtp-Source: AGHT+IHx4s/XpnhU0YN9P6FuM23tHmNqjatW0aU1ecFV2aj3TF6onudCp4HF51qNc/4vWPZYRopttQ== X-Received: by 2002:a05:6512:4608:b0:55f:7050:9550 with SMTP id 2adb3069b0e04-55f70924a63mr2181909e87.38.1756764623544; Mon, 01 Sep 2025 15:10:23 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Subject: [PATCH v6 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions Date: Tue, 2 Sep 2025 01:10:06 +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. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v6: - drop extra func/line printing from dprintk - drop checking context allocation from resume handler - merge some loops where it is possible 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 | 143 +++++++++++++++++++++++++++++++++ xen/arch/arm/gic.c | 29 +++++++ xen/arch/arm/include/asm/gic.h | 12 +++ 3 files changed, 184 insertions(+) diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index b23e72a3d0..6373599e69 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -1098,6 +1098,140 @@ 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, "GICv2 suspend context not allocated!\n"); + 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); + 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); + 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; + + 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); + + 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); + 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: + printk(XENLOG_ERR "Failed to allocate memory for GICv2 suspend context\n"); + + 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 +1436,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 +1484,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 Sep 01 22:10:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105407.1456404 (Exim 4.92) (envelope-from ) id 1utCjU-0007Go-Ay; Mon, 01 Sep 2025 22:10:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105407.1456404; Mon, 01 Sep 2025 22:10: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 1utCjU-0007FB-3r; Mon, 01 Sep 2025 22:10:36 +0000 Received: by outflank-mailman (input) for mailman id 1105407; Mon, 01 Sep 2025 22:10: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 1utCjS-00055o-NV for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:34 +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 7a98470c-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:33 +0200 (CEST) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-55f7a34fb35so1270886e87.1 for ; Mon, 01 Sep 2025 15:10:33 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7a98470c-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764632; x=1757369432; darn=lists.xenproject.org; h=content-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=Seeyes3vY54fd1iXGBX0pVpgCs7BHM5X3gEx1tAo94Y=; b=BK6ECKdm0QAJkSxTS9j1iOvns+W8+lf78lpJaGTdVEsmKOhtKnQcqUfC9vpK/znma6 f2e/+0xZtY+g3ixFop3ISP6P30XFNziscIDRemlk2sW2vIK8VBDUC4vOwNl6uknzHw1y /pJ3y6Q1MfDRqPDR5ZvB9vS6wXw1BfRpmDrz/HkrH5Qf2JdIlXGJrLxN1KooSjwqF2u5 D1BqWJxKkUAVXhzyHsEta9d/WapEfkWYCDvRho01qr48nia3kKFqIFCtaQ5peWrCg75h wJTWs2UKCCS3z3sMoCVhNkKuA4OHWI/HQUc8gKm4Ey+G4TlNWXRM5fWbEARi48UpZ2nq n2mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764632; x=1757369432; 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=Seeyes3vY54fd1iXGBX0pVpgCs7BHM5X3gEx1tAo94Y=; b=mkPNlY7UVqcraRGSq9VmjqswVpZNWZpRWMfNDGDoBactoGcXYPrLVSf7TIQv6+9rMX puhEe4M8QvsHH2abmvQ7lMWtdUCvO920DWXzW+bgmYo8YjtaV9YxQM7CwgOOdlS4gryy YuMs+U+9XRz/3Zqw8WoGMxsk6wYvoJpMSB7/ypKll5cWFrUtD0lbGkyTllNRMlSt3ERr afIh0NqXWfK1k7taR+YE4FzG08QyISd1qg9v1WTBYC0xBXBQZuyOSCCkEnfw79uzJ5mn wSusw6RkZKwGjyxRF69tQSGRGOH8gb2Ic7YgFR3KzDsSkq1Aos4mjylJq7aCOf0tUKV2 Cw0Q== X-Gm-Message-State: AOJu0YyKyLzdhP1zTt++TWi4CDyVrp2NmEnh91ggPQSSDCWx5El8rRor 2mMbRDKSqLYZ3ePjo7/B+M0AuRTk5Aqs5bbgJOuWikqx9ZRS+mzifPI3gjHFUhqa X-Gm-Gg: ASbGncuYWVxgRzsQQYEJsB1yljoJ2IIoNydfHSCCA+eQ8NBT5xR3taAZX1aUAwqPLjA NYAbBQMrpNDvE0Bg85vBaFGARIyOWAJAKps/o2Pa4DmrsC1BkL7H+0IuaYlzju5V9yNs/SPAn6e ARQT27PIWwoDAfezLR7tYlQSIdKDo4qLn9sxwOSiHvY36CwxthGh79vQ4tZbUZZNISUAKCykNKq CCeRnCSOrvwRFs0yhqgOVjlLuQXHKa+12GYNZfs9Hov56l2w6yR0v7ULGhuCAk3YlUF3BKP1/sw TWhR3iE0vlUy6zP/YQzvuggyHtSt5w/Tn4whPMHVt0PsSZsIsKfp1GZSCXvvJ4j42FjhjK2+Ei5 mUzEfE5iA8okyvaxf49AxpzqAhj+w7+mH488CtYAQkYrippCr1hvQJmUzGVJ/n9TlvdO61P33 X-Google-Smtp-Source: AGHT+IH5uEVLs+KWjRNFUSLQfbCaJILBg0f9f4JMQd0Q0IH2Ub2fAbgyI59Wkme8wRbZraFL+Nofsw== X-Received: by 2002:a05:6512:6512:b0:55f:391b:54df with SMTP id 2adb3069b0e04-55f70955022mr2152500e87.47.1756764632215; Mon, 01 Sep 2025 15:10:32 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Subject: [PATCH v6 09/13] xen/arm: Resume memory management on Xen resume Date: Tue, 2 Sep 2025 01:10: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 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). Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v6: - moved changes related to set_init_ttbr to commit that implements system_suspend call 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 ++++++++++++++++ 1 file changed, 16 insertions(+) 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) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105408.1456410 (Exim 4.92) (envelope-from ) id 1utCjU-0007Nl-U5; Mon, 01 Sep 2025 22:10:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105408.1456410; Mon, 01 Sep 2025 22:10: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 1utCjU-0007M9-OW; Mon, 01 Sep 2025 22:10:36 +0000 Received: by outflank-mailman (input) for mailman id 1105408; Mon, 01 Sep 2025 22:10: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 1utCjS-0005XP-Vp for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:34 +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 7b522cba-8780-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:10:34 +0200 (CEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55f69cf4b77so3061874e87.2 for ; Mon, 01 Sep 2025 15:10:34 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7b522cba-8780-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764634; x=1757369434; darn=lists.xenproject.org; h=content-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=RUm3eao0nv7lQDT5rWWvwgkJGYkE0FYcno3r5As+ock=; b=gMC/XyEF3f85vCpaLUurs0tmK7pd5exHkoE5EKQwKE2lGnHCkfJLvkGn9S6vQlBoqU ty9E01XQsuqUc3UnruMF/dYVUVX/BE+Q58ArXY6MPHYXRuf9Vm9EERGD+sCbonW8EafB jfx3aMVaPq7zPPHIt84JlznJ9SuedQzpfhw9AXc2ji6b/RDg8/jivCWQO7cLz4s3z1HI E7Y1W4A8fgCs035XNPLoxV9lM9ClG+11FqlNH4A+r7WIXDDDPdqmipsp88Ek65g+T2NK 1zffexZunfGprfoYyE01iBlEEzZ8scxO/PTwyiDGiQ2Emg4/byV7zrMGiRYdeGKAXwmi mrqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764634; x=1757369434; 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=RUm3eao0nv7lQDT5rWWvwgkJGYkE0FYcno3r5As+ock=; b=riQ+hJsV8GHqJVzZF48YEaWn/4MzprJ3lAl/JX5U4uMs7WeFlC7Y3wYojFfMDyWE7A K/zCnZ9Fw60P8T3WOl6oSBXTDM+tyk0zjNGGoWl2iQwBfP7tOeFqyovoaJT/oKQqZzz3 UUR8r3W3eI+u4WA8E1O73VCTbl00JMtBWo3Ol5MtGWIXRSXBzOqHF3WzmMk3+CbqGflJ IQS7/Tg8tmPsYOVaksadNHOK2wE6Exs8oe5AfNIt/x1r5KbXxL/wH5twh3rZVOTQYfjN VqvJJs27NAopjmhguDv5JKL0crH1oxB4PbR02fV+LFq8uk4c+54A9l6nlg6mFbT0l2F+ u3yw== X-Gm-Message-State: AOJu0Yz2CRpcDQ1ROc+jyIezzseLAsh79HcSa9hKcYTIaQOHnb8a1XHf 2c+n7PJ7mAGGv1yPDmxiTT+GXpm650HROYYYSFnB3gv9FSx2wtV3KscBJoDE2Op4 X-Gm-Gg: ASbGncs9lGJ+pSUa9kLWkxVrDOrzraYXMF0lxZP1BfmfTbNaVBJKJoVTyxe/LmabJyl Rvob/a/BuECbt49f9H2bzF5nC5PAbpP7yMQuN/XYgm1rIBXPoYGOdqu+LtXCf5KWU7/jPC48h2C npOJMXs5jgWP1IgSgoFacqpvXru7n8l3IH6rRP2AuDb7Ujy1dbaByuhqpcX2y6cxG8yY1yuvt2w agArvQsi5oTNE7qaC8BZFbjVug5yjrXAl7HCfgiak7Eg4ukwfZzj80+gKo4xhrNtENjQU/UtEvZ aAcOMY7I3uXE0Ws2vOy6LQXNRPRqLU6xmf5W8yHqYPUNkaYITy4OZ6Wr68E/QEZhaCVGd75CH4J 6cGv/D/2NsHqiWa8wAbA/G11cteJd1mRVoxyi6yLmfYptFDdTfL+kwoIcgchZKAT9b+WC2VvD X-Google-Smtp-Source: AGHT+IH5UsKj5cGBhn+itOcgkLe6OXnp3JP492VPrs/+mbJzdvslmcWUzDDr1Sm7tPeTMH53B2gN1A== X-Received: by 2002:a05:6512:2212:b0:55f:6649:45c5 with SMTP id 2adb3069b0e04-55f7089c32bmr2494605e87.11.1756764633457; Mon, 01 Sep 2025 15:10:33 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Subject: [PATCH v6 10/13] xen/arm: Save/restore context on suspend/resume Date: Tue, 2 Sep 2025 01:10: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 The context of CPU general purpose and system control registers must be saved on suspend and restored on resume. This is implemented in prepare_resume_ctx and before the return from the hyp_resume function. The prepare_resume_ctx must be invoked just before the PSCI system suspend call is issued to the ATF. The prepare_resume_ctx must return a non-zero value so that the calling 'if' statement evaluates to true, causing the system suspend to be invoked. Upon resume, the 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 to by the saved link register, which is the place from which prepare_resume_ctx was called. To ensure that the calling 'if' statement does not again evaluate to true and initiate system suspend, hyp_resume must return a zero value after restoring the context. Note that the order of saving register context into cpu_context structure must 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 v6: - Rename hyp_suspend to prepare_resume_ctx - moved invocation of prepare_resume_ctx to commit which implements system_suspend call 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/Makefile | 1 + xen/arch/arm/arm64/head.S | 90 +++++++++++++++++++++++++++++- xen/arch/arm/include/asm/suspend.h | 22 ++++++++ xen/arch/arm/suspend.c | 14 +++++ 4 files changed, 126 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/suspend.c diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index f833cdf207..3f6247adee 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -51,6 +51,7 @@ obj-y += setup.o obj-y += shutdown.o obj-y += smp.o obj-y += smpboot.o +obj-$(CONFIG_SYSTEM_SUSPEND) += suspend.o obj-$(CONFIG_SYSCTL) += sysctl.o obj-y += time.o obj-y += traps.o diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 596e960152..c6594c0bdd 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 prepare_resume_ctx(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. + * prepare_resume_ctx shall return a non-zero value. Upon restoring context + * hyp_resume shall return value zero instead. From C code that invokes + * prepare_resume_ctx, the return value is interpreted to determine whether + * the context is saved (prepare_resume_ctx) or restored (hyp_resume). + */ +FUNC(prepare_resume_ctx) + /* 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 + + /* prepare_resume_ctx must return a non-zero value */ + mov x0, #1 + ret +END(prepare_resume_ctx) FUNC(hyp_resume) /* Initialize the UART if earlyprintk has been enabled. */ @@ -580,7 +626,49 @@ 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 prepare_resume_ctx. To distinguish a return from + * prepare_resume_ctx which is called upon finalizing the suspend, + * as opposed to return from this function which executes on resume, + * we need to return zero value here. + */ + mov x0, #0 + ret END(hyp_resume) #endif /* CONFIG_SYSTEM_SUSPEND */ diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index 7e04c6e915..29eed4ee7f 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -3,9 +3,31 @@ #ifndef __ASM_ARM_SUSPEND_H__ #define __ASM_ARM_SUSPEND_H__ +#include + #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; + void hyp_resume(void); +int prepare_resume_ctx(struct cpu_context *ptr); #endif /* CONFIG_SYSTEM_SUSPEND */ diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c new file mode 100644 index 0000000000..5093f1bf3d --- /dev/null +++ b/xen/arch/arm/suspend.c @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include + +struct cpu_context cpu_context; + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105410.1456426 (Exim 4.92) (envelope-from ) id 1utCjX-0007wE-3C; Mon, 01 Sep 2025 22:10:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105410.1456426; Mon, 01 Sep 2025 22: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 1utCjW-0007ui-Rq; Mon, 01 Sep 2025 22:10:38 +0000 Received: by outflank-mailman (input) for mailman id 1105410; Mon, 01 Sep 2025 22:10:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjV-00055o-Sr for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:37 +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 7c5a7763-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:36 +0200 (CEST) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-55f7cd8ec2cso1473228e87.2 for ; Mon, 01 Sep 2025 15:10:36 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7c5a7763-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764635; x=1757369435; darn=lists.xenproject.org; h=content-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=iGzUVANbBHVQm2yt+EaiKz11N+mMUBJTMXRpUM7rLq4=; b=buVqwQTpFdnxff4F5Wq6sWoIKb28FFtDIx5qMbh2rU2EdfrDLp5TzhE6F2TYzEsZNR Rzw3EC0Qg5WZiOqskgeiSWbCGAUqJyjuxGKSfSKCNRLjLssAUPPzkrvUZugnViljDoA5 jiiP8iV+xJPBs5wuzkhpu0HkgI2CW2OhrIjlqiPJ3+HyZwpokDZYxGIk4a3LgF+GzrZ0 ieuuKLqn32tDylrUEL0SZP5RqqNQiYVNXBH6KAe2cSJY+vp6V+8KunSzgdRehhXfd03f QNstpsq+zMc9vNgAFeEoOJTBZxDs8tg90rhNaGC1h0A9D0HEDmD0om7F299EVCE0kvkI s6Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764635; x=1757369435; 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=iGzUVANbBHVQm2yt+EaiKz11N+mMUBJTMXRpUM7rLq4=; b=f85O8GxyC3Z/pZQOuT4fhbXX4qv6WQBi/HapHy3WjQDSvjktUB+uJVs1JSifIKcHdV OS/2xM6lL6EiYFJlo2Sdmqc++0U2td+uh3EFxYhKmWqEh1iJUo/uPUTs0U/ZT1twsxgf bfHoqfJyTQw6vMwSVFmjIDUNANBvPlCe9b+XTtThUd3KMh5AXWnAIz7IH7iyl+4TJ30R V13FxAlsqnfShfVlnFeeFrvYDiA+T7x1YWivDEAh6y0SlWWe0EM5iJAeWq6dIgEfWgD4 Uyi5vsc2rO3+itSJywHwVIfI/x+yd3AoquPBQJAlE1cuH8M+ZzLPqxzRf4klWRFLnt+i bL/w== X-Gm-Message-State: AOJu0YzsP9GCbabLjgyU2+pUAgCUOqrPC4De3uS8cUdlPwBTU+/noK6I XN51rKdB6T53BrQweltl7gdbNdK5Z/KtCdIzaJ/4Zkzyeyh5NbTTx06IceT7ZbcL X-Gm-Gg: ASbGncvvFoycXGyKoyAqStFofUUkvTQ96b5+6c08JrUZ3XjuP29jQKp7DD4y8kNL43F CGaVELZoX4ujh/3JzBlTYms5GIH+I/W/Qz7ZLlvijiuVwU4+oLlkyvExt7EweQKgRpGPGv15CWm wbXJO2XcySsaI36FFgS06mwgHulB+yIO1jZFGlrBtbHiWEfCU1l2+8oVE5AjmQnDOtsqkb998Vw ojIm1ZZsjZGIfAm8nontl05uwgbghfr6slrdixIoPMVCcYcZe3D3Xk3hwsmo75bH/0h3FcVrVZR SmYaTKr/Wg/9IMmjLNvyZ1uZ91oPcVNuCvhf0h9t9T7wvu7b5BZ39syUTeRA8tM5wMmg2qRnSn7 r/gDzPkOEKJGsnOXGVa2ddSaJVkRyqpDo1mJNG5Jvwg/SULNCa53yKxNwByYKCg== X-Google-Smtp-Source: AGHT+IH+YIb5/EiRCiek3MEhwqufDEz2NkLHmu/RcFSNtgnxC2gM0m7/gUw3Q4lC0sULlGwUgJZ6ng== X-Received: by 2002:a05:6512:691:b0:55f:56db:7648 with SMTP id 2adb3069b0e04-55f708b6be9mr2634797e87.19.1756764635113; Mon, 01 Sep 2025 15:10:35 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Subject: [PATCH v6 11/13] xen/arm: Add support for system suspend triggered by hardware domain Date: Tue, 2 Sep 2025 01:10:15 +0300 Message-ID: <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.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, iommu and console - maintain system state before and after suspend 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. Remove the restriction in the vPSCI interface preventing suspend from the hardware domain. Select HAS_SYSTEM_SUSPEND for ARM_64. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v6: - Minor changes in comments. - The implementation now uses own tasklet instead of continue_hypercall_on_cpu, as the latter rewrites user registers and would tie system suspend status to guest suspend status. - The order of calls when suspending devices has been updated. Changes in v5: - select HAS_SYSTEM_SUSPEND in ARM_64 instead of ARM - check llc_coloring_enabled instead of LLC_COLORING during the selection of HAS_SYSTEM_SUSPEND config - call host_system_suspend from guest PSCI system suspend instead of arch_domain_shutdown, reducing the complexity of the new code - update some comments 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/include/asm/mm.h | 2 + xen/arch/arm/include/asm/suspend.h | 2 + xen/arch/arm/mmu/smpboot.c | 2 +- xen/arch/arm/suspend.c | 150 +++++++++++++++++++++++++++++ xen/arch/arm/vpsci.c | 9 +- xen/common/domain.c | 4 + 7 files changed, 168 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 5355534f3d..fdad53fd68 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -8,6 +8,7 @@ config ARM_64 depends on !ARM_32 select 64BIT select HAS_FAST_MULTIPLY + select HAS_SYSTEM_SUSPEND if UNSUPPORTED select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH config ARM diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index 7a93dad2ed..61e211d087 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -365,6 +365,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/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index 29eed4ee7f..8d30b01b7c 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -29,6 +29,8 @@ extern struct cpu_context cpu_context; void hyp_resume(void); int prepare_resume_ctx(struct cpu_context *ptr); +void host_system_suspend(void); + #endif /* CONFIG_SYSTEM_SUSPEND */ #endif /* __ASM_ARM_SUSPEND_H__ */ 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 5093f1bf3d..35b20581f1 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -1,9 +1,159 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include +#include +#include +#include +#include +#include + +/* + * TODO list: + * - Decide which domain will trigger system suspend ctl or hw ? + * - Test system suspend with LLC_COLORING enabled and verify functionality + * - Implement IOMMU suspend/resume handlers and integrate them + * into the suspend/resume path (SMMU) + * - Enable "xl suspend" support on ARM architecture + * - Properly disable Xen timer watchdog from relevant services (init.d left) + * - Add suspend/resume CI test for ARM (QEMU if feasible) + * - 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 void cf_check system_suspend(void *data) +{ + int status; + unsigned long flags; + /* TODO: drop check after verification that features can work together */ + if ( llc_coloring_enabled ) + { + dprintk(XENLOG_ERR, + "System suspend is not supported with LLC_COLORING enabled\n"); + status = -ENOSYS; + goto dom_resume; + } + + BUG_ON(system_state != SYS_STATE_active); + + system_state = SYS_STATE_suspend; + + printk("Xen suspending...\n"); + + freeze_domains(); + scheduler_disable(); + + /* + * Non-boot CPUs have to be disabled on suspend and enabled on resume + * (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI + * CPU_OFF to be called by each non-boot CPU. Depending on the underlying + * platform capabilities, this may lead to the physical powering down of + * CPUs. + */ + status = disable_nonboot_cpus(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_nonboot_cpus; + } + + time_suspend(); + + 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; + } + + local_irq_save(flags); + status = gic_suspend(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_irqs; + } + + set_init_ttbr(xen_pgtable); + + /* + * Enable identity mapping before entering suspend to simplify + * the resume path + */ + update_boot_mapping(true); + + if ( prepare_resume_ctx(&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 prepare_resume_ctx. + * The difference in returning from prepare_resume_ctx on system suspend + * versus resume is in function's return value: on suspend, the return + * value is a non-zero value, on resume it is zero. That is why the + * control flow will not re-enter this 'if' branch on resume. + */ + if ( status ) + dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=%d\n", + status); + } + + system_state = SYS_STATE_resume; + update_boot_mapping(false); + + gic_resume(); + + resume_irqs: + local_irq_restore(flags); + + resume_console: + console_resume(); + console_end_sync(); + + 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; + + printk("Resume (status %d)\n", status); + + dom_resume: + /* The resume of hardware domain should always follow Xen's resume. */ + domain_resume(hardware_domain); +} + +static DECLARE_TASKLET(system_suspend_tasklet, system_suspend, NULL); + +void host_system_suspend(void) +{ + /* + * system_suspend should be called when hardware domain finalizes the + * suspend procedure from its boot core (VCPU#0). However, Dom0's vCPU#0 + * could be mapped to any pCPU. The suspend procedure has to be finalized + * by the pCPU#0 (non-boot pCPUs will be disabled during the suspend). + */ + tasklet_schedule_on_cpu(&system_suspend_tasklet, 0); +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c index 22c3a5f544..2f52aba48d 100644 --- a/xen/arch/arm/vpsci.c +++ b/xen/arch/arm/vpsci.c @@ -4,6 +4,7 @@ #include #include +#include #include #include #include @@ -221,9 +222,10 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) if ( is_64bit_domain(d) && is_thumb ) return PSCI_INVALID_ADDRESS; - /* SYSTEM_SUSPEND is not supported for the hardware domain yet */ +#ifndef CONFIG_SYSTEM_SUSPEND if ( is_hardware_domain(d) ) return PSCI_NOT_SUPPORTED; +#endif /* Ensure that all CPUs other than the calling one are offline */ domain_lock(d); @@ -249,6 +251,11 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) "SYSTEM_SUSPEND requested, epoint=0x%"PRIregister", cid=0x%"PRIregister"\n", epoint, cid); +#ifdef CONFIG_SYSTEM_SUSPEND + if ( is_hardware_domain(d) ) + host_system_suspend(); +#endif + return rc; } diff --git a/xen/common/domain.c b/xen/common/domain.c index 667017c5e1..5e224740d3 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1317,7 +1317,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 ) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105412.1456437 (Exim 4.92) (envelope-from ) id 1utCjZ-0008Qe-Gc; Mon, 01 Sep 2025 22:10:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105412.1456437; Mon, 01 Sep 2025 22:10: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 1utCjZ-0008Pb-9K; Mon, 01 Sep 2025 22:10:41 +0000 Received: by outflank-mailman (input) for mailman id 1105412; Mon, 01 Sep 2025 22:10:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjX-00055o-TK for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:39 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7d232868-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:37 +0200 (CEST) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-55f69cf4b77so3061906e87.2 for ; Mon, 01 Sep 2025 15:10:37 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7d232868-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764637; x=1757369437; darn=lists.xenproject.org; h=content-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=7jLnGK/W9IzxOZ6CLKOO5BPor3o3fyjNQvRa1agLv/o=; b=iTP2GJ/agVaLRIl9CbyxtbmKv9vK0Kmfc0vQvD9UJJ+VsWHnwm0C91teejA5069jbj lvFqrgdbERgifdjCWjURa5l9Bu8c9emdO4e8DqxZj/ebimOAlGs4BZfd5yFcFhvquTeq 3WEwZw9jewRdjaDmWlnViXn/8J7ukMTjdNha7uVsH2IPYGmmWmbyfOIJmcaLwd3ZFrBu D/00UtgdFwaF+rNmxT0mDBvPftWN4BWm4PH+wJadGkCpR+z2S3Jk+1j7lpNbf43tAw5D oTMCxYXZacmJUr+LstIXKxlSy7FlwXJczRaazLnvNJdP04Y/B1SLm12N05aetx+kk1Ul fL2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764637; x=1757369437; 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=7jLnGK/W9IzxOZ6CLKOO5BPor3o3fyjNQvRa1agLv/o=; b=Kl6XnjXUI5L8r90NrRQ6pL1FYqA9VjslaIcnFvcd+wC8o9gGLZEe/FJ0cHe/za5YHG +O864eobkRAnUpfO1ym45/ZAuwi0/FaYxXtFK+I+mkrztqMa3AL8iAV7VMNt35OSnMPp Ry/YbM7saD1Ns1eW3j4lMLJnxnw9Y8Ji6Tyf33pHCAqlEEz/uOeGV4XvY+KKp6vB3TeR Dd6e6vf1OJtgVUGIVGgmWS7ZMVMuE53iw4O2KTUIzEG/I7B+Iaozo4tYgSIZWVXnE2Vo CcBl3a1d8j4d8hnAvL7/SScYfFGOSYQgaNSsUYBIEhTB3bYgPeJHCtzL1REO22f4WBhb uFhg== X-Gm-Message-State: AOJu0Yx7K6ZRTJAE2/O1XtvM83f05XC1xVpsDmedUEbd0E0wWaorTb3a pGesJ2r/BX7HGZ0n1i6LQdF9Gfkh0mGmuH5wwfycrQKKgN4gZz4FArsxL7nnyiTS X-Gm-Gg: ASbGnct64cGiOEmevkj+8JPF/y1Zve+X5FLAzDZ2VjPvBHf8PxHlAKXg/uoJtNBuHCf Z28SAmUyv5sDYQjdNzuJOaWqnJnSGkfDOgCcPo8QWEBXx/dCdsm9eGMgkZJD9z+OTunwz4Qmv8i Ew1GmlKramjC2vUOe2hMo9n5pCHVhxnMvfaZ6egEettEf48Jt+9I+JaAXyj+fjnMtroKISWA5si WdKWQMznb/eJAs0vV9mYyOez/H6NWAnC2ZWoqD4JvnqenRSwiTXXB1O12camonfEZ3Hiec7n/Y2 MppBAalrq4m39+HD0PlQmDuGPnJKzGU7daSBslhCnvQlglIxr/yZoAyd8gEgV0+D1+oj9xAnvBg NSZJkkmlotKRwVF5qEoOKGv6mQ5n4vNoXeEKcHAw8RX8k6PvDQ0YtVWjkzaLZnQ== X-Google-Smtp-Source: AGHT+IGXdEdoSAzn5JEBY3rqDuehu56DiyGTfp49x/4lqJkOcHbolBJuNKUoq29Yojmc/eQDmAjVSQ== X-Received: by 2002:a05:6512:3c97:b0:55f:6a49:6e71 with SMTP id 2adb3069b0e04-55f708ecdadmr2606498e87.29.1756764636522; Mon, 01 Sep 2025 15:10:36 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh , Mykola Kvach Subject: [PATCH v6 12/13] xen/arm: Suspend/resume IOMMU on Xen suspend/resume Date: Tue, 2 Sep 2025 01:10:16 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Oleksandr Tyshchenko This is done using generic iommu_suspend/resume functions that cause IOMMU driver specific suspend/resume handlers to be called for enabled IOMMU (if one has suspend/resume driver handlers implemented). Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Mykola Kvach --- Changes in V6: - Drop iommu_enabled check from host system suspend. --- xen/arch/arm/suspend.c | 11 +++++++++++ xen/drivers/passthrough/arm/smmu-v3.c | 10 ++++++++++ xen/drivers/passthrough/arm/smmu.c | 10 ++++++++++ 3 files changed, 31 insertions(+) diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c index 35b20581f1..f3a3b831c5 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -5,6 +5,7 @@ #include #include +#include #include #include #include @@ -62,6 +63,13 @@ static void cf_check system_suspend(void *data) time_suspend(); + status = iommu_suspend(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_time; + } + console_start_sync(); status = console_suspend(); if ( status ) @@ -118,6 +126,9 @@ static void cf_check system_suspend(void *data) console_resume(); console_end_sync(); + iommu_resume(); + + resume_time: time_resume(); resume_nonboot_cpus: diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c index 81071f4018..f887faf7dc 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -2854,6 +2854,13 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) xfree(xen_domain); } +#ifdef CONFIG_SYSTEM_SUSPEND +static int arm_smmu_suspend(void) +{ + return -ENOSYS; +} +#endif + static const struct iommu_ops arm_smmu_iommu_ops = { .page_sizes = PAGE_SIZE_4K, .init = arm_smmu_iommu_xen_domain_init, @@ -2866,6 +2873,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = { .unmap_page = arm_iommu_unmap_page, .dt_xlate = arm_smmu_dt_xlate, .add_device = arm_smmu_add_device, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = arm_smmu_suspend, +#endif }; static __init int arm_smmu_dt_init(struct dt_device_node *dev, diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c index 22d306d0cb..45f29ef8ec 100644 --- a/xen/drivers/passthrough/arm/smmu.c +++ b/xen/drivers/passthrough/arm/smmu.c @@ -2947,6 +2947,13 @@ static void arm_smmu_iommu_domain_teardown(struct domain *d) xfree(xen_domain); } +#ifdef CONFIG_SYSTEM_SUSPEND +static int arm_smmu_suspend(void) +{ + return -ENOSYS; +} +#endif + static const struct iommu_ops arm_smmu_iommu_ops = { .page_sizes = PAGE_SIZE_4K, .init = arm_smmu_iommu_domain_init, @@ -2960,6 +2967,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = { .map_page = arm_iommu_map_page, .unmap_page = arm_iommu_unmap_page, .dt_xlate = arm_smmu_dt_xlate_generic, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = arm_smmu_suspend, +#endif }; static struct arm_smmu_device *find_smmu(const struct device *dev) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:10:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:10:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105417.1456449 (Exim 4.92) (envelope-from ) id 1utCjc-0000Vw-1g; Mon, 01 Sep 2025 22:10:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105417.1456449; Mon, 01 Sep 2025 22:10:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjb-0000Vb-O0; Mon, 01 Sep 2025 22:10:43 +0000 Received: by outflank-mailman (input) for mailman id 1105417; Mon, 01 Sep 2025 22:10:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCjZ-00055o-Tq for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:10:41 +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 7ddf5df5-8780-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 00:10:38 +0200 (CEST) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-55f687fd3bdso4496391e87.1 for ; Mon, 01 Sep 2025 15:10:38 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608279307asm123038e87.75.2025.09.01.15.10.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 15:10: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: 7ddf5df5-8780-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756764638; x=1757369438; darn=lists.xenproject.org; h=content-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=BjizghnjyTk2+1djq5Y5MywqYNIMRO2uUzS6ohxl4Eg=; b=iMnv7d1krAOipiWYOMc5/CdfPYAp+xruycgxo6Z5turoVv+X/bUoVJIWVqqbz5r2MQ YfQyIYzY1Rl0/sszIviPZcFJcrAC7OGzDFnfsUaTft4iwi7iis5F1HRT2wd19cyEbH6i oIXwSMuTY7SF3EbSiN2nOhVX6zJdlSX9cw1OYoKBf5rxvvzy17fwAxaKmJNADvuHVaF4 M636tMvq4Qayln8HU5aNVQPFqBFy6a6cL837OLOpTK6Pwl3EAzslH3JELnnk6E9ZOMCp bmTUKJmuu5lIvwRxqBmKaUSrWIAo5G+dynzmPIjgGPfc/UCm6itQl5jmNT6E5ZRSSTop wegw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756764638; x=1757369438; 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=BjizghnjyTk2+1djq5Y5MywqYNIMRO2uUzS6ohxl4Eg=; b=XEyVF/3UMcWRFni44Mh81eM3xlSIVA3AKZyLVZPq5G0SWhb6bss9aIxcppuUCIa6cC NVoRZV9XA+Uwcr+hKezaV/nkWx/kDMX8Stnztz3JSFooCQGt95Sus8ADegMstQ0SWncB EItTwiZtNr/ouNLa42MctZqLLb3+rQKaR4uMvSn3ytKUf1fOufYVYPnHabSvLHOaEmmh wf3I4NOmGM5kozKgkNOydpqMSBJzxJ8aAvdhutVI86BeAX2hXje4H6p7QZDke+UJpcJv 5ivV06Z5lSTOMLY72YwVHNQRRraZKsZ6EUFn9m81Fv1jxvyNTspc2g0tpH+MvS9PO3c5 /6Sg== X-Gm-Message-State: AOJu0YxMHrmcfuWNUsg0Hi8iEUp//1fgY/h0n9sjJy6f3mYrjoPGQX1+ v8tQyb8GK06XCDmn8zYLJj21pgM2OckYfBmZDJRHcpVw/IY3lu8he2xcEM3dE6nU X-Gm-Gg: ASbGncvxONl76xFllWIjApp9rBvonkZK+TvkMxoOnrlvNYPSMV8Qqlx0iThIJcifI3V FMyNPTvos0sEUrmTuLitdq6bfFLZxm5DGKC1ZYGAmqt2rRhgAUCFTshj/qnyM48OzkyCqa6tN8u qaHs43LLRqT+yMx2HqPoS8cLyCrZR34t0g/1ahVYV4CR0VUKHuZzkIvBtAb+byqL3hZ6hU2xvXo UxLKM1672aTdRQGzDwwGEt1gUAmVAhqzC/Fb/0DZ6D+r6dZFX/dbpyTreMATPXPI8/VHpQT/ksZ JCux90fO8hvM3qfR0StG/RCN0A3q7qQR2qmtn7+XZ2xnR8Y5lQzn44RqOKB45uQpVCl3eFvWg6z Pv22SE1Tf07DlvmWnNQ5/0pu5d9fffPhz4Hhg8nktmsxzOVmuIt4m2VMSyXiuLw== X-Google-Smtp-Source: AGHT+IEn9+xcjXygXejhEa0wyNG2hkVDUF3pRbujhPECoHvmyQVKBSuBe7768CCtbszL4fNE5HZPEA== X-Received: by 2002:a05:6512:3ca4:b0:55f:501e:7bf7 with SMTP id 2adb3069b0e04-55f709bdaa0mr2975906e87.57.1756764637835; Mon, 01 Sep 2025 15:10:37 -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 v6 13/13] xen/arm: gic-v3: Add suspend/resume support for eSPI registers Date: Tue, 2 Sep 2025 01:10:17 +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 Add suspend/resume handling for GICv3 eSPI registers. Signed-off-by: Mykola Kvach --- Note: The main eSPI patch series is still under review. This commit is intended to be applied after the main eSPI series: [PATCH v5 00/12] Introduce eSPI support https://patchew.org/Xen/cover.1756481577.git.leonid._5Fkomarianskyi@epam.com/ --- xen/arch/arm/gic-v3.c | 141 +++++++++++++++++++++++++++++------------- 1 file changed, 97 insertions(+), 44 deletions(-) diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 9f1be7e905..57403c82a8 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1782,17 +1782,14 @@ static bool gic_dist_supports_lpis(void) struct gicv3_ctx { struct dist_ctx { uint32_t ctlr; - /* - * This struct represent block of 32 IRQs - * TODO: store extended SPI configuration (GICv3.1+) - */ + /* This struct represent block of 32 IRQs */ struct irq_regs { uint32_t icfgr[2]; uint32_t ipriorityr[8]; uint64_t irouter[32]; uint32_t isactiver; uint32_t isenabler; - } *irqs; + } *irqs, *espi_irqs; } dist; /* have only one rdist structure for last running CPU during suspend */ @@ -1831,8 +1828,26 @@ static void __init gicv3_alloc_context(void) gicv3_ctx.dist.irqs = xzalloc_array(typeof(*gicv3_ctx.dist.irqs), blocks - 1); if ( !gicv3_ctx.dist.irqs ) + { printk(XENLOG_ERR "Failed to allocate memory for GICv3 suspend context\n"); + return; + } } + +#ifdef CONFIG_GICV3_ESPI + if ( !gicv3_info.nr_espi ) + return; + + gicv3_ctx.dist.espi_irqs = xzalloc_array(typeof(*gicv3_ctx.dist.espi_irqs), + gicv3_info.nr_espi / 32); + if ( !gicv3_ctx.dist.espi_irqs ) + { + xfree(gicv3_ctx.dist.irqs); + gicv3_ctx.dist.irqs = NULL; + + printk(XENLOG_ERR "Failed to allocate memory for GICv3 eSPI suspend context\n"); + } +#endif } static void gicv3_disable_redist(void) @@ -1852,6 +1867,65 @@ static void gicv3_disable_redist(void) while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) == 0 ); } +#define GET_SPI_REG_OFFSET(name, is_espi) \ + ((is_espi) ? GICD_##name##nE : GICD_##name) + +static void gicv3_store_spi_irq_block(typeof(gicv3_ctx.dist.irqs) irqs, + unsigned int i, bool is_espi) +{ + void __iomem *base; + unsigned int irq; + + base = GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + 8 * i; + irqs->icfgr[0] = readl_relaxed(base); + irqs->icfgr[1] = readl_relaxed(base + 4); + + base = GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi) + 32 * i; + for ( irq = 0; irq < 8; irq++ ) + irqs->ipriorityr[irq] = readl_relaxed(base + 4 * irq); + + base = GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi) + 32 * i; + for ( irq = 0; irq < 32; irq++ ) + irqs->irouter[irq] = readq_relaxed_non_atomic(base + 8 * irq); + + base = GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi) + 4 * i; + irqs->isactiver = readl_relaxed(base); + + base = GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi) + 4 * i; + irqs->isenabler = readl_relaxed(base); +} + +static void gicv3_restore_spi_irq_block(typeof(gicv3_ctx.dist.irqs) irqs, + unsigned int i, bool is_espi) +{ + void __iomem *base; + unsigned int irq; + + base = GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + 8 * i; + writel_relaxed(irqs->icfgr[0], base); + writel_relaxed(irqs->icfgr[1], base + 4); + + base = GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi) + 32 * i; + for ( irq = 0; irq < 8; irq++ ) + writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); + + base = GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi) + 32 * i; + for ( irq = 0; irq < 32; irq++ ) + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); + + base = GICD + GET_SPI_REG_OFFSET(ICENABLER, is_espi) + i * 4; + writel_relaxed(GENMASK(31, 0), base); + + base = GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi) + i * 4; + writel_relaxed(irqs->isenabler, base); + + base = GICD + GET_SPI_REG_OFFSET(ICACTIVER, is_espi) + i * 4; + writel_relaxed(GENMASK(31, 0), base); + + base = GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi) + i * 4; + writel_relaxed(irqs->isactiver, base); +} + static int gicv3_suspend(void) { unsigned int i; @@ -1871,6 +1945,14 @@ static int gicv3_suspend(void) return -ENOMEM; } +#ifdef CONFIG_GICV3_ESPI + if ( gicv3_info.nr_espi && !gicv3_ctx.dist.espi_irqs ) + { + printk(XENLOG_ERR "GICv3: eSPI suspend context is not allocated!\n"); + return -ENOMEM; + } +#endif + /* Save GICC configuration */ gicv3_ctx.cpu.ctlr = READ_SYSREG(ICC_CTLR_EL1); gicv3_ctx.cpu.pmr = READ_SYSREG(ICC_PMR_EL1); @@ -1903,25 +1985,12 @@ static int gicv3_suspend(void) gicv3_ctx.dist.ctlr = readl_relaxed(GICD + GICD_CTLR); for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) - { - typeof(gicv3_ctx.dist.irqs) irqs = gicv3_ctx.dist.irqs + i - 1; - unsigned int irq; + gicv3_store_spi_irq_block(gicv3_ctx.dist.irqs + i - 1, i, false); - base = GICD + GICD_ICFGR + 8 * i; - irqs->icfgr[0] = readl_relaxed(base); - irqs->icfgr[1] = readl_relaxed(base + 4); - - base = GICD + GICD_IPRIORITYR + 32 * i; - for ( irq = 0; irq < 8; irq++ ) - irqs->ipriorityr[irq] = readl_relaxed(base + 4 * irq); - - base = GICD + GICD_IROUTER + 32 * i; - for ( irq = 0; irq < 32; irq++ ) - irqs->irouter[irq] = readq_relaxed_non_atomic(base + 8 * irq); - - irqs->isactiver = readl_relaxed(GICD + GICD_ISACTIVER + 4 * i); - irqs->isenabler = readl_relaxed(GICD + GICD_ISENABLER + 4 * i); - } +#ifdef CONFIG_GICV3_ESPI + for ( i = 0; i < gicv3_info.nr_espi / 32; i++ ) + gicv3_store_spi_irq_block(gicv3_ctx.dist.espi_irqs + i, i, true); +#endif return 0; } @@ -1938,28 +2007,12 @@ static void gicv3_resume(void) writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4); for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) - { - typeof(gicv3_ctx.dist.irqs) irqs = gicv3_ctx.dist.irqs + i - 1; - unsigned int irq; + gicv3_restore_spi_irq_block(gicv3_ctx.dist.irqs + i - 1, i, false); - base = GICD + GICD_ICFGR + 8 * i; - writel_relaxed(irqs->icfgr[0], base); - writel_relaxed(irqs->icfgr[1], base + 4); - - base = GICD + GICD_IPRIORITYR + 32 * i; - for ( irq = 0; irq < 8; irq++ ) - writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); - - base = GICD + GICD_IROUTER + 32 * i; - for ( irq = 0; irq < 32; irq++ ) - writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); - - writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLER + i * 4); - writel_relaxed(irqs->isenabler, GICD + GICD_ISENABLER + i * 4); - - writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVER + i * 4); - writel_relaxed(irqs->isactiver, GICD + GICD_ISACTIVER + i * 4); - } +#ifdef CONFIG_GICV3_ESPI + for ( i = 0; i < gicv3_info.nr_espi / 32; i++ ) + gicv3_restore_spi_irq_block(gicv3_ctx.dist.espi_irqs + i, i, true); +#endif writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); gicv3_dist_wait_for_rwp(); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:11:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:11:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105462.1456459 (Exim 4.92) (envelope-from ) id 1utCkJ-0003li-Np; Mon, 01 Sep 2025 22:11:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105462.1456459; Mon, 01 Sep 2025 22: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 1utCkJ-0003lZ-JD; Mon, 01 Sep 2025 22:11:27 +0000 Received: by outflank-mailman (input) for mailman id 1105462; Mon, 01 Sep 2025 22:11:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCkI-0003kD-2L for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:11:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utCkH-001MWT-0f; Mon, 01 Sep 2025 22:11:25 +0000 Received: from [19.12.91.86] (helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utCkH-00CPCS-08; Mon, 01 Sep 2025 22:11: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID :Subject:Cc:To:Date:From; bh=kTpcAsQXOC1lRh6OHUM0WMrajhFSsDU5wbqwDlXpeyw=; b= oCKemQ/6pDkCLzBZLtnOA0SLVcznTVBT6+8U5tSj2XtDlqTHQCQpC/p7EH6HZ3GXC4vsJWvMleTU8 +5qufqZCXOp+zCm52uDf38hM5trTzuPuJ25QhZVSdtDe/IoErSPOGtAiEUyRiuP6z2gm0FNaGgoJY AAyto94X4RjWCIklM=; From: dmukhin@xen.org Date: Mon, 1 Sep 2025 15:11:24 -0700 To: Stefano Stabellini 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 01/15] emul/vuart: introduce framework for UART emulators Message-ID: References: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-2-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 29, 2025 at 12:27:13PM -0700, Stefano Stabellini wrote: > On Thu, 28 Aug 2025, dmukhin@xen.org wrote: > > From: Denis Mukhin > > > > 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_VUART_FRAMEWORK, which will be > > automatically enabled once the user enables any UART emulator. > > > > Current implementation supports maximum of one vUART of each kind per domain. > > > > Use new domain_has_vuart() in the console driver code to check whether to > > forward console input to the domain using vUART. > > > > Enable console forwarding over vUART for hardware domains with a vUART. That > > enables console forwarding to dom0 on x86, since console can be forwarded only > > to Xen, dom0 and pvshim on x86 as of now. > > > > Note: existing vUARTs are deliberately *not* hooked to the new framework to > > minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" (i.e. > > minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified. > > > > No functional changes for non-x86 architectures. > > > > Signed-off-by: Denis Mukhin > > --- > > Changes since v4: > > - addressed feedback > > - Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-3-dmukhin@ford.com/ > > --- > > xen/arch/arm/xen.lds.S | 1 + > > xen/arch/ppc/xen.lds.S | 1 + > > xen/arch/riscv/xen.lds.S | 1 + > > xen/arch/x86/xen.lds.S | 1 + > > xen/common/Kconfig | 2 + > > xen/common/Makefile | 1 + > > xen/common/emul/Kconfig | 6 ++ > > xen/common/emul/Makefile | 1 + > > xen/common/emul/vuart/Kconfig | 6 ++ > > xen/common/emul/vuart/Makefile | 1 + > > xen/common/emul/vuart/vuart.c | 156 +++++++++++++++++++++++++++++++++ > > xen/common/keyhandler.c | 3 + > > xen/drivers/char/console.c | 6 +- > > xen/include/xen/serial.h | 3 + > > xen/include/xen/vuart.h | 116 ++++++++++++++++++++++++ > > xen/include/xen/xen.lds.h | 10 +++ > > 16 files changed, 314 insertions(+), 1 deletion(-) > > create mode 100644 xen/common/emul/Kconfig > > create mode 100644 xen/common/emul/Makefile > > create mode 100644 xen/common/emul/vuart/Kconfig > > create mode 100644 xen/common/emul/vuart/Makefile > > create mode 100644 xen/common/emul/vuart/vuart.c > > create mode 100644 xen/include/xen/vuart.h > > > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S > > index db17ff1efa98..cd05b18770f4 100644 > > --- a/xen/arch/arm/xen.lds.S > > +++ b/xen/arch/arm/xen.lds.S > > @@ -58,6 +58,7 @@ SECTIONS > > *(.rodata) > > *(.rodata.*) > > VPCI_ARRAY > > + VUART_ARRAY > > *(.data.rel.ro) > > *(.data.rel.ro.*) > > > > diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S > > index 1de0b77fc6b9..f9d4e5b0dcd8 100644 > > --- a/xen/arch/ppc/xen.lds.S > > +++ b/xen/arch/ppc/xen.lds.S > > @@ -52,6 +52,7 @@ SECTIONS > > *(.rodata) > > *(.rodata.*) > > VPCI_ARRAY > > + VUART_ARRAY > > *(.data.rel.ro) > > *(.data.rel.ro.*) > > > > diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S > > index edcadff90bfe..59dcaa5fef9a 100644 > > --- a/xen/arch/riscv/xen.lds.S > > +++ b/xen/arch/riscv/xen.lds.S > > @@ -47,6 +47,7 @@ SECTIONS > > *(.rodata) > > *(.rodata.*) > > VPCI_ARRAY > > + VUART_ARRAY > > *(.data.rel.ro) > > *(.data.rel.ro.*) > > > > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S > > index 966e514f2034..d877b93a6964 100644 > > --- a/xen/arch/x86/xen.lds.S > > +++ b/xen/arch/x86/xen.lds.S > > @@ -132,6 +132,7 @@ SECTIONS > > *(.rodata) > > *(.rodata.*) > > VPCI_ARRAY > > + VUART_ARRAY > > *(.data.rel.ro) > > *(.data.rel.ro.*) > > > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > > index 76f9ce705f7a..78a32b69e2b2 100644 > > --- a/xen/common/Kconfig > > +++ b/xen/common/Kconfig > > @@ -676,4 +676,6 @@ config PM_STATS > > Enable collection of performance management statistics to aid in > > analyzing and tuning power/performance characteristics of the system > > > > +source "common/emul/Kconfig" > > + > > endmenu > > diff --git a/xen/common/Makefile b/xen/common/Makefile > > index c316957fcb36..c0734480ee4b 100644 > > --- a/xen/common/Makefile > > +++ b/xen/common/Makefile > > @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o > > obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/ > > obj-$(CONFIG_IOREQ_SERVER) += dm.o > > obj-y += domain.o > > +obj-y += emul/ > > obj-y += event_2l.o > > obj-y += event_channel.o > > obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o > > diff --git a/xen/common/emul/Kconfig b/xen/common/emul/Kconfig > > new file mode 100644 > > index 000000000000..7c6764d1756b > > --- /dev/null > > +++ b/xen/common/emul/Kconfig > > @@ -0,0 +1,6 @@ > > +menu "Domain Emulation Features" > > + visible if EXPERT > > + > > +source "common/emul/vuart/Kconfig" > > + > > +endmenu > > diff --git a/xen/common/emul/Makefile b/xen/common/emul/Makefile > > new file mode 100644 > > index 000000000000..ae0b575c3901 > > --- /dev/null > > +++ b/xen/common/emul/Makefile > > @@ -0,0 +1 @@ > > +obj-$(CONFIG_VUART_FRAMEWORK) += vuart/ > > diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig > > new file mode 100644 > > index 000000000000..ce1b976b7da7 > > --- /dev/null > > +++ b/xen/common/emul/vuart/Kconfig > > @@ -0,0 +1,6 @@ > > +config VUART_FRAMEWORK > > + bool > > + > > +menu "UART Emulation" > > + > > +endmenu > > diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makefile > > new file mode 100644 > > index 000000000000..97f792dc6641 > > --- /dev/null > > +++ b/xen/common/emul/vuart/Makefile > > @@ -0,0 +1 @@ > > +obj-y += vuart.o > > diff --git a/xen/common/emul/vuart/vuart.c b/xen/common/emul/vuart/vuart.c > > new file mode 100644 > > index 000000000000..7b277d00d5c7 > > --- /dev/null > > +++ b/xen/common/emul/vuart/vuart.c > > @@ -0,0 +1,156 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * UART emulator framework. > > + * > > + * Copyright 2025 Ford Motor Company > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#define for_each_emulator(e) \ > > + for ( e = vuart_array_start; e < vuart_array_end; e++ ) > > + > > +extern const struct vuart_emulator vuart_array_start[]; > > +extern const struct vuart_emulator vuart_array_end[]; > > + > > +static const struct vuart_emulator * > > +vuart_match_by_compatible(struct domain *d, const char *compat) > > +{ > > + const struct vuart_emulator *emulator; > > + > > + if ( d->console.vuart ) > > + return NULL; > > + > > + for_each_emulator(emulator) > > + if ( emulator->compatible && > > + !strncmp(emulator->compatible, compat, > > + strlen(emulator->compatible)) ) > > strncmp will continue until the given count even if compat is shorter I checked lib/strncmp.c. I'll flip the arguments, so that strncmp() will return early if compat is shorter than emulator->compatible > > > > + return emulator; > > + > > + return NULL; > > +} > > + > > +static struct vuart *vuart_find_by_console_permission(const struct domain *d) > > +{ > > + struct vuart *vuart = d->console.vuart; > > + > > + ASSERT(d->console.input_allowed); > > This ASSERT looks suspicious as we haven't even checked that vuart!=NULL > yet. I would remove it Ack > > > > + if ( !vuart || !vuart->emulator || !vuart->emulator->put_rx || > > + !(vuart->flags & VUART_CONSOLE_INPUT)) > > + return NULL; > > + > > + return vuart; > > +} > > + > > +struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long addr, > > + unsigned long size) > > +{ > > + struct vuart *vuart = d->console.vuart; > > + > > + if ( !vuart || !vuart->info ) > > + return NULL; > > You might as well call vuart_find_by_console_permission that has all the > checks already vuart_find_by_io_range() is used in the I/O hook to find the vUART by its I/O port range. Using vuart_find_by_console_permission() here may be problematic if the vUART does not support/enable console forwarding. I'll keep this check as is for now. > > > + > > + if ( addr >= vuart->info->base_addr && > > + addr + size - 1 <= vuart->info->base_addr + vuart->info->size - 1 ) > > + return vuart; > > + > > + return NULL; > > +} > > + > > +int vuart_init(struct domain *d, struct vuart_info *info) > > +{ > > + const struct vuart_emulator *emulator; > > + struct vuart *vuart; > > + int rc; > > + > > + emulator = vuart_match_by_compatible(d, info->compatible); > > + if ( !emulator ) > > + return -ENODEV; > > + > > + vuart = xzalloc(typeof(*vuart)); > > + if ( !vuart ) > > + return -ENOMEM; > > + > > + vuart->info = xvzalloc(typeof(*info)); > > + if ( !vuart->info ) > > + { > > + rc = -ENOMEM; > > + goto err_out; > > + } > > + memcpy(vuart->info, info, sizeof(*info)); > > one thing to note is that the fields (strings) compatible and name are > copied by address, I am not if it is OK but FYI Thanks, will update vuart_info struct. > > > > + vuart->vdev = emulator->alloc(d, vuart->info); > > + if ( IS_ERR(vuart->vdev) ) > > + { > > + rc = PTR_ERR(vuart->vdev); > > + goto err_out; > > this path leads to vuart->info not being freed Thanks > > > > + } > > + > > + vuart->emulator = emulator; > > + vuart->owner = d; > > + vuart->flags |= VUART_CONSOLE_INPUT; > > + > > + d->console.input_allowed = true; > > + d->console.vuart = vuart; > > + > > + return 0; > > + > > + err_out: > > + XVFREE(vuart); > > + return rc; > > +} > > + > > +/* > > + * Release any resources taken by UART emulators. > > + * > > + * NB: no flags are cleared, since currently exit() is called only during > > + * domain destroy. > > + */ > > +void vuart_deinit(struct domain *d) > > +{ > > + struct vuart *vuart = d->console.vuart; > > + > > + if ( vuart ) > > + { > > + vuart->emulator->free(vuart); > > should we pass vuart or vuart->vdev here? The emulator state is supposed > to be vuart->vdev? That should be vuart->vdev; thanks! > > > + XVFREE(vuart->info); > > + } > > + > > + XVFREE(d->console.vuart); > > +} > > + > > +void vuart_dump_state(const struct domain *d) > > +{ > > + struct vuart *vuart = d->console.vuart; > > + > > + if ( vuart ) > > + vuart->emulator->dump_state(vuart); > > also here vuart->vdev? Ack > > > > +} > > + > > +/* > > + * Put character to the *first* suitable emulated UART's FIFO. > > + */ > > +int vuart_put_rx(struct domain *d, char c) > > +{ > > + struct vuart *vuart = vuart_find_by_console_permission(d); > > + > > + return vuart ? vuart->emulator->put_rx(vuart, c) : -ENODEV; > > and here? Ack > > > > +} > > + > > +bool domain_has_vuart(const struct domain *d) > > +{ > > + return vuart_find_by_console_permission(d); > > +} > > + > > +/* > > + * Local variables: > > + * mode: C > > + * c-file-style: "BSD" > > + * c-basic-offset: 4 > > + * indent-tabs-mode: nil > > + * End: > > + */ > > diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c > > index cb6df2823b00..156e64d9eb58 100644 > > --- a/xen/common/keyhandler.c > > +++ b/xen/common/keyhandler.c > > @@ -22,6 +22,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > static unsigned char keypress_key; > > @@ -352,6 +353,8 @@ static void cf_check dump_domains(unsigned char key) > > v->periodic_period / 1000000); > > } > > } > > + > > + vuart_dump_state(d); > > } > > > > for_each_domain ( d ) > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > > index 9bd5b4825da6..d5164897a776 100644 > > --- a/xen/drivers/char/console.c > > +++ b/xen/drivers/char/console.c > > @@ -33,6 +33,7 @@ > > #include > > #include > > #include > > +#include > > > > #ifdef CONFIG_X86 > > #include > > @@ -596,11 +597,12 @@ static void __serial_rx(char c) > > if ( !d ) > > return; > > > > - if ( is_hardware_domain(d) ) > > + if ( is_hardware_domain(d) && !domain_has_vuart(d) ) > > { > > /* > > * 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) != SERIAL_RX_SIZE ) > > serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; > > @@ -611,6 +613,8 @@ static void __serial_rx(char c) > > */ > > send_global_virq(VIRQ_CONSOLE); > > } > > + else if ( domain_has_vuart(d) ) > > + rc = vuart_put_rx(d, c); > > #ifdef CONFIG_SBSA_VUART_CONSOLE > > else > > /* Deliver input to the emulated UART. */ > > diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h > > index 8e1844555208..d7e81f098359 100644 > > --- a/xen/include/xen/serial.h > > +++ b/xen/include/xen/serial.h > > @@ -36,6 +36,9 @@ struct vuart_info { > > unsigned long data_off; /* Data register offset */ > > unsigned long status_off; /* Status register offset */ > > unsigned long status; /* Ready status value */ > > + unsigned int irq; /* Interrupt */ > > + const char *compatible; /* Compatible string */ > > + const char *name; /* User-friendly name */ > > }; > > > > struct serial_port { > > diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h > > new file mode 100644 > > index 000000000000..ca025b4179be > > --- /dev/null > > +++ b/xen/include/xen/vuart.h > > @@ -0,0 +1,116 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * UART emulator framework. > > + * > > + * Copyright 2025 Ford Motor Company > > + */ > > + > > +#ifndef XEN_VUART_H > > +#define XEN_VUART_H > > + > > +#include > > +#include > > + > > +struct vuart_emulator; > > + > > +enum { > > + VUART_CONSOLE_INPUT = 0U << 1, /** Physical console input forwarding. */ > > code style: single * Ack > This flag is zero, is that intended? Will fix, thanks > > > > +}; > > + > > + > > +/* > > + * FIXME: #ifdef is temporary to avoid clash with > > + * arch/arm/include/asm/domain.h > > + */ > > +#ifdef CONFIG_VUART_FRAMEWORK > > +struct vuart { > > + const struct vuart_emulator *emulator; > > + struct vuart_info *info; > > + struct domain *owner; > > + uint32_t flags; > > + void *vdev; > > +}; > > +#endif > > + > > +struct vuart_emulator { > > + /* UART compatible string. Cannot be NULL or empty. */ > > + const char *compatible; > > + > > + /* > > + * Allocate emulated UART state (RX/TX FIFOs, locks, initialize registers, > > + * hook I/O handlers, etc.) > > + * Cannot be NULL. > > + */ > > + void *(*alloc)(struct domain *d, const struct vuart_info *info); > > + > > + /* > > + * Release resources used to emulate UART state (flush RX/TX FIFOs, unhook > > + * I/O handlers, etc.). > > + * Cannot be NULL. > > + */ > > + void (*free)(void *arg); > > + > > + /* > > + * Print emulated UART state, including registers, on the console. > > + * Can be NULL. > > + */ > > + void (*dump_state)(void *arg); > > + > > + /* > > + * Place character to the emulated RX FIFO. > > + * Used to forward physical console input to the guest OS. > > + * Can be NULL. > > + */ > > + int (*put_rx)(void *arg, char c); > > +}; > > + > > +#define VUART_REGISTER(name, x) \ > > + static const struct vuart_emulator name##_entry \ > > + __used_section(".data.rel.ro.vuart") = x > > + > > +struct vuart *vuart_find_by_io_range(struct domain *d, > > + unsigned long base_addr, > > + unsigned long size); > > + > > +int vuart_put_rx(struct domain *d, char c); > > + > > +#ifdef CONFIG_VUART_FRAMEWORK > > + > > +int vuart_init(struct domain *d, struct vuart_info *info); > > +void vuart_deinit(struct domain *d); > > +void vuart_dump_state(const struct domain *d); > > +bool domain_has_vuart(const struct domain *d); > > + > > +#else > > + > > +static inline int vuart_init(struct domain *d, struct vuart_info *info) > > +{ > > + return 0; > > +} > > + > > +static inline void vuart_deinit(struct domain *d) > > +{ > > +} > > + > > +static inline void vuart_dump_state(const struct domain *d) > > +{ > > +} > > + > > +static inline bool domain_has_vuart(const struct domain *d) > > +{ > > + return false; > > +} > > + > > +#endif /* CONFIG_VUART_FRAMEWORK */ > > + > > +#endif /* XEN_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/xen.lds.h b/xen/include/xen/xen.lds.h > > index b126dfe88792..2d65f32ddad3 100644 > > --- a/xen/include/xen/xen.lds.h > > +++ b/xen/include/xen/xen.lds.h > > @@ -194,4 +194,14 @@ > > #define VPCI_ARRAY > > #endif > > > > +#ifdef CONFIG_VUART_FRAMEWORK > > +#define VUART_ARRAY \ > > + . = ALIGN(POINTER_ALIGN); \ > > + vuart_array_start = .; \ > > + *(.data.rel.ro.vuart) \ > > + vuart_array_end = .; > > +#else > > +#define VUART_ARRAY > > +#endif > > + > > #endif /* __XEN_LDS_H__ */ > > -- > > 2.51.0 > > From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:23:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:23:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105582.1456469 (Exim 4.92) (envelope-from ) id 1utCvf-0006QJ-Ne; Mon, 01 Sep 2025 22:23:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105582.1456469; Mon, 01 Sep 2025 22: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 1utCvf-0006QC-KZ; Mon, 01 Sep 2025 22:23:11 +0000 Received: by outflank-mailman (input) for mailman id 1105582; Mon, 01 Sep 2025 22: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 1utCve-0006Q6-71 for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:23:10 +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 3bf58e38-8782-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 00:23:08 +0200 (CEST) Received: from CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) by IA1PR12MB7495.namprd12.prod.outlook.com (2603:10b6:208:419::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 1 Sep 2025 22:23:03 +0000 Received: from CH3PR12MB8659.namprd12.prod.outlook.com ([fe80::6eb6:7d37:7b4b:1732]) by CH3PR12MB8659.namprd12.prod.outlook.com ([fe80::6eb6:7d37:7b4b:1732%4]) with mapi id 15.20.9073.026; Mon, 1 Sep 2025 22:23: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: 3bf58e38-8782-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bS1daFUznnVp//4wMYjsC7mQ61wfIUfOOaXIhB/KaP2C0FWv8GZ+AgFHdNow9W+6LXe4icajYJ2+WxXsc3zUbDKHO5qLBwEuMw+Q9bPQuu+vMYEQBHOuug5k1pMM+CHRmqItzRdnFmk0yd9gP1Dz8dtvUDuBXv37ceqZgk4JkGoauVNdC7DCt21lV4fbSKhkV5UqbzVrfG15J2hRPgi77evgwJcR5AbM88DSP+44Jl9DoMtdqDfb7NmsFMEjmsqpPAOnDztFEHEvqFK124YgXyGcVctt2NDvsBD9+LotYwcs40TPnAp0q4vlNtCGwMuLIVI1Kmi6+1vjV6I4h+6LPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9PcD09FKAh1vF3qniFuOOvXvPYB3eKU4OoIktmAdxRs=; b=WD2g5hBKoBkYOk72WapCvsuBh+eJvISk6j/e7JOqGTjIMxvJ6yAKX/KGI8zX0b5x+4+D7HcK3ab0wk3SSgkNNQppdXjtXvwPBNcDl/9NZoiOPLVlA8jNZj4FT0aSixw2m2UOrq1lugxBIVYkegHX2pu9CTI0Plgmcu0xrdJl/XdmmG2pvxFen7O4klgiyYAPTFe38ZrLdRzIPoHJi1rLN5fMWUI5o1tfon6zz69GRkz9LZxZUWlRiWWC9ogwpn6NCnXrDMvwgcJSwnxSofKEcQ8vMyV9E7xVIeOfnxtX5z0kY9O2R0Z8GRkFx68JvIa68t9nPT2dARPCjIyNbT6RZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9PcD09FKAh1vF3qniFuOOvXvPYB3eKU4OoIktmAdxRs=; b=iv80n33ELEVJgtxrACFzsV82DMFeFd43SDMUiVLoegOHzbTYcA7r4CMH1sbGiPoY6cwkuw8VulWQXba0j3FeFjvT99gIiZa4vX8Tzxx6ip5ceePsWwkLhRXSXlIYIfhDj575uqeU9wxrHXDHja0UAN2pR+vtTxAgO4nG3CyLXU+T05mEaLRUYs7E4y+fRcEbPSVIgJ8eY0kCgCrTk+rYKNed0UZd8lKNowWUkVaZ3s3qL7UShVOncZb5UGp2klTxwCLlqBGluBQPWABO3E40ijffqC669j7VNVkElnT7UPJLbWBGvdbKL4Mnt4A5edHgaXkcDk65Yj3I1HAbQh/hKw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Date: Mon, 1 Sep 2025 19:23:02 -0300 From: Jason Gunthorpe To: Marek Szyprowski Cc: Leon Romanovsky , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based API Message-ID: <20250901222302.GA186519@nvidia.com> References: <20250828115729.GA10073@unreal> <26bd901a-0812-492d-9736-4a7bb2e6d6b4@samsung.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26bd901a-0812-492d-9736-4a7bb2e6d6b4@samsung.com> X-ClientProxiedBy: YT2PR01CA0016.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:38::21) To CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR12MB8659:EE_|IA1PR12MB7495:EE_ X-MS-Office365-Filtering-Correlation-Id: 2712e776-387d-4145-20bb-08dde9a61dfa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?V0E1b1lMQkNvUlZFcUJCUEU4NWNRZTNUNnMwT3J1MjJOc0N0MTRoUWdhTkd1?= =?utf-8?B?VW9GZ1FISlp2ekpIeGRia1RkR1F5VThDUituWGpVWVVHOWlNZzB3bExoZVNn?= =?utf-8?B?SDJGRmcwYmlDTVcyQ1NkQ2lvd0lwVWIwcDlYYURNVFFBdHZMUHBvMURRR1Ir?= =?utf-8?B?OGc3UG42ZTRlMktlN1BCVUR4NHNCRDA2T2V2dUJBN1liUlRjTGxIT0hZMkhN?= =?utf-8?B?YmJaV0dTZ3VYS292S1VMb2hJSWNhYzRmWDJOZnFxaktvTWplVGRDUjQ0RlJ3?= =?utf-8?B?U2VVY0pxaHlmallkNkd2ZElUd2l3L0FDelhSeHQyTlNTd2hwS2xvMDF0RFlI?= =?utf-8?B?R2xVTTJ1NUxZTWgvSnNvTGp0Y0ovQ21LcTkvaFV5UmpTUzlTUDhEV0pibXhU?= =?utf-8?B?ejlXZkN3Z3NtRDR2bUx6dUVVL3BtM0ZyN3BDbGMrVHJpaS9BM0p6T2Uyclpw?= =?utf-8?B?eE1ESmxUNkFWSHkwZkFLdDhDaHloMUwvMFM0ZmtNaWtIaGhZRDdIZEZVcVYw?= =?utf-8?B?TC85ckZTa1M1bWtVQ3F1azFyeDFWb3lyL2crMEtVcVcrZjczTGRxdU1pY3lH?= =?utf-8?B?bXhlT2Rla2VpdDdIQUV4b21uQ3FGTnA0dU9ZU0lmSVo2TEJPcG1LaDVBTG1o?= =?utf-8?B?cW9INzArVVJlZUNUUXY0QytHN1J4M3VWRUpRZHlMYTFyZTA1RHdWVlo4dktW?= =?utf-8?B?dHNPdnl4dHovK0EyOHBneUN4aC9WdWhyamZodytPNTBzcHg2bU9nOCtpN2JG?= =?utf-8?B?TTB2NkRnT1FKWWo0bkNDdXZBY2dMVzVocHBXTnp6TXRGdDk5UlJSNWZsSWUw?= =?utf-8?B?YmRBRjc4RTNKdXdkTzc2MmtyaWt1VEphMTR2c3Q3UzBJOEhUYzBGQXdvYlpL?= =?utf-8?B?OW9VbDQ5dDJERTZRMW9Ib0R2bnduMFVSMVBBZ083YzBSSzNxM1hyU1RDTmVX?= =?utf-8?B?UHJEMnNsdC8vSmJDWUwvaW1ScXBGQUpnMGJCb1lIWVJSNW43Qm9rVTVCTVRD?= =?utf-8?B?aTIyMUUyUm9KelBESWc2UUJ4YWNEc2Z5ODBsRjVOKzM0SEQrMVF3QXV4SnQ5?= =?utf-8?B?T0t0dC94bGxHaUo4eml1UFY5bmtWQjNpdEZXZ1BsNE1nZmFyTlQwU1p4enZC?= =?utf-8?B?amFHa2pLM2c5Tk9wUk5ObUFFRnN3SjhIVUFEclhzN20wdG1tbmxYYjE1NnNU?= =?utf-8?B?dFM3dUhIWVZEN3E4ODFxS1lRUjVHSG1VNG9qMm5hRFRsOEYxb2F1MkxKdmdP?= =?utf-8?B?ajFQTU1VUVNrL2Rrb21mTkg2bXdSZThLUHJOSEhKSHh2SWlwM0t4RVl5ZXpo?= =?utf-8?B?bW1DNk9KOHNBMkcrWkwvM1JUZ1FPU2d5c0JHZmNvL1hrc1NsalRHUlExZTho?= =?utf-8?B?RFdDSDM0NXo5cW1kTlk4RDVGaWc3YUhTZTdMWHRJbXJ3Y3FwRjNkQUkxRW1i?= =?utf-8?B?VVRBUm4rQ3QydHNxMlRFaU9KM0h4N3VCMVE3dWlVay94V0o4ZzQrVDdoaU9C?= =?utf-8?B?d0hLZ0JWWDE2UXY3THY3T05hMFVkNjFvMG9GL3M4UytyaThINkRXTXhNVlhV?= =?utf-8?B?WTQyMnNqZk1TT1loRXdYSWV3ZjhsMURMRllTQVZvZFZ6MHhicyt3S3NTVm9y?= =?utf-8?B?NkkvVEttZU1nSUtmMDNhcE5UTjYxTXpGYVVuby9HQkY1MXQxVDdDdi9ZMzh6?= =?utf-8?B?dWtsc2dGTkJiWWNnVGVlbGw1V1VHb25CWmcvQmFjTTJvN3lHdlFsc1J0cFp4?= =?utf-8?B?b1BOMmFtWjhYVTZ6NjdleTlFVEFvSUNiYnc5MDNBUURpQk1VcFoyV01tSW41?= =?utf-8?B?WVg4N0kvUmxnVFhuZkZJZE1NRnVpQWowVW03bWRIZ1dSQ2FuTXdwVXEzMkRZ?= =?utf-8?B?V1IxblJ1L3A2N0Z4N2t3VGVaT1JNR0IzbHZVdlBtUk5qVFpSZnZGY1NsdXBN?= =?utf-8?Q?9gT21r84I2k=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8659.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RkpjdmdHb1RMcitLaVM5OG5FZUZkYlU1WndDVjBnR1RrdEwxT3Jvdk8rVklj?= =?utf-8?B?d3NEVm1qSzBERU1wdVptRFhTUGZRTG43SDVvSHRCL25yMnZaSUMvVE1sUDJE?= =?utf-8?B?aldBMXRhTnNYN0c3NUVxK1M4dGFNNjQ2VFBnMmV0MnJzSCt0YTJGWlhLM0Fy?= =?utf-8?B?WjBjVVFiMDFmL2JLby8yWk9KYkk2REh1TFVQVGtxSUtFbytRY0xhMWt0VWxG?= =?utf-8?B?VW5GcEozb25ZaHUxWGQ5N3RTa3g4L1ZQeUQ2SVY2T2VmdHFnV29pa2lNc0h6?= =?utf-8?B?YVgwZTlyRDgyNmlxY3g4V2FyaVNsKzUzTzRlL0R2TFUyUzljZWx2SmY0VEpw?= =?utf-8?B?WFUxeTBrczh5MytEUUtVbU5XT0pOZ2U5T3NMR0xxUW5BNTd2MjNEVEZKVTJ1?= =?utf-8?B?Z1BHckFwWlJxZUVKckNsSUxFdGlScEtxM2ZBMkRHcHFtaGtkeGc0TEFRbEdt?= =?utf-8?B?ZnlXd1BzdEdZYUZxVFJXRmlFVks5MDlnNUYyVk0raHJ4NUpWbnozNG14RW1B?= =?utf-8?B?YzVIVEdERkUreVZaZlhUMTlDbDdBVzRRb3NCM0hiZGg0cXhuVGkzNm1oc1VU?= =?utf-8?B?TG4vSXZON2F5ZGUzUk1KMFM3SlRtQ0hyQkJlSmFFM0lnRGlnaVZEbC9EL2V2?= =?utf-8?B?VlhYdDZWL082a3pidkNQeEpGZEUwc2NWTStKQlByZnNLV2p0bGpmR2VVM2ho?= =?utf-8?B?ZFU1V3NrbGNaWlgyRFUvYTlKaUV3Kys0Qk91N1AxemVMemVhOURUYTRkQmln?= =?utf-8?B?MnNCSSsydW9KWFhQS0d1eVdEUTlITGVTVzNFZXlyd3BxeTRrZkg4Sk03bEw2?= =?utf-8?B?TWU3TE5mRVNDRU9VMmQ3V09yNlN6cWFrMjNOTjN5bXIwTVQ0RWJKU0tXdUFH?= =?utf-8?B?b0t3MkJoYkc5ZlR2c3R6YjRaU2RWVFBYdnFnQ1kraU9tc0ZXNlExa2xMeVZU?= =?utf-8?B?RFEwQWJtbGZGRHR0NXlSYXZhV0E0THk3WGRERUU4a3gzYjlTMnJlUWZ6eDM4?= =?utf-8?B?d0M3Ti9NNy83S1lCWGFqT0luTkF2VzF0ZUo5OW1sWUwzRXVpZzd4cnJhNmx6?= =?utf-8?B?K0dnLzhOZVdqMTBjVjgrL3pUTlByL3Z4WitmbkRSaEFwZGp1VVdJUDhsQWY5?= =?utf-8?B?akZpMlh2aDVYSUhwVXNpZWVjTnJqVXZ4T0prNDdQL2JSN200dlZ6NlBocnow?= =?utf-8?B?clorWUFjejM3WnpURWFkU1k2dDlSZUZ3RHJCZm1ZU2s0VmxKVDVvVlNNc2Ro?= =?utf-8?B?NW10T3ZYdi9LRXQ0dVdBRmVURHdaRlMzaUJzRm1SLzdzU1NVZ0QrcGU3UEVT?= =?utf-8?B?ZklXY1l3cFE3M09uT2w4bjkzcHpMcXZHT3k3bjhTcmpuT3dnQ2RMRmdDMmRQ?= =?utf-8?B?UzBDMXpoVlpwb3RVVVNqY2FUbkttYmplV01RRlQ5K1Ruc3p3QmFmSytaWnJM?= =?utf-8?B?RGJiVWQ3eWp5RTVFYXhmQWUrYzJlbmVjbzA2d1NCKzN1eS9LYlBLbWtnNEd0?= =?utf-8?B?RVdQMHVFdWZwTnVFcnFMQkpneXhocmw3d0ZMalo2dHMwQmhnY0VwNjI5Mkta?= =?utf-8?B?ZUNDQmhtZlg5eUpyVFhPM2s1NFZhbGVkbU9DZ1lxL1RCbGR6Q201WmsyMXE4?= =?utf-8?B?T2laZ1Bqb1NDNmNjU1dFVXZQb0xQOXd5Q1VwbWZQeXJhSkxmamRJa0MvTDQ0?= =?utf-8?B?bU00WXVZWlNYOTd5SlJBWUNydkpNVVhIUkVabkI3OHI1VWV1QlowOC9TdVZY?= =?utf-8?B?cm0vNlViOVp1V2Nxc2czaWZjbW1VVDBURVlCbHc5L3JtN2gycDNGNkNUNis2?= =?utf-8?B?ZkdyWnN6UU9rNzJ5bFFLZFJreTZkanlIUkRibk1MMEk2L0VXcFhLcGp3TW1T?= =?utf-8?B?dnlQUE9RRmFheVRaUitFbTZQaG1oenBLSXg4WFFiZXFJbHV5d3RMYUN5azZI?= =?utf-8?B?ZmlmMHR4YytsKzlaeUJ1dXpjdG9EYkJka2tMd0pMOXk1RGRIS2JJaStRdEk0?= =?utf-8?B?a0NkRTlmcVY4RloxUUI3Q21LU01Md2MxUzhqTUZ6TjdiVisrWUR3aFpKMjZQ?= =?utf-8?B?Y3lDWVlqZC9iUzB3dmtEWjJOK0NldjA5SWxxejlxZnNUTUZBZW56OVBOVW1r?= =?utf-8?Q?mYgQ=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2712e776-387d-4145-20bb-08dde9a61dfa X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8659.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2025 22:23:03.5273 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: w4znFzS8ZQTnhjINhC0mXrOLe3RICQMXCayvRTPzL4tTrPL8qJPNdtjBo+rtk6D0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7495 On Mon, Sep 01, 2025 at 11:47:59PM +0200, Marek Szyprowski wrote: > I would like to give those patches a try in linux-next, but in meantime > I tested it on my test farm and found a regression in dma_map_resource() > handling. Namely the dma_map_resource() is no longer possible with size > not aligned to kmalloc()'ed buffer, as dma_direct_map_phys() calls > dma_kmalloc_needs_bounce(), Hmm, it's this bit: capable = dma_capable(dev, dma_addr, size, !(attrs & DMA_ATTR_MMIO)); if (unlikely(!capable) || dma_kmalloc_needs_bounce(dev, size, dir)) { if (is_swiotlb_active(dev) && !(attrs & DMA_ATTR_MMIO)) return swiotlb_map(dev, phys, size, dir, attrs); goto err_overflow; } We shouldn't be checking dma_kmalloc_needs_bounce() on mmio as there is no cache flushing so the "dma safe alignment" for non-coherent DMA does not apply. Like you say looks good to me, and more of the surrouding code can be pulled in too, no sense in repeating the boolean logic: if (attrs & DMA_ATTR_MMIO) { dma_addr = phys; if (unlikely(!dma_capable(dev, dma_addr, size, false))) goto err_overflow; } else { dma_addr = phys_to_dma(dev, phys); if (unlikely(!dma_capable(dev, dma_addr, size, true)) || dma_kmalloc_needs_bounce(dev, size, dir)) { if (is_swiotlb_active(dev)) return swiotlb_map(dev, phys, size, dir, attrs); goto err_overflow; } if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) arch_sync_dma_for_device(phys, size, dir); } Jason From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:27:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:27:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105597.1456479 (Exim 4.92) (envelope-from ) id 1utCze-00073i-Da; Mon, 01 Sep 2025 22:27:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105597.1456479; Mon, 01 Sep 2025 22:27: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 1utCze-00073b-9o; Mon, 01 Sep 2025 22:27:18 +0000 Received: by outflank-mailman (input) for mailman id 1105597; Mon, 01 Sep 2025 22:27:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utCzd-00073V-Og for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:27:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utCzc-001MrD-03; Mon, 01 Sep 2025 22:27:16 +0000 Received: from [19.12.91.86] (helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utCzb-00CPkp-36; Mon, 01 Sep 2025 22:27: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID :Subject:Cc:To:Date:From; bh=AmGRIEQWN2t3+uQnit31rIzuuiXDc8uOzL0/4xtUwQU=; b= mfho3S7JVhUpE/qLmTk5tRbxoUPJuvBEQ0kCGGf0pPw9tclvA84BPPPIGNCpEEUtDqJXzk5JrJPM3 U3caTXJ0KI6ElVRm6fCdjv58VkSpNHqM04F+MMjci/6DENMEILt1PJZRqi2I8YLeOWFnKHEkyrtx3 P0yslCA1LunVtWurA=; From: dmukhin@xen.org Date: Mon, 1 Sep 2025 15:27:14 -0700 To: Jan Beulich Cc: Stefano Stabellini , 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 v5 01/15] emul/vuart: introduce framework for UART emulators Message-ID: References: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-2-dmukhin@ford.com> <37f4c1af-29e3-44eb-a238-a3e2e4641f10@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37f4c1af-29e3-44eb-a238-a3e2e4641f10@suse.com> On Mon, Sep 01, 2025 at 10:14:04AM +0200, Jan Beulich wrote: > On 29.08.2025 21:27, Stefano Stabellini wrote: > > On Thu, 28 Aug 2025, dmukhin@xen.org wrote: > >> --- /dev/null > >> +++ b/xen/common/emul/vuart/vuart.c > >> @@ -0,0 +1,156 @@ > >> +/* SPDX-License-Identifier: GPL-2.0-only */ > >> +/* > >> + * UART emulator framework. > >> + * > >> + * Copyright 2025 Ford Motor Company > >> + */ > >> + > >> +#include > >> +#include > >> +#include > >> +#include > >> + > >> +#define for_each_emulator(e) \ > >> + for ( e = vuart_array_start; e < vuart_array_end; e++ ) > >> + > >> +extern const struct vuart_emulator vuart_array_start[]; > >> +extern const struct vuart_emulator vuart_array_end[]; > >> + > >> +static const struct vuart_emulator * > >> +vuart_match_by_compatible(struct domain *d, const char *compat) > >> +{ > >> + const struct vuart_emulator *emulator; > >> + > >> + if ( d->console.vuart ) > >> + return NULL; > >> + > >> + for_each_emulator(emulator) > >> + if ( emulator->compatible && > >> + !strncmp(emulator->compatible, compat, > >> + strlen(emulator->compatible)) ) > > > > strncmp will continue until the given count even if compat is shorter > > Not really, one string having a nul char and the other not having one is a > difference, at which point comparison will stop. There would be a problem > if "compat" didn't point to a nul-terminated string, though (and I didn't > check that aspect, not the least because then "shorter" doesn't really > make much sense without a length passed in). re: NUL-termination: current assumption is that both compat and emulator->compatible are NUL-terminated. Current `compat` comes from the hardcoded NUL-terminated string (vuart_info). In case of `compat` is not NUL-terminated (I plan to populate the field from xl in the future), strncmp() will stop after strlen(emulator->compatible) bytes. From xen-devel-bounces@lists.xenproject.org Mon Sep 01 22:28:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 22:28:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105608.1456489 (Exim 4.92) (envelope-from ) id 1utD0p-0007ZZ-NB; Mon, 01 Sep 2025 22:28:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105608.1456489; Mon, 01 Sep 2025 22:28:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utD0p-0007ZS-JB; Mon, 01 Sep 2025 22:28:31 +0000 Received: by outflank-mailman (input) for mailman id 1105608; Mon, 01 Sep 2025 22:28:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utD0o-0007Z4-Bc for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 22:28:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utD0m-001Mub-2z; Mon, 01 Sep 2025 22:28:29 +0000 Received: from [19.12.91.86] (helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utD0m-00CPmO-2s; Mon, 01 Sep 2025 22:28:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID :Subject:Cc:To:Date:From; bh=cPp7hDa5h8fSCLCzSE9D8VYRRaCm78mxCPYXlYmi7Bg=; b= fZsMdM4hGBjpz1uVsscM14g2Te0QfGei85W8GawZja6En/UZxIhJfsSjGSZvO+kzdQFHF5QcBThXr LT0JfJ8Bu4n64nUIlumLSsyYE/Bh5e9SpkQQrzyZgqm8SnT4XiWXzSk8nFKwGW/RPlKLKW0uDlOuJ iHGczT+wz+r5rjnlI=; From: dmukhin@xen.org Date: Mon, 1 Sep 2025 15:28:28 -0700 To: Stefano Stabellini 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 02/15] xen/8250-uart: update definitions Message-ID: References: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-3-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 29, 2025 at 12:32:46PM -0700, Stefano Stabellini wrote: > On Thu, 27 Aug 2025, dmukhin@xen.org wrote: > > From: Denis Mukhin > > > > Added missing definitions needed for NS16550 UART emulator. > > > > Newly introduced MSR definitions re-used in the existing ns16550 driver. > > > > Also, corrected FCR DMA definition bit#3 (0x08) as per: > > https://www.ti.com/lit/ds/symlink/tl16c550c.pdf > > See "7.7.2 FIFO Control Register (FCR)". > > > > Signed-off-by: Denis Mukhin > > --- > > Changes since v4: > > - reused newly introduced UART_IIR and UART_IER bits in ns16550 driver > > - Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-5-dmukhin@ford.com/ > > --- > > xen/drivers/char/ns16550.c | 16 ++++++------ > > xen/include/xen/8250-uart.h | 50 ++++++++++++++++++++++++++++++------- > > 2 files changed, 49 insertions(+), 17 deletions(-) > > > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > > index df7fff7f81df..0e80fadbb894 100644 > > --- a/xen/drivers/char/ns16550.c > > +++ b/xen/drivers/char/ns16550.c > > @@ -388,7 +388,7 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) > > > > /* Check this really is a 16550+. Otherwise we have no FIFOs. */ > > if ( uart->fifo_size <= 1 && > > - ((ns_read_reg(uart, UART_IIR) & 0xc0) == 0xc0) && > > + ((ns_read_reg(uart, UART_IIR) & UART_IIR_FE) == UART_IIR_FE) && > > ((ns_read_reg(uart, UART_FCR) & UART_FCR_TRG14) == UART_FCR_TRG14) ) > > uart->fifo_size = 16; > > } > > @@ -728,20 +728,20 @@ static int __init check_existence(struct ns16550 *uart) > > * Mask out IER[7:4] bits for test as some UARTs (e.g. TL > > * 16C754B) allow only to modify them if an EFR bit is set. > > */ > > - scratch2 = ns_read_reg(uart, UART_IER) & 0x0f; > > - ns_write_reg(uart,UART_IER, 0x0F); > > - scratch3 = ns_read_reg(uart, UART_IER) & 0x0f; > > + scratch2 = ns_read_reg(uart, UART_IER) & UART_IER_MASK; > > + ns_write_reg(uart, UART_IER, UART_IER_MASK); > > + scratch3 = ns_read_reg(uart, UART_IER) & UART_IER_MASK; > > ns_write_reg(uart, UART_IER, scratch); > > - if ( (scratch2 != 0) || (scratch3 != 0x0F) ) > > + if ( (scratch2 != 0) || (scratch3 != UART_IER_MASK) ) > > return 0; > > > > /* > > * Check to see if a UART is really there. > > * Use loopback test mode. > > */ > > - ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | 0x0A); > > - status = ns_read_reg(uart, UART_MSR) & 0xF0; > > - return (status == 0x90); > > + ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | UART_MCR_RTS | UART_MCR_OUT2); > > + status = ns_read_reg(uart, UART_MSR) & UART_MSR_STATUS; > > + return (status == (UART_MSR_CTS | UART_MSR_DCD)); > > } > > > > #ifdef CONFIG_HAS_PCI > > diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h > > index d13352940c13..bc11cdc376c9 100644 > > --- a/xen/include/xen/8250-uart.h > > +++ b/xen/include/xen/8250-uart.h > > @@ -32,6 +32,7 @@ > > #define UART_MCR 0x04 /* Modem control */ > > #define UART_LSR 0x05 /* line status */ > > #define UART_MSR 0x06 /* Modem status */ > > +#define UART_SCR 0x07 /* Scratch pad */ > > #define UART_USR 0x1f /* Status register (DW) */ > > #define UART_DLL 0x00 /* divisor latch (ls) (DLAB=1) */ > > #define UART_DLM 0x01 /* divisor latch (ms) (DLAB=1) */ > > @@ -42,6 +43,8 @@ > > #define UART_IER_ETHREI 0x02 /* tx reg. empty */ > > #define UART_IER_ELSI 0x04 /* rx line status */ > > #define UART_IER_EMSI 0x08 /* MODEM status */ > > +#define UART_IER_MASK \ > > + (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI) > > > > /* Interrupt Identification Register */ > > #define UART_IIR_NOINT 0x01 /* no interrupt pending */ > > @@ -51,12 +54,19 @@ > > #define UART_IIR_THR 0x02 /* - tx reg. empty */ > > #define UART_IIR_MSI 0x00 /* - MODEM status */ > > #define UART_IIR_BSY 0x07 /* - busy detect (DW) */ > > +#define UART_IIR_FE 0xc0 /* FIFO enabled (2 bits) */ > > > > /* FIFO Control Register */ > > -#define UART_FCR_ENABLE 0x01 /* enable FIFO */ > > -#define UART_FCR_CLRX 0x02 /* clear Rx FIFO */ > > -#define UART_FCR_CLTX 0x04 /* clear Tx FIFO */ > > -#define UART_FCR_DMA 0x10 /* enter DMA mode */ > > +#define UART_FCR_ENABLE BIT(0, U) /* enable FIFO */ > > +#define UART_FCR_CLRX BIT(1, U) /* clear Rx FIFO */ > > +#define UART_FCR_CLTX BIT(2, U) /* clear Tx FIFO */ > > +#define UART_FCR_DMA BIT(3, U) /* enter DMA mode */ > > +#define UART_FCR_RESERVED0 BIT(4, U) /* reserved; always 0 */ > > +#define UART_FCR_RESERVED1 BIT(5, U) /* reserved; always 0 */ > > +#define UART_FCR_RTB0 BIT(6, U) /* receiver trigger bit #0 */ > > +#define UART_FCR_RTB1 BIT(7, U) /* receiver trigger bit #1 */ > > +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1) > > + > > #define UART_FCR_TRG1 0x00 /* Rx FIFO trig lev 1 */ > > #define UART_FCR_TRG4 0x40 /* Rx FIFO trig lev 4 */ > > #define UART_FCR_TRG8 0x80 /* Rx FIFO trig lev 8 */ > > @@ -96,11 +106,32 @@ > > #define UART_LCR_CONF_MODE_B 0xBF /* Configuration mode B */ > > > > /* Modem Control Register */ > > -#define UART_MCR_DTR 0x01 /* Data Terminal Ready */ > > -#define UART_MCR_RTS 0x02 /* Request to Send */ > > -#define UART_MCR_OUT2 0x08 /* OUT2: interrupt mask */ > > -#define UART_MCR_LOOP 0x10 /* Enable loopback test mode */ > > -#define UART_MCR_TCRTLR 0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */ > > +#define UART_MCR_DTR BIT(0, U) /* Data Terminal Ready */ > > +#define UART_MCR_RTS BIT(1, U) /* Request to Send */ > > +#define UART_MCR_OUT1 BIT(2, U) /* OUT1: interrupt mask */ > > is OUT1 an interrupt mask actually? Yep, thanks, that should be just "Output #1". > > > > +#define UART_MCR_OUT2 BIT(3, U) /* OUT2: interrupt mask */ > > +#define UART_MCR_LOOP BIT(4, U) /* Enable loopback test mode */ > > +#define UART_MCR_RESERVED0 BIT(5, U) /* Reserved #0 */ > > +#define UART_MCR_TCRTLR BIT(6, U) /* Access TCR/TLR (TI16C752, EFR[4]=1) */ > > +#define UART_MCR_RESERVED1 BIT(7, U) /* Reserved #1 */ > > +#define UART_MCR_MASK \ > > + (UART_MCR_DTR | UART_MCR_RTS | \ > > + UART_MCR_OUT1 | UART_MCR_OUT2 | \ > > + UART_MCR_LOOP | UART_MCR_TCRTLR) > > + > > +/* Modem Status Register */ > > +#define UART_MSR_DCTS BIT(0, U) /* Change in CTS */ > > +#define UART_MSR_DDSR BIT(1, U) /* Change in DSR */ > > +#define UART_MSR_TERI BIT(2, U) /* Change in RI */ > > +#define UART_MSR_DDCD BIT(3, U) /* Change in CTS */ > > Changes in DCD, can be done on commit Will fix. > > > > +#define UART_MSR_CTS BIT(4, U) > > +#define UART_MSR_DSR BIT(5, U) > > +#define UART_MSR_RI BIT(6, U) > > +#define UART_MSR_DCD BIT(7, U) > > +#define UART_MSR_CHANGE \ > > + (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD) > > +#define UART_MSR_STATUS \ > > + (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD) > > > > /* Line Status Register */ > > #define UART_LSR_DR 0x01 /* Data ready */ > > @@ -111,6 +142,7 @@ > > #define UART_LSR_THRE 0x20 /* Xmit hold reg empty */ > > #define UART_LSR_TEMT 0x40 /* Xmitter empty */ > > #define UART_LSR_ERR 0x80 /* Error */ > > +#define UART_LSR_MASK (UART_LSR_OE | UART_LSR_BI) > > > > /* These parity settings can be ORed directly into the LCR. */ > > #define UART_PARITY_NONE (0<<3) > > -- > > 2.51.0 > > From xen-devel-bounces@lists.xenproject.org Mon Sep 01 23:11:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Sep 2025 23:11:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105621.1456499 (Exim 4.92) (envelope-from ) id 1utDgK-0005wj-Lu; Mon, 01 Sep 2025 23:11:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105621.1456499; Mon, 01 Sep 2025 23: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 1utDgK-0005wc-J6; Mon, 01 Sep 2025 23:11:24 +0000 Received: by outflank-mailman (input) for mailman id 1105621; Mon, 01 Sep 2025 23:11:23 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utDgJ-0005wW-BU for xen-devel@lists.xenproject.org; Mon, 01 Sep 2025 23:11:23 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utDgG-001NkK-1r; Mon, 01 Sep 2025 23:11:20 +0000 Received: from [19.12.91.86] (helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utDgG-00CRt3-1C; Mon, 01 Sep 2025 23:11: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID :Subject:Cc:To:Date:From; bh=IzUS3LHd/eImv6fvReZxzAMIz4AXhsNISL4sp9+JyZk=; b= VhkW8yZs+B28R0ZDwgFF6wPIuzbfkocJrbma7cfq3V03FePnC8VEp79266OZo41pTVGzZbyOIlC9n Mn+z/OeuKl1uX/h8cadjbXZS+leuIo9jWvU54IcgBy6hsLZCbY/wFwZH2vAHpjJ5AX6zz1S6nwTE1 FuS0DDQLjlwbLKSyI=; From: dmukhin@xen.org Date: Mon, 1 Sep 2025 16:11:19 -0700 To: Stefano Stabellini 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 03/15] emul/ns16x50: implement emulator stub Message-ID: References: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-4-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 29, 2025 at 12:57:43PM -0700, Stefano Stabellini wrote: > On Thu, 28 Aug 2025, dmukhin@xen.org wrote: > > From: Denis Mukhin > > > > The change is the first on the way on introducing minimally functional > > NS16550-compatible UART emulator. > > > > Define UART state and a set of emulated registers. > > > > Implement alloc/free vUART hooks. > > > > Stub out I/O port handler. > > > > Add initialization of the NS16x50-compatible UART emulator state machine. > > > > Plumb debug logging. > > > > Signed-off-by: Denis Mukhin > > --- > > Changes since v4: > > - new patch > > --- > > xen/arch/x86/hvm/hvm.c | 20 ++ > > xen/common/emul/vuart/Kconfig | 18 ++ > > xen/common/emul/vuart/Makefile | 1 + > > xen/common/emul/vuart/ns16x50.c | 362 ++++++++++++++++++++++++++++++++ > > xen/include/xen/sched.h | 4 + > > 5 files changed, 405 insertions(+) > > create mode 100644 xen/common/emul/vuart/ns16x50.c > > > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > > index 23bd7f078a1d..26760cf995df 100644 > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -28,6 +28,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -689,6 +690,21 @@ int hvm_domain_initialise(struct domain *d, > > if ( rc != 0 ) > > goto fail1; > > > > + if ( IS_ENABLED(CONFIG_VUART_NS16X50) ) > > maybe only for the hardware domain? > or only input_allowed = true only for the hardware domain? Agreed; I can enable it for dom0 for now. The plan is have vuart_info populated by xl similarly how it is done for vpl011. > > > + { > > + struct vuart_info info = { > > + .name = "COM2", > > + .compatible = "ns16550", > > + .base_addr = 0x2f8, > > + .size = 8, > > + .irq = 3, > > + }; > > + > > + rc = vuart_init(d, &info); > > + if ( rc ) > > + goto out_vioapic_deinit; > > + } > > + > > stdvga_init(d); > > > > rtc_init(d); > > @@ -712,6 +728,8 @@ int hvm_domain_initialise(struct domain *d, > > return 0; > > > > fail2: > > + vuart_deinit(d); > > + out_vioapic_deinit: > > vioapic_deinit(d); > > fail1: > > if ( is_hardware_domain(d) ) > > @@ -774,6 +792,8 @@ void hvm_domain_destroy(struct domain *d) > > if ( hvm_funcs.domain_destroy ) > > alternative_vcall(hvm_funcs.domain_destroy, d); > > > > + vuart_deinit(d); > > + > > vioapic_deinit(d); > > > > XFREE(d->arch.hvm.pl_time); > > diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig > > index ce1b976b7da7..539e6d5e4fc7 100644 > > --- a/xen/common/emul/vuart/Kconfig > > +++ b/xen/common/emul/vuart/Kconfig > > @@ -3,4 +3,22 @@ config VUART_FRAMEWORK > > > > menu "UART Emulation" > > > > +config VUART_NS16X50 > > + bool "NS16550-compatible UART Emulator" if EXPERT > > + depends on X86 && HVM > > + select VUART_FRAMEWORK > > default n Ack > > > + help > > + In-hypervisor NS16x50 UART emulation. > > + > > + Only legacy PC COM2 port is emulated. > > + > > + This is strictly for testing purposes (such as early HVM guest console), > > + and not appropriate for use in production. > > + > > +config VUART_NS16X50_DEBUG > > + bool "NS16550-compatible UART Emulator Debugging" > > + depends on VUART_NS16X50 && DEBUG > > + help > > + Enable development debugging. > > + > > endmenu > > diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makefile > > index 97f792dc6641..fe904f6cb65d 100644 > > --- a/xen/common/emul/vuart/Makefile > > +++ b/xen/common/emul/vuart/Makefile > > @@ -1 +1,2 @@ > > obj-y += vuart.o > > +obj-$(CONFIG_VUART_NS16X50) += ns16x50.o > > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c > > new file mode 100644 > > index 000000000000..f0479e1022fb > > --- /dev/null > > +++ b/xen/common/emul/vuart/ns16x50.c > > @@ -0,0 +1,362 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * NS16550-compatible UART Emulator. > > + * > > + * See: > > + * - Serial and UART Tutorial: > > + * https://download.freebsd.org/doc/en/articles/serial-uart/serial-uart_en.pdf > > + * - UART w/ 16 byte FIFO: > > + * https://www.ti.com/lit/ds/symlink/tl16c550c.pdf > > + * - UART w/ 64 byte FIFO: > > + * https://www.ti.com/lit/ds/symlink/tl16c750.pdf > > + * > > + * Limitations: > > + * - Only x86; > > + * - Only Xen console as a backend, no inter-domain communication (similar to > > + * vpl011 on Arm); > > + * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit); > > + * - No baud rate emulation (reports 115200 baud to the guest OS); > > + * - No FIFO-less mode emulation; > > + * - No RX FIFO interrupt moderation (FCR) emulation; > > + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and > > + * friends); > > + * - No ISA IRQ sharing allowed; > > + * - No MMIO-based UART emulation. > > + */ > > + > > +#define pr_prefix "ns16x50" > > +#define pr_fmt(fmt) pr_prefix ": " fmt > > + > > +#ifdef CONFIG_VUART_NS16X50_DEBUG > > +#define guest_prefix "FROM GUEST " > > +#define ns16x50_log_level 2 > > +#else > > +#define guest_prefix "" > > +#define ns16x50_log_level 0 > > +#endif > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#define ns16x50_log(n, lvl, vdev, fmt, args...) do { \ > > + if ( ns16x50_log_level >= n) \ > > + gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \ > > +} while (0) > > + > > +#define ns16x50_err(vdev, fmt, args...) \ > > + ns16x50_log(0, KERN_ERR, vdev, fmt, ## args) > > +#define ns16x50_warn(vdev, fmt, args...) \ > > + ns16x50_log(1, KERN_WARNING, vdev, fmt, ## args) > > +#define ns16x50_info(vdev, fmt, args...) \ > > + ns16x50_log(2, KERN_INFO, vdev, fmt, ## args) > > +#define ns16x50_debug(vdev, fmt, args...) \ > > + ns16x50_log(3, KERN_DEBUG, vdev, fmt, ## args) > > + > > +/* > > + * Number of supported registers in the UART. > > + */ > > +#define NS16X50_REGS_NUM (UART_SCR + 1) > > + > > +/* > > + * Number of emulated registers. > > + * > > + * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=0. > > + * - DLAB=1, R/W, DLL = NS16X50_REGS_NUM + 0 > > + * - DLAB=1, R/W, DLM = NS16X50_REGS_NUM + 1 > > + * - R/O, IIR (IIR_THR) = NS16X50_REGS_NUM + 2 > > + */ > > +#define NS16X50_EMU_REGS_NUM (NS16X50_REGS_NUM + 3) > > + > > +/* > > + * Virtual ns16x50 device state. > > + */ > > +struct vuart_ns16x50 { > > + struct xencons_interface cons; /* Emulated RX/TX FIFOs */ > > + uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */ > > + const char *name; /* Device name */ > > + struct domain *owner; /* Owner domain */ > > + const struct vuart_info *info; /* UART description */ > > + spinlock_t lock; /* Protection */ > > +}; > > + > > +/* > > + * Emulate 8-bit write access to ns16x50 register. > > + */ > > +static int ns16x50_io_write8( > > + struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data) > > +{ > > + int rc = 0; > > + > > + return rc; > > +} > > + > > +/* > > + * Emulate 16-bit write access to ns16x50 register. > > + * NB: some guest OSes use outw() to access UART_DLL. > > + */ > > +static int ns16x50_io_write16( > > + struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data) > > +{ > > + int rc = -EINVAL; > > + > > + return rc; > > +} > > + > > +/* > > + * Emulate write access to ns16x50 register. > > + */ > > +static int ns16x50_io_write( > > + struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *data) > > +{ > > + int rc; > > + > > + switch ( size ) > > + { > > + case 1: > > + rc = ns16x50_io_write8(vdev, reg, (uint8_t *)data); > > + break; > > + > > + case 2: > > + rc = ns16x50_io_write16(vdev, reg, (uint16_t *)data); > > + break; > > + > > + default: > > + rc = -EINVAL; > > + break; > > + } > > + > > + return rc; > > +} > > + > > +/* > > + * Emulate 8-bit read access to ns16x50 register. > > + */ > > +static int ns16x50_io_read8( > > + struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data) > > +{ > > + uint8_t val = 0xff; > > + int rc = 0; > > + > > + *data = val; > > + > > + return rc; > > +} > > + > > +/* > > + * Emulate 16-bit read access to ns16x50 register. > > + */ > > +static int ns16x50_io_read16( > > + struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data) > > +{ > > + uint16_t val = 0xffff; > > + int rc = -EINVAL; > > + > > + *data = val; > > + > > + return rc; > > +} > > + > > +/* > > + * Emulate read access to ns16x50 register. > > + */ > > +static int ns16x50_io_read( > > + struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *data) > > +{ > > + int rc; > > + > > + switch ( size ) > > + { > > + case 1: > > + rc = ns16x50_io_read8(vdev, reg, (uint8_t *)data); > > + break; > > + > > + case 2: > > + rc = ns16x50_io_read16(vdev, reg, (uint16_t *)data); > > + break; > > + > > + default: > > + *data = 0xffffffff; > > + rc = -EINVAL; > > + break; > > + } > > + > > + return rc; > > +} > > + > > +/* > > + * Emulate I/O access to ns16x50 register. > > + * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled. > > + */ > > +static int cf_check ns16x50_io_handle( > > + int dir, unsigned int addr, unsigned int size, uint32_t *data) > > +{ > > +#define op(dir) (((dir) == IOREQ_WRITE) ? 'W' : 'R') > > + struct domain *d = rcu_lock_current_domain(); > > + struct vuart *vuart = vuart_find_by_io_range(d, addr, size); > > + struct vuart_ns16x50 *vdev; > > + const struct domain *owner; > > + const struct vuart_info *info; > > + uint32_t reg; > > + unsigned dlab; > > + int rc; > > + > > + if ( !vuart || !vuart->vdev ) > > + { > > + printk(KERN_ERR "%c io 0x%04x %d: not initialized\n", > > XENLOG_ERR Will update KERN to XENLOG everywhere in the new code. > > > > + op(dir), addr, size); > > + > > + ASSERT_UNREACHABLE(); > > + goto out; > > + } > > + vdev = vuart->vdev; > > + > > + owner = vuart->owner; > > + ASSERT(owner); > > + if ( d != owner ) > > + { > > + ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domain %pv\n", > > + op(dir), addr, size, d); > > + > > + ASSERT_UNREACHABLE(); > > + goto out; > > + } > > + > > + info = vuart->info; > > + ASSERT(info); > > + reg = addr - info->base_addr; > > + if ( !IS_ALIGNED(reg, size) ) > > + { > > + ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n", > > + op(dir), addr, size); > > > For this one we could consider returning X86EMUL_UNHANDLEABLE but I am not sure > as it would crash the guest. re: crashing the guest: that is the main reason why I kept X86EMUL_OKAY. I think the emulator should not crash the guest OS since this is facility for OS bringup debugging. > > > + goto out; > > + } > > + > > + dlab = 0; > > + if ( reg >= NS16X50_REGS_NUM ) > > + { > > + ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": not implemented\n", > > + op(dir), addr, size, dlab, reg, *data); > > + goto out; > > + } > > + > > + spin_lock(&vdev->lock); > > + > > + if ( dir == IOREQ_WRITE ) > > + { > > + ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n", > > + op(dir), addr, size, dlab, reg, *data); > > + rc = ns16x50_io_write(vdev, reg, size, data); > > + } > > + else > > + { > > + rc = ns16x50_io_read(vdev, reg, size, data); > > + ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n", > > + op(dir), addr, size, dlab, reg, *data); > > + } > > + if ( rc < 0 ) > > + ns16x50_err(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": unsupported access\n", > > + op(dir), addr, size, dlab, reg, *data); > > + > > + spin_unlock(&vdev->lock); > > + > > +out: > > + rcu_unlock_domain(d); > > + > > + return X86EMUL_OKAY; > > +#undef op > > +} > > + > > +static int ns16x50_init(void *arg) > > +{ > > + struct vuart_ns16x50 *vdev = arg; > > + const struct vuart_info *info = vdev->info; > > + struct domain *d = vdev->owner; > > + > > + ASSERT(vdev); > > + > > + register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle); > > + > > + return 0; > > +} > > + > > +static void cf_check ns16x50_deinit(void *arg) > > +{ > > + struct vuart_ns16x50 *vdev = arg; > > + > > + ASSERT(vdev); > > it should unregister the handlers Unfortunately, there's no unregister_portio_handler() and AFAIU the reason for that is there's no need in it since I/O handlers will be destroyed during domain destruction when ns16x50_deinit() is called. > > > > +} > > + > > +static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info) > > +{ > > + struct vuart_ns16x50 *vdev; > > + int rc; > > + > > + if ( !info ) > > + return ERR_PTR(-EINVAL); > > + > > + if ( vuart_find_by_io_range(d, info->base_addr, info->size) ) > > + { > > + ns16x50_err(info, "already registered\n"); > > + return ERR_PTR(-EBUSY); > > + } > > + > > + if ( !is_hvm_domain(d) ) > > + { > > + ns16x50_err(info, "not an HVM domain\n"); > > + return ERR_PTR(-ENOSYS); > > + } > > + > > + vdev = xvzalloc(typeof(*vdev)); > > + if ( !vdev ) > > + { > > + ns16x50_err(info, "failed to allocate memory\n"); > > + return ERR_PTR(-ENOMEM); > > + } > > + > > + /* Save convenience pointer. */ > > + vdev->name = info->name; > > + vdev->owner = d; > > + vdev->info = info; > > the spinlock should be initialized Ack > > > > + rc = ns16x50_init(vdev); > > + if ( rc ) > > + return ERR_PTR(rc); > > + > > + return vdev; > > +} > > + > > +static void cf_check ns16x50_free(void *arg) > > +{ > > + struct vuart_ns16x50 *vdev = arg; > > + > > + if ( vdev ) > > + ns16x50_deinit(vdev); > > + > > + XVFREE(vdev); > > XVFREE should only be called if ( vdev ) Ack > > > > +} > > + > > +#define ns16x50_emulator \ > > +{ \ > > + .compatible = "ns16550", \ > > + .alloc = ns16x50_alloc, \ > > + .free = ns16x50_free, \ > > + .dump_state = NULL, \ > > + .put_rx = NULL, \ > > +} > > + > > +VUART_REGISTER(ns16x50, ns16x50_emulator); > > + > > +/* > > + * Local variables: > > + * mode: C > > + * c-file-style: "BSD" > > + * c-basic-offset: 4 > > + * indent-tabs-mode: nil > > + * End: > > + */ > > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h > > index 02bdc256ce37..613f4596e33d 100644 > > --- a/xen/include/xen/sched.h > > +++ b/xen/include/xen/sched.h > > @@ -23,6 +23,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -660,6 +661,9 @@ struct domain > > struct { > > /* Permission to take ownership of the physical console input. */ > > bool input_allowed; > > +#ifdef CONFIG_VUART_FRAMEWORK > > + struct vuart *vuart; > > +#endif > > this should be in patch #1, as patch #1 does: > > d->console.vuart = vuart; Yes, indeed, thanks. Will move to patch #1. > > > > } console; > > } __aligned(PAGE_SIZE); > > > > -- > > 2.51.0 > > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 05:57:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 05:57:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105648.1456509 (Exim 4.92) (envelope-from ) id 1utK0i-0002Je-P8; Tue, 02 Sep 2025 05:56:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105648.1456509; Tue, 02 Sep 2025 05:56:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utK0i-0002JW-Jh; Tue, 02 Sep 2025 05:56:52 +0000 Received: by outflank-mailman (input) for mailman id 1105648; Tue, 02 Sep 2025 05:56:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utK0h-0002JQ-H9 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 05:56:51 +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 9d75d31b-87c1-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 07:56:49 +0200 (CEST) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-55f6b0049fbso3902728e87.0 for ; Mon, 01 Sep 2025 22:56: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: 9d75d31b-87c1-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756792608; x=1757397408; 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=xBtYL/xnnKUkcWrtYrM1qKOpz0HGqjaiTcUTa+dApB4=; b=C68xT3vYHmAZLbz5ueVCUgObUYU0bueRLyhI5QXj7luym7ThMZOxfFGaRiE4zdSbk1 Hlg6D+KZHgqDm0CV3P/L85NKO5Vpd0Eo1kZL4509lSIQkHe0EnuQ1G7ValtFdYOj69Sf +YIXhf3tA/K0A2W1wN7tvIAuOX7ib7kPwYEy3AAY9kX2wZLBEKPZPJT5UHoLfN/qcJ9L wYHG+O/gzFIoxB+aFDaoJCYWse8sYs1lLDv+CKw6fOfKKO/QkdeBiUwbhMdmXkrwm2es SvzQiP8pXwZbhkfK4C5NKsItzjyqWS5UJ/oVj1FEzbhr+FhA8wojBcA2+sBPeVG0a1jc EcFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756792608; x=1757397408; 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=xBtYL/xnnKUkcWrtYrM1qKOpz0HGqjaiTcUTa+dApB4=; b=lBSbgeoeBj4DoQfARpgzLvXnHkH/oV/BUb8S5ebW0yyG089wdnHgTesNxzw2DxwYDf jjvU1ZWFLCkn3Esr6FQkTtHUvAZ8zUIWP+3Ehu6TLypdMjtWvF1XMxrZ3acSlgyXkReq 6gy6lwDH2IhnbAUGJsBmcp0lTz8S+4+Bjo51TcaE+9yUI3u7qbC2W8oRKVW3PEYbAgeK 7xkXL6MSCUOleurw3M0MQp7mjdEk8M9OurU4AoHdh3dPYl8em0qn8F7vqAG77jI1H9Pm z24/lwid8tDydKrNazm5pZ6i3aPHgPRg0ekC9ZEnoFjSMc3erYWqyyrqTaekeNjZj7U1 V/uQ== X-Gm-Message-State: AOJu0YznU6/UGJY/v5G9NjHlTQnf2wBCxwZ5JIqW/VnAvutHHmKfNrZC VjnvOB6p1u6FU0Xh36Lf7F40VXnAlRTfkSiBwL8qZYjc22vJkzyptfxFUnacka0Pdyk8cOC0jlg KXXi+BMWjCYU5y2t4XfigfQRtAUiPVYZ22jdc X-Gm-Gg: ASbGncsqszRwb55qhjpLJBERJ4Q9Rnl00W7/HUsS5bqu/pRTtIdROYU6Qh2q/+Cmu9U ftSuza/xyLQ3sDE4sPjWXyoVbV01I5tSOCnKVHzy+Dfl+Gq187D7y7uE/UGG5J30FIC4fLy6N0A a+pxiZz8HrGU1SOyO2ozoEiq0ne0LNmcfsU14R91HqshYs9GXlecnF5AhzF2UrEIFqC/wjk/aiG 4r9Ug== X-Google-Smtp-Source: AGHT+IFXcha/5CjsSsuttar5UKQAn3KJjmfTCEAK4htexyH3ZbhMkBqZJ3iK7kJF9+jHb2ifAUwGJKcdw6UkXgAmP18= X-Received: by 2002:a05:6512:689:b0:55b:574c:6bf9 with SMTP id 2adb3069b0e04-55f708ec420mr3178840e87.29.1756792607763; Mon, 01 Sep 2025 22:56:47 -0700 (PDT) MIME-Version: 1.0 References: <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com> In-Reply-To: <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com> From: Mykola Kvach Date: Tue, 2 Sep 2025 08:56:36 +0300 X-Gm-Features: Ac12FXxofPWhi2r78HN1CsICKYUEsvS2VLmzkBIXyWqAyVs6ptTW6cFeyW6wtfg Message-ID: Subject: Re: [PATCH v6 11/13] xen/arm: Add support for system suspend triggered by hardware domain To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, This is the first commit in the second part of the patch series that cannot exist without part 1. All previous commits are independent and do not depend on part 1. On Tue, Sep 2, 2025 at 1:10=E2=80=AFAM Mykola Kvach wrote: > > 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_SUSPE= ND, > including logic to: > - disable and enable non-boot physical CPUs > - freeze and thaw domains > - suspend and resume the GIC, timer, iommu and console > - maintain system state before and after suspend > > 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. > > Remove the restriction in the vPSCI interface preventing suspend from the > hardware domain. > > Select HAS_SYSTEM_SUSPEND for ARM_64. > > Signed-off-by: Mirela Simonovic > Signed-off-by: Saeed Nowshadi > Signed-off-by: Mykyta Poturai > Signed-off-by: Mykola Kvach > --- > Changes in v6: > - Minor changes in comments. > - The implementation now uses own tasklet instead of continue_hypercall_o= n_cpu, > as the latter rewrites user registers and would tie system suspend stat= us > to guest suspend status. > - The order of calls when suspending devices has been updated. > > Changes in v5: > - select HAS_SYSTEM_SUSPEND in ARM_64 instead of ARM > - check llc_coloring_enabled instead of LLC_COLORING during the selection > of HAS_SYSTEM_SUSPEND config > - call host_system_suspend from guest PSCI system suspend instead of > arch_domain_shutdown, reducing the complexity of the new code > - update some comments > > 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 duri= ng > suspend/resume > 2) suspend/resume the timer, GIC, console, IOMMU, and hardware domain > --- > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/include/asm/mm.h | 2 + > xen/arch/arm/include/asm/suspend.h | 2 + > xen/arch/arm/mmu/smpboot.c | 2 +- > xen/arch/arm/suspend.c | 150 +++++++++++++++++++++++++++++ > xen/arch/arm/vpsci.c | 9 +- > xen/common/domain.c | 4 + > 7 files changed, 168 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 5355534f3d..fdad53fd68 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -8,6 +8,7 @@ config ARM_64 > depends on !ARM_32 > select 64BIT > select HAS_FAST_MULTIPLY > + select HAS_SYSTEM_SUSPEND if UNSUPPORTED > select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH > > config ARM > diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.= h > index 7a93dad2ed..61e211d087 100644 > --- a/xen/arch/arm/include/asm/mm.h > +++ b/xen/arch/arm/include/asm/mm.h > @@ -365,6 +365,8 @@ static inline void page_set_xenheap_gfn(struct page_i= nfo *p, gfn_t gfn) > } while ( (y =3D cmpxchg(&p->u.inuse.type_info, x, nx)) !=3D x ); > } > > +void set_init_ttbr(lpae_t *root); > + > #endif /* __ARCH_ARM_MM__ */ > /* > * Local variables: > diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/as= m/suspend.h > index 29eed4ee7f..8d30b01b7c 100644 > --- a/xen/arch/arm/include/asm/suspend.h > +++ b/xen/arch/arm/include/asm/suspend.h > @@ -29,6 +29,8 @@ extern struct cpu_context cpu_context; > void hyp_resume(void); > int prepare_resume_ctx(struct cpu_context *ptr); > > +void host_system_suspend(void); > + > #endif /* CONFIG_SYSTEM_SUSPEND */ > > #endif /* __ASM_ARM_SUSPEND_H__ */ > 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 5093f1bf3d..35b20581f1 100644 > --- a/xen/arch/arm/suspend.c > +++ b/xen/arch/arm/suspend.c > @@ -1,9 +1,159 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > +#include > #include > > +#include > +#include > +#include > +#include > +#include > + > +/* > + * TODO list: > + * - Decide which domain will trigger system suspend ctl or hw ? > + * - Test system suspend with LLC_COLORING enabled and verify functiona= lity > + * - Implement IOMMU suspend/resume handlers and integrate them > + * into the suspend/resume path (SMMU) > + * - Enable "xl suspend" support on ARM architecture > + * - Properly disable Xen timer watchdog from relevant services (init.d= left) > + * - Add suspend/resume CI test for ARM (QEMU if feasible) > + * - Investigate feasibility and need for implementing system suspend o= n ARM32 > + */ > + > struct cpu_context cpu_context; > > +/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) *= / > +static void cf_check system_suspend(void *data) > +{ > + int status; > + unsigned long flags; > + /* TODO: drop check after verification that features can work togeth= er */ > + if ( llc_coloring_enabled ) > + { > + dprintk(XENLOG_ERR, > + "System suspend is not supported with LLC_COLORING enabl= ed\n"); > + status =3D -ENOSYS; > + goto dom_resume; > + } > + > + BUG_ON(system_state !=3D SYS_STATE_active); > + > + system_state =3D SYS_STATE_suspend; > + > + printk("Xen suspending...\n"); > + > + freeze_domains(); > + scheduler_disable(); > + > + /* > + * Non-boot CPUs have to be disabled on suspend and enabled on resum= e > + * (hotplug-based mechanism). Disabling non-boot CPUs will lead to P= SCI > + * CPU_OFF to be called by each non-boot CPU. Depending on the under= lying > + * platform capabilities, this may lead to the physical powering dow= n of > + * CPUs. > + */ > + status =3D disable_nonboot_cpus(); > + if ( status ) > + { > + system_state =3D SYS_STATE_resume; > + goto resume_nonboot_cpus; > + } > + > + time_suspend(); > + > + console_start_sync(); > + status =3D console_suspend(); > + if ( status ) > + { > + dprintk(XENLOG_ERR, "Failed to suspend the console, err=3D%d\n",= status); > + system_state =3D SYS_STATE_resume; > + goto resume_console; > + } > + > + local_irq_save(flags); > + status =3D gic_suspend(); > + if ( status ) > + { > + system_state =3D SYS_STATE_resume; > + goto resume_irqs; > + } > + > + set_init_ttbr(xen_pgtable); > + > + /* > + * Enable identity mapping before entering suspend to simplify > + * the resume path > + */ > + update_boot_mapping(true); > + > + if ( prepare_resume_ctx(&cpu_context) ) > + { > + status =3D 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. Execut= ion > + * will continue from hyp_resume which is the hypervisor's resum= e point. > + * In hyp_resume CPU context will be restored and since link-reg= ister is > + * restored as well, it will appear to return from prepare_resum= e_ctx. > + * The difference in returning from prepare_resume_ctx on system= suspend > + * versus resume is in function's return value: on suspend, the = return > + * value is a non-zero value, on resume it is zero. That is why = the > + * control flow will not re-enter this 'if' branch on resume. > + */ > + if ( status ) > + dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=3D%= d\n", > + status); > + } > + > + system_state =3D SYS_STATE_resume; > + update_boot_mapping(false); > + > + gic_resume(); > + > + resume_irqs: > + local_irq_restore(flags); > + > + resume_console: > + console_resume(); > + console_end_sync(); > + > + 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 oc= curs > + * when non-boot CPUs are hot-unplugged on suspend and hotplugged on= resume. > + */ > + rcu_barrier(); > + enable_nonboot_cpus(); > + scheduler_enable(); > + thaw_domains(); > + > + system_state =3D SYS_STATE_active; > + > + printk("Resume (status %d)\n", status); > + > + dom_resume: > + /* The resume of hardware domain should always follow Xen's resume. = */ > + domain_resume(hardware_domain); > +} > + > +static DECLARE_TASKLET(system_suspend_tasklet, system_suspend, NULL); > + > +void host_system_suspend(void) > +{ > + /* > + * system_suspend should be called when hardware domain finalizes th= e > + * suspend procedure from its boot core (VCPU#0). However, Dom0's vC= PU#0 > + * could be mapped to any pCPU. The suspend procedure has to be fina= lized > + * by the pCPU#0 (non-boot pCPUs will be disabled during the suspend= ). > + */ > + tasklet_schedule_on_cpu(&system_suspend_tasklet, 0); > +} > + > /* > * Local variables: > * mode: C > diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c > index 22c3a5f544..2f52aba48d 100644 > --- a/xen/arch/arm/vpsci.c > +++ b/xen/arch/arm/vpsci.c > @@ -4,6 +4,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -221,9 +222,10 @@ static int32_t do_psci_1_0_system_suspend(register_t= epoint, register_t cid) > if ( is_64bit_domain(d) && is_thumb ) > return PSCI_INVALID_ADDRESS; > > - /* SYSTEM_SUSPEND is not supported for the hardware domain yet */ > +#ifndef CONFIG_SYSTEM_SUSPEND > if ( is_hardware_domain(d) ) > return PSCI_NOT_SUPPORTED; > +#endif > > /* Ensure that all CPUs other than the calling one are offline */ > domain_lock(d); > @@ -249,6 +251,11 @@ static int32_t do_psci_1_0_system_suspend(register_t= epoint, register_t cid) > "SYSTEM_SUSPEND requested, epoint=3D0x%"PRIregister", cid=3D= 0x%"PRIregister"\n", > epoint, cid); > > +#ifdef CONFIG_SYSTEM_SUSPEND > + if ( is_hardware_domain(d) ) > + host_system_suspend(); > +#endif > + > return rc; > } > > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 667017c5e1..5e224740d3 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -1317,7 +1317,11 @@ int domain_shutdown(struct domain *d, u8 reason) > d->shutdown_code =3D reason; > reason =3D d->shutdown_code; > > +#if defined(CONFIG_SYSTEM_SUSPEND) && defined(CONFIG_ARM) > + if ( reason !=3D SHUTDOWN_suspend && is_hardware_domain(d) ) > +#else > if ( is_hardware_domain(d) ) > +#endif > hwdom_shutdown(reason); > > if ( d->is_shutting_down ) > -- > 2.48.1 > Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 06:15:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 06:15:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105661.1456519 (Exim 4.92) (envelope-from ) id 1utKIF-000546-8B; Tue, 02 Sep 2025 06:14:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105661.1456519; Tue, 02 Sep 2025 06: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 1utKIF-00053z-4r; Tue, 02 Sep 2025 06:14:59 +0000 Received: by outflank-mailman (input) for mailman id 1105661; Tue, 02 Sep 2025 06:14: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 1utKID-00053t-4n for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 06:14:57 +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 254bbaed-87c4-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 08:14:55 +0200 (CEST) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-afcb7ace3baso276479066b.3 for ; Mon, 01 Sep 2025 23:14:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0432937e0esm372708166b.3.2025.09.01.23.14.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 23: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: 254bbaed-87c4-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756793695; x=1757398495; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2zalHF03nmx5/7oED+m4rQP8/WRq7ErqVBE0DD+p6KA=; b=UdWT7+N0pJW+n7V4kLHnhBIOlmm5y9EJyL8pKbrhRp81VwMRncdN9rqS2W33dhtW3d 0Zf5GDY/AUjwRiSBflmOyhD40qeuU3/o6vShxi/jQgfkNz3O9xe46xP5fW4JbzCmN3uv nmHM20akF+59Q1pdaOL2+Psz9i4ffvHsEfmaSQN9mr5HQYcrSMJHh54owqaXdE8YyQvD +TUdYkr1c2TQCu/IezZT7f1Q4BXOzGpVyhM9vXMhQoaHkjjVj6Ern7iSDewT4wAVzTf3 j2GDhAYEiWe8zc4y8ILzmxobeyGUoZQnZTNJIXrzR4WofeVLC8DV0b8s8SI3WPlSs+K/ n7pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756793695; x=1757398495; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2zalHF03nmx5/7oED+m4rQP8/WRq7ErqVBE0DD+p6KA=; b=AUOzl7oTKApdV5FqSygqQFZfzX/fvmcq5Z8kLMDUtfQExVztZjXqyI1e38HGvOP1Ra H8z6T3808m2bCdIEgNx/V3whZnIB5+uRtUFg/XD+w+eKE6H9wQhxJxGR15lfJdmMVYVf m4Yk4A0UEF54wnNtsr3parJz0c88WMiHe3NLVFSjzNYGJykRrmlGACPF50Ki6LorfNzM 9LVFhNLFV4YZfKb3O2IC1vhLPwyzUeDOwkqSYSk0s4JdUKE0qtjk2/8VSea4dAjhUR4E ZR17jNRfVMkpVEkw4DvvhHiLETPmfz358LQQJYMYGtkrBCl4pDitYvvsHEoT15eHpCG3 +zyA== X-Forwarded-Encrypted: i=1; AJvYcCUzgpjhNBSDcdDzkzzljV0uaDgxu2eCMTqV1hTSLs3A5ov5v6HSd1jU9QRqaHep+IVowm2wrTyT/2U=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQlZaIMug9XvCogOr10WQ2J+6UHv6WPueXOmKnr6o8nYVZZYds FquIEMZZwVVcx0smT+yrjTmkcz431j42wYiX04+xW5CrVtWnKpmnMU51//pluYO2mg== X-Gm-Gg: ASbGncsgtR7fhJ1lqEH3EDcRulYkhkuuLEWTNJnvIwSXhmO0b+qln/yiWKkdaFpxqJp oL+Pf255HRNJE7hy/yJsTezvj/w8hIgGfXIVwdu3+EzDlFHftzEBBmFfNWXtHwLxP4laNCjuoBu svlt2X4SdOsIcsGjn1yuEsE9kWSv71uNn1XWLzCPTyfuBk5eSoaiInThf4zDD2ccbiaGWOzgLiS Z53ac/wgEuQApSNn0auWmvieXuqc1qHCw8X7JCXhRxioBanCW25c9Bmyr3cZG/IghpH5Lq3UjZ9 LKi9viZvixYG3MsPfWDtcowA5r1b0Hz1Y8ykxQexS6pGjmKA+wMPDR+xyQQMQ+LEYzK7ClH8u/L qRmnrhR0lZiucxGbX+HrIXhWGwoWhwHkvhLKJuINofaW6N6sjahV70mNYyCIr9GmN2PcgyheuxK ovdkIJUutvO23esglCJw== X-Google-Smtp-Source: AGHT+IFPzwzaX36F2yqdOVys+Jf5sqidojXsvgPveWj5uyEUNwk1f2MK0sIs6JYz0HJGOjU4LfqYEQ== X-Received: by 2002:a17:906:c445:b0:b04:198c:54a9 with SMTP id a640c23a62f3a-b04198c5b14mr618301366b.61.1756793695293; Mon, 01 Sep 2025 23:14:55 -0700 (PDT) Message-ID: <8b93405c-60d7-4289-b775-ffbd953d8e10@suse.com> Date: Tue, 2 Sep 2025 08:14:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 01/15] emul/vuart: introduce framework for UART emulators To: dmukhin@xen.org Cc: Stefano Stabellini , 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: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-2-dmukhin@ford.com> <37f4c1af-29e3-44eb-a238-a3e2e4641f10@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.09.2025 00:27, dmukhin@xen.org wrote: > On Mon, Sep 01, 2025 at 10:14:04AM +0200, Jan Beulich wrote: >> On 29.08.2025 21:27, Stefano Stabellini wrote: >>> On Thu, 28 Aug 2025, dmukhin@xen.org wrote: >>>> --- /dev/null >>>> +++ b/xen/common/emul/vuart/vuart.c >>>> @@ -0,0 +1,156 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>>> +/* >>>> + * UART emulator framework. >>>> + * >>>> + * Copyright 2025 Ford Motor Company >>>> + */ >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +#define for_each_emulator(e) \ >>>> + for ( e = vuart_array_start; e < vuart_array_end; e++ ) >>>> + >>>> +extern const struct vuart_emulator vuart_array_start[]; >>>> +extern const struct vuart_emulator vuart_array_end[]; >>>> + >>>> +static const struct vuart_emulator * >>>> +vuart_match_by_compatible(struct domain *d, const char *compat) >>>> +{ >>>> + const struct vuart_emulator *emulator; >>>> + >>>> + if ( d->console.vuart ) >>>> + return NULL; >>>> + >>>> + for_each_emulator(emulator) >>>> + if ( emulator->compatible && >>>> + !strncmp(emulator->compatible, compat, >>>> + strlen(emulator->compatible)) ) >>> >>> strncmp will continue until the given count even if compat is shorter >> >> Not really, one string having a nul char and the other not having one is a >> difference, at which point comparison will stop. There would be a problem >> if "compat" didn't point to a nul-terminated string, though (and I didn't >> check that aspect, not the least because then "shorter" doesn't really >> make much sense without a length passed in). > > re: NUL-termination: current assumption is that both compat and > emulator->compatible are NUL-terminated. > > Current `compat` comes from the hardcoded NUL-terminated string (vuart_info). > > In case of `compat` is not NUL-terminated (I plan to populate the field from > xl in the future), strncmp() will stop after strlen(emulator->compatible) > bytes. Which might be too late; if not nul-terminated, "compat" may extend past a page boundary, with the latter page not mapped. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 06:17:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 06:17:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105673.1456529 (Exim 4.92) (envelope-from ) id 1utKKj-0005cv-KS; Tue, 02 Sep 2025 06:17:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105673.1456529; Tue, 02 Sep 2025 06:17: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 1utKKj-0005co-H2; Tue, 02 Sep 2025 06:17:33 +0000 Received: by outflank-mailman (input) for mailman id 1105673; Tue, 02 Sep 2025 06:17: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 1utKKi-0005ci-De for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 06:17:32 +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 816d019a-87c4-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 08:17:30 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-aff0775410eso494033566b.0 for ; Mon, 01 Sep 2025 23:17: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-aff0971379esm932767866b.102.2025.09.01.23.17.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 23:17: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: 816d019a-87c4-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756793850; x=1757398650; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gZt3bFPJkMMncWlUEi9JchKzNhlanR/N4cao59y1WR4=; b=c/BGpDpm5sU8QtduBcFIeu0mc2uCQPHTfsIlXfnnGFQdoZxl4QTSg4cXJ3FgaxKgJx Kji/e8RuGrKWVoC1DZec94lK5D4rh6lKiW/7JA8dmNp6WUW9XlPYCmucTEEQ4Eo+GjUi 95lTmpz/2afFSdSEapBROsDDFvX68U5sTX7JuPfG7KBbJjGF5Ylc1yHbkvsA5Pokgt3F IOu2+APWrt+BylMPFG6SGxZlmfkFF1egj/ZnX7p1S/qSg5n6Ghp1DAOc8gVVO8tE20iS GUHeWcleLGRU4jkue1Shc0VxtEyYTPGZ0YtBICayLi+nHldSVzVzF612MaVQpmsCNyDl Qfqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756793850; x=1757398650; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gZt3bFPJkMMncWlUEi9JchKzNhlanR/N4cao59y1WR4=; b=KrY8JiKuAD8qpyA5yeLzic+EZJHUWIE1tXrxS9WL08b6r+pFFVnlHKZyfSdMEDVO/I oS6JDqsey1Id1lozW9JiWW7J0+m6b1FGZCG4X82JyABErtTM3F9/VB5R3sLTzhdDrZn3 /jXqTG4cVUjOal2z1fA7T42Unl7/5e8kWmbPHmzf+yfHUTVsY5NOOI2NsTJ6xR6IxfMp rN7ULnrfvk8Elv73zeKJO0Ywt9OfratviC461bK1duGntuwoGUTPksu+eoJMed3JnEWS t6jWL52AMpCNbwD+Q4/byJEtzUJfCxNWNVowRp9UOfgn7IKMC3HJmKlIcKqEdWRLs5wz nGEw== X-Forwarded-Encrypted: i=1; AJvYcCU6Dvn+7WiCY6clDqEL28UX5wkOjhRjHXQmzX60YerQkx1zpSjyHu/JSwMc7vgS31mxyhLOBJwp3mY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz3jxCgZWf5RbzS3r8dohSsU36yhwjDH9ujfUqCeqEzhiA7zUVw VmCdHmIVfTxZDwdGcvi/+6+lHApHP1XqD3VhOdvRQkkAkT/JG+OHPJWmPwGhIWp6Mw== X-Gm-Gg: ASbGncumc/jy/kVuCZhTV65YBt4T+FkjR6bWp9TOFGssrEmJI/bw15wFBAY5HJ2H63h r8tYgWZKvETCdlW+d/p+CuswnupPdiaE9F1Ng3TzJb/qR2G8B1IwJfTQKbMf4IhGOLI4yA61qJi StPs4MvTy5u6a/WPHTAHVTCODDE7Z2Ilz+b1Vw0PoR8CM+L+VM+gttN7EX5UlyOllt853pwasPJ qrzYFhxmcuVEN2FG3U9sQA+fzgdQ2b8Vpg7J/EbXCnD0Lo6i8sAfYypgPlowk2+9NvnN9iy3z06 53qXAwqbvYwDqVgQuv271iriYJz71Q7R1/MZ+gWsg52iHa5ielXzzZR51Y2mlYUAubeNwN/5n4t X/WDOvXRIwyLyFe++U9Do0rmVm0R6Ig5y4pYyx9yVWrM7xfPdOaYPD8gZ5i46Ro6K8YZMpRjaAr oPz8SKpOsvS7HBg4Ycng== X-Google-Smtp-Source: AGHT+IEFz7ntxND1P1n8C8vW/y1FvLVfItkGR4898+qm3QNOantCM8J87NocSkbqeSg8UhVwt+y9uQ== X-Received: by 2002:a17:907:980c:b0:afd:eb4f:d5d2 with SMTP id a640c23a62f3a-b01f20c8180mr1092497166b.31.1756793849863; Mon, 01 Sep 2025 23:17:29 -0700 (PDT) Message-ID: <70b835e4-2b38-48c7-a7de-9720939502cb@suse.com> Date: Tue, 2 Sep 2025 08:17:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/23] x86/boot: Use RSTORSSP to establish SSP To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250828150409.901315-1-andrew.cooper3@citrix.com> <20250828150409.901315-8-andrew.cooper3@citrix.com> <9322056d-9f09-4f5b-801b-6f0fdad5ead9@suse.com> <18e139ce-36a5-4a0c-8a9c-440ef1c1e29f@citrix.com> <595a24ff-9eb8-40f3-9108-dca02e5a7a2c@suse.com> <935c5307-86c4-48ae-80da-a4454f28398d@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: <935c5307-86c4-48ae-80da-a4454f28398d@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01.09.2025 20:53, Andrew Cooper wrote: > On 01/09/2025 4:41 pm, Jan Beulich wrote: >> On 01.09.2025 17:33, Andrew Cooper wrote: >>> On 01/09/2025 10:28 am, Jan Beulich wrote: >>>> On 28.08.2025 17:03, Andrew Cooper wrote: >>>>> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void) >>>>> if ( cpu_has_xen_shstk ) >>>>> { >>>>> wrmsrl(MSR_S_CET, xen_msr_s_cet_value()); >>>>> - asm volatile ("setssbsy" ::: "memory"); >>>>> + >>>>> + /* >>>>> + * IDT and FRED differ by a Supervisor Token on the shadow stack, and >>>>> + * therefore by the value in MSR_PL0_SSP. >>>> Beside not being overly relevant here afaict, is this last part of the sentence >>>> actually correct? Patch 06 doesn't write different values into the MSR. >>> It is correct, but also well hidden. >>> >>> #define MSR_FRED_SSP_SL0                    MSR_PL0_SSP >>> >>> I suppose I should should write MSR_PL0_SSP/MSR_FRED_SSP_SL0 here to >>> highlight the logically different names for the two modes. >> But the code following the comment doesn't access any MSR. That's what >> first tripped me up. It was only then that I wasn't able to spot the two >> different writes. Now that you point out the aliasing it becomes clear >> that until patch 14 it is simply impossible to find that other write. > > I suppose the MSR value isn't relevant now that neither paths write the > value.  The first iteration had both writes here. > > I guess I can drop that paragraph, and just have the second? I'd keep everything up to the comma (plus the other paragraph of course). Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 06:30:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 06:30:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105688.1456539 (Exim 4.92) (envelope-from ) id 1utKWk-0007QJ-Sf; Tue, 02 Sep 2025 06:29:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105688.1456539; Tue, 02 Sep 2025 06:29: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 1utKWk-0007QC-Pi; Tue, 02 Sep 2025 06:29:58 +0000 Received: by outflank-mailman (input) for mailman id 1105688; Tue, 02 Sep 2025 06:29:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utKWk-0007Q6-1B for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 06:29:58 +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 397c411d-87c6-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 08:29:48 +0200 (CEST) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55f6aef1a7dso3444033e87.0 for ; Mon, 01 Sep 2025 23: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: 397c411d-87c6-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756794588; x=1757399388; 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=5cjE7xFR7p96yq3ltRQjbzh9cdzevz1eMLuW8PVJ95o=; b=F625HtDIkgcdTM01PagbHlWqbZ/qYt68ccz3j4kpkelAJhWUO7f1PV9hwIjwf6jPe3 JM+kOrGptCmzjzhmyaRM8Tkoa2+El7J1ytB42kZOU+hnB60EiObDNHf7DqiGLoNIg7Sv D7SrOQvR7fwV5coVxT69EZic7T5aCBLsJCYdApyI3Wu40wnFXEjxU3RwPv9a9BNeItuO wvs+mUePEUaRxltIttTMoBf1i+6/3IveQv0E1Ww3CZBzBwZtUyT8GoRIOJPVCDPFOpX9 s0e2qCwkbhUoYf9PPHz+CdN12SWhf+qBvw+sLZQY8k0zGb23XfyNx6xpNejUOYpkcbMS JVIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756794588; x=1757399388; 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=5cjE7xFR7p96yq3ltRQjbzh9cdzevz1eMLuW8PVJ95o=; b=T71YJKKvokulYYhEFN4wv53D0HK6f0jZujFu9pbA9bLFmysbLRbpb00XWBog5JXam4 taEtfup1Le6I6oZIvlurvZSIyyyiBrBzOoRWT7dfBSpWsiESnyNTPwctMT+7RWp70Dof tcw8hRYktNH8mzdjdMp6adrgNfK6YsPIYcaftmgjJOZlyUeaJS6OdGt7jeVMMWctaTHP qWqjC1c4Eoo+cy7mchs2vCNkmRLUCGtKKAt3Sp2+w8h5OqycaHV1wXPGKexRISIYDIZb unpd1jR0quo1/SjiI3WttA7ogzZ83Bng3BmfKqBQsGmSWz+KwG9tmlp16zECvSOtRURL LM8Q== X-Forwarded-Encrypted: i=1; AJvYcCWWmZJpQOpjPVGeY41pBohQgfGiToNk+pjhr6FqT12x7AcgvWVZLHrqmLiPx3vQsZRDxsA0SKoTNHI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzhkccoXG4UEcB5aHcQfSVoGl8Y5Pe1EnMMxR7YyouYNKLH453Q ux6CuMN7aUGMN/+zZjwvYbeDuMj06uTdmc5Rxo1j8tNzxZtFsjyhmpgm1nlmqmAJMja3uIDOXus e1VdCY013o2TlCTqn2KbpD9FQtOz/rjs= X-Gm-Gg: ASbGncuiNF3nGEtuUWCEeH9OzeFU5XIXXbuLeiVtNEUBAk8yECkwYFTciTu2OL2yQ3v a0oBmgfUorjUBic+sUJf5NHRsa1I05h9BH85rGx52ej9Mgbyc1NxpvoeEalVn5lbOBV8G6P6CXC 1JDksegCs/JldVjW4WqsYxdqnuR0eNSq/QUAAxSsONi35Dx8dHCpWSNR3EPI5lhcFE7nZ08rVuU xbvRg== X-Google-Smtp-Source: AGHT+IHGv95C8iiEM+/MfGqOem+SSSjlvfC/N2MarBpapnVzdaxxJqW+0Ymp5XYJTJqTkh7k8YvNfMe+iFoE3PsyGN0= X-Received: by 2002:a05:6512:b88:b0:55f:4512:71f3 with SMTP id 2adb3069b0e04-55f70995affmr3150946e87.33.1756794588064; Mon, 01 Sep 2025 23:29:48 -0700 (PDT) MIME-Version: 1.0 References: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@suse.com> In-Reply-To: From: Mykola Kvach Date: Tue, 2 Sep 2025 09:29:37 +0300 X-Gm-Features: Ac12FXy1_-tUQo7L6wu-oUe2Le2_XmAoiRd9ISDotrBgRKLyFLlQR_AahCWQf-8 Message-ID: Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Jan Beulich Cc: Mykola Kvach , 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 On Mon, Sep 1, 2025 at 8:02=E2=80=AFPM Mykola Kvach wrote: > > Hi Jan, > > On Mon, Sep 1, 2025 at 5:29=E2=80=AFPM Jan Beulich wr= ote: > > > > On 31.08.2025 00:10, Mykola Kvach wrote: > > > --- a/xen/arch/ppc/stubs.c > > > +++ b/xen/arch/ppc/stubs.c > > > @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain= *d) > > > BUG_ON("unimplemented"); > > > } > > > > > > +int arch_domain_resume(struct domain *d) > > > +{ > > > + return 0; > > > +} > > > + > > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > > > { > > > BUG_ON("unimplemented"); > > > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > > > index 1a8c86cd8d..52532ae14d 100644 > > > --- a/xen/arch/riscv/stubs.c > > > +++ b/xen/arch/riscv/stubs.c > > > @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain= *d) > > > BUG_ON("unimplemented"); > > > } > > > > > > +int arch_domain_resume(struct domain *d) > > > +{ > > > + return 0; > > > +} > > > + > > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > > > { > > > BUG_ON("unimplemented"); > > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > > index 19fd86ce88..94a06bc697 100644 > > > --- a/xen/arch/x86/domain.c > > > +++ b/xen/arch/x86/domain.c > > > @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct doma= in *d) > > > hvm_domain_creation_finished(d); > > > } > > > > > > +int arch_domain_resume(struct domain *d) > > > +{ > > > + return 0; > > > +} > > > + > > > #ifdef CONFIG_COMPAT > > > #define xen_vcpu_guest_context vcpu_guest_context > > > #define fpu_ctxt fpu_ctxt.x > > > > I definitely don't like this redundancy, and even less so that you intr= oduce out- > > of-line calls. > > Thank you for your feedback. > I followed the existing pattern used in other architecture stubs. > > > > > > --- a/xen/include/xen/domain.h > > > +++ b/xen/include/xen/domain.h > > > @@ -109,6 +109,8 @@ int arch_domain_soft_reset(struct domain *d); > > > > > > void arch_domain_creation_finished(struct domain *d); > > > > > > +int arch_domain_resume(struct domain *d); > > > > I think this wants to move to a per-arch header, presence of which is c= hecked by > > has_include(), with an inline fallback define once centrally here. > > Would it be acceptable to use a weak function as the default > implementation instead? This way, architectures needing a real > implementation could override it, while others would use the weak > default. AFAIU, both your proposal and mine would violate MISRA C Dir 1.1 and Rule 1.1 (also Rule 1.2 but it is acceptable). According to these requirements, any use of compiler extensions should be documented and understood. In the context of the Xen hypervisor, such extensions must be listed in "docs/misra/C-language-toolchain.rst" as required by our project guidelines. > > > > > Jan > > Best regards, > Mykola Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 06:56:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 06:56:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105698.1456548 (Exim 4.92) (envelope-from ) id 1utKw8-0002tz-OZ; Tue, 02 Sep 2025 06:56:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105698.1456548; Tue, 02 Sep 2025 06:56: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 1utKw8-0002ts-Lj; Tue, 02 Sep 2025 06:56:12 +0000 Received: by outflank-mailman (input) for mailman id 1105698; Tue, 02 Sep 2025 06:56: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 1utKw6-0002tl-QY for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 06:56:10 +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 e64c3fac-87c9-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 08:56:07 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by AM7PR03MB6660.eurprd03.prod.outlook.com (2603:10a6:20b:1c1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.16; Tue, 2 Sep 2025 06:56:04 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 06:56: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: e64c3fac-87c9-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h/muRC0qsBWt0YjJz7RjPAAEEO4YNRcoU7PGOawaom3l9fWpNs9lAscj8iaM5DhTqTKIki89XqGYmDkLigumHCKNNSsYDYt6cCsLRx5bQEH0A/oqlgS4brFcBdY307k2T3YoektBJ3NRWRkNfCswt9q6A083FGQ2b9hKTuL77crJtcDeGW9hG/mydxuReo28NY/OLIeQUQQOgVSoXsOU3hOJ0LZXEEEg0DTvjJyhNcMkr1FSXQNqAYhMY2IFmt1Uzy70DOLXst7HCkkHGBPVvV0k3F5uZ/hKaspjDLWuc0KSGqEInNdLXe/T5ie1aPJd0v1v+tnTuPw7jpzru/2yfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kQ4wlDO2THQCpCtYA09thsa4uK1n5VuFcpGOJhtXlCQ=; b=U2T6Dr5vnp2+7Qi5DVdwE/ce3ZncF4M41SxNT3HE/TFOE3Cx/IbcZ1gMlCM4QiF7AiZPfK/T1Nrx6iW+bqIe8d/kP7yJblZ66B3+jyoL899BUFmIR6rXVAGkXwFOu3kMyZPpZHLfoihgrME/fQYLnoDPykEFZqpmtXKNcveFWiMSuJhZmjJyA5EqlaMYzNA0kWYAIxJ+kg1Qn2KMZH9ATGKmhTt1upgQ39FLeru9Zq+IELA0nJatxs0dbnRImXw2fTA1TKZK0xU0JioKfpoCl2LPhkLhIanAQ6rLonz82BIDcHDMwMX628mEy+JElIcGIVxPleKeD4qZdfjlF8DQ7g== 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=kQ4wlDO2THQCpCtYA09thsa4uK1n5VuFcpGOJhtXlCQ=; b=jlX6zLUnU2GoYix76Mf+AI3JPb6oaLySneIBdloBAumm4OqC1sBClYIt/q8c/nsrpmuJfdrArXZGG/YiHhjwn3TzPRaT0tvxXI+C81Ba+1kROHNE53s300+4dHP0pnrwBF0suTkAS8lEeA24B4fh7pgr19KCeNg93xr0RuiEMV9+a50ceNeIX/9nU/kLD+lkVVTFwj9M9AdMQS2mTs00Em+WBJze3VcPJPUe6W+65K6wgUuWZGJxpdiU4kYIcI32iDGbQQoLmLsRYuWW7Vlr27cUt2BOyyyzS2zWpIjGb98YwdWMQLcRU31UwGaP7D8eiVz4LdKpg2Zj3dQ+MptTbw== From: Leonid Komarianskyi To: Julien Grall , Oleksandr Tyshchenko CC: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Thread-Topic: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Thread-Index: AQHcGP7bBiDA5fxWR0+DupelLQbe97R8z4uAgAGbqoCAABpjAIAA9bWA Date: Tue, 2 Sep 2025 06:56:04 +0000 Message-ID: References: <87tt1pykqz.fsf@epam.com> <399bdb41-7938-4ed3-887a-c9bf6e0636ec@epam.com> <14f057e5-eb1e-4d10-87f9-98619fc30eb1@xen.org> In-Reply-To: <14f057e5-eb1e-4d10-87f9-98619fc30eb1@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: GV2PR03MB8678:EE_|AM7PR03MB6660:EE_ x-ms-office365-filtering-correlation-id: c605dd8e-82e4-4225-fd6b-08dde9edc8e4 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?Q09yMHNXelZEbU04K0ZsS05WVEZUUTF4MUVpYjNWVU1DMHJuK2x2N0YxSi8z?= =?utf-8?B?MFl1NmZRblp1ejhkSDRhWmJjWnU4cWtCOHRvc3pFRUsvekpjRDdQell5UEYy?= =?utf-8?B?a21makJURFhwUlZlR2tORlRQYVhSWjdjNDJYVy9JR29QU3V3WUplOWZuN2lN?= =?utf-8?B?cXEyWDRWVXZENEQ5RjRJN05hWGFvQXFTVlJuNnJXbzZleExVQityanJ4bEgz?= =?utf-8?B?N1poZ0dFbHRxdVJJb0hYaUE5eDFRMkV6aGJuREcxS2hCcGNqcGo5Vm9NQmhR?= =?utf-8?B?V0IveG1yWmtWQXIxZTNSR0NNNmZIeDN5STJIa2pBWlNTRlV5MCsraFNveWg4?= =?utf-8?B?bS80aDN6aVQwb1h3SW43cjlMS3JWaVBySkU5dTNPMXdHYzQ4bkVoZWhiYWJx?= =?utf-8?B?TFppeFpCb3pPNlB4MU1JWlVXMUpqRmJKV3RwcVBXTDA2MjVhV25tVDZvakJq?= =?utf-8?B?SDRhaHR6dTYzdGpYUGQ5cE00dG94SWVWMDVkTlAwSlpvSVRoODBqR29ZYkpq?= =?utf-8?B?UWNLN3UyTGVNOVlwNVgyMXVSZUg2L2dOai8wZGdHdFJTanFNUmo0dkhBdUZF?= =?utf-8?B?UnhsbzlyVkVKbUhSMEtmSWd3YThWQ2IzQUllM285bE82cDYzTVlDamljR2pG?= =?utf-8?B?SFVINTRseVpCN04xNmU3cEJEbjErZ2tvbUVtcFE4SjZvMHBsZDIwUkRma3hM?= =?utf-8?B?RnBJTE9YUVZCVlAvZmRPSVlVU1ZUY2dKSnVST09yU28rbVVaMHFFL3A5Rkoz?= =?utf-8?B?R0RrR2RPVHVkK29SQjdUajBHRXMzSHJuWjBHUUlCRzBrM3F1WEU5L1UxTExS?= =?utf-8?B?eHd5RzB1dlNzK1ZXcjlWNkhSZXR4c3FhcExuUHgvVWQ2OXJTVHE3K0djSWpj?= =?utf-8?B?cW5KSzg0djE2VU5xYTZNVmo1bUtDeVd3Q2RvT2VVbW5iZXJ2dDg5Ukh5Ynl3?= =?utf-8?B?dlQremVUWHNKSWk3eEtLVzk3SFZlb0JVS2FQZzZrWDBnclM1RElvUzNnc1da?= =?utf-8?B?c2cwQUhsY3grVG5WcXlDejVFaXpWRERGeC9Id2c2ODQ3SWF0L0N3NXJjeEty?= =?utf-8?B?K1BDK2lzMlVvMU1RdGdycXFRMGZxZWNCZHpIK2k1V1NBOVN5SEVIL3BJODBu?= =?utf-8?B?RFVZU0tyYS9ERWVaOFZKMFN6WWFSNU51UW8rZ0ZnQzV4QTg4MnRKeDRVTVor?= =?utf-8?B?eUVjNW9zQ2Y1Z2xkK05vVFhyTklFS3ZYRWtNQVlXSnpWNU0rWGhaVUYvbC9n?= =?utf-8?B?TWVqUlhlb0VIR1JCRC9IczNxVGEzQXFGM3ZkOGlFeHNaaDZrYUtvdEg0ZHZm?= =?utf-8?B?QXJ5cWNuQ29KMmg3QlpUQ1dybXhxckp3RW8wa1NGRjZVWXVCeTZ4aWhJTFN0?= =?utf-8?B?cStIOEU0YlJ6Q1JxaW5DOWJ1UkdlWk84NDdLVFcrSmNhZG5qMkQyNXNMN0xJ?= =?utf-8?B?ZTRZUkQ3SWx4RkRBUzM0OE02NVNuZEV6VXg0OXl5UVlHd2Q1MUQ5UE91VENJ?= =?utf-8?B?S3B6dk1XcWxjMmZ0dGJEUmJSSHFhb052K2pFSGlRK1dFTHg4R0ttQTJpSG04?= =?utf-8?B?Y3NpU2lLQlo1ektDa2dza3liKzhSdkFVWXVjd0YxbzlDd0k1NlE5UVVCUCtO?= =?utf-8?B?NEJGSWV3UXdCaE5NUWxYKzJ5QXVjSW5MZk1LU3U5Wk9LUjQ4T3JyaG52WVVU?= =?utf-8?B?WUJXZEo5ZmEwdDVROEZGQVZNSU9Yd3dyTEJxcXZReUo2TG9tR1dnbVB3Vndv?= =?utf-8?B?Tm9CYnlHWHRFR3g5bmM4UStDOG1NMk9EL05JWmJiYVN5TXFYN3ZScHNvVk41?= =?utf-8?B?UkRZTXhHV1ZJanU5OVB1NkpnZTZ5NENDTlBPOVMvRDFnZzFyZk9pYVh6RU9m?= =?utf-8?B?VERuNE01OHR1SEVkWHJyYkdMREJMSG43MHBhQjZ4NnRTSGxUTm1NWUY2Q1Ez?= =?utf-8?B?WEM4TWNqM3Jya3N1clZkM3QxZHJHcVlac2VtOTRNVG1DaW1mbUpLMUtEbnU4?= =?utf-8?B?ZnhIb0N2djV3PT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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?UEFMUUFERlpabjY2ZWNYaVIrbTRZeW1xclZZNWszckFFQ3NKN1dDL0Z1QzFx?= =?utf-8?B?U1dYTndyNktTb25pRDZPdXhybzNoNUc4YmMyNzA1Q0RiRE1KM0dyNjZLUUIx?= =?utf-8?B?cEdwZjd3YXJoQS9wTGpnTXhxU1RLNCtIQmZ0MnI3d3FwSjlwdW9MR3A0VTdM?= =?utf-8?B?aExtTjdBb2ZqL1lhd1V6cTVCSlo4aFBnSVNYUDNjQk4vVjhaaGdXWXlSZVg4?= =?utf-8?B?SHkyQ3loOU9ldzliN1hGVzBmdWVhSXZVZFVxSEhXM0JrM2M5djlCR3I4a3pt?= =?utf-8?B?MVhqbWRrZUZIdDN2NUtTWTh6RHhreTgxVnFjN0pMNXZLczJwbDRMVUpoUFNk?= =?utf-8?B?bFFkckFrZ3UrcVdXcFE4TW4xS09mWkNxSHFxdllvTldGRWc0bm0zZjZEaUtT?= =?utf-8?B?UVJ0THFhdVlVVnFlOCtpbHU3VGdleWI4V3d4Q0NLenNpK3F6Q3N6UC9HaUx4?= =?utf-8?B?UlV1VVZaNlBLUmZ0d3RKYUdKL2ordUtFSFcybUwzQkZCUFpvaC9BUmFPQTJr?= =?utf-8?B?STd1N1djRGttSThqK3pMZnh6V3k1Q2wyZjhwM0k5TkptM0NmdnIxekdCMXJN?= =?utf-8?B?YnAzampRM2hSTXBkdkV2VFVKcGh5R3NnY1BhbGYzUWc5dUFZRXFQOTYvWkND?= =?utf-8?B?V1ZaWFZGbjJsK0M1U0piay9VN25tUFI2Tzd1ZXJCbDJNbEVLamxwZmxCMWwy?= =?utf-8?B?cFRjdFdibFdYa2ZwSGJwSDFCUGhBKzJHQXptWkxscDFPMnRNN2tPRkh6NHpK?= =?utf-8?B?RHVlMkR3ZGlMblp1d3lqYnNzT2U1eW5IaXViYTZ1Mk1ja21hTHVkZ0lxMU9Y?= =?utf-8?B?VGNPeHUxRWZRYXZpdGYxY1htRGx1MGVKbGdmbUU3K2JrNmRxVncxekpSQ2ZI?= =?utf-8?B?VWU0d3VHWURxZmU4TDJuUE5PM0wxK3RiR053ZG55R2RqbkhEdW8zODJ2d1cr?= =?utf-8?B?S1dKcnpjUHBTOFZNc2dsTG9URlJNQjMvVXdTYXRJdUVKT01XY2RuZVNsakRW?= =?utf-8?B?T1BIZjU4Sm9ESmxiNHdBOFNZd2FaQ2xJNWp3Zk4vMlAzOExEYlR3U1ZaRnZO?= =?utf-8?B?bGY3T2VWc1lIMFllNmVrZWdrMTFTdjZNU0ptaE5oQTNGV01SS1Z2QkRqaC9t?= =?utf-8?B?dEl4Z1BZSnpuYUJzMHJxOC9RQWhPc0NRMnFmVmNlNnRrT3h1cnZnVVZWL3lZ?= =?utf-8?B?WUo2WEZyWW5iTkVmZE1jbWxQYVZvVGdQVDVEdGk2WHI4U0duOTFJTkRXbjFM?= =?utf-8?B?ei9jK3cyOVM1SDMwVnNzTVdLNmRZcnNjRVVhbWRVaEtvTWs3ZXBoSFFnMGxP?= =?utf-8?B?S2dyV3JMeSsyUVY1dlcwOUZKMHg5b1FiQmluU2d2LzQzdkY3ZUZqMGJ3alVP?= =?utf-8?B?WFRCWVFFM0dlUjZjK3ViUWVBSjVzcGx6bWdKZ2NNcXZhQVIzRHJVaklKM2V4?= =?utf-8?B?ZVY1MkRVcFVwNUpLSWZYUVBzcjdSV2pEUktxZWpUWGhzYlZWWWcxQjFnY05G?= =?utf-8?B?MHpPSFN4anFaM3hyVEo1K2JSdXMyU0dFc3FaK2Y5aC9hMGpWVnNQQlRkLzZk?= =?utf-8?B?TEJ1NTlXdjNyVHF6ZTFmbVYxdzBISVlUYjBTeGRwakptamlrSkE3WXMxd1dz?= =?utf-8?B?WnBxUXEydHJGY29XYlR1OWJCTGNETlNvT0lvUjBKTkl0dDR1Zkt4aXZkeGlY?= =?utf-8?B?cHdYUEliekpZdys0L1g3TFVVZ1pudkh2d1MyK3d0T2pSdzE5T0ZOc3lqQ2R1?= =?utf-8?B?ZERDZTJhcE9TZjdOckd6ZWp0KzRVK2pwdW1qaWpVQnFQb1pPNHo1WDhjeTBq?= =?utf-8?B?bUN2VHZhSzBwVStnQ2ZTdnpFeURQVWV6SlhoMTBVMFFYMlVkY2dDMzVOTVhO?= =?utf-8?B?eFlYVXdNb1pPODN2VGpRNlBRd1QreW1HRjRSclltelUxQy9JVzZwa0k0bm1I?= =?utf-8?B?VVhET1dzekVkTFAxZGthdFZlRytnckUzaTFEbFpJZkVpcWVPblN6MkZrMzNa?= =?utf-8?B?QzRUTXBzSXBtbU9remVGSk5KbjFSQ0NrN0tDVTBoUTRNVWpMdS9CeTcwWDRu?= =?utf-8?B?K0JZTXVHa01EZk9MTjhvRGlIazJkc3g0ckdtSGpxMThja3NaaXFyY2p6T3d6?= =?utf-8?B?alFYMS9ITTBqQnlxYmlpcGlwTnp4WU5wbDJ1VGFoWFRPZHRwdHJLalhNcTlB?= =?utf-8?Q?AGBok2aL1OKS9lcXFsdGul0=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <9875E6D730E34D4EAB957C9CCEBAB0DD@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c605dd8e-82e4-4225-fd6b-08dde9edc8e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 06:56:04.2992 (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: mAEeFbU6hE4nmm1jPifkvEcIeHMDLopDS7T2Kazxtm2mHARRHRGY7SuojloKDKImTZMOaTEalCK0CGqJ8yKTqxTWY5f4d/xxe3ZQAt7PWNc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6660 SGVsbG8gSnVsaWVuLCBWb2xvZHlteXIgYW5kIE9sZWtzYW5kciwNCg0KT24gMDEuMDkuMjUgMTk6 MTYsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGksDQo+IA0KPiBPbiAwMS8wOS8yMDI1IDE1OjQy LCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0KPj4+PiBUYWtpbmcgaW50byBhY2NvdW50IHRo YXQgd2l0aCBDT05GSUdfR0lDVjNfRVNQST1uIHdlIHNob3VsZCBuZXZlciBoYXZlDQo+Pj4+ICJp cnEiIGluIGVTUEkgcmFuZ2UsIGRvIHlvdSByZWFsbHkgbmVlZCB0aGlzICNpZmRlZj8gSSB0aGlu ayB0aGF0DQo+Pj4+IEFTU0VSVF9VTlJFQUNIQUJMRSBpbiBlc3BpX3RvX2Rlc2MoKSBpcyBzdWZm aWNpZW50IGd1YXJkLg0KPj4+Pg0KPj4+PiBBbHNvLCBJUlEgbGluZSBudW1iZXIgYmVsb25ncyB0 byBlU1BJIHJhbmdlIHJlZ2FyZGxlc3Mgb2YNCj4+Pj4gQ09ORklHX0dJQ1YzX0VTUEksDQo+Pj4+ IHZhbHVlLCBzbyBpbiBteSBvcGluaW9uIGlzX2VzcGkoKSBzaG91bGQgYWx3YXlzIHJldHVybiBj b3JyZWN0IHZhbHVlIA0KPj4+PiBmb3INCj4+Pj4gYSBnaXZlbiAiaXJxIi4NCj4+Pg0KPj4+IMKg IMKgLi4uIEkgYWdyZWUgd2l0aCBWb2xvZHlteXIncyBzdWdnZXN0aW9uIGZvciBpc19lc3BpKCkg dG8gYWx3YXlzIA0KPj4+IHJldHVybg0KPj4+IGNvcnJlY3QgdmFsdWUgZm9yIGEgZ2l2ZW4gImly cSIuDQo+Pj4NCj4+Pg0KPj4NCj4+IEkgd2lsbCBmaXggdGhhdCBpbiBWNi4NCj4gDQo+IEkgYW0g bm90IHN1cmUgYWJvdXQgdGhpcy4gSWYgaXNfZXNwaSgpIGlzIG5vdCByZXR1cm5pbmcgZmFsc2Ug d2l0aCANCj4gQ09ORklHX0dJQ1YzX0VQU0ksIHRoZW4gdGhlIGNvbXBpbGVyIHdvdWxkIG5vdCBi ZSBhYmxlIHRvIG9wdGltaXplIGNvZGUgDQo+IGxpa2U6DQo+IA0KPiBpZiAoaXNfZXNwaSguLi4p KSB7DQo+ICDCoMKgIHJldHVybiBlc3BpX3RvX2Rlc2MoaXJxKTsNCj4gfQ0KPiANCj4gcmV0dXJu ICZpcnFfZGVzY1tpcnEtTlJfTE9DQUxfSVJRU107DQo+IA0KPiBpcnFfdG9fZGVzYygpIGlzIGNh bGxlZCBmYWlybHkgb2Z0ZW4sIHNvIEkgd291bGQgbGlrZSB0byBrZWVwIHRoZSBjb2RlIA0KPiBm YWlybHkgb3B0aW1pemVkLiBBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byB1c2UgI2lmZGVmIENP TkZJR18qLiBJIA0KPiBkb24ndCBsaWtlIGl0LCBidXQgaXQgY291bGQgYmUgYSBjb21wcm9taXNl IGlmIE9sZWtzYW5kciBhbmQgVm9sb2R5bXlyIA0KPiB3YW50cyB0byBwdXNoIHRvIHJlbW92ZSAj aWZkZWYgZnJvbSBDT05GSUdfSVNfRVNQSS4NCj4gDQo+IENoZWVycywNCj4gDQoNCkkgYW0ganVz dCB0aGlua2luZyBhYm91dCBhIHBvc3NpYmxlIGNvbXByb21pc2UgYmV0d2VlbiB3cml0aW5nIGxv Z2ljYWwgDQpjb2RlIHdoZXJlIHRoZSBmdW5jdGlvbiBuYW1lIHJlZmxlY3RzIGl0cyBhY3R1YWwg ZnVuY3Rpb25hbGl0eSBhbmQgDQphbGxvd2luZyBmb3IgY29tcGlsZXIgb3B0aW1pemF0aW9uLiBQ ZXJoYXBzIGl0IHdvdWxkIGJlIGJldHRlciB0byBrZWVwIA0KdGhlICNpZmRlZiBidXQgcmVuYW1l IHRoZSBmdW5jdGlvbiB0byBgaXNfdmFsaWRfZXNwaSgpYCBvciBzb21ldGhpbmcgDQpzaW1pbGFy Lg0KDQpJbiB0aGF0IGNhc2UsIEkgdGhpbmsgdGhlcmUgd291bGQgYmUgbGVzcyBjb25mdXNpb24s IGFzIGl0IHNlZW1zIA0KcmVhc29uYWJsZSBmb3IgYSBmdW5jdGlvbiB3aXRoIHN1Y2ggYSBuYW1l IHRvIHJldHVybiBmYWxzZSB3aGVuIA0KQ09ORklHX0dJQ1YzX0VTUEk9biwgYW5kIGFsc28gdGhl IGNvbXBpbGVyIHdvdWxkIGJlIGFibGUgdG8gb3B0aW1pemUgdGhlIA0KY29kZS4NCg0KV2hhdCBk byB5b3UgdGhpbmsgYWJvdXQgdGhpcyBhcHByb2FjaD8NCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlk DQo= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 06:57:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 06:57:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105708.1456559 (Exim 4.92) (envelope-from ) id 1utKws-0003Oq-0P; Tue, 02 Sep 2025 06:56:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105708.1456559; Tue, 02 Sep 2025 06:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utKwr-0003Oj-Ti; Tue, 02 Sep 2025 06:56:57 +0000 Received: by outflank-mailman (input) for mailman id 1105708; Tue, 02 Sep 2025 06:56: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 1utKwp-0002tl-V1 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 06:56:55 +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 027174c3-87ca-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 08:56:54 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b042cc3962aso194314166b.0 for ; Mon, 01 Sep 2025 23:56: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 a640c23a62f3a-b03ab857474sm718771266b.89.2025.09.01.23.56.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Sep 2025 23: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: 027174c3-87ca-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756796214; x=1757401014; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hNnfACBahHBKeprYuJQzjChOP5KXOJ9ZHh3sDc3oWVk=; b=TLRV++gQAAwg2UsEexfF023pgRj1d8Xv79yp5w3V4xa7pRJSNKViDTDHOUEGTtuNk/ KXDIE4favuOdbVq1TcubJ/L1B9+DhAQcRYMWm7YKv9BnJP2sZCAlBThojSMRDdVY6EUg Gi1QVWjN1PRaBr+puW5UuUsJtqr6DJlEGb9Lc7pgoKfW1m5YtjV1PyvqRr/l+bAETnN+ 7sC891VL39z3I4JMSlP8zvkWZt0Dk02a9G0WpRSSqWWWXtURtIGj8FvTvircq4aQ5ZAb i44jodWOhkMxZQDWi6GcgdrHCTqwIXMdtBFFPLJSZekeuR2DS8hnWR4UVDJMuMpB/oE+ 8EXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756796214; x=1757401014; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hNnfACBahHBKeprYuJQzjChOP5KXOJ9ZHh3sDc3oWVk=; b=JjyCdEfUbNUIQo58EOyOQBAcSXiT/obCF+pSMebwQqrsIBZAxVCYsa3yrFQfPhgykF MVb2nEzXnO/IiyO0Tl4biJTACkhIDb+5nxXQeUVAr31QzqRzSLXW0FfzRHbemH9IH10M eWPiRWFIJoK/RAFMox6zKfJik8uzYyvsvSvYWta3ifnb8RUCpuNPtcczhGeE5qc925x0 9jjWxpnMHgMVF55uJ/cdkqbQFUo6YMBTcVkDcwO9uzpLp69bOJiVYZes8iEpKBWfudQB kG/xlSsfq3hq5LlNa6qcpH3SJfi0wPIi4kCgj5Y4+JgATKBcovamv87k8Vz+od9dQVgt RR/g== X-Forwarded-Encrypted: i=1; AJvYcCXMYjAjxGdBeUKRrZ3HESGmXI6pPr5fNYFucY08Btm/io2aUbtHR8I3MZeRQFv7BoedFnmMD2Tb0Bc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxoLhhIA/Ylbszipzok7T+JpQhMAYr0wq+LXl+GeNSDjzlnyQHt QuJP/pwaVuFfpV0n9ist+6w7PY0NOUkjQBVHU4gmNfTwbkCFF37x9xJ69FzKZjjB+A== X-Gm-Gg: ASbGncscuKY4asb3iGKmEhxf5tt4ZLI17aGGv0UrR69/NJxIj57/0TLodXBK9UNFZvA kXxCYTJc0ljwNJl8qL6a0O21wSO6BJbJ2+bVnm7GfjuenRIpnerLQwO9rLiYCOuQeEfiEem3kiH P80BQNDBzzDr2YM6YbMXUAQoJ7Mi/W9GvKLae9wGOnKT72okNgj/feTkEFgb/sKKtZJFzhytKO4 QX7vE1eKimE/fRZNzLRx5lmv9rVuRl8QKclgu1TBhMGayImdMHWRccaf7YLSaU2zVflbH+VjZRX OvT5o0FFbbWsEo9fKPlG0WeUxrjZ6AUY1ZJOYB0kjln4h3h8123DBGEkfU10AW356+GzsMNcK1M 9ovw8nHx7MNx29/SMo0yQTym50dh2pjBp24AtabTjul05Q9hPRgEuejY4o/6U419KkFX8qqSJaU VxpY7wcb4= X-Google-Smtp-Source: AGHT+IHys+Fr7k7u2T8Xv9vHg9gjIwVZD1vPPlQfAIi5Fna/rSCAumm02LFYNGVkNtRJlFSWZUu9wg== X-Received: by 2002:a17:907:2d27:b0:b04:27a9:cfe1 with SMTP id a640c23a62f3a-b0427a9df6dmr501066166b.47.1756796210184; Mon, 01 Sep 2025 23:56:50 -0700 (PDT) Message-ID: <6f9d9bb0-9e36-4c20-b464-364aafdf239f@suse.com> Date: Tue, 2 Sep 2025 08:56:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Mykola Kvach Cc: Mykola Kvach , 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: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@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.09.2025 08:29, Mykola Kvach wrote: > On Mon, Sep 1, 2025 at 8:02 PM Mykola Kvach wrote: >> >> Hi Jan, >> >> On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote: >>> >>> On 31.08.2025 00:10, Mykola Kvach wrote: >>>> --- a/xen/arch/ppc/stubs.c >>>> +++ b/xen/arch/ppc/stubs.c >>>> @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *d) >>>> BUG_ON("unimplemented"); >>>> } >>>> >>>> +int arch_domain_resume(struct domain *d) >>>> +{ >>>> + return 0; >>>> +} >>>> + >>>> int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) >>>> { >>>> BUG_ON("unimplemented"); >>>> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c >>>> index 1a8c86cd8d..52532ae14d 100644 >>>> --- a/xen/arch/riscv/stubs.c >>>> +++ b/xen/arch/riscv/stubs.c >>>> @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain *d) >>>> BUG_ON("unimplemented"); >>>> } >>>> >>>> +int arch_domain_resume(struct domain *d) >>>> +{ >>>> + return 0; >>>> +} >>>> + >>>> int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) >>>> { >>>> BUG_ON("unimplemented"); >>>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c >>>> index 19fd86ce88..94a06bc697 100644 >>>> --- a/xen/arch/x86/domain.c >>>> +++ b/xen/arch/x86/domain.c >>>> @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct domain *d) >>>> hvm_domain_creation_finished(d); >>>> } >>>> >>>> +int arch_domain_resume(struct domain *d) >>>> +{ >>>> + return 0; >>>> +} >>>> + >>>> #ifdef CONFIG_COMPAT >>>> #define xen_vcpu_guest_context vcpu_guest_context >>>> #define fpu_ctxt fpu_ctxt.x >>> >>> I definitely don't like this redundancy, and even less so that you introduce out- >>> of-line calls. >> >> Thank you for your feedback. >> I followed the existing pattern used in other architecture stubs. >> >>> >>>> --- a/xen/include/xen/domain.h >>>> +++ b/xen/include/xen/domain.h >>>> @@ -109,6 +109,8 @@ int arch_domain_soft_reset(struct domain *d); >>>> >>>> void arch_domain_creation_finished(struct domain *d); >>>> >>>> +int arch_domain_resume(struct domain *d); >>> >>> I think this wants to move to a per-arch header, presence of which is checked by >>> has_include(), with an inline fallback define once centrally here. >> >> Would it be acceptable to use a weak function as the default >> implementation instead? This way, architectures needing a real >> implementation could override it, while others would use the weak >> default. Besides this not addressing my out-of-line concern, we avoided the use of weak symbols so far. While I don't recall specific details, iirc this was somewhat related to Linux at some point deciding to reduce (eventually eliminate?) the use of weak symbols. > AFAIU, both your proposal and mine would violate MISRA C Dir 1.1 and > Rule 1.1 (also Rule 1.2 but it is acceptable). According to these > requirements, any use of compiler extensions should be documented and > understood. In the context of the Xen hypervisor, such extensions must > be listed in "docs/misra/C-language-toolchain.rst" as required by our > project guidelines. Just to mention that we use has_include() already, and that there are two uses of __weak in livepatch code (which I would prefer not to use as justification that further use of weak symbols is okay, as they're in macros used in livepatches only, not in core Xen). Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 07:13:26 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 07:13:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105725.1456569 (Exim 4.92) (envelope-from ) id 1utLCf-0006Kh-Fq; Tue, 02 Sep 2025 07:13:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105725.1456569; Tue, 02 Sep 2025 07:13: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 1utLCf-0006Ka-CY; Tue, 02 Sep 2025 07:13:17 +0000 Received: by outflank-mailman (input) for mailman id 1105725; Tue, 02 Sep 2025 07:13: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 1utLCe-0006KU-On for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 07:13:16 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20616.outbound.protection.outlook.com [2a01:111:f403:2418::616]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 49ae3519-87cc-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 09:13:13 +0200 (CEST) Received: from CH5P221CA0019.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:1f2::26) by IA0PR12MB8256.namprd12.prod.outlook.com (2603:10b6:208:407::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 07:13:08 +0000 Received: from CH2PEPF00000144.namprd02.prod.outlook.com (2603:10b6:610:1f2:cafe::c5) by CH5P221CA0019.outlook.office365.com (2603:10b6:610:1f2::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.16 via Frontend Transport; Tue, 2 Sep 2025 07:13:08 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CH2PEPF00000144.mail.protection.outlook.com (10.167.244.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9052.8 via Frontend Transport; Tue, 2 Sep 2025 07:13: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, 2 Sep 2025 02:13:07 -0500 Received: from [10.252.147.171] (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, 2 Sep 2025 02:13: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: 49ae3519-87cc-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gkLiALWYPvp/3guEW3yZJRJKSUdyiHBsGT9FEiEhcLahi6SGa/uo/mdP7XhpztTUbBR/ctbj0MR7sgAosuHrOENtiluwDqxANNyXqMLiOIKHivL2yRRrMCmMegSLh8Ris6wptOYjKGCUruMzA1lL4+++WkWHa0c1sA/fA4mp9vzxeLcwpDmHB1fg+idV+Km356OLFHWAlMvU6sAlH7ejmonfd/TTevoj3VJD0f/RBOE86VNzWtRceJ6agFk+asWBYyfUCwmZrvLC3LwgjNukS0dfuO9p7BcOuVFlmgycKhOTOdRhshm9ZIWbLtTBMuB0DzjLpnxfDyekU5piV6ORBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HzC0ktdehDgC+okBw3AnDkzV7KrQTUdhJBzFbCOXxVg=; b=emmGxHTnMULwJMVeRNKLQtlhXV+PfAtqrots/5RIWcm4BPlhZ8pPRMb44R7Uo1jgvT5rfgYKikip4eBCZZtzFX9fYbzFVI8YSTsDovFdN6w1srSCqs51gE939Wf8qi89Oc8GTwDlpN1MV8CJjbO+kI8PArIhyamZHMEgvxNE8qCctH2GPHZIHekPdF0dtDU825PAhYaUY3yAsyg5uKQ8X/9emcEirldkVCodDVzT3gmTeChA8i9IrrhnR7sa+FhjzTWwT0y9vLf2YVKLLvXB1bKWQopKgTOSR8kNSDB+heKeseZyAb2nKBou2xgj3ashFv0QSfHC3XBv1Pe3svd91g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HzC0ktdehDgC+okBw3AnDkzV7KrQTUdhJBzFbCOXxVg=; b=M4cT8ZMx4R3m1dAVmVZ1eOeASY9f7O/NqKq2jzEqonJR2YOymDNDdJ8a8AYaj4Nz4+QnYnDZ4Imo/bsQrWekxA9ImIwBNSrVVQDAY4EO4QUVdQvDUb5MxOQQUaTc8yuFY6wid2n2C48x4T7RmZJT/Zv+L2yhorq9JalbNQZ64h4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <73b47ad9-5594-4684-bdc7-7655fc686633@amd.com> Date: Tue, 2 Sep 2025 09:13:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: platform: Select GICV3 dependency for RCAR4 To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20250901140231.1322170-1-oleksandr_tyshchenko@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250901140231.1322170-1-oleksandr_tyshchenko@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000144:EE_|IA0PR12MB8256:EE_ X-MS-Office365-Filtering-Correlation-Id: 73a0fb1f-f7b4-4170-31b5-08dde9f02b55 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?M2RRaEsyU0s4ZUlBeEk2U2QzZi93Y0JTSXFRYzR2d3ZCeGRabHlNK2Fpc2Zt?= =?utf-8?B?cHpteXZMTnRBREZRQXExa005ZkJmcXcyQjIrMEVWa0F6bTl6NU4yYm1Vdjc2?= =?utf-8?B?ZjVrNDlCWG93OWtVME55U2VPbXNzVis1cjNwM3VaU3ZWQjdTSkZlQ05iMy9x?= =?utf-8?B?V0UrbXljN1VvZE9wMmIrV3ZodWhPZXdPSURDRkhUYWE5SVllSldRbXFYT1Jw?= =?utf-8?B?YmRwWDBPbkh4SXNIaldmQ3BjQStzU1kvSmtyWWt6YTVEVFdEWmtVTVZBK3Z3?= =?utf-8?B?YzdzZjNxTEUweEpsZXVCdmp0UXh4OS9oZ1pNOUd6K21reEtOVTZZaGR4U0NZ?= =?utf-8?B?WXgyeDVJQm1OWlFhazRsVWl4QWp1UnRONDFXSG5Ua1p6dVhJcFNuQlNVOXhM?= =?utf-8?B?S0sxdVlrNGtoYzVUTFZEbTU5dWhteWdiZC9sZFlwcHRIU3RWOU95RUhxczhX?= =?utf-8?B?NStyam8zb1ZVbnRNaW1ZUnVqYU1pbkgyazJUNVFUM2lid0JwaEtqb2F3NVJJ?= =?utf-8?B?WDFUYURHNERjYzF6SldrRUdra3RraHF4ZHkwbmg1QUp2dkxBS2RZTHdHdGk1?= =?utf-8?B?czh1cWZITndJMGZzYmJDdmkzaytTVkEwN2EwbUxhZHRXMlM0TFIxZGgzVUs3?= =?utf-8?B?aElnSWFNbGh4ckpJd25nVWE3SEc4b0lPYmdhRnprMzByQ0lROFhHOHhnK1cy?= =?utf-8?B?Mlh0U0p4L3p5VG11QU5rKzU2VW9Ib1lSNUNRWkFRVCtLKzRjWmt6T3VrRGYr?= =?utf-8?B?L045NFVqdURzcldRcnk4OHVEZXBOQ05DMGhab3VFRXp1eGtEZ2o1OFFQdFBI?= =?utf-8?B?aTl1TTBDeGc2RHBBcnVmSWZ3UVVXMGlIV2QzaFZkb2xqb0J6WmVnbERVT3Uw?= =?utf-8?B?NTM4ckVBUUc2ejY4L3BZZWcrLzZQVDdXeTRKbUZYU2N2MUF0c3RSU0JEeHdz?= =?utf-8?B?WHlWRWNtUUUrVkxvdkpHWHFCM1Y2TzF2MVVJNW9vUXZvMEw4UzBTcCtxbU9j?= =?utf-8?B?RmZteDBjdVUvcWg5aTlXdll4eEtkb0lRN25WM0hSNFVEL1JKMCtrN2hkK1dr?= =?utf-8?B?aGllRm5uN0dxWjZXQTZxZk1xREhWOVhTN3p5Y29hZ0FFdUhidENIQ1ZwMzU5?= =?utf-8?B?ODBFdDhFNkdsY2x1cFBIenRmdGxZNWRFbWxTeDFVVi8rRFA1T0JScWFNMjlL?= =?utf-8?B?bWw3bVZoMXZRWkMyT3h3dWZ0aTFFOXB4QlpEOEFCMk9kbDhLcE5DcVZWZTYr?= =?utf-8?B?cGQ5WXAvTytPZWZCUUFudmlINUt1RmxMVnQwMWpQR3dmMlczSzhlbCtHNmE5?= =?utf-8?B?d3FJbjFsVy9WUFJTRVhmS0lleS94S1ZlTnoyejRkU2tnZzZBQTg3allDS25O?= =?utf-8?B?TEhwdDZWY3Y0Vks0VDlZNGRaTE5BQUxWMDJYMkg1ZTgycXg2b2RUMWh6R21w?= =?utf-8?B?Rnp4VlRjRE1GejRzaTF0YkxCTkJsTk9Qd0VBTkxXQnlGam43dmx1UElhRENM?= =?utf-8?B?NEJueFdEbVNyb2pLM0lGY1pxQ1grWmRLdEdrK2hzWGFKemgzRXlNT2ZkS2ow?= =?utf-8?B?c1FiaUdqOTZ6TTN3Y0hVSGpGdExjNm9uL2dSM3dOZDZvTC9jQUFCU3dKMjF3?= =?utf-8?B?eitlV256Yi8xK1JkZ0phVmtocUVDbXZ3d2VLRWFFTlM1N1FTdVVMb21Md3h2?= =?utf-8?B?REdQWE1kWEtjR2FuRHoxYmc0RHREOUFlS0V6YWlPM3prR3VZakdHcUtXNERn?= =?utf-8?B?bmdVTDZiSFQ3UTB3dEVxM0JvRldQS01rSUtuc3R3a09IUmNGTDAwVENZMEZl?= =?utf-8?B?UW9CVGphYTQwTzhzNW16UWk5Z1RYS0ZweVRycnYyZng0cTVnSXlpVHhRVlcv?= =?utf-8?B?ZDd0bDRXMld0YTRobjZUUzZ3TldQVjdrU3pRMlNvS25TUGJ3VjhWMkFkdG8r?= =?utf-8?B?RFBxL1c0ZWd6Ynl3Q3ZNRmE1T2xQcTgvRUxqU2ZwWHh3UnYveVoxamN2Vkta?= =?utf-8?B?dkcwWGtML293bGJHOHdrMXpQeEd5YXRKSjVJZEVyVzJoTlFUaFJ0YXV4ZGFZ?= =?utf-8?Q?S+gjSm?= 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: 02 Sep 2025 07:13:08.4345 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 73a0fb1f-f7b4-4170-31b5-08dde9f02b55 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000144.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8256 On 01/09/2025 16:02, Oleksandr Tyshchenko wrote: > The Renesas R-Car Gen4 platform requires the GICv3 driver, > including support for the Interrupt Translation Service (ITS). > > Without explicitly selecting GICV3, it was possible to create a > configuration with RCAR4=y and GICV3=n, leading to a build failure > due to unmet dependencies. > > GICv3 driver (GICV3) [Y/n/?] (NEW) n > WARNING: unmet direct dependencies detected for HAS_ITS > Depends on [n]: GICV3 [=n] && !NEW_VGIC [=n] && !ARM_32 [=n] > Selected by [y]: > - RCAR4 [=y] && && ARM_64 [=y] > > ... > > arch/arm/gic-v3-its.c: In function 'gicv3_its_map_guest_device': > arch/arm/gic-v3-its.c:729:41: error: 'struct vgic_dist' has no member named 'its_devices' > 729 | struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL; > | ^ > arch/arm/gic-v3-its.c:755:28: error: 'struct vgic_dist' has no member named 'its_devices_lock' > 755 | spin_lock(&d->arch.vgic.its_devices_lock); > | ^ > arch/arm/gic-v3-its.c:768:54: error: 'struct vgic_dist' has no member named 'its_devices' > 768 | rb_erase(&temp->rbnode, &d->arch.vgic.its_devices); > | ^ > In file included from ./include/xen/sched.h:6, > from ./include/xen/iocap.h:10, > from arch/arm/gic-v3-its.c:13: > > ... > > Fix this by adding "select GICV3" to the RCAR4 Kconfig entry. > > Fixes: 336fc7a19b49 ("xen/arm: platform: Add support for R-Car Gen4") > Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 02 07:13:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 07:13:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105727.1456579 (Exim 4.92) (envelope-from ) id 1utLCz-0006hk-QL; Tue, 02 Sep 2025 07:13:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105727.1456579; Tue, 02 Sep 2025 07:13:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utLCz-0006hd-MK; Tue, 02 Sep 2025 07:13:37 +0000 Received: by outflank-mailman (input) for mailman id 1105727; Tue, 02 Sep 2025 07:13: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 1utLCy-0006KU-Cv for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 07:13:36 +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 568b9299-87cc-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 09:13:34 +0200 (CEST) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61d7b2ec241so2523792a12.0 for ; Tue, 02 Sep 2025 00:13: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 4fb4d7f45d1cf-61cfc5306e6sm8894821a12.47.2025.09.02.00.13.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 00:13: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: 568b9299-87cc-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756797214; x=1757402014; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yEuKdVC8jVOAIRi0jKxVRzwiN9984gTQsblzjeJPkQU=; b=aHhavqgYhcMv5J8MwH3n98d5+xvh/QeqdLR6KkCyngPOJ/bJ8yjlPa0fogR6KfNjpN eKreNXYlDtM/UFnQHJnoOj0JPuPldqeruKayJTJcMcGJeZxZT/qxGfkaFpPImNQriYB8 Ubv9MFYsuyORyYdW7luqNdwuqgFnMZNeUjZdxNK+cl0yRsrC+bRO6cVhyb8Vi4DgWQ4f Zq82WhBaK+KWasPCoa/MhbQ1vGpKcqbXuc+ajhnpiiBRNuN/Z++DJMdSRKFzKJv1gcup kZIlAayhDZ9FRnQMRLCveQkECL+uiuabiNxqFxd6aLQcLcxp9IDPyL0KEE7U1XQHrHgN XY/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756797214; x=1757402014; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yEuKdVC8jVOAIRi0jKxVRzwiN9984gTQsblzjeJPkQU=; b=cJj29XzhQdlBVYNVAHkbPRRWmbOq/WXMSK1GCfT3YHnuf+/wtn7i+lDNRJdCY66Vu7 TZw7XzAtO2qcI3BGCc+liuQ6Hh/EED6+bRyQIIGNbSwlwlmxONAX2WeQgO7mUxPB39H4 M3b4CSXmoVZELGWfvjpNVODTh/04zNu27M9zlKKfohLZ05kZBK0G6Wiq2xbIdlbvXkBo 8urX6snwoNk9Jnr8p7mQVxKhsAABHQusDE29cv/gws4gVxwiSZ1yKtAe+AfZGL9Z8Y5Z xETCQLN8vWEFol0Zs/gldGHtXQQzfAjyh0jsLrvMJp4mb8J8+vCk5U3sZrJefyAlWXw7 Qc7A== X-Forwarded-Encrypted: i=1; AJvYcCXdST2YcWeiHo272Mv8q8jHr97oY3jeFF8/86p3xld9plmsDO0STO3alh5nFZuExy3f3aKpK0IVvaQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxne9uk6tPSIqLyzUoOvbJXrfRbPrcrow5Fpyf88hJ0E7VZV28o yomH5O1fIGrF3sVppfVF5SsR3EqAz32Oeyz9ZP9TarcC9tBWl2SbhRRSf9kAnXToLg== X-Gm-Gg: ASbGnctvulWG38C07s9xmNbpKA+LxKalU3tDOt/WMJnxp1qBKk4a+6mvXTvOr8Cymtx gxZWlwUCMRnEocPo2mBOryWuzrkngd6hrsWn6JMobxKZLHH86wDw7Q4giRb/v8Yhyc/SuK69DyC zy/lXIvzR34+zf2NDRvea8VKBrRgxhXY/epkojsKChCZ5i2bFAaMoVUh8AxRQJ6DlkZms5s+GJ3 tFfaezfCYQelogmgeRlW2DRXOeA1JHcG8CUARnpaMmGJJLXmgh/z7v4YOAfcpb6S3t8nzS9LOpy KazzcWeJVQkx9XoYp2uiWgP1zV8oFVg62jsttQSLPQKoDUGHBVjlr07OaItavCG7Tz2ziHgZR8E aHGCEVTHqEG4JKBlYZfCtfhku/Ox2md/rcNB43iZaAgXhBOmBwU8NfHrWM4Y/neDlCRX2Whngpp Y+TcZ0fZVCysAfPjbL+g== X-Google-Smtp-Source: AGHT+IHBGrUyZF9el+LCNh1T4c5/X5bP60TbK0gGpxs6Toe4Gl1k6NESVRsWMrLnraCvny0au9HEGg== X-Received: by 2002:a05:6402:40ce:b0:61c:7b6e:b242 with SMTP id 4fb4d7f45d1cf-61d260cc398mr8608628a12.0.1756797214112; Tue, 02 Sep 2025 00:13:34 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 09:13:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Mykola Kvach Cc: Mykola Kvach , 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: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@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 01.09.2025 19:17, Mykola Kvach wrote: > On Mon, Sep 1, 2025 at 8:02 PM Mykola Kvach wrote: >> On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote: >>> On 31.08.2025 00:10, Mykola Kvach wrote: >>>> --- a/xen/arch/ppc/stubs.c >>>> +++ b/xen/arch/ppc/stubs.c >>>> @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *d) >>>> BUG_ON("unimplemented"); >>>> } >>>> >>>> +int arch_domain_resume(struct domain *d) >>>> +{ >>>> + return 0; >>>> +} >>>> + >>>> int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) >>>> { >>>> BUG_ON("unimplemented"); >>>> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c >>>> index 1a8c86cd8d..52532ae14d 100644 >>>> --- a/xen/arch/riscv/stubs.c >>>> +++ b/xen/arch/riscv/stubs.c >>>> @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domain *d) >>>> BUG_ON("unimplemented"); >>>> } >>>> >>>> +int arch_domain_resume(struct domain *d) >>>> +{ >>>> + return 0; >>>> +} >>>> + >>>> int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) >>>> { >>>> BUG_ON("unimplemented"); >>>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c >>>> index 19fd86ce88..94a06bc697 100644 >>>> --- a/xen/arch/x86/domain.c >>>> +++ b/xen/arch/x86/domain.c >>>> @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct domain *d) >>>> hvm_domain_creation_finished(d); >>>> } >>>> >>>> +int arch_domain_resume(struct domain *d) >>>> +{ >>>> + return 0; >>>> +} >>>> + >>>> #ifdef CONFIG_COMPAT >>>> #define xen_vcpu_guest_context vcpu_guest_context >>>> #define fpu_ctxt fpu_ctxt.x >>> >>> I definitely don't like this redundancy, and even less so that you introduce out- >>> of-line calls. >> >> Thank you for your feedback. >> I followed the existing pattern used in other architecture stubs. > > ... while I understand your concern about redundancy and out-of-line > calls, I would appreciate more specific technical reasoning for why > this approach is undesirable. Out of line functions, even if as simple as the example above, have a code size and performance effect; effectively empty inline functions can typically be eliminated altogether by the compiler, including the checking of their "return" values. While the impact may be low, any such instance can later be used as motivation / justification to introduce further instances (much like you did in to your earlier reply, still in context above). And the sum of them then may not be "low impact" anymore. Furthermore we're already moving towards wider use of has_include(). > Code review is most effective when it is based on objective criteria > and project guidelines, rather than personal preferences. And what did you derive from that my comment was purely based on a personal preference? Plus even if it were (often I would indicate so), that's imo still okay, as in many case maintainer preferences also matter (e.g. if only for a more consistent overall code base). > This helps contributors understand the rationale and make improvements > that benefit the whole project. While content-wise I agree, considering the amount of work I put into doing reviews, I still view this sort of "education" as pretty close to an offense. Plus did you consider how well it would scale if in every review all sorts of extra justification would need giving? I don't really like to put things this way, but I would really recommend you first start doing perhaps dozens of reviews a week before judging on whether any particular review gave you enough background info. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 07:27:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 07:27:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105746.1456588 (Exim 4.92) (envelope-from ) id 1utLQR-00009c-UE; Tue, 02 Sep 2025 07:27:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105746.1456588; Tue, 02 Sep 2025 07:27: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 1utLQR-00009V-RH; Tue, 02 Sep 2025 07:27:31 +0000 Received: by outflank-mailman (input) for mailman id 1105746; Tue, 02 Sep 2025 07:27: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 1utLQQ-00009P-QC for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 07:27:30 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20618.outbound.protection.outlook.com [2a01:111:f403:2417::618]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 47e5dea0-87ce-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 09:27:29 +0200 (CEST) Received: from CH2PR16CA0001.namprd16.prod.outlook.com (2603:10b6:610:50::11) by MN2PR12MB4224.namprd12.prod.outlook.com (2603:10b6:208:1dd::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 07:27:26 +0000 Received: from CH2PEPF00000142.namprd02.prod.outlook.com (2603:10b6:610:50:cafe::cb) by CH2PR16CA0001.outlook.office365.com (2603:10b6:610:50::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Tue, 2 Sep 2025 07:27:26 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH2PEPF00000142.mail.protection.outlook.com (10.167.244.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Tue, 2 Sep 2025 07:27:25 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 2 Sep 2025 02:27:25 -0500 Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Tue, 2 Sep 2025 00:27:57 -0700 Received: from [10.252.147.171] (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, 2 Sep 2025 02: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: 47e5dea0-87ce-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Bs4QUvXR/hMjPbJGs7OjAKnY4LCyBzrbtZHO1ir4hNPBGr860gHQBHMhKmTXo8nty6b3bMrx4+iLihdQxqV2ib29C/6I3YsGL5n1omiQnJ4wKJhwkuRL2ydjU6/VhlD7V+Sx/g1+IpkpO1/i8ZqdRC9yzYPDRgXcxpOQtXpZNX9F0LTrIHbCZ7AMJJgxxAyx+sio8Flqfpe1/A0QNutdeVZuPIeExHzMvpDCh/BPYZt49r+x3k+CqnRVZitu/i3n7dbVemzZPdaI4lGqjpz/IGevLaJJ1gUEJk1D7j9q+8ZSfF0R4HxbDQPmZFkKv+Qv1GQTD27FmZY/wUElAXgBTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EI/oTIsEH+yF+vdp5hZ8znu5avii+Lx+745u0RHTIhI=; b=zHpC1WboxZzy3HCPylSie6wH9Wer7la2UbDO9M18ncTglS1k/VyCDSAfLymGQ9meX8FQ7kI09X/RBCKGl5Y1ad/7gFZt0hf1uPRWtyuwmEJwDy9KQv+zmzSt9ZBYTbj5v641h1TWQEQJNUjrLmiFHFh8tpdwIOQa4X/emMK8Ksk7nlIzJlBrk4YFeHLt4d2ISKVmWNbWaB0N5Vznm6hWXAv+w+Hkn+b7k2KQfaXC6NKIzu8G9fKLRiM1Vv/szkxUYiyHz5nQ9CHh6cM+DPEJcXVqHMhQatOH77yulEB2RHUe5x38W+C5RZSCiCe0C1umwG1dER7+bXv9v5wWD5RwKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EI/oTIsEH+yF+vdp5hZ8znu5avii+Lx+745u0RHTIhI=; b=vkBhaWlg3KfkVkqalTv8zm+qDDqdwGwD6dsRsCN72+XdU2EWRGJ/q3gAOKsdnvGbNkekjVo5g9fx9LwOJpCh5b/EqhVeNO9hY6xi3zvh0mq6q9sQ9lgMQdHgOSFpGPe2KO1n3ZhtWRyh08/N6IWZ01Pzgft51cYgkiawWLG7w10= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <5d670f97-5e04-45b8-b9ad-81e42706bc47@amd.com> Date: Tue, 2 Sep 2025 09:27:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/public: arch-arm: Drop XEN_DMOP_get_ioreq_server_info from supported To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <20250901125837.1271101-1-oleksandr_tyshchenko@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250901125837.1271101-1-oleksandr_tyshchenko@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000142:EE_|MN2PR12MB4224:EE_ X-MS-Office365-Filtering-Correlation-Id: 8df24562-4c49-4526-a31c-08dde9f22a76 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?blhNUy9WWWJqTVJUSGhtZVRSeFJxajFyb1lJZHJwdmJOa05JVWFmUEs4WEoz?= =?utf-8?B?TDc1Sy9aa1hnZXRzbmNtbnYvQnVEcVZLY0JUOUNRUno3NVBvT1pWSERjazl4?= =?utf-8?B?N3l3aXlGYy9pYW5wVm1nVnJoY3cvWWRybVNpUXZIVlV3RlF0c284YTZiUE9z?= =?utf-8?B?cHROeXBLZmU3ak9NSXJ3ZElSN0NZSGJTRFJXM3hNV3dNL0dFa1FiTGx0Z3VF?= =?utf-8?B?Wld6R25Mb09wbk9wekg4S3BwaisxZkJGYkQ2bGFqSlo3M1VwRXhrckMvU1c0?= =?utf-8?B?ZEkya2M1OGlObWdKY3ovRDV4dUVkWWt4MUFRZGtXd1QwWll4eTUvK2dibitM?= =?utf-8?B?QTBaaGl6L1dyRS9vNFJlUFA4VEU0NFJneWJtT0dvUnNKSDQxVHRkdWV0VVlX?= =?utf-8?B?U1ZHRFlzRkdBWWQwcmErVjR0NVFHSlkxOWMwSkk0TWd5MEpWZVZlemdkdGUv?= =?utf-8?B?RFVUNlNnK2g2cGxWNktRbE5aVlliSVV3Y3BldVBLbGRIdGp5QUZSSlgwcERN?= =?utf-8?B?dnk1T3lSQXNLTmdabHFLcW9YOWZ5S2cxVFhlOGF5KzFqQnpLbE43M0ZCSmUv?= =?utf-8?B?UGNhamVqUkVnT2M0akZZSlVNKzBLb00rTXM5MkQ3R0tnVnNic0Nxd2JROUd6?= =?utf-8?B?bFVUWS8xUEhHTzVWZytWZlROUU95OXFVaXZhbkZya1pROFdHN1MvUUFZbTR1?= =?utf-8?B?UUQvMzBjbkRUbFdUbDJ2VzNWU1ZURThTZkFzVFU4VnNCcVNwdURiWWRCZzJk?= =?utf-8?B?MldGUlFobmZqS09Eb2MrcjBsZGNrU0N0TWJtM3J4RHV6OExuUm1rd1M2M3dD?= =?utf-8?B?K2pJWEljNk5MUmF3Q1FPNlFTNjByZURQaVRvWCtuZlFoWE1LekZBdWt3Wk83?= =?utf-8?B?SHZtWXZZcks5UlVabmpxUm1iRnUwYSt6WWtXN1NITU80K1BjMkpNOHJEZ0hP?= =?utf-8?B?L21WUGhPSU9kNzdBeFFVKzZZUXZOMFZJZGx4SVJlanpaWVJ4cW9EOXRQc21h?= =?utf-8?B?NXdkZXJDMlltTTUya01hZmV2YW1mQUdhWGVFZW1UV1pyemhOMjdaaUxPTjht?= =?utf-8?B?RGlWL0U3YW5wcDEzbDZZWmNhMVRGTHkxd1JmZnVQT3lMWU5FZTd2T3hucEJ1?= =?utf-8?B?Mmxxb3A3bndsMkFqVHBwdkZ6WmkreHBrY2ZYUTh1azVxRWs1K3ExejhheUpG?= =?utf-8?B?OFp6MDMvSjlWdGsxR1dpR3VDYWpuaithVjZFL3MyejNqNG84cmZEWVJjQzgw?= =?utf-8?B?WTByaExkZG9WZnViOGkwOXZESTIzTU53TUpwQkxJZlpGTVhmRUV0enVHK1FO?= =?utf-8?B?OXpxMkJqRk5SbWtvV0t2dXN1dmFocVJkTVhSbWRQT3JVUGRNK0owYk1EdWQ3?= =?utf-8?B?WDBUc0pyeERDOTNVWkVZc3NYdkwwb09EbmRQKzlPL1N5OUJxd3dCUm5VcUpy?= =?utf-8?B?NmE3Yjc1V1ZBa3o2SlRidy9qYjdjUUtzeStZejZGeHFrZzVvS0R3Ym9PV3dx?= =?utf-8?B?Sitha0tYRE8xR0lKQTFRUCs4L2ppTzdOZjNLcDZDUmZydDR3aUIzbzFCdlNZ?= =?utf-8?B?RWhQMWR4V0RiYlFWTkdKbnJ4YjExaHhMb2hRcFhDK0pKeXNYeWRHeWhjdHNn?= =?utf-8?B?S3hONGd0VzBjZG9iYTlVV3ZFa245a3NsZm5yVXd3VFJIVTZMYmk5OTlSNk4x?= =?utf-8?B?T2ZMbXEwNlhoMjl6Wlg3WlNOa3VKcG1pSWJvcXRRNXRhZy83czg5NktZUldO?= =?utf-8?B?clc4YldrTDNmKzNZL1dIbU9PWWlTMHMzVDRxK1JYVW5FMGhIQWJiWSt3R1JQ?= =?utf-8?B?ZzVJY1o2cUM3MlYvNHJCTkxrTjdtV01SZW9tMzd4cXluc2daUTZOdENKMno2?= =?utf-8?B?VUduNXZlS0h5N1c2Z3p3RmRwTXQrNmJjY1JPeVU5NjZSM3A5eEJGbXhuR3ZE?= =?utf-8?B?M1U4bkZoV1B3SkowZkMyeG5NaHRVSit3NExpNFc5Unc0anVmaVlIOG1HZzF5?= =?utf-8?B?eHJzekdnZmNKaHdkRXZ1OVI2Y2wzMnFXTnpyOHc4RDNDczdXZ0dLVEp4Ti9i?= =?utf-8?Q?zaQP3c?= 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: 02 Sep 2025 07:27:25.9710 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8df24562-4c49-4526-a31c-08dde9f22a76 X-MS-Exchange-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: CH2PEPF00000142.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4224 On 01/09/2025 14:58, Oleksandr Tyshchenko wrote: > The said sub-op is not supported on Arm64, since it: > - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn > cannot be returned), please refer to ioreq_server_create() > - does not support "legacy" mechanism of mapping IOREQ Server > magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please > refer to arch_ioreq_server_map_pages(). On Arm64, only the Acquire > Resource infrastructure is used to query and map the IOREQ Server pages. These points are valid. However, I don't understand why you mention Arm64 only. What about Arm32? It's the same here.> > Signed-off-by: Oleksandr Tyshchenko > --- > xen/include/public/arch-arm.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index e2412a1747..023cc2f468 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -130,7 +130,6 @@ > * HYPERVISOR_dm_op > * Exactly these sub-operations are supported: > * * XEN_DMOP_create_ioreq_server > - * * XEN_DMOP_get_ioreq_server_info > * * XEN_DMOP_map_io_range_to_ioreq_server > * * XEN_DMOP_unmap_io_range_from_ioreq_server > * * XEN_DMOP_set_ioreq_server_state This list is kept in sync with the op_size array in xen/arch/arm/dm.c. I think we should drop this op from there, not only from the comment listing supported ops. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 02 07:41:23 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 07:41:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105761.1456599 (Exim 4.92) (envelope-from ) id 1utLdl-000348-6K; Tue, 02 Sep 2025 07:41:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105761.1456599; Tue, 02 Sep 2025 07: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 1utLdl-000341-3g; Tue, 02 Sep 2025 07:41:17 +0000 Received: by outflank-mailman (input) for mailman id 1105761; Tue, 02 Sep 2025 07: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 1utLdj-00033u-SP for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 07:41:15 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20603.outbound.protection.outlook.com [2a01:111:f403:2417::603]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3313329a-87d0-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 09:41:13 +0200 (CEST) Received: from BN8PR15CA0004.namprd15.prod.outlook.com (2603:10b6:408:c0::17) by CYYPR12MB8655.namprd12.prod.outlook.com (2603:10b6:930:c4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 07:41:08 +0000 Received: from BL02EPF00021F68.namprd02.prod.outlook.com (2603:10b6:408:c0:cafe::8b) by BN8PR15CA0004.outlook.office365.com (2603:10b6:408:c0::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.16 via Frontend Transport; Tue, 2 Sep 2025 07:41:08 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF00021F68.mail.protection.outlook.com (10.167.249.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Tue, 2 Sep 2025 07:41:08 +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, 2 Sep 2025 02:41: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; Tue, 2 Sep 2025 02:41:06 -0500 Received: from XIR-MICHALO-L1.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; Tue, 2 Sep 2025 02:41: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: 3313329a-87d0-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SGMIEeRLYO/GHDqLPMVvbJuD1RB+7Ytxh7d9kstaQSU0bzyenNy2vf7HnzrvebJYpVUS9Wp1SFijvYzO+cdGb/7Hj2kYYpzsKq0a2ZyRiptoEN/3Iu1SXw9h/1jz1n345fMBg53iXz2Jzfi+y4lPqS4aUVBHcjJTDLH4en1IYIpaepcc37FPpNnfP5UecVy14qn8TaQzE5xssK2PubX87bYJ18sxhuqaF9xXZyagliVAJWpJAscfJ3VCOJczGTiSnisveaPSOugcagspX7oUns4heCjy5/Ug0bP/NouQ+YSGElHNGeBjpd8frLDU+wL/YozbH2/a1X9yuvR22Efyxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PypRkw6gaVGzZSLokYgt0zMAdxYAKVqWEWSnmDuouAI=; b=elRvcw5GtNQZRkOKSV0JUgFGG1hpN3AkJ9zT2f+3MOuBLNP/xOfNfRJy3Xd7A29TNprNSX7nI9qe6tIAh1vAf2R569aIJtjemL68HIcZtNWPFabsL0CuiCQ6Ex/d8VAm/ENdZCYeJviwm6qk0Eft0jAtjMuCOirQCioQO9xQ3AMLKbqlV0VC8g7AWpm8vFplnlReIj2pYHmOL9gyYYDwj+hjkoOjlP+g1Tqdvs7Zxc76nnXvYt6Cq0GPvPQgS1AL4esTHogGZFoyiFSjlRnO7C2XLzvuT18EmOzkC8Xv9RKEOgevay61/OBcftFMOBTmrboGT+cdJE8qJ9u10gQVCg== 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=PypRkw6gaVGzZSLokYgt0zMAdxYAKVqWEWSnmDuouAI=; b=WdbjlZElnKY9BvAw6Ni09JlfowTZOlmbkOxWOqHFpd31hkcXEusQIo33AjJprfhDn+TGhHoh2+0MSWJj1HfyxEKCCn2tiffzw9yXmGKcdLoFamvxNFURRMt9HMt93eIfuJJFko3zF7ur4HQI/j1t1l85YXgJxnj6FGKMMoI4PIM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v2] x86: Fix AMD_SVM and INTEL_VMX dependency Date: Tue, 2 Sep 2025 09:40:48 +0200 Message-ID: <20250902074048.12094-1-michal.orzel@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: BL02EPF00021F68:EE_|CYYPR12MB8655:EE_ X-MS-Office365-Filtering-Correlation-Id: 6a5c893c-84f4-4df4-9c91-08dde9f41475 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?40O+Evd8WffvRm8r7nIP+4hOmqpI8gVWyWPpVeHCKrdSjeTFXBKNgYPKaaan?= =?us-ascii?Q?zSHQz83VN71zgnXEj5AjM4jPERxWzzpD1DeJP9I8c9RYuoa39cK7AD6PSs2v?= =?us-ascii?Q?S68cNT+oPiwnAQR3A3JEQTgKM8HtEo+IWLsdEkYldcLgc84DYUGBJqV7RWcx?= =?us-ascii?Q?PnYK0VaUXPl/YMueVYKJUxsloPzp2kip+gSB+LA+OYskgrbkVkkHVTQwc84n?= =?us-ascii?Q?Qky/JduyCLy70NvVb2rW345BNY/xP74Rv/Y6mu/aGyM3SUVU9bHbXRc9WWLc?= =?us-ascii?Q?jFla5MO1kAR69RZdZPMpE8dD0M1RbK5JGpoOKIWEYX4QXsQ66hAu2oMSbcZ4?= =?us-ascii?Q?/B4eVIOO8HRPvFFaXDBbIe+k1tgTF+Yf1oe53oBAGXV1/PBlDUwKhFannGc3?= =?us-ascii?Q?I72Vf8XgnhghKHz6adESqL2t7TFGknwI+SsUypU99UA5p8JJ/EoHE/h8WFax?= =?us-ascii?Q?HwiXCmDgeUxdt5v5l3L+9Y/UyWRgzYNcGNBI6S3O9xpid0SL1SrbFQgW8wqT?= =?us-ascii?Q?Ayl71T2tYxN/CX33ZBTT+SdTYjsppYSAjlLIffwUsc2IKpIXXYkfWdEuZ0ek?= =?us-ascii?Q?r8n7fGybHH+8C5dxfxeOaWfF59q4fQe6MxI5p3lFrQDh8k14rtUzopYftGAv?= =?us-ascii?Q?n76qrmpwukTkYStylEPu0CEh/yAysyxPwlWg/3wNifvG9iI7sRWIjdQReM7S?= =?us-ascii?Q?DtYE9zblxAPtnGhuwlBV+M4Me6wjgN/l6Yawtt3uu2WAURaWz54ahvMVndbu?= =?us-ascii?Q?l5ZQpgqRIGSsuok9nUEeaD91OzD7Rr+zbUeohymT6L18vJg2qcz4ADW4PplK?= =?us-ascii?Q?qDy+gVkiIhwQePzB1joU7zaxHXLTZNPLcSw785XqilxH/pI2DvojCGuuJ8gh?= =?us-ascii?Q?IvYHG2oU4Rhtnl3dA2zBu5pHbXQ0gNXE3ziUc7i/E5oLhHW1DkHPkHTNU02g?= =?us-ascii?Q?3WUMd2pe9ghnBuY/20KTC4zPYSZqUtlsZpnhTQ869e5oWA5K7lLasKO6dfba?= =?us-ascii?Q?zFiGGjKIX2i/bB82ecahCTHYlPSQFZfRhXJ2JR9w4Kygotdo1uBMBrJyo2aJ?= =?us-ascii?Q?Ar/0BRRTrdln0RaGH4fHWfjXQ4l2HwQ53WMNlst7fNjz3ZMJYnPIjgVtqqub?= =?us-ascii?Q?lz4RRrdCsE4eWk4LQ5UHkvkwayNjMSc8WYnN++gH8ijqaQYVxKGOT9Rd73+M?= =?us-ascii?Q?pAK71n0EoIJYXSGboNBLHnTApvN/ZWhk2fv3zvWaedUsEvZkZIjyEVXqCU+g?= =?us-ascii?Q?P1i1pXanFAC0g+AoiQRJCJubM3puDzrdIE9IjNnpl8Gbu/KhUVOGzr5dXEBk?= =?us-ascii?Q?GFCQn8qStMtpfm3lYWfynW+xCxw+vQodNwAeSCH33qMlIoiLyjLbXy/gacud?= =?us-ascii?Q?wFP1czs6L4Hi0lHgrafpsL6XhmbAmKJDMIXAM6PEneihDmZ+L9iIwQS8JRFG?= =?us-ascii?Q?omb9h70neV+etVSFXEXqVigl/dvZfsXZSV0tGALdEthFvEKO0nyWyN6JPfWc?= =?us-ascii?Q?R3WJD6dEuwanNPkHz/U4y6q50H2suZnms4J/?= 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 Sep 2025 07:41:08.0581 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6a5c893c-84f4-4df4-9c91-08dde9f41475 X-MS-Exchange-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: BL02EPF00021F68.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8655 Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and INTEL_VMX on INTEL. This dependency was reflected using 'if' next to a prompt which is incorrect as it that deals only with the visibility of the given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX when INTEL is disabled (option is hidden). Fix it while keeping the possibility of e.g. enabling INTEL_VMX when INTEL is disabled. Fixes: e3ed540f2e9f ("x86/hvm: add HVM-specific Kconfig") Signed-off-by: Michal Orzel --- Changes in v2: - change default instead (Jan) --- xen/arch/x86/hvm/Kconfig | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig index b903764bda0d..5cb9f2904255 100644 --- a/xen/arch/x86/hvm/Kconfig +++ b/xen/arch/x86/hvm/Kconfig @@ -16,8 +16,8 @@ menuconfig HVM if HVM config AMD_SVM - bool "AMD-V" if AMD && EXPERT - default y + bool "AMD-V" if EXPERT + default AMD help Enables virtual machine extensions on platforms that implement the AMD Virtualization Technology (AMD-V). @@ -25,8 +25,8 @@ config AMD_SVM If in doubt, say Y. config INTEL_VMX - bool "Intel VT-x" if INTEL && EXPERT - default y + bool "Intel VT-x" if EXPERT + default INTEL select ARCH_VCPU_IOREQ_COMPLETION help Enables virtual machine extensions on platforms that implement the -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 07:53:10 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 07:53:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105771.1456608 (Exim 4.92) (envelope-from ) id 1utLpC-0004md-68; Tue, 02 Sep 2025 07:53:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105771.1456608; Tue, 02 Sep 2025 07: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 1utLpC-0004mW-3Y; Tue, 02 Sep 2025 07:53:06 +0000 Received: by outflank-mailman (input) for mailman id 1105771; Tue, 02 Sep 2025 07: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 1utLpA-0004mQ-MB for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 07:53:04 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20605.outbound.protection.outlook.com [2a01:111:f403:2413::605]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d9a5c65f-87d1-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 09:53:01 +0200 (CEST) Received: from CH2PR16CA0006.namprd16.prod.outlook.com (2603:10b6:610:50::16) by DS0PR12MB8219.namprd12.prod.outlook.com (2603:10b6:8:de::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 07:52:57 +0000 Received: from CH1PEPF0000A34B.namprd04.prod.outlook.com (2603:10b6:610:50:cafe::eb) by CH2PR16CA0006.outlook.office365.com (2603:10b6:610:50::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.16 via Frontend Transport; Tue, 2 Sep 2025 07:52:57 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CH1PEPF0000A34B.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.9094.14 via Frontend Transport; Tue, 2 Sep 2025 07:52:57 +0000 Received: from satlexmb08.amd.com (10.181.42.217) 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, 2 Sep 2025 02:52:56 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Tue, 2 Sep 2025 00:52:56 -0700 Received: from [10.252.147.171] (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, 2 Sep 2025 02:52: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: d9a5c65f-87d1-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CYuq3wZC+7Gh+Rbfe+Q+3nmkF1ijA3LvjA6buSig1yXm3A1KudYHFnHMKWqPp/YE8Plu4YS/4Ck1fWNQKVCxjfL94RXGuOZnrofnCbydBq9BSxxGZKSWo8rH8HS0QTDrwGd1ODrWZy6VkRM9jcMJ9LDc9OKls31dB9L291loKVW1LsLj7bD6YMfyHicM+rc9I0XipUUXlYEWmBPwpTkj8PXf2+w3bB4A2Z7NCtJblVTzvJJII1se1ma2Bj96ynvtKgr7l9UsHW5WIU8xMG8q81XZuLAK9WOTEimilbOPzxJedkGxF1QO0pUR1HnB34Mda9TKhDJDB+ZbJeqXdGFPSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OJkkMhGXzvEg6x4kLTMWfsdi7Qal39hBqTeP/nXE5rI=; b=p0QcZ0IBrHbPvaUjKiy0WEIOpeMPVEjTPeXUZwVuh0QjqCOQOnU07sN4XRpj4T0XjbzcNZe9zIFfm+rlK6at6mnXX2zVB3NdQIzve6G77ifOp4P7wUIGfM6iZng/SnolDHILtgEeX8gT0a6NIb+XMtCOALaEzWEsuxMMvy5PsgXeQJdHdo1hTBIB/ZI+Fn97mFrdHfTKHVVPBrCnWKi46qRn9zJ6qz96bZc9d/p5YTwESUxCilJCFFLbokkGv8FV3blDGH1vG/poFX+GU8zxHJSrglaobVCn1otrooUaXnmlyEz/I22M4fqca3+f18+15QRTxY0VNoM9B2TlD0qimA== 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=OJkkMhGXzvEg6x4kLTMWfsdi7Qal39hBqTeP/nXE5rI=; b=ldu2cFXN6hNGwmduiAelCNMK1GQs2X56wnw9q5mXFzblOiUno4vuG+zAS7dut99c/bsKijf7EsTxO9R/5W+jCBhJUz9C7m6toUYP8feQEtLqmWB+5PQhlOgho87+uMHqJJulpY55OkaCFD0+SBnHr8iUYgndFPOwlqwnmZx91iI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 2 Sep 2025 09:52:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs/sending-patches: document "Amends:" tag To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <92b2d76e-2434-4606-94b6-93774a74fc87@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <92b2d76e-2434-4606-94b6-93774a74fc87@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34B:EE_|DS0PR12MB8219:EE_ X-MS-Office365-Filtering-Correlation-Id: 8731cc21-a4e7-44ab-17d5-08dde9f5bb10 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?Z3RSYXFSWjNNZzJDZmFZRzE1Zmt2dk1KbHlTeTgvRFdNYThXOGp1YUpVY084?= =?utf-8?B?OHFzNDBseUY5ZHRFTDdnTUFoRWNmOE54MWkrdVRHdlo1MzBBaml0SzlKaVcv?= =?utf-8?B?Vk5xY2N0c1ZqWWI0dTZ4aEV2TEh5anNxd01PNSsvVVIrald2NWxoRW1PQnl0?= =?utf-8?B?SVFPdy9odjRmdllHdi9HS2JLY1pEbFdSaXduRjVYVWQxUWxQakV5TzIzVnB0?= =?utf-8?B?bzBEZ2FROVErRmJtaHU4Qk5XQVJOZzVja09LamJVeiszOVoxTW9QRmZIY01Q?= =?utf-8?B?bUZXNnc5ZHkyUlQ1dndpbCtMcHh5RG9Pb0VYenlhNnZyRTdCeG5Jb3JweFgw?= =?utf-8?B?dTFlazRXVXdPYS9yTVdnOWhOSFp6Y1JHWllmTXdQTDJhMjVyWTNjMERNWWhO?= =?utf-8?B?VnFuWWZ2emtLQVRNUzhIRnY4ZUorQzdsQ1hGSzcwelRCczg4K0s5OXZEblVP?= =?utf-8?B?dTJyQm9GbUUzalh1QXYxZHJNanFoQWxkYStycUJEdHI5ZlBoWWV4RXpjME5X?= =?utf-8?B?QUFraTJRemhNZ3lUbGlPSFdnWEV6Q3RNUEFaOEliL3dxaDVvZHNTOUQ4cER0?= =?utf-8?B?Rkk2QVVFYlpJZzd1SlkvbzBJdkx2Z0lZWHNEUndnM3hIck5oOVBNbXEyc0s5?= =?utf-8?B?eXp5VXpBckFFL2pjTUZRZnhnNnFXRnJKdmhpajVnYXpIdXVSOWF0ZUYvaGgv?= =?utf-8?B?TTJPUzNoMmlYT0FaT3RPcllHcS9qV3FqeDlWd2xsUjVuQWZyWURFVUNvVS8v?= =?utf-8?B?SGxWMXBXRWdZYkRhcytIQnhPSlN6d1RqVWVUMnlpWGtNcjMrV1Fta1dDLzJJ?= =?utf-8?B?NTZjTUxQRHBkTUVXbG1uOUZsaEU2K2lINVIzdFBTVmFNTlpqKzZIb2FLa3Fw?= =?utf-8?B?YVJTNDJUUXBGZzFQNlRsUzdUOWR1Q1VvZlFRNW1nYUk0TVdUZk1sZnp2TnFm?= =?utf-8?B?R1FOQy9pWnh2WDBFaWZjSkVWYlAyeEl1VUhnY3VvcCswdVI0K2hCdytXcFpH?= =?utf-8?B?WllNMXFKcENsclN6akl2Y2JyUlJ4V1pCQWVXQWpmQmQzSzFSa0tnSG5GQUVz?= =?utf-8?B?bThqR2R3OVFUK3phdWJpMUx1M1puTjVyU244NDV0dDVaeUJvdmdRbjJTSFMz?= =?utf-8?B?V2FORXAvQnNZdi9rSmtuQlE1bERnTjRpMklyWDVDcFJpMmpvZktBajk3dHlE?= =?utf-8?B?R0gzU0dRbk93bDNYMFpxY015c0JwY2daWVpTTDBUQ0YvWlpMUU9sNW1XOXNB?= =?utf-8?B?TmR6S1hXTXhaSGxrNThwanZzRTBWaklvZTRRSlRLWHg3bGhpa2VyT2s0WXBs?= =?utf-8?B?dmUxcnF0STNkeUIrOHVpYVpZcUc3WE81eG56NWRhekVvdVBiUnU1bVFHSlFh?= =?utf-8?B?MlVhRDRYcnFyRUNxbi9SUi9CNEdaNXp6ODZZZXduNUF6bFZyaCtOVTg3NkxW?= =?utf-8?B?dlBvaGY3SUVsd1ZNaUZyQ200YWVmMTVDU1d2bDRxc1RZSzVxbnJ2RVlRZHZq?= =?utf-8?B?VEt0OHA1YnF1Rm1venhUaDFGYU5VVlFGQ0VTMzBmL000cEtSQ2FhMHkrenZr?= =?utf-8?B?MU5ROXFrbWRKWHNJV1lrZzBOOStKUTlQWUlzVXhsNlVqM0ZXNERxWFFMZlM3?= =?utf-8?B?aXBFSHpVYW9wdXdENkFuNkM0N3gzNjB5TUFINzJBL0Rob0YwaGlxUERRM2R3?= =?utf-8?B?UWdGU2xxK21jVnBudS8vcnJ5cmhLNkk2a2VyYjZwK0R5VTBLTm50QVYrSWJ1?= =?utf-8?B?Q0Z5aUtqK0R6K003OEY5ak1SNnB6dEN3YWdubTFheklKZEsyZXZsTWtpbWdp?= =?utf-8?B?VVJHWVM4ZHJSYTNQM1dMTDV3c0xGN2FtRFphWEpxOHhPV0ZtcUFaMDg1WjJQ?= =?utf-8?B?ODZESDduV3N6WllFdGFoenpBc25sb2M2Mm4rc3p6ZkY2R0NPWENDandXNnhC?= =?utf-8?B?b2dyTzZJL21CbHB5VStXL3o4T3FWaTBUeDVZa29rVklqU240eU5PYjR4bVZ1?= =?utf-8?B?U3ZHRFBPTXhQZStyY0lzVC81R0xOZko2NXgxTU5OdzRRWFhlZmtsem1Gdisv?= =?utf-8?Q?M02sks?= 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: 02 Sep 2025 07:52:57.0580 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8731cc21-a4e7-44ab-17d5-08dde9f5bb10 X-MS-Exchange-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: CH1PEPF0000A34B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8219 On 01/09/2025 11:00, Jan Beulich wrote: > On rare occasions Fixes: isn't quite appropriate to use, yet another > commit still wants making a connection to in a formalized way. Such could > e.g. happen if a pretty obvious optimization was left out (which isn't a > bug, but still a shortcoming). Formalize Amends: as a tage to use in such > a situation. > > Requested-by: Roger Pau Monné > Signed-off-by: Jan Beulich LGTM. Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 02 08:08:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 08:08:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105783.1456619 (Exim 4.92) (envelope-from ) id 1utM45-00075M-Hd; Tue, 02 Sep 2025 08:08:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105783.1456619; Tue, 02 Sep 2025 08:08: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 1utM45-00075F-Ei; Tue, 02 Sep 2025 08:08:29 +0000 Received: by outflank-mailman (input) for mailman id 1105783; Tue, 02 Sep 2025 08:08: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 1utM44-000759-EV for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 08:08: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 00e94b85-87d4-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 10:08:26 +0200 (CEST) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-55f646b1db8so4761359e87.0 for ; Tue, 02 Sep 2025 01:08:26 -0700 (PDT) Received: from [192.168.0.110] ([91.123.151.69]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-337f4c4ffd5sm2994461fa.14.2025.09.02.01.08.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 01:08: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: 00e94b85-87d4-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756800506; x=1757405306; 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=hNbUaKmMtwfR4+vc8Vw/zAOCPP39b/gYocjOV+di+aI=; b=go7/v9g8uqjeM/IXX/waybFWhtKh/R1+JTwt+Kgoqp+GO2Z+fCeLBYHBh3F0aTc5HG P8hvtIQtKTO4tIvz0umoFGK3rftB1pbpk0WUsXvwRaNG6jLj3ISyt8ZcQrmXajbefOB6 dDekj+S0k8kCKO1NAKDdWpAn3NtWUs0ckfG6ZTAhM8iDCVArbYUa/qGreyklIu6rlEj0 bUc8Y+3DJYQLdwMFbLaZlDiAcBuSy3CYRHpp9uSa4eoA1YdC0AJpQ/carwAo0PSWMmXD 66muj3xZZCtdbKpwT4M9pO5vVCZnjYTTdG9ik11KiKhdJt0pGlPwlcogmBPM1yQ4oUHQ B3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756800506; x=1757405306; 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=hNbUaKmMtwfR4+vc8Vw/zAOCPP39b/gYocjOV+di+aI=; b=wsoknXvGDtCUkHgWXei+ere6CXjEwHIc/QK+aV4eQ/wnjS+BNEMk0IDd7+j7ujO0MG TxNTvq4l8nNnb9hmz0eZ8uSon+XQeoheTJVAa7iGzVfEY7yjuqkOLeRM4CoZET+T5QTH tyXdORpD3SUAeGarTPeIcvnAo/6JN/1r2gm/M/40bc+Lr93vPGF4gkWTvebQUmwjOmZ6 hE7BzXNseTIm4+6MtQk4M63YkaKxC5IjC++c2LAo1PKGaFujycGS+rLZqT/kIsrqPswn zhKsM0rPUPC4U1losTAVNBVki+DmdxHasdzrplSOISUI3LijGuDZpYKlczLFAySNI6Yz fzFg== X-Forwarded-Encrypted: i=1; AJvYcCVReXaINTpLwUhbF+TXS7RSSQPxJY1C9StlVF1ix7LOdOkrLra0XviAjRCiwmT0x7KZwsl053JRYfQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwcjlrgK6VsP0BpRlIGEjHGS67N0PExv6HHjbhVvrD1s4J8pe5R Y2jzTAZTbMmXtNzlhgfn28d1DpqyhN+Fh4dmPmBSv+WNfaCufCu60XOV X-Gm-Gg: ASbGnctG4eiyg6MUXKOb2FrjBmulbb8jYdhoDPlv9xYNFt0NYOQMK919tEbwxIWwgkT YOIVzOldoy92v1dvbwGtwYZnxy3vwEeYFbiwlKeaV08jWUfOLyjseqmEqbFZ4SGD1hvtIBCWlvT P4gkT4q1QJXWo58NRsgz5pVQD17ct576qSu4AxyIPUUUeC2Yk0Ad0eZpJbjaRqRsbDVksShtDcd Ldo0/XcFlOxlsBwjUZmpnsjo34IblpS3opsrSCR/vwLRcadpu1OB1CZdSbpTnga8cQ7f5UAi0ev gOYEW89Py01vWS+xJfjO1oj4/HN5s9js1nQWKzVghOrZ+vQP2KDgiR80RFI5yVXQL7fXADwQAT1 UIVHZNpMNb0EIjgvx8PojJEsW4K+YnVOQZLUozO+Y0QPZyi4= X-Google-Smtp-Source: AGHT+IHyi/uvGmhk3aM7k9lfiHFuzlMMVBXQEVcrisJrW1P2Z+bKg5XkomkmFfIoHaVIJMhUmFfTcg== X-Received: by 2002:a05:6512:1357:b0:55f:6a38:f6c8 with SMTP id 2adb3069b0e04-55f708a2c55mr3000353e87.4.1756800505649; Tue, 02 Sep 2025 01:08:25 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 11:08:24 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/public: arch-arm: Drop XEN_DMOP_get_ioreq_server_info from supported To: "Orzel, Michal" , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Oleksandr Tyshchenko , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20250901125837.1271101-1-oleksandr_tyshchenko@epam.com> <5d670f97-5e04-45b8-b9ad-81e42706bc47@amd.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <5d670f97-5e04-45b8-b9ad-81e42706bc47@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.09.25 10:27, Orzel, Michal wrote: Hello Michal > > > On 01/09/2025 14:58, Oleksandr Tyshchenko wrote: >> The said sub-op is not supported on Arm64, since it: >> - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn >> cannot be returned), please refer to ioreq_server_create() >> - does not support "legacy" mechanism of mapping IOREQ Server >> magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please >> refer to arch_ioreq_server_map_pages(). On Arm64, only the Acquire >> Resource infrastructure is used to query and map the IOREQ Server pages. > These points are valid. However, I don't understand why you mention Arm64 only. > What about Arm32? It's the same here.> I will s/Arm64/Arm >> Signed-off-by: Oleksandr Tyshchenko >> --- >> xen/include/public/arch-arm.h | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h >> index e2412a1747..023cc2f468 100644 >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >> @@ -130,7 +130,6 @@ >> * HYPERVISOR_dm_op >> * Exactly these sub-operations are supported: >> * * XEN_DMOP_create_ioreq_server >> - * * XEN_DMOP_get_ioreq_server_info >> * * XEN_DMOP_map_io_range_to_ioreq_server >> * * XEN_DMOP_unmap_io_range_from_ioreq_server >> * * XEN_DMOP_set_ioreq_server_state > This list is kept in sync with the op_size array in xen/arch/arm/dm.c. > I think we should drop this op from there, not only from the comment listing > supported ops. I think you are right, will do > > ~Michal > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 08:17:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 08:17:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105794.1456629 (Exim 4.92) (envelope-from ) id 1utMCD-0000Ny-Ag; Tue, 02 Sep 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 1105794.1456629; Tue, 02 Sep 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 1utMCD-0000Nr-7j; Tue, 02 Sep 2025 08:16:53 +0000 Received: by outflank-mailman (input) for mailman id 1105794; Tue, 02 Sep 2025 08:16: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 1utMCB-0000Nl-EM for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 08:16:51 +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 2d1f2ab2-87d5-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 10:16:50 +0200 (CEST) Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-336af6356a5so33544681fa.3 for ; Tue, 02 Sep 2025 01:16:50 -0700 (PDT) Received: from [192.168.0.110] ([91.123.151.69]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-337f5032caasm3127831fa.35.2025.09.02.01.16.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 01:16: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: 2d1f2ab2-87d5-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756801010; x=1757405810; 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=wLY1d8KA4KLUy6FG3YkFSgHCh3n7IxayQ3VVQNip50o=; b=BuTkZXp3zsM97AEjwBGgfOpDNm9JPK8y/2vMm04a8NpA5wupiqC3OE5uDlWjhE3piY YIOpR0yCa3FYE7Lw9ZcZrKvd0d5aY5SPZgpgyLadWOhJPUVurlyV4CFbIcBdkhXubPgb 1VL4YHNMUCSZmuh76VyayH3rdr1CMh4DtOWaKyu3gWOsRaPqn0Wfa7z8qdy8OB5dnTJy i9fl3KjQTZv9f0oQBgI75KyIwdqNXEChUmRiykCF4USDLHwVGjNnNhWVm7zZ5fx2F56X mdqttGi1aMXh7EKgV0it7BL161cKY3zktdqIkQ3tfOsbaZONXrqzkg6N35Ul0iE7rWpG teyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756801010; x=1757405810; 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=wLY1d8KA4KLUy6FG3YkFSgHCh3n7IxayQ3VVQNip50o=; b=O6Wk386Z4+nGvXjPtC4H0jMcnTkNpExNccqPo/71J984AzrFCcsb93VFI88waMagKv Xd1ke26tuyhRUm9Cc1xoOtIE/mt8yEEFNpXq7KfmIudduSIc8y8Ozfpjcg01M/y58NGT SPj1Rilgw2QJVyCIYxmQQBPKeecMwaSb8OQKfY6YRgTzVOjskqPqw1BO4zx1OcFdTltX fyfthmR0I1XTH5s1pSuQ8ODh7iFMAV1Aew1zi+BLWAJoveWfmH+WXOtWIcxkOwolLsh2 BDhcH8c6OFwmXybdOyTD32FxWNEXmoVHIXvp6Geh0viLKKr36sj0q+Um5VPdO6bIZhH+ 27dw== X-Gm-Message-State: AOJu0YzY5oIQ7AvJwbFACuuWCfYMNHW3El02+LM4326RtSh7SHcMqlfo dRCCNLMtHB6sBMcAf6qYkNeD4Mc/8aqQjtu7nILI1XiK4OoScFsk7U3B X-Gm-Gg: ASbGncv4i8/ZsQ1N99Ttf8XmylPJf6ohD5+D1hKECKalQtQImlbKdPcUtiTvqqwKKG6 f3wimQUygDhvjikYxIpNQe+O8PnX/fI77VKECzrTAO7EhDhxE0uP5Zp0FuEng+hkon6hNQw2ezJ 3xeHuQrZdSfornaqLv10TuMcVmf+kstNPYx2z+4JFauE1VhMPrIZYkJW00+CnM7iCPQReYxoo+j Ye2VlJkGGNoqLXCubwpYX+qNh0292+1gmCXA1zvVED47j/VqIgfrKz/mQDNCWTv9ywUJLsBNBwF v5zOwfrSNMSQuz7pC8+pJIyr6YNwamDSWckWXP+/KXQL8NJHuEzYnaq+CYNhLL8U/9zDF3dp7bb ZIeZGSoW+HYDTonY1ET/T/h1VdA== X-Google-Smtp-Source: AGHT+IEQHcZH6lTyvrBcZ45nn6xjQyHDPc+u1M8NCYQ4VmJ3xkt5+1JtJNwRvA+shTlyU1ZXOMWFmw== X-Received: by 2002:a2e:a488:0:b0:32a:8bf4:3a81 with SMTP id 38308e7fff4ca-336ca9f4b3fmr22850551fa.5.1756801009346; Tue, 02 Sep 2025 01:16:49 -0700 (PDT) Message-ID: <1aad2e68-04f2-4a71-8a21-8ee5360a7062@gmail.com> Date: Tue, 2 Sep 2025 11:16:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs To: Leonid Komarianskyi Cc: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel References: <4b13dea924eabf1370d3f31030f3eef48371de06.1756481577.git.leonid_komarianskyi@epam.com> <87y0r1x3g2.fsf@epam.com> <0e9e5b72-2bf1-46a8-867d-8e6d306fe956@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <0e9e5b72-2bf1-46a8-867d-8e6d306fe956@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 01.09.25 21:00, Leonid Komarianskyi wrote: > Hello Oleksandr, Hello Leonid > > Thank you for your review. > > On 31.08.25 18:58, Oleksandr Tyshchenko wrote: >> >> >> On 29.08.25 23:45, Volodymyr Babchuk wrote: >> >> Hello Leonid, Volodymyr >> >>> >>> Hi Leonid, >>> >>> Leonid Komarianskyi writes: >>> >>>> This change introduces resource management in the VGIC to handle >>>> extended SPIs introduced in GICv3.1. The pending_irqs and >>>> allocated_irqs arrays are resized to support the required >>>> number of eSPIs, based on what is supported by the hardware and >>>> requested by the guest. A new field, ext_shared_irqs, is added >>>> to the VGIC structure to store information about eSPIs, similar >>>> to how shared_irqs is used for regular SPIs. >>>> >>>> Since the eSPI range starts at INTID 4096 and INTIDs between 1025 >>>> and 4095 are reserved, helper macros are introduced to simplify the >>>> transformation of indices and to enable easier access to eSPI-specific >>>> resources. These changes prepare the VGIC for processing eSPIs as >>>> required by future functionality. >>>> >>>> The initialization and deinitialization paths for vgic have been updated >>>> to allocate and free these resources appropriately. Additionally, >>>> updated handling of INTIDs greater than 1024, passed from the toolstack >>>> during domain creation, and verification logic ensures only valid SPI or >>>> eSPI INTIDs are used. >>>> >>>> The existing SPI behavior remains unaffected when guests do not request >>>> eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI >>>> option is disabled. >>>> >>>> Signed-off-by: Leonid Komarianskyi >>>> >>>> --- >>>> Changes in V5: >>>> - removed the has_espi field because it can be determined by checking >>>>    whether domain->arch.vgic.nr_espis is zero or not >>>> - since vgic_ext_rank_offset is not used in this patch, it has been >>>>    moved to the appropriate patch in the patch series, which implements >>>>    vgic eSPI registers emulation and requires this function >>>> - removed ifdefs for eSPI-specific macros to reduce the number of ifdefs >>>>    and code duplication in further changes >>>> - fixed minor nit: used %pd for printing domain with its ID >> >> @Leonid, thanks for optimizing the series, now it looks much better (the >> number of #ifdef-s is reduced, code is reused). >> >> > > I am doing my best, and you and the other reviewers are helping me > improve the code. Thank you for that! > >>>> >>>> Changes in V4: >>>> - added has_espi field to simplify determining whether a domain is able >>>>    to operate with eSPI >>>> - fixed formatting issues and misspellings >>>> >>>> Changes in V3: >>>> - fixed formatting for lines with more than 80 symbols >>>> - introduced helper functions to be able to use stubs in case of >>>>    CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of >>>>    #ifdefs >>>> - fixed checks for nr_spis in domain_vgic_init >>>> - updated comment about nr_spis adjustments with dom0less mention >>>> - moved comment with additional explanations before checks >>>> - used unsigned int for indexes since they cannot be negative >>>> - removed unnecessary parentheses >>>> - move vgic_ext_rank_offset to the below ifdef guard, to reduce the >>>>    number of ifdefs >>>> >>>> Changes in V2: >>>> - change is_espi_rank to is_valid_espi_rank to verify whether the array >>>>    element ext_shared_irqs exists. The previous version, is_espi_rank, >>>>    only checked if the rank index was less than the maximum possible >>>> eSPI >>>>    rank index, but this could potentially result in accessing a >>>>    non-existing array element. To address this, is_valid_espi_rank was >>>>    introduced, which ensures that the required eSPI rank exists >>>> - move gic_number_espis to >>>>    xen/arm: gicv3: implement handling of GICv3.1 eSPI >>>> - update vgic_is_valid_irq checks to allow operating with eSPIs >>>> - remove redundant newline in vgic_allocate_virq >>>> --- >>>>   xen/arch/arm/include/asm/vgic.h |  12 ++ >>>>   xen/arch/arm/vgic.c             | 199 +++++++++++++++++++++++++++++++- >>>>   2 files changed, 208 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/ >>>> asm/vgic.h >>>> index 3e7cbbb196..912d5b7694 100644 >>>> --- a/xen/arch/arm/include/asm/vgic.h >>>> +++ b/xen/arch/arm/include/asm/vgic.h >>>> @@ -146,6 +146,10 @@ struct vgic_dist { >>>>       int nr_spis; /* Number of SPIs */ >>>>       unsigned long *allocated_irqs; /* bitmap of IRQs allocated */ >>>>       struct vgic_irq_rank *shared_irqs; >>>> +#ifdef CONFIG_GICV3_ESPI >>>> +    struct vgic_irq_rank *ext_shared_irqs; >>>> +    int nr_espis; /* Number of extended SPIs */ >> >> It seems you have agreed (V4) that nr_espis could not be negative. >> > > I appologize for that, I missed this change. I will fix it in V6. everything is fine, no need to apologize > >>>> +#endif >>>>       /* >>>>        * SPIs are domain global, SGIs and PPIs are per-VCPU and >>>> stored in >>>>        * struct arch_vcpu. >>>> @@ -243,6 +247,14 @@ struct vgic_ops { >>>>   /* Number of ranks of interrupt registers for a domain */ >>>>   #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32) >>>> +#ifdef CONFIG_GICV3_ESPI >>>> +#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis+31)/32) >>>> +#endif >>>> +#define EXT_RANK_MIN (ESPI_BASE_INTID/32) >>>> +#define EXT_RANK_MAX ((ESPI_MAX_INTID+31)/32) >>>> +#define EXT_RANK_NUM2IDX(num) ((num)-EXT_RANK_MIN) >>>> +#define EXT_RANK_IDX2NUM(idx) ((idx)+EXT_RANK_MIN) >>>> + >>>>   #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock) >>>>   #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock) >>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c >>>> index 2bbf4d99aa..c9b9528c66 100644 >>>> --- a/xen/arch/arm/vgic.c >>>> +++ b/xen/arch/arm/vgic.c >>>> @@ -27,9 +27,82 @@ >>>>   bool vgic_is_valid_line(struct domain *d, unsigned int virq) >>>>   { >>>> +#ifdef CONFIG_GICV3_ESPI >>>> +    if ( virq >= ESPI_BASE_INTID && >>>> +         virq < ESPI_IDX2INTID(d->arch.vgic.nr_espis) ) >>>> +        return true; >>>> +#endif >>>> + >>>>       return virq < vgic_num_irqs(d); >>>>   } >>>> +#ifdef CONFIG_GICV3_ESPI >>>> +/* >>>> + * Since eSPI indexes start from 4096 and numbers from 1024 to >>>> + * 4095 are forbidden, we need to check both lower and upper >>>> + * limits for ranks. >>>> + */ >>>> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int >>>> rank) >>>> +{ >>>> +    return rank >= EXT_RANK_MIN && >>>> +           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d); >>>> +} >>>> + >>>> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, >>>> +                                                       unsigned int >>>> rank) >>>> +{ >>>> +    return &v->domain- >>>>> arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]; >>>> +} >>>> + >>>> +static inline bool vgic_reserve_espi_virq(struct domain *d, unsigned >>>> int virq) >>>> +{ >>>> +    return !test_and_set_bit(ESPI_INTID2IDX(virq) + vgic_num_irqs(d), >>>> +                             d->arch.vgic.allocated_irqs); >>>> +} >>>> + >>>> +static void arch_move_espis(struct vcpu *v) >>> >>> I don't need you need a copy of arch_move_irqs(). Se below for more info. >>> >>>> +{ >>>> +    const cpumask_t *cpu_mask = cpumask_of(v->processor); >>>> +    struct domain *d = v->domain; >>>> +    struct pending_irq *p; >>>> +    struct vcpu *v_target; >>>> +    unsigned int i; >>>> + >>>> +    for ( i = ESPI_BASE_INTID; >>>> +          i < EXT_RANK_IDX2NUM(d->arch.vgic.nr_espis); i++ ) >>>> +    { >>>> +        v_target = vgic_get_target_vcpu(v, i); >>>> +        p = irq_to_pending(v_target, i); >>>> + >>>> +        if ( v_target == v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p- >>>>> status) ) >>>> +            irq_set_affinity(p->desc, cpu_mask); >>>> +    } >>>> +} >>>> +#else >>>> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int >>>> rank) >>>> +{ >>>> +    return false; >>>> +} >>>> + >>>> +/* >>>> + * This function is stub and will not be called if CONFIG_GICV3_ESPI=n, >>>> + * because in this case, is_valid_espi_rank will always return false. >>>> + */ >>>> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, >>>> +                                                       unsigned int >>>> rank) >>>> +{ >>>> +    ASSERT_UNREACHABLE(); >>>> +    return NULL; >>>> +} >>>> + >>>> +static inline bool vgic_reserve_espi_virq(struct domain *d, unsigned >>>> int virq) >>>> +{ >>>> +    return false; >>>> +} >>>> + >>>> +static void arch_move_espis(struct vcpu *v) { } >>>> +#endif >>>> + >>>>   static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, >>>>                                                     unsigned int rank) >>>>   { >>>> @@ -37,6 +110,8 @@ static inline struct vgic_irq_rank >>>> *vgic_get_rank(struct vcpu *v, >>>>           return v->arch.vgic.private_irqs; >>>>       else if ( rank <= DOMAIN_NR_RANKS(v->domain) ) >>>>           return &v->domain->arch.vgic.shared_irqs[rank - 1]; >>>> +    else if ( is_valid_espi_rank(v->domain, rank) ) >>>> +        return vgic_get_espi_rank(v, rank); >>>>       else >>>>           return NULL; >>>>   } >>>> @@ -117,6 +192,62 @@ int domain_vgic_register(struct domain *d, >>>> unsigned int *mmio_count) >>>>       return 0; >>>>   } >>>> +#ifdef CONFIG_GICV3_ESPI >>>> +static unsigned int vgic_num_spi_lines(struct domain *d) >>>> +{ >>>> +    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis; >>>> +} >>>> + >>>> +static int init_vgic_espi(struct domain *d) >>>> +{ >>>> +    unsigned int i, idx; >>>> + >>>> +    if ( d->arch.vgic.nr_espis == 0 ) >>>> +        return 0; >>>> + >>>> +    d->arch.vgic.ext_shared_irqs = >>>> +        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d)); >>>> +    if ( d->arch.vgic.ext_shared_irqs == NULL ) >>>> +        return -ENOMEM; >>>> + >>>> +    for ( i = d->arch.vgic.nr_spis, idx = 0; >>>> +          i < vgic_num_spi_lines(d); i++, idx++ ) >>>> +        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i], >>>> +                              ESPI_IDX2INTID(idx)); >>>> + >>>> +    for ( i = 0; i < DOMAIN_NR_EXT_RANKS(d); i++ ) >>>> +        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i], i, 0); >>>> + >>>> +    return 0; >>>> +} >>>> + >>>> +struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) >>> >>> I know that I should made this observation in previous version, but I >>> didn't, sorry for that. Anyways, I don't think that this is a good idea >>> to introduce this function and vgic_reserve_espi_virq(), as well as >>> arch_move_espis(), actually, because in each case this is a code >>> duplication, which is not good. >>> >>> I think that instead you need to introduce a pair of helpers that will >>> map any (e)SPI number to pending_irq[]/allocate_irqs index and back. >>> >>> somethink like >>> >>> static inline unsigned virq_to_index(int virq) >>> { >>>     if (is_espi(virq)) >>>         return ESPI_INTID2IDX(irq) + d->arch.vgic.nr_spis; >>>     return virq; >>> } >>> >>> See below for examples. >>> >>>> +{ >>>> +    irq = ESPI_INTID2IDX(irq) + d->arch.vgic.nr_spis; >>>> +    return &d->arch.vgic.pending_irqs[irq]; >>>> +} >>>> +#else >>>> +static unsigned int init_vgic_espi(struct domain *d) >>>> +{ >>>> +    return 0; >>>> +} >>>> + >>>> +static unsigned int vgic_num_spi_lines(struct domain *d) >>>> +{ >>>> +    return d->arch.vgic.nr_spis; >>>> +} >>>> + >>>> +struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) >>>> +{ >>>> +    return NULL; >>>> +} >>>> +#endif >>>> + >>>> +static unsigned int vgic_num_alloc_irqs(struct domain *d) >>>> +{ >>>> +    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS; >>>> +} >> >> I do not know where it would be better to put a comment related to non- >> visible in the patch context route_irq_to_guest(), but put it here. >> >> I am afraid, the vgic_num_irqs(d) printed in the following error message >> is not entirely correct with your changes: >> >> route_irq_to_guest(): >> >> ... >> >>     if ( !vgic_is_valid_line(d, virq) ) >>     { >>         printk(XENLOG_G_ERR >>                "the vIRQ number %u is too high for domain %u (max = >> %u)\n", >>                irq, d->domain_id, vgic_num_irqs(d)); >>         return -EINVAL; >>     } >> >> > > Would it be okay to change the error message to something like: > "invalid vIRQ number %u for domain %pd\n" > > I understand that it is a more generic error message, but I think it > might become overly complicated if I add more information stating that > the IRQ should be within the range 0...vgic_num_irqs(d) or > 4096...ESPI_IDX2INTID(d->arch.vgic.nr_espis). > I see, so it would not be precise to just let's say print vgic_num_irqs(d) or ESPI_IDX2INTID(d->arch.vgic.nr_espis) as "(max = %u)" since the vIRQ range is not contiguous. Well, removing extra information (max) that could help the user to figure out what was wrong is not ideal, but if you think it would overcomplicate things, then I (not a maintainer of this code) would be okay with the proposed simplified error message. From xen-devel-bounces@lists.xenproject.org Tue Sep 02 08:42:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 08:42:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105811.1456639 (Exim 4.92) (envelope-from ) id 1utMav-0004XJ-6R; Tue, 02 Sep 2025 08:42:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105811.1456639; Tue, 02 Sep 2025 08:42: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 1utMav-0004XC-3Z; Tue, 02 Sep 2025 08:42:25 +0000 Received: by outflank-mailman (input) for mailman id 1105811; Tue, 02 Sep 2025 08:42: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 1utMat-0004X4-HE for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 08:42:23 +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 be6b6dc5-87d8-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 10:42:22 +0200 (CEST) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-55f7ab2a84eso1907197e87.1 for ; Tue, 02 Sep 2025 01: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: be6b6dc5-87d8-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756802542; x=1757407342; 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=Qg9WP+fM1lar770abagnLMdH/kaSBMg/qmi/2PLdEN8=; b=gWRDIl7GPm1CZaonIuryyVhsrBqhBMiDySMwUwPYktwuifpnOzBXadZ5aUodEiEjJ4 0Q7XcyWh5Ds4l/MauH0fAWN6P/3WA//YVx4iNRjwath6WWyVWYxcsBHI6+i+cEnjAITv /cRxcfql79F9nDujOqJdOIvZzW84tozJpv+8n+8+hKfbJDNyzrHRzZin3fUwJcGOZr5B byd+0KxChJ8sf9T34FVhIMZ01IcARbxM5qawo71e1hUhMCbt9Fu5cyQ1DsXfv9vC4aoK FPpQATy7Rk4fbQKWq9GZY19YzV11UpMvPbNEXS45ZbGqYo41mnb7XfnjkFTL0HQGeizm tmUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756802542; x=1757407342; 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=Qg9WP+fM1lar770abagnLMdH/kaSBMg/qmi/2PLdEN8=; b=YBVao1eZdRw0ezzcFbFt+WY3Ty2tjG4AAuK1tb53QzUnfjOniP7aFiQ8GXLdS/lUYf gryW9OXDlP4ec5krwduBqWfrdz/VuavCyf2p7FXJgYWefD4DMqHQcRSVlzpVR/d2Z2Qd REqda6jxWoirfnh+0GtIBIACys9SVC9o2yMC7mJqv3M7q91rV3vT63MikL6bwS6UbLc3 HeNzfiltGjCvUsXlcYxLkQUtqEYg/L8HyoKt29R65zGXJq1jhVVjkccIZ0tu7VtGJ/7E pkQShGT3dw3AQa/53ff3wzjp7YP895BLzuoocmolI1o2v9vOXHLub93OSsm5QXTCDWlp ztjw== X-Forwarded-Encrypted: i=1; AJvYcCVPUuCgrEOVr+OtjClZwTiGRSu/MEJYq/A7azDzk15hXLkOgMh1iXjbc5K68VF19wKHlk4fUop8lY4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy7PD6YJ48A9fMAzWdzlpo0WyON+TOpFRVFNo4yg5dOGXQ59Vd2 bXqWjBOXJDGs6AIbMuFamMx70XQho+j0jWKly/DTgLS7gbXswAdYQWyZTZdLQ0Qnf83J7x+LoF1 81div7OCGjkVlw9wedtyFFngk21z+wXI= X-Gm-Gg: ASbGncs5bN6ESUU+uwxFNpZOY9xNBQfDj4+HOsz+j4ZJjA6lXjY66ydIxyd92HMsV+r dXXM1lJ4Wom/cTs44We2G5yNaINKMbanfW2qz0WM6FNrTLRDDPdrpes71NkN4Pm7UDM2Qzw2fck ZENI1a1Gs2cORrwja1AEDeZzDb8C60Skqw5/6SL34eSMTqk+cqRUAB7/iXM0Fj6U7mLptlNqGJq +z/fn3E6YuNZZ7v X-Google-Smtp-Source: AGHT+IH/8lI0ropq8hF8ALw0uZ4FMop5nU5b+/jnhramUtA+Zz62gS9bcB3qR+yk7106SGYfrvXEOUInNXUr19eknVk= X-Received: by 2002:a05:6512:689:b0:55b:574c:6bf9 with SMTP id 2adb3069b0e04-55f708ec420mr3351379e87.29.1756802541507; Tue, 02 Sep 2025 01:42:21 -0700 (PDT) MIME-Version: 1.0 References: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@suse.com> In-Reply-To: From: Mykola Kvach Date: Tue, 2 Sep 2025 11:42:10 +0300 X-Gm-Features: Ac12FXx1gcMZiKd4rQYg1f3QaZNUn-jPMNNGUUVL45rumnZsXBOzaRLqbZb64q4 Message-ID: Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Jan Beulich Cc: Mykola Kvach , 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 On Tue, Sep 2, 2025 at 10:13=E2=80=AFAM Jan Beulich wro= te: > > On 01.09.2025 19:17, Mykola Kvach wrote: > > On Mon, Sep 1, 2025 at 8:02=E2=80=AFPM Mykola Kvach wrote: > >> On Mon, Sep 1, 2025 at 5:29=E2=80=AFPM Jan Beulich = wrote: > >>> On 31.08.2025 00:10, Mykola Kvach wrote: > >>>> --- a/xen/arch/ppc/stubs.c > >>>> +++ b/xen/arch/ppc/stubs.c > >>>> @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domai= n *d) > >>>> BUG_ON("unimplemented"); > >>>> } > >>>> > >>>> +int arch_domain_resume(struct domain *d) > >>>> +{ > >>>> + return 0; > >>>> +} > >>>> + > >>>> int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > >>>> { > >>>> BUG_ON("unimplemented"); > >>>> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > >>>> index 1a8c86cd8d..52532ae14d 100644 > >>>> --- a/xen/arch/riscv/stubs.c > >>>> +++ b/xen/arch/riscv/stubs.c > >>>> @@ -198,6 +198,11 @@ void arch_domain_creation_finished(struct domai= n *d) > >>>> BUG_ON("unimplemented"); > >>>> } > >>>> > >>>> +int arch_domain_resume(struct domain *d) > >>>> +{ > >>>> + return 0; > >>>> +} > >>>> + > >>>> int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c) > >>>> { > >>>> BUG_ON("unimplemented"); > >>>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > >>>> index 19fd86ce88..94a06bc697 100644 > >>>> --- a/xen/arch/x86/domain.c > >>>> +++ b/xen/arch/x86/domain.c > >>>> @@ -1138,6 +1138,11 @@ void arch_domain_creation_finished(struct dom= ain *d) > >>>> hvm_domain_creation_finished(d); > >>>> } > >>>> > >>>> +int arch_domain_resume(struct domain *d) > >>>> +{ > >>>> + return 0; > >>>> +} > >>>> + > >>>> #ifdef CONFIG_COMPAT > >>>> #define xen_vcpu_guest_context vcpu_guest_context > >>>> #define fpu_ctxt fpu_ctxt.x > >>> > >>> I definitely don't like this redundancy, and even less so that you in= troduce out- > >>> of-line calls. > >> > >> Thank you for your feedback. > >> I followed the existing pattern used in other architecture stubs. > > > > ... while I understand your concern about redundancy and out-of-line > > calls, I would appreciate more specific technical reasoning for why > > this approach is undesirable. > > Out of line functions, even if as simple as the example above, have a > code size and performance effect; effectively empty inline functions > can typically be eliminated altogether by the compiler, including the > checking of their "return" values. While the impact may be low, any > such instance can later be used as motivation / justification to > introduce further instances (much like you did in to your earlier > reply, still in context above). And the sum of them then may not be > "low impact" anymore. Thank you for your detailed explanation. As I mentioned earlier, I understand why it=E2=80=99s preferable to avoid out-of-line implementatio= ns, and I appreciate your technical reasoning... > > Furthermore we're already moving towards wider use of has_include(). > > > Code review is most effective when it is based on objective criteria > > and project guidelines, rather than personal preferences. > > And what did you derive from that my comment was purely based on a > personal preference? Plus even if it were (often I would indicate so), > that's imo still okay, as in many case maintainer preferences also > matter (e.g. if only for a more consistent overall code base). > > > This helps contributors understand the rationale and make improvements > > that benefit the whole project. > > While content-wise I agree, considering the amount of work I put into > doing reviews, I still view this sort of "education" as pretty close > to an offense. Plus did you consider how well it would scale if in > every review all sorts of extra justification would need giving? I > don't really like to put things this way, but I would really recommend > you first start doing perhaps dozens of reviews a week before judging > on whether any particular review gave you enough background info. ... I want to emphasize that I respect your work and the significant effort you put into reviews. My intention is not to question your expertise, but to highlight the importance of consistency for contributors. Since the current codebase already uses this approach in multiple places, contributors may get mixed signals when similar patterns are sometimes accepted and sometimes discouraged. Clearer project-wide guidance, or even small clarifications in coding style, would make it easier for contributors to align with maintainers=E2=80=99 expectations. I will adjust my patch accordingly and use has_include as you suggested. Thanks again for your guidance and for the effort you put into reviews. > > Jan Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 08:51:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 08:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105822.1456649 (Exim 4.92) (envelope-from ) id 1utMjT-0006G0-0N; Tue, 02 Sep 2025 08:51:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105822.1456649; Tue, 02 Sep 2025 08: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 1utMjS-0006Ft-SJ; Tue, 02 Sep 2025 08:51:14 +0000 Received: by outflank-mailman (input) for mailman id 1105822; Tue, 02 Sep 2025 08:51: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 1utMjR-0006Fl-G1 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 08:51:13 +0000 Received: from mail180-6.suw31.mandrillapp.com (mail180-6.suw31.mandrillapp.com [198.2.180.6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f912f935-87d9-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 10:51:11 +0200 (CEST) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-6.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4cGKGP60m5z2K1s51 for ; Tue, 2 Sep 2025 08:51:09 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 44205d22c4ed434480dfe465bddf34e9; Tue, 02 Sep 2025 08:51: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: f912f935-87d9-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1756803069; x=1757073069; bh=IctssQzfxiWFreFW7P+405nqJQelkdXxf9bCeLRH1ZQ=; 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=daO40ZNzOuZPtkHBnQkPCo6QXpGq1aXL/SGBPPhwSTHvbBZ8YNYoE0plPaHrGD844 ovRDcN9J3wh4l+YGYa4khvRcMMN4X67EkY44/1IGkOlCDeelhY7swvtI+ArY12YGhq kv5Julx/VIV1AxUInu9DBLHoUgN4AYHmQ/pgkdU2NsIYXqpNJNmgQugXqF2PxLc7ow cgBe1UM4QJI9aywfINL8oNMBMQ+FVxMQ+ijIRwSeW67MEMaI2MhtsmR9nHsB41TSH4 Te/lfCWR/PPPJv0ncrzkNdcsxG3YYD40PjcZQuUfsgDCuw1fpXSfi99aPDJIws3fh+ ft28B6CjAdROQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1756803069; x=1757063569; i=yann.sionneau@vates.tech; bh=IctssQzfxiWFreFW7P+405nqJQelkdXxf9bCeLRH1ZQ=; 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=0yaijl7FuSX27jCiOTp/h9JTykhUxM5snjbz3agSRfYXuAX72Tv9IHr0ksLp/HP00 4zXCjfMU5mWQOoMWOc4xcuf3VGWJwHxrQDYeSSuK/kk3jxoDeH0iKKhvdEbgC1xfQf O4W/1FPo/7LL9mxlG8JW4+tEfMkldgpZenyFgQp65HrwheyZAj3QtPJVbm89b/IN3M nhqVa2t2aUV2OiDvGimr21ZWygq4FMfLw81jyb1x44EQjl27+Z+BrHwZJerYzjBYEu StWaL2rmWm8mafJnFqtEuDWM7XNg2Gb6u8UsWe8GqS7Xj+NEY9jIW8gRCmsmCB8hk6 5iuDM6VbI0KLQ== From: "Yann Sionneau" Subject: =?utf-8?Q?Re:=20[XEN=20PATCH]=20efi:=20Use=20Shim's=20LoadImage=20to=20verify=20the=20Dom0=20kernel?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1756803067924 Message-Id: <9a19193e-39d6-4dce-81f5-f1c0e04bd480@vates.tech> To: "Gerald Elder-Vass" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Kevin Lampis" , "Daniel P. Smith" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Jan Beulich" References: <766be642204043b779cef688ec0ca2f1d64313ad.1756740104.git.gerald.elder-vass@cloud.com> In-Reply-To: <766be642204043b779cef688ec0ca2f1d64313ad.1756740104.git.gerald.elder-vass@cloud.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.44205d22c4ed434480dfe465bddf34e9?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250902:md Date: Tue, 02 Sep 2025 08:51:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/1/25 17:37, Gerald Elder-Vass wrote: > The existing Verify functionality of the Shim lock protocol is > deprecated and will be removed, instead we must use the LoadImage > interface to perform the verification. > > When the loading is successful we won't be using the newly loaded image > (as of yet) so we must then immediately unload the image to clean up. > > Signed-off-by: Gerald Elder-Vass > Signed-off-by: Kevin Lampis > --- > xen/common/efi/boot.c | 39 +++++++++++++++++++++++++++------------ > 1 file changed, 27 insertions(+), 12 deletions(-) > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 453b1ba099cd..67e7220d8fa3 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -36,8 +36,8 @@ > > #define SMBIOS3_TABLE_GUID \ > { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} } > -#define SHIM_LOCK_PROTOCOL_GUID \ > - { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} } > +#define SHIM_IMAGE_LOADER_GUID \ > + { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} } > #define APPLE_PROPERTIES_PROTOCOL_GUID \ > { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} } > #define EFI_SYSTEM_RESOURCE_TABLE_GUID \ > @@ -66,9 +66,12 @@ typedef EFI_STATUS > IN const VOID *Buffer, > IN UINT32 Size); > > -typedef struct { > - EFI_SHIM_LOCK_VERIFY Verify; > -} EFI_SHIM_LOCK_PROTOCOL; > +typedef struct _SHIM_IMAGE_LOADER { > + EFI_IMAGE_LOAD LoadImage; > + EFI_IMAGE_START StartImage; > + EFI_EXIT Exit; > + EFI_IMAGE_UNLOAD UnloadImage; > +} SHIM_IMAGE_LOADER; > > struct _EFI_APPLE_PROPERTIES; > > @@ -1333,13 +1336,13 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, > EFI_SYSTEM_TABLE *SystemTable) > { > static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL; > - static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; > EFI_LOADED_IMAGE *loaded_image; > EFI_STATUS status; > + EFI_HANDLE loaded_kernel; > unsigned int i; > CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL; > UINTN gop_mode = ~0; > - EFI_SHIM_LOCK_PROTOCOL *shim_lock; > + SHIM_IMAGE_LOADER *shim_loader; > EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL; > union string section = { NULL }, name; > bool base_video = false; > @@ -1590,12 +1593,24 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, > * device tree through the efi_check_dt_boot function, in this stage > * 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 ) > + if ( kernel.ptr && !kernel_verified ) > + { > PrintErrMesg(L"Dom0 kernel image could not be verified", status); I think this PrintErrMesg() should be removed. It will print a bogus message (indeed it has not been verified *Yet*, but maybe it's going to be). Also, PrintErrMesg calls blexit() which never returns, so the kernel verification with LoadImage will never happen and Xen boot will stop. > + status = efi_bs->LocateProtocol(&((EFI_GUID) SHIM_IMAGE_LOADER_GUID), > + NULL, (void **)&shim_loader); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"Error LocateProtocol IMAGE_LOADER", status); > + > + if ( kernel.ptr ) { > + status = shim_loader->LoadImage(false, ImageHandle, NULL, (void *)kernel.ptr, kernel.size, &loaded_kernel); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"LoadImage failed", status); > + > + // LoadImage performs verification, now unload it to clean up > + status = shim_loader->UnloadImage(loaded_kernel); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"UnloadImage failed", status); > + } > > efi_arch_edd(); > Regards, -- -- Yann Sionneau | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Sep 02 08:57:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 08:57:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105832.1456660 (Exim 4.92) (envelope-from ) id 1utMow-0006sK-In; Tue, 02 Sep 2025 08:56:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105832.1456660; Tue, 02 Sep 2025 08:56:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utMow-0006sD-EI; Tue, 02 Sep 2025 08:56:54 +0000 Received: by outflank-mailman (input) for mailman id 1105832; Tue, 02 Sep 2025 08:56:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utMov-0006s7-KX for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 08:56:53 +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 c31bcdf0-87da-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 10:56:51 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by DU0PR03MB9199.eurprd03.prod.outlook.com (2603:10a6:10:470::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 08:56:44 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 08:56: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: c31bcdf0-87da-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=n7ywhbfQeRTdVIk6zngOJiv1g1OVLlRWimVn4e52PNKv16n4rY9jhveYjQY2Uli6HzEm2XuB6mb5geVkHEtpUgZye5S8nsVilX4N/vTxGxH5pn+mcNy+qryaAa40KR9hwXe7DuTSuWVxWfMaEs/zeL6P82vSi3ScDp0agbe+DuY7cdpoSoMs7PrF2SsvBkz1kK4fNQRyIpTvCWhsv7u3Qbl/Ku3PVuxWUe5ae9xiNU5cwl6MqDc/WBr9nhneNkhbTRlHXAYPW7osVGpG3j8jRrvHJJueByne2HUcROLyDYEQMIf97tx1yifBmGpxxlMWzBKDTXzghTE8bGwZLp9fww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AEnWqtqjibiOM/a/teXEUvBkZTu/vae8y4s1hOhA0tg=; b=Udy68R7qqqhwAFUa8Srn3zywW/WMC1lDWxWILKTz59kDTgjDkb7T3OeZTXvunFWr7WVQpnQrJmbHbYJAywAshRH+dVUwfIhDf6yCEbVqDjWvuE6ZVRJZ6sL4c9JItKShbCptj/Ak/KoGIwpZHNt6/qqOyjtrsy7utLIo5twTmjEWIBj0M7UReSY+DNKRgNCUCQqwPZhbJNf2lLoJU6cF1AdMeWxXzvH9NNtMw20n9kx/zA+H5CLa9HLV/dBu0eGzJU2LP5uIOR0laNKzsqcsADQrJY+7LpdvAf+rKvrnPK2NZJmbRTI1yuTsS7+3mNr+pYKni6aOJx/xQ4hhUqBl+w== 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=AEnWqtqjibiOM/a/teXEUvBkZTu/vae8y4s1hOhA0tg=; b=cSt8vNY8p5D44PhsBfJiRt/gkzJOpCkq0A3h0WN1avAL7R3UlJe8JZ8sTSpaUhg66LR365+GRaVWBE1HDMjKmZHhsQqRTlmRY9UAnQCu9c20rcjmEsI2MHuL923gTKzPtf2BgezMfOgOtzfFXtx/PdaCst4xma0mqjCk54iDneAjvy+EHHQlzNYDNDKDOBrx8WwgwZCOwtSZEQb1CnQLPJgmTA8RY85NrnR5LQHfykmS0pbx4K5mNn1ZfDJEV88KQv+7I7gwrN/gJ4a0kYXrbFSNDmODRJoTc76cP0PH35Jp9OypxdZ7YQHuEZVvSJXc1sW2jTISXnBKuoGWW8mTKQ== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Thread-Topic: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Thread-Index: AQHcGP7bBiDA5fxWR0+DupelLQbe97R+hBgAgAEY7IA= Date: Tue, 2 Sep 2025 08:56:44 +0000 Message-ID: <4c3a2a94-7c19-4d1a-8477-c38716170c49@epam.com> References: <2e91a95a-3109-46ae-b796-1a1c50a9ac2d@xen.org> In-Reply-To: <2e91a95a-3109-46ae-b796-1a1c50a9ac2d@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: GV2PR03MB8678:EE_|DU0PR03MB9199:EE_ x-ms-office365-filtering-correlation-id: 7d8788dd-e3f1-44a4-0190-08dde9fea45c 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?eHlrTFl0UFFuRXRlL1hZd0JvaTdYeXdvSk5KZmlBcGJHNWQrZUpva0lLRFk1?= =?utf-8?B?R3crUFJFZkJWVjVVdzFvKzNMRlNuTmhpTUNBRmRUcEZpc3Z3YWU5MmhIa0dP?= =?utf-8?B?WTdGemdrYlJRWDBLTGs4Z092N3VNcmdnZVFrRVBDdkZBcVFNMXZkaENKaENS?= =?utf-8?B?eWhyd0ZjM1NJTDJDYmRSRVFjK2YwYWxhUkJ5RXE2d1VENldmR09Hc3hLVkI5?= =?utf-8?B?TUluUDhDKzZmdlNRNjA2dG5mc05pMExYak9TVWYyeUpYYmgyRUliN0ZQZHdK?= =?utf-8?B?cktqeVVuRVdIeUhBaTlFSmk5UytwOVRFYjl0ZWRRQkx5TjR4T0IvdUJWYndm?= =?utf-8?B?NWhKMVBOQWNsaUhZbGxlaUtHUlhvWmhnSmZ1QkprZlZsR0tMMldnbEJXQlBu?= =?utf-8?B?c3VhR0h6TjZuOGVlMkJLVHpKVHZCK0xPSGhxYWpoME9JbitibW80Y25ETllr?= =?utf-8?B?dDNBaXFqSHpqMnl1QktjcFJTcVVsekpzMm5QV3RqVG5vNDUxTVRtSmZrZ1lk?= =?utf-8?B?K0g2U3MwS21icTV6TjVpaWg3cFliaXgwOXlmc2VnQy9tdVRBQkZhVFhnbHBE?= =?utf-8?B?VDA1L3BqS1VnZC9oTkdFaU9aTisxY0ZxbUIwVmRiTWx2N0RhaW1zUXJlcXJ0?= =?utf-8?B?VDV1T3pMU1gyQzRKZmVxemdGV2t2UCtrNXczTWx3WDNVaCtlbUJINHd5V2FF?= =?utf-8?B?a0MvU2FPVVZrYm5ZSnpNWFVNZDJiZm9mTGx1eEFQbGlxZWtKRGRkTTJkeFBB?= =?utf-8?B?UGQ5ekZRSzNERkg3TFhET25GTGs2S1lVaHgxSVFjcFlzWXQ2S2ZpcUYzRlhu?= =?utf-8?B?R1QyNHpkTDB6SEVzSTRGNDVpcGZzYldabGMzenpoL21CdXBYbjVZYkJ0RDVZ?= =?utf-8?B?aEZneEdpN0dzdWowdmczR25scVczcXE3bGx4eE5sRzlxditSSGlZdTVHekp4?= =?utf-8?B?OUIyanVLbGNUNCtpZ3ordWJ0aWNVQXRBT0FZK3V4clFsaldjR2N2RGVVYmFr?= =?utf-8?B?by9aNHhYMWJ2QWo3dVRtK1FlZTE0UGxpRkpGTFdRUGtDdnROL3NVbXZtRGpZ?= =?utf-8?B?Z0VwQ1F5N01kZ1pJZjY1eXN4NmJCRU1QMFdBSzhpMWpuTGV5YlQ0NEprRmc0?= =?utf-8?B?a0J0dnd0YkZsZTdvRFROcWhSL1BKV2UvUitzZHc1UCtTdWZKb21vRXFJQkRy?= =?utf-8?B?VWpSTG95V1dWNFltU01Kc2JmT3RKbmhsMHQ2eXYzVlN6TmtlU05kYXQ2VDhV?= =?utf-8?B?YTY3YVVTeXlSYTlFdUMzSk8rRklTL3g1aE95aXNIUzNoeUVKclFRZ2kzNTMz?= =?utf-8?B?UnRHWHAvZ0RjMmZyZVVIQmhKUm16NkN1TEFOOE16NlJsWXc1NW1yRXFuUjJv?= =?utf-8?B?OW1MRnpNZ1FWdjIvcEdBbW5QMkJXOFRicHNQK1NKeTFlMVZEYUpKL3YyVjV0?= =?utf-8?B?dGdwNzBuT1lmR1p3ZVVxdXV4SXk3aGZyVmE5Z3BqRWdZR2JqZGE0b25PSndE?= =?utf-8?B?Rmo0dmpRVC9jNVEyZFY3ZlgyMFJ2bmJ2Qm4wVEhtZGRSa1dqZ3lsZDFJYXRD?= =?utf-8?B?d00vSU9jUmZtcWVRSnowVWo0WVU4ak1kbTJhcFUxMkdCU3Z0ZS9CUkpCUXFH?= =?utf-8?B?eDZqNk56dHBQSVhzdUxvNDU2ODZQY011d2FITVV3SmFMVHJva3gzWGdqSjhS?= =?utf-8?B?SXFIbkdUdUZTK0YzbE55cEpwbmd3bldVbnBtWmFwRkxrMGpqeEd5Q1RRS1lt?= =?utf-8?B?MHJnWDcrZmh0cmptVXp1N1JiREVKNVhBcFBta1JQVXI0OG5VVys2Snp2OEpy?= =?utf-8?B?dEFyVjk5eVB5YXZkVmNmWE9YU0JBckdSREUvU3Y5akI1d2lJY05ML1Vzb1Vr?= =?utf-8?B?ek40QWxwb0p2ZE5UWUFYYWgzd25LM2M4N0JQU3IyR2Z4SGEvcTh6ZE5QZWVz?= =?utf-8?B?aURENmRvRm5XUWhQd0JnUnVBdm8vTmsyVktYak1yU1F2NzI1eG5qeXNicVZJ?= =?utf-8?B?M0lQNUN5amVnPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.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?K0NhVDZxeHhDNkw1a29KanVaa3YybldpVnFWdlhrNnNQZk91TkFlSEJwZGU4?= =?utf-8?B?WXNXQnBwSW1XcWdKd1Vaa3d5U1kvQThVOCtFa1Z1aExPdThuZGgyVDJPZXpn?= =?utf-8?B?WjRRK3F4ZWtRQ0ord0Y0bmdvQ0N3VFU5cExxRE03dGxMdlFUNWF1UWJuS3FS?= =?utf-8?B?NG51Qkxna3haVGxmYUN5OTFBekJCVWtGb0YrM3NhcVljbjhvMFY0dVRuY3hM?= =?utf-8?B?N1VSdGN3RkdLQ2g3SC9KbFlHZE1aeHNIbE45Z3pmWnpyVWxRNjBORHNHc1dE?= =?utf-8?B?VlJsMkZpMHdvQzNNMVpIVXh3RnhWQm5WSnhaZWhFZjcwVHYxQ09WVG5SaEIz?= =?utf-8?B?R1oyQXJCcFlWS0JXQUxuUk95Mm9JV1EraERSLzVwT2VmbDVYNDViS0F3VXN6?= =?utf-8?B?bmdGRkZTUnpFcVhIa2xIbW5oRjhSU3ZHa3hzT2pJTC9kNnN0SjkzSTlPQ3BU?= =?utf-8?B?QXlmYTd0cXhNV011OU44cTdkMWxqNm1DNkhnaE9qSzAwWnNVbE1kMWM5MXFJ?= =?utf-8?B?Rzh5MWQ5bG1RWEtBbm1hUnlyNjhhUE9XS1gwTzh2YlpEelNFbVYra3hsb2Uv?= =?utf-8?B?OHE5R25PeTNCWXdZL04xVGpyUnRqbElkRGJDSStYVjM1aEFMSGwrdkhQd3V3?= =?utf-8?B?SDh4SGJOM290NHhSVlR3MU5vV0RLOS9JWkp3aDlQdHZnVnBUVU9RZWtXUnUx?= =?utf-8?B?N2lxQTF0SndLRFRJL3c3dk51Zzl4T1BlM0I0RGc3TlVQdVAyOWJHKzRsaGZY?= =?utf-8?B?c29sRXBzWTZzRXQ5Q2oyajBJd2IzTFVuOVFoWXpnOFJQQUd5enRNLzE1M3JF?= =?utf-8?B?eW9GUTFJbTVBaTltTUQxck1maXQ1ZWRnK1VDR0l5cVlKVHpVazZUN0wvcnhh?= =?utf-8?B?TVMzY1FwMXlqTmxORGNvSDdVcEVPWjNtQjdnZDNtNzRLYVA5RitkQ3hhQktU?= =?utf-8?B?d0pJRzVXTWhtSTd1cS9SSXhEUTE0OFR6K2dzZWg4Y3FQMTZQNGNuRjc5czBx?= =?utf-8?B?ZDhLMWRXODQzd1ZwL2RQejRyTVJ1SmtSTnlGQmo4UUhFS1F6M3dzbk5rWFB2?= =?utf-8?B?WUdSd0tRUDFkQ053ekQzRnJwcHB5TzlJNmxoY25yUkwyS0p3QXo3NmkveUE0?= =?utf-8?B?Z0ZWN3ZtazhkcXoxaVZ5S0lLc1NxK0lOenptMkZOdURSaFlOaTFrZ21XN1JU?= =?utf-8?B?NTRvenFLcHlNU3M1RHh5VS9hTDVMUncxaUdkTjBZTXFYYnlwaW56MmhiSlFs?= =?utf-8?B?SlJxOXBabnRIclUrZ2J1NHk1dkNRRXVKVzRJZzlKZ0JSYUYzU3p3L0c2T2tp?= =?utf-8?B?LzJKLzdnOXFmZ0tmOHhoeVdSOXhYMFdXM2FJaTRmTU4xcUo3WHNlbnZkWWQ4?= =?utf-8?B?RjN6c2JKeDNrTEptTTVsVmtEZzlDcHFDcCtHSmdUZmo3RnN1TFQ3RzZiVUJa?= =?utf-8?B?THlsZFFxVXF6Y3lKTU4zWEFodHovWXNyZEE4Z2RXLzFIblBBYUxXUFBacjln?= =?utf-8?B?Uy9Edk1YTzZvWXdjemk0ZGtpN25JWEhURk12S2dNa1VCRjUyS0xiVkwvR2dV?= =?utf-8?B?RWxjWU1WSXI3dEcxQ2dYblhJeTFscy91NVVvOXh0N0NYOHpmU0ZuMDVwdE1p?= =?utf-8?B?K093eFg3YTFTWGJnb2dYMjNoeDFwUEJuNnZ3OHhRN1ZLWDBpLzhEb21wZG52?= =?utf-8?B?SFpwVlo0amlSKzJheXVUME81dGtoY2lOcjM4OWQxa3ZvcHd2NXJVNlY1YUIy?= =?utf-8?B?aHIwSXFUTUQzaUhLTGl6cVRLTndRTmdFSk1qR3YxL2xreTVmcU1rVjd5ZzRp?= =?utf-8?B?S3k1MTFpMXRmTTJKUjM1a1lvTldvUmVSUkVCckl5LzRuWjBGVEJ1VndYNW90?= =?utf-8?B?MkVaWDRQaU9JblNpSmJ2YVArVVhMK0lkUk16UURwOGpFNHphUm95OEN4K2J6?= =?utf-8?B?a3FScDZmcWxEbUh1TzROU0NteUdHb01OTHZ6eElqaDFuTElPTWFxUlhpWFhw?= =?utf-8?B?WjY0cERsbXZJcVlnQmtLWlE1aG9jMS9ZZW9jQm5CM1RzY3Vkell0ckpCbnBu?= =?utf-8?B?ZE5iQTBHaG5ZUEE5R1RpUUkvOWs4VGF0WmJOWU5OTjZFaEFMamt1OVZWalM3?= =?utf-8?B?dFlQWTFvb2poQnIyaUxTYkRzeHdoYkpUSEhVdCtUYklvL25UMzBQQTNJb3la?= =?utf-8?Q?EQAPEqaWZ17tu3XHaHpG/Bg=3D?= 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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d8788dd-e3f1-44a4-0190-08dde9fea45c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 08:56:44.4206 (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: hyYX2cenQej+byh8XsFbH9lITvaiLz5zffLxRBk/I9xEIbTJwLBD2sLD9rktaAGdveWsPh6J4eK4Ldi4aZr1jTEGohk94eidYKgHVDe3OMc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9199 SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAwMS4wOS4yNSAx OToxMSwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBIaSBMZW9uaWQsDQo+IA0KPiBPbiAyOS8wOC8y MDI1IDE3OjA2LCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0KPj4gQ3VycmVudGx5LCBYZW4g ZG9lcyBub3Qgc3VwcG9ydCBlU1BJIGludGVycnVwdHMsIGxlYWRpbmcNCj4+IHRvIGEgZGF0YSBh Ym9ydCB3aGVuIHN1Y2ggaW50ZXJydXB0cyBhcmUgZGVmaW5lZCBpbiB0aGUgRFRTLg0KPj4NCj4+ IFRoaXMgcGF0Y2ggaW50cm9kdWNlcyBhIHNlcGFyYXRlIGFycmF5IHRvIGluaXRpYWxpemUgdXAg dG8NCj4+IDEwMjQgaW50ZXJydXB0IGRlc2NyaXB0b3JzIGluIHRoZSBlU1BJIHJhbmdlIGFuZCBh ZGRzIHRoZQ0KPj4gbmVjZXNzYXJ5IGRlZmluZXMgYW5kIGhlbHBlciBmdW5jdGlvbi4gVGhlc2Ug Y2hhbmdlcyBsYXkgdGhlDQo+PiBncm91bmR3b3JrIGZvciBmdXR1cmUgaW1wbGVtZW50YXRpb24g b2YgZnVsbCBlU1BJIGludGVycnVwdA0KPj4gc3VwcG9ydC4gQXMgdGhpcyBHSUN2My4xIGZlYXR1 cmUgaXMgbm90IHJlcXVpcmVkIGJ5IGFsbCB2ZW5kb3JzLA0KPj4gYWxsIGNoYW5nZXMgYXJlIGd1 YXJkZWQgYnkgaWZkZWZzLCBkZXBlbmRpbmcgb24gdGhlIGNvcnJlc3BvbmRpbmcNCj4+IEtjb25m aWcgb3B0aW9uLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IExlb25pZCBLb21hcmlhbnNreWkgPGxl b25pZF9rb21hcmlhbnNreWlAZXBhbS5jb20+DQo+Pg0KPj4gLS0tDQo+PiBDaGFuZ2VzIGluIFY1 Og0KPj4gLSBubyBmdW5jdGlvbmFsIGNoYW5nZXMgaW50cm9kdWNlZCBieSB0aGlzIHZlcnNpb24g Y29tcGFyZWQgd2l0aCBWNCwgb25seQ0KPj4gwqDCoCBtaW5vciBmaXhlcyBhbmQgcmVtb3ZhbCBv ZiBpZmRlZnMgZm9yIG1hY3Jvc2VzDQo+PiAtIGFkZGVkIFRPRE8gY29tbWVudCwgc3VnZ2VzdGVk IGJ5IE9sZWtzYW5kciBUeXNoY2hlbmtvDQo+PiAtIGNoYW5nZWQgaW50IHRvIHVuc2lnbmVkIGlu dCBmb3IgaXJxcw0KPj4gLSByZW1vdmVkIGlmZGVmcyBmb3IgZVNQSS1zcGVjaWZpYyBkZWZpbmVz IGFuZCBtYWNyb3MgdG8gcmVkdWNlIHRoZQ0KPj4gwqDCoCBudW1iZXIgb2YgaWZkZWZzIGFuZCBj b2RlIGR1cGxpY2F0aW9uIGluIGZ1cnRoZXIgY2hhbmdlcw0KPj4gLSByZW1vdmVkIHJldmlld2Vk LWJ5IGFzIG1vdmluZyBkZWZpbmVzIGZyb20gaWZkZWZzIHJlcXVpcmVzIGFkZGl0aW9uYWwNCj4+ IMKgwqAgY29uZmlybWF0aW9uIGZyb20gcmV2aWV3ZXJzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWNDoN Cj4+IC0gcmVtb3ZlZCByZWR1bmRhbnQgbGluZSB3aXRoICdkZWZhdWx0IG4nIGluIEtjb25maWcs IGFzIGl0IGlzIGRpc2FibGVkDQo+PiDCoMKgIGJ5IGRlZmF1bHQsIHdpdGhvdXQgZXhwbGljaXQg c3BlY2lmaWNhdGlvbg0KPj4gLSBhZGRlZCByZXZpZXdlZC1ieSBmcm9tIFZvbG9keW15ciBCYWJj aHVrDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMzoNCj4+IC0gaW50cm9kdWNlZCBhIG5ldyBkZWZpbmUg TlJfRVNQSV9JUlFTIHRvIGF2b2lkIGNvbmZ1c2lvbiwgbGlrZSBpbiB0aGUNCj4+IMKgwqAgY2Fz ZSBvZiB1c2luZyBOUl9JUlFTIGZvciBlc3BpX2Rlc2MgYXJyYXkNCj4+IC0gaW1wbGVtZW50ZWQg aGVscGVyIGZ1bmN0aW9ucyBlc3BpX3RvX2Rlc2MgYW5kIGluaXRfZXNwaV9kYXRhIHRvIG1ha2UN Cj4+IMKgwqAgaXQgcG9zc2libGUgdG8gYWRkIHN0dWJzIHdpdGggdGhlIHNhbWUgbmFtZSwgYW5k IGFzIGEgcmVzdWx0LCByZWR1Y2UNCj4+IMKgwqAgdGhlIG51bWJlciBvZiAjaWZkZWZzDQo+PiAt IGRpc2FibGUgQ09ORklHX0dJQ1YzX0VTUEkgZGVmYXVsdCB2YWx1ZSB0byBuDQo+Pg0KPj4gQ2hh bmdlcyBpbiBWMjoNCj4+IC0gdXNlIChFU1BJX01BWF9JTlRJRCArIDEpIGluc3RlYWQgb2YgKEVT UElfQkFTRV9JTlRJRCArIE5SX0lSUVMpDQo+PiAtIHJlbW92ZSB1bm5lY2Vzc2FyeSBjb21tZW50 IGZvciBucl9pcnFzIGluaXRpYWxpemF0aW9uDQo+PiAtLS0NCj4+IMKgIHhlbi9hcmNoL2FybS9L Y29uZmlnwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDggKysrKysNCj4+IMKgIHhlbi9hcmNoL2Fy bS9pbmNsdWRlL2FzbS9pcnEuaCB8IDI0ICsrKysrKysrKysrKysrKw0KPj4gwqAgeGVuL2FyY2gv YXJtL2lycS5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgNTYgKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrLQ0KPj4gwqAgMyBmaWxlcyBjaGFuZ2VkLCA4NyBpbnNlcnRpb25zKCsp LCAxIGRlbGV0aW9uKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9LY29uZmln IGIveGVuL2FyY2gvYXJtL0tjb25maWcNCj4+IGluZGV4IDE3ZGYxNDdiMjUuLjQzYjA1NTMzYjEg MTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vS2NvbmZpZw0KPj4gKysrIGIveGVuL2FyY2gv YXJtL0tjb25maWcNCj4+IEBAIC0xMzUsNiArMTM1LDE0IEBAIGNvbmZpZyBHSUNWMw0KPj4gwqDC oMKgwqDCoMKgwqAgRHJpdmVyIGZvciB0aGUgQVJNIEdlbmVyaWMgSW50ZXJydXB0IENvbnRyb2xs ZXIgdjMuDQo+PiDCoMKgwqDCoMKgwqDCoCBJZiB1bnN1cmUsIHVzZSB0aGUgZGVmYXVsdCBzZXR0 aW5nLg0KPj4gK2NvbmZpZyBHSUNWM19FU1BJDQo+PiArwqDCoMKgIGJvb2wgIkV4dGVuZGVkIFNQ SSByYW5nZSBzdXBwb3J0Ig0KPj4gK8KgwqDCoCBkZXBlbmRzIG9uIEdJQ1YzICYmICFORVdfVkdJ Qw0KPj4gK8KgwqDCoCBoZWxwDQo+PiArwqDCoMKgwqDCoCBBbGxvdyBYZW4gYW5kIGRvbWFpbnMg dG8gdXNlIGludGVycnVwdCBudW1iZXJzIGZyb20gdGhlIA0KPj4gZXh0ZW5kZWQgU1BJDQo+PiAr wqDCoMKgwqDCoCByYW5nZSwgZnJvbSA0MDk2IHRvIDUxMTkuIFRoaXMgZmVhdHVyZSBpcyBpbnRy b2R1Y2VkIGluIEdJQ3YzLjENCj4+ICvCoMKgwqDCoMKgIGFyY2hpdGVjdHVyZS4NCj4+ICsNCj4+ IMKgIGNvbmZpZyBIQVNfSVRTDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgYm9vbCAiR0lDdjMgSVRT IE1TSSBjb250cm9sbGVyIHN1cHBvcnQgKFVOU1VQUE9SVEVEKSIgaWYgDQo+PiBVTlNVUFBPUlRF RA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGRlcGVuZHMgb24gR0lDVjMgJiYgIU5FV19WR0lDICYm ICFBUk1fMzINCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaXJxLmgg Yi94ZW4vYXJjaC9hcm0vaW5jbHVkZS8gDQo+PiBhc20vaXJxLmgNCj4+IGluZGV4IDViYzY0NzVl YjQuLjQ0NDM3OTk2NDggMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v aXJxLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEuaA0KPj4gQEAgLTMy LDYgKzMyLDEzIEBAIHN0cnVjdCBhcmNoX2lycV9kZXNjIHsNCj4+IMKgICNkZWZpbmUgU1BJX01B WF9JTlRJRMKgwqAgMTAxOQ0KPj4gwqAgI2RlZmluZSBMUElfT0ZGU0VUwqDCoMKgwqDCoCA4MTky DQo+PiArI2RlZmluZSBFU1BJX0JBU0VfSU5USUQgNDA5Ng0KPj4gKyNkZWZpbmUgRVNQSV9NQVhf SU5USUTCoCA1MTE5DQo+PiArI2RlZmluZSBOUl9FU1BJX0lSUVPCoMKgwqAgMTAyNA0KPj4gKw0K Pj4gKyNkZWZpbmUgRVNQSV9JTlRJRDJJRFgoaW50aWQpICgoaW50aWQpIC0gRVNQSV9CQVNFX0lO VElEKQ0KPj4gKyNkZWZpbmUgRVNQSV9JRFgySU5USUQoaWR4KcKgwqAgKChpZHgpICsgRVNQSV9C QVNFX0lOVElEKQ0KPiANCj4gTklUOiBJIHdvdWxkIGNvbnNpZGVyIGFkZGluZyBzYW5pdHkgY2hl Y2sgKGkuZS4gQVNTRVJUKCkpIHRvIGNvbmZpcm0gDQo+IHRoYXQgYm90aCBgYGludGlkYGAgYW5k IGBgaWR4YGAgYXJlIHdpdGhpbiB0aGUgYm91bmRzLg0KPiANCg0KT2theSwgSSB3aWxsIGFkZCBz YW5pdHkgY2hlY2sgd2l0aCBBU1NFUlRzIGluIFY2IChzaW1pbGFyIHRvIA0KR05UUElOX2luY3Iy b2Zsb3dfbWFzayk6DQoNCiNkZWZpbmUgRVNQSV9JTlRJRDJJRFgoaW50aWQpICAgICAgICAgICAg ICAgICAgICAgICAgICAgXA0KICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgQVNTRVJUKCgoaW50aWQpID49IEVTUElfQkFT RV9JTlRJRCkgJiYgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICgoaW50aWQpIDw9IEVTUElf TUFYX0lOVElEKSk7ICAgICAgICAgICAgXA0KICAgICAgICAgKChpbnRpZCkgLSBFU1BJX0JBU0Vf SU5USUQpOyAgICAgICAgICAgICAgICAgICAgXA0KICAgICB9KQ0KDQojZGVmaW5lIEVTUElfSURY MklOVElEKGlkeCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgKHsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgIEFT U0VSVCgoKGlkeCkgPj0gMCkgJiYgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAg ICAgICAgICAoKGlkeCkgPD0gTlJfRVNQSV9JUlFTKSk7ICAgICAgICAgICAgICAgIFwNCiAgICAg ICAgICgoaWR4KSArIEVTUElfQkFTRV9JTlRJRCk7ICAgICAgICAgICAgICAgICAgICAgIFwNCiAg ICAgfSkNCg0KDQo+PiArDQo+PiDCoCAvKiBMUElzIGFyZSBhbHdheXMgbnVtYmVyZWQgc3RhcnRp bmcgYXQgODE5Miwgc28gMCBpcyBhIGdvb2QgaW52YWxpZCANCj4+IGNhc2UuICovDQo+PiDCoCAj ZGVmaW5lIElOVkFMSURfTFBJwqDCoMKgwqAgMA0KPj4gQEAgLTM5LDcgKzQ2LDE1IEBAIHN0cnVj dCBhcmNoX2lycV9kZXNjIHsNCj4+IMKgICNkZWZpbmUgSU5WQUxJRF9JUlHCoMKgwqDCoCAxMDIz DQo+PiDCoCBleHRlcm4gY29uc3QgdW5zaWduZWQgaW50IG5yX2lycXM7DQo+PiArI2lmZGVmIENP TkZJR19HSUNWM19FU1BJDQo+PiArLyoNCj4+ICsgKiBUaGlzIHdpbGwgYWxzbyBjb3ZlciB0aGUg ZVNQSSByYW5nZSwgYXMgc29tZSBjcml0aWNhbCBkZXZpY2VzDQo+PiArICogZm9yIGJvb3Rpbmcg WGVuIChlLmcuLCBzZXJpYWwpIG1heSB1c2UgdGhpcyB0eXBlIG9mIGludGVycnVwdHMuDQo+PiAr ICovDQo+IA0KPiBSZWFkaW5nIHRoaXMgYWdhaW4sIEkgc3RpbGwgZG9uJ3QgcXVpdGUgdW5kZXJz dGFuZCB3aHkgd2UgYXJlIG1lbnRpb25pbmcgDQo+IFhlbiBkZXZpY2VzLiBMb29raW5nIGF0IHRo ZSBjb2RlLCBmb3IgQXJtLCB3ZSBvbmx5IHNlZW0gdG8gdXNlIA0KPiBucl9zdGF0aWNfaXJxcyB0 byBjb25maWd1cmUgbnJfcGlycXMgYW5kIFhTTS4gQm90aCBhcmUgb255IHVzZWQgYnkgZG9tYWlu cy4NCj4gDQo+IFNvIEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBjbGFyaWZpZWQuDQo+IA0KDQpT dXJlLCBJIHdpbGwgdXBkYXRlIHRoZSBjb21tZW50Lg0KDQo+PiArI2RlZmluZSBucl9zdGF0aWNf aXJxcyAoRVNQSV9NQVhfSU5USUQgKyAxKQ0KPj4gKyNlbHNlDQo+PiDCoCAjZGVmaW5lIG5yX3N0 YXRpY19pcnFzIE5SX0lSUVMNCj4+ICsjZW5kaWYNCj4+IMKgIHN0cnVjdCBpcnFfZGVzYzsNCj4+ IMKgIHN0cnVjdCBpcnFhY3Rpb247DQo+PiBAQCAtNTUsNiArNzAsMTUgQEAgc3RhdGljIGlubGlu ZSBib29sIGlzX2xwaSh1bnNpZ25lZCBpbnQgaXJxKQ0KPj4gwqDCoMKgwqDCoCByZXR1cm4gaXJx ID49IExQSV9PRkZTRVQ7DQo+PiDCoCB9DQo+PiArc3RhdGljIGlubGluZSBib29sIGlzX2VzcGko dW5zaWduZWQgaW50IGlycSkNCj4+ICt7DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+ PiArwqDCoMKgIHJldHVybiAoaXJxID49IEVTUElfQkFTRV9JTlRJRCAmJiBpcnEgPD0gRVNQSV9N QVhfSU5USUQpOw0KPj4gKyNlbHNlDQo+PiArwqDCoMKgIHJldHVybiBmYWxzZTsNCj4+ICsjZW5k aWYNCj4+ICt9DQo+PiArDQo+PiDCoCAjZGVmaW5lIGRvbWFpbl9waXJxX3RvX2lycShkLCBwaXJx KSAocGlycSkNCj4+IMKgIGJvb2wgaXNfYXNzaWduYWJsZV9pcnEodW5zaWduZWQgaW50IGlycSk7 DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2lycS5jIGIveGVuL2FyY2gvYXJtL2lycS5j DQo+PiBpbmRleCBiOGVjY2ZjOTI0Li42MWM5MTVjM2Y5IDEwMDY0NA0KPj4gLS0tIGEveGVuL2Fy Y2gvYXJtL2lycS5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaXJxLmMNCj4+IEBAIC0xOSw3ICsx OSwxMSBAQA0KPj4gwqAgI2luY2x1ZGUgPGFzbS9naWMuaD4NCj4+IMKgICNpbmNsI3VkZSA8YXNt L3ZnaWMuaD4NCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICtjb25zdCB1bnNpZ25l ZCBpbnQgbnJfaXJxcyA9IEVTUElfTUFYX0lOVElEICsgMTsNCj4+ICsjZWxzZQ0KPj4gwqAgY29u c3QgdW5zaWduZWQgaW50IG5yX2lycXMgPSBOUl9JUlFTOw0KPj4gKyNlbmRpZg0KPiANCj4gTklU OiBJIHRoaW5rIHlvdSBjYW4gdXNlOg0KPiANCj4gY29uc3QgdW5zaWduZWQgaW50IG5yX2lycXMg PSBJU19FTkFCTEVEKENPTkZJR19HSUNWM19FU1BJKT8gDQo+IChFU1BJX01BWF9JTlRJRCArIDEp IDogTlJfSVJRUzsNCj4gDQoNCkkgd2lsbCB1cGRhdGUgaXQgdG8gcHJvcG9zZWQgYWJvdmUgaW4g VjYsIHRoYW5rcy4NCg0KPiBUaGF0IHNhaWQsIEkgdGhpbmsgd2UgbmVlZCB0byByZXRoaW5rIGFi b3V0IHRoZSB1c2Ugb2YgbnJfaXJxcyBhbmQgDQo+IG5yX3N0YXRpY19pcnFzIGJlY2F1c2UgdGhl eSBkb24ndCBlbnRpcmVseSBtYWtlIHNlbnNlIGZvciBBcm0gYXMgd2UgDQo+IGRvbid0IHN1cHBv cnQgUElSUXMuDQo+IA0KPiBJIHdvdWxkIGF0IGxlYXN0IHRyeSB0byBnZXQgcmlkIG9mIG9uZSBv ZiB0aGUgdmFyaWFibGUgKG1heWJlIG5yX2lycXMpIA0KPiBpZiBub3QgYm90aC4NCj4gDQo+IFRo aXMgY291bGQgYmUgZG9uZSBhcyBhIGZvbGxvdy11cC4NCj4gDQo+PiDCoCBzdGF0aWMgdW5zaWdu ZWQgaW50IGxvY2FsX2lycXNfdHlwZVtOUl9MT0NBTF9JUlFTXTsNCj4+IMKgIHN0YXRpYyBERUZJ TkVfU1BJTkxPQ0sobG9jYWxfaXJxc190eXBlX2xvY2spOw0KPj4gQEAgLTQ2LDYgKzUwLDUzIEBA IHZvaWQgaXJxX2VuZF9ub25lKHN0cnVjdCBpcnFfZGVzYyAqaXJxKQ0KPj4gwqAgfQ0KPj4gwqAg c3RhdGljIGlycV9kZXNjX3QgaXJxX2Rlc2NbTlJfSVJRUyAtIE5SX0xPQ0FMX0lSUVNdOw0KPj4g KyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gKy8qDQo+PiArICogVE9ETzogQ29uc2lkZXIg YWxsb2NhdGluZyBhbiBhcnJheSBkeW5hbWljYWxseSBpZg0KPj4gKyAqIHRoZXJlIGlzIGEgbmVl ZCB0byBlbmFibGUgR0lDVjNfRVNQSSBieSBkZWZhdWx0Lg0KPj4gKyAqLw0KPiANCj4gSSBrbm93 IHRoaXMgd2FzIHN1Z2dlc3RlZCBieSBPbGVrc2FuZHIsIGhvd2V2ZXIgbW9zdCBsaWtlbHkgZGlz dHJvIHdpbGwgDQo+IHdhbnQgdG8gZW5hYmxlIHRoaXMgZmVhdHVyZSBzbyB0aGV5IGNhbiBiZSBi b290ZWQgb24gYSB3aWRlIHJhbmdlIG9mIA0KPiBwbGF0Zm9ybS4gU28gSSB0aGluayAiaWYgdGhl cmUgaXMgYSBuZWVkIHRvIGVuYWJsZSBHSUNWM19FU1BJIGJ5IA0KPiBkZWZhdWx0IiBzaG91bGQg YmUgcmVtb3ZlZC4NCj4gDQoNCkkgd2lsbCByZW1vdmUgdGhlIHNlY29uZCBwYXJ0IG9mIGNvbW1l bnQgaW4gVjYuDQoNCj4gID4gK3N0YXRpYyBpcnFfZGVzY190IGVzcGlfZGVzY1tOUl9FU1BJX0lS UVNdOz4gKw0KPj4gK3N0YXRpYyBzdHJ1Y3QgaXJxX2Rlc2MgKmVzcGlfdG9fZGVzYyh1bnNpZ25l ZCBpbnQgaXJxKQ0KPj4gK3sNCj4+ICvCoMKgwqAgcmV0dXJuICZlc3BpX2Rlc2NbRVNQSV9JTlRJ RDJJRFgoaXJxKV07DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgX19pbml0IGluaXRfZXNw aV9kYXRhKHZvaWQpDQo+PiArew0KPj4gK8KgwqDCoCB1bnNpZ25lZCBpbnQgaXJxOw0KPj4gKw0K Pj4gK8KgwqDCoCBmb3IgKCBpcnEgPSBFU1BJX0JBU0VfSU5USUQ7IGlycSA8PSBFU1BJX01BWF9J TlRJRDsgaXJxKysgKQ0KPj4gK8KgwqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgc3RydWN0IGly cV9kZXNjICpkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpbnQg cmMgPSBpbml0X29uZV9pcnFfZGVzYyhkZXNjKTsNCj4+ICsNCj4+ICvCoMKgwqDCoMKgwqDCoCBp ZiAoIHJjICkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByYzsNCj4+ICsNCj4+ ICvCoMKgwqDCoMKgwqDCoCBkZXNjLT5pcnEgPSBpcnE7DQo+PiArwqDCoMKgwqDCoMKgwqAgZGVz Yy0+YWN0aW9uwqAgPSBOVUxMOw0KPj4gK8KgwqDCoCB9DQo+PiArDQo+PiArwqDCoMKgIHJldHVy biAwOw0KPj4gK30NCj4+ICsjZWxzZQ0KPj4gKy8qDQo+PiArICogVGhpcyBmdW5jdGlvbiBpcyBz dHViIGFuZCB3aWxsIG5vdCBiZSBjYWxsZWQgaWYgQ09ORklHX0dJQ1YzX0VTUEk9biwNCj4+ICsg KiBiZWNhdXNlIGluIHRoaXMgY2FzZSwgaXNfZXNwaSB3aWxsIGFsd2F5cyByZXR1cm4gZmFsc2Uu DQo+PiArICovDQo+IA0KPiBJcyB0aGlzIGlzIG5vdCBtZWFuIHRvIGJlIGNhbGxlZCwgdGhlbiBj YW4gd2Ugb25seSBkZWZpbmUgdGhlIHByb3RvdHlwZSANCj4gbGlrZSB3ZSBkbyBmb3IgX19iYWRf YXRvbWljX3JlYWQoKT8NCj4gDQoNClRoaXMgd291bGQgb25seSBiZSBwb3NzaWJsZSBpZiBpc19l c3BpKCkgY29udGFpbnMgI2lmZGVmcyAod2hlbiANCkNPTkZJR19HSUNWM19FU1BJPW4sIGl0IHJl dHVybnMgZmFsc2UgdW5jb25kaXRpb25hbGx5KSwgYnV0IHdlIG5lZWQgdG8gDQphZ3JlZSBvbiB0 aGlzIGluIHRoZSBwYXJhbGxlbCB0aHJlYWQgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHRoaXMgcGF0 Y2guIA0KSWYgaXQgaXMgZmVhc2libGUsIEkgd2lsbCBkZWZpbmUgaXQgYXMgYSBwcm90b3R5cGUg aW4gdjYuDQoNCj4+ICtzdGF0aWMgc3RydWN0IGlycV9kZXNjICplc3BpX3RvX2Rlc2ModW5zaWdu ZWQgaW50IGlycSkNCj4+ICt7DQo+PiArwqDCoMKgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KPj4g K8KgwqDCoCByZXR1cm4gTlVMTDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBfX2luaXQg aW5pdF9lc3BpX2RhdGEodm9pZCkNCj4+ICt7DQo+PiArwqDCoMKgIHJldHVybiAwOw0KPj4gK30N Cj4+ICsjZW5kaWYNCj4+ICsNCj4+IMKgIHN0YXRpYyBERUZJTkVfUEVSX0NQVShpcnFfZGVzY190 W05SX0xPQ0FMX0lSUVNdLCBsb2NhbF9pcnFfZGVzYyk7DQo+PiDCoCBzdHJ1Y3QgaXJxX2Rlc2Mg Kl9faXJxX3RvX2Rlc2ModW5zaWduZWQgaW50IGlycSkNCj4+IEBAIC01Myw2ICsxMDQsOSBAQCBz dHJ1Y3QgaXJxX2Rlc2MgKl9faXJxX3RvX2Rlc2ModW5zaWduZWQgaW50IGlycSkNCj4+IMKgwqDC oMKgwqAgaWYgKCBpcnEgPCBOUl9MT0NBTF9JUlFTICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBy ZXR1cm4gJnRoaXNfY3B1KGxvY2FsX2lycV9kZXNjKVtpcnFdOw0KPj4gK8KgwqDCoCBpZiAoIGlz X2VzcGkoaXJxKSApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIGVzcGlfdG9fZGVzYyhpcnEp Ow0KPj4gKw0KPj4gwqDCoMKgwqDCoCByZXR1cm4gJmlycV9kZXNjW2lycS1OUl9MT0NBTF9JUlFT XTsNCj4+IMKgIH0NCj4+IEBAIC03OSw3ICsxMzMsNyBAQCBzdGF0aWMgaW50IF9faW5pdCBpbml0 X2lycV9kYXRhKHZvaWQpDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgZGVzYy0+YWN0aW9uwqAgPSBO VUxMOw0KPj4gwqDCoMKgwqDCoCB9DQo+PiAtwqDCoMKgIHJldHVybiAwOw0KPj4gK8KgwqDCoCBy ZXR1cm4gaW5pdF9lc3BpX2RhdGEoKTsNCj4+IMKgIH0NCj4+IMKgIHN0YXRpYyBpbnQgaW5pdF9s b2NhbF9pcnFfZGF0YSh1bnNpZ25lZCBpbnQgY3B1KQ0KPiANCj4gQ2hlZXJzLA0KPiANCg0KQmVz dCByZWdhcmRzLA0KTGVvbmlkDQo= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:04:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:04:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105849.1456676 (Exim 4.92) (envelope-from ) id 1utMvl-0000J0-JY; Tue, 02 Sep 2025 09:03:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105849.1456676; Tue, 02 Sep 2025 09: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 1utMvl-0000Hc-D0; Tue, 02 Sep 2025 09:03:57 +0000 Received: by outflank-mailman (input) for mailman id 1105849; Tue, 02 Sep 2025 09:03: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 1utMvk-0000FE-8m for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:03:56 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bfede0b8-87db-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:03:53 +0200 (CEST) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-55f78e3cdf9so2564869e87.1 for ; Tue, 02 Sep 2025 02:03:53 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-560827aabf5sm524019e87.137.2025.09.02.02.03.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 02:03: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: bfede0b8-87db-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756803833; x=1757408633; darn=lists.xenproject.org; h=content-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=iMTZeV1RLqj8sJpYIV/jbQJb4350elWFSvSX2DVPWHc=; b=MvpUj7D11uo7SjuS56QFFBy1KNjJjT45KMCNiuLhMo4vZbF8ipcAb4F4m2qteAjmqV WrG1Z//akAs5iVQ89Hfv202ejN80LEdsxNghCv0ao9fGlB2TX9+Iqkf9AVQuYWtS+G2V yHNj0BXpFJcERSJGOzC7w+pV+1oaZAUOoIt6j81IpXg8JM+WuvJjECrP8CdM0OCll7BC BaijBkSfr3rACkyavLMm4p6lvZxEYHXybv8IIV62FOk23Iy9UsJTdyJ32LMA7jpgVN78 OqvY7SMhMBuCVmK9RH4KsQ3sD2CcA4nry5TTKdcnbx/TxXOvDZM8+Gnb5VQvrOT6ym5P EAYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756803833; x=1757408633; 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=iMTZeV1RLqj8sJpYIV/jbQJb4350elWFSvSX2DVPWHc=; b=DzOvwi2cfyLw/YFayNy1bpkGZn2u+xTvedplp0SwyuaIjGwhOXsTH6gBL98kAvhKyf crCuv5CJ2q229Nj/T4mNTpad7VotCJKrceRcYBFoGyDCzl+B5fIoi1RRrWTQfJeMc+EB wZpa4oYeyN+ij3XWRhBX32bPq+RjhwnYfoc48MqWfODec4dz63OvcM5jr3Nyvd+qmHaH z5Nfv/1NE7uE9iadJNetR1L7hWj96rBf0KnvwUYiB18giPIM5r8Nngs5TNdAWrNOK+ZQ k9SHgeRBYVV7kDzncl7LfYFi/qbLetbm8yAeQDNa0JJZpSenWnKL1vXgc5owz+LqlFn1 fyOw== X-Gm-Message-State: AOJu0YyNbPEZYn2snKbjDt86fWB8WK+NrNwYdpV/Lr+xGPJ4VBZMwyal Dw+uiAFEgSzDqs7U0qtEdDHtT+3grYW2oXkGY0WxXYhu2DnpF6w7rEIe3c6j9ruI X-Gm-Gg: ASbGnctfdKy+MTJAxDcnFwd+xkLWnXnl1WY0xSPtuSqvQlbDIpdAJpl56t9kIK6sSVP LYC38YGo/xxt/Qw+sxerXcF+MvZf9Kq7rF/oa7QpVv2d1mxl4G3z5RWkC+2xfT72hBOhIP4mHmK LMU42fz3ibYvGlAY0BVjtG0Tze8ze1To+4deQehCvMY5RGubgesq+Lt7ND5lDkN2mRKPQ/ZuOuq hAUj99l/dPfiXkjKvi4dDE6t9OiZalPgotNzCnpIZuyb3IzfuzvM6UMKsRxYFG/gUdPgKUks32g 8nhAn4r2Pm+2PLrBP6i2fQx45rO/vTNvEKt3UiUkky9HO9/jh3jIugpk1ZnTcKWAq1/XfzD509n Ild53mbV5qdApYgUXuPTX3eTfzZSUGbYNrT2t09tumQt7YLI77fGHdYm0YRrqXA== X-Google-Smtp-Source: AGHT+IEW/uO8bExTCAWVsP75Hs6qPB7WKcfr8U/dDlSXDxKlAstSE0vL7MmDMw/oC+fIWQgrVF1QlQ== X-Received: by 2002:a05:6512:239e:b0:55f:34e8:b1b8 with SMTP id 2adb3069b0e04-55f709b9c2dmr2943696e87.55.1756803832393; Tue, 02 Sep 2025 02:03:52 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Volodymyr Babchuk Subject: [PATCH v13 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests Date: Tue, 2 Sep 2025 12:03:45 +0300 Message-ID: <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.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 Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface, allowing guests to request suspend via the PSCI v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants). Implementation details: - Add SYSTEM_SUSPEND function IDs to PSCI definitions - Trap and handle SYSTEM_SUSPEND in vPSCI - Allow only non-hardware domains to invoke SYSTEM_SUSPEND; return PSCI_NOT_SUPPORTED for the hardware domain to avoid halting the system in hwdom_shutdown() via domain_shutdown - Require all secondary VCPUs of the calling domain to be offline before suspend, as mandated by the PSCI specification The arch_domain_resume() function is an architecture-specific hook that is invoked during domain resume to perform any necessary setup or restoration steps required by the platform. The new vpsci_vcpu_up_prepare() helper is called on the resume path to set up the vCPU context (such as entry point, some system regs and context ID) before resuming a suspended guest. This keeps ARM/vPSCI-specific logic out of common code and avoids intrusive changes to the generic resume flow. 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 Reviewed-by: Volodymyr Babchuk --- Changes in V13: - use __has_include plus static inline function instead of arch_domain_resume stubs Changes in v12: - Use the input vCPU from vpsci_vcpu_up_prepare function argument instead of current. - Add a check for the wake_cpu pointer on resume. - Call arch_domain_resume() under shutdown_lock. - Drop redundant vgic_clear_pending_irqs() call from vpsci_vcpu_up_prepare(). - Cosmetic fixes. Changes in V11: - introduce arch_domain_resume() and vpsci_vcpu_up_prepare(), which are now called on the resume path to avoid extra modifications to common code. The vCPU context is now updated during domain resume. Changes in V10: - small changes to the commit message reflect updates introduced in this version of the patch. - Comments are improved, clarified, and expanded, especially regarding PSCI requirements and context handling. - An ARM-specific helper (domain_resume_nopause_helper) - gprintk() and PRIregister are used for logging in vPSCI code. - An isb() is added before p2m_save_state - The is_64bit_domain check is dropped when masking the upper part of entry point and cid for SMC32 SYSTEM_SUSPEND PSCI calls Changes in V9: - no functional changes - cosmetic chnages after review - enhance commit message and add extra comment to the code after review Changes in V8: - GIC and virtual timer context must be saved when the domain suspends - rework locking - minor changes after code review Changes in V7: - add proper locking - minor changes after code review Changes in V6: - skip execution of ctxt_switch_from for vcpu that is in paused domain - add implementation of domain_resume without domain_pause - add helper function to determine if vcpu is suspended or not - ignore upper 32 bits of argument values when the domain is 64-bit and calls the SMC32 SYSTEM_SUSPEND function - cosmetic changes after review 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/domain.c | 37 ++++++++ xen/arch/arm/include/asm/domain.h | 6 ++ xen/arch/arm/include/asm/perfc_defn.h | 1 + xen/arch/arm/include/asm/psci.h | 2 + xen/arch/arm/include/asm/suspend.h | 18 ++++ xen/arch/arm/include/asm/vpsci.h | 5 +- xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- xen/common/domain.c | 9 ++ xen/include/xen/domain.h | 11 +++ 9 files changed, 183 insertions(+), 22 deletions(-) create mode 100644 xen/arch/arm/include/asm/suspend.h diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 863ae18157..7d7358abe5 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -12,6 +12,8 @@ #include #include +#include + #include #include #include @@ -27,6 +29,7 @@ #include #include #include +#include #include #include "vpci.h" @@ -880,6 +883,40 @@ void arch_domain_creation_finished(struct domain *d) p2m_domain_creation_finished(d); } +int arch_domain_resume(struct domain *d) +{ + int rc; + typeof(d->arch.resume_ctx) *ctx = &d->arch.resume_ctx; + + if ( !d->is_shutting_down || d->shutdown_code != SHUTDOWN_suspend ) + { + dprintk(XENLOG_WARNING, + "%pd: Invalid domain state for resume: is_shutting_down=%d, shutdown_code=%d\n", + d, d->is_shutting_down, d->shutdown_code); + return -EINVAL; + } + + /* + * It is still possible to call domain_shutdown() with a suspend reason + * via some hypercalls, such as SCHEDOP_shutdown or SCHEDOP_remote_shutdown. + * In these cases, the resume context will be empty. + * This is not expected to cause any issues, so we just warn about the + * situation and return without error, allowing the existing logic to + * proceed as expected. + */ + if ( !ctx->wake_cpu ) + { + dprintk(XENLOG_WARNING, "%pd: Invalid wake CPU pointer for resume\n", + d); + return 0; + } + + rc = vpsci_vcpu_up_prepare(ctx->wake_cpu , ctx->ep, ctx->cid); + memset(ctx, 0, sizeof(*ctx)); + + return rc; +} + static int is_guest_pv32_psr(uint32_t psr) { switch (psr & PSR_MODE_MASK) diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index a3487ca713..68185fc4d6 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -121,6 +121,12 @@ struct arch_domain void *tee; #endif + struct resume_info { + register_t ep; + register_t cid; + struct vcpu *wake_cpu; + } resume_ctx; + } __cacheline_aligned; struct arch_vcpu 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/suspend.h b/xen/arch/arm/include/asm/suspend.h new file mode 100644 index 0000000000..c8ea84bd40 --- /dev/null +++ b/xen/arch/arm/include/asm/suspend.h @@ -0,0 +1,18 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __ASM_ARM_SUSPEND_H__ +#define __ASM_ARM_SUSPEND_H__ + +int arch_domain_resume(struct domain *d); + +#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/include/asm/vpsci.h b/xen/arch/arm/include/asm/vpsci.h index 0cca5e6830..d790ab3715 100644 --- a/xen/arch/arm/include/asm/vpsci.h +++ b/xen/arch/arm/include/asm/vpsci.h @@ -23,12 +23,15 @@ #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); bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid); +int vpsci_vcpu_up_prepare(struct vcpu *v, register_t entry_point, + register_t context_id); + #endif /* __ASM_VPSCI_H__ */ /* diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c index 7ba9ccd94b..22c3a5f544 100644 --- a/xen/arch/arm/vpsci.c +++ b/xen/arch/arm/vpsci.c @@ -10,32 +10,16 @@ #include -static int do_common_cpu_on(register_t target_cpu, register_t entry_point, - register_t context_id) +int vpsci_vcpu_up_prepare(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; + struct domain *d = v->domain; 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; + struct vcpu_guest_context *ctxt; if ( (ctxt = alloc_vcpu_guest_context()) == NULL ) - return PSCI_DENIED; - - vgic_clear_pending_irqs(v); + return -ENOMEM; memset(ctxt, 0, sizeof(*ctxt)); ctxt->user_regs.pc64 = (u64) entry_point; @@ -76,8 +60,37 @@ static int do_common_cpu_on(register_t target_cpu, register_t entry_point, free_vcpu_guest_context(ctxt); if ( rc < 0 ) + return rc; + + return 0; +} + +static int do_common_cpu_on(register_t target_cpu, register_t entry_point, + register_t context_id) +{ + struct vcpu *v; + struct domain *d = current->domain; + 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; + + rc = vpsci_vcpu_up_prepare(v, entry_point, context_id); + if ( rc ) return PSCI_DENIED; + vgic_clear_pending_irqs(v); vcpu_wake(v); return PSCI_SUCCESS; @@ -197,6 +210,48 @@ static void do_psci_0_2_system_reset(void) domain_shutdown(d,SHUTDOWN_reboot); } +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) +{ + int32_t rc; + struct vcpu *v; + struct domain *d = current->domain; + bool is_thumb = epoint & 1; + + /* THUMB set is not allowed with 64-bit domain */ + if ( is_64bit_domain(d) && is_thumb ) + return PSCI_INVALID_ADDRESS; + + /* SYSTEM_SUSPEND is not supported for the hardware domain yet */ + if ( is_hardware_domain(d) ) + return PSCI_NOT_SUPPORTED; + + /* Ensure that all CPUs other than the calling one are offline */ + domain_lock(d); + for_each_vcpu ( d, v ) + { + if ( v != current && is_vcpu_online(v) ) + { + domain_unlock(d); + return PSCI_DENIED; + } + } + domain_unlock(d); + + rc = domain_shutdown(d, SHUTDOWN_suspend); + if ( rc ) + return PSCI_DENIED; + + d->arch.resume_ctx.ep = epoint; + d->arch.resume_ctx.cid = cid; + d->arch.resume_ctx.wake_cpu = current; + + gprintk(XENLOG_DEBUG, + "SYSTEM_SUSPEND requested, epoint=0x%"PRIregister", cid=0x%"PRIregister"\n", + epoint, cid); + + return rc; +} + static int32_t do_psci_1_0_features(uint32_t psci_func_id) { /* /!\ Ordered by function ID and not name */ @@ -214,6 +269,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 +401,23 @@ 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); + + if ( fid == PSCI_1_0_FN32_SYSTEM_SUSPEND ) + { + epoint &= GENMASK(31, 0); + cid &= GENMASK(31, 0); + } + + perfc_incr(vpsci_system_suspend); + PSCI_SET_RESULT(regs, do_psci_1_0_system_suspend(epoint, cid)); + return true; + } + default: return false; } diff --git a/xen/common/domain.c b/xen/common/domain.c index 104e917f07..667017c5e1 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1352,6 +1352,7 @@ int domain_shutdown(struct domain *d, u8 reason) void domain_resume(struct domain *d) { struct vcpu *v; + int rc; /* * Some code paths assume that shutdown status does not get reset under @@ -1361,6 +1362,13 @@ void domain_resume(struct domain *d) spin_lock(&d->shutdown_lock); + rc = arch_domain_resume(d); + if ( rc ) + { + printk("%pd: Failed to resume domain (ret %d)\n", d, rc); + goto fail; + } + d->is_shutting_down = d->is_shut_down = 0; d->shutdown_code = SHUTDOWN_CODE_INVALID; @@ -1371,6 +1379,7 @@ void domain_resume(struct domain *d) v->paused_for_shutdown = 0; } + fail: spin_unlock(&d->shutdown_lock); domain_unpause(d); diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index e10baf2615..63b81f8fba 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -8,6 +8,10 @@ #include +#if __has_include() +#include +#endif + struct guest_area { struct page_info *pg; void *map; @@ -109,6 +113,13 @@ int arch_domain_soft_reset(struct domain *d); void arch_domain_creation_finished(struct domain *d); +#if !__has_include() +static inline int arch_domain_resume(struct domain *d) +{ + return 0; +} +#endif /* !__has_include() */ + void arch_p2m_set_access_required(struct domain *d, bool access_required); int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:04:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:04:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105848.1456669 (Exim 4.92) (envelope-from ) id 1utMvl-0000Fb-AF; Tue, 02 Sep 2025 09:03:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105848.1456669; Tue, 02 Sep 2025 09: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 1utMvl-0000FU-7F; Tue, 02 Sep 2025 09:03:57 +0000 Received: by outflank-mailman (input) for mailman id 1105848; Tue, 02 Sep 2025 09:03: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 1utMvk-0000FD-4y for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:03:56 +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 bf157b78-87db-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 11:03:52 +0200 (CEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55f6e0eed29so2657689e87.3 for ; Tue, 02 Sep 2025 02:03:52 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-560827aabf5sm524019e87.137.2025.09.02.02.03.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 02:03: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: bf157b78-87db-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756803831; x=1757408631; 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=mg1UFQy8b4+Jl9em9JGkjavl7PzPMrHRsrQ0Kx7AK2g=; b=gIUBXGttowOXKOprZTrglvN9qYzywZUIE+Kj6CsruKJf6WcUsyOCIPodimAIdIbqLS EjmbYRqozUaKejuTjkNBtrQ6H6iXrdm/QgeQuX+lvQga/6xZPbl8qc1T1BpT5Df8elvD vRmu6ZaK8lL+dLP2rSb6dGo/SQSkVkjYfF76kPSiECqPDqwEa74kq2uaIk/z+07ZiwB9 IFFFVpwL/Zg6lPKqnUDspMD0fYwzs4WhjPxf1azt3TCiNoV8EUiyEuuchtOpuE7aiH2V jqWMOQAAQ5VheHuBC4iHbPIaSoGf27j1Qgn/lK/tSMxh+JSA+6/gEnU3QPVkgg2Gs2J9 eAsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756803831; x=1757408631; 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=mg1UFQy8b4+Jl9em9JGkjavl7PzPMrHRsrQ0Kx7AK2g=; b=KjjPFRNqPbJM+IHLYWxKR1ZVolqAnsWvb/oDgtdiZtQKFcy9sqlgA6Zv0gQ/19Q3J5 cU+GrTngt6l4CbMS7YgxoS4ickHhKXRYzrsfq2ihl09VYptff5f3HdBWCdnNAWosKnN3 WMkRiiCy8C78+TGQH902sadNmTNJZQ98TSzkcs6yLUrOF9aOo5d8oM1zj3r8B4Gjxo3Y 0EHqaMPvj2wWyWzfUGAsFz0f+1uj0id4WtZN56flphOea1doPr2ipfooMeYMgSPconq9 VlHGtxNmhvxYEC3KbU7SWAL5a0aq9AIZiwBfEDa0Zn7eV5wyr74z7f/5+G6thQsxOlcN 6YBg== X-Gm-Message-State: AOJu0YxxfZVeYwJjGOURySYAbpqiJwtgBHn8mP1H/XOvNpGL/G06yx2L 9MFvnmMHK7Rts8F5GJx1kD2mB/MoT0K1/irq6KJuysD1T5ZxrwIS5ExJEFm25xQY X-Gm-Gg: ASbGnct0HcGXtDaKtWZhYLqpBz7IAFfzbgs5k5IgOyeErbbodBGH616j3NGgT1f4RUe mTDfTsSidoC7aO9gvvfPoXuKimF5rai+I+RKKArsQ12UfrXleLauFu+hru3/O0LwjF36gvK3udo 3s0YSG4Swt26WHe+YXjpMWa0bOkUIOm07YxYUQZRiIb6J6LGF92py1bJl0nZz3hGQrl9p9TFY4T ifDrKia9w+lV2g1sp/EgfS1Jshz1IRibIOUnIefii5KyKbrGjeFEghTZ0uuTPHHF1ncIRTeBUXT tX/hzg8GxqZdUYKBAA5XrUEALfmOGT0W/KtlLuTj9koVxJajdwjvwtL/ZfP4jnnoWrAzIjywR4j LcnRRhq/z4yeLetDRQ3ZSy5xX3hPo4IWSWCM/j8Ty09AYX0t2V0X9c5fuebvAfcd9LzRyxXZr X-Google-Smtp-Source: AGHT+IE//cHmWTkVqedXGgDeK8sxQBuWl7s9c0VP6A9ciaBmwpc4OyWf+D0ng4OnkDvmYmQ/vQ365g== X-Received: by 2002:a05:6512:6398:b0:55f:6a38:f6c0 with SMTP id 2adb3069b0e04-55f709c0be8mr2454788e87.42.1756803831093; Tue, 02 Sep 2025 02:03:51 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross , Oleksii Kurochko , Community Manager Subject: [PATCH v13 0/4] Enable guest suspend/resume support on ARM via vPSCI Date: Tue, 2 Sep 2025 12:03:44 +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). --- This is the first part of previous patch series and originally consist only with necessary changes needed for guest domain suspend. The second part can be found here: https://patchew.org/Xen/cover.1756763487.git.mykola._5Fkvach@epam.com/ --- Changes in v12: - Use the input vCPU from vpsci_vcpu_up_prepare function argument instead of current. - Add a check for the wake_cpu pointer on resume. - Call arch_domain_resume() under shutdown_lock. - Drop redundant vgic_clear_pending_irqs() call from vpsci_vcpu_up_prepare(). Changes in V11: - introduce arch_domain_resume() and vpsci_vcpu_up_prepare(), which are now called on the resume path to avoid extra modifications to common code. The vCPU context is now updated during domain resume. Changes in V10: - An ARM-specific helper (domain_resume_nopause_helper) - An isb() is added before p2m_save_state - The is_64bit_domain check is dropped when masking the upper part of entry point and cid for SMC32 SYSTEM_SUSPEND PSCI calls - Status of vPSCI SYSTEM_SUSPEND changed from "Experimental" to "Tech Preview" Changes in V9: - no functional changes - enhance commit message and add extra comment to the code after review Changes in V8: - GIC and virtual timer context saved when the domain suspends - rework locking - minor changes after code review Changes in V7: - add proper locking - minor changes after code review Main changes in V6: - Skip execution of ctxt_switch_from for VCPUs in paused domains. - Implement domain_resume_nopause - Add a helper to determine if a VCPU is in suspended domain. - Ignore upper 32 bits of arguments for 64-bit domains calling SMC32 SYSTEM_SUSPEND. - Macro renamed from LIBXL_HAVE_NO_SUSPEND_RESUME to LIBXL_HAVE_NO_SUSPEND for clarity. - Documentation now focuses only on the SYSTEM_SUSPEND function, with improved wording and structure. - Changelog and commit messages refined for clarity and to remove redundant explanations. 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. 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 Mykola Kvach (4): xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests tools/xl: Allow compilation of 'xl resume' command on Arm SUPPORT.md: Document PSCI SYSTEM_SUSPEND support for guests CHANGELOG: Document guest suspend/resume to RAM support on Arm CHANGELOG.md | 2 + SUPPORT.md | 5 +- tools/include/libxl.h | 1 - tools/xl/xl.h | 4 +- tools/xl/xl_cmdtable.c | 4 +- tools/xl/xl_migrate.c | 2 +- tools/xl/xl_saverestore.c | 2 +- tools/xl/xl_vmcontrol.c | 12 +-- xen/arch/arm/domain.c | 37 ++++++++ xen/arch/arm/include/asm/domain.h | 6 ++ xen/arch/arm/include/asm/perfc_defn.h | 1 + xen/arch/arm/include/asm/psci.h | 2 + xen/arch/arm/include/asm/suspend.h | 18 ++++ xen/arch/arm/include/asm/vpsci.h | 5 +- xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- xen/common/domain.c | 9 ++ xen/include/xen/domain.h | 11 +++ 17 files changed, 200 insertions(+), 37 deletions(-) create mode 100644 xen/arch/arm/include/asm/suspend.h -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:04:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:04:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105850.1456689 (Exim 4.92) (envelope-from ) id 1utMvm-0000hM-RD; Tue, 02 Sep 2025 09:03:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105850.1456689; Tue, 02 Sep 2025 09: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 1utMvm-0000hF-Ng; Tue, 02 Sep 2025 09:03:58 +0000 Received: by outflank-mailman (input) for mailman id 1105850; Tue, 02 Sep 2025 09:03: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 1utMvk-0000FD-Pp for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:03:56 +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 c0ef90bc-87db-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 11:03:55 +0200 (CEST) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-55f7c0fb972so1927606e87.3 for ; Tue, 02 Sep 2025 02:03:55 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-560827aabf5sm524019e87.137.2025.09.02.02.03.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 02:03: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: c0ef90bc-87db-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756803834; x=1757408634; darn=lists.xenproject.org; h=content-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=Xe9xi3DaBptNnLW1VEAJiUhAp27nm19FtXNKIdaX+1M=; b=dUL+aX5qWSZNxFaHkRwM5RoMixoEbY9aAmIg18v57t7A1EVRjEWvnZ4AjSwunaiisp JULIoYOv/TGfcFANWe4Blc/sVPv2I6EoJS9LbZdoHcENy1kT4NIukxB3IA6GmO1xRSCn Fr6oOQKbq9L3TzMvvXYow0kuLBGfEkEonRvqa+iI7ZRfpwNt8qnW7WygKXxIuK6iCaoi y3S64km5zL5+BXF1hmwJ0AonUid6oPTjjltgJzsLfnEFsJSwBszSTfQ7mSWPC4pM/CbI zN4MZLikh6JoV2s54/g/F28mj5R3VIN8/prMfkO/jKGmFOJfwRxh0w260cdrC9dcmtH2 Srmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756803834; x=1757408634; 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=Xe9xi3DaBptNnLW1VEAJiUhAp27nm19FtXNKIdaX+1M=; b=RXj3rcckjFrWnmfxc/iCA0mFawvAYJPW6UpUMcsdJ5EGLESh4E01sJu5H5JHilELeQ rxINy4tToFhHu4mFPg4o4Q1kHAXDtF0CDluLqRyVP6QVKkafOTpVto3S4HRg+LtO/3nJ jerY+MRP0UqfjUHjxn243wLy4EAGaq/rp1RcRiLjDiezfpzZmAOConrps9exT28MOcnW OIzFehifD7V9lgY4V2QILxYOpqN+F65i9ZLMJFkXbtts+XoBjNVogko7m8tgBdZl/SeS JDoX11Udj7Nej0e9cIqfFEXhYWIR6pFaI3VhkU5iTu03Q8iEC5wcaMycQ4h6KevvKife N2hw== X-Gm-Message-State: AOJu0YyzGXM6IIiyP3iivgV8YEK8VJroT/lnRmXCKSYrx9CBnzd7/IC7 0U/XQRDYCSta1f8FxyHC28bm+37MxpOKEN8QxHw24HI66Y0THVqqqOh6GHx5VLMq X-Gm-Gg: ASbGncuMmzVY8G4M8JMGFW9dkzugjEfflxUI5efqgAJ1SgFdFWXq9RReUFDRVB4uimc 5PB7tKd13uEsmgeERURJ+HfYjAxqFYEVE5PPmFwCuWD5bdbVpGIEI1qlpElEBTHPU9waN/MEd+M OlB8bhHKlupKb5qhi0plSYxL5i6e0o4Ev56p/gzsHJgAg0tguzFyP4dcJd2KQOuJrU0yCfiegky y/rfrdqr4cuDqbQssJq3QQ0vS2sSrQZPthbsL+EydjkC0L1fBdfzp3t54eZYDtHpKW1bZp/swFg SRvZVb+Jp70wUk5yiE04mCFuge1AvahHWgAHDo32AQ5LjkIp11dY/eHY+fCzV3TlLsUyxt8NEbM BL4NQb9rj0nWS9/6WnrVqhxT0+7R3RWvrWfZSzpt3wuJ/57fSPFN4UlAkpgGRyvukTsPXhaSv X-Google-Smtp-Source: AGHT+IHNUanPnwKzxrXpPti+ujHJgeQYiDpY8lmWUWwQAx5lCpBYMktXUYgjBdwMwKKiXPGz921lJA== X-Received: by 2002:a05:6512:12c9:b0:55f:5428:eb72 with SMTP id 2adb3069b0e04-55f708ec77fmr2907330e87.35.1756803834283; Tue, 02 Sep 2025 02:03:54 -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 v13 3/4] SUPPORT.md: Document PSCI SYSTEM_SUSPEND support for guests Date: Tue, 2 Sep 2025 12:03:47 +0300 Message-ID: <9dffe19e3ba29020a8f35c0fcf12f088de6b9eea.1756803419.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 Add a new entry under the "Virtual Hardware, QEMU" section documenting support for the optional PSCI SYSTEM_SUSPEND function exposed to guests. This function is available via the virtual PSCI (vPSCI) interface and allows guest domains (domUs) to initiate system suspend operations. The feature is currently marked as "Tech Preview". Signed-off-by: Mykola Kvach --- Changes in V10: - Status of vPSCI SYSTEM_SUSPEND changed from "Experimental" to "Tech Preview" Changes in v6: - Dropped the generic guest PSCI support entry (merged in a separate patch) - This patch now documents only the SYSTEM_SUSPEND optional function - Reworded commit message to match the final form after rebase 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 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index 6a82a92189..0ce0903cb1 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -962,8 +962,9 @@ 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. - Status, Mandatory: Supported - Status, MIGRATE_INFO_TYPE: Supported + Status, Mandatory: Supported + Status, MIGRATE_INFO_TYPE: Supported + Status, SYSTEM_SUSPEND: Tech Preview ## Virtual Hardware, QEMU -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:04:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:04:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105851.1456699 (Exim 4.92) (envelope-from ) id 1utMvo-0000w4-30; Tue, 02 Sep 2025 09:04:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105851.1456699; Tue, 02 Sep 2025 09: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 1utMvn-0000vu-VO; Tue, 02 Sep 2025 09:03:59 +0000 Received: by outflank-mailman (input) for mailman id 1105851; Tue, 02 Sep 2025 09:03:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utMvm-0000FE-Ef for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:03: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 c1d77575-87db-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:03:56 +0200 (CEST) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-55f78e3cdf9so2564900e87.1 for ; Tue, 02 Sep 2025 02:03:56 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-560827aabf5sm524019e87.137.2025.09.02.02.03.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 02:03: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: c1d77575-87db-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756803836; x=1757408636; darn=lists.xenproject.org; h=content-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=hngrpYued6VRjNdXSCXsejFnZ9+NvVTFmNBYrfCV2Ms=; b=Dt37LKb5Rp5PCjx+5YgLP99BEMwk83BXN/4N2GhrZNooVM2nYxIPN+791CPP526JQq 5KDL92vf/kdISxdwz3gnh4qs7I9tcVpc8aT7FwaepTs42yNqOswASv4paf/ThEwpGsn4 KnMuqG3TtWGx5UdLociaC0eAUrJZRdCVIpwHnoCmVT2Np2UzQUkuDfh8xEwQuTkSjWoh W9+YEeNJfXHz9D11+qMd9Hrs+8Q9fDGtzptnpIyeme6pLG0aY8tavOmxR7oqG7qVo+YT POt5AKk0sbk+Q5kScm54a96S0TBSVBi67OZqO9MR687qbetWjo3e7zd60ThTwSnz1K3s /h/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756803836; x=1757408636; 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=hngrpYued6VRjNdXSCXsejFnZ9+NvVTFmNBYrfCV2Ms=; b=nv/gpr+42NrkSyQ9J3j0kiBSasZQDLee2VVbIUOJrRwnB9S4+nURpZOV9yldyRIJ1l y+v9BO2lCzaloJZIvJpGs/st6LCQQIe1nlX6d+dHnapnXxBIyFez4Pe56tZWPqBurf7E QXbLTJJhMZ7ah+phVgtteeosuf4WZnCN7x9Fybk0MUslzePAuqkGOICOSHDX4flHUZmt hiIrR8tm5cPa6KCxWluwzL9wq97M3QssGyAjWDMxAq7kIcaidgoaIlfJfcNaYm5NOUrf Akl65SDDkFkDll3dpPGtXAGwn3D1MZEm9EjoXPlCQ5knQUnsqorv0KOq2XntEgdah9cl NVNg== X-Gm-Message-State: AOJu0YwxsquG8hxBLq97rbqXEaYVX3JrxC1OQaix2UJz/7czlDiHireQ OUwfULPgY7ODHet6PerRxmXmWMN1RZmdFKd74PV4y4a+RWJn6becrdwQxDTsOgSc X-Gm-Gg: ASbGnctjYOD//K4IfzzOmjE276B1LMpIddWRk24QMQLSb+xUz2X13wNImppaQCRE/lx 97+4AEe4adUESKSPCz9xJ2K0QmpvUFUqLXjMf6oEYdfkrDLCwCODm2FTzxxC6mgK/CP0j2BP1v0 X/7Qb+yQDm7BxpR2Xp2hanQSHZY7HlzaIWRAQCikmUkBfq1AqdLvtfuoKE73lhUQeugth86xTjf 8vW2M+igUeP/CMeG2nCQAW+rZpT6/PIYjK4+3iLDmJe4pL8qQFNgbWZcyu44tjB/drD2rKV9s8p 3c1FulD3FM+RWkwwLuoNclI3xHjifU3m4Cd2ZDaiC1ha6Alzu2MH6tWwCfPif/2dNl0Znhhh++M G/PUTYP4TBNMbd5IuZ6WbXwIuUNPh+hcPozxYCx5Z2NX4cIi0WzVbd6U6HQpYRkhXSg45q7Zi X-Google-Smtp-Source: AGHT+IEGDR0zvIgC8giLGGenf6ffDNeOkUoGx5o3gXyi/iwQLHqrZHPK8kf1eGYeTBmfAMeKuFRvEg== X-Received: by 2002:a05:6512:4045:10b0:55f:71ad:5913 with SMTP id 2adb3069b0e04-55f71ad6048mr2708786e87.50.1756803835517; Tue, 02 Sep 2025 02:03:55 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Oleksii Kurochko , Community Manager Subject: [PATCH v13 4/4] CHANGELOG: Document guest suspend/resume to RAM support on Arm Date: Tue, 2 Sep 2025 12:03:48 +0300 Message-ID: <2b9c5acca22150548c122a851931304c5d1ec565.1756803419.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 Mention the newly added support for guest suspend and resume to/from RAM via vPSCI on Arm platforms. This support is limited to non-hardware domain guests. Signed-off-by: Mykola Kvach Acked-by: Oleksii Kurochko --- Chnages in v6: - removed reduntand explanation that thi support added for both arm32 and arm64. 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 cd34ea87b8..7a75bd37cb 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -36,6 +36,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. + Applies only to non-hardware domain guests. ### Removed - On x86: -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:04:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:04:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105852.1456709 (Exim 4.92) (envelope-from ) id 1utMvq-0001DK-Bb; Tue, 02 Sep 2025 09:04:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105852.1456709; Tue, 02 Sep 2025 09:04: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 1utMvq-0001D3-8X; Tue, 02 Sep 2025 09:04:02 +0000 Received: by outflank-mailman (input) for mailman id 1105852; Tue, 02 Sep 2025 09:04: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 1utMvo-0000FE-RS for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:04:00 +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 c036c170-87db-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:03:54 +0200 (CEST) Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-336bbcebca9so27128181fa.1 for ; Tue, 02 Sep 2025 02:03:54 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-560827aabf5sm524019e87.137.2025.09.02.02.03.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 02:03: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: c036c170-87db-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756803833; x=1757408633; darn=lists.xenproject.org; h=content-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=iKQtb2yDXXgVIM20M/9ZKDqMqVSaENj70H3OApwPWOA=; b=Mrw+WBgRuEPBe/fKIgym6g029AmtebPFYdTWgpyryjuY7ONrd1nqBN1gAz7kxCfZMf 95VxTGF2bdac1EWNKGlZklXMSn4vRnPQ2TeBeAPYMwLHu2yITF9kPgUM94fbc8rrEETq NfPUDskod38zj0/cEZEm4dtZk9IlKVdgnIK2F/rYA4rfgmwwlUKzCPcaAtIJNDgsSpxO N51TLV+8HLTFg+ZovxgbcO/kmz1Rxh/affSmh5WYrapUlYnrLgDl/h0PEicdU7IaXRgW kvNlnPEZGiP26gLs5w0avRVy+QWrBobkeCTSHitsjDQHp3WrRHXAxpI3muV7DGUmGmZW Ro5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756803833; x=1757408633; 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=iKQtb2yDXXgVIM20M/9ZKDqMqVSaENj70H3OApwPWOA=; b=CmnIhyyyPYnx7ki7LvnLxbRC3Si+V8z0zvqKCg5jJJeQqQK36cMutPSlH2h8EItD1p 8/8NOcloseQSZlU3enQg8XtatiyW0FQlF2Xxj2QxD2wulgBuGGMUg2PX9JJABV4Fq8GN VQv6fBq5AaapF16t60OEN4dYhtU4Shz35xjk7KA5vPNngdmGAc5sha74+rqsi+LsKgv5 W5tOGaPXyBgt+LySeJYjHT1bMy7hj5wPMqvIJt7UXSotLKb6XYnQyoWyrqdN45GusHxE bKAFKkz6RN30FG5Dh3wp0j2bAnfYkWnTqxSKjMEKgN6sNMMGtAUFgaTQSmH2ZxQd1xEX Wp/A== X-Gm-Message-State: AOJu0Yw82+HvFvbPmihKq2jTHxEemZDj7k1OGyZMm5cc2U0wzuHVY2Qt h4vDTLBECRHQ0Uha1KdX5bNefLIEYQWotZSeoti9YoxGxiQn5AOuqQTrihw3oApv X-Gm-Gg: ASbGncus30o4RK1RXUu9p29A8dNT+fer/rjTCl2nT8n/5X2XDXu5SH2ZXwUAsO9fbS2 kAovmeihLneoLQC2n9xvAUChImb6QFYTYinKzp9UgsOf2a3raNyBM/Ohqb4AU+U/08vwODlpPvt UYfvIx+0NVyd2E+fuWNNUbBKW3N65gRh+RFgxrwf3vTWbHhI0aQKiOIqSPjDM6nHRAuBkBjWs7v vHA6hMU2oykNQkmqfhPf4sBmUexy0TEra4uuMMQL2yMGlaLoU/95/Zbt/Nl2zT9aZPy78GElQVn V72IEGpgE4XvN8S7MmaljeAzGJJMNGZXxveeSiMNkwhdJXcP9Tsq0zGOWwoOW6bHkEi6bGb63J6 d6WUuovB1a2fYuxcMNGNWsv9TI94MHL4HpTe7r3BY+GZS5/kVWiS3y5hWvpV1dQ== X-Google-Smtp-Source: AGHT+IHWIeHHjMI4/q8ByA7QG0siSIFWtMD4pXqXFl9/kNEueqD20PIykgcXRmt500riGkhpKcKNMw== X-Received: by 2002:a05:651c:150b:b0:336:e0b3:235a with SMTP id 38308e7fff4ca-336e0b33082mr22657221fa.8.1756803833160; Tue, 02 Sep 2025 02:03:53 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Anthony PERARD , Juergen Gross Subject: [PATCH v13 2/4] tools/xl: Allow compilation of 'xl resume' command on Arm Date: Tue, 2 Sep 2025 12:03:46 +0300 Message-ID: <6553b10eb258b6f3a481d70d535731b397607c75.1756803419.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, this command is used for resume. This change enables compilation of `xl resume` on Arm regardless of the underlying implementation status, making the tool available for testing and future feature support. The relevant libxl infrastructure and handler functions are already present and usable. Note: This does not imply full system suspend/resume support on Arm. The `xl suspend` command still does not work on Arm platforms. Signed-off-by: Mykola Kvach Acked-by: Anthony PERARD --- Changes in v7: - dropped renaming of LIBXL_HAVE_NO_SUSPEND_RESUME macro Changes in v6: - Renamed macro from LIBXL_HAVE_NO_SUSPEND_RESUME to LIBXL_HAVE_NO_SUSPEND to better reflect the scope of this change - Applied cosmetic changes based on review feedback --- tools/include/libxl.h | 1 - tools/xl/xl.h | 4 ++-- tools/xl/xl_cmdtable.c | 4 ++-- tools/xl/xl_migrate.c | 2 +- tools/xl/xl_saverestore.c | 2 +- tools/xl/xl_vmcontrol.c | 12 ++++++------ 6 files changed, 12 insertions(+), 13 deletions(-) diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 185f74d8a8..b204fc5e2e 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -1140,7 +1140,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..9233b73f85 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -65,7 +65,7 @@ static const char migrate_permission_to_go[]= "domain is yours, you are cleared to unpause"; static const char migrate_report[]= "my copy unpause results are as follows"; -#endif +#endif /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ /* followed by one byte: * 0: everything went well, domain is running @@ -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); +#endif /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ int main_resume(int argc, char **argv); -#endif 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..bcb2d233cc 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 /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ { "resume", &main_resume, 0, 1, "Resume a domain from RAM", "", }, -#endif { "dump-core", &main_dump_core, 0, 1, "Core dump a domain", @@ -548,7 +548,7 @@ const struct cmd_spec cmd_table[] = { " checkpoint must be disabled.\n" "-p Use COLO userspace proxy." }, -#endif +#endif /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ { "devd", &main_devd, 0, 1, "Daemon that listens for devices and launches backends", diff --git a/tools/xl/xl_migrate.c b/tools/xl/xl_migrate.c index b8594f44a5..4b4a379aa1 100644 --- a/tools/xl/xl_migrate.c +++ b/tools/xl/xl_migrate.c @@ -767,7 +767,7 @@ int main_remus(int argc, char **argv) close(send_fd); return EXIT_FAILURE; } -#endif +#endif /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ /* diff --git a/tools/xl/xl_saverestore.c b/tools/xl/xl_saverestore.c index 953d791d1a..747094ec7b 100644 --- a/tools/xl/xl_saverestore.c +++ b/tools/xl/xl_saverestore.c @@ -270,7 +270,7 @@ int main_save(int argc, char **argv) return EXIT_SUCCESS; } -#endif /* LIBXL_HAVE_NO_SUSPEND_RESUME */ +#endif /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index c813732838..93766f631b 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 /* !LIBXL_HAVE_NO_SUSPEND_RESUME */ + +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 Tue Sep 02 09:28:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:28:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105907.1456719 (Exim 4.92) (envelope-from ) id 1utNIr-0005O0-3j; Tue, 02 Sep 2025 09:27:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105907.1456719; Tue, 02 Sep 2025 09:27: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 1utNIr-0005Nt-15; Tue, 02 Sep 2025 09:27:49 +0000 Received: by outflank-mailman (input) for mailman id 1105907; Tue, 02 Sep 2025 09: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 1utNIp-0005Nn-Mx for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:27:47 +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 1525d984-87df-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:27:45 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-afec56519c8so850961066b.2 for ; Tue, 02 Sep 2025 02:27: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 a640c23a62f3a-b04323984ffsm387513866b.64.2025.09.02.02.27.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 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: 1525d984-87df-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756805265; x=1757410065; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=X97cz4NWfnz3pesE7r7aRVYydzyNmT9gdbV9HvKfhDs=; b=H1WL8wD4Y8BjRJfOwxbqlqqXR0luQ0GyY2Q0Y5Rb+GAMEkHy7PyM/FNEkhlniUAIm6 aNjqN7R7WdC7Zoz+DyURd8HrkQ/kpEDLed9lJSRLr/175MabydjfPQt79oOsdBrCmtyS hGhmDIgy220JpIP0OXuZbclAZbZuBS8E54vaeQJkPikKG3+yif6vX6/dksE2W58H1/Jd +V8zRb4bmBTQSJyPtc9YVPTnkLZ0f4RxjC90LfkXu2KFlC6vcmcQGbE9nTw97ekXucTZ GtsUiUKOy4hNoY5st/tlCBq1ZDKk92n/TLKVhsjQll9fy0hwhIsSU9qWl1awbCsFvMsq I4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756805265; x=1757410065; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X97cz4NWfnz3pesE7r7aRVYydzyNmT9gdbV9HvKfhDs=; b=tOd5SfU97qHCC7mgeyZmFfzo9rL4y1mD7qxwIJyqscS7sPcR63ltaPzpi3ICDyq0xc JjWa3wzgC0dHx2h5u6XLfBkdhvcU4LAy1Is4pJUItuUgvWgt+2FbV28qjln21/H0nrSB +sBfEz1XWHFzIl1cgDtu2ntVPnxYVJLzqbphvzygRIDgVypH9tbu3srTlft+0Q65DkTH jkecJMyo3W1Ch7xsZplyuNHFsksmAWt8Z2vOwRhO5kCN3fUlniflwRIQIr89InofUwCL BkTQaQ1on3fObtm2spLL72Kif8YfnnC6H5TLlm2FmqnE1DmJfYpGEBXJ3QG/Esw+dfqK NLpw== X-Forwarded-Encrypted: i=1; AJvYcCVUksSvxCYHZUHHI0VUCrJvSm9VtArtXuADtKEawzYIPmL/JVRt+YKULUKqcs5eWrUvj70f7HgzRCs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx7DnA5qWcQTN+AmstixStavk2dR12/n8Rw/j9pVyouFf/QY3HW p7JIJYUeQYGS5XwEKsTbGu65n4tp6B64l6ATdyrnFe8rdtHM8jklmxSHuwadBd+9mw== X-Gm-Gg: ASbGncvVGrMypUg+MOLEF7VF6TysnOHWD+bjsgl16BzETJkHEZ9WDCuRzhKAyY+UxPE NCu4eiiYjKCGjs3LMCQQFLvCccQTnTi9yMgdqIOUP+6lK9GHj9fqbRc5L3JJPEat6zktoAWEGkm U3kV5U+GHXyu6LrkXaPsAnCSF9gC0JZB/xoNdc0+x0FqXMuhL6AGnxM5hTyF2ocLbfhI2QEnNAD lV0yDsZZ91FSTlaeQVOHLuItSQEIjsQfUDRsJJ+TmZWAbHt0Hl7a8oPUEPvPvPO8JhvNcQeZOTt v4NLxkxMOliNd39x9kh7TcsCZVHOElxgQWfQV8WXhq9wGjHn2+YNb0AZ7GgPYPMExSnFVut3oXh HCXqY6oy990ycfKzINt4+e0Kgemh3B5jzry1NRsFWeGOTIJjzwEduBNcQmrV/FMjhyI7FLsJkuC REBT4yBPM= X-Google-Smtp-Source: AGHT+IErc2bc7GNzVsMWnH4iTDE8EOQuQzEuefu/ThOJKNtF1lSCtuukiijMdl3t64rdNSL/zadwag== X-Received: by 2002:a17:907:7fa0:b0:b04:3a9c:33ac with SMTP id a640c23a62f3a-b043a9c3bb5mr474653566b.50.1756805264642; Tue, 02 Sep 2025 02:27:44 -0700 (PDT) Message-ID: <69a2cf29-2c87-45a6-9b27-dc5332e28c16@suse.com> Date: Tue, 2 Sep 2025 11:27:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Mykola Kvach Cc: Mykola Kvach , 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: <244e5c2bcebad9563595ac7564ffa105d5f568d3.1756586648.git.mykola_kvach@epam.com> <80c8dbfe-5240-441d-84fc-603e9c5f9812@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.09.2025 10:42, Mykola Kvach wrote: > Since the current codebase already uses this approach in multiple places, > contributors may get mixed signals when similar patterns are sometimes > accepted and sometimes discouraged. Clearer project-wide guidance, or even > small clarifications in coding style, would make it easier for contributors > to align with maintainers’ expectations. > > I will adjust my patch accordingly and use has_include as you suggested. One other thing to mention: I know time is somewhat tight, but you shouldn't be too quick either - another maintainer may have a different view, after all. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:28:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:28:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105916.1456729 (Exim 4.92) (envelope-from ) id 1utNJd-0005qV-D5; Tue, 02 Sep 2025 09:28:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105916.1456729; Tue, 02 Sep 2025 09: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 1utNJd-0005qO-A4; Tue, 02 Sep 2025 09:28:37 +0000 Received: by outflank-mailman (input) for mailman id 1105916; Tue, 02 Sep 2025 09:28: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 1utNJc-0005f4-AK for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:28:36 +0000 Received: from mail180-6.suw31.mandrillapp.com (mail180-6.suw31.mandrillapp.com [198.2.180.6]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 32c7d3ab-87df-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 11:28:35 +0200 (CEST) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-6.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4cGL5Z0m2xz2K2671 for ; Tue, 2 Sep 2025 09:28:34 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 5a36f42ca8a1486e95ff20a990a02aa7; Tue, 02 Sep 2025 09:28: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: 32c7d3ab-87df-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1756805314; x=1757075314; bh=mVE2bxoiaJc/omf+Xbgpgc0UASpoGRaDW87GrKaH4u4=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=j++PI+0++pbjylfCeY3fQ8zK7noV+3ix9tvCMfLs35RsyaYSl7FXBbv32p5T2E+mE s994SlUyEug3Z+9MsB3EkGMJbUIcBVTX/nxvg4hysRQfpAQf1JnTMvCMTrSaYYhNg5 nc2pEunUbMVta/9hj0n9IsU4VlXH9V+ra4wguTuPOd9fpzubkBQeXdig29XWeKqUmi aBy0PpKDR/YOKIJcuJrpzn6TXV/l2B3qdXtlfrlQLEDA2MzeSTh6S3sf5E2fSKOrPF Gdi2B8zcFtt7/8SB1BDwpxSfjmMKqtWDfM8Amkwcog/KqypGJfA1Z4RsHu6CwUo7CJ ec5IsIAuyUulQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1756805314; x=1757065814; i=teddy.astie@vates.tech; bh=mVE2bxoiaJc/omf+Xbgpgc0UASpoGRaDW87GrKaH4u4=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=P5jNEKVKz+utMDl8M2yH9csSGHgrN+yiv7VTbmU8+WkqLjHDqKQ06bldcG0RrqNfA mA+OhCDbKlVemaDZ7SGAEzeGRyCpdrM7w0Ado5Kao1/jD7DRYaIcM+pwH/nYGJ6Sym lz7p+XLrcY4tinD+Z9uG+F1c7Ip3Dj+zEbrd/i2Q9mKtwhK1gIFuyEMLWWT6ZSRheg IV7zmDAQ201pyYbkxsOOKd/E3f32ErgSLJg6+1AWV8GR/dX/T9yjO5PkjL9jxKdzVN zcpa00vEw6L/ZdkgTlXLBe5Qvjic/SvOiAXEb1N7TQ6njV+LSiRA+azRt+rpJ2/6YB ebuY34HSD9qKQ== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=20v5.10.y]=20xen:=20replace=20xen=5Fremap()=20with=20memremap()?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1756805309861 To: xen-devel@lists.xenproject.org, stable@vger.kernel.org Cc: "Juergen Gross" , "kernel test robot" , "Boris Ostrovsky" , "Stefano Stabellini" , "Teddy Astie" , "Anthoine Bourgeois" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "H. Peter Anvin" , "Greg Kroah-Hartman" , "Jiri Slaby" Message-Id: <4cc9c1f583fb4bfca02ff7050b9b01cb9abb7e7f.1756803599.git.teddy.astie@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.5a36f42ca8a1486e95ff20a990a02aa7?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250902:md Date: Tue, 02 Sep 2025 09:28:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit From: Juergen Gross From: Juergen Gross [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] xen_remap() is used to establish mappings for frames not under direct control of the kernel: for Xenstore and console ring pages, and for grant pages of non-PV guests. Today xen_remap() is defined to use ioremap() on x86 (doing uncached mappings), and ioremap_cache() on Arm (doing cached mappings). Uncached mappings for those use cases are bad for performance, so they should be avoided if possible. As all use cases of xen_remap() don't require uncached mappings (the mapped area is always physical RAM), a mapping using the standard WB cache mode is fine. As sparse is flagging some of the xen_remap() use cases to be not appropriate for iomem(), as the result is not annotated with the __iomem modifier, eliminate xen_remap() completely and replace all use cases with memremap() specifying the MEMREMAP_WB caching mode. xen_unmap() can be replaced with memunmap(). Reported-by: kernel test robot Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Acked-by: Stefano Stabellini Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Teddy Astie [backport to 5.10.y] --- Cc: Anthoine Bourgeois Cc: Juergen Gross Cc: Boris Ostrovsky Cc: Stefano Stabellini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Greg Kroah-Hartman Cc: Jiri Slaby arch/x86/include/asm/xen/page.h | 3 --- drivers/tty/hvc/hvc_xen.c | 2 +- drivers/xen/grant-table.c | 6 +++--- drivers/xen/xenbus/xenbus_probe.c | 3 +-- include/xen/arm/page.h | 3 --- 5 files changed, 5 insertions(+), 12 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 5941e18edd5a..c183b7f9efef 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -355,9 +355,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr); void make_lowmem_page_readonly(void *vaddr); void make_lowmem_page_readwrite(void *vaddr); -#define xen_remap(cookie, size) ioremap((cookie), (size)); -#define xen_unmap(cookie) iounmap((cookie)) - static inline bool xen_arch_need_swiotlb(struct device *dev, phys_addr_t phys, dma_addr_t dev_addr) diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c index 4886cad0fde6..7b472ab2f34f 100644 --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -270,7 +270,7 @@ static int xen_hvm_console_init(void) if (r < 0 || v == 0) goto err; gfn = v; - info->intf = xen_remap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE); + info->intf = memremap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE, MEMREMAP_WB); if (info->intf == NULL) goto err; info->vtermno = HVC_COOKIE; diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 0a2d24d6ac6f..a10e0741bec5 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -743,7 +743,7 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr) if (xen_auto_xlat_grant_frames.count) return -EINVAL; - vaddr = xen_remap(addr, XEN_PAGE_SIZE * max_nr_gframes); + vaddr = memremap(addr, XEN_PAGE_SIZE * max_nr_gframes, MEMREMAP_WB); if (vaddr == NULL) { pr_warn("Failed to ioremap gnttab share frames (addr=%pa)!\n", &addr); @@ -751,7 +751,7 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr) } pfn = kcalloc(max_nr_gframes, sizeof(pfn[0]), GFP_KERNEL); if (!pfn) { - xen_unmap(vaddr); + memunmap(vaddr); return -ENOMEM; } for (i = 0; i < max_nr_gframes; i++) @@ -770,7 +770,7 @@ void gnttab_free_auto_xlat_frames(void) if (!xen_auto_xlat_grant_frames.count) return; kfree(xen_auto_xlat_grant_frames.pfn); - xen_unmap(xen_auto_xlat_grant_frames.vaddr); + memunmap(xen_auto_xlat_grant_frames.vaddr); xen_auto_xlat_grant_frames.pfn = NULL; xen_auto_xlat_grant_frames.count = 0; diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index fb5358a73820..23595fdd053d 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -919,8 +919,7 @@ static int __init xenbus_init(void) #endif xen_store_gfn = (unsigned long)v; xen_store_interface = - xen_remap(xen_store_gfn << XEN_PAGE_SHIFT, - XEN_PAGE_SIZE); + memremap(xen_store_gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE, MEMREMAP_WB); break; default: pr_warn("Xenstore state unknown\n"); diff --git a/include/xen/arm/page.h b/include/xen/arm/page.h index ac1b65470563..f831cfeca000 100644 --- a/include/xen/arm/page.h +++ b/include/xen/arm/page.h @@ -109,9 +109,6 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn) return __set_phys_to_machine(pfn, mfn); } -#define xen_remap(cookie, size) ioremap_cache((cookie), (size)) -#define xen_unmap(cookie) iounmap((cookie)) - bool xen_arch_need_swiotlb(struct device *dev, phys_addr_t phys, dma_addr_t dev_addr); -- 2.51.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:29:32 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:29:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105932.1456739 (Exim 4.92) (envelope-from ) id 1utNKW-0006RH-0s; Tue, 02 Sep 2025 09:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105932.1456739; Tue, 02 Sep 2025 09:29:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utNKV-0006RA-US; Tue, 02 Sep 2025 09:29:31 +0000 Received: by outflank-mailman (input) for mailman id 1105932; Tue, 02 Sep 2025 09:29: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 1utNKV-0006KE-4T for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:29:31 +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 52a4557a-87df-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:29:29 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6678F43E7E; Tue, 2 Sep 2025 09:29:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 793FEC4CEED; Tue, 2 Sep 2025 09:29: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: 52a4557a-87df-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756805367; bh=DnDVES5Jg8WrIGoMPMfvxV9Wox20mcRcpnotwmcTmTg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u+YP0LKc7Ca9KSEGyhHI9LWKXOpYxDkmlx+xi/d94i28PXwnbkADYdG/kMj0eiK5B zd/GooYAccyXKqdo2LtN0swNMmhiizGQIgjHrkSZ2IAXK/1jBPSRk3StbcZycbdrVP g5quZtmGQMVEWVOV9clnOLPmMIcFNqak1dVeFhnzWaY1VIAyIlM9TCnw1bUSOb10fT eYPBFQEGyOkOZzS7K5YPtS3dmkawe2LLvJU33SWPAwVjDdMQDDLsS8LD6Qfe4rZdHI wki/IP/V+av0oWZTHcazqMPHDSPlXAIhw9qhWxKa10uhggFEbKZZEF+GYaHO+zcGYb 634HFrNZvr1dg== Date: Tue, 2 Sep 2025 12:29:20 +0300 From: Leon Romanovsky To: Jason Gunthorpe , Marek Szyprowski Cc: Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based API Message-ID: <20250902092920.GE10073@unreal> References: <20250828115729.GA10073@unreal> <26bd901a-0812-492d-9736-4a7bb2e6d6b4@samsung.com> <20250901222302.GA186519@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250901222302.GA186519@nvidia.com> On Mon, Sep 01, 2025 at 07:23:02PM -0300, Jason Gunthorpe wrote: > On Mon, Sep 01, 2025 at 11:47:59PM +0200, Marek Szyprowski wrote: > > I would like togive those patches a try in linux-next, but in meantime > > I tested it on my test farm and found a regression in dma_map_resource() > > handling. Namely the dma_map_resource() is no longer possible with size > > not aligned to kmalloc()'ed buffer, as dma_direct_map_phys() calls > > dma_kmalloc_needs_bounce(), > > Hmm, it's this bit: > > capable = dma_capable(dev, dma_addr, size, !(attrs & DMA_ATTR_MMIO)); > if (unlikely(!capable) || dma_kmalloc_needs_bounce(dev, size, dir)) { > if (is_swiotlb_active(dev) && !(attrs & DMA_ATTR_MMIO)) > return swiotlb_map(dev, phys, size, dir, attrs); > > goto err_overflow; > } > > We shouldn't be checking dma_kmalloc_needs_bounce() on mmio as there > is no cache flushing so the "dma safe alignment" for non-coherent DMA > does not apply. > > Like you say looks good to me, and more of the surrouding code can be > pulled in too, no sense in repeating the boolean logic: > > if (attrs & DMA_ATTR_MMIO) { > dma_addr = phys; > if (unlikely(!dma_capable(dev, dma_addr, size, false))) > goto err_overflow; > } else { > dma_addr = phys_to_dma(dev, phys); > if (unlikely(!dma_capable(dev, dma_addr, size, true)) || I tried to reuse same code as much as possible :( > dma_kmalloc_needs_bounce(dev, size, dir)) { > if (is_swiotlb_active(dev)) > return swiotlb_map(dev, phys, size, dir, attrs); > > goto err_overflow; > } > if (!dev_is_dma_coherent(dev) && > !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) > arch_sync_dma_for_device(phys, size, dir); > } Like Jason wrote, but in diff format: diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h index 92dbadcd3b2f..3f4792910604 100644 --- a/kernel/dma/direct.h +++ b/kernel/dma/direct.h @@ -85,7 +85,6 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev, unsigned long attrs) { dma_addr_t dma_addr; - bool capable; if (is_swiotlb_force_bounce(dev)) { if (attrs & DMA_ATTR_MMIO) @@ -94,17 +93,19 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev, return swiotlb_map(dev, phys, size, dir, attrs); } - if (attrs & DMA_ATTR_MMIO) + if (attrs & DMA_ATTR_MMIO) { dma_addr = phys; - else + if (unlikely(dma_capable(dev, dma_addr, size, false))) + goto err_overflow; + } else { dma_addr = phys_to_dma(dev, phys); + if (unlikely(!dma_capable(dev, dma_addr, size, true)) || + dma_kmalloc_needs_bounce(dev, size, dir)) { + if (is_swiotlb_active(dev)) + return swiotlb_map(dev, phys, size, dir, attrs); - capable = dma_capable(dev, dma_addr, size, !(attrs & DMA_ATTR_MMIO)); - if (unlikely(!capable) || dma_kmalloc_needs_bounce(dev, size, dir)) { - if (is_swiotlb_active(dev) && !(attrs & DMA_ATTR_MMIO)) - return swiotlb_map(dev, phys, size, dir, attrs); - - goto err_overflow; + goto err_overflow; + } } if (!dev_is_dma_coherent(dev) && I created new tag with fixed code. https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/tag/?h=dma-phys-Sep-2 Thanks > > Jason From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:32:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:32:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105944.1456749 (Exim 4.92) (envelope-from ) id 1utNNT-00089T-Ft; Tue, 02 Sep 2025 09:32:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105944.1456749; Tue, 02 Sep 2025 09: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 1utNNT-00089M-CM; Tue, 02 Sep 2025 09:32:35 +0000 Received: by outflank-mailman (input) for mailman id 1105944; Tue, 02 Sep 2025 09: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 1utNNS-000898-39 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:32:34 +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 c127214e-87df-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 11:32:33 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b04271cfc3eso243435366b.3 for ; Tue, 02 Sep 2025 02:32:33 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b041f6fb232sm582322566b.87.2025.09.02.02.32.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 02: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: c127214e-87df-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756805553; x=1757410353; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=NXdi+eL+bu6vyU0ShyxyymOxzjSvE9FE8HyeCBj8ZSg=; b=M1ajwX4U1h0TkXs43nf+c4wKEfpvUI8eZqqITRUs2qym6upsX76tdSf86vp8J5cCv4 xCG4oiZEgqqt9ixUMr9Z682DiSgVuqV5ER6HYrhwVI/I2tJCbC8xnfkE+1UBRz+n9DWp FXX/XakNvRO8P1cvktxfLb557MgE6Uk/z5q8gbua4jCxLMjTnkKcELCM1wOE3dWaSkJU /72V4Jz/u6lgZKZoMgr2J9gdeBrlIv1yWr/DkKgZ59zFlWwgcScdRyQ3A8lt/HP7AMfQ Fd/AloAGNV4+s8ZhxVa2HU5rGsnvAtBxUvAruvnG2VVsDYUfmFJkSf3uHfifDra43dBX +6Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756805553; x=1757410353; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NXdi+eL+bu6vyU0ShyxyymOxzjSvE9FE8HyeCBj8ZSg=; b=wpUReW8+TBzDXDM37PJyjp7vRG8q3YnmVICYy6IDZ/2J2YZTCdW9/wI7QGwYj3VBux yM709G/EsZuw2bRdQyyGfxNrasubjauc5beQ0qwB5d1yiBkKBlpkP+ryq4yTJGgUrH8S iKRJvjQaUQI2EyoRnij3Wsk0IepcUNShzpKk/5RdR1Vggab2G4KymGHljh+u/Qx2Jgpr Mug7M3bsqCKXGtqC5LSH6dtYS3fdjj7yKpysEfnNsZ/k7JjB0XBPxahCEOClvc29AGu8 QvDvYUrw1tYWVJoqNXZUOyriQkyDdxrm6pRx5uFacn0It/OKgjq9U7FCJhrncSGd2tTl 1CdQ== X-Gm-Message-State: AOJu0YwyYsJ899SsRx9mosc1liNpFPoDYs+HYOiwfjKSptetHHJbRqcv eO8VzuVCQskWqDjBnsRo7sgVyBqwqqetcXBM9YHynvLRFLj0H98R0dUIOr1ub7T7Ew== X-Gm-Gg: ASbGncvTqazyiTgbw3hIEToYrxPqSy0qL9Vu0TAelvjSu0OLL6nQ6GwqQu0FXEfCOJp DAdWoWfYVSTq4UjyEMovslE3Okb4nfKk2ESsflzWBM3z5ZKH8wF0Ms3KVoD4G7q9EJCqZq04h7q JsN9vo+ct+o/dTj4D4hjXQblUZQFSVDFA7exmVM7l3mGbPgShGvjRk0SZ29vcjBj0/loMOUP/Wf IrSfDbMtS/VP5i7hll5gexMAAAPQcxcRvitMbTPyckuH2GvharuGVhZ6UxQmJD9S86mPfLz31LC Wrg2+1j1H3DGcojXuhboAtAtUBtugeY6syCeCeh9gT9j72CmRW0LHB4/hWVcr03yCXGS6QlciLm fZdRUMQyXETgtUPi5AzSFrbX2UVnD842tkgJMm1WZsWCCZ68Pr8Ewjab0nDopF0RGpTfZzk3i9m hGPocVHNQ4O0YqinBRKnbQ7ax/hZR7 X-Google-Smtp-Source: AGHT+IEJkS/x53nwwWhIB5BtWQD9NKzIVr8j7nv4xL6dzyyUwyvyQKYORYQq0jVZ6L3wdexVfn4ZGA== X-Received: by 2002:a17:906:dc90:b0:b04:4ba7:4e0d with SMTP id a640c23a62f3a-b044ba75282mr199267666b.26.1756805553080; Tue, 02 Sep 2025 02:32:33 -0700 (PDT) Message-ID: <7a9210e1-d579-48e1-99ca-1685d7561529@suse.com> Date: Tue, 2 Sep 2025 11:32:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/15] emul/ns16x50: implement emulator stub To: dmukhin@xen.org, Stefano Stabellini 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: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-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 02.09.2025 01:11, dmukhin@xen.org wrote: > On Fri, Aug 29, 2025 at 12:57:43PM -0700, Stefano Stabellini wrote: >> On Thu, 28 Aug 2025, dmukhin@xen.org wrote: >>> --- a/xen/common/emul/vuart/Kconfig >>> +++ b/xen/common/emul/vuart/Kconfig >>> @@ -3,4 +3,22 @@ config VUART_FRAMEWORK >>> >>> menu "UART Emulation" >>> >>> +config VUART_NS16X50 >>> + bool "NS16550-compatible UART Emulator" if EXPERT >>> + depends on X86 && HVM >>> + select VUART_FRAMEWORK >> >> default n > > Ack No "default n" should ever be put anywhere; it's simply redundant. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:36:26 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:36:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105954.1456758 (Exim 4.92) (envelope-from ) id 1utNR9-0000Fm-0H; Tue, 02 Sep 2025 09:36:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105954.1456758; Tue, 02 Sep 2025 09:36: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 1utNR8-0000Ff-Ti; Tue, 02 Sep 2025 09:36:22 +0000 Received: by outflank-mailman (input) for mailman id 1105954; Tue, 02 Sep 2025 09:36: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 1utNR8-0000FX-0y for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:36:22 +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 48c43707-87e0-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 11:36:21 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-61cb4370e7bso7709502a12.3 for ; Tue, 02 Sep 2025 02:36: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 4fb4d7f45d1cf-61cfc1c7a8fsm9150713a12.3.2025.09.02.02.36.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 02: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: 48c43707-87e0-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756805780; x=1757410580; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=7+/5Vl//tzLfXwVhASc1rt+01VD2kpJA+zviG5NglgU=; b=QeK50tTpRBApS/CRtHZx4izKbcTkyoahjXlEkl3hGC/uM0EmpnPSC8Yz5RoO37qTSl hLi2S6I+mfND87CM7h1dxP03ZXfa8oS4aeVY96uxmmZHyP56v0aWW4TRvEAXj+/lVRMx 9TXTFYonVdjvsybGqXSUGahMJgM15sbdmlZoCXqhlXV8H+RcVMlMwgQt6HCbJT8rozcy PtXGB8rMFNWw0GYgG/5LeVR3P1TBwYCd1CQRR1iJgCJddd7zjKBXHIVnHvA22/OrJ2Py UFCTDABourOgc0xqM2tCGNX/Az+IF9oJd5yVdRI9PKGmjM9usflTJBdVZ6+lBQbk16BS OJDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756805780; x=1757410580; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7+/5Vl//tzLfXwVhASc1rt+01VD2kpJA+zviG5NglgU=; b=rxPTkB8yxlxHg3bcrzLQ8T25uiZsrTMgmusPB3OY0wXxn1Uxk7sFD95EVghph4Tl8W 2IWORmHBgi4CkWzrhb42KNRXWVMs2TWB0qKf+5olnJG6l2TDsy53wZxNszvDE7hnMVjv 0K6Kgn/oVgJayaJ1MnbzRi5Sdv5JwVMTlRkaUNedcnRLn9WBEgI9yKOrGXuqe9dCM4pn P7I3r3Fp4wDRbwOV4OByC9fsauKZ1n0yU6X2Q+7BHG9hUT0O96d7RlxljCS8PccNP+p9 8HAojLMFlKQ6WCJIjC68enQ3qCFLPM8dQjEkFZflFgdupl2LKUV1H6V13AL1IUkOxtlT qoBA== X-Gm-Message-State: AOJu0Yw0VlpQZFN3S4ZZQ3uA4F///mMRBJ24ag2Pav6OV9K/tPrbZYxh 8PQoU07yDpU6IKiiINKvgkRtp9oQsV8BIyn/us89lb7iJBm+rHEOPibQfvJhhUfNYg== X-Gm-Gg: ASbGncvZjnH6FoN6qJKQtb8OUim4smfxB/5sEyKdx/a+pZvKMMcWr7CiNac292ibJRB nwMzIq13m53cBZsIR0PMYrqPQcL6t6JUtvdHytDg+wqMbV18BQlZ4aYC1dbqkl22bPMrBzfGJzB Xk3OJ6N1IOxflTij2ceMHHP+tw1B/MCIM/otkI6+N9POyxoR/969dUZMnoZTl946sDgDppnbNfs 0nVtsu8BU8uoyGj+EskQkzwzTw1CNr/OsVWcyJx/HItsDdm9Xy8LWLlpzLC/IqnlGqXOQYCfaKm Uoj6xcnTBvsv7G8VrtIrYOFl9l0siNd4UgokMBWps0U0alEWincK6n5WE3CzeGuU1eNSTEdWF5y 09qUZvMGZJKJXLBA4mRtqJxU8wLo0eFKgILgekylTczMHzm5sKsses0CZSIYC6fm3teU5VVvW7h zrsV8BO0cUzn4o36ip3A== X-Google-Smtp-Source: AGHT+IEaHYJi0kFjAjlOkJ83/qBIQtlUsO7pJCsb0cQRnU9fsgY95z+j0TBUqWQPaHBm5bNcBQHa7A== X-Received: by 2002:a05:6402:5212:b0:61c:7f48:c476 with SMTP id 4fb4d7f45d1cf-61d26988edamr9275667a12.3.1756805780626; Tue, 02 Sep 2025 02:36:20 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 11:36:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/15] emul/ns16x50: implement emulator stub To: Stefano Stabellini , dmukhin@xen.org 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: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-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 29.08.2025 21:57, Stefano Stabellini wrote: > On Thu, 28 Aug 2025, dmukhin@xen.org wrote: >> +static void cf_check ns16x50_free(void *arg) >> +{ >> + struct vuart_ns16x50 *vdev = arg; >> + >> + if ( vdev ) >> + ns16x50_deinit(vdev); >> + >> + XVFREE(vdev); > > XVFREE should only be called if ( vdev ) Why would this be? Like free(), both xfree() and xvfree() are fine to be called with a NULL pointer. What's odd here is that the uppercase form (the wrapper macro) is used - clearing the local variable is pointless when it is about to go out of scope anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:41:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:41:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105965.1456773 (Exim 4.92) (envelope-from ) id 1utNWG-000236-Km; Tue, 02 Sep 2025 09:41:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105965.1456773; Tue, 02 Sep 2025 09:41:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utNWG-00022z-HV; Tue, 02 Sep 2025 09:41:40 +0000 Received: by outflank-mailman (input) for mailman id 1105965; Tue, 02 Sep 2025 09:41: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 1utNWE-00022a-UT for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:41:38 +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 04a2b054-87e1-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:41:36 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-61cb9e039d9so10303920a12.1 for ; Tue, 02 Sep 2025 02: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 4fb4d7f45d1cf-61cfc231561sm8984888a12.23.2025.09.02.02.41.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 02: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: 04a2b054-87e1-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756806096; x=1757410896; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zEQL+Uo/M9ox57ZUOUa3u3QRFRTtHXaecTK3I/aVK40=; b=YC7g1SjSjV0dfukh94K5IZT2wy3ViDtUFY6l45De1s7AmMAAvLp5KG2efRWExuPMzX Oyey9RSCpYv/Pxcw5ZIvH0JyP0Iblfk1X8vQ65r1YAs11IdClxhgRiiCPsrmyGFCIRfo YoXHUKdS64oYwgTt92zv4macPSmnOqp5b9wJimMZJLWS9ENjKBETfs37rXI8eOzrNM/W ltZTGInyaXLbpZQNK/7g3GZ73WpbgywhlGwSTvDNpIPuCuMPFFWATGoUL+Pnyw/BPBk+ Rb2SAWUvzXwOZYKG41W493mFkyY7c/+XfLtJE2XoMYoBLa28eRLSW6RbnFjula7Lkgkp LRKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756806096; x=1757410896; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zEQL+Uo/M9ox57ZUOUa3u3QRFRTtHXaecTK3I/aVK40=; b=q8yGRHqzE4pKQdqjm75LsJ112MqN4ySInsqUdCH2WCnl05pk5sP0jUakDPtk/BXyhR JjtrJesGD65NoK9UOr9Po/CrHkfvWNCPVc44vRnQOF74dJtifuUaE+rZ4lVitWSlVhAp CO2c5UT75tNNAVeO0HhD9pBWm1mR6qC4nDpA/Z1UnhrmRMM6N/2g7w1MerOzCjJerfPb Oey/mJVy/z8o0sT8uMeIF1XhTS3OwTs+iDXUkkbljclJ90yptV88FdkCWWipNZd6Dsr9 O49ecqB1Kew6mXTm6Y92/xnaw+Fj+QUTXrJFL6DRtDZDQKxeaFAu0139TkEyLR7Z+8ly /RYw== X-Forwarded-Encrypted: i=1; AJvYcCXV7Br2CMnCoEBnsJtWMCn/Wl9er/Gwb9B04JHmChYKZeRoV9WEidh3GSj4timlj1rAIZzXdfP35gM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzd5v7LN6wMWxK3ctbZ9oHH3OD0wQmsa6sEvnyzYyieMrsvEqG0 yUk1F+rCbNBZbVvukiBH36kX+GAm6ObXWyqP2uoVSnMu9WAZQSZUfNiICJjxza1dZg== X-Gm-Gg: ASbGncvHRXgQ5GyhzwIywascoMzF8QDKtXDpEdvf3J+kw3UKk4VoUFoP3H0ZWeEj3Xv kck7PqcjgcKQylHcUlcTHK6cvrFASqEFwqTf7ryBaFnEdL5KaDh1l1qzworgt5HsGpZ5ZZ1c2Xt AtKTKajwtNZ6gBO1Vocbys6jRh1z6xU9QBxVT/Pn9ybHYkY6cjg5IIGHzBetffwaHXz2TE0+XpO wAFESgw7mtYl+VKNMJAyqPxtHvjUesY9WlQpnBv1e1OLZeNaOSxGcOT3ZiHrZf20oLGoS3ehoPW jr3e+fOrZIrVpBwIDo7pR4MvWaM5AeXtIbpUNGtEKjlEoIj23woGLGnqHupiXszPYWPXabeuCom 3ckktU/eWQQOm29lXxiB7vZ1//4ZPoi6MlYbPGGLgK6OYAboElLE+tnuO890/AgkwjF+ap2Z8Ld SIJcDOpItX1FHP3dQpRQ== X-Google-Smtp-Source: AGHT+IFRb2x3CvevL5Gwrhy8jIviwNwNZpgzybwQlErQkuf5EE6kYHdXvihRuXN0kSfGb3ufoGzEOw== X-Received: by 2002:a05:6402:505c:b0:61c:e1d6:6bf6 with SMTP id 4fb4d7f45d1cf-61d26998f14mr10056049a12.7.1756806095406; Tue, 02 Sep 2025 02:41:35 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 11:41:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] xen/flask: limit sidtable size To: Sergiy Kibrik Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20250901105231.1570041-1-Sergiy_Kibrik@epam.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250901105231.1570041-1-Sergiy_Kibrik@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.09.2025 12:52, Sergiy Kibrik wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS > > If unsure, say Y. > > +config XSM_FLASK_SIDTABLE_ORDER > + int "Maximum number of security identifiers (base-2 exponent)" if EXPERT > + range 4 32 > + default 32 When 32 is chosen (i.e. also the default when the prompt is hidden), ... > --- a/xen/xsm/flask/ss/sidtab.c > +++ b/xen/xsm/flask/ss/sidtab.c > @@ -14,6 +14,8 @@ > #include "security.h" > #include "sidtab.h" > > +#define SID_LIMIT ((1UL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1) ... for Arm32 I expect either already the compiler will not like this construct, or the latest an UBSAN checker would object. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:43:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:43:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105979.1456782 (Exim 4.92) (envelope-from ) id 1utNXk-0002YX-TZ; Tue, 02 Sep 2025 09:43:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105979.1456782; Tue, 02 Sep 2025 09:43: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 1utNXk-0002YQ-Qj; Tue, 02 Sep 2025 09:43:12 +0000 Received: by outflank-mailman (input) for mailman id 1105979; Tue, 02 Sep 2025 09:43: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 1utNXj-0002Xs-Ef for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:43:11 +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 3c53a397-87e1-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:43:09 +0200 (CEST) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-61e930b27bcso2479691a12.0 for ; Tue, 02 Sep 2025 02:43:09 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-61cfc4e5229sm9123380a12.39.2025.09.02.02.43.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 02:43: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: 3c53a397-87e1-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756806189; x=1757410989; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=m3fV4yIS9C9DVX/71GkHfa70EEstn3BwvJUSc5TN/nA=; b=OsJqd/DWy0LmIV5fvchb/DXWUICLc78TY+W19s1ox+fFi1awcA6aXnDPaw0+ilCLx9 /PHFGO7hrwxO3dvaY/aPQOyk9dKa7xIbw5RdA+8PmVuFy8mjn59MDGoB9+9eqE+wrDGj 7PJNvfREKIBFFmhPXmu/TV82kYJUV8wr7985tLvfsOEMUrtuJbiBDo1G5UFJLrpR3YWY GQs2o5BUt3+7Qnw9nWV/+J648gIfAyyQNZ00zhKKql17+xexlXOAbrpfHwupDmiDv5S7 IN3hwG/0Q6wtBKvMwsAelRcI2vpa+aIJCnFbCl3NJVjeahE143B+G8Zqj0p9mCSMNLRo R17w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756806189; x=1757410989; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m3fV4yIS9C9DVX/71GkHfa70EEstn3BwvJUSc5TN/nA=; b=pcUxo4ZTreKng8Ts5vHjtki/I1Bz9zFXVKSENxfktsQj5P2UiH16JvFBh4EmZWHB9U lv9QjkEsfgOh1qI4oKL7RndZNlZ/tsAE3bG9pHs8mbs9ppKLTuQ/rbUT8w6cnPersl2o qIFc/LfA9hwrfLzkOcoh21AxDayPrqFHlVUjaNFK+7dbkA+cGqqVOdd2R3WZ3kLN9Bv1 bKNodMpWnUbb63nVBcnoMrylh43OioGe5PFGvOWP1Lq+nzvCeIl4j8BoyzM4XgWacal3 7VDUbPtyOsfa2iycvio5UIG0Az7qZZJVigUz3AiRroODV0oAr+urRPhTjqLzVUDdXFwG ibag== X-Forwarded-Encrypted: i=1; AJvYcCUXuTyQnW9gege3oZPcjD80WsYVQUWT0cI3m2XvRSOAkDitCLiMs224PjnDlu8TcPXqV9GMDLjZUYo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwtTlv6Zdx3AkS5bskCDX5Hkt/nhQZbu5yyFb74oItuA+fa1VLx 1bYsKwurlvV0dm1Cw1GTK4FtNNmodW0omeEZpGCJ2ya4/TJHfyPJbUFR7P8ZrGS4JA== X-Gm-Gg: ASbGncvP3kz1a0D7a6IoaSje+K0tScuhLP1iakFbii/+Pq2+Z+D6w0kx2hb3US4m58A 0VOYC18NOZarXp75YP0C/Y1kIrAq42AsOGcHNlaTzqXAlyy0re972T6Wo56qTPNYe7gEJsAIulU XeGHMIbq8f1zMCmyRd5ufmLsF1HWt8twzb2tuXSXJG3tnTc5Nwqi9dpI/WttqWQq193R+kN1NFI Y+K4VM2stzAa5THwoWtSrfe4qgaTQjm8wPWX3Zo0s+Z7ygnTHcqgtaCfBwk/1t5optT9kYeNSJ+ FVefSQ+fM0ezN1HxHE7bwcf+1T9TA0VcMPwmTZkqa1xOO80OuCJ85fEP1oJX3HMsM7Qw79TSISJ AS0n3LQSrJLFyGToJkeyNWH/qHiz+uvH4yNIbkwRAOvP6Wf9lBM8ZfntFPsn5SVLUiAl+kJtRIh ioPs6aeLg= X-Google-Smtp-Source: AGHT+IHjv8M9OAyRDGGw+4jLnGYUb70sekq3UdBbMnqccZmXGPfXsgFWywXzseCXlC4A9ISi+FUZIA== X-Received: by 2002:a05:6402:23d4:b0:61d:24b4:aa6 with SMTP id 4fb4d7f45d1cf-61d26d8512bmr9150548a12.30.1756806189279; Tue, 02 Sep 2025 02:43:09 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 11:43:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86: Fix AMD_SVM and INTEL_VMX dependency To: Michal Orzel Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20250902074048.12094-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: <20250902074048.12094-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2025 09:40, Michal Orzel wrote: > Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and > INTEL_VMX on INTEL. This dependency was reflected using 'if' next to a > prompt which is incorrect as it that deals only with the visibility of the > given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX > when INTEL is disabled (option is hidden). Fix it while keeping the > possibility of e.g. enabling INTEL_VMX when INTEL is disabled. > > Fixes: e3ed540f2e9f ("x86/hvm: add HVM-specific Kconfig") > Signed-off-by: Michal Orzel Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Sep 02 09:49:42 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 09:49:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1105992.1456792 (Exim 4.92) (envelope-from ) id 1utNdx-0003D6-Ln; Tue, 02 Sep 2025 09:49:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1105992.1456792; Tue, 02 Sep 2025 09:49: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 1utNdx-0003Cz-IF; Tue, 02 Sep 2025 09:49:37 +0000 Received: by outflank-mailman (input) for mailman id 1105992; Tue, 02 Sep 2025 09:49: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 1utNdw-0003Ct-FI for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 09:49:36 +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 214e7c94-87e2-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 11:49:34 +0200 (CEST) Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20) by AS8PR03MB7524.eurprd03.prod.outlook.com (2603:10a6:20b:347::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 09:49:32 +0000 Received: from AM9PR03MB7025.eurprd03.prod.outlook.com ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 09:49: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: 214e7c94-87e2-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rXXqG/iTYeVFZJBh/hJ1uxxic29K/XhdVBvBCOxxqVaxhOFOXy5gh3TafM/Q3VbQvjRvjJk28IgJWwpFxPZUMM0vVJuX41zQvahJkqbs3hayTKWJosIl3vqfeffjSEZ7QpMeOdCP/DemKWSBTlMXU+UN3v6goIp2FSou4rMZMd7r+FQ4JEuOxvk+LTaUT6IK175bvzfMjjViDHLawOuHjmDCJkBBge5VVVIJP0VrUZKnE/XLyUlCwzPyEKCqZ+OCbgCGzJ+lnJOoyxzwyDKuH90Lg3TuqKDQS0L4J05OHOT60JZTzHVNm3rNHRea/Bot+srrEpEFLcoVTkYho6XiUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2hugrVlPjd4ZYGk5GZLw7kCjfIEEafvROtFkSpJP/WA=; b=DczYT1+kFbmoPjOFkU8OxulGTC45yWtR0QITB7+Nh7XOyBuIdZaJYsiKGEVnlUAiX2GYnnmyMFDt1egwnRDQuUqcDBBR8xj8AaVH2iYbkGJybMVICqtKf2w/DuPpT8KJ7QL08c9zxUb1YPqXnkFplLY2QPoIHNDp8v19c0/bElTID86XIM3qtKmf0OO38m72A5DNV4uwpe3pP/eEKOeGE7QdVlayvmg2rOPrYxID/CX85YvYEwnK7jr3IaAFVML1hqxmOkAtodPYyPZt7burOSNaKYRENfGVEwkRtR3pkOwH/fAr6HHXlIYRE76vbz1Do1r5si0IXI8u2UQncje90w== 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=2hugrVlPjd4ZYGk5GZLw7kCjfIEEafvROtFkSpJP/WA=; b=PbYO8nynLcuAGeMbldGMuF7SowKsCmENJe2M9LxCKGK5mFV3CPFJKaO8blB+BNHsvupjGX49Ba/SQ3WsoKoiDmbu0Zlk8+5TH/SGnH5lPuVZB0C7tK9BuaUoJI9++uZ4qswIYQoT/D4Bt+StXP01Qh07sUg/ihvk5goUnsIWd5tcHXjXKVjDycbHr/1bPz67h2O6H2/NXuoPB00io4G3Kkl5vrZYQDY3jPmXa/YpwT2FiCdRnwEGkGZC7VzhZADS4RhH3vQTuxpDK8zbr6tGo82MKl9asBQqZTOR0ZUV9Ud4CtxKGJx/G2WLveEzGORIpVGAbDV3vPmttfIb74NBaQ== From: Oleksandr Tyshchenko To: "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Topic: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Index: AQHcG+7h2TGQQIBGXEebyEy6VBbgNA== Date: Tue, 2 Sep 2025 09:49:32 +0000 Message-ID: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> Accept-Language: en-US, 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: AM9PR03MB7025:EE_|AS8PR03MB7524:EE_ x-ms-office365-filtering-correlation-id: 11dead38-5939-499f-33c5-08ddea060472 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|42112799006|366016|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?fXGxzWW7zLwdIKqS+P1mvX6RslXwr12mjvQ/A8rn1eKrs1XmtCr0Embyc9?= =?iso-8859-1?Q?WPjh50RC4rNi2SyCuiWRCHkCdFmDowNxSMUzQmRkvlXtccjd6/znGEdmiN?= =?iso-8859-1?Q?bsDJo0kN+Y5vopEH7bwiAluoKo0OeeJY7P0yOLYMvh4Nn40Its3iz8HWHG?= =?iso-8859-1?Q?uR/O55PvhpJMRjiS55CY275J260b4//3PonqUG1RPVVn6wv4N3qmhH9eE1?= =?iso-8859-1?Q?UitSf5s/XZFX3LcmH2/Vk9VHspQgX7HwQQRJDzc1/Mpp3XG/LvvOdAsnh8?= =?iso-8859-1?Q?uEmImIx4yK9K24RSsaFv+xX45zWUUWPrwXTZcWRbTVX+rpDeL3DTbct4o3?= =?iso-8859-1?Q?gy28Zx7Ng1sojGHJOi3BObwZ+ArwltH8hvtTL5++W0up5YMhbhOajBMDfa?= =?iso-8859-1?Q?+hgazQ3tAbr9XZDj3fpbD2+QiF7PI3Wz2TfjxiutU8OGuSBufPFVEYL1iA?= =?iso-8859-1?Q?w2h4hV5Oz1SXGOx228uM7DkQimICE6S6wKLhVCBR4mLFW79Kvc1nzgELpb?= =?iso-8859-1?Q?ujo/86ZVPBLBS+iOqX8aR0GXyTE00aflCSrF6UDe5zaqks9a8bXkkh5uaz?= =?iso-8859-1?Q?FiXkaX3hgjqYVe+xoPruZGKgXpP3vVCLSeVie7JAnTdxvijey3V2mTDNUe?= =?iso-8859-1?Q?z73bX+sXeVDp3xKKKaJ9BldPB5qkIG98wFqCDgubdyOJAmzN9+OG3OrmGi?= =?iso-8859-1?Q?rEIRgnWN2vGsUdpVuG89724959/fy5kCK4gaiIduwtXx+XghhRnKSAuJzZ?= =?iso-8859-1?Q?Krvgu2WCO9GOIkhE2DbU30RrrrgyKDBoBwNxUqr4hhrpQBhaRp/TzuSIrr?= =?iso-8859-1?Q?5A/51S3NhF6ehE9/NLG6TO+y6ClfWDu0jkGbWuUSdjgMOcVagDYgIYU7bo?= =?iso-8859-1?Q?UT9Z26ew7pXX8wYa8//jaBJGMFQaoRxB9gL/y42PSyx4ITCaLFdQG6ksr2?= =?iso-8859-1?Q?FQDENRj4L3SE8mbygUZ2xia4MHRla+/DIeCr/7UmPOpIRGlY5Ip/FPu/0x?= =?iso-8859-1?Q?3xOZErAJvZX9fUDbV6jkeb39Fg9rOQhsE7bmWm58FaWe6KA0g23E56SFCB?= =?iso-8859-1?Q?eEqJtqJc62mhdyuTNHy/kyMIBiAP7CyUJfQojYih/fIyObWBfDchn8J1Qj?= =?iso-8859-1?Q?8t+gdolb+yQVR92sd0kIDyf6Y0g/uN0uLWTEx69+l3qzFY4ScWzNkl6Fx8?= =?iso-8859-1?Q?V9J1DubFmKJmG4KL3V0+YGD0nrhsVrDJeP6GsVn5OzXsP6OpMV7gnuQato?= =?iso-8859-1?Q?WggOjUImIix4uCkZP3N6XIbmVJPrQXUI7xQPVi82pgOBqzMLb0h6Eg6WCY?= =?iso-8859-1?Q?lAHfsm4S/i4OJQnnfdBBaYANDRDzeDn0Zal7eSaXAaxKMakZ7cs9LZSXPn?= =?iso-8859-1?Q?vaFHSiXm5A3Dis1SR7Eg5E9EuZfSp3L3uQ2bkRSaS6HnpcQcSTbxskUSCg?= =?iso-8859-1?Q?0OIOVscRM+nwNZtbMniIN3PjRD+M+EK+sOjhKFn/Ul0IjbGPyoG1mVGrXi?= =?iso-8859-1?Q?8PFldFsz+M1wXy3VZs3HFOmMtZrMZDzDd6MKRaptzDDg=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(42112799006)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?NzahQdEEHjKBUuHjNbQltwvhywb1tIOPl1zoO2GSKL4alLRhRp4a7yhp9s?= =?iso-8859-1?Q?GDTqQZBvC5sFiJDz47OxlHpMIiyHPm3QRFEBl5m22RULIIO62BQaz9cgg7?= =?iso-8859-1?Q?wDlelAUMboLW5JdhzHwuF6FbiDeWRPdgD8OWfild/SKTi5LYNjd5tU4RTj?= =?iso-8859-1?Q?JTbDJSUeCuRzWsqrkFf9NBWf46x6c6Q5cQ3yYplh0yJBpoFEsQ1DWQz87E?= =?iso-8859-1?Q?DHwWovJSB5WDZ9k1nyCHxhLfTc4KeAlAQIllYY4Wq6SNrL7T1/MxHYxTda?= =?iso-8859-1?Q?mqW6q/w0BBZsT5xzgftoxlvWtiewDqTGCjRp5cDy/qBsLnA4u6t7RFDfk7?= =?iso-8859-1?Q?TAkjscEV0dCY8TNPG3D3P/Mppbfd8GF2SOg8N4MKHwBDv2VxTFEs5ksjlA?= =?iso-8859-1?Q?/ubYJYDlDvWJ037YE2eXg6fx2ZGz0HOJX2947jGWDekjoCIdYS7d53lyBJ?= =?iso-8859-1?Q?EDyknTKhglu1lcQPtwaiFh3BtzznV4amxQxL5T7W7FhdJGVhDgvMG+NB49?= =?iso-8859-1?Q?hD+r4su85t9zGaQWgUXKGPPy4NZVnIX1St2JCSkBX/Vso4C/7rFqC4OFSf?= =?iso-8859-1?Q?VCKHzIU/RpUOB6t8d1TyMYbTxP/JJufa5rTTIDFLoslmJhW1OXvqqGZDaV?= =?iso-8859-1?Q?FdGe6mm6528C7NyhWnz+vo0QXgQcgKUuY8tCqmHWbF78DYOzK1uk+nbBWy?= =?iso-8859-1?Q?LDiq2b6/+9eK5V7TziAFMUlC0XBQekhEw7c4N8GXdTYSo2mIhxaFOXfegX?= =?iso-8859-1?Q?NwxKl4oA7sneTbQHIDiWbZuuU+zF75eKQzDk8cbQKklxHnGLG0zXRqEtg+?= =?iso-8859-1?Q?UcXh9rqy9iC/5VeyXzya1eB6L4HQG6do34NVHZ7ktIUnooP8ZptEyGqSP/?= =?iso-8859-1?Q?mRd3MgOMRrlC6+SEAFbuHD4zs2laXmNC8gqH+72IBQ3rBHwzW0y2DKyb0Y?= =?iso-8859-1?Q?IwN5CP9SvKuBSymzyQuyKYAlIUY5YBbDKfYw/QbUAbhwiV2vaxpFn4WKmb?= =?iso-8859-1?Q?j1md0v1YForH9+4EgCWiIQDk20RdIOMkz2yPi35JyEc01/9aYKf246nwza?= =?iso-8859-1?Q?aCV05YZ5mGJZwt8gv01GNBulWh2Ka03YFHB1+dJ8/N/EoY5GJds/aYXvKz?= =?iso-8859-1?Q?UkFUxGZ9K/Yd5AyXHiftKRx2e+yX6Sa7nq/5OwZrm3KQQQoMNm+7jwpy8n?= =?iso-8859-1?Q?ZUJ2zZGg8BzfV75G3ZvONDYnyWqeicINwSbEK1dkIyvKLq6nB4KRbcKu/v?= =?iso-8859-1?Q?dj7phc8v5pz4ctb6isd7cnOqk1XdtAywxcXKbRvWiHMvC441ReuhzW2B58?= =?iso-8859-1?Q?CcmSGk0QPy2nbN0BKvSnZLJRgnH1grFz4qpOH2eJQwMSdZu27T5nU9iW03?= =?iso-8859-1?Q?PspbUVLhcTDkCOFH79ScIoUQ7PMBQXg7iBWoqHEDMSvlPGr2ioTkKza9jM?= =?iso-8859-1?Q?BJpBds1H4WHi50Ybm9gkUi8RS6E870aStR59mMDD26ovVJ9t5+PVoqF2o8?= =?iso-8859-1?Q?c8MNqsXvC9zXUxary4Y6qdHAU0oemr0b/aqc0exC1RRLeJeLjLE0POQjj3?= =?iso-8859-1?Q?dOzGS8/UhbfAB6ITOxT1FjhHz6wKcBO9zESrF4UiQyVTAz0+mCP9057iW4?= =?iso-8859-1?Q?32lTXTpRtqXwXyLL1ZtPe9zep8yr+O+AJ5/kox+NRfG592vFttsbBmnNn4?= =?iso-8859-1?Q?H2j3Npa0Bvy8czfuYUo=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: AM9PR03MB7025.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11dead38-5939-499f-33c5-08ddea060472 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 09:49:32.1419 (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: vh+1bmCHIplIDSwASx7m7grMcOcpW2QsO+1oOZM6kEtmwRAaI5oXVn28QUsHA+/WCfVaqqEoN4Er0MjhxW8PZLWawQJEQWP5577Ja8koaDk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7524 The said sub-op is not supported on Arm, since it: - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn cannot be returned), please refer to ioreq_server_create() - does not support "legacy" mechanism of mapping IOREQ Server magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire Resource infrastructure is used to query and map the IOREQ Server pages. Signed-off-by: Oleksandr Tyshchenko --- V2: - s/Arm64/Arm - drop from dm_op() in xen/arch/arm/dm.c - update commit subject --- --- xen/arch/arm/dm.c | 1 - xen/include/public/arch-arm.h | 1 - 2 files changed, 2 deletions(-) diff --git a/xen/arch/arm/dm.c b/xen/arch/arm/dm.c index fdb3d967ec..67d2c950e5 100644 --- a/xen/arch/arm/dm.c +++ b/xen/arch/arm/dm.c @@ -21,7 +21,6 @@ int dm_op(const struct dmop_args *op_args) =20 static const uint8_t op_size[] =3D { [XEN_DMOP_create_ioreq_server] =3D sizeof(struct xen_= dm_op_create_ioreq_server), - [XEN_DMOP_get_ioreq_server_info] =3D sizeof(struct xen_= dm_op_get_ioreq_server_info), [XEN_DMOP_map_io_range_to_ioreq_server] =3D sizeof(struct xen_= dm_op_ioreq_server_range), [XEN_DMOP_unmap_io_range_from_ioreq_server] =3D sizeof(struct xen_= dm_op_ioreq_server_range), [XEN_DMOP_set_ioreq_server_state] =3D sizeof(struct xen_= dm_op_set_ioreq_server_state), diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index e2412a1747..023cc2f468 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -130,7 +130,6 @@ * HYPERVISOR_dm_op * Exactly these sub-operations are supported: * * XEN_DMOP_create_ioreq_server - * * XEN_DMOP_get_ioreq_server_info * * XEN_DMOP_map_io_range_to_ioreq_server * * XEN_DMOP_unmap_io_range_from_ioreq_server * * XEN_DMOP_set_ioreq_server_state --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 10:17:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 10:17:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106007.1456807 (Exim 4.92) (envelope-from ) id 1utO5G-0007lQ-Op; Tue, 02 Sep 2025 10:17:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106007.1456807; Tue, 02 Sep 2025 10:17:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utO5G-0007lJ-M5; Tue, 02 Sep 2025 10:17:50 +0000 Received: by outflank-mailman (input) for mailman id 1106007; Tue, 02 Sep 2025 10:17: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 1utO5F-0007lB-I6 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 10:17:49 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0f7e6dab-87e6-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 12:17:42 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582AHfYj029339 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 2 Sep 2025 12:17:41 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582AHep1018068 for ; Tue, 2 Sep 2025 12:17:40 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 2E7F9107F7; Tue, 2 Sep 2025 12:17:39 +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: 0f7e6dab-87e6-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 12:17:39 +0200 From: Manuel Bouyer To: xen-devel@lists.xenproject.org Subject: issue with dom0_pvh on Xen 4.20 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/pxNkvLdhZauztBH" Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 12:17:41 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 --/pxNkvLdhZauztBH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. The same NetBSD kernel works fine with Xen 4.18 The boot options are: menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh and the full log from serial console is attached. With 4.20 the boot fails with: (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Freed 664kB init memory (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 (XEN) *** Dumping Dom0 vcpu#0 state: *** (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- (XEN) CPU: 7 (XEN) RIP: 0008:[<000000000020e268>] (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) cr3: 0000000000000000 cr2: 0000000000000000 (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 because of the triple fault the RIP above doens't point to the code. I tracked it down to this code: cmpl $0,%ecx ; /* zero-sized? */ \ je 2f ; \ pushl %ebp ; \ movl RELOC(nox_flag),%ebp ; \ 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ movl %eax,(%ebx) ; /* store phys addr */ \ addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ addl $PAGE_SIZE,%eax ; /* next phys page */ \ loop 1b ; \ popl %ebp ; \ 2: ; there are others pushl/popl before so I don't think that's the problem (in fact the exact same fragment is called just before with different inputs and it doesn't fault). So the culprit it probably the write to (%ebx), which would be 0x20e260 This is in the range: (XEN) [0000000000100000, 0000000040068e77] (usable) so I can't see why this would be a problem. Any idea, including how to debug this further, welcome thanks -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- --/pxNkvLdhZauztBH Content-Type: application/octet-stream Content-Disposition: attachment; filename="4.20.log.gz" Content-Transfer-Encoding: base64 H4sICD3CtmgAAzQuMjAubG9nAO19XXfiOrLo+/0VOjMPJz0npP0FGO7tWZcQ0s2ZkLCBZPde vfbyMrYMPgGbtg2dzJoff6tKtjFgQJB0z8tldSfBqi9JpVJVSZa+8oAZV5pypVUWEbc0Rasq pqYGY+V/XXzt3H9gXwFgxaPYD/cBsotxuHzl0f/9wC4mjsMugrHOoFxXFcX8wFTlqnqlfGAu Hy8nn17ZaLpkreWEaSpT9aZmNnWV9TrDEaJUU6Z3dsLjhLWndjDhQ540WVowXvozt+K7TaYr Gm84NdXxzLrrmFpV9Rqq67rcrCpavVFvVGtavaZm1WiHQRzOOAuXyWKZMD9m8WvgTKMwCJfx VQbUf2RPPHDDqMm6QcJnl+zWnvuzV1ZjF8pL7cMl64UunzHDwO+aAw+GCV8s/ADqwy4i+wdT FEVTao72IaV5Peyzue9EoQOYLOIrH5uyyZQXhT6qkQGGYTILbZcD83ueXA9vPr6YNXbdfRhS 2SUbpMiseqWq7OJ37rKeHTHgrNSbhtnUFPY4amM7atAVXhTOU0KscdWAf/qHvDHmcztw2cwP eJO54Vyx5nz+SVU0o8cc0VKfnHCuMvzxSTcNRbk0A5XNwslsNftkz2ZssoQesooPgiSxx9bc frGCyPIie87jTzWD2tnKiKrE7dNiNS2olz+3J5xh3dnYjjmzXTficQxtlAI9+S4PmR94YTS3 E2y+tIA9fW5hXyb8JWFzbGATuqV6ybwwSJj5otZywOvOx5ubNpvzZBq6QDsIA/6/Weeme8OS yA5ij0cs8efQHgqLOcjrxhkuASF3QEqgC5PI5yto/DF37CXIG4QMSacF9ixlAhqfcCfhbkrn xo+d0krchkvoDBgF1wMW+5PATpZQ/+3Szs1NEZvFSbR0ipDQlBVughIMWj02txc5/W/K1ueS Fb406mPP+5NdLGN7POMfypAadWcbyfMICbjzCNqiFI3v8PIk0NQtEcdevZ6i7RMRQEy+jWQK pOR1wVmjDKWxw6fhCj6tdr/LXDuxS1k1dlg5XgHv/mlYiubusHOPtgYAcWcLzTveiDz9vUbj Mmge51to9OQomudso0lwUzPgHK2mr9E2e/qe/ygYii0b8TJOxU6BsROabDC86SPh21b7hlho YLIjjUpbvQ8bsF+HNyN2fQsKoQpxzDbAqmzYa3dZ4aMpqqqYis56w9tR+qxR36QF/PqCltYg WrfIV2eIB0Ybi9WqUpWidZPLVWsBrVq1ppNcMKXWFEX8hE8mnsK696M7oKxUVVXdlWtItDpp kxub7dXqd9uCl05yq2qHeKVyY7G03L327WdBy7gmXnq7SOuh0yMIKVrDu27aBsatoKVs0SII KVoAfJ22gSH6ubpF61q6jsNBS8jVor5R1MaOXAiRfVTRN9m3TVpf+p2UlqmLOppbtAhCTmd6 rUFaR9J7NW0v+LR6oM1AjEByuQ7VMdW/lqp3kJae6t/NYtKfzxGjvVj25xkp7ZD+dbr3/53W sb4hF0jVGeBPi0Bk6njdGaTt1VKKOlGgRSAytDqDYUaL2l693pVrMJSj9aWT0bqm9lJa5gat 67b1pXOU1vA1TvgcJ/Em04xqrQ5KewHuLfylKM/XuU187LXAUUSfR2H9rz34eWSeJ9Mqhb07 BaeG+Tj2rlnX9f3YKmGrObZu7J8UNrAfY3S5VRMcPXDbppxN7XjK4qnvJZm3Fc5tP2BTbi/A bfIT3575MThtoP3sh+8mU6ZrbOwnmffkkZs17PVZr19JcPZhdsJoMqubma28gSG0wCktSLKY QUhC5tONfIiUwO3z7OUs2VCNfq8yAucyYt0H1g+jBOctUwH1gGkJhdg2ep1OH0bT7UOTLebq i+UEyTe1aSrGpdpU/rwUD/lKPFTo4QaB4ueH/cyXC2vFnW+p8+IABfhqxf4/+TdtC/UudMCD pfqkcyyI6m1OsQ9Qzch3tyv+w4dWHfuTeL7YINl9IKgL3/0GUY/6Z0b4GxIWvsOfbBL7Fs7s 35Q/s8YQePCgyeyF71g+uMGXeTCqa5cbEmZOyOdhlykVTT8ggr4lgmlviqAZ2zKoBRn0AzIQ JSGDZlSM+qYQ9yNrOGhbD08DiJmXgALxbGz50Xf4azILx/aMvmjM9Wb4/4MseqOI3mBTfzJl M4hRtikMflPYEkfB+JWFohP51TaIdhykcQSE5iuM0knLa7auqOS2NamV3KIu9duZxwAxl+dP lpEIb5SmcPQyXxaCsskcxh0ZBqw4hwZQWIV53g4lO+I2jt4cN/NCwRKwDoRIRQwxgAkPjck2 G/ijkrO4tf0ZUElCNuEJ60QRINyFMApSHRhgviJrCrT1TTYiU7KwI2IDZgrCRnRlU5P0zzw8 TA0JhhAXvdbN6AOJgwZps2EKMWA2Y/T64MDNZuEPykMYmMeI2QVMyNMwWcyWE3qQa/TgNwj8 52B0mswwUVUvAQf+6g27H+F/5WsKaEfOFFMQH31TqzaunKZuGmDJ0DDMfJukndvxc5Opzjp/ At2monN6dXXFtFqtznpf/rlNz1ksP86dKXee4Re3fMy0APl6XcP+a7G2vbDH/sxPXpvM86M4 GdvBM4NhBVE+D1xMe7Q7IO4An123W8PRJWuDr74hBeVvQEBn6gecETdQgwXYXhScB9gtWdMP F9xZzqBJV5xBw/gT0dKe7aAUPo/zUJp9sSP3B+gXjLEgKXvucRG+r4va4XyBalMB5YuXiwWZ /+79TXfQaY+s0ZfH+3+wQWf0OLhPvwy/tG4efrf6rc/d+8/sS2tw07m3WoNB64/sy/Wgdd/+ kn37/AiaZrXa7c5wmD27e2j/I5cAY6eYJ1hz6PTrUbcymi4D6Dlg23+46953Ltmw32lb7dHg DqfmS/YAk2oEsMTIEkRzenfq6BaGJ5+JPMhqOQt4hA16CQ3+spi+xmgUAeyGGcYldkgX/oLO GtpeHrqx3FXIbQFjQ9E+pPpfnnrsqRdjLHfNOq3PnYF1238sBe0/HYL82h/BmKoZFZhpETQM Zq8fmughKJkiXOK3x+wbu8CpLFwmaCFu8tAVcbHq4GfYLg22lIjrxyVUNsZ1DBroLmfYpjik 2xF3QZhh9hQTgxq7cOhxnjvsZkYCKQgUbU0pEwsTZxZ4JQ4lBy1ygmAUmhvlIC2InBXqeYuD 08MjgoDpww5gOCYh0Ma/1vk3svL7gCrZTMuiZfB9yZdgmO0oQkuIhrTJ4tB55pk7xBzwxzia MIeK2QQgYexFNNpVZZ75Y5QOTCLbecbKC/FhTgsm4GOoSl2vG6oJpi6It60LJvHAmhgNHY3V aMdY5cYfBjxaUsr6RZhFVI0rXTXBYNH8lbl8aRIPrVntql5toEUDJzB0QIfDKDP2txEHGMyg Pl9Do9L0eA3Dcc7nYfSayThLmHAt0aM1NRfiUMMe667JKn8vPhu7XqO2RnIwvzp3MEkLs63l Tu3Ahfb/L0xBf1RedBtUEPPlRyzsX+m3Rc9pgOJsFITQHe44qhlb/NzQSq2nwABuqgfcjJSZ oG8588BK5TlML4WfOzZmjWFwAUHDsIFi/TT5A2hpy5lxO8J5wYodOziDs904nTOMMRwJ2INn sq3Wa6ezleywTWLZksNHJ4xgPPwVPRBujcFNRDFACLVUhhwtEwGeQr2/U7Z/vY7xFkEif25H r1YyBS8NDFMYoWrp1C5yItmLxez1fYTJH1jLhWsn3Jry2YJGlq3jyJKUKO0nmOjJNfgZ8miu tlegLTGSl8SKYQZzphbavMzvfH+RvNq/RyQ0TVtSoXUSxlBSr09Sop02CAPk6MrrrBPOZjCP WDicaCnpHH76CQxPql+xfyhunEEPYZOqaCUxV/fuPQwxY5D43iu2CHKqcpxb3EOcwOJDlTBy EgbyJAaarR5lIEsafOnlAow6fLEwPYDk0VwYZkqdCFG+YOZGFjrEMgS7Dxm1eh3b3a0bghwq DTYquF1E1XfPoemZ706zoevvTtNWa2+m6QtYC2hbC8e3Iph9M402ix7Te1O33XegTsTF+voP 8Itx5Bscp+zq+P0Je/abCc9jn+a+EByMeTwh/QWi3ltorpMP0XcYmZYd48o45rcwk5mEOP/o Y9S+emadxHMLsGFgYgCPI58YSymhBUQcy/Y8HLyvQN7BCVetvaUWMTy2uv0uYQJJTiSzhtko PYOa13gXajGfeVsk8BFMBBPbeZXsJhF1/ZVcOidcgg3FHqKhbGyb3CLsdAEtTwiHGSEO+KHx co5aq1HNq3sJIxiRLicqckNPo4oLg2I+X+KWD5FNgKhtgWvMmBrH/Njz9S7KMAjDBW4oSqJw lgX7V7twlBrA5YY+KC94u+FyMqUdJPtRfsPw2YUnK4haXZGF2g+Nf0bRcpGwAZ/bYhfSfuh+ GCe8iHRYlOEUXFmXdfojEbLGZfDfAPTmT5H+jz8u1vX8uErcj999rAfG4prWZL91m2xJgbhW rVVgbo5eWQRfL9aZyY8PbOVHyRKXajYqnyUPKqJRcadPEyo9s1/ysnW9ou3GSCGCyBKpCOjY LGfRSRM+rh+JKL/z0BXrGKm1tCGCC2cuC4P/KKLkSx8oyhVLkzwaVQGfZ1mJzn3r+g6zeN2H CsF3B7/lO3sg5hd4yKDV/ke6bygtvroadXudQTO1a5+Ul1uF1iDUTwqD6qmfNPqqfaqo+B1/ p6i/w4hxwAo+szhcRpikafcehmwwamdZemEjob7pxizqCRZ6TNVM9g//Ouvg+Q/bTyo+RPdN 1vu91R3BQBnHCW7Pw1y+qua59CLkSrkyrlRqmxnDJEUJzIyal3IvMK5nvgiqiTIuEqSfFPGp 97WZJfxAaNtdYe7J3U22VkSv9HrdB2Y7mKLZ0qgtwFF/kGbz1gWdLMvcR0swEsp/AQPhwxrm SRCt9LM8EOsKd9OHgcAunvqFtGEOze573fVDzF8Ltaukko79BDR3DfEYQNWSyCfF/IzTdray 8NRrstawexNvD0hqqBtKR9IAeOHOUmSccCCDkeMR2reYuUuOyxjtp05FU1SzomqaUi+SB0pb 44ce53nuFkzIZFCglZDVxZdW/8P2ljeB0upvG9VLpvXgh/o5M69vyoxhVGhB5I1Bxzo61VVK cmTTN9j5MPhYBKWorIC5CH8cy2GVc2q4P4HTYulF/Ltlu24WIdV50VPLJz3bWfgfU3D6gsEf /LIyEiLk9I9MsLsM9YZzPkP+IsvQxeiRGLroimo7s/o78bNyeDFfWYkdTTgm5TRs2J2U3FG2 Al+WKQUL4cx30LXUDdSYnUj+KEsQGyLaI3nbktmYHGn0dJCg+z9LCADQk06dXZ/HFIFj6JKK tG9K3yICj7YIHQtBAN0SZsWCkBymAORcbH+RTtgA5P5chmyaKgGTauHeZ/LSU5ppwEZBj0X+ gQUTiQxRclIJmWgC8U2SVH4SRRHvkt8LgVPmJOsb1d+EkaEK6gH2ZSJctSyfmmvYse4UNCin DtFsmGSUTte0TYrucr6w0PZbuWA1pxAaHpML9WubhkxruLT5h6wesDQp3a3JtkVBAQt0ZNhO f7ioI4Kr6hRin1OYrqmcUFXkEoVoWzRMcFRP6viURgLdD57QkWUNgTILw+el6BfkWTuFZ6Gu BTIyXP0wmY0tb7aMp6hKCvarelJVCVfQOZEhJhYwYYKTPf+ZPJcBWBNUIAU9GM05o1mJhHSr Zuwa57I7hdn3pR3Z4CkHHHR2lQ0WMle1M1gXyMmOmHgZL6Acq+yeMOWhLUpR5SaONFchEo4n MBGYMjycyAbFiqfLBIdt1oyyNgd5bVKQ6z+Y5R0a9MaJFUtRZbiAY2Vlm7ZQT3yHW2IpPcv+ GCX+wn6s0yeyhYPel8vTxKOgRsMErY4mO4NFmwQsaGUAn/qLd5TI479AIkp0Q1uueIGzq5AK nDFuN0idwdlzfhFnjIfWbHVMbNel3apdX/YstoZdO5ftms6pPL3qz+aZOR+0iAI+iJPgBMvR rJjSs3px+EPxAnfonsFVU7V/B9uq5p3LdmMUn8XbrP0C3sh1boXoYVQVDPDHO6vJZWEvmnJn ie+RQtgrlnIkVyKIGmVYcMkYs8IirbjO13ioYVXZep8Z6p4gj1qziwKt5i+U0jg+I5/AQ+Ol PJZHrH4WU7tpcpYSBWgDzX2dSLAgRUwrNonvPMcWn9kL3BB3Mit9fBorXJwLTuqYAhnKtOQb ++gpbXKhlVd+TAhU2LUg7yqCrv/7RRh7/3YReP3niUB7aPLVCdz1hF9yHajWSrdZ/grWZvkO z3dhPV3NP8bwP+CYyYe/gFAAv6zV3BmnGwXQ7EcOXyQx5VhxLxGmasnlbKRSBWhOAMTK9k8f ZC84oOyrebQMKCeEfqTjbFcS5QPS+B9DCGCSGgkhmnMkh17GqFFk9Fa5zWr1jeSmEDn/sGfP 1p1qLbQ5Wlc0eeMiRWIJZBf0ctIRollPik2jhd5DcfVivuREaQ8RHtffg/BqjgpmBVqg4u4L DJvrtXelaVS1ItF307O97MZvqEOubWJXHYVbtWKG5s30NFpROpfeutJigSldfqddUDgqilSh NMK9x87zMbKkYRCiQuOjETqwce9Ip3Hv2BJbCauxcQ6rY/pRwsip/wxG5NXljGjIczJ4O9PH uzNqKPWfwegAHfAR8hUf2spWx5kya1LckzaPJ6ct+ZCupptYSb5sH7hqnmncSgiaurZB8UAV cc0wiR0r9Lz42EpjGSuPm7+Klao2vDc01MrH94ntwJq+QrziiFQ75fmqZiFkEUoDNbDmUhv/ qVq43dqCGueyVmkzpfkzdHUPQ9p6+wsZ1pTxL2aoGucwPG6kD7AcK5IsT9HtDTJ8jm+FonsN 3/ALZZg9sR3DKQtNd5l7GMmDhXpdu0xvkmCxzCQwyI64bxgeUmxUwyjyOVLVGbdXb+O8mnvL gLYFGIU1oQNshX8s6KTYbxLAscHFFRkrAx0kVULFfoz9YOXKdjGqcSYwvSoQBpRzrZoFx+kA twlP1g6XJfavHedIC+mCLb0nmojXZjS7sKD5TlpkFWso3l1Rx1g5TaI/45Nrt0FsSmEs6gSW jW3x5iKO1kahkpRg4/aRaek4YaOMMK5oR/yEd8H2kq+ZZXLLJwbXhLFHoDvQmk7JluJuvKz7 q+/R/Ws+qY13ou2tAe81ESETVJPIRbuOMZd4/0KryjHbwT3ODsecEG5hkxtXWPw8MlRzNLlK FbnoipwNjOXZ7OmzNQVsFs9/4bhCTplpiVnulCk240ZamPuPilx7biJKGD2xtQV3GAffl348 xQVi2hQdZ1x3Moq7XA9QeasIpLK86DS/B7P1iUeUP6YF8533MPbWc419nOEq216as6vRdiuJ aWwL9RxequKdwizdJSXJab2nqvzFy7cymc6SbH+I6R2lzVc8gOEN5KTslR/8D75vSljZQJbQ 9CLayUwatW1d3sge4298qeNUsnbtuOwiUyrSb5LCu+F6kw69b+kdb54TO6HIYqzKscAZI2Ug WxPMIot8nNgoSeeP0ehA3arViz0iHZIfImxQ4rsmOyJy51xmjIs+BDQfJyB9I7W8h5GVtZuz OPLmLnKYx5HYtpsrJ07ntMwiYSJ3seV8h4ijg1I8QOOIDgCCpBN0CuVYlvLaA0/zttly7M77 AO8Vn5RxrHrbqyHyqWRBE3Qpzyll21WxrzUZW7iDLNfX6Rli2ND4jgy6waTGkv7iNvp5/hzE 4RQt4Jv56GcIR1zGOUZMTOsSqpwOOpGCOojuVFXCKpyYBNrkotMingwbcS6N5Ugoypq84eg/ txYl2qHSqzaqxOxQRuC8WBCPcyrqB8dqNyRMCGFK6ockc11xJZmfFSZi3+AMXC196+ZdOhan BbHWUJxVbFPS8S5BP5cnVFCS6alBW4Ivluerh1Va3bQl7OjJfbYShw6RrqdZKnNc3HDwk5nR 2VC/ihktBf4qZrTy8auYeWc1o9x4K2GnqbL8TlX8jUWpDTN5asJsm1pVxu6d5t7i4Ujgpfvk s6Rs6N2+qvMGocuo1tQi1TcLv0FgHoLzFeJ2RuysAJ1CWyQzjEKK7+T9MWQ2BWmLLqTB0U6v 2RyZFk4MMbZYqKb203loyvvyEHHf5lhDQ4ytZe+0PxWfRHAjj1OMXtZEZXNDW5SzBMwWNam8 zGaz0SEF0GrisALyWqa+63LaS+ZupeYFNM3KDl1cdMTtzA7iQQTCTDXcJTOmvIFyXon5/KOI vj6Kt9JxOE0zc7ugF/dp/FMudEwvD8nP59OQpgb9J8ii1+q/SBbhk4IgWY4CN4q4IietyUyW Z9i3NXehAtpGU0AtrNQ8a9gUdKTUyeGI9MaaPcKs0z1FYVSar9TxuxmZM8Wou7qMHCdm7PYK o+/rIB2ncAONV/29/eBjwuy2jE5r5jYt1v/8DjoihufKyPFeHWTs6yCDtlDTwRnKr+ogY1/L GKJlaMHiSB7mHTrosBgmhaZH5XhDB03tBf7HiB9M6rprsjdIJJJhZ/dHKe+tOUajsws1iTWR k+aYtS+yN3lOJ8uaRW9naxv4MQ7gDdOddTRhzbSJjVQ3Ug0nO8bwGxiXeGa6d8LSV9pSyFOe Xfpm5IrWYSQzzEVuYsvP0cWFIsv0wHbBk95jlkiXvJVnvppY0wqe47s1KTJKN2USYsp7/GrR Qooq9jKd2LYnsU1Xj7cZm4rk/rHTGaOFFEMMv+WrBhTu1tVzx0JGWbyQoY23A0757b/UOOl5 /dnI18bvQqtR3aF1Uh2FMZysbHxnbuIFmV7mixSniVdGj17h2KR3kqHLaOIpOOK1I0q+nNcX KbFUvYTSpFRV9WyqIjBbnyihNcbFbtk4Sya1OUdPM8pHiBhP6aYwcXZUKr97wo4ZWknN0KXC x41pV5yfsD66ioKi815pob28qZGgtwdwGyK+TRtPRY0k9lTtQ5f1DWJ8uVgkzdNXBLKcUr4w cNarA4hEZzD50ff/yo6m0d5CMVVYP1jNFihkrSG3FUsgSPREnkCiF8Lz3RYqHZxXk5if0okb 0xL5AsTR/R2HWOs0/cuwPn3b+h6WhifLMjsiOPIXdMwwndkot3/QsuIkXFjJ1I+zw/yKhzSt pPd1xokd4fofXk9si7NQ9I3zrDNSx97rxux3tpWOcoeUc5Lcf3f6XvoFT9AXT88zyw+frusF lT5rkBDJcRTarmPTy6p0mpBGrwbo3lso4wZmCnw8f4Y3f0xiivWx22SW1k5YQy/lZDg1KVZ4 Qw63xK3mYKRj//gIzPmJ5ZOUhuy2CMFQIt2bWvvCERuKWFfTj7qCZ1Rql5tKp01Ic8OmCGXt 1yYj/aRqOenB0adyoW2V0lwmR6qD96Wx0HGWEZ7yDFDt/iNTsmNkr/HCNbPJuK3WNddUFAX/ j5VvbPOT3x15TedmJOA64D2weN1cWpDecIUmcuOmJzBSl0wlrgseiUutKtk+1xT3/19/JX/9 Vcul7Awek6Lgwb6ZMOtK3OJNegQAvZ0VXzLbSfyVjXPYLiW1lFIBQDsGoB8DMI4BVI8B1DYA 1DdUt15KqQBgHgNoHANQlaMQailEepkUuOGzJutt3GqIzxBb3GNGLsL6QOjcTKTXoqm6aabH gdPFaHiadsLqxiXEKi5/YdHH7CTs+6/sokPnR/P0RGn+Ae89wwOe0axQS2ZDFawSmpm5/eLP l3OmGY0a6xfOOv/b3/7Grpf+jKpps/7TF3GSOzxPIW7p/l28uwBEehwwPGDIpnrhZaDwadK/ K+UkePVEeP1E+OqJ8PUT4Rs5PNn9wMf+EqeFg5bQMedkalh2ke1ldg9tZpnpKFk82X3VB4uP lyUCJY/uMQXjlalXT8hBJ/9zuta0VB7VyOURB/GLw/Xs/MoNRif3ZMexhxFYV7yYfg0QN5m2 WapulqqbpdrBUv1gqXGwtHqwtHawtH6w1DxY2jhUqioHSw+2lXqwrdSDbaUebCv1YFupB9tK 3dNWnbvbJltM3Qh+4t12n2jNGy/dBaWK//kJ0zKGZxjmfnjV2ETQineJErzQT7ypIKVd+Tuj O122AQMwa00mLlIF0/iJ/eWeJ9fDm7/sA3rqDIbdh3uENK4ajRI4+F6EeuFBBaxLCeBTdzCy rlvDDoCtbz4wN69GLcD3Wzc3A+vh9nbYGSFKCcSXP4a6ZnXuR4M/iKimcMMtAfzyR78zaLfu 7vCy2W3+muKV8v/yZA1HLZD57uH3HCUTt1zk205r9DjoUMNiFJYehZgH0+Jk53/ZyyRcr2yI C3YgWPsX3Vuw8vEwKEzZWc88CvjsX7jIkr0rmd4KVNK8/VbH6j3cYO3+8srjEog71erdQme1 7ro3JaUPrZvOALEnPOCR75RQGD4O+537G6vdum937so7BbTJGv7RG7WuyyQR0wHOi/7cnvBi UXpfbvFKYUa3Wog0b/rBjlAKAHiDDw2ULFTfBiAKaVkpBQJ4Jn9iDbAxxtZQEFwUBVHrY3vc 2AETl74UiRXUEj+0blCo1IZGbt0JkhsEnF+S7SGul9oOnGwQNLMcAhacFcfOYIvzGuhe3ubf lK3PJSt8adRAsD/ZxVL4SWVIjbqzjeQJpOzI2lI0vsPLk0BTt0SE+tZMXq8fEDEFMbeQPBN5 0bXkrp3Y5XiNDWZjr15PZcSbcMvZAZDJt9FMgZa8LjhrlKE0lG2Uhis4HZAQoXZYOV4B7/5p WIrm7rBzjzY+AHFnC8073mfZXfVrNC6D5nG+hUZPjqJ5zjaaBLf8xu4craav0bb7Og3fIZT9 kQ0osALfGV78Gk/xziM0PTQecTjSHTFxFrcMnWg5HqP7iTcrs0GrBwEKQ0uPx60G+c3tiXvF 7sIJXVrZxHuN0gK6Lqe05G+nf1LM31uD++79ZwifHu6HD3cd9vA46j+OWHfIhn/ct78MHu4f Hocp8GjqxyzNwMBfmCCnS4XAbbd9l9GuzUl66RLezz5+ZTyIl9E6Mk2m0DaYDBKJMKQSvwbO NAqDcBnPcH/jDI8uFfmbZMqhPSNqcIgNs3b8Ev6ABoiYD7GwHaAYUeguHc6G3c/33dsuzFgj hrNt4OCRpjbYcduDACJLWGDY+Mw5Xqd1xbokxP3DiOFNyPO5qBHGFAuiSpVdxvw/3tzU+tXV FdPwh4o/ClHkUNTRD7BJoDFvHnoKuyCL8Z94fX3F/k/SME6iU5gklqcFSqac4r7uWg2v66aD 4zcu6naVlcJG4JzghUS4bYNVAGoVUjIG76XPT0y3RaXVgoQ3yzndPkYzCa7J/lWhsAh8gHUF K/D5hh1fMa405UqrLCJuaYpWVUxNDcYKY7g3u2YwoSmfYNoc2ahEELUx1sa58U+kkaXz+o/4 nGVXOA26ffoO48psfvs/Sv6BKVermX/PosPB7V3r87BZnF5wkNeQx8P9qPN11MTNxmKvKrvA dslaMLJf1ngguQEWRQe8aPxSpEcMFXzubDxXXI+PM3Ejd6NM2BnEif3N53r63N18rqMRzGiN F+uyzC0lWoXnCnoAGjfwudlkRbnok9FqlJQhjqo0y5+ru88zWqq2B0ff89w4QKtaiuNEO3JB zIjP99NyonL+TlQib4rjxeNSnMne5/FeWi4VqQjG1396KQIh53/GawBHPM3ctvxeMhp12fBs gqEahyGt0KWX2WeTk7iPT9Er0GKPtJBJeTda1+gOBjtgqhyYJgemy4EZcmBVObCaHFhdDsyU A2tINq9sN0j2gyrZEapkT6iSXaFK9oUq2RmqZG+okt2hSvaHJtkfmuy4kOwPbU9//D+Ft6v0 qJoAAA== --/pxNkvLdhZauztBH-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 10:19:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 10:19:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106018.1456817 (Exim 4.92) (envelope-from ) id 1utO6R-0008Fw-2N; Tue, 02 Sep 2025 10:19:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106018.1456817; Tue, 02 Sep 2025 10:19:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utO6Q-0008Fp-VH; Tue, 02 Sep 2025 10:19:02 +0000 Received: by outflank-mailman (input) for mailman id 1106018; Tue, 02 Sep 2025 10:19: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 1utO6P-0008Fh-TN for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 10:19:02 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20613.outbound.protection.outlook.com [2a01:111:f403:2414::613]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d60269a-87e6-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 12:19:00 +0200 (CEST) Received: from DS7PR03CA0236.namprd03.prod.outlook.com (2603:10b6:5:3ba::31) by SN7PR12MB8604.namprd12.prod.outlook.com (2603:10b6:806:273::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 10:18:54 +0000 Received: from DS2PEPF00003442.namprd04.prod.outlook.com (2603:10b6:5:3ba:cafe::36) by DS7PR03CA0236.outlook.office365.com (2603:10b6:5:3ba::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Tue, 2 Sep 2025 10:18:54 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by DS2PEPF00003442.mail.protection.outlook.com (10.167.17.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Tue, 2 Sep 2025 10:18:54 +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, 2 Sep 2025 05:18:53 -0500 Received: from [10.252.147.171] (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, 2 Sep 2025 05:18: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: 3d60269a-87e6-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LXOSzFPb2FGWL5b7LTjIVYIqtP4efcbp2FoN4Ubo+Y245FNbHufoH6OUG/BNpIqh4D2SKaSDeuFdmWX7GTkZgOmqsBqG/cX7cwkqZL2u211rYXBAFEILv0sZry3pxWTT9zXzs/DkMMYmkOsE9NR0nbre/oKs/nZKp/VuW4a+Fn7vJuz7vzi0gkwZ/vTREvEy2rlPy0lWc+Y8Apd7cgUtPd4zrHFRbLEYaX3iWDbsIhcnfln/AChdfW45ljL5WDHH7/YqgBx6ksMwW3cDzKmYuDCPy3GNDe7/hpmmqOhGo4uQq55gvSVoS7nR6FdA4f/cSmLCnhsTNEekQa3EEBXPdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CgTOqle6Otd2aLtwdCqdFpw9U+fbJotdJG/ecMLIEuA=; b=n0nTzmkdUUu2E8OcZSlOv+6MqXZgv9gwuAunu+jmITmL12OiYbFjSSJg6u1xug89GY3m4p9P9AJGkNCYxNPumVO07IVxN2SbAxU088F6OHRsLz6KH/xvCLjFEP/VSFgfJyAxF9LZ3hv4YTPk7Lo2ETb/eeQcxDTqKBkhXYV+zHRCNCVeZKmGh1nWiv11YiABUH8P1z2lzej9wxTGRUea0TrmHRFlsNsaHkq4krEwYAMBTgkHzefwis1cXnHN7VfgYSVc7gVMR5LegSUAnJqE6t2OVc0oOnoWkqkUHegoAYjiO4QxmnbOGx8vBA4GlMBp02zEIZLVLy2zFxljtA5/fA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CgTOqle6Otd2aLtwdCqdFpw9U+fbJotdJG/ecMLIEuA=; b=q9KeMXYn/MCGHd01+Rpp5Ek1doj8sw0Xw1FxYkVTcYexokXnYYlJSNsILXGqPIayS2OiJhWTOYYIlMOY8kIN3dAv894UhfZ2r23W5HgEU4mDaoeJf9IQC3xArehPgIrwUHy08tx6a/kqLW21Zddh7pR0MtLitHgrTwbBMYA/XcA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <319c280a-535d-498a-b0ab-93882663e23b@amd.com> Date: Tue, 2 Sep 2025 12:18:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF00003442:EE_|SN7PR12MB8604:EE_ X-MS-Office365-Filtering-Correlation-Id: f7978943-362c-4ea4-a331-08ddea0a1eef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NW14NHpDTysyNkJaSXJDUVpRNkJySy9qRXRPRGNSbmN0YXRPUTlQV3NCQ3JN?= =?utf-8?B?a05MZnoxWFM1TGVPbmRNUEF2NCt6dkJUKzBSR0pHVDZORnFGQlNMdXE4NzQ3?= =?utf-8?B?VzkxTlB4dDd4SWsvRENBb2dQL29pOE53b1JYanViVWZlbVAvR0xyaFVwUjEy?= =?utf-8?B?K2NvZmFXYXRDNlpHWDRrcXpRMG1yaWpoU2Z4ci9nR2t3ZHNOeWVlZ05BMEty?= =?utf-8?B?MFBTT1NJNUgwdW5IV2RBVFBPbFhNbUF5Sk93V1lJelRrVVBIb21pMmR2MjdG?= =?utf-8?B?ZlBLQ1Y2dXNyOENkbVNoeWplaHRjc3ZKbWlmTENqQnJvaGRaWTRwcFY3MTFi?= =?utf-8?B?dDdBZGkxUWhHRXAzM29WeE4xNTRuZzVqSC9zcXl5eWIwMkd5b1Z0Y1RlVlhM?= =?utf-8?B?SGUzaW1YY29HUGtFZThyOGdZd3o2SjZpNnk4TDcrUGlxdGN1bXpiMFpqa3Yz?= =?utf-8?B?RDV3c21Bc1ZWTDEyVXdBMnFRdFRwbWR0cmhGQ1QvblRQQnQzbVBSbTZCaC9w?= =?utf-8?B?N3A5cS9aWDFSb2cyMlhkMU5GY3gvKytDREJlL0d4YWhvVGtnUVVKMy9GMGRu?= =?utf-8?B?Z1N0QTZQenZWUWRkb0lrQmE2OWxlb2VQMXlvMVBHYVNlV3pxMXlzYWR2RHpq?= =?utf-8?B?dnJTS3NHMnpKL3ZFMklYcGNCODFQWlVURjdxcHM5OGRBU0NzRzdNa3QzWGR2?= =?utf-8?B?Z29nVTNHZ2pUcXcyRTJjR21vVWhQZWNzd3BUbThQT0N1L1VTMmpSTFhtRHdu?= =?utf-8?B?dklnZmdhL2lRbUNmSUpBTzBIYjFZL095bkpESGtsMlVFZHJOaEFNVTBibzFO?= =?utf-8?B?ZVpKNUJzSkpxbW5hMm52YU9PQUVlejlVVDBHVnlUWkpkTlQyTFcyZGRlclkx?= =?utf-8?B?eW5MeTcxVjFVdlZXZVVOZ01la0JnYmxhaFZIMmwrZGFDQWQzWGp0RktSRi9D?= =?utf-8?B?NG45WEswcUE3MTY3QzRXazZ3djFQQk92aisxSVRqNitlWUp6K1BFR3hNQS9O?= =?utf-8?B?OWpiTHlsUmUvL3JWRlhibHhveWw3TDR5SDBkcFkwaFJQQ3gxOUVNZFBwRGhn?= =?utf-8?B?ZGFmSmEvZlFVdWptYWtFNzZzek81dUY2TnpJY3BjcFNrenRFL2o5QWx5ekRL?= =?utf-8?B?bm1BUUhxb3liVVVkUmI1dHp0aXMrU05BcmpLVEV3RUcyc09EWWZ2YUgrMXUr?= =?utf-8?B?ZWJiaGtBNjBBeGtvS2hPMFhTK1h3YW9CR3FwZUhxcnVSaHpTSXdyY2ozRjRQ?= =?utf-8?B?anFUa1d3RWd0Qm55czNiZXhpeW4xYSs2VkJXYnV5VlBndnFacmc0cDROdlIw?= =?utf-8?B?MGlTdDhpOSsycmQwMmQxd1NnbmxwMVRQcmR1KzV2aW00cEgzQ3FOTnJIakxv?= =?utf-8?B?YjZtcUkzMlllSDVyZi83WGN4a0NTZTlRNUp0Wm5GNGtSZXlFU2VuajNWeUZz?= =?utf-8?B?c004ZHl2NVYxQUhsWmVIRzdkY3dPK0tTeUdqRTVzaTVDSUF2UmhOWk50d3pr?= =?utf-8?B?NVVyTzI1RnFOOG92dGpEK0pVeTBXMks1N2NjR3JxYkh2MnRackd5b3dLSER2?= =?utf-8?B?SDZMVVdBV3lnMnczV2Jwa250OTZpUHhnNm1kL2V4SWVwcGE5Tk5TWnhidkQv?= =?utf-8?B?cEVhczBldDlBZ010N0orb1VpSk5sMWxRNHM1TmM2S2QvNXE0SkVYK2Z1TzJF?= =?utf-8?B?d2EzZzc3Vk9xR1k2M20xTFJQQnJHdXNhQ0Q5SkN6Mmo0dHZoQ1lYVTRxREY4?= =?utf-8?B?dk9Udm1Ialg2U1FmVVFCYjVyZ2ZwVUZhTUxDNlM2T1hROStmVWdWbmtlU25s?= =?utf-8?B?VklsTytsYTJpaktmZlptRnpoRy9kVlBmU3E3dkVyVTVhYWd6L0xJRGtmRkVC?= =?utf-8?B?M2VpSnUzb0dhY1Bta0swWCtsRGlJUHlIK0NSbmdGRUdDemlUVFRucldiaHNZ?= =?utf-8?B?Ukg2emxsRlkrSDMrQlViV2lScXRZSFlETkNUZnBUTGlmNXdVaW1zL1FzNlkz?= =?utf-8?B?eGtKWGVGOWVvV0JUdUE2RG90U1BsRWhFM1ZGOWZUWStYMVVFajlUR0JoSEJ5?= =?utf-8?Q?G2dJrt?= 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)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2025 10:18:54.5258 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7978943-362c-4ea4-a331-08ddea0a1eef X-MS-Exchange-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: DS2PEPF00003442.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8604 On 02/09/2025 11:49, Oleksandr Tyshchenko wrote: > The said sub-op is not supported on Arm, since it: > - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn > cannot be returned), please refer to ioreq_server_create() > - does not support "legacy" mechanism of mapping IOREQ Server > magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please > refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire > Resource infrastructure is used to query and map the IOREQ Server pages. > > Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Michal Orzel Could we perhaps add a Fixes tag here pointing to the commit introducing these DM ops and thus add this patch for this release? Not sure what others think. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 02 10:38:10 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 10:38:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106036.1456826 (Exim 4.92) (envelope-from ) id 1utOOk-0002s2-LP; Tue, 02 Sep 2025 10:37:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106036.1456826; Tue, 02 Sep 2025 10:37: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 1utOOk-0002rv-In; Tue, 02 Sep 2025 10:37:58 +0000 Received: by outflank-mailman (input) for mailman id 1106036; Tue, 02 Sep 2025 10:37: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 1utOOj-0002rn-8L for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 10:37:57 +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 e26b7bbb-87e8-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 12:37:55 +0200 (CEST) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b042cc39551so277222766b.0 for ; Tue, 02 Sep 2025 03:37:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0425ce98f1sm509644466b.67.2025.09.02.03.37.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 03:37: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: e26b7bbb-87e8-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756809474; x=1757414274; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=J0nm8NxkCxzoPBauDSqefKIe23HsEQbIoRtT9FTRhjc=; b=P0EoGDUr8ddQKKcWWi56sQUnNCPFjOZ5/SXw9UNwn2gs66cVNFkTE727HXA/e64NcX deWqQ9mDiJ/2+7O0CeCYiGmGzhuQuTNOB5/SY7EMEQGPeGEozO1wF/dgVSbbLt4t7Amy PLT8C/140ZPbCdP5KIbJ+Igvh3S0vhjXBKUpytETBZvyThl1S+q8oSobI1MCw0+hkGyK 75QAEMXBE2PCQ/kh15jbpnyjYReepgo0gfIyFL5zjGH0S1ozuFB5j3cHbuQLXFsLgcvM uze3srvEDz+dZ1DdM3SFVmp+yDqMO1iImwREAA2wRIiJD7CT7pBsysg42RhvEG0+SdLT ZZHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756809474; x=1757414274; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=J0nm8NxkCxzoPBauDSqefKIe23HsEQbIoRtT9FTRhjc=; b=lFE3VuPQEbuYmN54N47rkTX6oaYCHHFccbwaTAHHkiFQVWvCjNIRtK3EBGt/Agi1GB wVtsPx/4yMyqwTEdJaeNLGJNBJnuAuaatQQqostWn56agXEzFG7jm+a5vhQAStd5ETPl MI6tpwbOmr2UIZoQPB5ENFYt1A6K3lhHAYG+jpavpRLvpNKHlAp1eDSjcuegyJWVBPSx kfMPjayiu9Fq3lThzSg53igiHPTGSO+NWDidykVEFgT4n+2ij/Z0yaiqD1LNZS5vnB9V /F2SZhz6oe7G0M+ZFrIfC9nJhoS8OXRFR8RyfAVqhima2ITFw3hw37JpEYpXOd9UhcXM HeGw== X-Gm-Message-State: AOJu0YyzW/oSMvrzCqvL4lX0lHZ9VaYBm/EW0RXvD5nAuB9TUhKijSA+ qAciOQAkWZhqjt97iwDJ07JJgNmTcHKLICygqiq3zPDmapmrI527p/mhavGFhzsFOA== X-Gm-Gg: ASbGncvRJNXqD4IBh2DjctSRL4HztyT1CN9S7Dj8yQ0BE2v6WblwbfLPeZdFOWSgEhg 1LQCCbM6gFmmRMw+Kw8/SyrclDm619GKlc2UAcJBa+eu+z8yOCE1iJNqOOINSLRgpbYKBEVGg1k PGnxbGxowWIZN62zFLgXJFT/yfSFmaf30HO4tT3E7UJA7ZccqWQEb5PUalZawFMxQpuocjVQnOk dRKTYT6HAQsYnKYbYztHiA7+/gPqDCRQiPKwLmmszEIiqpDgTKvWEww8BVHQ/4Vwjrw4Sm4AiFl u/LJffDQ5XsBFd1KQAaxY1xVsQ0qXaNP/57poUiu/5t/XC4WGp3sXI1W6v/YoYWVrSAJaOahzKk 30Cp+PojtFSlsBfr0MieRmUpLSGLPDLdJGiFwEOW1aIoCP90JrZrHDkvIpJl9Krt9eKAhRaFQNu xLCmhihfKCOu5XfBTU7Q== X-Google-Smtp-Source: AGHT+IHRBCyN9Qd5DucgluDdOwHZYf7UHKJm164aLcm7UBqlDemu/QuBFdorTGRitfN9FJbUiRGPrA== X-Received: by 2002:a17:907:d78b:b0:afe:cb06:ee2c with SMTP id a640c23a62f3a-b01f20becc7mr1062598066b.59.1756809474382; Tue, 02 Sep 2025 03:37:54 -0700 (PDT) Message-ID: <2d351d66-f55f-4ca3-8a27-525018558bdb@suse.com> Date: Tue, 2 Sep 2025 12:37:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/hvm: Rationalise CS limit handling in arch_set_info_hvm_guest() To: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Xen-devel References: <20250901180814.1366701-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: <20250901180814.1366701-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.09.2025 20:08, Andrew Cooper wrote: > Ever since it's introduction in commit 192df6f9122d ("x86: allow HVM guests to > use hypercalls to bring up vCPUs"), %cs.g/limit has been handled differently > to all other segments. > > The hypercall takes full 32bit, This is an implication from the implementation, but it's not said anywhere in the public header. Without it saying that .g is ignored when .p is set (due to ... > and hvm_set_segment_register() fixes up all > segments .g to match the limit being 2^20 or more. ... this internal behavior), I'd imply the opposite from what the public header has right now. IOW I think the public header also needs touching in the course of consolidating the code. > Therefore, treating %cs > only as having architectural (20-bit) limit field is weird and unexpected. > > Remove the custom handling for %cs. This is a guest ABI change, but all > callers are expected to be setting up flat segmentation, at which point limit > will be ~0U and there will be no change in practice whether .g is set or not. A legitimate input to achieve flat segmentation would be to pass in a CS limit of 0xfffff and .g set. Just that people trying to do so would have learned that this doesn't do what's intended. (This is just to further emphasize that the public header commentary needs adjusting.) That said, what hvm_set_segment_register() does isn't quite right for the purpose here: If we assume the limit to be the full 32-bit value, then when any of the upper 12 bits is set (meaning we would set .g) really we'd need to reject values with the lower 12 bits not all ones. (That could be a separate change to check_segment(), though.) I'm further puzzled by comments in the header talking of starting a vCPU in compatibility mode. How would that work sensibly? The guest can't really set up any of the long mode control structures, unless confining all of them into the low 4Gb (virtual and, for CR3, physical). The TR setup for VCPU_HVM_MODE_64B also looks suspicious: What use is it to set up a TSS at linear address 0, with a limit of 0x67? Wouldn't we better make the limit as small as possible (0?), such that any implicit access to it would fault? (I don't recall whether both SVM and VT-x would permit an entirely invalid TR.) Furthermore to enter a guest in compat mode, CR0.PG and CR4.PAE would also need to be set, whereas CS.L would need to be clear. Finally, why do we check both EFER.LME and EFER.LMA in the 32-bit case, but only EFER.LME in the 64-bit one? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 10:44:47 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 10:44:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106050.1456836 (Exim 4.92) (envelope-from ) id 1utOVG-0004WC-B8; Tue, 02 Sep 2025 10:44:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106050.1456836; Tue, 02 Sep 2025 10:44: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 1utOVG-0004W5-7p; Tue, 02 Sep 2025 10:44:42 +0000 Received: by outflank-mailman (input) for mailman id 1106050; Tue, 02 Sep 2025 10:44: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 1utOVF-0004Vz-M0 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 10:44:41 +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 d32d0d5e-87e9-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 12:44:39 +0200 (CEST) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3cbe70a7923so4090720f8f.2 for ; Tue, 02 Sep 2025 03:44:39 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b661d87a7sm166248535e9.2.2025.09.02.03.44.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 03: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: d32d0d5e-87e9-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756809878; x=1757414678; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=636gbm3lbPMHlo/s+e6WvvL4SNwIpAErN7aQj4hde20=; b=Dn5p2p7czksmtXn2QeEPEJoKpZTuxQHQ8E52k4+hobqBuGTKb0VJn/4I63TtsYgJOG DlLlP4g3G1pCxxcyXt/ejFmOcY14CF5wj0qqZ1BsHZpfOYl/H455kbJKAYJ7noNdISrz Spgo66whY6pwYsM/EpPLvLAhbE/MVBYCsvEWY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756809878; x=1757414678; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=636gbm3lbPMHlo/s+e6WvvL4SNwIpAErN7aQj4hde20=; b=O1P508XFsQKiBGP62j5DxUoBjceivUK6dFmDBmabBX6cxZ4uyraVXyzv3XFQZ2dz5G PuMCAuwr51lQsxj6gD42o3+lCiHaeargTvlgAFW5nfX4ZhKjU7u9Q8DI1jc9sQcZZGTf PlqFh6mIvnf56J1+j7AAE/xgG0DWB3VfsOV9fATd2fuRAXuTJFSn/4XmWwG9aeODb4Ll oGkKB+TAaECse1qca0ozLDTBfFouo3qnp0HSt8dSgyrJBdCbhwzszMLqp5vn2kQwUsla nmVKJmbqUyiHMEikgwiwpIXjm848VMyyq3T5xJuKEYWscAApnpGH5DhAxZg1TiKs2xhO +l5A== X-Forwarded-Encrypted: i=1; AJvYcCVOhH8HT3aSKybzHZogV+HJRWpdn54OxogQpFWRuH/wyh29T9vJfSaFGjFHdzXekBs/XEEFmpFf4v8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx5JtyAF34AEdKwWdk9MCqOJINMFBcIJHTSPLkLKv+rAc1MHL+s E3hl0cJuOA2w5+BWc4uQKY+GBNXqGmt0GLrhQs02cyMpWEdWhR67Dh00zqSUDKGqBgO/96sBJkl 5MoqA X-Gm-Gg: ASbGnctmMuB/u963dlVSy2UCfNbL2AfiRepOAxs/Ypaep0BVVC/NjIovjil+fi3vV8P l3PCUKGDHl2QRGk5bAMtlfxdxHAGbTSeMYYyfnu6WhJUrbJMK+xOkArGCDtafyxauxBrPYA1NVz xBWmlwuhA16ovUT6xbxGfUUaLJ2KIeM9gssIg0NDQpZYeiBbtMXSOuUwiCYMK1P31vtMhUlXba9 OwhBuRPLp6YuvG3mWJaBnpLn1PWmYFxgjB8x7FMk4voSJ36Fn2JrjRJ8k2DwOtD0FL6NIVhy+mA jRfwfsZOSC/5PzYKnWz69xoCkoFhtMU/a9GozqKCeTOl5RBPlVdkuBzhtY9TCDEwSSPREx7+7bO aw71DWYeJURPGy3LKtThcKneOH8g1eTpniUXjDyNnImxBas2eWh2b/azfxZK2QoyQSLN8umay7z K+1RQ= X-Google-Smtp-Source: AGHT+IGGYKzyAUe/IaGXDhdL9woA7O3AIE1PoFVumpFrnd4Cmt2fMT2p1sFtOUU7tMBYElXU3abJgQ== X-Received: by 2002:a05:6000:2908:b0:3ce:d43c:673c with SMTP id ffacd0b85a97d-3d1e03bffc3mr9104094f8f.46.1756809878224; Tue, 02 Sep 2025 03:44:38 -0700 (PDT) Message-ID: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> Date: Tue, 2 Sep 2025 11:44:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer , xen-devel@lists.xenproject.org References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/09/2025 11:17 am, Manuel Bouyer wrote: > Hello, > I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > The same NetBSD kernel works fine with Xen 4.18 > > The boot options are: > menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh > > and the full log from serial console is attached. > > With 4.20 the boot fails with: > > (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > (XEN) Freed 664kB init memory > (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > (XEN) *** Dumping Dom0 vcpu#0 state: *** > (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > (XEN) CPU: 7 > (XEN) RIP: 0008:[<000000000020e268>] > (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > > because of the triple fault the RIP above doens't point to the code. > > I tracked it down to this code: > cmpl $0,%ecx ; /* zero-sized? */ \ > je 2f ; \ > pushl %ebp ; \ > movl RELOC(nox_flag),%ebp ; \ > 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > movl %eax,(%ebx) ; /* store phys addr */ \ > addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > addl $PAGE_SIZE,%eax ; /* next phys page */ \ > loop 1b ; \ > popl %ebp ; \ > 2: ; > > there are others pushl/popl before so I don't think that's the problem > (in fact the exact same fragment is called just before with different > inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > which would be 0x20e260 > This is in the range: > (XEN) [0000000000100000, 0000000040068e77] (usable) > so I can't see why this would be a problem. > > Any idea, including how to debug this further, welcome Even though triple fault's are aborts, they're generally accurate under virt, so 0x20e268 is most likely where things die. Your best bet is to instrument hvm_triple_fault().  e.g. diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 23bd7f078a1d..0f960576b3e6 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1746,14 +1746,22 @@ void hvm_hlt(unsigned int eflags)    void hvm_triple_fault(void)  { +    const struct cpu_user_regs *regs = guest_cpu_user_regs();      struct vcpu *v = current;      struct domain *d = v->domain;      u8 reason = d->arch.hvm.params[HVM_PARAM_TRIPLE_FAULT_REASON]; +    char insns[32];        gprintk(XENLOG_ERR,              "Triple fault - invoking HVM shutdown action %d\n",              reason);      vcpu_show_execution_state(v); + +    if ( copy_from_user_hvm(insns, _p(regs->rip), ARRAY_SIZE(insns)) ) +        printk("Guest code stream: %32ph\n", insns); +    else +        printk("Bad pagetables for %%rip\n"); +      domain_shutdown(d, reason);  }   will try and get you the instruction which finally caused the fault. (compile tested only) Given that 4.18 works and 4.20 doesn't, it's probably to do with the initial memory map of the guest.  Do you have the full logs of both boots? Just for sanity sake (I don't know if it's going to be relevant or not), boot with dom0=pvh,pf-fixup  which just might highlight if we've got a mixup with the memory map presented to the guest vs the system. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 10:56:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 10:56:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106065.1456851 (Exim 4.92) (envelope-from ) id 1utOgl-0006KK-C7; Tue, 02 Sep 2025 10:56:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106065.1456851; Tue, 02 Sep 2025 10: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 1utOgl-0006KD-9X; Tue, 02 Sep 2025 10:56:35 +0000 Received: by outflank-mailman (input) for mailman id 1106065; Tue, 02 Sep 2025 10:56: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 1utOgk-0006K7-Ck for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 10:56:34 +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 7cd13767-87eb-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 12:56:33 +0200 (CEST) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-45b84367affso27552735e9.3 for ; Tue, 02 Sep 2025 03:56:33 -0700 (PDT) Received: from localhost.localdomain ([87.114.69.104]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e74b72esm197226915e9.0.2025.09.02.03.56.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 03:56: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: 7cd13767-87eb-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1756810592; x=1757415392; 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=uZi8Sj1r6fD/XAgHc/5d4qkPiGFTtkfD49OTXdflNVI=; b=WSZ5i9hG791qn9o3kz/znb4ZJ+Z0jpdpei/Qy/w/xT26U58jjZ3IVzlUP/MQLEYJCC 5CdiQrZXSiWMhrvrC5AfYogAxsJUPjGK0RWeMVDPqGbM9ggEMizIRwpWkeOtFWwOpx15 Pfr3NwH1f/tgU1BcvFoQB2+jS0sNdgHGXLyFQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756810592; x=1757415392; 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=uZi8Sj1r6fD/XAgHc/5d4qkPiGFTtkfD49OTXdflNVI=; b=qyH7BxBWLYMmlZUAOJoQfk/Q/Hb7n2tWKOLCahvyyz75R7NcZo1OzZQCacQk92wn8Z 5jf/8kw2B0iXKmV1R8/DsRYbio6S0Uf/FTgLYMoVbCDvHWQ6yQ/GyePLpgYJ4XhODvsA n/RnXuMxxvGfwT2mbcAosVCdcztB6dRVb7YFH8WFgX2RS6oPVlsmWL4GGcrn7SwlTe2C IKNrXQ79q3tZ0b/JUscdH37X5KLD+EV2bXzhPqq20n6fLHLi80gboBfAYb2w6BpYTlvb 2uttUKgIX45TSzs90I4FzoadLCXm96HMP14M7/41n6hkXhePeRpLfrl4cEoLMKyCXuaD Dcuw== X-Gm-Message-State: AOJu0Yz5bA8/pMtGJ0YqZ7m3/lv96v0hBdQUiFkr1VLi6AvT4EprpS6Y PMjBh2u5e+CGaU2YDZ4uqzaLAhidyPepj7to6yhYjZ845j0ptl0KJmFppYqBivs5QZkikV6C4SB 1IRFDl4Q= X-Gm-Gg: ASbGncsIWOZ792vJr9YIaG5lX+U1jwtoJPiwpG11GeRNL9je2GLpKpJXkE6fzIHXkek hXwkLvWJlwKGY9cJkqA+Wz+wcAOut6XU+zKX8sceGSY7N8iAcyT7AVKJC/KCXVOlhT/9+pMzc7I rWchQ1Xp/uVjZyBqsXKPdcjOJfPjrpHnfRofagc/HMqQhR9VAJSSM/hh8w5LmeOgZB0xgqFpXuP eNGn7T6hsbGGR0GDPph2jQKcethw2yRMLTFSOOL5pWKjTAq/+u1cGwCwnQErmF5i+xsbnoVxy1u RitUaU7Fh5Cs7MqKiH70I8cKioZvEn+Jv7On4q36FwJ7uTA2tCjzGxgNkdjf17RXQYqILYml9J8 BsjLxjxJ/RkzLcQZs2OSAvV2o0pTae2iDu+uxVkq6BA== X-Google-Smtp-Source: AGHT+IGBRNsdWIEVq2lvABTbUUECIfsmVa+EHXBbyet6RJA7rgFMhqYNN2EUThPsqZySlFDKzug8IQ== X-Received: by 2002:a05:600c:1f85:b0:45b:5f99:191c with SMTP id 5b1f17b1804b1-45b8555ca8dmr86401375e9.12.1756810592060; Tue, 02 Sep 2025 03:56:32 -0700 (PDT) From: Frediano Ziglio To: xen-devel@lists.xenproject.org Cc: Frediano Ziglio , Anthony PERARD , Juergen Gross , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper Subject: [PATCH v2] tools/libs: Use superpages where possible on migrate/resume Date: Tue, 2 Sep 2025 11:56:25 +0100 Message-ID: <20250902105625.28552-1-frediano.ziglio@cloud.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Try to allocate larger order pages. With some test memory program stressing TLB (many small random memory accesses) you can get 15% performance improves. On the first memory iteration the sender is currently sending memory in 4mb aligned chunks which allows the receiver to allocate most pages as 2mb superpages instead of single 4kb pages. This works even for HVM where the first 2mb contains some holes. This change does not handle 1gb superpages as this will require change in the protocol to preallocate space. Signed-off-by: Frediano Ziglio --- Changes since v1: - updated commit message and subject; - change the implementation detecting possible 2mb pages inside the packet sent allowing more 2mb superpages. --- tools/libs/guest/xg_sr_restore.c | 77 ++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c index 06231ca826..f2018299a7 100644 --- a/tools/libs/guest/xg_sr_restore.c +++ b/tools/libs/guest/xg_sr_restore.c @@ -129,6 +129,80 @@ static int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t pfn) return 0; } +#if defined(__i386__) || defined(__x86_64__) +/* Order of the smallest superpage */ +#define SMALL_SUPERPAGE_ORDER 9 +#else +#error Define SMALL_SUPERPAGE_ORDER for this platform +#endif + +static unsigned int populate_order(struct xc_sr_context *ctx, + unsigned int original_count, + xen_pfn_t *pfns, xen_pfn_t *mfns, + int order) +{ + size_t i = original_count, num_superpages; + xen_pfn_t prev = 0, order_mask = ~((~(xen_pfn_t)0) << order); + xen_pfn_t *const indexes_end = mfns + original_count; + xen_pfn_t *indexes = indexes_end; + unsigned int count = 0; + + while ( i > 0 ) + { + --i; + ++count; + if ( pfns[i] != prev - 1 ) + count = 1; + + /* + * Is this the start of a contiguous and aligned number + * of pages ? + */ + if ( (pfns[i] & order_mask) == 0 && count > order_mask ) + *--indexes = i; + + prev = pfns[i]; + } + + count = original_count; + + /* No superpages found */ + if ( indexes == indexes_end ) + return count; + num_superpages = indexes_end - indexes; + + /* Build list of PFNs that will be updated with MFNs */ + mfns = indexes - num_superpages; + for ( i = 0; i < num_superpages; ++i ) + mfns[i] = pfns[indexes[i]]; + + /* Try to allocate, fallback to single pages */ + if ( xc_domain_populate_physmap_exact( + ctx->xch, ctx->domid, num_superpages, order, 0, mfns) ) + return count; + + /* Scan all MFNs allocated */ + for ( i = 0; i < num_superpages; ++i ) + { + const xen_pfn_t mfn = mfns[i]; + const xen_pfn_t pfn = pfns[indexes[i]]; + + /* Check valid */ + if ( mfn == INVALID_MFN ) + continue; + + /* Update PFNs using callback */ + for ( size_t j = 0; j <= order_mask; ++j ) + ctx->restore.ops.set_gfn(ctx, pfn + j, mfn + j); + + /* remove from 4kb pages list */ + count -= order_mask + 1; + memmove(pfns + indexes[i], pfns + indexes[i] + order_mask + 1, + sizeof(*pfns) * (count - indexes[i])); + } + return count; +} + /* * Given a set of pfns, obtain memory from Xen to fill the physmap for the * unpopulated subset. If types is NULL, no page type checking is performed @@ -163,6 +237,9 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned int count, } } + /* try optimizing using larger order */ + nr_pfns = populate_order(ctx, nr_pfns, pfns, mfns, SMALL_SUPERPAGE_ORDER); + if ( nr_pfns ) { rc = xc_domain_populate_physmap_exact( -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 10:56:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 10:56:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106067.1456862 (Exim 4.92) (envelope-from ) id 1utOh4-0006gF-Ke; Tue, 02 Sep 2025 10:56:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106067.1456862; Tue, 02 Sep 2025 10:56:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utOh4-0006fN-GB; Tue, 02 Sep 2025 10:56:54 +0000 Received: by outflank-mailman (input) for mailman id 1106067; Tue, 02 Sep 2025 10:56:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utOh3-0006bW-9T for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 10:56:53 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 879e7b78-87eb-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 12:56:51 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582AulKl029857 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 12:56:48 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582AulRb015774; Tue, 2 Sep 2025 12:56:47 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 69D64107F7; Tue, 2 Sep 2025 12:56: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: 879e7b78-87eb-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 12:56:46 +0200 From: Manuel Bouyer To: Andrew Cooper Cc: xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 12:56:48 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: > On 02/09/2025 11:17 am, Manuel Bouyer wrote: > > Hello, > > I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > > The same NetBSD kernel works fine with Xen 4.18 > > > > The boot options are: > > menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh > > > > and the full log from serial console is attached. > > > > With 4.20 the boot fails with: > > > > (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > > (XEN) Freed 664kB init memory > > (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > > (XEN) *** Dumping Dom0 vcpu#0 state: *** > > (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > > (XEN) CPU: 7 > > (XEN) RIP: 0008:[<000000000020e268>] > > (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > > (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > > (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > > (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > > (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > > (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > > (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > > > > because of the triple fault the RIP above doens't point to the code. > > > > I tracked it down to this code: > > cmpl $0,%ecx ; /* zero-sized? */ \ > > je 2f ; \ > > pushl %ebp ; \ > > movl RELOC(nox_flag),%ebp ; \ > > 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > > movl %eax,(%ebx) ; /* store phys addr */ \ > > addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > > addl $PAGE_SIZE,%eax ; /* next phys page */ \ > > loop 1b ; \ > > popl %ebp ; \ > > 2: ; > > > > there are others pushl/popl before so I don't think that's the problem > > (in fact the exact same fragment is called just before with different > > inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > > which would be 0x20e260 > > This is in the range: > > (XEN) [0000000000100000, 0000000040068e77] (usable) > > so I can't see why this would be a problem. > > > > Any idea, including how to debug this further, welcome > > Even though triple fault's are aborts, they're generally accurate under > virt, so 0x20e268 is most likely where things die. but that's the RIP of the last fault, not the first one, right ? 0x20e268 isn't in the text segment of the kernel, my guess is that the first fault triggers an exception, but the exeption handler isn't set up yet so we end up jumping to some random value. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 11:13:35 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 11:13:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106137.1456887 (Exim 4.92) (envelope-from ) id 1utOx8-0002M4-BO; Tue, 02 Sep 2025 11:13:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106137.1456887; Tue, 02 Sep 2025 11:13: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 1utOx8-0002Lx-8m; Tue, 02 Sep 2025 11:13:30 +0000 Received: by outflank-mailman (input) for mailman id 1106137; Tue, 02 Sep 2025 11:13: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 1utOx7-0002Lr-V5 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 11:13:29 +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 da70ef0e-87ed-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 13:13:29 +0200 (CEST) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3cbb3ff70a0so3284830f8f.2 for ; Tue, 02 Sep 2025 04:13:29 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b814da51esm172282325e9.8.2025.09.02.04.13.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 04:13: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: da70ef0e-87ed-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756811608; x=1757416408; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=pf842Qo/2ZKmQTuxsH+JCJl+AjkW/F2ljYwdJgSFOms=; b=OK0tlKBNN1RfwT7bopVUA6d+5mVhZDSTcXXaefoLSiyxDl9bEErF5xy1Y0WlTXV1Zw ZpF0KqoQdgomj+wsrN+BMQVuY03KeO4lf1vd5FMgyw+QHB1Wmy90StgDJ/WVr9o7RUu4 zNBg/XCqeG8XTZAllxMgbMnD30G2CupHbSkJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756811608; x=1757416408; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pf842Qo/2ZKmQTuxsH+JCJl+AjkW/F2ljYwdJgSFOms=; b=hQ/BXbqfzsVmDeMLBUY/gxyluE9pXFv/u/nzhbaD2o5UjHDWcZATfgEQCA8rG5QE7L /nVquzEh+F/p1BpFJ25gjDm5cIz0ulx1sGMx3q6Us7cMFMFW0LJ59vZ9CghaZO9I51PN 4m0cglOOUACmOTvSjFqGP3DoB1H34Wfh39HNsvQPT3W7sX91f1jpfZRRWvqK/vd6DbAS fYo152VVyOdHequldvT1ufuvVr7UnOeDXETzrreaemxntpvZpif5eXvLLunP476O9FUG JO/tP6Dq3w2gxgQQYOT+VLmZcffSXE/fqEn4lFXYTCS2HJVDYeQJJUVia6YAkQGdpswm ZVaA== X-Gm-Message-State: AOJu0YxElaEebfEIFhDpuv8rItMyG3KgbFPR2ZUjB5/KHz3lxvJlBvJX ZnxxOY2u2QS50IunR5Q0TfyfgVSwVSI2Ii5Il9OW9QJmTIRSZHj5tpxQGNp5FcYebXvGU+49SfR up13s X-Gm-Gg: ASbGncuBE4oZGbx78CjkawmNMfnCNdrrU9kHGxGC03N0RjFYatbFyiwc6kVvQVag9Ql Qs6TbUyrAUipjuCv+FSiE1yvam/Yg0RgR8FpW4BS9MKT3V5Z+wF5SB7R8roWQrNe1+Xk/+zHAea 7k803hRmSum7UCQxiDFj9q8ablVOVUD6kPMMWyOMYcm5SSqwEZREl+dR4DQMdY3BHRw5Dp+CIG/ Xyp8tbuZ3gVnSs2qOtchwE0FrVV2WXvJpPuJ0/pkRdww2XCWhUCezcplMuxvE93YEc0sQbxP2jW zM0gV4gwEnNagUj099jzqcOr8C9sFK1KTTdhePhmeWItVF+H621dcjIuY1wEgOKJ4KMkvAiEuek GnR1P+MNDhUyVwX+eD9foo9UbxmkkDeFEwQIi/tCxGiWd2Ond/13PAO+xiL6vYYAhAD6c X-Google-Smtp-Source: AGHT+IH9sCvxRTXI8axQgp3hTDef0vrfMSIAzucSCk23s1rysQuAYH+ic0NKbdmUC2q9jBuIEjkQSg== X-Received: by 2002:a05:6000:22c8:b0:3d5:a6a9:7d3e with SMTP id ffacd0b85a97d-3d5a6a98bebmr5114958f8f.4.1756811608376; Tue, 02 Sep 2025 04:13:28 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 12:13:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@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/09/2025 11:56 am, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>> Hello, >>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>> The same NetBSD kernel works fine with Xen 4.18 >>> >>> The boot options are: >>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>> >>> and the full log from serial console is attached. >>> >>> With 4.20 the boot fails with: >>> >>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>> (XEN) Freed 664kB init memory >>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>> (XEN) CPU: 7 >>> (XEN) RIP: 0008:[<000000000020e268>] >>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>> >>> because of the triple fault the RIP above doens't point to the code. >>> >>> I tracked it down to this code: >>> cmpl $0,%ecx ; /* zero-sized? */ \ >>> je 2f ; \ >>> pushl %ebp ; \ >>> movl RELOC(nox_flag),%ebp ; \ >>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>> movl %eax,(%ebx) ; /* store phys addr */ \ >>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>> loop 1b ; \ >>> popl %ebp ; \ >>> 2: ; >>> >>> there are others pushl/popl before so I don't think that's the problem >>> (in fact the exact same fragment is called just before with different >>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>> which would be 0x20e260 >>> This is in the range: >>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>> so I can't see why this would be a problem. >>> >>> Any idea, including how to debug this further, welcome >> Even though triple fault's are aborts, they're generally accurate under >> virt, so 0x20e268 is most likely where things die. > but that's the RIP of the last fault, not the first one, right ? > 0x20e268 isn't in the text segment of the kernel, my guess is that the > first fault triggers an exception, but the exeption handler isn't set up yet > so we end up jumping to some random value. Double and Triple faults occur when trying to deliver an exception generates an exception.  So while multiple faults are involved, only one instruction typically is. Is this an Intel or an AMD system?  One thing virt can do is break apart a triple fault, but the logic to do so is vendor specific. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 11:16:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 11:16:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106147.1456897 (Exim 4.92) (envelope-from ) id 1utP0A-0002ud-PR; Tue, 02 Sep 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 1106147.1456897; Tue, 02 Sep 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 1utP0A-0002uW-Lw; Tue, 02 Sep 2025 11:16:38 +0000 Received: by outflank-mailman (input) for mailman id 1106147; Tue, 02 Sep 2025 11: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 1utP0A-0002uQ-4i for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 11:16:38 +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 499a24e2-87ee-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 13:16:36 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id C2F37601D3; Tue, 2 Sep 2025 11:16:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C530CC4CEED; Tue, 2 Sep 2025 11:16: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: 499a24e2-87ee-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1756811794; bh=4Xr3MgVLvcyS3MYbKzhy65gyGhMd61jNWAJJSRf8Jbg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dAY/WZU1oMdEysLvHbsplShcI8d+z7cbsIKf4eIoisPpKBDDB8yuoMtlyFHbE6lrt d6/iUnK3dEX0a5wFKmnSLFXF2M63iGcIH0cHJ3hrrMocqnjS1IiAMR/aE/dju788xp 3zaW4SC8vuxwdbO1I7BZQJHGzKBt61+/jWbiovAg= Date: Tue, 2 Sep 2025 13:16:31 +0200 From: Greg Kroah-Hartman To: Teddy Astie Cc: xen-devel@lists.xenproject.org, stable@vger.kernel.org, Juergen Gross , kernel test robot , Boris Ostrovsky , Stefano Stabellini , Anthoine Bourgeois , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Jiri Slaby Subject: Re: [PATCH v5.10.y] xen: replace xen_remap() with memremap() Message-ID: <2025090203-clothes-bullish-a21f@gregkh> References: <4cc9c1f583fb4bfca02ff7050b9b01cb9abb7e7f.1756803599.git.teddy.astie@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4cc9c1f583fb4bfca02ff7050b9b01cb9abb7e7f.1756803599.git.teddy.astie@vates.tech> On Tue, Sep 02, 2025 at 09:28:32AM +0000, Teddy Astie wrote: > From: Juergen Gross > > From: Juergen Gross > > [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] > > xen_remap() is used to establish mappings for frames not under direct > control of the kernel: for Xenstore and console ring pages, and for > grant pages of non-PV guests. > > Today xen_remap() is defined to use ioremap() on x86 (doing uncached > mappings), and ioremap_cache() on Arm (doing cached mappings). > > Uncached mappings for those use cases are bad for performance, so they > should be avoided if possible. As all use cases of xen_remap() don't > require uncached mappings (the mapped area is always physical RAM), > a mapping using the standard WB cache mode is fine. > > As sparse is flagging some of the xen_remap() use cases to be not > appropriate for iomem(), as the result is not annotated with the > __iomem modifier, eliminate xen_remap() completely and replace all > use cases with memremap() specifying the MEMREMAP_WB caching mode. > > xen_unmap() can be replaced with memunmap(). > > Reported-by: kernel test robot > Signed-off-by: Juergen Gross > Reviewed-by: Boris Ostrovsky > Acked-by: Stefano Stabellini > Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com > Signed-off-by: Juergen Gross > Signed-off-by: Teddy Astie [backport to 5.10.y] > --- Why is this needed for 5.10.y at all? What bug does it fix? And why are you still using Xen on a 5.10.y kernel? What prevents you from moving to a newer one? thanks, greg k-h From xen-devel-bounces@lists.xenproject.org Tue Sep 02 11:24:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 11:24:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106158.1456906 (Exim 4.92) (envelope-from ) id 1utP7D-0004cc-DM; Tue, 02 Sep 2025 11:23:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106158.1456906; Tue, 02 Sep 2025 11:23:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utP7D-0004cV-Ap; Tue, 02 Sep 2025 11:23:55 +0000 Received: by outflank-mailman (input) for mailman id 1106158; Tue, 02 Sep 2025 11:23: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 1utP7C-0004cP-Ln for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 11:23:54 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4d9717ad-87ef-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 13:23:52 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582BNneM010751 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 13:23:50 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582BNnIk006261; Tue, 2 Sep 2025 13:23:49 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 4D8D2107F7; Tue, 2 Sep 2025 13:23: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: 4d9717ad-87ef-11f0-8adc-4578a1afcccb Date: Tue, 2 Sep 2025 13:23:48 +0200 From: Manuel Bouyer To: Andrew Cooper Cc: xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 13:23:50 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 12:13:27PM +0100, Andrew Cooper wrote: > On 02/09/2025 11:56 am, Manuel Bouyer wrote: > > On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: > >> On 02/09/2025 11:17 am, Manuel Bouyer wrote: > >>> Hello, > >>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > >>> The same NetBSD kernel works fine with Xen 4.18 > >>> > >>> The boot options are: > >>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh > >>> > >>> and the full log from serial console is attached. > >>> > >>> With 4.20 the boot fails with: > >>> > >>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > >>> (XEN) Freed 664kB init memory > >>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > >>> (XEN) *** Dumping Dom0 vcpu#0 state: *** > >>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > >>> (XEN) CPU: 7 > >>> (XEN) RIP: 0008:[<000000000020e268>] > >>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > >>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > >>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > >>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > >>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > >>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > >>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > >>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > >>> > >>> because of the triple fault the RIP above doens't point to the code. > >>> > >>> I tracked it down to this code: > >>> cmpl $0,%ecx ; /* zero-sized? */ \ > >>> je 2f ; \ > >>> pushl %ebp ; \ > >>> movl RELOC(nox_flag),%ebp ; \ > >>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > >>> movl %eax,(%ebx) ; /* store phys addr */ \ > >>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > >>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ > >>> loop 1b ; \ > >>> popl %ebp ; \ > >>> 2: ; > >>> > >>> there are others pushl/popl before so I don't think that's the problem > >>> (in fact the exact same fragment is called just before with different > >>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > >>> which would be 0x20e260 > >>> This is in the range: > >>> (XEN) [0000000000100000, 0000000040068e77] (usable) > >>> so I can't see why this would be a problem. > >>> > >>> Any idea, including how to debug this further, welcome > >> Even though triple fault's are aborts, they're generally accurate under > >> virt, so 0x20e268 is most likely where things die. > > but that's the RIP of the last fault, not the first one, right ? > > 0x20e268 isn't in the text segment of the kernel, my guess is that the > > first fault triggers an exception, but the exeption handler isn't set up yet > > so we end up jumping to some random value. > > Double and Triple faults occur when trying to deliver an exception > generates an exception. So while multiple faults are involved, only one > instruction typically is. > > Is this an Intel or an AMD system? One thing virt can do is break apart > a triple fault, but the logic to do so is vendor specific. it's an old intel system: cpu0: "Intel(R) Xeon(R) CPU X5650 @ 2.67GHz" cpu0: Intel Xeon 36xx & 56xx, i7, i5 and i3 (686-class), 2667.30 MHz cpu0: family 0x6 model 0x2c stepping 0x2 (id 0x206c2) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 11:53:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 11:53:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106171.1456917 (Exim 4.92) (envelope-from ) id 1utPa2-0000Nk-Is; Tue, 02 Sep 2025 11:53:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106171.1456917; Tue, 02 Sep 2025 11:53:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPa2-0000Nd-Fr; Tue, 02 Sep 2025 11:53:42 +0000 Received: by outflank-mailman (input) for mailman id 1106171; Tue, 02 Sep 2025 11:53:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPa1-0000NX-Lg for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 11:53:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utPa0-002rup-3D; Tue, 02 Sep 2025 11:53:41 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utPa0-00D3Sm-34; Tue, 02 Sep 2025 11:53: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=0Zyq2pGGRUwcN7gtUS3MHMga2TViRRCdqDexNWRucnk=; b=I56VAH524DZzPrl6HImyxGxw81 WfOaSYo9RLqNlNMQRuyqC9SidPCTDatZHOesh1ZPznhEMki5NaBEsSvuMfdu8krqAhuTBUrhfVcEi tiGui4dCncbjL3LRQ8QaP5Gq4C/CgVOq5ajYVIAxoVuS+GscLZLkCShxdn02y6opo3LI=; Message-ID: Date: Tue, 2 Sep 2025 12:53:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Content-Language: en-GB To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> From: Julien Grall In-Reply-To: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 02/09/2025 10:49, Oleksandr Tyshchenko wrote: > The said sub-op is not supported on Arm, since it: > - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn > cannot be returned), please refer to ioreq_server_create() Yet. I can see use in the future to optimize some emulation (e.g. virtio notification). To be honest, I don't quite see the benefit of removing this code as most of it is mainly generic. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 11:54:48 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 11:54:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106180.1456927 (Exim 4.92) (envelope-from ) id 1utPb6-0000s3-SR; Tue, 02 Sep 2025 11:54:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106180.1456927; Tue, 02 Sep 2025 11:54: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 1utPb6-0000rw-PL; Tue, 02 Sep 2025 11:54:48 +0000 Received: by outflank-mailman (input) for mailman id 1106180; Tue, 02 Sep 2025 11:54:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPb5-0000ri-1o for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 11:54:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utPb4-002rw5-1Z; Tue, 02 Sep 2025 11:54:46 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utPb4-00D3V0-1S; Tue, 02 Sep 2025 11: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=2+jEwqycw1vDeXGQROS9+pQ2b06MUhzGIsuk6QT8jRI=; b=cE3VWr/thsd9iBTcZ51tQGAWW5 Jk1qZtctAH6+liOqtCip/4oLV1pTd+3WYG9noJ+wVC1qkNzsWrx0pRDwg1pmSVIVfcYiLPGulFHC2 KnB8gqU6Bw3w9ee4yV6eCAa8DoIXhIF3YUdQluaFrgZh3aUCxm2yDbYIQzFDShvnGUc8=; Message-ID: Date: Tue, 2 Sep 2025 12:54:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Content-Language: en-GB To: "Orzel, Michal" , Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> <319c280a-535d-498a-b0ab-93882663e23b@amd.com> From: Julien Grall In-Reply-To: <319c280a-535d-498a-b0ab-93882663e23b@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 02/09/2025 11:18, Orzel, Michal wrote: > > > On 02/09/2025 11:49, Oleksandr Tyshchenko wrote: >> The said sub-op is not supported on Arm, since it: >> - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn >> cannot be returned), please refer to ioreq_server_create() >> - does not support "legacy" mechanism of mapping IOREQ Server >> magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please >> refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire >> Resource infrastructure is used to query and map the IOREQ Server pages. >> >> Signed-off-by: Oleksandr Tyshchenko > Reviewed-by: Michal Orzel > > Could we perhaps add a Fixes tag here pointing to the commit introducing these > DM ops and thus add this patch for this release? Not sure what others think. Fixes usually implies a bug and I don't see what bug we are solving. In fact, I don't understand why we are trying to remove the subop... Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:00:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:00:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106198.1456936 (Exim 4.92) (envelope-from ) id 1utPgl-0002W6-Nf; Tue, 02 Sep 2025 12:00:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106198.1456936; Tue, 02 Sep 2025 12:00:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPgl-0002Vz-L1; Tue, 02 Sep 2025 12:00:39 +0000 Received: by outflank-mailman (input) for mailman id 1106198; Tue, 02 Sep 2025 12:00: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 1utPgk-0002UF-8Q for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:00:38 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7014e837-87f4-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 14:00:37 +0200 (CEST) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61ded2712f4so3805630a12.1 for ; Tue, 02 Sep 2025 05:00: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 4fb4d7f45d1cf-61eaf588377sm2613037a12.15.2025.09.02.05.00.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:00: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: 7014e837-87f4-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756814437; x=1757419237; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=EeCguA3zEelSa9l3otrauPOu6p28MDJ0IS+pQ6a844c=; b=TxHH/htUbKIVyIbjP0UWgAPy+4wzt0zB+2sAWO2M4LvqrB6bJs7SMJWe13yz5PBqVm Xaa8SP2z39BzuCGbkHzb6Nqiyrf/EXxtRt7hP3djvs+OG8DCxhcye1sVpiGZLhHZH796 P5CJqMQTx/h50A+TxW1/GgB5a5yOa9U36LShxzRMMoAGGnW5K4DHxQI/YxtdwrfSFvfG QUV1lyhr9VLRmXqFlTrhGYjXbUZJeL2n75n/XkTh+9UVO0An/H7P02HjwV6SY3P6hLyD 8UU0GRREvJb+Hk1fKC2tSg2rFWGi0Z8Yk+oqNYcBSTwbGHVNfP6ETdqdCDy418gvgoRb UAgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756814437; x=1757419237; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EeCguA3zEelSa9l3otrauPOu6p28MDJ0IS+pQ6a844c=; b=X8csketXxb4q00OHd5Mb2nOVUkEuxNUl998MzXql8Z9AgFMNEClRz1qaiKmFYQkZ4X RmVtmW6dh+RqnwoyhWbTOCRJ0jjoLXVbuMcM3hsLIKD7uZRpKH+DNB4F0hhgadJ9nFS6 +MhSTqpcK6RkRjteI/5Y8cOrL7GpIQvQdKOz5zIMkGPq7zR251MHt9UB+VUU3DeS9Z6Y 6LhxBNsi+nHDj5A7hi84gsuraYvnaz8PxkcFhxZWvp1TVyI/l1QKSxb/x1QOCCnYu/dw hLhTcHMR6PnpIsEvoMVl8Z3UQnyehW6/VYmYY8LZ68Hn0Oon35cS/Bm6keQIR8SP95qe Rrdg== X-Gm-Message-State: AOJu0Yy11hGRywhVnApr8DJgL73lcxV1Mo/XqUws+3qeRiGpEcMfKiNz 9YEGR0icLOJNXau841bFeTZkvDqE7FUBLTPON5jMJT6kDLSvrjXvyTAXfRFxFLBVZ9o70VqYZ8G w5YI= X-Gm-Gg: ASbGncv9FObZv6CxwbYj61PoZ9W+KD1AMdQBdESdkvMW8VfmJPDnAwApZtj7FN1jDx8 Dl+I+TTcR50tST0t7i5gC1TGGS9JeHnQ9tLXedGJjrHw5XT39CSv07tL9mHxpk7IdBI0HHkZd1h 7xBpzNkjwy+sbX7ooPns2WztIbhGmKfxxF/s+gapEL2T5IqHxkpjrWfrVdYbryeFUfUDpPBu4oJ NqzpwO268cQWoBnmM0BRbzxOBJF80/6hECx0YSrJ315EN2qd30EAPEGLGvvGOJG5NUdwoa4Qtcf b+XLV991n+06g6i+DxMVoDtzLMRwUZjupRV7//dR6IsaSgvO/qfPU4yotvDCPewerTFaPDOCyKt +9ZFU/NAXxvlobAX3Rt31qd2/SMRCq+DiPwurcyWsV7fez479v5+5zOPkDf2dmmCWGC14/0dpzI bPo6Gj+nVtsLbhR9WCZUstzanJFo4A X-Google-Smtp-Source: AGHT+IHIRTb8c38BBJJVa6dMybLPHer++wMBvFvoGBHIFnPJ7wQj9JGx1psv/6Qu4MCBznPfuNvOaw== X-Received: by 2002:a05:6402:34d2:b0:61c:87da:4bf7 with SMTP id 4fb4d7f45d1cf-61d26c5351bmr9550181a12.17.1756814436484; Tue, 02 Sep 2025 05:00:36 -0700 (PDT) Message-ID: <79612dd8-2d12-4f69-9371-8a788db3873f@suse.com> Date: Tue, 2 Sep 2025 14:00:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: xen-devel@lists.xenproject.org, Andrew Cooper References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2025 12:56, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>> Hello, >>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>> The same NetBSD kernel works fine with Xen 4.18 >>> >>> The boot options are: >>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>> >>> and the full log from serial console is attached. >>> >>> With 4.20 the boot fails with: >>> >>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>> (XEN) Freed 664kB init memory >>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>> (XEN) CPU: 7 >>> (XEN) RIP: 0008:[<000000000020e268>] >>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>> >>> because of the triple fault the RIP above doens't point to the code. >>> >>> I tracked it down to this code: >>> cmpl $0,%ecx ; /* zero-sized? */ \ >>> je 2f ; \ >>> pushl %ebp ; \ >>> movl RELOC(nox_flag),%ebp ; \ >>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>> movl %eax,(%ebx) ; /* store phys addr */ \ >>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>> loop 1b ; \ >>> popl %ebp ; \ >>> 2: ; >>> >>> there are others pushl/popl before so I don't think that's the problem >>> (in fact the exact same fragment is called just before with different >>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>> which would be 0x20e260 >>> This is in the range: >>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>> so I can't see why this would be a problem. >>> >>> Any idea, including how to debug this further, welcome >> >> Even though triple fault's are aborts, they're generally accurate under >> virt, so 0x20e268 is most likely where things die. > > but that's the RIP of the last fault, not the first one, right ? > 0x20e268 isn't in the text segment of the kernel, my guess is that the > first fault triggers an exception, but the exeption handler isn't set up yet > so we end up jumping to some random value. Can you perhaps check this guess against the %esp value seen? From the hypervisor's triple fault handling, you may want to actually log stack contents as well (in addition to what Andrew suggested), assuming %esp looks sane to you. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:10:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:10:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106218.1456946 (Exim 4.92) (envelope-from ) id 1utPpw-0004P6-IP; Tue, 02 Sep 2025 12:10:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106218.1456946; Tue, 02 Sep 2025 12:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPpw-0004Oz-Fr; Tue, 02 Sep 2025 12:10:08 +0000 Received: by outflank-mailman (input) for mailman id 1106218; Tue, 02 Sep 2025 12:10: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 1utPpv-0004Os-E9 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:10:07 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c2a2a82a-87f5-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:10:05 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582CA3R3007481 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 14:10:03 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582CA3Ko005434; Tue, 2 Sep 2025 14:10:03 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 95379107F7; Tue, 2 Sep 2025 14:10: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: c2a2a82a-87f5-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 14:10:01 +0200 From: Manuel Bouyer To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <79612dd8-2d12-4f69-9371-8a788db3873f@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79612dd8-2d12-4f69-9371-8a788db3873f@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 14:10:03 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 02:00:35PM +0200, Jan Beulich wrote: > On 02.09.2025 12:56, Manuel Bouyer wrote: > > On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: > >> On 02/09/2025 11:17 am, Manuel Bouyer wrote: > >>> Hello, > >>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > >>> The same NetBSD kernel works fine with Xen 4.18 > >>> > >>> The boot options are: > >>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh > >>> > >>> and the full log from serial console is attached. > >>> > >>> With 4.20 the boot fails with: > >>> > >>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > >>> (XEN) Freed 664kB init memory > >>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > >>> (XEN) *** Dumping Dom0 vcpu#0 state: *** > >>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > >>> (XEN) CPU: 7 > >>> (XEN) RIP: 0008:[<000000000020e268>] > >>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > >>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > >>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > >>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > >>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > >>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > >>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > >>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > >>> > >>> because of the triple fault the RIP above doens't point to the code. > >>> > >>> I tracked it down to this code: > >>> cmpl $0,%ecx ; /* zero-sized? */ \ > >>> je 2f ; \ > >>> pushl %ebp ; \ > >>> movl RELOC(nox_flag),%ebp ; \ > >>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > >>> movl %eax,(%ebx) ; /* store phys addr */ \ > >>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > >>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ > >>> loop 1b ; \ > >>> popl %ebp ; \ > >>> 2: ; > >>> > >>> there are others pushl/popl before so I don't think that's the problem > >>> (in fact the exact same fragment is called just before with different > >>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > >>> which would be 0x20e260 > >>> This is in the range: > >>> (XEN) [0000000000100000, 0000000040068e77] (usable) > >>> so I can't see why this would be a problem. > >>> > >>> Any idea, including how to debug this further, welcome > >> > >> Even though triple fault's are aborts, they're generally accurate under > >> virt, so 0x20e268 is most likely where things die. > > > > but that's the RIP of the last fault, not the first one, right ? > > 0x20e268 isn't in the text segment of the kernel, my guess is that the > > first fault triggers an exception, but the exeption handler isn't set up yet > > so we end up jumping to some random value. > > Can you perhaps check this guess against the %esp value seen? From the > hypervisor's triple fault handling, you may want to actually log stack > contents as well (in addition to what Andrew suggested), assuming %esp > looks sane to you. %esp is sane. I forgot to mention, this happens very early, while we're still in 32bits real mode. No function call did happen at this point, and on the stack there's only one 32bit value: the %ebp that we just pushed -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:10:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:10:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106220.1456957 (Exim 4.92) (envelope-from ) id 1utPq8-0004gX-QP; Tue, 02 Sep 2025 12:10:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106220.1456957; Tue, 02 Sep 2025 12:10:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPq8-0004gQ-ND; Tue, 02 Sep 2025 12:10:20 +0000 Received: by outflank-mailman (input) for mailman id 1106220; Tue, 02 Sep 2025 12: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 1utPq7-0004Os-LN for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:10:19 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2061d.outbound.protection.outlook.com [2a01:111:f403:2009::61d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c93f9dfe-87f5-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:10:17 +0200 (CEST) Received: from BL1P223CA0016.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:2c4::21) by IA0PR12MB7773.namprd12.prod.outlook.com (2603:10b6:208:431::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 12:10:13 +0000 Received: from BL02EPF0002992B.namprd02.prod.outlook.com (2603:10b6:208:2c4:cafe::3b) by BL1P223CA0016.outlook.office365.com (2603:10b6:208:2c4::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.26 via Frontend Transport; Tue, 2 Sep 2025 12:10:13 +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.9094.14 via Frontend Transport; Tue, 2 Sep 2025 12:10:12 +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, 2 Sep 2025 07:10:10 -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, 2 Sep 2025 07:10:07 -0500 Received: from [10.252.147.171] (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, 2 Sep 2025 07:10: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: c93f9dfe-87f5-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XbGyjTshHXpQkj1qznkFoXKiwhCD45zqLwVUVtF6pL1pJncJBR7KzZDcViOuHdn/NjfuIAFG7AUs58YMzXnf6eEFRRTjXt2jyePSZDxQO8NJo4jwjIiQ8RoZjM5WuIUeibeOrZhILlJKiBLdKhnS0GpmKPDn3YPqkLjbdnRsqc/Rt24NTiA2mpsG16qgrFk0uM/EgGDqqthDQXarFLjYvhdIJMQi2Wym+8QkgAPokMSjX6ZmZUjvk/MQ6Vgb9HlfKJLSbZePzLbaD9+rgT+DsqzE3xessXaSNkBH3v0PyikzSCr/LAIDobdrvo6HYmlPcvZKnGjdSF5fIRN3xWRh5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aO1uF3FNGPw7ezUjoIDMsMsbcoHxMUCDEIMqDsqIAW4=; b=eO+2KLyg4QKV0mrMEA9fGCniz909834DlJxxElQgb2X/Uh08/T8L9im1UBbl4N18mMjXppS8tC9CGQlZ2sJxAQMsvZm07aFxi1xC/g74dp180wWNBQeLOc8hIt7SiNvPzqDSRfJdV5X2j1PfdkU5XPKA5jxkSDdPHM0k+365TH0lmyrPHljZ63YH2wlvyjC3Yv5dre0wG5CbS+vLyiATtgFTBOMhY0OArX+OCVjSY15wYYTIGVSuCIxPD1Wrkz8lGqfyfMKDtzDJp7B2gcHPyOeTHTY+4lMADCQYnsDgBXhyIfw+A3mxD99NoPaJo19OX4JPTGVWgjFjtdc1YC9vMg== 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=aO1uF3FNGPw7ezUjoIDMsMsbcoHxMUCDEIMqDsqIAW4=; b=fL371TbulKAQUHcRaxGwQjwq6/WKqaWRnT4J7qYiC1hYUIN1/dOUvfUqm7xpay0GBr9Nwc/iGtI4CPl5Vg8It+e/yBowYyMRToUqD6Em5MS5rX/Erh5/BVvX90I6TVifVmtFN7oqvRqSlosAsdPYHLRgMlQ1AM/OWEoeNU/UF1M= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <4e01ed71-cdbb-4d41-8845-33449b08494b@amd.com> Date: Tue, 2 Sep 2025 14:10:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported To: Julien Grall , Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> <319c280a-535d-498a-b0ab-93882663e23b@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0002992B:EE_|IA0PR12MB7773:EE_ X-MS-Office365-Filtering-Correlation-Id: e581fb95-3922-46a2-c7a5-08ddea19ab16 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?UFhNcnBxOXBGZU51N0pKWHNNaFRiWHQ1a291ejVwZlNGczk4b2ZiMUorSldP?= =?utf-8?B?OENUT1ZaL05CblZWVEVua0ZLYmhPOWZwSVllNnVnS09tZnJFSFRvZVFsNHNH?= =?utf-8?B?Z3RKTFRPV0pVY1JiZzJtcXhSTzhaZGRBTGdkQ1BPcHN5cUxqM3pwY3NUT1U5?= =?utf-8?B?NUlaSnEvRk1sUGRncFNrR0w2TlZPVzVFYXY1a3piMkVMOW10bGU5UndlZjlG?= =?utf-8?B?OGlJaENVNTFFdHBFWlNuMHBldUJydFY3cDIxamowZWR4ODYvcmZKWUhBSUVn?= =?utf-8?B?VTdBMmM1bkFHb2F0K3d3bWZ1VDY0QmdaVERvZEx4Q2dWWXlsL1hoQ3hNOVZn?= =?utf-8?B?MnlxQjBwRy9RdzFmZmE3Z3AwcGJYcWpOZng1SGNpQkNIYWc5d2p6VGRTeE9Z?= =?utf-8?B?UC9nSWtrbGNiOTZwNWJpMmxXT1hOMlo5RTdQTm1NTmdhbXRPM0NLa1BoaDFz?= =?utf-8?B?QjlxdmJPN1ZITHVMQjBNYXlxRnNUQ2lqa2JiNUdHOFlSaGFSeEJuWUVHTFNh?= =?utf-8?B?c0lnVU1saUh0dVNGM2tYdDlsMmhJbFBuVXN6Zm5PWnF0RUp6SDVTam5HM2VX?= =?utf-8?B?VzMvdEhrS0Z1OHM2QTFJRkcremRSVHdNZExRV0V5VUIvWm9ZN0svL0QvZFRU?= =?utf-8?B?K1paVWJVaGlac3dRaE9lQjdqL3RsaFZGK2tMclFreTZCeSs5NUdrVGxWUXMx?= =?utf-8?B?TkFZVHdsRSs4ekoxRmtJNS9kNU1RQjZWNUpDN1dPRXU2TkYvWTlwc0liWlha?= =?utf-8?B?blByankxY0pYM0Y2K1pHM1lVaVF1V0lyOTUzTUhsT1NwRG82WU5rSHRYZWUr?= =?utf-8?B?MXoyYlh3QWFCMnhOd1dDOHdoSzBaZDltTGJoSmFnaHpMeVM2UUtUQmtsdVM0?= =?utf-8?B?dGJyU2N4UmtVYkF6RVpWQkM1K0ZnWkppVHdaRkhTeWNDcUFOVzkyby9mOFdN?= =?utf-8?B?Sk1EbzIrMWhjNmpvVXo0aEI5QmVNeWVkamtnSzhLZlgza2xibDNXMURVdE04?= =?utf-8?B?Vnh1YVllQTRhM0JaenZUTnhKbjMvZG5QdWtTaUFoNVQveXJQOGNCa0xTTC8w?= =?utf-8?B?b0p5SytDcEp2bUVRQWIyNmZEanBmZmozanNvYmtFeXc3amxrcFp2SzA2WG9z?= =?utf-8?B?MEpQa1FCTWFtT3c3VGV3bUhxN3RiSzJDTHdpRkFTSy9jclJ0SThBMFVTK0Zz?= =?utf-8?B?bFVUbGNIUmhXL25obUxnd1BsQ0ozRU5qNEFZZVdBUVRJaUg2b1NrOEZXVVhT?= =?utf-8?B?VWQ0L2F6MFcxSkR2czBkSU5zT00yeTRBYjRieXBqdEV0YUptbUtLcUR1WVFt?= =?utf-8?B?eGtsN2czcWhDL2U1UVcrVXltOTBJbmdyMVNCY3ErVXUrT0locW5DSHp4cnFK?= =?utf-8?B?clRna0NoeTU4dXZ6MlRMSlFnUFNkN1VzS0Z3TTVoc3gxTzJhbDhBWi9jc09L?= =?utf-8?B?M20xL21GUDBMQnduNmgvdmJ0ZW4vWUV5bUtxZXZKYStYZTFNVXkrcjZncEV6?= =?utf-8?B?b21mSllVeFljdG5iSEd6R284cGhRQ1RTSFRtbHR5RnFOU2ZKVFNnelFIZEdX?= =?utf-8?B?ejAxOXZOL3RkZG9CZlBObkVZRCtWYXBWY0FWcjByZzhKOHpheFVaZnNldXZT?= =?utf-8?B?eHJsYVFJTGRjL2pkMHdVREpPb0NSdXdvTUFSTmJNdGpJN1h0eWpkeVNqOXZ3?= =?utf-8?B?SFVuc2dnc2ZTelZuNkQwMXVMSjcxS3N2dHVJV0dHSmJkdGdMWVJWdzVvUGVt?= =?utf-8?B?TWVqWHlZNGtBcysvTG9XdlpmSS9DK1FVUG93Z1JOY2dmVXFnMklzRW1RTWxo?= =?utf-8?B?SW8yL0hHVWZBMks3b1lzVW9IKzBxaW5PL1BjenROTnJocFQ5WU1BRVJhY0dN?= =?utf-8?B?LzNnTEVEZldhRmxjM0ltaUlBbWx5Y1Z4TnJDSU03cW1ocU10K3V6RzJvazE0?= =?utf-8?B?ZExTVkM4WnRSQXpweUViSVNYUDNyQTBpRXJrdEFSaU5xTjcwZWFScGFnaHR2?= =?utf-8?B?NkhEKzYyQXNES2V2QS93ek42MUtPaEhaT3hzTjRZMlBtaTZxMWxQMGVTTUlJ?= =?utf-8?Q?xj8Qlb?= 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 Sep 2025 12:10:12.1500 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e581fb95-3922-46a2-c7a5-08ddea19ab16 X-MS-Exchange-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: IA0PR12MB7773 On 02/09/2025 13:54, Julien Grall wrote: > Hi, > > On 02/09/2025 11:18, Orzel, Michal wrote: >> >> >> On 02/09/2025 11:49, Oleksandr Tyshchenko wrote: >>> The said sub-op is not supported on Arm, since it: >>> - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn >>> cannot be returned), please refer to ioreq_server_create() >>> - does not support "legacy" mechanism of mapping IOREQ Server >>> magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please >>> refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire >>> Resource infrastructure is used to query and map the IOREQ Server pages. >>> >>> Signed-off-by: Oleksandr Tyshchenko >> Reviewed-by: Michal Orzel >> >> Could we perhaps add a Fixes tag here pointing to the commit introducing these >> DM ops and thus add this patch for this release? Not sure what others think. > > Fixes usually implies a bug and I don't see what bug we are solving. In > fact, I don't understand why we are trying to remove the subop... Hmm, the issue is that the subop that is not supported at the moment is listed as supported in the public header. I think if we mistakenly mention sth as supported in e.g. SUPPORT.md we would have no issues adding a Fixes tag. There are many cases where Fixes was used just to change something in a comment, so I'm having a hard time reasoning about when it's appropriate to use it. As for the code, from safety perspective if this subop is listed explicilty in Arm's dm.c, we would need to write a separate test case and test to cover it that at the end, still returns -EOPNOTSUPP. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:14:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:14:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106242.1456967 (Exim 4.92) (envelope-from ) id 1utPuF-0005dz-B7; Tue, 02 Sep 2025 12:14:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106242.1456967; Tue, 02 Sep 2025 12:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPuF-0005ds-8H; Tue, 02 Sep 2025 12:14:35 +0000 Received: by outflank-mailman (input) for mailman id 1106242; Tue, 02 Sep 2025 12:14: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 1utPuD-0005dm-Ob for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:14: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 617dd5a3-87f6-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:14:31 +0200 (CEST) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3db9641b725so146496f8f.2 for ; Tue, 02 Sep 2025 05:14:31 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d53fda847dsm10441089f8f.0.2025.09.02.05.14.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:14:30 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 617dd5a3-87f6-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756815271; x=1757420071; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Q3aFdQF1cfhWBuMfzuVNfwZbatR8AfdaWZ7DxMBccuQ=; b=pdJRAr1JuwXDqXMGRkZWFqDkQW95ay7sdVAEHwGcXFJBfEoc1hBWwLmzYvaLes3SnI iEXzFj0eec6TcTiH8qxWnB+Igux85ClP6ckvVEhTpkPE7hQ8eq6M4+i1ejFNUWGm9KYA UNofyvXXuVZrW95R5mxKA4DSlwUKCmJXOaOf8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756815271; x=1757420071; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Q3aFdQF1cfhWBuMfzuVNfwZbatR8AfdaWZ7DxMBccuQ=; b=WUSJS5NDhXatXOPEvGAEr+2bfg5DjMxQ8sv4k1vFuVgXrRSrRmEDbkENid4UHuSSw4 NQ3GQXhNRpA3BFoPae1lycgH3tLMNWWCQ5rYzQDYwsKOHy/n0yU6Cvjg5K155hTOfFmZ NUDpboLw9scR9ik0kMdflovXkn28NJVoA+V5AAaNH0AG+Jr1PWHGj/nxZKI8nUOHmUdH 73w7idguaNfwAf54jSogM3E7nD+vFjB56iYH/BWabrh2XoGHIMP2EJx1CUeLM1i3x+iW r279YCYF/2ZnY68F9WCvpx3z9MDnuFXoGoxurvCV4AwYzJDBbMfelhoBkOShKQV6OHxA Z4CQ== X-Gm-Message-State: AOJu0Yx77pgOUToqwCUFW6zp3f8j1i+7YRuVqocp73Y3qBugtifdi6xO sLSjYAb/ptJus/ZKBDn3iG/yCLr1d+kYeLbSSXo2vLB9ExsFbZxjtiwzb+ep5O5HBzc= X-Gm-Gg: ASbGncsTusBOSZ/7v3/n25s9YjAczpCpz0Phae/YoXffOT6uSJzljbKL0THgRCsegU1 cpFInIprnGIQe9optgJejNDsBbNRVzb6FEdQhHjaGR0PiM8z/aVuCVKysK5v1ttVB4JjMuM7F8v SSzszBxPBKELM4rnJgmkLg4MoK0kTSJMyB5QqUHblmJrsInN6qMOQ4iddVFinG0Odvk+Psdq7Q0 484njyoX5FZdKsVSgQpKRNxDtu2nZk4NlkKUZbyPXRta2IoZFEn5RG3GzJH1ma6g/nfkMx6Hafe RjQhxSyvx5RQnnAahsjHFT+eTL/lzEIO9+idS/y81tey+ceeD8FTSB/NaALs+WWe5j7GJT3hSNo UMYscnbspXY0i3G6KRWlgxzsiQpuz+8hE8qE2d6MlZ9yaJiODLMNeNFIHn0IzGu4nuJkD7Ix3Pa v6Ih4= X-Google-Smtp-Source: AGHT+IFNfSqjS2scDajx0lerSClUmaZuL4N/9hsivbDEtrzqOWY72dCWSEsDcI0L8QxqQDvoBgO67A== X-Received: by 2002:adf:f70c:0:b0:3d4:1517:d2b9 with SMTP id ffacd0b85a97d-3d41517d92amr5066327f8f.49.1756815271006; Tue, 02 Sep 2025 05:14:31 -0700 (PDT) Message-ID: <9a263568-54be-4193-9a4e-cd31268c5ee6@citrix.com> Date: Tue, 2 Sep 2025 13:14:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@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/09/2025 12:23 pm, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 12:13:27PM +0100, Andrew Cooper wrote: >> On 02/09/2025 11:56 am, Manuel Bouyer wrote: >>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>>>> Hello, >>>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>>>> The same NetBSD kernel works fine with Xen 4.18 >>>>> >>>>> The boot options are: >>>>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>>>> >>>>> and the full log from serial console is attached. >>>>> >>>>> With 4.20 the boot fails with: >>>>> >>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>>>> (XEN) Freed 664kB init memory >>>>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>>>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>>>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>>>> (XEN) CPU: 7 >>>>> (XEN) RIP: 0008:[<000000000020e268>] >>>>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>>>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>>>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>>>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>>>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>>>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>>>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>>>> >>>>> because of the triple fault the RIP above doens't point to the code. >>>>> >>>>> I tracked it down to this code: >>>>> cmpl $0,%ecx ; /* zero-sized? */ \ >>>>> je 2f ; \ >>>>> pushl %ebp ; \ >>>>> movl RELOC(nox_flag),%ebp ; \ >>>>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>>>> movl %eax,(%ebx) ; /* store phys addr */ \ >>>>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>>>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>>>> loop 1b ; \ >>>>> popl %ebp ; \ >>>>> 2: ; >>>>> >>>>> there are others pushl/popl before so I don't think that's the problem >>>>> (in fact the exact same fragment is called just before with different >>>>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>>>> which would be 0x20e260 >>>>> This is in the range: >>>>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>>>> so I can't see why this would be a problem. >>>>> >>>>> Any idea, including how to debug this further, welcome >>>> Even though triple fault's are aborts, they're generally accurate under >>>> virt, so 0x20e268 is most likely where things die. >>> but that's the RIP of the last fault, not the first one, right ? >>> 0x20e268 isn't in the text segment of the kernel, my guess is that the >>> first fault triggers an exception, but the exeption handler isn't set up yet >>> so we end up jumping to some random value. >> Double and Triple faults occur when trying to deliver an exception >> generates an exception.  So while multiple faults are involved, only one >> instruction typically is. >> >> Is this an Intel or an AMD system?  One thing virt can do is break apart >> a triple fault, but the logic to do so is vendor specific. > it's an old intel system: > cpu0: "Intel(R) Xeon(R) CPU X5650 @ 2.67GHz" > cpu0: Intel Xeon 36xx & 56xx, i7, i5 and i3 (686-class), 2667.30 MHz > cpu0: family 0x6 model 0x2c stepping 0x2 (id 0x206c2) > Hmm.  Westmere EP.  Are you running with EPT active, or with Shadow Paging? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:19:49 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:19:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106259.1456976 (Exim 4.92) (envelope-from ) id 1utPzF-0006Hw-1z; Tue, 02 Sep 2025 12:19:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106259.1456976; Tue, 02 Sep 2025 12: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 1utPzE-0006Hp-Vf; Tue, 02 Sep 2025 12:19:44 +0000 Received: by outflank-mailman (input) for mailman id 1106259; Tue, 02 Sep 2025 12:19:43 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utPzD-0006Hj-NB for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:19:43 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utPz6-002sVN-0p; Tue, 02 Sep 2025 12:19:36 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utPz6-00D4VF-0u; Tue, 02 Sep 2025 12:19:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=sOKsIW24p88VjgDar2drj4yIlw5UGQV0WxDlzQqNj8k=; b=Iq1g98H6nr0C5MNm5xyLc3KtpH WJQYk9er0uF+I/pk4Vi0m59RMwrON23q7SnLnOESdKfrSlalJgJPeSTOvVbuD8p6MrOqj61p1cRYd QMpS+Bwo82g7c9k/Oxqq0X9NfhhcqPEY23qACPZKaWxPL0nQLY0HM/TlN7Lzd6L9Aon8=; Message-ID: <8af7ca62-2f05-47d9-8604-170e7a40d8a0@xen.org> Date: Tue, 2 Sep 2025 13:19:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Content-Language: en-GB To: "Orzel, Michal" , Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> <319c280a-535d-498a-b0ab-93882663e23b@amd.com> <4e01ed71-cdbb-4d41-8845-33449b08494b@amd.com> From: Julien Grall In-Reply-To: <4e01ed71-cdbb-4d41-8845-33449b08494b@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/09/2025 13:10, Orzel, Michal wrote: > > > On 02/09/2025 13:54, Julien Grall wrote: >> Hi, >> >> On 02/09/2025 11:18, Orzel, Michal wrote: >>> >>> >>> On 02/09/2025 11:49, Oleksandr Tyshchenko wrote: >>>> The said sub-op is not supported on Arm, since it: >>>> - does not support the buffered emulation (so bufioreq_port/bufioreq_gfn >>>> cannot be returned), please refer to ioreq_server_create() >>>> - does not support "legacy" mechanism of mapping IOREQ Server >>>> magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please >>>> refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire >>>> Resource infrastructure is used to query and map the IOREQ Server pages. >>>> >>>> Signed-off-by: Oleksandr Tyshchenko >>> Reviewed-by: Michal Orzel >>> >>> Could we perhaps add a Fixes tag here pointing to the commit introducing these >>> DM ops and thus add this patch for this release? Not sure what others think. >> >> Fixes usually implies a bug and I don't see what bug we are solving. In >> fact, I don't understand why we are trying to remove the subop... > Hmm, the issue is that the subop that is not supported at the moment is listed > as supported in the public header. [...] > As for the code, from safety perspective if this subop is listed explicilty in Arm's > dm.c, we would need to write a separate test case and test to cover it that at > the end, still returns -EOPNOTSUPP. Why do you think it is not supported? AFAICT, it is still possible to pass XEN_DMOP_nognfs to figure out whwether bufioreq is currently available. The error code would be 0 not -EOPNOTSUPP. > I think if we mistakenly mention sth as> supported in e.g. SUPPORT.md we would have no issues adding a Fixes tag. There > are many cases where Fixes was used just to change something in a comment, so > I'm having a hard time reasoning about when it's appropriate to use it. I think what we would want is "Amends". This is currently proposed by [1]. [1] https://lore.kernel.org/xen-devel/e7c99116-f6a9-43e1-80ae-b3a4d44857b7@amd.com/T/#t > > ~Michal > -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:22:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:22:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106272.1456986 (Exim 4.92) (envelope-from ) id 1utQ1y-0007yD-Ek; Tue, 02 Sep 2025 12:22:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106272.1456986; Tue, 02 Sep 2025 12: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 1utQ1y-0007y6-C3; Tue, 02 Sep 2025 12:22:34 +0000 Received: by outflank-mailman (input) for mailman id 1106272; Tue, 02 Sep 2025 12:22: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 1utQ1x-0007y0-0f for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:22:33 +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 7f0e6fa0-87f7-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:22: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 4FD3F1F38F; Tue, 2 Sep 2025 12:22: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 1A4D413888; Tue, 2 Sep 2025 12:22: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 p0VPBIbhtmjxRQAAD6G6ig (envelope-from ); Tue, 02 Sep 2025 12:22:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f0e6fa0-87f7-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756815750; 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=iOWyPAhnVnUcwKSzBRYdNH2CPFxp/Rptscur4Sj4JYE=; b=qHyvTStHyVvzX/7Vlav4kpjnGKwqKxzfH9dy3GK4T5S5YjKW0MgQwfNYASzefuNTZ3eG2K uQbf42+ELOpsoUfJ5SoTf2I2V4MMjTCHkWYbu7mH51GoA9UWhSVXEldVaKYyJQR0yUx5Rv cUW92LzSGaC6H7fgx+dJzemqVKjlXIY= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756815750; 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=iOWyPAhnVnUcwKSzBRYdNH2CPFxp/Rptscur4Sj4JYE=; b=qHyvTStHyVvzX/7Vlav4kpjnGKwqKxzfH9dy3GK4T5S5YjKW0MgQwfNYASzefuNTZ3eG2K uQbf42+ELOpsoUfJ5SoTf2I2V4MMjTCHkWYbu7mH51GoA9UWhSVXEldVaKYyJQR0yUx5Rv cUW92LzSGaC6H7fgx+dJzemqVKjlXIY= Message-ID: <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> Date: Tue, 2 Sep 2025 14:22:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer , Andrew Cooper Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.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="------------2HGgRcD9o0xAP0RUnwBMEZzk" X-Spamd-Result: default: False [-5.20 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-0.993]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]; HAS_ATTACHMENT(0.00)[] X-Spam-Flag: NO X-Spam-Level: X-Spam-Score: -5.20 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------2HGgRcD9o0xAP0RUnwBMEZzk Content-Type: multipart/mixed; boundary="------------eas3qb7XCNYrfFl0Dpy0XRX2"; protected-headers="v1" From: Juergen Gross To: Manuel Bouyer , Andrew Cooper Cc: xen-devel@lists.xenproject.org Message-ID: <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> Subject: Re: issue with dom0_pvh on Xen 4.20 References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> In-Reply-To: --------------eas3qb7XCNYrfFl0Dpy0XRX2 Content-Type: multipart/mixed; boundary="------------PKcqyQf2PwCXcSguLT8NFcl3" --------------PKcqyQf2PwCXcSguLT8NFcl3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDIuMDkuMjUgMTI6NTYsIE1hbnVlbCBCb3V5ZXIgd3JvdGU6DQo+IE9uIFR1ZSwgU2Vw IDAyLCAyMDI1IGF0IDExOjQ0OjM2QU0gKzAxMDAsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+ PiBPbiAwMi8wOS8yMDI1IDExOjE3IGFtLCBNYW51ZWwgQm91eWVyIHdyb3RlOg0KPj4+IEhl bGxvLA0KPj4+IEknbSB0cnlpbmcgdG8gYm9vdCBhIE5ldEJTRCBQVkggZG9tMCBvbiBYZW4g NC4yMC4NCj4+PiBUaGUgc2FtZSBOZXRCU0Qga2VybmVsIHdvcmtzIGZpbmUgd2l0aCBYZW4g NC4xOA0KPj4+DQo+Pj4gVGhlIGJvb3Qgb3B0aW9ucyBhcmU6DQo+Pj4gbWVudT1Cb290IG5l dGJzZC1jdXJyZW50IFBWSCBYZW40MjA6ZGV2IGhkMGY6O2xvYWQgL25ldGJzZC1QVkggY29u c29sZT1jb20wIHJvb3Q9d2QwZjsgbXVsdGlib290IC94ZW40MjAtZGVidWcuZ3ogZG9tMF9t ZW09MTAyNE0gY29uc29sZT1jb20xIGNvbTE9Mzg0MDAsOG4xIGxvZ2x2bD1hbGwgZ3Vlc3Rf bG9nbHZsPWFsbCBnbnR0YWJfbWF4X25yX2ZyYW1lcz02NCBzeW5jX2NvbnNvbGU9MSBkb20w PXB2aA0KPj4+DQo+Pj4gYW5kIHRoZSBmdWxsIGxvZyBmcm9tIHNlcmlhbCBjb25zb2xlIGlz IGF0dGFjaGVkLg0KPj4+DQo+Pj4gV2l0aCA0LjIwIHRoZSBib290IGZhaWxzIHdpdGg6DQo+ Pj4NCj4+PiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IHRvIERPTTAgKHR5cGUgJ0NUUkwtYScg dGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0KQ0KPj4+IChYRU4pIEZyZWVkIDY2NGtCIGlu aXQgbWVtb3J5DQo+Pj4gKFhFTikgZDB2MCBUcmlwbGUgZmF1bHQgLSBpbnZva2luZyBIVk0g c2h1dGRvd24gYWN0aW9uIDENCj4+PiAoWEVOKSAqKiogRHVtcGluZyBEb20wIHZjcHUjMCBz dGF0ZTogKioqDQo+Pj4gKFhFTikgLS0tLVsgWGVuLTQuMjAuMi1wcmVfMjAyNTA4MjFuYjAg IHg4Nl82NCAgZGVidWc9eSAgVGFpbnRlZDogICBDICAgIF0tLS0tDQo+Pj4gKFhFTikgQ1BV OiAgICA3DQo+Pj4gKFhFTikgUklQOiAgICAwMDA4Ols8MDAwMDAwMDAwMDIwZTI2OD5dDQo+ Pj4gKFhFTikgUkZMQUdTOiAwMDAwMDAwMDAwMDEwMDA2ICAgQ09OVEVYVDogaHZtIGd1ZXN0 IChkMHYwKQ0KPj4+IChYRU4pIHJheDogMDAwMDAwMDAyMDI0YzAwMyAgIHJieDogMDAwMDAw MDAwMDIwZTI2MCAgIHJjeDogMDAwMDAwMDAwMDBkZmViNw0KPj4+IChYRU4pIHJkeDogMDAw MDAwMDAwMDEwMDAwMCAgIHJzaTogMDAwMDAwMDAwMDEwMzAwMCAgIHJkaTogMDAwMDAwMDAw MDEzZTAwMA0KPj4+IChYRU4pIHJicDogMDAwMDAwMDA4MDAwMDAwMCAgIHJzcDogMDAwMDAw MDAwMTQwMDJlNCAgIHI4OiAgMDAwMDAwMDAwMDAwMDAwMA0KPj4+IChYRU4pIHI5OiAgMDAw MDAwMDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAw MDAwMDAwMA0KPj4+IChYRU4pIHIxMjogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMzogMDAwMDAw MDAwMDAwMDAwMCAgIHIxNDogMDAwMDAwMDAwMDAwMDAwMA0KPj4+IChYRU4pIHIxNTogMDAw MDAwMDAwMDAwMDAwMCAgIGNyMDogMDAwMDAwMDAwMDAwMDAxMSAgIGNyNDogMDAwMDAwMDAw MDAwMDAwMA0KPj4+IChYRU4pIGNyMzogMDAwMDAwMDAwMDAwMDAwMCAgIGNyMjogMDAwMDAw MDAwMDAwMDAwMA0KPj4+IChYRU4pIGZzYjogMDAwMDAwMDAwMDAwMDAwMCAgIGdzYjogMDAw MDAwMDAwMDAwMDAwMCAgIGdzczogMDAwMDAwMDAwMDAwMDAwMA0KPj4+IChYRU4pIGRzOiAw MDEwICAgZXM6IDAwMTAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMTAgICBjczog MDAwOA0KPj4+DQo+Pj4gYmVjYXVzZSBvZiB0aGUgdHJpcGxlIGZhdWx0IHRoZSBSSVAgYWJv dmUgZG9lbnMndCBwb2ludCB0byB0aGUgY29kZS4NCj4+Pg0KPj4+IEkgdHJhY2tlZCBpdCBk b3duIHRvIHRoaXMgY29kZToNCj4+PiAgICAgICAgICBjbXBsICAgICQwLCVlY3ggICAgICAg ICAgICAgICAgIDsgICAgICAgLyogemVyby1zaXplZD8gKi8gICAgICAgXA0KPj4+ICAgICAg ICAgIGplICAgICAgMmYgICAgICAgICAgICAgICAgICAgICAgOyBcDQo+Pj4gICAgICAgICAg cHVzaGwgICAlZWJwICAgICAgICAgICAgICAgICAgICA7IFwNCj4+PiAgICAgICAgICBtb3Zs ICAgIFJFTE9DKG5veF9mbGFnKSwlZWJwICAgIDsgXA0KPj4+IDE6ICAgICAgbW92bCAgICAl ZWJwLChQREVfU0laRS00KSglZWJ4KSA7ICAgICAgIC8qIHVwcGVyIDMyIGJpdHM6IE5YICov IFwNCj4+PiAgICAgICAgICBtb3ZsICAgICVlYXgsKCVlYngpICAgICAgICAgICAgIDsgICAg ICAgLyogc3RvcmUgcGh5cyBhZGRyICovICAgXA0KPj4+ICAgICAgICAgIGFkZGwgICAgJFBE RV9TSVpFLCVlYnggICAgICAgICAgOyAgICAgICAvKiBuZXh0IFBURS9QREUgKi8gICAgICBc DQo+Pj4gICAgICAgICAgYWRkbCAgICAkUEFHRV9TSVpFLCVlYXggICAgICAgICA7ICAgICAg IC8qIG5leHQgcGh5cyBwYWdlICovICAgIFwNCj4+PiAgICAgICAgICBsb29wICAgIDFiICAg ICAgICAgICAgICAgICAgICAgIDsgXA0KPj4+ICAgICAgICAgIHBvcGwgICAgJWVicCAgICAg ICAgICAgICAgICAgICAgOyBcDQo+Pj4gMjogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDsNCj4+Pg0KPj4+IHRoZXJlIGFyZSBvdGhlcnMgcHVzaGwvcG9wbCBiZWZv cmUgc28gSSBkb24ndCB0aGluayB0aGF0J3MgdGhlIHByb2JsZW0NCj4+PiAoaW4gZmFjdCB0 aGUgZXhhY3Qgc2FtZSBmcmFnbWVudCBpcyBjYWxsZWQganVzdCBiZWZvcmUgd2l0aCBkaWZm ZXJlbnQNCj4+PiBpbnB1dHMgYW5kIGl0IGRvZXNuJ3QgZmF1bHQpLiBTbyB0aGUgY3VscHJp dCBpdCBwcm9iYWJseSB0aGUgd3JpdGUgdG8gKCVlYngpLA0KPj4+IHdoaWNoIHdvdWxkIGJl IDB4MjBlMjYwDQo+Pj4gVGhpcyBpcyBpbiB0aGUgcmFuZ2U6DQo+Pj4gKFhFTikgIFswMDAw MDAwMDAwMTAwMDAwLCAwMDAwMDAwMDQwMDY4ZTc3XSAodXNhYmxlKQ0KPj4+IHNvIEkgY2Fu J3Qgc2VlIHdoeSB0aGlzIHdvdWxkIGJlIGEgcHJvYmxlbS4NCj4+Pg0KPj4+IEFueSBpZGVh LCBpbmNsdWRpbmcgaG93IHRvIGRlYnVnIHRoaXMgZnVydGhlciwgd2VsY29tZQ0KPj4NCj4+ IEV2ZW4gdGhvdWdoIHRyaXBsZSBmYXVsdCdzIGFyZSBhYm9ydHMsIHRoZXkncmUgZ2VuZXJh bGx5IGFjY3VyYXRlIHVuZGVyDQo+PiB2aXJ0LCBzbyAweDIwZTI2OCBpcyBtb3N0IGxpa2Vs eSB3aGVyZSB0aGluZ3MgZGllLg0KPiANCj4gYnV0IHRoYXQncyB0aGUgUklQIG9mIHRoZSBs YXN0IGZhdWx0LCBub3QgdGhlIGZpcnN0IG9uZSwgcmlnaHQgPw0KPiAweDIwZTI2OCBpc24n dCBpbiB0aGUgdGV4dCBzZWdtZW50IG9mIHRoZSBrZXJuZWwsIG15IGd1ZXNzIGlzIHRoYXQg dGhlDQo+IGZpcnN0IGZhdWx0IHRyaWdnZXJzIGFuIGV4Y2VwdGlvbiwgYnV0IHRoZSBleGVw dGlvbiBoYW5kbGVyIGlzbid0IHNldCB1cCB5ZXQNCj4gc28gd2UgZW5kIHVwIGp1bXBpbmcg dG8gc29tZSByYW5kb20gdmFsdWUuDQo+IA0KDQpXaGF0IHB1enpsZXMgbWUgaXMgdGhhdDoN Cg0KLSAlY3IyIGlzIDAsIHNvIHByb2JhYmx5IHRoZSBmaXJzdCBmYXVsdCB3YXNuJ3QgYSBw YWdlIGZhdWx0DQotIFJJUCBpcyAlZWJ4ICsgOCwgc28gbWF5YmUgdGhlIGNvZGUgd2FzIGp1 c3QgY2xvYmJlcmVkIGJ5IHRoZSBsb29wPw0KDQpDb3VsZCBpdCBiZSB0aGUgY29kZSBoYXMg YmVlbiBtb3ZlZCB0byB0aGlzIGxvY2F0aW9uLCBvciBpcyBhYm91dCB0bw0KYmUgbW92ZWQg YXdheSBhZnRlcndhcmRzPw0KDQoNCkp1ZXJnZW4NCg== --------------PKcqyQf2PwCXcSguLT8NFcl3 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----- --------------PKcqyQf2PwCXcSguLT8NFcl3-- --------------eas3qb7XCNYrfFl0Dpy0XRX2-- --------------2HGgRcD9o0xAP0RUnwBMEZzk 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/Ey8FAmi24YUFAwAAAAAACgkQsN6d1ii/Ey8f rAgAiL4mlNJYggi+5XC79/szuKCABMaO7fKZVIxyF0e/7t9DyRJINvW8g0Jns1fM2aAW4nKb7ZOr BUUIVGjgUb5aEaZD29VyOM4y7/8K0daISxmisJ7K52SL6OklSxyxo5br3G5CVlMWDdZAbN9TU66X hXtiaEklrSXFGtwj01YOZh+onaJgS8i5Nl+wtHhiEg9Ijd+CMWUVCkBATHvDxYM5d6vU8p+lsAVq qie/xeBBMAaheJLyRGhZrz4+ifzbpxu8bFzg/QeE6Hd8bHPBaQ2FxQMygELcKzjloe/qaF2o6cy+ dTnxByD7VG6xD2hhGFvtyWYmY+WiSYB4a0LM6/Vpuw== =7hlr -----END PGP SIGNATURE----- --------------2HGgRcD9o0xAP0RUnwBMEZzk-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:24:47 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:24:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106280.1456996 (Exim 4.92) (envelope-from ) id 1utQ45-0008TW-Pq; Tue, 02 Sep 2025 12:24:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106280.1456996; Tue, 02 Sep 2025 12:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQ45-0008TP-NI; Tue, 02 Sep 2025 12:24:45 +0000 Received: by outflank-mailman (input) for mailman id 1106280; Tue, 02 Sep 2025 12:24: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 1utQ44-0008TJ-Ne for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:24:44 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ccfea49a-87f7-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:24:41 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582COdJk017765 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 14:24:39 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582COdgd016606; Tue, 2 Sep 2025 14:24:39 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id C8C79107F7; Tue, 2 Sep 2025 14:24: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: ccfea49a-87f7-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 14:24:37 +0200 From: Manuel Bouyer To: Andrew Cooper Cc: xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <9a263568-54be-4193-9a4e-cd31268c5ee6@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9a263568-54be-4193-9a4e-cd31268c5ee6@citrix.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 14:24:39 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 01:14:29PM +0100, Andrew Cooper wrote: > On 02/09/2025 12:23 pm, Manuel Bouyer wrote: > > On Tue, Sep 02, 2025 at 12:13:27PM +0100, Andrew Cooper wrote: > >> On 02/09/2025 11:56 am, Manuel Bouyer wrote: > >>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: > >>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote: > >>>>> Hello, > >>>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > >>>>> The same NetBSD kernel works fine with Xen 4.18 > >>>>> > >>>>> The boot options are: > >>>>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh > >>>>> > >>>>> and the full log from serial console is attached. > >>>>> > >>>>> With 4.20 the boot fails with: > >>>>> > >>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > >>>>> (XEN) Freed 664kB init memory > >>>>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > >>>>> (XEN) *** Dumping Dom0 vcpu#0 state: *** > >>>>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > >>>>> (XEN) CPU: 7 > >>>>> (XEN) RIP: 0008:[<000000000020e268>] > >>>>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > >>>>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > >>>>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > >>>>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > >>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > >>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > >>>>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > >>>>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > >>>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > >>>>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > >>>>> > >>>>> because of the triple fault the RIP above doens't point to the code. > >>>>> > >>>>> I tracked it down to this code: > >>>>> cmpl $0,%ecx ; /* zero-sized? */ \ > >>>>> je 2f ; \ > >>>>> pushl %ebp ; \ > >>>>> movl RELOC(nox_flag),%ebp ; \ > >>>>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > >>>>> movl %eax,(%ebx) ; /* store phys addr */ \ > >>>>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > >>>>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ > >>>>> loop 1b ; \ > >>>>> popl %ebp ; \ > >>>>> 2: ; > >>>>> > >>>>> there are others pushl/popl before so I don't think that's the problem > >>>>> (in fact the exact same fragment is called just before with different > >>>>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > >>>>> which would be 0x20e260 > >>>>> This is in the range: > >>>>> (XEN) [0000000000100000, 0000000040068e77] (usable) > >>>>> so I can't see why this would be a problem. > >>>>> > >>>>> Any idea, including how to debug this further, welcome > >>>> Even though triple fault's are aborts, they're generally accurate under > >>>> virt, so 0x20e268 is most likely where things die. > >>> but that's the RIP of the last fault, not the first one, right ? > >>> 0x20e268 isn't in the text segment of the kernel, my guess is that the > >>> first fault triggers an exception, but the exeption handler isn't set up yet > >>> so we end up jumping to some random value. > >> Double and Triple faults occur when trying to deliver an exception > >> generates an exception. So while multiple faults are involved, only one > >> instruction typically is. > >> > >> Is this an Intel or an AMD system? One thing virt can do is break apart > >> a triple fault, but the logic to do so is vendor specific. > > it's an old intel system: > > cpu0: "Intel(R) Xeon(R) CPU X5650 @ 2.67GHz" > > cpu0: Intel Xeon 36xx & 56xx, i7, i5 and i3 (686-class), 2667.30 MHz > > cpu0: family 0x6 model 0x2c stepping 0x2 (id 0x206c2) > > > > Hmm. Westmere EP. Are you running with EPT active, or with Shadow Paging? How do I know ? Note that the same problem shows up on much newer systems: an i9, and a Xeon W-2223. Both boots fine with the same NetBSD kernel and Xen 4.18 or 4.15. I'm using this old Xeon for debug because this one has a serial console. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:28:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:28:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106295.1457016 (Exim 4.92) (envelope-from ) id 1utQ7n-0000sH-Lj; Tue, 02 Sep 2025 12:28:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106295.1457016; Tue, 02 Sep 2025 12:28:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQ7n-0000sA-IX; Tue, 02 Sep 2025 12:28:35 +0000 Received: by outflank-mailman (input) for mailman id 1106295; Tue, 02 Sep 2025 12:28: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 1utQ7l-0000de-UQ for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:28:33 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 56d63e8a-87f8-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 14:28:33 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582CSUuB018402 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 14:28:31 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582CSUr8017102; Tue, 2 Sep 2025 14:28:30 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 5ADE0107F7; Tue, 2 Sep 2025 14:28: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: 56d63e8a-87f8-11f0-8adc-4578a1afcccb Date: Tue, 2 Sep 2025 14:28:29 +0200 From: Manuel Bouyer To: Juergen Gross Cc: Andrew Cooper , xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 14:28:31 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 02:22:29PM +0200, Juergen Gross wrote: > On 02.09.25 12:56, Manuel Bouyer wrote: > > On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: > > > On 02/09/2025 11:17 am, Manuel Bouyer wrote: > > > > Hello, > > > > I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > > > > The same NetBSD kernel works fine with Xen 4.18 > > > > > > > > The boot options are: > > > > menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh > > > > > > > > and the full log from serial console is attached. > > > > > > > > With 4.20 the boot fails with: > > > > > > > > (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > > > > (XEN) Freed 664kB init memory > > > > (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > > > > (XEN) *** Dumping Dom0 vcpu#0 state: *** > > > > (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > > > > (XEN) CPU: 7 > > > > (XEN) RIP: 0008:[<000000000020e268>] > > > > (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > > > > (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > > > > (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > > > > (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > > > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > > > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > > > > (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > > > > (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > > > > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > > > > (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > > > > > > > > because of the triple fault the RIP above doens't point to the code. > > > > > > > > I tracked it down to this code: > > > > cmpl $0,%ecx ; /* zero-sized? */ \ > > > > je 2f ; \ > > > > pushl %ebp ; \ > > > > movl RELOC(nox_flag),%ebp ; \ > > > > 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > > > > movl %eax,(%ebx) ; /* store phys addr */ \ > > > > addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > > > > addl $PAGE_SIZE,%eax ; /* next phys page */ \ > > > > loop 1b ; \ > > > > popl %ebp ; \ > > > > 2: ; > > > > > > > > there are others pushl/popl before so I don't think that's the problem > > > > (in fact the exact same fragment is called just before with different > > > > inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > > > > which would be 0x20e260 > > > > This is in the range: > > > > (XEN) [0000000000100000, 0000000040068e77] (usable) > > > > so I can't see why this would be a problem. > > > > > > > > Any idea, including how to debug this further, welcome > > > > > > Even though triple fault's are aborts, they're generally accurate under > > > virt, so 0x20e268 is most likely where things die. > > > > but that's the RIP of the last fault, not the first one, right ? > > 0x20e268 isn't in the text segment of the kernel, my guess is that the > > first fault triggers an exception, but the exeption handler isn't set up yet > > so we end up jumping to some random value. > > > > What puzzles me is that: > > - %cr2 is 0, so probably the first fault wasn't a page fault AFAIK it can't be as we're still in real mode > - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? > > Could it be the code has been moved to this location, or is about to > be moved away afterwards? No. RIP shouldn't end up there in any way. the assembly code is quite simple, it's just a loop and I'm quite confident that we did enter the loop with sane values -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:28:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:28:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106294.1457006 (Exim 4.92) (envelope-from ) id 1utQ7l-0000dr-9q; Tue, 02 Sep 2025 12:28:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106294.1457006; Tue, 02 Sep 2025 12:28: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 1utQ7l-0000dk-78; Tue, 02 Sep 2025 12:28:33 +0000 Received: by outflank-mailman (input) for mailman id 1106294; Tue, 02 Sep 2025 12:28: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 1utQ7k-0000de-0W for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:28:32 +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 5568fc30-87f8-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 14:28:30 +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 B6EE91F394; Tue, 2 Sep 2025 12:28: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 8EE2413888; Tue, 2 Sep 2025 12:28: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 2sRrIezitmjhRwAAD6G6ig (envelope-from ); Tue, 02 Sep 2025 12:28: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: 5568fc30-87f8-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756816110; 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=G+K/VzTMBzDs7fQuBwyce8UB6JA4tcDdbMURhPihSLs=; b=SsKQ5bQHFMI1jiiibkGf119YXhl47qIZbqQoJvv552ZqxgNP0wS6jcHvtvP1gXid/cxvXV fDkfSxysUP7G02xScHykeP8i7ADvJdY70u0+IfuVlpTsZYNDhUBVdY0T7rzWV4RQq1R6+0 g2YloKLZrkBNl7CKrzHTEitOvaohS/k= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=XRSxzP4N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756816108; 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=G+K/VzTMBzDs7fQuBwyce8UB6JA4tcDdbMURhPihSLs=; b=XRSxzP4Ng+lEc2B6GbMUbIC1UW8LXaauMBo0M5R9iR2oqljfRtYdFLrr/DxRnDxmQzHF/x DXPaD8ORdrpXqjjlA9PvOO5oDKCKjmmatiHgqcxBqeF5a0+L1kBpq+/dx0ljSbxdvW9eIi 8bxNlS4F+sfJ8l2NnYHAvzbHe+5NvU0= Message-ID: <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> Date: Tue, 2 Sep 2025 14:28:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 From: Juergen Gross To: Manuel Bouyer , Andrew Cooper Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@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: <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------c87ClrN02AQArw9YFUsUmFmv" X-Spam-Level: X-Spam-Flag: NO X-Rspamd-Queue-Id: B6EE91F394 X-Rspamd-Action: no action X-Rspamd-Server: rspamd1.dmz-prg2.suse.org 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_SIGNED(0.00)[suse.com:s=susede1]; FROM_HAS_DN(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Spam-Score: -6.41 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------c87ClrN02AQArw9YFUsUmFmv Content-Type: multipart/mixed; boundary="------------U8ErYhD1Ftw9n9VvnoXNUylP"; protected-headers="v1" From: Juergen Gross To: Manuel Bouyer , Andrew Cooper Cc: xen-devel@lists.xenproject.org Message-ID: <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> Subject: Re: issue with dom0_pvh on Xen 4.20 References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> In-Reply-To: <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> --------------U8ErYhD1Ftw9n9VvnoXNUylP Content-Type: multipart/mixed; boundary="------------H00j1QskIirtmuvCQULPLslD" --------------H00j1QskIirtmuvCQULPLslD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDIuMDkuMjUgMTQ6MjIsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IE9uIDAyLjA5LjI1 IDEyOjU2LCBNYW51ZWwgQm91eWVyIHdyb3RlOg0KPj4gT24gVHVlLCBTZXAgMDIsIDIwMjUg YXQgMTE6NDQ6MzZBTSArMDEwMCwgQW5kcmV3IENvb3BlciB3cm90ZToNCj4+PiBPbiAwMi8w OS8yMDI1IDExOjE3IGFtLCBNYW51ZWwgQm91eWVyIHdyb3RlOg0KPj4+PiBIZWxsbywNCj4+ Pj4gSSdtIHRyeWluZyB0byBib290IGEgTmV0QlNEIFBWSCBkb20wIG9uIFhlbiA0LjIwLg0K Pj4+PiBUaGUgc2FtZSBOZXRCU0Qga2VybmVsIHdvcmtzIGZpbmUgd2l0aCBYZW4gNC4xOA0K Pj4+Pg0KPj4+PiBUaGUgYm9vdCBvcHRpb25zIGFyZToNCj4+Pj4gbWVudT1Cb290IG5ldGJz ZC1jdXJyZW50IFBWSCBYZW40MjA6ZGV2IGhkMGY6O2xvYWQgL25ldGJzZC1QVkggY29uc29s ZT1jb20wIA0KPj4+PiByb290PXdkMGY7IG11bHRpYm9vdCAveGVuNDIwLWRlYnVnLmd6IGRv bTBfbWVtPTEwMjRNIGNvbnNvbGU9Y29tMSANCj4+Pj4gY29tMT0zODQwMCw4bjEgbG9nbHZs PWFsbCBndWVzdF9sb2dsdmw9YWxsIGdudHRhYl9tYXhfbnJfZnJhbWVzPTY0IA0KPj4+PiBz eW5jX2NvbnNvbGU9MSBkb20wPXB2aA0KPj4+Pg0KPj4+PiBhbmQgdGhlIGZ1bGwgbG9nIGZy b20gc2VyaWFsIGNvbnNvbGUgaXMgYXR0YWNoZWQuDQo+Pj4+DQo+Pj4+IFdpdGggNC4yMCB0 aGUgYm9vdCBmYWlscyB3aXRoOg0KPj4+Pg0KPj4+PiAoWEVOKSAqKiogU2VyaWFsIGlucHV0 IHRvIERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0KQ0K Pj4+PiAoWEVOKSBGcmVlZCA2NjRrQiBpbml0IG1lbW9yeQ0KPj4+PiAoWEVOKSBkMHYwIFRy aXBsZSBmYXVsdCAtIGludm9raW5nIEhWTSBzaHV0ZG93biBhY3Rpb24gMQ0KPj4+PiAoWEVO KSAqKiogRHVtcGluZyBEb20wIHZjcHUjMCBzdGF0ZTogKioqDQo+Pj4+IChYRU4pIC0tLS1b IFhlbi00LjIwLjItcHJlXzIwMjUwODIxbmIwwqAgeDg2XzY0wqAgZGVidWc9ecKgIFRhaW50 ZWQ6wqDCoCBDwqDCoMKgIF0tLS0tDQo+Pj4+IChYRU4pIENQVTrCoMKgwqAgNw0KPj4+PiAo WEVOKSBSSVA6wqDCoMKgIDAwMDg6WzwwMDAwMDAwMDAwMjBlMjY4Pl0NCj4+Pj4gKFhFTikg UkZMQUdTOiAwMDAwMDAwMDAwMDEwMDA2wqDCoCBDT05URVhUOiBodm0gZ3Vlc3QgKGQwdjAp DQo+Pj4+IChYRU4pIHJheDogMDAwMDAwMDAyMDI0YzAwM8KgwqAgcmJ4OiAwMDAwMDAwMDAw MjBlMjYwwqDCoCByY3g6IDAwMDAwMDAwMDAwZGZlYjcNCj4+Pj4gKFhFTikgcmR4OiAwMDAw MDAwMDAwMTAwMDAwwqDCoCByc2k6IDAwMDAwMDAwMDAxMDMwMDDCoMKgIHJkaTogMDAwMDAw MDAwMDEzZTAwMA0KPj4+PiAoWEVOKSByYnA6IDAwMDAwMDAwODAwMDAwMDDCoMKgIHJzcDog MDAwMDAwMDAwMTQwMDJlNMKgwqAgcjg6wqAgMDAwMDAwMDAwMDAwMDAwMA0KPj4+PiAoWEVO KSByOTrCoCAwMDAwMDAwMDAwMDAwMDAwwqDCoCByMTA6IDAwMDAwMDAwMDAwMDAwMDDCoMKg IHIxMTogMDAwMDAwMDAwMDAwMDAwMA0KPj4+PiAoWEVOKSByMTI6IDAwMDAwMDAwMDAwMDAw MDDCoMKgIHIxMzogMDAwMDAwMDAwMDAwMDAwMMKgwqAgcjE0OiAwMDAwMDAwMDAwMDAwMDAw DQo+Pj4+IChYRU4pIHIxNTogMDAwMDAwMDAwMDAwMDAwMMKgwqAgY3IwOiAwMDAwMDAwMDAw MDAwMDExwqDCoCBjcjQ6IDAwMDAwMDAwMDAwMDAwMDANCj4+Pj4gKFhFTikgY3IzOiAwMDAw MDAwMDAwMDAwMDAwwqDCoCBjcjI6IDAwMDAwMDAwMDAwMDAwMDANCj4+Pj4gKFhFTikgZnNi OiAwMDAwMDAwMDAwMDAwMDAwwqDCoCBnc2I6IDAwMDAwMDAwMDAwMDAwMDDCoMKgIGdzczog MDAwMDAwMDAwMDAwMDAwMA0KPj4+PiAoWEVOKSBkczogMDAxMMKgwqAgZXM6IDAwMTDCoMKg IGZzOiAwMDAwwqDCoCBnczogMDAwMMKgwqAgc3M6IDAwMTDCoMKgIGNzOiAwMDA4DQo+Pj4+ DQo+Pj4+IGJlY2F1c2Ugb2YgdGhlIHRyaXBsZSBmYXVsdCB0aGUgUklQIGFib3ZlIGRvZW5z J3QgcG9pbnQgdG8gdGhlIGNvZGUuDQo+Pj4+DQo+Pj4+IEkgdHJhY2tlZCBpdCBkb3duIHRv IHRoaXMgY29kZToNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBjbXBswqDCoMKgICQwLCVlY3jC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA7wqDCoMKgwqDCoMKgIC8qIHplcm8t c2l6ZWQ/ICovwqDCoMKgwqDCoMKgIFwNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBqZcKgwqDC oMKgwqAgMmbCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOyBc DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgcHVzaGzCoMKgICVlYnDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA7IFwNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBtb3Zs wqDCoMKgIFJFTE9DKG5veF9mbGFnKSwlZWJwwqDCoMKgIDsgXA0KPj4+PiAxOsKgwqDCoMKg wqAgbW92bMKgwqDCoCAlZWJwLChQREVfU0laRS00KSglZWJ4KSA7wqDCoMKgwqDCoMKgIC8q IHVwcGVyIDMyIGJpdHM6IE5YICovIFwNCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoCBtb3ZswqDC oMKgICVlYXgsKCVlYngpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDvCoMKgwqDCoMKgwqAg Lyogc3RvcmUgcGh5cyBhZGRyICovwqDCoCBcDQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqAgYWRk bMKgwqDCoCAkUERFX1NJWkUsJWVieMKgwqDCoMKgwqDCoMKgwqDCoCA7wqDCoMKgwqDCoMKg IC8qIG5leHQgUFRFL1BERSAqL8KgwqDCoMKgwqAgXA0KPj4+PiDCoMKgwqDCoMKgwqDCoMKg IGFkZGzCoMKgwqAgJFBBR0VfU0laRSwlZWF4wqDCoMKgwqDCoMKgwqDCoCA7wqDCoMKgwqDC oMKgIC8qIG5leHQgcGh5cyBwYWdlICovwqDCoMKgIFwNCj4+Pj4gwqDCoMKgwqDCoMKgwqDC oCBsb29wwqDCoMKgIDFiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDsgXA0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIHBvcGzCoMKgwqAgJWVicMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDsgXA0KPj4+PiAyOsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIDsNCj4+Pj4NCj4+Pj4gdGhlcmUgYXJlIG90aGVycyBwdXNobC9wb3BsIGJl Zm9yZSBzbyBJIGRvbid0IHRoaW5rIHRoYXQncyB0aGUgcHJvYmxlbQ0KPj4+PiAoaW4gZmFj dCB0aGUgZXhhY3Qgc2FtZSBmcmFnbWVudCBpcyBjYWxsZWQganVzdCBiZWZvcmUgd2l0aCBk aWZmZXJlbnQNCj4+Pj4gaW5wdXRzIGFuZCBpdCBkb2Vzbid0IGZhdWx0KS4gU28gdGhlIGN1 bHByaXQgaXQgcHJvYmFibHkgdGhlIHdyaXRlIHRvICglZWJ4KSwNCj4+Pj4gd2hpY2ggd291 bGQgYmUgMHgyMGUyNjANCj4+Pj4gVGhpcyBpcyBpbiB0aGUgcmFuZ2U6DQo+Pj4+IChYRU4p wqAgWzAwMDAwMDAwMDAxMDAwMDAsIDAwMDAwMDAwNDAwNjhlNzddICh1c2FibGUpDQo+Pj4+ IHNvIEkgY2FuJ3Qgc2VlIHdoeSB0aGlzIHdvdWxkIGJlIGEgcHJvYmxlbS4NCj4+Pj4NCj4+ Pj4gQW55IGlkZWEsIGluY2x1ZGluZyBob3cgdG8gZGVidWcgdGhpcyBmdXJ0aGVyLCB3ZWxj b21lDQo+Pj4NCj4+PiBFdmVuIHRob3VnaCB0cmlwbGUgZmF1bHQncyBhcmUgYWJvcnRzLCB0 aGV5J3JlIGdlbmVyYWxseSBhY2N1cmF0ZSB1bmRlcg0KPj4+IHZpcnQsIHNvIDB4MjBlMjY4 IGlzIG1vc3QgbGlrZWx5IHdoZXJlIHRoaW5ncyBkaWUuDQo+Pg0KPj4gYnV0IHRoYXQncyB0 aGUgUklQIG9mIHRoZSBsYXN0IGZhdWx0LCBub3QgdGhlIGZpcnN0IG9uZSwgcmlnaHQgPw0K Pj4gMHgyMGUyNjggaXNuJ3QgaW4gdGhlIHRleHQgc2VnbWVudCBvZiB0aGUga2VybmVsLCBt eSBndWVzcyBpcyB0aGF0IHRoZQ0KPj4gZmlyc3QgZmF1bHQgdHJpZ2dlcnMgYW4gZXhjZXB0 aW9uLCBidXQgdGhlIGV4ZXB0aW9uIGhhbmRsZXIgaXNuJ3Qgc2V0IHVwIHlldA0KPj4gc28g d2UgZW5kIHVwIGp1bXBpbmcgdG8gc29tZSByYW5kb20gdmFsdWUuDQo+Pg0KPiANCj4gV2hh dCBwdXp6bGVzIG1lIGlzIHRoYXQ6DQo+IA0KPiAtICVjcjIgaXMgMCwgc28gcHJvYmFibHkg dGhlIGZpcnN0IGZhdWx0IHdhc24ndCBhIHBhZ2UgZmF1bHQNCj4gLSBSSVAgaXMgJWVieCAr IDgsIHNvIG1heWJlIHRoZSBjb2RlIHdhcyBqdXN0IGNsb2JiZXJlZCBieSB0aGUgbG9vcD8N Cj4gDQo+IENvdWxkIGl0IGJlIHRoZSBjb2RlIGhhcyBiZWVuIG1vdmVkIHRvIHRoaXMgbG9j YXRpb24sIG9yIGlzIGFib3V0IHRvDQo+IGJlIG1vdmVkIGF3YXkgYWZ0ZXJ3YXJkcz8NCg0K QW5kIGluZGVlZDogZnJvbSB0aGUgZnVsbCBib290IGxvZyBJIGNhbiBzZWU6DQoNCihYRU4p ICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHgwDQooWEVOKSAgICAgZWxmX3BhZGRyX29mZnNl dCA9IDB4MA0KKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweDANCihYRU4pICAgICB2 aXJ0X2tzdGFydCAgICAgID0gMHgyMDAwMDANCihYRU4pICAgICB2aXJ0X2tlbmQgICAgICAg ID0gMHgxN2JhYjkwDQooWEVOKSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4MjBlNGQwDQoN ClNvIHZpcnRfa2VudHJ5IGlzIHZlcnkgbmVhciB0byB0aGUgUklQLg0KDQoNCkp1ZXJnZW4N Cg== --------------H00j1QskIirtmuvCQULPLslD 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----- --------------H00j1QskIirtmuvCQULPLslD-- --------------U8ErYhD1Ftw9n9VvnoXNUylP-- --------------c87ClrN02AQArw9YFUsUmFmv 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/Ey8FAmi24uwFAwAAAAAACgkQsN6d1ii/Ey97 TggAhzQfnvJ6djcEd4dgO1Jrj+LkBtdL22GbIb9LNVhzXvdGzFRAKH1U0SBijzk5QJzlb87IaGBf qDMwDarjh6Nk9BfwXNIybr26dmdmutzELH07tLjsSMqfxSRR/vptnpGva0kqaHwzm0DRmd0U7OAp HWDrPstKpulStsQL8KP7vpcMkubmPUxTDw5eRKsGMnbxAOrwhfTA1rH0CGUBo7N4RZ0WZ6Q8niDq WY6/NUUbtcxDdIgrDPKas7OfC2fINfDynpPbRA6yDpzGeolFN5/AIvuWX0NlsNPweOYJjSjGR126 XQTWYjsntOtQqafjas6vJqj1pr5b8lsRt0b3dvUyMQ== =ki0z -----END PGP SIGNATURE----- --------------c87ClrN02AQArw9YFUsUmFmv-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:35:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:35:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106323.1457026 (Exim 4.92) (envelope-from ) id 1utQEZ-0002we-Bf; Tue, 02 Sep 2025 12:35:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106323.1457026; Tue, 02 Sep 2025 12: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 1utQEZ-0002wX-93; Tue, 02 Sep 2025 12:35:35 +0000 Received: by outflank-mailman (input) for mailman id 1106323; Tue, 02 Sep 2025 12: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 1utQEY-0002wR-3D for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:35:34 +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 50b81685-87f9-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:35:32 +0200 (CEST) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-619487c8865so11060871a12.1 for ; Tue, 02 Sep 2025 05: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 4fb4d7f45d1cf-61d3174074bsm6371063a12.35.2025.09.02.05.35.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05: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: 50b81685-87f9-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756816531; x=1757421331; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=MVrRlgI3NdINquJMa1Z1E0HRvulqn/Sw7JVhHhLKaLg=; b=Sd8KBJ3Fc/VEcMt5qm8OE+SNwE3X2U5oyGiGmQE9tqE9XkhC2Mf54toFw0Eg9xlibm rN2PYuzlZRzGWnMDdMe1zJA3v5s3Jr7dLLzEWoFyyKYc1dg/lShtWoBgMBAueD4srFf4 KFGH7qey1w1UIrx12rfZ5gP1pPTniYKO3DbI00HuyrLrwGPOZKgWPIWBJoGHY06srQ+N cV6PkT5Ez5/TVMmK5Iv8Xm9bCoi/eaHMgTalA4H4tmkrCCWkeBMERBroy6f02wOyovRS wMt00iWy2COiwfORZGvxP39awD0dm+mw0cUqNwV9qEZ/Yr4FKEHlu9TH04g6sQkkYQmN 3wYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756816531; x=1757421331; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MVrRlgI3NdINquJMa1Z1E0HRvulqn/Sw7JVhHhLKaLg=; b=irUzCG1NyENJUlkYEKWVc9Sr1ty1rfLl/6Bh6MIwr02eBZeakmQ/8OhSmvQyXLJy9+ YN9FADJokEtyFhlGEzp4uPsi2YfxOBOCyiuU9SpG5ecMba/JRLHDh4loNT4ihPg51TCS DCtJfE++jni231xgESTd+3+YaavQ3zTvWpCZr2slHWZ3cn443NZqHxZlEwd/ao4ZqmRx UyFjY4I+RnLIJOFr2004imZS0+OBvT62E1iNXvo5Hwny979FBcktbvxcYlgIe8ug8/45 vrVqcjVRDSi0MaSFjTheOHCc007wO49/W3Zsx/Jjp1nNO00KUhAp0oiZS7U9FbYEskLz Etig== X-Forwarded-Encrypted: i=1; AJvYcCVrOb/j2PoutPiZgSUrntCedhejI454QVCRtcF91ORjK9Rp/dX+Ohu0DIUMkgU2ZIAja7EJiaMWSic=@lists.xenproject.org X-Gm-Message-State: AOJu0YwCpS8jjUFS851lOF/wS5c/mEF2AI3pC8v23KxHqKEsNeAscvFl Lwu1rsyV7PSJoRGlx8vppYtkm3ZfnaK/1ApC7mQb0owE76cLbwKeCkUYbLsWdx/DWA== X-Gm-Gg: ASbGncuuLRyfyaQ7W/0EZ8gNjqCz6gE5ya65huOTruEupZEiAaAAlj1KlvrFE2K918i Aq391Ln+5ZNSeNmhuUg9d9HvG6/A7OSvSqyGH1FInU6fp5KvrtAWp8Xr9cDgTIEetYCoxUWAPbO RYafLrjzGdawn+8PMBu1FaBlBAN3osbBswe5fYF+7TIZH+0s6rYRNW6E47515ttl9KrPgW+mitA 6pJSrmQ8dZYkypXG4xtFKaRXv/DdfJkaS1Zv+YujAZeoEVU8v6uoxiGq9mZDQDxRDrKHGDSDXSo O/3eHZcvoc3mAYLV+AJBoMEI5ZJUTxcZbxD8BFYW8taPKUer6Wt6oOvY8/YMxIseV3pRUes3Sry IbDw1gi3szPo3q9FSYemAFqu56zpioBnOfpM+ngr3WE61Sv7jFUgQ8vBL0ln2cqNSoiwRRlaDqK 2shureELF/8TfQwCCKKg== X-Google-Smtp-Source: AGHT+IFnAXfYbBskkEYYda6XSlHfUUXH97e5Lrn7rbfQ9HsF0/SYlwyIhB3iIOnPc7u875fbYfYvuQ== X-Received: by 2002:a05:6402:2356:b0:61c:e287:7ad3 with SMTP id 4fb4d7f45d1cf-61d22dfbd0emr12464067a12.6.1756816531436; Tue, 02 Sep 2025 05:35:31 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 14:35:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 2/3] hvmloader: Update to SMBIOS 2.6 To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <57c674cc364d3b8f4c6d03533b9e2b45728d2c19.1756460430.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: <57c674cc364d3b8f4c6d03533b9e2b45728d2c19.1756460430.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.08.2025 11:58, Teddy Astie wrote: > @@ -505,7 +505,22 @@ smbios_type_1_init(void *start, const char *xen_version, > p->version_str = 3; > p->serial_number_str = 4; > > - memcpy(p->uuid, uuid, 16); > + /* > + * Xen toolstack uses big endian UUIDs, however GUIDs (which requirement > + * is clarified by SMBIOS >= 2.6) has the first 3 components appearing as > + * being little endian and the rest as still being big endian. > + */ The SMBIOS spec I'm looking at (2.7.1) doesn't mention the term GUID at all (except of course when discussing the EFI System Table entry). It's all UUID there. Here and in the description I think this needs expressing better, to not raise extra questions. As to endian-ness: Since everything from byte 8 onwards are merely bytes, I don't think it makes much sense to talk of endian-ness for that latter half. > @@ -716,7 +731,7 @@ smbios_type_4_init( > > p->socket_designation_str = 1; > p->processor_type = 0x03; /* CPU */ > - p->processor_family = 0x01; /* other */ > + p->processor_family = p->processor_family_2 = 0x01; /* other */ In the hypervisor we need to avoid such double assignments for Misra's sake. I think we're better off avoiding them in hvmloader as well. > @@ -736,6 +751,22 @@ smbios_type_4_init( > p->l2_cache_handle = 0xffff; /* No cache information structure provided. */ > p->l3_cache_handle = 0xffff; /* No cache information structure provided. */ > > + /* > + * We have a smbios type 4 table per vCPU (which is per socket), > + * which means here that we have 1 socket per vCPU. > + */ > + p->core_count = p->core_enabled = p->thread_count = 1; Might we be better off keeping them all at 0 (unknown)? > + /* > + * We set 64-bits, execute protection and enhanced virtualization. > + * We don't set Multi-Core (bit 3) because this individual processor > + * (as being a single vCPU) is only having one core. > + * > + * SMBIOS specification says that these bits don't state anything > + * regarding the actual availability of such features. > + */ > + p->processor_characteristics = 0x64; Unless nested virt is enabled for the guest, I think we'd better avoid setting the Enhanced Virtualization bit. > @@ -870,8 +901,8 @@ smbios_type_17_init(void *start, uint32_t memory_size_mb, int instance) > char buf[16]; > struct smbios_type_17 *p = start; > > - /* Specification says Type 17 table has length of 1Bh for v2.3-2.6. */ > - BUILD_BUG_ON(sizeof(*p) != 27); > + /* Specification says Type 17 table has length of 1Ch for v2.6. */ > + BUILD_BUG_ON(sizeof(*p) != 28); > > memset(p, 0, sizeof(*p)); With this, ... > @@ -890,6 +921,7 @@ smbios_type_17_init(void *start, uint32_t memory_size_mb, int instance) > p->bank_locator_str = 0; > p->memory_type = 0x07; /* RAM */ > p->type_detail = 0; > + p->attributes = 0; ... I don't think we really need this. In fact I was considering to make a patch to strip all the unnecessary assignments of zero. > --- a/tools/firmware/hvmloader/smbios_types.h > +++ b/tools/firmware/hvmloader/smbios_types.h > @@ -147,6 +147,11 @@ struct smbios_type_4 { > uint8_t serial_number_str; > uint8_t asset_tag_str; > uint8_t part_number_str; > + uint8_t core_count; > + uint8_t core_enabled; > + uint8_t thread_count; > + uint16_t processor_characteristics; > + uint16_t processor_family_2; > } __attribute__ ((packed)); > > /* SMBIOS type 7 - Cache Information */ > @@ -185,6 +190,9 @@ struct smbios_type_9 { > uint16_t slot_id; > uint8_t slot_characteristics_1; > uint8_t slot_characteristics_2; > + uint16_t sgn_base; > + uint8_t bus_number_base; > + uint8_t devfn_base; Where do the _base suffixes come from? Nothing like that is said in the spec I'm looking at. Also "sgn" is imo too much of an abbreviation. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:45:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:45:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106335.1457038 (Exim 4.92) (envelope-from ) id 1utQNp-0004gc-7I; Tue, 02 Sep 2025 12:45:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106335.1457038; Tue, 02 Sep 2025 12:45: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 1utQNp-0004gV-3U; Tue, 02 Sep 2025 12:45:09 +0000 Received: by outflank-mailman (input) for mailman id 1106335; Tue, 02 Sep 2025 12:45:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQNo-0004gP-9r for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:45:08 +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 a6b51d7b-87fa-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:45:05 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b0454d63802so99028566b.2 for ; Tue, 02 Sep 2025 05:45: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-b04148f95b5sm662861066b.92.2025.09.02.05.45.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:45: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: a6b51d7b-87fa-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756817105; x=1757421905; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Uh1NgFBcXHgsIaFoT607qr9if5WG3cVwJrTdYRtE4p0=; b=V0VKqhm2Lza77PTcntvTI9Oe3PcFthSiUZ9V4SjpgVhFUgTSe1NvLaKnC+N1TekPMB EJUsiF8+YPjGgO8R0n8zAW0QXbu54JQem5O8gooh6xWJX0rW0TWzp9DNBUw8TdpuqJNj rOAX7nTxFt+bCiCamLfgaV8cLckOtJl9MkJp0WlEfS/kFxjCzQDjgTWsLiG92lnrBQHf E5KzmHhDWAX4FRtXFNZdX1+dko+67kQ9bc+DIRzKwwdP926TN5YNA6fjD2X6djrfshk3 uccaH+MyB/41N0+/efvy4u4xHhti8TsAOtR1BfkJTlHK2HRgXiAsjD8oyIAYX1bM9Nqm C0tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756817105; x=1757421905; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uh1NgFBcXHgsIaFoT607qr9if5WG3cVwJrTdYRtE4p0=; b=qOq9PsxXF1XW7xgGmZT4tJNbbNEw9n9ZGAr2sudmEvVxi8ndxEpKwstNF1pfA1RIFX BZNKE6pMdJG0Vhsbs7HQuFEBuTkQ2D1KSNng9DbiQZws2jRfdJXwXdZ6D5ivZiuIiWdh efxW4a9dY7gX/n5V8Yckcl2eU+n/h2gwwvpP+vkrVeaE5htDrd24bwPP+CDgaV7deZgN 37LEp737X75esX+ukmnw9FTbSomWsl4+4tbCwyGaEAzrBQahx4BfjweCIrzNHN563upa dat9prCKJJ/66Z/N05I2Mq+88qQgb1S9yGZa0IUs8CkEmJOCBX7Me2pzgJH0lgZ5+RWs vorQ== X-Forwarded-Encrypted: i=1; AJvYcCV7pdwORTsQMbrLj5PTJuT/WHV/7GGtTYXMyCeNPRBYd16dwVI6GlI2TomTLaWvFkkqsCffmFsd62g=@lists.xenproject.org X-Gm-Message-State: AOJu0YwVNqr7H0hwtfILqBSc0fobEFNSSW0AQhFOApL4EisB+wOa60/l XOEg/YHkkwOG0LTjlHhMHK6gwdQdE/ym4Husmt/+hqxkUna0I/OESScO1Qsuid84RA== X-Gm-Gg: ASbGncsXJzrS3Tu7cTjSPZimsRSwjYvO4ymJYc35xlSp4YYDdrAtE0aSdCLaLrc2oP9 7xaAqsRNmm34UdcfWLD8tvzuz2qh3sGFtVDbcAvATYeiNYLUP0xBH/U6JYCQo6B1DWIt3g8tWGc cu2zXqRWEFbHj5IMyrExNLmfl6UfmGwfNy06kvKLUG5rgqnS1zoL6gxt1g38/jyZwH9aR8M52xf 8TM298a5je/WDC36nDLkknbtukQ1NW7XyGw1skZd1qe9m2zxRRW9yyFDLw2pKEBNzuuNpn+9ojs MgsHYgl5CJKL6oPo3oK5+fH7/4Zi2EBBiioEx20Qd/L1kzQjDMHpx8R7doQTqaOn6gv2F8BpcEp LKKkhFSpQRdKntJuuGRexE4l56SSYttyK+W7e0lx8CHpBh/c1EeuyrH/tlkomOFCHuuyZCCYQw3 mL9HhCzTI= X-Google-Smtp-Source: AGHT+IEwRGmu8MzwMpS31kxE+pVv/EFPchFh3/wMO2ZekSbvqv2rJB9bDSb1ORXCGZHyN/BBtefaDg== X-Received: by 2002:a17:907:724c:b0:afe:c1bd:b6d6 with SMTP id a640c23a62f3a-b01d8a327damr963924266b.5.1756817105168; Tue, 02 Sep 2025 05:45:05 -0700 (PDT) Message-ID: <7d0fc0eb-52a4-4478-8c1b-9a359513abdd@suse.com> Date: Tue, 2 Sep 2025 14:45:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@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.09.2025 14:28, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 02:22:29PM +0200, Juergen Gross wrote: >> On 02.09.25 12:56, Manuel Bouyer wrote: >>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>>>> Hello, >>>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>>>> The same NetBSD kernel works fine with Xen 4.18 >>>>> >>>>> The boot options are: >>>>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>>>> >>>>> and the full log from serial console is attached. >>>>> >>>>> With 4.20 the boot fails with: >>>>> >>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>>>> (XEN) Freed 664kB init memory >>>>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>>>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>>>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>>>> (XEN) CPU: 7 >>>>> (XEN) RIP: 0008:[<000000000020e268>] >>>>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>>>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>>>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>>>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>>>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>>>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>>>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>>>> >>>>> because of the triple fault the RIP above doens't point to the code. >>>>> >>>>> I tracked it down to this code: >>>>> cmpl $0,%ecx ; /* zero-sized? */ \ >>>>> je 2f ; \ >>>>> pushl %ebp ; \ >>>>> movl RELOC(nox_flag),%ebp ; \ >>>>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>>>> movl %eax,(%ebx) ; /* store phys addr */ \ >>>>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>>>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>>>> loop 1b ; \ >>>>> popl %ebp ; \ >>>>> 2: ; >>>>> >>>>> there are others pushl/popl before so I don't think that's the problem >>>>> (in fact the exact same fragment is called just before with different >>>>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>>>> which would be 0x20e260 >>>>> This is in the range: >>>>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>>>> so I can't see why this would be a problem. >>>>> >>>>> Any idea, including how to debug this further, welcome >>>> >>>> Even though triple fault's are aborts, they're generally accurate under >>>> virt, so 0x20e268 is most likely where things die. >>> >>> but that's the RIP of the last fault, not the first one, right ? >>> 0x20e268 isn't in the text segment of the kernel, my guess is that the >>> first fault triggers an exception, but the exeption handler isn't set up yet >>> so we end up jumping to some random value. >>> >> >> What puzzles me is that: >> >> - %cr2 is 0, so probably the first fault wasn't a page fault > > AFAIK it can't be as we're still in real mode It's protected mode, but with paging still off. >> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? >> >> Could it be the code has been moved to this location, or is about to >> be moved away afterwards? > > No. RIP shouldn't end up there in any way. the assembly code is quite simple, > it's just a loop and I'm quite confident that we did enter the loop with > sane values Yet Jürgen has a point - entry point and what is being modified are on the same page (and despite paging still being off, you writing page tables here makes pages a relevant unit). Considering - entry point @ 0x20e4d0 - %ecx = 0xdfeb7 - %ebx = 0x20e260 the loop continuing a little further will overwrite the entry point code. And with the entry point not at an even (e.g page-aligned) address, other code (like the one here) could conceivably live immediately ahead of it. (Of course this overwriting may be intentional, but it looks suspicious in this context.) Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:49:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:49:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106346.1457046 (Exim 4.92) (envelope-from ) id 1utQRl-0005HM-Lk; Tue, 02 Sep 2025 12:49:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106346.1457046; Tue, 02 Sep 2025 12: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 1utQRl-0005HF-J4; Tue, 02 Sep 2025 12:49:13 +0000 Received: by outflank-mailman (input) for mailman id 1106346; Tue, 02 Sep 2025 12:49: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 1utQRk-0005H9-NJ for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:49:12 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 388052ef-87fb-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:49:10 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582Cn8Ep021816 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 14:49:08 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582Cn8ZO006636; Tue, 2 Sep 2025 14:49:08 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 978D8107F7; Tue, 2 Sep 2025 14:49: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: 388052ef-87fb-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 14:49:06 +0200 From: Manuel Bouyer To: Juergen Gross Cc: Andrew Cooper , xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 14:49:08 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: > On 02.09.25 14:22, Juergen Gross wrote: > > On 02.09.25 12:56, Manuel Bouyer wrote: > > > On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: > > > > On 02/09/2025 11:17 am, Manuel Bouyer wrote: > > > > > Hello, > > > > > I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. > > > > > The same NetBSD kernel works fine with Xen 4.18 > > > > > > > > > > The boot options are: > > > > > menu=Boot netbsd-current PVH Xen420:dev hd0f:;load > > > > > /netbsd-PVH console=com0 root=wd0f; multiboot > > > > > /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 > > > > > loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 > > > > > sync_console=1 dom0=pvh > > > > > > > > > > and the full log from serial console is attached. > > > > > > > > > > With 4.20 the boot fails with: > > > > > > > > > > (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) > > > > > (XEN) Freed 664kB init memory > > > > > (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 > > > > > (XEN) *** Dumping Dom0 vcpu#0 state: *** > > > > > (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- > > > > > (XEN) CPU: 7 > > > > > (XEN) RIP: 0008:[<000000000020e268>] > > > > > (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) > > > > > (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 > > > > > (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 > > > > > (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 > > > > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > > > > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > > > > > (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 > > > > > (XEN) cr3: 0000000000000000 cr2: 0000000000000000 > > > > > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > > > > > (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 > > > > > > > > > > because of the triple fault the RIP above doens't point to the code. > > > > > > > > > > I tracked it down to this code: > > > > > cmpl $0,%ecx ; /* zero-sized? */ \ > > > > > je 2f ; \ > > > > > pushl %ebp ; \ > > > > > movl RELOC(nox_flag),%ebp ; \ > > > > > 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ > > > > > movl %eax,(%ebx) ; /* store phys addr */ \ > > > > > addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ > > > > > addl $PAGE_SIZE,%eax ; /* next phys page */ \ > > > > > loop 1b ; \ > > > > > popl %ebp ; \ > > > > > 2: ; > > > > > > > > > > there are others pushl/popl before so I don't think that's the problem > > > > > (in fact the exact same fragment is called just before with different > > > > > inputs and it doesn't fault). So the culprit it probably the write to (%ebx), > > > > > which would be 0x20e260 > > > > > This is in the range: > > > > > (XEN) [0000000000100000, 0000000040068e77] (usable) > > > > > so I can't see why this would be a problem. > > > > > > > > > > Any idea, including how to debug this further, welcome > > > > > > > > Even though triple fault's are aborts, they're generally accurate under > > > > virt, so 0x20e268 is most likely where things die. > > > > > > but that's the RIP of the last fault, not the first one, right ? > > > 0x20e268 isn't in the text segment of the kernel, my guess is that the > > > first fault triggers an exception, but the exeption handler isn't set up yet > > > so we end up jumping to some random value. > > > > > > > What puzzles me is that: > > > > - %cr2 is 0, so probably the first fault wasn't a page fault > > - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? > > > > Could it be the code has been moved to this location, or is about to > > be moved away afterwards? > > And indeed: from the full boot log I can see: > > (XEN) virt_base = 0x0 > (XEN) elf_paddr_offset = 0x0 > (XEN) virt_offset = 0x0 > (XEN) virt_kstart = 0x200000 > (XEN) virt_kend = 0x17bab90 > (XEN) virt_entry = 0x20e4d0 > > So virt_kentry is very near to the RIP. thanks, I missed this point and got my math off by 0x100000 it seems. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:52:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:52:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106361.1457056 (Exim 4.92) (envelope-from ) id 1utQUj-000718-6b; Tue, 02 Sep 2025 12:52:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106361.1457056; Tue, 02 Sep 2025 12: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 1utQUj-000711-3c; Tue, 02 Sep 2025 12:52:17 +0000 Received: by outflank-mailman (input) for mailman id 1106361; Tue, 02 Sep 2025 12:52: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 1utQUh-00070v-WF for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:52:16 +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 a5d956c1-87fb-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:52:13 +0200 (CEST) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-45b7c56a987so16896135e9.1 for ; Tue, 02 Sep 2025 05:52:13 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b8acbe982sm60528145e9.6.2025.09.02.05.52.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:52: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: a5d956c1-87fb-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756817533; x=1757422333; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cGTGCvRG/yf0r3dCuUwGQhwhW4jWI2QYZSIJ5mec4Gg=; b=rVOcC4ZAUl5JjkS/DS01q6kxfw3MEYCChX2KYSwcHYycwNUXgqvdM6Hwxykh5ev/ja p5dv4eCnamVdxcUNIcQ1IxWambe3hxgzamlf1op19U885U4CXdQFsRQYXK7BlKBXRw5d t8p5fis9V8ROzcF+0gA2hzYQu8QPsT4Y9IeKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756817533; x=1757422333; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cGTGCvRG/yf0r3dCuUwGQhwhW4jWI2QYZSIJ5mec4Gg=; b=wMDjc+YJhZivjZEOdSDAqc92R8QAXLRSQuDsvA/hxJJUdo+HyzJ0zBANDrvLSIaUNX fZ2jrYHa1X9/u4xBMC6Dj8ZiQnk8oIs9sV4zS3t+nbymYBKqw0YYPLFFR/35OfgQ0Yvx CmIISNwntYi+Z+s+aKfoL39v+30NC7vcwSYKkjowRzvdvHfINXRnbQ4267CrFlWDhF0v n1bBM285+61eoeJShkcUAnjLkb/f8H3R60AbLCoceWJS0dNVG/Jy0kipowNyxvJWfzyU MXOAwiAfiFyHok+6XRgw257KPjg2QBLh8XB6LLwLF9SF/rTfcpXikWOezV4WbWLL9y1v Lfgg== X-Gm-Message-State: AOJu0YzfZtWeP2EGxKxcn1sYWrf6nEo88XHQQVTafbisy8UkrxuC95DP MB/B1BiKejV/QFIyJ3nLZb4i7QgbiBjcUlJLWRaK01o7PLL3Vo842iZ4vt4XH2yQbWU= X-Gm-Gg: ASbGncuwkeoB96+7DWtQfNDomaLwyvcYGMtm3d/yg3+QbanKcYCcAUvpp0d2B2UbMRm Dy39P8p4vIRbr9Cy2xaCXIezI7kgoJBuwpmx17XM+Hs/cVU4aXgM1NQhwgNIDvTgQbQuEMgoGBm jxA219H+LBlh3WtIe8lv5GB7uasEcil/3XT1Qo7rmhzNJ/h6EFAKwY1p4kvE02P2VaRvVI/W7sV QGUfjlA3r8w3x5LunwkClIDXkU4fMZwt+6rvwRxe4ANX4rBph3OUL558Rmwyq8spC5mJ79tnz0Z NEAqdShBUv5tS+er5C/MFbMG1I6Rwt742xYUwI4qwWdQrtp7Kjq3TQJ5TTA9UxJjqJwmRwolROE uTiAroeKNFxHFdijAZUib8keAD4tMnZjwwNFqBBSaG6vzKN2bTOuffQWXDLPaQq0Sr49j7xCibh pjKM8= X-Google-Smtp-Source: AGHT+IF3qwYZ40MgITa/0zyOZCuF7BfbfcKMFlKrwU0XKBlUHFkO1kv1SKeAclDrtQIgEOx0737IbQ== X-Received: by 2002:a05:600c:1d1f:b0:45b:8f11:8e00 with SMTP id 5b1f17b1804b1-45c055e1774mr2928605e9.37.1756817532394; Tue, 02 Sep 2025 05:52:12 -0700 (PDT) Message-ID: <50994916-4307-4224-9e48-053459b00a92@citrix.com> Date: Tue, 2 Sep 2025 13:52:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <9a263568-54be-4193-9a4e-cd31268c5ee6@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/09/2025 1:24 pm, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 01:14:29PM +0100, Andrew Cooper wrote: >> On 02/09/2025 12:23 pm, Manuel Bouyer wrote: >>> On Tue, Sep 02, 2025 at 12:13:27PM +0100, Andrew Cooper wrote: >>>> On 02/09/2025 11:56 am, Manuel Bouyer wrote: >>>>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >>>>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>>>>>> Hello, >>>>>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>>>>>> The same NetBSD kernel works fine with Xen 4.18 >>>>>>> >>>>>>> The boot options are: >>>>>>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>>>>>> >>>>>>> and the full log from serial console is attached. >>>>>>> >>>>>>> With 4.20 the boot fails with: >>>>>>> >>>>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>>>>>> (XEN) Freed 664kB init memory >>>>>>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>>>>>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>>>>>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>>>>>> (XEN) CPU: 7 >>>>>>> (XEN) RIP: 0008:[<000000000020e268>] >>>>>>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>>>>>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>>>>>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>>>>>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>>>>>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>>>>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>>>>>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>>>>>> >>>>>>> because of the triple fault the RIP above doens't point to the code. >>>>>>> >>>>>>> I tracked it down to this code: >>>>>>> cmpl $0,%ecx ; /* zero-sized? */ \ >>>>>>> je 2f ; \ >>>>>>> pushl %ebp ; \ >>>>>>> movl RELOC(nox_flag),%ebp ; \ >>>>>>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>>>>>> movl %eax,(%ebx) ; /* store phys addr */ \ >>>>>>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>>>>>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>>>>>> loop 1b ; \ >>>>>>> popl %ebp ; \ >>>>>>> 2: ; >>>>>>> >>>>>>> there are others pushl/popl before so I don't think that's the problem >>>>>>> (in fact the exact same fragment is called just before with different >>>>>>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>>>>>> which would be 0x20e260 >>>>>>> This is in the range: >>>>>>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>>>>>> so I can't see why this would be a problem. >>>>>>> >>>>>>> Any idea, including how to debug this further, welcome >>>>>> Even though triple fault's are aborts, they're generally accurate under >>>>>> virt, so 0x20e268 is most likely where things die. >>>>> but that's the RIP of the last fault, not the first one, right ? >>>>> 0x20e268 isn't in the text segment of the kernel, my guess is that the >>>>> first fault triggers an exception, but the exeption handler isn't set up yet >>>>> so we end up jumping to some random value. >>>> Double and Triple faults occur when trying to deliver an exception >>>> generates an exception.  So while multiple faults are involved, only one >>>> instruction typically is. >>>> >>>> Is this an Intel or an AMD system?  One thing virt can do is break apart >>>> a triple fault, but the logic to do so is vendor specific. >>> it's an old intel system: >>> cpu0: "Intel(R) Xeon(R) CPU X5650 @ 2.67GHz" >>> cpu0: Intel Xeon 36xx & 56xx, i7, i5 and i3 (686-class), 2667.30 MHz >>> cpu0: family 0x6 model 0x2c stepping 0x2 (id 0x206c2) >>> >> Hmm.  Westmere EP.  Are you running with EPT active, or with Shadow Paging? > How do I know ? Something like: HVM: Hardware Assisted Paging (HAP) detected on boot. > Note that the same problem shows up on much newer systems: an i9, and a > Xeon W-2223. Both boots fine with the same NetBSD kernel and Xen 4.18 or 4.15. > > I'm using this old Xeon for debug because this one has a serial console. Sure.  It's just that HAP vs Shadow is also relevant to breaking apart a triple fault. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:54:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:54:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106372.1457067 (Exim 4.92) (envelope-from ) id 1utQWg-0007YW-IM; Tue, 02 Sep 2025 12:54:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106372.1457067; Tue, 02 Sep 2025 12:54:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQWg-0007YP-Ep; Tue, 02 Sep 2025 12:54:18 +0000 Received: by outflank-mailman (input) for mailman id 1106372; Tue, 02 Sep 2025 12:54: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 1utQWf-0007YC-OW for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:54:17 +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 ef1650bd-87fb-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 14:54:16 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-b042cc39551so297910666b.0 for ; Tue, 02 Sep 2025 05:54: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-b04189de5b5sm637834166b.10.2025.09.02.05.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:54:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ef1650bd-87fb-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756817656; x=1757422456; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FBpFRyVjoau3Kw2UF9dSgF1MxEK2RGEvMrrnNFGzYhU=; b=K4xp8XuRevip0++WB4jomUuoGBtAieiZvXChyQMIfbMEr0fuqV+BBoUcICRU4j1Fz7 KCP0xoCgPOm5aqfgmCHayxgu8/cieRsdNScYOcfQhsxbUq04pw2l9vJoc6P/w8ZQ/iuL z2VFz9jGBUxX7GUWTvXzoOJB8jHEbTkih4zZcESeWOuBAJnSDqL1WFg9N/Ek+vZqd1+f RzX1+GZ4L+tv7+psmDNrg0xDMWvyC+8WvkcYlA1v2SGT2S4KqniYFsbe/e4MtMAWEfWj eg83GFBac/Fd4/CDQ1d17nIygL6p85M56AwMgn8gUS0+n58fqoVVMWeu5EN4E5aWrcOg nqWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756817656; x=1757422456; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FBpFRyVjoau3Kw2UF9dSgF1MxEK2RGEvMrrnNFGzYhU=; b=pTpVupF8ZJdNg0MhaEDrrPml7L8ByKn3eXnrO2BNX6kpntm5O+zMGlZx4+ir5q8HHU KSXO94uaDy9ussKP7LzZMJe5bBQOmL6LZrZrPMM192OJ23Y8UI9rdYo2b8I8vWb3Fypx 3C9LJbPZoLyl7b7cmwEfN+VFlfJV3fyVpVX/61Z9jr2DNFIlpqTgpr4AjNLNqd16XNWr 09/tciLW9DB+EckQ/x+2YdXA9IADNNyTx4YgmsolnFjK6MnB30MEnORX+gsO4xHwMe88 lFapduqn5ceW9+u+FVZ4S3pNUyLQtzkaQb1q9LlLay6/RCWk5GsJPpGHIYRXbnDuwOLI ZsWQ== X-Gm-Message-State: AOJu0Yy3ywcIMuSXW1wcp8HfsAfwDYtpXT7GqFQUU3Jf4vflWFpAxYSn V2kyBtKLXvl0lpZ6VhsYnAX8ve9YeLZuNlUT1tlTzAOTPAGT/DwqbjwQxGePIMN5IA== X-Gm-Gg: ASbGncsCncUELEV7j6Hm0mt3xfJBChkTDlg357t/KNDxHXCpnhorovQ0Ey3elkXx8IG 5C7H38JZy9rzZDQHVGyt59bZk2i9g68M7cXpSM6ET4eTydHcSVLOjB8xw/qmXUXE3efLhQEVNCj JLBIljVkMmmgnJjE8QN/3sQyEASieXSxg9Q2SPQRJ+eL5q1deFejWIJHvLxEYYx8f4yMe9KSyLi yj/268TU7R23rUWtRf6zMf5fLagS9BsOZQMQeb+LZ8EX6czwNMyVmJnnHkOQ+U0HeF4AWppKyUX b96HWh3N2WNAV9GxUQHdlZDl0kKFXd1xfONQUPgqyPpVI6Z4TCyml1kXwOrmzhgoCwR65XUgf9y YZ4jOByYEpJxmFtxxHMiP6I/++jQhzrp0CWNDs1REi+m11SiAVf17GyXFQPS6b3fWx3/lyfgXRr +geQ5nA9iTosb3MpQyRg== X-Google-Smtp-Source: AGHT+IFBJKJz/+j3DKyAjspzHHjTCAc/LVaxMHtUfyZpagPm5fuUb1CX0uz6torfHTyusEZc9MmBnw== X-Received: by 2002:a17:907:1c97:b0:ade:198c:4b6f with SMTP id a640c23a62f3a-b01d8a277e7mr1140143466b.1.1756817656079; Tue, 02 Sep 2025 05:54:16 -0700 (PDT) Message-ID: <4d1beced-02a5-4cd3-bfe2-1a7c3220a85f@suse.com> Date: Tue, 2 Sep 2025 14:54:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: xen-devel@lists.xenproject.org, Andrew Cooper References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <79612dd8-2d12-4f69-9371-8a788db3873f@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.09.2025 14:10, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 02:00:35PM +0200, Jan Beulich wrote: >> On 02.09.2025 12:56, Manuel Bouyer wrote: >>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>>>> Hello, >>>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>>>> The same NetBSD kernel works fine with Xen 4.18 >>>>> >>>>> The boot options are: >>>>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>>>> >>>>> and the full log from serial console is attached. >>>>> >>>>> With 4.20 the boot fails with: >>>>> >>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>>>> (XEN) Freed 664kB init memory >>>>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>>>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>>>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>>>> (XEN) CPU: 7 >>>>> (XEN) RIP: 0008:[<000000000020e268>] >>>>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>>>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>>>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>>>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>>>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>>>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>>>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>>>> >>>>> because of the triple fault the RIP above doens't point to the code. >>>>> >>>>> I tracked it down to this code: >>>>> cmpl $0,%ecx ; /* zero-sized? */ \ >>>>> je 2f ; \ >>>>> pushl %ebp ; \ >>>>> movl RELOC(nox_flag),%ebp ; \ >>>>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>>>> movl %eax,(%ebx) ; /* store phys addr */ \ >>>>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>>>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>>>> loop 1b ; \ >>>>> popl %ebp ; \ >>>>> 2: ; >>>>> >>>>> there are others pushl/popl before so I don't think that's the problem >>>>> (in fact the exact same fragment is called just before with different >>>>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>>>> which would be 0x20e260 >>>>> This is in the range: >>>>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>>>> so I can't see why this would be a problem. >>>>> >>>>> Any idea, including how to debug this further, welcome >>>> >>>> Even though triple fault's are aborts, they're generally accurate under >>>> virt, so 0x20e268 is most likely where things die. >>> >>> but that's the RIP of the last fault, not the first one, right ? >>> 0x20e268 isn't in the text segment of the kernel, my guess is that the >>> first fault triggers an exception, but the exeption handler isn't set up yet >>> so we end up jumping to some random value. >> >> Can you perhaps check this guess against the %esp value seen? From the >> hypervisor's triple fault handling, you may want to actually log stack >> contents as well (in addition to what Andrew suggested), assuming %esp >> looks sane to you. > > %esp is sane. I forgot to mention, this happens very early, while we're still > in 32bits real mode. No function call did happen at this point, and on the > stack there's only one 32bit value: the %ebp that we just pushed Which by implication means no earlier exception(s). Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:54:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:54:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106378.1457077 (Exim 4.92) (envelope-from ) id 1utQXB-0007yU-Pd; Tue, 02 Sep 2025 12:54:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106378.1457077; Tue, 02 Sep 2025 12:54: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 1utQXB-0007yN-M2; Tue, 02 Sep 2025 12:54:49 +0000 Received: by outflank-mailman (input) for mailman id 1106378; Tue, 02 Sep 2025 12:54: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 1utQXA-0007yD-TQ for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:54:48 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 018e2ef1-87fc-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 14:54:47 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582CsjNn012955 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 14:54:46 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582CsjZU008739; Tue, 2 Sep 2025 14:54:45 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 2D703107F7; Tue, 2 Sep 2025 14:54:44 +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: 018e2ef1-87fc-11f0-8adc-4578a1afcccb Date: Tue, 2 Sep 2025 14:54:44 +0200 From: Manuel Bouyer To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <7d0fc0eb-52a4-4478-8c1b-9a359513abdd@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7d0fc0eb-52a4-4478-8c1b-9a359513abdd@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 14:54:46 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 02:45:04PM +0200, Jan Beulich wrote: > >> What puzzles me is that: > >> > >> - %cr2 is 0, so probably the first fault wasn't a page fault > > > > AFAIK it can't be as we're still in real mode > > It's protected mode, but with paging still off. > > >> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? > >> > >> Could it be the code has been moved to this location, or is about to > >> be moved away afterwards? > > > > No. RIP shouldn't end up there in any way. the assembly code is quite simple, > > it's just a loop and I'm quite confident that we did enter the loop with > > sane values > > Yet Jrgen has a point - entry point and what is being modified are on the > same page (and despite paging still being off, you writing page tables here > makes pages a relevant unit). Considering > - entry point @ 0x20e4d0 > - %ecx = 0xdfeb7 > - %ebx = 0x20e260 > the loop continuing a little further will overwrite the entry point code. > And with the entry point not at an even (e.g page-aligned) address, other > code (like the one here) could conceivably live immediately ahead of it. > (Of course this overwriting may be intentional, but it looks suspicious in > this context.) Indeed. Now the exact same kernel is booting fine with Xen 4.18 (and also the same bootstrap is used for domU PVH which works with Xen 4.20). I guess something changed in the way Xen sets up the dom0 kernel. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:55:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:55:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106392.1457087 (Exim 4.92) (envelope-from ) id 1utQXh-0008Vi-14; Tue, 02 Sep 2025 12:55:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106392.1457087; Tue, 02 Sep 2025 12:55:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQXg-0008Vb-U3; Tue, 02 Sep 2025 12:55:20 +0000 Received: by outflank-mailman (input) for mailman id 1106392; Tue, 02 Sep 2025 12:55: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 1utQXf-0007yD-HS for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:55:19 +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 14354c80-87fc-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 14:55:19 +0200 (CEST) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-45b7ebe667cso34688145e9.3 for ; Tue, 02 Sep 2025 05:55:19 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7d9548edsm124127245e9.5.2025.09.02.05.55.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:55: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: 14354c80-87fc-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756817718; x=1757422518; 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=COPAyaOpb3K+mqHUgb9Evl0z1JDg0PfVd9ibeBwwfCk=; b=uJg2Iu6FOOFfvf445YmQSzV1XELNx0ITosIsTYfzrVD/DkyahTnpegjuq+N+/Xn5AF mPjfc8DVMP0i3hoYyWAuGeoBdDqVb9FQQCR2VB3NZy9lwBdEWHjh0Foxjpdo8RJPYFq4 ZKIFNNP2zIA1tspFduWIi3PzZrqncu3xSyrQE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756817718; x=1757422518; 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=COPAyaOpb3K+mqHUgb9Evl0z1JDg0PfVd9ibeBwwfCk=; b=G+dDVkKKVAT9dtjWPMCVxxCVr7xNcAj4q/60x5aJWzMEkWUB7lGK8RWWNsnAa4PxUj bLeqBEG1sDV0Q5LIu0iKFfWJCTVqYM+0gCf1HRjODRwB4yAJnrxuXQn2IGuCt/o3j5eN BkEPecNGyDObBKGhpEPwtsaKyEIGm5O+EEeZrED9jGsfIvk2BZE44ErWxPKcyEDRYH+a eLLc890Y2z9JjvW14mlDwrsW8617uPi66DTnXpP6XGjYggA/k7Mgk/gUXvxDc48FHuI4 tf6mj34fYhAXiEP9cpIMYebntK+cYnwVG78YjvWpNTmMxz4a7Dh8UTKiVccGnxibV2RO DWZQ== X-Gm-Message-State: AOJu0YwWw6yNSqrVXbJRZWtGYV33Mlrnee7Q9AKmzANDgzH3QaCLIKYZ WhAJCHbaPfQ88FT755L9ByvDunoYsZ+QVolqESpBf6HrDCNPXOmblcOOSDfGhYkEyvJmtlwLAO0 Deejd X-Gm-Gg: ASbGncv1Md/3Eh3HlOG0OXv/6x+oXIe/KwsXUt/YG+525eAR+U175iUovoT/TSvEJyM jYa+c3kWSXY0M2mFZ7t0OjPGd9GbQyVsL3S3RiBrwHBod05kfAOIDItdsQg2mKKTb8pwXnRJYWY vDBwIer4I9HBOjfWWgGEHZYAgLasH3GRd9QZr9eYr8iEoyKaLaV42rfE1DFSydNxBEKyK+Ffwab gegddxeRieI1Q+7D7Seh/HTIh+gD4TWuWq2dNmOy6FsC4O1P4YBbZxaTbmIM/FyZmpR2rY6crSW 2t5eiJq5LAd4a9sBg2/i16HnSlNaczSQbigYb5O5u5vZ63f/4UY9CZr9kuTAB+tGaIeHYtFfCCA dMKl48h7NZH4MK8dsDR8hKSiDMiZvFaRF0FS+PcZYXIZSZtFlSrfcL9EpFMt/AdetE+3IhY4jpv hPR7E= X-Google-Smtp-Source: AGHT+IFp3zMzDsCc5TCwAKvfdBOn/z+FI3V7B7mIa/OmiXQ0iJ2rTQvUTnslkwgdT7izTkv2Q7qjEw== X-Received: by 2002:a05:600c:524d:b0:45b:8a10:e5a6 with SMTP id 5b1f17b1804b1-45b8a10e833mr81102455e9.15.1756817718288; Tue, 02 Sep 2025 05:55:18 -0700 (PDT) Message-ID: <3462df8b-4212-47c4-b569-2a94be5f3a44@citrix.com> Date: Tue, 2 Sep 2025 13:55:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 From: Andrew Cooper To: Manuel Bouyer Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <9a263568-54be-4193-9a4e-cd31268c5ee6@citrix.com> <50994916-4307-4224-9e48-053459b00a92@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: <50994916-4307-4224-9e48-053459b00a92@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/09/2025 1:52 pm, Andrew Cooper wrote: > On 02/09/2025 1:24 pm, Manuel Bouyer wrote: >> On Tue, Sep 02, 2025 at 01:14:29PM +0100, Andrew Cooper wrote: >>> On 02/09/2025 12:23 pm, Manuel Bouyer wrote: >>>> On Tue, Sep 02, 2025 at 12:13:27PM +0100, Andrew Cooper wrote: >>>>> On 02/09/2025 11:56 am, Manuel Bouyer wrote: >>>>>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote: >>>>>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote: >>>>>>>> Hello, >>>>>>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20. >>>>>>>> The same NetBSD kernel works fine with Xen 4.18 >>>>>>>> >>>>>>>> The boot options are: >>>>>>>> menu=Boot netbsd-current PVH Xen420:dev hd0f:;load /netbsd-PVH console=com0 root=wd0f; multiboot /xen420-debug.gz dom0_mem=1024M console=com1 com1=38400,8n1 loglvl=all guest_loglvl=all gnttab_max_nr_frames=64 sync_console=1 dom0=pvh >>>>>>>> >>>>>>>> and the full log from serial console is attached. >>>>>>>> >>>>>>>> With 4.20 the boot fails with: >>>>>>>> >>>>>>>> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) >>>>>>>> (XEN) Freed 664kB init memory >>>>>>>> (XEN) d0v0 Triple fault - invoking HVM shutdown action 1 >>>>>>>> (XEN) *** Dumping Dom0 vcpu#0 state: *** >>>>>>>> (XEN) ----[ Xen-4.20.2-pre_20250821nb0 x86_64 debug=y Tainted: C ]---- >>>>>>>> (XEN) CPU: 7 >>>>>>>> (XEN) RIP: 0008:[<000000000020e268>] >>>>>>>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hvm guest (d0v0) >>>>>>>> (XEN) rax: 000000002024c003 rbx: 000000000020e260 rcx: 00000000000dfeb7 >>>>>>>> (XEN) rdx: 0000000000100000 rsi: 0000000000103000 rdi: 000000000013e000 >>>>>>>> (XEN) rbp: 0000000080000000 rsp: 00000000014002e4 r8: 0000000000000000 >>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 >>>>>>>> (XEN) cr3: 0000000000000000 cr2: 0000000000000000 >>>>>>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>>>>>>> (XEN) ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008 >>>>>>>> >>>>>>>> because of the triple fault the RIP above doens't point to the code. >>>>>>>> >>>>>>>> I tracked it down to this code: >>>>>>>> cmpl $0,%ecx ; /* zero-sized? */ \ >>>>>>>> je 2f ; \ >>>>>>>> pushl %ebp ; \ >>>>>>>> movl RELOC(nox_flag),%ebp ; \ >>>>>>>> 1: movl %ebp,(PDE_SIZE-4)(%ebx) ; /* upper 32 bits: NX */ \ >>>>>>>> movl %eax,(%ebx) ; /* store phys addr */ \ >>>>>>>> addl $PDE_SIZE,%ebx ; /* next PTE/PDE */ \ >>>>>>>> addl $PAGE_SIZE,%eax ; /* next phys page */ \ >>>>>>>> loop 1b ; \ >>>>>>>> popl %ebp ; \ >>>>>>>> 2: ; >>>>>>>> >>>>>>>> there are others pushl/popl before so I don't think that's the problem >>>>>>>> (in fact the exact same fragment is called just before with different >>>>>>>> inputs and it doesn't fault). So the culprit it probably the write to (%ebx), >>>>>>>> which would be 0x20e260 >>>>>>>> This is in the range: >>>>>>>> (XEN) [0000000000100000, 0000000040068e77] (usable) >>>>>>>> so I can't see why this would be a problem. >>>>>>>> >>>>>>>> Any idea, including how to debug this further, welcome >>>>>>> Even though triple fault's are aborts, they're generally accurate under >>>>>>> virt, so 0x20e268 is most likely where things die. >>>>>> but that's the RIP of the last fault, not the first one, right ? >>>>>> 0x20e268 isn't in the text segment of the kernel, my guess is that the >>>>>> first fault triggers an exception, but the exeption handler isn't set up yet >>>>>> so we end up jumping to some random value. >>>>> Double and Triple faults occur when trying to deliver an exception >>>>> generates an exception.  So while multiple faults are involved, only one >>>>> instruction typically is. >>>>> >>>>> Is this an Intel or an AMD system?  One thing virt can do is break apart >>>>> a triple fault, but the logic to do so is vendor specific. >>>> it's an old intel system: >>>> cpu0: "Intel(R) Xeon(R) CPU X5650 @ 2.67GHz" >>>> cpu0: Intel Xeon 36xx & 56xx, i7, i5 and i3 (686-class), 2667.30 MHz >>>> cpu0: family 0x6 model 0x2c stepping 0x2 (id 0x206c2) >>>> >>> Hmm.  Westmere EP.  Are you running with EPT active, or with Shadow Paging? >> How do I know ? > Something like: > > HVM: Hardware Assisted Paging (HAP) detected > > on boot. Sorry - i missed the log on the root of the conversation.  You do have HAP on this system. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:56:29 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:56:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106408.1457097 (Exim 4.92) (envelope-from ) id 1utQYm-0000hh-Ck; Tue, 02 Sep 2025 12:56:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106408.1457097; Tue, 02 Sep 2025 12: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 1utQYm-0000ha-9W; Tue, 02 Sep 2025 12:56:28 +0000 Received: by outflank-mailman (input) for mailman id 1106408; Tue, 02 Sep 2025 12:56: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 1utQYl-0000hN-4j for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:56:27 +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 3b7ce92c-87fc-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:56:25 +0200 (CEST) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-61a8c134533so9660449a12.3 for ; Tue, 02 Sep 2025 05:56: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 4fb4d7f45d1cf-61cfc4bbcc7sm9390400a12.24.2025.09.02.05.56.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 05:56: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: 3b7ce92c-87fc-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756817784; x=1757422584; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cxEmf8jKtqP9DgLcpkszv1taQDwhXj+TB4X+KX4NdnU=; b=KiF0COKoduhEMf1zSi8a9EMNhmmMGs8lf7AWJMlgbObJ5rDQv6bNfczJqzJEKxSF7q 22aauSDFeWvFpmUGkWS+mFINXduvys9S8sqjikX60AMsk/J88i5KMoQS3ecqkikbcl3u VRG6U+L6jAnS2FO0yxvS9tuLiZXWGQHu3tEA1h8RCqPqB2cx/tkDfsLD9VnOcng2PH8D qIPUtrtiQap/hzEuvpGqjck5LaXpYby6joAypLT5kJ/u3f/NZvYKxuTx4+0R0E7p7LRt YzaIFdw8wW/4Q3jQ0jL+XLIJyMBRiWVWintk88pgfs02VxZae+dRbgD7jnVbbankY+nX XK8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756817784; x=1757422584; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cxEmf8jKtqP9DgLcpkszv1taQDwhXj+TB4X+KX4NdnU=; b=ruO8Eq/qjtJJd4S6NriDbG7Q4qiZRIdHx2cv8A5PvsanZ/yT7JY6niOcaAG6F+3t/i iHZl0elOp+c9CLxTUdbJAIzWIWC6IREmaq6854G7LLKZiuKFFTCXAk/WA8n7DNgMy7xV Mp0vn97+JPz1bPgM+PVzuMrZJJgx77BjzOUqA2sor5oJTTfP/yTDrbP+dA80GoVgacan bOz8LYlekfgT/i6cmlWcRXfvNz5nHH51vJcHo4m7cmlMLVyBDN+xezV/SLyp9hk5gKgs 4j05g7gMtv5s/Ew5vqRWQym9mOh6NdaPG52VGm24i8YG7tpcWXnxQpRhfTxJhp0ppVLO jZ7w== X-Forwarded-Encrypted: i=1; AJvYcCXHr8z8I+340BBkUyMjp02FpGX5vDzx2O3EeXq7L7os7gtGagabMa2kBh9Vd6LdEVvfqVlwlRfNIeI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy4m8KJbRltcz+iRT9+iareEnTe1KskWzZ5WHwHwFgx/jgtF0lu BfCpWjmgv16KfwYoLUs4hhFePDH6avFg4H6O5WHCTpUn+i+srxYyJFgYfQLRCYKRKA== X-Gm-Gg: ASbGncv1/0nK3dzeMg5NoeUqNSo6J7AYNLrfQO+uGAuJhDDMkGzaMm6VDEOiMTneCYz hhfaXf6lKvGrsUp3uYWkK/uDCJu2PuYfBSpOAvbfvPXnyCdcJk/X8nfk9DdrpUKuSAKRv/qqp1F k6cI4Q3hztRhE9AKxlasOEh2qUUmbgiIqFvha11mTSuSsA7TLNtVev3jbrXkBAgdUwg4/DExLSN I+Xy79j9E/Zki/KhMN9YRgVeRCkB0YbF5xXhgo9767+mDFbUBdAx6X8TLKEtkmhoxLtJqV5QdJT djcXTuv3xXoUSCI69I7rqsLBJw7rXQPvxq2hTKjzpM/fEtICnXZpXaExhG1W4smFfkpKSXJo8eO +t5w8yqVdy9sXiWen3DjetVoVDyFAKLhGrPjisq3uF3aF+eysEm9vivStCy0hmVDCQ8jDA0tNyf 1NnVOLkUg= X-Google-Smtp-Source: AGHT+IEly4ATefmI7CxtKeh7/EbG28xcd3d0OaZ3FKNqBVqTgJqrdgOi232tbMO2kOSEZnLwF05zTw== X-Received: by 2002:a05:6402:40ce:b0:61c:c086:8092 with SMTP id 4fb4d7f45d1cf-61d26fd0c7emr11599428a12.23.1756817784349; Tue, 02 Sep 2025 05:56:24 -0700 (PDT) Message-ID: <8a1fa32f-e7fb-4879-8516-1ddca5367619@suse.com> Date: Tue, 2 Sep 2025 14:56:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <7d0fc0eb-52a4-4478-8c1b-9a359513abdd@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.09.2025 14:54, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 02:45:04PM +0200, Jan Beulich wrote: >>>> What puzzles me is that: >>>> >>>> - %cr2 is 0, so probably the first fault wasn't a page fault >>> >>> AFAIK it can't be as we're still in real mode >> >> It's protected mode, but with paging still off. >> >>>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? >>>> >>>> Could it be the code has been moved to this location, or is about to >>>> be moved away afterwards? >>> >>> No. RIP shouldn't end up there in any way. the assembly code is quite simple, >>> it's just a loop and I'm quite confident that we did enter the loop with >>> sane values >> >> Yet Jürgen has a point - entry point and what is being modified are on the >> same page (and despite paging still being off, you writing page tables here >> makes pages a relevant unit). Considering >> - entry point @ 0x20e4d0 >> - %ecx = 0xdfeb7 >> - %ebx = 0x20e260 >> the loop continuing a little further will overwrite the entry point code. >> And with the entry point not at an even (e.g page-aligned) address, other >> code (like the one here) could conceivably live immediately ahead of it. >> (Of course this overwriting may be intentional, but it looks suspicious in >> this context.) > > Indeed. Now the exact same kernel is booting fine with Xen 4.18 (and also > the same bootstrap is used for domU PVH which works with Xen 4.20). > I guess something changed in the way Xen sets up the dom0 kernel. Hence why Andrew asked for full logs of both boots, to put side by side. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 12:56:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 12:56:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106410.1457108 (Exim 4.92) (envelope-from ) id 1utQYy-000149-Mb; Tue, 02 Sep 2025 12:56:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106410.1457108; Tue, 02 Sep 2025 12:56:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQYy-000140-HU; Tue, 02 Sep 2025 12:56:40 +0000 Received: by outflank-mailman (input) for mailman id 1106410; Tue, 02 Sep 2025 12:56: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 1utQYw-0000hN-Ly for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 12:56:38 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 42add78f-87fc-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 14:56:37 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582CuZhP016800 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 14:56:35 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582CuZgu004018; Tue, 2 Sep 2025 14:56:35 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 182A6107F7; Tue, 2 Sep 2025 14:56: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: 42add78f-87fc-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 14:56:34 +0200 From: Manuel Bouyer To: Andrew Cooper Cc: xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <9a263568-54be-4193-9a4e-cd31268c5ee6@citrix.com> <50994916-4307-4224-9e48-053459b00a92@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50994916-4307-4224-9e48-053459b00a92@citrix.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 14:56:35 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 01:52:11PM +0100, Andrew Cooper wrote: > HVM: Hardware Assisted Paging (HAP) detected > on boot. So it is: (XEN) HVM: ASIDs enabled. (XEN) VMX: Disabling executable EPT superpages due to CVE-2018-12207 (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB but the RIP printed by Xen may be right, after all -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:05:23 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:05:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106437.1457116 (Exim 4.92) (envelope-from ) id 1utQhK-00039F-Ct; Tue, 02 Sep 2025 13:05:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106437.1457116; Tue, 02 Sep 2025 13:05: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 1utQhK-000398-AJ; Tue, 02 Sep 2025 13:05:18 +0000 Received: by outflank-mailman (input) for mailman id 1106437; Tue, 02 Sep 2025 13:05: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 1utQhI-000392-9M for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:05:16 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 777a4921-87fd-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 15:05:15 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582D5DWb013421 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 15:05:13 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582D5C6d019758; Tue, 2 Sep 2025 15:05:12 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 78D8B107F7; Tue, 2 Sep 2025 15:05: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: 777a4921-87fd-11f0-8adc-4578a1afcccb Date: Tue, 2 Sep 2025 15:05:11 +0200 From: Manuel Bouyer To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <7d0fc0eb-52a4-4478-8c1b-9a359513abdd@suse.com> <8a1fa32f-e7fb-4879-8516-1ddca5367619@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CY04cZXxvSYdQTAg" Content-Disposition: inline In-Reply-To: <8a1fa32f-e7fb-4879-8516-1ddca5367619@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 15:05:13 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 --CY04cZXxvSYdQTAg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 02, 2025 at 02:56:23PM +0200, Jan Beulich wrote: > Hence why Andrew asked for full logs of both boots, to put side by side. Sorry I missed this. Here's both log. 4.20 may be different from the one I posted earlier; I did another boot to make sure it's the exact same kernel for both logs. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- --CY04cZXxvSYdQTAg Content-Type: application/octet-stream Content-Disposition: attachment; filename="4.18.log.gz" Content-Transfer-Encoding: base64 H4sICC/rtmgAAzQuMTgubG9nAO0923LbOpLv+xWYOg9jn/GFoKjrVLZWluVEO5GtYyk52Uql WBQJShxTpMKLYs/Xb3eDpEhdSdnJ7MO6Etki0Bc0Go3uBgiwL8Jj2hVvXSm6qqg1znnDmyr/ cfalf3/OsHAlgtDxd1ViZ1M/fhHBf52zs5lpsjNvqjIsV5pcOWdcuapfwW9LTOPZuxc2iQW7 91dM5YzzjlLrcM6G/QlBJPQ+GpEII9abG95MjEXUYUnBNHZc69KxOkxrNFtTW7FtDngNpWFM FdNqWK16jdu2VTPMVkupi6adAPZ8L/Rdwfw4WsYRc0IWvnjmPPA9Pw6vkko3vh+5vmGJoMPu RXQzvr1+bjXYzeBhTGUX7FGsHJJC/Qq4PvtTWGxoBIypTGl2tFZHVdinSQ+booIw7MBfJIhY +6oN/2rnGT+LheFZzHU80WGWv1D0hVi844qqDZkpmX1n+gvO8ONdraUpykXL48z1Z+7KfWe4 LpvFICQ9/8CLImOqL4xn3Qt0OzAWInzX0KipeoqUE7V3y9U817nOwpgJhm1nUyMUzLCsQIRh h6Ua8NmxhM8cz/aDhRGBBDpJAfv8vovijMRzxBa+JVhLeVbrF8z2vYi1nnkjq3jTv7697bGF iOa+Bbg93xN/Z/3bwS2LAsMLbRGwyFmAPBQWCuDXClNYqoTUAShigYgCR6xA+FNhGjHw6/kM UScFhpsQAZ2LhBkJK8Fz64Tmzkbc+TF0BujhzSMLnZlnRDG0f7O0f3ubh2ZhFMRmvmZv9Il9 Fp7lgwINvEi4F+zOWDjuC2uwM+W5cX7BhiAil2kafldNeDCOxHLpeDPQobPA+MEURVGVhqme r7vnUrRAsR67Q7YwlhnPX5WNnwuW+9JuTm37GzuLQ2PqivNdQO2muQlk2wQELRIByHcnmNii ZZcA4xssTu1mMwHbxyJUaYlNoJYEil6WgrV3gbS36LQtSafbGw2YZUTGTlLtLVKmnYO7/zze CWZtkbOOSgMqCXMDzD4uRJH8XoOJMmC2EBtg9OQomG1ugpWgxtPKGVijtgYr9vS9+JEzPht2 5xmMO/0klbETOuxxfDtCxHfd3i2RUGEgBSqVdofnhbpfxrcTdnMHCsElO60e1OVsPOwNWO5H VThXWkqNDcd3k+RZu1nEBfRGEpfaJlx3SLfGEA4mAizmdaVeCtdtxlejC7ga9UaN+IKJsqEo 8hN+UvYUNriffATMSh3m222+xoSrn4hcK8qrOxr0JK0a8c15n2glfGNxab6Hvbv3Epd2Q7Rq vTyuh/6QapTCNf44SGSg3UlcygYuqlEKF1S+SWSgyX6ub+C6Kd3G8WNX8tWlvlF4e4svrJH+ cNk36bcirg+jfoKrVZNtbG3gohrldGbYfUzaSHrPE3nBT3cI2gzIqErG16E2JvrX5bU+4qol +ne7nI0WC4ToLePRIkWlHtK//uD+v5M2Ngt8AVf9R/zUqUqZNt70HxN5dZW8TuRwUZUyuPqP 4xQXyZ7fbPOFVcrg+tBPcd2QvJRuq4DrpqdTlcO4xi9hJBY4iXeYqtUbTVDaM7XO4S9FebrJ bOKnYRecT/SjFDb6MoTPI/M8mdZS0NtTcGKYj0Nvm/VabT80J2ieQde0/ZNCAfpTiI4Qb4Hz CK7gXLC5Ec5ZOHfsKPXg/IXheGwujCW4Yk7kGK4TgiMI2s9+OFY0ZzWVTZ0o9chsct3GwxEb ji4jnH2YETGazJqt1FbewhBa4pTmRWkoIDkh82kFDsQ+4EraRuxGBdUYDS8n4LAGbPDARn4Q 4bzVUkA9YFpCJjaNXr8/gtF099BhywV/1k0v+so7LUW7gDjo24V8KFbyoUIPCwjyPz+MJxEv 9ZUwvybOiwkY4KseOv8SX9UN0I++CV4xtSeZY4HV1DNIaj5AMwPH2mz4DwekOnVm4WJZQDl4 oFpnjvVVeVb4txTxV0QsfYdvbBY6Os7sX5VvqTAkHDzoMGPpmLoDrvVFFl7W1IsCh6kT8n48 YMplFiHuYqG2wULLKLKgaps88BwPtQM8ECbJg6pdas0iE/cTffzY0x8+P0IkHAMIhKmh7gTf 4a+Z608Nl76ozLJd/H9eFrydB2+zuTObMxfink0Mj38oLMZRMH1hvuxEcbVZRT1epX2kCs1X GHyTljeMmsLJbeuQlKy8Lo16qccAcZztzOJAhkxKRzp6qS8Lgd5sAeOODAM2XIAAFHbJbHsL kxEIA0dvBpt6oWAJWB9CpDyEHMAEh8Zkkwz8cZmRuDMcF7BEPpuJiPWDAAA++jAKEh14xDRE Kgq09R02IVOyNAIiA2YKQlF0ZROT9K8s5EwMCYYQZ8Pu7eSc2EGDVBRMLq5MZ4zhCBw41/V/ UHSoYXQZsjOYkOd+tHTjGT3INPrxD+Y6CzA6Haa1UFUvAAb+Go4H1/D/8ss6RoVO4OhqXl1d MbXRaLLhh38lpUZgzjHpcW0u4+uFORfmE/wSuoPR7JXZaTYb2Btd1jOWxtRxneilw2wnCKOp 4T0xGCTiOYIIGBMjvT4Qf8RnN73ueHLBeuB5F7igGBmCWnPueIIRNejUJVhSbLLwUMipIMdL YcYuCGglGDTTmUm52YaJXDgizAJj9sEIrB+gLTBivGjXc1vIAH9d1PMXS1SCS1ClMF4uyZgP 7m8Hj/3eRJ98+HT/Dzb+0L19+FMfdd8P7t9nkBjBhCJCjkH0N5PB5WQegyge+5PRw8fBfR9C /FG/p/cmjx9xfrxgDzCzBVD1sXvf+6B/6D7e9u8zdB/55A7GiHBlgmMVu54IUA4XIKfn5fwl RMsE1W6Zpl2gHAfwF8h4bNhZ/MSy+TobkIyNZbNI/z58HrLPwxADqhvW777vP+p3o087q44+ H6r5ZTQBxW5olzDdYVXfc1/OOzhNK2n/XeC3T+k3dobziR9HOExvs/gRYbHpMNkbFml8gsRy wh1YCoMrBMWxYhdliuOqFwgLmBmnT0GjVio7M+lxllYZpCMVMUgQdY0pZQszYjq4BiZl/XTy RGDwtArlwC2wnBbWMomD5yECqgE23PBgFEU+4Ma/1ok1MrX7Kl2m0x0LYu97LGKwjkYQoDlC a9ZhoW8+idQnYSY4RQLtiEnFbAY1YcgENEi5skidIsrzRYFhPmHjJfswsXgzmOi50qw1Nd4C e+Ol9Ucw7NA6UXYuwGwf165qvAVmg+aE1I1Kkm1oUxpXzQZHuwKOlW+CSvpBakDvAgF1MNP5 dAMyoinnZjxmC7Hwg5fUDrkRk+4aeokt1YLYTmvXrHaLXf5n/pmhCFtZA5mYBy0aMccEDsAt vTb9QFyZv6HRFvoUZta/wTx2rTxDnGFhunkPWGL6fjN914X26VCqUyoSrb7ng8StadDQTueB tyswAcQD8Z0yv1npazjJHujx0jIigc0DnjRgqfnr5bKHGy7Ks2Msl+7Lz5WN+m/hZhk4CyN4 0aM5+EFgdfzgCZipcWCm8cuZsXx9UzrYTxzHk2r/H+gp8CmQI7VWRZEXMC6FvjQic/6m3MyF uxQBmhsD5SPenJ8tir6HrTd/lnUzo+dID2EmN+c6RSQuzCSkAAqQ5Ooumikl+q3nMSyM8Cl1 o/eSBB8L4t3Bg46R299Q56fXGHYkpJBvxAPTp44hnQPzNjhLFXE2W2+O06hpb45zqqivxunI ujrg1pemowfgk6WdSLNi+ydhN6w3wE7I5QLoD/BvUNk1sw6I6z8BsWW8GvEidHQczz5M+4sQ 5dBsAtJX9WA2upzgO4wr3Qhx6RKTBZgWinw0OKpKvLcSOvK5DtC+SfETjnciXEoJdUBi6oZt Y5z7goqI2HnzdbrtWfpgNCBIQCnQG+JWgrJQegI2CITeBF0oXHsDBT4C4zczzJeS/YTuM3QU Td+mH4MdxC7ijV1WOl93vgTRE8BhQggD3mEYL2jqI0HW9yLGaoR6N1IZm3+eXFowKhaLGBfl ZVgI/voSV+ww0YjZhqebbZCx5/tL3HURBb6bRm1X2/UoxsPk7Qi0FzwbP57NaY1/P8gfGAdZ 8GQF4ZslswD7a+OfQRAvI/YoFoZcad9fe+SHkcgDHWZlPIf52WL90UQGK+Gu+l+h6u03mUwN r5frdl6vIuv6u4PtuDI7mqp22B+DDospqFXrjUuI4YIXFsDXs3We5/qBrZwgijHxXWh8GgVe SqHiXgyI2oVrPGdl63YFm8JIaniBLmNK6Ng0+OwnkbvlBDK+6z8MZFY4MZcQSOq+a0Hw/5c8 SJZIlqywEQw3BxT1iiWBu0qtwSpppNm/7958HNy/Z4OHSwIdPP6RbcOAwE/CIa1u7x/JJo+k +OpqMhj2HzuJjXunPN8plNzl7xQGLeXvVPqqvrvk+B1/p9lNaQ6hZckmGZI5823G1Rb7h3OT duXih+FEl47lQnOGf3YHExgS0zDC3UqYA+U8y0Hma66UK+2KkxRchrs+dtRxSZAUX8MIdh2U uC4xY3I1+UkAPw+/dNIcDTBtWCtMF1jbaa1LKf/hcPDADBPD8A3d2ag4GT0mCZh1QT/N541w zE+kmp+Byp+v63yWSC9HaazPBhYor2M7oPLs7PMol+nJarP74WD9EDOFUsEuE06nTgQ6uq7x yYOmRYFDKvgeZ+g0I/t52GHd8eA23Bx6JKhbyiCRqj8LM5ZZBRyyYM5EgJYsZFYsMP3b+9y/ VBXeuuSqqjTz6AHTxkihx1lGsQtzL5kOkBKSOvvQHZ1vbj+SIN3Rpvm8YOoQPvj71JC+Kvuh 45xuB+K7Lm2OHhnBTEQ4I2AYbWxOCIa5dK4TkPQ3RmfwOMMkURyefXZZOPJOcPZAhNY/Y/Cq 0D1JPAhHhDj/1XPz3z4zuYEEHm0gOubXAbguO1B/VnGwpWmF1DWSYUmhonAWZdAmIRcor447 /sj1SXAmXjB5kjrZXB2GbBmkNPETMOEE5EWUVF4JowwiyJcAb3TT8ZDNL9YpgxXUAyLUmZz+ MB/RyHuEx7pT4jBdYYDZ8/0oxVRd04oYrXix1HGU6RljDQyG7ZJ8oX5t4igjDYuWp3XUSYz2 6/lg+KgscgqYw1OG7PyHhToiqWro8dZPILrGUqGpSCXwMRZQW1Xo5nFE0P0w53hlyLq+/xTL fkGajRPbmkNThqrjR+5Ut904nFPq4ZpSHVWaSrAST0WCGK1RFJqLF38KzdgDawKUbKSkTk+Q KmEoLVRJjSv1U8lVIfY9NgIDXBJPgMqu0rFSO1V/cujKDpgwDpdQvpnwL2OKEtBy80YS/nFM O5W1PUhEQpahYQYG6FU4jyMctShGTEdpFWgVMZShCe6Hnq73Yw86ptDlihGagXqOfr6b9kNV n2GWpoOJb5GkWSQ2HC44sXCjZOuDIrwOzYfqc2f5dgzxevsXcERZPRDlSqwpq23K7SknDKgC qhMoW/wXUTYsKyfqKU225glkEx/zJLI1yv+eRHaNpypNkvBPpZk6BZQxBt/AjHDiE2jIGqd4 UTMoXuLerhOoqjXj30FWE+JUsoVRfArtes38BbSLcefS/yECQCYwMyUTHuvVMl6vNLpOjA0r MKRSTjVjaLV4pvWy43NYBRraVNtFIz5ijtMg1EryRhRZN3Px7Va8T3WBi5DSxpFjPoW6cI0l 7seoTKrWqkYKlwi8Sh2TQ0OpiWxfCT3FzrFp/Wdr8XkTGn2CNSNvykKt9u9nYWr/21kQzZ/H Aq1eZ4lTXGzHL5kOmKiH2taixy8gXVP4zyM9Xy2uQ/jvCUwywl+AyINf+mphTpPlSrTHgSmW EQzjZyfC1X1gi9Yu1XTt0kNzAlX0dDfeQfKSAvK+WgSxR5EvOnjmVg4R+QPU+B89fCCSGAnJ mhlUJkTJqYzQa/luto1XoptDrPnDcJ/0j1xfqgvy/XLZVMJIJAHtkvabH0Ga9qRO215zvYfs TvOJo4rcHkJs2G+BeLVABdM91eO4yQSHXLP+pjg1bZpH+mZ6to9cXXtFGzJtk9tZUDUs1F7V fCt8alO8At+60XJzT7IGSHsxcFTksUJpgPsSzadjaEnDIHYE4aMRQi4NsoBWxU4T+N53VVLk JFUmdUw/dhAymz+DEHl1GSEcma0phnSm9vMJWcrPIHQAD/gI2RIJbaip4+BOpyTcGbMIZ9XW SEhXk91jxB9gbZNta9qnDZIdCFvcKGA80ETcGxOFpu7bdnhsnWwXKa42a7+MlqYar5DUysF3 xAxPn79AwGLK5LSMi5q5mEVqDbRAX5Ta20nNwo2HOrQ447Uu0KFuvbW/cYCg3fq1BOU2xl9J kBLDlQket9IHSFKWrAzJKrpdQCMW+G4Q+tfwDb9Q6teWu8fNXbHpNnEbQ3kwUS9rn+lVHCzj lAPaMZ5tQjtleJQiwzUtT+dIU11hrF5HebWwY89M1xpKOGvSQZZ4EuhXMUC7vHV/SYkzbHr7 OA8/po63ssp2MapxyjBmk3Tfo2xovZXznA5Qm4lo7XHpcm/NcYq09CzJ0mtHkdxeT3ZbvK0W 6fkWyl3jfEq7+LdeKtg9XKu1roBsTnEs6gSWTQ3zaXO0Zhk2YRyZlo4jpnXxTcS4BhyIJb0s +Dr09dYuvstnBteIsUdc3POPr5ShLcWdQulit/YW3b+mk74uEWwupr/VRIREUE0CC+06Bl1y G3hhye6IihVgj5PDMSeZWxpR8o7X1hsJu4dqBlauUXkqNWXXizi7G1SSzJ4+W2NAsdjOs7DS /S0lZrkqU2xKjbQw8x+VcvIsApYwenIzCO5+9L7HTjjHlVs/BiMdplRLmPcDWF7LAqlsIZP2 FsTWp1igElHeQ+Ol27mGPk4wCf9z5BqUZyqhNBugp9CisLM0rWRbUUlC601INWvX+16vJTJ3 SfFb5VRQrIQHoxvQlTJXjvdPfPGKoLBP8pP8ASp5sMpE2mqOSJr4WWeP8TfuLK+K1lCP8y4z pTL9VpJ5y19va2nWc9v43q4T8iToBaUSJHDCSAiUbQlmkWU+Tu4spCNlyLrRsu9pCchDiGUi tVHZNy8zxGUfApiD80+tmd8Ut4eQnsrNXLrHKSzCQO5zzZQTZ3N6qbGE57ANXc51CAT6J3Y5 9yQBKOkDVcEclsW8dsCTvC2tAl7jW4I/KTzZRbGep1gxlSxxgi5lKaV0f6dZztXYAVyur5Nj YVDQuH0fvWBS463XsXaLbhP8NHcOwnAKFvCVWNpkQJt7SgxZgsS0LoGW00EzUFAHlXy+7u1y QEUqNVMrSWZueLibwCyhKGv02lT83Fbs0A7ept1+JebnXQhOCwXxcJC8fgiM09olQg2CLKkf JYnXpB9egvhJUSL2Db5WShvnqxIp17E4Lci1hvysYtC+gZKzygb4qTQ5+TJliFaN2SJ8uzVb PazXcW3BKBFUVO6zlTyPhHQ9SVJRrld96wWzPcRM8QuJCfMXEuOK8Sup8ZMEWW7E7aCnkkqW oVdV9QurUkiknc7lVTNmm9jqZh7bmzi4eIoK+OkOeS0JGXodrrD9ryrTu7A2Cpt3X818AcHC B/fLxw2N2FkeuoVGKHdj5VzdyjtkyHBK1DrdHYBxK72acmTGrxhkbJCQiyg/mQatMr4dDRn5 FccaLWBvJqzWxZUQFhI59s5OLZsc2sCcpmA2sJXKzBTFRm9Qg9Tkm9Tkt8wdyxK4/cuixXUl N6ZkdZqYTbpl4ojnmZ4IggAEmai41aYI5RWYs1YsFtcyALs2/QVoDI6neWpvl/RaMRkAyoZO aWiVCFPSE4h8mhxqP4GXGp1k8it4kW4pMJKmKXCviCWz0pScVY9k504wcGvqUgXUgiigFXpi n1XyjsmjKxEdnLa3Zg8z64xPnhlONp9bv0wme9ho047ko3xUTNrtZaa2r4NqFDKirjZKZKHf poNq+yRTo5mek/E4ws0bdNBhNtqmUoaPt+ogbV8HacgMBbfaW8eXx5jZlgwxI71U5c2Smiey YdK7SEf5eEUHzY0l/segH0zqumvSl0jKG/fq/bGT9uZ8R5vr1fIhbLk5Zu2M7M2fowbUrLy7 s7ET/BgFcIfpdiOasFx1ZiDWQrahsmcMv4HwDtesZpdbg17JrQ8kKaRZnlzy1uJKpLvUSySZ 89Tkpp+j6wt5kskJwJKmqpTTxtfSzBYUG2q5Rb9qIkVCaDGkyuG3LJFOLoSqnqobKWb5joLa zG3pqLgjFjGlByKnupWt77wOV6O1hatSG6VxmK0MfI1sZntpP2V5+2rs7cJHbzUU8VUa+NRi ufGWmpZo1/RFp9Uyepm2zDJDdb1KqCYbBDboUuK/TGa1It1EgnhujHzviHIvp2legiwhLodI gpXzk7HKsGx9CIPaxrGRnTtROH0lsThHz//J5CeFnWwKW/quY74k/FsVdszQUmoKXip4LEy6 8mCDBD4NiRonCYv28iYaRK8P4DZEfJ02nMsW7Tw3u9iifeBlPYMQTzeQWfPkHQHaIJPX35Pe HUAgOrXICb5nhmP6GoyJwjreyl0ik416ua1YEqBET2T5I3pVO9tuweXhz2UCKzltY1IiW4E4 usHjEOkaTf5lSFfftr6HpGY3S5JMTyoNnCWddkrnyZXbP6jrYeQv9WjuhOnZ4/ljjVal93WG kRHgAiBeY2nIQ0pU1N3a9g7Uw4gw+Z1upSMHiMxWiZnjtL30SxGhJ56cAJadgduwcyp90iAh lNPANyzToLdV6QAedUoOtv0azLiBmcIe23FdXGvFiIHe6KuXEVOFRfSdlDSzUYoUXrggdHkB LRjp0Dk+AjN6cvUkwVF2X4QkWCLbm1j73EkQdexuVStJolKbtoip8hCV0tRQEn5Z81UkZFVq lpmcXluRikpv9JSmMjvSHLw0h/mmGQd41CzUwktmlezKYrx1p9VhwuC2sPCetRbe7KZ8ZcWf 7DqwGzo3IwLPAa/2wxuEkoLkvhS0kIV7Q8BGXTBOVJcikFekXKbbXBPY/79MpfxlKl2LUjMg VqbgmaMpM+tG3OF1SlQBejstvmCGGTkrA6ewbUx8J6ZcBfVYhdqxCtqxCvVjFRqFCvwVzW3u xJSr0DpWoX2sAleO1uA7a8hLs9ALdztsWLjaCp8htLxGhzyE9Vm1j7Hn0W1GUTxlMEhQlV8Y HjKOd6GHV1fZ/TnOMwze3z7d0vWK3zrZebB4n7JQNI193XzyrXhsbK3V0uq8iO79aA+6+ha6 egl04/GbcnfzRtxltliegt7halvpgIl9GINBdww8+saIWFO7gHjQEs8suE5PQr7/ws76dH6w SE4UFud4txEe8Iu2m9Q1tYd0ADda84Xx7CziBWuB6zTKnWX9+++/sxu8yx573GCjzx8kDDxP G04XV+Ix9cDTp+RWctIevEUPfjr070qpVJ9XrF+rWL9esX6zYv12Vn8oa9Ix7IJu7NsJwbUM Qp6KLg//M7ILEBidYJSemO0HMMvgncvrCmGHqcVSXizlxVL1YGntYKl2sLR+sLRxsLR5sLR1 sLR9qJQrB0sPyooflBU/KCt+UFb8oKz4QVnxPbLK6w/EJdkh60fu520cvuQeqzTNnZf6Hrqd XUmugy+AHb8LfvsSYHAZGy3RPMSirNLaBLLbTQCimy0hwjd2w7WV4o3DzWZ6Fby3jxxUaolN sJYEi16WgrV3gbSVTZC2JSkd4DC5ObcIZ9o5uPvP451g1hY566jwoRJdZ7vjBuZDYOl1p2sw UQYsvdx3DUZPjoLZ5iZYCWrb90Ovb3je7us/u4/3g/v3HZr3HPDCPSaeIbhw0NE2XLopQV4w QTea4s0GsUfTrIEXjhaDDnDAf6TDcoUX5eL9aOEc74jAwBdve37GuIgO3Q9TJ2psBvF0ipMF XkeI13LjJbL4Ki+e3uhll45G1hVeBUt3XNFtrEkB3T+ws+T36j+bYuk93I8fPvbZw6fJ6NOE DcZs/D/3vQ+PD/cPn8ZJ5ckcBJfEjfAXZvXolgZwSQ3HYrTTbJbcYoFXlE5fIJoJ42DtT0dz kA2GsDJ8Ryzhi2fOA9/z49DFPVkuHrgoo068jRs6nwQOHm12G67/Q+Al0Q548AbeYgsRsxWb go0H7+8Hd4Ne937CcOnTM/EgRgPmeAPcNDMNs9APexICbyK5YgNi4v5hQv7vYiFbhJeQLgkr NTYOxV9eLeoaXX2LHxw/cl7ZWLbR8VAkIMzbh6HCzsju/BWvcL00/koaJoj1EKvIBRcJkqq4 vOSyobaebuhS4PR2S4zLwQmTP9/WXR7K6+E9gMJbLECKy5fk4mKI/EHp/w5/ibTkrHm+iakH jwMHI/sz85zxdrtxgZ9N+mzRZ/uCqTRE4ZPTp0qftYtNZPgDBRoV1+mzQZ9N+mzRJ6HjhI4T Ok7o+D50nNBxQscJHSd0nNBxQqcSOpXQqYRO3YdOJXRqfVfpBJT1XkQ341vpV9JUfgEWw7xi OFQZSSrMLpC+OibNlooSbJFMW22SJqfP2j7yj2IGnRXi8MOh88mjs0uhI/FJD+wYdK7nGPv4 2USbtIbDI/2mP+kyVLOajtoJRvSc/aZ12ASi0LFYogvKeaeudOpt1uuPJ1JM/ws83HOX4osA AA== --CY04cZXxvSYdQTAg Content-Type: application/octet-stream Content-Disposition: attachment; filename="4.20.log.gz" Content-Transfer-Encoding: base64 H4sICC/rtmgAAzQuMjAubG9nAO19XXfiOrLo+/0VOjMPJz0npP0FGO7tWZcQ0s2ZkLCBZPde vfbyMrYMPgGbtg2dzJoff6tKtjFgQJB0z8tldSfBqi9JpVJVSZa+8oAZV5pypVUWEbc0Rasq pqYGY+V/XXzt3H9gXwFgxaPYD/cBsotxuHzl0f/9wC4mjsMugrHOoFxXFcX8wFTlqnqlfGAu Hy8nn17ZaLpkreWEaSpT9aZmNnWV9TrDEaJUU6Z3dsLjhLWndjDhQ540WVowXvozt+K7TaYr Gm84NdXxzLrrmFpV9Rqq67rcrCpavVFvVGtavaZm1WiHQRzOOAuXyWKZMD9m8WvgTKMwCJfx VQbUf2RPPHDDqMm6QcJnl+zWnvuzV1ZjF8pL7cMl64UunzHDwO+aAw+GCV8s/ADqwy4i+wdT FEVTao72IaV5Peyzue9EoQOYLOIrH5uyyZQXhT6qkQGGYTILbZcD83ueXA9vPr6YNXbdfRhS 2SUbpMiseqWq7OJ37rKeHTHgrNSbhtnUFPY4amM7atAVXhTOU0KscdWAf/qHvDHmcztw2cwP eJO54Vyx5nz+SVU0o8cc0VKfnHCuMvzxSTcNRbk0A5XNwslsNftkz2ZssoQesooPgiSxx9bc frGCyPIie87jTzWD2tnKiKrE7dNiNS2olz+3J5xh3dnYjjmzXTficQxtlAI9+S4PmR94YTS3 E2y+tIA9fW5hXyb8JWFzbGATuqV6ybwwSJj5otZywOvOx5ubNpvzZBq6QDsIA/6/Weeme8OS yA5ij0cs8efQHgqLOcjrxhkuASF3QEqgC5PI5yto/DF37CXIG4QMSacF9ixlAhqfcCfhbkrn xo+d0krchkvoDBgF1wMW+5PATpZQ/+3Szs1NEZvFSbR0ipDQlBVughIMWj02txc5/W/K1ueS Fb406mPP+5NdLGN7POMfypAadWcbyfMICbjzCNqiFI3v8PIk0NQtEcdevZ6i7RMRQEy+jWQK pOR1wVmjDKWxw6fhCj6tdr/LXDuxS1k1dlg5XgHv/mlYiubusHOPtgYAcWcLzTveiDz9vUbj Mmge51to9OQomudso0lwUzPgHK2mr9E2e/qe/ygYii0b8TJOxU6BsROabDC86SPh21b7hlho YLIjjUpbvQ8bsF+HNyN2fQsKoQpxzDbAqmzYa3dZ4aMpqqqYis56w9tR+qxR36QF/PqCltYg WrfIV2eIB0Ybi9WqUpWidZPLVWsBrVq1ppNcMKXWFEX8hE8mnsK696M7oKxUVVXdlWtItDpp kxub7dXqd9uCl05yq2qHeKVyY7G03L327WdBy7gmXnq7SOuh0yMIKVrDu27aBsatoKVs0SII KVoAfJ22gSH6ubpF61q6jsNBS8jVor5R1MaOXAiRfVTRN9m3TVpf+p2UlqmLOppbtAhCTmd6 rUFaR9J7NW0v+LR6oM1AjEByuQ7VMdW/lqp3kJae6t/NYtKfzxGjvVj25xkp7ZD+dbr3/53W sb4hF0jVGeBPi0Bk6njdGaTt1VKKOlGgRSAytDqDYUaL2l693pVrMJSj9aWT0bqm9lJa5gat 67b1pXOU1vA1TvgcJ/Em04xqrQ5KewHuLfylKM/XuU187LXAUUSfR2H9rz34eWSeJ9Mqhb07 BaeG+Tj2rlnX9f3YKmGrObZu7J8UNrAfY3S5VRMcPXDbppxN7XjK4qnvJZm3Fc5tP2BTbi/A bfIT3575MThtoP3sh+8mU6ZrbOwnmffkkZs17PVZr19JcPZhdsJoMqubma28gSG0wCktSLKY QUhC5tONfIiUwO3z7OUs2VCNfq8yAucyYt0H1g+jBOctUwH1gGkJhdg2ep1OH0bT7UOTLebq i+UEyTe1aSrGpdpU/rwUD/lKPFTo4QaB4ueH/cyXC2vFnW+p8+IABfhqxf4/+TdtC/UudMCD pfqkcyyI6m1OsQ9Qzch3tyv+w4dWHfuTeL7YINl9IKgL3/0GUY/6Z0b4GxIWvsOfbBL7Fs7s 35Q/s8YQePCgyeyF71g+uMGXeTCqa5cbEmZOyOdhlykVTT8ggr4lgmlviqAZ2zKoBRn0AzIQ JSGDZlSM+qYQ9yNrOGhbD08DiJmXgALxbGz50Xf4azILx/aMvmjM9Wb4/4MseqOI3mBTfzJl M4hRtikMflPYEkfB+JWFohP51TaIdhykcQSE5iuM0knLa7auqOS2NamV3KIu9duZxwAxl+dP lpEIb5SmcPQyXxaCsskcxh0ZBqw4hwZQWIV53g4lO+I2jt4cN/NCwRKwDoRIRQwxgAkPjck2 G/ijkrO4tf0ZUElCNuEJ60QRINyFMApSHRhgviJrCrT1TTYiU7KwI2IDZgrCRnRlU5P0zzw8 TA0JhhAXvdbN6AOJgwZps2EKMWA2Y/T64MDNZuEPykMYmMeI2QVMyNMwWcyWE3qQa/TgNwj8 52B0mswwUVUvAQf+6g27H+F/5WsKaEfOFFMQH31TqzaunKZuGmDJ0DDMfJukndvxc5Opzjp/ At2monN6dXXFtFqtznpf/rlNz1ksP86dKXee4Re3fMy0APl6XcP+a7G2vbDH/sxPXpvM86M4 GdvBM4NhBVE+D1xMe7Q7IO4An123W8PRJWuDr74hBeVvQEBn6gecETdQgwXYXhScB9gtWdMP F9xZzqBJV5xBw/gT0dKe7aAUPo/zUJp9sSP3B+gXjLEgKXvucRG+r4va4XyBalMB5YuXiwWZ /+79TXfQaY+s0ZfH+3+wQWf0OLhPvwy/tG4efrf6rc/d+8/sS2tw07m3WoNB64/sy/Wgdd/+ kn37/AiaZrXa7c5wmD27e2j/I5cAY6eYJ1hz6PTrUbcymi4D6Dlg23+46953Ltmw32lb7dHg DqfmS/YAk2oEsMTIEkRzenfq6BaGJ5+JPMhqOQt4hA16CQ3+spi+xmgUAeyGGcYldkgX/oLO GtpeHrqx3FXIbQFjQ9E+pPpfnnrsqRdjLHfNOq3PnYF1238sBe0/HYL82h/BmKoZFZhpETQM Zq8fmughKJkiXOK3x+wbu8CpLFwmaCFu8tAVcbHq4GfYLg22lIjrxyVUNsZ1DBroLmfYpjik 2xF3QZhh9hQTgxq7cOhxnjvsZkYCKQgUbU0pEwsTZxZ4JQ4lBy1ygmAUmhvlIC2InBXqeYuD 08MjgoDpww5gOCYh0Ma/1vk3svL7gCrZTMuiZfB9yZdgmO0oQkuIhrTJ4tB55pk7xBzwxzia MIeK2QQgYexFNNpVZZ75Y5QOTCLbecbKC/FhTgsm4GOoSl2vG6oJpi6It60LJvHAmhgNHY3V aMdY5cYfBjxaUsr6RZhFVI0rXTXBYNH8lbl8aRIPrVntql5toEUDJzB0QIfDKDP2txEHGMyg Pl9Do9L0eA3Dcc7nYfSayThLmHAt0aM1NRfiUMMe667JKn8vPhu7XqO2RnIwvzp3MEkLs63l Tu3Ahfb/L0xBf1RedBtUEPPlRyzsX+m3Rc9pgOJsFITQHe44qhlb/NzQSq2nwABuqgfcjJSZ oG8588BK5TlML4WfOzZmjWFwAUHDsIFi/TT5A2hpy5lxO8J5wYodOziDs904nTOMMRwJ2INn sq3Wa6ezleywTWLZksNHJ4xgPPwVPRBujcFNRDFACLVUhhwtEwGeQr2/U7Z/vY7xFkEif25H r1YyBS8NDFMYoWrp1C5yItmLxez1fYTJH1jLhWsn3Jry2YJGlq3jyJKUKO0nmOjJNfgZ8miu tlegLTGSl8SKYQZzphbavMzvfH+RvNq/RyQ0TVtSoXUSxlBSr09Sop02CAPk6MrrrBPOZjCP WDicaCnpHH76CQxPql+xfyhunEEPYZOqaCUxV/fuPQwxY5D43iu2CHKqcpxb3EOcwOJDlTBy EgbyJAaarR5lIEsafOnlAow6fLEwPYDk0VwYZkqdCFG+YOZGFjrEMgS7Dxm1eh3b3a0bghwq DTYquF1E1XfPoemZ706zoevvTtNWa2+m6QtYC2hbC8e3Iph9M402ix7Te1O33XegTsTF+voP 8Itx5Bscp+zq+P0Je/abCc9jn+a+EByMeTwh/QWi3ltorpMP0XcYmZYd48o45rcwk5mEOP/o Y9S+emadxHMLsGFgYgCPI58YSymhBUQcy/Y8HLyvQN7BCVetvaUWMTy2uv0uYQJJTiSzhtko PYOa13gXajGfeVsk8BFMBBPbeZXsJhF1/ZVcOidcgg3FHqKhbGyb3CLsdAEtTwiHGSEO+KHx co5aq1HNq3sJIxiRLicqckNPo4oLg2I+X+KWD5FNgKhtgWvMmBrH/Njz9S7KMAjDBW4oSqJw lgX7V7twlBrA5YY+KC94u+FyMqUdJPtRfsPw2YUnK4haXZGF2g+Nf0bRcpGwAZ/bYhfSfuh+ GCe8iHRYlOEUXFmXdfojEbLGZfDfAPTmT5H+jz8u1vX8uErcj999rAfG4prWZL91m2xJgbhW rVVgbo5eWQRfL9aZyY8PbOVHyRKXajYqnyUPKqJRcadPEyo9s1/ysnW9ou3GSCGCyBKpCOjY LGfRSRM+rh+JKL/z0BXrGKm1tCGCC2cuC4P/KKLkSx8oyhVLkzwaVQGfZ1mJzn3r+g6zeN2H CsF3B7/lO3sg5hd4yKDV/ke6bygtvroadXudQTO1a5+Ul1uF1iDUTwqD6qmfNPqqfaqo+B1/ p6i/w4hxwAo+szhcRpikafcehmwwamdZemEjob7pxizqCRZ6TNVM9g//Ouvg+Q/bTyo+RPdN 1vu91R3BQBnHCW7Pw1y+qua59CLkSrkyrlRqmxnDJEUJzIyal3IvMK5nvgiqiTIuEqSfFPGp 97WZJfxAaNtdYe7J3U22VkSv9HrdB2Y7mKLZ0qgtwFF/kGbz1gWdLMvcR0swEsp/AQPhwxrm SRCt9LM8EOsKd9OHgcAunvqFtGEOze573fVDzF8Ltaukko79BDR3DfEYQNWSyCfF/IzTdray 8NRrstawexNvD0hqqBtKR9IAeOHOUmSccCCDkeMR2reYuUuOyxjtp05FU1SzomqaUi+SB0pb 44ce53nuFkzIZFCglZDVxZdW/8P2ljeB0upvG9VLpvXgh/o5M69vyoxhVGhB5I1Bxzo61VVK cmTTN9j5MPhYBKWorIC5CH8cy2GVc2q4P4HTYulF/Ltlu24WIdV50VPLJz3bWfgfU3D6gsEf /LIyEiLk9I9MsLsM9YZzPkP+IsvQxeiRGLroimo7s/o78bNyeDFfWYkdTTgm5TRs2J2U3FG2 Al+WKQUL4cx30LXUDdSYnUj+KEsQGyLaI3nbktmYHGn0dJCg+z9LCADQk06dXZ/HFIFj6JKK tG9K3yICj7YIHQtBAN0SZsWCkBymAORcbH+RTtgA5P5chmyaKgGTauHeZ/LSU5ppwEZBj0X+ gQUTiQxRclIJmWgC8U2SVH4SRRHvkt8LgVPmJOsb1d+EkaEK6gH2ZSJctSyfmmvYse4UNCin DtFsmGSUTte0TYrucr6w0PZbuWA1pxAaHpML9WubhkxruLT5h6wesDQp3a3JtkVBAQt0ZNhO f7ioI4Kr6hRin1OYrqmcUFXkEoVoWzRMcFRP6viURgLdD57QkWUNgTILw+el6BfkWTuFZ6Gu BTIyXP0wmY0tb7aMp6hKCvarelJVCVfQOZEhJhYwYYKTPf+ZPJcBWBNUIAU9GM05o1mJhHSr Zuwa57I7hdn3pR3Z4CkHHHR2lQ0WMle1M1gXyMmOmHgZL6Acq+yeMOWhLUpR5SaONFchEo4n MBGYMjycyAbFiqfLBIdt1oyyNgd5bVKQ6z+Y5R0a9MaJFUtRZbiAY2Vlm7ZQT3yHW2IpPcv+ GCX+wn6s0yeyhYPel8vTxKOgRsMErY4mO4NFmwQsaGUAn/qLd5TI479AIkp0Q1uueIGzq5AK nDFuN0idwdlzfhFnjIfWbHVMbNel3apdX/YstoZdO5ftms6pPL3qz+aZOR+0iAI+iJPgBMvR rJjSs3px+EPxAnfonsFVU7V/B9uq5p3LdmMUn8XbrP0C3sh1boXoYVQVDPDHO6vJZWEvmnJn ie+RQtgrlnIkVyKIGmVYcMkYs8IirbjO13ioYVXZep8Z6p4gj1qziwKt5i+U0jg+I5/AQ+Ol PJZHrH4WU7tpcpYSBWgDzX2dSLAgRUwrNonvPMcWn9kL3BB3Mit9fBorXJwLTuqYAhnKtOQb ++gpbXKhlVd+TAhU2LUg7yqCrv/7RRh7/3YReP3niUB7aPLVCdz1hF9yHajWSrdZ/grWZvkO z3dhPV3NP8bwP+CYyYe/gFAAv6zV3BmnGwXQ7EcOXyQx5VhxLxGmasnlbKRSBWhOAMTK9k8f ZC84oOyrebQMKCeEfqTjbFcS5QPS+B9DCGCSGgkhmnMkh17GqFFk9Fa5zWr1jeSmEDn/sGfP 1p1qLbQ5Wlc0eeMiRWIJZBf0ctIRollPik2jhd5DcfVivuREaQ8RHtffg/BqjgpmBVqg4u4L DJvrtXelaVS1ItF307O97MZvqEOubWJXHYVbtWKG5s30NFpROpfeutJigSldfqddUDgqilSh NMK9x87zMbKkYRCiQuOjETqwce9Ip3Hv2BJbCauxcQ6rY/pRwsip/wxG5NXljGjIczJ4O9PH uzNqKPWfwegAHfAR8hUf2spWx5kya1LckzaPJ6ct+ZCupptYSb5sH7hqnmncSgiaurZB8UAV cc0wiR0r9Lz42EpjGSuPm7+Klao2vDc01MrH94ntwJq+QrziiFQ75fmqZiFkEUoDNbDmUhv/ qVq43dqCGueyVmkzpfkzdHUPQ9p6+wsZ1pTxL2aoGucwPG6kD7AcK5IsT9HtDTJ8jm+FonsN 3/ALZZg9sR3DKQtNd5l7GMmDhXpdu0xvkmCxzCQwyI64bxgeUmxUwyjyOVLVGbdXb+O8mnvL gLYFGIU1oQNshX8s6KTYbxLAscHFFRkrAx0kVULFfoz9YOXKdjGqcSYwvSoQBpRzrZoFx+kA twlP1g6XJfavHedIC+mCLb0nmojXZjS7sKD5TlpkFWso3l1Rx1g5TaI/45Nrt0FsSmEs6gSW jW3x5iKO1kahkpRg4/aRaek4YaOMMK5oR/yEd8H2kq+ZZXLLJwbXhLFHoDvQmk7JluJuvKz7 q+/R/Ws+qY13ou2tAe81ESETVJPIRbuOMZd4/0KryjHbwT3ODsecEG5hkxtXWPw8MlRzNLlK FbnoipwNjOXZ7OmzNQVsFs9/4bhCTplpiVnulCk240ZamPuPilx7biJKGD2xtQV3GAffl348 xQVi2hQdZ1x3Moq7XA9QeasIpLK86DS/B7P1iUeUP6YF8533MPbWc419nOEq216as6vRdiuJ aWwL9RxequKdwizdJSXJab2nqvzFy7cymc6SbH+I6R2lzVc8gOEN5KTslR/8D75vSljZQJbQ 9CLayUwatW1d3sge4298qeNUsnbtuOwiUyrSb5LCu+F6kw69b+kdb54TO6HIYqzKscAZI2Ug WxPMIot8nNgoSeeP0ehA3arViz0iHZIfImxQ4rsmOyJy51xmjIs+BDQfJyB9I7W8h5GVtZuz OPLmLnKYx5HYtpsrJ07ntMwiYSJ3seV8h4ijg1I8QOOIDgCCpBN0CuVYlvLaA0/zttly7M77 AO8Vn5RxrHrbqyHyqWRBE3Qpzyll21WxrzUZW7iDLNfX6Rli2ND4jgy6waTGkv7iNvp5/hzE 4RQt4Jv56GcIR1zGOUZMTOsSqpwOOpGCOojuVFXCKpyYBNrkotMingwbcS6N5Ugoypq84eg/ txYl2qHSqzaqxOxQRuC8WBCPcyrqB8dqNyRMCGFK6ockc11xJZmfFSZi3+AMXC196+ZdOhan BbHWUJxVbFPS8S5BP5cnVFCS6alBW4Ivluerh1Va3bQl7OjJfbYShw6RrqdZKnNc3HDwk5nR 2VC/ihktBf4qZrTy8auYeWc1o9x4K2GnqbL8TlX8jUWpDTN5asJsm1pVxu6d5t7i4Ujgpfvk s6Rs6N2+qvMGocuo1tQi1TcLv0FgHoLzFeJ2RuysAJ1CWyQzjEKK7+T9MWQ2BWmLLqTB0U6v 2RyZFk4MMbZYqKb203loyvvyEHHf5lhDQ4ytZe+0PxWfRHAjj1OMXtZEZXNDW5SzBMwWNam8 zGaz0SEF0GrisALyWqa+63LaS+ZupeYFNM3KDl1cdMTtzA7iQQTCTDXcJTOmvIFyXon5/KOI vj6Kt9JxOE0zc7ugF/dp/FMudEwvD8nP59OQpgb9J8ii1+q/SBbhk4IgWY4CN4q4IietyUyW Z9i3NXehAtpGU0AtrNQ8a9gUdKTUyeGI9MaaPcKs0z1FYVSar9TxuxmZM8Wou7qMHCdm7PYK o+/rIB2ncAONV/29/eBjwuy2jE5r5jYt1v/8DjoihufKyPFeHWTs6yCDtlDTwRnKr+ogY1/L GKJlaMHiSB7mHTrosBgmhaZH5XhDB03tBf7HiB9M6rprsjdIJJJhZ/dHKe+tOUajsws1iTWR k+aYtS+yN3lOJ8uaRW9naxv4MQ7gDdOddTRhzbSJjVQ3Ug0nO8bwGxiXeGa6d8LSV9pSyFOe Xfpm5IrWYSQzzEVuYsvP0cWFIsv0wHbBk95jlkiXvJVnvppY0wqe47s1KTJKN2USYsp7/GrR Qooq9jKd2LYnsU1Xj7cZm4rk/rHTGaOFFEMMv+WrBhTu1tVzx0JGWbyQoY23A0757b/UOOl5 /dnI18bvQqtR3aF1Uh2FMZysbHxnbuIFmV7mixSniVdGj17h2KR3kqHLaOIpOOK1I0q+nNcX KbFUvYTSpFRV9WyqIjBbnyihNcbFbtk4Sya1OUdPM8pHiBhP6aYwcXZUKr97wo4ZWknN0KXC x41pV5yfsD66ioKi815pob28qZGgtwdwGyK+TRtPRY0k9lTtQ5f1DWJ8uVgkzdNXBLKcUr4w cNarA4hEZzD50ff/yo6m0d5CMVVYP1jNFihkrSG3FUsgSPREnkCiF8Lz3RYqHZxXk5if0okb 0xL5AsTR/R2HWOs0/cuwPn3b+h6WhifLMjsiOPIXdMwwndkot3/QsuIkXFjJ1I+zw/yKhzSt pPd1xokd4fofXk9si7NQ9I3zrDNSx97rxux3tpWOcoeUc5Lcf3f6XvoFT9AXT88zyw+frusF lT5rkBDJcRTarmPTy6p0mpBGrwbo3lso4wZmCnw8f4Y3f0xiivWx22SW1k5YQy/lZDg1KVZ4 Qw63xK3mYKRj//gIzPmJ5ZOUhuy2CMFQIt2bWvvCERuKWFfTj7qCZ1Rql5tKp01Ic8OmCGXt 1yYj/aRqOenB0adyoW2V0lwmR6qD96Wx0HGWEZ7yDFDt/iNTsmNkr/HCNbPJuK3WNddUFAX/ j5VvbPOT3x15TedmJOA64D2weN1cWpDecIUmcuOmJzBSl0wlrgseiUutKtk+1xT3/19/JX/9 Vcul7Awek6Lgwb6ZMOtK3OJNegQAvZ0VXzLbSfyVjXPYLiW1lFIBQDsGoB8DMI4BVI8B1DYA 1DdUt15KqQBgHgNoHANQlaMQailEepkUuOGzJutt3GqIzxBb3GNGLsL6QOjcTKTXoqm6aabH gdPFaHiadsLqxiXEKi5/YdHH7CTs+6/sokPnR/P0RGn+Ae89wwOe0axQS2ZDFawSmpm5/eLP l3OmGY0a6xfOOv/b3/7Grpf+jKpps/7TF3GSOzxPIW7p/l28uwBEehwwPGDIpnrhZaDwadK/ K+UkePVEeP1E+OqJ8PUT4Rs5PNn9wMf+EqeFg5bQMedkalh2ke1ldg9tZpnpKFk82X3VB4uP lyUCJY/uMQXjlalXT8hBJ/9zuta0VB7VyOURB/GLw/Xs/MoNRif3ZMexhxFYV7yYfg0QN5m2 WapulqqbpdrBUv1gqXGwtHqwtHawtH6w1DxY2jhUqioHSw+2lXqwrdSDbaUebCv1YFupB9tK 3dNWnbvbJltM3Qh+4t12n2jNGy/dBaWK//kJ0zKGZxjmfnjV2ETQineJErzQT7ypIKVd+Tuj O122AQMwa00mLlIF0/iJ/eWeJ9fDm7/sA3rqDIbdh3uENK4ajRI4+F6EeuFBBaxLCeBTdzCy rlvDDoCtbz4wN69GLcD3Wzc3A+vh9nbYGSFKCcSXP4a6ZnXuR4M/iKimcMMtAfzyR78zaLfu 7vCy2W3+muKV8v/yZA1HLZD57uH3HCUTt1zk205r9DjoUMNiFJYehZgH0+Jk53/ZyyRcr2yI C3YgWPsX3Vuw8vEwKEzZWc88CvjsX7jIkr0rmd4KVNK8/VbH6j3cYO3+8srjEog71erdQme1 7ro3JaUPrZvOALEnPOCR75RQGD4O+537G6vdum937so7BbTJGv7RG7WuyyQR0wHOi/7cnvBi UXpfbvFKYUa3Wog0b/rBjlAKAHiDDw2ULFTfBiAKaVkpBQJ4Jn9iDbAxxtZQEFwUBVHrY3vc 2AETl74UiRXUEj+0blCo1IZGbt0JkhsEnF+S7SGul9oOnGwQNLMcAhacFcfOYIvzGuhe3ubf lK3PJSt8adRAsD/ZxVL4SWVIjbqzjeQJpOzI2lI0vsPLk0BTt0SE+tZMXq8fEDEFMbeQPBN5 0bXkrp3Y5XiNDWZjr15PZcSbcMvZAZDJt9FMgZa8LjhrlKE0lG2Uhis4HZAQoXZYOV4B7/5p WIrm7rBzjzY+AHFnC8073mfZXfVrNC6D5nG+hUZPjqJ5zjaaBLf8xu4craav0bb7Og3fIZT9 kQ0osALfGV78Gk/xziM0PTQecTjSHTFxFrcMnWg5HqP7iTcrs0GrBwEKQ0uPx60G+c3tiXvF 7sIJXVrZxHuN0gK6Lqe05G+nf1LM31uD++79ZwifHu6HD3cd9vA46j+OWHfIhn/ct78MHu4f Hocp8GjqxyzNwMBfmCCnS4XAbbd9l9GuzUl66RLezz5+ZTyIl9E6Mk2m0DaYDBKJMKQSvwbO NAqDcBnPcH/jDI8uFfmbZMqhPSNqcIgNs3b8Ev6ABoiYD7GwHaAYUeguHc6G3c/33dsuzFgj hrNt4OCRpjbYcduDACJLWGDY+Mw5Xqd1xbokxP3DiOFNyPO5qBHGFAuiSpVdxvw/3tzU+tXV FdPwh4o/ClHkUNTRD7BJoDFvHnoKuyCL8Z94fX3F/k/SME6iU5gklqcFSqac4r7uWg2v66aD 4zcu6naVlcJG4JzghUS4bYNVAGoVUjIG76XPT0y3RaXVgoQ3yzndPkYzCa7J/lWhsAh8gHUF K/D5hh1fMa405UqrLCJuaYpWVUxNDcYKY7g3u2YwoSmfYNoc2ahEELUx1sa58U+kkaXz+o/4 nGVXOA26ffoO48psfvs/Sv6BKVermX/PosPB7V3r87BZnF5wkNeQx8P9qPN11MTNxmKvKrvA dslaMLJf1ngguQEWRQe8aPxSpEcMFXzubDxXXI+PM3Ejd6NM2BnEif3N53r63N18rqMRzGiN F+uyzC0lWoXnCnoAGjfwudlkRbnok9FqlJQhjqo0y5+ru88zWqq2B0ff89w4QKtaiuNEO3JB zIjP99NyonL+TlQib4rjxeNSnMne5/FeWi4VqQjG1396KQIh53/GawBHPM3ctvxeMhp12fBs gqEahyGt0KWX2WeTk7iPT9Er0GKPtJBJeTda1+gOBjtgqhyYJgemy4EZcmBVObCaHFhdDsyU A2tINq9sN0j2gyrZEapkT6iSXaFK9oUq2RmqZG+okt2hSvaHJtkfmuy4kOwPbU9//D+Ft6v0 qJoAAA== --CY04cZXxvSYdQTAg-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:11:42 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:11:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106454.1457127 (Exim 4.92) (envelope-from ) id 1utQnS-0004uf-5S; Tue, 02 Sep 2025 13:11:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106454.1457127; Tue, 02 Sep 2025 13:11:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQnS-0004uY-1T; Tue, 02 Sep 2025 13:11:38 +0000 Received: by outflank-mailman (input) for mailman id 1106454; Tue, 02 Sep 2025 13:11:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utQnR-0004uP-DR for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:11:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utQnQ-002tcf-1F; Tue, 02 Sep 2025 13:11:36 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utQnQ-00D78H-0j; Tue, 02 Sep 2025 13:11: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=mC41VI5MEHMjOTOTJQ7W0jtVQK8dAltVIkznSrmdRbA=; b=hBNM1IMLOcHWE8g8l4KECEi6Ca cZU9EkJtZj0WEcrKHUg0BDpIgL7zDE48VBpHjdZp+xLaRR8AkHkmcAuHPnzyKrBMjgt5rux0Uu2F0 HKY1lseH2baoGn2vOSR6cZt281Abysn3IJmJ326RBvvHrNKmGl4sSzBuEj49dR3MmRDw=; Message-ID: <825ff920-7c7c-4d4b-bfa5-f7238877c246@xen.org> Date: Tue, 2 Sep 2025 14:11:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 04/12] xen/arm/irq: add handling for IRQs in the eSPI range Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <2e91a95a-3109-46ae-b796-1a1c50a9ac2d@xen.org> <4c3a2a94-7c19-4d1a-8477-c38716170c49@epam.com> From: Julien Grall In-Reply-To: <4c3a2a94-7c19-4d1a-8477-c38716170c49@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 02/09/2025 09:56, Leonid Komarianskyi wrote: >>> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/ >>> asm/irq.h >>> index 5bc6475eb4..4443799648 100644 >>> --- a/xen/arch/arm/include/asm/irq.h >>> +++ b/xen/arch/arm/include/asm/irq.h >>> @@ -32,6 +32,13 @@ struct arch_irq_desc { >>>   #define SPI_MAX_INTID   1019 >>>   #define LPI_OFFSET      8192 >>> +#define ESPI_BASE_INTID 4096 >>> +#define ESPI_MAX_INTID  5119 >>> +#define NR_ESPI_IRQS    1024 >>> + >>> +#define ESPI_INTID2IDX(intid) ((intid) - ESPI_BASE_INTID) >>> +#define ESPI_IDX2INTID(idx)   ((idx) + ESPI_BASE_INTID) >> >> NIT: I would consider adding sanity check (i.e. ASSERT()) to confirm >> that both ``intid`` and ``idx`` are within the bounds. >> > > Okay, I will add sanity check with ASSERTs in V6 (similar to > GNTPIN_incr2oflow_mask): > > #define ESPI_INTID2IDX(intid) \ > ({ \ > ASSERT(((intid) >= ESPI_BASE_INTID) && \ > ((intid) <= ESPI_MAX_INTID)); \ > ((intid) - ESPI_BASE_INTID); \ > }) If you are using a macro, then you will need to stash "intid" in a local variable. Otherwise, it would be evaluated multiple time. The alternative is to use a static inline helper which is usually preferred. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:24:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:24:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106471.1457136 (Exim 4.92) (envelope-from ) id 1utR0E-0006gI-6l; Tue, 02 Sep 2025 13:24:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106471.1457136; Tue, 02 Sep 2025 13:24:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utR0E-0006gB-3n; Tue, 02 Sep 2025 13:24:50 +0000 Received: by outflank-mailman (input) for mailman id 1106471; Tue, 02 Sep 2025 13:24: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 1utR0C-0006g5-QM for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:24:48 +0000 Received: from mail187-26.suw11.mandrillapp.com (mail187-26.suw11.mandrillapp.com [198.2.187.26]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3054f18c-8800-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 15:24:44 +0200 (CEST) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-26.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4cGRL32qfzzKsbb7P for ; Tue, 2 Sep 2025 13:24:43 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id e0f5105993db47728ede90ddeee5c5f4; Tue, 02 Sep 2025 13:24: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: 3054f18c-8800-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1756819483; x=1757089483; bh=vJ/ShCaCXOV2bm+IUK0oG8GhcrkHPN6D2lP+VDOly90=; 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=PYdqb8FBrbW+5CF0q3dOviPb9fAm7Odfx13FaZ9r9bRxeBhsf7Yxt6O196zbqVxk6 feNlpVQxH/teIl/o7QqTA4F0x584M6a+5vBFMr+A5Op50e4utMmhORT8AtIsDPI4T6 Ztpg7U2GZ7wvParAY+Abv0KsaF8sDFnRXU6kPGBj4yYxM5nPTwquYl1kNfP5LV2Txa ShwgTNBtyQimrU62lWT97Y5ZYAimeGk5OssNRLwDI3XYj0M1imWZJS0oBnGD0gqjKT HmSBRdCU6I/R9jx6gLVOiU+rUi+oQwXaGc4NhZZYMUy4u7V6ZZlldNLPLKboTsk2cC C7WEn0YSiY2oQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1756819483; x=1757079983; i=teddy.astie@vates.tech; bh=vJ/ShCaCXOV2bm+IUK0oG8GhcrkHPN6D2lP+VDOly90=; 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=bLQl+39lpOxl06ZKOTJRO9Gu+vzqQMEmRrpHaf6I+lfX2Y1LU0f1IB2fBtFh41jKm tHCQnJz5WPvNwtqdBeFvDDhkD3JpOqNA4+wJkXkr/0v94OPOmUt5ULArZXiamNvoZL OIRANyB+gpjRu4KG2AtQ9wZIYpf+/rCW3NDZjdkkmcxf4rvoJtw8yc+gT75E1Ziw+R 6pVTY7VF1BFXPzNLQDqF394YtSPSWLgtdjBe5a8ULVEVTUm19At/Q1k9BwOEqzDGLa HLYj7Z9MNvKbaSKOLH8pOIa1Z/WxrIkHgxvEsikQpW/IlwAubP+o49Tn0XziJS7k42 Zsdz50oMQ9A5g== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RESEND=20PATCH=20v2=202/3]=20hvmloader:=20Update=20to=20SMBIOS=202.6?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1756819482291 Message-Id: To: "Jan Beulich" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , xen-devel@lists.xenproject.org References: <57c674cc364d3b8f4c6d03533b9e2b45728d2c19.1756460430.git.teddy.astie@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.e0f5105993db47728ede90ddeee5c5f4?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250902:md Date: Tue, 02 Sep 2025 13:24:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 02/09/2025 =C3=A0 14:38, Jan Beulich a =C3=A9crit=C2=A0: > On 29.08.2025 11:58, Teddy Astie wrote: >> @@ -505,7 +505,22 @@ smbios_type_1_init(void *start, const char *xen_ver= sion, >> p->version_str =3D 3; >> p->serial_number_str =3D 4; >> >> - memcpy(p->uuid, uuid, 16); >> + /* >> + * Xen toolstack uses big endian UUIDs, however GUIDs (which requir= ement >> + * is clarified by SMBIOS >=3D 2.6) has the first 3 components appe= aring as >> + * being little endian and the rest as still being big endian. >> + */ > > The SMBIOS spec I'm looking at (2.7.1) doesn't mention the term GUID at a= ll > (except of course when discussing the EFI System Table entry). It's all U= UID > there. Here and in the description I think this needs expressing better, = to > not raise extra questions. > Yes (this is also true for SMBIOS 3.9.0 spec). Not sure how to express that aside saying that UUID encoding differs between SMBIOS specification and Xen representation. > As to endian-ness: Since everything from byte 8 onwards are merely bytes,= I > don't think it makes much sense to talk of endian-ness for that latter ha= lf. > It's more to insist that the byte ordering differs with the first parts. >> @@ -716,7 +731,7 @@ smbios_type_4_init( >> >> p->socket_designation_str =3D 1; >> p->processor_type =3D 0x03; /* CPU */ >> - p->processor_family =3D 0x01; /* other */ >> + p->processor_family =3D p->processor_family_2 =3D 0x01; /* other */ > > In the hypervisor we need to avoid such double assignments for Misra's > sake. I think we're better off avoiding them in hvmloader as well. > yes >> @@ -736,6 +751,22 @@ smbios_type_4_init( >> p->l2_cache_handle =3D 0xffff; /* No cache information structure p= rovided. */ >> p->l3_cache_handle =3D 0xffff; /* No cache information structure p= rovided. */ >> >> + /* >> + * We have a smbios type 4 table per vCPU (which is per socket), >> + * which means here that we have 1 socket per vCPU. >> + */ >> + p->core_count =3D p->core_enabled =3D p->thread_count =3D 1; > > Might we be better off keeping them all at 0 (unknown)? > Making it Unknown would feel a bit weird, unless we only keep only one (instead of the number of vCPUs) of these table with core_count, core_enabled, thread_count as 0 (unknown) ? >> + /* >> + * We set 64-bits, execute protection and enhanced virtualization. >> + * We don't set Multi-Core (bit 3) because this individual processo= r >> + * (as being a single vCPU) is only having one core. >> + * >> + * SMBIOS specification says that these bits don't state anything >> + * regarding the actual availability of such features. >> + */ >> + p->processor_characteristics =3D 0x64; > > Unless nested virt is enabled for the guest, I think we'd better avoid > setting the Enhanced Virtualization bit. > I am not sure how to interpret the SMBIOS spec on this > Enhanced Virtualization indicates that the processor can execute > enhanced virtualization instructions. This bit does not indicate the > present state of this feature I see it as: Virtualization is available or can be enabled (with nested virtualization). Or as : We have virtualization related instructions. >> @@ -870,8 +901,8 @@ smbios_type_17_init(void *start, uint32_t memory_siz= e_mb, int instance) >> char buf[16]; >> struct smbios_type_17 *p =3D start; >> >> - /* Specification says Type 17 table has length of 1Bh for v2.3-2.6.= */ >> - BUILD_BUG_ON(sizeof(*p) !=3D 27); >> + /* Specification says Type 17 table has length of 1Ch for v2.6. */ >> + BUILD_BUG_ON(sizeof(*p) !=3D 28); >> >> memset(p, 0, sizeof(*p)); > > With this, ... > >> @@ -890,6 +921,7 @@ smbios_type_17_init(void *start, uint32_t memory_siz= e_mb, int instance) >> p->bank_locator_str =3D 0; >> p->memory_type =3D 0x07; /* RAM */ >> p->type_detail =3D 0; >> + p->attributes =3D 0; > > ... I don't think we really need this. In fact I was considering to make > a patch to strip all the unnecessary assignments of zero. > >> --- a/tools/firmware/hvmloader/smbios_types.h >> +++ b/tools/firmware/hvmloader/smbios_types.h >> @@ -147,6 +147,11 @@ struct smbios_type_4 { >> uint8_t serial_number_str; >> uint8_t asset_tag_str; >> uint8_t part_number_str; >> + uint8_t core_count; >> + uint8_t core_enabled; >> + uint8_t thread_count; >> + uint16_t processor_characteristics; >> + uint16_t processor_family_2; >> } __attribute__ ((packed)); >> >> /* SMBIOS type 7 - Cache Information */ >> @@ -185,6 +190,9 @@ struct smbios_type_9 { >> uint16_t slot_id; >> uint8_t slot_characteristics_1; >> uint8_t slot_characteristics_2; >> + uint16_t sgn_base; >> + uint8_t bus_number_base; >> + uint8_t devfn_base; > > Where do the _base suffixes come from? Nothing like that is said in the > spec I'm looking at. Also "sgn" is imo too much of an abbreviation. > My version of the specification (3.9.0) says 0Dh 2.6+ Segment Group Number (Base) 0Fh 2.6+ Bus Number (Base) 10h 2.6+ Device/Function Number (Base) Regarding sgn, maybe we can use `segment` instead ? > Jan > Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:25:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:25:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106473.1457147 (Exim 4.92) (envelope-from ) id 1utR0V-0006zx-D2; Tue, 02 Sep 2025 13:25:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106473.1457147; Tue, 02 Sep 2025 13:25: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 1utR0V-0006zq-A9; Tue, 02 Sep 2025 13:25:07 +0000 Received: by outflank-mailman (input) for mailman id 1106473; Tue, 02 Sep 2025 13:25: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 1utR0T-0006vk-OU for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:25:05 +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 3ca030e7-8800-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 15:25:04 +0200 (CEST) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3d19699240dso2213481f8f.1 for ; Tue, 02 Sep 2025 06:25:04 -0700 (PDT) Received: from [192.168.69.207] (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3cf270fbd01sm20127940f8f.13.2025.09.02.06.25.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 06:25: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: 3ca030e7-8800-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1756819504; x=1757424304; 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=rz/p6M0rklQHwfyQ6YvhjhFju5Y1e2Dz66wkkh69jUI=; b=m9d1JxIOb5EQzHvsteqdTQwT+fTMczljx8ym1B4Gyx1uFdSxaJIAiKfxiP1eyUhqMz JBqhse1dIb4ZkAYjgB5GJWUs3wYcHSjJeQXhu9Qw2yfNJ8J0uwMs0s0GttLbIlgnnWr2 mEYkiSVeZhOCYjExPyJsA47Yv06ANuGETHR2cF+7XMBI/WLiiTcfc9xQ/g6/eG9xPrM6 L1mdsbikFdiKrqs133xo+l5sm1ELZ7WfL6wxRegpYSXoknOkHNSeWgI+jcvm0mVYPm0x x/J0IvPSUyYELdHbvySCAAY3VPL1J5icB5WlZWeNgmvdI9X4HRX4YDxhBJdpG6Ox4oeU urow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756819504; x=1757424304; 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=rz/p6M0rklQHwfyQ6YvhjhFju5Y1e2Dz66wkkh69jUI=; b=v9n5GRHilZ4OIim6UOtbN1WCp1np8pKaldQyTuVrkqrpI9aArchfsvi+BaYfyTQQjx HxTsF5kvUaLIFaQNUSvl8b7UqhTSZuRh22snnn26zSz6nABshpfrVNr4+ZqhFJsktmcv 4mJCXoVt2JD6XvdKHR2gmsQ0Cu/e6cESIhmeBaGfnf+ho2474LbodeHXS1hE1HHHoHE6 pCaHcb1yoUrZ6XGZOWRPmT7FbmP07snghYcSCUU5zrCRTwzomUV87eb75FMbLV5AeI3N dMcdABZ12BnrUT4ougeIMOWSyXgG3ECkU6d+qHMtOrJ1smP+HIhEUPal4qmMd/P84Mz/ 0jXQ== X-Forwarded-Encrypted: i=1; AJvYcCXY+UfLT8e9zH+MpUaMzFddi6a+YWSI0B7LtxzYZ9c0Z9EZvgzkBnnVSqrnNomV8UQHNRUXvJWmUNE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQgU3RuCy4gClYa7HqpBN45R4JvAgenyvC8u+sp8xsgt5uIvZt jrY3vROjadS3cPEH2vNI6jrsWPTnaV1R7FNK0TA9ZHlC9pwE9jCs2WqPZ+klirBoQtc= X-Gm-Gg: ASbGnctq6XH4XwyuJBAdNm8Xw0EnLhFljvx0wiI+8wmo8AmA0GErEEXMmJYptx7/d36 2K+PSCx9BTRgbENldWJIFV7LMXCqYU/krsJFhS22b1ON4PVA7/8nk05kdeYL5prN/HrY+3pOJAn lzU2j4H9mcxft4vER9gI0OZF74WRLtDEidhg6VrrKu3z7O9NCvNXB5YgpZteugadC6SP7pSCNvw iwWEnQzDlR8kZ3bfEFQESr5ypK9LNT48HcnK0KStOW7zGsdp2BdsMQrxYz5zHFpRlAUILWrj9QK H6tzZiXCuLS7jXIaorqmT+309KWn6vABUsVFQZ64RrfCyiwk+4MPazQj0Vyo+JZfkUURMh/3OCW 7XCQhtoPp+7t+efaigeEfnPwg/I8/oBXXRo+b1T9mHiv+X7QJGNUD5kWsqhkd3vpFMeyYOWAkfE LV X-Google-Smtp-Source: AGHT+IEYmruxNHSN7LVlQ+61cQOiuO9GUpOJdI4vg0itRWRn52yE5aUCbQ+D5IlmMUWkcOPQ5loTdw== X-Received: by 2002:a5d:5712:0:b0:3dc:db:89f3 with SMTP id ffacd0b85a97d-3dc00db8a77mr46469f8f.16.1756819504134; Tue, 02 Sep 2025 06:25:04 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 15:25:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/7] accel: Add per-accelerator vCPUs queue To: qemu-devel@nongnu.org, Pierrick Bouvier Cc: Daniel Henrique Barboza , =?UTF-8?B?RnLDqWTDqXJpYyBCYXJyYXQ=?= , Stefano Stabellini , Ilya Leoshkevich , Cameron Esfahani , Paolo Bonzini , kvm@vger.kernel.org, Alexander Graf , Paul Durrant , David Hildenbrand , Halil Pasic , Marcel Apfelbaum , xen-devel@lists.xenproject.org, qemu-arm@nongnu.org, =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Yanan Wang , Reinoud Zandijk , Peter Maydell , qemu-s390x@nongnu.org, Riku Voipio , Anthony PERARD , Alistair Francis , Sunil Muthuswamy , Christian Borntraeger , Nicholas Piggin , Richard Henderson , Marcelo Tosatti , Thomas Huth , Roman Bolshakov , "Edgar E . Iglesias" , Zhao Liu , Phil Dennis-Jordan , David Woodhouse , Harsh Prateek Bora , Nina Schoetterl-Glausch , "Edgar E. Iglesias" , Eduardo Habkost , qemu-ppc@nongnu.org, Daniel Henrique Barboza , "Michael S. Tsirkin" , Anton Johansson , Salil Mehta References: <20250106200258.37008-1-philmd@linaro.org> Content-Language: en-US From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20250106200258.37008-1-philmd@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc'ing Pierrick & Salil. On 6/1/25 21:02, Philippe Mathieu-Daudé wrote: > Hi, > > Currently we register all vCPUs to the global 'cpus_queue' queue, > however we can not discriminate per accelerator or per target > architecture (which might happen in a soon future). > > This series tries to add an accelerator discriminator, so > accelerator specific code can iterate on its own vCPUs. This > is required to run a pair of HW + SW accelerators like the > (HVF, TCG) or (KVM, TCG) combinations. Otherwise, i.e. the > HVF core code could iterate on TCG vCPUs... > To keep it simple and not refactor heavily the code base, > we introduce the CPU_FOREACH_TCG/HVF/KVM() macros, only > defined for each accelerator. > > This is just a RFC to get some thoughts whether this is > heading in the correct direction or not ;) > > Regards, > > Phil. > > Philippe Mathieu-Daudé (7): > cpus: Restrict CPU_FOREACH_SAFE() to user emulation > cpus: Introduce AccelOpsClass::get_cpus_queue() > accel/tcg: Implement tcg_get_cpus_queue() > accel/tcg: Use CPU_FOREACH_TCG() > accel/hw: Implement hw_accel_get_cpus_queue() > accel/hvf: Use CPU_FOREACH_HVF() > accel/kvm: Use CPU_FOREACH_KVM() > > accel/tcg/tcg-accel-ops.h | 10 ++++++++++ > include/hw/core/cpu.h | 11 +++++++++++ > include/system/accel-ops.h | 6 ++++++ > include/system/hvf_int.h | 4 ++++ > include/system/hw_accel.h | 9 +++++++++ > include/system/kvm_int.h | 3 +++ > accel/accel-system.c | 8 ++++++++ > accel/hvf/hvf-accel-ops.c | 9 +++++---- > accel/kvm/kvm-accel-ops.c | 1 + > accel/kvm/kvm-all.c | 14 +++++++------- > accel/tcg/cputlb.c | 7 ++++--- > accel/tcg/monitor.c | 3 ++- > accel/tcg/tb-maint.c | 7 ++++--- > accel/tcg/tcg-accel-ops-rr.c | 10 +++++----- > accel/tcg/tcg-accel-ops.c | 16 ++++++++++++---- > accel/tcg/user-exec-stub.c | 5 +++++ > accel/xen/xen-all.c | 1 + > cpu-common.c | 10 ++++++++++ > hw/i386/kvm/clock.c | 3 ++- > hw/intc/spapr_xive_kvm.c | 5 +++-- > hw/intc/xics_kvm.c | 5 +++-- > system/cpus.c | 5 +++++ > target/arm/hvf/hvf.c | 4 ++-- > target/i386/kvm/kvm.c | 4 ++-- > target/i386/kvm/xen-emu.c | 2 +- > target/i386/nvmm/nvmm-accel-ops.c | 1 + > target/i386/whpx/whpx-accel-ops.c | 1 + > target/s390x/kvm/kvm.c | 2 +- > target/s390x/kvm/stsi-topology.c | 3 ++- > 29 files changed, 130 insertions(+), 39 deletions(-) > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:35:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:35:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106492.1457157 (Exim 4.92) (envelope-from ) id 1utRAs-0000VH-A7; Tue, 02 Sep 2025 13:35:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106492.1457157; Tue, 02 Sep 2025 13:35:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRAs-0000VA-71; Tue, 02 Sep 2025 13:35:50 +0000 Received: by outflank-mailman (input) for mailman id 1106492; Tue, 02 Sep 2025 13:35:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRAr-0000V4-2U for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:35:49 +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 bb422a5e-8801-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 15:35:46 +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 04AEF211A6; Tue, 2 Sep 2025 13:35: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 6A91813882; Tue, 2 Sep 2025 13:35: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 3kI9FrHytmiiXgAAD6G6ig (envelope-from ); Tue, 02 Sep 2025 13:35: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: bb422a5e-8801-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756820146; 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=RHjfEf1yPI2nOxhFxQiBgQrRwL1d1Gyt++yWH6Qw8eQ=; b=lvuL9bkqRLX1dlSy93w3AGmOV09etxe9fsZtu5Q4SeNfcAENDc3D1+dLNnLNRydpLBks1q qXzqbrCS21UoLgFr6ea0NrVam2muJCepahjJZn4O630OzsenbHFuCLR4sZxGOPE2VBCqfW KvnEZmcyhFTonQkOwBlDk5VUU9u0fik= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756820146; 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=RHjfEf1yPI2nOxhFxQiBgQrRwL1d1Gyt++yWH6Qw8eQ=; b=lvuL9bkqRLX1dlSy93w3AGmOV09etxe9fsZtu5Q4SeNfcAENDc3D1+dLNnLNRydpLBks1q qXzqbrCS21UoLgFr6ea0NrVam2muJCepahjJZn4O630OzsenbHFuCLR4sZxGOPE2VBCqfW KvnEZmcyhFTonQkOwBlDk5VUU9u0fik= Message-ID: Date: Tue, 2 Sep 2025 15:35:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] xen/events: Return -EEXIST for bound VIRQs To: Jason Andryuk , Stefano Stabellini , Oleksandr Tyshchenko Cc: stable@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20250828003604.8949-1-jason.andryuk@amd.com> <20250828003604.8949-3-jason.andryuk@amd.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20250828003604.8949-3-jason.andryuk@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mlryYWnr50GTxRvqV91tAT3H" X-Spam-Level: X-Spamd-Result: default: False [-5.20 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-0.992]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[amd.com:email,suse.com:email,suse.com:mid]; HAS_ATTACHMENT(0.00)[] X-Spam-Flag: NO X-Spam-Score: -5.20 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mlryYWnr50GTxRvqV91tAT3H Content-Type: multipart/mixed; boundary="------------fEpmfeuQilsqEH6fyNDmH5Z0"; protected-headers="v1" From: Juergen Gross To: Jason Andryuk , Stefano Stabellini , Oleksandr Tyshchenko Cc: stable@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Message-ID: Subject: Re: [PATCH v3 2/3] xen/events: Return -EEXIST for bound VIRQs References: <20250828003604.8949-1-jason.andryuk@amd.com> <20250828003604.8949-3-jason.andryuk@amd.com> In-Reply-To: <20250828003604.8949-3-jason.andryuk@amd.com> --------------fEpmfeuQilsqEH6fyNDmH5Z0 Content-Type: multipart/mixed; boundary="------------FhSdL1S6BZAPsb98FQA1Djo6" --------------FhSdL1S6BZAPsb98FQA1Djo6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjguMDguMjUgMDI6MzYsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IENoYW5nZSBmaW5k X3ZpcnEoKSB0byByZXR1cm4gLUVFWElTVCB3aGVuIGEgVklSUSBpcyBib3VuZCB0byBhDQo+ IGRpZmZlcmVudCBDUFUgdGhhbiB0aGUgb25lIHBhc3NlZCBpbi4gIFdpdGggdGhhdCwgcmVt b3ZlIHRoZSBCVUdfT04oKQ0KPiBmcm9tIGJpbmRfdmlycV90b19pcnEoKSB0byBwcm9wb2dh dGUgdGhlIGVycm9yIHVwd2FyZHMuDQo+IA0KPiBTb21lIFZJUlFzIGFyZSBwZXItY3B1LCBi dXQgb3RoZXJzIGFyZSBwZXItZG9tYWluIG9yIGdsb2JhbC4gIFRob3NlIG11c3QNCj4gYmUg Ym91bmQgdG8gQ1BVMCBhbmQgY2FuIHRoZW4gbWlncmF0ZSBlbHNld2hlcmUuICBUaGUgbG9v a3VwIGZvcg0KPiBwZXItZG9tYWluIGFuZCBnbG9iYWwgd2lsbCBwcm9iYWJseSBmYWlsIHdo ZW4gbWlncmF0ZWQgb2ZmIENQVSAwLA0KPiBlc3BlY2lhbGx5IHdoZW4gdGhlIGN1cnJlbnQg Q1BVIGlzIHRyYWNrZWQuICBUaGlzIG5vdyByZXR1cm5zIC1FRVhJU1QNCj4gaW5zdGVhZCBv ZiBCVUdfT04oKS4NCj4gDQo+IEEgc2Vjb25kIGNhbGwgdG8gYmluZCBhIHBlci1kb21haW4g b3IgZ2xvYmFsIFZJUlEgaXMgbm90IGV4cGVjdGVkLCBidXQNCj4gbWFrZSBpdCBub24tZmF0 YWwgdG8gYXZvaWQgdHJ5aW5nIHRvIGxvb2sgdXAgdGhlIGlycSwgc2luY2Ugd2UgZG9uJ3QN Cj4ga25vdyB3aGljaCBwZXJfY3B1KHZpcnFfdG9faXJxKSBpdCB3aWxsIGJlIGluLg0KPiAN Cj4gQ2M6IHN0YWJsZUB2Z2VyLmtlcm5lbC5vcmcNCj4gU2lnbmVkLW9mZi1ieTogSmFzb24g QW5kcnl1ayA8amFzb24uYW5kcnl1a0BhbWQuY29tPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdl biBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------FhSdL1S6BZAPsb98FQA1Djo6 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----- --------------FhSdL1S6BZAPsb98FQA1Djo6-- --------------fEpmfeuQilsqEH6fyNDmH5Z0-- --------------mlryYWnr50GTxRvqV91tAT3H 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/Ey8FAmi28rAFAwAAAAAACgkQsN6d1ii/Ey/8 fgf/Wr4ZBaXZlB5OWk0tjGGU8bWeBgNUC0e8dwe2Nzj4VFNVB8OAJkgoGDJXCS3RjF3X39PDZRTs wnjm+v1bqpmanzu1iTFfCOI+N4Jmui4P+lAasLCmn2r/5SeQhLj+9toE/mFjf9Wm9lj/I7XvuNJ5 NlgJA19/2HoGF4l9nf+oiS9P4dLLyTVP1YP7wfxZZmILx/+QlIH8pdHer5eLyRviuo5mJdDRlKJO h1d5s8sRSOn4xjSf3teqT01AXBwEcHAPG8vk7+qVyErpNiaR4hgv/eYwKEBqMxLl1ijgVperWas+ QIJ7u32LSuNIoVclofsD46AIeIr0BC5tkgZ1z9vHcg== =41aR -----END PGP SIGNATURE----- --------------mlryYWnr50GTxRvqV91tAT3H-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:37:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:37:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106505.1457167 (Exim 4.92) (envelope-from ) id 1utRC6-00015Q-O4; Tue, 02 Sep 2025 13:37:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106505.1457167; Tue, 02 Sep 2025 13: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 1utRC6-00015H-Ks; Tue, 02 Sep 2025 13:37:06 +0000 Received: by outflank-mailman (input) for mailman id 1106505; Tue, 02 Sep 2025 13: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 1utRC5-0000V4-9U for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:37:05 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e92a4880-8801-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 15:37:03 +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 283B3211A1; Tue, 2 Sep 2025 13:37: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 B61C213882; Tue, 2 Sep 2025 13:37:02 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id J0zdKf7ytmgGXwAAD6G6ig (envelope-from ); Tue, 02 Sep 2025 13:37: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: e92a4880-8801-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756820223; 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=SzeDgycto1XOoMcreGQSCS0wPlbWCFH7nGuPBL83p7U=; b=A28hkARLiL12iS5mPhCBk51miWvaaR0cOAv8NbqjkuPWahMeCehE0ODUwWQCSxil7MR8GO 7yAppSDUKfr6cOJ2m1QxNGX6GbUbNCLnlkekP7YV42aTjRMjWax6ndXzvo5hi4HxNaBZk3 fBPU2x7zyrslSQU5K7xHQqA74LU4TMs= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=A28hkARL DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1756820223; 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=SzeDgycto1XOoMcreGQSCS0wPlbWCFH7nGuPBL83p7U=; b=A28hkARLiL12iS5mPhCBk51miWvaaR0cOAv8NbqjkuPWahMeCehE0ODUwWQCSxil7MR8GO 7yAppSDUKfr6cOJ2m1QxNGX6GbUbNCLnlkekP7YV42aTjRMjWax6ndXzvo5hi4HxNaBZk3 fBPU2x7zyrslSQU5K7xHQqA74LU4TMs= Message-ID: Date: Tue, 2 Sep 2025 15:37:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/3] xen/events: Update virq_to_irq on migration To: Jason Andryuk , Stefano Stabellini , Oleksandr Tyshchenko , Jeremy Fitzhardinge , Chris Wright Cc: stable@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20250828003604.8949-1-jason.andryuk@amd.com> <20250828003604.8949-4-jason.andryuk@amd.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20250828003604.8949-4-jason.andryuk@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------3qXKDxEArtgBvx45yQgBsyqv" X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_ATTACHMENT(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_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[amd.com:email,suse.com:mid,suse.com:dkim,suse.com:email] X-Spam-Flag: NO X-Spam-Level: X-Rspamd-Queue-Id: 283B3211A1 X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -5.41 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3qXKDxEArtgBvx45yQgBsyqv Content-Type: multipart/mixed; boundary="------------XFxTLX7XzbIorwGI3WtEKT5w"; protected-headers="v1" From: Juergen Gross To: Jason Andryuk , Stefano Stabellini , Oleksandr Tyshchenko , Jeremy Fitzhardinge , Chris Wright Cc: stable@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Message-ID: Subject: Re: [PATCH v3 3/3] xen/events: Update virq_to_irq on migration References: <20250828003604.8949-1-jason.andryuk@amd.com> <20250828003604.8949-4-jason.andryuk@amd.com> In-Reply-To: <20250828003604.8949-4-jason.andryuk@amd.com> --------------XFxTLX7XzbIorwGI3WtEKT5w Content-Type: multipart/mixed; boundary="------------xZxaHUgdgWZCFnPgopKkQz49" --------------xZxaHUgdgWZCFnPgopKkQz49 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjguMDguMjUgMDI6MzYsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IFZJUlFzIGNvbWUg aW4gMyBmbGF2b3JzLCBwZXItVlBVLCBwZXItZG9tYWluLCBhbmQgZ2xvYmFsLCBhbmQgdGhl IFZJUlFzDQo+IGFyZSB0cmFja2VkIGluIHBlci1jcHUgdmlycV90b19pcnEgYXJyYXlzLg0K PiANCj4gUGVyLWRvbWFpbiBhbmQgZ2xvYmFsIFZJUlFzIG11c3QgYmUgYm91bmQgb24gQ1BV IDAsIGFuZA0KPiBiaW5kX3ZpcnFfdG9faXJxKCkgc2V0cyB0aGUgcGVyX2NwdSB2aXJxX3Rv X2lycSBhdCByZWdpc3RyYXRpb24gdGltZQ0KPiBMYXRlciwgdGhlIGludGVycnVwdCBjYW4g bWlncmF0ZSwgYW5kIGluZm8tPmNwdSBpcyB1cGRhdGVkLiAgV2hlbg0KPiBjYWxsaW5nIF9f dW5iaW5kX2Zyb21faXJxKCksIHRoZSBwZXItY3B1IHZpcnFfdG9faXJxIGlzIGNsZWFyZWQg Zm9yIGENCj4gZGlmZmVyZW50IGNwdS4gIElmIGJpbmRfdmlycV90b19pcnEoKSBpcyBjYWxs ZWQgYWdhaW4gd2l0aCBDUFUgMCwgdGhlDQo+IHN0YWxlIGlycSBpcyByZXR1cm5lZC4gIFRo ZXJlIHdvbid0IGJlIGFueSBpcnFfaW5mbyBmb3IgdGhlIGlycSwgc28NCj4gdGhpbmdzIGJy ZWFrLg0KPiANCj4gTWFrZSB4ZW5fcmViaW5kX2V2dGNobl90b19jcHUoKSB1cGRhdGUgdGhl IHBlcl9jcHUgdmlycV90b19pcnEgbWFwcGluZ3MNCj4gdG8ga2VlcCB0aGVtIHVwZGF0ZSB0 byBkYXRlIHdpdGggdGhlIGN1cnJlbnQgY3B1LiAgVGhpcyBlbnN1cmVzIHRoZQ0KPiBjb3Jy ZWN0IHZpcnFfdG9faXJxIGlzIGNsZWFyZWQgaW4gX191bmJpbmRfZnJvbV9pcnEoKS4NCj4g DQo+IEZpeGVzOiBlNDZjZGI2NmM4ZmMgKCJ4ZW46IGV2ZW50IGNoYW5uZWxzIikNCj4gQ2M6 IHN0YWJsZUB2Z2VyLmtlcm5lbC5vcmcNCj4gU2lnbmVkLW9mZi1ieTogSmFzb24gQW5kcnl1 ayA8amFzb24uYW5kcnl1a0BhbWQuY29tPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9z cyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------xZxaHUgdgWZCFnPgopKkQz49 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----- --------------xZxaHUgdgWZCFnPgopKkQz49-- --------------XFxTLX7XzbIorwGI3WtEKT5w-- --------------3qXKDxEArtgBvx45yQgBsyqv 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/Ey8FAmi28v4FAwAAAAAACgkQsN6d1ii/Ey84 9Qf6A2F3JG2SW93MO8A9bklox+jBDaxzI9DJ3S8LH0WNEkhBZm2cSa9LJ1pj50PBIIDLl2hPDBEB KHfFpAg/9FKBlyvLpmscDvIOL3vzZqLOqoIyqeHWWsSd9Z26XthnZedBT1K7FnhwUimzNvgd3992 GpCjox8Rs5k7baagpDjOx5owmBFLb/j7fADesYsWum1nAu747JXyazRoLF4Q84ofVrigkOICG8ut Jjk4HvgqfrSoycIsD2ZvQKYKTNv4SAN3xXHIVW+fhiXJQ7wgVQUc49csvdivpnFhuiYsOvdA8qan W6bmPbcur5rtdm6VCkE/gha9BwcT3kf4Up6xqTLEOQ== =6ykr -----END PGP SIGNATURE----- --------------3qXKDxEArtgBvx45yQgBsyqv-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:42:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:42:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106514.1457177 (Exim 4.92) (envelope-from ) id 1utRGs-0002mI-8G; Tue, 02 Sep 2025 13:42:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106514.1457177; Tue, 02 Sep 2025 13:42:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRGs-0002mB-5R; Tue, 02 Sep 2025 13:42:02 +0000 Received: by outflank-mailman (input) for mailman id 1106514; Tue, 02 Sep 2025 13:42: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 1utRGr-0002m5-Hk for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:42:01 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 99a2c2a7-8802-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 15:42:00 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582Dfwix012114 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 15:41:58 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582DfvRI021781; Tue, 2 Sep 2025 15:41:57 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id E2F0E107F7; Tue, 2 Sep 2025 15:41:55 +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: 99a2c2a7-8802-11f0-8adc-4578a1afcccb Date: Tue, 2 Sep 2025 15:41:55 +0200 From: Manuel Bouyer To: Juergen Gross Cc: Andrew Cooper , xen-devel@lists.xenproject.org Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 15:41:58 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: > > What puzzles me is that: > > > > - %cr2 is 0, so probably the first fault wasn't a page fault > > - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? > > > > Could it be the code has been moved to this location, or is about to > > be moved away afterwards? > > And indeed: from the full boot log I can see: > > (XEN) virt_base = 0x0 > (XEN) elf_paddr_offset = 0x0 > (XEN) virt_offset = 0x0 > (XEN) virt_kstart = 0x200000 > (XEN) virt_kend = 0x17bab90 > (XEN) virt_entry = 0x20e4d0 > > So virt_kentry is very near to the RIP. thanks to this, I think I found the issue: with Xen 4.18, the kernel is started with ebx=17bb018; with 4.20 it's 100018. The bootstrap code assumes that the kernel is after the kernel, and the kernel symbol table. That seems to be no longer true with Xen 4.20 and a PVH dom0 (but probably still true in all other cases). I can deal with that, but with the new layout how do I get the end of the symbol table ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:42:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:42:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106525.1457187 (Exim 4.92) (envelope-from ) id 1utRHX-0003Fs-FZ; Tue, 02 Sep 2025 13:42:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106525.1457187; Tue, 02 Sep 2025 13: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 1utRHX-0003Fl-Cf; Tue, 02 Sep 2025 13:42:43 +0000 Received: by outflank-mailman (input) for mailman id 1106525; Tue, 02 Sep 2025 13:42:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRHW-0003FX-K2 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:42:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utRHV-002uGB-1N; Tue, 02 Sep 2025 13:42:41 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utRHV-00D8iW-15; Tue, 02 Sep 2025 13:42: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=RQOBeHLl9PzNLflNgTIney80B2YgZ34VG3/X6iJD4OA=; b=2wfYSrZ+7O3W9Clhb/IDr3taxE SPeC6bOSc8sFWzGuI+XpE/qgu4fu0hvkEPql/TJCy1Rjg6m81Tokpnw6oz+8gXcV6vavUjuqVQpkg khGhJkElVlA19rBmPVpEXqpIIGFHkEVllhfdZp5eIAsTi/da7NH2xS+5TrZ4yUwkYaUY=; Message-ID: Date: Tue, 2 Sep 2025 14:42:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 06/12] xen/arm/irq: allow eSPI processing in the gic_interrupt function Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 29/08/2025 17:06, Leonid Komarianskyi wrote: > The gic_interrupt function is the main handler for processing IRQs. > Currently, due to restrictive checks, it does not process interrupt > numbers greater than 1019. This patch updates the condition to allow > the handling of interrupts from the eSPI range. > > Signed-off-by: Leonid Komarianskyi > Reviewed-by: Volodymyr Babchuk Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:53:11 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:53:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106537.1457197 (Exim 4.92) (envelope-from ) id 1utRRb-00058p-Cy; Tue, 02 Sep 2025 13:53:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106537.1457197; Tue, 02 Sep 2025 13:53:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRRb-00058i-9b; Tue, 02 Sep 2025 13:53:07 +0000 Received: by outflank-mailman (input) for mailman id 1106537; Tue, 02 Sep 2025 13:53:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRRa-00058c-Gn for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:53:06 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utRRZ-002uVn-2E; Tue, 02 Sep 2025 13:53:05 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utRRZ-00D9CB-2I; Tue, 02 Sep 2025 13:53: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" 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=kcTVl3o3jzR8FQXiFJgeLUrhxG1eraOx7KCpBZrkHzQ=; b=1PB7FwObzUEvRW2d32m8lUzexS dNKvCnuSbI/UOcq6/YkzklkxmFkeqckg0bfJq/fmUBv0V7tXg1QuFZzI8jdCiyQ5xeIdPrX1r8+qD 4Zx1mjRMw2sK3vqTy5GifDmJehCushtBBPbUSn9a3XzRKZQgrkfS7LAnRqj4lV/GUiYc=; Message-ID: <862df090-cbe2-44e9-8c7a-733f3bfd46ad@xen.org> Date: Tue, 2 Sep 2025 14:53:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <34b86693e1031a3ec786a38a0510f047c6c708da.1756481577.git.leonid_komarianskyi@epam.com> From: Julien Grall In-Reply-To: <34b86693e1031a3ec786a38a0510f047c6c708da.1756481577.git.leonid_komarianskyi@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 29/08/2025 17:06, Leonid Komarianskyi wrote: > To properly deactivate guest interrupts and allow them to be retriggered > after the initial trigger, the LR needs to be updated. The current Why guest specifically? Isn't the problem the same if a physical eSPI is routed to dom0? IOW, shouldn't the explaination be: "To properly deactivate physical eSPI routed to a domain and ..." > implementation ignores interrupts outside the range specified by the mask > 0x3FF, which only covers IRQ numbers up to 1023. To enable processing of > eSPI interrupts, this patch updates the mask to 0x13FF. > > Signed-off-by: Leonid Komarianskyi > Reviewed-by: Volodymyr Babchuk > > --- > Changes in V5: > - no changes > > Changes in V4: > - added reviewed-by from Volodymyr Babchuk > > Changes in V3: > - no changes > > Changes in V2: > - remove unnecessary CONFIG_GICV3_ESPI ifdef guard > --- > xen/arch/arm/include/asm/gic_v3_defs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h > index 3370b4cd52..e70c1a5675 100644 > --- a/xen/arch/arm/include/asm/gic_v3_defs.h > +++ b/xen/arch/arm/include/asm/gic_v3_defs.h > @@ -211,7 +211,7 @@ > #define ICH_LR_VIRTUAL_SHIFT 0 > #define ICH_LR_CPUID_MASK 0x7 > #define ICH_LR_CPUID_SHIFT 10 > -#define ICH_LR_PHYSICAL_MASK 0x3ff > +#define ICH_LR_PHYSICAL_MASK 0x13ff It took me a while to understand why we are using 0x13ff rather than 0x1fff. It is because eSPI range is 4096 - 5519. So in theory, it would be ok to just add '0x1000'. But I think this is more confusion that it is worth. So I would rather prefer if we use 0x1fff as this matches the specification. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:55:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:55:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106550.1457206 (Exim 4.92) (envelope-from ) id 1utRTj-0005gB-Rc; Tue, 02 Sep 2025 13:55:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106550.1457206; Tue, 02 Sep 2025 13:55: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 1utRTj-0005g4-Ov; Tue, 02 Sep 2025 13:55:19 +0000 Received: by outflank-mailman (input) for mailman id 1106550; Tue, 02 Sep 2025 13:55: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 1utRTi-0005fv-0b for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:55:18 +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 74223d1b-8804-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 15:55:16 +0200 (CEST) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b042cc39551so309891666b.0 for ; Tue, 02 Sep 2025 06:55: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 a640c23a62f3a-b0413782b94sm686669066b.35.2025.09.02.06.55.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 06:55: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: 74223d1b-8804-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756821315; x=1757426115; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/3668wISdCNXIO132PPwWE7rbS8MSARervAVnM57aFY=; b=Hi0rXo2nZsv/jyert0hiI36K0jZe4Xihrn0vJRKuW0Gui1hN3c+l8LVvz8yqaz5H4+ 4cV/+Xaxb/tUpnG+zu+A8vfua1x9w3lsOlnq2BiMTRmnSbsz4JzAeGn9Mlj1EwaEkQXr 9YM5DReZShslcxVmYj4cbQ3gtPN5pR5LnCk6X9hxgJT3VQxF+BxFJEeXkPCCPJF7KIJd 04D+KlO2F/FiTDgbuiXISFKUMllObdqsM5lVWaRAPVbKaPnJLO9B9bXlEo/AUxWeUTa3 nMmEpCHEFW1J+0cI3YY1jYZvLQgYn/QxzvcP3PjC9Ch9k/t2UNFqdGBJkFQInb9qKh3U GSJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756821315; x=1757426115; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/3668wISdCNXIO132PPwWE7rbS8MSARervAVnM57aFY=; b=A8r9UjgaBebKNKc3H+ksUBm7w7A4fEENpDBoOw7n0+WY/i7buGAnyBNUe+YYo8Ht3t nl0D6Pk/l2YAXGSaxGK/ikCPu0Oulc1F7A2urGxjU0lPDf5coce3by7NkjQflJeglOxO vFrCXRl8nTUDLFK0hlQBxUSj3COD3AxM8gItBH4CaQQdd/kqug4m0rHASlM1m1+9mmLs Ysucl1ihFgl522tMbz1dAM1wvwxM0EnfliYgSQBOM0J9DZQgQlPE29JRs/OEWc38mWle gybimWaCdZQhBRM1KwDRzomIwkqP86uM2caiG5UlgNH8cb9LwsDbTFwfM5a9PvrCsxqK I1ZQ== X-Forwarded-Encrypted: i=1; AJvYcCXqcYLVxUuJcn4gg31pmcOomgaw8EcDs04Y7YPY7+y7uBj9RB7/n+p+iaaDvDA8tEhp0/pLe6fS2ws=@lists.xenproject.org X-Gm-Message-State: AOJu0YyvNFRivbZI/pUkAI1zL/eyEg6kF7kgyQixOj0/to2RWvZdxIEe ckOfwilkw89s/BH6vkcFUyNVqk/nkNHRPHHcLzGH2GkO7Gm5EKNNdybr0lnsRbmuSg== X-Gm-Gg: ASbGnctFraqzjI8zBtsUkmQEG8Mf41yF2MN+M35SdRhLhMFF285ZQtAO/MHu9cVCqMM erA0ghuj70fyHZa3xnFYSvMl7J3xnxDtga0d4AknNi4osfyEPj04evga6BtW2D0ZV4PJcq6ezCl /CMHe6OYE89S4bBAIJ4ob4noFUaYv1o9iYQQ3Q3KfkhroiUPdDAamdciubeQpvZ4qOozrhZmyMH p6RVOlY1Gs2tN+ro9r9wK3NIDyMa1i4UTy2nDFuIPvyq0UBBHts/z6Rq3GQy7TQD19ozAaK71gs /qzHNoimnrDRUnQgw/wRSUy23ge4PJH/9Z8ZIkmob9rWWFtvP8mwlYdd9CadYJ28J03yWkZjqZh uckjTzKU0K7TrfAyLQTMYmT9ik/NDu1h9gta+V+DJC63TgR5ryycwFNhVVA5JvjN/lyIbQk/IED uB7U/ItZhOJi1WfbdPvg== X-Google-Smtp-Source: AGHT+IF9QDkVBnRtFt5jjzyMjbAHI4XouiD1dZ6Eh5tHSBeVSaMpw6tOQD5B7nyVWkqGh/VDITWPuQ== X-Received: by 2002:a17:907:d10:b0:afe:dc88:e65 with SMTP id a640c23a62f3a-b01d97400ffmr1278919066b.30.1756821315357; Tue, 02 Sep 2025 06:55:15 -0700 (PDT) Message-ID: <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@suse.com> Date: Tue, 2 Sep 2025 15:55:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@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.09.2025 15:41, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: >>> What puzzles me is that: >>> >>> - %cr2 is 0, so probably the first fault wasn't a page fault >>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? >>> >>> Could it be the code has been moved to this location, or is about to >>> be moved away afterwards? >> >> And indeed: from the full boot log I can see: >> >> (XEN) virt_base = 0x0 >> (XEN) elf_paddr_offset = 0x0 >> (XEN) virt_offset = 0x0 >> (XEN) virt_kstart = 0x200000 >> (XEN) virt_kend = 0x17bab90 >> (XEN) virt_entry = 0x20e4d0 >> >> So virt_kentry is very near to the RIP. > > thanks to this, I think I found the issue: > with Xen 4.18, the kernel is started with ebx=17bb018; with 4.20 it's > 100018. > > The bootstrap code assumes that the kernel is after the kernel, and the DYM "start info is after the kernel" or some such, seeing that that's what %ebx is about? > kernel symbol table. That seems to be no longer true with Xen 4.20 and a > PVH dom0 (but probably still true in all other cases). > > I can deal with that, but with the new layout how do I get the end of the > symbol table ? You'll need to handle that internally, I expect, perhaps from properties of your (ELF) binary. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 13:58:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 13:58:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106565.1457217 (Exim 4.92) (envelope-from ) id 1utRWR-0006Iy-DK; Tue, 02 Sep 2025 13:58:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106565.1457217; Tue, 02 Sep 2025 13:58:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRWR-0006Ir-AF; Tue, 02 Sep 2025 13:58:07 +0000 Received: by outflank-mailman (input) for mailman id 1106565; Tue, 02 Sep 2025 13:58:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRWQ-0006Il-Ok for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 13:58:06 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d8b7d70e-8804-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 15:58:04 +0200 (CEST) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-45b804ed966so17909955e9.2 for ; Tue, 02 Sep 2025 06:58:04 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d6cf485eb7sm9324065f8f.3.2025.09.02.06.58.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 06:58:03 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d8b7d70e-8804-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756821484; x=1757426284; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3ek1y9al2DZguhIYvsCvBZB3FqsxkmpgZmJHzBGcOgQ=; b=etMVtFpzlauYxtcvjrmsjSH0vOFMUJUmsq38BHlmZH1qO093H0T5mL73WorKWgev3r Fr/6X69TpPEEcMHiWdtm7+O27d9D8qra9SYsjz3uaGeKrTLkhuLteC7DK0TREHzH8//u J15WhjXM/JPDoFfSAl1UsTFqc3qyiDKKv3G/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756821484; x=1757426284; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3ek1y9al2DZguhIYvsCvBZB3FqsxkmpgZmJHzBGcOgQ=; b=KIna33FvV4WTKsGyNphvekczwwHa9IML/pqtNKBzkb0k4Lb2UGyYxUla8vG3MkaU7X dEVNurL1urlLEgE+2szah9xjrWz93kDTXoM12F8rXBzA5FAfmHg9rhOpbUGeDl/WhWx7 b78PUJambHO6GHw11IsLjdbThwnYTxmBIbUJ5pbveaUDXuLDVCZxzoJJXuNgXfq6BPBH Y/uh1EQtQM/abwb8DgEc2yOHbLBF9AMt6qw6xxQeiy7cX/+ptnspqTSJpBTgEnKm3ZQA MMyHGBfftIxioeO7I9Y4idS3W5Bg1AMnGf8CmFU9/ctNgT5t9xR6/+rxJTZB2kHABuJ7 ns9A== X-Gm-Message-State: AOJu0YzluylzcCW/Jg3S3WNE/fBaq+G7Rvnxl9/2/9BlLfD8gvZzfjDN gLpheaTR1j/v+OVam51OO/sde0Lm20aCCBT61Ivu3Sde1GczF3/PwiTffF4ufW1xGoM= X-Gm-Gg: ASbGnctNjrGMrHPAg6abKGWh2B03029nTc/xp7inFepcylTkuw9t502XBDjOKaMH7sE mwfwYANrjLenqRH3UB6txPKgdQQs/Lco30720BTmF7OBhZ8Yzhc7JZXa8r092oKUcWAqygTZb0s 3Ii+qBNuHtWS9czOnlbP129ygv3so/LZD9itNrDDotAC0vHG/V72IsbFPbEF+WYUCKkwWvCSawm f22p44u7Jm7Ldk0M8QRBhr/NvSWy3++2rcmhMt80qeUteFKnQ1fhSiWZkWdFGUXfjN0DoJbivnr 4nffQL6NDxcBCKlFJZfGnW/ZJqPDQ1RbT8Hrbj7gtN8Ut1U83z7T2jJNrcol+I7ZN1OIt+YzD+V 1YsHtbx5fbkEPRbVffAXUUi7mo9g7G690YWcHe97btefPT9UgLSt4Spu92PzErdWIoRJxw8urFH KF6PA= X-Google-Smtp-Source: AGHT+IFoAvGo536LZVpcDkyVeZyZFLfvz4UuJrZRJm1Rvw3vVhxsWZznkeq3xm0xhnlGcxaZnIgn7Q== X-Received: by 2002:a05:600c:3b19:b0:45b:9a46:69e9 with SMTP id 5b1f17b1804b1-45b9a466c97mr19900485e9.31.1756821484042; Tue, 02 Sep 2025 06:58:04 -0700 (PDT) Message-ID: <9f63274c-12d3-48a0-a53d-79e6106fbb53@citrix.com> Date: Tue, 2 Sep 2025 14:58:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer , Juergen Gross Cc: xen-devel@lists.xenproject.org References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@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 02/09/2025 2:41 pm, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: >>> What puzzles me is that: >>> >>> - %cr2 is 0, so probably the first fault wasn't a page fault >>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? >>> >>> Could it be the code has been moved to this location, or is about to >>> be moved away afterwards? >> And indeed: from the full boot log I can see: >> >> (XEN) virt_base = 0x0 >> (XEN) elf_paddr_offset = 0x0 >> (XEN) virt_offset = 0x0 >> (XEN) virt_kstart = 0x200000 >> (XEN) virt_kend = 0x17bab90 >> (XEN) virt_entry = 0x20e4d0 >> >> So virt_kentry is very near to the RIP. > thanks to this, I think I found the issue: > with Xen 4.18, the kernel is started with ebx=17bb018; with 4.20 it's > 100018. > > The bootstrap code assumes that the kernel is after the kernel, kernel after kernel? > and the > kernel symbol table. That seems to be no longer true with Xen 4.20 and a > PVH dom0 (but probably still true in all other cases). > > I can deal with that, but with the new layout how do I get the end of the > symbol table ? ebx points to the PVH info.  This is arbitrary, like multiboot info, and you shouldn't make assumptions about it's position relative to the other modules loaded. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:00:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:00:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106575.1457226 (Exim 4.92) (envelope-from ) id 1utRYW-0007rf-Pu; Tue, 02 Sep 2025 14:00:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106575.1457226; Tue, 02 Sep 2025 14: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 1utRYW-0007rY-NM; Tue, 02 Sep 2025 14:00:16 +0000 Received: by outflank-mailman (input) for mailman id 1106575; Tue, 02 Sep 2025 14:00: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 1utRYV-0007rQ-0X for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:00:15 +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 25165379-8805-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:00:13 +0200 (CEST) Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20) by PA3PR03MB10986.eurprd03.prod.outlook.com (2603:10a6:102:4b1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 14:00:07 +0000 Received: from AM9PR03MB7025.eurprd03.prod.outlook.com ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 14:00: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: 25165379-8805-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mmYtBpjo5bnDSBC39SHaefVtxAF/hIeh6zx9A06TuhHCSSLR28iaw/fRIC/3a9YrMh7SiVXabLxg0tI51GYmB2E6xlgNJWjh0qEhN5aDOrlSunuxlaz1CZz8RHqC3eeRw5DKQEr6BX+FIcUmhql2AZVWwCV1xL6fwNfr2wLV0v1WQFe0oLjG/k7hyXj97NZEwQyUA63QdDomutyJaOn8XP/5Nrkja41/pDbsf3bW10Z7gY3JLniuz6NAVIL8aQD4lIEHZtdgJge/5U/ps1Ljpkug6cxb25kgLkiWyMnF4poRtLku0D0jdbzv18m/SUVeC0OYAFPyKrRsEfTbG7Gvqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WKRwr53RkXkGRX1RJoB38hxDAO8hBpLydUe5unxQn8w=; b=X0aPgAsU5UwnQQBQ2FWrIgxjlmEKxqA5xM4WCBvua8gi5Rw0hf943mKyV0xwVh7TU4j4OjzwhEBrN7M0kjMZRij/pYb5LqGjrwa9j7tpGNZIdpPVpDqHKxq3vXvgiAnoOvkLWcRqjknyHtTg8Ppgw7FVqf5lIqGbm1gMolLsikuWxo9m+5QUpL9PFo7TgCwJ25XG8dxt18T2IfhkKULt6Tuxj2Aw1FLdaeMzusae6mCSi4b+KrJ0GkTKBrop1WJGybrFu+dsLdehgI8K4YUMT90xvEC4t22JMfGydHtzKg83Z9/J2fXzn09eLK5f/GdVCg3VcNLwrbDZ3+fl4G7XAQ== 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=WKRwr53RkXkGRX1RJoB38hxDAO8hBpLydUe5unxQn8w=; b=vnFU4se8kS6lMP56fxcwoqhyPOzJ9ubmYaxeyQ66jLGLaN1zXwOD3mf9QNam+RRdCY61KjgG5fA4WNCStnXmWBOgplGGjEDdrl09IchU+9QDauuRQMK3RoJnm0pBJFAUtf+MzrCVm48LMiDZgriwgFToIlLVt9I0S3KcsHLaC7dajm116hnuNVNtQ12T227Q684puK4dZhHXOhQuvnQ/QKTX/aGVh0J1Hp0hxaLDQ2w1jlMplBqDDSh2QuD+JbMchR3JslNPiUtdU0IO5w1Nq+O8wb/fUV2KpYgcJ0MJNZ7xkRNK7erzFZJ9HyJ9Oo7E92vLkJJ8N6MbqIM10BEmOA== From: Oleksandr Tyshchenko To: Julien Grall , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , "Orzel, Michal" , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Topic: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Index: AQHcG+7h2TGQQIBGXEebyEy6VBbgNLR/rhaAgAAaygCAAARKgIAAAqcAgAAcDQA= Date: Tue, 2 Sep 2025 14:00:04 +0000 Message-ID: <411d7b0f-01b8-46df-9bce-929eec366d2d@epam.com> References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> <319c280a-535d-498a-b0ab-93882663e23b@amd.com> <4e01ed71-cdbb-4d41-8845-33449b08494b@amd.com> <8af7ca62-2f05-47d9-8604-170e7a40d8a0@xen.org> In-Reply-To: <8af7ca62-2f05-47d9-8604-170e7a40d8a0@xen.org> Accept-Language: en-US, 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: AM9PR03MB7025:EE_|PA3PR03MB10986:EE_ x-ms-office365-filtering-correlation-id: 627a8e1c-a3ef-4869-3011-08ddea2904a2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|42112799006|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?bGpjTHBOdWJkWHpZSTRzQWM0TzBoZ2s5VWZUV2MwcENBUzdjYVRxb3czbTAr?= =?utf-8?B?enNnY2RpNU9idkhCbFBFZ29md2lORkNZczQ1Ui8zNWV2ZW5kYTgxeXB3MWc2?= =?utf-8?B?VkZtaWE0WFFHOERVWFY2ZWpqOVhRMmNvTlAybm5WcnB5OWxkaW5BZkc0VkxW?= =?utf-8?B?djZSKysweDNvNlI4bDFsL3Z5RUdBc1VLREgxKzMrQ2VzRkpKTjJaUlpIbTNK?= =?utf-8?B?WDFhNWlFYm9mbDhjR3lLdlY2a3hGNVcvOWRpK0NUKzFTUklXYjYyejl0dy9R?= =?utf-8?B?WncyakVxZ0pCc3VWTTdjQUFXSkZPZTh2ZzlvM3M1cWJ4L2VpMFFZakpoS2J1?= =?utf-8?B?VTdHVlozemRhQjBwQTVtWm1VMTk0QkUxL0IrRDVqY3czNTliRFlZYWw5SHJZ?= =?utf-8?B?RmgvL0x0M09EMHg5M2VCdDFxM3NCRmU3ak5sRlNrZTgrelJaOG5odmE3M0JG?= =?utf-8?B?MWUyamdqcU5OVTI5YTFPOEZndHl6Y1FNay9yZFZnTjhGYXYrYXFNOHdvK3hi?= =?utf-8?B?cHdNMWdUbjVFR1BDUkxhaGxlQmhSck5vcE92MndFa0ZvR0ttRmFpN05JTXow?= =?utf-8?B?Q0lLOTRSZVVhaGxtZjExK0U0QUU5Z2VIK0lIM2RneGJLOHVGdkNKRjAwUlBw?= =?utf-8?B?OW4zTlUzaDNjN3NRTkZGMlhoTUt0bTNjU3JkOHV5K0J4ekRTU3c0R1lDdEZF?= =?utf-8?B?YXZpMnRIWXBjUEs3Y0IzWEFSV3NZZG84cGhhU2pwVWJOTEZMQldud05mZW1r?= =?utf-8?B?SGZxbVNHNm80b0lzTW5lL0tja2RjVmNZVWQ1Wk5tVEFpYld4SGdQcFprZFZj?= =?utf-8?B?TVo3OXN0ZU1GYzlZZkVpTzFPK0pDTjV2eU9hNDkzU24wTWFhMnJCZ2Jrb05j?= =?utf-8?B?cTgzNll6bWE1Y2tMamVUZzhtaTNKZVF3RW1MMVY3dEVZMnpQc05EeSthSVlU?= =?utf-8?B?SG9POEl2dlArZHBXM1FpeHMzNUtKNGNaY2xnZ2RyR1E1QTV6V2pxQzZYUkVX?= =?utf-8?B?RWgrU015eG1Tc1FwL3Jxc2U2bVYzQUZTNVY4MVhjYk8vU0I2cmNSaU10THp0?= =?utf-8?B?RzBFNWNGNzk3dTQvUDdickRRR05CWFphQ3NSajZETzNjdktTdTVLSnRqempM?= =?utf-8?B?bEtzRDI5cTBKQ1BxQmUrbFh0UTRQN2NXdXpQY2xMUDJVR05oSTQ4andTV1Bi?= =?utf-8?B?Z3JzQ0Fud0hNYWgwQXB4YUlEMURUTEZPQzdFbnJWNWl6WVBUWGxLbDhCblFq?= =?utf-8?B?ZWhPc0p6T004aVNXeXd2VHF6Y0RsT0psTWY1bjcrV0RUc1ZOQVFTNytNdTN1?= =?utf-8?B?NVNlZ2R3NnVuQmI1V1ZKOEhUcXhNcU1rTk1aNnNWRnZBOWREajVReWlsZloy?= =?utf-8?B?V0dwUUFaNEdJOHFuUnVieDZ3bGEwaGtjTGhzN2l4a2x6MXJlTFplZTJtU05U?= =?utf-8?B?MTdFaTJzTkx4RmRJT0lVYVhmRUlNL2RiUmJFanVvMlNQTk5LTEhrTm9zS3px?= =?utf-8?B?STNrbjh2VGdFcXhZa3FRKzMwRUFnRXU5K1JMOHAweEIyRlIvck83WURsMmhk?= =?utf-8?B?YVMxeVh5SXovNDJRSHRoVTd2NG9vVW9tVms1Rjk4S1VwQUg3eUlKZHNybG9o?= =?utf-8?B?UDdqSDR5R0xKZTNiS0d2TVhUL01uRGZrSTVOeFRNZm4vTmVkTFZ1VjYzUUVi?= =?utf-8?B?QXZBcTFGYVBsbFpvOUxNcjJGUWdLSVlFbE5nL1ppRTBLUHV4a0o3YjF0NXdu?= =?utf-8?B?N0J0bE94cmovdTdQUzc0VTZrMzFuTGZkNW1MMnZPWmFHd0xGVU9qTVpBQ1VN?= =?utf-8?B?WmpyLzhndVh6ZXhmQzJoZmdaSzFaNHdnVGFvMys3NmlJWlY2SnVnNGRUOGxl?= =?utf-8?B?NXVDSHRBYTEyNGVPQXorekNpa0h5RjRzY3ZMbXp6dXpzenY1b1d1b3ZkdjhU?= =?utf-8?Q?Vg13mL9EcrI=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(42112799006)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NjhKTGxkTXV1bWRyQ2M3YXpTTUhFaTdLRnlZbU9YVVlDM1NPV21DV3gvQUpK?= =?utf-8?B?dmlYeHZzbW9FMXJ4MTRyaEpqRHhFVHduNEltSHBIdmtzVXRGdnRIeDFlRGlx?= =?utf-8?B?bFRZTUtPNUUvUXNaZ0dVV1UvZDFCYVJEVEdvU0psTHRhNzNsMDZvcWUrUVhl?= =?utf-8?B?WVpOWmFXZSs3b1NhYkZpSlcvUHh5NjlqT1p2Z21GZHh2bUdvN0M0SlRQV044?= =?utf-8?B?aW9tb3R1TEMvSW1ScnNpb3B0WEx0a205cWsvMkdIS01NKy9VR3M4NGFvbDBW?= =?utf-8?B?b3RPUzZjSkFvNkpGTXBTTnlnanlmcytwelV0bytOdU00S1dPeG5FVDlMSldX?= =?utf-8?B?SndYb2tWQVVSQkJHQ0tnclZJREd6UVpLakZkc0RnOFk4Tzd1NGR5bjdsd3BN?= =?utf-8?B?aTJlTjc1T0d3ZnJ1MmxZMFoxUHVPSll0L1NkTVRrSHJ5eG9XTmRYNlRUYXMw?= =?utf-8?B?WDFNRzd0UlBtNlh2UkxjSkkxWmd1U0NLOGF6aGRta1hKZko4c0RqWkcxQ1JI?= =?utf-8?B?Y05tVkVzQzV2LzdCSVltYzNmNU01cVM3bTJsYndvc3dGYmdEYTg2ekNxVHpZ?= =?utf-8?B?VEUrWE52bktLVTVRKzFVYnhQdDkyRUpoZ0x5aldFN3RCNzVmMC9CaHMySmVp?= =?utf-8?B?R1lRV2ZhZEV4YWhydlI3c3lOb3JOR1BaSkc3Mk53ams1WjZ6MEhtNE9BSHJy?= =?utf-8?B?LzRuTnd2MVpLTWxPSTRyaC9RblkvSkM4Ui93eUMyaXA4TXlpS0JPWjNXLzBI?= =?utf-8?B?M1AvTkhjYnN2QkhoVzZaMUg2VS9CU2RIbS9rVnM0bnpxd1RPZW5heHZva2hO?= =?utf-8?B?N0h4R044SjkzWXQvVFBzWFZJd3M5dlUrYnFpcDRwcTNkUXNydjdZbTVBYkpB?= =?utf-8?B?SXVMYWRSeC9RY2FnNFZ6OHo0amlsNXZ1a2N0N2RwdmtsUEl1MFhjUGU3dWNs?= =?utf-8?B?ZDJOVFBWeTBqM0RHNTREOVUycytWVjR5RU1PSnJKS1IrbUpBcXpwcWZOOUxV?= =?utf-8?B?SlN5ZHZaUXdLZktWM0NpcVZKUzJ6M3REOEJtQStRT1EzK0wvWFFTOFBrUEcv?= =?utf-8?B?TWh1V0VYdjBIODJZemJxVUJKNnZmR0wza0NzRy9aMG9vTHhOdVhpMjYxRVVw?= =?utf-8?B?enNaNzA0dGlheUtDRStBRFU1Zmd6S2grQStWWlBqWTdMbGtvUFZhY2NoM0pY?= =?utf-8?B?VE1ON0V5NnplcXZpZFowY25NTXpDU2grM1V2cVN3NExmMERWanN1WDNUNGtk?= =?utf-8?B?NERSQlY5RHRnTXJjY0h5ajI4YUJrZUs4UGthOHdrR1B5WGVnZVlPM2RNcFp2?= =?utf-8?B?VnFjWk9EblNkc3NWL09tdnZkUFhyaGxLZStoRUZvUXJ0cFlGcU0rN0xYUWNW?= =?utf-8?B?NG9VWDRaNGhtMnVUZXBIUmFlN0daK0dscURpZFlGYVJUTTIwdXhVdjdmZHBa?= =?utf-8?B?THBWREo3NkxTUS9lRkcrNDA4OHJXTW4xdml5OXMzaGdMbnB3d1FCazd1L2tJ?= =?utf-8?B?KzZLMnYxOUwxYjRVZncvOHJuaE5qMjdKd0xMc25VcmlsQUtmbG5CZ3M1UWJh?= =?utf-8?B?RDQ5S2NiNHppOUs4Tmh5bDRlb2ptSERJbFN0QTFZNGdKUDRESXdNM2E5MERs?= =?utf-8?B?M1VDMk1tNDBZNEt0T1A0WFRzaXpZck9HVGY5UjUxdUN3bTF6Ly9NYkY1RGV1?= =?utf-8?B?TnltcDRJVjB1bkNQN0pZaS9SWHJQYWt1VnNkaDdub05hL0s3WmFJbzBIRk9w?= =?utf-8?B?TVVsOElUazJSTDFXWGlzSVlmMGxOTU92emtxSGlvaEk5Mm4yZ0R5MTR5czRD?= =?utf-8?B?UmVlK0hWMGtwQTBOMDBZbjdEZnA0dnFHYmVuSDVGa0VQNTNDLzd0OEdXazlQ?= =?utf-8?B?ZGEvN0NlZG81Szc0Q1FjRkVSVHVRWjR1UlFhanB2WlFGbkNXN3FNUTFUb0NG?= =?utf-8?B?VE9iZ3VnTnc3K1JsOGl1M29xWDVtUllpNzZRSlVDenRiLzFDWGtuYktBS0l1?= =?utf-8?B?MWNUeWthVWpFTUlIZE80aks0dGE1aVRNS09ocGhuTXlTK1Ruakl0WnVyNXBp?= =?utf-8?B?c1lSYlkvc1prOFQ5N3JHZDNyOTZSVG9NL3RuUFF0WkJlTTZYczZ5SWVOc0wx?= =?utf-8?B?Y29KU1NCd1JGcGUzdUsrR3BHVW5uYVZjTVMvVGZQTDhqRUJGbGZVdy9Id252?= =?utf-8?Q?3y6KXRHqInKHlg3ePF3fJJ0=3D?= 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: AM9PR03MB7025.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 627a8e1c-a3ef-4869-3011-08ddea2904a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 14:00:04.8569 (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: Xut7Sf7pZ3ZaTrThr4U9f8ZE4vNXYkUGmEvf4r09WzLXZDj2pSPgph6KAdLcW+FanlDXO2dp/Y/vFtcFBmEgFVwdhz94dus6N5nT8CePxmM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA3PR03MB10986 DQoNCk9uIDAyLjA5LjI1IDE1OjE5LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQoNCkhlbGxvIEp1bGll bg0KDQo+IE9uIDAyLzA5LzIwMjUgMTM6MTAsIE9yemVsLCBNaWNoYWwgd3JvdGU6DQo+Pg0KPj4N Cj4+IE9uIDAyLzA5LzIwMjUgMTM6NTQsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+PiBIaSwNCj4+ Pg0KPj4+IE9uIDAyLzA5LzIwMjUgMTE6MTgsIE9yemVsLCBNaWNoYWwgd3JvdGU6DQo+Pj4+DQo+ Pj4+DQo+Pj4+IE9uIDAyLzA5LzIwMjUgMTE6NDksIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdyb3Rl Og0KPj4+Pj4gVGhlIHNhaWQgc3ViLW9wIGlzIG5vdCBzdXBwb3J0ZWQgb24gQXJtLCBzaW5jZSBp dDoNCj4+Pj4+IMKgwqAgLSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBidWZmZXJlZCBlbXVsYXRpb24g KHNvIGJ1ZmlvcmVxX3BvcnQvIA0KPj4+Pj4gYnVmaW9yZXFfZ2ZuDQo+Pj4+PiDCoMKgwqDCoCBj YW5ub3QgYmUgcmV0dXJuZWQpLCBwbGVhc2UgcmVmZXIgdG8gaW9yZXFfc2VydmVyX2NyZWF0ZSgp DQo+Pj4+PiDCoMKgIC0gZG9lcyBub3Qgc3VwcG9ydCAibGVnYWN5IiBtZWNoYW5pc20gb2YgbWFw cGluZyBJT1JFUSBTZXJ2ZXINCj4+Pj4+IMKgwqDCoMKgIG1hZ2ljIHBhZ2VzIChzbyBpb3JlcV9n Zm4vYnVmaW9yZXFfZ2ZuIGNhbm5vdCBiZSByZXR1cm5lZCksIA0KPj4+Pj4gcGxlYXNlDQo+Pj4+ PiDCoMKgwqDCoCByZWZlciB0byBhcmNoX2lvcmVxX3NlcnZlcl9tYXBfcGFnZXMoKS4gT24gQXJt LCBvbmx5IHRoZSBBY3F1aXJlDQo+Pj4+PiDCoMKgwqDCoCBSZXNvdXJjZSBpbmZyYXN0cnVjdHVy ZSBpcyB1c2VkIHRvIHF1ZXJ5IGFuZCBtYXAgdGhlIElPUkVRIA0KPj4+Pj4gU2VydmVyIHBhZ2Vz Lg0KPj4+Pj4NCj4+Pj4+IFNpZ25lZC1vZmYtYnk6IE9sZWtzYW5kciBUeXNoY2hlbmtvIDxvbGVr c2FuZHJfdHlzaGNoZW5rb0BlcGFtLmNvbT4NCj4+Pj4gUmV2aWV3ZWQtYnk6IE1pY2hhbCBPcnpl bCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQo+Pj4+DQo+Pj4+IENvdWxkIHdlIHBlcmhhcHMgYWRk IGEgRml4ZXMgdGFnIGhlcmUgcG9pbnRpbmcgdG8gdGhlIGNvbW1pdCANCj4+Pj4gaW50cm9kdWNp bmcgdGhlc2UNCj4+Pj4gRE0gb3BzIGFuZCB0aHVzIGFkZCB0aGlzIHBhdGNoIGZvciB0aGlzIHJl bGVhc2U/IE5vdCBzdXJlIHdoYXQgDQo+Pj4+IG90aGVycyB0aGluay4NCj4+Pg0KPj4+IEZpeGVz IHVzdWFsbHkgaW1wbGllcyBhIGJ1ZyBhbmQgSSBkb24ndCBzZWUgd2hhdCBidWcgd2UgYXJlIHNv bHZpbmcuIEluDQo+Pj4gZmFjdCwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBhcmUgdHJ5aW5n IHRvIHJlbW92ZSB0aGUgc3Vib3AuLi4NCj4+IEhtbSwgdGhlIGlzc3VlIGlzIHRoYXQgdGhlIHN1 Ym9wIHRoYXQgaXMgbm90IHN1cHBvcnRlZCBhdCB0aGUgbW9tZW50IA0KPj4gaXMgbGlzdGVkDQo+ PiBhcyBzdXBwb3J0ZWQgaW4gdGhlIHB1YmxpYyBoZWFkZXIuDQo+IA0KPiBbLi4uXQ0KPiANCj4+ IEFzIGZvciB0aGUgY29kZSwgZnJvbSBzYWZldHkgcGVyc3BlY3RpdmUgaWYgdGhpcyBzdWJvcCBp cyBsaXN0ZWQgDQo+PiBleHBsaWNpbHR5IGluIEFybSdzDQo+PiBkbS5jLCB3ZSB3b3VsZCBuZWVk IHRvIHdyaXRlIGEgc2VwYXJhdGUgdGVzdCBjYXNlIGFuZCB0ZXN0IHRvIGNvdmVyIGl0IA0KPj4g dGhhdCBhdA0KPj4gdGhlIGVuZCwgc3RpbGwgcmV0dXJucyAtRU9QTk9UU1VQUC4NCj4gDQo+IFdo eSBkbyB5b3UgdGhpbmsgaXQgaXMgbm90IHN1cHBvcnRlZD8gQUZBSUNULCBpdCBpcyBzdGlsbCBw b3NzaWJsZSB0byANCj4gcGFzcyBYRU5fRE1PUF9ub2duZnMgdG8gZmlndXJlIG91dCB3aHdldGhl ciBidWZpb3JlcSBpcyBjdXJyZW50bHkgDQo+IGF2YWlsYWJsZS4gVGhlIGVycm9yIGNvZGUgd291 bGQgYmUgMCBub3QgLUVPUE5PVFNVUFAuDQoNCg0KWWVzLCBieSBwYXNzaW5nIFhFTl9ETU9QX25v X2dmbnMgd2Ugd2lsbCBieXBhc3MgDQphcmNoX2lvcmVxX3NlcnZlcl9tYXBfcGFnZXMoKSBjYWxs LCBhbmQgeWVzLCBpb3JlcV9zZXJ2ZXJfZ2V0X2luZm8oKSANCndpbGwgcmV0dXJuIDAgaW4gdGhh dCBjYXNlLg0KDQpCdXQsICJidWZpb3JlcV9wb3J0IiBmaWVsZCBpbiBzdHJ1Y3QgeGVuX2RtX29w X2dldF9pb3JlcV9zZXJ2ZXJfaW5mbyANCihvdXQgcGFyYW0pIHdvbid0IGJlIHJlYWxseSB1cGRh dGVkIChzaW5jZSB0aGUgSU9SRVEgU2VydmVyIHdhcyBjcmVhdGVkIA0Kd2l0aCBIVk1fSU9SRVFT UlZfQlVGSU9SRVFfT0ZGIGJlZm9yZSB0aGF0KS4NCg0KU28sICJhdCB0aGUgbW9tZW50IiwgWEVO X0RNT1BfZ2V0X2lvcmVxX3NlcnZlcl9pbmZvIHN1Yi1vcCBpcyANCm5vbi1mdW5jdGlvbmFsL3Vz ZWxlc3Mgb24gQXJtICgidW5zdXBwb3J0ZWQiIGlzIHByb2JhYmx5IG5vdCBhIHByZWNpc2UgDQp3 b3JkIGluIHRoYXQgcGFydGljdWxhciBjYXNlKSwgdGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nICh3 aGljaCBtaWdodCBiZSANCndyb25nKS4gVGhhdCBpcyB3aHkgSSBoYXZlIHNlbnQgYSBwYXRjaCB0 byByZW1vdmUgdGhlIG1lbnRpb24gZnJvbSB0aGUgDQpwdWJsaWMgaGVhZGVyLg0KDQoNCj4gDQo+ ICA+IEkgdGhpbmsgaWYgd2UgbWlzdGFrZW5seSBtZW50aW9uIHN0aCBhcz4gc3VwcG9ydGVkIGlu IGUuZy4gU1VQUE9SVC5tZCANCj4gd2Ugd291bGQgaGF2ZSBubyBpc3N1ZXMgYWRkaW5nIGEgRml4 ZXMgdGFnLiBUaGVyZQ0KPiAgPiBhcmUgbWFueSBjYXNlcyB3aGVyZSBGaXhlcyB3YXMgdXNlZCBq dXN0IHRvIGNoYW5nZSBzb21ldGhpbmcgaW4gYSANCj4gY29tbWVudCwgc28NCj4gID4gSSdtIGhh dmluZyBhIGhhcmQgdGltZSByZWFzb25pbmcgYWJvdXQgd2hlbiBpdCdzIGFwcHJvcHJpYXRlIHRv IHVzZSBpdC4NCj4gSSB0aGluayB3aGF0IHdlIHdvdWxkIHdhbnQgaXMgIkFtZW5kcyIuIFRoaXMg aXMgY3VycmVudGx5IHByb3Bvc2VkIGJ5IFsxXS4NCg0KR29vZCBwb2ludC4NCg0KDQo+IA0KPiBb MV0gaHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/IA0KPiB1 cmw9aHR0cHMlM0ElMkYlMkZsb3JlLmtlcm5lbC5vcmclMkZ4ZW4tZGV2ZWwlMkZlN2M5OTExNi1m NmE5LTQzZTEtODBhZS0gDQo+IGIzYTRkNDQ4NTdiNyU0MGFtZC5jb20lMkZUJTJGJTIzdCZkYXRh PTA1JTdDMDIlN0NPbGVrc2FuZHJfVHlzaGNoZW5rbyU0MGVwYW0uY29tJTdDMjcwMjQ5MDJiMTRj NDJiN2VhZjYwOGRkZWExYjAxNzMlN0NiNDFiNzJkMDRlOWY0YzI2OGE2OWY5NDlmMzY3YzkxZCU3 QzElN0MwJTdDNjM4OTI0MTIzOTM0ODM1OTU3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SkZi WEIwZVUxaGNHa2lPblJ5ZFdVc0lsWWlPaUl3TGpBdU1EQXdNQ0lzSWxBaU9pSlhhVzR6TWlJc0lr Rk9Jam9pVFdGcGJDSXNJbGRVSWpveWZRJTNEJTNEJTdDMCU3QyU3QyU3QyZzZGF0YT03bzFDcE5r WFB4SFFxcW5XQlBFVXkxUTElMkJqTCUyRk03Vm1Uck1UN2ZPdTRMdyUzRCZyZXNlcnZlZD0wDQo+ IA0KPj4NCj4+IH5NaWNoYWwNCj4+DQo+IA0K From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:07:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:07:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106586.1457237 (Exim 4.92) (envelope-from ) id 1utRf6-0000Oi-Hd; Tue, 02 Sep 2025 14:07:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106586.1457237; Tue, 02 Sep 2025 14:07: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 1utRf6-0000Ob-Do; Tue, 02 Sep 2025 14:07:04 +0000 Received: by outflank-mailman (input) for mailman id 1106586; Tue, 02 Sep 2025 14:07: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 1utRf4-0000OV-T3 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:07:02 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 184df15f-8806-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:07:01 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582E6xxK012688 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 16:06:59 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582E6wXX006653; Tue, 2 Sep 2025 16:06:58 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 75957107F7; Tue, 2 Sep 2025 16:06: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: 184df15f-8806-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 16:06:57 +0200 From: Manuel Bouyer To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 16:06:59 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 03:55:14PM +0200, Jan Beulich wrote: > On 02.09.2025 15:41, Manuel Bouyer wrote: > > On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: > >>> What puzzles me is that: > >>> > >>> - %cr2 is 0, so probably the first fault wasn't a page fault > >>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? > >>> > >>> Could it be the code has been moved to this location, or is about to > >>> be moved away afterwards? > >> > >> And indeed: from the full boot log I can see: > >> > >> (XEN) virt_base = 0x0 > >> (XEN) elf_paddr_offset = 0x0 > >> (XEN) virt_offset = 0x0 > >> (XEN) virt_kstart = 0x200000 > >> (XEN) virt_kend = 0x17bab90 > >> (XEN) virt_entry = 0x20e4d0 > >> > >> So virt_kentry is very near to the RIP. > > > > thanks to this, I think I found the issue: > > with Xen 4.18, the kernel is started with ebx=17bb018; with 4.20 it's > > 100018. > > > > The bootstrap code assumes that the kernel is after the kernel, and the > > DYM "start info is after the kernel" or some such, seeing that that's what > %ebx is about? yes, sorry > > > kernel symbol table. That seems to be no longer true with Xen 4.20 and a > > PVH dom0 (but probably still true in all other cases). > > > > I can deal with that, but with the new layout how do I get the end of the > > symbol table ? > > You'll need to handle that internally, I expect, perhaps from properties of > your (ELF) binary. But I don't have access to the ELF headers from the kernel binary (nor do I know which kernel was booted). Hum, maybe a I can hardcode this info in some const of the binary with a ld trick ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:10:08 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:10:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106597.1457248 (Exim 4.92) (envelope-from ) id 1utRi4-0001uT-3L; Tue, 02 Sep 2025 14:10:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106597.1457248; Tue, 02 Sep 2025 14:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRi3-0001ty-St; Tue, 02 Sep 2025 14:10:07 +0000 Received: by outflank-mailman (input) for mailman id 1106597; Tue, 02 Sep 2025 14:10: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 1utRi2-0001h2-9q for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:10: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 85f93664-8806-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:10:05 +0200 (CEST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b042ec947e4so331887866b.0 for ; Tue, 02 Sep 2025 07:10: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-aff032125e2sm1089009866b.77.2025.09.02.07.10.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 07:10: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: 85f93664-8806-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756822204; x=1757427004; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Zj0vxc2nvs0Ks97yPYXzgSqJCAe6jpruEwLP5raDuHk=; b=F1Mv6e2Fiig2O7WGaPyDT0itxzwMw4FRmzC3OA0ll/WvWQTIqQlp0xDcdIZxslPcy5 sbp0+sEFHeRIsujYqCTd+pu/D5yoGwO99wrPWaa8FP7GfIJJCSObAyEaR0WdNT/UeGEO jkmanWNXoZEJSlA+asBj2sqx9BO54xxxfoaujYj/bdqnFSJwEaW7gsy/Kj9b1cqM8clE GVvpSuDLOZCIYG6wid0QJmB87c0wd5L5+D8ob/In+ZJQRx7JlQ8bRvajdUft5i2L4eKP jEizLCoigHU7v1IkKap5Mhz0UH3+wX4ZymywmzOAd0raqYKpzHtg6IQGTqydjO3s9h6v LMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756822204; x=1757427004; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Zj0vxc2nvs0Ks97yPYXzgSqJCAe6jpruEwLP5raDuHk=; b=pbfyQ2R1TKXptyznjYDWBdPwmFQMK3EgMb7KZ9aN05Xhjg9zlyihyboatGMNlmEfAJ 01/1xqR4nVP1tHwCK5dXzgMNfVMooInFof3LsKlRjjuAxpl+HVweGOx0LHPrZz9ir6+P PkXkjAhwYZgHrTlIcfrUfAQG27AvdGVhtWazl4x0Kz+MriaZMxHyOthevdrO7RvYD3ZR TLDScBTluLIVTL3wgO2aGWWUQXhQFC8icMRFEkhGFDDPnrWvoH5u3xN71UKr0zwBYM3E Ds5G3HzeKe2fb4FDeTI8pcvxrcnpeqBxuCect2Ss0MKRVGrdo4xRHm/gliO26KPq5t9S ah0g== X-Forwarded-Encrypted: i=1; AJvYcCUMCsmg5poVDNYyY0ncnnL93qWB5g7mtte05tN9Zdu1/CIhVeBUCxbIFfyMYfGTrDDUVuzJ4+J9u9Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YzEvxf7PdqHWKyLbS0w5Q7yinRsRfndJ5rn09DRcUmIJb5l4owo G2iDw4nBdhEhw/RRIklpMkQf/HQxO2Aws9yZKddXF/2fQiHBb1TDh0K5kK6mGVESkw== X-Gm-Gg: ASbGncsIT0t6ningy0QEZ6i58b5rQGpDL77PWRrUAzSY9oqJPpi8la+q2vZPKNoHfy0 SbWW+ye7y9T1v7B2RlSkX7olkR+bw5Yj+DaJLJw+H6EYUIejeTVNS14tlkptcIVnuSvtQ5Cpijk ltwnpdrRqt/JJG/UPwlnM7z5KCPIKI/HsFR0khRaVbYOKWHragVJ95pejFfLh92R2OD52rgwLDw acn7dFQaCDOTDWGdzdYPRh/kbycdHOK/gG7oLbjNJKni1GJEwVXGQyGGJWOeu++3eJ+k2STFbrN kJ89O27SBbwhgK6zGQv6jFlSYdxouzsC0ayPdBsW9dicojlOP+wRf+F27P87x1u94BTdOfExuLH XifNDYSxN+lGPzMC83n/+oRCci0HDkB8sm9wiJDa4zLoG+1T29Co8Qoju8mj0N590fwb1SfI3Ku BySn2zicuAxUWSump5ww== X-Google-Smtp-Source: AGHT+IEdHfoX1/iDcybcHK4Xjvi0Ze2xs4kj+5+L1g5O+LnyiTRClXRAlIodliGRd3nHXB9v+NbF2A== X-Received: by 2002:a17:907:948a:b0:afe:b2be:6109 with SMTP id a640c23a62f3a-b01f20cc03emr907726466b.59.1756822204141; Tue, 02 Sep 2025 07:10:04 -0700 (PDT) Message-ID: <0190dbe1-4583-49c1-86c1-9bcb57844315@suse.com> Date: Tue, 2 Sep 2025 16:10:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 2/3] hvmloader: Update to SMBIOS 2.6 To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <57c674cc364d3b8f4c6d03533b9e2b45728d2c19.1756460430.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.09.2025 15:24, Teddy Astie wrote: > Le 02/09/2025 à 14:38, Jan Beulich a écrit : >> On 29.08.2025 11:58, Teddy Astie wrote: >>> @@ -505,7 +505,22 @@ smbios_type_1_init(void *start, const char *xen_version, >>> p->version_str = 3; >>> p->serial_number_str = 4; >>> >>> - memcpy(p->uuid, uuid, 16); >>> + /* >>> + * Xen toolstack uses big endian UUIDs, however GUIDs (which requirement >>> + * is clarified by SMBIOS >= 2.6) has the first 3 components appearing as >>> + * being little endian and the rest as still being big endian. >>> + */ >> >> The SMBIOS spec I'm looking at (2.7.1) doesn't mention the term GUID at all >> (except of course when discussing the EFI System Table entry). It's all UUID >> there. Here and in the description I think this needs expressing better, to >> not raise extra questions. > > Yes (this is also true for SMBIOS 3.9.0 spec). Not sure how to express > that aside saying that UUID encoding differs between SMBIOS > specification and Xen representation. Maybe /* * Xen toolstack uses big endian UUIDs, whereas the UUIDs used by SMBIOS, * also known as GUIDs, have the first 3 components appearing in little * endian (with this requirement clarified by SMBIOS >= 2.6). */ ? >>> @@ -736,6 +751,22 @@ smbios_type_4_init( >>> p->l2_cache_handle = 0xffff; /* No cache information structure provided. */ >>> p->l3_cache_handle = 0xffff; /* No cache information structure provided. */ >>> >>> + /* >>> + * We have a smbios type 4 table per vCPU (which is per socket), >>> + * which means here that we have 1 socket per vCPU. >>> + */ >>> + p->core_count = p->core_enabled = p->thread_count = 1; >> >> Might we be better off keeping them all at 0 (unknown)? > > Making it Unknown would feel a bit weird, unless we only keep only one > (instead of the number of vCPUs) of these table with core_count, > core_enabled, thread_count as 0 (unknown) ? I don't see how unknown or not is related to how many structure instances we surface. Your suggestion of using 1 in all three fields isn't quite what we'd like to present to guests. Once we sort virtual topology in Xen, we may want to expose sane values here. Yet if we expose 1-s now, that adjustment would need to happen in lock-step with the hypervisor changes. Whereas when we expose "unknown" that can be done at a convenient later time. >>> + /* >>> + * We set 64-bits, execute protection and enhanced virtualization. >>> + * We don't set Multi-Core (bit 3) because this individual processor >>> + * (as being a single vCPU) is only having one core. >>> + * >>> + * SMBIOS specification says that these bits don't state anything >>> + * regarding the actual availability of such features. >>> + */ >>> + p->processor_characteristics = 0x64; >> >> Unless nested virt is enabled for the guest, I think we'd better avoid >> setting the Enhanced Virtualization bit. > > I am not sure how to interpret the SMBIOS spec on this > > > Enhanced Virtualization indicates that the processor can execute > > enhanced virtualization instructions. This bit does not indicate the > > present state of this feature > > I see it as: Virtualization is available or can be enabled (with nested > virtualization). > Or as : We have virtualization related instructions. You want to view what we expose to the guest from the guest's perspective on its own little world, I think. >>> --- a/tools/firmware/hvmloader/smbios_types.h >>> +++ b/tools/firmware/hvmloader/smbios_types.h >>> @@ -147,6 +147,11 @@ struct smbios_type_4 { >>> uint8_t serial_number_str; >>> uint8_t asset_tag_str; >>> uint8_t part_number_str; >>> + uint8_t core_count; >>> + uint8_t core_enabled; >>> + uint8_t thread_count; >>> + uint16_t processor_characteristics; >>> + uint16_t processor_family_2; >>> } __attribute__ ((packed)); >>> >>> /* SMBIOS type 7 - Cache Information */ >>> @@ -185,6 +190,9 @@ struct smbios_type_9 { >>> uint16_t slot_id; >>> uint8_t slot_characteristics_1; >>> uint8_t slot_characteristics_2; >>> + uint16_t sgn_base; >>> + uint8_t bus_number_base; >>> + uint8_t devfn_base; >> >> Where do the _base suffixes come from? Nothing like that is said in the >> spec I'm looking at. Also "sgn" is imo too much of an abbreviation. >> > > My version of the specification (3.9.0) says > > 0Dh 2.6+ Segment Group Number (Base) > 0Fh 2.6+ Bus Number (Base) > 10h 2.6+ Device/Function Number (Base) Without any clarification what "(Base)" means, afaics. > Regarding sgn, maybe we can use `segment` instead ? Why not segment_group or seg_group (seeing how devfn also is an abbreviation)? And if we omit _number there and on devfn, it's hard to see why it shouldn't be just "bus" then as well. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:14:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:14:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106612.1457257 (Exim 4.92) (envelope-from ) id 1utRlq-0002ur-Jv; Tue, 02 Sep 2025 14:14:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106612.1457257; Tue, 02 Sep 2025 14:14:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRlq-0002uk-Gb; Tue, 02 Sep 2025 14:14:02 +0000 Received: by outflank-mailman (input) for mailman id 1106612; Tue, 02 Sep 2025 14:14:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRlp-0002uc-WE for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:14:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utRlp-002v4P-0f; Tue, 02 Sep 2025 14:14:01 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utRlp-00DA8y-09; Tue, 02 Sep 2025 14:14: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=5tu1LSOY3Kbt+gnMyCgXBKFFcZLyu+GvOiHMhJ+s2yE=; b=Q7SK1AceDogFOgSVo6yHyGcD2x /hAa/CO+hkLUCPWRFXOSIaZAn5WyT4iodRWW9rQdQuoyP/u6Y2gLor1lckdCalCLlWxCeb1HDVhkV vcOxFcvryLX4trk0e/MDIQYGjheaW7eHnoa4MrDzEDc4F2FWWV5iVfhNssvzcO8QZSB4=; Message-ID: <49e321c0-d23f-48f0-a979-add2a6bccb50@xen.org> Date: Tue, 2 Sep 2025 15:13:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <4b13dea924eabf1370d3f31030f3eef48371de06.1756481577.git.leonid_komarianskyi@epam.com> From: Julien Grall In-Reply-To: <4b13dea924eabf1370d3f31030f3eef48371de06.1756481577.git.leonid_komarianskyi@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Leonid, On 29/08/2025 17:06, Leonid Komarianskyi wrote: > This change introduces resource management in the VGIC to handle > extended SPIs introduced in GICv3.1. The pending_irqs and > allocated_irqs arrays are resized to support the required > number of eSPIs, based on what is supported by the hardware and > requested by the guest. A new field, ext_shared_irqs, is added > to the VGIC structure to store information about eSPIs, similar > to how shared_irqs is used for regular SPIs. > > Since the eSPI range starts at INTID 4096 and INTIDs between 1025 > and 4095 are reserved, helper macros are introduced to simplify the > transformation of indices and to enable easier access to eSPI-specific > resources. These changes prepare the VGIC for processing eSPIs as > required by future functionality. > > The initialization and deinitialization paths for vgic have been updated > to allocate and free these resources appropriately. Additionally, > updated handling of INTIDs greater than 1024, passed from the toolstack > during domain creation, and verification logic ensures only valid SPI or > eSPI INTIDs are used. > > The existing SPI behavior remains unaffected when guests do not request > eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI > option is disabled. > > Signed-off-by: Leonid Komarianskyi > > --- > Changes in V5: > - removed the has_espi field because it can be determined by checking > whether domain->arch.vgic.nr_espis is zero or not > - since vgic_ext_rank_offset is not used in this patch, it has been > moved to the appropriate patch in the patch series, which implements > vgic eSPI registers emulation and requires this function > - removed ifdefs for eSPI-specific macros to reduce the number of ifdefs > and code duplication in further changes > - fixed minor nit: used %pd for printing domain with its ID > > Changes in V4: > - added has_espi field to simplify determining whether a domain is able > to operate with eSPI > - fixed formatting issues and misspellings > > Changes in V3: > - fixed formatting for lines with more than 80 symbols > - introduced helper functions to be able to use stubs in case of > CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of > #ifdefs > - fixed checks for nr_spis in domain_vgic_init > - updated comment about nr_spis adjustments with dom0less mention > - moved comment with additional explanations before checks > - used unsigned int for indexes since they cannot be negative > - removed unnecessary parentheses > - move vgic_ext_rank_offset to the below ifdef guard, to reduce the > number of ifdefs > > Changes in V2: > - change is_espi_rank to is_valid_espi_rank to verify whether the array > element ext_shared_irqs exists. The previous version, is_espi_rank, > only checked if the rank index was less than the maximum possible eSPI > rank index, but this could potentially result in accessing a > non-existing array element. To address this, is_valid_espi_rank was > introduced, which ensures that the required eSPI rank exists > - move gic_number_espis to > xen/arm: gicv3: implement handling of GICv3.1 eSPI > - update vgic_is_valid_irq checks to allow operating with eSPIs > - remove redundant newline in vgic_allocate_virq > --- > xen/arch/arm/include/asm/vgic.h | 12 ++ > xen/arch/arm/vgic.c | 199 +++++++++++++++++++++++++++++++- > 2 files changed, 208 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h > index 3e7cbbb196..912d5b7694 100644 > --- a/xen/arch/arm/include/asm/vgic.h > +++ b/xen/arch/arm/include/asm/vgic.h > @@ -146,6 +146,10 @@ struct vgic_dist { > int nr_spis; /* Number of SPIs */ > unsigned long *allocated_irqs; /* bitmap of IRQs allocated */ > struct vgic_irq_rank *shared_irqs; > +#ifdef CONFIG_GICV3_ESPI > + struct vgic_irq_rank *ext_shared_irqs; > + int nr_espis; /* Number of extended SPIs */ For new code, we prefer using "unsigned int" when the value is meant to be >= 0. > +#endif > /* > * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in > * struct arch_vcpu. > @@ -243,6 +247,14 @@ struct vgic_ops { > /* Number of ranks of interrupt registers for a domain */ > #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32) > > +#ifdef CONFIG_GICV3_ESPI > +#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis+31)/32) > +#endif > +#define EXT_RANK_MIN (ESPI_BASE_INTID/32) > +#define EXT_RANK_MAX ((ESPI_MAX_INTID+31)/32) > +#define EXT_RANK_NUM2IDX(num) ((num)-EXT_RANK_MIN) > +#define EXT_RANK_IDX2NUM(idx) ((idx)+EXT_RANK_MIN) For the 6 lines above, please add space before and after the operators. > + > #define vgic_lock(v) spin_lock_irq(&(v)->domain->arch.vgic.lock) > #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock) > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index 2bbf4d99aa..c9b9528c66 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -27,9 +27,82 @@ > > bool vgic_is_valid_line(struct domain *d, unsigned int virq) > { > +#ifdef CONFIG_GICV3_ESPI > + if ( virq >= ESPI_BASE_INTID && > + virq < ESPI_IDX2INTID(d->arch.vgic.nr_espis) ) > + return true; > +#endif > + > return virq < vgic_num_irqs(d); > } > > +#ifdef CONFIG_GICV3_ESPI > +/* > + * Since eSPI indexes start from 4096 and numbers from 1024 to > + * 4095 are forbidden, we need to check both lower and upper > + * limits for ranks. > + */ > +static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank) > +{ > + return rank >= EXT_RANK_MIN && > + EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d); > +} > + > +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, > + unsigned int rank) > +{ > + return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]; > +} > + > +static inline bool vgic_reserve_espi_virq(struct domain *d, unsigned int virq) > +{ > + return !test_and_set_bit(ESPI_INTID2IDX(virq) + vgic_num_irqs(d), > + d->arch.vgic.allocated_irqs); > +} > + > +static void arch_move_espis(struct vcpu *v) > +{ > + const cpumask_t *cpu_mask = cpumask_of(v->processor); > + struct domain *d = v->domain; > + struct pending_irq *p; > + struct vcpu *v_target; cpu_mask, p and v_target only seems to be used within the loop. If that's correct, then please move the definition within the loop. > + unsigned int i; > + > + for ( i = ESPI_BASE_INTID; > + i < EXT_RANK_IDX2NUM(d->arch.vgic.nr_espis); i++ ) > + { > + v_target = vgic_get_target_vcpu(v, i); > + p = irq_to_pending(v_target, i); > + > + if ( v_target == v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) ) > + irq_set_affinity(p->desc, cpu_mask); > + } > +} > +#else > +static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank) > +{ > + return false; > +} > + > +/* > + * This function is stub and will not be called if CONFIG_GICV3_ESPI=n, > + * because in this case, is_valid_espi_rank will always return false. > + */ > +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, > + unsigned int rank) > +{ > + ASSERT_UNREACHABLE(); > + return NULL; > +} > + > +static inline bool vgic_reserve_espi_virq(struct domain *d, unsigned int virq) > +{ > + return false; > +} > + > +static void arch_move_espis(struct vcpu *v) { } > +#endif > + > static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, > unsigned int rank) > { > @@ -37,6 +110,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, > return v->arch.vgic.private_irqs; > else if ( rank <= DOMAIN_NR_RANKS(v->domain) ) > return &v->domain->arch.vgic.shared_irqs[rank - 1]; > + else if ( is_valid_espi_rank(v->domain, rank) ) > + return vgic_get_espi_rank(v, rank); > else > return NULL; > } > @@ -117,6 +192,62 @@ int domain_vgic_register(struct domain *d, unsigned int *mmio_count) > return 0; > } > > +#ifdef CONFIG_GICV3_ESPI > +static unsigned int vgic_num_spi_lines(struct domain *d) > +{ > + return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis; > +} > + > +static int init_vgic_espi(struct domain *d) > +{ > + unsigned int i, idx; > + > + if ( d->arch.vgic.nr_espis == 0 ) > + return 0; > + > + d->arch.vgic.ext_shared_irqs = > + xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d)); > + if ( d->arch.vgic.ext_shared_irqs == NULL ) > + return -ENOMEM; > + > + for ( i = d->arch.vgic.nr_spis, idx = 0; > + i < vgic_num_spi_lines(d); i++, idx++ ) > + vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i], > + ESPI_IDX2INTID(idx)); > + > + for ( i = 0; i < DOMAIN_NR_EXT_RANKS(d); i++ ) > + vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i], i, 0); > + > + return 0; > +} > + > +struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) > +{ > + irq = ESPI_INTID2IDX(irq) + d->arch.vgic.nr_spis; > + return &d->arch.vgic.pending_irqs[irq]; > +} > +#else > +static unsigned int init_vgic_espi(struct domain *d) > +{ > + return 0; > +} > + > +static unsigned int vgic_num_spi_lines(struct domain *d) > +{ > + return d->arch.vgic.nr_spis; > +} > + > +struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) > +{ > + return NULL; > +} > +#endif > + > +static unsigned int vgic_num_alloc_irqs(struct domain *d) > +{ > + return vgic_num_spi_lines(d) + NR_LOCAL_IRQS; > +} > + > int domain_vgic_init(struct domain *d, unsigned int nr_spis) > { > int i; > @@ -131,6 +262,36 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis) > */ > nr_spis = ROUNDUP(nr_spis, 32); > > +#ifdef CONFIG_GICV3_ESPI > + /* > + * During domain creation, the dom0less DomUs code or toolstack specifies > + * the maximum INTID, which is defined in the domain config subtracted by > + * 32 to cover the local IRQs (please see the comment to VGIC_DEF_NR_SPIS). > + * To compute the actual number of eSPI that will be usable for, > + * add back 32. > + */ > + if ( nr_spis + 32 > ESPI_IDX2INTID(NR_ESPI_IRQS) ) > + return -EINVAL; > + > + if ( nr_spis + 32 >= ESPI_BASE_INTID ) > + { > + d->arch.vgic.nr_espis = min(nr_spis - ESPI_BASE_INTID + 32, 1024U); We should return an error rather than silently capping the value. > + /* Verify if GIC HW can handle provided INTID */ > + if ( d->arch.vgic.nr_espis > gic_number_espis() ) > + return -EINVAL; > + /* > + * Set the maximum available number for regular > + * SPI to pass the next check > + */ I think it would be better to rework the code so the check is not called. > + nr_spis = VGIC_DEF_NR_SPIS; > + } > + else > + { > + /* Domain will use the regular SPI range */ > + d->arch.vgic.nr_espis = 0; > + } > +#endif > + > /* Limit the number of virtual SPIs supported to (1020 - 32) = 988 */ > if ( nr_spis > (1020 - NR_LOCAL_IRQS) ) > return -EINVAL; > @@ -145,7 +306,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis) > return -ENOMEM; > > d->arch.vgic.pending_irqs = > - xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis); > + xzalloc_array(struct pending_irq, vgic_num_spi_lines(d)); > if ( d->arch.vgic.pending_irqs == NULL ) > return -ENOMEM; > > @@ -156,12 +317,16 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis) > for ( i = 0; i < DOMAIN_NR_RANKS(d); i++ ) > vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0); > > + ret = init_vgic_espi(d); > + if ( ret ) > + return ret; > + > ret = d->arch.vgic.handler->domain_init(d); > if ( ret ) > return ret; > > d->arch.vgic.allocated_irqs = > - xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d))); > + xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d))); > if ( !d->arch.vgic.allocated_irqs ) > return -ENOMEM; > > @@ -195,9 +360,27 @@ void domain_vgic_free(struct domain *d) > } > } > > +#ifdef CONFIG_GICV3_ESPI > + for ( i = 0; i < d->arch.vgic.nr_espis; i++ ) Now we are potentially doubling up the number of IRQs we have to release. I am not entirely sure this is still ok to do it without any preemption. Do you have any data? > + { > + struct pending_irq *p = spi_to_pending(d, ESPI_IDX2INTID(i)); > + > + if ( p->desc ) > + { > + ret = release_guest_irq(d, p->irq); > + if ( ret ) > + dprintk(XENLOG_G_WARNING, "%pd: Failed to release virq %u ret = %d\n", > + d, p->irq, ret); > + } > + } > +#endif > + > if ( d->arch.vgic.handler ) > d->arch.vgic.handler->domain_free(d); > xfree(d->arch.vgic.shared_irqs); > +#ifdef CONFIG_GICV3_ESPI > + xfree(d->arch.vgic.ext_shared_irqs); > +#endif > xfree(d->arch.vgic.pending_irqs); > xfree(d->arch.vgic.allocated_irqs); > } > @@ -331,6 +514,8 @@ void arch_move_irqs(struct vcpu *v) > if ( v_target == v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) ) > irq_set_affinity(p->desc, cpu_mask); > } > + > + arch_move_espis(v); > } > > void vgic_disable_irqs(struct vcpu *v, uint32_t r, unsigned int n) > @@ -538,6 +723,8 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq) > n = &v->arch.vgic.pending_irqs[irq]; > else if ( is_lpi(irq) ) > n = v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq); > + else if ( is_espi(irq) ) > + n = espi_to_pending(v->domain, irq); > else > n = &v->domain->arch.vgic.pending_irqs[irq - 32]; > return n; > @@ -547,6 +734,9 @@ struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) > { > ASSERT(irq >= NR_LOCAL_IRQS); > > + if ( is_espi(irq) ) > + return espi_to_pending(d, irq); > + > return &d->arch.vgic.pending_irqs[irq - 32]; > } > > @@ -668,6 +858,9 @@ bool vgic_reserve_virq(struct domain *d, unsigned int virq) > if ( !vgic_is_valid_line(d, virq) ) > return false; > > + if ( is_espi(virq) ) > + return vgic_reserve_espi_virq(d, virq); > + > return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs); > } > > @@ -685,7 +878,7 @@ int vgic_allocate_virq(struct domain *d, bool spi) > else > { > first = 32; > - end = vgic_num_irqs(d); > + end = vgic_num_alloc_irqs(d); > } > > /* Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:23:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:23:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106625.1457267 (Exim 4.92) (envelope-from ) id 1utRv5-0004xe-Fd; Tue, 02 Sep 2025 14:23:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106625.1457267; Tue, 02 Sep 2025 14: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 1utRv5-0004xX-Cm; Tue, 02 Sep 2025 14:23:35 +0000 Received: by outflank-mailman (input) for mailman id 1106625; Tue, 02 Sep 2025 14:23:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utRv4-0004xR-OU for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:23:34 +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 670ed193-8808-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:23:33 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b0431c12df3so313417866b.1 for ; Tue, 02 Sep 2025 07:23:32 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0420a16c32sm596088066b.94.2025.09.02.07.23.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 07:23: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: 670ed193-8808-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756823011; x=1757427811; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ysU0qV/SJMt5Mw8eex5NgT9TFhTQ5X+hg0T4pDSCLw4=; b=AGb3eI8So53hPaA6xJbBCgMq+kfpR1Vx0zkkfaCJhfUa/ODy4wp8RBn0HJuIsMg6VX RP29NIzIdSM+C6fxOBfmnPDiYJ00MdTQuQ32gJNdyEruyBXbQzqN2B9sBXs8jDgoOCiy FkuZTgFmrc4WsiouBhcLCTESiuw1cdw1vQoD8Tk+GhuSOJMi8TwwZZWP2iPba4m92R87 G8wTT2FQ4dDoQx0JUS7DFlH9cOsfXWb2A+FzPo/gJO/53lAQhG/qAMgP0/I8rwF3cubc Y6URfthJQH8yAUzwPwryu3SUOgqAWCAnpAnD92FufqSHMoP37/4Q2FXDuPFuh5mFHGEn +q3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756823011; x=1757427811; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ysU0qV/SJMt5Mw8eex5NgT9TFhTQ5X+hg0T4pDSCLw4=; b=aM4Nlne940K7dxbZ+czgl64WZr79ea8wxNB5M3vbHeQBeRcuqXTeKnFQpRG4LnxlEm In5L691rakP1f4CDBFVG+tJeqn19TXKfhDQWYkZuD/YtP0tEAoo1kJeqDBjXt/hA93qs ynA+k70x3nZvh/uXIIsKIqCWn5VE3U9cqFMhJmEypSu7saPDi6FDNsGkiwYzHWS35PjE vXI8cNL22P/u7TJxaSvHzZ5rJJYc7i9KVOnbn7lF9H7LHJRp/x3eR5nyW8AySCHTixrV zQ4Gng7uWFsdCS6j5LWvrIGZocddjlQ3wdYdta1roJWwrL1IB6LTk9QCiV4j6vIma6Og thUQ== X-Forwarded-Encrypted: i=1; AJvYcCUAV5EyxHo2rJtsI6AMw1o3/Onl/h4EnK7Q29aGm6r/YfTSXpaanIhcuIDjf/xniP2/jSyf5L1SUXg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy/zIbb5uyYipaDOz8YNR35sGbcQuu5x5qVA+dHO1M/rSvGgN/4 PODHnYcLi7RxPj4VejgLY5dAB4gUrdIgwv0qtOyahRTrFdLO/FgXIgtJV2B2mhc4DQ== X-Gm-Gg: ASbGnctTAv8j2vIelSGoNMaZh/XMDX9zZlWt5jsTTaqdjyeNTnTtJ6nWLlvHpTix+h6 MMvLmFUqSJOE2fvcizxCeBzueEsFv+hoBMnIF1SRMwoLgXaC+n8KS4JGQgDsbb5akW7tPtga3LV DitUGNIvosAiWFkAZGaz2SZQZi4AhmLTpIyESNIFxdBB9TcU6dJKV/AhLUrJyw0DuOtsPh4Z6py G2FDvj1j2KECxld+9kEE9f8GJaN/djZOgiISoRvbhmXCqw3Ds1FBJmqrLw3jfnwXREWa8q6JsOV oZjiCYkWZyeEN6c2GGqrgoQrHz/JiROJsDUA6PpEVdWbrzlep6QZcSTnXbE2Kt8mN2J7/KFj1zy vHYyavdkYuyR65df7/SiuwM6B0RuwtCzOQSkqNvO+UcduW2UYhVlB+6pcjIyn7VSc8pel+qYULn KQIA7TMgk= X-Google-Smtp-Source: AGHT+IH/++WGN670wvJiEuTzNp+g5Ph1N3D5WILlno8cbOAJ6o5/Sm3iHE1b2fFpTO7Tf1/TvEVdzw== X-Received: by 2002:a17:907:1c19:b0:b04:522c:e113 with SMTP id a640c23a62f3a-b04522d1ce2mr233087666b.53.1756823009898; Tue, 02 Sep 2025 07:23:29 -0700 (PDT) Message-ID: <49551fca-5059-4ca4-b551-d282d6099e36@suse.com> Date: Tue, 2 Sep 2025 16:23:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: issue with dom0_pvh on Xen 4.20 To: Manuel Bouyer Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@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.09.2025 16:06, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 03:55:14PM +0200, Jan Beulich wrote: >> On 02.09.2025 15:41, Manuel Bouyer wrote: >>> On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: >>>>> What puzzles me is that: >>>>> >>>>> - %cr2 is 0, so probably the first fault wasn't a page fault >>>>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? >>>>> >>>>> Could it be the code has been moved to this location, or is about to >>>>> be moved away afterwards? >>>> >>>> And indeed: from the full boot log I can see: >>>> >>>> (XEN) virt_base = 0x0 >>>> (XEN) elf_paddr_offset = 0x0 >>>> (XEN) virt_offset = 0x0 >>>> (XEN) virt_kstart = 0x200000 >>>> (XEN) virt_kend = 0x17bab90 >>>> (XEN) virt_entry = 0x20e4d0 >>>> >>>> So virt_kentry is very near to the RIP. >>> >>> thanks to this, I think I found the issue: >>> with Xen 4.18, the kernel is started with ebx=17bb018; with 4.20 it's >>> 100018. >>> >>> The bootstrap code assumes that the kernel is after the kernel, and the >> >> DYM "start info is after the kernel" or some such, seeing that that's what >> %ebx is about? > > yes, sorry > >>> kernel symbol table. That seems to be no longer true with Xen 4.20 and a >>> PVH dom0 (but probably still true in all other cases). >>> >>> I can deal with that, but with the new layout how do I get the end of the >>> symbol table ? >> >> You'll need to handle that internally, I expect, perhaps from properties of >> your (ELF) binary. > > But I don't have access to the ELF headers from the kernel binary (nor do I > know which kernel was booted). > > Hum, maybe a I can hardcode this info in some const of the binary with a > ld trick ? For the symbol table to be loaded, it needs to live in some loadable section. You should be able to mark that section's end (or the end of the symbol table in the section, in case there's more stuff there) with a symbol in the linker script (which I assume you use). If you used the GNU toolchain, you could also consider using the assembler's .startof. / .sizeof. operators (producing symbols that the linker then recognizes and resolves accordingly). Or wait - are you perhaps using the thing we call "bsd_symtab" in our libelf? Then, as per the scheme in elf_load_bsdsyms(), can't you find the start of the ELF header from the end of your kernel? At least that's how I understand it's supposed to work. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:28:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:28:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106638.1457277 (Exim 4.92) (envelope-from ) id 1utS0F-0005XT-4U; Tue, 02 Sep 2025 14:28:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106638.1457277; Tue, 02 Sep 2025 14:28:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS0F-0005XM-0c; Tue, 02 Sep 2025 14:28:55 +0000 Received: by outflank-mailman (input) for mailman id 1106638; Tue, 02 Sep 2025 14:28: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 1utS0E-0005XB-7E for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:28:54 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 20ff8d26-8809-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:28:44 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582ESgw4008511 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 16:28:42 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582ESfww029290; Tue, 2 Sep 2025 16:28:41 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 581B0107F7; Tue, 2 Sep 2025 16:28: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: 20ff8d26-8809-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 16:28:40 +0200 From: Manuel Bouyer To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@suse.com> <49551fca-5059-4ca4-b551-d282d6099e36@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49551fca-5059-4ca4-b551-d282d6099e36@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 16:28:42 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 04:23:28PM +0200, Jan Beulich wrote: > >>> kernel symbol table. That seems to be no longer true with Xen 4.20 and a > >>> PVH dom0 (but probably still true in all other cases). > >>> > >>> I can deal with that, but with the new layout how do I get the end of the > >>> symbol table ? > >> > >> You'll need to handle that internally, I expect, perhaps from properties of > >> your (ELF) binary. > > > > But I don't have access to the ELF headers from the kernel binary (nor do I > > know which kernel was booted). > > > > Hum, maybe a I can hardcode this info in some const of the binary with a > > ld trick ? > > For the symbol table to be loaded, it needs to live in some loadable section. > You should be able to mark that section's end (or the end of the symbol > table in the section, in case there's more stuff there) with a symbol in the > linker script (which I assume you use). If you used the GNU toolchain, you > could also consider using the assembler's .startof. / .sizeof. operators > (producing symbols that the linker then recognizes and resolves accordingly). > > Or wait - are you perhaps using the thing we call "bsd_symtab" in our libelf? yes, that's it. I'm looking at how it's loaded right now > Then, as per the scheme in elf_load_bsdsyms(), can't you find the start of > the ELF header from the end of your kernel? At least that's how I understand > it's supposed to work. I can, but at this point I can't easily call C code, and doing it in assembly doesn't look easy :( -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:32:52 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:32:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106653.1457286 (Exim 4.92) (envelope-from ) id 1utS42-0007Ha-Oq; Tue, 02 Sep 2025 14:32:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106653.1457286; Tue, 02 Sep 2025 14:32: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 1utS42-0007HT-Kw; Tue, 02 Sep 2025 14:32:50 +0000 Received: by outflank-mailman (input) for mailman id 1106653; Tue, 02 Sep 2025 14:32: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 1utS40-0007HN-PB for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:32:48 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b1aadc85-8809-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:32:46 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582EWj5e011669 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 16:32:45 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582EWjQ5027272; Tue, 2 Sep 2025 16:32:45 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 91481107F7; Tue, 2 Sep 2025 16:32:43 +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: b1aadc85-8809-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 16:32:43 +0200 From: Manuel Bouyer To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@suse.com> <49551fca-5059-4ca4-b551-d282d6099e36@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 16:32:45 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 04:28:40PM +0200, Manuel Bouyer wrote: > yes, that's it. I'm looking at how it's loaded right now > > > Then, as per the scheme in elf_load_bsdsyms(), can't you find the start of > > the ELF header from the end of your kernel? At least that's how I understand > > it's supposed to work. > > I can, but at this point I can't easily call C code, and doing it in > assembly doesn't look easy :( Oh, it looks like Xen stores the size just before the ELF header. if that's the case, all good ! -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:33:51 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:33:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106663.1457297 (Exim 4.92) (envelope-from ) id 1utS50-0007mv-4p; Tue, 02 Sep 2025 14:33:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106663.1457297; Tue, 02 Sep 2025 14:33:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS50-0007mo-15; Tue, 02 Sep 2025 14:33:50 +0000 Received: by outflank-mailman (input) for mailman id 1106663; Tue, 02 Sep 2025 14:33:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS4z-0007mg-C6 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:33:49 +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 d6597009-8809-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:33:48 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-afcb7ae31caso1051865166b.3 for ; Tue, 02 Sep 2025 07:33: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 a640c23a62f3a-aff12a6b404sm975059566b.88.2025.09.02.07.33.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 07:33: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: d6597009-8809-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756823628; x=1757428428; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+Fug8TST8D1TGIze0YJXLCGZTFH16x6VDhPpDNaS5GA=; b=Vp9t9fUiVvynF+IPsYLmXlEnmsIgifWv/h2M+ERMjlPPq1pN1iJgyYjb4GYXM+nOg3 R69L6sNV3Ftf5bNHQa5HLXaikOUCuNVp1wtobkceGXIPRTo8XZNf/DLTCVwrtvdYuoDM 7mCB0TvsICZ2zNhE2O1gGfBAkMcIpwF+Sus0CsfTFz+5gVsTOB/D5EbpBw1t4Pq+BHyr Bg0tskYOxBMlzI27un4iPL6BZuvVtWwTmgFnQrKRFclZwzKH6tQzuU5LX7JQWgz6xnZb DXAVGhc5MTB0IRci6yv8uVRxyNJJ5n9Ce4cUkCMQbmrCfmfp7C1taakZ5Uk/aQCTHHLX SsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756823628; x=1757428428; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+Fug8TST8D1TGIze0YJXLCGZTFH16x6VDhPpDNaS5GA=; b=J3jajr/nDoADyEsBE8cony8UXkajrnjVo70D9Mo57XleHOACekyb2r4dsInvuRPAgc 0q/sZ7Dsm82aL02hiLswGLXTj4gETWKwSLaxiXr3jRllvG2w7WPB961pmlpaj3LF5HeP nVGWKmV9a69vHKE7joZnY2+u9mwj7zRsNSl9AwwqxNGG1SsCMYPo+xE14xSOkcKfgHRC //2IzXGmegMo+IUb2fOBLF9ziM3k2ohglP7x+Lx3nPACG6yszzZE/xK7Dz+QMq2f/Z6n w12kub1/d8EEfIHTE9li8k03mWrKuwLkD0QGh18hoUAWRXdf7x93iZeJREWUyZkeqIBT YXXg== X-Forwarded-Encrypted: i=1; AJvYcCVMrf0atuOL+eUqKEzyEUKcn60y/blLTykc9CA7kjTweZqdNyza5/dLeLYZesY0flUUVcidWupZnwk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz/kDnUlDn96YSNbkeOL7TgH0d/9PxbJnMFUyrKbG2dp0eR4hBk AO3xE6hLge0NX96LU+BiGQUE7PLJMcbw4w0mqMR4GzBrGWTTXnmPfM2PnQiGC1m85w== X-Gm-Gg: ASbGncs9MUVXte+jvj41CgRK/TVxRKQfMyNe9wURC4t6Z9KxS0dcYMX8TGPX1IrYlJB z3f23DTqsY8vKRGw+zqBk7VOB8swPhVikgut7QcBaicInWq2FlsvT2LCSjCG8T6boCpJby26iM5 FUQtgU3nZhyWik/QVDtvda5C/aABXU1EAXp0EDD2r7+1SF9ZIh//2j8f8Nexsvd8EIKNV4tqMZk 3wTBQWPJVh5iLhJwctCsklbLwWERI8Lyw/8Z/54iOYtc7dNiAAFYbmnuCo/NqpxfB3dA4mQzdyQ rMq+jQnMqxEw56DC0khhJSUBcDzJ71t9ddOWJY1BfR++ZqJViNTqKAuT+vvgKKskdAsTffLheWu Ro1Pv+8+S1Rf+WwEk1mFiJyBLvr6GeSJKDZiF/8dOrRQcSP7rN/Rhsw6N5lEPICRFAJK1mRbCjR X4Y3Qtk5s= X-Google-Smtp-Source: AGHT+IGNLUoN+KqW8GbR6aVbQ7MW+h6iZmzXY8vHeCqg4KX2US57BqpyJYxb5P+nrSRkdsXKEV137A== X-Received: by 2002:a17:907:3f26:b0:b04:4b0d:8e82 with SMTP id a640c23a62f3a-b044b0dc4c6mr294149166b.50.1756823627453; Tue, 02 Sep 2025 07:33:47 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 16:33:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 11/13] 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?= , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach , xen-devel@lists.xenproject.org References: <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.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: <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2025 00:10, Mykola Kvach wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -1317,7 +1317,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); I still don't follow why Arm-specific code needs to live here. If this can't be properly abstracted, then at the very least I'd expect some code comment here, or at the very, very least something in the description. >From looking at hwdom_shutdown() I get the impression that it doesn't expect to be called with SHUTDOWN_suspend, yet then the question is why we make it into domain_shutdown() with that reason code. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:36:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:36:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106677.1457307 (Exim 4.92) (envelope-from ) id 1utS7Q-0008L0-HV; Tue, 02 Sep 2025 14:36:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106677.1457307; Tue, 02 Sep 2025 14:36:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS7Q-0008Kt-Eh; Tue, 02 Sep 2025 14:36:20 +0000 Received: by outflank-mailman (input) for mailman id 1106677; Tue, 02 Sep 2025 14:36:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS7O-0008Kn-St for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:36:18 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utS7K-002vWc-1E; Tue, 02 Sep 2025 14:36:14 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utS7K-00DB6X-1H; Tue, 02 Sep 2025 14:36: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=TuzUObI3LBItJXyXZ1OioYm+qlsQl8xxeE5D0ZjfQxw=; b=IQVNW2TQgOehj0t26MDuot/lR7 N7+bFjMlMFhfnCEnfpPz3Vf5CWyhh8oarnTscgFjfO1V+jdHyxa4EnEPeKFk5pc1zAzeFXIxrPtvN yJ6ZU/0QJktCTC2jMcRMPfN+/jnH2Bvk5cb46Pbh1sOk6Wnvqx2TQhPQaJEtHZUpsidg=; Message-ID: <1b79fedd-582b-4ec0-aa85-d4ae100eba1d@xen.org> Date: Tue, 2 Sep 2025 15:36:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Content-Language: en-GB To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , "Orzel, Michal" , Bertrand Marquis , Volodymyr Babchuk References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> <319c280a-535d-498a-b0ab-93882663e23b@amd.com> <4e01ed71-cdbb-4d41-8845-33449b08494b@amd.com> <8af7ca62-2f05-47d9-8604-170e7a40d8a0@xen.org> <411d7b0f-01b8-46df-9bce-929eec366d2d@epam.com> From: Julien Grall In-Reply-To: <411d7b0f-01b8-46df-9bce-929eec366d2d@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Oleksandr, On 02/09/2025 15:00, Oleksandr Tyshchenko wrote: > > > On 02.09.25 15:19, Julien Grall wrote: > > Hello Julien > >> On 02/09/2025 13:10, Orzel, Michal wrote: >>> >>> >>> On 02/09/2025 13:54, Julien Grall wrote: >>>> Hi, >>>> >>>> On 02/09/2025 11:18, Orzel, Michal wrote: >>>>> >>>>> >>>>> On 02/09/2025 11:49, Oleksandr Tyshchenko wrote: >>>>>> The said sub-op is not supported on Arm, since it: >>>>>>    - does not support the buffered emulation (so bufioreq_port/ >>>>>> bufioreq_gfn >>>>>>      cannot be returned), please refer to ioreq_server_create() >>>>>>    - does not support "legacy" mechanism of mapping IOREQ Server >>>>>>      magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), >>>>>> please >>>>>>      refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire >>>>>>      Resource infrastructure is used to query and map the IOREQ >>>>>> Server pages. >>>>>> >>>>>> Signed-off-by: Oleksandr Tyshchenko >>>>> Reviewed-by: Michal Orzel >>>>> >>>>> Could we perhaps add a Fixes tag here pointing to the commit >>>>> introducing these >>>>> DM ops and thus add this patch for this release? Not sure what >>>>> others think. >>>> >>>> Fixes usually implies a bug and I don't see what bug we are solving. In >>>> fact, I don't understand why we are trying to remove the subop... >>> Hmm, the issue is that the subop that is not supported at the moment >>> is listed >>> as supported in the public header. >> >> [...] >> >>> As for the code, from safety perspective if this subop is listed >>> explicilty in Arm's >>> dm.c, we would need to write a separate test case and test to cover it >>> that at >>> the end, still returns -EOPNOTSUPP. >> >> Why do you think it is not supported? AFAICT, it is still possible to >> pass XEN_DMOP_nognfs to figure out whwether bufioreq is currently >> available. The error code would be 0 not -EOPNOTSUPP. > > > Yes, by passing XEN_DMOP_no_gfns we will bypass > arch_ioreq_server_map_pages() call, and yes, ioreq_server_get_info() > will return 0 in that case. > > But, "bufioreq_port" field in struct xen_dm_op_get_ioreq_server_info > (out param) won't be really updated (since the IOREQ Server was created > with HVM_IOREQSRV_BUFIOREQ_OFF before that). Sure. But this would be the same behavior on x86, right? If so... > > So, "at the moment", XEN_DMOP_get_ioreq_server_info sub-op is > non-functional/useless on Arm ("unsupported" is probably not a precise > word in that particular case), this is my understanding (which might be > wrong). That is why I have sent a patch to remove the mention from the > public header. ... I still don't understand why we are just trying to sweep the problem under the rug on Arm. That's assuming there is one. If there is a problem, then we should fix it properly for all architectures. If there is no problem, then this patch should not exists. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:45:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:45:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106690.1457317 (Exim 4.92) (envelope-from ) id 1utSFn-0001Zh-9s; Tue, 02 Sep 2025 14:44:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106690.1457317; Tue, 02 Sep 2025 14:44:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSFn-0001Za-77; Tue, 02 Sep 2025 14:44:59 +0000 Received: by outflank-mailman (input) for mailman id 1106690; Tue, 02 Sep 2025 14:44: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 1utSFl-0001ZU-Ed for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:44: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 63dbd3a6-880b-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:44:55 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-afcb7ae31caso1054524266b.3 for ; Tue, 02 Sep 2025 07:44:55 -0700 (PDT) Received: from eddie5.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aff15fccad1sm942353066b.108.2025.09.02.07.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 07:44: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: 63dbd3a6-880b-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1756824294; x=1757429094; 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=f48bQFr2pwLrvr7pu6JK/rPhwtQpUL/wKoNYgBPv14Q=; b=c4kVIBZAJgFZpi2uHth1IJGrkbAR1aXZc0Sn05Eb5kYTqUMT3hoK8nm2rSxmAQPtl8 dH6XR8VwGY1yoo30UsdxacfMO8S3Aai+iT0OGc+Qsa8/cEPgG30cAkuMNzukZixuegCP 5p/fsZ2X4h9+U9sjte2Ln15OQ+MfqRxq9R6nQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756824294; x=1757429094; 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=f48bQFr2pwLrvr7pu6JK/rPhwtQpUL/wKoNYgBPv14Q=; b=U04JwGEMcyMpRbTkMz7Etc3m+Ta1QwxtmXyC6oLvzF7T+eSU2YkZrhrvkCd56JM0/j nJ2PxQukw0eAP6yuuIvnpA+WxDaJjWnhu2YjqFVwBN2YcflFnrmvaiSP/puvA7YHvb8L pjjDBJ+WqdugIrnC3IqjQls368E9ntIVEy3pzGIjWHWH2yn94DGg7sfrrPrYenH6BeBT hTgTayjQ4wxgtoIkRx9obvMrRFWf0keVMOOMOF90RnlFqIqNvn8TDtE+46OaGlCD8vY3 tdLZd+7hX7H8Txjza8UPpeXXca4k8cwERSyroqtTlAQCeqn6OXypxPOOxWoixnpKaoe+ oZ+A== X-Gm-Message-State: AOJu0Yy0G2W1CPVCCAu23zUbnjmgZynTzdDjzN8RFbRxRx+M7G+2eCTB 6EP+RFB27g3EF9LY9l+NLXNcdI0tjLI2JNtOD8B5ru5Yc1wMJoo2LTyEQRr0v+QeETLb6cnv4iQ AFgJW6U4= X-Gm-Gg: ASbGncseKSHihhY3jf9uzNGSafv3ifmPiCNkGjq9k/nKJcQDHSpn4AfinYu6NuVzlRo GJxWYVcaMX89Eqn4rvkf37R54Z2jNM/N+xo36g3bARHKvaL2kCJvDzcEKIM8aLGn7WkwWmm8rCD pq7pIG6WzvzGmgS0r2OZ5YJClcnrpUtDzPsOpwhRWsW2wfBhlRSzvyX2r2CQ/n1b3WMETeHrjzt EYX8Wbjx+J0WZ0Ikb56+aQtqgIi+p2CjA0Q8OBRCTHwUYUa51vm5KuL6LHCZXs7q9euPjgE9lWp JkJIhpihTwjqUdbxlnhuNj6E83IsKBQXA9uP+rZmfMpnIPKFgX0d1qB/Py5DD4N3ZQmaYH/c25/ xChM6oJG86lFvdCuZqn393AB+8yIIr32KBSfhY4fW6IYnuXwjeIVFrXsF X-Google-Smtp-Source: AGHT+IHjbWXHk9e+wapZHxoKH2FCnMDaeWlQIBl/ucIqvv5oPZW/Wr8d4x3VmEbuZcPcZuSyJq4uRQ== X-Received: by 2002:a17:906:6a02:b0:af9:2e26:4636 with SMTP id a640c23a62f3a-b01d971924bmr1109674166b.32.1756824294174; Tue, 02 Sep 2025 07:44:54 -0700 (PDT) From: Gerald Elder-Vass To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Gerald Elder-Vass , Kevin Lampis , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich Subject: [XEN PATCH v2] efi: Use Shim's LoadImage to verify the Dom0 kernel Date: Tue, 2 Sep 2025 14:44:45 +0000 Message-ID: <7f2f88f0d857ed3f8d7e3fabe349a3b5d5815981.1756822290.git.gerald.elder-vass@cloud.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The existing Verify functionality of the Shim lock protocol is deprecated and will be removed, instead we must use the LoadImage interface to perform the verification. When the loading is successful we won't be using the newly loaded image (as of yet) so we must then immediately unload the image to clean up. Signed-off-by: Gerald Elder-Vass Signed-off-by: Kevin Lampis --- Changes since v1: - Re-instated SHIM_LOCK_PROTOCOL as a fallback option if IMAGE_LOADER is not found - Fixed indentation and error messages --- xen/common/efi/boot.c | 43 +++++++++++++++++++++++++++++++++++++------ 1 file changed, 37 insertions(+), 6 deletions(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 453b1ba099cd..273da3d9e3e3 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -38,6 +38,8 @@ { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} } #define SHIM_LOCK_PROTOCOL_GUID \ { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} } +#define SHIM_IMAGE_LOADER_GUID \ + { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} } #define APPLE_PROPERTIES_PROTOCOL_GUID \ { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} } #define EFI_SYSTEM_RESOURCE_TABLE_GUID \ @@ -70,6 +72,13 @@ typedef struct { EFI_SHIM_LOCK_VERIFY Verify; } EFI_SHIM_LOCK_PROTOCOL; +typedef struct _SHIM_IMAGE_LOADER { + EFI_IMAGE_LOAD LoadImage; + EFI_IMAGE_START StartImage; + EFI_EXIT Exit; + EFI_IMAGE_UNLOAD UnloadImage; +} SHIM_IMAGE_LOADER; + struct _EFI_APPLE_PROPERTIES; typedef EFI_STATUS @@ -1336,10 +1345,12 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; EFI_LOADED_IMAGE *loaded_image; EFI_STATUS status; + EFI_HANDLE loaded_kernel; unsigned int i; CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL; UINTN gop_mode = ~0; EFI_SHIM_LOCK_PROTOCOL *shim_lock; + SHIM_IMAGE_LOADER *shim_loader; EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL; union string section = { NULL }, name; bool base_video = false; @@ -1590,12 +1601,32 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, * device tree through the efi_check_dt_boot function, in this stage * 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 ) - PrintErrMesg(L"Dom0 kernel image could not be verified", status); + if ( kernel.ptr && !kernel_verified ) + { + + if ( !EFI_ERROR(efi_bs->LocateProtocol(&((EFI_GUID) SHIM_IMAGE_LOADER_GUID), + NULL, (void **)&shim_loader)) ) + { + status = shim_loader->LoadImage(false, ImageHandle, NULL, (void *)kernel.ptr, kernel.size, &loaded_kernel); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"LoadImage failed", status); + + // LoadImage performs verification, now unload it to clean up + status = shim_loader->UnloadImage(loaded_kernel); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"UnloadImage failed", status); + } + else + { + status = efi_bs->LocateProtocol(&shim_lock_guid, NULL, (void **)&shim_lock); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"Failed to locate SHIM_LOCK protocol", status); + + status = shim_lock->Verify(kernel.ptr, kernel.size); + if ( EFI_ERROR(status) ) + PrintErrMesg(L"Dom0 kernel image could not be verified", status); + } + } efi_arch_edd(); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106701.1457326 (Exim 4.92) (envelope-from ) id 1utSJr-00028b-Q6; Tue, 02 Sep 2025 14:49:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106701.1457326; Tue, 02 Sep 2025 14: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 1utSJr-00028U-NK; Tue, 02 Sep 2025 14:49:11 +0000 Received: by outflank-mailman (input) for mailman id 1106701; Tue, 02 Sep 2025 14: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 1utSJq-00028O-0q for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:10 +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 f9ddbebd-880b-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49:07 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id DE20A43910; Tue, 2 Sep 2025 14:49:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ACFA9C4CEED; Tue, 2 Sep 2025 14:49: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: f9ddbebd-880b-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824545; bh=3SAFSguWc3mEh+7tLjgls851bpgvCDXeoOLUKYRDCQw=; h=From:To:Cc:Subject:Date:From; b=T4z/viMpK/6nZf/nQZOIsRAAm3EHCx98H3vJy/7M+HoAOU06u4ge/kUryG+aCfwUr EPLJmc0enqvgMLu/ql+aqcT5Fj2w9kmxR9H/m3pCJndhGClrY92+csP8H8rqa+M2F0 +/tg51ze5lLUyJvb9GuRMyJ6Mnz6YmTZuEbkE8BZXJxNc0WBeGGkH6nfvvoKcKyT7D 72RQkLhAK72Yfulrr+BomhHq1M5YBXZDuDEbusIH/tJezD3AHPAbYmPt0An2e0azvi DpDSFe11OrTeaTIEkB3Rx5xhIiAEjLUzU+nXQYo+9uCB+p85bgbRHkcFyUX4QjIfNW +sNnsW+E+uHqg== From: Leon Romanovsky To: Marek Szyprowski Cc: Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 00/16] dma-mapping: migrate to physical address-based API Date: Tue, 2 Sep 2025 17:48:37 +0300 Message-ID: X-Mailer: git-send-email 2.50.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Marek, Please pay attention that I'm resending all patches which includes nvme/blk conversion too. The code is based on clean -rc3, but NVMe tree got patch in this cycle which removes one of their REQ_* bits, on which I'm relying. This is the patch: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-6.18/block&id=7092639031a1bd5320ab827e8f665350f332b7ce and this is Keith's attempt to restore it: https://lore.kernel.org/linux-block/20250829142307.3769873-3-kbusch@meta.com/ So there are two possible options: 1. Apply only first 13 patches and I'll resend nvme/blk patches in next cycle with the hope that REQ_* bits issue is sorted. 2. Apply whole series and deal with merge conflicts by sending PR to Jens and ask him to merge this DMA series. Thanks ------------------------------------------------------------------------ Changelog: v5: * Added Jason's and Keith's Reviewed-by tags * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys * Jason's cleanup suggestions v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/ * Fixed kbuild error with mismatch in kmsan function declaration due to rebase error. v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org * Fixed typo in "cacheable" word * Simplified kmsan patch a lot to be simple argument refactoring v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org * Used commit messages and cover letter from Jason * Moved setting IOMMU_MMIO flag to dma_info_to_prot function * Micro-optimized the code * Rebased code on v6.17-rc1 v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org * Added new DMA_ATTR_MMIO attribute to indicate PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path. * Rewrote dma_map_* functions to use thus new attribute v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/ ------------------------------------------------------------------------ This series refactors the DMA mapping to use physical addresses as the primary interface instead of page+offset parameters. This change aligns the DMA API with the underlying hardware reality where DMA operations work with physical addresses, not page structures. The series maintains export symbol backward compatibility by keeping the old page-based API as wrapper functions around the new physical address-based implementations. This series refactors the DMA mapping API to provide a phys_addr_t based, and struct-page free, external API that can handle all the mapping cases we want in modern systems: - struct page based cacheable DRAM - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable MMIO - struct page-less PCI peer to peer non-cacheable MMIO - struct page-less "resource" MMIO Overall this gets much closer to Matthew's long term wish for struct-pageless IO to cacheable DRAM. The remaining primary work would be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on phys_addr_t without a struct page. The general design is to remove struct page usage entirely from the DMA API inner layers. For flows that need to have a KVA for the physical address they can use kmap_local_pfn() or phys_to_virt(). This isolates the struct page requirements to MM code only. Long term all removals of struct page usage are supporting Matthew's memdesc project which seeks to substantially transform how struct page works. Instead make the DMA API internals work on phys_addr_t. Internally there are still dedicated 'page' and 'resource' flows, except they are now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both flows use the same phys_addr_t. When DMA_ATTR_MMIO is specified things work similar to the existing 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), pfn_valid(), etc are never called on the phys_addr_t. This requires rejecting any configuration that would need swiotlb. CPU cache flushing is not required, and avoided, as ATTR_MMIO also indicates the address have no cacheable mappings. This effectively removes any DMA API side requirement to have struct page when DMA_ATTR_MMIO is used. In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, except on the common path of no cache flush, no swiotlb it never touches a struct page. When cache flushing or swiotlb copying kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU usage. This was already the case on the unmap side, now the map side is symmetric. Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA path must also set it. This corrects some existing bugs where iommu mappings for P2P MMIO were improperly marked IOMMU_CACHE. Since ATTR_MMIO is made to work with all the existing DMA map entry points, particularly dma_iova_link(), this finally allows a way to use the new DMA API to map PCI P2P MMIO without creating struct page. The VFIO DMABUF series demonstrates how this works. This is intended to replace the incorrect driver use of dma_map_resource() on PCI BAR addresses. This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation. Thanks Leon Romanovsky (16): dma-mapping: introduce new DMA attribute to indicate MMIO memory iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link(). dma-debug: refactor to use physical addresses for page mapping dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys iommu/dma: implement DMA_ATTR_MMIO for iommu_dma_(un)map_phys() dma-mapping: convert dma_direct_*map_page to be phys_addr_t based kmsan: convert kmsan_handle_dma to use physical addresses dma-mapping: implement DMA_ATTR_MMIO for dma_(un)map_page_attrs() xen: swiotlb: Open code map_resource callback dma-mapping: export new dma_*map_phys() interface mm/hmm: migrate to physical address-based DMA mapping API mm/hmm: properly take MMIO path block-dma: migrate to dma_map_phys instead of map_page block-dma: properly take MMIO path nvme-pci: unmap MMIO pages with appropriate interface Documentation/core-api/dma-api.rst | 4 +- Documentation/core-api/dma-attributes.rst | 18 ++++ arch/powerpc/kernel/dma-iommu.c | 4 +- block/blk-mq-dma.c | 15 ++- drivers/iommu/dma-iommu.c | 61 +++++------ drivers/nvme/host/pci.c | 18 +++- drivers/virtio/virtio_ring.c | 4 +- drivers/xen/swiotlb-xen.c | 21 +++- include/linux/blk-mq-dma.h | 6 +- include/linux/blk_types.h | 2 + include/linux/dma-direct.h | 2 - include/linux/dma-map-ops.h | 8 +- include/linux/dma-mapping.h | 33 ++++++ include/linux/iommu-dma.h | 11 +- include/linux/kmsan.h | 9 +- include/linux/page-flags.h | 1 + include/trace/events/dma.h | 9 +- kernel/dma/debug.c | 81 ++++----------- kernel/dma/debug.h | 37 ++----- kernel/dma/direct.c | 22 +--- kernel/dma/direct.h | 57 +++++++---- kernel/dma/mapping.c | 117 +++++++++++++--------- kernel/dma/ops_helpers.c | 6 +- mm/hmm.c | 19 ++-- mm/kmsan/hooks.c | 8 +- rust/kernel/dma.rs | 3 + tools/virtio/linux/kmsan.h | 2 +- 27 files changed, 315 insertions(+), 263 deletions(-) -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106702.1457337 (Exim 4.92) (envelope-from ) id 1utSJv-0002NS-4k; Tue, 02 Sep 2025 14:49:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106702.1457337; Tue, 02 Sep 2025 14:49: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 1utSJv-0002NL-1i; Tue, 02 Sep 2025 14:49:15 +0000 Received: by outflank-mailman (input) for mailman id 1106702; Tue, 02 Sep 2025 14: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 1utSJt-0002MQ-7F for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:13 +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 fc7e0ac2-880b-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49: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 272106021C; Tue, 2 Sep 2025 14:49:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C5C6C4CEED; Tue, 2 Sep 2025 14:49: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: fc7e0ac2-880b-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824549; bh=mXPBKGOTAXMaA8YnIACrT4VeK6ColaZH6f/lOi0T5+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U0Qv8COD9vJg/sj1gHJxX08tsa8mkqMwlswZW+JY7U0WZ8zpN+E0gqojH+zijJe4+ GuuBOfJJ7E92NxE/euEVPxir80asPMfJZGfrlBFEkkFiMxs1fGRxbBrARGWJDsvYEz 0KVNHATZmZLhqAH2lHu7WLDB7F7EQbI17lR4MqOQH/5s2HbhqrH3xM/s+mDuyDQQmx m02cD9zShxiSGxZ84PSZ2YclbBHgJpT4c2BpGr1yygJDBWMAsAnP+j3X0VDKrUyWPN 1KTnwLeTF/x2Orxw9fuAs97O/ssJyp2QOTAnt7oAnZkpfXEk2bpm2MqXqfbqd52vql XZaWqMxq2z8vg== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 02/16] iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link(). Date: Tue, 2 Sep 2025 17:48:39 +0300 Message-ID: <5a279b1ce492ba8635eb3fa6bb9a22fd77366672.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky This will replace the hacky use of DMA_ATTR_SKIP_CPU_SYNC to avoid touching the possibly non-KVA MMIO memory. Also correct the incorrect caching attribute for the IOMMU, MMIO memory should not be cachable inside the IOMMU mapping or it can possibly create system problems. Set IOMMU_MMIO for DMA_ATTR_MMIO. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- drivers/iommu/dma-iommu.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index ea2ef53bd4fe..e1185ba73e23 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -724,7 +724,12 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev static int dma_info_to_prot(enum dma_data_direction dir, bool coherent, unsigned long attrs) { - int prot = coherent ? IOMMU_CACHE : 0; + int prot; + + if (attrs & DMA_ATTR_MMIO) + prot = IOMMU_MMIO; + else + prot = coherent ? IOMMU_CACHE : 0; if (attrs & DMA_ATTR_PRIVILEGED) prot |= IOMMU_PRIV; @@ -1838,12 +1843,13 @@ static int __dma_iova_link(struct device *dev, dma_addr_t addr, unsigned long attrs) { bool coherent = dev_is_dma_coherent(dev); + int prot = dma_info_to_prot(dir, coherent, attrs); - if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) + if (!coherent && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO))) arch_sync_dma_for_device(phys, size, dir); return iommu_map_nosync(iommu_get_dma_domain(dev), addr, phys, size, - dma_info_to_prot(dir, coherent, attrs), GFP_ATOMIC); + prot, GFP_ATOMIC); } static int iommu_dma_iova_bounce_and_link(struct device *dev, dma_addr_t addr, @@ -1949,9 +1955,13 @@ int dma_iova_link(struct device *dev, struct dma_iova_state *state, return -EIO; if (dev_use_swiotlb(dev, size, dir) && - iova_unaligned(iovad, phys, size)) + iova_unaligned(iovad, phys, size)) { + if (attrs & DMA_ATTR_MMIO) + return -EPERM; + return iommu_dma_iova_link_swiotlb(dev, state, phys, offset, size, dir, attrs); + } return __dma_iova_link(dev, state->addr + offset - iova_start_pad, phys - iova_start_pad, -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106703.1457347 (Exim 4.92) (envelope-from ) id 1utSJy-0002e0-BB; Tue, 02 Sep 2025 14:49:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106703.1457347; Tue, 02 Sep 2025 14: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 1utSJy-0002dt-7i; Tue, 02 Sep 2025 14:49:18 +0000 Received: by outflank-mailman (input) for mailman id 1106703; Tue, 02 Sep 2025 14:49: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 1utSJx-00028O-AF for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:17 +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 fe612948-880b-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49:15 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id F0AD744942; Tue, 2 Sep 2025 14:49:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D3AAC4CEED; Tue, 2 Sep 2025 14:49: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: fe612948-880b-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824553; bh=bQCJOhk6/urs9rnk28jsW9huZ5BmqRf4rlNcWoQochY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qNA0rpdIfDKcKY8jylpr6rIPXKRrMZ2SSvxdExkc4iYFUg9CGiS5XwAxPyEf8F+qA AFogSmagV9JyRlbdhVx9tx/4ZYBW3H5JGbQk2Cby5UXJj532uQQp72RE6MsPyvuxDQ uroJ+7G99RhoyzZEntv72aqyl+sgfCBGI21ScktmjfktL21+44tukkP/L5aZVh3NC5 iE3uMu+rgCByY9sAMLkloAREC/O3bNxIEONVHjqR+3zFFnDdxFyQ+sUuX5VXRZOo1X 3naF/+0zGlWHD0/zMTwdb3f5RNa+dkqF/arrZ1VZMVnkpGQYpnYYxl5o8UVINu+IDv zbchkle3zvSEQ== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 01/16] dma-mapping: introduce new DMA attribute to indicate MMIO memory Date: Tue, 2 Sep 2025 17:48:38 +0300 Message-ID: <9cce2a2bf181edacb33151388caa47725f780907.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers that reside in memory-mapped I/O (MMIO) regions, such as device BARs exposed through the host bridge, which are accessible for peer-to-peer (P2P) DMA. This attribute is especially useful for exporting device memory to other devices for DMA without CPU involvement, and avoids unnecessary or potentially detrimental CPU cache maintenance calls. DMA_ATTR_MMIO is supposed to provide dma_map_resource() functionality without need to call to special function and perform branching when processing generic containers like bio_vec by the callers. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- Documentation/core-api/dma-attributes.rst | 18 ++++++++++++++++++ include/linux/dma-mapping.h | 20 ++++++++++++++++++++ include/trace/events/dma.h | 3 ++- rust/kernel/dma.rs | 3 +++ 4 files changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst index 1887d92e8e92..0bdc2be65e57 100644 --- a/Documentation/core-api/dma-attributes.rst +++ b/Documentation/core-api/dma-attributes.rst @@ -130,3 +130,21 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged subsystem that the buffer is fully accessible at the elevated privilege level (and ideally inaccessible or at least read-only at the lesser-privileged levels). + +DMA_ATTR_MMIO +------------- + +This attribute indicates the physical address is not normal system +memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page() +functions, it may not be cacheable, and access using CPU load/store +instructions may not be allowed. + +Usually this will be used to describe MMIO addresses, or other non-cacheable +register addresses. When DMA mapping this sort of address we call +the operation Peer to Peer as a one device is DMA'ing to another device. +For PCI devices the p2pdma APIs must be used to determine if +DMA_ATTR_MMIO is appropriate. + +For architectures that require cache flushing for DMA coherence +DMA_ATTR_MMIO will not perform any cache flushing. The address +provided must never be mapped cacheable into the CPU. diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 55c03e5fe8cb..4254fd9bdf5d 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -58,6 +58,26 @@ */ #define DMA_ATTR_PRIVILEGED (1UL << 9) +/* + * DMA_ATTR_MMIO - Indicates memory-mapped I/O (MMIO) region for DMA mapping + * + * This attribute indicates the physical address is not normal system + * memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page() + * functions, it may not be cacheable, and access using CPU load/store + * instructions may not be allowed. + * + * Usually this will be used to describe MMIO addresses, or other non-cacheable + * register addresses. When DMA mapping this sort of address we call + * the operation Peer to Peer as a one device is DMA'ing to another device. + * For PCI devices the p2pdma APIs must be used to determine if DMA_ATTR_MMIO + * is appropriate. + * + * For architectures that require cache flushing for DMA coherence + * DMA_ATTR_MMIO will not perform any cache flushing. The address + * provided must never be mapped cacheable into the CPU. + */ +#define DMA_ATTR_MMIO (1UL << 10) + /* * A dma_addr_t can hold any valid DMA or bus address for the platform. It can * be given to a device to use as a DMA source or target. It is specific to a diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h index d8ddc27b6a7c..ee90d6f1dcf3 100644 --- a/include/trace/events/dma.h +++ b/include/trace/events/dma.h @@ -31,7 +31,8 @@ TRACE_DEFINE_ENUM(DMA_NONE); { DMA_ATTR_FORCE_CONTIGUOUS, "FORCE_CONTIGUOUS" }, \ { DMA_ATTR_ALLOC_SINGLE_PAGES, "ALLOC_SINGLE_PAGES" }, \ { DMA_ATTR_NO_WARN, "NO_WARN" }, \ - { DMA_ATTR_PRIVILEGED, "PRIVILEGED" }) + { DMA_ATTR_PRIVILEGED, "PRIVILEGED" }, \ + { DMA_ATTR_MMIO, "MMIO" }) DECLARE_EVENT_CLASS(dma_map, TP_PROTO(struct device *dev, phys_addr_t phys_addr, dma_addr_t dma_addr, diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs index 2bc8ab51ec28..61d9eed7a786 100644 --- a/rust/kernel/dma.rs +++ b/rust/kernel/dma.rs @@ -242,6 +242,9 @@ pub mod attrs { /// Indicates that the buffer is fully accessible at an elevated privilege level (and /// ideally inaccessible or at least read-only at lesser-privileged levels). pub const DMA_ATTR_PRIVILEGED: Attrs = Attrs(bindings::DMA_ATTR_PRIVILEGED); + + /// Indicates that the buffer is MMIO memory. + pub const DMA_ATTR_MMIO: Attrs = Attrs(bindings::DMA_ATTR_MMIO); } /// An abstraction of the `dma_alloc_coherent` API. -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106704.1457356 (Exim 4.92) (envelope-from ) id 1utSK1-0002vg-Ij; Tue, 02 Sep 2025 14:49:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106704.1457356; Tue, 02 Sep 2025 14: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 1utSK1-0002vZ-Fr; Tue, 02 Sep 2025 14:49:21 +0000 Received: by outflank-mailman (input) for mailman id 1106704; Tue, 02 Sep 2025 14: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 1utSK0-0002MQ-70 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:20 +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 01152c50-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49:19 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 7EA356021C; Tue, 2 Sep 2025 14:49:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B2D4C4CEED; Tue, 2 Sep 2025 14:49: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: 01152c50-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824558; bh=ZQFwkiDPp1GyvHCZ7R7ij52YlSaCwxtclFyfGHPImis=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jZmeCwVFRuH1q78msLckvRK79MBxGIRsQSWl7GBnGjpSqFOv2UDpkk6433cUWOsEL l9FnZk3/0IIfwIr220SmWYn2k3PyNggQq6bLFnvgo1KPA8d0QkcJIRT0vceLl2NBv3 AyLz46HnllepaRbuN6Ht7Y/oPR7+rcoH7rVDA85AS1gdZ8v7IiwFHbwzMgE1Q2HXAx ZKVBRm1t0pVDRP6Kla06+MrDCyH7a11ZlI1r1bp8YNmS2rKCfQW03E6fHoFyIWG1eL Gf1sYErqR105oSaj09oPpOBM+XoEwrPIL4YnSSFSWBAOhlLxm/x9zMzxsifJI16EZE Wv26+f+T2tyxA== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 04/16] dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys Date: Tue, 2 Sep 2025 17:48:41 +0300 Message-ID: <7b4656d5f6392486f28f71ad600a95e6690e2f41.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky As a preparation for following map_page -> map_phys API conversion, let's rename trace_dma_*map_page() to be trace_dma_*map_phys(). Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- include/trace/events/dma.h | 4 ++-- kernel/dma/mapping.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h index ee90d6f1dcf3..84416c7d6bfa 100644 --- a/include/trace/events/dma.h +++ b/include/trace/events/dma.h @@ -72,7 +72,7 @@ DEFINE_EVENT(dma_map, name, \ size_t size, enum dma_data_direction dir, unsigned long attrs), \ TP_ARGS(dev, phys_addr, dma_addr, size, dir, attrs)) -DEFINE_MAP_EVENT(dma_map_page); +DEFINE_MAP_EVENT(dma_map_phys); DEFINE_MAP_EVENT(dma_map_resource); DECLARE_EVENT_CLASS(dma_unmap, @@ -110,7 +110,7 @@ DEFINE_EVENT(dma_unmap, name, \ enum dma_data_direction dir, unsigned long attrs), \ TP_ARGS(dev, addr, size, dir, attrs)) -DEFINE_UNMAP_EVENT(dma_unmap_page); +DEFINE_UNMAP_EVENT(dma_unmap_phys); DEFINE_UNMAP_EVENT(dma_unmap_resource); DECLARE_EVENT_CLASS(dma_alloc_class, diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 4c1dfbabb8ae..fe1f0da6dc50 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -173,7 +173,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, else addr = ops->map_page(dev, page, offset, size, dir, attrs); kmsan_handle_dma(page, offset, size, dir); - trace_dma_map_page(dev, phys, addr, size, dir, attrs); + trace_dma_map_phys(dev, phys, addr, size, dir, attrs); debug_dma_map_phys(dev, phys, size, dir, addr, attrs); return addr; @@ -193,7 +193,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, iommu_dma_unmap_page(dev, addr, size, dir, attrs); else ops->unmap_page(dev, addr, size, dir, attrs); - trace_dma_unmap_page(dev, addr, size, dir, attrs); + trace_dma_unmap_phys(dev, addr, size, dir, attrs); debug_dma_unmap_phys(dev, addr, size, dir); } EXPORT_SYMBOL(dma_unmap_page_attrs); -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106706.1457368 (Exim 4.92) (envelope-from ) id 1utSK6-0003KW-VM; Tue, 02 Sep 2025 14:49:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106706.1457368; Tue, 02 Sep 2025 14:49:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSK6-0003K2-No; Tue, 02 Sep 2025 14:49:26 +0000 Received: by outflank-mailman (input) for mailman id 1106706; Tue, 02 Sep 2025 14:49:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSK5-0002MQ-Hp for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:25 +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 0393c28b-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49: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 997C144B04; Tue, 2 Sep 2025 14:49:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63F72C4CEED; Tue, 2 Sep 2025 14:49: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: 0393c28b-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824562; bh=O6uMPMfn6w3e8A1zwYyTqdbKBNXEs5PSAm4+nCx8TRc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=myJAVWf/5pP27hEdW1OJXdbXUSkcP79/L41p91PWbmM6tvhAAcY6WU3zAKSpQUomc QH4aB6lvbbnIYw7q8DRSz00YjYtr7WYWtgm6T5RhfgesFjn7nG+KObPUcI6F2HA1Qe Y6d+0zlZE+phzYvWQX50DgVolFKX74Cyn9ITd/6PeRHDBMZF1q+BC/2sjXYDIX8w7t EVN4ghuKO3fVzEnRThIGn3kbv/JwxhkY6m6ltUwZQmazTDeuiTfOD6OQCFhjVu+HL1 Xj0ZRiNUw+h9pJF3hE1a+8iqZ02XyqiZEyRBb6QcXs/uIx6mg3fOHMcxuzeC43FpQ6 9gnsufUbJk7Lw== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 05/16] iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys Date: Tue, 2 Sep 2025 17:48:42 +0300 Message-ID: <9b7eebd170d68db9854056e24b94ec1fdad73d6f.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Rename the IOMMU DMA mapping functions to better reflect their actual calling convention. The functions iommu_dma_map_page() and iommu_dma_unmap_page() are renamed to iommu_dma_map_phys() and iommu_dma_unmap_phys() respectively, as they already operate on physical addresses rather than page structures. The calling convention changes from accepting (struct page *page, unsigned long offset) to (phys_addr_t phys), which eliminates the need for page-to-physical address conversion within the functions. This renaming prepares for the broader DMA API conversion from page-based to physical address-based mapping throughout the kernel. All callers are updated to pass physical addresses directly, including dma_map_page_attrs(), scatterlist mapping functions, and DMA page allocation helpers. The change simplifies the code by removing the page_to_phys() + offset calculation that was previously done inside the IOMMU functions. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- drivers/iommu/dma-iommu.c | 14 ++++++-------- include/linux/iommu-dma.h | 7 +++---- kernel/dma/mapping.c | 4 ++-- kernel/dma/ops_helpers.c | 6 +++--- 4 files changed, 14 insertions(+), 17 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index e1185ba73e23..aea119f32f96 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1195,11 +1195,9 @@ static inline size_t iova_unaligned(struct iova_domain *iovad, phys_addr_t phys, return iova_offset(iovad, phys | size); } -dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, enum dma_data_direction dir, - unsigned long attrs) +dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, + enum dma_data_direction dir, unsigned long attrs) { - phys_addr_t phys = page_to_phys(page) + offset; bool coherent = dev_is_dma_coherent(dev); int prot = dma_info_to_prot(dir, coherent, attrs); struct iommu_domain *domain = iommu_get_dma_domain(dev); @@ -1227,7 +1225,7 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page, return iova; } -void iommu_dma_unmap_page(struct device *dev, dma_addr_t dma_handle, +void iommu_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction dir, unsigned long attrs) { struct iommu_domain *domain = iommu_get_dma_domain(dev); @@ -1346,7 +1344,7 @@ static void iommu_dma_unmap_sg_swiotlb(struct device *dev, struct scatterlist *s int i; for_each_sg(sg, s, nents, i) - iommu_dma_unmap_page(dev, sg_dma_address(s), + iommu_dma_unmap_phys(dev, sg_dma_address(s), sg_dma_len(s), dir, attrs); } @@ -1359,8 +1357,8 @@ static int iommu_dma_map_sg_swiotlb(struct device *dev, struct scatterlist *sg, sg_dma_mark_swiotlb(sg); for_each_sg(sg, s, nents, i) { - sg_dma_address(s) = iommu_dma_map_page(dev, sg_page(s), - s->offset, s->length, dir, attrs); + sg_dma_address(s) = iommu_dma_map_phys(dev, sg_phys(s), + s->length, dir, attrs); if (sg_dma_address(s) == DMA_MAPPING_ERROR) goto out_unmap; sg_dma_len(s) = s->length; diff --git a/include/linux/iommu-dma.h b/include/linux/iommu-dma.h index 508beaa44c39..485bdffed988 100644 --- a/include/linux/iommu-dma.h +++ b/include/linux/iommu-dma.h @@ -21,10 +21,9 @@ static inline bool use_dma_iommu(struct device *dev) } #endif /* CONFIG_IOMMU_DMA */ -dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, enum dma_data_direction dir, - unsigned long attrs); -void iommu_dma_unmap_page(struct device *dev, dma_addr_t dma_handle, +dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, + enum dma_data_direction dir, unsigned long attrs); +void iommu_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction dir, unsigned long attrs); int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir, unsigned long attrs); diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index fe1f0da6dc50..58482536db9b 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -169,7 +169,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, arch_dma_map_page_direct(dev, phys + size)) addr = dma_direct_map_page(dev, page, offset, size, dir, attrs); else if (use_dma_iommu(dev)) - addr = iommu_dma_map_page(dev, page, offset, size, dir, attrs); + addr = iommu_dma_map_phys(dev, phys, size, dir, attrs); else addr = ops->map_page(dev, page, offset, size, dir, attrs); kmsan_handle_dma(page, offset, size, dir); @@ -190,7 +190,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, arch_dma_unmap_page_direct(dev, addr + size)) dma_direct_unmap_page(dev, addr, size, dir, attrs); else if (use_dma_iommu(dev)) - iommu_dma_unmap_page(dev, addr, size, dir, attrs); + iommu_dma_unmap_phys(dev, addr, size, dir, attrs); else ops->unmap_page(dev, addr, size, dir, attrs); trace_dma_unmap_phys(dev, addr, size, dir, attrs); diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c index 9afd569eadb9..6f9d604d9d40 100644 --- a/kernel/dma/ops_helpers.c +++ b/kernel/dma/ops_helpers.c @@ -72,8 +72,8 @@ struct page *dma_common_alloc_pages(struct device *dev, size_t size, return NULL; if (use_dma_iommu(dev)) - *dma_handle = iommu_dma_map_page(dev, page, 0, size, dir, - DMA_ATTR_SKIP_CPU_SYNC); + *dma_handle = iommu_dma_map_phys(dev, page_to_phys(page), size, + dir, DMA_ATTR_SKIP_CPU_SYNC); else *dma_handle = ops->map_page(dev, page, 0, size, dir, DMA_ATTR_SKIP_CPU_SYNC); @@ -92,7 +92,7 @@ void dma_common_free_pages(struct device *dev, size_t size, struct page *page, const struct dma_map_ops *ops = get_dma_ops(dev); if (use_dma_iommu(dev)) - iommu_dma_unmap_page(dev, dma_handle, size, dir, + iommu_dma_unmap_phys(dev, dma_handle, size, dir, DMA_ATTR_SKIP_CPU_SYNC); else if (ops->unmap_page) ops->unmap_page(dev, dma_handle, size, dir, -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106712.1457377 (Exim 4.92) (envelope-from ) id 1utSKB-0003ii-8v; Tue, 02 Sep 2025 14:49:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106712.1457377; Tue, 02 Sep 2025 14: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 1utSKB-0003iX-4e; Tue, 02 Sep 2025 14:49:31 +0000 Received: by outflank-mailman (input) for mailman id 1106712; Tue, 02 Sep 2025 14:49: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 1utSK9-0002MQ-Km for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:29 +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 0675ee45-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16: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 7F0616021C; Tue, 2 Sep 2025 14:49:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61C06C4CEED; Tue, 2 Sep 2025 14:49: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: 0675ee45-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824567; bh=uH7MCAz6dsaq9sct7ho6H+zYeVokmgR17T1ZOZaSB5I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i1626xjVt6rHPzjustWTh89OBItu5qQ/mpVf7G/FH1ewKFbLrncF9oXFg1ZN+Aa6Z D/OqGkivSxO+Wp/kh3rml8ZUgNX1VybO2kl7i0RlTjM7W98E8gxeBLn9vDdbpI60Lx sX5XKNZ4y3/vbcAN8Mp1j7NkZJc6hy3Rc9S1pcheGm8yN0vIstlHnUbc6dvYARbx/P YcXonxterBEeyDHNgUd8PWvIyyAGyIM67qT/YT7M9W+8Rgi4I3FHqD/9KIyjajW2Jj aLwXwchnsh4pPdnWnxqKHsXxeTVFAYi1AAfai0l1Mv/GgMBiSP0uTjG/NGvHxE1yxM CcCWiInzqH5Jw== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 03/16] dma-debug: refactor to use physical addresses for page mapping Date: Tue, 2 Sep 2025 17:48:40 +0300 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Convert the DMA debug infrastructure from page-based to physical address-based mapping as a preparation to rely on physical address for DMA mapping routines. The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and changes its signature to accept a phys_addr_t parameter instead of struct page and offset. Similarly, debug_dma_unmap_page() becomes debug_dma_unmap_phys(). A new dma_debug_phy type is introduced to distinguish physical address mappings from other debug entry types. All callers throughout the codebase are updated to pass physical addresses directly, eliminating the need for page-to-physical conversion in the debug layer. This refactoring eliminates the need to convert between page pointers and physical addresses in the debug layer, making the code more efficient and consistent with the DMA mapping API's physical address focus. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- Documentation/core-api/dma-api.rst | 4 ++-- include/linux/page-flags.h | 1 + kernel/dma/debug.c | 38 +++++++++++++++++------------- kernel/dma/debug.h | 16 ++++++------- kernel/dma/mapping.c | 15 ++++++------ 5 files changed, 39 insertions(+), 35 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index 3087bea715ed..ca75b3541679 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -761,7 +761,7 @@ example warning message may look like this:: [] find_busiest_group+0x207/0x8a0 [] _spin_lock_irqsave+0x1f/0x50 [] check_unmap+0x203/0x490 - [] debug_dma_unmap_page+0x49/0x50 + [] debug_dma_unmap_phys+0x49/0x50 [] nv_tx_done_optimized+0xc6/0x2c0 [] nv_nic_irq_optimized+0x73/0x2b0 [] handle_IRQ_event+0x34/0x70 @@ -855,7 +855,7 @@ that a driver may be leaking mappings. dma-debug interface debug_dma_mapping_error() to debug drivers that fail to check DMA mapping errors on addresses returned by dma_map_single() and dma_map_page() interfaces. This interface clears a flag set by -debug_dma_map_page() to indicate that dma_mapping_error() has been called by +debug_dma_map_phys() to indicate that dma_mapping_error() has been called by the driver. When driver does unmap, debug_dma_unmap() checks the flag and if this flag is still set, prints warning message that includes call trace that leads up to the unmap. This interface can be called from dma_mapping_error() diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 8d3fa3a91ce4..dfbc4ba86bba 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -614,6 +614,7 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE) * available at this point. */ #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p)) +#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p))) #define folio_test_highmem(__f) is_highmem_idx(folio_zonenum(__f)) #else PAGEFLAG_FALSE(HighMem, highmem) diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index e43c6de2bce4..a0b135455119 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -39,6 +39,7 @@ enum { dma_debug_sg, dma_debug_coherent, dma_debug_resource, + dma_debug_phy, }; enum map_err_types { @@ -141,6 +142,7 @@ static const char *type2name[] = { [dma_debug_sg] = "scatter-gather", [dma_debug_coherent] = "coherent", [dma_debug_resource] = "resource", + [dma_debug_phy] = "phy", }; static const char *dir2name[] = { @@ -1051,17 +1053,16 @@ static void check_unmap(struct dma_debug_entry *ref) dma_entry_free(entry); } -static void check_for_stack(struct device *dev, - struct page *page, size_t offset) +static void check_for_stack(struct device *dev, phys_addr_t phys) { void *addr; struct vm_struct *stack_vm_area = task_stack_vm_area(current); if (!stack_vm_area) { /* Stack is direct-mapped. */ - if (PageHighMem(page)) + if (PhysHighMem(phys)) return; - addr = page_address(page) + offset; + addr = phys_to_virt(phys); if (object_is_on_stack(addr)) err_printk(dev, NULL, "device driver maps memory from stack [addr=%p]\n", addr); } else { @@ -1069,10 +1070,12 @@ static void check_for_stack(struct device *dev, int i; for (i = 0; i < stack_vm_area->nr_pages; i++) { - if (page != stack_vm_area->pages[i]) + if (__phys_to_pfn(phys) != + page_to_pfn(stack_vm_area->pages[i])) continue; - addr = (u8 *)current->stack + i * PAGE_SIZE + offset; + addr = (u8 *)current->stack + i * PAGE_SIZE + + (phys % PAGE_SIZE); err_printk(dev, NULL, "device driver maps memory from stack [probable addr=%p]\n", addr); break; } @@ -1201,9 +1204,8 @@ void debug_dma_map_single(struct device *dev, const void *addr, } EXPORT_SYMBOL(debug_dma_map_single); -void debug_dma_map_page(struct device *dev, struct page *page, size_t offset, - size_t size, int direction, dma_addr_t dma_addr, - unsigned long attrs) +void debug_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, + int direction, dma_addr_t dma_addr, unsigned long attrs) { struct dma_debug_entry *entry; @@ -1218,19 +1220,21 @@ void debug_dma_map_page(struct device *dev, struct page *page, size_t offset, return; entry->dev = dev; - entry->type = dma_debug_single; - entry->paddr = page_to_phys(page) + offset; + entry->type = dma_debug_phy; + entry->paddr = phys; entry->dev_addr = dma_addr; entry->size = size; entry->direction = direction; entry->map_err_type = MAP_ERR_NOT_CHECKED; - check_for_stack(dev, page, offset); + if (!(attrs & DMA_ATTR_MMIO)) { + struct page *page = phys_to_page(phys); + size_t offset = offset_in_page(page); - if (!PageHighMem(page)) { - void *addr = page_address(page) + offset; + check_for_stack(dev, phys); - check_for_illegal_area(dev, addr, size); + if (!PhysHighMem(phys)) + check_for_illegal_area(dev, phys_to_virt(phys), size); } add_dma_entry(entry, attrs); @@ -1274,11 +1278,11 @@ void debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr) } EXPORT_SYMBOL(debug_dma_mapping_error); -void debug_dma_unmap_page(struct device *dev, dma_addr_t dma_addr, +void debug_dma_unmap_phys(struct device *dev, dma_addr_t dma_addr, size_t size, int direction) { struct dma_debug_entry ref = { - .type = dma_debug_single, + .type = dma_debug_phy, .dev = dev, .dev_addr = dma_addr, .size = size, diff --git a/kernel/dma/debug.h b/kernel/dma/debug.h index f525197d3cae..76adb42bffd5 100644 --- a/kernel/dma/debug.h +++ b/kernel/dma/debug.h @@ -9,12 +9,11 @@ #define _KERNEL_DMA_DEBUG_H #ifdef CONFIG_DMA_API_DEBUG -extern void debug_dma_map_page(struct device *dev, struct page *page, - size_t offset, size_t size, - int direction, dma_addr_t dma_addr, +extern void debug_dma_map_phys(struct device *dev, phys_addr_t phys, + size_t size, int direction, dma_addr_t dma_addr, unsigned long attrs); -extern void debug_dma_unmap_page(struct device *dev, dma_addr_t addr, +extern void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size, int direction); extern void debug_dma_map_sg(struct device *dev, struct scatterlist *sg, @@ -55,14 +54,13 @@ extern void debug_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems, int direction); #else /* CONFIG_DMA_API_DEBUG */ -static inline void debug_dma_map_page(struct device *dev, struct page *page, - size_t offset, size_t size, - int direction, dma_addr_t dma_addr, - unsigned long attrs) +static inline void debug_dma_map_phys(struct device *dev, phys_addr_t phys, + size_t size, int direction, + dma_addr_t dma_addr, unsigned long attrs) { } -static inline void debug_dma_unmap_page(struct device *dev, dma_addr_t addr, +static inline void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size, int direction) { } diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 107e4a4d251d..4c1dfbabb8ae 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -157,6 +157,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, unsigned long attrs) { const struct dma_map_ops *ops = get_dma_ops(dev); + phys_addr_t phys = page_to_phys(page) + offset; dma_addr_t addr; BUG_ON(!valid_dma_direction(dir)); @@ -165,16 +166,15 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, return DMA_MAPPING_ERROR; if (dma_map_direct(dev, ops) || - arch_dma_map_page_direct(dev, page_to_phys(page) + offset + size)) + arch_dma_map_page_direct(dev, phys + size)) addr = dma_direct_map_page(dev, page, offset, size, dir, attrs); else if (use_dma_iommu(dev)) addr = iommu_dma_map_page(dev, page, offset, size, dir, attrs); else addr = ops->map_page(dev, page, offset, size, dir, attrs); kmsan_handle_dma(page, offset, size, dir); - trace_dma_map_page(dev, page_to_phys(page) + offset, addr, size, dir, - attrs); - debug_dma_map_page(dev, page, offset, size, dir, addr, attrs); + trace_dma_map_page(dev, phys, addr, size, dir, attrs); + debug_dma_map_phys(dev, phys, size, dir, addr, attrs); return addr; } @@ -194,7 +194,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, else ops->unmap_page(dev, addr, size, dir, attrs); trace_dma_unmap_page(dev, addr, size, dir, attrs); - debug_dma_unmap_page(dev, addr, size, dir); + debug_dma_unmap_phys(dev, addr, size, dir); } EXPORT_SYMBOL(dma_unmap_page_attrs); @@ -712,7 +712,8 @@ struct page *dma_alloc_pages(struct device *dev, size_t size, if (page) { trace_dma_alloc_pages(dev, page_to_virt(page), *dma_handle, size, dir, gfp, 0); - debug_dma_map_page(dev, page, 0, size, dir, *dma_handle, 0); + debug_dma_map_phys(dev, page_to_phys(page), size, dir, + *dma_handle, 0); } else { trace_dma_alloc_pages(dev, NULL, 0, size, dir, gfp, 0); } @@ -738,7 +739,7 @@ void dma_free_pages(struct device *dev, size_t size, struct page *page, dma_addr_t dma_handle, enum dma_data_direction dir) { trace_dma_free_pages(dev, page_to_virt(page), dma_handle, size, dir, 0); - debug_dma_unmap_page(dev, dma_handle, size, dir); + debug_dma_unmap_phys(dev, dma_handle, size, dir); __dma_free_pages(dev, size, page, dma_handle, dir); } EXPORT_SYMBOL_GPL(dma_free_pages); -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106721.1457387 (Exim 4.92) (envelope-from ) id 1utSKG-0004If-GI; Tue, 02 Sep 2025 14:49:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106721.1457387; Tue, 02 Sep 2025 14: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 1utSKG-0004IQ-By; Tue, 02 Sep 2025 14:49:36 +0000 Received: by outflank-mailman (input) for mailman id 1106721; Tue, 02 Sep 2025 14:49: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 1utSKF-00028O-4e for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:35 +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 092628b9-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49:33 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 0C51C41994; Tue, 2 Sep 2025 14:49:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A196C4CEED; Tue, 2 Sep 2025 14:49: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: 092628b9-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824571; bh=H1qNdYxU1ovtF/Kf8Q7B45B32+Se6GftrqzmrTG8Akc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=agxG7jxNimedr+ehl5VL/FJJfWkaMHUW9N3eCg0O1tgYvMT9NgSaMNfnGfPrLahCh MRH1C8p1el2Pgvm6wVDXipR3AG8Cd5bz4MqKL18T/Dx8bMePVeLJKWgKIXU/CR7L+H kCCZ3f3LPrlMrDe3F1UUx75y9f4NLS4LEtQlywCdR4bgQwwX+S6jvPJagcFtGMPE2X 18Vq5j7QMhSuaasP6mIygRbKdmAJPXzruNfGaofMHxh1hw3iiwoIeHGDeEcyX/bdFo gt5fyWKJRg+d1ClXnnM4W0BdfqF95sxrSjrW7Ew2g0fYmKCUI+NQI0yGYZwDj9TiCH zcQjLoumK7NAg== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 07/16] dma-mapping: convert dma_direct_*map_page to be phys_addr_t based Date: Tue, 2 Sep 2025 17:48:44 +0300 Message-ID: <6b2f4cb436c98d6342db69e965a5621707b9711f.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Convert the DMA direct mapping functions to accept physical addresses directly instead of page+offset parameters. The functions were already operating on physical addresses internally, so this change eliminates the redundant page-to-physical conversion at the API boundary. The functions dma_direct_map_page() and dma_direct_unmap_page() are renamed to dma_direct_map_phys() and dma_direct_unmap_phys() respectively, with their calling convention changed from (struct page *page, unsigned long offset) to (phys_addr_t phys). Architecture-specific functions arch_dma_map_page_direct() and arch_dma_unmap_page_direct() are similarly renamed to arch_dma_map_phys_direct() and arch_dma_unmap_phys_direct(). The is_pci_p2pdma_page() checks are replaced with DMA_ATTR_MMIO checks to allow integration with dma_direct_map_resource and dma_direct_map_phys() is extended to support MMIO path either. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- arch/powerpc/kernel/dma-iommu.c | 4 +-- include/linux/dma-map-ops.h | 8 ++--- kernel/dma/direct.c | 6 ++-- kernel/dma/direct.h | 57 +++++++++++++++++++++------------ kernel/dma/mapping.c | 8 ++--- 5 files changed, 49 insertions(+), 34 deletions(-) diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c index 4d64a5db50f3..0359ab72cd3b 100644 --- a/arch/powerpc/kernel/dma-iommu.c +++ b/arch/powerpc/kernel/dma-iommu.c @@ -14,7 +14,7 @@ #define can_map_direct(dev, addr) \ ((dev)->bus_dma_limit >= phys_to_dma((dev), (addr))) -bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr) +bool arch_dma_map_phys_direct(struct device *dev, phys_addr_t addr) { if (likely(!dev->bus_dma_limit)) return false; @@ -24,7 +24,7 @@ bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr) #define is_direct_handle(dev, h) ((h) >= (dev)->archdata.dma_offset) -bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t dma_handle) +bool arch_dma_unmap_phys_direct(struct device *dev, dma_addr_t dma_handle) { if (likely(!dev->bus_dma_limit)) return false; diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h index f48e5fb88bd5..71f5b3025415 100644 --- a/include/linux/dma-map-ops.h +++ b/include/linux/dma-map-ops.h @@ -392,15 +392,15 @@ void *arch_dma_set_uncached(void *addr, size_t size); void arch_dma_clear_uncached(void *addr, size_t size); #ifdef CONFIG_ARCH_HAS_DMA_MAP_DIRECT -bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr); -bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t dma_handle); +bool arch_dma_map_phys_direct(struct device *dev, phys_addr_t addr); +bool arch_dma_unmap_phys_direct(struct device *dev, dma_addr_t dma_handle); bool arch_dma_map_sg_direct(struct device *dev, struct scatterlist *sg, int nents); bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist *sg, int nents); #else -#define arch_dma_map_page_direct(d, a) (false) -#define arch_dma_unmap_page_direct(d, a) (false) +#define arch_dma_map_phys_direct(d, a) (false) +#define arch_dma_unmap_phys_direct(d, a) (false) #define arch_dma_map_sg_direct(d, s, n) (false) #define arch_dma_unmap_sg_direct(d, s, n) (false) #endif diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 24c359d9c879..fa75e3070073 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -453,7 +453,7 @@ void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl, if (sg_dma_is_bus_address(sg)) sg_dma_unmark_bus_address(sg); else - dma_direct_unmap_page(dev, sg->dma_address, + dma_direct_unmap_phys(dev, sg->dma_address, sg_dma_len(sg), dir, attrs); } } @@ -476,8 +476,8 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents, */ break; case PCI_P2PDMA_MAP_NONE: - sg->dma_address = dma_direct_map_page(dev, sg_page(sg), - sg->offset, sg->length, dir, attrs); + sg->dma_address = dma_direct_map_phys(dev, sg_phys(sg), + sg->length, dir, attrs); if (sg->dma_address == DMA_MAPPING_ERROR) { ret = -EIO; goto out_unmap; diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h index d2c0b7e632fc..3f4792910604 100644 --- a/kernel/dma/direct.h +++ b/kernel/dma/direct.h @@ -80,42 +80,57 @@ static inline void dma_direct_sync_single_for_cpu(struct device *dev, arch_dma_mark_clean(paddr, size); } -static inline dma_addr_t dma_direct_map_page(struct device *dev, - struct page *page, unsigned long offset, size_t size, - enum dma_data_direction dir, unsigned long attrs) +static inline dma_addr_t dma_direct_map_phys(struct device *dev, + phys_addr_t phys, size_t size, enum dma_data_direction dir, + unsigned long attrs) { - phys_addr_t phys = page_to_phys(page) + offset; - dma_addr_t dma_addr = phys_to_dma(dev, phys); + dma_addr_t dma_addr; if (is_swiotlb_force_bounce(dev)) { - if (is_pci_p2pdma_page(page)) - return DMA_MAPPING_ERROR; + if (attrs & DMA_ATTR_MMIO) + goto err_overflow; + return swiotlb_map(dev, phys, size, dir, attrs); } - if (unlikely(!dma_capable(dev, dma_addr, size, true)) || - dma_kmalloc_needs_bounce(dev, size, dir)) { - if (is_pci_p2pdma_page(page)) - return DMA_MAPPING_ERROR; - if (is_swiotlb_active(dev)) - return swiotlb_map(dev, phys, size, dir, attrs); - - dev_WARN_ONCE(dev, 1, - "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n", - &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit); - return DMA_MAPPING_ERROR; + if (attrs & DMA_ATTR_MMIO) { + dma_addr = phys; + if (unlikely(dma_capable(dev, dma_addr, size, false))) + goto err_overflow; + } else { + dma_addr = phys_to_dma(dev, phys); + if (unlikely(!dma_capable(dev, dma_addr, size, true)) || + dma_kmalloc_needs_bounce(dev, size, dir)) { + if (is_swiotlb_active(dev)) + return swiotlb_map(dev, phys, size, dir, attrs); + + goto err_overflow; + } } - if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) + if (!dev_is_dma_coherent(dev) && + !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO))) arch_sync_dma_for_device(phys, size, dir); return dma_addr; + +err_overflow: + dev_WARN_ONCE( + dev, 1, + "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n", + &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit); + return DMA_MAPPING_ERROR; } -static inline void dma_direct_unmap_page(struct device *dev, dma_addr_t addr, +static inline void dma_direct_unmap_phys(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { - phys_addr_t phys = dma_to_phys(dev, addr); + phys_addr_t phys; + + if (attrs & DMA_ATTR_MMIO) + /* nothing to do: uncached and no swiotlb */ + return; + phys = dma_to_phys(dev, addr); if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC)) dma_direct_sync_single_for_cpu(dev, addr, size, dir); diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 58482536db9b..80481a873340 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -166,8 +166,8 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, return DMA_MAPPING_ERROR; if (dma_map_direct(dev, ops) || - arch_dma_map_page_direct(dev, phys + size)) - addr = dma_direct_map_page(dev, page, offset, size, dir, attrs); + arch_dma_map_phys_direct(dev, phys + size)) + addr = dma_direct_map_phys(dev, phys, size, dir, attrs); else if (use_dma_iommu(dev)) addr = iommu_dma_map_phys(dev, phys, size, dir, attrs); else @@ -187,8 +187,8 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, BUG_ON(!valid_dma_direction(dir)); if (dma_map_direct(dev, ops) || - arch_dma_unmap_page_direct(dev, addr + size)) - dma_direct_unmap_page(dev, addr, size, dir, attrs); + arch_dma_unmap_phys_direct(dev, addr + size)) + dma_direct_unmap_phys(dev, addr, size, dir, attrs); else if (use_dma_iommu(dev)) iommu_dma_unmap_phys(dev, addr, size, dir, attrs); else -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:49:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:49:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106728.1457397 (Exim 4.92) (envelope-from ) id 1utSKK-0004m6-RS; Tue, 02 Sep 2025 14:49:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106728.1457397; Tue, 02 Sep 2025 14:49:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSKK-0004lx-NG; Tue, 02 Sep 2025 14:49:40 +0000 Received: by outflank-mailman (input) for mailman id 1106728; Tue, 02 Sep 2025 14:49: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 1utSKJ-00028O-Vk for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:39 +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 0bda40ed-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49:37 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 9473A60222; Tue, 2 Sep 2025 14:49:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98CE2C4CEED; Tue, 2 Sep 2025 14:49: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: 0bda40ed-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824576; bh=sM+8A+mz8+vtMpvBupjrACoA7oSb6yM+3fTTBdtuWbE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CCnOPMO8OIfrdGQAw+IhIZhMZWCRKoDf4dQGPY29Dd/hDfXBfnF+b+xOpOG4qpI+J AHBThBcabS43lQECzg9G+ilemXSQ+Y8oPbO5KYb+db4yDJGohbLypwTIReUbV3pDt7 b1zwjJ9TpAgB3K3eJ24kdhUiG+Wng+01rXNX+6t6LyxkcHwvqQWKSM1yPPkKgtMVlh yn6Nuz2D3XZYCPtmAwCWYcE1iUpyYvDpJJafVUMXys4IVp1R9kAJAx1wKdWT2kOeAm 9vHzCM0WTGj6hP77HR+YyjtPFUvn0xAAW8QrPmD6XiDoAW9WhmKB8bAWqfa+hYHi6k B/FMTB65CPigw== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 08/16] kmsan: convert kmsan_handle_dma to use physical addresses Date: Tue, 2 Sep 2025 17:48:45 +0300 Message-ID: <9f59c7c5ca21b39cdc90696f270ec6b04c92abf6.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Convert the KMSAN DMA handling function from page-based to physical address-based interface. The refactoring renames kmsan_handle_dma() parameters from accepting (struct page *page, size_t offset, size_t size) to (phys_addr_t phys, size_t size). The existing semantics where callers are expected to provide only kmap memory is continued here. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- drivers/virtio/virtio_ring.c | 4 ++-- include/linux/kmsan.h | 9 ++++----- kernel/dma/mapping.c | 3 ++- mm/kmsan/hooks.c | 8 +++++--- tools/virtio/linux/kmsan.h | 2 +- 5 files changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index f5062061c408..c147145a6593 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -378,7 +378,7 @@ static int vring_map_one_sg(const struct vring_virtqueue *vq, struct scatterlist * is initialized by the hardware. Explicitly check/unpoison it * depending on the direction. */ - kmsan_handle_dma(sg_page(sg), sg->offset, sg->length, direction); + kmsan_handle_dma(sg_phys(sg), sg->length, direction); *addr = (dma_addr_t)sg_phys(sg); return 0; } @@ -3157,7 +3157,7 @@ dma_addr_t virtqueue_dma_map_single_attrs(struct virtqueue *_vq, void *ptr, struct vring_virtqueue *vq = to_vvq(_vq); if (!vq->use_dma_api) { - kmsan_handle_dma(virt_to_page(ptr), offset_in_page(ptr), size, dir); + kmsan_handle_dma(virt_to_phys(ptr), size, dir); return (dma_addr_t)virt_to_phys(ptr); } diff --git a/include/linux/kmsan.h b/include/linux/kmsan.h index 2b1432cc16d5..f2fd221107bb 100644 --- a/include/linux/kmsan.h +++ b/include/linux/kmsan.h @@ -182,8 +182,7 @@ void kmsan_iounmap_page_range(unsigned long start, unsigned long end); /** * kmsan_handle_dma() - Handle a DMA data transfer. - * @page: first page of the buffer. - * @offset: offset of the buffer within the first page. + * @phys: physical address of the buffer. * @size: buffer size. * @dir: one of possible dma_data_direction values. * @@ -192,7 +191,7 @@ void kmsan_iounmap_page_range(unsigned long start, unsigned long end); * * initializes the buffer, if it is copied from device; * * does both, if this is a DMA_BIDIRECTIONAL transfer. */ -void kmsan_handle_dma(struct page *page, size_t offset, size_t size, +void kmsan_handle_dma(phys_addr_t phys, size_t size, enum dma_data_direction dir); /** @@ -372,8 +371,8 @@ static inline void kmsan_iounmap_page_range(unsigned long start, { } -static inline void kmsan_handle_dma(struct page *page, size_t offset, - size_t size, enum dma_data_direction dir) +static inline void kmsan_handle_dma(phys_addr_t phys, size_t size, + enum dma_data_direction dir) { } diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 80481a873340..891e1fc3e582 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -172,7 +172,8 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, addr = iommu_dma_map_phys(dev, phys, size, dir, attrs); else addr = ops->map_page(dev, page, offset, size, dir, attrs); - kmsan_handle_dma(page, offset, size, dir); + + kmsan_handle_dma(phys, size, dir); trace_dma_map_phys(dev, phys, addr, size, dir, attrs); debug_dma_map_phys(dev, phys, size, dir, addr, attrs); diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c index 97de3d6194f0..ea6d1de19ede 100644 --- a/mm/kmsan/hooks.c +++ b/mm/kmsan/hooks.c @@ -336,14 +336,16 @@ static void kmsan_handle_dma_page(const void *addr, size_t size, } /* Helper function to handle DMA data transfers. */ -void kmsan_handle_dma(struct page *page, size_t offset, size_t size, +void kmsan_handle_dma(phys_addr_t phys, size_t size, enum dma_data_direction dir) { - u64 page_offset, to_go, addr; + struct page *page = phys_to_page(phys); + u64 page_offset, to_go; + void *addr; if (PageHighMem(page)) return; - addr = (u64)page_address(page) + offset; + addr = page_to_virt(page); /* * The kernel may occasionally give us adjacent DMA pages not belonging * to the same allocation. Process them separately to avoid triggering diff --git a/tools/virtio/linux/kmsan.h b/tools/virtio/linux/kmsan.h index 272b5aa285d5..6cd2e3efd03d 100644 --- a/tools/virtio/linux/kmsan.h +++ b/tools/virtio/linux/kmsan.h @@ -4,7 +4,7 @@ #include -inline void kmsan_handle_dma(struct page *page, size_t offset, size_t size, +inline void kmsan_handle_dma(phys_addr_t phys, size_t size, enum dma_data_direction dir) { } -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:50:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:50:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106767.1457406 (Exim 4.92) (envelope-from ) id 1utSLP-0007Gj-9F; Tue, 02 Sep 2025 14:50:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106767.1457406; Tue, 02 Sep 2025 14: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 1utSLP-0007Gc-6X; Tue, 02 Sep 2025 14:50:47 +0000 Received: by outflank-mailman (input) for mailman id 1106767; Tue, 02 Sep 2025 14: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 1utSKr-0002MQ-4O for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:50: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 204bf79e-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:50: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 D3F4C41994; Tue, 2 Sep 2025 14:50:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF152C4CEED; Tue, 2 Sep 2025 14:50: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: 204bf79e-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824610; bh=loKqVytyVDIeLrj3FO1P5XlYadT3usoA9sJi/ZhWYE4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XDqouYHc8vRB0ajJZqK4lwxspBtMW6b4AWggjQsPi5/K2g2R10AjUbWT8azo/7M7O N6Jh6bQk4hBxULYIt59wnr7HzVq+T18QfRotRvkr6SqeRycgt3KrMgeI2f9YoYF65R AMah6TQRO20arumHElmz/9xJv71VS+55KKRTzUhrWxBMRXKYC/ULWECIEily7rCTXe eS9NQqKv9qVWkNYpMk5mwrAgRsMMcEg2+JJNlzJdw/9SSH0fatvocB6pT/Dy/lfKbD W+rnlIzxGxfqLNVSwZwF1T0salbWquRx/dFWfgfMqcj//UlZSSQb08JaE3KYrMoHxH hxEoSoVhdeDtQ== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 16/16] nvme-pci: unmap MMIO pages with appropriate interface Date: Tue, 2 Sep 2025 17:48:53 +0300 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Block layer maps MMIO memory through dma_map_phys() interface with help of DMA_ATTR_MMIO attribute. There is a need to unmap that memory with the appropriate unmap function, something which wasn't possible before adding new REQ attribute to block layer in previous patch. Reviewed-by: Keith Busch Signed-off-by: Leon Romanovsky --- drivers/nvme/host/pci.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 2c6d9506b172..f8ecc0e0f576 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -682,11 +682,15 @@ static void nvme_free_prps(struct request *req) { struct nvme_iod *iod = blk_mq_rq_to_pdu(req); struct nvme_queue *nvmeq = req->mq_hctx->driver_data; + unsigned int attrs = 0; unsigned int i; + if (req->cmd_flags & REQ_MMIO) + attrs = DMA_ATTR_MMIO; + for (i = 0; i < iod->nr_dma_vecs; i++) - dma_unmap_page(nvmeq->dev->dev, iod->dma_vecs[i].addr, - iod->dma_vecs[i].len, rq_dma_dir(req)); + dma_unmap_phys(nvmeq->dev->dev, iod->dma_vecs[i].addr, + iod->dma_vecs[i].len, rq_dma_dir(req), attrs); mempool_free(iod->dma_vecs, nvmeq->dev->dmavec_mempool); } @@ -699,15 +703,19 @@ static void nvme_free_sgls(struct request *req) unsigned int sqe_dma_len = le32_to_cpu(iod->cmd.common.dptr.sgl.length); struct nvme_sgl_desc *sg_list = iod->descriptors[0]; enum dma_data_direction dir = rq_dma_dir(req); + unsigned int attrs = 0; + + if (req->cmd_flags & REQ_MMIO) + attrs = DMA_ATTR_MMIO; if (iod->nr_descriptors) { unsigned int nr_entries = sqe_dma_len / sizeof(*sg_list), i; for (i = 0; i < nr_entries; i++) - dma_unmap_page(dma_dev, le64_to_cpu(sg_list[i].addr), - le32_to_cpu(sg_list[i].length), dir); + dma_unmap_phys(dma_dev, le64_to_cpu(sg_list[i].addr), + le32_to_cpu(sg_list[i].length), dir, attrs); } else { - dma_unmap_page(dma_dev, sqe_dma_addr, sqe_dma_len, dir); + dma_unmap_phys(dma_dev, sqe_dma_addr, sqe_dma_len, dir, attrs); } } -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:50:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:50:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106775.1457418 (Exim 4.92) (envelope-from ) id 1utSLb-0007hl-IJ; Tue, 02 Sep 2025 14:50:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106775.1457418; Tue, 02 Sep 2025 14:50: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 1utSLb-0007h1-Cd; Tue, 02 Sep 2025 14:50:59 +0000 Received: by outflank-mailman (input) for mailman id 1106775; Tue, 02 Sep 2025 14:50: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 1utSKa-0002MQ-3M for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:56 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 15e46215-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49:54 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6DD06409E2; Tue, 2 Sep 2025 14:49:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E5E9C4CEED; Tue, 2 Sep 2025 14:49: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: 15e46215-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824593; bh=O9XZOHlHvjORXmOt4kTIQrFLHTrONFqw1ae8lUbcYw8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i4LP/8sFn4GJsZ/wYwZJG+51+koOumcx5kwuswjw9uzDtXu5nJFVYiFdkD5Pd0XDV CJojBBl/IcJFZ1DnDDaW5/OvJIPqgpfNaVsr+q2jlXPVvC5bdwVF7QKxf4Ph4v8jOj 2HjHKIF3azuV23NGrP/L0kmkIoLbU77FsGzLAIB4etR8CjLv/mm1W+Rm9wG7Wi20Qf 9bCfB5IoI0J0AUn4bKcg7P3o/CnocQo4hvP2QVxf1pC/4M65ApXfrRdTznGR7HL9EL UCDZyXx1Bbm4fIIthh7q4BpOhb2peNDAk4t3Me9zhw16A5tgAwshGbvt8aoBahblXj yINBs05SJGpZQ== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 12/16] mm/hmm: migrate to physical address-based DMA mapping API Date: Tue, 2 Sep 2025 17:48:49 +0300 Message-ID: <90d2f14352494d615d3a5d1251126c88f96a4171.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Convert HMM DMA operations from the legacy page-based API to the new physical address-based dma_map_phys() and dma_unmap_phys() functions. This demonstrates the preferred approach for new code that should use physical addresses directly rather than page+offset parameters. The change replaces dma_map_page() and dma_unmap_page() calls with dma_map_phys() and dma_unmap_phys() respectively, using the physical address that was already available in the code. This eliminates the redundant page-to-physical address conversion and aligns with the DMA subsystem's move toward physical address-centric interfaces. This serves as an example of how new code should be written to leverage the more efficient physical address API, which provides cleaner interfaces for drivers that already have access to physical addresses. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- mm/hmm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index d545e2494994..015ab243f081 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -775,8 +775,8 @@ dma_addr_t hmm_dma_map_pfn(struct device *dev, struct hmm_dma_map *map, if (WARN_ON_ONCE(dma_need_unmap(dev) && !dma_addrs)) goto error; - dma_addr = dma_map_page(dev, page, 0, map->dma_entry_size, - DMA_BIDIRECTIONAL); + dma_addr = dma_map_phys(dev, paddr, map->dma_entry_size, + DMA_BIDIRECTIONAL, 0); if (dma_mapping_error(dev, dma_addr)) goto error; @@ -819,8 +819,8 @@ bool hmm_dma_unmap_pfn(struct device *dev, struct hmm_dma_map *map, size_t idx) dma_iova_unlink(dev, state, idx * map->dma_entry_size, map->dma_entry_size, DMA_BIDIRECTIONAL, attrs); } else if (dma_need_unmap(dev)) - dma_unmap_page(dev, dma_addrs[idx], map->dma_entry_size, - DMA_BIDIRECTIONAL); + dma_unmap_phys(dev, dma_addrs[idx], map->dma_entry_size, + DMA_BIDIRECTIONAL, 0); pfns[idx] &= ~(HMM_PFN_DMA_MAPPED | HMM_PFN_P2PDMA | HMM_PFN_P2PDMA_BUS); -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:50:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:50:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106777.1457422 (Exim 4.92) (envelope-from ) id 1utSLb-0007ja-Or; Tue, 02 Sep 2025 14:50:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106777.1457422; Tue, 02 Sep 2025 14:50: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 1utSLb-0007ik-JT; Tue, 02 Sep 2025 14:50:59 +0000 Received: by outflank-mailman (input) for mailman id 1106777; Tue, 02 Sep 2025 14:50: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 1utSKQ-0002MQ-N3 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:46 +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 0fa61ff6-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49:43 +0200 (CEST) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-45b7d87b90fso37904145e9.0 for ; Tue, 02 Sep 2025 07:49:43 -0700 (PDT) Received: from localhost.localdomain (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3cf33fb9431sm19919809f8f.44.2025.09.02.07.49.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 07:49: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: 0fa61ff6-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756824582; x=1757429382; darn=lists.xenproject.org; h=content-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=KtZ7c0T5fMSKg4BzhqMTADQxM87Ecx0Up5U2mRA5ChQ=; b=ID5ufqhGhYq2w1fHR0vQXAYke8WX7eE+PTnoBiNHxvok0x34uM4DsdfnClICup7u3M a/gmtOwZukh5We+McxOPpxhhNc+kJLBfuestkkrE5DG2co+DVbXEr9X2Uf02Pxr70c60 sLS74xK+hdicLxKmGhd/8smn7hiQWonDK8D+o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756824582; x=1757429382; 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=KtZ7c0T5fMSKg4BzhqMTADQxM87Ecx0Up5U2mRA5ChQ=; b=A2j7e25TOsek4tKBsV4weS8+N15UZ2+tkRGGB0rb0E3XeXuOeKeh6gi/4d5lPBN7Cp yrTGTTQZmyOZ5Y+n5Q9+goWdJukDRo+NrkBDYV1l5xRYHngHDliTvMTY+3Ag5+Jatgif GTpCL6Bge06up2l8D9ETSgkoUz8ctvxxN3p+mkgrxucPtu6rn/jBpyHifSmccHxNwyMH Kpt7epU8DWJM0vAWHpRYGs3hQKHwekw/rHsY0iqlSZeBH8iGdWq1Y9szJ3ORN5jWp9nR H+QyP5lrP5iU5gegMnsvupD9vNAoL/wS17vAr8DXBEiCi25nQfNao+kJoAYN3agdUzry Nbmg== X-Gm-Message-State: AOJu0YyZkleHiuA8p2PLjABz3jhP6gXzKer15t91Fd+dRTPVeUp6YczD c/pqikEn2WbwLPF/POze4vvzUSFLBuduxHKQvXvKMlPmjaAJE3QefY8q3aPZBrYc351NmdQ6yW2 BbYLS X-Gm-Gg: ASbGncvuEGZlK5gnxupMaT14bppE1h2ZtBDhqv/XAhq6cHWvomseZJNqYGGpAzY29Gx a/NdYkgmwN/g5XlzpVBjN2GWgPv892GFZkbNh9CNbL/fxs0818ap06o1JhBliIjMR5+eb92kWL/ 8d6dot5k5ZpHuijbC4d836yk+u6kpzRqjkQRwfZhtH97PPkXL0S9r5QSyMO7Dtp6l6HEHBvhGSR gnlSy9vKOQLa9oUtDdHzX7m2Z9S7taqYwkyNW6WzQk0Umbv2Dl1+Xifw9B6zRjp/7ju84pEfS5q d+GFmuR6W9C9yfnhQ1cAKcpxtZoTE4rvj/0CyIHGKpjRJvUV265d64mRKjOvXVnD20WnrMGKL+K 1cKegEp3tUoN6rbGKhAxvAxja3a951L1y965we1WbvRKU56j18Gyiukc5FiosAXakJ9wvScOXQb tB X-Google-Smtp-Source: AGHT+IGIn8CTVoBnFgfWrk0uTKOhN2jQz02u0B5Lx2Hhy3eX5vzQYybySn5vFq7YTf5gONJMoNYNTg== X-Received: by 2002:a05:600c:19d3:b0:45b:8ac2:9761 with SMTP id 5b1f17b1804b1-45b8ac299a1mr80312755e9.13.1756824582367; Tue, 02 Sep 2025 07:49:42 -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 , Juergen Gross Subject: [PATCH 2/2] tools/misc: Move ignores into local .gitignore Date: Tue, 2 Sep 2025 15:49:37 +0100 Message-Id: <20250902144937.1414411-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250902144937.1414411-1-andrew.cooper3@citrix.com> References: <20250902144937.1414411-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ... instead of having them split across multiple. No functional change. 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: Juergen Gross --- .gitignore | 15 --------------- tools/misc/.gitignore | 15 +++++++++++++++ 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/.gitignore b/.gitignore index 84a01e8afe6a..d83427aba8cb 100644 --- a/.gitignore +++ b/.gitignore @@ -137,15 +137,6 @@ tools/include/_libxl*.h tools/include/xen-xsm/* tools/include/xen-foreign/*.(c|h|size) tools/include/xen-foreign/checker -tools/misc/xen-cpuid -tools/misc/xen-detect -tools/misc/xen-diag -tools/misc/xen-livepatch -tools/misc/xenperf -tools/misc/xenpm -tools/misc/xen-hvmctx -tools/misc/xenlockprof -tools/misc/xencov tools/pkg-config/* tools/qemu-xen-build tools/xentrace/xenalyze @@ -253,14 +244,8 @@ tools/include/xen-foreign/x86_64.h tools/include/xen-foreign/arm32.h tools/include/xen-foreign/arm64.h -tools/misc/xen-hptool -tools/misc/xen-mfndump tools/firmware/etherboot/eb-roms.h tools/firmware/etherboot/gpxe-git-snapshot.tar.gz -tools/misc/xenhypfs -tools/misc/xenwatchdogd -tools/misc/xen-hvmcrash -tools/misc/xen-lowmemd tools/vchan/vchan-node[12] tools/vchan/vchan-socket-proxy tools/debugger/kdd/kdd diff --git a/tools/misc/.gitignore b/tools/misc/.gitignore index 73ce95e6d77e..28af46280fa0 100644 --- a/tools/misc/.gitignore +++ b/tools/misc/.gitignore @@ -1,5 +1,20 @@ xen-access +xen-cpuid +xen-detect +xen-diag +xen-hptool +xen-hvmcrash +xen-hvmctx +xen-livepatch +xen-lowmemd xen-mceinj xen-memshare +xen-mfndump xen-ucode xen-vmtrace +xencov +xenhypfs +xenlockprof +xenperf +xenpm +xenwatchdogd -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106778.1457429 (Exim 4.92) (envelope-from ) id 1utSLc-0007pA-5x; Tue, 02 Sep 2025 14:51:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106778.1457429; Tue, 02 Sep 2025 14: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 1utSLb-0007oN-St; Tue, 02 Sep 2025 14:50:59 +0000 Received: by outflank-mailman (input) for mailman id 1106778; Tue, 02 Sep 2025 14:50: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 1utSKN-0002MQ-Me for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:43 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0ec5ff89-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49:42 +0200 (CEST) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-45b8e28b3c5so12722245e9.1 for ; Tue, 02 Sep 2025 07:49:42 -0700 (PDT) Received: from localhost.localdomain (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3cf33fb9431sm19919809f8f.44.2025.09.02.07.49.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 07:49: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: 0ec5ff89-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756824581; x=1757429381; 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=KpBnT7I8p7FGPb0FeHkvOUb1B4lVXyTx0EhHtDjZ/gk=; b=F4K9n091ZSqImpqPqnF/nta1pOFb228xQyD4GloexrK1tZFvOZq1GwljHg40nxjYAH SPwj6xG3CU30isemBbwyeht3bx0ictM1RmhSc7soS8RbiN3d/tBfmtn4C1qmIQUfhr4y cN3N07FnhEKjPpFZRjLUvSinn1aBUXr1o+KVg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756824581; x=1757429381; 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=KpBnT7I8p7FGPb0FeHkvOUb1B4lVXyTx0EhHtDjZ/gk=; b=VuZK8I178vZtqQGSMZGIrG64ypX8jBIJNAIvV14npehhNCxg+mu7pHOppvM/OsWTeI fBeO77bgH7X6N738i0zBtOmFvYPYn2UAGZXH7eoddRg51Mh3TG20DiQd6w0nxcjoT11l YN3WKiwc4a7KqLYcPL9o8UqV6kd2C1cqKTALpHWYesTB00nrGtA1U0HUaOFoTdjU3QYm cbomqStrcRpYCSIv92hAgxQbBY0RPpqpw3OQ1+yRNuQ2pDpKMQI3L+/+l3FjxNkbvzf6 y0su+udFq084m+AvI/6e+U+YigdzwSAo4LlB5raIoC1R/Xti33N2O9LxgYjhChe131SY sUqA== X-Gm-Message-State: AOJu0Yw83C1uJ41sHDw1vTXFdov1Pgvsj0issSiBqeYCTHaNbvtcUlCy NkS2PPSvZs8Xrg7s56xrhPWoXpwY2N0sjTxPuTQr92U1CVkoh7exUPIXrAeGG4KTVvymuPzpuxv S6Try X-Gm-Gg: ASbGnctJ4XUFVyJXzepkpLSizm4Td7sNbUKxd1Tnr9CGunD+P3XTQjUnWDfH3ca5XgY kTXOkcVV17+x4sH/KpZ4UVPWl9QRPFeB3+F34JdTuF7+ujP50fn8IC2U9ql4E8gSkS1j5vH0qmP qfn10U1ERGR94DvBtmg2b+miSOj4FyqaMeShh/hllNw5IE6Zrk2NROEXKbJd0DHS+5v8XTRi/cK p0iGFwJf+wJ1OrMKGVan8urmkrqaq3ccociUluAZz3er9K1RjXUlAv6Wv9Xq75qItz1KSt4nGG3 AT/DI16LPgFFXTEwbKrT8TVVx5zONkrfSqpuj+ElQBT0XV5qsIUeK/dkctAiK2H3/66szDidf+Q Nqsc8SEScghj8CbuW6XY0nUU+AL9XxH4JukUJ+XAkVvuAg2c7nzV06gabLwLzue8iGEnls7qvjP +536dyXg+K74o= X-Google-Smtp-Source: AGHT+IH7++S7yfO6nacueI2+WT/DeIbZ1fpbJq1Rc6I0UNJFkpUfi3x1f3TfZrPibuif+CVEFCe6jQ== X-Received: by 2002:a05:600c:1713:b0:45b:9548:c1a2 with SMTP id 5b1f17b1804b1-45b9548c1eamr21865175e9.3.1756824580760; Tue, 02 Sep 2025 07:49:40 -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 , Juergen Gross Subject: [PATCH 1/2] Tidy up .gitignore Date: Tue, 2 Sep 2025 15:49:36 +0100 Message-Id: <20250902144937.1414411-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 Drop unused or stale lines. * While it's necessary to have .git and .hg in each others ignore files if using multiple SCMs (as we did for a while), they should not be in their own. * The ignore for LibVNCServer* was added by commit a090ca495e7f ("VNC pasword authentication support for the paravirt framebuffer server.") (2006) but without justification or any obvious reason. * The ignore for tools/misc/lowmemd was added in commit c812282081bb ("Low mem virq incremental adjustments") (2012), but xen-lowmemd (from the same author) already existed and was ignored properly. * tools/libs/guest/xc_* were added in commit af6c78d9dc68 ("tools: move libxenctrl below tools/libs") for bisectibility, but should have been dropped in the following change, commit e3dd624e487c ("tools/libxc: move libxenguest to tools/libs/guest"). * tools/debugger/xenitp/ was dropped in commit e567964a54b8 ("tools: drop ia64 support") (2012). * tools/debugger/gdb/ was dropped in commit baa1aae9cfdd ("tools/debugger/gdb: Remove gdb") (2010). * tools/misc/cpuperf/ was dropped in commit ae95fdf65a72 ("[TOOLS] Remove the 'cpuperf' misc tool.") (2006). * tools/misc/xc_shadow was dropped in commit 7133144e3abf ("Remove xc_shadow tool") (2007). * tools/misc/xen_cpuperf was dropped in commit 60eba9b0d265 ("Delete some unused tools") (2004). * tools/misc/xen-tmem-list-parse was dropped in commit c588c002cc19 ("tools: remove tmem code and commands") (2018). No functional change. 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: Juergen Gross I'm sure there's more to clean up, but I've already been playing archeology too long on this. --- .gitignore | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/.gitignore b/.gitignore index 7b7f5e7a4ad3..84a01e8afe6a 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,3 @@ -.hg .*.cmd .*.d .*.d2 @@ -62,11 +61,6 @@ tools/config.cache config/Tools.mk config/Stubdom.mk config/Docs.mk -tools/libs/guest/xc_bitops.h -tools/libs/guest/xc_core.h -tools/libs/guest/xc_core_arm.h -tools/libs/guest/xc_core_x86.h -tools/libs/guest/xc_private.h tools/libs/light/_*.[ch] tools/libs/light/*.pyc tools/libs/light/_libxl.api-for-check @@ -84,11 +78,7 @@ tools/libs/store/list.h tools/libs/store/utils.h tools/libs/store/xs_lib.c tools/libs/util/libxlu_cfg_y.output -tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/* -tools/debugger/gdb/gdb-6.2.1/* -tools/debugger/gdb/gdb-6.2.1.tar.bz2 tools/debugger/gdbsx/gdbsx -tools/debugger/xenitp/xenitp tools/firmware/*/biossums tools/firmware/*.bin tools/firmware/*.sym @@ -147,20 +137,14 @@ tools/include/_libxl*.h tools/include/xen-xsm/* tools/include/xen-foreign/*.(c|h|size) tools/include/xen-foreign/checker -tools/misc/cpuperf/cpuperf-perfcntr -tools/misc/cpuperf/cpuperf-xen -tools/misc/xc_shadow -tools/misc/xen_cpuperf tools/misc/xen-cpuid tools/misc/xen-detect tools/misc/xen-diag -tools/misc/xen-tmem-list-parse tools/misc/xen-livepatch tools/misc/xenperf tools/misc/xenpm tools/misc/xen-hvmctx tools/misc/xenlockprof -tools/misc/lowmemd tools/misc/xencov tools/pkg-config/* tools/qemu-xen-build @@ -249,7 +233,6 @@ xen/suppression-list.txt xen/xen-syms xen/xen-syms.map xen/xen.* -LibVNCServer* tools/qemu-xen-dir-remote tools/qemu-xen-dir @@ -270,7 +253,6 @@ tools/include/xen-foreign/x86_64.h tools/include/xen-foreign/arm32.h tools/include/xen-foreign/arm64.h -.git tools/misc/xen-hptool tools/misc/xen-mfndump tools/firmware/etherboot/eb-roms.h base-commit: 437f07b2b52b32929c74c2e19a52437ce7e5b88f -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:11 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106786.1457447 (Exim 4.92) (envelope-from ) id 1utSLn-0000Gg-8Y; Tue, 02 Sep 2025 14:51:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106786.1457447; Tue, 02 Sep 2025 14: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 1utSLn-0000GT-4f; Tue, 02 Sep 2025 14:51:11 +0000 Received: by outflank-mailman (input) for mailman id 1106786; Tue, 02 Sep 2025 14: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 1utSKd-0002MQ-DH for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:59 +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 188cd5a1-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:49:58 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id E282C6021C; Tue, 2 Sep 2025 14:49:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98E4CC4CEED; Tue, 2 Sep 2025 14:49: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: 188cd5a1-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824597; bh=/+yFJK+B9QWHuc4E4Qjbxe4FKpOF4Mx7ckvNMqksRwM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eiIBn3T8WJVWsk3+I+fWd3PcxI0MCgzuCoUFUQ6X0tpaWBWbgKoyqfqOHBiWDIDiz 8p2HzbdfWqrQ60dofPqEdpLkK9IHTbg+v0SJZIYuCE/Og1VxxZlScreKdr1eSpD3sv /lx+bgPY7bT+Oe8q5/ipZoWvP5MZL/8U72Kogd0uDRyxsAmDtlwDjYXaLUb/vJvMBs v49CTWymtxxZQxWHK2HkfHOmNrocouCJRvv5qbRPaGPjvko9idbzbdGVkH62OwjqKI vcrbLiVodBbFcdGUzIrgeZ2fajxcWR0pq3lieMm1b99+a2xYHhXEQceE1aYKlKJK7C vmv2Md05FkfjQ== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 10/16] xen: swiotlb: Open code map_resource callback Date: Tue, 2 Sep 2025 17:48:47 +0300 Message-ID: <7e3225a24df41b483d60d87450b610b399bc15ca.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky General dma_direct_map_resource() is going to be removed in next patch, so simply open-code it in xen driver. Reviewed-by: Juergen Gross Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- drivers/xen/swiotlb-xen.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index da1a7d3d377c..dd7747a2de87 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -392,6 +392,25 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct scatterlist *sgl, } } +static dma_addr_t xen_swiotlb_direct_map_resource(struct device *dev, + phys_addr_t paddr, + size_t size, + enum dma_data_direction dir, + unsigned long attrs) +{ + dma_addr_t dma_addr = paddr; + + if (unlikely(!dma_capable(dev, dma_addr, size, false))) { + dev_err_once(dev, + "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n", + &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit); + WARN_ON_ONCE(1); + return DMA_MAPPING_ERROR; + } + + return dma_addr; +} + /* * Return whether the given device DMA address mask can be supported * properly. For example, if your device can only drive the low 24-bits @@ -426,5 +445,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = { .alloc_pages_op = dma_common_alloc_pages, .free_pages = dma_common_free_pages, .max_mapping_size = swiotlb_max_mapping_size, - .map_resource = dma_direct_map_resource, + .map_resource = xen_swiotlb_direct_map_resource, }; -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106809.1457457 (Exim 4.92) (envelope-from ) id 1utSM0-0001Bt-Lj; Tue, 02 Sep 2025 14:51:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106809.1457457; Tue, 02 Sep 2025 14:51: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 1utSM0-0001Bh-Hn; Tue, 02 Sep 2025 14:51:24 +0000 Received: by outflank-mailman (input) for mailman id 1106809; Tue, 02 Sep 2025 14:51: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 1utSKu-0002MQ-KO for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:50:16 +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 228a0df4-880c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 16:50:15 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id A15CE43588; Tue, 2 Sep 2025 14:50:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3108C4CEED; Tue, 2 Sep 2025 14:50: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: 228a0df4-880c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824614; bh=5GnXky7X8jRP4E4M761xyU7kxSqR5w3y9HvcAnisW/0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rJeu6B43+1PA3hIr12hg0lnVgq8hEaO1Lw0dSu66C4Hxh6OtUnH4qrmq2UzSSZ1N4 l2ZMHW11no8o4RgcofoNHTdHE1yoSWlx22rWWSHOD8+Ogvu4ojzleuOhx12qfasdh8 1xBycpNin9JG/1JisPEuSXMSjGw3Xeby21NvKY8cKczB0oynk2yRys0EmsHljVnB3u KBLTyBq9WFsVfFALrQa4WJtvJqzt56sC8sAjNNKhzQLMvhf/aVz1+461ufH6pc4SF9 +Mv7reAnOosbLyMyMqxFSSvL8KoRwphakYFROv2rFhXteTJEarDn/NkqrxQfsDao9k qBoW5Cs7du2bQ== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 13/16] mm/hmm: properly take MMIO path Date: Tue, 2 Sep 2025 17:48:50 +0300 Message-ID: <4aac9ae9c0fe39a2e47139fae6d602f71d90bd09.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky In case peer-to-peer transaction traverses through host bridge, the IOMMU needs to have IOMMU_MMIO flag, together with skip of CPU sync. The latter was handled by provided DMA_ATTR_SKIP_CPU_SYNC flag, but IOMMU flag was missed, due to assumption that such memory can be treated as regular one. Reuse newly introduced DMA attribute to properly take MMIO path. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- mm/hmm.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index 015ab243f081..6556c0e074ba 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -746,7 +746,7 @@ dma_addr_t hmm_dma_map_pfn(struct device *dev, struct hmm_dma_map *map, case PCI_P2PDMA_MAP_NONE: break; case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE: - attrs |= DMA_ATTR_SKIP_CPU_SYNC; + attrs |= DMA_ATTR_MMIO; pfns[idx] |= HMM_PFN_P2PDMA; break; case PCI_P2PDMA_MAP_BUS_ADDR: @@ -776,7 +776,7 @@ dma_addr_t hmm_dma_map_pfn(struct device *dev, struct hmm_dma_map *map, goto error; dma_addr = dma_map_phys(dev, paddr, map->dma_entry_size, - DMA_BIDIRECTIONAL, 0); + DMA_BIDIRECTIONAL, attrs); if (dma_mapping_error(dev, dma_addr)) goto error; @@ -811,16 +811,17 @@ bool hmm_dma_unmap_pfn(struct device *dev, struct hmm_dma_map *map, size_t idx) if ((pfns[idx] & valid_dma) != valid_dma) return false; + if (pfns[idx] & HMM_PFN_P2PDMA) + attrs |= DMA_ATTR_MMIO; + if (pfns[idx] & HMM_PFN_P2PDMA_BUS) ; /* no need to unmap bus address P2P mappings */ - else if (dma_use_iova(state)) { - if (pfns[idx] & HMM_PFN_P2PDMA) - attrs |= DMA_ATTR_SKIP_CPU_SYNC; + else if (dma_use_iova(state)) dma_iova_unlink(dev, state, idx * map->dma_entry_size, map->dma_entry_size, DMA_BIDIRECTIONAL, attrs); - } else if (dma_need_unmap(dev)) + else if (dma_need_unmap(dev)) dma_unmap_phys(dev, dma_addrs[idx], map->dma_entry_size, - DMA_BIDIRECTIONAL, 0); + DMA_BIDIRECTIONAL, attrs); pfns[idx] &= ~(HMM_PFN_DMA_MAPPED | HMM_PFN_P2PDMA | HMM_PFN_P2PDMA_BUS); -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106810.1457462 (Exim 4.92) (envelope-from ) id 1utSM1-0001Go-1i; Tue, 02 Sep 2025 14:51:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106810.1457462; Tue, 02 Sep 2025 14:51: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 1utSM0-0001Fy-QF; Tue, 02 Sep 2025 14:51:24 +0000 Received: by outflank-mailman (input) for mailman id 1106810; Tue, 02 Sep 2025 14:51: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 1utSKX-00028O-20 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:53 +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 136559a5-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49:50 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 32EDE60222; Tue, 2 Sep 2025 14:49:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DECF0C4CEF5; Tue, 2 Sep 2025 14:49: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: 136559a5-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824588; bh=/HCl3HOvsWTzCarzVdlMD7f/4v3gPsaMJ10z4KcUXMM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bZYcAtLwu1psF1muMSdmkP65AbKGbWFQCJo2LL567neKML0kAAzPANt3qFbqjcn0N V4gCR2nowx5Lo1PuU6VuJns/qR3sY3EuvXgeME5KBn7G+Ngcyei4RcEh6RxF3dcMHs e8tQmIAgTbW9z4p73SQvPRGCjVdn9Ltb56/HY6beiQu8eETLEUc2fZYysngtqhdfzf i2UueRWa9m5+zUZhtU0eQVmO+iKWmO4oKQF8/sdr+6fbA1WtQwmvoZV/yFOC0PMThg +7OmV7e4QNp2DHGxAMjMtCug23bO/U/hUSiynv/xnEV5BA5T/CHefOymweGEqBVARB TyxUPxpppCEfg== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 11/16] dma-mapping: export new dma_*map_phys() interface Date: Tue, 2 Sep 2025 17:48:48 +0300 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys() that operate directly on physical addresses instead of page+offset parameters. This provides a more efficient interface for drivers that already have physical addresses available. The new functions are implemented as the primary mapping layer, with the existing dma_map_page_attrs()/dma_map_resource() and dma_unmap_page_attrs()/dma_unmap_resource() functions converted to simple wrappers around the phys-based implementations. In case dma_map_page_attrs(), the struct page is converted to physical address with help of page_to_phys() function and dma_map_resource() provides physical address as is together with addition of DMA_ATTR_MMIO attribute. The old page-based API is preserved in mapping.c to ensure that existing code won't be affected by changing EXPORT_SYMBOL to EXPORT_SYMBOL_GPL variant for dma_*map_phys(). Reviewed-by: Jason Gunthorpe Reviewed-by: Keith Busch Signed-off-by: Leon Romanovsky --- drivers/iommu/dma-iommu.c | 14 -------- include/linux/dma-direct.h | 2 -- include/linux/dma-mapping.h | 13 +++++++ include/linux/iommu-dma.h | 4 --- include/trace/events/dma.h | 2 -- kernel/dma/debug.c | 43 ----------------------- kernel/dma/debug.h | 21 ----------- kernel/dma/direct.c | 16 --------- kernel/dma/mapping.c | 69 ++++++++++++++++++++----------------- 9 files changed, 50 insertions(+), 134 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 6804aaf034a1..7944a3af4545 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1556,20 +1556,6 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, __iommu_dma_unmap(dev, start, end - start); } -dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys, - size_t size, enum dma_data_direction dir, unsigned long attrs) -{ - return __iommu_dma_map(dev, phys, size, - dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO, - dma_get_mask(dev)); -} - -void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle, - size_t size, enum dma_data_direction dir, unsigned long attrs) -{ - __iommu_dma_unmap(dev, handle, size); -} - static void __iommu_dma_free(struct device *dev, size_t size, void *cpu_addr) { size_t alloc_size = PAGE_ALIGN(size); diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index f3bc0bcd7098..c249912456f9 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -149,7 +149,5 @@ void dma_direct_free_pages(struct device *dev, size_t size, struct page *page, dma_addr_t dma_addr, enum dma_data_direction dir); int dma_direct_supported(struct device *dev, u64 mask); -dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr, - size_t size, enum dma_data_direction dir, unsigned long attrs); #endif /* _LINUX_DMA_DIRECT_H */ diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 4254fd9bdf5d..8248ff9363ee 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -138,6 +138,10 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, unsigned long attrs); void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs); +dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, + enum dma_data_direction dir, unsigned long attrs); +void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size, + enum dma_data_direction dir, unsigned long attrs); unsigned int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir, unsigned long attrs); void dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg, @@ -192,6 +196,15 @@ static inline void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { } +static inline dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, + size_t size, enum dma_data_direction dir, unsigned long attrs) +{ + return DMA_MAPPING_ERROR; +} +static inline void dma_unmap_phys(struct device *dev, dma_addr_t addr, + size_t size, enum dma_data_direction dir, unsigned long attrs) +{ +} static inline unsigned int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir, unsigned long attrs) diff --git a/include/linux/iommu-dma.h b/include/linux/iommu-dma.h index 485bdffed988..a92b3ff9b934 100644 --- a/include/linux/iommu-dma.h +++ b/include/linux/iommu-dma.h @@ -42,10 +42,6 @@ size_t iommu_dma_opt_mapping_size(void); size_t iommu_dma_max_mapping_size(struct device *dev); void iommu_dma_free(struct device *dev, size_t size, void *cpu_addr, dma_addr_t handle, unsigned long attrs); -dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys, - size_t size, enum dma_data_direction dir, unsigned long attrs); -void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle, - size_t size, enum dma_data_direction dir, unsigned long attrs); struct sg_table *iommu_dma_alloc_noncontiguous(struct device *dev, size_t size, enum dma_data_direction dir, gfp_t gfp, unsigned long attrs); void iommu_dma_free_noncontiguous(struct device *dev, size_t size, diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h index 84416c7d6bfa..5da59fd8121d 100644 --- a/include/trace/events/dma.h +++ b/include/trace/events/dma.h @@ -73,7 +73,6 @@ DEFINE_EVENT(dma_map, name, \ TP_ARGS(dev, phys_addr, dma_addr, size, dir, attrs)) DEFINE_MAP_EVENT(dma_map_phys); -DEFINE_MAP_EVENT(dma_map_resource); DECLARE_EVENT_CLASS(dma_unmap, TP_PROTO(struct device *dev, dma_addr_t addr, size_t size, @@ -111,7 +110,6 @@ DEFINE_EVENT(dma_unmap, name, \ TP_ARGS(dev, addr, size, dir, attrs)) DEFINE_UNMAP_EVENT(dma_unmap_phys); -DEFINE_UNMAP_EVENT(dma_unmap_resource); DECLARE_EVENT_CLASS(dma_alloc_class, TP_PROTO(struct device *dev, void *virt_addr, dma_addr_t dma_addr, diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index a0b135455119..7f720fe5dc61 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -38,7 +38,6 @@ enum { dma_debug_single, dma_debug_sg, dma_debug_coherent, - dma_debug_resource, dma_debug_phy, }; @@ -141,7 +140,6 @@ static const char *type2name[] = { [dma_debug_single] = "single", [dma_debug_sg] = "scatter-gather", [dma_debug_coherent] = "coherent", - [dma_debug_resource] = "resource", [dma_debug_phy] = "phy", }; @@ -1446,47 +1444,6 @@ void debug_dma_free_coherent(struct device *dev, size_t size, check_unmap(&ref); } -void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size, - int direction, dma_addr_t dma_addr, - unsigned long attrs) -{ - struct dma_debug_entry *entry; - - if (unlikely(dma_debug_disabled())) - return; - - entry = dma_entry_alloc(); - if (!entry) - return; - - entry->type = dma_debug_resource; - entry->dev = dev; - entry->paddr = addr; - entry->size = size; - entry->dev_addr = dma_addr; - entry->direction = direction; - entry->map_err_type = MAP_ERR_NOT_CHECKED; - - add_dma_entry(entry, attrs); -} - -void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr, - size_t size, int direction) -{ - struct dma_debug_entry ref = { - .type = dma_debug_resource, - .dev = dev, - .dev_addr = dma_addr, - .size = size, - .direction = direction, - }; - - if (unlikely(dma_debug_disabled())) - return; - - check_unmap(&ref); -} - void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, int direction) { diff --git a/kernel/dma/debug.h b/kernel/dma/debug.h index 76adb42bffd5..424b8f912ade 100644 --- a/kernel/dma/debug.h +++ b/kernel/dma/debug.h @@ -30,14 +30,6 @@ extern void debug_dma_alloc_coherent(struct device *dev, size_t size, extern void debug_dma_free_coherent(struct device *dev, size_t size, void *virt, dma_addr_t addr); -extern void debug_dma_map_resource(struct device *dev, phys_addr_t addr, - size_t size, int direction, - dma_addr_t dma_addr, - unsigned long attrs); - -extern void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr, - size_t size, int direction); - extern void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, int direction); @@ -88,19 +80,6 @@ static inline void debug_dma_free_coherent(struct device *dev, size_t size, { } -static inline void debug_dma_map_resource(struct device *dev, phys_addr_t addr, - size_t size, int direction, - dma_addr_t dma_addr, - unsigned long attrs) -{ -} - -static inline void debug_dma_unmap_resource(struct device *dev, - dma_addr_t dma_addr, size_t size, - int direction) -{ -} - static inline void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, int direction) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index fa75e3070073..1062caac47e7 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -502,22 +502,6 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents, return ret; } -dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr, - size_t size, enum dma_data_direction dir, unsigned long attrs) -{ - dma_addr_t dma_addr = paddr; - - if (unlikely(!dma_capable(dev, dma_addr, size, false))) { - dev_err_once(dev, - "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n", - &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit); - WARN_ON_ONCE(1); - return DMA_MAPPING_ERROR; - } - - return dma_addr; -} - int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt, void *cpu_addr, dma_addr_t dma_addr, size_t size, unsigned long attrs) diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index fdabfdaeff1d..0ca098d2e88d 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -152,12 +152,10 @@ static inline bool dma_map_direct(struct device *dev, return dma_go_direct(dev, *dev->dma_mask, ops); } -dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, - size_t offset, size_t size, enum dma_data_direction dir, - unsigned long attrs) +dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, + enum dma_data_direction dir, unsigned long attrs) { const struct dma_map_ops *ops = get_dma_ops(dev); - phys_addr_t phys = page_to_phys(page) + offset; bool is_mmio = attrs & DMA_ATTR_MMIO; dma_addr_t addr; @@ -177,6 +175,9 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, addr = ops->map_resource(dev, phys, size, dir, attrs); } else { + struct page *page = phys_to_page(phys); + size_t offset = offset_in_page(phys); + /* * The dma_ops API contract for ops->map_page() requires * kmappable memory, while ops->map_resource() does not. @@ -191,9 +192,26 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, return addr; } +EXPORT_SYMBOL_GPL(dma_map_phys); + +dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, + size_t offset, size_t size, enum dma_data_direction dir, + unsigned long attrs) +{ + phys_addr_t phys = page_to_phys(page) + offset; + + if (unlikely(attrs & DMA_ATTR_MMIO)) + return DMA_MAPPING_ERROR; + + if (IS_ENABLED(CONFIG_DMA_API_DEBUG) && + WARN_ON_ONCE(is_zone_device_page(page))) + return DMA_MAPPING_ERROR; + + return dma_map_phys(dev, phys, size, dir, attrs); +} EXPORT_SYMBOL(dma_map_page_attrs); -void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, +void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { const struct dma_map_ops *ops = get_dma_ops(dev); @@ -213,6 +231,16 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, trace_dma_unmap_phys(dev, addr, size, dir, attrs); debug_dma_unmap_phys(dev, addr, size, dir); } +EXPORT_SYMBOL_GPL(dma_unmap_phys); + +void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, + enum dma_data_direction dir, unsigned long attrs) +{ + if (unlikely(attrs & DMA_ATTR_MMIO)) + return; + + dma_unmap_phys(dev, addr, size, dir, attrs); +} EXPORT_SYMBOL(dma_unmap_page_attrs); static int __dma_map_sg_attrs(struct device *dev, struct scatterlist *sg, @@ -338,41 +366,18 @@ EXPORT_SYMBOL(dma_unmap_sg_attrs); dma_addr_t dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { - const struct dma_map_ops *ops = get_dma_ops(dev); - dma_addr_t addr = DMA_MAPPING_ERROR; - - BUG_ON(!valid_dma_direction(dir)); - - if (WARN_ON_ONCE(!dev->dma_mask)) + if (IS_ENABLED(CONFIG_DMA_API_DEBUG) && + WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) return DMA_MAPPING_ERROR; - if (dma_map_direct(dev, ops)) - addr = dma_direct_map_resource(dev, phys_addr, size, dir, attrs); - else if (use_dma_iommu(dev)) - addr = iommu_dma_map_resource(dev, phys_addr, size, dir, attrs); - else if (ops->map_resource) - addr = ops->map_resource(dev, phys_addr, size, dir, attrs); - - trace_dma_map_resource(dev, phys_addr, addr, size, dir, attrs); - debug_dma_map_resource(dev, phys_addr, size, dir, addr, attrs); - return addr; + return dma_map_phys(dev, phys_addr, size, dir, attrs | DMA_ATTR_MMIO); } EXPORT_SYMBOL(dma_map_resource); void dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { - const struct dma_map_ops *ops = get_dma_ops(dev); - - BUG_ON(!valid_dma_direction(dir)); - if (dma_map_direct(dev, ops)) - ; /* nothing to do: uncached and no swiotlb */ - else if (use_dma_iommu(dev)) - iommu_dma_unmap_resource(dev, addr, size, dir, attrs); - else if (ops->unmap_resource) - ops->unmap_resource(dev, addr, size, dir, attrs); - trace_dma_unmap_resource(dev, addr, size, dir, attrs); - debug_dma_unmap_resource(dev, addr, size, dir); + dma_unmap_phys(dev, addr, size, dir, attrs | DMA_ATTR_MMIO); } EXPORT_SYMBOL(dma_unmap_resource); -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106811.1457468 (Exim 4.92) (envelope-from ) id 1utSM1-0001Lq-G5; Tue, 02 Sep 2025 14:51:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106811.1457468; Tue, 02 Sep 2025 14: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 1utSM1-0001JK-4H; Tue, 02 Sep 2025 14:51:25 +0000 Received: by outflank-mailman (input) for mailman id 1106811; Tue, 02 Sep 2025 14:51: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 1utSKj-00028O-9H for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:50:05 +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 1b2eec2c-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:50: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 4A6A641B36; Tue, 2 Sep 2025 14:50:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5010C4CEF5; Tue, 2 Sep 2025 14:50: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: 1b2eec2c-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824602; bh=ZBDCCXKOUbAW2GsG2jVC6suB2pwDgJLZN0OvrJL85zc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lkdauzdpN/SIpGSSfK8kLRUi86AA3+TOqmqD24ZnSor88UIrlGHjQsAmCWO6e2anl K1lRyv4MmrXkJu2ofOy32MFwkshextQSVPwvtX4cA3dJRuVSZhM7Jx9KBi5eSNonrI z4cGmqRTm+5StjFtRxvIwsoIxLa3y6W46EmimmukeeLvHkuxCFF2Vrt9w4OBWq+PE8 obKDUurvbMwMhMZ1bRG/wLIUXAqpLU+zCaTKDld6pT5B4hrYSp0DUwIX2ynJrtw+wC fv6qY0+duowp3cuGhIqsRETMXtVLq780uF5XI7RuDfeie+OQAT9g3cPsIbtn3Lr6Ky j7H6Q0F41/mKg== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 14/16] block-dma: migrate to dma_map_phys instead of map_page Date: Tue, 2 Sep 2025 17:48:51 +0300 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky After introduction of dma_map_phys(), there is no need to convert from physical address to struct page in order to map page. So let's use it directly. Reviewed-by: Keith Busch Signed-off-by: Leon Romanovsky --- block/blk-mq-dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c index ad283017caef..37e2142be4f7 100644 --- a/block/blk-mq-dma.c +++ b/block/blk-mq-dma.c @@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) static bool blk_dma_map_direct(struct request *req, struct device *dma_dev, struct blk_dma_iter *iter, struct phys_vec *vec) { - iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr), - offset_in_page(vec->paddr), vec->len, rq_dma_dir(req)); + iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len, + rq_dma_dir(req), 0); if (dma_mapping_error(dma_dev, iter->addr)) { iter->status = BLK_STS_RESOURCE; return false; -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:33 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106820.1457487 (Exim 4.92) (envelope-from ) id 1utSM9-0002Lu-F0; Tue, 02 Sep 2025 14:51:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106820.1457487; Tue, 02 Sep 2025 14: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 1utSM9-0002Ll-Bm; Tue, 02 Sep 2025 14:51:33 +0000 Received: by outflank-mailman (input) for mailman id 1106820; Tue, 02 Sep 2025 14: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 1utSKn-00028O-1I for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:50: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 1dabb114-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:50: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 63B9B60223; Tue, 2 Sep 2025 14:50:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36EC5C4CEED; Tue, 2 Sep 2025 14:50: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: 1dabb114-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824606; bh=LO26BwKAcM5bzAy5+YIJkrmuLLytzpcl+we8V4Bhs/s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LKY9fKoZOkueicaHrUccAoKo/BCx6mgGEeI1cqKthujBHZcr0grk1DET+0qz5Nn3j X04UfMZEYGgOAdyBKbdv3EPfUfaCtaHmX0pkTRXBtHe1eSWe+6/4HHjjh1fCZIrwFI 9u4k+CxQYWnfdDbRqzv9VvChyCpccmAzs4QD4X/Tb26RvsKJ7RFD5Cp//R7boSucJj 9OjWn48Lw0oVFJJbBnM3GtjtMTkhWTqDbczjxsHp85mixuHu1ODHv+b4/ZI3zPt/sf 2V6wheinrYkzZWQgXJQybZfQtO7DZfnbugbPgpjLZrYH99wuatKrAavrSz5zlEbB2g MSo533i8qyD0A== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 15/16] block-dma: properly take MMIO path Date: Tue, 2 Sep 2025 17:48:52 +0300 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Make sure that CPU is not synced and IOMMU is configured to take MMIO path by providing newly introduced DMA_ATTR_MMIO attribute. Reviewed-by: Keith Busch Signed-off-by: Leon Romanovsky --- block/blk-mq-dma.c | 13 +++++++++++-- include/linux/blk-mq-dma.h | 6 +++++- include/linux/blk_types.h | 2 ++ 3 files changed, 18 insertions(+), 3 deletions(-) diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c index 37e2142be4f7..d415088ed9fd 100644 --- a/block/blk-mq-dma.c +++ b/block/blk-mq-dma.c @@ -87,8 +87,13 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) static bool blk_dma_map_direct(struct request *req, struct device *dma_dev, struct blk_dma_iter *iter, struct phys_vec *vec) { + unsigned int attrs = 0; + + if (req->cmd_flags & REQ_MMIO) + attrs = DMA_ATTR_MMIO; + iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len, - rq_dma_dir(req), 0); + rq_dma_dir(req), attrs); if (dma_mapping_error(dma_dev, iter->addr)) { iter->status = BLK_STS_RESOURCE; return false; @@ -103,14 +108,17 @@ static bool blk_rq_dma_map_iova(struct request *req, struct device *dma_dev, { enum dma_data_direction dir = rq_dma_dir(req); unsigned int mapped = 0; + unsigned int attrs = 0; int error; iter->addr = state->addr; iter->len = dma_iova_size(state); + if (req->cmd_flags & REQ_MMIO) + attrs = DMA_ATTR_MMIO; do { error = dma_iova_link(dma_dev, state, vec->paddr, mapped, - vec->len, dir, 0); + vec->len, dir, attrs); if (error) break; mapped += vec->len; @@ -176,6 +184,7 @@ bool blk_rq_dma_map_iter_start(struct request *req, struct device *dma_dev, * same as non-P2P transfers below and during unmap. */ req->cmd_flags &= ~REQ_P2PDMA; + req->cmd_flags |= REQ_MMIO; break; default: iter->status = BLK_STS_INVAL; diff --git a/include/linux/blk-mq-dma.h b/include/linux/blk-mq-dma.h index c26a01aeae00..6c55f5e58511 100644 --- a/include/linux/blk-mq-dma.h +++ b/include/linux/blk-mq-dma.h @@ -48,12 +48,16 @@ static inline bool blk_rq_dma_map_coalesce(struct dma_iova_state *state) static inline bool blk_rq_dma_unmap(struct request *req, struct device *dma_dev, struct dma_iova_state *state, size_t mapped_len) { + unsigned int attrs = 0; + if (req->cmd_flags & REQ_P2PDMA) return true; if (dma_use_iova(state)) { + if (req->cmd_flags & REQ_MMIO) + attrs = DMA_ATTR_MMIO; dma_iova_destroy(dma_dev, state, mapped_len, rq_dma_dir(req), - 0); + attrs); return true; } diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h index 09b99d52fd36..283058bcb5b1 100644 --- a/include/linux/blk_types.h +++ b/include/linux/blk_types.h @@ -387,6 +387,7 @@ enum req_flag_bits { __REQ_FS_PRIVATE, /* for file system (submitter) use */ __REQ_ATOMIC, /* for atomic write operations */ __REQ_P2PDMA, /* contains P2P DMA pages */ + __REQ_MMIO, /* contains MMIO memory */ /* * Command specific flags, keep last: */ @@ -420,6 +421,7 @@ enum req_flag_bits { #define REQ_FS_PRIVATE (__force blk_opf_t)(1ULL << __REQ_FS_PRIVATE) #define REQ_ATOMIC (__force blk_opf_t)(1ULL << __REQ_ATOMIC) #define REQ_P2PDMA (__force blk_opf_t)(1ULL << __REQ_P2PDMA) +#define REQ_MMIO (__force blk_opf_t)(1ULL << __REQ_MMIO) #define REQ_NOUNMAP (__force blk_opf_t)(1ULL << __REQ_NOUNMAP) -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:51:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:51:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106841.1457497 (Exim 4.92) (envelope-from ) id 1utSMV-0003Qx-Rz; Tue, 02 Sep 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 1106841.1457497; Tue, 02 Sep 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 1utSMV-0003Qo-P9; Tue, 02 Sep 2025 14:51:55 +0000 Received: by outflank-mailman (input) for mailman id 1106841; Tue, 02 Sep 2025 14: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 1utSKT-00028O-1L for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:49 +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 10ac9ce9-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49: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 A23706021B; Tue, 2 Sep 2025 14:49:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A66F8C4CEED; Tue, 2 Sep 2025 14:49: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: 10ac9ce9-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824584; bh=2/thOeJ4NuvxSVVC3hxw/9bIX2PIBvboPgYtgi2/VE0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VKECAb+7Sse52mYJL41SXOrXDFGCRiIF9tuTww+7tx8TF5Ejmreeh3HY00rHaazQn aOTh2UXi0X7gB6XKiPuY2KJcOfZeTrAYxYVSBqbTN3F5Fl7eG0quZrJ/k42DqVVCsr GwhvRXbAMz4CU6yoxiw2WzZdasqegGQPNyQKGXTE5/3T3HPR4sL/jxhRLhqbGHtIqp Olwm6UL/KtvfA0rjsrKrcjQo7JfNFlEx+nnbC0Q+EsvdfGHJP1R+qDhsLnUhQ/x3ua ilF/FQzSLWqW8sNqDmIhrghX9qmh9Vix0gO6Gy0buRmc6/knYwd5Ib7hdXL+VxUnMe /kIUohye23SrQ== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 06/16] iommu/dma: implement DMA_ATTR_MMIO for iommu_dma_(un)map_phys() Date: Tue, 2 Sep 2025 17:48:43 +0300 Message-ID: <615b270dc8cd285c1b05cf3b9d3a969487049a5f.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Make iommu_dma_map_phys() and iommu_dma_unmap_phys() respect DMA_ATTR_MMIO. DMA_ATTR_MMIO makes the functions behave the same as iommu_dma_(un)map_resource(): - No swiotlb is possible - No cache flushing is done (ATTR_MMIO should not be cached memory) - prot for iommu_map() has IOMMU_MMIO not IOMMU_CACHE This is preparation for replacing iommu_dma_map_resource() callers with iommu_dma_map_phys(DMA_ATTR_MMIO) and removing iommu_dma_(un)map_resource(). Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- drivers/iommu/dma-iommu.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index aea119f32f96..6804aaf034a1 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1211,16 +1211,19 @@ dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, */ if (dev_use_swiotlb(dev, size, dir) && iova_unaligned(iovad, phys, size)) { + if (attrs & DMA_ATTR_MMIO) + return DMA_MAPPING_ERROR; + phys = iommu_dma_map_swiotlb(dev, phys, size, dir, attrs); if (phys == (phys_addr_t)DMA_MAPPING_ERROR) return DMA_MAPPING_ERROR; } - if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) + if (!coherent && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO))) arch_sync_dma_for_device(phys, size, dir); iova = __iommu_dma_map(dev, phys, size, prot, dma_mask); - if (iova == DMA_MAPPING_ERROR) + if (iova == DMA_MAPPING_ERROR && !(attrs & DMA_ATTR_MMIO)) swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs); return iova; } @@ -1228,10 +1231,14 @@ dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, void iommu_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction dir, unsigned long attrs) { - struct iommu_domain *domain = iommu_get_dma_domain(dev); phys_addr_t phys; - phys = iommu_iova_to_phys(domain, dma_handle); + if (attrs & DMA_ATTR_MMIO) { + __iommu_dma_unmap(dev, dma_handle, size); + return; + } + + phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle); if (WARN_ON(!phys)) return; -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 14:52:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 14:52:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106847.1457507 (Exim 4.92) (envelope-from ) id 1utSMb-0003t1-3T; Tue, 02 Sep 2025 14:52:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106847.1457507; Tue, 02 Sep 2025 14:52: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 1utSMb-0003sN-07; Tue, 02 Sep 2025 14:52:01 +0000 Received: by outflank-mailman (input) for mailman id 1106847; Tue, 02 Sep 2025 14: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 1utSKN-00028O-Ld for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:49:43 +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 0e3ae31b-880c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:49:41 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8B8DC437CE; Tue, 2 Sep 2025 14:49:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B593DC4CEED; Tue, 2 Sep 2025 14:49: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: 0e3ae31b-880c-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756824580; bh=RB2ksoieyLntDs7HJ/RFuf6vwP6H3wdrcrPesmw+pyc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JZSrHfV5RjgP6FwDhcPDrLH1lW/wS4YlLapHJysxuEeYKBdTeEA7mwHWta+DUwvDK 8usdO9pm0G9OJcPH2r6xdHblIJrIO415RfC5Jo9IYcWrcDkjpHn2FwnkLHPhIz23St wXHYoacDeswL+oFmO249wc5MuSyna3BF+sSD/rKFuhG8BkS8Swzg+mJ44CRMdKCVjJ JT5Y2NQNPc+7xnLzw9pSQotk1nGvp4p1upES9s3UQSikhPHPq/nquZmZaXUq0AprZi s3B+kTchlbCY1zBP+cxrbq6M9+mc7YC1+9T3u/HEsQcoDp2oijrmaAzD/IHheWAhET 7nxwjSwvkkL9Q== From: Leon Romanovsky To: Marek Szyprowski Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , David Hildenbrand , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: [PATCH v5 09/16] dma-mapping: implement DMA_ATTR_MMIO for dma_(un)map_page_attrs() Date: Tue, 2 Sep 2025 17:48:46 +0300 Message-ID: <098a7aace5780f8ad504ce021e7731dfe1f82dca.1756822782.git.leon@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Leon Romanovsky Make dma_map_page_attrs() and dma_map_page_attrs() respect DMA_ATTR_MMIO. DMA_ATR_MMIO makes the functions behave the same as dma_(un)map_resource(): - No swiotlb is possible - Legacy dma_ops arches use ops->map_resource() - No kmsan - No arch_dma_map_phys_direct() The prior patches have made the internal functions called here support DMA_ATTR_MMIO. This is also preparation for turning dma_map_resource() into an inline calling dma_map_phys(DMA_ATTR_MMIO) to consolidate the flows. Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky --- kernel/dma/mapping.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 891e1fc3e582..fdabfdaeff1d 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -158,6 +158,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, { const struct dma_map_ops *ops = get_dma_ops(dev); phys_addr_t phys = page_to_phys(page) + offset; + bool is_mmio = attrs & DMA_ATTR_MMIO; dma_addr_t addr; BUG_ON(!valid_dma_direction(dir)); @@ -166,14 +167,25 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, return DMA_MAPPING_ERROR; if (dma_map_direct(dev, ops) || - arch_dma_map_phys_direct(dev, phys + size)) + (!is_mmio && arch_dma_map_phys_direct(dev, phys + size))) addr = dma_direct_map_phys(dev, phys, size, dir, attrs); else if (use_dma_iommu(dev)) addr = iommu_dma_map_phys(dev, phys, size, dir, attrs); - else + else if (is_mmio) { + if (!ops->map_resource) + return DMA_MAPPING_ERROR; + + addr = ops->map_resource(dev, phys, size, dir, attrs); + } else { + /* + * The dma_ops API contract for ops->map_page() requires + * kmappable memory, while ops->map_resource() does not. + */ addr = ops->map_page(dev, page, offset, size, dir, attrs); + } - kmsan_handle_dma(phys, size, dir); + if (!is_mmio) + kmsan_handle_dma(phys, size, dir); trace_dma_map_phys(dev, phys, addr, size, dir, attrs); debug_dma_map_phys(dev, phys, size, dir, addr, attrs); @@ -185,14 +197,18 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { const struct dma_map_ops *ops = get_dma_ops(dev); + bool is_mmio = attrs & DMA_ATTR_MMIO; BUG_ON(!valid_dma_direction(dir)); if (dma_map_direct(dev, ops) || - arch_dma_unmap_phys_direct(dev, addr + size)) + (!is_mmio && arch_dma_unmap_phys_direct(dev, addr + size))) dma_direct_unmap_phys(dev, addr, size, dir, attrs); else if (use_dma_iommu(dev)) iommu_dma_unmap_phys(dev, addr, size, dir, attrs); - else + else if (is_mmio) { + if (ops->unmap_resource) + ops->unmap_resource(dev, addr, size, dir, attrs); + } else ops->unmap_page(dev, addr, size, dir, attrs); trace_dma_unmap_phys(dev, addr, size, dir, attrs); debug_dma_unmap_phys(dev, addr, size, dir); -- 2.50.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:01:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:01:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106885.1457517 (Exim 4.92) (envelope-from ) id 1utSVF-00063F-U8; Tue, 02 Sep 2025 15:00:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106885.1457517; Tue, 02 Sep 2025 15:00: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 1utSVF-000638-Qt; Tue, 02 Sep 2025 15:00:57 +0000 Received: by outflank-mailman (input) for mailman id 1106885; Tue, 02 Sep 2025 15:00: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 1utSVE-000632-Ka for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:00:56 +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 9ff039c4-880d-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 17:00:55 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b0431c12df3so321156966b.1 for ; Tue, 02 Sep 2025 08:00:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b04110b94cbsm723126466b.93.2025.09.02.08.00.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 08:00: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: 9ff039c4-880d-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756825254; x=1757430054; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wpUrdotCJ0Y0liN61EhVHhifJB6ZIfv8XU4reL1iPd8=; b=c6r15nWxr9hOgrL20A6NQLWT9eq8xkvBVJECH6GQm2N0mU8kFTAS0ukeUmkD7qfE7s 41BtFXjTcGO2iL15SpXB7rVqyJOCk9Zp0UV1tqvUxqqMSlKuk/FP69vKeI0iEEwdNw/H J9Ll+UsRZfxkka3PCJPTibB/ez3RBGa/Oqfep8QMA7V1QCIMciSpAPIqz/1rq65ILTTJ C0EWc8xq9wKuXjXCeY3N2iEsb1ohSUMYa5QPfKT3kKSl+y1grLgMpKHFX2eKAiFNK61X 6zW7tKW2S/o3yBd3dO/2Bdyo/qtHWt8PQw+YWrxJLWOZZUSVnNX9mdzWPp2o9hlLcljY kbqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756825254; x=1757430054; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wpUrdotCJ0Y0liN61EhVHhifJB6ZIfv8XU4reL1iPd8=; b=Epgo38m1yV/tbkRlHj9phdMIdOnPxC50gI+0MIOSbSYsg+o5+0w9M01uQ4Y67rOpQQ 8PfD0Y9mT9+8xhHtx8XWwRlRn3O8rlR9qNvS/Mhw62ngF/3eWo+uRDF6ZumFs1CsNVz8 9NVlvbX878Bvku9nHgkz+L8GNIU9O6ul5C379zEpMwSAEZ8UcjB7OywPpV2D9j1OTyyR GnhtixaUEPNb/TCJ/1/bTTb+9Z14rDXYNc87dPhPeyKqtOra5ahU1AxxS9ipoOUXPcCJ EvPoPPX14WAPDFNnCXAO6vUgXOk/mLr6uUEE2cegybC44dMEg8jBYNkLnaHZDs7EajZH ekhw== X-Forwarded-Encrypted: i=1; AJvYcCXHn0PvA7cWZcwC80abgIk46vESiMxR2QKC2IZvZKY8eQrauaNKpyKDglTueYw2RpyFgYVnVLfFnRM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxYOzeSa3PdDbSaqJkUq3EV1Dj7YGv0RMkuWyVDAx4XdhnUHYXg s5SUz1+oSKXFxF2Twym94toxZ/HaTE+58ixFQ+lhCZ33K9b/5HrUfrPf5MU0NZ23yA== X-Gm-Gg: ASbGncsmIiqkXi6ivebOUIC3bdAnyjTwGwKLdssr1jq7aJ6eK89GcgH/5KTfljixs/r dQvZh72adpi5ohPhjzAPZ74HodMrhNUds90jT7DYuJyf3kPUQFsNRe+N/mHxBGbfEqxSGx6mK21 71Uj/E/kv7D2evptvxqdZFncGMJyIlh5VP4eKOfAkq4l+vtXIPG2ODXyWz1f0QPkweRKbFWZmdS dq8Oqz/FfQxrPDC9Z9aI18t6HxUSvfkw52hn171NmzcuyDTM0Nw6Bgn5QTIacjEE5Lw9+KCDpXH YS9cLlmmnbHFMoUIpKrPauShISxB0ChqMDymlCS1UWAJYOLgrpEWCVDnvcBkC2KakD1ndEZuMm6 BxPe8vcOQ+mPbfKaggZ/PU7N/VSXdYh3O8GAU81ktNrPtQmotDum887kqPZePUabaN+zAgiFNdT Ue4On0y5QkgpfFnkQn3OfUhd6mWgBC X-Google-Smtp-Source: AGHT+IFCa4pndicxeIepm1ezRw8SU3+Jf8/iwRlB4ZlLIvrJqCrxs+/5UV2vH1LvgumHlM1Tkcwa5w== X-Received: by 2002:a17:907:9406:b0:b04:4aa9:eec8 with SMTP id a640c23a62f3a-b044aaa4b0cmr373841766b.17.1756825253991; Tue, 02 Sep 2025 08:00:53 -0700 (PDT) Message-ID: <12dada9a-96eb-45db-bd1a-5a88e323a100@suse.com> Date: Tue, 2 Sep 2025 17:00:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] efi: Use Shim's LoadImage to verify the Dom0 kernel To: Gerald Elder-Vass Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Kevin Lampis , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <7f2f88f0d857ed3f8d7e3fabe349a3b5d5815981.1756822290.git.gerald.elder-vass@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: <7f2f88f0d857ed3f8d7e3fabe349a3b5d5815981.1756822290.git.gerald.elder-vass@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2025 16:44, Gerald Elder-Vass wrote: > The existing Verify functionality of the Shim lock protocol is > deprecated and will be removed, instead we must use the LoadImage > interface to perform the verification. > > When the loading is successful we won't be using the newly loaded image > (as of yet) so we must then immediately unload the image to clean up. > > Signed-off-by: Gerald Elder-Vass > Signed-off-by: Kevin Lampis > --- > Changes since v1: > - Re-instated SHIM_LOCK_PROTOCOL as a fallback option if IMAGE_LOADER is > not found > - Fixed indentation and error messages > --- > xen/common/efi/boot.c | 43 +++++++++++++++++++++++++++++++++++++------ > 1 file changed, 37 insertions(+), 6 deletions(-) > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 453b1ba099cd..273da3d9e3e3 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -38,6 +38,8 @@ > { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} } > #define SHIM_LOCK_PROTOCOL_GUID \ > { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} } > +#define SHIM_IMAGE_LOADER_GUID \ > + { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} } > #define APPLE_PROPERTIES_PROTOCOL_GUID \ > { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} } > #define EFI_SYSTEM_RESOURCE_TABLE_GUID \ > @@ -70,6 +72,13 @@ typedef struct { > EFI_SHIM_LOCK_VERIFY Verify; > } EFI_SHIM_LOCK_PROTOCOL; > > +typedef struct _SHIM_IMAGE_LOADER { > + EFI_IMAGE_LOAD LoadImage; > + EFI_IMAGE_START StartImage; > + EFI_EXIT Exit; > + EFI_IMAGE_UNLOAD UnloadImage; > +} SHIM_IMAGE_LOADER; > + > struct _EFI_APPLE_PROPERTIES; > > typedef EFI_STATUS > @@ -1336,10 +1345,12 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, > static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID; Please put the new GUID here, rather than using a compound literal below. > EFI_LOADED_IMAGE *loaded_image; > EFI_STATUS status; > + EFI_HANDLE loaded_kernel; This variable wants to move into the more narrow scope you introduce. > unsigned int i; > CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL; > UINTN gop_mode = ~0; > EFI_SHIM_LOCK_PROTOCOL *shim_lock; > + SHIM_IMAGE_LOADER *shim_loader; Same for this new one as well as shim_lock, as it looks. > @@ -1590,12 +1601,32 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, > * device tree through the efi_check_dt_boot function, in this stage > * 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 ) > - PrintErrMesg(L"Dom0 kernel image could not be verified", status); > + if ( kernel.ptr && !kernel_verified ) > + { > + Nit: Stray blank line. > + if ( !EFI_ERROR(efi_bs->LocateProtocol(&((EFI_GUID) SHIM_IMAGE_LOADER_GUID), > + NULL, (void **)&shim_loader)) ) > + { > + status = shim_loader->LoadImage(false, ImageHandle, NULL, (void *)kernel.ptr, kernel.size, &loaded_kernel); Please pay attention to line length (see ./CODING_STYLE, also for other style aspects, like ... > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"LoadImage failed", status); > + > + // LoadImage performs verification, now unload it to clean up ... comment format). > + status = shim_loader->UnloadImage(loaded_kernel); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"UnloadImage failed", status); Does this really need to be fatal? > + } > + else > + { > + status = efi_bs->LocateProtocol(&shim_lock_guid, NULL, (void **)&shim_lock); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"Failed to locate SHIM_LOCK protocol", status); This is a behavioral change not justified in the description. Imo, if the original code was wrong, that would want to be a separate change anyway, so right here you want to retain original behavior. Simply consider the case of a shim-free boot, where neither of the two protocols would be available. Jan > + status = shim_lock->Verify(kernel.ptr, kernel.size); > + if ( EFI_ERROR(status) ) > + PrintErrMesg(L"Dom0 kernel image could not be verified", status); > + } > + } > > efi_arch_edd(); > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:03:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:03:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106897.1457527 (Exim 4.92) (envelope-from ) id 1utSXb-0006gk-As; Tue, 02 Sep 2025 15:03:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106897.1457527; Tue, 02 Sep 2025 15:03: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 1utSXb-0006gd-6Z; Tue, 02 Sep 2025 15:03:23 +0000 Received: by outflank-mailman (input) for mailman id 1106897; Tue, 02 Sep 2025 15:03: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 1utSXZ-0006gX-RJ for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:03:21 +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 f707ef4e-880d-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 17:03:21 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-61ce9bcc624so6240531a12.1 for ; Tue, 02 Sep 2025 08:03: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 a640c23a62f3a-b040f1cf4b9sm727218366b.29.2025.09.02.08.03.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 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: f707ef4e-880d-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756825400; x=1757430200; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=IuFyXOUTglkSB8mPMXD5cagEWTaZs+GMb0YUuWOTuoo=; b=WKgWE3PdhKrAyGIOUiKsYCL8CW0aZYEPmowv7T6K1UwVI2Iv33VGW7R2HW52rs6lKa iM5h9PuinwoK9Cp1/8wVk0p7TJlaorLVe+OKvIJ+BaBV8E1DrFs3KJJMCv26eScdyYPP 9JHE3aNcYvMIAms70Xd+spJDDIv7KTo0EehenXVG/hNlon/aeqscitB0EoJ0p7Hea/X6 2XIZJ8Xq/A+jhDPrbWvz9Iew+5S0I514RFC09JWw1J1CxMdxjE+/ihWS97QuPj9zQUsL WuntvQq5wOZaxST4FT23PehxZdgay8xLvrMtuSJcrmzConT2LtfnXUqgBVPmc3NfCWfY RSQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756825400; x=1757430200; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IuFyXOUTglkSB8mPMXD5cagEWTaZs+GMb0YUuWOTuoo=; b=m8lK7dICctt+T0srdIjxlK01jtymoEmWSiliEr/qQsZcNnkC50LM7n9gCVL5nG/LII 8jlJfMYlvbGsTSdajJZqcAPXmwLE2PkYfNaOc7YrZl6+Y+Hqqoze+NyxotazwUz31hzy n9ns5golnTyJX/RcBrb1DMLkELxfjXgYEqlUVwTipDjnZlpnaH6y5/vkr0kjt9lN4aCK RVq/zLyoi1f6kk17+4xs9gO/LkPLBc6TIC8XP4cXsajSUc6e0IMNu/njYXcIfG7AWMCT A5GJqdfzFJ4uZYzeuGlQb+NuhOyN+mZFZTPdFT/xNIOfdHGNJu8hA2ukKlANnF71U8sU uOcQ== X-Forwarded-Encrypted: i=1; AJvYcCWTHM86mPad9w8R5l/iZfYd09o/z33CHXOlBuKN9P+cj5Rs26uWLsfU5Y7aiy3Ez/TfqlCpd3FaVvw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMtmUq4oNtS/HWDw/N9XN5Kaa0IBjRJWbvC/PtsgrslIgFamDj LlHxknZXsh8L5Z691LPBUkOZHDvjfllF4oruUyliB8hWvClNSnmG9XYFIg7MU6qQGw== X-Gm-Gg: ASbGncv+y/sQACLevw0Q1qg9OKb1OTtqCxw7vT6wcxJXygPPTwdxJXUgtD06ysOS9Fm mRX5R0Xx5wr6KpY9lUvybgOzrFZ34OkrFeUiSkirfcCq4sH39O7tHKKzbpxmhUQsxPvamn6cvJb SgSIzXEcIkuWixo4jKNni3Vc5vIeBmw2hK2TkABVmYbeXzeOn4vu4an6qQUTf9GO/lg1STFAKMs tauk3cRB/QqMhyAIk8q7YBnhDlDYARiNiFUUq9iTBYv7Z0yqUKOnVSxqI04igGMwel+fjSY6faV 3iaHxy1dXJ8mBTw4O97AicyDuUlJIJqH8nZEnrl4qTYDGLFiNDEynaheFDaAMPgMd9FAlFvd39v SYwZPxGb3KhbWC6y97QnUrZQWW7l0tBa7PUOaVCiQmGyZFO1GVSoJ1A82K2BGwlGjs8/x7LBOpw C8pTAH1mcf+eS58kWwvw== X-Google-Smtp-Source: AGHT+IH2qck9JtepdUptIY/39GkOljL2lV2owwGjZi1Jv5EJUgDmag8t+ZAN6JPznHGobsVMoK3/+Q== X-Received: by 2002:a17:906:fd8d:b0:afe:35d:fd5d with SMTP id a640c23a62f3a-b01d8a33c18mr1222096266b.1.1756825400335; Tue, 02 Sep 2025 08:03:20 -0700 (PDT) Message-ID: <7418184c-9798-4c86-ac7e-9898de5df089@suse.com> Date: Tue, 2 Sep 2025 17:03:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] Tidy up .gitignore To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Xen-devel References: <20250902144937.1414411-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: <20250902144937.1414411-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2025 16:49, Andrew Cooper wrote: > Drop unused or stale lines. > > * While it's necessary to have .git and .hg in each others ignore files if > using multiple SCMs (as we did for a while), they should not be in their > own. Despite what you say you remove .hg from .gitignore though? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:04:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:04:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106909.1457537 (Exim 4.92) (envelope-from ) id 1utSYL-0007EA-Lh; Tue, 02 Sep 2025 15:04:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106909.1457537; Tue, 02 Sep 2025 15:04:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSYL-0007E3-IB; Tue, 02 Sep 2025 15:04:09 +0000 Received: by outflank-mailman (input) for mailman id 1106909; Tue, 02 Sep 2025 15:04: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 1utSYK-00071n-2b for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:04:08 +0000 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ed542be-880e-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 17:04:02 +0200 (CEST) Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2025 08:04:00 -0700 Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by fmviesa006.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2025 08:03:59 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 2 Sep 2025 08:03:58 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17 via Frontend Transport; Tue, 2 Sep 2025 08:03:58 -0700 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (40.107.102.72) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 2 Sep 2025 08:03:57 -0700 Received: from LV3PR11MB8603.namprd11.prod.outlook.com (2603:10b6:408:1b6::9) by IA1PR11MB6537.namprd11.prod.outlook.com (2603:10b6:208:3a3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.21; Tue, 2 Sep 2025 15:03:52 +0000 Received: from LV3PR11MB8603.namprd11.prod.outlook.com ([fe80::4622:29cf:32b:7e5c]) by LV3PR11MB8603.namprd11.prod.outlook.com ([fe80::4622:29cf:32b:7e5c%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 15:03: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: 0ed542be-880e-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1756825442; x=1788361442; h=date:from:to:cc:subject:message-id:mime-version; bh=7CMT17eXlp+frvas6mRk50H6MNe2lh81VfATKhv6tAo=; b=JAS0XZig50aR7kXXSEgOAzCYdagvXHbXa7c2XMMP0uHtVmjSYmtaETSy T0jR+MIonx9Ey8jg1YXLuGrFiks1OXG18w7gNMi36d101GyNr3aEWYEUX 87MEwdi9K0Et3uPxP36EZxQvLOI3PBwoUnE0m80oD4R8e0svdxo4kQPVd jdfKy5CG6k31m4cTJB146C5Xkf654Ka9y7ElNdHCZ5zCl/gd7RcQSoxtk E/TXui7z/zAy7YjN3Oa4GWITZUpuxF861pIZGcDoZ6oekFXNgS6fDAYVk mdmKEU27rgjtyOjEmmln4I4MPv0QjtdXD8/gGMO5i5F8wOavpeSTqfmyc g==; X-CSE-ConnectionGUID: +cwPXhvCRjOh+uhm+E1+qw== X-CSE-MsgGUID: 708FwS7ZQmKg8NV7wRRLJg== X-IronPort-AV: E=McAfee;i="6800,10657,11541"; a="84525503" X-IronPort-AV: E=Sophos;i="6.18,230,1751266800"; d="scan'208";a="84525503" X-CSE-ConnectionGUID: QIpjTnxOSkWJ46QRA0sVww== X-CSE-MsgGUID: 3C65hDlaS/iWaTozN6cahA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,230,1751266800"; d="scan'208";a="171269600" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s5n2dhIBY1Hvece1LsEQmP3eclZkPtImqfowFoBDWUGyOjfiZ+qEQmFJ3b+MMc4OTP29BbVAR2Plnvw06lR1DFcoeO5Z4+QBkPSI/7qqq/XH7/hYG4qVOppNoRn/4g71Rk4j9zKuwe/73zMtTaMrhrd7XZeJ5pwXlGfTX4Oo2yzD91EdOUnp0ZsLJFmh/Y3z+w41ZjAo+ha0WjLl/kboG1PXor31+0uAc0NPtSF3Lk+U+zNOcKsNBe38pmeshQd2RMcyc0Rr1rdkGMIBV22zW8uW+dnU7mvk3ero18iimKazDamGmRKFwJ9UIpbWTUBpx15gub1LVd0F6cNT0B4QDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HdlGoehymYZ+lfQkr0y+0rdJ+1SvoS8Ay0F3F8eXnzo=; b=jJYFmBUTSIMDe1S0Z70Rdj95wCqOewr58vVUI9Zh/jV9sgYKoHM9CoycTyEPdfTSwCkKsrVt/+EERRN8P9f4UrjNe9CzxF6p+jKmwGV0omGz1+AJjBTJN9WDL/IbtyqdSAtV1Pf7TYzQnodeskdLuqiT4eFRYJIL+8aHJ4JNLzKzLh7Dp7hqidcWdB658Vvcma3mVTPO+AV4yl6UlIYnX8xn3GprLl5JpmAZQXRU5+bY93H8jbwiXgoiiJv2feve4MlSYzAxEISIcz6T7/kd7y/GdW1CDUU0GX9bfmXaM5gnbHfAMbNu/XpvsmPFkR29Eposs6KcVfAdeBna26aQxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Date: Tue, 2 Sep 2025 23:03:43 +0800 From: kernel test robot To: Ard Biesheuvel CC: , , , , Subject: [ardb:x86-startup-confine-v7] [x86/boot] 7d40dc256f: BUG:kernel_reboot-without-warning_in_test_stage Message-ID: <202509022207.56fd97f4-lkp@intel.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-ClientProxiedBy: SI1PR02CA0034.apcprd02.prod.outlook.com (2603:1096:4:1f6::10) To LV3PR11MB8603.namprd11.prod.outlook.com (2603:10b6:408:1b6::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR11MB8603:EE_|IA1PR11MB6537:EE_ X-MS-Office365-Filtering-Correlation-Id: 38edb57c-b390-426f-b5d6-08ddea31eddc 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: =?us-ascii?Q?3IN/QJDqXlml2Fj2DlHyj1Qi181FJGhHP6h9buFzcQppeQucKfFb0XRWV7KH?= =?us-ascii?Q?ilXdBnbfPKvKGLGAIQcFoGylBmD4RMSftqyESN4cEwebQKbch6BNiznxG5N5?= =?us-ascii?Q?8QEh3XRabBZqe3og7A+mYLGn8SGEBSn9t1D5W2BhXIKmYN5HrcVC65dlWpGJ?= =?us-ascii?Q?aYd13JwM6bDzWwcRopY6Yx59pFPm/j+3hxuJX0vG85fzxZ5fWES6RR3MfcWb?= =?us-ascii?Q?2W648ewlljnUP/4JTllJCS/4uSeuDp8zpvGzPWUDKritjgBTwcgGXcYmFQc3?= =?us-ascii?Q?CF3Usa2QRsm8iN1+e2a9pv1M78lXv/pL5apG5JVrd7mynS00YGQbozXKIhp/?= =?us-ascii?Q?2QKyR4YaFCHGqYhm+MFaus+e76VEjnd79L70OmkXb7aCii20GkG73o8QYQqP?= =?us-ascii?Q?cABh2HkQiwReIAESsbkBjRegaq7HnFotRRamFv8KkeVY19BBeu4Vy3EcS9RO?= =?us-ascii?Q?pj5/pMyduN+HEIduyfl/1VFZBFkwXy4dyMe2KwT4ksceSXHO61fPg6zxOyhK?= =?us-ascii?Q?MNljq7MZ4jRBQHdZcUV62XluyCu2niAWthQzlzDFUEgEKzV8b3itE1MG+UYe?= =?us-ascii?Q?n374wr6qTAueihM0CLp/OMvhwgNxdjLFYoKyP6t/BHYK8M6LRWAUEVxOyeM2?= =?us-ascii?Q?EQ2lnu8YLtwiQUp1OtmG8l8M0IXGZU3rOvC7TJRgh2kcP95KBeInx9FqKoch?= =?us-ascii?Q?Hh2S2FUddEuq5ussseG6i5yzpWJnGeopqdKDUvDlVDYXV21fJjwKwS2z0pOS?= =?us-ascii?Q?crz5ULhdc4HBfqWECwa/bIp3rrldyhxV2sU0591a0Q3JITleo5g30clZLp/t?= =?us-ascii?Q?2TsI4/nBTrIzDg5XnvNaLTgnGQsmOaBaseaGVjvwm0/1JGd0hYNSpKkqERE8?= =?us-ascii?Q?ooZAvkey/a7MtJTg/+G8lexVs8iT5oaocHxXHNXVoNnzc8L6Ptq198SxTd9X?= =?us-ascii?Q?EqUKKDrQrw2keseOmuXzxV+Hc1So4HMkeJPXUwWOir/4xwSiFMaA6p9RA6Ld?= =?us-ascii?Q?yebbelp8mukU0ANBX+/tbTDPr4SJT8VYKLVGJn2ilpVV3W6dlVloCwvGEoGF?= =?us-ascii?Q?Xkd4AFHNgwzDfG4XxvNdvbfsj+wYq6EYM8WBrga4Fh3LoH0qTd0t00to7CNj?= =?us-ascii?Q?WzCSofTGJ8k9rjGW0kuknXYAqxZohR4R1J5AhGK2iKQluPXaVNytHOEr7BF1?= =?us-ascii?Q?NJRqUfLvKD2MYMKJnEDxt1VACxMdIIvbLV8ZBXYs34UAW/tXOHj5Na2u58Fj?= =?us-ascii?Q?l+zycn/oX3P3WMTKUxi1xFUWQlkJfpgRI2YB/nPsgLUFHvajWvZMfYdwD81H?= =?us-ascii?Q?4Qr4dgc9NcTzWj86TvB/wYHik46T4fJ81yTt8QN3BXVizk+bsrtqy9mnqGxq?= =?us-ascii?Q?iyFuV8UC8P+8LqSxI/DNUuk8k5Du?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR11MB8603.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/DO3G0u4OsXcefxOlfaori53x5dLtHIqIWQvUJ0fiXOgiht+QChz3NBVJ4Y4?= =?us-ascii?Q?TyIJpuv1vht3wPP8MysdQKp62H7Cf4K09ezHRvgHZAOgCVFt6ZJYsw+VMaQD?= =?us-ascii?Q?ly3LenMv4Z/7NFBpoXob9jHOtUVA6quBi+TztIFoGi/5KfRRbl/uxSXhEzxr?= =?us-ascii?Q?KOPRfJFH0rjATNawbOmK1FQt3suRX+e6zoegJEmfXk7z6IOVmUDYOotBtq++?= =?us-ascii?Q?021vbmHT8IjfWLSmLP2DTa/zOmjB+4pYX0hnEXoiC4z/byWV8GIR0hPU+7CN?= =?us-ascii?Q?3RZ2a0RAsONdoNwAcQLl6+uxg0yss7agwTcxaGFXck9X7zxmpDPSf2SSrmsa?= =?us-ascii?Q?0p6i28NdH5pm879ZGA9uHEvJLJ/YRZDYmcDJJdDi4WYTlbLJrtYhdbh+0MSU?= =?us-ascii?Q?cYGR9ogNAJir7hbtcUjL24he51EQjFhwwI/52GHH1lMRYFZVcrjOwtaqwtQ+?= =?us-ascii?Q?Mo+H5kFjl01OPtvc4RJZCxLOpvRY0VtT65dwFdWpjSeE6ZXLXCfc805KgZnX?= =?us-ascii?Q?BHjhH3RfaJXhqv6txUZk67vrFscm9RYaxed8tWMLA2HlabBddH9zcxDB+WdZ?= =?us-ascii?Q?6Z4ZBgHVvirGgC2q4rMymobDut1u4MKJIG6KEcZBQI9zciEhO4t9G86KRlwZ?= =?us-ascii?Q?74iudT+/Wyw4JGIf8Mv1EFpOyZyn1tDOZDRc6UsOf7TMumxMFkUGOR+Z1gR8?= =?us-ascii?Q?drjHQPBtBN1L4eSVXQsSf0DH8iFi2waP1BqB0WbKZ1cnMiz957JxvZS1tLRF?= =?us-ascii?Q?HhF7V7MskyDHqAh7rtuq+r3dqQvPP3ost43McJ6qpsyUR5wfmbF9dpG0oZ+g?= =?us-ascii?Q?8cxak59kox5kkevogcfUmXfcg5sOqMkqGVjMwKVQgoZIlu4DdDZNvjcoP+5z?= =?us-ascii?Q?7OPjWpVYYcmqdtuOjNuX1n40NO4gpNROJBDxXq8XCYAZUPtH7Q7HCGZzyycD?= =?us-ascii?Q?xw8zwxdcdvtm6Bpd3saAMTwyJUAYszmYXyP4wiohT4MrRNfnVk48XODw2k7D?= =?us-ascii?Q?gPxM28pLGTUoKzGaFP8rl1OGYER2Ew/kL7ToWNljkVScP6QJjn+DzNC5OEVq?= =?us-ascii?Q?BRMnRMlfENyqnYnHI2wOPStoO4+SS+LKWDJ7kFTFU6S2TAWUNxAXS8hulagy?= =?us-ascii?Q?mzZu510FE2iQYReED/4mG+JH6xt54q6HhAq4FrgOQrUCxDFViyTqb8tVdWJF?= =?us-ascii?Q?rF17NRs/+fbz/mTas0NKULVWzkeujBC2rKlzu0bhfELkq6Ernf7MyloDlvHG?= =?us-ascii?Q?tgadxEeK4pzH1l5szt1AbBnh4llmIeqmTMHvF4Ca4YPFuOjO4AKFcOiQvPn+?= =?us-ascii?Q?QcILMU+Bpcdx6+I5DpXudBnO8LFjBt9dIKfm60p8Dl0tqwJCJeZbtDGFaU43?= =?us-ascii?Q?CQCMveov2de3dF6eTMf8N5NrNZ4+N/HSFL2N2FvwJ9lfLAaGAxxBGYUtVGMi?= =?us-ascii?Q?Ub4UCC0PY1mFKPrXs8SyUEEKGNtYvsk8+3K63aTZAhzZY1/Y319twc0PuKA0?= =?us-ascii?Q?qHWDPb5wy2LYqwUHMquTaVbJDkskf+VwVVhAwwlEkGpFyXxJTBi1PuuBsJNM?= =?us-ascii?Q?pzLJ353qszUg3yf3nouNn38HfMNCT/4CPOFpPP9n4S+uyWR4lFHja8WQRVw8?= =?us-ascii?Q?Ig=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 38edb57c-b390-426f-b5d6-08ddea31eddc X-MS-Exchange-CrossTenant-AuthSource: LV3PR11MB8603.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2025 15:03:52.6043 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WCKXbObgdLtPhyfJLoZUFKSVBlqvyoMreypb9bgKUn4rMRr6/kNeY4vzYBl4M0j1VElnzJrgiEKLC+C2geveEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6537 X-OriginatorOrg: intel.com Hello, kernel test robot noticed "BUG:kernel_reboot-without-warning_in_test_stage" on: commit: 7d40dc256faa19a66045c7e3147f387e346d513c ("x86/boot: Move startup code out of __head section") https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git x86-startup-confine-v7 in testcase: rcutorture version: with following parameters: runtime: 300s test: cpuhotplug torture_type: tasks config: i386-randconfig-017-20250829 compiler: gcc-12 test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G (please refer to attached dmesg/kmsg for entire log/backtrace) +-------------------------------------------------+------------+------------+ | | 7ccec303a5 | 7d40dc256f | +-------------------------------------------------+------------+------------+ | boot_successes | 12 | 0 | | boot_failures | 0 | 12 | | BUG:kernel_reboot-without-warning_in_test_stage | 0 | 12 | +-------------------------------------------------+------------+------------+ 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 | Closes: https://lore.kernel.org/oe-lkp/202509022207.56fd97f4-lkp@intel.com [ 46.638864][ T218] 2025-08-30 23:52:51 sleep 300 [ 46.638874][ T218] [ 57.574765][ T460] tasks-torture: torture_onoff end holdoff [ 57.634414][ T65] smpboot: CPU 1 is now offline [ 57.663199][ T460] smpboot: Booting Node 0 Processor 1 APIC 0x1 BUG: kernel reboot-without-warning in test stage The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20250902/202509022207.56fd97f4-lkp@intel.com -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:07:11 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:07:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106946.1457547 (Exim 4.92) (envelope-from ) id 1utSbB-0008Jd-2P; Tue, 02 Sep 2025 15:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106946.1457547; Tue, 02 Sep 2025 15: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 1utSbA-0008JW-V3; Tue, 02 Sep 2025 15:07:04 +0000 Received: by outflank-mailman (input) for mailman id 1106946; Tue, 02 Sep 2025 15:07: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 1utSb9-00084u-FO for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:07:03 +0000 Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7961e084-880e-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 17:07:00 +0200 (CEST) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.stl.internal (Postfix) with ESMTP id E164D1D0003A; Tue, 2 Sep 2025 11:06:58 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Tue, 02 Sep 2025 11:06:59 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 11:06:56 -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: 7961e084-880e-11f0-8dd7-1b34d833f44b 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=1756825618; x=1756912018; bh=yfqYL+PBKmmYIwNFYiESmGThgwEExBob7KGrn14byxE=; b= jVSWydQ/o6OLvlke6vChxYFhSLZFdeIFXRTLLb6ba4TSRHOla4X06BogtHXrguB0 o/ei1EmaszBUocGoF1dAj8yY1rDltDslIMOm6pPKBU/Q5FO00pjYoP1bX39iXfqz Pohs4ugmC65ZBqHpNzKVCX48IgJc/AtqV10eaJUTwCRqVnPZOHDopssoHgT0OkN5 6EzkzDmibdZ5QHaZ+XN3cpxytI00IHruLEV0MYr+w582o9TTgyH/5Wvj6O7+rmwz zE9PqviBHXHOxsg658KVBVMtBQwJ6WcckynryOR4kZEZaURXo4N3ziAE+UzJifUZ p/qvrDetX204TJjDlzo9xQ== 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= 1756825618; x=1756912018; bh=yfqYL+PBKmmYIwNFYiESmGThgwEExBob7KG rn14byxE=; b=AARCB/maEAmBWKVh47Ms7Y73sqYnK/zHLYEyEjXjsjjiWRZz8G8 SNnUNQz7rAWXqAP8P31YTgyFoGxT9q7BXRfeTnpp89evComAOkc7hv4hHn97cmVS QRDiwYDtbK85BsvZxjqOeqsPkut6lBxKL0q8b46cWncIe8FkJ4wAN2lE/qqnv9i3 Y/BFZvczqodor7dL0WahYYICWZFGWNz/uFF/UTRQpXmpA3Bjqbv7+iQFiMchMimN P1RrLgbfbLKq8F1Qzi4Sdey8rcPqrb9YY+sSB749cO0LGpsDz3mukLK8UPflPFb+ 4uqP1NZGABLA0frVzHL7FdBUuB+OGL6PzQA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegrihhl ohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpe ffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghr tgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisg hlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteefvefh feehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhi shhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeduuddpmhhoug gvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdp rhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhssegtlhhouhgurdgtohhmpd hrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgt phhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpth htohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhi vghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrd gtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhr tghpthhtohepkhgvvhhinhdrlhgrmhhpihhssegtlhhouhgurdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 2 Sep 2025 17:06:54 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Gerald Elder-Vass , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , Kevin Lampis , "Daniel P. Smith" , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH v2] efi: Use Shim's LoadImage to verify the Dom0 kernel Message-ID: References: <7f2f88f0d857ed3f8d7e3fabe349a3b5d5815981.1756822290.git.gerald.elder-vass@cloud.com> <12dada9a-96eb-45db-bd1a-5a88e323a100@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I8OsBI9a2AT23IXC" Content-Disposition: inline In-Reply-To: <12dada9a-96eb-45db-bd1a-5a88e323a100@suse.com> --I8OsBI9a2AT23IXC Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Sep 2025 17:06:54 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Gerald Elder-Vass , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , Kevin Lampis , "Daniel P. Smith" , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH v2] efi: Use Shim's LoadImage to verify the Dom0 kernel On Tue, Sep 02, 2025 at 05:00:52PM +0200, Jan Beulich wrote: > On 02.09.2025 16:44, Gerald Elder-Vass wrote: > > + else > > + { > > + status =3D efi_bs->LocateProtocol(&shim_lock_guid, NULL, (= void **)&shim_lock); > > + if ( EFI_ERROR(status) ) > > + PrintErrMesg(L"Failed to locate SHIM_LOCK protocol", s= tatus); >=20 > This is a behavioral change not justified in the description. Imo, if > the original code was wrong, that would want to be a separate change > anyway, so right here you want to retain original behavior. Simply > consider the case of a shim-free boot, where neither of the two > protocols would be available. Yes, as commented by Yann on v1, this change as is seems to break shim-free boot (well, technically UKI is shim-free and remain working, but you know what I mean). That needs to remain working, even if only in SecureBoot-free case. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --I8OsBI9a2AT23IXC Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi3CA8ACgkQ24/THMrX 1yyTYgf/UEaIwot3TP6biSclGrSbwmPHWwIgkUex9Cw82/xy8KPjxEai25KhUtoq do06rU1hPQJ+c0MnhIb2A8Tbh5Zvf8ZoT68mX6vcD38fvLYt3ChiudZg/u5kDhXo iwMWc6jgU+32+cqrLTXbPZ+b46AWqbKyiwsHQmndQf5h8Va/zybCm4G58kFl2/tp 4/gTfttwuA0+Wu1wVR1HufBvc5nMXQcMI0wYvBTQ/2BJDgMKoF5y3YELQPOdjzex EyW7Wy/xw+7/CxwucqIwS9a1uytXu/brXaEG8jNO3GxlRRgXxv/uh3fDeV6ZrrNz 9VsNzEq72FnyaVIl23a5hD0et25Qdg== =J25Q -----END PGP SIGNATURE----- --I8OsBI9a2AT23IXC-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:10:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:10:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106970.1457556 (Exim 4.92) (envelope-from ) id 1utSev-0001z3-Gp; Tue, 02 Sep 2025 15:10:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106970.1457556; Tue, 02 Sep 2025 15: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 1utSev-0001yw-EB; Tue, 02 Sep 2025 15:10:57 +0000 Received: by outflank-mailman (input) for mailman id 1106970; Tue, 02 Sep 2025 15:10: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 1utSet-0001xZ-BS for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:10:55 +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 056b78ff-880f-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 17:10:54 +0200 (CEST) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-45b8b7ac427so14627385e9.2 for ; Tue, 02 Sep 2025 08:10:54 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d690f2edf1sm9386403f8f.16.2025.09.02.08.10.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 08: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: 056b78ff-880f-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756825854; x=1757430654; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=mqq8qu84oGzDsYr4FpIoL3NcNzsNZYmrqTXhCI2Lm3o=; b=dc50tKqtP5Xe3okvgx7TNCbxNNXNlbo9NQkQusnhKy9o0yEl0V8NyTaHThGDZ8eOE8 Oblv6sn0UReBc6gVwPb0pRU5cc4Bheefkr0HmUrJ9VFUe4U/7W/gB3I+HtyWkmd4sZQv mr/91bGWNk0Wk77IGXLtY9WCE9cEvHbdI14ag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756825854; x=1757430654; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mqq8qu84oGzDsYr4FpIoL3NcNzsNZYmrqTXhCI2Lm3o=; b=V13eyoRhif9qHUaDiXcHZUrkf0mULsOtx/V4c2Kn5segITH54bbE266bTp4Z0QwGPz nPgqYjCfvH+GhU74tV8FgrEmQduSSyndk02G/4PVfKahDS5CGEm9lSg2aetkDPkuFJ9W uPMkBat2yyw3wHsZPR+BAbRXjeN+H6uh8dQYp34Or2nEBG4KpnV4RsyoiyUK0ToPQPm+ n25Zq5npPuuBhKR+zjtI6E/6m2p01Fgcvzxth/tuttUfyH2OkFOrmcfz962OV+vylkD4 cSh0S2/6OaTGygPV5DwYLEU1kEULlSNN8z1LrzmKFDwx2Ez8FfOI53+wzbkMV2vNRerz 8d5A== X-Forwarded-Encrypted: i=1; AJvYcCXaP+ZvfaBSFdkuu6Fca3U0PH6t4xczFsQsj8DimxzONKqNkn5WOg7Mfwgchk3Z+dO/8rzdh9GLeqI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxd3lS97+2a1rOZAHCQrfmMamrtVA+rHcvCNXkP70wcQK9I6FeZ f57ut/JlX8IjccE69oHfmG8SahZeSSGxNYmxsArM96v4JKUEsLpgyK/C9X4ZQp9zc68= X-Gm-Gg: ASbGncuO84dj84xu7w3/26fNt9Hq5HZm/8TryKb3UxQxQvwywABd/OAZ2Wd3Ds5pxLt Y2uFKToCiEWbqHqG0JglH0Mb34jryyv1fI8Z/Q6BFWXuKM+sZaClXzTkTI4ktoP27xRY6lDkQKv TUtFE4n/Se2omre9uQgyIL+zaP5pHQKF03GQcgXFWZgnObAO8yZs89aARO7QZaszd7tSJWihsOX M6Wvh2FISmeArDHkobzku+sPmzX+rNoD5Gp9F3zRoexxZUgOWHvHs3Mf6DcQtO0Eh0b7TO2KS7s HLki7wQZOJ2PlndOKcUr0Z9Lps7PtOZQUh8FBrQ1rR2xXFYezdqOCRZpbySYERRiE1Zq2AyaIX3 P2SgDvE6DXDpyCxqSTTJQRH3tZCClFy2K95XBG76dGg3V47Hjd1y5Ru9Ld38CycyKpHaU X-Google-Smtp-Source: AGHT+IFxcnydYsJY8G91LGTTCPDcOlS7hXV2vpEXd+7pvtRmBr81WmY7fB/L0xsSIHEswoZIXg1qXg== X-Received: by 2002:a05:6000:18a9:b0:3da:84e2:c076 with SMTP id ffacd0b85a97d-3da85016655mr2034582f8f.55.1756825853906; Tue, 02 Sep 2025 08:10:53 -0700 (PDT) Message-ID: <63c9a5b5-6f9a-4abc-97de-19c85d80bf90@citrix.com> Date: Tue, 2 Sep 2025 16:10:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] Tidy up .gitignore To: Jan Beulich Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Xen-devel References: <20250902144937.1414411-1-andrew.cooper3@citrix.com> <7418184c-9798-4c86-ac7e-9898de5df089@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: <7418184c-9798-4c86-ac7e-9898de5df089@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/09/2025 4:03 pm, Jan Beulich wrote: > On 02.09.2025 16:49, Andrew Cooper wrote: >> Drop unused or stale lines. >> >> * While it's necessary to have .git and .hg in each others ignore files if >> using multiple SCMs (as we did for a while), they should not be in their >> own. > Despite what you say you remove .hg from .gitignore though? Oh, all .hg stuff was dropped in ba5bae659d907.  I can add a sentence to that effect. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:19:26 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:19:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1106995.1457567 (Exim 4.92) (envelope-from ) id 1utSn2-0004A3-BC; Tue, 02 Sep 2025 15:19:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106995.1457567; Tue, 02 Sep 2025 15:19:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSn2-00049w-6o; Tue, 02 Sep 2025 15:19:20 +0000 Received: by outflank-mailman (input) for mailman id 1106995; Tue, 02 Sep 2025 15:19: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 1utSn1-00049q-MR for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:19:19 +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 2c4e1a12-8810-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 17:19:09 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-b042cc3962aso254051166b.0 for ; Tue, 02 Sep 2025 08:19:09 -0700 (PDT) Received: from ?IPV6:2003:e5:872d:6400:8c05:37ee:9cf6:6840? (p200300e5872d64008c0537ee9cf66840.dip0.t-ipconnect.de. [2003:e5:872d:6400:8c05:37ee:9cf6:6840]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b01902d0e99sm851709166b.12.2025.09.02.08.19.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 08:19: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: 2c4e1a12-8810-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756826349; x=1757431149; 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=ElgHAVVNLwg9OsBq8IQHveis3g0DDocxmjJQYTfPOIY=; b=WuXSyoYpY8p7lFPACtVFV76ttnp8LQgkVZnqTtmn7azX8jrSuYccgus2L2f4D1mxxt B8RDMlmMq5EtO2D8zB+dw6k0oCD63UQG8vQ6Aa6ALlCWXwYP4hUFtyN5HW/LN2GUjXKs 6xkU2Lz/We8YxNV5fUH1k6O0k1xfrIv6KuHWbXf0HpYakil0IGJNCevH7BkrO8OheKqt Iq5VhyI4s3cewErR9AgiAKYrXTR6M5mXk95srAa3oehdIr0nxv4l9jKcctiIXnYp0h0n wkqGeJaR4NiNAcaoBq1QjHXZC/dOMuWeGcES/icUAHXuiXsbix8qDe0sttEzH/OCOfBT GAIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756826349; x=1757431149; 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=ElgHAVVNLwg9OsBq8IQHveis3g0DDocxmjJQYTfPOIY=; b=MAGlayu81SwtTUiSKQGmYlicjpsR3HADIMHnk7CW/AeSd3peBwM8lzOUOgHx/iMAPq Ah3F/Nh2g+fOuEvTFzeFEIYTNlZ3cFEt0Xe0Ntmokviu2akfDom92NFzs4/xXfW7mOxS 9xw6J6tpl9glYCJxXzGLTNL9VSVLqhkifalD6eu1eC8PEE4WYuLbZr3ysX6BbPQMxFji rfIWCGmgznDPJQ6VWk5ZtAod9tCxGfAhUztLCRYNqCwKyVwUHevPVNTesnhU9JoBp74i JnTD0MiFhIDPZAf/qRUKhOxr4pGfsXynNItZ6INkuv5pdMKe2ajVUzA1U/Zo+hsRLNYg rz5w== X-Forwarded-Encrypted: i=1; AJvYcCWcL3V4Bk0IMZJE6J4YGe6sAvFHVmPHdOkb5GMwaCs08aRHQbWpta8tL1AgjZLrE1L5Rg38S//fCtQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxY4HW5b463xj6YhaYgk8f9tQQnTgD+nAYf477yMCMX3sk+G92n o3oZqSjy8oP7/b2bU2XfEAHN22OdT6u4uCBug586GoR2E9uKWs8aGteJ2HRhJ+SyAioh8zU4wTI lccwKJWQ= X-Gm-Gg: ASbGncsHfcLI0ht1j4hXvDnlGRjCRZFAVp41DyCXFYSQVVGPpwo8tBM5rW8zC4XcfP3 Lt6CNrOXx49mwById+zUZlYN22hl6YvTbe09Nur2/btnX7bumwrNDcjRCgjUrcGkGFUprKjVz3J rO0F45IppT1SfjlYZXmJ0X1R9cc5sjs0oGR6RSjBLKVR+xNI3izs1b+WtIJ1L2DlhDDfHeu57kx wO4zheD+Qa7A83Ek3zHd0OIHFoZUCKV4AdFQdLpnAM4DgfJ0858fM6xpwP6CH0vK3y/TxyAq1dn bwiF4vxSEAPyK2zRpSPcX5SOS0CPUoxrUxzdbE/N5EKVFxuOPWUE4hRoqwMSkeHlsGl5qljLXOm Kma0P4bKi7mj5m1emvKsKxMdrVzRukztYdHeIPUHPZdtzkJGM8mBG7dU5oPJUpFN+Hjs+yz14ku bQ1U3wtv1tZOYscb1yaNhoE+56TUmvKv9ZDq6/QW6Ueoxg9QE= X-Google-Smtp-Source: AGHT+IHK/6t0CUQBqAgl9k1Xj4c34tPnjQ1B0gKcckG8Hg9hf+XEiYscuuNTQQl5ijJKYNRO4dBxOg== X-Received: by 2002:a17:906:478f:b0:afe:f651:118e with SMTP id a640c23a62f3a-b01d976e713mr1155638966b.49.1756826348657; Tue, 02 Sep 2025 08:19:08 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 17:19:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] Tidy up .gitignore To: Andrew Cooper , Xen-devel Cc: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20250902144937.1414411-1-andrew.cooper3@citrix.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20250902144937.1414411-1-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------QmqWKSwVUpvNzbVpnnIWrbH0" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QmqWKSwVUpvNzbVpnnIWrbH0 Content-Type: multipart/mixed; boundary="------------T7ZxjtksbhsgtG0Oyx5opl9z"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Andrew Cooper , Xen-devel Cc: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Message-ID: Subject: Re: [PATCH 1/2] Tidy up .gitignore References: <20250902144937.1414411-1-andrew.cooper3@citrix.com> In-Reply-To: <20250902144937.1414411-1-andrew.cooper3@citrix.com> Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------T7ZxjtksbhsgtG0Oyx5opl9z Content-Type: multipart/mixed; boundary="------------pPPwsi0nefxWAPDidgo06IPJ" --------------pPPwsi0nefxWAPDidgo06IPJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDIuMDkuMjUgMTY6NDksIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IERyb3AgdW51c2Vk IG9yIHN0YWxlIGxpbmVzLg0KPiANCj4gICAqIFdoaWxlIGl0J3MgbmVjZXNzYXJ5IHRvIGhh dmUgLmdpdCBhbmQgLmhnIGluIGVhY2ggb3RoZXJzIGlnbm9yZSBmaWxlcyBpZg0KPiAgICAg dXNpbmcgbXVsdGlwbGUgU0NNcyAoYXMgd2UgZGlkIGZvciBhIHdoaWxlKSwgdGhleSBzaG91 bGQgbm90IGJlIGluIHRoZWlyDQo+ICAgICBvd24uDQo+IA0KPiAgICogVGhlIGlnbm9yZSBm b3IgTGliVk5DU2VydmVyKiB3YXMgYWRkZWQgYnkgY29tbWl0IGEwOTBjYTQ5NWU3ZiAoIlZO QyBwYXN3b3JkDQo+ICAgICBhdXRoZW50aWNhdGlvbiBzdXBwb3J0IGZvciB0aGUgcGFyYXZp cnQgZnJhbWVidWZmZXIgc2VydmVyLiIpICAoMjAwNikgYnV0DQo+ICAgICB3aXRob3V0IGp1 c3RpZmljYXRpb24gb3IgYW55IG9idmlvdXMgcmVhc29uLg0KPiANCj4gICAqIFRoZSBpZ25v cmUgZm9yIHRvb2xzL21pc2MvbG93bWVtZCB3YXMgYWRkZWQgaW4gY29tbWl0IGM4MTIyODIw ODFiYiAoIkxvdw0KPiAgICAgbWVtIHZpcnEgaW5jcmVtZW50YWwgYWRqdXN0bWVudHMiKSAo MjAxMiksIGJ1dCB4ZW4tbG93bWVtZCAoZnJvbSB0aGUgc2FtZQ0KPiAgICAgYXV0aG9yKSBh bHJlYWR5IGV4aXN0ZWQgYW5kIHdhcyBpZ25vcmVkIHByb3Blcmx5Lg0KPiANCj4gICAqIHRv b2xzL2xpYnMvZ3Vlc3QveGNfKiB3ZXJlIGFkZGVkIGluIGNvbW1pdCBhZjZjNzhkOWRjNjgg KCJ0b29sczogbW92ZQ0KPiAgICAgbGlieGVuY3RybCBiZWxvdyB0b29scy9saWJzIikgZm9y IGJpc2VjdGliaWxpdHksIGJ1dCBzaG91bGQgaGF2ZSBiZWVuDQo+ICAgICBkcm9wcGVkIGlu IHRoZSBmb2xsb3dpbmcgY2hhbmdlLCBjb21taXQgZTNkZDYyNGU0ODdjICgidG9vbHMvbGli eGM6IG1vdmUNCj4gICAgIGxpYnhlbmd1ZXN0IHRvIHRvb2xzL2xpYnMvZ3Vlc3QiKS4NCj4g DQo+ICAgKiB0b29scy9kZWJ1Z2dlci94ZW5pdHAvIHdhcyBkcm9wcGVkIGluIGNvbW1pdCBl NTY3OTY0YTU0YjggKCJ0b29sczogZHJvcA0KPiAgICAgaWE2NCBzdXBwb3J0IikgKDIwMTIp Lg0KPiANCj4gICAqIHRvb2xzL2RlYnVnZ2VyL2dkYi8gd2FzIGRyb3BwZWQgaW4gY29tbWl0 DQo+ICAgICBiYWExYWFlOWNmZGQgKCJ0b29scy9kZWJ1Z2dlci9nZGI6IFJlbW92ZSBnZGIi KSAoMjAxMCkuDQo+IA0KPiAgICogdG9vbHMvbWlzYy9jcHVwZXJmLyB3YXMgZHJvcHBlZCBp biBjb21taXQgYWU5NWZkZjY1YTcyICgiW1RPT0xTXSBSZW1vdmUgdGhlDQo+ICAgICAnY3B1 cGVyZicgbWlzYyB0b29sLiIpICAoMjAwNikuDQo+IA0KPiAgICogdG9vbHMvbWlzYy94Y19z aGFkb3cgd2FzIGRyb3BwZWQgaW4gY29tbWl0IDcxMzMxNDRlM2FiZiAoIlJlbW92ZSB4Y19z aGFkb3cNCj4gICAgIHRvb2wiKSAoMjAwNykuDQo+IA0KPiAgICogdG9vbHMvbWlzYy94ZW5f Y3B1cGVyZiB3YXMgZHJvcHBlZCBpbiBjb21taXQgNjBlYmE5YjBkMjY1ICgiRGVsZXRlIHNv bWUNCj4gICAgIHVudXNlZCB0b29scyIpICgyMDA0KS4NCj4gDQo+ICAgKiB0b29scy9taXNj L3hlbi10bWVtLWxpc3QtcGFyc2Ugd2FzIGRyb3BwZWQgaW4gY29tbWl0IGM1ODhjMDAyY2Mx OSAoInRvb2xzOg0KPiAgICAgcmVtb3ZlIHRtZW0gY29kZSBhbmQgY29tbWFuZHMiKSAoMjAx OCkuDQo+IA0KPiBObyBmdW5jdGlvbmFsIGNoYW5nZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6 IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQoNClJldmlld2Vk LWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------pPPwsi0nefxWAPDidgo06IPJ 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----- --------------pPPwsi0nefxWAPDidgo06IPJ-- --------------T7ZxjtksbhsgtG0Oyx5opl9z-- --------------QmqWKSwVUpvNzbVpnnIWrbH0 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/Ey8FAmi3CusFAwAAAAAACgkQsN6d1ii/Ey9V YAf8CfUyp8LSIZKyBgLTQ6VlsWMewXJPJZqbRCH+3lJQpY+6rtU+Q46wqVHQs3yYDrrMEnm+m+ce Pa2jr21NhCzcr7aaRuHwBiZWMxSCCL/VQkJmOARrE1bkFIZPunpOigD7VEL13u+ysrXwXzlGsHGH SlX18NiQWqpvqMsxbc+dAIwH0s7Ti1K60XAE/5bFFLP6ZHdiuoot3mVJzNQl4inYUQeQbhOptLA+ 3BbgIV+X0PfKlVW9VLZ+cH3QkJPp0vwIv78yKrEVjxZMaDcYS0/AQmZn7qBAgX4tkic6SNiM/MfC O4m4cFp1H95MpNt4vRJ2VdLNCb0I/NKLsFLjTcsYlA== =2AEN -----END PGP SIGNATURE----- --------------QmqWKSwVUpvNzbVpnnIWrbH0-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:20:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:20:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107002.1457576 (Exim 4.92) (envelope-from ) id 1utSnl-0005Lt-Qi; Tue, 02 Sep 2025 15:20:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107002.1457576; Tue, 02 Sep 2025 15:20:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSnl-0005LD-Lz; Tue, 02 Sep 2025 15:20:05 +0000 Received: by outflank-mailman (input) for mailman id 1107002; Tue, 02 Sep 2025 15:20:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utSnk-00054a-4B for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:20:04 +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 4bd95e04-8810-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 17:20:02 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b043da5a55fso250311066b.0 for ; Tue, 02 Sep 2025 08:20:02 -0700 (PDT) Received: from ?IPV6:2003:e5:872d:6400:8c05:37ee:9cf6:6840? (p200300e5872d64008c0537ee9cf66840.dip0.t-ipconnect.de. [2003:e5:872d:6400:8c05:37ee:9cf6:6840]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0416842ffasm681476366b.38.2025.09.02.08.20.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 08:20: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: 4bd95e04-8810-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756826402; x=1757431202; 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=RVkZiqHNPziOj2HYZjxLi7i2pQWJGa7CBcmFaEbBK6Q=; b=JjCpvsT8dw+iMIzMfo9XjtY0DMGfT4EE6+hSj0dj6Zt1PqtRtcERfgLnkvUlAVoecY +BWmXRg3miBEzV2PU9+UJWlt6LlU52/eh3L99OGifwJ6YckYi4ltv4glpOU57JvmfMEf N9uh8IdTDmy+MpuJfBUjzTUOHfTD50NhRQ93QeArNIPK7Oyc0Vfonm6eXN5NphiJo+Dj yURaSKJHhybaY8nfsS1fp4HHrtgAF8OIJX3TA1dFXSdvBK/IpjWK33H8oMI3u+/emDo6 izB1g6onuHNGYv1vzKSedd80Cg16EeUx21aBZpF+MYqp/36OW/YIUgGGLWFhT/0MUt2t FB7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756826402; x=1757431202; 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=RVkZiqHNPziOj2HYZjxLi7i2pQWJGa7CBcmFaEbBK6Q=; b=n19lidsc2Mjy/jbYJhI3rljvH/txAfH3Rl/Xwtb4TdvS4LlQcDpj88vedMGHYgQmph 8bOBvO9sHh92cdoAy7ZMsIJUqIyILnHOJpSiI7Uk2cqbmnKHHY2uRRfTYaAys3xJs578 etNP46rFRySk4o0iemVtKxrQiE3hWZ6r878iAdutCPzlV4Na/uVU9uk99cNeYv5h3Ny0 m/sF9VPUC/WKF2jV8Zn3zw90aXeuJSiNyUQ5ZvRaPqEsD2vDCBUQLGjOLnfVjkuO205F S/sR38iJ5fN7tKvgAukQQC/ab/x9ig/bTUJT4UoGpx1WgNjMNPPtozRfNyChX0ALv5jq B6Qw== X-Forwarded-Encrypted: i=1; AJvYcCXGmqCQQHVAbSpMK0DXq1BgAkhjG/Z400KNUe7DdZn44/kic5kFpx9ojouZGdwyKgxzzk89jzGANkw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzjopknvCcacODnHHN+pLZVIxsUjnYcwJiM+nPK9R1BtlORfc82 gv7toHaP3fWFTaIYlShhwMhIJePODMOuKuYsjPmlBb4FCrFPcQ6EnRFkviIMsoRMsMw= X-Gm-Gg: ASbGncvrK8heKhBeFrZ7QDokx8f38ZnCYnPgAaUE76uAvW5eX6oblUJUDaew0Crv6yK xfTA6SKB6uDd5L3+ypvk4q9GEqIv8pG/3IphsHETJIj79CP5nAmeySZweJYTd85rpmKuSjbm4bO 2+TByvbypU0sBwcw9FJlOTWSh+qchFpK4xd4xNVIAjjPDCd5e1e1SM6sSMmSi+m9MvhcPR4upCY lt176QnfSxbbmK6EYEPNAk373Tp6rSoRp/Z30MpbohajpzCJO6ijmtfRwy56M1VdJ1VRXtwInYC u5Ps63c9D1k9WHJ4c7wr3tMy77RRSAdbjuMgGIuiUe5fB7RglZibZ9YPqsGHd5Y/X0kgVuOxnc0 gGioGy5KBL15VslWL97g5YBY8dvs1EMcvizHrfULSsbiGD4DQ8hpDOKmlAgNGuZlEVfINVZ2ZLF DlhZmay0jIPs3suNLHhf4NRTalrcBaXhlZo0nM2amXuan3BPtl2ozrd322eg== X-Google-Smtp-Source: AGHT+IE+dWvCqHdF3Rnz64iEYk58MEI9zrHtuRlZOrNKy7LzVDl8q0botejUp0lCDHkoOVPlVPq7Xg== X-Received: by 2002:a17:907:2d8c:b0:ae3:163a:f69a with SMTP id a640c23a62f3a-b01d9731cf9mr1383974666b.33.1756826401661; Tue, 02 Sep 2025 08:20:01 -0700 (PDT) Message-ID: <0b470e85-ec4b-475c-9caf-90d710ce4aff@suse.com> Date: Tue, 2 Sep 2025 17:20:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] tools/misc: Move ignores into local .gitignore To: Andrew Cooper , Xen-devel Cc: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20250902144937.1414411-1-andrew.cooper3@citrix.com> <20250902144937.1414411-2-andrew.cooper3@citrix.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20250902144937.1414411-2-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------TeUuLX0hfmmqTtKri009FpBx" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------TeUuLX0hfmmqTtKri009FpBx Content-Type: multipart/mixed; boundary="------------Yxj9ANO0R0dGh0IePqWjMoyi"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Andrew Cooper , Xen-devel Cc: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Message-ID: <0b470e85-ec4b-475c-9caf-90d710ce4aff@suse.com> Subject: Re: [PATCH 2/2] tools/misc: Move ignores into local .gitignore References: <20250902144937.1414411-1-andrew.cooper3@citrix.com> <20250902144937.1414411-2-andrew.cooper3@citrix.com> In-Reply-To: <20250902144937.1414411-2-andrew.cooper3@citrix.com> Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------Yxj9ANO0R0dGh0IePqWjMoyi Content-Type: multipart/mixed; boundary="------------fr3c2goI7TBX9RlQQbRpDaY2" --------------fr3c2goI7TBX9RlQQbRpDaY2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDIuMDkuMjUgMTY6NDksIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IC4uLiBpbnN0ZWFk IG9mIGhhdmluZyB0aGVtIHNwbGl0IGFjcm9zcyBtdWx0aXBsZS4NCj4gDQo+IE5vIGZ1bmN0 aW9uYWwgY2hhbmdlLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5k cmV3LmNvb3BlcjNAY2l0cml4LmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3Mg PGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo= --------------fr3c2goI7TBX9RlQQbRpDaY2 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----- --------------fr3c2goI7TBX9RlQQbRpDaY2-- --------------Yxj9ANO0R0dGh0IePqWjMoyi-- --------------TeUuLX0hfmmqTtKri009FpBx 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/Ey8FAmi3CyAFAwAAAAAACgkQsN6d1ii/Ey8L 2Qf8DBMqvBf0eFMDdabA5/ddjqx95p9lIDkYixCT7S7dxkWeRnwGdLMRX3X224Kmfe/GS0/bVYvW dbu00JMGy2g9SXCOVcTSDiq2QaWTx06juXFy0bbY0kwYv6lcRsFWlEBvDKP8gRvx43uaB4Q0h2iU dlVSaaxuRzcPdvpEQbXAqvmoUk93FRZlWUMeEOjtvpmXQ/lZ+YBLA/ITgH8ogKjPgR/FPQAHBD+s Z6/L5M/Cw/UsNLvckdN93xFMc9nzZsdQovGRnYw3p4EWvfxXTgR1wFGYAnjWa1N4fLTh03vpCatA s9ufKQB66qbe0rCc/zh1SKPiGxGGiNrP/jjLUJ++mQ== =2C7U -----END PGP SIGNATURE----- --------------TeUuLX0hfmmqTtKri009FpBx-- From xen-devel-bounces@lists.xenproject.org Tue Sep 02 15:43:35 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 15:43:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107020.1457587 (Exim 4.92) (envelope-from ) id 1utTAP-0003lx-NU; Tue, 02 Sep 2025 15:43:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107020.1457587; Tue, 02 Sep 2025 15:43:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utTAP-0003lq-KA; Tue, 02 Sep 2025 15:43:29 +0000 Received: by outflank-mailman (input) for mailman id 1107020; Tue, 02 Sep 2025 15:43: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 1utTAO-0003kW-G7 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 15:43:28 +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 90639adf-8813-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 17:43:25 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-afcb78ead12so908090666b.1 for ; Tue, 02 Sep 2025 08:43: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 a640c23a62f3a-aff032125e2sm1109337966b.77.2025.09.02.08.43.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 08:43: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: 90639adf-8813-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756827805; x=1757432605; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=s27sYcfBo5BedRsyoGQGSf1YPSKtWJMTiIniCWlPGGY=; b=C/b9lL+EH4uK0OFc5j7JqESxucXVTCu7jJ1iznTiMTO9XPERn2xBMqyc2PuL0w8a2m r12xr+TdPiCTuJt+7eRtIClhxD/iS/D3qC5/MjRHiMKhRdzg+WdmX9tTEosnuuU1AA6o aGKLYbN9ykKdp85rTGuS+/BG6N64BE2ngXv60AqZvKXiwa4JPcCetne9WU4eVGchtZsi BbyUb9wirNEIpxbdnReW22SzdgLuNtYM1VCKi+T+VMYubQe5Q/0otoCCVmkNEgVLjsLQ /Cd9v1k1PkR1budypjWMpEw4MzRMx8uku8F73IrNrYkVi2hje62CAkM9kQVSR9dNYZCW BomQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756827805; x=1757432605; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s27sYcfBo5BedRsyoGQGSf1YPSKtWJMTiIniCWlPGGY=; b=N9wOi+tkq79FGxWuyJuzGJEqS1209UvxtpdOfQYZmpMCRuMGxPz7Nnvs4j3DWsoSpF /+13/h4gV6TIFhY3UacGHSRXSwfSVeYkuc+HsW/KC7deRBxAzHl7Vz5jeZaOn0L8j+Ql S0kQUZRo6pAFtj5tVwmjCqXqGlp+wuREYlCIoqUv9W6CFTjNvvGRvEpEA6g6q8IwJPUO LnrAJEmGJsVCZMuB6wjXnwZBOeUjUEL/S2bUrfVUrgBlFYq/07I8zgxJXrH655R7KVda kvfxPqN69fC/CLRRpieZSI5Oyo1drjKRoQn5iwHJ6rOVygf0X3GKKg60HPVnqf8QZoLg dRnA== X-Forwarded-Encrypted: i=1; AJvYcCU4GiELvn2WTejblpQtf6t1u1BHpPO7LdwLcm+eY6x4Ml8TH8AmOYUpf3gwFoDTjqhMGlWN7naK+70=@lists.xenproject.org X-Gm-Message-State: AOJu0YxZ2CTf87hIPOAGoqnfmOPFlHoNkHRiZRKLchGjQf+XUW/CyXIr QDPhtzGT0aeZgokE4jDZgQ5OXllC3y2zezIklsXDjflWVk8kUQ8sQfJ+ZZRFqLX+ow== X-Gm-Gg: ASbGncvk/Fu58o6w0AxRdIMqjhrkDcnqAq9pu1jognESnJhvBX3ON8bSVzlSo3vc9f6 Yu+VKFxKpFrJ84k1WY61J7odr7+sIgWEMq9ezrkjJEWhcAKZyxL4eQz0KtEM8neADMNj0/h7PWE Fu261xzlTmNMG9y/F6anOvpfzKDT6VRyUNGWda3klmA2WSoAeJ2B8ZjwEzcaE03V5OoqsS874hm 6uzX1cqpozTGTpvqzVnLflTcNMpeko0xH3Me/fUueiAdpOUpokWAmQnSYI//jbpUZAIAmlElZ91 UsZfM/GymUMG1HtS6KKU7K4s/R36x2mQkxXXXDOKF2ZJZbCpLvVlxjQjXWueFhpAXDLgRGCZZLg es+HaJgAlsesdtu2C9fzzPCgDzSDD7cg5mZkRFNfydiSbnQI5E9lsPeY+MBmpnfWQxX986QRWjA 6CnjjSxUc= X-Google-Smtp-Source: AGHT+IGAGzP55INN6cbP87P1zEYMrcsF/s7z7vfo8PiifqpoLeyrXfsAOg8lIVV2TgH3ciDcNbsHhQ== X-Received: by 2002:a17:907:3e84:b0:afe:b818:a6bc with SMTP id a640c23a62f3a-b01f20ca2a4mr1150556666b.56.1756827805219; Tue, 02 Sep 2025 08:43:25 -0700 (PDT) Message-ID: <28e78684-ff7b-4902-89cd-c341ba236d57@suse.com> Date: Tue, 2 Sep 2025 17:43:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v13 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Mykola Kvach Cc: Mykola Kvach , 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: <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.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: <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2025 11:03, Mykola Kvach wrote: > --- > xen/arch/arm/domain.c | 37 ++++++++ > xen/arch/arm/include/asm/domain.h | 6 ++ > xen/arch/arm/include/asm/perfc_defn.h | 1 + > xen/arch/arm/include/asm/psci.h | 2 + > xen/arch/arm/include/asm/suspend.h | 18 ++++ > xen/arch/arm/include/asm/vpsci.h | 5 +- > xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- > xen/common/domain.c | 9 ++ > xen/include/xen/domain.h | 11 +++ > 9 files changed, 183 insertions(+), 22 deletions(-) > create mode 100644 xen/arch/arm/include/asm/suspend.h Note, btw, how this way you won't need x86, ppc, and riscv acks. > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -8,6 +8,10 @@ > > #include > > +#if __has_include() > +#include > +#endif > + > struct guest_area { > struct page_info *pg; > void *map; > @@ -109,6 +113,13 @@ int arch_domain_soft_reset(struct domain *d); > > void arch_domain_creation_finished(struct domain *d); > > +#if !__has_include() > +static inline int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > +#endif /* !__has_include() */ > + > void arch_p2m_set_access_required(struct domain *d, bool access_required); > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c); Imo it would be preferable to have such in a single #if/#else. There's nothing wrong with an #include not sitting at the very top. (Another question is whether to put this in xen/domain.h at all. There could be a xen/suspend.h having - for now at least - just this and nothing else.) Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:09:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:09:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107038.1457596 (Exim 4.92) (envelope-from ) id 1utTYw-0000SX-K6; Tue, 02 Sep 2025 16:08:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107038.1457596; Tue, 02 Sep 2025 16: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 1utTYw-0000SQ-HY; Tue, 02 Sep 2025 16:08:50 +0000 Received: by outflank-mailman (input) for mailman id 1107038; Tue, 02 Sep 2025 16:08: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 1utTYu-0000SK-Lg for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:08:48 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1ac103a5-8817-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 18:08:46 +0200 (CEST) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-45b8b02dd14so15715125e9.1 for ; Tue, 02 Sep 2025 09:08:46 -0700 (PDT) Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b6f306c22sm288788585e9.13.2025.09.02.09.08.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 09:08: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: 1ac103a5-8817-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756829326; x=1757434126; 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=CBE0Vkk4sDZznE4o41DGgJzs1KLfClxgmngsyUAfs0A=; b=nkwpVK/1lgQ5smlc4xbBdNpn/ef2Saurt6RxsNrsSqzwjajG74gHGtCDSfN/kVeSNz 08Kcz4LpbSn0cWPeKR8rErCtYxgRNv9xBY3MSc9W23rfxgNvjFA4rc3fW5j0B5NcABD1 sXKzRWboFDrohcsgdZFprYbRziZmVg/mM0C3IG2hV46jLhrrgZmwLXKI5o1bqXB8Zgif Cx/BhlST6cZx4b3RrAlTh4kReC8Svy6mrs1Z9Bp3rasBFqtCExO7iZhVsFyRsTiAjoOc +qTme4A5opOmLYwwgShKkGCUtD/yTFg2SzR8/17gpDByg/DONCDtZEmJVELLyrowEyGI rDcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756829326; x=1757434126; 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=CBE0Vkk4sDZznE4o41DGgJzs1KLfClxgmngsyUAfs0A=; b=Mwl6WglYbv3Jkk/MzlECJk4r+f+ca22G5QinBmZpNsZFPNZ5miPlkZ9b0lyOxLH9nX 6aGcnXCbZ85O5smFn6855qOcp2214joFBnQ1s/YvUBJABYrRlLXb9ZP9pUsNoUmKMndl jOvPMrDf9+1dvHTSbX9ZIlgeLqlOdnph51aXJOKeg0KGvQxsP31PYN/T/xdVAQHfZdu3 +A/VJZv/e2Rm69ddt7bFbqU3x45AXp6AHXmvplJJowRfWTTHPM8Wy7s1X05hWbJl7vC5 iqkM1yVjKiXXGrz13+q6bAgWtSazLuLLKlqdGvMg9EVkC3qoxy3ADyau3LXsulhBM+Z7 oXig== X-Forwarded-Encrypted: i=1; AJvYcCWIN+TjOUTVgQywppLDhvxhTNxkzTgSeiOkXpidTpeVKfL2ayAVwSjUrL7Q1F6wFj3ogIgeoQUWh8U=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz9LLmXnGSMhQPToYDgl/GYl12FAoqlkCiekP6qDRk3kiPI10SW yL6hRaE4Uw0AnkRDR7mtgQGbpcaxUxj2SLKEJ25NcGTO0I4s38CoL+8s X-Gm-Gg: ASbGncvjuTgCsaHxCqOQtJh0AZMoH4nAfC/ImXF0ETmMpG1nL/WLr3N0PNjcLofnd7f NjU08pg/Eh1GRVRw/tyOQ+7Mdmh2DScgx+QWEv0gOMCKxOyxSscGkjQIoaMxpfh18aUsCZa7sMM oDHqvPgA+/SE60kI17GEsFbTSXGbwyfwu3LJ/z75weG7lyEy7A7Um+LIWYLPP7DvN/Pf0+Ch7OS eVMY4IbxAsQVBaVGljY69tDYt2RKxJ6bgveGBl6zZIL4f0vR3nbRQc5HohjlgpRQrH9Pb7mF6tW SYS2Xdtn6qlqMNViLUdVqqbL8xbVfI8w1jMWprcbxeAbU4bdemCOnMAE5VHXUgRSOqDQDeLEipm iygrOwkmvYHuMwu7TZA1eFMXWNeRO3ClaACtK3MaxXg5c3/SVWao3X3A= X-Google-Smtp-Source: AGHT+IGTowq7ER+TW92EsrtfzwrIp54X5Yg/9nwRUy14eU69NHA4ky0DnWgHFHc9/0Y6iPI7pOT8PQ== X-Received: by 2002:a05:600c:1551:b0:45b:88b1:373d with SMTP id 5b1f17b1804b1-45b8d3e4062mr68850475e9.30.1756829325430; Tue, 02 Sep 2025 09:08:45 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 19:08:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 03/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.09.25 01:10, Mykola Kvach wrote: Hello Mykola > From: Mykola Kvach > > 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. > > Signed-off-by: Mykola Kvach > --- > Changes in V6: > - Drop gicv3_save/restore_state since it is already handled during vCPU > context switch. > - The comment about systems without SPIs is clarified for readability. > - Error and warning messages related to suspend context allocation are unified > and now use printk() with XENLOG_ERR for consistency. > - The check for suspend context allocation in gicv3_resume() is removed, > as it is handled earlier in the suspend path. > - The loop for saving and restoring PPI/SGI priorities is corrected to use > the proper increment. > - The gicv3_suspend() function now prints an explicit error if ITS suspend > support is not implemented, and returns ENOSYS in this case. > - The GICD_CTLR_DS bit definition is added to gic_v3_defs.h. > - The comment for GICR_WAKER access is expanded to reference the relevant > ARM specification section and clarify the RAZ/WI behavior for Non-secure > accesses. > - Cleanup active and enable registers before restoring. > --- > xen/arch/arm/gic-v3-lpi.c | 3 + > xen/arch/arm/gic-v3.c | 235 +++++++++++++++++++++++++ > xen/arch/arm/include/asm/gic_v3_defs.h | 1 + > 3 files changed, 239 insertions(+) > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > index de5052e5cf..61a6e18303 100644 > --- a/xen/arch/arm/gic-v3-lpi.c > +++ b/xen/arch/arm/gic-v3-lpi.c > @@ -391,6 +391,9 @@ static int cpu_callback(struct notifier_block *nfb, unsigned long action, > switch ( action ) > { > case CPU_UP_PREPARE: > + if ( system_state == SYS_STATE_resume ) > + break; > + > rc = gicv3_lpi_allocate_pendtable(cpu); > if ( rc ) > printk(XENLOG_ERR "Unable to allocate the pendtable for CPU%lu\n", > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index cd3e1acf79..9f1be7e905 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -1776,6 +1776,233 @@ static bool gic_dist_supports_lpis(void) > return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS); > } > > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +/* GICv3 registers to be saved/restored on system suspend/resume */ > +struct gicv3_ctx { > + struct dist_ctx { > + uint32_t ctlr; > + /* > + * This struct represent block of 32 IRQs > + * TODO: store extended SPI configuration (GICv3.1+) > + */ > + struct irq_regs { > + uint32_t icfgr[2]; > + uint32_t ipriorityr[8]; > + uint64_t irouter[32]; > + uint32_t isactiver; > + uint32_t isenabler; > + } *irqs; > + } dist; > + > + /* have only one rdist structure for last running CPU during suspend */ > + struct redist_ctx { > + uint32_t ctlr; > + /* TODO: handle case when we have more than 16 PPIs (GICv3.1+) */ > + uint32_t icfgr[2]; > + uint32_t igroupr; > + uint32_t ipriorityr[8]; > + uint32_t isactiver; > + uint32_t isenabler; > + } rdist; > + > + struct cpu_ctx { > + uint32_t ctlr; > + uint32_t pmr; > + uint32_t bpr; > + uint32_t sre_el2; > + uint32_t grpen; > + } cpu; > +}; > + > +static struct gicv3_ctx gicv3_ctx; > + > +static void __init gicv3_alloc_context(void) > +{ > + uint32_t blocks = DIV_ROUND_UP(gicv3_info.nr_lines, 32); > + > + /* We don't have ITS support for suspend */ > + if ( gicv3_its_host_has_its() ) > + return; > + > + /* The spec allows for systems without any SPIs */ > + if ( blocks > 1 ) > + { > + gicv3_ctx.dist.irqs = xzalloc_array(typeof(*gicv3_ctx.dist.irqs), > + blocks - 1); > + if ( !gicv3_ctx.dist.irqs ) > + printk(XENLOG_ERR "Failed to allocate memory for GICv3 suspend context\n"); > + } > +} > + > +static void gicv3_disable_redist(void) > +{ > + void __iomem* waker = GICD_RDIST_BASE + GICR_WAKER; > + > + /* > + * Avoid infinite loop if Non-secure does not have access to GICR_WAKER. > + * See Arm IHI 0069H.b, 12.11.42 GICR_WAKER: > + * When GICD_CTLR.DS == 0 and an access is Non-secure accesses to this > + * register are RAZ/WI. > + */ > + if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) ) > + return; > + > + writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, waker); > + while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) == 0 ); > +} > + > +static int gicv3_suspend(void) > +{ > + unsigned int i; > + void __iomem *base; > + typeof(gicv3_ctx.rdist)* rdist = &gicv3_ctx.rdist; > + > + /* TODO: implement support for ITS */ > + if ( gicv3_its_host_has_its() ) > + { > + printk(XENLOG_ERR "GICv3: ITS suspend support is not implemented\n"); > + return -ENOSYS; > + } > + > + if ( !gicv3_ctx.dist.irqs && gicv3_info.nr_lines > NR_GIC_LOCAL_IRQS ) > + { > + printk(XENLOG_ERR "GICv3: suspend context is not allocated!\n"); > + return -ENOMEM; > + } > + > + /* Save GICC configuration */ > + gicv3_ctx.cpu.ctlr = READ_SYSREG(ICC_CTLR_EL1); > + gicv3_ctx.cpu.pmr = READ_SYSREG(ICC_PMR_EL1); > + gicv3_ctx.cpu.bpr = READ_SYSREG(ICC_BPR1_EL1); > + gicv3_ctx.cpu.sre_el2 = READ_SYSREG(ICC_SRE_EL2); > + gicv3_ctx.cpu.grpen = READ_SYSREG(ICC_IGRPEN1_EL1); > + > + gicv3_disable_interface(); > + gicv3_disable_redist(); > + > + /* Save GICR configuration */ > + gicv3_redist_wait_for_rwp(); > + > + base = GICD_RDIST_SGI_BASE; > + > + rdist->ctlr = readl_relaxed(base + GICR_CTLR); > + > + /* Save priority on PPI and SGI interrupts */ > + for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > + rdist->ipriorityr[i] = readl_relaxed(base + GICR_IPRIORITYR0 + 4 * i); > + > + rdist->isactiver = readl_relaxed(base + GICR_ISACTIVER0); > + rdist->isenabler = readl_relaxed(base + GICR_ISENABLER0); > + rdist->igroupr = readl_relaxed(base + GICR_IGROUPR0); > + rdist->icfgr[0] = readl_relaxed(base + GICR_ICFGR0); GICR_ICFGR0 is for SGIs, which are always edge-triggered, so I am not sure that we need to save it here ... > + rdist->icfgr[1] = readl_relaxed(base + GICR_ICFGR1); > + > + /* Save GICD configuration */ > + gicv3_dist_wait_for_rwp(); > + gicv3_ctx.dist.ctlr = readl_relaxed(GICD + GICD_CTLR); > + > + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + { > + typeof(gicv3_ctx.dist.irqs) irqs = gicv3_ctx.dist.irqs + i - 1; > + unsigned int irq; > + > + base = GICD + GICD_ICFGR + 8 * i; > + irqs->icfgr[0] = readl_relaxed(base); > + irqs->icfgr[1] = readl_relaxed(base + 4); > + > + base = GICD + GICD_IPRIORITYR + 32 * i; > + for ( irq = 0; irq < 8; irq++ ) > + irqs->ipriorityr[irq] = readl_relaxed(base + 4 * irq); > + > + base = GICD + GICD_IROUTER + 32 * i; > + for ( irq = 0; irq < 32; irq++ ) > + irqs->irouter[irq] = readq_relaxed_non_atomic(base + 8 * irq); > + > + irqs->isactiver = readl_relaxed(GICD + GICD_ISACTIVER + 4 * i); > + irqs->isenabler = readl_relaxed(GICD + GICD_ISENABLER + 4 * i); > + } > + > + return 0; > +} > + > +static void gicv3_resume(void) > +{ > + unsigned int i; > + void __iomem *base; > + typeof(gicv3_ctx.rdist)* rdist = &gicv3_ctx.rdist; > + > + writel_relaxed(0, GICD + GICD_CTLR); > + > + for ( i = NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i += 32 ) > + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4); > + > + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + { > + typeof(gicv3_ctx.dist.irqs) irqs = gicv3_ctx.dist.irqs + i - 1; > + unsigned int irq; > + > + base = GICD + GICD_ICFGR + 8 * i; > + writel_relaxed(irqs->icfgr[0], base); > + writel_relaxed(irqs->icfgr[1], base + 4); > + > + base = GICD + GICD_IPRIORITYR + 32 * i; > + for ( irq = 0; irq < 8; irq++ ) > + writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); > + > + base = GICD + GICD_IROUTER + 32 * i; > + for ( irq = 0; irq < 32; irq++ ) > + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); > + > + writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLER + i * 4); > + writel_relaxed(irqs->isenabler, GICD + GICD_ISENABLER + i * 4); > + > + writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVER + i * 4); > + writel_relaxed(irqs->isactiver, GICD + GICD_ISACTIVER + i * 4); > + } > + > + writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); > + gicv3_dist_wait_for_rwp(); > + > + /* Restore GICR (Redistributor) configuration */ > + gicv3_enable_redist(); > + > + base = GICD_RDIST_SGI_BASE; > + > + writel_relaxed(0xffffffff, base + GICR_ICENABLER0); > + gicv3_redist_wait_for_rwp(); > + > + for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > + writel_relaxed(rdist->ipriorityr[i], base + GICR_IPRIORITYR0 + i * 4); > + > + writel_relaxed(rdist->isactiver, base + GICR_ISACTIVER0); > + > + writel_relaxed(rdist->igroupr, base + GICR_IGROUPR0); > + writel_relaxed(rdist->icfgr[0], base + GICR_ICFGR0); ... and restore it here. > + writel_relaxed(rdist->icfgr[1], base + GICR_ICFGR1); > + [snip] From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:15:29 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:15:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107054.1457608 (Exim 4.92) (envelope-from ) id 1utTfI-0002d7-F2; Tue, 02 Sep 2025 16:15:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107054.1457608; Tue, 02 Sep 2025 16: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 1utTfI-0002d0-B9; Tue, 02 Sep 2025 16:15:24 +0000 Received: by outflank-mailman (input) for mailman id 1107054; Tue, 02 Sep 2025 16: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 1utTfG-0002cu-TV for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:15: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 038d166a-8818-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 18:15:17 +0200 (CEST) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-3dae49b1293so559977f8f.1 for ; Tue, 02 Sep 2025 09:15:17 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b98e77231sm31748715e9.12.2025.09.02.09.15.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 09:15: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: 038d166a-8818-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756829716; x=1757434516; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8rpCTPTFw8X4eh6zkPAZWJ5LiQbfBpH/0A49TUy6YBA=; b=Unoa3NgAoYEw/xNE6OEPKhve9TBsp676LEg+t8DqLDgwoch0Rnrl1ZRk9NAK6H9mIc mxpUXaXPu6thu8QXUfoqwso/s+LmYDIBsIwmuTJ3YzO1wQOsuhxggjXGslZnH/OnzzfR 7JJYQzHYmU6PwD6A1xd9f6qxPY/j8Fhf65Uzo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756829716; x=1757434516; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8rpCTPTFw8X4eh6zkPAZWJ5LiQbfBpH/0A49TUy6YBA=; b=p2wfLpsb9npILYNYZsppDCMHl3skGld3uosL2M/PkGDwVWocSXbAZDKsTCSs6h1TPm xQC+ZlvMn+VaC3AJS4GqGZRGNrWX7iF0VW7Y5PslhmjWmsNtE1Fr3zcbeBx3qqaa+xlH fE7xBroV288NbsFptX2Pxgu0zgjIR5tvRl8eOaYSc0FZcOIb1SoFhWKtCpa295EWpeyF 0WO8IfFUhOhdG1L70xFjSuFJGM1i03LANFPsj8ef14d5N5M6PWwSxAgju0N1wJF1YJ2X V9Y4KBqLSbaVi/+IyE1IqrsVWHGsSldvh9mkL0CFZOTpYEdjCXT88oV0fHAqoK7lNb4+ XLOA== X-Forwarded-Encrypted: i=1; AJvYcCWZZe0W8UVcIon6vjPfVBGPm+GpM3xzz7R6W1Myp7h8xV92HnbFq2g1JzTYcELm++Nrx+vePvbpWHc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxXJsVYSFqrdv7mcLW7236NPVK05Wt+Eknra7oaUPK0MR2As7pR EWvTVlZn0g/X8qqb3ZjLt26IhDwmxueSoAsrFL/vv8GQftpE7wZObkwobAq5DodarjWY5RjIKsN GEqup X-Gm-Gg: ASbGncs3VMWIF+k2EcV8yRjYsSCSipfWprcx8oBO3voCQ/T6MsqvxOe+bRaC9QurXNB qI0toWWjH2ZDGy5SmWLotmJ2an4X1ZMjXqHgFkTGde6h2XNZfxTQQnTuWQQvOhi2rBhjVEVO9Hc OmsGOF28DD0E8XPXCb98nCxaXYDimrrcTutlCb6qBNyFhIdK328+pdqCi+NGt8PIoHD1SyQox3M SUcdTFVpGQ7Nd/53VYpw0u1oRZRf4rqRXBO4sUEcwh2V/3FgKqsD5GpLyuBmISXOlQCoS0pQZpV AGZKDkkDWU2nEjFqHTO5B+XYnDigPWpt7CIMsiT5Cw7yFmF6o+C7RrC1237jvRowQjbjWbm72Ox h5s0KRwq7r+7R4Pj1NHtGBpKzLH0UOS07i6+0h15zYaKtysK0GfJYpbVmpuX5Sf5S5vzM X-Google-Smtp-Source: AGHT+IE/AyVSkKsjhPXo2LgmBpxtIFIwbOo5KWGKKcl8U81GcYp6/IDMatSE7EsGOFQx/bYuImj0rg== X-Received: by 2002:a05:6000:22ca:b0:3d0:64c1:1a40 with SMTP id ffacd0b85a97d-3d1e01d67bemr10175487f8f.46.1756829716216; Tue, 02 Sep 2025 09:15:16 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 17:15:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] releases: use newer compression methods for tarballs 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: 8bit On 25/08/2025 2:54 pm, Jan Beulich wrote: > Other projects have long switched to xz and/or lzip. > > Tidy things some as well: With the removal of qemu from the tarball, > intermediately extracting the tarball again has become wasteful. Drop > that. Invoke compressors using asynchronous lists, to reduce overall > latency. Drop the -v option from the (previously implicit) gzip > invocation. > > Signed-off-by: Jan Beulich > --- > v2: Don't expand intermediate uncompressed tarball. Don't check for > commands' availablity. Don't request statistics. Use async lists. > > --- a/docs/process/release-technician-checklist.txt > +++ b/docs/process/release-technician-checklist.txt > @@ -119,7 +119,7 @@ RELEASE TARBALL > make src-tarball # uses git-describe (best for RCs) > # ^find some way to add git-cache-proxy to this (done in ~iwj/.gitconfig) > mkdir /volatile/iwj/website-thing/xen.org/oss-xen/release/$v > - mv dist/xen-$v.tar.gz /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/. > + mv dist/xen-$v.tar.[glx]z /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/. > > # website-thing/xen.org is cvs -d mail.xenproject.org:/home/downloads-cvs/cvs-repos co xen.org > cd /volatile/iwj/website-thing/xen.org > @@ -139,9 +139,12 @@ RELEASE TARBALL > cvs add -kb oss-xen/release/$v/ > > cd oss-xen/release/$v > - gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' xen-$v.tar.gz > - cvs add -kb xen-$v.tar.gz > - cvs add -kb xen-$v.tar.gz.sig > + for t in xen-$v.tar.[glx]z > + do > + gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' $t > + cvs add -kb $t > + cvs add -kb $t.sig > + done > cd ../../.. > > cvs ci -m $v > @@ -152,6 +155,10 @@ RELEASE TARBALL > # should show something like > # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz > # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz.sig > + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.lz > + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.lz.sig > + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.xz > + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.xz.sig > > After a .0 release, update XEN_EXTRAVERSION again (to .1-pre, see above). > > --- a/docs/process/xen-release-management.pandoc > +++ b/docs/process/xen-release-management.pandoc > @@ -274,10 +274,10 @@ Xen X.Y rcZ is tagged. You can check tha > https://xenbits.xen.org/git-http/xen.git X.Y.0-rcZ > > For your convenience there is also a tarball at: > -https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz > +https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.[glx]z > > And the signature is at: > -https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz.sig > +https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.[glx]z.sig > > Please send bug reports and test reports to xen-devel@lists.xenproject.org. > When sending bug reports, please CC relevant maintainers and me > --- a/tools/misc/mktarball > +++ b/tools/misc/mktarball > @@ -5,14 +5,6 @@ > # Takes 2 arguments, the path to the dist directory and the version > set -ex > > -function git_archive_into { > - mkdir -p "$2" > - > - git --git-dir="$1"/.git \ > - archive --format=tar HEAD | \ > - tar Cxf "$2" - > -} > - > if [[ -z "$1" || -z "$2" ]] ; then > echo "usage: $0 path-to-XEN_ROOT xen-version" > exit 1 > @@ -21,14 +13,20 @@ fi > xen_root="$1" > desc="$2" > > -tdir="$xen_root/dist/tmp.src-tarball" > +tdir="$xen_root/dist" > > -rm -rf $tdir > +rm -f $tdir/xen-$desc.tar.[glx]z This is asymmetric with the rm at the end.  I'd remove $tdir/xen-$desc.tar* here and remove the final rm. Looking at the uncompressed tarball is part of my process, and it was preserved previously. With something along these lines, Reviewed-by: Andrew Cooper > > mkdir -p $tdir > > -git_archive_into $xen_root $tdir/xen-$desc > +git --git-dir="$xen_root/.git" archive --format=tar HEAD --prefix=xen-$desc/ \ > + >"$tdir/xen-$desc.tar" > + > +gzip -9k "$tdir/xen-$desc.tar" & > +xz -9k "$tdir/xen-$desc.tar" & > +lzip -9k "$tdir/xen-$desc.tar" & > +wait Interestingly, this wasn't fatal for not having lzip, but the error was clear on the console given the reduced verbosity, and doing 3 at the same time worked very nicely. > > -GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc > +rm -f $tdir/xen-$desc.tar > > -echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz" > +echo "Source tarball in" $tdir/xen-$desc.tar.[glx]z This was grammatically awkward to begin with, but is now pretty useless, especially combined with the set -x so it gets printed twice. Something like this: echo "Source tarballs:" ls -lah $tdir/xen-$desc.tar* generates: -rw-rw-r-- 1 andrew andrew  32M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar -rw-rw-r-- 1 andrew andrew 6.8M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.gz -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.lz -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.xz on my system and is rather more useful IMO. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:24:46 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:24:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107066.1457617 (Exim 4.92) (envelope-from ) id 1utToG-0004cl-8O; Tue, 02 Sep 2025 16:24:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107066.1457617; Tue, 02 Sep 2025 16:24:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utToG-0004ce-5C; Tue, 02 Sep 2025 16:24:40 +0000 Received: by outflank-mailman (input) for mailman id 1107066; Tue, 02 Sep 2025 16:24: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 1utToE-0004cY-AX for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:24:38 +0000 Received: from mail180-6.suw31.mandrillapp.com (mail180-6.suw31.mandrillapp.com [198.2.180.6]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 50b193d1-8819-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 18:24:36 +0200 (CEST) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-6.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4cGWKb0WjMz2K26vj for ; Tue, 2 Sep 2025 16:24:35 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 5e1a612a322445909a6d6fba84a1902f; Tue, 02 Sep 2025 16:24:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50b193d1-8819-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1756830275; x=1757100275; bh=n5RkPVqtiuLNefJ34qS3+Xaj6pVCICTdq8QdOKNDxko=; 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=nGmV4vFkkPBfnKvfKG8LEa1C8lBK4P3wQf1a58J/t646s2N404RQiEwUZ0iQzTodj myAeMvU9YV9jmdZ2fWRjlAsqdEB0gRuav3svHn0rNp07mQLBiHeFDAZq+ptDpZZ01L hnwbW+Juy8iMmz9FtGaA4/v3cazfrfwyv4WH9uYL52kwVDIyms0PoLngz8/NgZ3Dyd EciyApEPTvt4WB+o7cao9/IDI1hWhIBy31/8doTv4a+8wtwzeMv6jwyZT9e1q+kYk1 9DOjkua0X3rCp+5hxNbdhX2bO8fWnMcQ28Pe6fL/zO6MaFlpqcF2eeOSNQtzjnHr+V BGy+SlC0RHGcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1756830275; x=1757090775; i=teddy.astie@vates.tech; bh=n5RkPVqtiuLNefJ34qS3+Xaj6pVCICTdq8QdOKNDxko=; 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=WkiL5MNzWk7UeBBXh7/qF4HNn9cUYM0YiqTDzUYpZcljyPl/81v3xZ5ApGtkGAaez 8c/5lctQXG+HM0/GxrTDkNvGcGxLBpfWluvFf/xhxUS7rlgWAM5ViH3oPs7HtdkeEh aRQMTK9lWupL0Xd0wOgaxNB9fxYSaoaTfCHqF4ms4YsYsvVYD4tKxpqjrYVULbNqMz m0nLGj/gktVXKvNsgug6IbvSUibZ0UeAl3o+YaGawbmniqmyWb4+ZzDCg5uXg2daL6 FrmaiDsdr5NHBh9v9cUb9EV6gXav6DPaizvZKq6U7dO6A/MVNP7ckFKCGNSWBe6StN c3YdY3Haca5iQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v5.10.y]=20xen:=20replace=20xen=5Fremap()=20with=20memremap()?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1756830272879 Message-Id: To: "Greg Kroah-Hartman" Cc: xen-devel@lists.xenproject.org, stable@vger.kernel.org, "Juergen Gross" , "kernel test robot" , "Boris Ostrovsky" , "Stefano Stabellini" , "Anthoine Bourgeois" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "H. Peter Anvin" , "Jiri Slaby" References: <4cc9c1f583fb4bfca02ff7050b9b01cb9abb7e7f.1756803599.git.teddy.astie@vates.tech> <2025090203-clothes-bullish-a21f@gregkh> In-Reply-To: <2025090203-clothes-bullish-a21f@gregkh> 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.5e1a612a322445909a6d6fba84a1902f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250902:md Date: Tue, 02 Sep 2025 16:24:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 02/09/2025 =C3=A0 13:18, Greg Kroah-Hartman a =C3=A9crit=C2=A0: > On Tue, Sep 02, 2025 at 09:28:32AM +0000, Teddy Astie wrote: >> From: Juergen Gross >> >> From: Juergen Gross >> >> [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] >> >> xen_remap() is used to establish mappings for frames not under direct >> control of the kernel: for Xenstore and console ring pages, and for >> grant pages of non-PV guests. >> >> Today xen_remap() is defined to use ioremap() on x86 (doing uncached >> mappings), and ioremap_cache() on Arm (doing cached mappings). >> >> Uncached mappings for those use cases are bad for performance, so they >> should be avoided if possible. As all use cases of xen_remap() don't >> require uncached mappings (the mapped area is always physical RAM), >> a mapping using the standard WB cache mode is fine. >> >> As sparse is flagging some of the xen_remap() use cases to be not >> appropriate for iomem(), as the result is not annotated with the >> __iomem modifier, eliminate xen_remap() completely and replace all >> use cases with memremap() specifying the MEMREMAP_WB caching mode. >> >> xen_unmap() can be replaced with memunmap(). >> >> Reported-by: kernel test robot >> Signed-off-by: Juergen Gross >> Reviewed-by: Boris Ostrovsky >> Acked-by: Stefano Stabellini >> Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com >> Signed-off-by: Juergen Gross >> Signed-off-by: Teddy Astie [backport to 5.10.y] >> --- > > Why is this needed for 5.10.y at all? What bug does it fix? And why > are you still using Xen on a 5.10.y kernel? What prevents you from > moving to a newer one? > This patch is only useful for virtual machines (DomU) that runs this Linux version (a notable Linux distribution with this kernel branch is Debian 11); it's not useful for Dom0 kernels. On AMD platforms (and future Intel ones with TME); this patch along with [1] makes the caching attribute for access as WB instead of falling back to UC due to ioremap (within xen_remap) being used improving the performance as explained in the commit. [1] x86/hvmloader: select xen platform pci MMIO BAR UC or WB MTRR cache attribute https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommit;h=3D22650d6054625be1= 0172fe0c78b9cadd1a39bd63 > thanks, > > greg k-h > Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:41:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:41:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107083.1457627 (Exim 4.92) (envelope-from ) id 1utU40-0007fF-Ht; Tue, 02 Sep 2025 16:40:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107083.1457627; Tue, 02 Sep 2025 16:40:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utU40-0007f8-Ed; Tue, 02 Sep 2025 16:40:56 +0000 Received: by outflank-mailman (input) for mailman id 1107083; Tue, 02 Sep 2025 16:40:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utU3z-0007dl-2q for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:40:55 +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 97e28c78-881b-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 18:40:54 +0200 (CEST) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-45b7d485173so35247595e9.0 for ; Tue, 02 Sep 2025 09:40:54 -0700 (PDT) Received: from [192.168.1.183] (host-195-149-20-212.as13285.net. [195.149.20.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7d9548edsm128113305e9.5.2025.09.02.09.40.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 09:40: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: 97e28c78-881b-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1756831254; x=1757436054; 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=w995QXMl+ajSCUdhcTsbZeyt3v+uJlHG+nqUSvW9xio=; b=L1SN4yi8tO45ZByEFiU5K+o+KWygRJ7nK9QtzzfOzgs4AfRdQrjziN9yEQlV9Yj+5U 07HEw1DCYacNpuC0CXNoKpz34lHmCybmTnD8LgKLgHwPFEacZJKh+AaYdl2Fm8qecdBQ RjyHOI9sf+vIEVO5YTBCXgEnZOQelHRtT25B8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756831254; x=1757436054; 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=w995QXMl+ajSCUdhcTsbZeyt3v+uJlHG+nqUSvW9xio=; b=IzAiVqFj1qsS40T6ZvhhtztMyJECVThjmY1CP/6hpC7lvMHJM75cmIQOKdIP6nSpUI ztY0JQ0LWhGlGVN0rFqgPwDMz/Axo2pqrJ5gEdFjubROlwn/xhHXO/Llt95RfL2pr5Fp 51/oXiHBeXOyRf3WR/vSW+gwnVz9AEJRDsBoK5jhQgiPFxR5hEKXkr67w7CwFRnkqPi7 YryXDrkcKheG/xHcih5b+eDq+EHtALDCn4zQF19tg/cCFrOzRlpSgcFBCtAE4bAaJe1l mKkAR/Mvk3AoNb/0q1A6oOJ6SSkcviAYEjd6VcQ6fc5RxV0c4jws6zw24+i/0rtAYJlX 5FfA== X-Forwarded-Encrypted: i=1; AJvYcCVTy286GekLf6SMjFkqBh8c9RQD5Fx4oyHQP6nzAxTyKuU0dwearwNgzHrZhr4/n2GE61ybFXU2beI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzhUNcNWhZ7BloyB7oG7B/FoX9shC7MkLunjZowEm0/LBhzu8br dAL5c7D5eHlEqyRtautPnBFDcu71CzBwWgzD4plA7CdptV0+vwjG9t4wmabXplIcMwc= X-Gm-Gg: ASbGncvxI25AzMxEZeufTbHNB+xYGVmc8vYe9RGFUuC8iTHf8gsDXVvIeyO1IDDnL/Z t8UPDdK+bTuZ8zqdEm7lUwf7vsizfkiN4nqMSJPcSZE50i5tU2KMIXgrcxyqp2+Pq0v5eYvj1kI /P01UKdfJHazL4l9FeNZCTdyAT2Z8qOjCY5gXBkmELEEb9V/gCtg1O4qdSPUtRNLsSVpa1XyVuf pRPlnQ54gQMg+D9srQo2zp0tdHBylmO5eE1dxzoZCi6JNCAOP50CLc/AhWR2NDJXkbLeDMPL8Po DeDNGrQU9pOhAmbhWZ2dYdi1gpHamRo9xKFFM6deuAfS8wx7fWexCyIpsf/5mqoj/o1Lk1GR+oU nw4gB6QUNhD3Nyu4CrqX9uywSsRa5MkHCwWm7u+uaH5sMA+i3dr6DPz4N/BJjhClz9He2 X-Google-Smtp-Source: AGHT+IEF0jPgjk5pMLgQgzgGB1wBN6wdYeGgnR7YGofvOzo1L979/MDO00s/nu8nuyKWrSlhg1kCRQ== X-Received: by 2002:a05:600c:1c1d:b0:45b:9322:43fc with SMTP id 5b1f17b1804b1-45c1f25b266mr8091355e9.29.1756831253606; Tue, 02 Sep 2025 09:40:53 -0700 (PDT) Message-ID: <1afdc536-6583-42d2-807b-41ffa241893c@citrix.com> Date: Tue, 2 Sep 2025 17:40:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] releases: use newer compression methods for tarballs From: Andrew Cooper 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 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/09/2025 5:15 pm, Andrew Cooper wrote: > On 25/08/2025 2:54 pm, Jan Beulich wrote: >> Other projects have long switched to xz and/or lzip. >> >> Tidy things some as well: With the removal of qemu from the tarball, >> intermediately extracting the tarball again has become wasteful. Drop >> that. Invoke compressors using asynchronous lists, to reduce overall >> latency. Drop the -v option from the (previously implicit) gzip >> invocation. >> >> Signed-off-by: Jan Beulich >> --- >> v2: Don't expand intermediate uncompressed tarball. Don't check for >> commands' availablity. Don't request statistics. Use async lists. >> >> --- a/docs/process/release-technician-checklist.txt >> +++ b/docs/process/release-technician-checklist.txt >> @@ -119,7 +119,7 @@ RELEASE TARBALL >> make src-tarball # uses git-describe (best for RCs) >> # ^find some way to add git-cache-proxy to this (done in ~iwj/.gitconfig) >> mkdir /volatile/iwj/website-thing/xen.org/oss-xen/release/$v >> - mv dist/xen-$v.tar.gz /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/. >> + mv dist/xen-$v.tar.[glx]z /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/. >> >> # website-thing/xen.org is cvs -d mail.xenproject.org:/home/downloads-cvs/cvs-repos co xen.org >> cd /volatile/iwj/website-thing/xen.org >> @@ -139,9 +139,12 @@ RELEASE TARBALL >> cvs add -kb oss-xen/release/$v/ >> >> cd oss-xen/release/$v >> - gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' xen-$v.tar.gz >> - cvs add -kb xen-$v.tar.gz >> - cvs add -kb xen-$v.tar.gz.sig >> + for t in xen-$v.tar.[glx]z >> + do >> + gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' $t >> + cvs add -kb $t >> + cvs add -kb $t.sig >> + done >> cd ../../.. >> >> cvs ci -m $v >> @@ -152,6 +155,10 @@ RELEASE TARBALL >> # should show something like >> # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz >> # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz.sig >> + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.lz >> + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.lz.sig >> + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.xz >> + # U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.xz.sig >> >> After a .0 release, update XEN_EXTRAVERSION again (to .1-pre, see above). >> >> --- a/docs/process/xen-release-management.pandoc >> +++ b/docs/process/xen-release-management.pandoc >> @@ -274,10 +274,10 @@ Xen X.Y rcZ is tagged. You can check tha >> https://xenbits.xen.org/git-http/xen.git X.Y.0-rcZ >> >> For your convenience there is also a tarball at: >> -https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz >> +https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.[glx]z >> >> And the signature is at: >> -https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz.sig >> +https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.[glx]z.sig >> >> Please send bug reports and test reports to xen-devel@lists.xenproject.org. >> When sending bug reports, please CC relevant maintainers and me >> --- a/tools/misc/mktarball >> +++ b/tools/misc/mktarball >> @@ -5,14 +5,6 @@ >> # Takes 2 arguments, the path to the dist directory and the version >> set -ex >> >> -function git_archive_into { >> - mkdir -p "$2" >> - >> - git --git-dir="$1"/.git \ >> - archive --format=tar HEAD | \ >> - tar Cxf "$2" - >> -} >> - >> if [[ -z "$1" || -z "$2" ]] ; then >> echo "usage: $0 path-to-XEN_ROOT xen-version" >> exit 1 >> @@ -21,14 +13,20 @@ fi >> xen_root="$1" >> desc="$2" >> >> -tdir="$xen_root/dist/tmp.src-tarball" >> +tdir="$xen_root/dist" >> >> -rm -rf $tdir >> +rm -f $tdir/xen-$desc.tar.[glx]z > This is asymmetric with the rm at the end.  I'd remove > $tdir/xen-$desc.tar* here and remove the final rm. > > Looking at the uncompressed tarball is part of my process, and it was > preserved previously. > > With something along these lines, Reviewed-by: Andrew Cooper > > >> >> mkdir -p $tdir >> >> -git_archive_into $xen_root $tdir/xen-$desc >> +git --git-dir="$xen_root/.git" archive --format=tar HEAD --prefix=xen-$desc/ \ >> + >"$tdir/xen-$desc.tar" >> + >> +gzip -9k "$tdir/xen-$desc.tar" & >> +xz -9k "$tdir/xen-$desc.tar" & >> +lzip -9k "$tdir/xen-$desc.tar" & >> +wait > Interestingly, this wasn't fatal for not having lzip, but the error was > clear on the console given the reduced verbosity, and doing 3 at the > same time worked very nicely. > >> >> -GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc >> +rm -f $tdir/xen-$desc.tar >> >> -echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz" >> +echo "Source tarball in" $tdir/xen-$desc.tar.[glx]z > This was grammatically awkward to begin with, but is now pretty useless, > especially combined with the set -x so it gets printed twice. > > Something like this: > > echo "Source tarballs:" > ls -lah $tdir/xen-$desc.tar* > > generates: > > -rw-rw-r-- 1 andrew andrew  32M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar > -rw-rw-r-- 1 andrew andrew 6.8M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.gz > -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.lz > -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.xz > > > on my system and is rather more useful IMO. And just for reference, here is what zstd looks like: -rw-rw-r-- 1 andrew andrew  32M Sep  2 17:24 /home/andrew/xen.git/dist/xen-4.21-unstable.tar -rw-rw-r-- 1 andrew andrew 6.8M Sep  2 17:24 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.gz -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:24 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.lz -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:24 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.xz -rw-rw-r-- 1 andrew andrew 4.9M Sep  2 17:24 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.zst using -19kq  (zstd defaults to giving an interactive progress bar, and needs quietening). With a bit of `time` hacking, gzip is 2.4s, zx is 11.8s, zstd is 13s and lzip is 17.3s on my system. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:42:48 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:42:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107098.1457636 (Exim 4.92) (envelope-from ) id 1utU5o-0008OX-0Q; Tue, 02 Sep 2025 16:42:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107098.1457636; Tue, 02 Sep 2025 16:42: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 1utU5n-0008OQ-T3; Tue, 02 Sep 2025 16:42:47 +0000 Received: by outflank-mailman (input) for mailman id 1107098; Tue, 02 Sep 2025 16:42:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utU5l-0008OC-S4 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:42:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utU5l-002yie-0C; Tue, 02 Sep 2025 16:42:45 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utU5l-00DHrD-06; Tue, 02 Sep 2025 16: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=UIHGFTGttUFMFzgNU+ihyk8d0IGpgeTFlFTVEjVBREY=; b=OuoW9d5RjYv7LmEobi056jAoyU UH4XX3WObvcYMPY+xbpTdFkiuNHVQXON5HmgjtTMCyrt8eHJUHpDHItQ1LPjlPuJ9uewHZDW7v1UD FGQUohD4Pn7Ij8oHMUSKTrzuLlW7QtOphBvpMUZHW6CMnzFYJFZdFZxK5DcBkX+fzj3I=; Message-ID: <5ab75c0a-0bf6-418a-8c8f-7411a46d4189@xen.org> Date: Tue, 2 Sep 2025 17:42:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 09/12] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Oleksandr Tyshchenko References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Leonid, On 29/08/2025 17:06, Leonid Komarianskyi wrote: > The Dom0 and DomUs logic for the dom0less configuration in create_dom0() and > arch_create_domUs() has been updated to account for extended SPIs when > supported by the hardware and enabled with CONFIG_GICV3_ESPI. Style: We don't commonly use past tense to describe the new behavior. > xen/arch/arm/dom0less-build.c | 2 +- > xen/arch/arm/domain_build.c | 2 +- > xen/arch/arm/include/asm/vgic.h | 19 +++++++++++++++++++ > 3 files changed, 21 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 69b9ea22ce..02d5559102 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -285,7 +285,7 @@ void __init arch_create_domUs(struct dt_device_node *node, > { > int vpl011_virq = GUEST_VPL011_SPI; > > - d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS; > + d_cfg->arch.nr_spis = vgic_def_nr_spis(); > > /* > * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index d91a71acfd..39eea0be00 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -2054,7 +2054,7 @@ void __init create_dom0(void) > > /* The vGIC for DOM0 is exactly emulating the hardware GIC */ > dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > - dom0_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS; > + dom0_cfg.arch.nr_spis = vgic_def_nr_spis(); > dom0_cfg.arch.tee_type = tee_get_type(); > dom0_cfg.max_vcpus = dom0_max_vcpus(); > > diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h > index 912d5b7694..3aa22114ba 100644 > --- a/xen/arch/arm/include/asm/vgic.h > +++ b/xen/arch/arm/include/asm/vgic.h > @@ -347,6 +347,25 @@ extern void vgic_check_inflight_irqs_pending(struct vcpu *v, > /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */ > #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)> > +static inline unsigned int vgic_def_nr_spis(void) > +{ > +#ifdef CONFIG_GICV3_ESPI > + /* > + * Check if the hardware supports extended SPIs (even if the appropriate > + * config is set). If not, the common SPI range will be used. Otherwise > + * return the maximum eSPI INTID, supported by HW GIC, subtracted by 32. > + * For Dom0 and started at boot time DomUs we will add back this value > + * during VGIC initialization. This ensures consistent handling for Dom0 > + * and other domains. For the regular SPI range interrupts in this case, > + * the maximum value of VGIC_DEF_NR_SPIS will be used. > + */ > + if ( gic_number_espis() > 0 ) > + return ESPI_BASE_INTID + min(gic_number_espis(), 1024U) - 32; > +#endif > + > + return VGIC_DEF_NR_SPIS; This is the only user of VGIC_DEF_NR_SPIS. Therefore, I would prefer if we remove the define. This will avoid any confusion between the helper and the define. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:49:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:49:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107111.1457647 (Exim 4.92) (envelope-from ) id 1utUCM-0000Yg-EH; Tue, 02 Sep 2025 16:49:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107111.1457647; Tue, 02 Sep 2025 16:49:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utUCM-0000YZ-BX; Tue, 02 Sep 2025 16:49:34 +0000 Received: by outflank-mailman (input) for mailman id 1107111; Tue, 02 Sep 2025 16:49: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 1utUCK-0000YT-Hv for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:49:32 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cb85af78-881c-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 18:49:30 +0200 (CEST) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-45b88bff3ebso17693065e9.3 for ; Tue, 02 Sep 2025 09:49:30 -0700 (PDT) Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b814da51esm182460925e9.8.2025.09.02.09.49.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 09:49: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: cb85af78-881c-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756831770; x=1757436570; 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=MJ40ZRWGK1gb/0Ib0mzYXkq8QZP/wltgmRDQm7vwZMU=; b=LhA80NQ+6y9Aud6nFJ2at6SMaO//H/3WCviqCU5O5KyeCYLoKBhN+pCxeOs8Npp6KP 3zFu9cfpGylk6nInytcursKIHOEAsdDgi7jqoZlJjHxhv/wHKQzK9c+LINS2ibP9bbHs 2PTm5hzGLoS7cja98TUSjcN3csqUa+gObeeOzz/VuvoknLuFvHw6BKgWO/+V6Z1P36dA zxSFMYRav76GUyPz0j+OEiA458jsmSzhSuUB0yIKg1m2ZlC806vVWSqa+WQnGKoH5Ssd p2BpQjLWl9ndkOqgRgMAgDpMq6Pta4UViBiW/qiGkjKovJatoRvDnW6N4/hjLnSr9Tzu x5WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756831770; x=1757436570; 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=MJ40ZRWGK1gb/0Ib0mzYXkq8QZP/wltgmRDQm7vwZMU=; b=NH0wGNPXdh73loa0dDlwOQxMAJVA/6nW7RefN829pmdOpnJKROVG/Jg2gW6s08sG0p Wrw83K+UjuRil7vRFQinX/AP11OZr4S80bv9qh7vZbjBKm9vjxcSO1EaJEOkUxU2r/oZ D8BFBb6ZQnY/rjBLHfHeCov9EgnbPLVZ21Zet+QavDzLPbYTBlUpfN+2xvwY5ciqaiFS qCvTzNET6GkJ3jJO5VDmnnwrh9tNM8J7NcF5jW3W9PFnzICki0dltqmWHWh5UFDlxMWY fOKKv944KIsA2pnHMVq9uiLcmwk595hNMGyw7krpQ8NW/xBSrIPNqSDTl4B/JZ/cu3CO D3pA== X-Forwarded-Encrypted: i=1; AJvYcCXjjt6mYHCxq1poUzBx3JBHdtDznCmM/2sf22jBTNtoDGW3U8cUJExKR49C8aSIR3X4OQFwocP6Hs0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy8c88n0vITiQR9b0pfAQ8rNpuQ8AZtt9ljMC/XHvR+pbZrGspY Iy8n4jhmgr/9qWgd5GWstGXiAKq9wdSp9FKXd9sinYfEQW7tC+b4Lc1v X-Gm-Gg: ASbGncvVLhuyrjZdWJgEuhqksJVz/2hJh91FtM5q4c2ZbKQ41swS5bVy5A53QMr3DZR h6ferPAVhN0IPIAYob+yApzaUG57pVPwfHMRPyakxHZ8AVQG+xHJ3c0fgGAmo3FvRn8hdn7IiiC 4nqaaVo6lWqhfLh0tjB8z0pILcw6qfikR/DCBYpY7PqRKvDMLqGbB8d+J+rPXmQ4A1YzCKtbFOg ARBlzi8JEUocxXXw87geWQfFh4s/KLAY0wZSAafaSM+BsjsvBCdo8z1X6tEHot/51UoEuQDAmbr 40iYfWnq8j/3krXA8Ydv4x4r5d3iuukkTmjYLGR6bKuXVrWbQa9LA491p/wLUeKfTB3xqDXAieo XooxQIeVm4G6aUUHw3gp0PWhBZ/ZiTkgYkkIDpqCvQxLksNSC7j2U4YMpF6FHnIAXMw== X-Google-Smtp-Source: AGHT+IGxfW4y5GwVfokZdpipEi5/pu1pDbC7Rb5WS652P7zfnqSxmqzsCGKijwM4sSJi+me3SvRHRg== X-Received: by 2002:a05:600c:3ba8:b0:445:1984:247d with SMTP id 5b1f17b1804b1-45b8552853amr105216085e9.7.1756831769436; Tue, 02 Sep 2025 09:49:29 -0700 (PDT) Message-ID: <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> Date: Tue, 2 Sep 2025 19:49:27 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.09.25 01:10, Mykola Kvach wrote: Hello Mykola > 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 > --- > Changes in V6: > - Call handler->disable() instead of just setting the _IRQ_DISABLED flag > - Move the system state check outside of restore_local_irqs_on_resume() > --- > xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) > > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 6c899347ca..ddd2940554 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -116,6 +116,41 @@ 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; NIT: Please, use "unsigned int" if irq cannot be negative > + > + 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; > + } > + > + /* Disable the IRQ to avoid assertions in the following calls */ > + desc->handler->disable(desc); > + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); Shouldn't we use GIC_PRI_IPI for SGIs? > + 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) > { > @@ -134,6 +169,10 @@ 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: > + if ( system_state == SYS_STATE_resume ) > + restore_local_irqs_on_resume(); > + break; May I please ask, why all this new code (i.e. restore_local_irqs_on_resume()) is not covered by #ifdef CONFIG_SYSTEM_SUSPEND? > } > > return notifier_from_errno(rc); From xen-devel-bounces@lists.xenproject.org Tue Sep 02 16:55:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 16:55:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107122.1457657 (Exim 4.92) (envelope-from ) id 1utUIS-0002Jn-2l; Tue, 02 Sep 2025 16:55:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107122.1457657; Tue, 02 Sep 2025 16: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 1utUIR-0002Jg-VN; Tue, 02 Sep 2025 16:55:51 +0000 Received: by outflank-mailman (input) for mailman id 1107122; Tue, 02 Sep 2025 16:55:51 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utUIR-0002Ja-KK for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 16:55:51 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utUIQ-002z0Z-2f; Tue, 02 Sep 2025 16:55:51 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utUIQ-00DOIr-2e; Tue, 02 Sep 2025 16:55: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=Da+spqadYJRWZTS0JzTI0TvZ8uyZirH1vlrWSybvfqc=; b=lOiyapAJE95XcZlqyMIvmWdZBb TixrRAMlvjdVJ9wkg3vndhckY+cRd3gWi+rXemXNiJcfTcoTUvw6FKzSq9TH/HqawHkkcfOPBSMLW TeIr7deOUvEk7NYEOHgoFPBXhDchg+r2XxLdExrUZzS1xhaTQuLQeE6pnexzfxhrrij8=; Message-ID: <06ff285f-39d5-4ffd-b842-6d776bb793ac@xen.org> Date: Tue, 2 Sep 2025 17:55:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> From: Julien Grall In-Reply-To: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Leonid, On 29/08/2025 17:06, Leonid Komarianskyi wrote: > @@ -782,46 +804,81 @@ static int __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v, > { > case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN): > case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN): > + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN): > + case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN): > /* We do not implement security extensions for guests, write ignore */ > goto write_ignore_32; > > case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN): > + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN): > if ( dabt.size != DABT_WORD ) goto bad_width; > - rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); > + if ( reg >= GICD_ISENABLERnE ) > + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE, > + DABT_WORD); > + else > + rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); While I understand the desire to try to avoid code duplication. I feel this is making the code a lot more complicating and in fact riskier because... > if ( rank == NULL ) goto write_ignore; > vgic_lock_rank(v, rank, flags); > tr = rank->ienable; > vreg_reg32_setbits(&rank->ienable, r, info); > - vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); > + if ( reg >= GICD_ISENABLERnE ) > + vgic_enable_irqs(v, (rank->ienable) & (~tr), > + EXT_RANK_IDX2NUM(rank->index)); > + else > + vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); ... you now have to keep both "if" the same. Unless we can have a version to avoid "ifs" everywhere (maybe using macros), I would rather create a separate funciton to handle eSPIs. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:06:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:06:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107136.1457667 (Exim 4.92) (envelope-from ) id 1utUSl-0004Am-WC; Tue, 02 Sep 2025 17:06:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107136.1457667; Tue, 02 Sep 2025 17:06:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utUSl-0004Af-Sx; Tue, 02 Sep 2025 17:06:31 +0000 Received: by outflank-mailman (input) for mailman id 1107136; Tue, 02 Sep 2025 17:06: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 1utUSl-00049G-2W for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:06:31 +0000 Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c202::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2b31d918-881f-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 19:06:30 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by PAWPR03MB9154.eurprd03.prod.outlook.com (2603:10a6:102:33f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.16; Tue, 2 Sep 2025 17:06:26 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 17:06: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: 2b31d918-881f-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QchOGZc/kdJCrmimdS3flJ8osyccZPq0C36E8oY74Jv7qOaTKTctR1No2Qv6v+j3cAYhGQj/L8rTbvqpNJ2kWvo5JxJNtZ4BXFq/+OCVkJGi4x8ze8eqg4bD3aJlBVc+lvgR2LMtxSX/vJSCEmBZfJC2QqqWe9srNjgmXk54TieFqta42wBRt4EXUo8H9j/AHph5+yPoTYqjF6B2wc56DoVTI6JhtSJeYfgx22exLzXh4NRZQPJp29qSfYR2IKiYz1TePHaundRkPN7haMaaDQt+Rn0WDuli9QxzJvU1uv2BeM6YUbDcPAzCO/BvlCEjjQivelUrkyolK9jPem+ZGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jIp0ZermkvYdId4d+XAtfCKgp2r+e2osQHFdaiDPTJA=; b=cvXBrNW8Hg9slBdlc4CMdBUfDS0bl2pNvzFLUBBk91uXXvGgS2qYgJp171bLShnnuUA08uvStYeazR+ZmhZMN0/Bgr4hkPi97ogN1GyhuoNSX5PCnvIGqIEJbQI7hh9120JQI7zQRq5gox3MhkF3cFHMUQeFqUIsezLsUlARuqosTwHTmQnUM7sX5CV0EJtF8/pl0BnmkMuidnCa2WWsqvUxpltA5Ps4Z7KK9aicQM8ZO5YM2xIII+xOXZUc3yEViSmqouBWl/qT4nZkRTCts9cNwrafBeOqClNmJ+yjQoP+6+yUjRGLaQ00MRsnncnt3fIFY3R3hxFPuBxM4rzwww== 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=jIp0ZermkvYdId4d+XAtfCKgp2r+e2osQHFdaiDPTJA=; b=dSCdUJMowbxjJBSdS6pl78MwVhqLf2pHgHsg+ZKwFlyos+hFzc9lMijDkSLkG6crljL1xDOr1PCJYUbf2vsmMf60doxaAbA6HCBHfW2jQWUDzGiHFA3qjnTwK3ztMBEYadYlynuFPGbY3iFIyxcNNl5tKlyKf+AJ8MVjFueelv2U+Twfos8/H+7h4E/iKMGklVUtRgLsmTZbmVPHb4ly/3KaU23F1r2oXwAzwV4w/I3xW/Hbor7TK+fHYrTpVb1I3iJ7Epwz4F/TeG4CDJ/Kz47I7gxG8iFrXTSXl5rpF1TdfOj981by+YZlNznnMOwlqxud3jBimfdDlOCYlyFrgw== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing Thread-Topic: [PATCH v5 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing Thread-Index: AQHcGP7fr2aNz8WgzkeaOcGbW6a0ZbR/78+AgAA2BgA= Date: Tue, 2 Sep 2025 17:06:25 +0000 Message-ID: <6d1492bc-195d-4b74-85ca-82b5565dba1f@epam.com> References: <34b86693e1031a3ec786a38a0510f047c6c708da.1756481577.git.leonid_komarianskyi@epam.com> <862df090-cbe2-44e9-8c7a-733f3bfd46ad@xen.org> In-Reply-To: <862df090-cbe2-44e9-8c7a-733f3bfd46ad@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: GV2PR03MB8678:EE_|PAWPR03MB9154:EE_ x-ms-office365-filtering-correlation-id: d4577c3f-ec50-44b8-5e20-08ddea430ca6 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?ZUNoUzZzYW1lWWRScWJBcDk0RDNDMGN0aU9lQkpXU0J6aTJKd1E2SmZTOGNV?= =?utf-8?B?WTFxenRJcEU5cTN4QUd6cTRUMnpYQis1YzAyUUdsZitCUVdNL3JPT1I0TnA5?= =?utf-8?B?KzNFTGtQbjB3RTFCbUhuVmZZUUd3azdhb1NRUzA5QmxjRExsWkI0TkVHU2Q3?= =?utf-8?B?MXg0Zk1pbitvK0dQWE4vWGJwNG12ditCQjhYOEpZYUJxbmpsK20vOWpYdlRl?= =?utf-8?B?U09CemM4Q3pMejMzTHBaNXlkZkdxVGwxZkFkTW1VMi94bldaRnFnRC9SVzNm?= =?utf-8?B?T3cyVC95dWdsM2xwM01DdDZGRGU2MTBKMENPMm5XbXcxMnVOME9EMDNhVEtC?= =?utf-8?B?Unc4SW1XS0U2SDlkdlEvNlVnbkMxRmkwRmRyNzdhMStVTDI0MS8zS2t2NENw?= =?utf-8?B?bjhNQjh6NnQwM2NVOTVyWXFQSmFqWTlvVVkrWlRRZTFPY0FIWlNnWkJxVU5Y?= =?utf-8?B?enVEeHRvRGJwQkd0VVhtaklzbXRBR0lIVlk2WlBqdC9WQi9LODZ3R0pwUmRv?= =?utf-8?B?OTFKUU83ZjNTSjQzVHBsVjBOL1UrVGI1UmhZRk9EM3kwalpqTks0dXdxdTE0?= =?utf-8?B?YkVPNG9HUnFkVlQzNlNVNFNsa1d0c1BpaGNhZjc3bDUxL2VhZTFLOFJMWmFR?= =?utf-8?B?YStOL0grTzMyTy9wcXd0cm9WOXJLbVhIb0JkaCswR0J4TnQ2ejFUZ0RVRVE5?= =?utf-8?B?NFlIVHF5N1YzSWJ3Tnhxb3ZSOW1QcDdOMnRyWWxHVkN1K2YwSDBqdkRTK25o?= =?utf-8?B?M1VmQjdieWcyaTBZaXhmVHlQUGFBaEFwbzg3Q2dtYXlCeW55T05CQXBFOEJG?= =?utf-8?B?MnF0RmFOZXhKTWUyeG5BaWNoeVFIa0Z3b3BEeFlCbVVlVU10Qlo3dFRsNTA0?= =?utf-8?B?T0FDZm95TnF3NERnMVQxM0hLdStyRVV2V0pjaFN5UUFCeDNsYVJzdjllYXIz?= =?utf-8?B?bG1TamVhSUJsMEJNN3dkYURocVVaRmdZUEFPRDczdEpyKzdHd283QUp4RGVz?= =?utf-8?B?Rnkyc1c0R2cxQXFoYWkwTVg4RzRxSjlKNDQ5bUYyRzMyU3dSMVR1bFgyUkwr?= =?utf-8?B?bnFkWnE0YWRxNTM4UEh5UmpoekxlVDZtRGNhMDRsdktJeXRDUXJCWTZRR29m?= =?utf-8?B?eUFuRytYUXAwQThUUmdCRHNNVlVwR3Z5UmdueTZkSWkrM3o0TFExcWtHYVQz?= =?utf-8?B?bVFGeXplVkJNY1Fjc0ZoTEE3MzY2Mm9JMnI0WmoySHc2dnBmWnBTQjNFWFZz?= =?utf-8?B?T1hkclBoOHNtRmMzdXdCVTMxY2N1WVI3YTI5c3lCNmJ1Y2JFeDBPRnFzaXZD?= =?utf-8?B?Vm1rRUpmMVlld2tGeFEzUHp5eTh1SVRsK0doaXU4NnZaZjNTRXYvNEROV0dS?= =?utf-8?B?czlHV241R2YrYURoTkhKdVpXalF2SFZMcXFZZlZRcDZtaGw2c21mbWhDejN2?= =?utf-8?B?ZE9UUmk0eG15NS9kbnlDQVRxTTVqcld4SHFxZlZiejdLSW5MWHMwS1JySnBj?= =?utf-8?B?STFrTUZkZVNJd2EyWS83cUtDUGVwUDMwbzlrdTlWbmdJcHBkM1lxeldhRTR1?= =?utf-8?B?aE51d1lsUmFTMjREU0tkUVRRQ09TR0VDWWNEVkQ2VmwzU1E2MFdSK0srMW9U?= =?utf-8?B?TTJ0eUEvYTlCTXFndE9jWExFeTBPc1U3Y1NKVE1SeHFucERMTmRmT2d2NnVH?= =?utf-8?B?Y0ttTk1pNUo2YTZ1bDlWT0NnSjBPdGg0Y3ZhekxaYm14bGpkbGhGZWZvTXFN?= =?utf-8?B?R25QREJReE1QNmkrN3ZhVDE5RnpkRGtEQ3VrUXZnZHhtMS9NTytVaDlLNm0w?= =?utf-8?B?QkdzSTQ5Yit1anJFSHhKaE1OeThqamcyU1VrdzBUdzdKS1JjRFdJNm5acWIx?= =?utf-8?B?cWhLdENCUEFLVzU4WHZ5cjZvZ0czOG5OTzZTOWJreEp1NU9oQlJoOU1pVWtR?= =?utf-8?B?VVFReUZHY0VjWVNNSmpCZVBpSXIzU3dpOFBWZ1FhRXoyRWVVU1NNdi9iWndC?= =?utf-8?B?TFhIajFkZlBBPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UWtZRE0vVjBIOEU5Wkh6S215NjRTSW9LMUtsbEdCK3l3Uk5QZnhkeDAxVk1S?= =?utf-8?B?dkM5YzZ6M3dEZ1oydEVWNXJSY3JVQi9FVHFKUkkrV0lsektGdG04bmxaNjFw?= =?utf-8?B?ZTZ3Vk5ya2hGNGtSRnRDdUMyWDVzRTRwd3FHejVweVZFVUFROTJEdEtxb05P?= =?utf-8?B?ODFkbUoyS1F4Qnc5MkIwUzE5ZHV5cmxtSlg0YjRCYjl2NUpJZnNzSHV2aEN5?= =?utf-8?B?WmQwUnVkbU5MaS9PbzFxMHpZSWFmVS9RQUN3RWExaU9oeFFkUFZ4WWtwQVJG?= =?utf-8?B?WDNRZWxCYi9SbTQ0RWhtMXIwOUhZdUJBNjRJRFdxRDFYVEhQZENGMzMxWU5q?= =?utf-8?B?WWhZcEwwMG1uOHU4K2pkOXZrTWNSR0pIU0prMnNGV1FLc3Y3eWtlZ1FnZ1h4?= =?utf-8?B?Z2cwUVQ5M3pCck1IbjZ2T0krSHJqQXR1K1FwbS9jeVNHLzM2LzJtVDBJb1pM?= =?utf-8?B?UFFLeVZuTVdYZFp4c2pOTGZ0SkFKTk1qS1lCMlRRWnpQZmgwaGhIUVpSRStF?= =?utf-8?B?MHdRT2xBbVl6WXlONlN2VHRWZlg5UmRlaE95RlhBckN1UjE4U2FNVTJVSEQz?= =?utf-8?B?OUlpMUlnSU5KSXF3UURScXdhUy81cDFydzlleVFndzVRN1grTjcxZUoxK2Ro?= =?utf-8?B?SndKVnlmRi9HUDlsN28rK3U5VEtwZFdJekx4M1JaSVlOY3N1ajl6TjkrM1FB?= =?utf-8?B?SU11c3FvN2NCemdzZDJrdlhWZkt0M2xtNUVrN0djSWlVOWwxTXl4SXVqSGp2?= =?utf-8?B?VitrRmU1ZkgybklDNHpsQTJvTkZ1ZmdMckVSU3U5dUUrTVY2N2E1SFNGRzNO?= =?utf-8?B?MmFvcUhTRktadGpnQ1NjYlVMdEdOOWd4alM5OVpGMU1JWE1qdGY3Y3Q1aFBn?= =?utf-8?B?aUNoaFFwV3JYVE9vOWE3bG1iZjlQV08yOVZhWVdrQ2NYckliM0xIOGlVV3RX?= =?utf-8?B?QmV0aHowN0oybjNPeXNYamM5SGtmaStGWENXN1FmSzh6elU0bG1SeWE2TFVC?= =?utf-8?B?dG1lSngxVGRYVUNQNDZaTGc5OGEwN2pzejVJUFhCQytQNFQvemtacUxzc0FP?= =?utf-8?B?Q05LZnBuYnJqSlI5aEM2c1MralVkZTBIWnU4bDJyQjVtcEM3R3JwelBjTzNh?= =?utf-8?B?N1NBWDdSaGJrZmJlaW9TczVDSndxeFFWZHdTbjFIL2h6eG9HL0pueWF5Zm5z?= =?utf-8?B?YWUxRWpzam1zaEVFSnZZVno2WjhnMXpKS3dWMjRVZDJCa1RUS2FQYitmUDV1?= =?utf-8?B?Y3dNRlIvUFlXVW13Mjd6QVRTd1Flczg2ZisycVA3ZGY3dzZySVVjdW5DdTZo?= =?utf-8?B?YWR1c29MMVlqNXVod1FCLzJlcnBBTWhDUjM0R2U0dHRIQ0U3NUwydUszYkFY?= =?utf-8?B?VlRZMmpWa1lRbTJIYW1BTlM4NGtFYTBUeVhXbFVkanV4aFZTMWsvZzVTUVVN?= =?utf-8?B?N01yY2lBa3Zlc3B0ZFhBWGxtb2c2bjdnQkc1bHZmdkNUc0pTQm5ZQW5BUU5i?= =?utf-8?B?ZHpkYVgrZkRqQmUzSjVsMUJyRnN1SVJIblZPcjZhSDhML1doVlVyRkhxQ01M?= =?utf-8?B?WTNCU0ZqNUk4RGtOR0haMTc0YTZ4YnhLWVFjZzdoL29xUGJUOWxGZ1pFcWhI?= =?utf-8?B?L1JGK05yb3kzR1Y4VStNQy9VWEtOU2ovVkthbGtSY2RwSTIrVGZaT0V1MGRv?= =?utf-8?B?YmVvZUl0K2lhWnBJRENvcUVSNCtXejMxcTg1OXhLTWl5eDBWSWhaVko0MTJj?= =?utf-8?B?SjE2RkJmOWE5dmZyZVZ2UGx1OCtkOXhlUEpYOUlBdDN2N2FpL1JiVE9wcnR1?= =?utf-8?B?eVo3S0lrdGNEM0VmUUg4bWhzNTVPSTh0elQzQXpvZ1JQZUVPb1BBTDE4QXQz?= =?utf-8?B?eWt5MmoxQUVKc1luOTR5RDlaMUducjlSUmw3VFRiUmM3aktoKzFua24vM0k5?= =?utf-8?B?Zkg0YlE1MWhHajNlT2J4eUF0c3RuUzRLbnVZc1BNaHBIc013eFFEUzQzVlVl?= =?utf-8?B?cDE5NWhRMUxocmFhTVorMldZVEg5TVRkVmkrN2UwRlBZV3RDL0RwSjg4VEpp?= =?utf-8?B?bUQ4b2R0YkJWSDNhK1piRm5LMWoxZldCczFsTS85Mjk5MWcvNndNMnp3UlZQ?= =?utf-8?B?TzRHWng1S1N4RUJiQnFyc0d4bk9sZysvUU1pTkdRd2M4N1NjZUtyMnB3VWxJ?= =?utf-8?Q?LY6EFvUXtK4f0EJQ8JpCSUY=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <70AC2874CEF83148AA73E508633C44BC@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d4577c3f-ec50-44b8-5e20-08ddea430ca6 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 17:06:25.2298 (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: 3+RHf+8vOyFfjA/Gb63+SJHTN2Eg7919Xj3jZ6WmsizUdQimiReJDW0NQ6hN/n8MkQKqEX4oTaqZ0A4zJTFgvrflRxLxR/A7yFl6qXvmXcI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9154 SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAwMi4wOS4yNSAx Njo1MywgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBIaSwNCj4gDQo+IE9uIDI5LzA4LzIwMjUgMTc6 MDYsIExlb25pZCBLb21hcmlhbnNreWkgd3JvdGU6DQo+PiBUbyBwcm9wZXJseSBkZWFjdGl2YXRl IGd1ZXN0IGludGVycnVwdHMgYW5kIGFsbG93IHRoZW0gdG8gYmUgcmV0cmlnZ2VyZWQNCj4+IGFm dGVyIHRoZSBpbml0aWFsIHRyaWdnZXIsIHRoZSBMUiBuZWVkcyB0byBiZSB1cGRhdGVkLiBUaGUg Y3VycmVudA0KPiANCj4gV2h5IGd1ZXN0IHNwZWNpZmljYWxseT8gSXNuJ3QgdGhlIHByb2JsZW0g dGhlIHNhbWUgaWYgYSBwaHlzaWNhbCBlU1BJIGlzIA0KPiByb3V0ZWQgdG8gZG9tMD8gSU9XLCBz aG91bGRuJ3QgdGhlIGV4cGxhaW5hdGlvbiBiZToNCj4gDQo+ICJUbyBwcm9wZXJseSBkZWFjdGl2 YXRlIHBoeXNpY2FsIGVTUEkgcm91dGVkIHRvIGEgZG9tYWluIGFuZCAuLi4iDQo+DQoNCkkgd2ls bCB1cGRhdGUgdGhlIGNvbW1pdCBpbiBWNi4NCg0KPj4gaW1wbGVtZW50YXRpb24gaWdub3JlcyBp bnRlcnJ1cHRzIG91dHNpZGUgdGhlIHJhbmdlIHNwZWNpZmllZCBieSB0aGUgbWFzaw0KPj4gMHgz RkYsIHdoaWNoIG9ubHkgY292ZXJzIElSUSBudW1iZXJzIHVwIHRvIDEwMjMuIFRvIGVuYWJsZSBw cm9jZXNzaW5nIG9mDQo+PiBlU1BJIGludGVycnVwdHMsIHRoaXMgcGF0Y2ggdXBkYXRlcyB0aGUg bWFzayB0byAweDEzRkYuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogTGVvbmlkIEtvbWFyaWFuc2t5 aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4NCj4+IFJldmlld2VkLWJ5OiBWb2xvZHlt eXIgQmFiY2h1ayA8dm9sb2R5bXlyX2JhYmNodWtAZXBhbS5jb20+DQo+Pg0KPj4gLS0tDQo+PiBD aGFuZ2VzIGluIFY1Og0KPj4gLSBubyBjaGFuZ2VzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWNDoNCj4+ IC0gYWRkZWQgcmV2aWV3ZWQtYnkgZnJvbSBWb2xvZHlteXIgQmFiY2h1aw0KPj4NCj4+IENoYW5n ZXMgaW4gVjM6DQo+PiAtIG5vIGNoYW5nZXMNCj4+DQo+PiBDaGFuZ2VzIGluIFYyOg0KPj4gLSBy ZW1vdmUgdW5uZWNlc3NhcnkgQ09ORklHX0dJQ1YzX0VTUEkgaWZkZWYgZ3VhcmQNCj4+IC0tLQ0K Pj4gwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpY192M19kZWZzLmggfCAyICstDQo+PiDC oCAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkNCj4+DQo+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpY192M19kZWZzLmggYi94ZW4v YXJjaC9hcm0vIA0KPj4gaW5jbHVkZS9hc20vZ2ljX3YzX2RlZnMuaA0KPj4gaW5kZXggMzM3MGI0 Y2Q1Mi4uZTcwYzFhNTY3NSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2Fz bS9naWNfdjNfZGVmcy5oDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3Yz X2RlZnMuaA0KPj4gQEAgLTIxMSw3ICsyMTEsNyBAQA0KPj4gwqAgI2RlZmluZSBJQ0hfTFJfVklS VFVBTF9TSElGVMKgwqDCoMKgwqDCoMKgwqAgMA0KPj4gwqAgI2RlZmluZSBJQ0hfTFJfQ1BVSURf TUFTS8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMHg3DQo+PiDCoCAjZGVmaW5lIElDSF9MUl9DUFVJ RF9TSElGVMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEwDQo+PiAtI2RlZmluZSBJQ0hfTFJfUEhZU0lD QUxfTUFTS8KgwqDCoMKgwqDCoMKgwqAgMHgzZmYNCj4+ICsjZGVmaW5lIElDSF9MUl9QSFlTSUNB TF9NQVNLwqDCoMKgwqDCoMKgwqDCoCAweDEzZmYNCj4gDQo+IEl0IHRvb2sgbWUgYSB3aGlsZSB0 byB1bmRlcnN0YW5kIHdoeSB3ZSBhcmUgdXNpbmcgMHgxM2ZmIHJhdGhlciB0aGFuIA0KPiAweDFm ZmYuIEl0IGlzIGJlY2F1c2UgZVNQSSByYW5nZSBpcyA0MDk2IC0gNTUxOS4gU28gaW4gdGhlb3J5 LCBpdCB3b3VsZCANCj4gYmUgb2sgdG8ganVzdCBhZGQgJzB4MTAwMCcuIEJ1dCBJIHRoaW5rIHRo aXMgaXMgbW9yZSBjb25mdXNpb24gdGhhdCBpdCANCj4gaXMgd29ydGguIFNvIEkgd291bGQgcmF0 aGVyIHByZWZlciBpZiB3ZSB1c2UgMHgxZmZmIGFzIHRoaXMgbWF0Y2hlcyB0aGUgDQo+IHNwZWNp ZmljYXRpb24uDQo+IA0KPiBDaGVlcnMsDQo+IA0KDQpZZXMsIEkgYWdyZWUgd2l0aCB0aGF0IC0g aXQgd2lsbCBiZSBjbGVhcmVyLCBzbyBJIHdpbGwgdXBkYXRlIHRoZSBtYXNrIA0KdG8gMHgxZmZm Lg0KDQpCZXN0IHJlZ2FyZHMsDQpMZW9uaWQNCg0K From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:15:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:15:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107154.1457677 (Exim 4.92) (envelope-from ) id 1utUbM-0005z1-Rl; Tue, 02 Sep 2025 17:15:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107154.1457677; Tue, 02 Sep 2025 17: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 1utUbM-0005yu-Oy; Tue, 02 Sep 2025 17:15:24 +0000 Received: by outflank-mailman (input) for mailman id 1107154; Tue, 02 Sep 2025 17:15: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 1utUbL-0005yo-Ie for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:15:23 +0000 Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c202::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 664441c3-8820-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 19:15:18 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by GVXPR03MB10500.eurprd03.prod.outlook.com (2603:10a6:150:149::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 17:15:15 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 17:15: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: 664441c3-8820-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KKDy0Y+8pMRV+8GHNj9s71By16TKkP9QOdKp95H2QstZvoWZTntXoqkHBHjYiQ71dE65n4ElMMEz0BQA/w+zqj1z8saXkmTV0iJPEB6LhVrF/pIvfbP6S7Xjec1yW5ibAl/UOu5ySe59nAxVVKKvyoaUWhCGYSTCczugFooRJHkp/0mEcwKC0oXpRg6LHCKsYdepqucjIVGLoxFtVlLTdXlxQEQ1kP3NB7PfQRM1wJu5uCO8C1iFHt7zU2VuVcCzKTZqBvqUra6o4sglhfgzfx8t8E64zeNJK9VTEjr5Kwl6ohmqZVSy7lW29MC86h5NQxDoQOqNqWy/cEkQl83E6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YFR8q9x1RHDV2a9Df+paZY4uaImCiQgN/73ET3Qnloc=; b=WBsSEyXqEPZkLmqIboTgHKO1AAXUAvwkZGQTkLREet9CbCF7u4Lk15A/ooI3g9gAQ5b9GzrpMfx8y7i+uJ0kVPcOuXCivLBOV+vB91JIL8rMJiXQNJ/YCklZhZs0ZbYjN8rk399MQCc0rwP5Mx5H/pgiPZfjbprSGVamySxMpVUsDxAFSAS8qbznVjJq3i8iF/MhxkfByIHRrtQ7PBrbg8LgUFsjh1apHtCTisXTi8B+nLtrm4nEJdd6lJcKwW2FHurBZ1IslweeaQfyF2SuVl/SH6m9pwmAWc9l7WCW3GtSMvs65rb5JrjBzUwizLNctMQjy+0F+Rlp44NjTBKiWQ== 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=YFR8q9x1RHDV2a9Df+paZY4uaImCiQgN/73ET3Qnloc=; b=KWdsVxZ2g838m8OXj70I/Noa8ZPp9nmZw1Xq9WiLt0xJbzAxB8MopVawRin9IzTT0SxfhnH6MuxuCqD5247S7NwBOX6HPtie9BR5rdeDAk/YM+CThEJaL/dAGk4ccXfypO46V3ijwnsLZL8bwKIYBkDpfwjlGQ3tlLFIZjZzT9o+tgajtyW8GS1dsEztdfBrLFgUbLlL/GmMSSH5lOVRBC5bf/VTCo65ffc+TIwQVRVyi6Y/ZdJDpWvxiZbod8skH6qsvfYedxVi2e81X55GFvUvkU/2PGdEO5WCAEYYslVSoI+eedRDToNqZ0HK7kS2FLO0onlw7QQdbeSzL2kN1Q== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Oleksandr Tyshchenko Subject: Re: [PATCH v5 09/12] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Thread-Topic: [PATCH v5 09/12] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Thread-Index: AQHcGP7ji/JPLIO80UCW93TQMdVywbSAHzeAgAAJFQA= Date: Tue, 2 Sep 2025 17:15:15 +0000 Message-ID: <30a25153-1f1f-41cf-afad-195d73ba405e@epam.com> References: <5ab75c0a-0bf6-418a-8c8f-7411a46d4189@xen.org> In-Reply-To: <5ab75c0a-0bf6-418a-8c8f-7411a46d4189@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: GV2PR03MB8678:EE_|GVXPR03MB10500:EE_ x-ms-office365-filtering-correlation-id: 2d35538a-fde7-4578-0897-08ddea4448db 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?cU5LdGk4RDJTUXN1RFhkRGtKSnZLRDRjUGxkK2oydXVGdGVtbTZrdjkwN09l?= =?utf-8?B?bmVOUFlwd0pDZjM3S20reWthbS9YbkFIRlBhSDZ4U2J0aGpnYTFlbkpwRFZs?= =?utf-8?B?K2FNc1JpU2krVGR6cWQ1T2QxaEwweDFLS05mNEozak1Ubm13cjdwZmNMeGFQ?= =?utf-8?B?clhNRXhuU29xUWo1clBlLy9tN0pMN2hvNXFYMkJKZUN3SnpZVHMySzNlekNt?= =?utf-8?B?d1JNTTVDME9EZXBzNGI0MnhCbzY0c3g5Y1RSU3hnTlhDZGRKVEovdHhSMVA2?= =?utf-8?B?dDNOWVBXVFhST1AvN0RPMGVaYldiZmdoenF2bkFmejVhWnA5V01tV0hnaTEr?= =?utf-8?B?NTdxRXBBWGVnWS9BVFBxVThNU1BLWDRSbnplc2ZUa3VLc2NjT2lqVjZ1ZTkx?= =?utf-8?B?MUdpZ2pwYzhQcWZsVW1FS1VkRkZEVWw2QzY0ME1QRTNpcUpBWFNrL1NoY0RO?= =?utf-8?B?RXM3bHVPOG1nOFhaQXZESkVkZktrT2NCZnZIQ0s3SGpIRmNLL0hBckhGdDZO?= =?utf-8?B?bE9POHR1WXJGWTgxakxUZzZ6Q0JsU2tBakEzcTAxdUpzWDBsTVl4MUI3N0t2?= =?utf-8?B?YmF4cDdCTnovb05ZT3ZtMzUyZ0swNHAyRGsvWTFzOEp0VHJSNWxzTU9waHc4?= =?utf-8?B?dUg1bWp1VkFtYkhTSGlMNFZxZWZnZlJWNWdGZ0ZPYy9oZTliMFNZRXFIbFBa?= =?utf-8?B?d0REcmpDL1hYSytzYUNIdHY1cUEwVm4xSTlBcE5KS0lNdHB5MkNTSjAxaHBy?= =?utf-8?B?YS9xNXNYekxhUU9oQ3U1S1dXKzczQjQ4eGxvL0FVRmsxSVZ3eVFJaXY0K29E?= =?utf-8?B?MHJRRWl4c3BHK0pRQkcvM3p5NDdhS1N5UnYxNXJOYzYremltb2QyUVdLTHpt?= =?utf-8?B?eWRQeGx0aHpHck5MaUplcGdFMWxZNi9LZ0g0UjFHb2lZVFgzNDM0ZFB3S01E?= =?utf-8?B?a2hXdXJaZ25CaFNoa0UrWGM1TjJnNEgwcHNETnZib1hNckpHSnpSU3NDRGU1?= =?utf-8?B?Vm9QTnBnemRCN2FOZ0UrakJyVDQzRS96cVZTcTMxN05kaUZHTzBTRFk5ZWpP?= =?utf-8?B?dVFRTTRZYTFJcjk3aVNSdUF5bU1QemR3T1lCR0lNbUE2Z0pzZ3ZCMDQyUDlE?= =?utf-8?B?bndsTiszVHRyd3c4RlVjaFl4dDFVc2hQK2h3eWh1R0xYRWdYNE5SenVQYkt2?= =?utf-8?B?S3plSzdMcHAybkc2VGZtR0VadWdwL0hwd0xHZmMxaUxlOFNNUm10cDlNVFda?= =?utf-8?B?UUJEblZCVWlQQk91MURRQ2VLd1FvRXovRktkV3NZZFpOdkFlUlUzRk0xc0JV?= =?utf-8?B?bitYdS9MU2RBZjVvRkgzYjdSNjhtUjZNaVdIeFRmMUlwVVdXdURubHVvbXdx?= =?utf-8?B?T3UwU1Q2MXQ1U2RBMWltaFZZNjlTS0xzZWxwaHF1Y2pUR0VZVkEvWnVzR1lZ?= =?utf-8?B?aUdRa29PdXJlY082TUVzWEk1Q09HTzNKT0pBcXVSTit1UCsvQmxBNFNYL2Zq?= =?utf-8?B?RGxTUlJHc2QzdkcwaitBcTI3Tk5mTEt2Sm8xeVZHQjVUcG5pZkYvcXJsQ3c2?= =?utf-8?B?UFZKMGFOaDR3TUFiK3Z2eE1aejFFSlhKcjd5Mmo1L2Y5bFVFNkpIQ3VoV2Vr?= =?utf-8?B?cjJUdisxQVVUWitLb3VyNloxTEFPMjRQOGxGQ2tuWmI5SkxYUkFlOHNYNlhZ?= =?utf-8?B?eFhXSGxKdlptMi9sS254SE10bENXTlJXY0JjYUxmRXZFTk15bU5SV3VnNmk0?= =?utf-8?B?bE9CbWozWjZpRC8vZE8yaXlXdlduZEFhaFhhWjJVcTQ1RGl5RGFNaWptWGN3?= =?utf-8?B?SWlxT1JZenNlcFhwNXRFa1krYklZUHBkSnNjWXJwTkpSU2lKK29iblVvcTNV?= =?utf-8?B?RTFzZ3BSZVJnVUJSc2JvUnkwdk4wWVpiVld2dUVKY2JsL0ttb3JJRDVvNGpN?= =?utf-8?B?Ujh0TUtKMUF1cFVGdy90TGRsTFBuSUFmSDNDcXdIVGxwWkxFdkFMVW1jRU4v?= =?utf-8?B?cy9zcGxFcGVnPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZUlVUFVhU2dEM1dYVWlCMVExdEE0VU5YM0VsTlNsU2lDeGZBU2RUcXhsbGkv?= =?utf-8?B?aS9DejUzcWJSYlJqOGtlRjVhUTlVNnVCRjJjRmw4ZDlsYTJFY2dqRklaZnVN?= =?utf-8?B?VW9sbFQ4MGtwWTh4N25BOHBRS0hpekxMZjdGU2N4b1RsTW1ib09zdmIrdFRw?= =?utf-8?B?Tkx0Yk9EaEJrVWpRSTFYaDZMYUI3SGpxZDFFYW54a3RJRVBLaDFiTG9ESHVz?= =?utf-8?B?V01YSVIzeEdRSUlKbEFSUHRDSmRPTlRLVTQvM0FTOTRSRFl3bWRxSVdtZFVw?= =?utf-8?B?c0ZIeUM5eUZSNlRlK1hOb2k1Q05zdTZwRTdYRDVNVzZZNlF4YlNBczgzd1Bi?= =?utf-8?B?S0lVR2xKQjFpcFR6WjBVZ3pMcUxhQk1aSUlWN3EwUHJLVmMzRkhMaTV6TEM4?= =?utf-8?B?S1JJaVA4U1JlVWhoVmFTZ2ViSHgvOEp6ZjZwS2RsMDlOYlE3dkJrb2FDM2xN?= =?utf-8?B?UElEYnlnQkxKZEdkbVN3aTM0MTJpaFRoMG9xRDY2Mi9MaFQzVnQ1Ni84N1ZE?= =?utf-8?B?MmJSUlJmM2hsS3Yva1lPUzhlYk1pc095QVg1RjNEdjQzNzB1cUkvbFBoVHBp?= =?utf-8?B?VTRraUFmdXY3eC9qQ0Y0UE5OMDlPRHByeVd1dTRiKzJjQW4vc0dUL0RQeW1X?= =?utf-8?B?T0NXeXJhUWRoNkt1SjA4cWlzdWE1NkNpZmlxSGFMTEtuOW9DdUhFWmhrekVJ?= =?utf-8?B?NHg2TmRBanJQRlFKNU93SjdHT3l5OHRGdlBtZXdERWxVeUJsWDhMS0Y0bHpD?= =?utf-8?B?NEpKRzVMT1EvY2d1NEJIckg2M3N2VXovRnJxaENGcDJHMWRLVWpZYk1UYmFG?= =?utf-8?B?WkZxNG5LbSs1QktOaXFDTkxTWjEzVzdQR3l6R3d0VThKdHZ4RzFMTzlUZzlt?= =?utf-8?B?cVJsSFVFaFNrd0x4bEc0SnlqTnF1NHJVcTVTbXNTS1BHc0piNkRJcnloMjRv?= =?utf-8?B?MUoyb1k3WjUzRUp3ckkrWXlpYjluR0ZTS1FDSmdKeFNyL2t6dkpTcXdwRU5s?= =?utf-8?B?V3ZoMVVPSVhIQlpldU53SEppRUVPMHpKRlNNRDMwdmphcG5nNFFvRENDWkNW?= =?utf-8?B?TkJpbnRpOWpKOWhiaHlxaVRycm9KVFFRNkMrN1loZWxaekI1SFpNbVlqNS95?= =?utf-8?B?eTgxQ0VwTGMrLzNvMG5VTHNRZlZScjBpdC9ycGdSNG1UT2s5RU0yd1BZL0Jm?= =?utf-8?B?aXRKZGl0dUh2NEdNdFRyd3NxYzhWVkJSUGRSWnJOMUl0ZVNOL0h3YnBXekh3?= =?utf-8?B?T3VYOEdCa25vTXc5eElLSmVXdmxRUC9KVGRBK2ZNeDd2K0dJeHJuSGVjTGtt?= =?utf-8?B?N1ZGNzZ1L0NBV0JzZDBoUTU5YmdUL0tUYmlOVk5tNGNadWpOZ0w4ME5sUjI0?= =?utf-8?B?T3BCZG9IcjhHS1ZKUWFPdXA5eDNwSW9kMHFaRTdDZ0x3K3NOQUFDWXhTb1dK?= =?utf-8?B?TllSYnNxeCttdkgvUHMxKzVqWWpiTGlMeStrQk9Sd2wxNWZYK1RLZXprWEpL?= =?utf-8?B?SGJwdjRRZUFwdGJwaEplcUc5ZTFvRlJiZEdxbGppdXo1b1hsUmtGUGFYZDBL?= =?utf-8?B?Y3JxUnhRU3ZxVUNMR1ZLbHk3b2VRTXpTQnprbTV1N29MU3lHejlBcERRWXlT?= =?utf-8?B?eW9aTGN0WUo0eldJQzMzbU9vemI3NkUzQzgzaVg2aHd3ekZ2R2h4cjRqOEpV?= =?utf-8?B?VnJvcTFIeUhWS1R4ZjA1QlEvVDFmR1EvVFEzVy9UeDB6R1FRQkV1VkRNRE9F?= =?utf-8?B?MkZmdDlYSVA5WldWbEZwclVMVmVTZEVCTW9BMEtMbFdKTWd2U2VjVVhlQW4z?= =?utf-8?B?MkhGenVzVkNoVUtBVlVBc3NlWTBBQjRZWGo2eDJtbzlWeTEwZ0lPQzVhRzhp?= =?utf-8?B?YWxIUEJrOExiS2Z6dHQyang5N09jNDlSMHovSTFCYXZkMEtHcWxFY1BIWDZq?= =?utf-8?B?ZTIzYmJDUFFUbU81cVhjbFpZaUVIMGY2bGVFK0pYdEZKUHd6YzdxdTc5VkJk?= =?utf-8?B?Tk1WL2VTc1Z6NDRiQ1FLSWIxYVlvaEE0OWlBcVVITXQ1bEMwcURndmp6Wmhr?= =?utf-8?B?Rk5XZFlmSm8rWTVVZEZoUUR0NGp6VE4yQUxmZitrRkFUOUdMVnhmV0tyNERX?= =?utf-8?B?M0UrQTVmUFg4NTVkd1JVbFZBYWRJelZRQTBRRmlqdkZ3YUxnejJvSjJ5bVFJ?= =?utf-8?Q?uTh7IoewaUuQg1aWFk7cybM=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <50CC25017D72FB45B946A0C2222EBB9E@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d35538a-fde7-4578-0897-08ddea4448db X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 17:15:15.6964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cvAEzOiUtjNJfW5Sb9MYQbVS6PzpbAenyO9rBgqSzMd5brA5IO7Qgf04LxEWdvXhyA1Wl3hveVLvkAJ7rHKDyqmZ02xbW8vlGpSPA4mDfzk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10500 SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAwMi4wOS4yNSAx OTo0MiwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBIaSBMZW9uaWQsDQo+IA0KPiBPbiAyOS8wOC8y MDI1IDE3OjA2LCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0KPj4gVGhlIERvbTAgYW5kIERv bVVzIGxvZ2ljIGZvciB0aGUgZG9tMGxlc3MgY29uZmlndXJhdGlvbiBpbiANCj4+IGNyZWF0ZV9k b20wKCkgYW5kDQo+PiBhcmNoX2NyZWF0ZV9kb21VcygpIGhhcyBiZWVuIHVwZGF0ZWQgdG8gYWNj b3VudCBmb3IgZXh0ZW5kZWQgU1BJcyB3aGVuDQo+PiBzdXBwb3J0ZWQgYnkgdGhlIGhhcmR3YXJl IGFuZCBlbmFibGVkIHdpdGggQ09ORklHX0dJQ1YzX0VTUEkuDQo+IA0KPiBTdHlsZTogV2UgZG9u J3QgY29tbW9ubHkgdXNlIHBhc3QgdGVuc2UgdG8gZGVzY3JpYmUgdGhlIG5ldyBiZWhhdmlvci4N Cg0KSSB3aWxsIHVwZGF0ZSBpdCBpbiBWNi4NCg0KPj4gwqAgeGVuL2FyY2gvYXJtL2RvbTBsZXNz LWJ1aWxkLmPCoMKgIHzCoCAyICstDQo+PiDCoCB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmPC oMKgwqDCoCB8wqAgMiArLQ0KPj4gwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaCB8 IDE5ICsrKysrKysrKysrKysrKysrKysNCj4+IMKgIDMgZmlsZXMgY2hhbmdlZCwgMjEgaW5zZXJ0 aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJt L2RvbTBsZXNzLWJ1aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtIA0KPj4gYnVpbGQuYw0K Pj4gaW5kZXggNjliOWVhMjJjZS4uMDJkNTU1OTEwMiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNo L2FybS9kb20wbGVzcy1idWlsZC5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVp bGQuYw0KPj4gQEAgLTI4NSw3ICsyODUsNyBAQCB2b2lkIF9faW5pdCBhcmNoX2NyZWF0ZV9kb21V cyhzdHJ1Y3QgDQo+PiBkdF9kZXZpY2Vfbm9kZSAqbm9kZSwNCj4+IMKgwqDCoMKgwqAgew0KPj4g wqDCoMKgwqDCoMKgwqDCoMKgIGludCB2cGwwMTFfdmlycSA9IEdVRVNUX1ZQTDAxMV9TUEk7DQo+ PiAtwqDCoMKgwqDCoMKgwqAgZF9jZmctPmFyY2gubnJfc3BpcyA9IFZHSUNfREVGX05SX1NQSVM7 DQo+PiArwqDCoMKgwqDCoMKgwqAgZF9jZmctPmFyY2gubnJfc3BpcyA9IHZnaWNfZGVmX25yX3Nw aXMoKTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAvKg0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAg KiBUaGUgVlBMMDExIHZpcnEgaXMgR1VFU1RfVlBMMDExX1NQSSwgdW5sZXNzIGRpcmVjdC1tYXAg aXMNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgYi94ZW4vYXJj aC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+IGluZGV4IGQ5MWE3MWFjZmQuLjM5ZWVhMGJlMDAgMTAw NjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+ICsrKyBiL3hlbi9h cmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gQEAgLTIwNTQsNyArMjA1NCw3IEBAIHZvaWQgX19p bml0IGNyZWF0ZV9kb20wKHZvaWQpDQo+PiDCoMKgwqDCoMKgIC8qIFRoZSB2R0lDIGZvciBET00w IGlzIGV4YWN0bHkgZW11bGF0aW5nIHRoZSBoYXJkd2FyZSBHSUMgKi8NCj4+IMKgwqDCoMKgwqAg ZG9tMF9jZmcuYXJjaC5naWNfdmVyc2lvbiA9IFhFTl9ET01DVExfQ09ORklHX0dJQ19OQVRJVkU7 DQo+PiAtwqDCoMKgIGRvbTBfY2ZnLmFyY2gubnJfc3BpcyA9IFZHSUNfREVGX05SX1NQSVM7DQo+ PiArwqDCoMKgIGRvbTBfY2ZnLmFyY2gubnJfc3BpcyA9IHZnaWNfZGVmX25yX3NwaXMoKTsNCj4+ IMKgwqDCoMKgwqAgZG9tMF9jZmcuYXJjaC50ZWVfdHlwZSA9IHRlZV9nZXRfdHlwZSgpOw0KPj4g wqDCoMKgwqDCoCBkb20wX2NmZy5tYXhfdmNwdXMgPSBkb20wX21heF92Y3B1cygpOw0KPj4gZGlm ZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmggYi94ZW4vYXJjaC9hcm0v aW5jbHVkZS8gDQo+PiBhc20vdmdpYy5oDQo+PiBpbmRleCA5MTJkNWI3Njk0Li4zYWEyMjExNGJh IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaA0KPj4gKysr IGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaA0KPj4gQEAgLTM0Nyw2ICszNDcsMjUg QEAgZXh0ZXJuIHZvaWQgDQo+PiB2Z2ljX2NoZWNrX2luZmxpZ2h0X2lycXNfcGVuZGluZyhzdHJ1 Y3QgdmNwdSAqdiwNCj4+IMKgIC8qIERlZmF1bHQgbnVtYmVyIG9mIHZHSUMgU1BJcy4gMzIgYXJl IHN1YnN0cmFjdGVkIHRvIGNvdmVyIGxvY2FsIA0KPj4gSVJRcy4gKi8NCj4+IMKgICNkZWZpbmUg VkdJQ19ERUZfTlJfU1BJUyAobWluKGdpY19udW1iZXJfbGluZXMoKSwgVkdJQ19NQVhfSVJRUykg LSAzMik+DQo+PiArc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQgdmdpY19kZWZfbnJfc3Bpcyh2 b2lkKQ0KPj4gK3sNCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICvCoMKgwqAgLyoN Cj4+ICvCoMKgwqDCoCAqIENoZWNrIGlmIHRoZSBoYXJkd2FyZSBzdXBwb3J0cyBleHRlbmRlZCBT UElzIChldmVuIGlmIHRoZSANCj4+IGFwcHJvcHJpYXRlDQo+PiArwqDCoMKgwqAgKiBjb25maWcg aXMgc2V0KS4gSWYgbm90LCB0aGUgY29tbW9uIFNQSSByYW5nZSB3aWxsIGJlIHVzZWQuIA0KPj4g T3RoZXJ3aXNlDQo+PiArwqDCoMKgwqAgKiByZXR1cm4gdGhlIG1heGltdW0gZVNQSSBJTlRJRCwg c3VwcG9ydGVkIGJ5IEhXIEdJQywgc3VidHJhY3RlZCANCj4+IGJ5IDMyLg0KPj4gK8KgwqDCoMKg ICogRm9yIERvbTAgYW5kIHN0YXJ0ZWQgYXQgYm9vdCB0aW1lIERvbVVzIHdlIHdpbGwgYWRkIGJh Y2sgdGhpcyANCj4+IHZhbHVlDQo+PiArwqDCoMKgwqAgKiBkdXJpbmcgVkdJQyBpbml0aWFsaXph dGlvbi4gVGhpcyBlbnN1cmVzIGNvbnNpc3RlbnQgaGFuZGxpbmcgDQo+PiBmb3IgRG9tMA0KPj4g K8KgwqDCoMKgICogYW5kIG90aGVyIGRvbWFpbnMuIEZvciB0aGUgcmVndWxhciBTUEkgcmFuZ2Ug aW50ZXJydXB0cyBpbiANCj4+IHRoaXMgY2FzZSwNCj4+ICvCoMKgwqDCoCAqIHRoZSBtYXhpbXVt IHZhbHVlIG9mIFZHSUNfREVGX05SX1NQSVMgd2lsbCBiZSB1c2VkLg0KPj4gK8KgwqDCoMKgICov DQo+PiArwqDCoMKgIGlmICggZ2ljX251bWJlcl9lc3BpcygpID4gMCApDQo+PiArwqDCoMKgwqDC oMKgwqAgcmV0dXJuIEVTUElfQkFTRV9JTlRJRCArIG1pbihnaWNfbnVtYmVyX2VzcGlzKCksIDEw MjRVKSAtIDMyOw0KPj4gKyNlbmRpZg0KPj4gKw0KPj4gK8KgwqDCoCByZXR1cm4gVkdJQ19ERUZf TlJfU1BJUzsNCj4gDQo+IFRoaXMgaXMgdGhlIG9ubHkgdXNlciBvZiBWR0lDX0RFRl9OUl9TUElT LiBUaGVyZWZvcmUsIEkgd291bGQgcHJlZmVyIGlmIA0KPiB3ZSByZW1vdmUgdGhlIGRlZmluZS4g VGhpcyB3aWxsIGF2b2lkIGFueSBjb25mdXNpb24gYmV0d2VlbiB0aGUgaGVscGVyIA0KPiBhbmQg dGhlIGRlZmluZS4NCj4gDQo+IENoZWVycywNCj4gDQoNCkFjdHVhbGx5LCB3ZSBuZWVkIHRoaXMg bWFjcm8gaW4gdGhlIHByZXZpb3VzIHBhdGNoIGluIHRoZSBzZXJpZXM6DQpbMDgvMTJdIHhlbi9h cm06IHZnaWM6IGFkZCByZXNvdXJjZSBtYW5hZ2VtZW50IGZvciBleHRlbmRlZCBTUElzDQooZG9t YWluX3ZnaWNfaW5pdCk6DQoNCiAgICAgaWYgKCBucl9zcGlzICsgMzIgPj0gRVNQSV9CQVNFX0lO VElEICkNCiAgICAgew0KICAgICAgICAgZC0+YXJjaC52Z2ljLm5yX2VzcGlzID0gbWluKG5yX3Nw aXMgLSBFU1BJX0JBU0VfSU5USUQgKyAzMiwgMTAyNFUpOw0KICAgICAgICAgLyogVmVyaWZ5IGlm IEdJQyBIVyBjYW4gaGFuZGxlIHByb3ZpZGVkIElOVElEICovDQogICAgICAgICBpZiAoIGQtPmFy Y2gudmdpYy5ucl9lc3BpcyA+IGdpY19udW1iZXJfZXNwaXMoKSApDQogICAgICAgICAgICAgcmV0 dXJuIC1FSU5WQUw7DQogICAgICAgICAvKg0KICAgICAgICAgICogU2V0IHRoZSBtYXhpbXVtIGF2 YWlsYWJsZSBudW1iZXIgZm9yIHJlZ3VsYXINCiAgICAgICAgICAqIFNQSSB0byBwYXNzIHRoZSBu ZXh0IGNoZWNrDQogICAgICAgICAgKi8NCiAgICAgICAgIG5yX3NwaXMgPSBWR0lDX0RFRl9OUl9T UElTOw0KICAgICB9DQoNCkkgaGF2ZSBzZWVuIHlvdXIgY29tbWVudCByZWdhcmRpbmcgcmV3b3Jr aW5nIHRoZSBjaGVja3MsIGJ1dCBpbiBhbnkgDQpjYXNlLCBJIHN0aWxsIG5lZWQgdGhpcyBtYWNy byB0byBhc3NpZ24gdGhlIHZhbHVlIHRvIG5yX3NwaXMsIHNvIEkgd291bGQgDQpwcmVmZXIgdG8g bGVhdmUgaXQuDQoNCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlk From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:25:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:25:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107166.1457686 (Exim 4.92) (envelope-from ) id 1utUkq-0007iZ-Mm; Tue, 02 Sep 2025 17:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107166.1457686; Tue, 02 Sep 2025 17:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utUkq-0007iS-KC; Tue, 02 Sep 2025 17:25:12 +0000 Received: by outflank-mailman (input) for mailman id 1107166; Tue, 02 Sep 2025 17:25:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utUkp-0007iM-Ik for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:25:11 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c6828326-8821-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 19:25:09 +0200 (CEST) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-45b7d497ab9so51299725e9.0 for ; Tue, 02 Sep 2025 10:25:09 -0700 (PDT) Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e7f14bbsm209450565e9.8.2025.09.02.10.25.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 10:25: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: c6828326-8821-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756833909; x=1757438709; 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=PFjgMDmRG0RvRn8jcxfZJppN4ti5avtqPxOHumOTe34=; b=AxiX6wuRNHqKD9Zz7xyuIWvQXXKZoLsjdGAkgSiSlHm5q0w1wkHkSUWqpsu5d/LkIF 44Y6oKYebpN2v6WKTQg8jbYmfEOdm0i18UDv5AXm6mM82vthGWC0xIfW3OUxA3y82PeQ ikfEpksNWFadR6cvSoBpICsC1FaxJS+aTF2jGAscKMUkizUkyKbskD0n2yN57jfmPLT/ phWtRgPKq8IPQ2xTLunsmXisw94B3qYew5XCnvWHj8G/oX8qDisxsU6tQt0ibFYyHZxS 1EUJub3lg76e3EYYS5OkYU1c7QzZNatlpdE55Vfo64rsLkYhSjyEGNyKOHQtTb8+nOhr 6G0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756833909; x=1757438709; 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=PFjgMDmRG0RvRn8jcxfZJppN4ti5avtqPxOHumOTe34=; b=SdPkVjqXRewjm7D8u6x3R3rUsNPOiSOuBBLruwQxTUfo052sOu2lHf1RmuwZ8dZOmW UDVi9u7qNJDOuo+HnvPfH7mhhCzla6a5iGwRqOR3UsrGyPpfMCTFajd2XB/2Md8thYju qzRK8Ue3/UA9m2F3OY0yvL6WvB7gfwhpFPW7uGvVqOEGiAEscntqd+Q/uKjb36nx95fx x4xVxX2rGFauqo0HMu1nwvvG9MCCILr+Dl1RfBjldOtU9fBoulDnT0ieF/K0FJcgdDMr an6VYjSYgIn7W07sNw6N3I/pA+aMo+SED4F+Nzsd/6p0F9MyMnga/yrl2TOANZ8YG2mm smsA== X-Forwarded-Encrypted: i=1; AJvYcCXVrdAt9zyP4CXHLoNytfURiWtF9/pVxi7AdiMBkY2TZJ17X3S+Lwh/OfsB4VCJpL6f0Hu63Y8cKvs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy/5JHyvUoyPKdAVtPbEqMs+0NASwA98cg9ti9mfCw1zUT/eO4a nK1tqDfWr5pNqGhWtMHgdBti+swTbaMNQs5aIdgJ1gQVx8X7CZvhOmoA X-Gm-Gg: ASbGncsl0b63NDB3fKvMGTRRy8cs2P6fkmnTMlAhx+dPcnqG+NQynVC2pbTYsNhwp52 1w/AFF0cIzTqoQCD+UkBMwApTrLc36ewlgphzen7FeEH0s0UYRepwuqwdOxyZU3IGTDeqgogRme f4QC2PqqHrtvCXQMyp8wfHZyb2Q5yg4sYAYXfxHAt1kSrxlvp+/fszh4TUTPThK0/217vKFLzkD SDgMMoMxDg0eN03jdctGFKeWxZjUk4BGD0vOoxevUkg2QvkzEmRWHmPoNom5ntroq4C81n1PZL5 AWQc9Lx+ZObDzlYvIg+cAdj5xMSoevRXesGiNkLN2lbUGiUX7RicWUBI0nVr2PiA/ipd0AvX6C3 FMQgdPdrRnDD3zdubqsrkPpwVwdC119a5DM7KsEMPvoKnt7/xPAU2mvI= X-Google-Smtp-Source: AGHT+IFewne8udaKZi5O5/EHGdS+V0zqJrzJR87cN4IA6CbDt357R4s6zA5Xykz0pM/djQQI0WckbA== X-Received: by 2002:a05:600c:1d24:b0:45b:581c:ad0d with SMTP id 5b1f17b1804b1-45b85550679mr106806015e9.8.1756833908757; Tue, 02 Sep 2025 10:25:08 -0700 (PDT) Message-ID: <361a7a79-a11c-4c35-a688-0937e9d65fcf@gmail.com> Date: Tue, 2 Sep 2025 20:25:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 12/13] xen/arm: Suspend/resume IOMMU on Xen suspend/resume To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh , Mykola Kvach References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.09.25 01:10, Mykola Kvach wrote: Hello Mykola > From: Oleksandr Tyshchenko > > This is done using generic iommu_suspend/resume functions that cause > IOMMU driver specific suspend/resume handlers to be called for enabled > IOMMU (if one has suspend/resume driver handlers implemented). > > Signed-off-by: Oleksandr Tyshchenko > Signed-off-by: Mykola Kvach > --- > Changes in V6: > - Drop iommu_enabled check from host system suspend. I do not have any comments for the updated version, thanks. > --- > xen/arch/arm/suspend.c | 11 +++++++++++ > xen/drivers/passthrough/arm/smmu-v3.c | 10 ++++++++++ > xen/drivers/passthrough/arm/smmu.c | 10 ++++++++++ > 3 files changed, 31 insertions(+) > > diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c > index 35b20581f1..f3a3b831c5 100644 > --- a/xen/arch/arm/suspend.c > +++ b/xen/arch/arm/suspend.c > @@ -5,6 +5,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -62,6 +63,13 @@ static void cf_check system_suspend(void *data) > > time_suspend(); > > + status = iommu_suspend(); > + if ( status ) > + { > + system_state = SYS_STATE_resume; > + goto resume_time; > + } > + > console_start_sync(); > status = console_suspend(); > if ( status ) > @@ -118,6 +126,9 @@ static void cf_check system_suspend(void *data) > console_resume(); > console_end_sync(); > > + iommu_resume(); > + > + resume_time: > time_resume(); > > resume_nonboot_cpus: > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index 81071f4018..f887faf7dc 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -2854,6 +2854,13 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) > xfree(xen_domain); > } > > +#ifdef CONFIG_SYSTEM_SUSPEND > +static int arm_smmu_suspend(void) > +{ > + return -ENOSYS; > +} > +#endif > + > static const struct iommu_ops arm_smmu_iommu_ops = { > .page_sizes = PAGE_SIZE_4K, > .init = arm_smmu_iommu_xen_domain_init, > @@ -2866,6 +2873,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = { > .unmap_page = arm_iommu_unmap_page, > .dt_xlate = arm_smmu_dt_xlate, > .add_device = arm_smmu_add_device, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend = arm_smmu_suspend, > +#endif > }; > > static __init int arm_smmu_dt_init(struct dt_device_node *dev, > diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c > index 22d306d0cb..45f29ef8ec 100644 > --- a/xen/drivers/passthrough/arm/smmu.c > +++ b/xen/drivers/passthrough/arm/smmu.c > @@ -2947,6 +2947,13 @@ static void arm_smmu_iommu_domain_teardown(struct domain *d) > xfree(xen_domain); > } > > +#ifdef CONFIG_SYSTEM_SUSPEND > +static int arm_smmu_suspend(void) > +{ > + return -ENOSYS; > +} > +#endif > + > static const struct iommu_ops arm_smmu_iommu_ops = { > .page_sizes = PAGE_SIZE_4K, > .init = arm_smmu_iommu_domain_init, > @@ -2960,6 +2967,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = { > .map_page = arm_iommu_map_page, > .unmap_page = arm_iommu_unmap_page, > .dt_xlate = arm_smmu_dt_xlate_generic, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend = arm_smmu_suspend, > +#endif > }; > > static struct arm_smmu_device *find_smmu(const struct device *dev) From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:26:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:26:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107177.1457696 (Exim 4.92) (envelope-from ) id 1utUmD-0008Fq-1i; Tue, 02 Sep 2025 17:26:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107177.1457696; Tue, 02 Sep 2025 17: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 1utUmC-0008Fj-Uq; Tue, 02 Sep 2025 17:26:36 +0000 Received: by outflank-mailman (input) for mailman id 1107177; Tue, 02 Sep 2025 17:26: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 1utUmA-0008FY-RI for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:26:34 +0000 Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazlp170130006.outbound.protection.outlook.com [2a01:111:f403:c201::6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f80bf676-8821-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 19:26:32 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by DBAPR03MB6645.eurprd03.prod.outlook.com (2603:10a6:10:17f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 17:26:30 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 17:26: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: f80bf676-8821-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yxRgNP2rDRrJ79wBtAf910JNU7vxy9Rob452QgiJd3PZBXwKLIYcNsLc3E+LYGmpcdWZgaBLKJmTNoaNfZiafY+2l0kK4KmPDOieixm2AaVd1PUkmYxdGqIvAwPQ7luOdRvRz+A44jmuegl1vTl+cKj+V44d93jlviNg6iyKYVncUicMCnQdxWswpGllgXQfTqaroAuBys4wmuEl5JdCSDnrdZXvw3YwMYQVm1IdhWhTfTc4yzs9YbtFKkbKGMiBtPUPTzIi7zQjlTGYS+vdllZQQGAAWC/MZB7jp2YFjzGRTrK69zGMjTZoWIkAvQBpCDbajqNSq3s0JZUBIJdDJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6qsO6yvl8kP8Lnb/IhB+86EVh+gzG8bLFyt+V2oF6zw=; b=V3Fin9RFnmS6HXtqoQ78CZzTkbFb/cR6qBuFrjLp+I3zUvRt4c5EeEWKIprlXw4PwCRxmAItztzaO8QBui2oXaC0e4Ivhmq8l5XaMne0o3tHc6B/LSgYYGp28rbciqUB90F/vy50CAjWeSevvcEEjrQ1XLM9fMU1B6WW9JGcFdZ1fO3ikrf3J8rTWyQkk3bZLqJUGohIeptUiUVGQR7k9BdCbi+6k5Ph6srNozEKUdo/QYpmTJn14Nz8F/O19mB4yCrWxYRsynIk+QdN9SPyw7jlFdWszYK03h0GkMC1amY1jDJo748u05WI7PhhKn6KB6di/Ls3pDvWSWpdTA62Ig== 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=6qsO6yvl8kP8Lnb/IhB+86EVh+gzG8bLFyt+V2oF6zw=; b=uhZasLP0Zlyjzu3tMfTe8yRRhwCUnLGfFIjojwh+SFfFntu3TamODZBahdWZx6iJtcvcC+vZkGsf8/yrhAFELoGL8l4TQ8UeUdOi2f6i/NqhMlC/I7GQ4R1VLAibSzkBVQtd5HHqGg1j8rbAiNQ6XOL2JKThfvfP3XO2kvPY97Z5m422o582vhHmFjqfNtX210q9YxrJyE2w4EHOYXVcb87U4xtGuMXmeg7J1LEXjWRyKx3TI2SOS5v0FUvl0aKRXRoOXTSODPvS7Jmm7x0WVFbgzrBoWj9m+dMADJHetWelQ9JfyRdq7si9uSXorhUZQex6LCwD5DPRJQG8A5qhXg== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Topic: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Index: AQHcGP7lSnKp01vKiUyg8GCh+goOA7SAIt4AgAAIk4A= Date: Tue, 2 Sep 2025 17:26:30 +0000 Message-ID: References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> <06ff285f-39d5-4ffd-b842-6d776bb793ac@xen.org> In-Reply-To: <06ff285f-39d5-4ffd-b842-6d776bb793ac@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: GV2PR03MB8678:EE_|DBAPR03MB6645:EE_ x-ms-office365-filtering-correlation-id: f0cfb65c-3b1c-4120-f015-08ddea45daf7 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?RjJiSFFwVUVyV04rN29JOVJ2eFB1am9tYmNUU0JlcDV0UndMQlNXVTFWeXor?= =?utf-8?B?UXA1b0Z6TUFWYmNIb1hTZlVnQUprdkVEUFhJQlNzQjNWcW5mN3duaG4xbm9U?= =?utf-8?B?Q21wYnY2N0M2VjhRZWo2T1N1RXBFMFV3QW1vcTk1bnhWZGV6UTg1b1gzT0F1?= =?utf-8?B?K0x4S0hNUVQxelVMUCtGRWJzcW00d0k4em12cDIybDJoV3kzNm9Ec1dQa09K?= =?utf-8?B?V1NvNUROMEpjc2tRVVhFQnBlaEF2NytHaUZOQ1ZSSGhXNjdZMk5XSjM3Y3FF?= =?utf-8?B?YUx3Rk9Qci9lbTMyeCs1d3hQK3BlREEySStvRjlQaWR3aTNEek9vZFQ2aWlu?= =?utf-8?B?cEFNRFhlSXhQaHc1aE1OMmtiYk40Vmw1M3dGTlRqNWwxdVpxbGxIYS9PQm81?= =?utf-8?B?SFJ4c2phZkZ1YXZGU1lyVUtqRUlxYVRqSS9LR2RGRTY2dndCdk5tNFovVWdI?= =?utf-8?B?Yk5tQk4rKzhHVGFCRmN6MHNmMmlkZkg2M094VjJvc081eDQxb29nSlp5MUZJ?= =?utf-8?B?a1U2Q3pUOGJRQ3JRK09wN1ZMbC95ZnptdFY0S3poVEpFblluRnQzWHZTUG1J?= =?utf-8?B?RTFXaXZjaDdob25sWXBRMTI2cE5PejcrWUJXcmxyK2htWDhGOSszVlc2Mjhs?= =?utf-8?B?SGFYdmIvZ3g3UG1RK1RjU1E2RjVOZG1UNWpGWHhzWVpLVzhPeE4rdjRRQjhl?= =?utf-8?B?aEhkVWl4SVpQdjZpRnQ5YnNxSEpuR3gvN2t2RDZ3eFljejVUR3BrRVBtMzNQ?= =?utf-8?B?U3BxamRxcW9lVElIeTBJaXNLLy8rbnZDendjS3pqUzEydlg0ZmdjdTNtVUJq?= =?utf-8?B?VkJ1UDZ3QWowcFRVZmd2V0YyUkV3cUt1bVkwUnZiRGxCWjVGb3o1VVlyOC84?= =?utf-8?B?RWpuRng4eWNjd2RKZmxOQTYxQjdQdU5LZGwxREwyYUhUVklVK2ZibkxpMlli?= =?utf-8?B?UjloakNlUllUOVY5N21QQ2VOeFhFT1FsNGxFNVVWendWTGd5RkhyaXhyRmdU?= =?utf-8?B?RHBZR3BTcXo3S1RvWUFJbmZkcFBlMTZ4NjVUOGx0Y0JscnUyai8rN3VuUU4z?= =?utf-8?B?anZoc0N6WWZzRXZLdlV0MEN0K3NQNkZLTDJybXR4NkpTQXIzZ0pjenFRc1F4?= =?utf-8?B?NUxpeU96SkRsMlRWc3BKbEhNSm9LZndiMDgxQ0Jic2VIbG83WXNPL0ZyTGtJ?= =?utf-8?B?SmdRYnI3T0pndEUzN1lVVzZrUENmUXY3blRTSnovYzVCYnNQVVBWaTgvdWNt?= =?utf-8?B?Q21yWDRwU0RrK1A5bllQczNGZUhaZTd5MEFGSFJISEhRVlZhYWdxTG54cUZM?= =?utf-8?B?ZlpITksvd3NDOGt3Sko5VzZaU2k5dEhhVXlRVmM3OHZta0ZxQ01oZzVCQ3I1?= =?utf-8?B?TGcwSWpDN0RhRlJNK0twNDI4SEFLZlN5L3hqK1hGVGFkc1o2aXg5REF4dEF2?= =?utf-8?B?cU5SUGc2YkUxWVdZNmlydWhvYS9xVjlSZU9qRmE1WXB5K3Z3SHFBWFRhNG55?= =?utf-8?B?Q1dCN0NUcXFWVDMwcXVVK2Nlai81TmtjVy95amJ0eUo5OVNacWNUeTdYNFk4?= =?utf-8?B?TkMwSi9MSUtZL1hweWZIRnZuZmJFNGZxTy9USmEvSUFIWTB0QWhmNVA4a1ZB?= =?utf-8?B?WmFEV2pzRzNTeHNaWnlUSit5WlRqamprNWhvZTJ5YUJKUXFzeExORFhPQng1?= =?utf-8?B?dEYxM2VhV2p0WVhmSXRMdHV5Y09wSWo4VTBoN1FlVHhESnBsV3dVZWE5ZnBY?= =?utf-8?B?NUU5SkpiZDAvUVFMRDg4NTFJNElrZld6cUNJYm5XMmRNejBTbUVTQzh5b1Yv?= =?utf-8?B?Y05pNk9hb0pWU1kwSGR4QTczNXFQZmFLUU1OTGpaVFVvS1hqWHFNVnZLdjZM?= =?utf-8?B?aVk5SVdNUXdyRjc3Z2JScmEvR1Y3MWk1c0xDQnRJNFVhUWN1TzdJdXhoMzEw?= =?utf-8?B?TWpDcFNZWG5icXIyajNVRGFPNWhzRGF5bVRlTHM1Mi9sdEUxSlg3VnREbHFO?= =?utf-8?B?MzJQK0dVVURnPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SU5PSjVyTW8xYU80TzRsamo2U0gxMVpPUmRjaklUUjlkeWc4UUxxOTZTS1JO?= =?utf-8?B?M092YzZHMWI0U1ZuM1NieC9kR0tjK1JTTjVaZ0U1aHU5UWVCVnlkcEllVE1w?= =?utf-8?B?M2RNMWFKN2RtVlVoNHZ1RHlQSjVSOGd4YXBrYjBRZVBnYm9ZRm0yVTlqY0xw?= =?utf-8?B?bWNuMVhWdXBWaDdWV0s2VXJyYVpvNnJDcVlXaTdBb2F2dnRidzFKWFhadU1u?= =?utf-8?B?SkVHNGpsV1pPTTQzZ2ptb2dPOG9QQUVBMUkxWSs4cFpWdGlQenEvSnA1Nlo3?= =?utf-8?B?T1VxTzR2QXk3d1Iya3Jka3V2RlJsdkpPMmZVeWp5eFNYR1Vvek9GNUdWZFcw?= =?utf-8?B?NGUyZktLcHFQdEQ5VE81cWlIUXVaZlZCaWFCNUVxZURIQjNuYXpoR0s0cjJx?= =?utf-8?B?SWM2V2xpNXQ0Qms3dUZoMWdyeTdnRi9TSkEvREhadjFlRERwczNkcUtpL3NT?= =?utf-8?B?VVhGTmswSUZKNHkwR3d1VGZtZ0dXT3lCb0xWc3lIM3Z2bnhnYk5nUURNUDYz?= =?utf-8?B?THNiU2Y2UGtMU2hwdDJHNXd3ZjZsV25uVE1INXpsSGNQdndocUdwZm4vMnNa?= =?utf-8?B?NHIvK0x3UXl4SnZSNlJWV0dxZEkzclNRcUdZNW5NWmlYaVcxMTZYRXJkNVdH?= =?utf-8?B?U0swZ1ZwRWpackRWZURGaVBKTFZ6ZHk2dVN4L1Q5V1FPc05LeVRGbUZIdnFQ?= =?utf-8?B?QW5xUE9jREIxUFZDY04zOUxzT1ZaOCtPaGpVbjl4UjhqOTJDR0lQU0dxSFVi?= =?utf-8?B?QnpRWW1OYXhvM0VkWEg1WXcrRWNmZEtTZXVWMkU3ZzF6Q1dLVERuVHlULzlk?= =?utf-8?B?UG5GQlBYTlYzekZ3QVRYWjJpQjQ5ajEvNHJSOFJUTXhGbHJsZVEvZVh5MVll?= =?utf-8?B?a2srLzFET3JTNFdaeHk5UlptRUN4U1BIZDJaalZtV3p3c1VtY3o0bS9rZGJV?= =?utf-8?B?dE5xcmNGV0dwRkFFZllUdEorWm1yR0NHRlovOTBxTzFLTTErV1ZMelArMm9o?= =?utf-8?B?MUZGOWxGaThXcUx5c3lLbWdMMERram9WUVJhUWZYUnV3NW8zSE9sajYzb0JD?= =?utf-8?B?M3R5bjB5ZlRwaFVhYTBVZk5SQkJRcmdJKzRKQ0tYb1IxS0I4RWx0bFZ1MVZp?= =?utf-8?B?bXRyaUt3QXlyaXhjK0hoTVkweXp0ZHNXd0xMaGNhd0FnYlZVaEhCZG12SzFu?= =?utf-8?B?dFdCQ3BZcUltYXVNNTJySDNPWUF1MXVRYWxqUlhUNllXRjNwRFpSTzVrcm01?= =?utf-8?B?NTRPRytMOHNwQ0VQRE5qRkkvNE1ZTmVkLzVCb0taQWF3c2RQaW5UTGp0bHVF?= =?utf-8?B?NkhaWldRMjVmNjE1a2Z1cDVzM2UyT0pndnV2S2RoSWE2bkVqWEpwOTdjRnZx?= =?utf-8?B?VjMwZXhvU1hmMHJ1eEF4TDdHakppSWtDaWk1M0NUMFJxTWJVWkJOVnFZcmFj?= =?utf-8?B?cER1STBrRWlmdjByR1N1ckFOUHJvVE4waFJnQjZQbmNvMVRhbGJpcmtXeWFs?= =?utf-8?B?TE42WFpvQlp4ZWc3TWpJOGVaVmpWMXoxaFgySVExeWRYZHd3ejNWRTJKMWxG?= =?utf-8?B?L050QnI2Z2g1ZVVIZmZaUGhHL2JoOU5uM2UyaXVmWm9memhHeEx6cWtONzYv?= =?utf-8?B?aWdRVXZQZmxCdnZsb05WRVV0TDYxYUIrUWJkbGdsQmI5NG1ZWEFWSVp6ODdI?= =?utf-8?B?cHl6OWZ3bTc2cDlmWWhhOWllbVFMakE1RlA3cVZTV21IVDZnVmkwNnZLK2tQ?= =?utf-8?B?ZlJYSCt2NXZkcy82cmFLWnp5a2ZZZWM4a3ZKdmdnd3cxT3dJWWRUYU0rOTRJ?= =?utf-8?B?b1FKUiszYjdZYSt1QTd0dDByRFN2ZnVpK3oxUFFHYzdxQkF0bUFRazNreldI?= =?utf-8?B?ZkhLT1dmOEpHSXNkS0dmNDhUdlJ5R1FpSGE5blJ5UFpRaUlOV0JHRlBtMTNR?= =?utf-8?B?bkwzdTJIOHRKMmhOSit5Y09vTS9hMTRBZXQwaWZuTzFHMWx1c1owQks3LzF6?= =?utf-8?B?OWl4aXI2R3VmVGw4MW1ST0IwUG5CaFhKczFpdDVVYlFqbTNxZnJoVEovNDRo?= =?utf-8?B?ejFkVHNEMDh3c082eFhXaGFCMEZmVHNlTlVrYUx1M1BSYWgyOFNRN1hHWFdS?= =?utf-8?B?bjJiVkU5QUUrcDJhNnJ5U1QvNzY0bEF3bGNHN0NtY2MyOHNRUnJCam5LbkYr?= =?utf-8?Q?cIcvReWahJL4vbV5ooGZIno=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <4D0EC90B7A90E84F9B2B15011B58ADD5@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0cfb65c-3b1c-4120-f015-08ddea45daf7 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 17:26:30.3406 (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: JxcxpHW+XBW6BQ9EGuSAaq8iwfouNQORRMD4C2DzGsV491XJHfr7vwEP0x+mCjsV+VuGcf4FPPXjtuo0WgPWbLAqbDQZ3dqsBl43Idvnsnc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6645 SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBzdWdnZXN0aW9ucy4N Cg0KT24gMDIuMDkuMjUgMTk6NTUsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgTGVvbmlkLA0K PiANCj4gT24gMjkvMDgvMjAyNSAxNzowNiwgTGVvbmlkIEtvbWFyaWFuc2t5aSB3cm90ZToNCj4+ IEBAIC03ODIsNDYgKzgwNCw4MSBAQCBzdGF0aWMgaW50IA0KPj4gX192Z2ljX3YzX2Rpc3RyX2Nv bW1vbl9tbWlvX3dyaXRlKGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDC oMKgwqDCoCB7DQo+PiDCoMKgwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSLCBHSUNE X0lHUk9VUFJOKToNCj4+IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBNT0RSLCBH SUNEX0lHUlBNT0RSTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JPVVBSbkUs IEdJQ0RfSUdST1VQUm5FTik6DQo+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JR1JQTU9E Um5FLCBHSUNEX0lHUlBNT0RSbkVOKToNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAvKiBXZSBkbyBu b3QgaW1wbGVtZW50IHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIGd1ZXN0cywgd3JpdGUgDQo+PiBp Z25vcmUgKi8NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBnb3RvIHdyaXRlX2lnbm9yZV8zMjsNCj4+ IMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUiwgR0lDRF9JU0VOQUJMRVJO KToNCj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lTRU5BQkxFUm5FLCBHSUNEX0lTRU5B QkxFUm5FTik6DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9X T1JEICkgZ290byBiYWRfd2lkdGg7DQo+PiAtwqDCoMKgwqDCoMKgwqAgcmFuayA9IHZnaWNfcmFu a19vZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU0VOQUJMRVIsIERBQlRfV09SRCk7DQo+PiArwqDC oMKgwqDCoMKgwqAgaWYgKCByZWcgPj0gR0lDRF9JU0VOQUJMRVJuRSApDQo+PiArwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19leHRfcmFua19vZmZzZXQodiwgMSwgcmVnIC0gR0lD RF9JU0VOQUJMRVJuRSwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgREFCVF9XT1JEKTsNCj4+ ICvCoMKgwqDCoMKgwqDCoCBlbHNlDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0g dmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBHSUNEX0lTRU5BQkxFUiwgDQo+PiBEQUJUX1dP UkQpOw0KPiANCj4gV2hpbGUgSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gdHJ5IHRvIGF2b2lk IGNvZGUgZHVwbGljYXRpb24uIEkgZmVlbCANCj4gdGhpcyBpcyBtYWtpbmcgdGhlIGNvZGUgYSBs b3QgbW9yZSBjb21wbGljYXRpbmcgYW5kIGluIGZhY3Qgcmlza2llciANCj4gYmVjYXVzZS4uLg0K PiANCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIHJhbmsgPT0gTlVMTCApIGdvdG8gd3JpdGVf aWdub3JlOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZs YWdzKTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB0ciA9IHJhbmstPmllbmFibGU7DQo+PiDCoMKg wqDCoMKgwqDCoMKgwqAgdnJlZ19yZWczMl9zZXRiaXRzKCZyYW5rLT5pZW5hYmxlLCByLCBpbmZv KTsNCj4+IC3CoMKgwqDCoMKgwqDCoCB2Z2ljX2VuYWJsZV9pcnFzKHYsIChyYW5rLT5pZW5hYmxl KSAmICh+dHIpLCByYW5rLT5pbmRleCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCByZWcgPj0g R0lDRF9JU0VOQUJMRVJuRSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2Z2ljX2VuYWJs ZV9pcnFzKHYsIChyYW5rLT5pZW5hYmxlKSAmICh+dHIpLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEVYVF9SQU5LX0lEWDJOVU0o cmFuay0+aW5kZXgpKTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBlbHNlDQo+PiArwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB2Z2ljX2VuYWJsZV9pcnFzKHYsIChyYW5rLT5pZW5hYmxlKSAmICh+dHIpLCBy YW5rLT5pbmRleCk7DQo+IA0KPiAuLi4geW91IG5vdyBoYXZlIHRvIGtlZXAgYm90aCAiaWYiIHRo ZSBzYW1lLiBVbmxlc3Mgd2UgY2FuIGhhdmUgYSANCj4gdmVyc2lvbiB0byBhdm9pZCAiaWZzIiBl dmVyeXdoZXJlIChtYXliZSB1c2luZyBtYWNyb3MpLCBJIHdvdWxkIHJhdGhlciANCj4gY3JlYXRl IGEgc2VwYXJhdGUgZnVuY2l0b24gdG8gaGFuZGxlIGVTUElzLg0KPiANCj4gQ2hlZXJzLA0KPiAN Cg0KVGhlIG1haW4gaWRlYSBvZiBWNSBvZiB0aGlzIHBhdGNoIGlzIHRvIGNvbnNvbGlkYXRlIHNp bWlsYXIgY29kZSBhbmQgDQprZWVwIHRoZSBwYWlycyBvZiByZWd1bGFyIFNQSXMgYW5kIHRoZWly IGVTUEkgY291bnRlcnBhcnRzIGluIHRoZSBzYW1lIA0KcGxhY2UgdG8gc2ltcGxpZnkgYW55IGZ1 dHVyZSBtb2RpZmljYXRpb25zIG9mIHRoZXNlIHBhaXJzLiBJZiANCmVTUEktc3BlY2lmaWMgcmVn aXN0ZXJzIGFyZSBtb3ZlZCB0byBhIHNlcGFyYXRlIGZ1bmN0aW9uLCBpdCB3b3VsZCANCnJlc3Vs dCBpbiBjb2RlIGR1cGxpY2F0aW9uLiBBZGRpdGlvbmFsbHksIEkgdGhpbmsgaXQgd291bGQgYmUg ZWFzaWVyIHRvIA0KbWlzcyB1cGRhdGluZyB0aGUgY29kZSBmb3Igb25lIHJlZ2lzdGVyIG9mIHRo ZSBTUEkvZVNQSSBwYWlyIHdoaWxlIA0KbW9kaWZ5aW5nIHRoZSBjb2RlIGZvciB0aGUgb3RoZXIu Lg0KDQpTbywgSSB3aWxsIHJldmlzZSB0aGUgY29kZSBhbmQgdHJ5IHRvIGF2b2lkIGlmcyB3aGVy ZSBwb3NzaWJsZS4NCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:30:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:30:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107192.1457706 (Exim 4.92) (envelope-from ) id 1utUq8-0001O0-KL; Tue, 02 Sep 2025 17:30:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107192.1457706; Tue, 02 Sep 2025 17:30:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utUq8-0001Nt-HX; Tue, 02 Sep 2025 17:30:40 +0000 Received: by outflank-mailman (input) for mailman id 1107192; Tue, 02 Sep 2025 17:30: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 1utUq7-0001Ni-BD for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:30:39 +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 8a7e6245-8822-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 19:30:38 +0200 (CEST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-55f691c9febso4600007e87.0 for ; Tue, 02 Sep 2025 10:30: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: 8a7e6245-8822-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756834238; x=1757439038; 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=Zq5lCFTrf27tKo4TnS8xSpAFb1/eGhmT8fSIWcjSaCE=; b=Da+FsW6tBTSxL0x2FMrNVuIR/1073uGx1UIbAhkETGXvS27VlAIX64H76d/WfywOQa 2v7lXcYA0j1QBFFb4kkTKUNH1ItGBoOQtCajot91lvypAjvMZnvAccvtBnVQHAOS35/i 4+dBLNcJRa9iEMfiszHmBTa9g7+555Or2COBcYKclf2LkY9mplKgUu5nKWxlIYwTHyIY 6Q8VoSF6RtqsTjleAFssRpiKTrly5Y+ZBfzsN3j9KWPNrWj9xDfJYuLWFDJD/hiEEvtl 1oA/Z0hyL82XsmaATCvcqEE3Qv2mnk48dCEZVxNldVAG/VZrNy5KHdVGUZAWNe+1LY5w kHiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756834238; x=1757439038; 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=Zq5lCFTrf27tKo4TnS8xSpAFb1/eGhmT8fSIWcjSaCE=; b=K8a4EEbu42UANcE+mv9NFEOaCLTuRWbaM98l/7RDqJSbFfseiyKaWWo+WzpiJbPKp5 JP+Jm27+oMS371ksIcddxBCMk6TTGlLA8+3vgYw2XA1RtJVuK/HvdsXa1KAmfwa8D8nT vvMuM9QfAxcS75SG1i5OtzfHxYLc0VCfr2BWwWS13yUPFKoCCxtNn1xEtvubzWNHmgMg +0cBK69o2/7VzAcKwJyh5+/hZ2I+rIybKrepUTUxq4rGfHX1Y40oCGk9BXTK981IpXnW zzi/9T+itHRraFjWDqWctEKfF4FOg9YIfqk7GmwchLLXJ2O1MgkUgrQa+nfdvH31QKUz iprw== X-Gm-Message-State: AOJu0YxH5rRKOJjS3bpMDHO3GbKWBkPGzzH9GbIJBBpktjN3hogtGeWB 3hgs9zW0LKydNENGsBFLckHSt0a2xbWcjaWw1s106PhcuP4bqG76qqxuRVKfzbJKv0OjibYC1hK /saDnnNQ9Jk0IcPEalcd3SZUu4rvOcoQ= X-Gm-Gg: ASbGncvdoZumLDNWDkq+T4r4b9Fy4L7pLS+pp4iMFsW9u3xpKWny2NxMLnY+I7DKwiX RHEJknPASO9nJYgTYWLpkIz6bVM5XRLWhd2GiGkxlQBuZkJ2t5MbcD+oRVolFiVbcz5D8hWZFwp pf5F3zM5yN/Z4OSuG9mQJGAIvc5blXu2yWSdp1c5nYkvKyuRLx632156ynO6RBGyrU0VS6EF3M1 Wf09LyE3mKupjS4d4c41EKXMkA= X-Google-Smtp-Source: AGHT+IHfcLomDgZv5JieRWe2MKafHlDikojt6rPO2wUqKTbYVRm+9QL/v0ODkJAKCNZEbz+G1jSbbLCvaP/qyKGJ3io= X-Received: by 2002:ac2:4bc5:0:b0:55f:3e82:9c7f with SMTP id 2adb3069b0e04-55f7099a779mr3264871e87.51.1756834237319; Tue, 02 Sep 2025 10:30:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Tue, 2 Sep 2025 20:30:25 +0300 X-Gm-Features: Ac12FXypx56Kr5JaPxUtzfhPGSYumJ8qfdUj0eiR9hUZZhaaeIGZKJq-riEMHGY Message-ID: Subject: Re: [PATCH v6 03/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Oleksandr, On Tue, Sep 2, 2025 at 7:08=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > On 02.09.25 01:10, Mykola Kvach wrote: > > Hello Mykola > > > > From: Mykola Kvach > > > > 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. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in V6: > > - Drop gicv3_save/restore_state since it is already handled during vCPU > > context switch. > > - The comment about systems without SPIs is clarified for readability. > > - Error and warning messages related to suspend context allocation are = unified > > and now use printk() with XENLOG_ERR for consistency. > > - The check for suspend context allocation in gicv3_resume() is removed= , > > as it is handled earlier in the suspend path. > > - The loop for saving and restoring PPI/SGI priorities is corrected to = use > > the proper increment. > > - The gicv3_suspend() function now prints an explicit error if ITS susp= end > > support is not implemented, and returns ENOSYS in this case. > > - The GICD_CTLR_DS bit definition is added to gic_v3_defs.h. > > - The comment for GICR_WAKER access is expanded to reference the releva= nt > > ARM specification section and clarify the RAZ/WI behavior for Non-se= cure > > accesses. > > - Cleanup active and enable registers before restoring. > > --- > > xen/arch/arm/gic-v3-lpi.c | 3 + > > xen/arch/arm/gic-v3.c | 235 ++++++++++++++++++++++++= + > > xen/arch/arm/include/asm/gic_v3_defs.h | 1 + > > 3 files changed, 239 insertions(+) > > > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > > index de5052e5cf..61a6e18303 100644 > > --- a/xen/arch/arm/gic-v3-lpi.c > > +++ b/xen/arch/arm/gic-v3-lpi.c > > @@ -391,6 +391,9 @@ static int cpu_callback(struct notifier_block *nfb,= unsigned long action, > > switch ( action ) > > { > > case CPU_UP_PREPARE: > > + if ( system_state =3D=3D SYS_STATE_resume ) > > + break; > > + > > rc =3D gicv3_lpi_allocate_pendtable(cpu); > > if ( rc ) > > printk(XENLOG_ERR "Unable to allocate the pendtable for C= PU%lu\n", > > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > > index cd3e1acf79..9f1be7e905 100644 > > --- a/xen/arch/arm/gic-v3.c > > +++ b/xen/arch/arm/gic-v3.c > > @@ -1776,6 +1776,233 @@ static bool gic_dist_supports_lpis(void) > > return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS); > > } > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + > > +/* GICv3 registers to be saved/restored on system suspend/resume */ > > +struct gicv3_ctx { > > + struct dist_ctx { > > + uint32_t ctlr; > > + /* > > + * This struct represent block of 32 IRQs > > + * TODO: store extended SPI configuration (GICv3.1+) > > + */ > > + struct irq_regs { > > + uint32_t icfgr[2]; > > + uint32_t ipriorityr[8]; > > + uint64_t irouter[32]; > > + uint32_t isactiver; > > + uint32_t isenabler; > > + } *irqs; > > + } dist; > > + > > + /* have only one rdist structure for last running CPU during suspe= nd */ > > + struct redist_ctx { > > + uint32_t ctlr; > > + /* TODO: handle case when we have more than 16 PPIs (GICv3.1+)= */ > > + uint32_t icfgr[2]; > > + uint32_t igroupr; > > + uint32_t ipriorityr[8]; > > + uint32_t isactiver; > > + uint32_t isenabler; > > + } rdist; > > + > > + struct cpu_ctx { > > + uint32_t ctlr; > > + uint32_t pmr; > > + uint32_t bpr; > > + uint32_t sre_el2; > > + uint32_t grpen; > > + } cpu; > > +}; > > + > > +static struct gicv3_ctx gicv3_ctx; > > + > > +static void __init gicv3_alloc_context(void) > > +{ > > + uint32_t blocks =3D DIV_ROUND_UP(gicv3_info.nr_lines, 32); > > + > > + /* We don't have ITS support for suspend */ > > + if ( gicv3_its_host_has_its() ) > > + return; > > + > > + /* The spec allows for systems without any SPIs */ > > + if ( blocks > 1 ) > > + { > > + gicv3_ctx.dist.irqs =3D xzalloc_array(typeof(*gicv3_ctx.dist.i= rqs), > > + blocks - 1); > > + if ( !gicv3_ctx.dist.irqs ) > > + printk(XENLOG_ERR "Failed to allocate memory for GICv3 sus= pend context\n"); > > + } > > +} > > + > > +static void gicv3_disable_redist(void) > > +{ > > + void __iomem* waker =3D GICD_RDIST_BASE + GICR_WAKER; > > + > > + /* > > + * Avoid infinite loop if Non-secure does not have access to GICR_= WAKER. > > + * See Arm IHI 0069H.b, 12.11.42 GICR_WAKER: > > + * When GICD_CTLR.DS =3D=3D 0 and an access is Non-secure acce= sses to this > > + * register are RAZ/WI. > > + */ > > + if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) ) > > + return; > > + > > + writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, w= aker); > > + while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) =3D=3D = 0 ); > > +} > > + > > +static int gicv3_suspend(void) > > +{ > > + unsigned int i; > > + void __iomem *base; > > + typeof(gicv3_ctx.rdist)* rdist =3D &gicv3_ctx.rdist; > > + > > + /* TODO: implement support for ITS */ > > + if ( gicv3_its_host_has_its() ) > > + { > > + printk(XENLOG_ERR "GICv3: ITS suspend support is not implement= ed\n"); > > + return -ENOSYS; > > + } > > + > > + if ( !gicv3_ctx.dist.irqs && gicv3_info.nr_lines > NR_GIC_LOCAL_IR= QS ) > > + { > > + printk(XENLOG_ERR "GICv3: suspend context is not allocated!\n"= ); > > + return -ENOMEM; > > + } > > + > > + /* Save GICC configuration */ > > + gicv3_ctx.cpu.ctlr =3D READ_SYSREG(ICC_CTLR_EL1); > > + gicv3_ctx.cpu.pmr =3D READ_SYSREG(ICC_PMR_EL1); > > + gicv3_ctx.cpu.bpr =3D READ_SYSREG(ICC_BPR1_EL1); > > + gicv3_ctx.cpu.sre_el2 =3D READ_SYSREG(ICC_SRE_EL2); > > + gicv3_ctx.cpu.grpen =3D READ_SYSREG(ICC_IGRPEN1_EL1); > > + > > + gicv3_disable_interface(); > > + gicv3_disable_redist(); > > + > > + /* Save GICR configuration */ > > + gicv3_redist_wait_for_rwp(); > > + > > + base =3D GICD_RDIST_SGI_BASE; > > + > > + rdist->ctlr =3D readl_relaxed(base + GICR_CTLR); > > + > > + /* Save priority on PPI and SGI interrupts */ > > + for ( i =3D 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > > + rdist->ipriorityr[i] =3D readl_relaxed(base + GICR_IPRIORITYR0= + 4 * i); > > + > > + rdist->isactiver =3D readl_relaxed(base + GICR_ISACTIVER0); > > + rdist->isenabler =3D readl_relaxed(base + GICR_ISENABLER0); > > + rdist->igroupr =3D readl_relaxed(base + GICR_IGROUPR0); > > + rdist->icfgr[0] =3D readl_relaxed(base + GICR_ICFGR0); > > GICR_ICFGR0 is for SGIs, which are always edge-triggered, so I am not > sure that we need to save it here ... Looks like I didn=E2=80=99t read the spec carefully and only paid attention= to: 12.11.7 GICR_ICFGR0, Interrupt Configuration Register 0 Determines whether the corresponding SGI is edge-triggered or level-sensiti= ve. But a few lines below it states: but a few lines below Int_config, bits [2x+1:2x], for x =3D 15 to 0 Indicates whether the is level-sensitive or edge-triggered. 0b00 Corresponding interrupt is level-sensitive. 0b10 Corresponding interrupt is edge-triggered. SGIs are always edge-triggered. > > > > + rdist->icfgr[1] =3D readl_relaxed(base + GICR_ICFGR1); > > + > > + /* Save GICD configuration */ > > + gicv3_dist_wait_for_rwp(); > > + gicv3_ctx.dist.ctlr =3D readl_relaxed(GICD + GICD_CTLR); > > + > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > > + { > > + typeof(gicv3_ctx.dist.irqs) irqs =3D gicv3_ctx.dist.irqs + i -= 1; > > + unsigned int irq; > > + > > + base =3D GICD + GICD_ICFGR + 8 * i; > > + irqs->icfgr[0] =3D readl_relaxed(base); > > + irqs->icfgr[1] =3D readl_relaxed(base + 4); > > + > > + base =3D GICD + GICD_IPRIORITYR + 32 * i; > > + for ( irq =3D 0; irq < 8; irq++ ) > > + irqs->ipriorityr[irq] =3D readl_relaxed(base + 4 * irq); > > + > > + base =3D GICD + GICD_IROUTER + 32 * i; > > + for ( irq =3D 0; irq < 32; irq++ ) > > + irqs->irouter[irq] =3D readq_relaxed_non_atomic(base + 8 *= irq); > > + > > + irqs->isactiver =3D readl_relaxed(GICD + GICD_ISACTIVER + 4 * = i); > > + irqs->isenabler =3D readl_relaxed(GICD + GICD_ISENABLER + 4 * = i); > > + } > > + > > + return 0; > > +} > > + > > +static void gicv3_resume(void) > > +{ > > + unsigned int i; > > + void __iomem *base; > > + typeof(gicv3_ctx.rdist)* rdist =3D &gicv3_ctx.rdist; > > + > > + writel_relaxed(0, GICD + GICD_CTLR); > > + > > + for ( i =3D NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i +=3D 32 = ) > > + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) = * 4); > > + > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > > + { > > + typeof(gicv3_ctx.dist.irqs) irqs =3D gicv3_ctx.dist.irqs + i -= 1; > > + unsigned int irq; > > + > > + base =3D GICD + GICD_ICFGR + 8 * i; > > + writel_relaxed(irqs->icfgr[0], base); > > + writel_relaxed(irqs->icfgr[1], base + 4); > > + > > + base =3D GICD + GICD_IPRIORITYR + 32 * i; > > + for ( irq =3D 0; irq < 8; irq++ ) > > + writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); > > + > > + base =3D GICD + GICD_IROUTER + 32 * i; > > + for ( irq =3D 0; irq < 32; irq++ ) > > + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * i= rq); > > + > > + writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLER + i * 4); > > + writel_relaxed(irqs->isenabler, GICD + GICD_ISENABLER + i * 4)= ; > > + > > + writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVER + i * 4); > > + writel_relaxed(irqs->isactiver, GICD + GICD_ISACTIVER + i * 4)= ; > > + } > > + > > + writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); > > + gicv3_dist_wait_for_rwp(); > > + > > + /* Restore GICR (Redistributor) configuration */ > > + gicv3_enable_redist(); > > + > > + base =3D GICD_RDIST_SGI_BASE; > > + > > + writel_relaxed(0xffffffff, base + GICR_ICENABLER0); > > + gicv3_redist_wait_for_rwp(); > > + > > + for ( i =3D 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > > + writel_relaxed(rdist->ipriorityr[i], base + GICR_IPRIORITYR0 += i * 4); > > + > > + writel_relaxed(rdist->isactiver, base + GICR_ISACTIVER0); > > + > > + writel_relaxed(rdist->igroupr, base + GICR_IGROUPR0); > > + writel_relaxed(rdist->icfgr[0], base + GICR_ICFGR0); > > ... and restore it here. Thank you for pointing that out. I will remove it in the next version of the patch series. > > > > + writel_relaxed(rdist->icfgr[1], base + GICR_ICFGR1); > > + > > [snip] Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:44:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:44:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107204.1457717 (Exim 4.92) (envelope-from ) id 1utV3F-0003Tu-N6; Tue, 02 Sep 2025 17:44:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107204.1457717; Tue, 02 Sep 2025 17:44:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utV3F-0003Tn-JL; Tue, 02 Sep 2025 17:44:13 +0000 Received: by outflank-mailman (input) for mailman id 1107204; Tue, 02 Sep 2025 17:44: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 1utV3E-0003Tb-5i for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:44:12 +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 6f03f3e4-8824-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 19:44:11 +0200 (CEST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-55f7b6e4145so2235812e87.1 for ; Tue, 02 Sep 2025 10:44: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: 6f03f3e4-8824-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756835051; x=1757439851; 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=jn/viCOgNFC0lTtvUQY7w4C+puM3z+1KjMHgAJ8xAL4=; b=FTmVwl9vt1AYMC1VpLQeHlhZF3213aBzG8KKbwqp/z/xNoJc0mKwepsc4xqX4nmTux h6uaUFBFoWsaHt6OsEMBk2PZltNqpVOLAlwkl7Uzx2K5mKdKIEgQzF1X/9t/hfeaQx/6 g5ORBV/seGWbs8a0MbWyNM6W6qVmeCrkr7gZeYiJNID4isi6tiMk723FgIu6MAyN3Ws+ mZ+lLaSj82crECu1sxXXCmFoxUf01tei1GuXAVVqh0ubIzsY6AwFq4jc+8APQuHvO4/r +m9FpkEIpxHuQSciCvHcCWA2qypW+gSHCACeUlzGnwdmhu2aUVRa8mPfjgYVxWhPtF0z tOoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756835051; x=1757439851; 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=jn/viCOgNFC0lTtvUQY7w4C+puM3z+1KjMHgAJ8xAL4=; b=m/JjEPLPvKYTjW1lmJB9I9nziQ+o11SLRDB2rQWZWKp4DPk24bzypqfb/pnhIgzEXo ta5LwSfY6mLz/hyPYZSDiW31+Ex/A0iaBL9eOU8mtwRCfm+iKVbU+Vbu5LGUfBpb44UD uswOgPlR4UPEgHWqZRrnNByPa4yLutgVu91HMejQLe/sGNfzZKefXOE32R5pvwE2oglG t90ofEMKIFB35/1iJdGsaEP4LKqg6kxMKWsp1ElYVateILUuJn82Rre4dD2QxFKKjz1Z Y0Ff6Ear4SL+EKZkfO+qdTzTtSeMW6H1iY6A49DQG8FYPgBBYUPifYuxKrGf+cQCXQ+g h40g== X-Gm-Message-State: AOJu0Yx9MuwHK2S44reBCBkHIupnc9ZFXlimOjh84zTXIhX7qPZO0Pa0 AxuXA2zU1BYa46lHDVlXYh0J4ggUuQwVFPF3pWLVJnZLTJFerCwFDycVRCqwKBTGimXMqjyew2W jJEwpC8jmK+qEKT60yI4ky2qvzujTRGU= X-Gm-Gg: ASbGncv8aWcDf5U+JQsyly+5ELfXKRzP3Ma30u6aIDy6T8vyossp/4V/Dh+8wn4kthR 8DmEZpu5idKhZ6ix1gUyKYkEGSJLzlUvU7lMddfQh9v3GFe/1OEAAuyuolKVO3M2XcizUt0Uwaq oA0F2f9cLov166kc2V4JxJyAf0niEV6V78bMinX55gE1E88Wm11i87vgeqMuoJ6sPCLkTbILXt9 3Jhxg== X-Google-Smtp-Source: AGHT+IG73TqjaNimC4QjloHojVsBYgWmznJdrSPuUU/471DjQJ8EKH7nk4g+9/JkRD/xVddemGACp2tz1U9kmzq0veQ= X-Received: by 2002:a05:6512:6203:b0:55f:4423:f52 with SMTP id 2adb3069b0e04-55f708ec8dbmr3245061e87.37.1756835050302; Tue, 02 Sep 2025 10:44:10 -0700 (PDT) MIME-Version: 1.0 References: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> In-Reply-To: <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> From: Mykola Kvach Date: Tue, 2 Sep 2025 20:43:59 +0300 X-Gm-Features: Ac12FXwIzD4h6VOCwZvg7vfzLS1DJ2hYUEQGaQJvY2A8ggx63NKxPpnfiVAjTY0 Message-ID: Subject: Re: [PATCH v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Oleksandr, On Tue, Sep 2, 2025 at 7:49=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > On 02.09.25 01:10, Mykola Kvach wrote: > > Hello Mykola > > > 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 > > --- > > Changes in V6: > > - Call handler->disable() instead of just setting the _IRQ_DISABLED fla= g > > - Move the system state check outside of restore_local_irqs_on_resume() > > --- > > xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > > index 6c899347ca..ddd2940554 100644 > > --- a/xen/arch/arm/irq.c > > +++ b/xen/arch/arm/irq.c > > @@ -116,6 +116,41 @@ 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; > > NIT: Please, use "unsigned int" if irq cannot be negative ok > > > + > > + spin_lock(&local_irqs_type_lock); > > + > > + for ( irq =3D 0; irq < NR_LOCAL_IRQS; irq++ ) > > + { > > + struct irq_desc *desc =3D irq_to_desc(irq); > > + > > + spin_lock(&desc->lock); > > + > > + if ( test_bit(_IRQ_DISABLED, &desc->status) ) > > + { > > + spin_unlock(&desc->lock); > > + continue; > > + } > > + > > + /* Disable the IRQ to avoid assertions in the following calls = */ > > + desc->handler->disable(desc); > > + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); > > Shouldn't we use GIC_PRI_IPI for SGIs? Yes, we should. But currently I am restoring the same value as it was before suspend... I definitely agree that this needs to be fixed at the original place where the issue was introduced, but I was planning to address it in a future patch. > > > > + desc->handler->startup(desc); > > + > > + spin_unlock(&desc->lock); > > + } > > + > > + spin_unlock(&local_irqs_type_lock); > > +} > > + > > static int cpu_callback(struct notifier_block *nfb, unsigned long act= ion, > > void *hcpu) > > { > > @@ -134,6 +169,10 @@ 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: > > + if ( system_state =3D=3D SYS_STATE_resume ) > > + restore_local_irqs_on_resume(); > > + break; > > May I please ask, why all this new code (i.e. > restore_local_irqs_on_resume()) is not covered by #ifdef > CONFIG_SYSTEM_SUSPEND? I don=E2=80=99t see a reason to introduce such "macaron-style" code. On ARM= , the system suspend state is only set when CONFIG_SYSTEM_SUSPEND is defined anyway. If you would prefer me to wrap all relevant code with this define, please let me know and I=E2=80=99ll make the change. In this case, I think the cur= rent approach is cleaner, but I=E2=80=99m open to your opinion. > > > } > > > > return notifier_from_errno(rc); > Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:46:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:46:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107218.1457727 (Exim 4.92) (envelope-from ) id 1utV5P-00040t-1t; Tue, 02 Sep 2025 17:46:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107218.1457727; Tue, 02 Sep 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 1utV5O-00040m-Vd; Tue, 02 Sep 2025 17:46:26 +0000 Received: by outflank-mailman (input) for mailman id 1107218; Tue, 02 Sep 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 1utV5N-0003ze-V3 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:46:25 +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 bf18c8a7-8824-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 19:46:25 +0200 (CEST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-55f687fd3bdso5658824e87.1 for ; Tue, 02 Sep 2025 10:46: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: bf18c8a7-8824-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756835185; x=1757439985; 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=ZM/wKtAH/uAh0FVZjh4gVX9F0y/yeEChczro5pZMJ74=; b=ONdiZXi7y55oLU5OCcmRwbFCZMwSN5BdOLeyzPgiFS4tV7tkGBqw6nu6CbNexrcXj3 kJ6Y4iv9UKT20pXhv1SlaITydIuLYqx/8jopThUE7mN4/FV4ar8GsRpvXA29YjHStamJ 4Lltvm74KrMI6YjhqYFRkKd6nDof1MxB3BPPhf7Rg4+40RDmJeU3bJOoEp9zGqkOIQRy AlaDW2WlSF0kpmx+UCCFHdtz/FbD1s3SnlyW6S/Y53LY078BRQwFXDsxeXI42O3We3KB auCe7mRRsnjn4YFrNkSqDZnmBR8Fetv8aAIfH0ugJ5VpCNq7i+LILTMiQgmeHzD3FNgf VX9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756835185; x=1757439985; 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=ZM/wKtAH/uAh0FVZjh4gVX9F0y/yeEChczro5pZMJ74=; b=Klx5IS37/k2RR0edfaJ9/bbwoUYR6hp1xRkBZmMpUHwV7MM9OkQbDO4Ka7uWn97vuj MTT7WoHwckQFchHHdDXoXVzgsiHetX+CkDl5iUsILhrtkMBAHAVpaREjM3vPGHJLhGFG VmCOBKnU8O3m1rxXDkvwHrKYFpEsuHZkACWBii8vf1pOb19YhCmaqYsP/zzBjVy8VDZ/ 972NZUcxLcAgiWzb2Rr0qxXK/hw0JJUSOjSwCwAqbg1o+OHR5RydEf/Mu84MZ7leutqv O4W3uffyeCYb05bw2faYmb/YyOg5m6JRPHkoSPjbkTs2T3Iv51qYn838UelVH5HFwHFy PblQ== X-Gm-Message-State: AOJu0YwwN8+eXj9ftjbAnDA2FfmWuZc248UKx95q48YFuK6iiW3OVA9f qjDcsZOrGCF52w6gdi1Q2bf4TN8nbBZ0vS6ui8uTzq4LnF9B0Xm/uLjw0wqLiQ2+IBt49cqvMui dmIfhZbFnwQnjeAPwkhmLpcH/bEEbTtU= X-Gm-Gg: ASbGncuigW9C5LCamFHafowd37Cr2qbVscm/rsJrtkZ5Q/mAO+agJdqAR+Pn6yy85F7 +n7zBnKva8Q7iwRr3aVrweP52dU48bMzX2D1U7HM+jBwqP8DD4ip/CxbcRTFWdUwjwTfrwA3ivY veyibcdp2ptVW6KZcflH6bAxD2wdxNYZokffonM9rixtLcNWmERqU+eYUBQcMINjTzBmfbZQney +BQPDNA96rBFphn X-Google-Smtp-Source: AGHT+IGRBZsoq0gunQOIp9dd/bzrryT5gQ0T+UsGYqgYJ8yVuIKR8bkRz6b+q43kAhvTvyvsNn01j9yGa/eTWk/B1Ok= X-Received: by 2002:a05:6512:61cb:20b0:560:87c4:e105 with SMTP id 2adb3069b0e04-56087c4e3fdmr319169e87.33.1756835184696; Tue, 02 Sep 2025 10:46:24 -0700 (PDT) MIME-Version: 1.0 References: <361a7a79-a11c-4c35-a688-0937e9d65fcf@gmail.com> In-Reply-To: <361a7a79-a11c-4c35-a688-0937e9d65fcf@gmail.com> From: Mykola Kvach Date: Tue, 2 Sep 2025 20:46:13 +0300 X-Gm-Features: Ac12FXwDIHO1Dze7SK2hINvNNjKdhVj5zSGdbrHT-DFoCTcv0_f2aiUzV53wWYo Message-ID: Subject: Re: [PATCH v6 12/13] xen/arm: Suspend/resume IOMMU on Xen suspend/resume To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh , Mykola Kvach Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Oleksandr, On Tue, Sep 2, 2025 at 8:25=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > On 02.09.25 01:10, Mykola Kvach wrote: > > Hello Mykola > > > From: Oleksandr Tyshchenko > > > > This is done using generic iommu_suspend/resume functions that cause > > IOMMU driver specific suspend/resume handlers to be called for enabled > > IOMMU (if one has suspend/resume driver handlers implemented). > > > > Signed-off-by: Oleksandr Tyshchenko > > Signed-off-by: Mykola Kvach > > --- > > Changes in V6: > > - Drop iommu_enabled check from host system suspend. > > I do not have any comments for the updated version, thanks. Thank you for your time and the review! > > > > --- > > xen/arch/arm/suspend.c | 11 +++++++++++ > > xen/drivers/passthrough/arm/smmu-v3.c | 10 ++++++++++ > > xen/drivers/passthrough/arm/smmu.c | 10 ++++++++++ > > 3 files changed, 31 insertions(+) > > > > diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c > > index 35b20581f1..f3a3b831c5 100644 > > --- a/xen/arch/arm/suspend.c > > +++ b/xen/arch/arm/suspend.c > > @@ -5,6 +5,7 @@ > > > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -62,6 +63,13 @@ static void cf_check system_suspend(void *data) > > > > time_suspend(); > > > > + status =3D iommu_suspend(); > > + if ( status ) > > + { > > + system_state =3D SYS_STATE_resume; > > + goto resume_time; > > + } > > + > > console_start_sync(); > > status =3D console_suspend(); > > if ( status ) > > @@ -118,6 +126,9 @@ static void cf_check system_suspend(void *data) > > console_resume(); > > console_end_sync(); > > > > + iommu_resume(); > > + > > + resume_time: > > time_resume(); > > > > resume_nonboot_cpus: > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passth= rough/arm/smmu-v3.c > > index 81071f4018..f887faf7dc 100644 > > --- a/xen/drivers/passthrough/arm/smmu-v3.c > > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > > @@ -2854,6 +2854,13 @@ static void arm_smmu_iommu_xen_domain_teardown(s= truct domain *d) > > xfree(xen_domain); > > } > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > +static int arm_smmu_suspend(void) > > +{ > > + return -ENOSYS; > > +} > > +#endif > > + > > static const struct iommu_ops arm_smmu_iommu_ops =3D { > > .page_sizes =3D PAGE_SIZE_4K, > > .init =3D arm_smmu_iommu_xen_domain_init, > > @@ -2866,6 +2873,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = =3D { > > .unmap_page =3D arm_iommu_unmap_page, > > .dt_xlate =3D arm_smmu_dt_xlate, > > .add_device =3D arm_smmu_add_device, > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + .suspend =3D arm_smmu_suspend, > > +#endif > > }; > > > > static __init int arm_smmu_dt_init(struct dt_device_node *dev, > > diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrou= gh/arm/smmu.c > > index 22d306d0cb..45f29ef8ec 100644 > > --- a/xen/drivers/passthrough/arm/smmu.c > > +++ b/xen/drivers/passthrough/arm/smmu.c > > @@ -2947,6 +2947,13 @@ static void arm_smmu_iommu_domain_teardown(struc= t domain *d) > > xfree(xen_domain); > > } > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > +static int arm_smmu_suspend(void) > > +{ > > + return -ENOSYS; > > +} > > +#endif > > + > > static const struct iommu_ops arm_smmu_iommu_ops =3D { > > .page_sizes =3D PAGE_SIZE_4K, > > .init =3D arm_smmu_iommu_domain_init, > > @@ -2960,6 +2967,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = =3D { > > .map_page =3D arm_iommu_map_page, > > .unmap_page =3D arm_iommu_unmap_page, > > .dt_xlate =3D arm_smmu_dt_xlate_generic, > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + .suspend =3D arm_smmu_suspend, > > +#endif > > }; > > > > static struct arm_smmu_device *find_smmu(const struct device *dev) > Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:51:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:51:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107237.1457737 (Exim 4.92) (envelope-from ) id 1utV9r-0005iu-Lf; Tue, 02 Sep 2025 17:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107237.1457737; Tue, 02 Sep 2025 17: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 1utV9r-0005im-J5; Tue, 02 Sep 2025 17:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1107237; Tue, 02 Sep 2025 17:51:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utV9q-0005ak-3u for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:51:02 +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 5c62c858-8825-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 19:50:49 +0200 (CEST) Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20) by PR3PR03MB6393.eurprd03.prod.outlook.com (2603:10a6:102:78::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 17:50:47 +0000 Received: from AM9PR03MB7025.eurprd03.prod.outlook.com ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 17:50: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: 5c62c858-8825-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=i+/kLqosCGL0a2isUuQ5ltaC4541xZLTxowTmrY7Yh88coPB9JzGzY+MV2MtKDa/Fynyo3N17DwZZFP7sJATcM4tJCAINx0lfeAnZ6nm9bXJK94SqOTkPqeXXI0SvOhkKJo9ULHfyeSoGqL6hll5dgeb/ARim6HxnVn6zyOvWFIvccOOOQep9J+HccPjbGCjH5LAnlmfCQNEVxPgog0cVdPUyeWpraW+AK8vrh7ZtY7H0/wZ1QYZAYmGPkaJzZtr/6rbLqD1hQbtOHfZRqHDJ920cfW3kMOWwqsUIU5xIh+9Mi1HWg8jzJjJrzq/jlCaw+VmL/+X1PI3YBs5ru7jFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DXGGT5mRXV753L47a+ZTuU6JasbY92eMbcTm1MoG6K8=; b=SnS7ihVdJ2WSBDOy9TgiDENxYChtfr3/M5jA+mnHOo/Ko5tcBMp9fKMT6csqvxbl1fXYPHAdTf41UGcea8ZlBhu6iZUtfC67SajRpCmDe1NZd1j0WN5iQOtK+43IPlcdXTOfbvt6247ySdVNv2KySWOBiYhMVdwvus3ehdMKDrDlYqDMqyHVx5dyrJ83W9pernp/YuB1hJwflD0IjGorgx+wwtWaAcqDyTu9TrgP7QSnA5LkUZt/Y18tMrFOn7yoBNkclArLCyjPuxM5H1zRNYejpB6TrAcmqNjJ0FyHrcsFaxCJWHeuakVx6VRXgf6qeQGou4kMMDEUK+2fifvsdg== 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=DXGGT5mRXV753L47a+ZTuU6JasbY92eMbcTm1MoG6K8=; b=THmSnQK7wqYGCLlVgxYXtRHYX1PwP49cj9IlTGLXTY/H0qwcE8k1dMnSPjcFcevTEP7baW/yQIix32LNrtzqceVjcT8bCMgu+BbO7yEjTud0tFJ7vjiuP5bcCnwitmzfydIi3mEqziMRjn7boATY8WFqmNCK93GZs76ftB+AgNyGZeu++lsXS8rYVZFCCT6CHNwPC4EfdaD7xxSALzxyXBUEEZFUrUC60P+4Zvjsjq6kc1MlnLnphL7W95sbOgCmuKJ4WIVxLaDp80hXCZwAd+/fjWFnXAVqJUVdxHj6c31wXbAlhU3VZkkAne7y7NBmD9//kdLHX5M4EqtfcYFQBw== From: Oleksandr Tyshchenko To: Julien Grall , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , "Orzel, Michal" , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Topic: [PATCH V2] xen/arm: dm: Drop XEN_DMOP_get_ioreq_server_info from supported Thread-Index: AQHcG+7h2TGQQIBGXEebyEy6VBbgNLR/rhaAgAAaygCAAARKgIAAAqcAgAAcDQCAAAofAIAANl0A Date: Tue, 2 Sep 2025 17:50:46 +0000 Message-ID: References: <20250902094931.1733774-1-oleksandr_tyshchenko@epam.com> <319c280a-535d-498a-b0ab-93882663e23b@amd.com> <4e01ed71-cdbb-4d41-8845-33449b08494b@amd.com> <8af7ca62-2f05-47d9-8604-170e7a40d8a0@xen.org> <411d7b0f-01b8-46df-9bce-929eec366d2d@epam.com> <1b79fedd-582b-4ec0-aa85-d4ae100eba1d@xen.org> In-Reply-To: <1b79fedd-582b-4ec0-aa85-d4ae100eba1d@xen.org> Accept-Language: en-US, 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: AM9PR03MB7025:EE_|PR3PR03MB6393:EE_ x-ms-office365-filtering-correlation-id: eb35ac59-a6a8-4818-65f2-08ddea493f34 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|366016|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?TisrVnp2YVpvQkV3akdYRmE0MG04NUZKbmdpUEdvaUdyVUYwUElOM2lFNHVh?= =?utf-8?B?NC9kOEVvT0xnbU9Oakp5QWZaNG9QcEZQUDd3bWNSZHZ0RTJ2MERvV2hvSDlE?= =?utf-8?B?THNOZjVoeGxVTW1ucVVBYlVpNnltUFVOQWcyeTJyNHdzWmlRTnpRQ1F2SlJx?= =?utf-8?B?UTNORE8xand1WDFpZlJJWHloQ2hJWEY0RWNXbkRQYmtWVHdvd1BtVG5FNjc3?= =?utf-8?B?T1Y4aGpBRU9JY2Y4OW5vMDk2Q1VHUDljcjhUcjFlWlFJL3NuVll4bE1PU29s?= =?utf-8?B?V0U0N3h4QUlDTjk4cGhiQTlsTXB3NmFLSkJRVUVITE1DbDhHWXV4ZE9QR0tB?= =?utf-8?B?N0YvK2wxTWdtWllpYWNmeHBMZ0greVRXMDVoYVhOOXhXT016clhvWXpCMFFR?= =?utf-8?B?REp4SGI2SndsOGJpTUlkQlYrb2FuU0d1M3JDVmU3bVZ5YWZjQ2JQa2FxdlRG?= =?utf-8?B?ZGJkKzNJbm5iQWFXWVFsL0ZPQ1lGTERrRVVTRnpSbmhBRlNuNllzMnRyc1JU?= =?utf-8?B?T2MzaFpyVDJWNytJb0h0cWVNTGlmNEVYTUpIcXU3ekMzL2l4WFRrTVNCb25u?= =?utf-8?B?aFh2NU5WTkdEMlFFRnVSMlBqSEdJVHpoMThIeGVCemgwd2JiSThXZmFFQjJ3?= =?utf-8?B?ckRVWlJEZzkvRVRhc2pzbms3bDYvT0srMkhYVlBSUm5uSFBnS0ZiWUF4c0Ir?= =?utf-8?B?bzVpcVlPemtsQ2VVMHkwSk9DRzZDVkxpZFd2bk1vTHdxeDRjcjdhdDM5ay8x?= =?utf-8?B?aVhock9PN3ZVSVhNK3FxUnhoR0tIakVSR1JRQ1NmcU9VQS9uRndFb1R2TUUz?= =?utf-8?B?dUs2TERVRm83MHNiVkY0Mk15TWY4WjlwWXh5MVZjblZ4QjZad0pNcmVlOFdL?= =?utf-8?B?VHNVbDJUSVNra3I0dUFoSFhKbFFJbEg5ME03RjZFRnZBdVNZTFBROGZFRWtL?= =?utf-8?B?TjBwekZzWWc0dStTZzI4TnZ5WVJLQ1N1ZkRXSTVRMjdFcFhsbmlWVktWU25j?= =?utf-8?B?MmdFV3N5T1VSR3V0NEdoTzJqOEJvRlg1czltSVJxN1JrUUNnSVUyZHVrUmMw?= =?utf-8?B?Yzd0ekhTNmhuaWkxZ0FUYmh3S0hycDl6NXlmakR6QVRxeGhPTzVuNGUzRU9t?= =?utf-8?B?dFYzNkt6eUx0NzdBYW8xcm42NUw1cXhvTHMrMkJxM2hrMUVsMWhlbHJGNEl2?= =?utf-8?B?NWtBNG1QcklZV1hkbE9LSVlLS21vcTVmZnpCc0NHSEc3bTRXNUJUNHNZWVY0?= =?utf-8?B?Nm1SQ1IraGhFeGY1MnE4NitBbjMra3JyQjVxSmF1THRGMUxoc2RuR3F2TlBR?= =?utf-8?B?TDZQdlVJSkl3L1VRNDVwN1FtWVd0NVp1anR5K0l6andSTHA3MUdhbkNsVXZK?= =?utf-8?B?bWEwb280S2Z0Umc5dmhTSmVlMnQ3cGFUdC9PdlB3SW1vUit0ZGVFSGFsQ0Zv?= =?utf-8?B?UUxkRC9SOXpYdHNieWhSMkg2NGh4endWK2luRS80Z1VTOHdoYk9MMEtyUVpH?= =?utf-8?B?MnRmYkpNMjZrMEpoQlQ2UGhKOVJIR3RLajVzMm8vYzlVUFFIdDJhTGkxWHBy?= =?utf-8?B?d2lFb2RCdENhc0NzSHdMNlFkS3VhNXYvMlcvUU1QVDV3bGowcjNmSjVNMzQz?= =?utf-8?B?QVJjaHcxSGM1amlUMkF0Q0tGeVhsV0R5U0ovaldwVDNpNDhQdkh5THRtR24r?= =?utf-8?B?RVBDZ1pJTDZVaE5mUWFPdHRRV3dTM3V2YVRoSGtCc3RPMzB6SytJd0E5eDgr?= =?utf-8?B?N2NnSXZJd0QxdzQwcDZmNGR3T3NGYThnd1QvVEVxUGFrZ0haZDM5ckRibG5y?= =?utf-8?B?dUlWajFta2p2M1pESFQ0bVAyTGhYNUdiaEU5R0FrS3hTWTRvQS95cVpIZyts?= =?utf-8?B?bXJiamFqTmNlam4rTkRrYndXYmRsamxRRkxXL1RtcmNkYytUUWRNSG5LTldL?= =?utf-8?B?aTBoSG1TektzL3NOZ0IyTDNCSlIzNlNDZnlwbU5zazFEY1N0dmxqL0M4czVs?= =?utf-8?B?d2gwL2I1SkxRPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?d243NFBESmt3S3J0cU8waGJBTVpkeGtZTUU3WWUwaFpJUEdrTDZwbWI4ZUd0?= =?utf-8?B?SFE4NjUxblNYYm92NkNmeGhFb1dRQTkzMTVzeXJMUElZNFdGQzV1VENjWmJw?= =?utf-8?B?Q1RvQ0lraFlXNU55UTR2bmFjT3lPa1k1RCtBem5RV0NnRW9NR0RnTllKOVVv?= =?utf-8?B?RmYwajl5a2tSdnJYNjZHTGl5MElZUkdac1BuNkpWS0NHc2Y1b3hHV1BiVm9V?= =?utf-8?B?Z0N0WVJ0T2owZGhUVTRYM0J5Q0hvZ2VOSExTNGExSnEyeTVNN2pyeHRqWlM4?= =?utf-8?B?a0VkM3JtT212elhyd3I4RVFlcU1CV1BmOVFVbTkwMFE2VDFFTEd6NkFtZmkz?= =?utf-8?B?SlRkRkFtbDhwbzlhQWI3blBXL3JQRzhIbWxyYjNWS1d5U2dkcnB3eCt2SVlK?= =?utf-8?B?SWdDYmF5eUludjE4SkhzbDBIRFo2R2piMG81Yyt5QU96Tm9kZWd1VDVzNEF5?= =?utf-8?B?SjJmdzZORmw0eU1iTXZNVG5qc0lwU3QvNEJYVzgxNmM4Z0NZd1NHa3FMOFI4?= =?utf-8?B?NVl2czRGajlHVU1KQjV6eVpHaFMxYnhYVG1ZdXZZa3lkeW15eHc3MSt3L1JS?= =?utf-8?B?MlhtZjVYQjdBcGtWZkh6bFRVL0hFN2F0YUo3VjkxcG9GTWxqSTVKWW1DQkp1?= =?utf-8?B?ZHZUVG9NQzBKbTFYaWtWdk9kbVI3dmN2VzZmZFhjMDUvdElDckdvS2ZyeUJ6?= =?utf-8?B?c2oyY0RjODlibnhlRzI5V2RLN3ZQcW01cERGVDZ5eVFmZWgrTnZ3NVIyZW1J?= =?utf-8?B?SndMWFRZZ285RVlObUV3eGRRWC9zK2RFZ1liN2JaLzlxeXFtSWZZaUdFdWZW?= =?utf-8?B?UkE2Y1RaZDhHRTdJeklmWU0xcG13Z0Fta3ZYWFdsTTVMdk9WV3diODZIS0Vs?= =?utf-8?B?a2NITnc2bkNRYVAyN3VPVWtLSUE2M29UU0xCVCt1OTAxTkYvRmNoUEt6TjJs?= =?utf-8?B?NjA1NHFJeGVHYTAvRVpJTE8yb3drUHdrMStYdmJ2VDREUGkvazBVMlNLWlR2?= =?utf-8?B?TnN1aklKZm9hV3FkbDFGSHlXOCs2MFo2U1dUcTBub0tERkdBTGV4dk9rdnN6?= =?utf-8?B?bWhnQkIrWjlmY0hjZUJFb1huakdmcUVHekJsVjh0ZktMOUIwYlRKTE9vRWVu?= =?utf-8?B?TXd6N1BqNlBqMHdaeDNJS1lpUjdaMkVldXRvOTBkTXZMVFlMUlkrK080TGto?= =?utf-8?B?OXZFTVZ6aEZ3Vk1Pc3VKY214ZFVTM2lFdERsQW1BVXhFWUJWZk11OEdXL04y?= =?utf-8?B?NVVsNzRNVHN6RVlKV1pnOVRQK2JlVFpXM3NweGdISkZXaGRPTWdsN0VFYjVR?= =?utf-8?B?RElDMUtUT2xhWE9jcnVzVTNaMGF3blAwK3puOERJUngvZkN6UUNraFlENHcx?= =?utf-8?B?SE5WUnZhWCtKT2xuYlpZaUVHTkMxRjF4eEgyeEk4WmtJY0tIVFhxdFJOZjBQ?= =?utf-8?B?K2RlbWVjZlhHdFN3K1A0Z0svWThNL0tmeE8rbUpQelpQeHFNdDYyOW5JTzZK?= =?utf-8?B?NDdtKzVJOEJ5c0lBUFJOWFBMVXFVbXNtaWllU0U5cERWUi9URmxMWHkveFRX?= =?utf-8?B?ZkFzWncrWkxZUm1TWHdESjVmVFBxTXJTUEx3MlJxNjR2d0IyRnR4UWlmckY0?= =?utf-8?B?ZGI5UmRlbUsrNnExV0lhTjNvY1A0cmJwWmVySDB6ZFl0NEg5MmRLVWQxSlF1?= =?utf-8?B?QUN6bHhVVzNZa3JFS0o1cW0yMndaUTB2ejBaRmwxWUl6aDR1L1dWYmNCcDZB?= =?utf-8?B?RGFsY1dXcHVOSys3MGFxZVV1WmV5RzJLUG00T0xFZm5QaXVMandDakZBUG9T?= =?utf-8?B?cTZJM1BkVjA2SG5DTGo1RjZuOTB1b1lqRnF1QWhHWmFmNmlWYVJHMlJkK1pF?= =?utf-8?B?eW12cnJCeDBwcWtHTkdndHE0ZFk0NHpPWE11WXhPTjg4R3NmcUhTdEIwWDU0?= =?utf-8?B?Mnh1WjVZYTloUjAxWVBaSXNnbmRxMmtLajlMYjcwYlQrSUxlZDlhK0hPTVdV?= =?utf-8?B?K1lFVG0xK3ROdm02WkIySjFsZ1VmL2lzcHNtSGpUQXpqUmQrMWpQeFYvSlpt?= =?utf-8?B?Mzh6bTJUaTA3VnVVZ054cFVtYlRjVDFaMFNoeW5VMkhXeElXMCtjcktsSlB6?= =?utf-8?B?WnNZT2Urd0wyUWk2ejJieEU4NjFGZVo2MlI5TVVqVEVTZGd5UUh6aXZqN0tz?= =?utf-8?Q?Qr55X+N2FrVa0dh2yeSKzXg=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <13E56CDFED767745994D5E093653CF49@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: AM9PR03MB7025.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb35ac59-a6a8-4818-65f2-08ddea493f34 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 17:50:46.9681 (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: 4EGw0nasy1GBe4b+YVnG9AHVseOOU5qcHOLbhlRemtnfIoZdu450TgVcWR2Uiok7vwRNme39EfSH7pGbC3BdEmGhzcvKmZC+fYGPaiMJ9QI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6393 DQoNCk9uIDAyLjA5LjI1IDE3OjM2LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIE9sZWtzYW5k ciwNCg0KSGVsbG8gSnVsaWVuDQoNCj4gDQo+IE9uIDAyLzA5LzIwMjUgMTU6MDAsIE9sZWtzYW5k ciBUeXNoY2hlbmtvIHdyb3RlOg0KPj4NCj4+DQo+PiBPbiAwMi4wOS4yNSAxNToxOSwgSnVsaWVu IEdyYWxsIHdyb3RlOg0KPj4NCj4+IEhlbGxvIEp1bGllbg0KPj4NCj4+PiBPbiAwMi8wOS8yMDI1 IDEzOjEwLCBPcnplbCwgTWljaGFsIHdyb3RlOg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAwMi8wOS8y MDI1IDEzOjU0LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+Pj4+PiBIaSwNCj4+Pj4+DQo+Pj4+PiBP biAwMi8wOS8yMDI1IDExOjE4LCBPcnplbCwgTWljaGFsIHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+PiBPbiAwMi8wOS8yMDI1IDExOjQ5LCBPbGVrc2FuZHIgVHlzaGNoZW5rbyB3cm90ZToN Cj4+Pj4+Pj4gVGhlIHNhaWQgc3ViLW9wIGlzIG5vdCBzdXBwb3J0ZWQgb24gQXJtLCBzaW5jZSBp dDoNCj4+Pj4+Pj4gwqDCoMKgIC0gZG9lcyBub3Qgc3VwcG9ydCB0aGUgYnVmZmVyZWQgZW11bGF0 aW9uIChzbyBidWZpb3JlcV9wb3J0Lw0KPj4+Pj4+PiBidWZpb3JlcV9nZm4NCj4+Pj4+Pj4gwqDC oMKgwqDCoCBjYW5ub3QgYmUgcmV0dXJuZWQpLCBwbGVhc2UgcmVmZXIgdG8gaW9yZXFfc2VydmVy X2NyZWF0ZSgpDQo+Pj4+Pj4+IMKgwqDCoCAtIGRvZXMgbm90IHN1cHBvcnQgImxlZ2FjeSIgbWVj aGFuaXNtIG9mIG1hcHBpbmcgSU9SRVEgU2VydmVyDQo+Pj4+Pj4+IMKgwqDCoMKgwqAgbWFnaWMg cGFnZXMgKHNvIGlvcmVxX2dmbi9idWZpb3JlcV9nZm4gY2Fubm90IGJlIHJldHVybmVkKSwNCj4+ Pj4+Pj4gcGxlYXNlDQo+Pj4+Pj4+IMKgwqDCoMKgwqAgcmVmZXIgdG8gYXJjaF9pb3JlcV9zZXJ2 ZXJfbWFwX3BhZ2VzKCkuIE9uIEFybSwgb25seSB0aGUgDQo+Pj4+Pj4+IEFjcXVpcmUNCj4+Pj4+ Pj4gwqDCoMKgwqDCoCBSZXNvdXJjZSBpbmZyYXN0cnVjdHVyZSBpcyB1c2VkIHRvIHF1ZXJ5IGFu ZCBtYXAgdGhlIElPUkVRDQo+Pj4+Pj4+IFNlcnZlciBwYWdlcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g U2lnbmVkLW9mZi1ieTogT2xla3NhbmRyIFR5c2hjaGVua28gPG9sZWtzYW5kcl90eXNoY2hlbmtv QGVwYW0uY29tPg0KPj4+Pj4+IFJldmlld2VkLWJ5OiBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnpl bEBhbWQuY29tPg0KPj4+Pj4+DQo+Pj4+Pj4gQ291bGQgd2UgcGVyaGFwcyBhZGQgYSBGaXhlcyB0 YWcgaGVyZSBwb2ludGluZyB0byB0aGUgY29tbWl0DQo+Pj4+Pj4gaW50cm9kdWNpbmcgdGhlc2UN Cj4+Pj4+PiBETSBvcHMgYW5kIHRodXMgYWRkIHRoaXMgcGF0Y2ggZm9yIHRoaXMgcmVsZWFzZT8g Tm90IHN1cmUgd2hhdA0KPj4+Pj4+IG90aGVycyB0aGluay4NCj4+Pj4+DQo+Pj4+PiBGaXhlcyB1 c3VhbGx5IGltcGxpZXMgYSBidWcgYW5kIEkgZG9uJ3Qgc2VlIHdoYXQgYnVnIHdlIGFyZSANCj4+ Pj4+IHNvbHZpbmcuIEluDQo+Pj4+PiBmYWN0LCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHdlIGFy ZSB0cnlpbmcgdG8gcmVtb3ZlIHRoZSBzdWJvcC4uLg0KPj4+PiBIbW0sIHRoZSBpc3N1ZSBpcyB0 aGF0IHRoZSBzdWJvcCB0aGF0IGlzIG5vdCBzdXBwb3J0ZWQgYXQgdGhlIG1vbWVudA0KPj4+PiBp cyBsaXN0ZWQNCj4+Pj4gYXMgc3VwcG9ydGVkIGluIHRoZSBwdWJsaWMgaGVhZGVyLg0KPj4+DQo+ Pj4gWy4uLl0NCj4+Pg0KPj4+PiBBcyBmb3IgdGhlIGNvZGUsIGZyb20gc2FmZXR5IHBlcnNwZWN0 aXZlIGlmIHRoaXMgc3Vib3AgaXMgbGlzdGVkDQo+Pj4+IGV4cGxpY2lsdHkgaW4gQXJtJ3MNCj4+ Pj4gZG0uYywgd2Ugd291bGQgbmVlZCB0byB3cml0ZSBhIHNlcGFyYXRlIHRlc3QgY2FzZSBhbmQg dGVzdCB0byBjb3ZlciBpdA0KPj4+PiB0aGF0IGF0DQo+Pj4+IHRoZSBlbmQsIHN0aWxsIHJldHVy bnMgLUVPUE5PVFNVUFAuDQo+Pj4NCj4+PiBXaHkgZG8geW91IHRoaW5rIGl0IGlzIG5vdCBzdXBw b3J0ZWQ/IEFGQUlDVCwgaXQgaXMgc3RpbGwgcG9zc2libGUgdG8NCj4+PiBwYXNzIFhFTl9ETU9Q X25vZ25mcyB0byBmaWd1cmUgb3V0IHdod2V0aGVyIGJ1ZmlvcmVxIGlzIGN1cnJlbnRseQ0KPj4+ IGF2YWlsYWJsZS4gVGhlIGVycm9yIGNvZGUgd291bGQgYmUgMCBub3QgLUVPUE5PVFNVUFAuDQo+ Pg0KPj4NCj4+IFllcywgYnkgcGFzc2luZyBYRU5fRE1PUF9ub19nZm5zIHdlIHdpbGwgYnlwYXNz DQo+PiBhcmNoX2lvcmVxX3NlcnZlcl9tYXBfcGFnZXMoKSBjYWxsLCBhbmQgeWVzLCBpb3JlcV9z ZXJ2ZXJfZ2V0X2luZm8oKQ0KPj4gd2lsbCByZXR1cm4gMCBpbiB0aGF0IGNhc2UuDQo+Pg0KPj4g QnV0LCAiYnVmaW9yZXFfcG9ydCIgZmllbGQgaW4gc3RydWN0IHhlbl9kbV9vcF9nZXRfaW9yZXFf c2VydmVyX2luZm8NCj4+IChvdXQgcGFyYW0pIHdvbid0IGJlIHJlYWxseSB1cGRhdGVkIChzaW5j ZSB0aGUgSU9SRVEgU2VydmVyIHdhcyBjcmVhdGVkDQo+PiB3aXRoIEhWTV9JT1JFUVNSVl9CVUZJ T1JFUV9PRkYgYmVmb3JlIHRoYXQpLg0KPiANCj4gU3VyZS4gQnV0IHRoaXMgd291bGQgYmUgdGhl IHNhbWUgYmVoYXZpb3Igb24geDg2LCByaWdodD8gDQoNCnNlZW1zIHNvLCB5ZXMNCg0KSWYgc28u Li4NCj4gDQo+Pg0KPj4gU28sICJhdCB0aGUgbW9tZW50IiwgWEVOX0RNT1BfZ2V0X2lvcmVxX3Nl cnZlcl9pbmZvIHN1Yi1vcCBpcw0KPj4gbm9uLWZ1bmN0aW9uYWwvdXNlbGVzcyBvbiBBcm0gKCJ1 bnN1cHBvcnRlZCIgaXMgcHJvYmFibHkgbm90IGEgcHJlY2lzZQ0KPj4gd29yZCBpbiB0aGF0IHBh cnRpY3VsYXIgY2FzZSksIHRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZyAod2hpY2ggbWlnaHQgYmUN Cj4+IHdyb25nKS4gVGhhdCBpcyB3aHkgSSBoYXZlIHNlbnQgYSBwYXRjaCB0byByZW1vdmUgdGhl IG1lbnRpb24gZnJvbSB0aGUNCj4+IHB1YmxpYyBoZWFkZXIuDQo+IC4uLiBJIHN0aWxsIGRvbid0 IHVuZGVyc3RhbmQgd2h5IHdlIGFyZSBqdXN0IHRyeWluZyB0byBzd2VlcCB0aGUgcHJvYmxlbSAN Cj4gdW5kZXIgdGhlIHJ1ZyBvbiBBcm0uDQo+IA0KPiBUaGF0J3MgYXNzdW1pbmcgdGhlcmUgaXMg b25lLiBJZiB0aGVyZSBpcyBhIHByb2JsZW0sIHRoZW4gd2Ugc2hvdWxkIGZpeCANCj4gaXQgcHJv cGVybHkgZm9yIGFsbCBhcmNoaXRlY3R1cmVzLiBJZiB0aGVyZSBpcyBubyBwcm9ibGVtLCB0aGVu IHRoaXMgDQo+IHBhdGNoIHNob3VsZCBub3QgZXhpc3RzLg0KDQpJIHRoaW5rLCBJIGdvdCB5b3Vy IHBvaW50LiBMZXQncyBpZ25vcmUgdGhlIGN1cnJlbnQgcGF0Y2guDQoNCg0KPiANCj4gQ2hlZXJz LA0KPiANCg== From xen-devel-bounces@lists.xenproject.org Tue Sep 02 17:56:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 17:56:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107249.1457746 (Exim 4.92) (envelope-from ) id 1utVEe-0006S8-7K; Tue, 02 Sep 2025 17:56:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107249.1457746; Tue, 02 Sep 2025 17:56: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 1utVEe-0006S0-48; Tue, 02 Sep 2025 17:56:00 +0000 Received: by outflank-mailman (input) for mailman id 1107249; Tue, 02 Sep 2025 17:55: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 1utVEc-0006Ru-Cv for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 17:55:58 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 13eb5c46-8826-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 19:55:57 +0200 (CEST) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61cc281171cso9703511a12.0 for ; Tue, 02 Sep 2025 10:55: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: 13eb5c46-8826-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756835757; x=1757440557; 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=JeMCaETJ15KlQOb/LFepnWLSIdng3W6/qh/WhqmNexM=; b=AC4ZmdjUcK633nQ1mONIF5EkgO1iMo5eWn9AxWtR/eV9WOAOSFked55HKGhARIGbs1 kpE6X2U+O3FIgB0MUf0NmZb74UTjI2vHCQ2vxtdN98caNdPnrVa1rJANkUUdlwNF7nal 8OZio6Gy6Gu9yTGRq3nuTCrdzcWc/5Jqd7pzEyt2Rk2WQuCYEiOp7cA2PzUVDHGL1wrg UQNpz8d+hwomP1Wtg0Ntne+r84kDHEitjsOBYFjTcHdZB4nuAeNfECq50TmyUX4ZdBjB wBOnFYTEQ93jPlbUGSTiRetpVeTAcAS9sfhaRtEaGztE8xEbJMeGg8cOElGUh5AxTHjV /BVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756835757; x=1757440557; 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=JeMCaETJ15KlQOb/LFepnWLSIdng3W6/qh/WhqmNexM=; b=t5tnSLKtbU5JEJrhkds7Te2+TrnceNd5cYuRt2tbAPIJG1QyykdZi4t4sQ+Fg3p507 RrBORn9SuPQmGodxn7P4Xq9Dx9PhhauGddKwTOfp7Ak2O118H1TapCVPGlyPt8nc81zr ++9ma1T4c2U/uRfekQgrx6UEqGrSc28qBn+tAhIBOCRjiFilR4i3sSi4tCb9NeemdakO R3TrlbH9FBzMgt3qBxj/yoCj0E+NtEN2cv1yGX2Zbl8Z6nckbR3C6baHiGxhS1nmrd/t H0L/TAYLb+jLHNi11ExiTWwOHM7lUFrCbVokZ2JG9pN+tHza6xsRj2V/jDx78KYr8E1A wkRw== X-Forwarded-Encrypted: i=1; AJvYcCU8+eGqZQXHaSgLB7Aj1W8WtjlglpsE3aByl7VLQ1PetX5xjZ72DxNTKu7gdA4KuLtiRu+NPHp9lnU=@lists.xenproject.org X-Gm-Message-State: AOJu0YyoVU1Q9l1hkp+1ZimMt6+BXtjftADlEluuzEqyesrY9ieXp5zW z5vLGpmHk1vRho0csWDNn8jc/inaevzjiJuPzsGnjEgu+EXVG6tuMl8e0Qpc84nXbkFLIqipXir Jz+IasASJ1QBXeCbsp1blZof4hu1tIOc= X-Gm-Gg: ASbGncv6TtixTyXMcdP/n99qPYxEu79AqDw8t6qAW67toltpIpZzEXeJtaEbbDcj3TZ KnU6UQJumnqSWFSP52sAp03IQn+sTZDk9DLq8Eq1QsJNh/TrbqrgfcPMf6Anyl8vgY2+5Gv1uOO r0/b39NzyrGis64p4JTjBd7v/U1H6ZXlycJ0QfX230RQj50crMcCZHN0bmiE4GKf0UT6TfpEdsD QZiQfwRXZTrm6fa X-Google-Smtp-Source: AGHT+IG8/mV0QClmH5H974Y8oFMA2swgFkMVmgsAGfjaIWB2yNIx/lmnxm3KrPpD6j032qrrH5Z9lfILnMsODUkiiN8= X-Received: by 2002:a05:6402:5216:b0:61d:2405:b4a9 with SMTP id 4fb4d7f45d1cf-61d26d9143dmr10325248a12.17.1756835756638; Tue, 02 Sep 2025 10:55:56 -0700 (PDT) MIME-Version: 1.0 References: <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com> <28e78684-ff7b-4902-89cd-c341ba236d57@suse.com> In-Reply-To: <28e78684-ff7b-4902-89cd-c341ba236d57@suse.com> From: Mykola Kvach Date: Tue, 2 Sep 2025 20:55:45 +0300 X-Gm-Features: Ac12FXxuRuM-7Bz8QE4tJc92lRUsbKSJR6i5zA_q1DBKTVQeWU1VXZtDLiIaDYI Message-ID: Subject: Re: [PATCH v13 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Jan Beulich Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 6:43=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2025 11:03, Mykola Kvach wrote: > > --- > > xen/arch/arm/domain.c | 37 ++++++++ > > xen/arch/arm/include/asm/domain.h | 6 ++ > > xen/arch/arm/include/asm/perfc_defn.h | 1 + > > xen/arch/arm/include/asm/psci.h | 2 + > > xen/arch/arm/include/asm/suspend.h | 18 ++++ > > xen/arch/arm/include/asm/vpsci.h | 5 +- > > xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- > > xen/common/domain.c | 9 ++ > > xen/include/xen/domain.h | 11 +++ > > 9 files changed, 183 insertions(+), 22 deletions(-) > > create mode 100644 xen/arch/arm/include/asm/suspend.h > > Note, btw, how this way you won't need x86, ppc, and riscv acks. Thanks for suggesting this approach. Hopefully, the other stub functions can be updated in a similar manner. > > > --- a/xen/include/xen/domain.h > > +++ b/xen/include/xen/domain.h > > @@ -8,6 +8,10 @@ > > > > #include > > > > +#if __has_include() > > +#include > > +#endif > > + > > struct guest_area { > > struct page_info *pg; > > void *map; > > @@ -109,6 +113,13 @@ int arch_domain_soft_reset(struct domain *d); > > > > void arch_domain_creation_finished(struct domain *d); > > > > +#if !__has_include() > > +static inline int arch_domain_resume(struct domain *d) > > +{ > > + return 0; > > +} > > +#endif /* !__has_include() */ > > + > > void arch_p2m_set_access_required(struct domain *d, bool access_requir= ed); > > > > int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c); > > Imo it would be preferable to have such in a single #if/#else. There's no= thing > wrong with an #include not sitting at the very top. I understand that includes can be placed near where something from the header is used. However, I find it more natural to keep them together in a single location. > > (Another question is whether to put this in xen/domain.h at all. There co= uld > be a xen/suspend.h having - for now at least - just this and nothing else= .) With this approach, I don=E2=80=99t need to move the include to the middle = of the file. > > Jan Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 18:16:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 18:16:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107267.1457756 (Exim 4.92) (envelope-from ) id 1utVYI-0001MO-NU; Tue, 02 Sep 2025 18:16:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107267.1457756; Tue, 02 Sep 2025 18:16:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utVYI-0001MH-K2; Tue, 02 Sep 2025 18:16:18 +0000 Received: by outflank-mailman (input) for mailman id 1107267; Tue, 02 Sep 2025 18:16:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utVYH-0001MB-NB for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 18:16:17 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ea00ec09-8828-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 20:16:15 +0200 (CEST) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-45b8b25296fso18564045e9.2 for ; Tue, 02 Sep 2025 11:16:15 -0700 (PDT) Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3dcc19a386dsm118818f8f.4.2025.09.02.11.16.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 11:16: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: ea00ec09-8828-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756836975; x=1757441775; 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=SqMHAPMH4OTCuEp6LUw0NE0Zc7xhyAwnJYqEI+MXBxc=; b=EJ2JCwfcWItLUt/UmG3StAzcicecDRT8ET1FVeoZG8dRbxzCaDJ+frx//QM2oyIbO0 CmUJQ8wRqAD9+i3NzKIE2QXMAD3MYIuzVmo75NWWaJzyN8t1OOIHg2WB2Rigf6tsWx7r F7GS+ZupLi9jiIBUgiafCwUOyAXjll5XMRTInECwJinHCIVE5sxuNRqwwViUkCvOwhrJ Xp1QV7z2a+dQ4ip/dSKUtvI1fWei4GFj09hMVfJT6BdJgeRzhg2DeRC1z3iWfkkkCk+/ D/GuC+fMO9pd/e9hXB51DcYbEbUsoutHisdRK40N86eDqHv3A0XAj0rBUZ77maGU9EHd 3+7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756836975; x=1757441775; 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=SqMHAPMH4OTCuEp6LUw0NE0Zc7xhyAwnJYqEI+MXBxc=; b=iUyPW65Kva6cP7TyrlnfAEa3VBkoVz8xyxnEH+dT1wV+mXc03MuSo8XMZbMQJ6Axy9 1As3NzYh+YXYRG1/A2WXpEvyTYW1wt7h1vZHEc6bhGwR7ANN7fzHzDSjsypi+OQbs8ty 8Jz5K7Un+v95QioSMDQpuYrBiGgorDN8frHVEkEXkOvFCa9TX7YqK9KfpV6n7W2eD3b5 JYeF/d1YHQkeWAVuyRBdhQETq7jjV+5X8LvYNTNyaRCTUwPcI25GKPwgA/dNUERXV8ne MWxmHh7OFoU6Vl7YjyyRQEN7WSDczRablUw0nwW5fKm0jQOPrk1D5bCBNhWpqlej/Hov U2bw== X-Gm-Message-State: AOJu0Yy1p6Iyi2TSPUfKMv2NI4lda/7lHwY2eYWOmUJAoQp86N1X/2/x mQ3HRDh6toobR4bAegRPKf1ZHeuRQuJFgx0DXP8IF6KZ1Dwtp6i2STNE X-Gm-Gg: ASbGncuw/dgpU0Kd18IwsIbYKq+1Lwnka+dsHH6xA2UdVZdimjpGbgsJ6twGw3J810K sYiCFQkwPsV8yQGMDh06TUWVV61naG2TR+t+uDQdNBwHEwAoAzKRl5b01OQDJZf0YoRMHfqGf8E iwk5POmVcSdzdkbVUjeZ18TNycdxfgFwVxDvGvJfF3B7znviBn2C/XxORMI7VhozQCW05KysH42 lgBiOOKJXq98DmmLmlCitsFUpiuQhKuMSCAggvoB+Y+UsSvLPkElqNjhbkkDPi3n15FQlJtOcA9 IByiXK3g/0hRTGt2ClHO8N+3hXGvTpkR++bICatJIJebQTe8kr5MrOfYlfSh9/zr6IVRsYfEPDi /3oueJjI15yhogzKShdK92H/my5P7UWeDWUkxUxNT1Y3kjMAtR6lPPPY= X-Google-Smtp-Source: AGHT+IHN/azAid88EWGaKIY1h1/du7XllgDOPyRwqW5NXSxwfALXCk4Zpr321+MfGwM1Mu2Wl53bDA== X-Received: by 2002:a05:6000:2207:b0:3cd:e63a:cfd5 with SMTP id ffacd0b85a97d-3d1e07a4cc1mr9205899f8f.56.1756836974674; Tue, 02 Sep 2025 11:16:14 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2025 21:16:13 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume To: Mykola Kvach Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02.09.25 20:43, Mykola Kvach wrote: > Hi Oleksandr, Hello Mykola > > On Tue, Sep 2, 2025 at 7:49 PM Oleksandr Tyshchenko wrote: >> >> >> >> On 02.09.25 01:10, Mykola Kvach wrote: >> >> Hello Mykola >> >>> 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 >>> --- >>> Changes in V6: >>> - Call handler->disable() instead of just setting the _IRQ_DISABLED flag >>> - Move the system state check outside of restore_local_irqs_on_resume() >>> --- >>> xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 39 insertions(+) >>> >>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c >>> index 6c899347ca..ddd2940554 100644 >>> --- a/xen/arch/arm/irq.c >>> +++ b/xen/arch/arm/irq.c >>> @@ -116,6 +116,41 @@ 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; >> >> NIT: Please, use "unsigned int" if irq cannot be negative > > ok > >> >>> + >>> + 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; >>> + } >>> + >>> + /* Disable the IRQ to avoid assertions in the following calls */ >>> + desc->handler->disable(desc); >>> + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); >> >> Shouldn't we use GIC_PRI_IPI for SGIs? > > Yes, we should. But currently I am restoring the same value > as it was before suspend... > > I definitely agree that this needs to be fixed at the original > place where the issue was introduced, but I was planning to > address it in a future patch. > >> >> >>> + 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) >>> { >>> @@ -134,6 +169,10 @@ 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: >>> + if ( system_state == SYS_STATE_resume ) >>> + restore_local_irqs_on_resume(); >>> + break; >> >> May I please ask, why all this new code (i.e. >> restore_local_irqs_on_resume()) is not covered by #ifdef >> CONFIG_SYSTEM_SUSPEND? > > I don’t see a reason to introduce such "macaron-style" code. On ARM, the > system suspend state is only set when CONFIG_SYSTEM_SUSPEND is defined > anyway. right > > If you would prefer me to wrap all relevant code with this define, please > let me know and I’ll make the change. In this case, I think the current > approach is cleaner, but I’m open to your opinion. In other patches, you seem to wrap functions/code that only get called during suspend/resume with #ifdef CONFIG_SYSTEM_SUSPEND, so I wondered why restore_local_irqs_on_resume() could not be compiled out if the feature is not enabled. But if you still think it would be cleaner this way (w/o #ifdef), I would be ok. > >> >>> } >>> >>> return notifier_from_errno(rc); >> > > Best regards, > Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 02 18:53:16 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 18:53:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107293.1457777 (Exim 4.92) (envelope-from ) id 1utW81-00076l-Nf; Tue, 02 Sep 2025 18:53:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107293.1457777; Tue, 02 Sep 2025 18:53:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utW81-00076e-Kx; Tue, 02 Sep 2025 18:53:13 +0000 Received: by outflank-mailman (input) for mailman id 1107293; Tue, 02 Sep 2025 18: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 1utW80-0006sm-7F for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 18:53:12 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2060a.outbound.protection.outlook.com [2a01:111:f403:2412::60a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 122ebfdd-882e-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 20:53:11 +0200 (CEST) Received: from CYXPR03CA0016.namprd03.prod.outlook.com (2603:10b6:930:d0::24) by MW6PR12MB8836.namprd12.prod.outlook.com (2603:10b6:303:241::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 18:53:07 +0000 Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com (2603:10b6:930:d0:cafe::56) by CYXPR03CA0016.outlook.office365.com (2603:10b6:930:d0::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.16 via Frontend Transport; Tue, 2 Sep 2025 18:53:06 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Tue, 2 Sep 2025 18:53:06 +0000 Received: from satlexmb10.amd.com (10.181.42.219) 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, 2 Sep 2025 13:53:02 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Tue, 2 Sep 2025 11:53:02 -0700 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; Tue, 2 Sep 2025 13:53: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: 122ebfdd-882e-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=br0eaAFscp7noKkmjN0mjv3Bc/BGcmgsKo9+eEi8GqP29uf0Qe6hzLaSU2sePR6u7zGFHP1P23ilXbaGppu70+LCMpkLsDBRWIH4u9R5eM1x3bkkLkynLWAOSX5Lm4SxxV1M2H1sMOJ7PQQsuYTj47b6vZLp0ky/686mNWJinGGPhIHAiAf0gVk80WI1Fr0B1RY3EMa3l/p7AgFnxsCcpKXh2x1ZXFwft6205TMeY3KNE9hRrINoEeig6ePGqp0RbGf2fJgUGYQ9Uh05eh/I1YLaGGcHbcPEghuk2r8QvohJFEEF2997GRmz/0pokbma+OzjD3K/SrzQws4Y95Exxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=m6yCb7W2Cm2FwrxRUKS4GH+23hZoJ5wJ30wTXxrEdLA=; b=ict2SfU6Le/Ow0d2Mc9Z/gI3vCKcapBXSDZtHa1iOpZaZd6tmZIjl2kQBbiJI013ax2f/OtMmvIRndAvLbryVBt7OpXtK6TDwy475q8KsN4x+Sa5hR8IZlWcjtUMbA5MGSfJHTq9sbMp/KNK6FZn8F4c/JA6u84bIYdikN1/MIxaVx3B/p+QKOAzy1CuBtX46Gdbrxzeal0k4iBQxWISwPJimIHcfY3o39AnzRKCDvADec6MhQfzp3YgJZV5x/hK88GnbemBApoRA17mggnO9t5IV6NqArh8XzzlQuBxJ3Zvg6yrzffJnRQXF+S97n/+pshjU6qrseScDQXv9nLI3A== 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=m6yCb7W2Cm2FwrxRUKS4GH+23hZoJ5wJ30wTXxrEdLA=; b=Q1hZ8T/JzZtUObUD6ycGlzOvZOeV7h7OQSifkNN673ZIFVfPCjJJqHDg/j2llw28hMt29ePe+x+lDJql2iNRGjI6ViuNf3e8JEx6hwkJs2oFRlMTF8BzNa9M772MCNW/S8OYsXk7IKaZnCj+LToIOXGbmPTH3HanBBoKihMIIQk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Victor Lira , Doug Goldstein , Stefano Stabellini Subject: [PATCH v1 2/2] automation: edit expect script to separate error message lines Date: Tue, 2 Sep 2025 11:52:35 -0700 Message-ID: X-Mailer: git-send-email 2.50.GIT In-Reply-To: <729708b7e6c1815e7ba9b712f6c847e0a0374fd9.1756834803.git.victorm.lira@amd.com> References: <729708b7e6c1815e7ba9b712f6c847e0a0374fd9.1756834803.git.victorm.lira@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D2:EE_|MW6PR12MB8836:EE_ X-MS-Office365-Filtering-Correlation-Id: 3ad6e037-cd66-4601-bf92-08ddea51f3f6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?xoQHesoGw7cSA6WBj6NC/WsQFVSN3nWJsjb8cXitsVQlSVQrbAMv2201+sMP?= =?us-ascii?Q?3DTDcr4RUV46O6ezRrOM3dIHtcSgEin5OGNJgp7ofEVaDa6+A7PjxHDxoOgW?= =?us-ascii?Q?HVrJaCW9QCYmuKUmPw1sti+k1RrlJuMi30Gz3jt9s3vuS+n8kYYU+U/vNqxK?= =?us-ascii?Q?VdBYL9IeEzzIgOqmvRu7KT3D8BUQafpP+vdSS3pleKenhNrCf+nELUP2v/an?= =?us-ascii?Q?tvWxtdzYg8h0o8pVhEeOY7vJmdl1Ir1p0Ydc+Tw9VeJHGFW1SHf8pErJLNT3?= =?us-ascii?Q?e6Wc2T7UMO1GTBMMVN2HOu4YsgAs1q06n0ohn6UUHc/jgYsttxh+SQcv3d2r?= =?us-ascii?Q?mqTxj1rDMAEemGdxrVCWXCNwb07Pef43QL6CMJUIL9RdrRntsrNgK/6xJOG2?= =?us-ascii?Q?z725CY7J8pKinoloVv6N1tUC54BppuXvvp30vwbAOUsQMeVVFUV/LpLQvtIW?= =?us-ascii?Q?f+MVlMeYwxluqqqGq4avxnkOnjv93Oxqq+khyL9PTIX8vIvXX7jhK3SukDIb?= =?us-ascii?Q?wbrD8wITqCaI3h8OcTIroEIMXqKp5szPEi9D0A4hPUrI1ZObenK1UITik2A5?= =?us-ascii?Q?xBcBkZC14jo2FqFF7WmxldYGPvowu9zAux/ci1BkUkCvb5P1vdOi2UG2N4/L?= =?us-ascii?Q?HyJgoALR/I05mRgLOTG9cnAoEKSdphnZW2NiSz2DeUgMFJv1OqXfRPPku8zE?= =?us-ascii?Q?fSoUchcIC65F3FKJ5IDOFZ/K6gugzNXhChvEFiLuD3FaQF9/pXjtaYuZt2Lh?= =?us-ascii?Q?HI8wMv4TL+FZHwlk+Sv4mDlhq/TlmOQLTqt3uaWy0zHG9oWUrHn2oLAlB6Mi?= =?us-ascii?Q?BcdTri0YBVkJbgNJlN+Pa/qkMIMrzmKO4qkab/tcoS/hyHTcCtk3OZVMnu1J?= =?us-ascii?Q?w6GnLB+NzrujlMi3+Q05RsGPmJo9DR2hvRT9ZaJcE8ZWZTzSP7GSVNmS4gXa?= =?us-ascii?Q?vP7YQ25TNOEcqQT6Z2v/J0eZmDYZddV3iT8UtdvVUxUxdalKxTFL2QdNfydu?= =?us-ascii?Q?pCghVwmXT6WRG4896u9O2Zw9wX7ULFzbmI8cZaHslSwzecbB5Pi/ChrevDK6?= =?us-ascii?Q?uSg4p5ebODfdCsmQH8zW5i+gm/vkedYBwK6+PaIOY9L2SKGrkliSL25QBn4i?= =?us-ascii?Q?rTX+1KdsuCbramEouuOMNJDy1tyY4sghy+LNMxHNjPJ6cwYbcWxWTz0fRnQv?= =?us-ascii?Q?KozTu9slFqN3+VuHzYNe6QKBZdwdB93ngWQRzFBIbPc8adWxNn5fybReHWJy?= =?us-ascii?Q?Oqfzd9ch2JOzl70uFfjGMvg39RGj1OmsA6Uyws94WtMmLcvGwKTo3gCWQwTW?= =?us-ascii?Q?Jb/pjfxUIGfpXwgP75ixJx6OUO0N2cUHfnCrsCshFinDhL3URjXHz5RIlmU3?= =?us-ascii?Q?tRy5xKWGY66Q0LuJn8DN/5zRlsaPy5s0qGwlsWRA4k/azs7eyGNelIcXq7kV?= =?us-ascii?Q?p2CqVj8nTP066YgE24wXyGCotIHHcIJYqj7MaSzpYqZMEbVYFJ1UzA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2025 18:53:06.1864 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3ad6e037-cd66-4601-bf92-08ddea51f3f6 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D2.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8836 From: Victor Lira The errors can happen in the middle of a console line which causes the message to appear at the end of the current line. Prepend a newline to clearly separate the error line. Signed-off-by: Victor Lira --- example of the problem: - https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11220478458 - line 652 --- pipeline: - https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/2017775449 --- Cc: Doug Goldstein Cc: Stefano Stabellini Cc: xen-devel@lists.xenproject.org --- automation/scripts/console.exp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/automation/scripts/console.exp b/automation/scripts/console.exp index fc80513dfb..e27886bbef 100755 --- a/automation/scripts/console.exp +++ b/automation/scripts/console.exp @@ -35,8 +35,8 @@ expect_after { -re "(.*)\r" { exp_continue -continue_timer } - timeout {send_error "ERROR-Timeout!\n"; exit 1} - eof {send_error "ERROR-EOF!\n"; exit 1} + timeout {send_error "\nERROR-Timeout!\n"; exit 1} + eof {send_error "\nERROR-EOF!\n"; exit 1} } if {[info exists env(UBOOT_CMD)]} { -- 2.50.GIT From xen-devel-bounces@lists.xenproject.org Tue Sep 02 18:53:16 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 18:53:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107292.1457768 (Exim 4.92) (envelope-from ) id 1utW7z-0006sz-IS; Tue, 02 Sep 2025 18:53:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107292.1457768; Tue, 02 Sep 2025 18: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 1utW7z-0006ss-Du; Tue, 02 Sep 2025 18:53:11 +0000 Received: by outflank-mailman (input) for mailman id 1107292; Tue, 02 Sep 2025 18:53: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 1utW7x-0006sm-M1 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 18:53:09 +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 0f6e1e1a-882e-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 20:53:06 +0200 (CEST) Received: from CYXPR03CA0019.namprd03.prod.outlook.com (2603:10b6:930:d0::16) by SJ2PR12MB9114.namprd12.prod.outlook.com (2603:10b6:a03:567::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 18:53:03 +0000 Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com (2603:10b6:930:d0:cafe::af) by CYXPR03CA0019.outlook.office365.com (2603:10b6:930:d0::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Tue, 2 Sep 2025 18:53:03 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Tue, 2 Sep 2025 18:53:02 +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, 2 Sep 2025 13:53:01 -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, 2 Sep 2025 13:53:01 -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; Tue, 2 Sep 2025 13:53: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: 0f6e1e1a-882e-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b2jN34h1tyZfN1GJ5wzrSi29ix+e+CY9Rr1oJxZde58sSR9WgmpEmzi1maSuJnpNcXROoKg83wKkR5Xnhv/xmyixfPwd54Pe05WhH6ojxYqussVuaBBZP9rBc5C0pN+dF1zKhRxwv/EQufDzKs91TjL7uT8C68r8FfxiG6Zm7w3XwJMYESmmXO1+jwtkq510ZMrCG0YAH5qMHTZIdEaM3ocdTUSp/qiU5l+aEPNLB088gdXfxUjzjI4xGWegpt2Iw6Nxi5oUDwEdhj5T+t/hUj2pKQFkW9PIcTM/ZO1xhg0zDEOlp2CVJz9cEHsOGrrDJMzPPyhGMwC0WoBhMpsfBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZIy6GuThc4GKjoVg7TEXuAnD5k/i4XiSHVvQgeN4b9I=; b=aVcW/YkXdwT4iwAgCWNqNE45fkPh83xoIQ53AjMAhJAyYUKUG63HlyH5rvNbwTUVldLFgv/ncF38V4qMURDq1wZfbBpprhKig5ieKzki/x4/sFCx6YAS/byXlMBf4sbLY7adEg3HsgTONsk0WyEOoW8Z6+Em7NRxJ0nYvccGHAzADS9kMEQ9Alno2DPrySSK7kqWsgNtRRX7yVynZSRLgWI6gZXTWflEQdSov13QW4Sxut4DgwKjo+vb0Lh8be+YmYTyXnvkWBfEk+nAzKpiIUTqT2bxs94RDbJcFCAEoYuUDgOFoM1Vy5MB30qIjX24WipT8R2TZjk+++WTRFlHWA== 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=ZIy6GuThc4GKjoVg7TEXuAnD5k/i4XiSHVvQgeN4b9I=; b=UvMQHTOi9bOJQm6xskf/asmr46pj9u7J7vyejeVZR5n+yT3iQ71v9yomEe+3Z1qZzaEOEtdxOulb6KQn0zBuLONSgHjjEhn4wgnCqleIEfO1u8jZf608k6BeklQPuDlLk4l4vpJrPdF+GHga5kGtvPGR/yFBm5qIw/SuDeUZ6gQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Victor Lira , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Doug Goldstein" Subject: [PATCH v1 1/2] automation: call expect script with redirected standard error Date: Tue, 2 Sep 2025 11:52:34 -0700 Message-ID: <729708b7e6c1815e7ba9b712f6c847e0a0374fd9.1756834803.git.victorm.lira@amd.com> X-Mailer: git-send-email 2.50.GIT 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: CY4PEPF0000E9D2:EE_|SJ2PR12MB9114:EE_ X-MS-Office365-Filtering-Correlation-Id: bc929388-3bca-4544-3fee-08ddea51f1e2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?LytvMlJTaWMyYnF0KytYZVNtdGhmY2xvMndhUURLUk8zSDFhL2JnazlFSk9N?= =?utf-8?B?ZWlSZmNLTU9JMisxNFlwenFSeUJ4VVNEejNqYXUyWGRObkU2bjQwZkx0SHU2?= =?utf-8?B?Nm5PaGpLQUUwUnFaMk16R0oyY010NUlvSDliV0Vwei9VTkRwZjNBRzJaWDlV?= =?utf-8?B?b0pabU95S0czNjFOcE1CY3IrbGJESFRrc1dzOVpCQmtXQjl5TzJlSTlRbHQr?= =?utf-8?B?RGlCR0Eya05LeU9jenp6Mm9VRzZTZVI0VzV5STZIbmRmSHh6ZGhPUFlKQjYy?= =?utf-8?B?RVhrbWt3WEtOY1VrRTM2eWM5UUN0bnpXZDdwTHpGUXdDc2ZLcWpLZjdMUXdP?= =?utf-8?B?V1dUdjFkbUViRG9mRlU1QTZhUjVIcU1vUVZUL0hIc3Q1LzZyUEVwdk1LOXgy?= =?utf-8?B?MUVsTjdPUHpCVDdCSFRka2Q1MjZRMzIyZ3EyUUdZcHZjRVA1TlFXMzNPZFpB?= =?utf-8?B?c0lqaEE5K2dGRjhSRzBuRG12Q3V6eE9vTllzVWRFUUY5QzZPL2daYjRLNVRw?= =?utf-8?B?NHE1STBiYUpvVzJvQm1CeEdxYmZGSGlwMVBpM2kyeXpVU09PRHF1bDJRbnY0?= =?utf-8?B?MkhqRlQ4WE14WmNiT1prRHpnNk16a2xGVGRSdlQ2dU1jU0p0N1A3TWVlTjlX?= =?utf-8?B?Z3VRZUJ2L09WTDY5eXE2QUQrSCtWM05ZcjBvSGxyeVgxSUUvWkh1STJCTTli?= =?utf-8?B?am9QNmNZcjM1dE5penlpNGs1ZVBmQTBON21yWUR6aW92UVJxVGJRR21hTitq?= =?utf-8?B?bVZOdGtWNytUT0JMeWdVN1A2WkFjN2RyQnJ3SStCT1NmNGRDUng5K0lpTGlv?= =?utf-8?B?K2hobFZMdEI4NzVoUXdQVWVCUXcxMC8wVjRjQkk1K3R4c3VySjRsYnNwaWFv?= =?utf-8?B?d2pDSXcyM0R1VkNlQjk2cytOSUhyZTZCK2lUeXFtdUk2SUdZRkR2QW5FNUxy?= =?utf-8?B?eVZyaUZsU1BZMzFRQjJDVmkxWHpyWkpxRFpBS3ZBUXNWS1Bma0xhN3BFWjVT?= =?utf-8?B?RVVvRHFqMTB3UzdNNkVScmZGeGtCNnN6V0l1WU5sTnNSdmlHR3B6b3dFdlJP?= =?utf-8?B?NGZSUmk2STVVSE1YSEsxQnJlYXFVUmxBVmwxa3lHZGl2T0xRVHA3ZDJ1NHZJ?= =?utf-8?B?UTkvb1p4WG1qZlcxZ0JmY2RiM1k4YzN2UXdxVHJzU3d1aCt5OVVQMlViMCtL?= =?utf-8?B?OVA1b0NaRjRoREJGVWtSZUJ0eEV6Y1l6d3FTb3UyQzhueGo0T2FOOUNFeXA2?= =?utf-8?B?RVAySmdSQ2NlaXh3VWRZREU3YXNjWjlKbmlFSGtsRHIxU2ZxYnQwdmh0eDRD?= =?utf-8?B?R3NxTGxaeFRSU2gvWGNPL0JRcWV5MVdhRGtmZzlqUUFuVlFTcHlkL0t6czdr?= =?utf-8?B?VXpvVWpORExTVFY1MWdvejZmZ1pKb1hXZUNNWm9qWHo0SFFkbU1BUVZvU3Ev?= =?utf-8?B?R0RUeGw5NHVkUDBvbE1GOGFPK0ZGU0VrMXg3KzUyQSswMERIMjByRjJ0YXdq?= =?utf-8?B?eVpJWmhCM05iVzlod2VtZDd5MTR5bUxLNFlWQUtONFB3bmhqRytlRDExOGp0?= =?utf-8?B?bEJ2SWVsSmJqRVpvZFdGazVUNzFpRDN3OVIwVXU2RTZsYkhtaWdjemxrQnVu?= =?utf-8?B?QVhoMXR6anB2b1BwMU84VVdZSWFsYjFZelM1eDhlOTZOVmtFOWFqRkZ2bGJz?= =?utf-8?B?elBNK3R0Wnp3L2lGYTAwN05mMlNhU0VPTVc5Z29TajdiaSs5czYxc3FIVnJ3?= =?utf-8?B?WGFxclRyQXBNemd2MDd4blpOK0g3R2d1SW5sSmFxcHBrb1lPblBJVGFCa3pu?= =?utf-8?B?RjFPblo3bHVZZURKWlBQV0ROM2tzTW53L3k4ZzZTenJ4R2NyVlk3VjI5NjZh?= =?utf-8?B?aFkrMWxTZ1NCMjk1Z3JScU1rTTdyYzR5QjNoSjVWYnJVdE1yTlBXc2pEUG8z?= =?utf-8?B?YSt2amd3NktPM3RzeVdHTnpFdTF2RHNKSWNpdlhFVTdMT1dNRzJvbWFQMEkr?= =?utf-8?B?WHBudmpQbFZRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2025 18:53:02.6988 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bc929388-3bca-4544-3fee-08ddea51f1e2 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D2.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9114 From: Victor Lira In the console expect script, "send_error" will send a message to standard error. Current use of this script redirects only standard output into a pipeline. This causes the error messages to sometimes appear hidden in the middle of the test logs. Redirect also standard error to clearly show when a test has timed out or hit EOF. Signed-off-by: Victor Lira --- example of the problem: - https://gitlab.com/xen-project/people/luca.miccio/xen/-/jobs/11136585863#L615 - timeout message on line 615 shown before end of log note: - I couldn't check the change on cirrus-ci as I don't have access --- Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: "Roger Pau Monné" Cc: Stefano Stabellini Cc: Doug Goldstein Cc: xen-devel@lists.xenproject.org --- .cirrus.yml | 2 +- automation/scripts/include/xtf-runner | 2 +- automation/scripts/qemu-alpine-x86_64.sh | 2 +- automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +- automation/scripts/qemu-smoke-dom0-arm64.sh | 2 +- automation/scripts/qemu-smoke-dom0less-arm32.sh | 2 +- automation/scripts/qemu-smoke-dom0less-arm64.sh | 2 +- automation/scripts/qemu-smoke-ppc64le.sh | 2 +- automation/scripts/qemu-smoke-riscv64.sh | 2 +- automation/scripts/qubes-x86-64.sh | 2 +- automation/scripts/xilinx-smoke-dom0-x86_64.sh | 2 +- automation/scripts/xilinx-smoke-dom0less-arm64.sh | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/.cirrus.yml b/.cirrus.yml index 3163ab8f11..f295c8cb0a 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -166,7 +166,7 @@ task: export TEST_LOG="serial-${FREEBSD_BUILD}-${XTF_ARCH}.txt" export PASSED="Test result: SUCCESS" export TEST_TIMEOUT=120 - ./automation/scripts/console.exp | sed 's/\r\+$//' + ./automation/scripts/console.exp |& sed 's/\r\+$//' always: serial_artifacts: diff --git a/automation/scripts/include/xtf-runner b/automation/scripts/include/xtf-runner index b7fea52dad..43ff2d4d88 100644 --- a/automation/scripts/include/xtf-runner +++ b/automation/scripts/include/xtf-runner @@ -114,7 +114,7 @@ function xtf_run_test() { rm -f ${TEST_LOG} export BOOT_MSG PASSED TEST_CMD TEST_LOG UBOOT_CMD - ./console.exp | sed 's/\r\+$//' + ./console.exp |& sed 's/\r\+$//' } # Setup environment and run an XTF test. diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh index 746e70483d..c4666b9507 100755 --- a/automation/scripts/qemu-alpine-x86_64.sh +++ b/automation/scripts/qemu-alpine-x86_64.sh @@ -84,4 +84,4 @@ export BOOT_MSG="Latest ChangeSet: " export LOG_MSG="Domain-0" export PASSED="BusyBox" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qemu-smoke-dom0-arm32.sh b/automation/scripts/qemu-smoke-dom0-arm32.sh index 4f50eabdef..36c47daa42 100755 --- a/automation/scripts/qemu-smoke-dom0-arm32.sh +++ b/automation/scripts/qemu-smoke-dom0-arm32.sh @@ -96,4 +96,4 @@ export BOOT_MSG="Latest ChangeSet: " export LOG_MSG="Domain-0" export PASSED="/ #" -../automation/scripts/console.exp | sed 's/\r\+$//' +../automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qemu-smoke-dom0-arm64.sh b/automation/scripts/qemu-smoke-dom0-arm64.sh index d6f6b74880..ee682015a0 100755 --- a/automation/scripts/qemu-smoke-dom0-arm64.sh +++ b/automation/scripts/qemu-smoke-dom0-arm64.sh @@ -106,4 +106,4 @@ export TEST_LOG="smoke.serial" export LOG_MSG="Domain-0" export PASSED="BusyBox" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-dom0less-arm32.sh index 0e2c5496db..e27636dc9e 100755 --- a/automation/scripts/qemu-smoke-dom0less-arm32.sh +++ b/automation/scripts/qemu-smoke-dom0less-arm32.sh @@ -149,4 +149,4 @@ export TEST_LOG="${serial_log}" export LOG_MSG="${dom0_prompt}" export PASSED="${passed}" -../automation/scripts/console.exp | sed 's/\r\+$//' +../automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-dom0less-arm64.sh index e7a3e670d0..e660485f3a 100755 --- a/automation/scripts/qemu-smoke-dom0less-arm64.sh +++ b/automation/scripts/qemu-smoke-dom0less-arm64.sh @@ -218,4 +218,4 @@ export TEST_LOG="smoke.serial" export LOG_MSG="Welcome to Alpine Linux" export PASSED="${passed}" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qemu-smoke-ppc64le.sh b/automation/scripts/qemu-smoke-ppc64le.sh index 617096ad1f..119c3ed4d5 100755 --- a/automation/scripts/qemu-smoke-ppc64le.sh +++ b/automation/scripts/qemu-smoke-ppc64le.sh @@ -24,4 +24,4 @@ export TEST_CMD="qemu-system-ppc64 \ export TEST_LOG="${serial_log}" export PASSED="Hello, ppc64le!" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh index 25f9e4190e..c0b1082a08 100755 --- a/automation/scripts/qemu-smoke-riscv64.sh +++ b/automation/scripts/qemu-smoke-riscv64.sh @@ -16,4 +16,4 @@ export TEST_CMD="qemu-system-riscv64 \ export TEST_LOG="smoke.serial" export PASSED="All set up" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh index b49a44c5b1..bd939dc948 100755 --- a/automation/scripts/qubes-x86-64.sh +++ b/automation/scripts/qubes-x86-64.sh @@ -292,7 +292,7 @@ export LOG_MSG="\nWelcome to Alpine Linux" export TEST_CMD="ssh $CONTROLLER console" export TEST_LOG="smoke.serial" export TEST_TIMEOUT="$timeout" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' TEST_RESULT=$? if [ -n "$retrieve_xml" ]; then diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh index 0ad8f658e3..96f534f3aa 100755 --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh @@ -173,7 +173,7 @@ export BOOT_MSG="Latest ChangeSet: " export TEST_CMD="cat ${SERIAL_DEV}" export TEST_LOG="smoke.serial" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' TEST_RESULT=$? sh "/scratch/gitlab-runner/${TEST_BOARD}.sh" 2 exit ${TEST_RESULT} diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-dom0less-arm64.sh index 1d7162f1b3..a6da7a830c 100755 --- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh +++ b/automation/scripts/xilinx-smoke-dom0less-arm64.sh @@ -137,7 +137,7 @@ export LOG_MSG="Welcome to Alpine Linux" export TEST_CMD="cat ${SERIAL_DEV}" export TEST_LOG="smoke.serial" -./automation/scripts/console.exp | sed 's/\r\+$//' +./automation/scripts/console.exp |& sed 's/\r\+$//' TEST_RESULT=$? sh "/scratch/gitlab-runner/zcu102.sh" 2 exit ${TEST_RESULT} -- 2.50.GIT From xen-devel-bounces@lists.xenproject.org Tue Sep 02 19:45:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 19:45:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107321.1457786 (Exim 4.92) (envelope-from ) id 1utWvz-0005Ax-Ch; Tue, 02 Sep 2025 19:44:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107321.1457786; Tue, 02 Sep 2025 19: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 1utWvz-0005Aq-9i; Tue, 02 Sep 2025 19:44:51 +0000 Received: by outflank-mailman (input) for mailman id 1107321; Tue, 02 Sep 2025 19: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 1utWvy-0005Ad-Ou for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 19:44:50 +0000 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [81.169.146.165]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 47fc9721-8835-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 21:44:49 +0200 (CEST) Received: from mail.onlineschubla.de by smtp.strato.de (RZmta 52.1.2 AUTH) with ESMTPSA id e4daa2182JiXhVP (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 2 Sep 2025 21:44:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.onlineschubla.de (Postfix) with ESMTP id CC72021579; Tue, 2 Sep 2025 21:44:32 +0200 (CEST) Received: from mail.onlineschubla.de ([127.0.0.1]) by localhost (mail.onlineschubla.de [127.0.0.1]) (amavis, port 10024) with ESMTP id 9Hax-33er-4N; Tue, 2 Sep 2025 21:44:31 +0200 (CEST) Received: from [10.0.0.105] (unknown [10.0.0.105]) by mail.onlineschubla.de (Postfix) with ESMTPA id 6E50C201BF; Tue, 2 Sep 2025 21:44: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: 47fc9721-8835-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; t=1756842273; cv=none; d=strato.com; s=strato-dkim-0002; b=bVvT49nGbsgpSlIUVos0SmdzFFejtMHZs3aXPs+U+M33+xecsrFscnbBgfsE15fc+n e+VO0e/qA/J0xsG1va678JMCVMwZS5cfo46+jy9DtSI48Gx6zIKoT+zpcjVrwalYlcWU RHe+ybaMVC93gqrUg7sh8i8lcqRsk3E/Ho4WHc+4ZdGVWIBOFI9rJm5/ZEoVV39O1B7A ac0UGHv/m8YzDDV5DcsJEyygbNYJE2bq7A24XgPx7i0eTCQ7mEUtPcVXcK/bC6Pg5Vuk 1WTr7lv4QZ3qBcv/4xktc5d/+3loCajo09Xw7ZBVuH/CQRMmviUQqqr+zpEkyBfWgND5 CxAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1756842273; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=GbpgQVIjjGUXL3PXvixxP4aig2ii2mgDcC5RxM3z/Io=; b=h78IRfWthvTv5iPFtWBn11lzk/QE0UaRL/mqhqoeOQULKKil7mmwhrX1kVLA6MgUI0 Z6bE7B4nBb0qJU7aRKk6kOOioy943bKfHx9+ibusxKaSG3fQokjWtSngsUK3UuqxyYz/ BrdMelPGoQH4/0bYk3WkGYGYHbX3ZwjoS9rppAqQu5NJgjgq2M+qsOJ1xnOgcaRUP5uj takzfNlVkvXUYJxuWphU4j+yDTu3wfQxBRERNxqLzqLDe2r3wgQvwIgZB3k/qjS9wjcF H/PpFtw9ZWBbkB+HmBj60ZbJueT3w3zxmgTlGftJAabJkow2SJWd6DgKOYe55sQ2DS2X ApZA== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1756842273; s=strato-dkim-0002; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=GbpgQVIjjGUXL3PXvixxP4aig2ii2mgDcC5RxM3z/Io=; b=a99IERNCjEOYKZLO6id8nMqUYnXoCLKg6e+SM+D1INvZutvJ0jl7KsaT6e3KXu3eJ4 4Gz9HusO46uB8aUFEtYMDtCqxpWyStX+WhYvCset5DsU+J58Dq2+cQGcH6+U2akRB06o yJ/XLZhWVmNXowvUPiqg0vhJeCzf7ita2x9/jPuFI5HT8nAgOq2UlCG6ZPsqr+3R1Ce1 /NzUmhqIRNf2YsmYqHEsDX50gCDoMroI1ma94HL5YOcLwf0rWfZKt+5lFwgkjTdQl54n +O4xT8nOCY0wsVOSBBkffHhiz24aHn1Z714Pdl+P6aDtf0aTTITjjyNPkk1t7/BF6mDB u9tQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1756842273; s=strato-dkim-0003; d=onlineschubla.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=GbpgQVIjjGUXL3PXvixxP4aig2ii2mgDcC5RxM3z/Io=; b=NTuMIkGmU1oOGsQcgG0BrZVIE3GUsaQX4b3S4R0446ISA2f3ZMCPx8izbiX2h5Xu88 WdKP1u40ZE1unPAu83Cw== X-RZG-AUTH: ":PG0ReWCndfO3rCSML4AvNaDxJ7WJyilEI/NMX3IPpS4dskMFCImCETb1V6b0vc0G82XEylMud93Y+DuZ3uJ2CpXvFoK3ctvQEzg=" X-Virus-Scanned: Debian amavis at onlineschubla.de Message-ID: <291070b9-c79d-47ed-b971-cb935a1724c0@onlineschubla.de> Date: Tue, 2 Sep 2025 21:44:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Consider changing CONFIG_ACPI default on ARM? To: Julien Grall , Elliott Mitchell , Jan Beulich Cc: Demi Marie Obenour , xen-users@lists.xenproject.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <1b96f2f3-55a2-4b33-84b1-a7c18d38d10c@suse.com> <6e9b5265-7a3b-4fd5-b14e-0e60a8b49833@gmail.com> <2f11b8ea-a386-4c2a-afe6-c7e57d1d7f75@xen.org> Content-Language: en-US From: Paul Leiber In-Reply-To: <2f11b8ea-a386-4c2a-afe6-c7e57d1d7f75@xen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 23.08.2025 um 09:59 schrieb Julien Grall: > Out of interest, sorry if this was already mentioned before, is there > any reason ACPI is used on the Raspberry PI over Device-Tree? Is there > any issue with the latter on Xen? Perhaps I can chime in here and point out why I have been using ACPI on Raspberry Pi (RPi) with Xen. This is my personal experience as a user, and I don't really know much about Device Trees, so I can't make a technical analysis of ACPI vs. DT. Debian is currently the only linux distribution I am using. Therefore, I am used to setting up Xen by installing Debian and then installing the packages from Debian. When installing these packages, I end up with a ready-to-use Xen/Dom0 setup and Grub as the bootloader. When I install kernel updates, grub automatically is updated to use the correct Xen/kernel combination as a default. This is very convenient. My first tries with a RPi were with RPi OS. However, RPi OS doesn't provide Xen packages. Next, the official explanations on [1] seemed rather complicated to me. Coming from Debian, I didn't know anything about U-Boot. As I didn't want to mess with U-boot, I installed vanilla Debian (following [2]), which provided me with the familiar ACPI/Grub/Debian environment. With Julien's help, I managed to compile Xen (with ACPI switched on) on the RPi, got it running, and have been using it since then with an occasional recompile of Xen. (There are still some networking related issues I experience in certain setups, but that's a different story.) So, to sum it up, the combination of ACPI/Grub/Debian and a self-compiled Xen package provided a solution that comes close to the experience I have on my other Xen systems. Apart from some deviation when installing vanilla Debian and the need to compile Xen myself (due to the experimental status of ACPI, of course), I can basically use and manage the RPi system like any x86 system. That's why I am using it this way. From my point of view, the biggest drawback of the ACPI solution is that I can't use I2C because I2C is not supported when using UEFI boot on a RPi. [3] Nowadays, there are semi-official packages for RPi provided by Debian, but as they use a different boot mechanism, they break my workflow, that's why I haven't been using them. Best regards, Paul [1] https://xenproject.org/blog/xen-on-raspberry-pi-4-adventures/ [2] https://forums.raspberrypi.com/viewtopic.php?t=282839 [3] https://github.com/pftf/RPi4/issues/130 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 19:59:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 19:59:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107357.1457797 (Exim 4.92) (envelope-from ) id 1utXAX-0006wG-Pg; Tue, 02 Sep 2025 19:59:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107357.1457797; Tue, 02 Sep 2025 19: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 1utXAX-0006w9-N6; Tue, 02 Sep 2025 19:59:53 +0000 Received: by outflank-mailman (input) for mailman id 1107357; Tue, 02 Sep 2025 19:59:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXAW-0006w3-Ma for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 19:59:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utXAU-0032mY-2p; Tue, 02 Sep 2025 19:59:51 +0000 Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utXAU-00DYSJ-2m; Tue, 02 Sep 2025 19:59: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=mIMUPR2G2aJu9rSZjV7j9Wzw64WSIS00NQbD+BrzNeM=; b=2z0oK+vho8nYxtk0FxZQHVl7hJ hI4UAy5w4ezPLsCF+FouDn/Fi3Jm0sT8g+v9EbPNOSezspU/tcywIuJqinR8NqAsLGVJlAeWZMIXk 2RS4c8lE/bliuXTSQG7ZRcj76AfGgJrd+R5CxG29M6UiuU7T75EmfWinZHUGVCHeWykw=; Message-ID: <6a6c5bf8-4c2f-4b9d-8d2c-654fd6ae08aa@xen.org> Date: Tue, 2 Sep 2025 20:59:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 09/12] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Oleksandr Tyshchenko References: <5ab75c0a-0bf6-418a-8c8f-7411a46d4189@xen.org> <30a25153-1f1f-41cf-afad-195d73ba405e@epam.com> From: Julien Grall In-Reply-To: <30a25153-1f1f-41cf-afad-195d73ba405e@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02/09/2025 18:15, Leonid Komarianskyi wrote: > Hi Julien, Hi Leonid, > On 02.09.25 19:42, Julien Grall wrote: >> Hi Leonid, >> >> On 29/08/2025 17:06, Leonid Komarianskyi wrote: >>> The Dom0 and DomUs logic for the dom0less configuration in >>> create_dom0() and >>> arch_create_domUs() has been updated to account for extended SPIs when >>> supported by the hardware and enabled with CONFIG_GICV3_ESPI. >> >> Style: We don't commonly use past tense to describe the new behavior. > > I will update it in V6. > >>>   xen/arch/arm/dom0less-build.c   |  2 +- >>>   xen/arch/arm/domain_build.c     |  2 +- >>>   xen/arch/arm/include/asm/vgic.h | 19 +++++++++++++++++++ >>>   3 files changed, 21 insertions(+), 2 deletions(-) >>> >>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less- >>> build.c >>> index 69b9ea22ce..02d5559102 100644 >>> --- a/xen/arch/arm/dom0less-build.c >>> +++ b/xen/arch/arm/dom0less-build.c >>> @@ -285,7 +285,7 @@ void __init arch_create_domUs(struct >>> dt_device_node *node, >>>       { >>>           int vpl011_virq = GUEST_VPL011_SPI; >>> -        d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS; >>> +        d_cfg->arch.nr_spis = vgic_def_nr_spis(); >>>           /* >>>            * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is >>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >>> index d91a71acfd..39eea0be00 100644 >>> --- a/xen/arch/arm/domain_build.c >>> +++ b/xen/arch/arm/domain_build.c >>> @@ -2054,7 +2054,7 @@ void __init create_dom0(void) >>>       /* The vGIC for DOM0 is exactly emulating the hardware GIC */ >>>       dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; >>> -    dom0_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS; >>> +    dom0_cfg.arch.nr_spis = vgic_def_nr_spis(); >>>       dom0_cfg.arch.tee_type = tee_get_type(); >>>       dom0_cfg.max_vcpus = dom0_max_vcpus(); >>> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/ >>> asm/vgic.h >>> index 912d5b7694..3aa22114ba 100644 >>> --- a/xen/arch/arm/include/asm/vgic.h >>> +++ b/xen/arch/arm/include/asm/vgic.h >>> @@ -347,6 +347,25 @@ extern void >>> vgic_check_inflight_irqs_pending(struct vcpu *v, >>>   /* Default number of vGIC SPIs. 32 are substracted to cover local >>> IRQs. */ >>>   #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)> >>> +static inline unsigned int vgic_def_nr_spis(void) >>> +{ >>> +#ifdef CONFIG_GICV3_ESPI >>> +    /* >>> +     * Check if the hardware supports extended SPIs (even if the >>> appropriate >>> +     * config is set). If not, the common SPI range will be used. >>> Otherwise >>> +     * return the maximum eSPI INTID, supported by HW GIC, subtracted >>> by 32. >>> +     * For Dom0 and started at boot time DomUs we will add back this >>> value >>> +     * during VGIC initialization. This ensures consistent handling >>> for Dom0 >>> +     * and other domains. For the regular SPI range interrupts in >>> this case, >>> +     * the maximum value of VGIC_DEF_NR_SPIS will be used. >>> +     */ >>> +    if ( gic_number_espis() > 0 ) >>> +        return ESPI_BASE_INTID + min(gic_number_espis(), 1024U) - 32; >>> +#endif >>> + >>> +    return VGIC_DEF_NR_SPIS; >> >> This is the only user of VGIC_DEF_NR_SPIS. Therefore, I would prefer if >> we remove the define. This will avoid any confusion between the helper >> and the define. >> >> Cheers, >> > > Actually, we need this macro in the previous patch in the series: > [08/12] xen/arm: vgic: add resource management for extended SPIs > (domain_vgic_init): > > if ( nr_spis + 32 >= ESPI_BASE_INTID ) > { > d->arch.vgic.nr_espis = min(nr_spis - ESPI_BASE_INTID + 32, 1024U); > /* Verify if GIC HW can handle provided INTID */ > if ( d->arch.vgic.nr_espis > gic_number_espis() ) > return -EINVAL; > /* > * Set the maximum available number for regular > * SPI to pass the next check > */ > nr_spis = VGIC_DEF_NR_SPIS; > } > > I have seen your comment regarding reworking the checks, but in any > case, I still need this macro to assign the value to nr_spis, so I would > prefer to leave it. Ah! I didn't spot the other use. Then let's keep it for now. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:08:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:08:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107368.1457806 (Exim 4.92) (envelope-from ) id 1utXJ0-0000C5-J1; Tue, 02 Sep 2025 20:08:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107368.1457806; Tue, 02 Sep 2025 20:08:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXJ0-0000By-GF; Tue, 02 Sep 2025 20:08:38 +0000 Received: by outflank-mailman (input) for mailman id 1107368; Tue, 02 Sep 2025 20:08: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 1utXIz-0000Bs-JE for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:08:37 +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 9a2c0866-8838-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:08:33 +0200 (CEST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-55f69cf4b77so4133884e87.2 for ; Tue, 02 Sep 2025 13:08: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: 9a2c0866-8838-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756843713; x=1757448513; 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=LvCR52lESdjN68+p3ZTk4n3ifImJi43k8YhAjRFMIVA=; b=X6zE6oggw0jhRSNTWjoMn3KGsxhfg6SNEf8IqVw/rHbXLq1dwUdwx1ItZzdLEVv2nw /j5OPcj9nyIiFN6TYrwkehaepehi1+G5JXsGQMDIPW1IEbiK/vmTvZj+AlRqOdZmiILg AqM3PWFTe30m4MCsyarIKqbmwK0Bg1s9PMol5CGn1cHXPkdUAOF8sGbg/yP0oA3lbH9K nd16J87nebLYemSLFastfKQCxqzOJi0QDNlHfCB7GH+mikdkcd31d4IXcJINyCDihKuC kiyBwPiJrGqtD7MZHUNF+7pHgWHq9cWFSAZF3daY+wT0q0naJt6z1nnm/M3nmsu1zcv1 bKrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756843713; x=1757448513; 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=LvCR52lESdjN68+p3ZTk4n3ifImJi43k8YhAjRFMIVA=; b=r8pt3oqiOOaEAR++b/Wt+NeIw7DnuCeNBjsO+amAgy6/2rHOiRd9auNgAIlK6P1UW/ ZwWA3ayF9nog1mJWCja3bI7m6feTgQXcz+5wAU66Gz49kv3ynXXh3qxe0+FMB87FXTrj IB9xvrFzjix7VxygsUcOst7bbXvCqSeI/2Vk+WBQdIVYFUeb7/7kHr28XxIei9egsz53 03QBacmHJJm3EoKcardHYCFyPPCbEhBrOQfercQm46LdPznbGlklmlVyvNGhEaFLGODP ykskrijkE15ZH79XAzS5X78oLpJyFfWkozLw6laTuyvE+Raralp8WzjwEN1VgO8jlGyo Tobw== X-Gm-Message-State: AOJu0YyTENzkwI4ohw158gZTbrpEt7UUFUNxa2Kyg6GBbrTsKb4EW/Jk ARburrCAyfkDWGrjiSaO0oBhry6Ok16SYNcsy9aGqUA/6pZ+Ov/A/T+EowiEBtIUCkmWZcJ5MqF zzbKBGJqkjNKltQ/ecfVZpEmogbAlkpM= X-Gm-Gg: ASbGncuXqZDhSXFuOZOnDWPN1z9yM55rFLtz0sQg+h2GRZgfKsTwSchQQ5KC5KgMqs/ 1iwaTcd0CaJu8f9YsyKv3iERbCdkav69p7SKynr68hxwrIcUUYMjEi8cPVNm8Mjghz/94NoaraS CFFedCiT1Le+mmSZWfukaFK9r/0khr9fbzu0H76vjtlq1oYqSUaC3R92aTLjZ9fNQojzCcDR6gM z9kNGCK52zuoro+ X-Google-Smtp-Source: AGHT+IEFaS7sG9infLLYcClQpHGtnw+ylh7nh2Tq67ReNfd/h2dM90wwmuwWKCI2V9NaIEvy9ZKaSONcNasbLeEIivk= X-Received: by 2002:a05:6512:1357:b0:55f:3ce4:585e with SMTP id 2adb3069b0e04-55f708f118cmr3696830e87.31.1756843712620; Tue, 02 Sep 2025 13:08:32 -0700 (PDT) MIME-Version: 1.0 References: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> In-Reply-To: From: Mykola Kvach Date: Tue, 2 Sep 2025 23:08:21 +0300 X-Gm-Features: Ac12FXyW3XnFwspk-_0J4Bx7LoF27XV3Uh-CUd1XECJ_yAfhrNnRCawLXiK6jY0 Message-ID: Subject: Re: [PATCH v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 9:16=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > On 02.09.25 20:43, Mykola Kvach wrote: > > Hi Oleksandr, > > Hello Mykola > > > > > On Tue, Sep 2, 2025 at 7:49=E2=80=AFPM Oleksandr Tyshchenko wrote: > >> > >> > >> > >> On 02.09.25 01:10, Mykola Kvach wrote: > >> > >> Hello Mykola > >> > >>> 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 > >>> --- > >>> Changes in V6: > >>> - Call handler->disable() instead of just setting the _IRQ_DISABLED f= lag > >>> - Move the system state check outside of restore_local_irqs_on_resume= () > >>> --- > >>> xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ > >>> 1 file changed, 39 insertions(+) > >>> > >>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > >>> index 6c899347ca..ddd2940554 100644 > >>> --- a/xen/arch/arm/irq.c > >>> +++ b/xen/arch/arm/irq.c > >>> @@ -116,6 +116,41 @@ 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; > >> > >> NIT: Please, use "unsigned int" if irq cannot be negative > > > > ok > > > >> > >>> + > >>> + spin_lock(&local_irqs_type_lock); > >>> + > >>> + for ( irq =3D 0; irq < NR_LOCAL_IRQS; irq++ ) > >>> + { > >>> + struct irq_desc *desc =3D irq_to_desc(irq); > >>> + > >>> + spin_lock(&desc->lock); > >>> + > >>> + if ( test_bit(_IRQ_DISABLED, &desc->status) ) > >>> + { > >>> + spin_unlock(&desc->lock); > >>> + continue; > >>> + } > >>> + > >>> + /* Disable the IRQ to avoid assertions in the following call= s */ > >>> + desc->handler->disable(desc); > >>> + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); > >> > >> Shouldn't we use GIC_PRI_IPI for SGIs? > > > > Yes, we should. But currently I am restoring the same value > > as it was before suspend... > > > > I definitely agree that this needs to be fixed at the original > > place where the issue was introduced, but I was planning to > > address it in a future patch. > > > >> > >> > >>> + 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) > >>> { > >>> @@ -134,6 +169,10 @@ static int cpu_callback(struct notifier_block *n= fb, unsigned long action, > >>> printk(XENLOG_ERR "Unable to allocate local IRQ for CP= U%u\n", > >>> cpu); > >>> break; > >>> + case CPU_STARTING: > >>> + if ( system_state =3D=3D SYS_STATE_resume ) > >>> + restore_local_irqs_on_resume(); > >>> + break; > >> > >> May I please ask, why all this new code (i.e. > >> restore_local_irqs_on_resume()) is not covered by #ifdef > >> CONFIG_SYSTEM_SUSPEND? > > > > I don=E2=80=99t see a reason to introduce such "macaron-style" code. On= ARM, the > > system suspend state is only set when CONFIG_SYSTEM_SUSPEND is defined > > anyway. > > right > > > > > If you would prefer me to wrap all relevant code with this define, plea= se > > let me know and I=E2=80=99ll make the change. In this case, I think the= current > > approach is cleaner, but I=E2=80=99m open to your opinion. > > In other patches, you seem to wrap functions/code that only get called > during suspend/resume with #ifdef CONFIG_SYSTEM_SUSPEND, so I wondered > why restore_local_irqs_on_resume() could not be compiled out > if the feature is not enabled. But if you still think it would be > cleaner this way (w/o #ifdef), I would be ok. It=E2=80=99s not entirely true -- I only wrapped code that has a direct dep= endency on host_system_suspend(), either being called from it or required for its correct operation. If you look through this patch series for the pattern: SYS_STATE_(suspend|resume) you=E2=80=99ll see that not all suspend/resume-related code is wrapped in #ifdef CONFIG_SYSTEM_SUSPEND. This is intentional -- the same applies to some code already merged into the common parts of Xen. So restore_local_irqs_on_resume is consistent with the existing approach in all cpu notifier blocks. > > > > >> > >>> } > >>> > >>> return notifier_from_errno(rc); > >> > > > > Best regards, > > Mykola > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:14:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:14:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107385.1457816 (Exim 4.92) (envelope-from ) id 1utXP0-0001lp-75; Tue, 02 Sep 2025 20:14:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107385.1457816; Tue, 02 Sep 2025 20:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXP0-0001li-4Y; Tue, 02 Sep 2025 20:14:50 +0000 Received: by outflank-mailman (input) for mailman id 1107385; Tue, 02 Sep 2025 20:14: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 1utXOy-0001lc-7F for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:14:48 +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 74882329-8839-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 22:14:40 +0200 (CEST) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by VI0PR03MB10568.eurprd03.prod.outlook.com (2603:10a6:800:20a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 20:14:33 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:14: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: 74882329-8839-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qVLAPWMkxaGZ5+NaDmQHclp7q6zELB4/hOflFY0b1hPN3ZJ8IyaQo2jwmkv/A3PiI6pTT7+b4XlVOq1ILXrSsyXudkgH/NjKxd6ZCvZh/ySOQCIlfDse97w4rYJWfr3d601zjSx738nRpNNnGh2iTgp1NOCV6KgBQ/XgQ7frAgGpZYr2fUDLMF6X09XJEg4wdHGMigzF5l4rBK2T+LS+cVJBe+g7/lFDQetcso8JbZTF1jrd+YGFbuKsxI/bJvWa3Y43ZXo0dDZNrsSijKIk+I7xBSuaWZY5lxv9jDOU0pDbLNRXnWlIxUZHpKqUxUr94AVpYzY4kfj21mYZbSZLKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JfBzhqG3dKrQs+WAJJZl0fXxiYFWJkxq7Hsbg0uPEzw=; b=eAwAeQlgFq/hPW1GlMyBi0qaic0NmJA6oDx83STeY+VO3gkTiHci5I9LtjSGTntgMwLLBBFjA6zo9pwEFUXW98OAe6/RXoXpixXX2JCr41iB4hHuZdevIxCF8DP8EoAeSYHTEQaK8EyTYCgleUgXDzOBX5HESK1kwep7sig0B12CIqu8azHWiC8cfcr3znApd4lrQvhuV1GCQ9Q4J37GTTgqn9c4HZCfd/DmBrqXTV/4iecAjVbwIl7PikEOmLcixbTwevcwBljgI7VzAaqgHEfs64OVvprRctpJF59OFg7j2PzzQEww/TOi7kQAHg/ZX00AIxTBzvDxdFfmok8voA== 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=JfBzhqG3dKrQs+WAJJZl0fXxiYFWJkxq7Hsbg0uPEzw=; b=nIj0J3x5TedsdDflk8XQVHWF7OxCwupx1ZKck4PR+L6y+NG0gIhgFAAb7vnCmIO46r8xRm4eRw2qp1e8zviFN717Y8tQ09qzbieuf3pn8Q4DHU4CD548j28MQuqNkJROGD0t8rluzXtfMJ1GSwli5MExw4Jw873z4wxyNXFEBYZAoOpJ8pmgD6rpSkLyCrjtnjcrHeZSdzNQ1RRCQR7byEuddAaMXRN0UjTyLx7O6GG/7Ham0Tbi98Q6l3VopAZvu8KFdxVz/Jx6c350CmZeCq3czMKL7JGRRfwSO+U4NHg8XA28/jYRCE88cVkRd1wcCEUaULgFjJd+LtLGaicOOA== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Saeed Nowshadi , Mykola Kvach Subject: Re: [PATCH v6 01/13] xen/arm: Add suspend and resume timer helpers Thread-Topic: [PATCH v6 01/13] xen/arm: Add suspend and resume timer helpers Thread-Index: AQHcG404ScLtR2ZKGku1UaXKdUHwsg== Date: Tue, 2 Sep 2025 20:14:32 +0000 Message-ID: <87h5xkwr14.fsf@epam.com> References: <781c8e1b3a4d9b269bfde125072a84baae3f9bb3.1756763487.git.mykola_kvach@epam.com> In-Reply-To: <781c8e1b3a4d9b269bfde125072a84baae3f9bb3.1756763487.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 2 Sep 2025 01:10:05 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|VI0PR03MB10568:EE_ x-ms-office365-filtering-correlation-id: f254f2fe-31f3-42da-2bd3-08ddea5d5471 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|42112799006|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?fqgMcROvA6ZDXsKbxZRUPChzSVrQGdQtOSJNly1L8MPgvkHsezfO0tVdJk?= =?iso-8859-1?Q?e0uO+7R0FV13FQ93Z/ozYitdBQyZux8ey/VJxP1LvzHr9fTx9d5pYu+XTb?= =?iso-8859-1?Q?UbRz754xoZKoCNxQ4YnVfWY7QM+bfNXz2kMSkUZo/0JX3xIUgHdO5HtmHY?= =?iso-8859-1?Q?eMlCHMo3Go2IlbAaECcSDGXcz7N3ba7Liy+bcLxnCUj7ioMvPBeT6L0U42?= =?iso-8859-1?Q?ay69ReiOw3Gn/zcqzcF+faCEHLsU2wJYtsa7Ki6GZ2YEZ92klAZHAY2R+K?= =?iso-8859-1?Q?a+sMfq0fXUlhcUdw1LYjHPxdowZkWmu1aajc+6z/3hz7kPIfR0FjLC1eNq?= =?iso-8859-1?Q?JpsG7zmffDmJ4dRAwBUEsLjy96NHBxP1My+rcpGjGMe/J75FWkkhxypJ+0?= =?iso-8859-1?Q?PUXmfB+uXmeAQ8CiY6SA5doLdXRMW+VaE6U/zC4RRSN6BpFbnStWFao3fY?= =?iso-8859-1?Q?thBxngcvP5WhxE6nruvRcBFF9GdHszgvKuvoMey/2odh1rBDFeimU2tpTU?= =?iso-8859-1?Q?FsJ/zK6U2exxn5vk2eFJGWFcN54EnqpW9aev0AbhEX4+HmqhDCSx+X5h5e?= =?iso-8859-1?Q?xjOfTq3sRECEXwPc7HLeoKDiZyK8CzRcZh7VywrKI2rH27dSXlGy254WED?= =?iso-8859-1?Q?a2VNEyCgXGYZSJnzBE9fuc3T+zOSX20baYs5YjINSS2uxWGtUEdIyPTLrT?= =?iso-8859-1?Q?66IVft9UJhBOdoCBQdoom8A6e4Z2//+jh+J0cH6BeSbz4nL68bC58FVmtR?= =?iso-8859-1?Q?qLiiM9Mw3asOkRT9KbqiwLybua28RkNZI8NsKLEBmBCoNtQCOWhlbRCaSn?= =?iso-8859-1?Q?nWKVoGTuB1HdSa2E1bl7uKlq+9nnb0Htgl+tdqf/MfBLA0V+S6NwazppAh?= =?iso-8859-1?Q?i9VTVgdDgIdpCXj9apUQCdvKNsk7M9lJXe2VkEhz9knjPwkqM2oghgCLov?= =?iso-8859-1?Q?OnAcz2J/HK3CLnhcaWCITC/8eWduFv13WA8JP47cZkWrGaNqypqcUKNTZL?= =?iso-8859-1?Q?rlnoJq0p29HbUbqnDeANVCy7NQ/n6y1CHj+Y6dWELtV9pWRQsgdHWLkC0o?= =?iso-8859-1?Q?vHwzDiWw2RA4k188uOKLPSLPD3jUDPpx1TW4GmWWnDET3EAq5ZAtFzE3KD?= =?iso-8859-1?Q?8GbZAdUU/jkN9ffv5wjx7kxWKqBrQ+nvilibQNDxsYeYPcXEP5Kitx6N8P?= =?iso-8859-1?Q?QZNCLyyeAmgn6gyHs7/vuxakiQ2CCSYBTS6tdgLjRdz4ThQrqjbTIkfrxc?= =?iso-8859-1?Q?cpytHwnYtlxJdiUoCU/WD0hvspWCvaGvw8MYJ6VjgI9MVQuwPUIT911JxF?= =?iso-8859-1?Q?fn2UoXMFecV6mVFeQmHkxTWa13S/J1fIJQafDTem2fPTFVFknlIN1ddFUe?= =?iso-8859-1?Q?75A2qyjpwN7tOgxGS6IebMhKZhaiVvxLA0zBr2tNRv8SGPH6ozQ2ZCI4Tv?= =?iso-8859-1?Q?436ggu3r0Pi7mOzV4JL9t9ek2tpQ/TmNigDO5idyltpfe0DaX1YDzSvlMK?= =?iso-8859-1?Q?fk1+i3/092FGxysgHeLl1Tbozc3UDyCCKMVmqojxFH7A=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(42112799006)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gIyJveTQ5riHfpMS0Jg4KmTAGZW+fthxVWNxW9tB73pnbM+EdrYL/t5itP?= =?iso-8859-1?Q?MSeGst7qblu0phxV2zbBA66ISUxRoyeBhQcbZj4H56v8rC+vMBhbEHzzQs?= =?iso-8859-1?Q?VO/gEuhGvwy0aIZ99Ez5abRbJohI8ZFWCYIehojO59PylwSqVWy8M9uR5w?= =?iso-8859-1?Q?ZVADj19bEcdleWZpkh6+H5BW2MBmBvNiB8AwOdNy/gRKU0QsEq4n85x5Zw?= =?iso-8859-1?Q?1EVYsv8TDpVOSBJzFsL3UkyFmS1s9gA6Sp44fxDPr+GaE5vEJ+QrzncHtQ?= =?iso-8859-1?Q?tEHxkQjqymDBqvDpB+NT0umDqpuGjMVEsNqvkgbpiNHTEONYDhlruOT7Oc?= =?iso-8859-1?Q?e3OGc8XKjrdgoXHkwmS/ciJbAW1CyBIHfmCfCSqjwZTrb2DvhFfqA/VKFD?= =?iso-8859-1?Q?NcewWVSm3kMmizEJDY1UycaaM7L7Kbz8p6zXFxvZ3PlCHVtOQmECZuv7ZF?= =?iso-8859-1?Q?zYUBfccgXJyNSRo6MwrdMywF/v/D8vBy3Vqlcrrnnig5TOzY0wD6OrQqTu?= =?iso-8859-1?Q?4dcEfWcg9Y3rwNUPSvHklChQZoZzLfsTcv7d3JqzFYmXn5VVeE5YZT5Raq?= =?iso-8859-1?Q?Mc0sYciDYHw2ik/KwdD7D6V5PF3aKNCVPw6yf9UnTUkl60vGivzQsXshMw?= =?iso-8859-1?Q?wif7zYly0x3FJ1lqrb7QCmOy553Nuvk+cW9pL3E1ci9Itcp/u1z3hY47bL?= =?iso-8859-1?Q?avH7gI72nD1Qer/+e+H7LFxvx8AYIt+wf8GE3Dx5OpYcj4RQnoQQ/D32Lh?= =?iso-8859-1?Q?f1bzeTALKSdzkXl/jHKpbcF23PhP/3pncoB+n159L1pdiW4q9nikFe9E/e?= =?iso-8859-1?Q?u71TNj+v6Oet/m/V7a0Y6XNmNOcMAmSBCwboVaGIMdvuVTPVpskCBZYZkT?= =?iso-8859-1?Q?9lGxK+k3CvmpOlCLu6DZwciqRLUzQQNr9SHp3OTsv7Ja/cuHQ/8+42oR06?= =?iso-8859-1?Q?ULI7sGVOqm6hs+1ABtpyXzeHGkJMuhgN3lbCdmiMlUQxQJgPCwuGbICQGT?= =?iso-8859-1?Q?z4VbTV0+Jn+07IzAXHI6sgLNLbMO0iwWh1ZS1wIvbtnJ8Bgd9PtwoOIwCi?= =?iso-8859-1?Q?RDhIVgK6wz9AX109AgyoHHy3Dq/VCROoq8Jsjs6TqfCJMTad5DJQnbN0AP?= =?iso-8859-1?Q?R7ivZ1Jgr8TYI1aI7vWrwL+3CrAB0AryHibVFdiMVrz9s0tm4Iemt9xLcl?= =?iso-8859-1?Q?In9TA2LQhJJsOF6dRcLiFXxVvFY7yEu71+43z+cYOJcNUjKS+QDP9EJFXL?= =?iso-8859-1?Q?C2d5Q7vLm5UhokxDhmHKyqrVn+B5hxSFz9citzuIkcvjY5riyTFjXdjMDz?= =?iso-8859-1?Q?ut9fLVOuqa9UxZZ1SoC0L+HVM1vAGcvXBDTC50BbebVXL8mCyk3gVdNjnQ?= =?iso-8859-1?Q?K5XJgxUi8YNhKjWgu+wW3nCsNeO73h6Juy+MbZLV8NPeAYfzBpPAPgLCBd?= =?iso-8859-1?Q?FLpGv8pCCeuHEMny4vkHH9WEK0SS1M7lN1hfvxXw89wGF5L6hGcprNqkRC?= =?iso-8859-1?Q?J5JhXz7MyWQUmPShW4vKv4uQoxbNorZKruayP8XPohXNCyvP+jWyJKnwR8?= =?iso-8859-1?Q?XWA26YI2QGduWrRvUqFZU1G7vd2wP5j0+GsYh+x4ZNY/AwLasSrScRtN1Q?= =?iso-8859-1?Q?QTWwy0CEbMLCm9OHzIWI8/x9IO6kdN1HE3DGFuanwGzt5LrLYrAu7c7w?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f254f2fe-31f3-42da-2bd3-08ddea5d5471 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:14:32.5163 (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: XcLnUAQqbeLjODvysTiPlD95eP5PGdU/ObD9GOmHIeFlAhdkBEoJhLCGmqclxESLK7NXskYMKlDFywvUtSW/7d8iDis9bNozr3nitxARClE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10568 Hi, Mykola Kvach writes: > From: Mirela Simonovic > > Timer interrupts must be disabled while the system is suspended to preven= t > 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 Reviewed-by: Volodymyr Babchuk > --- > 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/t= ime.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); > =20 > void force_update_vcpu_system_time(struct vcpu *v); > =20 > +#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, co= nst char *which) > "WARNING: %s-timer IRQ%u is not level triggered.\n", which, i= rq); > } > =20 > +/* 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 phys= ical 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(); > =20 > 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(); > =20 > 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 */ > } > =20 > +#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 do= wn, > + * 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 dom= ain." > + */ > + raise_softirq(TIMER_SOFTIRQ); > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > static int cpu_time_callback(struct notifier_block *nfb, > unsigned long action, > void *hcpu) --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:19:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:19:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107400.1457827 (Exim 4.92) (envelope-from ) id 1utXTb-0002Po-UK; Tue, 02 Sep 2025 20:19:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107400.1457827; Tue, 02 Sep 2025 20: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 1utXTb-0002Ph-RH; Tue, 02 Sep 2025 20:19:35 +0000 Received: by outflank-mailman (input) for mailman id 1107400; Tue, 02 Sep 2025 20:19: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 1utXTb-0002Pb-B8 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:19:35 +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 23258f48-883a-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:19:32 +0200 (CEST) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-55f72452a8eso3822679e87.3 for ; Tue, 02 Sep 2025 13:19: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: 23258f48-883a-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756844372; x=1757449172; 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=Cg5CC8giSLI9lHr4w/CbFA6ZTg9IkPNj6lNJrLtIztM=; b=HbChGueF8SJ5mDAZaXtBTPmkcPYVx6lSNqyFuF63FCLz8SBnZITzeNDzZcbbxqLcfP RRpKnVW1L5WJ+0ANEoQn3KvZHcB73DlCHoJmKU1N8CXy0fphjGmVDG7RAfofSauotgob rIjJ4rY3CHGIdg6EiDvkx6WnocAQ/oSEFDZRu+MgvjD4UgfEBw6trawijDKKpd7QsjQQ I/ccYSI4e1loUYqr5W6ywQyLZ4VNe5TGPCu3MArhmVhUVZatyUe1TDG5LPz019ZEWr0E Quv6pay0C92r2ztrBZMTaMVseF4B1A+WAiHDKMhWdEfgMaj8S4ukRbuPpQQ/avnCOljN XYhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756844372; x=1757449172; 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=Cg5CC8giSLI9lHr4w/CbFA6ZTg9IkPNj6lNJrLtIztM=; b=fYAukayRODHLsm3eY8ZlT/1y4/0mqQ5ldxDlAaUAZ3eks+Kdha/Eg+YNOUXAK1pX+1 RNrjBNSIF6QVVzr5Bf+hkDaQskRgx9bhGPiwrkKRdCXdXoqzJ5JJuCyAOJdoqqz4uf1B diDDU9h5USlDzNuvQl8U2Kcf7RsyX20iXEMLvVgDvu1uCwIdxxtQDzD3ogWkLH6ssneu B+CBeML8QzH7YeC7/xsgpW40dUqUJYRzVNVKAsQWgoCpjO56HAHS1R88qSbiOn68KpbW EIdEXu6MT5OOgU0AYVzjehuY2gdlCzAOD11u7J9anN+r6jmTuyPDhOzJ8ymM44vOs+af b85A== X-Gm-Message-State: AOJu0YzK+L6MrPdF1/8hNxFH5W/Ttw4f2BkGDOZHpQLGzhG9XiiS56Jy oOR3HlRczDlznCF52JEotW0ik0nK7+0JF5H16fNj9k76zFKyZlU9WpGtdaDg22+gMnEHgvRaS+q QwC9xXNRdIjYoHu4JF2r4PASalhkS7XI= X-Gm-Gg: ASbGncvMiD+y94iNplOAHGi63bViTVCoq1HX3E81cv1Ub7+vkRBEsDjtjCQW28s4ri4 xTNYLIFf42shnVhZtF3Cw8YTdyM0CVf7e+5nQwGR3TlshlJZsUvaqHjdMmQcovtmZNNK0osldMX jiXzxIm+mgdo31v94534XlwO8tWFEhb4OZScKSLwQEYuhlDyLbHAcPCwLW4wswftZw9+O7Tn7yX Et6QHRDxm+/A07h X-Google-Smtp-Source: AGHT+IEAINxbtFlFQyPaFDgwf4yU9NLGLtstkjlQM0k5sBtufP5f2W0dEhtr0zEjUeNzjNdCw0eT9Q238VjMBlKi1eg= X-Received: by 2002:a05:6512:4017:b0:55f:63ef:b2b3 with SMTP id 2adb3069b0e04-55f708b7024mr3258255e87.22.1756844371809; Tue, 02 Sep 2025 13:19:31 -0700 (PDT) MIME-Version: 1.0 References: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> In-Reply-To: From: Mykola Kvach Date: Tue, 2 Sep 2025 23:19:20 +0300 X-Gm-Features: Ac12FXwwKHNF0p6YG3oQafV25qOuzWb1DLqsCKI-22JhNXOziPuxpU8271CuIAA Message-ID: Subject: Re: [PATCH v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 11:08=E2=80=AFPM Mykola Kvach wrote: > > On Tue, Sep 2, 2025 at 9:16=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > > > > > On 02.09.25 20:43, Mykola Kvach wrote: > > > Hi Oleksandr, > > > > Hello Mykola > > > > > > > > On Tue, Sep 2, 2025 at 7:49=E2=80=AFPM Oleksandr Tyshchenko wrote: > > >> > > >> > > >> > > >> On 02.09.25 01:10, Mykola Kvach wrote: > > >> > > >> Hello Mykola > > >> > > >>> 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 I= RQ > > >>> state is restored early during CPU bring-up after suspend. > > >>> > > >>> Signed-off-by: Mykola Kvach > > >>> --- > > >>> Changes in V6: > > >>> - Call handler->disable() instead of just setting the _IRQ_DISABLED= flag > > >>> - Move the system state check outside of restore_local_irqs_on_resu= me() > > >>> --- > > >>> xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ > > >>> 1 file changed, 39 insertions(+) > > >>> > > >>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > > >>> index 6c899347ca..ddd2940554 100644 > > >>> --- a/xen/arch/arm/irq.c > > >>> +++ b/xen/arch/arm/irq.c > > >>> @@ -116,6 +116,41 @@ static int init_local_irq_data(unsigned int cp= u) > > >>> 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; > > >> > > >> NIT: Please, use "unsigned int" if irq cannot be negative > > > > > > ok > > > > > >> > > >>> + > > >>> + spin_lock(&local_irqs_type_lock); > > >>> + > > >>> + for ( irq =3D 0; irq < NR_LOCAL_IRQS; irq++ ) > > >>> + { > > >>> + struct irq_desc *desc =3D irq_to_desc(irq); > > >>> + > > >>> + spin_lock(&desc->lock); > > >>> + > > >>> + if ( test_bit(_IRQ_DISABLED, &desc->status) ) > > >>> + { > > >>> + spin_unlock(&desc->lock); > > >>> + continue; > > >>> + } > > >>> + > > >>> + /* Disable the IRQ to avoid assertions in the following ca= lls */ > > >>> + desc->handler->disable(desc); > > >>> + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); > > >> > > >> Shouldn't we use GIC_PRI_IPI for SGIs? > > > > > > Yes, we should. But currently I am restoring the same value > > > as it was before suspend... > > > > > > I definitely agree that this needs to be fixed at the original > > > place where the issue was introduced, but I was planning to > > > address it in a future patch. > > > > > >> > > >> > > >>> + desc->handler->startup(desc); > > >>> + > > >>> + spin_unlock(&desc->lock); > > >>> + } > > >>> + > > >>> + spin_unlock(&local_irqs_type_lock); > > >>> +} > > >>> + > > >>> static int cpu_callback(struct notifier_block *nfb, unsigned lon= g action, > > >>> void *hcpu) > > >>> { > > >>> @@ -134,6 +169,10 @@ 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: > > >>> + if ( system_state =3D=3D SYS_STATE_resume ) > > >>> + restore_local_irqs_on_resume(); > > >>> + break; > > >> > > >> May I please ask, why all this new code (i.e. > > >> restore_local_irqs_on_resume()) is not covered by #ifdef > > >> CONFIG_SYSTEM_SUSPEND? > > > > > > I don=E2=80=99t see a reason to introduce such "macaron-style" code. = On ARM, the > > > system suspend state is only set when CONFIG_SYSTEM_SUSPEND is define= d > > > anyway. > > > > right > > > > > > > > If you would prefer me to wrap all relevant code with this define, pl= ease > > > let me know and I=E2=80=99ll make the change. In this case, I think t= he current > > > approach is cleaner, but I=E2=80=99m open to your opinion. > > > > In other patches, you seem to wrap functions/code that only get called > > during suspend/resume with #ifdef CONFIG_SYSTEM_SUSPEND, so I wondered > > why restore_local_irqs_on_resume() could not be compiled out > > if the feature is not enabled. But if you still think it would be > > cleaner this way (w/o #ifdef), I would be ok. > > It=E2=80=99s not entirely true -- I only wrapped code that has a direct d= ependency > on host_system_suspend(), either being called from it or required for its > correct operation. > > If you look through this patch series for the pattern: > SYS_STATE_(suspend|resume) > > you=E2=80=99ll see that not all suspend/resume-related code is wrapped in > #ifdef CONFIG_SYSTEM_SUSPEND. This is intentional -- the same applies to > some code already merged into the common parts of Xen. > > So restore_local_irqs_on_resume is consistent with the existing approach > in all cpu notifier blocks. Of course, I can wrap all code in this patch series if needed. For me, the current approach looks clearer and aligns with existing code. On the other hand, I introduced this config option not so long ago, so that may be why some parts in common code and even in some architectures like x86 are still uncovered. In any case, I don't mind covering all the code if you think it would be be= tter. Right now, this implementation is mainly my preference and aligns with the existing code. There isn't any other reasoning behind this decision. > > > > > > > > >> > > >>> } > > >>> > > >>> return notifier_from_errno(rc); > > >> > > > > > > Best regards, > > > Mykola > > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:20:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:20:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107411.1457837 (Exim 4.92) (envelope-from ) id 1utXUX-0003q0-6f; Tue, 02 Sep 2025 20:20:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107411.1457837; Tue, 02 Sep 2025 20: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 1utXUX-0003pt-3V; Tue, 02 Sep 2025 20:20:33 +0000 Received: by outflank-mailman (input) for mailman id 1107411; Tue, 02 Sep 2025 20:20:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXUW-0003pn-Bd for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:20:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utXUV-0033HQ-1q; Tue, 02 Sep 2025 20:20:31 +0000 Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utXUV-00DZLI-1n; Tue, 02 Sep 2025 20: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" 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=cavwInxVrptAo+kg5d+eS1AAfpE5abQwXQa8JwJOk4M=; b=cFVZkB4/vPyhLJns/1mfyAZ0Za oknJt1pATn1AssFwL1ZfjWNUSzI4LWDWqv33K1663LlQxF/zgqxJF/qikO1KpUOeWlI1y1Ks0iz6Q 0nqSkpUtqmAaLWNt+ZlWJuwBg5FjXI8oj1XYLDf+aQKgNR+1y55ARps4u2vhqRSmeGHY=; Message-ID: Date: Tue, 2 Sep 2025 21:20:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> <06ff285f-39d5-4ffd-b842-6d776bb793ac@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Leonid, On 02/09/2025 18:26, Leonid Komarianskyi wrote: > Hi Julien, > > Thank you for your review and suggestions. > > On 02.09.25 19:55, Julien Grall wrote: >> Hi Leonid, >> >> On 29/08/2025 17:06, Leonid Komarianskyi wrote: >>> @@ -782,46 +804,81 @@ static int >>> __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v, >>>       { >>>       case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN): >>>       case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN): >>> +    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN): >>> +    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN): >>>           /* We do not implement security extensions for guests, write >>> ignore */ >>>           goto write_ignore_32; >>>       case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN): >>> +    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN): >>>           if ( dabt.size != DABT_WORD ) goto bad_width; >>> -        rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD); >>> +        if ( reg >= GICD_ISENABLERnE ) >>> +            rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE, >>> +                                        DABT_WORD); >>> +        else >>> +            rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, >>> DABT_WORD); >> >> While I understand the desire to try to avoid code duplication. I feel >> this is making the code a lot more complicating and in fact riskier >> because... >> >>>           if ( rank == NULL ) goto write_ignore; >>>           vgic_lock_rank(v, rank, flags); >>>           tr = rank->ienable; >>>           vreg_reg32_setbits(&rank->ienable, r, info); >>> -        vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); >>> +        if ( reg >= GICD_ISENABLERnE ) >>> +            vgic_enable_irqs(v, (rank->ienable) & (~tr), >>> +                             EXT_RANK_IDX2NUM(rank->index)); >>> +        else >>> +            vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); >> >> ... you now have to keep both "if" the same. Unless we can have a >> version to avoid "ifs" everywhere (maybe using macros), I would rather >> create a separate funciton to handle eSPIs. >> >> Cheers, >> > > The main idea of V5 of this patch is to consolidate similar code and > keep the pairs of regular SPIs and their eSPI counterparts in the same > place to simplify any future modifications of these pairs. If > eSPI-specific registers are moved to a separate function, it would > result in code duplication. Additionally, I think it would be easier to > miss updating the code for one register of the SPI/eSPI pair while > modifying the code for the other.. I understand your reasoning, but in this case, we need to try to keep the code as common as possible and reduce the number of ifs. Looking at the patch again, we seem to often use "EXT_RANK_IDX2NUM(rank->index)" and this is why we have the second "if", for instance here. I think it would be preferable if "index" store the proper value. An alternative would be to process the 3rd parameters separately. The next big one to takle is: if ( reg >= ... ) vgic_ext_rank_...(...) else vgic_rank(...) Ideally I would like to provide an helper that can figure out whether this is an eSPI or not. Looking at the pattern, I think we would introduce a new helper which rather than taking a relative offset take the reg offset, the base for SPIs and the base for eSPIs. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:24:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:24:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107421.1457846 (Exim 4.92) (envelope-from ) id 1utXYj-0004Y8-Mi; Tue, 02 Sep 2025 20:24:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107421.1457846; Tue, 02 Sep 2025 20:24:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXYj-0004Y1-K0; Tue, 02 Sep 2025 20:24:53 +0000 Received: by outflank-mailman (input) for mailman id 1107421; Tue, 02 Sep 2025 20:24: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 1utXYi-0004Xv-L6 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:24:52 +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 e0ba9135-883a-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 22:24:51 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by AS8PR03MB7045.eurprd03.prod.outlook.com (2603:10a6:20b:292::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 20:24:48 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:24: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: e0ba9135-883a-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JgHeip0LW95Zu/YcT/82qaJHv0nH+52edFtSi73lbjfneY0N4QPfBwbDM2va7AjM/mPe8xFmjF/oWs6Mkom9HOIawnir+Gss/ZMGVzR8UQFe4nHqRX3c0ZzBU2nUMaoNitPIkS9BF9aPqqmd0pqiOSLZ5FmOlggIiv8P/+LOjmRw3VuWNXGZnJpm5d0YaxE62gwYS+getZ1WARECOkjHTV8TqafrSdU1d7IdRgmRJ7q+Hg+NLMOmAqvYkMZXw9xk/Ktaz6dp0zGGJdIi0kvS58c0EwMBs7E4/o7xcnBu/T1cXK50sbyQU5U4hqzoZK+mjy6svAcUkPieaTQyY1tn4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H0ik1lznqMMrLqd0xDEoVWrIluYUBTH0G2GXDRvtSpg=; b=DxgveCbqQelz1HVVEKwskwMWj+wMZ4otjlW5SPIe96hPcx9nipbqJ+XQ83uJLfMJrZN9RNNUDnTnxfyJEzD0HC98Wh5bP8YT9O+is53wPYEtSIKdp5Tznfeh8wCqCR5zpvhYrwv3iQdIdYZHd+4SudmNr7FF1IF2nHsXD1GSP5xjD1uTjuoqUrF5ZxPmwBv+K3eIAyO0CCb3P8lxtaXbaQw1VdhWqVItGUGAN9HrOxvAZk0NgD7zKq6lMe6rnq52kbJDGrlb7gLxhhVUa0je5ZGkZsTdEvWNIcusKdAmGbFcZH/JSTrLVyDIgW+0IgUqyj3vIeBK96FhGestqz+4og== 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=H0ik1lznqMMrLqd0xDEoVWrIluYUBTH0G2GXDRvtSpg=; b=m5zkAQF+89P+H0yrdCAdgBOWja1SKzA/3YB5/UeoJfieep2ol6dF0DXfFiIXe1v3sXv2nUtaqBgLD61M0LaM50PtNkIeoc8ZEmBepVt+2dIqFr1UBivqGJe0rpmOPdfEb4QhjnjUtnZ7JQB6PIVR+h3JdcTTShOPqb+v8Kmv9DvTOcsu0/TQt4i3nykkXUrzjDr2ixfs1fQ1IbemLcq6sRWen72Qwi6djTNTqLTIw8tvGHVSsAO4NbBKl0bKNknzQJrJPCxKD5aOhGUOztyXoZRMQiMXlVJV5JFViqRb/1Ejcip0E0J0Z040ULNjVzw4C8uerDRuwCOE261Qjbr8ZQ== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Thread-Topic: [PATCH v5 08/12] xen/arm: vgic: add resource management for extended SPIs Thread-Index: AQHcGP7gzxYtqJZFyUiPTlrb5XV2MbR/9acAgABnm4A= Date: Tue, 2 Sep 2025 20:24:48 +0000 Message-ID: <5ae0fe27-a5be-4bb2-93ee-88f59398889d@epam.com> References: <4b13dea924eabf1370d3f31030f3eef48371de06.1756481577.git.leonid_komarianskyi@epam.com> <49e321c0-d23f-48f0-a979-add2a6bccb50@xen.org> In-Reply-To: <49e321c0-d23f-48f0-a979-add2a6bccb50@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: GV2PR03MB8678:EE_|AS8PR03MB7045:EE_ x-ms-office365-filtering-correlation-id: 365284ff-e2ef-4292-f5f7-08ddea5ec364 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?akc1TW5qSjB2STI4YXd2WlZJcVlsaStTaGlwcGJKOHlmQ2lzTWUwYkFPWlk2?= =?utf-8?B?UzZCeWZDb1BVNm1sb3FIMTBOZUcyZlJ0dE0zdW9TZjRrU0VZaGFDMElMZ3NG?= =?utf-8?B?UTlvaU1Zb04vaHZJc0Y2N0crb2Y2bWZTd1VKR003bE40cVY3dmlBcE12WTJO?= =?utf-8?B?Z1pMU3Q1MWhtN2w4VDBCRTJ5TWpWRUtjTFArK3hMZUliMmIrTmovSGZjMFJG?= =?utf-8?B?WWVMVURlcGtGVUcrRmE2K2ZwczJOOWFmeFlMbzd5aExldWEweEpnbE9LQlNa?= =?utf-8?B?Nm9SVk9paTBZeWE5dnNGNFAyOWIyQmJlVVhuN1RaR21IM0VqcEc5L3AvNStN?= =?utf-8?B?RE01bWN1eS9jV0R1Wit0M25NOE5iNTZPT1JRWkNmSjRERUhVUSs4bjRuZlZY?= =?utf-8?B?SS9iUHg1UnNaS01lazk5WEdEUkg3azRHdlJ6MCszajk5RHMwemlpaEsvNFpD?= =?utf-8?B?RFZ4TUxwc2c3MVhaMEoyTHprVjVpWVBWZHZRRm5vekgvMzVUOGhGREpvbVFa?= =?utf-8?B?dUtnMmJGZmxOT09RVjgzRk4raEJOdC8wZlI3UWxSdC9FYko5eGxZcDluRXNr?= =?utf-8?B?ZFROUmN3WXBOY3FuWnpPbEZCTkNDa0RhYmpDR2UwbVRhUDNZdmNuRmhQM3c5?= =?utf-8?B?VTJYZEE3eU5EeHZOTDFnSEZibW9pemxRaEdRcmVPVEFGaTlKU1g3amhVc1Y5?= =?utf-8?B?a0pValZkbHJQZEQxVXFtWHFwNjNiSTJlQjlud0JEYkUvbWwyNUV6QTMvUFpp?= =?utf-8?B?Sk02NkhqOHdsbVZoczhFOUdhcDhFT0VQaUxjUmtWaU5VYitMMVdPQy9MNW5u?= =?utf-8?B?YUh0Z2p5d3kwYThSU3A2YUtxTTRjVXd6NFlYaHBVTkp3SG5JODZpb2tzQ1pL?= =?utf-8?B?TXhlM0w4eFB2ejRENENtRlBuaFVQUUxqS21tc3NHNTNkY0dNRnRHbmdMUkRp?= =?utf-8?B?MHAzeGd2YzFYN0pRZFdpaC9Tb1J1cVVyZk5lR3VmU3U0NlBFR3V0RFJVeU1L?= =?utf-8?B?bXZodjd3eUpCUWZHdmltUG1CUEJndGpZSFNBeDZScFVYb2NMa0hrazlBMXRQ?= =?utf-8?B?ZUtTZWRVNFA0VVB4QktEREc5Znp3Qmp3d2I5Y05MTGh0UGdYc2twWkpiVk5j?= =?utf-8?B?NEV0L2k2ZTdkaC91aXJMbHloV3dBY1VNMTkyUnU1SEYxUHczSys1c0R1azU1?= =?utf-8?B?ck5YVkhHTUwreTRKbXhnNmNtcFA4bHJOK3ZoRVdmd0hxN0JNajZuWFlpRmkx?= =?utf-8?B?WlpJZmoxK1hXbkdFQWp5eHRyYW5xMWluM3RIWFhWTng3T2tQTUMyUjdFN2c1?= =?utf-8?B?OVZuMFpXamIya0JUanc2WEs2ajhidy9mMTErNVkxOUZ1clJDbTBlOW1BRVY3?= =?utf-8?B?UXBVaGZJMnpEbk9GT3VWVE9Qa0J6SWlHTEJ6VUxwUUFTS215eHRWTXV1OGQ2?= =?utf-8?B?cVQ0RUVucGFtcVo3Z0ZNSVEycjBlS1Z1RkppRDFHQ3RodE44R25ZWVBqczVL?= =?utf-8?B?V3pYKy9lNnpHa0tibFhpa1pZd1lIZmZWV0NZZ3dXUWgway9GcTUvbW5sWGwy?= =?utf-8?B?cE02aGZPVytYRndkakJpQVI4dmJITWRWdnlWTFNXc25NR1pSdlRlWWdYUnpX?= =?utf-8?B?YmdYWURYUFdKeGJhMzVSakZ0cjR5bVNnb3VmRUtWVnY2eDQxVkRtSDlsRmo2?= =?utf-8?B?QWJjUjFIS0xXRFJMQWtQWFlHSjlVQWdzWnN6bCttWlptM3kxUlMrNHFNUEwy?= =?utf-8?B?RDB4bHgwcWo5dzhWNG03dzVkdnFOdlBtZExWRFlZUTZHYzM1K09NYWEybWlX?= =?utf-8?B?Y3RnTHo5K3dJbTd4eFk3ZVJXRWR4aW14T0Z5UHh6NUhNYzk3WTEwRzZsc3pn?= =?utf-8?B?WHVSbVhqMnlzenkyejhhY0hCMWd0aGYvUGFMcU5SSjVVcUtwTTlCUGQxb1lY?= =?utf-8?B?OEs4N2NGMnQ2Vk11b0c0VVZRbGJQckNUVjRPY1ZMWUVnTndNNGdQdlFoM2tW?= =?utf-8?B?bC91YmU5TlpBPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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?RTdXWTRwOE50NFgzaTAvc1JZVDZIY3pmeWlXSVhleTM0a3hIajB1MHEzZXky?= =?utf-8?B?V2FKK1p5N1hGOFd6dVFVSTdTWlRFdW9ld01yVUNFcjFvbWVuY1hNdGo5azlo?= =?utf-8?B?VDR6dE41VndGSkdML3NHSUloUkZTaUlkMk1zWGI0OEJ3NVBNaTVSS2lIcWkw?= =?utf-8?B?M2hScG5PNndhcDltTklZRnBsNXE1Zms4dHFsU0NBMXBTdTJhdFlHNnNZUmxR?= =?utf-8?B?ckU0VUp0K2ExV3d0eEhJNk5waHZYb3duWHJNSHNuT09ua0tHK3c2cmpRLy9U?= =?utf-8?B?WnROcTdXTUQySzcxdWZuZ1BNZjFkcVVuMkhSY3l0RGZyUDF0Nlg2a0NMYlAw?= =?utf-8?B?NXE1WmNSeEVBd3lLRGFaeXh4YzJLbldValg2VkxhY1hZNVh2Wk5kM2thRW5n?= =?utf-8?B?VzQyN0ZQSzFZU21iUVYzT3hXd1Y2OGRwTER0aTBVYlNLVkxXdmtHTkVLYzgr?= =?utf-8?B?b0QrdkVkZGRRbW1JaFZVRVdlSlpPbUVsOThYckNXekI5YTRVWFNabm9FSmlH?= =?utf-8?B?QW5xTmI4WEVhQTFRdTZiR1o1U21ITzZhS2F6ODlYazNaekxxT0I1T0wzMU9R?= =?utf-8?B?L3ZSa3l4WWtMQ3RtL2MvTVhjeVorckVPVVNTaXlGYVlUeHlxdFQ3MkhEamRl?= =?utf-8?B?VnlJY2c1cEh1czRuMDVoTVhLZWc0MnoxRFN5Q05JWlRuaVIzdkY4eWd2RERB?= =?utf-8?B?QzNvcnJvaDB3MUVXR2ZkWjRHOStBKzdoYStNNWdzZnJSMWdvL2dpWVJLT2FL?= =?utf-8?B?R3RVUVg0QTJnb0FEWHRtOGFPSEFBUDNDcnBBRWhqZUN4RllmQ0hHMy9ud0I0?= =?utf-8?B?OUllaWwrYWc2UUZBSFJXaldpdnI5L0puRzNjekhTdFZ1Vk4wWVpyODkyN2p1?= =?utf-8?B?OHprNVoxUFlWbTZkamVMZmFudGdnalZvVVdXQVo4ZHVTNDFDSldZWWFGNS92?= =?utf-8?B?MitYTWVYTHphVUVjTGZuUWd5eENoR2w0Rm5PcHByK25kSndoTWxxamJyaThB?= =?utf-8?B?KzhLMUJzcjFnbHNJVG45YzNzWUNhWDhuSHJaWnBKTXA2RjNDNVU0bHc0Sm5H?= =?utf-8?B?aCtxKzNmYzk2dWZya3ZhV0JnZ2VnL09JVE8yVFlNL2dUT2VocGdNRFZ0czN4?= =?utf-8?B?T0pydUEzL2l1dXl2d0NaRW9lekpzTHhBcEYwOG5sa0JudmFHT1pwSkxiU3l0?= =?utf-8?B?bFlFMkRXMDlZOE5BeDZrSWc3NTd3dThIb1FrY1FkNSt2V3lxNUxNL0hmSGZN?= =?utf-8?B?U0MzZHJ4SmlReFJFNS94UHF0MnpDS09jVUw0VWplaEVpNzYzMjJpWE1lYlBl?= =?utf-8?B?cEowNk5vaHF0REU0YjUyRGZFdFRrS1Z4TTBvT2syb3J0Tm04RWhtRThPUmd5?= =?utf-8?B?bGxyY1czdjFqbit4NkJBN0x6TENiaFZTcTFYZjhzRW5kb0liQ0pUbHBIMTZN?= =?utf-8?B?V05jMUZWV3FsNmRVTnFTZzZ0Sk14aWNhemFvZU5Pd1pHOUZzTXZHOThodS9h?= =?utf-8?B?RkZrY04xWFBtVHdrU05mVjExeTJwL054cTBYYjR4VDVtNi9zMklic2F6RGFo?= =?utf-8?B?L3JDczFMb2pCb2ZUVG1qZ2IvaUpCK0wxVjR5ZlAvN1gxMy80ellDK20wT3lz?= =?utf-8?B?OUZ0dWhIUDdBMnJXTG4rRnhBVE8yWjlDa2NIdW1CUWxqUDhDVEpIT1VwdS91?= =?utf-8?B?bkQ2TFlyaFl5Y0RwVFBDL1BTbWJabmlTakpUT0lqNXpMbUxxMjdZWVNzd29E?= =?utf-8?B?SHFzM3ZGKzRHdWF6OWZpMDBRMklZZ1M2dE5wb0hldWUxS0t5bXhCa0lqWUxF?= =?utf-8?B?a1BhYUNhZE5DVXNlZU5yM201dkdCQUNtbGJGZGtjTjJxbmVlT3BRbWEzZkov?= =?utf-8?B?WkJ2TmhQdWtQRHpRcWVkdWIyaUdyYWdNR0ZMaklrSzRaUUdMUmlseXRNSFZK?= =?utf-8?B?RndqOVErNktTUDRHVUdQNU5aQkRCQW1nelJZa0VOeER0SFpVcHIwMUg0K1hE?= =?utf-8?B?YjNobFJUdXlQWmU2dTR5eFNhYjZ0MVBWQ3JHWVA3M3AzOFdwSTlXV3gyeEhv?= =?utf-8?B?UlAxQ1ZzaU4xdWZiYnZONWVaZmZtdXlNWTFPUDhucVREaVBKZUZRM0xaK29T?= =?utf-8?B?WitPTmFVb3RPTk9XTURNS0lEN3B6TkwzKzJZL2JMQ2RudjE3SnNxMEZrbFNL?= =?utf-8?Q?1VlvMbVOzsyz0KYNtKRFkfc=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <552C2FFF8DF8D14DB13908C4D2A92943@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 365284ff-e2ef-4292-f5f7-08ddea5ec364 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:24:48.2225 (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: ML5r5GPchaUj5qsuf8bBRQt//DiSw5KATa6gy/QPhvc4YziQ6fWg1e7v1uRiqs/28xlUwaRtq0SOBRH9OTvRBNcu0kmM3eIhQPDs7FQSOAI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7045 SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzIGFuZCB5b3Vy IHF1ZXN0aW9uLg0KDQpPbiAwMi4wOS4yNSAxNzoxMywgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBI aSBMZW9uaWQsDQo+IA0KPiBPbiAyOS8wOC8yMDI1IDE3OjA2LCBMZW9uaWQgS29tYXJpYW5za3lp IHdyb3RlOg0KPj4gVGhpcyBjaGFuZ2UgaW50cm9kdWNlcyByZXNvdXJjZSBtYW5hZ2VtZW50IGlu IHRoZSBWR0lDIHRvIGhhbmRsZQ0KPj4gZXh0ZW5kZWQgU1BJcyBpbnRyb2R1Y2VkIGluIEdJQ3Yz LjEuIFRoZSBwZW5kaW5nX2lycXMgYW5kDQo+PiBhbGxvY2F0ZWRfaXJxcyBhcnJheXMgYXJlIHJl c2l6ZWQgdG8gc3VwcG9ydCB0aGUgcmVxdWlyZWQNCj4+IG51bWJlciBvZiBlU1BJcywgYmFzZWQg b24gd2hhdCBpcyBzdXBwb3J0ZWQgYnkgdGhlIGhhcmR3YXJlIGFuZA0KPj4gcmVxdWVzdGVkIGJ5 IHRoZSBndWVzdC4gQSBuZXcgZmllbGQsIGV4dF9zaGFyZWRfaXJxcywgaXMgYWRkZWQNCj4+IHRv IHRoZSBWR0lDIHN0cnVjdHVyZSB0byBzdG9yZSBpbmZvcm1hdGlvbiBhYm91dCBlU1BJcywgc2lt aWxhcg0KPj4gdG8gaG93IHNoYXJlZF9pcnFzIGlzIHVzZWQgZm9yIHJlZ3VsYXIgU1BJcy4NCj4+ DQo+PiBTaW5jZSB0aGUgZVNQSSByYW5nZSBzdGFydHMgYXQgSU5USUQgNDA5NiBhbmQgSU5USURz IGJldHdlZW4gMTAyNQ0KPj4gYW5kIDQwOTUgYXJlIHJlc2VydmVkLCBoZWxwZXIgbWFjcm9zIGFy ZSBpbnRyb2R1Y2VkIHRvIHNpbXBsaWZ5IHRoZQ0KPj4gdHJhbnNmb3JtYXRpb24gb2YgaW5kaWNl cyBhbmQgdG8gZW5hYmxlIGVhc2llciBhY2Nlc3MgdG8gZVNQSS1zcGVjaWZpYw0KPj4gcmVzb3Vy Y2VzLiBUaGVzZSBjaGFuZ2VzIHByZXBhcmUgdGhlIFZHSUMgZm9yIHByb2Nlc3NpbmcgZVNQSXMg YXMNCj4+IHJlcXVpcmVkIGJ5IGZ1dHVyZSBmdW5jdGlvbmFsaXR5Lg0KPj4NCj4+IFRoZSBpbml0 aWFsaXphdGlvbiBhbmQgZGVpbml0aWFsaXphdGlvbiBwYXRocyBmb3IgdmdpYyBoYXZlIGJlZW4g dXBkYXRlZA0KPj4gdG8gYWxsb2NhdGUgYW5kIGZyZWUgdGhlc2UgcmVzb3VyY2VzIGFwcHJvcHJp YXRlbHkuIEFkZGl0aW9uYWxseSwNCj4+IHVwZGF0ZWQgaGFuZGxpbmcgb2YgSU5USURzIGdyZWF0 ZXIgdGhhbiAxMDI0LCBwYXNzZWQgZnJvbSB0aGUgdG9vbHN0YWNrDQo+PiBkdXJpbmcgZG9tYWlu IGNyZWF0aW9uLCBhbmQgdmVyaWZpY2F0aW9uIGxvZ2ljIGVuc3VyZXMgb25seSB2YWxpZCBTUEkg b3INCj4+IGVTUEkgSU5USURzIGFyZSB1c2VkLg0KPj4NCj4+IFRoZSBleGlzdGluZyBTUEkgYmVo YXZpb3IgcmVtYWlucyB1bmFmZmVjdGVkIHdoZW4gZ3Vlc3RzIGRvIG5vdCByZXF1ZXN0DQo+PiBl U1BJcywgR0lDIGhhcmR3YXJlIGRvZXMgbm90IHN1cHBvcnQgdGhlbSwgb3IgdGhlIENPTkZJR19H SUNWM19FU1BJDQo+PiBvcHRpb24gaXMgZGlzYWJsZWQuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTog TGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4NCj4+DQo+ PiAtLS0NCj4+IENoYW5nZXMgaW4gVjU6DQo+PiAtIHJlbW92ZWQgdGhlIGhhc19lc3BpIGZpZWxk IGJlY2F1c2UgaXQgY2FuIGJlIGRldGVybWluZWQgYnkgY2hlY2tpbmcNCj4+IMKgwqAgd2hldGhl ciBkb21haW4tPmFyY2gudmdpYy5ucl9lc3BpcyBpcyB6ZXJvIG9yIG5vdA0KPj4gLSBzaW5jZSB2 Z2ljX2V4dF9yYW5rX29mZnNldCBpcyBub3QgdXNlZCBpbiB0aGlzIHBhdGNoLCBpdCBoYXMgYmVl bg0KPj4gwqDCoCBtb3ZlZCB0byB0aGUgYXBwcm9wcmlhdGUgcGF0Y2ggaW4gdGhlIHBhdGNoIHNl cmllcywgd2hpY2ggaW1wbGVtZW50cw0KPj4gwqDCoCB2Z2ljIGVTUEkgcmVnaXN0ZXJzIGVtdWxh dGlvbiBhbmQgcmVxdWlyZXMgdGhpcyBmdW5jdGlvbg0KPj4gLSByZW1vdmVkIGlmZGVmcyBmb3Ig ZVNQSS1zcGVjaWZpYyBtYWNyb3MgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgaWZkZWZzDQo+PiDC oMKgIGFuZCBjb2RlIGR1cGxpY2F0aW9uIGluIGZ1cnRoZXIgY2hhbmdlcw0KPj4gLSBmaXhlZCBt aW5vciBuaXQ6IHVzZWQgJXBkIGZvciBwcmludGluZyBkb21haW4gd2l0aCBpdHMgSUQNCj4+DQo+ PiBDaGFuZ2VzIGluIFY0Og0KPj4gLSBhZGRlZCBoYXNfZXNwaSBmaWVsZCB0byBzaW1wbGlmeSBk ZXRlcm1pbmluZyB3aGV0aGVyIGEgZG9tYWluIGlzIGFibGUNCj4+IMKgwqAgdG8gb3BlcmF0ZSB3 aXRoIGVTUEkNCj4+IC0gZml4ZWQgZm9ybWF0dGluZyBpc3N1ZXMgYW5kIG1pc3NwZWxsaW5ncw0K Pj4NCj4+IENoYW5nZXMgaW4gVjM6DQo+PiAtIGZpeGVkIGZvcm1hdHRpbmcgZm9yIGxpbmVzIHdp dGggbW9yZSB0aGFuIDgwIHN5bWJvbHMNCj4+IC0gaW50cm9kdWNlZCBoZWxwZXIgZnVuY3Rpb25z IHRvIGJlIGFibGUgdG8gdXNlIHN0dWJzIGluIGNhc2Ugb2YNCj4+IMKgwqAgQ09ORklHX0dJQ1Yz X0VTUEkgZGlzYWJsZWQsIGFuZCBhcyBhIHJlc3VsdCwgcmVkdWNlIHRoZSBudW1iZXIgb2YNCj4+ IMKgwqAgI2lmZGVmcw0KPj4gLSBmaXhlZCBjaGVja3MgZm9yIG5yX3NwaXMgaW4gZG9tYWluX3Zn aWNfaW5pdA0KPj4gLSB1cGRhdGVkIGNvbW1lbnQgYWJvdXQgbnJfc3BpcyBhZGp1c3RtZW50cyB3 aXRoIGRvbTBsZXNzIG1lbnRpb24NCj4+IC0gbW92ZWQgY29tbWVudCB3aXRoIGFkZGl0aW9uYWwg ZXhwbGFuYXRpb25zIGJlZm9yZSBjaGVja3MNCj4+IC0gdXNlZCB1bnNpZ25lZCBpbnQgZm9yIGlu ZGV4ZXMgc2luY2UgdGhleSBjYW5ub3QgYmUgbmVnYXRpdmUNCj4+IC0gcmVtb3ZlZCB1bm5lY2Vz c2FyeSBwYXJlbnRoZXNlcw0KPj4gLSBtb3ZlIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0IHRvIHRoZSBi ZWxvdyBpZmRlZiBndWFyZCwgdG8gcmVkdWNlIHRoZQ0KPj4gwqDCoCBudW1iZXIgb2YgaWZkZWZz DQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMjoNCj4+IC0gY2hhbmdlIGlzX2VzcGlfcmFuayB0byBpc192 YWxpZF9lc3BpX3JhbmsgdG8gdmVyaWZ5IHdoZXRoZXIgdGhlIGFycmF5DQo+PiDCoMKgIGVsZW1l bnQgZXh0X3NoYXJlZF9pcnFzIGV4aXN0cy4gVGhlIHByZXZpb3VzIHZlcnNpb24sIGlzX2VzcGlf cmFuaywNCj4+IMKgwqAgb25seSBjaGVja2VkIGlmIHRoZSByYW5rIGluZGV4IHdhcyBsZXNzIHRo YW4gdGhlIG1heGltdW0gcG9zc2libGUgZVNQSQ0KPj4gwqDCoCByYW5rIGluZGV4LCBidXQgdGhp cyBjb3VsZCBwb3RlbnRpYWxseSByZXN1bHQgaW4gYWNjZXNzaW5nIGENCj4+IMKgwqAgbm9uLWV4 aXN0aW5nIGFycmF5IGVsZW1lbnQuIFRvIGFkZHJlc3MgdGhpcywgaXNfdmFsaWRfZXNwaV9yYW5r IHdhcw0KPj4gwqDCoCBpbnRyb2R1Y2VkLCB3aGljaCBlbnN1cmVzIHRoYXQgdGhlIHJlcXVpcmVk IGVTUEkgcmFuayBleGlzdHMNCj4+IC0gbW92ZSBnaWNfbnVtYmVyX2VzcGlzIHRvDQo+PiDCoMKg IHhlbi9hcm06IGdpY3YzOiBpbXBsZW1lbnQgaGFuZGxpbmcgb2YgR0lDdjMuMSBlU1BJDQo+PiAt IHVwZGF0ZSB2Z2ljX2lzX3ZhbGlkX2lycSBjaGVja3MgdG8gYWxsb3cgb3BlcmF0aW5nIHdpdGgg ZVNQSXMNCj4+IC0gcmVtb3ZlIHJlZHVuZGFudCBuZXdsaW5lIGluIHZnaWNfYWxsb2NhdGVfdmly cQ0KPj4gLS0tDQo+PiDCoCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oIHzCoCAxMiAr Kw0KPj4gwqAgeGVuL2FyY2gvYXJtL3ZnaWMuY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IDE5 OSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPj4gwqAgMiBmaWxlcyBjaGFuZ2Vk LCAyMDggaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEv eGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlLyAN Cj4+IGFzbS92Z2ljLmgNCj4+IGluZGV4IDNlN2NiYmIxOTYuLjkxMmQ1Yjc2OTQgMTAwNjQ0DQo+ PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oDQo+PiArKysgYi94ZW4vYXJj aC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oDQo+PiBAQCAtMTQ2LDYgKzE0NiwxMCBAQCBzdHJ1Y3Qg dmdpY19kaXN0IHsNCj4+IMKgwqDCoMKgwqAgaW50IG5yX3NwaXM7IC8qIE51bWJlciBvZiBTUElz ICovDQo+PiDCoMKgwqDCoMKgIHVuc2lnbmVkIGxvbmcgKmFsbG9jYXRlZF9pcnFzOyAvKiBiaXRt YXAgb2YgSVJRcyBhbGxvY2F0ZWQgKi8NCj4+IMKgwqDCoMKgwqAgc3RydWN0IHZnaWNfaXJxX3Jh bmsgKnNoYXJlZF9pcnFzOw0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gK8KgwqDC oCBzdHJ1Y3QgdmdpY19pcnFfcmFuayAqZXh0X3NoYXJlZF9pcnFzOw0KPj4gK8KgwqDCoCBpbnQg bnJfZXNwaXM7IC8qIE51bWJlciBvZiBleHRlbmRlZCBTUElzICovDQo+IA0KPiBGb3IgbmV3IGNv ZGUsIHdlIHByZWZlciB1c2luZyAidW5zaWduZWQgaW50IiB3aGVuIHRoZSB2YWx1ZSBpcyBtZWFu dCB0byANCj4gYmUgPj0gMC4NCj4gDQoNClN1cmUsIE9sZWtzYW5kciBoYXMgYWxyZWFkeSBzcG90 dGVkIHRoaXMuIEkgd2lsbCBjaGFuZ2UgdGhlIHR5cGUgdG8gDQp1bnNpZ25lZCBpbiBWNi4NCg0K Pj4gKyNlbmRpZg0KPj4gwqDCoMKgwqDCoCAvKg0KPj4gwqDCoMKgwqDCoMKgICogU1BJcyBhcmUg ZG9tYWluIGdsb2JhbCwgU0dJcyBhbmQgUFBJcyBhcmUgcGVyLVZDUFUgYW5kIHN0b3JlZCBpbg0K Pj4gwqDCoMKgwqDCoMKgICogc3RydWN0IGFyY2hfdmNwdS4NCj4+IEBAIC0yNDMsNiArMjQ3LDE0 IEBAIHN0cnVjdCB2Z2ljX29wcyB7DQo+PiDCoCAvKiBOdW1iZXIgb2YgcmFua3Mgb2YgaW50ZXJy dXB0IHJlZ2lzdGVycyBmb3IgYSBkb21haW4gKi8NCj4+IMKgICNkZWZpbmUgRE9NQUlOX05SX1JB TktTKGQpICgoKGQpLT5hcmNoLnZnaWMubnJfc3BpcyszMSkvMzIpDQo+PiArI2lmZGVmIENPTkZJ R19HSUNWM19FU1BJDQo+PiArI2RlZmluZSBET01BSU5fTlJfRVhUX1JBTktTKGQpICgoKGQpLT5h cmNoLnZnaWMubnJfZXNwaXMrMzEpLzMyKQ0KPj4gKyNlbmRpZg0KPj4gKyNkZWZpbmUgRVhUX1JB TktfTUlOIChFU1BJX0JBU0VfSU5USUQvMzIpDQo+PiArI2RlZmluZSBFWFRfUkFOS19NQVggKChF U1BJX01BWF9JTlRJRCszMSkvMzIpDQo+PiArI2RlZmluZSBFWFRfUkFOS19OVU0ySURYKG51bSkg KChudW0pLUVYVF9SQU5LX01JTikNCj4+ICsjZGVmaW5lIEVYVF9SQU5LX0lEWDJOVU0oaWR4KSAo KGlkeCkrRVhUX1JBTktfTUlOKQ0KPiANCj4gRm9yIHRoZSA2IGxpbmVzIGFib3ZlLCBwbGVhc2Ug YWRkIHNwYWNlIGJlZm9yZSBhbmQgYWZ0ZXIgdGhlIG9wZXJhdG9ycy4NCj4gDQoNCkkgd2lsbCBm aXggZm9ybWF0dGluZyBpbiBWNi4NCg0KPj4gKw0KPj4gwqAgI2RlZmluZSB2Z2ljX2xvY2sodinC oMKgIHNwaW5fbG9ja19pcnEoJih2KS0+ZG9tYWluLT5hcmNoLnZnaWMubG9jaykNCj4+IMKgICNk ZWZpbmUgdmdpY191bmxvY2sodikgc3Bpbl91bmxvY2tfaXJxKCYodiktPmRvbWFpbi0+YXJjaC52 Z2ljLmxvY2spDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3ZnaWMuYyBiL3hlbi9hcmNo L2FybS92Z2ljLmMNCj4+IGluZGV4IDJiYmY0ZDk5YWEuLmM5Yjk1MjhjNjYgMTAwNjQ0DQo+PiAt LS0gYS94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+ PiBAQCAtMjcsOSArMjcsODIgQEANCj4+IMKgIGJvb2wgdmdpY19pc192YWxpZF9saW5lKHN0cnVj dCBkb21haW4gKmQsIHVuc2lnbmVkIGludCB2aXJxKQ0KPj4gwqAgew0KPj4gKyNpZmRlZiBDT05G SUdfR0lDVjNfRVNQSQ0KPj4gK8KgwqDCoCBpZiAoIHZpcnEgPj0gRVNQSV9CQVNFX0lOVElEICYm DQo+PiArwqDCoMKgwqDCoMKgwqDCoCB2aXJxIDwgRVNQSV9JRFgySU5USUQoZC0+YXJjaC52Z2lj Lm5yX2VzcGlzKSApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIHRydWU7DQo+PiArI2VuZGlm DQo+PiArDQo+PiDCoMKgwqDCoMKgIHJldHVybiB2aXJxIDwgdmdpY19udW1faXJxcyhkKTsNCj4+ IMKgIH0NCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICsvKg0KPj4gKyAqIFNpbmNl IGVTUEkgaW5kZXhlcyBzdGFydCBmcm9tIDQwOTYgYW5kIG51bWJlcnMgZnJvbSAxMDI0IHRvDQo+ PiArICogNDA5NSBhcmUgZm9yYmlkZGVuLCB3ZSBuZWVkIHRvIGNoZWNrIGJvdGggbG93ZXIgYW5k IHVwcGVyDQo+PiArICogbGltaXRzIGZvciByYW5rcy4NCj4+ICsgKi8NCj4+ICtzdGF0aWMgaW5s aW5lIGJvb2wgaXNfdmFsaWRfZXNwaV9yYW5rKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGlu dCANCj4+IHJhbmspDQo+PiArew0KPj4gK8KgwqDCoCByZXR1cm4gcmFuayA+PSBFWFRfUkFOS19N SU4gJiYNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoCBFWFRfUkFOS19OVU0ySURYKHJhbmspIDwg RE9NQUlOX05SX0VYVF9SQU5LUyhkKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGlubGluZSBz dHJ1Y3QgdmdpY19pcnFfcmFuayAqdmdpY19nZXRfZXNwaV9yYW5rKHN0cnVjdCB2Y3B1ICp2LA0K Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1 bnNpZ25lZCBpbnQgDQo+PiByYW5rKQ0KPj4gK3sNCj4+ICvCoMKgwqAgcmV0dXJuICZ2LT5kb21h aW4tIA0KPj4gPmFyY2gudmdpYy5leHRfc2hhcmVkX2lycXNbRVhUX1JBTktfTlVNMklEWChyYW5r KV07DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgYm9vbCB2Z2ljX3Jlc2VydmVfZXNw aV92aXJxKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIA0KPj4gaW50IHZpcnEpDQo+PiArew0K Pj4gK8KgwqDCoCByZXR1cm4gIXRlc3RfYW5kX3NldF9iaXQoRVNQSV9JTlRJRDJJRFgodmlycSkg KyB2Z2ljX251bV9pcnFzKGQpLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGQtPmFyY2gudmdpYy5hbGxvY2F0ZWRfaXJxcyk7DQo+ PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGFyY2hfbW92ZV9lc3BpcyhzdHJ1Y3QgdmNwdSAq dikNCj4+ICt7DQo+PiArwqDCoMKgIGNvbnN0IGNwdW1hc2tfdCAqY3B1X21hc2sgPSBjcHVtYXNr X29mKHYtPnByb2Nlc3Nvcik7DQo+PiArwqDCoMKgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21h aW47DQo+PiArwqDCoMKgIHN0cnVjdCBwZW5kaW5nX2lycSAqcDsNCj4+ICvCoMKgwqAgc3RydWN0 IHZjcHUgKnZfdGFyZ2V0Ow0KPiANCj4gY3B1X21hc2ssIHAgYW5kIHZfdGFyZ2V0IG9ubHkgc2Vl bXMgdG8gYmUgdXNlZCB3aXRoaW4gdGhlIGxvb3AuIElmIA0KPiB0aGF0J3MgY29ycmVjdCwgdGhl biBwbGVhc2UgbW92ZSB0aGUgZGVmaW5pdGlvbiB3aXRoaW4gdGhlIGxvb3AuDQo+IA0KDQpUaGlz IGZ1bmN0aW9uIHdpbGwgYmUgcmVtb3ZlZCAodGhhbmtzIHRvIFZvbG9keW15cidzIHN1Z2dlc3Rp b24gd2l0aCANCmhlbHBlciBmdW5jdGlvbiksIGFuZCBJIHdpbGwgcmV1c2UgdGhlIGV4aXN0aW5n IGNvZGUgaW4gVjYuDQoNCj4+ICvCoMKgwqAgdW5zaWduZWQgaW50IGk7DQo+PiArDQo+PiArwqDC oMKgIGZvciAoIGkgPSBFU1BJX0JBU0VfSU5USUQ7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgIGkg PCBFWFRfUkFOS19JRFgyTlVNKGQtPmFyY2gudmdpYy5ucl9lc3Bpcyk7IGkrKyApDQo+PiArwqDC oMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCB2X3RhcmdldCA9IHZnaWNfZ2V0X3RhcmdldF92Y3B1 KHYsIGkpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIHAgPSBpcnFfdG9fcGVuZGluZyh2X3RhcmdldCwg aSk7DQo+PiArDQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCB2X3RhcmdldCA9PSB2ICYmICF0ZXN0 X2JpdChHSUNfSVJRX0dVRVNUX01JR1JBVElORywgJnAtIA0KPj4gPnN0YXR1cykgKQ0KPj4gK8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqAgaXJxX3NldF9hZmZpbml0eShwLT5kZXNjLCBjcHVfbWFzayk7 DQo+PiArwqDCoMKgIH0NCj4+ICt9DQo+PiArI2Vsc2UNCj4+ICtzdGF0aWMgaW5saW5lIGJvb2wg aXNfdmFsaWRfZXNwaV9yYW5rKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCANCj4+IHJh bmspDQo+PiArew0KPj4gK8KgwqDCoCByZXR1cm4gZmFsc2U7DQo+PiArfQ0KPj4gKw0KPj4gKy8q DQo+PiArICogVGhpcyBmdW5jdGlvbiBpcyBzdHViIGFuZCB3aWxsIG5vdCBiZSBjYWxsZWQgaWYg Q09ORklHX0dJQ1YzX0VTUEk9biwNCj4+ICsgKiBiZWNhdXNlIGluIHRoaXMgY2FzZSwgaXNfdmFs aWRfZXNwaV9yYW5rIHdpbGwgYWx3YXlzIHJldHVybiBmYWxzZS4NCj4+ICsgKi8NCj4+ICtzdGF0 aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9lc3BpX3Jhbmsoc3RydWN0 IHZjcHUgKnYsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHVuc2lnbmVkIGludCANCj4+IHJhbmspDQo+PiArew0KPj4gK8KgwqDCoCBBU1NF UlRfVU5SRUFDSEFCTEUoKTsNCj4+ICvCoMKgwqAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gKw0K Pj4gK3N0YXRpYyBpbmxpbmUgYm9vbCB2Z2ljX3Jlc2VydmVfZXNwaV92aXJxKHN0cnVjdCBkb21h aW4gKmQsIHVuc2lnbmVkIA0KPj4gaW50IHZpcnEpDQo+PiArew0KPj4gK8KgwqDCoCByZXR1cm4g ZmFsc2U7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGFyY2hfbW92ZV9lc3BpcyhzdHJ1 Y3QgdmNwdSAqdikgeyB9DQo+PiArI2VuZGlmDQo+PiArDQo+PiDCoCBzdGF0aWMgaW5saW5lIHN0 cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9yYW5rKHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBy YW5rKQ0KPj4gwqAgew0KPj4gQEAgLTM3LDYgKzExMCw4IEBAIHN0YXRpYyBpbmxpbmUgc3RydWN0 IHZnaWNfaXJxX3JhbmsgDQo+PiAqdmdpY19nZXRfcmFuayhzdHJ1Y3QgdmNwdSAqdiwNCj4+IMKg wqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gdi0+YXJjaC52Z2ljLnByaXZhdGVfaXJxczsNCj4+IMKg wqDCoMKgwqAgZWxzZSBpZiAoIHJhbmsgPD0gRE9NQUlOX05SX1JBTktTKHYtPmRvbWFpbikgKQ0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAmdi0+ZG9tYWluLT5hcmNoLnZnaWMuc2hhcmVk X2lycXNbcmFuayAtIDFdOw0KPj4gK8KgwqDCoCBlbHNlIGlmICggaXNfdmFsaWRfZXNwaV9yYW5r KHYtPmRvbWFpbiwgcmFuaykgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiB2Z2ljX2dldF9l c3BpX3JhbmsodiwgcmFuayk7DQo+PiDCoMKgwqDCoMKgIGVsc2UNCj4+IMKgwqDCoMKgwqDCoMKg wqDCoCByZXR1cm4gTlVMTDsNCj4+IMKgIH0NCj4+IEBAIC0xMTcsNiArMTkyLDYyIEBAIGludCBk b21haW5fdmdpY19yZWdpc3RlcihzdHJ1Y3QgZG9tYWluICpkLCANCj4+IHVuc2lnbmVkIGludCAq bW1pb19jb3VudCkNCj4+IMKgwqDCoMKgwqAgcmV0dXJuIDA7DQo+PiDCoCB9DQo+PiArI2lmZGVm IENPTkZJR19HSUNWM19FU1BJDQo+PiArc3RhdGljIHVuc2lnbmVkIGludCB2Z2ljX251bV9zcGlf bGluZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArwqDCoMKgIHJldHVybiBkLT5hcmNo LnZnaWMubnJfc3BpcyArIGQtPmFyY2gudmdpYy5ucl9lc3BpczsNCj4+ICt9DQo+PiArDQo+PiAr c3RhdGljIGludCBpbml0X3ZnaWNfZXNwaShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICvC oMKgwqAgdW5zaWduZWQgaW50IGksIGlkeDsNCj4+ICsNCj4+ICvCoMKgwqAgaWYgKCBkLT5hcmNo LnZnaWMubnJfZXNwaXMgPT0gMCApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIDA7DQo+PiAr DQo+PiArwqDCoMKgIGQtPmFyY2gudmdpYy5leHRfc2hhcmVkX2lycXMgPQ0KPj4gK8KgwqDCoMKg wqDCoMKgIHh6YWxsb2NfYXJyYXkoc3RydWN0IHZnaWNfaXJxX3JhbmssIERPTUFJTl9OUl9FWFRf UkFOS1MoZCkpOw0KPj4gK8KgwqDCoCBpZiAoIGQtPmFyY2gudmdpYy5leHRfc2hhcmVkX2lycXMg PT0gTlVMTCApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FTk9NRU07DQo+PiArDQo+PiAr wqDCoMKgIGZvciAoIGkgPSBkLT5hcmNoLnZnaWMubnJfc3BpcywgaWR4ID0gMDsNCj4+ICvCoMKg wqDCoMKgwqDCoMKgwqAgaSA8IHZnaWNfbnVtX3NwaV9saW5lcyhkKTsgaSsrLCBpZHgrKyApDQo+ PiArwqDCoMKgwqDCoMKgwqAgdmdpY19pbml0X3BlbmRpbmdfaXJxKCZkLT5hcmNoLnZnaWMucGVu ZGluZ19pcnFzW2ldLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgRVNQSV9JRFgySU5USUQoaWR4KSk7DQo+PiArDQo+PiArwqDC oMKgIGZvciAoIGkgPSAwOyBpIDwgRE9NQUlOX05SX0VYVF9SQU5LUyhkKTsgaSsrICkNCj4+ICvC oMKgwqDCoMKgwqDCoCB2Z2ljX3JhbmtfaW5pdCgmZC0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJx c1tpXSwgaSwgMCk7DQo+PiArDQo+PiArwqDCoMKgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ ICtzdHJ1Y3QgcGVuZGluZ19pcnEgKmVzcGlfdG9fcGVuZGluZyhzdHJ1Y3QgZG9tYWluICpkLCB1 bnNpZ25lZCBpbnQgaXJxKQ0KPj4gK3sNCj4+ICvCoMKgwqAgaXJxID0gRVNQSV9JTlRJRDJJRFgo aXJxKSArIGQtPmFyY2gudmdpYy5ucl9zcGlzOw0KPj4gK8KgwqDCoCByZXR1cm4gJmQtPmFyY2gu dmdpYy5wZW5kaW5nX2lycXNbaXJxXTsNCj4+ICt9DQo+PiArI2Vsc2UNCj4+ICtzdGF0aWMgdW5z aWduZWQgaW50IGluaXRfdmdpY19lc3BpKHN0cnVjdCBkb21haW4gKmQpDQo+PiArew0KPj4gK8Kg wqDCoCByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHVuc2lnbmVkIGludCB2Z2lj X251bV9zcGlfbGluZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArwqDCoMKgIHJldHVy biBkLT5hcmNoLnZnaWMubnJfc3BpczsNCj4+ICt9DQo+PiArDQo+PiArc3RydWN0IHBlbmRpbmdf aXJxICplc3BpX3RvX3BlbmRpbmcoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IGlycSkN Cj4+ICt7DQo+PiArwqDCoMKgIHJldHVybiBOVUxMOw0KPj4gK30NCj4+ICsjZW5kaWYNCj4+ICsN Cj4+ICtzdGF0aWMgdW5zaWduZWQgaW50IHZnaWNfbnVtX2FsbG9jX2lycXMoc3RydWN0IGRvbWFp biAqZCkNCj4+ICt7DQo+PiArwqDCoMKgIHJldHVybiB2Z2ljX251bV9zcGlfbGluZXMoZCkgKyBO Ul9MT0NBTF9JUlFTOw0KPj4gK30NCj4+ICsNCj4+IMKgIGludCBkb21haW5fdmdpY19pbml0KHN0 cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBucl9zcGlzKQ0KPj4gwqAgew0KPj4gwqDCoMKg wqDCoCBpbnQgaTsNCj4+IEBAIC0xMzEsNiArMjYyLDM2IEBAIGludCBkb21haW5fdmdpY19pbml0 KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIA0KPj4gaW50IG5yX3NwaXMpDQo+PiDCoMKgwqDC oMKgwqAgKi8NCj4+IMKgwqDCoMKgwqAgbnJfc3BpcyA9IFJPVU5EVVAobnJfc3BpcywgMzIpOw0K Pj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gK8KgwqDCoCAvKg0KPj4gK8KgwqDCoMKg ICogRHVyaW5nIGRvbWFpbiBjcmVhdGlvbiwgdGhlIGRvbTBsZXNzIERvbVVzIGNvZGUgb3IgdG9v bHN0YWNrIA0KPj4gc3BlY2lmaWVzDQo+PiArwqDCoMKgwqAgKiB0aGUgbWF4aW11bSBJTlRJRCwg d2hpY2ggaXMgZGVmaW5lZCBpbiB0aGUgZG9tYWluIGNvbmZpZyANCj4+IHN1YnRyYWN0ZWQgYnkN Cj4+ICvCoMKgwqDCoCAqIDMyIHRvIGNvdmVyIHRoZSBsb2NhbCBJUlFzIChwbGVhc2Ugc2VlIHRo ZSBjb21tZW50IHRvIA0KPj4gVkdJQ19ERUZfTlJfU1BJUykuDQo+PiArwqDCoMKgwqAgKiBUbyBj b21wdXRlIHRoZSBhY3R1YWwgbnVtYmVyIG9mIGVTUEkgdGhhdCB3aWxsIGJlIHVzYWJsZSBmb3Is DQo+PiArwqDCoMKgwqAgKiBhZGQgYmFjayAzMi4NCj4+ICvCoMKgwqDCoCAqLw0KPj4gK8KgwqDC oCBpZiAoIG5yX3NwaXMgKyAzMiA+IEVTUElfSURYMklOVElEKE5SX0VTUElfSVJRUykgKQ0KPj4g K8KgwqDCoMKgwqDCoMKgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4gK8KgwqDCoCBpZiAoIG5y X3NwaXMgKyAzMiA+PSBFU1BJX0JBU0VfSU5USUQgKQ0KPj4gK8KgwqDCoCB7DQo+PiArwqDCoMKg wqDCoMKgwqAgZC0+YXJjaC52Z2ljLm5yX2VzcGlzID0gbWluKG5yX3NwaXMgLSBFU1BJX0JBU0Vf SU5USUQgKyAzMiwgDQo+PiAxMDI0VSk7DQo+IA0KPiBXZSBzaG91bGQgcmV0dXJuIGFuIGVycm9y IHJhdGhlciB0aGFuIHNpbGVudGx5IGNhcHBpbmcgdGhlIHZhbHVlLg0KPiANCj4+ICvCoMKgwqDC oMKgwqDCoCAvKiBWZXJpZnkgaWYgR0lDIEhXIGNhbiBoYW5kbGUgcHJvdmlkZWQgSU5USUQgKi8N Cj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIGQtPmFyY2gudmdpYy5ucl9lc3BpcyA+IGdpY19udW1i ZXJfZXNwaXMoKSApDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVJTlZBTDsN Cj4+ICvCoMKgwqDCoMKgwqDCoCAvKg0KPj4gK8KgwqDCoMKgwqDCoMKgwqAgKiBTZXQgdGhlIG1h eGltdW0gYXZhaWxhYmxlIG51bWJlciBmb3IgcmVndWxhcg0KPj4gK8KgwqDCoMKgwqDCoMKgwqAg KiBTUEkgdG8gcGFzcyB0aGUgbmV4dCBjaGVjaw0KPj4gK8KgwqDCoMKgwqDCoMKgwqAgKi8NCj4g DQo+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIHJld29yayB0aGUgY29kZSBzbyB0aGUg Y2hlY2sgaXMgbm90IGNhbGxlZC4NCj4gDQoNCkkgd2lsbCByZXdvcmsgdGhlIGNvZGUgaW4gVjYs IHRoYW5rcy4NCg0KPj4gK8KgwqDCoMKgwqDCoMKgIG5yX3NwaXMgPSBWR0lDX0RFRl9OUl9TUElT Ow0KPj4gK8KgwqDCoCB9DQo+PiArwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqAgew0KPj4gK8KgwqDC oMKgwqDCoMKgIC8qIERvbWFpbiB3aWxsIHVzZSB0aGUgcmVndWxhciBTUEkgcmFuZ2UgKi8NCj4+ ICvCoMKgwqDCoMKgwqDCoCBkLT5hcmNoLnZnaWMubnJfZXNwaXMgPSAwOw0KPj4gK8KgwqDCoCB9 DQo+PiArI2VuZGlmDQo+PiArDQo+PiDCoMKgwqDCoMKgIC8qIExpbWl0IHRoZSBudW1iZXIgb2Yg dmlydHVhbCBTUElzIHN1cHBvcnRlZCB0byAoMTAyMCAtIDMyKSA9IA0KPj4gOTg4wqAgKi8NCj4+ IMKgwqDCoMKgwqAgaWYgKCBucl9zcGlzID4gKDEwMjAgLSBOUl9MT0NBTF9JUlFTKSApDQo+PiDC oMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FSU5WQUw7DQo+PiBAQCAtMTQ1LDcgKzMwNiw3IEBA IGludCBkb21haW5fdmdpY19pbml0KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIA0KPj4gaW50 IG5yX3NwaXMpDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FTk9NRU07DQo+PiDCoMKg wqDCoMKgIGQtPmFyY2gudmdpYy5wZW5kaW5nX2lycXMgPQ0KPj4gLcKgwqDCoMKgwqDCoMKgIHh6 YWxsb2NfYXJyYXkoc3RydWN0IHBlbmRpbmdfaXJxLCBkLT5hcmNoLnZnaWMubnJfc3Bpcyk7DQo+ PiArwqDCoMKgwqDCoMKgwqAgeHphbGxvY19hcnJheShzdHJ1Y3QgcGVuZGluZ19pcnEsIHZnaWNf bnVtX3NwaV9saW5lcyhkKSk7DQo+PiDCoMKgwqDCoMKgIGlmICggZC0+YXJjaC52Z2ljLnBlbmRp bmdfaXJxcyA9PSBOVUxMICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVOT01FTTsN Cj4+IEBAIC0xNTYsMTIgKzMxNywxNiBAQCBpbnQgZG9tYWluX3ZnaWNfaW5pdChzdHJ1Y3QgZG9t YWluICpkLCB1bnNpZ25lZCANCj4+IGludCBucl9zcGlzKQ0KPj4gwqDCoMKgwqDCoCBmb3IgKCBp ID0gMDsgaSA8IERPTUFJTl9OUl9SQU5LUyhkKTsgaSsrICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCB2Z2ljX3JhbmtfaW5pdCgmZC0+YXJjaC52Z2ljLnNoYXJlZF9pcnFzW2ldLCBpICsgMSwgMCk7 DQo+PiArwqDCoMKgIHJldCA9IGluaXRfdmdpY19lc3BpKGQpOw0KPj4gK8KgwqDCoCBpZiAoIHJl dCApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIHJldDsNCj4+ICsNCj4+IMKgwqDCoMKgwqAg cmV0ID0gZC0+YXJjaC52Z2ljLmhhbmRsZXItPmRvbWFpbl9pbml0KGQpOw0KPj4gwqDCoMKgwqDC oCBpZiAoIHJldCApDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIHJldDsNCj4+IMKgwqDC oMKgwqAgZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzID0NCj4+IC3CoMKgwqDCoMKgwqDCoCB4 emFsbG9jX2FycmF5KHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9fTE9OR1ModmdpY19udW1faXJxcyhk KSkpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIHh6YWxsb2NfYXJyYXkodW5zaWduZWQgbG9uZywgDQo+ PiBCSVRTX1RPX0xPTkdTKHZnaWNfbnVtX2FsbG9jX2lycXMoZCkpKTsNCj4+IMKgwqDCoMKgwqAg aWYgKCAhZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCByZXR1cm4gLUVOT01FTTsNCj4+IEBAIC0xOTUsOSArMzYwLDI3IEBAIHZvaWQgZG9tYWluX3Zn aWNfZnJlZShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIH0NCj4+IMKg wqDCoMKgwqAgfQ0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gK8KgwqDCoCBmb3Ig KCBpID0gMDsgaSA8IGQtPmFyY2gudmdpYy5ucl9lc3BpczsgaSsrICkNCj4gDQo+IE5vdyB3ZSBh cmUgcG90ZW50aWFsbHkgZG91YmxpbmcgdXAgdGhlIG51bWJlciBvZiBJUlFzIHdlIGhhdmUgdG8g DQo+IHJlbGVhc2UuIEkgYW0gbm90IGVudGlyZWx5IHN1cmUgdGhpcyBpcyBzdGlsbCBvayB0byBk byBpdCB3aXRob3V0IGFueSANCj4gcHJlZW1wdGlvbi4gRG8geW91IGhhdmUgYW55IGRhdGE/DQo+ IA0KDQpJIG1hZGUgc29tZSBtZWFzdXJlbWVudHMgb24gb3VyIGhhcmR3YXJlICh1bmZvcnR1bmF0 ZWx5LCB3ZSBjdXJyZW50bHkgDQpjYW5ub3QgZW5hYmxlIGFsbCBkZXZpY2VzIHRvIHVzZSBtb3Jl IElSUXMpLiBIb3dldmVyLCBJIG9ic2VydmVkIGEgDQpsaW5lYXIgdGltZSBkZXBlbmRlbmN5IGJh c2VkIG9uIHRoZSBudW1iZXIgb2YgSVJRcywgc28gSSBiZWxpZXZlIHdlIGNhbiANCmV4dHJhcG9s YXRlIHRoZSBkYXRhLg0KDQpJIHByZXBhcmVkIHNvbWUgY2hhbmdlcyBmb3IgVjYgYWNjb3JkaW5n IHRvIHRoZSBjb21tZW50cyAodGhpcyBpcyBub3QgDQp0aGUgZmluYWwgc29sdXRpb24sIGJ1dCBJ IGNhbiBzdGlsbCBtZWFzdXJlIHRoZSB0aW1lKS4gSSBhZGRlZCBhIGZldyANCm1vcmUgbGluZXMg b2YgY29kZSB0byBtZWFzdXJlIHRoZSBlbGFwc2VkIHRpbWU6DQoNCnZvaWQgZG9tYWluX3ZnaWNf ZnJlZShzdHJ1Y3QgZG9tYWluICpkKQ0Kew0KICAgICBzdHJ1Y3QgcGVuZGluZ19pcnEgKnA7DQog ICAgIHVuc2lnbmVkIGludCBpLCB2aXJxOw0KICAgICBpbnQgcmV0Ow0KICAgICB1bnNpZ25lZCBp bnQgcmVsc2VzZWQgPSAwOw0KICAgICBzX3RpbWVfdCBzdGFydCA9IE5PVygpLCBkaWZmOw0KDQog ICAgIGZvciAoIGkgPSAzMjsgaSA8IHZnaWNfbnVtX2FsbG9jX2lycXMoZCk7IGkrKyApDQogICAg IHsNCiAgICAgICAgIHZpcnEgPSBpZHhfdG9fdmlycShkLCBpKTsNCiAgICAgICAgIHAgPSBzcGlf dG9fcGVuZGluZyhkLCB2aXJxKTsNCg0KICAgICAgICAgaWYgKCBwLT5kZXNjICkNCiAgICAgICAg IHsNCiAgICAgICAgICAgICByZWxzZXNlZCsrOw0KICAgICAgICAgICAgIHJldCA9IHJlbGVhc2Vf Z3Vlc3RfaXJxKGQsIHAtPmlycSk7DQogICAgICAgICAgICAgaWYgKCByZXQgKQ0KICAgICAgICAg ICAgICAgICBkcHJpbnRrKFhFTkxPR19HX1dBUk5JTkcsICJkJXU6IEZhaWxlZCB0byByZWxlYXNl IHZpcnEgDQoldSByZXQgPSAlZFxuIiwNCiAgICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21h aW5faWQsIHAtPmlycSwgcmV0KTsNCiAgICAgICAgIH0NCiAgICAgfQ0KICAgICBkaWZmID0gTk9X KCkgLSBzdGFydDsNCiAgICAgcHJpbnRrKCJ0aW1lIGVsYXBzZWQgPSAlbHUgbnMgKCVsdSB1cywg JWx1IG1zKSByZWxlYXNlZCA9ICV1IElSUXNcbiIsDQogICAgICAgICAgICBkaWZmLCBkaWZmIC8g MTAwMCwgZGlmZiAvIDEwMDAwMDAsIHJlbHNlc2VkKTsNCg0KUGxlYXNlIG5vdGUgdGhhdCB2Z2lj X251bV9hbGxvY19pcnFzKGQpIGluIFY2IHdpbGwgb3BlcmF0ZSBhY3Jvc3MgdGhlIA0KZnVsbCBJ UlEgcmFuZ2UsIGluY2x1ZGluZyB0aGUgZVNQSXMuIEkgYWxzbyBjaGVja2VkIG11bHRpcGxlIHRp bWVzIGFuZCANCm9idGFpbmVkIGNvbnNpc3RlbnQgcmVzdWx0cy4NCkhlcmUgYXJlIHRoZSBtZWFz dXJlbWVudHM6DQoNCnRpbWUgZWxhcHNlZCA9IDQ4NTE0NSBucyAoNDg1IHVzLCAwIG1zKSByZWxl YXNlZCA9IDEwMCBJUlFzDQp0aW1lIGVsYXBzZWQgPSA5NTQxOTYgbnMgKDk1NCB1cywgMCBtcykg cmVsZWFzZWQgPSAyMDAgSVJRcw0KdGltZSBlbGFwc2VkID0gMTkyMTcxMiBucyAoMTkyMSB1cywg MSBtcykgcmVsZWFzZWQgPSA0MDAgSVJRcw0KDQpBbHNvLCB0aGUgaW5kZXggY29udmVyc2lvbiBh bmQgc3BpX3RvX3BlbmRpbmcoKSBkbyBub3QgdGFrZSBtdWNoIHRpbWUsIA0KYXMgdGhleSBhcmUg cXVpdGUgc2ltcGxlIG9wZXJhdGlvbnMuIFRoZSBtb3N0IHRpbWUtY29uc3VtaW5nIG9wZXJhdGlv biANCmlzIHJlbGVhc2VfZ3Vlc3RfaXJxKCksIGJ1dCBpdCBpcyBpbnZva2VkIG9ubHkgd2hlbiBh biBJUlEgaXMgYXNzaWduZWQgDQp0byBhIGRvbWFpbi4NCg0KU28sIHJlbGVhc2luZyBldmVyeSAx MDAgSVJRcyB3aGlsZSBkZXN0cm95aW5nIGRvbWFpbiB0YWtlcyBhcHByb3hpbWF0ZWx5IA0KNTAw IHVzIG9uIG91ciBzZXR1cC4gVGhlcmVmb3JlLCByZWxlYXNpbmcgdGhlIG1heGltdW0gSVJRcyAt IDk2MCBTUElzICsgDQoxMDI0IGVTUElzID0gMTk4NCBJUlFzIC0gd291bGQgdGFrZSBhcHByb3hp bWF0ZWx5IDEwIG1zLiBGcm9tIG15IA0KdW5kZXJzdGFuZGluZywgdGhpcyBpcyBub3QgY3JpdGlj YWwsIGVzcGVjaWFsbHkgY29uc2lkZXJpbmcgdGhhdCBuZWFybHkgDQoyMDAwIElSUXMgdHlwaWNh bGx5IHdpbGwgbm90IGJlIGFzc2lnbmVkIHRvIGEgc2luZ2xlIGRvbWFpbi4NCg0KPj4gK8KgwqDC oCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgc3RydWN0IHBlbmRpbmdfaXJxICpwID0gc3BpX3RvX3Bl bmRpbmcoZCwgRVNQSV9JRFgySU5USUQoaSkpOw0KPj4gKw0KPj4gK8KgwqDCoMKgwqDCoMKgIGlm ICggcC0+ZGVzYyApDQo+PiArwqDCoMKgwqDCoMKgwqAgew0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgwqAgcmV0ID0gcmVsZWFzZV9ndWVzdF9pcnEoZCwgcC0+aXJxKTsNCj4+ICvCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIGlmICggcmV0ICkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgZHByaW50ayhYRU5MT0dfR19XQVJOSU5HLCAiJXBkOiBGYWlsZWQgdG8gcmVsZWFzZSANCj4+ IHZpcnEgJXUgcmV0ID0gJWRcbiIsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBkLCBwLT5pcnEsIHJldCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgfQ0K Pj4gK8KgwqDCoCB9DQo+PiArI2VuZGlmDQo+PiArDQo+PiDCoMKgwqDCoMKgIGlmICggZC0+YXJj aC52Z2ljLmhhbmRsZXIgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGQtPmFyY2gudmdpYy5oYW5k bGVyLT5kb21haW5fZnJlZShkKTsNCj4+IMKgwqDCoMKgwqAgeGZyZWUoZC0+YXJjaC52Z2ljLnNo YXJlZF9pcnFzKTsNCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICvCoMKgwqAgeGZy ZWUoZC0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxcyk7DQo+PiArI2VuZGlmDQo+PiDCoMKgwqDC oMKgIHhmcmVlKGQtPmFyY2gudmdpYy5wZW5kaW5nX2lycXMpOw0KPj4gwqDCoMKgwqDCoCB4ZnJl ZShkLT5hcmNoLnZnaWMuYWxsb2NhdGVkX2lycXMpOw0KPj4gwqAgfQ0KPj4gQEAgLTMzMSw2ICs1 MTQsOCBAQCB2b2lkIGFyY2hfbW92ZV9pcnFzKHN0cnVjdCB2Y3B1ICp2KQ0KPj4gwqDCoMKgwqDC oMKgwqDCoMKgIGlmICggdl90YXJnZXQgPT0gdiAmJiAhdGVzdF9iaXQoR0lDX0lSUV9HVUVTVF9N SUdSQVRJTkcsICZwLSANCj4+ID5zdGF0dXMpICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGlycV9zZXRfYWZmaW5pdHkocC0+ZGVzYywgY3B1X21hc2spOw0KPj4gwqDCoMKgwqDCoCB9 DQo+PiArDQo+PiArwqDCoMKgIGFyY2hfbW92ZV9lc3Bpcyh2KTsNCj4+IMKgIH0NCj4+IMKgIHZv aWQgdmdpY19kaXNhYmxlX2lycXMoc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IHIsIHVuc2lnbmVk IGludCBuKQ0KPj4gQEAgLTUzOCw2ICs3MjMsOCBAQCBzdHJ1Y3QgcGVuZGluZ19pcnEgKmlycV90 b19wZW5kaW5nKHN0cnVjdCB2Y3B1ICp2LCANCj4+IHVuc2lnbmVkIGludCBpcnEpDQo+PiDCoMKg wqDCoMKgwqDCoMKgwqAgbiA9ICZ2LT5hcmNoLnZnaWMucGVuZGluZ19pcnFzW2lycV07DQo+PiDC oMKgwqDCoMKgIGVsc2UgaWYgKCBpc19scGkoaXJxKSApDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAg biA9IHYtPmRvbWFpbi0+YXJjaC52Z2ljLmhhbmRsZXItPmxwaV90b19wZW5kaW5nKHYtPmRvbWFp biwgDQo+PiBpcnEpOw0KPj4gK8KgwqDCoCBlbHNlIGlmICggaXNfZXNwaShpcnEpICkNCj4+ICvC oMKgwqDCoMKgwqDCoCBuID0gZXNwaV90b19wZW5kaW5nKHYtPmRvbWFpbiwgaXJxKTsNCj4+IMKg wqDCoMKgwqAgZWxzZQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIG4gPSAmdi0+ZG9tYWluLT5hcmNo LnZnaWMucGVuZGluZ19pcnFzW2lycSAtIDMyXTsNCj4+IMKgwqDCoMKgwqAgcmV0dXJuIG47DQo+ PiBAQCAtNTQ3LDYgKzczNCw5IEBAIHN0cnVjdCBwZW5kaW5nX2lycSAqc3BpX3RvX3BlbmRpbmco c3RydWN0IGRvbWFpbiANCj4+ICpkLCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4gwqAgew0KPj4gwqDC oMKgwqDCoCBBU1NFUlQoaXJxID49IE5SX0xPQ0FMX0lSUVMpOw0KPj4gK8KgwqDCoCBpZiAoIGlz X2VzcGkoaXJxKSApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIGVzcGlfdG9fcGVuZGluZyhk LCBpcnEpOw0KPj4gKw0KPj4gwqDCoMKgwqDCoCByZXR1cm4gJmQtPmFyY2gudmdpYy5wZW5kaW5n X2lycXNbaXJxIC0gMzJdOw0KPj4gwqAgfQ0KPj4gQEAgLTY2OCw2ICs4NTgsOSBAQCBib29sIHZn aWNfcmVzZXJ2ZV92aXJxKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIA0KPj4gaW50IHZpcnEp DQo+PiDCoMKgwqDCoMKgIGlmICggIXZnaWNfaXNfdmFsaWRfbGluZShkLCB2aXJxKSApDQo+PiDC oMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIGZhbHNlOw0KPj4gK8KgwqDCoCBpZiAoIGlzX2VzcGko dmlycSkgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiB2Z2ljX3Jlc2VydmVfZXNwaV92aXJx KGQsIHZpcnEpOw0KPj4gKw0KPj4gwqDCoMKgwqDCoCByZXR1cm4gIXRlc3RfYW5kX3NldF9iaXQo dmlycSwgZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzKTsNCj4+IMKgIH0NCj4+IEBAIC02ODUs NyArODc4LDcgQEAgaW50IHZnaWNfYWxsb2NhdGVfdmlycShzdHJ1Y3QgZG9tYWluICpkLCBib29s IHNwaSkNCj4+IMKgwqDCoMKgwqAgZWxzZQ0KPj4gwqDCoMKgwqDCoCB7DQo+PiDCoMKgwqDCoMKg wqDCoMKgwqAgZmlyc3QgPSAzMjsNCj4+IC3CoMKgwqDCoMKgwqDCoCBlbmQgPSB2Z2ljX251bV9p cnFzKGQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGVuZCA9IHZnaWNfbnVtX2FsbG9jX2lycXMoZCk7 DQo+PiDCoMKgwqDCoMKgIH0NCj4+IMKgwqDCoMKgwqAgLyoNCj4gDQo+IENoZWVycywNCj4gDQoN CkJlc3QgcmVnYXJkcywNCkxlb25pZA0K From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:25:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:25:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107422.1457857 (Exim 4.92) (envelope-from ) id 1utXYt-0004pZ-26; Tue, 02 Sep 2025 20:25:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107422.1457857; Tue, 02 Sep 2025 20:25: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 1utXYs-0004pS-Uw; Tue, 02 Sep 2025 20:25:02 +0000 Received: by outflank-mailman (input) for mailman id 1107422; Tue, 02 Sep 2025 20:25:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXYr-0004ol-J0 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:25:01 +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 e5bbe793-883a-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:24:59 +0200 (CEST) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by AM0PR03MB6308.eurprd03.prod.outlook.com (2603:10a6:20b:152::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Tue, 2 Sep 2025 20:24:56 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:24: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: e5bbe793-883a-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eYg20URorB5RWrCo5d1MCqPJwHGfDfzYm9DnUqjUc++QsLCmc512N8fqITCT5z8VOg+szVJilvo7S8eAWXlPCVVV7w+G9fqR5vIXh+mK3XbLyi07EYMYFN1WxJSo2qmU7aHQVhxp8+eLfAL0BRk3FG38XCM8LAwETky5JkK4C3oTVvTSLXq4lcDMhAIZs00GEMrtXCF3oPmey8PUmgck89GGOEzF4ylFdl2zZtpt23moav3xaL7SC8hrfs3th6L6Y6T3y29MSyyyMKMH+JXM+QgydPou1INiqfbXAXH94+hakFt9jHW9E/sj3bgJGFDSyx2mNU3BQJ5McsEdtLpEpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BiaST0ehVkbNnNRoWfpImv+RIARwbEGB6zRzp/50Fy8=; b=dEuKXk9XMM8SZ+gaxcSR8foENeZuHpd5LdR1MAavH2Rj7qGrqU763aUUXOcCsDIkfP17HqH1xk2B3dtJn/ltO5U34uiFLC5fL2K56IfC0qNgNEwINfzDVE3GTHSHqLVdG16eEc0esXuu11ftOsRbh2//mLroO0SwJCqOUgyUtgQo+kJEZ2KzfS9TfBm15E6tL78fQuaIQikjxulDTnpRe8G2yD0ZE+Lz/h9TFOYWUmRGLKtNAGmf2TdPFNx+1oxmHrxReRMnNzhKLUn9UIPiXUkR1hnkLp5fPLjPrqUMTkHAxjRjS6uYfjVFjfsakVIVF+hOd3j5NumSbYcJaAaNbA== 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=BiaST0ehVkbNnNRoWfpImv+RIARwbEGB6zRzp/50Fy8=; b=Rp8IQsVNOqQzAvUyPuVeglC++gQfxi8GABu/47ybjXBGm2DYYkUtsfnS08cFHH8bTZLaBVerbB4cmut9L250kx+rls9N2JNAFIziffx0I9XzSvYPmmhwyRecN7BYLqMNakGVxjVf60u1YkRoJDkMmiMYW3v7PiwPxsPRfMAPyAVuRBz7gSMU4mLGaI+B8QPa565Zh/O1/Ra1Uu/yJBgF0rMCeKtCU60ORblKf48N1+zUboC/jcZX7/kEq8HdXbwugv3x8qOfZs83eVHut704YIoAU8vJkTZYgYE1xJtXBBGzk0gLeKbHKC7dJ07UfdyatqcFzg74qwqO2iOIbnw6Zg== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach Subject: Re: [PATCH v6 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions Thread-Topic: [PATCH v6 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions Thread-Index: AQHcG4064D97SFCG3kWQLRIi5MFCzA== Date: Tue, 2 Sep 2025 20:24:55 +0000 Message-ID: <87bjnswqjs.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 2 Sep 2025 01:10:06 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AM0PR03MB6308:EE_ x-ms-office365-filtering-correlation-id: 84213983-04bf-4477-23f0-08ddea5ec801 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|42112799006|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?KO/vzXUEEcqhbNs14weiPoVJAGjL+2tbXEpA3og0vfrbt09oVgAbX1p44l?= =?iso-8859-1?Q?JtudJtqcRf24xBiFzWaPlXk+8AIlK6z08SQ7lfZvaRtMnj70jpqA33OvAo?= =?iso-8859-1?Q?vKyfv9Q4qzfU3yJmSjfP1Fodur/L86Gn2xNCXOmtCc/WYlY94cBu77pRwv?= =?iso-8859-1?Q?LGkpug0PzOkQXcaQAxUKHwaT7Ceo9Ye8l8ICUd6Kq9QbrXAU++V2j4B+HQ?= =?iso-8859-1?Q?/Dz6DjA2hEb3//jxEUaIPRCuUI77htJzIWwjEfc8+Sv3q+v7CS/Sd9qCyd?= =?iso-8859-1?Q?FX+Rr1QAv7yVrRXszm7sBJyTTHNWd/fJ8OXOb0v3oWwWhOd8jX3rfTbKpJ?= =?iso-8859-1?Q?QKy8zKQn3auxgMhQxgXAAHmc3ViHQeNwWD1PAImbiwZHybptj+ydogi8TO?= =?iso-8859-1?Q?8y9aiHdjTlRMabUOAo9hZuYUgt5mfzvjeW2kq9UkSEpKrESwwf9/iHEe7I?= =?iso-8859-1?Q?RJafPYtWoXYS1s89AV/qUUquy5MZtfMcTkCR7Kddh9u+OsxyIuMf4BhvfP?= =?iso-8859-1?Q?vji1kxFrxNoxWsyxC/xpWhiTfwS+RCXB9agRCRU0XOMd77pGIyUumVE2uC?= =?iso-8859-1?Q?y9eKszbNJAAjW8j6vUpS5j0OVXdkXiES2Vn+CMIMUW8qqg0dKdlg83Mmuw?= =?iso-8859-1?Q?IHHx4Spw6lBhpPfFFkTcxrP+hWYUoavLAmQ7c4ES83dWGYmGoeyva2iXyi?= =?iso-8859-1?Q?5QxE66JbY1NMcQ+CKnMO/SEFoh/nYwNrMitaobjFsS3yy4zaXQSivAq/1A?= =?iso-8859-1?Q?/jTTfczSQtra869eh8AzdIUSa3nOZKOe07Y9XyRraSPbGYTs/xlnLy65Jt?= =?iso-8859-1?Q?C0A8uAlFMHbNR6nRK+4ubuR/UQt4FMiT3WxR91BgBSiin1XERHdjO4ZvlU?= =?iso-8859-1?Q?krX7NzzBIYg0oqEa9MdH54mF3Zs/bxcqKKtOe15tDiiRPTRQIQRkkOeru3?= =?iso-8859-1?Q?uS5xse0Ju24r7n2augZPbfqiFggPkW5daYRSNwenyhttOucYq6dEXAwK+d?= =?iso-8859-1?Q?VVYa0rcQlpQiW8bYlmzeOCw6GpDeQrdOJ1yNfOSi8yQSzLpopJFVYafGUZ?= =?iso-8859-1?Q?C1kPvGkDJqHyr4b8aAjKa9OhCM9qkdNU+ZlilpUGquDPFs+c3hCbM90EM1?= =?iso-8859-1?Q?M4V1A8U5TqeoL5TF3Q3Frgo4B0Y5QSYsuJlEyuksqqj5G1ZrfWsXI2c4Cw?= =?iso-8859-1?Q?Aqic7th0kBaWPLeiObns73fEXFZOaxCBx+2Lo5HsuLYBENTsNOfev3etjR?= =?iso-8859-1?Q?FmPrZ+hUFeXM/KXjli0IquxXoB54ZZCUQn/mSYLdgbkShlC1eMYrn/zGfp?= =?iso-8859-1?Q?WNNJxMHgAwbjmb1JXdViMQwUaNa+I7rZ48XLlYmm2er93tOrDDSdTWgTvu?= =?iso-8859-1?Q?jgCH0LQcqqE6cCMyVBQL6pTQMOj1D2puef5loFp3+11lVXE0RdmCLbwg5s?= =?iso-8859-1?Q?AgMTGpR2YdSk7CICQUJVm+PPY0LSkTXYXSKKHxcS+9Z5r54tsPxPyM6RPx?= =?iso-8859-1?Q?fb6tA3k1jkq56gjICNQFJ5u4R9zfhxL1Fcoy1qjHclaw=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(42112799006)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?oSWU/7K+OriiLJYjtSmh3gEE5Bv/52finQ1Ckgx8mFfKHGRMpeqd85aeEX?= =?iso-8859-1?Q?ezykyJtwymT/RzRJPxh1TOmGKq7fXbAp5M949xsFJNeJSrfmuP/yk9zF6p?= =?iso-8859-1?Q?xOaX2Tfwz5587A2lhAH5JQ2enEGVc+v9SPxEjhW0Tei3QUz2ZZmYvPY0Rc?= =?iso-8859-1?Q?U2ZgV9T7nHuw4ULEpeGzUscn95ddBT2KjBHHZA1fXGIx7YP1fOpfvFzsal?= =?iso-8859-1?Q?PHTDv+kpNPIk/jFnFeJVUxZ7msGcYkyVUBfBwf7+vRuiM1kfKcFXL4uYKw?= =?iso-8859-1?Q?WhV1ICFdNBiIm35aSqyje6Tek1O7yr4k8VToVXx9IRFAXt3oi/838HMpgm?= =?iso-8859-1?Q?w2u6cjPcauvd4Yz5QdjTrVQy+5YjR14eTD1jAAGXaI0xeviEkvpZxYIloX?= =?iso-8859-1?Q?XlFiVEfPtWoaQBS3m1iIpsdt/LxWC/NPgEHnl8jU4X3SfWA3jxRCrYT8Ci?= =?iso-8859-1?Q?FAOKw/cqkHTg3IfAxZqjGbwieAHBxN4emfutt0QG1C+we7VcUtE0J5P9Cc?= =?iso-8859-1?Q?N7MutWPNsB+qyqueURgLYiZ1xT+Uocwq9sRymvFG6WmcGL+E5cEMsiQoKs?= =?iso-8859-1?Q?O28489zd4E03rJNQIjcVWo8SxmFExytEmPlWgh5Kr62+rm+naGAmtumAPr?= =?iso-8859-1?Q?dmplqZF7GPYAjJBPPTb7YykkoTYuQ9QTWtlQB+uaTs4ZDMrewMNhPJIc2F?= =?iso-8859-1?Q?DC+QyP/S91iYXKOGpxDHTjTCddNfg5l5QdOebSQjj1Jt6fA5JSaWgaZxu+?= =?iso-8859-1?Q?U9axtkIZLfrfaRJgBwJBobXm8mDvUJqrzT0SBNAidPqBGl1vqcn6EkGSBo?= =?iso-8859-1?Q?5ubqwldusw3U3KdYayBbMhlC12aFDqWKTxAADrImokmjCTZBLdc5DTruQJ?= =?iso-8859-1?Q?ilfBxjyWegltGbq8QOGW/eQvFBk32nFXEdIFcMC1rT5vROGDFT9uFMLOYB?= =?iso-8859-1?Q?Mak+fd5L7Q0XTlV1LLbT0cXGLKUvZNXmDmqhamFpkgo9Mx929HW/PGsi6B?= =?iso-8859-1?Q?cuc3+qT3uiXgRQj/ufnhbxhBMH0g7Zvw5rUeHAKVNS1z6EQWEKZmKQhwea?= =?iso-8859-1?Q?N+L1qdPG+ERJUM6vKIBBbpB+hjJdKNJDNw17vBxpmlXbBtCiBRKepAAMHr?= =?iso-8859-1?Q?uZ1A/rze69RY4mddYYGFImg3slRewXRkoBmyB5KWDkUH5ClgnyLdWHMO0V?= =?iso-8859-1?Q?D1aFozTRFFWvYbWs0C5WRT9squN528plDfH2Ikimk8iLZ3O8czaG3snUOC?= =?iso-8859-1?Q?t+MCYbN5Wf1jt1A4jpcyPtlEjfNql4xr4OpB4y6UDTveeuUyC90dI8bxAK?= =?iso-8859-1?Q?CuY3x7riNg8j4/zdNIbIP9EAppAqAZnfmv9ZKPxqDCQK3aTgmUOX4QSiGo?= =?iso-8859-1?Q?LPX9H2WLBmkLT14884qDVlaI4S8hh857cZn+yOxwsj2Tqvz9rQ9XMLLvIo?= =?iso-8859-1?Q?SU9yxBYvaKGLI0HjyRqMYPgCam9Xj2ikEauDjRiy79UQgE7OA79Wz/3n0D?= =?iso-8859-1?Q?kcRNdBwZpXaTHoQk3QK+Kyf9dFP6cd8d5DB56+zkvHrHgq14NjC/ASlYx3?= =?iso-8859-1?Q?GWGGFEG3lpXRPgZAM8a1kdDXeCNZaXzW1eagTmh/N7Z3BWMVo7rDexVPUI?= =?iso-8859-1?Q?rmciHX2D4uYY6Q2dnvtgJbkh6U7MXwz38VsMJe73AduFx4VJq678Ajww?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84213983-04bf-4477-23f0-08ddea5ec801 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:24:55.9512 (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: 0kGzLQNZVVJtUovtLsXGuSoUaz3IWJAUlc7YpHO6EG9S+rjiIFRci6+kljcBxSOspoIlA3p9qxr3ZTvgqmnXZxDPDuVqDsJwYOW//kRGSTw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB6308 Mykola Kvach writes: > 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. > > Signed-off-by: Mirela Simonovic > Signed-off-by: Saeed Nowshadi > Signed-off-by: Mykyta Poturai > Signed-off-by: Mykola Kvach Reviewed-by: Volodymyr Babchuk > --- > Changes in v6: > - drop extra func/line printing from dprintk > - drop checking context allocation from resume handler > - merge some loops where it is possible > > 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 | 143 +++++++++++++++++++++++++++++++++ > xen/arch/arm/gic.c | 29 +++++++ > xen/arch/arm/include/asm/gic.h | 12 +++ > 3 files changed, 184 insertions(+) > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c > index b23e72a3d0..6373599e69 100644 > --- a/xen/arch/arm/gic-v2.c > +++ b/xen/arch/arm/gic-v2.c > @@ -1098,6 +1098,140 @@ static int gicv2_iomem_deny_access(struct domain = *d) > return iomem_deny_access(d, mfn, mfn + nr); > } > =20 > +#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, "GICv2 suspend context not allocated!\n"= ); > + return -ENOMEM; > + } > + > + /* Save GICC configuration */ > + gicv2_context.gicc_ctlr =3D readl_gicc(GICC_CTLR); > + gicv2_context.gicc_pmr =3D readl_gicc(GICC_PMR); > + gicv2_context.gicc_bpr =3D readl_gicc(GICC_BPR); > + > + /* Save GICD configuration */ > + gicv2_context.gicd_ctlr =3D readl_gicd(GICD_CTLR); > + > + for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) > + { > + gicv2_context.gicd_isenabler[i] =3D readl_gicd(GICD_ISENABLER + = i * 4); > + gicv2_context.gicd_isactiver[i] =3D readl_gicd(GICD_ISACTIVER + = i * 4); > + } > + > + for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ ) > + { > + gicv2_context.gicd_ipriorityr[i] =3D readl_gicd(GICD_IPRIORITYR = + i * 4); > + gicv2_context.gicd_itargetsr[i] =3D readl_gicd(GICD_ITARGETSR + = i * 4); > + } > + > + for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ ) > + gicv2_context.gicd_icfgr[i] =3D readl_gicd(GICD_ICFGR + i * 4); > + > + return 0; > +} > + > +static void gicv2_resume(void) > +{ > + unsigned int i; > + > + gicv2_cpu_disable(); > + /* Disable distributor */ > + writel_gicd(0, GICD_CTLR); > + > + /* Restore GICD configuration */ > + for ( i =3D 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); > + > + writel_gicd(0xffffffff, GICD_ICACTIVER + i * 4); > + writel_gicd(gicv2_context.gicd_isactiver[i], GICD_ISACTIVER + i = * 4); > + } > + > + for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ ) > + { > + writel_gicd(gicv2_context.gicd_ipriorityr[i], GICD_IPRIORITYR + = i * 4); > + writel_gicd(gicv2_context.gicd_itargetsr[i], GICD_ITARGETSR + i = * 4); > + } > + > + for ( i =3D 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 =3D gicv2_info.nr_lines; > + > + gc->gicd_isenabler =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32)); > + if ( !gc->gicd_isenabler ) > + goto err_free; > + > + gc->gicd_isactiver =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32)); > + if ( !gc->gicd_isactiver ) > + goto err_free; > + > + gc->gicd_itargetsr =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4)); > + if ( !gc->gicd_itargetsr ) > + goto err_free; > + > + gc->gicd_ipriorityr =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4)); > + if ( !gc->gicd_ipriorityr ) > + goto err_free; > + > + gc->gicd_icfgr =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 16)); > + if ( !gc->gicd_icfgr ) > + goto err_free; > + > + return; > + > + err_free: > + printk(XENLOG_ERR "Failed to allocate memory for GICv2 suspend conte= xt\n"); > + > + 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 +1436,11 @@ static int __init gicv2_init(void) > =20 > spin_unlock(&gicv2.lock); > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + /* Allocate memory to be used for saving GIC context during the susp= end */ > + gicv2_alloc_context(&gicv2_context); > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > return 0; > } > =20 > @@ -1345,6 +1484,10 @@ static const struct gic_hw_operations gicv2_ops = =3D { > .map_hwdom_extra_mappings =3D gicv2_map_hwdom_extra_mappings, > .iomem_deny_access =3D gicv2_iomem_deny_access, > .do_LPI =3D gicv2_do_LPI, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend =3D gicv2_suspend, > + .resume =3D gicv2_resume, > +#endif /* CONFIG_SYSTEM_SUSPEND */ > }; > =20 > /* 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); > } > =20 > +#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_s= uspend > + * 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/gi= c.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); > =20 > +#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 */ > }; > =20 > extern const struct gic_hw_operations *gic_hw_ops; --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:32:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:32:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107447.1457867 (Exim 4.92) (envelope-from ) id 1utXfh-0006tu-Nt; Tue, 02 Sep 2025 20:32:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107447.1457867; Tue, 02 Sep 2025 20:32:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXfh-0006tn-LF; Tue, 02 Sep 2025 20:32:05 +0000 Received: by outflank-mailman (input) for mailman id 1107447; Tue, 02 Sep 2025 20:32: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 1utXff-0006th-UZ for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:32:04 +0000 Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c202::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e14c969d-883b-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:32:01 +0200 (CEST) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by GV1PR03MB10208.eurprd03.prod.outlook.com (2603:10a6:150:16e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 20:31:57 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:31: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: e14c969d-883b-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t8hGgysEbR8wGy1Go2WJoRI01GgHkF4rt3wgAh32tS1ebNUc8OjUDuarzPkJ34NePyWA2HmUFIaKktBC0Y/xT+/VI+ADvN6xiV7n8tAKZyr15BIXC83aprDWw/+dT7CqhOL4rGPYrGAnsx9xd9vKhjiqgWZkrghFkPPSTO8JJEs42sNDiim5mZajk3NnKQzRqwvKKQSw1n1/aExsL2q/IoDYe+GajLGs01WDFIhdvDbbL0DFB+Vzr0AY/IfMYDLYLymasNTcIU2s5OIMYyhjQnBBVSc/FGAWHYz/K+ce4JR6idL+Ee5IsS7ohId9tLKFBtPe6b/+FRdZQH/WNDJqYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=obyXw49Y6GCbPfYlK437SY6qiLtFejO9rSyOMNUoTVA=; b=XZilVSJ+3aVbNv7EMBl6T4a40GAIYScvD+DZGpx8TaR1bEy4iR6a7siIBwxFSy55zyuGFdCYP3WXZdrEi+/MwufRqkNQyRQqSk8iXb10DBkuoYS4y8EJ2yLfhcGwS56bPjol4JOcem1licyG3ysY6VEFj11UBYHk+NU2JhL9lLF/5CHNARJaf19p9cgQG0zvcimxhy1bGbkGfRlWyCOPRFsk40EKpUBleGYn8mhhI9s0AQsLDyg24hOYraEG+Wy+rPYIO0Sn5FvlWQ45S1XxBmglHZY1P5XBfmG6han8yEI6r6eoRgJ+mn+d2jadv0q31bem4sIqcdjc1v3Dj5TFAA== 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=obyXw49Y6GCbPfYlK437SY6qiLtFejO9rSyOMNUoTVA=; b=LYMNCKQtmU/eCn8kTyoTZNCl/fB8hgG/uIvaZHer/+ZsMRIx62ZD9H3J0bls+C+X7rpybCj9AV2NquvIUOn7DHtUW3+YMcthypCg3T9/LQGhSDWhzWFo7u3lpVjp4544T6D+dMSMlf2USKfSmiUNqM2TPz8Uje66eCcvGCz2BZQpBXu0e3M907ZOJFdMvUKVfL1fVzbfeMMjbQ9TeTsD9zxoCOFZFYcnLKCescQ4Uke94vN04r3gmYZ0+W0NfQ9GWsYFXpMl24xd/pa3rDxLmUR883OXfSrdTdhOq2HdfNok3XtaYUBrX9NMV4ZHnLUY54Zeekk4A2hkCjL18l+57g== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v6 04/13] xen/arm: Don't release IRQs on suspend Thread-Topic: [PATCH v6 04/13] xen/arm: Don't release IRQs on suspend Thread-Index: AQHcG4070V6Pun9gkU+MtbSzx0yRtQ== Date: Tue, 2 Sep 2025 20:31:57 +0000 Message-ID: <875xe0wq83.fsf@epam.com> References: <293acbb653b5f4d5bf71dc459f9de3e729bff3e1.1756763487.git.mykola_kvach@epam.com> In-Reply-To: <293acbb653b5f4d5bf71dc459f9de3e729bff3e1.1756763487.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 2 Sep 2025 01:10:08 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|GV1PR03MB10208:EE_ x-ms-office365-filtering-correlation-id: 24a7b23c-1001-4709-3702-08ddea5fc309 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|42112799006|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?Ix57hZpw2SnZ0EywFxXqR7x1zSUZNiEhzM7iCEVdn3zUBoVpmCuGbCc62K?= =?iso-8859-1?Q?c7eAZbDvBcK7EkjLPPhbmev2e41h5mQ+WnjZcudH5fgEWO1brP8frGuOeX?= =?iso-8859-1?Q?v7CWIX3J5blvKnQbHMZ9NgWcWTTcsKc5hxCLC5yAyS7qCXwMbcM6yDGXFx?= =?iso-8859-1?Q?eEeT7aioilvgAkEqb/Ai9qc+fOKpuSjxp3R/DySxLr4dqQvvd/YXf+oAdt?= =?iso-8859-1?Q?r/Fqz/OO+q/f02jpFHdFDQaLb2nRTt6tY5gWAGGW4ib5NRIj19Y83bwYW0?= =?iso-8859-1?Q?ajoQRPiljkTbNH/Q6RXJG+xTHN6o0+BHYBe3qHR5JPU3K6WkmYTpVUq7Q8?= =?iso-8859-1?Q?F5J3Pau/sfQwVXImqjGXui7ugWH9IWd/qULh3kXWv2slx6hwRCjLwtQO6i?= =?iso-8859-1?Q?Gpc+peIOrXN6rHt+Q4DhQg4muq4+hIdRzyEkXUFzwr20rm3nksTEhcwjIr?= =?iso-8859-1?Q?WMYOvNMuj3jwFwXpP/zyYKeExOiX/JvkQR/PPy6WqYy7Ndpt3afM4U3X2+?= =?iso-8859-1?Q?GDnRzHOICIL0v8qipyj1EeW84+undw1E5d0LqXFd3m6XfCQ3QMKohP9QwJ?= =?iso-8859-1?Q?H5de0+S6+bhGLtCY3yvVBiAk2XODDGIhyqBAUECbrkw0B0dlyLqx+v0qKf?= =?iso-8859-1?Q?sZxQD6CgTJ1ZQqgPVP6LJDqJzka17+Vg09ghP4lMFTLYKVBPukNOKNITpt?= =?iso-8859-1?Q?P80e9I+jTQuMZguGrVQja1CLthc7NRC1tm5U8vPglJE7oMzDKNN/MQZi3C?= =?iso-8859-1?Q?L5KIbWrzuDzamdjUnoaPwbqkZiltN3IkpQwHmEnEwq+/7jGcz+Xc/PxJsx?= =?iso-8859-1?Q?H18FCqY3f1LNd3yjhtZCcDW1MyyEg+piII41qnxSU2dJuReJfpEF/+J0f+?= =?iso-8859-1?Q?NQgWRmTJebFAERc7pipNIq3lSnD5d3P95vGP2dLxXjE9E4jCe71RF+ijCt?= =?iso-8859-1?Q?qOyy4Uzcbs5UwO8NdgxVPgVeFyBFEPbF6dUGd/29JD6D6HAz9f+iuukCL5?= =?iso-8859-1?Q?DRkEvdJwqhfgMTgJf+MbLr5Ie0llCnWc7NvIJwtTng45xcCD5nyzmMzyA3?= =?iso-8859-1?Q?WLZ5y6swnDsStoy98N7dx8vAM1Zs9+cbPaGHBbQ5RxuF6LzRrtqyNEYl5M?= =?iso-8859-1?Q?ay7sdro4tfOANzw6O6TkF+DfIl65mcA0fQXZ7NdOFJf3OAnZZEtektoQ/J?= =?iso-8859-1?Q?akw7iEL6kBGbmompg7/7oLbNkskeXdpgwYwyVaqKb2GhPy0qt23MfXpxY7?= =?iso-8859-1?Q?edg3rKKVS2wlee54pARPai1aCrmA8NcWOZwRFqb/8hDVdWTNNTXrwv8yOR?= =?iso-8859-1?Q?xpTqWgeMPMPW5QSKOA9yZ+f+pgDH0kzya1NWCTC29UmWXjkkuO0syUuW8k?= =?iso-8859-1?Q?ab21sW1611O0daPw5+uuubk2EqJ1IclMK7EDB+Nwocxd+KfOCorrKy0+Pb?= =?iso-8859-1?Q?EAShQC0IKM9CqHkh3j9lUj9aluoro+u1dZXrl/G55jKVcLr2WwnUkXPuwi?= =?iso-8859-1?Q?0YulerfjGVXi6KgEdAiQQrTFte8lormVhE/OljyzWmSA=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(42112799006)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?l8tYZjZKdBmlKBRX6gEd2aHWUL3cKKReWhdZlq02SRMyu73MsERe7sKa+A?= =?iso-8859-1?Q?5NcSXEnz453ZmUnXxO13FVLTdUBcXf9avsm8SSUkzCPFkgsi0sZIJ2GfEX?= =?iso-8859-1?Q?f03WAyPQT9Lqa7GDxxyhNahfrqATLd7tSDh2EkLZnEgMeXoqBIEV6pqUUz?= =?iso-8859-1?Q?uq+8Sa6exipMn9u0JyASTSewq3GZagO372r8TyvJsKmKNaX6BjBMjoYC3Q?= =?iso-8859-1?Q?txQENefd03V8ab6yotsWwEAjIQRnRsQrMfCTqSgZKrA+MgR8vSR8aOWrcl?= =?iso-8859-1?Q?MaPHtcyD+3wCgR+OIpsMy7VExezYpUH/sbCyGYgJI1W5uJZH5buECOVo/e?= =?iso-8859-1?Q?s6T+IXFU4T8RvSlnANcg8HyEsK8Ky5w8Tqyjbv6F4Zq5Z2KHydVj8GHF0M?= =?iso-8859-1?Q?BVVk/p87eZ2MGYtNSf81Gyw96M0oFoUyXsFhem8VD6+NRTL43GpHmBL1C/?= =?iso-8859-1?Q?2TDbsvIub/GswFjFOgM+kjvIFACTq7il091/otMgQ02gJGJg9mLx9EMaq8?= =?iso-8859-1?Q?v1XKtMsbCzpCuBh5/Xu7YiyVNmwnm6DTstClHmFl9p0C7hR30KUMohhxHw?= =?iso-8859-1?Q?QjJ5TLg8oWS0GqJ4dVLvjyHMwrwU+XfhJmm+MoNB4n6wrgaXhDXIES1/rA?= =?iso-8859-1?Q?Am8Gth5tB+6Sq5t5SIpDvsombPitTdSplSHbpJk2uBziAsUJA0qw3QIl9j?= =?iso-8859-1?Q?btwjQR+eZNki7cayE1C6fJKKFNhXHOD933CKn/KokDOy+s+Ge92/tLxCDK?= =?iso-8859-1?Q?kLCXbWlikLaDyR94rV44+DIpzGo4wP1pRSXSqM+Atg9yxYSpHA/7EEfE0n?= =?iso-8859-1?Q?JNSEV6rQ9FtDyeCH1I6R6oZ+MZxBKJWnBOvXV8uGyYH/Rez+oe/JPB8hM/?= =?iso-8859-1?Q?2/wtxuvrmixI/O0yA0cCPupwF1MCdPzBpUcpQHW65mof4VdsNqhqYqyUmO?= =?iso-8859-1?Q?Gptsv82n+K/jQn3jC9Zg40Lyu66QTDFB7mKVr/EcU7ZfNhljx5oqSZg8gA?= =?iso-8859-1?Q?zldXBJxaDk+f9vD0TXcO6LwLDfF0ZoRIaSRdjVa+rMIzRdMKmHNjpL0yjg?= =?iso-8859-1?Q?qUvVamb/SsqmsVl2lcIRWBYcB6N//OLihQj1h+Uqxl2Im3E6oe+k1kRb7J?= =?iso-8859-1?Q?efb0NyRJ8gsBVxl3RXv0pQm3M0RtIo6TwsJGC0IYt6TMG2h75yWa+5hIsy?= =?iso-8859-1?Q?kwsf+P7klYahjUkhM4kAoKxMHdymWt4UxaIcqA0IE1J5GKH44ZM0zhBxPB?= =?iso-8859-1?Q?D8YJXFd3EOnEGaIkFdJlqNwWwFqCrWR2c+cRD1i+oT4+VkH9G7eo9PKJ5X?= =?iso-8859-1?Q?pHzmudiLRUvJrxBC3kw04XX74BbaIm8Rk/vh7S/wNEqLg2h/viHfEbWnD+?= =?iso-8859-1?Q?xbUi9yp383490Ll00dJ+IQMp1IWSMY5fJyu65j4VftAppLsl9ed0GTZJx+?= =?iso-8859-1?Q?kkLU2hzhLHi0gGNl4LTn3DIOMhJwT3XGbNlaH18mICJ2e9ZSg3OZBaoB5a?= =?iso-8859-1?Q?aSA6SldNKjsYm9xfPo5H9UNXV+TMg6CaDF5UfYqtoFAv9CdN/9i+uHR+Ob?= =?iso-8859-1?Q?kaEik3cChDDP95mrq10gSALsTXKVvsMlLuqiJylYYbKQtvtQb5ALxcsfsu?= =?iso-8859-1?Q?E+Aj9mXBvVXZtIdCWbIbbOv+1/MkILnKnioxqWrK0lRykbgDP0YHDtnQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24a7b23c-1001-4709-3702-08ddea5fc309 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:31:57.0815 (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: ETpEsE0ffbHZkvCi41wjvfOu6x7P2LPiqOOjjUd4ifhoUkMALVvptzz9CwhdsCgtV0dJ6euOIzQ39XBP69FY9cRRz87JQy/1iqzLGCY/Zag= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10208 Hi Mykola, Mykola Kvach writes: > 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() || n= um_online_cpus() <=3D 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+0x4= 4/0x60 > (XEN) [ 26.003150] [<00000a000021d678>] notifier_call_chain+0x7c/0xa= 0 > (XEN) [ 26.009717] [<00000a00002018e0>] cpu.c#cpu_notifier_call_chai= n+0x24/0x48 > (XEN) [ 26.017148] [<00000a000020192c>] cpu.c#_take_cpu_down+0x28/0x= 34 > (XEN) [ 26.023801] [<00000a0000201944>] cpu.c#take_cpu_down+0xc/0x18 > (XEN) [ 26.030281] [<00000a0000225c5c>] stop_machine.c#stopmachine_a= ction+0xbc/0xe4 > (XEN) [ 26.038057] [<00000a00002264bc>] tasklet.c#do_tasklet_work+0x= b8/0x100 > (XEN) [ 26.045229] [<00000a00002268a4>] do_tasklet+0x68/0xb0 > (XEN) [ 26.051018] [<00000a000026e120>] domain.c#idle_loop+0x7c/0x19= 4 > (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_r= un > 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 Reviewed-by: Volodymyr Babchuk > --- > Changes in V6: > - skipping of IRQ release during system suspend is now handled > inside release_irq(). > 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 | 3 +++ > xen/arch/arm/irq.c | 3 +++ > xen/arch/arm/tee/ffa_notif.c | 2 +- > xen/arch/arm/time.c | 11 +++++++---- > 4 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index a018bd7715..c64481faa7 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -388,6 +388,9 @@ void gic_dump_info(struct vcpu *v) > =20 > void init_maintenance_interrupt(void) > { > + if ( system_state =3D=3D SYS_STATE_resume ) > + return; > + > request_irq(gic_hw_ops->info->maintenance_irq, 0, maintenance_interr= upt, > "irq-maintenance", NULL); > } > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 02ca82c089..361496a6d0 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -300,6 +300,9 @@ void release_irq(unsigned int irq, const void *dev_id= ) > unsigned long flags; > struct irqaction *action, **action_ptr; > =20 > + if ( system_state =3D=3D SYS_STATE_suspend ) > + return; > + > desc =3D irq_to_desc(irq); > =20 > spin_lock_irqsave(&desc->lock,flags); > diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c > index 86bef6b3b2..4835e25619 100644 > --- a/xen/arch/arm/tee/ffa_notif.c > +++ b/xen/arch/arm/tee/ffa_notif.c > @@ -363,7 +363,7 @@ void ffa_notif_init_interrupt(void) > { > int ret; > =20 > - if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI ) > + if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI && system_state = !=3D 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..8267fa5191 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(); > =20 > - 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 !=3D 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); > + } > =20 > check_timer_irq_cfg(timer_irq[TIMER_HYP_PPI], "hypervisor"); > check_timer_irq_cfg(timer_irq[TIMER_VIRT_PPI], "virtual"); --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:39:52 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:39:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107465.1457876 (Exim 4.92) (envelope-from ) id 1utXnA-0007Ze-KF; Tue, 02 Sep 2025 20:39:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107465.1457876; Tue, 02 Sep 2025 20: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 1utXnA-0007ZX-Hc; Tue, 02 Sep 2025 20:39:48 +0000 Received: by outflank-mailman (input) for mailman id 1107465; Tue, 02 Sep 2025 20:39: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 1utXn9-0007ZR-S7 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:39:47 +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 f5bcc792-883c-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:39:45 +0200 (CEST) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by AM9PR03MB7137.eurprd03.prod.outlook.com (2603:10a6:20b:2d9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 20:39:41 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:39: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: f5bcc792-883c-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fdICQakDqve6QitTFcjMT3eakef8Z+YurmWm12C/cbzjKSWFhE+K9HgUpiGG3ZltBjWnSrnrY7V+T/uS+iVLyF3tYAA6nIuJw/b84Lkl7UhluhNa1mNUbdLV2MwrJ20S9fKTfgI6WnVVT0ttx0af7TNoORnCyaHGNrfI9yFMEQNRrcxJtBPNjhotsTEhAtdRIGBwmNvads2LBNZwmsci+o2LVdi3OsvXefiQw/GeQC+bDNtaYFU6liY7SS9W0R+v16hrMTjvfNe4RB82Zcrt6or0wi/p8eXvlPw4xmUKGT5jgmtAseuIHqN3pMI+fqJWZUOPYFTdu9xmoee+LFVTsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Cxd15S9cG9TO0HjzQAmllabL/ai5xUhN3K3bgIQ6jsU=; b=kSJRj2wJdkRl2vLnAnigXuLIJQKPkCjuaPpJg/GmqNfy2bK8C4bjg9h8IfYz/Kcou0wJNi8oQWQTL9br+qIDI+nbxx5XB2B+O4ES1R/vt71CCF5CVQxNNroOJJ5iwut1Z90Gtl+b+hLgTFfiEOfTmzlJRx2rckKEFXRaUnPuNhVpSVmC/YOR+SgQjQOSS8bFmQEhM+jp0gdX8qXSL/jaR+eUQPu5L1wGPzjXmuAGz918VNkkhjUsANCIkGPABixIfM5uMBt+ZKuvVRjUFh8I3/rxAwSQ3DbNi8L3vEZCvswLuE8Qsg5OwdZoLYcFTiMRY4+BLcztamaH0u4SlLW5lg== 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=Cxd15S9cG9TO0HjzQAmllabL/ai5xUhN3K3bgIQ6jsU=; b=gUbo2zWCLLbRdoYwEtsX8QeGhdG7IcIpouxY6X6G/hi0ab+tuOrILVSQ+iySEHVkhnM/n7XXspyePCvZeEL2FxSqFRcWLncoD53askBr3a3JAZA0gBT0ReCYsVlgIgzcvq8D6kSoWlRqSXhEhVKleDXilLITfemNXFDLtqqHrK/9DqN1eMCh+YIj2dntlEMLioxkdR6rXjFObiEm1NSVJLWx1wKjMq0jg9TZB4tF2ub6rB1cxROBz15ZAovW3XODOj7AXkROB+hNUwyzecNzpPhGy4WCvy2dciKs7lQuqUc+6f0nxTZQDcoQJ8g7FKCDSRbOK9BNezk7YYtl97Hdvw== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Mykola Kvach Subject: Re: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Thread-Topic: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Thread-Index: AQHcG40/dU6/M1xyc0yVxU6cfQnuGg== Date: Tue, 2 Sep 2025 20:39:41 +0000 Message-ID: <87zfbcvbar.fsf@epam.com> References: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com> In-Reply-To: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 2 Sep 2025 01:10:11 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AM9PR03MB7137:EE_ x-ms-office365-filtering-correlation-id: 391ebabf-dea2-43e7-c93d-08ddea60d7b5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|42112799006|366016|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?/RDsUP23TsNYi3RRVT3VKmyq7Stca381mVUzzKAKIyn128roL8390TIhm3?= =?iso-8859-1?Q?rHw6rjIH9hM7Fw72SxtBAoshuaIGwqVrW2sg3Cv3HXmgDJ69oh69709TOT?= =?iso-8859-1?Q?mwHXAy11DFlPAjkZlOPunB7zre5s3X41hOtSb7qZNv1CbNxadmQi1HaOtz?= =?iso-8859-1?Q?PXzQaedClBfQ0Mxr0SFhEDWCrrrx5BjqrGmq3MZ73JALLjZnKRRxCxQoUh?= =?iso-8859-1?Q?5pkZBfmn+OENfkNGxHNHg2P+6diQG6a4kTA1xuOJR3UAJZG5e1R+tRa0JQ?= =?iso-8859-1?Q?vIAA9kMqI7+x3CIZ2Mr/7sWD6jc2nX3MqeSBdR9mN+VvGAbmSKVEcQB7jn?= =?iso-8859-1?Q?6UJHuLL1mJf6Nq0irLHe+8StbQ50LEZMuA3BYBx9SC9mAOodvd9NQa+3jr?= =?iso-8859-1?Q?l3UQNrhXiHRcCJyY/3OHzN6U9xeuQvINgr8lfmj5AfSF6O9Ws/HGoC584w?= =?iso-8859-1?Q?xsvlEEevxY6wCb+/Iv1FRSyw1BDp3z+nGTi9tGVNzP+Nmrb3qfOtlmNerH?= =?iso-8859-1?Q?iN7Yga1lsNUydlZCfFG8GJV/YLx9E1F1outIDZCiA8RlEm2g/05UTqRZyM?= =?iso-8859-1?Q?jh5PmXBOvrayNQWvvUl36WmCmXBBsYZW6+SiBnLIGkKltrq7YroI+3f8+9?= =?iso-8859-1?Q?ajFkRKs6ACyT9KHpfqsgQeqIIDrSAtzB5eZxHUlmENnubtvdO36OYy5BIr?= =?iso-8859-1?Q?vty/Z0iDuLQu2sRJbrlxkpBo15K/LiBS3ej4k2R0V5EhTtAo3C4J9Pw6mn?= =?iso-8859-1?Q?ZCfrOugW360ZmRPvgCROkmJAvVZNvPTXuRr2CWxVEJY83ECNnTH4laZmUE?= =?iso-8859-1?Q?hAMmLG37rlYec4cffjWOcQG/iVAN73f0G0GisOdHbCdWswCDKV/9GNMFtV?= =?iso-8859-1?Q?sEQLStmYDvu8X7uDDlF2JS4QBjTLzOHtfVs+6a+c/5RmKhu8U3jxM5Alhb?= =?iso-8859-1?Q?ZaXlcCzhF2Yf8sU+lHw1WCWdWB+2+Rp+T0xvMKTvIqTOHSkHpXFgyMzrHE?= =?iso-8859-1?Q?xCMr6MPMl/mUNsUqZ/7AK/PDC6UOq65DMLpCX2Bw2ZQHJV47DdCnMshCh1?= =?iso-8859-1?Q?UGVugmxMms1DZix6wv7+cULcDu3CJfc8b3w4PuvluS/KQQ8rvurghYODKH?= =?iso-8859-1?Q?h7Vo9HIbPu5+znD++/VjVd0aUa5xUnRa/dN8LhROlCturU155jc8HveHN4?= =?iso-8859-1?Q?N1flEPBppr46qdJFOBB0RjwYzGrtY/KfN2Rl/7PyjpHvMym39Dg01f5By8?= =?iso-8859-1?Q?4JuXVNPy6WbgTVKQ0XNFOvGXpgwzmacXEaHQ722rmDW9S8Thuz/UKay+tJ?= =?iso-8859-1?Q?HRFuwkigvg0Yz/3MHVqYgmJo9U5HtqEfJUaJo8PwV2OmgbfqAbDiOeNILv?= =?iso-8859-1?Q?lx4yTL9SAAraJ0lJVXQ+oMyReIWQVnXwD3U9m2Hn2YroMQIt6z+Q8RLydB?= =?iso-8859-1?Q?db/hh7hdGJ0E/4aE2DwvQRJT/nltqWV2edCJbPuwoBC5F1egvS8OdSGHDt?= =?iso-8859-1?Q?TRodX3r+yrrgcuidcMXEMJrtoi7gAxUvQZJzDwLWgEmA=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(42112799006)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?c5hR8pIWFEvM66i0V8n9pLE9LIIzHOsSkkQvEhOmPRS8469zFvo8/a6Kd2?= =?iso-8859-1?Q?G8g34G1q1SkEbeYRoiDd4Cg0JMptpnrv6KxFgtO+UIxZmusSInzfvK84gL?= =?iso-8859-1?Q?7ZUY/Z81K2rpjsBl5WrqWqXw2g9cJpVcyOFDd3+NLJEFO4kIwBA3ZCJ/GL?= =?iso-8859-1?Q?3x11rp8YQEEvApFLHWxOdexfRpdnpnXMwX26TgOEFEA5ocCAgQlfa7//Je?= =?iso-8859-1?Q?2ZRVNApT7Pb0pwkK06yHqHcmfbh1C6QivB98cJzkqZV0BzVyWLiPV6x3bg?= =?iso-8859-1?Q?9t6fhqP18iKJokHU0EB9yIYyDyW3xakesrLB6xgniatOkzgQYqliw9F/6n?= =?iso-8859-1?Q?Bs8h0HM4oNI70jh7+WxNDjrunRS4v8SGMbH7C8IgNiHOjh3ldzoIghveFL?= =?iso-8859-1?Q?ruT8NMdz32GFyhoT8OmIVfhJsso087FdRJ2kFSfZZsbpNsCqLbHE0w4p/x?= =?iso-8859-1?Q?kSOa/hu8XRO4wfTjNR2beDacEbSPsXLj2+u22vrP6I/fTGDZaznDqm+e3k?= =?iso-8859-1?Q?U23JQcVHXWZgfgI8YJKfeKv2tWK17LWpLGCL7p5uwGOLow0zMEr/kjulHc?= =?iso-8859-1?Q?oTgCu/5M4KlTc7TZ4oVh8wt7QgLabiE3J+ZLpLNFK4sCGu+75F3z/02oir?= =?iso-8859-1?Q?gowlv/6yao+VCiZxsGVqaeHdKdHKSaxC2vx2ttiTKwLlcLhqbGsSPU7lwa?= =?iso-8859-1?Q?o3/clqG6JDceQkO0MjJ+ATI81DJUB3gy6i2XiMMqIcwjCcOM2u9dLzU8Bm?= =?iso-8859-1?Q?4mi7lo8ahG7KEU02U1z9vF8bVHsPIIjDX3WT2ji2ZryzfFk0iKafjZHeLW?= =?iso-8859-1?Q?itIYGyhbHl0xL56If02KoC6EaD8Gamiry+3QCJnR5Fcz/hl0jLAti1YZyM?= =?iso-8859-1?Q?mEhVsMgNOblKxBWas+4EiPfar/fNJK69gyDNQEVHzxOW+uK8WzWXT7IJ5V?= =?iso-8859-1?Q?elQLco2SbtncysNdwzKvx6mTMyo7XGg3L9sSMDXSxXkFOjHYzGRibsx2X8?= =?iso-8859-1?Q?bEzrSf5qPJdYtNn0FkjHqPq8/13ealT7+DDwkFLmkarE06/QGsOBZz5lZy?= =?iso-8859-1?Q?lDnmtOAcZb5HNBkUc+Dw/ZTKUOeGTfw23sNAlyGPqy9PqJ3a0IkvOHwuPj?= =?iso-8859-1?Q?YJL3bUyQQNZI31g+A7gD9gYG360ctkAdjP/Apqzf1Ovji49hAzH/bXqoS0?= =?iso-8859-1?Q?3BLB8nJ7TgrMc0fez/fA0Eat6rzFsVt7SGbmvpmoVCINdBU4mtUXpr9V1v?= =?iso-8859-1?Q?rHpeBHymx0eX/6Pih43nyl6o+PmG2XNIqxpH3cupS38czEF+VZkQPyy0Xc?= =?iso-8859-1?Q?J2D6sdayL/G90eTv8lLrSXhH5meHScCSTn74nHKtREHHqDRSGD+QiXXofq?= =?iso-8859-1?Q?5iAfJbGlEMQkfFVWjxysrkaA/yHNujwhsnJrGGdtzmzF/uwOfbxHyR4ihV?= =?iso-8859-1?Q?PRr8HRNgFLk91QoQBzLeul628DlZOrgh4TND1s30ORgQB87MEfE0LhHGLN?= =?iso-8859-1?Q?8iPRjB9v/3jR1wQeGn1hFINy/H509revNrb9yJNYtf5vMzT9aHcgqp7RBK?= =?iso-8859-1?Q?qBIwSDwEMzq5ZznYjrIcYp5QaEhGoFH9WnP4MDBZnsTAg5cONri1fHDmeL?= =?iso-8859-1?Q?wUWghT7fKgESZilU0QzcmrYngmSZLqrzMkIx48UweXy2S3ZNgi+aK7kw?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 391ebabf-dea2-43e7-c93d-08ddea60d7b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:39:41.2969 (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: PP3qQtK6sJKxiG3NyqTTmRb2DFD8p0WRCWQbofY1XvSz8REDlVCSUv22EgJhX2a7hGVCs3T3QClOEOOKIfkDX8HS77C9nifVhWnaSceQFhM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7137 Hi, Mykola Kvach writes: > From: Oleksandr Tyshchenko > > Store and restore active context and micro-TLB registers. > > Tested on R-Car H3 Starter Kit. > > Signed-off-by: Oleksandr Tyshchenko > Signed-off-by: Mykola Kvach Reviewed-by: Volodymyr Babchuk > --- > Changes in V6: > - refactor code related to hw_register struct, from now it's called > ipmmu_reg_ctx > --- > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 +++++++++++++++++++++++ > 1 file changed, 257 insertions(+) > > diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passt= hrough/arm/ipmmu-vmsa.c > index ea9fa9ddf3..0973559861 100644 > --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c > +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > @@ -71,6 +71,8 @@ > }) > #endif > =20 > +#define dev_dbg(dev, fmt, ...) \ > + dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__) > #define dev_info(dev, fmt, ...) \ > dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__) > #define dev_warn(dev, fmt, ...) \ > @@ -130,6 +132,24 @@ struct ipmmu_features { > unsigned int imuctr_ttsel_mask; > }; > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +struct ipmmu_reg_ctx { > + unsigned int imttlbr0; > + unsigned int imttubr0; > + unsigned int imttbcr; > + unsigned int imctr; > +}; > + > +struct ipmmu_vmsa_backup { > + struct device *dev; > + unsigned int *utlbs_val; > + unsigned int *asids_val; > + struct list_head list; > +}; > + > +#endif > + > /* Root/Cache IPMMU device's information */ > struct ipmmu_vmsa_device { > struct device *dev; > @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device { > struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX]; > unsigned int utlb_refcount[IPMMU_UTLB_MAX]; > const struct ipmmu_features *features; > +#ifdef CONFIG_SYSTEM_SUSPEND > + struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX]; > +#endif > }; > =20 > /* > @@ -547,6 +570,222 @@ static void ipmmu_domain_free_context(struct ipmmu_= vmsa_device *mmu, > spin_unlock_irqrestore(&mmu->lock, flags); > } > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock); > +static LIST_HEAD(ipmmu_devices_backup); > + > +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX]; > + > +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu, > + unsigned int utlb) > +{ > + return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb))); > +} > + > +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu) > +{ > + struct ipmmu_vmsa_backup *backup_data; > + > + dev_dbg(mmu->dev, "Handle micro-TLBs backup\n"); > + > + spin_lock(&ipmmu_devices_backup_lock); > + > + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) > + { > + struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(backup_data= ->dev); > + unsigned int i; > + > + if ( to_ipmmu(backup_data->dev) !=3D mmu ) > + continue; > + > + for ( i =3D 0; i < fwspec->num_ids; i++ ) > + { > + unsigned int utlb =3D fwspec->ids[i]; > + > + backup_data->asids_val[i] =3D ipmmu_imuasid_read(mmu, utlb); > + backup_data->utlbs_val[i] =3D ipmmu_imuctr_read(mmu, utlb); > + } > + } > + > + spin_unlock(&ipmmu_devices_backup_lock); > +} > + > +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu) > +{ > + struct ipmmu_vmsa_backup *backup_data; > + > + dev_dbg(mmu->dev, "Handle micro-TLBs restore\n"); > + > + spin_lock(&ipmmu_devices_backup_lock); > + > + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) > + { > + struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(backup_data= ->dev); > + unsigned int i; > + > + if ( to_ipmmu(backup_data->dev) !=3D mmu ) > + continue; > + > + for ( i =3D 0; i < fwspec->num_ids; i++ ) > + { > + unsigned int utlb =3D fwspec->ids[i]; > + > + ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]); > + ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]); > + } > + } > + > + spin_unlock(&ipmmu_devices_backup_lock); > +} > + > +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *domain= ) > +{ > + struct ipmmu_vmsa_device *mmu =3D domain->mmu->root; > + struct ipmmu_reg_ctx *regs =3D mmu->reg_backup[domain->context_id]; > + > + dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->conte= xt_id); > + > + regs->imttlbr0 =3D ipmmu_ctx_read_root(domain, IMTTLBR0); > + regs->imttubr0 =3D ipmmu_ctx_read_root(domain, IMTTUBR0); > + regs->imttbcr =3D ipmmu_ctx_read_root(domain, IMTTBCR); > + regs->imctr =3D ipmmu_ctx_read_root(domain, IMCTR); > +} > + > +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *domai= n) > +{ > + struct ipmmu_vmsa_device *mmu =3D domain->mmu->root; > + struct ipmmu_reg_ctx *regs =3D mmu->reg_backup[domain->context_id]; > + > + dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->cont= ext_id); > + > + ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0); > + ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0); > + ipmmu_ctx_write_root(domain, IMTTBCR, regs->imttbcr); > + ipmmu_ctx_write_all(domain, IMCTR, regs->imctr | IMCTR_FLUSH); > +} > + > +/* > + * Xen: Unlike Linux implementation, Xen uses a single driver instance > + * for handling all IPMMUs. There is no framework for ipmmu_suspend/resu= me > + * callbacks to be invoked for each IPMMU device. So, we need to iterate > + * through all registered IPMMUs performing required actions. > + * > + * Also take care of restoring special settings, such as translation > + * table format, etc. > + */ > +static int __must_check ipmmu_suspend(void) > +{ > + struct ipmmu_vmsa_device *mmu; > + > + if ( !iommu_enabled ) > + return 0; > + > + printk(XENLOG_DEBUG "ipmmu: Suspending ...\n"); > + > + spin_lock(&ipmmu_devices_lock); > + > + list_for_each_entry( mmu, &ipmmu_devices, list ) > + { > + if ( ipmmu_is_root(mmu) ) > + { > + unsigned int i; > + > + for ( i =3D 0; i < mmu->num_ctx; i++ ) > + { > + if ( !mmu->domains[i] ) > + continue; > + ipmmu_domain_backup_context(mmu->domains[i]); > + } > + } > + else > + ipmmu_utlbs_backup(mmu); > + } > + > + spin_unlock(&ipmmu_devices_lock); > + > + return 0; > +} > + > +static void ipmmu_resume(void) > +{ > + struct ipmmu_vmsa_device *mmu; > + > + if ( !iommu_enabled ) > + return; > + > + printk(XENLOG_DEBUG "ipmmu: Resuming ...\n"); > + > + spin_lock(&ipmmu_devices_lock); > + > + list_for_each_entry( mmu, &ipmmu_devices, list ) > + { > + uint32_t reg; > + > + /* Do not use security group function */ > + reg =3D IMSCTLR + mmu->features->control_offset_base; > + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP= ); > + > + if ( ipmmu_is_root(mmu) ) > + { > + unsigned int i; > + > + /* Use stage 2 translation table format */ > + reg =3D IMSAUXCTLR + mmu->features->control_offset_base; > + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2PT= E); > + > + for ( i =3D 0; i < mmu->num_ctx; i++ ) > + { > + if ( !mmu->domains[i] ) > + continue; > + ipmmu_domain_restore_context(mmu->domains[i]); > + } > + } > + else > + ipmmu_utlbs_restore(mmu); > + } > + > + spin_unlock(&ipmmu_devices_lock); > +} > + > +static int ipmmu_alloc_ctx_suspend(struct device *dev) > +{ > + struct ipmmu_vmsa_backup *backup_data; > + unsigned int *utlbs_val, *asids_val; > + struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(dev); > + > + utlbs_val =3D xzalloc_array(unsigned int, fwspec->num_ids); > + if ( !utlbs_val ) > + return -ENOMEM; > + > + asids_val =3D xzalloc_array(unsigned int, fwspec->num_ids); > + if ( !asids_val ) > + { > + xfree(utlbs_val); > + return -ENOMEM; > + } > + > + backup_data =3D xzalloc(struct ipmmu_vmsa_backup); > + if ( !backup_data ) > + { > + xfree(utlbs_val); > + xfree(asids_val); > + return -ENOMEM; > + } > + > + backup_data->dev =3D dev; > + backup_data->utlbs_val =3D utlbs_val; > + backup_data->asids_val =3D asids_val; > + > + spin_lock(&ipmmu_devices_backup_lock); > + list_add(&backup_data->list, &ipmmu_devices_backup); > + spin_unlock(&ipmmu_devices_backup_lock); > + > + return 0; > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) > { > uint64_t ttbr; > @@ -559,6 +798,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vms= a_domain *domain) > return ret; > =20 > domain->context_id =3D ret; > +#ifdef CONFIG_SYSTEM_SUSPEND > + domain->mmu->root->reg_backup[ret] =3D &root_pgtable[ret]; > +#endif > =20 > /* > * TTBR0 > @@ -615,6 +857,9 @@ static void ipmmu_domain_destroy_context(struct ipmmu= _vmsa_domain *domain) > ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH); > ipmmu_tlb_sync(domain); > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + domain->mmu->root->reg_backup[domain->context_id] =3D NULL; > +#endif > ipmmu_domain_free_context(domain->mmu->root, domain->context_id); > } > =20 > @@ -1427,6 +1672,14 @@ static int ipmmu_add_device(u8 devfn, struct devic= e *dev) > } > #endif > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + if ( ipmmu_alloc_ctx_suspend(dev) ) > + { > + dev_err(dev, "Failed to allocate context for suspend\n"); > + return -ENOMEM; > + } > +#endif > + > dev_info(dev, "Added master device (IPMMU %s micro-TLBs %u)\n", > dev_name(fwspec->iommu_dev), fwspec->num_ids); > =20 > @@ -1492,6 +1745,10 @@ static const struct iommu_ops ipmmu_iommu_ops =3D > .unmap_page =3D arm_iommu_unmap_page, > .dt_xlate =3D ipmmu_dt_xlate, > .add_device =3D ipmmu_add_device, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend =3D ipmmu_suspend, > + .resume =3D ipmmu_resume, > +#endif > }; > =20 > static __init int ipmmu_init(struct dt_device_node *node, const void *da= ta) --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:47:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:47:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107479.1457887 (Exim 4.92) (envelope-from ) id 1utXuY-00010A-Au; Tue, 02 Sep 2025 20:47:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107479.1457887; Tue, 02 Sep 2025 20:47: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 1utXuY-000103-7E; Tue, 02 Sep 2025 20:47:26 +0000 Received: by outflank-mailman (input) for mailman id 1107479; Tue, 02 Sep 2025 20:47: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 1utXuW-0000zx-JN for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:47:24 +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 058692f6-883e-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:47: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 4E43843CCA; Tue, 2 Sep 2025 20:47:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D8F5C4CEED; Tue, 2 Sep 2025 20:47: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: 058692f6-883e-11f0-8dd7-1b34d833f44b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756846040; bh=iHB+SnEhXOCUQ28YU0ftKrC44f0sJC9uDSZ7GVQs13Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FY+LHXnzyBmaSlgocIEx0cemwbifAR1OVN/JQAvYJg8N/kTOJYC3Z5MzoUpFhMssm UHfLBXSA9cwb5p9SvdLCGZqB+PUtnzQ3hj4Llu1KudC1tu5LMqtOS7vTwSjKjVAuIK 5+fhvnqH/5Hhl+SvvpVKDmNegLT7Fhr4iFTUhhJ8YAwa96o6+QkOmViO89pD4gFbX4 OaOCsyux7NLP0+2rK1pklKcPNrb0VOfg6zFBsWZntH3IXjcJzkkK74ItxzsZr9jVEl NRW3t25QxwY35WOBtu5taD5zwnhIQXFvs8/4YtjKCLsSDNQvj2nT5FXNkkhBAstfaQ qDVUvMOozmZIw== Date: Tue, 2 Sep 2025 13:47:14 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Moisieiev 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?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v7 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent In-Reply-To: <712ece45055667a8261956e68ad349fe503b40fe.1756734682.git.oleksii_moisieiev@epam.com> Message-ID: References: <712ece45055667a8261956e68ad349fe503b40fe.1756734682.git.oleksii_moisieiev@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, 1 Sep 2025, Oleksii Moisieiev wrote: > From: Grygorii Strashko > > The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls > handling layer") introduces simple driver which forwards SCMI over SMC > calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent > support. While it is working gracefully for hwdom/dom0 use case it doesn't > cover "thin Dom0 with guest domain, which serves as Driver domain" > use-case. In this case HW need to be enable in Driver domain and dom0 is > performing only control functions. > > The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is > pretty generic case for the default vendors SDK and new platforms. > > This patch enables passthrough of SCMI SMC single agent interface to the > one guest domain serving as Driver domain. > > Configure Dom0 to enable SCMI passthrough: > > - dom0: add scmi-smc-passthrough to the Xen Command Line > > Enabled SCMI passthrough for guest using toolstack in the following way: > > - domD: xl.cfg add "arm_sci" option as below > > arm_sci = "type=scmi_smc" > > - domD: xl.cfg enable access to the "arm,scmi-shmem" > > iomem = [ > "47ff0,1@22001", > ] > > - domD: add SCMI nodes to the Driver domain partial device tree as in the > below example: > > 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"; > shmem = <&scmi_shm_0>; > ... > } > } > } > > dom0less case configuration: > > - add "xen,sci_type" property for required DomU ("xen,domain") node > > xen,sci_type="scmi_smc" > > - add scmi nodes to the Driver domain partial device tree the same way > as above and enable access to the "arm,scmi-shmem" according to > dom0less documentation. For example: > > scmi_shm_0: sram@22001000 { > compatible = "arm,scmi-shmem"; > reg = <0x00 0x22001000 0x00 0x1000>; > -> xen,reg = <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; > -> xen,force-assign-without-iommu; > }; > > The SCMI SMC single agent interface can be enabled for one and only one > domain. In general, the configuration is similar to any other HW > passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option. > > Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from > dom0/hwdom DT when "scmi-smc-passthrough" cmdline parameter was provided. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > Acked-by: Anthony PERARD # tools Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:48:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:48:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107489.1457897 (Exim 4.92) (envelope-from ) id 1utXvX-0001UL-J5; Tue, 02 Sep 2025 20:48:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107489.1457897; Tue, 02 Sep 2025 20:48:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXvX-0001UE-Fp; Tue, 02 Sep 2025 20:48:27 +0000 Received: by outflank-mailman (input) for mailman id 1107489; Tue, 02 Sep 2025 20:48:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utXvV-0000zx-QN for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:48:25 +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 2af2ae60-883e-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:48:24 +0200 (CEST) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by PAWPR03MB9666.eurprd03.prod.outlook.com (2603:10a6:102:2e9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.21; Tue, 2 Sep 2025 20:48:21 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:48: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: 2af2ae60-883e-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tHQoCCogiUznew1yIX/8/Y1mK6nF3+kvmMbhetIeieWsjWr5qpb+YJ+RIo7ocdhLlE3yqwDiHCKEkBf5zL8oLBFy7SomlR5NXJCq9X+jsYEWqV//Gp8pOeQr4LlK/OtmqOwjquohQthB8b1N/KcioLyfzJnA7BPzyfsVOl9WplD4BUUwBJWhiXJfw+9e4EzrRw0Wny2VujRhiRQenY6TAWUIWZ0y7Z+zQfOY43MxTvIiXJm19yqigKCsWwNYtVuMYpk7B5tXwsancBJjLDVEN/bGwo3gi28z/soEcM9KmqwRBbJQq2RZITv4mbr5Gk7UlhiGXOaUzX0XSMpPAnkoNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WqqRyw0Mk2IQZN5rPaDBbkHYOk7OT9L56hUetDGQ9b8=; b=il/Wa2RDdqoJqjnq8Wux7Me4sYXadsdvGcNGZCcKuj6MP89M5Dg5g0DAnM0PmoKQ4qsaWHXIALlywHDZUMhrJ52MM3W0q/lv6qAn3Hy3td+9m4Dj9zzbW6jLSWRimtMeEss/QziRGRkfjnDFYWuzOIPO+ugoXdBhFevLRGL8F9ZEouNu67CFSS2+C7OjqdWbIyvlGPj7TFkJz9UyU9vWdDQBE89P5/vhmWqUJMnqagYZyarbq/2kpmEe0qALar2TZAzUCRpRcGBM7ctBcKi54WEobLAgJpl/VG6gB2BI0OPdIgfjoftg9lUhIq0cp66dN/u+MfUaCrl7VT5awCLbUQ== 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=WqqRyw0Mk2IQZN5rPaDBbkHYOk7OT9L56hUetDGQ9b8=; b=Y8HPqid6xnA6kro7a6EORjemrrRzjg/PzXSxSfCQODAL7kFEGqr3cCZ7OqvB27LUKba4WFZYtkQ2iAz1yaa7L4qzAmhP2h8GsXwwn0jPWwwLLU1I2DLnUX/eqSbigZWg38Wmg+TmsgBN4e0EEG5JBfVFCn6cHBdiEtd4NIj9cZIjosYRWqebJS3idKs6nlfrbBm+PspAmbQp5bv3CGQPvGs82XQXVxP0hp9quFcoMXeJjKrKxMNOIHszpyYNSvX5UA+jYi72NGLjdrcJ+u1+wUDUl4N2/LkjWl9N/mgjlyJsaM2HC6+o4OLHLo+8quMbc3pN46fPUFhMD5uaLGRJ8g== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Rahul Singh Subject: Re: [PATCH v6 00/13] Add initial Xen Suspend-to-RAM support on ARM64 Thread-Topic: [PATCH v6 00/13] Add initial Xen Suspend-to-RAM support on ARM64 Thread-Index: AQHcG405yzu82Zbgnk2mcrS8YfaGcg== Date: Tue, 2 Sep 2025 20:48:21 +0000 Message-ID: <87qzwovawb.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 2 Sep 2025 01:10:04 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|PAWPR03MB9666:EE_ x-ms-office365-filtering-correlation-id: b3352e95-c069-4577-ca65-08ddea620dc0 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|42112799006|366016|7416014|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?sBGb1Z0UAIHi00OvS3QGUW+Q5K89JYCL9SD7N94G6jDV1atCOFgt71roFL?= =?iso-8859-1?Q?VCDLE/iFjG3EejZd+HJ64B81unT/bvmBXH6nA02cBaeXtxlUNfCHWGuHvT?= =?iso-8859-1?Q?zQpwuyQVulh7ADsNpkbwesNDK/TpYkyLt4Bg+JEDcbHdcHb25vQcBxgHZH?= =?iso-8859-1?Q?GVH3NyBdMrf1PZknbr9EAlX6fWErFtTKJ1wzBrQTvAOsMeTojTjU/mrwJA?= =?iso-8859-1?Q?WhyYSgTkc/HsrdfbsiZGjmLUdKlecRAXxyUrR/mqO1XgsXPrfWzvYyY4Mh?= =?iso-8859-1?Q?k+evri+Xm1L9LqpK6xCXd5J1CjMOANF4d6E5HGY/l9fF0gmy8AxxEYPoZc?= =?iso-8859-1?Q?lx3NmpmIO7MgMywNj6moRDHMrZj72tRcRd84sQh3gyYHbDIQD9MyNC/Mug?= =?iso-8859-1?Q?v0RstQH/mpIfpl7H6pPpK1mXX1mXHtRx2TQPlT4vTURlpo6XiT/HoC2rSH?= =?iso-8859-1?Q?AaEMh9DRgTvo9o2cuWZp0t/Loo3CkgyJc2O3U4fSVX3NMhwznr9oHea5Co?= =?iso-8859-1?Q?Ygpd7PCjs9L6IWQfpLSq/dB13VhnzgFWqdkn7oNMgHm5VZGYSeXtWt2iBe?= =?iso-8859-1?Q?ZGCEm8BOAargOCxR8lr7eLclJaa4LnXoIOvbMGxVT6/AZPAFCrNaa2Whqi?= =?iso-8859-1?Q?qCX8ZHkT/M/aGo3za0+qEa6jv0uOjx8Z0o2cHVaSD1ff+CbGAgSWBFWuiy?= =?iso-8859-1?Q?qIdXkEZsWBMBC5NDVcxz9OTU6Y9M7TCoEqaQvwHGSDJAg1bmuLAVBCcOCw?= =?iso-8859-1?Q?vJBFa7V9CcSxSYk/UtC54nkf4uD/Lolya3vzSVm6p9eWih81wvNp0iW+Za?= =?iso-8859-1?Q?+F0RgESdT/Lxni2V4ihF1423Qo5gExh6Bo7cNZMu8Rjl1+5dapqHws8LMn?= =?iso-8859-1?Q?2lR62BECHsBI/Mz7yZgyAZm6w1/khntQnZvmz9uOU/RXNy1JurBuQZlUhG?= =?iso-8859-1?Q?rD/FQK+09kBH4vE5DyaAlbtaZE+5iIrOidRC0JPXxb0DPV+SeClgaX2zvr?= =?iso-8859-1?Q?//0QAAf6IH+CEMkivp8C5RdF+/ysEM0SmvEE7KRZBDvI96jevI+9WQ5KYi?= =?iso-8859-1?Q?iUyEmtR1CPB7NiZ66nD7sTYXPhAoH/R3PIdLhqeUJHVQPyUJp6JJYryKuu?= =?iso-8859-1?Q?ZoOlIs4KtOq3vnpxz4Zv0o3d1ccix8StCA/36hmjOl3IMRn8siVDopzSNs?= =?iso-8859-1?Q?GNu3mqSClNUo+YqwORlasuaIfcPG7sSqti7X2fo8MyXH+zgfeGsfgawz4Q?= =?iso-8859-1?Q?CSx9Q35gVQPk3QwOs7sJngR/exd2S3ps7yblw5gEc8GVJdwAWr5GN4mo5a?= =?iso-8859-1?Q?jebRIFAXSZbvHlOVYcN45MR8kk/16yirQ1zXpN8JtaU+GK6TR3MmVt6iXh?= =?iso-8859-1?Q?ZDY+ttloagnvv2A8Zgf/OqwnqnS/+XI+FVyGVvMtiOG5RRnDbw1dodLv1b?= =?iso-8859-1?Q?O1DFn+kFvRS5aOy6cnVMLXC2xuwu4FyRqBTJ/5DkrwbAyA91QDTPXjGoS/?= =?iso-8859-1?Q?Q=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(42112799006)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?IdgfL7XISriIuqOq52ajG18x+oaMrUWm7t4m82das67EKX6HWFcoUovDGW?= =?iso-8859-1?Q?eqv0G3ql7g4dWrAQUeuaxdnIrbr7dxYjKnDu1W9/x6A3686ii2dl1TgB6q?= =?iso-8859-1?Q?AiiPXg186khFbKITdXUM9BQDmAg5/4VJ496/yK1OgAJp7+7q8Y1x1TPgTc?= =?iso-8859-1?Q?RtzFmt5hr6xT4CT9HN3UyXsTohqizsy+1HTAWpaNzqPhq2YhfnyYpTmFGR?= =?iso-8859-1?Q?84ignLnFvpfUi55FBUCPZ/3gnHDz0R2v2UJU+qvfN8kENitlihpkhaZmFR?= =?iso-8859-1?Q?+6Zm85SAxTb1D4uO9R0a/FJ2mM0rZLEYzqeRPgIifANURdUKQJ0KQJb9o0?= =?iso-8859-1?Q?ry5F9L0lRCT8ylXnnzgcvCwqIXHmeW29+GhPCDT+TxrrwLyaDgtOYVdzkY?= =?iso-8859-1?Q?9UHmxUpMMaa7nMfsf3ixOZlcskcCr1UYJgQ2b0oUS0wdaP2vQbqC/Y6FUA?= =?iso-8859-1?Q?WtGTg5v1PMBrxqkpsyXNLUAWYV9v1hzzKNsKbAV5zfn6bvyP9tqTwkRc0F?= =?iso-8859-1?Q?M8fEHFW1flrrNr8nnlnRYv2gtuEueg6RJfWL2bhgriCjqb9aQHkv/QOaKp?= =?iso-8859-1?Q?h/h04WX8inQkLuhXjfhVQQWhXS2m0p0gioZLFbHXQH3xeTUPIPeetHPckR?= =?iso-8859-1?Q?ZpoISY06MYX6ROWLlZjlmA/EhaoyPDcNvM6yRUBc4T8E09C7qeo8oYUpX9?= =?iso-8859-1?Q?vWD7O8Jbt6ozMwpfL/6ZHyQAimVDsR5YbUFkcmFc+uHuUuwhgQGYaE2/1d?= =?iso-8859-1?Q?jlGlMJeoY0o3FtG+/DZJxwXDd7zqduMsO3a1O+tECEm6MLegvIB4ozQl5v?= =?iso-8859-1?Q?I+nCIGjXL80NegMgUiVaMN1qlg1SC+o1u8elDP9s3rYH31vG/WugdEy8GA?= =?iso-8859-1?Q?Imbx5gILCqPA2yj8s9o2RxNW1C4bfRdgIqiyI4WqyiroDM954EqxsajYrQ?= =?iso-8859-1?Q?8WvZgDAXVeRT2fc5GvYm8Xt1hyKJw+wxmLdGpaIkWKNxwcmWjToG5mc6HK?= =?iso-8859-1?Q?kR/qmT/z/lusYKm1t5zQZqLi6Kc2z+vGzyQDnhcJJVCEqdeys+CwOWce38?= =?iso-8859-1?Q?HcY2/BZ6HLMWyOIL6b9eAJ1tOZAGnlmKMb8anXRipUbAQ4ZHSYUF5dIgpr?= =?iso-8859-1?Q?yNboTXmrnfu15OAqEgZWsnfpQRvaNV9xbh6xohB+9lMEw5TCm02T5xUzyB?= =?iso-8859-1?Q?Ttf/cXBMvTDyhzXC+mvuqp6L96rmCUqyOpjXCsfosB3A1U/dm+Et7Oj/Mx?= =?iso-8859-1?Q?94MQo48bJusItOhicxGJXfd+H8sT8rwX7cMbyv6Y0OmdNe+AeGJxnp9kp/?= =?iso-8859-1?Q?L/sjLjr2fhTCblal7I728RWavbxr3BpHp7MVe4DMfZTgQ+0lbAj3k70wzF?= =?iso-8859-1?Q?1l1ed6XGup2FF0I+KmmjxtHQdjuzOPel9ttIvRHvQoLj5gtCQIkWVI+0S8?= =?iso-8859-1?Q?yaeWDC9TBQ+UIrMs9YllsUqphRND3+omXwuY1yaCvodX4zdqDVGsniN3Hd?= =?iso-8859-1?Q?J8H8DzGhiJy6gG9+iC7HUNv1nZJqoJlq5mcPE3KLmQ4NiHeLgCJdxNP0IP?= =?iso-8859-1?Q?4PrgFbnq7lusmKhvxWnp3Myk7TAS8p1X3gtyMwB+SaGRjcacOo6pb5ntTL?= =?iso-8859-1?Q?8h/Tdgjyd5pIan2lpvKqytvHlyXsxR3TL2Yqs/X+KgYM4JnDns/0waIw?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3352e95-c069-4577-ca65-08ddea620dc0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:48:21.4450 (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: e379bXLMHeXXvShhbQ9v7sxmP8e1C2OPfLOV/weR50HHXpe+hUBFg5Stt6t0JhYRQCKINQ6ZEudkjgp26KT1iw4u8Jn1G/W1cM66icXJTyY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9666 Hi Mykola, Mykola Kvach writes: > From: Mykola Kvach > > This is part 2 of version 5 of the ARM Xen system suspend/resume patch > series, based on earlier work by Mirela Simonovic and Mykyta Poturai. > > The first part is here: > https://marc.info/?l=3Dxen-devel&m=3D175659181415965&w=3D2 > > 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. > > At a high-level, this patch series provides: > - Support for Host system suspend/resume via PSCI SYSTEM_SUSPEND > (ARM64) I am wondering if you had to split this into 3 patches. Looks like patches 8 and 9 are useless without patch 10. They just add bunch of dead code. Maybe it is better to squash them into one patch? I may be wrong here, so maybe other reviewers/maintainers will correct me. > - Suspend/resume infrastructure for CPU context, timers, GICv2/GICv3 and= IPMMU-VMSA > - Proper error propagation and recovery throughout the suspend/resume fl= ow > > Key updates in this series: > - Introduced architecture-specific suspend/resume infrastructure (new `s= uspend.c`, `suspend.h`, low-level context save/restore in `head.S`) > - Integrated GICv2/GICv3 suspend and resume, including memory-backed con= text save/restore with error handling > - Added time and IRQ suspend/resume hooks, ensuring correct timer/interr= upt state across suspend cycles > - Implemented proper PSCI SYSTEM_SUSPEND invocation and version checks > - Improved state management and recovery in error cases during suspend/r= esume > - Added support for IPMMU-VMSA context save/restore > - Added support for GICv3 eSPI registers context save/restore > > --- > TODOs: > - Test system suspend with llc_coloring_enabled set and verify functiona= lity > - Implement SMMUv3 suspend/resume handlers > - Enable "xl suspend" support on ARM > - Properly disable Xen timer watchdog from relevant services (only init.= d left) > - Add suspend/resume CI test for ARM (QEMU if feasible) > - Investigate feasibility and need for implementing system suspend on AR= M32 > --- > > Changelog for v6: > - Add suspend/resume support for GICv3 eSPI registers (to be applied aft= er the > main eSPI series). > - Drop redundant iommu_enabled check from host system suspend. > - Switch from continue_hypercall_on_cpu to a dedicated tasklet for syste= m > suspend, avoiding user register modification and decoupling guest/syst= em > suspend status. > - Refactor IOMMU register context code. > - Improve IRQ handling: call handler->disable(), move system state check= s, and > skip IRQ release during suspend inside release_irq(). > - Remove redundant GICv3 save/restore state logic now handled during vCP= U > context switch. > - Clarify and unify error/warning messages, comments, and documentation. > - Correct loops for saving/restoring priorities and merge loops where po= ssible. > - Add explicit error for unimplemented ITS suspend support. > - Add missing GICD_CTLR_DS bit definition and clarify GICR_WAKER comment= s. > - Cleanup active and enable registers before restoring. > - Minor comment improvements and code cleanups. > > Changes introduced in V5: > - Add support for IPMMU-VMSA context save/restore > - Add support for GICv3 context save/restore > - Select HAS_SYSTEM_SUSPEND in ARM_64 instead of ARM > - Check llc_coloring_enabled instead of LLC_COLORING during the selectio= n > of HAS_SYSTEM_SUSPEND config > - Call host_system_suspend from guest PSCI system suspend instead of > arch_domain_shutdown, reducing the complexity of the new code > > 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 CPU= s. > - Drop code for saving and restoring VCPU context (see part 1 of the pat= ch > series for details). > - Remove IOMMU suspend and resume calls until these features are impleme= nted. > - 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 syst= em_suspend. > - Produce a build-time error for ARM32 when CONFIG_SYSTEM_SUSPEND is ena= bled. > - 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. > > Previous versions: > V1: https://marc.info/?l=3Dxen-devel&m=3D154202231501850&w=3D2 > V2: https://marc.info/?l=3Dxen-devel&m=3D166514782207736&w=3D2 > V3: https://lists.xen.org/archives/html/xen-devel/2025-03/msg00168.html > > Mirela Simonovic (6): > xen/arm: Add suspend and resume timer helpers > xen/arm: gic-v2: Implement GIC suspend/resume functions > 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 > xen/arm: Add support for system suspend triggered by hardware domain > > Mykola Kvach (5): > xen/arm: gic-v3: Implement GICv3 suspend/resume functions > xen/arm: Don't release IRQs 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/arm: gic-v3: Add suspend/resume support for eSPI registers > > Oleksandr Tyshchenko (2): > iommu/ipmmu-vmsa: Implement suspend/resume callbacks > xen/arm: Suspend/resume IOMMU on Xen suspend/resume > > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/Makefile | 1 + > xen/arch/arm/arm64/head.S | 112 +++++++++ > xen/arch/arm/gic-v2.c | 143 +++++++++++ > xen/arch/arm/gic-v3-lpi.c | 3 + > xen/arch/arm/gic-v3.c | 288 +++++++++++++++++++++++ > xen/arch/arm/gic.c | 32 +++ > xen/arch/arm/include/asm/gic.h | 12 + > xen/arch/arm/include/asm/gic_v3_defs.h | 1 + > xen/arch/arm/include/asm/mm.h | 2 + > xen/arch/arm/include/asm/psci.h | 1 + > xen/arch/arm/include/asm/suspend.h | 46 ++++ > xen/arch/arm/include/asm/time.h | 5 + > xen/arch/arm/irq.c | 46 ++++ > xen/arch/arm/mmu/smpboot.c | 2 +- > xen/arch/arm/psci.c | 23 +- > xen/arch/arm/suspend.c | 175 ++++++++++++++ > xen/arch/arm/tee/ffa_notif.c | 2 +- > xen/arch/arm/time.c | 49 +++- > xen/arch/arm/vpsci.c | 9 +- > xen/common/domain.c | 4 + > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 ++++++++++++++++++++ > xen/drivers/passthrough/arm/smmu-v3.c | 10 + > xen/drivers/passthrough/arm/smmu.c | 10 + > 24 files changed, 1220 insertions(+), 14 deletions(-) > create mode 100644 xen/arch/arm/include/asm/suspend.h > create mode 100644 xen/arch/arm/suspend.c --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:50:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:50:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107506.1457907 (Exim 4.92) (envelope-from ) id 1utXx2-00026x-1P; Tue, 02 Sep 2025 20:50:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107506.1457907; Tue, 02 Sep 2025 20: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 1utXx1-00026q-UU; Tue, 02 Sep 2025 20:49:59 +0000 Received: by outflank-mailman (input) for mailman id 1107506; Tue, 02 Sep 2025 20: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 1utXwz-00025m-JJ for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:49:58 +0000 Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5f5371f7-883e-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 22:49:53 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20250902204951euoutp019772216366e471dce5ab670ff270a1c3~hkk2PqBI40583005830euoutp01b; Tue, 2 Sep 2025 20:49:51 +0000 (GMT) Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20250902204950eucas1p1185c6ab6c55958183bb0c347b0396b5b~hkk1r34Tc3157531575eucas1p1q; Tue, 2 Sep 2025 20:49:50 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250902204948eusmtip14b51a6d907c8deca19aa6660d162e2c8~hkkz6C6Li1369313693eusmtip1I; Tue, 2 Sep 2025 20:49:48 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5f5371f7-883e-11f0-8adc-4578a1afcccb DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20250902204951euoutp019772216366e471dce5ab670ff270a1c3~hkk2PqBI40583005830euoutp01b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1756846191; bh=cns0fXIAbt1EqvizSg/wAnSv3SWVs6AXpQ/9VbxT1xc=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=TCSDXZF2Z62YcDiWqMDDa7Dv+pRBN+EUSjgrFZ1mzkO8tak0poyAI0nhbznKNDhqf D8kNvQjhwMLyfbECL2R2+e0uzHGZze/5arbNIj/FB7PwNbK4vxp5cjSUYa4Wb+jDZr M4rtfp2Rgp2ma7OWloLOB4f81ua8G4Rw/nxkJvc0= Message-ID: <2d8e67b2-4ab2-4c1f-9ef3-470810f99d07@samsung.com> Date: Tue, 2 Sep 2025 22:49:48 +0200 MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: [PATCH v4 14/16] block-dma: migrate to dma_map_phys instead of map_page To: Leon Romanovsky Cc: Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, Keith Busch , linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Content-Language: en-US From: Marek Szyprowski In-Reply-To: <22b824931bc8ba090979ab902e4c1c2ec8327b65.1755624249.git.leon@kernel.org> Content-Transfer-Encoding: 7bit X-CMS-MailID: 20250902204950eucas1p1185c6ab6c55958183bb0c347b0396b5b X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250819173845eucas1p221cd6842839f5e7130f131cd341df566 X-EPHeader: CA X-CMS-RootMailID: 20250819173845eucas1p221cd6842839f5e7130f131cd341df566 References: <22b824931bc8ba090979ab902e4c1c2ec8327b65.1755624249.git.leon@kernel.org> On 19.08.2025 19:36, Leon Romanovsky wrote: > From: Leon Romanovsky > > After introduction of dma_map_phys(), there is no need to convert > from physical address to struct page in order to map page. So let's > use it directly. > > Signed-off-by: Leon Romanovsky > --- > block/blk-mq-dma.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c > index ad283017caef..37e2142be4f7 100644 > --- a/block/blk-mq-dma.c > +++ b/block/blk-mq-dma.c > @@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) > static bool blk_dma_map_direct(struct request *req, struct device *dma_dev, > struct blk_dma_iter *iter, struct phys_vec *vec) > { > - iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr), > - offset_in_page(vec->paddr), vec->len, rq_dma_dir(req)); > + iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len, > + rq_dma_dir(req), 0); > if (dma_mapping_error(dma_dev, iter->addr)) { > iter->status = BLK_STS_RESOURCE; > return false; I wonder where is the corresponding dma_unmap_page() call and its change to dma_unmap_phys()... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:51:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:51:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107517.1457916 (Exim 4.92) (envelope-from ) id 1utXy8-0003pS-As; Tue, 02 Sep 2025 20:51:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107517.1457916; Tue, 02 Sep 2025 20:51: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 1utXy8-0003pL-85; Tue, 02 Sep 2025 20:51:08 +0000 Received: by outflank-mailman (input) for mailman id 1107517; Tue, 02 Sep 2025 20:51: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 1utXy7-0003o1-4l for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:51:07 +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 8ae426d8-883e-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 22:51:05 +0200 (CEST) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by PAWPR03MB9666.eurprd03.prod.outlook.com (2603:10a6:102:2e9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.21; Tue, 2 Sep 2025 20:51:02 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:51: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: 8ae426d8-883e-11f0-8dd7-1b34d833f44b ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nr+CTPh7NaT3v2vD2gynFLwSvD/CF2nwaIpLJi0WB0FoanG2+tRHoaYS4Zc21mK75Bb+hpGhiPgiisSVyiEfdzTBNVcnFXBAHBFdq6BqXcAII4hYo295f6KA6vXfR6vsU0XIiQEkORM3yaRKdCii9KdRRkpUl55+ykeR/6KWUsMKRCwReMARGsjmJdWrmb3HUFbkF45c8iTMFdOAt6BEdKFAta105FYmbxwXFsl9VNupyjH09D7tzt8npNhyLb2DAuOsZDrGZa4KKvUrmKGtFvSCuL0/HyxDrbh9ewq2pZsKYMjOWeIkfrNSMk1EblYW5DISwphlKUB3zNfqspRr2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xZg9WdvBc4ptVK6Fzpby0SF6v91+OlzcC6RnQhtWsRU=; b=uOO7cmXqfj/R0TO7PBP1V9vX81FgrmeuHTiHqQq0Ev5WbFlPEh9SsmSnfLrFNFgW5+GZ9LLQZ5/uUw59OhQe9UV1b+YNyu7wG/LUh/4mLKH9SwU9Y09WRC83aKYVGfSM4ZN7RGo6t8ov/jdq829tMPKftGLQ+25nfZvCURt3RcNJIgTX8ItrRLdt0FIYK7tKflT1ZNJLL++K/kvswVOXL0mP1FHGZ/+mW+dtzzWMYAMJboTAzemsPpPNJEGOWFFD+Y5WcVmYqGochrQEoDeDKB//OZyQVuXILJ9wtJkiaCzhfzuXGZtN4x02JkfoGb6WWNVUHImOwCxPd/Ykv2zWBQ== 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=xZg9WdvBc4ptVK6Fzpby0SF6v91+OlzcC6RnQhtWsRU=; b=nzXuFClTQv/5MwM9qAibKDDr+tqn61CtwOLmxRmfOpdfCI6gBhcNcz65fB7yS7WPFQ5UcARWN77cpLhHYV2nfUcx7RohZnbF3ucFupj62U4kK/HjecG+8Lf546GmdoXAWh8CbMkXwMse37E4Q/xvU9g4qHS+QUkXLl86n1E/YIJApdzXGaBWLpDVJJV37nakbjUBYzC3PPuBD4EENUH87Iy/KCNTZBaLlUxl8KTr7CWf8Dj1Jtf9DzjQI89ZpwdY+BqoXUgvPrveVqxDo9gPYlRHbEo+bF0BLkfMmxWaOxrbCIfP0rGdmCgdMB19gpAq2LzMNOZvQQ53scCmfjHQ1w== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Rahul Singh , Mykola Kvach Subject: Re: [PATCH v6 12/13] xen/arm: Suspend/resume IOMMU on Xen suspend/resume Thread-Topic: [PATCH v6 12/13] xen/arm: Suspend/resume IOMMU on Xen suspend/resume Thread-Index: AQHcG40/8HE5GdQkB0yiceKuLwbmGQ== Date: Tue, 2 Sep 2025 20:51:01 +0000 Message-ID: <87ldmwvarv.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 2 Sep 2025 01:10:16 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|PAWPR03MB9666:EE_ x-ms-office365-filtering-correlation-id: 57fdb8a9-5609-450e-ef90-08ddea626d05 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|42112799006|366016|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?goqhH50nrd0UuMRUhZVbtZQqwOfWiX7N1OQMptZZTonhCvPuGbWw8iFqmg?= =?iso-8859-1?Q?JzoJi4Hg3+PPPGIOdcdrkPeTnGomlYNFdmiaeU6Apj7NyZrTpXk0wGmN3B?= =?iso-8859-1?Q?2AfaeKgT2kSU40zFrFo6baEP5CezkhPOwNzqmS09KrdQhMS08LddILDjhG?= =?iso-8859-1?Q?37cs7F8Pxp5mYEZ6K/L9J7A1D5uKa3iZE4cnNrLa0xe3l9Ig5qPCL2e9wP?= =?iso-8859-1?Q?i9uHvMNw/shMihW9LuBBsg9WWl8up7G61DqEM126SnTAdy2RP0HEXNI6bB?= =?iso-8859-1?Q?Akjyl1Yigwt/GGcyrjJ20cUAgdbE4GU2fS7B9vGSkbsvjc9CKmx5AFD6XH?= =?iso-8859-1?Q?Ru8ZvThdEOCpYVFJGDhx0fwXx4qh6MTETPPCX7xhQQJ3H0r13mBq7ubstC?= =?iso-8859-1?Q?p2I+ehrNtyjqnQwMF5p9h/8/FjL/z4ZuFfaS87J10A0NbOlujRm7Mz4ybz?= =?iso-8859-1?Q?8hjFRKOlm2A/ref/IYoVnsIKYs0VfYJeMGg/fYYt055GUHgVF6T8T2gVHw?= =?iso-8859-1?Q?AqIYPeCzggIRT+UYq6vtjiL9AKqvmDcHFHD/Hm+ty8nUmMQwerrKqX+aQa?= =?iso-8859-1?Q?SwjAk7wTtN8als7p4N6FM7PA8FdLF37Y6PjKQxuP2cbrW76pNJzuwmYhEL?= =?iso-8859-1?Q?fGvcIcjmql5pUGbYwbrYdmTN1kUCNgYrWQO6wmrwUwPfW1ixdlFZKpam2S?= =?iso-8859-1?Q?twf1Bk/KD3OfsnemRnqPy9+iaEIOGQRUHd+XlgBVrhLibGsY16IF8EFc+L?= =?iso-8859-1?Q?i1jnjZyFGaE5ukCr+OO4iFebbAXhmllEynH6fqHBa2rv4SaTQRk4ObZXsJ?= =?iso-8859-1?Q?F84TOrLqFkeuPr9K7vH+GYXnf8ku4CdoykD17A5ThPYMDmMIxC8MFY5IAO?= =?iso-8859-1?Q?0ZSKDpF5otc4uMEI5tQyUMgU5e0hNJkxUKFfNnqcSDWfX66BXveu2el6KV?= =?iso-8859-1?Q?skUe4Nufkdjs80lJi9+QvJf0xsPCJvA+I55VTbhcQZTo6rA5NS+Zp5sS0i?= =?iso-8859-1?Q?sTu7VuZT415aZ5orsDPCArvZ0/8USjjReL5caxNTlparT7Lyoa0aYLu0WL?= =?iso-8859-1?Q?C1zdUBmAWEjxTzPSSPUjfqvdYdli98OnQEJqvI+kBWaYadjjGABNHUmU4u?= =?iso-8859-1?Q?gT/w9Jv8zCD1VXwtvuuhSu2/954mURf1InKE4tlxrP3AD61sa2zy+0Q9v0?= =?iso-8859-1?Q?2NLCQNlO4o1mT2UTzQaMVlI05STrCGcw85gTiRTC8y14H6+RkuJyMb5qo3?= =?iso-8859-1?Q?+TQ1mukjuxkuiUOZwbf5f7+n9KT3zzf6rNp3Q/aEVPhfuTFysbg8Vdwhqw?= =?iso-8859-1?Q?8a/JaPns4I7o8pMvEzHGdfa8PTlZMEiIq7o7SmMDBqUYJFM8xNqY4z28Az?= =?iso-8859-1?Q?JezmiFqWBA6A3sr0+esx7XaPEP8MqUEWJHDzIGvP6eJmLWhZFYllF4DdLm?= =?iso-8859-1?Q?8TxuK5ejcADS26EZ3l+ZHEvv7WAkTgmCx6+ANsbaXU5cJu2J/txBVHcxMQ?= =?iso-8859-1?Q?DbnIXukB1ei5XjzRq30wOHOw6DZngfN521U+0bvJUmgg=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(42112799006)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?XNDoOMjzykRHvAPxrgy7HEptBGh9mbE9SF262K71rhBMxXNSRriWvMDIwq?= =?iso-8859-1?Q?WSxxkr9GHWOl2oASLxnc4ocLwqtrqpAdFDVpz4qTYWsBGuF5c+ZeKlZvYj?= =?iso-8859-1?Q?UEfumDHPxZNBk6v3XqFc0yaJyH3a2srMd2vHjj3TwLw3VzrakJIxkV9bQ+?= =?iso-8859-1?Q?YBMj9OIztgWua0gyNhP3kRoyryd4Rc0Z1s73ccHcToT2N4QKZQO2LSc6yb?= =?iso-8859-1?Q?21T+vcnekUDvlPbw31aH5dU2xDdBFxQkE11VGV6mOq8TQcdM8LyQefWGGR?= =?iso-8859-1?Q?kwmuceAiZZoswixjTr8tRPmo2rYzKwNiiuZdtikPz7ZQ2Hcy4dCtIkaIBr?= =?iso-8859-1?Q?5piM8Z7ApOlZ4FhHw1fJAMxSGvi5YdCkY0rqgbjeWAJoyO7OS+pT7xdrAV?= =?iso-8859-1?Q?Bwtk8Dn9+IgTnfIhACJHxHeckhJriaYXPVkOYWyGwme00A7D8EIVLOwQky?= =?iso-8859-1?Q?TPCfJ9Aqo+9kzVOFZOX+cdnKkT6djC3aQpyrFCsYByPARD3KBwYN7n0Ymx?= =?iso-8859-1?Q?Ril+rJn2key7LvP0OEmFxLRnW2WBveWp8K96jnNqveRdKPGXCZR04CP5kL?= =?iso-8859-1?Q?3flMg0ZmHvUE7Dj7+8w307td8y06nAoO65pOQzkleGoRsL0g3vi3xWX66X?= =?iso-8859-1?Q?9IzXjqsl7TRPpxZe91bT17cRCccdECry+uzuK6xHIkg/Clx1gHDntUprjv?= =?iso-8859-1?Q?nf4mXcYON7KpOELzySc6FroN4taQKw4YpJOD6N7r1bEvIi2ZnQ90ryvSAN?= =?iso-8859-1?Q?HwwmfTNum9le6vqrqRcDQFa1N6+rh6HAuSQVISDRbxZjeiwkpaflvW+lrX?= =?iso-8859-1?Q?SsvasaMrsCdkQ+HXVugW7yrYPIxjOnPxUd4TlCGOB7oCRQMHkd0rAeiog4?= =?iso-8859-1?Q?gYLAvRL3X6n/+vZ7TMfCsvQjH7mqRycEQMoTi2HlMcAAohKAVlmvk/yedp?= =?iso-8859-1?Q?cZV1goRULTJNg2ZhS6wJN64sOjbig5tZYIVf4Y2J4rBhAzm6wNH7sUfB0J?= =?iso-8859-1?Q?Xyr6Hx4kr0tGYYRUpcx6HtMAaxkkshym3uvJP3NzHXwpza3t4gLjRoJ3s0?= =?iso-8859-1?Q?1JiXVpkyQRmScQKL8Pz4pZvBfcUl+t7fpBOnV/cynRZ7Be/R/LGoTD+yu4?= =?iso-8859-1?Q?WuJdzmzIuEUdCgy4212TKOJwigPSAo0ADzp399zFoK3jLZMZF0wAp/pvTI?= =?iso-8859-1?Q?bhLbJQRGjQb9qmQ6gnQ54FYZTNb6TZWUlxO+nlzr+18B/t+aDGnGwt+vtH?= =?iso-8859-1?Q?zhSLmdL53jIiqDGwGdTu7efeIdfI2pDU4MwRkozp5NsIGSWQDKIKXsO6ae?= =?iso-8859-1?Q?htBIkiz2tQoMffvAIsPhWUm4WQ1Sh/vRnPz17qWRLaL0lmEbrWfyY2RsBv?= =?iso-8859-1?Q?u9D6p2Wknlmg7n0zHo8CfVQI0gQvY0jEzl3u+38uMvFb1T1aYpo4obFZvF?= =?iso-8859-1?Q?7RhTDKLp009PulZ3bCEoy3phgDSPMhQzp+NJjCrVzYINAEjWMUpP7ilOEG?= =?iso-8859-1?Q?zK4kyTnJcL+sti60te0cDpwaRofUHdzDnM//h3iJgkjb22CuEprWMmTYnc?= =?iso-8859-1?Q?kGD5TqslPP/5o7stemTQkc71mUhCLNZg48H2UoDiD7z6HkrO8Ix0imjHMo?= =?iso-8859-1?Q?iW+/tiMpkS8aF2Qftu+kWWM8KkrPwPF0ghJlIbCF5+c/dbIfaETD3u9w?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57fdb8a9-5609-450e-ef90-08ddea626d05 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:51:01.3004 (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: oODbxUsqtf3RY0Y/UUylZ/wISDvz4AoNIhWB2lLICVeRaYTpiemK2Yj2inHD4KuX5SddROnW8wlLTRmMOGQwj/L1unBMGRN8UZVzn1FhLhE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9666 Hi, Mykola Kvach writes: > From: Oleksandr Tyshchenko > > This is done using generic iommu_suspend/resume functions that cause > IOMMU driver specific suspend/resume handlers to be called for enabled > IOMMU (if one has suspend/resume driver handlers implemented). > > Signed-off-by: Oleksandr Tyshchenko > Signed-off-by: Mykola Kvach Reviewed-by: Volodymyr Babchuk > --- > Changes in V6: > - Drop iommu_enabled check from host system suspend. > --- > xen/arch/arm/suspend.c | 11 +++++++++++ > xen/drivers/passthrough/arm/smmu-v3.c | 10 ++++++++++ > xen/drivers/passthrough/arm/smmu.c | 10 ++++++++++ > 3 files changed, 31 insertions(+) > > diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c > index 35b20581f1..f3a3b831c5 100644 > --- a/xen/arch/arm/suspend.c > +++ b/xen/arch/arm/suspend.c > @@ -5,6 +5,7 @@ > =20 > #include > #include > +#include > #include > #include > #include > @@ -62,6 +63,13 @@ static void cf_check system_suspend(void *data) > =20 > time_suspend(); > =20 > + status =3D iommu_suspend(); > + if ( status ) > + { > + system_state =3D SYS_STATE_resume; > + goto resume_time; > + } > + > console_start_sync(); > status =3D console_suspend(); > if ( status ) > @@ -118,6 +126,9 @@ static void cf_check system_suspend(void *data) > console_resume(); > console_end_sync(); > =20 > + iommu_resume(); > + > + resume_time: > time_resume(); > =20 > resume_nonboot_cpus: > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthro= ugh/arm/smmu-v3.c > index 81071f4018..f887faf7dc 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -2854,6 +2854,13 @@ static void arm_smmu_iommu_xen_domain_teardown(str= uct domain *d) > xfree(xen_domain); > } > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > +static int arm_smmu_suspend(void) > +{ > + return -ENOSYS; > +} > +#endif > + > static const struct iommu_ops arm_smmu_iommu_ops =3D { > .page_sizes =3D PAGE_SIZE_4K, > .init =3D arm_smmu_iommu_xen_domain_init, > @@ -2866,6 +2873,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = =3D { > .unmap_page =3D arm_iommu_unmap_page, > .dt_xlate =3D arm_smmu_dt_xlate, > .add_device =3D arm_smmu_add_device, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend =3D arm_smmu_suspend, > +#endif > }; > =20 > static __init int arm_smmu_dt_init(struct dt_device_node *dev, > diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough= /arm/smmu.c > index 22d306d0cb..45f29ef8ec 100644 > --- a/xen/drivers/passthrough/arm/smmu.c > +++ b/xen/drivers/passthrough/arm/smmu.c > @@ -2947,6 +2947,13 @@ static void arm_smmu_iommu_domain_teardown(struct = domain *d) > xfree(xen_domain); > } > =20 > +#ifdef CONFIG_SYSTEM_SUSPEND > +static int arm_smmu_suspend(void) > +{ > + return -ENOSYS; > +} > +#endif > + > static const struct iommu_ops arm_smmu_iommu_ops =3D { > .page_sizes =3D PAGE_SIZE_4K, > .init =3D arm_smmu_iommu_domain_init, > @@ -2960,6 +2967,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = =3D { > .map_page =3D arm_iommu_map_page, > .unmap_page =3D arm_iommu_unmap_page, > .dt_xlate =3D arm_smmu_dt_xlate_generic, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend =3D arm_smmu_suspend, > +#endif > }; > =20 > static struct arm_smmu_device *find_smmu(const struct device *dev) --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:55:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:55:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107528.1457927 (Exim 4.92) (envelope-from ) id 1utY29-0004SW-Qw; Tue, 02 Sep 2025 20:55:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107528.1457927; Tue, 02 Sep 2025 20:55:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utY29-0004SP-OC; Tue, 02 Sep 2025 20:55:17 +0000 Received: by outflank-mailman (input) for mailman id 1107528; Tue, 02 Sep 2025 20:55: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 1utY29-0004SJ-5N for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:55:17 +0000 Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c202::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 207b55f1-883f-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 22:55:15 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by DU6PR03MB10942.eurprd03.prod.outlook.com (2603:10a6:10:5c3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 20:55:12 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 20:55:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 207b55f1-883f-11f0-8adc-4578a1afcccb ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QpHKkXgRsCMc5+wubH/XlB2kLZKR7dURo9nMjLmrSrK0G7mGIT2kPa+K19ZbDVlIUsqSVuwpzCQ2KhAgEJCIite8imTVkLeVcwdRVeQjZmXQxmf273bomevTYceJb//NhcU2AW0XeLTwJZlZDoOI6Ec/D1lHwW9tt+U2DECCVp6tsunrGr8v2t5+8ofgqQ3xx0VhF5S2pOz2413Vkve1Vvvc3uXC2WeOlkFjaI93TdUbc4UJakKcxBbE+m93H5Buab0ov9fDKscUDTqsTxTbPeLD8OCgN1htUEyuoEYLCS8+/czC24V/XywVF+6brScLN2n0GH2VKmqP9gGK/Wb9Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bN/MR7wiZDcyYcAlpQvmaGF4GxqF1x0A4lpNK/Q18eo=; b=Ir+BXWP8emf0NlsOLkLfysznOoZB2CNUD8mLhWb1C/tn44lB/QAydUaKurEjBjmQvImhSnWBRhV0Shbm3lNE0yTPew4zn3b3B7KNqX8YwKiCmuOnwV3BctLbc1WObOpn9TyRhpgAf7VrXMEnavSb/xQ1jsUCR2EN9gkZnLinb6yTGvvWmOSa8Gb7TH9zp3dkLGIa/6B1x1ZA9x2OcNEdw9m0SlccG+1rNE5EBFh38kvYJtOriN860cAZE6Ok93HbBzM9PUcrybS5+iL7WRHC3H/8ub3YCkY4qu28L2QPERbe8KpWjG/IFGqBTYAY0QiIeImLD1qQoxZr/D1JDYNNkw== 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=bN/MR7wiZDcyYcAlpQvmaGF4GxqF1x0A4lpNK/Q18eo=; b=s6lvxEdg6N2aqTY3NcAd0nHjDXolppYMeZxfFF9elQth8ycWeBsZYzcE1w9gXrtM4obZ87DUsFHeHnSsq/AbVxitv5IPlO5J2Vs8rIzvqPJIRMn+y58Psl6XrL0rKMItWoRZR2YYSyZznLGdNxkbUWcYdqOKO6OkEyEyW8DhhSztbOZWIO+LtSzTmW5OwnBRRgrsAcUnqJKnFE+anh9reSvPdxTMVPy7ASEzNI/hU5kIIWpN+7elm7yMGBR9liJ9qDEGLa3f9Ib07H/s8slJNlqbdwTXpEuTnMbIl0VXYK53dAHoqf1kSalBnxhOEbmpepA3M1unwsIt9T1zieOV1A== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Topic: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Index: AQHcGP7lSnKp01vKiUyg8GCh+goOA7SAIt4AgAAIk4CAADCcAIAACbGA Date: Tue, 2 Sep 2025 20:55:12 +0000 Message-ID: <9d784bea-7ae8-4b0d-aa54-155dccd3f533@epam.com> References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> <06ff285f-39d5-4ffd-b842-6d776bb793ac@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: GV2PR03MB8678:EE_|DU6PR03MB10942:EE_ x-ms-office365-filtering-correlation-id: 1623fd42-b581-4d7f-944f-08ddea630282 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?cEFSeEpvaklQTU9FblBHZnN6WUxEZTVUWXVRZzU3MFV5OWI4ZFhXaXNYSVlH?= =?utf-8?B?VC9pMDR2VFJ2bjAwcHlSeGwyQXJvQkxuckd6RFc5N2dYT0tDQit4R2FSSTlP?= =?utf-8?B?VWJrY0RLeFJaV2M1cnU5dTFoWmlYSlYzS3FSVmpZMG90MUFaVWlDS0wyeXpz?= =?utf-8?B?aU1hL2hJdFhJU3FaUlBBRzNmS1AyQVRBZG1PRVNLc3ZRcmdmVHY4SUt2TGF1?= =?utf-8?B?ZnNnZWtXbDVMZ0JKOEprRnZjd2puWVNCSnFJQU04TTEyWVNtb1Z0QkZxUDBk?= =?utf-8?B?VmVEcktDdFQ1eDRjaXMycXVmNEZCbGVjNGRlcnc1OWdQOHhUaWZ1NXFkN3VV?= =?utf-8?B?VUZ5d1BmWm1vMUhHUkw1N2ZZS25mZVNuT0lrdFkxam9TV0lFNjdOZDMwRWZo?= =?utf-8?B?Z29Eemt6K2xTak41UTh5cU9kZGF4SlVvSGhTREdQak1JcEZ1Q2xVMXlpQ2w1?= =?utf-8?B?d0greUhqRXBLZmNrZGRaVWlBWFdtakxWODFuM3pDWFI3eCsrYXFGcFNCQ09w?= =?utf-8?B?c080MWEySWUxNGgzcWtOR0xweThVUTF4Qms2a2dOYXd1Vk1IU2d4d1lHV3Bm?= =?utf-8?B?MXdydGtXZUVvSGRlUk9KQzFCM2lzT1ZpWjZyMXZJRFRRd3ZmZFRJWWM1MVls?= =?utf-8?B?MVVNNDdWS2tYZC9TM2hOLzZlc1pWVVpxMnRsS0JsM0tEOUJnLzVnR1VSNmR4?= =?utf-8?B?Vjd6K0VieUlQOTQ4VUhJb1pObythYmwrQSt3MzhsRGxQSmUvR0ZNdVQ1bDBk?= =?utf-8?B?bFJDazh3ODdzOUxjbFplQ3BwZlRHMER4WU9TblR0WUtMUmtJKzlrdTUwQTNQ?= =?utf-8?B?N2tJTENDZjFBa0FMMVFGNi9OaHZsVzJnQndVQTVtQnlXMVlRQ09Rd1VUN1kx?= =?utf-8?B?RUdsZTFSMi9BemRYUm9Bd2hoNis4dDhIQVptZkV6empWejFWMUk2YXI3bks3?= =?utf-8?B?WjFxR2NXRTUzdmRsazdJU05WRUFDa0p1VlZVVUQ2SXdVdWRWOVBPSDlhTitp?= =?utf-8?B?clB0Qjh4RTRHWXlGMFZkUlUrVDhKcXd4UzNkeDFLN0NDVEdNWXlxRE5HVi9u?= =?utf-8?B?Y3Y0TTNTQjFVaUJqd25DWTlTSkxnak9hd1A2UnBJb1BUOENQc3hlV0xvbEtk?= =?utf-8?B?Snk3Q2d3RS9DVjZENTM4RVo2UGpyYTRxRjdCTXBvY2NhUHBhVXR0cjZpZzdp?= =?utf-8?B?b2I0cUM1THRtUEI2aFVFbkJCT3U4T1l0dU9nRnZUOVJHYWtQUEgwTGNobEpX?= =?utf-8?B?ZXE0NDNuYlhNMlgrNXBVVGkrOUFBWTFqRHFVU1hFeVdmTDBpeFRYRUF6OG02?= =?utf-8?B?Q1IyYW40ZzNIY0I3NXNhS2ttWWV0ZktTZXpDQVJVc0F5a2NKVFpRNEFNR2Zl?= =?utf-8?B?Rm1GdUZ6alRUa21KYUpXcmdkYXZ0V2NFNWxsMzdHM3FuUmVRTG1QaWtaelQr?= =?utf-8?B?NmZRR2xYYnNMT0wzeHFlbHRaV2pTK2k2aFA1N0F4SGd0bEp1RFBGV2pNSmFi?= =?utf-8?B?QXdBam55aGtNb3JzbnM0SXFVVDFBWXBPZ1JRVFUxaUVnQjdhN3cvaStXMElm?= =?utf-8?B?OTRoeHNDYW1TbUZrTFR6Y0hwUnpIWUYyTERuQ2FLL3VpLyt5aUgzdnFQWTYy?= =?utf-8?B?a0ZWczgySFRHTFE5ellDQ0FEZTVONG56RFc4ZnJZSGZZbWlraFNXSXZnUkRK?= =?utf-8?B?VUdjZG5aMXZTUG9oeXdYNUprTjJsK1hHVHZQUHRjZjdEeHpGRG1iMGU3aXFP?= =?utf-8?B?NzZzTDIvR2VGaThLMUNxajNjT0ltbEtTbTBiNTZvalhHSStIMjlOQmowYWt3?= =?utf-8?B?ZXNRU3BGanZSbVU4RDlMR2NhcWt2bUM1ZHY2bk10ZlZBMnVGTzk3dExRSnV6?= =?utf-8?B?aGpwZmRMK29PbUowSTRyMkdubm1Gek1QWXp3MnNsUTFmNXl0V1Vlc0FrWHBN?= =?utf-8?B?WEgyazJaT2VCSEhMSFZTL1Q4eUNheDZPVjIyZDFUYjJHTnBVLzFpR0tRY2NS?= =?utf-8?B?M2gyYUxJbENBPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L0RtOUl2SktTS1AzeVhLM3VDSDdaK0h0UzRPeHlWSFNmSG1NbnBVNTBGdll0?= =?utf-8?B?ekJvR3Q4YlJZZERuTnllTEczWWVhdVBSYzE4VkZTK01sQkZ6Tm5RN25JYjQv?= =?utf-8?B?WU9lOEJ4RDYrQlB1WG9wSFdEKzViMUs5cVZVbXMzQ0tSNlZqVU16S1ZlUStL?= =?utf-8?B?SXN4aGMrbEE5bXBQQ2s5NDl3VU1EdkN5a3NXa2Z6QWwzOXl2dE1nbVh3TDU4?= =?utf-8?B?ZEZFWTBBdFFiTGptU0Y3MS9FR1VCcFE1ZmpkTE1lUzFsSG44WmtJcHlJOXBa?= =?utf-8?B?ZHc2Rm9mZnk1eDNsV1QrZURJZXZTeEpma3NvTk5CTGxZOEZzeFB2REdoeUk3?= =?utf-8?B?YnFkVXppSTNKdmtybnZvVXg4VlYwbjlNRy9udnBlK1YyakZ4RmExNG9ENlpu?= =?utf-8?B?VG5yYXA0dTRrZ1lXR2NRL1ZCYTRhOTR1SFBWY2ZaYWM2ZkVKOUZaQlU1elJ3?= =?utf-8?B?T0puejd3WUppMk5Ya2JabjJnSWhkMVdZaEZocnEyR1F4RmpoTG1ybFlXNlZR?= =?utf-8?B?WmxXbjdlNW54anE3aGoxOHZzMXdnejYrNUZreUVpVHVmMThnYld1dWtWNEI1?= =?utf-8?B?Q2N6VDhNN292OUdtY0diekhpVm9FdE1kRVJ0eEVVT1NoU0NuNEx3Vkg2cTdj?= =?utf-8?B?M1NBQjR2Vkx1dWZ3cWlSTDNHSVRyVkc2TTNzZXNVeGtoWWR2YlhxQXdMeVND?= =?utf-8?B?WnNVRVMxN2lxY3podUhCTXZDTElwWlNhZkJPN0ZKRGd4U25QV2J5YWxrZXZY?= =?utf-8?B?SitnVlJqNk1oczVZZWZSbDR6Mmo1N2JMdjd6WDBjbEdOd3J5OGNsdTVVcDE5?= =?utf-8?B?elQ3cmpVN3FWRm14WTQ3MU1ZeG1WY2R1b0xQRXhiRXl2WTE2NXA0Y3o1VDZt?= =?utf-8?B?bGcrRjV2RXpudm81MjFpWWtqaWR1ZHRtRGYrYSsya0taYWRMVkpOYnZMc2hU?= =?utf-8?B?TjhpUC9BZEdkQmY5UFNUTzhoOVE0WnZmUURteFhTNDMxVWJMaTB3aE5tb25I?= =?utf-8?B?MFpEUlVOZjhvSmtZU1NTMzF0QWF5ekRlMkxOcHNlbHRYV3FwSFNmdVp6bXpE?= =?utf-8?B?SW4xZ1IxRkFKTXdsNFEvVkdIb1hJRHNIV1N2Ui8raytMR01rVVljdCtFMVVh?= =?utf-8?B?RG9QMHgrYjkvVVBIM0R4M3ROMG1KaUJXUFZJQ0l3K1VsUlVOTGJyTFZvdUJO?= =?utf-8?B?ME9oYUZEaURnMkRLeE9pRG9kL294ZkVVWG1CVWIxcHNDWUZLbnBtZzRXYlh2?= =?utf-8?B?VGtTYlFqTTVEYXhhcUJpQmdsNk1VWGlQZTBJN2JZRXQ0aHRTc1JxVUpGS2lh?= =?utf-8?B?aGVwcGo3WWUrRHNxUmpyaWo2RGx4Q3Z2cU1WNlZnNHlTZTZmWjNrVnV1V2dU?= =?utf-8?B?U0JWcGJzUW1pclJFRnoyQWFQaENma2dPQWZpb29TbjFMaEg1d3Ixall6RkVt?= =?utf-8?B?MU4zTHZOdmtSZ3dKY1ducW9ERHMzdk5xbVQ4Yk9QdzN5aDZUazFxRmVpVVpz?= =?utf-8?B?Y2xTQ3JjOUE5cXA1MTBzMTUxbjBqZ1NZYUJBNDd2Q0hXZkUxY0xsb1h6WTd0?= =?utf-8?B?MjVmK0QvMWdaa2ZWMXFaditkT2tTKzBYWi9BTTNCZWlaWkRwdDAyRFJTNFg1?= =?utf-8?B?blo2SXhxT3pwSC81WTdzdDZidjJEellyU2Q1REQyajAvWEhuUFEvMUFsVVY3?= =?utf-8?B?VDBBbVRXalJxTlE3MDdaaHRFcWNHSVBwbDIxcmVMT0lMczBNWVhENkFvZnYy?= =?utf-8?B?cVdSUnV5TlNVS0U3VDIvU2xBRlJMMG5VWUdGd3UxRHp3dkxrRkc0WXNlOVZN?= =?utf-8?B?YjlSSy9rQWp1VCtBYTJQRUsxRjErdy9QUmdUY2huUWZIZWcwcjYxS2RDS2pM?= =?utf-8?B?TkhZRGduNWpvZi9aZkpVMTVaU0NHMGVJK2YwL2oyYndZMm91eFkySVhnQ1Ew?= =?utf-8?B?QWxNY1dnSlQ1S1lBTUJycDUrd2FxNGxIcmhUeVpiK0xNVzdEZFZmWjZHck5w?= =?utf-8?B?QS9ZbkoyNW03Q3ZZVUxrQlhKSXpKVVBXbHV2UGlFUGJNWjhsdGtEemduZDdL?= =?utf-8?B?TGlybjcyeGZwdHJsb2lsQk1CcGtQSFlzb3R3K2lzUnJ6aW5VeTIrdnpNUFdy?= =?utf-8?B?RHpMOURkYWtHWTlSQnhlYnU0aHhQWWhhR2Izd0l6eWRFUXlCejV1MmhRMXBN?= =?utf-8?Q?ktsVvCWCvLmGFGrC9IIoa+c=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <188523B599C13D498C9EC806BE4AD546@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1623fd42-b581-4d7f-944f-08ddea630282 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2025 20:55:12.1175 (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: EZ8+BsjYQnfuoRSE24mG8eo9xJAdwPR7iOCi1rfiBHOymDQKMKvIhJFnr/BYFZz2prOmmZ24k7d/Yi/xjPWMFYDS4vhqj0jns9kKz3rSHHs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU6PR03MB10942 SGkgSnVsaWVuLA0KDQpPbiAwMi4wOS4yNSAyMzoyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBI aSBMZW9uaWQsDQo+IA0KPiBPbiAwMi8wOS8yMDI1IDE4OjI2LCBMZW9uaWQgS29tYXJpYW5za3lp IHdyb3RlOg0KPj4gSGkgSnVsaWVuLA0KPj4NCj4+IFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcg YW5kIHN1Z2dlc3Rpb25zLg0KPj4NCj4+IE9uIDAyLjA5LjI1IDE5OjU1LCBKdWxpZW4gR3JhbGwg d3JvdGU6DQo+Pj4gSGkgTGVvbmlkLA0KPj4+DQo+Pj4gT24gMjkvMDgvMjAyNSAxNzowNiwgTGVv bmlkIEtvbWFyaWFuc2t5aSB3cm90ZToNCj4+Pj4gQEAgLTc4Miw0NiArODA0LDgxIEBAIHN0YXRp YyBpbnQNCj4+Pj4gX192Z2ljX3YzX2Rpc3RyX2NvbW1vbl9tbWlvX3dyaXRlKGNvbnN0IGNoYXIg Km5hbWUsIHN0cnVjdCB2Y3B1ICp2LA0KPj4+PiDCoMKgwqDCoMKgwqAgew0KPj4+PiDCoMKgwqDC oMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUk9VUFIsIEdJQ0RfSUdST1VQUk4pOg0KPj4+PiDC oMKgwqDCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUlBNT0RSLCBHSUNEX0lHUlBNT0RSTik6 DQo+Pj4+ICvCoMKgwqAgY2FzZSBWUkFOR0UzMihHSUNEX0lHUk9VUFJuRSwgR0lDRF9JR1JPVVBS bkVOKToNCj4+Pj4gK8KgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSUdSUE1PRFJuRSwgR0lDRF9J R1JQTU9EUm5FTik6DQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgIC8qIFdlIGRvIG5vdCBpbXBs ZW1lbnQgc2VjdXJpdHkgZXh0ZW5zaW9ucyBmb3IgZ3Vlc3RzLCB3cml0ZQ0KPj4+PiBpZ25vcmUg Ki8NCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgZ290byB3cml0ZV9pZ25vcmVfMzI7DQo+Pj4+ IMKgwqDCoMKgwqDCoCBjYXNlIFZSQU5HRTMyKEdJQ0RfSVNFTkFCTEVSLCBHSUNEX0lTRU5BQkxF Uk4pOg0KPj4+PiArwqDCoMKgIGNhc2UgVlJBTkdFMzIoR0lDRF9JU0VOQUJMRVJuRSwgR0lDRF9J U0VOQUJMRVJuRU4pOg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIGRhYnQuc2l6ZSAh PSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCj4+Pj4gLcKgwqDCoMKgwqDCoMKgIHJhbmsg PSB2Z2ljX3Jhbmtfb2Zmc2V0KHYsIDEsIHJlZyAtIEdJQ0RfSVNFTkFCTEVSLCANCj4+Pj4gREFC VF9XT1JEKTsNCj4+Pj4gK8KgwqDCoMKgwqDCoMKgIGlmICggcmVnID49IEdJQ0RfSVNFTkFCTEVS bkUgKQ0KPj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19leHRfcmFua19v ZmZzZXQodiwgMSwgcmVnIC0gR0lDRF9JU0VOQUJMRVJuRSwNCj4+Pj4gK8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBEQUJUX1dPUkQpOw0KPj4+PiArwqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4+PiArwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCByYW5rID0gdmdpY19yYW5rX29mZnNldCh2LCAxLCByZWcgLSBH SUNEX0lTRU5BQkxFUiwNCj4+Pj4gREFCVF9XT1JEKTsNCj4+Pg0KPj4+IFdoaWxlIEkgdW5kZXJz dGFuZCB0aGUgZGVzaXJlIHRvIHRyeSB0byBhdm9pZCBjb2RlIGR1cGxpY2F0aW9uLiBJIGZlZWwN Cj4+PiB0aGlzIGlzIG1ha2luZyB0aGUgY29kZSBhIGxvdCBtb3JlIGNvbXBsaWNhdGluZyBhbmQg aW4gZmFjdCByaXNraWVyDQo+Pj4gYmVjYXVzZS4uLg0KPj4+DQo+Pj4+IMKgwqDCoMKgwqDCoMKg wqDCoMKgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3cml0ZV9pZ25vcmU7DQo+Pj4+IMKgwqDC oMKgwqDCoMKgwqDCoMKgIHZnaWNfbG9ja19yYW5rKHYsIHJhbmssIGZsYWdzKTsNCj4+Pj4gwqDC oMKgwqDCoMKgwqDCoMKgwqAgdHIgPSByYW5rLT5pZW5hYmxlOw0KPj4+PiDCoMKgwqDCoMKgwqDC oMKgwqDCoCB2cmVnX3JlZzMyX3NldGJpdHMoJnJhbmstPmllbmFibGUsIHIsIGluZm8pOw0KPj4+ PiAtwqDCoMKgwqDCoMKgwqAgdmdpY19lbmFibGVfaXJxcyh2LCAocmFuay0+aWVuYWJsZSkgJiAo fnRyKSwgcmFuay0+aW5kZXgpOw0KPj4+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCByZWcgPj0gR0lD RF9JU0VOQUJMRVJuRSApDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfZW5hYmxl X2lycXModiwgKHJhbmstPmllbmFibGUpICYgKH50ciksDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBFWFRfUkFOS19JRFgyTlVN KHJhbmstPmluZGV4KSk7DQo+Pj4+ICvCoMKgwqDCoMKgwqDCoCBlbHNlDQo+Pj4+ICvCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHZnaWNfZW5hYmxlX2lycXModiwgKHJhbmstPmllbmFibGUpICYgKH50 ciksIHJhbmstPmluZGV4KTsNCj4+Pg0KPj4+IC4uLiB5b3Ugbm93IGhhdmUgdG8ga2VlcCBib3Ro ICJpZiIgdGhlIHNhbWUuIFVubGVzcyB3ZSBjYW4gaGF2ZSBhDQo+Pj4gdmVyc2lvbiB0byBhdm9p ZCAiaWZzIiBldmVyeXdoZXJlIChtYXliZSB1c2luZyBtYWNyb3MpLCBJIHdvdWxkIHJhdGhlcg0K Pj4+IGNyZWF0ZSBhIHNlcGFyYXRlIGZ1bmNpdG9uIHRvIGhhbmRsZSBlU1BJcy4NCj4+Pg0KPj4+ IENoZWVycywNCj4+Pg0KPj4NCj4+IFRoZSBtYWluIGlkZWEgb2YgVjUgb2YgdGhpcyBwYXRjaCBp cyB0byBjb25zb2xpZGF0ZSBzaW1pbGFyIGNvZGUgYW5kDQo+PiBrZWVwIHRoZSBwYWlycyBvZiBy ZWd1bGFyIFNQSXMgYW5kIHRoZWlyIGVTUEkgY291bnRlcnBhcnRzIGluIHRoZSBzYW1lDQo+PiBw bGFjZSB0byBzaW1wbGlmeSBhbnkgZnV0dXJlIG1vZGlmaWNhdGlvbnMgb2YgdGhlc2UgcGFpcnMu IElmDQo+PiBlU1BJLXNwZWNpZmljIHJlZ2lzdGVycyBhcmUgbW92ZWQgdG8gYSBzZXBhcmF0ZSBm dW5jdGlvbiwgaXQgd291bGQNCj4+IHJlc3VsdCBpbiBjb2RlIGR1cGxpY2F0aW9uLiBBZGRpdGlv bmFsbHksIEkgdGhpbmsgaXQgd291bGQgYmUgZWFzaWVyIHRvDQo+PiBtaXNzIHVwZGF0aW5nIHRo ZSBjb2RlIGZvciBvbmUgcmVnaXN0ZXIgb2YgdGhlIFNQSS9lU1BJIHBhaXIgd2hpbGUNCj4+IG1v ZGlmeWluZyB0aGUgY29kZSBmb3IgdGhlIG90aGVyLi4NCj4gDQo+IEkgdW5kZXJzdGFuZCB5b3Vy IHJlYXNvbmluZywgYnV0IGluIHRoaXMgY2FzZSwgd2UgbmVlZCB0byB0cnkgdG8ga2VlcCANCj4g dGhlIGNvZGUgYXMgY29tbW9uIGFzIHBvc3NpYmxlIGFuZCByZWR1Y2UgdGhlIG51bWJlciBvZiBp ZnMuIExvb2tpbmcgYXQgDQo+IHRoZSBwYXRjaCBhZ2Fpbiwgd2Ugc2VlbSB0byBvZnRlbiB1c2Ug IkVYVF9SQU5LX0lEWDJOVU0ocmFuay0+aW5kZXgpIg0KPiBhbmQgdGhpcyBpcyB3aHkgd2UgaGF2 ZSB0aGUgc2Vjb25kICJpZiIsIGZvciBpbnN0YW5jZSBoZXJlLiBJIHRoaW5rIGl0IA0KPiB3b3Vs ZCBiZSBwcmVmZXJhYmxlIGlmICJpbmRleCIgc3RvcmUgdGhlIHByb3BlciB2YWx1ZS4NCj4NCg0K QWN0dWFsbHksIHRoZXJlIGFyZSA0IHNwZWNpZmljIGNhc2VzIHdoZXJlIEkgbmVlZCB0byB1c2Ug RVhUX1JBTktfSURYMk5VTToNCnZnaWNfZW5hYmxlX2lycXMsIHZnaWNfZGlzYWJsZV9pcnFzLCB2 Z2ljX3NldF9pcnFzX3BlbmRpbmcsIGFuZCANCnZnaWNfY2hlY2tfaW5mbGlnaHRfaXJxc19wZW5k aW5nLiBUaGUgcmVhc29uIEkgbWFkZSB0aGlzIHRyYW5zZm9ybWF0aW9uIA0KaXMgdGhhdCB0aGVz ZSBmdW5jdGlvbnMgYXJlIGdlbmVyaWMgYW5kIGNhbGN1bGF0ZSB0aGUgdmlycSBiYXNlZCBvbiB0 aGUgDQpyYW5rIG51bWJlciwgZS5nLiB2Z2ljX2NoZWNrX2luZmxpZ2h0X2lycXNfcGVuZGluZygp Og0KDQp1bnNpZ25lZCBpbnQgaXJxID0gaSArIDMyICogcmFuazsNCg0KQXMgYSByZXN1bHQsIEkg ZGVjaWRlZCB0byBpbnRyb2R1Y2UgRVhUX1JBTktfSURYMk5VTSB3aXRoIGlmcyByYXRoZXIgDQp0 aGFuIG1vZGlmeWluZyB2ZXJ5IGdlbmVyaWMgY29kZSB0aGF0IHdvdWxkIGFsc28gYWZmZWN0IHZH SUN2MiBhbmQgYmUgDQptb3JlIGRpZmZpY3VsdCB0byB1cHN0cmVhbS4uDQoNCj4gQW4gYWx0ZXJu YXRpdmUgd291bGQgYmUgdG8gcHJvY2VzcyB0aGUgM3JkIHBhcmFtZXRlcnMgc2VwYXJhdGVseS4N Cj4gDQo+IFRoZSBuZXh0IGJpZyBvbmUgdG8gdGFrbGUgaXM6DQo+IA0KPiBpZiAoIHJlZyA+PSAu Li4gKQ0KPiAgwqDCoCB2Z2ljX2V4dF9yYW5rXy4uLiguLi4pDQo+IGVsc2UNCj4gIMKgwqAgdmdp Y19yYW5rKC4uLikNCj4gDQo+IElkZWFsbHkgSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgYW4gaGVs cGVyIHRoYXQgY2FuIGZpZ3VyZSBvdXQgd2hldGhlciANCj4gdGhpcyBpcyBhbiBlU1BJIG9yIG5v dC4gTG9va2luZyBhdCB0aGUgcGF0dGVybiwgSSB0aGluayB3ZSB3b3VsZCANCj4gaW50cm9kdWNl IGEgbmV3IGhlbHBlciB3aGljaCByYXRoZXIgdGhhbiB0YWtpbmcgYSByZWxhdGl2ZSBvZmZzZXQg dGFrZSANCj4gdGhlIHJlZyBvZmZzZXQsIHRoZSBiYXNlIGZvciBTUElzIGFuZCB0aGUgYmFzZSBm b3IgZVNQSXMuDQo+IA0KPiBDaGVlcnMsDQo+IA0KDQpIbSwgdGhhdCdzIGEgZ29vZCBpZGVhLiBJ IHdpbGwgdHJ5IHRvIGltcGxlbWVudCB0aGlzLiBJIGFncmVlIHRoYXQgaXQgDQp3aWxsIHJlZHVj ZSB0aGUgYm9pbGVycGxhdGUgY29kZS4NCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo= From xen-devel-bounces@lists.xenproject.org Tue Sep 02 20:58:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 20:58:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107544.1457937 (Exim 4.92) (envelope-from ) id 1utY4m-00054V-BD; Tue, 02 Sep 2025 20:58:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107544.1457937; Tue, 02 Sep 2025 20: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 1utY4m-00054O-7i; Tue, 02 Sep 2025 20:58:00 +0000 Received: by outflank-mailman (input) for mailman id 1107544; Tue, 02 Sep 2025 20:57: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 1utY4k-00054I-Il for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 20:57:58 +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 7c022e34-883f-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 22:57: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 BC86940761; Tue, 2 Sep 2025 20:57:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E897CC4CEED; Tue, 2 Sep 2025 20:57: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: 7c022e34-883f-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756846668; bh=aHW+swPHNscAMC3hJlwenPCQ7EMvQvlQTYIIah4L/Rs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IGQlEZcPdyGEYroU/EHdWHfO3SAaVgPwQLfamPa9iJ+taaRRNPo4w2jnwD/nMTrhD F363js9FyDkd3CVVe0DNGkpd3dt03sNJshR53Nm8ab3JNuJ8HRRINgHlRKehgHZNuU UlGnt2FyqEX5lHYiVS28CbGpFXJL+hunQUXdmPBK5TAJqi64qRVZnBaDppAEXsaJID j6BkoC+IChdfHPDcR8crl0f0SLEHBu0I8lRclp2wwviRFBUecLlgnu0AEVWACWcbz0 G9yBaAt328Mj+htUgA48CnI2BOKNJrPDfXkfMuL0Kp/rbLr4ZTMfrxMuuOTqkLDLwq 4XcLhbtWvcuSQ== Date: Tue, 2 Sep 2025 13:57:45 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Moisieiev 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?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v7 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support 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 I was going to commit this series but this patch breaks compilation on x86: https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11223159836 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 21:59:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 21:59:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107567.1457947 (Exim 4.92) (envelope-from ) id 1utZ2X-0004yD-Oy; Tue, 02 Sep 2025 21:59:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107567.1457947; Tue, 02 Sep 2025 21:59: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 1utZ2X-0004y6-LX; Tue, 02 Sep 2025 21:59:45 +0000 Received: by outflank-mailman (input) for mailman id 1107567; Tue, 02 Sep 2025 21:59: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 1utZ2X-0004y0-8W for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 21:59:45 +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 21192ced-8848-11f0-8adc-4578a1afcccb; Tue, 02 Sep 2025 23:59: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 55E3F405D0; Tue, 2 Sep 2025 21:59:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A15CEC4CEED; Tue, 2 Sep 2025 21:59: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: 21192ced-8848-11f0-8adc-4578a1afcccb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756850381; bh=zUOixGI5e23gDVx/zmq/5QWAYGpvZZ1gzj0irhRA2AU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t/Eu3RveeWFJ7QPQZS0HMJnJ18RJisbVk4Pk4B2mkUogsXCsDnOh5nmkT6QJ4KkpV WAD5v3cszsJls2vJneW0RL/RKpho+ZzAZhFpATDVsn7wwLvJDFu6zSx6RUEKSctSsY MYZrvd5dFbrPEZmkILy8ZxDbNlA6Ej38GRHuRquE0I86IxDtV1kdU0Sm1EDnwtGqEF c1keYzFalxZPfGjORlUbEIAtFrtMdhOixv+lPDaKzXO5a+aOyNEdMKgtKZcG+wqmef IRgJjgP6zlr77O2RCDhrfy6xxK73ZGX0o3JyM4rB09vZuyTewz4+/r6JUDL31Kg2Mp O1zPH9rjxq5Aw== Date: Tue, 2 Sep 2025 15:59:37 -0600 From: Keith Busch To: Marek Szyprowski Cc: Leon Romanovsky , Leon Romanovsky , Jason Gunthorpe , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 14/16] block-dma: migrate to dma_map_phys instead of map_page Message-ID: References: <22b824931bc8ba090979ab902e4c1c2ec8327b65.1755624249.git.leon@kernel.org> <2d8e67b2-4ab2-4c1f-9ef3-470810f99d07@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d8e67b2-4ab2-4c1f-9ef3-470810f99d07@samsung.com> On Tue, Sep 02, 2025 at 10:49:48PM +0200, Marek Szyprowski wrote: > On 19.08.2025 19:36, Leon Romanovsky wrote: > > @@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) > > static bool blk_dma_map_direct(struct request *req, struct device *dma_dev, > > struct blk_dma_iter *iter, struct phys_vec *vec) > > { > > - iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr), > > - offset_in_page(vec->paddr), vec->len, rq_dma_dir(req)); > > + iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len, > > + rq_dma_dir(req), 0); > > if (dma_mapping_error(dma_dev, iter->addr)) { > > iter->status = BLK_STS_RESOURCE; > > return false; > > I wonder where is the corresponding dma_unmap_page() call and its change > to dma_unmap_phys()... You can't do that in the generic layer, so it's up to the caller. The dma addrs that blk_dma_iter yield are used in a caller specific structure. For example, for NVMe, it goes into an NVMe PRP. The generic layer doesn't know what that is, so the driver has to provide the unmapping. From xen-devel-bounces@lists.xenproject.org Tue Sep 02 22:16:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 22:16:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107584.1457957 (Exim 4.92) (envelope-from ) id 1utZIk-0007vP-33; Tue, 02 Sep 2025 22:16:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107584.1457957; Tue, 02 Sep 2025 22: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 1utZIk-0007vI-09; Tue, 02 Sep 2025 22:16:30 +0000 Received: by outflank-mailman (input) for mailman id 1107584; Tue, 02 Sep 2025 22:16:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utZIi-0007vC-Ld for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 22:16:28 +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 77231883-884a-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 00:16:27 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id BB38943690; Tue, 2 Sep 2025 22:16:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C33BC4CEED; Tue, 2 Sep 2025 22:16: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: 77231883-884a-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756851384; bh=rTTa0P43RBx62hRKI6ThhogWr2yjUp043GcKRQp5yCs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=d3On7y8soCGF0cjuogyTcW89kVvCWlsihCjUWq42bnAKeO0iMQxqz0Y3V/pri+XRn E47bTQwrJNXTJAXZWsI0rkOXuQxG3MFoBUypY6EiYISVLSDqTkNFIh2VM1iFbvsbmC JS88orw3w+TrK+ExPDFZOEK3TxZ0qNnPDjLuhuNhytRK0VJR5ZjpTO+RYgPC7bxxnY hr93wOEeIIJrloytj7wdzOX13p157Gm1XTRhqW6BwCUchHn52YqSwRgup1tlEvAu2J AIai8anBPPBaLoVaXjbnow0ZHjnTVmeBVy5yjM6KmoQQcuimS3/pr2v0WAiL4sjjqj tJ9rSC1hwr+/Q== Date: Tue, 2 Sep 2025 15:16:21 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: oleksii.kurochko@gmail.com cc: Stefano Stabellini , Oleksii Kurochko , ray.huang@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , xen-devel@lists.xenproject.org, Penny Zheng , jbeulich@suse.com Subject: Domctl series as a fix to PV_SHIM_EXCLUSIVE, was: [PATCH] xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE In-Reply-To: Message-ID: References: <20250815102728.1340505-1-Penny.Zheng@amd.com> <2035b14e-3836-4e80-9dad-8a49ca90864a@suse.com> <49416df6-83c8-4fa3-bf81-2d1e504ef31b@suse.com> <5f5ba1dd-1252-4740-8c64-e4fcd8a7ac32@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi Oleksii, We previously discussed the PV_SHIM_EXCLUSIVE build issue on Matrix and agreed on resolving it after the feature freeze as a fix. This conversation took place before the feature freeze was rescheduled to September 5. I am documenting this on xen-devel both for record-keeping and because Matrix is currently offline. I am proceeding under the assumption that the conclusions from that discussion still apply. I would like to request an additional clarification. While there is no consensus among the maintainers on the preferred short-term compromise, there is agreement that reviewing and committing the domctl series [1] in time would be the best outcome. (Together with unifying CONFIG_SYSCTL and CONFIG_DOMCTL into a single CONFIG_MGMT_HYPERCALLS for simplicify.) Are you still OK with us going ahead with reviewing and committing the domctl series as a fix to the PV_SHIM_EXCLUSIVE issue, potentially going past the feature freeze by a week? Many thanks! Cheers, Stefano [1] https://marc.info/?l=xen-devel&m=175421442423500 From xen-devel-bounces@lists.xenproject.org Tue Sep 02 22:22:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 22:22:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107594.1457967 (Exim 4.92) (envelope-from ) id 1utZO1-00012I-MY; Tue, 02 Sep 2025 22:21:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107594.1457967; Tue, 02 Sep 2025 22:21:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utZO1-00012B-Is; Tue, 02 Sep 2025 22:21:57 +0000 Received: by outflank-mailman (input) for mailman id 1107594; Tue, 02 Sep 2025 22:21: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 1utZO0-000125-JW for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 22:21:56 +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 3a7b7e66-884b-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 00:21:54 +0200 (CEST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-55f7a34fb35so2248660e87.1 for ; Tue, 02 Sep 2025 15:21: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: 3a7b7e66-884b-11f0-9809-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756851713; x=1757456513; 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=FQypM20kVsD54oX5v8mDhtQA8PZenADmQOEGUfI9XJY=; b=IqobnaYNpfA0ylhHhWP3+Tj9vc8YC02EqHfmEcKdoq4W+ID4cUzw/fgPhoZs69zQdb tZSbDiYvWkLI4OCx56uZjp7rtEmkIjTR2le8nXLvrsg9OsR4B+EdMSC68wFg2CaxqZgY AOOMv8fQmzgcuxoqCbg+lsH/Pb6O1+zKzBb3Lv+T9+qxDGnvzI6cCmIVKVFvQ8gTbsez l//05KnFf6SsmpgAGetRwel2Owljj2peivjwluG4VmX8E0Pmez9fOprPJHnIpc1a6Nnu VJdJMq/65NaxoY6vwcpWr/fo5uYBPSVgJ/JCBiJ7CxUjRYJmESlVDR4Bo+TYfsULQpBL 0B9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756851713; x=1757456513; 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=FQypM20kVsD54oX5v8mDhtQA8PZenADmQOEGUfI9XJY=; b=gixGuas7NNWktFd6mZExtbegUNK3WGBZQ/hLqqeb0HXtfU8fklKa5mjMnoueqqxwiF BoiKpQRopOoMdi4KtxMX0BfpQWwDMZQIdTc9yx6EgG8c2kXSBOH/tO1o1sRE0iQdz5rN rT4q0c04htn+ZNl/+KABdk6zQeIclTsqOFN/8odfkVDHX3bU8VdcREjCdS1zZWYQ78QY S70T8KPkEvuYuLKfiwKELEtmfhILjNT0nzzDKIprCMq5nrTccWXGs4rXuuAYz7iPOdw7 swW4gFmymT6l1bLQPy9QnL8+4orakQqoP5OGKVA4cFKqxo8ykO1twRfnxgykOEscS75E pfWw== X-Gm-Message-State: AOJu0Yzh6/Euj7zd5092EpxKprPVthTDJt9QGNl5LiYY1n5wbiYq8IEL OYYwNF0hyOWygJMKDYuT+1QHbuqd4fSZk94Y8dhQuPlWVa5JywR/MiwQbuK/Bf/Z4Evsyoa9lv3 yFemaPKEUYmkzBHUCwtrULcGXVrGsrYw= X-Gm-Gg: ASbGncsUlrJUh3tfyjZNkSaPkuelY+P31XTpwls6hhOOPnAOFRU2JK/2V9gRsaxjNf/ 71SCodComjE55eoPwWAVspAUJSX2NAd21r7SndYi3YWuBP7jOAi3BI+H3uJ3AW+9cwv1bdHGPpl TewXUvWxvRNoloQVcMwZeZ1A1hy79jjfsMz4TnSLYqYZPoQdGOeiflqHTF62AUrDxq/0kKZivtK PdBJYg0gwwxFXBa X-Google-Smtp-Source: AGHT+IFGxJuRvg1FGeBW+e9xp2Y9kYy5F5Z9M1amwEp2ec0axbGRItnmvplg7sQ4Hk02Zn6vn5/Wjm+GmEVIqLG3d1o= X-Received: by 2002:a05:6512:32cb:b0:55f:4fac:3f0c with SMTP id 2adb3069b0e04-55f708db36cmr3713181e87.30.1756851712506; Tue, 02 Sep 2025 15:21:52 -0700 (PDT) MIME-Version: 1.0 References: <18c51957660441c945d51b02be965fbcc19c7c2b.1756763487.git.mykola_kvach@epam.com> <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> In-Reply-To: <0fb4d962-a92a-4b8b-805d-60a03fe1b734@gmail.com> From: Mykola Kvach Date: Wed, 3 Sep 2025 01:21:41 +0300 X-Gm-Features: Ac12FXwHNeXtdZtMB8tYdSk0_2dyXMbhvFVUdfekan3M5pmBuC0R90gdygSz5uI Message-ID: Subject: Re: [PATCH v6 06/13] xen/arm: irq: Restore state of local IRQs during system resume To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 7:49=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > On 02.09.25 01:10, Mykola Kvach wrote: > > Hello Mykola > > > 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 > > --- > > Changes in V6: > > - Call handler->disable() instead of just setting the _IRQ_DISABLED fla= g > > - Move the system state check outside of restore_local_irqs_on_resume() > > --- > > xen/arch/arm/irq.c | 39 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > > index 6c899347ca..ddd2940554 100644 > > --- a/xen/arch/arm/irq.c > > +++ b/xen/arch/arm/irq.c > > @@ -116,6 +116,41 @@ 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; > > NIT: Please, use "unsigned int" if irq cannot be negative > > > + > > + spin_lock(&local_irqs_type_lock); > > + > > + for ( irq =3D 0; irq < NR_LOCAL_IRQS; irq++ ) > > + { > > + struct irq_desc *desc =3D irq_to_desc(irq); > > + > > + spin_lock(&desc->lock); > > + > > + if ( test_bit(_IRQ_DISABLED, &desc->status) ) > > + { > > + spin_unlock(&desc->lock); > > + continue; > > + } > > + > > + /* Disable the IRQ to avoid assertions in the following calls = */ > > + desc->handler->disable(desc); > > + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); > > Shouldn't we use GIC_PRI_IPI for SGIs? I'll update the priority value in the next version. Initially, I assumed gic_route_irq_to_xen() was used for all interrupts with the same priority. But looking more closely, it doesn't appear to be called for SGIs at all. In fact, SGI configuration, including priority, is handled during CPU initialization in gic_init_secondary_cpu(), which is called before the CPU_STARTING notifier. Given that, it's probably better to avoid updating SGI priorities here entirely and rely on their boot-time configuration instead. > > > > + desc->handler->startup(desc); > > + > > + spin_unlock(&desc->lock); > > + } > > + > > + spin_unlock(&local_irqs_type_lock); > > +} > > + > > static int cpu_callback(struct notifier_block *nfb, unsigned long act= ion, > > void *hcpu) > > { > > @@ -134,6 +169,10 @@ 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: > > + if ( system_state =3D=3D SYS_STATE_resume ) > > + restore_local_irqs_on_resume(); > > + break; > > May I please ask, why all this new code (i.e. > restore_local_irqs_on_resume()) is not covered by #ifdef > CONFIG_SYSTEM_SUSPEND? > > > } > > > > return notifier_from_errno(rc); > From xen-devel-bounces@lists.xenproject.org Tue Sep 02 23:25:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Sep 2025 23:25:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107640.1457977 (Exim 4.92) (envelope-from ) id 1utaN9-0000OY-Tq; Tue, 02 Sep 2025 23:25:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107640.1457977; Tue, 02 Sep 2025 23:25: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 1utaN9-0000OR-QE; Tue, 02 Sep 2025 23:25:07 +0000 Received: by outflank-mailman (input) for mailman id 1107640; Tue, 02 Sep 2025 23:25:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utaN7-0000OL-MD for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 23:25:05 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2061a.outbound.protection.outlook.com [2a01:111:f403:2009::61a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0c3c61af-8854-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 01:25:02 +0200 (CEST) Received: from CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) by CH1PR12MB9574.namprd12.prod.outlook.com (2603:10b6:610:2ae::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Tue, 2 Sep 2025 23:24:58 +0000 Received: from CH3PR12MB8659.namprd12.prod.outlook.com ([fe80::6eb6:7d37:7b4b:1732]) by CH3PR12MB8659.namprd12.prod.outlook.com ([fe80::6eb6:7d37:7b4b:1732%4]) with mapi id 15.20.9073.026; Tue, 2 Sep 2025 23:24:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0c3c61af-8854-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EPPUGTpBQtvDStMLISia+THnTG3E+xG7M30x/PlBo2tAa/Nr/FmSG//W8J1ytvmYfhHAim/W9vQgGujfcSuDILGI3MLD6pI6zS/OBY6OjTRcOngtk4jHhyGUh7jyRRB7szMQuPkC0FVnIUpnLJxS17iQdNA6AwS8d3tSA1dKuSftvGm2YCpQt3teeyNM/4nDnpsnuHxKCtSsm4ZxJ7lDZKrevojcXGC2x64W2xWlegQeMIK2rdxpSOR3mUEg+68waaoLnziZs6CRUl9OORYmCDYjZdsiUhla3kDKGqETPLX9l+jUVxkpUfFVQZaaMQUTmy9sd4idVJ3XjDo1oc5Fqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5WhB/bSCKzhLBnuuHt7TF4nSB4uzH/8ebtNNvqKnLZo=; b=Bp8uobg7Bc/BzSSDdn/btXqGPCvh/sMoJV2WrMiwae2gLXXMNa74iBFMOK8/Kd3nIe9DK65EPLAHjJyQmW8DOXDs0DsFGRmQLve8gYV8a6tY17tfpTo8zCgFv5+3GgNHnagEytgV8j4HLlBahFH4W76yI1oHiycXqbmiQtuJxjyhuu6icEqsWPa7LoOyNl2pEd2PzvwHOQbnGhYo3Fzzd9EA/sudkNK/l5w4yDPSkDAmsiZvXW6QfcWhCsAF2m1x/v5zC7XkqaqZe82trwitDyL1DcbG/w15m/gyz76Y438tMp0oBXpcw+HMFmc6FRhQx7LSn25C6eW1Cargibj6zQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5WhB/bSCKzhLBnuuHt7TF4nSB4uzH/8ebtNNvqKnLZo=; b=FrwZLjypAbDrjjqAKk256crdzVZq5Sew5KLCSVqXFIm6JyrV7WWqseMrpiu6vHBAy6Xlq7hJUsVrsT/FkYId14wsn536VKml4D6dVf0nX1pDWvZdYx95NPTtj+TUehlsqj5w0TNjWea9EzqyGH1Szex82Slu5m16O469Jqf4vo8LVpYziiKli7KTd/FS6+moUTxeys5qqRTu4BHPio4D6BiG9luxRnn5KUs1cBGj9i9sQBFRtT+dthQPMa8u8xyA4r41LbqjNUFXR0e1kW0r+ZfYYrCZlj/fR+WLDmZd8zFTpgKVynLwnmDbpnxukVNhCQvtdttg4v7iM17l9idL/Q== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Date: Tue, 2 Sep 2025 20:24:57 -0300 From: Jason Gunthorpe To: Keith Busch Cc: Marek Szyprowski , Leon Romanovsky , Leon Romanovsky , Abdiel Janulgue , Alexander Potapenko , Alex Gaynor , Andrew Morton , Christoph Hellwig , Danilo Krummrich , iommu@lists.linux.dev, Jason Wang , Jens Axboe , Joerg Roedel , Jonathan Corbet , Juergen Gross , kasan-dev@googlegroups.com, linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , "Michael S. Tsirkin" , Miguel Ojeda , Robin Murphy , rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano Stabellini , Steven Rostedt , virtualization@lists.linux.dev, Will Deacon , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 14/16] block-dma: migrate to dma_map_phys instead of map_page Message-ID: <20250902232457.GC470103@nvidia.com> References: <22b824931bc8ba090979ab902e4c1c2ec8327b65.1755624249.git.leon@kernel.org> <2d8e67b2-4ab2-4c1f-9ef3-470810f99d07@samsung.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: YT4PR01CA0469.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:d6::7) To CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR12MB8659:EE_|CH1PR12MB9574:EE_ X-MS-Office365-Filtering-Correlation-Id: 63dbd94d-8dd9-4729-0d10-08ddea77eed5 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: =?us-ascii?Q?Higtp3/WM5oOHXkSSI5Z6pkQhOJorSSmJ1rnzoaJINMSn5inopVW+5S1K/Ek?= =?us-ascii?Q?7UrVD4MqKyLijH5h/vlsnHGvvpnFBsM7bvA+EFOiGdGldsWfaZYD8zUnE+Ia?= =?us-ascii?Q?ecNJ/0eJumt+b4s+tCBkkWx3wAlbR3L7ZwRembGJ0qEAW5a8nMcl2O4pKBo3?= =?us-ascii?Q?PdQLHRgzmpB+Zi9Fyvs7ObYDwqrX3SvjiyXTY7dfz6xgl2cNvZLi0VYii1/b?= =?us-ascii?Q?MkmMnZxsMlCME5PY63Vbs+iSk/IsvqtWZHysYL4ru2GKkqHySeU/UxTsKS9H?= =?us-ascii?Q?NCQuJHY9AoYkjqmoR9wiyV8tPiNXWxpRtpTZLV+P9wxTPx+sIP6lmWoS5/S8?= =?us-ascii?Q?tScHp8k0n3YfKg3GgKbdM3XqOzkoumuJYdU2wWmSvEiefzhn121027ScVc0M?= =?us-ascii?Q?mgzvNL4BID9woA1Jopw2qWMOUr6I42j9dddH10a2Hv1fG7SqI425nv/pOe0t?= =?us-ascii?Q?XJLZrlOU3bEWKkS5qf5qLZ4koodOuW/or2bHHG01Kw+qVJViR5uQMQErX1Rn?= =?us-ascii?Q?dtqR9Vv9ju+N686ia1iq1DS9dkK7YGKHd5W0b0ulhNTSQMFxZH3cWGGjfWTk?= =?us-ascii?Q?pjUR3HiLnhZ/Gd+XDqBYF4iqr14XCZkC491u0cxXUHDii+HrI0WlyWJ2BKs0?= =?us-ascii?Q?dBy7a/RbGYkwaioywaADLcf4CQNWk5/2GrFCGWhBSwYB4ZjprP1MGHvYdI3R?= =?us-ascii?Q?DMzz2x8pNRL7Mivdz1EtHsC/rhFLc7JonZiWPL/pvdgvSnbboCWHS7c6QOpl?= =?us-ascii?Q?0swby8pOQj4N0n49XZtvW/idwcbe4eNzXJ0jm7wrkcFtMMUxVvl8m7yvIDtZ?= =?us-ascii?Q?lkBLoshQkBjqhFQ/rMBX0tNenSjQGAw3q6U+TAYT6ONJyKzPzXMD6ONMEEr2?= =?us-ascii?Q?lM7nczTb/5U62gC4bHgrqTQZG0/IV/K146tgoh4kVZhRNS4+1TDwn85Ef00w?= =?us-ascii?Q?b25m6ZgpKhrAxPuKScb48bdqsiYSeRjlub9AcOjtrsTjupvo5g4b1uCSu360?= =?us-ascii?Q?ihn81VgyyrErWwvwyxXUY+zUoPHstPTvUXgO4hhJQGEphLgRHf5IZJ8FNF9E?= =?us-ascii?Q?y8aOe+19T3uf4BgYrljrHnyl7H7Ivmy/M3TWnpkf0Ne3P/rxpcFURQqPyxrA?= =?us-ascii?Q?nmax8Lk0p77thdRstB+Hc504ESJo3wkqm2nGrwePMZqg9Ex+ZwuwPzIh+yFc?= =?us-ascii?Q?NW4E84kHyQmH9bigD2OQ2nj80E+nsEUiEfPtQu9DDNkHPhsc3DWmsQp5F5ID?= =?us-ascii?Q?v2iXvkdUv4q4fUxzbDu8lvbKB34fT2OkWHmduiMObfU44H+8USLbzFbYGHvp?= =?us-ascii?Q?W+zopG0awjW8HwejpiP/r5KxoNSrY51NLps/3h1ryMebgbOTFkdvuQ/1Jubh?= =?us-ascii?Q?wHoM62r1+0y7npOtu7w7ng34SwuefUBlBMTA1ghgxypuzWM4sbecLls4XAyK?= =?us-ascii?Q?d1RHM5UhoGk=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8659.namprd12.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: =?us-ascii?Q?p5eHAhSaNlykrbWpG/UPoqPb+iB4di9SrzYYl3qOPeAc97/mV6PDVi69YGjb?= =?us-ascii?Q?/G5ZcFGR6SHgsNA89667543XYP54vL2aGbWD7mO+dDPSxdYPwrSwbR4OZKGj?= =?us-ascii?Q?0uZ/4QYa3QBppOpU7LU6Ruc7Eb3ZaXR3MCTcpATP7+YKn3PKMq/qRJBInuh0?= =?us-ascii?Q?mndkVYAZ72At+hxcF5ZZ1QA16/AxGYtIV/Rwnv1vRZM5FjoG/84e4j5oYx0S?= =?us-ascii?Q?ocyFVke+zLfEuBT2oM5/3BmRbPrJY0izl9cUqeCfBv+jquc7o7TVk014BH20?= =?us-ascii?Q?TrICRhQ3NARiEsVmZK87iG72oNredufI/8XNg3bhNZYwsHRYRQcEPg6aDbLL?= =?us-ascii?Q?mT/NPGXf52sa56OYUv6OkB7bxN24Uich0CeXNjMtCeNXO2pASJCwHnwEB1gZ?= =?us-ascii?Q?PV0X5lZBA2ewO+tX4LQUKqqT3mB8MTEJYbqCa94pF3vxk5cbJMuob9np/A/L?= =?us-ascii?Q?o6CfmeH6x+Z7S8Pfqgb/Q12IwsSGyQFRPyo7W8hR2V/qW5e7ER223wB7eCyx?= =?us-ascii?Q?ZIg3y+y0vcamWCdg2D0pXVK9J4+85ZPfxV7N1YX2oez3G9epg/ohsdHic9fu?= =?us-ascii?Q?JxCIJgemIxztEXy4YoOTaMsgz4GYwTVodoS1cZ0NYpMROKPBCTm7xT4XBjq6?= =?us-ascii?Q?2+DE2mLQ/UCL5jhiTp6poXSCR0qBOgWzUJKyaLwjQ1GZAyzxbNrcljo82ame?= =?us-ascii?Q?TKeXuuv6aBzpD/6RZMBMAZzh2sr9hg0LORN8vJe5fFvmR5JRmNzsO7Q9ris6?= =?us-ascii?Q?HfrkG070I/eqfwuSBDJ4nzLvACcAJoQhez6FytC0UcpRlbOPD+r1rMwKdl+w?= =?us-ascii?Q?8lx/vYLaNoXVZSsWZEpftqg+gPlzE2ccC3sAfFDqYq3osSe3yhfuGgjIngrI?= =?us-ascii?Q?N763ZBm1UZHKcOoUIJkq1IlWBPaat+KVqpOv53f9E59PqJtGu2/h6H95WyRJ?= =?us-ascii?Q?bW7CcTqQM9bEWsW9kzofp/5dvkCxlaWHY3Nh4Nxjy0jS2fGPWAPM3qZAc0jS?= =?us-ascii?Q?V9kmZydsir6/Cx30g7K33l3dwibq6q46+W03IF+gjL9XnaWlmCieooWek8lW?= =?us-ascii?Q?h/uGyVI8CqH12zNfrFojddv8yK/hTDrQN9jYSkA1ahEv6ZL1DLwqBlMya4Ap?= =?us-ascii?Q?/r5/qlXRyAHu5A0QAwyPDGs5ml3qsMX2ajkBGSk9X0ntPihhkWkUqk8sd2hO?= =?us-ascii?Q?rlkadpZpHqJepYOKHZrUdi3WSU0xKSSJeQ+u71wDEK9qghkKVjSYjER13IuG?= =?us-ascii?Q?i4NUzxZ2pIKqaql+Ty58blZQRf1++v8itAdRiREY4lAVu2ikKLoPkfJFvxNJ?= =?us-ascii?Q?Q1hdIWrcRdvBX+JaZtvjSYcRpyrhBZdKBE0l39mN8fcvqiw5hQ3glHMoqD8j?= =?us-ascii?Q?ccHD1YCwdTzvyjY8bMoZJ/h7M+UAHuTS16dOswEl+UJKX5koND+Ql9PGkxhP?= =?us-ascii?Q?9fgidwA9mzNyZdN9S2gZjRAls3FnVg2GPr6TkGVDXf8WJ8ZImtMPr+uZU7Kx?= =?us-ascii?Q?C3uqBfEEQfmHvbJAVwFTC6HZU+GYssMua51pl763bOE6Zw39qHuaSaSowPOq?= =?us-ascii?Q?x1wOdD6P+giXyxbN/Ko=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63dbd94d-8dd9-4729-0d10-08ddea77eed5 X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8659.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2025 23:24:58.6964 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zp9UTtFHtRHHEdUZ3DhGe9qQeSrMw2x+t/nR0QIEskMOvB26XU5zEDnMfQkF+y5a X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9574 On Tue, Sep 02, 2025 at 03:59:37PM -0600, Keith Busch wrote: > On Tue, Sep 02, 2025 at 10:49:48PM +0200, Marek Szyprowski wrote: > > On 19.08.2025 19:36, Leon Romanovsky wrote: > > > @@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) > > > static bool blk_dma_map_direct(struct request *req, struct device *dma_dev, > > > struct blk_dma_iter *iter, struct phys_vec *vec) > > > { > > > - iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr), > > > - offset_in_page(vec->paddr), vec->len, rq_dma_dir(req)); > > > + iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len, > > > + rq_dma_dir(req), 0); > > > if (dma_mapping_error(dma_dev, iter->addr)) { > > > iter->status = BLK_STS_RESOURCE; > > > return false; > > > > I wonder where is the corresponding dma_unmap_page() call and its change > > to dma_unmap_phys()... > > You can't do that in the generic layer, so it's up to the caller. The > dma addrs that blk_dma_iter yield are used in a caller specific > structure. For example, for NVMe, it goes into an NVMe PRP. The generic > layer doesn't know what that is, so the driver has to provide the > unmapping. To be specific I think it is this hunk in another patch that matches the above: @@ -682,11 +682,15 @@ static void nvme_free_prps(struct request *req) { struct nvme_iod *iod = blk_mq_rq_to_pdu(req); struct nvme_queue *nvmeq = req->mq_hctx->driver_data; + unsigned int attrs = 0; unsigned int i; + if (req->cmd_flags & REQ_MMIO) + attrs = DMA_ATTR_MMIO; + for (i = 0; i < iod->nr_dma_vecs; i++) - dma_unmap_page(nvmeq->dev->dev, iod->dma_vecs[i].addr, - iod->dma_vecs[i].len, rq_dma_dir(req)); + dma_unmap_phys(nvmeq->dev->dev, iod->dma_vecs[i].addr, + iod->dma_vecs[i].len, rq_dma_dir(req), attrs); And it is functionally fine to split the series like this because unmap_page is a nop around unmap_phys: void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { if (unlikely(attrs & DMA_ATTR_MMIO)) return; dma_unmap_phys(dev, addr, size, dir, attrs); } EXPORT_SYMBOL(dma_unmap_page_attrs); Jason From xen-devel-bounces@lists.xenproject.org Wed Sep 03 01:50:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 01:50:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107693.1457987 (Exim 4.92) (envelope-from ) id 1utcdj-0000Y3-LT; Wed, 03 Sep 2025 01:50:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107693.1457987; Wed, 03 Sep 2025 01:50: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 1utcdj-0000Xw-IC; Wed, 03 Sep 2025 01:50:23 +0000 Received: by outflank-mailman (input) for mailman id 1107693; Wed, 03 Sep 2025 01:50:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utcdi-0000Xq-0v for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 01:50:22 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20624.outbound.protection.outlook.com [2a01:111:f403:2414::624]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 584a930c-8868-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 03:50:19 +0200 (CEST) Received: from BY5PR17CA0038.namprd17.prod.outlook.com (2603:10b6:a03:167::15) by CH3PR12MB9220.namprd12.prod.outlook.com (2603:10b6:610:198::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 01:50:14 +0000 Received: from SJ1PEPF00002318.namprd03.prod.outlook.com (2603:10b6:a03:167:cafe::67) by BY5PR17CA0038.outlook.office365.com (2603:10b6:a03:167::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.25 via Frontend Transport; Wed, 3 Sep 2025 01:50:14 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF00002318.mail.protection.outlook.com (10.167.242.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.9094.14 via Frontend Transport; Wed, 3 Sep 2025 01:50:13 +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, 2 Sep 2025 20:50:12 -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, 2 Sep 2025 20:50:12 -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; Tue, 2 Sep 2025 20:50: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: 584a930c-8868-11f0-9d12-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gefUB+dyUt7T333RZVqrL3kGtc8QSLqXyEBT7WrOECZJ8yyhe8gLmeN7MdHX/VoaBXHRj3mZ/2wz0aR7iqqBYMCToKqFdzSijHenczN0NluCbnjx5jz9onpZG1C437CkcloQrVn9IZBnJSfLE6R3Gce8mrOvPPmvujlo54VIHPZbHyM9RwqmHfeVUBBY6UslrMYPuP1vX4Ft4gO9711o6rpuJUsZoC2HfOQT0scdcSqjU4KhP51GBF4oJFT7RuPivhIeI7ytADG6AerM0JGhB33vTq5gBSxO4hNRxKeTYcPzWD9+SglwbdJjGg0s4mMGGr351MRj3vLeYiJ/Pk7Lvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rz2eaBwwwCZp211l/RyjUbSt3GFwVa8Bm/HnKDz3ZXc=; b=tixjQu9yyqVhFQpOQM5QuMyjnIjMc9o0B6w9JwnEooVco5UkOSHZVwFCbreyENTC+qFcBNDfVXrsOCp2FvXSNnyA/vZVjJUyNv9BoSRTILkriZu7IFLfw6n9i0dSW5rlSpBlsYZAyivcn4ZoskzR2rqlNPGYeU4MBrf0xdlnVZIU8v+IFTs0zCXNQ+8n9vaKdl2LYOL0n2jCZ6UpLDkwciBMj//LymCJ+0MDQxB9wRonk+JJ3scS+oTrhBR5vztvLsjyeeduKQslPwy/0f0PRCosN6rKnl+K2yKsWYBfVztOZFqiyE7GKRoOppRLo5iqIxllS3mK2Y/Fa4rYRtE/8Q== 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=rz2eaBwwwCZp211l/RyjUbSt3GFwVa8Bm/HnKDz3ZXc=; b=f0BMjefRvX3cLCY8+XfLfyZhXXc6xu/LdCamqHmU2H77wX4V8uV4/aqgg4jpDT10a5M77+M1hPKu1+exEuOj7Zsn6OQrtoAUs4Fp4AUBRV4dsuUpjULyn4x6zNjnGVvO1bbfvqQOWZ9DTCJTbNLRSRFlTbfhEcQBTJdQH2BT7FI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Nicola Vetrini , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [PATCH v1] automation: edit pipeline to prevent running non-selected jobs Date: Tue, 2 Sep 2025 18:49:44 -0700 Message-ID: <1437334569e10b76d1d7dc4e9fca7c25606855fb.1756862843.git.victorm.lira@amd.com> X-Mailer: git-send-email 2.50.GIT 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: SJ1PEPF00002318:EE_|CH3PR12MB9220:EE_ X-MS-Office365-Filtering-Correlation-Id: afc7bb58-6eb9-4c72-2cbd-08ddea8c397c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aFZsbFVzWW1TZVlvUCtvZ29hNm1vVUNnVkZMdThkdzZqUlVwUkVWZGs1bGVp?= =?utf-8?B?UW82M3VpcC9LV3FGaU5DSFlUVDM5SndkVHFkYWQ4UnNzQ0M4Wm9MUWZVS3p1?= =?utf-8?B?UGdZQ2JtOXYwSVV2Y3FGMGYxWkt1YnUyWVBnMGpPUVBucmtrdGY1bzcvbTN6?= =?utf-8?B?a3RJS3gyMXk1ZCtHeURDaVRtdENmK2NzUkpKSDA2cTFTMmYvR3h6djJDQndy?= =?utf-8?B?T1h5S0hQTkVTQWVVSSs0TFZSUUVzUXcwOUdicTFkWXVCYnhMYTdYb1NQTDQz?= =?utf-8?B?aVpyLzF1aFhycE92b3dmbjBvSng4VGZ2bjF6N3NleEZ2b1NHampTL1ZTYjdp?= =?utf-8?B?VGtaSWIwZzl4TGVXTkV3bDFFYjlJdnI5cGxFVkdIM1JNcG1kYmFWUkhtaGtO?= =?utf-8?B?cnJjNklESG9EYldQOGp2bEJxbFpFYkpocG5hY2pBQS9NUFRCZm1YNVNTTzNv?= =?utf-8?B?cm5QbUNPMmNldmltSitzV0VtSVF6N0xHRk5FRHVzNW9ONFRNeU1xRnp1dTZu?= =?utf-8?B?QjNPVE5rRXVJZkZCR3FKUWViMUxwVkd4Z0ZZeE12WDNxY3JkUlIwZDdML0tt?= =?utf-8?B?UWVYZGVJUGZsd1RXUzZ5R2h1T1RhTjdwUDJxSXJvSVFSYlJ0ZnQ0K0ZhTFQw?= =?utf-8?B?UGpSQlo5T1V0WmRrclZUMDROY0V5aThhaGIyN2VRMmhrdHptMVU0a3ovN2E5?= =?utf-8?B?U2NXSEsxT2kwRXVzVzZpSTE4OFhHTzEvN3RpY2lucndlR0FMMUhYYjhkendU?= =?utf-8?B?QjBIK1UwdzJHQ1FQQWV5U3A5OGlyRlJ2R3g3dzhUbnFIYmdpTEdtWGN3WVdF?= =?utf-8?B?TElJS3VJUksyakxyRHRxNW43Y0h0bmo4bEduUURQcmI1c0FIOEJ0L203MWtD?= =?utf-8?B?QngrZG9lNE1ESkNmT1M3ZzJoc2pKMTR3eU9VbDlMMFdPazllTk5LNXNDTmkz?= =?utf-8?B?SDlYNEJ5cnd3LzJjL3I0aHEyVUdqZ0lZbFdZSmZSSW1nSU4vK0RhQmczYVVx?= =?utf-8?B?ZENZOGdNUTFBYkh2QzFUdWNiTUl3bkFwK3hxZkNqM0llQ2o3TFdoRGxGNFNV?= =?utf-8?B?WVpOU1pzcm1ycUJMVlRncnIyU0FxTU9YOFB3cFB6akFWS0tYN2xjejJrTW1S?= =?utf-8?B?Q1VQZ0VYcXUzRGdpTjdGK2NSOEpIM0FWTWI0djZaeEwxck1SUFpVZlc3a1g5?= =?utf-8?B?RmtVWUFmOVhuZG1mb3JiQU1yNm9ZU2lrKzRvNE15NkhtWXQvdUZNOEJzV25w?= =?utf-8?B?eUN4ZkEzVmZPWm52UDFMWVhhZ1RyeTdWSjVEbmV5RDZrSjZQTHNwYXdXbStq?= =?utf-8?B?d2xGcTJHLy9wYlJSNWVHUUxOdkVFM2dqTTQ4Y3pubzFLblZMZTZUdzI5ek1E?= =?utf-8?B?TlJwTzcxMmlaanlZMXlLbEo0b0ROQkpraUJOSVFLc1dKeTF4U3lCWTJTN2Yz?= =?utf-8?B?ZnNGd0xLeGd2MUZsTXFRNCtsY3JicTJKZk14ZjR5RG81NGJ1Mk9sOXJJdXBP?= =?utf-8?B?OWEvQ1JQQmN6ay9TUy9KYTZDQVl4eGg3RlNNQjlMR0hRZlJyTHZqelJEY3Ew?= =?utf-8?B?MjVteCtST3laZXcraEpNdnA2UEMwMHhkMmg0RWdoUWxQWEpvY2NGMWd3RFhO?= =?utf-8?B?cGxWa3RiYUtHWVpCOWJxMjZpdURiWHI0NmNhOUFTVk9FcUhyd0RBT05OeWw3?= =?utf-8?B?Q3pyOGxwaitmbVUzNlU5TGIxcTF6TE9vclRNeW9iVkhBNW5QOURsdi93OEFt?= =?utf-8?B?cDVIaXlPa2d2dUZ0aThjWU44M0xNeHVKU1Y3cnprODkxN2lZczNmL3dqSXJC?= =?utf-8?B?aUNwdXhqUDBYaU9jNnpNbnZEa3h5UllzT3hYLzdKTlhxRklPbDdoZ1A2aUlC?= =?utf-8?B?ckxkY0RtMm9XdUE5VnVBZ2M1UmVmbnhDd1dMOUpOekprWHJOUmlJRnZwanBx?= =?utf-8?B?cmpRYTBlbmEyMWVHUHd4WUJJeVJ6ajVOQVp6dGZGdnZuWk83Z1ZMd0ppcW9l?= =?utf-8?B?V0RuT2Y3Wk9BPT0=?= 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)(13003099007)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2025 01:50:13.6400 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: afc7bb58-6eb9-4c72-2cbd-08ddea8c397c X-MS-Exchange-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: SJ1PEPF00002318.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9220 From: Victor Lira Filtering jobs using the selected jobs regex is missing for qemu-export/yocto- jobs when running regular pipelines and eclair jobs when running scheduled pipelines. Add the missing rules to filter out those jobs, and set a default value for the selected jobs regex to remove the need to always check if the variable is empty. Signed-off-by: Victor Lira --- example of the problem: - https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/2018353899 - SELECTED_JOBS_ONLY=/alpine-3.18-gcc$/ should produce 1 job only note: - I tested only on sstabellini but the logic should work for hardware/staging too --- Cc: Marek Marczykowski-Górecki Cc: Nicola Vetrini Cc: Anthony PERARD Cc: Doug Goldstein Cc: Stefano Stabellini Cc: xen-devel@lists.xenproject.org --- .gitlab-ci.yml | 1 + automation/gitlab-ci/analyze.yaml | 5 +++-- automation/gitlab-ci/build.yaml | 9 ++++++--- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 7974ac4e82..64bed300a6 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -2,6 +2,7 @@ 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/" + value: "/.*/" workflow: name: "$CI_PIPELINE_SCHEDULE_DESCRIPTION" diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml index d507210067..1f58e13cb2 100644 --- a/automation/gitlab-ci/analyze.yaml +++ b/automation/gitlab-ci/analyze.yaml @@ -31,8 +31,7 @@ rules: - if: $CI_PIPELINE_SOURCE == "schedule" when: never - - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY - - if: $SELECTED_JOBS_ONLY + - if: $CI_JOB_NAME !~ $SELECTED_JOBS_ONLY when: never - if: $WTOKEN && $CI_PROJECT_PATH =~ /^xen-project\/people\/.*$/ when: manual @@ -126,6 +125,8 @@ eclair-ARM64: rules: - if: $CI_PIPELINE_SOURCE != "schedule" when: never + - if: $CI_JOB_NAME !~ $SELECTED_JOBS_ONLY + when: never - !reference [.eclair-analysis, rules] eclair-x86_64:on-schedule: diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index ab5211f77e..b2f96c1fe0 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -226,6 +226,9 @@ - binaries/ when: always needs: [] + rules: + - if: $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY + when: manual .yocto-test-arm64: extends: .yocto-test @@ -261,6 +264,9 @@ .test-jobs-artifact-common: stage: build needs: [] + rules: + - if: $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY + when: on_success # Arm test artifacts @@ -468,20 +474,17 @@ yocto-qemuarm64: extends: .yocto-test-arm64 variables: YOCTO_BOARD: qemuarm64 - when: manual yocto-qemuarm: extends: .yocto-test-arm64 variables: YOCTO_BOARD: qemuarm YOCTO_OUTPUT: --copy-output - when: manual yocto-qemux86-64: extends: .yocto-test-x86-64 variables: YOCTO_BOARD: qemux86-64 - when: manual # Cppcheck analysis jobs -- 2.50.GIT From xen-devel-bounces@lists.xenproject.org Wed Sep 03 02:55:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 02:55:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107723.1457996 (Exim 4.92) (envelope-from ) id 1utdea-0008Gc-6J; Wed, 03 Sep 2025 02:55:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107723.1457996; Wed, 03 Sep 2025 02:55: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 1utdea-0008GV-3m; Wed, 03 Sep 2025 02:55:20 +0000 Received: by outflank-mailman (input) for mailman id 1107723; Wed, 03 Sep 2025 02:55: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 1utdeY-0008GO-K7 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 02:55:18 +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 6c087ea0-8871-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 04:55:17 +0200 (CEST) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5607c2f1598so2418112e87.3 for ; Tue, 02 Sep 2025 19:55:17 -0700 (PDT) Received: from alina-IdeaPad-Gaming-3-15ARH05.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5608ad4cd5dsm198602e87.145.2025.09.02.19.55.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 19:55: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: 6c087ea0-8871-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756868117; x=1757472917; 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=48Bo/x1uHirQgD6UhpfUYjtWJgtRNUdUXngg1z/5/NE=; b=g16NiQbxyUQI/xZTrEbqHbm7dZaiN7SMge8anRGgESj53Y+lvo93FyOY1q9dUTo+cF EgDFM4pXBAqwYzTZAyArlBw01IJy3v6vqiGefglCWXlRBV/5DMSBgcMPl9KqojzQlYOz +z0ULzCkHiv0Hka6rKl6hHEwM+zeqzAt6He1paxQXlzwNCFdSxBPVvT20MyFmtWDK4gV kOftEMQvowLwRyumLBzwX8li/T+8mdrK7vdSfw8XxH6Cpt6274qUKQqa0E3l5LEYnDAP AqD9cD4WkU+djy355ljEF+2pBd8n72gg2sM0/oMYBgj/+Z5gths46ZlOhPNN5G8+BqvD b69Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756868117; x=1757472917; 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=48Bo/x1uHirQgD6UhpfUYjtWJgtRNUdUXngg1z/5/NE=; b=wrae93cVkHcR+mdtgSyxN4cvdBk+m0kX5sLKlUEIWHfQhE9/WiJkSwK3TJ2UQfjAwk Rlzlo2Jf2FX7Sv0hSbVgtq+nVxZ8NlRYFeL6Ma1fJBraiEQQfW/jFR0W29vElcL/C8pZ UWRMKBq6e3EwvnpE2qG4GIWFV9/ezDhpLfax+2kiRx2SGGxJve3+jv09ON3EJq/xpRfM VmZOrY/x4Eu7jx3hEdA/DCoBoyQ8OtQb1koJdY6uy0RcvUz2gJ6feA5MWGxkDGKB4Zsz +5rstoeHHIXxbKHezSUWef/TVxinLaJWGoLXrPcrhAQ4u5gF0FWWGVWozqXGRE1WSXuq iiCg== X-Gm-Message-State: AOJu0YxID3F9sZGgwK3UuaHdJwymDN/wjQDH52XhNatEVerSzedbz/IJ 7e2ou1PVYFjmMaQBhbPt8T9hIoPzpW2OWPe/uR0RkvFCKAe6ivb/rRWaOCXoSu68 X-Gm-Gg: ASbGncv0Mwf32vdtffXx+cVbUlBhS9kxIUsKWp7azw9WylhjJbxVdF/PCCSVnfztOKk EvGvW8cWOaMVkfPHkksljYEmOUvOvvPQ30M7uNBbCgIh5U+OnSLjsmTQSfFx+JqbL9kZMZCM+qC ecxLjtG2xb6XCDMBX21s4KKMzAOikmZlB6+4YBzUtplWO6Al8ebJz5pQ6zg/WXpvdDE/PjUYn9V L7MORPn7MfiSXAc8PLFlM8N18n9Rh8xcB0Aq3YM4m3d+D9SoNav8kf8o5qTnZ2f6EoK6d3XO3W4 o9Mf2Dn/D+mi77EJSoTeSkp8SfSuV9xWkyWPD4DjqtP0V3n/fFGAm6xAM87tOicYxiFv7XrerAk kWecPy9X0cxWNLwbzV+ldK+jxVV+nrAV7UaV0UzZ1tyRR82O60bu0T2hpNIPXWw== X-Google-Smtp-Source: AGHT+IEHTE5ME7OvU7zU/shNh04Cn5W+Xaptf8HRwQT38ptQ6z9RqgHPWvTPteFJyjCMF7DW0BDLIw== X-Received: by 2002:a05:6512:639a:20b0:560:8b56:5dc6 with SMTP id 2adb3069b0e04-5608b565f03mr140729e87.19.1756868116396; Tue, 02 Sep 2025 19:55:16 -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] xen/arm: irq: Use appropriate priority for SGIs in setup_irq() Date: Wed, 3 Sep 2025 05:55:13 +0300 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach Use GIC_PRI_IPI priority for SGI interrupts instead of the generic GIC_PRI_IRQ priority in setup_irq(). This change ensures that SGIs get the correct priority level when being set up for Xen's use, maintaining proper interrupt precedence in the system. The priority assignment now follows ARM GIC best practices: - SGIs (0-15): GIC_PRI_IPI (higher priority) - PPIs/SPIs (16+): GIC_PRI_IRQ (standard priority) Signed-off-by: Mykola Kvach --- xen/arch/arm/irq.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 02ca82c089..17c7ac92b5 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -397,7 +397,13 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new) /* First time the IRQ is setup */ if ( disabled ) { - gic_route_irq_to_xen(desc, GIC_PRI_IRQ); + unsigned int prio = GIC_PRI_IRQ; + + /* Use appropriate priority based on interrupt type */ + if (desc->irq < NR_GIC_SGI) + prio = GIC_PRI_IPI; + + gic_route_irq_to_xen(desc, prio); /* It's fine to use smp_processor_id() because: * For SGI and PPI: irq_desc is banked * For SPI: we don't care for now which CPU will receive the -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 03:14:45 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 03:14:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107734.1458008 (Exim 4.92) (envelope-from ) id 1utdxH-0002ap-O6; Wed, 03 Sep 2025 03:14:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107734.1458008; Wed, 03 Sep 2025 03:14: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 1utdxH-0002ai-K9; Wed, 03 Sep 2025 03:14:39 +0000 Received: by outflank-mailman (input) for mailman id 1107734; Wed, 03 Sep 2025 03:14: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 1utdxG-0002ac-8d for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 03:14:38 +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 1cf8b2fc-8874-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 05:14:35 +0200 (CEST) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by DM4PR12MB6232.namprd12.prod.outlook.com (2603:10b6:8:a5::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 03:14:29 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d%7]) with mapi id 15.20.9052.019; Wed, 3 Sep 2025 03: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: 1cf8b2fc-8874-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WxAwGY0JVmx1t9w6esGLnhpOJlKt/CE4IY60921/uYCzxfOzB7EJ58f3kRzMVjYn5TSkWYd2bmHSKpcmTS5pDiOG5s+XWosn+MUTvQk/gmTcABuvLovwMK07AKHk1Y7hb109/w3Szxv5iVYsKDmW4iqYs/bWK1oMdpSFNrRgO6fcx2UxbubaI2M3YKWxsxTcHfUs093TmZCioUrb9YEaALw+IXBBbgzSU33xU2Gtf98lid/iLjvpgDktH5zgQfGEDmnc4JJcl2Kxs5Ml3T/b9aAxFJst8u7NPVpDWl3hyPFCNnzu8zWoqxv1SY5DyI2/tMewPyRBM8UihmXK/kIJrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BAK7DeDIBY+h+qJnlFV1ONcfRP4n13DLZB6paRwZT9k=; b=X1DoNasP6LqHOYnlGRKx6EquvB3vHAd0bbCbG2H8Dxd1A41pendeFXLLCWraYZt4BX/3Tq1BFLh5CF6Lw8ynpvzat1Ul0E7rVSPhThEG7R0FdQgmTs45zP/BAwErcPVMWZjJSO1Iba12ryz6MqoyZh39IJDwhoEEm+gQNRESSP6mWczS7IXI3uCVzFhROvg/c/GFwrCq+QFKzD+ohkmnTqpwpNXxpZuXbKdpKK/6jR/L4OS5trFmbEUCgj9RNBOUmi6mpRmWzQdARFuYvMmCWFCAzH8XkqizSX/TI2q1nRg36jsuWcjjXxFqDtJFnpsxfU5r+KkNX4kexVLZaTpOGQ== 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=BAK7DeDIBY+h+qJnlFV1ONcfRP4n13DLZB6paRwZT9k=; b=aYq7jVYjOc4W0I8M5jeWVV0gxD9ZoI+VRJXQf1IyETbS9L5jn1r981x9Zn4XRdWHYKLhTLUR09buL1D4DwAGk5ZJeqv4/ExXFiWiYU9e7PXifXS6d9SQZ9Y0h2WwJaXXjkbZ6teMTisgMEZa7dINnJonKh+pHv9byxp1i1DDLfg= From: "Penny, Zheng" To: Jan Beulich CC: "Huang, Ray" , Anthony PERARD , Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver Thread-Topic: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver Thread-Index: AQHcGANplGdEMGicVkezx0Fs9samVLR357kAgAjockA= Date: Wed, 3 Sep 2025 03:14:28 +0000 Message-ID: References: <20250828100601.1777197-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-09-03T03:14:22.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_|DM4PR12MB6232:EE_ x-ms-office365-filtering-correlation-id: 9a585bfa-c7d2-4035-70cd-08ddea97fea8 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?dHV0NEVOc3pCdTQyTFh4b011L0RCSG9PeDI1dFFDRmpYaFcrTE1ra0ZJcXdQ?= =?utf-8?B?aExxMVc0bnM5aGlmaDV5aTNENlBjNmlhOHBaZ01TcXF5VXJSbHlCOW9jeWpa?= =?utf-8?B?VzZhdnpuT2xhMms5OCtKMjB5RTEwQ0NzcmNXREdsbkhDclFLcjFkbHdNRk81?= =?utf-8?B?ZVhmdzdRb0MramRkd0JZYURPSDBoVDYwRXNSelBUTDB2R0NHNVNiZENUVCti?= =?utf-8?B?UEg2NUNldzRibXpia1dsNThtOFlTY1MwM1hQei92dTl3cnBsN0JBQzdidVAx?= =?utf-8?B?aUF0bW5lVnN3VjVIa3JDaklZdUJYK0tqOHBGeUhDR1ZmcGFybUVQS1VsVG1Q?= =?utf-8?B?TDJnVXZzVzZsZGE3azdiR1Q4UUh4MUxkWlBGNElBRnB1bUhWNE5OL2orOTJk?= =?utf-8?B?WE9Xa2dDa05aTFR2VzZ1OFU4UVFtZ2xqYXQzSGdubGZyYTE1TFR3N01mZUx0?= =?utf-8?B?R1M1bFE3NlN4NStPNURyOTlYOVlZM05rbzRRWnBKWHNmNjlvOXVkamJWc0pm?= =?utf-8?B?L3FWeE9rdDJ2T0V4SWNRbDd1RmZFTVFZQzMxNWtFeDR2TjhjdHJsMDBnTmxK?= =?utf-8?B?ZkRHOEVkUUFiTE9LSlZneHVVSEgwS0VlQks0TFRyLzFvbjBrWkw0R1laaDBl?= =?utf-8?B?YVV1WmVvK1V0a3lWdkp6azg3OVlkUTU2VktxMWtJWW1neTRTMEJxbStjTUhP?= =?utf-8?B?Sk1sSjZXb0oxNVo3UnBtWi9BVHFVd2dkbDRNMWFXTEhxcFZxbk9DSmRYSVEy?= =?utf-8?B?Z0JBOEZlY1dIR0FpTXlmWUN3QWRjNzhqOHNycWtPZ0I1WnI0RXBiSGRyMlNq?= =?utf-8?B?eTA3R0diVHJuVXJEN1gyM1Bsem15d1RJVFhMTzVoQjdzU0lPTEdmWXM3RndW?= =?utf-8?B?bG4waGRESmJWVFlqaXAzb1FNcW82bWxwaG1EN2pWcHZycHFxTTlETkNvUEx6?= =?utf-8?B?SUhzMnlGZU1RVTF2VjNjcCtialM1c0xvcDFiSWs4WWpITGZxVFBIbEJwb0Zz?= =?utf-8?B?eTBkTUQ4cm54NHVMMy9WeTJSM29wbUNQVmhIbldGaDVSWis5VnNMeXVDVHkv?= =?utf-8?B?VW05OUdsK2hHbEFxQ1RmNUZDN0ZWcjcrOVhWb1hIY2hnSUhKNWlkVlc5aU1h?= =?utf-8?B?NC83YXJzM0liT0IwQXA3VUt4cWxCbHhZQTBpYkFtNmg5SWJabE8ybjFFOTEx?= =?utf-8?B?SU1FYmk5MVNlNk9OQkRNeWxCU0M1LzhUc1lKZ3VlYmdxSVNQM2g1alMraEVz?= =?utf-8?B?VG52MkZySDVkSFh4OHBLbkd3c1VJR1d0dS9QMWh4czNzZnVCb0JMYmI3OHQr?= =?utf-8?B?R1lhSEkwT1lUQWZkaHVPNWlGTCthNURLQm9PMjRoa1NmUEIxcDA1QVlzWWNn?= =?utf-8?B?L29ZWXhvSnF1SG1jWnhnY1Z0YzVtWlVScldoQXpCb1FGZUhYdlR2aVduVWNJ?= =?utf-8?B?ZkJPRjV4ZUZnMEtrVC8yNUdUckM5aGJWQjVqMTgwYS9qOE5ZYkhreTVvWWty?= =?utf-8?B?aGcrbHdNcTB2alpQN2xUS2VHeVBSR1lMYUhFUkdBYTI5dytFbUt3OE9nb0s5?= =?utf-8?B?NzBVaWN6bDBQdjJiWjE1bTN4SEt2V2NvYzU2eXdMWFptNUVZMWpJUnhwRjVj?= =?utf-8?B?S1lia2hBUnFxQ1ZZMEhaeml1MmJBUVpiTE5jOW5YSzVEQml6dy9IdlhEVkFZ?= =?utf-8?B?WWQ3NWw3TEg2TnZvcXp3VXdYSUpWZGx5c3RmSXB0eW1ZZ25iRk5USms3dDJ5?= =?utf-8?B?Y3d0OFZmSHoxNzVNQ0xYeVBSNmhCR3RlTnUvSHIzaVE1a1ZHY08zWVN1RjhJ?= =?utf-8?B?MmtDTFRjVy9oMjhDVzVSNEIyNCt3aTg0RytoY2IvQjVOMkdRVTZqM2pJNXZn?= =?utf-8?B?OWRqYTlyQ2oycDQ3a0NUS0Y5QXp6blhIY1kvY29UajZ5em00eFFuTElPNVJu?= =?utf-8?B?Lysxa21UUVhMSXNhN2xXV203NmhuV3ZVZDFjR25HU3o1QmViTmxFbGlSQmFM?= =?utf-8?B?T3pZSmsvdHN3PT0=?= 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?MHRCRFlWMHdFbFh6Y3BSdElKbzlYczdGRmpNcTRSWE9iUjNuNUpaR3ZybjFM?= =?utf-8?B?d0VtcHJqb0pHdFg5NEFxOXFMQUJDVGpGUnkza0lUNzRFWlhjTk11a1JjTURG?= =?utf-8?B?aG9vMTB0YmhyTVFBU05BRHRaZVVrOWJYeDk2K1crLzFmQVd5cnBScU9UTGZl?= =?utf-8?B?aExXUFRBUlpWdHpGN1pSdk1ZR01ueTFxb2xOZzhrWk9MRlpncXh3NmVLMWhZ?= =?utf-8?B?VmpkRUdnd2VzZUtMckZCd0tUMXhyNGZJSDFtTjV2bUhkajRoQU0vc1Q4d3FD?= =?utf-8?B?UGR4cG14MEg0T2ZXcUFnb1dLNmVPTU5ETEk5dUE0NEF3bnNXYjhxODlpSnJI?= =?utf-8?B?ZDRwSkF4d2h0Q1BIKyt2empndDRROHBMWXIzZllsSVZsb3ZwcGtmRldwTUNT?= =?utf-8?B?TXYvblo2M0Y4bHQ0MDhlbGdtTksrbks3ekFVbXZCczlpbndDc3k2SWdCcXNk?= =?utf-8?B?UWtHV1QwN1VGV3dRQWxQSnVtVjRwdnRHcVd3TTFMY012czRXVm1QN2hUSWND?= =?utf-8?B?WDcxUVB3bjlxNHlNVjU1ODFTRkhuVFFzTm0rb2pOVklCSUdGSVR6MEREeXNL?= =?utf-8?B?eEwvWUZjSGhidEJTcTkyNGFWc2ZwWDFodUw3bHpOczJTNDhRL2d2TFZtR1Ev?= =?utf-8?B?NGhzVG1xanErZ0Z1aFFQLythOFpHNE9aWEZndG8yYVQzYUVXczJRQVh2dnJt?= =?utf-8?B?NXJEc3VJOHMvNFhrTmF6Tks4ZStFdEVVM2hyZCtJNlJiL0t5SGRIbjNZckZS?= =?utf-8?B?Zm9xN1NZNGd6OHc0bWVVWEdDQW5RdmVsNjMxMmpjdDA3MllrV0dlMENSa2Zp?= =?utf-8?B?ckFiQ0M3VWo5dGRJYTNDQXdlNEJ6Q1FEUHhIdnI4d2dKM3dVRG13TFVsVmtN?= =?utf-8?B?allSeXBleUhqelhRQVpMV0k3SUFMeE9WUm9pVkp4Mk1Xelg3MHRIeXFLWGV1?= =?utf-8?B?Vzljd2w1MW8yd2d3dW5vcllkR0xvd05xNUdXWjc1cHdsUlFIQWNMK01PSnhI?= =?utf-8?B?Q2JnWXNGL2thNWZpTFpxQjhVckZ6ZGV6R0JpUERyZHZVemtCY0ZwdzlEZ00y?= =?utf-8?B?bmE0UFgyd1hSTXZuMFNGRHBPUW9tRDVzemxxcmozU2RDQmcyd2VpYWNQTVNF?= =?utf-8?B?T1h1SFBtZ2c3QkptdkxFdFMrb1YrWUNaQ2lrKzVVUlBxeUlGMEx5R3RsVDM4?= =?utf-8?B?bFRVc1FLM0RPU1o1NmlxNEErRERCWGs3dm9sQkt5ZGYvNFVhL0VTbHRHYnlW?= =?utf-8?B?K3U1WGN3TkdLRWFwd2hxUkdjM05tWUVYa0poenFDTmxsN3NnRmhJQTlpWm5m?= =?utf-8?B?Q0tnV1Ntd05jVVl4M0RjNXBJL25mR2pTeEJKZWI4SEpwQ1RsY2R5QVZGbUw2?= =?utf-8?B?blg4VzcwRncvY2grN3lzV3F3WWN3aTgvc3M1T2NkdmYyckN1S2daLzBzeUh0?= =?utf-8?B?Z1hwMXlrTEpCYU95c0hnc0ZaeDl1QWFkb25lTnlCdEZrRGlDR21sc0lzbnJV?= =?utf-8?B?M0licSszQUMvaGFoRms4WDcrVlUyc3R1d29vcUFyakFuK2FiVGVXK1lhR2ZY?= =?utf-8?B?NDJSV0E4NDlscC82cHJzWnhHWmY3a3VBUGhEU3l0ZnNxb0xOVkhDK0ZlWTll?= =?utf-8?B?YndjRW9xQVFKS0hRUkZveTBjcUNYdUdLNG1OdWUzRklXcG01OTBuNHF5YWd4?= =?utf-8?B?OHJGNGRwVUFqUlVXVXV5d21RMXAwMk5PdXdBMTlsYWVUQzBSTkN4NW03Q1ZS?= =?utf-8?B?c1pOWm1vY3NmMmsvblFVTGFWUm9INy9PYTAwZXdrNGQwczFlQk40RmYrZVFD?= =?utf-8?B?aGxpWEoyQWZjM2Q5S0hFQmxuN3ZNN2kzK3JBem5GN1czZU5BQ0JkYmpvSGp1?= =?utf-8?B?b0JFb2p6T2VUcUxhTUFHd3hrWnpOTmZJK05pWDQxRjRkNEFNdlkvMDdOZHRN?= =?utf-8?B?U0lGeThDdkprWjRRYXdzdHNpekpyWEowSktZbmh1Tm5xRlIrcGhnSE9QM0JN?= =?utf-8?B?NW1SaGQ0WlZPcFAzS1o0R25mNGNPb0N3eHZ0MlJ5dTVDYUlabDhrQkRWaWU4?= =?utf-8?B?WHJaWFM0RHNkVmpxK1ExTFErY0sxMnZTbVBXa0ZrdUlBYmdBdEg1VVRqZVlv?= =?utf-8?Q?yoX0=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: 9a585bfa-c7d2-4035-70cd-08ddea97fea8 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 03:14:28.9819 (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: xVS6a0FxeWkvJ2/CWs+W8Dd+UhVAYjZz0yT5TFfJZ6sOFCGWA7wb7Y9Etm5qg58mm1TObIQWH10i6rDcQLwI8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6232 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjgsIDIw MjUgNzowNyBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD YzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbnRob255IFBFUkFSRA0KPiA8YW50 aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+Ow0KPiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IHhl bi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY4IDgv OF0geGVuL2NwdWZyZXE6IEFkYXB0IFNFVC9HRVRfQ1BVRlJFUV9DUFBDDQo+IHhlbl9zeXNjdGxf cG1fb3AgZm9yIGFtZC1jcHBjIGRyaXZlcg0KPg0KPiBPbiAyOC4wOC4yMDI1IDEyOjA2LCBQZW5u eSBaaGVuZyB3cm90ZToNCj4gPiBAQCAtMTU0LDYgKzE1NiwxNyBAQCBzdGF0aWMgaW50IGdldF9j cHVmcmVxX3BhcmEoc3RydWN0IHhlbl9zeXNjdGxfcG1fb3ANCj4gKm9wKQ0KPiA+ICAgICAgZWxz ZQ0KPiA+ICAgICAgICAgIHN0cmxjcHkob3AtPnUuZ2V0X3BhcmEuc2NhbGluZ19kcml2ZXIsICJV bmtub3duIiwNCj4gPiBDUFVGUkVRX05BTUVfTEVOKTsNCj4gPg0KPiA+ICsgICAgLyoNCj4gPiAr ICAgICAqIEluIENQUEMgYWN0aXZlIG1vZGUsIHdlIGFyZSBib3Jyb3dpbmcgZ292ZXJub3IgZmll bGQgdG8gaW5kaWNhdGUNCj4gPiArICAgICAqIHBvbGljeSBpbmZvLg0KPiA+ICsgICAgICovDQo+ ID4gKyAgICBpZiAoIHBvbGljeS0+Z292ZXJub3ItPm5hbWVbMF0gKQ0KPiA+ICsgICAgICAgIHN0 cmxjcHkob3AtPnUuZ2V0X3BhcmEudS5zLnNjYWxpbmdfZ292ZXJub3IsDQo+ID4gKyAgICAgICAg ICAgICAgICBwb2xpY3ktPmdvdmVybm9yLT5uYW1lLCBDUFVGUkVRX05BTUVfTEVOKTsNCj4gPiAr ICAgIGVsc2UNCj4gPiArICAgICAgICBzdHJsY3B5KG9wLT51LmdldF9wYXJhLnUucy5zY2FsaW5n X2dvdmVybm9yLCAiVW5rbm93biIsDQo+ID4gKyAgICAgICAgICAgICAgICBDUFVGUkVRX05BTUVf TEVOKTsNCj4NCj4gSXNuJ3QgcHVsbGluZyB0aGlzIC4uLg0KPg0KPiA+ICAgICAgaWYgKCAhY3B1 ZnJlcV9pc19nb3Zlcm5vcmxlc3Mob3AtPmNwdWlkKSApDQo+ID4gICAgICB7DQo+ID4gICAgICAg ICAgaWYgKCAhKHNjYWxpbmdfYXZhaWxhYmxlX2dvdmVybm9ycyA9DQo+DQo+IC4uLiBvdXQgb2Yg dGhpcyBpZigpJ3MgYm9keSBnb2luZyB0byBhZmZlY3QgSFdQPyBJdCdzIG5vdCBjbGVhciB0byBt ZSB3aGV0aGVyIHRoYXQgd291bGQNCj4gYmUgZW50aXJlbHkgYmVuaWduLg0KPg0KDQpIV1AgaGFz IGl0cyBvd24gdW5pcXVlICJod3AiIGdvdmVybm9yLiBTbywgaW1vLCBpdCBtYXkgbm90IGFmZmVj dC4NCg0KPiBKYW4NCg== From xen-devel-bounces@lists.xenproject.org Wed Sep 03 03:15:23 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 03:15:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107744.1458016 (Exim 4.92) (envelope-from ) id 1utdxz-00036Q-3R; Wed, 03 Sep 2025 03:15:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107744.1458016; Wed, 03 Sep 2025 03:15: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 1utdxz-00036J-0Z; Wed, 03 Sep 2025 03:15:23 +0000 Received: by outflank-mailman (input) for mailman id 1107744; Wed, 03 Sep 2025 03: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 1utdxx-0002xH-FX for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 03:15:21 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on20628.outbound.protection.outlook.com [2a01:111:f403:2406::628]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 38290e29-8874-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 05:15:19 +0200 (CEST) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by DM4PR12MB6232.namprd12.prod.outlook.com (2603:10b6:8:a5::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 03:15: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%7]) with mapi id 15.20.9052.019; Wed, 3 Sep 2025 03:15: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: 38290e29-8874-11f0-9d12-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oUz/zQ61G/w4l3uQ+JQYpccNAd4QAWxQhxwckxIPp5ygpYOkwYMHxGJoDdXzfMllAwlbZbhWdWrG+pNIPeYkYRVktLDZyCc0BVyR47ymUci3hGCm3YJGP25YHYnxThrODTFSiCCI+BooPPAuj4B2Z1T0OBLn11zPIjqcOd3H0bi/zFj6vqzq2gvGdIsV2HRSSWwwzuxnWsct+v/8cqqXZDdAlI1b8upA5ilpwnOLJhNclLMZmBk93JQUYhIPwfcrzfoHXZiEecTbaNA3qCx+Yt8qFQVaPQiVj0nqoi7cNnD454Sw7jwWgDlPhgUxDyBqFECb5/QcboW7YXy0Vm8Fgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gBxPuVYPBglpvWBWjpO0e8bUphfMwrIMC+BbUyvkfZY=; b=p0ZIT9N3Hg523/qV6XPLkJAoPwAdAX7aaIkVSngB6lnrKMbBbWHEt/e29mdFtgkjHXP8AJi0va9xiX2Mi/YCTUhk6RQB0hEeN/CjL2hr93mxNqKCbjItxEVSStev+SaxnewJ8YzguuP/wlfzpN+ZqTUQQ/AbzzVWCJMyThvKaBILAUvZptZVfs9TvrwzjHBUCS9yBvTwpyVP288SfLATQxucoNCwV0zIGW6czQfc1NRINv7vFhU0JcwfTMk6zJZZuejA+IOruelrMlIzJmCIbP3sdgn0bBIXOIRGxk8Nf7uRQeqN31VMZymI/g8ykqbtMwxEa+2Jy7qEoafoNJADpQ== 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=gBxPuVYPBglpvWBWjpO0e8bUphfMwrIMC+BbUyvkfZY=; b=q7OvqVGBA62yk+dgNiV5G2t4NUv+GqZFrDI+VFqz2z/+7iDvP59uOZlE9QwkBODZt96t9kBkF9ulpkFDA/SHJsMowIMmiSsiRnCKkjEWk3LxJHAX3kGEp8P8v/gqnBzGWLusUzWZX+6FaBnq80Y6khvEfG/QVP45Sbli7lv56Cs= 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 v8 0/8] amd-cppc CPU Performance Scaling Driver Thread-Topic: [PATCH v8 0/8] amd-cppc CPU Performance Scaling Driver Thread-Index: AQHcGAMDd72a6pbrUkeHflfdpjpvurR3+VkAgAjYZ1A= Date: Wed, 3 Sep 2025 03:15:15 +0000 Message-ID: References: <20250828100306.1776031-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-09-03T03:14:47.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_|DM4PR12MB6232:EE_ x-ms-office365-filtering-correlation-id: 54c9390b-7fd7-439d-11bb-08ddea981a7f 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?cHp5UElPOXRwTkRINWFXU2pxK3FvVmd6QVd4Q1Z2WVl6SWh1RkFHckFjeE9T?= =?utf-8?B?bkFZUkt6TTJtYU1GVnp0V0FIQ0M3amZsdmFUL1J4L2Z0elVPcWovMFRwaDhJ?= =?utf-8?B?ak1xQVpxbmxUSk92VEY5bzFhMlM0VEpyem1MNDVSd0VwekUvVTNrMERuWkRl?= =?utf-8?B?MFJ4a2wxOE51TVpVVGlQSnhFd3I5RDc5TlJvb0JMc2lLWTNOVDVuRzFibDVq?= =?utf-8?B?MjNWQXUyalhyZWtFK0NrMGdDL2krS00zZE1udS9YcnVtWXNibWo0YlpEZmJj?= =?utf-8?B?K2NvV2dzcEV0ek85cTBqNGd6aEpBZW1EaWJmSmdEYmowY1dsKzYyQ0tMVndY?= =?utf-8?B?QkhFbVJHbUFTZEw0QWpPRFZpeHlEYjVtMk9VL0Zodm0wajZVZzlHWU5iKzA4?= =?utf-8?B?Z1pGbVJkQnFrSlM0alluM2JUU1FyN1NsTmxTWE8wV1RFY0NvV1ZwaXFnUURZ?= =?utf-8?B?ek05ZFdML3ZlUkNaNlJVeUh5YzRqN3Npdkp0dEl1K3h1NndxZnI3aUk0djZ5?= =?utf-8?B?M2s0Vmd5Ui9TM1hXWnpYTDYybStPdThWZkt0clVhYWQxcFVBTUpaRzZOOFQ2?= =?utf-8?B?YTFzL1RKMjFYTm5jTTVJR1dza3hXQ3d5eUZ6UkMzWTZQcnlaTFlWeWpUVStB?= =?utf-8?B?NVZjb0pockVYMWlqZkRVSThXVlN5ZGdJYXdya1hLTjRZZFBpWlk5bWk0YmZp?= =?utf-8?B?Z01ab2xtMmNsZW9VRHZjZTU5cE9Hemt6MS8ydnNLNUptdmdBYlR6M2tuYkVK?= =?utf-8?B?Ujl5aU5ucHRYem9qYlZFb1RJUnJ4YytFK1RWK1MwYWlDb0hBVWkwRlMrc1ZO?= =?utf-8?B?UHoxL0JqVTVST2l3OG9mUm90RDZGdGwraC9HOFJZaXdEeDF1ei9uM25iTWp5?= =?utf-8?B?UnlXL05UK1lDQUlBMkVibHhGUHBlQmZBK2Fyb3Jnc1o1Qi8zUHJ2bjVCR293?= =?utf-8?B?Wm5qTUYzdTBvS1loa1pBbVdMNFVEZmRFc0RrYkdXakFyemZSZjlSM1VqZW84?= =?utf-8?B?akFzQlJlNEw5NlZScFBqaDhpOHNEQjJKZ2YwRjNtTUpoaVhNR3N6RVNBaXg2?= =?utf-8?B?UTJVL2h5YVo3VUlCdDlOdUtraTFDZzJkQjhHTjRRMTBCRHpFQjVVbjFjNGRF?= =?utf-8?B?VjgwekdGQWhjVEl4WmJYdUxmVUxtbFlxaElmTWJ2YWwxOGJTSVdwbGVuMzEz?= =?utf-8?B?MXJSUTRQSHgvWEV3T1hnaHgxejJYbVIyZXNlYVBsL1N2UHNBSkJ4blZJS0NQ?= =?utf-8?B?NTZJYVdySzZSaVZKK2xNU01xZUhYSVdlRzZNMHZiVlpIYmdNM01YM2JweEpN?= =?utf-8?B?ZHFlM1Y5Vzh1Rzg3SjJJT3BNNjN3d0p5MzEzNFBzTkpCaXdkRWQ1TjU0MnBD?= =?utf-8?B?ZG9YOGRCZmQ2WUp4QTRqNGR0SXB5QmVGTlNVN1FFd1Voc0NVTzhOaGhNd2tF?= =?utf-8?B?TDE5OEZ6MWJXRE5YaUIwYXEyUnRrakRjQmhTTm9kZDhPcTNPR3NxQit4ZlpD?= =?utf-8?B?QzVXREp4TVUzVTRQZitLZEFwNHo0QUgrTmJ6SEhpN0NidlpwcEI5aEpCKzUx?= =?utf-8?B?VlRxcUYrSEEwSThPRHhxWlhOZnhHbENYMTNLbDNTbGk2MjhQT01YUEpCMTU1?= =?utf-8?B?a2FQK0g4Q2xmOWdKK293b09uemtGZThmVEE1NjFldFZ4cE93bXpPazZITXd4?= =?utf-8?B?akFlTjJwYmYwUnZFejNlVXF1QXZqZ2IzRXhWUGdtTnhGZUltRm41bnZHcTlq?= =?utf-8?B?WXcyOEVSR1haTUp3cmlZV0Q2dzRQUWdVM3UrQ2xlc2g4VTRuNXM1RVhZSSts?= =?utf-8?B?MWVBQllrcE51RUlXeHNMaC9DdThua0dYWE5XcDE1bDM2c3EvU2ZmQ2QvRTNG?= =?utf-8?B?cmVGT0NuNUNQaUpycGhqWnpBaUxWZ2svVUNBekZJVVVCVVlOT0Q0ZWxFam1U?= =?utf-8?B?ZHBVSVhpVE8wdmxNcVRQTFlQK005RDlyeXpHdCt3dHRqckVJZTFsZjV3Q1or?= =?utf-8?B?WFIvUE5jR3NBPT0=?= 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?Y3dnbThKRDEzZUZhNkZ5K1BqTGhvNUtVRllaZlArclIvb3pHcUw0UUI0dldB?= =?utf-8?B?d1lzNVNQZjZvT2xSRkZnMjlydEVKd0JCUWhRYUZ5Q3VGcTBEKzdvOGxIYmxX?= =?utf-8?B?MnJML2tlbzhjbXc0VGluaDgvZUpDNjhmWlNGMzFhSGwwRHNlNVlueGlQZG96?= =?utf-8?B?ZEkwVTZsRUJBQzZkbWlSQ1pzT3dudW1mYU1ZLzNXeW10R3pEbnAxeHIvMitK?= =?utf-8?B?dTJBWlVlbUtpNW5SNG0vTlhReUJTMlhhR2MrTmYyR20rVXh6ejBiTlNqSURq?= =?utf-8?B?d09KMUVCR2pDTlRVbGJheVVHNyt4K2N0c3RoenV3VWFIcmVUUTlXZnU2eVA4?= =?utf-8?B?T2xpeGlLY3MwNnF0R05pSjZoZlJSY2JyQzU1N2ZvWkhXQUtMV2dTVm42L2xo?= =?utf-8?B?WGQyM2Q0ZGNCamduMDhPeDNSYm9iQ0U4Vis0ak9iL1RKWkdCMEc0a0JFclVS?= =?utf-8?B?aFBqM1hXOThMOEdFWFFSejd0WXJwSFFuUUcwWXpQVXVkd2VRdWIxV3JMakJT?= =?utf-8?B?S3VQTHZWRXVpZHArQlhOZVpuNmI4WlYwdlRkNWVsMmF3ZWp0eVNqeEtzOEV3?= =?utf-8?B?am1Da0RxYXBaYzduVnNGNlZoWHRwNEdBNHZtak9RRW5kdFcySno4LzZxYlo4?= =?utf-8?B?dTFBa2c4U2wvUDdmY3BNaWxOU0MwMEM5TUx2S3Q0KzVoRmVVZUpuYS80RDdB?= =?utf-8?B?QXBwUVNyOWxGZ0hLSmZFYTVSMUVqNFB4Y2hvaFJuYjd5dkgzZWdRR3E4cnVY?= =?utf-8?B?WElsaXNyVFZNZkt2QnA1aFBPQmJRN2NLWVhCa2Vtd1ZuVmRQU1FhVTE2enBi?= =?utf-8?B?OGlQbHdaUENDSFpsUmdyKzdaempOMnJEYm1uQzRNTTB3RWd0emJJSE0rVUVv?= =?utf-8?B?c1I3WmpTRHk1YWQ3U2J5MU1JMEpadGQ5UDQxeDhpS2wvR0pQQ0xtenhFbSs5?= =?utf-8?B?NEphRHh0QzVkMWx5ejVvMG0yeG42dGo5aVo2UGxjNk1IU1lrOWNmMW9XZW1r?= =?utf-8?B?N1luUDBEUkFPekloZzU2VFZ5ZWRzUG43MDMyR3ZNcWZtNlpzMW9SUTNRTlNI?= =?utf-8?B?dVZra0Q3ZjJad3F3aU9pQWRQVU1iaFpMOUlyMmRVanJHclRaMWZibGtaQkNp?= =?utf-8?B?TmVhTDFTblJ2NkFtb2dIaStlVUU2SzYrK2dRbWY0SksrME4yeHY1YkFGc2or?= =?utf-8?B?QXVERjRYdkplaHVGUG9TcTVHS3ExVHBlVE5raFBjeEJLSWZYdkh1QnhMYkM5?= =?utf-8?B?ZFFXcVNLaDRLd1BJR1ZyRkFkQVpzY2RaM0Jjd1BuS2ljVW9GeXNQVlcxQkdC?= =?utf-8?B?L3ByYnZlZGVxLzBiMDVyOEg1aHpEeFVWZFFMV0ExOWtlY29lek5aY2VjMmxo?= =?utf-8?B?TDl4ZFZ2VjV0a3ZWckhBZ3dYdXk2cjhKTXZxamFBdGEyczRaU3YzYVltV3dB?= =?utf-8?B?UVM4cEdkUDVZTFZGSVVqdUo5dEpodjNQOVRyTS9KUWV5T0V0dXZacWVweUQ2?= =?utf-8?B?a25hQTdiQnJpQ1VLaFpaRVZTNGM1WHllN0dLd3pibjdzd21EM1loV3p4NkhD?= =?utf-8?B?ZGZmRHlqSmJTVDk2UVhkMEM1d1Rwenh3WjJIMWprTEtrTisrSXdrVEI0bXZj?= =?utf-8?B?cXVFL1l3dHo0TmViNDhsQjhydTB4VE12NFUva2pyTGZEN204bll3RlF3VmdQ?= =?utf-8?B?S1A1RjZJR05zV1A4b0N6QW5iTTkxV2w3SzBvdy85WU1GSW9teWVLSHlLNGwv?= =?utf-8?B?V3BVUlZHblZESXFKSWdRSEFRL1lrSU91TEgyTFlma1hwdkFSUW8xU0RCUmln?= =?utf-8?B?TU9WdDJwUytGTW9iK0twV3liRGg5aU9YYmxNVVVwR1BUa1BDbG9hb1lJdytx?= =?utf-8?B?TThuQ1NlbjJSclhudHRlTTR1ZFRmc1hGZFlzSHYzSFF4bm8rcmpQenVHZm9S?= =?utf-8?B?M1ZPZ1BCb1h1bXVldk9nbVEvNk5OeWlhNUhSL2JPWHl0NmpVNXk0K05BQUcv?= =?utf-8?B?d1pudFRtTU50QjVtMFc2T2JMV0RIQzUwOHBkSWpVeUVhVTZhbWkrY0NWd05G?= =?utf-8?B?d2k0b2xsRGhQVUtMbHlOOFVTbERsSFpFV1lQbWVJWnlrNWVyc1oyTnp0bWJu?= =?utf-8?Q?8I7Y=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: 54c9390b-7fd7-439d-11bb-08ddea981a7f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 03:15:15.6318 (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: aWEFUaPryk5HrsEoInGvXqy7HGQOQt4+8SjAjgVHs61vuJsEXvhfuE9Rr8SAYq8lqhic3NUvlGzs7auydG+xIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6232 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjgsIDIw MjUgODoxMCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD YzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRy ZXcuY29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp eC5jb20+Ow0KPiBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9y emVsLCBNaWNoYWwNCj4gPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVuIEdyYWxsIDxqdWxp ZW5AeGVuLm9yZz47IFN0ZWZhbm8gU3RhYmVsbGluaQ0KPiA8c3N0YWJlbGxpbmlAa2VybmVsLm9y Zz47IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT47IHhlbi0NCj4gZGV2ZWxAbGlzdHMu eGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OCAwLzhdIGFtZC1jcHBjIENQ VSBQZXJmb3JtYW5jZSBTY2FsaW5nIERyaXZlcg0KPg0KPiBPbiAyOC4wOC4yMDI1IDEyOjAyLCBQ ZW5ueSBaaGVuZyB3cm90ZToNCj4gPiBhbWQtY3BwYyBpcyB0aGUgQU1EIENQVSBwZXJmb3JtYW5j ZSBzY2FsaW5nIGRyaXZlciB0aGF0IGludHJvZHVjZXMgYQ0KPiA+IG5ldyBDUFUgZnJlcXVlbmN5 IGNvbnRyb2wgbWVjaGFuaXNtIG9uIG1vZGVybiBBTUQgQVBVIGFuZCBDUFUgc2VyaWVzDQo+ID4g aW4gWGVuLiBUaGUgbmV3IG1lY2hhbmlzbSBpcyBiYXNlZCBvbiBDb2xsYWJvcmF0aXZlIFByb2Nl c3Nvcg0KPiA+IFBlcmZvcm1hbmNlIENvbnRyb2wgKENQUEMpIHdoaWNoIHByb3ZpZGVzIGZpbmVy IGdyYWluIGZyZXF1ZW5jeQ0KPiA+IG1hbmFnZW1lbnQgdGhhbiBsZWdhY3kgQUNQSSBoYXJkd2Fy ZSBQLVN0YXRlcy4gQ3VycmVudCBBTUQgQ1BVL0FQVQ0KPiA+IHBsYXRmb3JtcyBhcmUgdXNpbmcg dGhlIEFDUEkgUC1zdGF0ZXMgZHJpdmVyIHRvIG1hbmFnZSBDUFUgZnJlcXVlbmN5DQo+ID4gYW5k IGNsb2NrcyB3aXRoIHN3aXRjaGluZyBvbmx5IGluIDMgUC1zdGF0ZXMuIENQUEMgcmVwbGFjZXMg dGhlIEFDUEkNCj4gPiBQLXN0YXRlcyBjb250cm9scyBhbmQgYWxsb3dzIGEgZmxleGlibGUsIGxv dy1sYXRlbmN5IGludGVyZmFjZSBmb3IgWGVuDQo+ID4gdG8gZGlyZWN0bHkgY29tbXVuaWNhdGUg dGhlIHBlcmZvcm1hbmNlIGhpbnRzIHRvIGhhcmR3YXJlLg0KPiA+DQo+ID4gYW1kX2NwcGMgZHJp dmVyIGhhcyAyIG9wZXJhdGlvbiBtb2RlczogYXV0b25vbW91cyAoYWN0aXZlKSBtb2RlLCBhbmQN Cj4gPiBub24tYXV0b25vbW91cyAocGFzc2l2ZSkgbW9kZS4gV2UgcmVnaXN0ZXIgZGlmZmVyZW50 IENQVUZyZXEgZHJpdmVyDQo+ID4gZm9yIGRpZmZlcmVudCBtb2RlcywgImFtZC1jcHBjIiBmb3Ig cGFzc2l2ZSBtb2RlIGFuZCAiYW1kLWNwcGMtZXBwIg0KPiA+IGZvciBhY3RpdmUgbW9kZS4NCj4g Pg0KPiA+IFRoZSBwYXNzaXZlIG1vZGUgbGV2ZXJhZ2VzIGNvbW1vbiBnb3Zlcm5vcnMgc3VjaCBh cyAqb25kZW1hbmQqLA0KPiA+ICpwZXJmb3JtYW5jZSosIGV0YywgdG8gbWFuYWdlIHRoZSBwZXJm b3JtYW5jZSB0dW5pbmcuIFdoaWxlIHRoZSBhY3RpdmUNCj4gPiBtb2RlIHVzZXMgZXBwIHRvIHBy b3ZpZGVzIGEgaGludCB0byB0aGUgaGFyZHdhcmUgaWYgc29mdHdhcmUgd2FudHMgdG8NCj4gPiBi aWFzIHRvd2FyZCBwZXJmb3JtYW5jZSAoMHgwKSBvciBlbmVyZ3kgZWZmaWNpZW5jeSAoMHhmZiku IENQUEMgcG93ZXINCj4gPiBhbGdvcml0aG0gaW4gaGFyZHdhcmUgd2lsbCBhdXRvbWF0aWNhbGx5 IGNhbGN1bGF0ZSB0aGUgcnVudGltZQ0KPiA+IHdvcmtsb2FkIGFuZCBhZGp1c3QgdGhlIHJlYWx0 aW1lIGNwdSBjb3JlcyBmcmVxdWVuY3kgYWNjb3JkaW5nIHRvIHRoZQ0KPiA+IHBvd2VyIHN1cHBs eSBhbmQgdGhlcm1hbCwgY29yZSB2b2x0YWdlIGFuZCBzb21lIG90aGVyIGhhcmR3YXJlIGNvbmRp dGlvbnMuDQo+ID4NCj4gPiBhbWQtY3BwYyBpcyBlbmFibGVkIG9uIHBhc3NpdmUgbW9kZSB3aXRo IGEgdG9wLWxldmVsDQo+ID4gYGNwdWZyZXE9YW1kLWNwcGNgIG9wdGlvbiwgd2hpbGUgdXNlcnMg YWRkIGV4dHJhIGBhY3RpdmVgIGZsYWcgdG8gc2VsZWN0IGFjdGl2ZQ0KPiBtb2RlLg0KPiA+DQo+ ID4gV2l0aCBgY3B1ZnJlcT1hbWQtY3BwYyxhY3RpdmVgLCB3ZSBkaWQgYSA2MHMgc2FtcGxpbmcg dGVzdCB0byBzZWUgdGhlDQo+ID4gQ1BVIGZyZXF1ZW5jeSBjaGFuZ2UsIHRocm91Z2ggdHdlYWtp bmcgdGhlIGVuZXJneV9wZXJmIHByZWZlcmVuY2UgZnJvbQ0KPiA+IGB4ZW5wbSBzZXQtY3B1ZnJl cS1jcHBjIHBvd2Vyc2F2ZWAgdG8gYHhlbnBtIHNldC1jcHVmcmVxLWNwcGMgcGVyZm9ybWFuY2Vg Lg0KPiA+IFRoZSBvdXRwdXRzIGFyZSBhcyBmb2xsb3dzOg0KPiA+IGBgYA0KPiA+IFNldHRpbmcg Q1BVIGluIHBvd2Vyc2F2ZSBtb2RlDQo+ID4gU2FtcGxpbmcgYW5kIE91dHB1dHM6DQo+ID4gICBB dmcgZnJlcSAgICAgIDU4MDAwMCBLSHoNCj4gPiAgIEF2ZyBmcmVxICAgICAgNTgwMDAwIEtIeg0K PiA+ICAgQXZnIGZyZXEgICAgICA1ODAwMDAgS0h6DQo+ID4gU2V0dGluZyBDUFUgaW4gcGVyZm9y bWFuY2UgbW9kZQ0KPiA+IFNhbXBsaW5nIGFuZCBPdXRwdXRzOg0KPiA+ICAgQXZnIGZyZXEgICAg ICA0NjQwMDAwIEtIeg0KPiA+ICAgQXZnIGZyZXEgICAgICA0MjIwMDAwIEtIeg0KPiA+ICAgQXZn IGZyZXEgICAgICA0NjQwMDAwIEtIeg0KPiA+IGBgYA0KPiA+DQo+ID4gUGVubnkgWmhlbmcgKDgp Og0KPiA+ICAgeGVuL2NwdWZyZXE6IGludHJvZHVjZSBuZXcgc3ViLWh5cGVyY2FsbCB0byBwcm9w YWdhdGUgQ1BQQyBkYXRhDQo+ID4gICB4ZW4vY3B1ZnJlcTogaW50cm9kdWNlICJjcHVmcmVxPWFt ZC1jcHBjIiB4ZW4gY21kbGluZSBhbmQgYW1kLWNwcGMNCj4gPiAgICAgZHJpdmVyDQo+ID4gICB4 ZW4vY3B1ZnJlcTogaW1wbGVtZW50IGFtZC1jcHBjIGRyaXZlciBmb3IgQ1BQQyBpbiBwYXNzaXZl IG1vZGUNCj4gPiAgIHhlbi9jcHVmcmVxOiBpbXBsZW1lbnQgYW1kLWNwcGMtZXBwIGRyaXZlciBm b3IgQ1BQQyBpbiBhY3RpdmUgbW9kZQ0KPiA+ICAgeGVuL2NwdWZyZXE6IGdldCBwZXJmb3JtYW5j ZSBwb2xpY3kgZnJvbSBnb3Zlcm5vciBzZXQgdmlhIHhlbnBtDQo+ID4gICB0b29scy9jcHVmcmVx OiBleHRyYWN0IENQUEMgcGFyYSBmcm9tIGNwdWZyZXEgcGFyYQ0KPiA+ICAgeGVuL2NwdWZyZXE6 IGJ5cGFzcyBnb3Zlcm5vci1yZWxhdGVkIHBhcmEgZm9yIGFtZC1jcHBjLWVwcA0KPiA+ICAgeGVu L2NwdWZyZXE6IEFkYXB0IFNFVC9HRVRfQ1BVRlJFUV9DUFBDIHhlbl9zeXNjdGxfcG1fb3AgZm9y IGFtZC0NCj4gY3BwYw0KPiA+ICAgICBkcml2ZXINCj4gPg0KPiA+ICBkb2NzL21pc2MveGVuLWNv bW1hbmQtbGluZS5wYW5kb2MgICAgICAgICB8ICAxNCArLQ0KPiA+ICB0b29scy9pbmNsdWRlL3hl bmN0cmwuaCAgICAgICAgICAgICAgICAgICB8ICAgMyArLQ0KPiA+ICB0b29scy9saWJzL2N0cmwv eGNfcG0uYyAgICAgICAgICAgICAgICAgICB8ICAyNSArLQ0KPiA+ICB0b29scy9taXNjL3hlbnBt LmMgICAgICAgICAgICAgICAgICAgICAgICB8ICA5NCArKy0NCj4gPiAgeGVuL2FyY2gveDg2L2Fj cGkvY3B1ZnJlcS9NYWtlZmlsZSAgICAgICAgfCAgIDEgKw0KPiA+ICB4ZW4vYXJjaC94ODYvYWNw aS9jcHVmcmVxL2FtZC1jcHBjLmMgICAgICB8IDc2NiArKysrKysrKysrKysrKysrKysrKysrDQo+ ID4gIHhlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEvY3B1ZnJlcS5jICAgICAgIHwgIDY5ICstDQo+ ID4gIHhlbi9hcmNoL3g4Ni9jcHUvYW1kLmMgICAgICAgICAgICAgICAgICAgIHwgICA4ICstDQo+ ID4gIHhlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbWQuaCAgICAgICAgICAgIHwgICAyICsNCj4g PiAgeGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL21zci1pbmRleC5oICAgICAgfCAgIDYgKw0KPiA+ ICB4ZW4vYXJjaC94ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMgICAgICAgICB8ICAxOSArDQo+ID4g IHhlbi9hcmNoL3g4Ni94ODZfNjQvY3B1ZnJlcS5jICAgICAgICAgICAgIHwgIDE5ICsNCj4gPiAg eGVuL2FyY2gveDg2L3g4Nl82NC9wbGF0Zm9ybV9oeXBlcmNhbGwuYyAgfCAgIDMgKw0KPiA+ICB4 ZW4vZHJpdmVycy9hY3BpL3BtLW9wLmMgICAgICAgICAgICAgICAgICB8ICA2OCArLQ0KPiA+ICB4 ZW4vZHJpdmVycy9hY3BpL3Btc3RhdC5jICAgICAgICAgICAgICAgICB8ICAgNCArDQo+ID4gIHhl bi9kcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcS5jICAgICAgICAgICAgIHwgMTM3ICsrKy0NCj4gPiAg eGVuL2RyaXZlcnMvY3B1ZnJlcS91dGlsaXR5LmMgICAgICAgICAgICAgfCAgMTUgKw0KPiA+ICB4 ZW4vaW5jbHVkZS9hY3BpL2NwdWZyZXEvY3B1ZnJlcS5oICAgICAgICB8ICA0MCArLQ0KPiA+ICB4 ZW4vaW5jbHVkZS9hY3BpL2NwdWZyZXEvcHJvY2Vzc29yX3BlcmYuaCB8ICAxNCArLQ0KPiA+ICB4 ZW4vaW5jbHVkZS9wdWJsaWMvcGxhdGZvcm0uaCAgICAgICAgICAgICB8ICAyNiArDQo+ID4gIHhl bi9pbmNsdWRlL3B1YmxpYy9zeXNjdGwuaCAgICAgICAgICAgICAgIHwgICA1ICstDQo+ID4gIHhl bi9pbmNsdWRlL3hlbi9wbXN0YXQuaCAgICAgICAgICAgICAgICAgIHwgICA1ICsNCj4gPiAgeGVu L2luY2x1ZGUveGxhdC5sc3QgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKw0KPiA+ICAyMyBm aWxlcyBjaGFuZ2VkLCAxMjgzIGluc2VydGlvbnMoKyksIDYxIGRlbGV0aW9ucygtKSAgY3JlYXRl IG1vZGUNCj4gPiAxMDA2NDQgeGVuL2FyY2gveDg2L2FjcGkvY3B1ZnJlcS9hbWQtY3BwYy5jDQo+ DQo+IE9oLCBhbmQgLSB3aGF0IGlzIHN0aWxsIG1pc3NpbmcgaXMgYSBDSEFOR0VMT0cubWQgZW50 cnkuDQoNClRoeCwgdW5kZXJzdG9vZC4NCg0KPg0KPiBKYW4NCg== From xen-devel-bounces@lists.xenproject.org Wed Sep 03 03:16:53 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 03:16:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107758.1458026 (Exim 4.92) (envelope-from ) id 1utdzQ-0003hI-E1; Wed, 03 Sep 2025 03:16:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107758.1458026; Wed, 03 Sep 2025 03:16: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 1utdzQ-0003hB-BQ; Wed, 03 Sep 2025 03:16:52 +0000 Received: by outflank-mailman (input) for mailman id 1107758; Wed, 03 Sep 2025 03: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 1utdzQ-0003h5-0o for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 03:16:52 +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 6d9a9e58-8874-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 05:16:49 +0200 (CEST) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by DM4PR12MB6232.namprd12.prod.outlook.com (2603:10b6:8:a5::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 03:16:46 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d%7]) with mapi id 15.20.9052.019; Wed, 3 Sep 2025 03:16:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6d9a9e58-8874-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k5Dlr+a1cpKF4zqvwow11H4lhwMh64Pg8DZPRme+0PxPcCdyyF819Yx/e3S42uUVHtCjZOQ161jAaXIV12QtuZoSpP//nMeq20ygn7+AfyNyqJZX/5iCzcaBnlX5obIyXQLnj/SQ6mTe691r3idd/5z3wQ0ktGvu9xdTmDcYWOgWBtoooc/MzaLLDAz+PSooCol8LtdVX/g27kWglJ2nA+2ACK8+Kn10Adz+WsDPQRYruDgFI6ohzDFT+TmOGMpXkwtkIUhTy2uSANPip9cWviLsmS3VSMpBHcilxZ65af/O5ey75kaeHLJFBnaNxJ/AA6SvmjCTS52AOKlPqdxccg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3MKx7kjQDyAnmV3fL3rzYARSgLguR1FN9t/RRvMOIP8=; b=qbcqddfGjrwYiQdXh9oMxbnNA85+GsM/fJZ5xbJQkiH4ZxJPvt5qSadsSeTQtHrVOPGnjBRRU5EEQ+7Nes2LAZ/yeFSQmi+BScVfA8zGuW03IotzxnMO4JT53OO9hfRzYkMA/Onj2Jh3qnkSkWeIUi1+eRIUXEAKM5OjrjOSY9ucBz+JxxoJN1doNuMi6DVWu9Gr36Pk3h7zvBeksXHf67cBQEIUNe85NwbEg/nAa54OdYJyeti52btuGCXosnf99GlLSGZukPd1WpBX+prz+g+EM7GWJKWvQeVdT2y30Ooja0eUaCJ7aih1y7hmP3+KIf1Yah1K5zBfW9UzN3XmCA== 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=3MKx7kjQDyAnmV3fL3rzYARSgLguR1FN9t/RRvMOIP8=; b=FpdPoADAWfoCZl+x8xYNxawHSnGVwo6tKaRO4JGWK8hizELcXR4XNZRwDg7IJkOfixqPUiUwB/i1VFIffuaqUM7kZ76kYyoYlBAgYaBWvdpgfawJPVbGVY1Z5zmPFu1KE4oIu5bT3ZJWNGdPrG0WwAVAjOxT2cqxgmVqH3UxG1s= 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 v8 1/8] xen/cpufreq: introduce new sub-hypercall to propagate CPPC data Thread-Topic: [PATCH v8 1/8] xen/cpufreq: introduce new sub-hypercall to propagate CPPC data Thread-Index: AQHcGAMFn6LyRgMx2kqwcXFBCS++s7R4BJqAgAjNW6A= Date: Wed, 3 Sep 2025 03:16:45 +0000 Message-ID: References: <20250828100306.1776031-1-Penny.Zheng@amd.com> <20250828100306.1776031-2-Penny.Zheng@amd.com> <00e4af60-6916-4a71-b797-757c1163579a@suse.com> In-Reply-To: <00e4af60-6916-4a71-b797-757c1163579a@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-09-03T03:16:40.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_|DM4PR12MB6232:EE_ x-ms-office365-filtering-correlation-id: 96bebdb9-4047-489a-18ec-08ddea985052 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?N0hya29IRklTTmZaTDJJbFZYTFJIYS9PUUZjSU1CTUpjWlVZNGkvTDl5aFAx?= =?utf-8?B?bDNhdkE2ZEJ0ZUtlUG4vcWc2d2lrMm9VbHkvMFlnZXd6ZmppOE9pUllUbCtJ?= =?utf-8?B?ZWhZVGpwZklaWkw5enJtQ0hEV2JXT3FCWS83bVI2OUVUYlVBRXhsYmV6aFpF?= =?utf-8?B?cjI5NnpDclJCQVhVNTQxTlB0Nkl5bVdRL0RoRGJiRWpPc0d2ZVViOTBUM1ls?= =?utf-8?B?MFNvMFV6UGpzOFZvNkh6R0dsNVdrdXY5emxTNXF1dEZQeDhCZzlTQzJLT2FU?= =?utf-8?B?R3h0NTNudk85VEZPNVArNHMycGFWUjMzKzFwU0lBdUNYWjNzR1pRWHBPNHhn?= =?utf-8?B?YkJ0cFAwK3Y0VXBjRTlZM3U5ak54U2VlTmg3UE8wN3p6ci8zUFNOdDZlQmV4?= =?utf-8?B?Mk5TQ3QrM0dMejYxRVRTVTFDZDUybHpubFI1OEVYRmw3cXgvLzFWYmpXY2tz?= =?utf-8?B?T2FMbGM4YUNxNEFsRktwR2hZQUpjbjlYTHJoR21ia2liMFBmRmdhQ1VnVHZn?= =?utf-8?B?L3VQTXE2bExBR3VxL0VGWE16VXl2YkhSTkZkQzlmMmJEYTI3dEE1by9lSWdx?= =?utf-8?B?RXR1Tk5mclU2VDR6WDNUYlhZeTZ1VDZQekRocWhFbE9rZVRLUkFBKzkxMm5P?= =?utf-8?B?UW1xV3RaUWk1amNLSjFOV1B3V3o3WDU2Qkk3M0k4SkYydThPTUVlOFNxUlJz?= =?utf-8?B?VDN4Vlo1TEJVcGRybjZ3RlgwZU5jOUxFNkN3M2c0VlRzOWFValhEOXVQY3Zn?= =?utf-8?B?dTZJN0VTTkhQZVdZd2FTdHVqeWdQYkUrck8vaEVCSnRTMVQyaXV0Y3BtUGdD?= =?utf-8?B?QTNvYmdFd3J1Q3l5SUJtYVBJNnFXQ201cTF2YUNZMitzZ0VGem1vVlg3L3Yx?= =?utf-8?B?NENYQlFtaVo2Mit6UHBqaXdPcXo1V3VLYjl3a1dXU1RLUFN2QW1YVWZhZnU2?= =?utf-8?B?U0FOMGphS1k1OG04eUNQcEhlMTlhbTg5RnIvQnJ1QlErL3g2ZDloQ0lLNjl3?= =?utf-8?B?VnZXZm5tUms2aHhrM1M5RTdYNkc5ZGhpSzNTVDhYNmdHYjI0U3p0Z3NheGxE?= =?utf-8?B?VVAxK2ROd29HYmJMWFMvZDVha1pzbUxIRG51WTVaWUxMb2NVeXE2WjluNEg3?= =?utf-8?B?RCtqL2xFd1BpdS9mTWlkd2R6RS9IQ0VsdXhtQm1CMVJITytnWTVjbW5KQ1Ir?= =?utf-8?B?Zkw0aU5DU000ampBbUxzY3M1MEwrNFF6Zm1NdWFQUlUxaWU4a2tLNzJ5RHRF?= =?utf-8?B?L1dGeWk5Q1ZQcUFHYWg3VjdCZTVCWW1SOE91UERHUE5VS2w4L0Fxd0JmK1k3?= =?utf-8?B?bkhmOW1Ha0hLV3lsc2hhaENhcFJLMWFucWwwMG0wdjdtanp5NG9FYmtuL2Jv?= =?utf-8?B?TDB0QUZ2SFBRRjlSN3h4MmJuNmxUckNKVmxib0wxeUZ6UUIwaG5maUszUE85?= =?utf-8?B?N1V6TGgrdWxENXNjL3hOdjVxRWowR2NiTjJRNzM2cWZ1akNKMHhJRThJdUZP?= =?utf-8?B?dmtxUHlTTERpcnpmeVg3d3JOU1hpZnlWNHVQbWlSTHdsL2FhNjdnTWpOQllC?= =?utf-8?B?NXREYlNrNGc3QVBTUDNUZDFYTXpSNC80Mmg2bFd5cldUMU1sUXlRd1NKTHpW?= =?utf-8?B?Qy93WmwzU0xtaENHN1pUcURIQ3R4VldtbnUybXllRVQ3d1dscGp2ZThuclRa?= =?utf-8?B?VFpOSHBRSE9WNmI4TytQc28xa25SeENiQndjMVczZXBlNWhzeWJ4NFBxamF1?= =?utf-8?B?Z0VYbEVFeVJNbjJWU2F4MzJLam1UYUpiQjlYNmtBRktDOWpiK3FFdWZkYkNo?= =?utf-8?B?UUJ0cWM3bXJadFQ2UG5DYzVreXd1SklBK0N2aDRoajZTRnkyQlpUNnJ3NDRn?= =?utf-8?B?cU5helByVFFVZTdHYTZ3VmxEeFN5anJJQmpJeTBTTGdwSTRSZFFGM0ppQVha?= =?utf-8?B?eEFIN1AwNXJ5ckhyd013SWllU01Mc1NEam1QbFFZa05vbnJYUlZ6amUrTWh3?= =?utf-8?B?Yjk4K1psaWxBPT0=?= 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?UHdkL0RMZVE3cDBVZFpydEpkelpraUtkSTFJY1pNSW1WNU1CekVnSUhaZ1Iy?= =?utf-8?B?bnVpd2dYWWtJV3B6YTAxUzBYT0VlTEJkbWVPYXRrMU9pVGtER0tGTGdhSExp?= =?utf-8?B?UE90ZUcxRUJIQnM3TG1VTjl3YWZ1aythN3BKVmR2dXo5cGZLRGJ5WVRCTDBN?= =?utf-8?B?WkN4dmx0cnZDcnhZR1h5ckRRT0RPaGlyK1d3RDMrT1JHYndSb1VtNFcrMmxB?= =?utf-8?B?TnRTRTFGZDlhckViemJOdWIrY1AwUjgrVnhZRk9zUUxYQkJSN3Z0bUtWVVI4?= =?utf-8?B?VTJNeWdCRGRnRzhNUGdiMVlOdVZPNFJ3VzJ6QjdHcXpxMDNmVzNBQmJQRTVx?= =?utf-8?B?UmRRN0NYci8xa0RGQWRJRGhJYWkyWGFWYndjeXdqaVEvMm4wMitSR2MyWkpN?= =?utf-8?B?WWd1dk1maVNVbXVvL1NFWU5COFhrZ210OElXYXdpUmdOQU8yY1FWVzZRcDgr?= =?utf-8?B?OG15QjN6WmNERE43NGpoMmZTY3A4ZEQwK2wrbVJtMStURW5jZ1J4aThoOEN0?= =?utf-8?B?RGFQRWs5OGEwU3IxSzRvOFZYWEFRS3FVOFgvYjVsZWJMWEJLSTFXa093Y1FC?= =?utf-8?B?TFhqZmRaWVMwR0JhQThBbTRwS0JmaFV0OGZnSnF4QnJHbkk2MSsvMHZiTWhq?= =?utf-8?B?emczcnYxL2J1bzd1bm9oczczbVJhKzRpRWY5SEtwVFRDdjg5bXoyakozLzBL?= =?utf-8?B?WkMyOUF5clFtbGVUMDhzVWlkZ1UxWGxnRVJmZFlVVU1GdFlyaFJzTzNsSTQ2?= =?utf-8?B?TkhUUGtudUQ1SWdFbnFNK3BGNytZRGMrbS9UUzZZZjZabWUrV2QwemtkQloy?= =?utf-8?B?TVplSVJmZU80TEFCWStnU3VhVFQ1MFN2TzhrdzFwWjBtUzRYRW82bEF1eCtv?= =?utf-8?B?VzBWVWNKZS80OUhibzI2Tk51QlpIKzdTUFh4U1cxUjk5cE51djlFcDdEMUoz?= =?utf-8?B?THNFdzJqbm9hemsrYytaRUtkazFzU2g0ZUwwbUdVQWRHZ0FpYjVudUhoUExz?= =?utf-8?B?MHNIUklRY2wrNFhzSWdSb1ZWYXFvcmRhaHJaL0FrK09RbmpVNXJONEo1YmlU?= =?utf-8?B?b3NLU1Nxc1p5Y0hJaTlVTmJKM0dRYXRHVFljY3NFMXF2NnFmMldCci9DbXdJ?= =?utf-8?B?M0x6WjlaT3VZTmdLakNjdFdoTWpJZlZuNlJjaHVubVVZWTRsdlpaNFNzTm9X?= =?utf-8?B?UkpVZVdaS3ltMzlSOXVNOXRLWFp5TFZlOHhqa2IrR3BTQmdhMkdaWlFUYVV6?= =?utf-8?B?cWJ2WUJhTUl5Sk5veEdjelNLR3lYQ0RSbEpPcGlDc3A1MUVMQmNYdGR6NDBB?= =?utf-8?B?SFFFQ1ZCN25LakpKUkZzcVpRVVo5cTg4K3VCZTBLc3VlckpJazJRNjJDcnpP?= =?utf-8?B?U2hWU1c0NTB5TzB0eXpNTmMyUlNtU2lkK09sNXg0Ky9pd01hSkp6QzV4ZXhj?= =?utf-8?B?K3pZcU53eVk1ZHZjZFZON3ZQYk9BUjdkYlcvdkNtb3VBNGlIU3VxRkNlemx6?= =?utf-8?B?WDZpZ3hrckh4MWE3NUNwc1JVbDRmVkIwUnB3dmpSc1kxNlV5VUttNDRmMG9n?= =?utf-8?B?R2hMVnNTL3BDa1R1MnEzUjZ3UE9TZ29ETDdndlc5aEh3aW1yVmQ1UG8zSWVi?= =?utf-8?B?SXpjU2daR1RVc3BESlVtZ2x5elpEeVhMY0FaTzhTNFZjT0lYQlFHYWJlbnNH?= =?utf-8?B?OWc5dTZ5VVlFTzRyU28vSWIrbzN0aWducklqd1FzSkVEbmljNVh0eTc1dkF3?= =?utf-8?B?d0ZDS2VNQjNIekQ2R2xCZWg2N2RTTjIrYndNNXlQclpjQVJ6UWpBREo5Z2tP?= =?utf-8?B?NGtyY3R0cE5xY3owTXZUelhlbEJhdWhNR3h1R0x6SkdVbC9QclN2U3VaamJa?= =?utf-8?B?QWovYTVGMktHUmx2L3JjZVRpSUNoc1B4NGNSaXIxKzhZK2FFdm1wbnZIQXpz?= =?utf-8?B?RFNydk5KZ1NSQ2hvSmNIdzYxbE9pZFdjUGlzVkVLemVBODdUaDNITUdoU25N?= =?utf-8?B?dXVhMWRydDlRMkIwZEp6R1h3QW5iN3VuOVd2ODl5RXc0bTdCOVVwTnVUQm0y?= =?utf-8?B?andMM1oyZ09iSkV0TDRCajFFVVRCSWRFZ04xdkt2d2hVTjgxeDlJdTV3aTAv?= =?utf-8?Q?qfFw=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: 96bebdb9-4047-489a-18ec-08ddea985052 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 03:16:45.9929 (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: xyNyFMEX1xrggic0KJ5BWGJ18BA/wRhOZ8tmllqerpPhDFdcCtg/tfwx1eDRrmW8CB6egn5lN08gMBZsn0CSAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6232 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjgsIDIw MjUgODo1MCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD YzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRy ZXcuY29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp eC5jb20+Ow0KPiBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9y emVsLCBNaWNoYWwNCj4gPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVuIEdyYWxsIDxqdWxp ZW5AeGVuLm9yZz47IFN0ZWZhbm8gU3RhYmVsbGluaQ0KPiA8c3N0YWJlbGxpbmlAa2VybmVsLm9y Zz47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENI IHY4IDEvOF0geGVuL2NwdWZyZXE6IGludHJvZHVjZSBuZXcgc3ViLWh5cGVyY2FsbCB0byBwcm9w YWdhdGUNCj4gQ1BQQyBkYXRhDQo+DQo+IE9uIDI4LjA4LjIwMjUgMTI6MDIsIFBlbm55IFpoZW5n IHdyb3RlOg0KPiA+IEBAIC02OTMsNiArNjk5LDEyMCBAQCBpbnQgYWNwaV9zZXRfcGRjX2JpdHMo dW5zaWduZWQgaW50IGFjcGlfaWQsDQo+IFhFTl9HVUVTVF9IQU5ETEUodWludDMyKSBwZGMpDQo+ ID4gICAgICByZXR1cm4gcmV0Ow0KPiA+ICB9DQo+ID4NCj4gPiArc3RhdGljIHZvaWQgcHJpbnRf Q1BQQyhjb25zdCBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjICpjcHBjX2RhdGEpIHsNCj4gPiAr ICAgIHByaW50aygiXHRfQ1BDOiBoaWdoZXN0X3BlcmY9JXUsIGxvd2VzdF9wZXJmPSV1LCAiDQo+ ID4gKyAgICAgICAgICAgIm5vbWluYWxfcGVyZj0ldSwgbG93ZXN0X25vbmxpbmVhcl9wZXJmPSV1 LCAiDQo+ID4gKyAgICAgICAgICAgIm5vbWluYWxfbWh6PSV1TUh6LCBsb3dlc3RfbWh6PSV1TUh6 XG4iLA0KPiA+ICsgICAgICAgICAgIGNwcGNfZGF0YS0+Y3BjLmhpZ2hlc3RfcGVyZiwgY3BwY19k YXRhLT5jcGMubG93ZXN0X3BlcmYsDQo+ID4gKyAgICAgICAgICAgY3BwY19kYXRhLT5jcGMubm9t aW5hbF9wZXJmLCBjcHBjX2RhdGEtPmNwYy5sb3dlc3Rfbm9ubGluZWFyX3BlcmYsDQo+ID4gKyAg ICAgICAgICAgY3BwY19kYXRhLT5jcGMubm9taW5hbF9taHosIGNwcGNfZGF0YS0+Y3BjLmxvd2Vz dF9taHopOyB9DQo+ID4gKw0KPiA+ICtpbnQgc2V0X2NwcGNfcG1pbmZvKHVuc2lnbmVkIGludCBh Y3BpX2lkLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCB4ZW5fcHJvY2Vz c29yX2NwcGMgKmNwcGNfZGF0YSkgew0KPiA+ICsgICAgaW50IHJldCA9IDAsIGNwdWlkOw0KPg0K PiBFY2xhaXIgZG9lc24ndCBsaWtlIHRoaXM6DQo+DQo+IFJlcG9ydHMgZm9yIHNlcnZpY2UgTUMz QTIuUjUuMw0KPg0KPiBzZXJ2aWNlIE1DM0EyLlI1LjM6IChyZXF1aXJlZCkgQW4gaWRlbnRpZmll ciBkZWNsYXJlZCBpbiBhbiBpbm5lciBzY29wZSBzaGFsbCBub3QNCj4gaGlkZSBhbiBpZGVudGlm aWVyIGRlY2xhcmVkIGluIGFuIG91dGVyIHNjb3BlICgxIG9mIDEgdmlvbGF0aW9uKQ0KPg0KPiAg dmlvbGF0aW9uIGZvciBNQzNBMi5SNS4zIHVudGFnZ2VkDQo+IHhlbi9hcmNoL3g4Ni9pbmNsdWRl L2FzbS9wcm9jZXNzb3IuaDoxMzAuMjAtMTMwLjI0Og0KPiBub24tY29tcGxpYW50IGZ1bmN0aW9u IGBjcHVpZCh1bnNpZ25lZCwgdW5zaWduZWQqLCB1bnNpZ25lZCosIHVuc2lnbmVkKiwNCj4gdW5z aWduZWQqKScgKHVuaXQgYHhlbi9kcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcS5jJyB3aXRoIHRhcmdl dA0KPiBgeGVuL2RyaXZlcnMvY3B1ZnJlcS8uY3B1ZnJlcS5vLnRtcCcpOiB0aGVyZSBpcyBhbm90 aGVyIGlkZW50aWZpZXIgYGNwdWlkJw0KPiB4ZW4vZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEuYzo3 MjYuMTgtNzI2LjIyOg0KPiBub24tY29tcGxpYW50IGxvY2FsIHZhcmlhYmxlIGBjcHVpZCc6IHRo ZXJlIGlzIGFub3RoZXIgaWRlbnRpZmllciBgY3B1aWQnDQo+DQo+IEknbSBmaXhpbmcgdGhpcyB1 cCBmb3IgeW91LCBidXQgSSBoYXZlIHRvIGFkbWl0IHRoYXQgSSdtIGdldHRpbmcgdGlyZWQgb2Yg ZG9pbmcgc3VjaA0KPiBjbGVhbnVwcyBmb3Igc3VwcG9zZWRseS1yZWFkeS10by1jb21taXQgcGF0 Y2hlcy4NCj4NCg0KU28gc29ycnkuIEkgd2FzIG1pc3Npbmcgc3VjaCBtaXNyYSBDSSBpbiBvdXIg aW50ZXJuYWwuIEknbGwgYWRkIGl0IHRvIGF2b2lkIHN1Y2ggZXJyb3JzDQoNCj4gSmFuDQo= From xen-devel-bounces@lists.xenproject.org Wed Sep 03 04:31:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 04:31:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107799.1458037 (Exim 4.92) (envelope-from ) id 1utf9f-0004vI-M2; Wed, 03 Sep 2025 04:31:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107799.1458037; Wed, 03 Sep 2025 04: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 1utf9f-0004vB-HN; Wed, 03 Sep 2025 04:31:31 +0000 Received: by outflank-mailman (input) for mailman id 1107799; Wed, 03 Sep 2025 04:31:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utf9e-0004uK-FR for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 04:31:30 +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 dc0960de-887e-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 06:31:29 +0200 (CEST) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-55f76277413so3640335e87.3 for ; Tue, 02 Sep 2025 21:31: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: dc0960de-887e-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756873888; x=1757478688; 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=u+Rjp4rWjiJ+Q8/JHFJO/pL8imA5SGgCabIA2HZVHGA=; b=EoOyWjB33ywdtONVnm8uHK3M2jkFn9J4rVgTC8qlV+Dlu4ETJppJKMZPDsQWhhsqYD hC2/h0PL/HKZgevu4ifrrcwJbsIa2bemvNqST5ox0rz+fIrhvW80z0cQUxAoLr2FDaDT ibgMF/hoFIff0anVh3zvKDs3YSvTy9Pxd47L60SqXe/y6tG0eG4RtPb2NaWQtoaGHcqY 716EWJ2DWmrldUXszIOcsiO1UwP3kqQ7dFW1zNcBmxjZ1bGH+XRH4Lxqb/MpaOo33m61 EwXZz9+HwHBaNZ2mxcwS0GztiQPV49/RIzzhQ/kNkpeRk7ulrcGQZp/GgJwZZHMuk7Fd lD/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756873888; x=1757478688; 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=u+Rjp4rWjiJ+Q8/JHFJO/pL8imA5SGgCabIA2HZVHGA=; b=cphnCseHWplZLW/ng3Vuiw1Xsc3sqPZO+uiAICPbg966DIBXy7OegzRNGdthprEFkW omA8FXXtwfSDzdrNynV7dde+mOnwhAagmXQ69FXsYzvnhASEMYBdlkPQ1hgW0UIPvgjm Mql57PIB5L5cMX7aC5taFHSWLDccvh//XRjppkTx4VegzowiGSV30GvEQP51bulmPcec BssatCXH/s/hjVi28U+YnP1+JJ+2wgQMYE3oyY3xxpjjH+1bB5DXoXGb/qc/VdV9jaFj LJnpIfiCqPPZAD5yowuSmAZwAJuXuNkzArjhxw632hrs2cjB1+ezYqBeknmu/oacyJDB TRdA== X-Forwarded-Encrypted: i=1; AJvYcCVHRBEJPXOh29LVZWHSU7d6CyFCmCgUjWGq0atGcmjNM3MoIq+yYQ0p/hQXcab2iRvcsjABn2ctN70=@lists.xenproject.org X-Gm-Message-State: AOJu0YwKs+aBui8lANp9YT/V75k0s7DvmVtYac9B8Yh2goRudxThrtCJ +PK+AgfQdPU5m69GzH8iosCXdLksQ+gmevbMiGPBJb+bW1D4jRilUpLaGfV3cWPJZbv3EYnViO9 XetCPrq/SPzl/mfbHcFhSZ8ecorHWH/Q= X-Gm-Gg: ASbGncsJiAoE1SnH7mDarpi36UESRupneJlXyHDWbpg1MJN83Ajbz6e4UyI2Hy7zgqD ltBqIJE55xImA2rx3RdK3ZZjQZb3vPhgWIvexE6itnqLX/A1RMF0QYi/wKV92TTHsmvaDxQxxeH CDP8lwh1w4EdqSbfXjPfX6ixaHeU+naziIFr7M2q4/Aap4ihqLy9nixlAAdIMrMQJY0Y75VGKDh jtBFA== X-Google-Smtp-Source: AGHT+IHN97zOfoCsiDh3Day+a7KPX+vUMz/KuF5ILvLwaWX7knBDMp9vLusF2oScPw2vAXr5xjBghQI7dmrC3vkTZtQ= X-Received: by 2002:a05:6512:6413:b0:55f:6c72:b727 with SMTP id 2adb3069b0e04-55f708bd284mr4050407e87.24.1756873887841; Tue, 02 Sep 2025 21:31:27 -0700 (PDT) MIME-Version: 1.0 References: <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com> In-Reply-To: From: Mykola Kvach Date: Wed, 3 Sep 2025 07:31:16 +0300 X-Gm-Features: Ac12FXxau6q0TYBp03hKV00QoaC7vg2bhz_LEL_NPctGEJV5GPha06RoSYe8lho Message-ID: Subject: Re: [PATCH v6 11/13] 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?= , Saeed Nowshadi , Mykyta Poturai , Mykola Kvach , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, On Tue, Sep 2, 2025 at 5:33=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2025 00:10, Mykola Kvach wrote: > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -1317,7 +1317,11 @@ int domain_shutdown(struct domain *d, u8 reason) > > d->shutdown_code =3D reason; > > reason =3D d->shutdown_code; > > > > +#if defined(CONFIG_SYSTEM_SUSPEND) && defined(CONFIG_ARM) > > + if ( reason !=3D SHUTDOWN_suspend && is_hardware_domain(d) ) > > +#else > > if ( is_hardware_domain(d) ) > > +#endif > > hwdom_shutdown(reason); > > I still don't follow why Arm-specific code needs to live here. If this > can't be properly abstracted, then at the very least I'd expect some > code comment here, or at the very, very least something in the descriptio= n. Looks like I missed your comment about this in the previous version of the patch series. > > From looking at hwdom_shutdown() I get the impression that it doesn't > expect to be called with SHUTDOWN_suspend, yet then the question is why w= e > make it into domain_shutdown() with that reason code. Thank you for the question, it is a good one. Thinking about it, with the current implementation (i.e. when the HW domain requests system suspend), we don't really need to call domain_shutdown(). It would be enough to pause the last running vCPU (the current one) just to make sure that we don't return control to the domain after exiting from the hvc trap on the PSCI SYSTEM_SUSPEND command. We also need to set shutting_down to ensure that any asynchronous code or timer callbacks behave properly during suspend (i.e. skip their normal actions). However, if we consider a setup with two separate domains -- one control an= d one HW -- where the control domain makes the final decision about system suspend, then we would need to call __domain_finalise_shutdown() during the HW domain suspend in order to notify the control domain that the HW domain state has changed. The control domain would then check this state and call system suspend for itself after confirming that all other domains are in a suspended state. I already added a TODO about moving this logic to the control domain. So, a= t first sight (unless I am missing something), we can avoid extra modificatio= ns inside domain_shutdown() and simply avoid calling it in case of HW domain. > > Jan Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 03 05:34:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 05:34:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107821.1458046 (Exim 4.92) (envelope-from ) id 1utg8r-00043r-0P; Wed, 03 Sep 2025 05:34:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107821.1458046; Wed, 03 Sep 2025 05:34: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 1utg8q-00043k-U5; Wed, 03 Sep 2025 05:34:44 +0000 Received: by outflank-mailman (input) for mailman id 1107821; Wed, 03 Sep 2025 05:34: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 1utg8p-00043e-K7 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 05:34: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 b0cf37fc-8887-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 07:34: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 261BB60233; Wed, 3 Sep 2025 05:34:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38633C4CEF0; Wed, 3 Sep 2025 05:34: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: b0cf37fc-8887-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1756877680; bh=Dn99J/wNZcQ8cjepOF0bFowzIyB5iiQnDIx6F1w1350=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JLdgKnf5mpupjTIzrlpoUb9vBvABQUmYezdlPzitP7YFyCk6mKabo0tptyM9Z8Cp/ 8zTiAEwLD2fC3QO2iLBH2KDtxKucr8yG14D+61M8YdSzf20lmBjTppCTWTZk+ejkoQ exY7fWqTAQckpsxBk5+JhJhIjyKhjYu2AFSECO3o= Date: Wed, 3 Sep 2025 07:34:37 +0200 From: Greg Kroah-Hartman To: Teddy Astie Cc: xen-devel@lists.xenproject.org, stable@vger.kernel.org, Juergen Gross , kernel test robot , Boris Ostrovsky , Stefano Stabellini , Anthoine Bourgeois , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Jiri Slaby Subject: Re: [PATCH v5.10.y] xen: replace xen_remap() with memremap() Message-ID: <2025090335-operating-antarctic-39f7@gregkh> References: <4cc9c1f583fb4bfca02ff7050b9b01cb9abb7e7f.1756803599.git.teddy.astie@vates.tech> <2025090203-clothes-bullish-a21f@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Sep 02, 2025 at 04:24:33PM +0000, Teddy Astie wrote: > Le 02/09/2025 13:18, Greg Kroah-Hartman a crit: > > On Tue, Sep 02, 2025 at 09:28:32AM +0000, Teddy Astie wrote: > >> From: Juergen Gross > >> > >> From: Juergen Gross > >> > >> [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] > >> > >> xen_remap() is used to establish mappings for frames not under direct > >> control of the kernel: for Xenstore and console ring pages, and for > >> grant pages of non-PV guests. > >> > >> Today xen_remap() is defined to use ioremap() on x86 (doing uncached > >> mappings), and ioremap_cache() on Arm (doing cached mappings). > >> > >> Uncached mappings for those use cases are bad for performance, so they > >> should be avoided if possible. As all use cases of xen_remap() don't > >> require uncached mappings (the mapped area is always physical RAM), > >> a mapping using the standard WB cache mode is fine. > >> > >> As sparse is flagging some of the xen_remap() use cases to be not > >> appropriate for iomem(), as the result is not annotated with the > >> __iomem modifier, eliminate xen_remap() completely and replace all > >> use cases with memremap() specifying the MEMREMAP_WB caching mode. > >> > >> xen_unmap() can be replaced with memunmap(). > >> > >> Reported-by: kernel test robot > >> Signed-off-by: Juergen Gross > >> Reviewed-by: Boris Ostrovsky > >> Acked-by: Stefano Stabellini > >> Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com > >> Signed-off-by: Juergen Gross > >> Signed-off-by: Teddy Astie [backport to 5.10.y] > >> --- > > > > Why is this needed for 5.10.y at all? What bug does it fix? And why > > are you still using Xen on a 5.10.y kernel? What prevents you from > > moving to a newer one? > > > > This patch is only useful for virtual machines (DomU) that runs this > Linux version (a notable Linux distribution with this kernel branch is > Debian 11); it's not useful for Dom0 kernels. > > On AMD platforms (and future Intel ones with TME); this patch along with > [1] makes the caching attribute for access as WB instead of falling back > to UC due to ioremap (within xen_remap) being used improving the > performance as explained in the commit. So this is only a performance improvement? One that people have not noticed in over 3 years? That does not feel like a real bugfix that stable kernels should have to me. Again, what is preventing you from just running 5.15.y in your system instead? Debian 11 is quite old as well, why not use Debian 13 or 12? You only have one more year left of 5.10.y kernels so you need to consider moving off of that as soon as possible. thanks, greg k-h From xen-devel-bounces@lists.xenproject.org Wed Sep 03 06:22:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 06:22:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107851.1458056 (Exim 4.92) (envelope-from ) id 1utgsR-0001jM-Bt; Wed, 03 Sep 2025 06:21:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107851.1458056; Wed, 03 Sep 2025 06:21:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utgsR-0001jF-9M; Wed, 03 Sep 2025 06:21:51 +0000 Received: by outflank-mailman (input) for mailman id 1107851; Wed, 03 Sep 2025 06:21: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 1utgsQ-0001j9-1j for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 06:21:50 +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 45c1c295-888e-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 08:21:48 +0200 (CEST) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-61cd6089262so10066313a12.3 for ; Tue, 02 Sep 2025 23:21: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 a640c23a62f3a-b046d0b0135sm47982166b.73.2025.09.02.23.21.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 23:21: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: 45c1c295-888e-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756880508; x=1757485308; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XDD+zinFCR/GJ/2qAAr07f5TR6VDEBBRawRGHwaUeyA=; b=dTLdvMCon1sgZXhfWlsW4AMAJ2WJY6KlBfNAkkJB4aBWFaMb86B9MYcFv/6skv10zs ycXBogx29T4Tf/Z1RvO5H6o+j2gvT8+5I7UH1a3CLOhJiHEnrjMWbHIajPMnCmbXzbuC 01f/io8mmDJWAX8rMrul/QrgH3EWc4xzsATUTigb5q/bD4h1L0KBGo7s6MHenRddPqyg I6lEZ23BAtcyEYh4ynEgMdGMw3fbLPnpMStAoVo7uH7Z1uT1uymrjnoEB24n5u8qw4V4 t1/n+Okp9ieX3l6SLQsHsp2plUhOVy8TQNtDZofiWVkGMdiJDJwTdg9ntChs4HAnJEnT 8Vbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756880508; x=1757485308; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XDD+zinFCR/GJ/2qAAr07f5TR6VDEBBRawRGHwaUeyA=; b=bHtJhGyhHbll0UzHbwbEzxdW9FVwGo5nywk4dnpaen6Rr1sJJw3dzv6lkMeCu3atnn FXPnqx/zDUO0OkCyspnQSP7sRqiM1LJHLOwvDqcWIjb4ipw+jgCWWoc/xohp21Zcl79G 8AQRohQahnXKGvFE+Plb9RzGTL934nGOwblXyshfHScC1mxHQ94F0joWRWnv3/t8zjkU IqrSpop93AroC4TS2DcCKRal40HgZJ1Xri/Zr2GSBeZo/dR8GOtZ3iPZ1haWpHLa7c7f PNJv+FYA9L+law0sxahCOTE6jMlJrjyQ46w2HMcbMfyILF4RzUA6jw+gUyCaa+BWrjCB +VZA== X-Forwarded-Encrypted: i=1; AJvYcCUdnmj4D6kC9dkhSq3DzkSViXFI/ECcdLoHIYCYpdhU2XtAt85o/g9f+CSHJCG9pJCZ37s4Es+pYng=@lists.xenproject.org X-Gm-Message-State: AOJu0YxrylR8JCe/7z1Bo9Y9VGWdzSeWSt0NTbV2IcsWBawQHn4smGwt ZwaIONs6nhhnurmFMhh6n1et8AaiziBxJXvBsvIsXFoGOCgPYuL2Blw+pjfrQHkubw== X-Gm-Gg: ASbGnctxAZTLs/x7FdG+n+E9tCq250Nyc4R2rCDsG2FIbYaKP7Kpjrh34g2uZ9XNDke kItPYyImDHWDMTrhhra+ggKQKnnF2m/cHWUO5cyxDBRRMUfQKlWpGV3Pqqq8JIRj1Xj2t/Q87mU Eh6PJHnfl0j+Rm354iCPxe/LeSFPUnCFI15lu3EaVR7MUDlTBjVdSKlLljI+rvFo5z2Ja0jQ6mv NjcC9txu3xnbzy5v99QtrDTaKA7Pp+XuEzj84lZy0c0Ejcn6UbKoZH1cAjrWBAiJhvY8MbZOB/Z YEp/nxl+mTPjw5YiQ9Ke1D9dpJzOe0bcVOOIClHvIQpjHCPlEfxwdQjspum+Xgx1EKZg+IPfoWA rf/7gKyPR9j5BUOMLeK/7N7cFvRYDgE6MeWjwGCFKNGwcO/jf5dDjqEGfPG2ne4SMZkgNhpDGID Ts1DM1Kng= X-Google-Smtp-Source: AGHT+IGisr709yiLWCKKGkboVJOkM5UDKnoJjgyIamiQPhA3FJKk5Gdr38XUiOlwcvNj+Sy6TUBkFA== X-Received: by 2002:a17:907:3f9e:b0:b04:299d:53ab with SMTP id a640c23a62f3a-b04299d590cmr938789166b.37.1756880508090; Tue, 02 Sep 2025 23:21:48 -0700 (PDT) Message-ID: <7ec5e23e-2415-41b7-ab3e-7b0a7007bd1f@suse.com> Date: Wed, 3 Sep 2025 08:21:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver To: "Penny, Zheng" Cc: "Huang, Ray" , Anthony PERARD , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" , Jason Andryuk References: <20250828100601.1777197-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.09.2025 05:14, Penny, Zheng wrote: > [Public] > >> -----Original Message----- >> From: Jan Beulich >> Sent: Thursday, August 28, 2025 7:07 PM >> To: Penny, Zheng >> Cc: Huang, Ray ; Anthony PERARD >> ; Andrew Cooper ; >> Roger Pau Monné ; xen-devel@lists.xenproject.org >> Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC >> xen_sysctl_pm_op for amd-cppc driver >> >> On 28.08.2025 12:06, Penny Zheng wrote: >>> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op >> *op) >>> else >>> strlcpy(op->u.get_para.scaling_driver, "Unknown", >>> CPUFREQ_NAME_LEN); >>> >>> + /* >>> + * In CPPC active mode, we are borrowing governor field to indicate >>> + * policy info. >>> + */ >>> + 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); >> >> Isn't pulling this ... >> >>> if ( !cpufreq_is_governorless(op->cpuid) ) >>> { >>> if ( !(scaling_available_governors = >> >> ... out of this if()'s body going to affect HWP? It's not clear to me whether that would >> be entirely benign. > > HWP has its own unique "hwp" governor. So, imo, it may not affect. How does it matter what (unique or not) governor it uses? The relevant aspect (to me) is the !cpufreq_is_governorless() check that previously guarded the copying of the name. (It would be another thing if this was benign to HWP, but such would need clarifying in the description. Cc-ing Jason just in case.) Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 03 06:47:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 06:47:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107869.1458067 (Exim 4.92) (envelope-from ) id 1uthGc-0004cC-8d; Wed, 03 Sep 2025 06:46:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107869.1458067; Wed, 03 Sep 2025 06:46: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 1uthGc-0004c5-5r; Wed, 03 Sep 2025 06:46:50 +0000 Received: by outflank-mailman (input) for mailman id 1107869; Wed, 03 Sep 2025 06:46: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 1uthGa-0004bz-7v for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 06:46:48 +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 bff887ae-8891-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 08:46:43 +0200 (CEST) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by CH2PR12MB4229.namprd12.prod.outlook.com (2603:10b6:610:a5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.16; Wed, 3 Sep 2025 06:46:40 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d%7]) with mapi id 15.20.9052.019; Wed, 3 Sep 2025 06:46: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: bff887ae-8891-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BIYq2OW5mV/GkYcNzIEzxpIBXnFqCbAAcWUAOiF+eDXSWyCC08quilTHs9qdXdx38Pfjue6hbV9Bcdo71oRGHdOjD/yKNYvccDCw+tIdi+pw2AaxEGc/q5TJr24EnVrA44K7zIv89SulsIBMCBJ2UafCnSjZzRTqla/xaXHM6vvwA+VuPlB4NE2T5lAk4iPHdRiVN98vZpdltTENwogz8Tw5QkF3cTC2PxsiCiE2nAXt5Drzv9JK0ekUyQ26pl+zw9vld5j9udY2dFonjYKeeoYOPd2tIHJJqoWdkLrcRbSK/72XJkQ4CmK8XejpFWr0emT61pahFBMpUEHkY2PbmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g+bmyhh5rFnQXPoR57LllCgtHVYqY+F3Q8Ycl/WVPUU=; b=B23K2ZuurWYZf9Kmupazu1SyJ9lfJHcUyGb0miM5zAEI/lXg/Ut81xzZRmjKRIdOMBOtGz1pCtHsZys6TXBFwWr3gQvYR/ZlfLwKiryIi6/dEBF5BElQLk6gOZ9oOss8hu9ZSpheQIe3TP9W+LaNdOeuoRly8c23qo5WxuiF6aFFRHW2EBkH2lkFO+VLfa3jPlpDzhrdJ5fuMCVWP6v2U75zBV9NvxhZZvg6HjFXSHjURCgxFbLqKNoN9T68cU7HcAGbxWalnWETVNQaIVfw8RJCTFbFSLYJ8GSum5YkrpF7A8N4UjUIAXd186vuNH18g3WYZVGt9yU+bSrIYRDV5A== 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=g+bmyhh5rFnQXPoR57LllCgtHVYqY+F3Q8Ycl/WVPUU=; b=beGzoOPe2FigZnOeZ55+rEtb9yXTGe5dwyNs246vv+s6SI7QjHOK0yzCcSM4281lkGKdDQX4/fGfdoDFX8mj0vqzHMDIkE/0NLqkvcwGfeSidk9T9NQ+bvfnlSgH9M0D7F3aEtIyKhYExOu27/5d3kiGmmUkzceGI6XA1fNqhLM= From: "Penny, Zheng" To: Jan Beulich CC: "Huang, Ray" , Anthony PERARD , Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "xen-devel@lists.xenproject.org" , "Andryuk, Jason" Subject: RE: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver Thread-Topic: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver Thread-Index: AQHcGANplGdEMGicVkezx0Fs9samVLR357kAgAjockCAADXaAIAABi1w Date: Wed, 3 Sep 2025 06:46:39 +0000 Message-ID: References: <20250828100601.1777197-1-Penny.Zheng@amd.com> <7ec5e23e-2415-41b7-ab3e-7b0a7007bd1f@suse.com> In-Reply-To: <7ec5e23e-2415-41b7-ab3e-7b0a7007bd1f@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-09-03T06:46:30.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_|CH2PR12MB4229:EE_ x-ms-office365-filtering-correlation-id: f059fcb0-0a65-46b6-56eb-08ddeab5a2e0 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?eWVhN0xmQ3lOZXFwc0daTk1IdVg5U2paYWMwSnQrN2xPVWhNYWs5QlBDN3hN?= =?utf-8?B?OE9lOEVZUWxQODhSTHVtOFFHMlJGZWFPb1c5VXp3TmtLQTVqd2NBQ0daNjVw?= =?utf-8?B?TnVXeURlc0xvcmszb0NNci9QdHlkNU1md1VlbkxFeG8vT2Z4eXVlYjZvM3N0?= =?utf-8?B?Z21uMjl6d25rUDdiZHRNQXlCZkFhM2x6Q2JVRGg2cE9hd2ZNRjBOdkJXT0JG?= =?utf-8?B?VDZnc2xkUWF1Z1RZMmxEa3dicVRLU2dXeVZLenM1K1lJYVZiWWZpTWhWU3Fk?= =?utf-8?B?cnFiK01EUG1CUzhJY0U5VFo3eDNtSDNPUFpJY2FncUUwc0RMbkdjOWdTWnMv?= =?utf-8?B?bm1JTzlWb2pDajl1cE05NmJqU3lpbHJrVlU1VWVzWElzTmdjckhsVjJydUxj?= =?utf-8?B?VEg4UWdiaURoV0lCRlVqOUY2aHpaeFhkUFZZekRobGk2b0VIcktQVDdNQXln?= =?utf-8?B?ckxIcFpSSUNlMmhYa3h1S2dPMEM3dVdPNER2S2VuN0hCb2ZrL0ZKTUFweEZk?= =?utf-8?B?ZHpSZnlySlA3aDJSQ0hVa2hHekZ4T3NHeFVPcEhIeW1jQ29Da2xKd0dlRzV0?= =?utf-8?B?T3ErT2V5YUJzdFd5cko0TGtrL0xiRFI4YlFlYktvbncxcHFlWU1mT2xkMnhl?= =?utf-8?B?NDNSY2JuWkNPRTU3RmUvVFBWSWltWnlwT1IreDZPR29HWHM4cEVvOG02K0k5?= =?utf-8?B?Zi9jSUphUU01TXRBVUlSaWxqNjlHaHRRNXNHYW9JMVhpZmFOaE55YkFDc3lI?= =?utf-8?B?LzVUanpEYWdGWUNpd0tjdG41eS81VnRrWG5XVFRiOGJ1SGNwL1ZSenpMdlFG?= =?utf-8?B?MXQwemFMZUJybDl3cS9PUXhObERPR3ZSbjFSUUhTcmN3TXd3MTlYcEZrK0Vw?= =?utf-8?B?R0hPNXRtT2loZmZlYWJtYythbG1PK3RQVWZJdjgwOUJESVhoSi9PQXYreDVR?= =?utf-8?B?ZmROMnV4V1g4NXQ1b1RLQ2NiKzJYQ3hrVXdMeURWU01lVmlPVkJkSytsa2dG?= =?utf-8?B?d1lDQ0tjSmRIUGQ0U3dQV0ZodmVLaWhRVjZzUmg0NVdjc3FXSUZRTmxJdVVX?= =?utf-8?B?R0ZmeUJGMDBMbStRU3B0eUhJeUpnS0xGSzB1ODVRQVZDaFkvQ1F1SldWbUlk?= =?utf-8?B?Y09aTE5Vb3FFQTdsMzhvbEcwaVE3T1k0NjIrclJqSGRGb0x0UmJLYjlOblMr?= =?utf-8?B?aXRMWXRrbFdqMXV2VElRcEJvMmRlbHMwUVFuK1Y2UVVPY0JOMjNJOHZidGFk?= =?utf-8?B?dXdzN3JJYXBiUFZ3RU44TEp4VG5LWjZVcitYbkNUamhiUDJ0bHJhODZ4a1Zh?= =?utf-8?B?MmJVTEc0SThqQk45c2MydmZxU25wTmxLbVAxMy8xQ3M2TGNmZHJNZTQ2QzZO?= =?utf-8?B?T3pETUdkcXEwS1BuS3ZTOFdqQzJTMENlci9jVUcyTjE3N3N4L0NyQUxQYmF2?= =?utf-8?B?Z09oNG91NUJ5cmN2ODBJdkRrdmo1MHBBdFA2eE9idlBhWDhUQ3lyT2pOb0Y0?= =?utf-8?B?dlFpZ2U5aXZKZ0JzRVpscmFZOFN1bkFDVkFKelBIRGhXbEZ4NGVJR29PR2Np?= =?utf-8?B?bFg1U0E2TVJUYzdIdGFraHQwOVFhSEc0L1F3UDJoNEkvNHVKQnhiYXZtZ1ho?= =?utf-8?B?Rk5oZkYrZ2V5QTJqd2x0T2NwREpmQWtYVTNsWng3c0l2TUFQWUFycGlNRHhz?= =?utf-8?B?TTJ0aVI0TzczUmo1ZlJPNURBNnBEdHpMQVdrREkzNmZjNWQ3Y0E0VDlOWlNM?= =?utf-8?B?d1V4cEJJRUIrTm16SnJobnJ4VSs3UUlsVm13czNOazVRamdIZUhKa0pqZmJD?= =?utf-8?B?cm9TRmttQm1LMnBna0dycWZ5MmtEZ2prUVhjNjJtYVgrNmowNTEyL2F5M3kr?= =?utf-8?B?K2RZdjc4Y0pCVXo1bXgxOXlwMGROVmV3djlNWFdjMVJnYks3dEdNbERWZGIx?= =?utf-8?B?eEtFLzhtZWcrU25mN1N0bWE4dlNCb3VRRjVENzhMRmJpQ1F5UVN6YTNHa2Rt?= =?utf-8?Q?mChscxSelcnLY41UXL9fwNEkFOaRPQ=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?d0xOZlNtQ2g0VWF2VUt2dldEZ0lSSWlPSTcvbE1zZkQ2UE9sTzJVQ3dGZTV1?= =?utf-8?B?SWpVV1FUdUhTaUJPbmhvK0xJNTNKaWJJb2p6aWM5R0tzdVl4NWhMbG1VRU9k?= =?utf-8?B?TW1WbDN2TkltK2VWSUFFVmw0Z3hURGpIWkRULzBraHh4eWZNSEJwa1ZMdCtK?= =?utf-8?B?V3ZNQzhWdzgwRHRUb3JtdW5OYVZ2Q3RwWXlFVTV0eWl2M0xSUzN5M3pnTGJa?= =?utf-8?B?VUxCcE4vOHlLajBKeDBtWkYza2JqMW9qSHUremlPcHp4QUFZb2l3czd5UGR1?= =?utf-8?B?VENXUXlLcCtZWjQ3ZWEwM0tSM3F1QlVCNWRFM2R4Rm9PaElMMFZPZ2ZkNzVS?= =?utf-8?B?bWh2eTBFYzlGOTF3S2UrcFhnN2FsV08rSUpyU0YyWmVGQzYxMW9EcStERHNI?= =?utf-8?B?RTQwZG9kM3NoTWF3cUprU2pQaEdGMUZYSjVWb3FKdnZmaWVZMWtHakd1SEpD?= =?utf-8?B?ZjF1andyYWxLVU1mVVkvSm5tS1VKTkVDNjlSVlF0dmNFK0J3S3BJRzNRV3Va?= =?utf-8?B?TW13c3ZxMWxGVDk4cElmU1RhVm5VbnBkSUlpMWJxWFdzcE14dzJMbFlJOElP?= =?utf-8?B?UGp1Qm44bHZUeGRLYTlYZDN6MjJuYk5JN0pmYWt0U2xaU3pBQVRPVGpuSEw1?= =?utf-8?B?Rlhzc0lCSWdpNHNEWFFSMkpZdm1OQ29iZEVVak85QWZLRXZNdlRmWHdiYlVu?= =?utf-8?B?QmdxNVRuL1NTdy9mQXN2NlZSOWYrbTJOa05CTzgzWEZlUmNuNTg0NnllSWJS?= =?utf-8?B?bVB4Wm1UbWM2ZzRqRFpjOElPdzN1eENRZDgxbkxybzJQSkRaK0hTOUFaQTFE?= =?utf-8?B?L1NoemtsVmM0TWhEWW93Nmc1d0FuZVVkY3RPN0doemE4SitSSy9MZGQ4QW81?= =?utf-8?B?Um4vQnFaYWFwMXh5bGxHRWJvNlpGTFQ3RWhJVGNVSEljK0lvL1pnNjVreUFS?= =?utf-8?B?OXY5MGxYMmUxTWdlYXlNanpzdnFNK0lsejdCZTlGUDNzU3FKV1p6NnF0Qlo5?= =?utf-8?B?TmFEeVNFUGROZVN4T29QeFc3VHdEMGJnWWhsdkNVeFBjOVE0TFkxNWhXVnBB?= =?utf-8?B?aXdjUy92N3pkaVUrc0VlT0Q2RkpGUGNCR1h5bmRJQ1ZJNzNISmlhTGJPMTlE?= =?utf-8?B?dFJ2U3FuVklDQ3VGTlZZQnZEdkl1TFFQa2lPREY4WndrTmRMc05vTlJJV0U5?= =?utf-8?B?amRKYk9DR2xGRm80c0pVYUI2WVFiZHErYUV6NjBQZVBOU1RodVhENTZaM0JR?= =?utf-8?B?Rmk3eElpc0hNbVViWDdBUVZMTjNCLzBockNvZWF5OFNGanYrNkFQZlR1WVFZ?= =?utf-8?B?NWZTalpmWTM4bHRVQnZiSHVVVm8rTmpWZ0tsaVVnVDQvY25LSmpDZmo4cjYv?= =?utf-8?B?MStDUkZZZDRqZllxTURVeEJub1RFWHp1SFNZVDl4TTMyMXhOZDExeFNMZ0RQ?= =?utf-8?B?SGswSit2bktzY3JKNUVnY1k2dkJtdlU4VXFmU0E4SG5UVDFuR3EwYXQ4OGFE?= =?utf-8?B?cDZxSGRiTE5tdlZOOUlSRE96bDdEYUF2Wi92WHJFZkY4Z2ZjelRmcEhIZGRa?= =?utf-8?B?UjRucFN0eGpNczhOTVVwUHJ6VUZ2RU04b0dUVmRGVXJma1NIOGlDelhhUktU?= =?utf-8?B?WkQ3VEljNU9QOG9jcG1yUnNkWkVZT1Jya0ErMUN5WkRNNFZaOFZUME1qc0lK?= =?utf-8?B?K1NCSVhjK05uYVZiSnU0dkU2MTE5T002dVVHVzRhMzVuTTd0ZFNmcTlhdHFJ?= =?utf-8?B?bnpUT21qampWWk1LVjRaNit1eWJweDh3c09YZUZjUDdvYkVYMHZtZlhNS3RB?= =?utf-8?B?b2ZRRGR3YU55TWpaS0gvV3FwUWJYZU1hT1l4K1hmYk15bE14Tmd1OHlwenNK?= =?utf-8?B?TE1mRG4zWStHa09lbjFpWVFaS1pQT05yUGIyTGg3WUxvOE13d2xIZ2h2cits?= =?utf-8?B?cXN4Y2tlSzBDSjFpWHlPbnMvdEZlQ3MycmdiUiswQVQ4WkEvcE5IUUhyZktU?= =?utf-8?B?L0p0SDZ6NTd6Q2xyUVEyM05jTUk4NVhKeWxCZ0xtTGtwRnY1UjIyL1VOTXBm?= =?utf-8?B?RGdvTWM2NnM0dExQekpGbXN0NjdvQkRyK0VXQVRaditUb2NLbnVlYzJzMTY4?= =?utf-8?Q?6ZPA=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: f059fcb0-0a65-46b6-56eb-08ddeab5a2e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 06:46:39.8821 (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: ZH0upONjrG9nu3DPz+t1yTeePKbsi+QxXuQQFp/euxxkJ3yuv+Wryhz2jIoxcOyTpdiquHBjyIqcomE6qgwWqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4229 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDMs IDIwMjUgMjoyMiBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbnRob255IFBFUkFSRA0KPiA8 YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz QGNpdHJpeC5jb20+Ow0KPiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47 IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsNCj4gQW5kcnl1aywgSmFzb24gPEphc29u LkFuZHJ5dWtAYW1kLmNvbT4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OCA4LzhdIHhlbi9jcHVm cmVxOiBBZGFwdCBTRVQvR0VUX0NQVUZSRVFfQ1BQQw0KPiB4ZW5fc3lzY3RsX3BtX29wIGZvciBh bWQtY3BwYyBkcml2ZXINCj4NCj4gT24gMDMuMDkuMjAyNSAwNToxNCwgUGVubnksIFpoZW5nIHdy b3RlOg0KPiA+IFtQdWJsaWNdDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gRnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiA+PiBTZW50OiBU aHVyc2RheSwgQXVndXN0IDI4LCAyMDI1IDc6MDcgUE0NCj4gPj4gVG86IFBlbm55LCBaaGVuZyA8 cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gPj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQu Y29tPjsgQW50aG9ueSBQRVJBUkQNCj4gPj4gPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+OyBB bmRyZXcgQ29vcGVyDQo+ID4+IDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Ow0KPiA+PiB4ZW4tZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OCA4LzhdIHhlbi9jcHVmcmVx OiBBZGFwdCBTRVQvR0VUX0NQVUZSRVFfQ1BQQw0KPiA+PiB4ZW5fc3lzY3RsX3BtX29wIGZvciBh bWQtY3BwYyBkcml2ZXINCj4gPj4NCj4gPj4gT24gMjguMDguMjAyNSAxMjowNiwgUGVubnkgWmhl bmcgd3JvdGU6DQo+ID4+PiBAQCAtMTU0LDYgKzE1NiwxNyBAQCBzdGF0aWMgaW50IGdldF9jcHVm cmVxX3BhcmEoc3RydWN0DQo+ID4+PiB4ZW5fc3lzY3RsX3BtX29wDQo+ID4+ICpvcCkNCj4gPj4+ ICAgICAgZWxzZQ0KPiA+Pj4gICAgICAgICAgc3RybGNweShvcC0+dS5nZXRfcGFyYS5zY2FsaW5n X2RyaXZlciwgIlVua25vd24iLA0KPiA+Pj4gQ1BVRlJFUV9OQU1FX0xFTik7DQo+ID4+Pg0KPiA+ Pj4gKyAgICAvKg0KPiA+Pj4gKyAgICAgKiBJbiBDUFBDIGFjdGl2ZSBtb2RlLCB3ZSBhcmUgYm9y cm93aW5nIGdvdmVybm9yIGZpZWxkIHRvIGluZGljYXRlDQo+ID4+PiArICAgICAqIHBvbGljeSBp bmZvLg0KPiA+Pj4gKyAgICAgKi8NCj4gPj4+ICsgICAgaWYgKCBwb2xpY3ktPmdvdmVybm9yLT5u YW1lWzBdICkNCj4gPj4+ICsgICAgICAgIHN0cmxjcHkob3AtPnUuZ2V0X3BhcmEudS5zLnNjYWxp bmdfZ292ZXJub3IsDQo+ID4+PiArICAgICAgICAgICAgICAgIHBvbGljeS0+Z292ZXJub3ItPm5h bWUsIENQVUZSRVFfTkFNRV9MRU4pOw0KPiA+Pj4gKyAgICBlbHNlDQo+ID4+PiArICAgICAgICBz dHJsY3B5KG9wLT51LmdldF9wYXJhLnUucy5zY2FsaW5nX2dvdmVybm9yLCAiVW5rbm93biIsDQo+ ID4+PiArICAgICAgICAgICAgICAgIENQVUZSRVFfTkFNRV9MRU4pOw0KPiA+Pg0KPiA+PiBJc24n dCBwdWxsaW5nIHRoaXMgLi4uDQo+ID4+DQo+ID4+PiAgICAgIGlmICggIWNwdWZyZXFfaXNfZ292 ZXJub3JsZXNzKG9wLT5jcHVpZCkgKQ0KPiA+Pj4gICAgICB7DQo+ID4+PiAgICAgICAgICBpZiAo ICEoc2NhbGluZ19hdmFpbGFibGVfZ292ZXJub3JzID0NCj4gPj4NCj4gPj4gLi4uIG91dCBvZiB0 aGlzIGlmKCkncyBib2R5IGdvaW5nIHRvIGFmZmVjdCBIV1A/IEl0J3Mgbm90IGNsZWFyIHRvIG1l DQo+ID4+IHdoZXRoZXIgdGhhdCB3b3VsZCBiZSBlbnRpcmVseSBiZW5pZ24uDQo+ID4NCj4gPiBI V1AgaGFzIGl0cyBvd24gdW5pcXVlICJod3AiIGdvdmVybm9yLiBTbywgaW1vLCBpdCBtYXkgbm90 IGFmZmVjdC4NCj4NCj4gSG93IGRvZXMgaXQgbWF0dGVyIHdoYXQgKHVuaXF1ZSBvciBub3QpIGdv dmVybm9yIGl0IHVzZXM/IFRoZSByZWxldmFudCBhc3BlY3QgKHRvDQo+IG1lKSBpcyB0aGUgIWNw dWZyZXFfaXNfZ292ZXJub3JsZXNzKCkgY2hlY2sgdGhhdCBwcmV2aW91c2x5IGd1YXJkZWQgdGhl IGNvcHlpbmcNCj4gb2YgdGhlIG5hbWUuIChJdCB3b3VsZCBiZSBhbm90aGVyIHRoaW5nIGlmIHRo aXMgd2FzIGJlbmlnbiB0byBIV1AsIGJ1dCBzdWNoIHdvdWxkDQo+IG5lZWQgY2xhcmlmeWluZyBp biB0aGUgZGVzY3JpcHRpb24uIENjLWluZyBKYXNvbiBqdXN0IGluIGNhc2UuKQ0KDQpTb3JyeSwg V2hhdCBJIG1lYW4gaXMgdGhhdCBIV1AgZG8gaGF2ZSBhIGdvdmVybm9yLCBzbyBzdWNoIGNvcHlp bmcgb2YgdGhlIG5hbWUgc2hhbGwgYmUgYmVuaWduIHRvIHRoZSBIV1AuIEknbGwgY2xhcmlmeSBp dCBpbiB0aGUgZGVzY3JpcHRpb24NCg0KPg0KPiBKYW4NCg== From xen-devel-bounces@lists.xenproject.org Wed Sep 03 06:55:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 06:55:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107885.1458077 (Exim 4.92) (envelope-from ) id 1uthPL-0006HZ-5P; Wed, 03 Sep 2025 06:55:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107885.1458077; Wed, 03 Sep 2025 06: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 1uthPL-0006HS-1w; Wed, 03 Sep 2025 06:55:51 +0000 Received: by outflank-mailman (input) for mailman id 1107885; Wed, 03 Sep 2025 06:55: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 1uthPK-0006HM-5j for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 06:55:50 +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 05eddf29-8893-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 08:55:49 +0200 (CEST) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61cf0901a72so9458793a12.1 for ; Tue, 02 Sep 2025 23:55:49 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-61cfc1c77f9sm11314824a12.8.2025.09.02.23.55.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 23:55: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: 05eddf29-8893-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756882548; x=1757487348; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+D0dgYdAzqhdFgfDa05EDsaAPryxTBJIiIfAW4Tgdds=; b=Rbl+SM3UVV84yAUErKQnNhZE2qjvF2xyOIPGIAOtzBE9M4Bk3EDsCBMQbWOhRsz+vH JUBFxWS6ZuSxDEEMzcmvmcHTaEF6UaxLuuAkMDZIde+WmNIVc6L70CYvRfeyp9mHZv5p UP804th21BbXVMeM07oPYuhmwpd5uFnoDArLyfzs48C/67oQVkCBrOyKYvZhsu0QZo0M nmmltFqbHU6/6KcuJhxL5lf0cRiwF1Geip/43w93RdNiDlQq0fbs2RfybUwulNO2C76e QtjrMQrqqJKgu1jFO7+vNxXR90bBovHIJeSeSgYDoNGT0tbfLsItt2MDj5/o4hjEzPJg JmAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756882548; x=1757487348; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+D0dgYdAzqhdFgfDa05EDsaAPryxTBJIiIfAW4Tgdds=; b=t2k6vrs4CwmP9dwbL9iO5RlkYYJiGCkrPOJ7I2t0WaEJEtf3X6zm06Ta+bX51fjx2J paRjdovXZzT4+Wvua1WqwMXY4KTIch/h1APfBGHwBKWTnLKFw6TMP8Ek5oHrFT219EUv OzO4FEcT2Rwz3sigm77keggYiH92F8ZR7Ya4R0njylVeRGEb/WtIrdutfi6ThH/H+VZO Ae5tvOhNNJTItp9vINpyKlALJfVpvjtfapzQ7YWphJyk2dWzMMEXH3rph2FlFqHCugG0 vRk8feN2qpwDLhVyVQYnvMgi5kvK40mqx8kkXi21WFwstsYQOuoB5BdLGtsu0nrzeY8R 8QPg== X-Forwarded-Encrypted: i=1; AJvYcCU6K/aiHpMXOXJ/ppyPvJ4Fad8Ddp5/tm1rE03tW52f8wQsPEtTLzwSDSA+QJj25m+IPDwDEwdhrks=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywz9dW0fpePA68GsbuMRbLOYVivndQIvpBypZmx26LTV8XM0Gni QmCcg6KBn2gMjc0P4ozaNXE28k24sbSvP0FWadZUEssRQveW0IwR5TIioz1VfMrHRg== X-Gm-Gg: ASbGncuxIu/G+5g1jvAQlyNFasT811AV2EZ0k8fqbYE7IdmLrD1jBacv1yFT/dWM4jg DnKyNmRQlL4E/xaIrwydMfHtdrlc8LVrjc5rhbKDji51561+1ZypVxe6H1+G/D+a7mWzqNkNJ/8 0dZ023nvue7vqwjZ0KaE3pZZK4htTlTzfO3c/nkrmT7urGwdDdvGL5GrMKVfKkOQRdEFFMSOM0e G0OlplejwxtlZmNoDSG5h0Qq/Tm22aM7zi4LYGYmvAnKxziPPQfEa+gJ9YcVWvoKxknK3RPWnpl uHeZImnpUV1yjUFGixLG/EU86A1DLNliJduDyDwP8Zg6S9loEstLO8LsUQccYGoUsuHmdLUCe9G JQXwdaFrNltroMcq+AuO1K5CIyMDCZgfaPeiQDmKqOMIk7qVNdUCnWubaO9CK/3cLfzJGMZLzn4 tNktkrZ9hfsvk9FiGM2A== X-Google-Smtp-Source: AGHT+IHK2NDAsCPqbNh7WJuIkTl1J7oIOgPZeqybWiy8KfApeyqh8zN7PazMPrt0sbnEHq8JmTjk0A== X-Received: by 2002:a05:6402:5211:b0:61d:1d16:19b1 with SMTP id 4fb4d7f45d1cf-61d2699c0bamr12506353a12.14.1756882548418; Tue, 02 Sep 2025 23:55:48 -0700 (PDT) Message-ID: <4f6c48af-a3aa-4609-a805-51867f01d99e@suse.com> Date: Wed, 3 Sep 2025 08:55:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] releases: use newer compression methods for tarballs To: Andrew Cooper Cc: Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?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 02.09.2025 18:15, Andrew Cooper wrote: > On 25/08/2025 2:54 pm, Jan Beulich wrote: >> --- a/tools/misc/mktarball >> +++ b/tools/misc/mktarball >> @@ -5,14 +5,6 @@ >> # Takes 2 arguments, the path to the dist directory and the version >> set -ex >> >> -function git_archive_into { >> - mkdir -p "$2" >> - >> - git --git-dir="$1"/.git \ >> - archive --format=tar HEAD | \ >> - tar Cxf "$2" - >> -} >> - >> if [[ -z "$1" || -z "$2" ]] ; then >> echo "usage: $0 path-to-XEN_ROOT xen-version" >> exit 1 >> @@ -21,14 +13,20 @@ fi >> xen_root="$1" >> desc="$2" >> >> -tdir="$xen_root/dist/tmp.src-tarball" >> +tdir="$xen_root/dist" >> >> -rm -rf $tdir >> +rm -f $tdir/xen-$desc.tar.[glx]z > > This is asymmetric with the rm at the end.  I'd remove > $tdir/xen-$desc.tar* here and remove the final rm. Can do, but ... > Looking at the uncompressed tarball is part of my process, and it was > preserved previously. ... afaics none was ever generated previously. git_archive_into() piped git's output into an "untar", and then the resulting tree was all that was ever acted upon, with tar directly piping into gzip. If we were retaining the uncompressed tarball, it wasn't quite clear to me whether that might get in the way of the uploading process: We surely want to upload only the compressed ones. > With something along these lines, Reviewed-by: Andrew Cooper > Thanks, but the above first need clarifying (at the very least because I would want to somehow mention the behavioral change in the description, yet then there may be none if my observation was wrong). >> mkdir -p $tdir >> >> -git_archive_into $xen_root $tdir/xen-$desc >> +git --git-dir="$xen_root/.git" archive --format=tar HEAD --prefix=xen-$desc/ \ >> + >"$tdir/xen-$desc.tar" >> + >> +gzip -9k "$tdir/xen-$desc.tar" & >> +xz -9k "$tdir/xen-$desc.tar" & >> +lzip -9k "$tdir/xen-$desc.tar" & >> +wait > > Interestingly, this wasn't fatal for not having lzip, but the error was > clear on the console given the reduced verbosity, and doing 3 at the > same time worked very nicely. Well, obviously, because the exit status is effectively lost for async lists. >> -GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc >> +rm -f $tdir/xen-$desc.tar >> >> -echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz" >> +echo "Source tarball in" $tdir/xen-$desc.tar.[glx]z > > This was grammatically awkward to begin with, but is now pretty useless, > especially combined with the set -x so it gets printed twice. > > Something like this: > > echo "Source tarballs:" > ls -lah $tdir/xen-$desc.tar* > > generates: > > -rw-rw-r-- 1 andrew andrew  32M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar > -rw-rw-r-- 1 andrew andrew 6.8M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.gz > -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.lz > -rw-rw-r-- 1 andrew andrew 4.7M Sep  2 17:13 /home/andrew/xen.git/dist/xen-4.21-unstable.tar.xz > > > on my system and is rather more useful IMO. I was indeed wondering whether to do something like this, but didn't because it again would have extended the scope of the patch. Now that you're asking for it, I will. I won't pass 'a' to ls though, as the glob doesn't allow for file names starting with '.'. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 03 07:41:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 07:41:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107917.1458098 (Exim 4.92) (envelope-from ) id 1uti7N-00048z-Ht; Wed, 03 Sep 2025 07:41:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107917.1458098; Wed, 03 Sep 2025 07:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uti7N-00048s-FF; Wed, 03 Sep 2025 07:41:21 +0000 Received: by outflank-mailman (input) for mailman id 1107917; Wed, 03 Sep 2025 07:41:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uti7L-00048m-Vh for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 07:41:19 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 60c9ad76-8899-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 09:41:18 +0200 (CEST) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-b0428b537e5so503317566b.3 for ; Wed, 03 Sep 2025 00:41:18 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0427c0d4cbsm714577166b.45.2025.09.03.00.41.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 00:41: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: 60c9ad76-8899-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756885278; x=1757490078; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=KAvnL5SRF5Lo+M2iHOGAS/PugArumXQv5xsmK4GAAu8=; b=PsBbYdZOT84y7M1VH5OMrkOyfpB58CQLzJZnD5Z+CtOJ+nOdVIt5A3BK4wSPbmTBJB OyE02Xbijxfb8yfYD1LWzBj8PFS50Xthv/nRvdTiUbAxd9ySh9dNAZP4dU75er5xE8Dk anA/UQGevV45yVYFQhpkdq8pDwb8YDanXYcVRKJYCbx5nqjqxnrNLgg3jD0wU4Hu8NUq 3v77ufBUB/zvrnodCy6SnvaYKiNQYHEImLi8UDdHhrXu2YMLtrkBSTqwphelu0lmTv5P UGw9Rj1aMVcgy+Y42aLUpwD75RHMmIu0y3DpdiUFIZ28UTmH1vB3D1vStkSkQ5ekPN+H gf/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756885278; x=1757490078; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KAvnL5SRF5Lo+M2iHOGAS/PugArumXQv5xsmK4GAAu8=; b=AsoHbTrz3b0UGvysscQZpZhFdSyirwP8jYG94qR9u2BnKIU7nCV16LWn9E6EbJY7g6 JaXbf/4Cg/3XfzjTQP7jXBbCsaD2HsgxX61mN2YYZCIaYrkHc+QwO9YH7fpA2idSGmDK drfIhnLaOsads7yHXY0q6L+K7VyHEg/7PQEM6kXDcDBT3R4RnYi+aHIUNYpk38//lou3 YvrSBPeXQfcj1M4pdQx8VKkA8lPlCOzKcN+Y5YFsf4ivMFQ+YekeKGlVrtgX2iHqjcrN 7Y2qiZl1WPCl5jF76RXNtzNgBnQMCd4MKnPS4GC+45vrpcI3PoXX9cvtpRDpcBYm7Pf0 WwgA== X-Forwarded-Encrypted: i=1; AJvYcCVnrxjzya+UDVDsdHIzvsaGzpGFD2dVsnzr9q+fLfjrD/UahB85FcQqqlgyO0pmjMGO0WkjYx/7mT0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwJ0muf6/K52RT7Yy6l5wPTcW3h0W7jk40O8kl65js9wxL1RSf+ r+/zUm4VScF9nlyCp7l//LesqegjlpuCUTMTtIS0vAh5QGVu1gI37Bd2nzE/RD1iBg== X-Gm-Gg: ASbGncuBAxPVd4DKBRoVQDeohgyWui00uH1Nw/RR+8OIkA+HhoT3Hg8vtkAQuz7n7Vk aX1ehcVslGfPAsHEh5q0TfWdml4nSWSGGTgTZDKsbWC93GHbRcScO1zziyOg7FN0cl4hnY8Ny3J VwPXz2bbgCgp4UvrpJE5+HKuflNccfRE8Ok9EAGeaXjUu/qNAsxTw706NrLvxAIq3KUggk6Jr/k m57/tsjghS1D4EwHBqJPeDIEh0Rm8RPw/2DROWH7REt1eAeeV36QF9gYHOx2HBH+prclA8XLGe/ yx592gc8iGLRDhI7rSZQWs2t2d9OE963DDhcXrciS/qmBICapzcltKWFk+dhkdeHjUf54lACnYM fECyamO+xhN7yTMv/Dbh4/57+k5jI4Mgn9RwAEcR9J5vnD1p+ItHJz+YzVWG6VUHVVUomn+Tl76 ilR/DNTDs= X-Google-Smtp-Source: AGHT+IFkMihsqnaS9GprkQ0zfoziB9ZtGqnlNRhuR3tny2FbLUOJkaBnkDARShsHiFRLzr12kMqKCQ== X-Received: by 2002:a17:907:928a:b0:b04:5b3d:c31f with SMTP id a640c23a62f3a-b045b3dc692mr377292066b.49.1756885277887; Wed, 03 Sep 2025 00:41:17 -0700 (PDT) Message-ID: <5934de0f-2bdd-49a3-8159-f1af4ce5b4e3@suse.com> Date: Wed, 3 Sep 2025 09:41:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver To: "Penny, Zheng" Cc: "Huang, Ray" , Anthony PERARD , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" , "Andryuk, Jason" References: <20250828100601.1777197-1-Penny.Zheng@amd.com> <7ec5e23e-2415-41b7-ab3e-7b0a7007bd1f@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.09.2025 08:46, Penny, Zheng wrote: > [Public] > >> -----Original Message----- >> From: Jan Beulich >> Sent: Wednesday, September 3, 2025 2:22 PM >> To: Penny, Zheng >> Cc: Huang, Ray ; Anthony PERARD >> ; Andrew Cooper ; >> Roger Pau Monné ; xen-devel@lists.xenproject.org; >> Andryuk, Jason >> Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC >> xen_sysctl_pm_op for amd-cppc driver >> >> On 03.09.2025 05:14, Penny, Zheng wrote: >>> [Public] >>> >>>> -----Original Message----- >>>> From: Jan Beulich >>>> Sent: Thursday, August 28, 2025 7:07 PM >>>> To: Penny, Zheng >>>> Cc: Huang, Ray ; Anthony PERARD >>>> ; Andrew Cooper >>>> ; Roger Pau Monné ; >>>> xen-devel@lists.xenproject.org >>>> Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC >>>> xen_sysctl_pm_op for amd-cppc driver >>>> >>>> On 28.08.2025 12:06, Penny Zheng wrote: >>>>> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct >>>>> xen_sysctl_pm_op >>>> *op) >>>>> else >>>>> strlcpy(op->u.get_para.scaling_driver, "Unknown", >>>>> CPUFREQ_NAME_LEN); >>>>> >>>>> + /* >>>>> + * In CPPC active mode, we are borrowing governor field to indicate >>>>> + * policy info. >>>>> + */ >>>>> + 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); >>>> >>>> Isn't pulling this ... >>>> >>>>> if ( !cpufreq_is_governorless(op->cpuid) ) >>>>> { >>>>> if ( !(scaling_available_governors = >>>> >>>> ... out of this if()'s body going to affect HWP? It's not clear to me >>>> whether that would be entirely benign. >>> >>> HWP has its own unique "hwp" governor. So, imo, it may not affect. >> >> How does it matter what (unique or not) governor it uses? The relevant aspect (to >> me) is the !cpufreq_is_governorless() check that previously guarded the copying >> of the name. (It would be another thing if this was benign to HWP, but such would >> need clarifying in the description. Cc-ing Jason just in case.) > > Sorry, What I mean is that HWP do have a governor, so such copying of the name shall be benign to the HWP. I'll clarify it in the description FTAOD - "shall" isn't enough, it needs to be (provably) "is". Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 03 07:55:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 07:55:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107935.1458108 (Exim 4.92) (envelope-from ) id 1utiKc-0005qO-K8; Wed, 03 Sep 2025 07:55:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107935.1458108; Wed, 03 Sep 2025 07:55:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utiKc-0005qH-HV; Wed, 03 Sep 2025 07:55:02 +0000 Received: by outflank-mailman (input) for mailman id 1107935; Wed, 03 Sep 2025 07:55: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 1utiKb-0005qB-7W for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 07:55:01 +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 4a8159f3-889b-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 09:55:00 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-b042ec947e4so451836966b.0 for ; Wed, 03 Sep 2025 00:55:00 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b02152cc1b8sm1013733366b.36.2025.09.03.00.54.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 00: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: 4a8159f3-889b-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756886099; x=1757490899; 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=f8Fac9W0WyfAOWo1532JBJfaFeza7fgTiztMVtxng74=; b=fVWhTUsRgnx0g/BixGhssjTmxP/n1pysQglqGRNQUI0MrD7fLlN7JW40/y3HJhjh/9 MS4/tIWg5eVC1Dn34jtKonXsys8rZ8z5srL0S4CQYzKiWQAZvmWfVKNFhOb11crZ8ZQv eZ5vkzX0jm2p9rixlEcnlNn10A8+HLu4Ojn9ufpUCwGblL8HRPVcVq+gtaIwsLumR1M6 fwQtXgnvmkkd7ow/fkbpwX8xWQNArB5Vcvr52m3+96jJ34IcrDkc1v9FHpAyLBi2xsu5 gPVsTEAHlDNOxctT0JHyzZUW9H9xsXMvzljeAo+WEECJPI0Kh0Us1DTWxNZM2UKjUasc 3nLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756886099; x=1757490899; 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=f8Fac9W0WyfAOWo1532JBJfaFeza7fgTiztMVtxng74=; b=ByLqQsZzDCZidJF7yM7hm/UyDJXxoBqoF23jvA88UXrkJ5uiGB30o6Pn70sREAfgDm P9Xys3bu4jEbsQxZf1nUWczSn0Lpf38cYhB9Srf5J6RdEYiNRop1FpG1ehDZKIs7MCqE HKmIdB1h/pF+WthPldgQ1wDKJm0FR9Fl4e8QZ6C1ckyRilFP06zViAqYnjB87GlUhXM8 rkv0ptdoKDXS0rT+CFa6M2cOFj6o76Cj2oHB8DA58sJb1uJ9hC2H2T9b01fRFcMqSBzI 3Z1+i0H0tTOQGKexqJNSsC2B+TBDhB7e16WqkzWYpcyRUOTD1vxvRAyoxr4MPZt1fSX4 cUAw== X-Gm-Message-State: AOJu0YxbdL7CGSDXsWPA12v/9YFcTx+eQuduCSIoG039ulnHHFE+krd0 3+5YZEMJ1rfvlPFdte2lZslnDvDpbhQefKp3zoHRLDXoeJc9dGMLuT+jYW/oDZevEcemZ3V/Mqy 4sgM= X-Gm-Gg: ASbGncuC2v16XIzUx87nCqT1xXIgEGYM2kVJn+siewYuSrsybmGdcbhGz/mX8frGsHs K4Flw7VsUfl1Nvl0riILXJLXbwSg+AUV6vUYDXSiwP8pA8h1W/geifK9YOA7Fky7UuepdtT5RC0 +UBxkuVSQEl7vVORQfBYZRpybfkPbUKgxBvjWS+9D41V5IM4CysNV5IyFoEn/voLueMuBO8/N+9 RwWAY3EfcPeVuVXdhUbmN21tnxb2H07n+OtcXcQ57b+IUlgVtS+W27ypBpVeku06AG+BAHcg7vs a0UNPYfJjuPRq3gmRLUeniQCYCij1mggsIGNtBsbD9y9W3D9+wJa/eRcV1t4HVR61YwJtskK0EP ENYUYl5T8nAame/lIlY2JtjU6Z7olQ8cr2q7ds45d3R/ct5WWo6qAiF8t0q0+JGq1kaSk80duqL omo/nRCZkPkHY1vt7YDg== X-Google-Smtp-Source: AGHT+IGVRSeoD1SWy4Epend3lSVzSf9IlN2J/ki83n5e2qHv8f8sg0mDmQUmBW1FI7f48/1oZSCfEw== X-Received: by 2002:a17:907:e916:b0:afe:ae6c:411c with SMTP id a640c23a62f3a-b01f2113c64mr1317974066b.64.1756886099526; Wed, 03 Sep 2025 00:54:59 -0700 (PDT) Message-ID: Date: Wed, 3 Sep 2025 09:54:58 +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?= , "consulting@bugseng.com" From: Jan Beulich Subject: [PATCH 0/2] x86/IO-APIC: remove dead / unreachable code Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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's not quite clear whether the two functions involved violate only rule 2.1 (dead code, not accepted so far) or even rule 2.2 (unreachable code). I'm leaning towards the latter, hence the changes would be an active fix. This is effectively follow-on to "x86/apic: Drop vestigial pieces (Intel VFM cleanup)". 1: drop setup_ioapic_ids_from_mpc() 2: drop io_apic_get_unique_id() Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 03 07:55:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 07:55:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107944.1458120 (Exim 4.92) (envelope-from ) id 1utiLV-0006Jm-VX; Wed, 03 Sep 2025 07:55:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107944.1458120; Wed, 03 Sep 2025 07:55: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 1utiLV-0006Jf-Qs; Wed, 03 Sep 2025 07:55:57 +0000 Received: by outflank-mailman (input) for mailman id 1107944; Wed, 03 Sep 2025 07:55: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 1utiLU-0006JU-7i for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 07:55:56 +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 6b5dfc16-889b-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 09:55:55 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-61cbfa1d820so12380343a12.3 for ; Wed, 03 Sep 2025 00:55:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-afefcbd874bsm1312198966b.57.2025.09.03.00.55.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 00:55: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: 6b5dfc16-889b-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756886155; x=1757490955; 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=LG18tho9TDeej44L4XAv91aRvSPRwD20YKPihFcGYo0=; b=IL3aoGoxCmS0E5np3fLw852xY64qZqOhakDdixCvgeqDa/VjGPn9zQBgWt3shEOBun E28SK+2KNzQfCw3dY53fgmL8bDjSjiOuYFfKc0L6amb+GzNR23dOTbD9iBUjMG0Squvs y9UtUdxabg6k6rGGeOUnKUupeekGd9U9mIbUZyVokyM7ex8PueZkHlS6zqSkSEcC0quO XXOPgcZBRuC6d0ofm1cBal9qMwT0zU0eXAjmskc5eC4Faqbhh2JTxCv/khEKspZgWvxv s5ZiI8qA9ZQFnuHPEsH/GdfyXH8m6cAVqdmEb6lAC0AGatJql7SwQRE0mjAYgEMES+wf iqnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756886155; x=1757490955; 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=LG18tho9TDeej44L4XAv91aRvSPRwD20YKPihFcGYo0=; b=UKZiRz1xRQGOkIJgYaCMwDMH6AXqnBpvYe0jDeBN/grxdmOEvRJg3bAc0LL6aETEHn RTNqsCiMAUC2A4AnGJVw4Et1HczDdn4UdfXGaiH3kCF7aq2n2Dh8ay7HjbBT4Xo0AqMr 8BN3Xxi+81HGrExtNOQYhGdbazSI0uoCdUwpyKvRFcfq0o7mLKN3EE1qs94mwKgnZiJu HMIw+En6pavmqhJomnOqifBUtYanPSLnkOOXx4389ALPzEefQ1yk7930lkL7thjRQerH 628yELXODMUqk1TINkttkKAyvc/2Nd7bmicRo3+fuQoIR1pjk7vIOBbVfm8ihwgJ5TW4 AXuw== X-Gm-Message-State: AOJu0Yxry782m1bW2eOFAkY4dafPAN2AKwdBxsY+bH71WCb0yVsoYDdF M2Lp4uH1CzyBOSJ6OFfJMwslqdwaCUc68KJxaTAQKnjEDRnK5g+wJeysxfBwicYJXJcU9J/Z3/a uCZo= X-Gm-Gg: ASbGncvC/XgJVe8Ucn4hnfGy2Puosy7e0pwYAzeKOrsllq5ehS3km+zvy/fKMEs2rJc BEAiCCg9gbsH367dwRgyKobhfSQ3c/4Ao5xnZFG0xixz/3NbqC09roEPqgPQYl0CVB9I33WpxO7 j5jTMqwbhpJ4EBtHqXX5Ltj8eyWkTv7uhOlQ3Gaf8qe649AHVsoHsfnrRcLu9C9Uy5p51m9AZKZ mh0+fm785sClqMq8ZZdr26E7abbqO3DV/whHH2YX5bcoN1jEIpddfBujY3vhtOThnvB88iRcOXe ouQdze2cB+dtbXFgY+gQLsWKMysoSb1Rus2JP1zGEe2jrZhHuCcDSr5/daaX1Bt7x8I2edHVHzl JNIg0VWl+sinRcdbmDjX8vxDV7OByK/wEN8PIqb6M9i5OKIZQGIwe6UnnL9nOjRga+NaXQGOhJL oVW6p0dx6AcbfRngK0Nyb3clnUgjW2 X-Google-Smtp-Source: AGHT+IHuLZVTLOWVnTFZ3HRpxYvwAECX2by0fldLjh2nrwdQdGd8D9LhUBxNtYRk8OClqASrob597A== X-Received: by 2002:a17:907:1ca0:b0:b04:286a:2fb8 with SMTP id a640c23a62f3a-b04286a4b87mr1062345166b.56.1756886154577; Wed, 03 Sep 2025 00:55:54 -0700 (PDT) Message-ID: <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@suse.com> Date: Wed, 3 Sep 2025 09:55:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/2] x86/IO-APIC: drop setup_ioapic_ids_from_mpc() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "consulting@bugseng.com" 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 Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()") said, the function is dead logic as well: All 64-bit capable Intel systems have (at least) xAPIC (if not x2APIC). Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead code; we didn't accept that yet, but - where possible - we probably would better follow it). Depending on one's reading, this code may actually be a violation of rule 2.1 (unreachable), which we did accept: "Code is unreachable if, ..., there is no combination of program inputs that can cause it to be executed." Otoh it's "only" __init code. Signed-off-by: Jan Beulich --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -1459,119 +1459,6 @@ void disable_IO_APIC(void) } /* - * function to set the IO-APIC physical IDs based on the - * values stored in the MPC table. - * - * by Matt Domsch Tue Dec 21 12:25:05 CST 1999 - */ - -static void __init setup_ioapic_ids_from_mpc(void) -{ - union IO_APIC_reg_00 reg_00; - static physid_mask_t __initdata phys_id_present_map; - int apic; - int i; - unsigned char old_id; - unsigned long flags; - const uint32_t broadcast_id = 0xf; - - /* - * Don't check I/O APIC IDs for xAPIC systems. They have - * no meaning without the serial APIC bus. - */ - if (!(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) - || APIC_XAPIC(apic_version[boot_cpu_physical_apicid])) - return; - - /* - * This is broken; anything with a real cpu count has to - * circumvent this idiocy regardless. - */ - phys_id_present_map = phys_cpu_present_map; - - /* - * Set the IOAPIC ID to the value stored in the MPC table. - */ - for (apic = 0; apic < nr_ioapics; apic++) { - if (!nr_ioapic_entries[apic]) - continue; - - /* Read the register 0 value */ - spin_lock_irqsave(&ioapic_lock, flags); - reg_00.raw = io_apic_read(apic, 0); - spin_unlock_irqrestore(&ioapic_lock, flags); - - old_id = mp_ioapics[apic].mpc_apicid; - - if (mp_ioapics[apic].mpc_apicid >= broadcast_id) { - printk(KERN_ERR "BIOS bug, IO-APIC#%d ID is %d in the MPC table!...\n", - apic, mp_ioapics[apic].mpc_apicid); - printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n", - reg_00.bits.ID); - mp_ioapics[apic].mpc_apicid = reg_00.bits.ID; - } - - /* - * Sanity check, is the ID really free? Every APIC in a - * system must have a unique ID or we get lots of nice - * 'stuck on smp_invalidate_needed IPI wait' messages. - */ - if ( physid_isset(mp_ioapics[apic].mpc_apicid, phys_id_present_map) ) - { - printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n", - apic, mp_ioapics[apic].mpc_apicid); - for (i = 0; i < broadcast_id; i++) - if (!physid_isset(i, phys_id_present_map)) - break; - if (i >= broadcast_id) - panic("Max APIC ID exceeded\n"); - printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n", - i); - mp_ioapics[apic].mpc_apicid = i; - } else { - apic_printk(APIC_VERBOSE, "Setting %d in the " - "phys_id_present_map\n", - mp_ioapics[apic].mpc_apicid); - } - physid_set(mp_ioapics[apic].mpc_apicid, phys_id_present_map); - - /* - * We need to adjust the IRQ routing table - * if the ID changed. - */ - if (old_id != mp_ioapics[apic].mpc_apicid) - for (i = 0; i < mp_irq_entries; i++) - if (mp_irqs[i].mpc_dstapic == old_id) - mp_irqs[i].mpc_dstapic - = mp_ioapics[apic].mpc_apicid; - - /* - * Read the right value from the MPC table and - * write it into the ID register. - */ - apic_printk(APIC_VERBOSE, KERN_INFO - "...changing IO-APIC physical APIC ID to %d ...", - mp_ioapics[apic].mpc_apicid); - - reg_00.bits.ID = mp_ioapics[apic].mpc_apicid; - spin_lock_irqsave(&ioapic_lock, flags); - io_apic_write(apic, 0, reg_00.raw); - spin_unlock_irqrestore(&ioapic_lock, flags); - - /* - * Sanity check - */ - spin_lock_irqsave(&ioapic_lock, flags); - reg_00.raw = io_apic_read(apic, 0); - spin_unlock_irqrestore(&ioapic_lock, flags); - if (reg_00.bits.ID != mp_ioapics[apic].mpc_apicid) - printk("could not set ID!\n"); - else - apic_printk(APIC_VERBOSE, " ok.\n"); - } -} - -/* * There is a nasty bug in some older SMP boards, their mptable lies * about the timer IRQ. We do the following to work around the situation: * @@ -2158,12 +2045,6 @@ void __init setup_IO_APIC(void) ioapic_level_type.end = end_level_ioapic_irq_new; } - /* - * Set up IO-APIC IRQ routing. - */ - if (!acpi_ioapic) - setup_ioapic_ids_from_mpc(); - setup_IO_APIC_irqs(); init_IO_APIC_traps(); check_timer(); From xen-devel-bounces@lists.xenproject.org Wed Sep 03 07:56:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 07:56:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107956.1458129 (Exim 4.92) (envelope-from ) id 1utiMC-0006rJ-A9; Wed, 03 Sep 2025 07:56:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107956.1458129; Wed, 03 Sep 2025 07:56:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utiMC-0006rC-78; Wed, 03 Sep 2025 07:56:40 +0000 Received: by outflank-mailman (input) for mailman id 1107956; Wed, 03 Sep 2025 07:56: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 1utiMB-0006fP-9E for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 07:56:39 +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 8451b886-889b-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 09:56:37 +0200 (CEST) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-6188b5ad4f0so8428520a12.0 for ; Wed, 03 Sep 2025 00:56: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 4fb4d7f45d1cf-61cfc1c7caesm11215967a12.9.2025.09.03.00.56.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 00:56: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: 8451b886-889b-11f0-9809-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756886196; x=1757490996; 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=an+6YpWz4Gh3Vcy0oc++hJHbZ3MoC5BmOYat5FVoGmE=; b=NkkEWTVoqDXNfe1iU0lyBw9og3kVvC7wQ2m+OLlrY+AVlyUbKOk/LaCexx4FdNgPVL cXj6kurHRa8HiTIe9vephW2cQkxxQlCrDcuNb5yBdaXye6MafYIL4VYeYNEHgDu9XYse 0LjebpaSx8uRTJsBtEIVJr3+k6IdTl/ffeJiRGPE5BLIxK1Bsv8CoRj9E2EG3eQo6J8f p0SAArq9xwf6dLKfYQvY/wl33fQvkJk16XigZq4xmeua+JWwut+jvfZKGtZk4NjkoIpY WyoOtk1KK5s74JwxwmWwg+WdDpgJmnZrb2yi8F14d0pGl2otfq0AydOdb+UzPDEjOsS+ YXCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756886196; x=1757490996; 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=an+6YpWz4Gh3Vcy0oc++hJHbZ3MoC5BmOYat5FVoGmE=; b=P414FaOpHrYnwxZBr5UDAwc8y3YwBIg3KdFIsNDwESDi928mHbFoOGU/veJdEIAIXp LHICVE7qdkszkUelJ9YXWKQS6LLmZL53rg3YvpOIBrve7eojbPiR4k4KgplyDmgz1Hnq hG0Ul1aNiEjSZ17WMVvzYNFEmIm0iN83V+wpmAAccc6zMOfuS143zOeeJ/lmfX5Ekb+t XasNOKau2udpa/fAKnHVENDeH+zXq4qzS7SnOWsHkfgachLPxLbmPEnG/QbG8Q3z3IBd 3uw7YRr9nkA4UglpUxaBHMqMaXqJjuvhbYQHHqABXa52bpiqelbfdFvL/qEvm2U9P5mj tYHg== X-Gm-Message-State: AOJu0YyGGnOL+fNM8LJ7kIu2rS90/AX4F0ZaEJwAriDtJ8fVextumBCC 6Zbt9ZLLYLPi02ScneRuAOn42Dz34nblRNJJgjQGyjVlofmjo4LWYmjjE83PwYa3SzE6dUbJy1t DFS4= X-Gm-Gg: ASbGncuAVN3Fj6ippDhyGr6KmMRKMUiATJEMrVmGBrVHnCYg8WYNq3QBPVvFzs02Pec ZR5U9XoA7PjNdBJQtZd2bmzA4yGRm5cY0xJD3F+e4C97dpdUxPU5IlRYqND+gbh8+dBMeBIE0Kn goow3rx+mRlHI+8T9WbEU0SpBGaJR0/AyBfZrMWC5I0uI7UItDpKdY15rdyhzab/s+X4ThzBZ+P +t5SI+gRueOiOLJC3KdDLYSX/2+jFOoMkGn3zF8d6eTSgxSH/b7vImvq2NW2ud4vMd2jkhwLa4n ahMaII2qj3lfsMsNa8TSKDoF45BGl3X3mdsfrCm68T3UlgnfpNmEE/+kHAsMD+hygqci9bQBzuG 51LZT3zQWHcLlKmTWpX2CRQ2Of+CmpbMy6ykwB0FtZg/9vfvFuZrHd9xIOjCzLIrTdVKEiCzv2U 3/ha9gEGc= X-Google-Smtp-Source: AGHT+IFzXwY8gVHyYYT5gxbKyGgJQ7lRfPYNTvMFDy2WSksEMD2guSfs5I7ylKG+MTufiPvdOR41yg== X-Received: by 2002:a05:6402:27ca:b0:61c:5a8c:9a4e with SMTP id 4fb4d7f45d1cf-61d2699752fmr13261626a12.4.1756886196475; Wed, 03 Sep 2025 00:56:36 -0700 (PDT) Message-ID: <80c035e0-54f6-4632-a5c2-a10d2c1c8422@suse.com> Date: Wed, 3 Sep 2025 09:56:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/2] x86/IO-APIC: drop io_apic_get_unique_id() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "consulting@bugseng.com" 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 Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()") said, the function is dead logic as well: All 64-bit capable Intel systems have (at least) xAPIC (if not x2APIC). Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead code; we didn't accept that yet, but - where possible - we probably would better follow it). Depending on one's reading, this code may actually be a violation of rule 2.1 (unreachable), which we did accept: "Code is unreachable if, ..., there is no combination of program inputs that can cause it to be executed." Otoh it's "only" __init code. As this removes the last user of APIC_XAPIC(), remove the macro as well. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/apicdef.h +++ b/xen/arch/x86/include/asm/apicdef.h @@ -19,7 +19,6 @@ #define APIC_LVR_DIRECTED_EOI (1 << 24) #define GET_APIC_VERSION(x) ((x)&0xFF) #define GET_APIC_MAXLVT(x) (((x)>>16)&0xFF) -#define APIC_XAPIC(x) ((x) >= 0x14) #define APIC_TASKPRI 0x80 #define APIC_TPRI_MASK 0xFF #define APIC_ARBPRI 0x90 --- a/xen/arch/x86/include/asm/io_apic.h +++ b/xen/arch/x86/include/asm/io_apic.h @@ -184,7 +184,6 @@ extern bool skip_ioapic_setup; extern bool ioapic_ack_new; extern bool ioapic_ack_forced; -extern int io_apic_get_unique_id (int ioapic, int apic_id); extern int io_apic_get_version (int ioapic); extern int io_apic_get_redir_entries (int ioapic); extern int io_apic_set_pci_routing (int ioapic, int pin, int irq, int edge_level, int active_high_low); --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -2092,86 +2092,6 @@ void ioapic_resume(void) spin_unlock_irqrestore(&ioapic_lock, flags); } -/* -------------------------------------------------------------------------- - ACPI-based IOAPIC Configuration - -------------------------------------------------------------------------- */ - - -int __init io_apic_get_unique_id (int ioapic, int apic_id) -{ - union IO_APIC_reg_00 reg_00; - static physid_mask_t __initdata apic_id_map = PHYSID_MASK_NONE; - unsigned long flags; - int i = 0; - const uint32_t broadcast_id = 0xf; - - /* - * The P4 platform supports up to 256 APIC IDs on two separate APIC - * buses (one for LAPICs, one for IOAPICs), where predecessors only - * supports up to 16 on one shared APIC bus. - * - * TBD: Expand LAPIC/IOAPIC support on P4-class systems to take full - * advantage of new APIC bus architecture. - */ - - if (physids_empty(apic_id_map)) - apic_id_map = phys_cpu_present_map; - - spin_lock_irqsave(&ioapic_lock, flags); - reg_00.raw = io_apic_read(ioapic, 0); - spin_unlock_irqrestore(&ioapic_lock, flags); - - if (apic_id >= broadcast_id) { - printk(KERN_WARNING "IOAPIC[%d]: Invalid apic_id %d, trying " - "%d\n", ioapic, apic_id, reg_00.bits.ID); - apic_id = reg_00.bits.ID; - } - - /* - * Every APIC in a system must have a unique ID or we get lots of nice - * 'stuck on smp_invalidate_needed IPI wait' messages. - */ - if ( physid_isset(apic_id, apic_id_map) ) - { - - for (i = 0; i < broadcast_id; i++) { - if ( !physid_isset(i, apic_id_map) ) - break; - } - - if (i == broadcast_id) - panic("Max apic_id exceeded\n"); - - printk(KERN_WARNING "IOAPIC[%d]: apic_id %d already used, " - "trying %d\n", ioapic, apic_id, i); - - apic_id = i; - } - - physid_set(apic_id, apic_id_map); - - if (reg_00.bits.ID != apic_id) { - reg_00.bits.ID = apic_id; - - spin_lock_irqsave(&ioapic_lock, flags); - io_apic_write(ioapic, 0, reg_00.raw); - reg_00.raw = io_apic_read(ioapic, 0); - spin_unlock_irqrestore(&ioapic_lock, flags); - - /* Sanity check */ - if (reg_00.bits.ID != apic_id) { - printk("IOAPIC[%d]: Unable to change apic_id!\n", ioapic); - return -1; - } - } - - apic_printk(APIC_VERBOSE, KERN_INFO - "IOAPIC[%d]: Assigned apic_id %d\n", ioapic, apic_id); - - return apic_id; -} - - int __init io_apic_get_version (int ioapic) { union IO_APIC_reg_01 reg_01; --- a/xen/arch/x86/mpparse.c +++ b/xen/arch/x86/mpparse.c @@ -871,7 +871,6 @@ void __init mp_register_ioapic ( u32 gsi_base) { int idx = 0; - int tmpid; if (nr_ioapics >= MAX_IO_APICS) { printk(KERN_ERR "ERROR: Max # of I/O APICs (%d) exceeded " @@ -891,16 +890,7 @@ void __init mp_register_ioapic ( mp_ioapics[idx].mpc_apicaddr = address; set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address); - if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) - && !APIC_XAPIC(apic_version[boot_cpu_physical_apicid])) - tmpid = io_apic_get_unique_id(idx, id); - else - tmpid = id; - if (tmpid == -1) { - nr_ioapics--; - return; - } - mp_ioapics[idx].mpc_apicid = tmpid; + mp_ioapics[idx].mpc_apicid = id; mp_ioapics[idx].mpc_apicver = io_apic_get_version(idx); /* From xen-devel-bounces@lists.xenproject.org Wed Sep 03 07:58:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 07:58:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1107969.1458138 (Exim 4.92) (envelope-from ) id 1utiNW-0007QX-JF; Wed, 03 Sep 2025 07:58:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1107969.1458138; Wed, 03 Sep 2025 07:58:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utiNW-0007QQ-Gb; Wed, 03 Sep 2025 07:58:02 +0000 Received: by outflank-mailman (input) for mailman id 1107969; Wed, 03 Sep 2025 07:58:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utiNV-0007QI-Pw for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 07:58:01 +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 b5b306c8-889b-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 09:57:59 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b040df389easo642253466b.3 for ; Wed, 03 Sep 2025 00:57: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 a640c23a62f3a-b016e56a4e2sm1028442166b.26.2025.09.03.00.57.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 00:57: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: b5b306c8-889b-11f0-9809-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1756886279; x=1757491079; 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=h97/yc04p7cp7pcV+OMKBhRHGEqEz0yLjWc8+cllglg=; b=fjJEbvi01+HbrAL2HD21g802mQtlxc5/3y9a1J0aWymzrdDn9LAM+3xLaUiRy+XeFY WOD8BSE1DdtjO4qUhErrKWhHE3IkBZOwSniF2Y9DgxOXPNAOYu71JrVfiA817MJDhEby AmIV3iAYnfOJnya5nqLVJ/SlT9cxOEPWhGlAPYb5ZGuQsL8qgmKhKfesH3Q2hHRDc77R uX0R4xrnZIWsndFcFkdqJFICYakg5Pohpt2yjfMBp4RtK5Q6NlC+fWNpBjlb5P8e7oH2 x8J3jSTP72R6wyZn+qyr2vZUw78v0a64DmCaLrPOnZvAN75ETSST9qVoccdV65oy+MuH pTIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756886279; x=1757491079; 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=h97/yc04p7cp7pcV+OMKBhRHGEqEz0yLjWc8+cllglg=; b=XAcfC2MYejbOgchq7MR8bbfmMn0zPgUBeanianZq+4l+m2PxeAfIgDKjGdM/PIFDya Fxr+K8oqIoLP5j+s9050scQeaqTxiDVRc1bqiuXDTQog4H1PahYKDg3BQFJnVm+/hwLm 9cp8COdyxSMoNwfL9K4yvJeS9wLe2K93/9e2fw3Ve0z0tEfSRjY0UiITsRwHyCAXMtFJ 6t00ADwWg0x8Mo66lSdT66eby2CcxLYFFscpRRgp6UPOW/nfjCWzfuhYJdHT/UbVdeqE EnDzgpXZxYHHXmKIp8tntdm63ArTodXmRx2Hw1xzxleC1qjTWAmghg49fot29sA4IbTz Blww== X-Gm-Message-State: AOJu0YzbRimkMP5RRAFf1EdPvMF+mXQK7ict/2c8wEJbkswzvRPvVYDt iXtsoQMuZZ3hXlXJcOaVe88LJTJQ/J4x5WYwp8goPGGCm7+JMotjUR0FhALsa2RzX/9j+cfd84X fLBQ= X-Gm-Gg: ASbGnctZWOyy9CygtOtNhAxtj3dsJTwg9ULgw5rWwzhBHlq9/mOjG6FmH8tB/j9LScK vSjVE0N7HDUlSfTG3iKd6tWR+qdfaizcKNmYe+7NPmPXTkRtzcCYlXZSRhRVx9Wx0lXdit0ngtW n6PSRQyOob9z1Z9cJgFmVdSl5LWywzWiQPc6nNaiUvuNdTKSI/8xgkH+qbZlcw1gI8IebKBVf+v vrzQCcBublqBSuwexXcjM0zAIyQXjE3dGYCCzRLpSlTlUiuFOXMqYWlmgaJhYFJw2510B9WFQo0 5zv9vtQtAPRVQ720kSkYAVC+Qr6Pud/6wmjVk224+90Xo/CB/Cf/g7usWwy+/qhQq0ZQjm17bhM H3QntPoOqc5mlpvmw0fHHlj0hml8Kww9Blc7FMsBns5ANipjSydQZheJksMp4MmVFBiOdBgseAD Q7Q4S9TsTsjhtYA25dyg== X-Google-Smtp-Source: AGHT+IFaIWsQcYs2AgEI2MOpF+H86WZPXMXDvw5t2pmziFYJ4WZ7UrvAL4Q0QtUyxe9ebvTASlfVPQ== X-Received: by 2002:a17:907:98d:b0:af9:29c1:1103 with SMTP id a640c23a62f3a-b01f20c704fmr1603978666b.55.1756886278639; Wed, 03 Sep 2025 00:57:58 -0700 (PDT) Message-ID: <629927a5-f2cd-4c70-ac7b-525b7ad28369@suse.com> Date: Wed, 3 Sep 2025 09:57:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] x86/IO-APIC: remove dead / unreachable 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 On 03.09.2025 09:54, Jan Beulich wrote: > It's not quite clear whether the two functions involved violate only rule > 2.1 (dead code, not accepted so far) or even rule 2.2 (unreachable code). > I'm leaning towards the latter, hence the changes would be an active fix. > > This is effectively follow-on to "x86/apic: Drop vestigial pieces (Intel > VFM cleanup)". > > 1: drop setup_ioapic_ids_from_mpc() > 2: drop io_apic_get_unique_id() Just to mention: This drops about 7% (in terms of LoC) from io_apic.c Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:01:53 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:01:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108021.1458173 (Exim 4.92) (envelope-from ) id 1utkJB-0006eY-BL; Wed, 03 Sep 2025 10:01:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108021.1458173; Wed, 03 Sep 2025 10:01: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 1utkJB-0006eQ-7F; Wed, 03 Sep 2025 10:01:41 +0000 Received: by outflank-mailman (input) for mailman id 1108021; Wed, 03 Sep 2025 10:01: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 1utkJA-0006eK-G1 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:01:40 +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 fb088dbe-88ac-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:01:37 +0200 (CEST) Received: from PA4PR03MB7038.eurprd03.prod.outlook.com (2603:10a6:102:e1::6) by GV1PR03MB9870.eurprd03.prod.outlook.com (2603:10a6:150:3d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 10:01:29 +0000 Received: from PA4PR03MB7038.eurprd03.prod.outlook.com ([fe80::62a8:3ed7:1b8e:677b]) by PA4PR03MB7038.eurprd03.prod.outlook.com ([fe80::62a8:3ed7:1b8e:677b%4]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025 10:01: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: fb088dbe-88ac-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lgJ5EHAoLLmAiuRdkGofkKwxb9Hhqhg3PzNu8N44RXXSM0E1q6K7ukgQCeB7IzfiEOBs8f8xtGxWD+S8RGSDIxyreZFV2Hl1AlcIsJu8svO6kUKV5/Uxh7bZIRiWUyXpgIurBHjMCA30r50o57NQtGrdvCPMTSkujkCx8797Stegmdm4iF5TJ2tKD+n783ojzp9XFXQNkjRS2C1zpuQfvjsro0mlXXuWdjDH+OEfw9Oxfs5kYfOPBezxQurtjY+UJR2N2DW9p/alEtnnt6865k8DRly8gWqPYbo10qj1Qfe4XvDupNvQjK3O/og3JI4sUZ3jZsdyXVuTIiJmBqfdvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FYev9yE9BVqfSNBVNtH8XkNO6uHjWYVuWKHmuSNHAVA=; b=IkFQi71kHqhurckzhNrb1WDaLWQwDYLBuYj40SunX2TRX5SgOdsMRUleh1qHqP4HxZZTBJ0cr/gslByNsagdF6co4EI6MuCU1CFAfKJW7EFA8LLhRxkbBE8xVQOMjlnd7BqJeS4b72IPK0ty+wYjp97JCnVcL8l9/w7BjWIoE/Q5MmQGxYQLHiUfj1AzSi5/UILRzSc5z160z5Su/ELWzsBFXKOKzox7P9WSoGjU2NFkA2pM0zCCEYhZmGoLu8OZ/YzueK8yZro5sgIkQTnNjKErgnW1WWLIsyRyeGWuhA/Dhp/tfDmlzhX5u9/2XZo+NFTkckY5Q2rK3bLrBxp8bw== 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=FYev9yE9BVqfSNBVNtH8XkNO6uHjWYVuWKHmuSNHAVA=; b=qRuwakkjUjl3t7NCPsaDUQSouw+kgwcz2bGIEHsZMJg9tGSk1dMhhfzkzbAxBcOKPcJH0NIKhoK8HdpvcE6xTa5SDGO8hBz/q+9cvxdUVF6phQQpAxYkvWoerwHIucgo2UTx0F2dqWgcFaCn7VrnnkFtIHGI0tY6dNFB+cOkIQLu8XOZYrpk5L1H+A+/yETB6tRiFhRFu7ByEcrok67JnOYX7RqKLIeM22r5tVcqbUskju/YPBQqfr4YFgd/UDbslwDBbLAqmSXDM3uK1cPoLVgGEZNKX9Ga+iGw4oSwfqkBTamFoDwEXbTLVLo53MqzVtpi/8zE85dEZ38WtC+Rmg== From: Oleksandr Tyshchenko To: Mykola Kvach , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Mykola Kvach Subject: Re: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Thread-Topic: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Thread-Index: AQHcG40/oXlWAzbIxEi9O+f56L7WfLSBPFMA Date: Wed, 3 Sep 2025 10:01:28 +0000 Message-ID: <41cddeee-6cc2-4426-9020-2f1000983845@epam.com> References: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com> In-Reply-To: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com> Accept-Language: en-US, 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: PA4PR03MB7038:EE_|GV1PR03MB9870:EE_ x-ms-office365-filtering-correlation-id: 63e740de-e1ad-4483-a6fc-08ddead0da17 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|42112799006|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?OUoyQVBOMWZWSTJOeWYwRGU3ZFlQSnY3cEp1b0VnZXBvYk1OaktVRUswQ1Aw?= =?utf-8?B?K0FxU0pXT3drcVdxa01DN2k3UDJudHVnanN0dmc4MEJZWVRkOG1hdGVLSFdY?= =?utf-8?B?MjFraUhpa0c2YzV6dFhieG9EK0xRWVVyb0NJbll2QU5PYWhEL3lhSGxIc0JB?= =?utf-8?B?YStWdFh6aEYyVXhWa25EYVNhME8wSGkzV0RSMU9DTWRSYmcyK3oyREZnTHVk?= =?utf-8?B?NzhuMmlGZ3ZPNUt5ODYvU3h0Z1pPbjU5NnBLbHpOem1qNUhMckRvdTdyZGRO?= =?utf-8?B?aldJd2dBR0pjUEp6a1JoMW4wbUwvSER2dzhDS3dlRWZYUlN2MUxrSFZhcTIr?= =?utf-8?B?bVpGSzlnL0FMY3pKMnpUMENtVG1pQ0tDSXBBZlg5eXBmeDdtUUxTYWdhaThp?= =?utf-8?B?T1psWGVxMlJqMUNkdSszM0lQbWUxYVQzUmlEd3V3d1EwbEVNS0lzdFlrbHo3?= =?utf-8?B?Wlkzek04ZjVLMFpUMWd1SWFtNldmT1lvUmdPQWI0YzRPeWdXaEw4bGRvYUh1?= =?utf-8?B?Wk1WdjJjSzhZaklLNmNQWlQ4TEtxOFlWMi9QV0lXTko2NExIUHZySGM0Wmo0?= =?utf-8?B?d1BmaXRBZXNlRWxEdTVkaVZJNzZhTWhrZmwzYlBUVUZSbFcwcTlweXVRK1ZJ?= =?utf-8?B?WDVTdi93aXhNWUNDWnFoeFJabDB5ampINnNFUmE5eWhJdDJJMjJYWVR3eE5z?= =?utf-8?B?Vm1lODhoSkEwWVVtWEFYbmRSL3JNMVcrbnZrc1FibXlRYk8xVSt0RnV1UTRN?= =?utf-8?B?eFcvR2tQTzUwV0N4akFjTWh4KzdBbFhDQU81bHEzUHhIMU1Qd1RuYVptRnFP?= =?utf-8?B?Z2wyTElENk5nYnZ5Y053cUgyT0ZDOExKOHZua01MSGxSU0lmc3ZkRm8zdjZU?= =?utf-8?B?ODQwY2QxNWpneE42cEhXVGdhMU54UTdrRFk5SUcxb0F6NjhSZ09TdU9aUzNE?= =?utf-8?B?ODZTYkl6dStudElybGhpWHg5WDlreVkzT2ZIYXYyWFRpVlcvVEVudE42bHdC?= =?utf-8?B?RWJzbGdPM3F3cUI5OStNOVF6a1JUc1FyeDZ2NGs0SFdRYW9RREJ1RmlKMUF3?= =?utf-8?B?QkxQemUrME96ZURKSEQwbWlIOWliSEFxdS9sYjNsT3V5amxhd20zY0FIWkdp?= =?utf-8?B?blhCVVE4d0U5VzBvVnI1UndyMi9PYURCY2RzaFI3WlQ2TjJ1d09GSzhxbjlR?= =?utf-8?B?LzJRbTh5VHFyb0paclh3Y2NmSE9RVzJId3dHRHc4emYrQmw3bktacm1McC9F?= =?utf-8?B?c084a211Q29tM1dNNjYzS1oyTWc2SzNOMThuS3pZMzJJSlRMWTNBS05PclEw?= =?utf-8?B?L0RmSzdjb1lzUzlXc2g1TmJ4QXpjUENZTGlFNGczbGJKOVB4d2VsV3g3Qkpi?= =?utf-8?B?TEJyN0tGWmdobjVlMHFwYVZIcXdJYVpxMFhWSGc2RDlmT1FrbGdPdkxPWHI2?= =?utf-8?B?Um4xd0s0UlZnbW9sVExRMlFvaHNmaDM0eko0YlBoWTVaUC8vQlpacWk5Z2VE?= =?utf-8?B?dVMybFpPcTRheWpYUFNLZUhLWmZyU2JBWXRvbHFJVnNYVHY4eUJ3MXJIUkFK?= =?utf-8?B?N1owWS91RmdlY1huMEtvTGFVdEZCUEpMa3JRWmlSN2xxdEFIQjFtT2UxWGM3?= =?utf-8?B?bHEyNWgwMWtkWGkrSUJiQm05K3NlNWtjam1mR0g1dDBBYms0MENvbDEwd29N?= =?utf-8?B?ZmVEdWZxdDV3VDRWZHhPc3lLQkxqU01neXRyTGd2RUZGU2pxVnVJN2VRd0hV?= =?utf-8?B?Z0VnMDRhNFRQNGg1YWZRV3BmVStjdUJuTm1iSGJTV0diaU9NZlo4WUUzU01Z?= =?utf-8?B?N0hZRWNzQU5hdkJtcGE1ZW45MFlFL1VsRUVMNjlQTnRkTlVPeWhOTXpUVXRu?= =?utf-8?B?NS9TREJIVnNMNlhDM1F0LzBIa04vOFRaZlZkdDZSdmxxejdIN2JlWTEwRVhl?= =?utf-8?B?M3YwTkpXMEJnbEpFY1dYYWdTemJDVE0vcDRXYlVFWVNpQnF2L1ZnaXI2dmEz?= =?utf-8?B?MWNObE1YRUZ3PT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR03MB7038.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(42112799006)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TURRNFpLeXQzRkY4eENFcWJnaW94WTFoZ1pWNmNyQ2RWdkw0d3BIdDV3WDZC?= =?utf-8?B?VTgvdVhvdXhUUU56UE9GQXFrakl2N3JhRmttbnBwVUg2WDdhbk9haUFvMk16?= =?utf-8?B?UFNiUk1yeWpOT21UOS85dHFsR2tjUXpoZ2NrNENFdjZSaUUwczl2d2hQaldt?= =?utf-8?B?MlgxY0hKbG1QeU41SkttSzhYSjV6ZldUSldLVXRtdWVYYWw0ZXNjYjh0L2Fz?= =?utf-8?B?WHAzanJqN1ZVanBUQ1VzVUlaYUFScktueHU0YVhyWFFHTHlxZUZKaitIWmFW?= =?utf-8?B?S2lOb010Q2Vyb0pvSm1JMWdOOXVNUzRUdUU0YTA2QnFoZGhMZldCWFJhNEU0?= =?utf-8?B?c2lpa2dYZ3IzNGxlRVMxUFNpQXRnTWxOS29FMDg3dDA4SVVJYjVFZFZEZ1FQ?= =?utf-8?B?bGc5eHBlRDRLYkFCd05LR3VJSHVrL1Jpc2hVQzRkL0lzVzhocmlCNlFuNzVq?= =?utf-8?B?S3FVNk5MS0J4UCtsM3hHM1lnVjFTSDJ6T3JReVlrV05oY0t3eExJTm85Mmtj?= =?utf-8?B?WS9uU1YwSElWb3lvdXU2MnhuV0lJUkRvbXNnTHFkalNYMXVOWUpsL1kwSlBF?= =?utf-8?B?UkVZaEk1bHJ2U0hzZzgrQ0VqUTFibUl3WWNEcEFkRUJiQ0dyZXY2QzZMb0po?= =?utf-8?B?ZmdrSEt4QW5NcFRTQTlFRytFZ3VDcnd6NkQ1M2ZLS0xUdEEzK0tvK01mSGpt?= =?utf-8?B?dXUvcE5wYis0ZlJ0OURoVngyc29nbUQ5VUYzSmV0U3FTZ0FMZHhlbWtGVGNa?= =?utf-8?B?K2czUnhBaVpuaG4yOVA0bGpKa0MrNFplWHRDNWxDMTRqdmZFUFE5djY0MFZV?= =?utf-8?B?U2ppRU9vcm1KYWVRaVJBTmNPMWRDTVpXNVRaUEoxOExtRm9laHA1SDlxY3ly?= =?utf-8?B?b1k4MmkrbGYwOXJvWVR1bGQ2WUI3ci9lSCtDektSL2FQYTE0T24zQzk1dlF2?= =?utf-8?B?TXJ5NnhkS3Z1RjN6b2VXMFVDT1BMRm5WL2d4WTQ1T2ZFQVpaZkdlbmllZGg0?= =?utf-8?B?SlppcVpMNWlLT0RhY2ZtQlQycU5zcFlFVFZwNmtjaTBTc3BjZ2dZT2hDamoz?= =?utf-8?B?QzlqSFFIb3ZDRDB4U2kvelVJbWxBTXZoNGxzcHFTMXBXK2VUZENkVEdzTTNi?= =?utf-8?B?czVDK0poR3c2V2ZyNVhlR1JBY1hmaGdEVll5YVJNbktqMzhLc2dySSthR1dm?= =?utf-8?B?Rm5zM3NiTjkzbFdiRHg1cFYyNUlSdTZXaTlNRTJMZXlQT25GdUFERW9HVEtS?= =?utf-8?B?Q3NqTlNSMlVtV1FoUGx0MUp3TEpidk9Ya0MzWGhlckVvSDhJK2tabU5YRExi?= =?utf-8?B?WnpmRlBoMjBhUVZDVC9acWI1UVVoR2tYcnNhUHNBdE5zelRJY3oxaWpoM2pD?= =?utf-8?B?Tkl2MnRxSTMyRkNoNnhnd29OWHRWcWIyckYvTXJ0VFZoRTZlQ0t4MlhiUHln?= =?utf-8?B?NFFDSzNJTDhNUXFOVm9VYllYUmlDYnl5SEJzU0dkN2c5K0JaNCtMZ0Z3N0Mv?= =?utf-8?B?czlLUnJJSHNGN2JkNXJlSXA5eHYzZ2NqdzJtWjlML0RqcGRDOWtBWkl2eHF1?= =?utf-8?B?Z0I3VzN2OWxxMkp0YSt0aFNtNzBxMHJoZ3oxOE1GM256dG8rblZsMlNVQmdI?= =?utf-8?B?RFBuanZzQ1hKT2h1aE9JTlpEZmV5Rzh4ZUFmSElFWUZTZlRydzQrL3luREJC?= =?utf-8?B?TC9GeVVjckdMODNteXJLM05QL253NGo0ZnVhM0xiVzVUYzN2YVNGWDAxSEZP?= =?utf-8?B?d2FFWWtFWWlNdmV6M2M0dnZhVnZzUFM0RHJYcXM3dmV5ZHdmajk2MUJSZUU0?= =?utf-8?B?amE5SzlkRFc1TFBPQnQ0WU5WemwxdEIyRXQwMS9sM3FETUNab2RMTjJhR0xp?= =?utf-8?B?eXh6UFZVNGZMMlEzRmtHODlYbi9vUDF5aklBaUhndENEa3NzZkhsMzFoeldL?= =?utf-8?B?OXVkVW9zM2ZUTkpveWFPYVJnek13VVc0eVdXUDhWV0k1dWJzWGVkS21pYnJs?= =?utf-8?B?ZjRzRG5JRFA2bTNDVHcvZE50eDlGcUNBUU40T1FzbHJMZ01VN2pPNGVNMFNL?= =?utf-8?B?T2Z1OHV4eGgvQjVIYmxoa3BTd2VrckRET2Vtcnk0OEI5czJoNHJ5WG45K1R0?= =?utf-8?B?bmJaUjRRTVJkci80akFPWjZBZVBoOWo2VnIzdWZ6bmhlSUNqcW05ZlhpdHZJ?= =?utf-8?Q?2Rxoyrz4Iwq0on+VzG3ajl4=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <7882F46E02A4EC4BBE017BE7EDC4426F@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: PA4PR03MB7038.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63e740de-e1ad-4483-a6fc-08ddead0da17 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 10:01:28.9503 (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: PhVQh0KxbdEP6FYv4gM4jI12TpQo/EK8oK7KublskRIreZsl1hHD7DWf2rlUAnSkjZAkQuvslcImLmNWlucQf2O5ge7VQEFL26dGYQZjpDI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB9870 DQoNCk9uIDAyLjA5LjI1IDAxOjEwLCBNeWtvbGEgS3ZhY2ggd3JvdGU6DQoNCkhlbGxvIE15a29s YQ0KDQoNCj4gRnJvbTogT2xla3NhbmRyIFR5c2hjaGVua28gPG9sZWtzYW5kcl90eXNoY2hlbmtv QGVwYW0uY29tPg0KPiANCj4gU3RvcmUgYW5kIHJlc3RvcmUgYWN0aXZlIGNvbnRleHQgYW5kIG1p Y3JvLVRMQiByZWdpc3RlcnMuDQo+IA0KPiBUZXN0ZWQgb24gUi1DYXIgSDMgU3RhcnRlciBLaXQu DQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2FuZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5 c2hjaGVua29AZXBhbS5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IE15a29sYSBLdmFjaCA8bXlrb2xh X2t2YWNoQGVwYW0uY29tPg0KPiAtLS0NCj4gQ2hhbmdlcyBpbiBWNjoNCj4gLSByZWZhY3RvciBj b2RlIHJlbGF0ZWQgdG8gaHdfcmVnaXN0ZXIgc3RydWN0LCBmcm9tIG5vdyBpdCdzIGNhbGxlZA0K PiAgICBpcG1tdV9yZWdfY3R4DQoNClRoZSB1cGRhdGVkIHZlcnNpb24gbG9va3MgZ29vZCwgdGhh bmtzLiBIb3dldmVyLCBJIGhhdmUgb25lIA0KY29uY2Vybi9yZXF1ZXN0IC4uLg0KDQo+IC0tLQ0K PiAgIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9pcG1tdS12bXNhLmMgfCAyNTcgKysrKysr KysrKysrKysrKysrKysrKysNCj4gICAxIGZpbGUgY2hhbmdlZCwgMjU3IGluc2VydGlvbnMoKykN Cj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vaXBtbXUtdm1z YS5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL2lwbW11LXZtc2EuYw0KPiBpbmRleCBl YTlmYTlkZGYzLi4wOTczNTU5ODYxIDEwMDY0NA0KPiAtLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhy b3VnaC9hcm0vaXBtbXUtdm1zYS5jDQo+ICsrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Fy bS9pcG1tdS12bXNhLmMNCj4gQEAgLTcxLDYgKzcxLDggQEANCj4gICB9KQ0KPiAgICNlbmRpZg0K PiAgIA0KPiArI2RlZmluZSBkZXZfZGJnKGRldiwgZm10LCAuLi4pICAgIFwNCj4gKyAgICBkZXZf cHJpbnQoZGV2LCBYRU5MT0dfREVCVUcsIGZtdCwgIyMgX19WQV9BUkdTX18pDQo+ICAgI2RlZmlu ZSBkZXZfaW5mbyhkZXYsIGZtdCwgLi4uKSAgICBcDQo+ICAgICAgIGRldl9wcmludChkZXYsIFhF TkxPR19JTkZPLCBmbXQsICMjIF9fVkFfQVJHU19fKQ0KPiAgICNkZWZpbmUgZGV2X3dhcm4oZGV2 LCBmbXQsIC4uLikgICAgXA0KPiBAQCAtMTMwLDYgKzEzMiwyNCBAQCBzdHJ1Y3QgaXBtbXVfZmVh dHVyZXMgew0KPiAgICAgICB1bnNpZ25lZCBpbnQgaW11Y3RyX3R0c2VsX21hc2s7DQo+ICAgfTsN Cj4gICANCj4gKyNpZmRlZiBDT05GSUdfU1lTVEVNX1NVU1BFTkQNCj4gKw0KPiArc3RydWN0IGlw bW11X3JlZ19jdHggew0KPiArICAgIHVuc2lnbmVkIGludCBpbXR0bGJyMDsNCj4gKyAgICB1bnNp Z25lZCBpbnQgaW10dHVicjA7DQo+ICsgICAgdW5zaWduZWQgaW50IGltdHRiY3I7DQo+ICsgICAg dW5zaWduZWQgaW50IGltY3RyOw0KPiArfTsNCj4gKw0KPiArc3RydWN0IGlwbW11X3Ztc2FfYmFj a3VwIHsNCj4gKyAgICBzdHJ1Y3QgZGV2aWNlICpkZXY7DQo+ICsgICAgdW5zaWduZWQgaW50ICp1 dGxic192YWw7DQo+ICsgICAgdW5zaWduZWQgaW50ICphc2lkc192YWw7DQo+ICsgICAgc3RydWN0 IGxpc3RfaGVhZCBsaXN0Ow0KPiArfTsNCj4gKw0KPiArI2VuZGlmDQo+ICsNCj4gICAvKiBSb290 L0NhY2hlIElQTU1VIGRldmljZSdzIGluZm9ybWF0aW9uICovDQo+ICAgc3RydWN0IGlwbW11X3Zt c2FfZGV2aWNlIHsNCj4gICAgICAgc3RydWN0IGRldmljZSAqZGV2Ow0KPiBAQCAtMTQyLDYgKzE2 Miw5IEBAIHN0cnVjdCBpcG1tdV92bXNhX2RldmljZSB7DQo+ICAgICAgIHN0cnVjdCBpcG1tdV92 bXNhX2RvbWFpbiAqZG9tYWluc1tJUE1NVV9DVFhfTUFYXTsNCj4gICAgICAgdW5zaWduZWQgaW50 IHV0bGJfcmVmY291bnRbSVBNTVVfVVRMQl9NQVhdOw0KPiAgICAgICBjb25zdCBzdHJ1Y3QgaXBt bXVfZmVhdHVyZXMgKmZlYXR1cmVzOw0KPiArI2lmZGVmIENPTkZJR19TWVNURU1fU1VTUEVORA0K PiArICAgIHN0cnVjdCBpcG1tdV9yZWdfY3R4ICpyZWdfYmFja3VwW0lQTU1VX0NUWF9NQVhdOw0K PiArI2VuZGlmDQo+ICAgfTsNCj4gICANCj4gICAvKg0KPiBAQCAtNTQ3LDYgKzU3MCwyMjIgQEAg c3RhdGljIHZvaWQgaXBtbXVfZG9tYWluX2ZyZWVfY29udGV4dChzdHJ1Y3QgaXBtbXVfdm1zYV9k ZXZpY2UgKm1tdSwNCj4gICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmbW11LT5sb2NrLCBm bGFncyk7DQo+ICAgfQ0KPiAgIA0KPiArI2lmZGVmIENPTkZJR19TWVNURU1fU1VTUEVORA0KPiAr DQo+ICtzdGF0aWMgREVGSU5FX1NQSU5MT0NLKGlwbW11X2RldmljZXNfYmFja3VwX2xvY2spOw0K PiArc3RhdGljIExJU1RfSEVBRChpcG1tdV9kZXZpY2VzX2JhY2t1cCk7DQo+ICsNCj4gK3N0YXRp YyBzdHJ1Y3QgaXBtbXVfcmVnX2N0eCByb290X3BndGFibGVbSVBNTVVfQ1RYX01BWF07DQo+ICsN Cj4gK3N0YXRpYyB1aW50MzJfdCBpcG1tdV9pbXVhc2lkX3JlYWQoc3RydWN0IGlwbW11X3Ztc2Ff ZGV2aWNlICptbXUsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln bmVkIGludCB1dGxiKQ0KPiArew0KPiArICAgIHJldHVybiBpcG1tdV9yZWFkKG1tdSwgaXBtbXVf dXRsYl9yZWcobW11LCBJTVVBU0lEKHV0bGIpKSk7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyB2b2lk IGlwbW11X3V0bGJzX2JhY2t1cChzdHJ1Y3QgaXBtbXVfdm1zYV9kZXZpY2UgKm1tdSkNCj4gK3sN Cj4gKyAgICBzdHJ1Y3QgaXBtbXVfdm1zYV9iYWNrdXAgKmJhY2t1cF9kYXRhOw0KPiArDQo+ICsg ICAgZGV2X2RiZyhtbXUtPmRldiwgIkhhbmRsZSBtaWNyby1UTEJzIGJhY2t1cFxuIik7DQo+ICsN Cj4gKyAgICBzcGluX2xvY2soJmlwbW11X2RldmljZXNfYmFja3VwX2xvY2spOw0KPiArDQo+ICsg ICAgbGlzdF9mb3JfZWFjaF9lbnRyeSggYmFja3VwX2RhdGEsICZpcG1tdV9kZXZpY2VzX2JhY2t1 cCwgbGlzdCApDQo+ICsgICAgew0KPiArICAgICAgICBzdHJ1Y3QgaW9tbXVfZndzcGVjICpmd3Nw ZWMgPSBkZXZfaW9tbXVfZndzcGVjX2dldChiYWNrdXBfZGF0YS0+ZGV2KTsNCj4gKyAgICAgICAg dW5zaWduZWQgaW50IGk7DQo+ICsNCj4gKyAgICAgICAgaWYgKCB0b19pcG1tdShiYWNrdXBfZGF0 YS0+ZGV2KSAhPSBtbXUgKQ0KPiArICAgICAgICAgICAgY29udGludWU7DQo+ICsNCj4gKyAgICAg ICAgZm9yICggaSA9IDA7IGkgPCBmd3NwZWMtPm51bV9pZHM7IGkrKyApDQo+ICsgICAgICAgIHsN Cj4gKyAgICAgICAgICAgIHVuc2lnbmVkIGludCB1dGxiID0gZndzcGVjLT5pZHNbaV07DQo+ICsN Cj4gKyAgICAgICAgICAgIGJhY2t1cF9kYXRhLT5hc2lkc192YWxbaV0gPSBpcG1tdV9pbXVhc2lk X3JlYWQobW11LCB1dGxiKTsNCj4gKyAgICAgICAgICAgIGJhY2t1cF9kYXRhLT51dGxic192YWxb aV0gPSBpcG1tdV9pbXVjdHJfcmVhZChtbXUsIHV0bGIpOw0KPiArICAgICAgICB9DQo+ICsgICAg fQ0KPiArDQo+ICsgICAgc3Bpbl91bmxvY2soJmlwbW11X2RldmljZXNfYmFja3VwX2xvY2spOw0K PiArfQ0KPiArDQo+ICtzdGF0aWMgdm9pZCBpcG1tdV91dGxic19yZXN0b3JlKHN0cnVjdCBpcG1t dV92bXNhX2RldmljZSAqbW11KQ0KPiArew0KPiArICAgIHN0cnVjdCBpcG1tdV92bXNhX2JhY2t1 cCAqYmFja3VwX2RhdGE7DQo+ICsNCj4gKyAgICBkZXZfZGJnKG1tdS0+ZGV2LCAiSGFuZGxlIG1p Y3JvLVRMQnMgcmVzdG9yZVxuIik7DQo+ICsNCj4gKyAgICBzcGluX2xvY2soJmlwbW11X2Rldmlj ZXNfYmFja3VwX2xvY2spOw0KPiArDQo+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeSggYmFja3Vw X2RhdGEsICZpcG1tdV9kZXZpY2VzX2JhY2t1cCwgbGlzdCApDQo+ICsgICAgew0KPiArICAgICAg ICBzdHJ1Y3QgaW9tbXVfZndzcGVjICpmd3NwZWMgPSBkZXZfaW9tbXVfZndzcGVjX2dldChiYWNr dXBfZGF0YS0+ZGV2KTsNCj4gKyAgICAgICAgdW5zaWduZWQgaW50IGk7DQo+ICsNCj4gKyAgICAg ICAgaWYgKCB0b19pcG1tdShiYWNrdXBfZGF0YS0+ZGV2KSAhPSBtbXUgKQ0KPiArICAgICAgICAg ICAgY29udGludWU7DQo+ICsNCj4gKyAgICAgICAgZm9yICggaSA9IDA7IGkgPCBmd3NwZWMtPm51 bV9pZHM7IGkrKyApDQo+ICsgICAgICAgIHsNCj4gKyAgICAgICAgICAgIHVuc2lnbmVkIGludCB1 dGxiID0gZndzcGVjLT5pZHNbaV07DQo+ICsNCj4gKyAgICAgICAgICAgIGlwbW11X2ltdWFzaWRf d3JpdGUobW11LCB1dGxiLCBiYWNrdXBfZGF0YS0+YXNpZHNfdmFsW2ldKTsNCj4gKyAgICAgICAg ICAgIGlwbW11X2ltdWN0cl93cml0ZShtbXUsIHV0bGIsIGJhY2t1cF9kYXRhLT51dGxic192YWxb aV0pOw0KPiArICAgICAgICB9DQo+ICsgICAgfQ0KPiArDQo+ICsgICAgc3Bpbl91bmxvY2soJmlw bW11X2RldmljZXNfYmFja3VwX2xvY2spOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgdm9pZCBpcG1t dV9kb21haW5fYmFja3VwX2NvbnRleHQoc3RydWN0IGlwbW11X3Ztc2FfZG9tYWluICpkb21haW4p DQo+ICt7DQo+ICsgICAgc3RydWN0IGlwbW11X3Ztc2FfZGV2aWNlICptbXUgPSBkb21haW4tPm1t dS0+cm9vdDsNCj4gKyAgICBzdHJ1Y3QgaXBtbXVfcmVnX2N0eCAqcmVncyA9IG1tdS0+cmVnX2Jh Y2t1cFtkb21haW4tPmNvbnRleHRfaWRdOw0KPiArDQo+ICsgICAgZGV2X2RiZyhtbXUtPmRldiwg IkhhbmRsZSBkb21haW4gY29udGV4dCAldSBiYWNrdXBcbiIsIGRvbWFpbi0+Y29udGV4dF9pZCk7 DQo+ICsNCj4gKyAgICByZWdzLT5pbXR0bGJyMCA9IGlwbW11X2N0eF9yZWFkX3Jvb3QoZG9tYWlu LCBJTVRUTEJSMCk7DQo+ICsgICAgcmVncy0+aW10dHVicjAgPSBpcG1tdV9jdHhfcmVhZF9yb290 KGRvbWFpbiwgSU1UVFVCUjApOw0KPiArICAgIHJlZ3MtPmltdHRiY3IgID0gaXBtbXVfY3R4X3Jl YWRfcm9vdChkb21haW4sIElNVFRCQ1IpOw0KPiArICAgIHJlZ3MtPmltY3RyICAgID0gaXBtbXVf Y3R4X3JlYWRfcm9vdChkb21haW4sIElNQ1RSKTsNCj4gK30NCj4gKw0KPiArc3RhdGljIHZvaWQg aXBtbXVfZG9tYWluX3Jlc3RvcmVfY29udGV4dChzdHJ1Y3QgaXBtbXVfdm1zYV9kb21haW4gKmRv bWFpbikNCj4gK3sNCj4gKyAgICBzdHJ1Y3QgaXBtbXVfdm1zYV9kZXZpY2UgKm1tdSA9IGRvbWFp bi0+bW11LT5yb290Ow0KPiArICAgIHN0cnVjdCBpcG1tdV9yZWdfY3R4ICpyZWdzICA9IG1tdS0+ cmVnX2JhY2t1cFtkb21haW4tPmNvbnRleHRfaWRdOw0KPiArDQo+ICsgICAgZGV2X2RiZyhtbXUt PmRldiwgIkhhbmRsZSBkb21haW4gY29udGV4dCAldSByZXN0b3JlXG4iLCBkb21haW4tPmNvbnRl eHRfaWQpOw0KPiArDQo+ICsgICAgaXBtbXVfY3R4X3dyaXRlX3Jvb3QoZG9tYWluLCBJTVRUTEJS MCwgcmVncy0+aW10dGxicjApOw0KPiArICAgIGlwbW11X2N0eF93cml0ZV9yb290KGRvbWFpbiwg SU1UVFVCUjAsIHJlZ3MtPmltdHR1YnIwKTsNCj4gKyAgICBpcG1tdV9jdHhfd3JpdGVfcm9vdChk b21haW4sIElNVFRCQ1IsICByZWdzLT5pbXR0YmNyKTsNCj4gKyAgICBpcG1tdV9jdHhfd3JpdGVf YWxsKGRvbWFpbiwgIElNQ1RSLCAgICByZWdzLT5pbWN0ciB8IElNQ1RSX0ZMVVNIKTsNCj4gK30N Cj4gKw0KPiArLyoNCj4gKyAqIFhlbjogVW5saWtlIExpbnV4IGltcGxlbWVudGF0aW9uLCBYZW4g dXNlcyBhIHNpbmdsZSBkcml2ZXIgaW5zdGFuY2UNCj4gKyAqIGZvciBoYW5kbGluZyBhbGwgSVBN TVVzLiBUaGVyZSBpcyBubyBmcmFtZXdvcmsgZm9yIGlwbW11X3N1c3BlbmQvcmVzdW1lDQo+ICsg KiBjYWxsYmFja3MgdG8gYmUgaW52b2tlZCBmb3IgZWFjaCBJUE1NVSBkZXZpY2UuIFNvLCB3ZSBu ZWVkIHRvIGl0ZXJhdGUNCj4gKyAqIHRocm91Z2ggYWxsIHJlZ2lzdGVyZWQgSVBNTVVzIHBlcmZv cm1pbmcgcmVxdWlyZWQgYWN0aW9ucy4NCj4gKyAqDQo+ICsgKiBBbHNvIHRha2UgY2FyZSBvZiBy ZXN0b3Jpbmcgc3BlY2lhbCBzZXR0aW5ncywgc3VjaCBhcyB0cmFuc2xhdGlvbg0KPiArICogdGFi bGUgZm9ybWF0LCBldGMuDQo+ICsgKi8NCj4gK3N0YXRpYyBpbnQgX19tdXN0X2NoZWNrIGlwbW11 X3N1c3BlbmQodm9pZCkNCj4gK3sNCj4gKyAgICBzdHJ1Y3QgaXBtbXVfdm1zYV9kZXZpY2UgKm1t dTsNCj4gKw0KPiArICAgIGlmICggIWlvbW11X2VuYWJsZWQgKQ0KPiArICAgICAgICByZXR1cm4g MDsNCj4gKw0KPiArICAgIHByaW50ayhYRU5MT0dfREVCVUcgImlwbW11OiBTdXNwZW5kaW5nIC4u LlxuIik7DQo+ICsNCj4gKyAgICBzcGluX2xvY2soJmlwbW11X2RldmljZXNfbG9jayk7DQo+ICsN Cj4gKyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KCBtbXUsICZpcG1tdV9kZXZpY2VzLCBsaXN0ICkN Cj4gKyAgICB7DQo+ICsgICAgICAgIGlmICggaXBtbXVfaXNfcm9vdChtbXUpICkNCj4gKyAgICAg ICAgew0KPiArICAgICAgICAgICAgdW5zaWduZWQgaW50IGk7DQo+ICsNCj4gKyAgICAgICAgICAg IGZvciAoIGkgPSAwOyBpIDwgbW11LT5udW1fY3R4OyBpKysgKQ0KPiArICAgICAgICAgICAgew0K PiArICAgICAgICAgICAgICAgIGlmICggIW1tdS0+ZG9tYWluc1tpXSApDQo+ICsgICAgICAgICAg ICAgICAgICAgIGNvbnRpbnVlOw0KPiArICAgICAgICAgICAgICAgIGlwbW11X2RvbWFpbl9iYWNr dXBfY29udGV4dChtbXUtPmRvbWFpbnNbaV0pOw0KPiArICAgICAgICAgICAgfQ0KPiArICAgICAg ICB9DQo+ICsgICAgICAgIGVsc2UNCj4gKyAgICAgICAgICAgIGlwbW11X3V0bGJzX2JhY2t1cCht bXUpOw0KPiArICAgIH0NCj4gKw0KPiArICAgIHNwaW5fdW5sb2NrKCZpcG1tdV9kZXZpY2VzX2xv Y2spOw0KPiArDQo+ICsgICAgcmV0dXJuIDA7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyB2b2lkIGlw bW11X3Jlc3VtZSh2b2lkKQ0KPiArew0KPiArICAgIHN0cnVjdCBpcG1tdV92bXNhX2RldmljZSAq bW11Ow0KPiArDQo+ICsgICAgaWYgKCAhaW9tbXVfZW5hYmxlZCApDQo+ICsgICAgICAgIHJldHVy bjsNCj4gKw0KPiArICAgIHByaW50ayhYRU5MT0dfREVCVUcgImlwbW11OiBSZXN1bWluZyAuLi5c biIpOw0KPiArDQo+ICsgICAgc3Bpbl9sb2NrKCZpcG1tdV9kZXZpY2VzX2xvY2spOw0KPiArDQo+ ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeSggbW11LCAmaXBtbXVfZGV2aWNlcywgbGlzdCApDQo+ ICsgICAgew0KPiArICAgICAgICB1aW50MzJfdCByZWc7DQo+ICsNCj4gKyAgICAgICAgLyogRG8g bm90IHVzZSBzZWN1cml0eSBncm91cCBmdW5jdGlvbiAqLw0KPiArICAgICAgICByZWcgPSBJTVND VExSICsgbW11LT5mZWF0dXJlcy0+Y29udHJvbF9vZmZzZXRfYmFzZTsNCj4gKyAgICAgICAgaXBt bXVfd3JpdGUobW11LCByZWcsIGlwbW11X3JlYWQobW11LCByZWcpICYgfklNU0NUTFJfVVNFX1NF Q0dSUCk7DQo+ICsNCj4gKyAgICAgICAgaWYgKCBpcG1tdV9pc19yb290KG1tdSkgKQ0KPiArICAg ICAgICB7DQo+ICsgICAgICAgICAgICB1bnNpZ25lZCBpbnQgaTsNCj4gKw0KPiArICAgICAgICAg ICAgLyogVXNlIHN0YWdlIDIgdHJhbnNsYXRpb24gdGFibGUgZm9ybWF0ICovDQo+ICsgICAgICAg ICAgICByZWcgPSBJTVNBVVhDVExSICsgbW11LT5mZWF0dXJlcy0+Y29udHJvbF9vZmZzZXRfYmFz ZTsNCj4gKyAgICAgICAgICAgIGlwbW11X3dyaXRlKG1tdSwgcmVnLCBpcG1tdV9yZWFkKG1tdSwg cmVnKSB8IElNU0FVWENUTFJfUzJQVEUpOw0KPiArDQo+ICsgICAgICAgICAgICBmb3IgKCBpID0g MDsgaSA8IG1tdS0+bnVtX2N0eDsgaSsrICkNCj4gKyAgICAgICAgICAgIHsNCj4gKyAgICAgICAg ICAgICAgICBpZiAoICFtbXUtPmRvbWFpbnNbaV0gKQ0KPiArICAgICAgICAgICAgICAgICAgICBj b250aW51ZTsNCj4gKyAgICAgICAgICAgICAgICBpcG1tdV9kb21haW5fcmVzdG9yZV9jb250ZXh0 KG1tdS0+ZG9tYWluc1tpXSk7DQo+ICsgICAgICAgICAgICB9DQo+ICsgICAgICAgIH0NCj4gKyAg ICAgICAgZWxzZQ0KPiArICAgICAgICAgICAgaXBtbXVfdXRsYnNfcmVzdG9yZShtbXUpOw0KPiAr ICAgIH0NCj4gKw0KPiArICAgIHNwaW5fdW5sb2NrKCZpcG1tdV9kZXZpY2VzX2xvY2spOw0KPiAr fQ0KPiArDQo+ICtzdGF0aWMgaW50IGlwbW11X2FsbG9jX2N0eF9zdXNwZW5kKHN0cnVjdCBkZXZp Y2UgKmRldikNCj4gK3sNCj4gKyAgICBzdHJ1Y3QgaXBtbXVfdm1zYV9iYWNrdXAgKmJhY2t1cF9k YXRhOw0KPiArICAgIHVuc2lnbmVkIGludCAqdXRsYnNfdmFsLCAqYXNpZHNfdmFsOw0KPiArICAg IHN0cnVjdCBpb21tdV9md3NwZWMgKmZ3c3BlYyA9IGRldl9pb21tdV9md3NwZWNfZ2V0KGRldik7 DQo+ICsNCj4gKyAgICB1dGxic192YWwgPSB4emFsbG9jX2FycmF5KHVuc2lnbmVkIGludCwgZndz cGVjLT5udW1faWRzKTsNCj4gKyAgICBpZiAoICF1dGxic192YWwgKQ0KPiArICAgICAgICByZXR1 cm4gLUVOT01FTTsNCj4gKw0KPiArICAgIGFzaWRzX3ZhbCA9IHh6YWxsb2NfYXJyYXkodW5zaWdu ZWQgaW50LCBmd3NwZWMtPm51bV9pZHMpOw0KPiArICAgIGlmICggIWFzaWRzX3ZhbCApDQo+ICsg ICAgew0KPiArICAgICAgICB4ZnJlZSh1dGxic192YWwpOw0KPiArICAgICAgICByZXR1cm4gLUVO T01FTTsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBiYWNrdXBfZGF0YSA9IHh6YWxsb2Moc3RydWN0 IGlwbW11X3Ztc2FfYmFja3VwKTsNCj4gKyAgICBpZiAoICFiYWNrdXBfZGF0YSApDQo+ICsgICAg ew0KPiArICAgICAgICB4ZnJlZSh1dGxic192YWwpOw0KPiArICAgICAgICB4ZnJlZShhc2lkc192 YWwpOw0KPiArICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBi YWNrdXBfZGF0YS0+ZGV2ID0gZGV2Ow0KPiArICAgIGJhY2t1cF9kYXRhLT51dGxic192YWwgPSB1 dGxic192YWw7DQo+ICsgICAgYmFja3VwX2RhdGEtPmFzaWRzX3ZhbCA9IGFzaWRzX3ZhbDsNCj4g Kw0KPiArICAgIHNwaW5fbG9jaygmaXBtbXVfZGV2aWNlc19iYWNrdXBfbG9jayk7DQo+ICsgICAg bGlzdF9hZGQoJmJhY2t1cF9kYXRhLT5saXN0LCAmaXBtbXVfZGV2aWNlc19iYWNrdXApOw0KPiAr ICAgIHNwaW5fdW5sb2NrKCZpcG1tdV9kZXZpY2VzX2JhY2t1cF9sb2NrKTsNCj4gKw0KPiArICAg IHJldHVybiAwOw0KPiArfQ0KPiArDQo+ICsjZW5kaWYgLyogQ09ORklHX1NZU1RFTV9TVVNQRU5E ICovDQo+ICsNCj4gICBzdGF0aWMgaW50IGlwbW11X2RvbWFpbl9pbml0X2NvbnRleHQoc3RydWN0 IGlwbW11X3Ztc2FfZG9tYWluICpkb21haW4pDQo+ICAgew0KPiAgICAgICB1aW50NjRfdCB0dGJy Ow0KPiBAQCAtNTU5LDYgKzc5OCw5IEBAIHN0YXRpYyBpbnQgaXBtbXVfZG9tYWluX2luaXRfY29u dGV4dChzdHJ1Y3QgaXBtbXVfdm1zYV9kb21haW4gKmRvbWFpbikNCj4gICAgICAgICAgIHJldHVy biByZXQ7DQo+ICAgDQo+ICAgICAgIGRvbWFpbi0+Y29udGV4dF9pZCA9IHJldDsNCj4gKyNpZmRl ZiBDT05GSUdfU1lTVEVNX1NVU1BFTkQNCj4gKyAgICBkb21haW4tPm1tdS0+cm9vdC0+cmVnX2Jh Y2t1cFtyZXRdID0gJnJvb3RfcGd0YWJsZVtyZXRdOw0KPiArI2VuZGlmDQo+ICAgDQo+ICAgICAg IC8qDQo+ICAgICAgICAqIFRUQlIwDQo+IEBAIC02MTUsNiArODU3LDkgQEAgc3RhdGljIHZvaWQg aXBtbXVfZG9tYWluX2Rlc3Ryb3lfY29udGV4dChzdHJ1Y3QgaXBtbXVfdm1zYV9kb21haW4gKmRv bWFpbikNCj4gICAgICAgaXBtbXVfY3R4X3dyaXRlX3Jvb3QoZG9tYWluLCBJTUNUUiwgSU1DVFJf RkxVU0gpOw0KPiAgICAgICBpcG1tdV90bGJfc3luYyhkb21haW4pOw0KPiAgIA0KPiArI2lmZGVm IENPTkZJR19TWVNURU1fU1VTUEVORA0KPiArICAgIGRvbWFpbi0+bW11LT5yb290LT5yZWdfYmFj a3VwW2RvbWFpbi0+Y29udGV4dF9pZF0gPSBOVUxMOw0KPiArI2VuZGlmDQo+ICAgICAgIGlwbW11 X2RvbWFpbl9mcmVlX2NvbnRleHQoZG9tYWluLT5tbXUtPnJvb3QsIGRvbWFpbi0+Y29udGV4dF9p ZCk7DQo+ICAgfQ0KPiAgIA0KPiBAQCAtMTQyNyw2ICsxNjcyLDE0IEBAIHN0YXRpYyBpbnQgaXBt bXVfYWRkX2RldmljZSh1OCBkZXZmbiwgc3RydWN0IGRldmljZSAqZGV2KQ0KPiAgICAgICB9DQo+ ICAgI2VuZGlmDQo+ICAgDQo+ICsjaWZkZWYgQ09ORklHX1NZU1RFTV9TVVNQRU5EDQo+ICsgICAg aWYgKCBpcG1tdV9hbGxvY19jdHhfc3VzcGVuZChkZXYpICkNCj4gKyAgICB7DQo+ICsgICAgICAg IGRldl9lcnIoZGV2LCAiRmFpbGVkIHRvIGFsbG9jYXRlIGNvbnRleHQgZm9yIHN1c3BlbmRcbiIp Ow0KPiArICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4gKyAgICB9DQo+ICsjZW5kaWYNCg0KLi4u IFRoZSBpbml0aWFsIHZlcnNpb24gd2FzIGJhc2VkIG9uIHRoZSBkcml2ZXIgY29kZSB3aXRob3V0 IFBDSSANCnN1cHBvcnQsIGJ1dCBpdCBpcyBub3cgcHJlc2VudC4gVGhlcmUgaXMgUENJLXNwZWNp ZmljIGNvZGUgYWJvdmUgaW4gdGhpcyANCmZ1bmN0aW9uIChub3QgdmlzaWJsZSBpbiB0aGUgY29u dGV4dCkgdGhhdCBwZXJmb3JtcyBzb21lIGluaXRpYWxpemF0aW9uLCANCmFsbG9jYXRpb24gYW5k IGRldmljZSBhc3NpZ25tZW50LiBXaGF0IEkgbWVhbiBpcyB0aGF0IGluIGNhc2Ugb2YgdGhlIA0K c3VzcGVuZCBjb250ZXh0IGFsbG9jYXRpb24gZXJyb3IgaGVyZSwgd2Ugd2lsbCBuZWVkIHRvIHVu ZG8gdGhlc2UgDQphY3Rpb25zIChpLmUuIGRlYXNzaWduIGRldmljZSkuIEkgd291bGQgbW92ZSB0 aGlzIGNvbnRleHQgYWxsb2NhdGlvbiANCih3aG9zZSBwcm9iYWJpbGl0eSB0byBmYWlsIGlzIG11 Y2ggbG93ZXIgdGhhbiB3aGF0IGlzIGRvbmUgZm9yIFBDSSBkZXYpIA0KYWJvdmUgdGhlIFBDSS1z cGVjaWZpYyBzdHVmZiwgYW5kIHBlcmZvcm0gdGhlIGNvbnRleHQgZnJlZWluZyBvbiB0aGUgDQpl cnJvciBwYXRoLg0KDQo+ICsNCj4gICAgICAgZGV2X2luZm8oZGV2LCAiQWRkZWQgbWFzdGVyIGRl dmljZSAoSVBNTVUgJXMgbWljcm8tVExCcyAldSlcbiIsDQo+ICAgICAgICAgICAgICAgIGRldl9u YW1lKGZ3c3BlYy0+aW9tbXVfZGV2KSwgZndzcGVjLT5udW1faWRzKTsNCj4gICANCj4gQEAgLTE0 OTIsNiArMTc0NSwxMCBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IGlvbW11X29wcyBpcG1tdV9pb21t dV9vcHMgPQ0KPiAgICAgICAudW5tYXBfcGFnZSAgICAgID0gYXJtX2lvbW11X3VubWFwX3BhZ2Us DQo+ICAgICAgIC5kdF94bGF0ZSAgICAgICAgPSBpcG1tdV9kdF94bGF0ZSwNCj4gICAgICAgLmFk ZF9kZXZpY2UgICAgICA9IGlwbW11X2FkZF9kZXZpY2UsDQo+ICsjaWZkZWYgQ09ORklHX1NZU1RF TV9TVVNQRU5EDQo+ICsgICAgLnN1c3BlbmQgICAgICAgICA9IGlwbW11X3N1c3BlbmQsDQo+ICsg ICAgLnJlc3VtZSAgICAgICAgICA9IGlwbW11X3Jlc3VtZSwNCj4gKyNlbmRpZg0KPiAgIH07DQo+ ICAgDQo+ICAgc3RhdGljIF9faW5pdCBpbnQgaXBtbXVfaW5pdChzdHJ1Y3QgZHRfZGV2aWNlX25v ZGUgKm5vZGUsIGNvbnN0IHZvaWQgKmRhdGEpDQo= From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:23:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:23:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108053.1458187 (Exim 4.92) (envelope-from ) id 1utkeR-0001Au-6q; Wed, 03 Sep 2025 10:23:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108053.1458187; Wed, 03 Sep 2025 10:23:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utkeR-0001An-36; Wed, 03 Sep 2025 10:23:39 +0000 Received: by outflank-mailman (input) for mailman id 1108053; Wed, 03 Sep 2025 10:23: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 1utkeP-0001Ah-Nk for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:23:37 +0000 Received: from rein-hpcbdc09 (unknown [1.6.89.6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ac8769e-88b0-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:23:34 +0200 (CEST) Received: by rein-hpcbdc09 (Postfix, from userid 1000) id A8E7A80C0658; Wed, 3 Sep 2025 15:53:30 +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: 0ac8769e-88b0-11f0-9809-7dc792cee155 From: Jahan Murudi To: xen-devel@lists.xenproject.org Cc: Jahan Murudi , Anthony PERARD Subject: [PATCH v4 0/4] xentop: add physical CPU usage support Date: Wed, 3 Sep 2025 15:53:19 +0530 Message-Id: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This is v4 of the patch series to add physical CPU monitoring to xentop. Changes since v3: - Split the single large patch into a logical series of 3 smaller patches for easier review. - Fixed the memory allocation error handling in pcpu.c as pointed out by Anthony PERARD. The realloc() result is now assigned immediately to avoid invalid pointers on failure. - Simplified the time calculation by using a single global timestamp instead of a per-CPU array, as the time difference is the same for all cores. - Removed the unnecessary check for small time intervals which could lead to incorrect usage calculations. - Integrated the PCPU display with the existing print() function to ensure correct behavior in both interactive and batch modes. The series adds a new '-p'/'--pcpus' flag to xentop. When enabled, it displays a table showing the usage percentage of each physical CPU core in the system. Jahan Murudi (4): xentop: add pcpu header and basic infrastructure xentop: add pcpu implementation with proper error handling xentop: update Makefile to link against libxenctrl xentop: integrate pcpu support into main program tools/xentop/Makefile | 5 +- tools/xentop/pcpu.c | 141 ++++++++++++++++++++++++++++++++++++++++++ tools/xentop/pcpu.h | 17 +++++ tools/xentop/xentop.c | 79 +++++++++++++++++------ 4 files changed, 222 insertions(+), 20 deletions(-) create mode 100644 tools/xentop/pcpu.c create mode 100644 tools/xentop/pcpu.h -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:23:49 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:23:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108054.1458197 (Exim 4.92) (envelope-from ) id 1utkeb-0001R5-DF; Wed, 03 Sep 2025 10:23:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108054.1458197; Wed, 03 Sep 2025 10:23:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utkeb-0001Qw-AD; Wed, 03 Sep 2025 10:23:49 +0000 Received: by outflank-mailman (input) for mailman id 1108054; Wed, 03 Sep 2025 10: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 1utkeZ-0001Ah-Km for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:23:47 +0000 Received: from rein-hpcbdc09 (unknown [1.6.89.6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 120b53b1-88b0-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:23:45 +0200 (CEST) Received: by rein-hpcbdc09 (Postfix, from userid 1000) id 6175880C06CE; Wed, 3 Sep 2025 15:53:44 +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: 120b53b1-88b0-11f0-9809-7dc792cee155 From: Jahan Murudi To: xen-devel@lists.xenproject.org Cc: Jahan Murudi , Anthony PERARD Subject: [PATCH v4 1/4] xentop: add pcpu header and basic infrastructure Date: Wed, 3 Sep 2025 15:53:20 +0530 Message-Id: <20250903102323.2553142-2-jahan.murudi.zg@renesas.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce a new header (pcpu.h) which defines the interfaces for physical CPU statistics collection. This provides the basic infrastructure needed to track per-CPU usage and will be used in subsequent patches. Signed-off-by: Jahan Murudi --- tools/xentop/pcpu.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 tools/xentop/pcpu.h diff --git a/tools/xentop/pcpu.h b/tools/xentop/pcpu.h new file mode 100644 index 0000000000..a528177476 --- /dev/null +++ b/tools/xentop/pcpu.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2025 Renesas Electronics Corporation + */ + +#ifndef __XENTOP_PCPU_H__ +#define __XENTOP_PCPU_H__ + +#include + +int update_pcpu_stats(const struct timeval *now, unsigned int delay); +int get_pcpu_count(void); +float get_pcpu_usage(int cpu_index); +int has_pcpu_data(void); +void free_pcpu_stats(void); + +#endif /* __XENTOP_PCPU_H__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:24:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:24:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108060.1458207 (Exim 4.92) (envelope-from ) id 1utkeo-0001wH-KR; Wed, 03 Sep 2025 10:24:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108060.1458207; Wed, 03 Sep 2025 10:24:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utkeo-0001w6-Hd; Wed, 03 Sep 2025 10:24:02 +0000 Received: by outflank-mailman (input) for mailman id 1108060; Wed, 03 Sep 2025 10:24:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utkem-0001Ah-Ua for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:24:00 +0000 Received: from rein-hpcbdc09 (unknown [1.6.89.6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 19e2120a-88b0-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:23:59 +0200 (CEST) Received: by rein-hpcbdc09 (Postfix, from userid 1000) id 871E680C0822; Wed, 3 Sep 2025 15:53:57 +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: 19e2120a-88b0-11f0-9809-7dc792cee155 From: Jahan Murudi To: xen-devel@lists.xenproject.org Cc: Jahan Murudi , Anthony PERARD Subject: [PATCH v4 2/4] xentop: add pcpu implementation with proper error handling Date: Wed, 3 Sep 2025 15:53:21 +0530 Message-Id: <20250903102323.2553142-3-jahan.murudi.zg@renesas.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce pcpu.c which implements physical CPU statistics collection using xc_getcpuinfo(). The code handles allocation and reallocation of statistics buffers, maintains previous idle times, and calculates usage percentages. Proper error handling and cleanup are provided to ensure robustness in the face of allocation or hypervisor API failures. Signed-off-by: Jahan Murudi --- tools/xentop/pcpu.c | 141 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 tools/xentop/pcpu.c diff --git a/tools/xentop/pcpu.c b/tools/xentop/pcpu.c new file mode 100644 index 0000000000..cdb4cb2131 --- /dev/null +++ b/tools/xentop/pcpu.c @@ -0,0 +1,141 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2025 Renesas Electronics Corporation + */ + +#include +#include +#include +#include +#include +#include +#include "pcpu.h" + +#define MAX_PCPUS 128 + +typedef struct { + float usage_pct; +} pcpu_stat_t; + +static pcpu_stat_t *pcpu_stats = NULL; +static uint64_t *prev_idle = NULL; +static int allocated_pcpus = 0; +static xc_interface *xc_handle = NULL; +static uint64_t prev_global_time = 0; + +static void report_pcpu_error(const char *context) +{ + fprintf(stderr, "PCPU error: %s (%s)\n", context, strerror(errno)); +} + +int update_pcpu_stats(const struct timeval *now, unsigned int delay_sec) +{ + struct xen_sysctl_cpuinfo info[MAX_PCPUS]; + int detected_cpus = 0; + int ret, i; + uint64_t current_time = (uint64_t)now->tv_sec * 1000000ULL + now->tv_usec; + uint64_t time_diff; + + if (!xc_handle) { + xc_handle = xc_interface_open(NULL, NULL, 0); + if (!xc_handle) { + report_pcpu_error("xc_interface_open failed"); + return -1; + } + } + + ret = xc_getcpuinfo(xc_handle, MAX_PCPUS, info, &detected_cpus); + if (ret < 0) { + report_pcpu_error("xc_getcpuinfo failed"); + return -1; + } + + /* Allocate/reallocate memory if needed */ + if (!pcpu_stats || detected_cpus > allocated_pcpus) { + pcpu_stat_t *new_stats = realloc(pcpu_stats, + detected_cpus * sizeof(*pcpu_stats)); + if (!new_stats) goto alloc_error; + + pcpu_stats = new_stats; + + uint64_t *new_prev_idle = realloc(prev_idle, + detected_cpus * sizeof(*prev_idle)); + if (!new_prev_idle) goto alloc_error; + + prev_idle = new_prev_idle; + allocated_pcpus = detected_cpus; + + /* Initialize new entries */ + for (i = 0; i < detected_cpus; i++) { + prev_idle[i] = info[i].idletime / 1000; /* ns->us */ + pcpu_stats[i].usage_pct = 0.0; + } + + /* Set initial global time reference */ + prev_global_time = current_time; + return 0; + } + + /* Calculate time difference since last update */ + time_diff = current_time - prev_global_time; + + /* Calculate CPU usage for each core */ + for (i = 0; i < detected_cpus; i++) { + uint64_t current_idle = info[i].idletime / 1000; + uint64_t idle_diff = current_idle - prev_idle[i]; + + if (time_diff > 0) { + double usage = 100.0 * (1.0 - ((double)idle_diff / time_diff)); + /* Clamp between 0-100% */ + pcpu_stats[i].usage_pct = (usage < 0) ? 0.0 : + (usage > 100) ? 100.0 : usage; + } else { + pcpu_stats[i].usage_pct = 0.0; + } + + prev_idle[i] = current_idle; + } + + /* Update global time reference for next calculation */ + prev_global_time = current_time; + + return 0; + +alloc_error: + free_pcpu_stats(); + errno = ENOMEM; + report_pcpu_error("memory allocation failed"); + return -1; +} + +/* Accessor functions for xentop.c */ +int get_pcpu_count(void) +{ + return allocated_pcpus; +} + +float get_pcpu_usage(int cpu_index) +{ + if (!pcpu_stats || cpu_index < 0 || cpu_index >= allocated_pcpus) { + return 0.0; + } + return pcpu_stats[cpu_index].usage_pct; +} + +int has_pcpu_data(void) +{ + return (pcpu_stats != NULL && allocated_pcpus > 0); +} + +void free_pcpu_stats(void) +{ + if (xc_handle) { + xc_interface_close(xc_handle); + xc_handle = NULL; + } + free(pcpu_stats); + pcpu_stats = NULL; + free(prev_idle); + prev_idle = NULL; + allocated_pcpus = 0; +} -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:24:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:24:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108061.1458218 (Exim 4.92) (envelope-from ) id 1utkep-0002Bx-SF; Wed, 03 Sep 2025 10:24:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108061.1458218; Wed, 03 Sep 2025 10: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 1utkep-0002Bo-Nl; Wed, 03 Sep 2025 10:24:03 +0000 Received: by outflank-mailman (input) for mailman id 1108061; Wed, 03 Sep 2025 10:24: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 1utken-0001Ah-Uo for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:24:01 +0000 Received: from rein-hpcbdc09 (unknown [1.6.89.6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1a6421f5-88b0-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:23:59 +0200 (CEST) Received: by rein-hpcbdc09 (Postfix, from userid 1000) id 5F18480C094C; Wed, 3 Sep 2025 15:53:58 +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: 1a6421f5-88b0-11f0-9809-7dc792cee155 From: Jahan Murudi To: xen-devel@lists.xenproject.org Cc: Jahan Murudi , Anthony PERARD Subject: [PATCH v4 3/4] xentop: update Makefile to link against libxenctrl Date: Wed, 3 Sep 2025 15:53:22 +0530 Message-Id: <20250903102323.2553142-4-jahan.murudi.zg@renesas.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Update the build system so that xentop links against libxenctrl, which is required for retrieving per-CPU statistics via the hypervisor API. Also update the build rule to include the new pcpu.o object file. Signed-off-by: Jahan Murudi --- tools/xentop/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/xentop/Makefile b/tools/xentop/Makefile index 70cc2211c5..f514a6f7a8 100644 --- a/tools/xentop/Makefile +++ b/tools/xentop/Makefile @@ -15,6 +15,7 @@ include $(XEN_ROOT)/tools/Rules.mk CFLAGS += -DGCC_PRINTF $(CFLAGS_libxenstat) LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(TINFO_LIBS) $(SOCKET_LIBS) -lm +LDLIBS += $(LDLIBS_libxenctrl) CFLAGS += -DHOST_$(XEN_OS) # Include configure output (config.h) @@ -25,8 +26,8 @@ TARGETS := xentop .PHONY: all all: $(TARGETS) -xentop: xentop.o - $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) $(APPEND_LDFLAGS) +xentop: xentop.o pcpu.o + $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS) .PHONY: install install: all -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:24:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:24:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108066.1458227 (Exim 4.92) (envelope-from ) id 1utkes-0002Tf-3f; Wed, 03 Sep 2025 10:24:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108066.1458227; Wed, 03 Sep 2025 10:24:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utker-0002TW-V1; Wed, 03 Sep 2025 10:24:05 +0000 Received: by outflank-mailman (input) for mailman id 1108066; Wed, 03 Sep 2025 10:24: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 1utker-0001Ah-Jm for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:24:05 +0000 Received: from rein-hpcbdc09 (unknown [1.6.89.6]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1ca9427b-88b0-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:24:03 +0200 (CEST) Received: by rein-hpcbdc09 (Postfix, from userid 1000) id 3254980C094F; Wed, 3 Sep 2025 15:54:02 +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: 1ca9427b-88b0-11f0-9809-7dc792cee155 From: Jahan Murudi To: xen-devel@lists.xenproject.org Cc: Jahan Murudi , Anthony PERARD Subject: [PATCH v4 4/4] xentop: integrate pcpu support into main program Date: Wed, 3 Sep 2025 15:53:23 +0530 Message-Id: <20250903102323.2553142-5-jahan.murudi.zg@renesas.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Integrate physical CPU usage statistics into xentop. This patch adds: - a new command-line option (-p, --pcpus) - display of per-CPU usage statistics - cleanup of pcpu resources on exit This allows users to monitor host physical CPU utilization alongside existing domain metrics. Signed-off-by: Jahan Murudi --- tools/xentop/xentop.c | 79 +++++++++++++++++++++++++++++++++---------- 1 file changed, 61 insertions(+), 18 deletions(-) diff --git a/tools/xentop/xentop.c b/tools/xentop/xentop.c index f5d6c19cf9..addb1c70c9 100644 --- a/tools/xentop/xentop.c +++ b/tools/xentop/xentop.c @@ -37,6 +37,7 @@ #endif #include +#include "pcpu.h" #define XENTOP_VERSION "1.0" @@ -205,6 +206,7 @@ field_id sort_field = FIELD_DOMID; unsigned int first_domain_index = 0; unsigned int delay = 3; unsigned int batch = 0; +static unsigned int show_pcpus = 0; unsigned int loop = 1; unsigned int iterations = 0; int show_vcpus = 0; @@ -230,22 +232,23 @@ static WINDOW *cwin; /* Print usage message, using given program name */ static void usage(const char *program) { - printf("Usage: %s [OPTION]\n" - "Displays ongoing information about xen vm resources \n\n" - "-h, --help display this help and exit\n" - "-V, --version output version information and exit\n" - "-d, --delay=SECONDS seconds between updates (default 3)\n" - "-n, --networks output vif network data\n" - "-x, --vbds output vbd block device data\n" - "-r, --repeat-header repeat table header before each domain\n" - "-v, --vcpus output vcpu data\n" - "-b, --batch output in batch mode, no user input accepted\n" - "-i, --iterations number of iterations before exiting\n" - "-f, --full-name output the full domain name (not truncated)\n" - "-z, --dom0-first display dom0 first (ignore sorting)\n" - "\n" XENTOP_BUGSTO, - program); - return; + printf("Usage: %s [OPTION]\n" + "Displays ongoing information about xen vm resources \n\n" + "-h, --help display this help and exit\n" + "-V, --version output version information and exit\n" + "-d, --delay=SECONDS seconds between updates (default 3)\n" + "-n, --networks output vif network data\n" + "-x, --vbds output vbd block device data\n" + "-r, --repeat-header repeat table header before each domain\n" + "-v, --vcpus output vcpu data\n" + "-b, --batch output in batch mode, no user input accepted\n" + "-p, --pcpus show physical CPU stats\n" + "-i, --iterations number of iterations before exiting\n" + "-f, --full-name output the full domain name (not truncated)\n" + "-z, --dom0-first display dom0 first (ignore sorting)\n" + "\n" XENTOP_BUGSTO, + program); + return; } /* Print program version information */ @@ -267,6 +270,8 @@ static void cleanup(void) xenstat_free_node(cur_node); if(xhandle != NULL) xenstat_uninit(xhandle); + + free_pcpu_stats(); } /* Display the given message and gracefully exit */ @@ -313,6 +318,32 @@ static void print(const char *fmt, ...) } } +/* PCPU statistics display function */ +static void print_pcpu_stats_display(void) +{ + int i; + int num_cpus; + + if (!has_pcpu_data()) { + print("\nNo PCPU data available\n"); + return; + } + + num_cpus = get_pcpu_count(); + + /* Use the existing print() function which handles cursor bounds */ + print("\nPhysical CPU Usage:\n"); + print("+-------+--------+\n"); + print("| Core | Usage |\n"); + print("+-------+--------+\n"); + + for (i = 0; i < num_cpus; i++) { + print("| %-5d | %5.1f%% |\n", i, get_pcpu_usage(i)); + } + + print("+-------+--------+\n"); +} + static void xentop_attron(int attr) { if (!batch) @@ -1245,6 +1276,14 @@ static void top(void) do_vbd(domains[i]); } + if (show_pcpus) { + if (update_pcpu_stats(&curtime, delay) == 0) { + print_pcpu_stats_display(); + } else { + fail("Error getting PCPU stats\n"); + } + } + if (!batch) do_bottom_line(); @@ -1271,13 +1310,14 @@ int main(int argc, char **argv) { "repeat-header", no_argument, NULL, 'r' }, { "vcpus", no_argument, NULL, 'v' }, { "delay", required_argument, NULL, 'd' }, - { "batch", no_argument, NULL, 'b' }, + { "batch", no_argument, NULL, 'b' }, + { "pcpus", no_argument, NULL, 'p' }, { "iterations", required_argument, NULL, 'i' }, { "full-name", no_argument, NULL, 'f' }, { "dom0-first", no_argument, NULL, 'z' }, { 0, 0, 0, 0 }, }; - const char *sopts = "hVnxrvd:bi:fz"; + const char *sopts = "hVnxrvd:bpi:fz"; if (atexit(cleanup) != 0) fail("Failed to install cleanup handler.\n"); @@ -1312,6 +1352,9 @@ int main(int argc, char **argv) case 'b': batch = 1; break; + case 'p': + show_pcpus = 1; + break; case 'i': iterations = atoi(optarg); loop = 0; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 10:25:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 10:25:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108098.1458236 (Exim 4.92) (envelope-from ) id 1utkgN-0003i6-Cq; Wed, 03 Sep 2025 10:25:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108098.1458236; Wed, 03 Sep 2025 10:25:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utkgN-0003hz-AB; Wed, 03 Sep 2025 10:25:39 +0000 Received: by outflank-mailman (input) for mailman id 1108098; Wed, 03 Sep 2025 10:25:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utkgM-0003hX-Jj for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 10:25:38 +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 54840e9f-88b0-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 12:25:36 +0200 (CEST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-55f6f7edf45so4063953e87.2 for ; Wed, 03 Sep 2025 03:25: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: 54840e9f-88b0-11f0-9809-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756895135; x=1757499935; 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=4ZdUt7mgVvqTFTx9fuTQu6EjZ2GCzZ1RjGv44Z5ZUFg=; b=iNkm6EOzbTWDN7ZMkDzlIeuFUWTXmWY+JWPB/7eKPWO/oJ8wb8faYS00LDSNgXU6pD V4cYUh7yDqDJW9lD72NMmWHoJ4MaTBD9tg0UimbEQIfJ/FIKZN8ZJaWLVNUAqmQSRF+w QrAGlFJu8OG/U0GkbtlfGyxXcVPnY8EDECi6se1VHV9p4hrPi/oLn9qjXIAExmYduwdK a57I4Ztm61Qd5ZD/xbMJQwEzweGrIIAHIwqFNrJj5H1xag4K5EjHA1AhDXOZgpjDx5ye eYhAz3MV6cQm0Xh50+hLS5FfGfeF0UbveVsoqm0yGH7FmZlJO2+y4mTwFoCo27VV6yWp ZSmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756895135; x=1757499935; 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=4ZdUt7mgVvqTFTx9fuTQu6EjZ2GCzZ1RjGv44Z5ZUFg=; b=jLp5BVyRqQnq7/bs/HHgGDSrgD6RGFyDbZhtXOENpmowJ7psIWxoGowPBeaz5mdy5X 8yplNDJTkw8tcJ3/iE1yQ8KlbJINjAH89nVgH89xUScc1T3fYleTdoR+n48tJp48J1f3 9JAxR0LJwJeZC25NdX/6EybhxhrPXw7s9+ayFd8Mk4FdcE8r/JK68OD1s4jD2LnJ0COq WYofuOlRAch29+Cv+8p+uyfQo4JOEGWJEq//LHLNmNIy9UWG4Rk5Ta+60+nyrhTXJUlF d/lcl0M0oAG3mpC6X0UAr8VZDIDfMWp76eNP0ivGG6okPsR6uujvdyANb2mRser8ILWN 9Liw== X-Gm-Message-State: AOJu0Yxdc9aSVscuLMyKdUEYaV30P+OEjKVHtdK5z3X0//NYWsAzZ4Xf kezdgsSqOL5qYVXkEHEsZVIeF9XkZNfMPjYmfrbZAGwZDRx69Jdl73uhTpQigrNgxo7S3pjVmch OldSEdniYVpt9eMs7FZqpPOnw/SCVhzQ= X-Gm-Gg: ASbGnctaJqGeVgIsTLaLoh2+SbyVg1OABdPhd4BX5txupwCtx486S3s4TIZU2dD24cx 6yqYEUVVt1vhTzE+WKg0adrVtEibDk09koI65QWmBRFe5t544emBJ/nfPut1GIqZfSqNmKjeSQJ gFbYw5XQ0cbScC9xN2naDCRIdjgbs49+mGJbxIMDGh+V3bVWEw0skhdLH36bCL+D9PIfZB8gMhU nQS68S+/BobeTb3 X-Google-Smtp-Source: AGHT+IH6cW6pSrxaZ/6Xw6SrcENlGX34AWn45iYKTsIPoQ9VE3kvhmL28nCZnXc6ZEteqDvSHPNiqU53o01cYWRr6+4= X-Received: by 2002:a05:6512:3b9e:b0:55f:4a95:675 with SMTP id 2adb3069b0e04-55f708f168emr4950011e87.31.1756895133710; Wed, 03 Sep 2025 03:25:33 -0700 (PDT) MIME-Version: 1.0 References: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com> <41cddeee-6cc2-4426-9020-2f1000983845@epam.com> In-Reply-To: <41cddeee-6cc2-4426-9020-2f1000983845@epam.com> From: Mykola Kvach Date: Wed, 3 Sep 2025 13:25:22 +0300 X-Gm-Features: Ac12FXx9G5KlJeCAtsoIfvjd73bBXFRNo58KD309ae0vpKzQLNA7UQdiYCoLppQ Message-ID: Subject: Re: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks To: Oleksandr Tyshchenko Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Mykola Kvach Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Oleksandr, On Wed, Sep 3, 2025 at 1:01=E2=80=AFPM Oleksandr Tyshchenko wrote: > > > > On 02.09.25 01:10, Mykola Kvach wrote: > > Hello Mykola > > > > From: Oleksandr Tyshchenko > > > > Store and restore active context and micro-TLB registers. > > > > Tested on R-Car H3 Starter Kit. > > > > Signed-off-by: Oleksandr Tyshchenko > > Signed-off-by: Mykola Kvach > > --- > > Changes in V6: > > - refactor code related to hw_register struct, from now it's called > > ipmmu_reg_ctx > > The updated version looks good, thanks. However, I have one > concern/request ... > > > --- > > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 ++++++++++++++++++++++= + > > 1 file changed, 257 insertions(+) > > > > diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/pas= sthrough/arm/ipmmu-vmsa.c > > index ea9fa9ddf3..0973559861 100644 > > --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c > > +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > > @@ -71,6 +71,8 @@ > > }) > > #endif > > > > +#define dev_dbg(dev, fmt, ...) \ > > + dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__) > > #define dev_info(dev, fmt, ...) \ > > dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__) > > #define dev_warn(dev, fmt, ...) \ > > @@ -130,6 +132,24 @@ struct ipmmu_features { > > unsigned int imuctr_ttsel_mask; > > }; > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + > > +struct ipmmu_reg_ctx { > > + unsigned int imttlbr0; > > + unsigned int imttubr0; > > + unsigned int imttbcr; > > + unsigned int imctr; > > +}; > > + > > +struct ipmmu_vmsa_backup { > > + struct device *dev; > > + unsigned int *utlbs_val; > > + unsigned int *asids_val; > > + struct list_head list; > > +}; > > + > > +#endif > > + > > /* Root/Cache IPMMU device's information */ > > struct ipmmu_vmsa_device { > > struct device *dev; > > @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device { > > struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX]; > > unsigned int utlb_refcount[IPMMU_UTLB_MAX]; > > const struct ipmmu_features *features; > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX]; > > +#endif > > }; > > > > /* > > @@ -547,6 +570,222 @@ static void ipmmu_domain_free_context(struct ipmm= u_vmsa_device *mmu, > > spin_unlock_irqrestore(&mmu->lock, flags); > > } > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + > > +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock); > > +static LIST_HEAD(ipmmu_devices_backup); > > + > > +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX]; > > + > > +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu, > > + unsigned int utlb) > > +{ > > + return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb))); > > +} > > + > > +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu) > > +{ > > + struct ipmmu_vmsa_backup *backup_data; > > + > > + dev_dbg(mmu->dev, "Handle micro-TLBs backup\n"); > > + > > + spin_lock(&ipmmu_devices_backup_lock); > > + > > + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) > > + { > > + struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(backup_da= ta->dev); > > + unsigned int i; > > + > > + if ( to_ipmmu(backup_data->dev) !=3D mmu ) > > + continue; > > + > > + for ( i =3D 0; i < fwspec->num_ids; i++ ) > > + { > > + unsigned int utlb =3D fwspec->ids[i]; > > + > > + backup_data->asids_val[i] =3D ipmmu_imuasid_read(mmu, utlb= ); > > + backup_data->utlbs_val[i] =3D ipmmu_imuctr_read(mmu, utlb)= ; > > + } > > + } > > + > > + spin_unlock(&ipmmu_devices_backup_lock); > > +} > > + > > +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu) > > +{ > > + struct ipmmu_vmsa_backup *backup_data; > > + > > + dev_dbg(mmu->dev, "Handle micro-TLBs restore\n"); > > + > > + spin_lock(&ipmmu_devices_backup_lock); > > + > > + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) > > + { > > + struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(backup_da= ta->dev); > > + unsigned int i; > > + > > + if ( to_ipmmu(backup_data->dev) !=3D mmu ) > > + continue; > > + > > + for ( i =3D 0; i < fwspec->num_ids; i++ ) > > + { > > + unsigned int utlb =3D fwspec->ids[i]; > > + > > + ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]); > > + ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]); > > + } > > + } > > + > > + spin_unlock(&ipmmu_devices_backup_lock); > > +} > > + > > +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *doma= in) > > +{ > > + struct ipmmu_vmsa_device *mmu =3D domain->mmu->root; > > + struct ipmmu_reg_ctx *regs =3D mmu->reg_backup[domain->context_id]= ; > > + > > + dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->con= text_id); > > + > > + regs->imttlbr0 =3D ipmmu_ctx_read_root(domain, IMTTLBR0); > > + regs->imttubr0 =3D ipmmu_ctx_read_root(domain, IMTTUBR0); > > + regs->imttbcr =3D ipmmu_ctx_read_root(domain, IMTTBCR); > > + regs->imctr =3D ipmmu_ctx_read_root(domain, IMCTR); > > +} > > + > > +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *dom= ain) > > +{ > > + struct ipmmu_vmsa_device *mmu =3D domain->mmu->root; > > + struct ipmmu_reg_ctx *regs =3D mmu->reg_backup[domain->context_id= ]; > > + > > + dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->co= ntext_id); > > + > > + ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0); > > + ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0); > > + ipmmu_ctx_write_root(domain, IMTTBCR, regs->imttbcr); > > + ipmmu_ctx_write_all(domain, IMCTR, regs->imctr | IMCTR_FLUSH); > > +} > > + > > +/* > > + * Xen: Unlike Linux implementation, Xen uses a single driver instance > > + * for handling all IPMMUs. There is no framework for ipmmu_suspend/re= sume > > + * callbacks to be invoked for each IPMMU device. So, we need to itera= te > > + * through all registered IPMMUs performing required actions. > > + * > > + * Also take care of restoring special settings, such as translation > > + * table format, etc. > > + */ > > +static int __must_check ipmmu_suspend(void) > > +{ > > + struct ipmmu_vmsa_device *mmu; > > + > > + if ( !iommu_enabled ) > > + return 0; > > + > > + printk(XENLOG_DEBUG "ipmmu: Suspending ...\n"); > > + > > + spin_lock(&ipmmu_devices_lock); > > + > > + list_for_each_entry( mmu, &ipmmu_devices, list ) > > + { > > + if ( ipmmu_is_root(mmu) ) > > + { > > + unsigned int i; > > + > > + for ( i =3D 0; i < mmu->num_ctx; i++ ) > > + { > > + if ( !mmu->domains[i] ) > > + continue; > > + ipmmu_domain_backup_context(mmu->domains[i]); > > + } > > + } > > + else > > + ipmmu_utlbs_backup(mmu); > > + } > > + > > + spin_unlock(&ipmmu_devices_lock); > > + > > + return 0; > > +} > > + > > +static void ipmmu_resume(void) > > +{ > > + struct ipmmu_vmsa_device *mmu; > > + > > + if ( !iommu_enabled ) > > + return; > > + > > + printk(XENLOG_DEBUG "ipmmu: Resuming ...\n"); > > + > > + spin_lock(&ipmmu_devices_lock); > > + > > + list_for_each_entry( mmu, &ipmmu_devices, list ) > > + { > > + uint32_t reg; > > + > > + /* Do not use security group function */ > > + reg =3D IMSCTLR + mmu->features->control_offset_base; > > + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECG= RP); > > + > > + if ( ipmmu_is_root(mmu) ) > > + { > > + unsigned int i; > > + > > + /* Use stage 2 translation table format */ > > + reg =3D IMSAUXCTLR + mmu->features->control_offset_base; > > + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2= PTE); > > + > > + for ( i =3D 0; i < mmu->num_ctx; i++ ) > > + { > > + if ( !mmu->domains[i] ) > > + continue; > > + ipmmu_domain_restore_context(mmu->domains[i]); > > + } > > + } > > + else > > + ipmmu_utlbs_restore(mmu); > > + } > > + > > + spin_unlock(&ipmmu_devices_lock); > > +} > > + > > +static int ipmmu_alloc_ctx_suspend(struct device *dev) > > +{ > > + struct ipmmu_vmsa_backup *backup_data; > > + unsigned int *utlbs_val, *asids_val; > > + struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(dev); > > + > > + utlbs_val =3D xzalloc_array(unsigned int, fwspec->num_ids); > > + if ( !utlbs_val ) > > + return -ENOMEM; > > + > > + asids_val =3D xzalloc_array(unsigned int, fwspec->num_ids); > > + if ( !asids_val ) > > + { > > + xfree(utlbs_val); > > + return -ENOMEM; > > + } > > + > > + backup_data =3D xzalloc(struct ipmmu_vmsa_backup); > > + if ( !backup_data ) > > + { > > + xfree(utlbs_val); > > + xfree(asids_val); > > + return -ENOMEM; > > + } > > + > > + backup_data->dev =3D dev; > > + backup_data->utlbs_val =3D utlbs_val; > > + backup_data->asids_val =3D asids_val; > > + > > + spin_lock(&ipmmu_devices_backup_lock); > > + list_add(&backup_data->list, &ipmmu_devices_backup); > > + spin_unlock(&ipmmu_devices_backup_lock); > > + > > + return 0; > > +} > > + > > +#endif /* CONFIG_SYSTEM_SUSPEND */ > > + > > static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain= ) > > { > > uint64_t ttbr; > > @@ -559,6 +798,9 @@ static int ipmmu_domain_init_context(struct ipmmu_v= msa_domain *domain) > > return ret; > > > > domain->context_id =3D ret; > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + domain->mmu->root->reg_backup[ret] =3D &root_pgtable[ret]; > > +#endif > > > > /* > > * TTBR0 > > @@ -615,6 +857,9 @@ static void ipmmu_domain_destroy_context(struct ipm= mu_vmsa_domain *domain) > > ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH); > > ipmmu_tlb_sync(domain); > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + domain->mmu->root->reg_backup[domain->context_id] =3D NULL; > > +#endif > > ipmmu_domain_free_context(domain->mmu->root, domain->context_id); > > } > > > > @@ -1427,6 +1672,14 @@ static int ipmmu_add_device(u8 devfn, struct dev= ice *dev) > > } > > #endif > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + if ( ipmmu_alloc_ctx_suspend(dev) ) > > + { > > + dev_err(dev, "Failed to allocate context for suspend\n"); > > + return -ENOMEM; > > + } > > +#endif > > ... The initial version was based on the driver code without PCI > support, but it is now present. There is PCI-specific code above in this > function (not visible in the context) that performs some initialization, > allocation and device assignment. What I mean is that in case of the > suspend context allocation error here, we will need to undo these > actions (i.e. deassign device). I would move this context allocation > (whose probability to fail is much lower than what is done for PCI dev) > above the PCI-specific stuff, and perform the context freeing on the > error path. Maybe it would be better just to add some checks to the suspend handler. We could skip suspend in case the context is not available, and avoid deallocating previously allocated stuff. This is similar to what is done for GICs. What do you think? Or do you prefer to destroy everything related to the IOMMU here on error? > > > + > > dev_info(dev, "Added master device (IPMMU %s micro-TLBs %u)\n", > > dev_name(fwspec->iommu_dev), fwspec->num_ids); > > > > @@ -1492,6 +1745,10 @@ static const struct iommu_ops ipmmu_iommu_ops = =3D > > .unmap_page =3D arm_iommu_unmap_page, > > .dt_xlate =3D ipmmu_dt_xlate, > > .add_device =3D ipmmu_add_device, > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + .suspend =3D ipmmu_suspend, > > + .resume =3D ipmmu_resume, > > +#endif > > }; > > > > static __init int ipmmu_init(struct dt_device_node *node, const void = *data) Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 03 11:26:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 11:26:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108138.1458247 (Exim 4.92) (envelope-from ) id 1utld9-0002Wy-SW; Wed, 03 Sep 2025 11:26:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108138.1458247; Wed, 03 Sep 2025 11:26: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 1utld9-0002Wr-Ou; Wed, 03 Sep 2025 11:26:23 +0000 Received: by outflank-mailman (input) for mailman id 1108138; Wed, 03 Sep 2025 11:26:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utld8-0002Wl-CM for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 11:26:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1utld6-004YaV-2B; Wed, 03 Sep 2025 11:26:20 +0000 Received: from [2a02:8012:3a1:0:4072:878e:9179:858c] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utld6-00EGnZ-2C; Wed, 03 Sep 2025 11:26: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=yDrEc6UQluOeHjxcin4UDo4H+PmCqvtUQiUEvDvplqI=; b=2XMI/iQrIAo+IYL2Ml0mXxBJ7S kkERg3sNH+1VKqtklT/1/Qgkqzi/qfbIYYSOi/ow9umzKdZw+EcVlz3OEs9Y/zJ1WCWoD4X1tm+Vw jQYZnA11XmdmAmp20JArR+FFQNThHpS00Rtyqi5VxFsE5FWhlW1+X5RppQfyE2JA2lMQ=; Message-ID: <6c2cfffa-b36e-4094-be55-88c6a32234ce@xen.org> Date: Wed, 3 Sep 2025 12:26:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Content-Language: en-GB To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" Cc: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> <06ff285f-39d5-4ffd-b842-6d776bb793ac@xen.org> <9d784bea-7ae8-4b0d-aa54-155dccd3f533@epam.com> From: Julien Grall In-Reply-To: <9d784bea-7ae8-4b0d-aa54-155dccd3f533@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Leonid, On 02/09/2025 21:55, Leonid Komarianskyi wrote: >>>>>            if ( rank == NULL ) goto write_ignore; >>>>>            vgic_lock_rank(v, rank, flags); >>>>>            tr = rank->ienable; >>>>>            vreg_reg32_setbits(&rank->ienable, r, info); >>>>> -        vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); >>>>> +        if ( reg >= GICD_ISENABLERnE ) >>>>> +            vgic_enable_irqs(v, (rank->ienable) & (~tr), >>>>> +                             EXT_RANK_IDX2NUM(rank->index)); >>>>> +        else >>>>> +            vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index); >>>> >>>> ... you now have to keep both "if" the same. Unless we can have a >>>> version to avoid "ifs" everywhere (maybe using macros), I would rather >>>> create a separate funciton to handle eSPIs. >>>> >>>> Cheers, >>>> >>> >>> The main idea of V5 of this patch is to consolidate similar code and >>> keep the pairs of regular SPIs and their eSPI counterparts in the same >>> place to simplify any future modifications of these pairs. If >>> eSPI-specific registers are moved to a separate function, it would >>> result in code duplication. Additionally, I think it would be easier to >>> miss updating the code for one register of the SPI/eSPI pair while >>> modifying the code for the other.. >> >> I understand your reasoning, but in this case, we need to try to keep >> the code as common as possible and reduce the number of ifs. Looking at >> the patch again, we seem to often use "EXT_RANK_IDX2NUM(rank->index)" >> and this is why we have the second "if", for instance here. I think it >> would be preferable if "index" store the proper value. >> > > Actually, there are 4 specific cases where I need to use EXT_RANK_IDX2NUM: > vgic_enable_irqs, vgic_disable_irqs, vgic_set_irqs_pending, and > vgic_check_inflight_irqs_pending. The reason I made this transformation > is that these functions are generic and calculate the virq based on the > rank number, e.g. vgic_check_inflight_irqs_pending(): > > unsigned int irq = i + 32 * rank; > > As a result, I decided to introduce EXT_RANK_IDX2NUM with ifs rather > than modifying very generic code that would also affect vGICv2 and be > more difficult to upstream.. I wasn't asking to modify the code in vgic_enable_irqs() & co. But rather how it is called. Right now, rank->index for eSPI, will be starting at 0. But what if instead, it is starting at 128 (i.e. EXT_RANK_MIN)? Effectively, rather than initializating the eSPI ranks with: for ( i = 0; i < DOMAIN_NR_EXT_RANKS(d); i++ ) vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i], i, 0); You could do: for ( i = 0; i < DOMAIN_NR_EXT_RANKS(d); i++ ) vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i], EXT_RANK_IDX2NUM(i), 0); This would remove all the "if"s and the "EXT_RANK_IDX2NUM(rank->index)". Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Sep 03 11:45:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 11:45:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108158.1458256 (Exim 4.92) (envelope-from ) id 1utlvz-0005Kh-9K; Wed, 03 Sep 2025 11:45:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108158.1458256; Wed, 03 Sep 2025 11:45:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utlvz-0005Ka-6o; Wed, 03 Sep 2025 11:45:51 +0000 Received: by outflank-mailman (input) for mailman id 1108158; Wed, 03 Sep 2025 11:45: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 1utlvx-0005KS-2s for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 11:45:49 +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 884260f0-88bb-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 13:45:48 +0200 (CEST) Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13) by AS8PR03MB7752.eurprd03.prod.outlook.com (2603:10a6:20b:407::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Wed, 3 Sep 2025 11:45:44 +0000 Received: from GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025 11: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: 884260f0-88bb-11f0-9d12-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nxGm7j77DhcAzbWIFGpwNs6FMQBLwNqjYQCxXmUALc8P0JL4dbMo7cOqobWSnxNxG7FN+WWfB8DLZZ11EpHGs90NrAO3FjYk3vxJkOYB1VbUT1E5ro1PutYXbnwKYuVIhCFF3MH4RmSAJIV0MHPyfAjJ0elN0wZOsNNJJ47Q0AbI7Qerz7jawsT+4eWIVAQhuKzdyp5c5aBaUO/E1m5nh8DSY65sI0z4+jAmGfKEFXsld1W4MDXvGoHHm61s6Jx/Ukngg73/NMEDT/K7R7XBKlYavgChkjusIAucnttNmHArYd4UnKhCpyFOJ2CK4j53IpBOrfX7mnrYlMFgbiAphw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KOAh6ENdaUu54mP+IplBGvMSUQEl52ifOWUQyedUCxE=; b=f91etOVgmxJGFqZahFvdwaIcDw5OGqKw8wYw4/y8cKvUOIrE1G1vpEX98h4x+K5/uZjSsmgUdAEFfcy0uxbWsC0jvMCEIIC5GMTOYF4SzIhqEuRZ/UTwkH95fkkgvo21WNzyw6vHz3K5DozFRYuZlNaf3GJRoUSPw/0SOkAVFX7ScbkiUf5Y6CThPd41QB8H1ynOjtVlj+wFjZYMWRRgv5ACrTnKhzrMV3CKteu83BTzfykCDzFoP2Y/de87WTYazA/IXSXHW+6mrKXNf5ye5QQTkNYWfPbA7wwkOo72ifPZs/Gm0DJmN9HJ4IAEDL+vhqxxyddloWoe1LhvAg80Uw== 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=KOAh6ENdaUu54mP+IplBGvMSUQEl52ifOWUQyedUCxE=; b=ko0VeR9+oUf6p8+ma+mFhUHFxJpDK+DmzX9oezHrEuSKI7yDTP0vDcY692bqLEAmE7fKY1NpSnDtfx1WBAvgzi4fJ0pX0HWw+ai+Ofr7AMuKYy5XHMDNmWN0BMmflH162eKBbG6NIXRZ7BSQNdX/f1TbePQmSYWaEzXQ85ioi6GV/o09IDYUPDYtvY/ZJQ6vekqyj1BnV0ETddYhtHCKCsxkQp7Ka4l+9sCEIZNyNffta5GGsflc7SiCv315sjAdGnsCJ08+7Wy6EoaGOj39gUvOEm7j9bv0rgy2PS3KYSMOr3YLIEfAyOilbKZVWEDySjyZ29OVLS33s8kH0oPhfA== From: Leonid Komarianskyi To: Julien Grall , "xen-devel@lists.xenproject.org" CC: "olekstysh@gmail.com" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Topic: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Thread-Index: AQHcGP7lSnKp01vKiUyg8GCh+goOA7SAIt4AgAAIk4CAADCcAIAACbGAgADzZICAAAVugA== Date: Wed, 3 Sep 2025 11:45:44 +0000 Message-ID: <6af234f5-6a47-4687-94c7-b9d2b715d234@epam.com> References: <6fda233a1a2f0362062ff9a6e80ee223d33815cf.1756481577.git.leonid_komarianskyi@epam.com> <06ff285f-39d5-4ffd-b842-6d776bb793ac@xen.org> <9d784bea-7ae8-4b0d-aa54-155dccd3f533@epam.com> <6c2cfffa-b36e-4094-be55-88c6a32234ce@xen.org> In-Reply-To: <6c2cfffa-b36e-4094-be55-88c6a32234ce@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: GV2PR03MB8678:EE_|AS8PR03MB7752:EE_ x-ms-office365-filtering-correlation-id: aa575c9f-8df8-41cc-61ac-08ddeadf6ab6 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?bDIvUUtCTlBURk5JOFg3UE5tbHRLVm1pU3R4R1dxNWgzNFZZaU1qTStGOHN0?= =?utf-8?B?RFI5SlluNXJxSUt3aThOcno0VXdYcGtMMGROWTdiSmtuRDRvM0pYOTIyVFUr?= =?utf-8?B?SzBzZnpGc0ViOVNzeldiMkJSRTV0TzRqSjNiWUlEVXNVbGlUZjhuOE9sVlBW?= =?utf-8?B?TEdLdmJ6TmNOb1A4K0hranplTmZBbnRLY0x3ajhhaFZZVFU1WUlKM2lORC9v?= =?utf-8?B?cU9Bcjd4Sk1TQ001WG1Oa04wV25kNlhiUkNHdlMwck4zdWZhU0JtV1FwRW5j?= =?utf-8?B?bXBJeGVjRnMyNnR2bjJOQnA0YnE1ZzEwdmM0VS9rVWp5elhUd0xxc281MnBU?= =?utf-8?B?enBFemtqeG0rWVJCUEFxcHhEbnk4WnlNMDJnTUJCME40Z2JDMDNveGpuMmk0?= =?utf-8?B?SVNFWTVhM0hTS25pUmtyVnhQNnMzd0JWQWYwajNiS1JkMFVxWXNTSG8yZnJG?= =?utf-8?B?NVFoZm1vV1ZXVEV0Zm52czErdCtWL3RFMW5rTGJZMmRDbVBGSFVsQUt2dGNE?= =?utf-8?B?UTJiNy9IQThLRnNTOFdhblY1TGpLcnRHV3QybDllQkdHSEtITWo5SERzZkp6?= =?utf-8?B?d0FpUkdzcXZpOXptQ2p5N0JGY2dqb091R3RCalNydWlNd3IrODRRMGZaRU92?= =?utf-8?B?SGc5T0ozdC9tejJFbEJLL21jakVyZnFCNkZaWThRb1VyNHNaV05sUmppOERu?= =?utf-8?B?UGpTRzNVcmYvdjFvMHVRdkFEaDhOTFlndDNoSjZ3cVY3UlhaUHdYMkZMSnFp?= =?utf-8?B?L29tcXVyWEdCUC90K0EwZDNRNzMwTTI3d3RxT1JPZFdpQmlsaThMbHg1dUdG?= =?utf-8?B?bmRVcWNOZ3JzN3VnYVhNaWN3MFlvVTROMGdvTW9neXlKUDJEekgzclF4TEJw?= =?utf-8?B?VTI2N0VsY0xGa1BNTlBEbTIxR09qdTFQTG94OUZlVU5oVDFvem96QUp0S1NF?= =?utf-8?B?N3A4bFFML3JWUVdLYmdxUUNrcTFSUXR0WDVqcFBySnljaitpWE5ZS21ZRUxM?= =?utf-8?B?Q3hnUlZ5MUhMZTRYUzVkK2s4emU5YnlkMWVKWjQ3YW1NSzJ4UTdDR25mVjJT?= =?utf-8?B?V3FyaWRqVUVudWwvYit6cCs0UjJ4OUl2aHRvTlNsM2U1bkMzSHB6bkd4MFVC?= =?utf-8?B?MUNsdGJUOFRqWHlSVTU0ZVI1RGFEUFZVWEhtRmk4UDc4WCswamxXVTZYRisy?= =?utf-8?B?VTdHL2Y2RVhxVmowemFrcHNOUkcrNFk1Ri8wNkV4RWVRcEtldDJPZ0FpVkpx?= =?utf-8?B?bmpUNUh4T0xJUTZsb0VsNUxwYVoxZjZJNDNJR1FZOVF1bEJUdk5QcUN6T25R?= =?utf-8?B?aW5pbEJNSzVqaHljNXV2cFlOdmJ6eTd5NklJMVRrbGRzUVJwdXA3UHdKajhq?= =?utf-8?B?dGU3VXUyR3l1U3MzWXd0VFJQNUNHNUtDUUJpeSsrdTlhb25zTE9SeXZFMldR?= =?utf-8?B?dFhqVGlPZlhjekpFK09vNmtmenloSW0ySDJrcS9QVWFmL2s1UE1KeUhBZnJI?= =?utf-8?B?aVlhbW16MXpac0l0NHNxalgvVGhncDFSeE9pOGgwblh0RWlTV2hFR1pvVkJR?= =?utf-8?B?YkZ5aGNSb2UyUEJuWW9QYkdoZnZWREpFRSsxYldIN1ZwNWo5YWl6S08xNXFP?= =?utf-8?B?ZUtkQVQzUEVZZGd0WWxROURJZERDUk9WZlF1cEV0aFllQXdNeVhxSW9kVHpZ?= =?utf-8?B?Sy9nRUFEbWFXWFhWVVErcVN6TlVtdDJZV3p6d005K0xQRFJhS0V3NzJIMFlI?= =?utf-8?B?NmNZNWhEYTRHMEFQTjBTbnRITm8rSEpRaFhGbUNaM29HQmhzNzlENHVEaDVp?= =?utf-8?B?VjJMbFA1azFTTHN2REhETHkrZEt1UDNxT0kzNElUaWorc29Qc3lnb1ZqdXdu?= =?utf-8?B?by9ibUMvaXEyeFVJMmhidkF0ZmhSeXNSQUJ0a2FDVmFXeTgvcVJTdE1VS3dN?= =?utf-8?B?N2hRY3B6ZkJSeENVZHh3c3lvTXJXQkZxdTlNd3ByNWUxOVduVTh4MUdYb0I5?= =?utf-8?B?OGlUWjN4czJBPT0=?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eU4rV3BHMEIrNGtwc3dNVGdkdTFjR2lPdlVVTWwwM00vMEhzMlVYZ1F1RVp0?= =?utf-8?B?a1U1S2toRHhPeDRLZGdNTlZORHB6RkJtVldrRkRaT1JmQjYya20vVVljV2hE?= =?utf-8?B?NGdkcGl2LzdGWkxaM0RWQmh1RmxYWm5OVG81NmpkWHhrNjV4REt4dUhNdi9x?= =?utf-8?B?NEhsNkFlRzk0M29SMktjcUFaaUlabERQQlprUnorSm9VNzhiUVViNTFYdHoz?= =?utf-8?B?N0Y1em9HRFVVajJnRDZpaDU5a3JjVDV5cXBKaUdhRDZWQStNc1hJb1VrZkp0?= =?utf-8?B?MEMxMmwxNXlxZUtIdnM5MHBLb3RjUkNNZEMwVWxVdEhGN1BiQkh2YzNodTB6?= =?utf-8?B?M2g3Zko0ZkxEUm1rbmZPQmEwazdPdktwWGV6Sm1ENyt5UkRTVzRkMVFjODl0?= =?utf-8?B?ZVRmWVF5NWhJT2JMMFhYaUVMdnkrMGdKUVA0T29jcVYrUFNId0xlYmRhTGlI?= =?utf-8?B?eFcrcC9UNG0zTE9GZEtHcS8vU3d4aXRuOFBabDNlQXdvTExKWTJmcmsvTkEv?= =?utf-8?B?dEFBOWtoR3diV0ExTWZpbDREd1Rtcm11aFRGa0dCeXlHNWFUKzA3ZCtSMEw3?= =?utf-8?B?STlwcEZWQUQySFhzd01CWkx2aU5MQnkzVm1kUkpHV0s4QmpWaWkzVkVHTHQy?= =?utf-8?B?M0FkbGVCREQ0Z1FlanQ4NjdQdHVYbnQ1TW12ZjZ2MmRGWUVSbjVXQmUzeERX?= =?utf-8?B?VnNIMEVwRnJ4VXVmcXdpN1Vxdnk3bzE4SVk5U2JzbUJiS0o3WHhvcXpUU0hj?= =?utf-8?B?MlExUXBGL0lhNkRvY3E5TExWYlg4ZFpqM2hrZ1B3dHlCc1BHZmlEZGxlbkQ1?= =?utf-8?B?bEJHdEZqQnNKSTQ1ZHhjUmZjMXBubXRxbUxqaFdDenVneTB5VTBwT2haV0Fj?= =?utf-8?B?SmZPd1NqUzlqbkRKOFVRZytZRVk1QlJYSTNNVUVXU0x2RC9OeTB6dVNKdEZH?= =?utf-8?B?TDhWZEtFTG9uVmp4czRPM1JRTkt3a21kY1RzQVBIdWFQcUhNUTNhUlErYUp6?= =?utf-8?B?R2cvSEE5dzdXV2tlcUNKaWlKTFN5Z200QU1rcVIyQmM3dUNUOXJESXRiODFW?= =?utf-8?B?Wk5QMFRYN3NtMk1lNS9kbDlUVFlzVmpkTGdMeUVKa28zZ1M1Y3AvakJ6cWow?= =?utf-8?B?dkdXR3V0V0Q4ZlZObTB2ZE0zSTF4YXZ3eTdaTHhsNEZOSnYvaWdDYThrRWRy?= =?utf-8?B?QWxVOVVhNkM1STZiSjEzZ3RoRWllNW4wZ3dYMS90L29UenpXMGNsR1NtVTlP?= =?utf-8?B?SitoYW5Ia0lCU0ZYRzlSNkozSFFMbnZPOXptN2xESktndGFBam1oejZReGpC?= =?utf-8?B?Q0xJK1F6eTIwNERqODFqd3VtK29HU2FXTTlOMHRrR1NwOW9ianhVaDBza2Jk?= =?utf-8?B?VDRwM1QvUWFzZEVmTHhHUEtEd1puWGthWkJnYTFPdEpsaHVPYkk0TDBiNWtI?= =?utf-8?B?eXZSTDVSUmRRdi8rZ0dzTFBMZWRBUE5vMk9RQ3hUOElOMnF6VHBjVFRVZHVo?= =?utf-8?B?dkY0VGpXU3JhSUxsRWZIRGZ4eUZYdU8zTVdHRnhWNjRac0FpTE9qSmpBUE5E?= =?utf-8?B?QWRhVTVoWXEzQzRoRDFwanVtSFprUkR5eUVlRXU1NWJwT0FQbUpzcUlTMnNF?= =?utf-8?B?eVhhaW9GNVRLSm4wQ3N4QmxBS08wMmsrLzJhQkQ5MjlReVJ5Vm5PRlZQWDY4?= =?utf-8?B?YmUzMVl1dXFabU5GY0NiVnNibkg4V0YxVnl2MFlNT1dtZlhIYlgxTlFuV2Vn?= =?utf-8?B?WE5CcStacVJ5VnlxcElDM09hUE5tTnVhdzRzdFAyWGRxMlNGWmMyTUl2UzBR?= =?utf-8?B?OTNJQTJwNFhXRDJLWkIrYmtPWkdhNGZhZXFaOUp6aVh3dmJYZVM3VnM2YjNs?= =?utf-8?B?eFBxblRtZURLNEQ5eUdqN1FSU0k1clRWWENuVUpiUzZ2VW1zc1lGWTluYS9o?= =?utf-8?B?cDc3VWthZExIOFFhN0JsYWVnNlcrK28vRU5pU2h5WFBLdS9CTnR3Sy9PY3JG?= =?utf-8?B?cTFIcW4rK1U2UG0xZ1Z4VFNJRm0wMDdzUjBtT2lMM2xJZ1lZbWsxbktDUnY0?= =?utf-8?B?TWgvcU1VS2xaZ2JyR0NyMHVFM0VEUGNyRnd5WEJDQzVnNTJwbHp5UEU4emg3?= =?utf-8?B?K1hXNklmQmZ2cFBQL1BnbWJORFhpU0lMelJ3cnlNNVhxTndJV3IzWHJSZkVI?= =?utf-8?Q?pHwWIbcf0MB02SfYbGRLV5E=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <07D42F41FAF0E245AA857F724D31A8B7@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: GV2PR03MB8678.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa575c9f-8df8-41cc-61ac-08ddeadf6ab6 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 11:45:44.5209 (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: 19s8PATiBTnyGp+Aj03ecLaNq9Z1Gl1EyJkWdEVVpQp+gNAAbZ2x86CD/fFD83OjAo5gYY6wUGn5L6Ej63NV940Wtn0ZFdeDSYuFBjftyW4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7752 SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgc3VnZ2VzdGlvbi4NCg0KT24gMDMuMDku MjUgMTQ6MjYsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgTGVvbmlkLA0KPiANCj4gT24gMDIv MDkvMjAyNSAyMTo1NSwgTGVvbmlkIEtvbWFyaWFuc2t5aSB3cm90ZToNCj4+Pj4+PiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIGlmICggcmFuayA9PSBOVUxMICkgZ290byB3cml0ZV9pZ25vcmU7DQo+ Pj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2Z2ljX2xvY2tfcmFuayh2LCByYW5rLCBmbGFn cyk7DQo+Pj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0ciA9IHJhbmstPmllbmFibGU7DQo+ Pj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2cmVnX3JlZzMyX3NldGJpdHMoJnJhbmstPmll bmFibGUsIHIsIGluZm8pOw0KPj4+Pj4+IC3CoMKgwqDCoMKgwqDCoCB2Z2ljX2VuYWJsZV9pcnFz KHYsIChyYW5rLT5pZW5hYmxlKSAmICh+dHIpLCByYW5rLT5pbmRleCk7DQo+Pj4+Pj4gK8KgwqDC oMKgwqDCoMKgIGlmICggcmVnID49IEdJQ0RfSVNFTkFCTEVSbkUgKQ0KPj4+Pj4+ICvCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHZnaWNfZW5hYmxlX2lycXModiwgKHJhbmstPmllbmFibGUpICYgKH50 ciksDQo+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIEVYVF9SQU5LX0lEWDJOVU0ocmFuay0+aW5kZXgpKTsNCj4+Pj4+PiArwqDC oMKgwqDCoMKgwqAgZWxzZQ0KPj4+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfZW5h YmxlX2lycXModiwgKHJhbmstPmllbmFibGUpICYgKH50ciksIHJhbmstIA0KPj4+Pj4+ID5pbmRl eCk7DQo+Pj4+Pg0KPj4+Pj4gLi4uIHlvdSBub3cgaGF2ZSB0byBrZWVwIGJvdGggImlmIiB0aGUg c2FtZS4gVW5sZXNzIHdlIGNhbiBoYXZlIGENCj4+Pj4+IHZlcnNpb24gdG8gYXZvaWQgImlmcyIg ZXZlcnl3aGVyZSAobWF5YmUgdXNpbmcgbWFjcm9zKSwgSSB3b3VsZCByYXRoZXINCj4+Pj4+IGNy ZWF0ZSBhIHNlcGFyYXRlIGZ1bmNpdG9uIHRvIGhhbmRsZSBlU1BJcy4NCj4+Pj4+DQo+Pj4+PiBD aGVlcnMsDQo+Pj4+Pg0KPj4+Pg0KPj4+PiBUaGUgbWFpbiBpZGVhIG9mIFY1IG9mIHRoaXMgcGF0 Y2ggaXMgdG8gY29uc29saWRhdGUgc2ltaWxhciBjb2RlIGFuZA0KPj4+PiBrZWVwIHRoZSBwYWly cyBvZiByZWd1bGFyIFNQSXMgYW5kIHRoZWlyIGVTUEkgY291bnRlcnBhcnRzIGluIHRoZSBzYW1l DQo+Pj4+IHBsYWNlIHRvIHNpbXBsaWZ5IGFueSBmdXR1cmUgbW9kaWZpY2F0aW9ucyBvZiB0aGVz ZSBwYWlycy4gSWYNCj4+Pj4gZVNQSS1zcGVjaWZpYyByZWdpc3RlcnMgYXJlIG1vdmVkIHRvIGEg c2VwYXJhdGUgZnVuY3Rpb24sIGl0IHdvdWxkDQo+Pj4+IHJlc3VsdCBpbiBjb2RlIGR1cGxpY2F0 aW9uLiBBZGRpdGlvbmFsbHksIEkgdGhpbmsgaXQgd291bGQgYmUgZWFzaWVyIHRvDQo+Pj4+IG1p c3MgdXBkYXRpbmcgdGhlIGNvZGUgZm9yIG9uZSByZWdpc3RlciBvZiB0aGUgU1BJL2VTUEkgcGFp ciB3aGlsZQ0KPj4+PiBtb2RpZnlpbmcgdGhlIGNvZGUgZm9yIHRoZSBvdGhlci4uDQo+Pj4NCj4+ PiBJIHVuZGVyc3RhbmQgeW91ciByZWFzb25pbmcsIGJ1dCBpbiB0aGlzIGNhc2UsIHdlIG5lZWQg dG8gdHJ5IHRvIGtlZXANCj4+PiB0aGUgY29kZSBhcyBjb21tb24gYXMgcG9zc2libGUgYW5kIHJl ZHVjZSB0aGUgbnVtYmVyIG9mIGlmcy4gTG9va2luZyBhdA0KPj4+IHRoZSBwYXRjaCBhZ2Fpbiwg d2Ugc2VlbSB0byBvZnRlbiB1c2UgIkVYVF9SQU5LX0lEWDJOVU0ocmFuay0+aW5kZXgpIg0KPj4+ IGFuZCB0aGlzIGlzIHdoeSB3ZSBoYXZlIHRoZSBzZWNvbmQgImlmIiwgZm9yIGluc3RhbmNlIGhl cmUuIEkgdGhpbmsgaXQNCj4+PiB3b3VsZCBiZSBwcmVmZXJhYmxlIGlmICJpbmRleCIgc3RvcmUg dGhlIHByb3BlciB2YWx1ZS4NCj4+Pg0KPj4NCj4+IEFjdHVhbGx5LCB0aGVyZSBhcmUgNCBzcGVj aWZpYyBjYXNlcyB3aGVyZSBJIG5lZWQgdG8gdXNlIA0KPj4gRVhUX1JBTktfSURYMk5VTToNCj4+ IHZnaWNfZW5hYmxlX2lycXMsIHZnaWNfZGlzYWJsZV9pcnFzLCB2Z2ljX3NldF9pcnFzX3BlbmRp bmcsIGFuZA0KPj4gdmdpY19jaGVja19pbmZsaWdodF9pcnFzX3BlbmRpbmcuIFRoZSByZWFzb24g SSBtYWRlIHRoaXMgdHJhbnNmb3JtYXRpb24NCj4+IGlzIHRoYXQgdGhlc2UgZnVuY3Rpb25zIGFy ZSBnZW5lcmljIGFuZCBjYWxjdWxhdGUgdGhlIHZpcnEgYmFzZWQgb24gdGhlDQo+PiByYW5rIG51 bWJlciwgZS5nLiB2Z2ljX2NoZWNrX2luZmxpZ2h0X2lycXNfcGVuZGluZygpOg0KPj4NCj4+IHVu c2lnbmVkIGludCBpcnEgPSBpICsgMzIgKiByYW5rOw0KPj4NCj4+IEFzIGEgcmVzdWx0LCBJIGRl Y2lkZWQgdG8gaW50cm9kdWNlIEVYVF9SQU5LX0lEWDJOVU0gd2l0aCBpZnMgcmF0aGVyDQo+PiB0 aGFuIG1vZGlmeWluZyB2ZXJ5IGdlbmVyaWMgY29kZSB0aGF0IHdvdWxkIGFsc28gYWZmZWN0IHZH SUN2MiBhbmQgYmUNCj4+IG1vcmUgZGlmZmljdWx0IHRvIHVwc3RyZWFtLi4NCj4gDQo+IEkgd2Fz bid0IGFza2luZyB0byBtb2RpZnkgdGhlIGNvZGUgaW4gdmdpY19lbmFibGVfaXJxcygpICYgY28u IEJ1dCANCj4gcmF0aGVyIGhvdyBpdCBpcyBjYWxsZWQuDQo+IA0KPiBSaWdodCBub3csIHJhbmst PmluZGV4IGZvciBlU1BJLCB3aWxsIGJlIHN0YXJ0aW5nIGF0IDAuIEJ1dCB3aGF0IGlmIA0KPiBp bnN0ZWFkLCBpdCBpcyBzdGFydGluZyBhdCAxMjggKGkuZS4gRVhUX1JBTktfTUlOKT8NCj4gDQo+ IEVmZmVjdGl2ZWx5LCByYXRoZXIgdGhhbiBpbml0aWFsaXphdGluZyB0aGUgZVNQSSByYW5rcyB3 aXRoOg0KPiANCj4gIMKgwqDCoCBmb3IgKCBpID0gMDsgaSA8IERPTUFJTl9OUl9FWFRfUkFOS1Mo ZCk7IGkrKyApDQo+ICDCoMKgwqDCoMKgwqDCoCB2Z2ljX3JhbmtfaW5pdCgmZC0+YXJjaC52Z2lj LmV4dF9zaGFyZWRfaXJxc1tpXSwgaSwgMCk7DQo+IA0KPiBZb3UgY291bGQgZG86DQo+IA0KPiAg wqDCoMKgIGZvciAoIGkgPSAwOyBpIDwgRE9NQUlOX05SX0VYVF9SQU5LUyhkKTsgaSsrICkNCj4g IMKgwqDCoMKgwqDCoMKgIHZnaWNfcmFua19pbml0KCZkLT5hcmNoLnZnaWMuZXh0X3NoYXJlZF9p cnFzW2ldLCANCj4gRVhUX1JBTktfSURYMk5VTShpKSwgMCk7DQo+IA0KPiBUaGlzIHdvdWxkIHJl bW92ZSBhbGwgdGhlICJpZiJzIGFuZCB0aGUgIkVYVF9SQU5LX0lEWDJOVU0ocmFuay0+aW5kZXgp Ii4NCj4gDQo+IENoZWVycywNCj4gDQoNClllc3RlcmRheSBldmVuaW5nLCBJIHJlYWxpemVkIHRo ZSBzYW1lIDopIEkgZml4ZWQgdGhpcyB3aGlsZSBwcmVwYXJpbmcgDQp0aGUgbmV4dCB2ZXJzaW9u IG9mIHRoZSBwYXRjaCBzZXJpZXMuIEFsc28sIEkgZm91bmQgYSB3YXkgdG8gcmVtb3ZlIG1hbnkg DQppZnMgaW4gdGhpcyBwYXRjaCBieSBpbnRyb2R1Y2luZyBqdXN0IDIgaGVscGVyIGZ1bmN0aW9u cy4gSSB3aWxsIHB1c2ggdjYgDQpzb29uIHdpdGggdGhlc2UgdXBkYXRlcy4gSSBob3BlIGl0IHdp bGwgbG9vayBtdWNoIGJldHRlci4NCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo= From xen-devel-bounces@lists.xenproject.org Wed Sep 03 11:49:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 11:49:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108169.1458266 (Exim 4.92) (envelope-from ) id 1utlzD-0005uf-Nz; Wed, 03 Sep 2025 11:49:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108169.1458266; Wed, 03 Sep 2025 11: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 1utlzD-0005uY-LL; Wed, 03 Sep 2025 11:49:11 +0000 Received: by outflank-mailman (input) for mailman id 1108169; Wed, 03 Sep 2025 11: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 1utlzC-0005uQ-M9 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 11:49:10 +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 fff22493-88bb-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 13:49:08 +0200 (CEST) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-336dd55aae1so28612061fa.1 for ; Wed, 03 Sep 2025 04:49:08 -0700 (PDT) Received: from [192.168.0.110] ([91.123.151.69]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-337f50b0e98sm9605041fa.60.2025.09.03.04.49.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 04: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: fff22493-88bb-11f0-9809-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756900148; x=1757504948; 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=2HZ9ED8IhQeYW/SYNGTLZ7QR0Fs4zqE1wPhtH5mcgG4=; b=R9wkoXa/Z0HEUC9B2BO4q4rZWs6hhHV1b3wV4rjcVl19h93VtloU5YZVO3fhC7hnkL DSK46BcmZCRh8M9H8wg1ZTKbpGK5mV2HrARp0qha+SiN3sH6fjrIgFB0zNcpZDjE5pMk M0EzohyYbbdJ6YeB3uiPnecGa1uSnXPbOMgAx7ejoGLIV4wV09nRNgq2GViYDMYC4ziP a4Mvz40fXm9Pa1Ss34a1U9hQHMLABCVD4aAEUfwEg1v8X/PV3n/+MeDK7Pl3SDeQtI5H zcSWJloyb6zH8u225tSnRTVtkgd/vvYJRtWd+smEzYdUxN/EQ/HFzQBpUMJTEnBt+SnV LyIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756900148; x=1757504948; 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=2HZ9ED8IhQeYW/SYNGTLZ7QR0Fs4zqE1wPhtH5mcgG4=; b=uwSabvKvPFpJ32uPM3wzq8N40COb0LR6ilfg+e742tTBVSh1R8lJV/clvtg56pC3M8 FZkUxaN3LPJZfJU1h3q97YHAPmSvtb+zTlW6z2PG6d87hEIUrpnO4t2yHlsMILe9lekG ufFOctMgmiFownjztLkCoqEmwuMf/5JMzn97ypD/+fqcz+Syvrgs0RidfQdE08VsF1T1 riaV5izCau9czGK3QBv/IxrnPUkFMDqPR951wl1xBcESANTFvWaixlCxOS81SxVVEngY cZFTaWnpJpuNHj8BXb37xBDaCOg1LMwKs+sFnbbEyrDKrn3gY/ajWM8Cxunmj6V92mkc cf5g== X-Gm-Message-State: AOJu0Yx6fTPaTUoib4IWrKDdEeshUbIYXiLeaX4dvmx7Cvv69kWdRW7P ApJdazHpm59yJUpGtQ8grObmyHtJmri+u5EDI9lw0HRExI+LuZZ1Q5Jl X-Gm-Gg: ASbGncuUnrwLg1Y2UO6sJvSdMFQxPKOf5nLV2OXZfJabKIAW8JJfqb9Z5JR2kaAwAw7 xTuLXrJd8Ir3PIFOAA/rV99cWEKMalD1ewfMyWyOCgQ1c9r/rIMkqfL1CWSpUdQ8FdZ92x6WL2K 2qwKPDQysD9YqD6Z61ZX0pbVIhDWTIGtESNcK6oUJ5ryQMOzx/vNJ6/kEA5C/T89wpamCpMkDcB k6OxC7xy77ypWe28fJLasDLL6uHwy3k7k+8zHk3G2cI6XTkUFNIoKC7oIoQD6d33xoxpqqHjsZk s0Lds6RKiGwYPSSFddvY+PZHJIaG1ebVIJO9Us2BQUo2BCYvEIwnUj66qHvIT1AXFBeKtjuVdbi o7RuTH83/aidDe7NpbWnKdf8P0P8XjJp98Y8a X-Google-Smtp-Source: AGHT+IFGOUgPmwEt33MoFXflt1qtQHoB0ZJLNlE8xS7JJPS0h6fhPHCv2MzL+XbIpOTl0SAiM6VQBA== X-Received: by 2002:a05:651c:514:b0:336:ac3a:73b6 with SMTP id 38308e7fff4ca-336cad33d7bmr43532741fa.28.1756900145809; Wed, 03 Sep 2025 04:49:05 -0700 (PDT) Message-ID: <98444477-bf97-440e-a5a4-844d51e92a54@gmail.com> Date: Wed, 3 Sep 2025 14:49:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks To: Mykola Kvach , Oleksandr Tyshchenko Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Mykola Kvach References: <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com> <41cddeee-6cc2-4426-9020-2f1000983845@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03.09.25 13:25, Mykola Kvach wrote: > Hi Oleksandr, Hello Mykola > > On Wed, Sep 3, 2025 at 1:01 PM Oleksandr Tyshchenko > wrote: >> >> >> >> On 02.09.25 01:10, Mykola Kvach wrote: >> >> Hello Mykola >> >> >>> From: Oleksandr Tyshchenko >>> >>> Store and restore active context and micro-TLB registers. >>> >>> Tested on R-Car H3 Starter Kit. >>> >>> Signed-off-by: Oleksandr Tyshchenko >>> Signed-off-by: Mykola Kvach >>> --- >>> Changes in V6: >>> - refactor code related to hw_register struct, from now it's called >>> ipmmu_reg_ctx >> >> The updated version looks good, thanks. However, I have one >> concern/request ... >> >>> --- >>> xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 +++++++++++++++++++++++ >>> 1 file changed, 257 insertions(+) >>> >>> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c >>> index ea9fa9ddf3..0973559861 100644 >>> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c >>> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c >>> @@ -71,6 +71,8 @@ >>> }) >>> #endif >>> >>> +#define dev_dbg(dev, fmt, ...) \ >>> + dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__) >>> #define dev_info(dev, fmt, ...) \ >>> dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__) >>> #define dev_warn(dev, fmt, ...) \ >>> @@ -130,6 +132,24 @@ struct ipmmu_features { >>> unsigned int imuctr_ttsel_mask; >>> }; >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + >>> +struct ipmmu_reg_ctx { >>> + unsigned int imttlbr0; >>> + unsigned int imttubr0; >>> + unsigned int imttbcr; >>> + unsigned int imctr; >>> +}; >>> + >>> +struct ipmmu_vmsa_backup { >>> + struct device *dev; >>> + unsigned int *utlbs_val; >>> + unsigned int *asids_val; >>> + struct list_head list; >>> +}; >>> + >>> +#endif >>> + >>> /* Root/Cache IPMMU device's information */ >>> struct ipmmu_vmsa_device { >>> struct device *dev; >>> @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device { >>> struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX]; >>> unsigned int utlb_refcount[IPMMU_UTLB_MAX]; >>> const struct ipmmu_features *features; >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX]; >>> +#endif >>> }; >>> >>> /* >>> @@ -547,6 +570,222 @@ static void ipmmu_domain_free_context(struct ipmmu_vmsa_device *mmu, >>> spin_unlock_irqrestore(&mmu->lock, flags); >>> } >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + >>> +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock); >>> +static LIST_HEAD(ipmmu_devices_backup); >>> + >>> +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX]; >>> + >>> +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu, >>> + unsigned int utlb) >>> +{ >>> + return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb))); >>> +} >>> + >>> +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data; >>> + >>> + dev_dbg(mmu->dev, "Handle micro-TLBs backup\n"); >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + >>> + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) >>> + { >>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); >>> + unsigned int i; >>> + >>> + if ( to_ipmmu(backup_data->dev) != mmu ) >>> + continue; >>> + >>> + for ( i = 0; i < fwspec->num_ids; i++ ) >>> + { >>> + unsigned int utlb = fwspec->ids[i]; >>> + >>> + backup_data->asids_val[i] = ipmmu_imuasid_read(mmu, utlb); >>> + backup_data->utlbs_val[i] = ipmmu_imuctr_read(mmu, utlb); >>> + } >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> +} >>> + >>> +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data; >>> + >>> + dev_dbg(mmu->dev, "Handle micro-TLBs restore\n"); >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + >>> + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) >>> + { >>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); >>> + unsigned int i; >>> + >>> + if ( to_ipmmu(backup_data->dev) != mmu ) >>> + continue; >>> + >>> + for ( i = 0; i < fwspec->num_ids; i++ ) >>> + { >>> + unsigned int utlb = fwspec->ids[i]; >>> + >>> + ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]); >>> + ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]); >>> + } >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> +} >>> + >>> +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *domain) >>> +{ >>> + struct ipmmu_vmsa_device *mmu = domain->mmu->root; >>> + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; >>> + >>> + dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->context_id); >>> + >>> + regs->imttlbr0 = ipmmu_ctx_read_root(domain, IMTTLBR0); >>> + regs->imttubr0 = ipmmu_ctx_read_root(domain, IMTTUBR0); >>> + regs->imttbcr = ipmmu_ctx_read_root(domain, IMTTBCR); >>> + regs->imctr = ipmmu_ctx_read_root(domain, IMCTR); >>> +} >>> + >>> +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *domain) >>> +{ >>> + struct ipmmu_vmsa_device *mmu = domain->mmu->root; >>> + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; >>> + >>> + dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->context_id); >>> + >>> + ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0); >>> + ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0); >>> + ipmmu_ctx_write_root(domain, IMTTBCR, regs->imttbcr); >>> + ipmmu_ctx_write_all(domain, IMCTR, regs->imctr | IMCTR_FLUSH); >>> +} >>> + >>> +/* >>> + * Xen: Unlike Linux implementation, Xen uses a single driver instance >>> + * for handling all IPMMUs. There is no framework for ipmmu_suspend/resume >>> + * callbacks to be invoked for each IPMMU device. So, we need to iterate >>> + * through all registered IPMMUs performing required actions. >>> + * >>> + * Also take care of restoring special settings, such as translation >>> + * table format, etc. >>> + */ >>> +static int __must_check ipmmu_suspend(void) >>> +{ >>> + struct ipmmu_vmsa_device *mmu; >>> + >>> + if ( !iommu_enabled ) >>> + return 0; >>> + >>> + printk(XENLOG_DEBUG "ipmmu: Suspending ...\n"); >>> + >>> + spin_lock(&ipmmu_devices_lock); >>> + >>> + list_for_each_entry( mmu, &ipmmu_devices, list ) >>> + { >>> + if ( ipmmu_is_root(mmu) ) >>> + { >>> + unsigned int i; >>> + >>> + for ( i = 0; i < mmu->num_ctx; i++ ) >>> + { >>> + if ( !mmu->domains[i] ) >>> + continue; >>> + ipmmu_domain_backup_context(mmu->domains[i]); >>> + } >>> + } >>> + else >>> + ipmmu_utlbs_backup(mmu); >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_lock); >>> + >>> + return 0; >>> +} >>> + >>> +static void ipmmu_resume(void) >>> +{ >>> + struct ipmmu_vmsa_device *mmu; >>> + >>> + if ( !iommu_enabled ) >>> + return; >>> + >>> + printk(XENLOG_DEBUG "ipmmu: Resuming ...\n"); >>> + >>> + spin_lock(&ipmmu_devices_lock); >>> + >>> + list_for_each_entry( mmu, &ipmmu_devices, list ) >>> + { >>> + uint32_t reg; >>> + >>> + /* Do not use security group function */ >>> + reg = IMSCTLR + mmu->features->control_offset_base; >>> + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP); >>> + >>> + if ( ipmmu_is_root(mmu) ) >>> + { >>> + unsigned int i; >>> + >>> + /* Use stage 2 translation table format */ >>> + reg = IMSAUXCTLR + mmu->features->control_offset_base; >>> + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2PTE); >>> + >>> + for ( i = 0; i < mmu->num_ctx; i++ ) >>> + { >>> + if ( !mmu->domains[i] ) >>> + continue; >>> + ipmmu_domain_restore_context(mmu->domains[i]); >>> + } >>> + } >>> + else >>> + ipmmu_utlbs_restore(mmu); >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_lock); >>> +} >>> + >>> +static int ipmmu_alloc_ctx_suspend(struct device *dev) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data; >>> + unsigned int *utlbs_val, *asids_val; >>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); >>> + >>> + utlbs_val = xzalloc_array(unsigned int, fwspec->num_ids); >>> + if ( !utlbs_val ) >>> + return -ENOMEM; >>> + >>> + asids_val = xzalloc_array(unsigned int, fwspec->num_ids); >>> + if ( !asids_val ) >>> + { >>> + xfree(utlbs_val); >>> + return -ENOMEM; >>> + } >>> + >>> + backup_data = xzalloc(struct ipmmu_vmsa_backup); >>> + if ( !backup_data ) >>> + { >>> + xfree(utlbs_val); >>> + xfree(asids_val); >>> + return -ENOMEM; >>> + } >>> + >>> + backup_data->dev = dev; >>> + backup_data->utlbs_val = utlbs_val; >>> + backup_data->asids_val = asids_val; >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + list_add(&backup_data->list, &ipmmu_devices_backup); >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> + >>> + return 0; >>> +} >>> + >>> +#endif /* CONFIG_SYSTEM_SUSPEND */ >>> + >>> static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) >>> { >>> uint64_t ttbr; >>> @@ -559,6 +798,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) >>> return ret; >>> >>> domain->context_id = ret; >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + domain->mmu->root->reg_backup[ret] = &root_pgtable[ret]; >>> +#endif >>> >>> /* >>> * TTBR0 >>> @@ -615,6 +857,9 @@ static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain) >>> ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH); >>> ipmmu_tlb_sync(domain); >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + domain->mmu->root->reg_backup[domain->context_id] = NULL; >>> +#endif >>> ipmmu_domain_free_context(domain->mmu->root, domain->context_id); >>> } >>> >>> @@ -1427,6 +1672,14 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> } >>> #endif >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + if ( ipmmu_alloc_ctx_suspend(dev) ) >>> + { >>> + dev_err(dev, "Failed to allocate context for suspend\n"); >>> + return -ENOMEM; >>> + } >>> +#endif >> >> ... The initial version was based on the driver code without PCI >> support, but it is now present. There is PCI-specific code above in this >> function (not visible in the context) that performs some initialization, >> allocation and device assignment. What I mean is that in case of the >> suspend context allocation error here, we will need to undo these >> actions (i.e. deassign device). I would move this context allocation >> (whose probability to fail is much lower than what is done for PCI dev) >> above the PCI-specific stuff, and perform the context freeing on the >> error path. > > Maybe it would be better just to add some checks to the suspend handler. > We could skip suspend in case the context is not available, and avoid > deallocating previously allocated stuff. This is similar to what is > done for GICs. > > What do you think? Or do you prefer to destroy everything related to the > IOMMU here on error? I would prefer if we fail early here in ipmmu_add_device (and rollback changes) rather than continue and fail later, other people might think differently. I think, if we cannot simply allocate a memory for the sctructures that situation is bad. > >> >>> + >>> dev_info(dev, "Added master device (IPMMU %s micro-TLBs %u)\n", >>> dev_name(fwspec->iommu_dev), fwspec->num_ids); >>> >>> @@ -1492,6 +1745,10 @@ static const struct iommu_ops ipmmu_iommu_ops = >>> .unmap_page = arm_iommu_unmap_page, >>> .dt_xlate = ipmmu_dt_xlate, >>> .add_device = ipmmu_add_device, >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + .suspend = ipmmu_suspend, >>> + .resume = ipmmu_resume, >>> +#endif >>> }; >>> >>> static __init int ipmmu_init(struct dt_device_node *node, const void *data) > > Best regards, > Mykola > From xen-devel-bounces@lists.xenproject.org Wed Sep 03 13:19:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 13:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108272.1458447 (Exim 4.92) (envelope-from ) id 1utnOD-0001gq-3i; Wed, 03 Sep 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 1108272.1458447; Wed, 03 Sep 2025 13:19:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utnOC-0001fm-Tr; Wed, 03 Sep 2025 13:19:04 +0000 Received: by outflank-mailman (input) for mailman id 1108272; Wed, 03 Sep 2025 13:19:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utnOC-0001dW-1M for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 13:19:04 +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 8f4fcca0-88c8-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 15:19:02 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB7571.eurprd03.prod.outlook.com (2603:10a6:20b:34a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 13:18:58 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9052.014; Wed, 3 Sep 2025 13:18:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8f4fcca0-88c8-11f0-9d12-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YFRfE3M0c8eeyJFIP4UXZstuYG5vhXPlw33ddfiZtOn3MYQfP+dOO9PnKfrdjnnXyvU1mvAhxQLx1rax4dS8iBJFhkg4BO3Z/w7Bz0iZo2nDu91ql9fmclbhIHSxbjsqWNuNJNBo06t/Egd7mTKxCE/8vwLYKM9aFDr6zU2/xYsairYFNZVcJVq0V/BQMu85DbBdDxOMzvMKYkOG5TTNSjAvaPcb9TZ+Mq+ND8KJDhS/5q58S2IGDRsForT0N+aUvEc2LL/HuV0Gsl9IUVbX4ZcawtjYGicHshzywsBoTu4b31K0rYoJW/QtKOWEIYA7SFsGCqW7Lsgh92Go5k6pJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XYyf9uMSyGYMAhDGcubaXfEJRx7TblCIszb89bJrjRk=; b=L9S9WsWTlZ/4cnr2rJz5+pz+AqyNP/VbpGgeeef26ZFxZ8zA7Ors3giL1tRc+bw3i3J4x0MvR0fn5FtGewhUmMpZuAR5p8/8jFhz/avr8HZLSKexGajmZU4hdBpqBlmLTnDigm3rIR+/RUkyPhWTuKPVHWPpiOTxPd0mgYurhvpxAqQBL+gghh7Dr0Ig92L8/y57siSRKsRwRIvXDEPwpcBeggWXZi+XKYe2muLJCCraiqlg+QADO40jBeTCM/sSuj9wsqogxzynJs4RfY86pY08AytbVwGtIVzgPgU13j0dYpL/J73R3/PTQ1bcsib4k5Od78WsJGGgDeqpWQwSwg== 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=XYyf9uMSyGYMAhDGcubaXfEJRx7TblCIszb89bJrjRk=; b=qNdbO7NGLmzYaUaVX/UFGRQSCDdPi/FG/Xr281k3uxp8jJ8ox99tfcdlQk6p35sKNlQCjE8hYpF+oX/JGpOgUEIei/AT6vOEwHkTaKGWLKz0P00ABM2ClDpKGqvS4dXHe7mowEi97c0JtMePRALft646aXyfGMpnS+ed8E56KiYYveXTg2NCYTharLIYfbtwCw74PCTQEqudhy+9OOCgXyGfsxCwj/TOCa4chDNPsjfPP5DN10aoHGewrKwMWP/SLIdEFepwkNc+SJP1gv4iqmaPS2/6EGHueLKDX2e7bF2roiHVdwnYZr9p9Hjhjg9VRbKrlY7noYfyG1WY2iSdQQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 1/4] xen/arm: add generic SCI subsystem Thread-Topic: [PATCH v8 1/4] xen/arm: add generic SCI subsystem Thread-Index: AQHcHNVMIdkBkepdeEKtCYcl72337w== Date: Wed, 3 Sep 2025 13:18:54 +0000 Message-ID: <279579a2dffed091e4b9a208c286371c7ff87a26.1756905487.git.oleksii_moisieiev@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: PAVPR03MB8946:EE_|AS8PR03MB7571:EE_ x-ms-office365-filtering-correlation-id: 0a51d4c7-9e64-4fd3-3bc4-08ddeaec6fbd x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?AutgZLaywJ3MifsTlvM/onoImlzdOCHsvMUGVc1vVUdmt+frkiIWty8VQ9?= =?iso-8859-1?Q?/bR/5mKdMYixY+DZFXHp/49pooBoV6tW8yBJgx1VOFvfYO4UGHlLVjS+Bh?= =?iso-8859-1?Q?CvQi38xXfjta6DDE0m37hoUtj3ERxfxvXCtlVMrFEn1+7pbAAB5wFmBhik?= =?iso-8859-1?Q?m6LhFNTMDday0Io1ln/ywYPOuvfjUPTOk+fh+XguEqadCtC/Iy1O92gyeQ?= =?iso-8859-1?Q?nyEcX2J0c/waSi8sNM3tAzxM1FVUJ9e5HnqqOg1MVa3j2lJpV4gF+IL7Wr?= =?iso-8859-1?Q?9zJhH6rrTmc+QFzVeEb3SomZG6Gx1e4TfcIC6YQ3Y1HE/dG7K+gvIOsFlI?= =?iso-8859-1?Q?iF1vviMgCCtCzq1Oej4Wi/jDVOxynmDoT16ngc+be+qsLF/7rOV95W/3x5?= =?iso-8859-1?Q?R6REGPTFL1tHxrcQYbFNB5XIKf48vQXfEzFTpv113ZMeEcn9p1zo+nr+3v?= =?iso-8859-1?Q?oq4c9T8QQb5lJM3j2xoIrRu7gTNbhg0A6LPKLpI+JeCZiqIE7qcreFvXMN?= =?iso-8859-1?Q?dlc3vKdaOo26cV2oqePLLifstZqLXZ1f17PvDZIObqwkN6AJRWj0U/pUoT?= =?iso-8859-1?Q?wcfYLiR7kE9nN1PCX9wkU/PiOQ+pHT8nUvEZXpHujpMHpBkZXbAA++TuGq?= =?iso-8859-1?Q?6fnFYdDRz0tgUvqKF72dF9sWrFrRgvNuIuP5usKBk1woesKj2gQ516qxjH?= =?iso-8859-1?Q?bE/7EDOhf8tUHQZQxYDT+Vaake4oLwrPxpbinsDqdFcM1vkx4xSjzN4oXx?= =?iso-8859-1?Q?ezrk/KVvk4UcTb23cgP5BePJ7shMuAjoGrdMLaTjUBjL27bTyAYCzTWYmV?= =?iso-8859-1?Q?xPX1gQdrtFC8JcNDvtm0Dw+uSxX/isP5tNNZhfjkNfCHgZVLlirYJODoUg?= =?iso-8859-1?Q?0ADAErdoP7ospa95l0S1/7D/PiRckGOQtNBxbVxp6HNbVLKLV89nQWDG7u?= =?iso-8859-1?Q?kHg9B3kyoW8dKF8JRhqcosV48EAivSOAkldRFmhxgaUGzE8ltBJSZfcXMy?= =?iso-8859-1?Q?eVNro+u0b+242/44qC7oqDK58zVvHoMXT5CU3eZuslqRvfQejW8buwYPAr?= =?iso-8859-1?Q?EbzYcXs9Gh6UyVgPjZNtYfrYxn5XrMZ7bYeuS4/KO89S+gzn5LI6EdvXJ/?= =?iso-8859-1?Q?x91mwQFn8p4WAOlMWrZd0+auz1t/5KnJhScHt0yuOOXr+kufPEwU8ha3pw?= =?iso-8859-1?Q?X8c6NZ9hjJbbJzl1m/TE0px3WfztI+zblYTpogV1BthE+WzRKF2X1qd9HO?= =?iso-8859-1?Q?AqxLNCCbAUZbJkVWMjekk/wGYErWbG4xgXvvkwg3M3FKzg/PbQBuG3+qCo?= =?iso-8859-1?Q?uhc+NFo4rB5ADxsyXtKFfL5NuGKl0hazsPFmlZCbjH0QmH2muZiPM5c054?= =?iso-8859-1?Q?P9aPuurRk0LOpasmYy3LGIV1LJNWPfYVyj5Xs3HJbBXYgx7npk3Kr/xbne?= =?iso-8859-1?Q?vIgpVzFVtoqMeSVQ+Yp3/VBsk2EF0KGSEvA/Zzz/8Vb+QpqGgnsOk4y7Mo?= =?iso-8859-1?Q?+IpFmORse1Mc2GsfwrYnzYiriFyXgNOeXeloN7vVXrCQ=3D=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)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?GhSmkrDXe0Yxisspqj1XieaBmWCdZbfqEGZLdgmav3nxw8Pqs6u8fyLyqf?= =?iso-8859-1?Q?zdldH2x0/qCJLOt1uHu6H4SQD0YrLx1tL6SYuKbwb8IEEEZKANpQbkrVP0?= =?iso-8859-1?Q?HVrFIDwzYfwJTEUOaeNHvgaDY2TcVx6DFk2fWOzcVoREkBXPt1O+rVQLKT?= =?iso-8859-1?Q?iOQ1A7cygc8ljLF8Fp3PnKJAIsLvA9dqoAbDz9lTH2JZz47C3FMkV5d5Xs?= =?iso-8859-1?Q?cBl07jmH4tcumpTSV9uCwCQYS3vY2U/OucJkWCFyVShz7irmSmc7BviBbY?= =?iso-8859-1?Q?NpAGsY2eUyIWDK7g9DYcaXFfN3CZQ1efDh2uRm0lJ2XJhWMP7hcOjVjzUc?= =?iso-8859-1?Q?0yIxiXGfL6AiwyP0jcXnQBAE8IDU99UjNkRaRDwl0VSf2AqRx8ugPBfmSp?= =?iso-8859-1?Q?7EzhHIwvN7/p+U/K3JdWUVK18/TFV5Iwz7GShFXSC4aRdH0wnnrxWTB+HO?= =?iso-8859-1?Q?ljNn+k3bioCBNvD2NBEHbsivbKVaMsNZvySdDakEfqxsRaOAGtVyY8S0sr?= =?iso-8859-1?Q?WZkWLti3wS6qwITCdZivynJsmOaFVRUsG4P02H7ivXFD2/34iA6F4AED75?= =?iso-8859-1?Q?9g4LZwCkZzjFxXouUovnFkzLoEF5fJe9PkzKpsvW0blBlLgMcjtHJYzZZK?= =?iso-8859-1?Q?mJkFHzLHYKqXQWqb30NqS+kl2eT3DA85u0t648QU0Unq8mDtlS1IS3qHFE?= =?iso-8859-1?Q?ZIyho6yWAk4nTuT0Du3y1bdHFBPXJU4Xi9GHmjLWPCfIDtRm6kqZnj+pL8?= =?iso-8859-1?Q?+MJdBkmpBuLHBV+WIfs+EDP9pb/3t0KwqaKaAYbXj5+79FPNpAt3uTIU4K?= =?iso-8859-1?Q?5Z1f4O8slLZ2VMw+1Dm8DG4Dpbu5Nfr47BpxEoJF0h4EsYPT93ZIz1RlUz?= =?iso-8859-1?Q?joL4+LgG56G/O5KGt3QTCHSWiKfZssCzBCfWouQDU6FPfcgpybhAw8a8eo?= =?iso-8859-1?Q?UGuJDSGWrlyVxCC60WW0TeDU1mYtvPXe8bvE/DueB4gBo6oJbmBx0s3SCU?= =?iso-8859-1?Q?ISnY4e5/y4F/fru7R9/JMBMvhI2T+eD8VDaTDbCngHhhI31ZNI5hQaNqsK?= =?iso-8859-1?Q?oA8lqtgE6o6igEhSgYVYJZJzus/E/n070bvjUU14YRX1rTTTCpqRd9DKv5?= =?iso-8859-1?Q?Kod7VlZxggjjS93OnzybWqk0SBLVDfpWNoRwghy3/CXLsjlmRBRpDlleFM?= =?iso-8859-1?Q?GFoO9XUe2J6W9PQBUuPXvAleQPi9KSpuRsUloisP2sHKAW+RQPYHD39n5O?= =?iso-8859-1?Q?r6C0tkD6n35zaAcKN3JWiBcN76KqsBF1BZE9TEz5vHTlrJ3nP2XTgBSHO4?= =?iso-8859-1?Q?jpVsLJnh/fogwKGlonMwdYSu197E77q4mZUmflZxrvHyb0ywDIsQxoM/yl?= =?iso-8859-1?Q?mdG7mF9Zvm6h0oq8/P+iUP45wDl/dEFng1bBeCwnPWAb0Pc+XhfuebqfGD?= =?iso-8859-1?Q?jR18sywQUhyxAxD+zTfSc7lH7WZmBWUCV7CQ8cFHZmNZdh/Z10Kr6lAbeG?= =?iso-8859-1?Q?xCCufonwNgeUBXgLzfYBcrMG0PrTYKkXiYJyXr9qYjfbW8Xsao99dyNAXe?= =?iso-8859-1?Q?mpnkjXLJ5AP5nRI1wbJwZnS4v9YkD20gZ1B4UszpVX5PT0gMQrSXnZUWSN?= =?iso-8859-1?Q?VRpBc6Gz2qWTba6Qr/wxVQmgyul5QkmSf+NziQE1T/29zlcaLIT0z7Vg?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a51d4c7-9e64-4fd3-3bc4-08ddeaec6fbd X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 13:18:54.5998 (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: m8dQaThsDsX4szzR2s/BjEQ7deNG0OMzq2fTJ3OAnG2H0lnweZCn2PFSkjBsUIIoZpyymPhgD48AtbLP/F53bPEuHP1CqrX8EwiggwPScfg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7571 This patch adds the basic framework for ARM SCI mediator. SCI is System Control Interface, which is designed to redirect requests from the Domains to ARM specific Firmware (for example SCMI). This will allow the devices, passed-through to the different Domains, to access to the System resources (such as clocks/resets etc) by sending requests to the firmware. ARM SCI subsystem allows to implement different SCI drivers to handle specific ARM firmware interfaces (like ARM SCMI) and mediate requests -between the Domains and the Firmware. Also it allows SCI drivers to perfor= m proper action during Domain creation/destruction which is vital for handling use cases like Domain reboot. This patch introduces new DEVICE_FIRMWARE device subclass for probing SCI drivers basing on device tree, SCI drivers register itself with DT_DEVICE_START/END macro. On init - the SCI drivers should register its SCI ops with sci_register(). Only one SCI driver can be supported. At run-time, the following SCI API calls are introduced: - sci_domain_sanitise_config() called from arch_sanitise_domain_config() - sci_domain_init() called from arch_domain_create() - sci_relinquish_resources() called from domain_relinquish_resources() - sci_domain_destroy() called from arch_domain_destroy() - sci_handle_call() called from vsmccc_handle_call() - sci_dt_handle_node() - sci_dt_finalize() called from handle_node() (Dom0 DT) Signed-off-by: Oleksii Moisieiev Signed-off-by: Grygorii Strashko Reviewed-by: Stefano Stabellini --- (no changes since v7) Changes in v7: - fix sci_handl_call to make changes more readable - fix build error when DOM0LESS_BUILD is disabled (removed arch_handle_passthrough_prop from the header) - sort headers in alphabetical order in sci.h Changes in v6: - rebase on top of the latest master - fix return value of sci_dt_finalize() call Changes in v5: - update Maintainers file. Set role as a Reviewer - rebased on the latest master branch - Introduce arch_handle_passthrough_prop call to handle arm specific nodes Changes in v4: - fix SPDX-License - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE - move XEN_DOMCTL_assign_device code in separate patch - Add documentation for SCI SCMI drivers MAINTAINERS | 6 + xen/arch/arm/device.c | 5 + xen/arch/arm/dom0less-build.c | 8 + xen/arch/arm/domain.c | 12 +- xen/arch/arm/domain_build.c | 8 + xen/arch/arm/firmware/Kconfig | 8 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/sci.c | 154 ++++++++++++++++++ xen/arch/arm/include/asm/domain.h | 5 + xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++++++++ xen/arch/arm/vsmc.c | 3 +- xen/common/device-tree/dom0less-build.c | 4 + xen/include/asm-generic/device.h | 1 + xen/include/public/arch-arm.h | 4 + xen/include/xen/dom0less-build.h | 3 + 15 files changed, 420 insertions(+), 2 deletions(-) create mode 100644 xen/arch/arm/firmware/sci.c create mode 100644 xen/arch/arm/include/asm/firmware/sci.h diff --git a/MAINTAINERS b/MAINTAINERS index c4886c1159..31dbba54bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -509,6 +509,12 @@ R: George Dunlap S: Supported F: xen/common/sched/ =20 +SCI MEDIATORS +R: Oleksii Moisieiev +S: Supported +F: xen/arch/arm/firmware/sci.c +F: xen/arch/arm/include/asm/firmware/sci.h + SEABIOS UPSTREAM M: Wei Liu S: Supported diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c index 11523750ae..74b54cad34 100644 --- a/xen/arch/arm/device.c +++ b/xen/arch/arm/device.c @@ -13,6 +13,7 @@ #include #include =20 +#include #include =20 int map_irq_to_domain(struct domain *d, unsigned int irq, @@ -303,6 +304,10 @@ int handle_device(struct domain *d, struct dt_device_n= ode *dev, p2m_type_t p2mt, return res; } } + + res =3D sci_assign_dt_device(d, dev); + if ( res ) + return res; } =20 res =3D map_device_irqs_to_domain(d, dev, own_device, irq_ranges); diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index c8d07213e2..0094cf9e40 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -22,6 +22,7 @@ =20 #include #include +#include #include #include =20 @@ -272,6 +273,12 @@ int __init init_vuart(struct domain *d, struct kernel_= info *kinfo, return rc; } =20 +int __init arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node) +{ + return sci_assign_dt_device(kinfo->bd.d, node); +} + int __init arch_parse_dom0less_node(struct dt_device_node *node, struct boot_domain *bd) { @@ -281,6 +288,7 @@ int __init arch_parse_dom0less_node(struct dt_device_no= de *node, =20 d_cfg->arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; =20 if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) { diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 863ae18157..1a8585d02b 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -699,7 +700,7 @@ int arch_sanitise_domain_config(struct xen_domctl_creat= edomain *config) return -EINVAL; } =20 - return 0; + return sci_domain_sanitise_config(config); } =20 int arch_domain_create(struct domain *d, @@ -791,6 +792,9 @@ int arch_domain_create(struct domain *d, d->arch.sve_vl =3D config->arch.sve_vl; #endif =20 + if ( (rc =3D sci_domain_init(d, config)) !=3D 0 ) + goto fail; + return 0; =20 fail: @@ -851,6 +855,7 @@ void arch_domain_destroy(struct domain *d) domain_vgic_free(d); domain_vuart_free(d); free_xenheap_page(d->shared_info); + sci_domain_destroy(d); #ifdef CONFIG_ACPI free_xenheap_pages(d->arch.efi_acpi_table, get_order_from_bytes(d->arch.efi_acpi_len)); @@ -1044,6 +1049,7 @@ enum { PROG_p2m_root, PROG_p2m, PROG_p2m_pool, + PROG_sci, PROG_done, }; =20 @@ -1103,6 +1109,10 @@ int domain_relinquish_resources(struct domain *d) ret =3D relinquish_p2m_mapping(d); if ( ret ) return ret; + PROGRESS(sci): + ret =3D sci_relinquish_resources(d); + if ( ret ) + return ret; =20 PROGRESS(p2m_root): /* diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index a9e4153e3c..039aa71439 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -1640,6 +1641,9 @@ static int __init handle_node(struct domain *d, struc= t kernel_info *kinfo, return 0; } =20 + if ( sci_dt_handle_node(d, node) ) + return 0; + /* * The vGIC does not support routing hardware PPIs to guest. So * we need to skip any node using PPIs. @@ -1740,6 +1744,10 @@ static int __init handle_node(struct domain *d, stru= ct kernel_info *kinfo, if ( res ) return res; =20 + res =3D sci_dt_finalize(d, kinfo->fdt); + if ( res ) + return res; + /* * Create a second memory node to store the ranges covering * reserved-memory regions. diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 817da745fd..fc7918c7fc 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -1,3 +1,11 @@ +config ARM_SCI + bool + depends on ARM + help + This option enables generic Arm SCI (System Control Interface) mediator= s + support. It allows domains to control system resources via one of + Arm SCI mediators drivers implemented in XEN, like SCMI. + menu "Firmware Drivers" =20 config SCMI_SMC diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index a5e4542666..71bdefc24a 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1 +1,2 @@ +obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c new file mode 100644 index 0000000000..e1522e10e2 --- /dev/null +++ b/xen/arch/arm/firmware/sci.c @@ -0,0 +1,154 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Generic part of the SCI (System Control Interface) subsystem. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include +#include +#include +#include +#include + +#include + +static const struct sci_mediator_ops __read_mostly *cur_mediator; + +int sci_register(const struct sci_mediator_ops *ops) +{ + if ( cur_mediator ) + return -EEXIST; + + if ( !ops->domain_init || !ops->domain_destroy || !ops->handle_call ) + return -EINVAL; + + cur_mediator =3D ops; + + return 0; +}; + +bool sci_handle_call(struct cpu_user_regs *args) +{ + if ( unlikely(!cur_mediator) ) + return false; + + return cur_mediator->handle_call(args); +} + +int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf= ig) +{ + if ( !cur_mediator ) + return 0; + + return cur_mediator->domain_init(d, config); +} + +int sci_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->domain_sanitise_config ) + return 0; + + return cur_mediator->domain_sanitise_config(config); +} + +void sci_domain_destroy(struct domain *d) +{ + if ( !cur_mediator ) + return; + + cur_mediator->domain_destroy(d); +} + +int sci_relinquish_resources(struct domain *d) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->relinquish_resources ) + return 0; + + return cur_mediator->relinquish_resources(d); +} + +bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->dom0_dt_handle_node ) + return 0; + + return cur_mediator->dom0_dt_handle_node(d, node); +} + +int sci_dt_finalize(struct domain *d, void *fdt) +{ + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->dom0_dt_finalize ) + return 0; + + return cur_mediator->dom0_dt_finalize(d, fdt); +} + +int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) +{ + struct dt_phandle_args ac_spec; + int index =3D 0; + int ret; + + if ( !cur_mediator ) + return 0; + + if ( !cur_mediator->assign_dt_device ) + return 0; + + while ( !dt_parse_phandle_with_args(dev, "access-controllers", + "#access-controller-cells", index, + &ac_spec) ) + { + printk(XENLOG_DEBUG "sci: assign device %s to %pd\n", + dt_node_full_name(dev), d); + + ret =3D cur_mediator->assign_dt_device(d, &ac_spec); + if ( ret ) + return ret; + + index++; + } + + return 0; +} + +static int __init sci_init(void) +{ + struct dt_device_node *np; + unsigned int num_sci =3D 0; + int rc; + + dt_for_each_device_node(dt_host, np) + { + rc =3D device_init(np, DEVICE_FIRMWARE, NULL); + if ( !rc && num_sci ) + { + printk(XENLOG_ERR + "SCMI: Only one SCI controller is supported. found seco= nd %s\n", + np->name); + return -EOPNOTSUPP; + } + else if ( !rc ) + num_sci++; + else if ( rc !=3D -EBADF && rc !=3D -ENODEV ) + return rc; + } + + return 0; +} + +__initcall(sci_init); diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d= omain.h index a3487ca713..af3e168374 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -120,6 +120,11 @@ struct arch_domain #ifdef CONFIG_TEE void *tee; #endif +#ifdef CONFIG_ARM_SCI + bool sci_enabled; + /* ARM SCI driver's specific data */ + void *sci_data; +#endif =20 } __cacheline_aligned; =20 diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include= /asm/firmware/sci.h new file mode 100644 index 0000000000..66c88cec3c --- /dev/null +++ b/xen/arch/arm/include/asm/firmware/sci.h @@ -0,0 +1,200 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Generic ARM SCI (System Control Interface) subsystem. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef __ASM_ARM_SCI_H +#define __ASM_ARM_SCI_H + +#include +#include +#include +#include +#include + +#ifdef CONFIG_ARM_SCI + +struct sci_mediator_ops { + /* + * Called during domain construction. If it is requested to enable + * SCI support, so SCI driver can create own structures for the new do= main + * and inform firmware about new domain (if required). + * Mandatory. + */ + int (*domain_init)(struct domain *d, + struct xen_domctl_createdomain *config); + + /* + * Called during domain construction. The SCI driver uses + * it to sanitize domain SCI configuration parameters. + * Optional. + */ + int (*domain_sanitise_config)(struct xen_domctl_createdomain *config); + + /* + * Called during domain destruction, releases all resources, that + * were allocated for domain. + * Mandatory. + */ + void (*domain_destroy)(struct domain *d); + + /* + * Called during domain destruction to relinquish resources used + * by SCI driver itself and request resources releasing from firmware. + * Optional. + */ + int (*relinquish_resources)(struct domain *d); + + /* SMC/HVC Handle callback */ + bool (*handle_call)(struct cpu_user_regs *regs); + + /* + * Dom0 DT nodes handling callback so SCI driver can detect DT nodes i= t + * need to handle and decide if those nodes need to be provided to Dom= 0. + * Optional. + */ + bool (*dom0_dt_handle_node)(struct domain *d, struct dt_device_node *n= ode); + + /* + * SCI driver callback called at the end of Dom0 DT generation, so + * it can perform steps to modify DT to enable/disable SCI + * functionality for Dom0. + */ + int (*dom0_dt_finalize)(struct domain *d, void *fdt); + + /* + * SCI driver callback called when DT device is passed through to gues= t, + * so SCI driver can enable device access to the domain if SCI FW prov= ides + * Device specific access control functionality. + * Optional. + */ + int (*assign_dt_device)(struct domain *d, struct dt_phandle_args *ac_s= pec); +}; + + +static inline bool sci_domain_is_enabled(struct domain *d) +{ + return d->arch.sci_enabled; +} + +/* + * Register SCI subsystem ops. + * + * Register SCI drivers operation and so enable SCI functionality. + * Only one SCI driver is supported. + */ +int sci_register(const struct sci_mediator_ops *ops); + +/* + * Initialize SCI functionality for domain if configured. + * + * Initialization routine to enable SCI functionality for the domain. + * The SCI configuration data and decision about enabling SCI functionalit= y + * for the domain is SCI driver specific. + */ +int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf= ig); + +/* + * Sanitise domain configuration parameters. + * + */ +int sci_domain_sanitise_config(struct xen_domctl_createdomain *config); + +/* + * Destroy SCI domain instance. + */ +void sci_domain_destroy(struct domain *d); + +/* + * Free resources assigned to the certain domain. + */ +int sci_relinquish_resources(struct domain *d); + +/* + * SMC/HVC Handle callback. + * + * SCI driver acts as SMC/HVC server for the registered domains and + * does redirection of the domain calls to the SCI firmware, + * such as ARM TF-A or similar. + */ +bool sci_handle_call(struct cpu_user_regs *regs); + +/* + * Dom0 DT nodes handling function. + * + * Allows SCI driver to detect DT nodes it need to handle and decide if + * those nodes need to be provided to Dom0. + */ +bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node); + +/* + * Dom0 DT generation finalize. + * + * Called at the end of Dom0 DT generation, so SCI driver can perform step= s + * to modify DT to enable/disable SCI functionality for Dom0. + */ +int sci_dt_finalize(struct domain *d, void *fdt); + +/* + * Assign DT device to domain. + * + * Called when DT device is passed through to guest, so SCI driver can ena= ble + * device access to the domain if SCI FW provides "Device specific access + * control" functionality. + */ +int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev); +#else + +static inline bool sci_domain_is_enabled(struct domain *d) +{ + return false; +} + +static inline int sci_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + return 0; +} + +static inline int +sci_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + return 0; +} + +static inline void sci_domain_destroy(struct domain *d) +{} + +static inline int sci_relinquish_resources(struct domain *d) +{ + return 0; +} + +static inline bool sci_handle_call(struct cpu_user_regs *args) +{ + return false; +} + +static inline bool sci_dt_handle_node(struct domain *d, + struct dt_device_node *node) +{ + return false; +} + +static inline int sci_dt_finalize(struct domain *d, void *fdt) +{ + return 0; +} + +static inline int sci_assign_dt_device(struct domain *d, + struct dt_device_node *dev) +{ + return 0; +} + +#endif /* CONFIG_ARM_SCI */ + +#endif /* __ASM_ARM_SCI_H */ diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c index 6081f14ed0..4095171533 100644 --- a/xen/arch/arm/vsmc.c +++ b/xen/arch/arm/vsmc.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -232,7 +233,7 @@ static bool handle_sip(struct cpu_user_regs *regs) if ( platform_smc(regs) ) return true; =20 - return scmi_handle_smc(regs); + return (scmi_handle_smc(regs)) ? true : sci_handle_call(regs); } =20 /* diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr= ee/dom0less-build.c index badc227031..aaa5e9b22c 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -228,6 +228,10 @@ static int __init handle_passthrough_prop(struct kerne= l_info *kinfo, if ( res < 0 ) return res; =20 + res =3D arch_handle_passthrough_prop(kinfo, node); + if ( res ) + return res; + /* If xen_force, we allow assignment of devices without IOMMU protecti= on. */ if ( xen_force && !dt_device_is_protected(node) ) return 0; diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/dev= ice.h index 3bd97e33c5..cb13f7faea 100644 --- a/xen/include/asm-generic/device.h +++ b/xen/include/asm-generic/device.h @@ -18,6 +18,7 @@ enum device_class DEVICE_IOMMU, DEVICE_INTERRUPT_CONTROLLER, DEVICE_PCI_HOSTBRIDGE, + DEVICE_FIRMWARE, /* Use for error */ DEVICE_UNKNOWN, }; diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index e2412a1747..e7a17ede3e 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -327,6 +327,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); #define XEN_DOMCTL_CONFIG_TEE_OPTEE 1 #define XEN_DOMCTL_CONFIG_TEE_FFA 2 =20 +#define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 + struct xen_arch_domainconfig { /* IN/OUT */ uint8_t gic_version; @@ -350,6 +352,8 @@ struct xen_arch_domainconfig { * */ uint32_t clock_frequency; + /* IN */ + uint8_t arm_sci_type; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-bu= ild.h index 408859e325..faaf660424 100644 --- a/xen/include/xen/dom0less-build.h +++ b/xen/include/xen/dom0less-build.h @@ -62,6 +62,9 @@ void set_domain_type(struct domain *d, struct kernel_info= *kinfo); int init_intc_phandle(struct kernel_info *kinfo, const char *name, const int node_next, const void *pfdt); =20 +int arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node); + #else /* !CONFIG_DOM0LESS_BOOT */ =20 static inline void create_domUs(void) {} --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 13:19:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 13:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108273.1458451 (Exim 4.92) (envelope-from ) id 1utnOD-0001mL-BD; Wed, 03 Sep 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 1108273.1458451; Wed, 03 Sep 2025 13:19:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utnOD-0001ky-6F; Wed, 03 Sep 2025 13:19:05 +0000 Received: by outflank-mailman (input) for mailman id 1108273; Wed, 03 Sep 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 1utnOC-0001dc-7i for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 13:19:04 +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 8ea87dd5-88c8-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 15:19:01 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::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.9073.27; Wed, 3 Sep 2025 13:18:58 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9052.014; Wed, 3 Sep 2025 13:18: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: 8ea87dd5-88c8-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LqzE9p9l4Yf4BnX4rW+Qr+fzZCR5pOrImJ8vbD5zmkMR5/JZIzXeuweqSO7Qzrx+Fc3GmtvXTHfwS76leUtwhqB0n2mi0t6UFR0dzxVfVbvN+x2jFr9bgo7jor9OnaWzszcSuPwaZQw8x23MuNYmgY8uoOCtAx3J7UawqZcFYiIxxEsB+coa5Atm5FEwlUH9YZZMq7X8v8GYxLIYnORWisY/rvVAK7vueUlc66zhGcKleZSNs56M/r4YzQFqAEuahUVYWcsJmfgnoTb35/mGEHukGs/9hAswF8oqz6rqsN+Wm+JBrcSO+QAkeFE4Cb4ANU+C3/DlZV1m0wZxFJyPzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4RZ6TN9xlD23qNyo1sphiT2FyZ4D2fga5HP3rU8xy+M=; b=SgOSxJb6wzKgQWHYAYmc1FKFU0gIqXyRmCSvftr4u/aGD/jlA2W4y3QW+qP5dfX+bN8xQoyPKM3IswuQnKKl35rQ3/GXtpLT0whxr+RTA+Ul4hWC7OQ9LXWWh2hhdY2FdlvoqfyphsQVi0H6O49JZqFWwFrbjphEPwdCuO86MZdAotANA8kIlZVn0QpT582Y/Rd4bS6JYMRzE+eGAvC6+Q/ZNLDME8bra+uNc5PyiCpKNUxu9l/3pHYOwSOepLPv6IE+AzNgKnBGRnwc4tcZ8OlbGUws5Aj6Ab3DX58uusJLRPot8AJINggt1n9eLG4+W2qGwatJmUXvXnVqw7u3tg== 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=4RZ6TN9xlD23qNyo1sphiT2FyZ4D2fga5HP3rU8xy+M=; b=j52uIPUGypqi2TDJq/GWuN6RA1UH+IeSeNCX90QJganP917CYcvT4AF7TazfYegsgO8L6U5nEgp66sIzeu4G+fvdzOQwqWCMwaCqVaZdp02d93cstcuFo8VSU+qUTi2EavHyXOIffSlABl7vxA4HON/ZaKIOmR8VRTjYjC+NF94IkwBV+V6l4Qa8LqqJ9F0KTnrD2Z25RNXolvXrWIuwwIVE0NPHpYGueJFHN98oEbn9cTkweAiiOrBLJ5OEqM8rYuHHlsVEXf8av0gYAlcX3fFKd2p/T4qmOItcZfwfwMx7aaKnXrNd8ZdRZi2efTe6sKnTd4DoByunE2YSQ9srDw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 2/4] xen/arm: scmi-smc: update to be used under sci subsystem Thread-Topic: [PATCH v8 2/4] xen/arm: scmi-smc: update to be used under sci subsystem Thread-Index: AQHcHNVMsMXwm1Cux0SKgbROukIRhQ== Date: Wed, 3 Sep 2025 13:18:55 +0000 Message-ID: <99c2a98ec8ed09e1a5ea44ef515cb1bbd057410d.1756905487.git.oleksii_moisieiev@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: PAVPR03MB8946:EE_|AS8PR03MB8120:EE_ x-ms-office365-filtering-correlation-id: f79f96b9-916b-4655-4bc2-08ddeaec70ec x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?Emh1xVcXqSdwEJpkWPdwX+jELrLSEPJ2etOwe/G7qzdc/9LaTJZl5kTsIy?= =?iso-8859-1?Q?yEufNW+Lz4ap65mDB6aiTwzGFPfCMUhduD+f7PORVbs6bMvsFxVK0nH/yr?= =?iso-8859-1?Q?ZnPhXOqwy6Ccbew6NJXnBa/kAXSvMJE/TDoNI6va+44BoGaiKsE5XEmLaM?= =?iso-8859-1?Q?xzEuSAo9ebgtO0Sr3phrhFlOG/Uiv4wRsgqDeWODrqO/k0J3zDRq3cacAW?= =?iso-8859-1?Q?l62pHYkwwyBqqcOWHUuniQzQZJNXeO7bFMyE8DCd6V57bsJmouzymCBb3m?= =?iso-8859-1?Q?64b65Q4krryT2bjQbMRfSG4XZzYEBu2rdlR8yYBmqfr3IJVpbOQrV7Hrxk?= =?iso-8859-1?Q?bqh4tpeoiSQzzcQPDSfNj2P2jFUnmdRlp+3VTUuLXAAtwIoDD5mIIJrkpP?= =?iso-8859-1?Q?cIJKhio2yCXhl0w5TZ/6n1YkkwBYKHWvuUNN+QRXq+6hrrBdyXMXNy7nPg?= =?iso-8859-1?Q?CLy5M31A3Kpiv+P9pdDFWE0eMRDBd4zgaZ9HsPaVpHkWy918a7C2I5SX2R?= =?iso-8859-1?Q?M9CSsLrdSXPYFEJJ+ZctgasSeKjuRqlIBa1crPR+n4134sSZssMOod9KRe?= =?iso-8859-1?Q?ol2uStK8Iy0Ay+tyFMfx80HxRpon9bsSraTFiw7NSGlruWwvjuu/iL54c9?= =?iso-8859-1?Q?E1m9DMxuet5B4l3UP9PuI+/j07Xsg5kI0cYZAgyhQxh5PTuu2ovaIai+Hr?= =?iso-8859-1?Q?bbetZpO3hmKnIWQFbOxmLoWt8LMYSvSCbXEaN34Ykxw7gelJKBDqKH0H+m?= =?iso-8859-1?Q?gIuUusbQmygdodyNTq0VQ3pmpErzyQspnynF0wd25rwUmMEs9yergRNw47?= =?iso-8859-1?Q?RAqxOTneQucw+9l/S0img7SWF7//jXSULlf1kxPSxqDoEXz4KodpDzXLDp?= =?iso-8859-1?Q?wWsct7Rkwm6uL5Rf1ztTbLNUY67sFAUCPT4Qwd/SvwbGBgWduMD03+tEEP?= =?iso-8859-1?Q?78oAHLuPg0/ADMYLji/kBg0Wq2gB+gCbXONl0N+Vh26x8oa/UcBFi4nFgZ?= =?iso-8859-1?Q?ghPO8wOfIOdEhzoYpxn6wLkuTuzxHLFqpnj7M1goL2sdADUCpcT0AXcapf?= =?iso-8859-1?Q?Od2AOo4euD9Hj9ql6RWAnN9rzGe1csUePeuYwawyUl+DRKgvjB8xttpaJY?= =?iso-8859-1?Q?5UAiFSnp48+vT/DEYI/wfl1bY1g380SjVvve6nvSeMyuBFRX4JFluaCTdB?= =?iso-8859-1?Q?tphas+ioIT+FjFJUUEff5cMl74/nAw4/FxB0EPJYKEVtOEh8PY0gQ651d3?= =?iso-8859-1?Q?SUAyGoUFRbTv/xmJ5yQHq8puB3TUmfEPAR6xTHCwcEfUTVkSnJzl6ZlxOn?= =?iso-8859-1?Q?Iz49qnQJtT664vz3R85xuX6xHwzedolQdfuU+asldA5XFRdZDLwzn4pHn8?= =?iso-8859-1?Q?P6CJ+SAJlGH2IuwD/pscXdaW2/lXWsJlaOlHTp/REBW4GAwY1PhbSafNgV?= =?iso-8859-1?Q?LFVOsk3CR/OtegNJeA86LjYl57Nu3vCMFAa0dWoGuX4Gsef8t8WLTiHA7F?= =?iso-8859-1?Q?vfuSD67yRretawpNGVruij8HrUuo/i/CeLKmft9KZDgw=3D=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)(7416014)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ZkjXK3B+WzfT5bOCPe0to5gj97c+qOVtIRBSJytpYeF4i+m25k4i0O4JWq?= =?iso-8859-1?Q?OH1ROC0iYZfKWy+hpp7CNQ/RKTOLDazoKBm4yE8DbmEm+zzM7N3V/WA1yV?= =?iso-8859-1?Q?1xDo7r1g8tJvtpGJrWQBbCBx3uu2JQfy9EvHmkIRHrFVQD4tDjLZ6nsNAA?= =?iso-8859-1?Q?uJw1lPxXIE7DfWapjLC6pIRKZRWy0GDxddu1KK7IgjFrul2P3kEAEtCOch?= =?iso-8859-1?Q?tDQ5FlE3tMdutL8diXprF0CZkGsoK2eJtTFf13ym5uOeKycpGzFQKQwAoC?= =?iso-8859-1?Q?fCghFgiio9fRtQRlUpxHl7s6ZExxkbUSM5pK2/0m8Y8XZj0jHLBJOSxSNa?= =?iso-8859-1?Q?y58fw9GgiUDHtqZGqvILiuojbU+MMQyrATT7FeMZeyHE6B1BU8LFsnGS1Z?= =?iso-8859-1?Q?N04IlM7kQbMJetQLDU7N9HnwSyfr85+g8SvfpiOcMV6lTd8/9n8KUyu8Nk?= =?iso-8859-1?Q?KjIznD+b499tQ+JDFRKdD4FRtx+2BjZVNgz01s9CQo2u8HFi/FlLlyRnN2?= =?iso-8859-1?Q?bXcyysC6VjTtsqsGr0TFK7Lw1J6UY2o/NDoCfao4/aL2oNZsAnVo65X8Bj?= =?iso-8859-1?Q?VtmLyH6YhId5ysaJnH1395jyv6CMmZcx7ThLvfpcvo7zwHODZsWnMyMD2y?= =?iso-8859-1?Q?ilbjwes8py1OzzJBUGoSqeEcNuEp1ZgsiGQj6+2ZNG2XcQWoazF0KXhErO?= =?iso-8859-1?Q?cQSyd7nsuQQ3pePYpFeZ3h0pLRcRBrHvCvvljnCUOQvElYMlYRmI5wx1MZ?= =?iso-8859-1?Q?OJ+SjpieUODZj2RwdC/3Ch4s1qFFQ2J3dSUgU7YoCEzAD97Jbww6kZS2Us?= =?iso-8859-1?Q?VfWUN+OHMGZSO2TOrMjfg86/s0VsDMHpVP+ds8psSiP6zI7ekcT7J1LLZA?= =?iso-8859-1?Q?k5S/2znpBXxNe7SS7TyUo2XEBYuJJyPxYgt3f1PktEIryhwuvubU8uDadK?= =?iso-8859-1?Q?pDWMLgLIUUGKKXvoeSz+r0KWcOuIPsoSSPrB52X0irvfYzjkIrC85+Lh7e?= =?iso-8859-1?Q?Hia4pSoI0+r0DIIBN5NwDCnKRRvaqQtZIK4ysRdslWkZyRYeNdAT3T+A5s?= =?iso-8859-1?Q?hKtpB195BZrkyWiPeMvKS4H/oyni7gAbTY5M8TQo5C1NGNlnO03l119X+j?= =?iso-8859-1?Q?4/bcITTWAI1HbBcatTaUl9L/cPFzbTw3w4+6Eo3mVSindpl3c14o16I9+A?= =?iso-8859-1?Q?CreONkRd5ZheR/ltcxo/2eYiZXhMWhGU0J/y1nl1MzbrO+CJMToVulp3Pd?= =?iso-8859-1?Q?0DiO9S5C0c+OiSfnf2ndXadbMzozX7eaRVxV1V5Onnx6m+/OLVarjU7Phz?= =?iso-8859-1?Q?bwtzoLVQm0SajgvNg0RqiZvLIezo38MMKyHRs+M9pRPhX+OkcRlSFlxOS3?= =?iso-8859-1?Q?mujzePMPsXUrMiogN6dEh2wKu3tFuFwHZ1YJqnQqVGOy9oFtdzr/JH3JsB?= =?iso-8859-1?Q?bACMGpOCi58cSpuYVtBaq5tismtWqvpYmLl/pSqRkZRNFg/KJKaLcICZ3a?= =?iso-8859-1?Q?14es9zb/TUxSBl5gZXCsV9FwXvc06D1X5M6WGig8Qxdj06sOWs0uU+sL/T?= =?iso-8859-1?Q?r5UEpt5GqQqVYuSNPQEEgSu/aWVVW56ZLaGZeF+Kx6+VfePA/WxTo00aV5?= =?iso-8859-1?Q?tkIH60KbjZ/lTztvYwku7dDWdco8KvkRJsigpJBcTkX55vjnLjukzvdA?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f79f96b9-916b-4655-4bc2-08ddeaec70ec X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 13:18:55.0858 (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: vy8NGZJI9xOzRU1zHIX0hhBHNwm+1isZt3qvqhcsk56Bhpa7W7q/DNzjjg3/aOkmjf4NlTOfEiGGdqWyiGKYKpZo85jcK98W5qTWWb+9t6E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8120 From: Grygorii Strashko The introduced SCI (System Control Interface) subsystem provides unified interface to integrate in Xen SCI drivers which adds support for ARM firmware (EL3, SCP) based software interfaces (like SCMI) that are used in system management. The SCI subsystem allows to add drivers for different FW interfaces or have different drivers for the same FW interface (for example= , SCMI with different transports). This patch updates SCMI over SMC calls handling layer, introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling layer"), to be SCI driver: - convert to DT device; - convert to SCI Xen interface. There are no functional changes in general, the driver is just adopted to the SCI interface. Signed-off-by: Grygorii Strashko Reviewed-by: Stefano Stabellini Signed-off-by: Oleksii Moisieiev --- (no changes since v7) Changes in v7: - sort headers in scmi-smc.c file Changes in v6: - add R-b tag xen/arch/arm/firmware/Kconfig | 13 ++- xen/arch/arm/firmware/scmi-smc.c | 93 +++++++++++--------- xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 --------- xen/arch/arm/vsmc.c | 3 +- xen/include/public/arch-arm.h | 1 + 5 files changed, 64 insertions(+), 87 deletions(-) delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index fc7918c7fc..bbf88fbb9a 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -8,9 +8,18 @@ config ARM_SCI =20 menu "Firmware Drivers" =20 +choice + prompt "ARM SCI driver type" + default SCMI_SMC + help + Choose which ARM SCI driver to enable. + +config ARM_SCI_NONE + bool "none" + config SCMI_SMC bool "Forward SCMI over SMC calls from hwdom to EL3 firmware" - default y + select ARM_SCI help This option enables basic awareness for SCMI calls using SMC as doorbell mechanism and Shared Memory for transport ("arm,scmi-smc" @@ -18,4 +27,6 @@ config SCMI_SMC firmware node is used to trap and forward corresponding SCMI SMCs to firmware running at EL3, for calls coming from the hardware domain. =20 +endchoice + endmenu diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-= smc.c index 33473c04b1..4c5df714c2 100644 --- a/xen/arch/arm/firmware/scmi-smc.c +++ b/xen/arch/arm/firmware/scmi-smc.c @@ -16,12 +16,12 @@ #include #include =20 +#include +#include #include -#include =20 #define SCMI_SMC_ID_PROP "arm,smc-id" =20 -static bool __ro_after_init scmi_enabled; static uint32_t __ro_after_init scmi_smc_id; =20 /* @@ -41,14 +41,11 @@ static bool scmi_is_valid_smc_id(uint32_t fid) * * Returns true if SMC was handled (regardless of response), false otherwi= se. */ -bool scmi_handle_smc(struct cpu_user_regs *regs) +static bool scmi_handle_smc(struct cpu_user_regs *regs) { uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); struct arm_smccc_res res; =20 - if ( !scmi_enabled ) - return false; - if ( !scmi_is_valid_smc_id(fid) ) return false; =20 @@ -78,49 +75,45 @@ bool scmi_handle_smc(struct cpu_user_regs *regs) return true; } =20 -static int __init scmi_check_smccc_ver(void) +static int scmi_smc_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) { - if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) - { - printk(XENLOG_WARNING - "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); - return -ENOSYS; - } + if ( !is_hardware_domain(d) ) + return 0; =20 + d->arch.sci_enabled =3D true; + printk(XENLOG_DEBUG "SCMI: %pd init\n", d); return 0; } =20 -static int __init scmi_dt_init_smccc(void) +static void scmi_smc_domain_destroy(struct domain *d) { - static const struct dt_device_match scmi_ids[] __initconst =3D - { - /* We only support "arm,scmi-smc" binding for now */ - DT_MATCH_COMPATIBLE("arm,scmi-smc"), - { /* sentinel */ }, - }; - const struct dt_device_node *scmi_node; - int ret; + if ( !is_hardware_domain(d) ) + return; =20 - /* If no SCMI firmware node found, fail silently as it's not mandatory= */ - scmi_node =3D dt_find_matching_node(NULL, scmi_ids); - if ( !scmi_node ) - return -EOPNOTSUPP; + printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d); +} =20 - ret =3D dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id= ); - if ( !ret ) +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) { - printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod= e\n", - SCMI_SMC_ID_PROP, scmi_node->full_name); - return -ENOENT; + printk(XENLOG_WARNING + "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; } =20 - scmi_enabled =3D true; - return 0; } =20 +static const struct sci_mediator_ops scmi_smc_ops =3D { + .handle_call =3D scmi_handle_smc, + .domain_init =3D scmi_smc_domain_init, + .domain_destroy =3D scmi_smc_domain_destroy, +}; + /* Initialize the SCMI layer based on SMCs and Device-tree */ -static int __init scmi_init(void) +static int __init scmi_dom0_init(struct dt_device_node *dev, const void *d= ata) { int ret; =20 @@ -134,22 +127,36 @@ static int __init scmi_init(void) if ( ret ) return ret; =20 - ret =3D scmi_dt_init_smccc(); - if ( ret =3D=3D -EOPNOTSUPP ) - return ret; + ret =3D dt_property_read_u32(dev, SCMI_SMC_ID_PROP, &scmi_smc_id); + if ( !ret ) + { + printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod= e\n", + SCMI_SMC_ID_PROP, dt_node_full_name(dev)); + return -ENOENT; + } + + ret =3D sci_register(&scmi_smc_ops); if ( ret ) - goto err; + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + return ret; + } =20 printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id); =20 return 0; - - err: - printk(XENLOG_ERR "SCMI: Initialization failed (ret =3D %d)\n", ret); - return ret; } =20 -__initcall(scmi_init); +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc, "SCMI SMC DOM0", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_dom0_init, +DT_DEVICE_END =20 /* * Local variables: diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/in= clude/asm/firmware/scmi-smc.h deleted file mode 100644 index 6b1a164a40..0000000000 --- a/xen/arch/arm/include/asm/firmware/scmi-smc.h +++ /dev/null @@ -1,41 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * xen/arch/arm/include/asm/firmware/scmi-smc.h - * - * ARM System Control and Management Interface (SCMI) over SMC - * Generic handling layer - * - * Andrei Cherechesu - * Copyright 2024 NXP - */ - -#ifndef __ASM_SCMI_SMC_H__ -#define __ASM_SCMI_SMC_H__ - -#include - -struct cpu_user_regs; - -#ifdef CONFIG_SCMI_SMC - -bool scmi_handle_smc(struct cpu_user_regs *regs); - -#else - -static inline bool scmi_handle_smc(struct cpu_user_regs *regs) -{ - return false; -} - -#endif /* CONFIG_SCMI_SMC */ - -#endif /* __ASM_SCMI_H__ */ - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c index 4095171533..78d5bdf56f 100644 --- a/xen/arch/arm/vsmc.c +++ b/xen/arch/arm/vsmc.c @@ -21,7 +21,6 @@ #include #include #include -#include =20 /* Number of functions currently supported by Hypervisor Service. */ #define XEN_SMCCC_FUNCTION_COUNT 3 @@ -233,7 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs) if ( platform_smc(regs) ) return true; =20 - return (scmi_handle_smc(regs)) ? true : sci_handle_call(regs); + return sci_handle_call(regs); } =20 /* diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index e7a17ede3e..b31324f8d4 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -328,6 +328,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); #define XEN_DOMCTL_CONFIG_TEE_FFA 2 =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 =20 struct xen_arch_domainconfig { /* IN/OUT */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 13:19:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 13:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108271.1458440 (Exim 4.92) (envelope-from ) id 1utnOC-0001du-Pp; Wed, 03 Sep 2025 13:19:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108271.1458440; Wed, 03 Sep 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 1utnOC-0001dn-NB; Wed, 03 Sep 2025 13:19:04 +0000 Received: by outflank-mailman (input) for mailman id 1108271; Wed, 03 Sep 2025 13:19: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 1utnOA-0001dW-Hq for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 13:19:02 +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 8e0d90a4-88c8-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 15:19:01 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB7571.eurprd03.prod.outlook.com (2603:10a6:20b:34a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep 2025 13:18:54 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9052.014; Wed, 3 Sep 2025 13:18: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: 8e0d90a4-88c8-11f0-9d12-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Hf/3nRkSHubX7dVzznCaV1UWhxxRrmUQ/7YKNHafZGtjMVO0mb+D2ltjnYlcJcN4rOhRr8rLEsKykwSwKOD3jD9ItLkpTzA9su6mRkY65O0S5wZTzejkzBIiZIqos3I11nbWev+aHUvw7H6eFjdaIxMCSULXWrqlxie6YNUOBXJ2qW8VHN8uvGYezt4+T6lnTlgrNG0b6EX05uh1wXYejcaO+MMooYfgL7V0a6X6w43MH1tl/fCI/RSj4+hZrr7Nm+4wn3hqlohdKehw37cKOGEQZXeLl0xeYNzhp+Ihlc/NrHMETt5d/OKDNhiTvKcsT9Xj1zkrhsyDkwvX6CgBUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ANcx1s4SQzXjrDQlB+kjY7oqnp1S/ElTbvfce69YMxA=; b=B8u8M4N+H2ODiN5MI3nEkk5Kc1NO671OXRurJH+CuaD2uU71C4Ma4XxTyIMag6O+syQ3uvS3ohQTFkUlF8jpA0KBMi9QA2vSWhracgcYiAUz/jpvkwoMfAIcd9860PaHWr0t6SWIroYihC7SjFp6ZFbwGyjvbx67dmORiusDLwgcemqEZHpOLUl3cWW8dhyXeH8M1cjpAmSoabY55+qssZkFGwj6tkWv0wwPF2IQ7whcbKlF7WgSVZhbw4rlR1N4D+cHsMqYkrfCiBIwJcDVS4786rrMW0KZftwvq0v87rorEqe6y71AIWR0uGB3Q3lx7A23iLPF+QaRTvUPJYBTGw== 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=ANcx1s4SQzXjrDQlB+kjY7oqnp1S/ElTbvfce69YMxA=; b=T5vrmCSbfMqD0nXu1SKvsCbTFDQwsPBFTU2aDKs86LMjCYM0/Sz4Z6Om7ui2nzpEZSY1uLw9WLRIUcjCCnYttCEdu2FwCU5DoN6+cR0rLfupPZJeOHfm0Q4PaGGIz/TxLR1ncIZaTRE/rHC4aDRnGy20KsEWuW7gwPYDP7MWiIIx9yNF8/Np5hTcejLaANE0DP+HcCyt7z5osuYiMSYs/EE08QkpBCt4ep7Klor4N6mEt4zy9dUaDFafTOihGeKzxGVOX2Ys1MwcQ3MVlsnbAQRNKAxqDid5aLb/M6ldTuiW9I8aYo2Wa6xQ+0cChmYob5HNZ/mM3rZwtJii9MQOag== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support Thread-Topic: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support Thread-Index: AQHcHNVLdhHlv1cXk0a1m6gBYsABvg== Date: Wed, 3 Sep 2025 13:18:53 +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: PAVPR03MB8946:EE_|AS8PR03MB7571:EE_ x-ms-office365-filtering-correlation-id: 69efd87f-3a3b-4a5c-2ee4-08ddeaec6e4f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?+l+RM+Q+UMmhZMPPh73DMnL8zEhr+aKPXNeFiImYXzQ36YAgpSTEfe4tce?= =?iso-8859-1?Q?pdOiWJeFoby4T9+1/YikclI1A1Z5jl2uvBGKKNEg1pJHqQkaSZwat1X01Z?= =?iso-8859-1?Q?qZiekFqWJh2+b0HWExLAaBrooo8mkU3Pf2mT8s4O73kS4PyM7e3aY1Vj8O?= =?iso-8859-1?Q?H+OwLXvpZbSIhq2brk3cukDbSbwsmr8ZEIowxLnLikvi17nhji3TJODsG+?= =?iso-8859-1?Q?It63+30jv/QYO5iaCWfxOw6XB/HsvfVZv1JD+qNbIfbv13fO0CIMsSYibE?= =?iso-8859-1?Q?7TDyKp21jvSYF8u/cQU4GmfHiIDAng7S3CvI1W/rtvKMuJpvEkWwNx3bz0?= =?iso-8859-1?Q?QsJ6LCO/lsHyVUfvvjGAFQgdZbMsztwFFGGI5VikrXuBzlXPMZph8zjFjk?= =?iso-8859-1?Q?yZ0RPqCFx19WcxPWf4mjViBXYR9uJ6fsihiq1jcd9kPyUCvqid96xrUNHF?= =?iso-8859-1?Q?TnKQuiQD9uejPARHWXK6SUceH0ntN/mudhe4oaB+wbhDVAqaxFyTKxGVqp?= =?iso-8859-1?Q?9dpCKLCf/F/rQ3ldngbVfbJfQ19iRBLmQMLgU9VaQsUtDP39YsyvQYTcZk?= =?iso-8859-1?Q?bqmEUwG6a09OW8MwSxlQrXOh9APpcghi3KnSZ7XzsHzCQtWL3CC8iqpg0d?= =?iso-8859-1?Q?OstofxhAve8Xzw2pFm1QhSTOBm2RS48KznAH3DHTQDq3+IE49zw8s25iyZ?= =?iso-8859-1?Q?VKPwp39soKgoHhFxqgu8gP/I6SElgTAjqKtyNzfYNh97zJfe4GrrR0iH4U?= =?iso-8859-1?Q?PHf4p94A9f4vu33BzQ+x8XfS3QvUypVEz50q+zkQ3kqmS9Pgf8EH6BSmNY?= =?iso-8859-1?Q?sGK2vuvjbkIqx2DAbC5kx4YQvh3A80TZEbagKCvyJ9f4L3VlReSNLJ5rV+?= =?iso-8859-1?Q?eDTBC+PoQYdUw8NnBG55IWOm36FBHfeoo6AEgP7aXwG00vnDfH0RzWvCkJ?= =?iso-8859-1?Q?Kzi2RG8ImFmEeq/gqdBmfU1G8ExminFeKkPHbcakyMZKxwgPRk10YDeX16?= =?iso-8859-1?Q?1MXaH8otEWnvR6yN5W4igBsHnmjYFvNS8Z3c4dHE0u2DAUSeKYw4XYTPLe?= =?iso-8859-1?Q?o6MVlES4Tcyckc9z/08Q5dlrAjLYqq6N6lKklx2PlO0DQlzRErqSFeTLOj?= =?iso-8859-1?Q?IJtWJqcgIBcdWdCOKoDMGW6+zM2G76F8bj+X/UHiKCtHdlKkv7N9DT4OMH?= =?iso-8859-1?Q?mV+l6bcb6jsYJvFTjJPkPV5FDM+JEdzmkyxXq46dMfkvHgKMujtsfeDytA?= =?iso-8859-1?Q?SEOxwexx5QnWQFfkkpPCjqXZhhsuJaM24bHnjhBcDuWO2KllEM6BKIzm3S?= =?iso-8859-1?Q?lpRTmnSw61M/YZ5Gm6LNUlLtLstLJ1NwiXUFzYBenKTjbSG0aM5p6SIvRS?= =?iso-8859-1?Q?dby3P7bkNCUGO0bkgs/mw88WWeF39F56Sv05t9JWxVi5QLFlD/vXiP7+89?= =?iso-8859-1?Q?1kmN1NEQHbobqv0fGsgtSfLnZiOAq0zakhkOqR1K68tJuqPVvlGxLz0SRh?= =?iso-8859-1?Q?k=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)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gv/KE9VV8bEYJAaD5/ZLzSLwj7j6FAQ6w4gzvKFcegSp/9RsapnBi7thFf?= =?iso-8859-1?Q?d+XFvRrKjyn/QA8uNwobK5Eg357E5udFQDL8/fypVy8X565Y+Kt9ozsSkV?= =?iso-8859-1?Q?eLEqEiXLOwN0PXySBkMIavnoFMh/ASWlc8B1zeqqUSRl/gzCM3XXyvtqvl?= =?iso-8859-1?Q?jmVERXN5c2QF7iRhZkpwo4UfUxBhxyFk0l4pvuv1u2TkIHUzV6p8ZEqOxB?= =?iso-8859-1?Q?1yieER8vUmOIci9dAI73tYb1lZ5blQuCsDSEyo2GH+gtT2e7PHvZO+Zfd4?= =?iso-8859-1?Q?We79KKK35D00Tz0pM2yF48zM0Da/gGvUyZ5x42RH2BOzxQiIw3TvLSR3w/?= =?iso-8859-1?Q?rbMy5diqJIdjgfwjYdQKACi7cas8dVjLN+6t400Q7/NmXXhfATm1e2CHVi?= =?iso-8859-1?Q?HWGectbEURKwBw1sf4xMM+ZyxCiRMyfM55tvYiNSgccYugVjiFkuFxybb+?= =?iso-8859-1?Q?lMV605YwqsAdQNEvmdreEqVZLlXsna9elPxff2lyGEaqOauu8D921dnnoo?= =?iso-8859-1?Q?w/u8+iIGanPi3oMA/IKhgBaR855XzbJ7/VBguPXyEkoed9lUxOX26dbXYS?= =?iso-8859-1?Q?txZyNZ+K2iz72vAawP2X4Wl5yPI+aDfxptG//BLm39MTvZ07E0ZfdWDKhK?= =?iso-8859-1?Q?qLfQyW/VR1b87/LVOlUmp0feCALEyR4/jv2+VkL//bkziHWOKAuBPTwEOe?= =?iso-8859-1?Q?hVWLUGySdVOxCCkz+6uoFv1uJ7bT+Z+tSPUT/Q/WZfVHClUIBxCsXQtLF5?= =?iso-8859-1?Q?mMCv/Pwjq2h6WDAM4Fps4z/Uq21wtgL9oJxAVIqEcZC7yhCB1oz7c6fvWS?= =?iso-8859-1?Q?F7z5ducEiYeSWsD/YfCHbO2HjH2LvvVPSEfUV8KYQjf08SIhkrTgSwpeGR?= =?iso-8859-1?Q?JveB/6UD5Ac+GO9GdTtV00C1saGr+CsAhZF2U9BDsEbiJITME/aV4/py5R?= =?iso-8859-1?Q?fsH1343SapSiGUlBV6YmN+Ip9w3EVPeoio00wn7cnIK2TtNrQSHxr54IS/?= =?iso-8859-1?Q?o70OO3CgMm565Yd4o0UDOqz4zqd4RpmTdeUTOO6OS9dWMjOg6Nj84MUX8p?= =?iso-8859-1?Q?5e/5DOA9mMq9/zXRMX7LB78+xWKVnJpuMmD2ZYZmnND/dI0THLoINXIKLv?= =?iso-8859-1?Q?UaIU9oJgxG7bsC5K/KYNkPhF//XGUws9f732cGZUhDdzOgbxiJL2M4o/k9?= =?iso-8859-1?Q?w2KhH/EzqT7YHWHXnflGYWC2jQeT16kkHRRGL8qcpUiNqZni8+OmsfrfcB?= =?iso-8859-1?Q?bhI7rDVt0lBFozdtStsfvBPzsvTBBbx2oCyV0BnPOJgNknyHVglY422mh6?= =?iso-8859-1?Q?78ugYFMLtCchJmmgwpYfYfWTXDRyj6Qgmw9atv4U+WUQf+qkzabUGpkQET?= =?iso-8859-1?Q?aKdJqkK0syNFSpZGVk95azjN1OtYSTObrw70FdV+JR459DvtEgXznzBCm9?= =?iso-8859-1?Q?5U0SJRqgz5YpF/hjo119REeQKHzXfx1xLA2cz6dWbFzJFj6NWyMI6gS1no?= =?iso-8859-1?Q?XjvI8B7gKsbxhuiKQZh3BIDegyKqWoWTepe48lytOCF4oP/5EXZgBdLpoD?= =?iso-8859-1?Q?eKHCkmPJaKcIjJIYBpc6QGJhvK8uPyNH4RIKGqymkdl/UBf7FnX/mgq0q5?= =?iso-8859-1?Q?w7Ifhsfjl2Rd8OupSrHmi1rhL39NFkYQjw6fhJ6NqJuVhS2iwgM7SFEA?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69efd87f-3a3b-4a5c-2ee4-08ddeaec6e4f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 13:18:53.9974 (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: 7HVjFzy3u8okJAlBVHLzLaPsDVnHpr9K63t58U66J9v5sSAwoh6d/yerV74XXW+JSgFeNWpiqZaH923OYgEjIpJ/YyIaFXXx78QEiztXCkQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7571 Inroducing V8 patch series on top of the Xen version 4.20-rc2 which includes implementation of the SCI SCMI SMC single-agent support. This patch series is the first chunk of the "xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can be found at [0] SCMI-multiagent support will be provided as the followup patch series. [0] https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieie= v@epam.com/ Patch 1 "xen/arm: add generic SCI subsystem" - rebased and refactored - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probin= g instead of custom, linker sections based implementation. - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch dom0 code directly. - RFC changes in XEN_DOMCTL_assign_device OP processing - Introduce arch_handle_passthrough_prop call to handle arm specific nodes Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem" - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add = SCMI over SMC calls handling layer") be used under sci subsystem. - no functional changes in general Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain This is new change which allows passthrough SCMI SMC, single agent interfac= e to guest domain cover use case "thin Dom0 with guest domain, which serves as Driver domain"= . See patch commit message for full description. Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding driver - add documentation section for Simple Arm SCMI over SMC calls forwarding driver. Code can be found at: https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5 [1] RFC v2: http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.ol= eksii_moisieiev@epam.com/ [2] RFC v3: https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927= -1-grygorii_strashko@epam.com SCMI spec: https://developer.arm.com/documentation/den0056/e/?lang=3Den SCMI bindings: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /Documentation/devicetree/bindings/firmware/arm,scmi.yaml https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /Documentation/devicetree/bindings/access-controllers/access-controllers.ya= ml Reference EL3 FW: RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/ Renesas v4h: https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4= x-scmi_upd/ base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21) Changes in v8: - reneregated {helpers/types}.gen.go, dropped unneeded parameters Changes in v7: - fix sci_handl_call to make changes more readable - fix build error when DOM0LESS_BUILD is disabled (removed arch_handle_passthrough_prop from the header) - sort headers in alphabetical order in sci.h - sort headers in scmi-smc.c file - Fix commit description. - Move scmi-smc-passthrough definition to match alphaberical order - remove unneeded initialization with NULL - changed u64 to uint64_t - Send warning if iomem permit access was failed - fixed typos Changes in v6: - rebase on top of the latest master - fix return value of sci_dt_finalize() call - add R-b tag - added generated helpers and types go files - rename cmdline parameter to scmi-smc-passthrough - fix goto tag in parse_arm_sci_config - add link to the scmi bindings used in the doc - remove mentions about HVC calls from doc - rename cmdline parameter to scmi-smc-passthrough Changes in v5: - update Maintainers file. Set role as a Reviewer - rebased on the latest master branch - Introduce arch_handle_passthrough_prop call to handle arm specific nodes - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough - rename dom0_scmi_smc_passthrough in documentation Changes in v4: - fix SPDX-License - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE - move XEN_DOMCTL_assign_device code in separate patch - Add documentation for SCI SCMI drivers - xl.cfg doc - fix comments from Stefano Stabellini - fix toolstack code as sugested by Anthony PERARD - use MATCH_OPTION() - move arm_sci struct and cfg params in "arch_arm" - add SCMI passthrough for dom0less case Grygorii Strashko (3): xen/arm: scmi-smc: update to be used under sci subsystem xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent docs: arm: add docs for SCMI over SMC calls forwarding driver Oleksii Moisieiev (1): xen/arm: add generic SCI subsystem MAINTAINERS | 6 + .../arm/firmware/arm-scmi.rst | 180 ++++++++++++++++ docs/hypervisor-guide/arm/index.rst | 9 + docs/hypervisor-guide/index.rst | 1 + docs/man/xl.cfg.5.pod.in | 34 +++ docs/misc/arm/device-tree/booting.txt | 15 ++ docs/misc/xen-command-line.pandoc | 9 + tools/golang/xenlight/helpers.gen.go | 35 +++ tools/golang/xenlight/types.gen.go | 11 + tools/include/libxl.h | 5 + tools/libs/light/libxl_arm.c | 14 ++ tools/libs/light/libxl_types.idl | 10 + tools/xl/xl_parse.c | 36 ++++ xen/arch/arm/device.c | 5 + xen/arch/arm/dom0less-build.c | 40 ++++ xen/arch/arm/domain.c | 12 +- xen/arch/arm/domain_build.c | 8 + xen/arch/arm/firmware/Kconfig | 25 ++- xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/sci.c | 154 ++++++++++++++ xen/arch/arm/firmware/scmi-smc.c | 194 +++++++++++++---- xen/arch/arm/include/asm/domain.h | 5 + xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++ xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 ---- xen/arch/arm/vsmc.c | 4 +- xen/common/device-tree/dom0less-build.c | 4 + xen/include/asm-generic/device.h | 1 + xen/include/public/arch-arm.h | 5 + xen/include/xen/dom0less-build.h | 3 + 29 files changed, 982 insertions(+), 85 deletions(-) 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/include/asm/firmware/sci.h delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 13:19:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 13:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108275.1458480 (Exim 4.92) (envelope-from ) id 1utnOI-0002Zn-2t; Wed, 03 Sep 2025 13:19:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108275.1458480; Wed, 03 Sep 2025 13:19:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utnOH-0002Zf-W5; Wed, 03 Sep 2025 13:19:09 +0000 Received: by outflank-mailman (input) for mailman id 1108275; Wed, 03 Sep 2025 13:19: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 1utnOF-0001dc-T4 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 13:19:08 +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 91432e83-88c8-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 15:19:06 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::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.9073.27; Wed, 3 Sep 2025 13:19:00 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9052.014; Wed, 3 Sep 2025 13:19: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: 91432e83-88c8-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZCyramYxvCIMt/sQp/CbVr+f3EMhiSEqVB8cCE/b8f8z3QHvEWRmYHtioR3MryZML0WKdSHWlW8Tbzmh9bb8kQYEhX7ngnBTUDsGcVO76hBTcQLO97fRBqV9+68XzIS45d+EtejRUCBXbXHyPZZhm7bQ65IsmkDUaF1qmDI4D8gLtTF/UiGgiHRJu8vzHyGMbCYviwWgoW7PPnxt3dl3mABYiQZKPPAG1BjKzO++1dlEMkcHk3XZKgSHU8wJOEWLbdOZ9vbdVd6Ay/mYFBkbZoiI+qb2jQbtxc+B24flWFJ6fW4ZXjEDucDLyXiolzP/eiPjvo3gZhP/lSprFCiDLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AaHCelQ59jKtKWLwfwblTdez/+Ey8JJ4o/qqx28tWCs=; b=W6oSgzzzH7JiIjxafOr5ftja3LF83R7RbG9MPSmA5WIgmDdQyNh4hXMBy1EYlRBi/W4h4/AQ8ftESSkpTtWRIrX6cS1tkVayRXJPJ36JGnvQBgFNCeZinmyYIq6zxKHKF4ebSDonS6tr7zoG9Qf6jvw0ndjY1lNFhThdzReT444G2oD1XRrACsa51coUzsVsdMCxEYORLtf6JNbFgJhNQ8NlD9IU0vIzjIeTRjWrFlqFDBKcphmoWngIkHgA5gNIXWxyjzP8mh+/zgUluo0GTrErwDpT/CG6WQHtzCHry9K/yar7GmKZMAq5S/xK+ACJW46qtewKHAqEuJ7y8c3WMg== 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=AaHCelQ59jKtKWLwfwblTdez/+Ey8JJ4o/qqx28tWCs=; b=NM3WyjoaDwrrAix1UHB3bL30LLGYEwHN5Mx1TzyJtMhv/+8Fh5uD/H0RIfNPV8hnyPXGTqe+gO8EtDV1XbdzJpYAgjbsFXhcDZyPrLtrU0KyTOEvrhBJ/9YOqacOUUaYcgEMtoBcxaN5CVtA3ZOradVzs7y4V9yAmmPtyMjmYL2fMKr9c5EmyDvswd88DY31FCIXX1DT/l7bDatf2DxL2kIaXio+36VPaaK+oTuMKpghIGPAB1IVDMo5bJe29AETF2jKqyZXlbbFzqTjF60/3F+r/OFx8eWAiEpKVtzZ/7d/jEr0qq0x/saJ9LkhRP33LB9N/aysd9WYFckLRUpYBQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 4/4] docs: arm: add docs for SCMI over SMC calls forwarding driver Thread-Topic: [PATCH v8 4/4] docs: arm: add docs for SCMI over SMC calls forwarding driver Thread-Index: AQHcHNVMacs1ox/gAk+LMlCTxD8NJA== Date: Wed, 3 Sep 2025 13:18:55 +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: PAVPR03MB8946:EE_|AS8PR03MB8120:EE_ x-ms-office365-filtering-correlation-id: ea08d6e3-eb61-49f7-7546-08ddeaec71cb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?6c297EsFKHeuXRPgsVJW+RNqKumchFM5AUCsfO5gqcNstE4lGrGoB0uWCn?= =?iso-8859-1?Q?XFRdFGqaOi2s7syoSa26knAjy46BnXO3X1Kgrs2UT0hlEI5zRtS3WEz2wr?= =?iso-8859-1?Q?I9hI4ovHdlkodP6CRmbTM0aMzbxD86hygIYLD90EsFm4dkj57TzvQqB8NZ?= =?iso-8859-1?Q?dRm/C1WOIwyZSpKJE7z9FFQYfMfltjNKHUdLSB2a6uhrltGf7RSNlFboz8?= =?iso-8859-1?Q?/51qvKMpfPUULSsBqhhUVPkPZaJcol+e7Byf6bC5mSAx8P/RIOlw87gsRt?= =?iso-8859-1?Q?yA4DA8NPzQyn1nQm2rvtL/9TG5F+TMWz2q3AzcRqimJ9AMtnRvYFsHvwZ8?= =?iso-8859-1?Q?/kUzTzSKh64GuBQm3eQ932jL9kPPoZs32IuyKbfPTvVj4DAEXPGFS8vzHE?= =?iso-8859-1?Q?J2Dv5DpbUfjoFEmyYWyQl3+QVognLYSxAlpLn32xg3l+xNzoakOFxVnoIM?= =?iso-8859-1?Q?g4T3lPr+ylPeBJCGi7o6wVXuBx5O1PYfGWrtltM6zrXGjaA5k71Yzjjxis?= =?iso-8859-1?Q?/1/PlIXJRCIChiv9VBS9CClQjfznfBTRbPGWd5rq9lavE85h6ipvlDldnk?= =?iso-8859-1?Q?dvpJ1VmHPhA5e7n82IO520Edr+stJnRbc2HAbAhLi4tF3HV7NM1hMx2XiA?= =?iso-8859-1?Q?kWt3HymdFt46uQL4My58wY4zCchZswb2JwmNE30+JRuJDv57fqQW8EHfw5?= =?iso-8859-1?Q?u8XA9RCtAB3l48Go0NB+vHELvsfYgO7HoRzCSCm79yR6iIRHWgOCiwmnRu?= =?iso-8859-1?Q?dHLu+jal2hhJSXZUiN9VPSDnagb35Jt4gj4nBE+XLTwlDJ98xP8yyZ2zxU?= =?iso-8859-1?Q?d6ruY7V+Q2dvYhVe0dl6Gpq9m80mQycVIHoinNgkgvEOdDYYz0oTg7KUWB?= =?iso-8859-1?Q?wTmXe0zCr0LOzyFQcsCd+XiqC0j5XIIJQMiwUXyYmmDbS6zq/qCQ7MTNZW?= =?iso-8859-1?Q?xZsMrStsOhce7IWZNB6CMcDbi4MyKfRZcbWj97rZ/+PVCIrMl8zG7WUe+k?= =?iso-8859-1?Q?ebnvDRG7HLx4lOII86oDyxDyukZfYP7KjXlx+heIGMdpGnN/wkDc6tMy6x?= =?iso-8859-1?Q?NdMy9bZ+yvxUbiE15K9c+GaTIw7b0gNtxpKzBBZzNCpwWV9XEUkBgm9hCH?= =?iso-8859-1?Q?8sziRyWPqweJ9xR98+P/JiDscZTfCWdJtJKKCOp8M8XyTNOfUyNrmRQaUW?= =?iso-8859-1?Q?FRqLIMPG2G1Zk5wemz/Xy9Cze3nzR4KXTGiru2ny63bnzrrdvOiFZ1thho?= =?iso-8859-1?Q?jeFSWaUpNdZvP3ugq6dKsBMiLdIUTNfXvwf2A03pSqjTc9sfaszsasyMAR?= =?iso-8859-1?Q?umP9uOryWEluxb3RNGQyoLpqNnRRvJTPl8cfn0Vg2errvOLP3Ha3a+hme5?= =?iso-8859-1?Q?UOLEdYfwjlabj1KwhSGR1mj/irGbg4UAGaFAuww+ulS07dQRnLOj8vrQ7v?= =?iso-8859-1?Q?ftOkQYaEFwjUPWGWZ5m2qA5GDUEUfXcVPH5n3NG+JsB1no0U97sq92NhZl?= =?iso-8859-1?Q?E=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)(7416014)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?H21j2teYAl0eYPOXUeuLjVe1RNDMtO97at+gaYXXCWbjp5So5kbirsY+r+?= =?iso-8859-1?Q?tVbS2qwjMiFtfzAu9ohEa55GpYiRmA9cqGCrURLKzoAPwioTbm4j+3EEcX?= =?iso-8859-1?Q?1hhaqEqfhm52NjUAaElB5+RBe542G9KYoboteyAhD3VX6F+IYa8/eN4c0e?= =?iso-8859-1?Q?mqTmhw5F6Rf8ZF0sThyHVZQlIEg2N6M2UgrziCGHbgpKEM+F10zSNvQAEH?= =?iso-8859-1?Q?SfX6zobvk6JiB5AAdFbYvFjqqQ20Rrw8F3fpwC3bMSblUhCOgNDH5h/rI5?= =?iso-8859-1?Q?p5Ebhi1ZHo8RiJ/oYrNnh56b6YYxuDG4/JWo2rzOhwAPTJjI5A1mwlTClW?= =?iso-8859-1?Q?714X4RWNZxo+XMHv1BQMcLWkcTvTxOc7EIEPOShNHYlyGGoATiIQYLUsAr?= =?iso-8859-1?Q?PI96v4dh0GoggysU+8zwsa8sRaPnx/SvKJMekCC8kk2lIEiwaN4ZBbi1Vi?= =?iso-8859-1?Q?fHpo+d0wffL5Bx8M/KtM6npYWidAKzNUG2H0VoMqEM8Pyuth/vCWenW6Vi?= =?iso-8859-1?Q?Ff8Ns7YlwZvb9kmx7C54EiFmDKAoh64/+LZHDlP9VTfeF8oefm3yJ/6y7n?= =?iso-8859-1?Q?cR6PqBvZYEBnUnrfxeXnDjbja+udPxSWjcq+vAnlNzJa8EjzGMLsGvzc9Z?= =?iso-8859-1?Q?h5KcEEEcxGmmiDi6l7fYbqYjcey8Nkdhx3e0zEMrKkwlyfuukIw2aoF3aP?= =?iso-8859-1?Q?EHgUXPk10egboensgzZPnwN+HIwQHVlC6PVUyImTw/9Fl1R9Z3nG9VVj1j?= =?iso-8859-1?Q?bBHvcxGOlIe4Aj4uFzjQOqoUrCbiw3oMzFvahSryMjgUIjdp5wZkNIQ81k?= =?iso-8859-1?Q?yULUPOKLnUrXeXuX3aqY1h6/AgS4+MC7ew8XG1UwVcnivgv+vYikBnr8vt?= =?iso-8859-1?Q?w5B11eNhl8e9Ryuzz8T4fY6K/P3wu2ZQLQ4V5tmiEIALQmT/+joLr/JFz5?= =?iso-8859-1?Q?ldfRju9OvO78D61ON5nx+3E+MfsYi9k00Lr9Pb9qTMhyTTvjZ+Bp7GzsOv?= =?iso-8859-1?Q?YE0TNbf9qL6mRCX/Ce7Un+WmBAZ7yDlGb2rB6X8ow0lrRdwP6HwvouKAHj?= =?iso-8859-1?Q?P3iHpfQtLsLU/r25wX854w/Iy9TFEtE1PnafgrfaKLmq080kfu6Wtm987E?= =?iso-8859-1?Q?qfT3P/Vdy6gY6Oji8HigVH6TL0lPWqpWS9oZgmnme2DRlfLVTggK3Dgs18?= =?iso-8859-1?Q?SijAllhtVcwuZhVadj64MFe9Xe/zz57FZL9ihTZrwE+QviYU2kuEFYy5Bf?= =?iso-8859-1?Q?HEyF+CD1AlYEm7NKRKdEas0EVyCNfgieT/osBlbTRVrOR5IINbg8DcXNjK?= =?iso-8859-1?Q?ifE0NNDJu8ni2u5BRk7rqpqwBbkoMYrnt+RP92LCSfJsGzSHA0M9USGsTs?= =?iso-8859-1?Q?oFv/UsP5wtc5f5luZdIUoKmyIao8Z6dUsgKzLnUF/Y0Oof6u0hXRTvg08s?= =?iso-8859-1?Q?OoDwpEeOKT3y9m6DhKKobe2jZk+QYad4HJjdXVhKovPwNpDVAEzOfNUYbL?= =?iso-8859-1?Q?LPcmWScdED+OrS//yiRuQvZwuGjXxHX9OAJEl3QHvJoE5v5j5tvW688+mc?= =?iso-8859-1?Q?PUE2W8MV5NR4GrnrCh9Kujt/VsuTd9JyEcHRJePrXcSHy4G1Yegmn/9Ht2?= =?iso-8859-1?Q?QEKjk4zJ9JlJzviL/TiLePkpJqoQTyVaPqzSlJc5OpS3NZfz8IaxMB2Q?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea08d6e3-eb61-49f7-7546-08ddeaec71cb X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 13:18:55.9671 (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: sImTxDDug51v/QHmVtYqZnUtTF7M/DISzwjplzpqNycE+1BkNcKTTJly+UoJfbzuQsMWV1GDy0al/6yjPZ3+EXl6MjFVBTrUBHf1Q83k+Cc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8120 From: Grygorii Strashko Add documentation section for Simple Arm SCMI over SMC calls forwarding driver (EL3). Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- (no changes since v7) Changes in v7: - fixed typos Changes in v6: - add link to the scmi bindings used in the doc - remove mentions about HVC calls from doc - rename cmdline parameter to scmi-smc-passthrough Changes in v5: - rename dom0_scmi_smc_passthrough in documentation .../arm/firmware/arm-scmi.rst | 180 ++++++++++++++++++ docs/hypervisor-guide/arm/index.rst | 9 + docs/hypervisor-guide/index.rst | 1 + 3 files changed, 190 insertions(+) create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi.rst create mode 100644 docs/hypervisor-guide/arm/index.rst diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst new file mode 100644 index 0000000000..d65ce35acb --- /dev/null +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -0,0 +1,180 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +ARM System Control and Management Interface (SCMI) +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D + +The System Control and Management Interface (SCMI) [1], which is a set of = operating +system-independent software interfaces that are used in system management.= SCMI currently +provides interfaces for: + +- Discovery and self-description of the interfaces it supports +- Power domain management +- Clock management +- Reset domain management +- Voltage domain management +- Sensor management +- Performance management +- Power capping and monitoring +- Pin control protocol. + +The SCMI compliant firmware could run: + +- as part of EL3 secure world software (like Trusted Firmware-A) with + ARM SMC shared-memory transport; +- on dedicated System Control Processor (SCP) with HW mailbox shared-memor= y transport + +The major purpose of enabling SCMI support in Xen is to enable guest domai= ns access to the SCMI +interfaces for performing management actions on passed-through devices (su= ch as clocks/resets etc) +without accessing directly to the System control HW (like clock controller= s) which in most cases +can't be shared/split between domains. Or, at minimum, allow SCMI access f= or dom0/hwdom (or guest +domain serving as Driver domain). + +The below sections describe SCMI support options available for Xen. + +| [1] `Arm SCMI `= _ +| [2] `System Control and Management Interface (SCMI) bindings `_ + +Simple SCMI over SMC calls forwarding driver (EL3) +------------------------------------------------------ + +The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is pret= ty generic case for +the default vendors SDK and new platforms with SCMI support. Such EL3 SCMI= firmware supports only +single SCMI OSPM transport (agent) with Shared memory based transport and = SMC calls as doorbell. + +The SCMI over SMC calls forwarding driver solves major problem for this ca= se by allowing +SMC calls to be forwarded from guest to the EL3 SCMI firmware. + +By default, the SCMI over SMC calls forwarding is enabled for Dom0/hwdom. + +:: + + +--------------------------+ + | | + | EL3 SCMI FW (TF-A) | + ++-------+--^--------------+ + |shmem | | smc-id + +----^--+ | + | | + +----|-+---+---+----------+ + | | | FWD | Xen | + | | +---^---+ | + +----|-----|--------------+ + | | smc-id + +----v-----+--+ +---------+ + | | | | + | Dom0/hwdom | | DomU | + | | | | + | | | | + +-------------+ +---------+ + + +The SCMI messages are passed directly through SCMI shared-memory (zero-cop= y) and driver only +forwards SMC calls. + +Compiling +^^^^^^^^^ + +To build with the SCMI over SMC calls forwarding enabled support, enable K= config option + +:: + + SCMI_SMC + +The ``CONFIG_SCMI_SMC`` is enabled by default. + +Pass-through SCMI SMC to domain which serves as Driver domain +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This section describes how to configure the SCMI over SMC calls forwarding= driver to handle use +case "thin Dom0 with guest domain, which serves as Driver domain". In this= case HW need to be +enabled in Driver domain and dom0 is performing only control functions (wi= thout accessing FW) and so, +the SCMI need to be enabled in Driver domain. + +:: + + +--------------------------+ + |EL3 SCMI FW (TF-A) | + | | + +-------------^--+-------+-+ + smc-id| |shmem0 | + | +----^--+ + +-------------++------+|----+ + |Xen | FWD || | + | +--^----+| | + +----------------|-----|----+ + smc-id | | + +-----------+ +--+-----v-----+ + | | | | + | Dom0 | | Driver | + | Control | | domain | + | | | | + +-----------+ +--------------+ + +The SCMI can be enabled for one and only one guest domain. + +First, configure Dom0 to enable SCMI pass-through using Xen Command Line +**"scmi-smc-passthrough"** option. This will disable SCMI for Dom0/hwdom a= nd SCMI nodes will +be removed from Dom0/hwdom device tree. + +**Configure SCMI pass-through for guest domain with toolstack** + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" + +:: + + iomem =3D [ + "47ff0,1@22001", + ] + +.. note:: It's up to the user to select guest IPA for mapping SCMI shared-= memory. + +* Add SCMI nodes to the Driver domain partial device tree as in the below = example: + +.. code:: + + passthrough { + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x22001000 0x0 0x1000>; + }; + + firmware { + compatible =3D "simple-bus"; + scmi: scmi { + compatible =3D "arm,scmi-smc"; + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +Please refer to [2] for details of SCMI DT bindings. + +In general, the configuration is similar to any other HW pass-through, exc= ept explicitly +enabling SCMI with "arm_sci" xl.cfg option. + +**Configure SCMI pass-through for predefined domain (dom0less)** + +* add "xen,sci_type" property for required DomU ("xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc" + +* add scmi nodes to the Driver domain partial device tree the same way as = above and enable access + to the "arm,scmi-shmem" according to dom0less documentation. For exampl= e: + +.. code:: + + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x00 0x22001000 0x00 0x1000>; + -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; + -> xen,force-assign-without-iommu; + }; diff --git a/docs/hypervisor-guide/arm/index.rst b/docs/hypervisor-guide/ar= m/index.rst new file mode 100644 index 0000000000..7aae4a0a03 --- /dev/null +++ b/docs/hypervisor-guide/arm/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +ARM +=3D=3D=3D + +.. toctree:: + :maxdepth: 2 + + firmware/arm-scmi diff --git a/docs/hypervisor-guide/index.rst b/docs/hypervisor-guide/index.= rst index e4393b0697..520fe01554 100644 --- a/docs/hypervisor-guide/index.rst +++ b/docs/hypervisor-guide/index.rst @@ -9,3 +9,4 @@ Hypervisor documentation code-coverage =20 x86/index + arm/index \ No newline at end of file --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 13:19:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 13:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108274.1458471 (Exim 4.92) (envelope-from ) id 1utnOF-0002JM-Lf; Wed, 03 Sep 2025 13:19:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108274.1458471; Wed, 03 Sep 2025 13:19: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 1utnOF-0002JB-HO; Wed, 03 Sep 2025 13:19:07 +0000 Received: by outflank-mailman (input) for mailman id 1108274; Wed, 03 Sep 2025 13:19: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 1utnOE-0001dc-48 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 13:19:06 +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 8febc884-88c8-11f0-9809-7dc792cee155; Wed, 03 Sep 2025 15:19:03 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::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.9073.27; Wed, 3 Sep 2025 13:18:59 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9052.014; Wed, 3 Sep 2025 13:18: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: 8febc884-88c8-11f0-9809-7dc792cee155 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MLQ2FZvMbX5L1MLTkR5iouQ0gTQXh6n+scZuIHbgKlKn4bnAEV2eAbGCTmciXiZVvR3o3u+lxd+bh6SdPJal1WmKxCWupH8qPdyzKRaYqgTfGbhcYCHUKvz5eiLQhHZfVqAsT491rxMQFWqqtQwwU9Yuk2YSj+02/WGPekMzqTUYcSuZuyzTR78GvWPQ4SnEOUCH7Z1uyXOaH+R/1oJGqm8MBaxKbSFqfeWx5BV3CMDhtsgdJP8YwYGdYINjhDGrerAxUPB8q7Fe5AnBHOMeZRQmzWMMUL3juWQLni3zj56EiCxeGDlsrQ+wMTlMA9FqV5aqCvP4eI/GlxtwvQX+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=2Mm03IUR6xnzmkwFBucRTvpL5NnWIb+JOPQ07cSTRto=; b=Jzjs9g2wfBfUR/YhevOtWqaiXfM17YwKNPpAolbGFtJcCcq6cnh/yhdEm6ywRlX7QG1zSMKRhkXk2x3+0C7/qcotOl+LXK9Eq6syIgAi02HgGxI70oZ6xYzUHzTWdrBmOggbXHhntRP9I1P82nEkqwrbsIBM3YenOzSaLTsH8j4j7u7MOvuHw7TpdTXHvx6SBQmIIbW7PvUDczBD+ItpvD6DZqXCZFhQx5LUuLubYgIqIem5li11H1TF/6CeL9IYuHfeqKktfxcb2nGI791yxGj9BUno6qRtrozP5Fsdp1lOH2ITM3+Ke2UH2+OfKR4TeIDaGjro8GoLe5M/kBOIgA== 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=2Mm03IUR6xnzmkwFBucRTvpL5NnWIb+JOPQ07cSTRto=; b=VF1fiioOFhT3XRvLpho81yn8jmPT9SGtBEZpyxNmL6waXAV9//m+JJ+M8H4kvkZSXL3FmNmRMbj2YiF4WrTu/pESWkCaUE+cjhu6t/SfjUTXcLD2kbScpX5SS5mbVHrHX/GpZ/znPt0uHvjh8/5PzuW9160lmBQNffi0RgOXj9pWy0mN/KlsnDNsDORRHJDMBfyB9msQeZONV7FAYOBgsPCcWVVL1Yp0IfAE/LUg8olWxpp+vLB+KYM6sfPclROBi+XwAYHaIfjk0gsTgaYwfNY2yj7Z/kkz1A8X/126RkMwZQHatR8cX1B8hZ+yeiZ6O1NiumlZz3Y96i6325FOsQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent Thread-Topic: [PATCH v8 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent Thread-Index: AQHcHNVM0KndCD74VkeM9gjMBTxXTA== Date: Wed, 3 Sep 2025 13:18:55 +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: PAVPR03MB8946:EE_|AS8PR03MB8120:EE_ x-ms-office365-filtering-correlation-id: d23c5f3e-8478-4a35-32d5-08ddeaec712c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?iBnhsj+M+/twG/Mip9x7LSs5/SCzbLfI/IpsLCWfiCbiLRyJejVGJJ2BnY?= =?iso-8859-1?Q?LdLjhmHQfA4hDqdVA3tns5XmIkof3H1u5Ndyg120u/1OdWudmOPCgI9AR3?= =?iso-8859-1?Q?LAD5OBJVexyfAtweOkpKSmK0lPkRR3p9zg/20EeK9NCuAij2LuvqpWFep3?= =?iso-8859-1?Q?u0NxvdAQgJpYS76Igb5svPnOsCuKUr2QiT6Rl+bQJypzxpQHQLDHUTNAgy?= =?iso-8859-1?Q?QGk5Hp8tMJ0MBgJJBV+VKJLZYbebo3J5PTG7uzSfKtgXUAhCc8Kz6vlzhe?= =?iso-8859-1?Q?R9vc7IT17wvI6JAKJ/OqgiZ5NrAzFQfgQTK3UdL9ST6WiWujmvEIDRPDc6?= =?iso-8859-1?Q?KyO7bb0Ub5SSJXq3uwFE8IoQjlSy+HShTX3QirfWk67kXqelv4qhPhz4a+?= =?iso-8859-1?Q?J6KT4l63FM3ERcg4yvOaJ1CSggiNRfm1vgTt0UPrt2sNrUTgTSqCa6vhnN?= =?iso-8859-1?Q?xYZ/nkdfNHUQs0Ii08Fosvbi4LbZEH6n45Jvg5kor+neHUKFTt4TFZIPua?= =?iso-8859-1?Q?2ml2m7YtIt4gbq7VVVcJwtFyVBVfq5/fiVpsU7sqq3C0K4ZCFTZh8WxhHP?= =?iso-8859-1?Q?V1VSK5yEegIyd5nXnQDSzmSpJzwfShE5jmqHdVKf5UfeTK7K5Dk0wRxcp/?= =?iso-8859-1?Q?j9aOfURh5pc554yzENuplGf6mFL8Utxl5UWSp1znfL6OY7lu0EkAQlA/tA?= =?iso-8859-1?Q?Cpo5Ar7wUP8VlJJjPhfSDbE81fsbJzlATQ+uoTdJoZhGpvJ+SnV6zFjfoI?= =?iso-8859-1?Q?C8dQEQZfi7atM+ama+XUBaZGQA+OKSdgmsZ7wPNmhecmp02tDn3FU50x+A?= =?iso-8859-1?Q?igcit9YaD30R5bbn+K8p3fXk0yXiyo5xojy0sUmMBpOc017wFA/0ftqDIO?= =?iso-8859-1?Q?c/4LX+/R9Igo2aOadFaYjE0H+/tYxwKsWaKJbVVxuHWVptr0TTLKfmoUlW?= =?iso-8859-1?Q?3QqV23Z477uYR1c/9TND0ChH7l8swfMwoXE0PWQy+c646R5MbzLg/gHLXT?= =?iso-8859-1?Q?uNvVB4OoqJTn4QT2z5xRkwLk8uh5eVn+1VA1QmqFt1FHWeS8pMchVBUKrj?= =?iso-8859-1?Q?4Qk744I7mlvv9A9CHKKTJKecwbKaQhdTWLMkqhzTl7UISflArwAXrRJxBH?= =?iso-8859-1?Q?/oC7fkaDpkVg07uQ/4gRsGb6pP4diRk2+c9bKqlsSjjep/mxoy6pXE3IdH?= =?iso-8859-1?Q?OZ/tQCso98k1o4EuBE7LJSahRPduq/OcKpkkUC+nK2uoBiqLYSOB3LIKFS?= =?iso-8859-1?Q?IhQtwMS4kQ9azBWIo9JHb9QS3XcvaQRpt230/Iy3ll1fnyHF/90dn7AA5s?= =?iso-8859-1?Q?UlrzZtCxalgQNWlJbcyYKdt3GqJuNNYuAHwFzuq3Sm0ql5ley1VZjLQTw6?= =?iso-8859-1?Q?7ksQyjQvi3clvKUdhJutngof3toOUAMU6X9sizhVRtgPHzn+oUtsgyM9bB?= =?iso-8859-1?Q?Z1qIyWoaG1n0LC8eGEEhQ/ZbmOiMrhfl7NRVvHR3HuZfL+oa/dFJeUQV86?= =?iso-8859-1?Q?v5xqpY1+x9cBFKUPMAAITSMhjyJkFF6L7lM+9f6CJLBA=3D=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)(7416014)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TlL0+hWVANqgj8asuYqdB45OJPP7fOM/a6mw0iVgzDrlmOG/k1MCXo09TC?= =?iso-8859-1?Q?JyHfA6tFSACZGJSbq4UVvc6rfvpKqdBTMGa3em7habxtRzNKSAWfcy8QQt?= =?iso-8859-1?Q?bVF+H7g5JIETDGUm9ZKUqrDjEikeTQkRVBbN3sZeOBvKHfZ7hqQXZK+Xm1?= =?iso-8859-1?Q?7cW1GDmNab4SQMhh0yNIHOInFprHxwlP/ZrceHpjEJ1uhuJnPU2af1cogc?= =?iso-8859-1?Q?U205i/kEzGA4340BjBUcDni+hiJQNbzZeVAnhCTGOupl+okl+IFn0bViqO?= =?iso-8859-1?Q?Bu4lImLcTZNq0WRhx6mFAkT0FYxqoSSxuPKnLPv9eWiV8P1Bi/sGtsfdXu?= =?iso-8859-1?Q?AP+o3CPCdqtkh+v+fJ8sF1ujuirhkw2cKGq8Y1WLCgAo4mBsHjLYNraCLg?= =?iso-8859-1?Q?Mt3uX+Xalcop/3ZjXX6m7fCTr5JoW46BfLTz70I3pqnN0RhZbYHjf4q2Pb?= =?iso-8859-1?Q?9Cddj5aY+BuOSgiCZ+zh67iiCZ6BF0QJ+RMtkai4ep5BPteWEpNlM3dspF?= =?iso-8859-1?Q?cTbnU3Xsww6+LV2eYykcimNVrej4FjBt3rESDHKyTUu9+vpjLRy+mVk16C?= =?iso-8859-1?Q?hewTCtLiQMES/Dn11SnrEP+YPJm4YR8+gXDjwuAVRXthZKcGpX47Rgr6jB?= =?iso-8859-1?Q?PcozQpQO6jA/nRDQ5zrqPjZ3vtl5yMrYvyx3CZMu5c1tWvCygKIp5OR9jS?= =?iso-8859-1?Q?eWZ8qJbXOiLhpPwemx05f8trxau1MiWEibiKqe5Zn2rTnvztKS1lNqnzYh?= =?iso-8859-1?Q?rL0RAtJkUfBaiA8uaGh+bOVB/5CJMSB0Cuj7IVG9DjWmmC/mCQR8chvDoc?= =?iso-8859-1?Q?Y392OYzpgJzlWYQlczs2Ym37a1Kdt9Q7CsF0xb5UEtBefxgflkS7khQoI4?= =?iso-8859-1?Q?t6DzYhtSnnh6Swb63kxrI6BRW3dy9Cpvmg74lPeyGhfGiHKKuw+bOyFv91?= =?iso-8859-1?Q?S9u5NRTjymFVNId+t7yf9JOawvRoPIWg5+8B6twQJGme7YUTxWHDhqeoDT?= =?iso-8859-1?Q?e0Vdtnd31m5DiyOZgxI3rHAntKoMvqDf3dGfEIOOVX8OL8mJWjCp2sXVVD?= =?iso-8859-1?Q?zgWKWfiJ5SNb8LIEFzZaZk3aN1vKrsa32Wl3gkVedwk8mtILwTScx+4MLn?= =?iso-8859-1?Q?FTPBxiFwqAudnFbh7Fioo4qNbk8SLu8L3gGEEMBFtQDDKxb58Ugc0kSude?= =?iso-8859-1?Q?V9h9/3KgcV7PiBQWTt25KgfUSy7oUDuqGykkdeq3wmy7C92tOrGQ/D9LXr?= =?iso-8859-1?Q?vKzpjQEFeJuTYHbTYooO5/cDrD6jYH/2ScNw2X5ZBwtQQMnQunRPT+tyCU?= =?iso-8859-1?Q?P0FJOzov5V4awTRcMBYCBt25e4ilZ77ciqTzD6Pwe6DdmNh0jC8b5zxxEy?= =?iso-8859-1?Q?wbvx1fXsP/bqZz5L9orGcTTojIPBRAbxoLFS4uoS5cdHMnqgHR0iqdY+Sv?= =?iso-8859-1?Q?wyaiLR362w44VQdx4jq7VIw8eY4+hHUWBQFN5X8Vd0o/x1eGuVULWmXSuR?= =?iso-8859-1?Q?YpyeY+3l70JE/pZfp2bZms2WBOnSfOEJ0FEDQwsW0VrScBzbVzh7XkSyCt?= =?iso-8859-1?Q?mYxJlmJBu+ex7dMNX/dJAR/YRNIm/oShvyVol8aZyw7+RqXZgl5IgMzKdI?= =?iso-8859-1?Q?ombMPlwrC1/dpF1csKbJO4X3D/4WWcWIwS4CkHC6qTZJeHg93gvZ08xQ?= =?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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d23c5f3e-8478-4a35-32d5-08ddeaec712c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 13:18:55.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iZqTW/wkC7JaVGmrkWO6oN7XnyLBo+CQkVj1MYz3GTEPelSunx/LhjKqAHuZe+MapTdrgDhUpQostLTGGkTIvdkTymgSGavOd2lmAVoqbbo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8120 From: Grygorii Strashko The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling layer") introduces simple driver which forwards SCMI over SMC calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent support. While it is working gracefully for hwdom/dom0 use case it doesn't cover "thin Dom0 with guest domain, which serves as Driver domain" use-case. In this case HW need to be enable in Driver domain and dom0 is performing only control functions. The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is pretty generic case for the default vendors SDK and new platforms. This patch enables passthrough of SCMI SMC single agent interface to the one guest domain serving as Driver domain. Configure Dom0 to enable SCMI passthrough: - dom0: add scmi-smc-passthrough to the Xen Command Line Enabled SCMI passthrough for guest using toolstack in the following way: - domD: xl.cfg add "arm_sci" option as below arm_sci =3D "type=3Dscmi_smc" - domD: xl.cfg enable access to the "arm,scmi-shmem" iomem =3D [ "47ff0,1@22001", ] - domD: add SCMI nodes to the Driver domain partial device tree as in the below example: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; shmem =3D <&scmi_shm_0>; ... } } } dom0less case configuration: - add "xen,sci_type" property for required DomU ("xen,domain") node xen,sci_type=3D"scmi_smc" - add scmi nodes to the Driver domain partial device tree the same way as above and enable access to the "arm,scmi-shmem" according to dom0less documentation. For example: scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x00 0x22001000 0x00 0x1000>; -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; The SCMI SMC single agent interface can be enabled for one and only one domain. In general, the configuration is similar to any other HW passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option. Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from dom0/hwdom DT when "scmi-smc-passthrough" cmdline parameter was provided. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev Acked-by: Anthony PERARD # tools --- Changes in v8: - reneregated {helpers/types}.gen.go, dropped unneeded parameters Changes in v7: - Fix commit description. - Move scmi-smc-passthrough definition to match alphaberical order - remove unneeded initialization with NULL - changed u64 to uint64_t - Send warning if iomem permit access was failed Changes in v6: - added generated helpers and types go files - rename cmdline parameter to scmi-smc-passthrough - fix goto tag in parse_arm_sci_config Changes in v5: - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough Changes in v4: - xl.cfg doc - fix comments from Stefano Stabellini - fix toolstack code as sugested by Anthony PERARD - use MATCH_OPTION() - move arm_sci struct and cfg params in "arch_arm" - add SCMI passthrough for dom0less case docs/man/xl.cfg.5.pod.in | 34 ++++++++ docs/misc/arm/device-tree/booting.txt | 15 ++++ docs/misc/xen-command-line.pandoc | 9 ++ tools/golang/xenlight/helpers.gen.go | 35 ++++++++ tools/golang/xenlight/types.gen.go | 11 +++ tools/include/libxl.h | 5 ++ tools/libs/light/libxl_arm.c | 14 ++++ tools/libs/light/libxl_types.idl | 10 +++ tools/xl/xl_parse.c | 36 ++++++++ xen/arch/arm/dom0less-build.c | 34 +++++++- xen/arch/arm/firmware/Kconfig | 4 +- xen/arch/arm/firmware/scmi-smc.c | 115 +++++++++++++++++++++++++- 12 files changed, 317 insertions(+), 5 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index acff45d308..3b18bcc095 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3123,6 +3123,40 @@ writes will be ignored. =20 This option is only implemented for Arm where the default is enabled. =20 +=3Ditem B + +Set ARM_SCI specific options for the guest. ARM SCI is System +Control Protocol allows domain to manage various functions that are provid= ed +by HW platform firmware. + +B is a comma separated list of C settings, +from the following list: + +=3Dover 4 + +=3Ditem B + +Specifies an ARM SCI type for the guest. + +=3Dover 4 + +=3Ditem B + +Don't allow guest to use ARM SCI if present on the platform. This is the +default value. + +=3Ditem B + +Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC calls +forwarding from domain to the EL3 firmware (like Trusted Firmware-A) with = a +single SCMI OSPM agent support. +Should be used together with B Xen command line +option. + +=3Dback + +=3Dback + =3Dback =20 =3Dhead3 x86 diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index 07acc7ba64..977b428608 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -307,6 +307,21 @@ with the following properties: passed through. This option is the default if this property is missing and the user does not provide the device partial device tree for the d= omain. =20 +- xen,sci_type + + A string property specifying an ARM SCI type for the guest. + + - "none" + Don't allow guest to use ARM SCI if present on the platform. This is t= he + default value. + + - "scmi_smc" + Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC c= alls + forwarding from domain to the EL3 firmware (like Trusted Firmware-A) w= ith a + single SCMI OSPM agent support. + Should be used together with scmi-smc-passthrough Xen command line + option. + Under the "xen,domain" compatible node, one or more sub-nodes are present for the DomU kernel and ramdisk. =20 diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line= .pandoc index 4adcd7e762..518e42d965 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2382,6 +2382,15 @@ sockets, &c. This will reduce performance somewhat,= particularly on systems with hyperthreading enabled, but should reduce power by enabling more sockets and cores to go into deeper sleep states. =20 +### scmi-smc-passthrough (ARM) +> `=3D ` + +The option is available when `CONFIG_SCMI_SMC` is compiled in, and allows = to +enable SCMI SMC single agent interface for any, but only one guest domain, +which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom an= d +SCMI nodes removed from Dom0/hwdom device tree. +(for example, thin Dom0 with Driver domain use-case). + ### scrub-domheap > `=3D ` =20 diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/h= elpers.gen.go index 667030cbd7..8909fe8a1b 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -938,6 +938,35 @@ return fmt.Errorf("converting field Vcpus: %v", err) return nil } =20 +// NewArmSci returns an instance of ArmSci initialized with defaults. +func NewArmSci() (*ArmSci, error) { +var ( +x ArmSci +xc C.libxl_arm_sci) + +C.libxl_arm_sci_init(&xc) +defer C.libxl_arm_sci_dispose(&xc) + +if err :=3D x.fromC(&xc); err !=3D nil { +return nil, err } + +return &x, nil} + +func (x *ArmSci) fromC(xc *C.libxl_arm_sci) error { + x.Type =3D ArmSciType(xc._type) + + return nil} + +func (x *ArmSci) toC(xc *C.libxl_arm_sci) (err error){defer func(){ +if err !=3D nil{ +C.libxl_arm_sci_dispose(xc)} +}() + +xc._type =3D C.libxl_arm_sci_type(x.Type) + + return nil + } + // NewRdmReserve returns an instance of RdmReserve initialized with defaul= ts. func NewRdmReserve() (*RdmReserve, error) { var ( @@ -1163,6 +1192,9 @@ x.ArchArm.GicVersion =3D GicVersion(xc.arch_arm.gic_v= ersion) x.ArchArm.Vuart =3D VuartType(xc.arch_arm.vuart) x.ArchArm.SveVl =3D SveType(xc.arch_arm.sve_vl) x.ArchArm.NrSpis =3D uint32(xc.arch_arm.nr_spis) +if err :=3D x.ArchArm.ArmSci.fromC(&xc.arch_arm.arm_sci);err !=3D nil { +return fmt.Errorf("converting field ArchArm.ArmSci: %v", err) +} if err :=3D x.ArchX86.MsrRelaxed.fromC(&xc.arch_x86.msr_relaxed);err !=3D = nil { return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err) } @@ -1699,6 +1731,9 @@ xc.arch_arm.gic_version =3D C.libxl_gic_version(x.Arc= hArm.GicVersion) xc.arch_arm.vuart =3D C.libxl_vuart_type(x.ArchArm.Vuart) xc.arch_arm.sve_vl =3D C.libxl_sve_type(x.ArchArm.SveVl) xc.arch_arm.nr_spis =3D C.uint32_t(x.ArchArm.NrSpis) +if err :=3D x.ArchArm.ArmSci.toC(&xc.arch_arm.arm_sci); err !=3D nil { +return fmt.Errorf("converting field ArchArm.ArmSci: %v", err) +} if err :=3D x.ArchX86.MsrRelaxed.toC(&xc.arch_x86.msr_relaxed); err !=3D n= il { return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err) } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/typ= es.gen.go index e26b3cdfc7..ab9d4ca7b4 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -520,6 +520,16 @@ SveType1920 SveType =3D 1920 SveType2048 SveType =3D 2048 ) =20 +type ArmSciType int +const( +ArmSciTypeNone ArmSciType =3D 0 +ArmSciTypeScmiSmc ArmSciType =3D 1 +) + +type ArmSci struct { +Type ArmSciType +} + type RdmReserve struct { Strategy RdmReserveStrategy Policy RdmReservePolicy @@ -599,6 +609,7 @@ GicVersion GicVersion Vuart VuartType SveVl SveType NrSpis uint32 +ArmSci ArmSci } ArchX86 struct { MsrRelaxed Defbool diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 185f74d8a8..bc35e412da 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -313,6 +313,11 @@ */ #define LIBXL_HAVE_BUILDINFO_ARCH_NR_SPIS 1 =20 +/* + * libxl_domain_build_info has the arch_arm.sci* fields. + */ +#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 1 + /* * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing * 'soft reset' for domains and there is 'soft_reset' shutdown reason diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index 4a19a8d22b..7e9f8a1bc3 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -233,6 +233,20 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, config->arch.sve_vl =3D d_config->b_info.arch_arm.sve_vl / 128U; } =20 + switch (d_config->b_info.arch_arm.arm_sci.type) { + case LIBXL_ARM_SCI_TYPE_NONE: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; + break; + default: + LOG(ERROR, "Unknown ARM_SCI type %d", + d_config->b_info.arch_arm.arm_sci.type); + return ERROR_FAIL; + } + LOG(DEBUG, " - SCI type=3D%u", config->arch.arm_sci_type); + return 0; } =20 diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index a6030a2dbd..b53e013a44 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -551,6 +551,15 @@ libxl_sve_type =3D Enumeration("sve_type", [ (2048, "2048") ], init_val =3D "LIBXL_SVE_TYPE_DISABLED") =20 +libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ + (0, "none"), + (1, "scmi_smc") + ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") + +libxl_arm_sci =3D Struct("arm_sci", [ + ("type", libxl_arm_sci_type), + ]) + libxl_rdm_reserve =3D Struct("rdm_reserve", [ ("strategy", libxl_rdm_reserve_strategy), ("policy", libxl_rdm_reserve_policy), @@ -725,6 +734,7 @@ libxl_domain_build_info =3D Struct("domain_build_info",= [ ("vuart", libxl_vuart_type), ("sve_vl", libxl_sve_type), ("nr_spis", uint32, {'init_val': 'LIBXL_NR_= SPIS_DEFAULT'}), + ("arm_sci", libxl_arm_sci), ])), ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool), ])), diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 90c9386f5b..af86d3186d 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1284,6 +1284,36 @@ out: if (rc) exit(EXIT_FAILURE); } =20 +static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci, + const char *str) +{ + int ret =3D 0; + char *buf2, *ptr; + char *oparg; + + if (NULL =3D=3D (buf2 =3D ptr =3D strdup(str))) + return ERROR_NOMEM; + + ptr =3D strtok(buf2, ","); + while (ptr !=3D NULL) + { + if (MATCH_OPTION("type", ptr, oparg)) { + ret =3D libxl_arm_sci_type_from_string(oparg, &arm_sci->type); + if (ret) { + fprintf(stderr, "Unknown ARM_SCI type: %s\n", oparg); + ret =3D ERROR_INVAL; + goto out; + } + } + + ptr =3D strtok(NULL, ","); + } + +out: + free(buf2); + return ret; +} + void parse_config_data(const char *config_source, const char *config_data, int config_len, @@ -2989,6 +3019,12 @@ skip_usbdev: xlu_cfg_get_defbool(config, "trap_unmapped_accesses", &b_info->trap_unmapped_accesses, 0); =20 + if (!xlu_cfg_get_string(config, "arm_sci", &buf, 1)) { + if (parse_arm_sci_config(config, &b_info->arch_arm.arm_sci, buf)) = { + exit(EXIT_FAILURE); + } + } + parse_vkb_list(config, d_config); =20 d_config->virtios =3D NULL; diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 0094cf9e40..418657eed0 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -279,6 +279,36 @@ int __init arch_handle_passthrough_prop(struct kernel_= info *kinfo, return sci_assign_dt_device(kinfo->bd.d, node); } =20 +int __init domu_dt_sci_parse(struct dt_device_node *node, + struct xen_domctl_createdomain *d_cfg) +{ + const char *sci_type; + int ret; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + + if ( !IS_ENABLED(CONFIG_ARM_SCI) || + !dt_property_read_bool(node, "xen,sci_type") ) + return 0; + + ret =3D dt_property_read_string(node, "xen,sci_type", &sci_type); + if ( ret ) + return ret; + + if ( !strcmp(sci_type, "none") ) + 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 + { + printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , + sci_type, dt_node_name(node)); + return -EINVAL; + } + + return 0; +} + int __init arch_parse_dom0less_node(struct dt_device_node *node, struct boot_domain *bd) { @@ -288,7 +318,9 @@ int __init arch_parse_dom0less_node(struct dt_device_no= de *node, =20 d_cfg->arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; - d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + + if ( domu_dt_sci_parse(node, d_cfg) ) + panic("Error getting SCI configuration\n"); =20 if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) { diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index bbf88fbb9a..5c5f0880c4 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -25,7 +25,9 @@ config SCMI_SMC doorbell mechanism and Shared Memory for transport ("arm,scmi-smc" compatible only). The value of "arm,smc-id" DT property from SCMI firmware node is used to trap and forward corresponding SCMI SMCs - to firmware running at EL3, for calls coming from the hardware domain. + to firmware running at EL3, for calls coming from the hardware domain o= r + driver domain. + Use with EL3 firmware which supports only single SCMI OSPM agent. =20 endchoice =20 diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-= smc.c index 4c5df714c2..0835ddeeec 100644 --- a/xen/arch/arm/firmware/scmi-smc.c +++ b/xen/arch/arm/firmware/scmi-smc.c @@ -13,6 +13,8 @@ #include #include #include +#include +#include #include #include =20 @@ -22,7 +24,11 @@ =20 #define SCMI_SMC_ID_PROP "arm,smc-id" =20 +static bool __ro_after_init opt_scmi_smc_passthrough; +boolean_param("scmi-smc-passthrough", opt_scmi_smc_passthrough); + static uint32_t __ro_after_init scmi_smc_id; +static struct domain __read_mostly *scmi_dom; =20 /* * Check if provided SMC Function Identifier matches the one known by the = SCMI @@ -50,7 +56,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) return false; =20 /* Only the hardware domain should use SCMI calls */ - if ( !is_hardware_domain(current->domain) ) + if ( scmi_dom !=3D current->domain ) { gdprintk(XENLOG_WARNING, "SCMI: Unprivileged access attempt\n"); return false; @@ -75,12 +81,45 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) return true; } =20 +static int +scmi_smc_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= ) + return -EINVAL; + + return 0; +} + static int scmi_smc_domain_init(struct domain *d, struct xen_domctl_createdomain *config) { - if ( !is_hardware_domain(d) ) + /* + * scmi_passthrough is not enabled: + * - proceed only for hw_domain + * - fail if guest domain has SCMI enabled. + */ + if ( !opt_scmi_smc_passthrough && !is_hardware_domain(d) ) + { + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_SC= MI_SMC ) + return -EINVAL; + else + return 0; + } + /* + * scmi_passthrough is enabled: + * - ignore hw_domain + * - proceed only for domain with SCMI enabled. + */ + if ( opt_scmi_smc_passthrough && + (config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE = || + is_hardware_domain(d)) ) return 0; =20 + if ( scmi_dom ) + return -EEXIST; + + scmi_dom =3D d; d->arch.sci_enabled =3D true; printk(XENLOG_DEBUG "SCMI: %pd init\n", d); return 0; @@ -88,12 +127,80 @@ static int scmi_smc_domain_init(struct domain *d, =20 static void scmi_smc_domain_destroy(struct domain *d) { - if ( !is_hardware_domain(d) ) + if ( scmi_dom && scmi_dom !=3D d ) return; =20 + scmi_dom =3D NULL; + d->arch.sci_enabled =3D false; printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d); } =20 +/* + * Handle Dom0 SCMI SMC specific DT nodes + * + * if scmi_smc_passthrough=3Dfalse: + * - Copy SCMI nodes into Dom0 device tree. + * if scmi_smc_passthrough=3Dtrue: + * - skip SCMI nodes from Dom0 DT + * - give dom0 control access to SCMI shmem MMIO, so SCMI can be passed + * through to guest. + */ +static bool scmi_smc_dt_handle_node(struct domain *d, + struct dt_device_node *node) +{ + static const struct dt_device_match shmem_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 */ }, + }; + + /* skip scmi shmem node for dom0 if scmi not enabled */ + if ( dt_match_node(shmem_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk("Skip scmi shmem node\n"); + return true; + } + + /* + * skip scmi node for dom0 if scmi not enabled, but give dom0 control + * access to SCMI shmem + */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + struct dt_device_node *shmem_node; + const __be32 *prop; + uint64_t paddr, size; + int ret; + + /* give dom0 control access to SCMI shmem */ + prop =3D dt_get_property(node, "shmem", NULL); + if ( !prop ) + return true; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( !shmem_node ) + return true; + + ret =3D dt_device_get_address(shmem_node, 0, &paddr, &size); + if ( ret ) + return true; + + ret =3D iomem_permit_access(d, paddr_to_pfn(paddr), + paddr_to_pfn(paddr + size - 1)); + if ( ret ) + printk(XENLOG_WARNING + "SCMI: Failed to give access to SCMI shmem with code:= %d\n", ret); + + dt_dprintk("Skip scmi node\n"); + return true; + } + + return false; +} + static int __init scmi_check_smccc_ver(void) { if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) @@ -108,8 +215,10 @@ static int __init scmi_check_smccc_ver(void) =20 static const struct sci_mediator_ops scmi_smc_ops =3D { .handle_call =3D scmi_handle_smc, + .domain_sanitise_config =3D scmi_smc_domain_sanitise_config, .domain_init =3D scmi_smc_domain_init, .domain_destroy =3D scmi_smc_domain_destroy, + .dom0_dt_handle_node =3D scmi_smc_dt_handle_node, }; =20 /* Initialize the SCMI layer based on SMCs and Device-tree */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 03 13:22:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 13:22:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108332.1458491 (Exim 4.92) (envelope-from ) id 1utnR4-0005Qn-Gg; Wed, 03 Sep 2025 13:22:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1108332.1458491; Wed, 03 Sep 2025 13: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 1utnR4-0005Qg-DT; Wed, 03 Sep 2025 13:22:02 +0000 Received: by outflank-mailman (input) for mailman id 1108332; Wed, 03 Sep 2025 13:22: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 1utnR3-0005Qa-Ce for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 13:22:01 +0000 Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c200::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f91cd96f-88c8-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 15:22:00 +0200 (CEST) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by DU5PR03MB10443.eurprd03.prod.outlook.com (2603:10a6:10:529::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Wed, 3 Sep 2025 13:21: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%6]) with mapi id 15.20.9052.014; Wed, 3 Sep 2025 13:21: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: f91cd96f-88c8-11f0-9d12-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p6C9IvrXtpTcbdflD/YZ0Sp2pPg/ieYGWTypzoMuRXyoJpFsJXAU8qMjX2uNEz/0rqGKbCywj46gJqX9rkIbb0EIy0HALJPSK0b40F+web6DVjsWzVdQsko5/DT0dMipHOhOLkapxACzSCLWnf1bORtjVWZSGEsyRlReeGQbD9hbQ7f37/tKE69ch2NgAovTjVhaX33Iq1yVLH9tO2Pj5zzg5XrV1I0/1RiocEEVkIePgS90DYuntYtLKgVODS1nb446EhmaHBSOtEQK918CACWrZ5QhK7LJ9KkdcJo5lacj68uaf61oBQu0hNAE8mqHPNZZexHdnv8CxsBtPcxpYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9lrAum2DSdJ9MFjBQbXIXwMzj+q605qbwMbIWbX/uB0=; b=LzDkKupKgaxGFxT3gC4PyoR5HOYAuq/no1jU1bKLjplOGuTwtcFIvCNcY06uE09GnAMVxTGqOjHTB5WHMr3pxUUWuZWxnf0uIP92KB2SvS3FcS/vUZLYT44gYRYRgI+tNsVmV2BSpKLpThppCKqB30UWzvTVJbB3RJ8soOATT1EVy/oPJFgZoGUlGinduAS0/CymzO44vQfoSDnnNoTPx1wIXY/Qyk5/gk/uXLN/tT4hRhay5I5ZLMVBhnH7bqUjdpqJnm/LbLX0ZOyi7pPpBUKuCoNmdcdi2BfWyLru1mnu4wr3Azn6qRv64IptpheyK2jRGQkWuI2uyYzOMQ2w/Q== 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=9lrAum2DSdJ9MFjBQbXIXwMzj+q605qbwMbIWbX/uB0=; b=DahgewtcIILmA9wewy3Ujr22yN3ggXh/SXcgcQtqlOu3LeJVu7YNMQ+h/1rIbxdcMuoGfY0IXxsvYEnrO0Fvg9KLjyrQaDcoXIo6HtGUTstF+OxVz6xbwNB5OZIxWJD8q+gSfFFDPPCwaZEwL/t7YPjGDo+ZSF7VueMqA8FVJsdnHWSKwEHfP3wqNogL7VinFAsiuy1IpzezRiT50wRLpCnF5EZ1dgs3n3SPdbabyUxquN2p3FeM5lenLgOiHWEmnWrkT5/HEZsGmnuoDJ7j3XtXKOx/fwL4ixDLur/sBjKyQu7eeongAqV7JqqUsTngIpscnCOtp1zGZTBB1fjzcA== 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: [PATCH v7 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support Thread-Topic: [PATCH v7 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent support Thread-Index: AQHcG0ebYanbJEa5qUWsxxb4FhV7urSAYeeAgAES+AA= Date: Wed, 3 Sep 2025 13:21:55 +0000 Message-ID: <64a9eb3f-ead2-4180-8356-7943868d5792@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: PAVPR03MB8946:EE_|DU5PR03MB10443:EE_ x-ms-office365-filtering-correlation-id: c7365386-d57d-4e35-0835-08ddeaecda5e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?VlB4NHlSWkF3YlBjb0xiYW9BSnAzL0hZMlYxZGZiWjZrREV2QTFxUmU5L3c1?= =?utf-8?B?eThGcFRKK2Joc2J3b1htczVsOXZReDZMYUs4UVlxNk1MdGJvSFg0djRwNlFo?= =?utf-8?B?V0hVS01EWTFmeDJYVWpSWXNFcHpJSE9XVTR4eWM5UU1jalN5WlljTXQ1WkFG?= =?utf-8?B?SkZXL2FsR2NLaVhTUi8zOEFJZHhFNzBYUlhIMGdtVnpON2pabXFIcFJoQjdC?= =?utf-8?B?RGdQVHkxaGZxQzBJaktQS1RqWkswOUUyVUJYbFVXNkhMK0sxL1ZOMXN3Qkt4?= =?utf-8?B?cnE4VGYzclY4ang2M3EreS8wQUZhYjNUaUlMeGY2bXZnVDNFYnlSd3ZUb2ZF?= =?utf-8?B?SWdtSlE5bkZpem56UkVhU0lqYmpTQ3FJa0twZFdDTTBqYm1OMGpCU3BiRDYr?= =?utf-8?B?d3RaMytlNngyRHpEZnIyakxvUWdBbkhSY3d5cExHMmdDa0YxV1lxTkkxRDJT?= =?utf-8?B?SDNxdnBYMnpMbjFVODJLMjNYRFlHN25wNTFQL2Irb211cnVXUlFvZW96ZWxt?= =?utf-8?B?bGxvVi8yem5ydHJlU05lM2o3UzlZRWRpVEpvcnZTb1IyWUdMS1VJU0ptWm5a?= =?utf-8?B?M2JvQlZaY3BzOEVaV3VOdGw4YkJ1Q0txT1Y2YkQwZFJVdnloanQzUkNiZkdn?= =?utf-8?B?b1BhNkxoeXhMZW1FMkQ4dkFwenNkUVhvZU1BeEt2VE9YYng4eVp4eW5xYXhh?= =?utf-8?B?TmxtdFhaeHpoOWQ1S1FwZVdxTUk0VUw2cEpOWDQ3aWR6RjlCMnBBRjlkTW9p?= =?utf-8?B?MDZIUXp6WnVxL1N2SG1lVFBJbTUyaVUzYkEwc3dTaXRSbXV6UWtsUlhqOVRU?= =?utf-8?B?eWpNUEN4TzNNMXpjUFF4TmxEVmVqZC8zMmhITmNqdjM4cmxicElMR1hwVnk4?= =?utf-8?B?Y0o0S1l3TWgrQ2Q0V2h1ZW5IeTYwVFdKZ1Nod2pVL0dIRWlNRWVsaEowZm03?= =?utf-8?B?eTdUeTJ3T0lId3hNQVhxVkx0SVg3UnhMU2dvREE3Yk1nWUIvdk5Ga2lGV2k2?= =?utf-8?B?cjRERVlicm1lRlFENHJ6bXpVTkcxaWs3elpjUWxkWFRVZ3pwM3E3T01qSlZk?= =?utf-8?B?RldxVEZWNlE4Y001Zy9PT1Q0b2YxUW5BVzA0ZERBVFBJSVlyUExxdUhIc3cw?= =?utf-8?B?Q1kwMFBmU21SRXViZ1M2d3FMSFcrUGNkM3FmQ202NnFjS0IwZExMN0dTaGg3?= =?utf-8?B?T3N4UGgrK1drSTZhbGZWSWIvUDFDSWIyZ0FvYWh4bkxDcFNmM1VJa2FENUxV?= =?utf-8?B?WlZ2QVBuNzJkQzdXTThhY0F6dS9uWGlBMndSNUNpbTNsNnE2VERmeHJGUVVi?= =?utf-8?B?MnhydTVXbjJHTEd2VVB5VytJSnlZK3ZKYmg4YWJ3bkhBVlZCK2Iwa2FBRU50?= =?utf-8?B?Wk1vZTZzUW5uTzAyVHRNWFBld3c0NmV2dmQ3SzE4MWV5K1krZHN0QitYWDU3?= =?utf-8?B?OTh6SWxFYzdVZjBKSHRqMVEraXBjT0RWbmt0ak83WGZxcnVKdmFuT2lhTnVX?= =?utf-8?B?TUQyL05FNTNkSytPNUhsRjRzNlNSeUI2cnIvYTNuMXhPaGZITktnV1lzMlVK?= =?utf-8?B?ZkFoelVlb3lWTCtXV0ZQNnV5T0Y0Wkg3cERIbVdRejZweEVkZWhSUU41OE9u?= =?utf-8?B?cS91YnpGbGNhT0VZVGI2UVJMejVMNGxXa2NEV04rQ1cxMzd6SzZLRVFzV3RH?= =?utf-8?B?OFFLVVpub3g1KzJkQTB2VFR3dXlidi9MN2FzUUc0OW8rb2dJYWlobXQ0VjJD?= =?utf-8?B?VnVXMS9WNVQ3eXQwRE9yTWw5ZWV0UHVuWlVmeDVPa1NpcXJPL2R4QSt2Tno1?= =?utf-8?B?S2MxbDd6WGZrNlBpN3hQYXdYUU1VUHcxMHBLRVArN2VtZXhDRHE0QllpWXlu?= =?utf-8?B?QS8rUXVpMFA3K1pDTTN2Yi8xYmtON1BOWTVsRHl5SmhUS3FoS20yYmdyWlJr?= =?utf-8?B?UGF6WkJTM2s1VXFuYk42bWxDa2VnUkFvam9yWW1jcWJZQzhmYnRNSTViVUl0?= =?utf-8?Q?LF/LEQ04q5P6wNlhrR2RJST4kV/2DU=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)(7416014)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UFE1dDJuYk1uQklKVGV4dlpURnV0bnNOOXZYR3N5aHZnM1pLNEtJcWFRbXk4?= =?utf-8?B?LzVGM2ZhWTU5VlRkRmU2UFhqSFRJYkFpbmZTZ2pOeFFKdENzRllHV3djTVhi?= =?utf-8?B?ZldqcFIyL25WMkJLVk0ybEExNlQ2Q05zaERjY2lXSW4ySU9VMTQ4YkZUNCtP?= =?utf-8?B?MUdudEIyTENkRXRFaWFiOWMwKzBpVWRPdXN2Vi9CZFBXRi9QNEpFeEN3cUUr?= =?utf-8?B?ZHF6NHlwK2wrNStxZjV0dGQxaDg2YmtxK3dqVVVIaW03NU5ZSjk2dUJINmQ5?= =?utf-8?B?MjA3c0pjZlhKL3lGZHhpUE5FZjJkREp5VUxLNEtCVHlrcE1oMy8vZE8rbGk1?= =?utf-8?B?MFZmM3h2NVNlWlZWcHNWcXR6dm5ha1lEUUF1SDU2dDRmWkJabnBCMzQyM0JQ?= =?utf-8?B?QkFCVWFmVDdZVXVRMjRpU3U0YzB0RmZZVXhBSzhOZlRXekViNURqREtSWEM1?= =?utf-8?B?c1oyNUVGZ1dxMFZvSXVMTjBVL0pHemtJSGxZbms4T0JGTlNwTDRwWEM2aE5u?= =?utf-8?B?U041Y1RYWUVaM29VZ0I0TlpzQWVuV3RxSGtNenJzelJ6TktlblRKekloSmZV?= =?utf-8?B?T1czOHJReWVlczQrRnpaejVzczhkMVNsRTlObVJLSHpFazIrbEFFUUYrTVRW?= =?utf-8?B?eW1QSm05RFNyV01WMnoyT2p2bWhGVTQ4RUNTeHNKWnRoQlQwNnJOUVd5aFBu?= =?utf-8?B?WkJIa1BuNVFjYjZPUHFza2F0cllwRmpRVXppZTJRbVlaUUp2Ui84ZEtJZ3Vj?= =?utf-8?B?M2laN1RIUlQ5cWtSYVRONy9pcU05c0RlMEIya1FaQVZYNDVzMGoxZ05SbXRT?= =?utf-8?B?R1U0SXdoWHdhMHM1Mis3MGlndTlPOW5kSjdIUnRqRlZCTGFVdjd2aC9TVFJT?= =?utf-8?B?aGxqWmh2N0ZJRnFYZ2hIb1dXSEprN0xUZ2MvWk5IMCtSVFlndUMydzJ5bi80?= =?utf-8?B?b0xkRWNRb1EvVXJrMW83TmRCTTM5K3RWNW9Id0JPRENVTFdoa09Ed3ZTKzU2?= =?utf-8?B?V1FaUVBJUzIzV0RkeGhZblRWTW5yakt6ekM5VXlka3IyZEdVa3h2NWlGaFZM?= =?utf-8?B?bEFuZ3ltSExkV3RVeFF3dG10SzB5cUdoeURBY3RSeWlGK3grWnFMdWEwNkhi?= =?utf-8?B?MXZzcUVtdTFhV1EwdGxQTGdMT3o4cjVHRitOUkJYd3QzQmxIQWdpeXpGaFJv?= =?utf-8?B?R2lIOG9wV0NIWHJTOVdOcVZMNzl2NnpRemJ4TVVoZmVXM3pMRjZVb2RpRERx?= =?utf-8?B?U1l6QmtqOXIxYVNUVEp1Y1Ayd01vdHhwZmJEOVVYUk5zU2s1OFpNeVhZQVJS?= =?utf-8?B?Y3RwN2VNV3BxY0hkUGFDUkxuMjBlTlI1c1c5OHAzL0lzT1l4K3BnZDYrNnBV?= =?utf-8?B?QTdpZWlFa3pvVkRQZ2dXeWtGa2c0Q1hmVjE3QmhCMXFnNVh5OG1kYWU1dmJ3?= =?utf-8?B?ekNjZS9sK0JXdXhkNnhUakRlS0hyL082bjZ5K3BJTHVrZTNUakZsNEJoSFBr?= =?utf-8?B?MzZyZ0RXRks5OXFNVC96NmtYOXR1NmxiRmhzVHMrSzdCaDdteTVwNkF5WU9Y?= =?utf-8?B?cDJLSi9VVGlwRkx5Y3IrT3RKL21WbGhYVHpYWnlGdjV0Sno2TkFOVEZHbXRj?= =?utf-8?B?Mm9sczczM3h2T2R3WkZncllDSTlrQ21hLy9PUlF2b3I0c0gzTXNSNVNHRzgx?= =?utf-8?B?OElycWVXN0k4eGNtTjVmUXBrWDVIMks5MG5PYjRXTWlSMkdxU0ROYkxQV3Ir?= =?utf-8?B?OFg1NkQ0SThld0JpRU5qZU9tWXl1cU5vVlRmcmMyZWgwY05OUUdTT2IvYXl0?= =?utf-8?B?OVZxOVFoSFcrQ1JRbVU0TU9Ob1Q3aFFjcis2VlY1eHBHNVJQYXlXcm45MXdT?= =?utf-8?B?UWQza0l4R21yQktKdVdqL24wRm5DZDM5TDlRY1MwaFNaZExKbVJ6dHY3WGQv?= =?utf-8?B?bkhPV2dvMEUyR2R4aWJiMkZWMUZGTHo0NTM5TlZNWi9tSU5XNHQ2QzZDcG9B?= =?utf-8?B?RkcwV24vTzh6ZGJ6RnFWQkEyMFlSR2Z2N1JPeUZrSGFqRUV6djZtcWppOW5o?= =?utf-8?B?TWtoa0FTc1NWUXVTOXhRRkZudHdUVk56TDZ6bWF2dVVtZG1mSW91a3F1MnlP?= =?utf-8?B?UWxaazdMa3JnejdMREtYMDRMT2lkbktuU0xFc0xtbFZqS1ZlWGgvTGM3cUk1?= =?utf-8?B?dkE9PQ==?= 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: c7365386-d57d-4e35-0835-08ddeaecda5e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 13:21:55.2692 (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: uRTUA+isEw3RgPtk9fHg7+qrw/yjmwwhFccWH+bVELCZPllGBbD0sgug3yLH1e/SGR1+5jDxNqEiHuan3fXhFo7guJ7/DjI5HEyGPuz4mi4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10443 SGkgU3RlZmFubywNClNvcnJ5IGZvciB0aGF0LiBJJ3ZlIHJlZ2VuZXJhdGVkIHt0eXBlcyxoZWxw ZXJzfS5nZW4uZ28gd2l0aG91dCB1bm5lZGVkDQpvcHRpb24gYW5kIHNlbnQgaW4gVjguDQoNCi0t DQpPbGVrc2lpDQoNCk9uIDAyLzA5LzIwMjUgMjM6NTcsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90 ZToNCj4gSSB3YXMgZ29pbmcgdG8gY29tbWl0IHRoaXMgc2VyaWVzIGJ1dCB0aGlzIHBhdGNoIGJy ZWFrcyBjb21waWxhdGlvbiBvbg0KPiB4ODY6DQo+DQo+IGh0dHBzOi8vZ2l0bGFiLmNvbS94ZW4t cHJvamVjdC9wZW9wbGUvc3N0YWJlbGxpbmkveGVuLy0vam9icy8xMTIyMzE1OTgzNg0KPg0K From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:03:10 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 14:03:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108364.1458505 (Exim 4.92) (envelope-from ) id 1uto4m-0002dz-KU; Wed, 03 Sep 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 1108364.1458505; Wed, 03 Sep 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 1uto4m-0002ds-HY; Wed, 03 Sep 2025 14:03:04 +0000 Received: by outflank-mailman (input) for mailman id 1108364; Wed, 03 Sep 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 1uto4l-0002dm-CA for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:03:03 +0000 Received: from mail180-6.suw31.mandrillapp.com (mail180-6.suw31.mandrillapp.com [198.2.180.6]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b314addd-88ce-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 16:03:00 +0200 (CEST) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-6.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4cH47k25TVz2K38gB for ; Wed, 3 Sep 2025 14:02:58 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 3136e414752a4831a9435bcdc14b04ae; Wed, 03 Sep 2025 14: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: b314addd-88ce-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1756908178; x=1757178178; bh=w02FzrMXrW2vpcm0Fd62ghUMs7LKHJeX3vUiusZSv4E=; 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=nfkcUW/hhG1Yck0tIBDLXv4Jvsqcmy+RWc2fdKPMisA0qk0FSI3IaBTjQXlyUqHai kSVk2LqeURrtqjmNcjpWx/d6MCYRYlYX+Bz1WEVWsBzIFxNrxAE5xEVlwFr0OdDzGt HDjkc5pHoKHvJvrBaXnmaNkK9A9tZj6dK4wFOa629kgFLujoRg1rW4VaddR66jroMG Sn7bYIYfIqbMaLljux21tnUyAJ0nVHBdUaprwGJ3S1kCEY13CGqQgp3Iq+WotmKDWn TmwZrZcy8mAPKF1XilKM0ZweTeXDi/NIFcvBStWcp9dbx9j1uYhKPEQGXN4HJzYDYh LvKSB8/Tk9YGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1756908178; x=1757168678; i=teddy.astie@vates.tech; bh=w02FzrMXrW2vpcm0Fd62ghUMs7LKHJeX3vUiusZSv4E=; 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=02/inHDZPaEL3NI3+BwHQmMGSwpyAz7RO/CdImXFay0KEXvUzPZL+eSgp/uxah010 Jgb5kJHxSCZWXzkoWJrFDRiV+KPvLAa8LQIAmGAf2KzTLM8XRRqgB6j+fViqtJbRTw m5AOK2gFtEhoNdGHXws03e2r+UTZcg6u0NSEXO76PUvofuroTHdm0ZX/QvQJPdSDFS aiC4q9V955Q03CVwswNGVRgYyO52SNLyJHRYoPQcpCyfOAGaZmKYoZw4MydBXOF2ip jja1eLH4u9odRDuVL/YhWNIfCi/sUM1QtnlqWtXRdE34z4EAXOWDIyHNrqevC8r5an oR4KOiGApIHwg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RESEND=20PATCH=20v2=202/3]=20hvmloader:=20Update=20to=20SMBIOS=202.6?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1756908177349 Message-Id: To: "Jan Beulich" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , xen-devel@lists.xenproject.org References: <57c674cc364d3b8f4c6d03533b9e2b45728d2c19.1756460430.git.teddy.astie@vates.tech> <0190dbe1-4583-49c1-86c1-9bcb57844315@suse.com> In-Reply-To: <0190dbe1-4583-49c1-86c1-9bcb57844315@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.3136e414752a4831a9435bcdc14b04ae?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250903:md Date: Wed, 03 Sep 2025 14:02:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 02/09/2025 =C3=A0 16:10, Jan Beulich a =C3=A9crit=C2=A0: > On 02.09.2025 15:24, Teddy Astie wrote: >> Le 02/09/2025 =C3=A0 14:38, Jan Beulich a =C3=A9crit=C2=A0: >>> On 29.08.2025 11:58, Teddy Astie wrote: >>>> @@ -505,7 +505,22 @@ smbios_type_1_init(void *start, const char *xen_v= ersion, >>>> p->version_str =3D 3; >>>> p->serial_number_str =3D 4; >>>> >>>> - memcpy(p->uuid, uuid, 16); >>>> + /* >>>> + * Xen toolstack uses big endian UUIDs, however GUIDs (which requ= irement >>>> + * is clarified by SMBIOS >=3D 2.6) has the first 3 components ap= pearing as >>>> + * being little endian and the rest as still being big endian. >>>> + */ >>> >>> The SMBIOS spec I'm looking at (2.7.1) doesn't mention the term GUID at= all >>> (except of course when discussing the EFI System Table entry). It's all= UUID >>> there. Here and in the description I think this needs expressing better= , to >>> not raise extra questions. >> >> Yes (this is also true for SMBIOS 3.9.0 spec). Not sure how to express >> that aside saying that UUID encoding differs between SMBIOS >> specification and Xen representation. > > Maybe > > /* > * Xen toolstack uses big endian UUIDs, whereas the UUIDs used by SM= BIOS, > * also known as GUIDs, have the first 3 components appearing in lit= tle > * endian (with this requirement clarified by SMBIOS >=3D 2.6). > */ > > ? > Sounds good to me. >>>> @@ -736,6 +751,22 @@ smbios_type_4_init( >>>> p->l2_cache_handle =3D 0xffff; /* No cache information structur= e provided. */ >>>> p->l3_cache_handle =3D 0xffff; /* No cache information structur= e provided. */ >>>> >>>> + /* >>>> + * We have a smbios type 4 table per vCPU (which is per socket), >>>> + * which means here that we have 1 socket per vCPU. >>>> + */ >>>> + p->core_count =3D p->core_enabled =3D p->thread_count =3D 1; >>> >>> Might we be better off keeping them all at 0 (unknown)? >> >> Making it Unknown would feel a bit weird, unless we only keep only one >> (instead of the number of vCPUs) of these table with core_count, >> core_enabled, thread_count as 0 (unknown) ? > > I don't see how unknown or not is related to how many structure instances > we surface. Your suggestion of using 1 in all three fields isn't quite > what we'd like to present to guests. Once we sort virtual topology in Xen= , > we may want to expose sane values here. Yet if we expose 1-s now, that > adjustment would need to happen in lock-step with the hypervisor changes. > Whereas when we expose "unknown" that can be done at a convenient later > time. > It's mostly regarding this snippet that I am not sure it is a good idea to expose "unknown" counts. for ( cpu_num =3D 1; cpu_num <=3D vcpus; cpu_num++ ) do_struct(smbios_type_4_init(p, cpu_num, cpu_manufacturer)); AFAIU, we have as much smbios type 4 tables as we have vCPUs, things would be very confusing if the CPU count of each exposed "socket" (per vcpu) is unknown. To me, either we should have 1 smbios type 4 table (i.e one socket) with unknown core count, or what we currently have, but with one core per "socket". >>>> + /* >>>> + * We set 64-bits, execute protection and enhanced virtualization= . >>>> + * We don't set Multi-Core (bit 3) because this individual proces= sor >>>> + * (as being a single vCPU) is only having one core. >>>> + * >>>> + * SMBIOS specification says that these bits don't state anything >>>> + * regarding the actual availability of such features. >>>> + */ >>>> + p->processor_characteristics =3D 0x64; >>> >>> Unless nested virt is enabled for the guest, I think we'd better avoid >>> setting the Enhanced Virtualization bit. >> >> I am not sure how to interpret the SMBIOS spec on this >> >> > Enhanced Virtualization indicates that the processor can execute >> > enhanced virtualization instructions. This bit does not indicate the >> > present state of this feature >> >> I see it as: Virtualization is available or can be enabled (with nested >> virtualization). >> Or as : We have virtualization related instructions. > > You want to view what we expose to the guest from the guest's perspective > on its own little world, I think. > Most softwares will expose it as-is as said in the SMBIOS specification; i.e "Enhanced Virtualization". Especially since it's not bound to hardware (here virtualized) capability. But yes, it would make more sense to only expose it when we have meaningful nested virtualization. >>>> --- a/tools/firmware/hvmloader/smbios_types.h >>>> +++ b/tools/firmware/hvmloader/smbios_types.h >>>> @@ -147,6 +147,11 @@ struct smbios_type_4 { >>>> uint8_t serial_number_str; >>>> uint8_t asset_tag_str; >>>> uint8_t part_number_str; >>>> + uint8_t core_count; >>>> + uint8_t core_enabled; >>>> + uint8_t thread_count; >>>> + uint16_t processor_characteristics; >>>> + uint16_t processor_family_2; >>>> } __attribute__ ((packed)); >>>> >>>> /* SMBIOS type 7 - Cache Information */ >>>> @@ -185,6 +190,9 @@ struct smbios_type_9 { >>>> uint16_t slot_id; >>>> uint8_t slot_characteristics_1; >>>> uint8_t slot_characteristics_2; >>>> + uint16_t sgn_base; >>>> + uint8_t bus_number_base; >>>> + uint8_t devfn_base; >>> >>> Where do the _base suffixes come from? Nothing like that is said in the >>> spec I'm looking at. Also "sgn" is imo too much of an abbreviation. >>> >> >> My version of the specification (3.9.0) says >> >> 0Dh 2.6+ Segment Group Number (Base) >> 0Fh 2.6+ Bus Number (Base) >> 10h 2.6+ Device/Function Number (Base) > > Without any clarification what "(Base)" means, afaics. > Not a lot is said, apart that there are also "Peer" devices (SMBIOS 3.2+) defined as (7.10.9 Peer Devices) > Because some slots can be partitioned into smaller electrical widths, > additional peer device Segment/Bus/Device/Function are defined. These > peer groups are defined in Table 52. The base device is the lowest > ordered Segment/Bus/Device/Function and is listed first (offsets > 0Dh-11h). Peer devices are listed in the peer grouping section. With Table 52 having the same layout as the segment/bus/... values we have for the "base" ones. >> Regarding sgn, maybe we can use `segment` instead ? > > Why not segment_group or seg_group (seeing how devfn also is an abbreviat= ion)? > And if we omit _number there and on devfn, it's hard to see why it should= n't > be just "bus" then as well. So overall uint16_t segment_group; uint8_t bus; uint8_t devfn; ? segment_group looks a bit off compared with the rest. We could use `seg` like we do in Xen PCI code, as it is about PCI segment here. > > 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 Wed Sep 03 14:25:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Sep 2025 14:25:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1108395.1458514 (Exim 4.92) (envelope-from ) id 1utoPs-0005at-VI; Wed, 03 Sep 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 1108395.1458514; Wed, 03 Sep 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 1utoPs-0005am-Si; Wed, 03 Sep 2025 14:24:52 +0000 Received: by outflank-mailman (input) for mailman id 1108395; Wed, 03 Sep 2025 14:24: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 1utoPr-0005aZ-R5 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:24:51 +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 c09d9f77-88d1-11f0-9d12-b5c5bf9af7f9; Wed, 03 Sep 2025 16:24:51 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b0431c12df3so504176966b.1 for ; Wed, 03 Sep 2025 07:24:51 -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-aff3dd9574fsm1220892866b.84.2025.09.03.07.24.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 07:24: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: c09d9f77-88d1-11f0-9d12-b5c5bf9af7f9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756909490; x=1757514290; 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=EK1tr560GZibtfYpnh3lYs+KzRlMKMjRzLwK3lrUH9M=; b=A5h/cFZcIcEIKZttD18gT+LRWEU/6YjuHn75ouGPJ+ASfDkoidP/5nMqhuqa4tgbLe 4rkUN0xLD6Cplqmj8R905Vz8j6tmRIVvZ5VL4qXIk2FD4+xIcKXfkH6FD4AWkGg+kJRJ 4Qsly9Fx0TIUd1Ha4lfeIQQdy3mg7y1wOBMaKaU5hhUEiwhkkmnhalI6SZmrGcXF1nXg 3v3QFguW5bZKOnwnNX/OjZg6lXiEvAb2PEGKmthj2zZjoLIn/qSVjz0efJiAWXN/6beL xEd8Uttcb1MqTellM9Jpiuwje51h0kBogFzsD5iGroYS4bKPfnToJAEKElXVHyD3+JJx mNAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756909490; x=1757514290; 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=EK1tr560GZibtfYpnh3lYs+KzRlMKMjRzLwK3lrUH9M=; b=cSjzg6LyVsZ5evuVFqvO5NmzpaQK2ihc0jNXFwD3TlML8hTSk52mWqBTYO/BoJQ7g2 +E+D1MqyHdZggQReRqdAfJdzhiGS/aHK5QraQX2EHixk/8hMQTLNZROTZjnKdOpon1jN QBSUFe9W9FhEMzruL3+fEMGNhtUubF5dEnLkEg2blpDeYacx/xO1nogninRmGTjWpqKF 7quN0jQtW4ydaoYQNHpC9ODCM/gbFIGB9goQ/T3OZYkaNGvfU3d/H9Zx3XQ+CGFpjqka w9wHvia8eR0nZIWyVZt3EJm1a8QON9pd0qv4dEpHHrJVye+aUjo7bYwvUeJYh14tNyjI kqhw== X-Forwarded-Encrypted: i=1; AJvYcCV1fL6h8galTnpNFAiRE+KPDXTCePuefcJJnJW+sD8kzNC1tKgSsyCkpe1lHdoiZVZnNugPsgRN6II=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx+lu8Wv14FBf+OnODWzNrvYNYaqHI5TisjH55cPZtrYuYJxT5d 5g6imCvyI3dE2vH4LfjDuxVjMe8A50zK1jjP3ayd0vXnlS3gyitFvjnX X-Gm-Gg: ASbGncs890IruGhJlO72d3xMAXX/9kbqlZuTfHcaxegQ2e5BeccEcYNHyCwlZwAwZCG WNafIz3GfZkI1dY/ksJ3Wh6qvVIUJirbBgNN9hOcyiXr6+qDHJlatBVFxqAKvJ0mOY9WOMFscgc +CbR4AXUdQRf3RI6aENziof+05dVgZ870bqcCSG/bBiwzi973MYRNl9qpaYfQuaTQW47eH76jqY PocLxkrPlf1qeU2HdC4gUiaE4ukYK4KHbVaTcl9sXb5xkC1oh5xcYcLb4qR3nrR9+wDSQAWWs+Y pM5NatSi6UxE/OOIyUaYC0QvdbbzfG/bxMuMNa7idk0vKaZi4xH3u6/Q2JETYTWCxFXO0qLAoEI yKQw7vHwkfGBvqAPr8P5/HU0J1Ig2BL/T+F5Xs6jgOlnEzc+FdQ34rQk4HjaiX1eK52EC8JAm X-Google-Smtp-Source: AGHT+IHCkHjGOwQE2uUPD1e1XmMl8oqi6+nJ0/09cwpd6jIlSsvZIO8b3glK9PqIc9eoYCyuuX+W2g== X-Received: by 2002:a17:907:7242:b0:b04:5734:3b76 with SMTP id a640c23a62f3a-b045734438emr583139966b.24.1756909490025; Wed, 03 Sep 2025 07:24:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------qRxS4DN05Ufa4MMRvrxRWqow" Message-ID: Date: Wed, 3 Sep 2025 16:24:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v2 1/3] xen: Define xen_domain_handle_t encoding and formatting To: Jan Beulich , Teddy Astie Cc: Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------qRxS4DN05Ufa4MMRvrxRWqow Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/1/25 5:55 PM, Jan Beulich wrote: > On 29.08.2025 11:58, Teddy Astie wrote: >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -11,6 +11,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) >> - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11 >> - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25 >> - Linux based device model stubdomains are now fully supported. >> + - Clarify guest UUIDs as being big-endian encoded. > Is something like this really in need of having a ChangeLog entry? Perhaps, you are right and there is no a lot of sense to have such item in ChangeLog. ~ Oleksii >> --- a/xen/include/public/xen.h >> +++ b/xen/include/public/xen.h >> @@ -973,6 +973,13 @@ typedef struct dom0_vga_console_info { >> #define xen_vga_console_info dom0_vga_console_info >> #define xen_vga_console_info_t dom0_vga_console_info_t >> >> +/* >> + * The domain handle is chosen by the toolstack, and intended to hold a UUID >> + * conforming to RFC 9562 (i.e. big endian). >> + * >> + * Certain cases (e.g. SMBios) transform it to a Microsoft GUID (little >> + * endian) for presentation to the guest. >> + */ >> typedef uint8_t xen_domain_handle_t[16]; >> >> __DEFINE_XEN_GUEST_HANDLE(uint8, uint8_t); --------------qRxS4DN05Ufa4MMRvrxRWqow Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 9/1/25 5:55 PM, Jan Beulich wrote:
On 29.08.2025 11:58, Teddy Astie wrote:

--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
  - Linux based device model stubdomains are now fully supported.
+ - Clarify guest UUIDs as being big-endian encoded.

Is something like this really in need of having a ChangeLog entry?
Perhaps, you are right and there is no a lot of sense to have such item in ChangeLog.

~ Oleksii

      

        
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -973,6 +973,13 @@ typedef struct dom0_vga_console_info {
 #define xen_vga_console_info dom0_vga_console_info
 #define xen_vga_console_info_t dom0_vga_console_info_t
 
+/*
+ * The domain handle is chosen by the toolstack, and intended to hold a UUID
+ * conforming to RFC 9562 (i.e. big endian).
+ *
+ * Certain cases (e.g. SMBios) transform it to a Microsoft GUID (little
+ * endian) for presentation to the guest.
+ */
 typedef uint8_t xen_domain_handle_t[16];
 
 __DEFINE_XEN_GUEST_HANDLE(uint8,  uint8_t);


      

      

    

  


--------------qRxS4DN05Ufa4MMRvrxRWqow--


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:29:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:29:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108407.1458531 (Exim 4.92)
	(envelope-from )
	id 1utoUb-0006Hp-UI; Wed, 03 Sep 2025 14:29:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108407.1458531; Wed, 03 Sep 2025 14:29: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 1utoUb-0006HT-QY; Wed, 03 Sep 2025 14:29:45 +0000
Received: by outflank-mailman (input) for mailman id 1108407;
 Wed, 03 Sep 2025 14:29: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 1utoUb-0006B7-65
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:29:45 +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 6ee5d9c0-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:29:43 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by PAXPR03MB8100.eurprd03.prod.outlook.com (2603:10a6:102:223::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:29:41 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:29: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: 6ee5d9c0-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BYlW1b1q5FynTX2j9DVRmO8F3XB6vurM5iRhtZ/e9nkRTcVu2TzRSJs2eKwmMEbbvOosBJjfh39I2ZTWiDy2IHl+SkkU5c5pQpqA4smx2KvZQ1dYQLkBskX5d/ZBKNGfXKp7KwlmCOd1qfqqOZl/4wMs5NncvlU5nDeKQX1Xnv55zMEb/zjhou582CeIvYm6fXUHg3EUuFk/z1UnsYUq37F4vnjD41Rzt8Dkvr7fflDFlrOIu908+B299/K2qDilZro69c+h5wZnTRv66Rzx/Fb+CT6K7g+6trEyYcFVOkGQBQzaU+nLYfgzyMLRwfIYauhVF6qKgRByHH/ApWIYWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hS4UG6WanopHDmgibA/uVOw02shcO9ZrNjrAVUPDPy8=;
 b=DDIEdfNBooJLM3v8LHBgBqN4gFBPP1aC1sgQlh8K7tjGlNEbQ4cfa/NfDcQ7DfQ7XJvU01ybCard2QRPymvgP95dzrxFVBLSQW+/hRzVtiXosUUfdyqC/GJQ3V0xlAUrnUMtaosXP7mibbRpoCj+yNzuUeAYK8dHXMNZpmxdEYPPs+HUEHXq0MfcZ5OWDln4u/uUFPUqJwCV8+L2YdYvT+9GC6fR7Q1d4QAJDiyWUTI2Kd6L2Ttdex4o+Q/9q0v8dOz+2LeJfgP5iWLe9rPOotb5gzPRy2HyPPj/gyyJMEgoNTuqamVfGH1a9ZoWdsEh/tSPw+5ysQ/fcqE6x64iJg==
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=hS4UG6WanopHDmgibA/uVOw02shcO9ZrNjrAVUPDPy8=;
 b=dyAUiNtOKXqyqJLLpWig9g3/MQs8ypn3LLo/QjXbQH+N0UEUR7aCrH6dK65C1km32m1SDtAYmAvfB9LjqH4+9tDfZ7/X0p40qZRdKSeAC7IAtnqtKdFK3EltpcXZwFibOndrgqcweJJI908txPAaUJ3keBuDQW5e64kQydSzoAgWyHwH5QTMXQk5u7td6t1PHD2FAgLfNoD8J3T6Yt74xXSQAHOiVbMS3j75zXDsimttKBuEOt8gTv5oZHCfehGo3v3eEvPINP2KP1oORcsSecvKUwxroQHGddtX8vMKRCOonW88Ts5k+MVnLTUaLFhMHa1LXBnTwvxkdhOCiys3DA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko , Julien Grall
	
Subject: [PATCH v6 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for
 common operations
Thread-Topic: [PATCH v6 01/12] xen/arm: gicv3: refactor obtaining GIC
 addresses for common operations
Thread-Index: AQHcHN8uHGh8g8YI3EaFdLqSjksbgw==
Date: Wed, 3 Sep 2025 14:29:40 +0000
Message-ID:
 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|PAXPR03MB8100:EE_
x-ms-office365-filtering-correlation-id: ab2fd45a-77b5-41b4-d465-08ddeaf65144
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?c1rWeDZFevKrSE4MQm8sh9TdTQA29gdFo/YTmLA8PwBguoUS1PkfWQCOFE?=
 =?iso-8859-1?Q?kjfdeeKzRhGEjcH5gPh2Y82EGi4YohlzFUW1vzh9Tl/odFKQ+l34oC1sDo?=
 =?iso-8859-1?Q?ccYGuyNHQOK5OUnxQKNFIbP/iW54SRQFSRGQ2Gh7jbHbbx5poTFclU8Jqe?=
 =?iso-8859-1?Q?eJUD0Tv3gdkJlNUF9UdWqCYNPWLOdyvf61v1BexX5tHEJw6Cc3h9+l0VYK?=
 =?iso-8859-1?Q?Z0WDn6C6m4qopdqes8uQuOrb5lYJoStxyUYW/cN97pUEIxtTawTgGOrZ1o?=
 =?iso-8859-1?Q?n5z3V8dLKB5+5t441wQ53sFDGwOpqUBZBk9qo9ecaEqdoUODTj94S2onsY?=
 =?iso-8859-1?Q?SpoktfQUHWRYYvfK5qp17bpWh3kioKY1QgrQVSvKTnoBCnPO1LA/eNmrlE?=
 =?iso-8859-1?Q?s3Xd93BDOKz9N4kt6sB36nWWFzeQnSe+YCyaa8A8DN1A+0YnyidLEdxviI?=
 =?iso-8859-1?Q?1Me3eyMHRNonYmq5pJqbXEMY1oecnCi73iGd6JNRDK+Va9NQzlqki5Q8gk?=
 =?iso-8859-1?Q?FVETg5NTwReMiPtSFVgxYuk5TMppFVjZltIoTY44JhssChiK8UMNgE0/ns?=
 =?iso-8859-1?Q?rFYlVnSoPcE0eAierP+xKHEi6DErGR0Uef/n6hmiD0b4z8YVnoxZvPspFP?=
 =?iso-8859-1?Q?kcyMPQQHblSQg+oJHUyI5Wyk66XfcNb+8Mw/S0H/wO1WtktkILAzuUlHuG?=
 =?iso-8859-1?Q?NiGzO0lKrOwqkJMNOd2nlwWVD0q68e7Aeteo62TefRyuRIxeDNuZP9pZAd?=
 =?iso-8859-1?Q?bls/Hwm4eTcFA160xRfut/P53wKtS2MSl40xBdgbWaIcknNgvrbHdWd+eW?=
 =?iso-8859-1?Q?l8eCV5WUDz/5AVB+21CgzPMLRX+9zZE9Zb+ntWRC0xDOvPct6dY9wwSouc?=
 =?iso-8859-1?Q?MVWX/if8CWp2jxLH95fU1KI3bEZkprYiR7Lwv2CnAnIt6QUEcY0ET+VVaj?=
 =?iso-8859-1?Q?fqOmviSa9scvq3Ptq0rU8LWiucG12og9peXa7KJ06tX799BKiKfc98jZ1j?=
 =?iso-8859-1?Q?MIXWAkeyDQc0xc7MXSjUFrTB9IbOv5pIE3ysbtfTOO9AOGBmzDu1GpBf6i?=
 =?iso-8859-1?Q?8DDOU5I++mBqHVzCdCXe9b2652XEoHhnWU0pZ4Y06Ebl41cQca83XNfss3?=
 =?iso-8859-1?Q?8X1yfhv4M4UO6KrK3K1xcfVCsuuewzbWyN6v1bRlEQ55vLCGVGIx6ceLgT?=
 =?iso-8859-1?Q?6Nu40Z8GEp2O+mNNVnKNiZiC0EkgVKFLoKXRe8URhwKcnpHLTPpIRq3kmp?=
 =?iso-8859-1?Q?Pq6Hku1wOU/nrt9xv5j9IohEJBFwwPSyQlqPWTcPy5q9DDNhpYhrX2XVqf?=
 =?iso-8859-1?Q?J1un/XkDqdz97xPiEiWYO6p6M2sdIr2L9zKcomDI01SSwVAgSAPEpJ5xDi?=
 =?iso-8859-1?Q?tVBj/biFxfv3FcNsMmyWAh4ui/kc/xgD+qtJIi4iLWmf6mW/2RMfPspohX?=
 =?iso-8859-1?Q?43uvkUwgvY7rvDXuAyUz6UGLSrFMe+bGR+yCGgigKcU0/jEbV+BJ+7IzlO?=
 =?iso-8859-1?Q?9jHhoXtgbKx5osi7PDkI5d/fMwi3ajMxPnbPZd9hMXdQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?9ImoXJ2piG7NGAefgWOuQNFoxflMAnp/kLf+iMK1i8UKNLcFGlsU001tlV?=
 =?iso-8859-1?Q?HKsJ2LFiUVmdtxqcPBg6PePG4KTT3yi9lb5Uz3NTudVZxVmx3T0fQaJLN2?=
 =?iso-8859-1?Q?oyQH9EZt0aisACjvAsWZ/Ez8Z+ZvZr1pjDqGiEE09F2Fsn5Uh6GodS4oSL?=
 =?iso-8859-1?Q?Nx7QOIhXl6QNII1fRz8bueUZD/A830juiqawCYBr+gLqhdITpnP0MClb/a?=
 =?iso-8859-1?Q?jIjrWYfm+34oEw1i0/4PI+NCIm61J2VbshC7yqBGbH5bVM1GxUa7bGQgrB?=
 =?iso-8859-1?Q?4uzL8iJVAPFK9/3RxGZGl3LPuUAgCU33RJkjJedNbNM6htPUP+6GQXrB5k?=
 =?iso-8859-1?Q?tNa0jtAzC8L+jBAFRTXNY7EvnHWK90iQEj8exrSW/fhuv9ypIfUM2PqUQI?=
 =?iso-8859-1?Q?gRPW6Te7HlxxLGjEqk6zPYKzW/Gk9mOahJT3oDJSy4IVP33HZj7Ogfnoc8?=
 =?iso-8859-1?Q?RQ8wAWCADA7CR+v2GNpAum8tYKYyOyNNGds3OlAnWw7KHhuuM0nfdV9WiE?=
 =?iso-8859-1?Q?7M1PE4oTGM6jSXnJhwD9JBlp0WGNB23j9iUoTHgR2cEydSXid9Ca9Wihsl?=
 =?iso-8859-1?Q?Q6rqbNq2l/FKFJIbQcDZpLwu4BQh6IjR5B6zZJn2QPLdvShTDDLwSowNcy?=
 =?iso-8859-1?Q?zgYq/Zexvbmy9e1tKcX0LVmvdPpT2uwce3yfIin33wHmqPyYw8I2g9BVHt?=
 =?iso-8859-1?Q?B7Tv9hw2nmFPin14fBOtKUB09IHKCD2y6woSgliYfUEUHPz4ULP3sHbKHx?=
 =?iso-8859-1?Q?XuPSW11pLa/8VcxqVHWoQehJenQlONGEgxx+Y84gXaM2MlZ/+Ly+6Q+RxE?=
 =?iso-8859-1?Q?SSS1XdNLx6T2ua0XjsVFkjnkwrS8+wmxNIx9LgBK2yQAMBRjNKPchxGCX5?=
 =?iso-8859-1?Q?kkKPkGVuMiq/SIjFfLwlJzzIQ8rLIW1k+HhXW2HszeNCXnuJXvctcE3IdE?=
 =?iso-8859-1?Q?0sTAvom8iA6G7PCH3N19p47V866Aqnm1dj6U0Y8ReVR6qPkjj4xD24MB29?=
 =?iso-8859-1?Q?fh9+2Pggm0U+bSuwJFFJ3qD85Ia9X7tTN+qvYMj07kfCT7d3Qgm3KM5fM3?=
 =?iso-8859-1?Q?51K+R8u8630cfc4S7PJ0S2D1v57sE/g0GUfCbSP377y6MELxyCffEOH0sd?=
 =?iso-8859-1?Q?cqxO6VOvJpOI4quMf4Z7kfJBl0ioQSep+OmEoSCKMEwa6xhI1WCJuTu+Cr?=
 =?iso-8859-1?Q?t5V7JsrALhFyTOuz/p74gVyZP2v+6bnAFg7dfll/ZMkwEfN7ySOGvRBq42?=
 =?iso-8859-1?Q?1uzwMxZlBH+mJoqI7ZDrVmY4/hO5SNqcvt5miKZ7vjje8oqoWTh78YRTQp?=
 =?iso-8859-1?Q?ZQY1AgLzMnku8elbRHGcKD3o9tEOfZzGO+FlCFixBTKcQc60ARz76HlMiU?=
 =?iso-8859-1?Q?cJcYgG9mP3B1imspT8OREr2HgdIIHbfd+4RYawhydwqGIE7QliF5c+23zr?=
 =?iso-8859-1?Q?9H5mztQlkRtBDO81WHQrFlGk5UuGJJJ52IoY57uY+9Yp8Agn5CjQWnkrZq?=
 =?iso-8859-1?Q?HSPIbzHLktoyckdqH+LBrpegLxwewkzNGOLo+ZETfZDv7aU66DuSytFdyv?=
 =?iso-8859-1?Q?SCneGCSpz6E571lte4pJeXMJLyIMrkcwOfIfymh9scjhHebCJQyzy4mtNm?=
 =?iso-8859-1?Q?PJZqwJVWIbqKiVKpSnQN15HJjIAuO5CYg2uReGE0H73gJ30wvyW62NaSko?=
 =?iso-8859-1?Q?K7ghHxzbftXYVhFSK2k=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab2fd45a-77b5-41b4-d465-08ddeaf65144
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:29:40.2731
 (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: vrbi2t/psNxFATlPrriVIjXVFb1bV+LDsoRCfsKKXOYvPDIl8x3QWKa7KO+sU69LrfJMArhmQ3KvIVO8OSR3dZ62q4LpC09W4PVhJtgR7Po=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB8100

Currently, many common functions perform the same operations to calculate
GIC register addresses. This patch consolidates the similar code into
a separate helper function to improve maintainability and reduce duplicatio=
n.
This refactoring also simplifies the implementation of eSPI support in futu=
re
changes.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 

---
Changes in V6:
- no functional changes, just fixing minor nit: changed u32 to uint32_t
  in get_addr_by_offset()
- added reviewed-by from Oleksandr Tyshchenko

Changes in V5:
- fixed a minor nit: changed %d to %u in the warning message because the
  IRQ number cannot be less than zero
- added acked-by from Julien Grall

Changes in V4:
- no changes

Changes in V3:
- changed panic() in get_addr_by_offset() to printing warning and
  ASSERT_UNREACHABLE()
- added verification of return pointer from get_addr_by_offset() in the
  callers
- moved invocation of get_addr_by_offset() from spinlock guards, since
  it is not necessarry
- added RB from Volodymyr Babchuk

Changes in V2:
- no changes
---
 xen/arch/arm/gic-v3.c          | 114 +++++++++++++++++++++++----------
 xen/arch/arm/include/asm/irq.h |   1 +
 2 files changed, 81 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index cd3e1acf79..a1e302fea2 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -445,17 +445,67 @@ static void gicv3_dump_state(const struct vcpu *v)
     }
 }
=20
+static void __iomem *get_addr_by_offset(struct irq_desc *irqd, uint32_t of=
fset)
+{
+    switch ( irqd->irq )
+    {
+    case 0 ... (NR_GIC_LOCAL_IRQS - 1):
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+        case GICD_ICENABLER:
+        case GICD_ISPENDR:
+        case GICD_ICPENDR:
+        case GICD_ISACTIVER:
+        case GICD_ICACTIVER:
+            return (GICD_RDIST_SGI_BASE + offset);
+        case GICD_ICFGR:
+            return (GICD_RDIST_SGI_BASE + GICR_ICFGR1);
+        case GICD_IPRIORITYR:
+            return (GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + irqd->irq);
+        default:
+            break;
+        }
+    case NR_GIC_LOCAL_IRQS ... SPI_MAX_INTID:
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+        case GICD_ICENABLER:
+        case GICD_ISPENDR:
+        case GICD_ICPENDR:
+        case GICD_ISACTIVER:
+        case GICD_ICACTIVER:
+            return (GICD + offset + (irqd->irq / 32) * 4);
+        case GICD_ICFGR:
+            return (GICD + GICD_ICFGR + (irqd->irq / 16) * 4);
+        case GICD_IROUTER:
+            return (GICD + GICD_IROUTER + irqd->irq * 8);
+        case GICD_IPRIORITYR:
+            return (GICD + GICD_IPRIORITYR + irqd->irq);
+        default:
+            break;
+        }
+    default:
+        break;
+    }
+
+    /* Something went wrong, we shouldn't be able to reach here */
+    printk(XENLOG_WARNING "GICv3: WARNING: Invalid offset 0x%x for IRQ#%u"=
,
+           offset, irqd->irq);
+    ASSERT_UNREACHABLE();
+
+    return NULL;
+}
+
 static void gicv3_poke_irq(struct irq_desc *irqd, u32 offset, bool wait_fo=
r_rwp)
 {
     u32 mask =3D 1U << (irqd->irq % 32);
-    void __iomem *base;
+    void __iomem *addr =3D get_addr_by_offset(irqd, offset);
=20
-    if ( irqd->irq < NR_GIC_LOCAL_IRQS )
-        base =3D GICD_RDIST_SGI_BASE;
-    else
-        base =3D GICD;
+    if ( addr =3D=3D NULL )
+        return;
=20
-    writel_relaxed(mask, base + offset + (irqd->irq / 32) * 4);
+    writel_relaxed(mask, addr);
=20
     if ( wait_for_rwp )
         gicv3_wait_for_rwp(irqd->irq);
@@ -463,15 +513,12 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32=
 offset, bool wait_for_rwp)
=20
 static bool gicv3_peek_irq(struct irq_desc *irqd, u32 offset)
 {
-    void __iomem *base;
-    unsigned int irq =3D irqd->irq;
+    void __iomem *addr =3D get_addr_by_offset(irqd, offset);
=20
-    if ( irq >=3D NR_GIC_LOCAL_IRQS)
-        base =3D GICD + (irq / 32) * 4;
-    else
-        base =3D GICD_RDIST_SGI_BASE;
+    if ( addr =3D=3D NULL )
+        return false;
=20
-    return !!(readl(base + offset) & (1U << (irq % 32)));
+    return !!(readl(addr) & (1U << (irqd->irq % 32)));
 }
=20
 static void gicv3_unmask_irq(struct irq_desc *irqd)
@@ -558,30 +605,28 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cp=
u)
 static void gicv3_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
     uint32_t cfg, actual, edgebit;
-    void __iomem *base;
-    unsigned int irq =3D desc->irq;
+    void __iomem *addr;
=20
     /* SGI's are always edge-triggered not need to call GICD_ICFGR0 */
-    ASSERT(irq >=3D NR_GIC_SGI);
+    ASSERT(desc->irq >=3D NR_GIC_SGI);
=20
-    spin_lock(&gicv3.lock);
+    addr =3D get_addr_by_offset(desc, GICD_ICFGR);
+    if ( addr =3D=3D NULL )
+        return;
=20
-    if ( irq >=3D NR_GIC_LOCAL_IRQS)
-        base =3D GICD + GICD_ICFGR + (irq / 16) * 4;
-    else
-        base =3D GICD_RDIST_SGI_BASE + GICR_ICFGR1;
+    spin_lock(&gicv3.lock);
=20
-    cfg =3D readl_relaxed(base);
+    cfg =3D readl_relaxed(addr);
=20
-    edgebit =3D 2u << (2 * (irq % 16));
+    edgebit =3D 2u << (2 * (desc->irq % 16));
     if ( type & IRQ_TYPE_LEVEL_MASK )
         cfg &=3D ~edgebit;
     else if ( type & IRQ_TYPE_EDGE_BOTH )
         cfg |=3D edgebit;
=20
-    writel_relaxed(cfg, base);
+    writel_relaxed(cfg, addr);
=20
-    actual =3D readl_relaxed(base);
+    actual =3D readl_relaxed(addr);
     if ( ( cfg & edgebit ) ^ ( actual & edgebit ) )
     {
         printk(XENLOG_WARNING "GICv3: WARNING: "
@@ -600,16 +645,13 @@ static void gicv3_set_irq_type(struct irq_desc *desc,=
 unsigned int type)
 static void gicv3_set_irq_priority(struct irq_desc *desc,
                                    unsigned int priority)
 {
-    unsigned int irq =3D desc->irq;
+    void __iomem *addr =3D get_addr_by_offset(desc, GICD_IPRIORITYR);
=20
-    spin_lock(&gicv3.lock);
-
-    /* Set priority */
-    if ( irq < NR_GIC_LOCAL_IRQS )
-        writeb_relaxed(priority, GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + =
irq);
-    else
-        writeb_relaxed(priority, GICD + GICD_IPRIORITYR + irq);
+    if ( addr =3D=3D NULL )
+        return;
=20
+    spin_lock(&gicv3.lock);
+    writeb_relaxed(priority, addr);
     spin_unlock(&gicv3.lock);
 }
=20
@@ -1273,6 +1315,10 @@ static void gicv3_irq_set_affinity(struct irq_desc *=
desc, const cpumask_t *mask)
 {
     unsigned int cpu;
     uint64_t affinity;
+    void __iomem *addr =3D get_addr_by_offset(desc, GICD_IROUTER);
+
+    if ( addr =3D=3D NULL )
+        return;
=20
     ASSERT(!cpumask_empty(mask));
=20
@@ -1284,7 +1330,7 @@ static void gicv3_irq_set_affinity(struct irq_desc *d=
esc, const cpumask_t *mask)
     affinity &=3D ~GICD_IROUTER_SPI_MODE_ANY;
=20
     if ( desc->irq >=3D NR_GIC_LOCAL_IRQS )
-        writeq_relaxed_non_atomic(affinity, (GICD + GICD_IROUTER + desc->i=
rq * 8));
+        writeq_relaxed_non_atomic(affinity, addr);
=20
     spin_unlock(&gicv3.lock);
 }
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index fce7e42a33..5bc6475eb4 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -29,6 +29,7 @@ struct arch_irq_desc {
  */
 #define NR_IRQS		1024
=20
+#define SPI_MAX_INTID   1019
 #define LPI_OFFSET      8192
=20
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case.=
 */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:29:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:29:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108406.1458525 (Exim 4.92)
	(envelope-from )
	id 1utoUb-0006BP-Gt; Wed, 03 Sep 2025 14:29:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108406.1458525; Wed, 03 Sep 2025 14:29: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 1utoUb-0006BH-Dm; Wed, 03 Sep 2025 14:29:45 +0000
Received: by outflank-mailman (input) for mailman id 1108406;
 Wed, 03 Sep 2025 14:29: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 1utoUZ-0006B7-QB
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:29:43 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6dba6b6d-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:29:41 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by PAXPR03MB8100.eurprd03.prod.outlook.com (2603:10a6:102:223::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:29:38 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:29: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: 6dba6b6d-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dQNIum35jqqKaQvB6Erm4c4ezgnzF4o948lL5pHLAFy4q1XupOWxM1yh+yjwtYpPT3B7HXy6bait2cnvz2pRlNT80LS0ZBqI2cvfBZgW+bQj+0rO4ilwErvRg8e7t1tojSCWEURGoXdFuV199ew4yumKsFlQxCLxthOG5WUY6qqaC5pM5PjssTAbGVLIBD++wnCEtE0+UDzpWAJ8hM74W3sPyR3Yb/qGPCFHbcvND0buF7HTcSGRD+1UxInZcNO+FEpLtsQUppmg9wkU4NvrgM6eXr5VYT23i7Eqrr1eGhc8epkMIZjQTVJXsF5YeOwqSGd0grGKakcMgXN7n5y/Ew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6dq8bN6fyd5wtKxAni2CdiTYqqV4PATP9Xebh3pKhHQ=;
 b=ASpgk1WANwS88x9hlioYH6v6ZLDR8Mugr8AwGvXijf7JczgIkFA7CXK/F9cSip8EtHB6I38ikAz0pcDsw2Mj/YqLr7miETsrLehM7kIcVbQ1rdmLCn/yia+7NLzVAkHmk/EjRilqHJzaS2eSqzYI/0yVWuK3Yi6lz1gC9MN9flUyyEbkR/AEw3GWnTKa3zUyUqcwLdpvU0KAGUNaDshFAmCbsJ62kfwqFEfM6w8rvpeZpGkU/ivi8jqURVbzCajlgzQh6EdPrgS2m+eTvM3VyGr+B8CQ2EfwhgHi/AfKaLOMj1Bb16SLQKqYqmY1VXSrzEm5HZ4uggUHwOYSCXmxkg==
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=6dq8bN6fyd5wtKxAni2CdiTYqqV4PATP9Xebh3pKhHQ=;
 b=n0xE1syITlmOLlKoGEugZKJDV1v1GGWP5DlThZCvV+mxEnWlDN1Y3NzstVlcYL861iNtvp/T9c3DUvenGBqITSGJR+AydDkXKI93uTiAkZlxnlN1ms9gn3tDD/AoDI6Rsc2Cldg9I7IHT+O0skavLNRqhuns1dFmmDHkPKAmrlf0tIz9ohbiKfjkXNqUvS5bwvwkQUt6/oZ2GYswbh9G7BJJ5ySobSamF10GYRz+WdNRYPzWhEQT85cFLpEylGC5qGHGqEKtonnOazbzw1joRNW6c3gSrfO/q21iPvSVxZlD+ojOwjqSvT/IYgoYAMSlQk+e8pGd4MKLeFoL286zwg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Anthony PERARD ,
	Oleksii Kurochko , Community Manager
	
Subject: [PATCH v6 00/12] Introduce eSPI support
Thread-Topic: [PATCH v6 00/12] Introduce eSPI support
Thread-Index: AQHcHN8t1cvqj6mC5Uuo6UPszu4Kyg==
Date: Wed, 3 Sep 2025 14:29:37 +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: GV2PR03MB8678:EE_|PAXPR03MB8100:EE_
x-ms-office365-filtering-correlation-id: 89baac5f-af81-40a6-8bcd-08ddeaf64fe1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?q8i6Mkw7knnlQD3H7LmIjGOLpOs6nwsqcsPmLUJnj656QDL0pio5bQBqrq?=
 =?iso-8859-1?Q?rVs/uEikGAWgDhpG1qmf71L/no7Gt4iGv+3h91FAyXRbXqY3yVYtoYtwjr?=
 =?iso-8859-1?Q?OlzFXbWHLb0Z1YDX6C2Fvlj/HwoTqOavNfLbciTlBMmF810tP/y//UvSq6?=
 =?iso-8859-1?Q?slcDG3eBHrrTpMUir7oSzGJj5uFxNC4lQ+qd7x6mqwsv2Xxdj3iWqcUMBg?=
 =?iso-8859-1?Q?uG3nAyIGh5u8E5RtIwnY4pW/Ne3kMuRAS5H3NCybOzvXmuc79EgKxvm2vX?=
 =?iso-8859-1?Q?tNbaiHFY5q5DYAEzt8F2u4isCXP9SE88djkP5lvQeohqmWrHZ/LShtsQkc?=
 =?iso-8859-1?Q?PCc+wm0qU28jk6ObWE24h0lus6ojiTkWw4R4Qnco7TiU2kgm4VADx/6E9T?=
 =?iso-8859-1?Q?rlnFKfkziz5El9rFwFXwnRNXJFhYp3ckEinrxcNxU1+E4770QRWsH0y/1+?=
 =?iso-8859-1?Q?RxILMMdBXCNCP+JXQRrO5zRY+v3g0a9KOQ+4s3PH2MAp8Hq71TCo7rF5tU?=
 =?iso-8859-1?Q?DRglG/tZTsUSMh1bV97siVLXk8IPXhhU5xWhmZfSIzZVMa0PoVqCHblcKn?=
 =?iso-8859-1?Q?s/zmck5wRWK3ktc7b8bdV3/cbgaMiH6dgS5QKH91Z4TfCzlbw+vQedJqZF?=
 =?iso-8859-1?Q?EFDOtZowQBkPeov5zIMbif0cNSwr+6qhDf+GICuB5Qc4Pg9AZGrgY6qSeP?=
 =?iso-8859-1?Q?WS1xwLOwirgSDTpOamC/m7wpQ7w/WQjFBQWTt8u9hEkpIWrZm13H9v0sU4?=
 =?iso-8859-1?Q?ELZHITKnOgmAXGZ6nYT2gE6OtSfSObJoKXOiPTBfdhCG0Q/aowsjd04gBF?=
 =?iso-8859-1?Q?vemDBCcs/EhUZuJa0tn5CsPoEz2QmJHe5U2PUGW6BrA7rLghZO1Lrm2QPG?=
 =?iso-8859-1?Q?eEt2jlaZFlqPT68gOFbYwyXXcLVoGnvlIVIz0CcYd7zBPlITIk4040LmYk?=
 =?iso-8859-1?Q?zzmTjbyGI7/d+bFC+TNsIF/5xmSE83ejxCIRf4NbYV0B1O80E1HWi5aoZg?=
 =?iso-8859-1?Q?5zU2D/YMBFDXS2VB05oPGEPKUUqq9wA1Be/+IiSq18vTEKvi3skk5mjN1X?=
 =?iso-8859-1?Q?FokQdQG9KWPsxsVFttB3WdfTk0EAEEeokrJ25PPWt/BGqu4fitjRYEuUra?=
 =?iso-8859-1?Q?SiOYMldA8S1CVXlx04RYR8jp7cQtn3XDttk+h6CV4jnddT+POpLDyRjoRC?=
 =?iso-8859-1?Q?9mZVJLhKv2IYWNqs1ph4iB6oC3LfEPDr7/RM507D3zdJa0EOQE8wUCcSed?=
 =?iso-8859-1?Q?TAf3bMbOE3b4lvlk5pDHh0QmnN6miWGzXxMydcMYAyVAHw8MZAAPmc/+K5?=
 =?iso-8859-1?Q?yaMLRwz/caEFHr7vMoRttQTLtiGdpbBWO48PjZjd9+CzZqaXyHW1n5Va+N?=
 =?iso-8859-1?Q?TPBON/1WYU/bzUKsQhw3zHznbIVdLWm+2sPN1KMLXrAh103HqqlG2Uw/ne?=
 =?iso-8859-1?Q?HqNgCnsG7R+/v48yZJnMB1M7tmvOK8HOIUdtCMwwJsGxsBTq5+XwjkKyua?=
 =?iso-8859-1?Q?s=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?vAHbqHGsihCvc2ceeGKUsfnV0DkXLaSXr/W/4eiafwbrQyXVvQ12i+W+xy?=
 =?iso-8859-1?Q?QDkOFQ0gOIYCLjfp4H3Wktw3WnpFRnPyMuf5w41rDBfdN+f8Ld8BWFrRwt?=
 =?iso-8859-1?Q?AjlFtREMCBEmhQifB3p5twKEyeR12AXgzs5yv+Q8aR+yJ70HMdodkg9lOK?=
 =?iso-8859-1?Q?/q9RoNKy76eKAG6+H2qv8gdU/AsTOtjVK0k2VQHrclcZkH1FZZqfJxt564?=
 =?iso-8859-1?Q?xoigXFcgSpNS8JJItWkYbmslXZslWpbI333XKt/g0DJoWdTo9fOdjOpIJB?=
 =?iso-8859-1?Q?NWcNIt//H33MTzIPuIBipvJ+svTRr/rKLv0N3cW8/bCEUucb/1rgTxN7Uk?=
 =?iso-8859-1?Q?ubKfIxuBOZGO6ndWFXM1qajpoh36NMfM53tr96ZYD4T/bbJ4NNo8o1WoZs?=
 =?iso-8859-1?Q?aZQJtu5dFJlIr14qhWLPctY+Y0bz732zhyDbPY6uBY5gwr2ptuColIh8Bm?=
 =?iso-8859-1?Q?hd16Bngu0EEw5ztf410ARUb61UiirDSTcPiMzYUQOYZcJIrrQm5oppXoMK?=
 =?iso-8859-1?Q?TefaP++2enrUxkGfy3H/BDK/xi5jXl3SA13dV8ADzP8kQpo+Jf3SlR1ZNI?=
 =?iso-8859-1?Q?I2bXM7BBYc8ErTfdx+kg+IOjgMp0oUd/YdQIBXpTSgeuYPwTqH2zlfTDpJ?=
 =?iso-8859-1?Q?IqylpUvKunRF+iiLwiJGpfWwyMOTnRsBOMJ1/1OEMy+yFSfNwfLrTExU4P?=
 =?iso-8859-1?Q?6eN4DR5f8wzG7JB5NCPg1dMpa0o5ZK3XHFN3+ihmRsq8Zbkt379TkAXtJk?=
 =?iso-8859-1?Q?jNTQvpvdpx+30g631VJj8u2US418E1IZ6R4PSzWK14tKNuaFaYuss7Il8v?=
 =?iso-8859-1?Q?Di/djivIb/IVz58BbiS5os3Y3OSjrMUSjPO3z4OWB6ceFo9YAbVGmCumtd?=
 =?iso-8859-1?Q?iD5sn32PDNMR5w95avuKs1cJU1SlxJvWuF7OniVhZUg/vrRxq+huPocOgs?=
 =?iso-8859-1?Q?Vdjj0MFx5KsrImQ1swAi6n6x7T8/NIjTSPB0MCkBRAQU+qS3AX6cybXgfl?=
 =?iso-8859-1?Q?41ih47bwCyzuZ7ao7gR/iKzbPT1yEafxyKBxo9W7WQdiJKuHc+DywuN9c1?=
 =?iso-8859-1?Q?tXjXPR8wgU0KlSHUjOy6X85kEtEhMaH4Q0gVNjKq+Kk3HQI682KOr9rKQO?=
 =?iso-8859-1?Q?qP7NJ+KWUOPq0hGO+PO+W5vpq5K1vDTKpkvK9Ussh4cE7syF4w+6gsk/gt?=
 =?iso-8859-1?Q?NKgLmFOg0hDpE+4wRtr5CZ3iIsv+9sgevAz0n7Tm6NicoILyoLULoYK+d+?=
 =?iso-8859-1?Q?+i016e/XUvr8jFviZZwyis4cd4RC8r53/bDtKfSF5Etx5IcENH4rzIixg7?=
 =?iso-8859-1?Q?mma2u8ou22i2UIlxCTmy9yDhNglWjYEWOSDFnLRvLNUsw0LJPpf2ztdGyX?=
 =?iso-8859-1?Q?IQcSNnARkDW2+qbOMkaRU/IS/F4vsxoeO/849yaEjlNHQIY5J1UPJJWrMJ?=
 =?iso-8859-1?Q?Q1YaO3E8XfSqpmOzssuaXEB2TP52ORVY9ZlSHxdaVNa7kCxP482X4Xy+tv?=
 =?iso-8859-1?Q?8g08zha96si2nACKlIja3wo0V9rKHTL9W5d0MXk5HhhxoW/jMmXirCxKYe?=
 =?iso-8859-1?Q?3Hub2lIUnMxeMuzEwWSrRvYYGwypIdQvUvWnxrvxRg8dph8APdQHIQy5oW?=
 =?iso-8859-1?Q?bPzfMp0F1L7dFKS921iAc3JMbbinsMtLHsCRypNtO0QMANoRBo6TenfPeU?=
 =?iso-8859-1?Q?4UFRBvg9rIaTiHLN8g4=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89baac5f-af81-40a6-8bcd-08ddeaf64fe1
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:29:37.9187
 (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: bPTJQfVGuqXVF98EBzCvrnCdQyz3ooc1ISxefAa9P7zt+6iR+nduH2shGYiweCsC8mjYgQ4R3BSHK4vc6J3KrXJJuNTvwQquoSfHzoahr+Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB8100

Hello everyone!

This is V6 of the patch series to introduce eSPI support, which contains
fixes and improvements based on the comments received in V5.

The main changes in this version compared to V5 are related to improving
the reusability of the existing code for regular SPIs. Since some patches
that had already been reviewed were modified, I would ask Volodymyr and
Oleksandr to review the updated versions of:

[4/12]  xen/arm/irq: add handling for IRQs in the eSPI range
[7/12]  xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processin=
g
[10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers

Summarized description:
This patch series adds support for the extended shared peripheral
interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
and guest domains. The implementation uses a generic approach to handle
eSPIs, similar to regular SPIs, while maintaining compatibility with the
existing SPI range. Functionality remains unchanged for setups that do
not require eSPIs.

The series includes:
1) General refactoring of common IRQ operations with GIC registers to
improve code readability, simplify further maintenance and prepare the
key functions for eSPI implementation.
2) Introducing a new Kconfig option (default n) to enable or disable
eSPI support. Disabling this option prevents unnecessary resource
allocation for setups that do not require eSPIs.
3) Adding additional resources to store required information and operate
with up to 1024 interrupts from eSPI range.
4) Adjusting assertions and checks to pass verification for INTIDs in
the eSPI range.
5) Configuration of eSPI-specific registers during GIC initialization
for systems with GICv3.1+ hardware.
6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
access and operate within the eSPI's INTIDs.
7) Updating documentation and CHANGELOG to reflect the changes made for eSP=
I
support.

Also, to simplify reviewing, please find below link to unsquashed patches, =
that
are on top of every patch, that is changed in the series, compared to V5:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v=
6-unsquashed/

Github branch with patch series:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v=
6/

Changes in V6:
- individual changes in patches

Link on V5:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.htm=
l

Changes in V5:
- individual changes in patches

Link on V4:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.htm=
l

Changes in V4:
- added a patch for documentation
- individual changes in patches

Link on V3:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.htm=
l

Changes in V3:
- added a patch to update CHANGELOG.md
- individual changes in patches

Link on V2:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.htm=
l

Changes in V2:
- added 2 more patches to implement helper
  functions for gic/vgic:
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
- removed 2 patches:
  xen/arm/irq: allow assignment/releasing of eSPI interrupts
  xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
  since their functionality can be moved to appropriate patches after
  introducing patches with helper functions
- individual changes in patches

Link on V1:
- https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.htm=
l

Leonid Komarianskyi (12):
  xen/arm: gicv3: refactor obtaining GIC addresses for common operations
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
  xen/arm/irq: add handling for IRQs in the eSPI range
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
  xen/arm/irq: allow eSPI processing in the gic_interrupt function
  xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
  xen/arm: vgic: add resource management for extended SPIs
  xen/arm: domain_build/dom0less-build: adjust domains config to support
    eSPIs
  xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
  doc/man: update description for nr_spis with eSPI
  CHANGELOG.md: add mention of GICv3.1 eSPI support

 CHANGELOG.md                           |   2 +
 docs/man/xl.cfg.5.pod.in               |  13 +-
 xen/arch/arm/Kconfig                   |   8 +
 xen/arch/arm/dom0less-build.c          |   2 +-
 xen/arch/arm/domain_build.c            |   2 +-
 xen/arch/arm/gic-v3.c                  | 195 +++++++++++++++++++----
 xen/arch/arm/gic.c                     |   8 +-
 xen/arch/arm/include/asm/gic.h         |  28 ++++
 xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
 xen/arch/arm/include/asm/irq.h         |  38 +++++
 xen/arch/arm/include/asm/vgic.h        |  42 +++++
 xen/arch/arm/irq.c                     |  62 +++++++-
 xen/arch/arm/vgic-v3.c                 | 198 ++++++++++++++++++------
 xen/arch/arm/vgic.c                    | 206 +++++++++++++++++++++++--
 xen/arch/arm/vgic/vgic.c               |   5 +
 15 files changed, 740 insertions(+), 109 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:29:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:29:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108408.1458545 (Exim 4.92)
	(envelope-from )
	id 1utoUg-0006fm-54; Wed, 03 Sep 2025 14:29:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108408.1458545; Wed, 03 Sep 2025 14:29: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 1utoUg-0006fb-1w; Wed, 03 Sep 2025 14:29:50 +0000
Received: by outflank-mailman (input) for mailman id 1108408;
 Wed, 03 Sep 2025 14:29: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 1utoUf-0006ez-CY
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:29:49 +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 71b57246-88d2-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 16:29:48 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by PAXPR03MB8100.eurprd03.prod.outlook.com (2603:10a6:102:223::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:29:45 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14: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" 
X-Inumbo-ID: 71b57246-88d2-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gC0NgJ4rMgkXkh2lqqwtGSWuoRNKEpxKx6f4xqUMkx2MKJA5JRNwKCV5KZ2ZyM9ieA4wxrDKObNyLGXcXxQPp7u47WAulJJ9T6NFjniDOUpn8aCcYENx3NoP4kcoDZ4Aba/igeIMuH9FJNGfsN23puWoR6YnOjM6bY1iH7LmvFkK2W6i8w5X1dW2/XBL7ARb4MBEmlzJ3lK/W50LJVgLLZ0ycHuRz9kY1ff9ByL+h3SzHfICnKASfdqNZzYMeIjGLp9PA3C+thg0JsggfRNvvGIfsiZx12YBAE6mSBW9Fb8uH71w+Pzck/y2pEJQxOuDYA/AKepRNPCyb7aXfL5HJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iRl3NFKrUg/k7v6Lw+zVjZJtjfFQquHWqZIm7yHIZ9M=;
 b=A/u45gn3MmgXD/EnxmWdn1UjTmkfKamXGEVWSRs8I8ivzjVvsjmH/i2rlewKe8/isNjxuABaSUvKIjgbwqQcuzHfZZpmFm7xL7KpFOEgAzPAiTgF3dpR+T//ksnwrBhVUqMUQBSqE8ncdfsL/vkrOa/BJkKJV3pdqmTq8zm1csQh13XJZPpIow8I36n8OqjE1cS0QCKsbJX5Ov7cKNsZP1VYg0mQeykMDGTbSA6OnPsT23qBlPOUwVNRpcqPUBRSkO8z9suBHW0SHRMeWB+L83Uxqw1tV30sn/+YXCgHW3HAF36On3dhEyV+EJzuLhkW0T3JIa9Y+trf75wf14SPAw==
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=iRl3NFKrUg/k7v6Lw+zVjZJtjfFQquHWqZIm7yHIZ9M=;
 b=q3K8ia3qKEZ38Aaj3Ad+t7D3JQsbViLInOjniVEN+29wUxwWlwfYEqq7DvCXJQGkYJOU/krPXNnd+ZmxLAAcA2575OsblK4WFU93blT/8AS6WU0rDf6OC3YxtbJq82gOyLZ/z4nyh2wa0hvXSgnpi+01kmSItfBcsBagaHNtvKks8rVAGT+d+aSIqZyIKocX2LGfzLVPopQu3c7J+cftj8VoYOc2u5p2+BOikWQDC5mVfzFwkLmdxFdKtM4Jw2Y9k2tZ/iByegXC00dnl274LG3IB5LIHZ0yj2uzG1Oxgg+NoMOAy+2v9SJP8BUQplxtoFHNjrIg3uJK3pY8QjMThA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v6 02/12] xen/arm: gic: implement helper functions for INTID
 checks
Thread-Topic: [PATCH v6 02/12] xen/arm: gic: implement helper functions for
 INTID checks
Thread-Index: AQHcHN8xw0irkX2OhkWK7SZDCFd+4Q==
Date: Wed, 3 Sep 2025 14:29:45 +0000
Message-ID:
 <2ca603e479eb320c3ce02035ecdf64006160bf62.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|PAXPR03MB8100:EE_
x-ms-office365-filtering-correlation-id: 4afcc69c-3d45-40f7-78d9-08ddeaf6546d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?SaxGk2ZXsOcGV+xc4HUKcYV5Jyahv02/pNdTgGN8oQ8aqPjGQqeDTjVNyH?=
 =?iso-8859-1?Q?cP3Mc7qBagSjbrBLEakye3bUqEG9crLjv6pHJc5thRnwgmg8z7yH18D7jt?=
 =?iso-8859-1?Q?2fdv9n4htz9/Fa2GWNxvlY8wg0C9wPFIRTNIeU5EyDwFYXuOVWlXUXSaME?=
 =?iso-8859-1?Q?zlT05ZeqtfV0EIrgMLq/lNwxbkvDoaqhRAYfCi+Nhfj/pxhn47F9MKNPoZ?=
 =?iso-8859-1?Q?JiR6lx+kIH8r0T1Sd0zEnUkbHK8yPqi2nmZZTeFUiayHFWNNFhLWB31qoJ?=
 =?iso-8859-1?Q?/4zJGAPcPwqWVBWDuSo3v56b6qqDDAPL8lEUHA+PwaJfGIU/c1PtvHuIgt?=
 =?iso-8859-1?Q?qEkCVhZJUTuRwIRe9Aca5oxGaKSGsBln4yPoxqGboRLPOmEYCdn+RcdUeD?=
 =?iso-8859-1?Q?kN9TESiBGwpoQFgo/BEVd7ibXY6RYXATAyx8xVeg8HtSr2yDOt9NxzOYLN?=
 =?iso-8859-1?Q?OgbaBBqvSilHEei+TXb9VjkojL73dCvAZ10pEUwqd75Cg2LDJzkauD2YAN?=
 =?iso-8859-1?Q?ygu5S74ZCM7eyFUfXCKkGxPv+HrpDOYwJREd6qiccKI10DTvbZTf+8hWYc?=
 =?iso-8859-1?Q?dtD1quTuY7zYcTYocWL0Y1a6ob5x4VOTziimDoLr687mD8CG5Ls65RRFa8?=
 =?iso-8859-1?Q?Q7I9VO4aB+0c7UtPoiQp/ne0HQnG1lZbFNTlUsl3Eq227SG4DbE5rZUPvm?=
 =?iso-8859-1?Q?9MtnGmnQcxpLE2bIBFgOv0ppvUE4BFyhGI0u9rVD0954B+T8eL4lA58Wi8?=
 =?iso-8859-1?Q?UjZarxZmluQZ1kGHEy+dgABRUWN93BEYcb0Ay5C9xo8wpPcT/ET+XM+wc7?=
 =?iso-8859-1?Q?T92a8oL9jZ72QU3BpODZpO0AIsu0ewskUYxohWL/n53qJ9SA/cees+kKRx?=
 =?iso-8859-1?Q?bAnhytBbER3H5O9TbbeoFvmPRqKADKIxJ04pK+y/4gtq61Zd7LGJ0zX3o4?=
 =?iso-8859-1?Q?Xw1QYn9zTVZwgsdr2kXJMcuGGgzyN6KHD0RiL5/Ig2KTSFgJjp0rhWID+4?=
 =?iso-8859-1?Q?JWJ2UOMAuyb3S4GroVhMu4XHvhFyuSbKrd/PN5iR6wNXy9m67MZOpgrXTN?=
 =?iso-8859-1?Q?RSdCv/m1onLHYITWQKpQHCtPGO3CZIq7INh24kr3nS2jjKb4q6NY4/qc4D?=
 =?iso-8859-1?Q?Bi5qJdsH+xyYEr1WT0k9ykTQxUoHyeORZX8rErQDn6j6jxk4Q6A2g5YEdK?=
 =?iso-8859-1?Q?s03NEtwP+enYJzcYM+Qp8PTuj7ncw9/49u6kLJIbv83JFSuvRMVMX80Jx/?=
 =?iso-8859-1?Q?yK3mg5oY1uQshvSyvtbvSRHkySATJk7ZzQo/nH7WPsrLsT6VcJ3Mi3BSEw?=
 =?iso-8859-1?Q?S2gUD6Mf2Mr+BVbxC6pHGkV2mE8tPjlwkrPRmls+XaZiP2gmClmEQriVkc?=
 =?iso-8859-1?Q?uscQDBNERiJSuN4pfBK8uK+ntH2FWb9lEw9HVjnzuIsHJ6GnSoHwEWDY3r?=
 =?iso-8859-1?Q?y4xmTU/ES+Ll0YxLm9vlxGGi1TFSU/3bq7MeHS/qm901N8XSYoyZWf1FYb?=
 =?iso-8859-1?Q?zobghv28eIIEHbyEgBokE+jFdgUi6kRcPJMfHbNAHDGQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?3ekiKNQOxma2IAkT/tUzQPJx+0kb4jhXWTntMIvp9wF7ngt1Ogcs0IAK/L?=
 =?iso-8859-1?Q?FJ76Rd7N10r6tIE438jSVB9DipvMv4K7ZNEHfaNLX5imUtYjtQmBxegZLQ?=
 =?iso-8859-1?Q?yVxpqR8oH4J7rl567yCpP8GOd8zmW+dN2upMnXCrHtKtc1WRZwo54bl3m8?=
 =?iso-8859-1?Q?FAcu5chhIjUNEOzZdeZdH4vU1HPxSHGUMtwQtWhpOgiBwJXPMZGfwx1znu?=
 =?iso-8859-1?Q?LNaQmd/USNt5aqBM+PyhOWq3Tplxb65Sm0Rrxiq9wgdKHmOIacqk4xw1i5?=
 =?iso-8859-1?Q?bkpNCMMBqcWmxCvzr/F4nVtutweG67NnqszcHDw8rt0UFH+6KpSl2kHjTZ?=
 =?iso-8859-1?Q?mxB0oOLIrcZ2ASw4lpE70FX+UN/I4jwwWIYpicUOQUGF2Zt4pQZ+9ewr+4?=
 =?iso-8859-1?Q?1OBPvGk5M9OhveRnVL+n6gE0+vnlCbD1JezwXppwHkDSaVLEUr3LrpvH9v?=
 =?iso-8859-1?Q?M7wmxfx27TnS/WKj/pFK7DacAlq7tx9Vc8oq/0AKk2gsDG80rPrMN1NyQ9?=
 =?iso-8859-1?Q?f7d9d+OtN11t7agdvnoVKJBl1uiFp8X4uWw1ElN20ownLHQ4xdmD5jqrs4?=
 =?iso-8859-1?Q?lTE+gdV1YBLicewnUemqzoLFkNsp0O7COXZZqBsov6rOHQaxNLuWjSXUJP?=
 =?iso-8859-1?Q?R503GYSJZsNrRR5Zt5KPjs7Yxo0UZ2k6bzdt/6tXb0zy5mYAcgx+toESky?=
 =?iso-8859-1?Q?Q+GVuApHHX0vKT6HmG2dGXbEtGfXOmGEq7lTt4G8aO71168sAZUe452cCB?=
 =?iso-8859-1?Q?1Fx+IfnN8twW5xd5EX7PvEKF4An/KbBxlRMv+CNR+JeUbSqOxM8BC5Wx/I?=
 =?iso-8859-1?Q?igt5Zi5OLWeyaKEX9hY/QqZ45YlLLp+FpDmkXzJRjBM2TbCOnhzXDcaKqW?=
 =?iso-8859-1?Q?DJ6qharcnqwfnSf9nacdhKc0jsBtPDs55zjmoaKGDZoAROR980QQDHshiq?=
 =?iso-8859-1?Q?c9Z7xWtEBzDo2c/xlCtCSMyrNEnoG9udHAoBdGddc3HNWpfK82O2mPADsA?=
 =?iso-8859-1?Q?PMhL64EKbJRoxw+W/B6jQ/2s3MSukehrbOjSiGAhqkY/yRZdqeS6XZlQVT?=
 =?iso-8859-1?Q?lDW4hKBNQMImf5zWjTktg94/4c4w/zsRQwP0rjAy+DDJAjruehX0gEh4Nv?=
 =?iso-8859-1?Q?dCyKmvJbq+zso7E5uU7db4FNlSU3ryz8VW1H//zfSW4OEgCcHTGbxBASIg?=
 =?iso-8859-1?Q?mMUDejpMGYvF67b/8o19FQUB2LvrGfHFwllawHGbRrzuegvDSzxAeadl5H?=
 =?iso-8859-1?Q?Q9YHbvZ+pdZolopP8qPOK5PTQNFRTzRXco/48FFXX4nNZuMYMfmunWJQEe?=
 =?iso-8859-1?Q?ccbKzuAPWCQOMEgOysDCDP4JVgjSOYuLfu+7X7KMZfOtTXlByylA6rOWoj?=
 =?iso-8859-1?Q?LxSwXfqK7rORJ35/48DOw31ON8fNExNdGhFJE1mXJ6f0p4NSz9E2YumM+r?=
 =?iso-8859-1?Q?R/RbwIhzMdFAcBIAiM/6twOU354q3G7u+2UKmkuOHDfqjCYPyfGJ7I/BIK?=
 =?iso-8859-1?Q?Lfb9sKXECvTV7JLOqx/M1CdT1A0kvLhzSmwQtbGm3svOA7bavtuJaluDEP?=
 =?iso-8859-1?Q?5qmxV72JJcKHgJYCFf98PNa4gcNp0OdXZDSlqpZupLgkPSuV3kbhaXMtXD?=
 =?iso-8859-1?Q?m5mge2OBOv+mbWVMPfZt3O9+2R2YKOuGHRI+bSj8p65n3oA8dY2KMvwBSU?=
 =?iso-8859-1?Q?h620Fy8x/yX0nc8MkrY=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4afcc69c-3d45-40f7-78d9-08ddeaf6546d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:29:45.5691
 (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: AU6fhZ74rGvoVE62aAg/7rI+QXaCLoTI49qKvllz93iddVPuaoluooXeCpM25jMBdAIYYOo8i5XTqgRKlh5TWjoWb0BiU2xr3JQDp2NfsLg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB8100

Introduced two new helper functions: gic_is_valid_line and
gic_is_spi. The first function helps determine whether an IRQ
number is less than the number of lines supported by hardware. The
second function additionally checks if the IRQ number falls within the
SPI range. Also, updated the appropriate checks to use these new helper
functions.

The current checks for the real GIC are very similar to those for the
vGIC but serve a different purpose. For GIC-related code, the interrupt
numbers should be validated based on whether the hardware can operate
with such interrupts. On the other hand, for the vGIC, the indexes must
also be verified to ensure they are available for a specific domain. The
first reason for introducing these helper functions is to avoid
potential confusion with vGIC-related checks. The second reason is to
consolidate similar code into separate functions, which can be more
easily extended by additional conditions, e.g., when implementing
extended SPI interrupts.

The changes, which replace open-coded checks with the use of the new
helper functions, do not introduce any functional changes, as the helper
functions follow the current IRQ index verification logic.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V6:
- no changes

Changes in V5:
- fixed a minor nit: moved the existing comment to the line above to fix
  formatting that exceeded 80 characters
- added acked-by from Julien Grall

Changes in V4:
- removed redundant parentheses
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- renamed gic_is_valid_irq to gic_is_valid_line and gic_is_shared_irq to
  gic_is_spi
- updated commit message

Changes in V2:
- introduced this patch
---
 xen/arch/arm/gic.c             | 3 ++-
 xen/arch/arm/include/asm/gic.h | 9 +++++++++
 xen/arch/arm/irq.c             | 2 +-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e80fe0ca24..4bb11960ee 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -111,7 +111,8 @@ static void gic_set_irq_priority(struct irq_desc *desc,=
 unsigned int priority)
 void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(priority <=3D 0xff);     /* Only 8 bits of priority */
-    ASSERT(desc->irq < gic_number_lines());/* Can't route interrupts that =
don't exist */
+    /* Can't route interrupts that don't exist */
+    ASSERT(gic_is_valid_line(desc->irq));
     ASSERT(test_bit(_IRQ_DISABLED, &desc->status));
     ASSERT(spin_is_locked(&desc->lock));
=20
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.=
h
index 541f0eeb80..3fcee42675 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,6 +306,15 @@ extern void gic_dump_vgic_info(struct vcpu *v);
=20
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
+static inline bool gic_is_valid_line(unsigned int irq)
+{
+    return irq < gic_number_lines();
+}
+
+static inline bool gic_is_spi(unsigned int irq)
+{
+    return irq >=3D NR_LOCAL_IRQS && gic_is_valid_line(irq);
+}
=20
 /* IRQ translation function for the device tree */
 int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 03fbb90c6c..7dd5a2a453 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -415,7 +415,7 @@ err:
 bool is_assignable_irq(unsigned int irq)
 {
     /* For now, we can only route SPIs to the guest */
-    return (irq >=3D NR_LOCAL_IRQS) && (irq < gic_number_lines());
+    return gic_is_spi(irq);
 }
=20
 /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:30:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:30:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108413.1458555 (Exim 4.92)
	(envelope-from )
	id 1utoUu-0007pd-IE; Wed, 03 Sep 2025 14:30:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108413.1458555; Wed, 03 Sep 2025 14: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 1utoUu-0007p0-E2; Wed, 03 Sep 2025 14:30:04 +0000
Received: by outflank-mailman (input) for mailman id 1108413;
 Wed, 03 Sep 2025 14:30: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 1utoUt-0006ez-6u
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:03 +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 7a21a933-88d2-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 16:30:02 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV1PR03MB10653.eurprd03.prod.outlook.com (2603:10a6:150:203::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Wed, 3 Sep
 2025 14:29:54 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14: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: 7a21a933-88d2-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yWnW5gox+e8yQrydd1nsEbPKV4y+oj5C5Me0kTQt95ZtLMzhKx4WvPHPS9HHYFCG8CiOedXGtm3ct9TZXNFCmU682sCjh3QavdztemmzyMzK09Mw0oMsYe10rDavt843S9pGuc+r0yjvMIhw9vXXHESN6eSM689imL7zRlgN7/h07SwDLWlav4c7/MVUVRxS4DKpNC8eHsLyI2jk0HHSpbHhLLm8bCWw+lJlEZjqzKsgit4Bf/7bStLNfKbEUN0qu1dvylvf9mf8xFlOfrsg8c1xnAMhWxTmgyg/Jd7k51FcFsFyeKme/jv83XmPxLi04HW24kMEvo0rscASJJfNbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vrWC5uRhNl1SE1q8EhTRm8eket1SP2p4NaLI8u9TMD4=;
 b=inAtqYVJGoL1ChVQXkwLGyC8MMkb+9IcxB4uZAKfKFeP1U/KZnlVJKXjnT2qsWsJ3+KhaJl1eDBwxd9OFUnjmsnGz7ZN2sgUF9EE5Kri7UKUsZwAfgqFjX7yYjIkpUT8Ofqo7GZqHgFZN+cpXp/QoybX7kf2zcrmqBPk42Tm1YjMzfxMz5fKVgc8btoysK3cgQuWzSY3QYxSsZZ2sPbkspJ35rBVFqXdjhJHT8pkGWlbPV1fPaBIhHTwnyHkC7o7vy9gs92yR0nuA5voTbrXywImwf80BhJvTmbcx3zZmbtBOfBAwvb7raBct8IQolzDRsyG6yuqoRX2evDMSYOftg==
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=vrWC5uRhNl1SE1q8EhTRm8eket1SP2p4NaLI8u9TMD4=;
 b=u+q2zRnP1vL5HVdwHt2EHJaLpNvWP+VaijJmsuyesSUfC8vbVECg6zkRWu6XMmlbNn3XLjgqLCaI+JrOUXHGiDNwFTZTKExNwU5dMQAn1YyR8p5NUjamJANXfR8fVEjtA8/AkaTwmuvB8af6yWukS129BXrJQM+8ko4FGfWMMg3hPNUKUwziFUEgjJZ2QumWPGzxBnIZ1HipYf7ddfqwU2TAv39jK4PyirUcmxGR1JRiY4UkrWK8u0TAkVUbYEpYg9VtVhplMcvMxjAIWA/nlv24XCxn6ZQTpmtTqKLPQqBRBIzu70wpYIDxk3eBQ+vbZfdDqXtJRRUuRAsdiIQDRw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	, Volodymyr Babchuk
	, Julien Grall 
Subject: [PATCH v6 03/12] xen/arm: vgic: implement helper functions for virq
 checks
Thread-Topic: [PATCH v6 03/12] xen/arm: vgic: implement helper functions for
 virq checks
Thread-Index: AQHcHN83+5P/oJUHqU6wiYlK9zjsyg==
Date: Wed, 3 Sep 2025 14:29:54 +0000
Message-ID:
 <4462db231fb6ba3f63ac6dd51ae4016c0efdb646.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV1PR03MB10653:EE_
x-ms-office365-filtering-correlation-id: ebda2755-f131-43a7-1380-08ddeaf659b7
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?m3REkfmRRFG4HKPfYLpvT7NWEdTvTr8enG30l4VO9VYBnc6oNMSODk/ZkB?=
 =?iso-8859-1?Q?2SxBY27NXYhhZELvAxkHrLQ0MAB9Cko1L7kQpSJwBDNeD4Q9l5MMFsugWD?=
 =?iso-8859-1?Q?L2TQOoEEruUh7T7bwD50hXkvpVfmRyQiVSXPa3xRZHcm4xq0HHq9JtfY2t?=
 =?iso-8859-1?Q?fYE8QEtLLVv66Pv9ygkLaf4QfJ4+SaMRB5MiywlGxPWtthTf8eo3uVAd6C?=
 =?iso-8859-1?Q?4D5wUUX8h5PgDiJkxHe6igqeTDsrkm9Cal8alRdDIh9mvlgb9LnIu6p8mQ?=
 =?iso-8859-1?Q?gDb+/h9gewTuEojle5pVUQ8WqDFD1JUwLynGDy2YOCWg/Uk5yhhLyZCA8p?=
 =?iso-8859-1?Q?2ut9hUycehK3fAIP2kni14hH7YIDYHywD9PbbeLr27/blf7Wmcf8SvUWl4?=
 =?iso-8859-1?Q?MQb9A4keZGXkMhk3tYliCbAHwbDqsZYc6h/A0SeDSAMsKbMaZZFtgFpAGO?=
 =?iso-8859-1?Q?h0hcWKdRaqpWRPZRC2tDNwp4m28mxedUHAtBtudaeaBQrniaZphpCakrgG?=
 =?iso-8859-1?Q?Uww2NzW70aNMfB745giXr6saGaEyvvXN4Er4iOo7t4081Wcx9ihv5vyfGp?=
 =?iso-8859-1?Q?0gT/u/MPVtCNpMsA3D3EUHNK/puh2Ko/HlqX2Sc9cKwuSN0WRym9/LyEm/?=
 =?iso-8859-1?Q?IAGDW8joyJMb0eWzAuU2VawV5+R3X6m+an7fAZTEVeNrQ/m+MatzLTI7Vt?=
 =?iso-8859-1?Q?gMFqfk6kkhgC21xMdTmlJeq1IWY5BgxbX8Pxv+6QomwSvWNBkObi6ah0Fs?=
 =?iso-8859-1?Q?wdYCDfCRu/oydQIPq0sDb64Lo5y7V8yPzLE245tFCMXXOxu7+5PFiPsmwP?=
 =?iso-8859-1?Q?sHORJMoNRwwXJwzVvh/TbrB0YCARvSwB9EaV3h6Yq+2qrNcqB+VrwaOY6/?=
 =?iso-8859-1?Q?QYLHTF2PQYzt5FIeKa2J4xF1z71AW4nckF7JmhTHcata+lXg3tY79KS+e+?=
 =?iso-8859-1?Q?JP4/Mfu//EdQOH5FXHi5ueWz5W/JmSbMQwuSDUyYSbsDrVPOXKWRxSS+PR?=
 =?iso-8859-1?Q?VonO4pKVJv1jjzJ/F9CCiClXvfZRcLJrYYyFDlmZoKxxKNY3JmrSHtwuGh?=
 =?iso-8859-1?Q?LGcpaMNQzNDR/6HF7QW8TFnMGYMLwCN47oECd+KxLDo74rfADqtg5LTNmE?=
 =?iso-8859-1?Q?qckBXbrQfcMLbFNhpEe0Uq0GN9Hsxr7ex8A/nGb8G5cDtkwFmcsIu/m8Rs?=
 =?iso-8859-1?Q?dM0cyA9Tg7KjDByYkb1BmrQZmR8tiGtI8bPIGP9/mBnhJBYlcfeasVFqwy?=
 =?iso-8859-1?Q?ApaI8DMidi+l+i27xq8lVIR3ZkzeYCxq1tuHe8STQWgevgGNy24ZcI9ecK?=
 =?iso-8859-1?Q?yp7B0MCrX8JSQ2ROZ4hJjWYfjAGfaUjRtAepW1J+qt5uQpMZOGSFmgG1jn?=
 =?iso-8859-1?Q?g2XdzJ2mY+4pmFfJBVROwyb/qIAYJHYjSBjUd9RE4EA75q7y2aVv1zIF2l?=
 =?iso-8859-1?Q?OozOtF/CKW7PFvrCE8Ynj6K5IiBIh8j5TgfiHosk6ohi3cD2YeqmZJgyfx?=
 =?iso-8859-1?Q?yepbMZrdPUKGIV8QGR1Szkg6GR3QgxCsi1cSz5jl3a3w=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?AhkwvMO1g1dG1KE79zalOjd/L0OeJP7OUiW0YBX7tUfid6oIVCNi+sFiBz?=
 =?iso-8859-1?Q?i+p8DiDW+zWCApioULwS9yWRzXHjvxQNEEn5JpJLw/CnHqSUzEq0sxrQib?=
 =?iso-8859-1?Q?wbm/whGpzMC/ugJPVKwDE9xAq5Zh19+lAp14/2HAn5OJGaHc4j5Rlf+ICZ?=
 =?iso-8859-1?Q?62eO3xZjR2GAFAp9D/ZBHje493BIXzcltiPQHDrdeaA3cJeNSPI3hDpwZP?=
 =?iso-8859-1?Q?cnK4/O2XNpEANk6kFCjObbPm/HyntsCzy/vymRg2mjqLMW256m3GCcStX3?=
 =?iso-8859-1?Q?tw3NM2kKuJeenuOUpoCv1X4KLdT721IUKGh7SwQ+6SwBLHwpY23x71Sv5/?=
 =?iso-8859-1?Q?8MjYkgJNi9Plfmj1b+Od4LR+xHkQ5S+3W8YXSTNLBlfCNohUa1znXvGEof?=
 =?iso-8859-1?Q?0mVvVOcgbCAqIiyPB8Gsoh6t91wwMpMRdZVxIEk50JsEM7V7EWT2Qeb20J?=
 =?iso-8859-1?Q?muNfbAWVf8xt+YscGiogGIjOXxJbg46crwZsilYqQSp1brd3oNlOfSh1fI?=
 =?iso-8859-1?Q?iyrH8xH9evpAhLDEZ1MqEsQGGhBseLFgPvx9aJVfScbMbgpmD5AdpTs9+L?=
 =?iso-8859-1?Q?emHF+Xe+vX/btv6GGpNmoUD47mQ7h9FFEFkJQXgMclUN08USePRrRGyA/o?=
 =?iso-8859-1?Q?mIBhbL1XUsYLe2Qd4x86RVY6XrBoEWqcQaD2XHXUHc1XTyGUKBNLiOc3rm?=
 =?iso-8859-1?Q?l9bwqUldUSW1bG7EiX79XReYymm78C2RxpXXrhS+lU0fubvEQiy80+agMG?=
 =?iso-8859-1?Q?0aUMwGymqffYEZ9p2SrPyi5OGCYy6Rbe8K0JHI6VqUVs/l36WWsa+FFR3X?=
 =?iso-8859-1?Q?LkDVS1aaa+aRLueLhJoHJLlgIPoIEijmLx89+lwXHbxiLz/8V9G4u1jjJM?=
 =?iso-8859-1?Q?eJvL+w4KiiIdU3vwsWmvYYDPKN9SEw3VE1TkbNaqLI7nHQiNNcpH87ZmXL?=
 =?iso-8859-1?Q?m53b6c0ff8OWCkTh0OpLHaHK7uF3AL8k7sL4ssQ5jJJz3vo/uTL0P4OvcI?=
 =?iso-8859-1?Q?C5Ddb/sBxlBGzBfQjX7GxPKRDufAi8f9GIfBW1Xi8kfupIDMF7Z5VY8B4K?=
 =?iso-8859-1?Q?nSaMhfqiEyizOd11waAMLfmgoFaDFkjXUV65fz4Kjzi/TQ0vGosh5OLMc8?=
 =?iso-8859-1?Q?Re/x8UOqSUUe+iV9+JUS2WfzVSqIMGUhrnus5IMPJzuERbCCuYaStQ+9G1?=
 =?iso-8859-1?Q?WLnVQlTT4yeglAlVghbX+yOmrkvS4oQodvWCa3ivhXtygpfhLgPNFHAGih?=
 =?iso-8859-1?Q?8RRJFN//LHYIssbq7c20yUgd/cwuGTMsS5IaguNShxXTIDE5W8JQyI7kX0?=
 =?iso-8859-1?Q?uIx1a10goYGv/tSkrDWxpDQeg0p4FhuMIioBESKWd2MdSo7HaXSN+0apOz?=
 =?iso-8859-1?Q?RnZI1bOtd8ydWay5JVAF37gfugvvc7ZnO41UhMV4Mc5FY6dTWKbgAgmvBG?=
 =?iso-8859-1?Q?wqHGy2A56i/n2qwUx+LwRE4IIk5tzRG97agr1ilBQvSKVmvzj1tylYFL/h?=
 =?iso-8859-1?Q?aLMzkwqlYjBEnlv2dFasO2+T+CtOXEwDqjjRhKDtXUVJBdRbaizmTgmq8P?=
 =?iso-8859-1?Q?A9i2jvJQgVVWHj/l6tbzIFg6/Q1W+F+erZtjHxgqS5k/Ju/Jq1AaVnURBU?=
 =?iso-8859-1?Q?msfkCh9PjYFXqmCRRRTTAoGQgXD32eLE8+fTtjDSs5jDUX2n2uDTLcISs5?=
 =?iso-8859-1?Q?wQ3dt8vgtZMKv8zxzY8=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ebda2755-f131-43a7-1380-08ddeaf659b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:29:54.3937
 (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: t8pQ1BfqZ6YnaStW2Lk/ILSVuLGuXhPIdLQuRH572ofi8qAXN1y5yTcmuRWT/RkPwBTyaPQze/Z6raCudOTg1CEHkd2lN9hdYR8eE/7XHdc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10653

Introduced two new helper functions for vGIC: vgic_is_valid_line and
vgic_is_spi. The functions are similar to the newly introduced
gic_is_valid_line and gic_is_spi, but they verify whether a vIRQ
is available for a specific domain, while GIC-specific functions
validate INTIDs for the real GIC hardware. For example, the GIC may
support all 992 SPI lines, but the domain may use only some part of them
(e.g., 640), depending on the highest IRQ number defined in the domain
configuration. Therefore, for vGIC-related code and checks, the
appropriate functions should be used. Also, updated the appropriate
checks to use these new helper functions.

The purpose of introducing new helper functions for vGIC is essentially
the same as for GIC: to avoid potential confusion with GIC-related
checks and to consolidate similar code into separate functions, which
can be more easily extended by additional conditions, e.g., when
implementing extended SPI interrupts.

Only the validation change in vgic_inject_irq may affect existing
functionality, as it currently checks whether the vIRQ is less than or
equal to vgic_num_irqs. Since IRQ indexes start from 0 (where 32 is the
first SPI), the check should behave consistently with similar logic in
other places and should check if the vIRQ number is less than
vgic_num_irqs. The remaining changes, which replace open-coded checks
with the use of these new helper functions, do not introduce any
functional changes, as the helper functions follow the current vIRQ
index verification logic.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V6:
- no changes

Changes in V5:
- added reviewed-by from Oleksandr Tyshchenko and from Volodymyr Babchuk
- added acked-by from Julien Grall

Changes in V4:
- removed redundant parentheses

Changes in V3:
- renamed vgic_is_valid_irq to vgic_is_valid_line and vgic_is_shared_irq
  to vgic_is_spi
- added vgic_is_valid_line implementation for new-vgic, because
  vgic_is_valid_line is called from generic code. It is necessary to fix
  the build for new-vgic.
- updated commit message

Changes in V2:
- introduced this patch
---
 xen/arch/arm/gic.c              |  3 +--
 xen/arch/arm/include/asm/vgic.h |  7 +++++++
 xen/arch/arm/irq.c              |  4 ++--
 xen/arch/arm/vgic.c             | 10 ++++++++--
 xen/arch/arm/vgic/vgic.c        |  5 +++++
 5 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4bb11960ee..9469c9d08c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -134,8 +134,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned i=
nt virq,
=20
     ASSERT(spin_is_locked(&desc->lock));
     /* Caller has already checked that the IRQ is an SPI */
-    ASSERT(virq >=3D 32);
-    ASSERT(virq < vgic_num_irqs(d));
+    ASSERT(vgic_is_spi(d, virq));
     ASSERT(!is_lpi(virq));
=20
     ret =3D vgic_connect_hw_irq(d, NULL, virq, desc, true);
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 35c0c6a8b0..3e7cbbb196 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -335,6 +335,13 @@ extern void vgic_check_inflight_irqs_pending(struct vc=
pu *v,
 /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
 #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
=20
+extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
+
+static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
+{
+    return virq >=3D NR_LOCAL_IRQS && vgic_is_valid_line(d, virq);
+}
+
 /*
  * Allocate a guest VIRQ
  *  - spi =3D=3D 0 =3D> allocate a PPI. It will be the same on every vCPU
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 7dd5a2a453..b8eccfc924 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -442,7 +442,7 @@ int route_irq_to_guest(struct domain *d, unsigned int v=
irq,
     unsigned long flags;
     int retval =3D 0;
=20
-    if ( virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_valid_line(d, virq) )
     {
         printk(XENLOG_G_ERR
                "the vIRQ number %u is too high for domain %u (max =3D %u)\=
n",
@@ -560,7 +560,7 @@ int release_guest_irq(struct domain *d, unsigned int vi=
rq)
     int ret;
=20
     /* Only SPIs are supported */
-    if ( virq < NR_LOCAL_IRQS || virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_spi(d, virq) )
         return -EINVAL;
=20
     desc =3D vgic_get_hw_irq_desc(d, NULL, virq);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index c563ba93af..2bbf4d99aa 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -24,6 +24,12 @@
 #include 
 #include 
=20
+
+bool vgic_is_valid_line(struct domain *d, unsigned int virq)
+{
+    return virq < vgic_num_irqs(d);
+}
+
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)
 {
@@ -582,7 +588,7 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, =
unsigned int virq,
     if ( !v )
     {
         /* The IRQ needs to be an SPI if no vCPU is specified. */
-        ASSERT(virq >=3D 32 && virq <=3D vgic_num_irqs(d));
+        ASSERT(vgic_is_spi(d, virq));
=20
         v =3D vgic_get_target_vcpu(d->vcpu[0], virq);
     };
@@ -659,7 +665,7 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr=
 hsr)
=20
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
-    if ( virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_valid_line(d, virq) )
         return false;
=20
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 6cabd0496d..b2c0e1873a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -718,6 +718,11 @@ bool vgic_reserve_virq(struct domain *d, unsigned int =
virq)
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
 }
=20
+bool vgic_is_valid_line(struct domain *d, unsigned int virq)
+{
+    return virq < vgic_num_irqs(d);
+}
+
 int vgic_allocate_virq(struct domain *d, bool spi)
 {
     int first, end;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:30:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:30:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108415.1458566 (Exim 4.92)
	(envelope-from )
	id 1utoUv-0008Ex-Sm; Wed, 03 Sep 2025 14:30:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108415.1458566; Wed, 03 Sep 2025 14:30:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utoUv-0008ES-Nb; Wed, 03 Sep 2025 14:30:05 +0000
Received: by outflank-mailman (input) for mailman id 1108415;
 Wed, 03 Sep 2025 14:30: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 1utoUu-0006ez-6x
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:04 +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 7aad0cb2-88d2-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 16:30:03 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV1PR03MB10653.eurprd03.prod.outlook.com (2603:10a6:150:203::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Wed, 3 Sep
 2025 14:29:59 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:29: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: 7aad0cb2-88d2-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CLFl93IL7tEJsRvKBcL6QiLeeJXdzsW+Gyp4aexmIfmc4veRrNskAbjPi2Gx5CgA8E0WVSMDjhBmv1XUwoG4TPQtTmdkhru/OFsYxp3GdZcSFulE25RGxQc/WyNHrrgQ2SQvQjTilxbxWgBnzsY4+WsRAtFxAJ++IMF6hJr7x54n6xTpzq83ZDXcU6JSGWnvaQt2LQmGb0QiQD6x0iu9W0nfsmPMy6XaecTx+GVVH36V4rTEwNIhriLDjnTac7NIbRgtkymjKHlqzsdUS37OKF0hkcF0lWBm6dGGSwIWAKbu+hq2Kyd7veUsz9lf3QN7Vr/KyOq5tkY1UO8aMXetkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uddG+ZQNOEeV7oaE/2uDHhE7FrL2ecdb6+J/N7Jflu8=;
 b=n+EH1H53kJd6ViW93OceMYDHaCSMS2QaFwdFBb8MjHLfXfDExv9J3hu0ZPW/6jkq1tEJ0qPH7XjeL/cuVOXL6QbyGO0qCsQJkYM36aZND+okWxv77rMKucAQ6WCqPlczqGI3926LIgUeY8jDfOcq9AfiFkj5TFPZg7jb92C6f6hMloCIMY7F7+mSodGsmDplcIGfnf7EH0HX2OajiZqOAe5nXrNylZ6T5+yTO46/cd14Xdd2nKCNOowoPg975iuIXzERhnx4gT34t2qvi+Vk6TdVhBSPyc6wSohuaM34myGxjIjpxiPWEDN1ETkrcnZmSs46YQyUL0WzSrLh181sgw==
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=uddG+ZQNOEeV7oaE/2uDHhE7FrL2ecdb6+J/N7Jflu8=;
 b=nRYo59ZDAjr56Ykbh3+JfHyA4yqr/1bwVUmHuJxxf972dl+Qtksg5EhVQv7+PerzNsgAvDVldpGQf/3UK++lbo6wMystqTtkU+k5DKRU7Qytbu0JtZ/hrXJN8tI0jKZ4Dqe550x9PimCcBVl7iCr5bScGJJYBdZEB0i/AN8/s/u+awL6SFUR8Jea9Jj4UwWh5bnC6atSWdttEyI28ZEt8etfQAKBvPljLmiEcsV6DdByeY1UffPSCexhYWCYdqhjW5v4hg/HYvWyszjCKKIg6OlNhQ9ahsKkkFf61M8U4gEm6aPJmDpyx/8h38xjO6PFSQdzJWFcBHW1pPhAr6838A==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI range
Thread-Topic: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHN861IdGTmH+JEChpQbSpoZJ2Q==
Date: Wed, 3 Sep 2025 14:29:59 +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: GV2PR03MB8678:EE_|GV1PR03MB10653:EE_
x-ms-office365-filtering-correlation-id: 84f1623c-a08f-4349-e1fb-08ddeaf65ce1
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?xtj6eVt22J5h89hLkHM/ZAgCUHSY+2FSzZ5PojWK5Ro7UjRS9uSAmst1N8?=
 =?iso-8859-1?Q?x2N4YNyA4hSaByRzyP7NT/2rKCJLi2WVpDkYzMZjOJHE/9CPwiPqDj47dL?=
 =?iso-8859-1?Q?opRyWlmSerEQnTv07jVda7Vqn7eXEksgkENe0vL+OQCSoenh4uML3/n4gV?=
 =?iso-8859-1?Q?9/+QlkGk4plv7Li+8V6KbgEZFN+Jnjzc0y/hpMNyYH2D98pN06b4rF/lbN?=
 =?iso-8859-1?Q?LX2uTZ8HQXxP58o0sIYwbKh2aWmGa3L08lqtOdgvnYJyNix3DXmKzWQuqr?=
 =?iso-8859-1?Q?+BJqOs2LsrKqwcPHjBphL+kmTx0G21F8xx7ffTbZVPtEvnpuLwzG4El3Em?=
 =?iso-8859-1?Q?T4TDJ6SeAzQIp4AH8AHlud2SVMIEbsJ2lNJrBmcYCq/j1UrmTg9oGwU0J7?=
 =?iso-8859-1?Q?EzGvMbj0sHJVATacqZV6qmfgvsCdwi7HffTQNCzz0aqMNczfZaoq2SZHIV?=
 =?iso-8859-1?Q?dgqecZaC9YTBtGJ/HJGf5k+fqQOaFY5q3nm96ANIJ72xS+i/Ue1IRvuW9V?=
 =?iso-8859-1?Q?g9vOpw3mRSFcndBUGJppctGbvPhbu645M6qrMAgz7v/6z2aKqhxJXpNlH3?=
 =?iso-8859-1?Q?bHZtiPOe5GhQbNwqYPKqGQ91V0pMjt6+7KbbPkx7VjdphhjdKv8LNFrTd4?=
 =?iso-8859-1?Q?3zAMxc2fJANKm4GhRcbflGtgFK64IN1+BZNHipvM8+U+omnbbjZYQPsKh+?=
 =?iso-8859-1?Q?0lItIPW/0gFi6syw2rg8MK661oQUDmicC66pNeFoCe02lyRO4EIRPQX0g+?=
 =?iso-8859-1?Q?Sn6A7gOGNQYbdjKgy49G2a6ISe2w7fJ+J1UqFilGSVHYvkJS7wLnFsGirp?=
 =?iso-8859-1?Q?49AvlMRbL3+5Q77gA6jipT9mhKUX3rs4dZ0i/8XXwFdvnVfexsObtuoau7?=
 =?iso-8859-1?Q?9YFB4FQqvnqyj/yh7Q2yznrD0nTHKB+qSLGq2lOuiG2ezrj/SnRRuE4Ba3?=
 =?iso-8859-1?Q?JdMhKs/bz90rC0+ed1sDmiYPoxpd8LTrG9G34fU4gTkAMvpMqcoHziCwlM?=
 =?iso-8859-1?Q?9qyFqlp2GMGj3qL/57P6jlASGL9WkyMIQRQw71/Ua3FQHDS+0hDAK2/HV6?=
 =?iso-8859-1?Q?trbchhK7JkURqGGr1YwWFqgKap5A0w71KIIK3dFkui1ilygS+heZwzN5AW?=
 =?iso-8859-1?Q?3wmmUlZBvigmgV4M/9ukeU8l08nsEapVokxneusrGdvQi9+TlTYR3RjgmR?=
 =?iso-8859-1?Q?RU6WRyx/j1+DNH003Cz20jrsBtzMkxq/3WVhfAcX8+kQh+2eZk+KZdbJHw?=
 =?iso-8859-1?Q?S1JAow/rs2jPpzjbres3hAaCF2rYJwZOHSZfrGogMuYmWZOozaPBFG4WlI?=
 =?iso-8859-1?Q?ho6wB9+ZegIiE3oKlABzo3PN8ffFmoF/7kJriRbp9ipHQAWCAv/NoOg4s3?=
 =?iso-8859-1?Q?jk83i+18sglQjatgInlggIaHrKvebymL4kLJ4Fk91JJAUzl4YgiZQVYHRI?=
 =?iso-8859-1?Q?8/yGYt+vfmEP9VtQi1C6fnJWzcJ3dnVWv8yddhlOjfzDFYa49hduqvJAqU?=
 =?iso-8859-1?Q?iwIHwS4CgxyRws/Hg4drEde9TxNSylgdkGAnTrvDDX9Q=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?BXJeqR/GWaY4Qq0jHCRsflB0HBKOKpR4o8OE/MRLf5XhQ26wUsOCj756PT?=
 =?iso-8859-1?Q?kvDryPeg0TbXyipE5qdUwr/2fLjPxpWyyPXRZ8fvKeBh8Zo8clFpu5swE0?=
 =?iso-8859-1?Q?GEUPR/QlM19xfXCdy63bCDD20+o6liE73xJOJVekkxRkGus73+lVdwMIZQ?=
 =?iso-8859-1?Q?loYcIHRY9Ydndf0BDuJi1aUia6jaQaBRxOR+XtFyAt5Bq8eLAW3dU4omEu?=
 =?iso-8859-1?Q?OvhOBG/pTtfwXYkwyA+ytpWHFuJ3TKvZD4yUZmulwIlOEEOswIRV+kmj1L?=
 =?iso-8859-1?Q?NY3YXZGrR90tSKPIXe2EHszfoIJ9Q4BjEsmfFYJfE63ZlmKmowiOh/HrbN?=
 =?iso-8859-1?Q?/13vlFH+n0tBGdeuyENAQJQBUUEwQOzlLh74l4SVNrmxDJ/2rujxsK+Fy/?=
 =?iso-8859-1?Q?m1MjQEh59BvpBxPTwgYzwHo9tsRdMxVUwcgScrenRbX35oAbTmXd5whXXq?=
 =?iso-8859-1?Q?TlwezNrQjQKvJ1zADsA4V63RkWjc/nYxz1PHLvxSapfTV74BDh7d9JvaYX?=
 =?iso-8859-1?Q?k3IXT40act+92Hm/d1dhHRbiBanqT2JO9Ge3JBlxW8zrzP2U3RjWWTffuM?=
 =?iso-8859-1?Q?0JIkqudRbRdpY37t9pzb0i6GNiM4ExldDriKgY7a7FcjIVXMb6JpDyFvqX?=
 =?iso-8859-1?Q?tUyM7rG9NMi+uWk1s3n0rfNgYMAvrtvAiBI4FkX1U3Kt+TfND75whxh92W?=
 =?iso-8859-1?Q?jEFStvwTDoksEP7CQBLWvXYXj3AJj5cCKL5Mle10hZIM8ivBZIfjQsg/zh?=
 =?iso-8859-1?Q?n4bse9PgnILRhCjBJVKzI9AQV/EHX7aH0BzEogkydmwsRpNe7KKikRMUai?=
 =?iso-8859-1?Q?TdhQBGR8XThXnU4QrKEmgjF+YTCccEMnYje7lTL8W1RgPWNQeAPfIa2BGx?=
 =?iso-8859-1?Q?UVJQVB93ozJyiW9K//t1zLEs6KeXe59I6VqD+SixW2FyFgg33DWOFT/SYy?=
 =?iso-8859-1?Q?y8nPcWBXoftfeh1POqhRe6p2SIXGNs7JE1Z0NGJrHfHMMkWe7H6pjl2KRb?=
 =?iso-8859-1?Q?SkKx7O15fj1rnee5gVoRFOhSqqbO9H5qMAWhQgK+Jdw7m0mtjW1tNzI8ji?=
 =?iso-8859-1?Q?EFsYc0VlFA/hZrGU5AqHpsVuyIF/7fN300n6k9hAudck9L9DNt066pxvHg?=
 =?iso-8859-1?Q?h6GFcis0qapk6vcvO1PYcDlIYrXNPncvW8GoDmcbnTlxKii1k6g8Eps1iF?=
 =?iso-8859-1?Q?uqUhOJd6D0BThq+qXxEKqiQBEtiEfq7GEj23TicTGikAy0QYYtK+IeuR2L?=
 =?iso-8859-1?Q?dF1h2c9hEA88lo27JnRbcF3i4W20aqYW2QqxUphg20x+rgu5HfTn5fRqWl?=
 =?iso-8859-1?Q?o218ZV74Jhsf5RTb7Adrtr2Um1P95XDbrB0SLoD1gGpYkFbVcj0o0TFcqD?=
 =?iso-8859-1?Q?sYkSke8X79Zu3ljjya2mZuG3HslnjYZg7cmgxJAzwomn38ThTHdzG9UX0r?=
 =?iso-8859-1?Q?hM9CiOHEzQH2pW6XMCZjxSx7ASIojBHfwFZbYce1jUQmNFYmi7WPH2xjYM?=
 =?iso-8859-1?Q?lBGRekfn1z7PyBC8Ac83jV3XQ3OqQsWN5Kaj5zNwKOJMpfPw3G5hKjwNUo?=
 =?iso-8859-1?Q?Zo9+ASwAiX13iWctw5ciOY5nAVJ2vTNI7wxh4zO6OCle8BOezkJre0gfs2?=
 =?iso-8859-1?Q?3OJOCKnLWbCER1rJSBmUsLq+ZkheT2W+g7XlZOrXMSVi4HdsYg31+WEZG1?=
 =?iso-8859-1?Q?rT7IF7U3CEYIs0UPRtY=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84f1623c-a08f-4349-e1fb-08ddeaf65ce1
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:29:59.7562
 (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: C6dR9DhLvYO9u4Ii2XNdIlEC1STg/txzLcSXEsUXmCporXgEzOC1P/d841Mim+N2LS7QQyCPY91YgbWBrjuAE5dFrwlABblo2fyOFyTQ1oY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10653

Currently, Xen does not support eSPI interrupts, leading
to a data abort when such interrupts are defined in the DTS.

This patch introduces a separate array to initialize up to
1024 interrupt descriptors in the eSPI range and adds the
necessary defines and helper function. These changes lay the
groundwork for future implementation of full eSPI interrupt
support. As this GICv3.1 feature is not required by all vendors,
all changes are guarded by ifdefs, depending on the corresponding
Kconfig option.

Signed-off-by: Leonid Komarianskyi 

---
Changes in V6:
- added an assert in is_espi() when CONFIG_GICV3_ESPI=3Dn to ensure that
  out-of-range array resources are not accessed, e.g., in __irq_to_desc()
- removed unnecessary parentheses in is_espi()
- converted helper macro to inline functions and added sanity checks
  with ASSERTs to them
- defined espi_to_desc for non-eSPI builds as a prototype
- updates the comments
- used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs

Changes in V5:
- no functional changes introduced by this version compared with V4, only
  minor fixes and removal of ifdefs for macroses
- added TODO comment, suggested by Oleksandr Tyshchenko
- changed int to unsigned int for irqs
- removed ifdefs for eSPI-specific defines and macros to reduce the
  number of ifdefs and code duplication in further changes
- removed reviewed-by as moving defines from ifdefs requires additional
  confirmation from reviewers

Changes in V4:
- removed redundant line with 'default n' in Kconfig, as it is disabled
  by default, without explicit specification
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
  case of using NR_IRQS for espi_desc array
- implemented helper functions espi_to_desc and init_espi_data to make
  it possible to add stubs with the same name, and as a result, reduce
  the number of #ifdefs
- disable CONFIG_GICV3_ESPI default value to n

Changes in V2:
- use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
- remove unnecessary comment for nr_irqs initialization
---
 xen/arch/arm/Kconfig           |  8 +++++
 xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
 xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
 3 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 17df147b25..43b05533b1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -135,6 +135,14 @@ config GICV3
 	  Driver for the ARM Generic Interrupt Controller v3.
 	  If unsure, use the default setting.
=20
+config GICV3_ESPI
+	bool "Extended SPI range support"
+	depends on GICV3 && !NEW_VGIC
+	help
+	  Allow Xen and domains to use interrupt numbers from the extended SPI
+	  range, from 4096 to 5119. This feature is introduced in GICv3.1
+	  architecture.
+
 config HAS_ITS
         bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORT=
ED
         depends on GICV3 && !NEW_VGIC && !ARM_32
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index 5bc6475eb4..f4d0997651 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -32,6 +32,10 @@ struct arch_irq_desc {
 #define SPI_MAX_INTID   1019
 #define LPI_OFFSET      8192
=20
+#define ESPI_BASE_INTID 4096
+#define ESPI_MAX_INTID  5119
+#define NR_ESPI_IRQS    1024
+
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case.=
 */
 #define INVALID_LPI     0
=20
@@ -39,7 +43,12 @@ struct arch_irq_desc {
 #define INVALID_IRQ     1023
=20
 extern const unsigned int nr_irqs;
+#ifdef CONFIG_GICV3_ESPI
+/* This will cover the eSPI range, to allow asignmant of eSPIs to domains.=
 */
+#define nr_static_irqs (ESPI_MAX_INTID + 1)
+#else
 #define nr_static_irqs NR_IRQS
+#endif
=20
 struct irq_desc;
 struct irqaction;
@@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
     return irq >=3D LPI_OFFSET;
 }
=20
+static inline unsigned int espi_intid_to_idx(unsigned int intid)
+{
+    ASSERT(intid >=3D ESPI_BASE_INTID && intid <=3D ESPI_MAX_INTID);
+    return intid - ESPI_BASE_INTID;
+}
+
+static inline unsigned int espi_idx_to_intid(unsigned int idx)
+{
+    ASSERT(idx <=3D NR_ESPI_IRQS);
+    return idx + ESPI_BASE_INTID;
+}
+
+static inline bool is_espi(unsigned int irq)
+{
+#ifdef CONFIG_GICV3_ESPI
+    return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID;
+#else
+    /*
+     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI =
is
+     * disabled. Returning false allows the compiler to optimize the code
+     * when the config is disabled, while the assert ensures that out-of-r=
ange
+     * array resources are not accessed, e.g., in __irq_to_desc().
+     */
+    ASSERT(irq >=3D ESPI_BASE_INTID);
+    return false;
+#endif
+}
+
 #define domain_pirq_to_irq(d, pirq) (pirq)
=20
 bool is_assignable_irq(unsigned int irq);
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index b8eccfc924..c934d39bf6 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -19,7 +19,9 @@
 #include 
 #include 
=20
-const unsigned int nr_irqs =3D NR_IRQS;
+const unsigned int nr_irqs =3D IS_ENABLED(CONFIG_GICV3_ESPI) ?
+                                        (ESPI_MAX_INTID + 1) :
+                                        NR_IRQS;
=20
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
@@ -46,6 +48,50 @@ void irq_end_none(struct irq_desc *irq)
 }
=20
 static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
+#ifdef CONFIG_GICV3_ESPI
+/* TODO: Consider allocating an array dynamically */
+static irq_desc_t espi_desc[NR_ESPI_IRQS];
+
+static struct irq_desc *espi_to_desc(unsigned int irq)
+{
+    return &espi_desc[espi_intid_to_idx(irq)];
+}
+
+static int __init init_espi_data(void)
+{
+    unsigned int irq;
+
+    for ( irq =3D ESPI_BASE_INTID; irq <=3D ESPI_MAX_INTID; irq++ )
+    {
+        struct irq_desc *desc =3D irq_to_desc(irq);
+        int rc =3D init_one_irq_desc(desc);
+
+        if ( rc )
+            return rc;
+
+        desc->irq =3D irq;
+        desc->action  =3D NULL;
+    }
+
+    return 0;
+}
+#else
+/*
+ * Defined as a prototype as it should not be called if CONFIG_GICV3_ESPI=
=3Dn.
+ * Without CONFIG_GICV3_ESPI, the additional 1024 IRQ descriptors will not
+ * be defined, and thus, they cannot be used. Unless INTIDs from the eSPI
+ * range are mistakenly defined in Xen DTS when the appropriate config is
+ * disabled, this function will not be reached because is_espi will return
+ * false for non-eSPI INTIDs.
+ */
+struct irq_desc *espi_to_desc(unsigned int irq);
+
+static int __init init_espi_data(void)
+{
+    return 0;
+}
+#endif
+
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
=20
 struct irq_desc *__irq_to_desc(unsigned int irq)
@@ -53,6 +99,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
     if ( irq < NR_LOCAL_IRQS )
         return &this_cpu(local_irq_desc)[irq];
=20
+    if ( is_espi(irq) )
+        return espi_to_desc(irq);
+
     return &irq_desc[irq-NR_LOCAL_IRQS];
 }
=20
@@ -79,7 +128,7 @@ static int __init init_irq_data(void)
         desc->action  =3D NULL;
     }
=20
-    return 0;
+    return init_espi_data();
 }
=20
 static int init_local_irq_data(unsigned int cpu)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:30:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:30:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108420.1458576 (Exim 4.92)
	(envelope-from )
	id 1utoUz-0000M0-DH; Wed, 03 Sep 2025 14:30:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108420.1458576; Wed, 03 Sep 2025 14:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utoUz-0000Lm-6c; Wed, 03 Sep 2025 14:30:09 +0000
Received: by outflank-mailman (input) for mailman id 1108420;
 Wed, 03 Sep 2025 14: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 1utoUy-0006B7-Be
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:08 +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 7be14cd9-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:05 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV1PR03MB10653.eurprd03.prod.outlook.com (2603:10a6:150:203::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Wed, 3 Sep
 2025 14:30:02 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 7be14cd9-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NFGN6oxP+WQidmqNCIKto45VAjsA8dbbZoEUD90kM5RIE3Wp2naVdv9NcA/Ay4FJCE/0+ED9/mc0Oz/whymCjMQLXQhXo4/Zt6VYLXWQWPxMhzu8tOCXqVSRFH4HnYBAW4ZQpUxtR2uKBY6TcRFMCHW94fwg3gRygFmFujoLeF5s6zyuPGr5ipQIkjqYA2QhMk6U1kGzbd9u/2XxlOfUzbyufWLqkEa0Dhzhfh0MYa657wbWrH4U8rKciewYWWYF0KyTujOU2VAlZQPQn7YxWcdaroUT2Fmbb3FsSndgKLSHKnH/M+SKX4fgJmYZ5up6EeFH6MOmTqb+owH0xMP8Kw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MhvpXOFtmQxJuVRE9CJhtBXOBydHj3sL4ZVyO2LLm0s=;
 b=Huyq1+oVleO42W3rtzj2+M22ai2bC255VkTYoXDxzhiraeAtQtf+9rDIxXWYSzcJIMXRY+BqzFdhUgUxdG37579dB/8QxZV7ISR9z4G43ijMyiOtubLH25vThsYbtq1XTTIhjEEqPQSy7sQbC4at1hJ+v+5U8TYE94/pTBKtZLtTD+k7tom6/CaVgnCGTXOoSFwsaV/W5G2HVs2Odrq3Y+GYosekqKw7qq6VLBJKBoBBAv2nctA7c2hpZiONlc+Cm0TwC8PQlJ8368JYPVGoy6yz4iRsux9NkfEINLnGRSbXW0EunT5HojLk7EGF5fuIIxTCkatc3eCAABSqk57blA==
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=MhvpXOFtmQxJuVRE9CJhtBXOBydHj3sL4ZVyO2LLm0s=;
 b=sDUIPmBps4C20T8aEMjqaVfTNTOClpAIRlGupvArS48gi70Rz+V50SZdmo/ThXbjCsIVloDbvhxtZC3HbHXmUJ6hVBaD30fM3BIXo7Z0D1dFASRddizpZRlgP6+uDIb6stQ8db+OIfCx66h1SvUplQsDo+CH+/ebimXPhzqrDFy36oAqPY9OskQMPn8I9kEm9wKdYWtsVUT3H1Qpo3b/Ul4sZy322KsHp7mmIZXbdCwmdBMSUpPeVJz9m8rAPGejbdpvHbd9BAUO60KIAKs//BlWeqkAydD0TuFd0EsDeeChvndT+xSKMVN7u5+/bYG+o2z+exTfLkh7EhikZhbWaw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	
Subject: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1 eSPI
Thread-Topic: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Index: AQHcHN88f5Lxm2g89kebOYUIBUtDZQ==
Date: Wed, 3 Sep 2025 14:30:02 +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: GV2PR03MB8678:EE_|GV1PR03MB10653:EE_
x-ms-office365-filtering-correlation-id: bbec0323-2e59-4482-a6b1-08ddeaf65e9d
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?dwrhO3qhWArjWi1AqERgtBD8nCiw2M+82rP9VwUfz0mDf97duu56TaxwbW?=
 =?iso-8859-1?Q?uWSZ7oJEyrSKBRNVi1i3l+va/+hUzP/x7CQE2O+a03uY9FByTv4lq8QALm?=
 =?iso-8859-1?Q?w3XbJKflQvcj2besFj9Oqgmqg6G0EfMjAdF7OPP5QXzR8B0wLTpCLpCLTs?=
 =?iso-8859-1?Q?bGw0cz0z9jJbnrBayyLOJfki69NNnxHaA+9dm5In2d4ZWmg+sASpUqEVc+?=
 =?iso-8859-1?Q?z3cUpkj626gcn49movM/wgJD9tXsnYAqhgsJbA6RSrvNSh1xPdsLLyG1YO?=
 =?iso-8859-1?Q?qBXjFyl8HD5uEcu3zeMiClbdnRprl634xG1R8pPzu2e+UP6qTZM5dfViRz?=
 =?iso-8859-1?Q?DJZ7kxX/O55TMC7DL5L63W37dUPUJbrxnipq1ZxFyBrqSt0ihgHnCYULrF?=
 =?iso-8859-1?Q?d7Ljxrkl11+mWD76uy3hJtVZohbn66bvDux+dRsEFxPwvQaGnk3+Gqqh6L?=
 =?iso-8859-1?Q?Q9AXHnh/w1eobAe4zeaj8rmoDkx5l81sPQd6wFcvjUTDkw1nRYMGYigeGY?=
 =?iso-8859-1?Q?fZwH5UbD0mQJwnDqSbBZNUvv2B2SfdwVQPwNvZBqT7JPe9SuLxl4awbCsa?=
 =?iso-8859-1?Q?tkiHs/9beRCRjB7pqyD2VX5wsZTI44XvCTS6LNr1E6Fmsl4PoaQVQCfKOA?=
 =?iso-8859-1?Q?0Qzc+aNKHgQEMfSB44cMJXmWvm5dqpdNJoWCVws+j/g3y2DZVspV96Sfmy?=
 =?iso-8859-1?Q?IslQMgr6q0Cm4G3do3lVHoCrwPPEcY1jOsFr3R7p3kG5qZVKHBcv2jbmK6?=
 =?iso-8859-1?Q?xXLT4QZM5cJrPP2cGGPLedaNbRvXrGcJFGaENbD1CHxnzbi3t1gA5X54am?=
 =?iso-8859-1?Q?oPsC+d8h4RwzVOXou+8gXRSwZgE6FH3RYEQhbAwqAs4erINIb3lHlGBWdl?=
 =?iso-8859-1?Q?yF9h+x+PQQMt5bEkumG8RYsbkpGyjAovNcifTN9pzL36RG5kieAAiLvSWb?=
 =?iso-8859-1?Q?SaU7lpdzzlgxoBDoO3s7wJzkxMcPtetDm4nvFlZFKSqngndaxCiwVOMLCP?=
 =?iso-8859-1?Q?aQqOPzbkiORngwuL8NKUN7NHA6YIDZ8yb6my7ndQ64apoKBqa1V79tqpCT?=
 =?iso-8859-1?Q?OGiO63UtjjMOBd9GpPYaVKX2wwX72ItRZjsxtRfwMG1EqGAPKlNWwu0rpp?=
 =?iso-8859-1?Q?yL6T5XJajLAmfEx/1PbrjLuXqQhj3gEAkhNgWuofNgg/yQKOsquQ6mq/+c?=
 =?iso-8859-1?Q?iUGFw6iziiuS0Y6IUWSJ7dffNINp8nbWL3rZBTvMFMBS29QwOnzqYhdoSP?=
 =?iso-8859-1?Q?xClSBPxnwesP4EZ5uxyoEfI7CqNB3K0+icZFZvOJAbCeU+o5h3eMQEqCCE?=
 =?iso-8859-1?Q?D69jx4RAttQxZhYwsQmk+9rz2Br3CO6xouEz+ZTo3USNtetAstVPtmed7M?=
 =?iso-8859-1?Q?cAu5RYk2lUV/QlchiNoq2h0t0LCyFFWITzQygg87gzHOUyDHzjIOhbMDOq?=
 =?iso-8859-1?Q?0/LlFMvjiqBMMNKTzdrrVbQrnpZiHTonHBpAtfd23iK/9GdkQcLmxxGHTI?=
 =?iso-8859-1?Q?jFOO8kCt6TOg0efeophgYG5kV0SMY7NX3wZW/+cMbL8A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?L8jtYipoQ2lhCiINznNx14DUNwe6EbPXG7Q8bvl0ghzf0RKDEXYqIZytQp?=
 =?iso-8859-1?Q?74+0fUkFkJQoRm5d6U3LNzm7W7bDkeCX9NJAfl/R2bvxEn9wAWzcNC/QRf?=
 =?iso-8859-1?Q?pxll3LcaTzF3FFzwAH8HaMzg8AL8oPtFqFrx3yxT8W7AUGEHZVT+vgUq3W?=
 =?iso-8859-1?Q?sKWL1xFwPp9w5ONIIvhTDU6Xv1VFqipjwFVuQZNNvag7pWAFiVayaFl++B?=
 =?iso-8859-1?Q?AfDO4/bzNpU20eY9sZoY20KEuRNPBqgr1781USMbMmjH4qFbXSco7NNuLm?=
 =?iso-8859-1?Q?roORt0ujS60IiHENT06JbtISlME71YWp49GjXb0YWwG1pVTY6T28q/saJf?=
 =?iso-8859-1?Q?iGiw5obeesI+Dejtqp4c0JxmD41yALZbPmVeZPHr0DDoJkZ6OhPqp3vf0M?=
 =?iso-8859-1?Q?i9poZs2oZBP3BNWMStbnMuoJEW+Q2WCI0zp19vol/tijTVcaYA27bkodCe?=
 =?iso-8859-1?Q?HRyCJ168wdZ2HciAJ0m/MrhgbLHh0how6P8bctC9HMsu0SZI3EglWZ/k9Y?=
 =?iso-8859-1?Q?eJScgZF9Lq6mJIhf7RckAPHZWk2EpKISXl9mrb8bnK4pq9rO67vrdgDdPk?=
 =?iso-8859-1?Q?lkr0oSFB5TPRjkoi5AXw83vZP5x4ydAfbOrPvJ4y7vAIrp9lLGm2JKX2zB?=
 =?iso-8859-1?Q?jTaJX4RxZBOoVkTQcMKUSRPqh22Kj6rqJHT4ZJmrazkX/SBs6d6ZpuMKM9?=
 =?iso-8859-1?Q?qKBP966tjXAGAACspCHSZFrSoRnDuWv46vNe4UwN1MS9wKmDSWK9GttMII?=
 =?iso-8859-1?Q?6DU6YTQim3qXO+BZzg2rZ6+NHNEv4rdj7NyQbSR/qKnIn5ybBysVOx45Tg?=
 =?iso-8859-1?Q?IhMvU+x9zRYiJdQQ9NsMg1p6n0v7NrNY7x9OrDIGm3VnTuMkOwvxhxjPeX?=
 =?iso-8859-1?Q?M1gJEAf62q4g7CTtjogpgWcITY1/pS3rzeje54RS0ZMLlNPquTpP4OgcO9?=
 =?iso-8859-1?Q?IDvJT7UXl7i2riHVN/TmTroQdKJtU/hoEad6+jdWJOQy3L1o+EUYEUr0+w?=
 =?iso-8859-1?Q?v0UPTUesa1GD24IxfielMVsrJ1BfudgZWUxM+0f/JjsoJsuyCKsgcCpwDa?=
 =?iso-8859-1?Q?S5X/5BbLcktb/11j2Im4pqWjRohKf17Mkrn3uGKWh6n/x7k68TS3KpFJys?=
 =?iso-8859-1?Q?tX4bBS1yTwoHBYWnZTfEg6W9GfrDwWsUD1yR76i9edEsrKGHnLIH+xjxmB?=
 =?iso-8859-1?Q?h22bTwx3TMvPvhFTwmCA2L6M5kPJ96h0Bxwc71FfCK9VYTtWKdTmsNzfS4?=
 =?iso-8859-1?Q?Vu+Zky2sU4TD2DRpfycmjGcYzWZ64TKqfl2Q/Z1hzHiEMfTyr1XdlZ4YfB?=
 =?iso-8859-1?Q?1c5fpE9mj5KeTeJR0P61wQihOKG/DPL95GTpo7WI1aX3+rmzk+cjDYeCfL?=
 =?iso-8859-1?Q?h+xAD+mvcEzyegetRJ/DkUD9lc884QU+E6ZIL9OIj4sj4ZL+HjaOxQ5fUb?=
 =?iso-8859-1?Q?LZA+ADYXqJL7frCMpc8dlq6mjVE7vRG+MFxW82ELg/Neti3JfausT7vtCL?=
 =?iso-8859-1?Q?KlsHJfJPVdkM0XAiDe89hmFu+wdTMKiMIaRjFecUzThsxUo0p8rlGJ/C1V?=
 =?iso-8859-1?Q?9+VEBDeyD2ATMISPwofbWanLtj5w+HS98ugWZ05GTErh4heR/cX4DRlsE3?=
 =?iso-8859-1?Q?Y9EzAGr0YoyQoH48xtoC8mAVB60l29eUsBykdYrnlGIk2a5pvnYH3IQ3s4?=
 =?iso-8859-1?Q?okWQL2ke48XfhO5vxqY=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bbec0323-2e59-4482-a6b1-08ddeaf65e9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:02.6439
 (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: p2danOuDV2CiYRN85IQDiwG29FXZQODncQn8Q8PYe68AWQwc+7qPhzXJqAAn2LCSvOjSySBUxoAf3rnHCiKXrYPS/ezLpIHZ3IZjpuE7U7Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10653

Introduced appropriate register definitions, helper macros,
and initialization of required GICv3.1 distributor registers
to support eSPI. This type of interrupt is handled in the
same way as regular SPI interrupts, with the following
differences:

1) eSPIs can have up to 1024 interrupts, starting from the
beginning of the range, whereas regular SPIs use INTIDs from
32 to 1019, totaling 988 interrupts;
2) eSPIs start at INTID 4096, necessitating additional interrupt
index conversion during register operations.

In case if appropriate config is disabled, or GIC HW doesn't
support eSPI, the existing functionality will remain the same.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V6:
- removed unnecessary parentheses in gic_is_valid_espi()
- updated gic_is_valid_line(): it now verifies the condition irq <
  gic_number_lines() first, as it is more likely that the irq number
  will be from the non-eSPI range
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch
- added reviewed-by from Oleksandr Tyshchenko

Changes in V5:
- fixed minor nits, no functional changes: changed u32 to uint32_t and
  added a comment noting that the configuration for eSPIs is the same as
  for regular SPIs
- removed ifdefs for eSPI-specific offsets to reduce the number of
  ifdefs and code duplication in further changes
- removed reviewed-by as moving offset from ifdefs requires additional
  confirmation from reviewers

Changes in V4:
- added offsets for GICD_IGRPMODRnE and GICD_NSACRnE that are required
  for vGIC emulation
- added a log banner with eSPI information, similar to the one for
  regular SPI
- added newline after ifdef and before gic_is_valid_line
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- add __init attribute to gicv3_dist_espi_common_init
- change open-codded eSPI register initialization to the appropriate
  gen-mask macro
- fixed formatting for lines with more than 80 symbols
- introduced gicv3_dist_espi_init_aff to be able to use stubs in case of
  CONFIG_GICV3_ESPI disabled
- renamed parameter in the GICD_TYPER_ESPI_RANGE macro to espi_range
  (name was taken from GIC specification) to avoid confusion
- changed type for i variable to unsigned int since it cannot be
  negative

Changes in V2:
- move gic_number_espis function from
  [PATCH 08/10] xen/arm: vgic: add resource management for extended SPIs
  to use it in the newly introduced gic_is_valid_espi
- add gic_is_valid_espi which checks if IRQ number is in supported
  by HW eSPI range
- update gic_is_valid_irq conditions to allow operations with eSPIs
---
 xen/arch/arm/gic-v3.c                  | 83 ++++++++++++++++++++++++++
 xen/arch/arm/include/asm/gic.h         | 21 ++++++-
 xen/arch/arm/include/asm/gic_v3_defs.h | 38 ++++++++++++
 3 files changed, 141 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a1e302fea2..a69263e461 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -485,6 +485,36 @@ static void __iomem *get_addr_by_offset(struct irq_des=
c *irqd, uint32_t offset)
         default:
             break;
         }
+#ifdef CONFIG_GICV3_ESPI
+    case ESPI_BASE_INTID ... ESPI_MAX_INTID:
+    {
+        uint32_t irq_index =3D espi_intid_to_idx(irqd->irq);
+
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+            return (GICD + GICD_ISENABLERnE + (irq_index / 32) * 4);
+        case GICD_ICENABLER:
+            return (GICD + GICD_ICENABLERnE + (irq_index / 32) * 4);
+        case GICD_ISPENDR:
+            return (GICD + GICD_ISPENDRnE + (irq_index / 32) * 4);
+        case GICD_ICPENDR:
+            return (GICD + GICD_ICPENDRnE + (irq_index / 32) * 4);
+        case GICD_ISACTIVER:
+            return (GICD + GICD_ISACTIVERnE + (irq_index / 32) * 4);
+        case GICD_ICACTIVER:
+            return (GICD + GICD_ICACTIVERnE + (irq_index / 32) * 4);
+        case GICD_ICFGR:
+            return (GICD + GICD_ICFGRnE + (irq_index / 16) * 4);
+        case GICD_IROUTER:
+            return (GICD + GICD_IROUTERnE + irq_index * 8);
+        case GICD_IPRIORITYR:
+            return (GICD + GICD_IPRIORITYRnE + irq_index);
+        default:
+            break;
+        }
+    }
+#endif
     default:
         break;
     }
@@ -655,6 +685,55 @@ static void gicv3_set_irq_priority(struct irq_desc *de=
sc,
     spin_unlock(&gicv3.lock);
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+unsigned int gic_number_espis(void)
+{
+    return gic_hw_ops->info->nr_espi;
+}
+
+static void __init gicv3_dist_espi_common_init(uint32_t type)
+{
+    unsigned int espi_nr, i;
+
+    espi_nr =3D min(1024U, GICD_TYPER_ESPIS_NUM(type));
+    gicv3_info.nr_espi =3D espi_nr;
+    /* The GIC HW doesn't support eSPI, so we can leave from here */
+    if ( gicv3_info.nr_espi =3D=3D 0 )
+        return;
+
+    printk("GICv3: %d eSPI lines\n", gicv3_info.nr_espi);
+
+    /* The configuration for eSPIs is similar to that for regular SPIs */
+    for ( i =3D 0; i < espi_nr; i +=3D 16 )
+        writel_relaxed(0, GICD + GICD_ICFGRnE + (i / 16) * 4);
+
+    for ( i =3D 0; i < espi_nr; i +=3D 4 )
+        writel_relaxed(GIC_PRI_IRQ_ALL,
+                       GICD + GICD_IPRIORITYRnE + (i / 4) * 4);
+
+    for ( i =3D 0; i < espi_nr; i +=3D 32 )
+    {
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLERnE + (i / 32) =
* 4);
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVERnE + (i / 32) =
* 4);
+    }
+
+    for ( i =3D 0; i < espi_nr; i +=3D 32 )
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + (i / 32) * =
4);
+}
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity)
+{
+    unsigned int i;
+
+    for ( i =3D 0; i < gicv3_info.nr_espi; i++ )
+        writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * 8)=
;
+}
+#else
+static void __init gicv3_dist_espi_common_init(uint32_t type) { }
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity) { }
+#endif
+
 static void __init gicv3_dist_init(void)
 {
     uint32_t type;
@@ -700,6 +779,8 @@ static void __init gicv3_dist_init(void)
     for ( i =3D NR_GIC_LOCAL_IRQS; i < nr_lines; i +=3D 32 )
         writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4)=
;
=20
+    gicv3_dist_espi_common_init(type);
+
     gicv3_dist_wait_for_rwp();
=20
     /* Turn on the distributor */
@@ -713,6 +794,8 @@ static void __init gicv3_dist_init(void)
=20
     for ( i =3D NR_GIC_LOCAL_IRQS; i < nr_lines; i++ )
         writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTER + i * 8);
+
+    gicv3_dist_espi_init_aff(affinity);
 }
=20
 static int gicv3_enable_redist(void)
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.=
h
index 3fcee42675..3947c8634d 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,9 +306,24 @@ extern void gic_dump_vgic_info(struct vcpu *v);
=20
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
+#ifdef CONFIG_GICV3_ESPI
+extern unsigned int gic_number_espis(void);
+
+static inline bool gic_is_valid_espi(unsigned int irq)
+{
+    return irq >=3D ESPI_BASE_INTID &&
+           irq < espi_idx_to_intid(gic_number_espis());
+}
+#else
+static inline bool gic_is_valid_espi(unsigned int irq)
+{
+    return false;
+}
+#endif
+
 static inline bool gic_is_valid_line(unsigned int irq)
 {
-    return irq < gic_number_lines();
+    return irq < gic_number_lines() || gic_is_valid_espi(irq);
 }
=20
 static inline bool gic_is_spi(unsigned int irq)
@@ -325,6 +340,10 @@ struct gic_info {
     enum gic_version hw_version;
     /* Number of GIC lines supported */
     unsigned int nr_lines;
+#ifdef CONFIG_GICV3_ESPI
+    /* Number of GIC eSPI supported */
+    unsigned int nr_espi;
+#endif
     /* Number of LR registers */
     uint8_t nr_lrs;
     /* Maintenance irq number */
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index 2af093e774..3370b4cd52 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -37,6 +37,44 @@
 #define GICD_IROUTER1019             (0x7FD8)
 #define GICD_PIDR2                   (0xFFE8)
=20
+/* Additional registers for GICv3.1 */
+#define GICD_IGROUPRnE               (0x1000)
+#define GICD_IGROUPRnEN              (0x107C)
+#define GICD_ISENABLERnE             (0x1200)
+#define GICD_ISENABLERnEN            (0x127C)
+#define GICD_ICENABLERnE             (0x1400)
+#define GICD_ICENABLERnEN            (0x147C)
+#define GICD_ISPENDRnE               (0x1600)
+#define GICD_ISPENDRnEN              (0x167C)
+#define GICD_ICPENDRnE               (0x1800)
+#define GICD_ICPENDRnEN              (0x187C)
+#define GICD_ISACTIVERnE             (0x1A00)
+#define GICD_ISACTIVERnEN            (0x1A7C)
+#define GICD_ICACTIVERnE             (0x1C00)
+#define GICD_ICACTIVERnEN            (0x1C7C)
+#define GICD_IPRIORITYRnE            (0x2000)
+#define GICD_IPRIORITYRnEN           (0x23FC)
+#define GICD_ICFGRnE                 (0x3000)
+#define GICD_ICFGRnEN                (0x30FC)
+#define GICD_IGRPMODRnE              (0x3400)
+#define GICD_IGRPMODRnEN             (0x347C)
+#define GICD_NSACRnE                 (0x3600)
+#define GICD_NSACRnEN                (0x36FC)
+#define GICD_IROUTERnE               (0x8000)
+#define GICD_IROUTERnEN              (0x9FFC)
+
+#ifdef CONFIG_GICV3_ESPI
+#define GICD_TYPER_ESPI_SHIFT        8
+#define GICD_TYPER_ESPI_RANGE_SHIFT  27
+#define GICD_TYPER_ESPI_RANGE_MASK   (0x1F)
+#define GICD_TYPER_ESPI              (1U << GICD_TYPER_ESPI_SHIFT)
+#define GICD_TYPER_ESPI_RANGE(espi_range) ((((espi_range) & \
+        GICD_TYPER_ESPI_RANGE_MASK) + 1) * 32)
+#define GICD_TYPER_ESPIS_NUM(typer)    \
+        (((typer) & GICD_TYPER_ESPI) ? \
+        GICD_TYPER_ESPI_RANGE((typer) >> GICD_TYPER_ESPI_RANGE_SHIFT) : 0)
+#endif
+
 /* Common between GICD_PIDR2 and GICR_PIDR2 */
 #define GIC_PIDR2_ARCH_MASK         (0xf0)
 #define GIC_PIDR2_ARCH_GICv3        (0x30)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:30:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:30:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108428.1458585 (Exim 4.92)
	(envelope-from )
	id 1utoV4-0000m1-Ix; Wed, 03 Sep 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 1108428.1458585; Wed, 03 Sep 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 1utoV4-0000ls-F3; Wed, 03 Sep 2025 14:30:14 +0000
Received: by outflank-mailman (input) for mailman id 1108428;
 Wed, 03 Sep 2025 14:30: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 1utoV3-0006B7-0s
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:13 +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 7f6f6876-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:11 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:06 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 7f6f6876-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ojVnU9i0e/k2uXXUyTxvpi/l4gAUvlZ+zw7pqaLaWwPTCg8AE36ZHRELid3jh/Tj64MI/iMLl6HocHuPPJFXVtLiDNScy8gskFflsFGJAfhXMvOxhGlN5Ebo0GikxrVtQIvVsapSD4b3om4P/s62FHlHje9cJOS3BAI49M64Z76yAWebgQcTybr1JJIg+RYQz2kn80yGqOEZo/XcjgPr/9malhkuSSyS5AgljrlEPfnLd7APKcgmb7QL2HcahQ7gCmu6qS6rGVoBgJKzjLi849KePdtIYlOdITDBC2nN0dUkc6NPJ3B0KAfFp4ncaMFcpOo23MpECCSWS2jaY5VWnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kt+MrXSrWQoMopLt4vHzSv5xdwM8xeu2Xm0s0Iqfftg=;
 b=KfGUPfy2zBdeA6vi0N4zy/ERgTdRQJCsUttpz/qRtAx+hDa5t9AGJr9g/lFGQH86c9TBKIb8H8ZCOrD8xrk87Fxva5UuPyfaVxqA1Vt/N5lyiIzF+OniievDyQE7KmXKQbeZPD0A+OmLUicR/5vCTailPpgBhGd7ku/Djte8YfF+dkFVWIVJzHM2VcWxmqY3lI5XLOr0+qpR5XT9ber2J5wWw64BSmPVSoABp7/F0CI2/1qlVKpUl+BFFNbmNm+CXFqdvxagKFEQvJBf4+uK3AgpRGLXWw1/SNOUXijmSlxywfBwEUdRRzstPBnP/CQMVkZt0wZbtNa0FH4XP2bNnA==
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=kt+MrXSrWQoMopLt4vHzSv5xdwM8xeu2Xm0s0Iqfftg=;
 b=lb5J5+DsoXWKboLiagADShRQninZjQAi6PPwNsXYh983IqC+LCDvzZpC5HFl9m7CJx0QQSG2AfuF4hdY1PHEqIHGuu503drZDMcVblkChOfh+EaqDRUbE8wefIbO0zKHSsjjWyoGEP52r9lqXF5DG/AFIaqhpB5XyBIC7cbnJ6eeZg8jD2n428vzCUkv9RR1DTiQnVLiNSGfmu/SKj1JkKAPl60lHf3Sw/JLQv6DeMtcDFMTv2MBTvKKBFbIiWrgC9+d/Iq4muPpx5LNErFxHL7tHDr0NuSKJViDDQ3iPrUg8VmqKoIN2P3Luu622OYx2D9UHHCspYcl1/xHXhuqXQ==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v6 06/12] xen/arm/irq: allow eSPI processing in the
 gic_interrupt function
Thread-Topic: [PATCH v6 06/12] xen/arm/irq: allow eSPI processing in the
 gic_interrupt function
Thread-Index: AQHcHN8+OArI03lw30qaP2eYXB9+3Q==
Date: Wed, 3 Sep 2025 14:30:06 +0000
Message-ID:
 <8769853433e9f5edb9902d88b82f8ee922b5d319.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: b1fd2df0-111a-4a34-eee1-08ddeaf660a2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?OcFlTO9Ahvg1dE5ZTbYhzF95WwEe+BcuQmSWG+vodP/a79YniPH2/VdWwz?=
 =?iso-8859-1?Q?juE2mN/gGdw8ylwasOcRbrHS4dFjHFkWIaPvKwGX4+Rr56Pa2G9qKkBukn?=
 =?iso-8859-1?Q?Asre2JTLjhdrccnhlRMWKPyIjlrpaV9EU2mrU8slI0syUvXYc8PCtgokrU?=
 =?iso-8859-1?Q?QTY+jok/e0lPwkdEw1+EocQICFMBG5yhWdE7l5+aMg7+tf66+u8LdF0PWW?=
 =?iso-8859-1?Q?hUHOv1i9OO8JPZITx+w8gcFT3yCKTfrObyGdNzO7m27E1BmrqF18c0aOWF?=
 =?iso-8859-1?Q?nk2cPE+0kZaLGijqKacu9iCCdAlmPOw1qurWuToBP9e0nopGKu1g2Or7y7?=
 =?iso-8859-1?Q?AzuBJZxAaE2frFK/KA+9KHvUpu7wbaGmiXRCuVorse5cExxVUGgJy32anH?=
 =?iso-8859-1?Q?Pynm1watlKiRljl+vgDUPgLw6pXRW3qAR9yaB4D55k9f4T9NKaWLF53xqe?=
 =?iso-8859-1?Q?w5kkZSAXrX+7Gygx4es1jR8tvI058EeBG61tuvg2MDWclNm87tiKIrcCxX?=
 =?iso-8859-1?Q?yH9fk9neUiZvqHd0ZyAVv1fosJDgEAqSBBzwANxZ5QR6PjEBsxBzT5onUr?=
 =?iso-8859-1?Q?K843zFK9kzkCNMEFyQLhLI8WAqAGSZCX3wj+81+80OlsaoHWZrLQQ7eXVZ?=
 =?iso-8859-1?Q?mHRc3FhIbr5QGHZRz90WuBCIbJz9kVnMjJePkFqR1O2SjuTWwRznc16n09?=
 =?iso-8859-1?Q?rsGaMUhlscUwn7vLrKzFfQAljauTxnf+QVTInH0N/ll+uZF7QH4W/VfCF6?=
 =?iso-8859-1?Q?E/n9Y9AswSVwictJzfJ5KZixPuhWC+gXyvxbgRSQj1wWsDOcieDB6vc0Q+?=
 =?iso-8859-1?Q?SFhp5ffDHhsPs2Gct2sORuRNMfE4V+n3qQBW9EPbQ4EdQm/1zw2MAewYzv?=
 =?iso-8859-1?Q?E1hzW2mZJjOUxddCxK4aIhuiQCq7Sd4UFfDBvkqww59NbgZIYF0o0gNTni?=
 =?iso-8859-1?Q?UNqi2NqCwpcF549Hw1P0x1KAFm7pYHhlpSJjYagq3dmp12VWuHf7fqOfhf?=
 =?iso-8859-1?Q?JJaXARZ8UDegsHngvSfDOZ5E0+GjeCpSH6NjBPCs9y0EXk13HxRUo3qJ9C?=
 =?iso-8859-1?Q?FNZ5aYrI8YY5rsS84hjU1kHSZD4YwVrSHI1K9SxRUKyV8heKfOULqjSWAs?=
 =?iso-8859-1?Q?Aey+TozKLavj2JPbNpHhaIZLloEsj8eZovAEURyQvI9V2zGvxlQydvjxI8?=
 =?iso-8859-1?Q?0EdcX5D3SLIA6vnDlTDXH/dnV0PCAOd0yBG4w90U/PV9l0sgaTTY/ySek7?=
 =?iso-8859-1?Q?mbybumtqyse8T8uvQnPQSHh7J56/sjCKcK9QjNQFDWJSvNbni2cpRo6rMi?=
 =?iso-8859-1?Q?Gczyp8GIJYrPmpF3kVaXTrf8FnZxuCnrO+IqKCzhbVB+N1k9ADV9nDnlRO?=
 =?iso-8859-1?Q?PmfHOcee7YPwsjacYymNjGeXKFs1iMuXTjc4JVlGNuk4cuK6dkhzCh6UeQ?=
 =?iso-8859-1?Q?TKAMmOah+Hl3x4ANNUM8qJJToJYxn/qa3a2NIbyZj/D6bIa8zg+PAicDdf?=
 =?iso-8859-1?Q?H86kKmpa+8Nec/HB1RHrblWVMpjkEEPZ2cVdvNLwfpFQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?854JDx3e53BdeJPMshHgykj/C0sWRWVdmmgdPuj87pxCxUZ/CVQzzyVp1C?=
 =?iso-8859-1?Q?ffat+Fw1b+xO9dOMYTn69Aeq8nr/drJ4Q/+fKoViYDeb8CZaU0/0z4uBTp?=
 =?iso-8859-1?Q?vtNNb02vl2rqSuTfB8NILZcXDPPFY6o9eTaFPSanHoMTtn0XCzcG1iixBP?=
 =?iso-8859-1?Q?KD8K/4VmsHusCfk7VySpGviMi8WqrJ5sdmzuV9n71iHG2O+PWSUyBM50A9?=
 =?iso-8859-1?Q?k2LC4JUP7UTutlYrC/Dlikrk/N30GaS7S71arZKg6uESQNOsPV7Vr8f+kq?=
 =?iso-8859-1?Q?/1gug/XLuJWP2D4M+shDwxkaWfF64Kj9BF23jmv2rHHkA36FJxryo14Pcj?=
 =?iso-8859-1?Q?d+BapkLjQaeKMb7lJtcHtWaXrUr93sH+TjuRQiVBFigr3m3VQwhPdVELR9?=
 =?iso-8859-1?Q?LbJBMInYPZDnsprYEFOlj9TIdFvOs9vAqwSmTLH0qfJbpXd+gUHXcv9RaX?=
 =?iso-8859-1?Q?UrpZhtckBXJFOkNPJJ3nVL8VhZWFuRgnD9smD0ntdWILPaYfEfvwgEYJ8V?=
 =?iso-8859-1?Q?7prdjatu8a79sEpc/730vcFyK1/r1iwNrfDpjl/ChbgzXjHAAa/bDs+LrK?=
 =?iso-8859-1?Q?3cMbCAW3GkglM98MBbPe9RY+BvUEbN+kt9Xh/1xkLqpkZl+EmPPrQj1Yas?=
 =?iso-8859-1?Q?HPMzmOKxIUEmKB+XevJzV2Xx0VbRD8gFOa3iSqBWX7yOPx06rINl4V/fKh?=
 =?iso-8859-1?Q?7si2w20H5JbC/saqoeYlxojsluDogtCiD1JVImD+XvvEHduuHO+oYjUSgV?=
 =?iso-8859-1?Q?RlsLCNb+pN27dj62TfPpsyZOT++KT+QmpynDZ3pZjrKYnB1oYpdZxzGMyK?=
 =?iso-8859-1?Q?PHPRVPeXK4Z1a9Duo32qj+kZlrAJ6Vtl1Kmu90olON/92NshGfeWD3gvke?=
 =?iso-8859-1?Q?/lbIEdj6bCIrNjdwPiYHYNxvLNeAF1RIWPtnOsO+1Q1hEe/1eU+p4TwTx0?=
 =?iso-8859-1?Q?xmuq3noGelkKvyYhtlDhgUtAhGToTmmdT0yn7EFzS2nT+KWHGN3ORyvmXv?=
 =?iso-8859-1?Q?A5vFWRrcQz/g/wJN6dnUOo5MhKPfg5ax1UWP/wqoS6wsvFFJerQdmnjeK8?=
 =?iso-8859-1?Q?e7oR7yDiLaplbBrRDLBVV9VQR6Du84keniif19V5wmsGyaYOos7IFFHuxr?=
 =?iso-8859-1?Q?2s4CwzxLswHQz2hF5RKTuIwu6J8JsHAooxSxrwGknL1rj9S5Cg9GfuViBT?=
 =?iso-8859-1?Q?HMcrAjfbatkyhyWePsuL/iLn0uBxX7jureOonmzT2Xvmkqm0+U6avzriFV?=
 =?iso-8859-1?Q?zeAhACXUMAVoTv+B2wiHEizEmnA2qTi+6PGiBQOWM354Rs8CTWwPD5DJ5w?=
 =?iso-8859-1?Q?d1Rh5EOUVFBHupM1sHu1NNuggKKRWMYQCNz9//SaMqLI7W6CwosFIEa/EW?=
 =?iso-8859-1?Q?H5cTA2sFx+Rk7Ol3R3SEPTa2tCevd4aBjpxqUQg+6PKBaE475aY+xsywJR?=
 =?iso-8859-1?Q?vm+2tUI/M8MbnpVz/Jly4iE9BbNHcm1HHaU89mVfbCd3IpoxcHS1C4qslH?=
 =?iso-8859-1?Q?UQFYD9SXMOZPUq9qcGr4WHTjDTA1gWwS64fY/6dQc/pCGqI/3cAAht4cO+?=
 =?iso-8859-1?Q?rEg1ZzuJfC3ujv1xkKN4VCFrR8rp3Fsc81ctrnVOeB8Lm6XDqO3jHLSrWl?=
 =?iso-8859-1?Q?bcviR2qXeeRKjouYLqKTpCozZ8JGbnGqm9dUP872UfE/eA0Q8k7PVTCoup?=
 =?iso-8859-1?Q?epj3LcL5Gm9dbOIpvyo=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1fd2df0-111a-4a34-eee1-08ddeaf660a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:06.0589
 (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: KYvbarSqhVTJraaAcN8XUUECdKfGyxE/Ji8VDlzJ+Dr361A9MK5Lne12Hhyd/gJhAuziVHSG7/cQIpIo4DCZ2tcgSxt6g0Lzfo7K/OfBFxQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

The gic_interrupt function is the main handler for processing IRQs.
Currently, due to restrictive checks, it does not process interrupt
numbers greater than 1019. This patch updates the condition to allow
the handling of interrupts from the eSPI range.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V6:
- added acked-by from Julien Grall

Changes in V5:
- no changes

Changes in V4:
- fixed commit message
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- no changes

Changes in V2:
- no changes
---
 xen/arch/arm/gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 9469c9d08c..260ee64cca 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -342,7 +342,7 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_f=
iq)
         /* Reading IRQ will ACK it */
         irq =3D gic_hw_ops->read_irq();
=20
-        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) )
+        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(=
irq) )
         {
             isb();
             do_IRQ(regs, irq, is_fiq);
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:30:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:30:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108455.1458600 (Exim 4.92)
	(envelope-from )
	id 1utoVf-0002OI-8j; Wed, 03 Sep 2025 14:30:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108455.1458600; Wed, 03 Sep 2025 14: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 1utoVf-0002OB-5C; Wed, 03 Sep 2025 14:30:51 +0000
Received: by outflank-mailman (input) for mailman id 1108455;
 Wed, 03 Sep 2025 14: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 1utoVF-0006B7-JW
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:25 +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 86f99437-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:24 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:22 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 86f99437-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EDApSG4SU7AcrJzS0jjZc4COVOUrs82CAJvL3o6Jkor+n9EEr+KOOtqdfnVipkaAIntDkA15SJeileGvmpzBA/xtvbra3fFovJgWMeC3sZdpykpOTcPvNMnwHJR9LdS2UTQR0Fmbj0efUvnoHDddszjOvNwGyxNGl8t8SOO3hEFljqDC53pbBc5hUgqmwOZAYYqCkSSt8Owolhmn+x5LLQIIGj65KHaQ9Q9VVZqFdUw0AkBXwqDa2W9fTOyw4vSvAYuPN5kzkD2O9yPwSfY3it9rG460ej56dDwf4mC1N77R2ssmLU1BA1gT15jNb4U0D7b9AqFt7ct+X+t/9RkoSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XyahV/BpOkGFxSqvav5Se24ucuKX8ic+JBea+qL3ihg=;
 b=kOmfXA347k4Hj1L/L1BrRxRnMd17+pRV3ofEBSVaoCh39HbtdBZfYQnFvbOlMbPZ5G+ORs3t6T6OGX0en7yD2fpgaRkjof1uTWBE11WmENjAX4cwl9GcTdW8dp8rbxZJxzvz7kpMklECrwD+7sWh+BTe2KoACnuySm9D0XvZ8OnW8evOcV4IHZP8JJP1E3w1TH0baUPN/MgyezGLBlQeWJHvLtUoXlBkwkowcOsKAOInj+2pqObIQYObp2n+fwm/AiY8g2WpDwvbIx8tF5K1NnH0XBQVXvHBSvhcP3xGACWNv92LTh+gq9V+Bcy0pOrifks38t6/sn0CgBc5l2Qw3A==
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=XyahV/BpOkGFxSqvav5Se24ucuKX8ic+JBea+qL3ihg=;
 b=Pi9iZ1wxsPAoJvpD7dMSzCz7YetvMqdzhxV+pI0dk+XPVZdxmb7wrmvrnaqcOzf643Hf4aGXLF5J3TCuHhb+qKLi5UmNjQU519TwZQ+2Al5SgKD9QG0PEN1Lv9t9Cg7WLbDeHXeeHEVobfKDhTTZrwJ7UjyLVXUq35WHiJjc1IDNmgxus6QC7oNdMNAkeNMRPYSjaFfccGvDYfm84GZtjshOHetXoG7Q7InAnZomsZ6/UoeZBZX9JrA8+hhjs7FCE3v263jx1dTmXi9FZ7xFL9GgkvnMoOrqXq+VAagFZlRuG8IFdmXPwMgYNNwjAdj1CRWlwjS9tJJDOiMZg0C4Tw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Anthony PERARD 
Subject: [PATCH v6 11/12] doc/man: update description for nr_spis with eSPI
Thread-Topic: [PATCH v6 11/12] doc/man: update description for nr_spis with
 eSPI
Thread-Index: AQHcHN9HOJL8STXwX0GL+HONwVVLYw==
Date: Wed, 3 Sep 2025 14:30:22 +0000
Message-ID:
 <3b452ade4d7d2fdbdf159e8ff67ec49724ff4d38.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: f75164df-1c39-4b70-f501-08ddeaf66a71
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?fFmRwlUM/vxLeLcwsL6hf8WmHskZDZfEJJnOAMMJ14cAPXgNYX4kXgfcbO?=
 =?iso-8859-1?Q?2AnCAN47rOJ/iwJjBGuPX2s0ZckMXjIjCSuwgQZf6zDzTrrrrp969q+Qq1?=
 =?iso-8859-1?Q?RsEMz0J0JXPF0Ic0EYhyRXCTaPExaypFsu5FGfBM7UVAmLJ7ogOLVQyPhL?=
 =?iso-8859-1?Q?tYqqXzIkhWIPl6d7JGv+4hT7TU/tBfmuZetYZUSQ57ekWg/pnsK4aopg7F?=
 =?iso-8859-1?Q?EM7qIAH3dx5ZP0EHEK75w59lWojtqghjiIXXhfB5izqHPBObdFBfr5HnLr?=
 =?iso-8859-1?Q?LFL5hVZ/C9UguiN2QasDnO5UsMVKt7+bvLZQwHeSe9Rf8daIS6zzoESEl/?=
 =?iso-8859-1?Q?8eeX/jVDI700M84GaJwRT4F2YoxpW9aOE+ln039mbtX81e5tAXY0s0B8DK?=
 =?iso-8859-1?Q?mdDkvSd5NPqPrxxnf4bJQ6fIsQkTniPa12bqGanbH0oykvQdj+ayROw0pd?=
 =?iso-8859-1?Q?I9k5bQm22kY7TMW04u6wo2B6ofiFtbFqNdeDwj5fwrtNPIEmia7TZYXkGw?=
 =?iso-8859-1?Q?e+64kI57WSR632v0/D6cHzCNiWKhchyNPCsp4Ryvi2++ySQWbtqW4H+my4?=
 =?iso-8859-1?Q?d1RuOLXWQ4g7169xP+MypcUpS497EOI2UvlhkYRwh8c5CKSm8ixqzVe68s?=
 =?iso-8859-1?Q?jUvghP+8UxwqcPpVW02kwu8t/lUNwhUvzIxPIzs6FGe4sPFBWqWFcDnY+x?=
 =?iso-8859-1?Q?ikPL76UtJDb80Ol6W5Pr7JnZwATU/Sbqny/lNl7Q51nzdPpMLTbeXXo119?=
 =?iso-8859-1?Q?k1tAdEgxEtoG2pcUVW697Q8SVIiYHkxVeCvYsGrYT5WlHeRbnDesc0F+9N?=
 =?iso-8859-1?Q?kjGfxcqko1VQpHgcR9zlHDyE8OlC88N8Dy7NIhvEznfpX1j5/fxbmXaC/W?=
 =?iso-8859-1?Q?YeFpn9xQnbygOk7vRXIONWfJspuBXS7mjUm+ijErmHJ/BK650EegXAdjQt?=
 =?iso-8859-1?Q?2BuOoigg9yOldRTIkIG0lWnQheeWowycvjTZ1LS7L4NZF9aFqULpfVG6n3?=
 =?iso-8859-1?Q?4cI7Hhl8udn0kAsBziLPL7ujHsO8cH4XKCAPuje1onDhp3k0MyiyIk5PNT?=
 =?iso-8859-1?Q?akrBqBmE1Qyya0Os98+bvvkJV7YrtXnswUXe41XByhpUheRzPsYz7WlkVO?=
 =?iso-8859-1?Q?yrW4Glre9jUa4Vf72jG/qdmlSvK3a+dblo2GHKQL78knTn1xM0xlbgANmL?=
 =?iso-8859-1?Q?Z/45BTF61zdMjHodII1ubxZvGXXGXHHdoQzfvGBXqb/6Zt7pjn2DI++x83?=
 =?iso-8859-1?Q?u/GpcAHVPu3JJDEsxNTTdQIs01OKgLeSELpiJIdB7aFo5XNhEwltB1p3pi?=
 =?iso-8859-1?Q?BCAsZX2XgtxQO+8R07SemlHXf287OTtoKVR3QJEnrqzVg+rIWK8nPKYmr2?=
 =?iso-8859-1?Q?oipYONbXC1QQaKtOrmdyZWFdmltFYhDOrOYceI9yECuc+Wkg7+aFSVxJsc?=
 =?iso-8859-1?Q?d+aQAkzuBpdZB/8ObZ8VArrJPelEkcG4qtUEfJpUT1oYXxKpVmbrRplima?=
 =?iso-8859-1?Q?n9XAFW3LmJCuJQpa2N6ccA14AJrReaMzHlqJCriYjSnZsazOLfK0lTnquZ?=
 =?iso-8859-1?Q?0zeu4xA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Chhi/m0LWWsyUAY8Ldd6pjDJ8em0ii/mNzEgb934aJEQYPHEZPrJ2Xz+dv?=
 =?iso-8859-1?Q?RfzsMjXsVoJf1LExcMXhiTl3AC7sHiUUIQcMJbRBV1axwQHn4RG4zEN+Gs?=
 =?iso-8859-1?Q?bRKjoubs2AvhOAjCJjV1XfJzoqz8cJ7WsF9if6e7+OGpWtgtJ7It4aKfOf?=
 =?iso-8859-1?Q?rIDd6VIZuVCKnHdvZu+H1sJKqJQBlSgFHLIfWgTM7FAhbo8hbCKKuqwcgl?=
 =?iso-8859-1?Q?w3Si3bQsiPsFqwRDQ13zNKjlLQEv394p6WZOG6EFbua0MVO2iLIqNugLzR?=
 =?iso-8859-1?Q?JZ3x3xWmu1eSzhU2o3kKYXtzJAmtjVoSiBQi1gSdCbuUptK5sq4lmlOx42?=
 =?iso-8859-1?Q?wp8CNZfYZlGifuJtZ4N0Camy17ACpeGKGT7ODgNAqm36EVIsxumrNcxWK4?=
 =?iso-8859-1?Q?mZddurOm303+OZZAdFhYOvzZ2XD/kP3JF4LATMJgvZTPqWCoNwVEFU9BYZ?=
 =?iso-8859-1?Q?32yml2awoKiDQ28zCwHeCo60IDHJgIYFaKw70ttbmwRGMxapsW0ARn6lyB?=
 =?iso-8859-1?Q?pu/chy3AyqpQsnBbcE0UUWoDeSx7az0nlFBzNwwhRySbOVizI12cEcSTYp?=
 =?iso-8859-1?Q?DXc8koHxXD466zsb2+IJFXgEsvConKBkgggeErXQm04nbo7mti9F6wf211?=
 =?iso-8859-1?Q?XYgLCgY8bIb61QQSQisi0jY2Wx8KleB6fmT0wHYBFak2M76S3gFIlNTDPh?=
 =?iso-8859-1?Q?8f/nIlk5Jn5eaTpLEAfoE56cvtId/nnYsNFGjeISuGVIy5rUxc6n+06rZv?=
 =?iso-8859-1?Q?6mzHjTIcickZ657+MfJEaXH72ZpRIBaoGZ9siaNXkOrDOcmfFLbvr1ISmS?=
 =?iso-8859-1?Q?DdNWZJbqhJ3uBNnzpcJdPVVTHXuDubzLbIOkT5bYMvTzoRrGU0yu8PsELo?=
 =?iso-8859-1?Q?Ea0xhIgKeMbBoYJsw/hL2bfufFjaqMrzIFZ5ORjsalofpeCB00qKobunAI?=
 =?iso-8859-1?Q?Mfk2uLlhTry47PhBJpjx6scuEm7hfVX/POhC3q/G76qB2zTO3DKhfB4THg?=
 =?iso-8859-1?Q?gMHgkLG+Zkn7jQab45D+Wqy4njj69TuJVmzSld5qkkCS6gNahBMXoHF0h2?=
 =?iso-8859-1?Q?iWqhHl7DjTrISLJTssLXSdfqCtlal2LpF+vK86H0jfb17NuGJCalxGeAyb?=
 =?iso-8859-1?Q?E+RM9HC6kejc5KCidFmAC2CtRocdQdFkAT7zAYzs50pNnmg1SqCt/EvZD+?=
 =?iso-8859-1?Q?rf6d3sFWoteWWMjfOINODqNZK73UNNTjxqdixS+1LJWmL1r0KONmKhU60b?=
 =?iso-8859-1?Q?BDk64SG/FZPQscfk0dZDTvtRbqTYzl0dt0R5Oc5176Uf6vLTDXDfC05ODX?=
 =?iso-8859-1?Q?p91gLJnnRUQ0j1URlx470AxmT8rCgmlZk+VIHKZblyLVGPNBhjpNzdv0iH?=
 =?iso-8859-1?Q?iCWd8YV7CWxuEjasrYe9tcZuAcYqKaF9S59OYTorclAWCcVqTlnoYIbN61?=
 =?iso-8859-1?Q?wIJ3KqIISAds0D1xan+NtHA+FMHGCpefZJCx92SSEuAf4ldfQOpOKXE2W4?=
 =?iso-8859-1?Q?FwOvfWl0kOPnsKnJAs27oVl1OkenkDevXZe1qE+R5MKOKiQHLGpgw0/OKT?=
 =?iso-8859-1?Q?LsG004SSKmKGBR7mVvd0Zdy13AAkdz0uoY7A3WXikiV6aC0SGrOHFHSrvg?=
 =?iso-8859-1?Q?Rhd1C8Za1TP4IbSkbJBWFnU5AwGufi1azwf9FdTYxqK9MVIvv2mM4lV8k9?=
 =?iso-8859-1?Q?tasb6OSd/MJlxaigWAA=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f75164df-1c39-4b70-f501-08ddeaf66a71
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:22.5057
 (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: ae9NEvLx7GO14hDVfnhZekj1ROAr5/c8pZvMD0gnMfQL8zMrAhSTBgYd0dbteM5o1L0ZRR6v9gP02YrH3FduarS3xMReeVFTqK7fBUpXzvc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

Since eSPI support has been introduced, update the documentation with
the appropriate description.

Signed-off-by: Leonid Komarianskyi 

---
The discussion is ongoing and can be addressed in V5.
Clarification is needed from the maintainers.
Link:
- https://lore.kernel.org/xen-devel/87y0r4z717.fsf@epam.com/

Changes in V6:
- no changes

Changes in V5:
- no changes

Changes in V4:
- introduced this patch
---
 docs/man/xl.cfg.5.pod.in | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 5362fb0e9a..292ab10331 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3072,11 +3072,14 @@ interval of colors (such as "0-4").
 =3Ditem B
=20
 An optional integer parameter specifying the number of SPIs (Shared
-Peripheral Interrupts) to allocate for the domain. Max is 960 SPIs. If
-the `nr_spis` parameter is not specified, the value calculated by the tool=
stack
-will be used for the domain. Otherwise, the value specified by the `nr_spi=
s`
-parameter will be used. The number of SPIs should match the highest interr=
upt
-ID that will be assigned to the domain.
+Peripheral Interrupts) to allocate for the domain. Max is 960 for regular =
SPIs
+or 5088 for eSPIs (Extended SPIs). The eSPIs includes an additional 1024 S=
PIs
+from the eSPI range (4096 to 5119) if the hardware supports extended SPIs
+(GICv3.1+) and CONFIG_GICV3_ESPI is enabled. If the `nr_spis` parameter is=
 not
+specified, the value calculated by the toolstack will be used for the doma=
in.
+Otherwise, the value specified by the `nr_spis` parameter will be used. Th=
e
+number of SPIs should match the highest interrupt ID that will be assigned=
 to
+the domain.
=20
 =3Ditem B
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:30:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:30:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108452.1458594 (Exim 4.92)
	(envelope-from )
	id 1utoVe-0002L6-Vn; Wed, 03 Sep 2025 14:30:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108452.1458594; Wed, 03 Sep 2025 14:30: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 1utoVe-0002Kz-TD; Wed, 03 Sep 2025 14:30:50 +0000
Received: by outflank-mailman (input) for mailman id 1108452;
 Wed, 03 Sep 2025 14: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 1utoV8-0006B7-9i
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:18 +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 82a7cf84-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:16 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:14 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 82a7cf84-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CRdIpArj430yq60+pGINacBxwKTTnbC/MSWb04K1xPDE/xNFrKDSf2coYqYnaUXfEfhgkUtK/KdvzaSI3zcBQ87tNvOcIcSexNgQweU7N/7QMCJz68yDY62Jl8p/O1Rg7cwk8ykJj1a19qZaOV7+eHUYuhdThahbRZK89ZkP7Ji742gwMSzO3vJn4vi+PRHOztnt2sXN/DodGQaWcI1Gi3grTR5P9VsSV7THJ31mX+O3FygaVvSgX8BGt+lHUBvfvdnPI0vLTmk7fKA+/A+i3D01M/7BbhhkPtpbLVPqSPIvkvBT63jy+62Zkw902Y9CkMbFGamxBh3qpi44gwssVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pAmPb+B0JvN5LffvQELkgNDtjp5u1iEl1UljJXn5Cug=;
 b=scdkC1ISq+Ye1X5FUstFF+dSh9wdZoP+SvrGnzzqRxral0nKG7hD0dExVQlHWAnqwoKPwKyoFK+/D/GDCuIwzWv4XwjHJp1ga7vRk/36k5TOVmENhJG+mT9S+zrIfcr8sffIPx4WTYmDY2+ptobVOGu2JMy8YdHPDNLSfBLut1i1OD17p+73+Rt1UhKRmBZpQMAjR9TutoC74lR6pHar3Tsx6Xtd9Hr95o8XiqyOXvqnmWmj31w4cjkbAIiycLWrnw6BWz1VCMf+z2OLQ6H7A57yHep8vVNe4ke+GXdm5fVqY9bEurw8FLTCHMZLdADLN70TTWR+/zcIhajJO2QbQg==
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=pAmPb+B0JvN5LffvQELkgNDtjp5u1iEl1UljJXn5Cug=;
 b=OT6bVKjtVQshAeR2edHZi8O1A3ZhL4GpnmC1SvkWZAcevinvenAsyYxhiKp351D5g+MtgVJv58xth7JUo6hA8nehTVOgn5j8wJE9850yb4YH57465ATU0a5/KINcX8QaY34NSWpFiG6X8dAhtscgLGgDEQi8DGjw8q/QkVkm/kDQ7lMoMxfD9ZSIUCcOqM6+y98iwYOtYZJC59LP+ko2m8Xv7iQTAsiHVj53bnGPyd07zobh3FmU0io2li96c0bIiywyaW9jd4wY0mPBHamk8HS2Q5Atny4w4WHSD4dzzWYwVvOGaMu2gPzfx0w9wAFbR7m7N/nHGEPcbIvqSqZJ3A==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko 
Subject: [PATCH v6 09/12] xen/arm: domain_build/dom0less-build: adjust domains
 config to support eSPIs
Thread-Topic: [PATCH v6 09/12] xen/arm: domain_build/dom0less-build: adjust
 domains config to support eSPIs
Thread-Index: AQHcHN9D7Q32NTwVrkWcahBgGhYi8w==
Date: Wed, 3 Sep 2025 14:30:14 +0000
Message-ID:
 <8c37ff7960ffb334647a6af07e9c878c1ede3b57.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: c502f03a-e546-4b6d-588f-08ddeaf665a5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?/ibMpheYZepxDCH5Zi0nTWqY+SDWz0YUkJgst/diDZv8KyKjhB0/eyIqy7?=
 =?iso-8859-1?Q?pom0roDRVMb4I7ecKlmkKRZmRtDrKg3QvbR5M6Xd1fHid0lYhtLC7tg4lQ?=
 =?iso-8859-1?Q?G2OeaXvWevU/pudewackski8GKTkyzDGEoNhrd/ECe4lBpxMUkhkEgEOy2?=
 =?iso-8859-1?Q?bUCxER98G04jcNEcI/cJtVidYhrJ8AQphNOh+F1ipAFh9oNY8mcyminXA0?=
 =?iso-8859-1?Q?wg1KqaO3vCamQE3SE26WrHECrdBzZknl0x9A7o6UKsVwT+UpVVKM/QZEPG?=
 =?iso-8859-1?Q?hQ62pP9CRBsa0msPoXeXw3+vhHHu63vDdEFtJNiOib58d4QaX7eW4DHdG6?=
 =?iso-8859-1?Q?wIGz9sz0yYVObwjuABq/YzcG5sOmpPKVJQ4StFJjUnHdHZCotp0Tm/V250?=
 =?iso-8859-1?Q?fQM4nrCf9qFK3ODAv8IPyLzoHhaC4XIg/aK30pSOG4TT/O8IIWX+Sb1ReG?=
 =?iso-8859-1?Q?dj4NFkTKOa4QRR7a+x7g8IqH0HkOBfED1W/o1sJq0FTbSnc2nsOE5RNlnL?=
 =?iso-8859-1?Q?mUaO1tkHfwt2KPhLCdYSWaB8kWdjEiFjHp69hYu071BzG60hDQHtOJ2FN2?=
 =?iso-8859-1?Q?+bdtK0yfOrtNxlkcmjepUo+3QBbA8H0vXTkUD7Xsat4PEOUNyoNk5pLSSa?=
 =?iso-8859-1?Q?ZLMu7zA2kW65e37o22z4xDaC0PyYTiwuX35mNgog0hKXihknkPb/i+EqVk?=
 =?iso-8859-1?Q?iXf5a4YE05HeTKA4D98BdjOo88q2VOiMOdjpftdW8NNICI2IFMTFxmgS24?=
 =?iso-8859-1?Q?y+f2Z9p/kgB8QuPcWWpw/MH+8fSsfnY7SvkKFVMd98QdlXwcUiNP023/NU?=
 =?iso-8859-1?Q?riLok+3mfyrvDx1oaIJktdbnWjRQMEk58Lr6zjI+ZT1aElwm2F+sEkGmFr?=
 =?iso-8859-1?Q?XKWYMTQkswPU/1NTRCQ/n13Ji91BsLnCcWnjTMbvCLUEiXxIJMOwWKwAu3?=
 =?iso-8859-1?Q?Fp+l8TmhCaEwaDUU9gCGvVLNNDBN5gaCZ10BYzQ4+S+O/vIh0p0c3PocIV?=
 =?iso-8859-1?Q?djSoAbZrLYltYYgCtI4oBO6rndzXogc5WQrrrEWm8y2NgP6YfI+866Q3um?=
 =?iso-8859-1?Q?HCE4eww9lJNVDwizKiMN1OqgM6KevNAzr/VP/CAG9Gu2RKId2WvoWCdU6A?=
 =?iso-8859-1?Q?cjsJayLLxkMG6IUb6gwa+m1CoCswxghvRkEDhpQ9cwQhk2T4BRwkUaKiah?=
 =?iso-8859-1?Q?klAQ15/FGNsU6jBsGYgbsN5T7B3yq8dmiONDjBFU/OSf7pZjdLQoEgaFUl?=
 =?iso-8859-1?Q?h5ze2Il5hp5DqigMOw8FvcJtvU1FOJzBhOLmFpHe/p9QsrRk+2t8cE3dIc?=
 =?iso-8859-1?Q?Vlvh3z/Lk9Er1Telo4aPWpZDJ6F0ksD7hdmb2cTc84xHAxJ+KYCyjphKjr?=
 =?iso-8859-1?Q?+H1fCZXAFQvfHAdW9Gbv82/I1I44TqcMO7WvA1uhpIPcdcjf2CUweA3DPi?=
 =?iso-8859-1?Q?hmfTX4LFG39tKnc1uk0qw0WPMCR1g5YzyuX81TXH2SBHKjfbMRD6Gz97pP?=
 =?iso-8859-1?Q?233LbABSSioW1MQmJ0zP+0RgzrefBvLyVWbQlYSDfLtg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?SJNjHdzAX7/VCA1J95U1OIWF+r1gUtIzMsL3b13XSFtv3qjXn/R+nhnQ7H?=
 =?iso-8859-1?Q?tp2FEEoKfyaoG3ht9lcNToOZPqGVkOOSCTpM72Y2ErjCmQtl/dtWW1swIv?=
 =?iso-8859-1?Q?5by84PFA8zefduG+oJzyTLGrMuV1OF2HlSeIpoBqWXDKH7VIjgTbFG6hY9?=
 =?iso-8859-1?Q?c5eiDj3MCQQyelG1xRsFmhqVwQOV3LzFLjgGeE3HNrcnn3mx7g5S8IJMto?=
 =?iso-8859-1?Q?m1rG9C2W0C4XhRv4F62SUkfUfrzUdoVwFV2Ew8sBwEiPAG9Zj0rZdL004h?=
 =?iso-8859-1?Q?Sdy2LotQkXtKNsysm2y6mQRbF1IdvtG1BsAMbEhf5elQSWYxMhWybvg52Q?=
 =?iso-8859-1?Q?DG66nBhE5Atj55teFieBkYoNRRd7WwTnyNbb3hUuyz+k7JY0OfyWty3vlQ?=
 =?iso-8859-1?Q?I3ygyvkbDJoe+nEEGkJXy/w6feSL4X1Z66aOYUeS0p6MRO0j1NW2kpUTGq?=
 =?iso-8859-1?Q?xXVBxCYE4cU3M3X7mWiXrp93gJEmzc2VEk7Bxpng2Hv1OvsX8uz9zaW6XP?=
 =?iso-8859-1?Q?DzYI7BYiSzn5EorTjEcvYNEm0gPV5Gynpnp0hTKisASgcTOu19Q3/Ktht7?=
 =?iso-8859-1?Q?UxTW6yBFrL8H9f4053t18OLr6SSnRfr5JgkO2tcqYmKUOYRzlBxCUDI0rD?=
 =?iso-8859-1?Q?QZYaldg1beZtTGxHzI8+eh5yImG/KHbyrMk3BVdrLVRfu0vtcMYBX123BC?=
 =?iso-8859-1?Q?3Eq0iaPdLTkkxYy+jjlzky2hUW1d4dNsMCic39jPam12wW6W/DDz7rX2f9?=
 =?iso-8859-1?Q?bxZQd98odYaVn0wxvjykdJNB34bfpjPNnIRsD1kr+oliHTvj2pjzZCINyD?=
 =?iso-8859-1?Q?pWrEOMr01gXPt14Xk4tsmb0KHCAe9LxsR42nZK6xho88lJL/kBtmZzoM20?=
 =?iso-8859-1?Q?HBi802meGjPbrOvIoNO1xsSdUsnEwCRsLS/WN3QNASMiATI0vSEGQsglH+?=
 =?iso-8859-1?Q?CIDjv3JlaO4H8MW6odIKVsfaB56HtHzxVThwddA+6pluRwAbpN/ZQs0Yfh?=
 =?iso-8859-1?Q?0tHtM6bNNLv0tEmjAYtH7Lhi41DIR0m5bBlhzs3rGVcUcSRtZIos7VCoOY?=
 =?iso-8859-1?Q?fgKSv1dVqje9XFmH4Ivi2WJHfmwcrrAmLjdgnfObunbc8fstFMbZdQ+lKL?=
 =?iso-8859-1?Q?htMMiTMwBqlwJIfZMJO/JFCbUIwbhnFG1VmgZjeBNTCxEDSfVv80Q+qHvw?=
 =?iso-8859-1?Q?0nTlBcbV5HRlxbpfh6gqgUDdYIzfJNLk4M3UrzUUPBzC9nbUa5xIZynQ+J?=
 =?iso-8859-1?Q?eVYLpcsLhbfrl7CXfkroandpaYrdKZ/XVeoVdCNetrhkYU3TikK8s41S/6?=
 =?iso-8859-1?Q?1Kw102Lal3QImPK6+79gcIM4euAoUm8VQ6hg5cP5XRlid/fbEsu8RfI/Qh?=
 =?iso-8859-1?Q?EqkkG3bpSAQnnvw8BqgLP5EE5PJgQOx6sgH43GJDwbnn90Qr/erwSUgrpL?=
 =?iso-8859-1?Q?GQTwWu+rof8D82TKmXpulbCvcGUjtNpywQut8ySIvcPXjAenCvN5tF+PJk?=
 =?iso-8859-1?Q?2ERz+HXHZXYztURLQjsuXbtxpk6+0zP0PBAbR9bHGKqt0H87/+OXUpRSEV?=
 =?iso-8859-1?Q?9lePV8j2uurdcqso3XC800UUKfjFbrRibL/bqLN/7HBEkTDBbJrIdPlzD7?=
 =?iso-8859-1?Q?sQqX9ZpcKD7jcRUr3G8s/OFKcEhwa/XZg/1+M6DmJ7I3UlXMdVvL2ZnS8H?=
 =?iso-8859-1?Q?y9NEKO2tc/1e1OzlKaA=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c502f03a-e546-4b6d-588f-08ddeaf665a5
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:14.4213
 (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: KB23C0eWAbv2VjrrAlvRbjgNbBRDc/Ld2WIBZem6teLYsUark5ZnnSZZE1Nj5iCKu/Mf+Q5bi/7GDgjjVBFAzR6fwPTsXXvvjuUI+VkvLMU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

The Dom0 and DomUs logic for the dom0less configuration in create_dom0()
and arch_create_domUs() should account for extended SPIs when supported
by the hardware and enabled with CONFIG_GICV3_ESPI. These changes ensure
proper calculation of the maximum number of SPIs and eSPIs available to
Dom0 and DomUs in dom0less setups.

When eSPIs are supported by the hardware and CONFIG_GICV3_ESPI is enabled, =
the
maximum number of eSPI interrupts is calculated using the ESPI_BASE_INTID
offset (4096) and is limited to 1024, with 32 IRQs subtracted. To ensure
compatibility with non-Dom0 domains, this adjustment is applied by the
toolstack during domain creation, while for Dom0 or DomUs in Dom0, it is
handled directly during VGIC initialization. If eSPIs are not supported, th=
e
calculation defaults to using the standard SPI range, with a maximum value =
of
992 interrupt lines, as it works currently.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V6:
- minor: updated the commit message

Changes in V5:
- fixed minor nits, no functional changes: updated the comment to make
  it clearer and corrected a misspelling
- added reviewed-by from Volodymyr Babchuk and from Oleksandr Tyshchenko

Changes in V4:
- consolidated the eSPI and SPI logic into a new inline function,
  vgic_def_nr_spis. Without eSPI support (either due to config being
  disabled or hardware not supporting it), it will return the regular SPI
  range, as it works currently. There are no functional changes compared
  with the previous patch version
- removed VGIC_DEF_MAX_SPI macro, to reduce the number of ifdefs

Changes in V3:
- renamed macro VGIC_DEF_NR_ESPIS to more appropriate VGIC_DEF_MAX_SPI
- added eSPI initialization for dom0less setups
- fixed comment with mentions about dom0less builds
- fixed formatting for lines with more than 80 symbols
- updated commit message

Changes in V2:
- no changes
---
 xen/arch/arm/dom0less-build.c   |  2 +-
 xen/arch/arm/domain_build.c     |  2 +-
 xen/arch/arm/include/asm/vgic.h | 19 +++++++++++++++++++
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 69b9ea22ce..02d5559102 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -285,7 +285,7 @@ void __init arch_create_domUs(struct dt_device_node *no=
de,
     {
         int vpl011_virq =3D GUEST_VPL011_SPI;
=20
-        d_cfg->arch.nr_spis =3D VGIC_DEF_NR_SPIS;
+        d_cfg->arch.nr_spis =3D vgic_def_nr_spis();
=20
         /*
          * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d91a71acfd..39eea0be00 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2054,7 +2054,7 @@ void __init create_dom0(void)
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
     dom0_cfg.arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
-    dom0_cfg.arch.nr_spis =3D VGIC_DEF_NR_SPIS;
+    dom0_cfg.arch.nr_spis =3D vgic_def_nr_spis();
     dom0_cfg.arch.tee_type =3D tee_get_type();
     dom0_cfg.max_vcpus =3D dom0_max_vcpus();
=20
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 1cf0a05832..c52bbcb115 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -347,6 +347,25 @@ extern void vgic_check_inflight_irqs_pending(struct vc=
pu *v,
 /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
 #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
=20
+static inline unsigned int vgic_def_nr_spis(void)
+{
+#ifdef CONFIG_GICV3_ESPI
+    /*
+     * Check if the hardware supports extended SPIs (even if the appropria=
te
+     * config is set). If not, the common SPI range will be used. Otherwis=
e
+     * return the maximum eSPI INTID, supported by HW GIC, subtracted by 3=
2.
+     * For Dom0 and started at boot time DomUs we will add back this value
+     * during VGIC initialization. This ensures consistent handling for Do=
m0
+     * and other domains. For the regular SPI range interrupts in this cas=
e,
+     * the maximum value of VGIC_DEF_NR_SPIS will be used.
+     */
+    if ( gic_number_espis() > 0 )
+        return ESPI_BASE_INTID + min(gic_number_espis(), 1024U) - 32;
+#endif
+
+    return VGIC_DEF_NR_SPIS;
+}
+
 extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
=20
 static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:31:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108463.1458615 (Exim 4.92)
	(envelope-from )
	id 1utoVq-00031a-GA; Wed, 03 Sep 2025 14:31:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108463.1458615; Wed, 03 Sep 2025 14: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 1utoVq-00031R-CV; Wed, 03 Sep 2025 14:31:02 +0000
Received: by outflank-mailman (input) for mailman id 1108463;
 Wed, 03 Sep 2025 14:31:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1utoVE-0006B7-CE
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:24 +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 8513629e-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:20 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:18 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 8513629e-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JPbYd2o0IOrjxvHjhYStZZ7cEfo2JH0sSBmtynJS5oK0gyRzg5Wv/RFRBZgqljhIKB4cOeQsnZG5jooNBUhVxXNq2aSTdcz6dhNtMja7GvKaBCp16PJOGhYBFC2aQFKUzK/A/sRCyB93sOo8lJD3xRFbbdtpqv4KGa+ReVE3khTXWvpGvcPNfSK8G7GZ7KJIiEsHwB5gBsJgiALLtZtihZ0y++ieSzx6bvmDUEALh32YdrJ22e8basUht8xSbdkfmX8ZE8mFxpC5G8kcoD/qW44a5Vw9LbZzAPhDdJTeQYFYOe9tR4rPGyupcjborNynT84xjqe4sCV0zQaMx8eiww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+WkysxZgw+5syaIui0nLw+HYZM4/1UBCEinESOtulBE=;
 b=aSFr0DRJhyQ6V6cf4zAPMplBgx+Tm3tvJlTPsuxwA5lgVVCHUAkppnXxLFZB+wY9DgfWPyK9djxZ4jM2f1Jn8H2YrpsbB70t6mApJCJ6Mt7TL/VfXu5NWk6YbTanilFmZR+/AJ8gaxP3C+GQVeLOHqidGwpmdZKh/qaeQdD4iAHNDLlk8LC9q0xVRV+19HwbJivg3hIDxSz4a1snwHq5FuaATARm7H4QL8nnVqtfwIZp6nqSR7XXbqXn66TaUQMP6hUApAJDSCf+mf/YHjClG8CvCWkc0t/5dCesZvx8RsYOm5D4fvT0H2g4OhmUNVa8lLFZs61CzEQaF/hYoaCGeg==
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=+WkysxZgw+5syaIui0nLw+HYZM4/1UBCEinESOtulBE=;
 b=iMt4muewn8i5K9O3BPgtReaw3b52XxLqmz7S6ci6LD+B0kNnBcsP9DLTQntOqP061+hkgWRHubbNrnKn+QSTg++LvFrnqaNb3uJEQ7mG7YhqyGwV+RnfxYlz+CSK/+BSObdPaY6/V+iCmPMw+GQ2WMQCtlFtgR8BoGqZJmmCSpLjeRhdbxNtNni+Y5Vf5UBey45ZVn12tI3YG9OqRvQHIEEGuglA7hIulH65Z4xuAEAAzQY8/127rfpwetwxMkHF/GsClnvuWsvK4mN/7Oc8GizONFm+8uRoSFmYGBFAPmuRDO57yG04fUEihyL3sG6Hm6egWlDyAKrsRd0Sh+crZQ==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Topic: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Index: AQHcHN9FrhwGrEUPyUu8gbPtoBO0RQ==
Date: Wed, 3 Sep 2025 14:30:18 +0000
Message-ID:
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: 53c3db52-e49b-4bbe-c758-08ddeaf66826
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ysaTRuYytc/nfMhIF9P/gaLoxRjAkFNJyHG8PAZ5s00xTMV/BackgRgFIp?=
 =?iso-8859-1?Q?PBi29laNuYCoTmo8T019H3Gm0YJB1wnymNJB8FEhAyakpHn9A6auLDFRp5?=
 =?iso-8859-1?Q?PW5/XG44PQfzNcvqmcJQelRyC/pB4JJ+7rMqfGLQ7Mnnqf26ofIDGlodqZ?=
 =?iso-8859-1?Q?noxitMcMdfZv3dKktM+nY63/P1ssBCVi/O40+2fCP4MDDFQ9IVrAvBLYJr?=
 =?iso-8859-1?Q?j8/MEo4Pr/Qc/VT8rOFck4NQxOknW6SOvRjm8k27ksfz16v8Qd8wKJR8FC?=
 =?iso-8859-1?Q?VVAXVfVm+WhoyWRxXti6arbembxJVKTdWkM+YbroOixvFE+vdPjg0vql7O?=
 =?iso-8859-1?Q?AsWQE17QwraTjCAmVJz1QB9tIMlSqVYYgqMQwEyL0S1zGosbWsie9YZIVu?=
 =?iso-8859-1?Q?t3dqvL0GinhcABtf1RDkHwPj88e5PWeu5GJ1SX5MWDIqc1g7TVu6WHDsQy?=
 =?iso-8859-1?Q?ny5YcLrG/eSrQTNXdZqTIPyC0gkbe8oBdYwq5glWsSTW6bPmqdsF21golq?=
 =?iso-8859-1?Q?XCoMvPRGLD3rGOQoPsVIV2WCrzjK5/CR7LqvltHAYPl75hHXPKo4Dbcxca?=
 =?iso-8859-1?Q?nKFFvE4KPFlurww2/w2TIyBlG/ETG6ppdeQOmwrXdqCyLjhxZFC2Jx+ffx?=
 =?iso-8859-1?Q?nY9NpAg2ozMaDwLjFTH5cP6UcXafTwjIdKHDCE+1D25Fmh1xpaZcPhPvbv?=
 =?iso-8859-1?Q?vB3883Fw6F2zL68O2yOoQUvF00Rs06G4frvuV7gy25YD+2kXX4EQqhbUiV?=
 =?iso-8859-1?Q?ZoAHrxynpgE63p073rrGeXmMmIHfV6HpZjpofEQlxxlO+aJwaJYtTT2MXP?=
 =?iso-8859-1?Q?8K8xai1ocaZyHFZdjEv8h5owct7PRWlgwstpO24/DFfukTFzmdmXMNPrT/?=
 =?iso-8859-1?Q?ThL2CqLHB8jltBFsoH27xYC/kVm/ir2MT4jgvbeZKNU5tNci/GZh6k7QEn?=
 =?iso-8859-1?Q?hAhgGxh0M0hwhl+0QWKFge/zOw6Whq1MuOvJdnV03ZWcljjrLR8haHZwLf?=
 =?iso-8859-1?Q?HHaWwB5VrX0tw50w23mKZxdeWZkpVIpYgsy7vChy4UtLAxXD6b8Zv56usF?=
 =?iso-8859-1?Q?of67kQw148IPjhpAxhKv+BJJyu9PHetJBEANcKP6Wd7pXIfOon4MF4LKKq?=
 =?iso-8859-1?Q?OzyW1LAImh4LSwxxRpAKkOgjnU5shgVIiOqb49sdlrekX4otBjojeBh3Cc?=
 =?iso-8859-1?Q?XvTky8Ke4yNUrMkT6RJ9jxKmOt18uOz0bTvoP0L30w+5Qv0aEd1mDL8tvM?=
 =?iso-8859-1?Q?6kN+O3QqszUrVBDVwVLCGY+3rxPYPlm/gzHeXvMxganhQOAM46lsCSBe5h?=
 =?iso-8859-1?Q?/jDHtBQGHGjMDxTuBuKqOtBIblDX5VwKi5LHUvHJg4+V4OpUuXIS8VD4QO?=
 =?iso-8859-1?Q?xtaw/tpAqsA3aEV5o0LKckAjkGMVFaq9ykGHD6RFsFPgKwvLw4G4tQoF9h?=
 =?iso-8859-1?Q?HOBH0fwTqz1vwOOVB69+qsD+XxZ9fJsa5zXpo7YinD/OXPmho17A5J33+c?=
 =?iso-8859-1?Q?HEVZc4MRjALIr97fEkDg0fLsGZWXvgHVQ9+cKXLDr96w=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?PSIZkWShYSeXGbOaf3kBtO+L55sEmPxt3t0cHKyUqYb2/Ad2R7/FkxtP8c?=
 =?iso-8859-1?Q?ZAJTkUR+IZhNymV0doRqoGVzEhg3YqiSqKwvJjh1bNx7mOMSs2uZb5jCmR?=
 =?iso-8859-1?Q?XdBes2h3tXMRY60fIltPzKmGJleTC0DushHkHh4UDQITRRPAcYLbHt+tco?=
 =?iso-8859-1?Q?3sJpJ+VEpNLT5OPw9xQSY3DnLOl+0i+2qkSBcatxQS5dnleezFVU2KAeMr?=
 =?iso-8859-1?Q?47lozjA2WTSHpCLAKp22igCmr/oXsICDXrhSElacZRqRK4I9uBcaWC8QQF?=
 =?iso-8859-1?Q?9aXjNLc8Gd4bEbURMWTcylCb0vy3Sp6ZhoUAlhYn5Z9BP7q6wkswdL4TQx?=
 =?iso-8859-1?Q?59yHHasvvfwAiqufYzfCFXos3xKMm1OFvBZzSRfoZ0RnURt2C1Y8vXa9ex?=
 =?iso-8859-1?Q?8Hu6iPz2UMzPlCNpCQSrk7xK+PiWyyIVt6NcVgIhqLJP346SqQtwWL/W7U?=
 =?iso-8859-1?Q?MHZzVSdtPPUjOhlYbFwauHi3YMrooaQQotTw2b/8CHoxlj8lHdRh0vcNqs?=
 =?iso-8859-1?Q?ZCQ8QWx2LcTNkdqbl42MzOSipkPuSFxT+almg/hTC5nw2pPMRODMPpU3JJ?=
 =?iso-8859-1?Q?zPlD6Paag35Scm/F8jl6wqpwv8G4xactiji5rPFmS4lXo9iA7nx70sTR4b?=
 =?iso-8859-1?Q?4p8LXIdm7NUBRhLXrmhNyiUSVmKv0JWwt0Ug8rKrzGO5AgjloQs/aeV/VD?=
 =?iso-8859-1?Q?58d1PxUZ8YoiGJhtltgtzxOQr4++NtqXRXGKRwKceFJSuq0GX9R8tudFLt?=
 =?iso-8859-1?Q?wJ/YcSIjMW+hdoYV5QFqgOGsBvlZ/NEDOJ+BrNJfAzbJDtLTxS4y21Zcn+?=
 =?iso-8859-1?Q?2bZY6h/LPH9lT0ZAHquQfyI3H86LTNoNntK/kZevEepmunOjKqMQEgUAlR?=
 =?iso-8859-1?Q?HepHa4QZOJi8VQjJhig5xOv+Tod9bUlPoUDvk3sybdByQYSZlF9j9VTjA5?=
 =?iso-8859-1?Q?JuRe8TG7QMa73RxgLxHIVC1Y35CEZQL+1xo3r43vV5EPZJX++llFhxlT78?=
 =?iso-8859-1?Q?mH+tX9kvOUxH4ASuvgGqXvcBS22HK3/aQ0MB31JyZres3GsC5lXwpv4sfL?=
 =?iso-8859-1?Q?6+hCkmHGe9okmCwFkyDAIkcdZNhI4KntiSMmzYJPsznV5M6aUurNiTN8Sg?=
 =?iso-8859-1?Q?oYJodjPkTp+x4aMrDsb90ZJCWfrUSw0uBVtk14f/Yi5Ew23Q7AIcaMyelQ?=
 =?iso-8859-1?Q?1x3HsnJJIepyK7CbzjCGUKpK6deWXElFM+/mU62VawE1HbNS0CMBlOSTV0?=
 =?iso-8859-1?Q?AfrPvdX3/OM/cm1zBgnOOaR9By9DGYIEA51HFxYFeX3CJi93h6EY/nRyBL?=
 =?iso-8859-1?Q?Q0k2UsO0Ovr9bpguKgBmyKzY65/4LiJ0KjzUm4tp3gcNdprLe1UOW1nlO1?=
 =?iso-8859-1?Q?3a02d8pvfH7GSNrCzMaEkogPU+ZEUFCu9hmecV2zhdhNkP4wfEDzdiLdIz?=
 =?iso-8859-1?Q?0LLyRbP4mm/opSHxkxC55mfzgEUSkKmrJf+wExx17hWpQCDnsw2FGfPgUn?=
 =?iso-8859-1?Q?5i9BHvvwBI460lKKgnzTTLiZM41nSicnIa38C0EY4Iy5svNn3GHX1GT2st?=
 =?iso-8859-1?Q?fgqh7LX2+diAGWPqXkb5l3GaD+1lArjmZ1RftkLiaVGy9B3//L46dSMylK?=
 =?iso-8859-1?Q?oxUwrK6lnHBUCq7J+Sq2TpN1vjKwci9Wzex7WflCk6EOzx4YMs9tkm0+XC?=
 =?iso-8859-1?Q?Ykt08fITAl7NXew7fOw=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 53c3db52-e49b-4bbe-c758-08ddeaf66826
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:18.6620
 (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: lJtdnkN1dhLySMofOadcw+/AGeZqGFXde1z3tR6eGfXZnN+ya/iLg5Se3gUg4Bl2MwlG3Xe+W7r6NxO0DfsCxYmQETNhQhJ1pYvTms32xNc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
following a similar approach to the handling of regular SPIs.

The eSPI registers, previously located in reserved address ranges,
are now adjusted to support MMIO read and write operations correctly
when CONFIG_GICV3_ESPI is enabled.

The availability of eSPIs and the number of emulated extended SPIs
for guest domains is reported by setting the appropriate bits in the
GICD_TYPER register, based on the number of eSPIs requested by the
domain and supported by the hardware. In cases where the configuration
option is disabled, the hardware does not support eSPIs, or the domain
does not request such interrupts, the functionality remains unchanged.

Signed-off-by: Leonid Komarianskyi 

---
Changes in V6:
- introduced helper functions: vgic_get_rank and vgic_get_reg_offset to
  avoid boilerplate code and simplify changes
- fixed index initialization in the previous patch ([08/12] xen/arm:
  vgic: add resource management for extended SPIs) and removed index
  conversion for vgic_enable_irqs(), vgic_disable_irqs(),
  vgic_set_irqs_pending(), and vgic_check_inflight_irqs_pending()
- grouped SPI and eSPI registers
- updated the comment for vgic_store_irouter to reflect parameter
  changes
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch

Changes in V5:
- since eSPI-specific defines and macros are now available even when the
  appropriate config is disabled, this allows us to remove many
  #ifdef guards and reuse the existing code for regular SPIs for eSPIs as
  well, as eSPIs are processed similarly. This improves code readability
  and consolidates the register ranges for SPIs and eSPIs in a single
  place, simplifying future changes or fixes for SPIs and their
  counterparts from the extended range
- moved vgic_ext_rank_offset() from
  [08/12] xen/arm: vgic: add resource management for extended SPIs
  as the function was unused before this patch
- added stub implementation of vgic_ext_rank_offset() when CONFIG_GICV3_ESP=
I=3Dn
- removed unnecessary defines for reserved ranges, which were introduced in
  V4 to reduce the number of #ifdefs. The issue is now resolved by
  allowing the use of SPI-specific offsets and reworking the logic

Changes in V4:
- added missing RAZ and write ignore eSPI-specific registers ranges:
  GICD_NSACRnE and GICD_IGRPMODRnE
- changed previously reserved range to cover GICD_NSACRnE and
  GICD_IGRPMODRnE
- introduced GICD_RESERVED_RANGE_START/END defines to remove
  hardcoded values and reduce the number of ifdefs
- fixed reserved ranges with eSPI option enabled: added missing range
  0x0F30-0x0F7C
- updated the logic for domains that do not support eSPI, but Xen is
  compiled with the eSPI option. Now, prior to other MMIO checks, we
  verify whether eSPI is available for the domain or not. If not, it
  behaves as it does currently - RAZ and WI
- fixed print for GICD_ICACTIVERnE
- fixed new lines formatting for switch-case

Changes in V3:
- changed vgic_store_irouter parameters - instead of offset virq is
  used, to remove the additional bool espi parameter and simplify
  checks. Also, adjusted parameters for regular SPI. Since the offset
  parameter was used only for calculating virq number and then reused for
  finding rank offset, it will not affect functionality.
- fixed formatting for goto lables - added newlines after condition
- fixed logs for GICD_ISACTIVERnE and GICD_ICACTIVERnE handlers
- removed #ifdefs in 2 places where they were adjacent and could be merged

Changes in V2:
- add missing rank index conversion for pending and inflight irqs
---
 xen/arch/arm/include/asm/vgic.h |   4 +
 xen/arch/arm/vgic-v3.c          | 198 +++++++++++++++++++++++++-------
 xen/arch/arm/vgic.c             |  22 ++++
 3 files changed, 180 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index c52bbcb115..dec08a75a4 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -314,6 +314,10 @@ extern struct vgic_irq_rank *vgic_rank_offset(struct v=
cpu *v,
                                               unsigned int b,
                                               unsigned int n,
                                               unsigned int s);
+extern struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v,
+                                                  unsigned int b,
+                                                  unsigned int n,
+                                                  unsigned int s);
 extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int ir=
q);
 extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4369c55177..27af247d30 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -107,17 +107,12 @@ static uint64_t vgic_fetch_irouter(struct vgic_irq_ra=
nk *rank,
 /*
  * Store an IROUTER register in a convenient way and migrate the vIRQ
  * if necessary. This function only deals with IROUTER32 and onwards.
- *
- * Note the offset will be aligned to the appropriate boundary.
  */
 static void vgic_store_irouter(struct domain *d, struct vgic_irq_rank *ran=
k,
-                               unsigned int offset, uint64_t irouter)
+                               unsigned int virq, uint64_t irouter)
 {
     struct vcpu *new_vcpu, *old_vcpu;
-    unsigned int virq;
-
-    /* There is 1 vIRQ per IROUTER */
-    virq =3D offset / NR_BYTES_PER_IROUTER;
+    unsigned int offset;
=20
     /*
      * The IROUTER0-31, used for SGIs/PPIs, are reserved and should
@@ -673,6 +668,34 @@ write_reserved:
     return 1;
 }
=20
+/*
+ * Since all eSPI counterparts of SPI registers belong to lower offsets,
+ * we can check whether the register offset is less than espi_base and,
+ * if so, return the rank for regular SPI. Otherwise, return the rank
+ * for eSPI.
+ */
+static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
+                                                  unsigned int b,
+                                                  uint32_t reg,
+                                                  unsigned int s,
+                                                  uint32_t spi_base,
+                                                  uint32_t espi_base)
+{
+    if ( reg < espi_base )
+        return vgic_rank_offset(v, b, reg - spi_base, s);
+    else
+        return vgic_ext_rank_offset(v, b, reg - espi_base, s);
+}
+
+static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base=
,
+                                           uint32_t espi_base)
+{
+    if ( reg < espi_base )
+        return reg - spi_base;
+    else
+        return reg - espi_base;
+}
+
 static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu =
*v,
                                             mmio_info_t *info, uint32_t re=
g,
                                             register_t *r)
@@ -685,13 +708,17 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     {
     case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* We do not implement security extensions for guests, read zero *=
/
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
         goto read_as_zero;
=20
     case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD);
+        rank =3D vgic_get_rank(v, 1, reg, DABT_WORD, GICD_ISENABLER,
+                             GICD_ISENABLERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
         vgic_lock_rank(v, rank, flags);
         *r =3D vreg_reg32_extract(rank->ienable, info);
@@ -699,8 +726,10 @@ static int __vgic_v3_distr_common_mmio_read(const char=
 *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD);
+        rank =3D vgic_get_rank(v, 1, reg, DABT_WORD, GICD_ICENABLER,
+                             GICD_ICENABLERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
         vgic_lock_rank(v, rank, flags);
         *r =3D vreg_reg32_extract(rank->ienable, info);
@@ -710,22 +739,29 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     /* Read the pending status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
     case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
         goto read_as_zero;
=20
     /* Read the active status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
         goto read_as_zero;
=20
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
     {
-        uint32_t ipriorityr;
+        uint32_t ipriorityr, offset;
         uint8_t rank_index;
=20
         if ( dabt.size !=3D DABT_BYTE && dabt.size !=3D DABT_WORD ) goto b=
ad_width;
-        rank =3D vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
+        rank =3D vgic_get_rank(v, 8, reg, DABT_WORD, GICD_IPRIORITYR,
+                             GICD_IPRIORITYRnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
-        rank_index =3D REG_RANK_INDEX(8, reg - GICD_IPRIORITYR, DABT_WORD)=
;
+        offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORIT=
YRnE);
+        rank_index =3D REG_RANK_INDEX(8, offset, DABT_WORD);
=20
         vgic_lock_rank(v, rank, flags);
         ipriorityr =3D ACCESS_ONCE(rank->ipriorityr[rank_index]);
@@ -737,14 +773,16 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     }
=20
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
     {
-        uint32_t icfgr;
+        uint32_t icfgr, offset;
=20
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD);
+        rank =3D vgic_get_rank(v, 2, reg, DABT_WORD, GICD_ICFGR, GICD_ICFG=
RnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
+        offset =3D vgic_get_reg_offset(reg, GICD_ICFGR, GICD_ICFGRnE);
         vgic_lock_rank(v, rank, flags);
-        icfgr =3D rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR, DABT_WORD=
)];
+        icfgr =3D rank->icfg[REG_RANK_INDEX(2, offset, DABT_WORD)];
         vgic_unlock_rank(v, rank, flags);
=20
         *r =3D vreg_reg32_extract(icfgr, info);
@@ -782,12 +820,16 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
     {
     case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* We do not implement security extensions for guests, write ignor=
e */
         goto write_ignore_32;
=20
     case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD);
+        rank =3D vgic_get_rank(v, 1, reg, DABT_WORD, GICD_ISENABLER,
+                             GICD_ISENABLERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
         vgic_lock_rank(v, rank, flags);
         tr =3D rank->ienable;
@@ -797,8 +839,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD);
+        rank =3D vgic_get_rank(v, 1, reg, DABT_WORD, GICD_ICENABLER,
+                             GICD_ICENABLERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
         vgic_lock_rank(v, rank, flags);
         tr =3D rank->ienable;
@@ -808,8 +852,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISPENDR, DABT_WORD);
+        rank =3D vgic_get_rank(v, 1, reg, DABT_WORD, GICD_ISPENDR,
+                             GICD_ISPENDRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
=20
         vgic_set_irqs_pending(v, r, rank->index);
@@ -817,8 +863,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICPENDR, DABT_WORD);
+        rank =3D vgic_get_rank(v, 1, reg, DABT_WORD, GICD_ICPENDR,
+                             GICD_ICPENDRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
=20
         vgic_check_inflight_irqs_pending(v, rank->index, r);
@@ -826,28 +874,42 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
         goto write_ignore;
=20
     case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        printk(XENLOG_G_ERR
-               "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER=
%d\n",
-               v, name, r, reg - GICD_ISACTIVER);
+        if ( reg < GICD_ISACTIVERnE )
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ISACT=
IVER%d\n",
+                   v, name, r, reg - GICD_ISACTIVER);
+        else
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ISACT=
IVER%dE\n",
+                   v, name, r, reg - GICD_ISACTIVERnE);
         return 0;
=20
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-        printk(XENLOG_G_ERR
-               "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER=
%d\n",
-               v, name, r, reg - GICD_ICACTIVER);
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+        if ( reg < GICD_ICACTIVERnE )
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ICACT=
IVER%d\n",
+                   v, name, r, reg - GICD_ICACTIVER);
+        else
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ICACT=
IVER%dE\n",
+                   v, name, r, reg - GICD_ICACTIVERnE);
         goto write_ignore_32;
=20
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
     {
-        uint32_t *ipriorityr, priority;
+        uint32_t *ipriorityr, priority, offset;
=20
         if ( dabt.size !=3D DABT_BYTE && dabt.size !=3D DABT_WORD ) goto b=
ad_width;
-        rank =3D vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
+        rank =3D vgic_get_rank(v, 8, reg, DABT_WORD, GICD_IPRIORITYR,
+                             GICD_IPRIORITYRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORIT=
YRnE);
         vgic_lock_rank(v, rank, flags);
-        ipriorityr =3D &rank->ipriorityr[REG_RANK_INDEX(8, reg - GICD_IPRI=
ORITYR,
-                                                      DABT_WORD)];
+        ipriorityr =3D &rank->ipriorityr[REG_RANK_INDEX(8, offset, DABT_WO=
RD)];
         priority =3D ACCESS_ONCE(*ipriorityr);
         vreg_reg32_update(&priority, r, info);
         ACCESS_ONCE(*ipriorityr) =3D priority;
@@ -859,17 +921,22 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
         goto write_ignore_32;
=20
     case VRANGE32(GICD_ICFGR + 4, GICD_ICFGRN): /* PPI + SPIs */
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    {
+        uint32_t offset;
+
         /* ICFGR1 for PPI's, which is implementation defined
            if ICFGR1 is programmable or not. We chose to program */
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD);
+        rank =3D vgic_get_rank(v, 2, reg, DABT_WORD, GICD_ICFGR, GICD_ICFG=
RnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(reg, GICD_ICFGR, GICD_ICFGRnE);
         vgic_lock_rank(v, rank, flags);
-        vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR,
-                                                     DABT_WORD)],
+        vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, offset, DABT_WORD)=
],
                           r, info);
         vgic_unlock_rank(v, rank, flags);
         return 1;
+    }
=20
     default:
         printk(XENLOG_G_ERR
@@ -1129,6 +1196,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, m=
mio_info_t *info,
             typer |=3D GICD_TYPE_LPIS;
=20
         typer |=3D (v->domain->arch.vgic.intid_bits - 1) << GICD_TYPE_ID_B=
ITS_SHIFT;
+#ifdef CONFIG_GICV3_ESPI
+        if ( v->domain->arch.vgic.nr_espis > 0 )
+        {
+            /* Set eSPI support bit for the domain */
+            typer |=3D GICD_TYPER_ESPI;
+            /* Set ESPI range bits */
+            typer |=3D (DIV_ROUND_UP(v->domain->arch.vgic.nr_espis, 32) - =
1)
+                       << GICD_TYPER_ESPI_RANGE_SHIFT;
+        }
+#endif
=20
         *r =3D vreg_reg32_extract(typer, info);
=20
@@ -1194,6 +1271,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, m=
mio_info_t *info,
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /*
          * Above all register are common with GICR and GICD
          * Manage in common
@@ -1201,6 +1288,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mm=
io_info_t *info,
         return __vgic_v3_distr_common_mmio_read("vGICD", v, info, gicd_reg=
, r);
=20
     case VRANGE32(GICD_NSACR, GICD_NSACRN):
+    case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN):
         /* We do not implement security extensions for guests, read zero *=
/
         goto read_as_zero_32;
=20
@@ -1216,27 +1304,30 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, =
mmio_info_t *info,
         /* Replaced with GICR_ISPENDR0. So ignore write */
         goto read_as_zero_32;
=20
-    case VRANGE32(0x0F30, 0x60FC):
+    case VRANGE32(0x0F30, 0x0FFC):
         goto read_reserved;
=20
     case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019):
+    case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):
     {
         uint64_t irouter;
+        uint32_t offset;
=20
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
-                                DABT_DOUBLE_WORD);
+        rank =3D vgic_get_rank(v, 64, gicd_reg, DABT_DOUBLE_WORD, GICD_IRO=
UTER,
+                             GICD_IROUTERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
+        offset =3D vgic_get_reg_offset(gicd_reg, GICD_IROUTER, GICD_IROUTE=
RnE);
         vgic_lock_rank(v, rank, flags);
-        irouter =3D vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER);
+        irouter =3D vgic_fetch_irouter(rank, offset);
         vgic_unlock_rank(v, rank, flags);
=20
         *r =3D vreg_reg64_extract(irouter, info);
=20
         return 1;
     }
-
-    case VRANGE32(0x7FE0, 0xBFFC):
+    case VRANGE32(0x3700, 0x60FC):
+    case VRANGE32(0xA004, 0xBFFC):
         goto read_reserved;
=20
     case VRANGE32(0xC000, 0xFFCC):
@@ -1382,12 +1473,23 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v,=
 mmio_info_t *info,
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* Above registers are common with GICR and GICD
          * Manage in common */
         return __vgic_v3_distr_common_mmio_write("vGICD", v, info,
                                                  gicd_reg, r);
=20
     case VRANGE32(GICD_NSACR, GICD_NSACRN):
+    case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN):
         /* We do not implement security extensions for guests, write ignor=
e */
         goto write_ignore_32;
=20
@@ -1405,26 +1507,34 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v,=
 mmio_info_t *info,
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
         return 0;
=20
-    case VRANGE32(0x0F30, 0x60FC):
+    case VRANGE32(0x0F30, 0x0FFC):
         goto write_reserved;
=20
     case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019):
+    case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):
     {
         uint64_t irouter;
+        unsigned int offset, virq;
=20
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
-                                DABT_DOUBLE_WORD);
+        rank =3D vgic_get_rank(v, 64, gicd_reg, DABT_DOUBLE_WORD, GICD_IRO=
UTER,
+                             GICD_IROUTERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(gicd_reg, GICD_IROUTER, GICD_IROUTE=
RnE);
         vgic_lock_rank(v, rank, flags);
-        irouter =3D vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER);
+        irouter =3D vgic_fetch_irouter(rank, offset);
         vreg_reg64_update(&irouter, r, info);
-        vgic_store_irouter(v->domain, rank, gicd_reg - GICD_IROUTER, irout=
er);
+        if ( gicd_reg < GICD_IROUTERnE )
+            virq =3D offset / NR_BYTES_PER_IROUTER;
+        else
+            virq =3D espi_idx_to_intid(offset / NR_BYTES_PER_IROUTER);
+        vgic_store_irouter(v->domain, rank, virq, irouter);
         vgic_unlock_rank(v, rank, flags);
         return 1;
     }
=20
-    case VRANGE32(0x7FE0, 0xBFFC):
+    case VRANGE32(0x3700, 0x60FC):
+    case VRANGE32(0xA004, 0xBFFC):
         goto write_reserved;
=20
     case VRANGE32(0xC000, 0xFFCC):
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index b42aee8d0c..9458ba93f7 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -170,6 +170,18 @@ int domain_vgic_register(struct domain *d, unsigned in=
t *mmio_count)
 }
=20
 #ifdef CONFIG_GICV3_ESPI
+/*
+ * The function behavior is the same as for regular SPIs (vgic_rank_offset=
),
+ * but it operates with extended SPI ranks.
+ */
+struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b,
+                                           unsigned int n, unsigned int s)
+{
+    unsigned int rank =3D REG_RANK_NR(b, (n >> s));
+
+    return vgic_get_rank(v, rank + EXT_RANK_MIN);
+}
+
 static unsigned int vgic_num_spi_lines(struct domain *d)
 {
     return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
@@ -210,6 +222,16 @@ static unsigned int vgic_num_spi_lines(struct domain *=
d)
     return d->arch.vgic.nr_spis;
 }
=20
+/*
+ * It is expected that, in the case of CONFIG_GICV3_ESPI=3Dn, the function=
 will
+ * return NULL. In this scenario, mmio_read/mmio_write will be treated as
+ * RAZ/WI, as expected.
+ */
+struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b,
+                                           unsigned int n, unsigned int s)
+{
+    return NULL;
+}
 #endif
=20
 static unsigned int vgic_num_alloc_irqs(struct domain *d)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:31:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108464.1458620 (Exim 4.92)
	(envelope-from )
	id 1utoVq-00033o-QY; Wed, 03 Sep 2025 14:31:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108464.1458620; Wed, 03 Sep 2025 14: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 1utoVq-00033J-KG; Wed, 03 Sep 2025 14:31:02 +0000
Received: by outflank-mailman (input) for mailman id 1108464;
 Wed, 03 Sep 2025 14:31:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1utoV4-0006B7-J8
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:14 +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 8087419a-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:13 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:09 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 8087419a-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LPVIcZMwCcxDkz+QtG7QO2rD1Upd9K6ycftXoXiNcVEMqggAhJJUVbh7swQjaH98IN3XY0/eZvtIwr8ZOrYmOKlnIp543DvXS+mqA0ee1aegjbbhEBJjvSTOZrgqA97VxNqCxqWmopI4dU5s0HbtWLasuOx6RHFFXesu7YDJ8pZqGgLo+WrTe0NiqDh0eIe3slkYaPqMrgOfHAAz0a08TYLQdOgHcHo+rnydTmcY+6GgDbMFMUnRax01OWq9HGQkzdaKLp+pXo4j5EhrAqIFbYrNPInDUTszzBdjU9Kt1i8gOsANbsjRPQQXlHrId+4gSPe7yJcV80/Ksi+WdQTb4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4P7Skptts/tLyCoYlyO9TM/LWsioRSC96rqr3DpuzSM=;
 b=viePGEdrb8D1Rf/2lhRxeUkhx9lSLgF9HyyraOeUJk0T4idjY1Ro0N2AZs87ZCcpnaaKiIikzF19cfbDJ8EI6eG3yxk6+kbkaAyL/3bPOSY8hCBBQvaWk5+Ldi2JiqkE2DgUZE+iWtnawZINyq8vHO8S02Amgvljldyt9FKwdqXiOPQlmuKAuGwF2KSYgoCgIbHSW2qLJtzf8Wm3DFQ0uQHPnr3UobRecw5Px/MWmKs9gUH2jWHbNddiM4v64J4WmaT/GRXmBymnHPkvrQra1j3+R9dvapGw7PtcOEEgbscIFC/3iJu0QWHtv3kw84ER1faR4uDuPaVzV38X2s9EHA==
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=4P7Skptts/tLyCoYlyO9TM/LWsioRSC96rqr3DpuzSM=;
 b=mXHFcBTG35DzxebPLlsc2u9dHg0nf6bF+eqSAwKZf93FYqhqMlkvfcoYUnrPtHtoGObtrUAfHAqT42fFsJsgM1uWTtPsigT3CoYTgd83uuawWpgCU2J3RvsH3JLDNp5GEYxwVbf/1PLQSyomf8d/J60wR4O/YJsyIzco4SDoR/MLMgXDMQ2/WHr3+BOhNdjTZUhLodoqjSr0S6Rz5bGR8Ud88/gojSjGVcTecyA+qP5k6gR13QxWZ63Yx/U1Z66TQ0yVkrIEloTCzhZC/LnFEiAnSgi58sfLH0E9W++W9MSEvZoGf2xPi/UkaFqg3slipNdhxWZqSMUXmq41OLDs4Q==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: [PATCH v6 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow
 eSPI processing
Thread-Topic: [PATCH v6 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to
 allow eSPI processing
Thread-Index: AQHcHN8/Ah6J9SF+q06s1wKlnTLbDw==
Date: Wed, 3 Sep 2025 14:30:08 +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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: 68a09ed4-ac28-4344-5fa8-08ddeaf662df
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?st8ESvCyLsCIovEquwVuIHiiIVxTiSt8VtRMlQSRf/fZ1uAGPFxfu8wr7b?=
 =?iso-8859-1?Q?FuUv0Do5j9ov6XZKGAxuTZBN/3JPNEhIG7xNKr4BKgE/ZFZ2JSi4HA8HhF?=
 =?iso-8859-1?Q?tuoM09jgRwuREK88VmQCBTtiQ+dANeXgSan0JPhOe4XVm9Fg29SVNXEqmo?=
 =?iso-8859-1?Q?R7bD//UCz5E75LWRJFlv+gYlObfQLQ/imf7F3uTzH2R/XaIk/PKlXPyPme?=
 =?iso-8859-1?Q?H7jwWblD7p0aH30AmbVRPt94Cb9hdZAsEds16C/z1WrBpWfFHPa/jLedTu?=
 =?iso-8859-1?Q?Xcb33NgvFiPavynkybSDADlVkeC32ecoacotu6+WJtYQ4InZFgUIwSyNi+?=
 =?iso-8859-1?Q?k8hh+CgN5W9AAFd1bkucKq2nDz33p8M4D3+1Lh552IKsdrjsA5SK6FTziv?=
 =?iso-8859-1?Q?2Q0WaZ3HI5dHdo/+SUGypkcsFkb8oP/omQ6mCt0nTAa+gBhPuLF/rli0Pz?=
 =?iso-8859-1?Q?1ukzX1l42ufUdQbOVd1R20I+Ot8XJMPzB6FkAjPifJPcZA9o/Ef6QxH45B?=
 =?iso-8859-1?Q?/icpbIzFTliuVo/sEbdETtan9BOAmNjKJvLbEt+ILCV30rsOAjAxCxEMoa?=
 =?iso-8859-1?Q?HQPPlBCMyo/IoE9taayDkPRa9OczQ66uw7Oa4Vqo8bk8OoDFSYCPGdxB/i?=
 =?iso-8859-1?Q?hxvkDECMBLSk6Q/9FxPUs1uG0qpwbWFIAJY1fj+j72O0MzWSm4md0JroeQ?=
 =?iso-8859-1?Q?nv9tHFyrzWFQ23XqwEBXmKDYg3W6o+fs/Pf2Fcnh1cVzWCaiNk7PtFI8CE?=
 =?iso-8859-1?Q?+kNv1MalVJBcaM8/p5rxr+umvDcEd8ZzsVxqOSeGvZnjXXyR7BHyjOk+DC?=
 =?iso-8859-1?Q?AAQlbn7vfGAr4N0VgguSOVeKkuCop26JRI0AMNahy2Z+kiPiXM4DmQEudz?=
 =?iso-8859-1?Q?zjQsUR8kgS2AlSlmcMnZYzP/rCKhL5kNh/bGkFPuzzbpWr72AwwdKOf3VY?=
 =?iso-8859-1?Q?+0jZeyjJ12GCFZA6BJmV+Bp+4fVPe05y6AkpBzhtnQ706qjGUEzf3RfsrQ?=
 =?iso-8859-1?Q?BOF0QCsduKpYRNayQzLvosDyQXxvVNOvTofqBI2PMrRLs1kMR/K3vFYb+S?=
 =?iso-8859-1?Q?BaayG38okNy76qPHcGbcCFQAY8A/rys2bFoKod872obJYr94NULWjvQQ3G?=
 =?iso-8859-1?Q?unCKH3+fA23oRoG3OTztwfgML6v8ew5m5cOhdpP6zAzRenXXZM22JxCTTe?=
 =?iso-8859-1?Q?h6+wgfQq9a4iQci21W7ajvnYHKUwaAvOWUXryFc7fCM0MpWezdTXV4175x?=
 =?iso-8859-1?Q?qXba8cgqv1yG/SApUk2GlRcdK41i9wI7wivh4GlmjlxNlYJ9Z168x14VrG?=
 =?iso-8859-1?Q?vdmXSLXgto2D1CRAjLHPowFRxkJa37IoYDXGhtzP/oIx4+Ca7XHSpAfB70?=
 =?iso-8859-1?Q?naZ1R/GNIX3ynlvJOZL61ie5eKCL9PiIaH8BTqhnmWjfU+7aRrA7hDlhVi?=
 =?iso-8859-1?Q?aPRMB1aY184Aj7fOsMauXbBhq5+sUNny7s1WqGXwz6Us2vMoiEOqfacrJS?=
 =?iso-8859-1?Q?g45mDKV5Je5R8X+Yfr2XOQAduRYmt40zNPzoY/Laj77g=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?sEj5OMdAwtFzc0nMDDNJJYQPxudFScmu8DAi7Bt5LAmLPVCsfLf9IFPV3/?=
 =?iso-8859-1?Q?LF+D7IlXyjGlfo575epHLegtClnZh1PVd2JAI1bEHZxz+8JQFsi/RUmEJ1?=
 =?iso-8859-1?Q?gmx07wyHdwd0DSKpS+6seq27hY8Uhl5ofJsbyK2eMVAfn4M9HrPRDvRofx?=
 =?iso-8859-1?Q?/wi9r3hodygXvLOHck8Mm7jlZkqL1KRp7bSVThstifNzqMsp+TykOjNsY3?=
 =?iso-8859-1?Q?Zfw+qyHDZXWxp5ZZpwFcXlNoan57B1BpBznaNrfhEaOZoLuE3OXvS9JA2h?=
 =?iso-8859-1?Q?WKArIJucrp/7p777yZu42Bn4cpzWjFJGCeatzE2gS8KvCLzJO2HBaoHZjX?=
 =?iso-8859-1?Q?2r5yFjIwkE98Wjvlh2uH0Yge6lgqv1ZzTA47/W3Cvk8lvmBWa4kZ3FboL6?=
 =?iso-8859-1?Q?bZvnGm70F9TVnXgHCiefliw+30Q4FY2HyTN6AVaQp+83W1FaQApPiuH0yY?=
 =?iso-8859-1?Q?r2IExj4DZOr1zjoLQFfvcUaBdffvOtALKtU9SjrkEQt/Nd2rbSCHlzrb5N?=
 =?iso-8859-1?Q?WXlD725dREZHFM33x5OPmNv0YetrT4ajrH8yllV+BCsTHH5hOhVUwkRKAP?=
 =?iso-8859-1?Q?47agjwJx0qv/yfW7Xqhe071Desa1XK4IqrD57jX341KcU7MgCjDQbvPK58?=
 =?iso-8859-1?Q?9NB9WFTwGogokNDrLt5MJloITn99L2Tt2WZvnW3iHI34FRdy48La6rE100?=
 =?iso-8859-1?Q?lAloMFJlYpR8tYbhBxbds9Zdr+pnCUBY3nsFaGpxcqRKNOzQy/ZbTGaHBa?=
 =?iso-8859-1?Q?p6soaVTiAQB4nFJQvIF+f4MT8hn5cxFJBuB4wsG0yhdQmbPLGGOZGKEgi3?=
 =?iso-8859-1?Q?H0eb+I2fhWMO6W7UUIDMBm29HzlXdwNbU5rvGPAhr7polF3+J01u1262Ld?=
 =?iso-8859-1?Q?xs9RTPEpiluqNASGzIUnZmPh1huEIkoQW5DHf3n766ln/gAi1/05cPAPdN?=
 =?iso-8859-1?Q?xXw0PXswh02H4oSh/r98JR6CmeuFQP3TIZ6mN8Nmgvj7ZZewfbnR1xi4s5?=
 =?iso-8859-1?Q?R8IWHVEl9eOpz/8XjRj9wpOp/kkjLC0YS0cC0knqLQrkjcAFOVPtcEizbZ?=
 =?iso-8859-1?Q?GmDdZlOwuJWK0V1l3qmiidblzBST5PYRD3dP1zyRpBcI5s0zE0J/kvMMfZ?=
 =?iso-8859-1?Q?BTBliRlDWwcq8yyPJKHtPHhcoHGn4HCX6EUUhxicagu1g60271BoerOc9Z?=
 =?iso-8859-1?Q?JCKRPNezbMQ4eq+8HzrADFTe4mW2XRJfmpBhFAWNWxIqraE7zt2yOEF72N?=
 =?iso-8859-1?Q?Pwtw9z6iUQoHkpphgtKfIWSyZ9Z2tKiHKT7RDn18ng28XGjGdY21NkrncC?=
 =?iso-8859-1?Q?exwi6BniYglImV/sTW5gV13hD/tv+OkOY5p/AeMiBufEfX2jQxIHz7X15x?=
 =?iso-8859-1?Q?YSUEB+Heo7uxOMy1oSbeby3XNyZMQ/ie4RDraNmxa7JNhIOvzwM7RjM3t7?=
 =?iso-8859-1?Q?4MfjBsX1iL0r42eB3RpY1IT3tPbG76mI5moOMwrm6Nj8n7DTmqNB1yq3op?=
 =?iso-8859-1?Q?zONg1S2X0RalcyV6GR9Z/IbjnjLbqyrP5gu2oXAzvIh7SF4/CzKZzwNQPv?=
 =?iso-8859-1?Q?I3txsqRwnSSw3CO4Pv0kFdJ9eOxkjFfMTsGsYExi8najwKAB9DQS0sWguj?=
 =?iso-8859-1?Q?VISTn+nxuOt9S/P15ya6CTRBAcf+KDm9CUGCWxDcjwuBMtBBqIVDdrk9+O?=
 =?iso-8859-1?Q?MqGOmMokCoP4l9CS8iI=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 68a09ed4-ac28-4344-5fa8-08ddeaf662df
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:08.2475
 (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: vf+0nB5AmsWlXOVFgboKJQ3brR+I2l1MdmAZ8buAMx3xS9iU8gp6Wd6a57h2ifDrMl9/eHhVMBLk/qoMDVVCu4qzGj4P+wRRNGXVGJfv1ss=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

To properly deactivate physical eSPI routed to a domain and allow them to
be retriggered after the initial trigger, the LR needs to be updated. The
current implementation ignores interrupts outside the range specified by
the mask 0x3FF, which only covers IRQ numbers up to 1023. To enable
processing of eSPI interrupts, this patch updates the mask to 0x1FFF.

Signed-off-by: Leonid Komarianskyi 

---
Changes in V6:
- updated mask to 0x1fff to avoid confusion
- updated commit message
- removed reviewed-by as new changes requires additional confirmation
  from reviewers

Changes in V5:
- no changes

Changes in V4:
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- no changes

Changes in V2:
- remove unnecessary CONFIG_GICV3_ESPI ifdef guard
---
 xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index 3370b4cd52..c373b94d19 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -211,7 +211,7 @@
 #define ICH_LR_VIRTUAL_SHIFT         0
 #define ICH_LR_CPUID_MASK            0x7
 #define ICH_LR_CPUID_SHIFT           10
-#define ICH_LR_PHYSICAL_MASK         0x3ff
+#define ICH_LR_PHYSICAL_MASK         0x1fff
 #define ICH_LR_PHYSICAL_SHIFT        32
 #define ICH_LR_STATE_MASK            0x3
 #define ICH_LR_STATE_SHIFT           62
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:31:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:31:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108474.1458635 (Exim 4.92)
	(envelope-from )
	id 1utoW7-000403-7H; Wed, 03 Sep 2025 14:31:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108474.1458635; Wed, 03 Sep 2025 14: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 1utoW7-0003zw-1z; Wed, 03 Sep 2025 14:31:19 +0000
Received: by outflank-mailman (input) for mailman id 1108474;
 Wed, 03 Sep 2025 14:31: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 1utoV6-0006B7-JJ
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:16 +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 817568c8-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:14 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:10 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 817568c8-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Pqi+rMUpXNI5xvsrhmhiOyjAIQTFnXge0cE2hC9l8JZpGWje3dGDYVSqYABERVD/RK8JVtuLYrm4X/pL//tlUsDON+bv8cLM2kVL03YCFOXUSPi9BxGbKIc148cJYmXOOkyTTSKkCMuFQ3s7bWYIqulK2afsuZP527ZljpWKiNyYDt8EwIBYSlpIDcOyM49h0si1fXEAy7SGh1pWuhXZ4QPs7iVYt6+v+mzPoPi4ZXfhIpfdWKqFLzfgADCGQH/xgqwTprw4umNbgbYitQtenVXiAkYm9ehYsnrrd2INwgg+fLSxywng1rWn2+OkVDB2aa9v9hZ/SUgXHrDRVqNEHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PLHN8gb/+L/f8ZpI5+SxlAV36wlxEeH+bBgvmGYv+D4=;
 b=U7rI+zf93PdeH+nCevhoaQ2xBJU8+Bw7u4nyCvyKhGrm+AlRRUkQu+fxqbodhyNzvnq/HfJZl4tY+4E5vJfgywpSpd8n7Z9nyVvIkq/FGlgpDalqxJYMRioJ3paK85zJbQDZgw0MfNRCGBrUPyTzi0d+eqAXLOc9kxWVJ2KxEYFW0XyId06uNDriou/jdtW3UX2SgQpQz7PGFQIBHY1IxBHPr1MJXqVI6VEtajhuz9dJPA/duSpcQUKxwEXmveZ+69lEvuKmqcBXBx7tsjbGM/ziObgvE0gT3wicUbPwxtnx9Ul3r//tJrxIX6RT3tUc1Di04jvR1+EQvtuf0tgBaQ==
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=PLHN8gb/+L/f8ZpI5+SxlAV36wlxEeH+bBgvmGYv+D4=;
 b=rHRUW46a0IIV10jLZbaHYAIBRXQ+7yvm4QiKmhV3WzWmbaNuQ4L+FlEBrFGjdb/XP4l7+5xYDQrbXjr6ZFl0MMxSedg3Il1eki1Tm88VPDKg5sBwSFRstAhaV+IZAIOBXoZUW/3bE4kVBPrUmhsw3J1uFssHMi6eUPUNL0StzSoWeQwD7WBpX5cz4p6wyeC4emqeCHnd1m9/zzAAYK6/M9rrWdi+iY2xEsIoNO49IUwWjorFBklvU0XY0q9L28ZCTcmkgYd/zWemJ850Oy4HIVr4w6fx2tdMz5V0vh08wLw7PsMEAYuVYNlVdDXRwu+rsUHgD9pFQzgoZsr6f2PfIQ==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: [PATCH v6 08/12] xen/arm: vgic: add resource management for extended
 SPIs
Thread-Topic: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcHN9AEk+ywvTyYUiwpifc3pdNGw==
Date: Wed, 3 Sep 2025 14:30:10 +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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: c0b416b9-3f9d-40c0-65ae-08ddeaf66377
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?UBsTxzYtB3L3jLc/PfQgnRx9vplWNoFIKDgpJctE8z8MGlDNYhZNO5Nesi?=
 =?iso-8859-1?Q?qKZ5uPozWkLZJctW0uhl5eaIQdiK5+RY9VCsHlHP5lNNTJUl9fTu6ZMcis?=
 =?iso-8859-1?Q?+RhQbtvpepPRw0IHJdXKZhMTUUEFT3Z94LRBo0K3RGs5iVr1PaCYQ/K4Mf?=
 =?iso-8859-1?Q?yCA+sFdojW4JcMXmNDsZTRoQtxYqovzYTsNUwxG1W2uyJZnV5mU99wOuIf?=
 =?iso-8859-1?Q?Ur1hZzHxTwcqaEf6kpQWuN7Juak8q+CrCxYQFcjbiNDAXTR4obPQYHCJp1?=
 =?iso-8859-1?Q?0Ei8BI9PciVuJWI/9HCbDHQovP1jm2vq78KrzHiECI5FLbBO9mOmXh2EGp?=
 =?iso-8859-1?Q?bAZI3wsKDqQTshpQH/FLqZvBTni4UHFy94ps2hhl6lYYJHitDeMzyLOquD?=
 =?iso-8859-1?Q?WChrQ25+1NB9YAWAVQsO2ViQjhI5I1JBpYSQFE+nj8aYz80QreW010pKFW?=
 =?iso-8859-1?Q?BOyFRHAt7N6yKu5qxrv4A4R9neIAHsAlZgUJ2P0uDinNj2opaohE6cubzW?=
 =?iso-8859-1?Q?bwsxZTBVWhkQJWsbmKmlhb9l3Z7DBfW1OZNG3etY/lJsLg5KWdbhRJ5qw5?=
 =?iso-8859-1?Q?2ok8XdqooGQxv9whWX219cjFct1WH0wy2Zxe3WW59YjMC3/wj1jE4Ucxsd?=
 =?iso-8859-1?Q?jPH6cFQlLVhlT0dat7awAz4RAozyCkphZ/Nyao7nztkkv6OOVUDyrFp7Wy?=
 =?iso-8859-1?Q?hmvRM2zMQBLz83/SF1LvEZF6vgkZaZH/mi9cbELDYYTM9H9PDi/RcEEGIw?=
 =?iso-8859-1?Q?mRn9/nQauCPKCRPMRvZsp9df7Aju4d89u3VXl4daLh/HlgEZtLUWiIEfMX?=
 =?iso-8859-1?Q?+UiQF1YrmWkY411gSu5AP/hzYIuzmUAWbxr9AbU5RN9383d8Ue7PyJoow/?=
 =?iso-8859-1?Q?Qu3P97zZnZVYrgVb2BjXZtTPYdBZCI5pRgdauooWtU4bYcdIvWUMMDwJ5R?=
 =?iso-8859-1?Q?XjCmwAagq5FQvmrN0V73UWDvR3n9N5cF7gsU8Y4hCCRx4pzlbN6r5siCwf?=
 =?iso-8859-1?Q?5i8HR9CbUNHozzew6/eCb36WMrnMjrSNlHgFocyhglIRDKq5L38ud4/JnA?=
 =?iso-8859-1?Q?LlbzLowc6mAMCSfA4Tq78Ei0DQg0wsmXvp5TM+wlgDCwjgEyn6Pn89PVHV?=
 =?iso-8859-1?Q?i5krCHz38g81LItJtVVArud4quWX1rkzZphoUlBhSDKdS8sormK2uaP7vP?=
 =?iso-8859-1?Q?HD4MGGeAt+1aSGKz7Je+ba4S5bZ9xWFl6OQVE8S/dFMJiIhxl4iSOftqVa?=
 =?iso-8859-1?Q?4E1zUgOihmKVqqNbQcutWNYQz1clrX5Zaog3DCWicABST0+r15N34nD/yW?=
 =?iso-8859-1?Q?kIuVH0fdBXC+jjA9FfdE9Q5hl2DxMFssmmo2KhDwGVsa/2CUX6Ly7e/wcq?=
 =?iso-8859-1?Q?sbRNDmMi9so/2ny/PTXwdVBd4sgcATc3j3aAcWfbJoheKxJTqenfYoIEph?=
 =?iso-8859-1?Q?wWubFNGzllmtX3drRihBW/6wXhjtkWj0tDeAY6KxUArZp3U14qhSmhkkxT?=
 =?iso-8859-1?Q?JpgVSBIj4Df/FW5SwzbfUE/XAyjddDbE6zFAPUAsVtYw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?lE7JA9s/u/w7U+3VMS9/WDtfQmW7QG31uJ7O5CROIcy7B8xCqdNaJ42Jje?=
 =?iso-8859-1?Q?6R5lj2t+Om0Q3V4tPLcUs7E+iVhjqBYwDdQ/VBB9BPHtPFAboI7vHbvAKU?=
 =?iso-8859-1?Q?j4E0s/wp9W2F1yQloim5TzfA1wpFpD9Zk27cMw8bL+ey0JYNkk/0lCR5P1?=
 =?iso-8859-1?Q?1w+dds/osfOPa4QpGidi+ZuhzHKTfItu0NcCdLv4anWLALr/+qagwXMuYw?=
 =?iso-8859-1?Q?izMPH+ZJ1jI3+vqjd+y95Wo19i5hwJSk1g+Hf7lZLBZ70H/OFDbYDhltmY?=
 =?iso-8859-1?Q?NKMQLUjYL6AhXuIoSE4TwpZNjCcY4S8USkyTDrG/e3Qe1oRIEIJgFsi5Pt?=
 =?iso-8859-1?Q?HOL/258xPG0UPOxzfyzI+UeWuOJ1EICmL+JmRIY3JSOr55W51pCJS6Ism0?=
 =?iso-8859-1?Q?tYMfUDm4yRZtkqHHulweAMFtKbNwfbtFLpud7M1tV/4ixLuIsukt2ojPph?=
 =?iso-8859-1?Q?gAFQrEIdU0KX6BfdT0Ra1I7kojx2X1ll3fW+lovfTsXZZI43dZQZ8Xk2qX?=
 =?iso-8859-1?Q?2ih7yZQE9+O4wGU1As5WmqFk3HD3p0O2Cb1hWT4sPxQlsL4/EMb/+/RIRi?=
 =?iso-8859-1?Q?5uOwuYbqkLhdpisujBagkzgpYDN7cwwT2abFUSMrqyeEQ1jX+9NFHW4eEi?=
 =?iso-8859-1?Q?VWpjZCNyl871xqFP1Lb7Hx5/1/uAAkHWF+BQ1e9iEPcC37wmGIoVUsV7qN?=
 =?iso-8859-1?Q?8Ro6+CaByZ7WeV2H0O9DGVbf108tc5ZDbIN5UTQqtUZHlfDRBj8uWxUkkF?=
 =?iso-8859-1?Q?ndZCXpY1+EIZJGyXxq3M3jeXjvyaQCrbunXTE5IP+8vk+aBnKXaq6mBIe9?=
 =?iso-8859-1?Q?mCBwOvDUxKTi0JvEluC8Bia8ccizQSd2ueSW45xJmJynUcR6zG3nGExSH8?=
 =?iso-8859-1?Q?AQav+JQEk8XoQELHJSX/odx/idqPXDd/Fszx4zpgzH9C8bPs4PHPi9CW0b?=
 =?iso-8859-1?Q?SET0JBnzjPapgDD5Q/NYiI8y1j9sLgySrKxJRJxZ1RRzZFu7UGG2ueKhV2?=
 =?iso-8859-1?Q?h9T9yTZgLqhwTO0mVulqEIIl04kTxM+pgqLAX3PS/xtxWHAYN4oCcMfzdm?=
 =?iso-8859-1?Q?WCkbbv69KLpj9aWCeBnJo36P4JZR27CEo9Q56/G7cJhwmnQVWDMHTB79CA?=
 =?iso-8859-1?Q?QStcsE2xtVWaP0afup67Yx/f9GNR1kcIw1X4dUzGJWwVVMVgCmv3tz9dY9?=
 =?iso-8859-1?Q?V7w63mjjKbIrWEe8R2bIZsNE5tsdfRx+esjvtcRqnuqcR2VLHkuHz757Nd?=
 =?iso-8859-1?Q?K6/ZVSJq6XGcDuEdgwyVnA+ZLlIxyiHiFbWCiAxpctpsjiYU0MhpHvuxAa?=
 =?iso-8859-1?Q?0IJXLcWK65oCr3Bw/ZPQCG0EqAGV3uYSaSi0SiBTFDShqTqbolbXRJzYHF?=
 =?iso-8859-1?Q?ruwryQX7I+mV/Q46QZfuJ/HoC8aLhwc3qFJSmD0hDtZERzUQ1902KInjdE?=
 =?iso-8859-1?Q?BpbpK7cSJOzobwGlaNp2HBktG3xTxq3FdP+fLgKwnkmQrMblNHfE7i9Trp?=
 =?iso-8859-1?Q?gTrk4joDMN7bTcWbaki5670eOMzFTtti0OsW9ufH84i47G6qbJ2lKp6/Un?=
 =?iso-8859-1?Q?dyLxW2B1lnFgM7vlIE0CAva670rz/Xbo5ZcptJQ/QNH5K05ZlgqpYmtdqD?=
 =?iso-8859-1?Q?QVAlNKyhdnoysTBAGk0t3lMB36V++w1VLGoGWjatSt7hRMgcCt3h9ty8Vi?=
 =?iso-8859-1?Q?Al2rk0ZCSWoJSVr6GSY=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0b416b9-3f9d-40c0-65ae-08ddeaf66377
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:10.7667
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0+EtT31HBg/1NObwzFhtxqClXMqBzEouPexoawcRFtnjPjL+x0jKgD/L/F6akJUnpXjyL1qiX4isCDUBHEqQlDBWFJ3Khbhib+f+2pGzVNI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
number of eSPIs, based on what is supported by the hardware and
requested by the guest. A new field, ext_shared_irqs, is added
to the VGIC structure to store information about eSPIs, similar
to how shared_irqs is used for regular SPIs.

Since the eSPI range starts at INTID 4096 and INTIDs between 1025
and 4095 are reserved, helper macros are introduced to simplify the
transformation of indices and to enable easier access to eSPI-specific
resources. These changes prepare the VGIC for processing eSPIs as
required by future functionality.

The initialization and deinitialization paths for vgic have been updated
to allocate and free these resources appropriately. Additionally,
updated handling of INTIDs greater than 1024, passed from the toolstack
during domain creation, and verification logic ensures only valid SPI or
eSPI INTIDs are used.

The existing SPI behavior remains unaffected when guests do not request
eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
option is disabled.

Signed-off-by: Leonid Komarianskyi 

---
Changes for V6:
- introduced a new function for index to virq conversion, idx_to_virq.
  This allows the removal of eSPI-specific functions and enables the
  reuse of existing code for regular SPIs
- fixed the return value of vgic_allocate_virq in the case of eSPI
- updated the error message in route_irq_to_guest(). To simplify it and
  avoid overcomplicating with INTID ranges, propose removing the
  information about the max number of IRQs
- fixed eSPI rank initialization to avoid using EXT_RANK_IDX2NUM for
  converting the eSPI rank to the extended range
- updated the recalculation logic to avoid the nr_spis > 1020 -
  NR_LOCAL_IRQS check when nr_spis is reassigned in the case of eSPI
- fixed formatting issues for macros
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch
- minor change: changed int to unsigned int for nr_espis

Changes in V5:
- removed the has_espi field because it can be determined by checking
  whether domain->arch.vgic.nr_espis is zero or not
- since vgic_ext_rank_offset is not used in this patch, it has been
  moved to the appropriate patch in the patch series, which implements
  vgic eSPI registers emulation and requires this function
- removed ifdefs for eSPI-specific macros to reduce the number of ifdefs
  and code duplication in further changes
- fixed minor nit: used %pd for printing domain with its ID

Changes in V4:
- added has_espi field to simplify determining whether a domain is able
  to operate with eSPI
- fixed formatting issues and misspellings

Changes in V3:
- fixed formatting for lines with more than 80 symbols
- introduced helper functions to be able to use stubs in case of
  CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of
  #ifdefs
- fixed checks for nr_spis in domain_vgic_init
- updated comment about nr_spis adjustments with dom0less mention
- moved comment with additional explanations before checks
- used unsigned int for indexes since they cannot be negative
- removed unnecessary parentheses
- move vgic_ext_rank_offset to the below ifdef guard, to reduce the
  number of ifdefs

Changes in V2:
- change is_espi_rank to is_valid_espi_rank to verify whether the array
  element ext_shared_irqs exists. The previous version, is_espi_rank,
  only checked if the rank index was less than the maximum possible eSPI
  rank index, but this could potentially result in accessing a
  non-existing array element. To address this, is_valid_espi_rank was
  introduced, which ensures that the required eSPI rank exists
- move gic_number_espis to
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
- update vgic_is_valid_irq checks to allow operating with eSPIs
- remove redundant newline in vgic_allocate_virq
---
 xen/arch/arm/include/asm/vgic.h |  12 +++
 xen/arch/arm/irq.c              |   3 +-
 xen/arch/arm/vgic.c             | 174 ++++++++++++++++++++++++++++++--
 3 files changed, 176 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 3e7cbbb196..1cf0a05832 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -146,6 +146,10 @@ struct vgic_dist {
     int nr_spis; /* Number of SPIs */
     unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
     struct vgic_irq_rank *shared_irqs;
+#ifdef CONFIG_GICV3_ESPI
+    struct vgic_irq_rank *ext_shared_irqs;
+    unsigned int nr_espis; /* Number of extended SPIs */
+#endif
     /*
      * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
      * struct arch_vcpu.
@@ -243,6 +247,14 @@ struct vgic_ops {
 /* Number of ranks of interrupt registers for a domain */
 #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
=20
+#ifdef CONFIG_GICV3_ESPI
+#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis + 31) / 32)
+#endif
+#define EXT_RANK_MIN (ESPI_BASE_INTID / 32)
+#define EXT_RANK_MAX ((ESPI_MAX_INTID + 31) / 32)
+#define EXT_RANK_NUM2IDX(num) ((num) - EXT_RANK_MIN)
+#define EXT_RANK_IDX2NUM(idx) ((idx) + EXT_RANK_MIN)
+
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
=20
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index c934d39bf6..c2f1ceb91f 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -494,8 +494,7 @@ int route_irq_to_guest(struct domain *d, unsigned int v=
irq,
     if ( !vgic_is_valid_line(d, virq) )
     {
         printk(XENLOG_G_ERR
-               "the vIRQ number %u is too high for domain %u (max =3D %u)\=
n",
-               irq, d->domain_id, vgic_num_irqs(d));
+               "invalid vIRQ number %u for domain %pd\n", irq, d);
         return -EINVAL;
     }
=20
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 2bbf4d99aa..b42aee8d0c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,11 +25,61 @@
 #include 
=20
=20
+static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx)
+{
+    if ( idx >=3D vgic_num_irqs(d) )
+        return espi_idx_to_intid(idx - vgic_num_irqs(d));
+
+    return idx;
+}
+
 bool vgic_is_valid_line(struct domain *d, unsigned int virq)
 {
+#ifdef CONFIG_GICV3_ESPI
+    if ( virq >=3D ESPI_BASE_INTID &&
+         virq < espi_idx_to_intid(d->arch.vgic.nr_espis) )
+        return true;
+#endif
+
     return virq < vgic_num_irqs(d);
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+/*
+ * Since eSPI indexes start from 4096 and numbers from 1024 to
+ * 4095 are forbidden, we need to check both lower and upper
+ * limits for ranks.
+ */
+static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
+{
+    return rank >=3D EXT_RANK_MIN &&
+           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d);
+}
+
+static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
+                                                       unsigned int rank)
+{
+    return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)];
+}
+
+#else
+static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
+{
+    return false;
+}
+
+/*
+ * This function is stub and will not be called if CONFIG_GICV3_ESPI=3Dn,
+ * because in this case, is_valid_espi_rank will always return false.
+ */
+static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
+                                                       unsigned int rank)
+{
+    ASSERT_UNREACHABLE();
+    return NULL;
+}
+#endif
+
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)
 {
@@ -37,6 +87,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struct =
vcpu *v,
         return v->arch.vgic.private_irqs;
     else if ( rank <=3D DOMAIN_NR_RANKS(v->domain) )
         return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else if ( is_valid_espi_rank(v->domain, rank) )
+        return vgic_get_espi_rank(v, rank);
     else
         return NULL;
 }
@@ -117,6 +169,54 @@ int domain_vgic_register(struct domain *d, unsigned in=
t *mmio_count)
     return 0;
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+static unsigned int vgic_num_spi_lines(struct domain *d)
+{
+    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
+}
+
+static int init_vgic_espi(struct domain *d)
+{
+    unsigned int i, idx;
+
+    if ( d->arch.vgic.nr_espis =3D=3D 0 )
+        return 0;
+
+    d->arch.vgic.ext_shared_irqs =3D
+        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d));
+    if ( d->arch.vgic.ext_shared_irqs =3D=3D NULL )
+        return -ENOMEM;
+
+    for ( i =3D d->arch.vgic.nr_spis, idx =3D 0;
+          i < vgic_num_spi_lines(d); i++, idx++ )
+        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i],
+                              espi_idx_to_intid(idx));
+
+    for ( i =3D 0; i < DOMAIN_NR_EXT_RANKS(d); i++ )
+        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i],
+                       EXT_RANK_IDX2NUM(i), 0);
+
+    return 0;
+}
+
+#else
+static int init_vgic_espi(struct domain *d)
+{
+    return 0;
+}
+
+static unsigned int vgic_num_spi_lines(struct domain *d)
+{
+    return d->arch.vgic.nr_spis;
+}
+
+#endif
+
+static unsigned int vgic_num_alloc_irqs(struct domain *d)
+{
+    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS;
+}
+
 int domain_vgic_init(struct domain *d, unsigned int nr_spis)
 {
     int i;
@@ -133,7 +233,39 @@ int domain_vgic_init(struct domain *d, unsigned int nr=
_spis)
=20
     /* Limit the number of virtual SPIs supported to (1020 - 32) =3D 988  =
*/
     if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+#ifndef CONFIG_GICV3_ESPI
         return -EINVAL;
+#else
+    {
+        /*
+         * During domain creation, the dom0less DomUs code or toolstack
+         * specifies the maximum INTID, which is defined in the domain
+         * config subtracted by 32 to cover the local IRQs (please see
+         * the comment to VGIC_DEF_NR_SPIS). To compute the actual number
+         * of eSPI that will be usable for, add back 32.
+         */
+        nr_spis +=3D 32;
+        if ( nr_spis > espi_idx_to_intid(NR_ESPI_IRQS) )
+            return -EINVAL;
+
+        if ( nr_spis >=3D ESPI_BASE_INTID )
+        {
+            unsigned int nr_espis =3D min(nr_spis - ESPI_BASE_INTID, 1024U=
);
+
+            /* Verify if GIC HW can handle provided INTID */
+            if ( nr_espis > gic_number_espis() )
+                return -EINVAL;
+
+            d->arch.vgic.nr_espis =3D nr_espis;
+            /* Set the maximum available number for regular SPIs */
+            nr_spis =3D VGIC_DEF_NR_SPIS;
+        }
+        else
+        {
+            return -EINVAL;
+        }
+    }
+#endif
=20
     d->arch.vgic.nr_spis =3D nr_spis;
=20
@@ -145,7 +277,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_=
spis)
         return -ENOMEM;
=20
     d->arch.vgic.pending_irqs =3D
-        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
+        xzalloc_array(struct pending_irq, vgic_num_spi_lines(d));
     if ( d->arch.vgic.pending_irqs =3D=3D NULL )
         return -ENOMEM;
=20
@@ -156,12 +288,16 @@ int domain_vgic_init(struct domain *d, unsigned int n=
r_spis)
     for ( i =3D 0; i < DOMAIN_NR_RANKS(d); i++ )
         vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0);
=20
+    ret =3D init_vgic_espi(d);
+    if ( ret )
+        return ret;
+
     ret =3D d->arch.vgic.handler->domain_init(d);
     if ( ret )
         return ret;
=20
     d->arch.vgic.allocated_irqs =3D
-        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
+        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d))=
);
     if ( !d->arch.vgic.allocated_irqs )
         return -ENOMEM;
=20
@@ -182,9 +318,12 @@ void domain_vgic_free(struct domain *d)
     int i;
     int ret;
=20
-    for ( i =3D 0; i < (d->arch.vgic.nr_spis); i++ )
+    for ( i =3D 32; i < vgic_num_alloc_irqs(d); i++ )
     {
-        struct pending_irq *p =3D spi_to_pending(d, i + 32);
+        struct pending_irq *p;
+        unsigned int virq =3D idx_to_virq(d, i);
+
+        p =3D spi_to_pending(d, virq);
=20
         if ( p->desc )
         {
@@ -198,6 +337,9 @@ void domain_vgic_free(struct domain *d)
     if ( d->arch.vgic.handler )
         d->arch.vgic.handler->domain_free(d);
     xfree(d->arch.vgic.shared_irqs);
+#ifdef CONFIG_GICV3_ESPI
+    xfree(d->arch.vgic.ext_shared_irqs);
+#endif
     xfree(d->arch.vgic.pending_irqs);
     xfree(d->arch.vgic.allocated_irqs);
 }
@@ -323,10 +465,12 @@ void arch_move_irqs(struct vcpu *v)
      */
     ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
=20
-    for ( i =3D 32; i < vgic_num_irqs(d); i++ )
+    for ( i =3D 32; i < vgic_num_alloc_irqs(d); i++ )
     {
-        v_target =3D vgic_get_target_vcpu(v, i);
-        p =3D irq_to_pending(v_target, i);
+        unsigned int virq =3D idx_to_virq(d, i);
+
+        v_target =3D vgic_get_target_vcpu(v, virq);
+        p =3D irq_to_pending(v_target, virq);
=20
         if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->s=
tatus) )
             irq_set_affinity(p->desc, cpu_mask);
@@ -539,7 +683,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsi=
gned int irq)
     else if ( is_lpi(irq) )
         n =3D v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq)=
;
     else
-        n =3D &v->domain->arch.vgic.pending_irqs[irq - 32];
+        n =3D spi_to_pending(v->domain, irq);
     return n;
 }
=20
@@ -547,7 +691,12 @@ struct pending_irq *spi_to_pending(struct domain *d, u=
nsigned int irq)
 {
     ASSERT(irq >=3D NR_LOCAL_IRQS);
=20
-    return &d->arch.vgic.pending_irqs[irq - 32];
+    if ( is_espi(irq) )
+        irq =3D espi_intid_to_idx(irq) + d->arch.vgic.nr_spis;
+    else
+        irq -=3D 32;
+
+    return &d->arch.vgic.pending_irqs[irq];
 }
=20
 void vgic_clear_pending_irqs(struct vcpu *v)
@@ -668,6 +817,9 @@ bool vgic_reserve_virq(struct domain *d, unsigned int v=
irq)
     if ( !vgic_is_valid_line(d, virq) )
         return false;
=20
+    if ( is_espi(virq) )
+        virq =3D espi_intid_to_idx(virq) + vgic_num_irqs(d);
+
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
 }
=20
@@ -685,7 +837,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
     else
     {
         first =3D 32;
-        end =3D vgic_num_irqs(d);
+        end =3D vgic_num_alloc_irqs(d);
     }
=20
     /*
@@ -700,7 +852,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
     }
     while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
=20
-    return virq;
+    return idx_to_virq(d, virq);
 }
=20
 void vgic_free_virq(struct domain *d, unsigned int virq)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:31:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:31:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108476.1458642 (Exim 4.92)
	(envelope-from )
	id 1utoW7-00046s-Sq; Wed, 03 Sep 2025 14:31:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108476.1458642; Wed, 03 Sep 2025 14: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 1utoW7-00045r-Ki; Wed, 03 Sep 2025 14:31:19 +0000
Received: by outflank-mailman (input) for mailman id 1108476;
 Wed, 03 Sep 2025 14:31: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 1utoVL-0006B7-MO
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:30:31 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89614348-88d2-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:30:29 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7844.eurprd03.prod.outlook.com (2603:10a6:20b:343::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 14:30:25 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 14:30: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: 89614348-88d2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vBVCcbVA6eC6D1piIimZ2U6kpZ6dMJLnET+5HhFpWXb2EbduRq8Fs5PP6tW3Gnyj9dCdebm0XbxNnOG/5eYhJdTwUcl4zeX09ES8/jeFRnRa99Vb6J0M7bJvCCCv0X5ntHWCQDvdRG4FVHdk0depC44PgEPgtd9HMMGg6XqUwPlxH3344Gmr1/TVHWdBxQStMbapwBQ2hO+1+K+ySePbdf8IUXZ4Hq1g39LF79pUAHlGdhLyHtwfl9AvVkPDrub/KpvCsgK7ZgZVbOL9zOwPNpeFR/3lkyDqpFm4mChGODY/pT+iTklaNiQ/RQx/B/8O3ahul0YjbqQvMu/f/WReAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=m3NrOPn8zFlka5eJv+Rl5yy68/xDlMmoUaUQ1spR/Uw=;
 b=hufCOt8EFQXJuETDey2FqzMn7iys4cskBGWc6zCUHm4ZGOUD5ALp9slMmvgvFNpJ1E105b3KjXCpHMxEhSycuIvJ45CRoUPlInpFJ5hqWX9gV1iFHtuy/K1OdHbkYQ8gzFDQuH0zPgzMho5YHSKbHVppqZXBbRao6wNAi1MOO1n5ZT7PMMy8tTLNj5tZUrfRvxjy5RNM30kUvVMG9DpJPWnDM75WfHa+gdUb2Ol1oh9g63RP4JZGyDyXQ7rhID5xPdswMaphXlYvD2t8jEAwbT9gd/NPw2t1j2nF693XMppX+Q5tLVSnSjAhvyiwzrZIaB/z66F8RHewX4T6wSQL0w==
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=m3NrOPn8zFlka5eJv+Rl5yy68/xDlMmoUaUQ1spR/Uw=;
 b=pPbMr/bAgJOTDRRCYHVW6A4fM8MxZcq6gNuDrQPNG83LjHUisNK8aJDzuB6oEc5gDwYI6HTwDHEJo8Yk67uugjSPHG0Wh36TbVXxxAFz6//wo53BL8klpqo2OsudaMmX7xq7y1AEjnOB3I8RN2KvaiJA5TDb9kmBRHGp6Ednoo7cHRi+nvK/2Liwebf8hI9JkzHiPlgzn09UfudLeFEigwmoAt3On8hPJdSalSdaB29O96eZN0bsYbC8I5sGRy+hn7y9fdBoIvPPG4Hiu779v9GCyUWui/RhK6qyOazua+jVSVqBLk1Ri5Ldom4H3dblhOiXJOjOUkVlpIH/G7/bWw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v6 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI support
Thread-Topic: [PATCH v6 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI
 support
Thread-Index: AQHcHN9JAyQfw4t69UeYZUaq3Hk3PA==
Date: Wed, 3 Sep 2025 14:30:25 +0000
Message-ID:
 <607ddcbf90a16c460a1c4ad8c3242e420e16fef8.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|AS8PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: 14c75104-e888-4290-7885-08ddeaf66c61
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?SYvtTW/EjTYkLZNr+AxP0wH6M8xLgKLokOypvMWhJWIslc7JLv/tSZQES4?=
 =?iso-8859-1?Q?sv4i12ecZkv9WNsbF5o2qWPG3A5zj22/WdKx+EN9CNyTGKIz6abCaXYoGO?=
 =?iso-8859-1?Q?UGRoWwAdcJQewESIHIxhpMfZugczWGpkQfVXjyO4VwpVsisuQL+6brGp/a?=
 =?iso-8859-1?Q?GO9Mzc5LcWzLX6pdb+whjjlLR4WuObJWgCNE2taWhhVVkdjr+cREf2l8hs?=
 =?iso-8859-1?Q?TisX2/k+SGbYN4trrzPAynvk/X/FkfQ0r1/YRKwSrpRL6lwYlErrllE/wj?=
 =?iso-8859-1?Q?gXhcXhZYPWtYsdUd5EOOODtkgfG3JGbutG361+5unHIhb2eYhEb3lilH6q?=
 =?iso-8859-1?Q?7af2+ipYVfALZEal6UYOocYNuIR8rchq0lxk39ZTRzgtmUe7ciPYKPoe5r?=
 =?iso-8859-1?Q?Vwg4JeV94NROIrZ6cWlvJCQa/puuZ7+68nJjjEM/ahlpmm0ZJ0OmeqIVPV?=
 =?iso-8859-1?Q?GuouWqO8pgwLWDFRaUAH/rAn65ydYksLXjaHJT1mqdQub8oFm88r4fqB/F?=
 =?iso-8859-1?Q?IkVAGABtx6Nj5zPYcgkR/+XQJAPYblai1mfeFjaYmN6s/OMPevrMuia20f?=
 =?iso-8859-1?Q?UOu3sGUb5aeuHIq4teuvIrmQ5Al/ClsNKYUWfphiBL537LgfCvS60mEwO4?=
 =?iso-8859-1?Q?5LRY5ZTlmuNWIY7sv4fP5RLOoDHSvFFIODxI4QmNF/Leelargx757plSty?=
 =?iso-8859-1?Q?nksSjJGb38Xr62ktqs+Va1aVUOUTiW/wL0C5nGxExaAnHfGEeF0WnIFyK3?=
 =?iso-8859-1?Q?XPs9rWPER95sctwc0j6HFzhxqqd/jCViCEJAKZi5+xVK39F3KxwFb+/qat?=
 =?iso-8859-1?Q?lBbBU8ltN9YqLkg5ahLSpNULUEiyPi9QhEqsUy439GwgI4h8kV7a/9uYLW?=
 =?iso-8859-1?Q?sWwoSq/h6lIOJVzWCs24ZTjZzn/inSPxI6Mx+q0u1a8+Ox4OAvxttJmz1s?=
 =?iso-8859-1?Q?nfSNGZvMocVRPzLkz16jKJP8q+zSF2b5pz/FysfQmMOC2Y8Wmnz+lMOAZU?=
 =?iso-8859-1?Q?WX2g9NNyw+pDc2AP1TL01WhAdgyOJ9AEvtCRyxafFlsaTq+uLZ+/b8my7U?=
 =?iso-8859-1?Q?xISOssdyAG2SGXBYn0syJQ99LjyZPtiItp8lXS603fI0LBRjICiItY2yK1?=
 =?iso-8859-1?Q?y/AXwB1RGkphZfulDkN783QiRzuD+lKjO5x2Ie3PbIFTFDNkckwxSajDeb?=
 =?iso-8859-1?Q?5eWkxAFAeDnGF6LGCdPyu4kXid4fEFRrBU0hrexjIlMGgvBpj53KgtceTf?=
 =?iso-8859-1?Q?eiwvmskCIO9lPx0gTp/lsw5xkMQ4FvQl4TNTEi2SqY3mNGwu8LpaC9C5EC?=
 =?iso-8859-1?Q?1xW7jjEUe4RY6SJqj50hDHXPQqutBlSAwk/DpCGz8jcdNr/fKU0qFY0MH9?=
 =?iso-8859-1?Q?HWWBCqRaiPTYFDWzV7ymmrC3SDdDcVcWsICQ/Dg1rNwXy5QFwm+5lUNqWA?=
 =?iso-8859-1?Q?CXlZix33FnZAA0GosLJez23gpbsgP28KJ/SHt8wMkOryWghP7pbociFVzC?=
 =?iso-8859-1?Q?E=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?1GgDm0+UsgK67l+Bd+BOZC550JsJ3nZ1ckp4QOrNHJZNZmxAm37h/ZSXIb?=
 =?iso-8859-1?Q?/jPerpVcfziWyH19JCAFI3/jtZea1GF+f+5omupc/Fr9MDB/lzuxAqqB3Z?=
 =?iso-8859-1?Q?Knyll0+vn1OK23EaOmfOwYX0tMFrxMgvw42Ou4tBjn+0kSYTRkTFsK50aE?=
 =?iso-8859-1?Q?pHmyiP7qCLkB1ihu2G2Snpkki+kEIhO+eT3ZlLGaQrFliB+wGW/9ofMAQ5?=
 =?iso-8859-1?Q?YDGsJOKXVfHa6Vi2oCVMzWv4ONkxvcT/KEJYGWqH01KxVO9b8W22iGuWH5?=
 =?iso-8859-1?Q?Q8AOCNohOzB4Xw3gOdIFU4DSZ/1gxVZHdiSCyVK/6o22VSAhUG/hmpXf6T?=
 =?iso-8859-1?Q?7ZUkITdnCOi8IytmgyMoJAexyYO1dzUD8cILx6FaKgtde803LsjaFNOBmj?=
 =?iso-8859-1?Q?cuWZWAjiDC6kMvIwbXGPLID63bhGD+jCVE7jhZAI+0DwmP7PuDpiiLvFIu?=
 =?iso-8859-1?Q?0Ok2P9FmsVLgkID71pqUZj6tPlIv5zq9T5M/PUF4GqxO9yglcjJ1kZB9IF?=
 =?iso-8859-1?Q?GZOZGlNFChRF9ox3Sm3DU1CRT+eNpl+NZvBVunBA98FLe9OKdruvg8s/4r?=
 =?iso-8859-1?Q?9CfEnZ5g/XLj5a5f2aySanDEktvN6Rbp/ybPf0dCAkEsBxzb33TDF6wc7P?=
 =?iso-8859-1?Q?PMQaNOFfNYmsoY6t7jlak52U1zCe725I8afjvgu1G4WVc78sIbXeZHzJQe?=
 =?iso-8859-1?Q?X1+9TxVdFuqWcc6Rd9sDlHdX6GPr5K3tos5D53aATmTMkipJz27gT+EHyH?=
 =?iso-8859-1?Q?eVnhjxqU+Md3rHSEAPE1U2thK9bsqgzgoZaVw2w+e2WgFhn7Jb6B7uXwP6?=
 =?iso-8859-1?Q?totpY22o+vOhfFa8ZreXGQtE7dtI1bCaFEEOBBo4oeaPFY83i5I6jHt0fu?=
 =?iso-8859-1?Q?2AZv1/9DQNbLkK3H0VZRuZXV/gWw+PiS7FqPzO+jZ+azMR7k2/Hg0y4N7w?=
 =?iso-8859-1?Q?5dJyKHHN+Dv64b50HQOtVhsVkH/DLghMHcYNymluXOjIiwXSLBK2aalMsR?=
 =?iso-8859-1?Q?z0bRqFeLx2KrLu2Lyw5CQSaW2klsr4MZT4bC3XliZ5XBMfVwMkYbc8a57B?=
 =?iso-8859-1?Q?XSHPOgav3GdvmJMQFw1KgZ8BW5rtf3ez5nGEppWIKLfJmGYdNyDlAfB/lL?=
 =?iso-8859-1?Q?+r8w65Si9d2e+JDhxH8IpRtiXA+SFaMr9/BdCMc5tsAp1K+LdADFAzE1lm?=
 =?iso-8859-1?Q?E8nuxxWqwQl4is9r91qkeHd++TGa2C4seqO1CSCO/rPI3ZzeSr4QnWaG6C?=
 =?iso-8859-1?Q?29kPGnmtDcuiIUPuyu14/ihBGTmf2CQfzFDobtOMaECD6RqHEbTgpfeCbO?=
 =?iso-8859-1?Q?ZmNaEuLpiMJGHh0u2MbewTdF4QUHx5syrt69zs4tET88/2vN43u9nnDe1j?=
 =?iso-8859-1?Q?+qE77R5cKyvhT4p7AhM+4QCAQ8CcrUK3ogNUaEJxoTEtw3ZPbuCX+feqPk?=
 =?iso-8859-1?Q?pwPnzga0zddI6cRKeiZJxQ5+mla5tljsLp9YLP5nCeio6wYxdInkGl3T+q?=
 =?iso-8859-1?Q?dDsDvJZjKc6mxCMuUObUjilZLzgcouIB+T9U77TE+nW72tP6T3HuosAdQq?=
 =?iso-8859-1?Q?mEhoYGDsUhYgGhpSazd3hi0OvKpiSk4tkHSGkMm9rwwWYMnUUahFmpdEFi?=
 =?iso-8859-1?Q?pQBzhMZHXPo+3XakeVWyrq98N+HOAcvUwVNXVkkpxDirj428P0M56wIAIg?=
 =?iso-8859-1?Q?7bK5AgAs1lvTdc0l2fc=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14c75104-e888-4290-7885-08ddeaf66c61
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 14:30:25.7608
 (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: njUmRyD9eI4KsX9qxPOzMt/Fqtinu9bB0tSj6j7t/4+MuSBJ+V8MzV5Fp+xy65IcOCyQQ+2tkgMJsontZTjCCu79x/YSROyuup+SCx/Q4M8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7844

The GICv3.1 eSPI (Extended Shared Peripheral Interrupts) range is
already supported with CONFIG_GICV3_ESPI enabled, so this feature should
be mentioned in CHANGELOG.md.

Signed-off-by: Leonid Komarianskyi 
Acked-by: Oleksii Kurochko

---
Changes in V6:
- no changes

Changes in V5:
- extended changelog update with a brief explanation of what eSPI is
- added acked-by from Oleksii Kurochko, which was received for V3:
  https://lore.kernel.org/xen-devel/bce5e07c-eee7-481b-a833-4d5d8bbce78f@gm=
ail.com/

Changes in V4:
- no changes

Changes in V3:
- introduced this patch
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5f31ca08fe..31b4ded444 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -29,6 +29,8 @@ The format is based on [Keep a Changelog](https://keepach=
angelog.com/en/1.0.0/)
=20
  - On Arm:
     - Ability to enable stack protector
+    - GICv3.1 eSPI (Extended Shared Peripheral Interrupts) support for Xen
+      and guest domains.
=20
 ### Removed
  - On x86:
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 14:41:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 14:41:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108532.1458656 (Exim 4.92)
	(envelope-from )
	id 1utofc-00073C-OJ; Wed, 03 Sep 2025 14:41:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108532.1458656; Wed, 03 Sep 2025 14:41: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 1utofc-000735-KE; Wed, 03 Sep 2025 14:41:08 +0000
Received: by outflank-mailman (input) for mailman id 1108532;
 Wed, 03 Sep 2025 14:41: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 1utofb-00072g-IC
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 14:41:07 +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 050d1ca6-88d4-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 16:41:04 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-61ec59e833aso2839488a12.1
 for ; Wed, 03 Sep 2025 07:41:04 -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-aff08b86833sm1298942166b.48.2025.09.03.07.41.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 07:41: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: 050d1ca6-88d4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756910464; x=1757515264; 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=e5gylBqcfTlrBhktlHFUaOyZ1wYujkpAVleyJVZn6gk=;
        b=SqH7E2WbDQjc6Nv0p1PQhlUd804ORWVNQeIKSCQMvdg48QdClNm6As4j2GCt1573dw
         gqg1FK4wMDrG1hBCHzmbQn7TPngCzGKTHB0rHiJaAY7VUQoQfRwWX6AFQ8pusendkvHp
         utEy5gpMScQRw4J2GCJNfUVmjTW9dLeav+/qex17Oia5KoLn5MgwnYw4zJ4XpsUwMzXP
         l8/gkXcEJ1VJUrj5qYqBzWcDrmrkcSkeCEATnXAC8tWWGqc0hpbLyb2DLAHZL50taILk
         10+MbjshtNFwrLAT04QAw3BMHgPf/B09y/2Q5sNodcA3qT4We4bUgkWrbWl5s+bIQPYN
         0EcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756910464; x=1757515264;
        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=e5gylBqcfTlrBhktlHFUaOyZ1wYujkpAVleyJVZn6gk=;
        b=HtKG27d4Dp/pJ1ipxeLp/SKty8qsYFbylgEMFBgXYxLfGX1Ar9L/hKYEV/+UB2HMQ/
         ux0gHMQFZUV2tvVqTiCbPUmZjQ8mjhgyN6ozr0+J41ydBZuUP2jAPoMJgiwXJhJT2LTd
         WFURmzoCToAtEUR1PCiF1bSmNhgqkhUo3eCKNX00ywW4IWfEZY/Yo702epcyF1oS6OeE
         xtY5qGSZR/Prui++XVfIl/J4E7AaR5rlKdsxcYd11caI0BhLeA74SdFBYOzii0GhAh4V
         gzjYF1YN10BjwZZHfIvIPbVN8yr4U0G+h0P0Qj+AVbdMeB0xLElIkiLuR04bhE5aT2UM
         aZ6A==
X-Forwarded-Encrypted: i=1; AJvYcCUSQ1SVYW4k3vCn5BUW6UnjNkDsVs8PPQoqb+gA67noyJv1pL3p2Z922WByJ7K7ERWpdPsnH0eCG3o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yybe+O7rAeYyLMVL2iEQkRfOA43s4hi2uyboX7Wlbap2GN1fZBx
	V+PzAs2SOTsrHg9MdrhtjSQXZZwc9YKagwAoWjiqQejCXGj4B3vDfTsi
X-Gm-Gg: ASbGncue3+8QwH0hQ+UL4dQ3SPo05I/MmEb2lDIAlfxRA96rl4aPAzXPP2x8/n4Hq3S
	F02w4xwwjP2t7n8nnVZfDbFqCmc+Fo7JD83sIvxv0CcOooJ8PBI0lqD7g1o4cOQ9238mjeyEx6s
	59qBTLnJlGQF06UneCgHxZdrNNTV4rgkoDeLOOiT4JJAX1DPYipfMAO5aILe5ku9JPX0DIKeqg/
	49HtiFJ4pWN38IfkOOvcyAAR/fI4I4zcHuHu1qosPMzWBbPUl7J13Q6vfgu/+y91Ovp8SFv4ULv
	sZW2y+SbBKAlMbxJA4StOvcofqBuBa6gOp0RhakAswVpx8SgbS6La/LHpKLH95nLMSvq0i8vV75
	p2pAasjJ59CFArv/kYGv9ykaRpeFckyNTfHIZLgOMCus/NmrCaJA2VWoWmc1rL49zeFPeru6ntL
	9M1sxOBqg=
X-Google-Smtp-Source: AGHT+IFaPwXpn6xcYWJcssWCvdMCAVPT2zjOekeaAUu9FL4NIElajJnRRzKTHZSfGkWtm/YY32EkbA==
X-Received: by 2002:a17:906:794e:b0:b04:6d3d:9936 with SMTP id a640c23a62f3a-b046d3d9ae5mr204554666b.51.1756910464010;
        Wed, 03 Sep 2025 07:41:04 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------hBmKXonvLQj1jynq2TQbEZQZ"
Message-ID: <4600abf5-000f-436f-b80c-06f42ce22f62@gmail.com>
Date: Wed, 3 Sep 2025 16:41:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Domctl series as a fix to PV_SHIM_EXCLUSIVE, was: [PATCH]
 xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE
To: Stefano Stabellini 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 xen-devel@lists.xenproject.org, Penny Zheng ,
 jbeulich@suse.com
References: <20250815102728.1340505-1-Penny.Zheng@amd.com>
 
 
 <2035b14e-3836-4e80-9dad-8a49ca90864a@suse.com>
 
 <49416df6-83c8-4fa3-bf81-2d1e504ef31b@suse.com>
 
 
 
 
 <5f5ba1dd-1252-4740-8c64-e4fcd8a7ac32@suse.com>
 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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

Hello Stefano,

On 9/3/25 12:16 AM, Stefano Stabellini wrote:
> Hi Oleksii,
>
> We previously discussed the PV_SHIM_EXCLUSIVE build issue on Matrix
> and agreed on resolving it after the feature freeze as a fix. This
> conversation took place before the feature freeze was rescheduled to
> September 5. I am documenting this on xen-devel both for record-keeping
> and because Matrix is currently offline. I am proceeding under the
> assumption that the conclusions from that discussion still apply.

Thank you for documenting this on xen-devel.


>
> I would like to request an additional clarification. While there is no
> consensus among the maintainers on the preferred short-term compromise,
> there is agreement that reviewing and committing the domctl series [1]
> in time would be the best outcome. (Together with unifying CONFIG_SYSCTL
> and CONFIG_DOMCTL into a single CONFIG_MGMT_HYPERCALLS for simplicify.)
>
> Are you still OK with us going ahead with reviewing and committing the
> domctl series as a fix to the PV_SHIM_EXCLUSIVE issue, potentially going
> past the feature freeze by a week?

Regarding your request for clarification on the domctl series [1], I agree
that reviewing and committing this series as a fix for the PV_SHIM_EXCLUSIV
issue is the preferred short-term solution.
Given that the series primarily consists of refactoring changes with minimal
functional impact, I am comfortable with making an exception to the feature
freeze to allow its inclusion, potentially extending up to one week past
September 5 (only for this patch series).

But if it will/could take more time then I think that we should consider
an option just to revert some patches, IIUC it should fix the mentioned issue
too.

~ Oleksii

> Stefano
>
> [1]https://marc.info/?l=xen-devel&m=175421442423500
--------------hBmKXonvLQj1jynq2TQbEZQZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
Hello Stefano,



    
On 9/3/25 12:16 AM, Stefano Stabellini
      wrote:

    

    

      
Hi Oleksii,

We previously discussed the PV_SHIM_EXCLUSIVE build issue on Matrix
and agreed on resolving it after the feature freeze as a fix. This
conversation took place before the feature freeze was rescheduled to
September 5. I am documenting this on xen-devel both for record-keeping
and because Matrix is currently offline. I am proceeding under the
assumption that the conclusions from that discussion still apply.

    

    
Thank you for documenting this on xen-devel.

    



    

      

I would like to request an additional clarification. While there is no
consensus among the maintainers on the preferred short-term compromise,
there is agreement that reviewing and committing the domctl series [1]
in time would be the best outcome. (Together with unifying CONFIG_SYSCTL
and CONFIG_DOMCTL into a single CONFIG_MGMT_HYPERCALLS for simplicify.)

Are you still OK with us going ahead with reviewing and committing the
domctl series as a fix to the PV_SHIM_EXCLUSIVE issue, potentially going
past the feature freeze by a week?

    

    
Regarding your request for clarification on the domctl series [1], I agree
that reviewing and committing this series as a fix for the PV_SHIM_EXCLUSIV
issue is the preferred short-term solution.
Given that the series primarily consists of refactoring changes with minimal
functional impact, I am comfortable with making an exception to the feature
freeze to allow its inclusion, potentially extending up to one week past
September 5 (only for this patch series).

But if it will/could take more time then I think that we should consider
an option just to revert some patches, IIUC it should fix the mentioned issue
too.

~ Oleksii

    

      
Stefano

[1] https://marc.info/?l=xen-devel&m=175421442423500


    

  


--------------hBmKXonvLQj1jynq2TQbEZQZ--


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:05:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:05:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108596.1458664 (Exim 4.92)
	(envelope-from )
	id 1utp2p-0002RK-Go; Wed, 03 Sep 2025 15:05:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108596.1458664; Wed, 03 Sep 2025 15: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 1utp2p-0002RD-EF; Wed, 03 Sep 2025 15:05:07 +0000
Received: by outflank-mailman (input) for mailman id 1108596;
 Wed, 03 Sep 2025 15:05:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1utp2n-0002R7-RW
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:05:05 +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 5e836e0e-88d7-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 17:05:03 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-61c26f3cf0dso10264724a12.1
 for ; Wed, 03 Sep 2025 08:05: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
 4fb4d7f45d1cf-61cfc4e4d77sm12213284a12.37.2025.09.03.08.05.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 08: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: 5e836e0e-88d7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756911903; x=1757516703; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=r2BF/xXcKol29erf7Ae6jp/+Miz9iZhWqtqkfFCme/U=;
        b=DEK55NdrdlmTAgb7XlYInBu8d+vO67kHh4b66A8Hrfp72y/CK7BHkUdHsBGHY/byK/
         7WjC8HmE7O75tBGW0soBm2XXmPN8LEcfyyYoiraoVsVx7CMw/VU3M6v1Gmz0XRQkQqo8
         z0mH77vnTc3m7aSZ0imx1Qr7PZF1+ENdBg1mdRo4y4MziIsD/IgfSNeawCcSuTbfOfSZ
         oidimjBkbcVEWmRQzMm/KAU+oOSQsruAEhmHRTc3JzlpJG1BoLKoCTsxVxgfU45t55zG
         WfQLkXFQP2UCQlgsUeIJ12YDOhF1emz3Hm6qvD3ExqPHYQkVhOy+8pkooioy78auPEor
         ZYgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756911903; x=1757516703;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=r2BF/xXcKol29erf7Ae6jp/+Miz9iZhWqtqkfFCme/U=;
        b=gMwpxH8YKe/fnwyR1nLk8RpSZgfIGAAfLcCbtPmiZW0VwLM0rP9nLq2rRf+rc8bLLJ
         cJfNzpYhrO7dbv8jH0rSrQOssV1xg+sCdLiZdD7W8xRJv/xlEj7YexDTj3z1XkAzyNk0
         3R1/5Fsyza9H7/MdyB69zTGwzoR5TMGcAJbLmlY9w/hIFurmw1664sC09oyoChjoEj9f
         CpaVQ1zzrvl6srf8I5byRl9aTc56KCZ8Mvei5pzccS9FPwApI4Ng5qF/m5g0ntmuPDZE
         IsD1hY+RmYWm4wbunv8Uwauknw4cl7hwJ628Mm0GcEjWuvAw5lJBKq/LGAR8HKYorxZr
         ZroQ==
X-Forwarded-Encrypted: i=1; AJvYcCVG6B+dXkpWwUavxjqupOUi0C5mH3/ksN3SLasGkiu39N2OjsjGoS7f0Gsfy+IqKZq/NBri+3/mhPk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxrcPNEC4oFd6ABWkRaMPHuHui4M9vj5EaYng9HX3meCorP9ZdB
	8/+cIR9oKwF9SAuHZ1DH8LhXD+hcGSmFh9GupzEnolikW4uvseJcNsEGreX8PgX/fA==
X-Gm-Gg: ASbGncvq/db1yqBy2ZIsztOYJHZaebPSD7lMY3UGD68DhyICYDmQOQPoGxFz5glUQB4
	60tgR1KRURSQXzNlzfvknPg8BZjy2HlZGcwcZT0qXG7UUgLUFZJzOxy5Fh1ATZCYKecIU9YunnD
	8xhj4dpJCln+U4XFqCTObjU+WxbVVvRmvEPl++XgfectNNNPE6VA5w9r2nZv/9hX2rSQX+rqgdD
	6fylTLUBQNbC8qJ724j5Bh4C+84czqUkByqV42MX7u5QnC+tM3N0L1Or2wsI/5HTXe+fPIchqty
	6EBrWtIp6WFkdtkphtx0U4IIkgouDVKx+83g24TJX4P8VzScXGxiCBZNtpgnYVk2AvXz28Ok8kn
	NEeFcoXB8iMne8dFep2vjUuvO2sJh3uoxrWGgktr9I2qP5keCksVS3xxu+sQDbe+DutLzRkgKyW
	Uy3KxLfvN3x+qRARzADA==
X-Google-Smtp-Source: AGHT+IFT0vNMM7xVCDB94bcjRtJRR0h/b2zHPsluKJ3+gcFdv4w4+nRJu2qc36AdKqcWoCkVrcxeIQ==
X-Received: by 2002:a05:6402:2115:b0:61e:ca25:3502 with SMTP id 4fb4d7f45d1cf-61eca25373emr4266730a12.17.1756911902849;
        Wed, 03 Sep 2025 08:05:02 -0700 (PDT)
Message-ID: 
Date: Wed, 3 Sep 2025 17:05:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RESEND PATCH v2 2/3] hvmloader: Update to SMBIOS 2.6
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: 
 <57c674cc364d3b8f4c6d03533b9e2b45728d2c19.1756460430.git.teddy.astie@vates.tech>
 
 
 <0190dbe1-4583-49c1-86c1-9bcb57844315@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2025 16:02, Teddy Astie wrote:
> Le 02/09/2025 à 16:10, Jan Beulich a écrit :
>> On 02.09.2025 15:24, Teddy Astie wrote:
>>> Regarding sgn, maybe we can use `segment` instead ?
>>
>> Why not segment_group or seg_group (seeing how devfn also is an abbreviation)?
>> And if we omit _number there and on devfn, it's hard to see why it shouldn't
>> be just "bus" then as well.
> 
> So overall
> 
>   uint16_t segment_group;
>   uint8_t bus;
>   uint8_t devfn;
> 
> ?
> 
> segment_group looks a bit off compared with the rest.
> We could use `seg` like we do in Xen PCI code, as it is about PCI 
> segment here.

I wouldn't mind that, yet I wonder why the spec says "group". If there's a
(good) reason, carrying this through into our naming may be advisable.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:13:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:13:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108609.1458675 (Exim 4.92)
	(envelope-from )
	id 1utpAU-00047P-A9; Wed, 03 Sep 2025 15:13:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108609.1458675; Wed, 03 Sep 2025 15:13: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 1utpAU-00047I-6W; Wed, 03 Sep 2025 15:13:02 +0000
Received: by outflank-mailman (input) for mailman id 1108609;
 Wed, 03 Sep 2025 15:13: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 1utpAS-00047C-8H
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:13:00 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7913455e-88d8-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 17:12:57 +0200 (CEST)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-337cc414358so24929631fa.3
 for ; Wed, 03 Sep 2025 08:12: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: 7913455e-88d8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756912377; x=1757517177; 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=dap0rzn1CXYPNl7tCjbofW12YcUy+X+dfljiWUGZF3c=;
        b=OLwbeBBzrgWT9KBjra4WrT44JPJKTASozFh4NVVV5I1ZTLmEX6N0fdrRyyJ8BZPJCn
         IbNeLt7CXGX3oXyAYzHuvS7vFytmr/lY9RKSmArXHYQMxXB1q715APQQ+hwdaBZcD25x
         KI5IDc66MacvxMZLpYH8mKyG5I8SIDF0NXzuAUkADBG+IrnhOPDSfdoCurNxY6oNEjIR
         bGcIkNDmPOxqFEE1VM1XIHW1w8D+oM1sz8EK3aExW1V9ZAZyXCTHMHUcBEQ4fAydlCYF
         RRMO2LFqSN2uqG5XbuCTIXdimU3aQeUj1UAm7aKPybx0SFYH8qanqkFRjgn9fGCsJkhk
         0iUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756912377; x=1757517177;
        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=dap0rzn1CXYPNl7tCjbofW12YcUy+X+dfljiWUGZF3c=;
        b=dp9X6cBwJ2XNbZDDV9/1h8jO+vYdT5WT2Nsy5GktUk5KmknfnYl7pAfuhJpaNSXVcb
         C5Jfr68SKsutoNGbyBIe2tkTvPEDLvzPUQa6/jT/qXtYKKZz9+NWkXrhDfPlGcwJ1m1R
         BmbiH2bSaRh/5N/dcuVSd2o9FdSVGLVvgdhiXPXBRRhdlroIZpnLr4YcedTFfg1onfLR
         ukg06UDNWrwyKDmUWeezeKxbjnWdt44/9ZvRcyixLXcjnvEeR4IOBdhJDYg+uP4JJsWT
         88jRLuMPsMC939LJP6j7nBG0Niv8Fb9xk6itctkkNcRzf/0/JnXEEXA7jGUALGJSyrL6
         HQxQ==
X-Forwarded-Encrypted: i=1; AJvYcCUnjeu1hMhvP0XoqMYlhgLvN92Xpp5OXg4bx9rEZy+979Vng5rIMiwWdPyzWOY5c4r6nxzVrSaDQH8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFF8YMpsJtRfingonioLdVH8awKm8tvcqvuyipaHRV7BeH3XmB
	zObpSY8Mkj6UFzdfU50oQGtSLr/wXKlOom6/IrutYr+DTqeSOvA/L4S7CiN4ikY4HLAVWg6QqOl
	xLirCDDSvzfQKWi8YZ3w6kPfUz3ptUdA=
X-Gm-Gg: ASbGncs+PcqeuE+81bf+sXwc27/+n2UUjUDM4zbdDD74iRU9uZ2jZv3rgDB4yqDiZqr
	LwAmfwE5Fd7j02BBF0kn+96r/HPAnylFDZaH4FaBQyiqa8Gn8DCNSr89nqwDfxByRs0KB7RtiDI
	sjnBoJfK2klJY6RadKqnwiX3HFBASUU+6YU0GtcEfx//NPB6u7+ZB4AkR3yStgv+u6Ci/cCzy7E
	CTyBg==
X-Google-Smtp-Source: AGHT+IFRQJ4dbE9S/GLPZ2bOUzTs7T5YfDEWIR/O2CTgrDgLHZmkO2qIsPSB5J/uSyu0svNFugS4HLKEwZTz+cc2wUs=
X-Received: by 2002:a05:651c:e17:b0:336:5e1f:b1ec with SMTP id
 38308e7fff4ca-336cad33ce6mr38899791fa.31.1756912376372; Wed, 03 Sep 2025
 08:12:56 -0700 (PDT)
MIME-Version: 1.0
References:  <3a05d0f188943173703690981a7590fd12fabd4c.1756763487.git.mykola_kvach@epam.com>
 <41cddeee-6cc2-4426-9020-2f1000983845@epam.com> 
 <98444477-bf97-440e-a5a4-844d51e92a54@gmail.com>
In-Reply-To: <98444477-bf97-440e-a5a4-844d51e92a54@gmail.com>
From: Mykola Kvach 
Date: Wed, 3 Sep 2025 18:12:44 +0300
X-Gm-Features: Ac12FXxpi6tQLOkOcCnx_lYf_yz6EMfF5L2ZqK5JM7JzJI0Mw0_y4_5B4hyBXAM
Message-ID: 
Subject: Re: [PATCH v6 07/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks
To: Oleksandr Tyshchenko 
Cc: Oleksandr Tyshchenko , 
	"xen-devel@lists.xenproject.org" , 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Mykola Kvach 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 3, 2025 at 2:49=E2=80=AFPM Oleksandr Tyshchenko  wrote:
>
>
>
> On 03.09.25 13:25, Mykola Kvach wrote:
> > Hi Oleksandr,
>
> Hello Mykola
>
> >
> > On Wed, Sep 3, 2025 at 1:01=E2=80=AFPM Oleksandr Tyshchenko
> >  wrote:
> >>
> >>
> >>
> >> On 02.09.25 01:10, Mykola Kvach wrote:
> >>
> >> Hello Mykola
> >>
> >>
> >>> From: Oleksandr Tyshchenko 
> >>>
> >>> Store and restore active context and micro-TLB registers.
> >>>
> >>> Tested on R-Car H3 Starter Kit.
> >>>
> >>> Signed-off-by: Oleksandr Tyshchenko 
> >>> Signed-off-by: Mykola Kvach 
> >>> ---
> >>> Changes in V6:
> >>> - refactor code related to hw_register struct, from now it's called
> >>>     ipmmu_reg_ctx
> >>
> >> The updated version looks good, thanks. However, I have one
> >> concern/request ...
> >>
> >>> ---
> >>>    xen/drivers/passthrough/arm/ipmmu-vmsa.c | 257 +++++++++++++++++++=
++++
> >>>    1 file changed, 257 insertions(+)
> >>>
> >>> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/p=
assthrough/arm/ipmmu-vmsa.c
> >>> index ea9fa9ddf3..0973559861 100644
> >>> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> >>> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> >>> @@ -71,6 +71,8 @@
> >>>    })
> >>>    #endif
> >>>
> >>> +#define dev_dbg(dev, fmt, ...)    \
> >>> +    dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
> >>>    #define dev_info(dev, fmt, ...)    \
> >>>        dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
> >>>    #define dev_warn(dev, fmt, ...)    \
> >>> @@ -130,6 +132,24 @@ struct ipmmu_features {
> >>>        unsigned int imuctr_ttsel_mask;
> >>>    };
> >>>
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +
> >>> +struct ipmmu_reg_ctx {
> >>> +    unsigned int imttlbr0;
> >>> +    unsigned int imttubr0;
> >>> +    unsigned int imttbcr;
> >>> +    unsigned int imctr;
> >>> +};
> >>> +
> >>> +struct ipmmu_vmsa_backup {
> >>> +    struct device *dev;
> >>> +    unsigned int *utlbs_val;
> >>> +    unsigned int *asids_val;
> >>> +    struct list_head list;
> >>> +};
> >>> +
> >>> +#endif
> >>> +
> >>>    /* Root/Cache IPMMU device's information */
> >>>    struct ipmmu_vmsa_device {
> >>>        struct device *dev;
> >>> @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device {
> >>>        struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX];
> >>>        unsigned int utlb_refcount[IPMMU_UTLB_MAX];
> >>>        const struct ipmmu_features *features;
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +    struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX];
> >>> +#endif
> >>>    };
> >>>
> >>>    /*
> >>> @@ -547,6 +570,222 @@ static void ipmmu_domain_free_context(struct ip=
mmu_vmsa_device *mmu,
> >>>        spin_unlock_irqrestore(&mmu->lock, flags);
> >>>    }
> >>>
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +
> >>> +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock);
> >>> +static LIST_HEAD(ipmmu_devices_backup);
> >>> +
> >>> +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX];
> >>> +
> >>> +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu,
> >>> +                                   unsigned int utlb)
> >>> +{
> >>> +    return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)));
> >>> +}
> >>> +
> >>> +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu)
> >>> +{
> >>> +    struct ipmmu_vmsa_backup *backup_data;
> >>> +
> >>> +    dev_dbg(mmu->dev, "Handle micro-TLBs backup\n");
> >>> +
> >>> +    spin_lock(&ipmmu_devices_backup_lock);
> >>> +
> >>> +    list_for_each_entry( backup_data, &ipmmu_devices_backup, list )
> >>> +    {
> >>> +        struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(backup_=
data->dev);
> >>> +        unsigned int i;
> >>> +
> >>> +        if ( to_ipmmu(backup_data->dev) !=3D mmu )
> >>> +            continue;
> >>> +
> >>> +        for ( i =3D 0; i < fwspec->num_ids; i++ )
> >>> +        {
> >>> +            unsigned int utlb =3D fwspec->ids[i];
> >>> +
> >>> +            backup_data->asids_val[i] =3D ipmmu_imuasid_read(mmu, ut=
lb);
> >>> +            backup_data->utlbs_val[i] =3D ipmmu_imuctr_read(mmu, utl=
b);
> >>> +        }
> >>> +    }
> >>> +
> >>> +    spin_unlock(&ipmmu_devices_backup_lock);
> >>> +}
> >>> +
> >>> +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu)
> >>> +{
> >>> +    struct ipmmu_vmsa_backup *backup_data;
> >>> +
> >>> +    dev_dbg(mmu->dev, "Handle micro-TLBs restore\n");
> >>> +
> >>> +    spin_lock(&ipmmu_devices_backup_lock);
> >>> +
> >>> +    list_for_each_entry( backup_data, &ipmmu_devices_backup, list )
> >>> +    {
> >>> +        struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(backup_=
data->dev);
> >>> +        unsigned int i;
> >>> +
> >>> +        if ( to_ipmmu(backup_data->dev) !=3D mmu )
> >>> +            continue;
> >>> +
> >>> +        for ( i =3D 0; i < fwspec->num_ids; i++ )
> >>> +        {
> >>> +            unsigned int utlb =3D fwspec->ids[i];
> >>> +
> >>> +            ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]=
);
> >>> +            ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i])=
;
> >>> +        }
> >>> +    }
> >>> +
> >>> +    spin_unlock(&ipmmu_devices_backup_lock);
> >>> +}
> >>> +
> >>> +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *do=
main)
> >>> +{
> >>> +    struct ipmmu_vmsa_device *mmu =3D domain->mmu->root;
> >>> +    struct ipmmu_reg_ctx *regs =3D mmu->reg_backup[domain->context_i=
d];
> >>> +
> >>> +    dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->c=
ontext_id);
> >>> +
> >>> +    regs->imttlbr0 =3D ipmmu_ctx_read_root(domain, IMTTLBR0);
> >>> +    regs->imttubr0 =3D ipmmu_ctx_read_root(domain, IMTTUBR0);
> >>> +    regs->imttbcr  =3D ipmmu_ctx_read_root(domain, IMTTBCR);
> >>> +    regs->imctr    =3D ipmmu_ctx_read_root(domain, IMCTR);
> >>> +}
> >>> +
> >>> +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *d=
omain)
> >>> +{
> >>> +    struct ipmmu_vmsa_device *mmu =3D domain->mmu->root;
> >>> +    struct ipmmu_reg_ctx *regs  =3D mmu->reg_backup[domain->context_=
id];
> >>> +
> >>> +    dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->=
context_id);
> >>> +
> >>> +    ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0);
> >>> +    ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0);
> >>> +    ipmmu_ctx_write_root(domain, IMTTBCR,  regs->imttbcr);
> >>> +    ipmmu_ctx_write_all(domain,  IMCTR,    regs->imctr | IMCTR_FLUSH=
);
> >>> +}
> >>> +
> >>> +/*
> >>> + * Xen: Unlike Linux implementation, Xen uses a single driver instan=
ce
> >>> + * for handling all IPMMUs. There is no framework for ipmmu_suspend/=
resume
> >>> + * callbacks to be invoked for each IPMMU device. So, we need to ite=
rate
> >>> + * through all registered IPMMUs performing required actions.
> >>> + *
> >>> + * Also take care of restoring special settings, such as translation
> >>> + * table format, etc.
> >>> + */
> >>> +static int __must_check ipmmu_suspend(void)
> >>> +{
> >>> +    struct ipmmu_vmsa_device *mmu;
> >>> +
> >>> +    if ( !iommu_enabled )
> >>> +        return 0;
> >>> +
> >>> +    printk(XENLOG_DEBUG "ipmmu: Suspending ...\n");
> >>> +
> >>> +    spin_lock(&ipmmu_devices_lock);
> >>> +
> >>> +    list_for_each_entry( mmu, &ipmmu_devices, list )
> >>> +    {
> >>> +        if ( ipmmu_is_root(mmu) )
> >>> +        {
> >>> +            unsigned int i;
> >>> +
> >>> +            for ( i =3D 0; i < mmu->num_ctx; i++ )
> >>> +            {
> >>> +                if ( !mmu->domains[i] )
> >>> +                    continue;
> >>> +                ipmmu_domain_backup_context(mmu->domains[i]);
> >>> +            }
> >>> +        }
> >>> +        else
> >>> +            ipmmu_utlbs_backup(mmu);
> >>> +    }
> >>> +
> >>> +    spin_unlock(&ipmmu_devices_lock);
> >>> +
> >>> +    return 0;
> >>> +}
> >>> +
> >>> +static void ipmmu_resume(void)
> >>> +{
> >>> +    struct ipmmu_vmsa_device *mmu;
> >>> +
> >>> +    if ( !iommu_enabled )
> >>> +        return;
> >>> +
> >>> +    printk(XENLOG_DEBUG "ipmmu: Resuming ...\n");
> >>> +
> >>> +    spin_lock(&ipmmu_devices_lock);
> >>> +
> >>> +    list_for_each_entry( mmu, &ipmmu_devices, list )
> >>> +    {
> >>> +        uint32_t reg;
> >>> +
> >>> +        /* Do not use security group function */
> >>> +        reg =3D IMSCTLR + mmu->features->control_offset_base;
> >>> +        ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SE=
CGRP);
> >>> +
> >>> +        if ( ipmmu_is_root(mmu) )
> >>> +        {
> >>> +            unsigned int i;
> >>> +
> >>> +            /* Use stage 2 translation table format */
> >>> +            reg =3D IMSAUXCTLR + mmu->features->control_offset_base;
> >>> +            ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_=
S2PTE);
> >>> +
> >>> +            for ( i =3D 0; i < mmu->num_ctx; i++ )
> >>> +            {
> >>> +                if ( !mmu->domains[i] )
> >>> +                    continue;
> >>> +                ipmmu_domain_restore_context(mmu->domains[i]);
> >>> +            }
> >>> +        }
> >>> +        else
> >>> +            ipmmu_utlbs_restore(mmu);
> >>> +    }
> >>> +
> >>> +    spin_unlock(&ipmmu_devices_lock);
> >>> +}
> >>> +
> >>> +static int ipmmu_alloc_ctx_suspend(struct device *dev)
> >>> +{
> >>> +    struct ipmmu_vmsa_backup *backup_data;
> >>> +    unsigned int *utlbs_val, *asids_val;
> >>> +    struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(dev);
> >>> +
> >>> +    utlbs_val =3D xzalloc_array(unsigned int, fwspec->num_ids);
> >>> +    if ( !utlbs_val )
> >>> +        return -ENOMEM;
> >>> +
> >>> +    asids_val =3D xzalloc_array(unsigned int, fwspec->num_ids);
> >>> +    if ( !asids_val )
> >>> +    {
> >>> +        xfree(utlbs_val);
> >>> +        return -ENOMEM;
> >>> +    }
> >>> +
> >>> +    backup_data =3D xzalloc(struct ipmmu_vmsa_backup);
> >>> +    if ( !backup_data )
> >>> +    {
> >>> +        xfree(utlbs_val);
> >>> +        xfree(asids_val);
> >>> +        return -ENOMEM;
> >>> +    }
> >>> +
> >>> +    backup_data->dev =3D dev;
> >>> +    backup_data->utlbs_val =3D utlbs_val;
> >>> +    backup_data->asids_val =3D asids_val;
> >>> +
> >>> +    spin_lock(&ipmmu_devices_backup_lock);
> >>> +    list_add(&backup_data->list, &ipmmu_devices_backup);
> >>> +    spin_unlock(&ipmmu_devices_backup_lock);
> >>> +
> >>> +    return 0;
> >>> +}
> >>> +
> >>> +#endif /* CONFIG_SYSTEM_SUSPEND */
> >>> +
> >>>    static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *dom=
ain)
> >>>    {
> >>>        uint64_t ttbr;
> >>> @@ -559,6 +798,9 @@ static int ipmmu_domain_init_context(struct ipmmu=
_vmsa_domain *domain)
> >>>            return ret;
> >>>
> >>>        domain->context_id =3D ret;
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +    domain->mmu->root->reg_backup[ret] =3D &root_pgtable[ret];
> >>> +#endif
> >>>
> >>>        /*
> >>>         * TTBR0
> >>> @@ -615,6 +857,9 @@ static void ipmmu_domain_destroy_context(struct i=
pmmu_vmsa_domain *domain)
> >>>        ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH);
> >>>        ipmmu_tlb_sync(domain);
> >>>
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +    domain->mmu->root->reg_backup[domain->context_id] =3D NULL;
> >>> +#endif
> >>>        ipmmu_domain_free_context(domain->mmu->root, domain->context_i=
d);
> >>>    }
> >>>
> >>> @@ -1427,6 +1672,14 @@ static int ipmmu_add_device(u8 devfn, struct d=
evice *dev)
> >>>        }
> >>>    #endif
> >>>
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +    if ( ipmmu_alloc_ctx_suspend(dev) )
> >>> +    {
> >>> +        dev_err(dev, "Failed to allocate context for suspend\n");
> >>> +        return -ENOMEM;
> >>> +    }
> >>> +#endif
> >>
> >> ... The initial version was based on the driver code without PCI
> >> support, but it is now present. There is PCI-specific code above in th=
is
> >> function (not visible in the context) that performs some initializatio=
n,
> >> allocation and device assignment. What I mean is that in case of the
> >> suspend context allocation error here, we will need to undo these
> >> actions (i.e. deassign device). I would move this context allocation
> >> (whose probability to fail is much lower than what is done for PCI dev=
)
> >> above the PCI-specific stuff, and perform the context freeing on the
> >> error path.
> >
> > Maybe it would be better just to add some checks to the suspend handler=
.
> > We could skip suspend in case the context is not available, and avoid
> > deallocating previously allocated stuff. This is similar to what is
> > done for GICs.
> >
> > What do you think? Or do you prefer to destroy everything related to th=
e
> > IOMMU here on error?
>
> I would prefer if we fail early here in ipmmu_add_device (and rollback
> changes) rather than continue and fail later, other people might think
> differently. I think, if we cannot simply allocate a memory for the
> sctructures that situation is bad.

Got it, I=E2=80=99ll fix this in the next version of the patch series.
Thank you for pointing that out.

>
>
>
> >
> >>
> >>> +
> >>>        dev_info(dev, "Added master device (IPMMU %s micro-TLBs %u)\n"=
,
> >>>                 dev_name(fwspec->iommu_dev), fwspec->num_ids);
> >>>
> >>> @@ -1492,6 +1745,10 @@ static const struct iommu_ops ipmmu_iommu_ops =
=3D
> >>>        .unmap_page      =3D arm_iommu_unmap_page,
> >>>        .dt_xlate        =3D ipmmu_dt_xlate,
> >>>        .add_device      =3D ipmmu_add_device,
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +    .suspend         =3D ipmmu_suspend,
> >>> +    .resume          =3D ipmmu_resume,
> >>> +#endif
> >>>    };
> >>>
> >>>    static __init int ipmmu_init(struct dt_device_node *node, const vo=
id *data)
> >
> > Best regards,
> > Mykola
> >
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:13:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:13:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108610.1458685 (Exim 4.92)
	(envelope-from )
	id 1utpAh-0004Q6-Mm; Wed, 03 Sep 2025 15:13:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108610.1458685; Wed, 03 Sep 2025 15:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utpAh-0004Pw-Jk; Wed, 03 Sep 2025 15:13:15 +0000
Received: by outflank-mailman (input) for mailman id 1108610;
 Wed, 03 Sep 2025 15:13:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1utpAg-00047C-Nh
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:13:14 +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 8250c5d4-88d8-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 17:13:13 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-61cb4370e7bso10088679a12.3
 for ; Wed, 03 Sep 2025 08: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
 a640c23a62f3a-b042dcb9105sm771389366b.2.2025.09.03.08.13.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 08: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: 8250c5d4-88d8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756912392; x=1757517192; 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=eU9yPIjk+hMAyig/Ct0852tYZLmHe6qE5yP90ZCdm3A=;
        b=gG2vS24wAWy3TcIfLtiyNNtA9k6o67C3HtDJp5iDP1iLlU8yIw5O+hJ4+r+iR8+22T
         CjOxG3wnAtOyoblgWqCVojKykpwV03L2TW4tgSb820tZXM7ugYXxAOTHV+ucCnObbHqG
         72ngeX1baeIBTRQEuskkglPQOerJAnJRloZetwYCtKxznHuqurTNsOICWB8kYKw/uC2B
         1Q8exkFLD2VItNNaEJ0jDTRoN00MhSOtICvrmEcehiufyEK+Bpf4OPEM7iyIPEZypEsq
         suibDqsXOKipfAw3eGjGRVaSWZSxdtklylQq+LNkZ23Ltle9YJcbLabI9044kaNHfkYZ
         obuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756912392; x=1757517192;
        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=eU9yPIjk+hMAyig/Ct0852tYZLmHe6qE5yP90ZCdm3A=;
        b=WgxyMk0dtPui3GxWPwM0+XjJZJaRim3/f21ln8O684ZTYbGrpfxTVGzs7ECIw/t0iX
         WeXQxAJ5JfCAKMvAOJBj/IUVig2Vb+J3l5W58j8iWxDwAs0HwVriRhOELb65q64zovKM
         5pL/CnvgTIm9FPWIBGzbmvS/g+FCVyxXGUaGhxcvANJafPwmN0LVsLoCBmuMVhd7he3M
         pxnCBKbuwazGldg8YKcckVPbLxBYzdpn4FvpgZDA127CEZObWk1VZYLTUZ1hI2N134eS
         3K2Z+P7K1lE5akjJvpX3JIXhKZ5200R5U7SqrXcHF/3sMGBePj0TjznyNh+KCOWEWefF
         kYcw==
X-Gm-Message-State: AOJu0Yxc4vgOT3DEYaC4m26a4hTYMgkGP9UeYkA4AK6Oadgz4tmhezGc
	pD4KI9nCuOH8YedsrYvo0DqqKtPvvkAuv6IoDbMrXCYPpcyA22zcBZBq9ZqD5TvtFvOWlybF+KQ
	0q14=
X-Gm-Gg: ASbGncte9Me7vWxRN2X2A0QDd+QjwUgmQrecZdxpeWaS4W4XzP0vKp88g5DEoO5cT0m
	7gvmzJWFcX0dJM7XLKevXybiZlXOrrQEVKX92P7b6Cv3FOmetn+7F92FlxAAfhSXBxh+RD7pbUv
	C5OhRqNYPrYbBhlu5L2Vx+2jDLua2p60LzqRnGn6IvnsSYWJiNom30sC/5oVSMRb6QqzKnir1Bd
	JanKJehtP1ko/SqBy6/i3GZ59ty7BKfHaUIEFneFQrAUfT+YbSDhvHH5mpu++92/pDksjtz66de
	+lb67HX0drwP+jIRrftp+Rqh3m69L6xbQLNHCRUAVqOHVOMfgQeIptDGFAOemafwnwgkcW5crTY
	HMv7cv84rHic/blfqSZvBMueMLvu+oe1w5dhAk2UFlurt1vbZbO5dtEwWDT2wOJVDpecu0FK6sx
	VvrJjeQP8qNsQIJ2KZuQ==
X-Google-Smtp-Source: AGHT+IHMC07VAfa4DaT2Xm8NfFfTUewmCpyOhnTBxMcnx9r7nQ2vuTzTL5r7n29y62fteALKa4ELoQ==
X-Received: by 2002:a17:907:971a:b0:ae3:6cc8:e431 with SMTP id a640c23a62f3a-b01f20ca668mr1723529666b.57.1756912392383;
        Wed, 03 Sep 2025 08:13:12 -0700 (PDT)
Message-ID: <1071997f-efe6-4088-b753-b74d3a045a09@suse.com>
Date: Wed, 3 Sep 2025 17:13:10 +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] build: avoid absolute paths in executables
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 in-tree builds relative paths are used, whereas for out-of-tree builds
in various situations absolute ones come into play. The extra paths can be
long, wasting space and e.g. serial line bandwidth. They would also get in
the way of location-independent reproducible builds. Leverage newer gcc's
(and Clang's) ability to "remap" file names. For older gcc fall back to
using the option affecting debug info only.

Signed-off-by: Jan Beulich 
---
Of course we may want to consider putting this in the top-level Config.mk,
to also affect other sub-trees (presently mainly/only affecting debug
info, for which even gcc5 already supports -fdebug-prefix-remap=).

As to a Fixes: tag, I wasn't quite sure whether to "blame" the
introduction of out-of-tree builds.

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -448,6 +448,8 @@ LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin
 endif
 
 ifdef building_out_of_srctree
+    CFLAGS += $(call cc-option,$(CC),-ffile-prefix-map=$(srctree)/=, \
+                                     -fdebug-prefix-map=$(srctree)/=)
     CFLAGS += -I$(objtree)/include
     CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
 endif


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:21:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:21:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108641.1458694 (Exim 4.92)
	(envelope-from )
	id 1utpI8-0006Mu-F0; Wed, 03 Sep 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 1108641.1458694; Wed, 03 Sep 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 1utpI8-0006Mn-C7; Wed, 03 Sep 2025 15:20:56 +0000
Received: by outflank-mailman (input) for mailman id 1108641;
 Wed, 03 Sep 2025 15:20:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1utpI7-0006Md-CN
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:20:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1utpI6-004dkF-2l
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:20:55 +0000
Received: from mail-vk1-f178.google.com ([209.85.221.178])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1utpI7-00EUr2-02
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:20:55 +0000
Received: by mail-vk1-f178.google.com with SMTP id
 71dfb90a1353d-545dccac2f9so29356e0c.0
 for ; Wed, 03 Sep 2025 08:20: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:To:Subject:Message-ID:Date:
	From:MIME-Version; bh=5wLpxyT35MYjQy1lDG7ITcvMpGAAj6EgEsv9ErVZivQ=; b=X03kZDu
	4wKvX3YjDWXw4VJ7FigVrx+0NE/xBQrR0WuYmmbng8Wh2r0u4f5Mu8MckKmPQ4RcsT0QAliMUYJDI
	m6GjwdnOSg0TlDgXMg/xqSW2CmqzTtziMqvKISicg1lLTz7FYV46127qIXichr6EmtsdBprf3VnDf
	aPf0yQkvII=;
X-Gm-Message-State: AOJu0Yz9KwvwwkZc0BHWnmgY+3Amt7cl2JJnYFVlaG1LD6QU7bmeqh63
	on9jbzQg7+jj2vIV+bPwmPYvTEjHB2yOPeg36BeEYZJIR2b+bfuz5pfTibWElHdeKU1Py2NsWD5
	1Z7diKclBf2pWDCqVHmylLM+AuawHmqs=
X-Google-Smtp-Source: AGHT+IFFPDuqHwfTugBWMdaTzomUjTdWBYvoyU0mDOPAZuVA4osSDjSTRvWzDz/TIQDwqnHSY7yb0+ceipcjsIelrK0=
X-Received: by 2002:a05:6122:a27:b0:544:6eb7:d7b5 with SMTP id
 71dfb90a1353d-544a0295260mr5397251e0c.9.1756912854515; Wed, 03 Sep 2025
 08:20:54 -0700 (PDT)
MIME-Version: 1.0
From: Cody Zuschlag 
Date: Wed, 3 Sep 2025 17:20:43 +0200
X-Gmail-Original-Message-ID: 
X-Gm-Features: Ac12FXz__cgvA71FYzfmoDYTuuMzYWcL4nlx3mXaWmoX2DhKPgMGHgRR8tvJ3Bk
Message-ID: 
Subject: [ANNOUNCE] Call for agenda items for September 4, 2025 Community Call
 @ 15:00 UTC
To: xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="000000000000984cd2063de72663"

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

Hi everyone,

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

*Preparation:*

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



*Call Details:*

   - *Date:* Thursday, 4 September 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 on thursday!

Cody Zuschlag
Xen Project - Community Manager

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


Hi everyone,

We=E2=80=99re getting ready for A=
ugust's Xen Project Community Call on Thursday, 4 September 2025 at 15:=
00 UTC (4 pm UK time). We=E2=80=99d love for you to join. Feel free to part=
icipate or just observe. This call is a great opportunity to see what the c=
ommunity is working on, align our various efforts, and share updates. Every=
one is welcome!

Preparation:

Call Details:
We plan to open the meeting room at 15:00 UT=
C, but to allow time for switching between meetings and handling any techni=
cal issues, we=E2=80=99ll officially start discussing the agenda at 15:05 U=
TC.

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

Add or remove yo=
urself from our Sign-up Sheet.

See you on thursday!

Cody Zuschlag
Xen Project - Community Manager
=



--000000000000984cd2063de72663--


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:26:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:26:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108655.1458713 (Exim 4.92)
	(envelope-from )
	id 1utpNC-00072v-4F; Wed, 03 Sep 2025 15:26:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108655.1458713; Wed, 03 Sep 2025 15:26:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utpNC-00072o-1N; Wed, 03 Sep 2025 15:26:10 +0000
Received: by outflank-mailman (input) for mailman id 1108655;
 Wed, 03 Sep 2025 15:26:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1utpNA-00072i-V4
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:26:09 +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 4f3f129d-88da-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 17:26:06 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45b7d87b90fso11878615e9.0
 for ; Wed, 03 Sep 2025 08:26:06 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45b66b6985bsm213235225e9.2.2025.09.03.08.26.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 08:26: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: 4f3f129d-88da-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1756913166; x=1757517966; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kpptJI8bwAxPttCSKzlOJOSfG+7s/D1pOF0GDq6uRu4=;
        b=m+baBwM89HLFI5tTRTYPy4Lq3FeRwFgVl2Lkg0U5KQFAgRiszZqN8W2QHpKWs/47H6
         R16upT2y4g93oafq7ETwoCI3nlWw3Sal+zhM+Hbx+488wN7i02x+LxmSNYC8iBhzhpZX
         Z26qGE9zdl62YT+r7Hq90wLWh6zwMHEfypXyk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756913166; x=1757517966;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kpptJI8bwAxPttCSKzlOJOSfG+7s/D1pOF0GDq6uRu4=;
        b=RLURehtPqw0Dbl6Jlu0YxRVrxEg8Xs7hB7Oo1AkOByeRu4ClRV+4okTPyC5kI3k0Ug
         1kovWWI22sWeKRPYgjZ4hF61qXIdeEWkZ71851EttQvKFq4ran2yUABLFA4zWddrPU4I
         ne4K4D4wCkw7CPaFx6zoZlhlrMRtspjtq5snK9aWZa1E5yBr9cS9HROUOs+xyo5fRJlG
         SqgF/sxW2PZELQGMkOxpd5Iqou2JoERC2AI+a9A7WEkg46JXdO/KhO1F6ECMP6N8qS09
         ErCBRH0uDzfSm/XiMxETa0ZW4NvJdNDOlxdRZeeHNE85FTqd29i/HahRwjDXSjeeXFN3
         5ipQ==
X-Forwarded-Encrypted: i=1; AJvYcCVBL8jHr+Wetj79/mUd/e7CCRKWkXFmlUCSyy2JSbHDtNh5vy1e8rK6J+hX8jrqDP3GNxSuBcujCMM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxxVZLTnDP43DAw3BRM6FabkFDDwK5zaeNBnnMMt4HOzOnjqa7P
	nbQd76yusjHxV7ciHNNPWBMiZgQFGdTM1O1MjnRv0Lu65zotZHWiF1E77VPjK5GMbWU=
X-Gm-Gg: ASbGncv1DNaaoAvTTC7GQ9b9L3kyh5nu1GF8fVgOWcc3R9fQf+xGan0Tbx6kKsSsG+X
	pdLIVkaPoQwdk6If+NzpifZPDRqmbODWtyNTTcIFUnBbD7p2hefh2lbnqtjl7yqHJ5pGaGsedMH
	PFytdkesXdWKjehkFbUh6uK3QNcqLdGzVHYeiIYvb7rAKFTUiT2DFscaDFJYwES1mQL5ClRGTn2
	HUUxIGf1wm6bU1rIaxEhu3O3mYkCBIP/jZ9xrGRfF49cDjDUKhN2SG0NbzoMLzDHVqS2Sg7Lnbc
	4KaLf8MBvqptdESMIjDtXaf1orhG2i0ikKbK46CMyyuNqkumhw6wcGtk7zis6kiRmRErBnqoRAF
	/5FUBk2XyZITbu1monltl9uoUJwTQ+jK7VhBhx1vZkJdvGstsF9QitsIoodhvY8Y2tl0p2+Yf8V
	t6PHU=
X-Google-Smtp-Source: AGHT+IFOpcvYKWkMlJyK2mXxDxQq+ubNAfPEWMp3wi+GGH8Q+VLNDw6vHTWjOZa6KTjcT/KG8CZ4EQ==
X-Received: by 2002:a05:600c:4e88:b0:45c:b56c:418a with SMTP id 5b1f17b1804b1-45cb56c440emr26072865e9.7.1756913165883;
        Wed, 03 Sep 2025 08:26:05 -0700 (PDT)
Message-ID: <795b069f-12ea-4d05-bdc4-877a6a93fe7c@citrix.com>
Date: Wed, 3 Sep 2025 16:26:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] build: avoid absolute paths in executables
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: <1071997f-efe6-4088-b753-b74d3a045a09@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: <1071997f-efe6-4088-b753-b74d3a045a09@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/09/2025 4:13 pm, Jan Beulich wrote:
> For in-tree builds relative paths are used, whereas for out-of-tree builds
> in various situations absolute ones come into play. The extra paths can be
> long, wasting space and e.g. serial line bandwidth. They would also get in
> the way of location-independent reproducible builds. Leverage newer gcc's
> (and Clang's) ability to "remap" file names. For older gcc fall back to
> using the option affecting debug info only.
>
> Signed-off-by: Jan Beulich 
> ---
> Of course we may want to consider putting this in the top-level Config.mk,
> to also affect other sub-trees (presently mainly/only affecting debug
> info, for which even gcc5 already supports -fdebug-prefix-remap=).
>
> As to a Fixes: tag, I wasn't quite sure whether to "blame" the
> introduction of out-of-tree builds.
>
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -448,6 +448,8 @@ LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin
>  endif
>  
>  ifdef building_out_of_srctree
> +    CFLAGS += $(call cc-option,$(CC),-ffile-prefix-map=$(srctree)/=, \
> +                                     -fdebug-prefix-map=$(srctree)/=)
>      CFLAGS += -I$(objtree)/include
>      CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
>  endif

We do want to be taking a change like this, but it's also definitely not
limited to out-of-tree builds.  I have full paths embedded even for
in-tree builds.

To be useful, it wants to apply to everything, not just the hypervisor,
so does want to be in the top level Config.mk.

https://reproducible-builds.org/docs/build-path/ has a full list of
compiler versions. It looks like we need to use both options here until
we can increase the minimum GCC version to 8.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:47:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:47:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108669.1458726 (Exim 4.92)
	(envelope-from )
	id 1utpiB-0001dd-PJ; Wed, 03 Sep 2025 15:47:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108669.1458726; Wed, 03 Sep 2025 15:47: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 1utpiB-0001dW-Mj; Wed, 03 Sep 2025 15:47:51 +0000
Received: by outflank-mailman (input) for mailman id 1108669;
 Wed, 03 Sep 2025 15:47: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 1utpi9-0001dQ-Pv
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:47:49 +0000
Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5663b2b0-88dd-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 17:47:47 +0200 (CEST)
Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2])
 by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 583Fliwf010600
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Wed, 3 Sep 2025 17:47:45 +0200 (CEST)
Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133])
 by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 583FliAk005009;
 Wed, 3 Sep 2025 17:47:44 +0200 (MEST)
Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331)
 id 58C2E107F7; Wed,  3 Sep 2025 17:47:43 +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: 5663b2b0-88dd-11f0-9d12-b5c5bf9af7f9
Date: Wed, 3 Sep 2025 17:47:43 +0200
From: Manuel Bouyer 
To: Jan Beulich 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org,
        Juergen Gross 
Subject: Re: issue with dom0_pvh on Xen 4.20
Message-ID: 
References: 
 <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com>
 
 <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com>
 
 <7d0fc0eb-52a4-4478-8c1b-9a359513abdd@suse.com>
 
 <8a1fa32f-e7fb-4879-8516-1ddca5367619@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8a1fa32f-e7fb-4879-8516-1ddca5367619@suse.com>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Wed, 03 Sep 2025 17:47:45 +0200 (CEST)
X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2

Hello
with your help I now have a NetBSD PVH dom0 on Xen 4.20. Thanks all !

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:57:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:57:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108679.1458736 (Exim 4.92)
	(envelope-from )
	id 1utprP-0003Jx-Ka; Wed, 03 Sep 2025 15:57:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108679.1458736; Wed, 03 Sep 2025 15:57: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 1utprP-0003Jq-I3; Wed, 03 Sep 2025 15:57:23 +0000
Received: by outflank-mailman (input) for mailman id 1108679;
 Wed, 03 Sep 2025 15:57: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 1utprN-0003Jk-Vx
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:57:21 +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 abe004a9-88de-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 17:57:19 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-b04271cfc3eso2873766b.3
 for ; Wed, 03 Sep 2025 08:57: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-b047041dddasm117554866b.72.2025.09.03.08.57.18
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 08:57: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: abe004a9-88de-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756915039; x=1757519839; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+PObKb1FnC4BE7oEyeS20MPHFCGs0tmF52fixtQUq4I=;
        b=X5sajX6gwaQGYCHYgpsfz6+JPpp5A2KsoRd5Uztfr+bpfrDFa/eDhhCGTAhp5Pulh/
         PzUsp3gc2vfknX4sHcBQlT8NsfOC3ITSMI59hfEdalAG8lI+Ofautrc9Q/mFCHziPJKb
         p6HRD9dIgCjucXSs2XYA7xTnPbH4FXEaDiF84t9iogC083dAEY8LGW0Ix/6x5vknjMIP
         RYqAygx51+tlywfU6sYHtONOHaHnLyL+iaJcvGcia0ECGp9uv9C7ZQzla0DglUBMRpvN
         pXYjAeI8632oXRNV23PfIf5/YLER57YvmlBe9oPtt7OX0Zdc3Grwr7RgSxdPNP4ImZiA
         USNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756915039; x=1757519839;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+PObKb1FnC4BE7oEyeS20MPHFCGs0tmF52fixtQUq4I=;
        b=JrvDNMyZElKKNH5aOO++nkgvdSpizoXN0G/iB6ZnircccMqCXdeBxXUIKDTC66XHW/
         LDPk7hg05WYqy9/faHQS1PC++1UaMDmRZARur8mVU4M84SEZH2Hp6efqfh442agJk7yy
         x3IcZdiIqfKDYDZ0RBwIPnUNmUDBQgdGInlElOsAqplTKJaure2g5DfIAiGZIMv6teSu
         iFphipam0q7Op1PWRrxxpnl/Ikzt20dm2qnN4unW70jVEKR7+1KiKhG6N+Wkb/RTGmRH
         f+wGpePWu5sX8rpaX22cDuCLAK0daIJPgOi5swV4gIF/O1EnQIH4rF+5YJOzE1F6r8GY
         jd6w==
X-Gm-Message-State: AOJu0Yy3g1RBiS6sq4WyTMWs/isu8XViw8Ux8jbNu+RpxdJIKnlFS8mm
	S9btRRCFNo9e4OQE6rHruNoyR1z0xXnIhf94+62KxoZ8k662/RcAVkB9sd6XscEvMnshPUQJ4q3
	Paxc=
X-Gm-Gg: ASbGnctG18oPsw3uJQkrdntVlkEymyXRA3Ev3kzhVNFRki87u/TDdJxenmZXuvXVGaq
	NX48hDQIkslhA+Tt7djSwnlgqh8jB6QYUdB3OxQvH0976SRn4HmJ7pNQhgY7r+LhDA4rB0jMLHM
	6UbdYoEHt/5AeF05afVE/GNzvxVDQbUyqoDz0VjMZEa9JvNtAf3LA84xlg8JwOy4E+61DuCbkoU
	g/eTDj1GPAK8prBPmvrF2MsaQQmy5oIB8fd2mVxc5CnLnQZffpj5Q+r/7HJhniyp3JBukYy0f6e
	pRv9c6aPCVVjBcdsbvuqP9s3rYTW5bw+kqzgtFUVgjvZfYwquWJVyUGa44+GU4D/HGnD65lRkf7
	CiOGx1ALf/gHNskGXtonfSTlPB/Nm/gRyX/PYBC6/GdFZ6S2jgiRg+MZWAiRPdIlVsxp1ZbLhTE
	/XkbkFxWM=
X-Google-Smtp-Source: AGHT+IG7y4UydNtACL/2wsLnjvEhpHg/k9mPG70wHgfhNT8ZiHTOchCiSw9RkMoWGaerURFpFxbJ7w==
X-Received: by 2002:a17:907:3e11:b0:b04:65b4:711 with SMTP id a640c23a62f3a-b0465b40a87mr400583566b.57.1756915039128;
        Wed, 03 Sep 2025 08:57:19 -0700 (PDT)
Message-ID: 
Date: Wed, 3 Sep 2025 17:57:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging-4.19 | dabd7193
To: "xen-devel@lists.xenproject.org" 
References: <68b85acabf772_2ce5982c10997@gitlab-sidekiq-catchall-v2-5996545549-5wvcj.mail>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <68b85acabf772_2ce5982c10997@gitlab-sidekiq-catchall-v2-5996545549-5wvcj.mail>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.09.2025 17:12, GitLab wrote:
> 
> 
> Pipeline #2019389649 has failed!
> 
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging-4.19 ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.19 )
> 
> Commit: dabd7193 ( https://gitlab.com/xen-project/hardware/xen/-/commit/dabd719321b652286b9d0b0c23e29c8427eb7da5 )
> Commit Message: x86/gen-cpuid: Fix debugging for cycle detectio...
> Commit Author: Andrew Cooper ( https://gitlab.com/andyhhp )
> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
> 
> 
> Pipeline #2019389649 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/2019389649 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
> had 1 failed job.
> 
> Job #11232025215 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11232025215/raw )
> 
> Stage: test
> Name: qemu-alpine-x86_64-gcc

I cannot make sense of the failure, and hence I have no idea what to do. Is
the perhaps another root container issue?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 15:58:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 15:58:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108694.1458747 (Exim 4.92)
	(envelope-from )
	id 1utpsb-0003sv-24; Wed, 03 Sep 2025 15:58:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108694.1458747; Wed, 03 Sep 2025 15:58: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 1utpsa-0003so-VN; Wed, 03 Sep 2025 15:58:36 +0000
Received: by outflank-mailman (input) for mailman id 1108694;
 Wed, 03 Sep 2025 15:58: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 1utpsZ-0003sh-NZ
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 15:58:35 +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 d86653e4-88de-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 17:58:34 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b00a9989633so5223966b.0
 for ; Wed, 03 Sep 2025 08:58: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
 a640c23a62f3a-b043fd772bcsm619118766b.14.2025.09.03.08.58.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 08:58: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: d86653e4-88de-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756915114; x=1757519914; 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=swygL5HGQPRrf90Ch5ImAesfih2ztHFLRV2/KGDu/0w=;
        b=X5+q4wwdWEUWhXpc+jYxU1kPhc1IAGkvtfngZU/lls1Zceo889dMEVo8nlNnjAHVTh
         vmZ0NJayeu12XVeCp2FKWrJuRe9sdbaUGu0/W4Pv3SEXmocebzeSXS/keBPXlRyHDJ49
         jsnMa+XFt280hdkEK7+DdPHkwoxBljpApAmguiG0ZSEcb51VeqF6bskV9e0/vUT4TwrS
         IjXzoROv1FX2EhX6Tjtm4TSnAi93af3bIGLJaUTm7XeAtPWHxDqJDsy1vH8bubpCr7sN
         IXULmlYVbQjLzE4MF4cAv100JxBVqlRz11hg3A7sXsSZTr5oM3taLf4UY5CtqtH+ECi8
         yaAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756915114; x=1757519914;
        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=swygL5HGQPRrf90Ch5ImAesfih2ztHFLRV2/KGDu/0w=;
        b=XDIx/FXkHEDSWW/fPrR8SmjhVG3RZOVyPd6ubObLl/TMWOkVLC3BBI8fBvaIUZ/hLm
         gSKRfqRKBiqcxDeyPIT9xcC8xew7624wuHWY8wwd6ZGl1ZELMc4QxruHVHh+JmmzyR3B
         lLcjeXTg5PSR5XpOKHzycGGpeizhDuqLnjh5WCq2v3+By+3C1gDyOxe/yZhswyQ/Ts0T
         ZVE/vGX3wyGdFtSxy9VZYx9lrK8rplgnttH13S97xJTvt9CcHlJ2Leb8w+M+ESpxO1hC
         TCZlCw/7vlYKEZFL9IUtl39QXGsqVdMIn3ydOT0RmPhHbcmhjPDjdwQaalP6fRpeY5mZ
         vgOA==
X-Gm-Message-State: AOJu0Yx2Yy3MLhVdTUe87+CXSZRO05pTM2z/u4qz+mKFWR0vJ7eUdj1o
	5oOSZVaKJgfXWsx4UlDjEkTyGYN4HDAveHP21fKjCzmMwVpN+Wse5J6y+CTjFEzK62IodROwBRq
	Sy84=
X-Gm-Gg: ASbGncv4O+njklMJPKPSe6GghnvjeAwue801W+NEh6jcoNCGo0wbW2zyvjjKbPMIuOL
	bdInljJ2CCOCfOQbLgT1f1xuus8kfNyJTHkuq4No7f9tsaZ7Kq3GEedcoNoFsKTeeT9h1Sd7+k7
	HkL38/KOp5RiM8Hu5qk1pPcuUBAy8SmlCccnl7Esa6Zp++9qrJpR9vmHyvWB6JwCYBubOgeIaIo
	8cSqE7dPMp+EGx2/d9ljyIHCJhnye9dzuTEvmLlrrxBzz+4WZsOJucw/QyAAq/OT5RCYIZuBXNY
	HZ+0NAJtUyZBVKYnMogNoZuT0bfPbhsSxcdvA4NkSjkQ9HiG/wnC4eiNsxttfyArG9S2XgpX8iB
	SRUHrWWFhycJxPjBYDwR3QC97Z2q68xJ3D76AEeazB86PsW6THdB/WG/g3YT6qGIpr62GyD851G
	wSoE0rFS0=
X-Google-Smtp-Source: AGHT+IGhv8ojIwRCD6DqlFDEyPc2ZAM0qk1s1t2mvMNgQ5ZlXhQVn0oUuK0gyi4LD2rZRTB1WYo8Yw==
X-Received: by 2002:a17:906:4fca:b0:afe:ac57:f0be with SMTP id a640c23a62f3a-b010832f5famr1686552566b.31.1756915113843;
        Wed, 03 Sep 2025 08:58:33 -0700 (PDT)
Message-ID: <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com>
Date: Wed, 3 Sep 2025 17:58:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865
To: "xen-devel@lists.xenproject.org" 
References: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
Content-Language: en-US
Cc: Marek Marczykowski 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2025 17:46, GitLab wrote:
> 
> 
> Pipeline #2019390073 has failed!
> 
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging-4.18 ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.18 )
> 
> Commit: 51190865 ( https://gitlab.com/xen-project/hardware/xen/-/commit/51190865a4918c443c310c0478247d5f9caa5dad )
> Commit Message: x86/suspend: unconditionally raise a timer soft...
> Commit Author: Roger Pau Monné
> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
> 
> 
> Pipeline #2019390073 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/2019390073 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
> had 5 failed jobs.
> 
> Job #11230955404 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955404/raw )
> 
> Stage: test
> Name: adl-suspend-x86-64-gcc-debug
> Job #11230955410 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955410/raw )
> 
> Stage: test
> Name: adl-pci-pv-x86-64-gcc-debug
> Job #11230955417 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955417/raw )
> 
> Stage: test
> Name: adl-pci-hvm-x86-64-gcc-debug
> Job #11233274365 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233274365/raw )
> 
> Stage: test
> Name: adl-smoke-x86-64-gcc-debug
> Job #11233405609 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233405609/raw )
> 
> Stage: test
> Name: adl-smoke-x86-64-dom0pvh-gcc-debug

While the same tests are fine for 4.19 and 4.20, all five show rubbish in the log,
and then fail. No idea what's going on.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 16:03:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 16:03:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108704.1458757 (Exim 4.92)
	(envelope-from )
	id 1utpxj-00067K-Kb; Wed, 03 Sep 2025 16:03:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108704.1458757; Wed, 03 Sep 2025 16: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 1utpxj-00067D-HK; Wed, 03 Sep 2025 16:03:55 +0000
Received: by outflank-mailman (input) for mailman id 1108704;
 Wed, 03 Sep 2025 16:03: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 1utpxi-000677-6Z
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:03:54 +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 954fc57b-88df-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 18:03:52 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49])
 by mailfout.phl.internal (Postfix) with ESMTP id C8C69EC0372;
 Wed,  3 Sep 2025 12:03:50 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Wed, 03 Sep 2025 12:03:50 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 3 Sep 2025 12:03:49 -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: 954fc57b-88df-11f0-9d12-b5c5bf9af7f9
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=1756915430;
	 x=1757001830; bh=QhuJG5jH3FUiFBRyUodftBCdADSu6DKWopmjVFxsQsQ=; b=
	BWuiuCfEWda9GqGoNOUNV9pV1p1duJgNWmlR3BcXhroMpYa2NcsbTEGZjdgbc4nt
	hc0/yatLw31QibLg3k2QgfrqZ4PtYTbFSChnZ1fCUBVC4gAP9u187PNXAZwhMjgN
	Gfv+GOUcTsS6vusd3cG/c2lfOYBRf10R55eof9kZ6gkiySXRDgR4VUe/9dOkOUKo
	M2p76vZXI/RCVV5ffuiKjuPp2hDMOE0hijGHWLvHPALkTC09QORZB4s7TGJlOCSu
	iozEaLUUS1wOwaVodNbOxPCdUMmDlRCtujekh5fv6uKycHEg0eS7V3BlzT2C/xC8
	mt+JSLerRTDnSJn6lX3wNA==
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=
	1756915430; x=1757001830; bh=QhuJG5jH3FUiFBRyUodftBCdADSu6DKWopm
	jVFxsQsQ=; b=LQvKRqtPxc9uAIwq8N+vRdH4vWIGIKwO4SAT/7zdVz6/iWHPGmf
	oE8et3NyXIFfQWphgrg8AYb7rTY3aabaLloXK1T5D2d2besDbL5/NGjQMeEU5bIp
	gLj9qYiTQd+71RXmioIZx/R0orZrjRaxiaKP0a0mLlarxKJMBDsFX4YyIVtguar3
	SFjfPhf1jPiW57e7LaISZvrafAb5cMGHjz7ET0/agXJKT3jGEA3HNGUsKYQqLRSK
	wZy+Jm/yI2yAxOY/0af/C2E81pm/SJ3vefToQwoJ92OmZfxxmBG/Bo80VCr5j/pZ
	Bg1LLls3XCD6Oqt5tj9plAXWRIA1lnuEoHQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefheejucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhngh
    hslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephedtfeeuhffgjeehfeetvdevueef
    feehkeetfedujeehgfejudehleegudehgeeunecuffhomhgrihhnpehgihhtlhgrsgdrtg
    homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm
    rghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprh
    gtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjsggvuhhlihgt
    hhesshhushgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi
    gvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 3 Sep 2025 18:03:48 +0200
From: Marek Marczykowski 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" 
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865
Message-ID: 
References: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
 <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="SgNpc6CmfrriC82Z"
Content-Disposition: inline
In-Reply-To: <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com>


--SgNpc6CmfrriC82Z
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Sep 2025 18:03:48 +0200
From: Marek Marczykowski 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" 
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865

On Wed, Sep 03, 2025 at 05:58:32PM +0200, Jan Beulich wrote:
> On 03.09.2025 17:46, GitLab wrote:
> >=20
> >=20
> > Pipeline #2019390073 has failed!
> >=20
> > Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> > Branch: staging-4.18 ( https://gitlab.com/xen-project/hardware/xen/-/co=
mmits/staging-4.18 )
> >=20
> > Commit: 51190865 ( https://gitlab.com/xen-project/hardware/xen/-/commit=
/51190865a4918c443c310c0478247d5f9caa5dad )
> > Commit Message: x86/suspend: unconditionally raise a timer soft...
> > Commit Author: Roger Pau Monn=C3=A9
> > Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
> >=20
> >=20
> > Pipeline #2019390073 ( https://gitlab.com/xen-project/hardware/xen/-/pi=
pelines/2019390073 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich=
 )
> > had 5 failed jobs.
> >=20
> > Job #11230955404 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/1=
1230955404/raw )
> >=20
> > Stage: test
> > Name: adl-suspend-x86-64-gcc-debug
> > Job #11230955410 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/1=
1230955410/raw )
> >=20
> > Stage: test
> > Name: adl-pci-pv-x86-64-gcc-debug
> > Job #11230955417 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/1=
1230955417/raw )
> >=20
> > Stage: test
> > Name: adl-pci-hvm-x86-64-gcc-debug
> > Job #11233274365 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/1=
1233274365/raw )
> >=20
> > Stage: test
> > Name: adl-smoke-x86-64-gcc-debug
> > Job #11233405609 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/1=
1233405609/raw )
> >=20
> > Stage: test
> > Name: adl-smoke-x86-64-dom0pvh-gcc-debug
>=20
> While the same tests are fine for 4.19 and 4.20, all five show rubbish in=
 the log,
> and then fail. No idea what's going on.

The log says "baudrate is    : 115200", but looking at the state after
the test I see 9600. No idea if that was simply switched back after, or
setting to 115200 didn't work. Anyway I suggest to restart (now that
other jobs completed). I set it manually to 115200 now too (not sure if
that will remain there...).

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi4ZuQACgkQ24/THMrX
1yzTSQf+NTmipxFLJS9WXMocgL9X1Q+PudDLkjXaVdaClXxkYZ7PmLYrSasFPijs
ieiO6dEG+zdrfRwOlVhISYiEAu60EQNy2t8kNtbMYmpI4Bdea2yW/K5aopPW5mJE
aqBcFuVDHqn86ZtrIcDTXacytLjvYe5ASoD3jPPgnX2T4BMO6Rrsy5LiZYGFFqMB
IS5jVA8fgAEaHEoJRyYi3PD7Q0EvHc2e298NpsxzbNMGw2eBZDDbezpBWM3AdzeA
kTVrucF4gqrnLPTngSyJJErb6R3J62WYeMXnXPKx25cWM/PXmoFshtieeQK43kr5
maiZghBRL8g2vEji4rLm5p71BZqlvQ==
=D836
-----END PGP SIGNATURE-----

--SgNpc6CmfrriC82Z--


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 16:06:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 16:06:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108715.1458766 (Exim 4.92)
	(envelope-from )
	id 1utpzq-0006eJ-UX; Wed, 03 Sep 2025 16:06:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108715.1458766; Wed, 03 Sep 2025 16:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utpzq-0006eC-S0; Wed, 03 Sep 2025 16:06:06 +0000
Received: by outflank-mailman (input) for mailman id 1108715;
 Wed, 03 Sep 2025 16:06:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1utpzp-0006e4-Ii
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:06:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1utpzk-004fAB-3A;
 Wed, 03 Sep 2025 16:06:01 +0000
Received: from [2a01:cb15:80df:da00:7079:39df:8b4d:ea79] (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 1utpzk-00EXCz-2l;
 Wed, 03 Sep 2025 16:06: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=QBURlunJTq1qQGHrqwTGQ18AUOR39bZplNHJB3yn0to=; b=zp8YMSugmQVlJRMHC8e3hK0b1z
	tZW6E5vbZnb2Typxm5FEvqYbjZ0WTKqqrHziNtC4hOTZWa2gXQloK17MEoTMEZAor6imK3jiDNNmQ
	6faSHtIqhN6er5r+FMzZKPH6RiqS0KiO7azj8zVv2JczodPRKxYySK9xuFcxxtDSxYb0=;
Date: Wed, 3 Sep 2025 18:05:59 +0200
From: Anthony PERARD 
To: Jahan Murudi 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD 
Subject: Re: [PATCH v4 0/4]  xentop: add physical CPU usage support
Message-ID: 
References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com>

Hi Jahan,

On Wed, Sep 03, 2025 at 03:53:19PM +0530, Jahan Murudi wrote:
> This is v4 of the patch series to add physical CPU monitoring to xentop.
> 
> Changes since v3:
> -   Split the single large patch into a logical series of 3 smaller patches
>     for easier review.

The single patch in v3 was fine to review. It didn't really need to be
cut into several patches. Having one file change per patch is certainly
the worse possible way to cut one patch into several.

It might have been possible to separate into several patch in another
way, but it's a bit too late for that, there's already been several
reviews. What I like to do when I review a patch series, is to look at
the difference since the last review I gave, tools like
`git range-diff` and https://patchew.org/Xen/ can help with that.

Anyway, squashing back all the patch is the way to go I think.

I'll have a look at the changes.

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 16:07:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 16:07:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108724.1458777 (Exim 4.92)
	(envelope-from )
	id 1utq1e-0007Bo-9x; Wed, 03 Sep 2025 16:07:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108724.1458777; Wed, 03 Sep 2025 16:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utq1e-0007Bh-6W; Wed, 03 Sep 2025 16:07:58 +0000
Received: by outflank-mailman (input) for mailman id 1108724;
 Wed, 03 Sep 2025 16:07: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 1utq1c-0007BZ-97
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:07: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 25f24d9c-88e0-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 18:07:54 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3c46686d1e6so74342f8f.3
 for ; Wed, 03 Sep 2025 09:07:54 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3df4fd372ccsm2044061f8f.32.2025.09.03.09.07.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 09:07: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: 25f24d9c-88e0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1756915673; x=1757520473; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3m/rgbH8ClLoYH3sdTBN3BOtpxBTw+323MJgH3uWVbQ=;
        b=LuF4GNcm/ZvGa/z2fQ+VAfGrgg4/LsYQQ2Hlx1tGTkvRuaETryLKPO8s00ZCV6c7OE
         I4o6K+5EO1W3KOBAPqLrWw5X4jNrqAJixuSSAEX4QrxC4uDAD8VtSRIrVRTVnSUb+zkN
         KvjkJWcFdqq3N8+KL9QFoxrbeDMDva6R4rfe8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756915673; x=1757520473;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3m/rgbH8ClLoYH3sdTBN3BOtpxBTw+323MJgH3uWVbQ=;
        b=mIDY0xasOiIBmpoupXYfIgWjBUD99eVuQjtpwRvV9H/7gbWISGbA1HsS4EGBhALcXE
         /HD+hOMmqSv/Kq3/UbguW0LBsy7K9JHNoiiICbk+IHCCIv2e9AJ9xztGF5wugaDO/Wrd
         bCWw6KZ5NM2bDA6eucRObuzmvolgGxfjfUkC1oXEzOZKy02j1pJ7GXxjP8XMvxglYkh7
         RfMOYqmZuk0xRaJt+HrIOIrnYxn0R4Hldht0BWEU2M0I1n2RuPyKZaKF5SpfiNBBNKP1
         wRT5STMzK/Zy04T5SuyAGf9YTy8WpazRpGjP/8zj3wDGr0d9wASDWmAI/jQBjiQG9xn8
         BLCQ==
X-Forwarded-Encrypted: i=1; AJvYcCU/tShm2CHI+2vNlvS0CJZDHc5vb86PJWYE/jvW7pVpgNyUb/PaXN9GVhfLCjyP350Yo7heMonzkdc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQXVjwIxOm7zlB7lvZFcGW8LgVPxEJTKeHeE7jaowJRCNjr+Dx
	yd1vOY7ytw0kercMyzpJ5FJzmDMMPz1wdR+Bu6IbqH6+8+K1Inyoa8dfBsqpKXVZdj/W7TBnREp
	UyJPC
X-Gm-Gg: ASbGncs4HW0UR6Dw4UJbE0ZkRwnja+L4ZkASKi5pCWQ3DzQqeGEpu3B7dzUXq1IxGb7
	pOIhMdet+uhls67R20cYN3RI3Pd/67pRuHl4os5SVQEgppL6P8GPbXAT/aYCwWhUhxpT3o29TMT
	jrx1HfZsEsAr/MeMjwSawYy5t/oVeT6IQa9FVU8J1KmMtSVRIsrp1XITStH4X5xc2zQ/qUnnLE0
	BqAYpSjmDj59JrGTjyqoKSDiHnX3GR+L+l6B/WVAmn3V9EGS5NjE52QrbypcXTqXir+Fac6K8NU
	NKrAYTh/Qt8JL7yy+NiJQi3R0mdxUxgxSJH1eipnmLb22ZVBIeg1vepoADeItyAKRisEL4MvZtx
	R75AEQzQM+8qmBWcEmm9mjSWVIhTcc6FGELdHLPJ5eJanEnA6149d7bvIIK0pdVbHnlxL
X-Google-Smtp-Source: AGHT+IHwyHE/oR9zGyf3axYiroAcD3V1o5Yf1SItG89C5yfJqjKaKRJCTfyVwafmHzmiiM09VsbO1w==
X-Received: by 2002:a05:6000:26cb:b0:3ce:f0a5:d581 with SMTP id ffacd0b85a97d-3d1dd81d1cfmr11673916f8f.7.1756915673339;
        Wed, 03 Sep 2025 09:07:53 -0700 (PDT)
Message-ID: 
Date: Wed, 3 Sep 2025 17:07:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging-4.19 | dabd7193
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
References: <68b85acabf772_2ce5982c10997@gitlab-sidekiq-catchall-v2-5996545549-5wvcj.mail>
 
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/09/2025 4:57 pm, Jan Beulich wrote:
> On 03.09.2025 17:12, GitLab wrote:
>>
>> Pipeline #2019389649 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging-4.19 ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.19 )
>>
>> Commit: dabd7193 ( https://gitlab.com/xen-project/hardware/xen/-/commit/dabd719321b652286b9d0b0c23e29c8427eb7da5 )
>> Commit Message: x86/gen-cpuid: Fix debugging for cycle detectio...
>> Commit Author: Andrew Cooper ( https://gitlab.com/andyhhp )
>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>>
>>
>> Pipeline #2019389649 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/2019389649 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>> had 1 failed job.
>>
>> Job #11232025215 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11232025215/raw )
>>
>> Stage: test
>> Name: qemu-alpine-x86_64-gcc
> I cannot make sense of the failure, and hence I have no idea what to do. Is
> the perhaps another root container issue?

Seems like a likely guess.

That ran on gitlab-docker-seagull, but this is the singular failure
https://gitlab.com/groups/xen-project/-/runners/14174957

The sequentially previous job was
https://gitlab.com/xen-project/hardware/xen/-/jobs/11230956609 which was
a Xen 4.17 run of opensuse-leap-gcc which is a root container.

I think I'm going to have to do some careful container rebuilding here...

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 16:12:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 16:12:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108735.1458787 (Exim 4.92)
	(envelope-from )
	id 1utq6E-0000WR-Sd; Wed, 03 Sep 2025 16:12:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108735.1458787; Wed, 03 Sep 2025 16:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utq6E-0000WK-P2; Wed, 03 Sep 2025 16:12:42 +0000
Received: by outflank-mailman (input) for mailman id 1108735;
 Wed, 03 Sep 2025 16:12:41 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1utq6D-0000WE-7k
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:12:41 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1utq6C-004fHW-2r
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:12:41 +0000
Received: from mail-vk1-f181.google.com ([209.85.221.181])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1utq6D-00EXUO-08
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:12:41 +0000
Received: by mail-vk1-f181.google.com with SMTP id
 71dfb90a1353d-54494c3f7e3so32897e0c.3
 for ; Wed, 03 Sep 2025 09:12: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:To:Subject:Message-ID:Date:
	From:MIME-Version; bh=3T7ONl120rt7DynkOWZgU7o776H43FGtrof5fUbU7LA=; b=qzByZ+l
	2GDdpm0b+cdsyy7RumekVpg0XDA+vNFkDgnax2g537ZgK9EDBB+xfN58KYY7ykqTTVj2dYzmm+2hU
	fsTJTDBPkAWp0I6/2tn0qmZqT6jmATk/cgxRqATF88MOAkjMetbXGvgebBZgHv2K6XSsaX4gMvwal
	JPhFYFkMvQ=;
X-Gm-Message-State: AOJu0YwSV54FGYL+PHbj1mvdTqausRsKqIv6esuFtgwZpSegyv4+EtR/
	6TcK7sP6OWF/gGQuEP9Ve6nJ6jaPzmfQWJQdQWAIfVD8IjQ9mcBHmjxZQH9tZXrqueiEtdiVlW0
	wGIQP6i/jAFlbODYgzMXLIELqHJVY1aI=
X-Google-Smtp-Source: AGHT+IHCodRux8M1NXNWf8JeRJcZlYsRRpueRkIgXc/lGyzE7MXMY2YOr8QwwIlTEJ91gmPYTXc7RJpQHF++Y/Xfysc=
X-Received: by 2002:a05:6122:1350:b0:531:4041:c4c5 with SMTP id
 71dfb90a1353d-544a01cf405mr4619082e0c.7.1756915960513; Wed, 03 Sep 2025
 09:12:40 -0700 (PDT)
MIME-Version: 1.0
From: Cody Zuschlag 
Date: Wed, 3 Sep 2025 18:12:29 +0200
X-Gmail-Original-Message-ID: 
X-Gm-Features: Ac12FXxrBDs_tIPltVir-IgbDTf1hDntl1d40dzIpp9ePjRfu9kXuuXUqqW2bVQ
Message-ID: 
Subject: Xen Summit Updates
To: xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="000000000000ba0ca7063de7df41"

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

Hi everyone,

Xen Summit in Silicon Valley is starting in less than 2 weeks (September
15-17). I hope you're ready for the big event!

Here are a few quick updates:

   - *Schedule:* The schedule is live !
   We may make last-minute adjustments, so check back regularly.
   - *Registration:* If you are attending, please register as soon as
   possible. This helps us plan badges and meals. Attendees receive a daily
   hot breakfast and lunch, plus an invitation to the Tuesday evening dinne=
r
   at Loma Brewing Co. .
   - *Speakers:* You=E2=80=99ll receive a registration code and link.
   - *Sponsors:* If your employer is a sponsor, ask for the sponsor
   registration codes.
   - *All others:* Please register here
   .
   - *International travelers*: Let me know if you need a visa letter or
   formal invitation.
   - *Diversity scholarship:* There=E2=80=99s still time to apply
   !
   - *Design sessions:* Once you=E2=80=99re registered, watch for an email =
with
   details on how to suggest and vote for design sessions (or ask me). Thes=
e
   sessions are a great way to shape the future of Xen. Don=E2=80=99t miss =
out!

As always, don't hesitate to reach out if you have any questions. I'm here
to help!

Have a great day,


Cody Zuschlag
Xen Project - Community Manager

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


Hi everyone,

Xen Summit in Silicon Valley is starting in less than 2 weeks (September=
 15-17).=C2=A0I hope you're ready for the big event!

Here are a few quick updates:
  • Schedule: The=
 schedule is live! We may =
make last-minute adjustments, so check back regularly.
  • Registrat=
ion: If you are attending, please register as soon as possible. This he=
lps us plan badges and meals. Attendees receive a daily hot breakfast and l=
unch, plus an invitation to the Tuesday evening dinner at Loma Brewing Co..
  • Speakers: You=E2=80=
=99ll receive a registration code and link.
  • Sponsors: If you=
r employer is a sponsor, ask for the sponsor registration codes.
  • All others: Please register here.
  • International travelers: Le=
t me know if you need a visa letter or formal invitation.
  • Divers=
ity scholarship: There=E2=80=99s still time to apply!
  • Design sessions: Once you=
=E2=80=99re registered, watch for an email with details on how to suggest a=
nd vote for design sessions (or ask me). These sessions are a great way to =
shape the future of Xen. Don=E2=80=99t miss out!
A=
s always, don't hesitate to reach out if you have any questions. I'=
m here to help!

Have a great day,
=


Cody Zuschlag
Xen Project - Co=
mmunity Manager


--000000000000ba0ca7063de7df41--


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 16:12:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 16:12:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108736.1458797 (Exim 4.92)
	(envelope-from )
	id 1utq6H-0000kd-6D; Wed, 03 Sep 2025 16:12:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108736.1458797; Wed, 03 Sep 2025 16:12: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 1utq6H-0000kW-3C; Wed, 03 Sep 2025 16:12:45 +0000
Received: by outflank-mailman (input) for mailman id 1108736;
 Wed, 03 Sep 2025 16:12: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 1utq6F-0000ey-Le
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:12: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 d12eae53-88e0-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 18:12:41 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-61cc281171cso19006a12.0
 for ; Wed, 03 Sep 2025 09:12: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
 a640c23a62f3a-b046f2dda22sm134420466b.40.2025.09.03.09.12.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 09: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: d12eae53-88e0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756915961; x=1757520761; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QUf9Bi1fhQo7vi2u6LKUPiphXi834CMqGISW0FVoQo0=;
        b=dskfjaZ4Urm2fjKqwyPnmNUg+qDDXeGHoZFZXMZu5e+CZbmlEF0VCp1g8fMDpYt8gL
         XV4urUD/8aO+AvE1xRW3GPQEQCqlxDOvqevvrifJk2Lb+CQ37zDbn2tgJFsuz2gbQWxB
         qp8bdfuLO3o9vjC9uKwlR6/MAfpoTuYUgh2+OIdfPrdDrSj7ZDuBiPTExgPc0ANntcoP
         8GeLCblQ8cCdBxTBaCb1LOiME2w/zDOp7D7wOEZ+C8IJVHNuDMXT4BgSF9HcdSrlQ4We
         ccvBJq49A5iEVujmS/gpreQvZAtcl39XsKnH89UygbSP3TBu5EB+QMMjybIBvDfENQpE
         eKjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756915961; x=1757520761;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QUf9Bi1fhQo7vi2u6LKUPiphXi834CMqGISW0FVoQo0=;
        b=fLNres6kLQkaeY2UyPY7+n/GbI+sZKtXNLXHyesF/5fV1GozCe2Qp1RZuuB+OMQHYS
         fkMxym5/COShxAC3kO8N+Cp0YhBsGnRn6O5n7vKdZ7kW2VrKf64iewKWQuC98G72jPaV
         vPq0yz0TQlnjmuFIGc6bw9LZ+J5CnqXx9uiQFmZiAWfIq9AQxiuiWE9PybfNutpjlgLy
         U0d+uvVUfAukp5qcIBmOY4XtQ44UHjUhQ+Zs1HBWzt0If2abQdXbFwRMAiQaAjIR60Lk
         K8ZrhUI7KGaRmYG+SQzhgti1G1I69OlFv/VcHHzLsEw6M1fR+Z9Wtj78nLcjCV8LJ6o2
         OBdA==
X-Forwarded-Encrypted: i=1; AJvYcCUdx+wXV8KAxDgPugbybpNPR+PgA9iwIYn8gHlTDaqQeE8jPhH81TClJ1e3Ek9Pqn+pyNdcPAU7KSE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz6+Z+YtB8Ykh3wYgXoK7PJEX+lTmmLz7kEg6e0rQTdcGkWpLR4
	ZNB+kjvHWxX4qSrN83Q7gSxY+0CHTr/2JggF3SGbcNOJC5a4+73wUkYP9RqAElRrqQ==
X-Gm-Gg: ASbGncutXo5rm1CvYa16RWSGgyVrjP3xYsQ6nj0aJiBxhDCBtD9rx6h+GQUStz7HwMK
	GV2+7VPi+4LRt7dWDhFXDebiVMNswWL0KrX3GF05L0TJ2B+0BVyFgOijkpSrqQDNG2ktP5azuqs
	xcwf5xUfPhOSSEXbidzS7x+mx2fBnfAVrceqGd2nRzv1MTIflbXxDtfDNvp51PkKUGsY2uAqlY7
	JFiFklaIxtN8od97XJWGewp9QmqXJO3pbUSWBv+/RUeN0zurwpXpgvqiAD+GZYgt0aKgGmf1QYE
	krUdZbqqChIdCUgWbQ7DVVvan9zWOYwyZ6t3qaZ/hCbpNjdIXCVQzbipbG5qr9PTUbQPS8m1tXL
	Fb6xbuAbiLjxSP3U9jpM2nyHQcpHFkFU7pbPmilpA8RweiR5Hm8wp3a+PA0VPgDMTQpvfdpT6sB
	EuI12JlvxSeQCpEr0GaA==
X-Google-Smtp-Source: AGHT+IGvs8DYxc7WiMoCGafuAjEIsWW1mTSYnu8O6CEKhKgeSQkG2VRc1k94PTcbw0s7SC0TgvkW2A==
X-Received: by 2002:a17:907:a0c8:b0:b04:3513:5138 with SMTP id a640c23a62f3a-b0435137355mr1042257066b.41.1756915960751;
        Wed, 03 Sep 2025 09:12:40 -0700 (PDT)
Message-ID: <6f310470-60f3-4c8e-a1fd-1216fd44e4ea@suse.com>
Date: Wed, 3 Sep 2025 18:12:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] build: avoid absolute paths in executables
To: Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" 
References: <1071997f-efe6-4088-b753-b74d3a045a09@suse.com>
 <795b069f-12ea-4d05-bdc4-877a6a93fe7c@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: <795b069f-12ea-4d05-bdc4-877a6a93fe7c@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2025 17:26, Andrew Cooper wrote:
> On 03/09/2025 4:13 pm, Jan Beulich wrote:
>> For in-tree builds relative paths are used, whereas for out-of-tree builds
>> in various situations absolute ones come into play. The extra paths can be
>> long, wasting space and e.g. serial line bandwidth. They would also get in
>> the way of location-independent reproducible builds. Leverage newer gcc's
>> (and Clang's) ability to "remap" file names. For older gcc fall back to
>> using the option affecting debug info only.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> Of course we may want to consider putting this in the top-level Config.mk,
>> to also affect other sub-trees (presently mainly/only affecting debug
>> info, for which even gcc5 already supports -fdebug-prefix-remap=).
>>
>> As to a Fixes: tag, I wasn't quite sure whether to "blame" the
>> introduction of out-of-tree builds.
>>
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -448,6 +448,8 @@ LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin
>>  endif
>>  
>>  ifdef building_out_of_srctree
>> +    CFLAGS += $(call cc-option,$(CC),-ffile-prefix-map=$(srctree)/=, \
>> +                                     -fdebug-prefix-map=$(srctree)/=)
>>      CFLAGS += -I$(objtree)/include
>>      CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
>>  endif
> 
> We do want to be taking a change like this, but it's also definitely not
> limited to out-of-tree builds.  I have full paths embedded even for
> in-tree builds.

In xen-syms I see only two full paths - in debug info, supplying the base
path to the tree. That's okay to stay imo.

In xen.efi I see a few hundred, but they're all the same as above. As I
learned earlier today, SHF_MERGE processing isn't invoked when linking
ELF objects into a PE binary.

> To be useful, it wants to apply to everything, not just the hypervisor,
> so does want to be in the top level Config.mk.

As per my first remark then. But no, I meanwhile realized that this can't
go in Config.mk: For the hypervisor we want to use $(srctree), i.e.
including the leaf /xen referencing the xen/ subtree. I expect that for
e.g. tools/libs/ we'd want something similar - eliminate the entire path
up to the base of the component's source dir. So it will need to be
piecemeal.

> https://reproducible-builds.org/docs/build-path/ has a full list of
> compiler versions. It looks like we need to use both options here until
> we can increase the minimum GCC version to 8.

Not quite, -ffile-prefix-map= is documented to imply all other
-f*-prefix-map=, matching my observations.

Bottom line - at least for now I think the patch wants to remain as is,
and further patches for other parts of the tree will need making.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 16:40:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 16:40:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108784.1458807 (Exim 4.92)
	(envelope-from )
	id 1utqXL-000584-A8; Wed, 03 Sep 2025 16:40:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108784.1458807; Wed, 03 Sep 2025 16:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utqXL-00057x-6I; Wed, 03 Sep 2025 16:40:43 +0000
Received: by outflank-mailman (input) for mailman id 1108784;
 Wed, 03 Sep 2025 16:40: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 1utqXK-00057h-8a
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 16:40:42 +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 ba6ee8bd-88e4-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 18:40:41 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45b7d87b90fso629105e9.0
 for ; Wed, 03 Sep 2025 09:40:41 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45b945332adsm99257745e9.4.2025.09.03.09.40.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 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: ba6ee8bd-88e4-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1756917640; x=1757522440; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Xipl4Nx72wtXbNptURyvN8Bu7gPb+9II1FnRgokKKuo=;
        b=BAVEdutVJRulNWbmfCFeGVXt8Nq30VaLirQkYEx3L0JWBk1UEGlZAMaEFSESc0FDp9
         KPTROMUTnKLxVxLzUxghQU0nzYjjalqQNtxcgTYY4wQcIJhtNNVthnVUf4LkPj5o2W7I
         0VzcOjfiZ05FAyj3izUC8w27bCQ1Xr67iOv0g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756917640; x=1757522440;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Xipl4Nx72wtXbNptURyvN8Bu7gPb+9II1FnRgokKKuo=;
        b=UNSVpNXMMOgbFOqA1oy0YujDjca8P5aAiWSh9TwARGE/CE/kOLO+r37ikL3XHMxFgU
         HpA7Iz6IBVul6nh1J5+yYyswdDIi875ySwKoZdgmremAyRGFfutq0K+cHX2DSvZINZNC
         gdZoNNgMhLQqp5ldUbTkeIw6n4dBebmzlpJ3TW01pUlUjCJ9AzdlrrojsJXkDAlkalX6
         yzIVyjetrGqzQGjD+Wi3aJyeFPhtCeqOS0qYzmPsMO0t9/lYlN9fm8taulwomvz80bUP
         JEHQX6NUh9n69D2wUTKGjWDahCwZI4KDM0HeJ0dODSFjRF9DwUlepqhHE3CdA98fB8JE
         aAkA==
X-Forwarded-Encrypted: i=1; AJvYcCUBmCsyK/VU7x+h41AgGGPKlydZ5NoLgkaHnS64QAVxu5diBHvhjg0VHELdnDgyiyYc9JoQSU0BKAM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywbb5sCq/B82FZJbUdTA0aCSXz6ymbi0oen6FNd5Ym1i21DzMZJ
	wgWFVUtJsbCICEiE39zD9JnivMDLYlQQVKhHHLK3tJefoO4RslQBldLilrI4TJiqeWs=
X-Gm-Gg: ASbGncu94qR348eDDMtVVFlSvusq9ccagTci56N8apjPNHdDdSeKWfbxe+h6XuhvzQJ
	Y0mxWl3zhq7G25imHr8RSaDqiidFVuL8TU8o8kFyIltBBv3I612fVe/qvkDdDdEpFR03sQ3/Bek
	GjhPZrj+bdVNwLAKHJfWMJE665e7ijDJH7fCmwhBcVxlm8GUdhBsaZj5lAiWiYUmC4ZCGBYZew2
	iTsG4u91MMxx6oDAoWOs4gXgSBxBpoQn1zDtjd6VRZoC1z0rpHZb9BhGuZKn1yaX19Ypzff/t2U
	mK536+6kGQrH1wnSin10p20ci2MlTBzBvLPmXiws+xU21TRi/Mc2eBsuOPPUBDyQn5w6ilv70ij
	7FxwoNv8F+lo4hRwtdba4JJ2n9toKaeojr3oZQTCJ/wkNWcm59HnFKHF8DoOvpaA8qqHgTS4QI6
	BwQpk=
X-Google-Smtp-Source: AGHT+IGOXKgQc4XJzlsPghZlERMc0676mTnGZbRUvoySHNCKvo8Q7Ux5L85BV+L7kMGCHtz9Ne+CCA==
X-Received: by 2002:a05:600c:c4a1:b0:459:443e:b18a with SMTP id 5b1f17b1804b1-45b8559aff8mr148984485e9.14.1756917640500;
        Wed, 03 Sep 2025 09:40:40 -0700 (PDT)
Message-ID: 
Date: Wed, 3 Sep 2025 17:40:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] build: avoid absolute paths in executables
To: Jan Beulich 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Oleksii Kurochko 
References: <1071997f-efe6-4088-b753-b74d3a045a09@suse.com>
 <795b069f-12ea-4d05-bdc4-877a6a93fe7c@citrix.com>
 <6f310470-60f3-4c8e-a1fd-1216fd44e4ea@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: <6f310470-60f3-4c8e-a1fd-1216fd44e4ea@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/09/2025 5:12 pm, Jan Beulich wrote:
> On 03.09.2025 17:26, Andrew Cooper wrote:
>> On 03/09/2025 4:13 pm, Jan Beulich wrote:
>>> For in-tree builds relative paths are used, whereas for out-of-tree builds
>>> in various situations absolute ones come into play. The extra paths can be
>>> long, wasting space and e.g. serial line bandwidth. They would also get in
>>> the way of location-independent reproducible builds. Leverage newer gcc's
>>> (and Clang's) ability to "remap" file names. For older gcc fall back to
>>> using the option affecting debug info only.
>>>
>>> Signed-off-by: Jan Beulich 
>>> ---
>>> Of course we may want to consider putting this in the top-level Config.mk,
>>> to also affect other sub-trees (presently mainly/only affecting debug
>>> info, for which even gcc5 already supports -fdebug-prefix-remap=).
>>>
>>> As to a Fixes: tag, I wasn't quite sure whether to "blame" the
>>> introduction of out-of-tree builds.
>>>
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -448,6 +448,8 @@ LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin
>>>  endif
>>>  
>>>  ifdef building_out_of_srctree
>>> +    CFLAGS += $(call cc-option,$(CC),-ffile-prefix-map=$(srctree)/=, \
>>> +                                     -fdebug-prefix-map=$(srctree)/=)
>>>      CFLAGS += -I$(objtree)/include
>>>      CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
>>>  endif
>> We do want to be taking a change like this, but it's also definitely not
>> limited to out-of-tree builds.  I have full paths embedded even for
>> in-tree builds.
> In xen-syms I see only two full paths - in debug info, supplying the base
> path to the tree. That's okay to stay imo.

Not for reducible builds it's not.

>
> In xen.efi I see a few hundred, but they're all the same as above. As I
> learned earlier today, SHF_MERGE processing isn't invoked when linking
> ELF objects into a PE binary.
>
>> To be useful, it wants to apply to everything, not just the hypervisor,
>> so does want to be in the top level Config.mk.
> As per my first remark then. But no, I meanwhile realized that this can't
> go in Config.mk: For the hypervisor we want to use $(srctree), i.e.
> including the leaf /xen referencing the xen/ subtree. I expect that for
> e.g. tools/libs/ we'd want something similar - eliminate the entire path
> up to the base of the component's source dir. So it will need to be
> piecemeal.

Relative to the root of xen.git (or the source tarball) is the only
sensible option.  Anything else is intentionally misleading.

In fact, Marek had a more-correct form of this patch in
https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#u
which seems to be waiting on you to reply.

Please, along with Marek and Anthony, figure out what a v2 should look
like, which applies to the whole tree and does not trim the xen/ part of
the path from the hypervisor.

Oleksii, please track this for 4.21.  Build reproducibility is not an
optional exercise these days, and given multiple downstreams depending
on it, it needs fixing for once and for all in upstream.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 17:00:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 17:00:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108812.1458817 (Exim 4.92)
	(envelope-from )
	id 1utqql-0007xu-RR; Wed, 03 Sep 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 1108812.1458817; Wed, 03 Sep 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 1utqql-0007xn-OW; Wed, 03 Sep 2025 17:00:47 +0000
Received: by outflank-mailman (input) for mailman id 1108812;
 Wed, 03 Sep 2025 17:00:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1utqqk-0007xh-29
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 17:00:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1utqqj-004gM4-0I;
 Wed, 03 Sep 2025 17:00:45 +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 1utqqj-00EfpY-01;
 Wed, 03 Sep 2025 17:00: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=iEeNnU+R5bAInwKCWmP6SzRyhcG+xOojmDNTmaPqRLI=; b=5d1fbF8ZR41KkRyM5TWinR5xR2
	2G1lVw/viUnvdYuA41BSmEh67eWrpuDX+N3C4aLTlk/Jh2+1SEuLpbok7T18dbZTpxEOO8RZHCVkl
	bWYXDFvSP+0i+JRoBbrGnm9910lVZRh6Ey4kQflBWIJS556EDnmT9fVC0neSL9wOpkFo=;
Date: Wed, 3 Sep 2025 19:00:42 +0200
From: Anthony PERARD 
To: Jahan Murudi 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD 
Subject: Re: [PATCH v4 2/4] xentop: add pcpu implementation with proper error
 handling
Message-ID: 
References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com>
 <20250903102323.2553142-3-jahan.murudi.zg@renesas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250903102323.2553142-3-jahan.murudi.zg@renesas.com>

On Wed, Sep 03, 2025 at 03:53:21PM +0530, Jahan Murudi wrote:
> diff --git a/tools/xentop/pcpu.c b/tools/xentop/pcpu.c
> new file mode 100644
> index 0000000000..cdb4cb2131
> --- /dev/null
> +++ b/tools/xentop/pcpu.c
[..]
> +/* Accessor functions for xentop.c */
> +int get_pcpu_count(void)
> +{
> +    return allocated_pcpus;
> +}
> +
> +float get_pcpu_usage(int cpu_index)

You could use `size_t` instead of `int` for the `cpu_index`, and then,
no need to check for negatives. `allocated_pcpus` could also be `size_t`
or `unsigned int`, since "0" mean not available, we don't need "-1" or
other negative numbers.

> +{
> +    if (!pcpu_stats || cpu_index < 0 || cpu_index >= allocated_pcpus) {
> +        return 0.0;
> +    }
> +    return pcpu_stats[cpu_index].usage_pct;
> +}

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 17:07:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 17:07:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108822.1458826 (Exim 4.92)
	(envelope-from )
	id 1utqwr-0000Al-ED; Wed, 03 Sep 2025 17:07:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108822.1458826; Wed, 03 Sep 2025 17: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 1utqwr-0000Ae-Bc; Wed, 03 Sep 2025 17:07:05 +0000
Received: by outflank-mailman (input) for mailman id 1108822;
 Wed, 03 Sep 2025 17:07:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1utqwp-0000AX-Jq
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 17:07:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1utqwo-004gSd-2c;
 Wed, 03 Sep 2025 17:07:03 +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 1utqwo-00Eg3l-2P;
 Wed, 03 Sep 2025 17:07: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" 
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=gd0Rwck+1TCqFQ/mGpsrNnAR3p3MybsEV3uO/PKxq/4=; b=lEEeQ/0TZWGXTfb4IGKB79CmLB
	NcaKrg9GDQ7BWZixG6Z5thLhw3wisuydkq9/6yQ4dPxpJ645ZK+bCLSotpuy351RsC/mhQIYmFNf2
	BaVAY1CIEr0ML5fIegWZ7P+wZ/wlwqCAtR5N7bFu3lE/Bowmje126WeEumED+QE39GMM=;
Date: Wed, 3 Sep 2025 19:07:00 +0200
From: Anthony PERARD 
To: Jahan Murudi 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD 
Subject: Re: [PATCH v4 0/4]  xentop: add physical CPU usage support
Message-ID: 
References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Wed, Sep 03, 2025 at 06:06:01PM +0200, Anthony PERARD wrote:
> Hi Jahan,
> 
> On Wed, Sep 03, 2025 at 03:53:19PM +0530, Jahan Murudi wrote:
> > This is v4 of the patch series to add physical CPU monitoring to xentop.
> > 
> > Changes since v3:
> > -   Split the single large patch into a logical series of 3 smaller patches
> >     for easier review.
> 
> The single patch in v3 was fine to review. It didn't really need to be
> cut into several patches. Having one file change per patch is certainly
> the worse possible way to cut one patch into several.
> 
> It might have been possible to separate into several patch in another
> way, but it's a bit too late for that, there's already been several
> reviews. What I like to do when I review a patch series, is to look at
> the difference since the last review I gave, tools like
> `git range-diff` and https://patchew.org/Xen/ can help with that.
> 
> Anyway, squashing back all the patch is the way to go I think.
> 
> I'll have a look at the changes.

So the code looks good, but only if it is a single patch like on v3.
Would you be fine if I merge the change, but squash all patch of v4
together and take the patch description from v3? (or the patch
description of the last patch with "integrate" replace by "introduce".)

If I do the squashing, I'll just ignore the remark to use "unsigned int"
instead of "int".

With all patch squash together, more or less: Reviewed-by: Anthony
PERARD 

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 18:01:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 18:01:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108866.1458841 (Exim 4.92)
	(envelope-from )
	id 1utrnZ-0007Vy-BR; Wed, 03 Sep 2025 18:01:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108866.1458841; Wed, 03 Sep 2025 18: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 1utrnZ-0007Vr-8l; Wed, 03 Sep 2025 18:01:33 +0000
Received: by outflank-mailman (input) for mailman id 1108866;
 Wed, 03 Sep 2025 18:01: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 1utrnY-0007Uy-1A
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 18:01:32 +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 00f1febc-88f0-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 20:01:25 +0200 (CEST)
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com (2603:1096:604:2d7::7)
 by TYCPR01MB10068.jpnprd01.prod.outlook.com (2603:1096:400:1e9::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Wed, 3 Sep
 2025 18:01:17 +0000
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1]) by OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1%5]) with mapi id 15.20.9094.015; Wed, 3 Sep 2025
 18:01: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: 00f1febc-88f0-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a99O0zeIa6R2KcrQggsIUSVylnziOZ7KeDdmmtHUItn3PN7p9wCB4i2aPZfsYjzILTIKMJ+7j3GQae/dtC4L62ttjGf5w4hFow2sfP68ZWx1/Pkuwu3ZmWdrjKvnOB1EiqnAzRVMfP1AsaV6ztxw0g79k7BzcKyVEW74zAe71fGuvC0XvDI0KAebm1QUaWvWlS84em/wZl7ZTPfajutd4V8LgepQfaQh4kapS5Fjz0h3xTB4KtsgJkG0dCJUmYLbaHkjkl33+grFunRi0cwLI7yM7YCPqVY05mynLgxwxybelTQdvdTRrZMAYO38HQ/cjekJbFSy3PMgYMGsths35g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L8l4gIdEqhE1cmUACxb3kdeS4deI+iS6Qx7kCU94diQ=;
 b=wRly8STEC8ku4PaozAOAQiuPBa0T/o0xNZiv3ZaMgfK5pFBsdcjuAS1b2Z9nAuTHLPo1bm4ldZjI6PXM3VMwCdxL96OtpgoORWciuDZPK09gQYLGQmo4vwfJISM0SI27jgkW8Cbb2KBBvk9NbQh2SSUgPhaZItVfH5/DNKso4AB1ZkWMzUZikEp2Bde69bDdVZ2h+uHxgjo4TC7hVFDefKp/v/EGlgF9lZvNCEFulu4hGJQa37dTrCEYKhpaz2v77XtkyglLLpRo0ySye0JQ77Z1b1IGv0uKSH2eGCAVVJqnsbNqrQugayd3DMSOQb4oTTyOxhaUO+Ytw/7Nq0p5ig==
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=L8l4gIdEqhE1cmUACxb3kdeS4deI+iS6Qx7kCU94diQ=;
 b=GStT71peDdBw/DivR0+8SAcgKX/P3qLNokyfhmBF5rikYm/jQP8hCmsJv/ZbtYnA1MzVNnU1JqQgz1v8I/lU2XOFQxw0R8uvNeXcaWuQl7be7b1KLj4Y4nfT6WDZZiyFALFvEhsphahK86lw4W5/buVF+XEfpQ58h3fFsqNufyI=
From: Jahan Murudi 
To: Anthony PERARD 
CC: "xen-devel@lists.xenproject.org" , Anthony
 PERARD 
Subject: RE: [PATCH v4 0/4]  xentop: add physical CPU usage support
Thread-Topic: [PATCH v4 0/4]  xentop: add physical CPU usage support
Thread-Index: AQHcHLzc0wf0/CGB+EiRtdeisPpMILSBn8yAgAARDACAAA3CgA==
Date: Wed, 3 Sep 2025 18:01:14 +0000
Message-ID:
 
References: <20250903102323.2553142-1-jahan.murudi.zg@renesas.com>
  
In-Reply-To: 
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_|TYCPR01MB10068:EE_
x-ms-office365-filtering-correlation-id: 31d6c3b2-413f-4e5b-0e47-08ddeb13dfb6
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:
 =?us-ascii?Q?GDQdySSdjDSCa2BW0JGOa/GxAIbD+hY42IHQF+X4X1G5ofuEsvJqNIYBtss9?=
 =?us-ascii?Q?O/MhYJHD36EGO0Syq2+gQP0fNpUXsWbcoyW9hbexsXmwscnvodhKkXvXgrHY?=
 =?us-ascii?Q?OzSSe5qMFQU+9Rf2t7bY76RAJj3I4ODsJFkHRq0429hdBvEUp40Scycx2kxY?=
 =?us-ascii?Q?e83zQURNMo5lFujlG7X1nxkU0Xd+ELLr1Hff9eViGe811JRcfNfKcRNjXY0k?=
 =?us-ascii?Q?9i5Ubd8MswcIDM8kZXSqFkTCa0+UebtGQ9SxruQIsuqgjR/2Azj8F+VvCST0?=
 =?us-ascii?Q?onSjfZuTED9ZxpOlBIaNhUvBxcWSSRMrTVmAN+unaRRfFS0NjJaxbJVU97ba?=
 =?us-ascii?Q?SV1kA4jtKETBW+iecYYSEZKCKISWAUlLDp1qFf/5tbboYWcD61UdQ0U08gMb?=
 =?us-ascii?Q?fB9nWib59tLkrHAAz6ce+xo1z74VBg0Aov3s2d6EdItIlkXnGwMWuzD7xGWY?=
 =?us-ascii?Q?mmev9Qm0WU2IgpkkxFYcYw1T42l6kE703lC7eFn3EgKGVxLrG3Q6TbM+Lmq9?=
 =?us-ascii?Q?RdShs4hedXISwMThiVQ5Tfaf4FbtED5YVSf1znowadXKgCO9f7Q/xXCvZDl0?=
 =?us-ascii?Q?kzTla599sXdAKW7JhJm5kTJXOhkjTnbVaDUA1HGd5Kr3B2cUuhZx4ji5YoA8?=
 =?us-ascii?Q?blMlfzK9tnYuBM2vOf2psusRfJeUDueslke0nf/ubvzn8y3bwEZ7HLa3E5JT?=
 =?us-ascii?Q?epK0/EZ3ia6txts3w1q7pUCwB4xF88p9Urezh1r8RrCccAMaWpwIDmVoULra?=
 =?us-ascii?Q?13Z/g5wq0qJKfiHN/swFXWvg98kXG36D/7UJRn//q1jyEbSFZJKrYdyU9BqU?=
 =?us-ascii?Q?40IvrG6cUXhgvWNVD+k9dAdEPeeGQMaaYmn9qClqHd6ZfsnIJhK7KscL1ahr?=
 =?us-ascii?Q?Qe56vCjz5dG9twxUsxOxkbskGHhguWa5SU/bpvkyOE8bfvihsG1jKe32enKd?=
 =?us-ascii?Q?Qtqo+V32tmMvzBfCgkJe2c0aUqM/Ug35ekQfM5Gclz+mQjU4P9TLGAexkhn3?=
 =?us-ascii?Q?1vyRMJdjN9YGg+DfnIdj9ffhy0IDkfEdBDXyYx9TLSbaU1t5p7cFVvaKV3Cj?=
 =?us-ascii?Q?Eidkw/Rk4p+hcFYSApSfNVXRMQGoTi+CIq0LQcqp7pFN21qsrBQhgKSFMu8E?=
 =?us-ascii?Q?VVNpVHQDju5WMt9KNfV/jJlo1PRGzE+T8NI5m4qRy2hIartehm774Yy8moM6?=
 =?us-ascii?Q?wnRB9hiVLBYNe4r7Y+7bPD+QvVrYLe2+z+xn23pjg3gqTvERToQVtOnA1glG?=
 =?us-ascii?Q?ub5Fh+AEyjSOO+G6W+axttQToL+loudllt4A+xifq/sWrGrv+/E8vhGMr5gk?=
 =?us-ascii?Q?AjlmuaIcsPPrlp/k++0K63L8llSyhts+4FrtFyriPyoykYSgsP7q7nJX8aTl?=
 =?us-ascii?Q?74tbX/D1EkKyUjkPv2xc/5kE7pGUxmd1sNQxZegfobEe8rMSI7ZxUOrwnQRS?=
 =?us-ascii?Q?ikfrz9/mAtqJ82Rqf/bXo+jpDaGG/zLPcU55WQJkc9WLVYyy38gP0w=3D=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:
 =?us-ascii?Q?jKIBsEMjjd8Pa4wFF0PtNXJVKotI6kgrsPAO3jZRKsK+DGaXFP9+XDmft+fU?=
 =?us-ascii?Q?QHDdLPrQ7D5sCCLbXltfgVgH5RgxKZPteQby/vk7ICvg69mNGwlLweY6u7o6?=
 =?us-ascii?Q?QUwrzR8Os2EUUOKYoEZj4ctiKWgoc7QWEf0+kWh2Qkjy40M20axGYycBGVle?=
 =?us-ascii?Q?QSbdqAdh7842S1GllmtdfCHWdtIF8sNSNwEU17ctVPM6b4mQAf5VIx0IksLs?=
 =?us-ascii?Q?rih/bGDDmQIx+zA3y5272DAabWfZJ4mGjrunVsZ9GuO5X6b6u1esCkxcjq1k?=
 =?us-ascii?Q?yqSuDmaknd6vWtrSQaOhY3zYVrOmesq7xidsuM9wjD53c5C/ybyiTnGTs6pu?=
 =?us-ascii?Q?yXS4Nv/IHuf5YQf1h/tPS92QcsNsT8NXWLH3orZ8zzSnzWw9eaiMBfEuJATz?=
 =?us-ascii?Q?N4Dum93SBN/QIEQ4IgR/KNbm+CXmS9pdiTxZBSmqUc+TPOqxV23CUOKfm6fg?=
 =?us-ascii?Q?boLXf++cM3xBDUuNdFqF08mIpv/zbLD9cH0Xl5Y+Ef87KsyI3IP4dqvT0R93?=
 =?us-ascii?Q?nGQS/VJMThaETamzlzrhRh9v09GY3WbtnMTHuXnDhzJQQ40cKyIo61PaXCb9?=
 =?us-ascii?Q?GxyK1vW3L4M+S4VvAvpMX6tMJxZAjNCcJ+nndVFpyFwZWemScTrT4yM2gsNG?=
 =?us-ascii?Q?7l8gOFUTMgTRzOFDnSPCE47q4Gk/CtuaYZ5aTg0misJZvejiEBeoIMxLgThN?=
 =?us-ascii?Q?uDQdqBMQepUj4CnKS/XYRQZXYOlE3CDl+ixyMB/AWEbGfYP/wb2uR6wsSd+R?=
 =?us-ascii?Q?gNO1kp5Wk27KSHhufiawnAvgWctFE6O1T6dC0og42+vwAOWSwRNLC7wYJ3zW?=
 =?us-ascii?Q?r5hBB9iPx9XjrcEcjUpi3tD+WVgwNWbUhc66QeCEg+gWaHpQI+e/sYuvnAw8?=
 =?us-ascii?Q?actunGrb6HIGqQMrLOB4sm+RPTS/vuyGHFoL8lvQfOwCIRUxyoQHQ+1a6yZ0?=
 =?us-ascii?Q?+JRl4sKrES5Q3ufCtkbeHK1cIoK6tvJ+ewimEal6F3vBzaRBk1itj+/Wy/Q1?=
 =?us-ascii?Q?8pyeixhgWEnhjO8Ucjj9L65qSR62RUedLrrMnMJTcid3YVC0SUhX8oX1B4MH?=
 =?us-ascii?Q?z/EtoahbBiuqUXqv5X44/aW1Eep7P7hp14Qs7AKmW5feg2bVlM9q7IkDYGa7?=
 =?us-ascii?Q?Dh2gX4RSshI84rWcSFYsfxjLQ44BB19xC8xr2b4UmI6FydfdozAlTblq8WVa?=
 =?us-ascii?Q?g3cto2/DEh8YJm2GgmAFvWXzJAvPpYYbkaoFtfCGzuRWr+/pkG/kPwyqD6x8?=
 =?us-ascii?Q?n6OVb/b51a8UXQOrzAE6yc2ZgFOsnWsakyK6QP2HHoN1kSbrnVtBUucAlAlZ?=
 =?us-ascii?Q?FUiaGTv/jnGrWpN73Xemxnakj+NijSSPYlObNJdX7clp6v+HDEClaIgJC9Ra?=
 =?us-ascii?Q?gnWwtrtmHlafxRCsJJgun+0dTru/3p+rpF0mh0e6VgN/QaXjcsPtkJ1hz85d?=
 =?us-ascii?Q?N5pkZ1ho315fxdFGwVxOtDcTSzdZiEgnIXXc1torRbrSveNjZBs6qe28Xogl?=
 =?us-ascii?Q?PZjWqUWdKY7h7ZC0moQcXsIim4iLZNj/FLA5D4kd9BuTcNfSWZrNyfsOptGG?=
 =?us-ascii?Q?Fpj3TDqmL0bY9bKUdDfWJvHLQW9Vcp5VJXxcTQIg?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 31d6c3b2-413f-4e5b-0e47-08ddeb13dfb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 18:01:14.6475
 (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: e1AbNN2a1tMRpfx7L55HQyYTy4I6/GerDBAZFvpsCl+sgqPh8/8sOpato4MNvOgDumy8w+l/z+A1a8P7WSLbShG0MQE7vw62uIiYP9Bhz8o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB10068


Hi Anthony,

>> Anyway, squashing back all the patch is the way to go I think.
>>=20
>> I'll have a look at the changes.

> So the code looks good, but only if it is a single patch like on v3.
> Would you be fine if I merge the change, but squash all patch of v4 toget=
her and take the patch description from v3? (or the patch description of th=
e last patch with "integrate" replace by "introduce".)

> If I do the squashing, I'll just ignore the remark to use "unsigned int"
> instead of "int".

> With all patch squash together, more or less: Reviewed-by: Anthony PERARD=
 

Thank you for the review and feedback.
I completely understand. Please feel free to squash the v4 series back into=
 a single patch for merging, using the patch description from v3 as you sug=
gested.

Thanks again for your time and guidance.

Best regards,
Jahan


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 18:17:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 18:17:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108880.1458851 (Exim 4.92)
	(envelope-from )
	id 1uts3J-0000oS-Ok; Wed, 03 Sep 2025 18:17:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108880.1458851; Wed, 03 Sep 2025 18:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uts3J-0000oL-Lz; Wed, 03 Sep 2025 18:17:49 +0000
Received: by outflank-mailman (input) for mailman id 1108880;
 Wed, 03 Sep 2025 18:17: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 1uts3I-0000oF-MG
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 18:17:48 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20620.outbound.protection.outlook.com
 [2a01:111:f403:2417::620])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49cb575e-88f2-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 20:17:46 +0200 (CEST)
Received: from BY3PR05CA0046.namprd05.prod.outlook.com (2603:10b6:a03:39b::21)
 by SA1PR12MB8163.namprd12.prod.outlook.com (2603:10b6:806:332::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.29; Wed, 3 Sep
 2025 18:17:42 +0000
Received: from MWH0EPF000989E9.namprd02.prod.outlook.com
 (2603:10b6:a03:39b:cafe::b9) by BY3PR05CA0046.outlook.office365.com
 (2603:10b6:a03:39b::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.6 via Frontend Transport; Wed, 3
 Sep 2025 18:17:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000989E9.mail.protection.outlook.com (10.167.241.136) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9094.14 via Frontend Transport; Wed, 3 Sep 2025 18:17:41 +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, 3 Sep
 2025 13:17: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; Wed, 3 Sep
 2025 13:17:40 -0500
Received: from [172.31.134.167] (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, 3 Sep 2025 13:17: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: 49cb575e-88f2-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=s6Nhg/ZPY0ZXFZosz4rJzzM7bquv3KbfbTzpuzJK93tVw1PAUKbKGSQettrTsk/oMi2jPn9ocDjvpCGOoVMs8MXCpM5pG+SLB1m9ABMDO2vqvcwq08Pw5aLO3/dz3bEOWRygOByZd/Q+mq1OTIjdXIqesZ8Q7GYy1w2CFCAWM7C60XTOyWjAUjT+j1gJncGGIjWcffJhHMocw/FKhBl5uZjGSl63LNNZuXhCvxxVRT8gzu+K0waah8TiCz8pPa/aGkHFbVvFNiPy3UU2z5K8oy3s1CoweZRZeNQLQ6cenp36K5X1L5ZsjhUrJfxnK7RdXXMGLyQRkZm1zPwi1PqYcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LVR4KN/qTSmiKDA1hftFzD4YihUfYSCWsMeEvYvgLRQ=;
 b=xf5vzeVpEblkdZtRf5jMG0j8xBOQLvJNlWVkWe7e0pStK9b02B5vRqGSnyz475E1ujU2O7BhNq4hWTgJ0g6fNT4EnFOpjmBVZplLBpXRvRAP4IU4LsofaDKGdnZBipTiIsdAx+IUfo7aXm8zWJtje1dHsjF6MPMTWyl+q+f3WJkD5UNzKF8zhDwr0ckqL40X1cHmgaAKd7XYx7CBJ2shsgL3dOjM7Gg51ahmuuiTaHjUegaP0kfq8JmldES6B7AIs644nJqjBT+t/gzzHHLt6GfKLMChtpNTt8r4WqugBhq07PdOxYIZdrCY6oTxEXOw90HTLZLPZ04jLcSTghdMjg==
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=LVR4KN/qTSmiKDA1hftFzD4YihUfYSCWsMeEvYvgLRQ=;
 b=WNsvp8IFfMuXo3dYG4QotasYm71501A0mlhCVhfl+AHa9tCYGf/zhFSz2/tS02iu2N4NsZNbggWKRKX4mk9cKRAzgwO1keUAzb1Bq4KsJDwDDQdUotRyMRkHiYhoR0n7abLdF9IXnKs07Y8KxmPadBmoosbdyXwDcfoL1Gi8iUA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: <8ab89125-4693-4d9a-b9a3-b8ab38b1908f@amd.com>
Date: Wed, 3 Sep 2025 14:17:39 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: "Penny, Zheng" , Jan Beulich 
CC: "Huang, Ray" , Anthony PERARD
	, Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	"xen-devel@lists.xenproject.org" 
References: <20250828100601.1777197-1-Penny.Zheng@amd.com>
 
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000989E9:EE_|SA1PR12MB8163:EE_
X-MS-Office365-Filtering-Correlation-Id: c5fb2cd8-1298-4887-91e5-08ddeb162c07
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VTNzcG50TEJCcHFFNTdpMlVlZGxUUzdWUEx0NEMwY3M0eS9oMzRJeS83QjUw?=
 =?utf-8?B?RkI0M2F3clNMS0J3d3IxN205NlBQb1BRaEg0VFZPaGp4Slp5NU5hNHppQUJu?=
 =?utf-8?B?c0N1TjRoTU54Vyt5Yk5XaGNTUDJiNVZWckZOZy8rTVBiQU9HMlJmMDB4b0VJ?=
 =?utf-8?B?N2U1am82bDlUUVcvOU5salhSS0l4WWErYnBLZ0MwS2RGZTU4Ni9vQnR4VW1r?=
 =?utf-8?B?K2NMdUNqL0FBZkw0QzYrd3ZPa0JPdG9QbDAzWGRocVdSRENwQnVmWGVNZzRX?=
 =?utf-8?B?ZGFjT1JSWHEwaUZiWElwR1hGdFE4RkV4OGtXOUM5a3dIVDNRU0d5Vi8xeHd5?=
 =?utf-8?B?cW5pY3V0MzI1aGpxTUtSMStEcUhjbk1hTGdDRDVwV1FXcnN1SEJMdElGNi9B?=
 =?utf-8?B?SlZtRjBRQUJYdE5EMlhubDlGVE16UzNzaXk5ajlFakU4bFViSDQrVHFCOFdi?=
 =?utf-8?B?c1NnUG1ETmFDck9WUSt4MHdReEgvc0Fab1JtQ2tCRTRDWHltUkFvSllvdjJC?=
 =?utf-8?B?TG9iYVo5RU5HUHEreGpGNkRKc0VRa2UxL0NsenIyd3dOWnpkcFpHN3hmYktG?=
 =?utf-8?B?cmFuWUVoVlI4dDlySHU5b1pLZkxCTGQxcDNGNWpqUmZPOUR2NFI2VDlXSU9C?=
 =?utf-8?B?RFNBZnJwTlBJcU4rbjRzZ0w2L1BIellNczVHeldwTzAwTW5GOEdudUl5anFF?=
 =?utf-8?B?VDd2aGFKNkhSUU11MituN09FOWM1TC9DbGlzejAzbm1aRDVpUjdIdUx0UDVX?=
 =?utf-8?B?VWRRdUtnem5KVnBLWDkzNTJ3UzNKeDllcDBQVmRGQXdkZTFUODF4MW81dDBj?=
 =?utf-8?B?cjNxRHozNWh2cExNWEtYVUtZRHd2a0VEVUJXYnpQenFRVDdlL3JLL2FzU1JB?=
 =?utf-8?B?NTNrUy91M2w3VEIrdVRIWkY4eU1GNjBOaDBPM01QdXJ6bFpSMGJtQmhYemFY?=
 =?utf-8?B?N29mQWw5eDN0MHBNUnpObklWbFFTTDNWekFNU0N4ekxpNzFNb3c2TERaUEFK?=
 =?utf-8?B?SFZMeGl1SHpiaERCcXFVdEk1STQrdDdTTjF2c0JHMnhOdm5LL1pKTWR2TEJC?=
 =?utf-8?B?OWZ6aVAzZVdPYWZLSlFTWERYU0JsUTJaZjB6aXBPd1pwaVNONUFvaVVzYURm?=
 =?utf-8?B?MzVsd1BNRzlLb0tKOGtLcUdNNWFWSFZydFlIMEc3RzkzWFdvczdwa1dPdkNt?=
 =?utf-8?B?a2Z5OHN5L2tCc3RPSEdYbFhyUVZud0tDcGluMzgxSDdZS3ZMU0FWVldwZkNL?=
 =?utf-8?B?bDd6c2VkZ1IrbjdxUkpKSmdUS2xCZytucWp2ZmpXQW1QeWR0Z1duOGxWYW9n?=
 =?utf-8?B?V3hBS1VzaUd6QTJlVEJFQSt2aGpsMWhEV2ZrWmgzdmhJYUY2WVdmUzUxNEYr?=
 =?utf-8?B?c0pheU0wbjZINGswd2d1YkxuRjFlMEFUM2QyRDVCeGVNSEVrUnVzb3BCd2JD?=
 =?utf-8?B?cVNBSDVBbWVzRkxOUk5FM1JuS0ZjU21ubUtzdVRlaUdmZmNDdWxBaW05UElJ?=
 =?utf-8?B?Q1FBRk1mQlRnaXVzZ0FLV1c0VjVTWmxWSWJnZTJSVTYzaG1HWHlqM3BSSlNo?=
 =?utf-8?B?YitpL3FrU3R0V3ZoT3B2TXRPcGhEaHgzUzByWkZQZEl4d1RueXJVZyt5cVcy?=
 =?utf-8?B?NURiblpOTUhQUGdJVEtlRkdpVWtKcjBiZ0NldjdoVnNzVDZ6b1pHT1NRd29S?=
 =?utf-8?B?U25aUjEvbmtVUVJybmNkQTN6cUJxL2xrRURPaGExWGhtdnEyTUh1QS9IaEJ6?=
 =?utf-8?B?Q0ZhaWtiUUNwdk04UEpOQjNvcU1iMEdxS0grTHY5VnAzaDcwVitDZEVUUi9L?=
 =?utf-8?B?TFVPWTNJUUFWV0pyT05lSEVTQXlyTHBBcHFGZGF6RWdjMzE0UVhvT1piWGhr?=
 =?utf-8?B?SzIwalQyOHkyajRodGFFMWVES2VyUjRGWVgzOU13ckxtUGJDWTd0Y21HWEJw?=
 =?utf-8?B?dFBxVlpXUEV5Zmw0TktXY2g1cVBRZG1LRDF1a1VwaE1GVVdzQXpLU3l3V0FJ?=
 =?utf-8?B?TWNHaFgxcE5GR3FZSEhqaHJjdHhVK3FiclUvaFhESXZOLzRva0tjSUtYN3NW?=
 =?utf-8?Q?b7RDBN?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2025 18:17:41.5638
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c5fb2cd8-1298-4887-91e5-08ddeb162c07
X-MS-Exchange-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:
	MWH0EPF000989E9.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8163

On 2025-09-02 23:14, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, August 28, 2025 7:07 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Anthony PERARD
>> ; Andrew Cooper ;
>> Roger Pau Monné ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
>> xen_sysctl_pm_op for amd-cppc driver
>>
>> On 28.08.2025 12:06, Penny Zheng wrote:
>>> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
>> *op)
>>>       else
>>>           strlcpy(op->u.get_para.scaling_driver, "Unknown",
>>> CPUFREQ_NAME_LEN);
>>>
>>> +    /*
>>> +     * In CPPC active mode, we are borrowing governor field to indicate
>>> +     * policy info.
>>> +     */
>>> +    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);
>>
>> Isn't pulling this ...
>>
>>>       if ( !cpufreq_is_governorless(op->cpuid) )
>>>       {
>>>           if ( !(scaling_available_governors =
>>
>> ... out of this if()'s body going to affect HWP? It's not clear to me whether that would
>> be entirely benign.
>>
> 
> HWP has its own unique "hwp" governor. So, imo, it may not affect.

get_hwp_para() writes into the same union:
op->u.get_para.u.cppc_para
op->u.get_para.u.s.scaling_governor

Which is why I avoided it for hwp.

I guess writing scaling_governor first and then overwriting it still 
ends up with the same data in cppc_para.  Seems a little messy though.

Penny, I'm confused by this comment:
+    /*
+     * In CPPC active mode, we are borrowing governor field to indicate
+     * policy info.
+     */

You have CPPC active and passive modes - which uses a governor and which 
uses get_cppc?

It seems like only writing the scaling governor inside
if ( !cpufreq_is_governorless )

should be correct since it's using the union.  Am I missing something?

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 18:40:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 18:40:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108915.1458860 (Exim 4.92)
	(envelope-from )
	id 1utsOt-0004ZQ-68; Wed, 03 Sep 2025 18:40:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108915.1458860; Wed, 03 Sep 2025 18:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utsOt-0004ZJ-3G; Wed, 03 Sep 2025 18:40:07 +0000
Received: by outflank-mailman (input) for mailman id 1108915;
 Wed, 03 Sep 2025 18:40: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 1utsOs-0004Xv-F9
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 18:40:06 +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 679836f3-88f5-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 20:40:03 +0200 (CEST)
Received: from AS4PR03MB8338.eurprd03.prod.outlook.com (2603:10a6:20b:506::15)
 by VI0PR03MB10904.eurprd03.prod.outlook.com (2603:10a6:800:269::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 18:40:01 +0000
Received: from AS4PR03MB8338.eurprd03.prod.outlook.com
 ([fe80::ac40:2d43:5ea:11fe]) by AS4PR03MB8338.eurprd03.prod.outlook.com
 ([fe80::ac40:2d43:5ea:11fe%5]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 18:40: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: 679836f3-88f5-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=X6knr5LLfF3PvWqPjIeOJ3tkKFTSl6PPJEuUxHolzarE/mKHyo2jlFnbwRZDYvqHlN36sd4C9S4nRdpo+6jCdSKw3k3Uw7Vi8kRzwUZERA3AzN1kK61P+LsRjBvEw5RR0PADNf5IWKRHA7P91iqtoVhGgEKvJ2n6SK6ivK26PtNyJkSZwtvpPUXGTLMtME4/KEMqaJJCXTPATsAg4pViMcoCXsyNREUu3Vz3KMwBTSsayjIQkK4oWk31B/jd6V1eXF6GFkdNVCAh/xqdm7Zl6eCKC9zvYLSzX7RTNhfmgx2H+4eGhHQm3LRPsunvB6CpapiIObRWuVs61ee/NVwIfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kG/N3T5kiz281dvzKrsKM6UpDLoSc5gNyQOn0fcgKLs=;
 b=h7lr3rfzG0XwSfW32VUqj0ZtxzLCmz/SRCALY+qvbZaQ8XYcWBHW7HwTOBt2jfuHn+zj8d3tHrSy3kJry6K0hk+09p35/lZV8c6E2fI9P+GIq2720o/0MeDdz7tuWx0w+lrxuEH149k/Db7IKMSE3oyf3bkxLuw2fxSGfZ4zQddSjcwcK+6qN5ySwCX9VH/Lx/ggkCCrTAgUqiZU6bcahSpOZSdrajomNfceC+tWzy2mAdRAvHbJdFVPURTntRHWRJW0+zzxaTwpXBXMOtgEk18+vn7smXLCmNVpvonPMFC1v3ORwplsuOs4a1q9COdYQLCpBn/qOEQKhBAq1mkmiw==
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=kG/N3T5kiz281dvzKrsKM6UpDLoSc5gNyQOn0fcgKLs=;
 b=k39HvhpiuJIEZ8jN/9/npyUjSLRIRCv5IsvQEx+to5QE6h41dAXRspYpdPm9+nuJKqKk2svNz4AVLvxg6ncHEq6X4gDP3uqXxdm1P8SKeqZz7UFgw58AVpuyXC5/SGKi1gwCjLdEqzuQyUCTJi9Ny94wa7QdoYHL9vkcB9GWjptKxq2POJQj23CXBaEcLKexBHz49vIXxr9gZbnYV5Ua68lncmhAJ/DhlynyjqpaEzRUePW4kJ/uOt/dqOnhiSqQtt93EXROoLoG/YbHIXuaCd/pljqgs3r2kK/ooedWrdClPaMCZczJCWRIw9m9x/CDoOKoBOVN3RgelVn4/4Mh8A==
From: Dmytro Firsov 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Firsov , Bertrand Marquis
	, Rahul Singh , Stefano
 Stabellini , Julien Grall , Michal
 Orzel , Volodymyr Babchuk ,
	Julien Grall , Mykola Kvach 
Subject: [PATCH v2] xen/arm: smmuv3: Add cache maintenance for non-coherent
 SMMU queues
Thread-Topic: [PATCH v2] xen/arm: smmuv3: Add cache maintenance for
 non-coherent SMMU queues
Thread-Index: AQHcHQIn+C0aN53q3kCiWfPloZq/2A==
Date: Wed, 3 Sep 2025 18:40:00 +0000
Message-ID:
 <6f4552aab3748ea3ad96d45affb8ce9146b557a4.1756922110.git.dmytro_firsov@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS4PR03MB8338:EE_|VI0PR03MB10904:EE_
x-ms-office365-filtering-correlation-id: c1817b27-ca9d-48a2-76b5-08ddeb194a40
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?bclBucPbHYFsNElZ7pPEU31f29q6j6Z4JLN6fw57roSVkatEhpS6U+V2dV?=
 =?iso-8859-1?Q?aKKtlEfesioz2cYXKBfVCyHQEdnRmZ2+huHGXpwAubdbxhPivrXLiFlIZr?=
 =?iso-8859-1?Q?+XhiXXbyg0NVQ3teCoENoCfgloXjRa+XtpW4V6N5KQ+epkiOV3AxrFdFt1?=
 =?iso-8859-1?Q?HAByYKHqy2HxrMMaQYanZJDUKszM2KTzAOQIa0sfFpTsIQcX9zRztIodgX?=
 =?iso-8859-1?Q?lg/laLDqgjYK3ppAxLNrE9wZQkMoLDMCn6Mg0rv6Cm72Bl8WLrWDy2bh0R?=
 =?iso-8859-1?Q?KA/Xl5I6lBlj2Ztn+ltDotXXUeooiAE2Qf/Vpd/Bdxexsf1o0hmVCsgWpO?=
 =?iso-8859-1?Q?C1uM2PtTCxUpWmFUQDjFwZrIDsREBZVvS/4TTysC4/HlbYoawLUGDvBCO5?=
 =?iso-8859-1?Q?LXnpJAPSCy/hgNHI4yfj0cumskq+DSQABxekE1NDzgtMvcdQFhIgAXr+2X?=
 =?iso-8859-1?Q?tu0pk/2g388FLdpsefKg5k3LyPxbnFCqIqfAth08me2mAUxOix8YgmuH13?=
 =?iso-8859-1?Q?ODdihi4+PAtNij5PfaU9uCkGrvU0uwQvQWMouvQFe9hg/zrNMbEVRg9aty?=
 =?iso-8859-1?Q?oFZP/FEIVIfmO29MEu1a8jkDzDo0UOnSBrGNa9WmFQMijkZl0ilxVOcx8h?=
 =?iso-8859-1?Q?aYSnSFQg084wZIb1wRBhE7clIHrTry+C9YRJseoLtyVKr0gaEdOjZuSTwl?=
 =?iso-8859-1?Q?yGZkSS0O3N+oyRMm/8SYCEgmZNfYvyx1qv7/Ax60qR0XanVEeIHuWyDHHl?=
 =?iso-8859-1?Q?O1gDHVHIvNP6qhQaZ7ch0hEbQyFOENgUBoxPnK996FG4LdL3dHDr3HDWjZ?=
 =?iso-8859-1?Q?g2so+fYuY66RLOdeDfNym5FVYMG9uwosZOq7axtWOGS759BXw+Xhy6ebsm?=
 =?iso-8859-1?Q?+MDm5HXSQOsJjpZ3hT00QhOUVGzMwqJ2bUvh1YetedGO2duJnJzoTwzPAH?=
 =?iso-8859-1?Q?WA49atCPNYLmVlTjTmwpGMAPQNGwvPDmBPGPQszLn9axWS/66MBfH/7uVm?=
 =?iso-8859-1?Q?e6AZKDULXcvT9YlU+POOzWjuD7Ouf3NxCvIt2dngamI6Z8ybRSRiySq0TA?=
 =?iso-8859-1?Q?tr+rBeBVSXZ5R839s9GO5HhMCRrJq9ClraiHDikxiS7AkZssfRODbHla0Z?=
 =?iso-8859-1?Q?sfJJ166iqp9NEmbP/1Pa1Fp0+Zlp6PPZl0uW8pCZSs2zFf1bnb2l2acbcQ?=
 =?iso-8859-1?Q?hfmnsJXTtCtHpKJ64nSiSZZYB1qU3r8upXrEtUQPK9nF6ww/XaiQihjQUV?=
 =?iso-8859-1?Q?F1zda5qhgEKLOzzE3zzL2wjWQTJkLqlNmF/bpW1oeMyizrD8cd6KhuOIlo?=
 =?iso-8859-1?Q?ltAbcBgpVS4y20dHoTKWhLvf4cYVYx/tsnJxc1UjJgOJDm0TcSpZXmAqpB?=
 =?iso-8859-1?Q?tGknYRffkvj234sxW70tVMOTnr69RhEKvYlJzO0uXfLkaGXe4fJHyMTzd7?=
 =?iso-8859-1?Q?f6MzrBpMddlCIsG5E+M7SPYDJsjYgixkPJbYwCsLg9onpq4Cq16laU8BBT?=
 =?iso-8859-1?Q?CPB6W4lL3HRSfUgtuHAS5lZNHQ8KIha4x7Ew6JBX5xOA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS4PR03MB8338.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?jfo7G0DIsumDyk4yJ5sva9Kp1bziJdZXhViqVEANR3dq6z5sERDm8kgRRZ?=
 =?iso-8859-1?Q?og+eOC2njhGOtLMN4HKHk0CMyknVKmbi0+wuxb74wkVPGOSHD47I44QOHn?=
 =?iso-8859-1?Q?HfUA0kp0b7NR8AbMB3V5hZ5fPCnWLkh+HwIfU4LLChiQC9TkhztkA77uWC?=
 =?iso-8859-1?Q?bZHNuJLv1j3OxzZVys+kZiznhdf3gdmn0dRCB2VWHG0AWjdF/46iQezsK3?=
 =?iso-8859-1?Q?6TF7Rv6R0vw+Zb+Jqklgn3j3q96hLJ4FYdzCLweHbawpZE41NNFJImQPZS?=
 =?iso-8859-1?Q?4Le8XjI/Wn97d607/zzG5hg3p2yjtR8GS4hlkqyImeHW0YjMovjE5Spo08?=
 =?iso-8859-1?Q?mjuQtAgOADT6gvW11VF3BVDyqqS7IYzzrDgHhFPaVsKfF3AqAaVgMUPXlg?=
 =?iso-8859-1?Q?vf5KFQaUaFccRyDr+Hw1dxf6sva3yuGpz/ekFrBA9vh3Jljq+1G+Oym+mm?=
 =?iso-8859-1?Q?f0jRIPvSVL9v6hVzlpHJUhUFsYjgxF6W9Ucm3tISgnt5icuBGVDD5Yik80?=
 =?iso-8859-1?Q?IyqBMSMzzcdFqfaBaT3IvU1hRWZya4v0Xeu8yC4otIfiaro9uJOdUnzFlY?=
 =?iso-8859-1?Q?5/Oof6X3OGv8OkHrYAffEXhsXhWJmlh9oyllVttZTnYdKwhqLRuZqpYr+5?=
 =?iso-8859-1?Q?GQbs1XXrhcMnaRCCi+ZHzrUyQLcsChujKio2dwY6dI5ZlxuiZxmmrhbBzt?=
 =?iso-8859-1?Q?zflwIqaf/56jmMzZL3FScWy3HVhJLHTRE5gLlut3jfIkmL2VEuXM8Qo9Yr?=
 =?iso-8859-1?Q?z0ICpyJ/IaS97OxX42kHxXpz9I79Givzs+VynTXSOdo57lHf+UFN0v8Zbf?=
 =?iso-8859-1?Q?RYE6xitpPdG+NYhuNX52ZWmMbeBDNl23LbHTEPTwtcQo5/OKwZ7yKxoGCq?=
 =?iso-8859-1?Q?QjcaPeM9IcKb3j3KXBuigg6Je1g0QEphB7AUpqM5afbLKFJ8hHBYSJ7NHT?=
 =?iso-8859-1?Q?FraISyJDKKAiVVJc5nXeJlKqsqCUvZ2aVuxJ71gX9SH6MUBLnnLnX42G9o?=
 =?iso-8859-1?Q?puNjmPEIgYWBrFGqoORMwbD0VAllG8JB7hPjjR4wuPs9CPydbhLzXsU6dP?=
 =?iso-8859-1?Q?Mbu5O5dXSLAtI7+bYt36ZAxnZkV4Ic7Wa23b6copduXi4mfcoxgf9484Kp?=
 =?iso-8859-1?Q?VzuN5z1YiJCf+VzEByIYQO3oK6G+PkztlyLQ4/yuyaFXzJypUnNpwqGOmR?=
 =?iso-8859-1?Q?t2KlDXaEIqLXxSsZ60jGkzQVZcDbVz94UYNOBTYme6A7F7revwnXosJGzd?=
 =?iso-8859-1?Q?Axtv67X8LanAipsVyJNqCzgd2nMtRPTtngaD+M/YT+ZRLJeutY7l3u46sw?=
 =?iso-8859-1?Q?UmfNrhL8xZ/ilE3vIhzZeQxBu9RQ8DKZ1K+oVl/iMdbFSiKUctnGKBT/ET?=
 =?iso-8859-1?Q?7WlwEdN3FHa+rvmbDkItQFRIcPArxBhCVOUmHOUBPrItM7NUpLxE9KBgSk?=
 =?iso-8859-1?Q?3/ftVwgKYh3N6CtMhbAu3TnRoqUr1E8MhN0e0sduL68hYphCvfS53ZtV4R?=
 =?iso-8859-1?Q?hqofSwftcys6QSNJVv93NBM7ygBk1EhC0enGGTru0+CC52fXMWxOALC5Il?=
 =?iso-8859-1?Q?d6X4Eo8LPxcIotZCcvvNEqbHlg+l6tGfDQ1lRka0LirpE12MHm2rxfGH0I?=
 =?iso-8859-1?Q?3X/mP4Z28N4qfoJQL2jQG1nEIgX19qB+Q/QVUqN2JYwmDLeEzAVo0vJQ?=
 =?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: AS4PR03MB8338.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c1817b27-ca9d-48a2-76b5-08ddeb194a40
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 18:40:00.8630
 (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: uWQS/VXQ4ZT2MgGQK5p9UXwIEU0vHDdfc+PA4hcsZNe6h+iDbglmfPx57WkO/Q9wkOlRXAeLF8eWK8sWcTFDMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10904

According to the Arm SMMUv3 spec (ARM IHI 0070), a system may have
SMMU(s) that is/are non-coherent to the PE (processing element). In such
cases, memory accesses from the PE should be either non-cached or be
augmented with manual cache maintenance. SMMU cache coherency is reported
by bit 4 (COHACC) of the SMMU_IDR0 register and is already present in the
Xen driver. However, the current implementation is not aware of cache
maintenance for memory that is shared between the PE and non-coherent
SMMUs. It contains dmam_alloc_coherent() function, that is added during
Linux driver porting. But it is actually a wrapper for _xzalloc(), that
returns normal writeback memory (which is OK for coherent SMMUs).

During Xen bring-up on a system with non-coherent SMMUs, the driver did
not work properly - the SMMU was not functional and halted initialization
at the very beginning due to a timeout while waiting for CMD_SYNC
completion:

  (XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout
  (XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout

To properly handle such scenarios, add the non_coherent flag to the
arm_smmu_queue struct. It is initialized using features reported by the
SMMU HW and will be used for triggering cache clean/invalidate operations.
This flag is not queue-specific (it is applicable to the whole SMMU), but
adding it to arm_smmu_queue allows us to not change function signatures
and simplify the patch (smmu->features, which contains the required flag,
are not available in code parts that require cache maintenance).

Signed-off-by: Dmytro Firsov 
Reviewed-by: Julien Grall 
Tested-by: Mykola Kvach 
---
v2:
 - changed comment for non_coherent struct member
 - added Julien's RB
 - added Mykola's TB
---
 xen/drivers/passthrough/arm/smmu-v3.c | 27 +++++++++++++++++++++++----
 xen/drivers/passthrough/arm/smmu-v3.h |  3 +++
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthroug=
h/arm/smmu-v3.c
index bca5866b35..c65c47c038 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -341,10 +341,14 @@ static void queue_write(__le64 *dst, u64 *src, size_t=
 n_dwords)
=20
 static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent)
 {
+	__le64 *q_addr =3D Q_ENT(q, q->llq.prod);
+
 	if (queue_full(&q->llq))
 		return -ENOSPC;
=20
-	queue_write(Q_ENT(q, q->llq.prod), ent, q->ent_dwords);
+	queue_write(q_addr, ent, q->ent_dwords);
+	if (q->non_coherent)
+		clean_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
 	queue_inc_prod(&q->llq);
 	queue_sync_prod_out(q);
 	return 0;
@@ -360,10 +364,15 @@ static void queue_read(u64 *dst, __le64 *src, size_t =
n_dwords)
=20
 static int queue_remove_raw(struct arm_smmu_queue *q, u64 *ent)
 {
+	__le64 *q_addr =3D Q_ENT(q, q->llq.cons);
+
 	if (queue_empty(&q->llq))
 		return -EAGAIN;
=20
-	queue_read(ent, Q_ENT(q, q->llq.cons), q->ent_dwords);
+	if (q->non_coherent)
+		invalidate_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
+
+	queue_read(ent, q_addr, q->ent_dwords);
 	queue_inc_cons(&q->llq);
 	queue_sync_cons_out(q);
 	return 0;
@@ -458,6 +467,7 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_devi=
ce *smmu)
 	struct arm_smmu_queue *q =3D &smmu->cmdq.q;
 	u32 cons =3D readl_relaxed(q->cons_reg);
 	u32 idx =3D FIELD_GET(CMDQ_CONS_ERR, cons);
+	__le64 *q_addr =3D Q_ENT(q, cons);
 	struct arm_smmu_cmdq_ent cmd_sync =3D {
 		.opcode =3D CMDQ_OP_CMD_SYNC,
 	};
@@ -484,11 +494,14 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_de=
vice *smmu)
 		break;
 	}
=20
+	if (q->non_coherent)
+		invalidate_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
+
 	/*
 	 * We may have concurrent producers, so we need to be careful
 	 * not to touch any of the shadow cmdq state.
 	 */
-	queue_read(cmd, Q_ENT(q, cons), q->ent_dwords);
+	queue_read(cmd, q_addr, q->ent_dwords);
 	dev_err(smmu->dev, "skipping command in error state:\n");
 	for (i =3D 0; i < ARRAY_SIZE(cmd); ++i)
 		dev_err(smmu->dev, "\t0x%016llx\n", (unsigned long long)cmd[i]);
@@ -499,7 +512,10 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_dev=
ice *smmu)
 		return;
 	}
=20
-	queue_write(Q_ENT(q, cons), cmd, q->ent_dwords);
+	queue_write(q_addr, cmd, q->ent_dwords);
+
+	if (q->non_coherent)
+		clean_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
 }
=20
 static void arm_smmu_cmdq_insert_cmd(struct arm_smmu_device *smmu, u64 *cm=
d)
@@ -1587,6 +1603,9 @@ static int arm_smmu_init_one_queue(struct arm_smmu_de=
vice *smmu,
 	q->q_base |=3D FIELD_PREP(Q_BASE_LOG2SIZE, q->llq.max_n_shift);
=20
 	q->llq.prod =3D q->llq.cons =3D 0;
+
+	q->non_coherent =3D !(smmu->features & ARM_SMMU_FEAT_COHERENCY);
+
 	return 0;
 }
=20
diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthroug=
h/arm/smmu-v3.h
index f09048812c..ab07366294 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.h
+++ b/xen/drivers/passthrough/arm/smmu-v3.h
@@ -522,6 +522,9 @@ struct arm_smmu_queue {
=20
 	u32 __iomem			*prod_reg;
 	u32 __iomem			*cons_reg;
+
+	/* Is the memory access coherent? */
+	bool				non_coherent;
 };
=20
 struct arm_smmu_cmdq {
--=20
2.50.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 19:27:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 19:27:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1108939.1458871 (Exim 4.92)
	(envelope-from )
	id 1utt8T-0001VO-EQ; Wed, 03 Sep 2025 19:27:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1108939.1458871; Wed, 03 Sep 2025 19:27: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 1utt8T-0001VH-BV; Wed, 03 Sep 2025 19:27:13 +0000
Received: by outflank-mailman (input) for mailman id 1108939;
 Wed, 03 Sep 2025 19:27: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 1utt8R-0001VB-QS
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 19:27:11 +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 fc369ff3-88fb-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 21:27:10 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-55f78e3cdf9so226366e87.1
 for ; Wed, 03 Sep 2025 12:27:09 -0700 (PDT)
Received: from [192.168.0.110] ([91.123.151.69])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5608ad2c3adsm681780e87.131.2025.09.03.12.27.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 12:27: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: fc369ff3-88fb-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756927629; x=1757532429; 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=pYl2fq/xKQo6MRXjhA6xisl1n5IPmDm1Ug6zNjVIlT8=;
        b=m98qtnIBwHDAILljcflvEs2aAfOr94yUJMAKf0LRP3Sw0EA6HbEKY7ENYlrkmVFdi9
         sGDX+c8p/kF5OY+8Ncp9YagwPI6w3GO1boBkRZZqMBr7r6iFjP+ngYH9Ms+VN+xkGIWI
         kUPIcBG1adS7x3yOfFEp6IyCjZCn7EIC9kYalFpl+Rv+7PKJGGfsO87XMxv/oKe5oSY3
         ZL/pK6mTXbtt/Oji9uklqWXQbTuMyl9oTEpLgmo2VHGzBA3poH86PLvwjPtlG4MUy0BK
         qFraSVrQ3NwYoauCvhATPhyCb6ga3cLKr9DbHFSMPk5t1NEO+BrWDT6BSvNF3nGvRvX+
         YJSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756927629; x=1757532429;
        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=pYl2fq/xKQo6MRXjhA6xisl1n5IPmDm1Ug6zNjVIlT8=;
        b=RVJyoGS7IVT3B4Js+Nt5qVtf87BXUwWyu5JHHePmrP9R3oXdQ9b5BP6wzWPqDJbJMD
         8zMQydXVACNDuwoNcDRIK2KdJkL0+VpPX/gtjT0U+5LNm+YNuEokop0o6HHDWGM9eK97
         8QwsOosRcK/Yn1pYKV24wyI3flb0sTAwOrnblIibuLf5GJVEGYjPCIyGv0eCd1Zoc5Q4
         xQnqKgpYXXhzF12fvR0odVtz9jEauN+lkb4BF2AZkBiEVlkY+iJWChIYpEFENLv2IkSu
         KSxZfsEfDvGSa/1JILxSqg+Gladp4ctEj3EruwzeizlXkBzRav8yxfc2w4g35LWm3Sx2
         pUcg==
X-Forwarded-Encrypted: i=1; AJvYcCWGIONJivqpb7/s2FzyxjKlrt3xToGc+cteIGbXFg8Bk9ESxSj3kI1ctjcJ4jFv43oyOmQjNRN4DmI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/97J1edUAaVkNfcGzHmGJK3KL1pzd+ieNTY1A5hPPZqXFwnwk
	TiGYzK3h+jt0AI+5T/gaS7nTrvnRSNqnEKfLIbULGbrnOIdnPtJuLRps
X-Gm-Gg: ASbGncs7dZ9awNxM5v3blxyHMyARUXVrSdsi/gYipvVtQaY7nKvigUNCVzpH+3pmTkk
	aOEmocZtKmSgpzg2TFo00XzzkIAQv15EapqtpeAIdi1xDmDW4JtcAYw2BDTgKKZbddDw2sOLnoP
	ZlG74yyDMNgD89/tv0t/8A36++e4Ee/R+5w520/RQvuijkEKqrIgmCMuOLm7deFTtm4QEEkBK5+
	VBMKEATbIAjtxL25AfuKybqAeyMm4tRje+mGPp7PkM1cl+2AcoApOaba74dLaD3PXYMKfp42hkL
	HnKj+4TXw1X3xVy+cUR+mWpXbWt8C02GTXzY962r+gjqkYw/6ywdkW99WEKS9iVwUl7BLnztOGt
	9RDdM84xm/2wdND5k9mVN82eiHpPMlQFWHZeM
X-Google-Smtp-Source: AGHT+IF4iciau66j/+aZXTYHO8UW0frcJixHK4Xt5y+gIGkGG6g1mputXC3M5SkSqPU4hPcGLhQ9Wg==
X-Received: by 2002:a05:6512:3ca4:b0:55f:6b76:e7f7 with SMTP id 2adb3069b0e04-55f709bdd91mr4829403e87.56.1756927628844;
        Wed, 03 Sep 2025 12:27:08 -0700 (PDT)
Message-ID: 
Date: Wed, 3 Sep 2025 22:27:07 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 03.09.25 17:30, Leonid Komarianskyi wrote:

Hello Leonid

> Implemented support for GICv3.1 extended SPI registers for vGICv3,
> allowing the emulation of eSPI-specific behavior for guest domains.
> The implementation includes read and write emulation for eSPI-related
> registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
> following a similar approach to the handling of regular SPIs.
> 
> The eSPI registers, previously located in reserved address ranges,
> are now adjusted to support MMIO read and write operations correctly
> when CONFIG_GICV3_ESPI is enabled.
> 
> The availability of eSPIs and the number of emulated extended SPIs
> for guest domains is reported by setting the appropriate bits in the
> GICD_TYPER register, based on the number of eSPIs requested by the
> domain and supported by the hardware. In cases where the configuration
> option is disabled, the hardware does not support eSPIs, or the domain
> does not request such interrupts, the functionality remains unchanged.
> 
> Signed-off-by: Leonid Komarianskyi 
> 
> ---
> Changes in V6:
> - introduced helper functions: vgic_get_rank and vgic_get_reg_offset to
>    avoid boilerplate code and simplify changes
> - fixed index initialization in the previous patch ([08/12] xen/arm:
>    vgic: add resource management for extended SPIs) and removed index
>    conversion for vgic_enable_irqs(), vgic_disable_irqs(),
>    vgic_set_irqs_pending(), and vgic_check_inflight_irqs_pending()
> - grouped SPI and eSPI registers
> - updated the comment for vgic_store_irouter to reflect parameter
>    changes
> - minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
>    into appropriate inline functions introduced in the previous patch

Reviewed-by: Oleksandr Tyshchenko 

preferably with the comments below

> 
> Changes in V5:
> - since eSPI-specific defines and macros are now available even when the
>    appropriate config is disabled, this allows us to remove many
>    #ifdef guards and reuse the existing code for regular SPIs for eSPIs as
>    well, as eSPIs are processed similarly. This improves code readability
>    and consolidates the register ranges for SPIs and eSPIs in a single
>    place, simplifying future changes or fixes for SPIs and their
>    counterparts from the extended range
> - moved vgic_ext_rank_offset() from
>    [08/12] xen/arm: vgic: add resource management for extended SPIs
>    as the function was unused before this patch
> - added stub implementation of vgic_ext_rank_offset() when CONFIG_GICV3_ESPI=n
> - removed unnecessary defines for reserved ranges, which were introduced in
>    V4 to reduce the number of #ifdefs. The issue is now resolved by
>    allowing the use of SPI-specific offsets and reworking the logic
> 
> Changes in V4:
> - added missing RAZ and write ignore eSPI-specific registers ranges:
>    GICD_NSACRnE and GICD_IGRPMODRnE
> - changed previously reserved range to cover GICD_NSACRnE and
>    GICD_IGRPMODRnE
> - introduced GICD_RESERVED_RANGE_START/END defines to remove
>    hardcoded values and reduce the number of ifdefs
> - fixed reserved ranges with eSPI option enabled: added missing range
>    0x0F30-0x0F7C
> - updated the logic for domains that do not support eSPI, but Xen is
>    compiled with the eSPI option. Now, prior to other MMIO checks, we
>    verify whether eSPI is available for the domain or not. If not, it
>    behaves as it does currently - RAZ and WI
> - fixed print for GICD_ICACTIVERnE
> - fixed new lines formatting for switch-case
> 
> Changes in V3:
> - changed vgic_store_irouter parameters - instead of offset virq is
>    used, to remove the additional bool espi parameter and simplify
>    checks. Also, adjusted parameters for regular SPI. Since the offset
>    parameter was used only for calculating virq number and then reused for
>    finding rank offset, it will not affect functionality.
> - fixed formatting for goto lables - added newlines after condition
> - fixed logs for GICD_ISACTIVERnE and GICD_ICACTIVERnE handlers
> - removed #ifdefs in 2 places where they were adjacent and could be merged
> 
> Changes in V2:
> - add missing rank index conversion for pending and inflight irqs
> ---
>   xen/arch/arm/include/asm/vgic.h |   4 +
>   xen/arch/arm/vgic-v3.c          | 198 +++++++++++++++++++++++++-------
>   xen/arch/arm/vgic.c             |  22 ++++
>   3 files changed, 180 insertions(+), 44 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h
> index c52bbcb115..dec08a75a4 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -314,6 +314,10 @@ extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v,
>                                                 unsigned int b,
>                                                 unsigned int n,
>                                                 unsigned int s);
> +extern struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v,
> +                                                  unsigned int b,
> +                                                  unsigned int n,
> +                                                  unsigned int s);
>   extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq);
>   extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
>   extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 4369c55177..27af247d30 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -107,17 +107,12 @@ static uint64_t vgic_fetch_irouter(struct vgic_irq_rank *rank,
>   /*
>    * Store an IROUTER register in a convenient way and migrate the vIRQ
>    * if necessary. This function only deals with IROUTER32 and onwards.
> - *
> - * Note the offset will be aligned to the appropriate boundary.
>    */
>   static void vgic_store_irouter(struct domain *d, struct vgic_irq_rank *rank,
> -                               unsigned int offset, uint64_t irouter)
> +                               unsigned int virq, uint64_t irouter)
>   {
>       struct vcpu *new_vcpu, *old_vcpu;
> -    unsigned int virq;
> -
> -    /* There is 1 vIRQ per IROUTER */

You seem to have dropped a comment, but not just moved it to virq 
calculation outside of the vgic_store_irouter() in "case 
VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):". If the comment is valid (I 
assume so), it would be better to retain it.

> -    virq = offset / NR_BYTES_PER_IROUTER;
> +    unsigned int offset;
>   
>       /*
>        * The IROUTER0-31, used for SGIs/PPIs, are reserved and should
> @@ -673,6 +668,34 @@ write_reserved:
>       return 1;
>   }
>   
> +/*
> + * Since all eSPI counterparts of SPI registers belong to lower offsets,
> + * we can check whether the register offset is less than espi_base and,
> + * if so, return the rank for regular SPI. Otherwise, return the rank
> + * for eSPI.
> + */

NIT: I would just write the following:

The assumption is that offsets below espi_base are for regular SPI, 
while those at or above are for eSPI.

> +static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
> +                                                  unsigned int b,
> +                                                  uint32_t reg,
> +                                                  unsigned int s,
> +                                                  uint32_t spi_base,
> +                                                  uint32_t espi_base)

I find the name "vgic_get_rank" a bit confusing since the vgic.c already 
contains the helper with the same name:

static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)

So what we have for regular SPIs is:
vgic_get_rank()->vgic_rank_offset()->vgic_get_rank()
and for eSPIs is:
vgic_get_rank()->vgic_ext_rank_offset()->vgic_get_rank()

I would rename it, e.g. vgic_common_rank_offset (not ideal though)


> +{
> +    if ( reg < espi_base )
> +        return vgic_rank_offset(v, b, reg - spi_base, s);
> +    else
> +        return vgic_ext_rank_offset(v, b, reg - espi_base, s);
> +}
> +
> +static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base,
> +                                           uint32_t espi_base)
> +{
> +    if ( reg < espi_base )
> +        return reg - spi_base;
> +    else
> +        return reg - espi_base;
> +}

I am wondering (I do not request a change) whether vgic_get_reg_offset() 
is really helpfull,
e.g. is
  offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORITYRnE);
much better than:
  offset = reg < GICD_IPRIORITYRnE ? reg - GICD_IPRIORITYR : reg - 
GICD_IPRIORITYRnE;

?

[snip]


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 20:56:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 20:56:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109007.1458880 (Exim 4.92)
	(envelope-from )
	id 1utuWv-0003tk-Mz; Wed, 03 Sep 2025 20:56:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109007.1458880; Wed, 03 Sep 2025 20:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utuWv-0003td-K7; Wed, 03 Sep 2025 20:56:33 +0000
Received: by outflank-mailman (input) for mailman id 1109007;
 Wed, 03 Sep 2025 20:56:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1utuWu-0003ru-0z
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 20:56:32 +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 76d84045-8908-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 22:56:29 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9607.eurprd03.prod.outlook.com
 (2603:10a6:20b:5aa::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 20:56:23 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 20:56:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76d84045-8908-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Xk5OmPWSU9QfUWF96sPNf6cX4/Fwag4wc43GE71Svv4ukRKtYE06IxqCWIxH2N8YYDXZgC4S+oAEu4h2mkkRV6bPapFoKtb93XYD88bHCqLA9+8GjkFtkqPe3m2zd9KC1m/tuPFnxJ+g+MzV2AvB+nnDzvAKD+jdtnotVE8zC6D9xhoei+6tC4sgAS0OcJB6n9r307YbPRh1aOVJpM8H0vydi5Nk/rkL3cOEGUPLpTm6X9bHwIPIMD+DMrNTk8/ruZJ4nYT0s2UJC7d8HVwlr/YWnDHElKg2zv7umtCxdJ8jExI4TZOYEeEpFEYRBGNZPefcHlmx+lumwx0/+1mxAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NHBB6K7fdkexlFQb2xgGYNeRBsQkNzv4XxPRVogmNW0=;
 b=lUo14Taba/qQJSvx/GunzFmePQkvoqDaikkqFU0jZMW0VUerKC3M4r/0BbnIFcLvY30s2ElnS1B0ZVQaTLUFPHU9My3VJ31eqfcotbTafCFgjLgLxSfeh1Onpja+58nb45F4xtsdIfGmKYDferLIYmdN9gRV6Oa9dyA/JJ+s1NijwkOSaV0l0FjpkdpwSUkffhYpg+E9IkdJ6NyufE55KfkCtYzT2B7TvBRAG2Kgw2z+xxUXD6boKZDF5oL6D99bAOor18W9d7anAeyehP9bbgGJKWWZ7T1EVJCLPPdG6NoaXHjVXq4kOBWjdlmhyS7BSuRvY02T5bz0gL2IXzSyww==
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=NHBB6K7fdkexlFQb2xgGYNeRBsQkNzv4XxPRVogmNW0=;
 b=KorWWgmjTyLZDckxfnvWQd7tWLMveqmmEFYC00nZIBRQNuyGreKbV/c3EacVEQCokFVfqX7RCxLJ5BH3TrJF41sC2j/7Cg0J3/18tlOhYlstyeeqm80Z3riJi2YUbn8WhYLFHn4WfgFV4aihjga4eICsE8nH0WcNqL1BG9ramyIOToEgg+5u0UP1VdxEqbByGJr4h6VtelALiyKaLx7rzlts2YcClLSdJcnh3hdf4ghy09FLbxn1Fy64Qc8XNAaVeE3bZVr0VcoKHEAThkpZFBwjhTXT3lMGxdspA/XRCtRYtZllvAQCwTGHPa4U853LBMWOvYPfw6LlFrrYHwIj1g==
From: Volodymyr Babchuk 
To: Leonid Komarianskyi 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Topic: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHN87CzNpV/kRn0iD7+cHr07F5Q==
Date: Wed, 3 Sep 2025 20:56:22 +0000
Message-ID: <87a53buufe.fsf@epam.com>
References: 
	
In-Reply-To:
 
	(Leonid Komarianskyi's message of "Wed, 3 Sep 2025 14:29:59 +0000")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS8PR03MB9607:EE_
x-ms-office365-filtering-correlation-id: 75be6d07-784a-45f1-7bf5-08ddeb2c5758
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|366016|42112799006|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?7TBk6oD4DNqb/g8X7yQEJ8elKHzl2CQMbMOADjW4jPqIIzi2ioygcBoqUy?=
 =?iso-8859-1?Q?Ar2kDjAWB8ESgVzI6dO5IBlLOwyu9yeTfnlWk7ThOcsFkFnUsFQT6BTamP?=
 =?iso-8859-1?Q?QgjPNXXIS0oGMG7PZKtELprBYnnMwkHj2ghLMdTxXVPavrlEip0qUk+gd3?=
 =?iso-8859-1?Q?zgmP6PQQI/ADzdybubbu2/va8uaMYd1n1PtztdeB/XO6OufQZB44hvjhJ9?=
 =?iso-8859-1?Q?ySyiSzfjAo1imcN30SO+4RPsvZkl08xhsWmsW3ZPNmACr6dGRSXTG1Y+1o?=
 =?iso-8859-1?Q?axjEJvQIDxjM9W+r9QhohZp+hCsajNIk7bQDiraHS9X72K6dAyWtO0oJEW?=
 =?iso-8859-1?Q?vBjhgPxwueErQG7VI9Iy0lSSijs9GUgOTisDjojv3XsF/ePNVHONPEYYBa?=
 =?iso-8859-1?Q?0F3heDgDnLxbg7Hb2gNVUIH4Kx3YjTGCaUCILqiaxarEHQ4xCab5MDT1iy?=
 =?iso-8859-1?Q?3oqk+Vz6E9UT1T4CRGVJAOOU/o224pwSmRcc2353xyZ/BAXFir2gzAQc+3?=
 =?iso-8859-1?Q?1OzxBXDenQxwXNfwCQ3sx4yadFsyolXw9mUR1el8caviWYKrnSUOoY3BC0?=
 =?iso-8859-1?Q?CpoVJsP84YZycV4uPzLdO7aT65c5FEHNFYiBI1O5NPC6rrj/iBYBut3TWu?=
 =?iso-8859-1?Q?B2gIP9exKeMzeNs5QzXKpb/sajEPlzzntT5PvJERXZ42h+96IrQog/S1rn?=
 =?iso-8859-1?Q?ZVSWZ6LTQ0OI2KAbMFx8KY88vzos5zsz4xCHUHcrXim49GaDfdZL4qchJ3?=
 =?iso-8859-1?Q?zISf6+KM67SgGkZ0qySCJAgCkWlQvIM7ZJep6Djt5RYdljXeqcI4Vuuia0?=
 =?iso-8859-1?Q?nyd8qkCaQCjB4iQsjGf0lZbw1iUBkrT/F2Aw2Qa1ZVdaa0yQXi7XP9anSG?=
 =?iso-8859-1?Q?1MVEZqlUwy6WEO3PvzSi3sygNX+wcfz+xe5Iiafagtg7QZPOe37npa+xzd?=
 =?iso-8859-1?Q?r9mublmIt0+h4xETouKTpjlQunCawlsW3lHHBDEiVVOJbD1yk5k2Oi8cZx?=
 =?iso-8859-1?Q?YN5CTIeKSc69WevZeQ7FOJ0IT91U0UkAgbVuuba19gP7PKl7bStzfr8YI8?=
 =?iso-8859-1?Q?VsZs1eOeTzHOHqKJ1WTVHZWx+jbjBrDs+VUqMHEyLTGMIZe7aThPDnwdBx?=
 =?iso-8859-1?Q?Xw7xfkl/UecQOZdVaNHDZNLUOeTtJ2e79sHwT9WS00DVUT2g8XHvRYz/YI?=
 =?iso-8859-1?Q?aNPgvgDT2dlXNPH9HSTsXAsKTqmKcnC33+37Jdd3ijTxcSsYJIhx96n7Um?=
 =?iso-8859-1?Q?0WBawsGmS6RJS7UXBIk/a7WVPvs+MlqnwQyErrF+c03O2Ef0tqGIihlsIK?=
 =?iso-8859-1?Q?zDVKB9VtFDFv30RJebs2y1qEVKDy1iUlTNO8ioXbUof2oWPT2mF+I9595Y?=
 =?iso-8859-1?Q?2swNr3/iwxHpqdxK/myNus8x8uH2azZZA2mqBEkFfFaR+/OQvHETzPbUSt?=
 =?iso-8859-1?Q?XxN1xHCJREP8QHMOTL6ODbsMEROoH+QpcDcuXBTXvW1X0rlxGbSBNeq4Yf?=
 =?iso-8859-1?Q?zVollHkxiBnylWWG0VuctY0Yxj/nOiX8EhmIIiF6AYpg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(42112799006)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?MuQ+7/u31G6Ra/jUJVxnAvXHlYvI2Qt9sK/VOrJUz0tKfyDPHWfglBnum0?=
 =?iso-8859-1?Q?yY1BQInKBg6yNLwa0dXMI1PJ1hiEXWVEb5Upk/SxZBn4adkV248d4B3gbV?=
 =?iso-8859-1?Q?vaNfEqp9EUr4pYQxn+Xbw0fdFz0bZelPNI9WhBtTqEWmijYFhwTVuydo5D?=
 =?iso-8859-1?Q?jTFIUTrhbElNSmrbIWtrjbv8QyG6pzkXCni0D7lzIxs/AXqXLLU4/Htwrf?=
 =?iso-8859-1?Q?ai+LJq+nH4EwYRqBbTxIzNjp5aobALWoI2vXE5ZeDUxvXB4xpeCLyv0Aci?=
 =?iso-8859-1?Q?g7FKMuj7vyA4ifmCJqiiDGwlCuMPaloRSnTUgEYtFZUdl7vMxrw2LrDaLX?=
 =?iso-8859-1?Q?BQ7q3aekYw1bxpkORCEUrGHbBNqpz/TlS5OaSJYGUXirJmSIqdSmw3el+U?=
 =?iso-8859-1?Q?2OnnkBcJ+IjIc4wcIMZ3C7bSobA0sRD3J8PQmR5jutQtvQJ5dF6uvVqGd6?=
 =?iso-8859-1?Q?SR7ifA0emnwfT5rv8GOU7VDitAIGOa/1zgri12er/SBEu1kgnjIdTwOCxw?=
 =?iso-8859-1?Q?5cRdt1D8FMRDjWQehbSpNf2YM0N17LlM+jH/orNsMa3/UyLY7v6beRC/YH?=
 =?iso-8859-1?Q?gId6IuzdaKesJHRHi3mM4FRQ3RcW5F6MnVaeA+2cHZ7bNewLAd7A37t6gQ?=
 =?iso-8859-1?Q?ARb55lwK052avi3QypZWbdf9zBzC/xTG1FXijNJB3eL8fylwHqgFW/N0BQ?=
 =?iso-8859-1?Q?PdAmSSSF8m40lli2LnPzeGv3Vj7WMNjy2Z7gOqqtOZOgxPL6s0rwlRNzU5?=
 =?iso-8859-1?Q?vWwBJnWiPdPhtekxn7gsJeOj2M5tHutyV/C02kLYVb1a4ARcpdkNq4X6ST?=
 =?iso-8859-1?Q?VHMBJeXjHqIN7TEEPj7nplB/SzFc4oYKdExTFuz2AL+Ru5CpdNGADipmB4?=
 =?iso-8859-1?Q?JG7I66eMEdZoe2yM3A+1j4G+JN3WFA2jHiOZjd69925k2Q1KYiaBmjmpU9?=
 =?iso-8859-1?Q?BY7L9Swqhzx7rmu8amVppyf0DIkg0GcppMg8zlzTMag+pSwm2CU7HCm+NO?=
 =?iso-8859-1?Q?PuimQwU/Gn4jvUiIvcz5bv7JFfi6mzRujGc1QqTGYtSNKzm7AoPicOz105?=
 =?iso-8859-1?Q?30gt/ywg2yIjOeTC4J/7oz3HvcYgIA/EiRo0eb/xT1ola7DR7w7XPy+t6x?=
 =?iso-8859-1?Q?JHFw1SKKn5WarFMFYwU5urb8pr+lL2X85IKceCBjmB06C5IDRNCUCFjAYP?=
 =?iso-8859-1?Q?OvCRUZhjUux8vDCFZ05fh0v3uIoWLsN3jD+aMEK5PWkCd8XUjBoLXIlbti?=
 =?iso-8859-1?Q?zIJBxjQrRPdYY8CnB/q99ha8xbYubr/ZGjQsJBe8F8/43AhqfBIQx04Yao?=
 =?iso-8859-1?Q?DLusRWrziK4B8yllgFsWPPGE4uAmTY2sV2VNmjudMPWycOtszId+/RZEa2?=
 =?iso-8859-1?Q?YyPzU3MHD2HZosTuYZ0lve/H5JSajiL+h9VPveuhe/owXPZu44xqQZe3wx?=
 =?iso-8859-1?Q?MrX7zvhzW+Pmk9lYY63xc1Ify2XrSzNpH3nxpItP6feCuf0eaaFHJXbWWJ?=
 =?iso-8859-1?Q?/WVPxP9+FkCrCBdD1Pssj2geDO4XQpX436+02XR7+vLbx1b522g59iGpnz?=
 =?iso-8859-1?Q?/RXKJfrf5q+EEkoZ7dOePWWngBGwnUI50EzHFrP/hz1CZh8Z0RWf801fqy?=
 =?iso-8859-1?Q?r5dvnHJdQUSjzjsUgJXhxeSsIhMdDi8RYk/fSa9wQddI1i9Dfj5uiiJA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 75be6d07-784a-45f1-7bf5-08ddeb2c5758
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 20:56:23.2359
 (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: /oPPJqbBRRw/NyAALBykNjq6g1hru40HV9yGm0ClrAkUBfv4mle1nUEfm2L3dz4/K+W2Qz7/rD0WhB5CfoDzKzL6d1qkb4F3otidYUVyg7s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9607

Hi Leonid,

Leonid Komarianskyi  writes:

> Currently, Xen does not support eSPI interrupts, leading
> to a data abort when such interrupts are defined in the DTS.
>
> This patch introduces a separate array to initialize up to
> 1024 interrupt descriptors in the eSPI range and adds the
> necessary defines and helper function. These changes lay the
> groundwork for future implementation of full eSPI interrupt
> support. As this GICv3.1 feature is not required by all vendors,
> all changes are guarded by ifdefs, depending on the corresponding
> Kconfig option.
>
> Signed-off-by: Leonid Komarianskyi 
>
> ---
> Changes in V6:
> - added an assert in is_espi() when CONFIG_GICV3_ESPI=3Dn to ensure that
>   out-of-range array resources are not accessed, e.g., in __irq_to_desc()
> - removed unnecessary parentheses in is_espi()
> - converted helper macro to inline functions and added sanity checks
>   with ASSERTs to them
> - defined espi_to_desc for non-eSPI builds as a prototype
> - updates the comments
> - used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs
>
> Changes in V5:
> - no functional changes introduced by this version compared with V4, only
>   minor fixes and removal of ifdefs for macroses
> - added TODO comment, suggested by Oleksandr Tyshchenko
> - changed int to unsigned int for irqs
> - removed ifdefs for eSPI-specific defines and macros to reduce the
>   number of ifdefs and code duplication in further changes
> - removed reviewed-by as moving defines from ifdefs requires additional
>   confirmation from reviewers
>
> Changes in V4:
> - removed redundant line with 'default n' in Kconfig, as it is disabled
>   by default, without explicit specification
> - added reviewed-by from Volodymyr Babchuk
>
> Changes in V3:
> - introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
>   case of using NR_IRQS for espi_desc array
> - implemented helper functions espi_to_desc and init_espi_data to make
>   it possible to add stubs with the same name, and as a result, reduce
>   the number of #ifdefs
> - disable CONFIG_GICV3_ESPI default value to n
>
> Changes in V2:
> - use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
> - remove unnecessary comment for nr_irqs initialization
> ---
>  xen/arch/arm/Kconfig           |  8 +++++
>  xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
>  xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
>  3 files changed, 96 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 17df147b25..43b05533b1 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -135,6 +135,14 @@ config GICV3
>  	  Driver for the ARM Generic Interrupt Controller v3.
>  	  If unsure, use the default setting.
> =20
> +config GICV3_ESPI
> +	bool "Extended SPI range support"
> +	depends on GICV3 && !NEW_VGIC
> +	help
> +	  Allow Xen and domains to use interrupt numbers from the extended SPI
> +	  range, from 4096 to 5119. This feature is introduced in GICv3.1
> +	  architecture.
> +
>  config HAS_ITS
>          bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPO=
RTED
>          depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/ir=
q.h
> index 5bc6475eb4..f4d0997651 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>  #define SPI_MAX_INTID   1019
>  #define LPI_OFFSET      8192
> =20
> +#define ESPI_BASE_INTID 4096
> +#define ESPI_MAX_INTID  5119
> +#define NR_ESPI_IRQS    1024
> +
>  /* LPIs are always numbered starting at 8192, so 0 is a good invalid cas=
e. */
>  #define INVALID_LPI     0
> =20
> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>  #define INVALID_IRQ     1023
> =20
>  extern const unsigned int nr_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +/* This will cover the eSPI range, to allow asignmant of eSPIs to domain=
s. */
> +#define nr_static_irqs (ESPI_MAX_INTID + 1)
> +#else
>  #define nr_static_irqs NR_IRQS
> +#endif
> =20
>  struct irq_desc;
>  struct irqaction;
> @@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
>      return irq >=3D LPI_OFFSET;
>  }
> =20
> +static inline unsigned int espi_intid_to_idx(unsigned int intid)
> +{
> +    ASSERT(intid >=3D ESPI_BASE_INTID && intid <=3D ESPI_MAX_INTID);
> +    return intid - ESPI_BASE_INTID;
> +}
> +
> +static inline unsigned int espi_idx_to_intid(unsigned int idx)
> +{
> +    ASSERT(idx <=3D NR_ESPI_IRQS);
> +    return idx + ESPI_BASE_INTID;
> +}
> +
> +static inline bool is_espi(unsigned int irq)
> +{
> +#ifdef CONFIG_GICV3_ESPI
> +    return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID;
> +#else
> +    /*
> +     * The function should not be called for eSPIs when CONFIG_GICV3_ESP=
I is
> +     * disabled. Returning false allows the compiler to optimize the cod=
e
> +     * when the config is disabled, while the assert ensures that out-of=
-range
> +     * array resources are not accessed, e.g., in __irq_to_desc().
> +     */
> +    ASSERT(irq >=3D ESPI_BASE_INTID);

This really puzzles me. Should it be other way around? I.e.

ASSERT(irq < ESPI_BASE_INTID) ? Or even ASSERT(irq <=3D 1022) ?

Actually, I tried to your series. XEN does not boots at all when
CONFIG_GICV3_ESPI=3Dn. Looks like it panics even before it can bring up
the console, as I don't see any prints in QEMU. Non-debug build boots
fine, thought, but this is expected, as ASSERTs are disabled.


> +    return false;
> +#endif
> +}
> +
>  #define domain_pirq_to_irq(d, pirq) (pirq)
> =20
>  bool is_assignable_irq(unsigned int irq);
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index b8eccfc924..c934d39bf6 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -19,7 +19,9 @@
>  #include 
>  #include 
> =20
> -const unsigned int nr_irqs =3D NR_IRQS;
> +const unsigned int nr_irqs =3D IS_ENABLED(CONFIG_GICV3_ESPI) ?
> +                                        (ESPI_MAX_INTID + 1) :
> +                                        NR_IRQS;
> =20
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
> @@ -46,6 +48,50 @@ void irq_end_none(struct irq_desc *irq)
>  }
> =20
>  static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
> +#ifdef CONFIG_GICV3_ESPI
> +/* TODO: Consider allocating an array dynamically */

I'd considered using radix tree, honestly... But this is just topic for
discussion, no action should be taken here.

> +static irq_desc_t espi_desc[NR_ESPI_IRQS];
> +
> +static struct irq_desc *espi_to_desc(unsigned int irq)
> +{
> +    return &espi_desc[espi_intid_to_idx(irq)];
> +}
> +
> +static int __init init_espi_data(void)
> +{
> +    unsigned int irq;
> +
> +    for ( irq =3D ESPI_BASE_INTID; irq <=3D ESPI_MAX_INTID; irq++ )
> +    {
> +        struct irq_desc *desc =3D irq_to_desc(irq);
> +        int rc =3D init_one_irq_desc(desc);
> +
> +        if ( rc )
> +            return rc;
> +
> +        desc->irq =3D irq;
> +        desc->action  =3D NULL;
> +    }
> +
> +    return 0;
> +}
> +#else
> +/*
> + * Defined as a prototype as it should not be called if CONFIG_GICV3_ESP=
I=3Dn.
> + * Without CONFIG_GICV3_ESPI, the additional 1024 IRQ descriptors will n=
ot
> + * be defined, and thus, they cannot be used. Unless INTIDs from the eSP=
I
> + * range are mistakenly defined in Xen DTS when the appropriate config i=
s
> + * disabled, this function will not be reached because is_espi will retu=
rn
> + * false for non-eSPI INTIDs.
> + */
> +struct irq_desc *espi_to_desc(unsigned int irq);
> +
> +static int __init init_espi_data(void)
> +{
> +    return 0;
> +}
> +#endif
> +
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
> =20
>  struct irq_desc *__irq_to_desc(unsigned int irq)
> @@ -53,6 +99,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
>      if ( irq < NR_LOCAL_IRQS )
>          return &this_cpu(local_irq_desc)[irq];
> =20
> +    if ( is_espi(irq) )
> +        return espi_to_desc(irq);
> +
>      return &irq_desc[irq-NR_LOCAL_IRQS];
>  }
> =20
> @@ -79,7 +128,7 @@ static int __init init_irq_data(void)
>          desc->action  =3D NULL;
>      }
> =20
> -    return 0;
> +    return init_espi_data();
>  }
> =20
>  static int init_local_irq_data(unsigned int cpu)

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 20:58:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 20:58:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109017.1458891 (Exim 4.92)
	(envelope-from )
	id 1utuZ2-0004Of-3M; Wed, 03 Sep 2025 20:58:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109017.1458891; Wed, 03 Sep 2025 20: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 1utuZ1-0004OY-Vk; Wed, 03 Sep 2025 20:58:43 +0000
Received: by outflank-mailman (input) for mailman id 1109017;
 Wed, 03 Sep 2025 20:58: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 1utuZ0-0004OQ-Ed
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 20:58:42 +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 c491d829-8908-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 22:58:40 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9607.eurprd03.prod.outlook.com
 (2603:10a6:20b:5aa::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 20:58:37 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 20:58: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: c491d829-8908-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=crc/DZxct+UWQ90k9Y4XA9sVYKcOqx5GUZ6AmpQJuN3p9UXottYHIupibJ5Z9j/99Bni7QT1Qgi6h5M4I3FIE910oK/BThkZBknvIDu4cFtx0CjoxWK35r26QghOOWxsS24DQKDvVBb8Cx8AmxHZLzr8Nd4bDkLSyMaYWX/OhLGmpJTMwHxc9schrBmbJ/YV6tSAFqVkftut0DKqfKNppuatKLHwLkhZTA+z/UmiP0vWWthy9cKigt00RuBzdDDn6zwbkP14ikgUMi+zm8Kj8Fjy7cTYMDpk6b/nC/5xRDgZl8/yaSFTU2d+3kmqIn1bs7uOtaIC3E6NNWDzeHSHcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fvgXeD7gSv6SvgyBUH/iIov5VVjjIoJkJRHd8nXgWIk=;
 b=jPHlFaLePg//O7G/g8la32b6NGq44ytiorGhFnfKjIqP6JjwDq5DFILhIOmhRokwhbIYDS/Ptz1dq0Mg7l0b9SQRnfgEoW0YSNcqJMeT4mWlf9qsqaX7VWM8UUGa7YuRFdcppEUr9qXXfz9pndYmMzX2e5rg8DUdsXAuBcv3UL+YbZgeRtrojsuvxTPKMYw5JjqFCHZHdsbeZ4IllxYbkAiSARPry7NbZOpF4tgUfjcUj16AVFDDFICQhC6Yh0hoqz52Ps2Qve0jAgF1sjMzsK1mp3sN9n2DT/1WGU1DMFI6D4ovbrL4rJmgpIZyHp1cZHL50jXcZxib8fVEo3xbgA==
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=fvgXeD7gSv6SvgyBUH/iIov5VVjjIoJkJRHd8nXgWIk=;
 b=ur/osPkDz3+y1HpU9ZCKFiSRfjUyx1MyVSmMTRnjtPiGhAMj44SXoz260OMKc/fKd7CVJX76Yl+fsZMnJEVhhV3/stB7RvdG1Urzj7MExI7HjhmVEu6/vqjWF9UFvQhxM+3g+NmGMhwu/8RN3+eyM9lIyRtPTc2SR48ZycBKjRJ8wQUFL4T+GTH1MzywZ+WOqlJ7RHc/Jaz2uJgBttPrKCrBPQ5vTSwfbAkndtCNFxiZDlEvjIjJDTWxObomvihXTVmXMYTBDYddfBUwhyk0rXJwVqf2qMCJP1DhotGwfZc8yejTEpYLsGtQHNOOFJ6dfl0xyBPaWITC5aqjKSmvwg==
From: Volodymyr Babchuk 
To: Leonid Komarianskyi 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v6 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to
 allow eSPI processing
Thread-Topic: [PATCH v6 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to
 allow eSPI processing
Thread-Index: AQHcHN9BaUpUjNGOp0+m0BX8qyVhBg==
Date: Wed, 3 Sep 2025 20:58:37 +0000
Message-ID: <874itjuubn.fsf@epam.com>
References: 
	
In-Reply-To:
 
	(Leonid Komarianskyi's message of "Wed, 3 Sep 2025 14:30:08 +0000")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS8PR03MB9607:EE_
x-ms-office365-filtering-correlation-id: 796cf9cb-4bca-42dc-1464-08ddeb2ca763
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|366016|42112799006|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?7MRlv5bU9pl8gukW3YBpwWowGAO74pD7fUBtbNISsAg6j90viUnag12RpT?=
 =?iso-8859-1?Q?BquyUxZdWbZ9Dt0X7lmLvuWqx9RzEa5ArC2p65SwHqne24YqntAEsHpYe3?=
 =?iso-8859-1?Q?SbiUzPg/XmTwXdjkqF0W5VRC88iBDMkZ/RTF+fn/kj/27+0BG00H7ZbXoK?=
 =?iso-8859-1?Q?Qj8Arf5bkzAjcICvuAKRlL+9Y7XhXJWIaMAZkP7gQX8qewW3J6nj4rR+IY?=
 =?iso-8859-1?Q?/NvUE4BVj4qMGcSjEuFWkJWwCQVRD500H4kU6YbqXXH7+8nD+ZtwYtfonO?=
 =?iso-8859-1?Q?tgrPhRn96yuQQpkcDR+YJvKgI/jWz2+nnWgyrjQrvN9JG8hyO8N5ce7tMk?=
 =?iso-8859-1?Q?m6lFppLuaLmiZBglknBpp9bwG8hbs0WnCl5xnFd8WDPuyc/qO2+Q809qhx?=
 =?iso-8859-1?Q?hO1OXM/dJbmqDJ5erEUssehY6iiW+tX/m7JINgrck453Ul+xBJXqpTsF8y?=
 =?iso-8859-1?Q?n7bYaX49wc/PuHQSUbU6GpeYSNU57i7mhdVgUWTEHIKcOz/zN0oq4YOIFi?=
 =?iso-8859-1?Q?pA/kKlVnI7ScbkHi2AjdOtUI6/MvLqxLkMOOhnraZuYpLf/GO2mDZ8TPZs?=
 =?iso-8859-1?Q?+l2dggxChiJcW5QPGuJ5VlYUC/LhIXZG1pjp/P7STxj1q8dMWpPjB306Dx?=
 =?iso-8859-1?Q?sxitdyBtL8M4LQ2+Kdojogqo+BMY3hqNAoIO+KlAHgZUoiQw91GYQK6GBS?=
 =?iso-8859-1?Q?OgxrHoFjZo6q/UL/F45VK8d4CYQPh5lzX04fyk7PVbBeDml2jYSgEwi8Gl?=
 =?iso-8859-1?Q?PXOdAhiul1CMmRMf8VXDpdECZNSI5MSrr1zr36KA/EdDJF3X/LWS2sEaD5?=
 =?iso-8859-1?Q?WkoNOI0luHQmB17/3Lm0ig5T+71bHy3EU85f22K+U1x1caiYGW9sn8dQCr?=
 =?iso-8859-1?Q?nzOVgHMZa8zFyv1omZo1v4XmgIqUGDdbfa0f2q1vgpzlBq4FGw/nypSkdY?=
 =?iso-8859-1?Q?MN1x4+trBZF3C00SV8KY2hTFVpLwo+nztU3VWgrlxORztZZk14JzSRisNC?=
 =?iso-8859-1?Q?T4oINOoaOWuxtKVpBwvZfNZ180M2mXFiXjeZHm9Xf0bg64+Miya/jk7LVR?=
 =?iso-8859-1?Q?QQwUvFoT2wET+A/MBcGgCNJdGgzUmF0A3wlMnO1Fib+pYmoVdqE7iwjc/m?=
 =?iso-8859-1?Q?50camCQJqMmAWq2z2bQXdEfOXQnCSIocuvQ8mp54tJuXoaYaMlcYfkSa+6?=
 =?iso-8859-1?Q?gHYQ/Ciw721HFyES/au1RUTaFVtsMS6XOPaYxdaMxe7p41gBmj9ew0MFFU?=
 =?iso-8859-1?Q?nKm+7jqZhDp0hsJYTUYF5ljRCvORJ1DMfGqOFkpy11WzfkeZXPkjpkhtvP?=
 =?iso-8859-1?Q?6lu8p4w3TavHwwxBAOMoI4Gqdqua34v0faqiOecTVGOOax44fpm7ZkitfU?=
 =?iso-8859-1?Q?WFt2cSZsbxwCM/mZWlIXPKvpNYJU6due/Ikt4KGPfSWWAnGyn8doalsXRg?=
 =?iso-8859-1?Q?tNNiBXqtmh3pBb2KcOqJ64gTmowD77ma3Fk1mtEvGi/ggbERuXcrwcFWNg?=
 =?iso-8859-1?Q?K581zHvkK6PfAVyx06mDbMqjFQPNESrv0GOzHIfZ+isA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(42112799006)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?uDf0s1TDXYirBM8ntpu6x5I9drct5LeJy5Ulu1hr6qkhMblgSFZL977gy2?=
 =?iso-8859-1?Q?BmUQAv/ks9n0j57l5AW7oWhwRkUhYPkTcZI6AQv6+9r9Admx2PrB2QKjiS?=
 =?iso-8859-1?Q?1+aeCgFv4vDECQJoJKcw/JryNpdFsT4cP5M0HPMR0md+rpvW8V0AwsEn8/?=
 =?iso-8859-1?Q?zaXmVKLWCjP+6vyQYo0kzvuaQLbDEJOZmdcviGESHaULUJwKZ7yom7Mkz3?=
 =?iso-8859-1?Q?e+vYfeD5fulyuVtuBfJdVqVenKd0po1Ga9Q247ETF6vL4B944/lce/0jW9?=
 =?iso-8859-1?Q?Uvj3WBTW2vt2f36WZ2ds+LqvTn96cMJUOhm/U+BbnWNRE+Yq1NzNVU6Dm3?=
 =?iso-8859-1?Q?9vGKUXd1gMlU+SCC5/at3agQT5YKbocKkZQL4qvggzh2Bjvbvc/f9Rtjm9?=
 =?iso-8859-1?Q?TctnXgG54zxA/t3W39C7FSmB2naopAqfpvIjwMpKj0rp21W/q7Kuzutij5?=
 =?iso-8859-1?Q?06cy78mH4AWRHP+jf+wpjbpOEWfF/QP2agURgjMOTt9mYG886MbaHmBZ0d?=
 =?iso-8859-1?Q?Y2r6EnYrNdSTOVy6sru3fFrK5ze1OOg7m1p9S+5NViiBfmxDRh7K7JHI6+?=
 =?iso-8859-1?Q?/ttbOzW82sZQlPkJocVKFiKnPG7OKhPctAPbhhWcSMlBB1p9v9aGO3D11g?=
 =?iso-8859-1?Q?mS3cDWs6kxjSaN4Tzsr0RXcSrbr8fwgViZiXgH/B+pnVvd1iBu7bHYhmSq?=
 =?iso-8859-1?Q?PDj2QzwxwLxbiODiRJQ/FTQqaP8KpoP/G+g7JaM11f7zB0cTH9ZS0K9dPT?=
 =?iso-8859-1?Q?6d8Pb+vg9v76XNWpiKDcqfCjQU4z3E9/KTv/nkMCej7vgJN5uUvIT9tmEF?=
 =?iso-8859-1?Q?BWV8zmg4M5p3uirX3OFB9iPt7+wM9JLdY/RXb6lFX0fL64YP+qGxALrC1A?=
 =?iso-8859-1?Q?mtsZXKiN76WOiiwiOL5psUtLswC/T3MG200xy1bNm2fstZMgCQl+XZapPl?=
 =?iso-8859-1?Q?8QkZ/uc14pMc1M64pFmiPbfELw3Dvl3S5/ay0IgnnYd8NkuBdF9eTaTWYW?=
 =?iso-8859-1?Q?izM33a5BRDmW0ruPpAaU4Z0zTm0hQ6eyJxF4R83IkWjY25IUZZYEolXoKB?=
 =?iso-8859-1?Q?kvoevzceil3crYWiXcuwSC90X/zDneM6luOAJQdqdFrY/JdpIUt0olZQJY?=
 =?iso-8859-1?Q?zLwvnNmL/cGfjzI4qkRSqZYcJ881qDqkdUTtoaqixTvj+9uw5+WlHx2Mtt?=
 =?iso-8859-1?Q?1TAvdS7chorw4bKYsezYGScztsiqVg/X7NzD7wWkx91JVhOkv3bVbF/EXh?=
 =?iso-8859-1?Q?6ODQZf/f+0ucTHE+GuRWIeYUfsj5jpINkUn4eu9FRrGEJeFJjH2sFOV/3r?=
 =?iso-8859-1?Q?zt2VG9GCqCz4Feu4JWxF1UPmqTAlhClJ+AZkPEe0d5Lel4btgNcVrC+YX+?=
 =?iso-8859-1?Q?whCZ/7a65asaFd9qgofYj2Y6ohbyzVCvgAcaH06Q/iWXD2QQmNoIO7goOz?=
 =?iso-8859-1?Q?kqoDlnTN/uvpZXT0HK5/1DfJhDmDpGjUE+UtIxp5/jP0snFLyhbcsO2af3?=
 =?iso-8859-1?Q?sgpRnesc2dOXVH0rij+6yErhAvH5jvIMYy12wgbV6EdNnD2SYMyhnz3wg8?=
 =?iso-8859-1?Q?07+wHlFZ5gYWBJwc8T+H3BcYmHDxdScSyJOCd3EvRJPMX2US1iLrmcPVLV?=
 =?iso-8859-1?Q?+sQPyMj/GgQwQrHR1VHkYE26YvThIoS5wFRhaZHTA/d6Iy25USQuQ4ug?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 796cf9cb-4bca-42dc-1464-08ddeb2ca763
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 20:58:37.5259
 (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: 1d+tL62PTk+OI066BV0TN2Kym9yjAiWb+gEQxipTtknVQP9zxgxPjecwK5uyXwtDG71TnmKTU9PNilf9zYUePHyfruELEMARN3d0MbbAwL4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9607

Hi,

Leonid Komarianskyi  writes:

> To properly deactivate physical eSPI routed to a domain and allow them to
> be retriggered after the initial trigger, the LR needs to be updated. The
> current implementation ignores interrupts outside the range specified by
> the mask 0x3FF, which only covers IRQ numbers up to 1023. To enable
> processing of eSPI interrupts, this patch updates the mask to 0x1FFF.
>
> Signed-off-by: Leonid Komarianskyi 

Reviewed-by: Volodymyr Babchuk 

>
> ---
> Changes in V6:
> - updated mask to 0x1fff to avoid confusion
> - updated commit message
> - removed reviewed-by as new changes requires additional confirmation
>   from reviewers
>
> Changes in V5:
> - no changes
>
> Changes in V4:
> - added reviewed-by from Volodymyr Babchuk
>
> Changes in V3:
> - no changes
>
> Changes in V2:
> - remove unnecessary CONFIG_GICV3_ESPI ifdef guard
> ---
>  xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/includ=
e/asm/gic_v3_defs.h
> index 3370b4cd52..c373b94d19 100644
> --- a/xen/arch/arm/include/asm/gic_v3_defs.h
> +++ b/xen/arch/arm/include/asm/gic_v3_defs.h
> @@ -211,7 +211,7 @@
>  #define ICH_LR_VIRTUAL_SHIFT         0
>  #define ICH_LR_CPUID_MASK            0x7
>  #define ICH_LR_CPUID_SHIFT           10
> -#define ICH_LR_PHYSICAL_MASK         0x3ff
> +#define ICH_LR_PHYSICAL_MASK         0x1fff
>  #define ICH_LR_PHYSICAL_SHIFT        32
>  #define ICH_LR_STATE_MASK            0x3
>  #define ICH_LR_STATE_SHIFT           62

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 21:16:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 21:16:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109033.1458900 (Exim 4.92)
	(envelope-from )
	id 1utuqW-0007Iu-Jl; Wed, 03 Sep 2025 21:16:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109033.1458900; Wed, 03 Sep 2025 21: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 1utuqW-0007In-Gz; Wed, 03 Sep 2025 21:16:48 +0000
Received: by outflank-mailman (input) for mailman id 1109033;
 Wed, 03 Sep 2025 21: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 1utuqV-0007Ih-8o
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 21:16:47 +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 4abcaf9c-890b-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 23:16:44 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DB9PR03MB9830.eurprd03.prod.outlook.com (2603:10a6:10:454::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.28; Wed, 3 Sep
 2025 21:16:41 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 21:16: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: 4abcaf9c-890b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=L9GA4I9blh188EeuGup8JemwrSp+1jcguvDRmISdFafeBUiTAL4zX3GCJcfbRb3lF2/DDppbQDAqdgeBqNBq8MnIaIYaFCPPBdkVAkjFw+aAwZTr+fYJ/Z0t/pplsycR0D8fc1xIGHBgYJScNtJDnDxWgLfJeowbtP61tRjQjHddIvpUxW2B3dp0vdvPgsq9GTw2Y67Q4BYiilEOD5v1OvkxwZLX970wrLMNIk7nH0AHagKuLMmGL+RwKjPg2esopu0gfqdCKHminUwJ6mhXdhS4ctfDzTxhiS2YRSAG8tKGM/uSks83/PG58E+eRjDv+gB/Nwp3xFV+T9PYNVNZXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0a1zuAlAIBP4HVLqb1NGBRoeItRLQdGf0VndQuAWgvg=;
 b=Ef9LJ9RFJ3lyMXadk3S5TiKvdR0cXxe/UCGFii3hzsQ4YTjtWQG+My3q2BNjvVTfUp3kCftvyh8BKFha+1MGFZhY8Jd0cxxBnIE1MMUCetcX8+tJdrDeh1tQFjzXn0aoD7U1/Dw4rBBKd9aQoWuT8J90o4XV5evzhg/uLq4JtnLPl8lUopYdPHT7irPVQf9P2iLQRzEd8BW8Irsznw9hmvlJ9ojSXqqRc/8btlDCFD9X3VNfl+wbk+mR8B6/Q6PJSHX2tUkSfGnbawMkiouOEE3FFHfGEaLVZ9Co4ui+5x0fGthBCgYn4xzMtM87ACXuuLrWENSDCpGdSiXve4+yQA==
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=0a1zuAlAIBP4HVLqb1NGBRoeItRLQdGf0VndQuAWgvg=;
 b=UFh5/0rmosxRg7VaaT7TrAihEqQM38HqB1fsFwANGuRdrcP+uKuW41A/JktlN5PZbFxTvmwSrHkekvRGiLaJB96Zj55qMDTtFkd4/yIg4W1Cc7EPRJ8W5fOHTeb1P1pnUtobQUVDmjUmvPQEI5KYeVbXmftA2nR2iFrJURDkc3BWR15/6z+qu143laE71+j5cgTjl3VkQJsIuH17+P02QLbKHeihz9UwZatEroK8qlwTWUVFQ3wva6bcoJ3fhUBoDAGQ4S0FPW7qu0JjEXOSl8F9gNUYlCqZjPxitOYyEOmk+m9GZOd/Ru/Iuu2Csj3yZfAHMWVMoraWA32NOFR0kg==
From: Leonid Komarianskyi 
To: Volodymyr Babchuk 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Topic: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHN861IdGTmH+JEChpQbSpoZJ2bSB9lSA
Date: Wed, 3 Sep 2025 21:16:40 +0000
Message-ID: <0cd87464-e76f-4d9a-b67c-74354c17996f@epam.com>
References: 
 
 <87a53buufe.fsf@epam.com>
In-Reply-To: <87a53buufe.fsf@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|DB9PR03MB9830:EE_
x-ms-office365-filtering-correlation-id: 16fe7578-b8fd-4b3d-4cbd-08ddeb2f2d0c
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?cllRb3ozNHlpWDBpVWZUdEI3bHdhYWdBQ0VqZ0Y3OG9CS1hXcnpaOVVYVjU3?=
 =?utf-8?B?UFl6TkdsRHQxWHFyNVBRejJ5cUJ0bVBoejRRbEZsd2R1VmYvTEFqTDBCWFA0?=
 =?utf-8?B?TThuUk9JV1RHTHI3TnRrTklZWUpwSU1zNHBQSVZid3U3SUlmNGljS0JWM2or?=
 =?utf-8?B?QjZ6M2xrZ0swUitDeFVNeDlPVTA0ODNjaGQvTDVRN0pmbndXVTM5L0cwQlMr?=
 =?utf-8?B?cnBNdWxncitINmxxZHVaTTduNW5lZTVOclhmNC94VkFMcVBpb29Ydmh0MVFD?=
 =?utf-8?B?VzQreWxXcXd2MVRVWFlBYVg3OFN2V3JCUXpzTzNKaUFyS2x5b014MW03NFBo?=
 =?utf-8?B?aTc4cUJsY2ZQQkFoL1R3N3NCWTJscG02Z2JvaEhkSk5UaW54VHpvNVk2Tmov?=
 =?utf-8?B?cUtRS3NMc2J3ZXcreE5ibWNiNWZJczcyYk5ISWIxR1Z2U0dZVXU2SGhRdTBw?=
 =?utf-8?B?WUZSSEN2Rm9zblhVM3BKVGxLdkNHNlEwd3dBQ3l6Rk9yNXBEcGJqby9mREQz?=
 =?utf-8?B?Y0VtWmZIempiRy9KWFBubkorVjJqZkExZzF2OGtNZHUwelU0YTFoNG84aHhL?=
 =?utf-8?B?NUNhRVdubHRNK2FqUzdRM1BielIwQjRmZ2VXbU1vdUUraTIxRjAvUjZBbEdp?=
 =?utf-8?B?MkxzbzNWNk5Ic0t0NkZjTktNWWN4WHZZaVlmc2NDcDdLdHM3aHNkYmc4NlhS?=
 =?utf-8?B?MUZRcmdpdHdWcEN3c1NNV1hhQzg1VlY1WW5jSlFpNHA5bHB1RTZwY3JqeUhF?=
 =?utf-8?B?M3FNblJZTnk5YlY3bDExWURIanAwbVBxUnhuck93LzZJYVVkd2x4dXFNNG9n?=
 =?utf-8?B?ZlpsMld2cjBiczJmVzdkYVBNVkpZMGFWWldHenBrVjQyczVFNGxjYVplcnhw?=
 =?utf-8?B?b0VWNExLV3F1SDM2UVpGUm5XcTM4R1RqNVRGd050eVR1Q3o0MFl6akUvZStn?=
 =?utf-8?B?UldaT09IT2NhRHVPTkFlOE5jRmZKOGd2eUhub3lGWWNRY2JVbUwvVXJSSHJi?=
 =?utf-8?B?UUxVbU45ZHVFWE9HU2JaalY1aEpqTXIzUUN2MVRtKzN4N080VlpXaUhlbmgw?=
 =?utf-8?B?eC9QT3NydzdQVnJPQ01wUGpuaEZSUUErVEJxbkRScHBGR2dobEVHZWUzRHBq?=
 =?utf-8?B?WVZRbTd2SmQ2ZStQK3dBOTc5dENHb1U3TDl2Tng1NjVVQ0ZxTWVJcWs3NEFi?=
 =?utf-8?B?czNCZUVQMTRQdm5YQyttd3RCVVBCMXlOdjBGT0tGREhQYVVXSnF3b3gwcjY1?=
 =?utf-8?B?MFdqNE5TU2ZUcUR5UXJBUDRKOE1SakMwU0FOSkNLZllJTlg2NlZlcmdOdTN4?=
 =?utf-8?B?TlQzZUtudUFnOEhOL29DSGpVL1h1REVuNUo3WmROQ0Yzc0VOcEtCdHVMeHlz?=
 =?utf-8?B?dUNEZTZMNWxOMFpUWnF4dyt4YzRlSU9DWTN6TmFKK2hHZnBub1BWbGt1TWEw?=
 =?utf-8?B?OXhHaFVwZk1tUCtXKzZtUVljME5tOGNDSzRJdEZIOGN6YzMzc1J1bXlpS1gv?=
 =?utf-8?B?V2cxTElUS0J0S1BTQ3VYZWR2bW9JanRNdFFIdHJTRjhUSjR3Ky9KbXZVWXMw?=
 =?utf-8?B?WnJOUkFzaDluOE1vcXpIYVVOaWhDTFlFVkR3M3c2OVlUb3hNR1JnYTR3LzdR?=
 =?utf-8?B?M2NFUmR2eHExaU1rU0oya1JrN1VvbkphYlA5VUJOcVhwdE13d01NU1Q1eVBu?=
 =?utf-8?B?V0F1T1lJa21meHV4QnE4OEI0Y3RZRkFtdFFOS3loeWZqZWQwWitsNVFrYUYv?=
 =?utf-8?B?cHNmNkpJYlhZRjRNeDdadTZ3NE9MUytqd3NHait2ZDlPUFRFMWNDRlhIM0tG?=
 =?utf-8?B?a0Q3ejhaQi9zbkdnWGppR2RyTThiUmpvMmVKK3docVpXZmJXMVl2VTdTZElx?=
 =?utf-8?B?bUh5aHBHSC9GK0VyY0xJWXBGeDQ1QnVqZzV2WVRkM1NqeFRBVWFSbytBYW96?=
 =?utf-8?B?eTZGYjN0N3loeEJDV2tDL0hsUm9WdXhMRHBRNFhJT3NBenFpeUJnRkdQU25S?=
 =?utf-8?B?TjdjM3NkNVR3PT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.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?NGRLZkhSLzJrZzd5VkdVWEtJK25RQnZOVlFVRXlqUTZuNUh5QXlxMmNpYUhs?=
 =?utf-8?B?NkNTWFlVenBSNTRTdTFrZloxNU5BdVcyMG5wa2JRYUdrN1EwWnVKS1VvODdB?=
 =?utf-8?B?VlVTanhESVdjamw3OG81Nk40T0pYNC9RNXc3bFVUS3RNdXVrLzB6bFZaWXo5?=
 =?utf-8?B?aTB6ZlljM0lkSHFOSHpBTWdQbHQ4RTROZzJJS1Y0cmk1dDQrNGhxcnVIYllJ?=
 =?utf-8?B?Yjhvdm1rNVUzNXVZM1BjSmZqN0dLV281Ync2QmNXWjdZSlZDODNrUkRhc0JD?=
 =?utf-8?B?WXI5b0ZRcjhaQm4rYytLcW5aUlFyaWlJRkZiUHBLL0llV2xaU3dhUzRRUk5H?=
 =?utf-8?B?a24rd3BONXZqckxmQVB0eTE2dTBVRnpXejRtVnhsUkhUd29FUVVoZklobWRo?=
 =?utf-8?B?ZFFnUmFLUkIzSFdtWGFNME5qZFVDOTJnRGJiMm44bTdJdUtBdE9NZmJ2Nlhy?=
 =?utf-8?B?VzlrK1Z5VGk5a3BnYXoxenVSM2NMK25yZGswWXU1TXFkMnduL2Y3d2U1MUVL?=
 =?utf-8?B?TUlhZjVlRmI2K2RJMWQyZi83RU5aSU00TU9aaFpBdTdmSmpldGI1NEZESlNL?=
 =?utf-8?B?djJSZkxSOTgvVC91ak9YVEVsS1BWeU1VR0g2STFWcU9xenlaNGRoYUpZanNJ?=
 =?utf-8?B?Y3o4T3dJMXNWUi9DTEZYa3phRVNFTTNKKzVjbUMvREN2OUkyemJZRGVYVFR0?=
 =?utf-8?B?aUJpYkZjUmJkMmFmSFR5SUdGV2VFL3dadDRNUUNBZGFkbVl0bW9tNlhndGVy?=
 =?utf-8?B?OElqd0g1M1RKa21jWldOVkkvb2c3Sko3alAyL0dRaHU5Y3BMdzBNcnVJTTh4?=
 =?utf-8?B?c2tzL0liQm15eENwOWxlZi9leENsZGVmeE1ZdzFyOFdISUIvTU1OSkpTd01z?=
 =?utf-8?B?akQ3dUVFdUdha1BhYjltekNvYU9UM1o3SXF3aXJxbFZGTlQwSlVGRVdWbkhS?=
 =?utf-8?B?MWFxNnN4KzBCSThYdnE4MzBrL2VDc2diNVNvWlpSang0Y2ZHSlp1Z3FuK1cr?=
 =?utf-8?B?RkNxajUvbUdxUm8zQmlsRmlvQkJNQjdocUFxNWx4b2VWRmJpdXk5aEJRTVJj?=
 =?utf-8?B?TWtaVURiSW9Bak9NZUQySlZxKzZ3RlZQVXkxMnhaUmFwVFMrUFEvMDh3TkRL?=
 =?utf-8?B?RUlnbkZxeEQ4US9CVmY2dDFuVlVxNFZ0SGlrdXR5R2dDTDdJZWc0UGVOQkJO?=
 =?utf-8?B?OHAzN09VV0diZHJGeEtWalc5c2gyTWt1SEZuRHEyb0dYUk1qUlNKc1QvOC90?=
 =?utf-8?B?OUdWL1Rhbk9CYjhTUUNtemNOQkVteVdUT1djZDRjU2JWelBma2lWRzJvMy84?=
 =?utf-8?B?SFl3V0l5bEtIdWhWK3liQ28rRE5XdFVlTmZBQlJYZk9KT09oRTN5SXIxejJH?=
 =?utf-8?B?eU8xcG1SRFprSmgyeStzVGQ0V0NWeDZpSVF5SGtxK3JLUHd5NmFqZkFiMFQw?=
 =?utf-8?B?c0IrU1F4S09LejVtQnk0VXBiY3BYeDlOeUJMd3dYT2pRWmxBZXdzQ3dYb0Fi?=
 =?utf-8?B?VmlhNDViNHpOYWZzek8wbVZWaEEvendpdWFJQnZDbjJCb01pVkFvVXR2ZGtI?=
 =?utf-8?B?VTJzKzZrajFJUXVlUzlxcFRHRzlOQ3gwNzFSUk44eEJEM1pjYWVvWnJCaE1R?=
 =?utf-8?B?WW5Dekd6Z1hWK1NoZVdoRmRJcnRoaVlOQ1VKUkpnejJXOWJweVdoejJUNXl5?=
 =?utf-8?B?d3A2VWErZm1LTkg1UmxIY2VBcFNoMGFwNW1HaUc5c29GSEhjYmNIaWtVSVh5?=
 =?utf-8?B?N0g0NEZ0dUFMdFRPeGUvc0hFVDdXazhKOUhLM1RqcmhFL1g1ZEIzK0c3N3hz?=
 =?utf-8?B?L1Z1SXVRK0NoMnZYYW5nN0tKdGlkeUMzNFljMEp1aXNZS1RzaERKOVZTRW9m?=
 =?utf-8?B?ZE9zSXg3RmUzcUxLOGh0UkFoWkFtcEdzcCtBSHh3RTliSWxpMHNNWHU2WEta?=
 =?utf-8?B?QmcrVzVJMTJPNHZlbXhHdHI1ZVFuM1d6emRhMFdUb1JyUTFhaHV3QUNUWXNh?=
 =?utf-8?B?SU1uLzFraDV3alg2d3FDOVpxN1U5VHBoL1VJN3dYaWU4Q0NZUzJ3am5DVFhh?=
 =?utf-8?B?bXNvRGRwVFlDVHoxUEpSMzBOaFFHRzBNRWh4MlpwMmsrKzRJa25wVENjT3dW?=
 =?utf-8?B?V0o0ekttbVZuclNNZnZ5dDdUSUxhbnFiZ2NocWZlUjdwZEZqb2I5M1FYWVJs?=
 =?utf-8?Q?MTrDAGlJQK/ZIHwz2RLKaao=3D?=
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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 16fe7578-b8fd-4b3d-4cbd-08ddeb2f2d0c
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 21:16:40.7451
 (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: YzzJUOT3K+fKEWQHvb/Ce8ipjZ33jDjJRnFHsrGmkC66YWtUCCvUMDfXNXo29b0vQEkpd4S3CDoTpAP4igEr0SLDjqX0ltAFPsmTU1mI040=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9830

SGkgVm9sb2R5bXlyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY2xvc2UgcmV2aWV3IGFuZCBmb3Ig
eW91ciB0aW1lIHdoaWxlIHJldmlld2luZyBzbyANCm1hbnkgdmVyc2lvbnMuDQoNCk9uIDAzLjA5
LjI1IDIzOjU2LCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4gSGkgTGVvbmlkLA0KPiANCj4g
TGVvbmlkIEtvbWFyaWFuc2t5aSA8TGVvbmlkX0tvbWFyaWFuc2t5aUBlcGFtLmNvbT4gd3JpdGVz
Og0KPiANCj4+IEN1cnJlbnRseSwgWGVuIGRvZXMgbm90IHN1cHBvcnQgZVNQSSBpbnRlcnJ1cHRz
LCBsZWFkaW5nDQo+PiB0byBhIGRhdGEgYWJvcnQgd2hlbiBzdWNoIGludGVycnVwdHMgYXJlIGRl
ZmluZWQgaW4gdGhlIERUUy4NCj4+DQo+PiBUaGlzIHBhdGNoIGludHJvZHVjZXMgYSBzZXBhcmF0
ZSBhcnJheSB0byBpbml0aWFsaXplIHVwIHRvDQo+PiAxMDI0IGludGVycnVwdCBkZXNjcmlwdG9y
cyBpbiB0aGUgZVNQSSByYW5nZSBhbmQgYWRkcyB0aGUNCj4+IG5lY2Vzc2FyeSBkZWZpbmVzIGFu
ZCBoZWxwZXIgZnVuY3Rpb24uIFRoZXNlIGNoYW5nZXMgbGF5IHRoZQ0KPj4gZ3JvdW5kd29yayBm
b3IgZnV0dXJlIGltcGxlbWVudGF0aW9uIG9mIGZ1bGwgZVNQSSBpbnRlcnJ1cHQNCj4+IHN1cHBv
cnQuIEFzIHRoaXMgR0lDdjMuMSBmZWF0dXJlIGlzIG5vdCByZXF1aXJlZCBieSBhbGwgdmVuZG9y
cywNCj4+IGFsbCBjaGFuZ2VzIGFyZSBndWFyZGVkIGJ5IGlmZGVmcywgZGVwZW5kaW5nIG9uIHRo
ZSBjb3JyZXNwb25kaW5nDQo+PiBLY29uZmlnIG9wdGlvbi4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5
OiBMZW9uaWQgS29tYXJpYW5za3lpIDxsZW9uaWRfa29tYXJpYW5za3lpQGVwYW0uY29tPg0KPj4N
Cj4+IC0tLQ0KPj4gQ2hhbmdlcyBpbiBWNjoNCj4+IC0gYWRkZWQgYW4gYXNzZXJ0IGluIGlzX2Vz
cGkoKSB3aGVuIENPTkZJR19HSUNWM19FU1BJPW4gdG8gZW5zdXJlIHRoYXQNCj4+ICAgIG91dC1v
Zi1yYW5nZSBhcnJheSByZXNvdXJjZXMgYXJlIG5vdCBhY2Nlc3NlZCwgZS5nLiwgaW4gX19pcnFf
dG9fZGVzYygpDQo+PiAtIHJlbW92ZWQgdW5uZWNlc3NhcnkgcGFyZW50aGVzZXMgaW4gaXNfZXNw
aSgpDQo+PiAtIGNvbnZlcnRlZCBoZWxwZXIgbWFjcm8gdG8gaW5saW5lIGZ1bmN0aW9ucyBhbmQg
YWRkZWQgc2FuaXR5IGNoZWNrcw0KPj4gICAgd2l0aCBBU1NFUlRzIHRvIHRoZW0NCj4+IC0gZGVm
aW5lZCBlc3BpX3RvX2Rlc2MgZm9yIG5vbi1lU1BJIGJ1aWxkcyBhcyBhIHByb3RvdHlwZQ0KPj4g
LSB1cGRhdGVzIHRoZSBjb21tZW50cw0KPj4gLSB1c2VkIHRoZSBJU19FTkFCTEVEKENPTkZJR19H
SUNWM19FU1BJKSBtYWNybyB0byBpbml0aWFsaXplIG5yX2lycXMNCj4+DQo+PiBDaGFuZ2VzIGlu
IFY1Og0KPj4gLSBubyBmdW5jdGlvbmFsIGNoYW5nZXMgaW50cm9kdWNlZCBieSB0aGlzIHZlcnNp
b24gY29tcGFyZWQgd2l0aCBWNCwgb25seQ0KPj4gICAgbWlub3IgZml4ZXMgYW5kIHJlbW92YWwg
b2YgaWZkZWZzIGZvciBtYWNyb3Nlcw0KPj4gLSBhZGRlZCBUT0RPIGNvbW1lbnQsIHN1Z2dlc3Rl
ZCBieSBPbGVrc2FuZHIgVHlzaGNoZW5rbw0KPj4gLSBjaGFuZ2VkIGludCB0byB1bnNpZ25lZCBp
bnQgZm9yIGlycXMNCj4+IC0gcmVtb3ZlZCBpZmRlZnMgZm9yIGVTUEktc3BlY2lmaWMgZGVmaW5l
cyBhbmQgbWFjcm9zIHRvIHJlZHVjZSB0aGUNCj4+ICAgIG51bWJlciBvZiBpZmRlZnMgYW5kIGNv
ZGUgZHVwbGljYXRpb24gaW4gZnVydGhlciBjaGFuZ2VzDQo+PiAtIHJlbW92ZWQgcmV2aWV3ZWQt
YnkgYXMgbW92aW5nIGRlZmluZXMgZnJvbSBpZmRlZnMgcmVxdWlyZXMgYWRkaXRpb25hbA0KPj4g
ICAgY29uZmlybWF0aW9uIGZyb20gcmV2aWV3ZXJzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWNDoNCj4+
IC0gcmVtb3ZlZCByZWR1bmRhbnQgbGluZSB3aXRoICdkZWZhdWx0IG4nIGluIEtjb25maWcsIGFz
IGl0IGlzIGRpc2FibGVkDQo+PiAgICBieSBkZWZhdWx0LCB3aXRob3V0IGV4cGxpY2l0IHNwZWNp
ZmljYXRpb24NCj4+IC0gYWRkZWQgcmV2aWV3ZWQtYnkgZnJvbSBWb2xvZHlteXIgQmFiY2h1aw0K
Pj4NCj4+IENoYW5nZXMgaW4gVjM6DQo+PiAtIGludHJvZHVjZWQgYSBuZXcgZGVmaW5lIE5SX0VT
UElfSVJRUyB0byBhdm9pZCBjb25mdXNpb24sIGxpa2UgaW4gdGhlDQo+PiAgICBjYXNlIG9mIHVz
aW5nIE5SX0lSUVMgZm9yIGVzcGlfZGVzYyBhcnJheQ0KPj4gLSBpbXBsZW1lbnRlZCBoZWxwZXIg
ZnVuY3Rpb25zIGVzcGlfdG9fZGVzYyBhbmQgaW5pdF9lc3BpX2RhdGEgdG8gbWFrZQ0KPj4gICAg
aXQgcG9zc2libGUgdG8gYWRkIHN0dWJzIHdpdGggdGhlIHNhbWUgbmFtZSwgYW5kIGFzIGEgcmVz
dWx0LCByZWR1Y2UNCj4+ICAgIHRoZSBudW1iZXIgb2YgI2lmZGVmcw0KPj4gLSBkaXNhYmxlIENP
TkZJR19HSUNWM19FU1BJIGRlZmF1bHQgdmFsdWUgdG8gbg0KPj4NCj4+IENoYW5nZXMgaW4gVjI6
DQo+PiAtIHVzZSAoRVNQSV9NQVhfSU5USUQgKyAxKSBpbnN0ZWFkIG9mIChFU1BJX0JBU0VfSU5U
SUQgKyBOUl9JUlFTKQ0KPj4gLSByZW1vdmUgdW5uZWNlc3NhcnkgY29tbWVudCBmb3IgbnJfaXJx
cyBpbml0aWFsaXphdGlvbg0KPj4gLS0tDQo+PiAgIHhlbi9hcmNoL2FybS9LY29uZmlnICAgICAg
ICAgICB8ICA4ICsrKysrDQo+PiAgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEuaCB8IDM3
ICsrKysrKysrKysrKysrKysrKysrKysrKw0KPj4gICB4ZW4vYXJjaC9hcm0vaXJxLmMgICAgICAg
ICAgICAgfCA1MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tDQo+PiAgIDMgZmls
ZXMgY2hhbmdlZCwgOTYgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZm
IC0tZ2l0IGEveGVuL2FyY2gvYXJtL0tjb25maWcgYi94ZW4vYXJjaC9hcm0vS2NvbmZpZw0KPj4g
aW5kZXggMTdkZjE0N2IyNS4uNDNiMDU1MzNiMSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2Fy
bS9LY29uZmlnDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vS2NvbmZpZw0KPj4gQEAgLTEzNSw2ICsx
MzUsMTQgQEAgY29uZmlnIEdJQ1YzDQo+PiAgIAkgIERyaXZlciBmb3IgdGhlIEFSTSBHZW5lcmlj
IEludGVycnVwdCBDb250cm9sbGVyIHYzLg0KPj4gICAJICBJZiB1bnN1cmUsIHVzZSB0aGUgZGVm
YXVsdCBzZXR0aW5nLg0KPj4gICANCj4+ICtjb25maWcgR0lDVjNfRVNQSQ0KPj4gKwlib29sICJF
eHRlbmRlZCBTUEkgcmFuZ2Ugc3VwcG9ydCINCj4+ICsJZGVwZW5kcyBvbiBHSUNWMyAmJiAhTkVX
X1ZHSUMNCj4+ICsJaGVscA0KPj4gKwkgIEFsbG93IFhlbiBhbmQgZG9tYWlucyB0byB1c2UgaW50
ZXJydXB0IG51bWJlcnMgZnJvbSB0aGUgZXh0ZW5kZWQgU1BJDQo+PiArCSAgcmFuZ2UsIGZyb20g
NDA5NiB0byA1MTE5LiBUaGlzIGZlYXR1cmUgaXMgaW50cm9kdWNlZCBpbiBHSUN2My4xDQo+PiAr
CSAgYXJjaGl0ZWN0dXJlLg0KPj4gKw0KPj4gICBjb25maWcgSEFTX0lUUw0KPj4gICAgICAgICAg
IGJvb2wgIkdJQ3YzIElUUyBNU0kgY29udHJvbGxlciBzdXBwb3J0IChVTlNVUFBPUlRFRCkiIGlm
IFVOU1VQUE9SVEVEDQo+PiAgICAgICAgICAgZGVwZW5kcyBvbiBHSUNWMyAmJiAhTkVXX1ZHSUMg
JiYgIUFSTV8zMg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEu
aCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEuaA0KPj4gaW5kZXggNWJjNjQ3NWViNC4u
ZjRkMDk5NzY1MSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEu
aA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oDQo+PiBAQCAtMzIsNiAr
MzIsMTAgQEAgc3RydWN0IGFyY2hfaXJxX2Rlc2Mgew0KPj4gICAjZGVmaW5lIFNQSV9NQVhfSU5U
SUQgICAxMDE5DQo+PiAgICNkZWZpbmUgTFBJX09GRlNFVCAgICAgIDgxOTINCj4+ICAgDQo+PiAr
I2RlZmluZSBFU1BJX0JBU0VfSU5USUQgNDA5Ng0KPj4gKyNkZWZpbmUgRVNQSV9NQVhfSU5USUQg
IDUxMTkNCj4+ICsjZGVmaW5lIE5SX0VTUElfSVJRUyAgICAxMDI0DQo+PiArDQo+PiAgIC8qIExQ
SXMgYXJlIGFsd2F5cyBudW1iZXJlZCBzdGFydGluZyBhdCA4MTkyLCBzbyAwIGlzIGEgZ29vZCBp
bnZhbGlkIGNhc2UuICovDQo+PiAgICNkZWZpbmUgSU5WQUxJRF9MUEkgICAgIDANCj4+ICAgDQo+
PiBAQCAtMzksNyArNDMsMTIgQEAgc3RydWN0IGFyY2hfaXJxX2Rlc2Mgew0KPj4gICAjZGVmaW5l
IElOVkFMSURfSVJRICAgICAxMDIzDQo+PiAgIA0KPj4gICBleHRlcm4gY29uc3QgdW5zaWduZWQg
aW50IG5yX2lycXM7DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiArLyogVGhpcyB3
aWxsIGNvdmVyIHRoZSBlU1BJIHJhbmdlLCB0byBhbGxvdyBhc2lnbm1hbnQgb2YgZVNQSXMgdG8g
ZG9tYWlucy4gKi8NCj4+ICsjZGVmaW5lIG5yX3N0YXRpY19pcnFzIChFU1BJX01BWF9JTlRJRCAr
IDEpDQo+PiArI2Vsc2UNCj4+ICAgI2RlZmluZSBucl9zdGF0aWNfaXJxcyBOUl9JUlFTDQo+PiAr
I2VuZGlmDQo+PiAgIA0KPj4gICBzdHJ1Y3QgaXJxX2Rlc2M7DQo+PiAgIHN0cnVjdCBpcnFhY3Rp
b247DQo+PiBAQCAtNTUsNiArNjQsMzQgQEAgc3RhdGljIGlubGluZSBib29sIGlzX2xwaSh1bnNp
Z25lZCBpbnQgaXJxKQ0KPj4gICAgICAgcmV0dXJuIGlycSA+PSBMUElfT0ZGU0VUOw0KPj4gICB9
DQo+PiAgIA0KPj4gK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IGVzcGlfaW50aWRfdG9faWR4
KHVuc2lnbmVkIGludCBpbnRpZCkNCj4+ICt7DQo+PiArICAgIEFTU0VSVChpbnRpZCA+PSBFU1BJ
X0JBU0VfSU5USUQgJiYgaW50aWQgPD0gRVNQSV9NQVhfSU5USUQpOw0KPj4gKyAgICByZXR1cm4g
aW50aWQgLSBFU1BJX0JBU0VfSU5USUQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUg
dW5zaWduZWQgaW50IGVzcGlfaWR4X3RvX2ludGlkKHVuc2lnbmVkIGludCBpZHgpDQo+PiArew0K
Pj4gKyAgICBBU1NFUlQoaWR4IDw9IE5SX0VTUElfSVJRUyk7DQo+PiArICAgIHJldHVybiBpZHgg
KyBFU1BJX0JBU0VfSU5USUQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgYm9vbCBp
c19lc3BpKHVuc2lnbmVkIGludCBpcnEpDQo+PiArew0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNf
RVNQSQ0KPj4gKyAgICByZXR1cm4gaXJxID49IEVTUElfQkFTRV9JTlRJRCAmJiBpcnEgPD0gRVNQ
SV9NQVhfSU5USUQ7DQo+PiArI2Vsc2UNCj4+ICsgICAgLyoNCj4+ICsgICAgICogVGhlIGZ1bmN0
aW9uIHNob3VsZCBub3QgYmUgY2FsbGVkIGZvciBlU1BJcyB3aGVuIENPTkZJR19HSUNWM19FU1BJ
IGlzDQo+PiArICAgICAqIGRpc2FibGVkLiBSZXR1cm5pbmcgZmFsc2UgYWxsb3dzIHRoZSBjb21w
aWxlciB0byBvcHRpbWl6ZSB0aGUgY29kZQ0KPj4gKyAgICAgKiB3aGVuIHRoZSBjb25maWcgaXMg
ZGlzYWJsZWQsIHdoaWxlIHRoZSBhc3NlcnQgZW5zdXJlcyB0aGF0IG91dC1vZi1yYW5nZQ0KPj4g
KyAgICAgKiBhcnJheSByZXNvdXJjZXMgYXJlIG5vdCBhY2Nlc3NlZCwgZS5nLiwgaW4gX19pcnFf
dG9fZGVzYygpLg0KPj4gKyAgICAgKi8NCj4+ICsgICAgQVNTRVJUKGlycSA+PSBFU1BJX0JBU0Vf
SU5USUQpOw0KPiANCj4gVGhpcyByZWFsbHkgcHV6emxlcyBtZS4gU2hvdWxkIGl0IGJlIG90aGVy
IHdheSBhcm91bmQ/IEkuZS4NCj4gDQo+IEFTU0VSVChpcnEgPCBFU1BJX0JBU0VfSU5USUQpID8g
T3IgZXZlbiBBU1NFUlQoaXJxIDw9IDEwMjIpID8NCj4gDQo+IEFjdHVhbGx5LCBJIHRyaWVkIHRv
IHlvdXIgc2VyaWVzLiBYRU4gZG9lcyBub3QgYm9vdHMgYXQgYWxsIHdoZW4NCj4gQ09ORklHX0dJ
Q1YzX0VTUEk9bi4gTG9va3MgbGlrZSBpdCBwYW5pY3MgZXZlbiBiZWZvcmUgaXQgY2FuIGJyaW5n
IHVwDQo+IHRoZSBjb25zb2xlLCBhcyBJIGRvbid0IHNlZSBhbnkgcHJpbnRzIGluIFFFTVUuIE5v
bi1kZWJ1ZyBidWlsZCBib290cw0KPiBmaW5lLCB0aG91Z2h0LCBidXQgdGhpcyBpcyBleHBlY3Rl
ZCwgYXMgQVNTRVJUcyBhcmUgZGlzYWJsZWQuDQo+IA0KPiANCg0KWWVzLCBpdCdzIG15IGJhZCwg
SSByZWFsbHkgYXBvbG9naXplIGZvciB0aGF0LiBJdCBpcyBhIGNyaXRpY2FsIGlzc3VlLiANCkl0
IHNob3VsZCBkZWZpbml0ZWx5IGJlIGF0IGxlYXN0IGlycSA8IEVTUElfQkFTRV9JTlRJRC4uLg0K
DQo+PiArICAgIHJldHVybiBmYWxzZTsNCj4+ICsjZW5kaWYNCj4+ICt9DQo+PiArDQo+PiAgICNk
ZWZpbmUgZG9tYWluX3BpcnFfdG9faXJxKGQsIHBpcnEpIChwaXJxKQ0KPj4gICANCj4+ICAgYm9v
bCBpc19hc3NpZ25hYmxlX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsNCj4+IGRpZmYgLS1naXQgYS94
ZW4vYXJjaC9hcm0vaXJxLmMgYi94ZW4vYXJjaC9hcm0vaXJxLmMNCj4+IGluZGV4IGI4ZWNjZmM5
MjQuLmM5MzRkMzliZjYgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaXJxLmMNCj4+ICsr
KyBiL3hlbi9hcmNoL2FybS9pcnEuYw0KPj4gQEAgLTE5LDcgKzE5LDkgQEANCj4+ICAgI2luY2x1
ZGUgPGFzbS9naWMuaD4NCj4+ICAgI2luY2x1ZGUgPGFzbS92Z2ljLmg+DQo+PiAgIA0KPj4gLWNv
bnN0IHVuc2lnbmVkIGludCBucl9pcnFzID0gTlJfSVJRUzsNCj4+ICtjb25zdCB1bnNpZ25lZCBp
bnQgbnJfaXJxcyA9IElTX0VOQUJMRUQoQ09ORklHX0dJQ1YzX0VTUEkpID8NCj4+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEVTUElfTUFYX0lOVElEICsgMSkgOg0K
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOUl9JUlFTOw0KPj4g
ICANCj4+ICAgc3RhdGljIHVuc2lnbmVkIGludCBsb2NhbF9pcnFzX3R5cGVbTlJfTE9DQUxfSVJR
U107DQo+PiAgIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0sobG9jYWxfaXJxc190eXBlX2xvY2spOw0K
Pj4gQEAgLTQ2LDYgKzQ4LDUwIEBAIHZvaWQgaXJxX2VuZF9ub25lKHN0cnVjdCBpcnFfZGVzYyAq
aXJxKQ0KPj4gICB9DQo+PiAgIA0KPj4gICBzdGF0aWMgaXJxX2Rlc2NfdCBpcnFfZGVzY1tOUl9J
UlFTIC0gTlJfTE9DQUxfSVJRU107DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiAr
LyogVE9ETzogQ29uc2lkZXIgYWxsb2NhdGluZyBhbiBhcnJheSBkeW5hbWljYWxseSAqLw0KPiAN
Cj4gSSdkIGNvbnNpZGVyZWQgdXNpbmcgcmFkaXggdHJlZSwgaG9uZXN0bHkuLi4gQnV0IHRoaXMg
aXMganVzdCB0b3BpYyBmb3INCj4gZGlzY3Vzc2lvbiwgbm8gYWN0aW9uIHNob3VsZCBiZSB0YWtl
biBoZXJlLg0KPiANCj4+ICtzdGF0aWMgaXJxX2Rlc2NfdCBlc3BpX2Rlc2NbTlJfRVNQSV9JUlFT
XTsNCj4+ICsNCj4+ICtzdGF0aWMgc3RydWN0IGlycV9kZXNjICplc3BpX3RvX2Rlc2ModW5zaWdu
ZWQgaW50IGlycSkNCj4+ICt7DQo+PiArICAgIHJldHVybiAmZXNwaV9kZXNjW2VzcGlfaW50aWRf
dG9faWR4KGlycSldOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IF9faW5pdCBpbml0X2Vz
cGlfZGF0YSh2b2lkKQ0KPj4gK3sNCj4+ICsgICAgdW5zaWduZWQgaW50IGlycTsNCj4+ICsNCj4+
ICsgICAgZm9yICggaXJxID0gRVNQSV9CQVNFX0lOVElEOyBpcnEgPD0gRVNQSV9NQVhfSU5USUQ7
IGlycSsrICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjID0g
aXJxX3RvX2Rlc2MoaXJxKTsNCj4+ICsgICAgICAgIGludCByYyA9IGluaXRfb25lX2lycV9kZXNj
KGRlc2MpOw0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCByYyApDQo+PiArICAgICAgICAgICAgcmV0
dXJuIHJjOw0KPj4gKw0KPj4gKyAgICAgICAgZGVzYy0+aXJxID0gaXJxOw0KPj4gKyAgICAgICAg
ZGVzYy0+YWN0aW9uICA9IE5VTEw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7
DQo+PiArfQ0KPj4gKyNlbHNlDQo+PiArLyoNCj4+ICsgKiBEZWZpbmVkIGFzIGEgcHJvdG90eXBl
IGFzIGl0IHNob3VsZCBub3QgYmUgY2FsbGVkIGlmIENPTkZJR19HSUNWM19FU1BJPW4uDQo+PiAr
ICogV2l0aG91dCBDT05GSUdfR0lDVjNfRVNQSSwgdGhlIGFkZGl0aW9uYWwgMTAyNCBJUlEgZGVz
Y3JpcHRvcnMgd2lsbCBub3QNCj4+ICsgKiBiZSBkZWZpbmVkLCBhbmQgdGh1cywgdGhleSBjYW5u
b3QgYmUgdXNlZC4gVW5sZXNzIElOVElEcyBmcm9tIHRoZSBlU1BJDQo+PiArICogcmFuZ2UgYXJl
IG1pc3Rha2VubHkgZGVmaW5lZCBpbiBYZW4gRFRTIHdoZW4gdGhlIGFwcHJvcHJpYXRlIGNvbmZp
ZyBpcw0KPj4gKyAqIGRpc2FibGVkLCB0aGlzIGZ1bmN0aW9uIHdpbGwgbm90IGJlIHJlYWNoZWQg
YmVjYXVzZSBpc19lc3BpIHdpbGwgcmV0dXJuDQo+PiArICogZmFsc2UgZm9yIG5vbi1lU1BJIElO
VElEcy4NCj4+ICsgKi8NCj4+ICtzdHJ1Y3QgaXJxX2Rlc2MgKmVzcGlfdG9fZGVzYyh1bnNpZ25l
ZCBpbnQgaXJxKTsNCj4+ICsNCj4+ICtzdGF0aWMgaW50IF9faW5pdCBpbml0X2VzcGlfZGF0YSh2
b2lkKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKyNlbmRpZg0KPj4gKw0K
Pj4gICBzdGF0aWMgREVGSU5FX1BFUl9DUFUoaXJxX2Rlc2NfdFtOUl9MT0NBTF9JUlFTXSwgbG9j
YWxfaXJxX2Rlc2MpOw0KPj4gICANCj4+ICAgc3RydWN0IGlycV9kZXNjICpfX2lycV90b19kZXNj
KHVuc2lnbmVkIGludCBpcnEpDQo+PiBAQCAtNTMsNiArOTksOSBAQCBzdHJ1Y3QgaXJxX2Rlc2Mg
Kl9faXJxX3RvX2Rlc2ModW5zaWduZWQgaW50IGlycSkNCj4+ICAgICAgIGlmICggaXJxIDwgTlJf
TE9DQUxfSVJRUyApDQo+PiAgICAgICAgICAgcmV0dXJuICZ0aGlzX2NwdShsb2NhbF9pcnFfZGVz
YylbaXJxXTsNCj4+ICAgDQo+PiArICAgIGlmICggaXNfZXNwaShpcnEpICkNCj4+ICsgICAgICAg
IHJldHVybiBlc3BpX3RvX2Rlc2MoaXJxKTsNCj4+ICsNCj4+ICAgICAgIHJldHVybiAmaXJxX2Rl
c2NbaXJxLU5SX0xPQ0FMX0lSUVNdOw0KPj4gICB9DQo+PiAgIA0KPj4gQEAgLTc5LDcgKzEyOCw3
IEBAIHN0YXRpYyBpbnQgX19pbml0IGluaXRfaXJxX2RhdGEodm9pZCkNCj4+ICAgICAgICAgICBk
ZXNjLT5hY3Rpb24gID0gTlVMTDsNCj4+ICAgICAgIH0NCj4+ICAgDQo+PiAtICAgIHJldHVybiAw
Ow0KPj4gKyAgICByZXR1cm4gaW5pdF9lc3BpX2RhdGEoKTsNCj4+ICAgfQ0KPj4gICANCj4+ICAg
c3RhdGljIGludCBpbml0X2xvY2FsX2lycV9kYXRhKHVuc2lnbmVkIGludCBjcHUpDQo+IA0KDQpC
ZXN0IHJlZ2FyZHMsDQpMZW9uaWQNCg==


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 21:24:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 21:24:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109044.1458912 (Exim 4.92)
	(envelope-from )
	id 1utuxm-0000WS-CG; Wed, 03 Sep 2025 21:24:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109044.1458912; Wed, 03 Sep 2025 21:24: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 1utuxm-0000WL-7J; Wed, 03 Sep 2025 21:24:18 +0000
Received: by outflank-mailman (input) for mailman id 1109044;
 Wed, 03 Sep 2025 21:24:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1utuxk-0000WA-OQ
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 21:24:16 +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 56f19c80-890c-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 23:24:15 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 2432443BB0;
 Wed,  3 Sep 2025 21:24:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A5A8C4CEE7;
 Wed,  3 Sep 2025 21:24:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 56f19c80-890c-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1756934653;
	bh=4ydoQzsD8lA4FQhV7XYcqKPlZVew2J4b25z3LTMEbVk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JqgT8NPjd5nhFDt+Cja8QI4wpCVoE111028UHw6U+rKX+lh+4MRak38x1nl/0Tj3N
	 mN8YnBQWA+VjEFa078CO3AiiYO/1RQNcyXoU6bWDM3/2gyc0SkyBp4cFmNWmM6Qxl7
	 n3yoMzd0pG5kSYLJb98JDJjl9rAHBs4uNtFhOvolKJO/vadFkyxwtyQzMHvr5oPuiZ
	 xYzZipop0ph1uWSetrAUzNGi4RYW8yJsnfKtdSFS64DzKMNXQAH1pf430ljFCADWqS
	 OJANKrJLzNEvYDrzjSZ2aKu1ZQTfu78Jn91R1qGbheqN1Yjx1omHezvVthxdTFfqPX
	 BoJwDWe7Y/1nw==
Date: Wed, 3 Sep 2025 14:24:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
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?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
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

Hi Oleksii,

It is still not passing the ci-loop, this time due to MISRA. See the two
new 8.3 and 8.4 violations (previously zero) and also new additional
12.2, 13.1 violations:

https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/2020545544

https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/11238076156/PROJECT.ecd;/by_service.html#service&kind

per comparison, this is the baseline:
https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/ARM64/11232061644/PROJECT.ecd;/by_service.html#service&kind

These are the new 8.3 and 8.4 violations:

https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/11238076156/PROJECT.ecd;/by_service/MC3A2.R8.3.html#{%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}]}}}

https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/11238076156/PROJECT.ecd;/by_service/MC3A2.R8.4.html#{%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}]}}}

Cheers,

Stefano

On Wed, 3 Sep 2025, Oleksii Moisieiev wrote:
> 
> Inroducing V8 patch series  on top of the Xen version 4.20-rc2
> which includes implementation of the SCI SCMI SMC single-agent support.
> 
> This patch series is the first chunk of the
> "xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
> be found at [0]
> 
> SCMI-multiagent support will be provided as the followup patch series.
> 
> [0] https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/
> 
> Patch 1 "xen/arm: add generic SCI subsystem"
> - rebased and refactored
> - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
> instead of custom,
>   linker sections based implementation.
> - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
> dom0 code directly.
> - RFC changes in XEN_DOMCTL_assign_device OP processing
> - Introduce arch_handle_passthrough_prop call to handle arm specific
> nodes
> 
> Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
> - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI
> over SMC calls
> handling layer") be used under sci subsystem.
> - no functional changes in general
> 
> Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
> This is new change which allows passthrough SCMI SMC, single agent interface to
> guest domain
> cover use case "thin Dom0 with guest domain, which serves as Driver domain".
> See patch commit message for full description.
> 
> Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
> driver
> - add documentation section for Simple Arm SCMI over SMC calls
> forwarding driver.
> 
> Code can be found at:
> https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5
> 
> [1] RFC v2:
> http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/
> [2] RFC v3:
> https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927-1-grygorii_strashko@epam.com
> SCMI spec:
> https://developer.arm.com/documentation/den0056/e/?lang=en
> 
> SCMI bindings:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
> 
> Reference EL3 FW:
> RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
> Renesas v4h:
> https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/
> 
> base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)
> 
> Changes in v8:
> - reneregated {helpers/types}.gen.go, dropped unneeded parameters
> 
> Changes in v7:
> - fix sci_handl_call to make changes more readable
> - fix build error when DOM0LESS_BUILD is disabled (removed
>  arch_handle_passthrough_prop from the header)
> - sort headers in alphabetical order in sci.h
> - sort headers in scmi-smc.c file
> - Fix commit description.
> - Move scmi-smc-passthrough definition to match alphaberical order
> - remove unneeded initialization with NULL
> - changed u64 to uint64_t
> - Send warning if iomem permit access was failed
> - fixed typos
> 
> Changes in v6:
> - rebase on top of the latest master
> - fix return value of sci_dt_finalize() call
> - add R-b tag
> - added generated helpers and types go files
> - rename cmdline parameter to scmi-smc-passthrough
> - fix goto tag in parse_arm_sci_config
> - add link to the scmi bindings used in the doc
> - remove mentions about HVC calls from doc
> - rename cmdline parameter to scmi-smc-passthrough
> 
> Changes in v5:
> - update Maintainers file. Set role as a Reviewer
> - rebased on the latest master branch
> - Introduce arch_handle_passthrough_prop call to handle arm specific nodes
> - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
> - rename dom0_scmi_smc_passthrough in documentation
> 
> Changes in v4:
> - fix SPDX-License
> - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
> - move XEN_DOMCTL_assign_device code in separate patch
> - Add documentation for SCI SCMI drivers
> - xl.cfg doc
> - fix comments from Stefano Stabellini
> - fix toolstack code as sugested by Anthony PERARD
>   - use MATCH_OPTION()
>   - move arm_sci struct and cfg params in "arch_arm"
> - add SCMI passthrough for dom0less case
> 
> Grygorii Strashko (3):
>   xen/arm: scmi-smc: update to be used under sci subsystem
>   xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
>   docs: arm: add docs for SCMI over SMC calls forwarding driver
> 
> Oleksii Moisieiev (1):
>   xen/arm: add generic SCI subsystem
> 
>  MAINTAINERS                                   |   6 +
>  .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
>  docs/hypervisor-guide/arm/index.rst           |   9 +
>  docs/hypervisor-guide/index.rst               |   1 +
>  docs/man/xl.cfg.5.pod.in                      |  34 +++
>  docs/misc/arm/device-tree/booting.txt         |  15 ++
>  docs/misc/xen-command-line.pandoc             |   9 +
>  tools/golang/xenlight/helpers.gen.go          |  35 +++
>  tools/golang/xenlight/types.gen.go            |  11 +
>  tools/include/libxl.h                         |   5 +
>  tools/libs/light/libxl_arm.c                  |  14 ++
>  tools/libs/light/libxl_types.idl              |  10 +
>  tools/xl/xl_parse.c                           |  36 ++++
>  xen/arch/arm/device.c                         |   5 +
>  xen/arch/arm/dom0less-build.c                 |  40 ++++
>  xen/arch/arm/domain.c                         |  12 +-
>  xen/arch/arm/domain_build.c                   |   8 +
>  xen/arch/arm/firmware/Kconfig                 |  25 ++-
>  xen/arch/arm/firmware/Makefile                |   1 +
>  xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
>  xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
>  xen/arch/arm/include/asm/domain.h             |   5 +
>  xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
>  xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
>  xen/arch/arm/vsmc.c                           |   4 +-
>  xen/common/device-tree/dom0less-build.c       |   4 +
>  xen/include/asm-generic/device.h              |   1 +
>  xen/include/public/arch-arm.h                 |   5 +
>  xen/include/xen/dom0less-build.h              |   3 +
>  29 files changed, 982 insertions(+), 85 deletions(-)
>  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/include/asm/firmware/sci.h
>  delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
> 
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 21:24:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 21:24:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109045.1458921 (Exim 4.92)
	(envelope-from )
	id 1utuxy-0000p0-LP; Wed, 03 Sep 2025 21:24:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109045.1458921; Wed, 03 Sep 2025 21:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utuxy-0000ot-IW; Wed, 03 Sep 2025 21:24:30 +0000
Received: by outflank-mailman (input) for mailman id 1109045;
 Wed, 03 Sep 2025 21:24: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 1utuxw-0000WA-Rn
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 21:24:28 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f2e6501-890c-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 23:24:27 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by GVXPR03MB11033.eurprd03.prod.outlook.com
 (2603:10a6:150:287::8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 21:24:22 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 21:24: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: 5f2e6501-890c-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lAqGYWpGgcJqdaXTL9fPWp6Ph5qt63JXpfakdHr9yAKLR2PUDe/QDcRCdYrcVp9UZcqp2bqtB+C+26vmZ0NKLanN3IDEmClDha2ijo5bRDuTCYX17mAOSfjXX8d31oGC7X6vv45K/K4K4dBZGDeAAFnpyU5IQnfIqdaFCSYcSME5gjxdu4h97YeXSI/xLdwvYuoBNuAlxPoDVS8qGw8yH+T3aFy7OUibLc5VnxyZwpJWgcJ+/wrItsxzzSB8kvvyq0T/4rYogowygfToOeoVko9NzVVbRHOzKRmsCVG/FYvYSi3/FHE0RzbUcJBt8WRM29oBbVN6xWLDZsejAkoUyA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QTsDulHDpx1lzcz7xtXo4Vgsh3MUrM2r5m44z6nYTBM=;
 b=NvXfgXw5v3fRJffMQuULAjsLSZGQW+jJmaxE1ix0EgABFKCbw/7osmZEnpzR4ds+jQ/LCD2sSP4K6vJjwdwC7SndcNsEzdrE1jiL2/FaDuLUUmH8nRZnsvpSb73Tg91AzR3rUQ1UT6DSWALlR3vdEc4Hl9cNerhDcQrzfYbW0+yullmVDno1LOqmWzPYndbgmXd3gNsETA4QWOsQq9Bi4Jy1+lJ7GPvk4wad7DjRHLg1o4dp9BdBKxx2jKiOU9X238k9u6B68x8oPJKtvPf52t2BQxdzUeA20Mgnb8jc3hXAG+3D38x7WN+Lg5lCpGQRJmnDhkYDLbLvrDpZJhjAIQ==
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=QTsDulHDpx1lzcz7xtXo4Vgsh3MUrM2r5m44z6nYTBM=;
 b=ST7Q2oKS96Nbg4RiiUthG5UHP55m+zgBpttU8+rzvbqGodnWbBAHhdZOK7HwA1OdlgCqCCzn89oiDTewjt7zn/jgZ/5u93g+Uf7KwYsMD8FxspuMHLnZEORdtjKmIqNRALn7esML/d6U0Azdne0P9cCebrQvjwA9DTd4Y4qiV+qGInYta7S9FGYcA69JDa3eYTgiRqxRhshyQQWGaWMwG0TUXbn3QUDjO1+cvRgdlHB7Ia5If7ohS1nVN5LbofZDKeiH1bFEQ59F8dkQCUrCQeZFj2AN46eEGHqFDiTgZD0JAK/iJN9onmEtmo1mYLxcW6BRU9H5BtrOCnzrnDo/TA==
From: Volodymyr Babchuk 
To: Leonid Komarianskyi 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Topic: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcHN9B/XZckpNoZ0qtaeK6YdrfOA==
Date: Wed, 3 Sep 2025 21:24:21 +0000
Message-ID: <87y0qvteka.fsf@epam.com>
References: 
	
In-Reply-To:
 
	(Leonid Komarianskyi's message of "Wed, 3 Sep 2025 14:30:10 +0000")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|GVXPR03MB11033:EE_
x-ms-office365-filtering-correlation-id: fe7289e5-252d-443b-5c79-08ddeb303ff1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|42112799006|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?8FufkNwIBiBUBtTPdqQjgQOa0TnitFaqACdOGa3a6dlwlwOgsptT3lvTZd?=
 =?iso-8859-1?Q?p1KPKZehBfOOgjUUobs33bfFm31t744/hTnuz1SkW5Z9QU/lmrF+LCPBUe?=
 =?iso-8859-1?Q?17PIQzXBzUGHHBE7BqI4RGpgBCZ+r5x77FmamvwuMHMhiI0S+mKo0SiqhS?=
 =?iso-8859-1?Q?KiIJ+FDV5AohFDF7mSFm6sOCVVBo1U81ZsFOp63VjMSaXpd68iy/naRgmF?=
 =?iso-8859-1?Q?JRh4ri8i6tx8ebRnQV7jZKnxUSKqFZc5tbb3P0N9jzADfjmw/ky4r0tlS2?=
 =?iso-8859-1?Q?07ZrhUEV21V4T0zrVrpGYilGUHO9fIO0ivnJwh1eaLYz1rP7nkEixjaaQA?=
 =?iso-8859-1?Q?E9JBt5B3UFZVB/QVgVXU71sW2REOyVxiHhERJo1g+IglqEos7NvSgQ9Rgm?=
 =?iso-8859-1?Q?KtiSN8PJjKpta0EIc6dNWNniB+eLnCL1/0/iNaxmGgbLKZGhDf7oOn3sZm?=
 =?iso-8859-1?Q?rdn/DEfNp9J+8m8izo+3g0+7DcP7IAV5ukAwtAfRRQOuX/ABNQYs//eHdG?=
 =?iso-8859-1?Q?Hw9HYwmelM+5SC5LujLRvwfVc/flXRkOO7EmdLrK3aWqcto5eYTtxYB9T4?=
 =?iso-8859-1?Q?oWH5nHAK0MyefiaRQCNneBIUhGNliHouOHeZihaLjBX2eI0OBwpnF5HtEu?=
 =?iso-8859-1?Q?rAeEEEoBZxXiKgWwa313DV5cDogFlyTi/fcAqRVkzbN9a2PMq39Lm2iXkj?=
 =?iso-8859-1?Q?fkELsoxCseW7alSyIXzbWg94NfgRqts6Fz1ml/7fHzzSHw4Gr9WA/iPwtX?=
 =?iso-8859-1?Q?3SttYRuWqtdoKw8yc3J16aO/DS1t/OLgRov0yUzD76YZ0t+4Rm66q9+QlY?=
 =?iso-8859-1?Q?b8VR0kCYRQdL7ZpMC5umWSgIgJedsX4mYXPgaUt56u5PXOyItKOtHf/1Td?=
 =?iso-8859-1?Q?YfTy2gtVAM6RMmRKAXqUql6cRG9H8BrxZNRNtzbMITXf3wWczr+0a8TbNK?=
 =?iso-8859-1?Q?Gsk5aKBJxY0ziyFmTiNQjuttbXSeJfLgyXKYOg2gxZxSfOnyJ4SE0pvjID?=
 =?iso-8859-1?Q?VqprwKv75rZHvBWVu4HdtqBoEzZhHaqwPbI94lYMGbwg9PXUf8RCGBpxBj?=
 =?iso-8859-1?Q?RKUrJalGlnh6mB8yX70TOPpMrsyyMWaaC6cq2LXKoLAL8xrh/A4g+g7ZdS?=
 =?iso-8859-1?Q?RYybjKziJ5p0MvIucoALVzwZL/AbzNfluD7N0swiqBvJYcPyXKoikRJE26?=
 =?iso-8859-1?Q?xPXpp4ZDXdhQzDogkMWl79unGYFKookQdoY1+BYD1s8v3B6bTmPFyQUSJG?=
 =?iso-8859-1?Q?YNrVQ+rhKeM7jBsiNNQi0HzZgF+bEN+sgTUVARYA6SecOjU8AuG7HId8BN?=
 =?iso-8859-1?Q?HnFuyOFSSspRsG1ENPmBBBJjvsr2R38xlnumlwqMEmmkRms4uIq4PzPcks?=
 =?iso-8859-1?Q?MXPf+60IKHuphT0jFY+0b/fq0l6ULrKC/uK81xCNnMw+xRgOLWWAwW8pM7?=
 =?iso-8859-1?Q?127sXJT3WZ9x6HqwCAj+F/nd4riUdTH2pyVIx/LOAq2uvZMktfdagNed7m?=
 =?iso-8859-1?Q?fmFDwcl/bKe8gO7gk7oEzfIMnVt3o/fEpvDNbd2HwZRA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(42112799006)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?7KAQPtoTyIbeMcaiwdmXr/LfL2Sy73AsB5qPKUH7oeEVWBxs75A7bYMkoY?=
 =?iso-8859-1?Q?/0juuVhDUXKKoAxOUHYUKQNyS7nHfK5U+Pb0pqm7376Bjjzyvc/7hB2zGf?=
 =?iso-8859-1?Q?m+uDw5QDDQ/gosasUKQ9vlOID6FELorWxd7szN6Z8NJVQvbHKJRdYTOvVl?=
 =?iso-8859-1?Q?feQ7XTQvJstE/UP5J0WHUL1udCOaOqM/AfJ72/1QtOBqJVDAbbaluUjaHY?=
 =?iso-8859-1?Q?osE8TmZlDuz9aMlNHLSEq6lpW3yBjEmhnW/HycQ4W/8koN85aylUcNotQv?=
 =?iso-8859-1?Q?Eo5m2WO30Mf5vjOgYlB0dixxWGfS4Qy+BHS5RjQ+aQmMZsEfR2phrbLmtX?=
 =?iso-8859-1?Q?4RECu28hYCqeTQfykWmYlDX+wnMublXkLOtLRlaX+LS2Rz40e0fwH+0sJ6?=
 =?iso-8859-1?Q?rArk2vN0rT6DmqHtYL8QP6ubvwaTHm/G++ZgfBjut8OpbEHbb3QrZwPAAN?=
 =?iso-8859-1?Q?Pg7qcRfql7B8DsSZZGyLSVh3yliJYdSs96Y7HqEHIsvjxV6yOOiooD7hHu?=
 =?iso-8859-1?Q?I8LSI6IgkMLu9eOr5lGCsKUDvk4KHY6iHZMB9Dc+xSsbUp5GQLQS8K5VFk?=
 =?iso-8859-1?Q?eW2H1CTIUHsezj6LcJbyoZ3FIyqcpXzBmtbmCmumPU05HvjaUXZsI528KP?=
 =?iso-8859-1?Q?+Yx3QhYXmKiXdz/0WS0vEFzWJvGMIClLSAXsiBF6g+xQa7HIdA95QE2kBp?=
 =?iso-8859-1?Q?1EdnJ0sS8TpvnWqZKf6N7/UY7WNyOEQIVUqW/RC63Wyo940swFkl68p8zn?=
 =?iso-8859-1?Q?/i4o+kwwL8qX2GVsEEsFdZvbopFYAEMRc9NLB3AyZezdcpUgpfMbO9Q70Q?=
 =?iso-8859-1?Q?6tgP8XUwBCsRiuF5NQOeflBihYOlZVJOz4SfxBDzNphZDpKAarA6LjAZvP?=
 =?iso-8859-1?Q?pubD465k2K4E+vehwvvCUia+DB561tMtykpsJOl+yyCMMJRjCp7wIQ1/rL?=
 =?iso-8859-1?Q?bK/NlpZr8CZBRipO9kwcGl/OVQ/mL8t55K/t9n2aPmyqUS253Uhq3w9IsT?=
 =?iso-8859-1?Q?EWoTWpTfOsG1OQeQyR25SKD9sZaX1BNLEV9nn6sWhouFO5fl3zlOp9fB+7?=
 =?iso-8859-1?Q?I11OTd1Rd+5zsU0lydcXnfuezA//vXebfbKXtJhQsRNkdvn5wfk4N8nDKd?=
 =?iso-8859-1?Q?+Tahim9zeXs91n4Gl/GliHqavXl7/IJBzj1IUqdMPNXqUlPLXf3/Th/pTe?=
 =?iso-8859-1?Q?lICeBibVgwvZJJP5IKqd+qLv15ToVtJWC+6k7R68hzJgZ1gu6KVKCAG7B8?=
 =?iso-8859-1?Q?Dl3k7JxG1si+lPerVTXaGi0IG79c6ZKofaCC7F3ejFIuCFw5WKmO5h4WtT?=
 =?iso-8859-1?Q?WYHgGWxuhChEz5IsWSJle7mMwhUa3lfdauy4BfTmD3sNTWNZ4OSzgx8mLs?=
 =?iso-8859-1?Q?/WeOiztA4MdZbq3JsyfqGg1DvnClHLSaZ/L/6pLLankpthyX1Z12C9z6tX?=
 =?iso-8859-1?Q?OJVsTuGqRUX0IBNlYOHuFlIXeQm1zQHvlixoSlGGn4O/3VAztTI5Nduk3p?=
 =?iso-8859-1?Q?2at4HhGmtx1iVUI7Vz5Je35XHok1M6ibML66hmVydXcLkgv9zQ98w97sQs?=
 =?iso-8859-1?Q?4L0KX1zCxuKP2HbQbYUEYZHD00EgswycfaCkbNUszB7WhQbv0iCmMkEYgP?=
 =?iso-8859-1?Q?dmplkrrZ21qfDUeDc1VH9cvFU4iKVEQcFmpOiRnoCI5oYKPP7GbZH7zA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe7289e5-252d-443b-5c79-08ddeb303ff1
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 21:24:21.9606
 (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: vQ0ylBgeQRiVNVJ08WJqdktyZPqgV7gPSfdDW0zQcbREglLxic2ri9OSSx34IA95TrQOtxlfWY0GMa208bdp/TxTGqkuh3qehqN1WbKhFQg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11033

Hi Leonid,

Leonid Komarianskyi  writes:

> This change introduces resource management in the VGIC to handle
> extended SPIs introduced in GICv3.1. The pending_irqs and
> allocated_irqs arrays are resized to support the required
> number of eSPIs, based on what is supported by the hardware and
> requested by the guest. A new field, ext_shared_irqs, is added
> to the VGIC structure to store information about eSPIs, similar
> to how shared_irqs is used for regular SPIs.
>
> Since the eSPI range starts at INTID 4096 and INTIDs between 1025
> and 4095 are reserved, helper macros are introduced to simplify the
> transformation of indices and to enable easier access to eSPI-specific
> resources. These changes prepare the VGIC for processing eSPIs as
> required by future functionality.
>
> The initialization and deinitialization paths for vgic have been updated
> to allocate and free these resources appropriately. Additionally,
> updated handling of INTIDs greater than 1024, passed from the toolstack
> during domain creation, and verification logic ensures only valid SPI or
> eSPI INTIDs are used.
>
> The existing SPI behavior remains unaffected when guests do not request
> eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
> option is disabled.
>
> Signed-off-by: Leonid Komarianskyi 
>
> ---
> Changes for V6:
> - introduced a new function for index to virq conversion, idx_to_virq.
>   This allows the removal of eSPI-specific functions and enables the
>   reuse of existing code for regular SPIs
> - fixed the return value of vgic_allocate_virq in the case of eSPI
> - updated the error message in route_irq_to_guest(). To simplify it and
>   avoid overcomplicating with INTID ranges, propose removing the
>   information about the max number of IRQs
> - fixed eSPI rank initialization to avoid using EXT_RANK_IDX2NUM for
>   converting the eSPI rank to the extended range
> - updated the recalculation logic to avoid the nr_spis > 1020 -
>   NR_LOCAL_IRQS check when nr_spis is reassigned in the case of eSPI
> - fixed formatting issues for macros
> - minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
>   into appropriate inline functions introduced in the previous patch
> - minor change: changed int to unsigned int for nr_espis
>
> Changes in V5:
> - removed the has_espi field because it can be determined by checking
>   whether domain->arch.vgic.nr_espis is zero or not
> - since vgic_ext_rank_offset is not used in this patch, it has been
>   moved to the appropriate patch in the patch series, which implements
>   vgic eSPI registers emulation and requires this function
> - removed ifdefs for eSPI-specific macros to reduce the number of ifdefs
>   and code duplication in further changes
> - fixed minor nit: used %pd for printing domain with its ID
>
> Changes in V4:
> - added has_espi field to simplify determining whether a domain is able
>   to operate with eSPI
> - fixed formatting issues and misspellings
>
> Changes in V3:
> - fixed formatting for lines with more than 80 symbols
> - introduced helper functions to be able to use stubs in case of
>   CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of
>   #ifdefs
> - fixed checks for nr_spis in domain_vgic_init
> - updated comment about nr_spis adjustments with dom0less mention
> - moved comment with additional explanations before checks
> - used unsigned int for indexes since they cannot be negative
> - removed unnecessary parentheses
> - move vgic_ext_rank_offset to the below ifdef guard, to reduce the
>   number of ifdefs
>
> Changes in V2:
> - change is_espi_rank to is_valid_espi_rank to verify whether the array
>   element ext_shared_irqs exists. The previous version, is_espi_rank,
>   only checked if the rank index was less than the maximum possible eSPI
>   rank index, but this could potentially result in accessing a
>   non-existing array element. To address this, is_valid_espi_rank was
>   introduced, which ensures that the required eSPI rank exists
> - move gic_number_espis to
>   xen/arm: gicv3: implement handling of GICv3.1 eSPI
> - update vgic_is_valid_irq checks to allow operating with eSPIs
> - remove redundant newline in vgic_allocate_virq
> ---
>  xen/arch/arm/include/asm/vgic.h |  12 +++
>  xen/arch/arm/irq.c              |   3 +-
>  xen/arch/arm/vgic.c             | 174 ++++++++++++++++++++++++++++++--
>  3 files changed, 176 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/v=
gic.h
> index 3e7cbbb196..1cf0a05832 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -146,6 +146,10 @@ struct vgic_dist {
>      int nr_spis; /* Number of SPIs */
>      unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
>      struct vgic_irq_rank *shared_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +    struct vgic_irq_rank *ext_shared_irqs;
> +    unsigned int nr_espis; /* Number of extended SPIs */
> +#endif
>      /*
>       * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
>       * struct arch_vcpu.
> @@ -243,6 +247,14 @@ struct vgic_ops {
>  /* Number of ranks of interrupt registers for a domain */
>  #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
> =20
> +#ifdef CONFIG_GICV3_ESPI
> +#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis + 31) / 32)
> +#endif
> +#define EXT_RANK_MIN (ESPI_BASE_INTID / 32)
> +#define EXT_RANK_MAX ((ESPI_MAX_INTID + 31) / 32)
> +#define EXT_RANK_NUM2IDX(num) ((num) - EXT_RANK_MIN)
> +#define EXT_RANK_IDX2NUM(idx) ((idx) + EXT_RANK_MIN)
> +
>  #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
>  #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
> =20
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index c934d39bf6..c2f1ceb91f 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -494,8 +494,7 @@ int route_irq_to_guest(struct domain *d, unsigned int=
 virq,
>      if ( !vgic_is_valid_line(d, virq) )
>      {
>          printk(XENLOG_G_ERR
> -               "the vIRQ number %u is too high for domain %u (max =3D %u=
)\n",
> -               irq, d->domain_id, vgic_num_irqs(d));
> +               "invalid vIRQ number %u for domain %pd\n", irq, d);
>          return -EINVAL;
>      }
> =20
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 2bbf4d99aa..b42aee8d0c 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -25,11 +25,61 @@
>  #include 
> =20
> =20
> +static inline unsigned int idx_to_virq(struct domain *d, unsigned int id=
x)
> +{
> +    if ( idx >=3D vgic_num_irqs(d) )
> +        return espi_idx_to_intid(idx - vgic_num_irqs(d));
> +
> +    return idx;
> +}
> +
>  bool vgic_is_valid_line(struct domain *d, unsigned int virq)
>  {
> +#ifdef CONFIG_GICV3_ESPI
> +    if ( virq >=3D ESPI_BASE_INTID &&
> +         virq < espi_idx_to_intid(d->arch.vgic.nr_espis) )
> +        return true;
> +#endif
> +
>      return virq < vgic_num_irqs(d);
>  }
> =20
> +#ifdef CONFIG_GICV3_ESPI
> +/*
> + * Since eSPI indexes start from 4096 and numbers from 1024 to
> + * 4095 are forbidden, we need to check both lower and upper
> + * limits for ranks.
> + */
> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int ran=
k)
> +{
> +    return rank >=3D EXT_RANK_MIN &&
> +           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d);
> +}
> +
> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
> +                                                       unsigned int rank=
)
> +{
> +    return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]=
;
> +}
> +
> +#else
> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int ran=
k)
> +{
> +    return false;
> +}
> +
> +/*
> + * This function is stub and will not be called if CONFIG_GICV3_ESPI=3Dn=
,
> + * because in this case, is_valid_espi_rank will always return false.
> + */
> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
> +                                                       unsigned int rank=
)
> +{
> +    ASSERT_UNREACHABLE();
> +    return NULL;
> +}
> +#endif
> +
>  static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
>                                                    unsigned int rank)
>  {
> @@ -37,6 +87,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struc=
t vcpu *v,
>          return v->arch.vgic.private_irqs;
>      else if ( rank <=3D DOMAIN_NR_RANKS(v->domain) )
>          return &v->domain->arch.vgic.shared_irqs[rank - 1];
> +    else if ( is_valid_espi_rank(v->domain, rank) )
> +        return vgic_get_espi_rank(v, rank);
>      else
>          return NULL;
>  }
> @@ -117,6 +169,54 @@ int domain_vgic_register(struct domain *d, unsigned =
int *mmio_count)
>      return 0;
>  }
> =20
> +#ifdef CONFIG_GICV3_ESPI
> +static unsigned int vgic_num_spi_lines(struct domain *d)
> +{
> +    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
> +}
> +
> +static int init_vgic_espi(struct domain *d)
> +{
> +    unsigned int i, idx;
> +
> +    if ( d->arch.vgic.nr_espis =3D=3D 0 )
> +        return 0;
> +
> +    d->arch.vgic.ext_shared_irqs =3D
> +        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d));
> +    if ( d->arch.vgic.ext_shared_irqs =3D=3D NULL )
> +        return -ENOMEM;
> +
> +    for ( i =3D d->arch.vgic.nr_spis, idx =3D 0;
> +          i < vgic_num_spi_lines(d); i++, idx++ )
> +        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i],
> +                              espi_idx_to_intid(idx));
> +
> +    for ( i =3D 0; i < DOMAIN_NR_EXT_RANKS(d); i++ )
> +        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i],
> +                       EXT_RANK_IDX2NUM(i), 0);
> +
> +    return 0;
> +}
> +
> +#else
> +static int init_vgic_espi(struct domain *d)
> +{
> +    return 0;
> +}
> +
> +static unsigned int vgic_num_spi_lines(struct domain *d)
> +{
> +    return d->arch.vgic.nr_spis;
> +}
> +
> +#endif
> +
> +static unsigned int vgic_num_alloc_irqs(struct domain *d)
> +{
> +    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS;

This is good that you are using NR_LOCAL_IRQS here.

> +}
> +
>  int domain_vgic_init(struct domain *d, unsigned int nr_spis)
>  {
>      int i;
> @@ -133,7 +233,39 @@ int domain_vgic_init(struct domain *d, unsigned int =
nr_spis)
> =20
>      /* Limit the number of virtual SPIs supported to (1020 - 32) =3D 988=
  */
>      if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
> +#ifndef CONFIG_GICV3_ESPI
>          return -EINVAL;
> +#else
> +    {
> +        /*
> +         * During domain creation, the dom0less DomUs code or toolstack
> +         * specifies the maximum INTID, which is defined in the domain
> +         * config subtracted by 32 to cover the local IRQs (please see
> +         * the comment to VGIC_DEF_NR_SPIS). To compute the actual numbe=
r
> +         * of eSPI that will be usable for, add back 32.
> +         */
> +        nr_spis +=3D 32;

I think that it is better to use NR_LOCAL_IRQS here.

(Also, I just noticed the same problem as with documentation, meaning
that nr_spis actually does not represent number of SPIs anymore, and
behaves more like max_spi, but let's set this issue aside for now)

> +        if ( nr_spis > espi_idx_to_intid(NR_ESPI_IRQS) )
> +            return -EINVAL;
> +
> +        if ( nr_spis >=3D ESPI_BASE_INTID )
> +        {
> +            unsigned int nr_espis =3D min(nr_spis - ESPI_BASE_INTID, 102=
4U);
> +
> +            /* Verify if GIC HW can handle provided INTID */
> +            if ( nr_espis > gic_number_espis() )
> +                return -EINVAL;
> +
> +            d->arch.vgic.nr_espis =3D nr_espis;
> +            /* Set the maximum available number for regular SPIs */
> +            nr_spis =3D VGIC_DEF_NR_SPIS;
> +        }
> +        else
> +        {
> +            return -EINVAL;
> +        }
> +    }
> +#endif
> =20
>      d->arch.vgic.nr_spis =3D nr_spis;
> =20
> @@ -145,7 +277,7 @@ int domain_vgic_init(struct domain *d, unsigned int n=
r_spis)
>          return -ENOMEM;
> =20
>      d->arch.vgic.pending_irqs =3D
> -        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
> +        xzalloc_array(struct pending_irq, vgic_num_spi_lines(d));
>      if ( d->arch.vgic.pending_irqs =3D=3D NULL )
>          return -ENOMEM;
> =20
> @@ -156,12 +288,16 @@ int domain_vgic_init(struct domain *d, unsigned int=
 nr_spis)
>      for ( i =3D 0; i < DOMAIN_NR_RANKS(d); i++ )
>          vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0);
> =20
> +    ret =3D init_vgic_espi(d);
> +    if ( ret )
> +        return ret;
> +
>      ret =3D d->arch.vgic.handler->domain_init(d);
>      if ( ret )
>          return ret;
> =20
>      d->arch.vgic.allocated_irqs =3D
> -        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
> +        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d=
)));
>      if ( !d->arch.vgic.allocated_irqs )
>          return -ENOMEM;
> =20
> @@ -182,9 +318,12 @@ void domain_vgic_free(struct domain *d)
>      int i;
>      int ret;
> =20
> -    for ( i =3D 0; i < (d->arch.vgic.nr_spis); i++ )
> +    for ( i =3D 32; i < vgic_num_alloc_irqs(d); i++ )

s/32/NR_LOCAL_IRQS

>      {
> -        struct pending_irq *p =3D spi_to_pending(d, i + 32);
> +        struct pending_irq *p;
> +        unsigned int virq =3D idx_to_virq(d, i);
> +
> +        p =3D spi_to_pending(d, virq);
> =20
>          if ( p->desc )
>          {
> @@ -198,6 +337,9 @@ void domain_vgic_free(struct domain *d)
>      if ( d->arch.vgic.handler )
>          d->arch.vgic.handler->domain_free(d);
>      xfree(d->arch.vgic.shared_irqs);
> +#ifdef CONFIG_GICV3_ESPI
> +    xfree(d->arch.vgic.ext_shared_irqs);
> +#endif
>      xfree(d->arch.vgic.pending_irqs);
>      xfree(d->arch.vgic.allocated_irqs);
>  }
> @@ -323,10 +465,12 @@ void arch_move_irqs(struct vcpu *v)
>       */
>      ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
> =20
> -    for ( i =3D 32; i < vgic_num_irqs(d); i++ )
> +    for ( i =3D 32; i < vgic_num_alloc_irqs(d); i++ )

It is great idea to start using NR_LOCAL_IRQS here instead of hard-coded 32=
.

>      {
> -        v_target =3D vgic_get_target_vcpu(v, i);
> -        p =3D irq_to_pending(v_target, i);
> +        unsigned int virq =3D idx_to_virq(d, i);
> +
> +        v_target =3D vgic_get_target_vcpu(v, virq);
> +        p =3D irq_to_pending(v_target, virq);
> =20
>          if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p-=
>status) )
>              irq_set_affinity(p->desc, cpu_mask);
> @@ -539,7 +683,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, un=
signed int irq)
>      else if ( is_lpi(irq) )
>          n =3D v->domain->arch.vgic.handler->lpi_to_pending(v->domain, ir=
q);
>      else
> -        n =3D &v->domain->arch.vgic.pending_irqs[irq - 32];
> +        n =3D spi_to_pending(v->domain, irq);
>      return n;
>  }
> =20
> @@ -547,7 +691,12 @@ struct pending_irq *spi_to_pending(struct domain *d,=
 unsigned int irq)
>  {
>      ASSERT(irq >=3D NR_LOCAL_IRQS);
> =20
> -    return &d->arch.vgic.pending_irqs[irq - 32];
> +    if ( is_espi(irq) )
> +        irq =3D espi_intid_to_idx(irq) + d->arch.vgic.nr_spis;
> +    else
> +        irq -=3D 32;

s/32/NR_LOCAL_IRQS

Also, I want you to consider adding local variable "idx" instead of
reusing "irq" parameter.

> +
> +    return &d->arch.vgic.pending_irqs[irq];
>  }
> =20
>  void vgic_clear_pending_irqs(struct vcpu *v)
> @@ -668,6 +817,9 @@ bool vgic_reserve_virq(struct domain *d, unsigned int=
 virq)
>      if ( !vgic_is_valid_line(d, virq) )
>          return false;
> =20
> +    if ( is_espi(virq) )
> +        virq =3D espi_intid_to_idx(virq) + vgic_num_irqs(d);

Here as well. It is very confusing when you are updating virq with a
value that does not corresponds in IRQ number anymore.

> +
>      return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
>  }
> =20
> @@ -685,7 +837,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
>      else
>      {
>          first =3D 32;
> -        end =3D vgic_num_irqs(d);
> +        end =3D vgic_num_alloc_irqs(d);
>      }
> =20
>      /*
> @@ -700,7 +852,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
>      }
>      while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
> =20
> -    return virq;
> +    return idx_to_virq(d, virq);
>  }
> =20
>  void vgic_free_virq(struct domain *d, unsigned int virq)

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 21:28:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 21:28:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109080.1458930 (Exim 4.92)
	(envelope-from )
	id 1utv1j-0001fk-5T; Wed, 03 Sep 2025 21:28:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109080.1458930; Wed, 03 Sep 2025 21:28: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 1utv1j-0001fd-2Y; Wed, 03 Sep 2025 21:28:23 +0000
Received: by outflank-mailman (input) for mailman id 1109080;
 Wed, 03 Sep 2025 21: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 1utv1h-0001fX-HU
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 21:28:21 +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 e8653c44-890c-11f0-9809-7dc792cee155;
 Wed, 03 Sep 2025 23:28:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 546E66013F;
 Wed,  3 Sep 2025 21:28:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B25ABC4CEE7;
 Wed,  3 Sep 2025 21:28: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: e8653c44-890c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1756934897;
	bh=+CbtXfeAsx6ZEFMcO6rryfpd/rZSvxhEcK4vJsCAqDw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=d3jEH9/D21qe6Seq89N77/8lWZQSdzd/0eDiwwg6WvrkvKk0bF0LjC7MjVyP3LneI
	 epUwm1sj//UuqIhHkvSH8RYZ2zZ5KUKjS6GIh5IbPsma9DzAGJzyVV6guiJt4LvJHd
	 6/LmD3q7gCdC2vcvjL9QB0TCOX52itqXbgMefCNnUuyKpTYr8ENvm3NwCJldKFheE1
	 t/KoqsXd+Eox+iZXex9YW4tjsFcSLmGeUTrWFTIJDnxPAvG3gYn5VTUrPJbqVNon4x
	 BWaLCRQKJ7ijckKTTTQTG+0v7FETUJ0wxlt4ucnCqqdlGW8S5HPiK+PcAjy4BOU+Ro
	 ZMFEEBLswS4TA==
Date: Wed, 3 Sep 2025 14:28:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 v17 0/4] xen/domain: domain ID allocation
In-Reply-To: <20250829232132.3460081-1-dmukhin@ford.com>
Message-ID: 
References: <20250829232132.3460081-1-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

This series is fully acked except for:

- a minimal change to xen/arch/x86/setup.c
- the self test tools/tests/domid/

Based on this, I plan to commit it in the next couple of days. Please
let me know if you have any thoughts on that.



On Fri, 29 Aug 2025, dmukhin@xen.org wrote:
> Patch 1 introduces new domid_{alloc,free} calls.
> Patch 2 is a prep change for domain ID allocator test.
> Patch 3 introduces some basic testing for domain ID allocator.
> Patch 4 adjusts create_dom0() messages (use %pd).
> 
> Link to v16: https://lore.kernel.org/xen-devel/20250812223024.2364749-1-dmukhin@ford.com/
> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2012378054
> 
> Denis Mukhin (4):
>   xen/domain: unify domain ID allocation
>   tools/include: move xc_bitops.h to xen-tools/bitops.h
>   tools/tests: introduce unit tests for domain ID allocator
>   xen/domain: update create_dom0() messages
> 
>  .../xen-tools/bitops.h}                       | 16 +++-
>  tools/libs/ctrl/xc_misc.c                     | 13 +--
>  tools/libs/guest/xg_dom_elfloader.c           |  1 -
>  tools/libs/guest/xg_dom_hvmloader.c           |  1 -
>  tools/libs/guest/xg_private.h                 |  2 +-
>  tools/libs/guest/xg_sr_common.h               |  2 -
>  tools/tests/Makefile                          |  1 +
>  tools/tests/domid/.gitignore                  |  2 +
>  tools/tests/domid/Makefile                    | 88 +++++++++++++++++
>  tools/tests/domid/harness.h                   | 54 +++++++++++
>  tools/tests/domid/test-domid.c                | 95 +++++++++++++++++++
>  xen/arch/arm/domain_build.c                   | 13 ++-
>  xen/arch/x86/setup.c                          | 11 ++-
>  xen/common/Makefile                           |  1 +
>  xen/common/device-tree/dom0less-build.c       | 15 +--
>  xen/common/domain.c                           |  2 +
>  xen/common/domctl.c                           | 43 ++-------
>  xen/common/domid.c                            | 95 +++++++++++++++++++
>  xen/include/xen/domain.h                      |  3 +
>  xen/lib/find-next-bit.c                       |  5 +
>  20 files changed, 397 insertions(+), 66 deletions(-)
>  rename tools/{libs/ctrl/xc_bitops.h => include/xen-tools/bitops.h} (84%)
>  create mode 100644 tools/tests/domid/.gitignore
>  create mode 100644 tools/tests/domid/Makefile
>  create mode 100644 tools/tests/domid/harness.h
>  create mode 100644 tools/tests/domid/test-domid.c
>  create mode 100644 xen/common/domid.c
> 
> -- 
> 2.51.0
> 


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 21:37:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 21:37:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109101.1458941 (Exim 4.92)
	(envelope-from )
	id 1utvAv-0003SG-3K; Wed, 03 Sep 2025 21:37:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109101.1458941; Wed, 03 Sep 2025 21: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 1utvAv-0003S9-05; Wed, 03 Sep 2025 21:37:53 +0000
Received: by outflank-mailman (input) for mailman id 1109101;
 Wed, 03 Sep 2025 21: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 1utvAs-0003S3-Vm
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 21:37: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 3d1825ad-890e-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 23:37:49 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB7064.eurprd03.prod.outlook.com
 (2603:10a6:20b:29e::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 21:37:47 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 21: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: 3d1825ad-890e-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kpz4GyBlIDU/mHc+oHdF4jEanNFGelUce+KDupWNHOZyxE/JEnT50n+Olcal4e2Z7TRjkB9D9ZYFXlRXZwRuyiPWABBsISD6M4bCCiRCHZGE6e/Ax3ZTWufuLEBaYkfmd8OT2XL5fD1I4KAmmt5A2pTEDLsIJ3hwH2Vwpk6/us99VGHjZ5GHrA7ww+FQe83sA140hVTkA1udU+E2iAtrTqpFsGdV62djvdmx6EJ1fwqJq8OVsDfurCjewroR+MYDyBybqqDsdGsJy5CvDLY/dm03pDf+0+6QhHZs8VGxeruKtPRkmplOSfG1SEjFYfCm7u3AR9AKSskneyt0kp775w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QTWA/4owJ7JAQakxcsrR5jbfywMTVZmx00kFDWsEWks=;
 b=NBnrEy+U1EaalaHBjspsNxN7GZ9ylUQv+HB6ZTUqpOYJDK5lt6oI8Ccx9AZbonkXQItOBv/gDy6uTJsjyVQP3wPdddMHGD02o0NrVCsRvikcSQqo7GNu16ZeeRYPCA+VNnepUtuI4j+/TS2WHhtA1S4vDrR9T6hp1VzwnNcEr8vjI6Eju7nHzFgAc4gAZnplwk8BcDJmG+MxKZT7tWPY4oKNkx8Z4W0BIL/AoLjo/idrTFJPPAyK4BCKVmT8/NU5wEw8FDmLSB04Xqf05qAZZpmKSiY4DIe7BF74HDyUuFnyKj1PzX9sriNuxR481Iur2aD2+5CSEwqzg40GZxlRrA==
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=QTWA/4owJ7JAQakxcsrR5jbfywMTVZmx00kFDWsEWks=;
 b=qXCjPalRSQseTUOgrDtov4YVIJTTSjCE9M3azBijIOtMVL907PMcwZOUQymbLjezFQlhv/obYlJUGr+yDo2SXWEt/3GickJQfIxMX5QzO3NJFoIyxKtL9KiGKqgcOpoWiV33+SH+z2+zerWTBr1q6DcCen1cekfo9iByNonrFFW20BPbyhjOJZpK0EzGkyBhf/rgO1IQgln0pnnOFZggZ9ynAlVFkMgbOnf39OjE1YCDuSg8a7T0Wp5rRk2shPejV2bRWjUCO1NwHazkrJfWdp73umCVkDKMglpu3ljqM3QVYtn1mI6q5Xw2598WBr64GLi7ipPpX2YMaGgNjguYIw==
From: Volodymyr Babchuk 
To: Oleksandr Tyshchenko 
CC: Leonid Komarianskyi ,
	"xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel 
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Topic: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Index: AQHcHN9Gwo4As6udbUuFAitPPh/bLA==
Date: Wed, 3 Sep 2025 21:37:46 +0000
Message-ID: <87plc7tdxx.fsf@epam.com>
References: 
	<345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
	
In-Reply-To:  (Oleksandr
	Tyshchenko's message of "Wed, 3 Sep 2025 22:27:07 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS8PR03MB7064:EE_
x-ms-office365-filtering-correlation-id: 4d2304bd-243c-48cf-ed8d-08ddeb321fb7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?5cxvHvNU/AQSykEIcbMfCfMo++XOnwDFIK28zPPGmCOeVrXJ0N9BnleaH7?=
 =?iso-8859-1?Q?iCothoNoVOFd7U7xI6BB2L5CTPQNiy6+KZKcSKoKme3qfakrqauMSO+WX5?=
 =?iso-8859-1?Q?GBizb5t7iuZAzoXEz96MgC979e48+ipyQvT6/fEHiwY32AGably3tZSvha?=
 =?iso-8859-1?Q?YeG19Llmh1iKiNLHoFNJXMGjLf0NNhvU/fh4w7Bvp0PmWOPFhxAVD9DJyB?=
 =?iso-8859-1?Q?5y8QG0/J/9glPyy8cukEaRjOMDbTl5Twudlrfkl8PgdFH7D1gaMddWJZ7k?=
 =?iso-8859-1?Q?66DmLja4Y3AzQCWVc+YNEfr03C/IxnzItNgUvdJ/FloGc4wT/7lyUnbujk?=
 =?iso-8859-1?Q?oK0cWXK0qNLh4jliV/aABsaUX0aSPEPv3k/wmbWP2Pa4frylVqyasNqAUR?=
 =?iso-8859-1?Q?KJ/RsALVKf5Xd9euW05xieweC9faWRimet26xCfXFtQt6QASykmXNi1oVI?=
 =?iso-8859-1?Q?q6VwpuPECy4sP9sJL2w/FGpAmhaaaFtk1a6Xz3gaE/QMqxXssRWk2CXzqQ?=
 =?iso-8859-1?Q?aba47Y/2AJCabKMnA5LP0boXd1+oLKnpCfX6h3n4gFq2uw9ikPvR4xswMR?=
 =?iso-8859-1?Q?wZtfOn+l8c5iiMuwPs1/vOzD+mCnJxt21E9rCYbdZF/PIU6HtPRKL+GH6F?=
 =?iso-8859-1?Q?WAce+Jw4P16Z6pdqpUXick6Xsv1fhnK7OXjF6g5QseAtBdGCC3/XahZtFo?=
 =?iso-8859-1?Q?ZGms5VZ94pfzIfLqbJC2U7LEUlBVbAyaUh51bPebDJgNTTCoTzbt8PFy99?=
 =?iso-8859-1?Q?NZeqnX5wN6+bzPSeasMPkaeT+1RmoY+CDmuwc2yGSnBcw71QwsoBeJtuKJ?=
 =?iso-8859-1?Q?AXC5vcukoBYN6pwoULOnu2y7UTPfwcHD1hDHQrzWDsSXNso8mjeWysAr25?=
 =?iso-8859-1?Q?slowjvUPPnRXwoNGHQ3ho4i3cN9EiNxDSXb5V5TleoRD6fvs26BnEA5tHm?=
 =?iso-8859-1?Q?d491F9p5zhbcmKUO/lTtadj1McadVO/pf+XThyVTQV+asbcMfvyOXjnRqU?=
 =?iso-8859-1?Q?OIG3da6WxpY1bwF6ha6RLLJP9IUFjW1rs9QR4finqlqx4rL2KhOM3GpHPz?=
 =?iso-8859-1?Q?W1fkeGsfEH+bp1H1p7dU3UUGV92qaVGYQb3sXFyzTZI6KjhMUf5UemR37n?=
 =?iso-8859-1?Q?fKIF5WvAGXKj5PihdYpKDQar5QvCaFTH2OmdWFoKYhJMAt4WSjz15GJ4hx?=
 =?iso-8859-1?Q?uOCcG0mKDb4wBihYB3IGeuyh4fuQg1GyA3ZkqLtsL6jDug+1HEP/m3qfHA?=
 =?iso-8859-1?Q?VNMfjkJBevuW6vMZrMimBbKNI6v1Znzj2NIfxeZsmKSlZ19UompBpZwNpk?=
 =?iso-8859-1?Q?fK7Lx/epz1buwf26M48rUqQ1O2TlwSqQSwUI7TYfSugwgCtUm43Q7t/ERm?=
 =?iso-8859-1?Q?g8dYBBwZDWcBThT9m2T9YzZXNlb4Z5paug9KUIZrS2m5LQrCbPTUbuvd8P?=
 =?iso-8859-1?Q?TpG7ICQC1QECKk0mSjqy6D/83VpsamzJt9GqzLwyN9moYeA3zsnLhIGnr2?=
 =?iso-8859-1?Q?2V5H8fJGincsc2CkYTN+USbvHmebc/7WOhZ8aR82ljmw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(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?xpJKgM4wloh290VFSk1MpIyIr8/i2/PKfHiIzGY39SjL3KQZEP5girBXEq?=
 =?iso-8859-1?Q?Xt+L3Q+CNId7+iLCB4K0DWMVPssV4Mx/o2k4AxG3hkDe2eQHmUo6jOw8I/?=
 =?iso-8859-1?Q?2HTMNEHSXo+RERnohaFwGMkGLWaFuxP7wbdDS3lZ7582lQXiI3jO92miox?=
 =?iso-8859-1?Q?oBB71W7GgWn8XfTyfzaBVnbbG2DVzd6diGXwLiEZPi8ipOHaKQAjackOui?=
 =?iso-8859-1?Q?ec4QAiLd0MinLT12CkHXC+o5ICUkSkdVI0Fl4hp1segr4WMoSmEwA0cdYc?=
 =?iso-8859-1?Q?XNK/AwYwT0JH7GvPaoooDZ2fZbAKldvSekY9YiDJ11MDvVa3BQxMSFE+3B?=
 =?iso-8859-1?Q?0Qd7R1W/hba6EcfFq9P5lcFwM1N8l1lcLM8UZIFCyVx48607RHl2MnPg9q?=
 =?iso-8859-1?Q?FIUzO0hNSQcfIB7JWRjcXU71TZmvNaYILjwIlQPCErGZxNyVcNcc2ckjmq?=
 =?iso-8859-1?Q?JilAFlSK7tNjxnUFkxRNT95TaSIDTcmE06vLttjV7OmCIRAnUHR2nJsX8a?=
 =?iso-8859-1?Q?H5u3/YDmbs4VQGykU1nOxnz3deYXV/ANH6ZfpJR72QbUSY8fq2KgtSQ9qd?=
 =?iso-8859-1?Q?hlwBIk0almB/eKjn315blEzMAFKBMxWXbKAQk/jyfiul1OxJlN/lnP52po?=
 =?iso-8859-1?Q?zkw84DWMIkKXVl3ilTVxrabBbjES+KRc+4i+PVo/dRJLottetDG2K67W4i?=
 =?iso-8859-1?Q?jqVRg3GmlAjNcnzTRdutSOP5jvUmq5qMvCKq4Sj5lU5iqb6hobBtOJa4Nm?=
 =?iso-8859-1?Q?lppztzZNRfJ/2gKDEhc8kJ0bQa9JIjmBTe410IO+hRJiIfGjwfq1GtneJd?=
 =?iso-8859-1?Q?LHZMnOrpn/axZ4jwouwGgTcHiXduH0rcdyA8+Oager5gGG+RmuxB+PDyyH?=
 =?iso-8859-1?Q?yXQEzXi4lsozdk5oNLR7Lpk1IQysZ7GbV1TI08+egKt2lbJK7tvqtewtip?=
 =?iso-8859-1?Q?48mXuBK+4vUd0cXbRjlpF/9D1h22+wC1PpA8VnidIrTGT4cgnpQkJlQU+p?=
 =?iso-8859-1?Q?rVhpcoDN1M0ej152byRcwgkMP5SgjFAYHO5MXG9rlWS0Nep1eqMKl+pUKZ?=
 =?iso-8859-1?Q?Hy0G6jxN8PMs1VrtcE3W1eIgUIXcGf3z2DttW2gsqXGSbxAcdDasn1ZHZF?=
 =?iso-8859-1?Q?t5RfolhMpjKYcadXLe4QKHKJkFJa1CC05583iqZsjBkzMFRyK43q6ZAt2q?=
 =?iso-8859-1?Q?Vuw09jTUW56UF4RK3cyCxXzb3M+uT2Omdy9QxwNayn++EiqJumxgu4VY16?=
 =?iso-8859-1?Q?X2MUx1gRRJZBeE7q8tT842TpEjwkOnu+yeowpXT7vOYYvicQkD8PT2qcos?=
 =?iso-8859-1?Q?emCaiweyWkIqFIkquiRdzAapnJKwBSNa7N/aVtB3AevAcYloH8hyPK+Xwe?=
 =?iso-8859-1?Q?oagw/prsEas3IeLEOTrsBaqq7GUu4SjFFsKawFdd/IUYJywYKh8R4CzS1K?=
 =?iso-8859-1?Q?vmxpXOdrQ44WasGphcNpXVWt2u54OPikdIqoPcz6OJBwND28hDu9nftmyP?=
 =?iso-8859-1?Q?Ssk0GI7fXdiTf9WptPXyGsoqc7W5jOon51Sh+8XHcKb0xno5psZVl4oyDv?=
 =?iso-8859-1?Q?+SLZscUBWbE9gBySGlzP2mHIkeKNebDbRKlAhSq50eBRE5eI6mRYIggGnh?=
 =?iso-8859-1?Q?ojYTxH2Rdf1hM3sLVTUoMV2pKpcpp9y0rzT1iaf9JF9Ya3C77Sj9ag2g?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d2304bd-243c-48cf-ed8d-08ddeb321fb7
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 21:37:46.9263
 (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: M+El2Sq+YtrpjPn7QKoq8ccGM5k28EtZiQHD1UEUCuszDT8pJyhCNUbVSagEG69PSPhgVvqgpIfivz3mLaiMkCUFtDZpGKOD39zsJ5uAfLQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7064

Hi Oleksandr,

Oleksandr Tyshchenko  writes:


[...]

>> +static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_b=
ase,
>> +                                           uint32_t espi_base)
>> +{
>> +    if ( reg < espi_base )
>> +        return reg - spi_base;
>> +    else
>> +        return reg - espi_base;
>> +}
>
> I am wondering (I do not request a change) whether
> vgic_get_reg_offset() is really helpfull,
> e.g. is
>  offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORITYRnE);
> much better than:
>  offset =3D reg < GICD_IPRIORITYRnE ? reg - GICD_IPRIORITYR : reg -
>  GICD_IPRIORITYRnE;
>

IMO, it is easy to make a mistake, because you need to write register
name 3 times. Can cause errors during copy-pasting. But I saw clever
trick by Mykola Kvach, something like this:

#define vgic_get_reg_offset(addr, reg_name) ( addr < reg_name##nE ? \
 addr - reg_name : addr - reg_name##nE )

And then you can just use this as

offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR)

I don't know what maintainers think about this type of preprocessor
trickery, but in my opinion it is justified in this case, because it
leaves less room for a mistake.


--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 21:48:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 21:48:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109120.1458951 (Exim 4.92)
	(envelope-from )
	id 1utvKk-0005By-0Y; Wed, 03 Sep 2025 21:48:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109120.1458951; Wed, 03 Sep 2025 21:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1utvKj-0005Br-TN; Wed, 03 Sep 2025 21:48:01 +0000
Received: by outflank-mailman (input) for mailman id 1109120;
 Wed, 03 Sep 2025 21:48: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 1utvKi-0005Bl-L2
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 21:48:00 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a8894618-890f-11f0-9d12-b5c5bf9af7f9;
 Wed, 03 Sep 2025 23:47:59 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9557.eurprd03.prod.outlook.com
 (2603:10a6:20b:5a5::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Wed, 3 Sep
 2025 21:47:53 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%5]) with mapi id 15.20.9073.026; Wed, 3 Sep 2025
 21:47: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: a8894618-890f-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PWPaI+7DwS2DHOyK1ytQvtVNDFXfWNsVecMEVSeLNX6j1VbAbDvSm/xGLhUK/GDI5AjAtKuw7oCCR4jZg/lrEWToAAh2DU8mvVi2UBA5T8OwiTP8MLIY/yu3Imv4h1dsN0qBuhrSG0raN3FhsJweqX8lBNrGOPWPPhWXphg5pwpGcOJvf8V5r4V73MmnBh7yg78oJnnJzxL4YPJasw7ZcHHdDLNyOjMRru95MBM4yxQe9KijmsmgzLJRY3lKd0pjDt2Ao6t6Qlt1JsmtqSjNkgaWCIiLwTqpldI9txtP9VLUFpS4YC14E7CEMDtQT8ZHh1cIerRZIYfhFfIZxVeQ4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ajs9ITteRXrA1RVDIBcifvlcji10nUoiHA9jN4yIv8Q=;
 b=pUmDercO6vKfbXZ9OKmI8dyiMRzzX3+Sp8xWzt2Xp4kqcCjAZmOCNh0wt2yRtBtfklutWsET0jFbCu2a4SZJI7NPOAwZKaim8U9cesTzX6ux+KtcfxxX+VUPWS0XMVq7L96vZ9SLZW84U2jOe1Pb0jNxKC9VBQPw0DF5+pgjH2PQ1mSziapwGIRuh6XSoxWl5g1GenCSG++6I0Lh19LsMITGIiJ0agWxvgpz1E293r0fp6nHFvgg0SjeLMjP6+qff3CB7Jemziie6efabBsi6cLoCfphSnt2ZMRD7GLqBXHkzgFVs7D99E6zcCHUPuhtUH3jOtjU7icFbVsmYj7xZQ==
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=ajs9ITteRXrA1RVDIBcifvlcji10nUoiHA9jN4yIv8Q=;
 b=c4gyqnOX4UQc/TpolN/zDeI6sQ4rfHeRpF9/UJYzHPWWjemEDgHtt1e/MYbpCeAq5LL0EW8hj5O6BbIludHq6neM46O3tDGLlHS2a6lZ/IIZGYZFHmgJ8XfAeuZ/jb/dr0BzNuFdEohGjTywgruUgAmPgR3MRoZncFlayPlSoo4H+UEHZIyBByRCBGvJa4+uRuC6FaT/nzRZhyl9iG5OmfhfjGb394CIgGI9QOQooBSoOzdMhFDMhZCh3p6OV51h2KsXyPOPAi2Bf04runhy0u3cat8IsH6jJ2AVNRJhvS29K2qs2syydjrNjQlCcqJ91Q0i5d7YiBHfyGaRjLTSEQ==
From: Volodymyr Babchuk 
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 ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Grygorii Strashko
	
Subject: Re: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
Thread-Topic: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC
 single-agent support
Thread-Index: AQHcHNVLdhHlv1cXk0a1m6gBYsABvg==
Date: Wed, 3 Sep 2025 21:47:53 +0000
Message-ID: <87bjnrtdh3.fsf@epam.com>
References: 
	
In-Reply-To:
 
	(Stefano Stabellini's message of "Wed, 3 Sep 2025 14:24:10 -0700	(PDT)")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS8PR03MB9557:EE_
x-ms-office365-filtering-correlation-id: 46695fa4-f333-4ef8-20ed-08ddeb338938
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|376014|7416014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?E0IUqQRrXUIgmGxaVAzKYGeoONqT+LBCHZ7D7jfb+zRZfE9VAMAk3uv7N7?=
 =?iso-8859-1?Q?uatwaBfHefRCIOE2KmrFAX4YjK293OZOo3zMgXJFi4CF3UkXO9Y+qn/8mS?=
 =?iso-8859-1?Q?9mrzqj3W9wLR+7rBDOL7CIPLWKA6pfyXIC5siFPpUpRNQqBhrdq99h9xgR?=
 =?iso-8859-1?Q?eIaV6H7pCEhHcWJcDGhzdl9ZeYl7lZXkDW8r8g72zXechegXWfhFo1cV1k?=
 =?iso-8859-1?Q?Xt2MRNB5JNzpUEUkjsJNFje15oL1aetxa5a424CC1jANDNSrxSfq+eY2ZL?=
 =?iso-8859-1?Q?Jvk3X5D/BI1bbImayka1Z9GPGvNg3CuuR8KQUMvFLq/pcTpHuE1gxL0r4V?=
 =?iso-8859-1?Q?P4+joGZHXjQFMWxFDStb2MuUNVlOfsU+TMaVbUammiAgDsMKjTVAefBbht?=
 =?iso-8859-1?Q?/NbYo4++rdvM2HSzvKAJfjBxCSVmUxt4l3N45s31QFG5H24SZ3dzgZSK4F?=
 =?iso-8859-1?Q?sN0XncEEvXGaM3X4IPcIx2WZeqxhEI3IFnptCIlF1ojO98GPX4PDxf063+?=
 =?iso-8859-1?Q?XTRTWfUidvfmoSbkcsemxtnHjXUqg6ZCw3qL9RZARUnkcai5lymuAm1aPd?=
 =?iso-8859-1?Q?PW6C1aM1FPstRsEjO2CoebbsS22z9t81ieYvksjbuwwbzzPZ+BDL72CtdD?=
 =?iso-8859-1?Q?CvpCes5oUblCM+Q+6oWzNPkW+/BqeyRYtbJx8MKQpSz35wAVMHCtmpCPLE?=
 =?iso-8859-1?Q?h/n7oV+4IWNkic3SvzZgqHRWIkA6Kb3hz+96hRSrqsoggXOsEHysd+O2bL?=
 =?iso-8859-1?Q?u2aiqkaTe+Zb5+6YRxdLQfx2CvYDwg0/MKh/8ngv0vfrwKmSTS49Lhcx2P?=
 =?iso-8859-1?Q?wGmjboB/lLkjEVVSYZxGm9bdqY9illoA6ppUfk9KVTdMs75UgMWhjKg36Z?=
 =?iso-8859-1?Q?qvZi98Kz2Sg4Xapp5u/GR1Wh+oUazt/bf2CY9Z1cSb1hFVE56k/4mxJK3d?=
 =?iso-8859-1?Q?OUnJs/y6MujV/geCaSqLWt0OTHBpzOUWLcIO5NFBbc+4tLRO7nMNAPWhMX?=
 =?iso-8859-1?Q?9Ji/SoSPvFxBVJpUmQ/oQF2nDc/0c2lCQHnXH3F5xHIKGo3yI8fC75yITy?=
 =?iso-8859-1?Q?BN+g4AOMk4U/xSS0ThOWYIG3EFk/GYFfup3m4NRZXx6+hIXcMSQnNs1+tJ?=
 =?iso-8859-1?Q?6FpViefr2p2AXH3YvftPB+bk5IrGEWC+wpXEUaMVfoGY6Yui62xea6Nr1R?=
 =?iso-8859-1?Q?8NhwCbbQU4JuzU+MCr59xc3VMdLJrYH2vXCQVOsASiCkqhDW9t4tlTTNjQ?=
 =?iso-8859-1?Q?8RNiDf1JnEwBxINESsYWxeEcnRIgX1NS9eWorzP8az4xbpqAF0MNJxmaX/?=
 =?iso-8859-1?Q?VBQqqBH/2ipozcL9KphD97gzLSqkUmAusJguJspVDEkwEJdfbHQogAWKJ4?=
 =?iso-8859-1?Q?wsv7Prc6TlCNDGfIDzV4Z02qReSjzDpjPEMkVBdIsyUr4kdG57TIEd5Y4B?=
 =?iso-8859-1?Q?49Z4So8XmL5kXeVXIFJliuyyfePYacEAcMfUodx58f+aXd7Hr8rMt1X1f/?=
 =?iso-8859-1?Q?QYT46vjcXje1xIFi1SJ1THd0Zkbr2J6r0Aw8m9PHfk/A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(7416014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?xx+acViUl37eBjz5av8feW5o9hF1mrAcx7mEz0Y/aKLsA5AC7sf0htH9+3?=
 =?iso-8859-1?Q?Lk6g+24ppO/IOj2bCO5CGz2xdCtBHwTI62Iwuz5mk6q0wA82mfzzW//qcU?=
 =?iso-8859-1?Q?w/rsPqZl/qJ0/pMs6yPRRh4WMJHWhp/YdbcrEShgjTOI2ORI16rRACr6XV?=
 =?iso-8859-1?Q?nSKxlz1ux2PYJr/NdU/ZfMqWL6WdIHAfmAzeM8F0RWWTkDcUZImpmHqM6K?=
 =?iso-8859-1?Q?wT0sMDYcel7ypfy/3gRTxUroHONuhKWk2x2RoN4zciYVcD+XPRYzEux5OS?=
 =?iso-8859-1?Q?D8sQaO5iN8vgIiBf6SJ2sPCiMQnG2ROWnaoKp6cX9XKZbG8/E0TuE3EPvT?=
 =?iso-8859-1?Q?gEXjS1Xha1AJey1Psvi/cX+jAGaeMZprjThbEtglq6ShEO+DGXrX8pGbuc?=
 =?iso-8859-1?Q?ttJLP4B8rzJU79xYCtsgHqYkdeRFKk/Ovi9AhLfCSpvYBq5LFNJDJ2J4E0?=
 =?iso-8859-1?Q?vs58fzJZZ0X8u8c3q+aOpZ2Zt7SJKGDlj8uzpRkv7zG11YEfFTV8b1FE/J?=
 =?iso-8859-1?Q?ll1eer/Wy/cM7mmDodePjRnYn05vKETbxf1sEiTGG4FgPHZEF2V18tHOx0?=
 =?iso-8859-1?Q?diqcvBIio49MGW+zBr2ks+MYG3ClompEUMa41b5KYg3PxCVBnqVON8PsUQ?=
 =?iso-8859-1?Q?zRYuztf31GkC925OVyOi/U4mHg9TbJjgtEEw2mXikma2ZMnzgjLBYfr6UI?=
 =?iso-8859-1?Q?CIMh8rNgA92Z+SVNHINcu1bkXND7UxdXThJ8hkeKYWm0fcCdWdFblLt2r8?=
 =?iso-8859-1?Q?7fak2b4piyGTzsjpeDi4adS7El8QNY6MdlEOhAyuMyxwjSfSkD8sW5NPJF?=
 =?iso-8859-1?Q?KJ4AyVtB0/SnTZpon0PoGg3hHxkRbBxQQgoqRelSwphKo0MPALCxxS4x/f?=
 =?iso-8859-1?Q?ifpd7RBoElTkZVt0uVnYznRp0QHnNwQ49Q08HYTIMjAdqXJhARssiECNmv?=
 =?iso-8859-1?Q?DCQ7ZAJdW0xpVNVC7zDbwtTOFHK7qnLymY2sCEN/B01tSNwkhQsK3OfDlp?=
 =?iso-8859-1?Q?QdYhM01r8psYIZaBEgxZw03kn+wAdpNNYANyTjqbHxGxY6Aty5TqVWFaxx?=
 =?iso-8859-1?Q?srSNVLdyyUNjHCjv1AbHWFQfWJB7MRsV2yHmfgLk8cRM84B0EXce8giaP7?=
 =?iso-8859-1?Q?Fu6vyHKYl/AMJYPQ7KMkf/xC6gEEg+zAZld8fNPIAqBeYK+/MFtEGNvd/6?=
 =?iso-8859-1?Q?qhhPboQFEdw9GiP7f2/GzwHDa7FfJmNvW1+CuN4ZewU5LDT4O/bF0u7zFx?=
 =?iso-8859-1?Q?fTeJD4i9H71OtJD0O0S4x4QW2U/yzI7EC+AkgZQEE3XrX0VDK67L4d2jt7?=
 =?iso-8859-1?Q?We6ee2pUPsnDmnt3MA+LveM+RUyWy1rRCfOLY/U4jPcyt9rjkZF14DPEYQ?=
 =?iso-8859-1?Q?nIj1Xr/VrNTtMIgX5swZ7CB2fOFqMlg5dXsBy4XlxF+ykdGSV9vwBHpSG8?=
 =?iso-8859-1?Q?xQPPdVcH5RhFEUD6LokswEvOgDmI1KKtpnIn8yIUUyf+qQW4G2twQXPFo6?=
 =?iso-8859-1?Q?Sq9mJ6BsNjF5cF0o5WlsGZ6qlMuvRfLDUjomD0zB5I+fo8/WiJQCEok5Gk?=
 =?iso-8859-1?Q?UrAQZWKfOiwcQ8YFOK5IiUx2K6xPkL++Z8CvNsVTyDdmz2R06y67Hcbi8Q?=
 =?iso-8859-1?Q?8sciu4iGOCNAjv3Gis+6SugauE29RaPyTTSxjcugYtv/1PrJbRSAupWA?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 46695fa4-f333-4ef8-20ed-08ddeb338938
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2025 21:47:53.4389
 (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: iMUAq0W6p+bI3ZhSf6XfLzfoe1whSf9grgnMERZ5fB5DS8GJSTR3LBCydD9tHuNr33vsuKbdFRDTTJRNcx4HefFGF0Z27ZxRffPIX2NHnt8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9557

Hi Stefano,

Stefano Stabellini  writes:

> Hi Oleksii,
>
> It is still not passing the ci-loop, this time due to MISRA. See the two
> new 8.3 and 8.4 violations (previously zero) and also new additional
> 12.2, 13.1 violations:
>

Is there any way to run this kind of tests locally? (I suppose that
answer is "no")

Or at least maybe it is possible to use gitlab CI without sending
patches to the ML? Maybe via opening MRs at gitlab?

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Wed Sep 03 23:04:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Sep 2025 23:04:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109171.1458960 (Exim 4.92)
	(envelope-from )
	id 1utwWU-0006Yy-3u; Wed, 03 Sep 2025 23:04:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109171.1458960; Wed, 03 Sep 2025 23: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 1utwWU-0006Yr-1M; Wed, 03 Sep 2025 23:04:14 +0000
Received: by outflank-mailman (input) for mailman id 1109171;
 Wed, 03 Sep 2025 23:04:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1utwWS-0006Yl-Sb
 for xen-devel@lists.xenproject.org; Wed, 03 Sep 2025 23:04:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1utwWR-004nWw-1O;
 Wed, 03 Sep 2025 23:04:11 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1utwWR-00Ex9P-1A;
 Wed, 03 Sep 2025 23:04:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=RhhQYyZ5A3pujMZNcLTiHu3xupigp4QFFgdnGH0gUug=; b=bcdfrGjgNJEEnQxya0kSANhJ/M
	bbCwJogKGmAQp4oKpudL/lA4aMc+AHKkQemn9BbOznSi9/52QtIjUdeKMAsZQmtp7Fg+QKKAoxQjQ
	sTubUQvg7It/UZBevx9Ax00CHYRPrimch000pmF/ci7sndZ1fb04xH6t51HM2Eb2eZ3U=;
Message-ID: <13ed364c-bec3-4c3e-a451-7bc312b2db9d@xen.org>
Date: Thu, 4 Sep 2025 00:04:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Content-Language: en-GB
To: Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
Cc: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel 
References: 
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
  <87plc7tdxx.fsf@epam.com>
From: Julien Grall 
In-Reply-To: <87plc7tdxx.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 03/09/2025 22:37, Volodymyr Babchuk wrote:
> Hi Oleksandr,
> 
> Oleksandr Tyshchenko  writes:
> 
> 
> [...]
> 
>>> +static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base,
>>> +                                           uint32_t espi_base)
>>> +{
>>> +    if ( reg < espi_base )
>>> +        return reg - spi_base;
>>> +    else
>>> +        return reg - espi_base;
>>> +}
>>
>> I am wondering (I do not request a change) whether
>> vgic_get_reg_offset() is really helpfull,
>> e.g. is
>>   offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORITYRnE);
>> much better than:
>>   offset = reg < GICD_IPRIORITYRnE ? reg - GICD_IPRIORITYR : reg -
>>   GICD_IPRIORITYRnE;
 >>>
> IMO, it is easy to make a mistake, because you need to write register
> name 3 times. Can cause errors during copy-pasting.

+1.

  But I saw clever
> trick by Mykola Kvach, something like this:
> 
> #define vgic_get_reg_offset(addr, reg_name) ( addr < reg_name##nE ? \
>   addr - reg_name : addr - reg_name##nE )
> 
> And then you can just use this as
> 
> offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR)
> 
> I don't know what maintainers think about this type of preprocessor
> trickery, but in my opinion it is justified in this case, because it
> leaves less room for a mistake.

I don't have a strong opinion between the macro version or the static 
inline helper. However:
   * for the macro version, you want to store 'addr' in a local variable 
to ensure it is only evaluated once.
   * for both case, I would prefer if we assert (for the static inline 
helper) or use BUILD_BUG_ON() to confirm that spi_base < espi_base

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 00:19:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 00:19:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109224.1458971 (Exim 4.92)
	(envelope-from )
	id 1utxh9-00075k-AH; Thu, 04 Sep 2025 00:19:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109224.1458971; Thu, 04 Sep 2025 00: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 1utxh9-00075d-6f; Thu, 04 Sep 2025 00:19:19 +0000
Received: by outflank-mailman (input) for mailman id 1109224;
 Thu, 04 Sep 2025 00:19: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 1utxh8-00075X-9Z
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 00:19:18 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca318025-8924-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 02:19: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 77A7140A41;
 Thu,  4 Sep 2025 00:19:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 141D3C4CEE7;
 Thu,  4 Sep 2025 00:19: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: ca318025-8924-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1756945154;
	bh=Vwns9sCZhya6D4JDh1TQ0NJdzpUw5R3lAGOsHD395TY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VVMBTVX84FbG3Vl+PwPOMNjct+wDmo8rEC5A0oO1H2iz4IsXby3hX8eBbYVU8qvOi
	 GzMjdjBLk43/0UQTu53XNxkPvGya8+dmSIuuDsPPKoflZEBMDEC+FrFUod9MUcpfVF
	 sbVnfCha8yrx9oRFq23wPhBJo/I/tI1HOd7LU6o+6lpFHvwzOdMfTp15ZmYvsBDtep
	 h+MK6DGUs5FI88qQ2YLNLuGohcE1uVT/EDytJsqlChYalzgazRICC7BxpXUD+RFgr8
	 HcAotorWKwwU3eqxjG4XmDFD4NxOPVlWJBpOWYOpIIltIBRKl5ykIZllfjlmYM+v9d
	 a+RWOFMeMbmDA==
Date: Wed, 3 Sep 2025 17:19:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
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 , 
    Doug Goldstein 
Subject: Re: [PATCH v1 1/2] automation: call expect script with redirected
 standard error
In-Reply-To: <729708b7e6c1815e7ba9b712f6c847e0a0374fd9.1756834803.git.victorm.lira@amd.com>
Message-ID: 
References: <729708b7e6c1815e7ba9b712f6c847e0a0374fd9.1756834803.git.victorm.lira@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-437634610-1756945154=:1405870"

  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-437634610-1756945154=:1405870
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 2 Sep 2025, victorm.lira@amd.com wrote:
> From: Victor Lira 
> 
> In the console expect script, "send_error" will send a message to standard
> error. Current use of this script redirects only standard output into a
> pipeline. This causes the error messages to sometimes appear hidden in the
> middle of the test logs.
> 
> Redirect also standard error to clearly show when a test has timed out or hit
> EOF.
> 
> Signed-off-by: Victor Lira 

Reviewed-by: Stefano Stabellini 


> ---
> example of the problem:
>  - https://gitlab.com/xen-project/people/luca.miccio/xen/-/jobs/11136585863#L615
>  - timeout message on line 615 shown before end of log
> note:
>  - I couldn't check the change on cirrus-ci as I don't have access
> ---
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: "Roger Pau Monné" 
> Cc: Stefano Stabellini 
> Cc: Doug Goldstein 
> Cc: xen-devel@lists.xenproject.org
> ---
>  .cirrus.yml                                       | 2 +-
>  automation/scripts/include/xtf-runner             | 2 +-
>  automation/scripts/qemu-alpine-x86_64.sh          | 2 +-
>  automation/scripts/qemu-smoke-dom0-arm32.sh       | 2 +-
>  automation/scripts/qemu-smoke-dom0-arm64.sh       | 2 +-
>  automation/scripts/qemu-smoke-dom0less-arm32.sh   | 2 +-
>  automation/scripts/qemu-smoke-dom0less-arm64.sh   | 2 +-
>  automation/scripts/qemu-smoke-ppc64le.sh          | 2 +-
>  automation/scripts/qemu-smoke-riscv64.sh          | 2 +-
>  automation/scripts/qubes-x86-64.sh                | 2 +-
>  automation/scripts/xilinx-smoke-dom0-x86_64.sh    | 2 +-
>  automation/scripts/xilinx-smoke-dom0less-arm64.sh | 2 +-
>  12 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 3163ab8f11..f295c8cb0a 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -166,7 +166,7 @@ task:
>      export TEST_LOG="serial-${FREEBSD_BUILD}-${XTF_ARCH}.txt"
>      export PASSED="Test result: SUCCESS"
>      export TEST_TIMEOUT=120
> -    ./automation/scripts/console.exp | sed 's/\r\+$//'
> +    ./automation/scripts/console.exp |& sed 's/\r\+$//'
> 
>    always:
>      serial_artifacts:
> diff --git a/automation/scripts/include/xtf-runner b/automation/scripts/include/xtf-runner
> index b7fea52dad..43ff2d4d88 100644
> --- a/automation/scripts/include/xtf-runner
> +++ b/automation/scripts/include/xtf-runner
> @@ -114,7 +114,7 @@ function xtf_run_test()
>  {
>      rm -f ${TEST_LOG}
>      export BOOT_MSG PASSED TEST_CMD TEST_LOG UBOOT_CMD
> -    ./console.exp | sed 's/\r\+$//'
> +    ./console.exp |& sed 's/\r\+$//'
>  }
> 
>  # Setup environment and run an XTF test.
> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
> index 746e70483d..c4666b9507 100755
> --- a/automation/scripts/qemu-alpine-x86_64.sh
> +++ b/automation/scripts/qemu-alpine-x86_64.sh
> @@ -84,4 +84,4 @@ export BOOT_MSG="Latest ChangeSet: "
>  export LOG_MSG="Domain-0"
>  export PASSED="BusyBox"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qemu-smoke-dom0-arm32.sh b/automation/scripts/qemu-smoke-dom0-arm32.sh
> index 4f50eabdef..36c47daa42 100755
> --- a/automation/scripts/qemu-smoke-dom0-arm32.sh
> +++ b/automation/scripts/qemu-smoke-dom0-arm32.sh
> @@ -96,4 +96,4 @@ export BOOT_MSG="Latest ChangeSet: "
>  export LOG_MSG="Domain-0"
>  export PASSED="/ #"
> 
> -../automation/scripts/console.exp | sed 's/\r\+$//'
> +../automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qemu-smoke-dom0-arm64.sh b/automation/scripts/qemu-smoke-dom0-arm64.sh
> index d6f6b74880..ee682015a0 100755
> --- a/automation/scripts/qemu-smoke-dom0-arm64.sh
> +++ b/automation/scripts/qemu-smoke-dom0-arm64.sh
> @@ -106,4 +106,4 @@ export TEST_LOG="smoke.serial"
>  export LOG_MSG="Domain-0"
>  export PASSED="BusyBox"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-dom0less-arm32.sh
> index 0e2c5496db..e27636dc9e 100755
> --- a/automation/scripts/qemu-smoke-dom0less-arm32.sh
> +++ b/automation/scripts/qemu-smoke-dom0less-arm32.sh
> @@ -149,4 +149,4 @@ export TEST_LOG="${serial_log}"
>  export LOG_MSG="${dom0_prompt}"
>  export PASSED="${passed}"
> 
> -../automation/scripts/console.exp | sed 's/\r\+$//'
> +../automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-dom0less-arm64.sh
> index e7a3e670d0..e660485f3a 100755
> --- a/automation/scripts/qemu-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/qemu-smoke-dom0less-arm64.sh
> @@ -218,4 +218,4 @@ export TEST_LOG="smoke.serial"
>  export LOG_MSG="Welcome to Alpine Linux"
>  export PASSED="${passed}"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qemu-smoke-ppc64le.sh b/automation/scripts/qemu-smoke-ppc64le.sh
> index 617096ad1f..119c3ed4d5 100755
> --- a/automation/scripts/qemu-smoke-ppc64le.sh
> +++ b/automation/scripts/qemu-smoke-ppc64le.sh
> @@ -24,4 +24,4 @@ export TEST_CMD="qemu-system-ppc64 \
>  export TEST_LOG="${serial_log}"
>  export PASSED="Hello, ppc64le!"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh
> index 25f9e4190e..c0b1082a08 100755
> --- a/automation/scripts/qemu-smoke-riscv64.sh
> +++ b/automation/scripts/qemu-smoke-riscv64.sh
> @@ -16,4 +16,4 @@ export TEST_CMD="qemu-system-riscv64 \
>  export TEST_LOG="smoke.serial"
>  export PASSED="All set up"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index b49a44c5b1..bd939dc948 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -292,7 +292,7 @@ export LOG_MSG="\nWelcome to Alpine Linux"
>  export TEST_CMD="ssh $CONTROLLER console"
>  export TEST_LOG="smoke.serial"
>  export TEST_TIMEOUT="$timeout"
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
>  TEST_RESULT=$?
> 
>  if [ -n "$retrieve_xml" ]; then
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> index 0ad8f658e3..96f534f3aa 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -173,7 +173,7 @@ export BOOT_MSG="Latest ChangeSet: "
>  export TEST_CMD="cat ${SERIAL_DEV}"
>  export TEST_LOG="smoke.serial"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
>  TEST_RESULT=$?
>  sh "/scratch/gitlab-runner/${TEST_BOARD}.sh" 2
>  exit ${TEST_RESULT}
> diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> index 1d7162f1b3..a6da7a830c 100755
> --- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> @@ -137,7 +137,7 @@ export LOG_MSG="Welcome to Alpine Linux"
>  export TEST_CMD="cat ${SERIAL_DEV}"
>  export TEST_LOG="smoke.serial"
> 
> -./automation/scripts/console.exp | sed 's/\r\+$//'
> +./automation/scripts/console.exp |& sed 's/\r\+$//'
>  TEST_RESULT=$?
>  sh "/scratch/gitlab-runner/zcu102.sh" 2
>  exit ${TEST_RESULT}
> --
> 2.50.GIT
> 
--8323329-437634610-1756945154=:1405870--


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 00:19:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 00:19:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109225.1458981 (Exim 4.92)
	(envelope-from )
	id 1utxhK-0007Mo-LC; Thu, 04 Sep 2025 00:19:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109225.1458981; Thu, 04 Sep 2025 00: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 1utxhK-0007Mf-II; Thu, 04 Sep 2025 00:19:30 +0000
Received: by outflank-mailman (input) for mailman id 1109225;
 Thu, 04 Sep 2025 00:19:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1utxhJ-0007M2-Mi
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 00:19:29 +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 d0ddbf58-8924-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 02:19:27 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id B7BA66023D;
 Thu,  4 Sep 2025 00:19:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D734CC4CEE7;
 Thu,  4 Sep 2025 00: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: d0ddbf58-8924-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1756945165;
	bh=buP0pAYK8ZTSCuwJhINSgrZ4mwyeWN3niJRLzi3L7ok=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HuGjvAPAXQx3SwCRVhAke+60JfMEDZS0XGduqI9Jv/iEwdAZ8mlc9F5Fsxb8TDulP
	 ycN88zfcBUGSHzQOcaQvFk8pC9V4WNmWhx/L2x+eIM6gpW6gGB+S1cLnkZrY1tXZPz
	 KF/i6JHqCmE8G2iUprvvDIuCPZSB6KZYZ1033LLzSFSy2ZWo9hpf77d0O/siBYD/UJ
	 yr13qRtDJMXDYsgmvYVrH09tZQMRupQsie8z8jW2SeSBi9B8g1eOVUYhaa3chDoOKR
	 wCEDQsQE0aravoFc8qMdKKJB3O+ml8iCiaYLiMxMY7rlCagZUmj1RkRpd5VCEplp7u
	 rRbV89B5EnZTg==
Date: Wed, 3 Sep 2025 17:19:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [PATCH v1 2/2] automation: edit expect script to separate error
 message lines
In-Reply-To: 
Message-ID: 
References: <729708b7e6c1815e7ba9b712f6c847e0a0374fd9.1756834803.git.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, 2 Sep 2025, victorm.lira@amd.com wrote:
> From: Victor Lira 
> 
> The errors can happen in the middle of a console line which causes the message
> to appear at the end of the current line.
> 
> Prepend a newline to clearly separate the error line.
> 
> Signed-off-by: Victor Lira 

Reviewed-by: Stefano Stabellini 

> ---
> example of the problem:
>  - https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11220478458
>  - line 652
> ---
> pipeline:
>  - https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/2017775449
> ---
> Cc: Doug Goldstein 
> Cc: Stefano Stabellini 
> Cc: xen-devel@lists.xenproject.org
> ---
>  automation/scripts/console.exp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/automation/scripts/console.exp b/automation/scripts/console.exp
> index fc80513dfb..e27886bbef 100755
> --- a/automation/scripts/console.exp
> +++ b/automation/scripts/console.exp
> @@ -35,8 +35,8 @@ expect_after {
>      -re "(.*)\r" {
>          exp_continue -continue_timer
>      }
> -    timeout {send_error "ERROR-Timeout!\n"; exit 1}
> -    eof {send_error "ERROR-EOF!\n"; exit 1}
> +    timeout {send_error "\nERROR-Timeout!\n"; exit 1}
> +    eof {send_error "\nERROR-EOF!\n"; exit 1}
>  }
> 
>  if {[info exists env(UBOOT_CMD)]} {
> --
> 2.50.GIT
> 


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 05:53:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 05:53:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109414.1458999 (Exim 4.92)
	(envelope-from )
	id 1uu2u5-0003mT-Tz; Thu, 04 Sep 2025 05:53:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109414.1458999; Thu, 04 Sep 2025 05: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 1uu2u5-0003mL-PR; Thu, 04 Sep 2025 05:53:01 +0000
Received: by outflank-mailman (input) for mailman id 1109414;
 Thu, 04 Sep 2025 05:53:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uu2u4-0003mF-6b
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 05:53:00 +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 679f3291-8953-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 07:52:56 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU0PR03MB8265.eurprd03.prod.outlook.com (2603:10a6:10:31e::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.15; Thu, 4 Sep
 2025 05:52:53 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 05:52:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 679f3291-8953-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BHkqujKG+YNIvdqUJX98mMBROvb9Qh2rb4LntMkF9pLNz42shmd71OMbuSyz28fEKJTagzvvWSG8z4Q2b0GRgDQ7F95hG/gBKleS8FobU3YxB3GosX8d+XpwtjSF96NkNivtI8t0elPfwQ1k7e3PaL91fwCgDYi9A8S0ejrLnSZgZtFVbWIHpKFtoXnsXYFKRyDu79Ko+BxWmf394whOBvCAqYn85hAV+OsKVx/G/OsC+JPu1nn4MMwR4WXYA7vwZRStj22q6MnDRJjuVSZ9iAIjF5lqMW0B/gOtfckh7+vbzIg0TZlOv+lIELm0DXwpQVdEPdM2iWfjHIJ3lNsVHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nJEkX+ZN5YOwXfTmzsec36wkjEKtOCnkm3E0Knpu+NY=;
 b=L7PfTIeEuAkjJcyotAO4J8PZiWCBz7aeQtTH2eE5ZrG7JCvKzGoJtemvFme3+O4DSZ1pjnCRJ7IW/vXJugKZJpDusii0WSOJNxMiGcX4MjD13HD/rjb8vpY1OKt8/dQwlhmh2GyA0s3SYIIw3TYs8HD567HN1FK/z8wE41umfkqUrUaptRrIxLADhXFsvPT2x6NkNEkuIQo7SlXUvwTUKzZltw9IXz/ly4/rNICcjl9vuV7aPgBbi3oXcnFJoc2xAHZlXrB//0BziIRuC/uXCA7+h4+dp7Wp4SzLrLVR1vQfcgaXfYXnRRl04ivDzutZKnoKvsr+IIw3yT7TWMPXTw==
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=nJEkX+ZN5YOwXfTmzsec36wkjEKtOCnkm3E0Knpu+NY=;
 b=K3n611Ve+mgvngC2d7heZ21lYxjmUtRiddfCBcB2BT5TOQshftzMklQsDoFW15B/aSBeKBhGupntykRzp7iKW1uVJzWnDqjFViOrrJ7qLDgsNePYJRbERK9LiJ6wPAGzvxqW4tD0qDOYi3RJIewV3TYwdNu/FJwGXVCTRIxMYin1i7qxSckYyV55QjhNM9kyXawtc1/drq3BGQR2SolqaSPD17BY0k0ha/B3Bj/ch4gVbrDK6LqpyHtoyTqkYESoDMNhR1NTOLqQyPcp8+A3A0DsCN/ADV7pnrKJ6vs9MqLKNzrYlwb59TxvU53uJKtI7WoMmJTCg55Z4rPCUa0+vQ==
From: Leonid Komarianskyi 
To: Julien Grall , Volodymyr Babchuk
	, Oleksandr Tyshchenko 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Topic: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Index: AQHcHN9FrhwGrEUPyUu8gbPtoBO0RbSCFF2AgAByMgA=
Date: Thu, 4 Sep 2025 05:52:52 +0000
Message-ID: <1ec20c31-2ece-4d31-97e2-72995b6aa2b6@epam.com>
References: 
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
  <87plc7tdxx.fsf@epam.com>
 <13ed364c-bec3-4c3e-a451-7bc312b2db9d@xen.org>
In-Reply-To: <13ed364c-bec3-4c3e-a451-7bc312b2db9d@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: GV2PR03MB8678:EE_|DU0PR03MB8265:EE_
x-ms-office365-filtering-correlation-id: 39715ff7-4c7a-4347-849d-08ddeb7749ed
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?cmhOQm11dWxaUk0yMXZuc0dXMVhLVFQySzc0alo0VWV2a0x6S0xOUzhBdlNm?=
 =?utf-8?B?b3Ircis2S2kwNmdRMWcvck5ZS0VqOUovbDlodm14MEUrT2loSXZsTEorMlR0?=
 =?utf-8?B?eXJNL3NDL20rUmY1SGZnenlnZEVDTTNxL0F4SXp6QldJb3pZRFYyNi9KUS96?=
 =?utf-8?B?cmVFeCtHbFlyV09QYlN5bE5KQ1QvRC9JMWlab1pnaFRodXRacnZuT1NuL1d3?=
 =?utf-8?B?MTJTWXFtM0poVWVwOGs4QzVzK0IyM3VESVF4T3orclRCYllqM0lCc2NKMzAr?=
 =?utf-8?B?eXRsb05kSEcxUDQrZlNQTjlnbTNuWVhCOVhuQWZxVTl1UVQ2RUswSzM0TmdH?=
 =?utf-8?B?VGcrelRoNkZoTXdoSVNldi9lWGJnY09VNFlaVUpkQ2xSN1VKek8rd05sMmRU?=
 =?utf-8?B?RjAreUVtc0RUQ0MweW5qYitJN1AyNzZMVDlobW1QU21SUWQyMEdjblBYYmNq?=
 =?utf-8?B?RE5kTTRRaS9IRHd1amYxY2xYNGFOL29DWHk4MVU0aTZVOEpnNzJUVE5oc0Zy?=
 =?utf-8?B?YTFPWUVCbU9Tb1ErOG15TmVSYkpaYnBVYVJoTTdXcTJIL0pSSnBPbUpOMGp1?=
 =?utf-8?B?QjNSUE1rcjRUVnp3S2lya055dGRnSW5GajRKTUNFVmlRRGpzRUFZendoSko2?=
 =?utf-8?B?bm92cFhqTjVaNWlhSEVZTnRJQitQT0JadzNMMCtxS0didEV3c3RpZE9jZ1Nu?=
 =?utf-8?B?R0J5OFFPKytyNG4wUjZHcHNhWjlaQk9mZjFGUHRvcXMyanNDd01EbWt6ZkFB?=
 =?utf-8?B?MmJIR3Y5eStsSHNJLzJscWtybmhSUEE1dXg3d3lpYis1a2t5Z2pHUy9Mdmsw?=
 =?utf-8?B?b0NMVTlHNlhycjZWWmt2VHFUdytJTjQvZVJJSmtWeTFwZ0dlejRKUHBRc0p5?=
 =?utf-8?B?dWJUazFrdzR3R3haQTBNZFphY2x3a01aWGxLWkpLSTEvc0trNDJaOG16YlFa?=
 =?utf-8?B?ak9oZXNsU0ZxM1hwMUMzMjBKV0xTcWJHUFBiWlJyazVzZkgzSDhQUWxCM3ox?=
 =?utf-8?B?ZE1HdWduQ1h6Z2VqdEwyeThncEhUUHB6QkNRS014REJOT08vMWlWTEV5ZVFD?=
 =?utf-8?B?U1AxbWVZZEhpQVpIS25COU5qS1FtVnhJenlsYVVDeHVCV1ZIemxaMnA0Vkt1?=
 =?utf-8?B?elNoTGtMcVMyUzFKNlRMMGlROEYrM2kzdEdhemd0enRZdk5rdWVhTEt3SGNK?=
 =?utf-8?B?MndRc2pGZDZFTWRsS2pBREVNZmNCbHFJU1BEaGtRbUJvTVJaWVZOUCs2Njlv?=
 =?utf-8?B?RVhYR09DVE9FaWdRa2hwSzZUK3pYQWswZTZsSDl1NnVMcG1OcTY0MWtoMVVj?=
 =?utf-8?B?WXBQL0R0Mi92U0FLeEpXb3laOUkvSGJuR0VpVXVCUlJxUlBCWTBNdkhvQnNU?=
 =?utf-8?B?N0M3dk9aMnFST3hyK3NjaDU2NW9tNHRLbGtPSnBpNzlhdGd4TTNWVlZ5UWYw?=
 =?utf-8?B?cW1YWFpqY2JNRkIvKzhQTGNobWZGTzkxT293aHhEbEZTWXB0bkhHcmpvN0Rx?=
 =?utf-8?B?N2tRcmdueW9zckFrNjB0UyszRkR4OHZsb1ZLRU5wbytnYkl3NVlQNVZMY0U5?=
 =?utf-8?B?UkxpZUFJTk9hS1JJTTNVQ016YzFIOHlGNDBja2xYNFZIT2h5UmRsU0hheHVj?=
 =?utf-8?B?WVZTcUFnUmJ3MnBrSGdDMi8yTURqdjFZQUZsYzd2Z2NTQXlNOWRDQzh5L0Ex?=
 =?utf-8?B?RjRtRDFNUFpRdElhSXJRQkNYTUFVK2FOMkFDTVhoTFU3TVlDa3ZtTGs3L2tG?=
 =?utf-8?B?alBwQTdxajlwTVdycnU3RmwzTllNdG43eXFwUUVyMzZ4M0N6VzgyUlFYbUcw?=
 =?utf-8?B?MDZhTEJmdjRFeW1TVmoxQXQ0aUlWSlZhaEg5ZkwvU2NiN1FDdCtkNTlpT25j?=
 =?utf-8?B?ckVtM294QzRaVXZpVGJRdVNPL0hwdGFEUnhuelZqVm90aTRpM294b1puVWJG?=
 =?utf-8?B?TVlkMTV1dHhEUHNLazdkVGc2dVdKTXVKMjg0YXcxMHR6d3JOTXJYbHFRY09s?=
 =?utf-8?B?ZzNZLzFqbitBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OGhINGdxM3NVbDJUMk14WFFFQWthbDlEL2R1dGJ5ZXVmUXBSWVllRndScUps?=
 =?utf-8?B?Z2FKL3BxazJUa3FZU203emIzNjc3ZlFYY3pEcE9IajhOKy9TczhZVmNHdXVE?=
 =?utf-8?B?YXVrdVFmTGQwMk51RVpqRGpoT0JyYkViMkROeWZIUHhIQzdlOXVuQlA3TTRI?=
 =?utf-8?B?ZGVySFVocHJSVDlZWjA4UGxoYUtYcUlBTkUrRS84emVNTkVtcDdwaXFSdXhT?=
 =?utf-8?B?NTZPMG9USnNETWhjNzM0WldHR3RPcEM5RVNhNEZTQUdweGFMSTdWM1hkSG5J?=
 =?utf-8?B?UnNQQ3c1Zzk0c2M0dk5FUXg0VW9LVDhCcm5pa1YydFpWcHFkYWZyZ203dU9N?=
 =?utf-8?B?NFhFaUZxdGQxTU9HN3JqU2hKclRla1IvM3M3aEM0RVFha1U5SEp3dlpCUzAr?=
 =?utf-8?B?SHZ4UjFBeFkvSERCUTYza0M1d3U2MlJ6NjFTZ0tWSjRsN0gwQ0h3a3dzai9W?=
 =?utf-8?B?L05WY1l6dHY2enU3bC84dUk4QzVUYXdIQ2VZY0ExSDU2bCt4dXovbVRPb0lz?=
 =?utf-8?B?VDhXcFpPbXBreXp1c3dxc1JxbTExYVA5TUpTN3hlcUQvVGxKbGFmS0sxRWxw?=
 =?utf-8?B?a1dxeFRVRmErRGJCWU5qR2l0R0l6a0lTVlBncnNTOGJYd3FNZUlJTGRPZGhm?=
 =?utf-8?B?Z05mZGRwSXlxWUQxN0FRTS9zVFdQa0FrcnMvVk0rYi9XM2VYK21rdXlPQ1J2?=
 =?utf-8?B?cDdFcnYxNmJ0ZzN4R20wWldvWlNKN0d4OVFydjlrQ244c2p5RFVkbW5VMUNn?=
 =?utf-8?B?UDU0R2dxUE1IaVl3ZlprRzM1SlhsTm5rSER4c2FGQVdlb2J1azFkZFdueTBn?=
 =?utf-8?B?bEV0bThXSStCMitYSE5FOVd1UUY1RW5JK0xMaFUvMTdmWjE2VFR5bkVRNGZi?=
 =?utf-8?B?Wmp5MWtrYzFYQUNBNTRmNTJOOVRiUmtBSU9pNG81TTRnK25QVjRCaTBkQ2JL?=
 =?utf-8?B?Q3lMaGpqajI0ZG01SlFKblhUZjlFMGQ3UmMwTHN3cm1BOUhRUi9XRzV1emdH?=
 =?utf-8?B?NW1jdE9lMzBNNHpwWTZXVGVGSTlWSG90YWJhTUVNL2NwaGFkM2tKNmZzZHE3?=
 =?utf-8?B?SCt4RnNOTTd6cTd5eG41VTVYLzR1Rmx4MjhFZHpSRUZYMC9IMXpDek1TWlRk?=
 =?utf-8?B?akxGdUlLL25YdVFjUm9Ka3NSaVRVOS9uaVBsbzVkK1kzVjNheGIyNmJyYUFT?=
 =?utf-8?B?UXJFTnFXbmtybzJVRSt5enJLdmhnaGxUcGw1SVFobUtkNmVTbHZUU1hvSG9W?=
 =?utf-8?B?dFZ1YnJWbm5PYmJZUTlzd0pML1N2QlZtOWdELzF3QVNSTGk3Mk44eVVTazhY?=
 =?utf-8?B?alp0M3A0Q1FtYW9rQktzWE9LYU55M3ZTK0tHMHFGR3NhRzNuODZ1MjVmVUtG?=
 =?utf-8?B?b3BOakNjVGVuMUFNM2JpNlRzaHJPcXVsYTVhRXZ3eUpaa05xdnF1NXF3ZjIz?=
 =?utf-8?B?OHd0dWtBTlRhQ3AxSHZzSUorbmtMQm9BeklnQ2pvNEQ1dGJPN2dQMVFCTG83?=
 =?utf-8?B?WmMzSnE0NUk5MTZBTCtGUFNxREZ0S2YvTTJ6OUR0dmVtS1h0ME10TFFlK0hQ?=
 =?utf-8?B?VUpKYTZ3K0EyaWlsL0ZWREhHY1pIOEovQVVNU2FMWm9MQ1dmNm1ZL09SQkg5?=
 =?utf-8?B?QXFDU0FuMXIvdTYxWko2NzhpbStiL2ZONzVGMWt5UjNITzJnR1ErQnFaeTQx?=
 =?utf-8?B?Q3ViK3FnS0NuclJKRU1nN290RDNjSlUrK2t2U0Z1K0IxL3NxV2FVZHhNaitM?=
 =?utf-8?B?dCtJUzRyN3QzZXZ2Y2dnS1NEbnJWcDc4bnZiSG5qZm9YRVpSTFA4cXI4NEIw?=
 =?utf-8?B?MnVFTWgxdm1KNHN1dGMxWWhDM0xWTVBpbS92bnpMcXJjSFUvc0taWHFMK09m?=
 =?utf-8?B?Y2FRSHlQVUVuRW1DZWQ2UUhvNGlZVEJjRWFjRGRidVJtVEc0Tmk3SWMxVGp5?=
 =?utf-8?B?WWFIazVDK1pCb3BNVU1DbmY0eUFwOC9SbUhLL09RSmJ5b1RNcmFoTTZ2MGhL?=
 =?utf-8?B?emRDUFNaQldGZm5aRHJmRGg1MkJWT0ZCMU50SU9nblEwak9oVWlSczVqSzU0?=
 =?utf-8?B?ZGRxZkhIVFpydXpySGluMkVmWUYvYW1Lc0xyZjBFRldwQjdjVnZWaWVWeXJm?=
 =?utf-8?B?WTZJTUJBQXZmQ3QySWNVdURqbURYUjlVVC9VV1N4aWtkdFVHNG1Gd2pOaUMr?=
 =?utf-8?Q?ZPuOPP9UIwCECQDfZ0Zt3cM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <838F5CA8963C364094DD844F04358EE2@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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 39715ff7-4c7a-4347-849d-08ddeb7749ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 05:52:53.0038
 (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: U+nw1LkNp2JQZB653t8VfNs31CprdKIXqcEubymuUZOvtKk8llRfA32U4MLQHYuwodvPf+5w22PpqYobTjgrFC9m6msfq1m3VE/oU7O8NSQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8265

SGkgSnVsaWVuLCBWb2xvZHlteXIgYW5kIE9sZWtzYW5kciwNCg0KVGhhbmsgeW91IGZvciB5b3Vy
IGNvbW1lbnRzLg0KDQpPbiAwNC4wOS4yNSAwMjowNCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBI
aSwNCj4gDQo+IE9uIDAzLzA5LzIwMjUgMjI6MzcsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0K
Pj4gSGkgT2xla3NhbmRyLA0KPj4NCj4+IE9sZWtzYW5kciBUeXNoY2hlbmtvIDxvbGVrc3R5c2hA
Z21haWwuY29tPiB3cml0ZXM6DQo+Pg0KPj4NCj4+IFsuLi5dDQo+Pg0KPj4+PiArc3RhdGljIGlu
bGluZSB1aW50MzJfdCB2Z2ljX2dldF9yZWdfb2Zmc2V0KHVpbnQzMl90IHJlZywgdWludDMyX3Qg
DQo+Pj4+IHNwaV9iYXNlLA0KPj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVpbnQz
Ml90IGVzcGlfYmFzZSkNCj4+Pj4gK3sNCj4+Pj4gK8KgwqDCoCBpZiAoIHJlZyA8IGVzcGlfYmFz
ZSApDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gcmVnIC0gc3BpX2Jhc2U7DQo+Pj4+ICvC
oMKgwqAgZWxzZQ0KPj4+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIHJlZyAtIGVzcGlfYmFzZTsN
Cj4+Pj4gK30NCj4+Pg0KPj4+IEkgYW0gd29uZGVyaW5nIChJIGRvIG5vdCByZXF1ZXN0IGEgY2hh
bmdlKSB3aGV0aGVyDQo+Pj4gdmdpY19nZXRfcmVnX29mZnNldCgpIGlzIHJlYWxseSBoZWxwZnVs
bCwNCj4+PiBlLmcuIGlzDQo+Pj4gwqAgb2Zmc2V0ID0gdmdpY19nZXRfcmVnX29mZnNldChyZWcs
IEdJQ0RfSVBSSU9SSVRZUiwgR0lDRF9JUFJJT1JJVFlSbkUpOw0KPj4+IG11Y2ggYmV0dGVyIHRo
YW46DQo+Pj4gwqAgb2Zmc2V0ID0gcmVnIDwgR0lDRF9JUFJJT1JJVFlSbkUgPyByZWcgLSBHSUNE
X0lQUklPUklUWVIgOiByZWcgLQ0KPj4+IMKgIEdJQ0RfSVBSSU9SSVRZUm5FOw0KPiAgPj4+DQo+
PiBJTU8sIGl0IGlzIGVhc3kgdG8gbWFrZSBhIG1pc3Rha2UsIGJlY2F1c2UgeW91IG5lZWQgdG8g
d3JpdGUgcmVnaXN0ZXINCj4+IG5hbWUgMyB0aW1lcy4gQ2FuIGNhdXNlIGVycm9ycyBkdXJpbmcg
Y29weS1wYXN0aW5nLg0KPiANCj4gKzEuDQo+IA0KPiAgwqBCdXQgSSBzYXcgY2xldmVyDQo+PiB0
cmljayBieSBNeWtvbGEgS3ZhY2gsIHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+Pg0KPj4gI2RlZmlu
ZSB2Z2ljX2dldF9yZWdfb2Zmc2V0KGFkZHIsIHJlZ19uYW1lKSAoIGFkZHIgPCByZWdfbmFtZSMj
bkUgPyBcDQo+PiDCoCBhZGRyIC0gcmVnX25hbWUgOiBhZGRyIC0gcmVnX25hbWUjI25FICkNCj4+
DQo+PiBBbmQgdGhlbiB5b3UgY2FuIGp1c3QgdXNlIHRoaXMgYXMNCj4+DQo+PiBvZmZzZXQgPSB2
Z2ljX2dldF9yZWdfb2Zmc2V0KHJlZywgR0lDRF9JUFJJT1JJVFlSKQ0KPj4NCj4+IEkgZG9uJ3Qg
a25vdyB3aGF0IG1haW50YWluZXJzIHRoaW5rIGFib3V0IHRoaXMgdHlwZSBvZiBwcmVwcm9jZXNz
b3INCj4+IHRyaWNrZXJ5LCBidXQgaW4gbXkgb3BpbmlvbiBpdCBpcyBqdXN0aWZpZWQgaW4gdGhp
cyBjYXNlLCBiZWNhdXNlIGl0DQo+PiBsZWF2ZXMgbGVzcyByb29tIGZvciBhIG1pc3Rha2UuDQo+
IA0KPiBJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBiZXR3ZWVuIHRoZSBtYWNybyB2ZXJz
aW9uIG9yIHRoZSBzdGF0aWMgDQo+IGlubGluZSBoZWxwZXIuIEhvd2V2ZXI6DQo+ICDCoCAqIGZv
ciB0aGUgbWFjcm8gdmVyc2lvbiwgeW91IHdhbnQgdG8gc3RvcmUgJ2FkZHInIGluIGEgbG9jYWwg
dmFyaWFibGUgDQo+IHRvIGVuc3VyZSBpdCBpcyBvbmx5IGV2YWx1YXRlZCBvbmNlLg0KPiAgwqAg
KiBmb3IgYm90aCBjYXNlLCBJIHdvdWxkIHByZWZlciBpZiB3ZSBhc3NlcnQgKGZvciB0aGUgc3Rh
dGljIGlubGluZSANCj4gaGVscGVyKSBvciB1c2UgQlVJTERfQlVHX09OKCkgdG8gY29uZmlybSB0
aGF0IHNwaV9iYXNlIDwgZXNwaV9iYXNlDQo+IA0KPiBDaGVlcnMsDQo+IA0KDQpJIHdhcyBjb25z
aWRlcmluZyBpbnRyb2R1Y2luZyB0aGlzIGtpbmQgb2YgbWFjcm8sIGJ1dCBJIHRoaW5rIGl0IG1h
eSANCmxlYWQgdG8gaXNzdWVzIGluIHRoZSBmdXR1cmUgYmVjYXVzZSBpdCByZXF1aXJlcyB1cyB0
byBhbHdheXMgbWFpbnRhaW4gDQp0aGUgcGF0dGVybiByZWdfbmFtZS9yZWdfbmFtZSMjbkUgZm9y
IGFsbCByZWdpc3RlcnMuIEkgdW5kZXJzdGFuZCB0aGF0IA0KdGhlIG5hbWVzIG9mIHRoZSBkZWZp
bmVzIGFyZSB1bmxpa2VseSB0byBjaGFuZ2UsIGJ1dCBJIHdvdWxkIHByZWZlciB0byANCnVzZSBh
biBpbmxpbmUgZnVuY3Rpb24gYWxvbmcgd2l0aCB0aGUgc3VnZ2VzdGVkIEFTU0VSVCgpLCBhcyBp
dCBzZWVtcyANCm1vcmUgdmVyc2F0aWxlIHRvIG1lLg0KDQpCZXN0IHJlZ2FyZHMsDQpMZW9uaWQN
Cg==


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 05:58:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 05:58:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109425.1459009 (Exim 4.92)
	(envelope-from )
	id 1uu2zj-0004M6-EJ; Thu, 04 Sep 2025 05:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109425.1459009; Thu, 04 Sep 2025 05: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 1uu2zj-0004Lz-BK; Thu, 04 Sep 2025 05:58:51 +0000
Received: by outflank-mailman (input) for mailman id 1109425;
 Thu, 04 Sep 2025 05:58: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 1uu2zh-0004Lt-F0
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 05:58:49 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 38a6d25c-8954-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 07:58:47 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-61feb87fe26so150354a12.1
 for ; Wed, 03 Sep 2025 22: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
 4fb4d7f45d1cf-61cfc1c7a10sm13890552a12.5.2025.09.03.22.58.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 22: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: 38a6d25c-8954-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756965526; x=1757570326; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=st99eOe1p4Y6UEYhsnIz9Etion7fYyP9ZTFsqlb+lXU=;
        b=avl2Wn0AW6TVNG0Qtzq3ImV6DPzdsuwsnE+UtV9bgghsAKSr7fekwFvv+XentwhNLG
         XGZGkESZ7GLrOC+88VvSv9szfl5bLO1xuhpPZk2b7bnyd8+uus4Q0GuUzZFuwJLfL78D
         wN/qYuNf423i4bdSkLLf5L/EjmXIcIjC7G8GlxcOElcD78SwNKjTtmJTb8vVg0WV9wi0
         8hPL91CJDAwoCg+fqZM30HB+KTZMIW1kKnC72ERqZa71SEpTEhQhHSa8FyG4sCWxu+PH
         HOfpj9HWTJ2uLKNdAdVz4Fvu7AYYLmSgop4h1igfKG1wiMesKIAwR3jCAm8H/4RSlIzU
         hulw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756965526; x=1757570326;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=st99eOe1p4Y6UEYhsnIz9Etion7fYyP9ZTFsqlb+lXU=;
        b=Hhlt6j2ZQg50Nrjo9nNVOO0FXvRLvj6xVqhnIjwESKK/hzh0uio8gJ+gB602hGvB4F
         UfTYOn1TXvva1GRJb9ua0ySJnlu6WDNDDOiv5edLJkQNLc5mkVn3sPo4zYbFhL5iZreL
         Nr1Oa8oDg4875QLfhf0SLpna0Mpc8plQUQWlz+300+YW6vWE/uC6VfdDiWFnEy25FAW2
         yqRj7NoiXEbxBdunR2g8+EcZAYvXqCvov4S0SEQVgDxHVZMQXFvmTvSEG00RPyR3r+BQ
         78aJm/J1qdipjcRrt6F1vmIME5UtyZqp4pBDp3wd8TrX2levyi7jHOjNMx1/rO49JRmg
         IJ2A==
X-Gm-Message-State: AOJu0YwFLrXWfQXYRiVFGtLIHiAqkpWxrYloHBqy2JXba3aW2lzGChiL
	fzSwnfbQuXaKKg9rkacWa7qo5rwlsoYemqX0FPam1SQ0uyASdbECifTnnvnWzi3vXNs8pll8w/p
	6JqI=
X-Gm-Gg: ASbGncux66yZ2C7szUFfl+uiXAYU0mgb4u37TFffTLc07lV0BpyzLh9O4Wo5jIQbIqc
	YP6AztoXpDjWjsy6E2Rv5bnrpXeR0cV2vStlIO6KUocKviy7hPrct9GAAq1ILOFvV9x+Sdpl4A5
	XyKnt4QNNFvqVgeS8sV6lob07ZZ1QD7wakT7JnP5jqup6Ul+BzZjd6FTkxur2MVR891VKTKi+jT
	1e59mUvIse3HSTJgC0wDY4MjorxqSoGhii+/cdhQD+uVoGVtDEF1pwBp6oEzzHFrm5UxAqg1/if
	tXX6nTfWksyii7+W3K+D0xYOOkX5RPlj/GI/UvGXpnEELr71mM2AZJgTM/uA4b/iTfzoQLLoB+5
	IhuSxVynE/2gkJAkGVsAihVbKdLMT1TeDa+E4LKMbU0ZHOPi0iWBteig2xnWr4OFK54H2KUiwrs
	1l60yPW3+dCpJW87i/+A==
X-Google-Smtp-Source: AGHT+IEdf9aqurdLNteBfPFYV3Wvn0/PpUQS5NbLlDJvKrw8TxgiJmf2CurOansqukIeW16hiT1//A==
X-Received: by 2002:a05:6402:42cc:b0:618:38d6:7819 with SMTP id 4fb4d7f45d1cf-61d26d78d3cmr16258060a12.21.1756965526447;
        Wed, 03 Sep 2025 22:58:46 -0700 (PDT)
Message-ID: <0fb22103-c928-40ff-8be9-bf8d3914f028@suse.com>
Date: Thu, 4 Sep 2025 07:58:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865
To: Marek Marczykowski 
Cc: "xen-devel@lists.xenproject.org" 
References: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
 <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2025 18:03, Marek Marczykowski wrote:
> On Wed, Sep 03, 2025 at 05:58:32PM +0200, Jan Beulich wrote:
>> On 03.09.2025 17:46, GitLab wrote:
>>>
>>>
>>> Pipeline #2019390073 has failed!
>>>
>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>> Branch: staging-4.18 ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.18 )
>>>
>>> Commit: 51190865 ( https://gitlab.com/xen-project/hardware/xen/-/commit/51190865a4918c443c310c0478247d5f9caa5dad )
>>> Commit Message: x86/suspend: unconditionally raise a timer soft...
>>> Commit Author: Roger Pau Monné
>>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>>>
>>>
>>> Pipeline #2019390073 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/2019390073 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>>> had 5 failed jobs.
>>>
>>> Job #11230955404 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955404/raw )
>>>
>>> Stage: test
>>> Name: adl-suspend-x86-64-gcc-debug
>>> Job #11230955410 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955410/raw )
>>>
>>> Stage: test
>>> Name: adl-pci-pv-x86-64-gcc-debug
>>> Job #11230955417 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955417/raw )
>>>
>>> Stage: test
>>> Name: adl-pci-hvm-x86-64-gcc-debug
>>> Job #11233274365 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233274365/raw )
>>>
>>> Stage: test
>>> Name: adl-smoke-x86-64-gcc-debug
>>> Job #11233405609 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233405609/raw )
>>>
>>> Stage: test
>>> Name: adl-smoke-x86-64-dom0pvh-gcc-debug
>>
>> While the same tests are fine for 4.19 and 4.20, all five show rubbish in the log,
>> and then fail. No idea what's going on.
> 
> The log says "baudrate is    : 115200", but looking at the state after
> the test I see 9600. No idea if that was simply switched back after, or
> setting to 115200 didn't work. Anyway I suggest to restart (now that
> other jobs completed). I set it manually to 115200 now too (not sure if
> that will remain there...).

The rubbish in the output looks to have gone away, but the adl-* tests fail
as before. I'm retrying two of them another time, but with little hope.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:15:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:15:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109436.1459018 (Exim 4.92)
	(envelope-from )
	id 1uu3Fv-0007AJ-Lr; Thu, 04 Sep 2025 06:15:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109436.1459018; Thu, 04 Sep 2025 06:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu3Fv-0007AC-J6; Thu, 04 Sep 2025 06:15:35 +0000
Received: by outflank-mailman (input) for mailman id 1109436;
 Thu, 04 Sep 2025 06:15: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 1uu3Fu-0007A5-9B
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:15:34 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9035e957-8956-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:15:33 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AS8PR03MB7095.eurprd03.prod.outlook.com (2603:10a6:20b:295::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.21; Thu, 4 Sep
 2025 06:15:30 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 06:15: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: 9035e957-8956-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sxxhwFz0OvG741+pUU0Jzq4swYqO82P1jgpiZhSd+aLaFhB9/iQpDCuZZhxvZfQ/CT/4e3RwZHfssun/Kp2dytmWjfxSIoqTGih9rHDStoFe+ol6ikGQzFv33lRB+wykc+M7Bpwq/fiKejc9MVWrQCOZ9QVeNdYvZUEza33h2gwopLkl/EuysPa3hA9R/NCYWEPaWgUZxXR4kvs+9VzAsT6VHDZmBgS8heOoQ4JmHmNnV08A9ihHa6MO1cYz+Zn0D0GIaaa4mX0dlf3SE/TCo948aD5vSi59gYke+gzz3pvYWa9emrRCyrBUon5fOnZGAcE3kGZDGu5bVpuPONNZvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ssx44WJLOIvFnQML6/CkDIWtm4ItoBcDlQcHJXscHzE=;
 b=uYuhn10V6fvvaqQsHsZp6n9F+flMv6fx6hSoUSPM5Rc2TMmEce4GrRkEaXTSp57akhMZXLBSA+Qospjo4n9rEv08u4JG008NramUlGwtlqT5uy/m8KBTPvI44cSakskedSOeMFw92OVoms7y0vAtc6gz976hpKbLoVtqPfjKxjZM2xjBlRIheMBDD9xC3kixtnHVNTk5NcmWd+SADLbfgvKB8K0P3lO70iJkFLnFjq+K2rh9xJJCBYBtIQs6uBigqrcnc1SsLAtMTpoukPpE0OH4iYmJbrzGk6cdPcbrPUoTjVdAiQtxA4Xe5ZSW5O5KrYkpYbc7psjTaOaVlFKiLA==
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=Ssx44WJLOIvFnQML6/CkDIWtm4ItoBcDlQcHJXscHzE=;
 b=E6RTZnXAEfnvfIOGAEeKz0dB4bvxNheQg9388PpQS7Q4P5xW9zuUk1+dvmrQAOpK0RT1GyEfXu8auS3wO/lMeOy9bCz90FbGn7bqwxrvqsa8mlL9XrTj5cA1F4/VDhwhtw7+MP2+6B1vuUjACeFHViltGOkwzP/x7c2zHfUpqgbiU3OWROEoU2xMShv+mRovw7HtyT90Fulmn3xwLmYeZd3qHFKPccmQUu3XKkERmVuxELXpojYlr2yViZv6lCO6UQx9s8F7s6sTV7dAbGoYk7gKY0hTIf0ukdDttRbq+kUMvT3ilKpFU+L/4Mfyedfq+2Xm4JMuwErRK+T+WoNFUQ==
From: Leonid Komarianskyi 
To: Oleksandr Tyshchenko ,
	"xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Topic: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Index: AQHcHN9FrhwGrEUPyUu8gbPtoBO0RbSB17qAgAC1JoA=
Date: Thu, 4 Sep 2025 06:15:30 +0000
Message-ID: 
References: 
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|AS8PR03MB7095:EE_
x-ms-office365-filtering-correlation-id: 50f05624-daed-490e-6c7a-08ddeb7a7316
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?b3dxS2N3ZTkzdDlSMmFsRkM2ZWVpMnFQRWRwdFAvZUMxWm9jWnhKMGNVNFAx?=
 =?utf-8?B?WnZiUjdlTUNYV2ZmeHJZTGpsV1J4REhiWWFmZFdiK2c1K0g5UzVCUlVERXgy?=
 =?utf-8?B?SVJhMEEwa3c5SGUzMEdNQzFEUXBSbS9ITTU4TC9FU3ZOTTdSUFZmalA4NFUr?=
 =?utf-8?B?RTdyY1BuVXpuYjJ3bDcvRGhmVGlnQ3lnQ3FnYThldTNJWUdJOGk1YlNadWg2?=
 =?utf-8?B?Q3RKYW1QNVBmMnlROTZRbUMvbzFJOGttY2pEeEQ4S0JEMy9NRXp0MllVSTVO?=
 =?utf-8?B?bzJpNmZ3eWVVREZ6YmxqSGRmRkI5MUx0c2UxK2daeXhCR2NEd0ZGeTVlZkJV?=
 =?utf-8?B?SDEyNVMzQkxJUHhIMWNjcEtGa3RzaDdicnBJQ1d4UFFOWktTK0hHdTZ6QzVO?=
 =?utf-8?B?eS9xTmRUL1kyd29TaGJ6b3RZbnpYOWZHdHdWbTdxMW41bXdxTFBIRFZZMEJ6?=
 =?utf-8?B?TER1TWN6TWVTNXArdEsyQWRUQm5jbWFqVHFzTG50MzlwanVHc25TTXM2L2VU?=
 =?utf-8?B?WnVUWGFRRWhOZnhubmxjZ0VFdGZIRzc2TWhxdk84dkNyMXJSYVQ2aVRTb1NP?=
 =?utf-8?B?U0FJaWZUd3dESVZkTXVJN1F1SVcybkVhSC84SVl1d25zdzVqcW1QQTJnaGxa?=
 =?utf-8?B?U2FKT1RiZzFuaGFNRm0xT1VJMGV0MkRodUEzc1o0LytRbzFHWG9iKzR1VGtk?=
 =?utf-8?B?aEZIalNmNmwrTExXaURiTmV4NXBad0JOWXpENXZLNFlidEFGc3lidG9oSlA0?=
 =?utf-8?B?S2ZGVzJ6alhMcGNBR09wRjdVdXJGQzN0S0VRTC9Ja3dYbzMwUEVNcVVLTkY0?=
 =?utf-8?B?OVZsRHoyQnVZK3BycjZPRUFPa1VIRlNuT1FLUTFKUmI1OWY2T1dxR0cweTJF?=
 =?utf-8?B?Zy92MmRTRHJsaFNVWWpydW13NW83VVV5NnRVZFJ3cTRpVDBSaU5uUnJRNjRq?=
 =?utf-8?B?eEFkbndDeG5BYmNabFV0Q2QzVzd5blJJRUIvaHV1N3IrQ2ZzVTZDZFplYXBL?=
 =?utf-8?B?dWFMSDljSkhhb29reUlvbWwyUG82SmhLR2oya09aSGRZSEVWNDRGL2RxVDFE?=
 =?utf-8?B?Y20vVDZTc0szdG85YnpBcENIbzVWVVJFdUNjTmJuTVdTU0JNSGZGZE5xRWJ2?=
 =?utf-8?B?U0tYdi9sMTBhNUNyMEd5M0xhTlpUcGs5RHNJUTdkNVZlOVQxQ3NkWHRLZzVU?=
 =?utf-8?B?TllyZVpKbS8xTEZVcElpMXZvS3JEM0RHcHd3UjlEOTVBbk9xaVg0dnVKM1Iy?=
 =?utf-8?B?Z0hGRSt3bmc5eHR5YWRrME1nS0pIVjJPWStxU0xORTFXaFV5SlNrdUwxV21J?=
 =?utf-8?B?S2R1SkJxMlpPbFRGTk1Wb0JtMVhzWTByTXZseERKK1JDSVpWcCsxZXppcVNm?=
 =?utf-8?B?djhoaFY2MlFzTEp4RVFDajhNK00rSDNKQUlnV01pZHMrVmFybXZVMVZNbmd3?=
 =?utf-8?B?RHR4M1gzRThrYkcrYW1WVGlNK2pBSlA1c2orclBHVUVjTFllcUNUc1kwbnhN?=
 =?utf-8?B?RHNURjhyYTYrNGpPalo4TGNkNG9SVTcyMVRSbjZlRXd0VjUzZWxTRzVhUWJs?=
 =?utf-8?B?TURraFY2OFRWSUFYaTk4VzB5S1BUdXpFVkc5SGs5NnE3b3RKZ2MxM2RMOVFB?=
 =?utf-8?B?dnk2UjR3NFVKNWx0TDNIelZjdjgwaW5oWmtnZTVSeUVGaVJ2QktiRWFOM20w?=
 =?utf-8?B?aDV6VXFiQ0IycHdlWkZWUzVUdm9rTG5pNHVEMHFpOC8zRndyQmxFVVVZZmY1?=
 =?utf-8?B?NnUwNjh6bno0OGVWdXNWU01adU9PUlkwUjhWM05FM3l0TjBreWRRUExHcXJ2?=
 =?utf-8?B?YjQyRG9XY1RKMDBHYjZWYUF2WEZYKy9YMitqVXBraU5Ic3YxMlZmcnpmK1NP?=
 =?utf-8?B?NG5wY2xNU1JEcmlSN0hOTHNUZlgwOE9FTGMwN2dLYWtTQzMySkFxWGk4cnpS?=
 =?utf-8?B?VEhYT1FTSG5LVVJMMUtCUU1KV0xoTEZTbUtzR1BXcTBWdmo4MWxlMzIzaEFn?=
 =?utf-8?B?a0hNSlJqUlBBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.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?T2Jia1Z3VGJ6WnU1Z0FXeERsRkhLbERXOGNydm4zTDVoQzU1TkU1WDh5bFBI?=
 =?utf-8?B?L3JOVHBRTjljZkwwYitRRGw5V25wcHpzTldBNFJhUHFhUmlBdXlKeUs2bXAw?=
 =?utf-8?B?NmNhT0VOWGI5Y2I2V2V6dC9JUE1pb251YVZuNnNKZnp3VFNMKzAybTF2WVlN?=
 =?utf-8?B?NGpIN2d0QnJxc1pva0xNQTRjaEhLMS9IMnBtRExnM1NMS1ZRSjhNN3FzWGdY?=
 =?utf-8?B?RW9ZZEFNcWF2NVNMZ2FZR1ZxZ0l0UVJPYlZpYksyTzZPOGMrc0wrRit1QlBr?=
 =?utf-8?B?Ujkzc3hMRVJzYmxjblo1TTNmMjNlRzlyNFlUU3ZtMmE0OXd0S1ljaUYyQkZw?=
 =?utf-8?B?cEkxZVdEN0xZM0FuVUFzZVcyeHB4NkZocFJCUTR4d0FaLzlNVkhFV01pVXBj?=
 =?utf-8?B?VDlCVUJhblA3VDhiSzliU3N1VGRrdTJZejBVM25DZzI1SzJXbmU1ZWc1bGpp?=
 =?utf-8?B?d0JBWEsyUGpTbTRtT0grbE1QL0N6SzFVNmwyV1E4aHdZVTNOVDhla3MzaEY5?=
 =?utf-8?B?MlRDaFY2NGlDTDVqRk1FeG5DK3pCNGIwS3F6eGJhanFrV1FkTUwxWGFuTnVT?=
 =?utf-8?B?WmhZN2I0Wkd2ZmNuN0lqMG95dmdtclRtUjUwNThaamNVdXNQRFYyaXlMdExY?=
 =?utf-8?B?cWV6TG5Wd0QvVmwrRkQyYXZ1TnRVZ0VkSEZ4OEtiSDg3ZXZzL0NxVDMycTdx?=
 =?utf-8?B?bHlKOTRSbjRKL2FRaEJNeDBFcUd1bjE2ZGpheGltNkpuZ1VSc2kvYU1BckRu?=
 =?utf-8?B?UGJud3UweDZRVCticUdpMlFzMXp0WE9rLzVHMkpxVHN3TDZPdXUwS09vWk5j?=
 =?utf-8?B?ZWZBNlkxaXk4blYvWWtwNTVNWWNUam5RZ2VGV3BPcldNNEhuMUl2QkVLeC8v?=
 =?utf-8?B?RGE4L28xREhHczhMQ29sT2ptUGI4a2JDNkNYMmxobVhybzZQb2tRMVZVaXR2?=
 =?utf-8?B?ODRlMkJpVnBKcEF1cEo5cUNhU2srZDRmWENwc1lBbUdmYTQxZzluV0RuMUtp?=
 =?utf-8?B?bGRpTDZsb290WHFOaDlsRkhCSUlMTVM3N3gyUVRFa2Q0OG4rajJPNjJXdnk1?=
 =?utf-8?B?YkN2SlNHWEFJb3l1aUR2cDl2TnBCNEh0ZFdCREZEaHYzUVBXT0hhK1ZqZnh5?=
 =?utf-8?B?RWhCcE42R2YxWkJjSVNOZUtvYjZ5clVBWGc3cWJSdk9VS1BkL3RDRStLa29D?=
 =?utf-8?B?bm1rbzZzZzR2SjlyM0ZhMTVOc2plSjRaL3RKNEFSL1djWXB0eFJiWitwK1Vh?=
 =?utf-8?B?endtQkY0Ukk1aXFJWHI5WlNRTldjMU9Kdk1YVlpFZFk4U1FadnJ2c2YzZzNU?=
 =?utf-8?B?MGlzTEcydkZUSjM5dWhxYzBtenFLdnBMLzhtM0NIell3WW1oaEFzc0RnSjJH?=
 =?utf-8?B?aHVuczdIM1UxdGE4MmlHZzh6WXhnd3NDNFhKOTRCb0hvU25WWmNlaldSck83?=
 =?utf-8?B?VVoyYXpqQURnL3U4NXFjUm83L3dLZkNsUDBMTU5XZGp4R0dWL20wTGRBQUhB?=
 =?utf-8?B?Sk5JbVpXQ2lPcC9MNmN1ZmZxUlM4bENZMXhzdE5GN2N3SWdQZnc5ZGR5UEdJ?=
 =?utf-8?B?YXdWYWJ5Wm9OS3hmOVVNRkJSMTFvWU5uYXM0bWUxZVNwM3pVZDJNMFN4a2VX?=
 =?utf-8?B?UWg5dW1ybS9mMkt2dkJtRlgwRDQrTWpqUGthTDJWRHpiS1VESEIwcCttRjkv?=
 =?utf-8?B?d1pwbWg3M1JBVFVjYXVDTm15WStPK09wZG45eHZ0alRLcUdDNnBiSlZmbFYr?=
 =?utf-8?B?WlpCT2tyTUhhMTF2Q1RkLzhjTnFzV1B2WEl5R1dodnNNREZ5UmdKVlMvcVo5?=
 =?utf-8?B?SWk2MER3cXRDRHlKMUltcFJnNWd4c3JjMm9NcjhXU2d5dGp0VTVXeWtDZzlQ?=
 =?utf-8?B?WmN6OTlWRkw1UnBNVFRIZWt5MDNTaXFCeEtxMmlLWm14YXVuTklsVEplMm1w?=
 =?utf-8?B?SFRwK2hldDBwUlcxVTFiempaRWkzRUx2RUNnVElTYU1wOXllcUJST3F2NGFP?=
 =?utf-8?B?LzlwY09pL3N2QWFmNis5eXBQdUloZ0o3Y3lLTldLN3NZd3FvUjMwQkx4TStm?=
 =?utf-8?B?THhReWdyVk9lMEJ1ZVA0T3o3SkVTb3FqTGs5Skx1eDlRdHo1MW16VXFKSlhm?=
 =?utf-8?B?WlhXRFFHcWppSzk3WVNrYWZYV1JDc2k5NXQyT29JSEczV1g3RGc3Tm5pSDBB?=
 =?utf-8?Q?xfbHCBW1tWRWsUCtf9qTLAo=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3E4E880F70DBF2459D54A6CD7A40B98F@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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 50f05624-daed-490e-6c7a-08ddeb7a7316
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 06:15:30.5487
 (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: NS8Oskcog+BrOGO1iFHqfoR8rKsoCYc06MG+BWCNqHo8xLqnqN9gnTfUSpmXGr3Xt6x4YxU0HPFhMj4IKqB7rx/urIWn/jJJWaHFm8PIbUY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7095

SGVsbG8gT2xla3NhbmRyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LCBjb21tZW50cyBh
bmQgUkIuDQoNCk9uIDAzLjA5LjI1IDIyOjI3LCBPbGVrc2FuZHIgVHlzaGNoZW5rbyB3cm90ZToN
Cj4gDQo+IA0KPiBPbiAwMy4wOS4yNSAxNzozMCwgTGVvbmlkIEtvbWFyaWFuc2t5aSB3cm90ZToN
Cj4gDQo+IEhlbGxvIExlb25pZA0KPiANCj4+IEltcGxlbWVudGVkIHN1cHBvcnQgZm9yIEdJQ3Yz
LjEgZXh0ZW5kZWQgU1BJIHJlZ2lzdGVycyBmb3IgdkdJQ3YzLA0KPj4gYWxsb3dpbmcgdGhlIGVt
dWxhdGlvbiBvZiBlU1BJLXNwZWNpZmljIGJlaGF2aW9yIGZvciBndWVzdCBkb21haW5zLg0KPj4g
VGhlIGltcGxlbWVudGF0aW9uIGluY2x1ZGVzIHJlYWQgYW5kIHdyaXRlIGVtdWxhdGlvbiBmb3Ig
ZVNQSS1yZWxhdGVkDQo+PiByZWdpc3RlcnMgKGUuZy4sIEdJQ0RfSVNFTkFCTEVSbkUsIEdJQ0Rf
SVJPVVRFUm5FLCBhbmQgb3RoZXJzKSwNCj4+IGZvbGxvd2luZyBhIHNpbWlsYXIgYXBwcm9hY2gg
dG8gdGhlIGhhbmRsaW5nIG9mIHJlZ3VsYXIgU1BJcy4NCj4+DQo+PiBUaGUgZVNQSSByZWdpc3Rl
cnMsIHByZXZpb3VzbHkgbG9jYXRlZCBpbiByZXNlcnZlZCBhZGRyZXNzIHJhbmdlcywNCj4+IGFy
ZSBub3cgYWRqdXN0ZWQgdG8gc3VwcG9ydCBNTUlPIHJlYWQgYW5kIHdyaXRlIG9wZXJhdGlvbnMg
Y29ycmVjdGx5DQo+PiB3aGVuIENPTkZJR19HSUNWM19FU1BJIGlzIGVuYWJsZWQuDQo+Pg0KPj4g
VGhlIGF2YWlsYWJpbGl0eSBvZiBlU1BJcyBhbmQgdGhlIG51bWJlciBvZiBlbXVsYXRlZCBleHRl
bmRlZCBTUElzDQo+PiBmb3IgZ3Vlc3QgZG9tYWlucyBpcyByZXBvcnRlZCBieSBzZXR0aW5nIHRo
ZSBhcHByb3ByaWF0ZSBiaXRzIGluIHRoZQ0KPj4gR0lDRF9UWVBFUiByZWdpc3RlciwgYmFzZWQg
b24gdGhlIG51bWJlciBvZiBlU1BJcyByZXF1ZXN0ZWQgYnkgdGhlDQo+PiBkb21haW4gYW5kIHN1
cHBvcnRlZCBieSB0aGUgaGFyZHdhcmUuIEluIGNhc2VzIHdoZXJlIHRoZSBjb25maWd1cmF0aW9u
DQo+PiBvcHRpb24gaXMgZGlzYWJsZWQsIHRoZSBoYXJkd2FyZSBkb2VzIG5vdCBzdXBwb3J0IGVT
UElzLCBvciB0aGUgZG9tYWluDQo+PiBkb2VzIG5vdCByZXF1ZXN0IHN1Y2ggaW50ZXJydXB0cywg
dGhlIGZ1bmN0aW9uYWxpdHkgcmVtYWlucyB1bmNoYW5nZWQuDQo+Pg0KPj4gU2lnbmVkLW9mZi1i
eTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4NCj4+
DQo+PiAtLS0NCj4+IENoYW5nZXMgaW4gVjY6DQo+PiAtIGludHJvZHVjZWQgaGVscGVyIGZ1bmN0
aW9uczogdmdpY19nZXRfcmFuayBhbmQgdmdpY19nZXRfcmVnX29mZnNldCB0bw0KPj4gwqDCoCBh
dm9pZCBib2lsZXJwbGF0ZSBjb2RlIGFuZCBzaW1wbGlmeSBjaGFuZ2VzDQo+PiAtIGZpeGVkIGlu
ZGV4IGluaXRpYWxpemF0aW9uIGluIHRoZSBwcmV2aW91cyBwYXRjaCAoWzA4LzEyXSB4ZW4vYXJt
Og0KPj4gwqDCoCB2Z2ljOiBhZGQgcmVzb3VyY2UgbWFuYWdlbWVudCBmb3IgZXh0ZW5kZWQgU1BJ
cykgYW5kIHJlbW92ZWQgaW5kZXgNCj4+IMKgwqAgY29udmVyc2lvbiBmb3IgdmdpY19lbmFibGVf
aXJxcygpLCB2Z2ljX2Rpc2FibGVfaXJxcygpLA0KPj4gwqDCoCB2Z2ljX3NldF9pcnFzX3BlbmRp
bmcoKSwgYW5kIHZnaWNfY2hlY2tfaW5mbGlnaHRfaXJxc19wZW5kaW5nKCkNCj4+IC0gZ3JvdXBl
ZCBTUEkgYW5kIGVTUEkgcmVnaXN0ZXJzDQo+PiAtIHVwZGF0ZWQgdGhlIGNvbW1lbnQgZm9yIHZn
aWNfc3RvcmVfaXJvdXRlciB0byByZWZsZWN0IHBhcmFtZXRlcg0KPj4gwqDCoCBjaGFuZ2VzDQo+
PiAtIG1pbm9yIGNoYW5nZTogY2hhbmdlZCB0aGUgbWFjcm9zIEVTUElfSU5USUQySURYIGFuZCBF
U1BJX0lEWDJJTlRJRA0KPj4gwqDCoCBpbnRvIGFwcHJvcHJpYXRlIGlubGluZSBmdW5jdGlvbnMg
aW50cm9kdWNlZCBpbiB0aGUgcHJldmlvdXMgcGF0Y2gNCj4gDQo+IFJldmlld2VkLWJ5OiBPbGVr
c2FuZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5c2hjaGVua29AZXBhbS5jb20+DQo+IA0KPiBw
cmVmZXJhYmx5IHdpdGggdGhlIGNvbW1lbnRzIGJlbG93DQo+IA0KPj4NCj4+IENoYW5nZXMgaW4g
VjU6DQo+PiAtIHNpbmNlIGVTUEktc3BlY2lmaWMgZGVmaW5lcyBhbmQgbWFjcm9zIGFyZSBub3cg
YXZhaWxhYmxlIGV2ZW4gd2hlbiB0aGUNCj4+IMKgwqAgYXBwcm9wcmlhdGUgY29uZmlnIGlzIGRp
c2FibGVkLCB0aGlzIGFsbG93cyB1cyB0byByZW1vdmUgbWFueQ0KPj4gwqDCoCAjaWZkZWYgZ3Vh
cmRzIGFuZCByZXVzZSB0aGUgZXhpc3RpbmcgY29kZSBmb3IgcmVndWxhciBTUElzIGZvciANCj4+
IGVTUElzIGFzDQo+PiDCoMKgIHdlbGwsIGFzIGVTUElzIGFyZSBwcm9jZXNzZWQgc2ltaWxhcmx5
LiBUaGlzIGltcHJvdmVzIGNvZGUgcmVhZGFiaWxpdHkNCj4+IMKgwqAgYW5kIGNvbnNvbGlkYXRl
cyB0aGUgcmVnaXN0ZXIgcmFuZ2VzIGZvciBTUElzIGFuZCBlU1BJcyBpbiBhIHNpbmdsZQ0KPj4g
wqDCoCBwbGFjZSwgc2ltcGxpZnlpbmcgZnV0dXJlIGNoYW5nZXMgb3IgZml4ZXMgZm9yIFNQSXMg
YW5kIHRoZWlyDQo+PiDCoMKgIGNvdW50ZXJwYXJ0cyBmcm9tIHRoZSBleHRlbmRlZCByYW5nZQ0K
Pj4gLSBtb3ZlZCB2Z2ljX2V4dF9yYW5rX29mZnNldCgpIGZyb20NCj4+IMKgwqAgWzA4LzEyXSB4
ZW4vYXJtOiB2Z2ljOiBhZGQgcmVzb3VyY2UgbWFuYWdlbWVudCBmb3IgZXh0ZW5kZWQgU1BJcw0K
Pj4gwqDCoCBhcyB0aGUgZnVuY3Rpb24gd2FzIHVudXNlZCBiZWZvcmUgdGhpcyBwYXRjaA0KPj4g
LSBhZGRlZCBzdHViIGltcGxlbWVudGF0aW9uIG9mIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0KCkgd2hl
biANCj4+IENPTkZJR19HSUNWM19FU1BJPW4NCj4+IC0gcmVtb3ZlZCB1bm5lY2Vzc2FyeSBkZWZp
bmVzIGZvciByZXNlcnZlZCByYW5nZXMsIHdoaWNoIHdlcmUgDQo+PiBpbnRyb2R1Y2VkIGluDQo+
PiDCoMKgIFY0IHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mICNpZmRlZnMuIFRoZSBpc3N1ZSBpcyBu
b3cgcmVzb2x2ZWQgYnkNCj4+IMKgwqAgYWxsb3dpbmcgdGhlIHVzZSBvZiBTUEktc3BlY2lmaWMg
b2Zmc2V0cyBhbmQgcmV3b3JraW5nIHRoZSBsb2dpYw0KPj4NCj4+IENoYW5nZXMgaW4gVjQ6DQo+
PiAtIGFkZGVkIG1pc3NpbmcgUkFaIGFuZCB3cml0ZSBpZ25vcmUgZVNQSS1zcGVjaWZpYyByZWdp
c3RlcnMgcmFuZ2VzOg0KPj4gwqDCoCBHSUNEX05TQUNSbkUgYW5kIEdJQ0RfSUdSUE1PRFJuRQ0K
Pj4gLSBjaGFuZ2VkIHByZXZpb3VzbHkgcmVzZXJ2ZWQgcmFuZ2UgdG8gY292ZXIgR0lDRF9OU0FD
Um5FIGFuZA0KPj4gwqDCoCBHSUNEX0lHUlBNT0RSbkUNCj4+IC0gaW50cm9kdWNlZCBHSUNEX1JF
U0VSVkVEX1JBTkdFPG4+X1NUQVJUL0VORCBkZWZpbmVzIHRvIHJlbW92ZQ0KPj4gwqDCoCBoYXJk
Y29kZWQgdmFsdWVzIGFuZCByZWR1Y2UgdGhlIG51bWJlciBvZiBpZmRlZnMNCj4+IC0gZml4ZWQg
cmVzZXJ2ZWQgcmFuZ2VzIHdpdGggZVNQSSBvcHRpb24gZW5hYmxlZDogYWRkZWQgbWlzc2luZyBy
YW5nZQ0KPj4gwqDCoCAweDBGMzAtMHgwRjdDDQo+PiAtIHVwZGF0ZWQgdGhlIGxvZ2ljIGZvciBk
b21haW5zIHRoYXQgZG8gbm90IHN1cHBvcnQgZVNQSSwgYnV0IFhlbiBpcw0KPj4gwqDCoCBjb21w
aWxlZCB3aXRoIHRoZSBlU1BJIG9wdGlvbi4gTm93LCBwcmlvciB0byBvdGhlciBNTUlPIGNoZWNr
cywgd2UNCj4+IMKgwqAgdmVyaWZ5IHdoZXRoZXIgZVNQSSBpcyBhdmFpbGFibGUgZm9yIHRoZSBk
b21haW4gb3Igbm90LiBJZiBub3QsIGl0DQo+PiDCoMKgIGJlaGF2ZXMgYXMgaXQgZG9lcyBjdXJy
ZW50bHkgLSBSQVogYW5kIFdJDQo+PiAtIGZpeGVkIHByaW50IGZvciBHSUNEX0lDQUNUSVZFUm5F
DQo+PiAtIGZpeGVkIG5ldyBsaW5lcyBmb3JtYXR0aW5nIGZvciBzd2l0Y2gtY2FzZQ0KPj4NCj4+
IENoYW5nZXMgaW4gVjM6DQo+PiAtIGNoYW5nZWQgdmdpY19zdG9yZV9pcm91dGVyIHBhcmFtZXRl
cnMgLSBpbnN0ZWFkIG9mIG9mZnNldCB2aXJxIGlzDQo+PiDCoMKgIHVzZWQsIHRvIHJlbW92ZSB0
aGUgYWRkaXRpb25hbCBib29sIGVzcGkgcGFyYW1ldGVyIGFuZCBzaW1wbGlmeQ0KPj4gwqDCoCBj
aGVja3MuIEFsc28sIGFkanVzdGVkIHBhcmFtZXRlcnMgZm9yIHJlZ3VsYXIgU1BJLiBTaW5jZSB0
aGUgb2Zmc2V0DQo+PiDCoMKgIHBhcmFtZXRlciB3YXMgdXNlZCBvbmx5IGZvciBjYWxjdWxhdGlu
ZyB2aXJxIG51bWJlciBhbmQgdGhlbiByZXVzZWQgDQo+PiBmb3INCj4+IMKgwqAgZmluZGluZyBy
YW5rIG9mZnNldCwgaXQgd2lsbCBub3QgYWZmZWN0IGZ1bmN0aW9uYWxpdHkuDQo+PiAtIGZpeGVk
IGZvcm1hdHRpbmcgZm9yIGdvdG8gbGFibGVzIC0gYWRkZWQgbmV3bGluZXMgYWZ0ZXIgY29uZGl0
aW9uDQo+PiAtIGZpeGVkIGxvZ3MgZm9yIEdJQ0RfSVNBQ1RJVkVSbkUgYW5kIEdJQ0RfSUNBQ1RJ
VkVSbkUgaGFuZGxlcnMNCj4+IC0gcmVtb3ZlZCAjaWZkZWZzIGluIDIgcGxhY2VzIHdoZXJlIHRo
ZXkgd2VyZSBhZGphY2VudCBhbmQgY291bGQgYmUgDQo+PiBtZXJnZWQNCj4+DQo+PiBDaGFuZ2Vz
IGluIFYyOg0KPj4gLSBhZGQgbWlzc2luZyByYW5rIGluZGV4IGNvbnZlcnNpb24gZm9yIHBlbmRp
bmcgYW5kIGluZmxpZ2h0IGlycXMNCj4+IC0tLQ0KPj4gwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUv
YXNtL3ZnaWMuaCB8wqDCoCA0ICsNCj4+IMKgIHhlbi9hcmNoL2FybS92Z2ljLXYzLmPCoMKgwqDC
oMKgwqDCoMKgwqAgfCAxOTggKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0NCj4+IMKg
IHhlbi9hcmNoL2FybS92Z2ljLmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDIyICsrKysN
Cj4+IMKgIDMgZmlsZXMgY2hhbmdlZCwgMTgwIGluc2VydGlvbnMoKyksIDQ0IGRlbGV0aW9ucygt
KQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oIGIv
eGVuL2FyY2gvYXJtL2luY2x1ZGUvIA0KPj4gYXNtL3ZnaWMuaA0KPj4gaW5kZXggYzUyYmJjYjEx
NS4uZGVjMDhhNzVhNCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92
Z2ljLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgNCj4+IEBAIC0z
MTQsNiArMzE0LDEwIEBAIGV4dGVybiBzdHJ1Y3QgdmdpY19pcnFfcmFuayANCj4+ICp2Z2ljX3Jh
bmtfb2Zmc2V0KHN0cnVjdCB2Y3B1ICp2LA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgYiwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgdW5zaWduZWQgaW50IG4sDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBzKTsNCj4+ICtleHRlcm4gc3RydWN0IHZnaWNfaXJx
X3JhbmsgKnZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHN0cnVjdCB2Y3B1ICp2LA0KPj4gK8KgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBiLA0KPj4gK8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBuLA0K
Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGlu
dCBzKTsNCj4+IMKgIGV4dGVybiBzdHJ1Y3QgdmdpY19pcnFfcmFuayAqdmdpY19yYW5rX2lycShz
dHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgDQo+PiBpbnQgaXJxKTsNCj4+IMKgIGV4dGVybiB2b2lk
IHZnaWNfZGlzYWJsZV9pcnFzKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCByLCB1bnNpZ25lZCAN
Cj4+IGludCBuKTsNCj4+IMKgIGV4dGVybiB2b2lkIHZnaWNfZW5hYmxlX2lycXMoc3RydWN0IHZj
cHUgKnYsIHVpbnQzMl90IHIsIHVuc2lnbmVkIA0KPj4gaW50IG4pOw0KPj4gZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL2FybS92Z2ljLXYzLmMgYi94ZW4vYXJjaC9hcm0vdmdpYy12My5jDQo+PiBpbmRl
eCA0MzY5YzU1MTc3Li4yN2FmMjQ3ZDMwIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL3Zn
aWMtdjMuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3ZnaWMtdjMuYw0KPj4gQEAgLTEwNywxNyAr
MTA3LDEyIEBAIHN0YXRpYyB1aW50NjRfdCB2Z2ljX2ZldGNoX2lyb3V0ZXIoc3RydWN0IA0KPj4g
dmdpY19pcnFfcmFuayAqcmFuaywNCj4+IMKgIC8qDQo+PiDCoMKgICogU3RvcmUgYW4gSVJPVVRF
UiByZWdpc3RlciBpbiBhIGNvbnZlbmllbnQgd2F5IGFuZCBtaWdyYXRlIHRoZSB2SVJRDQo+PiDC
oMKgICogaWYgbmVjZXNzYXJ5LiBUaGlzIGZ1bmN0aW9uIG9ubHkgZGVhbHMgd2l0aCBJUk9VVEVS
MzIgYW5kIG9ud2FyZHMuDQo+PiAtICoNCj4+IC0gKiBOb3RlIHRoZSBvZmZzZXQgd2lsbCBiZSBh
bGlnbmVkIHRvIHRoZSBhcHByb3ByaWF0ZSBib3VuZGFyeS4NCj4+IMKgwqAgKi8NCj4+IMKgIHN0
YXRpYyB2b2lkIHZnaWNfc3RvcmVfaXJvdXRlcihzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgDQo+
PiB2Z2ljX2lycV9yYW5rICpyYW5rLA0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgb2Zmc2V0LCB1aW50
NjRfdCBpcm91dGVyKQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgdmlycSwgdWludDY0X3QgaXJvdXRl
cikNCj4+IMKgIHsNCj4+IMKgwqDCoMKgwqAgc3RydWN0IHZjcHUgKm5ld192Y3B1LCAqb2xkX3Zj
cHU7DQo+PiAtwqDCoMKgIHVuc2lnbmVkIGludCB2aXJxOw0KPj4gLQ0KPj4gLcKgwqDCoCAvKiBU
aGVyZSBpcyAxIHZJUlEgcGVyIElST1VURVIgKi8NCj4gDQo+IFlvdSBzZWVtIHRvIGhhdmUgZHJv
cHBlZCBhIGNvbW1lbnQsIGJ1dCBub3QganVzdCBtb3ZlZCBpdCB0byB2aXJxIA0KPiBjYWxjdWxh
dGlvbiBvdXRzaWRlIG9mIHRoZSB2Z2ljX3N0b3JlX2lyb3V0ZXIoKSBpbiAiY2FzZSANCj4gVlJB
TkdFNjQoR0lDRF9JUk9VVEVSbkUsIEdJQ0RfSVJPVVRFUm5FTik6Ii4gSWYgdGhlIGNvbW1lbnQg
aXMgdmFsaWQgKEkgDQo+IGFzc3VtZSBzbyksIGl0IHdvdWxkIGJlIGJldHRlciB0byByZXRhaW4g
aXQuDQo+IA0KDQpPa2F5LCBJIHdpbGwgcmVzdG9yZSB0aGUgY29tbWVudC4NCg0KPj4gLcKgwqDC
oCB2aXJxID0gb2Zmc2V0IC8gTlJfQllURVNfUEVSX0lST1VURVI7DQo+PiArwqDCoMKgIHVuc2ln
bmVkIGludCBvZmZzZXQ7DQo+PiDCoMKgwqDCoMKgIC8qDQo+PiDCoMKgwqDCoMKgwqAgKiBUaGUg
SVJPVVRFUjAtMzEsIHVzZWQgZm9yIFNHSXMvUFBJcywgYXJlIHJlc2VydmVkIGFuZCBzaG91bGQN
Cj4+IEBAIC02NzMsNiArNjY4LDM0IEBAIHdyaXRlX3Jlc2VydmVkOg0KPj4gwqDCoMKgwqDCoCBy
ZXR1cm4gMTsNCj4+IMKgIH0NCj4+ICsvKg0KPj4gKyAqIFNpbmNlIGFsbCBlU1BJIGNvdW50ZXJw
YXJ0cyBvZiBTUEkgcmVnaXN0ZXJzIGJlbG9uZyB0byBsb3dlciBvZmZzZXRzLA0KPj4gKyAqIHdl
IGNhbiBjaGVjayB3aGV0aGVyIHRoZSByZWdpc3RlciBvZmZzZXQgaXMgbGVzcyB0aGFuIGVzcGlf
YmFzZSBhbmQsDQo+PiArICogaWYgc28sIHJldHVybiB0aGUgcmFuayBmb3IgcmVndWxhciBTUEku
IE90aGVyd2lzZSwgcmV0dXJuIHRoZSByYW5rDQo+PiArICogZm9yIGVTUEkuDQo+PiArICovDQo+
IA0KPiBOSVQ6IEkgd291bGQganVzdCB3cml0ZSB0aGUgZm9sbG93aW5nOg0KPiANCj4gVGhlIGFz
c3VtcHRpb24gaXMgdGhhdCBvZmZzZXRzIGJlbG93IGVzcGlfYmFzZSBhcmUgZm9yIHJlZ3VsYXIg
U1BJLCANCj4gd2hpbGUgdGhvc2UgYXQgb3IgYWJvdmUgYXJlIGZvciBlU1BJLg0KPiANCg0KSSBh
Z3JlZSwgeW91ciBjb21tZW50IGlzIHNpbXBsZXIgYW5kIGVhc2llciB0byB1bmRlcnN0YW5kLiA6
KSBUaGFuayB5b3UsIA0KSSB3aWxsIHVwZGF0ZSBpdCB0byB5b3VyIHZlcnNpb24uDQoNCj4+ICtz
dGF0aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9yYW5rKHN0cnVjdCB2
Y3B1ICp2LA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVu
c2lnbmVkIGludCBiLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHVpbnQzMl90IHJlZywNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB1bnNpZ25lZCBpbnQgcywNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCB1aW50MzJfdCBzcGlfYmFzZSwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1aW50MzJfdCBlc3BpX2Jhc2UpDQo+IA0KPiBJIGZpbmQg
dGhlIG5hbWUgInZnaWNfZ2V0X3JhbmsiIGEgYml0IGNvbmZ1c2luZyBzaW5jZSB0aGUgdmdpYy5j
IGFscmVhZHkgDQo+IGNvbnRhaW5zIHRoZSBoZWxwZXIgd2l0aCB0aGUgc2FtZSBuYW1lOg0KPiAN
Cj4gc3RhdGljIGlubGluZSBzdHJ1Y3QgdmdpY19pcnFfcmFuayAqdmdpY19nZXRfcmFuayhzdHJ1
Y3QgdmNwdSAqdiwNCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IHVuc2lnbmVkIGludCByYW5rKQ0KPiANCj4gU28gd2hhdCB3ZSBoYXZlIGZvciByZWd1bGFyIFNQ
SXMgaXM6DQo+IHZnaWNfZ2V0X3JhbmsoKS0+dmdpY19yYW5rX29mZnNldCgpLT52Z2ljX2dldF9y
YW5rKCkNCj4gYW5kIGZvciBlU1BJcyBpczoNCj4gdmdpY19nZXRfcmFuaygpLT52Z2ljX2V4dF9y
YW5rX29mZnNldCgpLT52Z2ljX2dldF9yYW5rKCkNCj4gDQo+IEkgd291bGQgcmVuYW1lIGl0LCBl
LmcuIHZnaWNfY29tbW9uX3Jhbmtfb2Zmc2V0IChub3QgaWRlYWwgdGhvdWdoKQ0KPiANCj4gDQoN
Ckkgd2FudGVkIHRvIHVzZSBhIHNob3J0IG5hbWUgZm9yIGl0IHRvIGF2b2lkIGxvbmcgbGluZXMg
d2l0aCBmdW5jdGlvbiANCmNhbGxzIGJlY2F1c2UgaXQgaGFzIHNpeCBwYXJhbWV0ZXJzLiBJIGNo
b3NlIHRoaXMgbmFtaW5nLCBidXQgdGhlbiANCnJlYWxpemVkIHRoYXQgYSBzdGF0aWMgZnVuY3Rp
b24gd2l0aCB0aGUgc2FtZSBuYW1lIGlzIGFscmVhZHkgcHJlc2VudCBpbiANCnZnaWMuYywgYnV0
IEkgZGVjaWRlZCB0byBsZWF2ZSBpdC4uLg0KQnV0IHllcywgSSBhZ3JlZSAtIHRoZSBjYWxsIHN0
YWNrIGxvb2tzIHdlaXJkIGluIHRoaXMgY2FzZSwgc28gSSB3aWxsIA0KcmVuYW1lIHRoZSBmdW5j
dGlvbiB0byB2Z2ljX2NvbW1vbl9yYW5rX29mZnNldCgpLg0KDQo+PiArew0KPj4gK8KgwqDCoCBp
ZiAoIHJlZyA8IGVzcGlfYmFzZSApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuIHZnaWNfcmFu
a19vZmZzZXQodiwgYiwgcmVnIC0gc3BpX2Jhc2UsIHMpOw0KPj4gK8KgwqDCoCBlbHNlDQo+PiAr
wqDCoMKgwqDCoMKgwqAgcmV0dXJuIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0KHYsIGIsIHJlZyAtIGVz
cGlfYmFzZSwgcyk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgdWludDMyX3Qgdmdp
Y19nZXRfcmVnX29mZnNldCh1aW50MzJfdCByZWcsIHVpbnQzMl90IA0KPj4gc3BpX2Jhc2UsDQo+
PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVpbnQzMl90IGVzcGlfYmFzZSkNCj4+ICt7
DQo+PiArwqDCoMKgIGlmICggcmVnIDwgZXNwaV9iYXNlICkNCj4+ICvCoMKgwqDCoMKgwqDCoCBy
ZXR1cm4gcmVnIC0gc3BpX2Jhc2U7DQo+PiArwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDC
oCByZXR1cm4gcmVnIC0gZXNwaV9iYXNlOw0KPj4gK30NCj4gDQo+IEkgYW0gd29uZGVyaW5nIChJ
IGRvIG5vdCByZXF1ZXN0IGEgY2hhbmdlKSB3aGV0aGVyIHZnaWNfZ2V0X3JlZ19vZmZzZXQoKSAN
Cj4gaXMgcmVhbGx5IGhlbHBmdWxsLA0KPiBlLmcuIGlzDQo+ICDCoG9mZnNldCA9IHZnaWNfZ2V0
X3JlZ19vZmZzZXQocmVnLCBHSUNEX0lQUklPUklUWVIsIEdJQ0RfSVBSSU9SSVRZUm5FKTsNCj4g
bXVjaCBiZXR0ZXIgdGhhbjoNCj4gIMKgb2Zmc2V0ID0gcmVnIDwgR0lDRF9JUFJJT1JJVFlSbkUg
PyByZWcgLSBHSUNEX0lQUklPUklUWVIgOiByZWcgLSANCj4gR0lDRF9JUFJJT1JJVFlSbkU7DQo+
IA0KPiA/DQo+IA0KPiBbc25pcF0NCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:20:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:20:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109451.1459028 (Exim 4.92)
	(envelope-from )
	id 1uu3Kf-0000K5-BX; Thu, 04 Sep 2025 06:20:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109451.1459028; Thu, 04 Sep 2025 06:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu3Kf-0000Jy-8k; Thu, 04 Sep 2025 06:20:29 +0000
Received: by outflank-mailman (input) for mailman id 1109451;
 Thu, 04 Sep 2025 06:20: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 1uu3Ke-0000Js-E5
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:20:28 +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 3f84d5b1-8957-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:20:27 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by PA1PR03MB11086.eurprd03.prod.outlook.com (2603:10a6:102:4fb::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 06:20:25 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 06:20: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: 3f84d5b1-8957-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RR4KeYDEofYujSjB7TgFlOsF2wTdt45J+J3FpuQRRH0tnlBROWkTqe5trV150Kavoj+TvwbQIVaKZ3ChcJFilixKkTzdmUZE7NdyfLSEkg9EO1foFDN4mRLqEPbKz6Y5hOiVRky+5I89S7hG4kpP9pvnJ3nCD1lfYeZNkZKiR6igp4HWw0XQjOLNCLzerE0DYo/D6Ndg/TkyW5DSJbJBagV5zKJkeKMeSXBlHYxelDUeMaoXJC++6hHCimGN78cnTZMDU6nAHDBFtLwOq0rfzULuZ1DdOoGtmq2GLhKoePI49N7spdvPzvPFaVvJhG6jXCSk1Z09P/2yWsaV6Rd48w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dGOBf3W/N99F3LGncR0USoJKNnIwRrqbcJfOkbIM0GU=;
 b=xmThJyRoq9OBt9lhc6YhtCdUEDdimt2U9VAdvU8n2ZiMvPgLik71v4khpxZK2RS7Bix+/ttOMx7WEI1mOPxwtpGRKDKO2k2plKZaHV3LdkN0uaOhJAx5+FmJUUeQ2YJ9Izf6zry64ZZXyuep3BuVL7I0Dkzv0dMWztcH7c7VVNDwMDy9HjpNayBN1sMN/sGhePSA2kylTQAebZlvF8JuE7s6cmWWuPexHemHJXSc/ECNLcvtr5KbkLp1jRz4yD6ZsfyJt5rX4VCXhTWmjvTKa+mcHOiO/wa4OtKRW2TAmWwEolFGkQGgzVhF1XxspERzL05y9RaseEHeWPqXT2cojQ==
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=dGOBf3W/N99F3LGncR0USoJKNnIwRrqbcJfOkbIM0GU=;
 b=fbAWCiEzk4B+AF9SIckZ/aP1fpdHJPowKyvaH76wA+jmltlnpGjRkX1nA9aYUBsTWvDyEyHVjhxDNrgyXWRKD4qm/9Q6oJwNN6oa5GTpmS6/GhG6PAZDrMHj2QdXcUTxidjWT+I6GTh+VkLWfglYCw4SPjQcq82brAC1iijcIsVst7nu9XsY/ZF8Z382himdWhMRh0HrSszMIkA39i1kPVXTlelygIMoPA2wBW9ZrTflNqqux4hY9OWgQrYkBY+TPhZO9vZbsIFgPjJbwFT5ZChNVZoDShkSZbH+QDY7IRcd/js1qC1fYdvuqdUYmjGxJPcwI2jAwB9gJzQhWfiFuA==
From: Leonid Komarianskyi 
To: Volodymyr Babchuk 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Topic: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcHN9AEk+ywvTyYUiwpifc3pdNG7SCjj+A
Date: Thu, 4 Sep 2025 06:20:24 +0000
Message-ID: <67215b0a-25d0-44e4-8e96-25f001208a17@epam.com>
References: 
 
 <87y0qvteka.fsf@epam.com>
In-Reply-To: <87y0qvteka.fsf@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|PA1PR03MB11086:EE_
x-ms-office365-filtering-correlation-id: 1c3be66b-9da0-4144-d51c-08ddeb7b2266
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?R3FSWDVDV2JWZlhwSWY5QlBRa2RGYW1FQU5uMHIvbnVOTTZwd2N0U0lTKy9E?=
 =?utf-8?B?c0RjVHdUV1JnRGNBR0RKeHlxenpUV0M2WE01Rms4MlkxWWl3clhyVC9LZzhx?=
 =?utf-8?B?aWJwVlVocHpqcmxESUpwRXJpTVNzNG9LQ0RQbDR5eVlvWDZ0OTBtZ3lVL1Fw?=
 =?utf-8?B?T0dhNHZaYWhQeHN5VFYrUkY1bnpVaUFXK25HZG9VZGFMNWJOeFpkL0hvSmhw?=
 =?utf-8?B?VGwyVS8vWEVDNk42NFhaQ09rZDgvcW1RMWVDTTE1NjQ4aTRvRzFPUzcyQlp3?=
 =?utf-8?B?TXlOaEJvbDh3bDVZeWdqS095WmlhUW1FUW54Zm9MZzRsSHpEMm1GUG1oSVl5?=
 =?utf-8?B?Rys4U2p3anliSm10U1JjWHRmZDdOMktUWHpKczI1NTRxNlZyTmZQTnJnSkpZ?=
 =?utf-8?B?czNLV2NNVkg1aGI5WWtEMENxeElqa3JZN0E2ZFBSYTAvU2hoTk9ZWWhIT0J4?=
 =?utf-8?B?WURRcXVwcTJiT3hFSFg2VHRnZUJ2dC96ejlwQVd0RDlmT2lQZG01MCt6WmRq?=
 =?utf-8?B?SE54bFlZdmFzZkxoVGtnc0graldYZWg0VU1WUklvSHU3S005c3NsNjkrWUdQ?=
 =?utf-8?B?d1U2RGNBY1ZnbWdTZWxwcURWb1c4Q3ppNXRudksyTW1NQjNYMjZXVXQ4YzQv?=
 =?utf-8?B?VjNXZTlSRnhYOEVJVWY5T2pRL0FzZWZlN0tBWVNlWnYyUXQrWEtMTHd0TE00?=
 =?utf-8?B?MndWQmlJenhqMkdyNWxmR1BEcDdvUUIxZDlUSkpHRTdSZzg2U3I1NXBHZk81?=
 =?utf-8?B?YkxxUGF0dDdSOG1sNG1QUHBYUHh5WktqQTQrZE95MUFFcFR5WC9SS1AwVmM3?=
 =?utf-8?B?Z0lsWEVaT0NvR0RuVG9mejF1SzNqZENCaUEzK2toVFI5YkN1S3k0TWR1TzU3?=
 =?utf-8?B?SnU5RnNHUk5KeWhrK3g5enFlMXExS05BbHduaERnT1FNdEZ6SlpRbjVZSkxX?=
 =?utf-8?B?NXJIem8yUjE4MitWQmROTDU0U1VFQ2xUUm5GYURNbXlRSFJDcDJFVHZ4Q0I3?=
 =?utf-8?B?RFA4US9pVEg5WmNYM1l4QzBaUXh2KzRwUTRXL3ByOGlUZzVLakorOGZLQzhz?=
 =?utf-8?B?SmhYZ21WZGd5L0ZUVUJyUGxPd0k5N0JUN0xVa0I4RW9aYW5ETUpqQW5xQjlB?=
 =?utf-8?B?eEg3dG5scmFmOUpac3B4WDByNkx6Uzd0UkJEc21zVUJyWUFMNDZPMzgzSzl3?=
 =?utf-8?B?Snc3dmRuNmNwR0VrcUlHNStvTEpmKzJYYjE4VkZpd0VJanRUeUpzaGFOTGlu?=
 =?utf-8?B?SWUxei9iT040NEFIRjRseW9UcUFhUDVHTDdRQ3FRYnZxWmw4YlJKLzlHcW5O?=
 =?utf-8?B?SXJDV1Y1UGNZZ0wvakwzNXpXb2tJMEFFa3Y5ai9QRHI2Z29vWFNDTmtaNjhs?=
 =?utf-8?B?YjBmZndxVXovU0V1Zyt5RWRiYlhHQ3hCemUyTi9SZ1cvUll1V3VyckpEaFV4?=
 =?utf-8?B?RDk2dk1UOC9PTGpBbXFwZHNpVWIwTGMvaG5TSDFzYVc1cG9tUUhZenFNRDFS?=
 =?utf-8?B?LzJUc1RYQXdGdllvVVN0TW9EZ2FVRUZ0ZTVBR3pLeEZGN2ZYZ21tczdNZDdh?=
 =?utf-8?B?K0wrNlE2OGNtanJpalBRcXJLWHNDR3pjK0l5aHp3SHdUUlp3MFJDYm1lajVo?=
 =?utf-8?B?YTg2WFY1OE9yamg2YmhDNC9PWmJDZVFHWXFraGFhVHhHL1lXUU9ES1I2V1NH?=
 =?utf-8?B?S1RjaGp1OG5wRVQ0ZDFoOWhMallZRHVqKzduM1dTYXhCdmNNRXNCazJ6aEVW?=
 =?utf-8?B?UzgxU1dCZEJXNkdESDRrZjJWT0lOSlNFVmNuMHk0bUZxVVl4YkJoeFpSakxQ?=
 =?utf-8?B?QjBPZVNZUEN2cWpRTzQzalhrNmsxZTJGckl6THhzRElybkM1azBHekFjNFlK?=
 =?utf-8?B?Y3dqakdrNE82cVpjZ1JFdStaZTVTWFczek1wd05seXlxR2ZGVVZucnFucGRQ?=
 =?utf-8?B?eHVWWG1xTmRMZXc1ZFhYaW0yTFF1dHFkQWlROVNvOUlLL1Z5U0lvWFZFMExv?=
 =?utf-8?B?Y0pUcm43S1R3PT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?czR5TGlNdW5MNlhaQ2QvM0JkcEJ6MGZiT1RnS3crbW4yY3pDTlNtVVBoS3ho?=
 =?utf-8?B?OEJkK01BRkxEclpOaWgwa1Q5NWZDbWlHSlZPaExNaDRRVUFNWlZEcEhzTEhB?=
 =?utf-8?B?SkJFamgzeTlTOGhYbFV0WkxUczdBc0lScEtTWmF5SWFqZzN4aEJrZDAvMUtK?=
 =?utf-8?B?U2luWHJzSU5RTFBUczhUMjlTWUgrNkZZalFpTzdoWjdrejJ4NlFITURnT25v?=
 =?utf-8?B?Qm9GNEd4b29FVEJKRVdERFE3amlEVUFjMDlKdnpKTEtGR0U2bi9LQjRIVzFh?=
 =?utf-8?B?YVdrOXlwekQ5MmYvV010b1RWOFJtSURmd09rSmlZVXN3Zm1kN3hwcTNEYkxF?=
 =?utf-8?B?Q2x5UWo0dFIvdnh1aDIzVXprTHZ1UXJmZVhma3lXT1ptd2hhZWl2c3ZSV0xM?=
 =?utf-8?B?YzFmSWk3RGhxWStSNnREUzhBYSsxOXhlY3NCdzFLa3BJVi9DWUdFYTBoN1Js?=
 =?utf-8?B?dURRTm4yUCtadW1zdDU2M1BTQlkyck05QmVQNllYVTU2UjZqODlVbnUzai9B?=
 =?utf-8?B?Qm84c1RjQm5jZ1h5RnpvaU5Ybk41WHFmNzZCTWgxY2l5eVZxV1p1VHVnTVRl?=
 =?utf-8?B?TStJQUE0eUI0K3RrREt0Qk5oZjdOL3JUOXp0ejVGT1pnT3E5ak9WbTVFUnAv?=
 =?utf-8?B?c2VHM3RORUM1ZlQwTmZ0ZjdCcEZZVVZYRXlhT1NKK1VnSFlYdi9nd3ZUTDZq?=
 =?utf-8?B?ZVNZdWVHNHFwWVhBOGVRcHBsYkNDZnBjeVZ1SFM1YUJYdDUyRXh5RlRlRW9p?=
 =?utf-8?B?WGRxVGt4ZU1FekZjYTBEK25lVzNTYWQvaDkxVlNqMTd6czdnNlZLK1pWbjcr?=
 =?utf-8?B?TEszbHRiK0tBUFk4TnB2NU9lbGxUTGNkdVhJYWRFQ1dPMGxudU1CcTNZdDlr?=
 =?utf-8?B?enFnVE9ucU0rY3dnenk5emNRYTlZcFVzaDVOaE9uSDlpRGJ0Ni95czYrTmND?=
 =?utf-8?B?MGlOd0lGYUV5T0p3VzNsZG9XMU9Rbm43U2wzNjNDYkxFN2lORUkvdGNhMWxT?=
 =?utf-8?B?WlM1RDl2aFI4eDNGZnBWZ2UxWmorSkNQQUFkLzltRkRNcjFuNUlab0sra0kv?=
 =?utf-8?B?L0szaUdLNmhuNUFtRUNtMFQzMXpadElRRTdQMUZSMWhlV3JobjU1SE1nWitq?=
 =?utf-8?B?Y25ncG41bFJoeVprczB1UUNObkxvRk1MSjYyTEQrMjAzNXlxVnIvc1VNS1ZP?=
 =?utf-8?B?WnBYeWdDeXYzZlJiWmVUNkYxRWNHVGdBRitpTUs2RUxwRkpRR1FCYVQ5ZnRS?=
 =?utf-8?B?UHRTdjIvU1MwWEpHRm1jQ0NoVEVNV0t3QzlZZFpVTXoyWkR0citTZWc3dXo4?=
 =?utf-8?B?VEhsbFNVdEt5OGc4bVJudWh3SnV6T3A1Ym5qQ2l3elN2R1ptUlRCbTVndGV2?=
 =?utf-8?B?QTF0WVA2TENQTUJ0T29jLzUzTjB2ZEZ1ZUJyS1RjVjU0aWFYWmlLQU4ycGUv?=
 =?utf-8?B?U1lpY3FnSENybjdhQWJ3OFFEYkl4dUcrakZDdWUveUZ6UFRiS1dxVU91VmZu?=
 =?utf-8?B?M0NqaFl0dHdWYjRZemtEZWdBVnQra2xEemlydDBWSjJ6RG9oY2hUc0hHTWdr?=
 =?utf-8?B?dGovMS9tVjZYRlUzeHZXM3dsWXpGbldUME96TXcydDV5ei9nM2RTWXJpcURN?=
 =?utf-8?B?eVQ4NEllMnhwR2kzVGtFRVowRXFUZTlxckRWUTZwOWtUNDRCZGtWOHhjbEto?=
 =?utf-8?B?OTVmZTZuekhNL1g3ckFPU2Y4REJOdE1mYUVwYVNVdXZoenFCZjVDTS9KWFMy?=
 =?utf-8?B?NGxMNWR4dzNqYjBvdjdqK2NlWVJ3TGU5Y3d5NU9JSERWQ0pMMW5GNnFSRkJ0?=
 =?utf-8?B?ZmNvVEhtUUNLMU9zQnJzMG9LWllEcW0venNZdThoMFFxYWM4bFJnKzVQWWcr?=
 =?utf-8?B?amh1dnAyc3BkVVlyYUU0KzFteVZFc1BZdWplQ1ZNMXJGQ09jTjgyckF3dnhY?=
 =?utf-8?B?STFwYVY0N1FNNGlIaS9tNU56OFNjU25XdWhvK21OUGY1TStybjIwK1pFZnBH?=
 =?utf-8?B?ejFCcDE2OENNWnJic3ZNNzc5am93cHV1NWZCb2tIbUxraFBuYWN2a3YvSk5j?=
 =?utf-8?B?OUZORnVoRTF0anQ2bmVveG1BMlNpT0R5TVBDK0ptOHFCYlZDcWVjMHBUc2tT?=
 =?utf-8?B?NlduUFg2Y2VoUnBaam1ldExyWXlyVldiWFR4czU5UWY1Q2pDcUdBYjh2byt0?=
 =?utf-8?Q?Uvf9FOlUapQtbi6cjR3cGl4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0685D5C6F0A3D0418BF2A3241572649F@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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c3be66b-9da0-4144-d51c-08ddeb7b2266
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 06:20:24.6728
 (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: +V9lwUzB8HRFIhMqerJTII/E4bBO4w2r+VpLLeXv+61i/CU1p0a0WvMuVx7dIw40AkUBgXRnNsu9uOUKFdMyyGs7y7jlP0a49cK0mkefeeU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11086

SGkgVm9sb2R5bXlyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAwNC4wOS4y
NSAwMDoyNCwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+IEhpIExlb25pZCwNCj4gDQo+IExl
b25pZCBLb21hcmlhbnNreWkgPExlb25pZF9Lb21hcmlhbnNreWlAZXBhbS5jb20+IHdyaXRlczoN
Cj4gDQo+PiBUaGlzIGNoYW5nZSBpbnRyb2R1Y2VzIHJlc291cmNlIG1hbmFnZW1lbnQgaW4gdGhl
IFZHSUMgdG8gaGFuZGxlDQo+PiBleHRlbmRlZCBTUElzIGludHJvZHVjZWQgaW4gR0lDdjMuMS4g
VGhlIHBlbmRpbmdfaXJxcyBhbmQNCj4+IGFsbG9jYXRlZF9pcnFzIGFycmF5cyBhcmUgcmVzaXpl
ZCB0byBzdXBwb3J0IHRoZSByZXF1aXJlZA0KPj4gbnVtYmVyIG9mIGVTUElzLCBiYXNlZCBvbiB3
aGF0IGlzIHN1cHBvcnRlZCBieSB0aGUgaGFyZHdhcmUgYW5kDQo+PiByZXF1ZXN0ZWQgYnkgdGhl
IGd1ZXN0LiBBIG5ldyBmaWVsZCwgZXh0X3NoYXJlZF9pcnFzLCBpcyBhZGRlZA0KPj4gdG8gdGhl
IFZHSUMgc3RydWN0dXJlIHRvIHN0b3JlIGluZm9ybWF0aW9uIGFib3V0IGVTUElzLCBzaW1pbGFy
DQo+PiB0byBob3cgc2hhcmVkX2lycXMgaXMgdXNlZCBmb3IgcmVndWxhciBTUElzLg0KPj4NCj4+
IFNpbmNlIHRoZSBlU1BJIHJhbmdlIHN0YXJ0cyBhdCBJTlRJRCA0MDk2IGFuZCBJTlRJRHMgYmV0
d2VlbiAxMDI1DQo+PiBhbmQgNDA5NSBhcmUgcmVzZXJ2ZWQsIGhlbHBlciBtYWNyb3MgYXJlIGlu
dHJvZHVjZWQgdG8gc2ltcGxpZnkgdGhlDQo+PiB0cmFuc2Zvcm1hdGlvbiBvZiBpbmRpY2VzIGFu
ZCB0byBlbmFibGUgZWFzaWVyIGFjY2VzcyB0byBlU1BJLXNwZWNpZmljDQo+PiByZXNvdXJjZXMu
IFRoZXNlIGNoYW5nZXMgcHJlcGFyZSB0aGUgVkdJQyBmb3IgcHJvY2Vzc2luZyBlU1BJcyBhcw0K
Pj4gcmVxdWlyZWQgYnkgZnV0dXJlIGZ1bmN0aW9uYWxpdHkuDQo+Pg0KPj4gVGhlIGluaXRpYWxp
emF0aW9uIGFuZCBkZWluaXRpYWxpemF0aW9uIHBhdGhzIGZvciB2Z2ljIGhhdmUgYmVlbiB1cGRh
dGVkDQo+PiB0byBhbGxvY2F0ZSBhbmQgZnJlZSB0aGVzZSByZXNvdXJjZXMgYXBwcm9wcmlhdGVs
eS4gQWRkaXRpb25hbGx5LA0KPj4gdXBkYXRlZCBoYW5kbGluZyBvZiBJTlRJRHMgZ3JlYXRlciB0
aGFuIDEwMjQsIHBhc3NlZCBmcm9tIHRoZSB0b29sc3RhY2sNCj4+IGR1cmluZyBkb21haW4gY3Jl
YXRpb24sIGFuZCB2ZXJpZmljYXRpb24gbG9naWMgZW5zdXJlcyBvbmx5IHZhbGlkIFNQSSBvcg0K
Pj4gZVNQSSBJTlRJRHMgYXJlIHVzZWQuDQo+Pg0KPj4gVGhlIGV4aXN0aW5nIFNQSSBiZWhhdmlv
ciByZW1haW5zIHVuYWZmZWN0ZWQgd2hlbiBndWVzdHMgZG8gbm90IHJlcXVlc3QNCj4+IGVTUElz
LCBHSUMgaGFyZHdhcmUgZG9lcyBub3Qgc3VwcG9ydCB0aGVtLCBvciB0aGUgQ09ORklHX0dJQ1Yz
X0VTUEkNCj4+IG9wdGlvbiBpcyBkaXNhYmxlZC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBMZW9u
aWQgS29tYXJpYW5za3lpIDxsZW9uaWRfa29tYXJpYW5za3lpQGVwYW0uY29tPg0KPj4NCj4+IC0t
LQ0KPj4gQ2hhbmdlcyBmb3IgVjY6DQo+PiAtIGludHJvZHVjZWQgYSBuZXcgZnVuY3Rpb24gZm9y
IGluZGV4IHRvIHZpcnEgY29udmVyc2lvbiwgaWR4X3RvX3ZpcnEuDQo+PiAgICBUaGlzIGFsbG93
cyB0aGUgcmVtb3ZhbCBvZiBlU1BJLXNwZWNpZmljIGZ1bmN0aW9ucyBhbmQgZW5hYmxlcyB0aGUN
Cj4+ICAgIHJldXNlIG9mIGV4aXN0aW5nIGNvZGUgZm9yIHJlZ3VsYXIgU1BJcw0KPj4gLSBmaXhl
ZCB0aGUgcmV0dXJuIHZhbHVlIG9mIHZnaWNfYWxsb2NhdGVfdmlycSBpbiB0aGUgY2FzZSBvZiBl
U1BJDQo+PiAtIHVwZGF0ZWQgdGhlIGVycm9yIG1lc3NhZ2UgaW4gcm91dGVfaXJxX3RvX2d1ZXN0
KCkuIFRvIHNpbXBsaWZ5IGl0IGFuZA0KPj4gICAgYXZvaWQgb3ZlcmNvbXBsaWNhdGluZyB3aXRo
IElOVElEIHJhbmdlcywgcHJvcG9zZSByZW1vdmluZyB0aGUNCj4+ICAgIGluZm9ybWF0aW9uIGFi
b3V0IHRoZSBtYXggbnVtYmVyIG9mIElSUXMNCj4+IC0gZml4ZWQgZVNQSSByYW5rIGluaXRpYWxp
emF0aW9uIHRvIGF2b2lkIHVzaW5nIEVYVF9SQU5LX0lEWDJOVU0gZm9yDQo+PiAgICBjb252ZXJ0
aW5nIHRoZSBlU1BJIHJhbmsgdG8gdGhlIGV4dGVuZGVkIHJhbmdlDQo+PiAtIHVwZGF0ZWQgdGhl
IHJlY2FsY3VsYXRpb24gbG9naWMgdG8gYXZvaWQgdGhlIG5yX3NwaXMgPiAxMDIwIC0NCj4+ICAg
IE5SX0xPQ0FMX0lSUVMgY2hlY2sgd2hlbiBucl9zcGlzIGlzIHJlYXNzaWduZWQgaW4gdGhlIGNh
c2Ugb2YgZVNQSQ0KPj4gLSBmaXhlZCBmb3JtYXR0aW5nIGlzc3VlcyBmb3IgbWFjcm9zDQo+PiAt
IG1pbm9yIGNoYW5nZTogY2hhbmdlZCB0aGUgbWFjcm9zIEVTUElfSU5USUQySURYIGFuZCBFU1BJ
X0lEWDJJTlRJRA0KPj4gICAgaW50byBhcHByb3ByaWF0ZSBpbmxpbmUgZnVuY3Rpb25zIGludHJv
ZHVjZWQgaW4gdGhlIHByZXZpb3VzIHBhdGNoDQo+PiAtIG1pbm9yIGNoYW5nZTogY2hhbmdlZCBp
bnQgdG8gdW5zaWduZWQgaW50IGZvciBucl9lc3Bpcw0KPj4NCj4+IENoYW5nZXMgaW4gVjU6DQo+
PiAtIHJlbW92ZWQgdGhlIGhhc19lc3BpIGZpZWxkIGJlY2F1c2UgaXQgY2FuIGJlIGRldGVybWlu
ZWQgYnkgY2hlY2tpbmcNCj4+ICAgIHdoZXRoZXIgZG9tYWluLT5hcmNoLnZnaWMubnJfZXNwaXMg
aXMgemVybyBvciBub3QNCj4+IC0gc2luY2UgdmdpY19leHRfcmFua19vZmZzZXQgaXMgbm90IHVz
ZWQgaW4gdGhpcyBwYXRjaCwgaXQgaGFzIGJlZW4NCj4+ICAgIG1vdmVkIHRvIHRoZSBhcHByb3By
aWF0ZSBwYXRjaCBpbiB0aGUgcGF0Y2ggc2VyaWVzLCB3aGljaCBpbXBsZW1lbnRzDQo+PiAgICB2
Z2ljIGVTUEkgcmVnaXN0ZXJzIGVtdWxhdGlvbiBhbmQgcmVxdWlyZXMgdGhpcyBmdW5jdGlvbg0K
Pj4gLSByZW1vdmVkIGlmZGVmcyBmb3IgZVNQSS1zcGVjaWZpYyBtYWNyb3MgdG8gcmVkdWNlIHRo
ZSBudW1iZXIgb2YgaWZkZWZzDQo+PiAgICBhbmQgY29kZSBkdXBsaWNhdGlvbiBpbiBmdXJ0aGVy
IGNoYW5nZXMNCj4+IC0gZml4ZWQgbWlub3Igbml0OiB1c2VkICVwZCBmb3IgcHJpbnRpbmcgZG9t
YWluIHdpdGggaXRzIElEDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWNDoNCj4+IC0gYWRkZWQgaGFzX2Vz
cGkgZmllbGQgdG8gc2ltcGxpZnkgZGV0ZXJtaW5pbmcgd2hldGhlciBhIGRvbWFpbiBpcyBhYmxl
DQo+PiAgICB0byBvcGVyYXRlIHdpdGggZVNQSQ0KPj4gLSBmaXhlZCBmb3JtYXR0aW5nIGlzc3Vl
cyBhbmQgbWlzc3BlbGxpbmdzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMzoNCj4+IC0gZml4ZWQgZm9y
bWF0dGluZyBmb3IgbGluZXMgd2l0aCBtb3JlIHRoYW4gODAgc3ltYm9scw0KPj4gLSBpbnRyb2R1
Y2VkIGhlbHBlciBmdW5jdGlvbnMgdG8gYmUgYWJsZSB0byB1c2Ugc3R1YnMgaW4gY2FzZSBvZg0K
Pj4gICAgQ09ORklHX0dJQ1YzX0VTUEkgZGlzYWJsZWQsIGFuZCBhcyBhIHJlc3VsdCwgcmVkdWNl
IHRoZSBudW1iZXIgb2YNCj4+ICAgICNpZmRlZnMNCj4+IC0gZml4ZWQgY2hlY2tzIGZvciBucl9z
cGlzIGluIGRvbWFpbl92Z2ljX2luaXQNCj4+IC0gdXBkYXRlZCBjb21tZW50IGFib3V0IG5yX3Nw
aXMgYWRqdXN0bWVudHMgd2l0aCBkb20wbGVzcyBtZW50aW9uDQo+PiAtIG1vdmVkIGNvbW1lbnQg
d2l0aCBhZGRpdGlvbmFsIGV4cGxhbmF0aW9ucyBiZWZvcmUgY2hlY2tzDQo+PiAtIHVzZWQgdW5z
aWduZWQgaW50IGZvciBpbmRleGVzIHNpbmNlIHRoZXkgY2Fubm90IGJlIG5lZ2F0aXZlDQo+PiAt
IHJlbW92ZWQgdW5uZWNlc3NhcnkgcGFyZW50aGVzZXMNCj4+IC0gbW92ZSB2Z2ljX2V4dF9yYW5r
X29mZnNldCB0byB0aGUgYmVsb3cgaWZkZWYgZ3VhcmQsIHRvIHJlZHVjZSB0aGUNCj4+ICAgIG51
bWJlciBvZiBpZmRlZnMNCj4+DQo+PiBDaGFuZ2VzIGluIFYyOg0KPj4gLSBjaGFuZ2UgaXNfZXNw
aV9yYW5rIHRvIGlzX3ZhbGlkX2VzcGlfcmFuayB0byB2ZXJpZnkgd2hldGhlciB0aGUgYXJyYXkN
Cj4+ICAgIGVsZW1lbnQgZXh0X3NoYXJlZF9pcnFzIGV4aXN0cy4gVGhlIHByZXZpb3VzIHZlcnNp
b24sIGlzX2VzcGlfcmFuaywNCj4+ICAgIG9ubHkgY2hlY2tlZCBpZiB0aGUgcmFuayBpbmRleCB3
YXMgbGVzcyB0aGFuIHRoZSBtYXhpbXVtIHBvc3NpYmxlIGVTUEkNCj4+ICAgIHJhbmsgaW5kZXgs
IGJ1dCB0aGlzIGNvdWxkIHBvdGVudGlhbGx5IHJlc3VsdCBpbiBhY2Nlc3NpbmcgYQ0KPj4gICAg
bm9uLWV4aXN0aW5nIGFycmF5IGVsZW1lbnQuIFRvIGFkZHJlc3MgdGhpcywgaXNfdmFsaWRfZXNw
aV9yYW5rIHdhcw0KPj4gICAgaW50cm9kdWNlZCwgd2hpY2ggZW5zdXJlcyB0aGF0IHRoZSByZXF1
aXJlZCBlU1BJIHJhbmsgZXhpc3RzDQo+PiAtIG1vdmUgZ2ljX251bWJlcl9lc3BpcyB0bw0KPj4g
ICAgeGVuL2FybTogZ2ljdjM6IGltcGxlbWVudCBoYW5kbGluZyBvZiBHSUN2My4xIGVTUEkNCj4+
IC0gdXBkYXRlIHZnaWNfaXNfdmFsaWRfaXJxIGNoZWNrcyB0byBhbGxvdyBvcGVyYXRpbmcgd2l0
aCBlU1BJcw0KPj4gLSByZW1vdmUgcmVkdW5kYW50IG5ld2xpbmUgaW4gdmdpY19hbGxvY2F0ZV92
aXJxDQo+PiAtLS0NCj4+ICAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaCB8ICAxMiAr
KysNCj4+ICAgeGVuL2FyY2gvYXJtL2lycS5jICAgICAgICAgICAgICB8ICAgMyArLQ0KPj4gICB4
ZW4vYXJjaC9hcm0vdmdpYy5jICAgICAgICAgICAgIHwgMTc0ICsrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKy0tDQo+PiAgIDMgZmlsZXMgY2hhbmdlZCwgMTc2IGluc2VydGlvbnMoKyksIDEz
IGRlbGV0aW9ucygtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h
c20vdmdpYy5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3ZnaWMuaA0KPj4gaW5kZXggM2U3
Y2JiYjE5Ni4uMWNmMGEwNTgzMiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRl
L2FzbS92Z2ljLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgNCj4+
IEBAIC0xNDYsNiArMTQ2LDEwIEBAIHN0cnVjdCB2Z2ljX2Rpc3Qgew0KPj4gICAgICAgaW50IG5y
X3NwaXM7IC8qIE51bWJlciBvZiBTUElzICovDQo+PiAgICAgICB1bnNpZ25lZCBsb25nICphbGxv
Y2F0ZWRfaXJxczsgLyogYml0bWFwIG9mIElSUXMgYWxsb2NhdGVkICovDQo+PiAgICAgICBzdHJ1
Y3QgdmdpY19pcnFfcmFuayAqc2hhcmVkX2lycXM7DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19F
U1BJDQo+PiArICAgIHN0cnVjdCB2Z2ljX2lycV9yYW5rICpleHRfc2hhcmVkX2lycXM7DQo+PiAr
ICAgIHVuc2lnbmVkIGludCBucl9lc3BpczsgLyogTnVtYmVyIG9mIGV4dGVuZGVkIFNQSXMgKi8N
Cj4+ICsjZW5kaWYNCj4+ICAgICAgIC8qDQo+PiAgICAgICAgKiBTUElzIGFyZSBkb21haW4gZ2xv
YmFsLCBTR0lzIGFuZCBQUElzIGFyZSBwZXItVkNQVSBhbmQgc3RvcmVkIGluDQo+PiAgICAgICAg
KiBzdHJ1Y3QgYXJjaF92Y3B1Lg0KPj4gQEAgLTI0Myw2ICsyNDcsMTQgQEAgc3RydWN0IHZnaWNf
b3BzIHsNCj4+ICAgLyogTnVtYmVyIG9mIHJhbmtzIG9mIGludGVycnVwdCByZWdpc3RlcnMgZm9y
IGEgZG9tYWluICovDQo+PiAgICNkZWZpbmUgRE9NQUlOX05SX1JBTktTKGQpICgoKGQpLT5hcmNo
LnZnaWMubnJfc3BpcyszMSkvMzIpDQo+PiAgIA0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQ
SQ0KPj4gKyNkZWZpbmUgRE9NQUlOX05SX0VYVF9SQU5LUyhkKSAoKChkKS0+YXJjaC52Z2ljLm5y
X2VzcGlzICsgMzEpIC8gMzIpDQo+PiArI2VuZGlmDQo+PiArI2RlZmluZSBFWFRfUkFOS19NSU4g
KEVTUElfQkFTRV9JTlRJRCAvIDMyKQ0KPj4gKyNkZWZpbmUgRVhUX1JBTktfTUFYICgoRVNQSV9N
QVhfSU5USUQgKyAzMSkgLyAzMikNCj4+ICsjZGVmaW5lIEVYVF9SQU5LX05VTTJJRFgobnVtKSAo
KG51bSkgLSBFWFRfUkFOS19NSU4pDQo+PiArI2RlZmluZSBFWFRfUkFOS19JRFgyTlVNKGlkeCkg
KChpZHgpICsgRVhUX1JBTktfTUlOKQ0KPj4gKw0KPj4gICAjZGVmaW5lIHZnaWNfbG9jayh2KSAg
IHNwaW5fbG9ja19pcnEoJih2KS0+ZG9tYWluLT5hcmNoLnZnaWMubG9jaykNCj4+ICAgI2RlZmlu
ZSB2Z2ljX3VubG9jayh2KSBzcGluX3VubG9ja19pcnEoJih2KS0+ZG9tYWluLT5hcmNoLnZnaWMu
bG9jaykNCj4+ICAgDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2lycS5jIGIveGVuL2Fy
Y2gvYXJtL2lycS5jDQo+PiBpbmRleCBjOTM0ZDM5YmY2Li5jMmYxY2ViOTFmIDEwMDY0NA0KPj4g
LS0tIGEveGVuL2FyY2gvYXJtL2lycS5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaXJxLmMNCj4+
IEBAIC00OTQsOCArNDk0LDcgQEAgaW50IHJvdXRlX2lycV90b19ndWVzdChzdHJ1Y3QgZG9tYWlu
ICpkLCB1bnNpZ25lZCBpbnQgdmlycSwNCj4+ICAgICAgIGlmICggIXZnaWNfaXNfdmFsaWRfbGlu
ZShkLCB2aXJxKSApDQo+PiAgICAgICB7DQo+PiAgICAgICAgICAgcHJpbnRrKFhFTkxPR19HX0VS
Ug0KPj4gLSAgICAgICAgICAgICAgICJ0aGUgdklSUSBudW1iZXIgJXUgaXMgdG9vIGhpZ2ggZm9y
IGRvbWFpbiAldSAobWF4ID0gJXUpXG4iLA0KPj4gLSAgICAgICAgICAgICAgIGlycSwgZC0+ZG9t
YWluX2lkLCB2Z2ljX251bV9pcnFzKGQpKTsNCj4+ICsgICAgICAgICAgICAgICAiaW52YWxpZCB2
SVJRIG51bWJlciAldSBmb3IgZG9tYWluICVwZFxuIiwgaXJxLCBkKTsNCj4+ICAgICAgICAgICBy
ZXR1cm4gLUVJTlZBTDsNCj4+ICAgICAgIH0NCj4+ICAgDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL3ZnaWMuYyBiL3hlbi9hcmNoL2FybS92Z2ljLmMNCj4+IGluZGV4IDJiYmY0ZDk5YWEu
LmI0MmFlZThkMGMgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiArKysg
Yi94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiBAQCAtMjUsMTEgKzI1LDYxIEBADQo+PiAgICNpbmNs
dWRlIDxhc20vdmdpYy5oPg0KPj4gICANCj4+ICAgDQo+PiArc3RhdGljIGlubGluZSB1bnNpZ25l
ZCBpbnQgaWR4X3RvX3ZpcnEoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IGlkeCkNCj4+
ICt7DQo+PiArICAgIGlmICggaWR4ID49IHZnaWNfbnVtX2lycXMoZCkgKQ0KPj4gKyAgICAgICAg
cmV0dXJuIGVzcGlfaWR4X3RvX2ludGlkKGlkeCAtIHZnaWNfbnVtX2lycXMoZCkpOw0KPj4gKw0K
Pj4gKyAgICByZXR1cm4gaWR4Ow0KPj4gK30NCj4+ICsNCj4+ICAgYm9vbCB2Z2ljX2lzX3ZhbGlk
X2xpbmUoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IHZpcnEpDQo+PiAgIHsNCj4+ICsj
aWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICsgICAgaWYgKCB2aXJxID49IEVTUElfQkFTRV9J
TlRJRCAmJg0KPj4gKyAgICAgICAgIHZpcnEgPCBlc3BpX2lkeF90b19pbnRpZChkLT5hcmNoLnZn
aWMubnJfZXNwaXMpICkNCj4+ICsgICAgICAgIHJldHVybiB0cnVlOw0KPj4gKyNlbmRpZg0KPj4g
Kw0KPj4gICAgICAgcmV0dXJuIHZpcnEgPCB2Z2ljX251bV9pcnFzKGQpOw0KPj4gICB9DQo+PiAg
IA0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gKy8qDQo+PiArICogU2luY2UgZVNQ
SSBpbmRleGVzIHN0YXJ0IGZyb20gNDA5NiBhbmQgbnVtYmVycyBmcm9tIDEwMjQgdG8NCj4+ICsg
KiA0MDk1IGFyZSBmb3JiaWRkZW4sIHdlIG5lZWQgdG8gY2hlY2sgYm90aCBsb3dlciBhbmQgdXBw
ZXINCj4+ICsgKiBsaW1pdHMgZm9yIHJhbmtzLg0KPj4gKyAqLw0KPj4gK3N0YXRpYyBpbmxpbmUg
Ym9vbCBpc192YWxpZF9lc3BpX3Jhbmsoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IHJh
bmspDQo+PiArew0KPj4gKyAgICByZXR1cm4gcmFuayA+PSBFWFRfUkFOS19NSU4gJiYNCj4+ICsg
ICAgICAgICAgIEVYVF9SQU5LX05VTTJJRFgocmFuaykgPCBET01BSU5fTlJfRVhUX1JBTktTKGQp
Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2
Z2ljX2dldF9lc3BpX3Jhbmsoc3RydWN0IHZjcHUgKnYsDQo+PiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByYW5rKQ0K
Pj4gK3sNCj4+ICsgICAgcmV0dXJuICZ2LT5kb21haW4tPmFyY2gudmdpYy5leHRfc2hhcmVkX2ly
cXNbRVhUX1JBTktfTlVNMklEWChyYW5rKV07DQo+PiArfQ0KPj4gKw0KPj4gKyNlbHNlDQo+PiAr
c3RhdGljIGlubGluZSBib29sIGlzX3ZhbGlkX2VzcGlfcmFuayhzdHJ1Y3QgZG9tYWluICpkLCB1
bnNpZ25lZCBpbnQgcmFuaykNCj4+ICt7DQo+PiArICAgIHJldHVybiBmYWxzZTsNCj4+ICt9DQo+
PiArDQo+PiArLyoNCj4+ICsgKiBUaGlzIGZ1bmN0aW9uIGlzIHN0dWIgYW5kIHdpbGwgbm90IGJl
IGNhbGxlZCBpZiBDT05GSUdfR0lDVjNfRVNQST1uLA0KPj4gKyAqIGJlY2F1c2UgaW4gdGhpcyBj
YXNlLCBpc192YWxpZF9lc3BpX3Jhbmsgd2lsbCBhbHdheXMgcmV0dXJuIGZhbHNlLg0KPj4gKyAq
Lw0KPj4gK3N0YXRpYyBpbmxpbmUgc3RydWN0IHZnaWNfaXJxX3JhbmsgKnZnaWNfZ2V0X2VzcGlf
cmFuayhzdHJ1Y3QgdmNwdSAqdiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHJhbmspDQo+PiArew0KPj4gKyAg
ICBBU1NFUlRfVU5SRUFDSEFCTEUoKTsNCj4+ICsgICAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4g
KyNlbmRpZg0KPj4gKw0KPj4gICBzdGF0aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2
Z2ljX2dldF9yYW5rKHN0cnVjdCB2Y3B1ICp2LA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByYW5rKQ0KPj4gICB7DQo+
PiBAQCAtMzcsNiArODcsOCBAQCBzdGF0aWMgaW5saW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2
Z2ljX2dldF9yYW5rKHN0cnVjdCB2Y3B1ICp2LA0KPj4gICAgICAgICAgIHJldHVybiB2LT5hcmNo
LnZnaWMucHJpdmF0ZV9pcnFzOw0KPj4gICAgICAgZWxzZSBpZiAoIHJhbmsgPD0gRE9NQUlOX05S
X1JBTktTKHYtPmRvbWFpbikgKQ0KPj4gICAgICAgICAgIHJldHVybiAmdi0+ZG9tYWluLT5hcmNo
LnZnaWMuc2hhcmVkX2lycXNbcmFuayAtIDFdOw0KPj4gKyAgICBlbHNlIGlmICggaXNfdmFsaWRf
ZXNwaV9yYW5rKHYtPmRvbWFpbiwgcmFuaykgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHZnaWNfZ2V0
X2VzcGlfcmFuayh2LCByYW5rKTsNCj4+ICAgICAgIGVsc2UNCj4+ICAgICAgICAgICByZXR1cm4g
TlVMTDsNCj4+ICAgfQ0KPj4gQEAgLTExNyw2ICsxNjksNTQgQEAgaW50IGRvbWFpbl92Z2ljX3Jl
Z2lzdGVyKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCAqbW1pb19jb3VudCkNCj4+ICAg
ICAgIHJldHVybiAwOw0KPj4gICB9DQo+PiAgIA0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQ
SQ0KPj4gK3N0YXRpYyB1bnNpZ25lZCBpbnQgdmdpY19udW1fc3BpX2xpbmVzKHN0cnVjdCBkb21h
aW4gKmQpDQo+PiArew0KPj4gKyAgICByZXR1cm4gZC0+YXJjaC52Z2ljLm5yX3NwaXMgKyBkLT5h
cmNoLnZnaWMubnJfZXNwaXM7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgaW5pdF92Z2lj
X2VzcGkoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArICAgIHVuc2lnbmVkIGludCBpLCBp
ZHg7DQo+PiArDQo+PiArICAgIGlmICggZC0+YXJjaC52Z2ljLm5yX2VzcGlzID09IDAgKQ0KPj4g
KyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIGQtPmFyY2gudmdpYy5leHRfc2hhcmVk
X2lycXMgPQ0KPj4gKyAgICAgICAgeHphbGxvY19hcnJheShzdHJ1Y3QgdmdpY19pcnFfcmFuaywg
RE9NQUlOX05SX0VYVF9SQU5LUyhkKSk7DQo+PiArICAgIGlmICggZC0+YXJjaC52Z2ljLmV4dF9z
aGFyZWRfaXJxcyA9PSBOVUxMICkNCj4+ICsgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPj4gKw0K
Pj4gKyAgICBmb3IgKCBpID0gZC0+YXJjaC52Z2ljLm5yX3NwaXMsIGlkeCA9IDA7DQo+PiArICAg
ICAgICAgIGkgPCB2Z2ljX251bV9zcGlfbGluZXMoZCk7IGkrKywgaWR4KysgKQ0KPj4gKyAgICAg
ICAgdmdpY19pbml0X3BlbmRpbmdfaXJxKCZkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFzW2ldLA0K
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVzcGlfaWR4X3RvX2ludGlkKGlkeCkp
Ow0KPj4gKw0KPj4gKyAgICBmb3IgKCBpID0gMDsgaSA8IERPTUFJTl9OUl9FWFRfUkFOS1MoZCk7
IGkrKyApDQo+PiArICAgICAgICB2Z2ljX3JhbmtfaW5pdCgmZC0+YXJjaC52Z2ljLmV4dF9zaGFy
ZWRfaXJxc1tpXSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgIEVYVF9SQU5LX0lEWDJOVU0o
aSksIDApOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArI2Vsc2UN
Cj4+ICtzdGF0aWMgaW50IGluaXRfdmdpY19lc3BpKHN0cnVjdCBkb21haW4gKmQpDQo+PiArew0K
Pj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHVuc2lnbmVkIGludCB2
Z2ljX251bV9zcGlfbGluZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArICAgIHJldHVy
biBkLT5hcmNoLnZnaWMubnJfc3BpczsNCj4+ICt9DQo+PiArDQo+PiArI2VuZGlmDQo+PiArDQo+
PiArc3RhdGljIHVuc2lnbmVkIGludCB2Z2ljX251bV9hbGxvY19pcnFzKHN0cnVjdCBkb21haW4g
KmQpDQo+PiArew0KPj4gKyAgICByZXR1cm4gdmdpY19udW1fc3BpX2xpbmVzKGQpICsgTlJfTE9D
QUxfSVJRUzsNCj4gDQo+IFRoaXMgaXMgZ29vZCB0aGF0IHlvdSBhcmUgdXNpbmcgTlJfTE9DQUxf
SVJRUyBoZXJlLg0KPiANCj4+ICt9DQo+PiArDQo+PiAgIGludCBkb21haW5fdmdpY19pbml0KHN0
cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBucl9zcGlzKQ0KPj4gICB7DQo+PiAgICAgICBp
bnQgaTsNCj4+IEBAIC0xMzMsNyArMjMzLDM5IEBAIGludCBkb21haW5fdmdpY19pbml0KHN0cnVj
dCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBucl9zcGlzKQ0KPj4gICANCj4+ICAgICAgIC8qIExp
bWl0IHRoZSBudW1iZXIgb2YgdmlydHVhbCBTUElzIHN1cHBvcnRlZCB0byAoMTAyMCAtIDMyKSA9
IDk4OCAgKi8NCj4+ICAgICAgIGlmICggbnJfc3BpcyA+ICgxMDIwIC0gTlJfTE9DQUxfSVJRUykg
KQ0KPj4gKyNpZm5kZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICAgICAgICAgICByZXR1cm4gLUVJ
TlZBTDsNCj4+ICsjZWxzZQ0KPj4gKyAgICB7DQo+PiArICAgICAgICAvKg0KPj4gKyAgICAgICAg
ICogRHVyaW5nIGRvbWFpbiBjcmVhdGlvbiwgdGhlIGRvbTBsZXNzIERvbVVzIGNvZGUgb3IgdG9v
bHN0YWNrDQo+PiArICAgICAgICAgKiBzcGVjaWZpZXMgdGhlIG1heGltdW0gSU5USUQsIHdoaWNo
IGlzIGRlZmluZWQgaW4gdGhlIGRvbWFpbg0KPj4gKyAgICAgICAgICogY29uZmlnIHN1YnRyYWN0
ZWQgYnkgMzIgdG8gY292ZXIgdGhlIGxvY2FsIElSUXMgKHBsZWFzZSBzZWUNCj4+ICsgICAgICAg
ICAqIHRoZSBjb21tZW50IHRvIFZHSUNfREVGX05SX1NQSVMpLiBUbyBjb21wdXRlIHRoZSBhY3R1
YWwgbnVtYmVyDQo+PiArICAgICAgICAgKiBvZiBlU1BJIHRoYXQgd2lsbCBiZSB1c2FibGUgZm9y
LCBhZGQgYmFjayAzMi4NCj4+ICsgICAgICAgICAqLw0KPj4gKyAgICAgICAgbnJfc3BpcyArPSAz
MjsNCj4gDQo+IEkgdGhpbmsgdGhhdCBpdCBpcyBiZXR0ZXIgdG8gdXNlIE5SX0xPQ0FMX0lSUVMg
aGVyZS4NCj4gDQo+IChBbHNvLCBJIGp1c3Qgbm90aWNlZCB0aGUgc2FtZSBwcm9ibGVtIGFzIHdp
dGggZG9jdW1lbnRhdGlvbiwgbWVhbmluZw0KPiB0aGF0IG5yX3NwaXMgYWN0dWFsbHkgZG9lcyBu
b3QgcmVwcmVzZW50IG51bWJlciBvZiBTUElzIGFueW1vcmUsIGFuZA0KPiBiZWhhdmVzIG1vcmUg
bGlrZSBtYXhfc3BpLCBidXQgbGV0J3Mgc2V0IHRoaXMgaXNzdWUgYXNpZGUgZm9yIG5vdykNCj4g
DQo+PiArICAgICAgICBpZiAoIG5yX3NwaXMgPiBlc3BpX2lkeF90b19pbnRpZChOUl9FU1BJX0lS
UVMpICkNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAgICAg
IGlmICggbnJfc3BpcyA+PSBFU1BJX0JBU0VfSU5USUQgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAg
ICAgICAgICAgIHVuc2lnbmVkIGludCBucl9lc3BpcyA9IG1pbihucl9zcGlzIC0gRVNQSV9CQVNF
X0lOVElELCAxMDI0VSk7DQo+PiArDQo+PiArICAgICAgICAgICAgLyogVmVyaWZ5IGlmIEdJQyBI
VyBjYW4gaGFuZGxlIHByb3ZpZGVkIElOVElEICovDQo+PiArICAgICAgICAgICAgaWYgKCBucl9l
c3BpcyA+IGdpY19udW1iZXJfZXNwaXMoKSApDQo+PiArICAgICAgICAgICAgICAgIHJldHVybiAt
RUlOVkFMOw0KPj4gKw0KPj4gKyAgICAgICAgICAgIGQtPmFyY2gudmdpYy5ucl9lc3BpcyA9IG5y
X2VzcGlzOw0KPj4gKyAgICAgICAgICAgIC8qIFNldCB0aGUgbWF4aW11bSBhdmFpbGFibGUgbnVt
YmVyIGZvciByZWd1bGFyIFNQSXMgKi8NCj4+ICsgICAgICAgICAgICBucl9zcGlzID0gVkdJQ19E
RUZfTlJfU1BJUzsNCj4+ICsgICAgICAgIH0NCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAg
IHsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgICAgIH0NCj4+ICsg
ICAgfQ0KPj4gKyNlbmRpZg0KPj4gICANCj4+ICAgICAgIGQtPmFyY2gudmdpYy5ucl9zcGlzID0g
bnJfc3BpczsNCj4+ICAgDQo+PiBAQCAtMTQ1LDcgKzI3Nyw3IEBAIGludCBkb21haW5fdmdpY19p
bml0KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBucl9zcGlzKQ0KPj4gICAgICAgICAg
IHJldHVybiAtRU5PTUVNOw0KPj4gICANCj4+ICAgICAgIGQtPmFyY2gudmdpYy5wZW5kaW5nX2ly
cXMgPQ0KPj4gLSAgICAgICAgeHphbGxvY19hcnJheShzdHJ1Y3QgcGVuZGluZ19pcnEsIGQtPmFy
Y2gudmdpYy5ucl9zcGlzKTsNCj4+ICsgICAgICAgIHh6YWxsb2NfYXJyYXkoc3RydWN0IHBlbmRp
bmdfaXJxLCB2Z2ljX251bV9zcGlfbGluZXMoZCkpOw0KPj4gICAgICAgaWYgKCBkLT5hcmNoLnZn
aWMucGVuZGluZ19pcnFzID09IE5VTEwgKQ0KPj4gICAgICAgICAgIHJldHVybiAtRU5PTUVNOw0K
Pj4gICANCj4+IEBAIC0xNTYsMTIgKzI4OCwxNiBAQCBpbnQgZG9tYWluX3ZnaWNfaW5pdChzdHJ1
Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgbnJfc3BpcykNCj4+ICAgICAgIGZvciAoIGkgPSAw
OyBpIDwgRE9NQUlOX05SX1JBTktTKGQpOyBpKysgKQ0KPj4gICAgICAgICAgIHZnaWNfcmFua19p
bml0KCZkLT5hcmNoLnZnaWMuc2hhcmVkX2lycXNbaV0sIGkgKyAxLCAwKTsNCj4+ICAgDQo+PiAr
ICAgIHJldCA9IGluaXRfdmdpY19lc3BpKGQpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAg
ICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gICAgICAgcmV0ID0gZC0+YXJjaC52Z2ljLmhhbmRs
ZXItPmRvbWFpbl9pbml0KGQpOw0KPj4gICAgICAgaWYgKCByZXQgKQ0KPj4gICAgICAgICAgIHJl
dHVybiByZXQ7DQo+PiAgIA0KPj4gICAgICAgZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzID0N
Cj4+IC0gICAgICAgIHh6YWxsb2NfYXJyYXkodW5zaWduZWQgbG9uZywgQklUU19UT19MT05HUyh2
Z2ljX251bV9pcnFzKGQpKSk7DQo+PiArICAgICAgICB4emFsbG9jX2FycmF5KHVuc2lnbmVkIGxv
bmcsIEJJVFNfVE9fTE9OR1ModmdpY19udW1fYWxsb2NfaXJxcyhkKSkpOw0KPj4gICAgICAgaWYg
KCAhZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzICkNCj4+ICAgICAgICAgICByZXR1cm4gLUVO
T01FTTsNCj4+ICAgDQo+PiBAQCAtMTgyLDkgKzMxOCwxMiBAQCB2b2lkIGRvbWFpbl92Z2ljX2Zy
ZWUoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICAgICAgIGludCBpOw0KPj4gICAgICAgaW50IHJldDsN
Cj4+ICAgDQo+PiAtICAgIGZvciAoIGkgPSAwOyBpIDwgKGQtPmFyY2gudmdpYy5ucl9zcGlzKTsg
aSsrICkNCj4+ICsgICAgZm9yICggaSA9IDMyOyBpIDwgdmdpY19udW1fYWxsb2NfaXJxcyhkKTsg
aSsrICkNCj4gDQo+IHMvMzIvTlJfTE9DQUxfSVJRUw0KPiANCj4+ICAgICAgIHsNCj4+IC0gICAg
ICAgIHN0cnVjdCBwZW5kaW5nX2lycSAqcCA9IHNwaV90b19wZW5kaW5nKGQsIGkgKyAzMik7DQo+
PiArICAgICAgICBzdHJ1Y3QgcGVuZGluZ19pcnEgKnA7DQo+PiArICAgICAgICB1bnNpZ25lZCBp
bnQgdmlycSA9IGlkeF90b192aXJxKGQsIGkpOw0KPj4gKw0KPj4gKyAgICAgICAgcCA9IHNwaV90
b19wZW5kaW5nKGQsIHZpcnEpOw0KPj4gICANCj4+ICAgICAgICAgICBpZiAoIHAtPmRlc2MgKQ0K
Pj4gICAgICAgICAgIHsNCj4+IEBAIC0xOTgsNiArMzM3LDkgQEAgdm9pZCBkb21haW5fdmdpY19m
cmVlKHN0cnVjdCBkb21haW4gKmQpDQo+PiAgICAgICBpZiAoIGQtPmFyY2gudmdpYy5oYW5kbGVy
ICkNCj4+ICAgICAgICAgICBkLT5hcmNoLnZnaWMuaGFuZGxlci0+ZG9tYWluX2ZyZWUoZCk7DQo+
PiAgICAgICB4ZnJlZShkLT5hcmNoLnZnaWMuc2hhcmVkX2lycXMpOw0KPj4gKyNpZmRlZiBDT05G
SUdfR0lDVjNfRVNQSQ0KPj4gKyAgICB4ZnJlZShkLT5hcmNoLnZnaWMuZXh0X3NoYXJlZF9pcnFz
KTsNCj4+ICsjZW5kaWYNCj4+ICAgICAgIHhmcmVlKGQtPmFyY2gudmdpYy5wZW5kaW5nX2lycXMp
Ow0KPj4gICAgICAgeGZyZWUoZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzKTsNCj4+ICAgfQ0K
Pj4gQEAgLTMyMywxMCArNDY1LDEyIEBAIHZvaWQgYXJjaF9tb3ZlX2lycXMoc3RydWN0IHZjcHUg
KnYpDQo+PiAgICAgICAgKi8NCj4+ICAgICAgIEFTU0VSVCghaXNfbHBpKHZnaWNfbnVtX2lycXMo
ZCkgLSAxKSk7DQo+PiAgIA0KPj4gLSAgICBmb3IgKCBpID0gMzI7IGkgPCB2Z2ljX251bV9pcnFz
KGQpOyBpKysgKQ0KPj4gKyAgICBmb3IgKCBpID0gMzI7IGkgPCB2Z2ljX251bV9hbGxvY19pcnFz
KGQpOyBpKysgKQ0KPiANCj4gSXQgaXMgZ3JlYXQgaWRlYSB0byBzdGFydCB1c2luZyBOUl9MT0NB
TF9JUlFTIGhlcmUgaW5zdGVhZCBvZiBoYXJkLWNvZGVkIDMyLg0KPiANCj4+ICAgICAgIHsNCj4+
IC0gICAgICAgIHZfdGFyZ2V0ID0gdmdpY19nZXRfdGFyZ2V0X3ZjcHUodiwgaSk7DQo+PiAtICAg
ICAgICBwID0gaXJxX3RvX3BlbmRpbmcodl90YXJnZXQsIGkpOw0KPj4gKyAgICAgICAgdW5zaWdu
ZWQgaW50IHZpcnEgPSBpZHhfdG9fdmlycShkLCBpKTsNCj4+ICsNCj4+ICsgICAgICAgIHZfdGFy
Z2V0ID0gdmdpY19nZXRfdGFyZ2V0X3ZjcHUodiwgdmlycSk7DQo+PiArICAgICAgICBwID0gaXJx
X3RvX3BlbmRpbmcodl90YXJnZXQsIHZpcnEpOw0KPj4gICANCj4+ICAgICAgICAgICBpZiAoIHZf
dGFyZ2V0ID09IHYgJiYgIXRlc3RfYml0KEdJQ19JUlFfR1VFU1RfTUlHUkFUSU5HLCAmcC0+c3Rh
dHVzKSApDQo+PiAgICAgICAgICAgICAgIGlycV9zZXRfYWZmaW5pdHkocC0+ZGVzYywgY3B1X21h
c2spOw0KPj4gQEAgLTUzOSw3ICs2ODMsNyBAQCBzdHJ1Y3QgcGVuZGluZ19pcnEgKmlycV90b19w
ZW5kaW5nKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQgaXJxKQ0KPj4gICAgICAgZWxzZSBp
ZiAoIGlzX2xwaShpcnEpICkNCj4+ICAgICAgICAgICBuID0gdi0+ZG9tYWluLT5hcmNoLnZnaWMu
aGFuZGxlci0+bHBpX3RvX3BlbmRpbmcodi0+ZG9tYWluLCBpcnEpOw0KPj4gICAgICAgZWxzZQ0K
Pj4gLSAgICAgICAgbiA9ICZ2LT5kb21haW4tPmFyY2gudmdpYy5wZW5kaW5nX2lycXNbaXJxIC0g
MzJdOw0KPj4gKyAgICAgICAgbiA9IHNwaV90b19wZW5kaW5nKHYtPmRvbWFpbiwgaXJxKTsNCj4+
ICAgICAgIHJldHVybiBuOw0KPj4gICB9DQo+PiAgIA0KPj4gQEAgLTU0Nyw3ICs2OTEsMTIgQEAg
c3RydWN0IHBlbmRpbmdfaXJxICpzcGlfdG9fcGVuZGluZyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNp
Z25lZCBpbnQgaXJxKQ0KPj4gICB7DQo+PiAgICAgICBBU1NFUlQoaXJxID49IE5SX0xPQ0FMX0lS
UVMpOw0KPj4gICANCj4+IC0gICAgcmV0dXJuICZkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFzW2ly
cSAtIDMyXTsNCj4+ICsgICAgaWYgKCBpc19lc3BpKGlycSkgKQ0KPj4gKyAgICAgICAgaXJxID0g
ZXNwaV9pbnRpZF90b19pZHgoaXJxKSArIGQtPmFyY2gudmdpYy5ucl9zcGlzOw0KPj4gKyAgICBl
bHNlDQo+PiArICAgICAgICBpcnEgLT0gMzI7DQo+IA0KPiBzLzMyL05SX0xPQ0FMX0lSUVMNCj4g
DQoNCk9rYXksIEkgd2lsbCByZXBsYWNlIHRoZSBoYXJkY29kZWQgdmFsdWVzIHdpdGggTlJfTE9D
QUxfSVJRUyBoZXJlIGFuZCBpbiANCnNpbWlsYXIgcGxhY2VzLiA6KQ0KDQo+IEFsc28sIEkgd2Fu
dCB5b3UgdG8gY29uc2lkZXIgYWRkaW5nIGxvY2FsIHZhcmlhYmxlICJpZHgiIGluc3RlYWQgb2YN
Cj4gcmV1c2luZyAiaXJxIiBwYXJhbWV0ZXIuDQo+IA0KDQpBbmQgYWxzbyB1c2UgaWR4IGluIHRo
aXMgY2FzZS4NCg0KPj4gKw0KPj4gKyAgICByZXR1cm4gJmQtPmFyY2gudmdpYy5wZW5kaW5nX2ly
cXNbaXJxXTsNCj4+ICAgfQ0KPj4gICANCj4+ICAgdm9pZCB2Z2ljX2NsZWFyX3BlbmRpbmdfaXJx
cyhzdHJ1Y3QgdmNwdSAqdikNCj4+IEBAIC02NjgsNiArODE3LDkgQEAgYm9vbCB2Z2ljX3Jlc2Vy
dmVfdmlycShzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgdmlycSkNCj4+ICAgICAgIGlm
ICggIXZnaWNfaXNfdmFsaWRfbGluZShkLCB2aXJxKSApDQo+PiAgICAgICAgICAgcmV0dXJuIGZh
bHNlOw0KPj4gICANCj4+ICsgICAgaWYgKCBpc19lc3BpKHZpcnEpICkNCj4+ICsgICAgICAgIHZp
cnEgPSBlc3BpX2ludGlkX3RvX2lkeCh2aXJxKSArIHZnaWNfbnVtX2lycXMoZCk7DQo+IA0KPiBI
ZXJlIGFzIHdlbGwuIEl0IGlzIHZlcnkgY29uZnVzaW5nIHdoZW4geW91IGFyZSB1cGRhdGluZyB2
aXJxIHdpdGggYQ0KPiB2YWx1ZSB0aGF0IGRvZXMgbm90IGNvcnJlc3BvbmRzIGluIElSUSBudW1i
ZXIgYW55bW9yZS4NCj4gDQo+PiArDQo+PiAgICAgICByZXR1cm4gIXRlc3RfYW5kX3NldF9iaXQo
dmlycSwgZC0+YXJjaC52Z2ljLmFsbG9jYXRlZF9pcnFzKTsNCj4+ICAgfQ0KPj4gICANCj4+IEBA
IC02ODUsNyArODM3LDcgQEAgaW50IHZnaWNfYWxsb2NhdGVfdmlycShzdHJ1Y3QgZG9tYWluICpk
LCBib29sIHNwaSkNCj4+ICAgICAgIGVsc2UNCj4+ICAgICAgIHsNCj4+ICAgICAgICAgICBmaXJz
dCA9IDMyOw0KPj4gLSAgICAgICAgZW5kID0gdmdpY19udW1faXJxcyhkKTsNCj4+ICsgICAgICAg
IGVuZCA9IHZnaWNfbnVtX2FsbG9jX2lycXMoZCk7DQo+PiAgICAgICB9DQo+PiAgIA0KPj4gICAg
ICAgLyoNCj4+IEBAIC03MDAsNyArODUyLDcgQEAgaW50IHZnaWNfYWxsb2NhdGVfdmlycShzdHJ1
Y3QgZG9tYWluICpkLCBib29sIHNwaSkNCj4+ICAgICAgIH0NCj4+ICAgICAgIHdoaWxlICggdGVz
dF9hbmRfc2V0X2JpdCh2aXJxLCBkLT5hcmNoLnZnaWMuYWxsb2NhdGVkX2lycXMpICk7DQo+PiAg
IA0KPj4gLSAgICByZXR1cm4gdmlycTsNCj4+ICsgICAgcmV0dXJuIGlkeF90b192aXJxKGQsIHZp
cnEpOw0KPj4gICB9DQo+PiAgIA0KPj4gICB2b2lkIHZnaWNfZnJlZV92aXJxKHN0cnVjdCBkb21h
aW4gKmQsIHVuc2lnbmVkIGludCB2aXJxKQ0KPiANCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:27:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:27:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109481.1459038 (Exim 4.92)
	(envelope-from )
	id 1uu3RH-00016E-4A; Thu, 04 Sep 2025 06:27:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109481.1459038; Thu, 04 Sep 2025 06:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu3RH-000167-1b; Thu, 04 Sep 2025 06:27:19 +0000
Received: by outflank-mailman (input) for mailman id 1109481;
 Thu, 04 Sep 2025 06:27: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 1uu3RF-000161-JQ
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:27:17 +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 3361c57a-8958-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:27:16 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b0473327e70so107435166b.3
 for ; Wed, 03 Sep 2025 23: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
 a640c23a62f3a-b04190700a4sm1079052466b.63.2025.09.03.23.27.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 23: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: 3361c57a-8958-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756967236; x=1757572036; 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=QAT6aacsif7a4VbJL2kAV3AhmdsMl0g8zndkTq+tSP0=;
        b=B71+U06407o8q3v/3pvxQ5BVCiI5CA2TIuOmLIilK9nW9kidcPTtd7C9DCsk/iAd8W
         Wl61rPrThR1I6kL7Ov+WZUWWG+z37aZDADjp2jt1xViQINj3GVDy7HGYIcwIX67pUk2s
         2uWFl6GVZzxl5yFVPjsi4iahgz5aPqkSpirlTlVWeFIyEN5fmhsOvfQT2Vyt9PScMAFT
         /WXa9VouZwLlghGcv2Gus3dSmLfm/g5EYvjxlyMSsoz6RcoYWqKsMR26jhUIscdyKq8S
         zUerFatl4QRFJ12sal6/ZLe3t7Ru0DsiZZ3XCmuQrMjL102CBAYuMGbMn/zpEJBPPOMD
         A7lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756967236; x=1757572036;
        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=QAT6aacsif7a4VbJL2kAV3AhmdsMl0g8zndkTq+tSP0=;
        b=oPKGbt3URkFAJp9gEV0KOCHqCOVscsUo9v7XeCAYbEm04tF+Y4rJ/9L09N+i4oD5eT
         sHQGf9Y0/FBYTtXIJJ1DorvjIfnXsg0FxqqgmU1NYIfWN26jBo46995l5cIpFqppOlPC
         em3JCqQdobcktABzAfcAgS/djGDKA22sSRy8dmaBUxHW60qmDDovJNRDHTV2D+dxVyKH
         33glfw9JGg8cuDLg+tW9+IzGGa0Xx4VjNHfv35wa/rnbj/MH8hD8naJOcdAWmGIKDjSm
         POwAtjNRQkBQnEqVNQmQm+0QWEtiAhq0ZvXVEbydtaIJufphjxH3rCCYaa14L2/8xQDg
         LBdg==
X-Gm-Message-State: AOJu0YzSotlKHRtjFe9BYGMn64IbL4F8GJwzmzEf6XpCkb8O72rhl0SA
	uDY1K5lkS720zm8/ahTfiOrlw3ExeBUiLYmWwDNWh1MbAVIJJAE6l66twTpdfGJ9/A==
X-Gm-Gg: ASbGncvaXDv3oZ8I/dNR+6baxABNAuIbOFBkhxI2EhY3DsXEkizwHVWwYzyBmzyhz6B
	olq8RPcjSeYr2rQx1wkYqwC/SlMtipsVT/yS4NXJ49s9046kE3tWN4Pw9oKXkNVdBXmKqc9LNX5
	ZGRl02ZKu7LotbqPaLRddlcn7DTPuccSLPdcpweFh425xXELP6LDpZfSVQNr3unFMSVIUyJakbD
	+m4yCJ8q8sD7zFkbP7D6qbqoLPJ9d+P7miJ2Xaju9KXa4D+Y2qwZpUOxVF/fGmLO8NkLkrRzQNk
	6dP6OX7lK0Xv0gqsHHuj8Ty/Gle2Y5WQeuZSbhKs1uMqKtiGD8J45k7AGohV2zag1roVl2Y2NVn
	y0i3HzMifiRsqcnBYrLkNLNR/YibKR9jLXm68VyHO3Q35wM3ZTy1Xo9y7lEBguQulO9MIig372/
	V6RSWSNNVxUXDUmwbbueENyg/5SPJX
X-Google-Smtp-Source: AGHT+IHo2wBY4PhEBRW17R6lhrOkaIswY/ulsNskoGMIWjb6iO3db+huiX2fGWXMNiUugyZ0kZAdGA==
X-Received: by 2002:a17:907:9410:b0:b04:7702:c18f with SMTP id a640c23a62f3a-b047702c450mr275335466b.15.1756967235587;
        Wed, 03 Sep 2025 23:27:15 -0700 (PDT)
Message-ID: <15650736-585b-4b5c-b2d2-53f4670d8530@suse.com>
Date: Thu, 4 Sep 2025 08:27:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865
From: Jan Beulich 
To: Marek Marczykowski 
Cc: "xen-devel@lists.xenproject.org" 
References: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
 <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com> 
 <0fb22103-c928-40ff-8be9-bf8d3914f028@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: <0fb22103-c928-40ff-8be9-bf8d3914f028@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.09.2025 07:58, Jan Beulich wrote:
> On 03.09.2025 18:03, Marek Marczykowski wrote:
>> On Wed, Sep 03, 2025 at 05:58:32PM +0200, Jan Beulich wrote:
>>> On 03.09.2025 17:46, GitLab wrote:
>>>>
>>>>
>>>> Pipeline #2019390073 has failed!
>>>>
>>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>>> Branch: staging-4.18 ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.18 )
>>>>
>>>> Commit: 51190865 ( https://gitlab.com/xen-project/hardware/xen/-/commit/51190865a4918c443c310c0478247d5f9caa5dad )
>>>> Commit Message: x86/suspend: unconditionally raise a timer soft...
>>>> Commit Author: Roger Pau Monné
>>>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>>>>
>>>>
>>>> Pipeline #2019390073 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/2019390073 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>>>> had 5 failed jobs.
>>>>
>>>> Job #11230955404 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955404/raw )
>>>>
>>>> Stage: test
>>>> Name: adl-suspend-x86-64-gcc-debug
>>>> Job #11230955410 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955410/raw )
>>>>
>>>> Stage: test
>>>> Name: adl-pci-pv-x86-64-gcc-debug
>>>> Job #11230955417 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955417/raw )
>>>>
>>>> Stage: test
>>>> Name: adl-pci-hvm-x86-64-gcc-debug
>>>> Job #11233274365 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233274365/raw )
>>>>
>>>> Stage: test
>>>> Name: adl-smoke-x86-64-gcc-debug
>>>> Job #11233405609 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233405609/raw )
>>>>
>>>> Stage: test
>>>> Name: adl-smoke-x86-64-dom0pvh-gcc-debug
>>>
>>> While the same tests are fine for 4.19 and 4.20, all five show rubbish in the log,
>>> and then fail. No idea what's going on.
>>
>> The log says "baudrate is    : 115200", but looking at the state after
>> the test I see 9600. No idea if that was simply switched back after, or
>> setting to 115200 didn't work. Anyway I suggest to restart (now that
>> other jobs completed). I set it manually to 115200 now too (not sure if
>> that will remain there...).
> 
> The rubbish in the output looks to have gone away, but the adl-* tests fail
> as before. I'm retrying two of them another time, but with little hope.

As opposed to 4.19, where we have this

minimal cmds is: no
!! STDIN is not a TTY !! Continue anyway...
Type [C-a] [C-h] to see available commands
Terminal ready
 Xen 4.19.4-pre
(XEN) [00000043ae35c0c9] Xen version 4.19.4-pre (root@) (gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924) debug=y Wed Sep  3 12:15:19 UTC 2025

for 4.18 things (consistently across the tests) look like this

minimal cmds is: no
!! STDIN is not a TTY !! Continue anyway...
Type [C-a] [C-h] to see available commands
Terminal ready
Accessing Gembird #0 USB device 038
Switched outlet 2 on
Setting boot mode for 2 to gitlabci... done
+ trap 'ssh control@thor.testnet poweroff; : > /tmp/console-stdin' EXIT
+ '[' -n  ]
+ set +x
 Xen 4.18.5
(XEN) Xen version 4.18.5 (root@) (gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924) debug=y Wed Sep  3 12:27:30 UTC 2025

For 4.19 there's no visible delay between "Terminal ready" and the first Xen
message, whereas for 4.18 there is an approx 1:30min (±10s) delay after the
"+ set +x". That's a lot when the timeout is 2min.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:35:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:35:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109499.1459059 (Exim 4.92)
	(envelope-from )
	id 1uu3ZY-0002wx-5f; Thu, 04 Sep 2025 06:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109499.1459059; Thu, 04 Sep 2025 06: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 1uu3ZY-0002wq-22; Thu, 04 Sep 2025 06:35:52 +0000
Received: by outflank-mailman (input) for mailman id 1109499;
 Thu, 04 Sep 2025 06:35: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 1uu3ZW-0002id-Qo
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:35:50 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2060f.outbound.protection.outlook.com
 [2a01:111:f403:240a::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63c3be77-8959-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 08:35:48 +0200 (CEST)
Received: from MN2PR13CA0027.namprd13.prod.outlook.com (2603:10b6:208:160::40)
 by CY8PR12MB8313.namprd12.prod.outlook.com (2603:10b6:930:7d::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 06:35:43 +0000
Received: from MN1PEPF0000F0E4.namprd04.prod.outlook.com
 (2603:10b6:208:160:cafe::13) by MN2PR13CA0027.outlook.office365.com
 (2603:10b6:208:160::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.7 via Frontend Transport; Thu, 4
 Sep 2025 06:35:43 +0000
Received: from SATLEXMB03.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.9094.14 via Frontend Transport; Thu, 4 Sep 2025 06:35:42 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:42 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:40 -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: 63c3be77-8959-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HFClEdc6GDfz21vLXIu3qgjpcPlIl6rAcTqmg6W2EhJlHJDNqSBIW9byb3scBqK0lNHwNdCnsFO+6UGA/78HAst8wwbIQpxc0bF4KiPRpdxM6AzNPo32jbDAwOiBe//UYay8zLrp+IeZnQOPxwH42HqWCnK5MSyuHKaTgv/w20Z+fhgUSQ3hMe9BsZoJ2PhsMbSCkq5d9fik6Q7qDDK8l6dY/oBFkn0LnRcOhujykmW7AyXuGj//PYvIfKg4njbWqcIWZ+XjhJLwIG0msoamYsTu4KicAWAXookllO6fCcm9q7u/dsMIybClApJKC7nYgT9k2zgmD7G/TLmH3GED3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bDJFqa/0jwB62IgSYFWp412EHWmA50CeyfzZTWwYV/M=;
 b=Ik418D83nLVG40zTXnOqwmJWDEqmljFhbJc2CxNeDDDvwXvQyVE+zQSsKUrXKtfNef3zNOc9XAR2jFbU74PF+/czq6msJ9CCThHSbpgRtaTahgYPKbDVy8e5gXtE+k99rP4/Is4/d+DtKltS2HVEo2NnQaW2P031PkU9dsCd7itJvCrrEpq8MfMH+nEC0+jb3gJEkQ5VjQMEyayhuRiKbCPtgCK0cdcXJR0jQCiiLua4CK5dcBlEOggysCHP2LOmKFHSSOMSFfwc8aQFCh/xEUjxSn5tlEbiGdNrnxsaRseoZ0Jy/bRYv7RAy6ok3NW5rIEXVuDEoqmYoI+8KqTdBQ==
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=bDJFqa/0jwB62IgSYFWp412EHWmA50CeyfzZTWwYV/M=;
 b=V1srcP3wiA9bQTCWJFyBx7N2aqZYZPeKjPB1Fp8TAKcb+hYM5G4jap6VDoI+Mz2cizWthG9m9nOEiFx/7I3/fUTMuD+8lAR3s0xBUZc0RObKq4wJGK5ttHdeFUYxnIRme91Lge0VQ2ohdUd8YJkMwoJ5UXf0V+h9ZBvzr5QDMus=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: Penny Zheng 
To: 
CC: Penny Zheng , Jan Beulich , Andrew
 Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	
Subject: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct cpufreq_policy{}
Date: Thu, 4 Sep 2025 14:35:11 +0800
Message-ID: <20250904063518.2097629-2-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E4:EE_|CY8PR12MB8313:EE_
X-MS-Office365-Filtering-Correlation-Id: 0299f5e2-94bf-4c82-ae11-08ddeb7d45c3
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?npbfyEXTbCwjWYRBDwtBllnfzgLWntcvnYt26NJQRozP1ZxG4pQjryk1+Ghf?=
 =?us-ascii?Q?4DjTm1X1hL4yDkHxwRsdGsgyrUo1xZXe1dJFSz64P9kpzROHgXIM1daauAhg?=
 =?us-ascii?Q?sMFY+1KYU5l1BubtTcJcRi00l3zl70UNPOeGDKJfoDtgXYVe8UvpdKTN/xG6?=
 =?us-ascii?Q?qPOXEXNcq0JMUs3sn7JZNefjsJpFyPJfVSZZFO7Buf2dWlR1ech+ox7lOXHn?=
 =?us-ascii?Q?bVZ+PZQzAepi1aD8fI/KP3dV2wVKiTCb5pCGbM7MAIKp7EYDI7cQBpqs4U7I?=
 =?us-ascii?Q?3DGHPNNElMPQevJCkJHV6DvFGGejduLaMtX8ltcwXrFzNPY87HLqbTmo5v/m?=
 =?us-ascii?Q?KOg+y+ZRDJZA6FvdN+b+3gE9OQUYRs48Qowms4w2LJxXFc3dV9b0Ot6j05hf?=
 =?us-ascii?Q?NgxVsDvI7fztw1rPQixn+cCF6dupknAPXPovOVra6MXF9pgERS5kyWCwgkm+?=
 =?us-ascii?Q?aSaLsSKK/ghiqEOuglz1Hy7sJeBHlQsQvT9ehtkhj7zpLkH4SSLubnDHAxRL?=
 =?us-ascii?Q?nU+ZA1cjUhW4oO53WCIXLO4Q7+fAQIsgr6rQ27eELef2NCI+Iu0vf4aJ800r?=
 =?us-ascii?Q?hFJAgAjyABHRN912Ycc+PH3Aj74U7kxxqbvdc4/Dot8cIFYVlubbMLPlibgn?=
 =?us-ascii?Q?YRL2gXh3MQH6ITOiCvnxg77XE0B9w7jO9rNgs0lWDZCrxK0nlZtakmjzxgWk?=
 =?us-ascii?Q?P5kfVVqs3X4jhYBtS1GPCuKy6e9skShiGAnBdv0+AP0urfTj0y9gJI8AImRt?=
 =?us-ascii?Q?7qzvuGrJVyGbl4XYbmBsfNvi5NjU/3K8KwzJGzeQz2HfKUtg9tXbVhsCr1N6?=
 =?us-ascii?Q?EiF5oCGFmG1tqvk3BS2pmtPT8sJxys21W83oxFNVD9Jq22m6rTAn+icegdyz?=
 =?us-ascii?Q?h9pD2UL1RRg+W08i5DIGbVAA3zFAKMQw7qd0+8Rtg1jOyn9221VT+V+x2W2O?=
 =?us-ascii?Q?h5ewTjUSmLkKFSTRGlYd1G8vDQKtGEhIN8wvXKS6KtffSLgtm0CNjRMyPvLf?=
 =?us-ascii?Q?YR7LkNPmVzLW4dykPg3770CvHYDhzrVuP959isIdIKsDMD/jCWtcNTLurkGN?=
 =?us-ascii?Q?RUrzgqFF2hjEQ1JpPYP/Neqt2Oj+1e392E2E46/xSU64gQbFe+x4kh4Urje6?=
 =?us-ascii?Q?xTsI6RxxBn26IC9yJ2DJPv4+nOnnveHrmMz2FPkafimh6hZ4BjQA0PbAgYQT?=
 =?us-ascii?Q?ESv19vzQYgEvLi4V4W/JZwycWEjIs4MPp+YUNW5gM2CZKUQUKJLad3B7pzvD?=
 =?us-ascii?Q?3nuE71yIDmrnRX09Zst7+8W+i7Gcnppc1wZhUKiLHgVDM3AVZ+PF+SbdMn0R?=
 =?us-ascii?Q?8MAbKeSBuFAEVhcVuKgWC/hMtjfCIxcarBqVUqoJmYBsuQ+vL6pbsPw5awF3?=
 =?us-ascii?Q?5TPwm54PMBx3JxFT07fFs+fkrqFpv9RDD3jczfcrwtmhb3dJTqcCMFzm3eXj?=
 =?us-ascii?Q?O/HuA5LWtGWk81RWMfCsfVwKC6i9BPCc938TLb6XRF05qna+jFbE1cfQZtYY?=
 =?us-ascii?Q?uCd4OoU0q3Alm5/hAQJNL+D6/UB64+Ygt14e?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 06:35:42.9919
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0299f5e2-94bf-4c82-ae11-08ddeb7d45c3
X-MS-Exchange-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:
	MN1PEPF0000F0E4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8313

For cpus sharing one cpufreq domain, cpufreq_driver.init() is
only invoked on the firstcpu, so current per-CPU hwp driver data
struct hwp_drv_data{} actually fails to be allocated for cpus other than the
first one. There is no need to make it per-CPU.
We embed struct hwp_drv_data{} into struct cpufreq_policy{}, then cpus could
share the hwp driver data allocated for the firstcpu, like the way they share
struct cpufreq_policy{}. We also make it a union, with "hwp", and later
"amd-cppc" as a sub-struct.

Suggested-by: Jan Beulich 
Signed-off-by: Penny Zheng 
---
v8 -> v9:
- new commit
---
 xen/arch/x86/acpi/cpufreq/hwp.c    | 32 +++++++++++++-----------------
 xen/include/acpi/cpufreq/cpufreq.h |  6 ++++++
 2 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/acpi/cpufreq/hwp.c b/xen/arch/x86/acpi/cpufreq/hwp.c
index 240491c96a..5c98f3eb3e 100644
--- a/xen/arch/x86/acpi/cpufreq/hwp.c
+++ b/xen/arch/x86/acpi/cpufreq/hwp.c
@@ -67,7 +67,6 @@ struct hwp_drv_data
     uint8_t desired;
     uint8_t energy_perf;
 };
-static DEFINE_PER_CPU_READ_MOSTLY(struct hwp_drv_data *, hwp_drv_data);
 
 #define hwp_err(cpu, fmt, args...) \
     printk(XENLOG_ERR "HWP: CPU%u error: " fmt, cpu, ## args)
@@ -224,7 +223,7 @@ static bool __init hwp_available(void)
 
 static int cf_check hwp_cpufreq_verify(struct cpufreq_policy *policy)
 {
-    struct hwp_drv_data *data = per_cpu(hwp_drv_data, policy->cpu);
+    struct hwp_drv_data *data = policy->u.hwp;
 
     if ( !feature_hwp_activity_window && data->activity_window )
     {
@@ -239,7 +238,7 @@ static int cf_check hwp_cpufreq_verify(struct cpufreq_policy *policy)
 static void cf_check hwp_write_request(void *info)
 {
     const struct cpufreq_policy *policy = info;
-    struct hwp_drv_data *data = this_cpu(hwp_drv_data);
+    struct hwp_drv_data *data = policy->u.hwp;
     union hwp_request hwp_req = data->curr_req;
 
     data->ret = 0;
@@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct cpufreq_policy *policy,
                                        unsigned int relation)
 {
     unsigned int cpu = policy->cpu;
-    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
+    struct hwp_drv_data *data = policy->u.hwp;
     /* Zero everything to ensure reserved bits are zero... */
     union hwp_request hwp_req = { .raw = 0 };
 
@@ -350,7 +349,7 @@ static void hwp_get_cpu_speeds(struct cpufreq_policy *policy)
 static void cf_check hwp_init_msrs(void *info)
 {
     struct cpufreq_policy *policy = info;
-    struct hwp_drv_data *data = this_cpu(hwp_drv_data);
+    struct hwp_drv_data *data = policy->u.hwp;
     uint64_t val;
 
     /*
@@ -426,15 +425,14 @@ static int cf_check hwp_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
     policy->governor = &cpufreq_gov_hwp;
 
-    per_cpu(hwp_drv_data, cpu) = data;
+    policy->u.hwp = data;
 
     on_selected_cpus(cpumask_of(cpu), hwp_init_msrs, policy, 1);
 
     if ( data->curr_req.raw == -1 )
     {
         hwp_err(cpu, "Could not initialize HWP properly\n");
-        per_cpu(hwp_drv_data, cpu) = NULL;
-        xfree(data);
+        XFREE(policy->u.hwp);
         return -ENODEV;
     }
 
@@ -462,10 +460,8 @@ static int cf_check hwp_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
 static int cf_check hwp_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 {
-    struct hwp_drv_data *data = per_cpu(hwp_drv_data, policy->cpu);
-
-    per_cpu(hwp_drv_data, policy->cpu) = NULL;
-    xfree(data);
+    if ( policy->u.hwp )
+        XFREE(policy->u.hwp);
 
     return 0;
 }
@@ -480,7 +476,7 @@ static int cf_check hwp_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 static void cf_check hwp_set_misc_turbo(void *info)
 {
     const struct cpufreq_policy *policy = info;
-    struct hwp_drv_data *data = per_cpu(hwp_drv_data, policy->cpu);
+    struct hwp_drv_data *data = policy->u.hwp;
     uint64_t msr;
 
     data->ret = 0;
@@ -511,7 +507,7 @@ static int cf_check hwp_cpufreq_update(unsigned int cpu, struct cpufreq_policy *
 {
     on_selected_cpus(cpumask_of(cpu), hwp_set_misc_turbo, policy, 1);
 
-    return per_cpu(hwp_drv_data, cpu)->ret;
+    return policy->u.hwp->ret;
 }
 #endif /* CONFIG_PM_OP */
 
@@ -531,9 +527,10 @@ hwp_cpufreq_driver = {
 int get_hwp_para(unsigned int cpu,
                  struct xen_get_cppc_para *cppc_para)
 {
-    const struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
+    const struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_policy, cpu);
+    const struct hwp_drv_data *data;
 
-    if ( data == NULL )
+    if ( !policy || !(data = policy->u.hwp) )
         return -ENODATA;
 
     cppc_para->features         =
@@ -554,8 +551,7 @@ int get_hwp_para(unsigned int cpu,
 int set_hwp_para(struct cpufreq_policy *policy,
                  struct xen_set_cppc_para *set_cppc)
 {
-    unsigned int cpu = policy->cpu;
-    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
+    struct hwp_drv_data *data = policy->u.hwp;
     bool cleared_act_window = false;
 
     if ( data == NULL )
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 5d4881eea8..c0ecd690c5 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -62,6 +62,7 @@ struct perf_limits {
     uint32_t min_policy_pct;
 };
 
+struct hwp_drv_data;
 struct cpufreq_policy {
     cpumask_var_t       cpus;          /* affected CPUs */
     unsigned int        shared_type;   /* ANY or ALL affected CPUs
@@ -81,6 +82,11 @@ struct cpufreq_policy {
     int8_t              turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
+    union {
+#ifdef CONFIG_INTEL
+        struct hwp_drv_data *hwp; /* Driver data for Intel HWP */
+#endif
+    } u;
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:35:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:35:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109497.1459049 (Exim 4.92)
	(envelope-from )
	id 1uu3ZW-0002jT-Vv; Thu, 04 Sep 2025 06:35:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109497.1459049; Thu, 04 Sep 2025 06:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu3ZW-0002jI-RH; Thu, 04 Sep 2025 06:35:50 +0000
Received: by outflank-mailman (input) for mailman id 1109497;
 Thu, 04 Sep 2025 06:35: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 1uu3ZV-0002iS-Bl
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:35:49 +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 63dc3dd2-8959-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:35:48 +0200 (CEST)
Received: from BL1PR13CA0123.namprd13.prod.outlook.com (2603:10b6:208:2bb::8)
 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.9094.18; Thu, 4 Sep
 2025 06:35:41 +0000
Received: from BN3PEPF0000B06D.namprd21.prod.outlook.com
 (2603:10b6:208:2bb:cafe::50) by BL1PR13CA0123.outlook.office365.com
 (2603:10b6:208:2bb::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.7 via Frontend Transport; Thu, 4
 Sep 2025 06:35:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06D.mail.protection.outlook.com (10.167.243.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9115.0 via Frontend Transport; Thu, 4 Sep 2025 06:35:41 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:40 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:37 -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: 63dc3dd2-8959-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mSXnEc2nrB6hVKsbchqDu4cob5fOLcErZ8CVKk4gjvGeq9J9wHwTglxC/+XS1rumK0fiKEu5eRiQoG7lZouRdzXhA+bLKWf5hgdDiNioDpDPH7qvB/TU+u3bEKyGxhvrLb7oElxl6t848WS/XVE+FlaiPJzbv4Gr/LvmTESEKxZG6ybY4aJzweFYqgBRLObMgtTyKoWLwBXFiXgCxeKfu2lmRna5h57llPw9xHQ57/s+4Z5Wx1cfWy7yGNF+ARLmyy0ctt9/vX1gzrRixZFmRDhOHCch/zWxyM/XmxkeQEPlgzlcQzuSfRC43ogGpo3boaw0tCGTFoMYcUvFH/BOjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k0vfpD93FqCKRkqZ+5AZHXJ1ZRa+l+e1phs7KLQWPUU=;
 b=kQSEDWh+zpnOyx9GfxvOwnAxrmJQb44HmKwHgxjxZdScdVfFbotvCDAFuxrw7KVrWoY/5qZBZwirjD63pzWvcQ7/SGPNT+8r9HFqFInlt96lOEDPupU1TCuPvP/RycCFTIAHv58c/44kXkjOUIUwUewWbQN1HDiUWYLuR3bB8EVpOmn58kr7VsdJ4TXA1NBON+8/B6/gSFGHZmUsaoCWa5Mjf4ytxR8qaxaOlXrlIO1lfSJxsmMoKF7eFyPVxA01RBLD3u6G4y92I5SznjULuQFSW6z7bbEpWwxGXJ2LOhl5M16Fyeit8QtHm3isDFv+mCpK/gXvB3XBgYXmdAzsBQ==
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=k0vfpD93FqCKRkqZ+5AZHXJ1ZRa+l+e1phs7KLQWPUU=;
 b=lnbI2zjdSi/V78GT9Z77Ujo0h5NVjmTABio4CnQmMLhXqcPsAuBRc3nXOwYjYvNdxBRB/XcfrlHpeqoEHaAz5igjGw+9tJ+vIsxox0ywYe3q/y7E2fruzRVt39qzBoH+xzirhNROwyPLEAINuGLNTxmgAdsAgUDvKuwwINvBs5o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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 , Juergen Gross , Oleksii
 Kurochko , Community Manager
	
Subject: [PATCH v9 0/8] amd-cppc CPU Performance Scaling Driver
Date: Thu, 4 Sep 2025 14:35:10 +0800
Message-ID: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06D:EE_|DS2PR12MB9589:EE_
X-MS-Office365-Filtering-Correlation-Id: 7d617140-bd19-4926-4a20-08ddeb7d44b1
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:
	=?us-ascii?Q?iHTDNff6VzRllsP4Y1Yy/jpWMsx6Km0EGIJ68+V8Iv6ZLxDoGddpf5OTZDwe?=
 =?us-ascii?Q?iet0Hqz7YZgZXNsWngYLPSChFfpfPPeC/ex9WGlOfVV0SmWE4cBCxjuq97rq?=
 =?us-ascii?Q?i1MMvzjyajrwa6RRkj7+p5sPUDjLD/MeaU4iLRpRFh2Kfr3yT7yGfzuzZW5j?=
 =?us-ascii?Q?K+Be1/NhOJs9t1zf6QYgqve7clRZM8ovbUbdepGhVqrDIhiuzNUKlMyiOhCl?=
 =?us-ascii?Q?KNfB25tWFmZNbrao9AKNOfRUNmAwGqz14t9quTKUC6YgiO6WfXZ6gtwqtKKp?=
 =?us-ascii?Q?pzU0+2opybn/Zn1Ey+447jD4iDfwoqP+iZhVPboBX0NR+zGKgtqvfSjxLEzC?=
 =?us-ascii?Q?TihEBgVekJqBqRAWUe1hpY1waW6CK1LrMCBHXui3npPR+XPlZuZHcbAPLoEE?=
 =?us-ascii?Q?QRzPwasRK7j9bLx1iZ3jDmRD39P7zNHRXN0kFBHJQyp2DzEeeIgDqvmagFtn?=
 =?us-ascii?Q?v/VOHyjeRRk/mn2DYrQODT2wB0V62PutV3O5mbiJRevAVGcZli9aNvw/mmFl?=
 =?us-ascii?Q?l/yRs11EjE+aCU24aCuxmyKW8v4fIjMdZtQ5iJ0t7SgHvfsdf8BdGgT0FwlN?=
 =?us-ascii?Q?0I0oCmJd1uEwac2w8eBACzrHutcCo1QwWfQ3lCFKPrFdJ1zCRaBDogrwY9KB?=
 =?us-ascii?Q?6ARpFbtdvMwpRtVA+zRbOUF6IzPkWsMfZfA1kWoxXKk2h6J7ZGwv1J4Bnx2L?=
 =?us-ascii?Q?/NeIXlCa3B/v/E4Yzb8JL3uLtrX7wRtqAvDPbmIqF2o+RR4wdJgh4Q7MSRu7?=
 =?us-ascii?Q?nIMLUwuo6n5PBG8kkAfdS7RNS3ZQrS1XXWjAbCd4IwWcmusLv8tXFLLF0V2q?=
 =?us-ascii?Q?nYPZwhEnlf00UiKidUrdBsdrHenCdrLs5wkTly6X/puADOynGVq6/r0gzR/9?=
 =?us-ascii?Q?XQG721BBjMle+1el8aKKe9GWFWUwkyaMRdNt9VAf4tX91LQxJX7aNhTERyDk?=
 =?us-ascii?Q?Yq8gBDX1pj2c+w3gj2QYk+Or3VkQrVFRb1xgk4VCo2j6R8FeYNjL/f9vwiI6?=
 =?us-ascii?Q?9YMqUTLGKv1rumV3tUIppG9Nk9/YrpNBvp5oKgwp6h+4W0clHxwDn5EA9RTQ?=
 =?us-ascii?Q?+cFG1Z+MaRm+ai6FKpQQxq4xv/16bJuQpN6EVilA36uDIXNRPbSRC/hDOiwV?=
 =?us-ascii?Q?PrKouN52ST3oSYV0R9hdXR6lOMiPpaTHqXFd8RbCgpXbRRn2b2bF7WqTqSQZ?=
 =?us-ascii?Q?qJk08mZso+yYWTwcaPWyw8yUbyJV/50aeUdIvr1+0t01k3TGdPWeVLbrgWUK?=
 =?us-ascii?Q?6NZRa+1HLBi8dt2cTRMao9wsgToShe69nj2Nwx87sVY7uJUfZ9kh1znaZsUu?=
 =?us-ascii?Q?V6x3r+Cwo3GWAICd9bcBIeQSFYJrQpofeVsSezCYg5RLlxwpaXKujES5cfIK?=
 =?us-ascii?Q?dOkMF+Phpja4r/vPz00evZJn9SX23wsZ25JyPDvHSFtQDQ5Qcj6b3hGeGB+M?=
 =?us-ascii?Q?/rKONIYeNJfPZ+ET8SyRFjVM5WOm9cw/SB9F6i8LVOKecWz10BLB6s8eXmIR?=
 =?us-ascii?Q?vOO20+kyVFABPSRIo1K01Lm1wkf8yW7AWQiv?=
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: 04 Sep 2025 06:35:41.1963
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d617140-bd19-4926-4a20-08ddeb7d44b1
X-MS-Exchange-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:
	BN3PEPF0000B06D.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9589

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 (8):
  xen/cpufreq: embed hwp into struct cpufreq_policy{}
  xen/cpufreq: implement amd-cppc driver for CPPC in passive mode
  xen/cpufreq: implement amd-cppc-epp driver for CPPC in active mode
  xen/cpufreq: get performance policy from governor set via xenpm
  tools/cpufreq: extract CPPC para from cpufreq para
  xen/cpufreq: bypass governor-related para for amd-cppc-epp
  xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc
    driver
  CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq driver support

 CHANGELOG.md                         |   1 +
 docs/misc/xen-command-line.pandoc    |   9 +-
 tools/include/xenctrl.h              |   3 +-
 tools/libs/ctrl/xc_pm.c              |  25 +-
 tools/misc/xenpm.c                   |  94 ++--
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 703 ++++++++++++++++++++++++++-
 xen/arch/x86/acpi/cpufreq/hwp.c      |  32 +-
 xen/arch/x86/cpu/amd.c               |   8 +-
 xen/arch/x86/include/asm/amd.h       |   2 +
 xen/arch/x86/include/asm/msr-index.h |   6 +
 xen/drivers/acpi/pm-op.c             |  58 ++-
 xen/drivers/cpufreq/utility.c        |  15 +
 xen/include/acpi/cpufreq/cpufreq.h   |  44 ++
 xen/include/public/sysctl.h          |   5 +-
 14 files changed, 936 insertions(+), 69 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:35:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:35:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109500.1459068 (Exim 4.92)
	(envelope-from )
	id 1uu3Zd-0003Eo-Gd; Thu, 04 Sep 2025 06:35:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109500.1459068; Thu, 04 Sep 2025 06: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 1uu3Zd-0003Ef-DU; Thu, 04 Sep 2025 06:35:57 +0000
Received: by outflank-mailman (input) for mailman id 1109500;
 Thu, 04 Sep 2025 06: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 1uu3Zc-0002iS-CI
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:35:56 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20626.outbound.protection.outlook.com
 [2a01:111:f403:2416::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6887315a-8959-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:35:54 +0200 (CEST)
Received: from BN0PR07CA0004.namprd07.prod.outlook.com (2603:10b6:408:141::22)
 by SJ2PR12MB7866.namprd12.prod.outlook.com (2603:10b6:a03:4cc::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 06:35:46 +0000
Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com
 (2603:10b6:408:141:cafe::ba) by BN0PR07CA0004.outlook.office365.com
 (2603:10b6:408:141::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 06:35:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9115.0 via Frontend Transport; Thu, 4 Sep 2025 06:35:45 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:45 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:42 -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: 6887315a-8959-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QqS1pnPGHVRxbeRP6RkwqLQAR78kMVmui3KYq9tuVampSnp/dYHXFsZYSZPSwbay3EfozVxmpgXhyc7KI6rCpmjebgdcn4LIh0HwN0ldWYjE4zlF7C6JgNt+XhJ2vPJJxpOYmOrDxqnmJw6vBE1Q+R+ux1xkMwwZbPFSAKxwXknxm/RFUp59QfW2FEFQsUPwJSJpX7P0jw+saeTMdstXqpAO8PSlseSVsUcXxpc/pcgS+CLACwZMdMTi/8bVsFUwQYhtKDkz3U8BxC/kmWTsNW/zBq0t1+pHEZPI/Zox0FM4FRpfrw5R1acdOShYEAuo6QFNxl5wGOwX4xsL/Phx1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hMmiNQ4x6OxRNWqhwD1ruaQsLm6xQvA6vdWKIS2oZOk=;
 b=a8zSK35DShinAT6adRUv04tNkn/IQwdNaeRbJ+0Fg7zEhVJqPS//PNh26378rxPzYXedjIZLmGunzxawyftOyR4HXeLXyrMtV2xM3EHvNGYfA8rQfFP5m3BJlvN21Q82rcgYnExdAjp3MHXHMaLwZGOy9gBxkHsfqoFvS9PHDb0V1EhH4+4DSIvN0uvLbZS9GB8nrSOf68jGZi9/SqHpT+O6itAOjp8jxovr+HHjpBzRTBY2L9ALuWMOEIzYN4BBYMsmvtr8v6ElH3GPwtM5YQAuDLMGoV6AYg4A2v/oWMnxHEi7h+lRSOhD1IzgbWrQgcHZ6uhAsp+zYLtYOf8mRQ==
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=hMmiNQ4x6OxRNWqhwD1ruaQsLm6xQvA6vdWKIS2oZOk=;
 b=nO3QuaAFDGut154zTbe32iuvkf/Ooru7IMrc/CHDSMIO2Xg/m8+trAUewCIiPYAfP8/Oc2iQNGpuCWBG7GbKyVUuDgmsVRId6aY//yn61cQ4V5eh30ao0WhuAx5XtOsEcnXVx4gZf6T0w8f714C4cUkESKtbV6mfAHIZj6RZGOI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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 v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in passive mode
Date: Thu, 4 Sep 2025 14:35:12 +0800
Message-ID: <20250904063518.2097629-3-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|SJ2PR12MB7866:EE_
X-MS-Office365-Filtering-Correlation-Id: c0e5f05a-1eba-47af-926e-08ddeb7d4759
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?bkxvblZzamNUS2F3cit3aWVMTXduaEJSa2pDWFVMdUw2Mld6OSt0R0Y3elZj?=
 =?utf-8?B?L0MraU1LMmxSK2hyNi9DSWJSTjk3SkFWcmZoN2xacXI3ZHZWMHY4Nyt1Q2VC?=
 =?utf-8?B?b2k3Vk1FQ2YvQjlVSjljSmxXcU84eDBBRHJ1U1BlYmExaGV1S1E5N1JOTTZI?=
 =?utf-8?B?aXo5OE1HdmNkRFloWU4xdjRWdlBIMDZKYXdFVUdyeUNZcGgvcEkwclRyZUda?=
 =?utf-8?B?NWhqa3hXNWc0alZyekZxZG5zY3IwVG92V0R0ZjNjY0JVRnB5dGxqcE05d3l2?=
 =?utf-8?B?REZ6SnI3UDQ4bkpZZ0NHVEptWUcxc3VrQStVb1RPeVRTSFd1YVBoSklZbWpl?=
 =?utf-8?B?V2JnSi9XamNYRGJXYVdOWER2cHNhdDlUNFRRY2FMSnY4aDJGdkppMVpWOW5L?=
 =?utf-8?B?L1RRbjlqVGk3S3oyLzgxRUZ1WXc4OHNVRmpJdG4rdmlxeGMzdjRoTzVsY0po?=
 =?utf-8?B?bzlJOGdhZzFLaHFGZkdPL2ZNV1k4ZGoyRGs0Z2UwVEJpUEErWmE2T3ViRFdu?=
 =?utf-8?B?TEVRL0w0VGNPd3p4TlV5bGYrbzViREIreUJpZ1I3bWEzVFNBL0wrOTh6VTdT?=
 =?utf-8?B?Tk0rV01nZUhBM0ppc3RlQjhZUUVQemQ1R1RNQ2VIcHFxMHJRTXJZOU1DYi82?=
 =?utf-8?B?Ti9vZmY3RFJoYmF4bzVrMXZYNnRYWUdER1NKZk1SelZqb1g1dEFDOHJoOVZp?=
 =?utf-8?B?Lys2UitCUy9DQnZkNWVSR0xPQjZ6a01naENQZi9sNTNEWThoZm9yZ01yWTFz?=
 =?utf-8?B?MlVkWlNZUWliYlhyVDJHeFRFRXpnRXlsS2Z5SXd4c1lYY3dCVTYvWm4yaW9W?=
 =?utf-8?B?aEw0VzZqRTJXZ0EyNGVyZnY5VytRUHBvSUE1WGtCZEIrTlFUVmZtYUFzU2k3?=
 =?utf-8?B?Vi9BTzJxMUZnOWcxS3JpV0F0Qyt0MkdyVTB5b2M0djl1aTJNOTZRUDBzczJv?=
 =?utf-8?B?TE15RnJGTGNlS2ZFY09SS21BZE02dEhYQmlvejV1ak5FVlpqbWdtSWNFZ1hH?=
 =?utf-8?B?czNidHRBeXRIVml2WjU1clQzM0M0VEwrMDVuYlVNNnBWNXlmN1MwdXd1bWYw?=
 =?utf-8?B?VFMraURBN1pyNGp4Mi9vU2lBWkVXditaa0EyWU9UTk82bWNScnlCaGpkQ3pF?=
 =?utf-8?B?bER3UGlMYWhFNDBza3MzVE5yOS9zVnh0V2NjU2RtQTZEZDZTSmJoelBJNzFZ?=
 =?utf-8?B?VmF1NlhvMkhJVVA0bkNpSDRwWTUyNEpCTGwrYXR0RFVTN1FxSC90eHkzY2VD?=
 =?utf-8?B?Z3BIb3dqdEZTN3UrUUZJNWx5dUJycHYxOUFzckNBcGFuSHhpejFRYkhmMEtW?=
 =?utf-8?B?bWgrN01QVXZwOXNYbkoxNE1QSGErSHRlZGkvN2hrdEtHWklNenpuQXJKenB6?=
 =?utf-8?B?WHgvamduaGNBYUhnclFETGg5c3o4YTAxWnlzYUJUUW1wcnJ2UFBnNjVtdER6?=
 =?utf-8?B?N3ZPWUd2RGhFUDRzdmREbWFmOXZMUDhOa2l5bVZuSnhqdFV4WG9laVBsWlVI?=
 =?utf-8?B?WG40NEJBd1FvSXZld0hiMy9qT0QzV095WGk3UFB5VnJEQVdSZlU5bzhiTGdB?=
 =?utf-8?B?WFlVeENrNzlXQlFYR2tWU00reko1T1NKcU9sMnZUeDhRNGxPREUxOFhhMGdi?=
 =?utf-8?B?dnRkNEVveWFNUFF5L2k1dmsyazZ4RmM4VGg4cjkxRExMeDc1MU50QTV6Zito?=
 =?utf-8?B?Zmt0MmwycnVkYmNQUHVKZlRzc0lOdFVDTy9CYzhWakhCMEtsYjFLcldSZCtF?=
 =?utf-8?B?UGhyckVpTE43SHY5TU1XM2tIS1VZVDF3N2VhMW9WNjNybXZOMDlUekg3alFn?=
 =?utf-8?B?akcrd3lpN1hhUnJtSlhNZ3V0bHZFcGwzdDI3VWVTWEx1eVFmMzdSY0NmVTEw?=
 =?utf-8?B?OUx2clh4L1F6RllqZmFOdThmZk9MT1ZSUStHRk9zanR4WWlWcnZPeFpqZ3Rh?=
 =?utf-8?B?SFljSTNtY1g1YjYyVmM0Qy9NYSs2aEZaWnMxS3Q3clQ4Zy9PQXpRSXFwNFNy?=
 =?utf-8?B?TFFFVWNUS3lmOE80S1A1QWpvMWVobytLNVo5djE1cnJOcXV6T09rLzI4Vk1H?=
 =?utf-8?Q?LKcOnn?=
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 Sep 2025 06:35:45.6544
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c0e5f05a-1eba-47af-926e-08ddeb7d4759
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06C.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7866

amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism. The new mechanism is based on
Collaborative Processor Performance Control (CPPC) which is a finer grain
frequency management than legacy ACPI hardware P-States.
Current AMD CPU platforms are using the ACPI P-states driver to
manage CPU frequency and clocks with switching only in 3 P-states, while the
new amd-cppc allows a more flexible, low-latency interface for Xen
to directly communicate the performance hints to hardware.

"amd-cppc" driver is responsible for implementing CPPC in passive mode, which
still leverages Xen governors such as *ondemand*, *performance*, etc, to
calculate the performance hints. In the future, we will introduce an advanced
active mode to enable autonomous performence level selection.

Field epp, energy performance preference, which only has meaning when active
mode is enabled and will be introduced later in details, so we read
pre-defined BIOS value for it in passive mode.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v1 -> v2:
- re-construct union caps and req to have anonymous struct instead
- avoid "else" when the earlier if() ends in an unconditional control flow statement
- Add check to avoid chopping off set bits from cast
- make pointers pointer-to-const wherever possible
- remove noisy log
- exclude families before 0x17 before CPPC-feature MSR op
- remove useless variable helpers
- use xvzalloc and XVFREE
- refactor error handling as ENABLE bit can only be cleared by reset
---
v2 -> v3:
- Move all MSR-definations to msr-index.h and follow the required style
- Refactor opening figure braces for struct/union
- Sort overlong lines throughout the series
- Make offset/res int covering underflow scenario
- Error out when amd_max_freq_mhz isn't set
- Introduce amd_get_freq(name) macro to decrease redundancy
- Supported CPU family checked ahead of smp-function
- Nominal freq shall be checked between the [min, max]
- Use APERF/MPREF to calculate current frequency
- Use amd_cppc_cpufreq_cpu_exit() to tidy error path
---
v3 -> v4:
- verbose print shall come with a CPU number
- deal with res <= 0 in amd_cppc_khz_to_perf()
- introduce a single helper amd_get_lowest_or_nominal_freq() to cover both
lowest and nominal scenario
- reduce abuse of wrmsr_safe()/rdmsr_safe() with wrmsrl()/rdmsrl()
- move cf_check from amd_cppc_write_request() to amd_cppc_write_request_msrs()
- add comment to explain why setting non_linear_lowest in passive mode
- add check to ensure perf values in
lowest <= non_linear_lowest <= nominal <= highset
- refactor comment for "data->err != 0" scenario
- use "data->err" instead of -ENODEV
- add U suffixes for all msr macro
---
v4 -> v5:
- all freq-values shall be unsigned int type
- remove shortcuts as it is rarely taken
- checking cpc.nominal_mhz and cpc.lowest_mhz are non-zero values is enough
- drop the explicit type cast
- null pointer check is in no need for internal functions
- change amd_get_lowest_or_nominal_freq() to amd_get_cpc_freq()
- clarifying function-wide that the calculated frequency result is to be in kHz
- use array notation
- with cpu_has_cppc check, no need to do cpu family check
---
v5 -> v6
- replace "AMD_CPPC" with "AMD-CPPC" in message
- add equation(mul,div) non-zero check
- replace -EINVAL with -EOPNOTSUPP
- refactor comment
---
v6 -> v7
- used > in place of !=, to not only serve a doc aspect, but also allow to
drop one part
- unify with UINT8_MAX
- return -ERANGE as we reject perf values of 0 as invalid
- replace uint32_t with unsigned int
- Move some epp introduction here, otherwise we will mis-handle this field here
by always clearing it
---
v7 -> v8:
- refine message text by removing 0
---
v8 -> v9
- embed struct amd_cppc_drv_data{} into struct cpufreq_policy{}
---
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 414 ++++++++++++++++++++++++++-
 xen/arch/x86/cpu/amd.c               |   8 +-
 xen/arch/x86/include/asm/amd.h       |   2 +
 xen/arch/x86/include/asm/msr-index.h |   6 +
 xen/include/acpi/cpufreq/cpufreq.h   |   4 +
 xen/include/public/sysctl.h          |   1 +
 6 files changed, 430 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 3377783f7e..5cf8b85c9f 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -14,7 +14,96 @@
 #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);  \
+})
+
+/*
+ * Field highest_perf, nominal_perf, lowest_nonlinear_perf, and lowest_perf
+ * contain the values read from CPPC capability MSR. They represent the limits
+ * of managed performance range as well as the dynamic capability, which may
+ * change during processor operation
+ * Field highest_perf represents highest performance, which is the absolute
+ * maximum performance an individual processor may reach, assuming ideal
+ * conditions. This performance level may not be sustainable for long
+ * durations and may only be achievable if other platform components
+ * are in a specific state; for example, it may require other processors be
+ * in an idle state. This would be equivalent to the highest frequencies
+ * supported by the processor.
+ * Field nominal_perf represents maximum sustained performance level of the
+ * processor, assuming ideal operating conditions. All cores/processors are
+ * expected to be able to sustain their nominal performance state
+ * simultaneously.
+ * Field lowest_nonlinear_perf represents Lowest Nonlinear Performance, which
+ * is the lowest performance level at which nonlinear power savings are
+ * achieved. Above this threshold, lower performance levels should be
+ * generally more energy efficient than higher performance levels. So in
+ * traditional terms, this represents the P-state range of performance levels.
+ * Field lowest_perf represents the absolute lowest performance level of the
+ * platform. Selecting it may cause an efficiency penalty but should reduce
+ * the instantaneous power consumption of the processor. So in traditional
+ * terms, this represents the T-state range of performance levels.
+ *
+ * Field max_perf, min_perf, des_perf store the values for CPPC request MSR.
+ * Software passes performance goals through these fields.
+ * Field max_perf conveys the maximum performance level at which the platform
+ * may run. And it may be set to any performance value in the range
+ * [lowest_perf, highest_perf], inclusive.
+ * Field min_perf conveys the minimum performance level at which the platform
+ * may run. And it may be set to any performance value in the range
+ * [lowest_perf, highest_perf], inclusive but must be less than or equal to
+ * max_perf.
+ * Field des_perf conveys performance level Xen governor is requesting. And it
+ * may be set to any performance value in the range [min_perf, max_perf],
+ * inclusive.
+ * Field epp represents energy performance preference, which only has meaning
+ * when active mode is enabled.
+ */
+struct amd_cppc_drv_data
+{
+    const struct xen_processor_cppc *cppc_data;
+    union {
+        uint64_t raw;
+        struct {
+            unsigned int lowest_perf:8;
+            unsigned int lowest_nonlinear_perf:8;
+            unsigned int nominal_perf:8;
+            unsigned int highest_perf:8;
+            unsigned int :32;
+        };
+    } caps;
+    union {
+        uint64_t raw;
+        struct {
+            unsigned int max_perf:8;
+            unsigned int min_perf:8;
+            unsigned int des_perf:8;
+            unsigned int epp:8;
+            unsigned int :32;
+        };
+    } req;
+
+    int err;
+};
+
+/*
+ * Core max frequency read from PstateDef as anchor point
+ * for freq-to-perf transition
+ */
+static DEFINE_PER_CPU_READ_MOSTLY(unsigned int, pxfreq_mhz);
+static DEFINE_PER_CPU_READ_MOSTLY(uint8_t, epp_init);
 
 static bool __init amd_cppc_handle_option(const char *s, const char *end)
 {
@@ -50,10 +139,333 @@ 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 &&
+         data->caps.nominal_perf > data->caps.lowest_perf &&
+         cppc_data->cpc.nominal_mhz > cppc_data->cpc.lowest_mhz )
+    {
+        mul = data->caps.nominal_perf - data->caps.lowest_perf;
+        div = cppc_data->cpc.nominal_mhz - cppc_data->cpc.lowest_mhz;
+
+        /*
+         * 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 -EOPNOTSUPP;
+    }
+
+    res = offset + (mul * freq) / (div * 1000);
+    if ( res > UINT8_MAX )
+    {
+        printk_once(XENLOG_WARNING
+                    "Perf value exceeds maximum value 255: %d\n", res);
+        *perf = UINT8_MAX;
+        return 0;
+    }
+    if ( res <= 0 )
+    {
+        printk_once(XENLOG_WARNING
+                    "Perf value smaller than minimum value: %d\n", res);
+        return -ERANGE;
+    }
+    *perf = res;
+
+    return 0;
+}
+
+/*
+ * _CPC may define nominal frequecy and lowest frequency, if not, use
+ * Processor Max Speed as anchor point to calculate.
+ * Output freq stores cpc frequency in kHz
+ */
+static int amd_get_cpc_freq(const struct amd_cppc_drv_data *data,
+                            unsigned int cpc_mhz, uint8_t perf,
+                            unsigned int *freq)
+{
+    unsigned int mul, div, res;
+
+    if ( cpc_mhz )
+    {
+        /* Switch to kHz */
+        *freq = cpc_mhz * 1000;
+        return 0;
+    }
+
+    /* Read Processor Max Speed(MHz) as anchor point */
+    mul = this_cpu(pxfreq_mhz);
+    if ( !mul )
+        return -EOPNOTSUPP;
+    div = data->caps.highest_perf;
+    res = (mul * perf * 1000) / div;
+    if ( unlikely(!res) )
+        return -EOPNOTSUPP;
+
+    return 0;
+}
+
+/* Output max_freq stores calculated maximum frequency in kHz */
+static int amd_get_max_freq(const struct amd_cppc_drv_data *data,
+                            unsigned int *max_freq)
+{
+    unsigned int nom_freq = 0;
+    int res;
+
+    res = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
+                           data->caps.nominal_perf, &nom_freq);
+    if ( res )
+        return res;
+
+    *max_freq = (data->caps.highest_perf * nom_freq) / data->caps.nominal_perf;
+
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
+                                 policy->cpuinfo.max_freq);
+
+    return 0;
+}
+
+static void cf_check amd_cppc_write_request_msrs(void *info)
+{
+    const struct amd_cppc_drv_data *data = info;
+
+    wrmsrl(MSR_AMD_CPPC_REQ, data->req.raw);
+}
+
+static void amd_cppc_write_request(unsigned int cpu,
+                                   struct amd_cppc_drv_data *data,
+                                   uint8_t min_perf, uint8_t des_perf,
+                                   uint8_t max_perf, uint8_t epp)
+{
+    uint64_t prev = data->req.raw;
+
+    data->req.min_perf = min_perf;
+    data->req.max_perf = max_perf;
+    data->req.des_perf = des_perf;
+    data->req.epp = epp;
+
+    if ( prev == data->req.raw )
+        return;
+
+    on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs, data, 1);
+}
+
+static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
+                                            unsigned int target_freq,
+                                            unsigned int relation)
+{
+    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
+    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;
+
+    /*
+     * Having a performance level lower than the lowest nonlinear
+     * performance level, such as, lowest_perf <= perf <= lowest_nonliner_perf,
+     * may actually cause an efficiency penalty, So when deciding the min_perf
+     * value, we prefer lowest nonlinear performance over lowest performance.
+     */
+    amd_cppc_write_request(policy->cpu, data, data->caps.lowest_nonlinear_perf,
+                           des_perf, data->caps.highest_perf,
+                           /* Pre-defined BIOS value for passive mode */
+                           per_cpu(epp_init, policy->cpu));
+    return 0;
+}
+
+static void cf_check amd_cppc_init_msrs(void *info)
+{
+    struct cpufreq_policy *policy = info;
+    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
+    uint64_t val;
+    unsigned int min_freq = 0, nominal_freq = 0, max_freq;
+
+    /* Package level MSR */
+    rdmsrl(MSR_AMD_CPPC_ENABLE, val);
+    /*
+     * Only when Enable bit is on, the hardware will calculate the processor’s
+     * performance capabilities and initialize the performance level fields in
+     * the CPPC capability registers.
+     */
+    if ( !(val & AMD_CPPC_ENABLE) )
+    {
+        val |= AMD_CPPC_ENABLE;
+        wrmsrl(MSR_AMD_CPPC_ENABLE, val);
+    }
+
+    rdmsrl(MSR_AMD_CPPC_CAP1, data->caps.raw);
+
+    if ( data->caps.highest_perf == 0 || data->caps.lowest_perf == 0 ||
+         data->caps.nominal_perf == 0 || data->caps.lowest_nonlinear_perf == 0 ||
+         data->caps.lowest_perf > data->caps.lowest_nonlinear_perf ||
+         data->caps.lowest_nonlinear_perf > data->caps.nominal_perf ||
+         data->caps.nominal_perf > data->caps.highest_perf )
+    {
+        amd_cppc_err(policy->cpu,
+                     "Out of range values: highest(%u), lowest(%u), nominal(%u), lowest_nonlinear(%u)\n",
+                     data->caps.highest_perf, data->caps.lowest_perf,
+                     data->caps.nominal_perf, data->caps.lowest_nonlinear_perf);
+        goto err;
+    }
+
+    amd_process_freq(&cpu_data[policy->cpu],
+                     NULL, NULL, &this_cpu(pxfreq_mhz));
+
+    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.lowest_mhz,
+                                 data->caps.lowest_perf, &min_freq);
+    if ( data->err )
+        return;
+
+    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
+                                 data->caps.nominal_perf, &nominal_freq);
+    if ( data->err )
+        return;
+
+    data->err = amd_get_max_freq(data, &max_freq);
+    if ( data->err )
+        return;
+
+    if ( min_freq > nominal_freq || nominal_freq > max_freq )
+    {
+        amd_cppc_err(policy->cpu,
+                     "min(%u), or max(%u), or nominal(%u) freq value is incorrect\n",
+                     min_freq, max_freq, nominal_freq);
+        goto err;
+    }
+
+    policy->min = min_freq;
+    policy->max = max_freq;
+
+    policy->cpuinfo.min_freq = min_freq;
+    policy->cpuinfo.max_freq = max_freq;
+    policy->cpuinfo.perf_freq = nominal_freq;
+    /*
+     * Set after policy->cpuinfo.perf_freq, as we are taking
+     * APERF/MPERF average frequency as current frequency.
+     */
+    policy->cur = cpufreq_driver_getavg(policy->cpu, GOV_GETAVG);
+
+    /* Store pre-defined BIOS value for passive mode */
+    rdmsrl(MSR_AMD_CPPC_REQ, val);
+    this_cpu(epp_init) = MASK_EXTR(val, AMD_CPPC_EPP_MASK);
+
+    return;
+
+ err:
+    /*
+     * No fallback shceme is available here, see more explanation at call
+     * site in amd_cppc_cpufreq_cpu_init().
+     */
+    data->err = -EINVAL;
+}
+
+/*
+ * AMD CPPC driver is different than legacy ACPI hardware P-State,
+ * which has a finer grain frequency range between the highest and lowest
+ * frequency. And boost frequency is actually the frequency which is mapped on
+ * highest performance ratio. The legacy P0 frequency is actually mapped on
+ * nominal performance ratio.
+ */
+static void amd_cppc_boost_init(struct cpufreq_policy *policy,
+                                const struct amd_cppc_drv_data *data)
+{
+    if ( data->caps.highest_perf <= data->caps.nominal_perf )
+        return;
+
+    policy->turbo = CPUFREQ_TURBO_ENABLED;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    XVFREE(policy->u.amd_cppc);
+
+    return 0;
+}
+
+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;
+    policy->u.amd_cppc = data;
+
+    data->cppc_data = &processor_pminfo[cpu]->cppc_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 is taken effective, not only amd-cppc cpufreq core fails
+     * 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 core in CPPC mode\n");
+        amd_cppc_cpufreq_cpu_exit(policy);
+        return data->err;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    amd_cppc_boost_init(policy, data);
+
+    amd_cppc_verbose(policy->cpu,
+                     "CPU initialized with amd-cppc passive mode\n");
+
+    return 0;
+}
+
+static const struct cpufreq_driver __initconst_cf_clobber
+amd_cppc_cpufreq_driver =
+{
+    .name   = XEN_AMD_CPPC_DRIVER_NAME,
+    .verify = amd_cppc_cpufreq_verify,
+    .target = amd_cppc_cpufreq_target,
+    .init   = amd_cppc_cpufreq_cpu_init,
+    .exit   = amd_cppc_cpufreq_cpu_exit,
+};
+
 int __init amd_cppc_register_driver(void)
 {
     if ( !cpu_has_cppc )
         return -ENODEV;
 
-    return -EOPNOTSUPP;
+    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);
 }
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 567b992a9f..9767f63539 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -613,10 +613,10 @@ static unsigned int attr_const amd_parse_freq(unsigned int family,
 	return freq;
 }
 
-static void amd_process_freq(const struct cpuinfo_x86 *c,
-			     unsigned int *low_mhz,
-			     unsigned int *nom_mhz,
-			     unsigned int *hi_mhz)
+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;
diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index 9c9599a622..72df42a6f6 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -173,5 +173,7 @@ extern bool amd_virt_spec_ctrl;
 bool amd_setup_legacy_ssbd(void);
 void amd_set_legacy_ssbd(bool enable);
 void amd_set_cpuid_user_dis(bool enable);
+void amd_process_freq(const struct cpuinfo_x86 *c, unsigned int *low_mhz,
+                      unsigned int *nom_mhz, unsigned int *hi_mhz);
 
 #endif /* __AMD_H__ */
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index bb48d16f0c..df52587c85 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -252,6 +252,12 @@
 
 #define MSR_AMD_CSTATE_CFG                  0xc0010296U
 
+#define MSR_AMD_CPPC_CAP1                   0xc00102b0U
+#define MSR_AMD_CPPC_ENABLE                 0xc00102b1U
+#define  AMD_CPPC_ENABLE                    (_AC(1, ULL) << 0)
+#define MSR_AMD_CPPC_REQ                    0xc00102b3U
+#define  AMD_CPPC_EPP_MASK                  (_AC(0xff, ULL) << 24)
+
 /*
  * Legacy MSR constants in need of cleanup.  No new MSRs below this comment.
  */
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index c0ecd690c5..baffb5bbe6 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -63,6 +63,7 @@ struct perf_limits {
 };
 
 struct hwp_drv_data;
+struct amd_cppc_drv_data;
 struct cpufreq_policy {
     cpumask_var_t       cpus;          /* affected CPUs */
     unsigned int        shared_type;   /* ANY or ALL affected CPUs
@@ -85,6 +86,9 @@ struct cpufreq_policy {
     union {
 #ifdef CONFIG_INTEL
         struct hwp_drv_data *hwp; /* Driver data for Intel HWP */
+#endif
+#ifdef CONFIG_AMD
+        struct amd_cppc_drv_data *amd_cppc; /* Driver data for AMD CPPC */
 #endif
     } u;
 };
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index aafa7fcf2b..aa29a5401c 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -453,6 +453,7 @@ struct xen_set_cppc_para {
     uint32_t activity_window;
 };
 
+#define XEN_AMD_CPPC_DRIVER_NAME "amd-cppc"
 #define XEN_HWP_DRIVER_NAME "hwp"
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:35:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:35:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109501.1459080 (Exim 4.92)
	(envelope-from )
	id 1uu3Ze-0003UQ-Vi; Thu, 04 Sep 2025 06:35:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109501.1459080; Thu, 04 Sep 2025 06:35: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 1uu3Ze-0003UF-Qa; Thu, 04 Sep 2025 06:35:58 +0000
Received: by outflank-mailman (input) for mailman id 1109501;
 Thu, 04 Sep 2025 06:35:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uu3Zd-0002id-5B
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:35:57 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20614.outbound.protection.outlook.com
 [2a01:111:f403:2416::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 68bb4358-8959-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 08:35:55 +0200 (CEST)
Received: from BN0PR07CA0004.namprd07.prod.outlook.com (2603:10b6:408:141::22)
 by SJ2PR12MB8717.namprd12.prod.outlook.com (2603:10b6:a03:53d::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 06:35:49 +0000
Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com
 (2603:10b6:408:141:cafe::2b) by BN0PR07CA0004.outlook.office365.com
 (2603:10b6:408:141::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 06:35:49 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9115.0 via Frontend Transport; Thu, 4 Sep 2025 06:35:49 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:49 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:47 -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: 68bb4358-8959-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FAzzTj/5Kc7saUwPSVjXmsIonZwDGS0ZGbtFCpzGVi06grq3D0JHXvSsTon72k3ughDRnEMjri4qcd8V+fwAZ8c7bAT/QRnovfgbmMBqgD8SP4WlU8NH72gMTjXSXu/RnGJxUm+ZduFWHt9HQc5SHjirIU7okey/v/DkD6wIUaxFB4FncFTR4ObApN/eZhkI2SceZveaLWIY7NvM2jPfrP2Svejy/0OYvHyuibVfh/kBEsJk1LAVzjnCiApCqAXrK6ucVpE0v5vw0qB1mCUBcI6+72/IECKnkS+xEOSMc4DbFLAAHSU5+2cqK10LoeLmNKp/iP47YKH/+Iv2Q17TZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wwwi0tW4Ht3ef4KEnk99tP23MKB3LmcikYL/tmBwt+Y=;
 b=ClN4CMBSsQSWJDnWlIINnRJaAJet8wqbnkuaf+R92j3sZPgZePTCd+pDIYnMMlZjySsSjnynLLre03iiiHJZGD8QY7KJt6LdGDp0hushKmgR39OzG4ByQiqMuK0q6I0fRayzeaU4uQQjHVByNEc7kCYmxLN+0YsmqlnnxAp3RRg+1uvFI/PKW4ikF9F71BCOZ3hxIxp5fKBkX0+7486njzKS4/b+3p0OotmzsTST98aBf0DkW6+i1p+rA2Qgr5r1+IptXlL7jnHAHkjud5gqilIOyJV6oUAn3a4OjEVPNf/Oye9ofyVK0AyExqiAF8rzrzzDn+vT60qIzBqTICPpzg==
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=wwwi0tW4Ht3ef4KEnk99tP23MKB3LmcikYL/tmBwt+Y=;
 b=aVk9wFHFswzkz44mbuH5m27I/azqOqqvVGSzEgGeBxmGyrgDC8O5ySVqNIVQV6F+IOgJS0N2aYkZqW0Aei8xeO9MAvZ3HORiuRz1DwCGmnF/gLFSHcQgX52ILdxXxyTkXM8kQ6i1qRtqYikwZLOPfNL8dxiNrW2SK920fVJxpvk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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 
Subject: [PATCH v9 4/8] xen/cpufreq: get performance policy from governor set via xenpm
Date: Thu, 4 Sep 2025 14:35:14 +0800
Message-ID: <20250904063518.2097629-5-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|SJ2PR12MB8717:EE_
X-MS-Office365-Filtering-Correlation-Id: 0314d65e-5834-498c-5d89-08ddeb7d49b1
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?u+Mi3DimZ+UyW6CYKdnemqhM8xCOq/S0jChMsdtX+rZFENYSZPtG4TgbCut1?=
 =?us-ascii?Q?4rEyzyW0nUYKtJq7kTVsCjAy2fubbMiYM90HACIn+sa3VIOTyZIVlJhsALfv?=
 =?us-ascii?Q?TR/JNQXZZ6A10gjOsswCB22gT6Y5ybXz+3DMmeIeTTYZuOZQOygoIZz//TbV?=
 =?us-ascii?Q?9GQV5M0B79Nu8pTLwTt9zZbGqk+pI2+5KwnP7FvPEBPdIN3VUTEK3+THGSX+?=
 =?us-ascii?Q?dA6j9Oyf5pzDXl4YZey1fivfwJYCtvkgUlBR52MiMzFbfRZEZRLtk/DcIMdK?=
 =?us-ascii?Q?JrJNgYRDfgNr4LsS7z/eOev+VUyuiMKZw7xGwR7B1VefWDc/vzB1ZCsS+Mid?=
 =?us-ascii?Q?tdvugmuJDemu6u+KvOKbNlHi3VRsPWsrXqEtshu05Ps3ZJEza4Vp7rPJVIJU?=
 =?us-ascii?Q?QQWTXLK2jQT5NPHkUJCtmrcvk4BErAsuwWKKuyFLqhiSAnQcXngnsuFuMBDX?=
 =?us-ascii?Q?mTG9zUj2C1pcYZopBL1xIf3HqCR3dDpBB5y12cc0K2IsN/IzgvkoD3p3ppIa?=
 =?us-ascii?Q?mKDlSoIWZpYZfHa9fiXWduwaxfcd8tRY05iAOYl6LLQt1kuXbYM5FeQavqG/?=
 =?us-ascii?Q?Mb/Y+Rk9aV5QUDs5LFofSkeCA+ea+hQ3Ow7VaFPf+p6py8CIvPGPxhrwOiGE?=
 =?us-ascii?Q?5vzqZESx1CRJZl/mLM8wnZZr725ReR2Tr8RpSGADkOCx+95t0k0jwZwISZgC?=
 =?us-ascii?Q?dRItpl7QFrXfmZO1ohcwtIl1n2WVYUS/W93wEY8/zoLjDvvdG24x1fRTCpcp?=
 =?us-ascii?Q?ei+bZBDjkTEml5mrrzLbIN3qsJF/amdkyi12XpP86dR1B7qSvgO2nll2H4f2?=
 =?us-ascii?Q?Kat+pK3XxpxqxE0IBoRO80EAxfONyMuoK5L9aEEhR3z2wi4pwcUSoHrhlo6y?=
 =?us-ascii?Q?r0QhKaYsncTbXBES9GZeBlb9TGbkAftieC8thj/SPqIPUcDvgsXM6RZnelqB?=
 =?us-ascii?Q?6mwUoHtGUnDurdvYQo5dfIi6iutXQDLc4KfKg/zi9zL+zQHPDVSfV1iArNqs?=
 =?us-ascii?Q?GxUu9kam87xw++Yw/tFQzm2gVxvNXWeyxLYow2oI6p7XFPciZnWZGXY1WwYI?=
 =?us-ascii?Q?KGN8mJCad9RS9opUn7mhEMqDE/4uP3Hu7CK+Qd4g1PEAIMKZpyKYxEte9Wq0?=
 =?us-ascii?Q?bEHKxncW+1ho1h0E9m+GImf052xvOTEz0NM0IO+C4IPeu5suu4JknOTozJHv?=
 =?us-ascii?Q?97SpnnFjqVCs0LKPOaLgv2dIt7kcEY1SSBwLQHzdA05enGQqKrjO06bOL/P8?=
 =?us-ascii?Q?Rb+lO/GMnfrB8PaJ3zbRTX1/DzhawIfneqeoiTUw6Q8GT/FNaxuFSYK3jiJL?=
 =?us-ascii?Q?zxqTGOTCtKY6qtRrhZvXOQwMsbYQaoCK7+GRSORIbCWOjIORP9sTjZcV7ns2?=
 =?us-ascii?Q?tJ0LanZH0bTEhtrpap0pXgmgyCBxXD6PL+xGtSq9prttvG7srIAnXCsfmseQ?=
 =?us-ascii?Q?J5VX/OSB7drIgwl3OA5NP/dWSyM99w/9m4rQIpk5asrlQuWGmOcvO5HqyL0g?=
 =?us-ascii?Q?UK2Yjogg9JK37TOZOkrZlMpakDnxyIYVwiiE?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 06:35:49.5834
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0314d65e-5834-498c-5d89-08ddeb7d49b1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06C.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8717

Even if Xen governor is not used in amd-cppc active mode, we could
somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
apply through which governor they choose, such as:
If user chooses performance governor, they want maximum performance, then
the policy shall be CPUFREQ_POLICY_PERFORMANCE
If user chooses powersave governor, they want the least power consumption,
then the policy shall be CPUFREQ_POLICY_POWERSAVE
Function cpufreq_policy_from_governor() is responsible for above transition,
and it shall be also effective when users setting new governor through xenpm.

Userspace is a forbidden choice, and if users specify such option, we shall
not only give warning message to suggest using "xenpm set-cpufreq-cppc", but
also error out.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v4 -> v5:
- new commit
---
v5 -> v6:
- refactor warning message
---
v6 -> v7:
- move policy->policy set where it firstly gets introduced
- refactor commit message
---
v7 -> v8:
- policy transition is only limited in CPPC mode
---
 xen/drivers/acpi/pm-op.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index 2f516e62b1..a7eaf29c31 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -207,6 +207,17 @@ static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
     if ( new_policy.governor == NULL )
         return -EINVAL;
 
+    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+    {
+        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, Try \"xenpm set-cpufreq-cppc\"\n",
+                   new_policy.governor->name);
+            return -EINVAL;
+        }
+    }
+
     return __cpufreq_set_policy(old_policy, &new_policy);
 }
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:36:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:36:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109503.1459090 (Exim 4.92)
	(envelope-from )
	id 1uu3Zg-0003kF-8Z; Thu, 04 Sep 2025 06:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109503.1459090; Thu, 04 Sep 2025 06:36: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 1uu3Zg-0003jI-3Y; Thu, 04 Sep 2025 06:36:00 +0000
Received: by outflank-mailman (input) for mailman id 1109503;
 Thu, 04 Sep 2025 06:35: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 1uu3Ze-0002id-5E
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:35:58 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20625.outbound.protection.outlook.com
 [2a01:111:f403:2417::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 688a062a-8959-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 08:35:55 +0200 (CEST)
Received: from MN2PR13CA0004.namprd13.prod.outlook.com (2603:10b6:208:160::17)
 by MN2PR12MB4333.namprd12.prod.outlook.com (2603:10b6:208:1d3::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 06:35:48 +0000
Received: from MN1PEPF0000F0E4.namprd04.prod.outlook.com
 (2603:10b6:208:160:cafe::d5) by MN2PR13CA0004.outlook.office365.com
 (2603:10b6:208:160::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.6 via Frontend Transport; Thu, 4
 Sep 2025 06:35:48 +0000
Received: from SATLEXMB03.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.9094.14 via Frontend Transport; Thu, 4 Sep 2025 06:35:48 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:47 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:44 -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: 688a062a-8959-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lyyf7/GvWpH1QCZ1ZaJzBKcY8GJZdZs2UNlOhuUyosB5cMTfovhulTvzD0BIsPUUf0KqNsazJKlL4/97VJH28farJTBhTBOvGLryxOkzMpFiiQR9fH+uXoacABQYF/q/C0Hubjk7mbmQ9I8C/PIRW52FrG2tFEMs0u3z+eFypd87O1pFhRjVbB2PmjIcVZC7QQCbng1QZfmVptkJU/UAlugtXAVTIh3GnoDVSxEjr4frJKq3r3BAYT+oDNXrVBKLUo70BpIJYtVshIRQBit6vIVpiah5jGevQZr3AW24APirQsDQxI38NmlLH0QKp9W5gTtnbZTRQIN8GmBhsFuP6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=InJtpruVkIRxBk/COpkjf7/TVaYM33EtsQkgjkXoAW8=;
 b=lt8MGLJ+uHOPKPySAFYJV0QrcXKeArrZ0jAwGY+9dc73ncXsAiFza4zJoZAnpGxNDZzAvRVaNEhMIYUwFDgD32FWva+NThvw7+bJhC1+HQA095jQc1fOic+g6UpgMarzSCCiQDgolTJOxMD5Q/AhIdyMu+dapVkPmorCo90jUFD2uxVUUHfxtJqVvBAbhLYHrYVPkBHhbxiAQObxhGZVPU0dYOuUL/TDwjYEjUfjQXMnWZeXDRQzKlJnFeO9kYJfbRGhm3lV0wCnewp1XbK7YTk6CsIN11mmdqUHQ6HZ2POb/myQ+t8iQiqlWYMyFvoTJf0YNpIgd38zK3IEwjzuNw==
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=InJtpruVkIRxBk/COpkjf7/TVaYM33EtsQkgjkXoAW8=;
 b=qv2gl6dzTZ6flIGQY3h6PNNlmwz5bi4rzVsa4z2BrZFKX5NR+19dsuJUUf/kL1u7YU6U8mfqgoiVq3wV5vUzHMdo6pD12hbmIkn+DcjFq5Mw8cdwa6mbL9vUllVYZEGGJTQkuVhj8kISVfAc0uGBmxkevH6q0K1J+9iIZFGkT0E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: 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 v9 3/8] xen/cpufreq: implement amd-cppc-epp driver for CPPC in active mode
Date: Thu, 4 Sep 2025 14:35:13 +0800
Message-ID: <20250904063518.2097629-4-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E4:EE_|MN2PR12MB4333:EE_
X-MS-Office365-Filtering-Correlation-Id: 2fa9aaed-60a1-408b-8fc2-08ddeb7d4907
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?mSjGSYBqmUfs2yTMw6D3H15SLpWPzCLS8Yd/HtE8ullRBwXrl2K0vdnTeiUs?=
 =?us-ascii?Q?8qEt3W/L7f/ut0ZhjYZGoWO7Ye5hWHA0CVScWxgg+xJqVLZhDqKFWrPNuRs5?=
 =?us-ascii?Q?2PEb9TrqS/zNpyxMcJWDQP3L6hENj6kw6nY1ztkB4fisz/3HY+t7EUPCRh6p?=
 =?us-ascii?Q?bHUDXfsp6+ebe6+wsYUZOLhHoCBikXdPY3IARf0ZuoOCAJYm137n5rvZKJOv?=
 =?us-ascii?Q?0iAIjoEmY+hIklIG2mLyJFojYKBNcSbzH0QIbXEqYCai0o1S70YHZ9q8GXa1?=
 =?us-ascii?Q?hWA6Fu9NMlLA+83/t2g+MEDZFk/7K97wHBpzYSuFuLJzk3ofIUnDb6W+g9cn?=
 =?us-ascii?Q?PLv//Wt1yZYmlyzWMYTzYRuOJvF4v0wgPCOxpVT5VetSJBpy4JKe6K9r/nE2?=
 =?us-ascii?Q?3F1i2NlAW26154HptwIX335AYWn4voQyIwbG6ptBGnd4JyjKI6escVt7+Kzy?=
 =?us-ascii?Q?zZBSpqDip1pnBuYxLBctdp5IaZxE4LuUQfbHjPHJ+2exzeISFNiGnv+jrd7C?=
 =?us-ascii?Q?DP1oQb4OIBHWJIhEXAbuHpZtK0dC6YfIpwA0C915Nt1egD8E1LyGkeH+KKng?=
 =?us-ascii?Q?gHqXkRR7mS5b6yJbGOtOiCC7Gq9+P99257llttq9kmhqE8n//lLyEKs4M9Qv?=
 =?us-ascii?Q?eJy/LgevNh+J6U7B576DaNiqngpDWTX6CJssGw01PbxZpWC2bz5jZybhhylh?=
 =?us-ascii?Q?+L6THDBjWm+uDZA8DbfparWwoqKoAnwPIqGeNlaY/R8ux/fa8ziydVfwFtsW?=
 =?us-ascii?Q?itapzOW259pRmDIsp5XGg8fPC6lqjbEuT7eoj47guxPbBv0bMqm4uzV9RodD?=
 =?us-ascii?Q?EqCGkdJioQvB3bjmXXSdvefMUT4uoYOjGwr6sNQLMncj6escKY9cWO8Tz5X+?=
 =?us-ascii?Q?VbzSJrTtcH6/IJCAbgt5GoiS0I1aBiOF8ar7RJVQQf1vNBQFSC03Pzhf5ZwJ?=
 =?us-ascii?Q?HtRzvBBtB9Ir3SDKF+YSbzvrtcjveDE5klju0BvvjxXb5+ZOrxkdpWq7ilNq?=
 =?us-ascii?Q?ZvPHHMBxiABp6YrU9Z2w1kn1HtPmycKd6I/ZZriy5WZtvPrlz+hvJlCTnb3o?=
 =?us-ascii?Q?Cyi1vCgymVD0hPkl2Ucbfpy7aWKBVYYsF5vmHPCJ1m+EsvkSNAwkh+kq3Ut3?=
 =?us-ascii?Q?sL1CmFsW5FGcS+xJq6DeJsb9Ip92Q9zr9qVFdcG2q216Ow2gu2ZpxFlo3KL7?=
 =?us-ascii?Q?+DZMonYTeZDSnnNq66NkuadbP6vb/ry70xae3MJeaLehtxIcRpJvdLW1a1gG?=
 =?us-ascii?Q?CKvn8V89sR2h6mKyYicahAI/csThLlphEtncAb9tKDqGjg/YoO8Z/6als8VE?=
 =?us-ascii?Q?VHRwCU+TOPmVcrIUEiGx3oFBa+9RdFexKgLn8hKm2u8l0QzAe+eg4QAaHX7N?=
 =?us-ascii?Q?vMV1ZjAWPcorQEE2D1I0rgNlIWsFa4SnYdCloQTqllBMoiv/hON26qRWFgtt?=
 =?us-ascii?Q?+AmInYh+hrpV/4use1iE0fO0e7thj68flbOOT5rq/WtNqHm3IX0Pb253dMMr?=
 =?us-ascii?Q?hiCLxCOUUl5iSqlOXZufUY2ky40LL78bEJha?=
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)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 06:35:48.4701
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fa9aaed-60a1-408b-8fc2-08ddeb7d4907
X-MS-Exchange-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:
	MN1PEPF0000F0E4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4333

amd-cppc has 2 operation modes: autonomous (active) mode and
non-autonomous (passive) mode.
In active mode, we don't need Xen governor to calculate and tune the cpu
frequency, while hardware built-in CPPC power algorithm will calculate the
runtime workload and adjust cores frequency automatically according to the
power supply, thermal, core voltage and some other hardware conditions.
In active mode, CPPC ignores requests done in the desired performance field,
and takes into account only the values set to the minimum performance, maximum
performance, and energy performance preference registers.

A new field EPP (energy performance preference), in CPPC request register, is
introduced. It will be used in the CCLK DPM controller to drive the frequency
that a core is going to operate during short periods of activity, called
minimum active frequency, It could contatin a range of values from 0 to 0xff.
An EPP of zero sets the min active frequency to maximum frequency, while
an EPP of 0xff sets the min active frequency to approxiately Idle frequency.

We implement a new AMD CPU frequency driver `amd-cppc-epp` for active mode.
It requires `active` tag in Xen cmdline for users to explicitly select active
mode.
In driver `active-cppc-epp`, ->setpolicy() is hooked, not the ->target(), as
it does not depend on xen governor to do performance tuning.

We also introduce a new field "policy" (CPUFREQ_POLICY_xxx) to represent
performance policy. Right now, it supports three values:
CPUFREQ_POLICY_PERFORMANCE as maximum performance, CPUFREQ_POLICY_POWERSAVE
as the least power consumption, and CPUFREQ_POLICY_ONDEMAND as no preference,
just corresponding to "performance", "powersave" and "ondemand" Xen governor,
which benefit users from re-using "governor" in Xen cmdline to deliver
which performance policy they want to apply.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v1 -> v2:
- Remove redundant epp_mode
- Remove pointless initializer
- Define sole caller read_epp_init_once and epp_init value to read
pre-defined BIOS epp value only once
- Combine the commit "xen/cpufreq: introduce policy type when
cpufreq_driver->setpolicy exists"
---
v2 -> v3:
- Combined with commit "x86/cpufreq: add "cpufreq=amd-cppc,active" para"
- Refactor doc about "active mode"
- Change opt_cpufreq_active to opt_active_mode
- Let caller pass epp_init when unspecified to allow the function parameter
to be of uint8_t
- Make epp_init per-cpu value
---
v3 -> v4:
- doc refinement
- use MASK_EXTR() to get epp value
- fix indentation
- replace if-else() with switch()
- combine successive comments and do refinement
- no need to introduce amd_cppc_epp_update_limit() as a wrapper
- rename cpufreq_parse_policy() with cpufreq_policy_from_governor()
- no need to use case-insensitive comparison
---
v4 -> v5:
- refine doc to state what the default is for "active" sub-option and it's of
boolean nature
- excess blank after << for AMD_CPPC_EPP_MASK
- set max_perf with lowest_perf to get utmost powersave
- refine commit message to include description about relation between "policy"
and "governor"
---
v5 -> v6:
- expand comment for "epp" field
- let min_perf set with lowest_nonliner_perf, not lowest_perf, to constrain
  performance tuning in P-states range
- refactor doc and comments
- blank lines between non-fall-through case blocks
- introduce and add entry for "CPUFREQ_POLICY_ONDEMAND"
---
v6 -> v7
- make opt_active_mode __initdata when NDEBUG=y
- add assertion check for must-zero des_perf in active mode
- use the local variable max_perf and min_perf
- read_epp_init() doesn't worth a separate function
---
v7 -> v8:
- use "ASSERT(!opt_active_mode || !des_perf);" to remove #ifndef NDEBUG
- add a new helper amd_cppc_prepare_policy()
---
v8 -> v9:
- Adapt to changes of "Embed struct amd_cppc_drv_data{} into struct
cpufreq_policy{}"
---
 docs/misc/xen-command-line.pandoc    |   9 +-
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 134 ++++++++++++++++++++++++++-
 xen/drivers/cpufreq/utility.c        |  15 +++
 xen/include/acpi/cpufreq/cpufreq.h   |  18 ++++
 xen/include/public/sysctl.h          |   1 +
 5 files changed, 172 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 4adcd7e762..adfdf71b40 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -515,7 +515,7 @@ If set, force use of the performance counters for oprofile, rather than detectin
 available support.
 
 ### cpufreq
-> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[verbose]]`
+> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[active][,verbose]]`
 
 > Default: `xen`
 
@@ -537,6 +537,13 @@ 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 don't rely on Xen governor to do performance monitoring
+  and tuning. Hardware built-in CPPC power algorithm will calculate the runtime
+  workload and adjust cores frequency automatically according to the power
+  supply, thermal, core voltage and some other hardware conditions.
+  The default is disabled, and the option only applies when `amd-cppc` is
+  enabled.
 
 There is also support for `;`-separated fallback options:
 `cpufreq=hwp;xen,verbose`.  This first tries `hwp` and falls back to `xen` if
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 5cf8b85c9f..80b829b84e 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -67,9 +67,14 @@
  * max_perf.
  * Field des_perf conveys performance level Xen governor is requesting. And it
  * may be set to any performance value in the range [min_perf, max_perf],
- * inclusive.
+ * inclusive. In active mode, des_perf must be zero.
  * Field epp represents energy performance preference, which only has meaning
- * when active mode is enabled.
+ * when active mode is enabled. The EPP is used in the CCLK DPM controller
+ * to drive the frequency that a core is going to operate during short periods
+ * of activity, called minimum active frequency, It could contatin a range of
+ * values from 0 to 0xff. An EPP of zero sets the min active frequency to
+ * maximum frequency, while an EPP of 0xff sets the min active frequency to
+ * approxiately Idle frequency.
  */
 struct amd_cppc_drv_data
 {
@@ -104,6 +109,12 @@ struct amd_cppc_drv_data
  */
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned int, pxfreq_mhz);
 static DEFINE_PER_CPU_READ_MOSTLY(uint8_t, epp_init);
+#ifndef NDEBUG
+static bool __ro_after_init opt_active_mode;
+#else
+static bool __initdata opt_active_mode;
+#endif
+
 
 static bool __init amd_cppc_handle_option(const char *s, const char *end)
 {
@@ -116,6 +127,13 @@ static bool __init amd_cppc_handle_option(const char *s, const char *end)
         return true;
     }
 
+    ret = parse_boolean("active", s, end);
+    if ( ret >= 0 )
+    {
+        opt_active_mode = ret;
+        return true;
+    }
+
     return false;
 }
 
@@ -268,6 +286,7 @@ static void amd_cppc_write_request(unsigned int cpu,
 
     data->req.min_perf = min_perf;
     data->req.max_perf = max_perf;
+    ASSERT(!opt_active_mode || !des_perf);
     data->req.des_perf = des_perf;
     data->req.epp = epp;
 
@@ -414,7 +433,7 @@ static int cf_check amd_cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
     return 0;
 }
 
-static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+static int amd_cppc_cpufreq_init_perf(struct cpufreq_policy *policy)
 {
     unsigned int cpu = policy->cpu;
     struct amd_cppc_drv_data *data;
@@ -446,12 +465,102 @@ static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
     amd_cppc_boost_init(policy, data);
 
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    int ret;
+
+    ret = amd_cppc_cpufreq_init_perf(policy);
+    if ( ret )
+        return ret;
+
     amd_cppc_verbose(policy->cpu,
                      "CPU initialized with amd-cppc passive mode\n");
 
     return 0;
 }
 
+static int cf_check amd_cppc_epp_cpu_init(struct cpufreq_policy *policy)
+{
+    int ret;
+
+    ret = amd_cppc_cpufreq_init_perf(policy);
+    if ( ret )
+        return ret;
+
+    policy->policy = cpufreq_policy_from_governor(policy->governor);
+
+    amd_cppc_verbose(policy->cpu,
+                     "CPU initialized with amd-cppc active mode\n");
+
+    return 0;
+}
+
+static void amd_cppc_prepare_policy(struct cpufreq_policy *policy,
+                                    uint8_t *max_perf, uint8_t *min_perf,
+                                    uint8_t *epp)
+{
+    const struct amd_cppc_drv_data *data = policy->u.amd_cppc;
+
+    /*
+     * On default, set min_perf with lowest_nonlinear_perf, and max_perf
+     * with the highest, to ensure performance scaling in P-states range.
+     */
+    *max_perf = data->caps.highest_perf;
+    *min_perf = data->caps.lowest_nonlinear_perf;
+
+    /*
+     * In policy CPUFREQ_POLICY_PERFORMANCE, increase min_perf to
+     * highest_perf to achieve ultmost performance.
+     * In policy CPUFREQ_POLICY_POWERSAVE, decrease max_perf to
+     * lowest_nonlinear_perf to achieve ultmost power saving.
+     * Set governor only to help print proper policy info to users.
+     */
+    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 = *max_perf;
+        policy->governor = &cpufreq_gov_performance;
+        break;
+
+    case CPUFREQ_POLICY_POWERSAVE:
+        /* Force the epp value to be 0xff for powersave policy */
+        *epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
+        *max_perf = *min_perf;
+        policy->governor = &cpufreq_gov_powersave;
+        break;
+
+    case CPUFREQ_POLICY_ONDEMAND:
+        /*
+         * Set epp with medium value to show no preference over performance
+         * or powersave
+         */
+        *epp = CPPC_ENERGY_PERF_BALANCE;
+        policy->governor = &cpufreq_gov_dbs;
+        break;
+
+    default:
+        *epp = per_cpu(epp_init, policy->cpu);
+        break;
+    }
+}
+
+static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
+{
+    uint8_t max_perf, min_perf, epp;
+
+    amd_cppc_prepare_policy(policy, &max_perf, &min_perf, &epp);
+
+    amd_cppc_write_request(policy->cpu, policy->u.amd_cppc, min_perf,
+                           0 /* no des_perf in active mode */,
+                           max_perf, epp);
+    return 0;
+}
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
@@ -462,10 +571,27 @@ amd_cppc_cpufreq_driver =
     .exit   = amd_cppc_cpufreq_cpu_exit,
 };
 
+static const struct cpufreq_driver __initconst_cf_clobber
+amd_cppc_epp_driver =
+{
+    .name       = XEN_AMD_CPPC_EPP_DRIVER_NAME,
+    .verify     = amd_cppc_cpufreq_verify,
+    .setpolicy  = amd_cppc_epp_set_policy,
+    .init       = amd_cppc_epp_cpu_init,
+    .exit       = amd_cppc_cpufreq_cpu_exit,
+};
+
 int __init amd_cppc_register_driver(void)
 {
+    int ret;
+
     if ( !cpu_has_cppc )
         return -ENODEV;
 
-    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+    if ( opt_active_mode )
+        ret = cpufreq_register_driver(&amd_cppc_epp_driver);
+    else
+        ret = cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+
+    return ret;
 }
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 987c3b5929..e2cc9ff2af 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -250,6 +250,7 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
     data->min = policy->min;
     data->max = policy->max;
     data->limits = policy->limits;
+    data->policy = policy->policy;
     if (cpufreq_driver.setpolicy)
         return alternative_call(cpufreq_driver.setpolicy, data);
 
@@ -281,3 +282,17 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
 
     return __cpufreq_governor(data, CPUFREQ_GOV_LIMITS);
 }
+
+unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov)
+{
+    if ( !strncmp(gov->name, "performance", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_PERFORMANCE;
+
+    if ( !strncmp(gov->name, "powersave", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_POWERSAVE;
+
+    if ( !strncmp(gov->name, "ondemand", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_ONDEMAND;
+
+    return CPUFREQ_POLICY_UNKNOWN;
+}
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index baffb5bbe6..274b7ea06e 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -91,6 +91,7 @@ struct cpufreq_policy {
         struct amd_cppc_drv_data *amd_cppc; /* Driver data for AMD CPPC */
 #endif
     } u;
+    unsigned int        policy; /* CPUFREQ_POLICY_* */
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -141,6 +142,23 @@ 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
 
+/*
+ * Performance Policy
+ * If cpufreq_driver->target() exists, the ->governor decides what frequency
+ * within the limits is used. If cpufreq_driver->setpolicy() exists, these
+ * following policies are available:
+ * CPUFREQ_POLICY_PERFORMANCE represents maximum performance
+ * CPUFREQ_POLICY_POWERSAVE represents least power consumption
+ * CPUFREQ_POLICY_ONDEMAND represents no preference over performance or
+ * powersave
+ */
+#define CPUFREQ_POLICY_UNKNOWN      0
+#define CPUFREQ_POLICY_POWERSAVE    1
+#define CPUFREQ_POLICY_PERFORMANCE  2
+#define CPUFREQ_POLICY_ONDEMAND     3
+
+unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov);
+
 /* pass a target to the cpufreq driver */
 extern int __cpufreq_driver_target(struct cpufreq_policy *policy,
                                    unsigned int target_freq,
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index aa29a5401c..eb3a23b038 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -454,6 +454,7 @@ struct xen_set_cppc_para {
 };
 
 #define XEN_AMD_CPPC_DRIVER_NAME "amd-cppc"
+#define XEN_AMD_CPPC_EPP_DRIVER_NAME "amd-cppc-epp"
 #define XEN_HWP_DRIVER_NAME "hwp"
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:36:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:36:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109504.1459094 (Exim 4.92)
	(envelope-from )
	id 1uu3Zg-0003nr-Ia; Thu, 04 Sep 2025 06:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109504.1459094; Thu, 04 Sep 2025 06:36: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 1uu3Zg-0003nE-DI; Thu, 04 Sep 2025 06:36:00 +0000
Received: by outflank-mailman (input) for mailman id 1109504;
 Thu, 04 Sep 2025 06:35: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 1uu3Ze-0002iS-Hm
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:35:58 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2061e.outbound.protection.outlook.com
 [2a01:111:f403:240a::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6a4920a2-8959-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:35:57 +0200 (CEST)
Received: from BN0PR07CA0027.namprd07.prod.outlook.com (2603:10b6:408:141::29)
 by DM4PR12MB6183.namprd12.prod.outlook.com (2603:10b6:8:a7::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.25; Thu, 4 Sep
 2025 06:35:54 +0000
Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com
 (2603:10b6:408:141:cafe::32) by BN0PR07CA0027.outlook.office365.com
 (2603:10b6:408:141::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 06:35:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9115.0 via Frontend Transport; Thu, 4 Sep 2025 06:35:53 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:53 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:51 -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: 6a4920a2-8959-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hj4RWKAWvtO4/kWIrDa3eHDmvHOpCI8WvOL/Y4NwUFa2zlJcSLrrPuIu3MrLTR38xMAkO7sJQZpWtJBwOT6LAD785oblxSVjxnW77PSbwYP2ncxfvMOS55gzRKh2yevpA6R2FukUK+bJd8sdjZXAAmKcLsPBfgFFiGR3gAFGDEKCn/TWXnBo/SZM03OCqWq0G3naK9I92umQk8BdTSNaEIzhpO5BQtW4fALjwOFqcdps8g6aPSqCYUQMYsqlT3tA1TEZsL7eRJv+0TNOzh4QbZGRBLsmwo5uzDhxXe0Cxd3+ZNcKaT+jz27+5jyMfMRSWj+T756wqm+bPATbk1nOaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vTgoPQGZ52lYoy0+t7eUH+ZhoylKKzVdc6YoX7igME0=;
 b=BJLbm2UqMvjA4+JH4xMyAXwwVgvbFSQJuhZ/92cXFGrY9TCno69EKxDD3WiPgaxqJJ7lU1kBesoUnZBoCaKJl+unuXMYa0V81PlPpa3zafMkcW7eqKIlJpEvYXXBF9Zu2Ul/8UrAOt1jFPofR2LxVFAlgUlHt/gfJBpKQDG+yVDqKKgjpfxZb6IoZ5NU+2Kh6ja/vz4vVx4QpU1k5yyBYCbpjobg6z6mculbXuKtz/o4mjnRNQvyHypeVRl36imK6KavHCJcrW+/7cxz+clWEGP7ps234kEA/9nx/QdOPHGOpTMkhs5bQ4LEEU1/IG/XoaAEB1A1zzK8SD4Ko6G0gA==
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=vTgoPQGZ52lYoy0+t7eUH+ZhoylKKzVdc6YoX7igME0=;
 b=NuKy0jpENyGLRvTgOuSZsoLFM60NnPLjsEievwPDE57MNPTJLg+n3GX0MeU8WcOvwv6PGI6nh4LlhRKXZfyurKzdOTWqx/DQd0ou9VadpVP6RMIYIs2HajbRbqXvNdlzPaiut+4AYSoWTOsm8Pet2K5fyAO8a/x/z7gvdrJXIy0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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 , Anthony PERARD
	, Jan Beulich 
Subject: [PATCH v9 6/8] xen/cpufreq: bypass governor-related para for amd-cppc-epp
Date: Thu, 4 Sep 2025 14:35:16 +0800
Message-ID: <20250904063518.2097629-7-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|DM4PR12MB6183:EE_
X-MS-Office365-Filtering-Correlation-Id: bba50187-47f0-4154-8665-08ddeb7d4c4b
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?7Z2wdmxPUzd2E0xrLfhX1ygA+TW4/nOPwSba+03AWSd1X5SqU7eAJLLmDkRx?=
 =?us-ascii?Q?0mM7gvSy3h4gkeKq4f8qUSI8UWsn25wg1QyKP/F+8xr62T+fUAUrkpDPO/Ow?=
 =?us-ascii?Q?V1expMhOAjVhFHIyeSLEnMyvz6Bdoj8g4gxpy8XwmrZXMBCEyGV5gzN6Wq68?=
 =?us-ascii?Q?R5wpKpBy8bTJN6FepFFInsJGIDfpDEEqMnSU6dpKe6h27Su8FYalwKS5ngjW?=
 =?us-ascii?Q?cYQLY7mjAl5K/qZpvKmwdXTXUIW0yTuft/3YfD11mJAQ5ILmzTdeUixLgd+7?=
 =?us-ascii?Q?S4/1sgqQS/pGPNiybQHGykHtY3i3WfFnNWjPNAO7Vk0A+YkKRqJ2j1YGthXf?=
 =?us-ascii?Q?VIrlSh9Lj5QRp3D/8s7qFvBfR7w6syGDwwY2PidtlET1I0ERSgGvTNN7a+7s?=
 =?us-ascii?Q?RXZ9OtEtJjuKcw2p1g3KWdT4I4cAmtjSXPl4TASCD18bCzN3oqMdGhEfoBbJ?=
 =?us-ascii?Q?5rmIVBXpzOG+e93T84sIPF0eFTt5Rc7mfLzisBL5yS76HeS3lW6z5ItudrOI?=
 =?us-ascii?Q?CZXoPo4374oUhOQ9Q59W4Dzu4XT8LZkoLaYUa0PBtSN0ZmcIRqwv23RowDwT?=
 =?us-ascii?Q?oDRpSFaAcqoHjgKQ4FPc/t5YfY7v1rr/PJQhf55021U8CTgbMNKaCZ0MpyHe?=
 =?us-ascii?Q?ShgXvQC2cwETSfJCMr/3tnNNsXOcdYPU4qTqpDtJF2wD5Q7YTazsFC9mezbh?=
 =?us-ascii?Q?9a9/FY30BqA7LiKPWOeYD5UueL302vImjsiMLYuz+nNlGkpiK4xsn3R+sesG?=
 =?us-ascii?Q?Nd+qnZSkri/tl2pnaGwQ1KVLfovGI+KtblTcv1VAWXYusSb3AhfgqrdTQ7bm?=
 =?us-ascii?Q?a2Y705sFd3YY2DMphbL1PPrvBEYgNR7BtMrIME/KAboeiQ8Q77PdWGcaKAFH?=
 =?us-ascii?Q?P8yPdAbodze4fVWwg87ZigN8S2yD8V6yzs492vV4/5q+wXjxt4CN9fBeJ+l0?=
 =?us-ascii?Q?KGQHzxIicvxt78W76mt0PSu/LECRZhdVdLOeAqNLvYFJh8cRLfvQ6bGHXD7h?=
 =?us-ascii?Q?cxTxv/HdNhTNa7WVaID6hhFOfucdvI/OfhfkAmnvQRYH6lvrxam+LIN+pQsx?=
 =?us-ascii?Q?wCradQEvAoDWPIAiSon3tA1kFTIw5vHpcKSHjnFqb4OURNv8YfX7qoZpvrLF?=
 =?us-ascii?Q?3QuYN/PDVa1UObZjZW1BzbuD7JXvpIewhJyRpqbN8XK3RjGOLGmz/yqxPZ3/?=
 =?us-ascii?Q?QyjgfHv8pGjulB4vsKl8ylGz7bCTQQmWbqookzaDUhCeseAZnYtMCq9FWOeG?=
 =?us-ascii?Q?BQJF2bV5zUiYh75dicuEU1tOwMSKKWdg5L4iU+CqLQdYRp9IpCWd5wVFCG6M?=
 =?us-ascii?Q?3oF+mVfJs/DW8kVU+7x2xN58olk1yC9yIGYyAslf8UsueMa8S+f4igHbUCec?=
 =?us-ascii?Q?E6PUm3NVY6EQjKnNdz7O3C64tUu8jerqxuQgelcydmnwWbdOC+699ECWmGlw?=
 =?us-ascii?Q?A9i06g/VGA0+stUgjZH4WJbrDyYsrxYxtQRwYt1l7A1LmCOMWmHAg+qDHlJN?=
 =?us-ascii?Q?k0fZaaAc2mcky5TGCVNLt5YpqonCPkqxom00?=
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: 04 Sep 2025 06:35:53.9512
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bba50187-47f0-4154-8665-08ddeb7d4c4b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06C.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6183

HWP and amd-cppc-epp are both governor-less driver, so we introduce
"is_governor_less" flag and cpufreq_is_governorless() to help bypass
governor-related info on dealing with cpufreq para.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
Acked-by: Anthony PERARD 
---
v3 -> v4:
- Include validation check fix here
---
v4 -> v5:
- validation check has beem moved to where XEN_PROCESSOR_PM_CPPC and
XEN_CPPC_INIT have been firstly introduced
- adding "cpufreq_driver.setpolicy == NULL" check to exclude governor-related
para for amd-cppc-epp driver in get/set_cpufreq_para()
---
v5 -> v6:
- add helper cpufreq_is_governorless() to tell whether cpufreq driver is
governor-less
---
v6 -> v7:
- change "hw_auto" to "is_goverless"
- complement comment
- wrap around with PM_OP to avoid violating Misra rule 2.1
---
v7 -> v8:
- change "is_goverless" to "is_governor_less"
- make cpufreq_is_governorless() inline function
---
 tools/misc/xenpm.c                 | 10 +++++++---
 xen/drivers/acpi/pm-op.c           |  4 ++--
 xen/include/acpi/cpufreq/cpufreq.h | 12 ++++++++++++
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index e83dd0d80c..893a0afe11 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -832,9 +832,13 @@ static void print_cppc_para(unsigned int cpuid,
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
-    bool hwp = strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) == 0;
+    bool is_governor_less = false;
     int i;
 
+    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
+         !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+        is_governor_less = true;
+
     printf("cpu id               : %d\n", cpuid);
 
     printf("affected_cpus        :");
@@ -842,7 +846,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
         printf(" %d", p_cpufreq->affected_cpus[i]);
     printf("\n");
 
-    if ( hwp )
+    if ( is_governor_less )
         printf("cpuinfo frequency    : base [%"PRIu32"] max [%"PRIu32"]\n",
                p_cpufreq->cpuinfo_min_freq,
                p_cpufreq->cpuinfo_max_freq);
@@ -854,7 +858,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 
     printf("scaling_driver       : %s\n", p_cpufreq->scaling_driver);
 
-    if ( !hwp )
+    if ( !is_governor_less )
     {
         if ( p_cpufreq->gov_num )
             printf("scaling_avail_gov    : %s\n",
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index 19aedf6b0b..371deaf678 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -154,7 +154,7 @@ 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() )
+    if ( !cpufreq_is_governorless(op->cpuid) )
     {
         if ( !(scaling_available_governors =
                xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
@@ -240,7 +240,7 @@ static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
     if ( !policy || !policy->governor )
         return -EINVAL;
 
-    if ( hwp_active() )
+    if ( cpufreq_is_governorless(op->cpuid) )
         return -EOPNOTSUPP;
 
     switch( op->u.set_para.ctrl_type )
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 274b7ea06e..85fbf772a0 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -304,4 +304,16 @@ int acpi_cpufreq_register(void);
 int amd_cppc_cmdline_parse(const char *s, const char *e);
 int amd_cppc_register_driver(void);
 
+/*
+ * Governor-less cpufreq driver indicates the driver doesn't rely on Xen
+ * governor to do performance tuning, mostly it has hardware built-in
+ * algorithm to calculate runtime workload and adjust cores frequency
+ * automatically, like Intel HWP, or CPPC in AMD.
+ */
+static inline bool cpufreq_is_governorless(unsigned int cpuid)
+{
+    return processor_pminfo[cpuid]->init && (hwp_active() ||
+                                             cpufreq_driver.setpolicy);
+}
+
 #endif /* __XEN_CPUFREQ_PM_H__ */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:36:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109507.1459109 (Exim 4.92)
	(envelope-from )
	id 1uu3Zk-0004L2-3z; Thu, 04 Sep 2025 06:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109507.1459109; Thu, 04 Sep 2025 06:36: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 1uu3Zk-0004Kr-0I; Thu, 04 Sep 2025 06:36:04 +0000
Received: by outflank-mailman (input) for mailman id 1109507;
 Thu, 04 Sep 2025 06:36: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 1uu3Zi-0002id-Nv
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:36:02 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20617.outbound.protection.outlook.com
 [2a01:111:f403:2413::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b5a9337-8959-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 08:36:00 +0200 (CEST)
Received: from MN0PR02CA0021.namprd02.prod.outlook.com (2603:10b6:208:530::23)
 by MN6PR12MB8490.namprd12.prod.outlook.com (2603:10b6:208:470::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 06:35:54 +0000
Received: from MN1PEPF0000F0E5.namprd04.prod.outlook.com
 (2603:10b6:208:530:cafe::17) by MN0PR02CA0021.outlook.office365.com
 (2603:10b6:208:530::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9052.28 via Frontend Transport; Thu,
 4 Sep 2025 06:35:54 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 MN1PEPF0000F0E5.mail.protection.outlook.com (10.167.242.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9094.14 via Frontend Transport; Thu, 4 Sep 2025 06:35:54 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:52 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:48 -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: 6b5a9337-8959-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QJuN5vRu+UbjEdaXdKl0ZIUZjBbe8UWisbHnVxdqhdZYPeEATbVbRJnBjRaMgZmSFBR5xtdPFUI/kpCxCBbOKcJkx6yyQ71z/6bzL3/ZdlMw51KosGFXkUqlkpO3MZ8OwxZ7FU1oHROvKLNxavyWSaGk1NdMA7LsYAcKnUnoxfy/Z5BW9Q1USvpP0HvoojQwMq/CNB2VjLgWJ/z03z9arLkBByvlp6p0VG5+wviTV4BbXkQfms+r4si/qo2edg8NFrHOmy7axuCbtP4UB4M6e4ai+4MI+DMmNID3kYC9CdazrfesoWNCad0Ea2DsaMDOvHcZ+q4uhTkudTzmdmWlTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Toe6Isc8jD267iNGh3XLoNGxPPh/1SU1rDpbA94F4Os=;
 b=S1URRXxdFiDaLuqRtX+/x8Zf44tqbeSp5FTYKOG9ia8bbP3KINeMc3QaGfy5xaaEoa3cUoa7L0Hy1BqycCqjiCRHaAuzSleP+YJi+0FIl4vXhM7xkCR7sS1mnRbJEre5jjMKnRoA1b0FHbPXuifmqCFmxbVU50sNfEB1FtEBRyJr+BG6CEUpR4mNejnGoSQJFi+J3um07Y5zqxmBUshaHpKZMVHCMIRqv0TsFjQ5Lblm0zHpFRY2SgffqWRhKr7hWb4TcvkvKuUuV65K1+aSiPBejOPX5cSdjgEZWWlG+hE8tTh3KANnTOcO66o8LA+e9sncLSaVQ9Jkx7Mgi2btlg==
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=Toe6Isc8jD267iNGh3XLoNGxPPh/1SU1rDpbA94F4Os=;
 b=orsWwYkqkpywO4THZICY+z/uvYGcl3m+sq76ZmF1Wy+1QjBhAX8Rs7LByM79SqLFiJySaEz+/aOo1dhdhlQrstCm/wD/AuOay46ZuEwrxP+NI0CfjJ0EcavnZIMy8G/znwLUNqAGOi6sMsXsf8z1U2SGlZY9blGsvNgWSUnGIts=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: Penny Zheng 
To: 
CC: Penny Zheng , Anthony PERARD
	, Juergen Gross , Andrew Cooper
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH v9 5/8] tools/cpufreq: extract CPPC para from cpufreq para
Date: Thu, 4 Sep 2025 14:35:15 +0800
Message-ID: <20250904063518.2097629-6-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E5:EE_|MN6PR12MB8490:EE_
X-MS-Office365-Filtering-Correlation-Id: 040bf4e4-cb5d-4f0b-f403-08ddeb7d4c5c
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?KhpjyCZM8vgSfSZjB+0jQIUmGOQoBNhOUu+opGDjHCnWAtrCUVInIpsqsQlx?=
 =?us-ascii?Q?952YsMlY1BDCUvKs7JppGchOEfKiDL1wc/kxORD27kWMCbUda19JW2S4t/Xv?=
 =?us-ascii?Q?zNl8uFYY2XlA7iAw0lqnsvvURJmtQmorXeLMb980VNIhe57QDOoLuSX5+5xZ?=
 =?us-ascii?Q?VDjPVnCKDlCUt2mQfncKDQy5+3EHHSGpIgfKK5Jx85JN/EWgTNDgGoc4oJ73?=
 =?us-ascii?Q?DQfjVoOzrc3ENDvoRuTTE9RFH0kbpp1M7fsiKYZjt4Z4Flh8fTqVAcMZkitl?=
 =?us-ascii?Q?FFz44rdDydqoP5kvonfOh/TYe6DMG3gLuRA8iWUhtK9Mm+Q0yL20HeyjF+OA?=
 =?us-ascii?Q?uZqZFJ4JPY5MEUk9XpQB8yOrFH1NmDn7BajAd+JQYrnTkYbxVnYZu8ZQfidp?=
 =?us-ascii?Q?J6at9cPWTb4sQSrecNibDwNWbGJ9Qmk56cYOT3bbtku774e0D8DZ9m3HAphF?=
 =?us-ascii?Q?Q8czyhKkPKy1CuCCW5MbMZ4eb9ZjltuS3VY63TKQrwSWh9lVa8W6hYwKhwOt?=
 =?us-ascii?Q?QkrX6NVHTTNIMF/uvgQBJzqhLLh9+fJda9uJkSq2tG00MviUFES7D2hLGdcN?=
 =?us-ascii?Q?2JKuC5y+GCl11zFj/6Y5fg7afolIMtdQexRgER4l1Zz775SMUK2ee4SCQLXB?=
 =?us-ascii?Q?1NxfFSnhfGRv2diGfNaAqCYiG5r3TDmZTAqnA5rRVaKh0RfBkEXKvADAC7n1?=
 =?us-ascii?Q?mfyrRAS0c92m0P4z9vPe8LHJPypGHTrG2hLRCT0ERVp1csQg6STBTQAVVjbr?=
 =?us-ascii?Q?oRwI/k4CJU1ivsEgTYAADh/mYNjUHcNy4ZiwFqRP6eePf8cbiWCsTRO3ATGX?=
 =?us-ascii?Q?scGmpjjQG2Jwr0YfYts4B8JfdwkOk+kZKkmv4/A+N0KJ1699RIq2lOdUy7ID?=
 =?us-ascii?Q?bDiuiKpSWqWmgR8PaDL8mfjsGg33lcogULrpADgVMNzCTcGNSO7nTsKDQ1Hh?=
 =?us-ascii?Q?sJEA6hXhH6DKJhYhdi1sa4wfW7p/EVyiZJwT17xZ1+MOcxJzxbiPU9Op17h/?=
 =?us-ascii?Q?dWEZRnKYKo3R/Av8i7JIYPqa8nVXDHLC6/x1onG5iDrFceYbyHqvEaIWgaUx?=
 =?us-ascii?Q?3fBmn8sLjKu+6Ax8SU/nL5/msK7WMLxIRxPZTYDEdeGdq2oZhe8lbXvvTR1i?=
 =?us-ascii?Q?FmtRdce1yfAIeG+31MgTT5rqNB53DeyKf16zc6NSUr9ouHDNdhMZAmpcqsaS?=
 =?us-ascii?Q?1PgX6HR8D1/pmM6Il9Yt4RJ7/hgu0oBUFojJIWHdi/+WxTOI1bZjH7CGSuXE?=
 =?us-ascii?Q?rYtz2+FBX3esJ7F31KUv5neNpwFStSZO7lrJjhlIAJ0TRUWPu9rMAAZcEc5P?=
 =?us-ascii?Q?L/aU041RgyS+IdsB80GlnTqsVIP1EuKDHLU/C5dlvbfo0f2osHScBE2llEDC?=
 =?us-ascii?Q?o6iFhiNGk8WeRdNjw9xLknZhA5iznmjAHqWKhVEzKVZvahqfnJ1yTOW/XDnm?=
 =?us-ascii?Q?6nuAG6LqOhYjo5n4GOvuxsQ+lc4kTh5ZdnaH9QuXHuQLzq+tkG/lo22fK7BL?=
 =?us-ascii?Q?MiALowmKwJYtyLc2g8mxcZdN4EIEouWoVXfs?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 06:35:54.0633
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 040bf4e4-cb5d-4f0b-f403-08ddeb7d4c5c
X-MS-Exchange-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:
	MN1PEPF0000F0E5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8490

We extract cppc info from "struct xen_get_cpufreq_para", where it acts as
a member of union, and share the space with governor info.
However, it may fail in amd-cppc passive mode, in which governor info and
CPPC info could co-exist, and both need to be printed together via xenpm tool.
If we tried to still put it in "struct xen_get_cpufreq_para" (e.g. just move
out of union), "struct xen_get_cpufreq_para" will enlarge too much to further
make xen_sysctl.u exceed 128 bytes.

So we introduce a new sub-field GET_CPUFREQ_CPPC to dedicatedly acquire
CPPC-related para, and make get-cpufreq-para invoke GET_CPUFREQ_CPPC
if available.
New helpers print_cppc_para() and get_cpufreq_cppc() are introduced to
extract CPPC-related parameters process from cpufreq para.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich  # hypervisor
Acked-by: Anthony PERARD 
---
v4 -> v5:
- new commit
---
v5 -> v6:
- remove the changes for get-cpufreq-para
---
v6 -> v7:
- make get-cpufreq-para invoke GET_CPUFREQ_CPPC
---
v7 -> v8:
- use structure assignment as it is a alias
- add errno info to the error print
---
 tools/include/xenctrl.h     |  3 +-
 tools/libs/ctrl/xc_pm.c     | 25 +++++++++++-
 tools/misc/xenpm.c          | 79 ++++++++++++++++++++++++-------------
 xen/drivers/acpi/pm-op.c    | 19 +++++++--
 xen/include/public/sysctl.h |  3 +-
 5 files changed, 96 insertions(+), 33 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 965d3b585a..e5103453a9 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1938,7 +1938,6 @@ struct xc_get_cpufreq_para {
                 xc_ondemand_t ondemand;
             } u;
         } s;
-        xc_cppc_para_t cppc_para;
     } u;
 
     int32_t turbo_enabled;
@@ -1953,6 +1952,8 @@ int xc_set_cpufreq_para(xc_interface *xch, int cpuid,
                         int ctrl_type, int ctrl_value);
 int xc_set_cpufreq_cppc(xc_interface *xch, int cpuid,
                         xc_set_cppc_para_t *set_cppc);
+int xc_get_cppc_para(xc_interface *xch, unsigned int cpuid,
+                     xc_cppc_para_t *cppc_para);
 int xc_get_cpufreq_avgfreq(xc_interface *xch, int cpuid, int *avg_freq);
 
 int xc_set_sched_opt_smt(xc_interface *xch, uint32_t value);
diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
index 6fda973f1f..56e213018a 100644
--- a/tools/libs/ctrl/xc_pm.c
+++ b/tools/libs/ctrl/xc_pm.c
@@ -288,7 +288,6 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
         CHK_FIELD(s.scaling_min_freq);
         CHK_FIELD(s.u.userspace);
         CHK_FIELD(s.u.ondemand);
-        CHK_FIELD(cppc_para);
 
 #undef CHK_FIELD
 
@@ -366,6 +365,30 @@ int xc_set_cpufreq_cppc(xc_interface *xch, int cpuid,
     return ret;
 }
 
+int xc_get_cppc_para(xc_interface *xch, unsigned int cpuid,
+                     xc_cppc_para_t *cppc_para)
+{
+    int ret;
+    struct xen_sysctl sysctl = {};
+
+    if ( !xch  || !cppc_para )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_pm_op;
+    sysctl.u.pm_op.cmd = GET_CPUFREQ_CPPC;
+    sysctl.u.pm_op.cpuid = cpuid;
+
+    ret = xc_sysctl(xch, &sysctl);
+    if ( ret )
+        return ret;
+
+    *cppc_para = sysctl.u.pm_op.u.get_cppc;
+    return ret;
+}
+
 int xc_get_cpufreq_avgfreq(xc_interface *xch, int cpuid, int *avg_freq)
 {
     int ret = 0;
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 6b054b10a4..e83dd0d80c 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -801,6 +801,34 @@ static unsigned int calculate_activity_window(const xc_cppc_para_t *cppc,
     return mantissa * multiplier;
 }
 
+/* print out parameters about cpu cppc */
+static void print_cppc_para(unsigned int cpuid,
+                            const xc_cppc_para_t *cppc)
+{
+    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");
+    printf("\n");
+}
+
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
@@ -826,33 +854,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",
@@ -898,6 +900,24 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
     printf("\n");
 }
 
+/* show cpu cppc parameters information on CPU cpuid */
+static int show_cppc_para_by_cpuid(xc_interface *xc_handle, unsigned int cpuid)
+{
+    int ret;
+    xc_cppc_para_t cppc_para;
+
+    ret = xc_get_cppc_para(xc_handle, cpuid, &cppc_para);
+    if ( !ret )
+        print_cppc_para(cpuid, &cppc_para);
+    else if ( errno == ENODEV )
+        ret = 0; /* Ignore unsupported platform */
+    else
+        fprintf(stderr, "[CPU%u] failed to get cppc parameter: %s\n",
+                cpuid, strerror(errno));
+
+    return ret;
+}
+
 /* show cpu frequency parameters information on CPU cpuid */
 static int show_cpufreq_para_by_cpuid(xc_interface *xc_handle, int cpuid)
 {
@@ -957,7 +977,12 @@ static int show_cpufreq_para_by_cpuid(xc_interface *xc_handle, int cpuid)
     } while ( ret && errno == EAGAIN );
 
     if ( ret == 0 )
+    {
         print_cpufreq_para(cpuid, p_cpufreq);
+
+        /* Show CPPC parameters if available */
+        ret = show_cppc_para_by_cpuid(xc_handle, cpuid);
+    }
     else if ( errno == ENODEV )
     {
         ret = -ENODEV;
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index a7eaf29c31..19aedf6b0b 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -77,6 +77,17 @@ static int read_scaling_available_governors(char *scaling_available_governors,
     return 0;
 }
 
+static int get_cpufreq_cppc(unsigned int cpu,
+                            struct xen_get_cppc_para *cppc_para)
+{
+    int ret = -ENODEV;
+
+    if ( hwp_active() )
+        ret = get_hwp_para(cpu, cppc_para);
+
+    return ret;
+}
+
 static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
 {
     uint32_t ret = 0;
@@ -143,9 +154,7 @@ 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() )
-        ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
-    else
+    if ( !hwp_active() )
     {
         if ( !(scaling_available_governors =
                xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
@@ -385,6 +394,10 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         ret = set_cpufreq_para(op);
         break;
 
+    case GET_CPUFREQ_CPPC:
+        ret = get_cpufreq_cppc(op->cpuid, &op->u.get_cppc);
+        break;
+
     case SET_CPUFREQ_CPPC:
         ret = set_cpufreq_cppc(op);
         break;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index eb3a23b038..3f654f98ab 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -492,7 +492,6 @@ struct xen_get_cpufreq_para {
                 struct  xen_ondemand ondemand;
             } u;
         } s;
-        struct xen_get_cppc_para cppc_para;
     } u;
 
     int32_t turbo_enabled;
@@ -523,6 +522,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
@@ -547,6 +547,7 @@ struct xen_sysctl_pm_op {
     uint32_t cpuid;
     union {
         struct xen_get_cpufreq_para get_para;
+        struct xen_get_cppc_para    get_cppc;
         struct xen_set_cpufreq_gov  set_gov;
         struct xen_set_cpufreq_para set_para;
         struct xen_set_cppc_para    set_cppc;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:40:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:40:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109554.1459119 (Exim 4.92)
	(envelope-from )
	id 1uu3eI-0007bp-Tp; Thu, 04 Sep 2025 06:40:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109554.1459119; Thu, 04 Sep 2025 06:40:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu3eI-0007bc-RC; Thu, 04 Sep 2025 06:40:46 +0000
Received: by outflank-mailman (input) for mailman id 1109554;
 Thu, 04 Sep 2025 06:40: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 1uu3Zl-0002iS-Df
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:36:05 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2414::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e6a943c-8959-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:36:04 +0200 (CEST)
Received: from BN0PR04CA0141.namprd04.prod.outlook.com (2603:10b6:408:ed::26)
 by LV8PR12MB9641.namprd12.prod.outlook.com (2603:10b6:408:295::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 06:36:00 +0000
Received: from BN3PEPF0000B070.namprd21.prod.outlook.com
 (2603:10b6:408:ed:cafe::6b) by BN0PR04CA0141.outlook.office365.com
 (2603:10b6:408:ed::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 06:36:00 +0000
Received: from SATLEXMB04.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.9115.0 via Frontend Transport; Thu, 4 Sep 2025 06:35:59 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:57 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:55 -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: 6e6a943c-8959-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I6jc/6hVx1FPDkJoY1aurwK256xeTZdKxkGStIFfP3b0OT9WTBChYd+r1/LbXC5YNkStSbk6gwh99CArD7DuOwnJAOGXzrA4/tPtIUYG4YJrUWzcij6lH8qqpMaE+h+JcfOZtDCE7GVjga88mB4eCSpOmSipXlvHnI+s4ErvoOxI+coMWUVDf1y8n1YrgB0Tgs3SV3iTTIFuGPbxa8HnmmEsJQsADgBT/ARwqYuwkwFqHgzUMlRyLffIUOtXSNounMEyk8FrocJAh8M0sfBGhvm2acBagBWH4FkNuLCFkIwnx4/KkMlQiIAhfjpuan7S1nkpy+o77ENErIKouKB3aw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1Cm8DWA4z57MSB+CARUOHbMjYe/yew/NRXMVbVkbi0A=;
 b=AkijPjEMAHVsXXdCF9nVjI/gYxn1x2xswqPviJT8MUtnIEhW7D6Jf4O6jGlAyWi+RyG4tSsJcigtMZNeobsv+FeE5Yj64ftbq8t8QHCfhebRSnB+N4mjPYAmpvqLVjlGTlz9ExsRlW5QZJuTVYhWLypNn+YRnOIo/7Yb0YyndIeD9gbotJn8+bpasbhKXXklJjESUrorJINfHPZAFtLLQ4VMuPwH/nUGLJ8pvIoj9cZ5liFnVmkuypC2s9FHU6n/AO2/7cdmPEkwNLKowD0hpduCCBngv7Y+KktMEfG/+F7P2dLJiJ9bgoV+ZqTDb458wP7a5ayX3M8qoZ2RAKIi0w==
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=1Cm8DWA4z57MSB+CARUOHbMjYe/yew/NRXMVbVkbi0A=;
 b=sBzbug5VCeqLjbRMZg/xLwdSK2WBLJejdmdT4Wdyj1qPq+RDLPZBm0xKhZS/v1Vbdw5r8HoQUng8mfqJ+BNQhgO0R8jcolr6M4nf0fxHzFIBHSMTTLPRzjHRLdnpNYEpUmeBVxRdvp/SBFRfRxrqqvbIsZ2oD2K9z0jaKAiqaYE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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 , Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v9 8/8] CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq driver support
Date: Thu, 4 Sep 2025 14:35:18 +0800
Message-ID: <20250904063518.2097629-9-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B070:EE_|LV8PR12MB9641:EE_
X-MS-Office365-Filtering-Correlation-Id: 1a07aca0-e458-4ae9-2846-08ddeb7d4fc1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?qrp0oIrJ3VvCFfMe9aD0zepS6tx6Kt+oNbfh9a+O/cySg00J5Bh6e4OwRX0d?=
 =?us-ascii?Q?rxUMWPGcJbAu55sc+rjOS+CioJXKvQIqb7DdSROvomXhtvz8Ip/MbRE3yT0g?=
 =?us-ascii?Q?5d46/sJ7Iga1LCMfxXRG4hci1diH5BzDmEa3spt78z8Jz81NP19EsUEfeRyx?=
 =?us-ascii?Q?PCjqXONn2kI1lC+nxJqYJOCRg0f6g34wpkSjjW5qlo9pqfdPKy7d0UkphSeX?=
 =?us-ascii?Q?ZCYyJ3AB6WrmxhEUbJFvQL3MArv0zi06A6rZ5N66ePzoVfa+G/sdUpKn8q7V?=
 =?us-ascii?Q?PVGH3b1/4XODDrtsTUT0MEgKadQ1TiwPMcAl6xubVn1jR4GGg4rwa1TnGmXW?=
 =?us-ascii?Q?EUnWjkFSE7ywQPvlohuJvP0w5G7xA2c89E59z5MVtQomNYe8loHGpn4wfuGQ?=
 =?us-ascii?Q?lB5CMMah8EUjKMHY8Ed3thfDzHeRBCerhB0Mgmpq31Jpa6rSKSemz0CNPXBw?=
 =?us-ascii?Q?CEj0NKOnpaY2QbqNfpN9Z2EqMjV7OHw+Ys9IWxFR8MKZSUV04G3LlMaKczQ+?=
 =?us-ascii?Q?az1zPBx6GxXPSbd2e7PgS9SkAa0lPhSEk99ci7E+TPkEjSoyzhxkZ5ceRTQ/?=
 =?us-ascii?Q?292b0CYFoHQ6FDhY6okReT7TI75atSUYTCZ8lBs0fi1RhUhCoGjUC2plvRrC?=
 =?us-ascii?Q?4j4f3n6339U+nH5VsvefDeqKETTiYAztaEy1VBEbspHSjHjukqWR1SMA3yL9?=
 =?us-ascii?Q?Tp/Dgx1Bd+VFEPF5P689rEbQTCSsSmQ56iv69wGXlpOh3lGn/TmyuvesXKHD?=
 =?us-ascii?Q?nziW36SFZfi0rqLtUxLJNrrnRx3dn4Xb4BslgwLYp+K9+RYg7t+ysKPy+YF+?=
 =?us-ascii?Q?7pS4Fvek48U9YY0JR5qXMe1XERl7wSB5r+HlMcwVeO/9NPLil1AlzK2yvZ1O?=
 =?us-ascii?Q?+ij/OUe9SDbmuAvmBy568rHS0w0OrASHdLPcORFVifIOOoJXvn36RknZmVqu?=
 =?us-ascii?Q?5BVhti1Sslsx1VNNJFhi3w/ZsTpUGdNKISJy62JuqOqTwWUSdR69nDrd95TT?=
 =?us-ascii?Q?iB1P6RkgYbKRlErl5/ESwERIYD4t60zLJ0sIamyNlQHZfKr1Sqy9T1twtLkL?=
 =?us-ascii?Q?ADmMK055Bm0ABls2wk4weWNMUfDMo8NoHfuiLgNVnDB0ksO8w6VuwA3EFa4j?=
 =?us-ascii?Q?m75EiSgqXlDuLVyctg5CyfIksLPcBs5vU529d+asLaqUAsVxcKilWApgDiAt?=
 =?us-ascii?Q?S3Nh/FloHEa7D71QomnLDxCYmn3BjxGjYQ+8+eVL0whjaZS3N5vCjN8TetEV?=
 =?us-ascii?Q?hBt1DwxhD9Kibo3TKDiKuhxksaZlhkq0KynnUp4qn+ITwRIspTD/3PTv33Ev?=
 =?us-ascii?Q?pjVNGlf9RxtNohfgT++LMgNLL164p6n7xV0ktkUlENebLBa8Ts97FP7XlPDQ?=
 =?us-ascii?Q?QAR/3XqRBhvCklhiLv40+awoJiQFqOncczLVE/my9qeKSmu++4mBKNM9CV9f?=
 =?us-ascii?Q?12gePKhgtAfLVZIrjFpAdjYNxnJMlILqRXElT8fIeHo8rKEbKNMrZA=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 06:35:59.7532
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a07aca0-e458-4ae9-2846-08ddeb7d4fc1
X-MS-Exchange-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:
	BN3PEPF0000B070.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9641

Signed-off-by: Penny Zheng 
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index cd34ea87b8..c1a57924f3 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -33,6 +33,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
      Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
      and 28 (Temperature Probe).
+   - Support amd-cppc/amd-cppc-epp cpufreq driver
 
  - On Arm:
     - Ability to enable stack protector
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:41:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:41:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109583.1459129 (Exim 4.92)
	(envelope-from )
	id 1uu3eZ-00085U-6L; Thu, 04 Sep 2025 06:41:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109583.1459129; Thu, 04 Sep 2025 06: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 1uu3eZ-00085I-2o; Thu, 04 Sep 2025 06:41:03 +0000
Received: by outflank-mailman (input) for mailman id 1109583;
 Thu, 04 Sep 2025 06: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 1uu3Zl-0002iS-QT
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:36:05 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:200a::617])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6dd60877-8959-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:36:04 +0200 (CEST)
Received: from BL1PR13CA0114.namprd13.prod.outlook.com (2603:10b6:208:2b9::29)
 by MW5PR12MB5681.namprd12.prod.outlook.com (2603:10b6:303:19e::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 06:35:57 +0000
Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com
 (2603:10b6:208:2b9:cafe::ed) by BL1PR13CA0114.outlook.office365.com
 (2603:10b6:208:2b9::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.7 via Frontend Transport; Thu, 4
 Sep 2025 06:35:56 +0000
Received: from SATLEXMB03.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.9094.14 via Frontend Transport; Thu, 4 Sep 2025 06:35:55 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) 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, 4 Sep
 2025 01:35:55 -0500
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.2.1748.10; Wed, 3 Sep 2025 23:35:53 -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: 6dd60877-8959-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=E8ERicDMXk7esAREKpeSJ/clyod6mKBH6Sbeu1VSRskNSBjvui1IM1Ik9xQYOxrSMiGpR6rakQdljn8/U7DBWiJBhn6hAJCkiYcH0bH7imDQSvMhY0OaNAi4rhyF6CaHytbsxESqWjt9nC2c5E0yfuOE/lbzVHvZ+9A5iojT9xef+Olnz1nUiy9WPrZOdSvKQr+PBTv+T00gOUK2oVtEaAPxj/xhvaYZ9NWklbpUzgybIfLhE0j3JAanMZFMn+KEIlfAdL9ubvfY9/9deAGbQ9jtJrHXXxLu0bMBhu3keCw8M0yepgqNQHDdg4qjaaVNKMdIHMbL/tUQxk+K3LYiWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CdIK13lLqQxTnVxJzwlBzN2oYXCoef6BWaKaomLNwtc=;
 b=ZT4Uao6HPilvedWUd9MhDz5P3PUVifwDlTJorhEMHsvD5qE61tz0KKIEgESTDqEk6GUac92Mxjv/aQoRTt7b9TaPVo7KXcyDSCKvx+PT4lR4y01Sn+wLRy6+ID7q3J3SF4saIAAj7CroOuTmC0JPtETVgEd9gpn/eJ0yY2r2wq+91uJRkZJE2P22R7P6Z5nub+40hcCuE8Bjfot+9QSrQexYWAI6YGAxYMWcrMnhZL3Mk3CF6+6LyBlC055Lj5oSzOLJlWmbSgHKLwljMWIKNUfx0mHm/gmK9YPedUv+SfFNaeeMFKfNwHcn0HwuCEvBx3ewBB6BnPyxYxSZFM9Tsg==
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=CdIK13lLqQxTnVxJzwlBzN2oYXCoef6BWaKaomLNwtc=;
 b=lWC4B05T5fUHMN2WPOtI8yec8CXWu0fdymvFrhxiW6jl1nl5ZGDGqrEGfDeeQLgNiE9akzMnobhR9DY+5H4uj66sWdSK0fEhHU6O5Ch5WJECDnyPg/vPNK/wzXZtMcWju5mxX32V0ruCHRdSbbc7nPOW1GDkW6suQ7F9ny/Mp7E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: Penny Zheng 
To: 
CC: Penny Zheng , Anthony PERARD
	, Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	
Subject: [PATCH v9 7/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver
Date: Thu, 4 Sep 2025 14:35:17 +0800
Message-ID: <20250904063518.2097629-8-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250904063518.2097629-1-Penny.Zheng@amd.com>
References: <20250904063518.2097629-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 satlexmb09.amd.com
 (10.181.42.218)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0DF:EE_|MW5PR12MB5681:EE_
X-MS-Office365-Filtering-Correlation-Id: ab27a334-b81c-4b68-45a5-08ddeb7d4d84
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?lBAoQOjeYcvM42KZPPejzSIkFss8ZfUrELfMsMP7wYPkwslEM6DAalBedaLN?=
 =?us-ascii?Q?pS9+tq5Zspm97lhQA8on1pdR0jCxGdEsSYVA+nznFu8jlS9G2beQj2RPOvGs?=
 =?us-ascii?Q?fwx2KFSyVm2rP+8liYhvWcH37wtzv+QmgUYd3EwK4+MynQCGJEbmi3lB87Pn?=
 =?us-ascii?Q?WpIS1/18Pryysh740bGwjHgP4gI97tcGBtCb2O1JuKRDqJRcFTIgAy2o1NM2?=
 =?us-ascii?Q?l59L0q+bxOjjLQ1+/sMEsXnGmxzZV1+OpjfRJsaNmLWuzd82iTjL7Tm6ThSh?=
 =?us-ascii?Q?tzLTdzaThesrK+57U54PDa2DKKVXiuZ519SXuxGAT4lhNiwBJg26/6Eicj3D?=
 =?us-ascii?Q?ZTP4gXlHSkcZYlrNUz9Vl1bCMDo+e+/QZLXMdWLPIJcBAdkuO3gkjIJHequ8?=
 =?us-ascii?Q?HSf1jmF17soJ+6TGSHZQP5oee14zrfGZ4FmXllN3KVOxHeKsepG8QloNfIGJ?=
 =?us-ascii?Q?nvCKpLNdY/ZQnk8FYGlZEcUSoFiAqDUicu/I0cNNKlxKesbfzEsGCssGjt+U?=
 =?us-ascii?Q?r1YJUKoCNYotVq3f02K4FjcBpE26waI8v2FTSV6hjeJu5s/SW3pBw2yYuLgQ?=
 =?us-ascii?Q?PgsjiGgcF1J7QtDGPaT1RbjDWp5qx2hgmEHoqJuDP5azUhy58/ikcH7D14ya?=
 =?us-ascii?Q?gN1DYzofJscDekWpWKWHd4o7LXbHvE8XXqQPZFtYZx85QB4LCmsIoIl1gMlj?=
 =?us-ascii?Q?uK2fKsrvb9JyMBseY788nmaBOlhVuJjwXDFuBvYcKECgQ6FSYYmQ4d+kivmn?=
 =?us-ascii?Q?KxmkJM+wLkBPGJjlVwu+9UTdacvC0yH6vOPuxIpz4bwTSCFm59tDIp+KvCqI?=
 =?us-ascii?Q?e8Qao1N+ARnMRjPnEVxktsFMcP5/ozCcuFXtlcgifhqWw78piw8AYK0X/tFP?=
 =?us-ascii?Q?7YcWaB0iMuiEJrUdqRF7uxY52/rp+B15ko0X7gCGS5xhjpYCvAC8S1EN7zQK?=
 =?us-ascii?Q?lZJocLiWnAPz/BicgvzNzNVrsLDmALTzSskomZYJ+BJz+1lZLn45deO/V9HS?=
 =?us-ascii?Q?PmUGUyWbuA6FimV9SCGZaxPCJu2gOdPKcVrHCsKUuJtZPRJdv3aL0ia3NLzZ?=
 =?us-ascii?Q?POsl5masN2rAfc0BqQiQ4Khv7PxUb+sFeoyNrhIeH7Hn+MXzI0+ZRK//6jXm?=
 =?us-ascii?Q?Jsq4drvGw5SUbSjU3JgE12yq/XyZIxdKx3WhE/ZX1aOpEsHTOQMSg/xm2Tsy?=
 =?us-ascii?Q?TMxwyBJvHZex3RCBu5KnGvgtRtEFRA5i2K9blUr5cxTHzkFNa1rM10iElpeW?=
 =?us-ascii?Q?Bqo6TIK24w6wjNLKVmiG4YwquSxQYZ5IQrcMilaDG+TpqpNi2s31I8ywDmpy?=
 =?us-ascii?Q?u2XJWTjllQ9YXiS43UyCRmJFmdR1aZwtDL4Zw7TcDFog2xbYcU38bX7UN3uw?=
 =?us-ascii?Q?imL4as+lyRT4FqEXRV/S5GyuOxhqj9gK2CnRioOvmTctBVhfTXYuLlzReQ+0?=
 =?us-ascii?Q?ylR5iH/t70cfjLPOYC6jHceIo812RFbHmN8ujYKRVKrvzJsx/IKt2b4xQohO?=
 =?us-ascii?Q?7SRS5WQakVJ/7Ui8Zk6+/Th5OeJMym1v2TLY?=
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: 04 Sep 2025 06:35:55.9998
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ab27a334-b81c-4b68-45a5-08ddeb7d4d84
X-MS-Exchange-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:
	MN1PEPF0000F0DF.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5681

Introduce helper set_amd_cppc_para() and get_amd_cppc_para() to
SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.

In get_cpufreq_cppc()/set_cpufreq_cppc(), we include
"processor_pminfo[cpuid]->init & XEN_CPPC_INIT" condition check to deal with
cpufreq driver in amd-cppc.
We borrow governor field to indicate policy info for CPPC active mode,
so we need to move the copying of the governor name out of the
!cpufreq_is_governorless() guard.

Signed-off-by: Penny Zheng 
Acked-by: Anthony PERARD 
---
v1 -> v2:
- Give the variable des_perf an initializer of 0
- Use the strncmp()s directly in the if()
---
v3 -> v4
- refactor comments
- remove double blank lines
- replace amd_cppc_in_use flag with XEN_PROCESSOR_PM_CPPC
---
v4 -> v5:
- add new field "policy" in "struct xen_cppc_para"
- add new performamce policy XEN_CPUFREQ_POLICY_BALANCE
- drop string comparisons with "processor_pminfo[cpuid]->init & XEN_CPPC_INIT"
and "cpufreq.setpolicy == NULL"
- Blank line ahead of the main "return" of a function
- refactor comments, commit message and title
---
v5 -> v6:
- remove duplicated manifest constants, and just move it to public header
- use "else if" to avoid confusion that it looks as if both paths could be taken
- add check for legitimate perf values
- use "unknown" instead of "none"
- introduce "CPUFREQ_POLICY_END" for array overrun check in user space tools
---
v6 -> v7:
- use ARRAY_SIZE() instead
- ->policy print is avoided in passive mode and print "unknown" in invalid
cases
- let cpufreq_is_governorless() being the variable's initializer
- refactor with the conditional operator to increase readability
- move duplicated defination ahead and use local variable
- avoid using "else-condition" to bring "dead code" in Misra's nomeclature
- move the comment out of public header and into the respective internal
struct field
- wrap set{,get}_amd_cppc_para() with CONFIG_PM_OP
- add symmetry scenario for maximum check
---
v7 -> v8:
- change function name to amd_cppc_get{,set}_para()
- fix too deep indentation, and indent according to pending open parentheses
- missing -EINVAL when no flag is set at all
- use new helper amd_cppc_prepare_policy() to reduce redundancy
- borrow governor field to indicate policy info
---
v8 -> v9
- add description of "moving the copying of the governor name"
- Adapt to changes of "Embed struct amd_cppc_drv_data{} into struct
cpufreq_policy{}"
---
 tools/misc/xenpm.c                   |  13 ++-
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 163 +++++++++++++++++++++++++++
 xen/drivers/acpi/pm-op.c             |  28 +++--
 xen/include/acpi/cpufreq/cpufreq.h   |   4 +
 4 files changed, 195 insertions(+), 13 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 893a0afe11..bda9c62aa0 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -832,11 +832,14 @@ static void print_cppc_para(unsigned int cpuid,
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
-    bool is_governor_less = false;
+    bool is_governor_less = false, is_cppc_active = false;
     int i;
 
-    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
-         !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+    if ( !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+        is_cppc_active = true;
+
+    if ( is_cppc_active ||
+         !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) )
         is_governor_less = true;
 
     printf("cpu id               : %d\n", cpuid);
@@ -899,6 +902,10 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
                p_cpufreq->u.s.scaling_cur_freq);
     }
 
+    /* Translate governor info to policy info in CPPC active mode */
+    if ( is_cppc_active )
+        printf("policy               : %s\n", p_cpufreq->u.s.scaling_governor);
+
     printf("turbo mode           : %s\n",
            p_cpufreq->turbo_enabled ? "enabled" : "disabled or n/a");
     printf("\n");
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 80b829b84e..01203c65b1 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -561,6 +561,169 @@ static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
     return 0;
 }
 
+#ifdef CONFIG_PM_OP
+int amd_cppc_get_para(const struct cpufreq_policy *policy,
+                      struct xen_get_cppc_para *cppc_para)
+{
+    const struct amd_cppc_drv_data *data = policy->u.amd_cppc;
+
+    if ( data == NULL )
+        return -ENODATA;
+
+    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 amd_cppc_set_para(struct cpufreq_policy *policy,
+                      const struct xen_set_cppc_para *set_cppc)
+{
+    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
+    uint8_t max_perf, min_perf, des_perf, epp;
+    bool active_mode = cpufreq_is_governorless(policy->cpu);
+
+    if ( data == NULL )
+        return -ENOENT;
+
+    /* 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;
+
+    /* Return if there is nothing to do. */
+    if ( set_cppc->set_params == 0 )
+        return 0;
+
+    /*
+     * Validate all parameters
+     * Maximum performance may be set to any performance value in the range
+     * [Nonlinear Lowest Performance, Highest Performance], inclusive but must
+     * be set to a value that is larger than or equal to minimum Performance.
+     */
+    if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
+         (set_cppc->maximum > data->caps.highest_perf ||
+          (set_cppc->maximum <
+           (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM
+            ? set_cppc->minimum
+            : data->req.min_perf))) )
+        return -EINVAL;
+    /*
+     * Minimum performance may be set to any performance value in the range
+     * [Nonlinear Lowest Performance, Highest Performance], inclusive but must
+     * be set to a value that is less than or equal to Maximum Performance.
+     */
+    if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
+         (set_cppc->minimum < data->caps.lowest_nonlinear_perf ||
+          (set_cppc->minimum >
+           (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM
+            ? set_cppc->maximum
+            : data->req.max_perf))) )
+        return -EINVAL;
+    /*
+     * Desired performance may be set to any performance value in the range
+     * [Minimum Performance, Maximum Performance], inclusive.
+     */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+    {
+        if ( active_mode )
+            return -EOPNOTSUPP;
+
+        if ( (set_cppc->desired >
+              (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM
+               ? set_cppc->maximum
+               : data->req.max_perf)) ||
+             (set_cppc->desired <
+              (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM
+               ? set_cppc->minimum
+               : data->req.min_perf)) )
+            return -EINVAL;
+    }
+    /*
+     * Energy Performance Preference may be set with a range of values
+     * from 0 to 0xFF
+     */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
+    {
+        if ( !active_mode )
+            return -EOPNOTSUPP;
+
+        if ( set_cppc->energy_perf > UINT8_MAX )
+            return -EINVAL;
+    }
+
+    /* Activity window not supported in MSR */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
+        return -EOPNOTSUPP;
+
+    des_perf = data->req.des_perf;
+    /*
+     * Apply presets:
+     * XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/ONDEMAND are
+     * only available when CPPC in active mode
+     */
+    switch ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_PRESET_MASK )
+    {
+    case XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE:
+        if ( !active_mode )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_POWERSAVE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
+        if ( !active_mode )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_PERFORMANCE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_ONDEMAND:
+        if ( !active_mode )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_ONDEMAND;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
+        if ( active_mode )
+            policy->policy = CPUFREQ_POLICY_UNKNOWN;
+        break;
+
+    default:
+        return -EINVAL;
+    }
+    amd_cppc_prepare_policy(policy, &max_perf, &min_perf, &epp);
+
+    /* Further customize presets if needed */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM )
+        min_perf = set_cppc->minimum;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM )
+        max_perf = set_cppc->maximum;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
+        epp = set_cppc->energy_perf;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+        des_perf = set_cppc->desired;
+
+    amd_cppc_write_request(policy->cpu, data,
+                           min_perf, des_perf, max_perf, epp);
+
+    return 0;
+}
+#endif /* CONFIG_PM_OP */
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index 371deaf678..bcb3b9b2a7 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -84,6 +84,8 @@ static int get_cpufreq_cppc(unsigned int cpu,
 
     if ( hwp_active() )
         ret = get_hwp_para(cpu, cppc_para);
+    else if ( processor_pminfo[cpu]->init & XEN_CPPC_INIT )
+        ret = amd_cppc_get_para(per_cpu(cpufreq_cpu_policy, cpu), cppc_para);
 
     return ret;
 }
@@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     else
         strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
 
+    /*
+     * In CPPC active mode, we are borrowing governor field to indicate
+     * policy info.
+     */
+    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);
+
     if ( !cpufreq_is_governorless(op->cpuid) )
     {
         if ( !(scaling_available_governors =
@@ -178,13 +191,6 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
         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) )
@@ -321,10 +327,12 @@ static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
     if ( !policy || !policy->governor )
         return -ENOENT;
 
-    if ( !hwp_active() )
-        return -EOPNOTSUPP;
+    if ( hwp_active() )
+        return set_hwp_para(policy, &op->u.set_cppc);
+    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+        return amd_cppc_set_para(policy, &op->u.set_cppc);
 
-    return set_hwp_para(policy, &op->u.set_cppc);
+    return -EOPNOTSUPP;
 }
 
 int do_pm_op(struct xen_sysctl_pm_op *op)
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 85fbf772a0..adecf57e18 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -303,6 +303,10 @@ int acpi_cpufreq_register(void);
 
 int amd_cppc_cmdline_parse(const char *s, const char *e);
 int amd_cppc_register_driver(void);
+int amd_cppc_get_para(const struct cpufreq_policy *policy,
+                      struct xen_get_cppc_para *cppc_para);
+int amd_cppc_set_para(struct cpufreq_policy *policy,
+                      const struct xen_set_cppc_para *set_cppc);
 
 /*
  * Governor-less cpufreq driver indicates the driver doesn't rely on Xen
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:47:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:47:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109628.1459146 (Exim 4.92)
	(envelope-from )
	id 1uu3kk-0000ik-1D; Thu, 04 Sep 2025 06:47:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109628.1459146; Thu, 04 Sep 2025 06:47: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 1uu3kj-0000id-Us; Thu, 04 Sep 2025 06:47:25 +0000
Received: by outflank-mailman (input) for mailman id 1109628;
 Thu, 04 Sep 2025 06:47: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 1uu3ki-0000iX-M1
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:47: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 02c193a0-895b-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 08:47:23 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-61e425434bbso1107521a12.2
 for ; Wed, 03 Sep 2025 23:47: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-61cfc579ba9sm13332754a12.52.2025.09.03.23.47.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Sep 2025 23:47: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: 02c193a0-895b-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756968442; x=1757573242; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BvwuWPj50yyYb925F4Do7r/Dc7OvE9RkImlXpbDhMh0=;
        b=ZOjISwGUQxx2YZfVHjws/kb4Xn+daVnEjzyoRoGQGoyhnz0kMHGrUCJttnjwlbngH1
         K4NIEdl6EbMqFHSllri0KUpY2GjRWHrw2QZeakf7FCrVcXSUOU+o77iUYUzZqg4fH855
         Q28/ogoH98pbSL6VKwq+NVX75uI4rLNEc5RfSW002LQvbL+DlvfhLucuFLBfUU7bEl20
         xVpGDcZ5rmWvLSqjxLap+bthf1vmgEPO15+NvtsZ5pTpdXZ/V6u+VqLjX8hqBDYoywdb
         I1U8jn8aay6nG9NJwNIBK2NQLb9Dl4/IdXAfcLJGRDyiB9g9Qal4FzSvKWSXX9YKfAZt
         9G8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756968442; x=1757573242;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BvwuWPj50yyYb925F4Do7r/Dc7OvE9RkImlXpbDhMh0=;
        b=tiFWbSsaztwGiYcuN8ogiyjkzGt4Zdx+4zFOgvi5OXML52jj5na9AD4/B7YAjksF8g
         gm25q/96LFYp2PkqKESrilnbDfaRxbiH0bQ7OpJl6yLcyA4fCh5Qf910/HAIJ3ftkYfo
         YUHdpx8BYi0Hz70h4OH8YQsvi2plMchKhAkAkuHZLXSeLRLTl26GnYtGCBfpWUhHMoXW
         3iZ6chof+Glvedd9UgGv2gBvm5KgWIItkwCTBfhx1QxvCpo7n1qLGYWSw2vfWMb4We09
         cwCTJgpOIQ2nm051Ip7Je/d5fH0INyuGNhWVL9Raqi7KMPvWO55A8G7ikzhlTWFlml3z
         oGLw==
X-Forwarded-Encrypted: i=1; AJvYcCUCn8ya7hMOXrAUKwWuAz0hCpth8qRF5onZkAreWABzHwYLi0xwev4v4da4Q21cEn49oh1wgm67RBs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5b8wUT13nRQ7abARIyH5FYAzvTp3b77vGmDelV57oBTlv98E/
	GKSncyoaJoneRgxgI1D7o6RpaTKzQCXKNwfG53+Y1HVawSisK8WHP14hLWM9K/wGWw==
X-Gm-Gg: ASbGncuAvjDivHDElt79k06VlinbtOUiPyEX+rcZ6aGR+P3v3xJm9K5XX05+QEQ5MYJ
	E3XRPXL7+zZSMu5/mKqmlIk2k9TsJWMYqFi150AkuB8W5gDm6sZioD/iOSJNNu4vPgzkMnNK0xf
	Z6D8CKHNd0cQzhdh8W7NZF6qdttwe902WG0BfS3o3z4Tb44Digt6kIyidxVf7vLnMzEV3J4iARd
	ZfReDUKItvPxV2UovhoQfy7uSAdDMWeaDRYAAFEyTGdwF0TiUtT+HniJPn54esTV5XSDtGHmRmw
	/Ggz2Z62hqZa4rEdPSDriKK8FxtsCClw7REoYuCMk0edG9c37p3S45T+V9mzvDx+rsG3zsiWl5R
	GFw5Jz2yQySBDfcy/m4jg0en7pKWbxj3+aIhGj0pPDCfO2mj/grxySepmBhsk00G5PUSzr0fjAy
	eBI9jhdwJHh2u6cXtKRkmRvEjHxIdH
X-Google-Smtp-Source: AGHT+IFs/6oH8jSeJ5JpojCE+rZi8Hs6ZPCsxEWPBgCcG5LSB2bchOq7R6L3A5ow9FcRvEgsB/zPwg==
X-Received: by 2002:a05:6402:43c8:b0:61c:9970:a841 with SMTP id 4fb4d7f45d1cf-61d26d7874dmr14405465a12.25.1756968442523;
        Wed, 03 Sep 2025 23:47:22 -0700 (PDT)
Message-ID: <2bf9064a-e10d-481a-bbdf-b269db2e4746@suse.com>
Date: Thu, 4 Sep 2025 08:47:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 8/8] CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq
 driver support
To: Penny Zheng 
Cc: Oleksii Kurochko ,
 Community Manager ,
 xen-devel@lists.xenproject.org
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-9-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, Penny Zheng wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -33,6 +33,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
>       Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
>       and 28 (Temperature Probe).
> +   - Support amd-cppc/amd-cppc-epp cpufreq driver

s/Support/New/ ? Otherwise this reads as if the driver had been there already
(no matter that this is in the "Added" section, but the adjacent entries are
ambiguous already as to "added" vs "changed").

Also a full stop please at the end, like all other entries here have it.

Both can easily be adjusted while committing, of course.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 06:48:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 06:48:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109637.1459157 (Exim 4.92)
	(envelope-from )
	id 1uu3ls-0001DD-AU; Thu, 04 Sep 2025 06:48:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109637.1459157; Thu, 04 Sep 2025 06:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu3ls-0001D6-7U; Thu, 04 Sep 2025 06:48:36 +0000
Received: by outflank-mailman (input) for mailman id 1109637;
 Thu, 04 Sep 2025 06:48: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 1uu3lq-0001Cu-JU
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 06:48:34 +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 2b6d3993-895b-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 08:48:31 +0200 (CEST)
Received: from AM0PR02CA0181.eurprd02.prod.outlook.com (2603:10a6:20b:28e::18)
 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.9094.16; Thu, 4 Sep
 2025 06:48:28 +0000
Received: from AM3PEPF0000A78F.eurprd04.prod.outlook.com
 (2603:10a6:20b:28e:cafe::ce) by AM0PR02CA0181.outlook.office365.com
 (2603:10a6:20b:28e::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Thu,
 4 Sep 2025 06:48:28 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM3PEPF0000A78F.mail.protection.outlook.com (10.167.16.118) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.14
 via Frontend Transport; Thu, 4 Sep 2025 06:48:26 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DU0PR08MB9703.eurprd08.prod.outlook.com (2603:10a6:10:445::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 06:47:52 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%2]) with mapi id 15.20.9094.016; Thu, 4 Sep 2025
 06:47: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: 2b6d3993-895b-11f0-9809-7dc792cee155
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=FDWs1mmGYOVJph7JVuuHIl9VdsEUKHM15lC/1LsYwFjjadmHqCmlaAcXlS6+hnvJPxzeIa+UGDLdE4qb3kZK+BI4JWgN6wXkBt7jUYa0EbSBif1APxwJNeZjov/s3/dalfcfGlR+964njjhQPjkP+qUdfD5RgynJRbazZlNaJ09ppiFXwbVLD6txvfLiwINhg649Zh1m+tU189JJILSjutj3ki697Vv7HzBcF5Cn78QSgEEqOdtuBFzn5Z51gQXDzD/pgTxx1dF/Zfy+k6X4HBfh6x28kbIbrCDz2Eqil/qaRTKfrBXpoSAxS/Db19qDQo+JmJgRChzlTPfCFOwRXA==
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=Ttvx8c6sf0c2nXvr9jShfNp5pS2b5B7KdBzqk3E+vYI=;
 b=euOwY3ZtQ0jH+rKVDMKeRZ8SQApN4iP9KhB6yfPxhIRb/ugmX+dilzBR6UM8Z6uWeM92byiZx5MmgCIlzYBkNkeYIs7beeGhs5WAOlYPsPhbmJldyD1zBOwxRrZ0SRwyDSUob4DGQ7jqnrEzGp4/UdgnklD2Ek88rbaPL4MjG80HKRU3NKQANVmN4YNqqsXZnrLEehc+E1RwG6v/qzdDRyHeOb/sIxYtT/mpZxCo5eEiGAM9FTJgqe0LMQ6Z4C+4UIn4aiiCo+kUUR7u97DiKJl5XptG2goOH0rlvDBGCHXlfVWVrwAxPh7LVqNpUHQIPpOk08EUtc39Wra82iOCqg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=epam.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=Ttvx8c6sf0c2nXvr9jShfNp5pS2b5B7KdBzqk3E+vYI=;
 b=VOx158/SVYC6FaREhVaWFskV+38uBbbgClFEVGuasI4YDmQQha3ZJgNXUJzTOtxLnpDq+b9Ahs7Vlcg07AodYXIFXdDwj8JkLfdaLa53FCfdS+DmQlmAYsvwGZsJPkyoA3c2ArlS1aNXsyrzGR7CKGmwa80K6kuSpTrIra7YNbw=
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=oOV3S6xhry2GBTe/abxxYaDhA1CoM2uAYSi7q1ctWKFZnKQOVC0yc+sBductdEsgDpfCqCCy7D/mWO+GwOq/rvSyUAToBc+O1uFoJV1eKBnzOy4b7rHsyxE7nMwF5J0dMY4n/8g0nd7LTmZ+icAyielSu16vsBALX3MkrydB9xA9iBhb4Qc/TH3uu3P4zcmE+cPbm9lKArrHYg0Pj9APRNyW5pO/flcPzWgxCfvo1sladZeIQtlEDxBOVjDtaLYuFqLYU6xMV2sY1e2TfcKpJC0GyDddbPhWClCV37W5fKFVVDGWvd6TTZbTC/pRARQk6Q1o4nRV18sJb7Dto35Sww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ttvx8c6sf0c2nXvr9jShfNp5pS2b5B7KdBzqk3E+vYI=;
 b=CKshwpaMCwAZYovvvTTuOKowGzRuB3JeRCGGLayiNgj67X8vZ5sQ7o0UyvRw1Oq4CeibyUdpWlpVXl96DvHHWgcMA43rF/Dv9xKceYQV2yxenqlbXExB7hysPAUf9K1Z8NvLcsiH/hWJr8gVBY2w49/+kGaC5ek1F7oE0vvV21UjSbLCc+JmyniZlJtcf/VHDbIO7bRxW91DWQ+G3DvUVrtpayuymm32583w1nkICirrCpU/spFAGKpOVbkYA6RFqFsihEeWQ6Mv1llK6FGI7fpIBEnYcTzi/kI78yIJB7VF2jjulnpqafG6JMHI0UuwQwEnB0UI9dU65+DoafcFhw==
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=Ttvx8c6sf0c2nXvr9jShfNp5pS2b5B7KdBzqk3E+vYI=;
 b=VOx158/SVYC6FaREhVaWFskV+38uBbbgClFEVGuasI4YDmQQha3ZJgNXUJzTOtxLnpDq+b9Ahs7Vlcg07AodYXIFXdDwj8JkLfdaLa53FCfdS+DmQlmAYsvwGZsJPkyoA3c2ArlS1aNXsyrzGR7CKGmwa80K6kuSpTrIra7YNbw=
From: Bertrand Marquis 
To: Dmytro Firsov 
CC: "xen-devel@lists.xenproject.org" , Rahul
 Singh , Stefano Stabellini ,
	Julien Grall , Michal Orzel , Volodymyr
 Babchuk , Julien Grall ,
	Mykola Kvach 
Subject: Re: [PATCH v2] xen/arm: smmuv3: Add cache maintenance for
 non-coherent SMMU queues
Thread-Topic: [PATCH v2] xen/arm: smmuv3: Add cache maintenance for
 non-coherent SMMU queues
Thread-Index: AQHcHQIn+C0aN53q3kCiWfPloZq/2LSClZqA
Date: Thu, 4 Sep 2025 06:47:52 +0000
Message-ID: 
References:
 <6f4552aab3748ea3ad96d45affb8ce9146b557a4.1756922110.git.dmytro_firsov@epam.com>
In-Reply-To:
 <6f4552aab3748ea3ad96d45affb8ce9146b557a4.1756922110.git.dmytro_firsov@epam.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.700.81)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DU0PR08MB9703:EE_|AM3PEPF0000A78F:EE_|AS2PR08MB9595:EE_
X-MS-Office365-Filtering-Correlation-Id: 3604161b-6adf-4739-480f-08ddeb7f0cc0
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|10070799003|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?vsBOQ9r5O0cCPSpnKQ4sIbZDvWSCP9YfPe6IdUYuPGmvonGYepE/FnQKJOrp?=
 =?us-ascii?Q?ROyTs0s7+T0QFOofkuudHcTz9SXxT/Mwgg1Ajy/IyoeM69qcUBW0Mi/9ffLS?=
 =?us-ascii?Q?cY3aJwR3m8Qy9QkENp53TGqtq7Og4w39vPyU1kTrJgeBZa9W8nt9OcdnuzxY?=
 =?us-ascii?Q?Gv6Z+fAk57FNWY4h6OXj6x/Lbuk2GWIHR0dtufi3LuIJNAyDMMHD4gBwD899?=
 =?us-ascii?Q?FcCM8CndNW3YZyFtfX4pT3WmPapf0PkcrJpKCWtcZfl90Slz0QJBm90qXzrV?=
 =?us-ascii?Q?LEOn2z+LN6D2LWPtEKral+HupHDPHPVq85xYf7o+yvaMyxEA7/zTck/Kp7dr?=
 =?us-ascii?Q?uBkEIpaz6GCjvSatTkON7g/XwK1/tkYiaSvNq1Gnszg1+karhN6y+L+ZzydD?=
 =?us-ascii?Q?zGb2rI0AoR/+v8p7SzJIwX5zOM0k3HQ3QAtVbnxLNlbKi2yzqUTOQzUues0P?=
 =?us-ascii?Q?W/nme1IeKi4ZPltxZ0/vLHHT8AB+HEe2/FYfkha9+5LJo9qoOR4USntWHu+w?=
 =?us-ascii?Q?Y/C5PbnqBk5hvvLyqTnyX4D0WcY+gqhUDod6IX1sbOvXNflPFQtxw7DQykYq?=
 =?us-ascii?Q?0NxIaVf4HNZDmFvrrpeNlq1LRwXF2snzFUWDVfxMwpAEBKrfG6KFlsIUGlTS?=
 =?us-ascii?Q?0RUVoNHVJZ+hP3nR3l7ZfnrVXrb6XtktunRuF/pLlRf9Z45vAmCnMQlTyqV/?=
 =?us-ascii?Q?/Qb3nHX3uinBNfcXLC7o29Amil21V2rt2Az1YxmOAj25I6rrzcw2iFo7MnDr?=
 =?us-ascii?Q?GG6YUIxA39YGIioXQpG2H9fqX2Rvv9VmoaO4IcjchVU6KYROsl9WxDOhiOvt?=
 =?us-ascii?Q?VNZmiz/D25+F8/DjBbl46jjYSPclohkGixeebWob8rHiDk5HNVXYo4uKj4Tr?=
 =?us-ascii?Q?DlDzvr4h0nITd4Ybg+fPRVPfvbzS+OH3wYW3oslDH05sOGqcOgLFAvb9UVDk?=
 =?us-ascii?Q?K1YfFf1amZD6SMj2plj6LoLXAEIErzEeW/19/N90PLvJjl3bMo8CXML9vniG?=
 =?us-ascii?Q?HdpXTa2ov4SQbhA2MI34l0IMo36/nvSGVYmYamaCQaX5GGoJPYULLEOTFWcI?=
 =?us-ascii?Q?HcRHdNgnIzzB+hOo76jkQtjMIOZ9wBIRAeZ58TbtOZxmCBKP5V7FyCWjnwic?=
 =?us-ascii?Q?ddaLkgqDLUZawynBuFqEMN2AOeaqnL6vVKdT++MY3HmbZ6Gu6J48SuN4rZLq?=
 =?us-ascii?Q?Llyf5fXjHWDuwBNzZio3F3+DEr3ObfL/Y1YMh+XNn/ClZWK6Mk6CG70c/QJ5?=
 =?us-ascii?Q?nhl24zExSOcEfAB10v2oe4yCSI5BTn0rXRSqdITe9QpHQuLDYcjqMy9IbMTv?=
 =?us-ascii?Q?slOcFRViT5mMOPK52ifnlHecyEbQVo5fLjHn1xmtG3u49htMV9EArsSeAtsU?=
 =?us-ascii?Q?IbbUMQHCiQQlklamf/vLu+s2TFUyYf8ImUqwDsOdjmXm1zsru/QBDDFvCH/F?=
 =?us-ascii?Q?2pghbccKpEe5XUVZb/yXay8m0hrjIzw6TWEeEvzj81Qdfq36CMf6BQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <05F2E9B23BB8CF499FFFB74EB3862309@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9703
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF0000A78F.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	d7c47a0c-af09-4cf0-2f40-08ddeb7ef851
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|14060799003|376014|82310400026|35042699022|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Hiwy9rIUSvKT9xoWGiLq86xmXXtfDfT+Cu3Q8N5HPRm2EJHQy7R8hgPwgfqX?=
 =?us-ascii?Q?GbKuLcV7UmfLyOCetuVcNCMlSfL86Zx8Z7WHKEw+r34e85iw7zHaWOJ0NyB2?=
 =?us-ascii?Q?pTd6DtpsvTz6w/zGGN3dcrpu22aBk4SHwGBvjGhM11FOtuI9ROe4iQ2vqule?=
 =?us-ascii?Q?YLi5YkPpyk5ooRYGTwFGe9JlvOkzZY7e+ddiOX0EQfGvEod0xYeOEGBhP2Xt?=
 =?us-ascii?Q?AaNE0A3f+FvUN3md11M4WMOFzRux+L5eLkHzKZ6OzSI+iqOnXXt3uOWQiu6b?=
 =?us-ascii?Q?jiySU5bYG6MJhnZlQZXOkY3FsV5T4PhTo7kqy+VUFUzg/dje7AtDx4IM0Y6n?=
 =?us-ascii?Q?5Qfk/t/zKpVw0O5SkiAJ1JlhiZYLx99IT4FLR1nX3sjzKLLRne+z1l0sLCR3?=
 =?us-ascii?Q?57xMX88Z4ADmZE+VpXGJCXlfqPDDeReNJeo05VvYq6hdS3OCjDA8UW9rPWp/?=
 =?us-ascii?Q?MxYcLdiCJ+SIu4KO0gu7lrXHpkaU41VXDvbdoW+J17yCPcGVRizNcZGIRhQ3?=
 =?us-ascii?Q?bQKF1AHxNaiRSz0BGKSRzwY13qytDKiQKVjCu8nx3/paWBaJGZ6/7JlwhwKv?=
 =?us-ascii?Q?98HRDvMZkoWXBD8j8k8dcV6TEcfMLLY38udBVQ9yVblBtfC3MU78ioZ4mBKs?=
 =?us-ascii?Q?Kd6t/L0sCm8tA8nqOZg+cy332u12d6Wrqy6NOcvWitZD6QVPnVeP/J5FChqC?=
 =?us-ascii?Q?Au0HBqjaqg6yXxjSbb4wkzIdRqiCfrrml3NoVhTnoAxHyEDBy+4ECglyNzan?=
 =?us-ascii?Q?Q4NDYPdOfIOIabNPNIf62P6DdtKv4qxiWp3Y7JvSYSxa3OwEH/dud9sWhIsW?=
 =?us-ascii?Q?Ya3w1YjnKRo9nT12PMh7zEJ4nEo4PWdtlu4EuIESq10DvfSVj64UQuAkBwro?=
 =?us-ascii?Q?fkHptreVKujGQYFDg5MegMEO3awPArhP70g4etZGVWuPCvtr53OHWXEQZMDd?=
 =?us-ascii?Q?6etlvpCToBu9Hkq0Uy8mZqhxZOCQQDJ3/UzGrr5hdq99K60wwRo91I3Ehh+p?=
 =?us-ascii?Q?stSQl2dnBJtbm/vHzNoNrWga9Z8Fedyh/yDtGj9zt0lZGuzZRT3FoKj2RqF8?=
 =?us-ascii?Q?8EuYg6bVhPjoHF2q161D1GDsxGCk/xNQwzh2jJSt/aeNXiBsnLwtzwHjM15U?=
 =?us-ascii?Q?MhWJH9btiQKn2G3h5zeS9XllxP/BoCOfZE/qqcLbks7yyJVjvzuztq+dtT4G?=
 =?us-ascii?Q?EtvG34AAACGWMaUUI7Q/Kr0cxvaM/7KCvNtroalfiw8lWRk9sFaYpd5hfs5F?=
 =?us-ascii?Q?YLeHTzUDFhxzpkB7K+4MkaSlDsjaS9qO7/4trLDzfiqgMPDGunK+swZjd1dH?=
 =?us-ascii?Q?z0IvjoNrCyDxdyS8TpYgVdA5NBYJcFQST62ttyf03l0tcSaCJ5Vehha6en4G?=
 =?us-ascii?Q?rgrsGp4sLRisc3YtyEdxiOD4V7KJ61oadTaxsJLuf8UqaRq07Ecy0NZhys/p?=
 =?us-ascii?Q?hXBoHSpr1+GqiNfTgKMr72Dk9mSTFW2iMPfvVe06PRsVYuJBwKhNb82tjYAg?=
 =?us-ascii?Q?5P5DJ2cMyxJ7kxlbDEzf6Thyv30vPtzr+sPi?=
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)(14060799003)(376014)(82310400026)(35042699022)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 06:48:26.2799
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3604161b-6adf-4739-480f-08ddeb7f0cc0
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM3PEPF0000A78F.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9595

Hi Dmytro,

> On 3 Sep 2025, at 20:40, Dmytro Firsov  wrote:
>=20
> According to the Arm SMMUv3 spec (ARM IHI 0070), a system may have
> SMMU(s) that is/are non-coherent to the PE (processing element). In such
> cases, memory accesses from the PE should be either non-cached or be
> augmented with manual cache maintenance. SMMU cache coherency is reported
> by bit 4 (COHACC) of the SMMU_IDR0 register and is already present in the
> Xen driver. However, the current implementation is not aware of cache
> maintenance for memory that is shared between the PE and non-coherent
> SMMUs. It contains dmam_alloc_coherent() function, that is added during
> Linux driver porting. But it is actually a wrapper for _xzalloc(), that
> returns normal writeback memory (which is OK for coherent SMMUs).
>=20
> During Xen bring-up on a system with non-coherent SMMUs, the driver did
> not work properly - the SMMU was not functional and halted initialization
> at the very beginning due to a timeout while waiting for CMD_SYNC
> completion:
>=20
>  (XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout
>  (XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout
>=20
> To properly handle such scenarios, add the non_coherent flag to the
> arm_smmu_queue struct. It is initialized using features reported by the
> SMMU HW and will be used for triggering cache clean/invalidate operations=
.
> This flag is not queue-specific (it is applicable to the whole SMMU), but
> adding it to arm_smmu_queue allows us to not change function signatures
> and simplify the patch (smmu->features, which contains the required flag,
> are not available in code parts that require cache maintenance).
>=20
> Signed-off-by: Dmytro Firsov 
> Reviewed-by: Julien Grall 
> Tested-by: Mykola Kvach 

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v2:
> - changed comment for non_coherent struct member
> - added Julien's RB
> - added Mykola's TB
> ---
> xen/drivers/passthrough/arm/smmu-v3.c | 27 +++++++++++++++++++++++----
> xen/drivers/passthrough/arm/smmu-v3.h |  3 +++
> 2 files changed, 26 insertions(+), 4 deletions(-)
>=20
> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthro=
ugh/arm/smmu-v3.c
> index bca5866b35..c65c47c038 100644
> --- a/xen/drivers/passthrough/arm/smmu-v3.c
> +++ b/xen/drivers/passthrough/arm/smmu-v3.c
> @@ -341,10 +341,14 @@ static void queue_write(__le64 *dst, u64 *src, size=
_t n_dwords)
>=20
> static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent)
> {
> + __le64 *q_addr =3D Q_ENT(q, q->llq.prod);
> +
> if (queue_full(&q->llq))
> return -ENOSPC;
>=20
> - queue_write(Q_ENT(q, q->llq.prod), ent, q->ent_dwords);
> + queue_write(q_addr, ent, q->ent_dwords);
> + if (q->non_coherent)
> + clean_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
> queue_inc_prod(&q->llq);
> queue_sync_prod_out(q);
> return 0;
> @@ -360,10 +364,15 @@ static void queue_read(u64 *dst, __le64 *src, size_=
t n_dwords)
>=20
> static int queue_remove_raw(struct arm_smmu_queue *q, u64 *ent)
> {
> + __le64 *q_addr =3D Q_ENT(q, q->llq.cons);
> +
> if (queue_empty(&q->llq))
> return -EAGAIN;
>=20
> - queue_read(ent, Q_ENT(q, q->llq.cons), q->ent_dwords);
> + if (q->non_coherent)
> + invalidate_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
> +
> + queue_read(ent, q_addr, q->ent_dwords);
> queue_inc_cons(&q->llq);
> queue_sync_cons_out(q);
> return 0;
> @@ -458,6 +467,7 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_de=
vice *smmu)
> struct arm_smmu_queue *q =3D &smmu->cmdq.q;
> u32 cons =3D readl_relaxed(q->cons_reg);
> u32 idx =3D FIELD_GET(CMDQ_CONS_ERR, cons);
> + __le64 *q_addr =3D Q_ENT(q, cons);
> struct arm_smmu_cmdq_ent cmd_sync =3D {
> .opcode =3D CMDQ_OP_CMD_SYNC,
> };
> @@ -484,11 +494,14 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_=
device *smmu)
> break;
> }
>=20
> + if (q->non_coherent)
> + invalidate_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
> +
> /*
> * We may have concurrent producers, so we need to be careful
> * not to touch any of the shadow cmdq state.
> */
> - queue_read(cmd, Q_ENT(q, cons), q->ent_dwords);
> + queue_read(cmd, q_addr, q->ent_dwords);
> dev_err(smmu->dev, "skipping command in error state:\n");
> for (i =3D 0; i < ARRAY_SIZE(cmd); ++i)
> dev_err(smmu->dev, "\t0x%016llx\n", (unsigned long long)cmd[i]);
> @@ -499,7 +512,10 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_d=
evice *smmu)
> return;
> }
>=20
> - queue_write(Q_ENT(q, cons), cmd, q->ent_dwords);
> + queue_write(q_addr, cmd, q->ent_dwords);
> +
> + if (q->non_coherent)
> + clean_dcache_va_range(q_addr, q->ent_dwords * sizeof(*q_addr));
> }
>=20
> static void arm_smmu_cmdq_insert_cmd(struct arm_smmu_device *smmu, u64 *c=
md)
> @@ -1587,6 +1603,9 @@ static int arm_smmu_init_one_queue(struct arm_smmu_=
device *smmu,
> q->q_base |=3D FIELD_PREP(Q_BASE_LOG2SIZE, q->llq.max_n_shift);
>=20
> q->llq.prod =3D q->llq.cons =3D 0;
> +
> + q->non_coherent =3D !(smmu->features & ARM_SMMU_FEAT_COHERENCY);
> +
> return 0;
> }
>=20
> diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthro=
ugh/arm/smmu-v3.h
> index f09048812c..ab07366294 100644
> --- a/xen/drivers/passthrough/arm/smmu-v3.h
> +++ b/xen/drivers/passthrough/arm/smmu-v3.h
> @@ -522,6 +522,9 @@ struct arm_smmu_queue {
>=20
> u32 __iomem *prod_reg;
> u32 __iomem *cons_reg;
> +
> + /* Is the memory access coherent? */
> + bool non_coherent;
> };
>=20
> struct arm_smmu_cmdq {
> --=20
> 2.50.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 07:10:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 07:10:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109653.1459167 (Exim 4.92)
	(envelope-from )
	id 1uu47E-0005jV-1Z; Thu, 04 Sep 2025 07:10:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109653.1459167; Thu, 04 Sep 2025 07:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu47D-0005jO-Ud; Thu, 04 Sep 2025 07:10:39 +0000
Received: by outflank-mailman (input) for mailman id 1109653;
 Thu, 04 Sep 2025 07:10: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 1uu47B-0005jE-AY
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 07:10:38 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 40bccc24-895e-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 09:10:35 +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 6B36F4EEBC47;
 Thu,  4 Sep 2025 09:10: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: 40bccc24-895e-11f0-9d12-b5c5bf9af7f9
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=1756969834;
	b=HAYypZukrbdXY3Bf6igfWgGb475tllQZTgSsRGHIjhE0mW35s+tVXEaSGcxZ7AP7AvKO
	 Btgy8A1+0btm1qJwjqv0/wUKd4OpuXQrJ00OnkArZsQ0ZvZ7XyzbE6T3W/zEfs/KqJrt7
	 IYCk+t3Tp9KYwK+Dl6hnfuvo5QNGeOyyZhM7pESAio2boiws2RhG6AFHCceBoG9aDgK0g
	 ZOQRK94PVfkNSyDanAZEzFHojKcDf3lqdm+XuzTAR6yXO5fk6CoeLFpuQV7mkqjNtCQZV
	 8eVdQpHuhQlKsSz428YtWHUMQHOt7ChyO1R7habM9rq9BPaC5s+dB+XbNiNO1XsXbeurW
	 ADgr5CukXMncz9HHRZLcRDU/ZP9/+y0pyfIrKKNHAMJIwYaeT5hFSbZQ8Lu6CJlnaO0/L
	 pwq6qZhY7QCyiPtwINGi5hK+8mur0b1MY8bAbbbL/1HOyVKHlHth5tvs8soWl/mcnBqNU
	 hbxTYgvjOpw9ScgWxVXKlCxrtUP490xgr+drF1fZVw6pjx4PR3uJr33YiEnp9x+1z9NmO
	 SpdNVjRDQjcuws6ExKuI49s3EE7QTN5jwU8KDmQGsAM3+SbTlMDeynqtatw/zvH/ovqI0
	 W4an5KszCo5tnypWSn+OFxMmVPjvRJwim92aahHsFtPo0v0m2zgA+cqwZXxNhvc=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1756969834;
	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=XLbOswXUPJg6LIk8TV86ytb6mfJtQ1IBaz1pUak3pAU=;
	b=xms6hGTDVktfoSF43xEK6DApT9DGlzNy6lPu6qfSX2+3PSM3/23a6Hox6V9QHT3OAPQ6
	 XYY0MvwFanDJZet4HMUJbfQBl1yHhUOIHbwEF7XU/phAoJDe4PIX8Fnd9OW+DUTRdgoCv
	 38bN0on/b0DumjPLkcnyNzI6o1i1eOrxfSBWkeiF+YWgQbODFvIo0OFKxiTpS30++IhWB
	 KyEEmo8cp+0PvXsO4/PKz75uAdXZVNtMviGRQI15pVeHvbiXCCFKJsTlzNlaf+F24SqZd
	 iJRphnV4pYtDhOC/J+ZbM8Sur5Xb8cckcqbMuDiFclo9kJXx0X02SO9V3c+X1c16JMtg9
	 ZBV7IrGZthVyYRDiz1BC4LH/wyc/4hJ40+aRAWppI9iHDUyVoRVxiRHFNOxvIEa2PFlXV
	 DLnp7OUt5b5Z2tJ50px1S96/HzI3p7ZMhVguNwOub4pZ39L0O/MHRbTpdbcIiIO1WxYiG
	 N+7LbHNDL0UR7ogzJjY0eLb1hrKzKAc1Nm/gCW6Nk3ywOxohBpV9oOTR8CMI0KbEBqtef
	 C2Ki2TPHOsoANqQ6EfLXSv+qlF1Fz7B5J5KwTiUgvP7zQbBiRMBjaNfrMEbdy/dkWLWF4
	 E40dbGKbGk9SOZXhOp+YlF4CbeLfpaB2+S7ew3c+zFZXPZDXoJwvq38vMMyAFjs=
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=1756969834; bh=MugVdJV7NDuyuSGlolozR+FQTiAQRtEoFg2kgmNTFIg=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=y1g1xmaeNW0k6ihwf+w07eqt/45d7DR1TPR+FsKn6aPzrKF4EKEmwkacex6jnMTcb
	 9O+QBcpe1ppkn+opmm5cuTXPWKR9aWv1jOoc0oaU7kU4XjbBlw48E4K3id6hr4yukF
	 N5EVs5OIeL9lsEDW3dZIcJwEDpYDZj8ryo/cPzZg6xdH7Q5t4t6XaHyYKib9nSM8va
	 PH9RuIr6iyp+X/OOC2W2hnQRNT1QmAINKr7SX8Y/lAKk4Q7BhZ2E2FxvSladJ9siQo
	 4o8NnJtpEHAIKJIXLVSrgtDHCWM3JA2P2bQBB4+jYUvBy+I6AYQfS2T+tsOdlwLpXa
	 JG+dnv6mD6RrQ==
MIME-Version: 1.0
Date: Thu, 04 Sep 2025 09:10:34 +0200
From: Nicola Vetrini 
To: Volodymyr Babchuk 
Cc: Stefano Stabellini , 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?=
 =?UTF-8?Q?_Pau_Monn=C3=A9?= , Grygorii Strashko
 
Subject: Re: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
In-Reply-To: <87bjnrtdh3.fsf@epam.com>
References: 
 
 <87bjnrtdh3.fsf@epam.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-09-03 23:47, Volodymyr Babchuk wrote:
> Hi Stefano,
> 
> Stefano Stabellini  writes:
> 
>> Hi Oleksii,
>> 
>> It is still not passing the ci-loop, this time due to MISRA. See the 
>> two
>> new 8.3 and 8.4 violations (previously zero) and also new additional
>> 12.2, 13.1 violations:
>> 
> 
> Is there any way to run this kind of tests locally? (I suppose that
> answer is "no")
> 
> Or at least maybe it is possible to use gitlab CI without sending
> patches to the ML? Maybe via opening MRs at gitlab?

Hi Volodymyr,

you can manually run these on branches in sub-repos after creating the 
pipeline, I believe.

-- 
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 Sep 04 07:25:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 07:25:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109667.1459176 (Exim 4.92)
	(envelope-from )
	id 1uu4LA-00084f-D9; Thu, 04 Sep 2025 07:25:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109667.1459176; Thu, 04 Sep 2025 07:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu4LA-00084Y-A1; Thu, 04 Sep 2025 07:25:04 +0000
Received: by outflank-mailman (input) for mailman id 1109667;
 Thu, 04 Sep 2025 07: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 1uu4L9-00084S-3G
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 07:25:03 +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 4440129d-8960-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 09:25:00 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aff0775410eso207377566b.0
 for ; Thu, 04 Sep 2025 00:25:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b04190700a4sm1087796866b.63.2025.09.04.00.24.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 00:24: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: 4440129d-8960-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756970700; x=1757575500; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OfeT1Se81zUkeC4IRHtpFJi1bgBDIe5kD6wRBMQJTog=;
        b=FkGYxcU7uNGWI4y5GuOmXZ/RUhyaCd3KlTcnnUJ9wE1AiyhFi/EXPCbG8AbWTdmdKy
         7hTnm9EyCxP090bYcoF6vMQDviCmZ5KblMn0yBt/ZCuHXmYQLIWdXwff3gEe4550lgCu
         luD91EZoX1uhpXR6RX5GGpN9qTBLpDvPcY8R5USErJ4qbwjz5SJbl4/2zLZ14996pBxS
         Pdd2rYRsIQPMZCK/CucgyQ1YwzN9xTbPAt2J3wn4h2Nn6E9sCp5SY6Iy+GbTxaDj2g4Z
         9tM+rjRd9cBlH8T1kH/wo/IdzmlOMbXj95w0yVPD4lr1HDPs/kLG33NM+/5btk/1eIzA
         Vyfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756970700; x=1757575500;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OfeT1Se81zUkeC4IRHtpFJi1bgBDIe5kD6wRBMQJTog=;
        b=kgRgOirEA9QvKnP+asWE21N0iixGbEMh1H4jugIYqeqv3FGHIRdtBqGsh1HhCZOhpv
         fSF7UpHgPpctHp/rhUcGKUCuf+VE7pLre59pwoD+xqi00Rl6+4OvgegcHZnjhxkbCa/I
         rCuHTqXac3qggBDfdwStDLRYQ0cJB06EcEbB5VChUN5pnZziuyC+vVEMMJ/+f0DbPtIC
         uVE15xryL/3jI5eDViow9VsAuWDDJLXmo/q9h/y9uDKdtiApw55Qps4eX0QExhCkvjj0
         SlO8zkIoxfDKIhw++d4ZrOG/4aw/UYawH+O2F8rP+/mFOMHt618dJT7xLHc2wFq/rgjG
         a0dw==
X-Forwarded-Encrypted: i=1; AJvYcCV2z7MMgIMXnGBjkNzb7Cd9/Oxha0j63l0CNGwcS4tkc4D7lzuD8suaAQtyGz+wlHc8lvDWat4wmXI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyxhPCQiIdawYzH2kxQoQ1GwcdPNlTr3HeB6OIGzq8ViJ9+0M7o
	oZ/Jqr337XnOAlNCI6C2pvF5SFngdG7cydYTwxmobFs67bGVSfU4I0oZC2rE/4cM8w==
X-Gm-Gg: ASbGncuZZDUNGYWn32X0BAEV64h4/uG83olDahy4SRrORR2Gx3TeAsKC/S+yl3JkUqy
	G5YVR80ByERGgOljZAPfYPe4BluNNkyDvIZcVt7KZGYEFAY/JgkIuxj4x6ml2KcdRoa2Cbq5jun
	QXW+Wlp0NIGZO8W5flsOAj+LmhjLREWKKfDdT7jjq9upOOuXM4PwUguKnmksmqk63WI+Zc98VGh
	pYXJSYQA68lFuPH1ZAbTHUOajaAz06Zjx35mLK4/OMq+1exKOXbeXO6Nec8rkMSwjlqvkR8lPxk
	W5WPqVGHGDHFCqeNahI7uD4KiXlL+1nGq5ip9mMJEzErrtA6X3V2A+YAbUbTMDx4jqv83AJkCIf
	lD3OjR7vqlOorqJzNKlIqiUFDsgc2F5TUAQo7jwBCWdm9wGi8hrtLdryfHI1pD3NwUKzj500nWi
	V0cRigYHha91xcj4AhrQ==
X-Google-Smtp-Source: AGHT+IHhjVQsEfPZJ6EM9ZjWu4GFSa4gaSk0ZhleQjH+dGUqJy1XLk/VpJZsVZQ8gC/6dCT/m1eexA==
X-Received: by 2002:a17:907:a45:b0:afe:8bd8:e2c3 with SMTP id a640c23a62f3a-b01af2e0a2fmr2167487566b.0.1756970699845;
        Thu, 04 Sep 2025 00:24:59 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 09:24:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] build: avoid absolute paths in executables
To: Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Oleksii Kurochko 
References: <1071997f-efe6-4088-b753-b74d3a045a09@suse.com>
 <795b069f-12ea-4d05-bdc4-877a6a93fe7c@citrix.com>
 <6f310470-60f3-4c8e-a1fd-1216fd44e4ea@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2025 18:40, Andrew Cooper wrote:
> On 03/09/2025 5:12 pm, Jan Beulich wrote:
>> On 03.09.2025 17:26, Andrew Cooper wrote:
>>> On 03/09/2025 4:13 pm, Jan Beulich wrote:
>>>> --- a/xen/Makefile
>>>> +++ b/xen/Makefile
>>>> @@ -448,6 +448,8 @@ LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin
>>>>  endif
>>>>  
>>>>  ifdef building_out_of_srctree
>>>> +    CFLAGS += $(call cc-option,$(CC),-ffile-prefix-map=$(srctree)/=, \
>>>> +                                     -fdebug-prefix-map=$(srctree)/=)
>>>>      CFLAGS += -I$(objtree)/include
>>>>      CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
>>>>  endif
>>> We do want to be taking a change like this, but it's also definitely not
>>> limited to out-of-tree builds.  I have full paths embedded even for
>>> in-tree builds.
>> In xen-syms I see only two full paths - in debug info, supplying the base
>> path to the tree.

What I'm missing from your reply is clarification whether the mentioned
instances are indeed the only ones you see, or whether there's more in
what you have (and what I'm not seeing for whatever reason).

>> That's okay to stay imo.
> 
> Not for reducible builds it's not.

Yes, I realized this later.

However, I can see benefits to both: When one wants reproducible builds,
no absolute path whatsoever should remain. In other (debugging) cases
having a reference to the root of what everything else is relative to
might be helpful. So whether to replace these remaining instances may
want to be configurable (in turn making it necessary to deal with that
independently for xen/ and tools/; for xen/ that would be a Kconfig
option dependent upon DEBUG_INFO=y).

In out-of-tree builds similar references exist to the build tree root.
Once we zap both, the result is at risk of being ambiguous. I wonder
whether it would be possible (supported by consumers) to replace both
references by something macro-like (along the lines of $SRC/ and $BLD/).

>> In xen.efi I see a few hundred, but they're all the same as above. As I
>> learned earlier today, SHF_MERGE processing isn't invoked when linking
>> ELF objects into a PE binary.
>>
>>> To be useful, it wants to apply to everything, not just the hypervisor,
>>> so does want to be in the top level Config.mk.
>> As per my first remark then. But no, I meanwhile realized that this can't
>> go in Config.mk: For the hypervisor we want to use $(srctree), i.e.
>> including the leaf /xen referencing the xen/ subtree. I expect that for
>> e.g. tools/libs/ we'd want something similar - eliminate the entire path
>> up to the base of the component's source dir. So it will need to be
>> piecemeal.
> 
> Relative to the root of xen.git (or the source tarball) is the only
> sensible option.  Anything else is intentionally misleading.

I disagree. In-tree builds record things downward from xen/ only. So should
out-of-tree builds do. Every individual binary (i.e. including all the tools/
ones) has no need to record anything more than is necessary to unambiguously
identify the source files. In particular us bundling hypervisor, toolstack,
and stubdom (and there we expand various external packages) in a single
repo / tarball is an artifact, not how things normally would be arranged.

> In fact, Marek had a more-correct form of this patch in
> https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#u
> which seems to be waiting on you to reply.

I can't spot anything expecting my reply. What I can spot is a promise to
submit a v2. And, having entirely forgotten that there already was an
attempt, I only now realize why the options coming into play seemed
somewhat familiar.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 10:43:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 10:43:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109811.1459227 (Exim 4.92)
	(envelope-from )
	id 1uu7R2-0006lh-Eq; Thu, 04 Sep 2025 10:43:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109811.1459227; Thu, 04 Sep 2025 10:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu7R2-0006lZ-9u; Thu, 04 Sep 2025 10:43:20 +0000
Received: by outflank-mailman (input) for mailman id 1109811;
 Thu, 04 Sep 2025 10: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 1uu7R0-0006lT-LO
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 10:43:18 +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 f6233262-897b-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 12:43:16 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfout.stl.internal (Postfix) with ESMTP id 868A81D00291;
 Thu,  4 Sep 2025 06:43:14 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Thu, 04 Sep 2025 06:43:14 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 4 Sep 2025 06:43:13 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f6233262-897b-11f0-9809-7dc792cee155
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=1756982594;
	 x=1757068994; bh=vLKJ8EQ4Q3uf2z4yXyC1FFM1RW9BEz2YR4iv12SQq6w=; b=
	LURMkdxb8sbMyjphe4X9+sdSkSTMK/z3MPLKxcif0eWNtV8nVi8jcphh16y9l9Bu
	Bdhteoyo4+jCc8L+nr2dUluq3u4JJ53yrSyi9JSDID02nQjgr2xRhVGBlcGTmuKl
	V+y87tRRc5JCWqboBwlJOFGaLSfjeEeFm5gxj5lEl6KrBWlp5Wh07QuQ7/GqM493
	Q/Azsj+mlF5tNCgSOHWom1dz3bmEtgwZ0dI+lJg9wfqtYyGXutR+OEFXh/3XF3sa
	A5jYVk0QAARxEaOAgCZnYuUBK+xXtkmVBd7shibvx27Zu/pAhcvRkj1NQFTpyy/1
	SF3yHVdBNlyIBk0GdzzYDg==
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=
	1756982594; x=1757068994; bh=vLKJ8EQ4Q3uf2z4yXyC1FFM1RW9BEz2YR4i
	v12SQq6w=; b=eubCI+C3AX/GECW0qkukQzfkz7fL3mcxVDqIAGOUvJ9kWNyJa0+
	AqPQBtjC69hiQg4mpN8Xdb/2ZxVhoE2h00uMbNd/gIf6/ynpk7Tbh8hJa91fAF7N
	Qqhq3sBOiqXgJV9DtfTmhPcmYfLN/BmLNFkhyTOibNqiBEVXollqFmTb5PiZs5Xu
	MdTp1xXhfBWvv/nY2k49e2bnmY6dxPCZZGWqDpYI2AQW6xqrQv6UZid1uxdRYGtU
	taJU5V3Yj1Ou9n0VjoeCd9WOxu1HVi5mL+WjIaijM2lDo7nvid11shesitk9gBQk
	AA1IC6MRyngConerFn+EbRkDuFF6CsZOrbA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdehkeduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhngh
    hslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephedtfeeuhffgjeehfeetvdevueef
    feehkeetfedujeehgfejudehleegudehgeeunecuffhomhgrihhnpehgihhtlhgrsgdrtg
    homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm
    rghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprh
    gtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjsggvuhhlihgt
    hhesshhushgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi
    gvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 4 Sep 2025 12:43:11 +0200
From: Marek Marczykowski 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" 
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865
Message-ID: 
References: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
 <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com>
 
 <0fb22103-c928-40ff-8be9-bf8d3914f028@suse.com>
 <15650736-585b-4b5c-b2d2-53f4670d8530@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="KfBoBeeBXiUIOfsO"
Content-Disposition: inline
In-Reply-To: <15650736-585b-4b5c-b2d2-53f4670d8530@suse.com>


--KfBoBeeBXiUIOfsO
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 4 Sep 2025 12:43:11 +0200
From: Marek Marczykowski 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" 
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865

On Thu, Sep 04, 2025 at 08:27:14AM +0200, Jan Beulich wrote:
> On 04.09.2025 07:58, Jan Beulich wrote:
> > On 03.09.2025 18:03, Marek Marczykowski wrote:
> >> On Wed, Sep 03, 2025 at 05:58:32PM +0200, Jan Beulich wrote:
> >>> On 03.09.2025 17:46, GitLab wrote:
> >>>>
> >>>>
> >>>> Pipeline #2019390073 has failed!
> >>>>
> >>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> >>>> Branch: staging-4.18 ( https://gitlab.com/xen-project/hardware/xen/-=
/commits/staging-4.18 )
> >>>>
> >>>> Commit: 51190865 ( https://gitlab.com/xen-project/hardware/xen/-/com=
mit/51190865a4918c443c310c0478247d5f9caa5dad )
> >>>> Commit Message: x86/suspend: unconditionally raise a timer soft...
> >>>> Commit Author: Roger Pau Monn=C3=A9
> >>>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
> >>>>
> >>>>
> >>>> Pipeline #2019390073 ( https://gitlab.com/xen-project/hardware/xen/-=
/pipelines/2019390073 ) triggered by Jan Beulich ( https://gitlab.com/jbeul=
ich )
> >>>> had 5 failed jobs.
> >>>>
> >>>> Job #11230955404 ( https://gitlab.com/xen-project/hardware/xen/-/job=
s/11230955404/raw )
> >>>>
> >>>> Stage: test
> >>>> Name: adl-suspend-x86-64-gcc-debug
> >>>> Job #11230955410 ( https://gitlab.com/xen-project/hardware/xen/-/job=
s/11230955410/raw )
> >>>>
> >>>> Stage: test
> >>>> Name: adl-pci-pv-x86-64-gcc-debug
> >>>> Job #11230955417 ( https://gitlab.com/xen-project/hardware/xen/-/job=
s/11230955417/raw )
> >>>>
> >>>> Stage: test
> >>>> Name: adl-pci-hvm-x86-64-gcc-debug
> >>>> Job #11233274365 ( https://gitlab.com/xen-project/hardware/xen/-/job=
s/11233274365/raw )
> >>>>
> >>>> Stage: test
> >>>> Name: adl-smoke-x86-64-gcc-debug
> >>>> Job #11233405609 ( https://gitlab.com/xen-project/hardware/xen/-/job=
s/11233405609/raw )
> >>>>
> >>>> Stage: test
> >>>> Name: adl-smoke-x86-64-dom0pvh-gcc-debug
> >>>
> >>> While the same tests are fine for 4.19 and 4.20, all five show rubbis=
h in the log,
> >>> and then fail. No idea what's going on.
> >>
> >> The log says "baudrate is    : 115200", but looking at the state after
> >> the test I see 9600. No idea if that was simply switched back after, or
> >> setting to 115200 didn't work. Anyway I suggest to restart (now that
> >> other jobs completed). I set it manually to 115200 now too (not sure if
> >> that will remain there...).
> >=20
> > The rubbish in the output looks to have gone away, but the adl-* tests =
fail
> > as before. I'm retrying two of them another time, but with little hope.
>=20
> As opposed to 4.19, where we have this
>=20
> minimal cmds is: no
> !! STDIN is not a TTY !! Continue anyway...
> Type [C-a] [C-h] to see available commands
> Terminal ready
>  Xen 4.19.4-pre
> (XEN) [00000043ae35c0c9] Xen version 4.19.4-pre (root@) (gcc (Alpine 12.2=
=2E1_git20220924-r10) 12.2.1 20220924) debug=3Dy Wed Sep  3 12:15:19 UTC 20=
25
>=20
> for 4.18 things (consistently across the tests) look like this
>=20
> minimal cmds is: no
> !! STDIN is not a TTY !! Continue anyway...
> Type [C-a] [C-h] to see available commands
> Terminal ready
> Accessing Gembird #0 USB device 038
> Switched outlet 2 on
> Setting boot mode for 2 to gitlabci... done
> + trap 'ssh control@thor.testnet poweroff; : > /tmp/console-stdin' EXIT
> + '[' -n  ]
> + set +x
>  Xen 4.18.5
> (XEN) Xen version 4.18.5 (root@) (gcc (Alpine 12.2.1_git20220924-r10) 12.=
2.1 20220924) debug=3Dy Wed Sep  3 12:27:30 UTC 2025
>=20
> For 4.19 there's no visible delay between "Terminal ready" and the first =
Xen
> message, whereas for 4.18 there is an approx 1:30min (=C2=B110s) delay af=
ter the
> "+ set +x". That's a lot when the timeout is 2min.

That makes no sense to me, at this point there isn't really much
Xen-specific code running yet, so there shouldn't be any difference
between branches. I think this is only different presentation of the
output, because 4.18 doesn't use expect in that script yet.

As for the actual reason, at least one job ends at "Waiting for uevents
to be processed", which sounds like USB devices enumeration. Just in
case I reset that emulated USB now.

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi5bUAACgkQ24/THMrX
1yySjAf/ZxQ5pIPIxP6YSbdoNIX85J4HFy/lRM4TUCZ4oHZJpq66WlMxVC+rUTte
tJb/CoHoZ83GI9Nlv4urIYdcRxB66DgXm6mimdLuIxTJA5HDb8Hj1I+i4xJsPAmz
nnbX+qiGxpOQrmf61PZw3T9iYK1NcEDbegy5Y+fpz0660qfy30y0+6H76HKXOIpA
lRAdcsJ8SzNjoCqNjSpYXl+eCQ+r0BpdB1+7DDA5IxUkNRhLB1GyFq9rqBsdTHI7
K5M3a6gGvXt6c5qhkZiseiXGjsR6FCi1Z16IkwO5pvjgKKPRh1Rj9j4ijk6tyk+F
tiguG+C2M//PM94rxSdup0kULjlyhw==
=eTPH
-----END PGP SIGNATURE-----

--KfBoBeeBXiUIOfsO--


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 10:49:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 10:49:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109829.1459236 (Exim 4.92)
	(envelope-from )
	id 1uu7Wk-0007Mh-0P; Thu, 04 Sep 2025 10:49:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109829.1459236; Thu, 04 Sep 2025 10: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 1uu7Wj-0007Ma-Tl; Thu, 04 Sep 2025 10:49:13 +0000
Received: by outflank-mailman (input) for mailman id 1109829;
 Thu, 04 Sep 2025 10: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 1uu7Wi-0007MO-Eu
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 10:49:12 +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 ca888227-897c-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 12:49:11 +0200 (CEST)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-55f6507bd53so946551e87.3
 for ; Thu, 04 Sep 2025 03:49:11 -0700 (PDT)
Received: from [192.168.0.110] ([91.123.151.69])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5608ace8121sm1129405e87.84.2025.09.04.03.49.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 03:49: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: ca888227-897c-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756982951; x=1757587751; 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=6nR8TSyxQE0jhlJodX/fnhUjsMeLTIC+vPJygL9k0iM=;
        b=kPp6xd5wAipZFclQxk7JyckepW31dh+CVmsxbVKN+IpQ1F2bPxyTjNZw78thEripRY
         eBtcelWV45vgO4B1GAublmMFfWPLVheLvMxv092mPtE5+rZ2tDo+W4DcBIFkTC8LGg+/
         NbaUAwZMkRbY5+flQe/XAIULqce5EjITuONzgn7DcgYb6ylV4OVvSSMHVOyq3CSR4p/U
         mcntwHnrhBWJ+mubLIE+K8vKQty4jplqa9OGS45wPhThxAdv1N6J7GkDms6EL4mJ4mpR
         yiZx6c2/94jaMrMwKLpC6u6vhtrAGi1UGi4ySQ/UpcyHuF0Edm0L6FeAWGE9kswrYyCJ
         fBNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756982951; x=1757587751;
        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=6nR8TSyxQE0jhlJodX/fnhUjsMeLTIC+vPJygL9k0iM=;
        b=RfOm8TjFouzi32yf9fxQ5AH5uM/6D4NYdxXQh/J3dua9E8rS2KzGnY8bFgPBcyIa9k
         6fSekNdWQqI3PNRxMxiebHZq6InSNXZMjQa+pGvYRFoWP5t6ikaq7Ovw5MYVdRSYkTNQ
         7XZSqEAntucdGM5itWxfkrDuS9VIxZCOotcz9ljBgdBnMfV1KCBRSxeKrW5IfX/jhbQk
         S6dpK2Qr7Oe7GYmokBxtUckASP4/wB7f43L9FwmM7TkTQ8a1LXzG+szgVW44m4zxaOlj
         XVD7hzJq7UeTD/7gr4020EJJlggjBMED00JAQI+7I4eSKhIxwDGj/t+5kIeFHmJjeQB0
         6DKQ==
X-Forwarded-Encrypted: i=1; AJvYcCXV+L99sZxMVF2KYoogSMdpRQ87gAAEIROJ6UShVrn4baTRjOal8M8vsEdrpo1FZZwRoJ7ol+w8A20=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJ3HsoSQqfhaPZeYKn0dBGkcUWiqQkYIQKqEhSY3Evh9EsrMil
	lfzSQ3XTuZMlN0uhs/7jkid5id4l8+9Epr3ps1njOkGu1cre6y58Dx1Q
X-Gm-Gg: ASbGncsKKCv9KNeX18eQijMIa+wsK3CU7FKlSC5coYmIpH7aEY9Hbq6HwcmFvJu0GA/
	ZBWfbqmVkBh8qexyzaATTnML3p3ezFNaEo71xQNUahPjb4TYHKVvkKDhzfOYlkhizpz8HGccUKm
	nvj3/e+VIgA6Ckj77rfd5IlFD7my571NhfdPqwKX3PjoVntCxTu+6KLylgLmacM9kLYWLaEh2/S
	pzg7kU9C0Vo21AWO+VKvVzzlDaGVUAhYRGI7CIdFYtzTR4kzdBs9wj2czjjRkN0A2bR+37hI3N1
	nQUnmDo9u/pL7a3GLNX8yeZElhdcLpY9whv9uYcYg4q4wH8pgFQNAe8wQgykD631W+2s6r4CmqS
	TovOg8azyT4ShIV/SbJqipfd1HA==
X-Google-Smtp-Source: AGHT+IG6B0ndSnXtouzAq1Rlvz3J1/jrSn40Nr0nBsPeddw/0jC6aGsN5Tbc0QrCt5hy7DkUdUFuQg==
X-Received: by 2002:a05:6512:ace:b0:55f:4db1:e450 with SMTP id 2adb3069b0e04-55f708b7213mr5250385e87.22.1756982950759;
        Thu, 04 Sep 2025 03:49:10 -0700 (PDT)
Message-ID: <9d40e91c-5e9a-441b-85ad-8dddf4427cdb@gmail.com>
Date: Thu, 4 Sep 2025 13:49:09 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
To: Volodymyr Babchuk 
Cc: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel 
References: 
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
  <87plc7tdxx.fsf@epam.com>
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: <87plc7tdxx.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 04.09.25 00:37, Volodymyr Babchuk wrote:
> Hi Oleksandr,

Hello Volodymyr

> 
> Oleksandr Tyshchenko  writes:
> 
> 
> [...]
> 
>>> +static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base,
>>> +                                           uint32_t espi_base)
>>> +{
>>> +    if ( reg < espi_base )
>>> +        return reg - spi_base;
>>> +    else
>>> +        return reg - espi_base;
>>> +}
>>
>> I am wondering (I do not request a change) whether
>> vgic_get_reg_offset() is really helpfull,
>> e.g. is
>>   offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORITYRnE);
>> much better than:
>>   offset = reg < GICD_IPRIORITYRnE ? reg - GICD_IPRIORITYR : reg -
>>   GICD_IPRIORITYRnE;
>>
> 
> IMO, it is easy to make a mistake, because you need to write register
> name 3 times. Can cause errors during copy-pasting.

I got it

  But I saw clever
> trick by Mykola Kvach, something like this:
> 
> #define vgic_get_reg_offset(addr, reg_name) ( addr < reg_name##nE ? \
>   addr - reg_name : addr - reg_name##nE )
> 
> And then you can just use this as
> 
> offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR)

 From my PoV, the idea looks good

> 
> I don't know what maintainers think about this type of preprocessor
> trickery, but in my opinion it is justified in this case, because it
> leaves less room for a mistake.
> 
> 



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 10:54:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 10:54:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109840.1459247 (Exim 4.92)
	(envelope-from )
	id 1uu7c3-0000XD-Jp; Thu, 04 Sep 2025 10:54:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109840.1459247; Thu, 04 Sep 2025 10: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 1uu7c3-0000X6-GW; Thu, 04 Sep 2025 10:54:43 +0000
Received: by outflank-mailman (input) for mailman id 1109840;
 Thu, 04 Sep 2025 10:54: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 1uu7c1-0000X0-Sk
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 10:54:41 +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 8e789bed-897d-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 12:54:40 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-b046f6fb2a9so133838566b.2
 for ; Thu, 04 Sep 2025 03:54: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
 a640c23a62f3a-b04129eccbfsm1192486066b.7.2025.09.04.03.54.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 03:54: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: 8e789bed-897d-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756983280; x=1757588080; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nndLkPmvnacWgHdzXqA87PRQh0VWmzTHUS3W4634x2I=;
        b=G0Wp16q/gb8bvzOcXZ6oVdHTFsAqbgUKiqx+u0UMKeAMF+gWMB/iaj0iXj09FRmAjK
         YSBzS3Buzk77V2w+T9X2dx6kAog1/L4arCitdvr9xhDoJ9ynFoYiD+YEO2B0CPVNAU6J
         yT039aZvzGHsv8Ty8PhstWwk4SdzZrx/g6RHdcFzZqidTDSK5WyCx82JetqG9jYBZsNH
         SLpLbzoq1lznXAD8rdAGPgmxOgAKgF2aLz1f1J0zqdIID5lZRAbr1KkFU6N8FiHRiWsA
         AyNWbJAtpXfG8IhIB6UV5Rxsyi7lJeDmqjBZKjUc4XhfJ1rBAtVQKdzyoZmdWTUbS8z3
         bsdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756983280; x=1757588080;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nndLkPmvnacWgHdzXqA87PRQh0VWmzTHUS3W4634x2I=;
        b=BgGKr2ouJKRcKq+ZNmB4J3SFRfvVzPjRXC4S+wJgi29m831HeI3neoGHxVA1smfzJg
         ItM1u+D/t0m4EdFAORWqDfcOvIxJCwPBrkeOYCi0JGYhrv0n79ER8MiGIDZJH6mlt2HY
         DP9h1F39GuUKmSD9vZQy0+3NWfulfm56SbcWzQ/FVlywI2rdjFCE5pTFngWTHbcEk39J
         UQbW5NE2mR44poLuG8H2UvliO8q6D9rXsRuQ7TLWoqUQxn23uqcZf2dz+eQvdTkbL9BR
         hflY0O2rzdmYm69lg5hyfu0MAs//jr1s3HGYUOsAekqrdcTBr6rBljpe9PWp472tRoVE
         cyNw==
X-Gm-Message-State: AOJu0YxGK1FglRPGTAce7XXIAjnik8h65ufSo4YElqHq47KIZYGs+eDO
	GpaWIwF+aJV/3vbLF8be/Zhq3ZNdO1cw7qQxlpPOycfQxvejF7z3pSHCShNsu/eP9w==
X-Gm-Gg: ASbGncttWO9BQ7sbCuA0vH0pZQttm02YIM14lN/asi2Uub2BEPLp0vbVVcae/YdXizu
	ecKLiUecPIjfs5d/+28PJceUur4z0mLvOmRzWOBboNwAKh9Q9Q9CTfPuDiULXfzNvSsPAQVSINE
	kPep86/DLwCDYeiDU/jgGaY9gae/B3TihtvrEZVybrFOtX/sOty6gSazVncr7WlTICo2Uch2W37
	S/d4Sdxir/7xQFPuhj5YuNxe3bSPs47YDZ+rI0X1BlQNi7nLcAiBc62AsV7v0FigfunEzy4VspP
	HjWHnQTuFY8QSqpu0qq8MvQN/noO3Q5jHhsqs2em2TD634p3ewye7T3s8jEhJw+vX69sEXc1znP
	QQGo6+swtMbLvGH7E7LGMmdrDBpyt00Ft/Tw2ddVYrglGC4uhFW1UTb3O79JZgf/7hr82CJrmWX
	AP8LIRP/8=
X-Google-Smtp-Source: AGHT+IFYlWQU3xUc1hgux9vt256dVEJU2Kwk9qhbad5o4Cvlgzth0bOEOavEdZorJDN7KA86XCWvBg==
X-Received: by 2002:a17:906:ef0e:b0:ae3:a78d:a08a with SMTP id a640c23a62f3a-b01d8a2fcd6mr1363538966b.6.1756983279698;
        Thu, 04 Sep 2025 03:54:39 -0700 (PDT)
Message-ID: <3344c30d-99b7-4b0b-a86e-25063f925638@suse.com>
Date: Thu, 4 Sep 2025 12:54:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen | Failed pipeline for staging-4.18 | 51190865
To: Marek Marczykowski 
Cc: "xen-devel@lists.xenproject.org" 
References: <68b862c0518f3_2cdd2ac12775d@gitlab-sidekiq-catchall-v2-5996545549-kk9d8.mail>
 <8319cf73-52f9-48e2-a571-452da53c36d9@suse.com> 
 <0fb22103-c928-40ff-8be9-bf8d3914f028@suse.com>
 <15650736-585b-4b5c-b2d2-53f4670d8530@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.09.2025 12:43, Marek Marczykowski wrote:
> On Thu, Sep 04, 2025 at 08:27:14AM +0200, Jan Beulich wrote:
>> On 04.09.2025 07:58, Jan Beulich wrote:
>>> On 03.09.2025 18:03, Marek Marczykowski wrote:
>>>> On Wed, Sep 03, 2025 at 05:58:32PM +0200, Jan Beulich wrote:
>>>>> On 03.09.2025 17:46, GitLab wrote:
>>>>>>
>>>>>>
>>>>>> Pipeline #2019390073 has failed!
>>>>>>
>>>>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>>>>> Branch: staging-4.18 ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging-4.18 )
>>>>>>
>>>>>> Commit: 51190865 ( https://gitlab.com/xen-project/hardware/xen/-/commit/51190865a4918c443c310c0478247d5f9caa5dad )
>>>>>> Commit Message: x86/suspend: unconditionally raise a timer soft...
>>>>>> Commit Author: Roger Pau Monné
>>>>>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>>>>>>
>>>>>>
>>>>>> Pipeline #2019390073 ( https://gitlab.com/xen-project/hardware/xen/-/pipelines/2019390073 ) triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>>>>>> had 5 failed jobs.
>>>>>>
>>>>>> Job #11230955404 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955404/raw )
>>>>>>
>>>>>> Stage: test
>>>>>> Name: adl-suspend-x86-64-gcc-debug
>>>>>> Job #11230955410 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955410/raw )
>>>>>>
>>>>>> Stage: test
>>>>>> Name: adl-pci-pv-x86-64-gcc-debug
>>>>>> Job #11230955417 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11230955417/raw )
>>>>>>
>>>>>> Stage: test
>>>>>> Name: adl-pci-hvm-x86-64-gcc-debug
>>>>>> Job #11233274365 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233274365/raw )
>>>>>>
>>>>>> Stage: test
>>>>>> Name: adl-smoke-x86-64-gcc-debug
>>>>>> Job #11233405609 ( https://gitlab.com/xen-project/hardware/xen/-/jobs/11233405609/raw )
>>>>>>
>>>>>> Stage: test
>>>>>> Name: adl-smoke-x86-64-dom0pvh-gcc-debug
>>>>>
>>>>> While the same tests are fine for 4.19 and 4.20, all five show rubbish in the log,
>>>>> and then fail. No idea what's going on.
>>>>
>>>> The log says "baudrate is    : 115200", but looking at the state after
>>>> the test I see 9600. No idea if that was simply switched back after, or
>>>> setting to 115200 didn't work. Anyway I suggest to restart (now that
>>>> other jobs completed). I set it manually to 115200 now too (not sure if
>>>> that will remain there...).
>>>
>>> The rubbish in the output looks to have gone away, but the adl-* tests fail
>>> as before. I'm retrying two of them another time, but with little hope.
>>
>> As opposed to 4.19, where we have this
>>
>> minimal cmds is: no
>> !! STDIN is not a TTY !! Continue anyway...
>> Type [C-a] [C-h] to see available commands
>> Terminal ready
>>  Xen 4.19.4-pre
>> (XEN) [00000043ae35c0c9] Xen version 4.19.4-pre (root@) (gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924) debug=y Wed Sep  3 12:15:19 UTC 2025
>>
>> for 4.18 things (consistently across the tests) look like this
>>
>> minimal cmds is: no
>> !! STDIN is not a TTY !! Continue anyway...
>> Type [C-a] [C-h] to see available commands
>> Terminal ready
>> Accessing Gembird #0 USB device 038
>> Switched outlet 2 on
>> Setting boot mode for 2 to gitlabci... done
>> + trap 'ssh control@thor.testnet poweroff; : > /tmp/console-stdin' EXIT
>> + '[' -n  ]
>> + set +x
>>  Xen 4.18.5
>> (XEN) Xen version 4.18.5 (root@) (gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924) debug=y Wed Sep  3 12:27:30 UTC 2025
>>
>> For 4.19 there's no visible delay between "Terminal ready" and the first Xen
>> message, whereas for 4.18 there is an approx 1:30min (±10s) delay after the
>> "+ set +x". That's a lot when the timeout is 2min.
> 
> That makes no sense to me, at this point there isn't really much
> Xen-specific code running yet, so there shouldn't be any difference
> between branches. I think this is only different presentation of the
> output, because 4.18 doesn't use expect in that script yet.

Except that one can observe that 1:30min delay when watching the job progressing.

> As for the actual reason, at least one job ends at "Waiting for uevents
> to be processed", which sounds like USB devices enumeration. Just in
> case I reset that emulated USB now.

Others (e.g. the suspend job) timed out elsewhere, though.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 11:18:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 11:18:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109856.1459257 (Exim 4.92)
	(envelope-from )
	id 1uu7yZ-0003Y3-G9; Thu, 04 Sep 2025 11:17:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109856.1459257; Thu, 04 Sep 2025 11:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu7yZ-0003Xw-Cx; Thu, 04 Sep 2025 11:17:59 +0000
Received: by outflank-mailman (input) for mailman id 1109856;
 Thu, 04 Sep 2025 11:17:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uu7yY-0003Xq-Ly
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 11:17:58 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ce9c75cf-8980-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 13:17:56 +0200 (CEST)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-336d84b58edso9296051fa.0
 for ; Thu, 04 Sep 2025 04:17:56 -0700 (PDT)
Received: from [192.168.0.110] ([91.123.151.69])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-337f50bfda3sm14694061fa.62.2025.09.04.04.17.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 04:17: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: ce9c75cf-8980-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756984676; x=1757589476; 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=HBdwJF9jipzdshi0RpBlHO4oeC+gshQOme168Ak0B4k=;
        b=EaIJUGyKspmJhudvEAAdwCn1gI8MjwaJJkF3X/X7nhoWw63TuPg22huWkj9CLXAKqf
         KgmYBqCzfXH+3IttxZ98QWhHea2utom1W691KwUGafayh3ZDq6bd+FKand7EZxlTQ2uO
         BBD9WpW+APZg0p/TZa1JQkLuM9LidSuUUZOpaX8JiCOKYbtxJ9oPHnzahinDFr358AgS
         uuQxpRwNvY280geqzDkVJDC4Vdo3C633hXrsnuhYeEfI71n+SCVFcWQ872RwYwJJkE9/
         x72grxSFetCXBXswZ9pLvF61Xu9ib2QU8qkn2ylVo4TpdPw2afNtEYHFhpkviUgSDuwr
         AdSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756984676; x=1757589476;
        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=HBdwJF9jipzdshi0RpBlHO4oeC+gshQOme168Ak0B4k=;
        b=mGUCyajVh6RWHNtbecLrlwNkxJXDvUoPe/wBoYL0PD4UVoPO8HsheFqOvItfV4qnNe
         uPAHPMZ9eriC5nN8ksjHLfPTdp/kbrY9ZAc8IT3/0nZarp8VWfIydHsyGJcafAd17YHv
         4J8XlPT3153WUuzToH29fN2XL1KqYSTEcJ5RNJC3Dc2WurFyghc2FPGNhLWHGmy5ST9U
         sJ48aqZyEj6gtyRQzCVfwpn1BXdONcnktNy0hpuZm9f4EFGXXrgOVZ9d3Nksb3leGzy/
         fEHQrilLrINBcK26yz/3B9jU2UTV1yDDEce0cNbq9zna+bD2yHbQma4njC/1+8XfYgfs
         qjOw==
X-Gm-Message-State: AOJu0YxBGONtIEJ4V1x7/fkwJefL2jY7ovqvIDc3j4z8o4++yGOfvjj8
	Fl7yblUmvwXp7X1+4h6skSdLq3bTEm9KcSA4A4CMLytP6QOdvwvqA7mc
X-Gm-Gg: ASbGnctSV4ntPVt7hKhWBTJtphaO2mXxo3tG9Xg0BVk8PdB2brFQl6p2VMqx20tGtcL
	eHTslFjdDkqUDxu404iZz9U4MrPHUPxrgiUo+VqeedBuCtnG4kIH/PR51J8y4tenMdwZQ9ntPLo
	DKJVmMHGK3tSvSyaTdsWKl3yxMrqWqBf3DRl4j/+zXk/VXC7CDTsPG0vBpdVPm3xNmhp3g/OAxZ
	pezgDLJwmJEJ5+wf/yBsmN1eBdKi4QZNT+DcpJAfZpfhaNBWqVHUCQjhKuz9kRYLlECqY0kvjtk
	oZAftjiG7jGDXbIoa4aVUKXOTxkC/C9xMCMFCdTrYJNsnYLMJqNZb801G1YW4EHX1zegmLTR4Oa
	bld699RLrjyPvgA1FIeF2LORT7g==
X-Google-Smtp-Source: AGHT+IFskoRzcRASuGpMI/HEWiRnnTXPwIYfiu2FcCW4wwztEH2o8dRtvj8iEquCajBK/1Cw7S+kXA==
X-Received: by 2002:a2e:b8c1:0:b0:336:de52:f455 with SMTP id 38308e7fff4ca-336de52f908mr46742001fa.13.1756984675615;
        Thu, 04 Sep 2025 04:17:55 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 14:17:54 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
To: Leonid Komarianskyi ,
 Julien Grall , Volodymyr Babchuk 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel 
References: 
 <345da260fcb3bb400834f8a59dacfda8b37440a1.1756908472.git.leonid_komarianskyi@epam.com>
  <87plc7tdxx.fsf@epam.com>
 <13ed364c-bec3-4c3e-a451-7bc312b2db9d@xen.org>
 <1ec20c31-2ece-4d31-97e2-72995b6aa2b6@epam.com>
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: <1ec20c31-2ece-4d31-97e2-72995b6aa2b6@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 04.09.25 08:52, Leonid Komarianskyi wrote:
> Hi Julien, Volodymyr and Oleksandr,


Hello all

> 
> Thank you for your comments.
> 
> On 04.09.25 02:04, Julien Grall wrote:
>> Hi,
>>
>> On 03/09/2025 22:37, Volodymyr Babchuk wrote:
>>> Hi Oleksandr,
>>>
>>> Oleksandr Tyshchenko  writes:
>>>
>>>
>>> [...]
>>>
>>>>> +static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t
>>>>> spi_base,
>>>>> +                                           uint32_t espi_base)
>>>>> +{
>>>>> +    if ( reg < espi_base )
>>>>> +        return reg - spi_base;
>>>>> +    else
>>>>> +        return reg - espi_base;
>>>>> +}
>>>>
>>>> I am wondering (I do not request a change) whether
>>>> vgic_get_reg_offset() is really helpfull,
>>>> e.g. is
>>>>    offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORITYRnE);
>>>> much better than:
>>>>    offset = reg < GICD_IPRIORITYRnE ? reg - GICD_IPRIORITYR : reg -
>>>>    GICD_IPRIORITYRnE;
>>   >>>
>>> IMO, it is easy to make a mistake, because you need to write register
>>> name 3 times. Can cause errors during copy-pasting.
>>
>> +1.
>>
>>    But I saw clever
>>> trick by Mykola Kvach, something like this:
>>>
>>> #define vgic_get_reg_offset(addr, reg_name) ( addr < reg_name##nE ? \
>>>    addr - reg_name : addr - reg_name##nE )
>>>
>>> And then you can just use this as
>>>
>>> offset = vgic_get_reg_offset(reg, GICD_IPRIORITYR)
>>>
>>> I don't know what maintainers think about this type of preprocessor
>>> trickery, but in my opinion it is justified in this case, because it
>>> leaves less room for a mistake.
>>
>> I don't have a strong opinion between the macro version or the static
>> inline helper. However:
>>     * for the macro version, you want to store 'addr' in a local variable
>> to ensure it is only evaluated once.
>>     * for both case, I would prefer if we assert (for the static inline
>> helper) or use BUILD_BUG_ON() to confirm that spi_base < espi_base
>>
>> Cheers,
>>
> 
> I was considering introducing this kind of macro, but I think it may
> lead to issues in the future because it requires us to always maintain
> the pattern reg_name/reg_name##nE for all registers. I understand that
> the names of the defines are unlikely to change, but I would prefer to
> use an inline function along with the suggested ASSERT(), as it seems
> more versatile to me.

I was leaning more towards the macro, but would be happy with static 
inline helper (my R-b will stay).

I guess, the suggested ASSERT() for the static inline
helper vgic_get_reg_offset would be also applicable for helper 
vgic_get_rank (or whatever name it will gain).

> 
> Best regards,
> Leonid



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 11:42:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 11:42:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109893.1459267 (Exim 4.92)
	(envelope-from )
	id 1uu8M2-0007Pc-9m; Thu, 04 Sep 2025 11:42:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109893.1459267; Thu, 04 Sep 2025 11:42:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu8M2-0007PV-6j; Thu, 04 Sep 2025 11:42:14 +0000
Received: by outflank-mailman (input) for mailman id 1109893;
 Thu, 04 Sep 2025 11:42: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 1uu8M1-0007PP-GP
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 11:42:13 +0000
Received: from fout-b4-smtp.messagingengine.com
 (fout-b4-smtp.messagingengine.com [202.12.124.147])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 312caebe-8984-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 13:42:11 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id 85C2A1D002A4;
 Thu,  4 Sep 2025 07:42:09 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Thu, 04 Sep 2025 07:42:09 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 4 Sep 2025 07:42:07 -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: 312caebe-8984-11f0-9809-7dc792cee155
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=1756986129; x=1757072529; bh=ndzTJbL+Lm2p/b7sczaFIUrnFM/1frrJ
	UDrPdeoO0b4=; b=lOHRuLde4jBoUfOC/19uJ+hxE+fJiiwpPQpASK3AKaloYQxV
	Cb8huJOmVTRYeRBXVsNDJ3TJv9bCjaTW1AdXX7OzXabTIeBaD9XDu1JNV05KkAIf
	dbQMbCjmOAGHsRdLbQK7tv5/GSFZhd80kvol1MYF4NacNZLjO/ZcXfO6iQElIALG
	kuqP9JVTSqQUYG5Hbgl6YlbX20eBFicrkosXy6VjOYtxfZ/L/4RNlhlZDKfruZCj
	GUOlp9m0CVjSnUlHipi9tPL4GfOx1DkkgmOa1e4r4qZRQD4iZz5fpYtI/i0DydaZ
	sUPIB+tI1rvISw7uDIVFSlCIGh/UAO7+XdLp5w==
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=1756986129; x=1757072529; bh=ndzTJbL+Lm2p/b7sczaFIUrnFM/1
	frrJUDrPdeoO0b4=; b=PJHBaPkrO6161uEPmfwCG2QhcWWT30Ut484QTc6ylfsq
	sg8euX0HMqa4eXmXlpJe8evfDgN6XATKeOlzsIGXpw4rhs2WEBQ9OqX1hhOFVrfM
	K9/UbqhOTMrlz3HrUW549/id5+rItLmZKbI+FlVjM4Vtaoqa2Hxq2kfy4Y/NQK7D
	TMDoThDpwgAhXMsunwVg0rdIwkEi+cY279Zj7I/LaI2XWO1kp2nIm9k0ymF8lalo
	U0t2+m+anYRnJgTu7QhB7Tse6x6A5ux+BNa8pY1BfY0s8uJqh1MsJx4jxg2dV7dG
	9lCaGLtaEgUVqTn7TKZvBW/1XEhVF9z6tMvFA2TXng==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdehleefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    ephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghkucforghr
    tgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisg
    hlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeelkefhudelteel
    leelteetveeffeetffekteetjeehlefggeekleeghefhtdehvdenucevlhhushhtvghruf
    hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhi
    shhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeelpdhmohguvg
    epshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghn
    phhrohhjvggtthdrohhrghdprhgtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisg
    hlvghthhhinhhgshhlrggsrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgr
    rhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfe
    estghithhrihigrdgtohhmpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgu
    rdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtth
    hopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegt
    ihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlh
    drohhrgh
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?= ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2] Strip build path directories in tools and hypervisor
Date: Thu,  4 Sep 2025 13:41:40 +0200
Message-ID: <20250904114202.2722478-1-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
available in earlier toolchain versions. But use it together with
-fmacro-prefix-map (if available) for hypervisor build, otherwise it
still contains some paths in out-of-tree builds.

The out of tree build requires -fdebug-prefix-map mapping for both source
dir and object dir - otherwise the latter is included (2 occurrences) in
xen-syms. Note the ./xen path for out of tree builds may not be strictly
correct choice, but it's consistent across the tree, and just require
starting debugger from the source, not object, directory.

Ensure to have a realpath for XEN_ROOT else it fails to substitute
properly paths in strings sections.

Signed-off-by: Marek Marczykowski-Górecki 
---
v2:
- re-add chunk wrapping XEN_ROOT with realpath; simplify it with patsubst
  in hypervisor makefile
- fix cc-option-add usage
- extend commit message
- claim authorship of the patch, as no single line remained from the
  original version
- drop change in xen/arch/x86/Makefile
---
 tools/Makefile | 2 +-
 tools/Rules.mk | 2 ++
 xen/Makefile   | 6 +++++-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 6ecf7c0da821..80ec82a15979 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -1,4 +1,4 @@
-XEN_ROOT = $(CURDIR)/..
+XEN_ROOT = $(realpath $(CURDIR)/..)
 
 export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
 
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 725c3c32e9a2..428fce094819 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -166,6 +166,8 @@ endif
 CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
 CFLAGS += $(CFLAGS-y)
 
+$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
+
 CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
 
 INSTALL_PYTHON_PROG = \
diff --git a/xen/Makefile b/xen/Makefile
index 49da79e10fb4..015255971804 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -208,7 +208,7 @@ VPATH := $(srctree)
 
 export srctree objtree VPATH
 
-export XEN_ROOT := $(abs_srctree)/..
+export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))
 
 # To make sure we do not include .config for any of the *config targets
 # catch them early, and hand them over to tools/kconfig/Makefile
@@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
+$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_objtree)=./xen)
+$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_srctree)=./xen)
+$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=$(abs_srctree)=./xen)
+
 AFLAGS += -D__ASSEMBLY__
 
 $(call cc-option-add,AFLAGS,CC,-Wa$$(comma)--noexecstack)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 11:50:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 11:50:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109905.1459280 (Exim 4.92)
	(envelope-from )
	id 1uu8UJ-0000cr-3F; Thu, 04 Sep 2025 11:50:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109905.1459280; Thu, 04 Sep 2025 11: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 1uu8UJ-0000ck-0S; Thu, 04 Sep 2025 11:50:47 +0000
Received: by outflank-mailman (input) for mailman id 1109905;
 Thu, 04 Sep 2025 11: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 1uu8UH-0000ce-Dl
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 11:50:45 +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 63384771-8985-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 13:50:44 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-afcb7ae31caso156525066b.3
 for ; Thu, 04 Sep 2025 04:50: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-aff138a8d76sm1394444766b.104.2025.09.04.04.50.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 04:50: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: 63384771-8985-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756986643; x=1757591443; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Kq9GCpFaYT48FOq3UM86Tduy9jRrqzASQbYY7MHd40c=;
        b=GDU3OVuhZbei3hQUhD69KuP59v5+Oh+XUbRjfhmvJUf/AmV1wq2KTWIZQAz+UwUqCi
         TuWYOc634HFJkSOE7MDlqZT/OwXzu4lnwewzUVXV2CVN+Ha/KuGRV5xcd40pqe9r7G5I
         HH9klriAZrwzYpsPvxAQ51AVKarLZkZ7YAA+HU20MZpgEmDDteyeLCjvwSyuyOAG1NLU
         rJ6NEdvj2tgsRsUfR8e6HnNdFcBtrPDFaX/eiW7LADLfAUiUb2K3WNFU/VMT+8YDJ3ZK
         uwZs+Tig3pazJmxWP6VOKIYZTkDm2Cv/RwNdUfRyiRWwVzkzFRf/a+lVu5EkZbs+nl5H
         vdaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756986643; x=1757591443;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Kq9GCpFaYT48FOq3UM86Tduy9jRrqzASQbYY7MHd40c=;
        b=pIs+e3eltJ4PdBNhdUCD+XLPbkXsKUrQYliB8T6a1Zkuwucd4hqvllh0judTnEc8K4
         Sr3g+yT4gGIYAU1FSJGJSUjF26ciXPJLMW2VdJXZw5GG3OEHb1a/PWwQHypgP50tj0fM
         HqgCoWMdh29/xjPcofIo0MWGu/P7lGUQo1Uqxs/+czubkZnQjhsxXgF6iyf9rRwbmTqg
         APIvUMUbvqBx2/EcB8Ab6VKZMNzlEtF1IEFW2v88aBtTEJG61wY4xLqaMMyIZ9+Qwq+q
         hUE0LQ1o0hUWIDdXXTTJn/JpKnEa21Ga3+ov9Z7f/XGXftCkP5BNubWInLDfmuuFlg0a
         aTSw==
X-Forwarded-Encrypted: i=1; AJvYcCVwdQOiaQUJ3CohW/zYEmLR6RBx7NiHAUQSvzk0wTIU1AaBAmg3ufc9n/rt628ZTOg6yuuzV6neG+E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZ+lFU7/QJXszDxhXPA0thp3CcQv6gg9Zl2tsFn7xwp1gcQLQC
	S2wQjTC+HEDMggX/N2tPtBb5OAiVl5hSelUVCiZt/3BSoqmItK2JNk9QTkKvpShuNw==
X-Gm-Gg: ASbGncvtUqIMuYhQ7PZOlf+AefzkT0Z5wW9/6qVMBdn6o9lkCTEObho7j0izAIWa5r7
	kbzSyPJjz0zrLEBMmTgScnhlyAQjJhKV7o0kSzIF9eFjKYFF0YaSOMBP6XkpzwcNByiscQEm4KM
	zOPwiszq+QD5mp/lKTIBig+9Nd/7yCNwatfT3Kgf6PQgKbUPgft95XmgrfQMGpdkuv7FyidOP+V
	3oj1JgNZTUucM1Uphy3k6T1fIK27yXk1XO9CfMPX6sIhMe3XN3b7Fwazj8DKYTlHW0Z5N0dOYXr
	3vorftEKHWrPk9ZRk2cnjTUfsTnwHJGThXABTllYMXphxRbB3IhyFKh7moKpx9rYp5JfwFGRXAg
	xgHJ7at5HxVPFtxn5mszrk2XMjtbc8gXQduW8yBuhTZ0RLMJ76+GsGzpAtlPRuZrn0B65uCxaU3
	r+hXYUDXY=
X-Google-Smtp-Source: AGHT+IH5QzA0/Fz7AeS0tWtcY9JhCIx75XQWcWbi3GhxNuU03zhPs1jemvU1g/ztBqcjEPXFr9AIHw==
X-Received: by 2002:a17:906:f59f:b0:b04:72bd:2080 with SMTP id a640c23a62f3a-b0472bd2168mr403464666b.60.1756986643143;
        Thu, 04 Sep 2025 04:50:43 -0700 (PDT)
Message-ID: <849f73f1-4004-4d17-a7a9-d755fb0f889b@suse.com>
Date: Thu, 4 Sep 2025 13:50:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
To: Penny Zheng , Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, Penny Zheng wrote:
> For cpus sharing one cpufreq domain, cpufreq_driver.init() is
> only invoked on the firstcpu, so current per-CPU hwp driver data
> struct hwp_drv_data{} actually fails to be allocated for cpus other than the
> first one. There is no need to make it per-CPU.
> We embed struct hwp_drv_data{} into struct cpufreq_policy{}, then cpus could
> share the hwp driver data allocated for the firstcpu, like the way they share
> struct cpufreq_policy{}. We also make it a union, with "hwp", and later
> "amd-cppc" as a sub-struct.

And ACPI, as per my patch (which then will need re-basing).

> Suggested-by: Jan Beulich 

Not quite, this really is Reported-by: as it's a bug you fix, and in turn it
also wants to gain a Fixes: tag. This also will need backporting.

It would also have been nice if you had Cc-ed Jason right away, seeing that
this code was all written by him.

> @@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct cpufreq_policy *policy,
>                                         unsigned int relation)
>  {
>      unsigned int cpu = policy->cpu;
> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
> +    struct hwp_drv_data *data = policy->u.hwp;
>      /* Zero everything to ensure reserved bits are zero... */
>      union hwp_request hwp_req = { .raw = 0 };

Further down in this same function we have

    on_selected_cpus(cpumask_of(cpu), hwp_write_request, policy, 1);

That's similarly problematic when the CPU denoted by policy->cpu isn't
online anymore. (It's not quite clear whether all related issues would
want fixing together, or in multiple patches.)

> @@ -350,7 +349,7 @@ static void hwp_get_cpu_speeds(struct cpufreq_policy *policy)
>  static void cf_check hwp_init_msrs(void *info)
>  {
>      struct cpufreq_policy *policy = info;
> -    struct hwp_drv_data *data = this_cpu(hwp_drv_data);
> +    struct hwp_drv_data *data = policy->u.hwp;
>      uint64_t val;
>  
>      /*
> @@ -426,15 +425,14 @@ static int cf_check hwp_cpufreq_cpu_init(struct cpufreq_policy *policy)
>  
>      policy->governor = &cpufreq_gov_hwp;
>  
> -    per_cpu(hwp_drv_data, cpu) = data;
> +    policy->u.hwp = data;
>  
>      on_selected_cpus(cpumask_of(cpu), hwp_init_msrs, policy, 1);

If multiple CPUs are in a domain, not all of them will make it here. By
implication the MSRs accessed by hwp_init_msrs() would need to have wider
than thread scope. The SDM, afaics, says nothing either way in this regard
in the Architectural MSRs section. Later model-specific tables have some
data.

Which gets me back to my original question: Is "sharing" actually possible
for HWP? Note further how there are both HWP_REQUEST and HWP_REQUEST_PKG
MSRs, for example. Which one is (to be) used looks to be controlled by
HWP_CTL.PKG_CTL_POLARITY.

> @@ -462,10 +460,8 @@ static int cf_check hwp_cpufreq_cpu_init(struct cpufreq_policy *policy)
>  
>  static int cf_check hwp_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>  {
> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, policy->cpu);
> -
> -    per_cpu(hwp_drv_data, policy->cpu) = NULL;
> -    xfree(data);
> +    if ( policy->u.hwp )
> +        XFREE(policy->u.hwp);

No if() needed here.

> @@ -480,7 +476,7 @@ static int cf_check hwp_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>  static void cf_check hwp_set_misc_turbo(void *info)
>  {
>      const struct cpufreq_policy *policy = info;
> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, policy->cpu);
> +    struct hwp_drv_data *data = policy->u.hwp;
>      uint64_t msr;
>  
>      data->ret = 0;
> @@ -511,7 +507,7 @@ static int cf_check hwp_cpufreq_update(unsigned int cpu, struct cpufreq_policy *
>  {
>      on_selected_cpus(cpumask_of(cpu), hwp_set_misc_turbo, policy, 1);
>  
> -    return per_cpu(hwp_drv_data, cpu)->ret;
> +    return policy->u.hwp->ret;
>  }
>  #endif /* CONFIG_PM_OP */

Same concern here wrt MSR scope. MISC_ENABLE.TURBO_DISENGAGE's scope is
package as per the few tables which have the bit explicitly explained;
whether that extends to all models is unclear.

> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -62,6 +62,7 @@ struct perf_limits {
>      uint32_t min_policy_pct;
>  };
>  
> +struct hwp_drv_data;

This shouldn't be needed.

> @@ -81,6 +82,11 @@ struct cpufreq_policy {
>      int8_t              turbo;  /* tristate flag: 0 for unsupported
>                                   * -1 for disable, 1 for enabled
>                                   * See CPUFREQ_TURBO_* below for defines */
> +    union {
> +#ifdef CONFIG_INTEL
> +        struct hwp_drv_data *hwp; /* Driver data for Intel HWP */
> +#endif

While it may make for a smaller diff, ultimately I think we don't want
this to be a pointer, much like I've done in my patch for the ACPI driver.

> +    } u;

This wants to either not have a name at all, or be named e.g. drv_data.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:04:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:04:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109919.1459290 (Exim 4.92)
	(envelope-from )
	id 1uu8hV-0002Td-CL; Thu, 04 Sep 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 1109919.1459290; Thu, 04 Sep 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 1uu8hV-0002TW-9X; Thu, 04 Sep 2025 12:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1109919;
 Thu, 04 Sep 2025 12:04: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 1uu8hT-0002TQ-Jm
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:04:23 +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 4a5fa8eb-8987-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:04:21 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b043a33b060so148467466b.1
 for ; Thu, 04 Sep 2025 05: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
 a640c23a62f3a-b046d420e02sm352793066b.39.2025.09.04.05.04.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05: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: 4a5fa8eb-8987-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756987461; x=1757592261; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QXF2UONQ4ZIDiDV0wjlL23WDx+zGfbFqE9iBllcFLg4=;
        b=UEn5pxi8+eP8ifrFlRDeEBs1LU1oCt3zHobwj6fh/9YuwTDzE1K+QP1L9Q2TqRNmsf
         dHL5kmHAmN++A+yDMsYHTc/KcWBjfkW/qHbir2ffs0e0LTDL9hCGawZy0r3l3qDZ0jyD
         gvLYVYdl0jc9tkFfiWeV6uFgt+smfTrSDP83O4q9HdWak6Cxqi/XUblSmzSJ3INIR8i3
         YQZj2PbNp/ocrV1jlkECa06ectNupzNdXnZgaHgO0xPik0L1qSGQ5JBr3BwH4OxPZ5Nk
         Y5KBPcjZBCMCyGmRHp7VXsoAAlrX7kRJAk+/x+xBp+pc3NpFCXyNckRfBxDo12GfJXaZ
         vL5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756987461; x=1757592261;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QXF2UONQ4ZIDiDV0wjlL23WDx+zGfbFqE9iBllcFLg4=;
        b=kMTvZ6wUuLtK42eDabna5ggV77SoBtPXa5ByFEtfaTSMLEJu+AIj9NaRa28lDdt/oX
         aeshWZ2jVmsKbvCpNQQhkbjHIA/EGqMe4b55Mmfv727ili7DC5qK7mjAWWDAJarkAgAw
         iFrAnRZ48P56xed767/XNmLxIF96Ju31K0EVXUBbWrTUYxY4QenDezq2ZGG7Au4zeCvC
         9MnT98Q39zv03OFK3nZIhCc32azBHPnF+Ki6fQkUwekykwkN4lMxJZx/eP0uwBAqIN94
         C6h6EUFXfDAnENURCEFR1gE5huvwj1dUDo4SzsS6m+avduRIEBtxNy0mXnloqE01LMLG
         H4EQ==
X-Forwarded-Encrypted: i=1; AJvYcCXGyA5TsgxmP2FTrYqlUYPRWUCVsHdCOAqB9mehG/yG3n2fD2z1zRIS+ZWM2qqGduHZYNUVCMnyaOA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyA07NGNyvxEpAR7fU+RPk0oC5qcUH6xSOnzNb5jSrO3r6a+JuC
	YShCObMCNDykWWcCl7vybLZr/I/l00jQ6opfzipa9lf3QO4ybRi2I1FlU+HDNbJ5uA==
X-Gm-Gg: ASbGncu2EAL4GL1mYKdkWmHZCFjEJcGNCu4s1wgE0b5bzxEyzTUQ9gU+B1MEAMAtS3T
	hR4aIjbsCFkLu7hrFvx8G6n7DLXUkJSfhtuxDxucZnO13r0FV2Qnsfh7XKoaZ+tJzGXJvwWO6Aj
	4TSHKnyouHyG9CUlz+WNw3O9ChXNJhHAVSwqX9YesuO5UtrO8jMEG2QpQgTn+6LGcyRn3dHL7h9
	UihjYBwZTsqpxb3e7VzNqThvQonPOyDJCbdbrYPc7fl8E/YTPvK2MiI9IfNoMsRxLls5FbglinP
	8YyZVwmfvPsOWvLZEBGhECtXo5t39axWgBZhwmfEQZnAIeBfYAL+FHffJQ2DAzAJqzWn4GwKDtD
	v2xjmtN5RtxvytTmiUtZCQ/1tkb55bzJbYsL6KCPH4oAebNBIsrf2VUUAmwAJAvZtMb/nkrHHqg
	ojt2MHzYG4HGhS3gL/Y1UHIgtM1pGG
X-Google-Smtp-Source: AGHT+IE9vR2mOufoW5dEWF5p7stxol9hpASE4+Ky+04nHLfeIPOginWYpLh05m7KeVuBDJpaiAFZpg==
X-Received: by 2002:a17:907:3e11:b0:b04:65b4:711 with SMTP id a640c23a62f3a-b0465b40a87mr715730166b.57.1756987460553;
        Thu, 04 Sep 2025 05:04:20 -0700 (PDT)
Message-ID: <7e769952-a906-4a3e-af27-26faa76f6dd4@suse.com>
Date: Thu, 4 Sep 2025 14:04:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in
 passive mode
To: Penny Zheng 
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: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-3-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.09.2025 08:35, Penny Zheng wrote:
> amd-cppc is the AMD CPU performance scaling driver that introduces a
> new CPU frequency control mechanism. The new mechanism is based on
> Collaborative Processor Performance Control (CPPC) which is a finer grain
> frequency management than legacy ACPI hardware P-States.
> Current AMD CPU platforms are using the ACPI P-states driver to
> manage CPU frequency and clocks with switching only in 3 P-states, while the
> new amd-cppc allows a more flexible, low-latency interface for Xen
> to directly communicate the performance hints to hardware.
> 
> "amd-cppc" driver is responsible for implementing CPPC in passive mode, which
> still leverages Xen governors such as *ondemand*, *performance*, etc, to
> calculate the performance hints. In the future, we will introduce an advanced
> active mode to enable autonomous performence level selection.
> 
> Field epp, energy performance preference, which only has meaning when active
> mode is enabled and will be introduced later in details, so we read
> pre-defined BIOS value for it in passive mode.
> 
> Signed-off-by: Penny Zheng 
> Acked-by: Jan Beulich 

With the issue I had pointed out, leading to ...

> ---
> v8 -> v9
> - embed struct amd_cppc_drv_data{} into struct cpufreq_policy{}

... this change, I think the tag would have needed to be dropped.

> +static void cf_check amd_cppc_write_request_msrs(void *info)
> +{
> +    const struct amd_cppc_drv_data *data = info;
> +
> +    wrmsrl(MSR_AMD_CPPC_REQ, data->req.raw);
> +}
> +
> +static void amd_cppc_write_request(unsigned int cpu,
> +                                   struct amd_cppc_drv_data *data,
> +                                   uint8_t min_perf, uint8_t des_perf,
> +                                   uint8_t max_perf, uint8_t epp)
> +{
> +    uint64_t prev = data->req.raw;
> +
> +    data->req.min_perf = min_perf;
> +    data->req.max_perf = max_perf;
> +    data->req.des_perf = des_perf;
> +    data->req.epp = epp;
> +
> +    if ( prev == data->req.raw )
> +        return;
> +
> +    on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs, data, 1);

With "cpu" coming from ...

> +}
> +
> +static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
> +                                            unsigned int target_freq,
> +                                            unsigned int relation)
> +{
> +    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
> +    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;
> +
> +    /*
> +     * Having a performance level lower than the lowest nonlinear
> +     * performance level, such as, lowest_perf <= perf <= lowest_nonliner_perf,
> +     * may actually cause an efficiency penalty, So when deciding the min_perf
> +     * value, we prefer lowest nonlinear performance over lowest performance.
> +     */
> +    amd_cppc_write_request(policy->cpu, data, data->caps.lowest_nonlinear_perf,

... here, how can this work when this particular CPU isn't online anymore?

> +                           des_perf, data->caps.highest_perf,
> +                           /* Pre-defined BIOS value for passive mode */
> +                           per_cpu(epp_init, policy->cpu));
> +    return 0;
> +}
> +
> +static void cf_check amd_cppc_init_msrs(void *info)
> +{
> +    struct cpufreq_policy *policy = info;
> +    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
> +    uint64_t val;
> +    unsigned int min_freq = 0, nominal_freq = 0, max_freq;
> +
> +    /* Package level MSR */
> +    rdmsrl(MSR_AMD_CPPC_ENABLE, val);

Here you clarify the scope, yet what about ...

> +    /*
> +     * Only when Enable bit is on, the hardware will calculate the processor’s
> +     * performance capabilities and initialize the performance level fields in
> +     * the CPPC capability registers.
> +     */
> +    if ( !(val & AMD_CPPC_ENABLE) )
> +    {
> +        val |= AMD_CPPC_ENABLE;
> +        wrmsrl(MSR_AMD_CPPC_ENABLE, val);
> +    }
> +
> +    rdmsrl(MSR_AMD_CPPC_CAP1, data->caps.raw);

... this and ...

> +    if ( data->caps.highest_perf == 0 || data->caps.lowest_perf == 0 ||
> +         data->caps.nominal_perf == 0 || data->caps.lowest_nonlinear_perf == 0 ||
> +         data->caps.lowest_perf > data->caps.lowest_nonlinear_perf ||
> +         data->caps.lowest_nonlinear_perf > data->caps.nominal_perf ||
> +         data->caps.nominal_perf > data->caps.highest_perf )
> +    {
> +        amd_cppc_err(policy->cpu,
> +                     "Out of range values: highest(%u), lowest(%u), nominal(%u), lowest_nonlinear(%u)\n",
> +                     data->caps.highest_perf, data->caps.lowest_perf,
> +                     data->caps.nominal_perf, data->caps.lowest_nonlinear_perf);
> +        goto err;
> +    }
> +
> +    amd_process_freq(&cpu_data[policy->cpu],
> +                     NULL, NULL, &this_cpu(pxfreq_mhz));
> +
> +    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.lowest_mhz,
> +                                 data->caps.lowest_perf, &min_freq);
> +    if ( data->err )
> +        return;
> +
> +    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
> +                                 data->caps.nominal_perf, &nominal_freq);
> +    if ( data->err )
> +        return;
> +
> +    data->err = amd_get_max_freq(data, &max_freq);
> +    if ( data->err )
> +        return;
> +
> +    if ( min_freq > nominal_freq || nominal_freq > max_freq )
> +    {
> +        amd_cppc_err(policy->cpu,
> +                     "min(%u), or max(%u), or nominal(%u) freq value is incorrect\n",
> +                     min_freq, max_freq, nominal_freq);
> +        goto err;
> +    }
> +
> +    policy->min = min_freq;
> +    policy->max = max_freq;
> +
> +    policy->cpuinfo.min_freq = min_freq;
> +    policy->cpuinfo.max_freq = max_freq;
> +    policy->cpuinfo.perf_freq = nominal_freq;
> +    /*
> +     * Set after policy->cpuinfo.perf_freq, as we are taking
> +     * APERF/MPERF average frequency as current frequency.
> +     */
> +    policy->cur = cpufreq_driver_getavg(policy->cpu, GOV_GETAVG);
> +
> +    /* Store pre-defined BIOS value for passive mode */
> +    rdmsrl(MSR_AMD_CPPC_REQ, val);

... this?

> +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;
> +    policy->u.amd_cppc = data;
> +
> +    data->cppc_data = &processor_pminfo[cpu]->cppc_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 is taken effective, not only amd-cppc cpufreq core fails
> +     * 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 core in CPPC mode\n");
> +        amd_cppc_cpufreq_cpu_exit(policy);
> +        return data->err;

amd_cppc_cpufreq_cpu_exit() has already freed what data points to.

> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -63,6 +63,7 @@ struct perf_limits {
>  };
>  
>  struct hwp_drv_data;
> +struct amd_cppc_drv_data;
>  struct cpufreq_policy {
>      cpumask_var_t       cpus;          /* affected CPUs */
>      unsigned int        shared_type;   /* ANY or ALL affected CPUs
> @@ -85,6 +86,9 @@ struct cpufreq_policy {
>      union {
>  #ifdef CONFIG_INTEL
>          struct hwp_drv_data *hwp; /* Driver data for Intel HWP */
> +#endif
> +#ifdef CONFIG_AMD
> +        struct amd_cppc_drv_data *amd_cppc; /* Driver data for AMD CPPC */
>  #endif
>      } u;
>  };

Same comments here as for the HWP patch.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:11:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:11:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109931.1459301 (Exim 4.92)
	(envelope-from )
	id 1uu8oV-00043u-2i; Thu, 04 Sep 2025 12:11:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109931.1459301; Thu, 04 Sep 2025 12: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 1uu8oU-00043l-W9; Thu, 04 Sep 2025 12:11:38 +0000
Received: by outflank-mailman (input) for mailman id 1109931;
 Thu, 04 Sep 2025 12:11: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 1uu8oT-00043c-A3
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:11:37 +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 4cf387e0-8988-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:11:34 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-afec5651966so185028366b.2
 for ; Thu, 04 Sep 2025 05:11: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
 a640c23a62f3a-b0470f11088sm298889166b.111.2025.09.04.05.11.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05: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: 4cf387e0-8988-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756987894; x=1757592694; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8Q3EHp9v6FdnZ7sKhzqDgygy/4jbvc7hiANoP2TGvuk=;
        b=be1QH5upUK+tlQjMsAyei6n0z6/ScUatu/Tk0qMAPR2YGz6NXVCNiC7dzM0m1q5wlj
         19qtd1Zro0VZACeePz/L8cPzfi6mbujnzTW6qUhDLKpAXN5uiiB7A4a60wRzvv/7FIT+
         NUk+sCIIRIIaldHhuI634aLyk6qpATVayNQ4NNg2kN0FHdh2u3dq/wgu43HVNP8tvLaj
         dfkH9j85otiunwf0BTi2GFHQqZt59K0RKrdi8bTc7o68TaS9s0wgstoxgH8y62etTRgb
         t+bimGAkhLYw2+zZXzy/9eq5hRGLJBcbNsIHS7+zT+l4nZGIddR2usiAHaS5c03c0t08
         Gs4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756987894; x=1757592694;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8Q3EHp9v6FdnZ7sKhzqDgygy/4jbvc7hiANoP2TGvuk=;
        b=C9UXkA+VubpLVzTlzjN5C8GjRWwcrnSi4617EtzScvjBZFYVtR+eGJ/0X+e75DBJR4
         uJVVu0rg1F0SyYztluJD4dFfsn39qad8c9sbIBV3GexvqN0348yBEMcXhZS06rOAgOAI
         YipyM7gEPr3UewtzpNrM+IjFFRdNu65Wh2les8KD/eJa78xkWBFvHnxRYUH/wAaSnQ1R
         pqde0LEFooDG9nXJdcF/pjZxZj8hmOcxM2C7PGwV7XfV2J6Fmo41wcTXjqBiDUmdcT7C
         EOpsRxpyB1WX+2/1WbteW5SWqtTiD7nTplSrS1vS4U/ha9KhSBoQnrpwo8dV7IU4d2BN
         +L0Q==
X-Forwarded-Encrypted: i=1; AJvYcCWdWRXNiCmXfSQroEJOzKOc8XZ9GTy3EiZPc5zFdW+z8GU8IbJpAgG73XV3sCaRRTaBnhXDxBKKAy0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxv+NwlBt5mp5QMxqNj4aE0ZNiSftoVMjqTpCrolTDNLC1dD+2w
	eTBSfIHAAS+eL5mvJCHDNMkqskJYQ1YxNWeqlNSrGWqPKO9Fc0aVtp6PC4kBlNVFNw==
X-Gm-Gg: ASbGncvHwsNY4LdEk4cgwU/fd4jSmZkz+hnwRnw3c5W0sTYmpzuR5NCRE8Pw1iIoCc3
	imkQzDITw4MclZcP3Oc+hNH/jvQpBFNMQLoopESfo2ZEgEtQT6o2kVvrxZzVeXm7cw93NIsQly5
	R+jLe94FsTNVVl7vVTkwhQQEgNo8Gbu8u/SuA/ItGW7hAlqbBwbBthVWrq+VKT1I9MsFVOFcCk+
	UEEYmyXn3aNqenErSVV2sPCqosH2kbx0mMNr1fpvu5H676MRcf0AkOUUo7sxBYLJ+e4nHu5xXI+
	lacKrxNH+tgJ1VTfh3LHSMrKnTnY62ZfuISEJBle3h7kl1kPmNnbTwUkJbU2oa6vxgIsCcxf+eV
	kuWWP4/LMvcAhIjUeW9uNzA47liacvRrm+ktXbI2J3uCgGva5Zy44+oihCRS5bK+QazOlRnLjsv
	lXpe+lJ/U=
X-Google-Smtp-Source: AGHT+IHkUcuqwzDVqhNhZE8NGgCet4Xtlfsz24oRz6u9rPdnIXCZTAFmc9X68dABcGkOcJ9XRzzqBw==
X-Received: by 2002:a17:906:4fca:b0:b04:6546:347e with SMTP id a640c23a62f3a-b0465463a5bmr659419766b.51.1756987894499;
        Thu, 04 Sep 2025 05:11:34 -0700 (PDT)
Message-ID: <71560c55-b3e7-4049-bf7d-5474982c76dd@suse.com>
Date: Thu, 4 Sep 2025 14:11:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in
 passive mode
To: Penny Zheng 
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: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-3-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, Penny Zheng wrote:
> @@ -50,10 +139,333 @@ 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 &&
> +         data->caps.nominal_perf > data->caps.lowest_perf &&
> +         cppc_data->cpc.nominal_mhz > cppc_data->cpc.lowest_mhz )
> +    {
> +        mul = data->caps.nominal_perf - data->caps.lowest_perf;
> +        div = cppc_data->cpc.nominal_mhz - cppc_data->cpc.lowest_mhz;
> +
> +        /*
> +         * 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);

How do you know you ever initialized this instance of the per-CPU variable?
amd_cppc_init_msrs() may never have run for this particular CPU.

> +static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
> +                                            unsigned int target_freq,
> +                                            unsigned int relation)
> +{
> +    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
> +    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;
> +
> +    /*
> +     * Having a performance level lower than the lowest nonlinear
> +     * performance level, such as, lowest_perf <= perf <= lowest_nonliner_perf,
> +     * may actually cause an efficiency penalty, So when deciding the min_perf
> +     * value, we prefer lowest nonlinear performance over lowest performance.
> +     */
> +    amd_cppc_write_request(policy->cpu, data, data->caps.lowest_nonlinear_perf,
> +                           des_perf, data->caps.highest_perf,
> +                           /* Pre-defined BIOS value for passive mode */
> +                           per_cpu(epp_init, policy->cpu));

This may access per-CPU data of an offline CPU.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:13:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:13:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109942.1459312 (Exim 4.92)
	(envelope-from )
	id 1uu8pn-0004Yu-EK; Thu, 04 Sep 2025 12:12:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109942.1459312; Thu, 04 Sep 2025 12:12: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 1uu8pn-0004Yh-9u; Thu, 04 Sep 2025 12:12:59 +0000
Received: by outflank-mailman (input) for mailman id 1109942;
 Thu, 04 Sep 2025 12: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 1uu8pm-0004Yb-JM
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:12:58 +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 7d97b526-8988-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:12:56 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6188b5ad4f0so1646159a12.0
 for ; Thu, 04 Sep 2025 05:12: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
 4fb4d7f45d1cf-61cfc51e0c1sm13979947a12.42.2025.09.04.05.12.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05:12: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: 7d97b526-8988-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756987976; x=1757592776; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nOBEWNFFHPjnbNq4i67ABuyUthOxE9J2j5V1Te/Ttdk=;
        b=VYjvtrZ2fscMfYuUcSqOVs0GXZ9gG3PL8MEZSXv7edqlIpuSnWsIonZNlccDviIXqB
         3uTKOFx+JP0xOXJXwfgxIk4ogngObFHUQZbHfmlvpJyB/LjCnGfkwvp9aM8Xems97hIj
         pF1EbrnfzLtgEVS+IwDy252vfOUZibPcCnyQ5iEmO0VeWSMJwwvchg/cUgYV7wOFVfk3
         i5oGcZC27nI4wardf4m87+gBwg3yguL4PzK4aGP1rpE0wmISjmX2BKm+xDJCiWgNKwZM
         9bBTMDGJu1IaSyEoJBQUhEnR+0TvDFBAyIiRJLdgfzJPuXJif7kcRrSqziAUPhrl7W3E
         Mi2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756987976; x=1757592776;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nOBEWNFFHPjnbNq4i67ABuyUthOxE9J2j5V1Te/Ttdk=;
        b=F1lfI301EKjE8dhPmhjzHH3ubmIWXDv09nCY528auylD3K2POHTjUIIOhuHoYmmgnp
         qZsID+7X2oi5h4T7zCfg/RgWJN1S+Fipm8QlwcUJXOCTC8WiUGQKwR5vQlp10b71tPvJ
         RIvWd1dilivkNaxEqXCWGE8Fmx7eML69iqf8BiSy97wi1IL/tqKD6CL5iywV25R7KPLU
         FB6zdweOJteiJnt+BMA3G8tf0jwXx0f9G4H9bevBoKge0ODrm6Dasm9fKba6cTCgxT13
         ky766HTQ0XJm8lEPr334h6dPkL/meRTZ9KHdlSxNfU8TTwbNitT96SbKlmFRo1querPW
         UDKw==
X-Forwarded-Encrypted: i=1; AJvYcCVr9a1c3qfS9QDIslSKy0mJSDc8QXEmSo1LVP2ZW6Uytl/zuYgXYGEujEFKW2PC/gUVNfbuhTPNaoA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyFJ5BuzxTL4j1Yst+cLYKmCanLkqFn3CfG1JBe3qB0LUQU9S/Y
	/K+fEZGrhd0iAQrGN5Mj5kjM3vHtzvwC7U5zZxKNtP9nV0nbZwFp7VPdwoGpygQ9mA==
X-Gm-Gg: ASbGncuYcDyKUs0vHgb1yHli7omp42m+Ng5TK9CcBdgZp9outT1fZlL7ujnSx2uMqIm
	yKam3OnUOxlNWSJAWseu1KyAPoJaxaIcM0irLGym37rrrEf58t0DiA9gLJ1k75Z2cnV/TZo5frP
	OG38eCrYUo9caDs5KN7xA4ywNVnGMEqgkN+LcQ5lA16LTDfG2rvH7Fe33boSg4u2uphkPYFVQkC
	G4buZC1oClSgZUQE0QKvT6XMofBf+WqbU51cLCAJ334wO83z5apcAaZbyaTlRkjwf+1T2Vd0Ysi
	Fpv8a8rTSIUruHH8mJYsV+fEDO2erIXhx3JnWIrpw59PeYvGlS4AWaXpNHyr8sqgz7M0gMF/ARF
	KkS03kAey6F+LxMKwzbk3CzSk18ete4nBneExMGL9cxGcFW2sWAR486y735P8MFUfhejhzn8xZb
	a6u86jDiw=
X-Google-Smtp-Source: AGHT+IFT/+IREivLHHAl0YQHtnZpANlRv7fpvIMIt389jc9BAEBskf1NeQHaCQEoTKr+xpftH/SdyA==
X-Received: by 2002:a05:6402:4345:b0:61c:5440:ff7b with SMTP id 4fb4d7f45d1cf-61d26eac5b6mr16848524a12.25.1756987976176;
        Thu, 04 Sep 2025 05:12:56 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 14:12:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 3/8] xen/cpufreq: implement amd-cppc-epp driver for
 CPPC in active mode
To: Penny Zheng 
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: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-4-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, Penny Zheng wrote:
> ---
> v8 -> v9:
> - Adapt to changes of "Embed struct amd_cppc_drv_data{} into struct
> cpufreq_policy{}"

With problems mentioned there also extending here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:26:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:26:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109965.1459321 (Exim 4.92)
	(envelope-from )
	id 1uu93D-0006Lz-Kw; Thu, 04 Sep 2025 12:26:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109965.1459321; Thu, 04 Sep 2025 12:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu93D-0006Ls-Hm; Thu, 04 Sep 2025 12:26:51 +0000
Received: by outflank-mailman (input) for mailman id 1109965;
 Thu, 04 Sep 2025 12:26:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uu93C-0006Lm-Sj
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:26:50 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6de1115b-898a-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 14:26:49 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-61cf8280f02so1367598a12.0
 for ; Thu, 04 Sep 2025 05:26: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
 4fb4d7f45d1cf-61cfc4bbc51sm13901945a12.27.2025.09.04.05.26.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05:26: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: 6de1115b-898a-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756988808; x=1757593608; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XNX2HRvMEi5y+i4pXQz5zgydtrI2YMz4JAmIh8Fhxf0=;
        b=MlgaWAdcfputkfECWT7OxMyxuvlPRBZtY53+E496Zvr7TfZNSzeKpNape1Fgpj1KTe
         pSwGySfUF3VHkRIykJd05EkmkyKfGhD/gecBrDlA4TtmQ3JIvAZ0xVS/BohqpRBpP53j
         cRqzUnee6yLd6/U155merePheNL5LKInINt5Qj3QvF7GyNsyXWZwX0W4xQUnwVoyirUT
         LmZ2uHeHUcmGdhAp+HR+x2HrZbLe6e9lHb1SEJbZSU3abWZfHsjnZf9Ei2+Vbj7jvOO/
         8CqOzqJVBMEedTvSGHxDKESmIt/8ZWb9giJV7ephDbk/HIXwqy/UIz4x6lM2D7SWSoU1
         fKZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756988808; x=1757593608;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XNX2HRvMEi5y+i4pXQz5zgydtrI2YMz4JAmIh8Fhxf0=;
        b=JRxJP1v0SYcCPH7JqT36FVmVdz0B28iVtDOiO+sKkVs+XIY9g4OgTZgVsdFDlC0yU4
         BmSvdAZlK6226B3Cco182oBOyPUybqRpHAOP1ErHCmNrw0kA+cUu9Uodp8+GgPZct8T7
         AGeBbsL9ihGNP2SbFPKvG2NQncy9dVE+L1HVTP6AGdA5lVrgw4KwUBkBfMXw6STUx566
         aasCQdcJ7PQLw+BaXHV8/1UjF4sJuafzRmSe5O+inqDPGtmg2Q2ENJJME1aoPY0iybKu
         jRdEt17FEkGsZlgznMyIbUVYzbTzzZvYaSBUCMtpSvlvWzx2PErsugbdomHUk5SYO3Wx
         ixZw==
X-Forwarded-Encrypted: i=1; AJvYcCWxN+9NZSsmTcy2acT7L8eztKYJFpXIxazcwOZCoEsSrTSS5YItiMrUpr+Sw3UQBXciLo9AH+2hS7M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWcjsu4iFZTajfeTa3LJFskLrrasgbyDpNGCERZlsj+cOb8tVh
	3ypBknacM7qZXfW6KFpekOHHCtawSS6JGpsZnJv16kQZ2uqQPCl3ZFP3ILas2/injw==
X-Gm-Gg: ASbGncthpxesu2xh8CrnJfWSlmT+i0lxITP9ZHGlBakWcDP5/Rmn9fLGqegzrKiF2L8
	MElNTd4LwJvlkp+DdWr1oOw+OmbAPphpF7GVXQ/HCSQN6wYFcEXAt+DCsvC/eQWESgtWK3GEcVQ
	iwU4X0H54uhE35R+gDCfLlVdPUDyIl9bzQR+i5MjpWMN8NxCcHxw2nff7HWbzSP8t8J/EzAKI+q
	GD/VrDqBTNGhrk9HjaOSwfDB8velNYW7QkqG5ZHxzdecOJ3hNvhJvtNBvWkhmQkA/oPutEyJHjH
	wftJcq5n11MZDNbuMiWgH/yY4336twcCfEkjwLJoLJaBwslsKxh0I/KYZZ+EPjIbH1FlOr24Fhq
	hsSjq6UAdI6a5W8iSjJOXL5oGcp/TmuddHIV44ZFHXD29SVgTpy6Fsua2JAk9EeWN7tgWdabrDr
	jjxQ6jG7tjZ2MoRwvvqg==
X-Google-Smtp-Source: AGHT+IGRGxHkCR7V7xWervRFwYHMkNpFFiZAM0Oc4tHlJgeZxvC0/JlQ8PAbJnKm90JilP+lry15/Q==
X-Received: by 2002:a05:6402:3594:b0:61d:3e6a:197d with SMTP id 4fb4d7f45d1cf-61d3e6a198dmr14978452a12.22.1756988808480;
        Thu, 04 Sep 2025 05:26:48 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 14:26:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 5/8] tools/cpufreq: extract CPPC para from cpufreq para
To: Penny Zheng 
Cc: 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: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-6-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, Penny Zheng wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -492,7 +492,6 @@ struct xen_get_cpufreq_para {
>                  struct  xen_ondemand ondemand;
>              } u;
>          } s;
> -        struct xen_get_cppc_para cppc_para;
>      } u;

Which means the outer union could now be dropped as well. Which may help
proving (or perhaps even easily seeing) the safety of the change you're
making in patch 7.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:27:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:27:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109975.1459332 (Exim 4.92)
	(envelope-from )
	id 1uu941-0006q3-VH; Thu, 04 Sep 2025 12:27:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109975.1459332; Thu, 04 Sep 2025 12: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 1uu941-0006pw-RN; Thu, 04 Sep 2025 12:27:41 +0000
Received: by outflank-mailman (input) for mailman id 1109975;
 Thu, 04 Sep 2025 12:27:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uu940-0006pq-So
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:27:40 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uu93z-006Fkm-36;
 Thu, 04 Sep 2025 12:27:40 +0000
Received: from [15.248.2.239] (helo=[10.24.66.11])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uu93z-00FciN-35;
 Thu, 04 Sep 2025 12:27: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" 
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=T+Zq41eU3r7K9a6K3BFpgPe5HFtMwk8xVNxx3+KkcMY=; b=C1IycG5X+0oBrlqfVB3U4cJRc5
	6NJbwRMCIQqd7EJGy/bDD85VJU48gorUOP8hsbU/c81CGoXquDKTGbhQg92t0qxTlKDcAcU1onCZl
	2zesY0o+pZk/sT/4WNJbBKhFhVUW8RaOgWMjUjAdj1Wpx/ESmRNHXuC5rFmGwixN/vNc=;
Message-ID: 
Date: Thu, 4 Sep 2025 13:27:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 03/09/2025 15:29, Leonid Komarianskyi wrote:
> ---
>   xen/arch/arm/Kconfig           |  8 +++++
>   xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
>   xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
>   3 files changed, 96 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 17df147b25..43b05533b1 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -135,6 +135,14 @@ config GICV3
>   	  Driver for the ARM Generic Interrupt Controller v3.
>   	  If unsure, use the default setting.
>   
> +config GICV3_ESPI
> +	bool "Extended SPI range support"
> +	depends on GICV3 && !NEW_VGIC
> +	help
> +	  Allow Xen and domains to use interrupt numbers from the extended SPI
> +	  range, from 4096 to 5119. This feature is introduced in GICv3.1
> +	  architecture.
> +
>   config HAS_ITS
>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>           depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
> index 5bc6475eb4..f4d0997651 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>   #define SPI_MAX_INTID   1019
>   #define LPI_OFFSET      8192
>   
> +#define ESPI_BASE_INTID 4096
> +#define ESPI_MAX_INTID  5119
> +#define NR_ESPI_IRQS    1024
> +
>   /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */
>   #define INVALID_LPI     0
>   
> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>   #define INVALID_IRQ     1023
>   
>   extern const unsigned int nr_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +/* This will cover the eSPI range, to allow asignmant of eSPIs to domains. */
> +#define nr_static_irqs (ESPI_MAX_INTID + 1)
> +#else
>   #define nr_static_irqs NR_IRQS
> +#endif
>   
>   struct irq_desc;
>   struct irqaction;
> @@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
>       return irq >= LPI_OFFSET;
>   }
>   
> +static inline unsigned int espi_intid_to_idx(unsigned int intid)
> +{
> +    ASSERT(intid >= ESPI_BASE_INTID && intid <= ESPI_MAX_INTID);

Can we use is_espi()?

> +    return intid - ESPI_BASE_INTID;
> +}
> +
> +static inline unsigned int espi_idx_to_intid(unsigned int idx)
> +{
> +    ASSERT(idx <= NR_ESPI_IRQS);
> +    return idx + ESPI_BASE_INTID;
> +}
> +
> +static inline bool is_espi(unsigned int irq)
> +{
> +#ifdef CONFIG_GICV3_ESPI
> +    return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID;
> +#else
> +    /*
> +     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is
> +     * disabled. Returning false allows the compiler to optimize the code
> +     * when the config is disabled, while the assert ensures that out-of-range
> +     * array resources are not accessed, e.g., in __irq_to_desc().
> +     */
> +    ASSERT(irq >= ESPI_BASE_INTID);

Regardless what Volodymyr mentioned about the assert!(), I am a bit 
unsure where we guarantee is_espi() will not be called with an irq <= 
ESPI_BASE_INTID. In fact, we could have the following code in Xen:

if (is_espi(irq))
{
}
else if (is_lpi(irq))
{
}
else
{
}

We could replace the check with "!(irq >= ESPI_BASE_INTID && irq <= 
ESPI_MAX_INTID)". But I would actually prefer if there is no check 
because I don't see the value.

> +    return false;
> +#endif
> +}
> +

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:30:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1109986.1459340 (Exim 4.92)
	(envelope-from )
	id 1uu96a-0008MI-Ap; Thu, 04 Sep 2025 12:30:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1109986.1459340; Thu, 04 Sep 2025 12: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 1uu96a-0008MB-7v; Thu, 04 Sep 2025 12:30:20 +0000
Received: by outflank-mailman (input) for mailman id 1109986;
 Thu, 04 Sep 2025 12:30: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 1uu96Y-0008M5-Fg
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:30:18 +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 e974adba-898a-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:30:16 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-61cb4374d2fso1431967a12.2
 for ; Thu, 04 Sep 2025 05:30: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
 4fb4d7f45d1cf-61ded4749aesm10028832a12.32.2025.09.04.05.30.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05:30: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: e974adba-898a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756989016; x=1757593816; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Zx/hmlFxLP2KrveGa5u82+pZv7SJoB//hblsQ8YInIM=;
        b=SQnjVtHtB2DOMlZ8zib5eCOIcmQ6RoyUWfUYa/MZUJxFLba0bBzhbL36Ey2LKmWUQX
         hyBJX3RZUS3LGhnMHY0xf+Xz3elANd+DW9FBk32QIA9E1DBBLEOJVvk+iHcOLZisvFr0
         IE/C/QPtwzJcQYhttwoBiCIxZtwxF0qqwQVBDDUp4mPHyqMgsUeXEhJ0Vz2M2/DyZS8E
         qj7x0ngftThQpW9/D/vfgJLL2vBXNg2VcO6LikQeoSqSdbPk57fxDDmKKrSOBKF/HZ0R
         ihKINY0qT5iuhStzeF6Z6Ih38cccNaRIRVVyBE6DfBlDx/XtTFlQBErNKcMq88CSWWjV
         5gMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756989016; x=1757593816;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Zx/hmlFxLP2KrveGa5u82+pZv7SJoB//hblsQ8YInIM=;
        b=LAiaDBzS6GQb8YGZRJsMhnUNfCE5aiux7yNnITCsDJ0l9m45aaKjMpOjVsaHraQ6/s
         NsYhk51tlO0p69r9JwN+3NX5mO5NP2G3NLv56wnzvPfDIy8a+AqsnKlNrWkz7mHMqT9D
         MO/3Y0wNck41RT6+/YqYuH0UOIb3otyZNAk8QtHDo4Y01snKHgeivvO9AoQ7khoUNixG
         nrD+6wSYsRup4hi+DAzIVaXY43FmVQ43j23vdkcB2hzACRLsIeHB5yTRrxG3vJD7NHeC
         gW75oLKUIFgZnRCZ992QdTpaURv5mHV1T7rBqbXVSrYznC88gWvUVF6jfEMOKf4JE6Z+
         5XNg==
X-Forwarded-Encrypted: i=1; AJvYcCUAGJ+on5WHYb4mLerCdRjJLD3HPeBCN6VoNidsxIjQJx0icgGBUy070FmQhtVaFyk4xnPHo1B5164=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy2haczN/48YxcYCN0NoQbtOli/Kgk/MFUTwjBNMI9Whhc1mhq3
	iUdeci6sN10yQwmJWIkFtj6QiZYb7/uXvk/+Gdj9nwuDDLqW1A5aD4UJm5TnONVo7A==
X-Gm-Gg: ASbGncvLxlu6aRtZnfs1N6ezEYD/ryJXEaK5SFEvtI1MSdyjDheXF0kv9lkc8Cr1Vbr
	t7tz688rFzjX0/+UVyIbXjddYoCxDKWm9Yddc6D4LS8uqhML3UypYcDvg1GFmSifUn8ODWq2NfF
	YdNu3jVFa5XShI2PfSXfWbe7++QH8WQI/7/2U3oqtRwMba8wTsnBGKFzaG60ce0tVzSncmJoEQQ
	xWgVLpSstm7i2kYpd07OuxmECxt2hcmF1fteGv1DQo5/jkO+OiYzkTsn3vjGt7XQfTx1yrxl48i
	MBCY7AOlf+hk81pW8W3IDx9Zpj/cMh2lvRrgV8aGVMu+SdVKC0xZOHKYmTvTN7lgcb/4/YOYntC
	2mqbgfsqBJmiE/oynNGiJ6kOjCb17wm8NtrjCqkFGogAu/zb4WeILYSRbRrPnA9qh7yWuF97yYj
	eeW7ryFqI=
X-Google-Smtp-Source: AGHT+IEb6iIc0jRozbcXayisHqVHi2Y2Bp3vhP3PmwZp3Y4+epRa1lTFD8YBzS2ObwMvoArfRT7RTg==
X-Received: by 2002:a05:6402:3594:b0:61e:49dc:171f with SMTP id 4fb4d7f45d1cf-61e49dc176fmr13140088a12.1.1756989015811;
        Thu, 04 Sep 2025 05:30:15 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 14:30:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Jason Andryuk , "Penny, Zheng"
 
Cc: "Huang, Ray" ,
 Anthony PERARD ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20250828100601.1777197-1-Penny.Zheng@amd.com>
 
 
 <8ab89125-4693-4d9a-b9a3-b8ab38b1908f@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: <8ab89125-4693-4d9a-b9a3-b8ab38b1908f@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03.09.2025 20:17, Jason Andryuk wrote:
> On 2025-09-02 23:14, Penny, Zheng wrote:
>> [Public]
>>
>>> -----Original Message-----
>>> From: Jan Beulich 
>>> Sent: Thursday, August 28, 2025 7:07 PM
>>> To: Penny, Zheng 
>>> Cc: Huang, Ray ; Anthony PERARD
>>> ; Andrew Cooper ;
>>> Roger Pau Monné ; xen-devel@lists.xenproject.org
>>> Subject: Re: [PATCH v8 8/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
>>> xen_sysctl_pm_op for amd-cppc driver
>>>
>>> On 28.08.2025 12:06, Penny Zheng wrote:
>>>> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
>>> *op)
>>>>       else
>>>>           strlcpy(op->u.get_para.scaling_driver, "Unknown",
>>>> CPUFREQ_NAME_LEN);
>>>>
>>>> +    /*
>>>> +     * In CPPC active mode, we are borrowing governor field to indicate
>>>> +     * policy info.
>>>> +     */
>>>> +    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);
>>>
>>> Isn't pulling this ...
>>>
>>>>       if ( !cpufreq_is_governorless(op->cpuid) )
>>>>       {
>>>>           if ( !(scaling_available_governors =
>>>
>>> ... out of this if()'s body going to affect HWP? It's not clear to me whether that would
>>> be entirely benign.
>>>
>>
>> HWP has its own unique "hwp" governor. So, imo, it may not affect.
> 
> get_hwp_para() writes into the same union:
> op->u.get_para.u.cppc_para
> op->u.get_para.u.s.scaling_governor

Not anymore as of "tools/cpufreq: extract CPPC para from cpufreq para".

> Which is why I avoided it for hwp.
> 
> I guess writing scaling_governor first and then overwriting it still 
> ends up with the same data in cppc_para.  Seems a little messy though.
> 
> Penny, I'm confused by this comment:
> +    /*
> +     * In CPPC active mode, we are borrowing governor field to indicate
> +     * policy info.
> +     */
> 
> You have CPPC active and passive modes - which uses a governor and which 
> uses get_cppc?
> 
> It seems like only writing the scaling governor inside
> if ( !cpufreq_is_governorless )
> 
> should be correct since it's using the union.  Am I missing something?

The union is now fake; it has just a single member, and hence would better
be dropped. I've commented correspondingly on v9.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:33:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:33:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110010.1459350 (Exim 4.92)
	(envelope-from )
	id 1uu99w-0000bh-P0; Thu, 04 Sep 2025 12:33:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110010.1459350; Thu, 04 Sep 2025 12:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu99w-0000ba-MR; Thu, 04 Sep 2025 12:33:48 +0000
Received: by outflank-mailman (input) for mailman id 1110010;
 Thu, 04 Sep 2025 12:33: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 1uu99v-0000bU-8o
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:33:47 +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 65a1641e-898b-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:33:44 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-afcb7ae6ed0so155752966b.3
 for ; Thu, 04 Sep 2025 05:33: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
 a640c23a62f3a-b0413782b94sm1168239666b.35.2025.09.04.05.33.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05:33: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: 65a1641e-898b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756989224; x=1757594024; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GM/vGb8JyJ1bD/Cu90rKOQ2O/mHKMpaEJllntanhv64=;
        b=He32dxMboNM23cW6PpxScZIeswNeTZJoznDgcvH4+l4TztCFY/lLdNKZYZDQnwW4JA
         30+E43RkkGoEbBSc2N7d5cE0IRy5iCR+UGcISUlSxdwyL6JLwpuegHQexPUMbjrRWyA5
         RRVTYsR8j9JzgxSHG/4aIqXwi+ykwoQa7Mz0FvSFW+8gzZJJTer7ekCTOrmBKH5AXeeG
         18hfDfSgY/rvHW2Wpp7wFEzRmI/dzXad0GfeO0U9WYLFZasl+W5XwefInLyT0bf38/Hj
         ak2F+pNR5Euo6acK7A1ECo0pY2CcFpGnJ126zP/jjPoMXuQMlkLyMzzme5ybETp2D96/
         zA4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756989224; x=1757594024;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GM/vGb8JyJ1bD/Cu90rKOQ2O/mHKMpaEJllntanhv64=;
        b=Id1a3mETBYM5U8MRSw2unfAERpuJCVQ05ImntGnggeWafoRF7esmcn4MnK1byyFxjL
         PGpTNr9RTef5ceeyJ/mL6+cGmn6x9FRy0nR6e16xHCXHTCanOV0dUmGow6opWx8b7hD2
         caucxw8Omxi8LPJV1Q/h6689O4CZsghjvmOsryInoAtk+6rjDBjpDPuoRa+euDD2lsSD
         3V8GtHeqMosBQ5ir3j0xVBQ4yMJBHamSJdJT79T1fEQNN5N+e0U46aUwo+VUUXeR9BFk
         /foeCE9Fu8WsCuA2U8/p5stkk4PQ2Bq0/3VumuhyFPQI+YlWzp2UW4uoES8sWPxiyYS2
         G4DQ==
X-Forwarded-Encrypted: i=1; AJvYcCUzdh2Q0wBvwF+WUyJjvYk6jxqCLaILXQS5YwNVzYTii0nMhxWsnd7Lur0x+u/uEjP5ElGnZo9QHEo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxes5qqMAFWQQvopdQY5Nq+5RU0V774I5PFKZfx4uMdtoWwD2dE
	kDKEG8sQ7pTnTtRUgi+CNlED3VX9MZAThUANvjAIvx21G6PytdOQ5TwHSEW0RowSDg==
X-Gm-Gg: ASbGncvval1BqN0wuGuQ9CjBZpEvqcwZ17owMGSP4+FtjSqo5anV8yBTbPhFu/PGcCd
	13ia2qUQ1uG6eEJRWtP6l7SiSPH6I5qymV8bQtLL97ppgJGjJNfMFhhlPI+nq7/5puRgOnR0WBW
	ZbORi74zr4gS5YImv9HYya5FBhXPTBq7xpvk8kerDjTirv0vcyQkaNkoZx+mFw+6o2LKB/Yp7KZ
	5MQWkzQx128LlwYylcHgj18+X/cvSFy77E0QFr1kAYZ/CXBXzyamvAtZ8RLLkPf3bfWNR27amHx
	G0aa1qZuVIbIb8immuWdzfQIRG5tMNd/hVpAAnl4zzoMrLNViD76D6dXK1lZM6BpyHk6IwvLjoi
	sDrm3Ji7/of1bgldo6IzmPiiD7TjGjq7Hb9D+5R3qVfOPKhZcGE/bi4DZUMdn0rAQB2F6MgcTVr
	CAeipOLMaBStfw43LX+g==
X-Google-Smtp-Source: AGHT+IEgEuNqRxytqwviOQDruDtjWll61k2i2gBmawctUxjN894sV8RwULT/g7znCWHkmh6An5M6jg==
X-Received: by 2002:a17:907:3d16:b0:afe:8bee:fdb9 with SMTP id a640c23a62f3a-b01d8c99b67mr1847941766b.28.1756989224164;
        Thu, 04 Sep 2025 05:33:44 -0700 (PDT)
Message-ID: <5a5d949c-70b3-4255-a12d-7dbf988d15b4@suse.com>
Date: Thu, 4 Sep 2025 14:33:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 7/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Penny Zheng 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-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: <20250904063518.2097629-8-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, Penny Zheng wrote:
> Introduce helper set_amd_cppc_para() and get_amd_cppc_para() to
> SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.
> 
> In get_cpufreq_cppc()/set_cpufreq_cppc(), we include
> "processor_pminfo[cpuid]->init & XEN_CPPC_INIT" condition check to deal with
> cpufreq driver in amd-cppc.
> We borrow governor field to indicate policy info for CPPC active mode,
> so we need to move the copying of the governor name out of the
> !cpufreq_is_governorless() guard.

Well, as said in my v8 comment - it's not so much the "what" that needs covering,
but the "why is it correct / safe to do so". See my respective reply to patch 5,
and also to Jason's response on the v8 thread. Perhaps with the union there
removed this doesn't need calling out explicitly anymore.

> ---
> v8 -> v9
> - add description of "moving the copying of the governor name"
> - Adapt to changes of "Embed struct amd_cppc_drv_data{} into struct
> cpufreq_policy{}"

Except that again problems extend to here as well.

> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> @@ -561,6 +561,169 @@ static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
>      return 0;
>  }
>  
> +#ifdef CONFIG_PM_OP
> +int amd_cppc_get_para(const struct cpufreq_policy *policy,
> +                      struct xen_get_cppc_para *cppc_para)
> +{
> +    const struct amd_cppc_drv_data *data = policy->u.amd_cppc;
> +
> +    if ( data == NULL )
> +        return -ENODATA;
> +
> +    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 amd_cppc_set_para(struct cpufreq_policy *policy,
> +                      const struct xen_set_cppc_para *set_cppc)
> +{
> +    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
> +    uint8_t max_perf, min_perf, des_perf, epp;
> +    bool active_mode = cpufreq_is_governorless(policy->cpu);
> +
> +    if ( data == NULL )
> +        return -ENOENT;
> +
> +    /* 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;
> +
> +    /* Return if there is nothing to do. */
> +    if ( set_cppc->set_params == 0 )
> +        return 0;
> +
> +    /*
> +     * Validate all parameters
> +     * Maximum performance may be set to any performance value in the range
> +     * [Nonlinear Lowest Performance, Highest Performance], inclusive but must
> +     * be set to a value that is larger than or equal to minimum Performance.
> +     */
> +    if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
> +         (set_cppc->maximum > data->caps.highest_perf ||
> +          (set_cppc->maximum <
> +           (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM
> +            ? set_cppc->minimum
> +            : data->req.min_perf))) )
> +        return -EINVAL;
> +    /*
> +     * Minimum performance may be set to any performance value in the range
> +     * [Nonlinear Lowest Performance, Highest Performance], inclusive but must
> +     * be set to a value that is less than or equal to Maximum Performance.
> +     */
> +    if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
> +         (set_cppc->minimum < data->caps.lowest_nonlinear_perf ||
> +          (set_cppc->minimum >
> +           (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM
> +            ? set_cppc->maximum
> +            : data->req.max_perf))) )
> +        return -EINVAL;
> +    /*
> +     * Desired performance may be set to any performance value in the range
> +     * [Minimum Performance, Maximum Performance], inclusive.
> +     */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +    {
> +        if ( active_mode )
> +            return -EOPNOTSUPP;
> +
> +        if ( (set_cppc->desired >
> +              (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM
> +               ? set_cppc->maximum
> +               : data->req.max_perf)) ||
> +             (set_cppc->desired <
> +              (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM
> +               ? set_cppc->minimum
> +               : data->req.min_perf)) )
> +            return -EINVAL;
> +    }
> +    /*
> +     * Energy Performance Preference may be set with a range of values
> +     * from 0 to 0xFF
> +     */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
> +    {
> +        if ( !active_mode )
> +            return -EOPNOTSUPP;
> +
> +        if ( set_cppc->energy_perf > UINT8_MAX )
> +            return -EINVAL;
> +    }
> +
> +    /* Activity window not supported in MSR */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
> +        return -EOPNOTSUPP;
> +
> +    des_perf = data->req.des_perf;
> +    /*
> +     * Apply presets:
> +     * XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/ONDEMAND are
> +     * only available when CPPC in active mode
> +     */
> +    switch ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_PRESET_MASK )
> +    {
> +    case XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE:
> +        if ( !active_mode )
> +            return -EINVAL;
> +        policy->policy = CPUFREQ_POLICY_POWERSAVE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
> +        if ( !active_mode )
> +            return -EINVAL;
> +        policy->policy = CPUFREQ_POLICY_PERFORMANCE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_ONDEMAND:
> +        if ( !active_mode )
> +            return -EINVAL;
> +        policy->policy = CPUFREQ_POLICY_ONDEMAND;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
> +        if ( active_mode )
> +            policy->policy = CPUFREQ_POLICY_UNKNOWN;
> +        break;
> +
> +    default:
> +        return -EINVAL;
> +    }
> +    amd_cppc_prepare_policy(policy, &max_perf, &min_perf, &epp);
> +
> +    /* Further customize presets if needed */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM )
> +        min_perf = set_cppc->minimum;
> +
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM )
> +        max_perf = set_cppc->maximum;
> +
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
> +        epp = set_cppc->energy_perf;
> +
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +        des_perf = set_cppc->desired;
> +
> +    amd_cppc_write_request(policy->cpu, data,

Like elsewhere, policy->cpu may not be online.

> --- a/xen/drivers/acpi/pm-op.c
> +++ b/xen/drivers/acpi/pm-op.c
> @@ -84,6 +84,8 @@ static int get_cpufreq_cppc(unsigned int cpu,
>  
>      if ( hwp_active() )
>          ret = get_hwp_para(cpu, cppc_para);
> +    else if ( processor_pminfo[cpu]->init & XEN_CPPC_INIT )
> +        ret = amd_cppc_get_para(per_cpu(cpufreq_cpu_policy, cpu), cppc_para);
>  
>      return ret;
>  }
> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>      else
>          strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
>  
> +    /*
> +     * In CPPC active mode, we are borrowing governor field to indicate
> +     * policy info.
> +     */
> +    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);
> +
>      if ( !cpufreq_is_governorless(op->cpuid) )
>      {
>          if ( !(scaling_available_governors =
> @@ -178,13 +191,6 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>          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);

Just to re-iterate here: Pulling this out is okay because the union has
no other member anymore, and hence other date cannot be badly impacted.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 12:58:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 12:58:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110044.1459361 (Exim 4.92)
	(envelope-from )
	id 1uu9Xm-0003eb-Pm; Thu, 04 Sep 2025 12:58:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110044.1459361; Thu, 04 Sep 2025 12:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu9Xm-0003eU-Lw; Thu, 04 Sep 2025 12:58:26 +0000
Received: by outflank-mailman (input) for mailman id 1110044;
 Thu, 04 Sep 2025 12:58: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 1uu9Xl-0003eE-Q6
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:25 +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 d703a398-898e-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:58:23 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-afeec747e60so182472766b.0
 for ; Thu, 04 Sep 2025 05:58: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-b0424cc1698sm1038740866b.21.2025.09.04.05.58.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 05:58: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: d703a398-898e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756990703; x=1757595503; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ncs+StciXQshjJrmPuF0PSOBMkl7D6bmlZl6UnBxWtE=;
        b=DUbXo+kUt95PAJ17kEfdfz092Zw/QdzFrfDt9AJ4aMomB0g7P0En+ulrs4kNh0U3Qf
         JT1rzGSLikoakPcRO/whuxSsf+CeNLM2C+p+60nFx/vq+6J2N+RFURETHstYLjoCn3e7
         DyOYmDimZpTZg/hdDs0rs0+kKOLQnC3Ht9PdXaGcWhcpg3jOIYAvlsUbFpAE8rh2uzvV
         lHFzr7awdoVO9TpR9JNw7Msi9iUQmRldJUAfK20OkWphCUcSjUHUc7PuS2yu4UKna2bY
         OgpgMhTHbDXczuKWIjD2seQoiiOAnN10rNgtj+BlRvc7HoHcaF7Z7GWGjST1bLOf8ngS
         TD6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756990703; x=1757595503;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ncs+StciXQshjJrmPuF0PSOBMkl7D6bmlZl6UnBxWtE=;
        b=r8bfCuIYEBTYoMjaRvZtuz/2ksMs0V8yxsAMfbX4lAk3UjrNYwep3Oeu+Mtxvq24Tc
         XVaaMsqgiG0isIV7m4kjq5fvpvL5O+10nfyg8uXdk92lAJoOWJdXHWM8zBA0nwLsSgfr
         cSTij2ynR9EOLISS7CWRXgVQq7WyNnsuf3Kp2z4VjPyeNsZrO9APBQykfVLgbW5Gv3//
         /t5ulEQSu/5cOD8mvOB+pl7jKYjqsgZXxPlvWsY5F6Cjm93UBDprCi/uEsvM8agDW2ay
         lrW/HjFrENG/+MQOGjqM9O8uCx66bbcJ9G4ThRMfJf0JhjmnkKLd0rWBLtVlrrhcnpFA
         vP4w==
X-Forwarded-Encrypted: i=1; AJvYcCWHDcP8ZUHdc+i/aGOyDkOvLzBewk4QvTtNgw8cowc0G9ziYG2bxLdUr8VmB5ol9mgfrnOJnJ0HgYc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxaAKfT0V0xTNrjry+yB1HuQjlsBppnBE86MGItn4nCOQ5VMQYG
	Wu7USL9cKrrlaoCQ45z+wQa5T3Kjai+S5Ief6nKANH3XJ4/GUJu4dVceFxkoe0BuiA==
X-Gm-Gg: ASbGnctdx23MRxWjjuuy51pLMDRJijH3VzPOyv50EhykiMXQLgfcUwutVfOnCneOSYG
	bGu7bLoyxtyg0qfa4JXPlc0MNxAi19YaZ+0r0JwfX2zKYkpDKsjS9wkNpjrkUwXKGxU+tfN0D3Q
	2YDHQOaBy/D00Y4HTY155dgMMD5gCa1cOxdMejBAp7LtOvRurKGjWWJ1c+rpHg6bEoi266Iqzy/
	ssQcYbcdcddUEFB2iGk1alKJudAS0LW/liUi1FEdyhUySX8ynqOj9CJJBRnt5rmrkVcNZSaOfc7
	AA6BBIr8AWfb5J8mpIbVN/KxtthmhvjnjwAzD5kXhNMVLwbMJDGsyFwjNMI7YPYGVfnIQEes0eN
	idDlgbAQYnegSMofcO4uklI2mU2kb7yRqEc60lRUCjy4rhbUfWUJ+2JQnXyLRSn3laYAbU3fUgS
	iudBifS2Q=
X-Google-Smtp-Source: AGHT+IGBgGarIys1DEkp2vb0GnrmMkNM15916guNksS18bEAE1VK1EibLG4Qpa157pepvTFC1/umzw==
X-Received: by 2002:a17:906:c114:b0:b04:79e1:a08e with SMTP id a640c23a62f3a-b0479e1a68amr351894466b.24.1756990702839;
        Thu, 04 Sep 2025 05:58:22 -0700 (PDT)
Message-ID: <488408be-4728-4666-89a5-ac5b438bdbf5@suse.com>
Date: Thu, 4 Sep 2025 14:58:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250904114202.2722478-1-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: <20250904114202.2722478-1-marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> available in earlier toolchain versions. But use it together with
> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> still contains some paths in out-of-tree builds.

I consider it wrong not to use -ffile-prefix-map when available. That
already covers more than "debug" and "macro", and it may gain further
functionality.

> The out of tree build requires -fdebug-prefix-map mapping for both source
> dir and object dir - otherwise the latter is included (2 occurrences) in
> xen-syms.

As indicated in a reply to Andrew on the thread hanging off of my
patch - I think whether to remove those wants to be left to the user.

> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -1,4 +1,4 @@
> -XEN_ROOT = $(CURDIR)/..
> +XEN_ROOT = $(realpath $(CURDIR)/..)
>  
>  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
>  
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 725c3c32e9a2..428fce094819 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -166,6 +166,8 @@ endif
>  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
>  CFLAGS += $(CFLAGS-y)
>  
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)

Here and below - no need to use cc-option-add for -fdebug-prefix-map,
which all permissible compilers support.

Further, again as per reply to Andrew on the thread hanging off of my
patch - I don't view it as desirable to leave the tools/ prefix in
place, or e.g. for libraries, the entire tools/libs// part.
Imo every binary should have only the path (if any) from its own source
root left. (And yes, how to deal with e.g. shared include files isn't
quite clear to me, yet. Maybe we actually need to pass two options.)

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -208,7 +208,7 @@ VPATH := $(srctree)
>  
>  export srctree objtree VPATH
>  
> -export XEN_ROOT := $(abs_srctree)/..
> +export XEN_ROOT := $(patsubst %/xen,%,$(abs_srctree))

Unlike for tools/, is this still needed here? You don't use XEN_ROOT below.

> @@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
>  CFLAGS += -Wa,--strip-local-absolute
>  endif
>  
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_objtree)=./xen)
> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(abs_srctree)=./xen)
> +$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=$(abs_srctree)=./xen)

I disagree with leaving any xen/ prefix there. That's not how in-tree builds
name files; everything there is relative to xen/.

I also don't really see a point in using . in the substitution (similarly
for the toolstack, but there I have less to say).

Finally, why pass two identical, possibly long options for in-tree builds
(where $(abs_objtree) == $(abs_srctree))?

Below I'll reproduce my own further re-worked patch. It's not quite ready
for v2 submission yet, I expect though. For example, the actual Kconfig
portion is still missing. Whether the @SRC@ and @BLD@ parts actually make
sense (or what to replace them by) I'm also unsure about. If nothing else
they may need replacing by plain .

Jan

build: avoid absolute paths in executables

For in-tree builds relative paths are used in most cases, whereas for out-
of-tree builds in various situations absolute ones come into play. The
extra paths can be long, wasting space and e.g. serial line bandwidth.
They would also get in the way of location-independent reproducible
builds. Leverage newer gcc's (and Clang's) ability to "remap" file names.
For older gcc fall back to using the option affecting debug info only.

For the few absolute paths appearing in in-tree builds' debug info, use
the generally available option, conditional upon a new Kconfig control

Signed-off-by: Jan Beulich 
---
Of course we may want to consider putting this in the top-level Config.mk,
to also affect other sub-trees (presently mainly/only affecting debug
info, for which even gcc5 already supports -fdebug-prefix-remap=).

As to a Fixes: tag, I wasn't quite sure whether to "blame" the
introduction of out-of-tree builds.

Note that at least in the gcc5 I'm testing with the (limited) effect is
further undermined by the compiler emitting the specified command line
options into debug info, thus still leaving references to the absolute
directories in place.

For the mentioned gcc15 issue see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121788.
---
v2: Use $(abs_srctree). Introduce DEBUG_INFO_REL_PATHS.

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -461,7 +461,21 @@ CFLAGS += -flto
 LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
 endif
 
+CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += -fdebug-prefix-map=$(abs_srctree)=@SRC@
+
 ifdef building_out_of_srctree
+    # Need to add to CFLAGS-y here, as gcc checks later options before earlier
+    # ones, and we want in particular the latter one(s) here to be checked
+    # first.
+    CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) += -fdebug-prefix-map=$(abs_objtree)=@BLD@
+    CFLAGS-y += $(call cc-option,$(CC),-ffile-prefix-map=$(abs_srctree)/=)
+    # While -ffile-prefix-map= implies -fdebug-prefix-map=, we need to use the
+    # latter explicitly: Up to at least gcc15 the compiler specs translate all
+    # -ffile-prefix-map= ahead of all -fdebug-prefix-map= when invoking the
+    # the assembler for *.S files, thus breaking our intended ordering.
+    # (Otherwise the option below could be passed as 3rd [fallback] argument to
+    # cc-option above.)
+    CFLAGS-y += -fdebug-prefix-map=$(abs_srctree)/=
     CFLAGS += -I$(objtree)/include
     CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include
 endif



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110050.1459406 (Exim 4.92)
	(envelope-from )
	id 1uu9dX-0005iA-Pf; Thu, 04 Sep 2025 13:04:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110050.1459406; Thu, 04 Sep 2025 13: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 1uu9dX-0005fK-JI; Thu, 04 Sep 2025 13:04:23 +0000
Received: by outflank-mailman (input) for mailman id 1110050;
 Thu, 04 Sep 2025 12:58: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 1uu9Xx-0003uI-9z
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:37 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id dea293a4-898e-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 14:58:36 +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 4A9CE2EC6;
 Thu,  4 Sep 2025 05:58:27 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 17AC83F6A8;
 Thu,  4 Sep 2025 05:58: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: dea293a4-898e-11f0-9d12-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 3/7] arm64: mm: fully support nested lazy_mmu sections
Date: Thu,  4 Sep 2025 13:57:32 +0100
Message-ID: <20250904125736.3918646-4-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Despite recent efforts to prevent lazy_mmu sections from nesting, it
remains difficult to ensure that it never occurs - and in fact it
does occur on arm64 in certain situations (CONFIG_DEBUG_PAGEALLOC).
Commit 1ef3095b1405 ("arm64/mm: Permit lazy_mmu_mode to be nested")
made nesting tolerable on arm64, but without truly supporting it:
the inner leave() call clears TIF_LAZY_MMU, disabling the batching
optimisation before the outer section ends.

Now that the lazy_mmu API allows enter() to pass through a state to
the matching leave() call, we can actually support nesting. If
enter() is called inside an active lazy_mmu section, TIF_LAZY_MMU
will already be set, and we can then return LAZY_MMU_NESTED to
instruct the matching leave() call not to clear TIF_LAZY_MMU.

The only effect of this patch is to ensure that TIF_LAZY_MMU (and
therefore the batching optimisation) remains set until the outermost
lazy_mmu section ends. leave() still emits barriers if needed,
regardless of the nesting level, as the caller may expect any
page table changes to become visible when leave() returns.

Signed-off-by: Kevin Brodsky 
---
 arch/arm64/include/asm/pgtable.h | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 816197d08165..602feda97dc4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -85,24 +85,14 @@ typedef int lazy_mmu_state_t;
 
 static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
-	/*
-	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
-	 * does happen with CONFIG_DEBUG_PAGEALLOC, where a page allocation
-	 * inside a lazy_mmu_mode section (such as zap_pte_range()) will change
-	 * permissions on the linear map with apply_to_page_range(), which
-	 * re-enters lazy_mmu_mode. So we tolerate nesting in our
-	 * implementation. The first call to arch_leave_lazy_mmu_mode() will
-	 * flush and clear the flag such that the remainder of the work in the
-	 * outer nest behaves as if outside of lazy mmu mode. This is safe and
-	 * keeps tracking simple.
-	 */
+	int lazy_mmu_nested;
 
 	if (in_interrupt())
 		return LAZY_MMU_DEFAULT;
 
-	set_thread_flag(TIF_LAZY_MMU);
+	lazy_mmu_nested = test_and_set_thread_flag(TIF_LAZY_MMU);
 
-	return LAZY_MMU_DEFAULT;
+	return lazy_mmu_nested ? LAZY_MMU_NESTED : LAZY_MMU_DEFAULT;
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
@@ -113,7 +103,8 @@ static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
 		emit_pte_barriers();
 
-	clear_thread_flag(TIF_LAZY_MMU);
+	if (state != LAZY_MMU_NESTED)
+		clear_thread_flag(TIF_LAZY_MMU);
 }
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110043.1459386 (Exim 4.92)
	(envelope-from )
	id 1uu9dW-0005T4-VS; Thu, 04 Sep 2025 13:04:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110043.1459386; Thu, 04 Sep 2025 13:04:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu9dW-0005Sx-Sp; Thu, 04 Sep 2025 13:04:22 +0000
Received: by outflank-mailman (input) for mailman id 1110043;
 Thu, 04 Sep 2025 12:58: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 1uu9Xl-0003eE-4R
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:25 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id d5df21f3-898e-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:58:22 +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 9F7181756;
 Thu,  4 Sep 2025 05:58:12 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 684763F6A8;
 Thu,  4 Sep 2025 05:58: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: d5df21f3-898e-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/7] Nesting support for lazy MMU mode
Date: Thu,  4 Sep 2025 13:57:29 +0100
Message-ID: <20250904125736.3918646-1-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When the lazy MMU mode was introduced eons ago, it wasn't made clear
whether such a sequence was legal:

	arch_enter_lazy_mmu_mode()
	...
		arch_enter_lazy_mmu_mode()
		...
		arch_leave_lazy_mmu_mode()
	...
	arch_leave_lazy_mmu_mode()

It seems fair to say that nested calls to
arch_{enter,leave}_lazy_mmu_mode() were not expected, and most
architectures never explicitly supported it.

Ryan Roberts' series from March [1] attempted to prevent nesting from
ever occurring, and mostly succeeded. Unfortunately, a corner case
(DEBUG_PAGEALLOC) may still cause nesting to occur on arm64. Ryan
proposed [2] to address that corner case at the generic level but this
approach received pushback; [3] then attempted to solve the issue on
arm64 only, but it was deemed too fragile.

It feels generally fragile to rely on lazy_mmu sections not to nest,
because callers of various standard mm functions do not know if the
function uses lazy_mmu itself. This series therefore performs a U-turn
and adds support for nested lazy_mmu sections, on all architectures.

The main change enabling nesting is patch 2, following the approach
suggested by Catalin Marinas [4]: have enter() return some state and
the matching leave() take that state. In this series, the state is only
used to handle nesting, but it could be used for other purposes such as
restoring context modified by enter(); the proposed kpkeys framework
would be an immediate user [5].

Patch overview:

* Patch 1: general cleanup - not directly related, but avoids any doubt
  regarding the expected behaviour of arch_flush_lazy_mmu_mode() outside
  x86

* Patch 2: main API change, no functional change

* Patch 3-6: nesting support for all architectures that support lazy_mmu

* Patch 7: clarification that nesting is supported in the documentation

Patch 4-6 are technically not required at this stage since nesting is
only observed on arm64, but they ensure future correctness in case
nesting is (re)introduced in generic paths. For instance, it could be
beneficial in some configurations to enter lazy_mmu set_ptes() once
again.

This series has been tested by running the mm kselfetsts on arm64 with
DEBUG_PAGEALLOC and KFENCE. It was also build-tested on other
architectures (with and without XEN_PV on x86).

- Kevin

[1] https://lore.kernel.org/all/20250303141542.3371656-1-ryan.roberts@arm.com/
[2] https://lore.kernel.org/all/20250530140446.2387131-1-ryan.roberts@arm.com/
[3] https://lore.kernel.org/all/20250606135654.178300-1-ryan.roberts@arm.com/
[4] https://lore.kernel.org/all/aEhKSq0zVaUJkomX@arm.com/
[5] https://lore.kernel.org/linux-hardening/20250815085512.2182322-19-kevin.brodsky@arm.com/
---
Cc: Alexander Gordeev 
Cc: Andreas Larsson 
Cc: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Christophe Leroy 
Cc: Dave Hansen 
Cc: David Hildenbrand 
Cc: "David S. Miller" 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jann Horn 
Cc: Juergen Gross 
Cc: "Liam R. Howlett" 
Cc: Lorenzo Stoakes 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Thomas Gleixner 
Cc: Vlastimil Babka 
Cc: Will Deacon 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparclinux@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
Kevin Brodsky (7):
  mm: remove arch_flush_lazy_mmu_mode()
  mm: introduce local state for lazy_mmu sections
  arm64: mm: fully support nested lazy_mmu sections
  x86/xen: support nested lazy_mmu sections (again)
  powerpc/mm: support nested lazy_mmu sections
  sparc/mm: support nested lazy_mmu sections
  mm: update lazy_mmu documentation

 arch/arm64/include/asm/pgtable.h              | 34 ++++++-------------
 .../include/asm/book3s/64/tlbflush-hash.h     | 24 +++++++++----
 arch/powerpc/mm/book3s64/hash_tlb.c           | 10 +++---
 arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +--
 arch/sparc/include/asm/tlbflush_64.h          |  6 ++--
 arch/sparc/mm/tlb.c                           | 19 ++++++++---
 arch/x86/include/asm/paravirt.h               |  8 ++---
 arch/x86/include/asm/paravirt_types.h         |  6 ++--
 arch/x86/include/asm/pgtable.h                |  3 +-
 arch/x86/xen/enlighten_pv.c                   |  2 +-
 arch/x86/xen/mmu_pv.c                         | 13 ++++---
 fs/proc/task_mmu.c                            |  5 +--
 include/linux/mm_types.h                      |  3 ++
 include/linux/pgtable.h                       | 21 +++++++++---
 mm/madvise.c                                  | 20 ++++++-----
 mm/memory.c                                   | 20 ++++++-----
 mm/migrate_device.c                           |  5 +--
 mm/mprotect.c                                 |  5 +--
 mm/mremap.c                                   |  5 +--
 mm/vmalloc.c                                  | 15 ++++----
 mm/vmscan.c                                   | 15 ++++----
 21 files changed, 147 insertions(+), 97 deletions(-)


base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110048.1459401 (Exim 4.92)
	(envelope-from )
	id 1uu9dX-0005cy-Ia; Thu, 04 Sep 2025 13:04:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110048.1459401; Thu, 04 Sep 2025 13: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 1uu9dX-0005Zf-AC; Thu, 04 Sep 2025 13:04:23 +0000
Received: by outflank-mailman (input) for mailman id 1110048;
 Thu, 04 Sep 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 1uu9Xu-0003uI-JD
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:34 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id dbab6767-898e-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 14:58:31 +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 6F6E82E98;
 Thu,  4 Sep 2025 05:58:22 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1F7653F6A8;
 Thu,  4 Sep 2025 05:58: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: dbab6767-898e-11f0-9d12-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
Date: Thu,  4 Sep 2025 13:57:31 +0100
Message-ID: <20250904125736.3918646-3-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
(taking and returning no value). This is proving problematic in
situations where leave() needs to restore some context back to its
original state (before enter() was called). In particular, this
makes it difficult to support the nesting of lazy_mmu sections -
leave() does not know whether the matching enter() call occurred
while lazy_mmu was already enabled, and whether to disable it or
not.

This patch gives all architectures the chance to store local state
while inside a lazy_mmu section by making enter() return some value,
storing it in a local variable, and having leave() take that value.
That value is typed lazy_mmu_state_t - each architecture defining
__HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
For now we define it as int everywhere, which is sufficient to
support nesting.

The diff is unfortunately rather large as all the API changes need
to be done atomically. Main parts:

* Changing the prototypes of arch_{enter,leave}_lazy_mmu_mode()
  in generic and arch code, and introducing lazy_mmu_state_t.

* Introducing LAZY_MMU_{DEFAULT,NESTED} for future support of
  nesting. enter() always returns LAZY_MMU_DEFAULT for now.
  (linux/mm_types.h is not the most natural location for defining
  those constants, but there is no other obvious header that is
  accessible where arch's implement the helpers.)

* Changing all lazy_mmu sections to introduce a lazy_mmu_state
  local variable, having enter() set it and leave() take it. Most of
  these changes were generated using the Coccinelle script below.

@@
@@
{
+ lazy_mmu_state_t lazy_mmu_state;
...
- arch_enter_lazy_mmu_mode();
+ lazy_mmu_state = arch_enter_lazy_mmu_mode();
...
- arch_leave_lazy_mmu_mode();
+ arch_leave_lazy_mmu_mode(lazy_mmu_state);
...
}

Note: it is difficult to provide a default definition of
lazy_mmu_state_t for architectures implementing lazy_mmu, because
that definition would need to be available in
arch/x86/include/asm/paravirt_types.h and adding a new generic
 #include there is very tricky due to the existing header soup.

Signed-off-by: Kevin Brodsky 
---
 arch/arm64/include/asm/pgtable.h              | 10 +++++++---
 .../include/asm/book3s/64/tlbflush-hash.h     |  9 ++++++---
 arch/powerpc/mm/book3s64/hash_tlb.c           | 10 ++++++----
 arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +++--
 arch/sparc/include/asm/tlbflush_64.h          |  5 +++--
 arch/sparc/mm/tlb.c                           |  6 ++++--
 arch/x86/include/asm/paravirt.h               |  6 ++++--
 arch/x86/include/asm/paravirt_types.h         |  2 ++
 arch/x86/xen/enlighten_pv.c                   |  2 +-
 arch/x86/xen/mmu_pv.c                         |  2 +-
 fs/proc/task_mmu.c                            |  5 +++--
 include/linux/mm_types.h                      |  3 +++
 include/linux/pgtable.h                       |  6 ++++--
 mm/madvise.c                                  | 20 ++++++++++---------
 mm/memory.c                                   | 20 +++++++++++--------
 mm/migrate_device.c                           |  5 +++--
 mm/mprotect.c                                 |  5 +++--
 mm/mremap.c                                   |  5 +++--
 mm/vmalloc.c                                  | 15 ++++++++------
 mm/vmscan.c                                   | 15 ++++++++------
 20 files changed, 97 insertions(+), 59 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 728d7b6ed20a..816197d08165 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -81,7 +81,9 @@ static inline void queue_pte_barriers(void)
 }
 
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
-static inline void arch_enter_lazy_mmu_mode(void)
+typedef int lazy_mmu_state_t;
+
+static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	/*
 	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
@@ -96,12 +98,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
 	 */
 
 	if (in_interrupt())
-		return;
+		return LAZY_MMU_DEFAULT;
 
 	set_thread_flag(TIF_LAZY_MMU);
+
+	return LAZY_MMU_DEFAULT;
 }
 
-static inline void arch_leave_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	if (in_interrupt())
 		return;
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 176d7fd79eeb..c9f1e819e567 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -25,13 +25,14 @@ DECLARE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
 extern void __flush_tlb_pending(struct ppc64_tlb_batch *batch);
 
 #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
+typedef int lazy_mmu_state_t;
 
-static inline void arch_enter_lazy_mmu_mode(void)
+static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	struct ppc64_tlb_batch *batch;
 
 	if (radix_enabled())
-		return;
+		return LAZY_MMU_DEFAULT;
 	/*
 	 * apply_to_page_range can call us this preempt enabled when
 	 * operating on kernel page tables.
@@ -39,9 +40,11 @@ static inline void arch_enter_lazy_mmu_mode(void)
 	preempt_disable();
 	batch = this_cpu_ptr(&ppc64_tlb_batch);
 	batch->active = 1;
+
+	return LAZY_MMU_DEFAULT;
 }
 
-static inline void arch_leave_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	struct ppc64_tlb_batch *batch;
 
diff --git a/arch/powerpc/mm/book3s64/hash_tlb.c b/arch/powerpc/mm/book3s64/hash_tlb.c
index 21fcad97ae80..ee664f88e679 100644
--- a/arch/powerpc/mm/book3s64/hash_tlb.c
+++ b/arch/powerpc/mm/book3s64/hash_tlb.c
@@ -189,6 +189,7 @@ void hash__tlb_flush(struct mmu_gather *tlb)
  */
 void __flush_hash_table_range(unsigned long start, unsigned long end)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int hugepage_shift;
 	unsigned long flags;
 
@@ -205,7 +206,7 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
 	 * way to do things but is fine for our needs here.
 	 */
 	local_irq_save(flags);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; start < end; start += PAGE_SIZE) {
 		pte_t *ptep = find_init_mm_pte(start, &hugepage_shift);
 		unsigned long pte;
@@ -217,12 +218,13 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
 			continue;
 		hpte_need_flush(&init_mm, start, ptep, pte, hugepage_shift);
 	}
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	local_irq_restore(flags);
 }
 
 void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte;
 	pte_t *start_pte;
 	unsigned long flags;
@@ -237,7 +239,7 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
 	 * way to do things but is fine for our needs here.
 	 */
 	local_irq_save(flags);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	start_pte = pte_offset_map(pmd, addr);
 	if (!start_pte)
 		goto out;
@@ -249,6 +251,6 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
 	}
 	pte_unmap(start_pte);
 out:
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	local_irq_restore(flags);
 }
diff --git a/arch/powerpc/mm/book3s64/subpage_prot.c b/arch/powerpc/mm/book3s64/subpage_prot.c
index ec98e526167e..4720f9f321af 100644
--- a/arch/powerpc/mm/book3s64/subpage_prot.c
+++ b/arch/powerpc/mm/book3s64/subpage_prot.c
@@ -53,6 +53,7 @@ void subpage_prot_free(struct mm_struct *mm)
 static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
 			     int npages)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pgd_t *pgd;
 	p4d_t *p4d;
 	pud_t *pud;
@@ -73,13 +74,13 @@ static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
 	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
 	if (!pte)
 		return;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; npages > 0; --npages) {
 		pte_update(mm, addr, pte, 0, 0, 0);
 		addr += PAGE_SIZE;
 		++pte;
 	}
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(pte - 1, ptl);
 }
 
diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
index cd144eb31bdd..02c93a4e6af5 100644
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -40,10 +40,11 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
 void flush_tlb_kernel_range(unsigned long start, unsigned long end);
 
 #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
+typedef int lazy_mmu_state_t;
 
 void flush_tlb_pending(void);
-void arch_enter_lazy_mmu_mode(void);
-void arch_leave_lazy_mmu_mode(void);
+lazy_mmu_state_t arch_enter_lazy_mmu_mode(void);
+void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state);
 
 /* Local cpu only.  */
 void __flush_tlb_all(void);
diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index a35ddcca5e76..bf5094b770af 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -50,16 +50,18 @@ void flush_tlb_pending(void)
 	put_cpu_var(tlb_batch);
 }
 
-void arch_enter_lazy_mmu_mode(void)
+lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	struct tlb_batch *tb;
 
 	preempt_disable();
 	tb = this_cpu_ptr(&tlb_batch);
 	tb->active = 1;
+
+	return LAZY_MMU_DEFAULT;
 }
 
-void arch_leave_lazy_mmu_mode(void)
+void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index b5e59a7ba0d0..65a0d394fba1 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -527,12 +527,14 @@ static inline void arch_end_context_switch(struct task_struct *next)
 }
 
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
-static inline void arch_enter_lazy_mmu_mode(void)
+static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	PVOP_VCALL0(mmu.lazy_mode.enter);
+
+	return LAZY_MMU_DEFAULT;
 }
 
-static inline void arch_leave_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	PVOP_VCALL0(mmu.lazy_mode.leave);
 }
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 37a8627d8277..bc1af86868a3 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -41,6 +41,8 @@ struct pv_info {
 };
 
 #ifdef CONFIG_PARAVIRT_XXL
+typedef int lazy_mmu_state_t;
+
 struct pv_lazy_ops {
 	/* Set deferred update mode, used for batching operations. */
 	void (*enter)(void);
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 26bbaf4b7330..a245ba47a631 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -426,7 +426,7 @@ static void xen_start_context_switch(struct task_struct *prev)
 	BUG_ON(preemptible());
 
 	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
 		set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES);
 	}
 	enter_lazy(XEN_LAZY_CPU);
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2a4a8deaf612..2039d5132ca3 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2140,7 +2140,7 @@ static void xen_flush_lazy_mmu(void)
 	preempt_disable();
 
 	if (xen_get_lazy_mode() == XEN_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
 		arch_enter_lazy_mmu_mode();
 	}
 
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 29cca0e6d0ff..c9bf1128a4cd 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -2610,6 +2610,7 @@ static int pagemap_scan_thp_entry(pmd_t *pmd, unsigned long start,
 static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 				  unsigned long end, struct mm_walk *walk)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct pagemap_scan_private *p = walk->private;
 	struct vm_area_struct *vma = walk->vma;
 	unsigned long addr, flush_end = 0;
@@ -2628,7 +2629,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 		return 0;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	if ((p->arg.flags & PM_SCAN_WP_MATCHING) && !p->vec_out) {
 		/* Fast path for performing exclusive WP */
@@ -2698,7 +2699,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 	if (flush_end)
 		flush_tlb_range(vma, start, addr);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(start_pte, ptl);
 
 	cond_resched();
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 08bc2442db93..18745c32f2c0 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1441,6 +1441,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm);
 extern void tlb_gather_mmu_fullmm(struct mmu_gather *tlb, struct mm_struct *mm);
 extern void tlb_finish_mmu(struct mmu_gather *tlb);
 
+#define LAZY_MMU_DEFAULT	0
+#define LAZY_MMU_NESTED		1
+
 struct vm_fault;
 
 /**
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 8848e132a6be..6932c8e344ab 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -232,8 +232,10 @@ static inline int pmd_dirty(pmd_t pmd)
  * 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)
+typedef int lazy_mmu_state_t;
+
+#define arch_enter_lazy_mmu_mode()	(LAZY_MMU_DEFAULT)
+#define arch_leave_lazy_mmu_mode(state)	((void)(state))
 #endif
 
 #ifndef pte_batch_hint
diff --git a/mm/madvise.c b/mm/madvise.c
index 35ed4ab0d7c5..72c032f2cf56 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -357,6 +357,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				unsigned long addr, unsigned long end,
 				struct mm_walk *walk)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct madvise_walk_private *private = walk->private;
 	struct mmu_gather *tlb = private->tlb;
 	bool pageout = private->pageout;
@@ -455,7 +456,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	if (!start_pte)
 		return 0;
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
 		nr = 1;
 		ptent = ptep_get(pte);
@@ -463,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 		if (++batch_count == SWAP_CLUSTER_MAX) {
 			batch_count = 0;
 			if (need_resched()) {
-				arch_leave_lazy_mmu_mode();
+				arch_leave_lazy_mmu_mode(lazy_mmu_state);
 				pte_unmap_unlock(start_pte, ptl);
 				cond_resched();
 				goto restart;
@@ -499,7 +500,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				if (!folio_trylock(folio))
 					continue;
 				folio_get(folio);
-				arch_leave_lazy_mmu_mode();
+				arch_leave_lazy_mmu_mode(lazy_mmu_state);
 				pte_unmap_unlock(start_pte, ptl);
 				start_pte = NULL;
 				err = split_folio(folio);
@@ -510,7 +511,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				if (!start_pte)
 					break;
 				flush_tlb_batched_pending(mm);
-				arch_enter_lazy_mmu_mode();
+				lazy_mmu_state = arch_enter_lazy_mmu_mode();
 				if (!err)
 					nr = 0;
 				continue;
@@ -558,7 +559,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	}
 
 	if (start_pte) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(lazy_mmu_state);
 		pte_unmap_unlock(start_pte, ptl);
 	}
 	if (pageout)
@@ -657,6 +658,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 
 {
 	const cydp_t cydp_flags = CYDP_CLEAR_YOUNG | CYDP_CLEAR_DIRTY;
+	lazy_mmu_state_t lazy_mmu_state;
 	struct mmu_gather *tlb = walk->private;
 	struct mm_struct *mm = tlb->mm;
 	struct vm_area_struct *vma = walk->vma;
@@ -677,7 +679,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!start_pte)
 		return 0;
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; addr != end; pte += nr, addr += PAGE_SIZE * nr) {
 		nr = 1;
 		ptent = ptep_get(pte);
@@ -727,7 +729,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 				if (!folio_trylock(folio))
 					continue;
 				folio_get(folio);
-				arch_leave_lazy_mmu_mode();
+				arch_leave_lazy_mmu_mode(lazy_mmu_state);
 				pte_unmap_unlock(start_pte, ptl);
 				start_pte = NULL;
 				err = split_folio(folio);
@@ -738,7 +740,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 				if (!start_pte)
 					break;
 				flush_tlb_batched_pending(mm);
-				arch_enter_lazy_mmu_mode();
+				lazy_mmu_state = arch_enter_lazy_mmu_mode();
 				if (!err)
 					nr = 0;
 				continue;
@@ -778,7 +780,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	if (nr_swap)
 		add_mm_counter(mm, MM_SWAPENTS, nr_swap);
 	if (start_pte) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(lazy_mmu_state);
 		pte_unmap_unlock(start_pte, ptl);
 	}
 	cond_resched();
diff --git a/mm/memory.c b/mm/memory.c
index 0ba4f6b71847..ebe0ffddcb77 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1079,6 +1079,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	       pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
 	       unsigned long end)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct mm_struct *dst_mm = dst_vma->vm_mm;
 	struct mm_struct *src_mm = src_vma->vm_mm;
 	pte_t *orig_src_pte, *orig_dst_pte;
@@ -1126,7 +1127,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
 	orig_src_pte = src_pte;
 	orig_dst_pte = dst_pte;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		nr = 1;
@@ -1195,7 +1196,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	} while (dst_pte += nr, src_pte += nr, addr += PAGE_SIZE * nr,
 		 addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(orig_src_pte, src_ptl);
 	add_mm_rss_vec(dst_mm, rss);
 	pte_unmap_unlock(orig_dst_pte, dst_ptl);
@@ -1694,6 +1695,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 				unsigned long addr, unsigned long end,
 				struct zap_details *details)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	bool force_flush = false, force_break = false;
 	struct mm_struct *mm = tlb->mm;
 	int rss[NR_MM_COUNTERS];
@@ -1714,7 +1716,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		return addr;
 
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	do {
 		bool any_skipped = false;
 
@@ -1746,7 +1748,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		direct_reclaim = try_get_and_clear_pmd(mm, pmd, &pmdval);
 
 	add_mm_rss_vec(mm, rss);
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 
 	/* Do the actual TLB flush before dropping ptl */
 	if (force_flush) {
@@ -2683,6 +2685,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			unsigned long addr, unsigned long end,
 			unsigned long pfn, pgprot_t prot)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte, *mapped_pte;
 	spinlock_t *ptl;
 	int err = 0;
@@ -2690,7 +2693,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 	mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
 	if (!pte)
 		return -ENOMEM;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	do {
 		BUG_ON(!pte_none(ptep_get(pte)));
 		if (!pfn_modify_allowed(pfn, prot)) {
@@ -2700,7 +2703,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 		set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
 		pfn++;
 	} while (pte++, addr += PAGE_SIZE, addr != end);
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(mapped_pte, ptl);
 	return err;
 }
@@ -2989,6 +2992,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 				     pte_fn_t fn, void *data, bool create,
 				     pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte, *mapped_pte;
 	int err = 0;
 	spinlock_t *ptl;
@@ -3007,7 +3011,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			return -EINVAL;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	if (fn) {
 		do {
@@ -3020,7 +3024,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 	}
 	*mask |= PGTBL_PTE_MODIFIED;
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 
 	if (mm != &init_mm)
 		pte_unmap_unlock(mapped_pte, ptl);
diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index e05e14d6eacd..659285c6ba77 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -59,6 +59,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 				   unsigned long end,
 				   struct mm_walk *walk)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct migrate_vma *migrate = walk->private;
 	struct folio *fault_folio = migrate->fault_page ?
 		page_folio(migrate->fault_page) : NULL;
@@ -110,7 +111,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 	ptep = pte_offset_map_lock(mm, pmdp, addr, &ptl);
 	if (!ptep)
 		goto again;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	for (; addr < end; addr += PAGE_SIZE, ptep++) {
 		struct dev_pagemap *pgmap;
@@ -287,7 +288,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 	if (unmapped)
 		flush_tlb_range(walk->vma, start, end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(ptep - 1, ptl);
 
 	return 0;
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 113b48985834..7bba651e5aa3 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -273,6 +273,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 		struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr,
 		unsigned long end, pgprot_t newprot, unsigned long cp_flags)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte, oldpte;
 	spinlock_t *ptl;
 	long pages = 0;
@@ -293,7 +294,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 		target_node = numa_node_id();
 
 	flush_tlb_batched_pending(vma->vm_mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	do {
 		nr_ptes = 1;
 		oldpte = ptep_get(pte);
@@ -439,7 +440,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 			}
 		}
 	} while (pte += nr_ptes, addr += nr_ptes * PAGE_SIZE, addr != end);
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(pte - 1, ptl);
 
 	return pages;
diff --git a/mm/mremap.c b/mm/mremap.c
index e618a706aff5..dac29a734e16 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -193,6 +193,7 @@ static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr
 static int move_ptes(struct pagetable_move_control *pmc,
 		unsigned long extent, pmd_t *old_pmd, pmd_t *new_pmd)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct vm_area_struct *vma = pmc->old;
 	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
 	struct mm_struct *mm = vma->vm_mm;
@@ -256,7 +257,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
 	if (new_ptl != old_ptl)
 		spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
 	flush_tlb_batched_pending(vma->vm_mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	for (; old_addr < old_end; old_ptep += nr_ptes, old_addr += nr_ptes * PAGE_SIZE,
 		new_ptep += nr_ptes, new_addr += nr_ptes * PAGE_SIZE) {
@@ -301,7 +302,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
 		}
 	}
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	if (force_flush)
 		flush_tlb_range(vma, old_end - len, old_end);
 	if (new_ptl != old_ptl)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 6dbcdceecae1..f901675dd060 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -95,6 +95,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			phys_addr_t phys_addr, pgprot_t prot,
 			unsigned int max_page_shift, pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte;
 	u64 pfn;
 	struct page *page;
@@ -105,7 +106,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	if (!pte)
 		return -ENOMEM;
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		if (unlikely(!pte_none(ptep_get(pte)))) {
@@ -131,7 +132,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 		pfn++;
 	} while (pte += PFN_DOWN(size), addr += size, addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	*mask |= PGTBL_PTE_MODIFIED;
 	return 0;
 }
@@ -354,12 +355,13 @@ int ioremap_page_range(unsigned long addr, unsigned long end,
 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			     pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte;
 	pte_t ptent;
 	unsigned long size = PAGE_SIZE;
 
 	pte = pte_offset_kernel(pmd, addr);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 #ifdef CONFIG_HUGETLB_PAGE
@@ -378,7 +380,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 		WARN_ON(!pte_none(ptent) && !pte_present(ptent));
 	} while (pte += (size >> PAGE_SHIFT), addr += size, addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	*mask |= PGTBL_PTE_MODIFIED;
 }
 
@@ -514,6 +516,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 		unsigned long end, pgprot_t prot, struct page **pages, int *nr,
 		pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int err = 0;
 	pte_t *pte;
 
@@ -526,7 +529,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!pte)
 		return -ENOMEM;
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		struct page *page = pages[*nr];
@@ -548,7 +551,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 		(*nr)++;
 	} while (pte++, addr += PAGE_SIZE, addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	*mask |= PGTBL_PTE_MODIFIED;
 
 	return err;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a48aec8bfd92..13b6657c8743 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3521,6 +3521,7 @@ static void walk_update_folio(struct lru_gen_mm_walk *walk, struct folio *folio,
 static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 			   struct mm_walk *args)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int i;
 	bool dirty;
 	pte_t *pte;
@@ -3550,7 +3551,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 		return false;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 restart:
 	for (i = pte_index(start), addr = start; addr != end; i++, addr += PAGE_SIZE) {
 		unsigned long pfn;
@@ -3591,7 +3592,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 	if (i < PTRS_PER_PTE && get_next_vma(PMD_MASK, PAGE_SIZE, args, &start, &end))
 		goto restart;
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(pte, ptl);
 
 	return suitable_to_scan(total, young);
@@ -3600,6 +3601,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area_struct *vma,
 				  struct mm_walk *args, unsigned long *bitmap, unsigned long *first)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int i;
 	bool dirty;
 	pmd_t *pmd;
@@ -3632,7 +3634,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
 	if (!spin_trylock(ptl))
 		goto done;
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		unsigned long pfn;
@@ -3679,7 +3681,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
 
 	walk_update_folio(walk, last, gen, dirty);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	spin_unlock(ptl);
 done:
 	*first = -1;
@@ -4227,6 +4229,7 @@ static void lru_gen_age_node(struct pglist_data *pgdat, struct scan_control *sc)
  */
 bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int i;
 	bool dirty;
 	unsigned long start;
@@ -4278,7 +4281,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 		}
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	pte -= (addr - start) / PAGE_SIZE;
 
@@ -4312,7 +4315,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 
 	walk_update_folio(walk, last, gen, dirty);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 
 	/* feedback from rmap walkers to page table walkers */
 	if (mm_state && suitable_to_scan(i, young))
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110046.1459392 (Exim 4.92)
	(envelope-from )
	id 1uu9dX-0005Wg-6s; Thu, 04 Sep 2025 13:04:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110046.1459392; Thu, 04 Sep 2025 13: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 1uu9dX-0005Vj-2t; Thu, 04 Sep 2025 13:04:23 +0000
Received: by outflank-mailman (input) for mailman id 1110046;
 Thu, 04 Sep 2025 12: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 1uu9Xo-0003eE-Fm
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:28 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id d8c727f5-898e-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:58:26 +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 741D025E0;
 Thu,  4 Sep 2025 05:58:17 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 44AD33F6A8;
 Thu,  4 Sep 2025 05:58:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d8c727f5-898e-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/7] mm: remove arch_flush_lazy_mmu_mode()
Date: Thu,  4 Sep 2025 13:57:30 +0100
Message-ID: <20250904125736.3918646-2-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This function has only ever been used in arch/x86, so there is no
need for other architectures to implement it. Remove it from
linux/pgtable.h and all architectures besides x86.

The arm64 implementation is not empty but it is only called from
arch_leave_lazy_mmu_mode(), so we can simply fold it there.

Signed-off-by: Kevin Brodsky 
---
 arch/arm64/include/asm/pgtable.h                   | 9 +--------
 arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 2 --
 arch/sparc/include/asm/tlbflush_64.h               | 1 -
 arch/x86/include/asm/pgtable.h                     | 3 ++-
 include/linux/pgtable.h                            | 1 -
 5 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index abd2dee416b3..728d7b6ed20a 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -101,21 +101,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
 	set_thread_flag(TIF_LAZY_MMU);
 }
 
-static inline void arch_flush_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(void)
 {
 	if (in_interrupt())
 		return;
 
 	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
 		emit_pte_barriers();
-}
-
-static inline void arch_leave_lazy_mmu_mode(void)
-{
-	if (in_interrupt())
-		return;
 
-	arch_flush_lazy_mmu_mode();
 	clear_thread_flag(TIF_LAZY_MMU);
 }
 
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 146287d9580f..176d7fd79eeb 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -55,8 +55,6 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	preempt_enable();
 }
 
-#define arch_flush_lazy_mmu_mode()      do {} while (0)
-
 extern void hash__tlbiel_all(unsigned int action);
 
 extern void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize,
diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
index 8b8cdaa69272..cd144eb31bdd 100644
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -44,7 +44,6 @@ 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)
 
 /* Local cpu only.  */
 void __flush_tlb_all(void);
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index e33df3da6980..14fd672bc9b2 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -117,7 +117,8 @@ extern pmdval_t early_pmd_flags;
 #define pte_val(x)	native_pte_val(x)
 #define __pte(x)	native_make_pte(x)
 
-#define arch_end_context_switch(prev)	do {} while(0)
+#define arch_end_context_switch(prev)	do {} while (0)
+#define arch_flush_lazy_mmu_mode()	do {} while (0)
 #endif	/* CONFIG_PARAVIRT_XXL */
 
 static inline pmd_t pmd_set_flags(pmd_t pmd, pmdval_t set)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 4c035637eeb7..8848e132a6be 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -234,7 +234,6 @@ static inline int pmd_dirty(pmd_t pmd)
 #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)
 #endif
 
 #ifndef pte_batch_hint
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110056.1459431 (Exim 4.92)
	(envelope-from )
	id 1uu9dZ-0006OB-Im; Thu, 04 Sep 2025 13:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110056.1459431; Thu, 04 Sep 2025 13: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 1uu9dZ-0006MT-Ag; Thu, 04 Sep 2025 13:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1110056;
 Thu, 04 Sep 2025 12:58: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 1uu9Y6-0003uI-SO
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:46 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id e45b61f3-898e-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 14:58:46 +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 00A6F2ED2;
 Thu,  4 Sep 2025 05:58:37 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0CAA3F6A8;
 Thu,  4 Sep 2025 05:58:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e45b61f3-898e-11f0-9d12-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 5/7] powerpc/mm: support nested lazy_mmu sections
Date: Thu,  4 Sep 2025 13:57:34 +0100
Message-ID: <20250904125736.3918646-6-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The lazy_mmu API now allows nested sections to be handled by arch
code: enter() can return a flag if called inside another lazy_mmu
section, so that the matching call to leave() leaves any
optimisation enabled.

This patch implements that new logic for powerpc: if there is an
active batch, then enter() returns LAZY_MMU_NESTED and the matching
leave() leaves batch->active set. The preempt_{enable,disable} calls
are left untouched as they already handle nesting themselves.

TLB flushing is still done in leave() regardless of the nesting
level, as the caller may rely on it whether nesting is occurring or
not.

Signed-off-by: Kevin Brodsky 
---
 .../powerpc/include/asm/book3s/64/tlbflush-hash.h | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index c9f1e819e567..001c474da1fe 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -30,6 +30,7 @@ typedef int lazy_mmu_state_t;
 static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	struct ppc64_tlb_batch *batch;
+	int lazy_mmu_nested;
 
 	if (radix_enabled())
 		return LAZY_MMU_DEFAULT;
@@ -39,9 +40,14 @@ static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 	 */
 	preempt_disable();
 	batch = this_cpu_ptr(&ppc64_tlb_batch);
-	batch->active = 1;
+	lazy_mmu_nested = batch->active;
 
-	return LAZY_MMU_DEFAULT;
+	if (!lazy_mmu_nested) {
+		batch->active = 1;
+		return LAZY_MMU_DEFAULT;
+	} else {
+		return LAZY_MMU_NESTED;
+	}
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
@@ -54,7 +60,10 @@ static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 
 	if (batch->index)
 		__flush_tlb_pending(batch);
-	batch->active = 0;
+
+	if (state != LAZY_MMU_NESTED)
+		batch->active = 0;
+
 	preempt_enable();
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110052.1459427 (Exim 4.92)
	(envelope-from )
	id 1uu9dZ-0006Jr-7r; Thu, 04 Sep 2025 13:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110052.1459427; Thu, 04 Sep 2025 13: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 1uu9dZ-0006Ir-0x; Thu, 04 Sep 2025 13:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1110052;
 Thu, 04 Sep 2025 12: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 1uu9Y2-0003uI-4h
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:42 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id e17c05a8-898e-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 14:58:41 +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 2267F2ECB;
 Thu,  4 Sep 2025 05:58:32 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E64E73F6A8;
 Thu,  4 Sep 2025 05:58: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: e17c05a8-898e-11f0-9d12-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 4/7] x86/xen: support nested lazy_mmu sections (again)
Date: Thu,  4 Sep 2025 13:57:33 +0100
Message-ID: <20250904125736.3918646-5-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode")
originally introduced support for nested lazy sections (LAZY_MMU and
LAZY_CPU). It later got reverted by commit c36549ff8d84 as its
implementation turned out to be intolerant to preemption.

Now that the lazy_mmu API allows enter() to pass through a state to
the matching leave() call, we can support nesting again for the
LAZY_MMU mode in a preemption-safe manner. If xen_enter_lazy_mmu() is
called inside an active lazy_mmu section, xen_lazy_mode will already
be set to XEN_LAZY_MMU and we can then return LAZY_MMU_NESTED to
instruct the matching xen_leave_lazy_mmu() call to leave
xen_lazy_mode unchanged.

The only effect of this patch is to ensure that xen_lazy_mode
remains set to XEN_LAZY_MMU until the outermost lazy_mmu section
ends. xen_leave_lazy_mmu() still calls xen_mc_flush()
unconditionally.

Signed-off-by: Kevin Brodsky 
---
 arch/x86/include/asm/paravirt.h       |  6 ++----
 arch/x86/include/asm/paravirt_types.h |  4 ++--
 arch/x86/xen/mmu_pv.c                 | 11 ++++++++---
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 65a0d394fba1..4ecd3a6b1dea 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -529,14 +529,12 @@ static inline void arch_end_context_switch(struct task_struct *next)
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
 static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
-	PVOP_VCALL0(mmu.lazy_mode.enter);
-
-	return LAZY_MMU_DEFAULT;
+	return PVOP_CALL0(lazy_mmu_state_t, mmu.lazy_mode.enter);
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
-	PVOP_VCALL0(mmu.lazy_mode.leave);
+	PVOP_VCALL1(mmu.lazy_mode.leave, state);
 }
 
 static inline void arch_flush_lazy_mmu_mode(void)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index bc1af86868a3..b7c567ccbf32 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -45,8 +45,8 @@ typedef int lazy_mmu_state_t;
 
 struct pv_lazy_ops {
 	/* Set deferred update mode, used for batching operations. */
-	void (*enter)(void);
-	void (*leave)(void);
+	lazy_mmu_state_t (*enter)(void);
+	void (*leave)(lazy_mmu_state_t);
 	void (*flush)(void);
 } __no_randomize_layout;
 #endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2039d5132ca3..6e5390ff06a5 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2130,9 +2130,13 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 #endif
 }
 
-static void xen_enter_lazy_mmu(void)
+static lazy_mmu_state_t xen_enter_lazy_mmu(void)
 {
+	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
+		return LAZY_MMU_NESTED;
+
 	enter_lazy(XEN_LAZY_MMU);
+	return LAZY_MMU_DEFAULT;
 }
 
 static void xen_flush_lazy_mmu(void)
@@ -2167,11 +2171,12 @@ static void __init xen_post_allocator_init(void)
 	pv_ops.mmu.write_cr3 = &xen_write_cr3;
 }
 
-static void xen_leave_lazy_mmu(void)
+static void xen_leave_lazy_mmu(lazy_mmu_state_t state)
 {
 	preempt_disable();
 	xen_mc_flush();
-	leave_lazy(XEN_LAZY_MMU);
+	if (state != LAZY_MMU_NESTED)
+		leave_lazy(XEN_LAZY_MMU);
 	preempt_enable();
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110061.1459437 (Exim 4.92)
	(envelope-from )
	id 1uu9dZ-0006TV-TO; Thu, 04 Sep 2025 13:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110061.1459437; Thu, 04 Sep 2025 13: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 1uu9dZ-0006RT-Lk; Thu, 04 Sep 2025 13:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1110061;
 Thu, 04 Sep 2025 12:58: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 1uu9YC-0003eE-KO
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:52 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id e7477218-898e-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 14:58:50 +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 CD01C2F27;
 Thu,  4 Sep 2025 05:58:41 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9C1D63F6A8;
 Thu,  4 Sep 2025 05:58: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: e7477218-898e-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 6/7] sparc/mm: support nested lazy_mmu sections
Date: Thu,  4 Sep 2025 13:57:35 +0100
Message-ID: <20250904125736.3918646-7-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The lazy_mmu API now allows nested sections to be handled by arch
code: enter() can return a flag if called inside another lazy_mmu
section, so that the matching call to leave() leaves any
optimisation enabled.

This patch implements that new logic for sparc: if there is an
active batch, then enter() returns LAZY_MMU_NESTED and the matching
leave() leaves batch->active set. The preempt_{enable,disable} calls
are left untouched as they already handle nesting themselves.

TLB flushing is still done in leave() regardless of the nesting
level, as the caller may rely on it whether nesting is occurring or
not.

Signed-off-by: Kevin Brodsky 
---
 arch/sparc/mm/tlb.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index bf5094b770af..42de93d74d0e 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -53,12 +53,18 @@ void flush_tlb_pending(void)
 lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	struct tlb_batch *tb;
+	int lazy_mmu_nested;
 
 	preempt_disable();
 	tb = this_cpu_ptr(&tlb_batch);
-	tb->active = 1;
+	lazy_mmu_nested = tb->active;
 
-	return LAZY_MMU_DEFAULT;
+	if (!lazy_mmu_nested) {
+		tb->active = 1;
+		return LAZY_MMU_DEFAULT;
+	} else {
+		return LAZY_MMU_NESTED;
+	}
 }
 
 void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
@@ -67,7 +73,10 @@ void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 
 	if (tb->tlb_nr)
 		flush_tlb_pending();
-	tb->active = 0;
+
+	if (state != LAZY_MMU_NESTED)
+		tb->active = 0;
+
 	preempt_enable();
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:04:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:04:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110064.1459443 (Exim 4.92)
	(envelope-from )
	id 1uu9da-0006bF-Fo; Thu, 04 Sep 2025 13:04:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110064.1459443; Thu, 04 Sep 2025 13:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu9da-0006Yi-30; Thu, 04 Sep 2025 13:04:26 +0000
Received: by outflank-mailman (input) for mailman id 1110064;
 Thu, 04 Sep 2025 12: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 1uu9YG-0003uI-BX
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 12:58:56 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id ea234f23-898e-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 14:58:55 +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 A725E2F28;
 Thu,  4 Sep 2025 05:58:46 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 757883F6A8;
 Thu,  4 Sep 2025 05:58: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: ea234f23-898e-11f0-9d12-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 7/7] mm: update lazy_mmu documentation
Date: Thu,  4 Sep 2025 13:57:36 +0100
Message-ID: <20250904125736.3918646-8-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

We now support nested lazy_mmu sections on all architectures
implementing the API. Update the API comment accordingly.

Signed-off-by: Kevin Brodsky 
---
 include/linux/pgtable.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 6932c8e344ab..be0f059beb4d 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -228,8 +228,18 @@ static inline int pmd_dirty(pmd_t pmd)
  * 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.
+ * held, but for kernel PTE updates, no lock is held). The mode cannot be used
+ * in interrupt context.
+ *
+ * Calls may be nested: an arch_{enter,leave}_lazy_mmu_mode() pair may be called
+ * while the lazy MMU mode has already been enabled. An implementation should
+ * handle this using the state returned by enter() and taken by the matching
+ * leave() call; the LAZY_MMU_{DEFAULT,NESTED} flags can be used to indicate
+ * whether this enter/leave pair is nested inside another or not. (It is up to
+ * the implementation to track whether the lazy MMU mode is enabled at any point
+ * in time.) The expectation is that leave() will flush any batched state
+ * unconditionally, but only leave the lazy MMU mode if the passed state is not
+ * LAZY_MMU_NESTED.
  */
 #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
 typedef int lazy_mmu_state_t;
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:09:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:09:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110142.1459466 (Exim 4.92)
	(envelope-from )
	id 1uu9iH-0001Ez-Pc; Thu, 04 Sep 2025 13:09:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110142.1459466; Thu, 04 Sep 2025 13: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 1uu9iH-0001Es-Mx; Thu, 04 Sep 2025 13:09:17 +0000
Received: by outflank-mailman (input) for mailman id 1110142;
 Thu, 04 Sep 2025 13:09: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 1uu9iF-0001Eh-Gf
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 13:09:15 +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 5a057d62-8990-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 15:09:12 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DB9PR03MB7356.eurprd03.prod.outlook.com (2603:10a6:10:221::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 13:09:08 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 13:09: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: 5a057d62-8990-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Cmy+5EkCM3ohipKIdn4xQm3qq61AS5jZbjjUEFonrdcc24siJCiJ3UPqeRbcMsmfiPnbe9sFxwfUtni1OU9xm7XtkSBFzXH0LgLY/mqBIX8j48ErbBu1BkcklFfslEMIvZJPrDgwUC9gsIZjdxu0extmSnmUB9Bw8TH2qiEdhJ6OGka20NJVAkgdc+eMQpe/vd0Fnv6LE29yEISskQQKGllQrtTHUkc1pXD/THG6MGKh899QLUkaUpHCDH9ydyoK8bqSl7qApNVxnjKPPALpLb6eEXC5vmd/q67rUw5vkLdOp8UDJL+rsCW7mMafcEfFWlAxNEbDD8hyOxAvljCuUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GvtIxUnKBZJdSQxeuDSB4loFJi01Y3ZB3Aql2NIpYSk=;
 b=mcUtD0u5wXI2cDL5Lbbz/vg0PGUpEcf6CG+36gH8HdqYZq51P1VIGOLyp/ZeeMZjTHz9vTO9esMffGGWtRYhaqNXrXs8hGoPMaXWv/EYM8tPo9JUQbEmNuXYnW46dBgquUm4zFbdv1jopjSosDu8eLcMMyfUbThdgxKTt5JF9zdAVVKPfMYLzRj7uG3/fv1JiUwT6Eef95gCntX2TUZ7lONc+xEamEOOvUcaS8m5YEqwBfxLocbB1383p1SUz4HANGbjQS4o9vsGdn5L1Dbv5E+ZYmcqgmwP3Yv84dYg/s2ElElwERIesfJoKrNpbPHYBKcLkOGEnjx8Myt3USit7Q==
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=GvtIxUnKBZJdSQxeuDSB4loFJi01Y3ZB3Aql2NIpYSk=;
 b=KmXeEm/+AZKwoMYDqRYHpz+4fYhgmzSrvcaHgzpIsOY88D+MvH0QGVrvz8L+s5zWPu2cN5poJjHR+VIIZlxPZ4RlD0sOXJSXfrhORVrZTEGZxTFejZjE5CP8Fa2tjCJi+HQPxP2DDSK69GHcXpgF0mGFEXb5diXWlS16ii3BBV5/69LilxTl1r9aik0oXf0FZLYlJ20CnOeWUX6Dta3tSwxeBJ8c1BUpvlQTcLi2WAsOhBCEMwmd66BpUFJIwp+CP40cgF5kgkAifXTwycM4R+3WZNs64Ikwy8wSRiiPfkbnBrkZ5o+sI7wLgOUp8uO/YymXA6bbkHJzI47tfeptog==
From: Leonid Komarianskyi 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: "olekstysh@gmail.com" , Stefano Stabellini
	, Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk 
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Topic: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHN861IdGTmH+JEChpQbSpoZJ2bSC9NmAgAALmYA=
Date: Thu, 4 Sep 2025 13:09:08 +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: GV2PR03MB8678:EE_|DB9PR03MB7356:EE_
x-ms-office365-filtering-correlation-id: ef542897-b7f2-4726-fb6d-08ddebb43b7d
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?OW9QbHJrNENBcjNPTU5EL2tLSC9XeUpnQUhkMzFuOGJJVDcyNFUyTldwNTVY?=
 =?utf-8?B?WE41dFdDT3hHUjI3QnVBelNjeGRjM2NFY3pPTHh5Y1phTUJMYkFFMUJXVHA1?=
 =?utf-8?B?Mk5UdHkxU3g2enJYS3p0L1lqUDlEdDdMbmlZSjNqdmVxckYwakk5Z0dwL3NG?=
 =?utf-8?B?anl4eTJsUmFiZHNYaHBnK3pjbGd1YWRvZFhEZFlnZFFoOHAyUG5ES2U1UXBa?=
 =?utf-8?B?cWFtcXg0b21hQU9iVGJPUVRoa1lUenQ4b3pLWmtsSXZZVk01MGVPY1UxMHl0?=
 =?utf-8?B?OHJBdDNRWnJDZHFZTlAxMEdrSTExanBMMnVKS2oxLzBhbk1weXNuUk9pT253?=
 =?utf-8?B?TEVzWXZmbFpjTXhlYWQxS2pqY2xQcVBlRGt1M2pqUXV3TnVkcVNJelRzcEJz?=
 =?utf-8?B?WXVJd2plcGdyWmU4a3lYc2xaNVUxNUh0ZTdSQkpISjlPTkJKVkxmTHRkZVVS?=
 =?utf-8?B?NjBHOFhta0xsbDdzV1ZQSzUxamUwZVRTWlBxR010ZkdOSnBwWFNST0k0SXEv?=
 =?utf-8?B?aERRNjU3WmVwOXQxRGVCaDI0RktOTC9rODlWV1ExWk1Pdy95VStZN1M1RFBE?=
 =?utf-8?B?TFRCMVU5dTFKcFlRRUpnSjZMQ1FIUUFPTWxKazZtNHIwNUpWYUQ5S1ZoUXgy?=
 =?utf-8?B?REJCWXlIMDZueDhkZHArUHdnNjZyM3FsM0x4RHdrejVXWVdrazFkU0FvN2Ey?=
 =?utf-8?B?VjRCTUszZmt3QXdqSGFjRGQzN1pVWTJoY285K3pLelhYbk93c2tlUHJkd29y?=
 =?utf-8?B?RXM0bHptakduaWF1RnN4OVpQM0VGQytRaXJaOW9oMVFOTmhja2FReHI2c1FY?=
 =?utf-8?B?QnVXWUJ5TmVGdk9ReWhxeW9yd2h4RzZlNC9aM3I4VnZURWM2TVlUbEtWUEtL?=
 =?utf-8?B?NndRUXovVnpKbWRGSXU4djRtaklmdDBrYWtVZnkwdE5lcWVhUCt0VUVJZGU3?=
 =?utf-8?B?WGdSOHEvM1lsek02aUFjVWE2bEpQaGlseEhPRzIrd2ZXTlpBSVF4elFpVUx5?=
 =?utf-8?B?d09UdGQyQUVpTElEMmkzSTJUeFpQU1FzQWJhcStsd0J3QVQ5M3BkcFp4SUVD?=
 =?utf-8?B?dURVbHdNTHg3OXVTMXMzYnhVVkZIZGtNU2o3aHRnNkFNRjlCR1ZVV2pvcldU?=
 =?utf-8?B?WVZmOHVkZDJJek85RlBMb3NHcmdKcmgzOC91c0dqd0pmdys2Nk5CUjV3ZDJy?=
 =?utf-8?B?TFl4S3dHK2IrSnlUQnlEOTdCME9lSzVSeXh3ZTJRTGVTclQxek9od1FRTGpk?=
 =?utf-8?B?NXl1WWpMQWdFcUkwVWZqaDROblBHOUFDNDFvRmkxbVZ6RERLcm56SkV2K2Ew?=
 =?utf-8?B?cVVReTJURlMzSHFjb21aakYva2xKdWxaNFpZenB3eUNCR25QTkkvQS9QUTR6?=
 =?utf-8?B?YlFTdTkzd3hkM3hndEZVcGU0UXh4cWtBeGIwQ28yQmxWTVFlZGYvYzN2UDdY?=
 =?utf-8?B?dy9GN1dSQmZjWEVzVWxsNXF4ZHh4dWQrNW5GK1NHSEFwMmpHN1NiaUNPdU0y?=
 =?utf-8?B?Ry9ieGdDSW5RblFhRitTY0dJQTJHZEVkcThjZlNJT2pOc3ZxNmwyOXF1Umd0?=
 =?utf-8?B?bXB1cXltcnFFOWpSNTAyL2s4S0pyL2hGb09HTkc2d0w4eW00Q0Q1Nm1KNjlP?=
 =?utf-8?B?VWxvcEppTWtrYjdYSWRTN3FwTElaeWR4c05wVjVXYThvUytYRkVYT3NBZWI4?=
 =?utf-8?B?Q2hJNTRvMnVVcUhMUXByUDRIZzZWOU45YkpiZVJJOHZNN2lYcWY0QzZTV0l0?=
 =?utf-8?B?aWpGMkFTaHplcEtMTnIxN2FZb0djK0VPLyt0SzB4T3BQNEZ5dFJnRTFLMzdH?=
 =?utf-8?B?WjQ1TGdRL2Q0bFlzY0xUd1NHbnEyaFljWC9zU3dnZG80c3RwUEtYWjhXa3lV?=
 =?utf-8?B?K1djNzcwNlEzSHNFZHVWYldzSktrSFM5a0JGalhya2NYb3lJcU95NDRZdzUx?=
 =?utf-8?B?Q2ZBdFd6ZEJRQ2lHK0ZOaFVZdTA2Q3ZpUVdicUhWRXVxbXJQRklENzRXeldi?=
 =?utf-8?B?WTB6WjJlVmhRPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OWtoL2tpVk84cFJoSVh4UHRRZmdnTVJLenNMOHlqZXRyNU4wTmgvNXFtOGRp?=
 =?utf-8?B?bzBBM0MyZE4rWnU1RUZtUEN5SVJna1dHRmxSL0hqUGh4eHdqY3I1NkJXZkEw?=
 =?utf-8?B?QWtEWFhEVEF1VFUybmFBRk5FdUptWGJtV0pPMm5qOVVWU2l1b2JZelRWY0tv?=
 =?utf-8?B?cnBYczNrZHYxU0N4dTVaL2lybS9zQ1hPK0ZOOXlmMlptZmNzME5NUEdRQ1VT?=
 =?utf-8?B?eVVjdm5nR1krSDFRcFVDc3YvWmFqZUJwOGdobjloNVBJVUhuWGZjb1kvUDBX?=
 =?utf-8?B?NENLSDFrVGRMMVlXbHF5czBUaFpaMFFIMW1uUTZFVWhCQ1dKZUd4dWRKQUd6?=
 =?utf-8?B?eDI5R0dhTU9VSmRzTWpEMDhNZm5kWDQyWVhLZS9pcy9zSjZyZWc0dTVZWVZM?=
 =?utf-8?B?VWdRcTJBcTZGMHQrRzBPSTVPajJKSE4rMmN6Nk5LOWVWNnpFY21peHp3MW1k?=
 =?utf-8?B?TmhHaU9TeUxNaHcyeUpJeHRlS2lCOHhXRlVxa3c3SXZibUc0ZllRMjdET2Fv?=
 =?utf-8?B?OXVsb3lFTUZPNXdhSlgxREI4c3ovQmZET2NBcVBhZzdpd2s4K1dIZ1o1M29Q?=
 =?utf-8?B?R0J0Uzd5bTVORWp6VjdqRllhQnpKWUFqR2pjak9DU2IwTGJadGZ6Qm4xZDhD?=
 =?utf-8?B?cjdGQ0pFNlQ2MU1lUmFWZjh6U05mc2VERnFVamRUMWtjUVQ1OVB4STB3WVlq?=
 =?utf-8?B?VUFmUGg2K1pnSk9YY01uMEFnTjF3bTdsV29Hbi9IbjJrVHlHSTJVSDNwK0Vu?=
 =?utf-8?B?ZmZZYmNjdmplb3JCakZ2UW1hUmRwYW1jRkhlOTc0OWpWMnVrOGNrMG4xMmRT?=
 =?utf-8?B?NjlCR2NKbGc2Mnh5NUFJdDhsM0xRdXM4c1BFVU9wQ2xMeVBoZW9qSFFET2Fj?=
 =?utf-8?B?Rm9lVHJVYkcvd0xDWGlHMzRTenNqaG9IVXBTRlF0dVVHR1ViWDBlNDlwdWdw?=
 =?utf-8?B?dHplaXR2QTZvZWpvdit5bWJQL0pJZzVqOWVDNVFQZ0VmZzk3WTU0dEhYMmxG?=
 =?utf-8?B?SDFKQ3hGWEQwUEQ3TDN0N2lNUEV6c3RkK2Juelh6dk9ySWtINk5KaVNzdVlB?=
 =?utf-8?B?SFFEQ1dMbjJyTk1CWXJ3SHlJT2hOUGpSQmlTdVpGRWVZWS9DY2FhOXp4blZq?=
 =?utf-8?B?OU9oSzJiSkVYZTRTMGg4bXdzV1FGaGZzdW1ibmlEanhreVJhR1E1ZXhGdTNE?=
 =?utf-8?B?ZEZiVlNkRzAyYy84WEtZS3hDYVZDUUlvRTg1ZUxjL3drSjBlamFvVW1xUDlT?=
 =?utf-8?B?Z0JVblJxRWp4QTJLaTRncGpIQ3l5aXQzOVBqR1FNSUFkdHNkVVFHR2RDMVRN?=
 =?utf-8?B?c2p4WUZzSjVFNTlzSzhFSzdVSXhTUDJTdjNRU2orWElQWVJ0YVQ2ZncvT3Fj?=
 =?utf-8?B?M0hFV1I1clRZaEU2WXFIemxqUEZ3QUpnb09FdGhLS1VjSmY5T0wwbmoyQjdz?=
 =?utf-8?B?aStiaGpwLzF0UCtDV0g5OGtkQUR2UlY5dDc2ZmdQa0dUeEpNMElDNG52d3Fy?=
 =?utf-8?B?L2owOC80a0FEdk5mNDR3OWJWY3ErMWE5NFpUNzZiclNBK0U0ZHBHa1djOWVt?=
 =?utf-8?B?Uko4clc3T3NGcGdrRENQYVM1TitOSnE0YVlhQ09VSXhteW9abCszWVJJWktB?=
 =?utf-8?B?cVJXZmlnR2FpZlVHTXJacGFxOWNqcEs5K1VDdWhxcVVWZDhxUnZ2WFFLV1Nt?=
 =?utf-8?B?SW5ZRlJuVVpoYVNHK3hxMnROK2dUdk1acUMwMVBvVEZudktLb2h4NFNxcnZU?=
 =?utf-8?B?OEFwcFN1amFTdE8waFBXbjBjVGFHRlNDbWlCSlM0WnVRZWVQVFltdmRuYnh4?=
 =?utf-8?B?V2Zybk1KRVhzcTdCMGcrV3NMdnVuUWo4c2VXdGVHWHZzUFY4czZyUWR0WG1Z?=
 =?utf-8?B?MWNPMVUwY1E4VHJlcVAxWCtGTW8yRnJPc05Kb0VPUVFFdVpXN20xZ2pWWWI4?=
 =?utf-8?B?MVpVSFBUenNvazE1MjEzOTZpWm9ORW13MVlYaWhhbktlcmlWZE1DckV2MnE4?=
 =?utf-8?B?SGtJcWdzNlJ2YmtYOW1oVWJ6a1JzRVpqUG8yblFRc2c5Qmtzd1E1S0JCV2VN?=
 =?utf-8?B?eUczbzBCempTNlhhTzlpNXVJOTVUTERHOGo0TkkxbGxEV1NoYk9BVnJjSGRo?=
 =?utf-8?B?UE5kbmZacUxxV2c2d3VzL3VBc0N2cDFxNWFkZmYrVFlOUXFMS2I1SHZCcFZE?=
 =?utf-8?Q?5p8AtPRpMH/tuKYesLQDs7Y=3D?=
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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef542897-b7f2-4726-fb6d-08ddebb43b7d
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 13:09:08.0855
 (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: 2A7B2eu0C0Ehku+rwoIx5lpl7n1U5/eqg4escIielmj4ZIbSU/Fa3omrzp5rgW2KuPBST0f45zJtMyHAYy0kLvgU3dWHB44E8mxgGR0vBnI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7356

SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQoNCk9uIDA0LjA5LjI1
IDE1OjI3LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIExlb25pZCwNCj4gDQo+IE9uIDAzLzA5
LzIwMjUgMTU6MjksIExlb25pZCBLb21hcmlhbnNreWkgd3JvdGU6DQo+PiAtLS0NCj4+IMKgIHhl
bi9hcmNoL2FybS9LY29uZmlnwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDggKysrKysNCj4+IMKg
IHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9pcnEuaCB8IDM3ICsrKysrKysrKysrKysrKysrKysr
KysrKw0KPj4gwqAgeGVuL2FyY2gvYXJtL2lycS5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwg
NTMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPj4gwqAgMyBmaWxlcyBjaGFu
Z2VkLCA5NiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQ0KPj4NCj4+IGRpZmYgLS1naXQg
YS94ZW4vYXJjaC9hcm0vS2NvbmZpZyBiL3hlbi9hcmNoL2FybS9LY29uZmlnDQo+PiBpbmRleCAx
N2RmMTQ3YjI1Li40M2IwNTUzM2IxIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL0tjb25m
aWcNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9LY29uZmlnDQo+PiBAQCAtMTM1LDYgKzEzNSwxNCBA
QCBjb25maWcgR0lDVjMNCj4+IMKgwqDCoMKgwqDCoMKgIERyaXZlciBmb3IgdGhlIEFSTSBHZW5l
cmljIEludGVycnVwdCBDb250cm9sbGVyIHYzLg0KPj4gwqDCoMKgwqDCoMKgwqAgSWYgdW5zdXJl
LCB1c2UgdGhlIGRlZmF1bHQgc2V0dGluZy4NCj4+ICtjb25maWcgR0lDVjNfRVNQSQ0KPj4gK8Kg
wqDCoCBib29sICJFeHRlbmRlZCBTUEkgcmFuZ2Ugc3VwcG9ydCINCj4+ICvCoMKgwqAgZGVwZW5k
cyBvbiBHSUNWMyAmJiAhTkVXX1ZHSUMNCj4+ICvCoMKgwqAgaGVscA0KPj4gK8KgwqDCoMKgwqAg
QWxsb3cgWGVuIGFuZCBkb21haW5zIHRvIHVzZSBpbnRlcnJ1cHQgbnVtYmVycyBmcm9tIHRoZSAN
Cj4+IGV4dGVuZGVkIFNQSQ0KPj4gK8KgwqDCoMKgwqAgcmFuZ2UsIGZyb20gNDA5NiB0byA1MTE5
LiBUaGlzIGZlYXR1cmUgaXMgaW50cm9kdWNlZCBpbiBHSUN2My4xDQo+PiArwqDCoMKgwqDCoCBh
cmNoaXRlY3R1cmUuDQo+PiArDQo+PiDCoCBjb25maWcgSEFTX0lUUw0KPj4gwqDCoMKgwqDCoMKg
wqDCoMKgIGJvb2wgIkdJQ3YzIElUUyBNU0kgY29udHJvbGxlciBzdXBwb3J0IChVTlNVUFBPUlRF
RCkiIGlmIA0KPj4gVU5TVVBQT1JURUQNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBkZXBlbmRzIG9u
IEdJQ1YzICYmICFORVdfVkdJQyAmJiAhQVJNXzMyDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
YXJtL2luY2x1ZGUvYXNtL2lycS5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvIA0KPj4gYXNtL2ly
cS5oDQo+PiBpbmRleCA1YmM2NDc1ZWI0Li5mNGQwOTk3NjUxIDEwMDY0NA0KPj4gLS0tIGEveGVu
L2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVk
ZS9hc20vaXJxLmgNCj4+IEBAIC0zMiw2ICszMiwxMCBAQCBzdHJ1Y3QgYXJjaF9pcnFfZGVzYyB7
DQo+PiDCoCAjZGVmaW5lIFNQSV9NQVhfSU5USUTCoMKgIDEwMTkNCj4+IMKgICNkZWZpbmUgTFBJ
X09GRlNFVMKgwqDCoMKgwqAgODE5Mg0KPj4gKyNkZWZpbmUgRVNQSV9CQVNFX0lOVElEIDQwOTYN
Cj4+ICsjZGVmaW5lIEVTUElfTUFYX0lOVElEwqAgNTExOQ0KPj4gKyNkZWZpbmUgTlJfRVNQSV9J
UlFTwqDCoMKgIDEwMjQNCj4+ICsNCj4+IMKgIC8qIExQSXMgYXJlIGFsd2F5cyBudW1iZXJlZCBz
dGFydGluZyBhdCA4MTkyLCBzbyAwIGlzIGEgZ29vZCBpbnZhbGlkIA0KPj4gY2FzZS4gKi8NCj4+
IMKgICNkZWZpbmUgSU5WQUxJRF9MUEnCoMKgwqDCoCAwDQo+PiBAQCAtMzksNyArNDMsMTIgQEAg
c3RydWN0IGFyY2hfaXJxX2Rlc2Mgew0KPj4gwqAgI2RlZmluZSBJTlZBTElEX0lSUcKgwqDCoMKg
IDEwMjMNCj4+IMKgIGV4dGVybiBjb25zdCB1bnNpZ25lZCBpbnQgbnJfaXJxczsNCj4+ICsjaWZk
ZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICsvKiBUaGlzIHdpbGwgY292ZXIgdGhlIGVTUEkgcmFu
Z2UsIHRvIGFsbG93IGFzaWdubWFudCBvZiBlU1BJcyB0byANCj4+IGRvbWFpbnMuICovDQo+PiAr
I2RlZmluZSBucl9zdGF0aWNfaXJxcyAoRVNQSV9NQVhfSU5USUQgKyAxKQ0KPj4gKyNlbHNlDQo+
PiDCoCAjZGVmaW5lIG5yX3N0YXRpY19pcnFzIE5SX0lSUVMNCj4+ICsjZW5kaWYNCj4+IMKgIHN0
cnVjdCBpcnFfZGVzYzsNCj4+IMKgIHN0cnVjdCBpcnFhY3Rpb247DQo+PiBAQCAtNTUsNiArNjQs
MzQgQEAgc3RhdGljIGlubGluZSBib29sIGlzX2xwaSh1bnNpZ25lZCBpbnQgaXJxKQ0KPj4gwqDC
oMKgwqDCoCByZXR1cm4gaXJxID49IExQSV9PRkZTRVQ7DQo+PiDCoCB9DQo+PiArc3RhdGljIGlu
bGluZSB1bnNpZ25lZCBpbnQgZXNwaV9pbnRpZF90b19pZHgodW5zaWduZWQgaW50IGludGlkKQ0K
Pj4gK3sNCj4+ICvCoMKgwqAgQVNTRVJUKGludGlkID49IEVTUElfQkFTRV9JTlRJRCAmJiBpbnRp
ZCA8PSBFU1BJX01BWF9JTlRJRCk7DQo+IA0KPiBDYW4gd2UgdXNlIGlzX2VzcGkoKT8NCj4gDQoN
Clllcywgc3VyZS4gSSBqdXN0IG5lZWQgdG8gY2hhbmdlIHRoZSBmdW5jdGlvbiBkZWNsYXJhdGlv
biBvcmRlciBhbmQgdGhlbiANCkkgY2FuIHVzZSBpc19lc3BpKCkgaGVyZS4gSSB3aWxsIGRvIHRo
aXMgaW4gVjcuDQoNCj4+ICvCoMKgwqAgcmV0dXJuIGludGlkIC0gRVNQSV9CQVNFX0lOVElEOw0K
Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGludCBlc3BpX2lkeF90b19p
bnRpZCh1bnNpZ25lZCBpbnQgaWR4KQ0KPj4gK3sNCj4+ICvCoMKgwqAgQVNTRVJUKGlkeCA8PSBO
Ul9FU1BJX0lSUVMpOw0KPj4gK8KgwqDCoCByZXR1cm4gaWR4ICsgRVNQSV9CQVNFX0lOVElEOw0K
Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIGJvb2wgaXNfZXNwaSh1bnNpZ25lZCBpbnQg
aXJxKQ0KPj4gK3sNCj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+ICvCoMKgwqAgcmV0
dXJuIGlycSA+PSBFU1BJX0JBU0VfSU5USUQgJiYgaXJxIDw9IEVTUElfTUFYX0lOVElEOw0KPj4g
KyNlbHNlDQo+PiArwqDCoMKgIC8qDQo+PiArwqDCoMKgwqAgKiBUaGUgZnVuY3Rpb24gc2hvdWxk
IG5vdCBiZSBjYWxsZWQgZm9yIGVTUElzIHdoZW4gDQo+PiBDT05GSUdfR0lDVjNfRVNQSSBpcw0K
Pj4gK8KgwqDCoMKgICogZGlzYWJsZWQuIFJldHVybmluZyBmYWxzZSBhbGxvd3MgdGhlIGNvbXBp
bGVyIHRvIG9wdGltaXplIHRoZSANCj4+IGNvZGUNCj4+ICvCoMKgwqDCoCAqIHdoZW4gdGhlIGNv
bmZpZyBpcyBkaXNhYmxlZCwgd2hpbGUgdGhlIGFzc2VydCBlbnN1cmVzIHRoYXQgDQo+PiBvdXQt
b2YtcmFuZ2UNCj4+ICvCoMKgwqDCoCAqIGFycmF5IHJlc291cmNlcyBhcmUgbm90IGFjY2Vzc2Vk
LCBlLmcuLCBpbiBfX2lycV90b19kZXNjKCkuDQo+PiArwqDCoMKgwqAgKi8NCj4+ICvCoMKgwqAg
QVNTRVJUKGlycSA+PSBFU1BJX0JBU0VfSU5USUQpOw0KPiANCj4gUmVnYXJkbGVzcyB3aGF0IFZv
bG9keW15ciBtZW50aW9uZWQgYWJvdXQgdGhlIGFzc2VydCEoKSwgSSBhbSBhIGJpdCANCj4gdW5z
dXJlIHdoZXJlIHdlIGd1YXJhbnRlZSBpc19lc3BpKCkgd2lsbCBub3QgYmUgY2FsbGVkIHdpdGgg
YW4gaXJxIDw9IA0KPiBFU1BJX0JBU0VfSU5USUQuIEluIGZhY3QsIHdlIGNvdWxkIGhhdmUgdGhl
IGZvbGxvd2luZyBjb2RlIGluIFhlbjoNCj4gDQo+IGlmIChpc19lc3BpKGlycSkpDQo+IHsNCj4g
fQ0KPiBlbHNlIGlmIChpc19scGkoaXJxKSkNCj4gew0KPiB9DQo+IGVsc2UNCj4gew0KPiB9DQo+
IA0KPiBXZSBjb3VsZCByZXBsYWNlIHRoZSBjaGVjayB3aXRoICIhKGlycSA+PSBFU1BJX0JBU0Vf
SU5USUQgJiYgaXJxIDw9IA0KPiBFU1BJX01BWF9JTlRJRCkiLiBCdXQgSSB3b3VsZCBhY3R1YWxs
eSBwcmVmZXIgaWYgdGhlcmUgaXMgbm8gY2hlY2sgDQo+IGJlY2F1c2UgSSBkb24ndCBzZWUgdGhl
IHZhbHVlLg0KPiANCg0KVGhlIG1haW4gcmVhc29uIHRvIGFkZCBBU1NFUlQgaGVyZSBpcyB0byB0
cmlnZ2VyIGl0IGlmIHRoZSBjb25maWcgaXMgDQpkaXNhYmxlZCBidXQgYW4gZVNQSSBJTlRJRCBp
cyBkZWZpbmVkIGluIFhlbiBEVFMuIEluIHRoaXMgY2FzZSwgaW5zdGVhZCANCm9mIHRyaWdnZXJp
bmcgYW4gQVNTRVJUIChhcyBwcm9wb3NlZCksIHRoZSBmb2xsb3dpbmcgd2lsbCBvY2N1ciBpbiAN
Cl9faXJxX3RvX2Rlc2M6DQoNCi8vIEFzc3VtZSB3ZSBoYXZlIGlycSA9IDQwOTYNCnN0cnVjdCBp
cnFfZGVzYyAqX19pcnFfdG9fZGVzYyh1bnNpZ25lZCBpbnQgaXJxKQ0Kew0KICAgICAvLyBUaGlz
IGNoZWNrIHdpbGwgcmV0dXJuIGZhbHNlDQogICAgIGlmICggaXJxIDwgTlJfTE9DQUxfSVJRUyAp
DQogICAgICAgICByZXR1cm4gJnRoaXNfY3B1KGxvY2FsX2lycV9kZXNjKVtpcnFdOw0KDQogICAg
IC8qDQogICAgICAqIFRoaXMgY2hlY2sgd2lsbCBhbHNvIHJldHVybiBmYWxzZSBiZWNhdXNlIGlz
X2VzcGkoKQ0KICAgICAgKiB3aWxsIGFsd2F5cyByZXR1cm4gZmFsc2Ugd2hlbiBDT05GSUdfR0lD
VjNfRVNQST1uLg0KICAgICAgKi8NCiAgICAgaWYgKCBpc19lc3BpKGlycSkgKQ0KICAgICAgICAg
cmV0dXJuIGVzcGlfdG9fZGVzYyhpcnEpOw0KDQogICAgIC8qDQogICAgICAqIFdlIHdpbGwgZmFs
bCB0aHJvdWdoIHRvIHRoaXMgcG9pbnQgYW5kIGF0dGVtcHQgdG8gYWNjZXNzIDQwNjQsDQogICAg
ICAqIHdoaWNoIGRvZXMgbm90IGV4aXN0DQogICAgICAqLw0KICAgICByZXR1cm4gJmlycV9kZXNj
W2lycS1OUl9MT0NBTF9JUlFTXTsNCn0NCg0KU28sIEkgdGhpbmsgaXQncyBiZXR0ZXIgdG8gdXNl
IEFTU0VSVCB0byBzaW1wbGlmeSBlcnJvciBkZXRlY3Rpb24gaW4gDQpkZWJ1ZyBidWlsZHMuDQoN
Cj4+ICvCoMKgwqAgcmV0dXJuIGZhbHNlOw0KPj4gKyNlbmRpZg0KPj4gK30NCj4+ICsNCj4gDQo+
IENoZWVycywNCj4gDQoNCkJlc3QgcmVnYXJkcywNCkxlb25pZA0K


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:11:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:11:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110165.1459477 (Exim 4.92)
	(envelope-from )
	id 1uu9k8-0002ow-8k; Thu, 04 Sep 2025 13:11:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110165.1459477; Thu, 04 Sep 2025 13: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 1uu9k8-0002op-5e; Thu, 04 Sep 2025 13:11:12 +0000
Received: by outflank-mailman (input) for mailman id 1110165;
 Thu, 04 Sep 2025 13:11:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uu9k7-0002oh-2v
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 13:11:11 +0000
Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net
 [83.223.78.240]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f793a94-8990-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 15:11:09 +0200 (CEST)
Received: from h08.hostsharing.net (h08.hostsharing.net
 [IPv6:2a01:37:1000::53df:5f1c:0])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
 client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK))
 by bmailout2.hostsharing.net (Postfix) with ESMTPS id 68FB82009D10;
 Thu,  4 Sep 2025 15:11:08 +0200 (CEST)
Received: by h08.hostsharing.net (Postfix, from userid 100393)
 id 53B8B3FAE00; Thu,  4 Sep 2025 15:11: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: 9f793a94-8990-11f0-9d12-b5c5bf9af7f9
Message-Id: <22453676d1ddcebbe81641bb68ddf587fee7e21e.1756990799.git.lukas@wunner.de>
From: Lukas Wunner 
Date: Thu, 4 Sep 2025 15:11:09 +0200
Subject: [PATCH] xen/manage: Fix suspend error path
To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "Rafael J. Wysocki" 
Cc: xen-devel@lists.xenproject.org, linux-pm@vger.kernel.org, Pavel Machek , Len Brown 

The device power management API has the following asymmetry:
* dpm_suspend_start() does not clean up on failure
  (it requires a call to dpm_resume_end())
* dpm_suspend_end() does clean up on failure
  (it does not require a call to dpm_resume_start())

The asymmetry was introduced by commit d8f3de0d2412 ("Suspend-related
patches for 2.6.27") in June 2008:  It removed a call to device_resume()
from device_suspend() (which was later renamed to dpm_suspend_start()).

When Xen began using the device power management API in May 2008 with
commit 0e91398f2a5d ("xen: implement save/restore"), the asymmetry did
not yet exist.  But since it was introduced, a call to dpm_resume_end()
is missing in the error path of dpm_suspend_start().  Fix it.

Fixes: d8f3de0d2412 ("Suspend-related patches for 2.6.27")
Signed-off-by: Lukas Wunner 
Cc: stable@vger.kernel.org  # v2.6.27
---
kexec suffered from the same issue ever since it began using the
device power management API in July 2008 with commit 89081d17f7bb
("kexec jump: save/restore device state").  It was fixed this year
by commit 996afb6efd1a ("kexec_core: Fix error code path in the
KEXEC_JUMP flow").  All other callers seem fine.

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

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 841afa4..1f5a7a4 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -110,7 +110,7 @@ static void do_suspend(void)
 	err = dpm_suspend_start(PMSG_FREEZE);
 	if (err) {
 		pr_err("%s: dpm_suspend_start %d\n", __func__, err);
-		goto out_thaw;
+		goto out_resume_end;
 	}
 
 	printk(KERN_DEBUG "suspending xenstore...\n");
@@ -150,6 +150,7 @@ static void do_suspend(void)
 	else
 		xs_suspend_cancel();
 
+out_resume_end:
 	dpm_resume_end(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
 
 out_thaw:
-- 
2.50.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:22:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:22:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110197.1459488 (Exim 4.92)
	(envelope-from )
	id 1uu9uX-0004aa-7M; Thu, 04 Sep 2025 13:21:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110197.1459488; Thu, 04 Sep 2025 13:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uu9uX-0004aT-2S; Thu, 04 Sep 2025 13:21:57 +0000
Received: by outflank-mailman (input) for mailman id 1110197;
 Thu, 04 Sep 2025 13:21: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 1uu9uV-0004YW-MD
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 13:21:55 +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 1f7456b7-8992-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 15:21:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id A3CBC44236
 for ; Thu,  4 Sep 2025 13:21:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8522BC4CEF6
 for ; Thu,  4 Sep 2025 13:21:52 +0000 (UTC)
Received: by mail-ot1-f54.google.com with SMTP id
 46e09a7af769-74572fb94b3so841333a34.2
 for ; Thu, 04 Sep 2025 06:21: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: 1f7456b7-8992-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1756992112;
	bh=qo4+GKLXGFiTNyOVP1QuBOi8BIKyb9sSiyMt3ybbC2c=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=eeBjgvvhch4OWm+EspsXnXLs/o7YMHOSmgBmoqgtPdGUdyXiMV0vaXKJ9/999FwL7
	 xYnNZECKOcdKvFk2iksunSYqzVGLkoQBVweinX6P3KP2ORG6QfSVuvaeNaJiL0cqGp
	 MQ8dlBChywKAul9qx8/bFruLIbhVS4P8LG9KizpsrI7IuYuy+1Z9XfbsCpMYapM+cA
	 QbvFNL6VZorckg+NyMacmAkzPk/1lBUOLBF2oWUOjdsQSf4ZctiS5Qxzgc/aGm6iiE
	 Dn7sXNNHqcreStGTex+aJc/CoYjELH37LNeiucVfOyQvyAqACILDbJ4Cuat+m6Mc7R
	 yC9/FxWqFAQZA==
X-Forwarded-Encrypted: i=1; AJvYcCWXiIOdAtKbMwp9ShmMsyyj2G3e1IQoH29hIYAzznd3Gj1ioTqZPBJ0bhUyw4qz7SpAYKLyU/yCK5E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVMK9QEtuPCz2tZ0jHDBw4U3Me2QUADJPSozLLNz3yMeCKKRt8
	gBGqNDqV6ljIRIf5ctzez9v3q/Z+bV+u0N2dOcPuvXU9zyHullNKjRj1TRBiEZiORrwaxYAMcp9
	ayqjajL4IB2/JbjelSW+cYsh+cmeFzP0=
X-Google-Smtp-Source: AGHT+IHdGmlphfFGnt50ls1k7J1BDOKrtbE9wl3KpQcDoUFFaeFaf1j5/HssvVcWfRiAfoPn5J7l0vswcNJLXQD8K1s=
X-Received: by 2002:a05:6830:3c86:b0:745:4738:fc49 with SMTP id
 46e09a7af769-74569d94b2amr10619839a34.5.1756992111835; Thu, 04 Sep 2025
 06:21:51 -0700 (PDT)
MIME-Version: 1.0
References: <22453676d1ddcebbe81641bb68ddf587fee7e21e.1756990799.git.lukas@wunner.de>
In-Reply-To: <22453676d1ddcebbe81641bb68ddf587fee7e21e.1756990799.git.lukas@wunner.de>
From: "Rafael J. Wysocki" 
Date: Thu, 4 Sep 2025 15:21:40 +0200
X-Gmail-Original-Message-ID: 
X-Gm-Features: Ac12FXxuisaRR3J61UIxjJaNL4wSskbcFfNo2uvlzP8vHcRTSEW7Y5HYs2DQgBI
Message-ID: 
Subject: Re: [PATCH] xen/manage: Fix suspend error path
To: Lukas Wunner 
Cc: Juergen Gross , Stefano Stabellini , 
	Oleksandr Tyshchenko , "Rafael J. Wysocki" , 
	xen-devel@lists.xenproject.org, linux-pm@vger.kernel.org, 
	Pavel Machek , Len Brown 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 4, 2025 at 3:11=E2=80=AFPM Lukas Wunner  wrote=
:
>
> The device power management API has the following asymmetry:
> * dpm_suspend_start() does not clean up on failure
>   (it requires a call to dpm_resume_end())
> * dpm_suspend_end() does clean up on failure
>   (it does not require a call to dpm_resume_start())
>
> The asymmetry was introduced by commit d8f3de0d2412 ("Suspend-related
> patches for 2.6.27") in June 2008:  It removed a call to device_resume()
> from device_suspend() (which was later renamed to dpm_suspend_start()).
>
> When Xen began using the device power management API in May 2008 with
> commit 0e91398f2a5d ("xen: implement save/restore"), the asymmetry did
> not yet exist.  But since it was introduced, a call to dpm_resume_end()
> is missing in the error path of dpm_suspend_start().  Fix it.
>
> Fixes: d8f3de0d2412 ("Suspend-related patches for 2.6.27")
> Signed-off-by: Lukas Wunner 
> Cc: stable@vger.kernel.org  # v2.6.27

Thanks for catching this!

Reviewed-by: Rafael J. Wysocki (Intel) 

> ---
> kexec suffered from the same issue ever since it began using the
> device power management API in July 2008 with commit 89081d17f7bb
> ("kexec jump: save/restore device state").  It was fixed this year
> by commit 996afb6efd1a ("kexec_core: Fix error code path in the
> KEXEC_JUMP flow").  All other callers seem fine.
>
>  drivers/xen/manage.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index 841afa4..1f5a7a4 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -110,7 +110,7 @@ static void do_suspend(void)
>         err =3D dpm_suspend_start(PMSG_FREEZE);
>         if (err) {
>                 pr_err("%s: dpm_suspend_start %d\n", __func__, err);
> -               goto out_thaw;
> +               goto out_resume_end;
>         }
>
>         printk(KERN_DEBUG "suspending xenstore...\n");
> @@ -150,6 +150,7 @@ static void do_suspend(void)
>         else
>                 xs_suspend_cancel();
>
> +out_resume_end:
>         dpm_resume_end(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
>
>  out_thaw:
> --
> 2.50.1
>
>


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 13:50:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 13:50:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110232.1459497 (Exim 4.92)
	(envelope-from )
	id 1uuAMO-000065-AY; Thu, 04 Sep 2025 13:50:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110232.1459497; Thu, 04 Sep 2025 13:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuAMO-00005y-6J; Thu, 04 Sep 2025 13:50:44 +0000
Received: by outflank-mailman (input) for mailman id 1110232;
 Thu, 04 Sep 2025 13:50:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuAMN-00005r-4E
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 13:50:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuAML-006HO8-3D;
 Thu, 04 Sep 2025 13:50:42 +0000
Received: from [2a01:cb15:80df:da00:d2b0:117d:791c:30c0] (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 1uuAML-00FhpW-1x;
 Thu, 04 Sep 2025 13:50: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=PJHhQ3H+JmhApB2mrrcegAdSDYOEPR9jp4epF8Fwyrc=; b=seTSi5vVo+NK7DKlhNRn8QjLXP
	tGVfx5K2TFBzWihR5wYvLU7RyWmYgrvvhChcXiKog3Ds9FmZtxLc9yJ+iupP/WW6lxzl/s+LUBF9M
	SXvsD0ry8Uf2SmfZDlEo0kjDnDrCgqt8F706QPYBQvTBPTXkQgIZazRWtDFtuvqnDbB4=;
Date: Thu, 4 Sep 2025 15:50:38 +0200
From: Anthony PERARD 
To: dmukhin@xen.org
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 v17 3/4] tools/tests: introduce unit tests for domain ID
 allocator
Message-ID: 
References: <20250829232132.3460081-1-dmukhin@ford.com>
 <20250829232132.3460081-4-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250829232132.3460081-4-dmukhin@ford.com>

On Fri, Aug 29, 2025 at 04:21:31PM -0700, dmukhin@xen.org wrote:
> diff --git a/tools/tests/domid/Makefile b/tools/tests/domid/Makefile
> new file mode 100644
> index 000000000000..22f1f15d11db
> --- /dev/null
> +++ b/tools/tests/domid/Makefile
> +# NB: $1 cannot be a list

Why not? It would be the same as writing the rule multiple time for
different targets.

Is about my comment on "prerequisite" on v16? In this rule, "harness.h"
is a prerequisite.

> +define emit-harness-nested-rule
> +$(1): $(CURDIR)/harness.h
> +	mkdir -p $$(@D);
> +	ln -sf $$< $$@;
> +
> +endef
> diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
> new file mode 100644
> index 000000000000..5915c4699a5c
> --- /dev/null
> +++ b/tools/tests/domid/test-domid.c
> +
> +#include 
> +
> +#include "harness.h"
> +
> +#define verify(exp, fmt, args...) \
> +while (!(exp)) { \
> +    printf(fmt, ## args); \
> +    exit(EX_SOFTWARE); \

We never used any of "EX_*" macro, or even . I'm not sure
it's a good idea to introduce such use where exit(1) would have been
more than enough but sysexits.h seems to be available on BSD so it's
probably fine. It would be nice to change that to exit(1) and remove
sysexits.h.

Anyway, patch looks good enough so:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:06:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110243.1459506 (Exim 4.92)
	(envelope-from )
	id 1uuAbX-0001t9-Gr; Thu, 04 Sep 2025 14:06:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110243.1459506; Thu, 04 Sep 2025 14: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 1uuAbX-0001t2-EB; Thu, 04 Sep 2025 14:06:23 +0000
Received: by outflank-mailman (input) for mailman id 1110243;
 Thu, 04 Sep 2025 14:06:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuAbW-0001sw-4K
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:06:22 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuAbQ-006HlP-1F;
 Thu, 04 Sep 2025 14:06:16 +0000
Received: from [15.248.2.239] (helo=[10.24.66.11])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuAbQ-00FiYY-1F;
 Thu, 04 Sep 2025 14:06: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=kfFkrV1cOs3OOH0TuC/ydb3Fc5DnfzmsIo91t8WmrP4=; b=uw4Bw9zKO55t4T6jTKyKfa+r3M
	w6+6KaWopfTEMHwX9RbFiVLP/s1xO2PhufXdqpFxNrcePAkzE6lfuT4iZW3xADTjpfF/7ZkY+tgtO
	8CCvcWOycm4wFciDnNTJqBS7+Z+WknhzqymZn+6Q1vwFBHqeuqKamLJf+36JxW2nfAUw=;
Message-ID: <10c41b57-d02b-44d4-af48-ac3ed2f416b5@xen.org>
Date: Thu, 4 Sep 2025 15:06:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Leonid,

On 04/09/2025 14:09, Leonid Komarianskyi wrote:
> On 04.09.25 15:27, Julien Grall wrote:
>> Hi Leonid,
>>
>> On 03/09/2025 15:29, Leonid Komarianskyi wrote:
>>> ---
>>>    xen/arch/arm/Kconfig           |  8 +++++
>>>    xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
>>>    xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
>>>    3 files changed, 96 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index 17df147b25..43b05533b1 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -135,6 +135,14 @@ config GICV3
>>>          Driver for the ARM Generic Interrupt Controller v3.
>>>          If unsure, use the default setting.
>>> +config GICV3_ESPI
>>> +    bool "Extended SPI range support"
>>> +    depends on GICV3 && !NEW_VGIC
>>> +    help
>>> +      Allow Xen and domains to use interrupt numbers from the
>>> extended SPI
>>> +      range, from 4096 to 5119. This feature is introduced in GICv3.1
>>> +      architecture.
>>> +
>>>    config HAS_ITS
>>>            bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if
>>> UNSUPPORTED
>>>            depends on GICV3 && !NEW_VGIC && !ARM_32
>>> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/
>>> asm/irq.h
>>> index 5bc6475eb4..f4d0997651 100644
>>> --- a/xen/arch/arm/include/asm/irq.h
>>> +++ b/xen/arch/arm/include/asm/irq.h
>>> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>>>    #define SPI_MAX_INTID   1019
>>>    #define LPI_OFFSET      8192
>>> +#define ESPI_BASE_INTID 4096
>>> +#define ESPI_MAX_INTID  5119
>>> +#define NR_ESPI_IRQS    1024
>>> +
>>>    /* LPIs are always numbered starting at 8192, so 0 is a good invalid
>>> case. */
>>>    #define INVALID_LPI     0
>>> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>>>    #define INVALID_IRQ     1023
>>>    extern const unsigned int nr_irqs;
>>> +#ifdef CONFIG_GICV3_ESPI
>>> +/* This will cover the eSPI range, to allow asignmant of eSPIs to
>>> domains. */
>>> +#define nr_static_irqs (ESPI_MAX_INTID + 1)
>>> +#else
>>>    #define nr_static_irqs NR_IRQS
>>> +#endif
>>>    struct irq_desc;
>>>    struct irqaction;
>>> @@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
>>>        return irq >= LPI_OFFSET;
>>>    }
>>> +static inline unsigned int espi_intid_to_idx(unsigned int intid)
>>> +{
>>> +    ASSERT(intid >= ESPI_BASE_INTID && intid <= ESPI_MAX_INTID);
>>
>> Can we use is_espi()?
>>
> 
> Yes, sure. I just need to change the function declaration order and then
> I can use is_espi() here. I will do this in V7.
> 
>>> +    return intid - ESPI_BASE_INTID;
>>> +}
>>> +
>>> +static inline unsigned int espi_idx_to_intid(unsigned int idx)
>>> +{
>>> +    ASSERT(idx <= NR_ESPI_IRQS);
>>> +    return idx + ESPI_BASE_INTID;
>>> +}
>>> +
>>> +static inline bool is_espi(unsigned int irq)
>>> +{
>>> +#ifdef CONFIG_GICV3_ESPI
>>> +    return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID;
>>> +#else
>>> +    /*
>>> +     * The function should not be called for eSPIs when
>>> CONFIG_GICV3_ESPI is
>>> +     * disabled. Returning false allows the compiler to optimize the
>>> code
>>> +     * when the config is disabled, while the assert ensures that
>>> out-of-range
>>> +     * array resources are not accessed, e.g., in __irq_to_desc().
>>> +     */
>>> +    ASSERT(irq >= ESPI_BASE_INTID);
>>
>> Regardless what Volodymyr mentioned about the assert!(), I am a bit
>> unsure where we guarantee is_espi() will not be called with an irq <=
>> ESPI_BASE_INTID. In fact, we could have the following code in Xen:
>>
>> if (is_espi(irq))
>> {
>> }
>> else if (is_lpi(irq))
>> {
>> }
>> else
>> {
>> }
>>
>> We could replace the check with "!(irq >= ESPI_BASE_INTID && irq <=
>> ESPI_MAX_INTID)". But I would actually prefer if there is no check
>> because I don't see the value.
>>
> 
> The main reason to add ASSERT here is to trigger it if the config is
> disabled but an eSPI INTID is defined in Xen DTS. 

I will not insist on remove the ASSERT(). However, it could correct and 
we should avoid relying on ASSERT() to catch DTS bugs. Because...

> In this case, instead
> of triggering an ASSERT (as proposed), the following will occur in
> __irq_to_desc:
> 
> // Assume we have irq = 4096
> struct irq_desc *__irq_to_desc(unsigned int irq)
> {
>       // This check will return false
>       if ( irq < NR_LOCAL_IRQS )
>           return &this_cpu(local_irq_desc)[irq];
> 
>       /*
>        * This check will also return false because is_espi()
>        * will always return false when CONFIG_GICV3_ESPI=n.
>        */
>       if ( is_espi(irq) )
>           return espi_to_desc(irq);
> 
>       /*
>        * We will fall through to this point and attempt to access 4064,
>        * which does not exist
>        */
>       return &irq_desc[irq-NR_LOCAL_IRQS];
> }
> 
> So, I think it's better to use ASSERT to simplify error detection in
> debug builds.

... no everyone will use debug build. So if this is the purpose of the 
ASSERT() then we need to have another runtime check during the parsing 
of the DTS.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:11:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:11:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110256.1459525 (Exim 4.92)
	(envelope-from )
	id 1uuAgH-0003Ux-5c; Thu, 04 Sep 2025 14:11:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110256.1459525; Thu, 04 Sep 2025 14:11: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 1uuAgH-0003Uq-1g; Thu, 04 Sep 2025 14:11:17 +0000
Received: by outflank-mailman (input) for mailman id 1110256;
 Thu, 04 Sep 2025 14:11: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 1uuAgG-0003Qe-61
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:11:16 +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 04be17d9-8999-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 16:11:15 +0200 (CEST)
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com (2603:10a6:10:473::15)
 by AS8PR03MB7397.eurprd03.prod.outlook.com (2603:10a6:20b:2e6::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 14:11:11 +0000
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40]) by DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40%7]) with mapi id 15.20.9052.013; Thu, 4 Sep 2025
 14:11: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: 04be17d9-8999-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YWPoAgf+Bhos77kxLeR9njXP3YjoXvkD8di0ORV4+RaQaL4J7SmOZVnXDVGyvaQxfIFp1EUjJuve8CFnlQ+8B5ekDo2ku8jQWhThAqTtkL2F/MvoxN56RHyV6HJmm9tMCCLCiIsfV8ZDaIcaFjQt+tPlqh172tfVKDaRuC1ljwOBmQL7r91SsCstDh5XxfRxUSmELhOU5IZ9enDUHpIcJlkfIPzBWiwUD10YTrKqOyw/Y/L9mWQFzso8QSfzxv4yqFBqiX/J8C+u0XDBg3VR/asBh8HvCkuFmFHcap70pRlD1SeVlng92U5Fxw4WDinpdeMUPy3p1mbUqOI7sUbn9g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=x7VSvec88WS5AbMZw0W6BY+a8Ud6Xy4wc8prC99TZU4=;
 b=vsomYmKqtZX4Ay3qxwG4QlWFPk7ChQv7+CLzTLrh7BdSGgm7p/SHQJL2NBlEVN6Eh4MYrWUPmTsd6kFTioGdRuh5Knzin6EkgLtkS76Owy7VV46W9nRCnXuRhZr8j/+z6UgP5BrQdAVHgC29wDiBDBJWfpCgympchgl9UafO/l6jzeUJD5QOR8I+JwWl+c2oYQmwFj8k0t/6KtqJ+HsKfe5zPIQzwTrZve+XjnZvCAnsFsdcwdRmkJCciKyR1MloUHLlH3cAalVsw+Gb1oZs/cKNUy/UK1uMkRuqdGEQdXHv+RFrRSHqwKfpA3mufrQVnDhhmKQ4e+VivJUqRNWIFw==
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=x7VSvec88WS5AbMZw0W6BY+a8Ud6Xy4wc8prC99TZU4=;
 b=HpgV8DejGIjlVR9FyCSIGY+RCxX8bj/RXs9n+J9SPsiwQFGSR8MXdBsAGh9clV+7uAOlAtJ1be62kfDm+3ElE+UeSkwtJCY9nsXq5nZegT+YENX0D5/5H3MgxeEOL/+TSGk8hUZc1BfoEtgk4742C0CVnrWEjRG9xG6gDFaTVL/0QvMtKB/LoIenkQ59BnVHgtNMRpjw1UHcwukRVkjeKhCo18KRmoww2Jp0bLWuQOpLW7AqnIlLW65pVK60iZR/Evo+9dMzNRX+NNLV2e3Uw6ZGVC77vuJUtNdKxKUzVn+Tk1m8r0SM4938y3Zn83GoY+o4ZEqLSng8zHV1GX3Ywg==
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: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
Thread-Topic: [PATCH v8 0/4] xen/arm: scmi: introduce SCI SCMI SMC
 single-agent support
Thread-Index: AQHcHNVLdhHlv1cXk0a1m6gBYsABvrSB+IIAgAEZUAA=
Date: Thu, 4 Sep 2025 14:11:10 +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: DU0PR03MB8934:EE_|AS8PR03MB7397:EE_
x-ms-office365-filtering-correlation-id: 14880900-7ca4-4a1a-645c-08ddebbce678
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?Mk9xSXgyaGw1ZXpmQTU1dGY2cmxLWFZuTmZwck9QZVlmeHNwYU9SSnlxeUY5?=
 =?utf-8?B?UitzVnhTYnBWOXBHN2FRRUV3Qm1halhRMW04S3NyRUh5VGtTaDJPdUhaV0pM?=
 =?utf-8?B?R2pzU0VQbjVvY0lkRVF1OUJPbGlKTWFrSHlUYnRodkM4d2xlTHU3akdYZzdr?=
 =?utf-8?B?M1NwZjVsUW4wNGRMS3V4VjFWclMxV2VZemtBQXVsaTluY09RdHRQSEl2Yzlj?=
 =?utf-8?B?dVp2b0pwSklBNEc2UXExVFI5dGNhLzhyWlM1cUkyZGxMNUNFelFWSTY3Z2Q4?=
 =?utf-8?B?NUtGWVZnWWxEWENvKzluTzJmQkJlVE9kUDlDQWFiS2xRYmFoNWllRlZhQncw?=
 =?utf-8?B?dUNCSk8xUDVzdWlQREhqVmNTTDdYMGZrSHdJK0ViZ2N1RlZhMUswUWx1VWdG?=
 =?utf-8?B?Zm4za29odlcrRDdXMmxrUjluQkw2MUZaQlAyR1BPYU54NVRBUityM3hiWHZn?=
 =?utf-8?B?WFl2WVA0RndSNlQ1d0EveXhuRVNaMHhLTUxKYVk5cGhvdVV2c2diL1dBOXo0?=
 =?utf-8?B?bVREYUJoaEdNckQ1cmJMSDczeXRFd2YvYkNaVC9Scnd6ak5oVmFjb213OUNj?=
 =?utf-8?B?bkRXM2dyblQwVTA2a3VTYlkxbmtQRzQ1V3poZjV4a2R5S1dpTUhTbjQzZjJ2?=
 =?utf-8?B?NzFmSU1iVXhMTGlycWlhbDhoSWdDbmtZdmhtY29DUFVRTy9vcG9tekpqaVJO?=
 =?utf-8?B?T0FjWlRRUkdOVXdyUUFmTUo4MkxyTGxUSTdDTWw5UEpFZ1Bxc3NUNVVUR0dK?=
 =?utf-8?B?eUwxMjg3R3BVMHI3UjJURnRsdVZ2TURjQXpDSVUrbUpyc0tNRzAyTmpsQzRn?=
 =?utf-8?B?TGtZWVFSdVk0WFN5bHBuWjQ0Q3ZETjQ1ZzVBc3pYR1RzdURERHNYVU56VWJz?=
 =?utf-8?B?VGtTYjRmRUNuamEzUEtXNjlnL2pSSU1md3MvZ3VaWWdJNHU0ekNVUXllQVRi?=
 =?utf-8?B?SzlCc0psa1kvck1CVWpFUXJ2RXloUWgwd1lLSE1udE9LbjlaajloRVNIcjJp?=
 =?utf-8?B?b29TQjRIZzZMWG4rTlBNRXIvVm1FRzVFTHJseEFpUngrZi80SlozL09DTTVs?=
 =?utf-8?B?Z2NRaWtTRld5WTlaTDVVRUdFTEtQUk9Ra2xRMXQxa1YzQWdKdnF5V3g3Z0wr?=
 =?utf-8?B?RHVmc1ZCb1BQQ3RFSCtIZldoelBMQzRDQSsyb080Y1FlN002WG01K0VKczNM?=
 =?utf-8?B?Q1g0ajJ1MmVCRjhXVDZNNnVINUc2bVM1dVlQbys1VktnNit6dldVaDZtMVMw?=
 =?utf-8?B?ZzJNZDllTmFjbzZ4VEY4akg4My8yMVZxU1FSOXVBcW1IRnY0MzdqQmwrY1RK?=
 =?utf-8?B?ZWhEWWMvVTNWOFIrTXhZV1JIQi9LQ3Y3RGJGVEgwa0paQVJKa0grTUtoY2R4?=
 =?utf-8?B?Nk9mc0t2RUNWbStmbTJZZ1dFcG9JbVl6MUFTcnZoV0Z1TTgxK2N6K2dsNGlT?=
 =?utf-8?B?VWFtZXEzS0ZKbzg2a3F5K1gxdy9DcGhud0ljWjRPVmRGVTNjRGk2M2RUb1oy?=
 =?utf-8?B?Z1pLZmVVZGNNZG1PeHFLWG9VLzI3c3VWSW5lUy9Hb3JSOGo2bGVyVEFTc1RP?=
 =?utf-8?B?bGlGcjJzSjNtcGlaRzVrZjNJcGFiVVVPMnBqdlpIc29kNHFIcjJZMm9CQlly?=
 =?utf-8?B?U3g0c0dHTnMwVDBXTllnTmRwVHNWVWdKYTRJeXRCa3lwMnAreHF0dFlxWlM5?=
 =?utf-8?B?QWhFa3gyRjBEYmhKV2VndUIrL2NJVTNoVHQ3eXIxSWh4Uyszb294SFBMOWJC?=
 =?utf-8?B?WU9tN1RwN3NmcFcvcVJVWjRRbCs3OFhwVzJ5dE0rU3BoOHE1L1lpRzRoZGhX?=
 =?utf-8?B?M3YwZTVZZE9GTmU4R1ZWbkJxM2YzYTBPSDdzcGdUK2FvNUhjanNzVGVYeS9i?=
 =?utf-8?B?THFVQlA3M0dGaFNEcWw4cnRXZnBJUGxjSitKZXNoZHp6bCtNOW1qUjQxV21Q?=
 =?utf-8?Q?Sa1SUlhW95I=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8934.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?S1hpRUFtYXdUOTFrQk5EZmUrZTFoNHZiZTVsYmdNUnBCNS9tVDZ0ci81UzRx?=
 =?utf-8?B?NnRxUHVtbkdQelhRYUo4V0dXRmlDbk84bCtFWU50Q3JVNEsxeGhWdnNBVlh3?=
 =?utf-8?B?S1JuRlFzVVFDQldGUGJjTG5XTlhRTVlFWGN0Nk1VQTJ1UUwxWk1ObHFkRElH?=
 =?utf-8?B?Umcya2FacndKcjRPTnVMUUpIeVJVdGdrS01MZ2hEMHRGRThQemxpcDNqWFov?=
 =?utf-8?B?UlluOUVVdUNLZ2U1QldkWFRZSHRnMWY4a0ozb2xLZFJrRUNRTDZKYUUyN3VD?=
 =?utf-8?B?ZFRLTFJNczVBUnZhcS9SVkc5T2Vmb2xDak9CNHRGTEZ2L1NiMUdsM1BDRUZ3?=
 =?utf-8?B?dnQ4NU5yMFRyZFUvK0VWZTlrTGFJcUh4ZFBIc01uekl0cWM0cXFRcDFBQWZ2?=
 =?utf-8?B?ekVpa25STmJCemlXVkJVUXVPOEY3blQrVFFaNytjQVFDbnp3Y2tzam9lZ2dN?=
 =?utf-8?B?SHF5VWNXTTVPUDhiVzBmMlJnVFNmV0FMU1lnTnRhaGpoMGpIU241OWFrZHFw?=
 =?utf-8?B?QWtURXVsOEtueldxeTZKUFMzNnlxTjdmNnNZY01XWmRIMWRaUGhXWkRnemRS?=
 =?utf-8?B?OE5XVVNWU2FyM1lMNnZpQ0FjK08xeEhQQ1l3U3NIYk5ZWjVXNkhlTWdkcTlH?=
 =?utf-8?B?emwzNklrVjRCT3BwSjJhVy93N25xajNUSVByZUJOZTR2anZudks1OGhZakpT?=
 =?utf-8?B?Ky9UQnBHUGRab2x4SmFJRExIUnNYRHZ1aXFKcGIrSWxLV0ZZVVFzNEY4WWdW?=
 =?utf-8?B?S2YrNXZ3d0tQTkRJWEwvSlhYdFd4RStQQ09KcXIzY0dmRytCa1RYazlYZ01z?=
 =?utf-8?B?TzdBc21kUHgzNzBRVUN3Kzg1Tzl6MktXLzAzRmhyRG5uRmhHVzhxTDJIUDc3?=
 =?utf-8?B?YU9UUE1od1BjNUhSZXBONGtrdXBaWngrcjU4MkhGaTJEWnZiZXl2TkJ2TUNS?=
 =?utf-8?B?cVpKaVg3NUIzQmh2b2drSnZZek85RHR2MVJoQkhIUG56S3lVdEJ2S2tya0F6?=
 =?utf-8?B?cmdvbHRkVWd2U1BZZC9vWkJuc1lGVEdlQUhLTVc5bUFibThjMCtPaVVGUjZh?=
 =?utf-8?B?UitONmVzYklSTkxnZ2d0b2ZtKytiZk85dzdZZ2RrRUllTzlxTkVFTUVkRGJu?=
 =?utf-8?B?clczYVpYWlF6Rk00aWFyMTFYOFZTS1dpQXV2cXM3REozM3RKZWQ0bHdsRjY2?=
 =?utf-8?B?eTk0V0w2cWNteUpYSFZHQWs2ZnJZN0VyTWxhV21GZzJFV0l4ZjRUU3J3QTFB?=
 =?utf-8?B?TG5EcjVJVEZqZ2Q4QzllZ1hsdWY5V3V3azlPSUpIUDVSNmtHaGRxNmJQM0Jj?=
 =?utf-8?B?WkR0L1kzbWhRakgrazVwWUZMTVFjZXdtdk5ZalRwdEZIQ1FDOTZoNXhoc053?=
 =?utf-8?B?L21Fa0pDc0wyUFloeTVid0lISlNMTER4WlVaT0grclVVK21TMzV6aUR4QnY2?=
 =?utf-8?B?ZFVoNG0rdjROaFhkOW5Zc2dJVk1ZV1gxRjVTNEVzUEVDcEJSNGlSbnpyUXhr?=
 =?utf-8?B?NkpDRkJKaWdPOHA1WUk2ZVRwTy9lb2t1U1lNOEhWeDl5V0dwZXFnQVc5OUxm?=
 =?utf-8?B?ZTAzclVZbExseE1CQTV1Wnl2aGx6NldkSVpJeXBzNk9WTkZzVyt0RjZCcHhW?=
 =?utf-8?B?bG01NGdnUHRpdDhLMnVCcktQUy9tVnB3dk1iV29ZMGZzcHFDNDdtNXQ5UzlF?=
 =?utf-8?B?dENLY3lubzk3YW9XNXJrb1JIaExRYllCaTBFdkV0MXk2UkFjQVlxeUErbFFl?=
 =?utf-8?B?bUdHb1ZxalBKQ2JGQmhld0tiTlIySXlFa3NLL21UTnhWM0JSVGhXSlVZbVhn?=
 =?utf-8?B?bWxEKzRxWnU1ak5WRG5ZU2h2TXllWW9JRVhuOFoyZVhrOCsrYmZIRVZKWDlI?=
 =?utf-8?B?SW56WjRPQ0trbU5Xc3g1akJpc1lWSGNDUTQ0THJWemtRaTl0dXZsL1QreUJ0?=
 =?utf-8?B?OTZrZktQNlY1aWhMbXIwZkxOOG1HeFVzZlhXd25mL2lDOFdPWDNFTkV4ZHYr?=
 =?utf-8?B?YStSUVA2K2JBYjZCVG9tT3djYXdXaUl3REtCT2pwdXNXU21Da0ZhK1JGbUNr?=
 =?utf-8?B?eVU0bjlwS3FXZ1lFZFdBc2hqa1FnZzc4bGwzcld6Y2I3eS9RektCN0RwclRQ?=
 =?utf-8?B?YUNSQ1lJUHorNDFRQWFaUmU1cCtpOUI0RG5EczRWVGFWK0QxT1BjRERqV3dK?=
 =?utf-8?B?R2c9PQ==?=
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: DU0PR03MB8934.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14880900-7ca4-4a1a-645c-08ddebbce678
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 14:11:10.9316
 (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: S2m2zXpkaMxYuUiycbhxi6/7yyug0/4p8GevBl7gH2jbxAI9rjUhu2BDdXPJwRMJ6Ka9OZS6noZEGOKirsPaqA4vBd0XKezHmGTtSYpawx8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7397

SGkgU3RlZmFubywNCkkgZml4ZWQgTUlTUkEgcnVsZXMgdmlvbGF0aW9uIGFuZCBub3cgUGlwZWxp
bmUgcGFzc2VzIHdpdGggbm8gcmVncmVzc2lvbnM6DQpodHRwczovL2dpdGxhYi5jb20veGVuLXBy
b2plY3QvcGVvcGxlL2RpbWFwcmtwNGsveGVuLy0vcGlwZWxpbmVzLzIwMjIwMjIwMTMNCg0KSSB3
aWxsIHNlbmQgVjkgd2l0aCB1cGRhdGVzLg0KDQpCUiwNCk9sZWtzaWkNCg0KT24gMDQvMDkvMjAy
NSAwMDoyNCwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPiBIaSBPbGVrc2lpLA0KPg0KPiBJ
dCBpcyBzdGlsbCBub3QgcGFzc2luZyB0aGUgY2ktbG9vcCwgdGhpcyB0aW1lIGR1ZSB0byBNSVNS
QS4gU2VlIHRoZSB0d28NCj4gbmV3IDguMyBhbmQgOC40IHZpb2xhdGlvbnMgKHByZXZpb3VzbHkg
emVybykgYW5kIGFsc28gbmV3IGFkZGl0aW9uYWwNCj4gMTIuMiwgMTMuMSB2aW9sYXRpb25zOg0K
Pg0KPiBodHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxlL3NzdGFiZWxsaW5pL3hl
bi8tL3BpcGVsaW5lcy8yMDIwNTQ1NTQ0DQo+DQo+IGh0dHBzOi8vZWNsYWlyLWFuYWx5c2lzLWxv
Z3MueGVucHJvamVjdC5vcmcvZnMvdmFyL2xvY2FsL2VjbGFpci94ZW4tcHJvamVjdC5lY2RmL3hl
bi1wcm9qZWN0L3Blb3BsZS9zc3RhYmVsbGluaS94ZW4vRUNMQUlSX25vcm1hbC9wcHAyL0FSTTY0
LzExMjM4MDc2MTU2L1BST0pFQ1QuZWNkOy9ieV9zZXJ2aWNlLmh0bWwjc2VydmljZSZraW5kDQo+
DQo+IHBlciBjb21wYXJpc29uLCB0aGlzIGlzIHRoZSBiYXNlbGluZToNCj4gaHR0cHM6Ly9lY2xh
aXItYW5hbHlzaXMtbG9ncy54ZW5wcm9qZWN0Lm9yZy9mcy92YXIvbG9jYWwvZWNsYWlyL3hlbi1w
cm9qZWN0LmVjZGYveGVuLXByb2plY3QvaGFyZHdhcmUveGVuL0VDTEFJUl9ub3JtYWwvc3RhZ2lu
Zy9BUk02NC8xMTIzMjA2MTY0NC9QUk9KRUNULmVjZDsvYnlfc2VydmljZS5odG1sI3NlcnZpY2Um
a2luZA0KPg0KPiBUaGVzZSBhcmUgdGhlIG5ldyA4LjMgYW5kIDguNCB2aW9sYXRpb25zOg0KPg0K
PiBodHRwczovL2VjbGFpci1hbmFseXNpcy1sb2dzLnhlbnByb2plY3Qub3JnL2ZzL3Zhci9sb2Nh
bC9lY2xhaXIveGVuLXByb2plY3QuZWNkZi94ZW4tcHJvamVjdC9wZW9wbGUvc3N0YWJlbGxpbmkv
eGVuL0VDTEFJUl9ub3JtYWwvcHBwMi9BUk02NC8xMTIzODA3NjE1Ni9QUk9KRUNULmVjZDsvYnlf
c2VydmljZS9NQzNBMi5SOC4zLmh0bWwjeyUyMnNlbGVjdCUyMjp0cnVlLCUyMnNlbGVjdGlvbiUy
Mjp7JTIyaGlkZGVuQXJlYUtpbmRzJTIyOltdLCUyMmhpZGRlblN1YmFyZWFLaW5kcyUyMjpbXSwl
MjJzaG93JTIyOmZhbHNlLCUyMnNlbGVjdG9yJTIyOnslMjJlbmFibGVkJTIyOnRydWUsJTIybmVn
YXRlZCUyMjp0cnVlLCUyMmtpbmQlMjI6MCwlMjJkb21haW4lMjI6JTIya2luZCUyMiwlMjJpbnB1
dHMlMjI6W3slMjJlbmFibGVkJTIyOnRydWUsJTIydGV4dCUyMjolMjJ2aW9sYXRpb24lMjJ9XX19
fQ0KPg0KPiBodHRwczovL2VjbGFpci1hbmFseXNpcy1sb2dzLnhlbnByb2plY3Qub3JnL2ZzL3Zh
ci9sb2NhbC9lY2xhaXIveGVuLXByb2plY3QuZWNkZi94ZW4tcHJvamVjdC9wZW9wbGUvc3N0YWJl
bGxpbmkveGVuL0VDTEFJUl9ub3JtYWwvcHBwMi9BUk02NC8xMTIzODA3NjE1Ni9QUk9KRUNULmVj
ZDsvYnlfc2VydmljZS9NQzNBMi5SOC40Lmh0bWwjeyUyMnNlbGVjdCUyMjp0cnVlLCUyMnNlbGVj
dGlvbiUyMjp7JTIyaGlkZGVuQXJlYUtpbmRzJTIyOltdLCUyMmhpZGRlblN1YmFyZWFLaW5kcyUy
MjpbXSwlMjJzaG93JTIyOmZhbHNlLCUyMnNlbGVjdG9yJTIyOnslMjJlbmFibGVkJTIyOnRydWUs
JTIybmVnYXRlZCUyMjp0cnVlLCUyMmtpbmQlMjI6MCwlMjJkb21haW4lMjI6JTIya2luZCUyMiwl
MjJpbnB1dHMlMjI6W3slMjJlbmFibGVkJTIyOnRydWUsJTIydGV4dCUyMjolMjJ2aW9sYXRpb24l
MjJ9XX19fQ0KPg0KPiBDaGVlcnMsDQo+DQo+IFN0ZWZhbm8NCj4NCj4gT24gV2VkLCAzIFNlcCAy
MDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IElucm9kdWNpbmcgVjggcGF0Y2ggc2Vy
aWVzICBvbiB0b3Agb2YgdGhlIFhlbiB2ZXJzaW9uIDQuMjAtcmMyDQo+PiB3aGljaCBpbmNsdWRl
cyBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgU0NJIFNDTUkgU01DIHNpbmdsZS1hZ2VudCBzdXBwb3J0
Lg0KPj4NCj4+IFRoaXMgcGF0Y2ggc2VyaWVzIGlzIHRoZSBmaXJzdCBjaHVuayBvZiB0aGUNCj4+
ICJ4ZW4vYXJtOiBzY21pOiBpbnRyb2R1Y2UgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50IHN1cHBv
cnQiIHdoaWNoIGNhbg0KPj4gYmUgZm91bmQgYXQgWzBdDQo+Pg0KPj4gU0NNSS1tdWx0aWFnZW50
IHN1cHBvcnQgd2lsbCBiZSBwcm92aWRlZCBhcyB0aGUgZm9sbG93dXAgcGF0Y2ggc2VyaWVzLg0K
Pj4NCj4+IFswXSBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMTc1MzE4
NDQ4Ny5naXQub2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20vDQo+Pg0KPj4gUGF0Y2ggMSAieGVu
L2FybTogYWRkIGdlbmVyaWMgU0NJIHN1YnN5c3RlbSINCj4+IC0gcmViYXNlZCBhbmQgcmVmYWN0
b3JlZA0KPj4gLSBpbnRyb2R1Y2VkIERFVklDRV9BUk1fU0NJIERUIGRldmljZSBjbGFzcyBhbmQg
dXNlZCBmb3IgU0NJIGRyaXZlcnMgcHJvYmluZw0KPj4gaW5zdGVhZCBvZiBjdXN0b20sDQo+PiAg
ICBsaW5rZXIgc2VjdGlvbnMgYmFzZWQgaW1wbGVtZW50YXRpb24uDQo+PiAtIGFkZGVkIFNDSSBB
UEkgZm9yIERvbTAgRFQgaGFuZGxpbmcsIGluc3RlYWQgb2YgbWFuaXB1bGF0aW5nIHdpdGggQVJN
IGFyY2gNCj4+IGRvbTAgY29kZSBkaXJlY3RseS4NCj4+IC0gUkZDIGNoYW5nZXMgaW4gWEVOX0RP
TUNUTF9hc3NpZ25fZGV2aWNlIE9QIHByb2Nlc3NpbmcNCj4+IC0gSW50cm9kdWNlIGFyY2hfaGFu
ZGxlX3Bhc3N0aHJvdWdoX3Byb3AgY2FsbCB0byBoYW5kbGUgYXJtIHNwZWNpZmljDQo+PiBub2Rl
cw0KPj4NCj4+IFBhdGNoIDIgInhlbi9hcm06IHNjbWktc21jOiB1cGRhdGUgdG8gYmUgdXNlZCB1
bmRlciBzY2kgc3Vic3lzdGVtIg0KPj4gLSB1cGRhdGUgZHJpdmVyIGludHJvZHVjZWQgYnkgY29t
bWl0IDNlMzIyYmVmOGJjMCAoInhlbi9hcm06IGZpcm13YXJlOiBBZGQgU0NNSQ0KPj4gb3ZlciBT
TUMgY2FsbHMNCj4+IGhhbmRsaW5nIGxheWVyIikgYmUgdXNlZCB1bmRlciBzY2kgc3Vic3lzdGVt
Lg0KPj4gLSBubyBmdW5jdGlvbmFsIGNoYW5nZXMgaW4gZ2VuZXJhbA0KPj4NCj4+IFBhdGNoIDMg
Inhlbi9hcm06IHNjbWktc21jOiBwYXNzdGhyb3VnaCBTQ01JIFNNQyB0byBndWVzdCBkb21haW4N
Cj4+IFRoaXMgaXMgbmV3IGNoYW5nZSB3aGljaCBhbGxvd3MgcGFzc3Rocm91Z2ggU0NNSSBTTUMs
IHNpbmdsZSBhZ2VudCBpbnRlcmZhY2UgdG8NCj4+IGd1ZXN0IGRvbWFpbg0KPj4gY292ZXIgdXNl
IGNhc2UgInRoaW4gRG9tMCB3aXRoIGd1ZXN0IGRvbWFpbiwgd2hpY2ggc2VydmVzIGFzIERyaXZl
ciBkb21haW4iLg0KPj4gU2VlIHBhdGNoIGNvbW1pdCBtZXNzYWdlIGZvciBmdWxsIGRlc2NyaXB0
aW9uLg0KPj4NCj4+IFBhdGNoIDQgLSBkb2NzOiBhcm06IGFkZCBkb2NzIGZvciBTQ01JIG92ZXIg
U01DIGNhbGxzIGZvcndhcmRpbmcNCj4+IGRyaXZlcg0KPj4gLSBhZGQgZG9jdW1lbnRhdGlvbiBz
ZWN0aW9uIGZvciBTaW1wbGUgQXJtIFNDTUkgb3ZlciBTTUMgY2FsbHMNCj4+IGZvcndhcmRpbmcg
ZHJpdmVyLg0KPj4NCj4+IENvZGUgY2FuIGJlIGZvdW5kIGF0Og0KPj4gaHR0cHM6Ly9naXRodWIu
Y29tL29sZWtzaWltb2lzaWVpZXYveGVuL3RyZWUvc2NtaV91cHN0cnY1DQo+Pg0KPj4gWzFdIFJG
QyB2MjoNCj4+IGh0dHA6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9j
b3Zlci9jb3Zlci4xNjQ0MzQxNjM1LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCj4+
IFsyXSBSRkMgdjM6DQo+PiBodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVu
LWRldmVsL3BhdGNoLzIwMjUwMzExMTExNjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hrb0Bl
cGFtLmNvbQ0KPj4gU0NNSSBzcGVjOg0KPj4gaHR0cHM6Ly9kZXZlbG9wZXIuYXJtLmNvbS9kb2N1
bWVudGF0aW9uL2RlbjAwNTYvZS8/bGFuZz1lbg0KPj4NCj4+IFNDTUkgYmluZGluZ3M6DQo+PiBo
dHRwczovL3dlYi5naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFs
ZHMvbGludXguZ2l0L3RyZWUvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Zpcm13
YXJlL2FybSxzY21pLnlhbWwNCj4+IGh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20v
bGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2Rl
dmljZXRyZWUvYmluZGluZ3MvYWNjZXNzLWNvbnRyb2xsZXJzL2FjY2Vzcy1jb250cm9sbGVycy55
YW1sDQo+Pg0KPj4gUmVmZXJlbmNlIEVMMyBGVzoNCj4+IFJQSTU6IGh0dHBzOi8vZ2l0aHViLmNv
bS94ZW4tdHJvb3BzL2FybS10cnVzdGVkLWZpcm13YXJlL2NvbW1pdHMvcnBpNV9kZXYvDQo+PiBS
ZW5lc2FzIHY0aDoNCj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9HcnlnaXJpaVMvYXJtLXRydXN0ZWQt
ZmlybXdhcmUvY29tbWl0cy9yY2FyX2dlbjRfdjIuN192NHgtc2NtaV91cGQvDQo+Pg0KPj4gYmFz
ZS1jb21taXQ6IGRiZTYwZjI0NGMgKFVwZGF0ZSBYZW4gdG8gNC4yMSwgMjAyNS0wMi0yMSkNCj4+
DQo+PiBDaGFuZ2VzIGluIHY4Og0KPj4gLSByZW5lcmVnYXRlZCB7aGVscGVycy90eXBlc30uZ2Vu
LmdvLCBkcm9wcGVkIHVubmVlZGVkIHBhcmFtZXRlcnMNCj4+DQo+PiBDaGFuZ2VzIGluIHY3Og0K
Pj4gLSBmaXggc2NpX2hhbmRsX2NhbGwgdG8gbWFrZSBjaGFuZ2VzIG1vcmUgcmVhZGFibGUNCj4+
IC0gZml4IGJ1aWxkIGVycm9yIHdoZW4gRE9NMExFU1NfQlVJTEQgaXMgZGlzYWJsZWQgKHJlbW92
ZWQNCj4+ICAgYXJjaF9oYW5kbGVfcGFzc3Rocm91Z2hfcHJvcCBmcm9tIHRoZSBoZWFkZXIpDQo+
PiAtIHNvcnQgaGVhZGVycyBpbiBhbHBoYWJldGljYWwgb3JkZXIgaW4gc2NpLmgNCj4+IC0gc29y
dCBoZWFkZXJzIGluIHNjbWktc21jLmMgZmlsZQ0KPj4gLSBGaXggY29tbWl0IGRlc2NyaXB0aW9u
Lg0KPj4gLSBNb3ZlIHNjbWktc21jLXBhc3N0aHJvdWdoIGRlZmluaXRpb24gdG8gbWF0Y2ggYWxw
aGFiZXJpY2FsIG9yZGVyDQo+PiAtIHJlbW92ZSB1bm5lZWRlZCBpbml0aWFsaXphdGlvbiB3aXRo
IE5VTEwNCj4+IC0gY2hhbmdlZCB1NjQgdG8gdWludDY0X3QNCj4+IC0gU2VuZCB3YXJuaW5nIGlm
IGlvbWVtIHBlcm1pdCBhY2Nlc3Mgd2FzIGZhaWxlZA0KPj4gLSBmaXhlZCB0eXBvcw0KPj4NCj4+
IENoYW5nZXMgaW4gdjY6DQo+PiAtIHJlYmFzZSBvbiB0b3Agb2YgdGhlIGxhdGVzdCBtYXN0ZXIN
Cj4+IC0gZml4IHJldHVybiB2YWx1ZSBvZiBzY2lfZHRfZmluYWxpemUoKSBjYWxsDQo+PiAtIGFk
ZCBSLWIgdGFnDQo+PiAtIGFkZGVkIGdlbmVyYXRlZCBoZWxwZXJzIGFuZCB0eXBlcyBnbyBmaWxl
cw0KPj4gLSByZW5hbWUgY21kbGluZSBwYXJhbWV0ZXIgdG8gc2NtaS1zbWMtcGFzc3Rocm91Z2gN
Cj4+IC0gZml4IGdvdG8gdGFnIGluIHBhcnNlX2FybV9zY2lfY29uZmlnDQo+PiAtIGFkZCBsaW5r
IHRvIHRoZSBzY21pIGJpbmRpbmdzIHVzZWQgaW4gdGhlIGRvYw0KPj4gLSByZW1vdmUgbWVudGlv
bnMgYWJvdXQgSFZDIGNhbGxzIGZyb20gZG9jDQo+PiAtIHJlbmFtZSBjbWRsaW5lIHBhcmFtZXRl
ciB0byBzY21pLXNtYy1wYXNzdGhyb3VnaA0KPj4NCj4+IENoYW5nZXMgaW4gdjU6DQo+PiAtIHVw
ZGF0ZSBNYWludGFpbmVycyBmaWxlLiBTZXQgcm9sZSBhcyBhIFJldmlld2VyDQo+PiAtIHJlYmFz
ZWQgb24gdGhlIGxhdGVzdCBtYXN0ZXIgYnJhbmNoDQo+PiAtIEludHJvZHVjZSBhcmNoX2hhbmRs
ZV9wYXNzdGhyb3VnaF9wcm9wIGNhbGwgdG8gaGFuZGxlIGFybSBzcGVjaWZpYyBub2Rlcw0KPj4g
LSByZW5hbWUgZG9tMF9zY21pX3NtY19wYXNzdGhyb3VnaCB0byBzY21pX3NtY19wYXNzdGhyb3Vn
aA0KPj4gLSByZW5hbWUgZG9tMF9zY21pX3NtY19wYXNzdGhyb3VnaCBpbiBkb2N1bWVudGF0aW9u
DQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NDoNCj4+IC0gZml4IFNQRFgtTGljZW5zZQ0KPj4gLSByZW5h
bWUgREVWSUNFX0FSTV9TQ0kgRFQgZGV2aWNlIGNsYXNzIHRvIEZJUk1XQVJFX0RFVklDRQ0KPj4g
LSBtb3ZlIFhFTl9ET01DVExfYXNzaWduX2RldmljZSBjb2RlIGluIHNlcGFyYXRlIHBhdGNoDQo+
PiAtIEFkZCBkb2N1bWVudGF0aW9uIGZvciBTQ0kgU0NNSSBkcml2ZXJzDQo+PiAtIHhsLmNmZyBk
b2MNCj4+IC0gZml4IGNvbW1lbnRzIGZyb20gU3RlZmFubyBTdGFiZWxsaW5pDQo+PiAtIGZpeCB0
b29sc3RhY2sgY29kZSBhcyBzdWdlc3RlZCBieSBBbnRob255IFBFUkFSRA0KPj4gICAgLSB1c2Ug
TUFUQ0hfT1BUSU9OKCkNCj4+ICAgIC0gbW92ZSBhcm1fc2NpIHN0cnVjdCBhbmQgY2ZnIHBhcmFt
cyBpbiAiYXJjaF9hcm0iDQo+PiAtIGFkZCBTQ01JIHBhc3N0aHJvdWdoIGZvciBkb20wbGVzcyBj
YXNlDQo+Pg0KPj4gR3J5Z29yaWkgU3RyYXNoa28gKDMpOg0KPj4gICAgeGVuL2FybTogc2NtaS1z
bWM6IHVwZGF0ZSB0byBiZSB1c2VkIHVuZGVyIHNjaSBzdWJzeXN0ZW0NCj4+ICAgIHhlbi9hcm06
IHNjbWktc21jOiBwYXNzdGhyb3VnaCBTQ01JIFNNQyB0byBkb21haW4sIHNpbmdsZSBhZ2VudA0K
Pj4gICAgZG9jczogYXJtOiBhZGQgZG9jcyBmb3IgU0NNSSBvdmVyIFNNQyBjYWxscyBmb3J3YXJk
aW5nIGRyaXZlcg0KPj4NCj4+IE9sZWtzaWkgTW9pc2llaWV2ICgxKToNCj4+ICAgIHhlbi9hcm06
IGFkZCBnZW5lcmljIFNDSSBzdWJzeXN0ZW0NCj4+DQo+PiAgIE1BSU5UQUlORVJTICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNiArDQo+PiAgIC4uLi9hcm0vZmlybXdhcmUv
YXJtLXNjbWkucnN0ICAgICAgICAgICAgICAgICB8IDE4MCArKysrKysrKysrKysrKysrDQo+PiAg
IGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vaW5kZXgucnN0ICAgICAgICAgICB8ICAgOSArDQo+
PiAgIGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9pbmRleC5yc3QgICAgICAgICAgICAgICB8ICAgMSAr
DQo+PiAgIGRvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgICB8ICAz
NCArKysNCj4+ICAgZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCAgICAgICAg
IHwgIDE1ICsrDQo+PiAgIGRvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyAgICAgICAg
ICAgICB8ICAgOSArDQo+PiAgIHRvb2xzL2dvbGFuZy94ZW5saWdodC9oZWxwZXJzLmdlbi5nbyAg
ICAgICAgICB8ICAzNSArKysNCj4+ICAgdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L3R5cGVzLmdlbi5n
byAgICAgICAgICAgIHwgIDExICsNCj4+ICAgdG9vbHMvaW5jbHVkZS9saWJ4bC5oICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgICA1ICsNCj4+ICAgdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0u
YyAgICAgICAgICAgICAgICAgIHwgIDE0ICsrDQo+PiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxf
dHlwZXMuaWRsICAgICAgICAgICAgICB8ICAxMCArDQo+PiAgIHRvb2xzL3hsL3hsX3BhcnNlLmMg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAzNiArKysrDQo+PiAgIHhlbi9hcmNoL2FybS9k
ZXZpY2UuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNSArDQo+PiAgIHhlbi9hcmNoL2Fy
bS9kb20wbGVzcy1idWlsZC5jICAgICAgICAgICAgICAgICB8ICA0MCArKysrDQo+PiAgIHhlbi9h
cmNoL2FybS9kb21haW4uYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMiArLQ0KPj4gICB4
ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgICAgICAgICAgfCAgIDggKw0KPj4g
ICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyAgICAgICAgICAgICAgICAgfCAgMjUgKyst
DQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZSAgICAgICAgICAgICAgICB8ICAg
MSArDQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyAgICAgICAgICAgICAgICAgICB8
IDE1NCArKysrKysrKysrKysrKw0KPj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMu
YyAgICAgICAgICAgICAgfCAxOTQgKysrKysrKysrKysrKy0tLS0NCj4+ICAgeGVuL2FyY2gvYXJt
L2luY2x1ZGUvYXNtL2RvbWFpbi5oICAgICAgICAgICAgIHwgICA1ICsNCj4+ICAgeGVuL2FyY2gv
YXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oICAgICAgIHwgMjAwICsrKysrKysrKysrKysr
KysrKw0KPj4gICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NtaS1zbWMuaCAg
fCAgNDEgLS0tLQ0KPj4gICB4ZW4vYXJjaC9hcm0vdnNtYy5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgIDQgKy0NCj4+ICAgeGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1idWls
ZC5jICAgICAgIHwgICA0ICsNCj4+ICAgeGVuL2luY2x1ZGUvYXNtLWdlbmVyaWMvZGV2aWNlLmgg
ICAgICAgICAgICAgIHwgICAxICsNCj4+ICAgeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgg
ICAgICAgICAgICAgICAgIHwgICA1ICsNCj4+ICAgeGVuL2luY2x1ZGUveGVuL2RvbTBsZXNzLWJ1
aWxkLmggICAgICAgICAgICAgIHwgICAzICsNCj4+ICAgMjkgZmlsZXMgY2hhbmdlZCwgOTgyIGlu
c2VydGlvbnMoKyksIDg1IGRlbGV0aW9ucygtKQ0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgZG9j
cy9oeXBlcnZpc29yLWd1aWRlL2FybS9maXJtd2FyZS9hcm0tc2NtaS5yc3QNCj4+ICAgY3JlYXRl
IG1vZGUgMTAwNjQ0IGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vaW5kZXgucnN0DQo+PiAgIGNy
ZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+ICAgY3JlYXRl
IG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KPj4g
ICBkZWxldGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3Nj
bWktc21jLmgNCj4+DQo+PiAtLQ0KPj4gMi4zNC4xDQo+Pg0K


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:16:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:16:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110273.1459543 (Exim 4.92)
	(envelope-from )
	id 1uuAlh-0004HT-0V; Thu, 04 Sep 2025 14:16:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110273.1459543; Thu, 04 Sep 2025 14:16: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 1uuAlg-0004HM-U9; Thu, 04 Sep 2025 14:16:52 +0000
Received: by outflank-mailman (input) for mailman id 1110273;
 Thu, 04 Sep 2025 14:16: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 1uuAlf-0004HE-VP
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:16:52 +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 cb6e2d02-8999-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 16:16:49 +0200 (CEST)
Received: from BN0PR04CA0127.namprd04.prod.outlook.com (2603:10b6:408:ed::12)
 by MN0PR12MB5980.namprd12.prod.outlook.com (2603:10b6:208:37f::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Thu, 4 Sep
 2025 14:16:46 +0000
Received: from BN2PEPF000044A3.namprd02.prod.outlook.com
 (2603:10b6:408:ed:cafe::f6) by BN0PR04CA0127.outlook.office365.com
 (2603:10b6:408:ed::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 14:16:45 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044A3.mail.protection.outlook.com (10.167.243.154) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9094.14 via Frontend Transport; Thu, 4 Sep 2025 14:16: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; Thu, 4 Sep
 2025 09:16:44 -0500
Received: from [10.71.195.192] (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, 4 Sep 2025 09:16: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: cb6e2d02-8999-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nihkuabmQ+XtHsDCqljTS4KKPKFK4wssaudbcIFIH2BMscQ9wxk4l2d7x46R1UudcYzjdYnsL4/gwzqm2V76eXV3ocz9r2PXpNSpAaZ6+79eoEdDpRMtAEORMqirrPSL5dSZbtKMpAa0j7lgKie4p6rlm5lI/i5htU0KNbkEJhPRmJG53HAaL6CTphVL0JuIXt+GiXoPkUsfYxxrNBI1LowaWq+kIt50/qq/e5yTU1qFEnb0Uzj5IucHV0hxBmC3DAALVAN0Rr97U6YctASsUIYDgA19nqjgh/WYMvQwgmdvVu9khmFGQyk1VwmTTHU0EjSvzM219Qgq1Q/3VCkXGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=73SUVBZ6nW9unotFUaNLknrnE+H2gSnoW980g2+MLUM=;
 b=atAC4rVRKOclXywpus7TbO86BOnlHoQy0CS4R2Q2sczsJWSjEcGpkJzlHpSCEdRljkCUs/UAyAixoXdyKGLMzmt+ZF3mcnNa9l/FrB6g1qwyc+m2gKSoT2gTPmr4R3XrEC3UibI/piKsLItOtT1sNgDh6Qatb/JtVOIA7iQNgk4PgcTssxDBqKk5fGysxtiDowOi+ps5mLQ+5tfyi8U9mdLTms/Hh288xXs9Mja/JLchhtT7IvQfFmapQuG3NwGkozJNL5c0nJzrVUX6LU5Tbh00wM0araFgsh9lVSkOa0S+RcVsXW0H8zOFcNJHwgboj+52PKaU5ae08aIHkEWW0g==
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=73SUVBZ6nW9unotFUaNLknrnE+H2gSnoW980g2+MLUM=;
 b=CF3P7myL7nMAL8DWVO71YwI0XY5z/ZGvXiotMSLeaz1LyxpY9yT3YRBcvnzZtKY3YYwQK5uuK0GwvvMgUcEzVWFbU5wII4rlnqYp+fnC/WdaP5+Ijf+UDl69ivS5xF54rt7IAgdVUI7o+VfpshaDNJzZj49L2CDFQMi+v0JMV/g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <587d2566-b451-4385-ba49-062eca1d2acd@amd.com>
Date: Thu, 4 Sep 2025 15:16:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of
 device tree
Content-Language: en-GB
From: Ayan Kumar Halder 
To: "Orzel, Michal" , Ayan Kumar Halder
	, 
CC: , ,
	, ,
	, 
References: <20250901123103.11418-1-ayan.kumar.halder@amd.com>
 <20f5b553-75a6-43b3-9b2f-1cf73b9589c3@amd.com>
 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: ayankuma@amd.com does not designate
 permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A3:EE_|MN0PR12MB5980:EE_
X-MS-Office365-Filtering-Correlation-Id: 164fba5b-e25a-4082-a8e1-08ddebbdade0
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?cUpveUQzTzBDWHFkbWdUcVZXdlVWZEEwNStOTkRvdmNncHViTFV5YitLSFlZ?=
 =?utf-8?B?QTVYcXdoYUtBdHJ1emtVVjFUcGdOa291WkpJNlh1UW9CYUdsa2drQ1dvNmtu?=
 =?utf-8?B?QkNDL1lVbHN0WVNqWUtsN2QxZDN4a3dkeEt1ZkpWZ2Y1VnRGTWtzcmhCOTQv?=
 =?utf-8?B?bnZNV1pCSUJ6NlRaTWFydFRORUNNQTJtTkNCL1ZiRWNUMW5NUG5hSEFab2Q1?=
 =?utf-8?B?S3FXUURsLzNQZjJnUDhZdmtVVHlpMDlJdUI5dkRHc21tbmk4Q1RydHh2MlFE?=
 =?utf-8?B?ejhtMDRFcXNYSkdRbmpRUW1rTTN2eFBldHBLa0EyVC9Xc0xmWnhnQUxjMnRR?=
 =?utf-8?B?THZnampDRHdWU1dzNzlnOFJRMnBSeGpUc3BoSkdjM3RWV0VmWjZhR29FTEtm?=
 =?utf-8?B?WVR0OWVGSVJSZnJJSHlpYTZXQUVLamE0YmdGTStvSk1ESHFoWVNDUGRmM2xF?=
 =?utf-8?B?TFlkcHRvaW9LT2ltODhWRW5IQ1p4eGRWeTdEVHZ4VnRYaDViTzNCTCt0UkIy?=
 =?utf-8?B?RUJhOTdrVlljN1J3NXdWc05ZWElCRFFweHViMFNTeEtrSUR3OUp4d2RFb2ZD?=
 =?utf-8?B?SzJzdDZPMmFzb2M2UksxbjhnL1phd2JueXAya1BWZ0V1eU9ZUzh2NG5SUUdq?=
 =?utf-8?B?RVNPZ2lkeFNSeDF2VEQ2WTJ0UHhTY1ZHbmIyck9GOXQ3RGdPb01rOERVNit6?=
 =?utf-8?B?L24vZVYyOGQ1QllkelNXWHV3cFFuWXV3aG1vRDF0Q1ZlM3ZDVERSaHhHL0tm?=
 =?utf-8?B?VDlwZmVCRnhhQkJqZE9XcXJqSTBpWUhydDZkb3I4enppZ0RrZEhvcUxzejd6?=
 =?utf-8?B?RXppNk9senVCT0dwQnZYcjZvc1B0dnJHUGw1ckRHMHlGVGdBNWJMdG9yTE1J?=
 =?utf-8?B?QWk2RmMxY25ndjFEcUtpSHVsNzY2aUVWU2hUVEI2SzZkYys1TjdEeWxxT2Nw?=
 =?utf-8?B?UVl0dmNLMlhzL2FrOVRIbCswZ3lFU1BxeTM1TFZMMWxpWG5lYmRFMmw3TUJZ?=
 =?utf-8?B?UGpTcEgrMWxob0hWajd4RzkySGgyVXVobjgwN24xMFFOMWYvWkpPVWdBN0dI?=
 =?utf-8?B?TGxjVVkvTExuU3lEUVdvQzFYVGQ2R25MaGZTcW5UT3IrcHg2anIxa01qSGty?=
 =?utf-8?B?Y2dTS0FYTjlVT2I2dllUZEQ4bU5xYjlJbmJwaGhwcXUwaGJkeTR3bnJ1RGox?=
 =?utf-8?B?KzE3TTNnMjVOczJBMDBaRklwcFgrMkVCZ21DQlJXZnkwdUVRR3ZSNVNvQ3N4?=
 =?utf-8?B?M1d0ZGxRSnloMkxEM1hCeVE2L0dDS0h5TklBR1lOUmYwSVlkNUFobkJNTDdm?=
 =?utf-8?B?NjAvQVJsa09uRk9tZFAwVXVSZ0J4ZDdPMFk3QnRnYUs0SjV4NzZ0R2IxaGJW?=
 =?utf-8?B?M3BJc0Y0RzJZazcrYlgxeWRpSkJEUFY4SS9NcmtKZGNpT1RqVWZrRTYrNS9M?=
 =?utf-8?B?N2NZZVp5SnVWNGdDQlc2WWtkdmV1SE1za24zNyt0UWU4bzNYdkNTRXZpQ1Zq?=
 =?utf-8?B?UE9DWUV1Um5Id3d1eFdGajQ5cmExQkRPZGhSVmxOV3kvY0p4MFIyenUraUR4?=
 =?utf-8?B?dHZzVFFGb3pTUEhzQzRrR3pBM1ZmT2JYYnpURTRxTk1qcDc1NlhSYlJnSkI5?=
 =?utf-8?B?UnJNdjhrZW44bFFwNk1vVmV0STZMdzd3b2h4VC95WVkzUnNhVGZNYWxYT0ll?=
 =?utf-8?B?UWJ2dmsvMEdhZjNML3hoT2Z4TU84MGJqdEtIQmYyRzlxNVEzUHlkelZJWlBI?=
 =?utf-8?B?eTQ4aTJxVDIvU1Vrbk9rMlZQRWUvcE5naERjMDhnbGFlQmwydE9jbmJlV3kx?=
 =?utf-8?B?aldFNFBaYnVjZnZoeXIzUDk1Nmh2SHBMS0NMUzVWc3c3Q0NkMkU2d3VncHR3?=
 =?utf-8?B?RDlGd2lFUTl4VTI3R1NzS09vMThHNUsvWkd0M2NNUVQ3MTR2b3Exc0JnTldj?=
 =?utf-8?B?cGkvaXlETDI2YnIxeDlUWG5wRXA3dGNFR1d3eW4wekVrdXNWSUZHWlY2SDZl?=
 =?utf-8?B?V05GeHZFWk96NFlJUDVvSGZUcGZ4ZCtOdE8wMWlmVm51c25KVzlRNExzRTBS?=
 =?utf-8?Q?bxasQz?=
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: 04 Sep 2025 14:16:45.4573
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 164fba5b-e25a-4082-a8e1-08ddebbdade0
X-MS-Exchange-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:
	BN2PEPF000044A3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5980

Hi,

On 01/09/2025 14:51, Ayan Kumar Halder wrote:
> Hi Michal,
>
> On 01/09/2025 14:17, Orzel, Michal wrote:
>>
>> On 01/09/2025 14:31, Ayan Kumar Halder wrote:
>>> Xen gives a panic if certain nodes are not present in the device 
>>> tree. In order
>>> to prevent this panic, scripts/dt_sanity.py is written so that it 
>>> checks if the
>>> node/s are present. If the node/s are not present, the script gives 
>>> an error.
>>>
>>> User is expected to run the script against the device tree before 
>>> booting Xen
>>> with dtb.
>>
One thing I forgot to mention is that as part of safety certification, 
we do need to do "Failure mode and error analysis". This means 
describing the scenarios in which Xen can fail to perform its regular 
functionality and coming up with prevention, detection and mitigation 
measures.

One can argue that the panics caused by system misconfiguration, are the 
most straightforward of all the errors. However, we do need to define 
prevention mechanisms to avoid these panics. For this particular 
failure, the prevention mechanism can be described as manually looking 
into the device tree to ensure that the nodes expected by Xen, are 
present. The script aims to provide a better alternative.

This script is not meant to catch all possible panics. However we do 
want to have such scripts and utilities wherever possible, and document 
them as part of our FMEA.

May be a safety expert can comment if the approach makes sense.

- Ayan




From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:21:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:21:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110284.1459553 (Exim 4.92)
	(envelope-from )
	id 1uuAqG-0005uC-H9; Thu, 04 Sep 2025 14:21:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110284.1459553; Thu, 04 Sep 2025 14:21: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 1uuAqG-0005u5-E1; Thu, 04 Sep 2025 14:21:36 +0000
Received: by outflank-mailman (input) for mailman id 1110284;
 Thu, 04 Sep 2025 14:21:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuAqF-0005ts-5N
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:21:35 +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 738afa84-899a-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:21:32 +0200 (CEST)
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com (2603:10a6:10:473::15)
 by GV2PR03MB8751.eurprd03.prod.outlook.com (2603:10a6:150:a8::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 14:21:27 +0000
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40]) by DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40%7]) with mapi id 15.20.9052.013; Thu, 4 Sep 2025
 14:21: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: 738afa84-899a-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HzYTTyIzkMz75hspOv4c8PL41TdIzkkZsfKTCB8NJMRyy9rnCAeLK92wwvI3n5/awN4LdhMdBy5uGMsYuDOdGegKcm8iVpg06Vd7LBda4CfQQiPGr7bjfvW6DZ7muGg3iLP/+xCX9XjJlI1Jz+oxL4P/hvL+ffoKn1G/xepfxO4RdEvu7Cc6DldNnfq6HMDSZp9a+9R4KZVt7zjXLHY0n3Q67R5V4+3yQS2xyc8oKDhnNRAoNa+5i2TMtLJP4rvoPwirZ3MNNzhcxqwHxtmryWndTeWWpPajo2bhYK/ZbE2VoO+VN3Za2wxIhzuBsb7sWMx5F+51RARkxZbKolZtmA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fyzgNUPMD4DoamZnO5QjUZVFClHUGb02FXxvOb3EUcc=;
 b=SQJWuGo1lGVXFYDAkg+Igbl/JoaAmWXzf6YSaSP8H3yCrOrg3k9hJd3HoGRxEAgpYisoGxVx5vEi0JH+W+9y6VdhgqGrNeA9GIQ38ZUrilXnEP5Bw1WdyNWMsUBEkZMlEufIiqKcmfCysIq8UM5PhjsiwXj5KlhIBGJW0O37UbzlQUqZkHIzO413+eSzgCh/8Q2RF8tw2P+e73eF02HD+5WIH/VbVqB9YGRSjCRAg5o9jzWKeRMpWF1TDyR8U3QVm5HND/M+SWioCEfjsyMNTQFoqA9zKzuog1vIE+q/EylYb+IrPNqT9qI2cNhKTPINahAp/AzO5zP4xPPWw27fPg==
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=fyzgNUPMD4DoamZnO5QjUZVFClHUGb02FXxvOb3EUcc=;
 b=h9y10R9DAYEVedbVzb9e/lnxtLBvN3dTtCxXRlMuNBGbluJS5MA0qvq854FlBqHxAnXP/Uyjym5/YUSrm5FlZ/Yj598UFC+0zvwZJK4erS/3KbWsaz/N8TGeBTy5mUH0ek4QrG1/Ygz5T6OF5ux5iJhVfW5mktR424ECBRp/XaHiZD1jRoom/1kRVkL310cOiQonDTMr1pr8dqJ4YfGJ9BQAY+c1nBEA+0D8132UtG9H2tb2nbIr5QUQs0Q07R7y7LSkVgfVVTxTP5WcS3YHOZP48bZdNdOp/ng8rDAlujV9Bp8WjO6daMzYAuekxmqIMa2i8UP8M2R+EXkswQIteg==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel , Oleksii Moisieiev
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Grygorii Strashko
	
Subject: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
Thread-Topic: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC
 single-agent support
Thread-Index: AQHcHaczzFSreK7re0KgM50DbxoBaA==
Date: Thu, 4 Sep 2025 14:21:26 +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: DU0PR03MB8934:EE_|GV2PR03MB8751:EE_
x-ms-office365-filtering-correlation-id: a68bc284-838e-4af6-e6b3-08ddebbe559f
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:
 =?iso-8859-1?Q?2CCDtJogPV1VWgzcMHrCbBZTiIXjpJe6glcoT0Aqqv3uQII5Q7q28c42WD?=
 =?iso-8859-1?Q?rzLey+TUVszpXZJyFKnXlL1FdlIrwp+kiu81tO+nuOWYwfv3SbMV0nJh03?=
 =?iso-8859-1?Q?B3A/O+WYZr3RuC7SJAPJ1mBCxDNC/q3/x2cJIhHNFS2WcKP+HMfrCktCFT?=
 =?iso-8859-1?Q?iuSEj0jW3szDyd3oTHWspgNN50CtPXVJnicaQ0vE1NMNm6y7cIhee7dOU0?=
 =?iso-8859-1?Q?tEg+RbHtkP3SETK1Ae3c9hKf3n2alVOo8nXLu3QW/i0Y411wuEJMn6DYrT?=
 =?iso-8859-1?Q?/9J5h3BCZ4Kk82rxihfqkObgSD9EStfH0vpm73qO+irQYd0l0MFHwgR9OD?=
 =?iso-8859-1?Q?07iMV6a3ikC8IRZw5DX9IAtF+yv6J8Nh+JNF6SVlrdr+oFUDYQtbyVEEII?=
 =?iso-8859-1?Q?/ddj/AXdGa2i3byUi68yUi/55SkMxDkgFm2Mr7lmO78HDMSK0S80tlBvuB?=
 =?iso-8859-1?Q?/IrG+sHtqfO/WIgcZQi40MBwgFeFQbrcVvKWvILVgKe6WGkv3OHcojScgO?=
 =?iso-8859-1?Q?oF6GsHvYBeldcW3scZBw64diAeBn5G6COM8/NY5My7NGnzuq317l2/yBhF?=
 =?iso-8859-1?Q?PaRQXES58g64KTKs09tko0cTrUA5BgugVK4uqMiJ6eGfkDCWKkX5fffXBD?=
 =?iso-8859-1?Q?BBCaZ9VTzr/Yo+ZSqwSp9stVulfZcEHJ3dvFvNWcVmeGjckCWRPe05M3Bf?=
 =?iso-8859-1?Q?W77DsSXVWkJOYd0ORVQ1SknWoOdSXhd15FuS+NH1Rl6rmIdkuEu9XZtZEm?=
 =?iso-8859-1?Q?MEP5hSyTh9tFD1fH5PG//RCnro+BbpjPpQt4utWZFIVLkjvVgpTKekqlMx?=
 =?iso-8859-1?Q?2vcr9hHWNzXk19msTlTTHaKoSx0c3EV95WOXyEvhLhEJB49WZioU7NMj37?=
 =?iso-8859-1?Q?H47T+ast7hgZd9B7NoZOX9oJNNBKVeIfa8lxYYU8HRMcvEFyqNjZobvzxX?=
 =?iso-8859-1?Q?2KteTPdp1RoQMk2qtuQqPmvhr50AnJ2GGbBIzoVRFwbxBNE19s7qqINcuf?=
 =?iso-8859-1?Q?f8RFnlLfeh3Cl02AnGe6MB7HO0jUV8A4kNt4lAwWpqWKYjZubCgx7BL2fT?=
 =?iso-8859-1?Q?BOJOCtK5p7Zrg4w1iONTJw9AfgEpD0ksPDLhOLz/hHA00ewfCY1MgdOyYK?=
 =?iso-8859-1?Q?X42OXFpTZYv89mv34J1osR+KBs55kMECaM1SHIIbZfMircOelk4OzGIxX7?=
 =?iso-8859-1?Q?0+jSCZdO3ChopnH3AvVP7hIR2casEQhMnFy3HWqrainJbfdbuQI4hSnnzU?=
 =?iso-8859-1?Q?jjH0hSRemKtsfxPDhK7TGlRtUys/yh4oYA8+5Q8FgJG8ZzKgdJPB+/IiRs?=
 =?iso-8859-1?Q?3NKIlhlRevbe2KiGjCQJ8lDBdQguQXy7jRgSFORfy22htY5k6N6sEJtRpj?=
 =?iso-8859-1?Q?Ng/oqPDEvEPvkZpyxxEzBD0gWIYd7X+Ku/weGF4q/BNLbygdfOGYFGwZbw?=
 =?iso-8859-1?Q?yDuQpUxJgDVI35WZxjz+CMqzD1pk1Mj29TxdtLIk8BaiXW/sxR6+Qq2MLA?=
 =?iso-8859-1?Q?s=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8934.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:
 =?iso-8859-1?Q?nwE2rOA/1GgFiRK/DYgfgxBUXkpoZzER4BLbPKgU/962lv70gYUeV2Gble?=
 =?iso-8859-1?Q?IO0AyGtfCwO0e9t315RZZuGx89KyWHTSpkn05iO2B/lPqsw1FKRjpeiHaO?=
 =?iso-8859-1?Q?CY8waRZV3l3vni6BCHv/UbE2nw1hEDNfysaf/Suo3HnPgKBbHkdkmivoot?=
 =?iso-8859-1?Q?E3D62ItvP7a7N5cJEYIkY38dTvGnzMZV+8bBNWa2mfcqzB3btonWqNqbdK?=
 =?iso-8859-1?Q?hwWmuaA/R+nCAwMgyoXRIAPdyme+/A+qTMTiX6SFr8cGYm4iPxZRGfjr6D?=
 =?iso-8859-1?Q?iPOoknWJOjUDi3FJsirwG76s2KTT6zxQHL0yby5a0b99sexJKYQxih/B0h?=
 =?iso-8859-1?Q?5xFgg5Py8O6wgWvjLEP0gQdxp9LnwPg0sQxcUFTZ5H4MnkldBKbGd6N5AY?=
 =?iso-8859-1?Q?OXlpLGXWWz6mHEI8RpNTErkYd23w4Otg44gMwf6aIr7aFDfUep0kBBwIPm?=
 =?iso-8859-1?Q?q23WwRk2uIhfivFldPyw8jsCT0hIWYhNtZzA1LgVaQsy9zjXUmZao4KlxZ?=
 =?iso-8859-1?Q?v1LahOaAetH5cgfU+B3dh+R1GzFkDK+f8pfyZnk8Y7xsKQCxzZLmfpnFKV?=
 =?iso-8859-1?Q?LPtYmrEn9Cg2ai9KWzwjVdp6nG9rGYTG0U2zWy7iOrtzNv8Ch/Nfbk6hQJ?=
 =?iso-8859-1?Q?51cCYtsLn4z1VCszjyU8WywGv2HLMEinO4Ck+Wy81eJVr3z8LnE9d6x5dS?=
 =?iso-8859-1?Q?/u0txh9mjlqoow7ENlQWAjzyqatv34U5YM619TSygd3+BusBVscR9K65hf?=
 =?iso-8859-1?Q?3+OspMh1JL8eehfRWn75f9BDFPQj+GAGFyXIrtx6CFyMIjt7UQKc3pH8Gu?=
 =?iso-8859-1?Q?uyVEbtj57SFKy7hPlyxaoraKGSlZEPZcOWk/ZOL43JVrHzXWsMPZHXJzmj?=
 =?iso-8859-1?Q?Gcor9zNLQJ04e30WzqA/r384Mtoe391xzq9RDiNV+xJsTPyMB5CAuP6KTq?=
 =?iso-8859-1?Q?dNWMCzFBkZcYxDmcZU01TLtxq9Q2ktLNGlvgh/zTk+mtnwyxiIRizrLhT4?=
 =?iso-8859-1?Q?Dyj3W/WuN3ZAAZ21BYhJSjIGOyUyfdJwWKHzLrepBBcJfAj7IQlZMKywK+?=
 =?iso-8859-1?Q?FYgikiaE1n5xZDQnJeg6YcDa3kvRwGoTD8Osjbj9wR6hbAr6nQ3DDRfCSP?=
 =?iso-8859-1?Q?TKMgJ9uhlCnAElKfmWoKFJPlV5vRDzEEaOj8JEpKRp+36DieU02hH1f56A?=
 =?iso-8859-1?Q?4zTIMUCp149YhttED5H8o1qmvxq2AH4bfYDnp4qPg1uGgktXFTeRB7p1cj?=
 =?iso-8859-1?Q?609Ih6z4i0mD8e8/GjEUHy4R4aUJEhTOGa+LWofDcVr+X9P6fGzz5kLc+R?=
 =?iso-8859-1?Q?UccdHwVLnPTanos7/uMqdoFymdqvYiaVDlbpMRs12oaKqPCduNy4qY4buv?=
 =?iso-8859-1?Q?J7h4B4nCxSWp9lpoPSLCA+y3p7iUoGYlGZgKGFJbAO51w4Vkv3MqI1yu6T?=
 =?iso-8859-1?Q?VGqwpb39ue/vRkYN9Z+T7tjLz6EH8ZXBbuQY3K3i9sEnJutRKZg7Nco03N?=
 =?iso-8859-1?Q?ODaq70/uN1JKLvvoUKxs1ipTQUgkMcBsmobn9YvCymiycUR1wGcROj8p7W?=
 =?iso-8859-1?Q?gmL5K75OVPFm32N8HN32+dnzKnmgd90waI7HOxdXKwmAfLt0w87aM9kAOl?=
 =?iso-8859-1?Q?5AgWZGS5ZaE524neXtuLgdEQA8iwDssfemDiAY5TlLrXmlXZBJTuNiHw?=
 =?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: DU0PR03MB8934.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a68bc284-838e-4af6-e6b3-08ddebbe559f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 14:21:26.8881
 (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: ewIZWWM4yckn/vCGGMIAvVPs8GsNZ9WjMyGQOtMagcmM/XMHEgwvS9kuMZeuAgm/1LkCJlJK45gTicwZuEDDLK+qTIv7satbdD8aOv97r+A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8751


Inroducing V9 patch series  on top of the Xen version 4.20-rc2
which includes implementation of the SCI SCMI SMC single-agent support.

This patch series is the first chunk of the
"xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
be found at [0]

SCMI-multiagent support will be provided as the followup patch series.

[0] https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieie=
v@epam.com/

Patch 1 "xen/arm: add generic SCI subsystem"
- rebased and refactored
- introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probin=
g
instead of custom,
  linker sections based implementation.
- added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
dom0 code directly.
- RFC changes in XEN_DOMCTL_assign_device OP processing
- Introduce arch_handle_passthrough_prop call to handle arm specific
nodes

Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
- update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add =
SCMI
over SMC calls
handling layer") be used under sci subsystem.
- no functional changes in general

Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
This is new change which allows passthrough SCMI SMC, single agent interfac=
e to
guest domain
cover use case "thin Dom0 with guest domain, which serves as Driver domain"=
.
See patch commit message for full description.

Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
driver
- add documentation section for Simple Arm SCMI over SMC calls
forwarding driver.

Code can be found at:
https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5

[1] RFC v2:
http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.ol=
eksii_moisieiev@epam.com/
[2] RFC v3:
https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927=
-1-grygorii_strashko@epam.com
SCMI spec:
https://developer.arm.com/documentation/den0056/e/?lang=3Den

SCMI bindings:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/Documentation/devicetree/bindings/access-controllers/access-controllers.ya=
ml

Reference EL3 FW:
RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
Renesas v4h:
https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4=
x-scmi_upd/

base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)

Changes in v9:
- change input param name for sci_handle_call function to match MISRA rules
- update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule

Changes in v8:
- reneregated {helpers/types}.gen.go, dropped unneeded parameters

Changes in v7:
- fix sci_handl_call to make changes more readable
- fix build error when DOM0LESS_BUILD is disabled (removed
 arch_handle_passthrough_prop from the header)
- sort headers in alphabetical order in sci.h
- sort headers in scmi-smc.c file
- Fix commit description.
- Move scmi-smc-passthrough definition to match alphaberical order
- remove unneeded initialization with NULL
- changed u64 to uint64_t
- Send warning if iomem permit access was failed
- fixed typos

Changes in v6:
- rebase on top of the latest master
- fix return value of sci_dt_finalize() call
- add R-b tag
- added generated helpers and types go files
- rename cmdline parameter to scmi-smc-passthrough
- fix goto tag in parse_arm_sci_config
- add link to the scmi bindings used in the doc
- remove mentions about HVC calls from doc
- rename cmdline parameter to scmi-smc-passthrough

Changes in v5:
- update Maintainers file. Set role as a Reviewer
- rebased on the latest master branch
- Introduce arch_handle_passthrough_prop call to handle arm specific nodes
- rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
- rename dom0_scmi_smc_passthrough in documentation

Changes in v4:
- fix SPDX-License
- rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
- move XEN_DOMCTL_assign_device code in separate patch
- Add documentation for SCI SCMI drivers
- xl.cfg doc
- fix comments from Stefano Stabellini
- fix toolstack code as sugested by Anthony PERARD
  - use MATCH_OPTION()
  - move arm_sci struct and cfg params in "arch_arm"
- add SCMI passthrough for dom0less case

Grygorii Strashko (3):
  xen/arm: scmi-smc: update to be used under sci subsystem
  xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
  docs: arm: add docs for SCMI over SMC calls forwarding driver

Oleksii Moisieiev (1):
  xen/arm: add generic SCI subsystem

 MAINTAINERS                                   |   6 +
 .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
 docs/hypervisor-guide/arm/index.rst           |   9 +
 docs/hypervisor-guide/index.rst               |   1 +
 docs/man/xl.cfg.5.pod.in                      |  34 +++
 docs/misc/arm/device-tree/booting.txt         |  15 ++
 docs/misc/xen-command-line.pandoc             |   9 +
 tools/golang/xenlight/helpers.gen.go          |  35 +++
 tools/golang/xenlight/types.gen.go            |  11 +
 tools/include/libxl.h                         |   5 +
 tools/libs/light/libxl_arm.c                  |  14 ++
 tools/libs/light/libxl_types.idl              |  10 +
 tools/xl/xl_parse.c                           |  36 ++++
 xen/arch/arm/device.c                         |   5 +
 xen/arch/arm/dom0less-build.c                 |  40 ++++
 xen/arch/arm/domain.c                         |  12 +-
 xen/arch/arm/domain_build.c                   |   8 +
 xen/arch/arm/firmware/Kconfig                 |  25 ++-
 xen/arch/arm/firmware/Makefile                |   1 +
 xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
 xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
 xen/arch/arm/include/asm/domain.h             |   5 +
 xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
 xen/arch/arm/vsmc.c                           |   4 +-
 xen/common/device-tree/dom0less-build.c       |   4 +
 xen/include/asm-generic/device.h              |   1 +
 xen/include/public/arch-arm.h                 |   5 +
 xen/include/xen/dom0less-build.h              |   3 +
 29 files changed, 982 insertions(+), 85 deletions(-)
 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/include/asm/firmware/sci.h
 delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:21:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:21:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110285.1459563 (Exim 4.92)
	(envelope-from )
	id 1uuAqH-00067n-PM; Thu, 04 Sep 2025 14:21:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110285.1459563; Thu, 04 Sep 2025 14:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuAqH-00067g-Kn; Thu, 04 Sep 2025 14:21:37 +0000
Received: by outflank-mailman (input) for mailman id 1110285;
 Thu, 04 Sep 2025 14:21:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuAqF-0005ts-QV
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:21: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 7501f5db-899a-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:21:33 +0200 (CEST)
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com (2603:10a6:10:473::15)
 by DU0PR03MB8290.eurprd03.prod.outlook.com (2603:10a6:10:31c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Thu, 4 Sep
 2025 14:21:29 +0000
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40]) by DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40%7]) with mapi id 15.20.9052.013; Thu, 4 Sep 2025
 14:21: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: 7501f5db-899a-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K1h/HTSJh7gr2ZIJZCnyDO166So+wPA6iUjDi5K5ZmcjpxcFSwddRQwsCksC/8dhQ3u8150eXwtvmkYFQX466m8vwk9465mHxyXIAB2E8alfqAf7TSjzIquCMowv/rIu6jpoHnUe2U6sXOHI99eiB07eHiP0eG/LAXksew7394ROLCQwmxm49gJBAjKFfoReigNtr9bJYXJVnmf0pq8Nn8mJrQ9Qom1zukFg0lwXLF2PWDD+PBMPPr++/8VJjaUn+ZNo+OeNZTsE9++jlXOMK+/3Ijta4uFLXgPUD9zFAmPcPfrHgW1zFsoAgyIm7oU+PyM/ZKqsY5bp6bGFYzSsUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AaHCelQ59jKtKWLwfwblTdez/+Ey8JJ4o/qqx28tWCs=;
 b=t0SZ0KLzi5XjpCMaldxP7p+gaz65zBbZojdotruPZw1hfZTRtnYZwSPOn3NB3w42JQ8pndnVkhm5/xItXw73YAQA5wSj4RJdWiP/m3I79sq1oEuijJ7gcuN9iqgYKKed/mz8247PrJ5Qu0VI5YzEwUzx9c2lmkP6KQLNdSRnb9Z0RsaD2sApqJquW3FG9H+hEwSbQOGQ0rKRffwlo4tWQplyX/Mxg+ZMy7G1VgAa5EyE1FD1Dnc1iAXz/D4XFqkt7LrHxs5vjJ0dJ3RkIaXUcJYdZ4tSFE1NVFeAI+tjJ2kMSsJR5pAZulWP4uhwRwLPCjkeQnmYm35aXd2/4c9/uA==
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=AaHCelQ59jKtKWLwfwblTdez/+Ey8JJ4o/qqx28tWCs=;
 b=sb6b8uDV6LSHwtb7PO7wDsAn2iMKvs6UiRyl2kkPZOwbuDrbHu36FQNWENVMUl3yfJLe0Sc2aPqVfCeFSzWY74nlcu+2A6/+5U36SyU/Mol16oEfBs3birU2hi3Z3UXiCYzhSoAntKtVdoepMh3WCAZMQxDaTEVBcvCQMsy0PmCRVrP54QkDOkW5/pgVLE5DIZ1/gJPWOKx/WxyHkvg5IUsoxQm9KxMP9OtWdArtVHZmk1TgfvVJtX0mec28SeZWriSAiCE+VM9KY2HVqLbwiIO3JtF7oYZbq7pG9GCH10QemdkCh6cZiUW6gErhBFC4JhQzPeFcYsOepOJMxKeCkQ==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel , Oleksii Moisieiev
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Grygorii Strashko
	
Subject: [PATCH v9 4/4] docs: arm: add docs for SCMI over SMC calls forwarding
 driver
Thread-Topic: [PATCH v9 4/4] docs: arm: add docs for SCMI over SMC calls
 forwarding driver
Thread-Index: AQHcHaczJu4B0gXzU0Kn/cb9yNa3XQ==
Date: Thu, 4 Sep 2025 14:21:28 +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: DU0PR03MB8934:EE_|DU0PR03MB8290:EE_
x-ms-office365-filtering-correlation-id: bfe85a21-0b65-43d1-e573-08ddebbe571c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?gwF1j6gsXeE3x/HcVzW9nv/qqvnnyZT1YD8ZoMtop954CVCRLoFo3f5ojh?=
 =?iso-8859-1?Q?8IRszZYLMalMP6WdV5dPT4JxmP0XAH8UAJnqqlZFDc4h80a43S4+ep92ed?=
 =?iso-8859-1?Q?aDO3YfDde4YOaBiDC9ouZ6DZR/P0pA5EaJtq6fD4raAutB8Q8EfZTDOV6K?=
 =?iso-8859-1?Q?xLTtgmlFpZvT3+0Pm3NLyqKN9g5xBNqeLXe7IFXmFhLJSban8TL7q/mx8p?=
 =?iso-8859-1?Q?JQ/1tGE93Z9HUJt41Pg1OwMfpRzh4P/3A0xyVr4RlUYvURB7Na+wFOUsEU?=
 =?iso-8859-1?Q?bRkCTwMGsEw8IWQx0zGWzBFLyOg1SIlZuYrZAdEW4b0TJf7XcWQVJI0BCJ?=
 =?iso-8859-1?Q?JNwBt0b3f+F6Qjo9fW7omdk4un/j9+TiGfZNKLQynrM7dvNnDyhMn8hMr5?=
 =?iso-8859-1?Q?SICMZHaop3jct9an6o0eQ+ZCxugOSAeMkWC2dt4BkfNWXI3BkAUXZdZVY+?=
 =?iso-8859-1?Q?vRFMYmOEZLywTa6nqTttY7pPsLTkRQJF8wTXVu8wQn1glI6iaNgeRADJ2d?=
 =?iso-8859-1?Q?91UznIRtA81kbKYo4MmbCwOAi4bOU126NPkL6X/gCtlbkRJyPTVzaB+i/G?=
 =?iso-8859-1?Q?x+HN/rjWbdiB0dT5d5XNvjyL2cFwEB6wx563clL5mV4M+kpUOS8YiLhUOo?=
 =?iso-8859-1?Q?mB6z50BjrPuR0SNKcJoRl3O1Lg5U8B4El5Dl1ujN1Z0lG7hZbsKaqnnS8d?=
 =?iso-8859-1?Q?okqJerQjEqJb9WDwEDPCOHInJYLjjEqueoMIxJv+IkWrEmyGlMHpYrrz5x?=
 =?iso-8859-1?Q?zyH7L8goFS7g1OB73UCFmISu550JsjDiaipEjjacgGep5fmxCQ9kGwujyO?=
 =?iso-8859-1?Q?Wf9A23oclEhwTAXz7o2vu61c5W4NulM+yB9zk595qYmOxMbLik67Jsig1S?=
 =?iso-8859-1?Q?DqOcGH8Pi9uba/n6sBkf+U9k+ZWyAJXMKNBOZRVj8OCdRht4EmJHyFpzOm?=
 =?iso-8859-1?Q?O9SYWD4R047s89t4jdPPcncOyRWOai5sv4NhhAjwCi4xDftBdkGzlW7mpx?=
 =?iso-8859-1?Q?0oLZpoDmocGJ4ApAO8luizgTaCLkNzr/pbuPmmHWT8dW8Nl0oH55Q/K+9R?=
 =?iso-8859-1?Q?W6ARQW5ty97vCQUOBJLkqtEOyfebMJkb/i58cbE423NSyShIHpr/gnyMWB?=
 =?iso-8859-1?Q?X860uDK79wdXpfZYq1L99HrNV/w2/Pzh2NcuzqBAvb+HPCtj9Cc+JCQffP?=
 =?iso-8859-1?Q?UZgGy/PNm2W3dlWL/6CJpDGBxjtWJMRcONzH+85fKCK62EqQ7smBRcw9VH?=
 =?iso-8859-1?Q?cb65WxDs55f8tGvjAgOyii5+CkCZhFs9x1SjB0C8refWzNHxmE1Jd1P0TH?=
 =?iso-8859-1?Q?79PHLjTAVHkLG3oFwy4Xy4/hq+f/0w6fVKOGNhr0LY3N1DQ5og/6ZNO5/6?=
 =?iso-8859-1?Q?DYcKAmVPolsD0C5eAK3B7mPV0Drxox8zLmSi3IpI9N5XWDE01DsufI/4Wj?=
 =?iso-8859-1?Q?Efr1BV43hWAK9MH73JvC3261r+ZG2ncuUaL3gSBejh/xPE3axoSRU0bZ4g?=
 =?iso-8859-1?Q?c=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8934.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?CbWxF8axaGdst0B+kaObiUS+DfhCRYe95kmcaDQya1rKFtguXVdkZyQzPr?=
 =?iso-8859-1?Q?QCip1hzwXZAeKlVDNGoxdO5WuNNfo3NikrU06Zc7RQBVWB+4PbpwgEpQuJ?=
 =?iso-8859-1?Q?dak/Ptuz/9pOVeEfOjCeFM7S9mHZ9XyIiqrTSqIAdU65vu9Xl1HyEzRcS7?=
 =?iso-8859-1?Q?SrKgsxwME8hHgmxbo6LmobLyasillSPgYQwXbvk9tXSg5GmC/aIqilXsq6?=
 =?iso-8859-1?Q?uwSXlV13sw8i4bvRDODZ+N49TAqHpn2+rAmZLwgFXesTqZirjA1omiXkYD?=
 =?iso-8859-1?Q?UeajE+CPTgZfzaIKOHomAK2skqDW3KXxdbjkhcHQY38GgQ8kcB6i0aa40j?=
 =?iso-8859-1?Q?AYNsH5hbf9o0ZRTdEdU/bR6W1K3ZxUh9tB7Y3M+/4c8oWHFyVO2V8qIYt5?=
 =?iso-8859-1?Q?O1LHpNSM7WKjd04YxCKg++AA7imQP6GWf0fwGbDs0fdGpDDzRhmsiazm5H?=
 =?iso-8859-1?Q?H654DToTHUy2ojhFeM/72LTk7+aHybaHKrfQ5BRWSqO98w+T3Gyayxv2rn?=
 =?iso-8859-1?Q?sdnwV/dfmB7OE6fn0d1BYUKCl1zYZYwaMW7folfctx66yyxgLmegxXvFgr?=
 =?iso-8859-1?Q?+fp5uyU+qiEpNFUrPNNm3wV9UkQ8/OrKg35xuBHbOq2vgQmUHfzHZI6QrG?=
 =?iso-8859-1?Q?Kb8++7wlPGeQlfdKWYQaXj99CK1bCNSF55/mxPL8OL9aMs7zOEYwYtm4A5?=
 =?iso-8859-1?Q?w5u5lKMPOF4qPYiC3qT0rEiI0/WIL6IK9HJY9mXSL12T/Aizww7gW+8+Q9?=
 =?iso-8859-1?Q?AkNPe255jKPxErcqlP81D18hIA7yQz+a/fBpQ21CZf48eSrPokSrxdQw2x?=
 =?iso-8859-1?Q?aRG5Uotb+TujQroMMcNuM3V8l4EA9M8HTgNxSSVhsuXWui2Vgn43S7m/vD?=
 =?iso-8859-1?Q?hYoUag11VYp9MY1B1d7SLkR+1C+VkH0E4AjEPH3+BAX1ydnP4tBKRX4Onm?=
 =?iso-8859-1?Q?X868HvESGRLgYW2RCvdSJ5/zxHo/c0UzzZkq7FaoBLP+68DxSYOvBCUUP8?=
 =?iso-8859-1?Q?KiuodVVrCmsiZUgXyddUMNaPKqp+l0A0UhnBedtJ2saz+1p1j2oie300DT?=
 =?iso-8859-1?Q?nw2wsi/2uuc3oudnA1vciUmhLnSeiGxWCOw8ZelRXthwt4F4nw40R2evKK?=
 =?iso-8859-1?Q?Fx0Hv9achHCI3aoBySSjsXoD4F/GWedITQR2vQ8SmwQAidlyhdG4/VgRgc?=
 =?iso-8859-1?Q?3B/pNig3XS2xjRjA2FcBMQWsXOBe3Lngwm1FjoGcXYRR8RcXBnP0f7smMX?=
 =?iso-8859-1?Q?V6oUOhqSAa8twvQgHOPtSjbUdmHjMllr/41Rxa+rxO1XLWiEFzncL9hreM?=
 =?iso-8859-1?Q?ZpacoJRtxSd3rAawFBttYammHzRndRPMfiBLglZFlD6OIBJHjCIn3aCRXo?=
 =?iso-8859-1?Q?UwQeTXdkj1OwvlZoXT17elMwcC/K3MqvxG7yK4Rk94F2MVGF90YBA4HpXL?=
 =?iso-8859-1?Q?KAu0dxNMtVUPYBjpHkvrTIytnr3ewP3ZFd+7eSp9rBJr3RxElExkt44EHx?=
 =?iso-8859-1?Q?LeZNj3dqxZoawJiacpJ5SdxFdEjvaGVn7iUZ6iowwJNZMGZTfdiq0DvbPV?=
 =?iso-8859-1?Q?oq7CZiUIgfQ1+InZM71HF7QvApujWiCi4xqNhNZMzeEOWY2toGHtBDjUl7?=
 =?iso-8859-1?Q?MO0PY0/ZaK+KZrEQyJUJoUQx2lL3E3GaVBrh8xDxuGH0g5tI3M8HixoA?=
 =?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: DU0PR03MB8934.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bfe85a21-0b65-43d1-e573-08ddebbe571c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 14:21:28.2367
 (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: zJR6n9bf+6oFtLnhLcwuR850GVmi4nxhBLBsfAAaH602cglmwDfyp579dl2VSP+63pOemDbhd/7OaK4Z4uUSWjvPCcRUL6LxpZm27lTLpm8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8290

From: Grygorii Strashko 

Add documentation section for Simple Arm SCMI over SMC calls forwarding
driver (EL3).

Signed-off-by: Grygorii Strashko 
Signed-off-by: Oleksii Moisieiev 
---

(no changes since v7)

Changes in v7:
- fixed typos

Changes in v6:
- add link to the scmi bindings used in the doc
- remove mentions about HVC calls from doc
- rename cmdline parameter to scmi-smc-passthrough

Changes in v5:
- rename dom0_scmi_smc_passthrough in documentation

 .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++++
 docs/hypervisor-guide/arm/index.rst           |   9 +
 docs/hypervisor-guide/index.rst               |   1 +
 3 files changed, 190 insertions(+)
 create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi.rst
 create mode 100644 docs/hypervisor-guide/arm/index.rst

diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi=
sor-guide/arm/firmware/arm-scmi.rst
new file mode 100644
index 0000000000..d65ce35acb
--- /dev/null
+++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst
@@ -0,0 +1,180 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+ARM System Control and Management Interface (SCMI)
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
+
+The System Control and Management Interface (SCMI) [1], which is a set of =
operating
+system-independent software interfaces that are used in system management.=
 SCMI currently
+provides interfaces for:
+
+- Discovery and self-description of the interfaces it supports
+- Power domain management
+- Clock management
+- Reset domain management
+- Voltage domain management
+- Sensor management
+- Performance management
+- Power capping and monitoring
+- Pin control protocol.
+
+The SCMI compliant firmware could run:
+
+- as part of EL3 secure world software (like Trusted Firmware-A) with
+  ARM SMC shared-memory transport;
+- on dedicated System Control Processor (SCP) with HW mailbox shared-memor=
y transport
+
+The major purpose of enabling SCMI support in Xen is to enable guest domai=
ns access to the SCMI
+interfaces for performing management actions on passed-through devices (su=
ch as clocks/resets etc)
+without accessing directly to the System control HW (like clock controller=
s) which in most cases
+can't be shared/split between domains. Or, at minimum, allow SCMI access f=
or dom0/hwdom (or guest
+domain serving as Driver domain).
+
+The below sections describe SCMI support options available for Xen.
+
+| [1] `Arm SCMI `=
_
+| [2] `System Control and Management Interface (SCMI) bindings `_
+
+Simple SCMI over SMC calls forwarding driver (EL3)
+------------------------------------------------------
+
+The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is pret=
ty generic case for
+the default vendors SDK and new platforms with SCMI support. Such EL3 SCMI=
 firmware supports only
+single SCMI OSPM transport (agent) with Shared memory based transport and =
SMC calls as doorbell.
+
+The SCMI over SMC calls forwarding driver solves major problem for this ca=
se by allowing
+SMC calls to be forwarded from guest to the EL3 SCMI firmware.
+
+By default, the SCMI over SMC calls forwarding is enabled for Dom0/hwdom.
+
+::
+
+    +--------------------------+
+    |                          |
+    | EL3 SCMI FW (TF-A)       |
+    ++-------+--^--------------+
+     |shmem  |  | smc-id
+     +----^--+  |
+          |     |
+     +----|-+---+---+----------+
+     |    | |  FWD  |      Xen |
+     |    | +---^---+          |
+     +----|-----|--------------+
+          |     | smc-id
+     +----v-----+--+ +---------+
+     |             | |         |
+     | Dom0/hwdom  | | DomU    |
+     |             | |         |
+     |             | |         |
+     +-------------+ +---------+
+
+
+The SCMI messages are passed directly through SCMI shared-memory (zero-cop=
y) and driver only
+forwards SMC calls.
+
+Compiling
+^^^^^^^^^
+
+To build with the SCMI over SMC calls forwarding enabled support, enable K=
config option
+
+::
+
+    SCMI_SMC
+
+The ``CONFIG_SCMI_SMC`` is enabled by default.
+
+Pass-through SCMI SMC to domain which serves as Driver domain
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section describes how to configure the SCMI over SMC calls forwarding=
 driver to handle use
+case "thin Dom0 with guest domain, which serves as Driver domain". In this=
 case HW need to be
+enabled in Driver domain and dom0 is performing only control functions (wi=
thout accessing FW) and so,
+the SCMI need to be enabled in Driver domain.
+
+::
+
+     +--------------------------+
+     |EL3 SCMI FW (TF-A)        |
+     |                          |
+     +-------------^--+-------+-+
+             smc-id|  |shmem0 |
+                   |  +----^--+
+    +-------------++------+|----+
+    |Xen          |  FWD  ||    |
+    |             +--^----+|    |
+    +----------------|-----|----+
+              smc-id |     |
+    +-----------+ +--+-----v-----+
+    |           | |              |
+    | Dom0      | |    Driver    |
+    | Control   | |    domain    |
+    |           | |              |
+    +-----------+ +--------------+
+
+The SCMI can be enabled for one and only one guest domain.
+
+First, configure Dom0 to enable SCMI pass-through using Xen Command Line
+**"scmi-smc-passthrough"** option. This will disable SCMI for Dom0/hwdom a=
nd SCMI nodes will
+be removed from Dom0/hwdom device tree.
+
+**Configure SCMI pass-through for guest domain with toolstack**
+
+* In domain's xl.cfg file add **"arm_sci"** option as below
+
+::
+
+    arm_sci =3D "type=3Dscmi_smc"
+
+* In domain's xl.cfg file enable access to the "arm,scmi-shmem"
+
+::
+
+    iomem =3D [
+        "47ff0,1@22001",
+    ]
+
+.. note:: It's up to the user to select guest IPA for mapping SCMI shared-=
memory.
+
+* Add SCMI nodes to the Driver domain partial device tree as in the below =
example:
+
+.. code::
+
+    passthrough {
+       scmi_shm_0: sram@22001000 {
+           compatible =3D "arm,scmi-shmem";
+           reg =3D <0x0 0x22001000 0x0 0x1000>;
+       };
+
+       firmware {
+            compatible =3D "simple-bus";
+                scmi: scmi {
+                    compatible =3D "arm,scmi-smc";
+                    shmem =3D <&scmi_shm_0>;
+                    ...
+                }
+        }
+    }
+
+Please refer to [2] for details of SCMI DT bindings.
+
+In general, the configuration is similar to any other HW pass-through, exc=
ept explicitly
+enabling SCMI with "arm_sci" xl.cfg option.
+
+**Configure SCMI pass-through for predefined domain (dom0less)**
+
+* add "xen,sci_type" property for required DomU ("xen,domain") node
+
+::
+
+       xen,sci_type=3D"scmi_smc"
+
+* add scmi nodes to the Driver domain partial device tree the same way as =
above and enable access
+  to the "arm,scmi-shmem" according to  dom0less documentation. For exampl=
e:
+
+.. code::
+
+      scmi_shm_0: sram@22001000 {
+            compatible =3D "arm,scmi-shmem";
+            reg =3D <0x00 0x22001000 0x00 0x1000>;
+    ->        xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
+    ->        xen,force-assign-without-iommu;
+      };
diff --git a/docs/hypervisor-guide/arm/index.rst b/docs/hypervisor-guide/ar=
m/index.rst
new file mode 100644
index 0000000000..7aae4a0a03
--- /dev/null
+++ b/docs/hypervisor-guide/arm/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+ARM
+=3D=3D=3D
+
+.. toctree::
+   :maxdepth: 2
+
+   firmware/arm-scmi
diff --git a/docs/hypervisor-guide/index.rst b/docs/hypervisor-guide/index.=
rst
index e4393b0697..520fe01554 100644
--- a/docs/hypervisor-guide/index.rst
+++ b/docs/hypervisor-guide/index.rst
@@ -9,3 +9,4 @@ Hypervisor documentation
    code-coverage
=20
    x86/index
+   arm/index
\ No newline at end of file
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:21:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:21:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110286.1459573 (Exim 4.92)
	(envelope-from )
	id 1uuAqJ-0006Mn-8L; Thu, 04 Sep 2025 14:21:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110286.1459573; Thu, 04 Sep 2025 14: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 1uuAqJ-0006MY-48; Thu, 04 Sep 2025 14:21:39 +0000
Received: by outflank-mailman (input) for mailman id 1110286;
 Thu, 04 Sep 2025 14:21: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 1uuAqG-0005ts-Th
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:21:37 +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 760b2498-899a-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:21:34 +0200 (CEST)
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com (2603:10a6:10:473::15)
 by GV2PR03MB8751.eurprd03.prod.outlook.com (2603:10a6:150:a8::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 14:21:27 +0000
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40]) by DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40%7]) with mapi id 15.20.9052.013; Thu, 4 Sep 2025
 14:21: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: 760b2498-899a-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g1vx/7oJJ/owA78eDldT3gLToOv+Zm/JprMSh2uYIbyXSilBNOpcHuZUnLjl1ZGK8h2HmIJHCHbDdHVPGjhaP9HpzDzZh1q1LW4Jf+0Sz9KtDC34qUDz44jhFyxXUO1rq0UDBPUiGGhH+OqibQV9MRqVJejVFLSn34JIC2Kjlmujss1Li7yHHJWzxfB4VINSL9qSvRQekGkg4pYUDgTIcA0ghOjZ94PcmcxEuN/5JhAZ2f+sXYgHPXTX+gESxEb5vhwfiuQIHDQVdq5QgUlM+xFRHX8h2Om5o4HRW7hjzkzItrKTHEDxCle3wDpQgB/Rwh9gNppGApERE3zSEWom1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vBrFjLRNqA0YEzCePfVWiUA4mMc43WHwaPUc0JP2ZXc=;
 b=ruDlYz3nswZs9sBZc8BB7tr4Hbr9by5NJg7h4OiYw/HUP/ea06Jb2X9R+nzHnoAP3cz6ZQKmfnzRpj7pC2S3CwnePpSS4EikFHcGl9T5dSqmq+J05n5EFlMWiHd3gMhy9eOUn9D4cajcBH7NGInA+vjzUazdLDYxK/fFR1+eK4Q4yHvsY3XBRh1gJe1FS3NHDzRC1mw3UDeecHCjt93KiQYYf/sxld9EWb4uXWRn+8mKccZDXKqJM9PL810gJBMwSl9VD64rhLa+QMkhUuxM2ttoHZZq4iJX/8b7JAMcFcyUkJTWNrew6UTMkUj69rYQfa9SscnBbyP4D9rl7lAfmg==
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=vBrFjLRNqA0YEzCePfVWiUA4mMc43WHwaPUc0JP2ZXc=;
 b=Q4lJwQxIAU/CsiQQHkFJ/oh4+IRCkutGsnUP4DszT2JZK77AK/uoPBUFXfvDyCENtE+xukeLRlYZZ6KI08RC/A28VLJi76G2Y6klYE6LGteSMzp97flcaTGHIs+7JqHb0AHosW0XuJYIFf7yRyrnu6YK7NfJsll4JkXlQCZ8ykYV7F61xSVa8IIC3ncuKHAu0z0RynlLIeUhqLg46NDlzXuQ9xhA2+5ts9wBrP1F4pxzIbEJqYnsOsamv4EqzxBfaCXVLxMOVfxoNTc19Hx3XAe8AO0o8tQJRi5JrrFAg59hpV2Rl5M5ZovB6zgSsn7ZgIp08DMbPiODpTRrGjUOxw==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel , Oleksii Moisieiev
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Grygorii Strashko
	
Subject: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
Thread-Topic: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
Thread-Index: AQHcHaczp/pn2jKXU0i48m8PFCAwNA==
Date: Thu, 4 Sep 2025 14:21:27 +0000
Message-ID:
 <3e237c5256054a88b1c099d85d8bd1a602bba230.1756995595.git.oleksii_moisieiev@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: DU0PR03MB8934:EE_|GV2PR03MB8751:EE_
x-ms-office365-filtering-correlation-id: 3ea15c19-5fc1-4378-494a-08ddebbe560b
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:
 =?iso-8859-1?Q?+gUOHSrlBig1bNQUdrA4QDhiQsB888urPrPiF5tJe94HrSJOlfwhUck6tf?=
 =?iso-8859-1?Q?9uDqfpYC4UqsBBVPANGj4N2RppfDTI7fNvegJzp2OZHxWNLpwmztGPekf8?=
 =?iso-8859-1?Q?ndhUaDwnCSRtQbXaR3E9XdsAm3HAb+rk2YwSErcPKokKKa59eX6QGqnB0o?=
 =?iso-8859-1?Q?FotM630W/toBokDx/MZMlNd9WK7idg14Nb8h4nnGgCl0v36/LmHPkYZlLg?=
 =?iso-8859-1?Q?lKmqZybB4k8hXgbuqa2QqFmHiCulFXxHSW5T6QLud6HPBFzVECrB3cQ8M5?=
 =?iso-8859-1?Q?wpam5SZ/HUm/BGIvppnoQKsMrY+LQ8oMRns8zWOb1SlXdhCIcLdolV12KT?=
 =?iso-8859-1?Q?pcqr1HlkyNuHFSsZv8iXMHQ+AInL5DaHSk3TumHJBuU6vHyno5YFc/ohIj?=
 =?iso-8859-1?Q?22tuBPT9zFxuTYIBewWrnCXSOm5mYr911Cvm39H7Ttxqm+A3HD5RaTE+m7?=
 =?iso-8859-1?Q?dfRNYE8EpolviwEDTyIbeoe/fHE6TR0fAfo7ngmtjgMG0b93vOr4o/LoNk?=
 =?iso-8859-1?Q?FnlI056Np4AbheAPdgKejKyb9GUcAGJRXuQgflwdaueUIEif5F6dTmQZsR?=
 =?iso-8859-1?Q?i6MsjG0nSaRsm1BcjHsQ7n683lhB0JS5SBBeYNbDWxgENwQzcA/K3zVFR2?=
 =?iso-8859-1?Q?trlHmlkrVIFWhqVprS04OQhW3R24Ke6x/sUwMgjVsmwIpmApkMx2x8kXZk?=
 =?iso-8859-1?Q?rbDXGHYfLJb+XqOD7FFB9iREUUI4WaBqh4SSs7Bvz6YhNAybzqe9oxf31Z?=
 =?iso-8859-1?Q?XewJukgS8OiRYXDKUbs89qoJfdyM0sLbgFcPA+9+BtsT9ralmlrm4FNAWb?=
 =?iso-8859-1?Q?laqIxPzQWjsELONUW/sKxegY3AEs6C3nsU1FFvF1z5eh5d1Q1macS7NuuM?=
 =?iso-8859-1?Q?oQ5EppDmC+GbrxhoqOLYZYW1Q950vdUdfbk2jueyj1gIGeUwIndsOD5UVm?=
 =?iso-8859-1?Q?C8SdPmbVSg/jCRI8nz3MR1RlQ+wQiKwR32Zzw4TdipYmuS1st82KFx/3lP?=
 =?iso-8859-1?Q?vl9gvgD8HtImWiVlT4R5OgC7GFgdGKa3t7nTXvGb+0B/0/KwP3GUc9bdRf?=
 =?iso-8859-1?Q?omM/EOmwBoQjI7y67vpKrI1Tyz5sD7IKjz2cmseX+79L/RhT3f7ZF+fa26?=
 =?iso-8859-1?Q?aNqyOYyCs4Zyh2nd6oSN/PGGM0hbK4080btfBWVoJbhetgKL7B7d7raJ3r?=
 =?iso-8859-1?Q?ec+JWza1DSbQqi1M2CXbGKNUwnpoA6jWzrbr6RSiYv/mwAcSLyxDj90FbN?=
 =?iso-8859-1?Q?o4nMAM0F7ueO6T+E9fF7Lg92wjOwf9FAHKdwW5gQVqh0ThFaoNcElNrOp/?=
 =?iso-8859-1?Q?NhjQ2Z2AoiN4l3TdrnCbJjXcho04KMNuipfGFylcf+ptwVIvg2PPk/s8tp?=
 =?iso-8859-1?Q?drVTJTZwBXWPhlSbXPgnTEvPxHEuZebKiICfJeEsDtSAKnmzQ9oeunpoa8?=
 =?iso-8859-1?Q?5rS1akl5fTuPhun68hrAld2myfP8PWtd3eOJ2oamJV3MapFHuMs7ZXpLKB?=
 =?iso-8859-1?Q?TQn3f2E1kecTgN2EghvJQmQeHgvK11sRTC5bw3R69OKw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8934.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:
 =?iso-8859-1?Q?JUfyNbQjU1GAHZP5a0lMqAw6rH8fLz7iWM7zpk1kYpj2X3eq2FmdvMjL1D?=
 =?iso-8859-1?Q?G8SQHr5HwnUfLEKDWcyVStLwXrLSWXw4AFFUGlgTbAuHnz9rcjGhsci65P?=
 =?iso-8859-1?Q?z2/o8up36byjc/aW/XJyocQo7kYC//z34x+sYE+0HcMjwuii5eWREQVt4d?=
 =?iso-8859-1?Q?LS9e5P6lqe0/R1t5RPXGlRBsmIJyqgURYTILPLW6Vxzqo2UovldwIPdIZT?=
 =?iso-8859-1?Q?wHt4ZvLSzNPcZGG9n/nX4pbze6e5832r9rJn3zPy6dBqLtsYzAjtLKkjkD?=
 =?iso-8859-1?Q?6wqNioVAgPOS9GCpsvnnOcNWidwmYP+JAmV4tLpVuGHko2OVUDO2WYtRik?=
 =?iso-8859-1?Q?3y1Q5vSL1oan239syTAIKCPQ8fZY8LVNLECwzAVOTqleh33Y7lV5KiD+45?=
 =?iso-8859-1?Q?cFBzaZHx2ZC2J1qDg+8ek077N2qK+VKRbzkv3O1x+91XPsRRXrdNiFkUjn?=
 =?iso-8859-1?Q?qQCzg0LQTVWBNOvyCTjIJEp74ONCbHHP9JjlT6PlhbRXSTMjdLrw5xfNd/?=
 =?iso-8859-1?Q?iJoQvLr8Owu0hM0L4vDVzT/LHyynO7lH4m5iiE18Y+DLQ5m60vApImNDxQ?=
 =?iso-8859-1?Q?0mfogEp6aIXvF6fH2RmoHk8pjty+ogNLBOWWhi8TEuHIRb8sHq+whx38VV?=
 =?iso-8859-1?Q?0zyM9TA30NnNlgyU974n0d4iW0lqta1gdI8VRV9mbrqPkSf8Er+Vs8vcup?=
 =?iso-8859-1?Q?+7AWYBwMASDmLGzEd8RQQTKvveIC9dI4WX6uRiiXogubhb7ihVQOzFomc1?=
 =?iso-8859-1?Q?y1CB+3coTLSlOBsh04l8BJOwqgPZ1tWM01n8uoJ9a44ko0/vyAp856/y42?=
 =?iso-8859-1?Q?We7YCKCCU6gQ84SIpLIHUCfAYKiRr0JfsV1kukcSSVDPgRIw4vcK27M7je?=
 =?iso-8859-1?Q?A2b1STZorUdMbLkOYW6d6dwp+DL7Eeh7LnU2fKVll2shF/h4FJppvBm5fw?=
 =?iso-8859-1?Q?gdMNiNGCuwCKT5QOuECUD1XNrRIpDOvNlSHHd3fqOS4NI87tClKcLBjMLt?=
 =?iso-8859-1?Q?cUuiuQ3JUfamACrSAq+Bj8k3YVtImLS930hPC+YTd/wW6SNCluwIerxMzi?=
 =?iso-8859-1?Q?YWGCOQX7wNpO5IfL69xZLpFBfRg3Xy3BWM/BDq4XQfp9EMz4560DHPqyAU?=
 =?iso-8859-1?Q?oavONkj+EVYlBRdQpQZQZjgXpfvIDQHH386B62cJQSCo10fQxNBEOpgCqD?=
 =?iso-8859-1?Q?VVWcQUCS+nZ2XSHRWEdS93crfwOajGAvy9kpMgE8GP1GWfGBebiWa6Q0s6?=
 =?iso-8859-1?Q?BuFUhvyKWag+6RbMqE9rsA90VAlBNLt8/AqoOqWIug8/vpaeQwkmbcu481?=
 =?iso-8859-1?Q?oAdgpwMjRWvTfNqiwfv0aDfka+K/Benf8ij4Fy2GSFwiOuticFqlqSJZnB?=
 =?iso-8859-1?Q?Kr9CkJ7qvpZfYzE0Vozmym42+3IiXD4um6C/HPo3rr4K5IKAzNxW5b466R?=
 =?iso-8859-1?Q?jwszTRgRwlskGE22dRKBBt6mDsfDllgKqiiW1W9bI+SrdIbPfMNacbR4+b?=
 =?iso-8859-1?Q?uGbVt4NrNHj/7WLyQ/5ivs5XtK5i06pm/wlaWc11ncG+8U5AQ2YTCbb4xP?=
 =?iso-8859-1?Q?6SK0WoWNxLSRHV8idOQVXSl4tyYvEtQubF8mq1Ay7QnQ0S5jUQEevKbgm8?=
 =?iso-8859-1?Q?mZIRfHewb3QLIk8jvXvNOmJmmQhJX5fs0pvW3ivKgDvHmUrtLVHoYPVQ?=
 =?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: DU0PR03MB8934.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ea15c19-5fc1-4378-494a-08ddebbe560b
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 14:21:27.2395
 (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: ZzeoS0wSaXjo7kwRiIYSNa4xOqeBAQpuMxJqUWlm0t8cT01ZnQBH86LIMrLobrG5XzJcwWrGp9InHoq7PBCaPZYU/dV2OdgwNgSeWpaHWlM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8751

This patch adds the basic framework for ARM SCI mediator. SCI is System
Control Interface, which is designed to redirect requests from the Domains
to ARM specific Firmware (for example SCMI). This will allow the devices,
passed-through to the different Domains, to access to the System resources
(such as clocks/resets etc) by sending requests to the firmware.

ARM SCI subsystem allows to implement different SCI drivers to handle
specific ARM firmware interfaces (like ARM SCMI) and mediate requests
-between the Domains and the Firmware. Also it allows SCI drivers to perfor=
m
proper action during Domain creation/destruction which is vital for
handling use cases like Domain reboot.

This patch introduces new DEVICE_FIRMWARE device subclass for probing SCI
drivers basing on device tree, SCI drivers register itself with
DT_DEVICE_START/END macro. On init - the SCI drivers should register its
SCI ops with sci_register(). Only one SCI driver can be supported.

At run-time, the following SCI API calls are introduced:

- sci_domain_sanitise_config() called from arch_sanitise_domain_config()
- sci_domain_init() called from arch_domain_create()
- sci_relinquish_resources() called from domain_relinquish_resources()
- sci_domain_destroy() called from arch_domain_destroy()
- sci_handle_call() called from vsmccc_handle_call()
- sci_dt_handle_node()
- sci_dt_finalize() called from handle_node() (Dom0 DT)

Signed-off-by: Oleksii Moisieiev 
Signed-off-by: Grygorii Strashko 
Reviewed-by: Stefano Stabellini 
---

Changes in v9:
- change input param name for sci_handle_call function to match MISRA rules

Changes in v7:
- fix sci_handl_call to make changes more readable
- fix build error when DOM0LESS_BUILD is disabled (removed
 arch_handle_passthrough_prop from the header)
- sort headers in alphabetical order in sci.h

Changes in v6:
- rebase on top of the latest master
- fix return value of sci_dt_finalize() call

Changes in v5:
- update Maintainers file. Set role as a Reviewer
- rebased on the latest master branch
- Introduce arch_handle_passthrough_prop call to handle arm specific nodes

Changes in v4:
- fix SPDX-License
- rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
- move XEN_DOMCTL_assign_device code in separate patch
- Add documentation for SCI SCMI drivers

 MAINTAINERS                             |   6 +
 xen/arch/arm/device.c                   |   5 +
 xen/arch/arm/dom0less-build.c           |   8 +
 xen/arch/arm/domain.c                   |  12 +-
 xen/arch/arm/domain_build.c             |   8 +
 xen/arch/arm/firmware/Kconfig           |   8 +
 xen/arch/arm/firmware/Makefile          |   1 +
 xen/arch/arm/firmware/sci.c             | 154 ++++++++++++++++++
 xen/arch/arm/include/asm/domain.h       |   5 +
 xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++++++++
 xen/arch/arm/vsmc.c                     |   3 +-
 xen/common/device-tree/dom0less-build.c |   4 +
 xen/include/asm-generic/device.h        |   1 +
 xen/include/public/arch-arm.h           |   4 +
 xen/include/xen/dom0less-build.h        |   3 +
 15 files changed, 420 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/firmware/sci.c
 create mode 100644 xen/arch/arm/include/asm/firmware/sci.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c4886c1159..31dbba54bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -509,6 +509,12 @@ R:	George Dunlap 
 S:	Supported
 F:	xen/common/sched/
=20
+SCI MEDIATORS
+R:	Oleksii Moisieiev 
+S:	Supported
+F:	xen/arch/arm/firmware/sci.c
+F:	xen/arch/arm/include/asm/firmware/sci.h
+
 SEABIOS UPSTREAM
 M:	Wei Liu 
 S:	Supported
diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 11523750ae..74b54cad34 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -13,6 +13,7 @@
 #include 
 #include 
=20
+#include 
 #include 
=20
 int map_irq_to_domain(struct domain *d, unsigned int irq,
@@ -303,6 +304,10 @@ int handle_device(struct domain *d, struct dt_device_n=
ode *dev, p2m_type_t p2mt,
                 return res;
             }
         }
+
+        res =3D sci_assign_dt_device(d, dev);
+        if ( res )
+            return res;
     }
=20
     res =3D map_device_irqs_to_domain(d, dev, own_device, irq_ranges);
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index c8d07213e2..0094cf9e40 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -22,6 +22,7 @@
=20
 #include 
 #include 
+#include 
 #include 
 #include 
=20
@@ -272,6 +273,12 @@ int __init init_vuart(struct domain *d, struct kernel_=
info *kinfo,
     return rc;
 }
=20
+int __init arch_handle_passthrough_prop(struct kernel_info *kinfo,
+                                        struct dt_device_node *node)
+{
+    return sci_assign_dt_device(kinfo->bd.d, node);
+}
+
 int __init arch_parse_dom0less_node(struct dt_device_node *node,
                                     struct boot_domain *bd)
 {
@@ -281,6 +288,7 @@ int __init arch_parse_dom0less_node(struct dt_device_no=
de *node,
=20
     d_cfg->arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
     d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;
+    d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
=20
     if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) )
     {
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 863ae18157..1a8585d02b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -699,7 +700,7 @@ int arch_sanitise_domain_config(struct xen_domctl_creat=
edomain *config)
         return -EINVAL;
     }
=20
-    return 0;
+    return sci_domain_sanitise_config(config);
 }
=20
 int arch_domain_create(struct domain *d,
@@ -791,6 +792,9 @@ int arch_domain_create(struct domain *d,
     d->arch.sve_vl =3D config->arch.sve_vl;
 #endif
=20
+    if ( (rc =3D sci_domain_init(d, config)) !=3D 0 )
+        goto fail;
+
     return 0;
=20
 fail:
@@ -851,6 +855,7 @@ void arch_domain_destroy(struct domain *d)
     domain_vgic_free(d);
     domain_vuart_free(d);
     free_xenheap_page(d->shared_info);
+    sci_domain_destroy(d);
 #ifdef CONFIG_ACPI
     free_xenheap_pages(d->arch.efi_acpi_table,
                        get_order_from_bytes(d->arch.efi_acpi_len));
@@ -1044,6 +1049,7 @@ enum {
     PROG_p2m_root,
     PROG_p2m,
     PROG_p2m_pool,
+    PROG_sci,
     PROG_done,
 };
=20
@@ -1103,6 +1109,10 @@ int domain_relinquish_resources(struct domain *d)
         ret =3D relinquish_p2m_mapping(d);
         if ( ret )
             return ret;
+    PROGRESS(sci):
+        ret =3D sci_relinquish_resources(d);
+        if ( ret )
+            return ret;
=20
     PROGRESS(p2m_root):
         /*
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a9e4153e3c..039aa71439 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1640,6 +1641,9 @@ static int __init handle_node(struct domain *d, struc=
t kernel_info *kinfo,
         return 0;
     }
=20
+    if ( sci_dt_handle_node(d, node) )
+        return 0;
+
     /*
      * The vGIC does not support routing hardware PPIs to guest. So
      * we need to skip any node using PPIs.
@@ -1740,6 +1744,10 @@ static int __init handle_node(struct domain *d, stru=
ct kernel_info *kinfo,
         if ( res )
             return res;
=20
+        res =3D sci_dt_finalize(d, kinfo->fdt);
+        if ( res )
+            return res;
+
         /*
          * Create a second memory node to store the ranges covering
          * reserved-memory regions.
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index 817da745fd..fc7918c7fc 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -1,3 +1,11 @@
+config ARM_SCI
+	bool
+	depends on ARM
+	help
+	  This option enables generic Arm SCI (System Control Interface) mediator=
s
+	  support. It allows domains to control system resources via one of
+	  Arm SCI mediators drivers implemented in XEN, like SCMI.
+
 menu "Firmware Drivers"
=20
 config SCMI_SMC
diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil=
e
index a5e4542666..71bdefc24a 100644
--- a/xen/arch/arm/firmware/Makefile
+++ b/xen/arch/arm/firmware/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_ARM_SCI) +=3D sci.o
 obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o
diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
new file mode 100644
index 0000000000..aa93cda7f0
--- /dev/null
+++ b/xen/arch/arm/firmware/sci.c
@@ -0,0 +1,154 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Generic part of the SCI (System Control Interface) subsystem.
+ *
+ * Oleksii Moisieiev 
+ * Copyright (c) 2025 EPAM Systems
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct sci_mediator_ops __read_mostly *cur_mediator;
+
+int sci_register(const struct sci_mediator_ops *ops)
+{
+    if ( cur_mediator )
+        return -EEXIST;
+
+    if ( !ops->domain_init || !ops->domain_destroy || !ops->handle_call )
+        return -EINVAL;
+
+    cur_mediator =3D ops;
+
+    return 0;
+};
+
+bool sci_handle_call(struct cpu_user_regs *regs)
+{
+    if ( unlikely(!cur_mediator) )
+        return false;
+
+    return cur_mediator->handle_call(regs);
+}
+
+int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf=
ig)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    return cur_mediator->domain_init(d, config);
+}
+
+int sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->domain_sanitise_config )
+        return 0;
+
+    return cur_mediator->domain_sanitise_config(config);
+}
+
+void sci_domain_destroy(struct domain *d)
+{
+    if ( !cur_mediator )
+        return;
+
+    cur_mediator->domain_destroy(d);
+}
+
+int sci_relinquish_resources(struct domain *d)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->relinquish_resources )
+        return 0;
+
+    return cur_mediator->relinquish_resources(d);
+}
+
+bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->dom0_dt_handle_node )
+        return 0;
+
+    return cur_mediator->dom0_dt_handle_node(d, node);
+}
+
+int sci_dt_finalize(struct domain *d, void *fdt)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->dom0_dt_finalize )
+        return 0;
+
+    return cur_mediator->dom0_dt_finalize(d, fdt);
+}
+
+int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
+{
+    struct dt_phandle_args ac_spec;
+    int index =3D 0;
+    int ret;
+
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->assign_dt_device )
+        return 0;
+
+    while ( !dt_parse_phandle_with_args(dev, "access-controllers",
+                                        "#access-controller-cells", index,
+                                        &ac_spec) )
+    {
+        printk(XENLOG_DEBUG "sci: assign device %s to %pd\n",
+               dt_node_full_name(dev), d);
+
+        ret =3D cur_mediator->assign_dt_device(d, &ac_spec);
+        if ( ret )
+            return ret;
+
+        index++;
+    }
+
+    return 0;
+}
+
+static int __init sci_init(void)
+{
+    struct dt_device_node *np;
+    unsigned int num_sci =3D 0;
+    int rc;
+
+    dt_for_each_device_node(dt_host, np)
+    {
+        rc =3D device_init(np, DEVICE_FIRMWARE, NULL);
+        if ( !rc && num_sci )
+        {
+            printk(XENLOG_ERR
+                   "SCMI: Only one SCI controller is supported. found seco=
nd %s\n",
+                   np->name);
+            return -EOPNOTSUPP;
+        }
+        else if ( !rc )
+            num_sci++;
+        else if ( rc !=3D -EBADF && rc !=3D -ENODEV )
+            return rc;
+    }
+
+    return 0;
+}
+
+__initcall(sci_init);
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index a3487ca713..af3e168374 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -120,6 +120,11 @@ struct arch_domain
 #ifdef CONFIG_TEE
     void *tee;
 #endif
+#ifdef CONFIG_ARM_SCI
+    bool sci_enabled;
+    /* ARM SCI driver's specific data */
+    void *sci_data;
+#endif
=20
 }  __cacheline_aligned;
=20
diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include=
/asm/firmware/sci.h
new file mode 100644
index 0000000000..3500216bc2
--- /dev/null
+++ b/xen/arch/arm/include/asm/firmware/sci.h
@@ -0,0 +1,200 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Generic ARM SCI (System Control Interface) subsystem.
+ *
+ * Oleksii Moisieiev 
+ * Copyright (c) 2025 EPAM Systems
+ */
+
+#ifndef __ASM_ARM_SCI_H
+#define __ASM_ARM_SCI_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_ARM_SCI
+
+struct sci_mediator_ops {
+    /*
+     * Called during domain construction. If it is requested to enable
+     * SCI support, so SCI driver can create own structures for the new do=
main
+     * and inform firmware about new domain (if required).
+     * Mandatory.
+     */
+    int (*domain_init)(struct domain *d,
+                       struct xen_domctl_createdomain *config);
+
+    /*
+     * Called during domain construction. The SCI driver uses
+     * it to sanitize domain SCI configuration parameters.
+     * Optional.
+     */
+    int (*domain_sanitise_config)(struct xen_domctl_createdomain *config);
+
+    /*
+     * Called during domain destruction, releases all resources, that
+     * were allocated for domain.
+     * Mandatory.
+     */
+    void (*domain_destroy)(struct domain *d);
+
+    /*
+     * Called during domain destruction to relinquish resources used
+     * by SCI driver itself and request resources releasing from firmware.
+     * Optional.
+     */
+    int (*relinquish_resources)(struct domain *d);
+
+    /* SMC/HVC Handle callback */
+    bool (*handle_call)(struct cpu_user_regs *regs);
+
+    /*
+     * Dom0 DT nodes handling callback so SCI driver can detect DT nodes i=
t
+     * need to handle and decide if those nodes need to be provided to Dom=
0.
+     * Optional.
+     */
+    bool (*dom0_dt_handle_node)(struct domain *d, struct dt_device_node *n=
ode);
+
+    /*
+     * SCI driver callback called at the end of Dom0 DT generation, so
+     * it can perform steps to modify DT to enable/disable SCI
+     * functionality for Dom0.
+     */
+    int (*dom0_dt_finalize)(struct domain *d, void *fdt);
+
+    /*
+     * SCI driver callback called when DT device is passed through to gues=
t,
+     * so SCI driver can enable device access to the domain if SCI FW prov=
ides
+     * Device specific access control functionality.
+     * Optional.
+     */
+    int (*assign_dt_device)(struct domain *d, struct dt_phandle_args *ac_s=
pec);
+};
+
+
+static inline bool sci_domain_is_enabled(struct domain *d)
+{
+    return d->arch.sci_enabled;
+}
+
+/*
+ * Register SCI subsystem ops.
+ *
+ * Register SCI drivers operation and so enable SCI functionality.
+ * Only one SCI driver is supported.
+ */
+int sci_register(const struct sci_mediator_ops *ops);
+
+/*
+ * Initialize SCI functionality for domain if configured.
+ *
+ * Initialization routine to enable SCI functionality for the domain.
+ * The SCI configuration data and decision about enabling SCI functionalit=
y
+ * for the domain is SCI driver specific.
+ */
+int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf=
ig);
+
+/*
+ * Sanitise domain configuration parameters.
+ *
+ */
+int sci_domain_sanitise_config(struct xen_domctl_createdomain *config);
+
+/*
+ * Destroy SCI domain instance.
+ */
+void sci_domain_destroy(struct domain *d);
+
+/*
+ * Free resources assigned to the certain domain.
+ */
+int sci_relinquish_resources(struct domain *d);
+
+/*
+ * SMC/HVC Handle callback.
+ *
+ * SCI driver acts as SMC/HVC server for the registered domains and
+ * does redirection of the domain calls to the SCI firmware,
+ * such as ARM TF-A or similar.
+ */
+bool sci_handle_call(struct cpu_user_regs *regs);
+
+/*
+ * Dom0 DT nodes handling function.
+ *
+ * Allows SCI driver to detect DT nodes it need to handle and decide if
+ * those nodes need to be provided to Dom0.
+ */
+bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node);
+
+/*
+ * Dom0 DT generation finalize.
+ *
+ * Called at the end of Dom0 DT generation, so SCI driver can perform step=
s
+ * to modify DT to enable/disable SCI functionality for Dom0.
+ */
+int sci_dt_finalize(struct domain *d, void *fdt);
+
+/*
+ * Assign DT device to domain.
+ *
+ * Called when DT device is passed through to guest, so SCI driver can ena=
ble
+ * device access to the domain if SCI FW provides "Device specific access
+ * control" functionality.
+ */
+int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
+#else
+
+static inline bool sci_domain_is_enabled(struct domain *d)
+{
+    return false;
+}
+
+static inline int sci_domain_init(struct domain *d,
+                                  struct xen_domctl_createdomain *config)
+{
+    return 0;
+}
+
+static inline int
+sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
+{
+    return 0;
+}
+
+static inline void sci_domain_destroy(struct domain *d)
+{}
+
+static inline int sci_relinquish_resources(struct domain *d)
+{
+    return 0;
+}
+
+static inline bool sci_handle_call(struct cpu_user_regs *regs)
+{
+    return false;
+}
+
+static inline bool sci_dt_handle_node(struct domain *d,
+                                      struct dt_device_node *node)
+{
+    return false;
+}
+
+static inline int sci_dt_finalize(struct domain *d, void *fdt)
+{
+    return 0;
+}
+
+static inline int sci_assign_dt_device(struct domain *d,
+                                       struct dt_device_node *dev)
+{
+    return 0;
+}
+
+#endif /* CONFIG_ARM_SCI */
+
+#endif /* __ASM_ARM_SCI_H */
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 6081f14ed0..4095171533 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -232,7 +233,7 @@ static bool handle_sip(struct cpu_user_regs *regs)
     if ( platform_smc(regs) )
         return true;
=20
-    return scmi_handle_smc(regs);
+    return (scmi_handle_smc(regs)) ? true : sci_handle_call(regs);
 }
=20
 /*
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index badc227031..aaa5e9b22c 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -228,6 +228,10 @@ static int __init handle_passthrough_prop(struct kerne=
l_info *kinfo,
     if ( res < 0 )
         return res;
=20
+    res =3D arch_handle_passthrough_prop(kinfo, node);
+    if ( res )
+        return res;
+
     /* If xen_force, we allow assignment of devices without IOMMU protecti=
on. */
     if ( xen_force && !dt_device_is_protected(node) )
         return 0;
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/dev=
ice.h
index 3bd97e33c5..cb13f7faea 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -18,6 +18,7 @@ enum device_class
     DEVICE_IOMMU,
     DEVICE_INTERRUPT_CONTROLLER,
     DEVICE_PCI_HOSTBRIDGE,
+    DEVICE_FIRMWARE,
     /* Use for error */
     DEVICE_UNKNOWN,
 };
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e2412a1747..e7a17ede3e 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -327,6 +327,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 #define XEN_DOMCTL_CONFIG_TEE_OPTEE     1
 #define XEN_DOMCTL_CONFIG_TEE_FFA       2
=20
+#define XEN_DOMCTL_CONFIG_ARM_SCI_NONE      0
+
 struct xen_arch_domainconfig {
     /* IN/OUT */
     uint8_t gic_version;
@@ -350,6 +352,8 @@ struct xen_arch_domainconfig {
      *
      */
     uint32_t clock_frequency;
+    /* IN */
+    uint8_t arm_sci_type;
 };
 #endif /* __XEN__ || __XEN_TOOLS__ */
=20
diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-bu=
ild.h
index 408859e325..faaf660424 100644
--- a/xen/include/xen/dom0less-build.h
+++ b/xen/include/xen/dom0less-build.h
@@ -62,6 +62,9 @@ void set_domain_type(struct domain *d, struct kernel_info=
 *kinfo);
 int init_intc_phandle(struct kernel_info *kinfo, const char *name,
                       const int node_next, const void *pfdt);
=20
+int arch_handle_passthrough_prop(struct kernel_info *kinfo,
+                                 struct dt_device_node *node);
+
 #else /* !CONFIG_DOM0LESS_BOOT */
=20
 static inline void create_domUs(void) {}
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:21:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:21:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110287.1459583 (Exim 4.92)
	(envelope-from )
	id 1uuAqK-0006bg-IP; Thu, 04 Sep 2025 14:21:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110287.1459583; Thu, 04 Sep 2025 14:21: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 1uuAqK-0006bV-Ea; Thu, 04 Sep 2025 14:21:40 +0000
Received: by outflank-mailman (input) for mailman id 1110287;
 Thu, 04 Sep 2025 14:21: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 1uuAqI-0005ts-MZ
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:21:38 +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 77580edf-899a-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:21:36 +0200 (CEST)
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com (2603:10a6:10:473::15)
 by GV2PR03MB8751.eurprd03.prod.outlook.com (2603:10a6:150:a8::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 14:21:28 +0000
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40]) by DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40%7]) with mapi id 15.20.9052.013; Thu, 4 Sep 2025
 14:21: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: 77580edf-899a-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xjnJOz4kzjyGz+9hbMnanO9ye/Jl4hoWy6YrxVOwwZLSTqubUmo4AYhBMix0Q+DiQ/OuNIVSynA4Foj9IutlUF3L4tpmzWj2TN5HConArzfmz9kdb/q0u56xjiP3Iiuj3MrNfCFEmsAE2yUKH1h3T/vwvol4gUBSSj9iZH54I8xJy2io8ndi7wrkR0ZxYwD/Rai+WKPVQpEH9BNsFMmpl4obqPJpdmQ3Hn/lk+N2UF4Ssoz3HoI0hTbhOamfZC2O4gjJZACgNzHIFGAxLRVm7WjLc+a8GhfculakbuWPJnGasjZProuEZC16Rc/n4/kn3zVrwrXq6O1WvQD2IkXnMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qLqKtUXnnhvD9/L7FKSmlG8ST1SlgHYQ55gQP5fFKiI=;
 b=XC78V7Z6Xl/1MxR6uMvWQXsHvpitVY9lE7oS9s6l1kOQplocxXGqhR6JaV/KqnjAVKdNt0TLDw9x8uLDXDUixkqmJYcGTVFllydcWt570IHeAFk/dePGBYWVsJHFOCTFte5/Yiqu9sYLi0Iv7MzDYgKeswq7Fm4dG0r+tgmSesIBUvxd9pdIIlfMT1QZW04L2ZAjlRdKfKHEwI5BUhpy2/E+J9+5UZzZWtMPkFbVeTJG36G+F4i0O612LEol56sFQLrlQA4Vst+D+5+ggXhfVi21KHncs3wQL5haMOPq6QJQoL5TIzuEuaseEPsP+M3P0F1KtevONOJXC8M29LjuOA==
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=qLqKtUXnnhvD9/L7FKSmlG8ST1SlgHYQ55gQP5fFKiI=;
 b=Gh/KkS1EiboPbLxMXtIf7t65408TR9Z4Sltqy4NSrMzMQ+Eks73+jWroTar+r42BBzwO/7tcx2AfeuGhzCZhZbWTh2juvbNzzXy1vsgdaSNC2O7x8t+OC/Fah6TE5ZFGMEQ/wS9qgvri2/p0o9YMHdNHuNBf+F4eiGSKdBNezyy28Qi/MC5GFcseHtB3yo4lQ/DuCXs3tH/EB3OiHob6eo9aPCeYjtHHjEExZZ1sA5R8vwZXUgU2IU6s5UJcXhOUQqZ03dzCshgAMOYZgoAAH6+6yZihQzP/xAdAqIYhbbWOOdvcsTMbhjMTaiiPkchCoG8q2JyPelRYeeJkThuA8w==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel , Oleksii Moisieiev
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Grygorii Strashko
	
Subject: [PATCH v9 2/4] xen/arm: scmi-smc: update to be used under sci
 subsystem
Thread-Topic: [PATCH v9 2/4] xen/arm: scmi-smc: update to be used under sci
 subsystem
Thread-Index: AQHcHaczwiXWETSGtUC3f6Sg3ujscw==
Date: Thu, 4 Sep 2025 14:21:27 +0000
Message-ID:
 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0PR03MB8934:EE_|GV2PR03MB8751:EE_
x-ms-office365-filtering-correlation-id: a00457a0-5939-4a70-17a7-08ddebbe563d
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:
 =?iso-8859-1?Q?ArRqZYeNxee8ki1fQ76xsDP/X3cBNIFySWT9k1DDprrQg/yb94VQVFa+z0?=
 =?iso-8859-1?Q?+sO24Eok+ZfxHh0Cn9q0sMuat4DSJngaRa28Uz9uXOubBzyBwL4ZGlH+3G?=
 =?iso-8859-1?Q?BrJZ0dbjJCDN2GURukQjSnmiZMXcdgld6p5Ihu90phxrLfvQp9VG0v8dKb?=
 =?iso-8859-1?Q?kF4RtVvgggjNtBX7FxpotZZ+GKTi1SghR3f54Z31xVR/tUeHDHXstRk4Dj?=
 =?iso-8859-1?Q?2KdKrd5Vf0i+ZBpPNEotdacWruqgW6IaARoDDugirp5F53M51Fch9DYJsO?=
 =?iso-8859-1?Q?Tu0R/T7JdEXq9WULfz/+CDPUf5WRxKbopjdEYabdVm2UYdcudmuDFgpgU5?=
 =?iso-8859-1?Q?2vtqaYY5L055M9PZtWFaaiaWYHSbBemvYezqePxoQOGEmMRClz2iKwigEY?=
 =?iso-8859-1?Q?PQh18S/c3ULUjYWVS+acfbiBz6wDj3vKTTLIqeUs/olxBDsu470V4SCuFe?=
 =?iso-8859-1?Q?24fv0fnp2U9Koj8xWIS9wonxmKAw7pWw+Fgv2KTOfI5qYa/9TvZ9R6WrKe?=
 =?iso-8859-1?Q?HrXAVCLfEFZ4i1MYow4lOoXtPS6j296VsAqljMkbJzQf0cxPhwLx8UC8a6?=
 =?iso-8859-1?Q?qvz9y4nh0AMBcywfd+lDJoE3sZCvhpeAVB+Vp/g/Izld+5MdK9pHKlSC20?=
 =?iso-8859-1?Q?hgQTEB5J5bJffJHOwMebSLCTFl+uJy5kYaaesJcTSLMzGt78aVpGgar/Ux?=
 =?iso-8859-1?Q?2J388pbqAjV6jR9DO6idLTOg1x/KFuA9XWmW29ULFtLVyBJy0gux2zS+jB?=
 =?iso-8859-1?Q?Nq4Yl9LQLeNm+c3zUDfUKr7KWMOcdwv6vlyPR7YsebiXvDp5nKPnzmGywz?=
 =?iso-8859-1?Q?62UhDAvJgty8qqRUQa1J+yan5QPddPf0nHBqpx6D0cHVshnTzhfoO7xRrC?=
 =?iso-8859-1?Q?16DgUm3yQWDOY169zcTfUoDEGp70FnexRNJGuVotN+iuBxdB9BFn3pQEK2?=
 =?iso-8859-1?Q?2mR7oOyclKzbAE0ugceOqATH/mut1R4bdy2dYbW0Bo110Eh6Jb2/UEkdKR?=
 =?iso-8859-1?Q?VKYEFqHCLjO+wHG+l9hRygHDMQWhhmygJGMt0vCxk9WFS+cQOCXmEWRIT7?=
 =?iso-8859-1?Q?gHk+zGfGQJ6Ceoqa3Bj77OvjuHF+a3QPUiEKL00UhShp6H6u6BqmHvJpA9?=
 =?iso-8859-1?Q?rxAhXeTohqW9tmZUeBQyKyYxZbM7hdgckl/FTVJ4wLaTSbKk+ue39CxwsL?=
 =?iso-8859-1?Q?+4aYq9PSmUZbyXw3HW944E5COhuTru5bO/Q3a+UjhYH9wMRu3RQtk7EiAV?=
 =?iso-8859-1?Q?nsL6iV1aSi8A9oS/619qBuPndYNPDFAa8RxCekIvFlRN3yyjkfmAxCEnxm?=
 =?iso-8859-1?Q?lgxD3GCOKgLILbVeF9sVzHqPmyQ7VqJLxOWaSIY5RaR+XIwHqh+VbyGLwJ?=
 =?iso-8859-1?Q?g0SYfuStSq2AS6l7kSp7nBmLF2onm9Be2L0LUPflDvlpV9+cToiBg+OyTw?=
 =?iso-8859-1?Q?lV7MVnhuyEqCGuC9Ihl8JhkjWm3HJNaRin8tZV8Vu1ssf/TSfXUcL+YwyQ?=
 =?iso-8859-1?Q?T6CJRx4GMvUgf0oF1p3y74ZQ2Cs8F4nun+TZ08A3jrGw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8934.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:
 =?iso-8859-1?Q?7tmWfT43VPUzIYxRme6lD93HSrE7p8jyQYSBFwI5o4wmiX/rlRxS9aBzuS?=
 =?iso-8859-1?Q?k81b06Y7gIs5RYPkY+fx7PqLuSlr7b7tlPtTZcpkn+HRHhKvHlH6S+JaPj?=
 =?iso-8859-1?Q?Cw14ooKccAZkqS5GIr/p73ocnIQSyOnnoPFj5vEWHaxO+ijBqa35d1mLjh?=
 =?iso-8859-1?Q?1E+ysGtRicciNnWeqjjPij/FZbiaEVACf8HGYOV18uxOhWiUlJb28YDQgL?=
 =?iso-8859-1?Q?RZwqe6hL8ogcNPKUYiFHUDZO4bm9vLcDgQS1x7vuKKbhja5sj/4vTYVmus?=
 =?iso-8859-1?Q?OmGoriQo4Erm3/NweIQp12xOpfN46xP2xj4WZmeKPWfxB4LzRXX5JA67Gq?=
 =?iso-8859-1?Q?j+tHV2w/2l9dWnNdCnRAP5IBBj6yfpEJXZh2Mm+Y4pZccjJTdt/F0IJMYX?=
 =?iso-8859-1?Q?dsnJckD5cKoaWYZSvoRHxdhNuu15VxBsZZqU7cJRRI1Q2Ep+8KogxYWZ41?=
 =?iso-8859-1?Q?JSjZP24UHbA//xnKMQOZfz2XLnA6pN+S2FQ0lVnf5ZvcnVPcDyxOYT7fL2?=
 =?iso-8859-1?Q?KNIEZ3evBmCIQL67FG/1WT+aEI3zxMtloCwX0ZjYqQqeApusY2E87lY/0d?=
 =?iso-8859-1?Q?AB6LvWcLYKz/NRGVT5a8cp7YKhjzAd0luK1HQfStKlYjikzQ+cBYzr4hep?=
 =?iso-8859-1?Q?+vP6p8FW9fx0gmOrhNbKgQwyIoxYuLED2D5StkQfspx5llFslgFTlhsEjG?=
 =?iso-8859-1?Q?yGZxqJuLrnXgyPjZc6haZ5FrI/158b6CmRaJlFvCfwOIM5tZ32iCab/7cB?=
 =?iso-8859-1?Q?w69hfZSVtlMdgEz4peDAZyoJIFlFo/eo63le+Qp44wGmc3Rs4cXOPirhYf?=
 =?iso-8859-1?Q?qSM64VfuJTC7N+ikaOi8O6IwxWohcQcEYBs3hLJSGw5CfpFnrskTnHiV5I?=
 =?iso-8859-1?Q?Eue3kxrFEjlYa4kl1PWM1hN+MAndOHeIxeHNZerrVZedr5BQaiOMF8UlYL?=
 =?iso-8859-1?Q?Mw9SH4gqJzcEdK2cf5pwonL1x6+WdtRik+VqmYKcM6FsyNM0B4ywWG5rz3?=
 =?iso-8859-1?Q?qm3rjAgG3fAzgzjcxUvosb3jjlxpsaYkprLvgYr0C8nHVBE8zmEt/yBQ0o?=
 =?iso-8859-1?Q?oG6zH7aVLZsQsBjhTUCCch+MxV+2EljKj5wtDEM64gIdilvKmFd/Y3hQC9?=
 =?iso-8859-1?Q?WcID00E7oLKH8MX9Q25+NTv1CfYQr7jfLjFBl/bpXWrmhLuD1DBQCRMoE9?=
 =?iso-8859-1?Q?yO4ZZLAt9CLOLNQkkeRYfvXpZGM2722yIR90UC+/6nTBmUHPPzE9heACIb?=
 =?iso-8859-1?Q?e5Px9qEHvwSlbCQigl4DIYTJgGsRej/ujXWcHdRe1PUX9pkxEXqaNcYzHn?=
 =?iso-8859-1?Q?PmUlWsxNm//Q4Ln86FxnlXdD6c3Fc9KSPt8ecmB8mOxG1nKNRXJhZL+eog?=
 =?iso-8859-1?Q?o8jpolhm26CRmb4pWcjBNPt+fte9TuJ2DOMEQ6LMgqWfyNzOljblMwb4Wg?=
 =?iso-8859-1?Q?McFp21tOC0JFjvcYAbBFcv/NkaTsxv0aBNs3KrczPSC6pwc2kz9JOHRFGm?=
 =?iso-8859-1?Q?ueldGPNUXEAo6U5v0gA7wESytwGiFL13wD8AUyslFw7pMoTpsM2g7RKtuU?=
 =?iso-8859-1?Q?UJ8au3+LV4CMyjeWqctopdypgH3RyHOMFCtRJukYY3tfzG+cBm1Eva4Ics?=
 =?iso-8859-1?Q?sNWXaQ24C/sbYhOYyEq1Qnan5/Fee/RrEw6EIqzuPXfXxcQ/NkAh7Sjw?=
 =?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: DU0PR03MB8934.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a00457a0-5939-4a70-17a7-08ddebbe563d
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 14:21:27.5197
 (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: 3992foHw6gz3wsQr2lV0uXTFZ8Nc6oF/rcoZx4Q8FP+hhRfszUo5SRRA1P36qHBeDHtPSnTT+iOOvHtwWGWoHmKw7C3Wn8aynDIyoWczmdU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8751

From: Grygorii Strashko 

The introduced SCI (System Control Interface) subsystem provides unified
interface to integrate in Xen SCI drivers which adds support for ARM
firmware (EL3, SCP) based software interfaces (like SCMI) that are used in
system management. The SCI subsystem allows to add drivers for different FW
interfaces or have different drivers for the same FW interface (for example=
,
SCMI with different transports).

This patch updates SCMI over SMC calls handling layer, introduced by
commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling
layer"), to be SCI driver:
- convert to DT device;
- convert to SCI Xen interface.

There are no functional changes in general, the driver is just adopted
to the SCI interface.

Signed-off-by: Grygorii Strashko 
Reviewed-by: Stefano Stabellini 

---

(no changes since v7)

Changes in v7:
- sort headers in scmi-smc.c file

Changes in v6:
- add R-b tag

 xen/arch/arm/firmware/Kconfig                | 13 ++-
 xen/arch/arm/firmware/scmi-smc.c             | 93 +++++++++++---------
 xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 ---------
 xen/arch/arm/vsmc.c                          |  3 +-
 xen/include/public/arch-arm.h                |  1 +
 5 files changed, 64 insertions(+), 87 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index fc7918c7fc..bbf88fbb9a 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -8,9 +8,18 @@ config ARM_SCI
=20
 menu "Firmware Drivers"
=20
+choice
+	prompt "ARM SCI driver type"
+	default SCMI_SMC
+	help
+	Choose which ARM SCI driver to enable.
+
+config ARM_SCI_NONE
+	bool "none"
+
 config SCMI_SMC
 	bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
-	default y
+	select ARM_SCI
 	help
 	  This option enables basic awareness for SCMI calls using SMC as
 	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
@@ -18,4 +27,6 @@ config SCMI_SMC
 	  firmware node is used to trap and forward corresponding SCMI SMCs
 	  to firmware running at EL3, for calls coming from the hardware domain.
=20
+endchoice
+
 endmenu
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-=
smc.c
index 33473c04b1..4c5df714c2 100644
--- a/xen/arch/arm/firmware/scmi-smc.c
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -16,12 +16,12 @@
 #include 
 #include 
=20
+#include 
+#include 
 #include 
-#include 
=20
 #define SCMI_SMC_ID_PROP   "arm,smc-id"
=20
-static bool __ro_after_init scmi_enabled;
 static uint32_t __ro_after_init scmi_smc_id;
=20
 /*
@@ -41,14 +41,11 @@ static bool scmi_is_valid_smc_id(uint32_t fid)
  *
  * Returns true if SMC was handled (regardless of response), false otherwi=
se.
  */
-bool scmi_handle_smc(struct cpu_user_regs *regs)
+static bool scmi_handle_smc(struct cpu_user_regs *regs)
 {
     uint32_t fid =3D (uint32_t)get_user_reg(regs, 0);
     struct arm_smccc_res res;
=20
-    if ( !scmi_enabled )
-        return false;
-
     if ( !scmi_is_valid_smc_id(fid) )
         return false;
=20
@@ -78,49 +75,45 @@ bool scmi_handle_smc(struct cpu_user_regs *regs)
     return true;
 }
=20
-static int __init scmi_check_smccc_ver(void)
+static int scmi_smc_domain_init(struct domain *d,
+                                struct xen_domctl_createdomain *config)
 {
-    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
-    {
-        printk(XENLOG_WARNING
-               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled=
\n");
-        return -ENOSYS;
-    }
+    if ( !is_hardware_domain(d) )
+        return 0;
=20
+    d->arch.sci_enabled =3D true;
+    printk(XENLOG_DEBUG "SCMI: %pd init\n", d);
     return 0;
 }
=20
-static int __init scmi_dt_init_smccc(void)
+static void scmi_smc_domain_destroy(struct domain *d)
 {
-    static const struct dt_device_match scmi_ids[] __initconst =3D
-    {
-        /* We only support "arm,scmi-smc" binding for now */
-        DT_MATCH_COMPATIBLE("arm,scmi-smc"),
-        { /* sentinel */ },
-    };
-    const struct dt_device_node *scmi_node;
-    int ret;
+    if ( !is_hardware_domain(d) )
+        return;
=20
-    /* If no SCMI firmware node found, fail silently as it's not mandatory=
 */
-    scmi_node =3D dt_find_matching_node(NULL, scmi_ids);
-    if ( !scmi_node )
-        return -EOPNOTSUPP;
+    printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d);
+}
=20
-    ret =3D dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id=
);
-    if ( !ret )
+static int __init scmi_check_smccc_ver(void)
+{
+    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
     {
-        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod=
e\n",
-               SCMI_SMC_ID_PROP, scmi_node->full_name);
-        return -ENOENT;
+        printk(XENLOG_WARNING
+               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled=
\n");
+        return -ENOSYS;
     }
=20
-    scmi_enabled =3D true;
-
     return 0;
 }
=20
+static const struct sci_mediator_ops scmi_smc_ops =3D {
+    .handle_call =3D scmi_handle_smc,
+    .domain_init =3D scmi_smc_domain_init,
+    .domain_destroy =3D scmi_smc_domain_destroy,
+};
+
 /* Initialize the SCMI layer based on SMCs and Device-tree */
-static int __init scmi_init(void)
+static int __init scmi_dom0_init(struct dt_device_node *dev, const void *d=
ata)
 {
     int ret;
=20
@@ -134,22 +127,36 @@ static int __init scmi_init(void)
     if ( ret )
         return ret;
=20
-    ret =3D scmi_dt_init_smccc();
-    if ( ret =3D=3D -EOPNOTSUPP )
-        return ret;
+    ret =3D dt_property_read_u32(dev, SCMI_SMC_ID_PROP, &scmi_smc_id);
+    if ( !ret )
+    {
+        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod=
e\n",
+               SCMI_SMC_ID_PROP, dt_node_full_name(dev));
+        return -ENOENT;
+    }
+
+    ret =3D sci_register(&scmi_smc_ops);
     if ( ret )
-        goto err;
+    {
+        printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\=
n",
+               ret);
+        return ret;
+    }
=20
     printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id);
=20
     return 0;
-
- err:
-    printk(XENLOG_ERR "SCMI: Initialization failed (ret =3D %d)\n", ret);
-    return ret;
 }
=20
-__initcall(scmi_init);
+static const struct dt_device_match scmi_smc_match[] __initconst =3D {
+    DT_MATCH_COMPATIBLE("arm,scmi-smc"),
+    { /* sentinel */ },
+};
+
+DT_DEVICE_START(scmi_smc, "SCMI SMC DOM0", DEVICE_FIRMWARE)
+    .dt_match =3D scmi_smc_match,
+    .init =3D scmi_dom0_init,
+DT_DEVICE_END
=20
 /*
  * Local variables:
diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/in=
clude/asm/firmware/scmi-smc.h
deleted file mode 100644
index 6b1a164a40..0000000000
--- a/xen/arch/arm/include/asm/firmware/scmi-smc.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * xen/arch/arm/include/asm/firmware/scmi-smc.h
- *
- * ARM System Control and Management Interface (SCMI) over SMC
- * Generic handling layer
- *
- * Andrei Cherechesu 
- * Copyright 2024 NXP
- */
-
-#ifndef __ASM_SCMI_SMC_H__
-#define __ASM_SCMI_SMC_H__
-
-#include 
-
-struct cpu_user_regs;
-
-#ifdef CONFIG_SCMI_SMC
-
-bool scmi_handle_smc(struct cpu_user_regs *regs);
-
-#else
-
-static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
-{
-    return false;
-}
-
-#endif /* CONFIG_SCMI_SMC */
-
-#endif /* __ASM_SCMI_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 4095171533..78d5bdf56f 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
=20
 /* Number of functions currently supported by Hypervisor Service. */
 #define XEN_SMCCC_FUNCTION_COUNT 3
@@ -233,7 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs)
     if ( platform_smc(regs) )
         return true;
=20
-    return (scmi_handle_smc(regs)) ? true : sci_handle_call(regs);
+    return sci_handle_call(regs);
 }
=20
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e7a17ede3e..b31324f8d4 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -328,6 +328,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 #define XEN_DOMCTL_CONFIG_TEE_FFA       2
=20
 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE      0
+#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC  1
=20
 struct xen_arch_domainconfig {
     /* IN/OUT */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:21:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:21:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110288.1459593 (Exim 4.92)
	(envelope-from )
	id 1uuAqM-0006sj-Qt; Thu, 04 Sep 2025 14:21:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110288.1459593; Thu, 04 Sep 2025 14:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuAqM-0006sY-ND; Thu, 04 Sep 2025 14:21:42 +0000
Received: by outflank-mailman (input) for mailman id 1110288;
 Thu, 04 Sep 2025 14:21: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 1uuAqK-0005ts-Sg
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:21:41 +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 7867e3e3-899a-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:21:38 +0200 (CEST)
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com (2603:10a6:10:473::15)
 by GV2PR03MB8751.eurprd03.prod.outlook.com (2603:10a6:150:a8::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 14:21:29 +0000
Received: from DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40]) by DU0PR03MB8934.eurprd03.prod.outlook.com
 ([fe80::26fd:98f2:a1cc:be40%7]) with mapi id 15.20.9052.013; Thu, 4 Sep 2025
 14:21: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: 7867e3e3-899a-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fs6TctSJkznTpWPDHPMce9dPh9CwBCgXTCTnzypmreYTlSpZRRCW13q2a8oWVrdbeeUVISOwq86dbKU12HlroATrYj6KAfbYXXjzAxaB6/y/n5qTgGCcFHnkxXpby7CQV74FEnGTj525Xu8QStsln2xSx+DDPNfKhmH6XQyryF3vbx1twAuGyrku+C9uL/Ih6dv9ulOFF6OVrV/c4NvJTs2XOgavIZuwmy2KnFMxBFOqNZXqhs91JgtrukUfl5s8IGwvnMeF2zkynmgNpC+UeXlX5Pd3M6jMfILqxUPi1knH9bfFwKF+yxwB3R/LaE+FAXYSbDdmJNyJvhgBVyFUlQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=teOFbImDoAuyxS7ou+OcBlhl+FQv/TEZwzgs8NJKvxY=;
 b=ZLC+/1eSYvE0LowxRh+jlJu/eljWa804S8jrSNaZfr45tTAYdottIdRmEXXZigDS4bR4bnayBGSt0MogCtjSCq/BNwMUXwq06FsRn5CRizlpUpNwYuGwvlJ3PUIb/3f4tJBndOWfhgFjF879gJRnum8h+50fuN6kum1y1+cgUKbDWi9oRa96xJHyrs669vYOA68TL9KL1a3T4w45kH93GpE7lomnpxqEHpdpO8Pdw+/Gd4NbksU7d/ahFya3Vy6OgFOMkTQOJ4cT6RlAK0jyitHBl0QLJF601Th6O86wousP3eyJBoURoKU/mGThSYfwrqgg1ca/H0GT36nXEADU6Q==
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=teOFbImDoAuyxS7ou+OcBlhl+FQv/TEZwzgs8NJKvxY=;
 b=N+k4/zcpKgSpQOtvI88ZiuKnCEx5SWcFr2h/9uVOyq2JldPeqDOvRVL6qLnaKaP3CX0MaJGwfd0sb09jRZ4cUtThNNUpcRcDZ8V1MM//G2JyQnsZfMD+8FUNGL0kT4/Zx5B+/cRa837/4E86UGkzNzlIyCtTMksYHz/a/v68Vvf4bfbnx8N38o3u08mswD+WJVYHIBOkBqqbOAUWLX9Zzyabgnh/b5sPnUKJOarE9cZWpWENZzK4/o2j6MasGDK88JFNLPW07dQ4eFsjMlr9lUU3Uq4c0m5GL9EFPlHjQH+b5FNQErl9oAPWwitXUf1+PahlVUqeNBAqasg024ankg==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel , Oleksii Moisieiev
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Grygorii Strashko
	
Subject: [PATCH v9 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to domain,
 single agent
Thread-Topic: [PATCH v9 3/4] xen/arm: scmi-smc: passthrough SCMI SMC to
 domain, single agent
Thread-Index: AQHcHacz/gTYQbUqxEKwBpOKNI4z1w==
Date: Thu, 4 Sep 2025 14:21:27 +0000
Message-ID:
 <15e6518d9413e073d1c6bbc33dc2bf721ddbfe00.1756995595.git.oleksii_moisieiev@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: DU0PR03MB8934:EE_|GV2PR03MB8751:EE_
x-ms-office365-filtering-correlation-id: 8cdf7f9b-e7f2-4958-ec01-08ddebbe56e1
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:
 =?iso-8859-1?Q?+wzbPiLEF67njxZqz/I9UOPfK4RghEeywa1BLIJjv4Q31yArguDTnbATy3?=
 =?iso-8859-1?Q?WBM7aSjJn5qzvin2QxKEjrGEjTc48ytd3b2mPG00wVKQ0z+KPDcusnnuBD?=
 =?iso-8859-1?Q?ki22Xq/TbweDbv3QWmBhJ+1ZWOVrxo+CMCKKIFJs7TprHd7SnmaCkbFINy?=
 =?iso-8859-1?Q?0W4kKhiOr+mWMjM5VvceMnDd8syJ9JzBxIN55Gjkn0uONWcs21ybfz0ovY?=
 =?iso-8859-1?Q?/zpZMQFjJZs4WVacCV8TDnlQKFr73NwB69UeGfGs8Y+N1G+B6wNpJVXPdF?=
 =?iso-8859-1?Q?u6nmn3KDpkuqB8ZGl8C0E4+MmwZm6CQH4otQ3P6FrH5+bB1CM47DCIUhRW?=
 =?iso-8859-1?Q?/ZxNdv+KxYUURAM9l1aBPEyW4wKZIFbRF6+Xx5+hHnRZrLzU9B45eBPgLi?=
 =?iso-8859-1?Q?rEfszJjgQ7vbqFd0LMG+dRGqHfsOaH3PpjbpS/+Xv5bgGVjWWQq0Y0yMjA?=
 =?iso-8859-1?Q?ryZVInam3uu0HpS6ycFNpgti8EP0X+4IO4kxHFEbyQzwrDiz/lmjpszbQB?=
 =?iso-8859-1?Q?VZKkXpckzRWETw6uPfWPBbMJvF+5G829i/Vt++0hPjd4UHHaQ4boim29FS?=
 =?iso-8859-1?Q?lIrxcdCpCcTs0z6L4ZwqtaIjLtILZZKhEQeyz9+nsokGqfHSs14eY6hsnd?=
 =?iso-8859-1?Q?E8StlKgBYPz9D2yFzgF3b+4bt5JIwoUrUkEvjiF1HoBlv6owcCDZFjGd/2?=
 =?iso-8859-1?Q?8C1wE26Uk7WqArfk000UqEPXhawG7kSGN32Be7VF2aDByIKV0uz2Jxe+w5?=
 =?iso-8859-1?Q?Edq7Pyj0gp3zBajiqn69zvWReJyYCIhW/ZFrUtBIS5yTDKvJWM6ynatvSu?=
 =?iso-8859-1?Q?OP73W2tHyQnkB8F4KKv2hTJAvOfGTJ1w+mZh17g6cSlyTDBE6XnZnky4ee?=
 =?iso-8859-1?Q?nlGzJlREh9cfXWgBbp3PbGncjbJt1mnhsxtrQjpz1CuLXpSwT0SPSkOYdw?=
 =?iso-8859-1?Q?XF2j29fhW+y3kHoakqJ9DOjtoMQE1BderVVqYvYbVabjrO5nN3ZQzP29gD?=
 =?iso-8859-1?Q?Wr6/TiCjr0pIDwU3MCeD5zign6y0KlosufGK9e1e0fCoDc4R1l9/3qwQ6C?=
 =?iso-8859-1?Q?n21Y8OpyBZZf0uUkJQM4xuvgEM8okk79giB9QHqVXizBFoyC2vBFx/c88z?=
 =?iso-8859-1?Q?qHFLiS4LPLrLmGGX0eur+YE7lmtoXl6eXIiEW2u5gNbufocyB3oEkT+qH1?=
 =?iso-8859-1?Q?KfYuHpFUhLL7CvlYkUtjgnAkP76WOMLLh+CsIMy5sKbEaTpUC8vKbUuclD?=
 =?iso-8859-1?Q?9QNO16hJ754RDmuwoG93XY5r69yCJfEQlUNCZk0hPkfrnDUJ+86G5/KR3B?=
 =?iso-8859-1?Q?FeXQmdA+FtncZ2PMsttIcWswWaBgr1MCK1WgNqnVLI8VG0qgpNzk4sPSyh?=
 =?iso-8859-1?Q?qPzDY9FVPG5lIjXq6X6/3DpO8my2dyAh16tlKKPY8w3thsQPJClKhDi2Bj?=
 =?iso-8859-1?Q?8tr1/ZgyzpvzveivItWAGoQmK8ZQHao76Hf+cCSZ5TM2X3EoHaBj+YnPEr?=
 =?iso-8859-1?Q?+MrV3Z3uhNCUI/fHJhbxQ0m1fhtLGolwzMrzNxm+f0Zw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB8934.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:
 =?iso-8859-1?Q?5n/djyPEJ/iTKUYW8HwBZEOVHDiLSOvGypj8r6biHO4Zw/AS6595JFh98v?=
 =?iso-8859-1?Q?owkXN4oOHb3EUVAMG9avAZt0MmmUDobVQte0BMMpTFiDf3TM1IbaWzczIh?=
 =?iso-8859-1?Q?oYTLjQ8bgo1h2ly/9yalOdXi1Ql5OqaT635viWndOZ6rEM1snrrWPYswZS?=
 =?iso-8859-1?Q?0hEuy+KVO5c2omGGsdHv84/Bbh/MdmsnRW59UQJAV9NCcFmwe7dksHkJ9g?=
 =?iso-8859-1?Q?tqWCWEpnJ6aKjYCtrwXrz1TbM79IDA1sNs3icxbRHZpobpYRkXs/tovpWq?=
 =?iso-8859-1?Q?HXLY2m3bQgLE3gMu/IpBNNkX/CiQXbD6jpf2U1JJ46ww+VxDouKjjXRynm?=
 =?iso-8859-1?Q?joDrIAZzoZgnvimf3DX/z1ayy19wAoE3sUxGxZt7YOkb2JYRbthVKYNfFh?=
 =?iso-8859-1?Q?hMELwel2yg73renlaOJignpIeGD4LW0kqKidkuOyYXSIyWoIb62xaNFpwq?=
 =?iso-8859-1?Q?yJVAaWbiwQeCsCNoB6T3khd3LS3r34t0WoSCc8jFImF79cxR9epCaYcFYe?=
 =?iso-8859-1?Q?L5x6efuU8L/jtiwf8r0xc4FX4x6LmQm0bzLU9iUz9J5zWQ/IJI8BrAoe6F?=
 =?iso-8859-1?Q?hTNSssYDrs1r8FICnL8aVYi9hgd3DwF2fom/O1b/WohFamK9kK0NoeVOiB?=
 =?iso-8859-1?Q?sXf3VQsGPRFONhyVpsjzxVoSONelPgUy55/wfj2zAoX++X9coISq/sXWKM?=
 =?iso-8859-1?Q?PqmQait0CA91GgZwk/BL5AxotQ9y7C7brsHhaHGwLjQT9Gnorz1M0phbIT?=
 =?iso-8859-1?Q?1fnUYzgxN1gL8KuLOkWnxPyUnw1niPyt1dwathWudFP+NoZgPH9v7ltCiW?=
 =?iso-8859-1?Q?GyhaLJ1AfNRCn5Lf0hRNhzJ0Rc+nOQZ4olELJP3VY1YUV87Vdq20cINi+m?=
 =?iso-8859-1?Q?VhqresDP6Z6nj6qtYk0R5dfiK9wMDW7ahQSiEyREtez1EL1roBlLznHTAR?=
 =?iso-8859-1?Q?uj2gkvGo1h4m5kTOMZtd7rC1AvXHCSwL6XxtQPavLzsKU2aVv9YRCUjygw?=
 =?iso-8859-1?Q?w8Zk03AWopzlhjmBge92wO4cj6r4k754YcnkxBVLRhAeWhPvPaYaeoX1DO?=
 =?iso-8859-1?Q?szBfoXUr4C49D83r1pGHla+/uO5NwvHvTjsWtIHjw0uFnO8iCWpYjASSk6?=
 =?iso-8859-1?Q?KlCMvAdyp1Tm8Qy508J0Jj05rMTz73WXI4lBPQ/K67ydXJC616zDsDLkSC?=
 =?iso-8859-1?Q?YPrEz5IFF+XLdiJ6ApKvg0Pq4qLfQ5NYAViIERdryJPtUMAjJljpSyRGao?=
 =?iso-8859-1?Q?bIpIpufz92tqZdI2EhqKwyS4fkw9NYpk5OZuK/XMdu+00uEq3tkFKhjVr3?=
 =?iso-8859-1?Q?t/NdfHMiFbgM+nfHxViPxh61M7o5FUmTU1Ascw7IZLhBUAiKeKPllqSAs4?=
 =?iso-8859-1?Q?T+kPtJCHbT0BlzMmlgM6cT6jqBUQPo/9qzPxUnFkAEGJQedDIlWEU8hThZ?=
 =?iso-8859-1?Q?QVz/p8ZOygOvwHwHyXWBB/cLN+03aGrh2TiFTg2YXZ/N66J3nZXyogx1gH?=
 =?iso-8859-1?Q?cs0immE3eGfopomBk/Q8BwnJI64HDnoHkiDLVyUPmHpCRpgSkHZBJqEPUO?=
 =?iso-8859-1?Q?4j/ewe8cbY5W8JdoiAKIXGiE/zmMe+mJZRB/l80IRKRfTm/PvepThFWm77?=
 =?iso-8859-1?Q?YLN+ylTZMj7/oGrBOBkoUFJTz/FyiLQUva35UM5tXbdi9ktcr2FCBtnA?=
 =?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: DU0PR03MB8934.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8cdf7f9b-e7f2-4958-ec01-08ddebbe56e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 14:21:27.9229
 (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: fkuJ7hfu6jhzbGeS23n1fsgrhLnJMAuA7t6hxzYsZyDiF+1Nk+N9QjDv6IMbiYrN32Y93rcbeK/JL6m2rkV1eZVEUu1a8DFTf45ytk7F+xo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8751

From: Grygorii Strashko 

The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls
handling layer") introduces simple driver which forwards SCMI over SMC
calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent
support. While it is working gracefully for hwdom/dom0 use case it doesn't
cover "thin Dom0 with guest domain, which serves as Driver domain"
use-case. In this case HW need to be enable in Driver domain and dom0 is
performing only control functions.

The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is
pretty generic case for the default vendors SDK and new platforms.

This patch enables passthrough of SCMI SMC single agent interface to the
one guest domain serving as Driver domain.

Configure Dom0 to enable SCMI passthrough:

 - dom0: add scmi-smc-passthrough to the Xen Command Line

Enabled SCMI passthrough for guest using toolstack in the following way:

 - domD: xl.cfg add "arm_sci" option as below

   arm_sci =3D "type=3Dscmi_smc"

 - domD: xl.cfg enable access to the "arm,scmi-shmem"

iomem =3D [
    "47ff0,1@22001",
]

 - domD: add SCMI nodes to the Driver domain partial device tree as in the
 below example:

passthrough {
   scmi_shm_0: sram@22001000 {
       compatible =3D "arm,scmi-shmem";
       reg =3D <0x0 0x22001000 0x0 0x1000>;
   };

   firmware {
        compatible =3D "simple-bus";
            scmi: scmi {
                compatible =3D "arm,scmi-smc";
                shmem =3D <&scmi_shm_0>;
                ...
            }
    }
}

dom0less case configuration:

- add "xen,sci_type" property for required DomU ("xen,domain") node

   xen,sci_type=3D"scmi_smc"

- add scmi nodes to the Driver domain partial device tree the same way
as above and enable access to the "arm,scmi-shmem" according to
dom0less documentation. For example:

  scmi_shm_0: sram@22001000 {
        compatible =3D "arm,scmi-shmem";
        reg =3D <0x00 0x22001000 0x00 0x1000>;
->        xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
->        xen,force-assign-without-iommu;
  };

The SCMI SMC single agent interface can be enabled for one and only one
domain. In general, the configuration is similar to any other HW
passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option.

Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from
dom0/hwdom DT when "scmi-smc-passthrough" cmdline parameter was provided.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Oleksii Moisieiev 
Acked-by: Anthony PERARD  # tools
---

Changes in v9:
- update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule

Changes in v8:
- reneregated {helpers/types}.gen.go, dropped unneeded parameters

Changes in v7:
- Fix commit description.
- Move scmi-smc-passthrough definition to match alphaberical order
- remove unneeded initialization with NULL
- changed u64 to uint64_t
- Send warning if iomem permit access was failed

Changes in v6:
- added generated helpers and types go files
- rename cmdline parameter to scmi-smc-passthrough
- fix goto tag in parse_arm_sci_config

Changes in v5:
- rename dom0_scmi_smc_passthrough to scmi_smc_passthrough

Changes in v4:
- xl.cfg doc
- fix comments from Stefano Stabellini
- fix toolstack code as sugested by Anthony PERARD
  - use MATCH_OPTION()
  - move arm_sci struct and cfg params in "arch_arm"
- add SCMI passthrough for dom0less case

 docs/man/xl.cfg.5.pod.in              |  34 ++++++++
 docs/misc/arm/device-tree/booting.txt |  15 ++++
 docs/misc/xen-command-line.pandoc     |   9 ++
 tools/golang/xenlight/helpers.gen.go  |  35 ++++++++
 tools/golang/xenlight/types.gen.go    |  11 +++
 tools/include/libxl.h                 |   5 ++
 tools/libs/light/libxl_arm.c          |  14 ++++
 tools/libs/light/libxl_types.idl      |  10 +++
 tools/xl/xl_parse.c                   |  36 ++++++++
 xen/arch/arm/dom0less-build.c         |  34 +++++++-
 xen/arch/arm/firmware/Kconfig         |   4 +-
 xen/arch/arm/firmware/scmi-smc.c      | 115 +++++++++++++++++++++++++-
 12 files changed, 317 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index acff45d308..3b18bcc095 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3123,6 +3123,40 @@ writes will be ignored.
=20
 This option is only implemented for Arm where the default is enabled.
=20
+=3Ditem B
+
+Set ARM_SCI specific options for the guest. ARM SCI is System
+Control Protocol allows domain to manage various functions that are provid=
ed
+by HW platform firmware.
+
+B is a comma separated list of C settings,
+from the following list:
+
+=3Dover 4
+
+=3Ditem B
+
+Specifies an ARM SCI type for the guest.
+
+=3Dover 4
+
+=3Ditem B
+
+Don't allow guest to use ARM SCI if present on the platform. This is the
+default value.
+
+=3Ditem B
+
+Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC calls
+forwarding from domain to the EL3 firmware (like Trusted Firmware-A) with =
a
+single SCMI OSPM agent support.
+Should be used together with B Xen command line
+option.
+
+=3Dback
+
+=3Dback
+
 =3Dback
=20
 =3Dhead3 x86
diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t=
ree/booting.txt
index 07acc7ba64..977b428608 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -307,6 +307,21 @@ with the following properties:
     passed through. This option is the default if this property is missing
     and the user does not provide the device partial device tree for the d=
omain.
=20
+- xen,sci_type
+
+    A string property specifying an ARM SCI type for the guest.
+
+    - "none"
+    Don't allow guest to use ARM SCI if present on the platform. This is t=
he
+    default value.
+
+    - "scmi_smc"
+    Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC c=
alls
+    forwarding from domain to the EL3 firmware (like Trusted Firmware-A) w=
ith a
+    single SCMI OSPM agent support.
+    Should be used together with scmi-smc-passthrough Xen command line
+    option.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
=20
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line=
.pandoc
index 4adcd7e762..518e42d965 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2382,6 +2382,15 @@ sockets, &c.  This will reduce performance somewhat,=
 particularly on
 systems with hyperthreading enabled, but should reduce power by
 enabling more sockets and cores to go into deeper sleep states.
=20
+### scmi-smc-passthrough (ARM)
+> `=3D `
+
+The option is available when `CONFIG_SCMI_SMC` is compiled in, and allows =
to
+enable SCMI SMC single agent interface for any, but only one guest domain,
+which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom an=
d
+SCMI nodes removed from Dom0/hwdom device tree.
+(for example, thin Dom0 with Driver domain use-case).
+
 ### scrub-domheap
 > `=3D `
=20
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/h=
elpers.gen.go
index 667030cbd7..8909fe8a1b 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -938,6 +938,35 @@ return fmt.Errorf("converting field Vcpus: %v", err)
  return nil
  }
=20
+// NewArmSci returns an instance of ArmSci initialized with defaults.
+func NewArmSci() (*ArmSci, error) {
+var (
+x ArmSci
+xc C.libxl_arm_sci)
+
+C.libxl_arm_sci_init(&xc)
+defer C.libxl_arm_sci_dispose(&xc)
+
+if err :=3D x.fromC(&xc); err !=3D nil {
+return nil, err }
+
+return &x, nil}
+
+func (x *ArmSci) fromC(xc *C.libxl_arm_sci) error {
+ x.Type =3D ArmSciType(xc._type)
+
+ return nil}
+
+func (x *ArmSci) toC(xc *C.libxl_arm_sci) (err error){defer func(){
+if err !=3D nil{
+C.libxl_arm_sci_dispose(xc)}
+}()
+
+xc._type =3D C.libxl_arm_sci_type(x.Type)
+
+ return nil
+ }
+
 // NewRdmReserve returns an instance of RdmReserve initialized with defaul=
ts.
 func NewRdmReserve() (*RdmReserve, error) {
 var (
@@ -1163,6 +1192,9 @@ x.ArchArm.GicVersion =3D GicVersion(xc.arch_arm.gic_v=
ersion)
 x.ArchArm.Vuart =3D VuartType(xc.arch_arm.vuart)
 x.ArchArm.SveVl =3D SveType(xc.arch_arm.sve_vl)
 x.ArchArm.NrSpis =3D uint32(xc.arch_arm.nr_spis)
+if err :=3D x.ArchArm.ArmSci.fromC(&xc.arch_arm.arm_sci);err !=3D nil {
+return fmt.Errorf("converting field ArchArm.ArmSci: %v", err)
+}
 if err :=3D x.ArchX86.MsrRelaxed.fromC(&xc.arch_x86.msr_relaxed);err !=3D =
nil {
 return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err)
 }
@@ -1699,6 +1731,9 @@ xc.arch_arm.gic_version =3D C.libxl_gic_version(x.Arc=
hArm.GicVersion)
 xc.arch_arm.vuart =3D C.libxl_vuart_type(x.ArchArm.Vuart)
 xc.arch_arm.sve_vl =3D C.libxl_sve_type(x.ArchArm.SveVl)
 xc.arch_arm.nr_spis =3D C.uint32_t(x.ArchArm.NrSpis)
+if err :=3D x.ArchArm.ArmSci.toC(&xc.arch_arm.arm_sci); err !=3D nil {
+return fmt.Errorf("converting field ArchArm.ArmSci: %v", err)
+}
 if err :=3D x.ArchX86.MsrRelaxed.toC(&xc.arch_x86.msr_relaxed); err !=3D n=
il {
 return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err)
 }
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/typ=
es.gen.go
index e26b3cdfc7..ab9d4ca7b4 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -520,6 +520,16 @@ SveType1920 SveType =3D 1920
 SveType2048 SveType =3D 2048
 )
=20
+type ArmSciType int
+const(
+ArmSciTypeNone ArmSciType =3D 0
+ArmSciTypeScmiSmc ArmSciType =3D 1
+)
+
+type ArmSci struct {
+Type ArmSciType
+}
+
 type RdmReserve struct {
 Strategy RdmReserveStrategy
 Policy RdmReservePolicy
@@ -599,6 +609,7 @@ GicVersion GicVersion
 Vuart VuartType
 SveVl SveType
 NrSpis uint32
+ArmSci ArmSci
 }
 ArchX86 struct {
 MsrRelaxed Defbool
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 185f74d8a8..bc35e412da 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -313,6 +313,11 @@
  */
 #define LIBXL_HAVE_BUILDINFO_ARCH_NR_SPIS 1
=20
+/*
+ * libxl_domain_build_info has the arch_arm.sci* fields.
+ */
+#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 1
+
 /*
  * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing
  * 'soft reset' for domains and there is 'soft_reset' shutdown reason
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 4a19a8d22b..7e9f8a1bc3 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,6 +233,20 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl =3D d_config->b_info.arch_arm.sve_vl / 128U;
     }
=20
+    switch (d_config->b_info.arch_arm.arm_sci.type) {
+    case LIBXL_ARM_SCI_TYPE_NONE:
+        config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+        break;
+    case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
+        config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
+        break;
+    default:
+        LOG(ERROR, "Unknown ARM_SCI type %d",
+            d_config->b_info.arch_arm.arm_sci.type);
+        return ERROR_FAIL;
+    }
+    LOG(DEBUG, " - SCI type=3D%u", config->arch.arm_sci_type);
+
     return 0;
 }
=20
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type=
s.idl
index a6030a2dbd..b53e013a44 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -551,6 +551,15 @@ libxl_sve_type =3D Enumeration("sve_type", [
     (2048, "2048")
     ], init_val =3D "LIBXL_SVE_TYPE_DISABLED")
=20
+libxl_arm_sci_type =3D Enumeration("arm_sci_type", [
+    (0, "none"),
+    (1, "scmi_smc")
+    ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE")
+
+libxl_arm_sci =3D Struct("arm_sci", [
+    ("type", libxl_arm_sci_type),
+    ])
+
 libxl_rdm_reserve =3D Struct("rdm_reserve", [
     ("strategy",    libxl_rdm_reserve_strategy),
     ("policy",      libxl_rdm_reserve_policy),
@@ -725,6 +734,7 @@ libxl_domain_build_info =3D Struct("domain_build_info",=
[
                                ("vuart", libxl_vuart_type),
                                ("sve_vl", libxl_sve_type),
                                ("nr_spis", uint32, {'init_val': 'LIBXL_NR_=
SPIS_DEFAULT'}),
+                               ("arm_sci", libxl_arm_sci),
                               ])),
     ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
                               ])),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 90c9386f5b..af86d3186d 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1284,6 +1284,36 @@ out:
     if (rc) exit(EXIT_FAILURE);
 }
=20
+static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
+                                const char *str)
+{
+    int ret =3D 0;
+    char *buf2, *ptr;
+    char *oparg;
+
+    if (NULL =3D=3D (buf2 =3D ptr =3D strdup(str)))
+        return ERROR_NOMEM;
+
+    ptr =3D strtok(buf2, ",");
+    while (ptr !=3D NULL)
+    {
+        if (MATCH_OPTION("type", ptr, oparg)) {
+            ret =3D libxl_arm_sci_type_from_string(oparg, &arm_sci->type);
+            if (ret) {
+                fprintf(stderr, "Unknown ARM_SCI type: %s\n", oparg);
+                ret =3D ERROR_INVAL;
+                goto out;
+            }
+        }
+
+        ptr =3D strtok(NULL, ",");
+    }
+
+out:
+    free(buf2);
+    return ret;
+}
+
 void parse_config_data(const char *config_source,
                        const char *config_data,
                        int config_len,
@@ -2989,6 +3019,12 @@ skip_usbdev:
     xlu_cfg_get_defbool(config, "trap_unmapped_accesses",
                         &b_info->trap_unmapped_accesses, 0);
=20
+    if (!xlu_cfg_get_string(config, "arm_sci", &buf, 1)) {
+        if (parse_arm_sci_config(config, &b_info->arch_arm.arm_sci, buf)) =
{
+            exit(EXIT_FAILURE);
+        }
+    }
+
     parse_vkb_list(config, d_config);
=20
     d_config->virtios =3D NULL;
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 0094cf9e40..f00912a1ca 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -279,6 +279,36 @@ int __init arch_handle_passthrough_prop(struct kernel_=
info *kinfo,
     return sci_assign_dt_device(kinfo->bd.d, node);
 }
=20
+static int __init domu_dt_sci_parse(struct dt_device_node *node,
+                                    struct xen_domctl_createdomain *d_cfg)
+{
+    const char *sci_type;
+    int ret;
+
+    d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+
+    if ( !IS_ENABLED(CONFIG_ARM_SCI) ||
+         !dt_property_read_bool(node, "xen,sci_type") )
+        return 0;
+
+    ret =3D dt_property_read_string(node, "xen,sci_type", &sci_type);
+    if ( ret )
+        return ret;
+
+    if ( !strcmp(sci_type, "none") )
+        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
+    {
+        printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"=
,
+               sci_type, dt_node_name(node));
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
 int __init arch_parse_dom0less_node(struct dt_device_node *node,
                                     struct boot_domain *bd)
 {
@@ -288,7 +318,9 @@ int __init arch_parse_dom0less_node(struct dt_device_no=
de *node,
=20
     d_cfg->arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
     d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;
-    d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+
+    if ( domu_dt_sci_parse(node, d_cfg) )
+        panic("Error getting SCI configuration\n");
=20
     if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) )
     {
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index bbf88fbb9a..5c5f0880c4 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -25,7 +25,9 @@ config SCMI_SMC
 	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
 	  compatible only). The value of "arm,smc-id" DT property from SCMI
 	  firmware node is used to trap and forward corresponding SCMI SMCs
-	  to firmware running at EL3, for calls coming from the hardware domain.
+	  to firmware running at EL3, for calls coming from the hardware domain o=
r
+	  driver domain.
+	  Use with EL3 firmware which supports only single SCMI OSPM agent.
=20
 endchoice
=20
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-=
smc.c
index 4c5df714c2..0835ddeeec 100644
--- a/xen/arch/arm/firmware/scmi-smc.c
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
=20
@@ -22,7 +24,11 @@
=20
 #define SCMI_SMC_ID_PROP   "arm,smc-id"
=20
+static bool __ro_after_init opt_scmi_smc_passthrough;
+boolean_param("scmi-smc-passthrough", opt_scmi_smc_passthrough);
+
 static uint32_t __ro_after_init scmi_smc_id;
+static struct domain __read_mostly *scmi_dom;
=20
 /*
  * Check if provided SMC Function Identifier matches the one known by the =
SCMI
@@ -50,7 +56,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
         return false;
=20
     /* Only the hardware domain should use SCMI calls */
-    if ( !is_hardware_domain(current->domain) )
+    if ( scmi_dom !=3D current->domain )
     {
         gdprintk(XENLOG_WARNING, "SCMI: Unprivileged access attempt\n");
         return false;
@@ -75,12 +81,45 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
     return true;
 }
=20
+static int
+scmi_smc_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=
 )
+        return -EINVAL;
+
+    return 0;
+}
+
 static int scmi_smc_domain_init(struct domain *d,
                                 struct xen_domctl_createdomain *config)
 {
-    if ( !is_hardware_domain(d) )
+    /*
+     * scmi_passthrough is not enabled:
+     * - proceed only for hw_domain
+     * - fail if guest domain has SCMI enabled.
+     */
+    if ( !opt_scmi_smc_passthrough && !is_hardware_domain(d) )
+    {
+        if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_SC=
MI_SMC )
+            return -EINVAL;
+        else
+            return 0;
+    }
+    /*
+     * scmi_passthrough is enabled:
+     * - ignore hw_domain
+     * - proceed only for domain with SCMI enabled.
+     */
+    if ( opt_scmi_smc_passthrough &&
+         (config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE =
||
+          is_hardware_domain(d)) )
         return 0;
=20
+    if ( scmi_dom )
+        return -EEXIST;
+
+    scmi_dom =3D d;
     d->arch.sci_enabled =3D true;
     printk(XENLOG_DEBUG "SCMI: %pd init\n", d);
     return 0;
@@ -88,12 +127,80 @@ static int scmi_smc_domain_init(struct domain *d,
=20
 static void scmi_smc_domain_destroy(struct domain *d)
 {
-    if ( !is_hardware_domain(d) )
+    if ( scmi_dom && scmi_dom !=3D d )
         return;
=20
+    scmi_dom =3D NULL;
+    d->arch.sci_enabled =3D false;
     printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d);
 }
=20
+/*
+ * Handle Dom0 SCMI SMC specific DT nodes
+ *
+ * if scmi_smc_passthrough=3Dfalse:
+ * - Copy SCMI nodes into Dom0 device tree.
+ * if scmi_smc_passthrough=3Dtrue:
+ * - skip SCMI nodes from Dom0 DT
+ * - give dom0 control access to SCMI shmem MMIO, so SCMI can be passed
+ *   through to guest.
+ */
+static bool scmi_smc_dt_handle_node(struct domain *d,
+                                    struct dt_device_node *node)
+{
+    static const struct dt_device_match shmem_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 */ },
+    };
+
+    /* skip scmi shmem node for dom0 if scmi not enabled */
+    if ( dt_match_node(shmem_matches, node) && !sci_domain_is_enabled(d) )
+    {
+        dt_dprintk("Skip scmi shmem node\n");
+        return true;
+    }
+
+    /*
+     * skip scmi node for dom0 if scmi not enabled, but give dom0 control
+     * access to SCMI shmem
+     */
+    if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) )
+    {
+        struct dt_device_node *shmem_node;
+        const __be32 *prop;
+        uint64_t paddr, size;
+        int ret;
+
+        /* give dom0 control access to SCMI shmem */
+        prop =3D dt_get_property(node, "shmem", NULL);
+        if ( !prop )
+            return true;
+
+        shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop));
+        if ( !shmem_node )
+            return true;
+
+        ret =3D dt_device_get_address(shmem_node, 0, &paddr, &size);
+        if ( ret )
+            return true;
+
+        ret =3D iomem_permit_access(d, paddr_to_pfn(paddr),
+                                  paddr_to_pfn(paddr + size - 1));
+        if ( ret )
+            printk(XENLOG_WARNING
+                     "SCMI: Failed to give access to SCMI shmem with code:=
 %d\n", ret);
+
+        dt_dprintk("Skip scmi node\n");
+        return true;
+    }
+
+    return false;
+}
+
 static int __init scmi_check_smccc_ver(void)
 {
     if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
@@ -108,8 +215,10 @@ static int __init scmi_check_smccc_ver(void)
=20
 static const struct sci_mediator_ops scmi_smc_ops =3D {
     .handle_call =3D scmi_handle_smc,
+    .domain_sanitise_config =3D scmi_smc_domain_sanitise_config,
     .domain_init =3D scmi_smc_domain_init,
     .domain_destroy =3D scmi_smc_domain_destroy,
+    .dom0_dt_handle_node =3D scmi_smc_dt_handle_node,
 };
=20
 /* Initialize the SCMI layer based on SMCs and Device-tree */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:27:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:27:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110336.1459604 (Exim 4.92)
	(envelope-from )
	id 1uuAw5-0000GP-I6; Thu, 04 Sep 2025 14:27:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110336.1459604; Thu, 04 Sep 2025 14:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuAw5-0000GI-EL; Thu, 04 Sep 2025 14:27:37 +0000
Received: by outflank-mailman (input) for mailman id 1110336;
 Thu, 04 Sep 2025 14:27: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 1uuAw3-0000GC-MZ
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:27:35 +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 4a6ed29c-899b-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:27:32 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 6B31FEC0275;
 Thu,  4 Sep 2025 10:27:30 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Thu, 04 Sep 2025 10:27:30 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 4 Sep 2025 10:27: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: 4a6ed29c-899b-11f0-9809-7dc792cee155
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=1756996050;
	 x=1757082450; bh=0PF0/TWTKN6ReBqUEasJOa3agjL3JFjZ5ey/uYSth8Q=; b=
	CMtCrvoSVvyBVnKyRCtrjrjzDQpGP5T/lvkAXckgy9L9U5m9iyxS+4UD/k5xEYY+
	bCby0d/Xt0C1Gj5B4OJRHZi3H9hZA8OtVAaQlYEG468KYN4MuqkgAVpQxomUCmJx
	jlX2yybTNisvu7+xiWTDeRqUTAu/sE+TJ9O2TP23c7h+avNIGHOKOxqtI7yBnWjW
	cmaoIXfssgMl/NTraMht2VEtmITluf62Zk5VqNGmtTnHf881u6TCw43y3yADLRd+
	UOMKxyTO2y6A2HtKb11ASzcjpgTwVophNggC2ab/IT7gqYVyJyxg1v+b37gEdFEm
	2eX606CwIzL3iUrmmy29jw==
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=
	1756996050; x=1757082450; bh=0PF0/TWTKN6ReBqUEasJOa3agjL3JFjZ5ey
	/uYSth8Q=; b=OV1aL/yEydyqWw761fUOdFqGZ6Ah5G7n6Yt8h5CohpJMpZOjCQA
	Qj1Pd/BWw21ppO8TU8xP7/EcbQa1NbNbtHfrtPedgaKD3rNcyEI65lYKLWbsu2PO
	i5e/IY8PHO6obhb+AtXL+1EF8nBMYJpO0oYaHzrcadVgZCopSJuKYVPVG11NOSqZ
	1WUwcnIZRIBjahwdh6RaNe/PwVgwSx+NkshtuJIsm2V+rivg0hgPG77stFcFThKb
	8eahz3U/UlrKihqXyunA9DIstemq+6kJCz9YEiKqaVehrmpgeoNJf+VcglmHq6/4
	EXC2veK9ACC3Dp71oxXmE2K+zy+FeRu7TkQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeivdeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephfekhfelgeeu
    tdduvddtveetheetudevudelffdvhfffffehjeegleevtdeffffgnecuffhomhgrihhnpe
    hkvghrnhgvlhdrohhrghdpghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu
    rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh
    hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeekpdhmohguvgepshhmthhpohhu
    thdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtoheprg
    hnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopegrnhgu
    rhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepmhhitghhrg
    hlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdho
    rhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpth
    htohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepgigv
    nhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 4 Sep 2025 16:27:27 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor
Message-ID: 
References: <20250904114202.2722478-1-marmarek@invisiblethingslab.com>
 <488408be-4728-4666-89a5-ac5b438bdbf5@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="/LOmJVvnW0+dvPYA"
Content-Disposition: inline
In-Reply-To: <488408be-4728-4666-89a5-ac5b438bdbf5@suse.com>


--/LOmJVvnW0+dvPYA
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 4 Sep 2025 16:27:27 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor

On Thu, Sep 04, 2025 at 02:58:20PM +0200, Jan Beulich wrote:
> On 04.09.2025 13:41, Marek Marczykowski-G=C3=B3recki wrote:
> > Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> > available in earlier toolchain versions. But use it together with
> > -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> > still contains some paths in out-of-tree builds.
>=20
> I consider it wrong not to use -ffile-prefix-map when available. That
> already covers more than "debug" and "macro", and it may gain further
> functionality.

I asked about that on v1 and got ambiguous answer suggesting the opposite:
https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.=
1742317309.git-series.marmarek@invisiblethingslab.com/T/#m74a8883835e30fb74=
a85b07a7b14507ee52e7c65


> > The out of tree build requires -fdebug-prefix-map mapping for both sour=
ce
> > dir and object dir - otherwise the latter is included (2 occurrences) in
> > xen-syms.
>=20
> As indicated in a reply to Andrew on the thread hanging off of my
> patch - I think whether to remove those wants to be left to the user.
>=20
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -1,4 +1,4 @@
> > -XEN_ROOT =3D $(CURDIR)/..
> > +XEN_ROOT =3D $(realpath $(CURDIR)/..)
> > =20
> >  export PKG_CONFIG_DIR =3D $(CURDIR)/pkg-config
> > =20
> > diff --git a/tools/Rules.mk b/tools/Rules.mk
> > index 725c3c32e9a2..428fce094819 100644
> > --- a/tools/Rules.mk
> > +++ b/tools/Rules.mk
> > @@ -166,6 +166,8 @@ endif
> >  CFLAGS-$(CONFIG_X86_32) +=3D $(call cc-option,$(CC),-mno-tls-direct-se=
g-refs)
> >  CFLAGS +=3D $(CFLAGS-y)
> > =20
> > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=3D$(realpath $(XEN_R=
OOT))=3D.)
>=20
> Here and below - no need to use cc-option-add for -fdebug-prefix-map,
> which all permissible compilers support.

Ok.

> Further, again as per reply to Andrew on the thread hanging off of my
> patch - I don't view it as desirable to leave the tools/ prefix in
> place, or e.g. for libraries, the entire tools/libs// part.
> Imo every binary should have only the path (if any) from its own source
> root left. (And yes, how to deal with e.g. shared include files isn't
> quite clear to me, yet. Maybe we actually need to pass two options.)

I don't think it's valid to strip arbitrary prefixes from debug symbols,
especially in tools. This will break some automated tools that try to match
coredumps (and similar) to source code and sometimes even debug symbols
too. But even for manual usage, having to jump between directories (I'm
not sure if gdb supports multiple source dirs at once?) just because you
happen to debug a binary that use more of libraries isn't exactly
desirable.
I think the paths in debug symbols and similar should match the layout
in the source repository, not a subset of it.

Theoretically this doesn't apply to the hypervisor yet, as I'm not aware
of any tool processing xen memory dumps automatically (and those for
manual usage are quite unstable, to say the least...). But I don't think
it's an excuse to have incomplete paths in there, just to save few
bytes?
The only case where I can see it would make some sense is out of tree
build, where indeed it's about just the hypervisor, not the toolstack
(IMO due to the build system limitation, but well...). But at the same
time, having different path variant depending on it-tree/out-of-tree
build feels weird.

> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -208,7 +208,7 @@ VPATH :=3D $(srctree)
> > =20
> >  export srctree objtree VPATH
> > =20
> > -export XEN_ROOT :=3D $(abs_srctree)/..
> > +export XEN_ROOT :=3D $(patsubst %/xen,%,$(abs_srctree))
>=20
> Unlike for tools/, is this still needed here? You don't use XEN_ROOT belo=
w.

Indeed in this revision not anymore.

> > @@ -412,6 +412,10 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
> >  CFLAGS +=3D -Wa,--strip-local-absolute
> >  endif
> > =20
> > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=3D$(abs_objtree)=3D.=
/xen)
> > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=3D$(abs_srctree)=3D.=
/xen)
> > +$(call cc-option-add,CFLAGS,CC,-fmacro-prefix-map=3D$(abs_srctree)=3D.=
/xen)
>=20
> I disagree with leaving any xen/ prefix there. That's not how in-tree bui=
lds
> name files; everything there is relative to xen/.
>=20
> I also don't really see a point in using . in the substitution (similarly
> for the toolstack, but there I have less to say).
>=20
> Finally, why pass two identical, possibly long options for in-tree builds
> (where $(abs_objtree) =3D=3D $(abs_srctree))?

That can be avoided, yes.

> Below I'll reproduce my own further re-worked patch. It's not quite ready
> for v2 submission yet, I expect though. For example, the actual Kconfig
> portion is still missing. Whether the @SRC@ and @BLD@ parts actually make
> sense (or what to replace them by) I'm also unsure about. If nothing else
> they may need replacing by plain .
>=20
> Jan
>=20
> build: avoid absolute paths in executables
>=20
> For in-tree builds relative paths are used in most cases, whereas for out-
> of-tree builds in various situations absolute ones come into play. The
> extra paths can be long, wasting space and e.g. serial line bandwidth.
> They would also get in the way of location-independent reproducible
> builds. Leverage newer gcc's (and Clang's) ability to "remap" file names.
> For older gcc fall back to using the option affecting debug info only.
>=20
> For the few absolute paths appearing in in-tree builds' debug info, use
> the generally available option, conditional upon a new Kconfig control
>=20
> Signed-off-by: Jan Beulich 
> ---
> Of course we may want to consider putting this in the top-level Config.mk,
> to also affect other sub-trees (presently mainly/only affecting debug
> info, for which even gcc5 already supports -fdebug-prefix-remap=3D).
>=20
> As to a Fixes: tag, I wasn't quite sure whether to "blame" the
> introduction of out-of-tree builds.
>=20
> Note that at least in the gcc5 I'm testing with the (limited) effect is
> further undermined by the compiler emitting the specified command line
> options into debug info, thus still leaving references to the absolute
> directories in place.
>=20
> For the mentioned gcc15 issue see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D121788.
> ---
> v2: Use $(abs_srctree). Introduce DEBUG_INFO_REL_PATHS.
>=20
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -461,7 +461,21 @@ CFLAGS +=3D -flto
>  LDFLAGS-$(CONFIG_CC_IS_CLANG) +=3D -plugin LLVMgold.so
>  endif
> =20
> +CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) +=3D -fdebug-prefix-map=3D$(abs_sr=
ctree)=3D@SRC@
> +
>  ifdef building_out_of_srctree
> +    # Need to add to CFLAGS-y here, as gcc checks later options before e=
arlier
> +    # ones, and we want in particular the latter one(s) here to be check=
ed
> +    # first.
> +    CFLAGS-$(CONFIG_DEBUG_INFO_REL_PATHS) +=3D -fdebug-prefix-map=3D$(ab=
s_objtree)=3D@BLD@
> +    CFLAGS-y +=3D $(call cc-option,$(CC),-ffile-prefix-map=3D$(abs_srctr=
ee)/=3D)
> +    # While -ffile-prefix-map=3D implies -fdebug-prefix-map=3D, we need =
to use the
> +    # latter explicitly: Up to at least gcc15 the compiler specs transla=
te all
> +    # -ffile-prefix-map=3D ahead of all -fdebug-prefix-map=3D when invok=
ing the
> +    # the assembler for *.S files, thus breaking our intended ordering.
> +    # (Otherwise the option below could be passed as 3rd [fallback] argu=
ment to
> +    # cc-option above.)
> +    CFLAGS-y +=3D -fdebug-prefix-map=3D$(abs_srctree)/=3D
>      CFLAGS +=3D -I$(objtree)/include
>      CFLAGS +=3D -I$(objtree)/arch/$(SRCARCH)/include
>  endif
>=20

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

--/LOmJVvnW0+dvPYA
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi5oc8ACgkQ24/THMrX
1ywiXwf/dOuj3Ri32AYXFOP8bbsJJyHpJCvgNeCtbuJtOmKQTOjdenNzaU/rTTf+
7KCD69hXKoQAmBtOh6is1FcZXZmv+MGRPdBFgUvWi1yOaxDc/8o8/luCDE1HuveD
IGiYDPG72oLD3rfBW9LGgmLTPTm8rAvKcpdgU08RGN3dT2hhFYqI9SI6pAr4iqo6
tQGS8aqm0hZU47vGo4g/xpgs4wt9d8lvxl3ARQCt/qgXvSrdrlEESj8fjpHBtlir
+gCHTzydVtchwKFbTFh9KDTNYksv3PwtUctVgvAN8VDdVea8ds049GGSGs3KYwAI
alYd6Y6z/FMFDicPFlx+yxUar31j/A==
=oUbX
-----END PGP SIGNATURE-----

--/LOmJVvnW0+dvPYA--


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:37:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:37:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110379.1459614 (Exim 4.92)
	(envelope-from )
	id 1uuB5S-0002E5-Et; Thu, 04 Sep 2025 14:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110379.1459614; Thu, 04 Sep 2025 14: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 1uuB5S-0002Dy-A5; Thu, 04 Sep 2025 14:37:18 +0000
Received: by outflank-mailman (input) for mailman id 1110379;
 Thu, 04 Sep 2025 14: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 1uuB5R-0002Ds-HV
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:37:17 +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 a6869c4d-899c-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 16:37:15 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3dcce361897so764078f8f.3
 for ; Thu, 04 Sep 2025 07:37:15 -0700 (PDT)
Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3d7ac825b88sm14982660f8f.7.2025.09.04.07.37.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 07:37: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: a6869c4d-899c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756996634; x=1757601434; 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=iJCwKFoMwnJG5hneaGZsfWFqvLmvoxOanH68IbCRnyc=;
        b=m+G4WRzCJ/oHalyEGgtY8q9wZBm3BkebdrDMIiVduhLfMrre7221CN98pkkrOF6iMJ
         hvIN5xvflhqiPguf37KSOPW75JxGxi/p6PnTk0+4MtYHEwcKxJVUAkIOSfSiag74FfCj
         L4pv/e48Q3cRGgXAvjYcWSk/Dfr/fA3BJFfstNhHBdnktyXQPjHqpPhaq4FVYaz2nEYH
         9B8XmUd9jZBAgHFVa3AEUxzoeIiXBp18cvxQcn5Hj0ByyO7/KwSOmk91VzSBAKuDqaAb
         gbLKFdjJ0TMQCPqGgZJazGUyo4c7glAYfvdlGZ9gOi9xi0AFtD4lYfpmQo/N9Gg23e12
         tB8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756996634; x=1757601434;
        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=iJCwKFoMwnJG5hneaGZsfWFqvLmvoxOanH68IbCRnyc=;
        b=jeQVdfZ6qFMt6rOJGpHSD6DVuhpPl+hyGgqy29btPxKTC5Ku1HaJxEZwa/zrvD18n1
         b/nq6U2dnDCVGlyx768m1pbNa+abiGgqQ50SlnkEHYPr6T4jbxgPSa2juTFvCFfGXOYe
         dN1sugozy6EYf+Z4KonbQRZv3+lhKL7LApKcMpgPidhOroADlEo+Z3MK6B6hfboBXcIZ
         holvbZ0He2dn3UQbYr5TtpzCxookmGkN4dBhUgPUS8/GuzZmDCVs67kM8+fYmKA/xOoO
         sJe2jOng/Gl8Hnj27IQQ64KAKQoE7/rv5s8w5fgMFJFMThaFnG60AybauySS2/f0Odfn
         wq0g==
X-Forwarded-Encrypted: i=1; AJvYcCVTmrXt/vL0JoC0MF/MCbeLobBRssB0LYOkGQ1ZbysDl/zqqzujAmzeSRyxvH/7Pp0qH+EEmKAjHYM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcJzYSUbSB8wSupXhdTHPjRoc0/Vxc13R7I/ZlCvtLpmBHUzPz
	cWjM2RN+VmNmY48tl/nH5sxbgtbbXsA1pkfDYVf+IT7XhDX34KDUfI44
X-Gm-Gg: ASbGncsBMNjN46JJkGcWLRiH5UXT8042xaSnK+mdvnI+Pi+GyR1TLhFkcsT7m8uE1vI
	uisCrnPTOGhGfpgDau5m+Itw+aZj/2UNClqp+bJoihL+kaocAAVGFT7xdCKWVsO2P/ZzUP4AlWx
	PzreGZsbXiIi/gmkWNWX2gasWtVZPROay1F98/3BsRtMSZJJdm6Pz0EFy1wEIoZR4uJqFBem///
	FxaA3KWv9+zX+H+PyYqv5vbStNC6uhzoVhVzWTLSXTL5v4cg0JUlduy9KmdtLi+WkWdOvcGKfja
	3Qw/Kk/ODcN/GuJkrwndKYBJC+KA7fLm8p4azTk9g7EfSoS2CKL3xkMGwLzi5xdjqczoHkmpaVJ
	4BUDcG6cR31t1mWg28C9yQaBOt5+hxHyugYURun8HJ12foYDsc/D38Xq3XmOk1EFgOQ==
X-Google-Smtp-Source: AGHT+IGP9XYswsF0kuWSHdZ+9DWYj1MiK//7idoUn9FVRQaIP7QA+oT1aQxbrNKYtzFm7sM4dh395g==
X-Received: by 2002:a05:6000:2381:b0:3d7:cd09:ae1e with SMTP id ffacd0b85a97d-3d7cd09b425mr9764805f8f.17.1756996634259;
        Thu, 04 Sep 2025 07:37:14 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 17:37:12 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
References: 
 
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 03.09.25 17:30, Leonid Komarianskyi wrote:

Hello Leonid


> Introduced appropriate register definitions, helper macros,
> and initialization of required GICv3.1 distributor registers
> to support eSPI. This type of interrupt is handled in the
> same way as regular SPI interrupts, with the following
> differences:
> 
> 1) eSPIs can have up to 1024 interrupts, starting from the
> beginning of the range, whereas regular SPIs use INTIDs from
> 32 to 1019, totaling 988 interrupts;
> 2) eSPIs start at INTID 4096, necessitating additional interrupt
> index conversion during register operations.
> 
> In case if appropriate config is disabled, or GIC HW doesn't
> support eSPI, the existing functionality will remain the same.
> 
> Signed-off-by: Leonid Komarianskyi 
> Reviewed-by: Oleksandr Tyshchenko 
> 
> ---
> Changes in V6:
> - removed unnecessary parentheses in gic_is_valid_espi()
> - updated gic_is_valid_line(): it now verifies the condition irq <
>    gic_number_lines() first, as it is more likely that the irq number
>    will be from the non-eSPI range
> - minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
>    into appropriate inline functions introduced in the previous patch
> - added reviewed-by from Oleksandr Tyshchenko
> 
> Changes in V5:
> - fixed minor nits, no functional changes: changed u32 to uint32_t and
>    added a comment noting that the configuration for eSPIs is the same as
>    for regular SPIs
> - removed ifdefs for eSPI-specific offsets to reduce the number of
>    ifdefs and code duplication in further changes
> - removed reviewed-by as moving offset from ifdefs requires additional
>    confirmation from reviewers
> 
> Changes in V4:
> - added offsets for GICD_IGRPMODRnE and GICD_NSACRnE that are required
>    for vGIC emulation
> - added a log banner with eSPI information, similar to the one for
>    regular SPI
> - added newline after ifdef and before gic_is_valid_line
> - added reviewed-by from Volodymyr Babchuk
> 
> Changes in V3:
> - add __init attribute to gicv3_dist_espi_common_init
> - change open-codded eSPI register initialization to the appropriate
>    gen-mask macro
> - fixed formatting for lines with more than 80 symbols
> - introduced gicv3_dist_espi_init_aff to be able to use stubs in case of
>    CONFIG_GICV3_ESPI disabled
> - renamed parameter in the GICD_TYPER_ESPI_RANGE macro to espi_range
>    (name was taken from GIC specification) to avoid confusion
> - changed type for i variable to unsigned int since it cannot be
>    negative
> 
> Changes in V2:
> - move gic_number_espis function from
>    [PATCH 08/10] xen/arm: vgic: add resource management for extended SPIs
>    to use it in the newly introduced gic_is_valid_espi
> - add gic_is_valid_espi which checks if IRQ number is in supported
>    by HW eSPI range
> - update gic_is_valid_irq conditions to allow operations with eSPIs
> ---
>   xen/arch/arm/gic-v3.c                  | 83 ++++++++++++++++++++++++++
>   xen/arch/arm/include/asm/gic.h         | 21 ++++++-
>   xen/arch/arm/include/asm/gic_v3_defs.h | 38 ++++++++++++
>   3 files changed, 141 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a1e302fea2..a69263e461 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -485,6 +485,36 @@ static void __iomem *get_addr_by_offset(struct irq_desc *irqd, uint32_t offset)
>           default:
>               break;
>           }
> +#ifdef CONFIG_GICV3_ESPI
> +    case ESPI_BASE_INTID ... ESPI_MAX_INTID:
> +    {
> +        uint32_t irq_index = espi_intid_to_idx(irqd->irq);
> +
> +        switch ( offset )
> +        {
> +        case GICD_ISENABLER:
> +            return (GICD + GICD_ISENABLERnE + (irq_index / 32) * 4);
> +        case GICD_ICENABLER:
> +            return (GICD + GICD_ICENABLERnE + (irq_index / 32) * 4);
> +        case GICD_ISPENDR:
> +            return (GICD + GICD_ISPENDRnE + (irq_index / 32) * 4);
> +        case GICD_ICPENDR:
> +            return (GICD + GICD_ICPENDRnE + (irq_index / 32) * 4);
> +        case GICD_ISACTIVER:
> +            return (GICD + GICD_ISACTIVERnE + (irq_index / 32) * 4);
> +        case GICD_ICACTIVER:
> +            return (GICD + GICD_ICACTIVERnE + (irq_index / 32) * 4);
> +        case GICD_ICFGR:
> +            return (GICD + GICD_ICFGRnE + (irq_index / 16) * 4);
> +        case GICD_IROUTER:
> +            return (GICD + GICD_IROUTERnE + irq_index * 8);
> +        case GICD_IPRIORITYR:
> +            return (GICD + GICD_IPRIORITYRnE + irq_index);
> +        default:
> +            break;
> +        }
> +    }
> +#endif
>       default:
>           break;
>       }
> @@ -655,6 +685,55 @@ static void gicv3_set_irq_priority(struct irq_desc *desc,
>       spin_unlock(&gicv3.lock);
>   }
>   
> +#ifdef CONFIG_GICV3_ESPI
> +unsigned int gic_number_espis(void)
> +{
> +    return gic_hw_ops->info->nr_espi;
> +}
> +
> +static void __init gicv3_dist_espi_common_init(uint32_t type)
> +{
> +    unsigned int espi_nr, i;
> +
> +    espi_nr = min(1024U, GICD_TYPER_ESPIS_NUM(type));
> +    gicv3_info.nr_espi = espi_nr;


Sorry, I have just noticed one thing, and gicv3_cpu_init() probably 
would be a more correct place to write about it, but since you don't 
modify that function (it is not visible in the context), so writing here:

 From "Arm IHI 0069H.b (ID041224)"
10.1.2 GICv3.1 extended INTID range support

Note
Arm recommends that Armv8-R AArch64 PEs report ICC_CTLR_EL1.ExtRange==1, 
indicating that the GICv3.1 extended SPI and PPI ranges are supported.

Linux driver has an extra check for that:

  WARN((gic_data.ppi_nr > 16 || GIC_ESPI_NR != 0) &&
  !(gic_read_ctlr() & ICC_CTLR_EL1_ExtRange),
  "Distributor has extended ranges, but CPU%d doesn't\n",
  smp_processor_id());

added by the following commit:
irqchip/gic-v3: Warn about inconsistent implementations of extended ranges
https://github.com/torvalds/linux/commit/ad5a78d3da81836c88d1f2d53310484462660997


What is your opinion, is it worth having a similar check in Xen?


> +    /* The GIC HW doesn't support eSPI, so we can leave from here */
> +    if ( gicv3_info.nr_espi == 0 )
> +        return;
> +
> +    printk("GICv3: %d eSPI lines\n", gicv3_info.nr_espi);
> +


[snip]



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 14:54:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 14:54:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110399.1459623 (Exim 4.92)
	(envelope-from )
	id 1uuBLr-0005Lk-Op; Thu, 04 Sep 2025 14:54:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110399.1459623; Thu, 04 Sep 2025 14:54:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuBLr-0005Ld-M0; Thu, 04 Sep 2025 14:54:15 +0000
Received: by outflank-mailman (input) for mailman id 1110399;
 Thu, 04 Sep 2025 14:54: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 1uuBLp-0005LE-TL
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 14:54:14 +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 04ce721e-899f-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 16:54:12 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-61e8fe26614so1995864a12.1
 for ; Thu, 04 Sep 2025 07:54:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-61cfc1c7ed1sm14881499a12.1.2025.09.04.07.54.11
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 07:54: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: 04ce721e-899f-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1756997652; x=1757602452; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KvfZFCF++iFIXHxCkympi4+YUmyTvno+HR2qF84oyOw=;
        b=gm/QYKp0gn/YGXgFKDA1UPMAj650RO4GnlmdvFuScfgxV8JO3Qhcizx+ZiFfyuMAGg
         DjCjhhiE8SbyGTXxD1G3A1FEddxEFwZvaQRBJ7LQzc0IWZOSkZEmOMhOYGxWhQ6YATEA
         oaGs4vhmJCziP2Xf48CXuYK7OUI23Q/gpTRe2udkki35V8F/i1wPkukI94K3TUB6r8jR
         EVcXlmXr+EMq1v5gHQdlsqFFy9wASR2WgOyzVI3XVS2eJCVPdgv62kCW7cEYVwFA531g
         WkPCQ3+QK+qno9/SFlYWpQVul6Fbq0jfKyjOIMZSOkoUfftZvFqkVu6CrexmrC49/oBF
         kxhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756997652; x=1757602452;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=KvfZFCF++iFIXHxCkympi4+YUmyTvno+HR2qF84oyOw=;
        b=F7O0noT436kDNjZ4AchJzhp6tBgolaygI+VkqFECYPcaOyjAvmxRrtOecFOx8Sjpje
         d8dlD3uBXx6dAvcNGNCNeQpxaPve0XaEr6dG1DGh0VR7eGfHLm6e5etmVthJm9EGsRQx
         vDFe1Tuezk2gdnM77XkxzHHRK7EbRAieu77g7xvb4H2n7HTxzkz1Acnn+Rlnv0ipAGZT
         TPNXPfv6bkspK0vlH+J8ASJJnzGAT1yt4xdWvjWVuguD4ksOmKpO9r4OgryfmHudUx7k
         y3u4GfIVDtLiQOEoW2CovvDwdSX9t5vz8mfezmmmTatMnBpfW7Bei8gZWSJCAkdVGQi0
         IoUw==
X-Gm-Message-State: AOJu0YzT4PONWB0trtkstxQVApaGeXNDTMRX4hN79mNcANla6ZNqaCd4
	JNWcQ/+5Kh1LpLUY7y0weV9Lk/d0a+Akb/4+O59zuwHm1YMJuMb0+FqhuAB4uw9yTGsNRTqhlKa
	/sdg=
X-Gm-Gg: ASbGncssy0uK6EWrX2ac++YdXmFbbki5Xpj5g1yQuQVD3708yjJvaDz1Lz2pw2YKdbE
	94LGu/+dLg0Q138eO0lOb4qipXRptmfKON5AHC3EiFeVvZr73A6sm5QiJih68evg/1pdNKXd9Gu
	h4EqFa9RbM+HxTqjSzSEhiA4B0UmkdK0Hjy+kv4RsW1nPT9U3h5Zql//i9x1onwP0l6K4ODAaCG
	1OyngIfoEPdehtbGm0SN2qlOBpAl/BR0Z+DMfDH1ZofxU/lZO2zuwzAUOrna5uiC0O8Ns1rVpeO
	5ozH+valj2biqn63jTR7LMbLNbFKCcNs3fcVQeUdZX2uVTyRkjA0IH+WpYTJjcn5Q8JfTwoBpKk
	NKUsw2DrDOOCAM7tHTX3DyPaVaHZGVERgcZPmkmQ4vhQCBzSnQrFZZRQXxFHHSwQCV2xvl/TYoy
	VA4tMVXVxVgSsj1F8gaw==
X-Google-Smtp-Source: AGHT+IHe9kK1smMzFK70YRuzIDzb8hTWRDmN35rvVE6wZVCua2cIfFKu3TEepqm8IcluEAEZZZticg==
X-Received: by 2002:a05:6402:d0e:b0:61c:8114:8832 with SMTP id 4fb4d7f45d1cf-61d2699b037mr17856608a12.16.1756997651721;
        Thu, 04 Sep 2025 07:54:11 -0700 (PDT)
Message-ID: <78196af7-d6b6-4f08-a806-ffee777ee762@suse.com>
Date: Thu, 4 Sep 2025 16:54:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: New Defects reported by Coverity Scan for XenProject
To: "xen-devel@lists.xenproject.org" 
References: <68b9a73be8eb_27ea7e2d9ed55e799088716@prd-scan-dashboard-0.mail>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <68b9a73be8eb_27ea7e2d9ed55e799088716@prd-scan-dashboard-0.mail>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 16:50, scan-admin@coverity.com wrote:
> Hi,
> 
> Please find the latest report on new defect(s) introduced to XenProject found with Coverity Scan.
> 
> 1 new defect(s) introduced to XenProject found with Coverity Scan.
> 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
> 
> 
> ** CID 1665214:       Integer handling issues  (INTEGER_OVERFLOW)
> /tools/firmware/xen-dir/xen-root/xen/common/symbols.c: 123           in symbols_lookup()
> 
> 
> _____________________________________________________________________________________________
> *** CID 1665214:         Integer handling issues  (INTEGER_OVERFLOW)
> /tools/firmware/xen-dir/xen-root/xen/common/symbols.c: 123             in symbols_lookup()
> 117         }
> 118     
> 119         /* If we hit an END symbol, move to the previous (real) one. */
> 120         if (!symbols_names[get_symbol_offset(low)]) {
> 121             ASSERT(low);

With this I wonder ...

> 122             symbol_end = symbols_address(low);
>>>>     CID 1665214:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>     Expression "--low", where "low" is known to be equal to 0, underflows the type of "--low", which is type "unsigned int".
> 123             --low;

... how "low" can be known to be zero when getting here. Without the
assertion I would accept that the tool doesn't understand that an
"end" symbol can't come first (albeit imo the report then would still
be a false positive one).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 15:10:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 15:10:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110417.1459637 (Exim 4.92)
	(envelope-from )
	id 1uuBbG-0008GN-7v; Thu, 04 Sep 2025 15:10:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110417.1459637; Thu, 04 Sep 2025 15: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 1uuBbG-0008GG-4U; Thu, 04 Sep 2025 15:10:10 +0000
Received: by outflank-mailman (input) for mailman id 1110417;
 Thu, 04 Sep 2025 15:10: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 1uuBbE-0008GA-IU
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 15:10:08 +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 3d040e06-89a1-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 17:10:07 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DB9PR03MB8146.eurprd03.prod.outlook.com (2603:10a6:10:372::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 15:10:00 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 15:10: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: 3d040e06-89a1-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XE269mKapFIF66iuRIt6USP6BWKLXdex7ZUM8QwILAalJu3Pr4Z0OiUoJ3YR0L79uMZXVcesSDIgxDjWZ7rXg3NTMbnH+mX+jFvhOmU85MYma0Yt8zz6NygrRQwQnJ11D1s9G0uHhGle6/08/HPwF5Na1UaW5jiDbRIxGKVNHYaVG/vsnHi4OUpe9w9EJvnEbD3zsBUNQjl+sOAbYkfS1aHdxbiurS8ER+NtkLqDztVOwzNfE3QhVDN2cIeuKv84A65Wxxf00C9CtL+m3hD4btRNImEKa3aSFAKvsJFRSm0vFJ4G2iKqYz2gsZzmv+Dl0aR6e2FXGGCT2wwlxflSrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Niz0DFUPRpKCHqdfz0aJlHUKTsNhm2yo8ao1X2XDMBM=;
 b=ZyBPbpIbOY0lXblWbf6JCJ7EWL19n8mikdnwAuq67Esi5riLV2A7QG9FchntKR3AYw6iK7YwgrCPDxb60SYWF18Ygbx4/STe8QRjRCk3EPStsK5ttOpzlFg268QTdpcCICyGSVHzFp5g6sFwSkja74cRMXyLfXfkkIVSyLuOLFnFpA5mR9B5Cy3queIWMaXzUE5b/+u+3h3bw/CCr4w6bLygcAdniffu4rJxV9I7VPP5yhQqY2KJ47gmViT4yRmMPwjrzJUs0eY67P4zRbA3dZO4GGxzN7LvBDg7Cd21wdA42Jp2D1DFtKM2A0BMh3dQxF+bScxQgb6Uj7NbCVQT5g==
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=Niz0DFUPRpKCHqdfz0aJlHUKTsNhm2yo8ao1X2XDMBM=;
 b=Xst59p/6k0MCem11w7XqCyxKtQ6vxELY1EthUqjJ2d93q85o1Dr/o4oNNNUk162AYUX4IOizsyjxcZK8z3gFDcKk4rhIBubC9EYsNMDtJcm9GYsgCXNPffpM2bCKeTVAu0woNOG4K9QT2FTbkyDOfwrGTgsnTid0tPbi7ETAZ5yUQno/b6lrni3zmQWMupIOVbgMqgSUakwS5aLprTDRAobQu3E4i6MT3KB3aagt/EHs5JCx9+fTB8NSdGhzTdVVaNSEFn+x0alGvVaK3f777M5yAZzwzzbv4gisbKCSotM/dpxFq2/t1vKLiMmau5KW0KelHw8MQLR1om4dib2Tzg==
From: Leonid Komarianskyi 
To: Oleksandr Tyshchenko ,
	"xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko 
Subject: Re: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Topic: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Index: AQHcHN88f5Lxm2g89kebOYUIBUtDZbSDGQ4AgAAJKYA=
Date: Thu, 4 Sep 2025 15:10:00 +0000
Message-ID: <9b6e873d-e96f-49a9-9d64-b03a2493d6bc@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: GV2PR03MB8678:EE_|DB9PR03MB8146:EE_
x-ms-office365-filtering-correlation-id: c56f0789-5842-4c05-aece-08ddebc51e1f
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?ajNaVkFWU2xGd3I1dFVrc3JFY3NOSHpyV1U3dnUvQmk2dkVibFV1SVN2YmRi?=
 =?utf-8?B?WWFaKzRtS2dsRnRkWW1UWktDU01DQ056RGdxMUpkZ0lxblVlcWFxMTBiWUVl?=
 =?utf-8?B?ZXU0NDJsV0MySFJJbUdBQStvakU1b2ZxT29MclJjT25OSlJuTmRnWGJ0MEZt?=
 =?utf-8?B?Y1V5eHduWTlVRUI5Vk5MakVreVl2L0pyTW9sUm9xcis2VmxyS2w0eWF6d0Zz?=
 =?utf-8?B?b3BMUGJHZHdpZTg5UXBqRHhDMVlwZWVlTENCT1R6M3B6c3krUldoSzdjdFBU?=
 =?utf-8?B?ZDlTTjRZcGc3aUtIMnBZSitDMTJyUGpFOWlRUG01ZUM4SE1FL2tjNXZNQlNR?=
 =?utf-8?B?eGJaUm9IOXpDa20wdFErdXNPTEQwVk1GN2VLL2dlSDVEdkFDV3J6YlJDU2hJ?=
 =?utf-8?B?aWlsaVQvRUE4MzZNZStkaVIvaUI3eHJ4UFpLZEpWeTN4bS9Ic0NpUGREcVRZ?=
 =?utf-8?B?cFgvYThITW1iOVRaSGNzT1hpMm9NOGhBempGSVRVNmRJNTVoY2w0RWZ4dVpj?=
 =?utf-8?B?Q0FTdWYzcHdxc1FYajBTeDJWWWpQVURsNDF4ajVldGZHYktLRTNIeUc1dXRE?=
 =?utf-8?B?UG1sajEzcUdTdGc4VmtVL2x3Mnc3U1Z5ZTBSenFyUjF2clUzWUgvTld3azYy?=
 =?utf-8?B?RkFEVkpqVFNMREJUbTJEZ0t1ZEQ5OW55MVFHSm14dXJzWEttbDFGb1htT2ZG?=
 =?utf-8?B?VXpoZWxqM0E0enFVODJlelV5ekJPMHB3cTBDdkFwVVY2ZGQrSmg2TE9nckVs?=
 =?utf-8?B?bEVKanh2eTgwTGFzNU5NWlZXWTRPV0dqcTg3NFF6M3R4OG1jZ1JjaEFRQmt4?=
 =?utf-8?B?dkhiUTRnQ05pZEhXMWdxaGhPaEVtZi81YTNPek55eEp6YW9GcEpDbVhPUE5j?=
 =?utf-8?B?RWErdEI2dm9pOXF3Z1hiSTN0RGVGRVNhK1dXOGpmd291ZkZmdFVDNE1oRkhL?=
 =?utf-8?B?Q2ZLVkxSdmxMSkRvc051V1c1LzJQSDVhZUZYK0ptaEo2YjhSbnFjeElWa01N?=
 =?utf-8?B?U2hsMEJWeWd5V3pVbjVRdnNZbUpON0xmdy83bUhmQkt6UitBMW5lRXpEbEg3?=
 =?utf-8?B?SlgwK0dEaTlLbVZ0UHNONmZSR0c5YVFodTZwaFhyWWZHalRlUGxLMXJaeG1I?=
 =?utf-8?B?OVhldGZWZHl4U1kvYXNYOUFtOXc3SnU0WmI3dVd1dzZiNTRINU4zSXI2eXdH?=
 =?utf-8?B?djZ3R1VhWnhCbG9SS1NzVkFXYWdicFh4RFVjRTZSeHFnK0dtcXJuS0trcEp5?=
 =?utf-8?B?enZFc0xvcDZkcFNuRmU5dlBpQUZROWJRYVhMMHdDME1XSXM0VGpzMFFqQnFH?=
 =?utf-8?B?dW1qWklFNm5ocEFKaTJ5ZkUrUHR3NUhyRjZVc25OWUd1ZEg3bkw1L1Q1QWgz?=
 =?utf-8?B?MTcvakw5UENnOUp0QVhBaUVGbmN5NU5PZmpiR1Zua0V3cDMrcUtUZjJ1dzNP?=
 =?utf-8?B?RU43YmlBWXZvcjNrelIxR0RRbU1DREloUCtIS25pSU1aNktmUzg0NENIUEdM?=
 =?utf-8?B?eVk3eGw3a2tiN3p1Y1Q0Qld6Tjhramttb2g3ell6T1I1bExjUUhvcFNuTUxv?=
 =?utf-8?B?SXZxeHh3RHJpcEpNWHVLWnJmbFJPTkQyNlF1M2MwMTFvZmNlcGkrODFrU3RG?=
 =?utf-8?B?NUlDcDFMNHpvMHgyb2ZERkxoZFh4TllJcUJCQThLNDFKS3h4dVhZblRWQ3Zr?=
 =?utf-8?B?QmIzYURDYVU2Z0xILy9UcXBGNEoyUUFsZGZrdUhaOUtpT1NLNkNPM3pFcW1p?=
 =?utf-8?B?aUk2OGFDa2I3cGFqeFFqMWp3UEN4dDA1U0ZWMmJ1S1dNZ01LY0Y4TzZjS0VE?=
 =?utf-8?B?UTE2YVpIUW1YWlRrZ0xLWm9sbkplWi8vOGdwT1lhZzNxb2Qzc2liQjB6OFJj?=
 =?utf-8?B?clFRVGJMUWVuVFUrWUhPbmZSR1BjZ2swQmJmTEpIR2NaVkx5UlhINGNGU1ZL?=
 =?utf-8?Q?bf9vntxh9EI=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OW1KVDRqVzk0QzlXbENGWWpmMUdFazZOc0x3WXpzbHEyTmJ2TklEalRUWHRo?=
 =?utf-8?B?RzIxODNOSkVZaUVGeWxVQVo4T2lvb0dsY1l2TUZGVWxNTTVuVjZtTmRJam9L?=
 =?utf-8?B?cnlkVVg4NkJadHV3WjJPUlRBZ251YkZxZUFEZFZCNCs4aC9VTTN4Tk0rWlY0?=
 =?utf-8?B?NEcrN0IvMnRESGVPQnV6TStLamw1cmRQMUpiK2FRSndza3IvNWlOWmlGNmhD?=
 =?utf-8?B?bS9oZVp1em8rT001TktHcCt5OW5TWDlray9nelFGdHVmK0c3NE81Z0dzVEda?=
 =?utf-8?B?ejUzVnhnMXM5TXRlQU0vSXNLTVRXRzkrb1Q3MURjbW5CdTlRZUZIQXFuUGZ4?=
 =?utf-8?B?QmlVLytQYkw5SmVwOG1jOFdpSmxlbW9VK2ozR0l6N3NMWk9pYUZqYk5TUUJ2?=
 =?utf-8?B?ZXZVNU91RFN3VUdwcSs4RjVwVmVkUXZnc3ZVb0tTdTRUVWJQNHV2YmR6THpK?=
 =?utf-8?B?ZmVnT3hnVzFpR2dTVFFlWUEzM1lLZlArSENLTTlFUmI0dWtWbEtWRllzQkxC?=
 =?utf-8?B?Nm1hSEZ0N2YyUDNjcWJFNW9yRjVjaVFGOVFhak12aXJ6N01BTmt0YnZxTjRU?=
 =?utf-8?B?QTJQVXJOSjBRT0N2NFRHbUlEdWVHMGQ1SnBUbENlcTlSRzNtM1Yybk40UmJ3?=
 =?utf-8?B?TXlXdC9OSXZ6Q2lwWmFSZGxZcDRiWCtMMUE0WjdBTXhaK1cyaGpOOXN0cy83?=
 =?utf-8?B?UFlzdjM0TFBHdEl1Y2FrL1orUEZ2T1I3NEhidlQzMTR3UmFGUU5mcm1jak96?=
 =?utf-8?B?Rm56OWlhQTJnVzFjK0djV3JIWHNFUXlDS1I0eTlCZ3BvSmFoK3c4RDJRQyt5?=
 =?utf-8?B?VjFaRTlIQTNodk4waW5nR3p2aDFOY3FIVVIzRExUZ3c3ekhheHFwU2daV0ZQ?=
 =?utf-8?B?NjJma2ZsVWdiOUVlU2Fnd3ZwWEtOTzkzTnJNbml4OFVpbE5lRGVyQi9kOHpj?=
 =?utf-8?B?WEwrTEY4VmFTZUdSRjZWRTIzUVpneTBsandHenBZZThsUGZDaUF6UFhjQ0pE?=
 =?utf-8?B?Wk9tWEhPbFhTMUVvZVY5MEM5U2lKMWRybDBxY1M5Tlh3WStmWUV1ZnArb1ZP?=
 =?utf-8?B?aVcrbDQ5MHhnS1NiNHlQRlNRUS94RElEcXpibmhLcEc1U3NWZlR3Z094ekpW?=
 =?utf-8?B?MEJCdXhWK3RwV1RSUE5Oc1JXeEdOaHY4L0I3UzVvdDA5b0ZGTGRFQjlGUjk0?=
 =?utf-8?B?N29JaW9JSnd2R2hUUEREZ1pObnAvSUJ0YVZoWWs0ei9XVHFGRkdBc0p1NHQ4?=
 =?utf-8?B?QUI1WGc1RC9FK0xvRDYyUzNJTkJ6b2YrVytzRis5Yml3MnJMRkt0dTRqOXVC?=
 =?utf-8?B?REx0LzRBTzVySStScHlOdkZvdnlXMzNLWGt0Tm1qdjZCSW5tUUl1VktibmNr?=
 =?utf-8?B?NkJPaXJ5ZkpTUkhoUHJlYUdIc0VpMG1rVWRNQUFWNVhFSTVHKzUydXI1c3Vn?=
 =?utf-8?B?MGJMenVQYUZmVzhMRXc2SzBReG5kWmRHbm9iS21laE51UTYrRHJnTWlwOHVD?=
 =?utf-8?B?SHgrelFRVEhRTzFpc0pUOHhYZmRDTzlYYTZlRnJ0ZDEwdDRPN2dBME5EaVhO?=
 =?utf-8?B?RFBscCtOWlFxWVpCLzV3NnVUWHVkWG9KRlhBRmRFZ0JEYnlKOHZicVc3akJW?=
 =?utf-8?B?UFByaTRxYXJEV01MTDZOTHUxYVhpQUpPUlQwQ2VkcVArSnVPZWpvNXZCUmxO?=
 =?utf-8?B?OUhlS2hlbnJQWnpKT3NNTC9xV1hjYXRheUoxeTg3dUtKSWlMTWdad3lGcnFp?=
 =?utf-8?B?RXc1Y2tDQTMwWXhNUkdBdHV1QTRIZGcyRHVWNG9KNlVIWG43UGNsRlNvc2xm?=
 =?utf-8?B?QWVBSG5YeUMrckRnL2M4RUZra1dQak1ZZHhuRUhZa0ZEOVVoaHRpb0Y1RWdH?=
 =?utf-8?B?YTNOVEdMeGwyVHpoV1BGMFdGRTh4NHI2S09QaVF2RXhJT2tBb24wU2tZeEw0?=
 =?utf-8?B?RTBvYVZVaXpLb01pcVN0QWVVT1FJeUZDWkVydTZTOE9tQW9IWitqSGxGWnE0?=
 =?utf-8?B?ZnEyNjF3NUd5THhuYlZrZFRFWkhGOHpvN296ZVkweXBIZ0pKZ2YvZTgrVElO?=
 =?utf-8?B?a0hmZHVxN3hnNkgzRU9XTWhrV2xpcmNNME1IV0pzUk02cUR1dW45YzZteUI4?=
 =?utf-8?B?c0w5UG5jZ2ZBYUJ1aTVHTmdyK1hITGVnSWxBZ2I1c09BUUpRSG0wblR0L3dI?=
 =?utf-8?Q?ot7GSjNXBcGXeblUl+TaVLc=3D?=
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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c56f0789-5842-4c05-aece-08ddebc51e1f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 15:10:00.2543
 (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: f+Ij+3VItIxO89K3DGrQlih5EkaHnJzMsALKiQ1sFz+zTuqLxDi6/qJG9zcXawS0DatWzEsljDA31v3ZKVuoE2Alv0e84u+GaLSRYBfgz6s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB8146

SGVsbG8gT2xla3NhbmRyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4NCg0KT24gMDQu
MDkuMjUgMTc6MzcsIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdyb3RlOg0KPiANCj4gDQo+IE9uIDAz
LjA5LjI1IDE3OjMwLCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0KPiANCj4gSGVsbG8gTGVv
bmlkDQo+IA0KPiANCj4+IEludHJvZHVjZWQgYXBwcm9wcmlhdGUgcmVnaXN0ZXIgZGVmaW5pdGlv
bnMsIGhlbHBlciBtYWNyb3MsDQo+PiBhbmQgaW5pdGlhbGl6YXRpb24gb2YgcmVxdWlyZWQgR0lD
djMuMSBkaXN0cmlidXRvciByZWdpc3RlcnMNCj4+IHRvIHN1cHBvcnQgZVNQSS4gVGhpcyB0eXBl
IG9mIGludGVycnVwdCBpcyBoYW5kbGVkIGluIHRoZQ0KPj4gc2FtZSB3YXkgYXMgcmVndWxhciBT
UEkgaW50ZXJydXB0cywgd2l0aCB0aGUgZm9sbG93aW5nDQo+PiBkaWZmZXJlbmNlczoNCj4+DQo+
PiAxKSBlU1BJcyBjYW4gaGF2ZSB1cCB0byAxMDI0IGludGVycnVwdHMsIHN0YXJ0aW5nIGZyb20g
dGhlDQo+PiBiZWdpbm5pbmcgb2YgdGhlIHJhbmdlLCB3aGVyZWFzIHJlZ3VsYXIgU1BJcyB1c2Ug
SU5USURzIGZyb20NCj4+IDMyIHRvIDEwMTksIHRvdGFsaW5nIDk4OCBpbnRlcnJ1cHRzOw0KPj4g
MikgZVNQSXMgc3RhcnQgYXQgSU5USUQgNDA5NiwgbmVjZXNzaXRhdGluZyBhZGRpdGlvbmFsIGlu
dGVycnVwdA0KPj4gaW5kZXggY29udmVyc2lvbiBkdXJpbmcgcmVnaXN0ZXIgb3BlcmF0aW9ucy4N
Cj4+DQo+PiBJbiBjYXNlIGlmIGFwcHJvcHJpYXRlIGNvbmZpZyBpcyBkaXNhYmxlZCwgb3IgR0lD
IEhXIGRvZXNuJ3QNCj4+IHN1cHBvcnQgZVNQSSwgdGhlIGV4aXN0aW5nIGZ1bmN0aW9uYWxpdHkg
d2lsbCByZW1haW4gdGhlIHNhbWUuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogTGVvbmlkIEtvbWFy
aWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4NCj4+IFJldmlld2VkLWJ5OiBP
bGVrc2FuZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5c2hjaGVua29AZXBhbS5jb20+DQo+Pg0K
Pj4gLS0tDQo+PiBDaGFuZ2VzIGluIFY2Og0KPj4gLSByZW1vdmVkIHVubmVjZXNzYXJ5IHBhcmVu
dGhlc2VzIGluIGdpY19pc192YWxpZF9lc3BpKCkNCj4+IC0gdXBkYXRlZCBnaWNfaXNfdmFsaWRf
bGluZSgpOiBpdCBub3cgdmVyaWZpZXMgdGhlIGNvbmRpdGlvbiBpcnEgPA0KPj4gwqDCoCBnaWNf
bnVtYmVyX2xpbmVzKCkgZmlyc3QsIGFzIGl0IGlzIG1vcmUgbGlrZWx5IHRoYXQgdGhlIGlycSBu
dW1iZXINCj4+IMKgwqAgd2lsbCBiZSBmcm9tIHRoZSBub24tZVNQSSByYW5nZQ0KPj4gLSBtaW5v
ciBjaGFuZ2U6IGNoYW5nZWQgdGhlIG1hY3JvcyBFU1BJX0lOVElEMklEWCBhbmQgRVNQSV9JRFgy
SU5USUQNCj4+IMKgwqAgaW50byBhcHByb3ByaWF0ZSBpbmxpbmUgZnVuY3Rpb25zIGludHJvZHVj
ZWQgaW4gdGhlIHByZXZpb3VzIHBhdGNoDQo+PiAtIGFkZGVkIHJldmlld2VkLWJ5IGZyb20gT2xl
a3NhbmRyIFR5c2hjaGVua28NCj4+DQo+PiBDaGFuZ2VzIGluIFY1Og0KPj4gLSBmaXhlZCBtaW5v
ciBuaXRzLCBubyBmdW5jdGlvbmFsIGNoYW5nZXM6IGNoYW5nZWQgdTMyIHRvIHVpbnQzMl90IGFu
ZA0KPj4gwqDCoCBhZGRlZCBhIGNvbW1lbnQgbm90aW5nIHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24g
Zm9yIGVTUElzIGlzIHRoZSBzYW1lIGFzDQo+PiDCoMKgIGZvciByZWd1bGFyIFNQSXMNCj4+IC0g
cmVtb3ZlZCBpZmRlZnMgZm9yIGVTUEktc3BlY2lmaWMgb2Zmc2V0cyB0byByZWR1Y2UgdGhlIG51
bWJlciBvZg0KPj4gwqDCoCBpZmRlZnMgYW5kIGNvZGUgZHVwbGljYXRpb24gaW4gZnVydGhlciBj
aGFuZ2VzDQo+PiAtIHJlbW92ZWQgcmV2aWV3ZWQtYnkgYXMgbW92aW5nIG9mZnNldCBmcm9tIGlm
ZGVmcyByZXF1aXJlcyBhZGRpdGlvbmFsDQo+PiDCoMKgIGNvbmZpcm1hdGlvbiBmcm9tIHJldmll
d2Vycw0KPj4NCj4+IENoYW5nZXMgaW4gVjQ6DQo+PiAtIGFkZGVkIG9mZnNldHMgZm9yIEdJQ0Rf
SUdSUE1PRFJuRSBhbmQgR0lDRF9OU0FDUm5FIHRoYXQgYXJlIHJlcXVpcmVkDQo+PiDCoMKgIGZv
ciB2R0lDIGVtdWxhdGlvbg0KPj4gLSBhZGRlZCBhIGxvZyBiYW5uZXIgd2l0aCBlU1BJIGluZm9y
bWF0aW9uLCBzaW1pbGFyIHRvIHRoZSBvbmUgZm9yDQo+PiDCoMKgIHJlZ3VsYXIgU1BJDQo+PiAt
IGFkZGVkIG5ld2xpbmUgYWZ0ZXIgaWZkZWYgYW5kIGJlZm9yZSBnaWNfaXNfdmFsaWRfbGluZQ0K
Pj4gLSBhZGRlZCByZXZpZXdlZC1ieSBmcm9tIFZvbG9keW15ciBCYWJjaHVrDQo+Pg0KPj4gQ2hh
bmdlcyBpbiBWMzoNCj4+IC0gYWRkIF9faW5pdCBhdHRyaWJ1dGUgdG8gZ2ljdjNfZGlzdF9lc3Bp
X2NvbW1vbl9pbml0DQo+PiAtIGNoYW5nZSBvcGVuLWNvZGRlZCBlU1BJIHJlZ2lzdGVyIGluaXRp
YWxpemF0aW9uIHRvIHRoZSBhcHByb3ByaWF0ZQ0KPj4gwqDCoCBnZW4tbWFzayBtYWNybw0KPj4g
LSBmaXhlZCBmb3JtYXR0aW5nIGZvciBsaW5lcyB3aXRoIG1vcmUgdGhhbiA4MCBzeW1ib2xzDQo+
PiAtIGludHJvZHVjZWQgZ2ljdjNfZGlzdF9lc3BpX2luaXRfYWZmIHRvIGJlIGFibGUgdG8gdXNl
IHN0dWJzIGluIGNhc2Ugb2YNCj4+IMKgwqAgQ09ORklHX0dJQ1YzX0VTUEkgZGlzYWJsZWQNCj4+
IC0gcmVuYW1lZCBwYXJhbWV0ZXIgaW4gdGhlIEdJQ0RfVFlQRVJfRVNQSV9SQU5HRSBtYWNybyB0
byBlc3BpX3JhbmdlDQo+PiDCoMKgIChuYW1lIHdhcyB0YWtlbiBmcm9tIEdJQyBzcGVjaWZpY2F0
aW9uKSB0byBhdm9pZCBjb25mdXNpb24NCj4+IC0gY2hhbmdlZCB0eXBlIGZvciBpIHZhcmlhYmxl
IHRvIHVuc2lnbmVkIGludCBzaW5jZSBpdCBjYW5ub3QgYmUNCj4+IMKgwqAgbmVnYXRpdmUNCj4+
DQo+PiBDaGFuZ2VzIGluIFYyOg0KPj4gLSBtb3ZlIGdpY19udW1iZXJfZXNwaXMgZnVuY3Rpb24g
ZnJvbQ0KPj4gwqDCoCBbUEFUQ0ggMDgvMTBdIHhlbi9hcm06IHZnaWM6IGFkZCByZXNvdXJjZSBt
YW5hZ2VtZW50IGZvciBleHRlbmRlZCBTUElzDQo+PiDCoMKgIHRvIHVzZSBpdCBpbiB0aGUgbmV3
bHkgaW50cm9kdWNlZCBnaWNfaXNfdmFsaWRfZXNwaQ0KPj4gLSBhZGQgZ2ljX2lzX3ZhbGlkX2Vz
cGkgd2hpY2ggY2hlY2tzIGlmIElSUSBudW1iZXIgaXMgaW4gc3VwcG9ydGVkDQo+PiDCoMKgIGJ5
IEhXIGVTUEkgcmFuZ2UNCj4+IC0gdXBkYXRlIGdpY19pc192YWxpZF9pcnEgY29uZGl0aW9ucyB0
byBhbGxvdyBvcGVyYXRpb25zIHdpdGggZVNQSXMNCj4+IC0tLQ0KPj4gwqAgeGVuL2FyY2gvYXJt
L2dpYy12My5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IDgzICsrKysrKysr
KysrKysrKysrKysrKysrKysrDQo+PiDCoCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljLmjC
oMKgwqDCoMKgwqDCoMKgIHwgMjEgKysrKysrLQ0KPj4gwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUv
YXNtL2dpY192M19kZWZzLmggfCAzOCArKysrKysrKysrKysNCj4+IMKgIDMgZmlsZXMgY2hhbmdl
ZCwgMTQxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gvYXJtL2dpYy12My5jIGIveGVuL2FyY2gvYXJtL2dpYy12My5jDQo+PiBpbmRleCBh
MWUzMDJmZWEyLi5hNjkyNjNlNDYxIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2dpYy12
My5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZ2ljLXYzLmMNCj4+IEBAIC00ODUsNiArNDg1LDM2
IEBAIHN0YXRpYyB2b2lkIF9faW9tZW0gKmdldF9hZGRyX2J5X29mZnNldChzdHJ1Y3QgDQo+PiBp
cnFfZGVzYyAqaXJxZCwgdWludDMyX3Qgb2Zmc2V0KQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGRl
ZmF1bHQ6DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+IMKgwqDCoMKg
wqDCoMKgwqDCoCB9DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiArwqDCoMKgIGNh
c2UgRVNQSV9CQVNFX0lOVElEIC4uLiBFU1BJX01BWF9JTlRJRDoNCj4+ICvCoMKgwqAgew0KPj4g
K8KgwqDCoMKgwqDCoMKgIHVpbnQzMl90IGlycV9pbmRleCA9IGVzcGlfaW50aWRfdG9faWR4KGly
cWQtPmlycSk7DQo+PiArDQo+PiArwqDCoMKgwqDCoMKgwqAgc3dpdGNoICggb2Zmc2V0ICkNCj4+
ICvCoMKgwqDCoMKgwqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lTRU5BQkxF
UjoNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAoR0lDRCArIEdJQ0RfSVNFTkFC
TEVSbkUgKyAoaXJxX2luZGV4IC8gMzIpICogNCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBH
SUNEX0lDRU5BQkxFUjoNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAoR0lDRCAr
IEdJQ0RfSUNFTkFCTEVSbkUgKyAoaXJxX2luZGV4IC8gMzIpICogNCk7DQo+PiArwqDCoMKgwqDC
oMKgwqAgY2FzZSBHSUNEX0lTUEVORFI6DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1
cm4gKEdJQ0QgKyBHSUNEX0lTUEVORFJuRSArIChpcnFfaW5kZXggLyAzMikgKiA0KTsNCj4+ICvC
oMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSUNQRU5EUjoNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHJldHVybiAoR0lDRCArIEdJQ0RfSUNQRU5EUm5FICsgKGlycV9pbmRleCAvIDMyKSAqIDQp
Ow0KPj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9JU0FDVElWRVI6DQo+PiArwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBHSUNEX0lTQUNUSVZFUm5FICsgKGlycV9pbmRl
eCAvIDMyKSAqIDQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9JQ0FDVElWRVI6DQo+
PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBHSUNEX0lDQUNUSVZFUm5F
ICsgKGlycV9pbmRleCAvIDMyKSAqIDQpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lDRF9J
Q0ZHUjoNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAoR0lDRCArIEdJQ0RfSUNG
R1JuRSArIChpcnFfaW5kZXggLyAxNikgKiA0KTsNCj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJ
Q0RfSVJPVVRFUjoNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAoR0lDRCArIEdJ
Q0RfSVJPVVRFUm5FICsgaXJxX2luZGV4ICogOCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBH
SUNEX0lQUklPUklUWVI6DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJQ0Qg
KyBHSUNEX0lQUklPUklUWVJuRSArIGlycV9pbmRleCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgZGVm
YXVsdDoNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGJyZWFrOw0KPj4gK8KgwqDCoMKgwqDC
oMKgIH0NCj4+ICvCoMKgwqAgfQ0KPj4gKyNlbmRpZg0KPj4gwqDCoMKgwqDCoCBkZWZhdWx0Og0K
Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIGJyZWFrOw0KPj4gwqDCoMKgwqDCoCB9DQo+PiBAQCAtNjU1
LDYgKzY4NSw1NSBAQCBzdGF0aWMgdm9pZCBnaWN2M19zZXRfaXJxX3ByaW9yaXR5KHN0cnVjdCAN
Cj4+IGlycV9kZXNjICpkZXNjLA0KPj4gwqDCoMKgwqDCoCBzcGluX3VubG9jaygmZ2ljdjMubG9j
ayk7DQo+PiDCoCB9DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiArdW5zaWduZWQg
aW50IGdpY19udW1iZXJfZXNwaXModm9pZCkNCj4+ICt7DQo+PiArwqDCoMKgIHJldHVybiBnaWNf
aHdfb3BzLT5pbmZvLT5ucl9lc3BpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgdm9pZCBfX2lu
aXQgZ2ljdjNfZGlzdF9lc3BpX2NvbW1vbl9pbml0KHVpbnQzMl90IHR5cGUpDQo+PiArew0KPj4g
K8KgwqDCoCB1bnNpZ25lZCBpbnQgZXNwaV9uciwgaTsNCj4+ICsNCj4+ICvCoMKgwqAgZXNwaV9u
ciA9IG1pbigxMDI0VSwgR0lDRF9UWVBFUl9FU1BJU19OVU0odHlwZSkpOw0KPj4gK8KgwqDCoCBn
aWN2M19pbmZvLm5yX2VzcGkgPSBlc3BpX25yOw0KPiANCj4gDQo+IFNvcnJ5LCBJIGhhdmUganVz
dCBub3RpY2VkIG9uZSB0aGluZywgYW5kIGdpY3YzX2NwdV9pbml0KCkgcHJvYmFibHkgDQo+IHdv
dWxkIGJlIGEgbW9yZSBjb3JyZWN0IHBsYWNlIHRvIHdyaXRlIGFib3V0IGl0LCBidXQgc2luY2Ug
eW91IGRvbid0IA0KPiBtb2RpZnkgdGhhdCBmdW5jdGlvbiAoaXQgaXMgbm90IHZpc2libGUgaW4g
dGhlIGNvbnRleHQpLCBzbyB3cml0aW5nIGhlcmU6DQo+IA0KPiAgRnJvbSAiQXJtIElISSAwMDY5
SC5iIChJRDA0MTIyNCkiDQo+IDEwLjEuMiBHSUN2My4xIGV4dGVuZGVkIElOVElEIHJhbmdlIHN1
cHBvcnQNCj4gDQo+IE5vdGUNCj4gQXJtIHJlY29tbWVuZHMgdGhhdCBBcm12OC1SIEFBcmNoNjQg
UEVzIHJlcG9ydCBJQ0NfQ1RMUl9FTDEuRXh0UmFuZ2U9PTEsIA0KPiBpbmRpY2F0aW5nIHRoYXQg
dGhlIEdJQ3YzLjEgZXh0ZW5kZWQgU1BJIGFuZCBQUEkgcmFuZ2VzIGFyZSBzdXBwb3J0ZWQuDQo+
IA0KPiBMaW51eCBkcml2ZXIgaGFzIGFuIGV4dHJhIGNoZWNrIGZvciB0aGF0Og0KPiANCj4gIMKg
V0FSTigoZ2ljX2RhdGEucHBpX25yID4gMTYgfHwgR0lDX0VTUElfTlIgIT0gMCkgJiYNCj4gIMKg
IShnaWNfcmVhZF9jdGxyKCkgJiBJQ0NfQ1RMUl9FTDFfRXh0UmFuZ2UpLA0KPiAgwqAiRGlzdHJp
YnV0b3IgaGFzIGV4dGVuZGVkIHJhbmdlcywgYnV0IENQVSVkIGRvZXNuJ3RcbiIsDQo+ICDCoHNt
cF9wcm9jZXNzb3JfaWQoKSk7DQo+IA0KPiBhZGRlZCBieSB0aGUgZm9sbG93aW5nIGNvbW1pdDoN
Cj4gaXJxY2hpcC9naWMtdjM6IFdhcm4gYWJvdXQgaW5jb25zaXN0ZW50IGltcGxlbWVudGF0aW9u
cyBvZiBleHRlbmRlZCByYW5nZXMNCj4gaHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/IA0KPiB1cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGdG9ydmFs
ZHMlMkZsaW51eCUyRmNvbW1pdCUyRmFkNWE3OGQzZGE4MTgzNmM4OGQxZjJkNTMzMTA0ODQ0NjI2
NjA5OTcmZGF0YT0wNSU3QzAyJTdDTGVvbmlkX0tvbWFyaWFuc2t5aSU0MGVwYW0uY29tJTdDOTEw
YmQ5MzViYjRmNDk3ZGYxMmIwOGRkZWJjMDhiMmMlN0NiNDFiNzJkMDRlOWY0YzI2OGE2OWY5NDlm
MzY3YzkxZCU3QzElN0MwJTdDNjM4OTI1OTM0NDA2MDk2OTYzJTdDVW5rbm93biU3Q1RXRnBiR1pz
YjNkOGV5SkZiWEIwZVUxaGNHa2lPblJ5ZFdVc0lsWWlPaUl3TGpBdU1EQXdNQ0lzSWxBaU9pSlhh
VzR6TWlJc0lrRk9Jam9pVFdGcGJDSXNJbGRVSWpveWZRJTNEJTNEJTdDMCU3QyU3QyU3QyZzZGF0
YT1KalhBeDl6MCUyRnJkZjl1bCUyRnY3OWQ3cSUyRnliNE1uOHR3dWlSbHhZUUhFMUhBJTNEJnJl
c2VydmVkPTANCj4gDQo+IA0KPiBXaGF0IGlzIHlvdXIgb3BpbmlvbiwgaXMgaXQgd29ydGggaGF2
aW5nIGEgc2ltaWxhciBjaGVjayBpbiBYZW4/DQo+IA0KPiANCg0KSSB0aGluayB3ZSBjYW4gb21p
dCBhZGRpbmcgc3VjaCBhIHdhcm5pbmcgZm9yIG5vdywgaWYgeW91IGRvbid0IG1pbmQuIEkgDQp3
aWxsIGFuYWx5emUgaXQgaW4gbW9yZSBkZXRhaWwgYW5kIHNlbmQgaXQgYXMgYSBmb2xsb3ctdXAg
cGF0Y2ggbGF0ZXIgaWYgDQpuZWVkZWQuIFdvdWxkIHRoYXQgYmUgb2theSBmb3IgeW91Pw0KDQo+
PiArwqDCoMKgIC8qIFRoZSBHSUMgSFcgZG9lc24ndCBzdXBwb3J0IGVTUEksIHNvIHdlIGNhbiBs
ZWF2ZSBmcm9tIGhlcmUgKi8NCj4+ICvCoMKgwqAgaWYgKCBnaWN2M19pbmZvLm5yX2VzcGkgPT0g
MCApDQo+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuOw0KPj4gKw0KPj4gK8KgwqDCoCBwcmludGso
IkdJQ3YzOiAlZCBlU1BJIGxpbmVzXG4iLCBnaWN2M19pbmZvLm5yX2VzcGkpOw0KPj4gKw0KPiAN
Cj4gDQo+IFtzbmlwXQ0KPiANCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 15:25:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 15:25:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110433.1459646 (Exim 4.92)
	(envelope-from )
	id 1uuBqS-0001kr-Lz; Thu, 04 Sep 2025 15:25:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110433.1459646; Thu, 04 Sep 2025 15:25: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 1uuBqS-0001kk-JR; Thu, 04 Sep 2025 15:25:52 +0000
Received: by outflank-mailman (input) for mailman id 1110433;
 Thu, 04 Sep 2025 15:25: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 1uuBqS-0001ke-1a
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 15:25:52 +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 70443f51-89a3-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 17:25:50 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-45dd513f4ecso2158035e9.3
 for ; Thu, 04 Sep 2025 08:25:50 -0700 (PDT)
Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3da13041bcasm11898450f8f.35.2025.09.04.08.25.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 08:25: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: 70443f51-89a3-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1756999550; x=1757604350; 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=tyHSFAuZBycwb3f9nK3RwRJ9aOJ/KqELn7Qj7AhEtqQ=;
        b=L3R+H+K6GKB4FdXQXyXL+dnOKfDnocGm93ykeAXndA9v+6ucE7D9BT+Dw+bR5H/2yd
         iAJYIO2dDsAAXfYcKvq2dzTJFVpCPi7A1zWfCgNhnqRB0UcxQGy2aHK8cR1jilVUpJTg
         vllU5OHAUfH29+of+cR65g1TiEtG4deEUW9JS+vd/bO+p+zJenIgyJ9+zNkciAYeJGC6
         degULukoUS4RNhPydRaM49rLYYHLZfUKnOXvGBU4t5wO5vdCGcbJUq6BgrovMWX+nRQe
         6gPnGBx+JuEBKp3rPbRk6+zMtlGqZbt6a5y82yQ9UXQhRbjOiwkNrY3AJ1iMeMss0Eay
         Qvgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1756999550; x=1757604350;
        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=tyHSFAuZBycwb3f9nK3RwRJ9aOJ/KqELn7Qj7AhEtqQ=;
        b=wRMYEHdShaQXVgRHecoPro9fXLG8aHE3ig9XdxZ6ganbZcDexGsinp4OMAko/gR+YY
         pSCOawIwmYzb0oxY+xwX80sed5OcP/Y2mrGlvLmak1EnNfIzL4oDj8aO1ne7BpMLQTCO
         v4qT3dvq4BPa35/1Q8ApMQU0dQUvXmslv84VMkHfeeXDRNky1NjiKI7PODPmdAyIm0ai
         pptnDFEa09YzvJyRj3ZbAImr8CU63DXG3Lsq7XHuO9SZKas/Nm8n+/3k5bq8aAXl59LK
         YpLn53U4wqEW5raLqU068j0muDXvO6+a4QlTywUNKbsvLtt/8vcsI91MvqDnKMYgKs5X
         3/vA==
X-Forwarded-Encrypted: i=1; AJvYcCUlwmIMCB5KyYgJPgEWi0nmO7LIeuEnLcGqz1aNwFMYDy5FZQQrZZi9VLEDz6FFb8Yqd4bHTSEdCp4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzUN72xfIBbX94D0Xhx2QPb1Pgfs8XTsI4DPwkNgJwXtLyLjRw0
	H5WGXEc1YLucQ2DzckMkHYvO9EKz0FfgqI+YtYRG/yO9YlivymR7Dyiq
X-Gm-Gg: ASbGncsP7NrPfOJe9F/2OPY5lJn92KL4JhwD73rfyPs5D2+co9PJJ6AohjENqwUWeVl
	yrHTz+9qgDGaMCdn85Uj4t0NXFbDRAW1q88gER+b/ykN2xlff+FImGf+3nPo6i9c4ft2HOykuZ0
	I1aLjgoqh1c63EhtUgFrNBN8+5290JhesyDVu5XaVfvIZ4htobRy6AIzk7HPuVovObvOv5pryzp
	SeqgWuSdYlX73PlxXLscBTrCUr/hRxl/LFj9kWCpi4LLS6E4Q1d3gbRTYyizHjje6GnHdp52u5U
	mMjiDsCTla6pkblDQOVsY31hONM6OKdJFpRncKJKDpW9k7K2gCXlTvqlOZWbg6f9cCPd8AsBqMW
	XMUPodStl0WT6yGDkH6OlJ8GPPFtM/MTD0vhpqIRwhXdBdIUT7Tai/ng=
X-Google-Smtp-Source: AGHT+IEy/Ogm62ztKNU2ZChot8pIxpQhAStH7E9hgq9jmck8bK0njhwd68p4UsBLkNqBDbgWQtGa1g==
X-Received: by 2002:a05:600c:45c9:b0:458:bbed:a81a with SMTP id 5b1f17b1804b1-45b877be05bmr178574555e9.10.1756999549823;
        Thu, 04 Sep 2025 08:25:49 -0700 (PDT)
Message-ID: 
Date: Thu, 4 Sep 2025 18:25:47 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in
 setup_irq()
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 03.09.25 05:55, Mykola Kvach wrote:

Hello Mykola

> From: Mykola Kvach 
> 
> Use GIC_PRI_IPI priority for SGI interrupts instead of the generic
> GIC_PRI_IRQ priority in setup_irq().
> 
> This change ensures that SGIs get the correct priority level when
> being set up for Xen's use, maintaining proper interrupt precedence
> in the system.
> 
> The priority assignment now follows ARM GIC best practices:
> - SGIs (0-15): GIC_PRI_IPI (higher priority)
> - PPIs/SPIs (16+): GIC_PRI_IRQ (standard priority)
> 
> Signed-off-by: Mykola Kvach 

Reviewed-by: Oleksandr Tyshchenko 


> ---
>   xen/arch/arm/irq.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 02ca82c089..17c7ac92b5 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -397,7 +397,13 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
>       /* First time the IRQ is setup */
>       if ( disabled )
>       {
> -        gic_route_irq_to_xen(desc, GIC_PRI_IRQ);
> +        unsigned int prio = GIC_PRI_IRQ;
> +
> +        /* Use appropriate priority based on interrupt type */
> +        if (desc->irq < NR_GIC_SGI)
> +            prio = GIC_PRI_IPI;
> +
> +        gic_route_irq_to_xen(desc, prio);
>           /* It's fine to use smp_processor_id() because:
>            * For SGI and PPI: irq_desc is banked
>            * For SPI: we don't care for now which CPU will receive the



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 15:35:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 15:35:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110448.1459658 (Exim 4.92)
	(envelope-from )
	id 1uuBzN-0003Oq-Bv; Thu, 04 Sep 2025 15:35:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110448.1459658; Thu, 04 Sep 2025 15:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuBzN-0003Oj-7V; Thu, 04 Sep 2025 15:35:05 +0000
Received: by outflank-mailman (input) for mailman id 1110448;
 Thu, 04 Sep 2025 15: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 1uuBzM-0003Od-IL
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 15:35:04 +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 b82d3b83-89a4-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 17:35:00 +0200 (CEST)
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20)
 by AS8PR03MB7191.eurprd03.prod.outlook.com (2603:10a6:20b:2ee::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 15:34:58 +0000
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9094.016; Thu, 4 Sep 2025
 15:34:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b82d3b83-89a4-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HB4PqirXBvr4jV6199cztenbqRaFuFN2UgFKIYfqyAENvc24oWBCc96PqMhzXyUF4/1pX4EAI6fHasNJu5OlxNxxxuznluYVdavSCzRu6Tt00ZaKr9h63mhjo+fgDWXb7uRNWF1Zt0lbWviI7jCfmet7lGTK6epxGWPjkP9s4T39JjaUzPkGcKYAC3udiTvYOlGt7mvfX1T8wI0T3WtfF6f0ImCoQ1qsiAdeDCwsTFWnnHfk8YYhuMX4jMZJZ2uILbN2nU26jqbFBxySeKSwqKrfsjPu2RaCIo856gjiVPtkTrEw9Yu3MS6dEcckNfNNU3WaSnkoEzI7ZC/QZhhulw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yPZJXb86pby2xPb/ULlnxu8WbrCi5ODEpl2dYxBp7U4=;
 b=v5RWcEBa0e8JXrkTH3LQWE0PSn17najBop4QcYDQQ0utpiA7vtDv34/1VQfCyXZyx3Vv6FGWwWXEUGaJQNaWDiSaOHGJGqOvD/wxGLQO9dJVd0zsAxLH5RbDRHhfZ1hz2arLSLvIp400zjvJ8Q9anYSx5LzGXQ/u+TzXIGILwD/qIzBPuElDn4twHIHIDTnPrHB0eBk00UNkexYJoxofGmP0fWoPzDZrkdrVw+ve6tnRQHQAzJ3z9CPH7Dwdp7bt8S9aUsya05yy3mTa6yk5qXk10q0qOUyqRiSkUf8NNagTIj8+dgCeBWMuMcHF4RNWg8BU6d0Wbnp8BZEsNLXgGg==
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=yPZJXb86pby2xPb/ULlnxu8WbrCi5ODEpl2dYxBp7U4=;
 b=aD5Xl0/PFyz8Nr/F2NdUdce5yqhn+lh2rEqqd5YqEKYaC+R2aTfhXhep0Io0JsA7jfZwyNGM2kg0c6UkQuNmIsvUFjPlg1fpfoq0P1PQxHkfuj0SN5UawXLmTkPsM2dkhY7L0AOTNoUDa56H367Dy0qxLlwLxhf43K2VgGlr4H2O49EO72iCy/QSzg9KXM6hIHrczBwWZMrSqynawR1HLeNgDIOFwotqTlWM1dWc0e7s3tSCvTmbko/hNbciGqJdwQAasnttFhThjvpqFyKnmL1NU4eNmqz3fP786ER5An3ircMQwVOTMIyDCQVhcWuqxr5lrTn3ADfX2QjmMyXnhQ==
From: Oleksandr Tyshchenko 
To: Leonid Komarianskyi , Oleksandr Tyshchenko
	, "xen-devel@lists.xenproject.org"
	
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
Subject: Re: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Topic: [PATCH v6 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Index: AQHcHN88f5Lxm2g89kebOYUIBUtDZbSDGQ4AgAAJKYCAAAb0AA==
Date: Thu, 4 Sep 2025 15:34:58 +0000
Message-ID: 
References: 
 
 
 <9b6e873d-e96f-49a9-9d64-b03a2493d6bc@epam.com>
In-Reply-To: <9b6e873d-e96f-49a9-9d64-b03a2493d6bc@epam.com>
Accept-Language: en-US, 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: AM9PR03MB7025:EE_|AS8PR03MB7191:EE_
x-ms-office365-filtering-correlation-id: e8ca0607-8091-4bef-17f9-08ddebc89b25
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|366016|1800799024|42112799006|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?YUI3TFJVR0x2MnBDb3FQd1ZVcnFQMmxEcjgxREJic2FLRVBzZkFyazNob1Zu?=
 =?utf-8?B?WjdXMWdmQnBQaGVuaVdLZlhGdnB4SHRJdzdwQXpPNDRtdDBFMjNERGUyUnA4?=
 =?utf-8?B?Z3U2OXROeW1qVXNzMUs2cDluQ1dxMGNQNlg3aFlTQndPbG43dW4vajdtUXoy?=
 =?utf-8?B?bDV1blg2bUUwZkx6cEtBeDFwWG9nSGxXNTY2eU1CaWZRVW5ycnhCNzhKTDcz?=
 =?utf-8?B?Nzk2dzZObUpwM3FCaEJVdnhEWWZKNlBFTXlRR29ERmZWRmM3Ukd6OG5LUlBx?=
 =?utf-8?B?M2lKSjdnK21PK2Y4bWZncXBZMWNSZUtzdU1SOGFJL2ROQlZJOFhOb3dIbDJ1?=
 =?utf-8?B?anlXck0yeTZpR3F6ZmkyWktGbFk3TFV2NUY3SHZkRkl3VThKa2dMckNPcmlO?=
 =?utf-8?B?c2M3RkM4WnQrN2JaL05LMHJWUUNIN25yM3EwWFV2cm9mUWJyUStFZlJZdVJa?=
 =?utf-8?B?R0czNHNZeXNNYjlpT2txZzBaWXBGSlRqL2ludlNxNG1xZ2xjeGs0YnVPVE9T?=
 =?utf-8?B?Qzh3ckZnRU9CUmx4ZmxhaXUzNDlMMnA0VHVwaWhyeEIzYXZ4M25qaXhrSlpQ?=
 =?utf-8?B?YlJLTWdqd3Q4SmNua3IvOU5uT1NMY2tUZGVsTXFSRjhpMW44anorSHFPN21j?=
 =?utf-8?B?L0ozRC9VeXgwK3A3RGhJek5YYmJBUjk0ZG9TVFN4ejVFWkozYkpwNU5KZXk0?=
 =?utf-8?B?cjluUXFLNGlrR3NYcHg5SzlNOGZHS1NNSDJUbDgwMFJqeTVPZmpTSERob3NW?=
 =?utf-8?B?TkNVaVUxblpiY2dWUXZJam1udkY5RUV3cEFHOTkzek5QZ2VRNVR0cWEwdEs0?=
 =?utf-8?B?S1JLYWswMG96ZVluN1NKOEVpTVpFYkhWYW9PaCtTZm5wRDk1OFNiMzY0a2xt?=
 =?utf-8?B?bTRsMjd5NVlGU0c1bjdhQmg4MUNYZm5rMFBnQlhDVkdXSmtVcjMvc3gzakNj?=
 =?utf-8?B?KzlPUHQ1Z1NNTkdnWllySVlzRjZEeTFYUTBrbHNsU0hzc0FOSmcrb1pURXJ4?=
 =?utf-8?B?cUdIZ1lRWmhKay9VOHVCcnNrMFB5TlJxTGw1eGNhSHlXSjRJSFg3Rlk1Vzl0?=
 =?utf-8?B?UXhTVmxRblVESGxHTVNVcmcxMTlCSXpvY0g4c2VjOTF0OEg4aEEybVlQRjJW?=
 =?utf-8?B?WkRmd3ZxNHVaVEVTZ1g3NmNnVnhOTis2ci8yY2NKTTJBVlYxM1JqQkVQYVN0?=
 =?utf-8?B?WUNqRXVXZklkK3p0aGNTR3RuWGQwTklnazMzeldxRlQzUk9EdnhyMlpiM3Nn?=
 =?utf-8?B?WWRFSkYxdEZLdDIrczBBYnJxdEhYSjFIR0hDek5Fc0Q5dm9Kckw5NitiYit2?=
 =?utf-8?B?eUFiQ0ZrUm5QVGZuc2s5eDRlQTlWdi9ndDYzN0dEN09DSFE0RTNNZE1YdjYz?=
 =?utf-8?B?YjB4NjlRY3ByQnp4OGR5REI2U2Q0bWtQekl1MG9yV3AvdElrdTUxZk9nZ2FH?=
 =?utf-8?B?WmRLek1PaUEzYndON3ZCODl1NHZLWFVpdEhPNlY4ckwrazZ5K3B6dHlURW4v?=
 =?utf-8?B?SWIxN1hhWDVLZEQzNFlDOHFnOExRL1lOYXFPaS9Hc1dGdGlhYkowWjVXTTVh?=
 =?utf-8?B?WGJGTExyb1JDMkdLejlPWGErVWNOdmJXdDBuek1rUnlRZUZjclZxVFdmN3JO?=
 =?utf-8?B?YWluYWM5MVlONW9NTHJMNlEyUkJDK2JPd2kzTE1Pdy9pRXRNTU1ldzRMaCs2?=
 =?utf-8?B?Mm8vME5CcHo3aDc2NEViYkNVRDUwL3FJTXRaaEx4MnAreFJya1VHVml1RXI4?=
 =?utf-8?B?eTlhUWdmaXpIRGdZYXl4QWdJeVVQNEUzNDROMDlLOVR6cGVkSGdmY2JHUWd0?=
 =?utf-8?B?WXRvNUV0TUdZcHFNd3FSUDNJUUJKV1NaZFBzeXBVMXgxK0dxWVNJeWNlNjhT?=
 =?utf-8?B?K0RIWHdnV08xSEJmMldNei9zUzlYd2orOUNYR01NWlFTZXZPdkNDWUVnMmx3?=
 =?utf-8?Q?cSFHnEHpeeY=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(42112799006)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?QkdjRmFrNktNWDVEUEd4SGdTdXhMMDlBaUNPeGdZWnc2eEtpNzhoZ0NhOUgx?=
 =?utf-8?B?S0kyN1UzOTk4SWV6UEVsNmdpMnhIOEV0OEpuUGxNejd2L1JacVgrOGhVV1h1?=
 =?utf-8?B?UXdSRThzUHJvRnlnMFpDUlZmMGI3UEpHT0w5RVhpOS9Ba0k4UUpkZUo1bVJz?=
 =?utf-8?B?RnVrWHh3ekFIZytWcDUxTDR1dUtoekJGVjhNS2JTZ0sraFNUQkhmeVltMUlq?=
 =?utf-8?B?M0pCQnY2cjhheWNsK0J4QTRkUUhYV3JCUmgyeXkyZFJZTlo5MzNJSTNWNXh6?=
 =?utf-8?B?S2d0MURMZEhKYVBVSmxSYTR5b25GT2tzYmRHWEdLQzU1dWpYU0wzMWVzYkhH?=
 =?utf-8?B?cENVVG9lWnY5T3hBbW5vY092ZUV0MHMyUEdYcSs2cUNNT1B1a3pGbE5SenpP?=
 =?utf-8?B?QWVrYjcxa2JDSmZ5NVVIcnM5Q2M2cnpubEVZdTVadWtZNXU0anlRRmZQVUt0?=
 =?utf-8?B?WUV2SjFhcFhmSXdiTU5aRyt4OS9kWDFsbXNiYUhlSS9TTlZyMEx5aGZhWHpX?=
 =?utf-8?B?Q3VNT0lYOWxBRmNBc2VuZUJnRnRiamJHczArcThaekwyNEZmak0rQnlUVjdV?=
 =?utf-8?B?N3Bxd2hhdlF1MWdHb09tVmZ1SENLVWZxZW1oZGY5bDZkbFNkK3VjYW9IY015?=
 =?utf-8?B?SjVFL1BuYndvRmNhQ3dQR3RrMWxtT0tzdWMxcjFxVWtadVVtVEVzMDhhMTJs?=
 =?utf-8?B?ZEVidTE3aXM4MnhiOE9CRGc1ZWp3RXFxOEhwUXFJcjllSFpyRzN2US9hS3d4?=
 =?utf-8?B?Z25Wb2cyblNYQUtieEhLZDN6UkZEUzlFOVJMcEFvNnVWbktQQlBldGhsa2VY?=
 =?utf-8?B?aUtVVzV5RFZzMmZlaHFnMXhzR0h6MnlCQTlIcEJkSko0b0NBRUQ3M0ZqZjlG?=
 =?utf-8?B?eWwyV1RoNTl1ZzlxREM5RHM2T2ZRVHpmSVpQclUwZ3U3endQRU1wSVhLZjVE?=
 =?utf-8?B?S3JWZHNQTVdRZWtKMllDcnk3YUFpcExMN0NoU1ZVdk9LKzY3K0NBSUFiT1dU?=
 =?utf-8?B?VkU2b3lkVTBySE1reUVISFVXNUpXUURJbzNseTByL0pocFZrNmlaL29jNUl4?=
 =?utf-8?B?STNUUHJjWFRZSTIvR0NUaTc1Y2EzbE53MmlvRjZwVVEyWmxaS3h6ZmZQV2hV?=
 =?utf-8?B?L0pYU2NnbzFRSU9XRkloT1Q2VitWb1VqWG9nU3RmVHl0QWJRQzFmUit5ZGNO?=
 =?utf-8?B?V3VuS3dDN3dyVFJXU1BKREtrMkxxS3N3bW8zVDB1R3RKaW9UVVNyb3lIRTlH?=
 =?utf-8?B?eGF2YlJaa2xFNDNST1k2SWdiRDZacVBuSkxyM1p6NjQ4MjFYckNUZnBUT29K?=
 =?utf-8?B?a1dYaDJwZVNSQStCYzRjU05ZakFBY2t1WjlvcjRYSEloOEJ2RytsUzUxRCtQ?=
 =?utf-8?B?VkxJV1VNcjVnWTQrV0xiaVdyOXpJZy96ODd2dlYvNVdabHBIdFErWlVXTXY4?=
 =?utf-8?B?VnJrTEwyU1pZa2wreGFXZzREOTl5bkF0bUFvQi9nYUZscnRrN3VJY1VWSVo1?=
 =?utf-8?B?djBPUm40WjlpZDJzdEVrZFBCZWhqVS8xZFozampuZTcvYWZ4aWNRNG1rV1Bs?=
 =?utf-8?B?MlNGQms4QXFvUDhOSk0wN041LzhzZ29jdDFNcmg2Skk1NUJNNVBKNEtNUkl0?=
 =?utf-8?B?Q0hHTWF6TndNekdZM3Nxa0VDL2lqWDFZY25KbXhFSGZGNnUvc1lxUmt4dnRG?=
 =?utf-8?B?T1krZnpvZ2VjakVHQVAyaVVSbUh3TWZsQ3psWU1IWENpSXpoOTRFODFEU25s?=
 =?utf-8?B?N1hFVDdFdURJMWUxTUd5ZVJmWWVTeWwzaVNmeDkydUx4WjBuYVdpMGcyZ29V?=
 =?utf-8?B?WnlNSDY3bWtqeURNZFdWbkRhMnN0REpnSGszdlpSVS9UbmZra0xPQkYwUVl5?=
 =?utf-8?B?YUExeVVWN2MxVm5jNGtxbUFlUTR4QVRocnVSbEltQVZGU3htMHV5bG1kVFox?=
 =?utf-8?B?VlNic2YydC8ySlg4NXRNMEE1ZTJyYzU2bFdRMnRzVTFVdjhDVXN6OUFMeWpR?=
 =?utf-8?B?KzE1cEtPa1ZVOW1hODg4TEZDSDdUMzBXS0liUjBKQTFxYW1nV2lZMGQwODN4?=
 =?utf-8?B?NzhZcHhSVmhESVhLUjBJaXo5TjUyQXpwTHhIYy8yVkxrVzFwUFBiQmVMc3A0?=
 =?utf-8?B?N09KRXVyTDlhc04xcllQaXJJYUc5eXhKR2NvOEVpTHdxeGI2cFpRM0EycEk2?=
 =?utf-8?Q?wKVOYhnghQ6yPMIEW9yAkag=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <58FD6FAA3764E14B812AE60F43260F8A@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: AM9PR03MB7025.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e8ca0607-8091-4bef-17f9-08ddebc89b25
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 15:34:58.5228
 (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: yfNZIj4NR0POlpdy8rftkzwcgvc+EbYJCqhmrS6FbvXrisosK+CELA1MPhKod4rlnqvooHKhdaiqXCDSuA/qjP9hkHwk2uSs58OUmdJS+70=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7191

DQoNCk9uIDA0LjA5LjI1IDE4OjEwLCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0KPiBIZWxs
byBPbGVrc2FuZHIsDQoNCkhlbGxvIExlb25pZA0KDQo+IA0KPiBUaGFuayB5b3UgZm9yIHlvdXIg
Y29tbWVudC4NCj4gDQo+IE9uIDA0LjA5LjI1IDE3OjM3LCBPbGVrc2FuZHIgVHlzaGNoZW5rbyB3
cm90ZToNCj4+DQo+Pg0KPj4gT24gMDMuMDkuMjUgMTc6MzAsIExlb25pZCBLb21hcmlhbnNreWkg
d3JvdGU6DQo+Pg0KPj4gSGVsbG8gTGVvbmlkDQo+Pg0KPj4NCj4+PiBJbnRyb2R1Y2VkIGFwcHJv
cHJpYXRlIHJlZ2lzdGVyIGRlZmluaXRpb25zLCBoZWxwZXIgbWFjcm9zLA0KPj4+IGFuZCBpbml0
aWFsaXphdGlvbiBvZiByZXF1aXJlZCBHSUN2My4xIGRpc3RyaWJ1dG9yIHJlZ2lzdGVycw0KPj4+
IHRvIHN1cHBvcnQgZVNQSS4gVGhpcyB0eXBlIG9mIGludGVycnVwdCBpcyBoYW5kbGVkIGluIHRo
ZQ0KPj4+IHNhbWUgd2F5IGFzIHJlZ3VsYXIgU1BJIGludGVycnVwdHMsIHdpdGggdGhlIGZvbGxv
d2luZw0KPj4+IGRpZmZlcmVuY2VzOg0KPj4+DQo+Pj4gMSkgZVNQSXMgY2FuIGhhdmUgdXAgdG8g
MTAyNCBpbnRlcnJ1cHRzLCBzdGFydGluZyBmcm9tIHRoZQ0KPj4+IGJlZ2lubmluZyBvZiB0aGUg
cmFuZ2UsIHdoZXJlYXMgcmVndWxhciBTUElzIHVzZSBJTlRJRHMgZnJvbQ0KPj4+IDMyIHRvIDEw
MTksIHRvdGFsaW5nIDk4OCBpbnRlcnJ1cHRzOw0KPj4+IDIpIGVTUElzIHN0YXJ0IGF0IElOVElE
IDQwOTYsIG5lY2Vzc2l0YXRpbmcgYWRkaXRpb25hbCBpbnRlcnJ1cHQNCj4+PiBpbmRleCBjb252
ZXJzaW9uIGR1cmluZyByZWdpc3RlciBvcGVyYXRpb25zLg0KPj4+DQo+Pj4gSW4gY2FzZSBpZiBh
cHByb3ByaWF0ZSBjb25maWcgaXMgZGlzYWJsZWQsIG9yIEdJQyBIVyBkb2Vzbid0DQo+Pj4gc3Vw
cG9ydCBlU1BJLCB0aGUgZXhpc3RpbmcgZnVuY3Rpb25hbGl0eSB3aWxsIHJlbWFpbiB0aGUgc2Ft
ZS4NCj4+Pg0KPj4+IFNpZ25lZC1vZmYtYnk6IExlb25pZCBLb21hcmlhbnNreWkgPGxlb25pZF9r
b21hcmlhbnNreWlAZXBhbS5jb20+DQo+Pj4gUmV2aWV3ZWQtYnk6IE9sZWtzYW5kciBUeXNoY2hl
bmtvIDxvbGVrc2FuZHJfdHlzaGNoZW5rb0BlcGFtLmNvbT4NCj4+Pg0KPj4+IC0tLQ0KPj4+IENo
YW5nZXMgaW4gVjY6DQo+Pj4gLSByZW1vdmVkIHVubmVjZXNzYXJ5IHBhcmVudGhlc2VzIGluIGdp
Y19pc192YWxpZF9lc3BpKCkNCj4+PiAtIHVwZGF0ZWQgZ2ljX2lzX3ZhbGlkX2xpbmUoKTogaXQg
bm93IHZlcmlmaWVzIHRoZSBjb25kaXRpb24gaXJxIDwNCj4+PiAgwqDCoCBnaWNfbnVtYmVyX2xp
bmVzKCkgZmlyc3QsIGFzIGl0IGlzIG1vcmUgbGlrZWx5IHRoYXQgdGhlIGlycSBudW1iZXINCj4+
PiAgwqDCoCB3aWxsIGJlIGZyb20gdGhlIG5vbi1lU1BJIHJhbmdlDQo+Pj4gLSBtaW5vciBjaGFu
Z2U6IGNoYW5nZWQgdGhlIG1hY3JvcyBFU1BJX0lOVElEMklEWCBhbmQgRVNQSV9JRFgySU5USUQN
Cj4+PiAgwqDCoCBpbnRvIGFwcHJvcHJpYXRlIGlubGluZSBmdW5jdGlvbnMgaW50cm9kdWNlZCBp
biB0aGUgcHJldmlvdXMgcGF0Y2gNCj4+PiAtIGFkZGVkIHJldmlld2VkLWJ5IGZyb20gT2xla3Nh
bmRyIFR5c2hjaGVua28NCj4+Pg0KPj4+IENoYW5nZXMgaW4gVjU6DQo+Pj4gLSBmaXhlZCBtaW5v
ciBuaXRzLCBubyBmdW5jdGlvbmFsIGNoYW5nZXM6IGNoYW5nZWQgdTMyIHRvIHVpbnQzMl90IGFu
ZA0KPj4+ICDCoMKgIGFkZGVkIGEgY29tbWVudCBub3RpbmcgdGhhdCB0aGUgY29uZmlndXJhdGlv
biBmb3IgZVNQSXMgaXMgdGhlIHNhbWUgYXMNCj4+PiAgwqDCoCBmb3IgcmVndWxhciBTUElzDQo+
Pj4gLSByZW1vdmVkIGlmZGVmcyBmb3IgZVNQSS1zcGVjaWZpYyBvZmZzZXRzIHRvIHJlZHVjZSB0
aGUgbnVtYmVyIG9mDQo+Pj4gIMKgwqAgaWZkZWZzIGFuZCBjb2RlIGR1cGxpY2F0aW9uIGluIGZ1
cnRoZXIgY2hhbmdlcw0KPj4+IC0gcmVtb3ZlZCByZXZpZXdlZC1ieSBhcyBtb3Zpbmcgb2Zmc2V0
IGZyb20gaWZkZWZzIHJlcXVpcmVzIGFkZGl0aW9uYWwNCj4+PiAgwqDCoCBjb25maXJtYXRpb24g
ZnJvbSByZXZpZXdlcnMNCj4+Pg0KPj4+IENoYW5nZXMgaW4gVjQ6DQo+Pj4gLSBhZGRlZCBvZmZz
ZXRzIGZvciBHSUNEX0lHUlBNT0RSbkUgYW5kIEdJQ0RfTlNBQ1JuRSB0aGF0IGFyZSByZXF1aXJl
ZA0KPj4+ICDCoMKgIGZvciB2R0lDIGVtdWxhdGlvbg0KPj4+IC0gYWRkZWQgYSBsb2cgYmFubmVy
IHdpdGggZVNQSSBpbmZvcm1hdGlvbiwgc2ltaWxhciB0byB0aGUgb25lIGZvcg0KPj4+ICDCoMKg
IHJlZ3VsYXIgU1BJDQo+Pj4gLSBhZGRlZCBuZXdsaW5lIGFmdGVyIGlmZGVmIGFuZCBiZWZvcmUg
Z2ljX2lzX3ZhbGlkX2xpbmUNCj4+PiAtIGFkZGVkIHJldmlld2VkLWJ5IGZyb20gVm9sb2R5bXly
IEJhYmNodWsNCj4+Pg0KPj4+IENoYW5nZXMgaW4gVjM6DQo+Pj4gLSBhZGQgX19pbml0IGF0dHJp
YnV0ZSB0byBnaWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQNCj4+PiAtIGNoYW5nZSBvcGVuLWNv
ZGRlZCBlU1BJIHJlZ2lzdGVyIGluaXRpYWxpemF0aW9uIHRvIHRoZSBhcHByb3ByaWF0ZQ0KPj4+
ICDCoMKgIGdlbi1tYXNrIG1hY3JvDQo+Pj4gLSBmaXhlZCBmb3JtYXR0aW5nIGZvciBsaW5lcyB3
aXRoIG1vcmUgdGhhbiA4MCBzeW1ib2xzDQo+Pj4gLSBpbnRyb2R1Y2VkIGdpY3YzX2Rpc3RfZXNw
aV9pbml0X2FmZiB0byBiZSBhYmxlIHRvIHVzZSBzdHVicyBpbiBjYXNlIG9mDQo+Pj4gIMKgwqAg
Q09ORklHX0dJQ1YzX0VTUEkgZGlzYWJsZWQNCj4+PiAtIHJlbmFtZWQgcGFyYW1ldGVyIGluIHRo
ZSBHSUNEX1RZUEVSX0VTUElfUkFOR0UgbWFjcm8gdG8gZXNwaV9yYW5nZQ0KPj4+ICDCoMKgIChu
YW1lIHdhcyB0YWtlbiBmcm9tIEdJQyBzcGVjaWZpY2F0aW9uKSB0byBhdm9pZCBjb25mdXNpb24N
Cj4+PiAtIGNoYW5nZWQgdHlwZSBmb3IgaSB2YXJpYWJsZSB0byB1bnNpZ25lZCBpbnQgc2luY2Ug
aXQgY2Fubm90IGJlDQo+Pj4gIMKgwqAgbmVnYXRpdmUNCj4+Pg0KPj4+IENoYW5nZXMgaW4gVjI6
DQo+Pj4gLSBtb3ZlIGdpY19udW1iZXJfZXNwaXMgZnVuY3Rpb24gZnJvbQ0KPj4+ICDCoMKgIFtQ
QVRDSCAwOC8xMF0geGVuL2FybTogdmdpYzogYWRkIHJlc291cmNlIG1hbmFnZW1lbnQgZm9yIGV4
dGVuZGVkIFNQSXMNCj4+PiAgwqDCoCB0byB1c2UgaXQgaW4gdGhlIG5ld2x5IGludHJvZHVjZWQg
Z2ljX2lzX3ZhbGlkX2VzcGkNCj4+PiAtIGFkZCBnaWNfaXNfdmFsaWRfZXNwaSB3aGljaCBjaGVj
a3MgaWYgSVJRIG51bWJlciBpcyBpbiBzdXBwb3J0ZWQNCj4+PiAgwqDCoCBieSBIVyBlU1BJIHJh
bmdlDQo+Pj4gLSB1cGRhdGUgZ2ljX2lzX3ZhbGlkX2lycSBjb25kaXRpb25zIHRvIGFsbG93IG9w
ZXJhdGlvbnMgd2l0aCBlU1BJcw0KPj4+IC0tLQ0KPj4+ICDCoCB4ZW4vYXJjaC9hcm0vZ2ljLXYz
LmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgODMgKysrKysrKysrKysrKysr
KysrKysrKysrKysNCj4+PiAgwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpYy5owqDCoMKg
wqDCoMKgwqDCoCB8IDIxICsrKysrKy0NCj4+PiAgwqAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNt
L2dpY192M19kZWZzLmggfCAzOCArKysrKysrKysrKysNCj4+PiAgwqAgMyBmaWxlcyBjaGFuZ2Vk
LCAxNDEgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL2FybS9naWMtdjMuYyBiL3hlbi9hcmNoL2FybS9naWMtdjMuYw0KPj4+IGluZGV4
IGExZTMwMmZlYTIuLmE2OTI2M2U0NjEgMTAwNjQ0DQo+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2dp
Yy12My5jDQo+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2dpYy12My5jDQo+Pj4gQEAgLTQ4NSw2ICs0
ODUsMzYgQEAgc3RhdGljIHZvaWQgX19pb21lbSAqZ2V0X2FkZHJfYnlfb2Zmc2V0KHN0cnVjdA0K
Pj4+IGlycV9kZXNjICppcnFkLCB1aW50MzJfdCBvZmZzZXQpDQo+Pj4gIMKgwqDCoMKgwqDCoMKg
wqDCoCBkZWZhdWx0Og0KPj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+
PiAgwqDCoMKgwqDCoMKgwqDCoMKgIH0NCj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+
Pj4gK8KgwqDCoCBjYXNlIEVTUElfQkFTRV9JTlRJRCAuLi4gRVNQSV9NQVhfSU5USUQ6DQo+Pj4g
K8KgwqDCoCB7DQo+Pj4gK8KgwqDCoMKgwqDCoMKgIHVpbnQzMl90IGlycV9pbmRleCA9IGVzcGlf
aW50aWRfdG9faWR4KGlycWQtPmlycSk7DQo+Pj4gKw0KPj4+ICvCoMKgwqDCoMKgwqDCoCBzd2l0
Y2ggKCBvZmZzZXQgKQ0KPj4+ICvCoMKgwqDCoMKgwqDCoCB7DQo+Pj4gK8KgwqDCoMKgwqDCoMKg
IGNhc2UgR0lDRF9JU0VOQUJMRVI6DQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJu
IChHSUNEICsgR0lDRF9JU0VOQUJMRVJuRSArIChpcnFfaW5kZXggLyAzMikgKiA0KTsNCj4+PiAr
wqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lDRU5BQkxFUjoNCj4+PiArwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBHSUNEX0lDRU5BQkxFUm5FICsgKGlycV9pbmRleCAvIDMy
KSAqIDQpOw0KPj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVNQRU5EUjoNCj4+PiArwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBHSUNEX0lTUEVORFJuRSArIChpcnFf
aW5kZXggLyAzMikgKiA0KTsNCj4+PiArwqDCoMKgwqDCoMKgwqAgY2FzZSBHSUNEX0lDUEVORFI6
DQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIChHSUNEICsgR0lDRF9JQ1BFTkRS
bkUgKyAoaXJxX2luZGV4IC8gMzIpICogNCk7DQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGNhc2UgR0lD
RF9JU0FDVElWRVI6DQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIChHSUNEICsg
R0lDRF9JU0FDVElWRVJuRSArIChpcnFfaW5kZXggLyAzMikgKiA0KTsNCj4+PiArwqDCoMKgwqDC
oMKgwqAgY2FzZSBHSUNEX0lDQUNUSVZFUjoNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBy
ZXR1cm4gKEdJQ0QgKyBHSUNEX0lDQUNUSVZFUm5FICsgKGlycV9pbmRleCAvIDMyKSAqIDQpOw0K
Pj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSUNGR1I6DQo+Pj4gK8KgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgcmV0dXJuIChHSUNEICsgR0lDRF9JQ0ZHUm5FICsgKGlycV9pbmRleCAvIDE2KSAq
IDQpOw0KPj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVJPVVRFUjoNCj4+PiArwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBHSUNEX0lST1VURVJuRSArIGlycV9pbmRl
eCAqIDgpOw0KPj4+ICvCoMKgwqDCoMKgwqDCoCBjYXNlIEdJQ0RfSVBSSU9SSVRZUjoNCj4+PiAr
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gKEdJQ0QgKyBHSUNEX0lQUklPUklUWVJuRSAr
IGlycV9pbmRleCk7DQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGRlZmF1bHQ6DQo+Pj4gK8KgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgYnJlYWs7DQo+Pj4gK8KgwqDCoMKgwqDCoMKgIH0NCj4+PiArwqDCoMKg
IH0NCj4+PiArI2VuZGlmDQo+Pj4gIMKgwqDCoMKgwqAgZGVmYXVsdDoNCj4+PiAgwqDCoMKgwqDC
oMKgwqDCoMKgIGJyZWFrOw0KPj4+ICDCoMKgwqDCoMKgIH0NCj4+PiBAQCAtNjU1LDYgKzY4NSw1
NSBAQCBzdGF0aWMgdm9pZCBnaWN2M19zZXRfaXJxX3ByaW9yaXR5KHN0cnVjdA0KPj4+IGlycV9k
ZXNjICpkZXNjLA0KPj4+ICDCoMKgwqDCoMKgIHNwaW5fdW5sb2NrKCZnaWN2My5sb2NrKTsNCj4+
PiAgwqAgfQ0KPj4+ICsjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCj4+PiArdW5zaWduZWQgaW50
IGdpY19udW1iZXJfZXNwaXModm9pZCkNCj4+PiArew0KPj4+ICvCoMKgwqAgcmV0dXJuIGdpY19o
d19vcHMtPmluZm8tPm5yX2VzcGk7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyB2b2lkIF9f
aW5pdCBnaWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQodWludDMyX3QgdHlwZSkNCj4+PiArew0K
Pj4+ICvCoMKgwqAgdW5zaWduZWQgaW50IGVzcGlfbnIsIGk7DQo+Pj4gKw0KPj4+ICvCoMKgwqAg
ZXNwaV9uciA9IG1pbigxMDI0VSwgR0lDRF9UWVBFUl9FU1BJU19OVU0odHlwZSkpOw0KPj4+ICvC
oMKgwqAgZ2ljdjNfaW5mby5ucl9lc3BpID0gZXNwaV9ucjsNCj4+DQo+Pg0KPj4gU29ycnksIEkg
aGF2ZSBqdXN0IG5vdGljZWQgb25lIHRoaW5nLCBhbmQgZ2ljdjNfY3B1X2luaXQoKSBwcm9iYWJs
eQ0KPj4gd291bGQgYmUgYSBtb3JlIGNvcnJlY3QgcGxhY2UgdG8gd3JpdGUgYWJvdXQgaXQsIGJ1
dCBzaW5jZSB5b3UgZG9uJ3QNCj4+IG1vZGlmeSB0aGF0IGZ1bmN0aW9uIChpdCBpcyBub3Qgdmlz
aWJsZSBpbiB0aGUgY29udGV4dCksIHNvIHdyaXRpbmcgaGVyZToNCj4+DQo+PiAgIEZyb20gIkFy
bSBJSEkgMDA2OUguYiAoSUQwNDEyMjQpIg0KPj4gMTAuMS4yIEdJQ3YzLjEgZXh0ZW5kZWQgSU5U
SUQgcmFuZ2Ugc3VwcG9ydA0KPj4NCj4+IE5vdGUNCj4+IEFybSByZWNvbW1lbmRzIHRoYXQgQXJt
djgtUiBBQXJjaDY0IFBFcyByZXBvcnQgSUNDX0NUTFJfRUwxLkV4dFJhbmdlPT0xLA0KPj4gaW5k
aWNhdGluZyB0aGF0IHRoZSBHSUN2My4xIGV4dGVuZGVkIFNQSSBhbmQgUFBJIHJhbmdlcyBhcmUg
c3VwcG9ydGVkLg0KPj4NCj4+IExpbnV4IGRyaXZlciBoYXMgYW4gZXh0cmEgY2hlY2sgZm9yIHRo
YXQ6DQo+Pg0KPj4gICDCoFdBUk4oKGdpY19kYXRhLnBwaV9uciA+IDE2IHx8IEdJQ19FU1BJX05S
ICE9IDApICYmDQo+PiAgIMKgIShnaWNfcmVhZF9jdGxyKCkgJiBJQ0NfQ1RMUl9FTDFfRXh0UmFu
Z2UpLA0KPj4gICDCoCJEaXN0cmlidXRvciBoYXMgZXh0ZW5kZWQgcmFuZ2VzLCBidXQgQ1BVJWQg
ZG9lc24ndFxuIiwNCj4+ICAgwqBzbXBfcHJvY2Vzc29yX2lkKCkpOw0KPj4NCj4+IGFkZGVkIGJ5
IHRoZSBmb2xsb3dpbmcgY29tbWl0Og0KPj4gaXJxY2hpcC9naWMtdjM6IFdhcm4gYWJvdXQgaW5j
b25zaXN0ZW50IGltcGxlbWVudGF0aW9ucyBvZiBleHRlbmRlZCByYW5nZXMNCj4+IGh0dHBzOi8v
ZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vPw0KPj4gdXJsPWh0dHBzJTNB
JTJGJTJGZ2l0aHViLmNvbSUyRnRvcnZhbGRzJTJGbGludXglMkZjb21taXQlMkZhZDVhNzhkM2Rh
ODE4MzZjODhkMWYyZDUzMzEwNDg0NDYyNjYwOTk3JmRhdGE9MDUlN0MwMiU3Q0xlb25pZF9Lb21h
cmlhbnNreWklNDBlcGFtLmNvbSU3QzkxMGJkOTM1YmI0ZjQ5N2RmMTJiMDhkZGViYzA4YjJjJTdD
YjQxYjcyZDA0ZTlmNGMyNjhhNjlmOTQ5ZjM2N2M5MWQlN0MxJTdDMCU3QzYzODkyNTkzNDQwNjA5
Njk2MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpGYlhCMGVVMWhjR2tpT25SeWRXVXNJbFlp
T2lJd0xqQXVNREF3TUNJc0lsQWlPaUpYYVc0ek1pSXNJa0ZPSWpvaVRXRnBiQ0lzSWxkVUlqb3lm
USUzRCUzRCU3QzAlN0MlN0MlN0Mmc2RhdGE9SmpYQXg5ejAlMkZyZGY5dWwlMkZ2NzlkN3ElMkZ5
YjRNbjh0d3VpUmx4WVFIRTFIQSUzRCZyZXNlcnZlZD0wDQo+Pg0KPj4NCj4+IFdoYXQgaXMgeW91
ciBvcGluaW9uLCBpcyBpdCB3b3J0aCBoYXZpbmcgYSBzaW1pbGFyIGNoZWNrIGluIFhlbj8NCj4+
DQo+Pg0KPiANCj4gSSB0aGluayB3ZSBjYW4gb21pdCBhZGRpbmcgc3VjaCBhIHdhcm5pbmcgZm9y
IG5vdywgaWYgeW91IGRvbid0IG1pbmQuIEkNCj4gd2lsbCBhbmFseXplIGl0IGluIG1vcmUgZGV0
YWlsIGFuZCBzZW5kIGl0IGFzIGEgZm9sbG93LXVwIHBhdGNoIGxhdGVyIGlmDQo+IG5lZWRlZC4g
V291bGQgdGhhdCBiZSBva2F5IGZvciB5b3U/DQoNClN1cmUsIEkgZG8gbm90IG1pbmQsIGl0IHdh
cyBhIHF1ZXN0aW9uLCBidXQgbm90IGEgcmVxdWVzdCBmb3IgaW1tZWRpYXRlIA0KY2hhbmdlLg0K
DQoNCj4gDQo+Pj4gK8KgwqDCoCAvKiBUaGUgR0lDIEhXIGRvZXNuJ3Qgc3VwcG9ydCBlU1BJLCBz
byB3ZSBjYW4gbGVhdmUgZnJvbSBoZXJlICovDQo+Pj4gK8KgwqDCoCBpZiAoIGdpY3YzX2luZm8u
bnJfZXNwaSA9PSAwICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuOw0KPj4+ICsNCj4+PiAr
wqDCoMKgIHByaW50aygiR0lDdjM6ICVkIGVTUEkgbGluZXNcbiIsIGdpY3YzX2luZm8ubnJfZXNw
aSk7DQo+Pj4gKw0KPj4NCj4+DQo+PiBbc25pcF0NCj4+DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+
IExlb25pZA0K


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 15:47:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 15:47:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110490.1459667 (Exim 4.92)
	(envelope-from )
	id 1uuCBg-0005Do-Gp; Thu, 04 Sep 2025 15:47:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110490.1459667; Thu, 04 Sep 2025 15:47: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 1uuCBg-0005Dh-DR; Thu, 04 Sep 2025 15:47:48 +0000
Received: by outflank-mailman (input) for mailman id 1110490;
 Thu, 04 Sep 2025 15:47: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 1uuCBe-0005Db-MX
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 15:47:46 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7f742829-89a6-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 17:47:44 +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 7F682339;
 Thu,  4 Sep 2025 08:47:35 -0700 (PDT)
Received: from [10.57.59.221] (unknown [10.57.59.221])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1309D3F6A8;
 Thu,  4 Sep 2025 08:47: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: 7f742829-89a6-11f0-9d12-b5c5bf9af7f9
Message-ID: 
Date: Thu, 4 Sep 2025 17:47:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
To: Yeoreum Yun 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , linux-arm-kernel@lists.infradead.org,
 linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04/09/2025 17:06, Yeoreum Yun wrote:
> Hi Kevin,
>
> [...]
>> Signed-off-by: Kevin Brodsky 
>> ---
>>  arch/arm64/include/asm/pgtable.h              | 10 +++++++---
>>  .../include/asm/book3s/64/tlbflush-hash.h     |  9 ++++++---
>>  arch/powerpc/mm/book3s64/hash_tlb.c           | 10 ++++++----
>>  arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +++--
>>  arch/sparc/include/asm/tlbflush_64.h          |  5 +++--
>>  arch/sparc/mm/tlb.c                           |  6 ++++--
>>  arch/x86/include/asm/paravirt.h               |  6 ++++--
>>  arch/x86/include/asm/paravirt_types.h         |  2 ++
>>  arch/x86/xen/enlighten_pv.c                   |  2 +-
>>  arch/x86/xen/mmu_pv.c                         |  2 +-
>>  fs/proc/task_mmu.c                            |  5 +++--
>>  include/linux/mm_types.h                      |  3 +++
>>  include/linux/pgtable.h                       |  6 ++++--
>>  mm/madvise.c                                  | 20 ++++++++++---------
>>  mm/memory.c                                   | 20 +++++++++++--------
>>  mm/migrate_device.c                           |  5 +++--
>>  mm/mprotect.c                                 |  5 +++--
>>  mm/mremap.c                                   |  5 +++--
>>  mm/vmalloc.c                                  | 15 ++++++++------
>>  mm/vmscan.c                                   | 15 ++++++++------
>>  20 files changed, 97 insertions(+), 59 deletions(-)
> I think you miss the mm/kasan/shadow.c

Ah yes that's because my series is based on v6.17-rc4 but [1] isn't in
mainline yet. I'll rebase v2 on top of mm-stable.

[1]
https://lore.kernel.org/all/0d2efb7ddddbff6b288fbffeeb10166e90771718.1755528662.git.agordeev@linux.ibm.com/

> But here, the usage is like:
>
> static int kasan_populate_vmalloc_pte()
> {
> 	...
> 	arch_leave_lazy_mmu_mode();
> 	...
> 	arch_enter_lazy_mmu_mode();
> 	...
> }
>
> Might be you can call the arch_leave_lazy_mmu_mode() with LAZY_MMU_DEFAULT
> in here since I think kasan_populate_vmalloc_pte() wouldn't be called
> nestly.

In fact in that case it doesn't matter if the section is nested or not.
We're already assuming that lazy_mmu is enabled, and we want to fully
disable it so that PTE operations take effect immediately. For that to
happen we must call arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT). We will
then re-enable lazy_mmu, and the next call to leave() will do the right
thing whether it is nested or not.

It's worth nothing the same situation occurs in xen_flush_lazy_mmu() and
this patch handles it in the way I've just described.

I'll take care of that in v2, thanks for the heads-up!

- Kevin


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 17:25:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 17:25:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110541.1459680 (Exim 4.92)
	(envelope-from )
	id 1uuDiM-0000WT-9R; Thu, 04 Sep 2025 17:25:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110541.1459680; Thu, 04 Sep 2025 17:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuDiM-0000WM-6h; Thu, 04 Sep 2025 17:25:38 +0000
Received: by outflank-mailman (input) for mailman id 1110541;
 Thu, 04 Sep 2025 17:25:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuDiK-0000WG-UY
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 17:25:36 +0000
Received: from rein-hpcbdc09 (unknown [1.6.89.6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28713e42-89b4-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 19:25:33 +0200 (CEST)
Received: by rein-hpcbdc09 (Postfix, from userid 1000)
 id 51C3E80C12F9; Thu,  4 Sep 2025 22:55: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: 28713e42-89b4-11f0-9809-7dc792cee155
From: Jahan Murudi 
To: xen-devel@lists.xenproject.org
Cc: Jahan Murudi ,
	Anthony PERARD 
Subject: [PATCH] docs/xentop: Add documentation for physical CPU monitoring feature
Date: Thu,  4 Sep 2025 22:55:25 +0530
Message-Id: <20250904172525.2795998-1-jahan.murudi.zg@renesas.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add man page documentation for the new '-p/--pcpus' flag that displays
physical CPU utilization metrics. This provides hypervisor-level CPU
usage insights alongside existing domain statistics.

Changes include:
- Add '-p' flag to SYNOPSIS section
- Document '--pcpus' option with description
- Maintain consistency with existing documentation style

Signed-off-by: Jahan Murudi 
---
 docs/man/xentop.1.pod | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/docs/man/xentop.1.pod b/docs/man/xentop.1.pod
index 593a484ce7..db64ceb694 100644
--- a/docs/man/xentop.1.pod
+++ b/docs/man/xentop.1.pod
@@ -5,7 +5,7 @@ xentop - displays real-time information about a Xen system and domains
 =head1 SYNOPSIS
 
 B [B<-h>] [B<-V>] [B<-d>SECONDS] [B<-n>] [B<-r>] [B<-v>] [B<-f>]
-[B<-b>] [B<-i>ITERATIONS] [B<-z>]
+[B<-b>] [B<-i>ITERATIONS] [B<-z>] [B<-p>]
 
 =head1 DESCRIPTION
 
@@ -61,6 +61,10 @@ maximum number of iterations xentop should produce before ending
 
 display dom0 first, ignoring interactive sorting
 
+=item B<-p>, B<--pcpus>
+
+display physical CPU utilization metrics
+
 =back
 
 =head1 INTERACTIVE COMMANDS
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 17:29:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 17:29:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110557.1459691 (Exim 4.92)
	(envelope-from )
	id 1uuDmL-000164-Or; Thu, 04 Sep 2025 17:29:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110557.1459691; Thu, 04 Sep 2025 17:29: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 1uuDmL-00015x-M4; Thu, 04 Sep 2025 17:29:45 +0000
Received: by outflank-mailman (input) for mailman id 1110557;
 Thu, 04 Sep 2025 17:29: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 1uuDmK-00015r-ML
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 17:29:44 +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 bc92c5a8-89b4-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 19:29:41 +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 584H9gVS006612;
 Thu, 4 Sep 2025 17:28:42 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 48yewx00vc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 04 Sep 2025 17:28:42 +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 584HAWjO031009; Thu, 4 Sep 2025 17:28:41 GMT
Received: from nam11-co1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2043.outbound.protection.outlook.com [40.107.220.43])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 48uqrbx6dv-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 04 Sep 2025 17:28:41 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by PH8PR10MB6340.namprd10.prod.outlook.com (2603:10b6:510:1cf::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Thu, 4 Sep
 2025 17:28:37 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.9094.016; Thu, 4 Sep 2025
 17:28: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: bc92c5a8-89b4-11f0-9809-7dc792cee155
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=LF2G2NPm3MsLQzTUfa9jpynsdPan5ydgu5DT+jSFOTo=; b=
	PoEsVtoeLRK3Zr0BYUo5JMO+5pCeP7PXOyMhjl1WQAvVAorfDTB+1IjPaei6fK9X
	Gcv1F1UtV09ZL2vbnWdmX7hxvt5qe+VZ5WPWhnbS9FDe7JjUjYge4NjDLwUGdoZZ
	Z7tNDvRyLdljDIUZAjrWz4EVUvPRyUnfL1+IfpnFurRQ/4Ie02MjGgvanBt9eCgK
	wQpfh0v5GX58uETbC9DpHiU3vePgL8MOS2XR0f9Dh7uCxak3Q20pi3b9qQgefzq9
	WbWTof/AO+XhwMixJJc0gaRHuJt+YrzGuXTJmmiSmfcw9GrV7aFOGgnejBoOlv3E
	0Xt7Nfhad3I3c2YB2uL4yA==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mHfivJswNxHbZnP4eDMn+SOUuXl3pFL55lLoBf0JQ7oOB1FJ0J5NWHQdiuKz6EFA6nlqVln4J6GyZwQ0uBL/vI0vdB7kUCkHzUefnLizNdvkpgl9VRN7reVsEHNmRtVamA+mM/KtVh4+sVLTfhqLX4kL+NA0fbuV/I9s55E40VqFAbLa38iuqzXo5G3LRQY7Tt5dPr6akONL+7yohKoLfjIKTFh8qOlO441wzJkh3R1CKsj1eabBhZRXZlLMK2IuqXh4rork4zuuB2gPKncyQtWi8/Wj6MeSgmpqVO+DvuCSge8qdjsXh3YHaU5jhKRk+fzclK5HxzPV1YylTwFZuw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LF2G2NPm3MsLQzTUfa9jpynsdPan5ydgu5DT+jSFOTo=;
 b=TzSg7wSMo1UlosK6kz4JeU36NwPpRzLmBcC39gwUfUyL4H+RWuDcIRbnWd5Fu44Ud4LGrzr2K+3Yiz5wwFHUOX7z6wZb6wxd6fJqYXIPniwIFZpbSo87nYIm7PRIXXLiHPnNjw10f+6CbT+tC+/DPf68ipUg+qiy6YqadwenPfqas1pVnUHVb03Mpu6Y+28nXznEsp5ewwrq+sNMn5WjrSx7O/tHPCV/u5zU3KszlBzo2ANre7eXDkqc1bt817Kf1xVJWBBZCaiIojaOKLlA+IgzloTkwLMT3kStfu9sos7XrdfiOCT+fsz6tGHMk2x8C/FhVHyNwe2aPy8ZsysfoQ==
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=LF2G2NPm3MsLQzTUfa9jpynsdPan5ydgu5DT+jSFOTo=;
 b=J/QyW5EgKQ5eJfAlwxZZmoKAMkOOC5k8oTS4z+58b+2t3XUj1ct27Gac1sZcFxfau+aTUIGup5PnMvo5P2+ipud+cT/vtjQnpUE94NUwKLWRkKfJ8y/+dmaxHYz/ING6BPTw0tlpOuANvML75fCjqWV5FxbRpxhNR2Z8HTzu+yI=
Date: Thu, 4 Sep 2025 18:28:30 +0100
From: Lorenzo Stoakes 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Alexander Gordeev ,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: <22131943-3f92-4f5a-be28-7b668c07a25c@lucifer.local>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250904125736.3918646-3-kevin.brodsky@arm.com>
X-ClientProxiedBy: MM0P280CA0011.SWEP280.PROD.OUTLOOK.COM
 (2603:10a6:190:a::33) To DM4PR10MB8218.namprd10.prod.outlook.com
 (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|PH8PR10MB6340:EE_
X-MS-Office365-Filtering-Correlation-Id: 32b28cd3-50b2-475e-e506-08ddebd87b4d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VDdzUFM3dk5GQk0yVEE4SkZISUtERE1GdHZMZ1lpa01Dd1M5SFlFTGhKUlhT?=
 =?utf-8?B?TUFpVmtvWHArMi94NmNJSXpiQjBiRDZvTHg4WDRGM3h4cW1CcmhRTUR1V3lq?=
 =?utf-8?B?UTVlam1MYWg4cmFqejZMalp0UzlwMW9tTWJtYkt4eElIZ1lYMjJSak4rcjJl?=
 =?utf-8?B?Kzd3bVl2Si8wcHhEZVU3YmFRYXRVYVBId29mQXBieDZSbVFhYWpmN215ajBD?=
 =?utf-8?B?RHVJZngwQlZSbEZBTFlESEdCaHBJK0lPV3JKbzkyOSsyVTlySVc1WmMxN3Zq?=
 =?utf-8?B?cE56UDF6TWJZYlJ4UzlCT0kxalJxeWp3YUdKZ2E3TWVKQ2lFNlMrZFRaNFhT?=
 =?utf-8?B?amZGZ1YyVitxUER3OGttZ1lQb0kzQXRFYm82VTgrV08ySTM1aEE5RGlRUjVE?=
 =?utf-8?B?cUNHZ0F4b1BhaHYwT0IzR1BBNFJPWDQ2U09sVVAzKzNsaDdHQXNvK1VXK051?=
 =?utf-8?B?TURuVlNKNXVmd3o0cGVOa042Tk5oR0x3Z0hIUnZIUS9PdTNyTUZDcU1CLzBE?=
 =?utf-8?B?SWVSMXVERzc1SmhoZllkZkRiRUlHRFhHM2pwWjNvRnJPYldTbDJObjhxejdG?=
 =?utf-8?B?VkJwcFg1MnltRS9LV2pibWkvbVhVMmF2a0JnZGhiL0NhZUVwQ3FtNTFiSS9a?=
 =?utf-8?B?Y2tvRWZaL0ZEUEFQcFhLUlRlYlBFanM4Vlp4TzhWU1FBaHROTDBWTkxpV0x6?=
 =?utf-8?B?NDlrVUZEWXh0RmpXMjV0QlN2YzRjMWkzQ2hVVGlMQ2owclRTV3Z2dlVZdWVX?=
 =?utf-8?B?aGpmTGljR2oxTkJtT1ltTktUdGtZaXp5WmprMnlOSlFILy9ZWlJ5M2YyaVNy?=
 =?utf-8?B?VURLdWRtSHlCSDRqazJYK3oxcnR5ekNJTms0aDV1eTN0Und5TGZFOEF3cDRW?=
 =?utf-8?B?OVVVVE15T2JPUGN4My9mUXBDbE1SQWY0NWU5YkZHczd2NzJaRmR0Y0d5QzRX?=
 =?utf-8?B?bGNsVUZxSE9kbTVnd0phcmtjQlBhNG5pRWN1bzRqR1B4L0d0dHNyVFhkcThj?=
 =?utf-8?B?SHYvVDI5RFV1RkNRcnNCYnNaUTJqTHBNSnZsOUNCVU9PUWVtYU5WVzhpUFZP?=
 =?utf-8?B?emhqVkdzQTdWSVo2cHUxOGRFM2xsSGNwSmYveVJkZVptQ1NlclFVS3lBWVh5?=
 =?utf-8?B?Qmg3UktxUWVUa0pQSS9PY0JReHhuTmYzSnk0TStHUSt4dE9KaWhheWNFL3lX?=
 =?utf-8?B?YWtCb0tNOVBLeDUzM0wvZUFIN0NMS1phdExHN0lvZ0FqdUpQb3F1VHBESXU4?=
 =?utf-8?B?SzNsRVdTNTd6VkVXM29SV1lyUTBHOHZCaFd0VDk2dDV1aGxVZGFVejV1WjNL?=
 =?utf-8?B?UWpqSW9lc3BJazkzRU16UERLRkF4Yjkrd0ptMjVQOVNpTU9pWVYrMGNhSEtx?=
 =?utf-8?B?d0NhR2hMdjJuVkJHT3Nld2UyTVhYdEkva0x0WlZkM1l3NzkrRUliY2c1T2lC?=
 =?utf-8?B?UHdVZHNiUmZBTUR6c1pwRG1HS3dpeXU0SitBb0ZMaXhOVXllL3doVml4dFVp?=
 =?utf-8?B?L3RYS2MzSnlSYWdvU1dOL3RBVmJXaE9nYWpOQmhBbi9OTWlTTGh6VXhKekFp?=
 =?utf-8?B?MEZ4MzFPblo3OFBXSzVEcmV5VTQ4UXM3L2lXcTRxc05NaFRjZ3krZ2VhZE5t?=
 =?utf-8?B?RGtlTGxpajIzdEIrVzJlQ0J4bXlMSWFFRUNPTGhNSE1nbFdHbmlLdE44R3ZV?=
 =?utf-8?B?ZFh4SENLRGMyYk1ZWG1rU3JuNzdxaE40NmQyaC9WamJidGNNaGJ1dXVzVFVS?=
 =?utf-8?B?ZG43ams3UXlqSy9FS1NjU05xS3l5S1IySktrRk9QYXNsLzJWci9rd0MvNjRv?=
 =?utf-8?B?RGtoK29iUjVMWXhmU1hVdUxEMHljOGhHSjh5d0QxbmliTHlKT3hOMFdsSXlJ?=
 =?utf-8?B?d0lPeG1vQjVGL1RteW5MSDZBditKZS9DRVFXeFV1RSttTFE9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QUdkanFOQ01pWFRTVzVJR1JJOFJoVnRrczVweS9XSXlKZyszclhsS3ZuSXRh?=
 =?utf-8?B?UEJCOVVtcXFTb1VVWHN4VUNsM2VZY0xyWWsxL3daZU1nRWk2WGZQQlhtTW01?=
 =?utf-8?B?VDlKamc1TzdiU2pqWVdSQ01nMHdwS0IrNmRXc3p1UnJTQ1dqaEk5STZoTjNj?=
 =?utf-8?B?MW55Q1dnK2NmbFhlWTA3Q2FsZ2tybFJGTzR5eDlBV2d4b245V1lkYlZyd1Aw?=
 =?utf-8?B?S2dmQlFPdGorU1VQck1JOHBadm5BZU1qb01VTldrci9nWDJOKzg3elc5T2d4?=
 =?utf-8?B?RW9XRllEUUFaNmtJNkNIbzluTHpJM0ZTVWlrV281V2NOckxDVG9zV29oTUht?=
 =?utf-8?B?aERocmFIa0lZMm1LY1V1R0JXSGVSdE95aFJuR3FldWpIUDl4L1lSZG82OVJL?=
 =?utf-8?B?eGVBSTU2TXhuSWxGV3oxNzhaS2ZNNkVjUUJNL0FEY3NoV1pNK3Jia1ZzNlMw?=
 =?utf-8?B?b3VnWU5vRUw1RkhVWFMyMlBHRldnTVphMFViSWZJTFZGT21BUUMrWkhPWTFG?=
 =?utf-8?B?REdiQ1pIUnBnZDZnSm5nTFMwdTJzOEt2cTloNnVLUldnSVQ0dnRLSGRTREdO?=
 =?utf-8?B?RTFlUjJsY2ZMU2I4TTJsZExGYVVFSkd0SlRucy9xZ2dBQjh6WmpJdzY3U2JE?=
 =?utf-8?B?UkRIU2xBYWVvbzUrL3h4WlRvS1pYVWQ3VUt2S28yVW9MS004RGJ5ODMvOHlq?=
 =?utf-8?B?bVUra2RTZ1ZDeTVEV0U3dGY2b3ozU3B0VlFlQjh0cm9DNXZyZ2o0dmVXNm9y?=
 =?utf-8?B?OVJXOTVDRmFjS1hMUnlUOXB3YkNOdE5HZ0l0K1JpTVBlS2syeXJqcFFkN2t3?=
 =?utf-8?B?UEJTeXo4WGJnWDkvaUFySlprL1FUSHBUdDhLVXU3VkR6d0p6Ukl3Um5XYmR1?=
 =?utf-8?B?cVBTZWxXSXlYQXIrM3UyU3NycGVSSGhZdmxlREo2Q001RkE5OTFwaXd0blFw?=
 =?utf-8?B?NXQxQ2NMOTNkbEdOamhxaGZtV0lJVVRWYXFkNGI2SHZaVmhheG9adnV4SzYv?=
 =?utf-8?B?eXdqaGp2bG5RRzcrU3dHMzZHMTQ4K0hENjdxdHZpR0R1ZUp1Y2ZrOU1wYm5X?=
 =?utf-8?B?a1A3cmpYVEROdUNQNmRtVU5uQVY5MmpuTWVFUTduZ0JkZkdzN0pDRDJIV1hR?=
 =?utf-8?B?U3lnTGE1L0FGb3dCNklxMy9iRk1YSXBLOUZja0hOZXlSSEtscFNsMXBMQVI5?=
 =?utf-8?B?ZTJlTWQ3eXZydUcrZ2ltd2RPWm0vWXdoYmlxU3BxOEdTMUd5bGhYR0h0SU5Y?=
 =?utf-8?B?SDBTK1ArVWM3Qlc1SHZKQzNsRWN4YW91dE1rREtqN0g3UzIrMjVRODFrVW5n?=
 =?utf-8?B?WVFwcS9kLzhFSEoyUGFqcURzQUVVUVJIWG45VkQrTnVoRC9tbHdjMW4wVUtB?=
 =?utf-8?B?M3hwQUZmM3lSRjRTRmZHU3owL2VlRkVOaCtTOWcvSmw1OXNaeDBHQXZXRkNM?=
 =?utf-8?B?M1FCbDBleWQrOEluWUs5Z0RJd2xVVkN4QjlRQ3hYSmZuY3VOd0o4WWNkRFZo?=
 =?utf-8?B?cFl5RkNYaXlOUkJvVTZrTEtFY1oxM0tzUFJ3T1EyTFFrb0JtOFZnbFRMajEv?=
 =?utf-8?B?Z2VtNENEb0xpc0tZS25LakI4YUR4S0tSWEVaM05xS1VvRVFFbVZUZ3NlME0x?=
 =?utf-8?B?TU93NGlESk1JL1BWcnVxQ1pUdWNYYmNoZURLSHNoTGxFOXdMeE1PaURRTCtw?=
 =?utf-8?B?ZzlSdm5NeHVoVXhQaWhlOWpQMVhpdnRpK3ErOWdEVkN3dVRnc3ozblNPTXRj?=
 =?utf-8?B?a2NaRlI4M0xNaVlKam5aZkRaeERLYkZpQVRSWk5FUk04eFNuVzZ1Ym92Y1Bj?=
 =?utf-8?B?aElsYVgzNCswdEVvYWY1Uk95Tis5MVgyMTlSUUo4dFdNTU9nRC9yV3Ixbzl6?=
 =?utf-8?B?aTVQMWU1c1BzZWd3OWJRSkovenJsTi96Nno5QzAxSjYrSWUvRDdUendtdGpO?=
 =?utf-8?B?bCtnc0twTnNJU1d4M2NOdzF4UDY1b2NqWGl2Uk1SVkMwY1FEZkladnUra2lm?=
 =?utf-8?B?ZkxON2VPSVpmUGwya2FHajBKZzYxWC8rWmNYajZnZVNUWjhENWVsNmdJOG5P?=
 =?utf-8?B?aFp3aG0vNk1RcUJETGlicjVZQ0kzTHFEUFQ2M3RnUm9rb2NZWmZmMzFyTDJJ?=
 =?utf-8?B?YWZ0cGRueHJmd3p5c2MwM0JTL0pNT1NXWUsxSnk5NjFWekhGRHZvUktwaEMx?=
 =?utf-8?B?eVE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	OpAQu6u1fg91tf/+ls7CLxI95stDEMDd+M2be/qdu8Qg3QDVhP9QfwX8+WyAIJqWHlomTdmQrXdcK0tlLTfYdd8KGKtZBxlqNtmq+kIFMF+JLq3RvnTaO7YwV6yaluYsONj4spsXbi8bHyFOMQVqNfFHemXP4l+8DuoMlQZ+hSwDzyMDsShRYOTw/2w6beLRX9WJ3ZQqsnaEF0Le4e+6qiZrWIkl0CJ/oa8RCpT+wMGZywa4hDvjn4vNDaToADc4GL8WoU1W12z18OqggRWw95PC53OaYTHrJzBFDMKCV/U1IYNXZSwLe5VbjEd7ce/UK1QPiLCHJHZcU8qLChScaRDVtWntFDceVWH9dIFCUaku84SBGsxHBEQPm8bhAesDsELAMlKP9530dNK7rlys3lZ3iVDV/b5XPhgC7EfDWrFe6lVnsBe82+u4FaC0/c/UNuxwaIZAPDOzAqS85/fUTq2ozYngqFcWRMsmp9+NH3wdUiVc0roArCBUcp+4AtxcPGG8dBy3EQQ8T668XKyvaC3BhNPHT236mDJUvRe8WHpyfXQNvbCtSDqeLQp4pV21Cp+XOyC9lN2P/pANCexAx+21SEHZmKTB0HPNY6mvT9c=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 32b28cd3-50b2-475e-e506-08ddebd87b4d
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 17:28:37.2573
 (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: ctG8KvbY0zFlyb0WOAKEQq6qlwTdOGP2oLJmXLj5ccLFJEL4Zx8efU2pI5ZvDaGmoNmtClLFekpf4Zu12SOG0T0wfEnmHyPTl8S9v+hzbyE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR10MB6340
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-04_06,2025-09-04_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 malwarescore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2508110000 definitions=main-2509040172
X-Proofpoint-GUID: g5lBYVr94SgUq3nY8TTpYRPxuH2LzrwH
X-Proofpoint-ORIG-GUID: g5lBYVr94SgUq3nY8TTpYRPxuH2LzrwH
X-Authority-Analysis: v=2.4 cv=M6FNKzws c=1 sm=1 tr=0 ts=68b9cc4a b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10
 a=yJojWOMRYYMA:10 a=GoEa3M9JfhUA:10 a=7CQSdrXTAAAA:8 a=eOSbTCzkzg-9sdUchKgA:9
 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 cc=ntf
 awl=host:13602
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA0MDE2OSBTYWx0ZWRfX7RaI/6EU65HE
 C33YcWvj97H3ccDVOMJOXk2GgPpjuWpqhMo7Sw2luNUKLgmpvjap9wHX0fRwJzhlUo23zqLArzM
 gNeZLNTFa+GnU1JY4t55L8+IpHacZvPVmUO16KRF83xq6Rv8yukTcx3IBRdBu9f7rfSPB+G216w
 JQZs04mptj048TExs9VQZnnd8TmxtNUrq7yjZasneeCS0E4x26zgXavY2yIc+5NjULhg724fo5E
 /X85taJqxx5FTuzXAk6xn8bvbn8+XZDkIcvIzFS803uPqYXQwCS7YYbdnbK2oErheOC1QP4PCr8
 Q9sWmhAuNQkRuEqbxSJzWOwpc1KDz71RZ5V8fejFAMlaYJLq3Q0+i4/A/YJfSCB6ofMtTztLwzg
 tyfZTMQ3DwuBXdNQToTzepevK3L2+g==

Hi Kevin,

This is causing a build failure:

In file included from ./include/linux/mm.h:31,
                 from mm/userfaultfd.c:8:
mm/userfaultfd.c: In function ‘move_present_ptes’:
./include/linux/pgtable.h:247:41: error: statement with no effect [-Werror=unused-value]
  247 | #define arch_enter_lazy_mmu_mode()      (LAZY_MMU_DEFAULT)
      |                                         ^
mm/userfaultfd.c:1103:9: note: in expansion of macro ‘arch_enter_lazy_mmu_mode’
 1103 |         arch_enter_lazy_mmu_mode();
      |         ^~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/pgtable.h:248:54: error: expected expression before ‘)’ token
  248 | #define arch_leave_lazy_mmu_mode(state) ((void)(state))
      |                                                      ^
mm/userfaultfd.c:1141:9: note: in expansion of macro ‘arch_leave_lazy_mmu_mode’
 1141 |         arch_leave_lazy_mmu_mode();
      |         ^~~~~~~~~~~~~~~~~~~~~~~~

It seems you haven't carefully checked call sites here, please do very
carefully recheck these - I see Yeoreum reported a mising kasan case, so I
suggest you just aggressively grep this + make sure you've covered all
bases :)

Cheers, Lorenzo


On Thu, Sep 04, 2025 at 01:57:31PM +0100, Kevin Brodsky wrote:
> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> (taking and returning no value). This is proving problematic in
> situations where leave() needs to restore some context back to its
> original state (before enter() was called). In particular, this
> makes it difficult to support the nesting of lazy_mmu sections -
> leave() does not know whether the matching enter() call occurred
> while lazy_mmu was already enabled, and whether to disable it or
> not.
>
> This patch gives all architectures the chance to store local state
> while inside a lazy_mmu section by making enter() return some value,
> storing it in a local variable, and having leave() take that value.
> That value is typed lazy_mmu_state_t - each architecture defining
> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> For now we define it as int everywhere, which is sufficient to
> support nesting.
>
> The diff is unfortunately rather large as all the API changes need
> to be done atomically. Main parts:
>
> * Changing the prototypes of arch_{enter,leave}_lazy_mmu_mode()
>   in generic and arch code, and introducing lazy_mmu_state_t.
>
> * Introducing LAZY_MMU_{DEFAULT,NESTED} for future support of
>   nesting. enter() always returns LAZY_MMU_DEFAULT for now.
>   (linux/mm_types.h is not the most natural location for defining
>   those constants, but there is no other obvious header that is
>   accessible where arch's implement the helpers.)
>
> * Changing all lazy_mmu sections to introduce a lazy_mmu_state
>   local variable, having enter() set it and leave() take it. Most of
>   these changes were generated using the Coccinelle script below.
>
> @@
> @@
> {
> + lazy_mmu_state_t lazy_mmu_state;
> ...
> - arch_enter_lazy_mmu_mode();
> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> ...
> - arch_leave_lazy_mmu_mode();
> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> ...
> }
>
> Note: it is difficult to provide a default definition of
> lazy_mmu_state_t for architectures implementing lazy_mmu, because
> that definition would need to be available in
> arch/x86/include/asm/paravirt_types.h and adding a new generic
>  #include there is very tricky due to the existing header soup.
>
> Signed-off-by: Kevin Brodsky 
> ---
>  arch/arm64/include/asm/pgtable.h              | 10 +++++++---
>  .../include/asm/book3s/64/tlbflush-hash.h     |  9 ++++++---
>  arch/powerpc/mm/book3s64/hash_tlb.c           | 10 ++++++----
>  arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +++--
>  arch/sparc/include/asm/tlbflush_64.h          |  5 +++--
>  arch/sparc/mm/tlb.c                           |  6 ++++--
>  arch/x86/include/asm/paravirt.h               |  6 ++++--
>  arch/x86/include/asm/paravirt_types.h         |  2 ++
>  arch/x86/xen/enlighten_pv.c                   |  2 +-
>  arch/x86/xen/mmu_pv.c                         |  2 +-
>  fs/proc/task_mmu.c                            |  5 +++--
>  include/linux/mm_types.h                      |  3 +++
>  include/linux/pgtable.h                       |  6 ++++--
>  mm/madvise.c                                  | 20 ++++++++++---------
>  mm/memory.c                                   | 20 +++++++++++--------
>  mm/migrate_device.c                           |  5 +++--
>  mm/mprotect.c                                 |  5 +++--
>  mm/mremap.c                                   |  5 +++--
>  mm/vmalloc.c                                  | 15 ++++++++------
>  mm/vmscan.c                                   | 15 ++++++++------
>  20 files changed, 97 insertions(+), 59 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 728d7b6ed20a..816197d08165 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -81,7 +81,9 @@ static inline void queue_pte_barriers(void)
>  }
>
>  #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> -static inline void arch_enter_lazy_mmu_mode(void)
> +typedef int lazy_mmu_state_t;
> +
> +static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	/*
>  	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
> @@ -96,12 +98,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
>  	 */
>
>  	if (in_interrupt())
> -		return;
> +		return LAZY_MMU_DEFAULT;
>
>  	set_thread_flag(TIF_LAZY_MMU);
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -static inline void arch_leave_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	if (in_interrupt())
>  		return;
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> index 176d7fd79eeb..c9f1e819e567 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> @@ -25,13 +25,14 @@ DECLARE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
>  extern void __flush_tlb_pending(struct ppc64_tlb_batch *batch);
>
>  #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> +typedef int lazy_mmu_state_t;
>
> -static inline void arch_enter_lazy_mmu_mode(void)
> +static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	struct ppc64_tlb_batch *batch;
>
>  	if (radix_enabled())
> -		return;
> +		return LAZY_MMU_DEFAULT;
>  	/*
>  	 * apply_to_page_range can call us this preempt enabled when
>  	 * operating on kernel page tables.
> @@ -39,9 +40,11 @@ static inline void arch_enter_lazy_mmu_mode(void)
>  	preempt_disable();
>  	batch = this_cpu_ptr(&ppc64_tlb_batch);
>  	batch->active = 1;
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -static inline void arch_leave_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	struct ppc64_tlb_batch *batch;
>
> diff --git a/arch/powerpc/mm/book3s64/hash_tlb.c b/arch/powerpc/mm/book3s64/hash_tlb.c
> index 21fcad97ae80..ee664f88e679 100644
> --- a/arch/powerpc/mm/book3s64/hash_tlb.c
> +++ b/arch/powerpc/mm/book3s64/hash_tlb.c
> @@ -189,6 +189,7 @@ void hash__tlb_flush(struct mmu_gather *tlb)
>   */
>  void __flush_hash_table_range(unsigned long start, unsigned long end)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int hugepage_shift;
>  	unsigned long flags;
>
> @@ -205,7 +206,7 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
>  	 * way to do things but is fine for our needs here.
>  	 */
>  	local_irq_save(flags);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; start < end; start += PAGE_SIZE) {
>  		pte_t *ptep = find_init_mm_pte(start, &hugepage_shift);
>  		unsigned long pte;
> @@ -217,12 +218,13 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
>  			continue;
>  		hpte_need_flush(&init_mm, start, ptep, pte, hugepage_shift);
>  	}
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	local_irq_restore(flags);
>  }
>
>  void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte;
>  	pte_t *start_pte;
>  	unsigned long flags;
> @@ -237,7 +239,7 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
>  	 * way to do things but is fine for our needs here.
>  	 */
>  	local_irq_save(flags);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	start_pte = pte_offset_map(pmd, addr);
>  	if (!start_pte)
>  		goto out;
> @@ -249,6 +251,6 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
>  	}
>  	pte_unmap(start_pte);
>  out:
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	local_irq_restore(flags);
>  }
> diff --git a/arch/powerpc/mm/book3s64/subpage_prot.c b/arch/powerpc/mm/book3s64/subpage_prot.c
> index ec98e526167e..4720f9f321af 100644
> --- a/arch/powerpc/mm/book3s64/subpage_prot.c
> +++ b/arch/powerpc/mm/book3s64/subpage_prot.c
> @@ -53,6 +53,7 @@ void subpage_prot_free(struct mm_struct *mm)
>  static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
>  			     int npages)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pgd_t *pgd;
>  	p4d_t *p4d;
>  	pud_t *pud;
> @@ -73,13 +74,13 @@ static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
>  	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
>  	if (!pte)
>  		return;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; npages > 0; --npages) {
>  		pte_update(mm, addr, pte, 0, 0, 0);
>  		addr += PAGE_SIZE;
>  		++pte;
>  	}
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(pte - 1, ptl);
>  }
>
> diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
> index cd144eb31bdd..02c93a4e6af5 100644
> --- a/arch/sparc/include/asm/tlbflush_64.h
> +++ b/arch/sparc/include/asm/tlbflush_64.h
> @@ -40,10 +40,11 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
>  void flush_tlb_kernel_range(unsigned long start, unsigned long end);
>
>  #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> +typedef int lazy_mmu_state_t;
>
>  void flush_tlb_pending(void);
> -void arch_enter_lazy_mmu_mode(void);
> -void arch_leave_lazy_mmu_mode(void);
> +lazy_mmu_state_t arch_enter_lazy_mmu_mode(void);
> +void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state);
>
>  /* Local cpu only.  */
>  void __flush_tlb_all(void);
> diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
> index a35ddcca5e76..bf5094b770af 100644
> --- a/arch/sparc/mm/tlb.c
> +++ b/arch/sparc/mm/tlb.c
> @@ -50,16 +50,18 @@ void flush_tlb_pending(void)
>  	put_cpu_var(tlb_batch);
>  }
>
> -void arch_enter_lazy_mmu_mode(void)
> +lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	struct tlb_batch *tb;
>
>  	preempt_disable();
>  	tb = this_cpu_ptr(&tlb_batch);
>  	tb->active = 1;
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -void arch_leave_lazy_mmu_mode(void)
> +void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
>
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index b5e59a7ba0d0..65a0d394fba1 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -527,12 +527,14 @@ static inline void arch_end_context_switch(struct task_struct *next)
>  }
>
>  #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> -static inline void arch_enter_lazy_mmu_mode(void)
> +static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	PVOP_VCALL0(mmu.lazy_mode.enter);
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -static inline void arch_leave_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	PVOP_VCALL0(mmu.lazy_mode.leave);
>  }
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 37a8627d8277..bc1af86868a3 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -41,6 +41,8 @@ struct pv_info {
>  };
>
>  #ifdef CONFIG_PARAVIRT_XXL
> +typedef int lazy_mmu_state_t;
> +
>  struct pv_lazy_ops {
>  	/* Set deferred update mode, used for batching operations. */
>  	void (*enter)(void);
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 26bbaf4b7330..a245ba47a631 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -426,7 +426,7 @@ static void xen_start_context_switch(struct task_struct *prev)
>  	BUG_ON(preemptible());
>
>  	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
>  		set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES);
>  	}
>  	enter_lazy(XEN_LAZY_CPU);
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 2a4a8deaf612..2039d5132ca3 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2140,7 +2140,7 @@ static void xen_flush_lazy_mmu(void)
>  	preempt_disable();
>
>  	if (xen_get_lazy_mode() == XEN_LAZY_MMU) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
>  		arch_enter_lazy_mmu_mode();
>  	}
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 29cca0e6d0ff..c9bf1128a4cd 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -2610,6 +2610,7 @@ static int pagemap_scan_thp_entry(pmd_t *pmd, unsigned long start,
>  static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  				  unsigned long end, struct mm_walk *walk)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct pagemap_scan_private *p = walk->private;
>  	struct vm_area_struct *vma = walk->vma;
>  	unsigned long addr, flush_end = 0;
> @@ -2628,7 +2629,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  		return 0;
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	if ((p->arg.flags & PM_SCAN_WP_MATCHING) && !p->vec_out) {
>  		/* Fast path for performing exclusive WP */
> @@ -2698,7 +2699,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  	if (flush_end)
>  		flush_tlb_range(vma, start, addr);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(start_pte, ptl);
>
>  	cond_resched();
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 08bc2442db93..18745c32f2c0 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1441,6 +1441,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm);
>  extern void tlb_gather_mmu_fullmm(struct mmu_gather *tlb, struct mm_struct *mm);
>  extern void tlb_finish_mmu(struct mmu_gather *tlb);
>
> +#define LAZY_MMU_DEFAULT	0
> +#define LAZY_MMU_NESTED		1
> +
>  struct vm_fault;
>
>  /**
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8848e132a6be..6932c8e344ab 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -232,8 +232,10 @@ static inline int pmd_dirty(pmd_t pmd)
>   * 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)
> +typedef int lazy_mmu_state_t;
> +
> +#define arch_enter_lazy_mmu_mode()	(LAZY_MMU_DEFAULT)
> +#define arch_leave_lazy_mmu_mode(state)	((void)(state))
>  #endif
>
>  #ifndef pte_batch_hint
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 35ed4ab0d7c5..72c032f2cf56 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -357,6 +357,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  				unsigned long addr, unsigned long end,
>  				struct mm_walk *walk)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct madvise_walk_private *private = walk->private;
>  	struct mmu_gather *tlb = private->tlb;
>  	bool pageout = private->pageout;
> @@ -455,7 +456,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  	if (!start_pte)
>  		return 0;
>  	flush_tlb_batched_pending(mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
>  		nr = 1;
>  		ptent = ptep_get(pte);
> @@ -463,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  		if (++batch_count == SWAP_CLUSTER_MAX) {
>  			batch_count = 0;
>  			if (need_resched()) {
> -				arch_leave_lazy_mmu_mode();
> +				arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  				pte_unmap_unlock(start_pte, ptl);
>  				cond_resched();
>  				goto restart;
> @@ -499,7 +500,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  				if (!folio_trylock(folio))
>  					continue;
>  				folio_get(folio);
> -				arch_leave_lazy_mmu_mode();
> +				arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  				pte_unmap_unlock(start_pte, ptl);
>  				start_pte = NULL;
>  				err = split_folio(folio);
> @@ -510,7 +511,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  				if (!start_pte)
>  					break;
>  				flush_tlb_batched_pending(mm);
> -				arch_enter_lazy_mmu_mode();
> +				lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  				if (!err)
>  					nr = 0;
>  				continue;
> @@ -558,7 +559,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  	}
>
>  	if (start_pte) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  		pte_unmap_unlock(start_pte, ptl);
>  	}
>  	if (pageout)
> @@ -657,6 +658,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>
>  {
>  	const cydp_t cydp_flags = CYDP_CLEAR_YOUNG | CYDP_CLEAR_DIRTY;
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct mmu_gather *tlb = walk->private;
>  	struct mm_struct *mm = tlb->mm;
>  	struct vm_area_struct *vma = walk->vma;
> @@ -677,7 +679,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (!start_pte)
>  		return 0;
>  	flush_tlb_batched_pending(mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; addr != end; pte += nr, addr += PAGE_SIZE * nr) {
>  		nr = 1;
>  		ptent = ptep_get(pte);
> @@ -727,7 +729,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  				if (!folio_trylock(folio))
>  					continue;
>  				folio_get(folio);
> -				arch_leave_lazy_mmu_mode();
> +				arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  				pte_unmap_unlock(start_pte, ptl);
>  				start_pte = NULL;
>  				err = split_folio(folio);
> @@ -738,7 +740,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  				if (!start_pte)
>  					break;
>  				flush_tlb_batched_pending(mm);
> -				arch_enter_lazy_mmu_mode();
> +				lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  				if (!err)
>  					nr = 0;
>  				continue;
> @@ -778,7 +780,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (nr_swap)
>  		add_mm_counter(mm, MM_SWAPENTS, nr_swap);
>  	if (start_pte) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  		pte_unmap_unlock(start_pte, ptl);
>  	}
>  	cond_resched();
> diff --git a/mm/memory.c b/mm/memory.c
> index 0ba4f6b71847..ebe0ffddcb77 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1079,6 +1079,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	       pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
>  	       unsigned long end)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct mm_struct *dst_mm = dst_vma->vm_mm;
>  	struct mm_struct *src_mm = src_vma->vm_mm;
>  	pte_t *orig_src_pte, *orig_dst_pte;
> @@ -1126,7 +1127,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
>  	orig_src_pte = src_pte;
>  	orig_dst_pte = dst_pte;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		nr = 1;
> @@ -1195,7 +1196,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	} while (dst_pte += nr, src_pte += nr, addr += PAGE_SIZE * nr,
>  		 addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(orig_src_pte, src_ptl);
>  	add_mm_rss_vec(dst_mm, rss);
>  	pte_unmap_unlock(orig_dst_pte, dst_ptl);
> @@ -1694,6 +1695,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  				unsigned long addr, unsigned long end,
>  				struct zap_details *details)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	bool force_flush = false, force_break = false;
>  	struct mm_struct *mm = tlb->mm;
>  	int rss[NR_MM_COUNTERS];
> @@ -1714,7 +1716,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  		return addr;
>
>  	flush_tlb_batched_pending(mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	do {
>  		bool any_skipped = false;
>
> @@ -1746,7 +1748,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  		direct_reclaim = try_get_and_clear_pmd(mm, pmd, &pmdval);
>
>  	add_mm_rss_vec(mm, rss);
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>
>  	/* Do the actual TLB flush before dropping ptl */
>  	if (force_flush) {
> @@ -2683,6 +2685,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			unsigned long addr, unsigned long end,
>  			unsigned long pfn, pgprot_t prot)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte, *mapped_pte;
>  	spinlock_t *ptl;
>  	int err = 0;
> @@ -2690,7 +2693,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
>  	if (!pte)
>  		return -ENOMEM;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	do {
>  		BUG_ON(!pte_none(ptep_get(pte)));
>  		if (!pfn_modify_allowed(pfn, prot)) {
> @@ -2700,7 +2703,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  		set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
>  		pfn++;
>  	} while (pte++, addr += PAGE_SIZE, addr != end);
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(mapped_pte, ptl);
>  	return err;
>  }
> @@ -2989,6 +2992,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  				     pte_fn_t fn, void *data, bool create,
>  				     pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte, *mapped_pte;
>  	int err = 0;
>  	spinlock_t *ptl;
> @@ -3007,7 +3011,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			return -EINVAL;
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	if (fn) {
>  		do {
> @@ -3020,7 +3024,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	}
>  	*mask |= PGTBL_PTE_MODIFIED;
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>
>  	if (mm != &init_mm)
>  		pte_unmap_unlock(mapped_pte, ptl);
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index e05e14d6eacd..659285c6ba77 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -59,6 +59,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>  				   unsigned long end,
>  				   struct mm_walk *walk)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct migrate_vma *migrate = walk->private;
>  	struct folio *fault_folio = migrate->fault_page ?
>  		page_folio(migrate->fault_page) : NULL;
> @@ -110,7 +111,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>  	ptep = pte_offset_map_lock(mm, pmdp, addr, &ptl);
>  	if (!ptep)
>  		goto again;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	for (; addr < end; addr += PAGE_SIZE, ptep++) {
>  		struct dev_pagemap *pgmap;
> @@ -287,7 +288,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>  	if (unmapped)
>  		flush_tlb_range(walk->vma, start, end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(ptep - 1, ptl);
>
>  	return 0;
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 113b48985834..7bba651e5aa3 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -273,6 +273,7 @@ static long change_pte_range(struct mmu_gather *tlb,
>  		struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr,
>  		unsigned long end, pgprot_t newprot, unsigned long cp_flags)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte, oldpte;
>  	spinlock_t *ptl;
>  	long pages = 0;
> @@ -293,7 +294,7 @@ static long change_pte_range(struct mmu_gather *tlb,
>  		target_node = numa_node_id();
>
>  	flush_tlb_batched_pending(vma->vm_mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	do {
>  		nr_ptes = 1;
>  		oldpte = ptep_get(pte);
> @@ -439,7 +440,7 @@ static long change_pte_range(struct mmu_gather *tlb,
>  			}
>  		}
>  	} while (pte += nr_ptes, addr += nr_ptes * PAGE_SIZE, addr != end);
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(pte - 1, ptl);
>
>  	return pages;
> diff --git a/mm/mremap.c b/mm/mremap.c
> index e618a706aff5..dac29a734e16 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -193,6 +193,7 @@ static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr
>  static int move_ptes(struct pagetable_move_control *pmc,
>  		unsigned long extent, pmd_t *old_pmd, pmd_t *new_pmd)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct vm_area_struct *vma = pmc->old;
>  	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
>  	struct mm_struct *mm = vma->vm_mm;
> @@ -256,7 +257,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
>  	if (new_ptl != old_ptl)
>  		spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
>  	flush_tlb_batched_pending(vma->vm_mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	for (; old_addr < old_end; old_ptep += nr_ptes, old_addr += nr_ptes * PAGE_SIZE,
>  		new_ptep += nr_ptes, new_addr += nr_ptes * PAGE_SIZE) {
> @@ -301,7 +302,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
>  		}
>  	}
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	if (force_flush)
>  		flush_tlb_range(vma, old_end - len, old_end);
>  	if (new_ptl != old_ptl)
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 6dbcdceecae1..f901675dd060 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -95,6 +95,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  			phys_addr_t phys_addr, pgprot_t prot,
>  			unsigned int max_page_shift, pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte;
>  	u64 pfn;
>  	struct page *page;
> @@ -105,7 +106,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	if (!pte)
>  		return -ENOMEM;
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		if (unlikely(!pte_none(ptep_get(pte)))) {
> @@ -131,7 +132,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  		pfn++;
>  	} while (pte += PFN_DOWN(size), addr += size, addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  	return 0;
>  }
> @@ -354,12 +355,13 @@ int ioremap_page_range(unsigned long addr, unsigned long end,
>  static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  			     pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte;
>  	pte_t ptent;
>  	unsigned long size = PAGE_SIZE;
>
>  	pte = pte_offset_kernel(pmd, addr);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  #ifdef CONFIG_HUGETLB_PAGE
> @@ -378,7 +380,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  		WARN_ON(!pte_none(ptent) && !pte_present(ptent));
>  	} while (pte += (size >> PAGE_SHIFT), addr += size, addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  }
>
> @@ -514,6 +516,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  		unsigned long end, pgprot_t prot, struct page **pages, int *nr,
>  		pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int err = 0;
>  	pte_t *pte;
>
> @@ -526,7 +529,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (!pte)
>  		return -ENOMEM;
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		struct page *page = pages[*nr];
> @@ -548,7 +551,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  		(*nr)++;
>  	} while (pte++, addr += PAGE_SIZE, addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	*mask |= PGTBL_PTE_MODIFIED;
>
>  	return err;
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a48aec8bfd92..13b6657c8743 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3521,6 +3521,7 @@ static void walk_update_folio(struct lru_gen_mm_walk *walk, struct folio *folio,
>  static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  			   struct mm_walk *args)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int i;
>  	bool dirty;
>  	pte_t *pte;
> @@ -3550,7 +3551,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  		return false;
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  restart:
>  	for (i = pte_index(start), addr = start; addr != end; i++, addr += PAGE_SIZE) {
>  		unsigned long pfn;
> @@ -3591,7 +3592,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  	if (i < PTRS_PER_PTE && get_next_vma(PMD_MASK, PAGE_SIZE, args, &start, &end))
>  		goto restart;
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(pte, ptl);
>
>  	return suitable_to_scan(total, young);
> @@ -3600,6 +3601,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area_struct *vma,
>  				  struct mm_walk *args, unsigned long *bitmap, unsigned long *first)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int i;
>  	bool dirty;
>  	pmd_t *pmd;
> @@ -3632,7 +3634,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
>  	if (!spin_trylock(ptl))
>  		goto done;
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		unsigned long pfn;
> @@ -3679,7 +3681,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
>
>  	walk_update_folio(walk, last, gen, dirty);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	spin_unlock(ptl);
>  done:
>  	*first = -1;
> @@ -4227,6 +4229,7 @@ static void lru_gen_age_node(struct pglist_data *pgdat, struct scan_control *sc)
>   */
>  bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int i;
>  	bool dirty;
>  	unsigned long start;
> @@ -4278,7 +4281,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
>  		}
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	pte -= (addr - start) / PAGE_SIZE;
>
> @@ -4312,7 +4315,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
>
>  	walk_update_folio(walk, last, gen, dirty);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>
>  	/* feedback from rmap walkers to page table walkers */
>  	if (mm_state && suitable_to_scan(i, young))
> --
> 2.47.0
>


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 17:34:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 17:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110572.1459701 (Exim 4.92)
	(envelope-from )
	id 1uuDqd-0002hk-Ej; Thu, 04 Sep 2025 17:34:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110572.1459701; Thu, 04 Sep 2025 17: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 1uuDqd-0002hd-BI; Thu, 04 Sep 2025 17:34:11 +0000
Received: by outflank-mailman (input) for mailman id 1110572;
 Thu, 04 Sep 2025 17:34:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuDqb-0002hX-G6
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 17:34:09 +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 5c606926-89b5-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 19:34:08 +0200 (CEST)
Received: from AS4PR03MB8676.eurprd03.prod.outlook.com (2603:10a6:20b:58c::8)
 by DB4PR03MB8563.eurprd03.prod.outlook.com (2603:10a6:10:38d::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 17:34:05 +0000
Received: from AS4PR03MB8676.eurprd03.prod.outlook.com
 ([fe80::c5ca:906a:1ded:634b]) by AS4PR03MB8676.eurprd03.prod.outlook.com
 ([fe80::c5ca:906a:1ded:634b%5]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 17:34: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: 5c606926-89b5-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LJ/gI+BqnYCuSrCNJbw9tA6qBEQJdHqKX6RqKl8XxpK/uPptnxxfN5qIvlsXyGE68UQ9qf6dfMVe8ot+n9UIEnXMXOnRziheqLBw7RYNA3vjjYDjtJtxSqtjNkAhlpm/WhXwlJKY9ep0TSSUWI+9GVEycCfPfL+e5shDKA7lFYRfrXdtqJHzV7296Xze4GRUIvIjI2VG33BcajV0ZoQOhApi95u0Ow74eOCkBOb9VBcxCKSuWDoETgYWQ3h9MMI+RHYzGM7Zr7H/yhRZi4UR7dzFr2tBfrTmagug/ozAqHNatBvBcEIXQ4Flj/iN2V7qw0/VJG9qUife9C17kVTnWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RkNHuK1VcK0638gjlQnu5hZIQ6U1caw6B5ct1s2KEfM=;
 b=Jwoi0Q/3MkPKTewGlvg73fldYmgPlMY/StM7rXuYrfxN1Sfbsx2zOmy0+Q5Etm37HWlWIer23dg+JPm3aX77yqUuOE/azA/GJRSAzHhMUtZwkrbJ9KWXI4Krvwhm64+D95qx6XxX2YQIg8QqzhOuPMH7OHejwk/BfsADGbWyvv5fGatxqQUgi/8SaXFkxy5XAjwrVMVX6g/8VpxKvbCgCF+s5YKfNiwQuv7mVGFer7h/urSrK/X++OFAAq76SbejNcSEdCXJAaJCr9n9ZbZu3Ge4jE7efkmK/TszvWnRqDrSBAOCXDTO9qnw+twulZnEnmCzJaMHGZcRa9t7AlekEA==
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=RkNHuK1VcK0638gjlQnu5hZIQ6U1caw6B5ct1s2KEfM=;
 b=hrvcglf5EB3UyekXOqx3+fDPUSERgQACoa+/V/510gpYcm4lKzZ8lrdrrZd8FyGZMuThJ5LSVkrKoO6os/C9gLbxIb8pDqlnUM/8poZiKVuTXaXgUqC7FzVdwiySGz1pcC81xtw9UCibXUkH6chGvLzam/UtOsI7x7pxAYzfPj9aVxeFQZKt11WXCV2FGUpo3dyqldv2GhXVYYgmNfKU8ofnHautOD4o8JetSndSA0UPjHKA1Zu9DlciT1FS6gOs3GlNeJZUMx7oYZ2ElHUotgb0f5caX5SDdR29evWghAk5MVAHlKy0Sk4Fz5VM/o4glfXOWmJzAbK9DljPeWWAIQ==
From: Leonid Komarianskyi 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: "olekstysh@gmail.com" , Stefano Stabellini
	, Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk 
Subject: Re: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Topic: [PATCH v6 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHN861IdGTmH+JEChpQbSpoZJ2bSC9NmAgAALmYCAAA/1AIAAOhEA
Date: Thu, 4 Sep 2025 17:34:05 +0000
Message-ID: 
References: 
 
 
 
 <10c41b57-d02b-44d4-af48-ac3ed2f416b5@xen.org>
In-Reply-To: <10c41b57-d02b-44d4-af48-ac3ed2f416b5@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: AS4PR03MB8676:EE_|DB4PR03MB8563:EE_
x-ms-office365-filtering-correlation-id: b8ebac53-4294-4441-7582-08ddebd93f14
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?MkpKenYvKy95VUJ0SG9jc3pxTDR1QlZUKzNSd3N0SUkzZS94ZE5FOU1NbGxQ?=
 =?utf-8?B?cWdLb2NYZ0J4cU5tbjJlQnZxaGJiUHVXcWREM1RackkrOWlVMHlJUXBZZS8r?=
 =?utf-8?B?L2tsVjk4TS9Wd3ZPbXRQa01HUndvK0ZJcS9vL3l1YktQWENvd3FiWC9CMHk4?=
 =?utf-8?B?N1FrZTQ2ZWpPdEJZRWlLSjJrQUI0TjExZWhodHNoTjRGT2VibkhZeWdhNm9W?=
 =?utf-8?B?T0x1bXljUmFIb3c0bEFDbU9YbXJIY1dNOThRZmU5MmMrTG11ZUtHVnM2VTNP?=
 =?utf-8?B?UDlXeW1EM21DekxIVmVTVi80dXQyS2xOeEtGQU5kME9wRGZ6RWJLVEIrY05I?=
 =?utf-8?B?VDZnTkpxMUhDM2ViaDkvc2VZbHBQaXdhTmpPV08yRWJZNjU5MkhzWHgycEVL?=
 =?utf-8?B?MkUrdDI2ekljZ0MrK2FjUFZKdUFNR0JtZllGUVdhSXJBVFlNVGtNeHErRFRT?=
 =?utf-8?B?VUgwNEpJd2NKcFh0UXB4dXRmblhCbHJSTDFtbCtPa1NCQ2h2ODYycDg4VzhG?=
 =?utf-8?B?bytncGJkRzdzUVhHUkJ2V2Q2NkFxM25Vd2VsM1FnckNEV3MvQmRWYi95eUlW?=
 =?utf-8?B?b0h3aERyampBMUpPaGFyQW1GR1ZxK0o1bFhndUFNeDIrNldTcU9ML05BSnRN?=
 =?utf-8?B?YWxodnAyblMrdnF1R2NuWWNhcUdleDNZaGdUTHc0U2RuWlFPcVVPYWlPVkEw?=
 =?utf-8?B?U3dFbjZsdXhWMExPdnV5c0p0bVBZRHAwYXRGOHZiWE1RREhxYXgvYkZBWHZl?=
 =?utf-8?B?cjVCV2dzUW5PQ2J0cjM0a1dTNjV3L1d5RU8zQU5VZng4UzJvZVRPTWZxTURp?=
 =?utf-8?B?dTRyUHE2cWg2MmxhcmgrYWZaR2duVEIySEhWd01zNTFyRlovTmQ2VEZYT2RZ?=
 =?utf-8?B?WXZBYit4TjZqZENtV0c3dnROWkdJdGdnRkRJU2VWYkI2QkprbDg1Y0Z6TlRt?=
 =?utf-8?B?V3F1a2poMEUza2xLNkVtRUJDNGx1U2JET3ZWWkNnRUs0TTN3TXVRRlhQRUtF?=
 =?utf-8?B?VnkrSnNSZEtYNitELzM4M3BBM3BnZCtoSExybWRKTlVFdi8yTHY0dlJiVE9N?=
 =?utf-8?B?ZDdqOEVWa0JXRU5YOWF4Y2Znb01JMlRLTml5QzZabXRnR3NENTZHanM4Qnh5?=
 =?utf-8?B?QVBwK0V0SUgvd25TeCt2NCtuK2wwVG1ET3ZLRWJKMG82N3Rkd2kvUHlyT0xr?=
 =?utf-8?B?a0dVRTJUTVpqV2F1ckRZT2VqWmVVOWRLMGFSYVh6aGxwNDBuRlJ1ZDdaNElU?=
 =?utf-8?B?NmRudE5NaS95MC90cktpOXVkYWhUTEtzUHdidGxkSUJEWHEwaVhTNFQrUy9k?=
 =?utf-8?B?SDh0clRYK1Z5czdNT3Z4UkwwZGFscGRIZDhSczNDTTBRekhVc1MzTCszeGdk?=
 =?utf-8?B?TGdBWnJrNEo2SEErMHd1UTY2eEcvRnhuckVwWTVFWmNEaWFqVW1HWDFWekV6?=
 =?utf-8?B?bjBNZVd0dVVJdHBhRlJrblF1ZDZhTEJKc3h5dmZJbnVBeHVEU3kxaEU1NGJm?=
 =?utf-8?B?WG4rWm5ZR1JxZlV4Y0owNWU1cWVUcGRhbCtWSFVNK0tjT2xsRmlDVVZEZnp3?=
 =?utf-8?B?Ni8rbmQ1MnN1bHRiZXhSVkthNmoxSEI2dzhvRmxGQmxyWG5DRGVwNXBSS3VZ?=
 =?utf-8?B?c2cyT1lUdVUzR1A3blpJY3h2YW9kM1gzWmZ3RHBUUm5yeDhaR0hwVGNpUi9D?=
 =?utf-8?B?ajFPQVkrSTVGY3MrY1RoSXhvU2N1OTNBL3ZaV1JpWVZ1dXFwS3dwUXVSNmlX?=
 =?utf-8?B?Q0w2MDRtN0hZMFEveDhWUGt5ajRIRUVkTk9VdTdTZnRFNVp1TUN4blRDWTZZ?=
 =?utf-8?B?VXZmVGhlZ1FMNjdDQ0xmZUxTVlNvQk1pL0toL0VFMmZ5QW5STG91ajZMMkxI?=
 =?utf-8?B?cXNxUmxyQTNaWnVTb2RTckEvaHlKS0tIRy9RK0VwckVIdFB1dzFTcVV3OXZa?=
 =?utf-8?B?ZVA5VFNQaDJIT0Q5R0xxa0dkcXVGV2ZqWGlkNzRlZG9qaHFYa1FDd2hibUFR?=
 =?utf-8?B?SlhzdFM4RzBBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS4PR03MB8676.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RzJheUt5WWhMQ1lPRXU1N3M1S29SMVNET3FpbUw1RlRXME5MTnl0THhTY1ZY?=
 =?utf-8?B?ZHhrd1FNclAvbmUrWjU0eHRYRmtWRlAwOGtNK2FSWUk5eDBtbXA1TytXckhS?=
 =?utf-8?B?ZFVrTFgxcThjUnJuMTI2MlNRenBSMzBGMWhFNjR4N2cwK2F0cm84MHRKMGdC?=
 =?utf-8?B?RVR4dlJUczNOQUZnamtlVUVNWnhMTkp5N0NDczZ6QTEyZXFDWDh4dllwdEtj?=
 =?utf-8?B?N3JvakFNNHNCcHplQ1NUeGw1eTVNNjBoVU4rOHc5bDJOWTNTNE5JZGRDcTBH?=
 =?utf-8?B?N0VubjRvZjNrdG8wSnd3K0xNR2FYRk1LZm5FK3VwTU9mdjZLUjZFV3N3VjRV?=
 =?utf-8?B?a2cyWmRSWVpSZTN0bWNtMWVDUldPdU1ZQnpFV05jd2Q1dzI5b05YR2lKamRu?=
 =?utf-8?B?RExlbGY1U2lIcHJiRWpxejlOL1psY2REUEpBOG1ZejBZOENsOEJFcTlxQmx1?=
 =?utf-8?B?UDQycjM0NEx1WGNFbXVqam1iSnBYbHdsSHF6aEFRUUpnM1VhVWFEQkNiY0FW?=
 =?utf-8?B?UE5pTUVyZ2Qvd2xqY2FLZko4SUtXYW5waUxZZXZEZVVOa29wc2pwNFlRdTVv?=
 =?utf-8?B?S1JpRXV5ZXloTTVxYWNKNTVpMGJqWWE0blJ2SDFBQUZkcE50bjZzYnk4bDV2?=
 =?utf-8?B?djdUT3B6MDlCQWVuemMyQjZBd0hFSzdyUUVPZzFLT2hoYUtPb3UvZkxyOWdr?=
 =?utf-8?B?eEVoSFkzMU9zeDBMWDhVbXVUaGRDK1lRSzFiY0RmNmdjaUw3cktObmpiQ0Vw?=
 =?utf-8?B?NS9TblVnVmdqL2NQT3F1YXFFRUI5dGVmbjFlcUhBU2RJZStSZ3l2S05GWE1P?=
 =?utf-8?B?aC9pK3IrOTh3V1FGVTJBMGtTdHQ3YWFrTXF4cU5EL1JVSlUxOGRmZyszL1pO?=
 =?utf-8?B?cWo0TEYyeDlFdjJKb2V2WGRyWC9HRzc0M1Bua0UxMGNjRlNwYUtwZTZXalVY?=
 =?utf-8?B?amFSYkQ5U1NzcVphUCt3NmZXUVdnRGg3R1RPZ21XRXIwWTl2K3FNYlVhenpJ?=
 =?utf-8?B?V3Y1SmZteitDdU5Lc2tJamliRHk2ZjBjU3kxaWZzeC9QcldNUXV5dXdRS1NH?=
 =?utf-8?B?S3dDOGgxdTViWTdmWWo5TjZTdWF6TXJvTEJjaHFQeUNPa1F3Tld5S1owRTI1?=
 =?utf-8?B?a0wwVUZESVdYVVd1bXRTYmpjbGlld05BYTVZMXhpckdpQlBJcE1TRkJRbVNu?=
 =?utf-8?B?ejdQRW9NUWFvd3VROS9LTGVYV0QrZklHOW1lU0FmK0VlNVJxQVFxR3ZVYitx?=
 =?utf-8?B?WVNtc0lyRVZjWHBXMTc3Y05JWGFDR2FISWpVb29WNzN3c1Z3ZGp6OEt3Wk9n?=
 =?utf-8?B?N2htbFMzb244SDJ2TGJnMlNCK01XdUVXRGlRa21wdlp5dzNVanBDYWR1ZXlG?=
 =?utf-8?B?L21aZlVaOVRpc1ArdGNKejYrQU5USlVkci91L2lqbGJXSDB2amYzZHMxTUEz?=
 =?utf-8?B?TllDaWVlU1o3V3lxUENueG5QcEM3K2ZmWGZiSEEwazUxV2xkVUpuZzBMT1p1?=
 =?utf-8?B?czk3K2kvZExmLzJMVS9QOE4zMVVGUnBaOFZYK3VXZ1VsZ1hUN1ozdFhiYkNZ?=
 =?utf-8?B?K0M5LzR5OGRvZkI4bTEvNkRsVi9mVzVjaHFySzkvT2FCK3R6MnphL0dDNWQx?=
 =?utf-8?B?WnA4UzdWa0EyV1V5bmRjcFJVMkdJbERiYkg1WmdhMTAyNGVQdjVMcCt0WS92?=
 =?utf-8?B?MGMxaGkvNmczUzNGWkVCT04rWlZPbWhNdXhiK2RseC91ckVJU0Y2QlhVdlBn?=
 =?utf-8?B?OWV6bEszUE05NDdVVzFVNWhIZ09MQ0dnYkYyeWtPY2NDTnZTR0FZclJoQllU?=
 =?utf-8?B?bVJVcTFNajVvWllud1B1S3ZWUXQ5WERMNXFJNHc3Yk16aXRBUEZicTh3QnZD?=
 =?utf-8?B?TzN2UFE3ajJLNWRJQmFReHpYOXpDWWZZa1RLYzBpOEJYWUpDekNtNGZRSHBU?=
 =?utf-8?B?Y29DNDNOampEV0kyM2RTcjdyZzhhSGt3OVdaZ3l1Y25vWlBWRUlsbDB0RFpm?=
 =?utf-8?B?aVduWlVkdnFHcWFvYXNSd1FyYTFOdDJuUkw4aHowOHl0WG5ocXFpTUFpeGwy?=
 =?utf-8?B?VWpSVnhGd1dna2trOVVFRTh4YUh2T2ljd2xKNlkwTnp6N0xta05iaE5zZDdG?=
 =?utf-8?B?a3diMnNZSjNuM00rdWlIRzZIN3VINEx3c3RlTEd1dWNmVFFGVGRrNkJWN0hz?=
 =?utf-8?Q?JrOSBKoOE5jrcmAAabCMxB0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <13C4CF71945A6947BBA0308D15A54BF7@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: AS4PR03MB8676.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8ebac53-4294-4441-7582-08ddebd93f14
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 17:34:05.5029
 (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: t7OhcNx1EBKQqyPJ4wdETZowpt6I5gDt0/wbnAUR/5Nf5F6d/uTTJikcFqgCDCoHsjJgHXhXJxfY7uSQnMgCTxCe9VOaKncbaSzEVRYYf7s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB8563

SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQoNCk9uIDA0LjA5LjI1
IDE3OjA2LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIExlb25pZCwNCj4gDQo+IE9uIDA0LzA5
LzIwMjUgMTQ6MDksIExlb25pZCBLb21hcmlhbnNreWkgd3JvdGU6DQo+PiBPbiAwNC4wOS4yNSAx
NToyNywgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+IEhpIExlb25pZCwNCj4+Pg0KPj4+IE9uIDAz
LzA5LzIwMjUgMTU6MjksIExlb25pZCBLb21hcmlhbnNreWkgd3JvdGU6DQo+Pj4+IC0tLQ0KPj4+
PiDCoMKgIHhlbi9hcmNoL2FybS9LY29uZmlnwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDggKysr
KysNCj4+Pj4gwqDCoCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaXJxLmggfCAzNyArKysrKysr
KysrKysrKysrKysrKysrKysNCj4+Pj4gwqDCoCB4ZW4vYXJjaC9hcm0vaXJxLmPCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgfCA1MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKyANCj4+Pj4g
KysrLS0NCj4+Pj4gwqDCoCAzIGZpbGVzIGNoYW5nZWQsIDk2IGluc2VydGlvbnMoKyksIDIgZGVs
ZXRpb25zKC0pDQo+Pj4+DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vS2NvbmZpZyBi
L3hlbi9hcmNoL2FybS9LY29uZmlnDQo+Pj4+IGluZGV4IDE3ZGYxNDdiMjUuLjQzYjA1NTMzYjEg
MTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS9LY29uZmlnDQo+Pj4+ICsrKyBiL3hlbi9h
cmNoL2FybS9LY29uZmlnDQo+Pj4+IEBAIC0xMzUsNiArMTM1LDE0IEBAIGNvbmZpZyBHSUNWMw0K
Pj4+PiDCoMKgwqDCoMKgwqDCoMKgIERyaXZlciBmb3IgdGhlIEFSTSBHZW5lcmljIEludGVycnVw
dCBDb250cm9sbGVyIHYzLg0KPj4+PiDCoMKgwqDCoMKgwqDCoMKgIElmIHVuc3VyZSwgdXNlIHRo
ZSBkZWZhdWx0IHNldHRpbmcuDQo+Pj4+ICtjb25maWcgR0lDVjNfRVNQSQ0KPj4+PiArwqDCoMKg
IGJvb2wgIkV4dGVuZGVkIFNQSSByYW5nZSBzdXBwb3J0Ig0KPj4+PiArwqDCoMKgIGRlcGVuZHMg
b24gR0lDVjMgJiYgIU5FV19WR0lDDQo+Pj4+ICvCoMKgwqAgaGVscA0KPj4+PiArwqDCoMKgwqDC
oCBBbGxvdyBYZW4gYW5kIGRvbWFpbnMgdG8gdXNlIGludGVycnVwdCBudW1iZXJzIGZyb20gdGhl
DQo+Pj4+IGV4dGVuZGVkIFNQSQ0KPj4+PiArwqDCoMKgwqDCoCByYW5nZSwgZnJvbSA0MDk2IHRv
IDUxMTkuIFRoaXMgZmVhdHVyZSBpcyBpbnRyb2R1Y2VkIGluIEdJQ3YzLjENCj4+Pj4gK8KgwqDC
oMKgwqAgYXJjaGl0ZWN0dXJlLg0KPj4+PiArDQo+Pj4+IMKgwqAgY29uZmlnIEhBU19JVFMNCj4+
Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgYm9vbCAiR0lDdjMgSVRTIE1TSSBjb250cm9sbGVyIHN1
cHBvcnQgKFVOU1VQUE9SVEVEKSIgaWYNCj4+Pj4gVU5TVVBQT1JURUQNCj4+Pj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqAgZGVwZW5kcyBvbiBHSUNWMyAmJiAhTkVXX1ZHSUMgJiYgIUFSTV8zMg0KPj4+
PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oIGIveGVuL2FyY2gv
YXJtL2luY2x1ZGUvDQo+Pj4+IGFzbS9pcnEuaA0KPj4+PiBpbmRleCA1YmM2NDc1ZWI0Li5mNGQw
OTk3NjUxIDEwMDY0NA0KPj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaXJxLmgN
Cj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lycS5oDQo+Pj4+IEBAIC0zMiw2
ICszMiwxMCBAQCBzdHJ1Y3QgYXJjaF9pcnFfZGVzYyB7DQo+Pj4+IMKgwqAgI2RlZmluZSBTUElf
TUFYX0lOVElEwqDCoCAxMDE5DQo+Pj4+IMKgwqAgI2RlZmluZSBMUElfT0ZGU0VUwqDCoMKgwqDC
oCA4MTkyDQo+Pj4+ICsjZGVmaW5lIEVTUElfQkFTRV9JTlRJRCA0MDk2DQo+Pj4+ICsjZGVmaW5l
IEVTUElfTUFYX0lOVElEwqAgNTExOQ0KPj4+PiArI2RlZmluZSBOUl9FU1BJX0lSUVPCoMKgwqAg
MTAyNA0KPj4+PiArDQo+Pj4+IMKgwqAgLyogTFBJcyBhcmUgYWx3YXlzIG51bWJlcmVkIHN0YXJ0
aW5nIGF0IDgxOTIsIHNvIDAgaXMgYSBnb29kIGludmFsaWQNCj4+Pj4gY2FzZS4gKi8NCj4+Pj4g
wqDCoCAjZGVmaW5lIElOVkFMSURfTFBJwqDCoMKgwqAgMA0KPj4+PiBAQCAtMzksNyArNDMsMTIg
QEAgc3RydWN0IGFyY2hfaXJxX2Rlc2Mgew0KPj4+PiDCoMKgICNkZWZpbmUgSU5WQUxJRF9JUlHC
oMKgwqDCoCAxMDIzDQo+Pj4+IMKgwqAgZXh0ZXJuIGNvbnN0IHVuc2lnbmVkIGludCBucl9pcnFz
Ow0KPj4+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+Pj4+ICsvKiBUaGlzIHdpbGwgY292
ZXIgdGhlIGVTUEkgcmFuZ2UsIHRvIGFsbG93IGFzaWdubWFudCBvZiBlU1BJcyB0bw0KPj4+PiBk
b21haW5zLiAqLw0KPj4+PiArI2RlZmluZSBucl9zdGF0aWNfaXJxcyAoRVNQSV9NQVhfSU5USUQg
KyAxKQ0KPj4+PiArI2Vsc2UNCj4+Pj4gwqDCoCAjZGVmaW5lIG5yX3N0YXRpY19pcnFzIE5SX0lS
UVMNCj4+Pj4gKyNlbmRpZg0KPj4+PiDCoMKgIHN0cnVjdCBpcnFfZGVzYzsNCj4+Pj4gwqDCoCBz
dHJ1Y3QgaXJxYWN0aW9uOw0KPj4+PiBAQCAtNTUsNiArNjQsMzQgQEAgc3RhdGljIGlubGluZSBi
b29sIGlzX2xwaSh1bnNpZ25lZCBpbnQgaXJxKQ0KPj4+PiDCoMKgwqDCoMKgwqAgcmV0dXJuIGly
cSA+PSBMUElfT0ZGU0VUOw0KPj4+PiDCoMKgIH0NCj4+Pj4gK3N0YXRpYyBpbmxpbmUgdW5zaWdu
ZWQgaW50IGVzcGlfaW50aWRfdG9faWR4KHVuc2lnbmVkIGludCBpbnRpZCkNCj4+Pj4gK3sNCj4+
Pj4gK8KgwqDCoCBBU1NFUlQoaW50aWQgPj0gRVNQSV9CQVNFX0lOVElEICYmIGludGlkIDw9IEVT
UElfTUFYX0lOVElEKTsNCj4+Pg0KPj4+IENhbiB3ZSB1c2UgaXNfZXNwaSgpPw0KPj4+DQo+Pg0K
Pj4gWWVzLCBzdXJlLiBJIGp1c3QgbmVlZCB0byBjaGFuZ2UgdGhlIGZ1bmN0aW9uIGRlY2xhcmF0
aW9uIG9yZGVyIGFuZCB0aGVuDQo+PiBJIGNhbiB1c2UgaXNfZXNwaSgpIGhlcmUuIEkgd2lsbCBk
byB0aGlzIGluIFY3Lg0KPj4NCj4+Pj4gK8KgwqDCoCByZXR1cm4gaW50aWQgLSBFU1BJX0JBU0Vf
SU5USUQ7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50
IGVzcGlfaWR4X3RvX2ludGlkKHVuc2lnbmVkIGludCBpZHgpDQo+Pj4+ICt7DQo+Pj4+ICvCoMKg
wqAgQVNTRVJUKGlkeCA8PSBOUl9FU1BJX0lSUVMpOw0KPj4+PiArwqDCoMKgIHJldHVybiBpZHgg
KyBFU1BJX0JBU0VfSU5USUQ7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK3N0YXRpYyBpbmxpbmUg
Ym9vbCBpc19lc3BpKHVuc2lnbmVkIGludCBpcnEpDQo+Pj4+ICt7DQo+Pj4+ICsjaWZkZWYgQ09O
RklHX0dJQ1YzX0VTUEkNCj4+Pj4gK8KgwqDCoCByZXR1cm4gaXJxID49IEVTUElfQkFTRV9JTlRJ
RCAmJiBpcnEgPD0gRVNQSV9NQVhfSU5USUQ7DQo+Pj4+ICsjZWxzZQ0KPj4+PiArwqDCoMKgIC8q
DQo+Pj4+ICvCoMKgwqDCoCAqIFRoZSBmdW5jdGlvbiBzaG91bGQgbm90IGJlIGNhbGxlZCBmb3Ig
ZVNQSXMgd2hlbg0KPj4+PiBDT05GSUdfR0lDVjNfRVNQSSBpcw0KPj4+PiArwqDCoMKgwqAgKiBk
aXNhYmxlZC4gUmV0dXJuaW5nIGZhbHNlIGFsbG93cyB0aGUgY29tcGlsZXIgdG8gb3B0aW1pemUg
dGhlDQo+Pj4+IGNvZGUNCj4+Pj4gK8KgwqDCoMKgICogd2hlbiB0aGUgY29uZmlnIGlzIGRpc2Fi
bGVkLCB3aGlsZSB0aGUgYXNzZXJ0IGVuc3VyZXMgdGhhdA0KPj4+PiBvdXQtb2YtcmFuZ2UNCj4+
Pj4gK8KgwqDCoMKgICogYXJyYXkgcmVzb3VyY2VzIGFyZSBub3QgYWNjZXNzZWQsIGUuZy4sIGlu
IF9faXJxX3RvX2Rlc2MoKS4NCj4+Pj4gK8KgwqDCoMKgICovDQo+Pj4+ICvCoMKgwqAgQVNTRVJU
KGlycSA+PSBFU1BJX0JBU0VfSU5USUQpOw0KPj4+DQo+Pj4gUmVnYXJkbGVzcyB3aGF0IFZvbG9k
eW15ciBtZW50aW9uZWQgYWJvdXQgdGhlIGFzc2VydCEoKSwgSSBhbSBhIGJpdA0KPj4+IHVuc3Vy
ZSB3aGVyZSB3ZSBndWFyYW50ZWUgaXNfZXNwaSgpIHdpbGwgbm90IGJlIGNhbGxlZCB3aXRoIGFu
IGlycSA8PQ0KPj4+IEVTUElfQkFTRV9JTlRJRC4gSW4gZmFjdCwgd2UgY291bGQgaGF2ZSB0aGUg
Zm9sbG93aW5nIGNvZGUgaW4gWGVuOg0KPj4+DQo+Pj4gaWYgKGlzX2VzcGkoaXJxKSkNCj4+PiB7
DQo+Pj4gfQ0KPj4+IGVsc2UgaWYgKGlzX2xwaShpcnEpKQ0KPj4+IHsNCj4+PiB9DQo+Pj4gZWxz
ZQ0KPj4+IHsNCj4+PiB9DQo+Pj4NCj4+PiBXZSBjb3VsZCByZXBsYWNlIHRoZSBjaGVjayB3aXRo
ICIhKGlycSA+PSBFU1BJX0JBU0VfSU5USUQgJiYgaXJxIDw9DQo+Pj4gRVNQSV9NQVhfSU5USUQp
Ii4gQnV0IEkgd291bGQgYWN0dWFsbHkgcHJlZmVyIGlmIHRoZXJlIGlzIG5vIGNoZWNrDQo+Pj4g
YmVjYXVzZSBJIGRvbid0IHNlZSB0aGUgdmFsdWUuDQo+Pj4NCj4+DQo+PiBUaGUgbWFpbiByZWFz
b24gdG8gYWRkIEFTU0VSVCBoZXJlIGlzIHRvIHRyaWdnZXIgaXQgaWYgdGhlIGNvbmZpZyBpcw0K
Pj4gZGlzYWJsZWQgYnV0IGFuIGVTUEkgSU5USUQgaXMgZGVmaW5lZCBpbiBYZW4gRFRTLiANCj4g
DQo+IEkgd2lsbCBub3QgaW5zaXN0IG9uIHJlbW92ZSB0aGUgQVNTRVJUKCkuIEhvd2V2ZXIsIGl0
IGNvdWxkIGNvcnJlY3QgYW5kIA0KPiB3ZSBzaG91bGQgYXZvaWQgcmVseWluZyBvbiBBU1NFUlQo
KSB0byBjYXRjaCBEVFMgYnVncy4gQmVjYXVzZS4uLg0KPiANCg0KWWVzLCBJIGFncmVlIHdpdGgg
dGhhdCwgYnV0IEkganVzdCBjaGVja2VkIHNvbWV0aGluZyBlbHNlIC0gSSB0cmllZCANCnVzaW5n
IG1haW5saW5lIFhlbiAod2l0aG91dCBlU1BJIHBhdGNoZXMpIGFuZCBkZWZpbmVkIGFuIGludmFs
aWQgSVJRIA0KKDB4MTEwYTAwKSBmb3IgYSBkZXZpY2UgaW4gdGhlIFhlbiBEVFM6DQoNCmludGVy
cnVwdHMgPSA8MHgwMCAweDExMGEwMCAweDA0PjsNCg0KQW5kIFhlbiBjcmFzaGVkIHdpdGggYSBk
YXRhIGFib3J0IHdoaWxlIHN0YXJ0aW5nIERvbTA6DQoNCihYRU4pICoqKiBMT0FESU5HIERPTUFJ
TiAwICoqKg0KKFhFTikgTG9hZGluZyBkMCBrZXJuZWwgZnJvbSBib290IG1vZHVsZSBAIDAwMDAw
MDAwN2EwMDAwMDANCihYRU4pIExvYWRpbmcgcmFtZGlzayBmcm9tIGJvb3QgbW9kdWxlIEAgMDAw
MDAwMDA1NTk2NDAwMA0KKFhFTikgR3JhbnQgdGFibGUgcmFuZ2U6IDB4MDAwMDAwNzgyMDAwMDAt
MHgwMDAwMDA3ODI0MDAwMA0KKFhFTikgQWxsb2NhdGluZyAxOjEgbWFwcGluZ3MgdG90YWxsaW5n
IDUxMk1CIGZvciBkb20wOg0KKFhFTikgQkFOS1swXSAweDAwMDAwMDY4MDAwMDAwLTB4MDAwMDAw
NzgwMDAwMDAgKDI1Nk1CKQ0KKFhFTikgQkFOS1sxXSAweDAwMDAxMGQwMDAwMDAwLTB4MDAwMDEw
ZTAwMDAwMDAgKDI1Nk1CKQ0KKFhFTikgRGF0YSBBYm9ydCBUcmFwLiBTeW5kcm9tZT0weDYNCihY
RU4pIFdhbGtpbmcgSHlwZXJ2aXNvciBWQSAweGEwMDA4Yjk5MWE0IG9uIENQVTAgdmlhIFRUQlIg
DQoweDAwMDAwMDAwNzgzNDgwMDANCihYRU4pIDBUSFsweDAxNF0gPSAweDc4MzQ3ZjdmDQooWEVO
KSAxU1RbMHgwMDBdID0gMHg3ODM0NmY3Zg0KKFhFTikgMk5EWzB4MDQ1XSA9IDB4MA0KKFhFTikg
Q1BVMDogVW5leHBlY3RlZCBUcmFwOiBEYXRhIEFib3J0DQooWEVOKSAtLS0tWyBYZW4tNC4yMS11
bnN0YWJsZSAgYXJtNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBDUFU6ICAg
IDANCihYRU4pIFBDOiAgICAgMDAwMDBhMDAwMDIyODVjOCBfc3Bpbl9sb2NrKzB4NDAvMHhhNA0K
KFhFTikgTFI6ICAgICAwMDAwMGEwMDAwMjI4NWIwDQooWEVOKSBTUDogICAgIDAwMDAwYTAwMDAz
MjYyMTANCihYRU4pIENQU1I6ICAgMDAwMDAwMDA2MDAwMDJjOSBNT0RFOjY0LWJpdCBFTDJoIChI
eXBlcnZpc29yLCBoYW5kbGVyKQ0KKFhFTikgICAgICBYMDogMDAwMDBhMDAwMDMzMDA1OCAgWDE6
IDAwMDAwMDAwMDAwMDAwMDEgIFgyOiAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSAgICAgIFgzOiAw
MDAwMDAwMDAwMDAwMDAwICBYNDogMDAwMDAwMDAwMDAwMDAwMCAgWDU6IDAwMDAwYTAwMDAzMzAx
MzANCihYRU4pICAgICAgWDY6IDAwMDAwMDAwMDAwMDAwMDAgIFg3OiAwMDAwODAwZmJmZmRmOWIw
ICBYODogN2Y3ZjdmN2Y3ZjdmN2Y3Zg0KKFhFTikgICAgICBYOTogMDAwMDAwMDAwMDAwMDA4MCBY
MTA6IDAxMDEwMTAxMDEwMTAxMDEgWDExOiAwMDAwMDAwMDAwMDAwMDMwDQooWEVOKSAgICAgWDEy
OiAwMDAwMDAwMDAwMDAwMDI4IFgxMzogZmYwMDAwMDAwMDAwMDAwMCBYMTQ6IDAwMDAwMDAwMDQw
MDAwMDANCihYRU4pICAgICBYMTU6IDAwODAwMDAwMDAwMDAwMDAgWDE2OiAwMDAwMDAwMDAwMGZm
ZmZmIFgxNzogMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgICAgIFgxODogMDAwMDAwMDBiYmZlZmQy
MCBYMTk6IDAwMDAwYTAwMDhiOTkxYTQgWDIwOiAwMDAwMDAwMDAwMDEwMDAwDQooWEVOKSAgICAg
WDIxOiAwMDAwMGEwMDA4Yjk5MWE4IFgyMjogMDAwMDAwMDAwMDAwMDAwNCBYMjM6IDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pICAgICBYMjQ6IDAwMDAwMDAwMDAwMDAwMDAgWDI1OiAwMDAwODAwZmJm
ZmNjOTgwIFgyNjogMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgICAgIFgyNzogMDAwMDAwMDAwMDE3
MzAwMCBYMjg6IDAwMDAwMDAwNDgxYTgwNjAgIEZQOiAwMDAwMGEwMDAwMzI2MjEwDQooWEVOKQ0K
KFhFTikgICBWVENSX0VMMjogMDAwMDAwMDA4MDBkMzU5MA0KKFhFTikgIFZUVEJSX0VMMjogMDAw
MDAwMDAwMDAwMDAwMA0KKFhFTikNCihYRU4pICBTQ1RMUl9FTDI6IDAwMDAwMDAwMzBjZDE4M2QN
CihYRU4pICAgIEhDUl9FTDI6IDAwMDAwMDAwODAwMDAwMzgNCihYRU4pICBUVEJSMF9FTDI6IDAw
MDAwMDAwNzgzNDgwMDANCihYRU4pDQooWEVOKSAgICBFU1JfRUwyOiAwMDAwMDAwMDk2MDAwMDA2
DQooWEVOKSAgSFBGQVJfRUwyOiAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSAgICBGQVJfRUwyOiAw
MDAwMGEwMDA4Yjk5MWE0DQooWEVOKQ0KLi4uLg0KKFhFTikgWGVuIGNhbGwgdHJhY2U6DQooWEVO
KSAgICBbPDAwMDAwYTAwMDAyMjg1Yzg+XSBfc3Bpbl9sb2NrKzB4NDAvMHhhNCAoUEMpDQooWEVO
KSAgICBbPDAwMDAwYTAwMDAyMjg1YjA+XSBfc3Bpbl9sb2NrKzB4MjgvMHhhNCAoTFIpDQooWEVO
KSAgICBbPDAwMDAwYTAwMDAyMjg3MmM+XSBfc3Bpbl9sb2NrX2lycXNhdmUrMHgxOC8weDI4DQoo
WEVOKSAgICBbPDAwMDAwYTAwMDAyNzhlOWM+XSBpcnFfc2V0X3NwaV90eXBlKzB4MzQvMHg3OA0K
KFhFTikgICAgWzwwMDAwMGEwMDAwMjc5MDM0Pl0gaXJxX3NldF90eXBlKzB4MTU0LzB4MTZjDQoo
WEVOKSAgICBbPDAwMDAwYTAwMDAyNzkwNzQ+XSBwbGF0Zm9ybV9nZXRfaXJxKzB4MjgvMHg0NA0K
KFhFTikgICAgWzwwMDAwMGEwMDAwMmUxODhjPl0gZG9tYWluX2J1aWxkLmMjaGFuZGxlX25vZGUr
MHgxMDAvMHg3YjANCihYRU4pICAgIFs8MDAwMDBhMDAwMDJlMWRhYz5dIGRvbWFpbl9idWlsZC5j
I2hhbmRsZV9ub2RlKzB4NjIwLzB4N2IwDQooWEVOKSAgICBbPDAwMDAwYTAwMDAyZTFkYWM+XSBk
b21haW5fYnVpbGQuYyNoYW5kbGVfbm9kZSsweDYyMC8weDdiMA0KKFhFTikgICAgWzwwMDAwMGEw
MDAwMmUyNGU4Pl0gY29uc3RydWN0X2h3ZG9tKzB4M2Y0LzB4NGJjDQooWEVOKSAgICBbPDAwMDAw
YTAwMDAyZTI2NTA+XSBkb21haW5fYnVpbGQuYyNjb25zdHJ1Y3RfZG9tMCsweGEwLzB4YjQNCihY
RU4pICAgIFs8MDAwMDBhMDAwMDJlMjczYz5dIGNyZWF0ZV9kb20wKzB4ZDgvMHgxMWMNCihYRU4p
ICAgIFs8MDAwMDBhMDAwMDJlODdlOD5dIHN0YXJ0X3hlbisweDhiYy8weDk4Yw0KKFhFTikgICAg
WzwwMDAwMGEwMDAwMjAwMWE0Pl0gaGVhZC5vI3ByaW1hcnlfc3dpdGNoZWQrMHg0LzB4MjQNCihY
RU4pDQooWEVOKQ0KKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Kg0KKFhFTikgUGFuaWMgb24gQ1BVIDA6DQooWEVOKSBDUFUwOiBVbmV4cGVjdGVkIFRyYXA6IERh
dGEgQWJvcnQNCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cg0KDQpDdXJyZW50bHksIFhlbiBkb2VzIG5vdCB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIGludGVy
cnVwdCBudW1iZXJzIGRlZmluZWQgDQppbiB0aGUgRFRTIGZpbGUuIFRoaXMgc2hvdWxkIGRlZmlu
aXRlbHkgYmUgYWRkcmVzc2VkIGVsc2V3aGVyZSBhbmQgbm90IA0KanVzdCBmb3IgdGhlIGVTUEkg
cmFuZ2UsIGJ1dCBhdCBsZWFzdCB0aGUgQVNTRVJUIGZvciBlU1BJcyB3aWxsIG5vdCBtYWtlIA0K
dGhpbmdzIHdvcnNlLiBQZXJoYXBzIHRoZSBpc3N1ZSB3aXRoIElSUSBudW1iZXIgdmFsaWRhdGlv
biBzaG91bGQgYmUgDQpmaXhlZCBpbiBhIHNlcGFyYXRlIHBhdGNoIHNlcmllcy4gSSB3aWxsIHRy
eSB0byBsb29rIGludG8gdGhpcyBpc3N1ZSANCmFmdGVyIGVTUEkgYW5kIGR5bmFtaWMgYWxsb2Nh
dGlvbiBmb3IgaXJxX2Rlc2NfdCBhcnJheS4NCg0KPj4gSW4gdGhpcyBjYXNlLCBpbnN0ZWFkDQo+
PiBvZiB0cmlnZ2VyaW5nIGFuIEFTU0VSVCAoYXMgcHJvcG9zZWQpLCB0aGUgZm9sbG93aW5nIHdp
bGwgb2NjdXIgaW4NCj4+IF9faXJxX3RvX2Rlc2M6DQo+Pg0KPj4gLy8gQXNzdW1lIHdlIGhhdmUg
aXJxID0gNDA5Ng0KPj4gc3RydWN0IGlycV9kZXNjICpfX2lycV90b19kZXNjKHVuc2lnbmVkIGlu
dCBpcnEpDQo+PiB7DQo+PiDCoMKgwqDCoMKgIC8vIFRoaXMgY2hlY2sgd2lsbCByZXR1cm4gZmFs
c2UNCj4+IMKgwqDCoMKgwqAgaWYgKCBpcnEgPCBOUl9MT0NBTF9JUlFTICkNCj4+IMKgwqDCoMKg
wqDCoMKgwqDCoCByZXR1cm4gJnRoaXNfY3B1KGxvY2FsX2lycV9kZXNjKVtpcnFdOw0KPj4NCj4+
IMKgwqDCoMKgwqAgLyoNCj4+IMKgwqDCoMKgwqDCoCAqIFRoaXMgY2hlY2sgd2lsbCBhbHNvIHJl
dHVybiBmYWxzZSBiZWNhdXNlIGlzX2VzcGkoKQ0KPj4gwqDCoMKgwqDCoMKgICogd2lsbCBhbHdh
eXMgcmV0dXJuIGZhbHNlIHdoZW4gQ09ORklHX0dJQ1YzX0VTUEk9bi4NCj4+IMKgwqDCoMKgwqDC
oCAqLw0KPj4gwqDCoMKgwqDCoCBpZiAoIGlzX2VzcGkoaXJxKSApDQo+PiDCoMKgwqDCoMKgwqDC
oMKgwqAgcmV0dXJuIGVzcGlfdG9fZGVzYyhpcnEpOw0KPj4NCj4+IMKgwqDCoMKgwqAgLyoNCj4+
IMKgwqDCoMKgwqDCoCAqIFdlIHdpbGwgZmFsbCB0aHJvdWdoIHRvIHRoaXMgcG9pbnQgYW5kIGF0
dGVtcHQgdG8gYWNjZXNzIDQwNjQsDQo+PiDCoMKgwqDCoMKgwqAgKiB3aGljaCBkb2VzIG5vdCBl
eGlzdA0KPj4gwqDCoMKgwqDCoMKgICovDQo+PiDCoMKgwqDCoMKgIHJldHVybiAmaXJxX2Rlc2Nb
aXJxLU5SX0xPQ0FMX0lSUVNdOw0KPj4gfQ0KPj4NCj4+IFNvLCBJIHRoaW5rIGl0J3MgYmV0dGVy
IHRvIHVzZSBBU1NFUlQgdG8gc2ltcGxpZnkgZXJyb3IgZGV0ZWN0aW9uIGluDQo+PiBkZWJ1ZyBi
dWlsZHMuDQo+IA0KPiAuLi4gbm8gZXZlcnlvbmUgd2lsbCB1c2UgZGVidWcgYnVpbGQuIFNvIGlm
IHRoaXMgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIA0KPiBBU1NFUlQoKSB0aGVuIHdlIG5lZWQgdG8g
aGF2ZSBhbm90aGVyIHJ1bnRpbWUgY2hlY2sgZHVyaW5nIHRoZSBwYXJzaW5nIA0KPiBvZiB0aGUg
RFRTLg0KPiANCj4gQ2hlZXJzLA0KPiANCg0KQmVzdCByZWdhcmRzLA0KTGVvbmlkDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 18:12:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 18:12:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110610.1459710 (Exim 4.92)
	(envelope-from )
	id 1uuERr-0007tP-4z; Thu, 04 Sep 2025 18:12:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110610.1459710; Thu, 04 Sep 2025 18: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 1uuERr-0007tI-2P; Thu, 04 Sep 2025 18:12:39 +0000
Received: by outflank-mailman (input) for mailman id 1110610;
 Thu, 04 Sep 2025 18:12:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuERp-0007tA-Vv
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 18:12:38 +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 bbbfeab0-89ba-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 20:12:35 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3df2f4aedc7so812328f8f.2
 for ; Thu, 04 Sep 2025 11:12:35 -0700 (PDT)
Received: from [10.17.76.214] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e23d29bb9esm1904026f8f.4.2025.09.04.11.12.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 11:12: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: bbbfeab0-89ba-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757009555; x=1757614355; 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=z0UUr3AwLcLrhB6YEzODmxI4kys16aqgKfK/o2RcQ2E=;
        b=O8gC+gukgsa5QjEHu5s1yhd6T+rzX7PpXNZpcp/wAVWuKEimNhkMOru50F0XIVL0sJ
         NXgHHG4jqb0u1i8h8JfLysFf/egDk88IZiTt1Udvn1apy533JpWCLIyWi5pT2CMRh/gR
         XQTc9MvzPxuEzX70nBOYnA9ZD2GHqWj7AZ/bF52Ipr8RmxWVCJpSXmHDmXPMeitMRkKx
         1xTxj9Rb2Z5f+AAvQFrYs0Y8dUT1EqPOwovVP0NBNXCaSc+OygB6HbJNSpxwMog8mxPG
         6FeWjw+zxDd+I3FeB1BT9hAcPMEEv8L7qpbMDZrHfyiFgkyCwYpCjhuzJR8HLQYznf3j
         8xxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757009555; x=1757614355;
        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=z0UUr3AwLcLrhB6YEzODmxI4kys16aqgKfK/o2RcQ2E=;
        b=rFcByBtgyf0upVSAtu82A0cMhKV3zM24Ke3QjVB45UU8qEyH07AP7x9L/956pK6PAG
         9RfCp9hzAp09uoSk+/XZJJbwFilcvPSulcAsPCv/VLucesIKseCJ7ZPwdFsXx87F39hF
         QF1q5xWLRd9t1//NAERYMoX5+KxUAukKJGctuDlDNdft9bfu67fGIvFL3XKHNfEYVeDB
         Si8VjbStXGSsTgoXaoxZ5Q1dvA3vjiVwjlUN31J8dTx5tUil11qZV6VdBw4QgBz8iLhZ
         3UP4O26xYluZqCMkSIv0s1y8MeWAClmwOE01PZJLmMliGiAa/Yw86xWjjPWCFlwtrCNz
         0hfg==
X-Forwarded-Encrypted: i=1; AJvYcCX/SYFHDxaVVEypw5sWZwMkAfvezvoN7VfXymjjzhwgtDQwThd3HtjlDsjbR3xLt63EInenBPznrKI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyjMWI8Bgf+HMhlZVgJcfFh5RGt3YCFlOM7ZDSbJ0Mcukuyiu45
	n1rscWnA4RvCFJKJ+ks/pj//qMGP8sOvezEgDomuXFcPQvoTk1j3HHq0
X-Gm-Gg: ASbGncuykkFpiZL/9wr6+jKIh2+vykJ74byU7WFUZGTOknF5C7ebEpO0rb66d+nHN/q
	Z5g/qHJYIMCpbHn5ios8nvD1L1ND8+o/5tfqSvyGkJsnUBpW7qFW+YGfYzlP3tcIvnlXQN/7pgK
	l5wKw0RQyPrGewP51G41ybmDmuGlbZWrLXU4NdnmtbcnJ0ovWgMnL79DjVAjQesZdN6vhtY1ymX
	Jkpmo6WcpDmF7kDxEj8lcjXd9+jPBRNdee+2E2f+//nd3b94qVtCAApyKAP1lz0TYDruYXt4uEw
	tlfbkyp9+84t1HcJEnU8tqhv84UDLc8oIfFm6E0U3alLt4zAEiXybyiWtBcTvvkIORV5a2JduFr
	JeD8IWCzmJX1S2SU4LcsbV3uwYW95j2f7h+EMDuK8V3nBsJYmQheXnF0=
X-Google-Smtp-Source: AGHT+IETZhSOmf7SXVDSQlSkiMOgX+gGwqA0w4/OY+F//VaBIeokPy+vgk9sIlNcdLA+f7SHoEaHxQ==
X-Received: by 2002:a05:6000:2011:b0:3cd:edee:c7f1 with SMTP id ffacd0b85a97d-3d1e07a4d63mr14486267f8f.56.1757009554689;
        Thu, 04 Sep 2025 11:12:34 -0700 (PDT)
Message-ID: <454e10ed-c873-4782-a669-b1dea4ec405f@gmail.com>
Date: Thu, 4 Sep 2025 21:12:33 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 03.09.25 17:30, Leonid Komarianskyi wrote:

Hello Leonid

> This change introduces resource management in the VGIC to handle
> extended SPIs introduced in GICv3.1. The pending_irqs and
> allocated_irqs arrays are resized to support the required
> number of eSPIs, based on what is supported by the hardware and
> requested by the guest. A new field, ext_shared_irqs, is added
> to the VGIC structure to store information about eSPIs, similar
> to how shared_irqs is used for regular SPIs.
> 
> Since the eSPI range starts at INTID 4096 and INTIDs between 1025
> and 4095 are reserved, helper macros are introduced to simplify the
> transformation of indices and to enable easier access to eSPI-specific
> resources. These changes prepare the VGIC for processing eSPIs as
> required by future functionality.
> 
> The initialization and deinitialization paths for vgic have been updated
> to allocate and free these resources appropriately. Additionally,
> updated handling of INTIDs greater than 1024, passed from the toolstack
> during domain creation, and verification logic ensures only valid SPI or
> eSPI INTIDs are used.
> 
> The existing SPI behavior remains unaffected when guests do not request
> eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
> option is disabled.
> 
> Signed-off-by: Leonid Komarianskyi 
> 
> ---
> Changes for V6:
> - introduced a new function for index to virq conversion, idx_to_virq.
>    This allows the removal of eSPI-specific functions and enables the
>    reuse of existing code for regular SPIs
> - fixed the return value of vgic_allocate_virq in the case of eSPI
> - updated the error message in route_irq_to_guest(). To simplify it and
>    avoid overcomplicating with INTID ranges, propose removing the
>    information about the max number of IRQs
> - fixed eSPI rank initialization to avoid using EXT_RANK_IDX2NUM for
>    converting the eSPI rank to the extended range
> - updated the recalculation logic to avoid the nr_spis > 1020 -
>    NR_LOCAL_IRQS check when nr_spis is reassigned in the case of eSPI
> - fixed formatting issues for macros
> - minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
>    into appropriate inline functions introduced in the previous patch
> - minor change: changed int to unsigned int for nr_espis

Reviewed-by: Oleksandr Tyshchenko 

preferably with NIT below


> 
> Changes in V5:
> - removed the has_espi field because it can be determined by checking
>    whether domain->arch.vgic.nr_espis is zero or not
> - since vgic_ext_rank_offset is not used in this patch, it has been
>    moved to the appropriate patch in the patch series, which implements
>    vgic eSPI registers emulation and requires this function
> - removed ifdefs for eSPI-specific macros to reduce the number of ifdefs
>    and code duplication in further changes
> - fixed minor nit: used %pd for printing domain with its ID
> 
> Changes in V4:
> - added has_espi field to simplify determining whether a domain is able
>    to operate with eSPI
> - fixed formatting issues and misspellings
> 
> Changes in V3:
> - fixed formatting for lines with more than 80 symbols
> - introduced helper functions to be able to use stubs in case of
>    CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of
>    #ifdefs
> - fixed checks for nr_spis in domain_vgic_init
> - updated comment about nr_spis adjustments with dom0less mention
> - moved comment with additional explanations before checks
> - used unsigned int for indexes since they cannot be negative
> - removed unnecessary parentheses
> - move vgic_ext_rank_offset to the below ifdef guard, to reduce the
>    number of ifdefs
> 
> Changes in V2:
> - change is_espi_rank to is_valid_espi_rank to verify whether the array
>    element ext_shared_irqs exists. The previous version, is_espi_rank,
>    only checked if the rank index was less than the maximum possible eSPI
>    rank index, but this could potentially result in accessing a
>    non-existing array element. To address this, is_valid_espi_rank was
>    introduced, which ensures that the required eSPI rank exists
> - move gic_number_espis to
>    xen/arm: gicv3: implement handling of GICv3.1 eSPI
> - update vgic_is_valid_irq checks to allow operating with eSPIs
> - remove redundant newline in vgic_allocate_virq
> ---
>   xen/arch/arm/include/asm/vgic.h |  12 +++
>   xen/arch/arm/irq.c              |   3 +-
>   xen/arch/arm/vgic.c             | 174 ++++++++++++++++++++++++++++++--
>   3 files changed, 176 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h
> index 3e7cbbb196..1cf0a05832 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -146,6 +146,10 @@ struct vgic_dist {
>       int nr_spis; /* Number of SPIs */
>       unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
>       struct vgic_irq_rank *shared_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +    struct vgic_irq_rank *ext_shared_irqs;
> +    unsigned int nr_espis; /* Number of extended SPIs */
> +#endif
>       /*
>        * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
>        * struct arch_vcpu.
> @@ -243,6 +247,14 @@ struct vgic_ops {
>   /* Number of ranks of interrupt registers for a domain */
>   #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
>   
> +#ifdef CONFIG_GICV3_ESPI
> +#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis + 31) / 32)
> +#endif
> +#define EXT_RANK_MIN (ESPI_BASE_INTID / 32)
> +#define EXT_RANK_MAX ((ESPI_MAX_INTID + 31) / 32)
> +#define EXT_RANK_NUM2IDX(num) ((num) - EXT_RANK_MIN)
> +#define EXT_RANK_IDX2NUM(idx) ((idx) + EXT_RANK_MIN)
> +
>   #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
>   #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
>   
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index c934d39bf6..c2f1ceb91f 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -494,8 +494,7 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
>       if ( !vgic_is_valid_line(d, virq) )
>       {
>           printk(XENLOG_G_ERR
> -               "the vIRQ number %u is too high for domain %u (max = %u)\n",
> -               irq, d->domain_id, vgic_num_irqs(d));
> +               "invalid vIRQ number %u for domain %pd\n", irq, d);
>           return -EINVAL;
>       }
>   
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 2bbf4d99aa..b42aee8d0c 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -25,11 +25,61 @@
>   #include 
>   
>   
> +static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx)
> +{
> +    if ( idx >= vgic_num_irqs(d) )
> +        return espi_idx_to_intid(idx - vgic_num_irqs(d));
> +
> +    return idx;
> +}
> +
>   bool vgic_is_valid_line(struct domain *d, unsigned int virq)
>   {
> +#ifdef CONFIG_GICV3_ESPI
> +    if ( virq >= ESPI_BASE_INTID &&
> +         virq < espi_idx_to_intid(d->arch.vgic.nr_espis) )
> +        return true;
> +#endif
> +
>       return virq < vgic_num_irqs(d);
>   }
>   
> +#ifdef CONFIG_GICV3_ESPI
> +/*
> + * Since eSPI indexes start from 4096 and numbers from 1024 to
> + * 4095 are forbidden, we need to check both lower and upper
> + * limits for ranks.
> + */
> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
> +{
> +    return rank >= EXT_RANK_MIN &&
> +           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d);
> +}
> +
> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
> +                                                       unsigned int rank)
> +{
> +    return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)];
> +}
> +
> +#else
> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
> +{
> +    return false;
> +}
> +
> +/*
> + * This function is stub and will not be called if CONFIG_GICV3_ESPI=n,
> + * because in this case, is_valid_espi_rank will always return false.
> + */
> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
> +                                                       unsigned int rank)
> +{
> +    ASSERT_UNREACHABLE();
> +    return NULL;
> +}
> +#endif
> +
>   static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
>                                                     unsigned int rank)
>   {
> @@ -37,6 +87,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
>           return v->arch.vgic.private_irqs;
>       else if ( rank <= DOMAIN_NR_RANKS(v->domain) )
>           return &v->domain->arch.vgic.shared_irqs[rank - 1];
> +    else if ( is_valid_espi_rank(v->domain, rank) )
> +        return vgic_get_espi_rank(v, rank);
>       else
>           return NULL;
>   }
> @@ -117,6 +169,54 @@ int domain_vgic_register(struct domain *d, unsigned int *mmio_count)
>       return 0;
>   }
>   
> +#ifdef CONFIG_GICV3_ESPI
> +static unsigned int vgic_num_spi_lines(struct domain *d)
> +{
> +    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
> +}
> +
> +static int init_vgic_espi(struct domain *d)
> +{
> +    unsigned int i, idx;
> +
> +    if ( d->arch.vgic.nr_espis == 0 )
> +        return 0;
> +
> +    d->arch.vgic.ext_shared_irqs =
> +        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d));
> +    if ( d->arch.vgic.ext_shared_irqs == NULL )
> +        return -ENOMEM;
> +
> +    for ( i = d->arch.vgic.nr_spis, idx = 0;
> +          i < vgic_num_spi_lines(d); i++, idx++ )
> +        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i],
> +                              espi_idx_to_intid(idx));
> +
> +    for ( i = 0; i < DOMAIN_NR_EXT_RANKS(d); i++ )
> +        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i],
> +                       EXT_RANK_IDX2NUM(i), 0);
> +
> +    return 0;
> +}
> +
> +#else
> +static int init_vgic_espi(struct domain *d)
> +{
> +    return 0;
> +}
> +
> +static unsigned int vgic_num_spi_lines(struct domain *d)
> +{
> +    return d->arch.vgic.nr_spis;
> +}
> +
> +#endif
> +
> +static unsigned int vgic_num_alloc_irqs(struct domain *d)
> +{
> +    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS;
> +}
> +
>   int domain_vgic_init(struct domain *d, unsigned int nr_spis)
>   {
>       int i;
> @@ -133,7 +233,39 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis)
>   
>       /* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
>       if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
> +#ifndef CONFIG_GICV3_ESPI
>           return -EINVAL;
> +#else
> +    {
> +        /*
> +         * During domain creation, the dom0less DomUs code or toolstack
> +         * specifies the maximum INTID, which is defined in the domain
> +         * config subtracted by 32 to cover the local IRQs (please see
> +         * the comment to VGIC_DEF_NR_SPIS). To compute the actual number
> +         * of eSPI that will be usable for, add back 32.
> +         */
> +        nr_spis += 32;
> +        if ( nr_spis > espi_idx_to_intid(NR_ESPI_IRQS) )
> +            return -EINVAL;
> +
> +        if ( nr_spis >= ESPI_BASE_INTID )
> +        {
> +            unsigned int nr_espis = min(nr_spis - ESPI_BASE_INTID, 1024U);
> +
> +            /* Verify if GIC HW can handle provided INTID */
> +            if ( nr_espis > gic_number_espis() )
> +                return -EINVAL;
> +
> +            d->arch.vgic.nr_espis = nr_espis;
> +            /* Set the maximum available number for regular SPIs */
> +            nr_spis = VGIC_DEF_NR_SPIS;
> +        }
> +        else
> +        {
> +            return -EINVAL;
> +        }
> +    }
> +#endif
>   
>       d->arch.vgic.nr_spis = nr_spis;
>   
> @@ -145,7 +277,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis)
>           return -ENOMEM;
>   
>       d->arch.vgic.pending_irqs =
> -        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
> +        xzalloc_array(struct pending_irq, vgic_num_spi_lines(d));


So, you do not keep two separate pending_irqs arrays, just like 
the shared_irqs and ext_shared_irqs arrays. You allocate
pending_irqs array as a single flat array to hold both regular SPIs and 
eSPIs with looks like the following mapping ---> regular SPIs 
[0..nr_spis-1] and eSPIs [nr_spis..nr_spis+nr_espis-1].

NIT: I would add a comment above the pending_irqs field in struct 
vgic_dist saying that an array is also supposed to hold extended SPIs if 
present, or something like that.
Otherwise, by just looking into struct vgic_dist in the header, it is 
not clear where other (than ext_shared_irqs, nr_espis) eSPI bits are.


>       if ( d->arch.vgic.pending_irqs == NULL )
>           return -ENOMEM;
>   
> @@ -156,12 +288,16 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis)
>       for ( i = 0; i < DOMAIN_NR_RANKS(d); i++ )
>           vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0);
>   
> +    ret = init_vgic_espi(d);
> +    if ( ret )
> +        return ret;
> +
>       ret = d->arch.vgic.handler->domain_init(d);
>       if ( ret )
>           return ret;
>   
>       d->arch.vgic.allocated_irqs =
> -        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
> +        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d)));

NIT: The same goes for the allocated_irqs field.

>       if ( !d->arch.vgic.allocated_irqs )
>           return -ENOMEM;
>   


[snip]


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 18:23:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 18:23:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110625.1459721 (Exim 4.92)
	(envelope-from )
	id 1uuEcU-0001Eh-8H; Thu, 04 Sep 2025 18:23:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110625.1459721; Thu, 04 Sep 2025 18:23: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 1uuEcU-0001Ea-4q; Thu, 04 Sep 2025 18:23:38 +0000
Received: by outflank-mailman (input) for mailman id 1110625;
 Thu, 04 Sep 2025 18:23:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuEcS-0001EU-AK
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 18:23:36 +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 43f6233e-89bc-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 20:23:33 +0200 (CEST)
Received: from AS4PR03MB8676.eurprd03.prod.outlook.com (2603:10a6:20b:58c::8)
 by AS8PR03MB9141.eurprd03.prod.outlook.com (2603:10a6:20b:5b4::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 18:23:31 +0000
Received: from AS4PR03MB8676.eurprd03.prod.outlook.com
 ([fe80::c5ca:906a:1ded:634b]) by AS4PR03MB8676.eurprd03.prod.outlook.com
 ([fe80::c5ca:906a:1ded:634b%5]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 18:23: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: 43f6233e-89bc-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ixtLDKEzRm0HaSvZ1hvNRvdbVzofH/T7bJX3r3YkG1TLA68eo9jmEr0FsHgBUQyAYYDV/l9ptgtNUTgr1d7YfSg1jJO0gC0rmTlLNiH8BcuM9t+9ixwi6E+oKDcjHJHsJoBjkdQ1plIQS/lBuaZKVyzt4H0ol8P8tGmBXoZHZK1ZsMsrWRZZiHb2+cGRE9ICQdj4P0OJpO39auNqAjfugR64aEQetHmAiQ/U/wuyoPnY+ZSg6Zj77+89wC0Tao/NO6rQNi9yVbYuN2kPgAz606rZSGcWX1xSqG7bjvzP0usX+N39EhVkYVbDT5JoHT5Ja3IENUhFMciwhfQOiA8uPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xrphQgpfKUwOiTmFT7ujOUacG2qmagn+QEtzLZf0kfA=;
 b=TZptNRWZmOnMLHFgxW7Y7es700FXuqWlDckydFGGrRyqywli1i+9ZV5y26VTxEa+49A45NVJNUB/a5cAzDlR9zTqh/Deiio/Sa+iHPxoAyrgN2YbdjsEFQyXMqfK6ziLM7oX/rSdAc+/sWctT9KyGM4I2LxcBKyEsjMZnwVjb+ANtufNCmXYRvnQZuA/myLzf2+xpV73XUcchfPXHrUQPqTpkgkzyx9RQZHq1vH1hJR3iZOm/8yjB4daF7SzzeB21INQ71qCbo5u2yCOT6nWD6B6TBFgmmEsEyeZ/4Z+fb+vcjrHQ0M1Ww5e0AMhqaPNiaQpz/BAO861cZfKuWPhxg==
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=xrphQgpfKUwOiTmFT7ujOUacG2qmagn+QEtzLZf0kfA=;
 b=OCipmRyoMvh/oN9L9NsOe6V+53RSZS0BI58fab3qgxqgCq1R/9ti/A0lGDCMaeDqZsyAv/JFzhQQLvMtrHTmQGaNHA3zBS2b2bqmDMa8nBRVfqI4HyBDSCGfWrmHZizT1g//KZ1ah9d/7IjPppxYlF9ruLD+vhcm2cmlJfOWUzBK+f3WAHIFu/1F6ALwZNolNigs9nr9vQThwYuUQyE+r1SwX7ftaHjVeUkHJu1j9lLXymw8XSxF1gVNe9OMsDWn1ghIb6Ou4k8fhujZcxxMQuRryRH5TtVXH4B61XtvhA0cFRxyZU6hvPZ33Vh7GYEKHZtdNMttkhbVuHSHLxruwQ==
From: Leonid Komarianskyi 
To: Oleksandr Tyshchenko ,
	"xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
Subject: Re: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Topic: [PATCH v6 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcHN9AEk+ywvTyYUiwpifc3pdNG7SDVTmAgAADDwA=
Date: Thu, 4 Sep 2025 18:23:30 +0000
Message-ID: <7888d846-053b-4938-bd78-90528bfee1cb@epam.com>
References: 
 
 <454e10ed-c873-4782-a669-b1dea4ec405f@gmail.com>
In-Reply-To: <454e10ed-c873-4782-a669-b1dea4ec405f@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: AS4PR03MB8676:EE_|AS8PR03MB9141:EE_
x-ms-office365-filtering-correlation-id: 2acf9f71-bf14-4b02-544b-08ddebe02696
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?T3dreWUxOFVGRXBMOXg0eFM3dmlZcEs5UTdXM1VQQlROSUJOaHlvQlcrL2dH?=
 =?utf-8?B?clUrZUp4UG93ZEhWTE9oaS9xcit6OXgybmR4eUZZNCtNY2ZVd2RUOWZocU9P?=
 =?utf-8?B?cWFnajJUV2NqTWo0TkFhcll5NGMvZmhaT2VpVGlkNzhjekpoK2daU3YxT1B0?=
 =?utf-8?B?MmFsUkVGeS8zUEJ5dVh0eXZPNjl0RXJpZjdyNU9icWt1N2VJSVZZZ0wyemp1?=
 =?utf-8?B?cG1tZVZ4eldJSHQwTW1OSGlnK2xpVnZPS0Ezd0NnVWgrbDRIVmEwY0pCRFNi?=
 =?utf-8?B?SUpFY2Z5SmY5RXAvb3hydTdDSzFzMUJIWHBjK0FaNHRzcFZqZXM5VGprYWQ4?=
 =?utf-8?B?c1lnRjZRZG9JUFlvMklOVEkrYXdJbnNNQjlueE0vbEFMYjVkU3BwQlV2bWxk?=
 =?utf-8?B?aGgvcHpHTDdkZkxZaE1OdkVzZ2JMNnNrVW1ueDl1VzhDYjVrcWxzMHI0VUx1?=
 =?utf-8?B?WGxacmxRWU83bUpNWldVTHcvbDdabTBFQnd6NGZxY0dyWjVPV0E0NHJveXIx?=
 =?utf-8?B?TklCdCtqYlRLdWxJZWg0azZwRXZkdldhbW80SHdFQmxtVHRWWitPNHZxWG85?=
 =?utf-8?B?cjJWcXFnVG1IMXJBeUtLRjFPNEZqUENqZ1JzaVEzOG1YSDZJaUY3NndJeVpQ?=
 =?utf-8?B?K2RBS3p2aTc3akNwbXFWNUxVclI2SGhFYkhVVnRrc3EzRFBkY1ZNMUo3ZjRT?=
 =?utf-8?B?RExoRWd5MWZ6SC9maC8vOEFOOEU5SlZJM1FBR3NObXNLS0RGOW50K3V2Z1JF?=
 =?utf-8?B?SnRRb2tWWVQxc3JOaW0vN1kvcEdneEp3UmIzTERNcXp5TE1hRlo5Q3RreVg3?=
 =?utf-8?B?cW9lSjVaenozY0JPQVNYSWJNVnZ0Mmd1b0pWNkpXWXhxSkgyVGh2YUxpaTMy?=
 =?utf-8?B?d1FDTnBBYjBoMnpiM3c1bnBuVG9SakRqTzN3MUo2RXRZQXlXS2V2Nk5jR2RC?=
 =?utf-8?B?c21hTjdJMUpiMitUVG9Cc3gyY3JPU0ZWSSt0R3ZsT3A5bDlBNFIzRzR5dllW?=
 =?utf-8?B?VnFXSkRTazNWR3dzUWl5NjJsR3BKTEtFRC81ZlQ2YnBvb3RSRGRoOU5OMHRK?=
 =?utf-8?B?cnU0MWNjak5BZy9XV3AralNRR2krdmxhaUZWOVQzb05kZE5rRm0rVS8yZUhS?=
 =?utf-8?B?ZDR4TVUxNlVJZGJtVHNqdGhMVDlrWnFCbGpqUGtsNERNcitPRFlqa1diMGM2?=
 =?utf-8?B?NVdIQkRTR2ZtQWhPSDk4MGtENktNMGE2ZVZoSS9BNDR2L2p3OU1IbHFKVzMz?=
 =?utf-8?B?bFBXMlR4TTlKbnQ2cWsyQ2Ztd2RLZU91SHh3eFRmYXBwOTY4R2tDekdoWCtI?=
 =?utf-8?B?NDRXSisrR3VKa0hyU01pOTZGRmVBY3BqSk0wTzEvMW13bVBLaWc0QmdUd2to?=
 =?utf-8?B?VHo1SDRWQk9HYkRJWllZWHNNRnphTU9FcElYRG5hWTl6c2pwUkJ5alFscVA2?=
 =?utf-8?B?Z0NSTnE5ZGVCK1hZbE1vQllZcVBUQWdGRW5KTGlhM09xWFJUMjFBR3pyTHU0?=
 =?utf-8?B?eWl3THpuaG5Eci9jWTYzenltYlBTOFc4cjgrRmwvd1hpcUNzd2pvR21JNmpF?=
 =?utf-8?B?RUQxcDBESUZRWDQ0aEI1TEROMHRTbW5hKzUzdVlIdGFYb0NhYm05ZjA2MExn?=
 =?utf-8?B?ZTZra1hOUXZIQVhDSkg1cC9SMmJKcnZXZVE1MWJ2ZnpvT2lRT3BUMCtrQXRm?=
 =?utf-8?B?SXFzSUU3M2lKbm9WaWVTcW5mQVVNUFRCcmVOZzQ1bUk0TG90eE9BTW96dm1z?=
 =?utf-8?B?N0ZWVXY1VUk1SXdEMG1PSmkrK0pFSjliUUgzMlZwbXJtVlVCTnpmNEt3cDlQ?=
 =?utf-8?B?bjFRMFNtTkp5ZWkyYXZrc01OQUxyTzZrVE1Ucng3ODBGRDBTUGllR3RmOHd0?=
 =?utf-8?B?UngwOUdSbFhSbXZianQxOWNsN2M5MUVKWFNaVFUwVWN0bHQyWEtpQWU1cEdo?=
 =?utf-8?B?UWtSeHlPYkxMSnlFd1FVK0QxSy80US93NFVhSE43eFQ4c2tvZk5UeEFYNUhP?=
 =?utf-8?B?Tk1yQTloWkdnPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS4PR03MB8676.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WExjc3VuaUNSNllnblFPMUNnRVR4V0c0UWMrY1FKYnhjSkRZOVBWZERmbXRp?=
 =?utf-8?B?OUJsdG5LZzFTVmd5WElVOVZ2TnR0V2VOMXNSRTZQeFE5WmJCaS9GZStDU0hr?=
 =?utf-8?B?YjdRYXlIYmNSSGorWDlWTWpPTFdBTWU1dmlGNFovenFkY1pWU3dDTG9LVkta?=
 =?utf-8?B?QXIrOWpqbjRhTmhjTXNYQXdaWWpqSFQ4MUZqQTdiMlQxbjB3TGJTK1d5RkJU?=
 =?utf-8?B?MVhFUUNWQUlIQ0FFamNHcjhoQ0FWeElCUUFQZ01DZUF4V1pQQWhhVEM2ak04?=
 =?utf-8?B?NXFUN1VBY3JDOEtoTFlScGZSazM0Mi9VMzhjT0xpQ3Ira3FhczVPSGNtRS9J?=
 =?utf-8?B?K1ZCaFFEeXhiU3Y1dXZZc2ZzV2s5S2JNNk51UmFIWC9JK3draFEyR0RvV0Fh?=
 =?utf-8?B?dHU5K2FDWHppREw2OVc1UmYramRRd0dVSzZXUG45MzNvVFJJZlRVY243Ykdn?=
 =?utf-8?B?eDJ1OGFycjFoTmU3bEhzUXBVaWVpbTEycTAvSTlPb3ZxUDNrbzV2NkhJYlZ0?=
 =?utf-8?B?anpwRzFrS1pvekNIYVFINGhoblpqbFArbnR6T0ZlWGNuODlzbThrSXJLSlQ0?=
 =?utf-8?B?cFhpMnc4RFoybEJ3S1hpOG5oVkVlV21vMlhmUzdyK2hjTXByMFVEdVpnNWFS?=
 =?utf-8?B?a1NFZ0hGcEdCZFV0REVoVnI1MEZ2czM1eEJFY0Yzd2I4WWczQkJCOXp1RTVH?=
 =?utf-8?B?RU1qdnRla2FWZllwd0YveTU2aGxwSUVONFphYU5BU1pZdTRNbUF4S1kwZThx?=
 =?utf-8?B?YkpvenNCaHJjNVBacDkzL2Q4a1VXYVZRamoyaDVHZXdJVlBHWVpMZXkvMXc3?=
 =?utf-8?B?VzhCbUFRT0JDQmowbkk3OFo2SkE0anVoSVpwUm50NFJNUDJZY0Q0amo0dGU3?=
 =?utf-8?B?V2pHdDlVOWJOM2o0eUMzeDJRckNRaHFiRkFyN0N2Q0lZRUIrOXhMK3VtalIr?=
 =?utf-8?B?TXdZaDVBNUhqNllxYjRRL0N0V1JRV3E2UnJYYkd4M2F2VmxHU2ZIc0s5Q1ZO?=
 =?utf-8?B?eXdtVWs1YVVTdjlUb0xrcjVORkdHaHlidHNMSlRYL1dNNEZuTjRER2w4bHdT?=
 =?utf-8?B?bnBCaEFtRjM3bGc3eVJrMXhEVG1Mb0dGbm1DNzF1V2pnaGlhNFhrVVJzblJv?=
 =?utf-8?B?K2pMUXBTblc2amQ3V0ptWEFQUHFJZU9hUTE5UU56VVAyOTF1Z0l6QkdPYXoz?=
 =?utf-8?B?KzBxVTBML01OOFVxNnhTWElkNUl3Lzg3d0RIdGgvZTZwR3k3Y3RUOFNFN0dC?=
 =?utf-8?B?YjlEYVU3VHpvT1hFRU1HZDhUS1o5VVpaTkowL1phSi9EdHdpRzJRdHQ4RGZD?=
 =?utf-8?B?QkxPclhwd1hTVTcxeFdhU2YwSXJaL2ZIRHgvTkZXNjB0RmJ6b3h5cnJOOG9M?=
 =?utf-8?B?aEtUM0crUHMwU09DZnFlOW5TeVFMdUE0Y0dnNDNyMk1US3hOU0xobW5QVTR2?=
 =?utf-8?B?RGd2ZlJKNkExbzVtMFI3b21vc2lVbTRJaDBMQTUwUC9TVjIrZnlQRHRSM29Z?=
 =?utf-8?B?UmdLQTl3Zmt1MFVoV2dyeEV5bjZYcE5kbmFTK1V6czMwQUphQ2h0TUNtam9Z?=
 =?utf-8?B?TWpBYy9JbGUzMlNrbkdkRzNndFZmTjZjTlpxM1NZL05DZHpwaWYxVnZmL25T?=
 =?utf-8?B?YW9EcUlUckhoZm5QZWo2WHNIU0ROdExqTHZwZm1xSGlrMVNaQ2N6ekVWTVFC?=
 =?utf-8?B?YUhMSmsvNEpadTIvTE0wa3h2SDczYUhzWjFXOTVyV0J2enJuMStvVnFGbTJF?=
 =?utf-8?B?eFRlUFhDa0pMZDh4bGg2MTJSd25nU2ZNbGJuVUtlR3R0OHpLelZsVTRKU1Fu?=
 =?utf-8?B?OVJGN2tIMFhDY1RLb0VXNlRZcW5VRUE5dTkvc01jWWZuL2VaYXVxc3BSWEJD?=
 =?utf-8?B?YnJ2RnlELzZ3TnlvV053WkxnREVKQ0ZiZjBvNDlhYk94OExBNGV4TUMrUjdr?=
 =?utf-8?B?SC9yQmRiQ3U1SWNRbjAyaHhsYUIybDZhanVJeXJHUzh6TXRrNFZqZ3hVK2pT?=
 =?utf-8?B?K0JSMzhvQklvVytPR3c1MkdVYklXTE1TODBIKzVRT2I1VklQR05Zc3g0aStw?=
 =?utf-8?B?aEZYSmJiLzNTRi81elVaR0FJMjNCRVFPYURMWm9JWTNZSG9ybTlkYms1SG1H?=
 =?utf-8?B?bTYzWm1mclMrSisybEVDSWtqSldoaVYyS2RWOFlETklodHJ6L3RZbG5xeCs4?=
 =?utf-8?Q?XEPbFn+WcaGqutHdAnhI4aM=3D?=
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: AS4PR03MB8676.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2acf9f71-bf14-4b02-544b-08ddebe02696
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 18:23:30.8841
 (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: mAkv8QtJHyF5wF5PMpXpp7e+o41ZTqDgPE8Wp+rQr7xn6x6XZGMuBlXXJg3dLDqlnRF09G3ZCP7uEVFFIp7PwBK+PaJsF7pHlb2TC6nwwRc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9141

SGVsbG8gT2xla3NhbmRyLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzIGFu
ZCBSQi4NCg0KT24gMDQuMDkuMjUgMjE6MTIsIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdyb3RlOg0K
PiANCj4gDQo+IE9uIDAzLjA5LjI1IDE3OjMwLCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0K
PiANCj4gSGVsbG8gTGVvbmlkDQo+IA0KPj4gVGhpcyBjaGFuZ2UgaW50cm9kdWNlcyByZXNvdXJj
ZSBtYW5hZ2VtZW50IGluIHRoZSBWR0lDIHRvIGhhbmRsZQ0KPj4gZXh0ZW5kZWQgU1BJcyBpbnRy
b2R1Y2VkIGluIEdJQ3YzLjEuIFRoZSBwZW5kaW5nX2lycXMgYW5kDQo+PiBhbGxvY2F0ZWRfaXJx
cyBhcnJheXMgYXJlIHJlc2l6ZWQgdG8gc3VwcG9ydCB0aGUgcmVxdWlyZWQNCj4+IG51bWJlciBv
ZiBlU1BJcywgYmFzZWQgb24gd2hhdCBpcyBzdXBwb3J0ZWQgYnkgdGhlIGhhcmR3YXJlIGFuZA0K
Pj4gcmVxdWVzdGVkIGJ5IHRoZSBndWVzdC4gQSBuZXcgZmllbGQsIGV4dF9zaGFyZWRfaXJxcywg
aXMgYWRkZWQNCj4+IHRvIHRoZSBWR0lDIHN0cnVjdHVyZSB0byBzdG9yZSBpbmZvcm1hdGlvbiBh
Ym91dCBlU1BJcywgc2ltaWxhcg0KPj4gdG8gaG93IHNoYXJlZF9pcnFzIGlzIHVzZWQgZm9yIHJl
Z3VsYXIgU1BJcy4NCj4+DQo+PiBTaW5jZSB0aGUgZVNQSSByYW5nZSBzdGFydHMgYXQgSU5USUQg
NDA5NiBhbmQgSU5USURzIGJldHdlZW4gMTAyNQ0KPj4gYW5kIDQwOTUgYXJlIHJlc2VydmVkLCBo
ZWxwZXIgbWFjcm9zIGFyZSBpbnRyb2R1Y2VkIHRvIHNpbXBsaWZ5IHRoZQ0KPj4gdHJhbnNmb3Jt
YXRpb24gb2YgaW5kaWNlcyBhbmQgdG8gZW5hYmxlIGVhc2llciBhY2Nlc3MgdG8gZVNQSS1zcGVj
aWZpYw0KPj4gcmVzb3VyY2VzLiBUaGVzZSBjaGFuZ2VzIHByZXBhcmUgdGhlIFZHSUMgZm9yIHBy
b2Nlc3NpbmcgZVNQSXMgYXMNCj4+IHJlcXVpcmVkIGJ5IGZ1dHVyZSBmdW5jdGlvbmFsaXR5Lg0K
Pj4NCj4+IFRoZSBpbml0aWFsaXphdGlvbiBhbmQgZGVpbml0aWFsaXphdGlvbiBwYXRocyBmb3Ig
dmdpYyBoYXZlIGJlZW4gdXBkYXRlZA0KPj4gdG8gYWxsb2NhdGUgYW5kIGZyZWUgdGhlc2UgcmVz
b3VyY2VzIGFwcHJvcHJpYXRlbHkuIEFkZGl0aW9uYWxseSwNCj4+IHVwZGF0ZWQgaGFuZGxpbmcg
b2YgSU5USURzIGdyZWF0ZXIgdGhhbiAxMDI0LCBwYXNzZWQgZnJvbSB0aGUgdG9vbHN0YWNrDQo+
PiBkdXJpbmcgZG9tYWluIGNyZWF0aW9uLCBhbmQgdmVyaWZpY2F0aW9uIGxvZ2ljIGVuc3VyZXMg
b25seSB2YWxpZCBTUEkgb3INCj4+IGVTUEkgSU5USURzIGFyZSB1c2VkLg0KPj4NCj4+IFRoZSBl
eGlzdGluZyBTUEkgYmVoYXZpb3IgcmVtYWlucyB1bmFmZmVjdGVkIHdoZW4gZ3Vlc3RzIGRvIG5v
dCByZXF1ZXN0DQo+PiBlU1BJcywgR0lDIGhhcmR3YXJlIGRvZXMgbm90IHN1cHBvcnQgdGhlbSwg
b3IgdGhlIENPTkZJR19HSUNWM19FU1BJDQo+PiBvcHRpb24gaXMgZGlzYWJsZWQuDQo+Pg0KPj4g
U2lnbmVkLW9mZi1ieTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBl
cGFtLmNvbT4NCj4+DQo+PiAtLS0NCj4+IENoYW5nZXMgZm9yIFY2Og0KPj4gLSBpbnRyb2R1Y2Vk
IGEgbmV3IGZ1bmN0aW9uIGZvciBpbmRleCB0byB2aXJxIGNvbnZlcnNpb24sIGlkeF90b192aXJx
Lg0KPj4gwqDCoCBUaGlzIGFsbG93cyB0aGUgcmVtb3ZhbCBvZiBlU1BJLXNwZWNpZmljIGZ1bmN0
aW9ucyBhbmQgZW5hYmxlcyB0aGUNCj4+IMKgwqAgcmV1c2Ugb2YgZXhpc3RpbmcgY29kZSBmb3Ig
cmVndWxhciBTUElzDQo+PiAtIGZpeGVkIHRoZSByZXR1cm4gdmFsdWUgb2YgdmdpY19hbGxvY2F0
ZV92aXJxIGluIHRoZSBjYXNlIG9mIGVTUEkNCj4+IC0gdXBkYXRlZCB0aGUgZXJyb3IgbWVzc2Fn
ZSBpbiByb3V0ZV9pcnFfdG9fZ3Vlc3QoKS4gVG8gc2ltcGxpZnkgaXQgYW5kDQo+PiDCoMKgIGF2
b2lkIG92ZXJjb21wbGljYXRpbmcgd2l0aCBJTlRJRCByYW5nZXMsIHByb3Bvc2UgcmVtb3Zpbmcg
dGhlDQo+PiDCoMKgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBtYXggbnVtYmVyIG9mIElSUXMNCj4+
IC0gZml4ZWQgZVNQSSByYW5rIGluaXRpYWxpemF0aW9uIHRvIGF2b2lkIHVzaW5nIEVYVF9SQU5L
X0lEWDJOVU0gZm9yDQo+PiDCoMKgIGNvbnZlcnRpbmcgdGhlIGVTUEkgcmFuayB0byB0aGUgZXh0
ZW5kZWQgcmFuZ2UNCj4+IC0gdXBkYXRlZCB0aGUgcmVjYWxjdWxhdGlvbiBsb2dpYyB0byBhdm9p
ZCB0aGUgbnJfc3BpcyA+IDEwMjAgLQ0KPj4gwqDCoCBOUl9MT0NBTF9JUlFTIGNoZWNrIHdoZW4g
bnJfc3BpcyBpcyByZWFzc2lnbmVkIGluIHRoZSBjYXNlIG9mIGVTUEkNCj4+IC0gZml4ZWQgZm9y
bWF0dGluZyBpc3N1ZXMgZm9yIG1hY3Jvcw0KPj4gLSBtaW5vciBjaGFuZ2U6IGNoYW5nZWQgdGhl
IG1hY3JvcyBFU1BJX0lOVElEMklEWCBhbmQgRVNQSV9JRFgySU5USUQNCj4+IMKgwqAgaW50byBh
cHByb3ByaWF0ZSBpbmxpbmUgZnVuY3Rpb25zIGludHJvZHVjZWQgaW4gdGhlIHByZXZpb3VzIHBh
dGNoDQo+PiAtIG1pbm9yIGNoYW5nZTogY2hhbmdlZCBpbnQgdG8gdW5zaWduZWQgaW50IGZvciBu
cl9lc3Bpcw0KPiANCj4gUmV2aWV3ZWQtYnk6IE9sZWtzYW5kciBUeXNoY2hlbmtvIDxvbGVrc2Fu
ZHJfdHlzaGNoZW5rb0BlcGFtLmNvbT4NCj4gDQo+IHByZWZlcmFibHkgd2l0aCBOSVQgYmVsb3cN
Cj4gDQo+IA0KPj4NCj4+IENoYW5nZXMgaW4gVjU6DQo+PiAtIHJlbW92ZWQgdGhlIGhhc19lc3Bp
IGZpZWxkIGJlY2F1c2UgaXQgY2FuIGJlIGRldGVybWluZWQgYnkgY2hlY2tpbmcNCj4+IMKgwqAg
d2hldGhlciBkb21haW4tPmFyY2gudmdpYy5ucl9lc3BpcyBpcyB6ZXJvIG9yIG5vdA0KPj4gLSBz
aW5jZSB2Z2ljX2V4dF9yYW5rX29mZnNldCBpcyBub3QgdXNlZCBpbiB0aGlzIHBhdGNoLCBpdCBo
YXMgYmVlbg0KPj4gwqDCoCBtb3ZlZCB0byB0aGUgYXBwcm9wcmlhdGUgcGF0Y2ggaW4gdGhlIHBh
dGNoIHNlcmllcywgd2hpY2ggaW1wbGVtZW50cw0KPj4gwqDCoCB2Z2ljIGVTUEkgcmVnaXN0ZXJz
IGVtdWxhdGlvbiBhbmQgcmVxdWlyZXMgdGhpcyBmdW5jdGlvbg0KPj4gLSByZW1vdmVkIGlmZGVm
cyBmb3IgZVNQSS1zcGVjaWZpYyBtYWNyb3MgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgaWZkZWZz
DQo+PiDCoMKgIGFuZCBjb2RlIGR1cGxpY2F0aW9uIGluIGZ1cnRoZXIgY2hhbmdlcw0KPj4gLSBm
aXhlZCBtaW5vciBuaXQ6IHVzZWQgJXBkIGZvciBwcmludGluZyBkb21haW4gd2l0aCBpdHMgSUQN
Cj4+DQo+PiBDaGFuZ2VzIGluIFY0Og0KPj4gLSBhZGRlZCBoYXNfZXNwaSBmaWVsZCB0byBzaW1w
bGlmeSBkZXRlcm1pbmluZyB3aGV0aGVyIGEgZG9tYWluIGlzIGFibGUNCj4+IMKgwqAgdG8gb3Bl
cmF0ZSB3aXRoIGVTUEkNCj4+IC0gZml4ZWQgZm9ybWF0dGluZyBpc3N1ZXMgYW5kIG1pc3NwZWxs
aW5ncw0KPj4NCj4+IENoYW5nZXMgaW4gVjM6DQo+PiAtIGZpeGVkIGZvcm1hdHRpbmcgZm9yIGxp
bmVzIHdpdGggbW9yZSB0aGFuIDgwIHN5bWJvbHMNCj4+IC0gaW50cm9kdWNlZCBoZWxwZXIgZnVu
Y3Rpb25zIHRvIGJlIGFibGUgdG8gdXNlIHN0dWJzIGluIGNhc2Ugb2YNCj4+IMKgwqAgQ09ORklH
X0dJQ1YzX0VTUEkgZGlzYWJsZWQsIGFuZCBhcyBhIHJlc3VsdCwgcmVkdWNlIHRoZSBudW1iZXIg
b2YNCj4+IMKgwqAgI2lmZGVmcw0KPj4gLSBmaXhlZCBjaGVja3MgZm9yIG5yX3NwaXMgaW4gZG9t
YWluX3ZnaWNfaW5pdA0KPj4gLSB1cGRhdGVkIGNvbW1lbnQgYWJvdXQgbnJfc3BpcyBhZGp1c3Rt
ZW50cyB3aXRoIGRvbTBsZXNzIG1lbnRpb24NCj4+IC0gbW92ZWQgY29tbWVudCB3aXRoIGFkZGl0
aW9uYWwgZXhwbGFuYXRpb25zIGJlZm9yZSBjaGVja3MNCj4+IC0gdXNlZCB1bnNpZ25lZCBpbnQg
Zm9yIGluZGV4ZXMgc2luY2UgdGhleSBjYW5ub3QgYmUgbmVnYXRpdmUNCj4+IC0gcmVtb3ZlZCB1
bm5lY2Vzc2FyeSBwYXJlbnRoZXNlcw0KPj4gLSBtb3ZlIHZnaWNfZXh0X3Jhbmtfb2Zmc2V0IHRv
IHRoZSBiZWxvdyBpZmRlZiBndWFyZCwgdG8gcmVkdWNlIHRoZQ0KPj4gwqDCoCBudW1iZXIgb2Yg
aWZkZWZzDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMjoNCj4+IC0gY2hhbmdlIGlzX2VzcGlfcmFuayB0
byBpc192YWxpZF9lc3BpX3JhbmsgdG8gdmVyaWZ5IHdoZXRoZXIgdGhlIGFycmF5DQo+PiDCoMKg
IGVsZW1lbnQgZXh0X3NoYXJlZF9pcnFzIGV4aXN0cy4gVGhlIHByZXZpb3VzIHZlcnNpb24sIGlz
X2VzcGlfcmFuaywNCj4+IMKgwqAgb25seSBjaGVja2VkIGlmIHRoZSByYW5rIGluZGV4IHdhcyBs
ZXNzIHRoYW4gdGhlIG1heGltdW0gcG9zc2libGUgZVNQSQ0KPj4gwqDCoCByYW5rIGluZGV4LCBi
dXQgdGhpcyBjb3VsZCBwb3RlbnRpYWxseSByZXN1bHQgaW4gYWNjZXNzaW5nIGENCj4+IMKgwqAg
bm9uLWV4aXN0aW5nIGFycmF5IGVsZW1lbnQuIFRvIGFkZHJlc3MgdGhpcywgaXNfdmFsaWRfZXNw
aV9yYW5rIHdhcw0KPj4gwqDCoCBpbnRyb2R1Y2VkLCB3aGljaCBlbnN1cmVzIHRoYXQgdGhlIHJl
cXVpcmVkIGVTUEkgcmFuayBleGlzdHMNCj4+IC0gbW92ZSBnaWNfbnVtYmVyX2VzcGlzIHRvDQo+
PiDCoMKgIHhlbi9hcm06IGdpY3YzOiBpbXBsZW1lbnQgaGFuZGxpbmcgb2YgR0lDdjMuMSBlU1BJ
DQo+PiAtIHVwZGF0ZSB2Z2ljX2lzX3ZhbGlkX2lycSBjaGVja3MgdG8gYWxsb3cgb3BlcmF0aW5n
IHdpdGggZVNQSXMNCj4+IC0gcmVtb3ZlIHJlZHVuZGFudCBuZXdsaW5lIGluIHZnaWNfYWxsb2Nh
dGVfdmlycQ0KPj4gLS0tDQo+PiDCoCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oIHzC
oCAxMiArKysNCj4+IMKgIHhlbi9hcmNoL2FybS9pcnEuY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHzCoMKgIDMgKy0NCj4+IMKgIHhlbi9hcmNoL2FybS92Z2ljLmPCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgfCAxNzQgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0NCj4+IMKgIDMg
ZmlsZXMgY2hhbmdlZCwgMTc2IGluc2VydGlvbnMoKyksIDEzIGRlbGV0aW9ucygtKQ0KPj4NCj4+
IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmdpYy5oIGIveGVuL2FyY2gv
YXJtL2luY2x1ZGUvIA0KPj4gYXNtL3ZnaWMuaA0KPj4gaW5kZXggM2U3Y2JiYjE5Ni4uMWNmMGEw
NTgzMiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgNCj4+
ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92Z2ljLmgNCj4+IEBAIC0xNDYsNiArMTQ2
LDEwIEBAIHN0cnVjdCB2Z2ljX2Rpc3Qgew0KPj4gwqDCoMKgwqDCoCBpbnQgbnJfc3BpczsgLyog
TnVtYmVyIG9mIFNQSXMgKi8NCj4+IMKgwqDCoMKgwqAgdW5zaWduZWQgbG9uZyAqYWxsb2NhdGVk
X2lycXM7IC8qIGJpdG1hcCBvZiBJUlFzIGFsbG9jYXRlZCAqLw0KPj4gwqDCoMKgwqDCoCBzdHJ1
Y3QgdmdpY19pcnFfcmFuayAqc2hhcmVkX2lycXM7DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19F
U1BJDQo+PiArwqDCoMKgIHN0cnVjdCB2Z2ljX2lycV9yYW5rICpleHRfc2hhcmVkX2lycXM7DQo+
PiArwqDCoMKgIHVuc2lnbmVkIGludCBucl9lc3BpczsgLyogTnVtYmVyIG9mIGV4dGVuZGVkIFNQ
SXMgKi8NCj4+ICsjZW5kaWYNCj4+IMKgwqDCoMKgwqAgLyoNCj4+IMKgwqDCoMKgwqDCoCAqIFNQ
SXMgYXJlIGRvbWFpbiBnbG9iYWwsIFNHSXMgYW5kIFBQSXMgYXJlIHBlci1WQ1BVIGFuZCBzdG9y
ZWQgaW4NCj4+IMKgwqDCoMKgwqDCoCAqIHN0cnVjdCBhcmNoX3ZjcHUuDQo+PiBAQCAtMjQzLDYg
KzI0NywxNCBAQCBzdHJ1Y3QgdmdpY19vcHMgew0KPj4gwqAgLyogTnVtYmVyIG9mIHJhbmtzIG9m
IGludGVycnVwdCByZWdpc3RlcnMgZm9yIGEgZG9tYWluICovDQo+PiDCoCAjZGVmaW5lIERPTUFJ
Tl9OUl9SQU5LUyhkKSAoKChkKS0+YXJjaC52Z2ljLm5yX3NwaXMrMzEpLzMyKQ0KPj4gKyNpZmRl
ZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gKyNkZWZpbmUgRE9NQUlOX05SX0VYVF9SQU5LUyhkKSAo
KChkKS0+YXJjaC52Z2ljLm5yX2VzcGlzICsgMzEpIC8gMzIpDQo+PiArI2VuZGlmDQo+PiArI2Rl
ZmluZSBFWFRfUkFOS19NSU4gKEVTUElfQkFTRV9JTlRJRCAvIDMyKQ0KPj4gKyNkZWZpbmUgRVhU
X1JBTktfTUFYICgoRVNQSV9NQVhfSU5USUQgKyAzMSkgLyAzMikNCj4+ICsjZGVmaW5lIEVYVF9S
QU5LX05VTTJJRFgobnVtKSAoKG51bSkgLSBFWFRfUkFOS19NSU4pDQo+PiArI2RlZmluZSBFWFRf
UkFOS19JRFgyTlVNKGlkeCkgKChpZHgpICsgRVhUX1JBTktfTUlOKQ0KPj4gKw0KPj4gwqAgI2Rl
ZmluZSB2Z2ljX2xvY2sodinCoMKgIHNwaW5fbG9ja19pcnEoJih2KS0+ZG9tYWluLT5hcmNoLnZn
aWMubG9jaykNCj4+IMKgICNkZWZpbmUgdmdpY191bmxvY2sodikgc3Bpbl91bmxvY2tfaXJxKCYo
diktPmRvbWFpbi0+YXJjaC52Z2ljLmxvY2spDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJt
L2lycS5jIGIveGVuL2FyY2gvYXJtL2lycS5jDQo+PiBpbmRleCBjOTM0ZDM5YmY2Li5jMmYxY2Vi
OTFmIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2lycS5jDQo+PiArKysgYi94ZW4vYXJj
aC9hcm0vaXJxLmMNCj4+IEBAIC00OTQsOCArNDk0LDcgQEAgaW50IHJvdXRlX2lycV90b19ndWVz
dChzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCANCj4+IGludCB2aXJxLA0KPj4gwqDCoMKgwqDC
oCBpZiAoICF2Z2ljX2lzX3ZhbGlkX2xpbmUoZCwgdmlycSkgKQ0KPj4gwqDCoMKgwqDCoCB7DQo+
PiDCoMKgwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19HX0VSUg0KPj4gLcKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgInRoZSB2SVJRIG51bWJlciAldSBpcyB0b28gaGlnaCBmb3IgZG9t
YWluICV1IChtYXggPSANCj4+ICV1KVxuIiwNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIGlycSwgZC0+ZG9tYWluX2lkLCB2Z2ljX251bV9pcnFzKGQpKTsNCj4+ICvCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgICJpbnZhbGlkIHZJUlEgbnVtYmVyICV1IGZvciBkb21haW4gJXBk
XG4iLCBpcnEsIGQpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAtRUlOVkFMOw0KPj4g
wqDCoMKgwqDCoCB9DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3ZnaWMuYyBiL3hlbi9h
cmNoL2FybS92Z2ljLmMNCj4+IGluZGV4IDJiYmY0ZDk5YWEuLmI0MmFlZThkMGMgMTAwNjQ0DQo+
PiAtLS0gYS94ZW4vYXJjaC9hcm0vdmdpYy5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdmdpYy5j
DQo+PiBAQCAtMjUsMTEgKzI1LDYxIEBADQo+PiDCoCAjaW5jbHVkZSA8YXNtL3ZnaWMuaD4NCj4+
ICtzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGludCBpZHhfdG9fdmlycShzdHJ1Y3QgZG9tYWluICpk
LCB1bnNpZ25lZCBpbnQgDQo+PiBpZHgpDQo+PiArew0KPj4gK8KgwqDCoCBpZiAoIGlkeCA+PSB2
Z2ljX251bV9pcnFzKGQpICkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gZXNwaV9pZHhfdG9f
aW50aWQoaWR4IC0gdmdpY19udW1faXJxcyhkKSk7DQo+PiArDQo+PiArwqDCoMKgIHJldHVybiBp
ZHg7DQo+PiArfQ0KPj4gKw0KPj4gwqAgYm9vbCB2Z2ljX2lzX3ZhbGlkX2xpbmUoc3RydWN0IGRv
bWFpbiAqZCwgdW5zaWduZWQgaW50IHZpcnEpDQo+PiDCoCB7DQo+PiArI2lmZGVmIENPTkZJR19H
SUNWM19FU1BJDQo+PiArwqDCoMKgIGlmICggdmlycSA+PSBFU1BJX0JBU0VfSU5USUQgJiYNCj4+
ICvCoMKgwqDCoMKgwqDCoMKgIHZpcnEgPCBlc3BpX2lkeF90b19pbnRpZChkLT5hcmNoLnZnaWMu
bnJfZXNwaXMpICkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gdHJ1ZTsNCj4+ICsjZW5kaWYN
Cj4+ICsNCj4+IMKgwqDCoMKgwqAgcmV0dXJuIHZpcnEgPCB2Z2ljX251bV9pcnFzKGQpOw0KPj4g
wqAgfQ0KPj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gKy8qDQo+PiArICogU2luY2Ug
ZVNQSSBpbmRleGVzIHN0YXJ0IGZyb20gNDA5NiBhbmQgbnVtYmVycyBmcm9tIDEwMjQgdG8NCj4+
ICsgKiA0MDk1IGFyZSBmb3JiaWRkZW4sIHdlIG5lZWQgdG8gY2hlY2sgYm90aCBsb3dlciBhbmQg
dXBwZXINCj4+ICsgKiBsaW1pdHMgZm9yIHJhbmtzLg0KPj4gKyAqLw0KPj4gK3N0YXRpYyBpbmxp
bmUgYm9vbCBpc192YWxpZF9lc3BpX3Jhbmsoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50
IA0KPj4gcmFuaykNCj4+ICt7DQo+PiArwqDCoMKgIHJldHVybiByYW5rID49IEVYVF9SQU5LX01J
TiAmJg0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgIEVYVF9SQU5LX05VTTJJRFgocmFuaykgPCBE
T01BSU5fTlJfRVhUX1JBTktTKGQpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIHN0
cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9lc3BpX3Jhbmsoc3RydWN0IHZjcHUgKnYsDQo+
PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVu
c2lnbmVkIGludCANCj4+IHJhbmspDQo+PiArew0KPj4gK8KgwqDCoCByZXR1cm4gJnYtPmRvbWFp
bi0gDQo+PiA+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxc1tFWFRfUkFOS19OVU0ySURYKHJhbmsp
XTsNCj4+ICt9DQo+PiArDQo+PiArI2Vsc2UNCj4+ICtzdGF0aWMgaW5saW5lIGJvb2wgaXNfdmFs
aWRfZXNwaV9yYW5rKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCANCj4+IHJhbmspDQo+
PiArew0KPj4gK8KgwqDCoCByZXR1cm4gZmFsc2U7DQo+PiArfQ0KPj4gKw0KPj4gKy8qDQo+PiAr
ICogVGhpcyBmdW5jdGlvbiBpcyBzdHViIGFuZCB3aWxsIG5vdCBiZSBjYWxsZWQgaWYgQ09ORklH
X0dJQ1YzX0VTUEk9biwNCj4+ICsgKiBiZWNhdXNlIGluIHRoaXMgY2FzZSwgaXNfdmFsaWRfZXNw
aV9yYW5rIHdpbGwgYWx3YXlzIHJldHVybiBmYWxzZS4NCj4+ICsgKi8NCj4+ICtzdGF0aWMgaW5s
aW5lIHN0cnVjdCB2Z2ljX2lycV9yYW5rICp2Z2ljX2dldF9lc3BpX3Jhbmsoc3RydWN0IHZjcHUg
KnYsDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHVuc2lnbmVkIGludCANCj4+IHJhbmspDQo+PiArew0KPj4gK8KgwqDCoCBBU1NFUlRfVU5S
RUFDSEFCTEUoKTsNCj4+ICvCoMKgwqAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gKyNlbmRpZg0K
Pj4gKw0KPj4gwqAgc3RhdGljIGlubGluZSBzdHJ1Y3QgdmdpY19pcnFfcmFuayAqdmdpY19nZXRf
cmFuayhzdHJ1Y3QgdmNwdSAqdiwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgcmFuaykNCj4+IMKgIHsNCj4+IEBAIC0zNyw2ICs4
Nyw4IEBAIHN0YXRpYyBpbmxpbmUgc3RydWN0IHZnaWNfaXJxX3JhbmsgDQo+PiAqdmdpY19nZXRf
cmFuayhzdHJ1Y3QgdmNwdSAqdiwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gdi0+YXJj
aC52Z2ljLnByaXZhdGVfaXJxczsNCj4+IMKgwqDCoMKgwqAgZWxzZSBpZiAoIHJhbmsgPD0gRE9N
QUlOX05SX1JBTktTKHYtPmRvbWFpbikgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAm
di0+ZG9tYWluLT5hcmNoLnZnaWMuc2hhcmVkX2lycXNbcmFuayAtIDFdOw0KPj4gK8KgwqDCoCBl
bHNlIGlmICggaXNfdmFsaWRfZXNwaV9yYW5rKHYtPmRvbWFpbiwgcmFuaykgKQ0KPj4gK8KgwqDC
oMKgwqDCoMKgIHJldHVybiB2Z2ljX2dldF9lc3BpX3JhbmsodiwgcmFuayk7DQo+PiDCoMKgwqDC
oMKgIGVsc2UNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gTlVMTDsNCj4+IMKgIH0NCj4+
IEBAIC0xMTcsNiArMTY5LDU0IEBAIGludCBkb21haW5fdmdpY19yZWdpc3RlcihzdHJ1Y3QgZG9t
YWluICpkLCANCj4+IHVuc2lnbmVkIGludCAqbW1pb19jb3VudCkNCj4+IMKgwqDCoMKgwqAgcmV0
dXJuIDA7DQo+PiDCoCB9DQo+PiArI2lmZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiArc3RhdGlj
IHVuc2lnbmVkIGludCB2Z2ljX251bV9zcGlfbGluZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7
DQo+PiArwqDCoMKgIHJldHVybiBkLT5hcmNoLnZnaWMubnJfc3BpcyArIGQtPmFyY2gudmdpYy5u
cl9lc3BpczsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBpbml0X3ZnaWNfZXNwaShzdHJ1
Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICvCoMKgwqAgdW5zaWduZWQgaW50IGksIGlkeDsNCj4+
ICsNCj4+ICvCoMKgwqAgaWYgKCBkLT5hcmNoLnZnaWMubnJfZXNwaXMgPT0gMCApDQo+PiArwqDC
oMKgwqDCoMKgwqAgcmV0dXJuIDA7DQo+PiArDQo+PiArwqDCoMKgIGQtPmFyY2gudmdpYy5leHRf
c2hhcmVkX2lycXMgPQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHh6YWxsb2NfYXJyYXkoc3RydWN0IHZn
aWNfaXJxX3JhbmssIERPTUFJTl9OUl9FWFRfUkFOS1MoZCkpOw0KPj4gK8KgwqDCoCBpZiAoIGQt
PmFyY2gudmdpYy5leHRfc2hhcmVkX2lycXMgPT0gTlVMTCApDQo+PiArwqDCoMKgwqDCoMKgwqAg
cmV0dXJuIC1FTk9NRU07DQo+PiArDQo+PiArwqDCoMKgIGZvciAoIGkgPSBkLT5hcmNoLnZnaWMu
bnJfc3BpcywgaWR4ID0gMDsNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqAgaSA8IHZnaWNfbnVtX3Nw
aV9saW5lcyhkKTsgaSsrLCBpZHgrKyApDQo+PiArwqDCoMKgwqDCoMKgwqAgdmdpY19pbml0X3Bl
bmRpbmdfaXJxKCZkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFzW2ldLA0KPj4gK8KgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZXNwaV9pZHhf
dG9faW50aWQoaWR4KSk7DQo+PiArDQo+PiArwqDCoMKgIGZvciAoIGkgPSAwOyBpIDwgRE9NQUlO
X05SX0VYVF9SQU5LUyhkKTsgaSsrICkNCj4+ICvCoMKgwqDCoMKgwqDCoCB2Z2ljX3JhbmtfaW5p
dCgmZC0+YXJjaC52Z2ljLmV4dF9zaGFyZWRfaXJxc1tpXSwNCj4+ICvCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBFWFRfUkFOS19JRFgyTlVNKGkpLCAwKTsNCj4+
ICsNCj4+ICvCoMKgwqAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gKyNlbHNlDQo+PiArc3Rh
dGljIGludCBpbml0X3ZnaWNfZXNwaShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICvCoMKg
wqAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB1bnNpZ25lZCBpbnQgdmdpY19u
dW1fc3BpX2xpbmVzKHN0cnVjdCBkb21haW4gKmQpDQo+PiArew0KPj4gK8KgwqDCoCByZXR1cm4g
ZC0+YXJjaC52Z2ljLm5yX3NwaXM7DQo+PiArfQ0KPj4gKw0KPj4gKyNlbmRpZg0KPj4gKw0KPj4g
K3N0YXRpYyB1bnNpZ25lZCBpbnQgdmdpY19udW1fYWxsb2NfaXJxcyhzdHJ1Y3QgZG9tYWluICpk
KQ0KPj4gK3sNCj4+ICvCoMKgwqAgcmV0dXJuIHZnaWNfbnVtX3NwaV9saW5lcyhkKSArIE5SX0xP
Q0FMX0lSUVM7DQo+PiArfQ0KPj4gKw0KPj4gwqAgaW50IGRvbWFpbl92Z2ljX2luaXQoc3RydWN0
IGRvbWFpbiAqZCwgdW5zaWduZWQgaW50IG5yX3NwaXMpDQo+PiDCoCB7DQo+PiDCoMKgwqDCoMKg
IGludCBpOw0KPj4gQEAgLTEzMyw3ICsyMzMsMzkgQEAgaW50IGRvbWFpbl92Z2ljX2luaXQoc3Ry
dWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgDQo+PiBpbnQgbnJfc3BpcykNCj4+IMKgwqDCoMKgwqAg
LyogTGltaXQgdGhlIG51bWJlciBvZiB2aXJ0dWFsIFNQSXMgc3VwcG9ydGVkIHRvICgxMDIwIC0g
MzIpID0gDQo+PiA5ODjCoCAqLw0KPj4gwqDCoMKgwqDCoCBpZiAoIG5yX3NwaXMgPiAoMTAyMCAt
IE5SX0xPQ0FMX0lSUVMpICkNCj4+ICsjaWZuZGVmIENPTkZJR19HSUNWM19FU1BJDQo+PiDCoMKg
wqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FSU5WQUw7DQo+PiArI2Vsc2UNCj4+ICvCoMKgwqAgew0K
Pj4gK8KgwqDCoMKgwqDCoMKgIC8qDQo+PiArwqDCoMKgwqDCoMKgwqDCoCAqIER1cmluZyBkb21h
aW4gY3JlYXRpb24sIHRoZSBkb20wbGVzcyBEb21VcyBjb2RlIG9yIHRvb2xzdGFjaw0KPj4gK8Kg
wqDCoMKgwqDCoMKgwqAgKiBzcGVjaWZpZXMgdGhlIG1heGltdW0gSU5USUQsIHdoaWNoIGlzIGRl
ZmluZWQgaW4gdGhlIGRvbWFpbg0KPj4gK8KgwqDCoMKgwqDCoMKgwqAgKiBjb25maWcgc3VidHJh
Y3RlZCBieSAzMiB0byBjb3ZlciB0aGUgbG9jYWwgSVJRcyAocGxlYXNlIHNlZQ0KPj4gK8KgwqDC
oMKgwqDCoMKgwqAgKiB0aGUgY29tbWVudCB0byBWR0lDX0RFRl9OUl9TUElTKS4gVG8gY29tcHV0
ZSB0aGUgYWN0dWFsIA0KPj4gbnVtYmVyDQo+PiArwqDCoMKgwqDCoMKgwqDCoCAqIG9mIGVTUEkg
dGhhdCB3aWxsIGJlIHVzYWJsZSBmb3IsIGFkZCBiYWNrIDMyLg0KPj4gK8KgwqDCoMKgwqDCoMKg
wqAgKi8NCj4+ICvCoMKgwqDCoMKgwqDCoCBucl9zcGlzICs9IDMyOw0KPj4gK8KgwqDCoMKgwqDC
oMKgIGlmICggbnJfc3BpcyA+IGVzcGlfaWR4X3RvX2ludGlkKE5SX0VTUElfSVJRUykgKQ0KPj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArwqDCoMKg
wqDCoMKgwqAgaWYgKCBucl9zcGlzID49IEVTUElfQkFTRV9JTlRJRCApDQo+PiArwqDCoMKgwqDC
oMKgwqAgew0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdW5zaWduZWQgaW50IG5yX2VzcGlz
ID0gbWluKG5yX3NwaXMgLSBFU1BJX0JBU0VfSU5USUQsIA0KPj4gMTAyNFUpOw0KPj4gKw0KPj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLyogVmVyaWZ5IGlmIEdJQyBIVyBjYW4gaGFuZGxlIHBy
b3ZpZGVkIElOVElEICovDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIG5yX2VzcGlz
ID4gZ2ljX251bWJlcl9lc3BpcygpICkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkLT5h
cmNoLnZnaWMubnJfZXNwaXMgPSBucl9lc3BpczsNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IC8qIFNldCB0aGUgbWF4aW11bSBhdmFpbGFibGUgbnVtYmVyIGZvciByZWd1bGFyIFNQSXMgKi8N
Cj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG5yX3NwaXMgPSBWR0lDX0RFRl9OUl9TUElTOw0K
Pj4gK8KgwqDCoMKgwqDCoMKgIH0NCj4+ICvCoMKgwqDCoMKgwqDCoCBlbHNlDQo+PiArwqDCoMKg
wqDCoMKgwqAgew0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FSU5WQUw7DQo+
PiArwqDCoMKgwqDCoMKgwqAgfQ0KPj4gK8KgwqDCoCB9DQo+PiArI2VuZGlmDQo+PiDCoMKgwqDC
oMKgIGQtPmFyY2gudmdpYy5ucl9zcGlzID0gbnJfc3BpczsNCj4+IEBAIC0xNDUsNyArMjc3LDcg
QEAgaW50IGRvbWFpbl92Z2ljX2luaXQoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgDQo+PiBp
bnQgbnJfc3BpcykNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVOT01FTTsNCj4+IMKg
wqDCoMKgwqAgZC0+YXJjaC52Z2ljLnBlbmRpbmdfaXJxcyA9DQo+PiAtwqDCoMKgwqDCoMKgwqAg
eHphbGxvY19hcnJheShzdHJ1Y3QgcGVuZGluZ19pcnEsIGQtPmFyY2gudmdpYy5ucl9zcGlzKTsN
Cj4+ICvCoMKgwqDCoMKgwqDCoCB4emFsbG9jX2FycmF5KHN0cnVjdCBwZW5kaW5nX2lycSwgdmdp
Y19udW1fc3BpX2xpbmVzKGQpKTsNCj4gDQo+IA0KPiBTbywgeW91IGRvIG5vdCBrZWVwIHR3byBz
ZXBhcmF0ZcKgcGVuZGluZ19pcnFzwqBhcnJheXMsIGp1c3QgbGlrZSANCj4gdGhlwqBzaGFyZWRf
aXJxc8KgYW5kwqBleHRfc2hhcmVkX2lycXMgYXJyYXlzLiBZb3UgYWxsb2NhdGUNCj4gcGVuZGlu
Z19pcnFzwqBhcnJheSBhcyBhIHNpbmdsZSBmbGF0IGFycmF5IHRvIGhvbGQgYm90aCByZWd1bGFy
IFNQSXMgYW5kIA0KPiBlU1BJcyB3aXRoIGxvb2tzIGxpa2UgdGhlIGZvbGxvd2luZyBtYXBwaW5n
IC0tLT7CoHJlZ3VsYXIgU1BJcyANCj4gWzAuLm5yX3NwaXMtMV3CoGFuZMKgZVNQSXMgW25yX3Nw
aXMuLm5yX3NwaXMrbnJfZXNwaXMtMV0uDQo+IA0KPiBOSVQ6IEkgd291bGQgYWRkIGEgY29tbWVu
dCBhYm92ZSB0aGUgcGVuZGluZ19pcnFzIGZpZWxkIGluIHN0cnVjdCANCj4gdmdpY19kaXN0IHNh
eWluZyB0aGF0IGFuIGFycmF5IGlzIGFsc28gc3VwcG9zZWQgdG8gaG9sZCBleHRlbmRlZCBTUElz
IGlmIA0KPiBwcmVzZW50LCBvciBzb21ldGhpbmcgbGlrZSB0aGF0Lg0KPiBPdGhlcndpc2UsIGJ5
IGp1c3QgbG9va2luZyBpbnRvIHN0cnVjdCB2Z2ljX2Rpc3QgaW4gdGhlIGhlYWRlciwgaXQgaXMg
DQo+IG5vdCBjbGVhciB3aGVyZSBvdGhlciAodGhhbiBleHRfc2hhcmVkX2lycXMsIG5yX2VzcGlz
KSBlU1BJIGJpdHMgYXJlLg0KPiANCj4gDQoNClllcywgaXQgd2lsbCBkZWZpbml0ZWx5IGJlIHVz
ZWZ1bC4gSSB3aWxsIGFkZCB0aGUgY29tbWVudHMgLSB0aGFuayB5b3UuDQoNCj4+IMKgwqDCoMKg
wqAgaWYgKCBkLT5hcmNoLnZnaWMucGVuZGluZ19pcnFzID09IE5VTEwgKQ0KPj4gwqDCoMKgwqDC
oMKgwqDCoMKgIHJldHVybiAtRU5PTUVNOw0KPj4gQEAgLTE1NiwxMiArMjg4LDE2IEBAIGludCBk
b21haW5fdmdpY19pbml0KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIA0KPj4gaW50IG5yX3Nw
aXMpDQo+PiDCoMKgwqDCoMKgIGZvciAoIGkgPSAwOyBpIDwgRE9NQUlOX05SX1JBTktTKGQpOyBp
KysgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZnaWNfcmFua19pbml0KCZkLT5hcmNoLnZnaWMu
c2hhcmVkX2lycXNbaV0sIGkgKyAxLCAwKTsNCj4+ICvCoMKgwqAgcmV0ID0gaW5pdF92Z2ljX2Vz
cGkoZCk7DQo+PiArwqDCoMKgIGlmICggcmV0ICkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4g
cmV0Ow0KPj4gKw0KPj4gwqDCoMKgwqDCoCByZXQgPSBkLT5hcmNoLnZnaWMuaGFuZGxlci0+ZG9t
YWluX2luaXQoZCk7DQo+PiDCoMKgwqDCoMKgIGlmICggcmV0ICkNCj4+IMKgwqDCoMKgwqDCoMKg
wqDCoCByZXR1cm4gcmV0Ow0KPj4gwqDCoMKgwqDCoCBkLT5hcmNoLnZnaWMuYWxsb2NhdGVkX2ly
cXMgPQ0KPj4gLcKgwqDCoMKgwqDCoMKgIHh6YWxsb2NfYXJyYXkodW5zaWduZWQgbG9uZywgQklU
U19UT19MT05HUyh2Z2ljX251bV9pcnFzKGQpKSk7DQo+PiArwqDCoMKgwqDCoMKgwqAgeHphbGxv
Y19hcnJheSh1bnNpZ25lZCBsb25nLCANCj4+IEJJVFNfVE9fTE9OR1ModmdpY19udW1fYWxsb2Nf
aXJxcyhkKSkpOw0KPiANCj4gTklUOiBUaGUgc2FtZSBnb2VzIGZvciB0aGUgYWxsb2NhdGVkX2ly
cXMgZmllbGQuDQo+IA0KPj4gwqDCoMKgwqDCoCBpZiAoICFkLT5hcmNoLnZnaWMuYWxsb2NhdGVk
X2lycXMgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiAtRU5PTUVNOw0KPiANCj4gDQo+
IFtzbmlwXQ0KDQpCZXN0IHJlZ2FyZHMsDQpMZW9uaWQNCg==


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 18:53:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 18:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110655.1459731 (Exim 4.92)
	(envelope-from )
	id 1uuF5S-0005Hg-Ij; Thu, 04 Sep 2025 18:53:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110655.1459731; Thu, 04 Sep 2025 18:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuF5S-0005HZ-Fl; Thu, 04 Sep 2025 18:53:34 +0000
Received: by outflank-mailman (input) for mailman id 1110655;
 Thu, 04 Sep 2025 18:53: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 1uuF5R-0005HT-L2
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 18:53:33 +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 722e545b-89c0-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 20:53:30 +0200 (CEST)
Received: from MW4PR03CA0020.namprd03.prod.outlook.com (2603:10b6:303:8f::25)
 by DM4PR12MB6589.namprd12.prod.outlook.com (2603:10b6:8:b4::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 18:53:24 +0000
Received: from SN1PEPF000397B3.namprd05.prod.outlook.com
 (2603:10b6:303:8f:cafe::2c) by MW4PR03CA0020.outlook.office365.com
 (2603:10b6:303:8f::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 18:53:20 +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.9094.14 via Frontend Transport; Thu, 4 Sep 2025 18:53:23 +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, 4 Sep
 2025 13:53:20 -0500
Received: from [172.31.134.167] (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, 4 Sep 2025 13:53: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: 722e545b-89c0-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UvmEpstWeWWTEMU4kmeEnAHwPX/z52tM3aAMz08CLKU0sMmKNuaPSbMB/R4N7RMVVmh6pJLkUy1QeMjQ4vXUDSsIAKe7c2t0UwLdgug89Z1bMTTyRAoKwXrEQGPVwW+j5FKUWX/B4y2UHAuaFZJSN8jbDQZzkYbM852OajkmpWSjXks/FVzuMXlrIjSPu0eCMZgQqnt+0oWKap9H9uolQiYuG1BUWT9Eo4KD44G11avyqsn6WOl3lSC2aoKgoSQ+sqdz8YJ8K7o3dXHkGVnQJbpa8jYACWfWsnR7VTx8Zp/nMrVPDL8EN4LvtWlr6CNP296pKHAvCOHQQR3JmjVvOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Aa33LKobugZJ2n1Alem9MeMOFTIqWpw0pDgYkKTy/KM=;
 b=VCrobMp+SXEkrvcYVHsN4HQ+f7OCavK0I2BEgkRqiKQupoZOxAIb6lZjhabJcwLN7qA5+wdap+H1NhOlTYvdL3JBTbqPJcjLVos87WEDLaj4RWVhHNpA4mrhdEXcMmVjCccl45URPEUONZ8sLwU53nRPu6OsxPZDCoxV85F7DhmdkziV4lybznszldyMUlPWmZUJ7h355hFW4Av05M3bb4P73GRI76eB9AUVi1wQmzwCVCXiXYrilEjEfQo2KElF1gaKyIWc2x2F/YJIGcDnDXUskf3hzymZKVHN/d6Vs9Nv4kNUsRbwr3f1u84/3Wg2HdVug3gLLqSpseXJv19QHQ==
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=Aa33LKobugZJ2n1Alem9MeMOFTIqWpw0pDgYkKTy/KM=;
 b=dULTV4z9H16Qq1Fsn3UjCwnv0HtnsJ3p+kLQpkU4gdf8fq/aM7fTaCyWZ0BFKNqj4LAO5b6ymZ0YpGdUthQ1QmUjP2+UDaXC5QrLkYemE7JXv8bCId82va7uNas6rGpg7y+taubcpwbuS9as6ni94jNxqKOkDP2p1OoMDCbkPkE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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, 4 Sep 2025 14:53:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
To: Jan Beulich , Penny Zheng 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <849f73f1-4004-4d17-a7a9-d755fb0f889b@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: SN1PEPF000397B3:EE_|DM4PR12MB6589:EE_
X-MS-Office365-Filtering-Correlation-Id: b313d7f2-d0e0-4d2f-be96-08ddebe452de
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?ejRrSzM2Ulg4cDZRVFVqTmNjRzh0SDNtSGM1L2JrSFJqaS9NVmlzL1RHQm00?=
 =?utf-8?B?aC9LV2ZzdnEzRnBMNllFQytzS25BZmpSQWVYd0NFVDlRVUdPZFpPSzBCTG5x?=
 =?utf-8?B?VHN1d2lVWk9GRjkwZ3FOc1NmM2tyeHlnOFpsMWt3eHl4cjdKbUxaeXlOQ09a?=
 =?utf-8?B?aU5NaGpiS09WRmZsVFNybFV3S1ZqNEgyeVRoVzRBQjVZTjc5VkNSeXM0MVo4?=
 =?utf-8?B?NHUvM2N4ZHhnaEJPNDJBZUtkRXgxWk9LUlRBVDRmMjdrei83S1lKUVdkays2?=
 =?utf-8?B?NUJnRWdPYlBKbWVxdzJQeEJDeFFtZ1lRZlhZN1ZtamVINkZBQzZGWnhPNVB1?=
 =?utf-8?B?eU5JQjU3UVN5WFFXbEJDSkpVTGZGdE11SW9scEt0QzlEMGx3NXhIS3V0R3R5?=
 =?utf-8?B?SndVRTgvVVBCZG9sRExyOFBQSEZXRUVYTW1rcXlDZ3FMbzNEUlFicTVSeDc2?=
 =?utf-8?B?K3Fqd0hnNFZkRHhlclZtRzFRR1pUSVdIelJBaDNsSkJIa3N1cGhOMHNIQ05X?=
 =?utf-8?B?TDdwSVlDd1lMaUs0NzBsTGRYS2xYRXVqWHRrMjRid0NBWkg5SFR2a2p1T3BJ?=
 =?utf-8?B?NTBvM0U2dGVkaVU4b25YVnFhVlFHQjFmd1pJL25VajBueGNDQ25FcFB2L1Bh?=
 =?utf-8?B?WTZpNk9BMFpOc2hTMXdsTDV4Ujljdzg1YjdrWGpzTWVodjBQWmhIRFFCbWdt?=
 =?utf-8?B?eEhBdmRQMUs5b1FLNWtaU1EzcUNiNk5SM2Vrc0JJVGhkMGluSkkxTnYxTTRX?=
 =?utf-8?B?M3A0TytXcHdLRXN5RmtDeG1zN3pOYmtyQ2FrbjdvS28zVlBFRXFvQWNVb3U2?=
 =?utf-8?B?VUg2S3M3Y0NpWVN5UkltMEhBY1o1bEhHV3dLN21HdFZLRzRLWUxOWHJyWXVF?=
 =?utf-8?B?UnFBMHV1bFBCRWJZdThtZWIvbWMwN0tJTnJjN3VRWE5sVTI1cnByZjBKQjBh?=
 =?utf-8?B?R2R5YzdiWFZCZmJZRVQwS1NKSjd5YzV1Y2oxaEpMQXpuWlRxcWs1dU9aVldK?=
 =?utf-8?B?WmphM2c2ZkFMZWx0UXBaTFVwWThpSlZEOUs1cjd6OWtzdjBXS2JFVXU2U1Za?=
 =?utf-8?B?TlFFQldNWHllU1hFWUgrSzlXQmNyamFYUkRPc3RWMFpVbDRVajZkdEFEVldv?=
 =?utf-8?B?KzNQM2dCdklSOXVHbTVLMVVna1RTYnIwbSt2a2lKdWkraXNZbDFDajhIN0RT?=
 =?utf-8?B?Z0JBTXFhVXpBWnhIZTliTE0vREYxeVVwc295TXkraWpuQlhrbHVHc3JXbU92?=
 =?utf-8?B?ZWs4NERUcmQvU2xoTGI0RVBBalJYUzhBMnUwQm9VVk9VZWZwek1LWmNVdjBB?=
 =?utf-8?B?ZWJkaitpMmt2ZUN0cTRIU2VqaTBCcDJYaUg5MVRJRkgwTmY2ZVJVbXQvemxX?=
 =?utf-8?B?K2w4ZEF4VktjVmx6UmQwUTFVL2pBTkJTeGlzcmJFSENodS9tZGlCWEF5TnpQ?=
 =?utf-8?B?ZzNMY1p1aHp3TzU4dkxvVkF6TzNqTzIyTDN1THpGTGpuOXd6YUNkdnBHbTNo?=
 =?utf-8?B?bkxGK1ZOTXhNOWZNVDh4amU2MUFLVFkwK2YxRGIyNzRBRGp4ZzdQdXhkQzNx?=
 =?utf-8?B?YUlnT1R4bTR2aDV4blQzdjgxd2FURGYzRzdiRGxUMVpqR2xpVitxaTFlYUxp?=
 =?utf-8?B?eFI1OGhMMGl4bTlCNk9sUmtrSkhFdnBzUUJna292MG5EWXMvRHVCSlBHUDhY?=
 =?utf-8?B?aHU0VmVpUXlkeFdYcU9pR3BnbEt2eUNTTFFHejY3bHZBVytyVFRaUHhKTU9j?=
 =?utf-8?B?OVcwZzVTMVdBTC9PSWpCS1R0Mjg0d01zSGdFajJmaVpxK2VQV2RkYzFxWDV3?=
 =?utf-8?B?TVVvcHQ4bUxnQnVycmQ2RUcxZjhLUHdSdTNQVDFMcDNKU203K0tySmk4MkxU?=
 =?utf-8?B?QnljN1VOVC9DcUtVblRSVEdISnVKU2JMUkEreHFqQmlQY1NyV1BvclZSbEYw?=
 =?utf-8?B?MVN3cHpzWk5ra1RtUjZvbDREKzJVOVg2Z0RiNGFtUDBsOGZZdHE4OU5WdEs5?=
 =?utf-8?B?M21pRnNGc21odHE2TDMrV2pUV1d2NDdmc3A1aDMyTE80TjlySitkSEx3MGZR?=
 =?utf-8?Q?NQPKc1?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 18:53:23.1191
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b313d7f2-d0e0-4d2f-be96-08ddebe452de
X-MS-Exchange-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: DM4PR12MB6589

On 2025-09-04 07:50, Jan Beulich wrote:
> On 04.09.2025 08:35, Penny Zheng wrote:
>> For cpus sharing one cpufreq domain, cpufreq_driver.init() is
>> only invoked on the firstcpu, so current per-CPU hwp driver data
>> struct hwp_drv_data{} actually fails to be allocated for cpus other than the
>> first one.
 >> There is no need to make it per-CPU.>> We embed struct 
hwp_drv_data{} into struct cpufreq_policy{}, then cpus could
>> share the hwp driver data allocated for the firstcpu, like the way they share
>> struct cpufreq_policy{}. We also make it a union, with "hwp", and later
>> "amd-cppc" as a sub-struct.
> 
> And ACPI, as per my patch (which then will need re-basing).
> 
>> Suggested-by: Jan Beulich 
> 
> Not quite, this really is Reported-by: as it's a bug you fix, and in turn it
> also wants to gain a Fixes: tag. This also will need backporting.
> 
> It would also have been nice if you had Cc-ed Jason right away, seeing that
> this code was all written by him.
> 
>> @@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct cpufreq_policy *policy,
>>                                          unsigned int relation)
>>   {
>>       unsigned int cpu = policy->cpu;
>> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
>> +    struct hwp_drv_data *data = policy->u.hwp;
>>       /* Zero everything to ensure reserved bits are zero... */
>>       union hwp_request hwp_req = { .raw = 0 };
> 
> Further down in this same function we have
> 
>      on_selected_cpus(cpumask_of(cpu), hwp_write_request, policy, 1);
> 
> That's similarly problematic when the CPU denoted by policy->cpu isn't
> online anymore. (It's not quite clear whether all related issues would
> want fixing together, or in multiple patches.)
> 
>> @@ -350,7 +349,7 @@ static void hwp_get_cpu_speeds(struct cpufreq_policy *policy)
>>   static void cf_check hwp_init_msrs(void *info)
>>   {
>>       struct cpufreq_policy *policy = info;
>> -    struct hwp_drv_data *data = this_cpu(hwp_drv_data);
>> +    struct hwp_drv_data *data = policy->u.hwp;
>>       uint64_t val;
>>   
>>       /*
>> @@ -426,15 +425,14 @@ static int cf_check hwp_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>   
>>       policy->governor = &cpufreq_gov_hwp;
>>   
>> -    per_cpu(hwp_drv_data, cpu) = data;
>> +    policy->u.hwp = data;
>>   
>>       on_selected_cpus(cpumask_of(cpu), hwp_init_msrs, policy, 1);
> 
> If multiple CPUs are in a domain, not all of them will make it here. By
> implication the MSRs accessed by hwp_init_msrs() would need to have wider
> than thread scope. The SDM, afaics, says nothing either way in this regard
> in the Architectural MSRs section. Later model-specific tables have some
> data.

When I wrote the HWP driver, I expected there to be per-cpu 
hwp_drv_data.  policy->cpu looked like the correct way to identify each 
CPU.  I was unaware of the idea of cpufreq_domains, and didn't intend 
there to be any sharing.

> Which gets me back to my original question: Is "sharing" actually possible
> for HWP? Note further how there are both HWP_REQUEST and HWP_REQUEST_PKG
> MSRs, for example. Which one is (to be) used looks to be controlled by
> HWP_CTL.PKG_CTL_POLARITY.

I was aware of the Package Level MSRs, but chose not to support them. 
Topology information didn't seem readily available to the driver, and 
using non-Package Level MSRs is needed for backwards compatibility anyway.

I don't have access to an HWP system, so I cannot check if processors 
share a domain.  I'd feel a little silly if I only ever wrote to CPU 0 :/

I have no proof, but I want to say that at some point I had debug 
statements and saw hwp_cpufreq_target() called for each CPU.

Maybe forcing hw_all=1 in cpufreq_add_cpu()/cpufreq_del_cpu() would 
ensure per-cpu policies?

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110713.1459740 (Exim 4.92)
	(envelope-from )
	id 1uuG92-0005Mw-4u; Thu, 04 Sep 2025 20:01:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110713.1459740; Thu, 04 Sep 2025 20:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuG92-0005Mp-2E; Thu, 04 Sep 2025 20:01:20 +0000
Received: by outflank-mailman (input) for mailman id 1110713;
 Thu, 04 Sep 2025 20: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 1uuG91-0005Me-1e
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:19 +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 e4489068-89c9-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:01:06 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:00 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: e4489068-89c9-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UxcRTPh4NcfH5j4Pv9Oz3mVcgyoYgcm4/clJkvctYdzkPUdbABhn7vsLlRfpS9SbqjwBhKfChvQSRRXH7cOp55vYIBKS+aYVg3gsSvT9v7ulPaCvhL230+lX0/3A7iIQpdzK54WeuTo0yQpUxPfDVvcgTe9qny7Ug2Hhm5xSLzRjBtEuXL//ySJJsgZcn0Imn6wYTiY/cO9SD+i4N4BHhP+5n7Yuz39aXMINgVVqtq0fhT7s4PLnu5RYkenPNhK7N8mQpdBQYCcALqBDq4cWFqfmZpwpgG+RuOi5dkLnBrkc5RyW0kZrTPDml+ZAvXXJUAbd2kCAE7WqY4hO1WYGWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ks6Jq/KdQ5OiANovjTsiVIvn5MnPmzaxPuXYEs8DDK8=;
 b=S5uPz9sjLzYgPIoUsH9oMxhmJ+DGAw7iBlP46AaFWJy1h7+hkyIV5EdkDlVhy/n4jCQfaSFzZlMaI7Yf70fQdYnfOP8F/0qdCL+d8+HrPlmfl5K26uD/idOuirMbD2xMqWjsiTwfpG7Rwu47SLsZ553wzak0jW5xy9+qv3FTwm4vHKOJfPhzbdoe1+p+hNwB9WeXN9cwNhngBFOPJJ0rPLXE58wTiQlXrEOZwrsY3a5hdZDOcVhDQ3Wq6XjP4fG9jsKl4k4LionpOJsRhLoH1MOhJl0dHn6VoiCjCuiSwt4zwGuoA2iJIS98NVU27ul9umR/DExxWUco4c42B1m12w==
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=Ks6Jq/KdQ5OiANovjTsiVIvn5MnPmzaxPuXYEs8DDK8=;
 b=B7lUDFE9SvwrPL92x1aDo+6pZiftueYBnH0nQ7cDV36R0jaVLeWXT3kx3mqTXks7DNVOnGR38cZT7kmF2UFYGQNWVpqT11nOOCQr9NziqNlLdKLo3BmVC6Jr7ejAgflo+RspylAUSgZ4HEj480+bqQoUN5Hxd/HYxIwXQCYqYrsDz+QHSDGdEtp+RkXi9F73HmlH/R//G20biwFc2jdvraHgVJTRht7Cym++fFSh4dNLMtFmtjzvTS9i8w3spcbRewh+atjVsFAToZPCj6aHM936MxGqZOXMUxgVK4dM90rQ9/f4O69iAvqhEL2PM4Xbfr9adKvUnLsVBcpyGRZ8UA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Anthony PERARD ,
	Oleksii Kurochko , Community Manager
	
Subject: [PATCH v7 00/12] Introduce eSPI support
Thread-Topic: [PATCH v7 00/12] Introduce eSPI support
Thread-Index: AQHcHdai+Ac/NEuVikikoMKerzFsQg==
Date: Thu, 4 Sep 2025 20:00:59 +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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: fe3b533d-3f24-4d36-0576-08ddebedc4f5
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:
 =?iso-8859-1?Q?dBjiSc3ZXgvpIGwWr1c+simAWHzZJazpE6J49hcLETAWvxbofjtyD6ozER?=
 =?iso-8859-1?Q?mJ7PMxWw2roywT0XZAnPwxfamt3cSwyze9MPrPNe5mt2vXTbVN6tVmJNNZ?=
 =?iso-8859-1?Q?OkKeXYjq3K5SS5rnzQR9wB8lV0dcixR29yp/Lq26Ekpk+rl1O/0qgrLX3O?=
 =?iso-8859-1?Q?vFth9Cm9I9HnekIy511M1CCCcQw1UDuoKy1RYLpOPtEz7P0UehWZkMGeSb?=
 =?iso-8859-1?Q?8FCVoKWWdeC61ZvJydwfVbGO5qe+lwtBpXYfM6vfB6fXgYeCn5Nj7nP3SF?=
 =?iso-8859-1?Q?AfLLdx58Ob4s37ZNoUmVzJFMg2m64h2HAexGdRhqp3FU7BhuLSNXOqA8zE?=
 =?iso-8859-1?Q?peQE1lJvlXUOkT4HTJpOukjLLlV2xanoiorLWcX/Dq3PItPkLPgz3AS38g?=
 =?iso-8859-1?Q?Wro8APcFlkYYDUhWVvigbKxRI5HDoOGdDrkSdEZaL/Dd+UzGEtGRhdM3KT?=
 =?iso-8859-1?Q?wekbmLdVLX5yIWpg8/QMMuAiE6cZnUZH0gmGZYippx/LZdtsVrWxXvGVa7?=
 =?iso-8859-1?Q?2gQUx+lZ96WAav2+BBpE334hK3Xhtmy3Mja3cD6FG2/vzVgXNCePjpvWdx?=
 =?iso-8859-1?Q?m/1BTzNHLItgPsd0YwT7/p9aHf67fIiWx0jxZdyQBqaVhQcQdg/B+8cORb?=
 =?iso-8859-1?Q?4Iyym8FXFM7+KgMpGNFapNJVIXIykOVJJ8cnbxDrrwl1iBjhB7AfZ0cjD4?=
 =?iso-8859-1?Q?2MXaIWkaSpf3vSRP7H/iOCB6GRm1JgktpR7iJmtji9t3li/OPKfbX1bSDO?=
 =?iso-8859-1?Q?3yRrvrecGmQXhywJDcuVZZ9fu/0Ny4RYjNN/pbPx2N7WMdWw9Z9VvkwL10?=
 =?iso-8859-1?Q?gLs4B1EoXo3Jl36LhdAE1joTy2i0UclDpBAxmPx7D7Zt7UhGXdsAiF64KF?=
 =?iso-8859-1?Q?mSv5eUSr7qqOTaAw7qhMGW9hleYe1DA6HeS0udn+VObiGTkoXH7/u55nf3?=
 =?iso-8859-1?Q?sAfpaCwgs+ISfEH5Ch8+rKw/YuSjuWnTa62BGhs/gPeEkrTywwyMCjrsFp?=
 =?iso-8859-1?Q?WshHTjWPTYFzPlAad6gjTemOe6JrACo/KwNisAvASL/J5re276l3Eojz9/?=
 =?iso-8859-1?Q?NInd/qTUMKkc25Mbj4dkEkvkj02GKZg7TvB9d6WRoPyoIeMI4rWx63SjUE?=
 =?iso-8859-1?Q?AkZJvJWlA1maAcGQkharsx6IJK5l2+UZOmjvfSshgh8yG5WdBmtcUds1w+?=
 =?iso-8859-1?Q?Qm2He4pkirWqw7ACkrr12jyRPDK6t5+slPc/o7xnNtHGDSbbs/4u2FGRtB?=
 =?iso-8859-1?Q?1PBGdIThDPtPhGha3JH3J/iEH0Hev6zFezgkiTKZeYl2tMCXXKj7RWkQ6F?=
 =?iso-8859-1?Q?v88hW3Nhkuth/wpR6wuNEhgPO4U106AmNO1myaC3wUYACN5rcZiMF46P6l?=
 =?iso-8859-1?Q?g1ZxdKqugEeEhv8Ii0yjYO6lqut7rtugM7uNOuvoh0p8H7broUpdT/RHtA?=
 =?iso-8859-1?Q?P8Ph0/cql7rfFn0e/pdL+hLZs9W/XlnU5nBJit9lTDh4n9xykkwd6Wu3fI?=
 =?iso-8859-1?Q?s=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?iejzS9NBNa4YkmD2WcrMDbJEi7Y+C6giWG9l3nQmL5oTDRhlvWB8rigMCq?=
 =?iso-8859-1?Q?YqLwPNduuc28+8d74sOSOXR7plkTjcpVFaOmOTe3wjGIJzEuAKlQ2vRAA0?=
 =?iso-8859-1?Q?gFN+nW1WWm9Exy4n3FLUAYmhvBuV+WO4VwHoMikW9qicTwbbH3SPHaLu8N?=
 =?iso-8859-1?Q?mJJuCOGMznWuKWcY0FR8RUOeGjjQ1rV84vm8rk4RHv56cq/zGJ0kY2R5B8?=
 =?iso-8859-1?Q?3PQJkjWbLx4QqLAFqYn/nhUEZvtCDVWoFWYCj/adw9rP7SroYV36tIhq/u?=
 =?iso-8859-1?Q?DQdTn4Uz5x1kwNE+14cBoY6KelaG8qbiGV1k5XS5BsSdbWFIKWV3TAgH5c?=
 =?iso-8859-1?Q?qO7paEvNujCe5Xyjba+ntgI3vARf/3KLQkCtp2uEDlfNKRoko3fHmLhbO0?=
 =?iso-8859-1?Q?XAA0QeOPdtAXNTkuUjmBePBGPbb6BagDPPOZ4SRevcN9Cqnuuj6W1GNVOT?=
 =?iso-8859-1?Q?jr94E6MsA+SEtqTc+6B9PQGvseHeP8NLHZ3DcTpGbDTFBFHVPxhjGtc/yj?=
 =?iso-8859-1?Q?frQHQJEK/f4pnR28RjVQm3F7TxU+TStKmZc7s2jVzg3gA6nio+b6/VTjDs?=
 =?iso-8859-1?Q?M+A/TSQFr9j76uvN11A8g24hL4sx0FU689s0mKirFMZtmTXgHUcSD89UM3?=
 =?iso-8859-1?Q?JLFKcMqaAQp0FwOc4wprkdIK1pMvp+x2xnkDOlWdUORDg3zJZOuZRiIFmN?=
 =?iso-8859-1?Q?nA8+j/JJInVekkHHXyJTh/K+U0dvGlTU9Dl8fiTXwBKJbxi1smNKUUUjmI?=
 =?iso-8859-1?Q?4654l4XmAAr+t/GYPYJYXKdie5qG0g7x7YGrveeq6kRv39SQGSkjKLPReI?=
 =?iso-8859-1?Q?DsFnOH6KGuhaagF8tOShZSlbtRC+fJ3yqUX7pmllfxjvNGWYMOm+DAGSgc?=
 =?iso-8859-1?Q?xyChOrTdiQrljmC6428iGqsKB704XCQA/P4WBfHAsv52wNTNSdTS4rz/yJ?=
 =?iso-8859-1?Q?IuWM9mufAFx7t17aWyhrqZf2MpsZtW5N5K79Mf9Fx/gpGwaZdGd3P+556M?=
 =?iso-8859-1?Q?e2P5+RSaHcLg2zWvAxHhJF+3vfOR6BOov4LfyHgQWgg2fknE7zAxFZ+zVV?=
 =?iso-8859-1?Q?MWPglFads083f7wFpaOa3rVyl/D6gXBjBvadjg2u3QZ4sh7KjJp8X5+euO?=
 =?iso-8859-1?Q?lsRSQbc58x57LUdtyNYR1Y9ipy3LbhTMHwKlH8lxjdiD7gUlN59grR+Q4n?=
 =?iso-8859-1?Q?HTTMTZjD7skNO2ooKWcoBTk800eYI4VqK4BBx3TqGzupjfzkUZPjBstMNA?=
 =?iso-8859-1?Q?nyEolZeMEGa55yhfLZ3VrZB6rmDMrs+8F1XOW6aWO9yWjgOgaHJWvbVVzA?=
 =?iso-8859-1?Q?JZsyIOlRL398J/SvxTVuFIXxCGDUwTcD6WBZ/utMoCgf520cmeaGnyz59j?=
 =?iso-8859-1?Q?Ms+x4bOxDySc9eMt/kgU7fEAYe+QzZ+xNr6FnJYq1L62X3RXcMk8raIoeE?=
 =?iso-8859-1?Q?GvJFxT7A65a2v8ppSMff8kTOk43qkN7fI6OF5Atoo1b23PmeLC0IATvhcK?=
 =?iso-8859-1?Q?85zFO6pxsiF5WVjBuFfLjecjO70tVDgkJH7qRT9G4YqVQsJDO+3l2IySOA?=
 =?iso-8859-1?Q?U95aVbmvX2Z4/l9CeMm6ozdJ+vWzLggZKZC6Kxi8ZSJ9VUptHmNvDX3ejY?=
 =?iso-8859-1?Q?mHPpbgBYrizmN1QGOEUMxwynFe4VVAXScnF/ycaL929Mv2ZV8kDYoiYfzx?=
 =?iso-8859-1?Q?dzVstEkHj5L+VoF7k0k=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe3b533d-3f24-4d36-0576-08ddebedc4f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:00.0316
 (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: hhfUqBUy7vCTxltbBUte9NcYIIAA0wk2DWMgJQyPcIt+DbGbdZXEt/T/swZdyAOJQSe4xMlDGJ7UzXIPB4/944kMqMnU36YhQ7reZi8KtFU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Hello everyone!

V6 contains an issue for debug builds with CONFIG_GICV3_ESPI=3Dn due to a
mistake in the ASSERT() condition in the is_espi() function. This patch
series fixes the issue and also includes minor fixes according to the
review of V6.

Summarized description:
This patch series adds support for the extended shared peripheral
interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
and guest domains. The implementation uses a generic approach to handle
eSPIs, similar to regular SPIs, while maintaining compatibility with the
existing SPI range. Functionality remains unchanged for setups that do
not require eSPIs.

The series includes:
1) General refactoring of common IRQ operations with GIC registers to
improve code readability, simplify further maintenance and prepare the
key functions for eSPI implementation.
2) Introducing a new Kconfig option (default n) to enable or disable
eSPI support. Disabling this option prevents unnecessary resource
allocation for setups that do not require eSPIs.
3) Adding additional resources to store required information and operate
with up to 1024 interrupts from eSPI range.
4) Adjusting assertions and checks to pass verification for INTIDs in
the eSPI range.
5) Configuration of eSPI-specific registers during GIC initialization
for systems with GICv3.1+ hardware.
6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
access and operate within the eSPI's INTIDs.
7) Updating documentation and CHANGELOG to reflect the changes made for eSP=
I
support.

Also, to simplify reviewing, please find below link to unsquashed patches, =
that
are on top of every patch, that is changed in the series, compared to V6:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v=
7-unsquashed/

Github branch with patch series:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v=
7/

Changes in V7:
- individual changes in patches

Link on V6:
- https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00296.htm=
l

Changes in V6:
- individual changes in patches

Link on V5:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.htm=
l

Changes in V5:
- individual changes in patches

Link on V4:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.htm=
l

Changes in V4:
- added a patch for documentation
- individual changes in patches

Link on V3:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.htm=
l

Changes in V3:
- added a patch to update CHANGELOG.md
- individual changes in patches

Link on V2:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.htm=
l

Changes in V2:
- added 2 more patches to implement helper
  functions for gic/vgic:
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
- removed 2 patches:
  xen/arm/irq: allow assignment/releasing of eSPI interrupts
  xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
  since their functionality can be moved to appropriate patches after
  introducing patches with helper functions
- individual changes in patches

Link on V1:
- https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.htm=
l

Leonid Komarianskyi (12):
  xen/arm: gicv3: refactor obtaining GIC addresses for common operations
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
  xen/arm/irq: add handling for IRQs in the eSPI range
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
  xen/arm/irq: allow eSPI processing in the gic_interrupt function
  xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
  xen/arm: vgic: add resource management for extended SPIs
  xen/arm: domain_build/dom0less-build: adjust domains config to support
    eSPIs
  xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
  doc/man: update description for nr_spis with eSPI
  CHANGELOG.md: add mention of GICv3.1 eSPI support

 CHANGELOG.md                           |   2 +
 docs/man/xl.cfg.5.pod.in               |  13 +-
 xen/arch/arm/Kconfig                   |   8 +
 xen/arch/arm/dom0less-build.c          |   2 +-
 xen/arch/arm/domain_build.c            |   2 +-
 xen/arch/arm/gic-v3.c                  | 195 +++++++++++++++++++----
 xen/arch/arm/gic.c                     |   8 +-
 xen/arch/arm/include/asm/gic.h         |  28 ++++
 xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
 xen/arch/arm/include/asm/irq.h         |  38 +++++
 xen/arch/arm/include/asm/vgic.h        |  56 ++++++-
 xen/arch/arm/irq.c                     |  62 +++++++-
 xen/arch/arm/vgic-v3.c                 | 203 ++++++++++++++++++-----
 xen/arch/arm/vgic.c                    | 212 +++++++++++++++++++++++--
 xen/arch/arm/vgic/vgic.c               |   5 +
 15 files changed, 762 insertions(+), 112 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110715.1459761 (Exim 4.92)
	(envelope-from )
	id 1uuG94-0005oq-Mt; Thu, 04 Sep 2025 20:01:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110715.1459761; Thu, 04 Sep 2025 20:01: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 1uuG94-0005oi-J9; Thu, 04 Sep 2025 20:01:22 +0000
Received: by outflank-mailman (input) for mailman id 1110715;
 Thu, 04 Sep 2025 20: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 1uuG92-0005Me-N1
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:20 +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 ec2c6fe0-89c9-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:01:19 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:11 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: ec2c6fe0-89c9-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ABBq6qnYPiOvPcB3kNkCO8devkBd0sPDBrU/6ROIrfiZA5ruZbA8YmraQwZuqHA/Z13r9K7S0Qu3LH7B0v3P+nXbLrUSmA4PBwHCDvhNGLCWBj7gU7HqURpIagCYv6C2trdNg9iG6hkxemrFs5mN8i7dRUlC4J4eairU3ul0PdoA7alXvyIqi0+Oidd79v0Vxml2Yio3h+RM6Lhl4Ip0kWWECCb4ytxX51td0ulxHkWMa0lCzHp2hsIGrjaqsKeNsOAirxlrQxo8FB8/ViLV27TrRFwCSn12IUhp3In/UpYrHTqRJsSenVdYSWzHPgxli8EzkjnntG6MfhRdViCD1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=f65apG4C53Gx80G7sqxIHr7SUDXQIALLuO5Rqk5ixqY=;
 b=FKZOipOEUrrp38t7fu42jwDDnhj1tV+ohOP9bFvp/yLpN8hGVKu+Bboc+82R4wQ+AHZQWGH0UfnEHlqXS3wvJKp/r+aCpyJW1t2ENvxSAsEZ7ILyqxKtQlUiYiL/wTF/JB7PR19gLOCyQooTApsecigkBvjLQFDsOkuBMhK4C49Iled2vF3sq0a5aPsV3+kPOtZTde6DIvTiUTKgwQl3KvDtATOZwdqkOcZNacZbD4fBaVS+zrAFU/ls9pf4aLFNPzk2DLIdw1+uXNl4VHizcfA4Dron9Qbka6OFil4lNtUO/j1TEow4+MCzu5bEJSELWwoEmOZGB0AwehKYfRJAmw==
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=f65apG4C53Gx80G7sqxIHr7SUDXQIALLuO5Rqk5ixqY=;
 b=VgAG0Fgn+3UdqjqZnT+OS1iXmpYxo5xzfDJZmO0EKVj/iMAKXk7pzdbhGm8NjHDI1ow8dyMsW4NWhMIgbWjnMkQA1IQWj5y6Vheuo2XLopygHcUjvWpEvdUdrNriiqUQXxvdWHsCOLlaRgmwvBSFP/8Fx5zhJDO3fTTjUAr80ySKf5vphTXrY9RH/nXi0XGzA709W2C6uJoQeYGJpFBtEzI5VXX79uKoiiyNJxIqFxJjXeg9ndwiiFuFQmDqRS4DhELHezQnUTdcEVuAhF8GDHPulJYZ+AXBF85Rr5uggfvqDsfZKJLOBj+VPQk/CvIFV+oMiX2eQ8+ooL7Dm9YnSg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v7 02/12] xen/arm: gic: implement helper functions for INTID
 checks
Thread-Topic: [PATCH v7 02/12] xen/arm: gic: implement helper functions for
 INTID checks
Thread-Index: AQHcHdap1hDc78ei/Ei0f3qUM8qeYA==
Date: Thu, 4 Sep 2025 20:01:11 +0000
Message-ID:
 <896848d3f4758e45e032351b5759965e041ed220.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 5237f30f-611a-41c3-1894-08ddebedcbd9
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:
 =?iso-8859-1?Q?cf0IDe986aEk3hgOBmSZSpoXYTLiEAtLfdKXLvT2bCz/QYrYJIGlKh2C6p?=
 =?iso-8859-1?Q?Kvn/28HvZgd3ITf6we1Lpzj/+jE+CK8+8N24Q7b5OCPrDSRLI7AKETgLGW?=
 =?iso-8859-1?Q?aHxXWCcVHFkKDRjO0a7SMSH69wUooFZs2jNpVGdwelsYAPO1f52+5pR7Zl?=
 =?iso-8859-1?Q?ZtDuTjqLf3HBNqbXRTfMwivMa5QWopmJ1/oJ25I+IaLwzJWk5VirJtB8kz?=
 =?iso-8859-1?Q?mJWrC+/jrXAVkAk//Qv0M6JdZnVs1x+FZOTjBBVzl2fV2y3TUjuraYM2i7?=
 =?iso-8859-1?Q?0lRLIVsAkJE7rt7O2c8tPAyDV4f6FQNQg5aacFfO8NYhDQwlPmudsCV94f?=
 =?iso-8859-1?Q?nEL3UTLCKKSdkmKkGH7z7j1Rop5bPn9nJTKcpZGoolaFsa4avcbpiro+E2?=
 =?iso-8859-1?Q?wAMLP0Iy/ltQ4RH8RlxT1vfejRl0UVpRrwsvNWEThFSVFWehilPPz3jp49?=
 =?iso-8859-1?Q?alVhUaKE7PEB5wDhHlAurYWEgSl1jPOvm5OROOSKg4Twfsr8JNddeWBi3u?=
 =?iso-8859-1?Q?3724Hjy451mYODzHJ9lu/wH4aW73sH9GKM40zOW9lu1itQ5wZo4HpCc04y?=
 =?iso-8859-1?Q?jwiUQOpq9bznUDc5esrWJNlJXfa2dX/Bhk9qylAvdNHCTP/Xu+CnAljOJt?=
 =?iso-8859-1?Q?8plFFnAs4ldVgRqlx2x9Ph7h9cAFNLFKB2Sj27ZCULQ8A+VnZu4Jh0XxZK?=
 =?iso-8859-1?Q?RCaTDGAON/rtcztEfh9CcfaKMG07AfDZGuTxVROLrGZUeJiFOZz2+c3BQY?=
 =?iso-8859-1?Q?kHJPOg7Gfiouw+EwI1gs5Mi6RkXtfcY9LDwjtMP0csR89mkm4tTnfLpnw0?=
 =?iso-8859-1?Q?AwDMnoklJ/rSNxoanhsAF58aOeI/Ul7atZDPw0y2hpZABk8W4QJGzr5oix?=
 =?iso-8859-1?Q?SLiLmD3xLixHqlyP1hK6hwnIsdzbgF7Z/OVLrb4HiFwSqJ+IPYEhRYXmt5?=
 =?iso-8859-1?Q?j7ModaHw5jk4wfydY5VvxkXEqTc+Dwrm2MQfbqILAZc/HL18H0FRNkYShv?=
 =?iso-8859-1?Q?StF3HcZNE6Jb9mQS+Z3gYDWknbBnC9TxMjRAxiY9vlTP/BLxOWSZnl+t5v?=
 =?iso-8859-1?Q?hEnjDTFp96mYS2PaNmj4cHUE5S+gt+OYeQJOuLNRdAlBKBSdS0POuhMO1x?=
 =?iso-8859-1?Q?hrtgJ0t6mcVF/Wh9FRXEIzDtQxAPLC7xE7Xl0XwVKjkp17RVR9+d78S2ig?=
 =?iso-8859-1?Q?6blxfjD1vJLyOzcO5LovLot33jjjpDTP6vXZ7qBxByymon38N/kfUaSqQ5?=
 =?iso-8859-1?Q?FBM/E/IBHNYPqgSrnMWtW5Dgfm89SIfwqMs2RNoF4Wgdn3zhZ8RyT/qvEU?=
 =?iso-8859-1?Q?MJwi92ddqr020IYXRZdO5WFp53L4OTt5Bvn6dy82HL+C4gEV8VZf7Igdot?=
 =?iso-8859-1?Q?Au3RaZF17p30rXV3aTKYPLKaS/UkhLGzWXIFUHNIuufZnu88YkaaEAlloR?=
 =?iso-8859-1?Q?zhBCkSJ8W+APnyD2uYJVqOzngxf+54YblAo8eHfetjNtUifVqhJCpFoYSH?=
 =?iso-8859-1?Q?VgmLjApr2dFhqzsTpDLJd3bt32JMsBhePwj9XjPa0LIg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?mCt6YRpyEfA2JcCbZJ2zTREwdUF74mHJZ6gtOPp0DeubF08TXV9OEoFvjf?=
 =?iso-8859-1?Q?moee0inU5jAJrmpdFH2+G7wEiiz9u9AkaqrqIQCMTWVir4xHjEE4/s2/a8?=
 =?iso-8859-1?Q?dK9BgKmORVV8gFK2HnpsiAk8l7J610LO9c9sE44ECGFwZMosHhe+nrDCPp?=
 =?iso-8859-1?Q?9u5XEflPiqJCX5aoScprdicEYzLonnZORFg6fsUKyeC9V0Syf1svjfW9y0?=
 =?iso-8859-1?Q?W0C0tGJOqtJ1nqtjk8IpXuYIK9JidntBSF3YWkyVd9ialFFBMovMt7zSHp?=
 =?iso-8859-1?Q?/bI9vXQPZvQ6eDPMVJOzMqjxKbH0cgWxMFFmvk6B2txiUM3tnoTIPNlMFP?=
 =?iso-8859-1?Q?NvdREuH+KIn+0Rg42w8A2uM0WQksgI60/6DWhRGGdoNCjv9ypaF8rByh6S?=
 =?iso-8859-1?Q?EDCgmZe32YrG3BskobDDbd0iLTjJbZdBskrWxHDqJD/EUlSz2e9Qs+n6Z8?=
 =?iso-8859-1?Q?hTNpU47j1XhkZH63t2zw0pcugwea4Z+6ozF/pjtFKncXEaVfJhdLkNinxX?=
 =?iso-8859-1?Q?XpQGhwI00QxdYNOvMIwkF4jepHDHc2dQBRfYUlXQYmLqCfphdAhnVE3t2z?=
 =?iso-8859-1?Q?6qPusxIYaY4whYBj3el+V2S6adtIoEBu/6IbehNLVI3SdRfpwqOB9I2ejC?=
 =?iso-8859-1?Q?FhwHId82Zd2NhqMsfWVo+u0SGOubybTa+YUXRc8PbARymf5Q5rPqKC/o15?=
 =?iso-8859-1?Q?iDNo76yzXgvJaB/1vFJE98LcgpWjR6qlmsalokCbCctMpHm9zm8dCxAfdq?=
 =?iso-8859-1?Q?egSTVv6yxQ9iWZNRkvF0ZExf3fw0k6w8NA8hMOAkMYzNQdwtqdwvKYi/98?=
 =?iso-8859-1?Q?tTgY2b3He+Yr6ORp5JHQC36/Vyu75+DAErOvm7AD4v/4S+WaRHyaRYe/qX?=
 =?iso-8859-1?Q?4eI3FxURrQI6HOUtxIzJRJgE4pTBk04Zvxm1I4Xp+aviboubyvjPGb0SyP?=
 =?iso-8859-1?Q?hMh/Rnl+v+iZ3+YlgTQH5Ja+LotIBKgsu+c/+KUjaftDCaEACmiMg67d3S?=
 =?iso-8859-1?Q?SVSaxw+6EHrRMMozbavfQIUGRYPxusFYYAqEWeeGtaizkrDf2B7wXP0i8U?=
 =?iso-8859-1?Q?UWOSB4/6e6ZMojqQRuzYh0hnVAesW8hOUIRf8lgPbMIycV5QcjSw7FANPP?=
 =?iso-8859-1?Q?OSLYLoJwPT0Evv47IrnXKGKat9Jtzf9K+2EV8CWqPoX4kJWYWNizVnUXQF?=
 =?iso-8859-1?Q?+XIjGAbDA0xF66e8DZyZKRchW8JOrHTgdQMoxzi1mOKOtCSfU+cdZvVESD?=
 =?iso-8859-1?Q?lZXrmj5mn1+yzWszsvES+5DpKVpmRIQu8KErJMxednxDcivbkpZH/U7FIy?=
 =?iso-8859-1?Q?2GVMKsFDlqYqq3xXMJ+Go40zB6wJWKqOfJ2Osp1L9uyEISpa5cfdKOMLA0?=
 =?iso-8859-1?Q?69wG/xCLnUvnj4/wC1xeVv7vvqVfme/ZZupAczBgB2uHOXttZVxKLGpYRH?=
 =?iso-8859-1?Q?dq0rZiWvB0UqTPKyRxNMBC/DU6SFdUyPmzTZnN5jOo246hPGlCefZ/Nr+v?=
 =?iso-8859-1?Q?zrBqk4B36638J6Tx9cgFwy7SjD70pWe+HbGzGZ7dUsyoJ6LYKkX7AwURFS?=
 =?iso-8859-1?Q?aLcYStJDZQl5zIULI+anWMPETvcJiUxgXkfAz2CEieefuv3pzhrre0Ygw1?=
 =?iso-8859-1?Q?kLQnMdiU7JJU8eBOXWONTKpuXq7FJE4YzmfidXBFfyoB7EaMC+N7Uq1net?=
 =?iso-8859-1?Q?sQaFJwG3CtnKl6kzbdg=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5237f30f-611a-41c3-1894-08ddebedcbd9
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:11.5910
 (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: hNuJSajT1wjc0vV9zBCzGTylrQVrM1gGe0xbEHqINQugq46vy2y+mwiv0SnRxuF+0ohHuZ0oGFPNy5zxhs+9bG1EJonpXT0NQGkBq4Zr/D4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Introduced two new helper functions: gic_is_valid_line and
gic_is_spi. The first function helps determine whether an IRQ
number is less than the number of lines supported by hardware. The
second function additionally checks if the IRQ number falls within the
SPI range. Also, updated the appropriate checks to use these new helper
functions.

The current checks for the real GIC are very similar to those for the
vGIC but serve a different purpose. For GIC-related code, the interrupt
numbers should be validated based on whether the hardware can operate
with such interrupts. On the other hand, for the vGIC, the indexes must
also be verified to ensure they are available for a specific domain. The
first reason for introducing these helper functions is to avoid
potential confusion with vGIC-related checks. The second reason is to
consolidate similar code into separate functions, which can be more
easily extended by additional conditions, e.g., when implementing
extended SPI interrupts.

The changes, which replace open-coded checks with the use of the new
helper functions, do not introduce any functional changes, as the helper
functions follow the current IRQ index verification logic.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- fixed a minor nit: moved the existing comment to the line above to fix
  formatting that exceeded 80 characters
- added acked-by from Julien Grall

Changes in V4:
- removed redundant parentheses
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- renamed gic_is_valid_irq to gic_is_valid_line and gic_is_shared_irq to
  gic_is_spi
- updated commit message

Changes in V2:
- introduced this patch
---
 xen/arch/arm/gic.c             | 3 ++-
 xen/arch/arm/include/asm/gic.h | 9 +++++++++
 xen/arch/arm/irq.c             | 2 +-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e80fe0ca24..4bb11960ee 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -111,7 +111,8 @@ static void gic_set_irq_priority(struct irq_desc *desc,=
 unsigned int priority)
 void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(priority <=3D 0xff);     /* Only 8 bits of priority */
-    ASSERT(desc->irq < gic_number_lines());/* Can't route interrupts that =
don't exist */
+    /* Can't route interrupts that don't exist */
+    ASSERT(gic_is_valid_line(desc->irq));
     ASSERT(test_bit(_IRQ_DISABLED, &desc->status));
     ASSERT(spin_is_locked(&desc->lock));
=20
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.=
h
index 541f0eeb80..3fcee42675 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,6 +306,15 @@ extern void gic_dump_vgic_info(struct vcpu *v);
=20
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
+static inline bool gic_is_valid_line(unsigned int irq)
+{
+    return irq < gic_number_lines();
+}
+
+static inline bool gic_is_spi(unsigned int irq)
+{
+    return irq >=3D NR_LOCAL_IRQS && gic_is_valid_line(irq);
+}
=20
 /* IRQ translation function for the device tree */
 int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 03fbb90c6c..7dd5a2a453 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -415,7 +415,7 @@ err:
 bool is_assignable_irq(unsigned int irq)
 {
     /* For now, we can only route SPIs to the guest */
-    return (irq >=3D NR_LOCAL_IRQS) && (irq < gic_number_lines());
+    return gic_is_spi(irq);
 }
=20
 /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110716.1459771 (Exim 4.92)
	(envelope-from )
	id 1uuG96-000644-Tp; Thu, 04 Sep 2025 20:01:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110716.1459771; Thu, 04 Sep 2025 20:01: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 1uuG96-00063v-RF; Thu, 04 Sep 2025 20:01:24 +0000
Received: by outflank-mailman (input) for mailman id 1110716;
 Thu, 04 Sep 2025 20:01:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuG95-00062f-Tn
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:24 +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 ed908d7e-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:21 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:19 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: ed908d7e-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gVECdtmfvm/ifmprLF123ovutT5zrvHgw2ykQrQHGBUBTCaW/C2bHM5w+1mlM/a8OpTgMFmQFRcBv1LOpCyWKT3Q62reCh3gtoKzxxr6tf3J7N0fegg3VFeeb7ArRWJvgy1jm44i/z7lVG7WCrYjWBowtTP9k7pRgqUx2gXI56DBOBz2oaBZm8VZXpnXb27Ns66e02M79pCJNNHgt0pZ2sqUXPjDMn34jG766nUmgphZGWcqMKAJEHlmuPhkPEaRCVSrqWaqRpimjDgwjQAwwG19b27F1ANo+kchf7XkIISld+4GNisvPLa61WxF+VvgHJhgi5Xg57DxsM1TWEIgZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xUxC/EzITt3a0WgMgWfYUK8XS0r83FbjMjiYxSZk+jg=;
 b=nY1/rY+c7bQwb5MpETGsYV1vpMcfm1II+RnaTFN9JDGHPdVy+CWYzoYUMh7jkZmSJ0/WHTAmdcDAFQcOWPHtWwAtzeYuas0BNZIJAdGAterCBBI4hPDhb8koKBYOX1c5iljD37kfCJET9ajJkZ2T5Vrw26o4DXL4kKwu3I7Q7mK/gRxbNDvv7Tb9mTYwUkam3cu2OivfSVKsLs2XCn53rf1CYwpA74UsRuB/twmEvLQrIkuy9/uTZgqLNITXJ52uTyvJqk5yzB8u17naj3P1iBsedrw+ukIzlJRw827pJ/qUWOWvc4PjO/koiRtLQC73QCcCrDX8SmlXJUfUdeGkHA==
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=xUxC/EzITt3a0WgMgWfYUK8XS0r83FbjMjiYxSZk+jg=;
 b=K2g415sg3Lqr9vnOuvH6oqMLLC/5mWKfFb6IhTbyhSrpfLEeDOwk2IAGg9+jGBq1ZwocivAEptlQThpwY0Zx/tf0JQw4s6hdj1r88orAU2ys+p85Bzn58AOUo6x/DbaYHF4bpKRN9T+9YA27HXxldk0pv1nzKERzrRyGu/nlWUm2eBw66IFk7emqTdu9JZdly5QXqnJjaV5IDwL2kdcmeQyNFNi1M/zH9H990Qc6dSOUFKbi1gteXunGvpy146u6kNQAf3kUnOXBF/TuiOhgzZ1TeAjCMsY8U21gL1m6VgyxKztZJapd+F02UHKEOay1eBhGpeO3FkdSy0cYNsKU7w==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	, Volodymyr Babchuk
	, Julien Grall 
Subject: [PATCH v7 03/12] xen/arm: vgic: implement helper functions for virq
 checks
Thread-Topic: [PATCH v7 03/12] xen/arm: vgic: implement helper functions for
 virq checks
Thread-Index: AQHcHdat8GUnc6NjkU6Jp8NxZ7QMlw==
Date: Thu, 4 Sep 2025 20:01:19 +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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 81ab3b00-d4c2-438a-438e-08ddebedd069
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:
 =?iso-8859-1?Q?F9xKCfWVFZqC1Spqr4Vp5p6iIT6mczWjO/u2IVEuwPSSOcdDTPyXCB8kGc?=
 =?iso-8859-1?Q?Ic8P8oT1jYFTPsrIx3dMLQc7QduZGWBFr2ilvvWobfsHUksnzs3XN1FM3K?=
 =?iso-8859-1?Q?/n/Ji4hemNMr/x9xBbYAl/l6xe2t2Rp2PWeOh7t42aUb/9HuXSOTx3+/qE?=
 =?iso-8859-1?Q?AbGZIzFVh+MnquIIHWlauFKr6ly9hYlTeSPXUbcUWhsb+UqxBbIclIGiZN?=
 =?iso-8859-1?Q?tD/gS0HipIYcQC4hi6foj0/e6EAEITOU9IQ0hhafiw+u/8U2D8xfRGBemi?=
 =?iso-8859-1?Q?rKNdF5/6cwZp1KTjMltvYM64JAM9b62PoNRbeWFcxklfOdJXrq5cIaIsOc?=
 =?iso-8859-1?Q?HK+6M9cOywKVRD4KXlogiM3Kb3buptUbe2ZnfeU1E7W8//ofjvRleRHd88?=
 =?iso-8859-1?Q?AdelEcued7M+YcbMYZZ1x4VpDW0hnhnzme9e3avpczP1beRgObyPBhbgji?=
 =?iso-8859-1?Q?e2H+9WGxBFaR+BOz8VaJk0wHmA51QbQ0SkSNZugjeOMnCdoWkKUUveqtt1?=
 =?iso-8859-1?Q?VbO7VUNnEpua42KahqE/P+8omX96avm9MubrKWa6Tme2c7iSSlSmtSOqlx?=
 =?iso-8859-1?Q?A2Z4Q/aoWCKpDCP55mvCh6RCeumMtv1MR1w7NHJwy8LLco+YRK8QvCeJpX?=
 =?iso-8859-1?Q?vb905/0c3KuNKBaYgauodBkNVEmaKLXPXryABCqehQhHmYs7IG0babEXcA?=
 =?iso-8859-1?Q?YZI9voWFHwl5nCNBlEpZ0qyMvDx1r8MGpYGxjgkYJ32zvTPEwSJWPcavap?=
 =?iso-8859-1?Q?5TyXNh6ZdnNyRb0zydDYqcg2PDb/o3X9z378ZG9s9lW65pfhWXDLYxM0CG?=
 =?iso-8859-1?Q?z62zTncQ3LdUwDKmwVEY1wt8OES6OpMaPfTOI9XQtGR8gRThUVfh5tUtaE?=
 =?iso-8859-1?Q?gPz5jS/Lg1MqN5MuTLuaU+7WGlRgN2XKlA5/hUXQoX+4i4fmRGvLbDbL0n?=
 =?iso-8859-1?Q?s8zofi/jqqoiRZy+BcN9V0/hsqI7rVUte5NCDZlblqIedx/ep3f9kCj/jn?=
 =?iso-8859-1?Q?754mEzWtmNwnsSeHIvOLJjSqCtyBPHaxJTZ+yoAd3qQLJCkxEvyG1doxeC?=
 =?iso-8859-1?Q?wcQVKSbVhBbp9SjHTWIB9yhbsitaCEN5ud0Od2d29R7ArZas/dZYAghkSL?=
 =?iso-8859-1?Q?6INJl9FJcd7ypVI24udZ32hupsGu+f7Ssh8cj1Iu7Cv+VekQS46UX+9+Fs?=
 =?iso-8859-1?Q?Cj/Ezt+pTsCifv9pjTHgzqUwIhnhbHZx/eS5vEpeLVQRqDpjLPdqkKMhUa?=
 =?iso-8859-1?Q?wsvjHe52CvUAOeMxcArepmH/N4OpuNs0869lj0TeE2cpoFQ5ZnGdH3nexj?=
 =?iso-8859-1?Q?tS7VWd0091ZEEee9i0hTiVfPci6i0iPeo+rzOH/iopPiDRNe9JuEmGtNs5?=
 =?iso-8859-1?Q?us2OC61x+fqLUE38v9Ld67H9fkvnrneDVBXeDHN9LuKtQWX8mmw4BCGjdi?=
 =?iso-8859-1?Q?aw4CJ/9rnLx/k8/GTLPhupHjlWsVcKKmtq93Ixu6W6Ag+p9s60rQOwUiSP?=
 =?iso-8859-1?Q?FVh03Ybf0Lu+E30Iz9P7UIXHo5U0wLeFrNWShmK+8IZg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?/ntgAEkM9syAH9awizfzttxBny+eayHV9XihKzLmdlV8IeSAzpmmYcPyWo?=
 =?iso-8859-1?Q?AvLoS4oOux7yb8jSDF4KWierQwL6uSUPx2EUTwHZ9oo4Nel366OvlI/RGE?=
 =?iso-8859-1?Q?5df15CL1P3pLojoSedhnmb3WTIy58Q0n2KmlbKAJHeBeMPsk9OJVOJpkpi?=
 =?iso-8859-1?Q?ztosHvQUfV3pUow8NAOBI8idh17Y7s/w3bynPOND4cBzx7KIb2JuuNxLXr?=
 =?iso-8859-1?Q?D6v6scD4ZJ8aSqDhHZUnISA2grQ94yhwg99G/znWwBr/p3Fu6PZLLfGQ0o?=
 =?iso-8859-1?Q?ez4zTNATsF6AT2ttCjYBobikWERC26PiixMACbL3DwXbwEZfDj4qcdJa22?=
 =?iso-8859-1?Q?cnerSGhlNvdWdg2Bb0WGdcFw9iSND1twmiHzQlw3ibdQ1KPmZlN1/3hDKs?=
 =?iso-8859-1?Q?XJpVaa/uASR32n3wIgVz5aYk3CBUDRlVr+TAhhn21ibNjPAFQC4nmc4CtL?=
 =?iso-8859-1?Q?JDXEAUDzhWK4zJMSg4WCAJJ8ip9lZ7u/X39uR4jkWk0G6WeYBJLGtOpb9v?=
 =?iso-8859-1?Q?t/4udnj66gEwMrBB96DT+RDZyAAmA1wLUBliHGLC9y4QDGztjOZOkum2JO?=
 =?iso-8859-1?Q?iBOGonofs4JBP2zlCNYb9rxWn2n4JhYb7nHmGAOotTSTB5pLFvDSwwYKHM?=
 =?iso-8859-1?Q?ShCR+xDWejEyFJkcpds8OhR0ThvaNOM7Tll5wqwohmxj37ChfC3GyOJXMH?=
 =?iso-8859-1?Q?rUEZ/wOcgTN1B3gHce2vGG5nULqh7avo3a+fc8CQ2rBPonNkUw5RRC91Om?=
 =?iso-8859-1?Q?TxoRIEXlAM3l7CPckSExV6YKYRjMvF2IUEt+P/CzJvnRDFolN8v87ojsR5?=
 =?iso-8859-1?Q?b1GlWo9WNvHI0PT9NfIzCp7u1Q4qnGES5u/fhFw6zKx42oLnWG+dWlZZhe?=
 =?iso-8859-1?Q?wiF2dkfM6QlMC9OwURGZs16Itpbt69WS4EnvFMrqhvCkp6gwYAHp9NhBYW?=
 =?iso-8859-1?Q?UsrrNtc+fz0vwxi9XfnSdnhs6mKbaCWrFgPVdGvB+E4UVnjgH/EzFpnHfR?=
 =?iso-8859-1?Q?py6X+oOKpjVMYjRHMC7Gnlq8XISpviSh1sWY0D9yylyGRHdaZu2YLay1vy?=
 =?iso-8859-1?Q?8CQhROLQtZNZrkSytfVklZy5dC72IeEN+ZHfAMStunLETIz6ew1cPxUfJR?=
 =?iso-8859-1?Q?h/T8tyzy83ey31b/fDO+aqs6cCTPzjElOTfdfsIpZL0LFLKx7gWwW4SoJV?=
 =?iso-8859-1?Q?yl4JvkyfopM4MpjqO2YUy7HDVNh3CmtMpLADWjYVZwIXdJFFBXwhy1IidG?=
 =?iso-8859-1?Q?xM4aohoY0Kajya6u2rtTMjDfeom8Mb5OQ18HzT5Iy2f8LHE5H6xaI3OPhs?=
 =?iso-8859-1?Q?DDdnctbOn3Jg0iHTtSiALZPTylTjg+j8lX0h4XsgETtmObfNsrGDPwFA1J?=
 =?iso-8859-1?Q?ZrWKboQggDKenlc+lU3x6ej6VufbZr77z6qyQ+xnxNJMA4wOgHHbuhkzqA?=
 =?iso-8859-1?Q?7SBUho8nZdbJW+cJ/OlJ0NZJsEhRF75VUCj8uG3Q8nd8WE8RO8M/5z34t1?=
 =?iso-8859-1?Q?Id6R1onqQbMZsOT2dDgUWDJ0LMTXQLuWPDYSXeEwY9QvBIjWRYuySMdmsV?=
 =?iso-8859-1?Q?2GfD1WJnsJJYEkfn6D5H53MItiKTAk7iO0A4Bg66x1UZx/JtCeZV7dkgHp?=
 =?iso-8859-1?Q?FZGktGi9Ne/pPJu4187OAxGjAQA5kI43i+mQ2e++wXj3WH4POqx7kg+25+?=
 =?iso-8859-1?Q?8Fga2HuU9yBR/IBwklg=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 81ab3b00-d4c2-438a-438e-08ddebedd069
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:19.2787
 (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: JdIXcWRWL1P8sG8bu/fzo1L2pQ3qvmmxzr67hnSkyzkwh4u/uiGkspDlN60+np0aw5u1VGh3vYz4UNGzErsTBo4bL0bL5/0fH7E5bBQnOPs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Introduced two new helper functions for vGIC: vgic_is_valid_line and
vgic_is_spi. The functions are similar to the newly introduced
gic_is_valid_line and gic_is_spi, but they verify whether a vIRQ
is available for a specific domain, while GIC-specific functions
validate INTIDs for the real GIC hardware. For example, the GIC may
support all 992 SPI lines, but the domain may use only some part of them
(e.g., 640), depending on the highest IRQ number defined in the domain
configuration. Therefore, for vGIC-related code and checks, the
appropriate functions should be used. Also, updated the appropriate
checks to use these new helper functions.

The purpose of introducing new helper functions for vGIC is essentially
the same as for GIC: to avoid potential confusion with GIC-related
checks and to consolidate similar code into separate functions, which
can be more easily extended by additional conditions, e.g., when
implementing extended SPI interrupts.

Only the validation change in vgic_inject_irq may affect existing
functionality, as it currently checks whether the vIRQ is less than or
equal to vgic_num_irqs. Since IRQ indexes start from 0 (where 32 is the
first SPI), the check should behave consistently with similar logic in
other places and should check if the vIRQ number is less than
vgic_num_irqs. The remaining changes, which replace open-coded checks
with the use of these new helper functions, do not introduce any
functional changes, as the helper functions follow the current vIRQ
index verification logic.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- added reviewed-by from Oleksandr Tyshchenko and from Volodymyr Babchuk
- added acked-by from Julien Grall

Changes in V4:
- removed redundant parentheses

Changes in V3:
- renamed vgic_is_valid_irq to vgic_is_valid_line and vgic_is_shared_irq
  to vgic_is_spi
- added vgic_is_valid_line implementation for new-vgic, because
  vgic_is_valid_line is called from generic code. It is necessary to fix
  the build for new-vgic.
- updated commit message

Changes in V2:
- introduced this patch
---
 xen/arch/arm/gic.c              |  3 +--
 xen/arch/arm/include/asm/vgic.h |  7 +++++++
 xen/arch/arm/irq.c              |  4 ++--
 xen/arch/arm/vgic.c             | 10 ++++++++--
 xen/arch/arm/vgic/vgic.c        |  5 +++++
 5 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4bb11960ee..9469c9d08c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -134,8 +134,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned i=
nt virq,
=20
     ASSERT(spin_is_locked(&desc->lock));
     /* Caller has already checked that the IRQ is an SPI */
-    ASSERT(virq >=3D 32);
-    ASSERT(virq < vgic_num_irqs(d));
+    ASSERT(vgic_is_spi(d, virq));
     ASSERT(!is_lpi(virq));
=20
     ret =3D vgic_connect_hw_irq(d, NULL, virq, desc, true);
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 35c0c6a8b0..3e7cbbb196 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -335,6 +335,13 @@ extern void vgic_check_inflight_irqs_pending(struct vc=
pu *v,
 /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
 #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
=20
+extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
+
+static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
+{
+    return virq >=3D NR_LOCAL_IRQS && vgic_is_valid_line(d, virq);
+}
+
 /*
  * Allocate a guest VIRQ
  *  - spi =3D=3D 0 =3D> allocate a PPI. It will be the same on every vCPU
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 7dd5a2a453..b8eccfc924 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -442,7 +442,7 @@ int route_irq_to_guest(struct domain *d, unsigned int v=
irq,
     unsigned long flags;
     int retval =3D 0;
=20
-    if ( virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_valid_line(d, virq) )
     {
         printk(XENLOG_G_ERR
                "the vIRQ number %u is too high for domain %u (max =3D %u)\=
n",
@@ -560,7 +560,7 @@ int release_guest_irq(struct domain *d, unsigned int vi=
rq)
     int ret;
=20
     /* Only SPIs are supported */
-    if ( virq < NR_LOCAL_IRQS || virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_spi(d, virq) )
         return -EINVAL;
=20
     desc =3D vgic_get_hw_irq_desc(d, NULL, virq);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index c563ba93af..2bbf4d99aa 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -24,6 +24,12 @@
 #include 
 #include 
=20
+
+bool vgic_is_valid_line(struct domain *d, unsigned int virq)
+{
+    return virq < vgic_num_irqs(d);
+}
+
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)
 {
@@ -582,7 +588,7 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, =
unsigned int virq,
     if ( !v )
     {
         /* The IRQ needs to be an SPI if no vCPU is specified. */
-        ASSERT(virq >=3D 32 && virq <=3D vgic_num_irqs(d));
+        ASSERT(vgic_is_spi(d, virq));
=20
         v =3D vgic_get_target_vcpu(d->vcpu[0], virq);
     };
@@ -659,7 +665,7 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr=
 hsr)
=20
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
-    if ( virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_valid_line(d, virq) )
         return false;
=20
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 6cabd0496d..b2c0e1873a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -718,6 +718,11 @@ bool vgic_reserve_virq(struct domain *d, unsigned int =
virq)
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
 }
=20
+bool vgic_is_valid_line(struct domain *d, unsigned int virq)
+{
+    return virq < vgic_num_irqs(d);
+}
+
 int vgic_allocate_virq(struct domain *d, bool spi)
 {
     int first, end;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110714.1459750 (Exim 4.92)
	(envelope-from )
	id 1uuG93-0005au-B8; Thu, 04 Sep 2025 20:01:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110714.1459750; Thu, 04 Sep 2025 20: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 1uuG93-0005an-8L; Thu, 04 Sep 2025 20:01:21 +0000
Received: by outflank-mailman (input) for mailman id 1110714;
 Thu, 04 Sep 2025 20: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 1uuG91-0005Me-Mm
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:19 +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 ebcd3938-89c9-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:01:18 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:04 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: ebcd3938-89c9-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KUqBKVYNO1+wPqoL7ggsymvGweaqMrAqsZM+9iJDeWCBTx7vxBwt/oeUL3C99W4ydsxg51zX4wZ/W/oHS2UmU4fgSz3eILfTM8aeOyDnSYrXDbOVtAokch1KW4x6AkDfUlsFbM1109+yxKjtogmzslhQr7L/CB/7iWryXr5Us+O59swTb0PO1gmIE444zSp6NPxd3XOsLxfdBsqghVQfPA9IeAy/OMXU1Fq0gAnqsKgwIg+qWtlZARe7JmloJnnPjfhe+ee2P886kAVeLu2HDn0CUhJA4dYuAr1ab5+TJGlBwYMDk4Zd10kZt6Dvgp2kaR+PL1D8Aqa+AQdjMSY5Iw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=D5kUT3eHgwr0S9xZDmX1S6lCOxxbrUCPmHvjlMrO3hY=;
 b=xgIgzhXVFIm3WrpJewoxLH4W+aH5wppTBRWOYWl1vcfBvJym5FkYJ7i+xybAbLg9CpY1RfHxMqvXMQUr13mu9wht/LMlfppNfCyluhj96DtJ06edE++tC92rXwhx1z0n6qHl2+gdBgpANKkGlSLSLzgRozU5NM2ml8pC/L//ljz5SkEFcEmdR/Dkq+CJ0+astIzvumoCaWfBfoUP/pGFs/nCjaBiJR8G+X2ZNPfY2B8R58ivV1u67XLuTu1ThEL4IOZn93IsvS1U4MqssSqnXfVPRbhHJfIwD7q3Vy17XbDNbx4QCnDgXo2Pib1OZzuw/BYVi4pGlXl0BtPtS+RlDg==
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=D5kUT3eHgwr0S9xZDmX1S6lCOxxbrUCPmHvjlMrO3hY=;
 b=lQzirvgHFcA64PhjJPGCvDN9eCAKfeY+tkHLV24gWhZyXrTmLFIke0st/k1W5rjhlVDJwVkl9Fu/dXK+qCCBIIMM1CBhdsDAH/59ucnSZJp4aqN0M/U6P/FMw67tlCKoYtFjRjs/AP90PvymAeS/tXLmU8lOj9P9kLDIctIHPhqPwDlC2ObSVuUk2GLjir7KldKoPLX1Q+NWl2ceSuPVs+8miVd6AwcpT4AwehFIdgMUmseZcyXxj/Ar+nLi6sRyEjsRlaClEvQmVuk5aORDAqWsExS0tOwsf/eF6buNQ/on/T8Wh6XFy/qpG9uC0fGXvAv6QpiVCWs0sVn+I/FcMg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko , Julien Grall
	
Subject: [PATCH v7 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for
 common operations
Thread-Topic: [PATCH v7 01/12] xen/arm: gicv3: refactor obtaining GIC
 addresses for common operations
Thread-Index: AQHcHdal7cagAlXN9kSVHBDXaJuORw==
Date: Thu, 4 Sep 2025 20:01:04 +0000
Message-ID:
 <39bc13a7de6db81d6c5d19ddde7d6400feeca34f.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 140b36de-500c-4c08-b7ec-08ddebedc799
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:
 =?iso-8859-1?Q?WfPNkCDsAab1oza5gJHfJA4FbUWEVfI7pgLIJe1NR+JXRXuCKTkYHPYRhl?=
 =?iso-8859-1?Q?yGlRyJbUZbLuRfSnOMp7rEtCt+W7VPRiA9MIXgxxFwh1DhTkfyh7gakZAd?=
 =?iso-8859-1?Q?yHthrbBkrNtkegB+tmLHS+3LIpIjnaXM6joJLDQ+Z9+ujGFDWtsoGX4VWs?=
 =?iso-8859-1?Q?2CsVjmSrhImoQgeVwt2m0BuzLkRmq52t+05xHUqqjyfShcqfsP9aOWoKh8?=
 =?iso-8859-1?Q?MvFKhRUVsJjXeqp1bXo5hkksS29d+JHkRbiohJFMZ46qm4LW8jFqpD4Efy?=
 =?iso-8859-1?Q?+eEqF4Pl4hE6GAb55cSWvqTS1fcZarwrSjOB3Vo5s+0QzUR2jBHzct8aP5?=
 =?iso-8859-1?Q?ySFjEcDmNGWDn2QzAVeGTixMrKvwjrotUEPfQg3YeSLu94683xve3VI36N?=
 =?iso-8859-1?Q?zqni6efaRQLleTg4eOmHeovE36Iy+Rv2+NE2miaucVStSK1rSNZIZcc4wi?=
 =?iso-8859-1?Q?SJtHcYQmQer7SuA5rYqDzkdmQPQr6XO8k3XSjA93x9gK6909Fk4jB0dX7v?=
 =?iso-8859-1?Q?PgNEvwT0rv7QvIJshF8tglXNWoAJjoe328SsXQmXC09dmmuQsTW7L28v9j?=
 =?iso-8859-1?Q?vVpc6hswm2HxANxkQDiEsnnhTuKzQj+6WfUN2pxpGa16u+bFViOMwQwBpV?=
 =?iso-8859-1?Q?KW/P/w3TtW4beiZ4BX/voxpbynrZ6dkbFlPy7C6TJiMDxxbWSrrmYT5gwi?=
 =?iso-8859-1?Q?G3x3SfsVif0Az+EfjohzS8WG9J5nXpoY0o5PCzoy1aUn+TJm3/0nv/O7Lc?=
 =?iso-8859-1?Q?UwLaT2hBogEDWcryyIkmJRZ4BOPl5MsdzKW6ja+QiHA/+DoWKYwyvH31kM?=
 =?iso-8859-1?Q?NI4PcVNUy2/TtJWI0Kv3yNS2fzoP5tjP3q/7wEzC070bPVotSfiN4ExVsZ?=
 =?iso-8859-1?Q?oqTXEUpNwO1TvdaaiwpOmq1ku5W2pIVuxHBN0j/8dnFzU3r2yih/HjFsOJ?=
 =?iso-8859-1?Q?oy1KguBf0VHgX9urAIonIi/xa3k2n6mElW+gxBzLk89xlJCi6s33Lo/njS?=
 =?iso-8859-1?Q?WKwSGUFfL43vnTI1dhqTvpcKpj4VYR8aBJib9fVHuBKdO4TsEYSycol6YV?=
 =?iso-8859-1?Q?u8sie1EHdOlCOkpKihfqhBIIVPdI9aBG6sbQMpocRqkfqPmJaROlz6aR8R?=
 =?iso-8859-1?Q?Yo/DkmojnNzhI6oprur5MdxoCQ6aSbhcSdFgDfvMLZRpYQQa6wbjX2A/QP?=
 =?iso-8859-1?Q?KonuC4SMN6f+Ls+8NdVoMvf2AkN2X53Mlrcxty6pg4Lp3MmW5+UuSkcB+i?=
 =?iso-8859-1?Q?CzGD/QksFJsyh58End1Wb9On8FGUcAiSbNTiRCJ3N0uo0YLvROANWnZWU3?=
 =?iso-8859-1?Q?jwriE5/410Snvk2y8wa+YVvxLpYIbVV2vYHHZ8kWsTZ0H5HJllwCZuiwUT?=
 =?iso-8859-1?Q?Lv32O2clxxeUnTr2NyZvyLXJQ0WuzXLOHF8g8VMdO+OMy9HjGDG1KoAXMe?=
 =?iso-8859-1?Q?E/k2m5zr8SUorddTgEgn235bSxcT6rGr0nP6gnlOhfLW8GQFLfHrvTvQop?=
 =?iso-8859-1?Q?vH21cEaBu+qavCV4D4eBxb17hk1VsLFohxdAdWpD7Qvg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?w1imJr0Tpl107yBwjkjmI+Dix3hkTyQXIiSwOG7CE7x9L1FH0ASKuo45WJ?=
 =?iso-8859-1?Q?lKkp+QLlSJGddPlGrZNWAMpHdTNmBFmZyrTUu5Nc83P95mS/3ts2YzHVPm?=
 =?iso-8859-1?Q?A6t427K0wVpBZAIiOMJgxheoe5j+K6U/MUcBtUrMSIVJxn1B7J/cNevv98?=
 =?iso-8859-1?Q?kUcbND5WQKhQQHZm+RbuloxozMAkX702jMD7Rll3lAy8I7dP4Kx3vaFaRU?=
 =?iso-8859-1?Q?N7tf/lvw8rg+e1tNG4mrb8N2QrRj+wL21/WJjitfHOdLz9g29fmFQbSskA?=
 =?iso-8859-1?Q?Qde/F+qCUcPdSFnDs9KTs99d068ga/7HxLoBr6uSPJapnnNs1s7P7IYx1a?=
 =?iso-8859-1?Q?krx00cWrh91obOu0GbXIM/ezkKR3muFbI15GgioSS55wpZpTUIPfxj/Yqr?=
 =?iso-8859-1?Q?pQrnnhtocyqJF9K/NC7obdnouStLtrWwyTsiBX/eg1TiVaVGNZDBC5jFF1?=
 =?iso-8859-1?Q?X8DDJTn8UCMF8q2x9vsOltTFjk3Bb2yPlnQy7AHYqQC3yKHYKa96xO+XEe?=
 =?iso-8859-1?Q?uphmTAlryQo9ZDnryKsh0939rw6oi+lB1yui1VnAf4vpJBRso5eDy0F3pw?=
 =?iso-8859-1?Q?6RXij0Ychr3VA/zY0pxODIoGbZwYk5C4hsun4OUaK9jY51sY+P/7FoKJLz?=
 =?iso-8859-1?Q?bEbxVkovSeCpMniJCIjr3S85iNjCqCWU/Y1G0x8DVyRI9hwAxF6EcU5DWw?=
 =?iso-8859-1?Q?eRlgimsRJYn8YqeO5xFz+Qm6yfC50Ab7a6saVHKY0+HTafzKvAwcvUvAZg?=
 =?iso-8859-1?Q?fTL8wmz86FQ1PV4yqdRNN9ytczujgBnYVz5Vsdv4KMPP5gxbkRBWYcBt3+?=
 =?iso-8859-1?Q?WCeKbxIfgiTOmtFuNylNHQ0u943oC/meXs/avdv7/v2/1ijp6Piswue74B?=
 =?iso-8859-1?Q?B59LYlM8o9JULK2viNYiEhMUP9zTlGBKrF7a2pwFpvmESTHYNm3Q/NmDMT?=
 =?iso-8859-1?Q?qTthvo0eqwvM83d3jCI7bSOqqZSbSJ8rBn/ITOJHSXYJ2kTu8GQ4zZvQ22?=
 =?iso-8859-1?Q?8lvbvu6yN/oBDX8Nl7y+cWAuK5ruvgFTA6nqdnk8pz0k2+TFXjhUChcCtL?=
 =?iso-8859-1?Q?xVrQQA8sQg6eRUfuyS8xc9fGPn13MlwbkjThLT0H6sXdcmVOULHIhdw5uH?=
 =?iso-8859-1?Q?VLcqQE9Gc+vDEMupGgBXsw3P79t6Fg6sXUbbE3HHW36XQlh6gGjkd3SdTa?=
 =?iso-8859-1?Q?O2IsnCvfMiCZ2/eKk+W684yKdtU+r1+wrFIrNyiz1dA4lBV9a0LZMfe/v0?=
 =?iso-8859-1?Q?421tkRt3gM4bb92XALGiSW/vT0XbJqVPg92z1yqVi59hrVjGOZOU/qvTty?=
 =?iso-8859-1?Q?cRSQ98hh9wIxCQzuuD8dITuhibFGG+mAIZjCou2riFKERqzaE5VP77p4I5?=
 =?iso-8859-1?Q?RkSXQ0+BhSV+ySoLEA/wEgNln1zRzipm1HItYofyImEebUV59c9bi79STe?=
 =?iso-8859-1?Q?EW5gVq25v93+gqhbysjU6W631WQVu+xDEN8LIzoYSv6anM4qGedPApXu0l?=
 =?iso-8859-1?Q?UOkdkZRMRjMThTV2cCn3Xm8FaTk7ENc6m0kML9Fy8qVZciy7urAhGxR+IV?=
 =?iso-8859-1?Q?lWgm+vI9b3h2X/zXmb9onzh/Nq28ydLnCmZJwqRqyLKlKtxIBPYAKawKqD?=
 =?iso-8859-1?Q?K3ml4YMHdherWbnTTPLqRfe8mpHQHVViWbqP2iFv8vpB0VxVX9vEy3RrQQ?=
 =?iso-8859-1?Q?BQsWRetOdPYPtBN70Ww=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 140b36de-500c-4c08-b7ec-08ddebedc799
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:04.4507
 (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: +VdXNKgU1BwL0eu9TK3hXv9jY+7VkGq0UH0ToQtr6UtTM7P2qbev/CWomhm3QNIvIWAZbtA4it4NbVtP3I0P47PeJxOtghXHKxvO3FvTKOk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Currently, many common functions perform the same operations to calculate
GIC register addresses. This patch consolidates the similar code into
a separate helper function to improve maintainability and reduce duplicatio=
n.
This refactoring also simplifies the implementation of eSPI support in futu=
re
changes.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 

---
Changes in V7:
- no changes

Changes in V6:
- no functional changes, just fixing minor nit: changed u32 to uint32_t
  in get_addr_by_offset()
- added reviewed-by from Oleksandr Tyshchenko

Changes in V5:
- fixed a minor nit: changed %d to %u in the warning message because the
  IRQ number cannot be less than zero
- added acked-by from Julien Grall

Changes in V4:
- no changes

Changes in V3:
- changed panic() in get_addr_by_offset() to printing warning and
  ASSERT_UNREACHABLE()
- added verification of return pointer from get_addr_by_offset() in the
  callers
- moved invocation of get_addr_by_offset() from spinlock guards, since
  it is not necessarry
- added RB from Volodymyr Babchuk

Changes in V2:
- no changes
---
 xen/arch/arm/gic-v3.c          | 114 +++++++++++++++++++++++----------
 xen/arch/arm/include/asm/irq.h |   1 +
 2 files changed, 81 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index cd3e1acf79..a1e302fea2 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -445,17 +445,67 @@ static void gicv3_dump_state(const struct vcpu *v)
     }
 }
=20
+static void __iomem *get_addr_by_offset(struct irq_desc *irqd, uint32_t of=
fset)
+{
+    switch ( irqd->irq )
+    {
+    case 0 ... (NR_GIC_LOCAL_IRQS - 1):
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+        case GICD_ICENABLER:
+        case GICD_ISPENDR:
+        case GICD_ICPENDR:
+        case GICD_ISACTIVER:
+        case GICD_ICACTIVER:
+            return (GICD_RDIST_SGI_BASE + offset);
+        case GICD_ICFGR:
+            return (GICD_RDIST_SGI_BASE + GICR_ICFGR1);
+        case GICD_IPRIORITYR:
+            return (GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + irqd->irq);
+        default:
+            break;
+        }
+    case NR_GIC_LOCAL_IRQS ... SPI_MAX_INTID:
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+        case GICD_ICENABLER:
+        case GICD_ISPENDR:
+        case GICD_ICPENDR:
+        case GICD_ISACTIVER:
+        case GICD_ICACTIVER:
+            return (GICD + offset + (irqd->irq / 32) * 4);
+        case GICD_ICFGR:
+            return (GICD + GICD_ICFGR + (irqd->irq / 16) * 4);
+        case GICD_IROUTER:
+            return (GICD + GICD_IROUTER + irqd->irq * 8);
+        case GICD_IPRIORITYR:
+            return (GICD + GICD_IPRIORITYR + irqd->irq);
+        default:
+            break;
+        }
+    default:
+        break;
+    }
+
+    /* Something went wrong, we shouldn't be able to reach here */
+    printk(XENLOG_WARNING "GICv3: WARNING: Invalid offset 0x%x for IRQ#%u"=
,
+           offset, irqd->irq);
+    ASSERT_UNREACHABLE();
+
+    return NULL;
+}
+
 static void gicv3_poke_irq(struct irq_desc *irqd, u32 offset, bool wait_fo=
r_rwp)
 {
     u32 mask =3D 1U << (irqd->irq % 32);
-    void __iomem *base;
+    void __iomem *addr =3D get_addr_by_offset(irqd, offset);
=20
-    if ( irqd->irq < NR_GIC_LOCAL_IRQS )
-        base =3D GICD_RDIST_SGI_BASE;
-    else
-        base =3D GICD;
+    if ( addr =3D=3D NULL )
+        return;
=20
-    writel_relaxed(mask, base + offset + (irqd->irq / 32) * 4);
+    writel_relaxed(mask, addr);
=20
     if ( wait_for_rwp )
         gicv3_wait_for_rwp(irqd->irq);
@@ -463,15 +513,12 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32=
 offset, bool wait_for_rwp)
=20
 static bool gicv3_peek_irq(struct irq_desc *irqd, u32 offset)
 {
-    void __iomem *base;
-    unsigned int irq =3D irqd->irq;
+    void __iomem *addr =3D get_addr_by_offset(irqd, offset);
=20
-    if ( irq >=3D NR_GIC_LOCAL_IRQS)
-        base =3D GICD + (irq / 32) * 4;
-    else
-        base =3D GICD_RDIST_SGI_BASE;
+    if ( addr =3D=3D NULL )
+        return false;
=20
-    return !!(readl(base + offset) & (1U << (irq % 32)));
+    return !!(readl(addr) & (1U << (irqd->irq % 32)));
 }
=20
 static void gicv3_unmask_irq(struct irq_desc *irqd)
@@ -558,30 +605,28 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cp=
u)
 static void gicv3_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
     uint32_t cfg, actual, edgebit;
-    void __iomem *base;
-    unsigned int irq =3D desc->irq;
+    void __iomem *addr;
=20
     /* SGI's are always edge-triggered not need to call GICD_ICFGR0 */
-    ASSERT(irq >=3D NR_GIC_SGI);
+    ASSERT(desc->irq >=3D NR_GIC_SGI);
=20
-    spin_lock(&gicv3.lock);
+    addr =3D get_addr_by_offset(desc, GICD_ICFGR);
+    if ( addr =3D=3D NULL )
+        return;
=20
-    if ( irq >=3D NR_GIC_LOCAL_IRQS)
-        base =3D GICD + GICD_ICFGR + (irq / 16) * 4;
-    else
-        base =3D GICD_RDIST_SGI_BASE + GICR_ICFGR1;
+    spin_lock(&gicv3.lock);
=20
-    cfg =3D readl_relaxed(base);
+    cfg =3D readl_relaxed(addr);
=20
-    edgebit =3D 2u << (2 * (irq % 16));
+    edgebit =3D 2u << (2 * (desc->irq % 16));
     if ( type & IRQ_TYPE_LEVEL_MASK )
         cfg &=3D ~edgebit;
     else if ( type & IRQ_TYPE_EDGE_BOTH )
         cfg |=3D edgebit;
=20
-    writel_relaxed(cfg, base);
+    writel_relaxed(cfg, addr);
=20
-    actual =3D readl_relaxed(base);
+    actual =3D readl_relaxed(addr);
     if ( ( cfg & edgebit ) ^ ( actual & edgebit ) )
     {
         printk(XENLOG_WARNING "GICv3: WARNING: "
@@ -600,16 +645,13 @@ static void gicv3_set_irq_type(struct irq_desc *desc,=
 unsigned int type)
 static void gicv3_set_irq_priority(struct irq_desc *desc,
                                    unsigned int priority)
 {
-    unsigned int irq =3D desc->irq;
+    void __iomem *addr =3D get_addr_by_offset(desc, GICD_IPRIORITYR);
=20
-    spin_lock(&gicv3.lock);
-
-    /* Set priority */
-    if ( irq < NR_GIC_LOCAL_IRQS )
-        writeb_relaxed(priority, GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + =
irq);
-    else
-        writeb_relaxed(priority, GICD + GICD_IPRIORITYR + irq);
+    if ( addr =3D=3D NULL )
+        return;
=20
+    spin_lock(&gicv3.lock);
+    writeb_relaxed(priority, addr);
     spin_unlock(&gicv3.lock);
 }
=20
@@ -1273,6 +1315,10 @@ static void gicv3_irq_set_affinity(struct irq_desc *=
desc, const cpumask_t *mask)
 {
     unsigned int cpu;
     uint64_t affinity;
+    void __iomem *addr =3D get_addr_by_offset(desc, GICD_IROUTER);
+
+    if ( addr =3D=3D NULL )
+        return;
=20
     ASSERT(!cpumask_empty(mask));
=20
@@ -1284,7 +1330,7 @@ static void gicv3_irq_set_affinity(struct irq_desc *d=
esc, const cpumask_t *mask)
     affinity &=3D ~GICD_IROUTER_SPI_MODE_ANY;
=20
     if ( desc->irq >=3D NR_GIC_LOCAL_IRQS )
-        writeq_relaxed_non_atomic(affinity, (GICD + GICD_IROUTER + desc->i=
rq * 8));
+        writeq_relaxed_non_atomic(affinity, addr);
=20
     spin_unlock(&gicv3.lock);
 }
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index fce7e42a33..5bc6475eb4 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -29,6 +29,7 @@ struct arch_irq_desc {
  */
 #define NR_IRQS		1024
=20
+#define SPI_MAX_INTID   1019
 #define LPI_OFFSET      8192
=20
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case.=
 */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110717.1459781 (Exim 4.92)
	(envelope-from )
	id 1uuG9D-0006Qp-Dh; Thu, 04 Sep 2025 20:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110717.1459781; Thu, 04 Sep 2025 20: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 1uuG9D-0006Qd-7A; Thu, 04 Sep 2025 20:01:31 +0000
Received: by outflank-mailman (input) for mailman id 1110717;
 Thu, 04 Sep 2025 20:01: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 1uuG9B-00062f-LT
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:29 +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 f111a0ee-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:27 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:25 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: f111a0ee-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=clJdcSJ78Lp5yHwmVwSVH4wZioPwVUP1QuqtXwXUO1WssRnojFSTI092JHh/m9Akvwo052enSbiT2UYFEIT8OsouzS3ufQbJnIT/KSqaaPRc8U/Rq8+wXeXGwT+aIZ9dhUHsnO+EGy/Dhia0d94z+9x70ys5l5fWEmHojGnxi9iaEA+H0YpF5R0JH7qQlWbz63dbM5q3ldGzEcgrwAEDbRIJWznuGVLeHGUVklBTkYwDck2vgqFuWwSkaldHmj6MqSQPddV6cMEdy5xjaIznWnym0rNq3xdy5kKAg+nk7xOujcXGY8djS6YU0ow2fhb5+NS01mjO4PuqI/rXZ6GTxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Cktca4KjjAxZKyZjKCeMpl9aQ7UrtWBk5FkrJKPR44c=;
 b=eTK4rSdFlkoCwWv1Zo/O3GQO83jBXewn3APhtrvDyqAuOUaNK69BrDLf3JGZslFiW5M29QED3zMwKCMzW2gBb05OVw5sgjp3sKvK2J7qUd/W7FqmxemciUXkoeNnWdwc/ZkP037w4zbwyhto7GQsI71rwFdrfFF3v1MrPL8wS/9Bg4rsfwjAHQPyQSai7hUTEIC3hliFYbBLCsnpQGznOjbVKEZD84PGaAOOGaR6K3sIHhxFDKq4jyidCnIIhWS2bGRQw+70xKjtrhkvbt+FujKt77PJLjEv/GAMBflaI/cUg1VWWrP2fnenZ14R5FHzVYb59CbmkuV8syhryNnNMg==
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=Cktca4KjjAxZKyZjKCeMpl9aQ7UrtWBk5FkrJKPR44c=;
 b=MHsYt5gcVklhH+bkFJd40frjB9RYsHTVvqKcHWQ5QV/uEhut5c9bofL8RZuzQfNYmGpo94aO3C20FONBrFAxkFhqVEf9i+X2cXN2+ucyOKo5h9iPpQ0GfmlVlyMrN9XWrfwk1NYtA7J6yOSB4tMmviN9kg2Hwo+BFWZ7sKUwpXxwt9ikVfK74Ci4oP93xQH8xk+PViaKYRFLr6AE808bX/S/5iTpjZ9ChUb1RjnrAUMIAgzMzOFyLuzWPuYEuZ0jBOYogtPs63NYwProQOByo0315cquw2JWb7zSBUAyu18gnHD2kwC3LUv7UC0DG3odVNteC/jjr8KDG+/8p+VsTA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI range
Thread-Topic: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHdaxzH0gJHOWB0uscg50WGUPxw==
Date: Thu, 4 Sep 2025 20:01:24 +0000
Message-ID:
 <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 20e0b82c-f9d6-4d85-1c4c-08ddebedd3ba
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:
 =?iso-8859-1?Q?dBcKyfobxezHkUXex8VUvSa9+SzOFxB9vXMDKMlknrA59H6EYGTyQ07jnJ?=
 =?iso-8859-1?Q?zXkqxwF4lBU0eltjwX3IZ6yIFrM0yLQUvFQgfATzoh+HoPbFvvuV0W0egP?=
 =?iso-8859-1?Q?uBZEl7aKn4UguhgvRTfGmrRS5NuWyVIw0dPgiTgal78X5QLYoDFcuF3j/F?=
 =?iso-8859-1?Q?CyLhGs6+lgEQCwdmWCZt0k+FguVwLMQj9WJAtSRRHiOIzK/u7EclyfSGDA?=
 =?iso-8859-1?Q?Pv9kEhvPUoZGN8aciqPtq3xZNzdtQtM4YHM+DX18sEBCSWXQ37zfagzr0V?=
 =?iso-8859-1?Q?ojlIBTAK6n+xR/GvXTjNwWw0yI8UzIT+VWm5V7TK6v6zpS7Kn9Rx//GspR?=
 =?iso-8859-1?Q?2u1dH6TIutn2fsKk5a95hrKurZdKQ42/AEvaiez+QMUYCDyNY76SedaGF0?=
 =?iso-8859-1?Q?hbLdzJqisA5w7m9Ua51/ycAUiupPr3A5IVzlBO+GalSMfJx6Jgi79UItNY?=
 =?iso-8859-1?Q?+CuXF1Ec1VQsFJ6wa4sX5JsDCNocEkB41t5I2wSLtkcyvs5wp8dpZjC4x9?=
 =?iso-8859-1?Q?EOTlYgI0HdkjbnqZPvWBoOR5KNVYUNOSTmO8Xdq3IpPK6k8C5VgCLXkrdh?=
 =?iso-8859-1?Q?PISR9Xj1OCcF9p5Q02YrAVbJ/QZpO1uQ9S+s6UCrptUsTbAvKu/KXBSdcZ?=
 =?iso-8859-1?Q?xWpE5zQeornvowqiWemQ7Nl99Ci1Q5/3MZ2ApQXQOG4uXkeo9Om/HyvvR0?=
 =?iso-8859-1?Q?wn5Knhro5AV6v8HnirCP16SnNGo5pOXUiIyVGJlltKiDIMYsFc8awNLPar?=
 =?iso-8859-1?Q?ljexKsuUHuTi9nTj6ZfPArJGtfoM+jPI0CcSXeJgSZ7l0G0Q9fZua4c26t?=
 =?iso-8859-1?Q?0ytQo0rJG+2ZrfDkkf48DF5wBN3HCj5V/LmjkLzyMvmZHPt+/xC0s1Xp+K?=
 =?iso-8859-1?Q?Tz5fSuVnmK6UeKvr9Uzu2vPNLCNKyhBEjYvGZgJRSUSaZOImp7gNM9Tinv?=
 =?iso-8859-1?Q?aqXrb4lQu20P1KpBHtanWuLBoXli55x0rzLoFfzZD3zBFF4M5sCclHee+s?=
 =?iso-8859-1?Q?V5EtaoR6fGVY+1zOn4XXjuEmXgEueXK2AhIbvDiqGb8/LVP1VMefufThZB?=
 =?iso-8859-1?Q?sxvUEvo4abiDL8HKjFI2TQH40H5NX4RujU6D765ViB2DP9mCOj8kUcBqZR?=
 =?iso-8859-1?Q?haU8w6sgkVSfiqMMvgRPC8fmFAsyLL/mdJszlanoZYpwiFeweih3JGCXF/?=
 =?iso-8859-1?Q?aFvJCMXNCQyotN8XgCSY24zvVN9Uyu2HsDVkavyNZJjUq8NzVSIOXAUKE7?=
 =?iso-8859-1?Q?mqx2NY4qm8sdqQ2x3nL2iTAWYMjcYlI7l2YkurwjhHcNz0Tt5MKyyb7YF3?=
 =?iso-8859-1?Q?9obL1UjgGFhOVix3dcwVcBjzhae9v1Y50aJvqpSmfEU8VP7wlxa84renLq?=
 =?iso-8859-1?Q?ICBPrhk5G6YylOmhD0bbCSgQ2tnFZKDRshy6/j0355oW2sF+FTFbrsTIte?=
 =?iso-8859-1?Q?6mClIDhrajlOX/oBNUtmeQb4TiSFF0EujMk+oTEpk54xxy+U+qyzfC2ZpN?=
 =?iso-8859-1?Q?yg/h9I5ZCK62XBRtOfNl16INvowQ6o9sIY2ShIIN1b2A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?+twAIjFEhInHuvD+kwuO+3wtf3FKVWFNwW0GBW0hlCQ2VDF0lw9v5nyXYx?=
 =?iso-8859-1?Q?NC0m9VMH5t/cSLg1YiVrBPPqoeFWb4CsAxmNHgeN6CJWjGxb2mBGK8SqLn?=
 =?iso-8859-1?Q?UbWhuhv0ihgWu/N+J+hF4bKUBQ9/02gQfEBQxa/+nRR3TI9r77M3VuCo1+?=
 =?iso-8859-1?Q?2jKfaRPTdq1HEFLDZJTr5gwulLWX5wz3ZfeA76z0N3vvQXU6coayfbUVWI?=
 =?iso-8859-1?Q?7vuboUTyFinUaT/8OkWnpRquPtMlopNAbpbp4y0Y6Zt2ha+shxxiORueZt?=
 =?iso-8859-1?Q?nD5aS3XmbprsMAS2vqCMVNa10T037yfO2Mrjgf7Q4pUyliw8/YXc6Rp2/K?=
 =?iso-8859-1?Q?4hs7Hsewk8oVVuG+WTxJMkDLhD85xsaNGFnbN/+8DgbLHpE/ryw0xapFmc?=
 =?iso-8859-1?Q?zRyZ+7tpbDdMeYW8qXqkxzERAZmFk3TmwSmYZJI1wC+ngHmb1FuANYNZbm?=
 =?iso-8859-1?Q?ExoZDDdZDTl2kxtv7sVigknJFoTSvk41KDIqjTVH09bflLoEyZN9UbITqE?=
 =?iso-8859-1?Q?XHDybAOFqjhpo26WehZfyE0Rt0ToBWQQ0nZVQ3qXWsAtYZsdrpNs9ZodXL?=
 =?iso-8859-1?Q?WZMcKQt8ktO1K9pdzqSIX7mR496CxzMGlGETBcFrob5Cl7KQxkbMlwitmT?=
 =?iso-8859-1?Q?omLewI3wEUcIT7eKebfE/KB1fF3I1jKdI9PtS1MrqlM42xjdOf89SZsgcj?=
 =?iso-8859-1?Q?/dh8COT7llrTnwgsm7um8HNYa5wVL5oBZ792gkQgniYVLlyYod7/ZBxRW7?=
 =?iso-8859-1?Q?SmDQRMD8kVXtxc33SzWXZDU+CPS8NkfXQ6cB+R/XQrG+jxfl7QFqHegmRt?=
 =?iso-8859-1?Q?b93yqRpM6kVfoaqp1QLoqLE0sPo/XkAbyNE105ZGmp9J/Y2Lpirva8vLR7?=
 =?iso-8859-1?Q?Imsqqnzqp8LHfNPgsbPUhC91WUCsoKhGEWhdsbTJpfL7yQW7nrOHB5n+ZM?=
 =?iso-8859-1?Q?f9RX8In+gMva7QFmnwMwYsDtx1bTXG05PzFcEKJ9rWacdowa6vhX8aYpof?=
 =?iso-8859-1?Q?aSkh+hburBjoGbRegg9EcmA+dbMjnDGkFbJRIuYcqdavFUcB+9uN+c5f94?=
 =?iso-8859-1?Q?C1UPTXeTiOy6GSa7Dzu1YPCj3+glaDgKTKOYelSKYofaNdr7n3VJojDiaa?=
 =?iso-8859-1?Q?iC0n40a3BoSsKe7LTJZbx4aL3Abt+Sop74+rfIAFc2BjUm6iSdPDvusQmN?=
 =?iso-8859-1?Q?WtVtmyyB51omIjexSN6U0r54j8LfWr1S6aQlojrV7ObBlsjLXmZUUKHBUj?=
 =?iso-8859-1?Q?hUxZ4SE1r5Z0SL88w1UV1IO2QsJppkRcA68G/P2p0psEdKAmo72igYw1JJ?=
 =?iso-8859-1?Q?Mu68TOYTSVE0Nr4wD1El/KYB7WSgo0lxaQLLWz2kNeUjxKIYMa+QUn1k6r?=
 =?iso-8859-1?Q?DD+hBMZxozxg431TgVkU4Q07zEG4jk06vVt+6XSv+SxzQumYbdKcj4syzF?=
 =?iso-8859-1?Q?AgP6i9IB9YiP28JorDF9Rb5ApFbFb+1u8yxl7zrgW/go6YHwfSw0PfmBXu?=
 =?iso-8859-1?Q?A99Qz9OZBUGPdOz/jjHnfATOVqYAKqoJDSKcmq71Lh28iFQQ1X//421Lv0?=
 =?iso-8859-1?Q?D8B1T4LStywTM6S/g1F7KEHAulAUILEV7+cN35kj2ZbRKG7HeaYZ/uiVeW?=
 =?iso-8859-1?Q?NxkJ/VjeOeBwgdmVWUlsuB1okrDSlVX71KOSc2zLWAhIi29KtMAnSx1rxC?=
 =?iso-8859-1?Q?VEwkkN0s1jhzOMktSBs=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20e0b82c-f9d6-4d85-1c4c-08ddebedd3ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:24.8232
 (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: dUKBNayhDMWoiywyjlyhWvE1efz2xhOjTwsvu7ofF7kucWNxtPMVbfnIHf2MAWVZW+Z54/Y2UbvBEmSvcDeMP5iaNdiduCxIToNi+AK51E4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Currently, Xen does not support eSPI interrupts, leading
to a data abort when such interrupts are defined in the DTS.

This patch introduces a separate array to initialize up to
1024 interrupt descriptors in the eSPI range and adds the
necessary defines and helper function. These changes lay the
groundwork for future implementation of full eSPI interrupt
support. As this GICv3.1 feature is not required by all vendors,
all changes are guarded by ifdefs, depending on the corresponding
Kconfig option.

Signed-off-by: Leonid Komarianskyi 

---
Changes in V7:
- fixed the condition in the is_espi assert for non-eSPI builds: the
  previous condition was mistakenly added with a wrong check and led to
  triggering asserts for all non-eSPI INTIDs, when it should be triggered
  in this case in the other way around
- minor: used is_espi() in the espi_intid_to_idx() ASSERT, as is_espi
  performs the same verification

Changes in V6:
- added an assert in is_espi() when CONFIG_GICV3_ESPI=3Dn to ensure that
  out-of-range array resources are not accessed, e.g., in __irq_to_desc()
- removed unnecessary parentheses in is_espi()
- converted helper macro to inline functions and added sanity checks
  with ASSERTs to them
- defined espi_to_desc for non-eSPI builds as a prototype
- updates the comments
- used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs

Changes in V5:
- no functional changes introduced by this version compared with V4, only
  minor fixes and removal of ifdefs for macroses
- added TODO comment, suggested by Oleksandr Tyshchenko
- changed int to unsigned int for irqs
- removed ifdefs for eSPI-specific defines and macros to reduce the
  number of ifdefs and code duplication in further changes
- removed reviewed-by as moving defines from ifdefs requires additional
  confirmation from reviewers

Changes in V4:
- removed redundant line with 'default n' in Kconfig, as it is disabled
  by default, without explicit specification
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
  case of using NR_IRQS for espi_desc array
- implemented helper functions espi_to_desc and init_espi_data to make
  it possible to add stubs with the same name, and as a result, reduce
  the number of #ifdefs
- disable CONFIG_GICV3_ESPI default value to n

Changes in V2:
- use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
- remove unnecessary comment for nr_irqs initialization
---
 xen/arch/arm/Kconfig           |  8 +++++
 xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
 xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
 3 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 17df147b25..43b05533b1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -135,6 +135,14 @@ config GICV3
 	  Driver for the ARM Generic Interrupt Controller v3.
 	  If unsure, use the default setting.
=20
+config GICV3_ESPI
+	bool "Extended SPI range support"
+	depends on GICV3 && !NEW_VGIC
+	help
+	  Allow Xen and domains to use interrupt numbers from the extended SPI
+	  range, from 4096 to 5119. This feature is introduced in GICv3.1
+	  architecture.
+
 config HAS_ITS
         bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORT=
ED
         depends on GICV3 && !NEW_VGIC && !ARM_32
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index 5bc6475eb4..2ff2d07d6d 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -32,6 +32,10 @@ struct arch_irq_desc {
 #define SPI_MAX_INTID   1019
 #define LPI_OFFSET      8192
=20
+#define ESPI_BASE_INTID 4096
+#define ESPI_MAX_INTID  5119
+#define NR_ESPI_IRQS    1024
+
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case.=
 */
 #define INVALID_LPI     0
=20
@@ -39,7 +43,12 @@ struct arch_irq_desc {
 #define INVALID_IRQ     1023
=20
 extern const unsigned int nr_irqs;
+#ifdef CONFIG_GICV3_ESPI
+/* This will cover the eSPI range, to allow asignmant of eSPIs to domains.=
 */
+#define nr_static_irqs (ESPI_MAX_INTID + 1)
+#else
 #define nr_static_irqs NR_IRQS
+#endif
=20
 struct irq_desc;
 struct irqaction;
@@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
     return irq >=3D LPI_OFFSET;
 }
=20
+static inline bool is_espi(unsigned int irq)
+{
+#ifdef CONFIG_GICV3_ESPI
+    return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID;
+#else
+    /*
+     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI =
is
+     * disabled. Returning false allows the compiler to optimize the code
+     * when the config is disabled, while the assert ensures that out-of-r=
ange
+     * array resources are not accessed, e.g., in __irq_to_desc().
+     */
+    ASSERT(!(irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID));
+    return false;
+#endif
+}
+
+static inline unsigned int espi_intid_to_idx(unsigned int intid)
+{
+    ASSERT(is_espi(intid));
+    return intid - ESPI_BASE_INTID;
+}
+
+static inline unsigned int espi_idx_to_intid(unsigned int idx)
+{
+    ASSERT(idx <=3D NR_ESPI_IRQS);
+    return idx + ESPI_BASE_INTID;
+}
+
 #define domain_pirq_to_irq(d, pirq) (pirq)
=20
 bool is_assignable_irq(unsigned int irq);
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index b8eccfc924..c934d39bf6 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -19,7 +19,9 @@
 #include 
 #include 
=20
-const unsigned int nr_irqs =3D NR_IRQS;
+const unsigned int nr_irqs =3D IS_ENABLED(CONFIG_GICV3_ESPI) ?
+                                        (ESPI_MAX_INTID + 1) :
+                                        NR_IRQS;
=20
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
@@ -46,6 +48,50 @@ void irq_end_none(struct irq_desc *irq)
 }
=20
 static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
+#ifdef CONFIG_GICV3_ESPI
+/* TODO: Consider allocating an array dynamically */
+static irq_desc_t espi_desc[NR_ESPI_IRQS];
+
+static struct irq_desc *espi_to_desc(unsigned int irq)
+{
+    return &espi_desc[espi_intid_to_idx(irq)];
+}
+
+static int __init init_espi_data(void)
+{
+    unsigned int irq;
+
+    for ( irq =3D ESPI_BASE_INTID; irq <=3D ESPI_MAX_INTID; irq++ )
+    {
+        struct irq_desc *desc =3D irq_to_desc(irq);
+        int rc =3D init_one_irq_desc(desc);
+
+        if ( rc )
+            return rc;
+
+        desc->irq =3D irq;
+        desc->action  =3D NULL;
+    }
+
+    return 0;
+}
+#else
+/*
+ * Defined as a prototype as it should not be called if CONFIG_GICV3_ESPI=
=3Dn.
+ * Without CONFIG_GICV3_ESPI, the additional 1024 IRQ descriptors will not
+ * be defined, and thus, they cannot be used. Unless INTIDs from the eSPI
+ * range are mistakenly defined in Xen DTS when the appropriate config is
+ * disabled, this function will not be reached because is_espi will return
+ * false for non-eSPI INTIDs.
+ */
+struct irq_desc *espi_to_desc(unsigned int irq);
+
+static int __init init_espi_data(void)
+{
+    return 0;
+}
+#endif
+
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
=20
 struct irq_desc *__irq_to_desc(unsigned int irq)
@@ -53,6 +99,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
     if ( irq < NR_LOCAL_IRQS )
         return &this_cpu(local_irq_desc)[irq];
=20
+    if ( is_espi(irq) )
+        return espi_to_desc(irq);
+
     return &irq_desc[irq-NR_LOCAL_IRQS];
 }
=20
@@ -79,7 +128,7 @@ static int __init init_irq_data(void)
         desc->action  =3D NULL;
     }
=20
-    return 0;
+    return init_espi_data();
 }
=20
 static int init_local_irq_data(unsigned int cpu)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110720.1459791 (Exim 4.92)
	(envelope-from )
	id 1uuG9F-0006jQ-Lc; Thu, 04 Sep 2025 20:01:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110720.1459791; Thu, 04 Sep 2025 20: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 1uuG9F-0006ij-G0; Thu, 04 Sep 2025 20:01:33 +0000
Received: by outflank-mailman (input) for mailman id 1110720;
 Thu, 04 Sep 2025 20:01: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 1uuG9E-00062f-D2
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:32 +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 f2ba6701-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:30 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:28 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20: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" 
X-Inumbo-ID: f2ba6701-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YfOh3weuaya+xaFwWSfDvbuDAIupZDLXvbVYhqwGJfVy88+wkgRMBDR3F8FKc2qe53UU01FtUqXQxWDiniTUETc21nfIIoil/49vkBzqIBsJHqLO2crACLFHbCk0+7zwbIjmw7A3got9KnEP79rJdqrpq7DLwj7l2ylnjsW8joLxzZJyfgxxz7xlB9dFHaaLqk6vQN1ZQb+6oL6G0dc+he45n3sPVJ/xB0KfnhN3SJpF0bfDbgtMhkmzKF3E3/dh3w/HkEaucdT1ajWY7qMQ/46pXALkyQBkJ08H8kxptflX7ecqF98Ht0dUcOL+a+jiMKbZBzDe9jxskJz3Usqwrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=j9XHhD5txai2A40boCFbZtFLYe1p5OBuox3b41qDc8k=;
 b=Surimlp5XkzDePjN5phQxYqKlnBzIrEd9ZzDA1UVPdhSCuuGmAZMxxIjySercWPmsCgZFNA+oc8thsubpxTqFJdTOsrcWkgYqx5U5KA0xRgNBSA0aTnogc8+VXeWjx28xkQvmqsb7bFzXYuu4q+2LR6speK9vGlziAeyTV926ko0rUAYcbhJGap4gf7EjyKpa1itabmVqKbZalMLS/+FRwOlbuzwhHzzeg/cIZtksGtegpZZu1onYNX8VEhUrTUuKo+gnwC++rYHHqIFMBdVq5+VeKQCWO9LrdjJwjZRmwp9IXH5kH3Wg+jAZZE6Aj2mZhHmVSi3KWm+7tQklD5UUg==
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=j9XHhD5txai2A40boCFbZtFLYe1p5OBuox3b41qDc8k=;
 b=JwEKP6SOxE8rHJl7bHVsEo+wiVjKABRnS5flqLBCszr/sbpoWfT0VuXrbDWvl65lWRrX2DXWN00CktEMNBh4tXVstaWao4FNTlFqwLn2LmuuPRF2FVrXzziJBs4fe8iaD5ce0NI56GTqcqBeQop9VLV4CRAR+4ZXqdFRgSiLEZADc2PlRs4Ab8oUzm4SGkyAJn0yMWAwGdbopO3qEirvqmHt21/Q28y89szfxmIOVtrvFNxQ0kiX3U7P/pZBbVCoprh9E+4Rg1DXs6dC9ahR48FEk7dHMGnYBWt9TRe0i9D+VyuVUSqPcEonaSgDrxc475mYVdj7uSLLUW4zBt3u8g==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	
Subject: [PATCH v7 05/12] xen/arm: gicv3: implement handling of GICv3.1 eSPI
Thread-Topic: [PATCH v7 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Index: AQHcHdazISYJ96ARO0ihPlIvp7RWEw==
Date: Thu, 4 Sep 2025 20:01:28 +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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 55dd55c4-9f68-4b71-31fb-08ddebedd607
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:
 =?iso-8859-1?Q?4NB35yWsLsDoMxU9E8BNxlyUxQivEEPQLQOhQ0Oox4PVh4PCd4Bucqo2mC?=
 =?iso-8859-1?Q?pD1tx68cKFj6bUx0SGV80QIPBa0R+6U1DZtDISQXL0UM+kKhZZNJVVM2k9?=
 =?iso-8859-1?Q?TBWPcBxYlgXGFRfQGwraHGpHLe4++yEpozJMtgFwJxK3d6y6HRIEkNPI3t?=
 =?iso-8859-1?Q?YxTb97nd28pPL4+3VQRBy3gYUWP5Uf6KQlNThSX1CiIR3c3SZgRsTlv8vS?=
 =?iso-8859-1?Q?venEbek8WPGmQ2MqdLKOZhrZWZ6ZV30GF/aQc4jL1UpzKgkxHZdIjwFbI7?=
 =?iso-8859-1?Q?25jqA/Tq4B4rhHIyaNVQI3tD8pGV8oHAysNQsQUhxc+PWr6BBmqSJzceQu?=
 =?iso-8859-1?Q?artJ5LTbFhXjVNmSHmfQUV/XVHcYfdaRaonVv9Jka2k49CJEtB6+l3dPQe?=
 =?iso-8859-1?Q?YKw9grENOhWfc+98s9WrgyZutaQeQJFJfQQ95uww7yuMD4zf8XLII3JIN3?=
 =?iso-8859-1?Q?Ke2Szry/gVC5iJc/7wTNnHmK4yUlExHIkzRAmLY24epYm4oobyrTdEt4hy?=
 =?iso-8859-1?Q?iP82788uJk2mbU2N8tdNK8sS1SWP8pNfQwFBlp99RPaBprcck3BhDwfLQt?=
 =?iso-8859-1?Q?chAnYUdRjxwgSOduTNlNwVLJ3NONqPUoN7f1TvpSuKXJ4y/z4mvYba0zRC?=
 =?iso-8859-1?Q?HX4pPGPqGcU2DYzUINKF8mJTLbRRbL0qjBJREGml6D3vAcmyaJ1gQUsu3s?=
 =?iso-8859-1?Q?xCadG1Ere6rWsjJbQDB//2dMMUvExjr+EzFSDoYgKEwCjgsNk05U5znD9d?=
 =?iso-8859-1?Q?xQpNqL45cPvkPyAk+bYyL3nowcI2cCfkBv+zSqoMg8hsCTwXAs7hHPlNzv?=
 =?iso-8859-1?Q?dwmtSsztymFMji4wZRo/llJmXeI95r+xmSCRMh/9MH35/5+MSx2dHoRfZP?=
 =?iso-8859-1?Q?6Joan4yJYVqQHRSatusVUpgZNjv3LeBKEmavMHKRoZiOS3YiEz+YSS1s2/?=
 =?iso-8859-1?Q?eT8/a+qkjcEylQNyapuhenG4odQpdKZVndTfausL5TLXZETfFiHNPBfpCW?=
 =?iso-8859-1?Q?TM/E+EuMax0aRelWnwhN4Dy74QlmxSk3iCbmenQR7IOFS8WfGzO9yLp6OL?=
 =?iso-8859-1?Q?PI90udOH7So4HVH2Xpykx/AHU/LpYMG4MNh4kwImvu3A9uVufLsvRXSQDq?=
 =?iso-8859-1?Q?g97D/vdubmH5dRCkXVvah6VM048ZR/4LZMpc5eG85MFAPK6X20n/oEKsTR?=
 =?iso-8859-1?Q?nhF1CBS6gKaZ+iZVqCcohKPy5aSgr8pMN71m5rrvYPJJO1vX6ZWTRWzdBe?=
 =?iso-8859-1?Q?MSmtvHkBRwU1IJgdEynP8LhHPNx9T4qbzaLs6folvq9jCKkdeOORpq/ecB?=
 =?iso-8859-1?Q?NRPayRpICmYypYZh6Pp1He95PBr3H0YPhB9x6jqUORXOB5lZIIgJHapFFD?=
 =?iso-8859-1?Q?hXUmuq11Qmg2tWCmDP5YQuecoTsr8tOTU/rB2g/7fkZ5yp+a4bauo+OY7b?=
 =?iso-8859-1?Q?g4a/ODpbhlWg3nDdZk5gRM0h9VEYLej/dC1dSPoIvJnkhKfKOw1N0ByLEU?=
 =?iso-8859-1?Q?jITzSoJdgGV5k4W0+NNF+bO2jQkB0iP/KvjTnENR6jPw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?YYdmVREBWR2UMCC1KspPFj320kC+ZzV01Ntn2i2f3XEi8G3Hog2QGvrinn?=
 =?iso-8859-1?Q?TH3fkZpVplkwJLFHXGeuaQXHoufxbTorQ9KtxrLlJBtMi+yJn/XoeLsmTD?=
 =?iso-8859-1?Q?8U9s3zq5iCfDd04hKJCZgWxIICcF9BkeTolKTfrwfAocltxdfX+D/qLx9D?=
 =?iso-8859-1?Q?yB54hUCGyx/N9McAEzgBQNKy/NRIDqyUsrSP8lsLtYmzkLqOmG0xbfEUqT?=
 =?iso-8859-1?Q?8YYSZP7MqGirHoanSYoUG1hPuiNbfjLMbhN+7VEZWYsfgprgrdzqrtQj2v?=
 =?iso-8859-1?Q?gdAw24b0Nq9RK/2QC6Ad3mQT/qtQIpGaUXba9cilmPvZv11ZOI6KybWE/p?=
 =?iso-8859-1?Q?dbCG2nVMGkxpBd7hif2Koby3qnTO51jy1eO5n/+qr6XMo5j/SKKyHJRx62?=
 =?iso-8859-1?Q?ZMiSCrGzWPEGGlZlOK37XKD4bvVcBaWZGqHqm2qDi1awyndF1j25ygzfEo?=
 =?iso-8859-1?Q?rvKRXwQXP/BeFt7fa9BpTbr8+AuUAhOYhPLFkK8DwEHce06wtaAC0Nb63Q?=
 =?iso-8859-1?Q?AzeVBhse9Q1NXFLisbIjoYp/or2Fn0/jq0GgxIdlxSsY8/vSAzl2jTAZEA?=
 =?iso-8859-1?Q?PoR8vZnwQXoJMR4/DYQ/4IUVG9V/vlijp5ySGpTCQUApspQekUoPM7/c2b?=
 =?iso-8859-1?Q?2286MFlvyoSZuSdbvarOoga1RjKxJCbRAX+7YK2lsOTPzJb0heyPcr4kj7?=
 =?iso-8859-1?Q?q7HPC+UJL7UkoWPEKjhXGae+9DBq3oADm3XnaLcvF+A0usYIJtivCtPLAb?=
 =?iso-8859-1?Q?IGTb/ay9yg6zc81e7w9mDBvEF7DMLT1/l4yXbTCkHPPOCWeO37TF1NdBaP?=
 =?iso-8859-1?Q?CZzyR19M/HXY2SvdA+hMUsK4oGAaiPP5QP3LNuXZujTy4tfduNImTbs+A2?=
 =?iso-8859-1?Q?wmgcoexD9//oIJNfQJvRDgHH2GoELSQ9XGGpQwpZe6SHDtTiDdonCRjkkH?=
 =?iso-8859-1?Q?xh15PgGvE1BVixYC2q3A1f9TQSXUYfXKXPZBEW0dewC/I8BS4vKRyz9ane?=
 =?iso-8859-1?Q?xywmvh42410DTTehhae/WFN1z+PYOpzc5qHY3hYx49lzR0ccDkfNS6BObQ?=
 =?iso-8859-1?Q?aVhT6fbd8A/Ym47b/L2pftii53I/RQmnT0j82WdXd49zzmQSJHKcnjR8ke?=
 =?iso-8859-1?Q?5h2LJP88H3ehmbJHEV9H/LgvPMRBuY+Bba5FADF9B41oC9WpUwo0UUplsj?=
 =?iso-8859-1?Q?b6/csWPVyvnGDBvPI8or8IS2E4wB5wRvC0V2K/PDN639wXK4HihvIHLVf2?=
 =?iso-8859-1?Q?pF4OYuti7fpYqQV8xoqeIPvfu5YY1S1WzTHS6U58eDNtEgySs4QIUbvBAi?=
 =?iso-8859-1?Q?GTpj+9On5z2UAKQ/6ysCM5/2GSasGFD0EUFgC6b94gikh60sMz6SeZL5Xu?=
 =?iso-8859-1?Q?Kkc4s+LqcEfZIk5HOTXjs+aR4y1KUnyMhlcCLWAFb5txXrAqSeyYWAxrLs?=
 =?iso-8859-1?Q?RuTyw5d3hHcFKJ3PM+uPFBzVezX0y1c+WyhsGNRUovlGU47UbSzIDarvyM?=
 =?iso-8859-1?Q?7Tsf9E2nSc8dfuApTQZBEaAtSS0Uo5Q0zWfdGYGLQrFvW9vXXWypPPa6D1?=
 =?iso-8859-1?Q?kOE+oXxAVvjIWqmarRQuDKW23jaGQe/bjkLvce2wciPze+ULyiLo1gBP9Y?=
 =?iso-8859-1?Q?AHuzTS71+hqwUKYfgJilidoWA2XOcPX1UV7Z6vo0HsBRdXAfEqKHZAphX+?=
 =?iso-8859-1?Q?HgpcnKb/1YyWZpij7XQ=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 55dd55c4-9f68-4b71-31fb-08ddebedd607
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:28.7002
 (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: TIPfTqjDqj5O72VMVQ46Pd0Oq3XXEz4oW7cSaZ223zdLdZZ9d9XkAMufxzwumhNfNNvzAF8nWE/XbdHtfoDJc81OQ66yoTKB+C/4Y5kSJT0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Introduced appropriate register definitions, helper macros,
and initialization of required GICv3.1 distributor registers
to support eSPI. This type of interrupt is handled in the
same way as regular SPI interrupts, with the following
differences:

1) eSPIs can have up to 1024 interrupts, starting from the
beginning of the range, whereas regular SPIs use INTIDs from
32 to 1019, totaling 988 interrupts;
2) eSPIs start at INTID 4096, necessitating additional interrupt
index conversion during register operations.

In case if appropriate config is disabled, or GIC HW doesn't
support eSPI, the existing functionality will remain the same.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V7:
- no changes

Changes in V6:
- removed unnecessary parentheses in gic_is_valid_espi()
- updated gic_is_valid_line(): it now verifies the condition irq <
  gic_number_lines() first, as it is more likely that the irq number
  will be from the non-eSPI range
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch
- added reviewed-by from Oleksandr Tyshchenko

Changes in V5:
- fixed minor nits, no functional changes: changed u32 to uint32_t and
  added a comment noting that the configuration for eSPIs is the same as
  for regular SPIs
- removed ifdefs for eSPI-specific offsets to reduce the number of
  ifdefs and code duplication in further changes
- removed reviewed-by as moving offset from ifdefs requires additional
  confirmation from reviewers

Changes in V4:
- added offsets for GICD_IGRPMODRnE and GICD_NSACRnE that are required
  for vGIC emulation
- added a log banner with eSPI information, similar to the one for
  regular SPI
- added newline after ifdef and before gic_is_valid_line
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- add __init attribute to gicv3_dist_espi_common_init
- change open-codded eSPI register initialization to the appropriate
  gen-mask macro
- fixed formatting for lines with more than 80 symbols
- introduced gicv3_dist_espi_init_aff to be able to use stubs in case of
  CONFIG_GICV3_ESPI disabled
- renamed parameter in the GICD_TYPER_ESPI_RANGE macro to espi_range
  (name was taken from GIC specification) to avoid confusion
- changed type for i variable to unsigned int since it cannot be
  negative

Changes in V2:
- move gic_number_espis function from
  [PATCH 08/10] xen/arm: vgic: add resource management for extended SPIs
  to use it in the newly introduced gic_is_valid_espi
- add gic_is_valid_espi which checks if IRQ number is in supported
  by HW eSPI range
- update gic_is_valid_irq conditions to allow operations with eSPIs
---
 xen/arch/arm/gic-v3.c                  | 83 ++++++++++++++++++++++++++
 xen/arch/arm/include/asm/gic.h         | 21 ++++++-
 xen/arch/arm/include/asm/gic_v3_defs.h | 38 ++++++++++++
 3 files changed, 141 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a1e302fea2..a69263e461 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -485,6 +485,36 @@ static void __iomem *get_addr_by_offset(struct irq_des=
c *irqd, uint32_t offset)
         default:
             break;
         }
+#ifdef CONFIG_GICV3_ESPI
+    case ESPI_BASE_INTID ... ESPI_MAX_INTID:
+    {
+        uint32_t irq_index =3D espi_intid_to_idx(irqd->irq);
+
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+            return (GICD + GICD_ISENABLERnE + (irq_index / 32) * 4);
+        case GICD_ICENABLER:
+            return (GICD + GICD_ICENABLERnE + (irq_index / 32) * 4);
+        case GICD_ISPENDR:
+            return (GICD + GICD_ISPENDRnE + (irq_index / 32) * 4);
+        case GICD_ICPENDR:
+            return (GICD + GICD_ICPENDRnE + (irq_index / 32) * 4);
+        case GICD_ISACTIVER:
+            return (GICD + GICD_ISACTIVERnE + (irq_index / 32) * 4);
+        case GICD_ICACTIVER:
+            return (GICD + GICD_ICACTIVERnE + (irq_index / 32) * 4);
+        case GICD_ICFGR:
+            return (GICD + GICD_ICFGRnE + (irq_index / 16) * 4);
+        case GICD_IROUTER:
+            return (GICD + GICD_IROUTERnE + irq_index * 8);
+        case GICD_IPRIORITYR:
+            return (GICD + GICD_IPRIORITYRnE + irq_index);
+        default:
+            break;
+        }
+    }
+#endif
     default:
         break;
     }
@@ -655,6 +685,55 @@ static void gicv3_set_irq_priority(struct irq_desc *de=
sc,
     spin_unlock(&gicv3.lock);
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+unsigned int gic_number_espis(void)
+{
+    return gic_hw_ops->info->nr_espi;
+}
+
+static void __init gicv3_dist_espi_common_init(uint32_t type)
+{
+    unsigned int espi_nr, i;
+
+    espi_nr =3D min(1024U, GICD_TYPER_ESPIS_NUM(type));
+    gicv3_info.nr_espi =3D espi_nr;
+    /* The GIC HW doesn't support eSPI, so we can leave from here */
+    if ( gicv3_info.nr_espi =3D=3D 0 )
+        return;
+
+    printk("GICv3: %d eSPI lines\n", gicv3_info.nr_espi);
+
+    /* The configuration for eSPIs is similar to that for regular SPIs */
+    for ( i =3D 0; i < espi_nr; i +=3D 16 )
+        writel_relaxed(0, GICD + GICD_ICFGRnE + (i / 16) * 4);
+
+    for ( i =3D 0; i < espi_nr; i +=3D 4 )
+        writel_relaxed(GIC_PRI_IRQ_ALL,
+                       GICD + GICD_IPRIORITYRnE + (i / 4) * 4);
+
+    for ( i =3D 0; i < espi_nr; i +=3D 32 )
+    {
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLERnE + (i / 32) =
* 4);
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVERnE + (i / 32) =
* 4);
+    }
+
+    for ( i =3D 0; i < espi_nr; i +=3D 32 )
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + (i / 32) * =
4);
+}
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity)
+{
+    unsigned int i;
+
+    for ( i =3D 0; i < gicv3_info.nr_espi; i++ )
+        writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * 8)=
;
+}
+#else
+static void __init gicv3_dist_espi_common_init(uint32_t type) { }
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity) { }
+#endif
+
 static void __init gicv3_dist_init(void)
 {
     uint32_t type;
@@ -700,6 +779,8 @@ static void __init gicv3_dist_init(void)
     for ( i =3D NR_GIC_LOCAL_IRQS; i < nr_lines; i +=3D 32 )
         writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4)=
;
=20
+    gicv3_dist_espi_common_init(type);
+
     gicv3_dist_wait_for_rwp();
=20
     /* Turn on the distributor */
@@ -713,6 +794,8 @@ static void __init gicv3_dist_init(void)
=20
     for ( i =3D NR_GIC_LOCAL_IRQS; i < nr_lines; i++ )
         writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTER + i * 8);
+
+    gicv3_dist_espi_init_aff(affinity);
 }
=20
 static int gicv3_enable_redist(void)
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.=
h
index 3fcee42675..3947c8634d 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,9 +306,24 @@ extern void gic_dump_vgic_info(struct vcpu *v);
=20
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
+#ifdef CONFIG_GICV3_ESPI
+extern unsigned int gic_number_espis(void);
+
+static inline bool gic_is_valid_espi(unsigned int irq)
+{
+    return irq >=3D ESPI_BASE_INTID &&
+           irq < espi_idx_to_intid(gic_number_espis());
+}
+#else
+static inline bool gic_is_valid_espi(unsigned int irq)
+{
+    return false;
+}
+#endif
+
 static inline bool gic_is_valid_line(unsigned int irq)
 {
-    return irq < gic_number_lines();
+    return irq < gic_number_lines() || gic_is_valid_espi(irq);
 }
=20
 static inline bool gic_is_spi(unsigned int irq)
@@ -325,6 +340,10 @@ struct gic_info {
     enum gic_version hw_version;
     /* Number of GIC lines supported */
     unsigned int nr_lines;
+#ifdef CONFIG_GICV3_ESPI
+    /* Number of GIC eSPI supported */
+    unsigned int nr_espi;
+#endif
     /* Number of LR registers */
     uint8_t nr_lrs;
     /* Maintenance irq number */
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index 2af093e774..3370b4cd52 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -37,6 +37,44 @@
 #define GICD_IROUTER1019             (0x7FD8)
 #define GICD_PIDR2                   (0xFFE8)
=20
+/* Additional registers for GICv3.1 */
+#define GICD_IGROUPRnE               (0x1000)
+#define GICD_IGROUPRnEN              (0x107C)
+#define GICD_ISENABLERnE             (0x1200)
+#define GICD_ISENABLERnEN            (0x127C)
+#define GICD_ICENABLERnE             (0x1400)
+#define GICD_ICENABLERnEN            (0x147C)
+#define GICD_ISPENDRnE               (0x1600)
+#define GICD_ISPENDRnEN              (0x167C)
+#define GICD_ICPENDRnE               (0x1800)
+#define GICD_ICPENDRnEN              (0x187C)
+#define GICD_ISACTIVERnE             (0x1A00)
+#define GICD_ISACTIVERnEN            (0x1A7C)
+#define GICD_ICACTIVERnE             (0x1C00)
+#define GICD_ICACTIVERnEN            (0x1C7C)
+#define GICD_IPRIORITYRnE            (0x2000)
+#define GICD_IPRIORITYRnEN           (0x23FC)
+#define GICD_ICFGRnE                 (0x3000)
+#define GICD_ICFGRnEN                (0x30FC)
+#define GICD_IGRPMODRnE              (0x3400)
+#define GICD_IGRPMODRnEN             (0x347C)
+#define GICD_NSACRnE                 (0x3600)
+#define GICD_NSACRnEN                (0x36FC)
+#define GICD_IROUTERnE               (0x8000)
+#define GICD_IROUTERnEN              (0x9FFC)
+
+#ifdef CONFIG_GICV3_ESPI
+#define GICD_TYPER_ESPI_SHIFT        8
+#define GICD_TYPER_ESPI_RANGE_SHIFT  27
+#define GICD_TYPER_ESPI_RANGE_MASK   (0x1F)
+#define GICD_TYPER_ESPI              (1U << GICD_TYPER_ESPI_SHIFT)
+#define GICD_TYPER_ESPI_RANGE(espi_range) ((((espi_range) & \
+        GICD_TYPER_ESPI_RANGE_MASK) + 1) * 32)
+#define GICD_TYPER_ESPIS_NUM(typer)    \
+        (((typer) & GICD_TYPER_ESPI) ? \
+        GICD_TYPER_ESPI_RANGE((typer) >> GICD_TYPER_ESPI_RANGE_SHIFT) : 0)
+#endif
+
 /* Common between GICD_PIDR2 and GICR_PIDR2 */
 #define GIC_PIDR2_ARCH_MASK         (0xf0)
 #define GIC_PIDR2_ARCH_GICv3        (0x30)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110722.1459800 (Exim 4.92)
	(envelope-from )
	id 1uuG9J-000747-0M; Thu, 04 Sep 2025 20:01:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110722.1459800; Thu, 04 Sep 2025 20: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 1uuG9I-00073y-TA; Thu, 04 Sep 2025 20:01:36 +0000
Received: by outflank-mailman (input) for mailman id 1110722;
 Thu, 04 Sep 2025 20:01: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 1uuG9I-0005Me-2V
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:36 +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 f5c9f06b-89c9-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:01:35 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:34 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: f5c9f06b-89c9-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jmBQ9eHFyeTYg+SbovRQYmI9bsTrqsrQNS79LwhoGKvGPjbX8Yz4r9UdpR4TXg0yHaXNme4cxfq4PaPW5QHqMrAvxzpRYmdoQABpAOmAxylFvRMGHgHSPunb+/lrRFxwvcN2yPT9JuPGx7SZpujpQvUvg9vDZAS1irBQ+kPcWCbxu2S9cFWhdBn8zfjIP73bv1Xm5UBL786Wc5BuZmoQDMyMNsYJuYWGJ6FZ+OWNMuRj15lK0p9dI1MFBrmuKA91k/4BBOazSkkm9xpH2WGo3AB5hXEi+ghSroNc14FihNdnXOPbUr51rBmlq7naKgKSO71OlR5RXMSYXC+k/vpQhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8amQj52uB6F8lrYVBAs4+YtHsqR9Gt74UGDRJFJCFA8=;
 b=Q+tziy9Yrgk5yH2IA2JIigiF3kn6K7QTIK+P97/x+yr+2AwZIWy6Vf9rFDtOxPpNwAwJ7JTb7aTZs5xiHug2GS2nr7ck+uulZdWEW+UYgcyXMSNTp8BZP1mKaTv5nxxznPiNRr91B+DOI9YPei7RRXxIHkhMLFxlUkydR5GVpYheLH6hkV23D3SUuQSFUJ8QaurzOegsfVEoG8oMAX98QCW+BsaRDRissjmTiZvGaXozkewQqxllx1L1jcoex2o6RqSvyizY97IApz2+K861Q2Y1lsJKH7nEon8ApdyZfUAHZv/hyouda/tWYpiWjwKPGSYI5ftTfup7Vm64hnHyFA==
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=8amQj52uB6F8lrYVBAs4+YtHsqR9Gt74UGDRJFJCFA8=;
 b=ta95FLH3uvF0ET4M50NXIgjLcOeFOVCCEhVoRMQfZZvV1i1TZ9UZT4eSBuaNPD5fhR+ncN0cgc/q16gKQCPNCk7pSDGtyLCk4DMU8ATCqR07NtrAKE57GBXDOwOHUd6KPIYQ6zn5jrCT3iudRoeAlnWedgelgX7siHT44ItYZ1iqXTYOuFInmD0Vxs9zR9zASVGq97/Syfk+GlYzALdfZe2CP9enR3K3SINKsBiZWFuBnWzHfYhyYJE7X30b/hQmyD9PdoY52G6uzwpRerAFZR3I591RvC7v7M/jhWpd2Q4imw47qamEXI6uzfrdH9Vw1mr3ZnzEYdeEKZ2V0v05ng==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v7 06/12] xen/arm/irq: allow eSPI processing in the
 gic_interrupt function
Thread-Topic: [PATCH v7 06/12] xen/arm/irq: allow eSPI processing in the
 gic_interrupt function
Thread-Index: AQHcHda2Rm5suYGrqkeUMzwFAqKwmA==
Date: Thu, 4 Sep 2025 20:01:33 +0000
Message-ID:
 <59cae29e51b13a71f57f701d5991e06ecf6690aa.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 166a4d60-29eb-48a2-ae35-08ddebedd931
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:
 =?iso-8859-1?Q?FfL5PMyiw2E8E3rE4saNo79uKTIbkLY8zO4VxgX3pW34wb8otKEKiJrsBY?=
 =?iso-8859-1?Q?vh7HU8sk6f/edx/sTiJfT/tQOJ5fjHgrkFan4znR459GOx8VJFTTZk+RSW?=
 =?iso-8859-1?Q?lARpVfGMdUk5g0KTdxKdFahyJQ89jbJmB1Aqrg6IXQiwRQ1KdcuGaQRJu9?=
 =?iso-8859-1?Q?Cvz1uEheMasgbZYMRaYJ3OtLOMsp+WXne5dd9Su92LUAM6lLs1H54/vp3P?=
 =?iso-8859-1?Q?xmCd4mxr9REndzxptvR20uW/MPUBOqItQGmPIdvoIm/bRRD72zX1SKXPsb?=
 =?iso-8859-1?Q?Ui5AUdjiLVpF50TCNm4pBPYBqnG7rv8Xp6u0pBhoL/lpk0UFgv1PNUeoVL?=
 =?iso-8859-1?Q?KOlgjAnBXDWF3zc2febiIbJvVOH/IDnZ/JSOV4vs5CtP2NupPXw6Sao2zX?=
 =?iso-8859-1?Q?DSZ08DMDtm28219IWjUBaakRICf/mqgLIy2S4pmQcP4E0l0WiKR9BFau1P?=
 =?iso-8859-1?Q?PBJ2dt120TD54bUJSB5RVZXlHlPdXhq+2jjJqYcwl7IHd/E/vPjYv7nOFZ?=
 =?iso-8859-1?Q?ntsAbcxHucLX/4YbnGTGLsg4iK5hI6+E02j6wUbbSxyLtIsJ+M8nALU7c6?=
 =?iso-8859-1?Q?pprEpjYxA6U4TB9zhgMWn9hlQemEn3XP3nxoe5Izqt0dh+YoHfbpFUkNU8?=
 =?iso-8859-1?Q?7t+mxtfbej8Lei6q9D25cKem9w+NMKZk3sxrsGTrw+XTD4jU4QhairjxlT?=
 =?iso-8859-1?Q?lCp7WgC8hjW0Y5yjNfnr4IO0MMiHUUmrc319SyzZ4vn2N5VO/oBkpE/STE?=
 =?iso-8859-1?Q?34S4me7TxFOwiavCmnntDxLTy2X7/k1mmqLfDiLQ7+ctHH8n0AZfjXqTvn?=
 =?iso-8859-1?Q?Hbh001useR1/E5W3UqnRziFigtP9ybbTy4nO8up0925npuN/HkzaGYnwaD?=
 =?iso-8859-1?Q?RwsLphNRjl1gD0xT6MLytBQ4gVQ5aS+bynGE6elnuwBGZI9Se1blnEmaSh?=
 =?iso-8859-1?Q?6ezblYx5iFMJvByqOR71471xNwQoCefgXecSPsgZI/6G7yC7bWxLR5sosv?=
 =?iso-8859-1?Q?ctJ8CoknIEP1qL561mX/oCOqcMNnlxweoNKLTcgG61FDJuJBgl68ZHRG2w?=
 =?iso-8859-1?Q?l1s6sRGd+hhNad1i3bWpQj1dFBhv7YRSgb3b2iJ/dvFk4DNSDn5IyWlzx3?=
 =?iso-8859-1?Q?OriHdDyb2i3fBYDetwAHDdiJTZPsVX2Ud5LU7AOrNxcc2TD0ZRTzlj0sGq?=
 =?iso-8859-1?Q?HZK+NPbUDc9EeqzWrVHf/psfxwclqt03ar/uTtQkEvNw//RLSt/mny3LDW?=
 =?iso-8859-1?Q?fWrWY+4/yc2ykVy6hXvYKxzanIA755gp7WCFXj1z8CPmnYIdWnDczLmFH+?=
 =?iso-8859-1?Q?Lx7XVIK5fW0IpIYpXSr35UE3gPq302W8b566GaGWvqfmSZzroCWJYcp7HC?=
 =?iso-8859-1?Q?5QxU0e+KkIQvlzXA0e3NaeTIR/DwHdgq69JYQtYgW25eun4TCiQ09uXaRb?=
 =?iso-8859-1?Q?g+Um0nLt3gOObWp7YwiSnP4IPOADM0UVett7ctRDvza2ZJZ4VoSNPPIfQE?=
 =?iso-8859-1?Q?SrYCRJDf03W8+1yLBJzxjQVYiSweRhEMLqB+0w/z3xew=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?/iWf7nJeDOFIplQqadzY4pa0jtXM0frOUkoMNP7kdWAwbwtXgi/tJxEoj6?=
 =?iso-8859-1?Q?C4vSwSt4baUDgIM5AEYpG6qcHW9rKyshCY8IU8Xxt4QUW/lbmEX3lQ3sk8?=
 =?iso-8859-1?Q?+Ku+Gxv/uag3HfsONdgd8vo/txUiY9436la+KM9SkSthXZLxld3r99e7cz?=
 =?iso-8859-1?Q?JbWSEMt6jH+BqdLeEQJ4+A4ZKGbW2zVqfAlqQQIm57chDjtIex6C84Wqfx?=
 =?iso-8859-1?Q?WFh1DeOxolmhPo0O/eHeUjZ4pRJdPJmyaRDjhjY+maqIUryFfhb8FNO5Ir?=
 =?iso-8859-1?Q?YAsfS15rVuPMWI/BsSpL0A7/dG1T10EkELzS/ooV57/oZTPIZQDXI69xNz?=
 =?iso-8859-1?Q?A4kLAm1SnjM66jWZ+17nMzTIvVidHSyoqshxlbfApaBwAxMSJYoExeTN8X?=
 =?iso-8859-1?Q?P39fY0bhJTxJnOO7GebE0E/K3+uyovTGY8KKe5JZKvVIlur1pjOJUEv21k?=
 =?iso-8859-1?Q?VaI+0nlCW4GuFry/7Qd8fIAV+7yBt7gdGObAn2S3XEehi3kBtqoSZJDsTc?=
 =?iso-8859-1?Q?4qP6psh402gUojlb6OlI2NjZngRetKUuCRb8d4k6/sc+0J8crNHwhN6ToH?=
 =?iso-8859-1?Q?b0eJZ539m4s4eKsYD1QrtGRj4e0VgIXv2NAoah3Ovr0CN+/r0aD640S4uo?=
 =?iso-8859-1?Q?gVl8n5M2tmmtPO/wb8rAugyQFT6n8w6XlIdNCcDAcNx+qynvGfYp3WZ2iK?=
 =?iso-8859-1?Q?jO6EkAg0Dcu5mrBXndZKTQR3K1f7CJ9WUsAd6LJFSLHFJLK/diHNLXEiaf?=
 =?iso-8859-1?Q?zr+wJ7MXvBeoWHOOJmm7JJ9zF+i3I4h6C6fm5+MoPRKrUVp/3bwrCmDtOX?=
 =?iso-8859-1?Q?SXeJc2TPF53i5HyDMljSjCjrfPfJu69tenmf2cIVckFGPvcS/XNg+z1kjr?=
 =?iso-8859-1?Q?Dw+w3YO7AIVSQP2jU/E7/L7WLJ2R9nsmSu6L4qmEtkMxmGooFUxzjyBH94?=
 =?iso-8859-1?Q?6TM+X6kNTiKYGgAcDzPAn9KGC3SQC9WywMsxog7okczSnf09D0QlXJdQa+?=
 =?iso-8859-1?Q?ry+EXMT80IK9lDwYyDrEGoSF/9ivSMET2yND4wQtoyMjt4zk5rhDXgaAL6?=
 =?iso-8859-1?Q?yEM6sb64+n3sHZn46m7AtDEN4EbADQqkQT3SgHksfpU1/aqE3UuJx87JXf?=
 =?iso-8859-1?Q?vPtfnd1Klr8VNbmxP1jSCEmjORxi/e9ovseRwdKdv8+g0jO38RInVvh5Lb?=
 =?iso-8859-1?Q?1p8XeocybiQvBH81NW0jTod8yG02ubaMmduEuokLVA+pESqdoVy3ng4bJ7?=
 =?iso-8859-1?Q?o4mVhPb+JuJ7HXRVIPfudZP/7kEUqZdrS1bnyQK+1U1N2sNwA29tljUy0N?=
 =?iso-8859-1?Q?1bxhbKlHVNt15/ZiP0RCath9JdKzPYsGmRZM+rv0Ze1bUYv6PfOhk1I8QV?=
 =?iso-8859-1?Q?ppceG8mUG45P+inGLCzwr5ZHqeNrjUGyNtWs+2yqO/PKLSPy7O9pZNnnSB?=
 =?iso-8859-1?Q?z+mlQkE3yphEXzu/Rgk9sLdHZ66lPgdnX6KOrD85Ysd8C2RDadk8TzpOHk?=
 =?iso-8859-1?Q?tnK1MGoQq9o9duqkhcKK0zJg5ZtjTi01eAUxFRadcajFArR2GIJW1vXCOQ?=
 =?iso-8859-1?Q?dVlmmg7Qp7IcXq3lRgZ4NQwVAjos2fTa3uhYsya0pvmGz582IlVlGPe1vo?=
 =?iso-8859-1?Q?68sxc4C2UXPVOBC+OMF/7XE9Tqb7sMtk8y+7W6CAyeS4poeBwzPrn3m4c2?=
 =?iso-8859-1?Q?x3dc6JcSZJ/+SGbcyTM=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 166a4d60-29eb-48a2-ae35-08ddebedd931
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:33.9820
 (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: NNQkWw50kWMCMsPxJGyciYsJdI5X7GD4BT8a38W/CCfmMnQj6UbW4c4oswTgFOmZfCcdqixYYoMwoqhGQDE/lwjmho491IDAoYIG8H4nPZ4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

The gic_interrupt function is the main handler for processing IRQs.
Currently, due to restrictive checks, it does not process interrupt
numbers greater than 1019. This patch updates the condition to allow
the handling of interrupts from the eSPI range.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V7:
- no changes

Changes in V6:
- added acked-by from Julien Grall

Changes in V5:
- no changes

Changes in V4:
- fixed commit message
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- no changes

Changes in V2:
- no changes
---
 xen/arch/arm/gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 9469c9d08c..260ee64cca 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -342,7 +342,7 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_f=
iq)
         /* Reading IRQ will ACK it */
         irq =3D gic_hw_ops->read_irq();
=20
-        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) )
+        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(=
irq) )
         {
             isb();
             do_IRQ(regs, irq, is_fiq);
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:01:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:01:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110737.1459811 (Exim 4.92)
	(envelope-from )
	id 1uuG9W-000802-Ct; Thu, 04 Sep 2025 20:01:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110737.1459811; Thu, 04 Sep 2025 20:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuG9W-0007zt-7O; Thu, 04 Sep 2025 20:01:50 +0000
Received: by outflank-mailman (input) for mailman id 1110737;
 Thu, 04 Sep 2025 20:01: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 1uuG9U-00062f-Ka
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:48 +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 fb53b42a-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:44 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:42 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: fb53b42a-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ClLDr0qni1HBWAl7djD3UP+zzlHfMooTvx6iJV3g9yoltysC9BQXR2ZuV4DNzTST3ed8Z4U18+CX++nEw34E4JGMyQOR3mgXgxew/FvzDc/W3wL0Ua9qzqfPeHpdDGXI81zz3yQ4rCPtvi4KBOrpJiirvDX1SsefuH9mbKfou0PKV7VMij2H1LFlLy5F2YXFC4o5TDYzcX2NxXM+Zyes169eq/DFm49BMu25O0NSrjAWwDDcYIP7669DR8rw2Aiz1JtatXpOBoRzIJlfwqnEMbcYLYQiszNqtWHUJiNX7D298otmDI1vXV1E6gLTA3ljYZGen33aX+sO25gtXkE4zQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NwEideHyBWH5HBdcPZEG3XzSkmnV4wroH/dA6t1HAZQ=;
 b=jOU4FTSpSOFZ83KYZXVbIvDpdUNxa8hfFAraJHLXXkQGRGglAxqzaQm5qRiJQ4ohY/AQaBQP1DjrwJRh5sOD85Jd4oZSFQDVlR4cwV2xD7JRFPNc5HA4+w3TecYDvHHCSTD0XzrPSeNHPjJrd3T4GvprLeiWBlvdG7aJbnDS5kNpR7WEa6zj/kNzThjhr5jQNF73jBlMRbjuZSveG+s/X8sW99PgB0hEJRu3fOooEo3Wd0wQ5JE0N7/OKCIKzmbmVCg3n9modoihBTlOVKnX4lg+4t/SKrdzSX3Q414xO6Llv7Y6cPFFIbxfIquyeUyUBwRpJqA+fyQha+1zAG6pcw==
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=NwEideHyBWH5HBdcPZEG3XzSkmnV4wroH/dA6t1HAZQ=;
 b=WfpdAVdW1apVmKrHume4+l5ITi1HTxjjpv6hJcy2wyFKTALCA0Q77KPvmVUGPLZdF9Syv8VMmXz9ZbEMBQY7yCsBomBCw1+EXwO1/yCD67YjuPDbvoRfu9QVJmU1+D8kQE6i1X3m4g6SMXuhsyBVhOMTLWHmWZzktGnlsrtr9TKHMvMawEsYWVud8nQImWGmO/B8XDy4IP52Z/fwcJyR6X+oYzAYElaf/Wjhu8GGIbZCOPx3er+J09oxm8ayI8g5PO1hc62we/KXvLDpPx9DdjAGG/MNa+hFnhOL35OZFv5GMbuJEShOFngEL78AKG50n6F0XD+OvEsH9j4za6plxg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	
Subject: [PATCH v7 08/12] xen/arm: vgic: add resource management for extended
 SPIs
Thread-Topic: [PATCH v7 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcHda7K0pyLOwxO0S0jgjHf9IKGA==
Date: Thu, 4 Sep 2025 20:01:42 +0000
Message-ID:
 <5b34940bbc90c4144f4d91880524f452d974d14a.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 3c9c3d6c-b2cb-42f3-97f1-08ddebedde09
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:
 =?iso-8859-1?Q?IcFXbsq48jlms575+Gsq7/gId1IwOidgJuYlowu8rNksV6whPJfuD8aOfV?=
 =?iso-8859-1?Q?Kva4UVyX4asiHhrii9c5Mlf20OMKFfXQD7f5JUVtwHdoHcmVvL0sbiRdq6?=
 =?iso-8859-1?Q?IkWPyvHAaJC876wLIhdAT3pd+qMW7bWQDQNfugyqvw2XFafE70sAdkhlJ9?=
 =?iso-8859-1?Q?+tVsgN/CkBAic9ywokRaC4oaTJ05RIMbwD+6qInGBp4vhU1VP0yHmlk/N7?=
 =?iso-8859-1?Q?PDfUtb2pwiZYcaPBmGo8OZ/whMvAwMDBckB5qt08YZYbs0Fy8ODpovHhQy?=
 =?iso-8859-1?Q?6RoaJ1JIorhtGqPm00I8TIzKenCUJQnVCQTPqBRRIOuYj8SAqOtwV2xXHB?=
 =?iso-8859-1?Q?vF9C2QeILu0dWsBt0uoVgbxU3Jf9MY6klvn/aOioKV4ghTmU3GIh0tF16D?=
 =?iso-8859-1?Q?4PLUclL1O0ROa/vQSOD99WPMKgsOMqZ3MRULd69BYL/huhc8wzvdRJrBLp?=
 =?iso-8859-1?Q?MPHyJnLU5tzA9+ODiGolSav9m9ylU3Wue31ZwxYqpWOsibDjFNRdchN4LB?=
 =?iso-8859-1?Q?WGNWT25I/Ssol/mwW2QJaTDCT2NQPm0yhapFpYWHHfBfDiTXbu+pTotQs/?=
 =?iso-8859-1?Q?tgt/rKPecOcmLtDvESIs3i25XvgUlkKcGjfeDvc0VlSGYZikrAuQUMxLlY?=
 =?iso-8859-1?Q?sm6DioAoMIx3tZ3zVUttorl4eTSswiyg1cpBF5tmXSQOGAK1FD/JXDnXnM?=
 =?iso-8859-1?Q?6Mmg6dOHRAbXbTPMG+dIr2acRI/LVGoNWBsPtWGHserHLdeHmTb4Zw4tE0?=
 =?iso-8859-1?Q?1ZChptIUbeLAVRH5IUTxFL0tefw+akccub9ivBkcnx6nHOA1z+ZmbyTLE9?=
 =?iso-8859-1?Q?f8VhIY263DK78LZytzvI3mcNlPavr+ZxqNaLyLwwL1XnyyKb1W8MNfCOSV?=
 =?iso-8859-1?Q?CgZIIeakHmT87wRMwyjHmrkxOqq2+p3iZdW90pwx+EIpiXaQuPDgLDp8cB?=
 =?iso-8859-1?Q?Sa1TEaIp324pZHbgqhgEuUSb9fN+oO5ck1DJbfpRhscyss4aDpNNct48re?=
 =?iso-8859-1?Q?9CtEWoh4Q0AZlY+iz49iZweOtbu9N3AOhVKV8CFESwprGJCxoRkQyiKTzF?=
 =?iso-8859-1?Q?EnTgaYLc8U7wghqcUY00/NnVBjsgWZoV+ipFTxdBe/2FF8WD3OUHsMbH73?=
 =?iso-8859-1?Q?q70ffTOd2Tl1uSYrc6+JjZQfKPaLbvjWiWi4HRYyxtus5zbxVDJFO9LYeg?=
 =?iso-8859-1?Q?zqqNyYh7EWKwK9uAVXEId3uHcFPc7eofLXRyiCuJaHg5zGBjTkxAdD/wf5?=
 =?iso-8859-1?Q?ivnszpWwVuKGJERQUXyqAttVOI6VGy62wLO62X/8dOfSdrmrO1CSsHuLlF?=
 =?iso-8859-1?Q?DYISRz6PHkR4jW7WuufwhDMGNJr3n+H7Y2tiA7FPUdCoILmZgdWLtfnhmt?=
 =?iso-8859-1?Q?buJ/qfOXNjiLhPkgOmNQ0qL35yPf5Wgu+7+cUA/IZcl+WFYysQCrvY7wcT?=
 =?iso-8859-1?Q?YWltKEdlmrPrAMIKHpoMkNhu78gdfT7wk9qcIhhtA4RTRtd3kkxEzdZBsf?=
 =?iso-8859-1?Q?wWqNKJFU0yQwFMnaDe6R3zoGbDWuM4bRPTdKrzKe1McA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?1t/HZczFzwNEfu8EaBQIxhfzS1t9XfAZvTie4aa1DZLExP4wcKFPNJ5uoj?=
 =?iso-8859-1?Q?KZJ46RMpEXPjacXXgKoorAIOb9GP42+3BVvW57mQ9ryIf/EbSeDjBb207O?=
 =?iso-8859-1?Q?574VmTN7xYr7XXyY4tWHFwqvLZr4hk8bZqnQXoIC0Pp37OjUao5aKbixdr?=
 =?iso-8859-1?Q?HJ9NpAyHlSqVDdgfPwaSd5cg4SGDtNfCiHrqLFxCr47VS3HKK/Up6R6OmT?=
 =?iso-8859-1?Q?w+eJSgKjY032kRk5xsHVEiP0uTyK8KoKBptlailJCAoGDeZlfWx1amkGax?=
 =?iso-8859-1?Q?1l75RjuKqFSCyNloyaCINCC8L5ukOMQgzQctnYsd4PcEIZpBQrUOd4qAme?=
 =?iso-8859-1?Q?zpD3Q4LieCFjVvlTQfK0QheNRMA04J9rI7m9Y+9UfCa6P1ZWXwOJY/8bxQ?=
 =?iso-8859-1?Q?zR+94kyDSFU1O33Tz5Y8m2wrKj0RZlWxn7pfdOnYePTOFcKtyrup2iN0v8?=
 =?iso-8859-1?Q?6ZpyrvUXoea0dvuci4b27R6wSByqVaZXVGD9qIrKXv702YU61dOB8o0JvZ?=
 =?iso-8859-1?Q?3afLLcNf62mcLiIFerAuakRXWb0B2DT8AFDW3c2AoISDp/LV+E6TkxCjuQ?=
 =?iso-8859-1?Q?D0qnx90F1zMURLuOyIZX6UlvZ/0w7cEN3DpbbRLN1eGrphWLPXM+NOT8fZ?=
 =?iso-8859-1?Q?qw3NjX895e6uqRlxF5CvhL58IkJx3tql/mObQlAc2C4Lw0292kUsxHRpb0?=
 =?iso-8859-1?Q?hJrjmr4xahpScxVYYoBgMcxamkzpSFDYNlxcXwU9LjRYC/klqpG7zab+rj?=
 =?iso-8859-1?Q?gcwqNxA+L16JpUoEPKgSHJP7kR8BxyV8kg76C5nDaG+njeHHfhDSXXMJZc?=
 =?iso-8859-1?Q?s1co984poQ8AGKg4UUmxhiq6MFmWOKFIj9zQOueUZjX/2fqeSTlfbgRviZ?=
 =?iso-8859-1?Q?6bxIBaG9mRJOCvraXIXZiqJbAKhI/u6UPt09uJd52e/N1+YoTOOx5HGVzV?=
 =?iso-8859-1?Q?xGEJzpF9LEGi/27bv+UISJUHggQdvvb4Y+fBdLWhIXoUgVSF+z3aqGxh+g?=
 =?iso-8859-1?Q?pDP1S4z0ASqoHa1ckpTYQdfFrKBPaPwwKfmb7m0bfTkPKMox7iy/8lg1RM?=
 =?iso-8859-1?Q?3bh3v4qgTffUAoygQDbe7hr2xveVbN4QkUqsw6GIvUB++RuFiZdmA+U/++?=
 =?iso-8859-1?Q?qO34Efs9XPy4jHIPPH7yQlyFWLsh4DSxJrY0dmZE9CEyjWOZQn2FrBGJIj?=
 =?iso-8859-1?Q?reNaFRR/aYiNNi1c2LhVHoaNRgQqzj0Qw53bz8EbACfW0UaJSKt02vgJaV?=
 =?iso-8859-1?Q?uWiX+chQcnBeD7BhunOe3mxxjVihii0SuJNXz3407Rj07tbP7/Wy79i6cP?=
 =?iso-8859-1?Q?xhHLYNk/8xBUuM0YjEiMt9G7HV7HSlyiPn6ajqTo6DUi7qRhcmNc4k/kZv?=
 =?iso-8859-1?Q?AJLMPBaZ0FaPExI91FqszJX9GnqXTfw4rpeqkewUV5Zs5YoMr2NuVny6FI?=
 =?iso-8859-1?Q?bq6K2v0ZgjvEGY9UEgzVhDBy8H4rghCTBFLXIM+46jH0YiHVkIyQgSKz2Y?=
 =?iso-8859-1?Q?oFMO1qSIZWHW28vY8B+0ilgMxB3jW66PtlE567es+DvJfA8FSTownZTvqM?=
 =?iso-8859-1?Q?agSBTZuPcRI78F/Pp7RmjprjZAP2ysizudG13PFg3uqyrQ7GjvLm/5nCHS?=
 =?iso-8859-1?Q?A94hiYorhGxs++P3kNdMU3l8DgVCMsU5ZN1RPAAtDFPyKspP/abMqjm3+n?=
 =?iso-8859-1?Q?5zyAIRWk2bYogQByg/I=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c9c3d6c-b2cb-42f3-97f1-08ddebedde09
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:42.0865
 (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: 6/MP+NKlmzzt4qMmW4wGLJw+ei+/CUulYuOIqLVb76v5CcBjpkwbWfgm06icjelgwkTXgmC0DssYCz/6McNDHptAlzelSUL6BfUSL9MMsDI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
number of eSPIs, based on what is supported by the hardware and
requested by the guest. A new field, ext_shared_irqs, is added
to the VGIC structure to store information about eSPIs, similar
to how shared_irqs is used for regular SPIs.

Since the eSPI range starts at INTID 4096 and INTIDs between 1025
and 4095 are reserved, helper macros are introduced to simplify the
transformation of indices and to enable easier access to eSPI-specific
resources. These changes prepare the VGIC for processing eSPIs as
required by future functionality.

The initialization and deinitialization paths for vgic have been updated
to allocate and free these resources appropriately. Additionally,
updated handling of INTIDs greater than 1024, passed from the toolstack
during domain creation, and verification logic ensures only valid SPI or
eSPI INTIDs are used.

The existing SPI behavior remains unaffected when guests do not request
eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
option is disabled.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V7:
- minor: changed hardcoded value of 32 to NR_LOCAL_IRQS
- minor: used local variable idx in spi_to_pending() and vgic_reserve_virq(=
)
- minor: added a comment for allocated_irqs and pending_irqs with index
  mappings
- added reviewed-by from Oleksandr Tyshchenko

Changes for V6:
- introduced a new function for index to virq conversion, idx_to_virq.
  This allows the removal of eSPI-specific functions and enables the
  reuse of existing code for regular SPIs
- fixed the return value of vgic_allocate_virq in the case of eSPI
- updated the error message in route_irq_to_guest(). To simplify it and
  avoid overcomplicating with INTID ranges, propose removing the
  information about the max number of IRQs
- fixed eSPI rank initialization to avoid using EXT_RANK_IDX2NUM for
  converting the eSPI rank to the extended range
- updated the recalculation logic to avoid the nr_spis > 1020 -
  NR_LOCAL_IRQS check when nr_spis is reassigned in the case of eSPI
- fixed formatting issues for macros
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch
- minor change: changed int to unsigned int for nr_espis

Changes in V5:
- removed the has_espi field because it can be determined by checking
  whether domain->arch.vgic.nr_espis is zero or not
- since vgic_ext_rank_offset is not used in this patch, it has been
  moved to the appropriate patch in the patch series, which implements
  vgic eSPI registers emulation and requires this function
- removed ifdefs for eSPI-specific macros to reduce the number of ifdefs
  and code duplication in further changes
- fixed minor nit: used %pd for printing domain with its ID

Changes in V4:
- added has_espi field to simplify determining whether a domain is able
  to operate with eSPI
- fixed formatting issues and misspellings

Changes in V3:
- fixed formatting for lines with more than 80 symbols
- introduced helper functions to be able to use stubs in case of
  CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of
  #ifdefs
- fixed checks for nr_spis in domain_vgic_init
- updated comment about nr_spis adjustments with dom0less mention
- moved comment with additional explanations before checks
- used unsigned int for indexes since they cannot be negative
- removed unnecessary parentheses
- move vgic_ext_rank_offset to the below ifdef guard, to reduce the
  number of ifdefs

Changes in V2:
- change is_espi_rank to is_valid_espi_rank to verify whether the array
  element ext_shared_irqs exists. The previous version, is_espi_rank,
  only checked if the rank index was less than the maximum possible eSPI
  rank index, but this could potentially result in accessing a
  non-existing array element. To address this, is_valid_espi_rank was
  introduced, which ensures that the required eSPI rank exists
- move gic_number_espis to
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
- update vgic_is_valid_irq checks to allow operating with eSPIs
- remove redundant newline in vgic_allocate_virq
---
 xen/arch/arm/include/asm/vgic.h |  26 ++++-
 xen/arch/arm/irq.c              |   3 +-
 xen/arch/arm/vgic.c             | 180 +++++++++++++++++++++++++++++---
 3 files changed, 193 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 3e7cbbb196..caffea092b 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -144,11 +144,25 @@ struct vgic_dist {
     spinlock_t lock;
     uint32_t ctlr;
     int nr_spis; /* Number of SPIs */
-    unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
+    /*
+     * Bitmap of allocated IRQs with the following index mapping:
+     * Local IRQs [0..31]
+     * Regular SPIs [32..nr_spis + 31]
+     * Optional, if supported:
+     * Extended SPIs [nr_spis + 32..nr_spis + nr_espis + 31]
+     */
+    unsigned long *allocated_irqs;
     struct vgic_irq_rank *shared_irqs;
+#ifdef CONFIG_GICV3_ESPI
+    struct vgic_irq_rank *ext_shared_irqs;
+    unsigned int nr_espis; /* Number of extended SPIs */
+#endif
     /*
      * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
-     * struct arch_vcpu.
+     * struct arch_vcpu. The index mapping is as follows:
+     * Regular SPIs [0..nr_spis - 1]
+     * Optional, if supported:
+     * eSPIs [nr_spis..nr_spis + nr_espis - 1]
      */
     struct pending_irq *pending_irqs;
     /* Base address for guest GIC */
@@ -243,6 +257,14 @@ struct vgic_ops {
 /* Number of ranks of interrupt registers for a domain */
 #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
=20
+#ifdef CONFIG_GICV3_ESPI
+#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis + 31) / 32)
+#endif
+#define EXT_RANK_MIN (ESPI_BASE_INTID / 32)
+#define EXT_RANK_MAX ((ESPI_MAX_INTID + 31) / 32)
+#define EXT_RANK_NUM2IDX(num) ((num) - EXT_RANK_MIN)
+#define EXT_RANK_IDX2NUM(idx) ((idx) + EXT_RANK_MIN)
+
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
=20
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index c934d39bf6..c2f1ceb91f 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -494,8 +494,7 @@ int route_irq_to_guest(struct domain *d, unsigned int v=
irq,
     if ( !vgic_is_valid_line(d, virq) )
     {
         printk(XENLOG_G_ERR
-               "the vIRQ number %u is too high for domain %u (max =3D %u)\=
n",
-               irq, d->domain_id, vgic_num_irqs(d));
+               "invalid vIRQ number %u for domain %pd\n", irq, d);
         return -EINVAL;
     }
=20
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 2bbf4d99aa..878daa71d4 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,11 +25,61 @@
 #include 
=20
=20
+static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx)
+{
+    if ( idx >=3D vgic_num_irqs(d) )
+        return espi_idx_to_intid(idx - vgic_num_irqs(d));
+
+    return idx;
+}
+
 bool vgic_is_valid_line(struct domain *d, unsigned int virq)
 {
+#ifdef CONFIG_GICV3_ESPI
+    if ( virq >=3D ESPI_BASE_INTID &&
+         virq < espi_idx_to_intid(d->arch.vgic.nr_espis) )
+        return true;
+#endif
+
     return virq < vgic_num_irqs(d);
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+/*
+ * Since eSPI indexes start from 4096 and numbers from 1024 to
+ * 4095 are forbidden, we need to check both lower and upper
+ * limits for ranks.
+ */
+static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
+{
+    return rank >=3D EXT_RANK_MIN &&
+           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d);
+}
+
+static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
+                                                       unsigned int rank)
+{
+    return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)];
+}
+
+#else
+static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
+{
+    return false;
+}
+
+/*
+ * This function is stub and will not be called if CONFIG_GICV3_ESPI=3Dn,
+ * because in this case, is_valid_espi_rank will always return false.
+ */
+static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
+                                                       unsigned int rank)
+{
+    ASSERT_UNREACHABLE();
+    return NULL;
+}
+#endif
+
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)
 {
@@ -37,6 +87,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struct =
vcpu *v,
         return v->arch.vgic.private_irqs;
     else if ( rank <=3D DOMAIN_NR_RANKS(v->domain) )
         return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else if ( is_valid_espi_rank(v->domain, rank) )
+        return vgic_get_espi_rank(v, rank);
     else
         return NULL;
 }
@@ -117,6 +169,54 @@ int domain_vgic_register(struct domain *d, unsigned in=
t *mmio_count)
     return 0;
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+static unsigned int vgic_num_spi_lines(struct domain *d)
+{
+    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
+}
+
+static int init_vgic_espi(struct domain *d)
+{
+    unsigned int i, idx;
+
+    if ( d->arch.vgic.nr_espis =3D=3D 0 )
+        return 0;
+
+    d->arch.vgic.ext_shared_irqs =3D
+        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d));
+    if ( d->arch.vgic.ext_shared_irqs =3D=3D NULL )
+        return -ENOMEM;
+
+    for ( i =3D d->arch.vgic.nr_spis, idx =3D 0;
+          i < vgic_num_spi_lines(d); i++, idx++ )
+        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i],
+                              espi_idx_to_intid(idx));
+
+    for ( i =3D 0; i < DOMAIN_NR_EXT_RANKS(d); i++ )
+        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i],
+                       EXT_RANK_IDX2NUM(i), 0);
+
+    return 0;
+}
+
+#else
+static int init_vgic_espi(struct domain *d)
+{
+    return 0;
+}
+
+static unsigned int vgic_num_spi_lines(struct domain *d)
+{
+    return d->arch.vgic.nr_spis;
+}
+
+#endif
+
+static unsigned int vgic_num_alloc_irqs(struct domain *d)
+{
+    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS;
+}
+
 int domain_vgic_init(struct domain *d, unsigned int nr_spis)
 {
     int i;
@@ -133,7 +233,39 @@ int domain_vgic_init(struct domain *d, unsigned int nr=
_spis)
=20
     /* Limit the number of virtual SPIs supported to (1020 - 32) =3D 988  =
*/
     if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+#ifndef CONFIG_GICV3_ESPI
         return -EINVAL;
+#else
+    {
+        /*
+         * During domain creation, the dom0less DomUs code or toolstack
+         * specifies the maximum INTID, which is defined in the domain
+         * config subtracted by 32 to cover the local IRQs (please see
+         * the comment to VGIC_DEF_NR_SPIS). To compute the actual number
+         * of eSPI that will be usable for, add back 32 (NR_LOCAL_IRQS).
+         */
+        nr_spis +=3D NR_LOCAL_IRQS;
+        if ( nr_spis > espi_idx_to_intid(NR_ESPI_IRQS) )
+            return -EINVAL;
+
+        if ( nr_spis >=3D ESPI_BASE_INTID )
+        {
+            unsigned int nr_espis =3D min(nr_spis - ESPI_BASE_INTID, 1024U=
);
+
+            /* Verify if GIC HW can handle provided INTID */
+            if ( nr_espis > gic_number_espis() )
+                return -EINVAL;
+
+            d->arch.vgic.nr_espis =3D nr_espis;
+            /* Set the maximum available number for regular SPIs */
+            nr_spis =3D VGIC_DEF_NR_SPIS;
+        }
+        else
+        {
+            return -EINVAL;
+        }
+    }
+#endif
=20
     d->arch.vgic.nr_spis =3D nr_spis;
=20
@@ -145,7 +277,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_=
spis)
         return -ENOMEM;
=20
     d->arch.vgic.pending_irqs =3D
-        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
+        xzalloc_array(struct pending_irq, vgic_num_spi_lines(d));
     if ( d->arch.vgic.pending_irqs =3D=3D NULL )
         return -ENOMEM;
=20
@@ -156,12 +288,16 @@ int domain_vgic_init(struct domain *d, unsigned int n=
r_spis)
     for ( i =3D 0; i < DOMAIN_NR_RANKS(d); i++ )
         vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0);
=20
+    ret =3D init_vgic_espi(d);
+    if ( ret )
+        return ret;
+
     ret =3D d->arch.vgic.handler->domain_init(d);
     if ( ret )
         return ret;
=20
     d->arch.vgic.allocated_irqs =3D
-        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
+        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d))=
);
     if ( !d->arch.vgic.allocated_irqs )
         return -ENOMEM;
=20
@@ -182,9 +318,12 @@ void domain_vgic_free(struct domain *d)
     int i;
     int ret;
=20
-    for ( i =3D 0; i < (d->arch.vgic.nr_spis); i++ )
+    for ( i =3D NR_LOCAL_IRQS; i < vgic_num_alloc_irqs(d); i++ )
     {
-        struct pending_irq *p =3D spi_to_pending(d, i + 32);
+        struct pending_irq *p;
+        unsigned int virq =3D idx_to_virq(d, i);
+
+        p =3D spi_to_pending(d, virq);
=20
         if ( p->desc )
         {
@@ -198,6 +337,9 @@ void domain_vgic_free(struct domain *d)
     if ( d->arch.vgic.handler )
         d->arch.vgic.handler->domain_free(d);
     xfree(d->arch.vgic.shared_irqs);
+#ifdef CONFIG_GICV3_ESPI
+    xfree(d->arch.vgic.ext_shared_irqs);
+#endif
     xfree(d->arch.vgic.pending_irqs);
     xfree(d->arch.vgic.allocated_irqs);
 }
@@ -323,10 +465,12 @@ void arch_move_irqs(struct vcpu *v)
      */
     ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
=20
-    for ( i =3D 32; i < vgic_num_irqs(d); i++ )
+    for ( i =3D NR_LOCAL_IRQS; i < vgic_num_alloc_irqs(d); i++ )
     {
-        v_target =3D vgic_get_target_vcpu(v, i);
-        p =3D irq_to_pending(v_target, i);
+        unsigned int virq =3D idx_to_virq(d, i);
+
+        v_target =3D vgic_get_target_vcpu(v, virq);
+        p =3D irq_to_pending(v_target, virq);
=20
         if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->s=
tatus) )
             irq_set_affinity(p->desc, cpu_mask);
@@ -539,15 +683,22 @@ struct pending_irq *irq_to_pending(struct vcpu *v, un=
signed int irq)
     else if ( is_lpi(irq) )
         n =3D v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq)=
;
     else
-        n =3D &v->domain->arch.vgic.pending_irqs[irq - 32];
+        n =3D spi_to_pending(v->domain, irq);
     return n;
 }
=20
 struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq)
 {
+    unsigned int idx;
+
     ASSERT(irq >=3D NR_LOCAL_IRQS);
=20
-    return &d->arch.vgic.pending_irqs[irq - 32];
+    if ( is_espi(irq) )
+        idx =3D espi_intid_to_idx(irq) + d->arch.vgic.nr_spis;
+    else
+        idx =3D irq - NR_LOCAL_IRQS;
+
+    return &d->arch.vgic.pending_irqs[idx];
 }
=20
 void vgic_clear_pending_irqs(struct vcpu *v)
@@ -665,10 +816,15 @@ bool vgic_emulate(struct cpu_user_regs *regs, union h=
sr hsr)
=20
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
+    unsigned int idx =3D virq;
+
     if ( !vgic_is_valid_line(d, virq) )
         return false;
=20
-    return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+    if ( is_espi(virq) )
+        idx =3D espi_intid_to_idx(virq) + vgic_num_irqs(d);
+
+    return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs);
 }
=20
 int vgic_allocate_virq(struct domain *d, bool spi)
@@ -685,7 +841,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
     else
     {
         first =3D 32;
-        end =3D vgic_num_irqs(d);
+        end =3D vgic_num_alloc_irqs(d);
     }
=20
     /*
@@ -700,7 +856,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
     }
     while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
=20
-    return virq;
+    return idx_to_virq(d, virq);
 }
=20
 void vgic_free_virq(struct domain *d, unsigned int virq)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:09:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:09:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110778.1459820 (Exim 4.92)
	(envelope-from )
	id 1uuGHB-0001Kd-6P; Thu, 04 Sep 2025 20:09:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110778.1459820; Thu, 04 Sep 2025 20: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 1uuGHB-0001KW-3Z; Thu, 04 Sep 2025 20:09:45 +0000
Received: by outflank-mailman (input) for mailman id 1110778;
 Thu, 04 Sep 2025 20: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 1uuGH9-0001KQ-S1
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:09:43 +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 17803460-89cb-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:09:41 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by PA1PR03MB11060.eurprd03.prod.outlook.com (2603:10a6:102:4fc::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Thu, 4 Sep
 2025 20:09:39 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 20:09: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: 17803460-89cb-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F5Yfpl9ELsIxrMzm2p6cYPlBVZIOF42BaiEu0NRW/2pSbRAdjz5D9gzPVRxmT+29y8obWrek+4yUKgPPJahD8uRmS9xJmcRBrf3Xnwcy9ua5Kpbi8zaBnJvbdYX0gtoR9SnUaR8ZWBIOQr3fT0DfULz3LoeHoSjjVTBIgtrWx9dG8Z2MTKKoXlU4ZnHLrZuSLYbixIDDhoKAoI+mTKWp3GPNQJvct5L0TkfFASlJB073CsDRBtni0cSpBl7j2qs65Suyh9YjYZzigZGOuvA2CyRsWPxgt/E3uAYvsPx9EBLgA90Ie1mt8JHEg5Uc4Zw3OMXbADsk4yncWM38VwX3Pw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rbFw219gsz36VnFihYJZeueH79SxPMDz6q8rd9b98w8=;
 b=oo+PxVaXdowC8mvhLtMCPlpWvlM6YRk/GZwvDAB7dKgkBb0qiHxS2HaPVG0emtmCXJmDtjfuIqYK7DRlwMpPEq2Pkfz+RqQiXx5kGTMTCDb8iy3JUzpQYxhDB9vTv9z4sZvVnbdTp7XxoMb+61xuqnXtoB/rAUlCoIbagdkozTfpbOCBUzXREbHDg9uQvYZeq7U2aWHvwvdsjwUWUa627VqwoO/h/bd5VBSL+8isoSCOkfYvt7FILDUCeFEWenROpImL/6T7oKhKMz7uUEuQbcDibFoi9QPtW7howNnzHNEo+mWXdDAHlyZRPW68qAbJdacUqmn4Utbbkagi4c7aIw==
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=rbFw219gsz36VnFihYJZeueH79SxPMDz6q8rd9b98w8=;
 b=sfefW1d6A3OsFwr6veYFJfqVIBHLNx0waq/P0m6UGaJkWu8KNyyTQIXACRQ1WM62N67fDp9c0vlXXGLHEI0d5tKL8MrW3L5ZFn7xLQNHBZRt+ohaAePEY2v2l7fHEQwmostadmK7Vs/Cw7ylILIQhSoSFUQk61Z5MBICO+NoNGfP/SEh5en0Lk9ntUUjpqasA7E/cwQWwME1C/YV9Hb+sGbO9zDdr1QDudtAMYZwcFglME2+/upis4GFrpOBx2OpsTIGrzN5PmBwbi2Eykzc4oKk6oWTmVVKePYFT1+QVicIZlliPkb/8BAF2ag/9SPmJztbzSaFltX0QJ4C2rnLyw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <2cdcd8a6-0f14-4a4e-ac56-f0c33763ad53@epam.com>
Date: Thu, 4 Sep 2025 23:09:35 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen/arm: split set_domain_type() between
 arm64/arm32
To: Volodymyr Babchuk 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-2-grygorii_strashko@epam.com>
 <87bjo13976.fsf@epam.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <87bjo13976.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA2P291CA0034.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1f::7) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|PA1PR03MB11060:EE_
X-MS-Office365-Filtering-Correlation-Id: 21c9a591-63f3-45b3-3c74-08ddebeefa63
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?aGIyM3VzUm41eG9GOVVLL3NxNDhuT1F5QzV6cGxicE1taFl0NzhyY1Q5U3VS?=
 =?utf-8?B?eExWREVTSWNJL2NEb1VKT0t2UlBvYWdJNWFiOGtNOWtuejJrM2JSOE1kTDRX?=
 =?utf-8?B?bHB2OCtaK2wyVFNrakM4NWs2VU14NFNJY0h0emhaSG1LUWQ5M0FlT2drdEcv?=
 =?utf-8?B?QWV6c0ZQNDRrdzhWS0pSb1hvdmV1b2srYStnNTB0TXYrYnJTQnR6NXN6N2x4?=
 =?utf-8?B?S1ZLOURyY2MvR0JWQjYrSndvRGFxOWl6a0RkelIvSTNaSDZOSFZzR1BFejJ4?=
 =?utf-8?B?bStwTDJRZUdNdU45a1lvY0poUU1OaTVRSjEwTE5MMzVsekhIblBQNFpwT1ZM?=
 =?utf-8?B?d2dHTDlmbG9PZ3pScHJjVzFQbUFHV2JidklXMjAzZHYzb1dta2NBemMvNjRK?=
 =?utf-8?B?S2NOSzdGR2JHUloxUFBpWW9VUFVYd0pVT2I2TExBSVJzZllIU1M2VUxEZFdi?=
 =?utf-8?B?bGxWWVdvZm9UV0M0SERaZ2k5a2JFNjRhRG5lUmlpeDRLVzJlUUJ3cFhxVDl5?=
 =?utf-8?B?WU9WeVVUdjlLdHFLNXlTeXFCTW1lWVhoNCtabGhpdzNBNys1QVRPcVhLTGgz?=
 =?utf-8?B?SSthajRFT2NnVmJVT2xsQ2dLQytHNDV1eFpZWC96dS9CYklCTmV3VEJnVXJ3?=
 =?utf-8?B?YXh2TENsblBXV2VnZ0hURmRqZk5aVWE3SzlMODNQV1VQenVlMEtORFRRaUlz?=
 =?utf-8?B?STNVSlA2azNCcGlTV1RRUWpwcWhDY3ZsdWFkUjgxQ1ZnVHZXWk5RTUtJbWEx?=
 =?utf-8?B?LzRiMlc4aDZHNUxqWnpOSThXSnoxK1lpZ1NkVGJzMDZKbFNRbXBxTGZVdXc5?=
 =?utf-8?B?blNHRCs3Y3AwMEhnaWdzT2pBdG9LdUMzYzJkN25iaVRucUZFZnJhbFNGaUlk?=
 =?utf-8?B?VWNHTldJUjZTUWZNcDdNejlYU1BHWWpncUpQUVdRYkg0Z1hkdjVwMFNOaFVI?=
 =?utf-8?B?L1FMaEZIb0s2cjZlNnkwLzNSRTBUZk81eUxFZDc4Y3d2aTdZNmwzZUhGVmEx?=
 =?utf-8?B?Q3BjNU8vK0pCYlV0UmhMdHlFeXVKZjI3cmRHYkx4a0VBTS9KLzgvbUx6NFV5?=
 =?utf-8?B?dTJ4elBZbG83NWZheTFTV1hveGJhcHR6eGhMdjlDN2RVQ29TcEo2UjExNWNF?=
 =?utf-8?B?cHhyVFdzY3JiQmVKc09TeElxRElTVFR1eHhuRXp1ZVRGR1ZHd3FQb0UzR2tQ?=
 =?utf-8?B?T2l4ZlM5RjJvd0M2emtSeTIyVjAvNW9TL3VEeVZWQ3JmaUNnb2NycGJ3Vjl0?=
 =?utf-8?B?SzYvMDkvSU8wQmpDQSthTmt4Q2NuY2xlUUhTWVk2R0wvRUc5YmZBTlVrVURu?=
 =?utf-8?B?NmNzMXVxMC9nemJmWEE5dDBFRVIyOXVmbUd0WjI5R3hhVlkwZFIxbDNMV2Nk?=
 =?utf-8?B?Q3U2SlMvR002QTFoNEYzcHo2NFZEU0MzZGk2KzhXUmxHelppUVBzc0N4L1gv?=
 =?utf-8?B?ci9nTXE0eWZxQmxFeWFQNjFQS0FmeUQ5anBJaHRhV1o4cnhSSUFIcFlSV3ZD?=
 =?utf-8?B?NEV3YmtOSkw4ZmRGRFJqMmNQNmovT2p1enVKczdzQmNoWjhVNUhEQVJxUFVx?=
 =?utf-8?B?dGN3QWpERHJZQUZZMXdKeXBlMkNRejl5ZVVGMkF0M1hhMzMwakdRYTR2Tjlv?=
 =?utf-8?B?NEZ0c3I5Z1hEVTJsK1ZPTHEySzlFd1grQk1BQmsxZG9NRGdURXFlZEQxZ3h6?=
 =?utf-8?B?TE4wMlB6S2JQenhrRUZPRHorQ1VKOTczcEh5Q05KTUc1R0xURlZxU04rSEp1?=
 =?utf-8?B?OXFTaUo0R1Y4dHN5YUlPMHYzeDRBMS9BS1dsNHM0VnZYZ1ZBeC9ESE9zV1U5?=
 =?utf-8?B?aVp4WERxOEgzYTJnVldqcjZ6TTlIL1ZnL2xVL2ZhbTI4dSsvZGFrL0F2V2Vu?=
 =?utf-8?B?eHJiNzlFUmJXeDV2blJ1RzFHSGNPdlFCQ0ZBdFhYMmpySVRJeWRveUJWbFdJ?=
 =?utf-8?Q?2cbECcH/3Ck=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dUV0Wk5pZzZPU0l6QmdLeXcrbzBKWVpReHNxZEN5RGovUXZacW5aOVpYZmo5?=
 =?utf-8?B?RVlqbFRtQ0h5R2I1Nm5jakJkUlJvY0M5L3lpK3BQeVRWVlRCelNFbEl2YnM4?=
 =?utf-8?B?eWtOUXMzVFRWMTAzWk9BS2puQVVaOWM2b1Z1VEs0emJUZVpLanBXNVRJVlQ3?=
 =?utf-8?B?L0F6Z05qU0RpV0RKa3gvSzNtNnhoVnd6LzUyK1pCYjNwamhLellmcmRKTWtx?=
 =?utf-8?B?L2lHOEdza0JHdTJObERsZkY3MTUyZmE0YnJpaGhQRWJCaUxSUjdrOUM2N2hV?=
 =?utf-8?B?UFRhMmNOdGJDTE55cUdKWkU1aUlMV25nSHFRYTNlRnAxaUtRV1FuRU0za3RH?=
 =?utf-8?B?NVpkTmh5SG5KaVRJMnV6MklmcDRjUmVYdlI1a0Nva3o4TER1RHNrZnFNK1No?=
 =?utf-8?B?STZPN3BqK2tzMTZCUllQaDQ0L3hTa1lmSllTYlFNQWJrWW91aUQ3MTdSTS9B?=
 =?utf-8?B?YkFIdjdqZnBZOHhiK1d3ampSOWJzdFY5YkNNMm5MTXZuUmtNZ1RNRWNPOGdh?=
 =?utf-8?B?bnlEcUdLK00vOGFka2wxcm9DL3FKK3I2SDVhL1FDU21vYjJZTDBkQmU1VFln?=
 =?utf-8?B?TTVwU05Db3VnZzlPVzBlZ2dOZjN4K0Y2UXVzWHczS1o1Z0M1WFBPZFNKclox?=
 =?utf-8?B?dlRYWU5nNGpEMGRmM0xObUN0dUp3WHltTjVpT0ZNYUtnaFl4K2NuRTBUUzhm?=
 =?utf-8?B?V01aeVlCZXNudk4vamZxNXBXcVJKNkVLaUYyNElqV1dUUlg1eFVBVlNISW5G?=
 =?utf-8?B?cyt6QVkzNklxWm1UQzgyOTY4VFEwcXpISEQzSkI3dm9LNUxVMzkwYk9ZbEpp?=
 =?utf-8?B?UVlUVzhyejc1Wlh6UWcvUW5wNDZPN3VNOEdURndRUkVPSDdZRDNXQkZmOThL?=
 =?utf-8?B?Nk5YWGVPQXpNMVlrUlI5M2NhbUxObE5SWEhFWEpzT2I5dkJrVDk4c09JTy9S?=
 =?utf-8?B?czhyWHJsTkxiUDdQem84QzVEcExBcFlaeVg3QVJhLzF6djRlZEFIbzd5WlZO?=
 =?utf-8?B?WG9Ld3VaeVBOR3RBSDlJVTVnR2xNS3NvdWtBc0hyUURWYnZCZnVWdU9id045?=
 =?utf-8?B?Sm1zSk9PWkFVS0ljbmFGZlBvMG1ackJsSnFqV2JFRzdHVjFJWVF1VkpKU2c2?=
 =?utf-8?B?UFk1bThxb2xzdDhyTHhXZFFsUy9EVU05cXpPeWNNa1Rpa0dIVHQ3WmtNN0kw?=
 =?utf-8?B?bnRadWZhMFJqaDNRNGhFZ00rcUdTSHZ1UjRZOW1rNWlubGpHQXp3RHZiTHB6?=
 =?utf-8?B?MHg5b1QrUlBBemJqZXZZMlJmYkpQSUU3SUhhZVdBQVlVSVF1WFRnUEh3U2o0?=
 =?utf-8?B?WHhzcXZlang0MDVUUCs5K0VUS1Y0UlBIQlllcDVwQXRoTGF6ekt2UHFUUG4y?=
 =?utf-8?B?S2lDSTArbUo4WXJBc3RYbkp3RzVtNlhtTENxQXB1Ulc0YXVnMjdpZk4zNGhm?=
 =?utf-8?B?K3VzVUJrNTJLQzYvUjdWU3FEeW00ZGZqbG8xeWlrSDB3cThEMUlEd1ZOWkpj?=
 =?utf-8?B?UjZSQ0RNZjYrUUhyTnlKUGVyN2U1eU5LczhZMlRRWjNpZFpYd3doZ3AxUlZq?=
 =?utf-8?B?TStPL0c3Z01yZWJ1MVZaay9wWjRZMlJZdEJVZXh6Z1VMZlViT01Sb1d2NDlJ?=
 =?utf-8?B?UFZ2ZkprY2VRWGM0V0V6VUEycy8vOEQ3WEkxdGprUXZGbWR2MEJYaTJzWVRH?=
 =?utf-8?B?ZXd4ZzI3WllvSVVkRUF3R2RVakVIYkU4UEEzNTMyWjJNbFN2ZXZqN0FMTDlt?=
 =?utf-8?B?NTUyRWpackpEVjN4OUFjN0s3cEt0Nk4xS3E1VFBIcDdxU3JlRUp1UXRlZzlP?=
 =?utf-8?B?dyt2WTFjc1ZJVjVuRU91VUN2T2hMcjNibDBRUUpqc0xtcUlnV3FNQUdpWXNQ?=
 =?utf-8?B?ZmVIYU5ZbkR6QzVNSjd6SUxwamVuVDk1N25UUUFGSjMxN01mSWZJWTZWREs3?=
 =?utf-8?B?cU1pd1k1VWsrd2JhT3pGWTFvSWd1ZGtMY1pxSmVCdWpuaUxqSlJYREgyNFJH?=
 =?utf-8?B?RFhiZTVjY1IweHR5YzZMRHVhZTRNZkIxdXdDejZKR3dQV0R1WHBhOWdzT3li?=
 =?utf-8?B?ZlNSWEdza0k1dGxBc09YbERETWc2N2REbzJxUnZOS21qZGMzSzJtdE5jRmk3?=
 =?utf-8?B?ZWtwbmFDeE1IdE42b1kwa2xvQVRDcXZWUGE5UlBZbWh5a3BjM1lrRUxIOWIr?=
 =?utf-8?B?UEE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 21c9a591-63f3-45b3-3c74-08ddebeefa63
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 20:09:39.3975
 (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: IRwqQ98QWb4UcU8xNsUjXnc6Lise2DF4Io4jr9yaVuITH/L9Vxgc8bM6m6ylw7zBGlnqu1GOQw54XI21D+SrLtXXJ8gxmziAgHUx5RdhM1w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11060



On 27.08.25 03:22, Volodymyr Babchuk wrote:
> Hi,
> 
> Grygorii Strashko  writes:
> 
>> From: Grygorii Strashko 
>>
>> Split set_domain_type() between Arm64/Arm32 sub-arches as
>> set_domain_type() implementation is going to be extended for Arm64.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>> v2:
>> - no changes, rebase
>>
>>   xen/arch/arm/arm32/Makefile       |  1 +
>>   xen/arch/arm/arm32/domain-build.c | 22 ++++++++++++++++++++++
>>   xen/arch/arm/arm64/Makefile       |  1 +
>>   xen/arch/arm/arm64/domain-build.c | 24 ++++++++++++++++++++++++
>>   xen/arch/arm/dom0less-build.c     | 14 --------------
>>   xen/include/xen/dom0less-build.h  |  8 ++++++++
>>   6 files changed, 56 insertions(+), 14 deletions(-)
>>   create mode 100644 xen/arch/arm/arm32/domain-build.c
>>   create mode 100644 xen/arch/arm/arm64/domain-build.c
> 
> Is it really worth to create two more source files just for one
> function? Maybe it is better to use already existing
> xen/arch/arm/arm*/domain.c ?

It seems a common approach used for splitting ARM subarch code.
code from arch/arm/A.c goes in
  -> arch/arm/arm32/A.c
  -> arch/arm/arm64/A.c
(just "-" is used vs "_")

This approach also simplifies any further code split (there ~250 CONFIG_ARM_64/32 ifdefs).

One additional thing, I probably missed, is that "x-build.c" should be placeholder for "__init" code only and
so added as "domain-build.init.o" in Makefile.

> 
>>
>> diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
>> index 531168f58a0a..0fd3f5272361 100644
>> --- a/xen/arch/arm/arm32/Makefile
>> +++ b/xen/arch/arm/arm32/Makefile
>> @@ -6,6 +6,7 @@ obj-y += cache.o
>>   obj-$(CONFIG_EARLY_PRINTK) += debug.o
>>   obj-y += domctl.o
>>   obj-y += domain.o
>> +obj-y += domain-build.o
>>   obj-y += entry.o
>>   obj-y += head.o
>>   obj-y += insn.o
>> diff --git a/xen/arch/arm/arm32/domain-build.c b/xen/arch/arm/arm32/domain-build.c
>> new file mode 100644
>> index 000000000000..e34261e4a2ad
>> --- /dev/null
>> +++ b/xen/arch/arm/arm32/domain-build.c
>> @@ -0,0 +1,22 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#ifdef CONFIG_DOM0LESS_BOOT
>> +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>> +{
>> +    /* Nothing to do */
>> +}
>> +#endif
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
>> index 6491c5350b2e..3272fe7e4ca2 100644
>> --- a/xen/arch/arm/arm64/Makefile
>> +++ b/xen/arch/arm/arm64/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
>>   obj-$(CONFIG_EARLY_PRINTK) += debug.o
>>   obj-y += domctl.o
>>   obj-y += domain.o
>> +obj-y += domain-build.o
>>   obj-y += entry.o
>>   obj-y += head.o
>>   obj-y += insn.o
>> diff --git a/xen/arch/arm/arm64/domain-build.c b/xen/arch/arm/arm64/domain-build.c
>> new file mode 100644
>> index 000000000000..3a89ee46b8c6
>> --- /dev/null
>> +++ b/xen/arch/arm/arm64/domain-build.c
>> @@ -0,0 +1,24 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#ifdef CONFIG_DOM0LESS_BOOT
>> +/* TODO: make arch.type generic ? */
>> +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>> +{
>> +    /* type must be set before allocate memory */
>> +    d->arch.type = kinfo->arch.type;
>> +}
>> +#endif
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>> index c8d07213e247..58f77628df1f 100644
>> --- a/xen/arch/arm/dom0less-build.c
>> +++ b/xen/arch/arm/dom0less-build.c
>> @@ -236,20 +236,6 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
>>       return 0;
>>   }
>>   
>> -/* TODO: make arch.type generic ? */
>> -#ifdef CONFIG_ARM_64
>> -void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>> -{
>> -    /* type must be set before allocate memory */
>> -    d->arch.type = kinfo->arch.type;
>> -}
>> -#else
>> -void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>> -{
>> -    /* Nothing to do */
>> -}
>> -#endif
>> -
>>   int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
>>                         const struct dt_device_node *node)
>>   {
>> diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-build.h
>> index 408859e3255a..3e81d8ba3a47 100644
>> --- a/xen/include/xen/dom0less-build.h
>> +++ b/xen/include/xen/dom0less-build.h
>> @@ -57,6 +57,14 @@ int init_vuart(struct domain *d, struct kernel_info *kinfo,
>>   int make_intc_domU_node(struct kernel_info *kinfo);
>>   int make_arch_nodes(struct kernel_info *kinfo);
>>   
>> +/*
>> + * Set domain type from struct kernel_info which defines guest Execution
>> + * State 32-bit/64-bit (for Arm AArch32/AArch64).
>> + * The domain type must be set before allocate_memory.
>> + *
>> + * @d: pointer to the domain structure.
>> + * @kinfo: pointer to the kinfo structure.
>> + */
>>   void set_domain_type(struct domain *d, struct kernel_info *kinfo);
>>   
>>   int init_intc_phandle(struct kernel_info *kinfo, const char *name,
> 

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:09:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:09:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110779.1459831 (Exim 4.92)
	(envelope-from )
	id 1uuGHG-0001Zb-DX; Thu, 04 Sep 2025 20:09:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110779.1459831; Thu, 04 Sep 2025 20: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 1uuGHG-0001ZU-AL; Thu, 04 Sep 2025 20:09:50 +0000
Received: by outflank-mailman (input) for mailman id 1110779;
 Thu, 04 Sep 2025 20:09: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 1uuGHE-0001Yl-S3
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:09:48 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b000b5b-89cb-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:09:47 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by PA1PR03MB11060.eurprd03.prod.outlook.com (2603:10a6:102:4fc::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Thu, 4 Sep
 2025 20:09:45 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9073.026; Thu, 4 Sep 2025
 20:09: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: 1b000b5b-89cb-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bK90QBglhrI2pWx5q7wBDanZirtvzVDpIPEHtjeuqQfFXFschXONnCNcsXei/flmja4f8Ff8ys1kZdaR8Yn6GisSk2D1AxqaTU8eFv0vMovkIErO7TsbggIZeym/9ajEmSYol9d5yzvQJrDziJUoiEcy8hXoBUmkXLoQ87xveo3P+tn2ruWzwBdlSCw4jK5nWvwJlyPKeUwloyhWPbe0Ynz0qBKO5Nu5qq9zzmBv9RrYX+vU0qCDVIpccl0AApChM+cJAG83t965Et4YDMcZY3WCXexMvlPYKYh+N9hzQaVO9wZbA37rFveyq2v8CDPUZN3rYEq46J+SrNT7Oh/Kmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CCN9x4JRfuUCaCtfz5jfZntfsG24fKF4Hhqu4l4kko0=;
 b=ttNL7zipo4bcXnRdqFVi4S8p2L3/c/3JqfuIvIMgdCnTG5hAttSNHlxKNesV5zI513coQZK3MipkovY7D+EZAOIjIPIsh3j9VE3nsVGZhipRthU+yWwLTXt0PITcH33a5QOXVxrAohptrvYq5ntxzZ7E7U1S6+kanr9oAIbVqTAdNEn1RyMXbJtblBarl9p8Ks33/uDgXuwQc4kXpXSAe0sDbawhbO/qXuscBkiiyGKw/ai9SN0iSjRQ2aT6xJ8PQICg5OoTNkC+eMxHiTFuncL52+V88r+9EuN3mfGyP5oZFR10oC0igtaRDQSbiqH50kLoJKZ280E/2XZiPiY1oQ==
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=CCN9x4JRfuUCaCtfz5jfZntfsG24fKF4Hhqu4l4kko0=;
 b=iMlME2k0mTdUpDomSvx6NwXWkeYN+/5DR2G5lME5RHE7hDRHjT2AP25Pessc6vJZT62+a1RoYzloJqBcR8VkOV7UeJyzKBsA2eyNu2sD3rnux/5wCPjplxYoCbCKGXi/KaEr53+sYvhkoSZXs/B0GJJ1U+fhHHJQTzbqp5wp482WriUVNffvgtr5+MFzxzDPe99PHSXTeyMIrdyqUZgbjHld+m/2UemSwYUoPwQ1cAZSltmEZTu/7jnCPAJeJCXVm6QiI2Z1x0qqriDE4H2B69VqzaUR+3KuNJGW2LgVRTA1iuLPVFPWqcjeR3CGnj3TOhmhXnYH4wfogp7eEuAsfw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <540abaa2-9946-40b8-bf49-b54e4f7a1393@epam.com>
Date: Thu, 4 Sep 2025 23:09:45 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
To: Volodymyr Babchuk 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
 <87ms7l39gl.fsf@epam.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <87ms7l39gl.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA2P291CA0034.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1f::7) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|PA1PR03MB11060:EE_
X-MS-Office365-Filtering-Correlation-Id: db645ccd-ac78-446b-3a00-08ddebeefe22
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?akNWZkRXazZySFhxRWNzVXVWMVl1bFAwd3JpaFBrMmJ1QzJabllhclN1Z2Nu?=
 =?utf-8?B?U1lGVUZEQ2tTMFZxbUw1L0dlT0QrWG9GR1FKMlA2eGw2U0NmdFR3eXA2VFRv?=
 =?utf-8?B?anl0cHRtUW1EalU5U0JsR3l5UDVGU1BJakpjNHJJVlNiK01CbjZ0NW5FSDdG?=
 =?utf-8?B?dkxCNXZ6cTBySWFPcW84dTlxSnR0ZmxrQ0RydkkwTm5wY3B2WGNmWGt1RWti?=
 =?utf-8?B?Wkg2WkIwQUFmemlONGVnaWpzdDdFN3poZkNkZ3BBbVB3M3N2Wk5RcVVrZVF2?=
 =?utf-8?B?ZXdrRzRjQ1VoV3NlTXl2NWFUQ2l6S0Y2YmI0d3pUSkphcGNMVnNQc2RCeERj?=
 =?utf-8?B?M2R6UVR5TnZHUjNaNXUwSG1UcHNFYXFka21yOEtnUVFzVEZ4ZG5teTN3QWdX?=
 =?utf-8?B?YytZaSs0RVJaelBKWG0rdk55ZWdiU3gya1dXM1BzcmZ5aEQ4RXd0OS9mUDlX?=
 =?utf-8?B?bExCYU1iQ21UaWlMSU4vYS90SmFFSC8yZ0pTa0lNNU9XcnlDYUxjNmJRRE5a?=
 =?utf-8?B?anBialM3cmQzRlBhUm1sM1UvbjlJdG0vTGxQaU5qTloyRk5LR09rYndOSlZX?=
 =?utf-8?B?SDg0YTNDYWE3dE9UUkZKYXoxRlhZTW54ZW5TaW8yQk0zZnNJN2toN1piUE1G?=
 =?utf-8?B?QjUwY2x2SE5HQ05iYnFHSnh1cWIrRGo5SWtDVUFiUWZOSUJFVnNaWXVBSjR3?=
 =?utf-8?B?Mit3eTVWL2loUysxYTJ5NE8reHAzN2Fvd01jY2U2ZUZKbWQ0L3VVNEJaaHg4?=
 =?utf-8?B?TFJoUTlCU01mdUs2VExPeWhFOFhsSlQzWDRTYzVQVW16UFdsNFhoRUFXNHBY?=
 =?utf-8?B?Z3JGaWdPUnJNSTVJcEVhTThNMHRiRlFOdldnOTcwcjJqblFsNmMwMGJLQ29j?=
 =?utf-8?B?ODIxcUUzVFlYdTJvSzJUMFY0SWQ2dUJ6ZWYxNmhVQzRiTVA1TE1UL1Rqb1U1?=
 =?utf-8?B?d1k5enl2cGZVYUtvOUNDcWFGNUVSdHVmZndGajgxSVlmUUdkWnhBVlV4c1ZD?=
 =?utf-8?B?RThtVSt3T3dqblJzTXpBWHFHODU5U2YxSGdTM05ONWs1cGphNEF2dWcyby9U?=
 =?utf-8?B?QXl2RitZZGVIQ051M1ZseVBWZDFWTlFuQXg5aVo2RDNVVmR3dXBJUDA0NCtL?=
 =?utf-8?B?STRpcFA4eTR6MW9vblFuSVRpUkYxVGRCWXA0ZlhsSjN5UDNIaXVCN2ZNSzlD?=
 =?utf-8?B?anBpQXRqLzcrWUNTZ3FCbXdXMlNhc0gyVEJxYk56dDZidzgyRkR4NGJzOVN1?=
 =?utf-8?B?OTkwY2VkaitaSVp3UWJUZ0NzTVNHeTllNHB6TnZGZFBnMFdGOXVyS3JzVEFn?=
 =?utf-8?B?NTFJZVM2a01iMlZkcVNTQmZkTCs2anUxVFJqazhqdEd1UDlBQ3F2cStiMWlN?=
 =?utf-8?B?US9UZ0hLb0RaejUwa1ZoLzRYbjYzc2RYZHlZU3Zqb1ZXODVGQVpZMTlhU2d4?=
 =?utf-8?B?S1owVkR1Z01oNTVUMHN2Uk5Ya2RDQWpTeC9sOXJUTEZ4bjJhckRwTFJEWVdt?=
 =?utf-8?B?TFNaeE5jME9Wc1V1akhZajJWQmVncWRYd3dLdW9Ea1J3YTNqbjc5QWV3aWt3?=
 =?utf-8?B?VmhWMTVrbXlOWjJHU2NOckRhdDRvTEFHdmhyRGRmbTJ2YXArWVRqME1lb1Vz?=
 =?utf-8?B?WkhtS3RqczVvMm1talNPNkY5My9NL2dlVzFxbUF6WjFnVHVLaVJpRWdLUXRa?=
 =?utf-8?B?ZFp6QWhpYjBzQzZCZ3NUbU8rYXcxU2hNRFNJUlJQdGdZSFRVd1R2ZHFmcmt4?=
 =?utf-8?B?S1kvbGlxZ3BTa2hPWEpiUC9ZYXB1NCtKamYrTVg5NHhMOHEwdUxrN1Uxblg5?=
 =?utf-8?B?VlBORVdvelhOSXVOaFZpUWovL1Q1dFJyK2JDeHVzcHR6YTVBdzA0RWtHS2Mz?=
 =?utf-8?B?cUNGanhaVjJkNVJuYlNXMzh0eE1MSkFRVVBhQ2t2c0RTS2c9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bWY5Z2xSNWNwZWdPcDVzVGdHZm9mb0dRTHQyV3h6a25RY2ZHcjk3N0YvOEpr?=
 =?utf-8?B?NkN3V243V25zOE9RNk9nNE05azBrUjJSUWw4bVZLMFFiWTk0b1Z0NjFzd2kx?=
 =?utf-8?B?RjFxbUFSQjhsWFEvdUliWURMQk9aeE16eEcrTGswalVWZXJuQlhKSmVqMlhr?=
 =?utf-8?B?NVYrKysyYzRWZk9nU0U1cUUzcmp0UzBPRU5qQlNsSFhxRW9rS1lPQW15QXFZ?=
 =?utf-8?B?UWk0UkNuV1d3KzU2bVNhMENkUlBqam1lQnQ5SGtJVVFPenNKK3RvSE9sNFhp?=
 =?utf-8?B?cjBUWG1Tbi8vaGt5Q0d5Q2Voc3VNRVJyVVQvcFJyZjlBWStSUXZCeVdmbHBC?=
 =?utf-8?B?LzJDR1hQVlR1alpuVUVmRWZTVlFkQkZKSmlxOGZqTm90Y1dKRDQySHdPa3d4?=
 =?utf-8?B?bit6cmhvZXRKSUlUQkZ3UnBBSDlVZTFQUCs4TkVIcVV3bE0wTHR0d1RBclV5?=
 =?utf-8?B?TDNLdmpSU1dLUGdDSjJONU9zK1IxSVVnaFpBcUh5eUgyRldYSkFaaUpoUFp1?=
 =?utf-8?B?dEE3TlFxVTVBcG9Md1NoWE9BQkFJd29UNzdqMGRKYjVwc2FvTU5OOFJjWGw2?=
 =?utf-8?B?WFlRbXgyUS85T2pQbFhyNktSWHorMklQYVc5QzNkWUIzcjVDTHJtTk5WN29H?=
 =?utf-8?B?TTdtUVdqYlF1SkhnSHBrQTN5SlpWRmg3R2xKUkRYdWw0OGIyNTFmNXRNU1U0?=
 =?utf-8?B?d0IrREJPeUtza0JBK1hCSS9sTkM4TVFiNVBnblRQNE1ZbDllQWJ0UDRsQWtM?=
 =?utf-8?B?TkdPMnE0ME8xQ3lrL1dUWS92WjNSUU1rbVdFSHJrZVE1dE5hQ2d1anNJUmVt?=
 =?utf-8?B?OTZhU0NLZ2F4SCtsamd4c2FHOFZrbEl5Y1FodE5QT0dyOTFVYVI5OHNweWNX?=
 =?utf-8?B?VG02dzZRK09LNGhhY0tjUENIRGxCd0o1N0FkaUxTRnFzcDFFS1k1dGNwNzk1?=
 =?utf-8?B?MDhhdFRJWVNVSWpzRFp5eXhENzVmSlh6WTdLZ1BxYXpPcVlISkxsdFhRYWRH?=
 =?utf-8?B?ZW5GN2drNGRoRko4UEg0UVRrWDJsRkp4cEVGcW9Qd01JVVNMZ1VkdWhQUEJp?=
 =?utf-8?B?eE1maW4rejh0Q2lvVXhFZWdnL2N3T0FDRCtuT3U4RGdrZXVKSmFid3IxY2Q2?=
 =?utf-8?B?Q28wME5DRnhGSmprZUxyRWRpOXNuTmRWcHNqU3hrTWR2Q2hZU3pnOExTVVRx?=
 =?utf-8?B?NzNYU3hSQ0lHWUdMVW5HNktvVmtGT3lWS20wWWFlZHV2T25SMHl0ZXFsUHRW?=
 =?utf-8?B?aGRoTWtSUmVjOXl2bmxwS3d6ZDFlZ1hIRHJNT0tSL2doOEM3WmwvQ2FjYlZk?=
 =?utf-8?B?c1phelpNWExHdmttMXg5cFJGNDh6eEtZVlRNYjRhbHNzTE1Uanp5S2U2dWZG?=
 =?utf-8?B?V1VUSlJsUTZUMnNmSmwzYklUc0xpU0ZtbDkyMmdhWTY3eU1jKyt1UWU1aVVp?=
 =?utf-8?B?T2hpSWhWczRCdi9lYnhlNzlIVHhTeUNmVG1MT3FPNHlJVFljNFpyTWpiNzNF?=
 =?utf-8?B?RE5pY3JkSHRKRTMzenhDd0R1Vm4xNTJCa1ZRMHJwNnBhaFZTcS91L1R3WkRJ?=
 =?utf-8?B?WUlPL2QyK09YQTc4dDBDYzR3bFdKZm93Q0V3d0JqcXdoQ0UwektLTEc4L0tT?=
 =?utf-8?B?UVgzVG5wOUphK2lucmZ5bTZhZnhwdU0zbWFleVNlejJLaWM0dXFQc3A4cDN3?=
 =?utf-8?B?RUcyZlNxSEl6UjR5THozSHBBT2RUNXBMTzVYelo5MGZublY0R2VQQXZQU3pu?=
 =?utf-8?B?M3QzNFpmaWtmUkt5MlFaVVdBT3JtdVprK0o1dEkzZlAwT1pwemkwTkR1ZHJ2?=
 =?utf-8?B?aUxodG5zbUVkQTROSU85aXRmUVNiOGx1R0xyMkg4dytUN2MvTHB5RXV5czlm?=
 =?utf-8?B?MHIwWUREVCtiSmpBMU9xMW9Sa1pteENNbzl1enoyWlZJZUVrWGZSOW9zOTJM?=
 =?utf-8?B?VlA0NGVKQVJCZG9pSlI1bytRbE5YN21TeTJMaVpoVjk3MmFZeGwxQ1dCTm1l?=
 =?utf-8?B?U1hFc3N5OWFJZUpkWXlyOG9oN21uRWp6d2IvTXhHS1BRUGdNYUV4OTZZR2ho?=
 =?utf-8?B?a2MyRVpjVHFHbWZtcFVvUlhuZlZEbG1jcm9hV1JYUE53ZWkyMWxra1RYSDNM?=
 =?utf-8?B?eDVvdnZobnByVFNsY2VSNEZKeGpMc1BqUmlBV0lzaTRBeUlFb3lSd3BKR2Q5?=
 =?utf-8?B?T0E9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: db645ccd-ac78-446b-3a00-08ddebeefe22
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 20:09:45.6266
 (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: r9vOp3PdeJmkAfrdytJ3YYMRCW0FUQMKiq+MhCBI/idFOeNYLtaBbG3EIC3gGNuB4/pq+84V9r1M7FCSKDEWKd2+xdfsVU/GldMaBAHiosE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11060



On 27.08.25 03:16, Volodymyr Babchuk wrote:
> Hi Grygorii,
> 
> Grygorii Strashko  writes:
> 
>> From: Grygorii Strashko 
>>
>> Now Arm64 AArch32 guest support is always enabled and built-in while not
>> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
>> support might not be needed (Arm64 AArch32 is used quite rarely in embedded
>> systems). More over, when focusing on safety certification, AArch32 related
>> code in Xen leaves a gap in terms of coverage that cannot really be
>> justified in words. This leaves two options: either support it (lots of
>> additional testing, requirements and documents would be needed) or compile
>> it out.
>>
>> Hence, this patch introduces basic support to allow make Arm64
>> AArch32 guest support optional. The following changes are introduced:
>>
>> - Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
>>    Arm64 AArch32 guest support (default y)
>>
>> - Introduce is_aarch32_enabled() helper which accounts Arm64 HW capability
>>    and CONFIG_ARM64_AARCH32 setting
>>
>> - Introduce arm64_set_domain_type() to configure Arm64 domain type in
>>    unified way instead of open coding (d)->arch.type, and account
>>    CONFIG_ARM64_AARCH32 configuration.
>>
>> - toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 is
>>    disabled.
>>
>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>    AArch32 is disabled.
>>
>> - Set Arm64 domain type to DOMAIN_64BIT by default.
>>    - the Arm Xen boot code is handling this case properly already;
>>    - for toolstack case the XEN_DOMCTL_set_address_size hypercall handling
>>      updated to forcibly configure domain type regardless of current domain
>>      type configuration, so toolstack behavior is unchanged.
>>
>> With CONFIG_ARM64_AARCH32=n the Xen will reject AArch32 guests (kernels) if
>> configured by user in the following way:
>> - Xen boot will fail with panic during dom0 or dom0less domains creation
>> - toolstack domain creation will be rejected due to xc_dom_compat_check()
>>    failure.
>>
>> Making Arm64 AArch32 guest support open further possibilities for build
>> optimizations of Arm64 AArch32 guest support code.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>> changes in v2:
>> - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 support
>> - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with any
>>    initial domain type set (32bit or 64 bit)
>> - fix comments related to macro parameters evaluation issues
>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>    AArch32 is disabled
>>
>>   xen/arch/arm/Kconfig                    |  7 ++++
>>   xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++--
>>   xen/arch/arm/arm64/domctl.c             | 16 +++++----
>>   xen/arch/arm/arm64/vsysreg.c            |  9 +++++
>>   xen/arch/arm/domain.c                   |  9 +++++
>>   xen/arch/arm/domain_build.c             | 21 +++--------
>>   xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
>>   xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
>>   xen/arch/arm/setup.c                    |  2 +-
>>   9 files changed, 119 insertions(+), 26 deletions(-)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index a0c816047427..bf6dd73caf73 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
>>   	help
>>   	  This option enables PCI device passthrough
>>   
>> +config ARM64_AARCH32
>> +	bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTED
> 
> But aarch32 guests are supported... I understand that you wanted to say
> "Disabling aarch32 support is unsupported". But currently this entry
> reads backwards. I think it should be reworded better. But I have no
> idea - how to do this.

I think "(UNSUPPORTED)" can be just dropped. Is it ok?

> 
>> +	depends on ARM_64
>> +	default y
>> +	help
>> +	  This option enables AArch32 Guests on ARM64.
>> +
>>   endmenu
>>   
>>   menu "ARM errata workaround via the alternative framework"
>> diff --git a/xen/arch/arm/arm64/domain-build.c b/xen/arch/arm/arm64/domain-build.c
>> index 3a89ee46b8c6..5951f002e3af 100644
>> --- a/xen/arch/arm/arm64/domain-build.c
>> +++ b/xen/arch/arm/arm64/domain-build.c
>> @@ -4,13 +4,55 @@
>>   #include 
>>   
>>   #include 
>> +#include 
>> +
>> +int __init arm64_set_domain_type(struct kernel_info *kinfo)
>> +{
>> +    struct domain *d = kinfo->bd.d;
>> +    enum domain_type type;
>> +
>> +    ASSERT(d);
>> +    ASSERT(kinfo);
> 
> I don't think there is a sense in asserting that kinfo != NULL after you
> dereferenced it retrieve "d"

right

> 
>> +
>> +    type = kinfo->arch.type;
>> +
>> +    if ( !is_aarch32_enabled() )
>> +    {
>> +        ASSERT(d->arch.type == DOMAIN_64BIT);
>> +
>> +        if ( type == DOMAIN_32BIT )
>> +        {
>> +            const char *str = "not available";
>> +
>> +            if ( !IS_ENABLED(CONFIG_ARM64_AARCH32) )
>> +                str = "disabled";
>> +            printk("aarch32 guests support is %s\n", str);
> 
> XENLOG_ERROR?

ok

> 
>> +            return -EINVAL;
>> +        }
>> +
>> +        return 0;
>> +    }
>> +
>> +    if ( is_sve_domain(d) && type == DOMAIN_32BIT )
>> +    {
>> +        printk("SVE is not available for 32-bit domain\n");
> 
> XENLOG_ERROR?
> 
>> +        return -EINVAL;
>> +    }
>> +
>> +    d->arch.type = type;
>> +
>> +    return 0;
>> +}
>>   
>>   #ifdef CONFIG_DOM0LESS_BOOT
>>   /* TODO: make arch.type generic ? */
>>   void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>>   {
>> -    /* type must be set before allocate memory */
>> -    d->arch.type = kinfo->arch.type;
>> +    int rc;
>> +
>> +    rc = arm64_set_domain_type(kinfo);
>> +    if ( rc < 0 )
>> +        panic("Unsupported guest type\n");
>>   }
>>   #endif
>>   
>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>> index 8720d126c97d..4f0f143daef8 100644
>> --- a/xen/arch/arm/arm64/domctl.c
>> +++ b/xen/arch/arm/arm64/domctl.c
>> @@ -13,6 +13,11 @@
>>   #include 
>>   #include 
>>   
>> +static void vcpu_switch_to_aarch32_mode(struct vcpu *v)
>> +{
>> +    v->arch.hcr_el2 &= ~HCR_RW;
>> +}
>> +
>>   static long switch_mode(struct domain *d, enum domain_type type)
>>   {
>>       struct vcpu *v;
>> @@ -21,14 +26,14 @@ static long switch_mode(struct domain *d, enum domain_type type)
>>           return -EINVAL;
>>       if ( domain_tot_pages(d) != 0 )
>>           return -EBUSY;
>> -    if ( d->arch.type == type )
>> -        return 0;
>>   
>>       d->arch.type = type;
>>   
>> -    if ( is_64bit_domain(d) )
>> -        for_each_vcpu(d, v)
>> +    for_each_vcpu(d, v)
>> +        if ( is_64bit_domain(d) )
> 
> Do you really need to check domain type for every vCPU? I think that
> original variant was better.
> 
>>               vcpu_switch_to_aarch64_mode(v);
>> +        else
>> +            vcpu_switch_to_aarch32_mode(v);

Do you mean like below?

     if ( is_64bit_domain(d) )
         for_each_vcpu(d, v)
             vcpu_switch_to_aarch64_mode(v);
     else
         for_each_vcpu(d, v)
             vcpu_switch_to_aarch32_mode(v);


>>   
>>       return 0;
>>   }
>> @@ -38,7 +43,7 @@ static long set_address_size(struct domain *d, uint32_t address_size)
>>       switch ( address_size )
>>       {
>>       case 32:
>> -        if ( !cpu_has_el1_32 )
>> +        if ( !is_aarch32_enabled() )
>>               return -EINVAL;
>>           /* SVE is not supported for 32 bit domain */
>>           if ( is_sve_domain(d) )
>> @@ -58,7 +63,6 @@ long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>       {
>>       case XEN_DOMCTL_set_address_size:
>>           return set_address_size(d, domctl->u.address_size.size);
>> -
> 
> Stray change?

ok

> 
>>       default:
>>           return -ENOSYS;
>>       }
>> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
>> index d14258290ff0..9f7e735c9b74 100644
>> --- a/xen/arch/arm/arm64/vsysreg.c
>> +++ b/xen/arch/arm/arm64/vsysreg.c
>> @@ -330,6 +330,15 @@ void do_sysreg(struct cpu_user_regs *regs,
>>       {
>>           register_t guest_reg_value = domain_cpuinfo.pfr64.bits[0];
>>   
>> +        if ( !is_aarch32_enabled() )
>> +        {
>> +            /* do not expose EL1 AArch32 support if disabled */
>> +            register_t mask = GENMASK(ID_AA64PFR0_EL1_SHIFT + 4 - 1,
>> +                                      ID_AA64PFR0_EL1_SHIFT);
>> +            guest_reg_value &= ~mask;
>> +            guest_reg_value |= (1 << ID_AA64PFR0_EL1_SHIFT) & mask;
> 
> Why do you need to apply mask here?

will drop

> 
>> +        }
>> +
>>           if ( is_sve_domain(v->domain) )
>>           {
>>               /* 4 is the SVE field width in id_aa64pfr0_el1 */
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 310c5789096d..544d1422a793 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -791,6 +791,15 @@ int arch_domain_create(struct domain *d,
>>       d->arch.sve_vl = config->arch.sve_vl;
>>   #endif
>>   
>> +#ifdef CONFIG_ARM_64
>> +    /*
>> +     * Set default Execution State to AArch64 (64bit)
>> +     * - Xen will reconfigure it properly at boot time
>> +     * - toolstack will reconfigure it properly by XEN_DOMCTL_set_address_size
>> +     */
>> +    d->arch.type = DOMAIN_64BIT;
>> +#endif
>> +
>>       return 0;
>>   
>>   fail:
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 47ba920fc6b0..c616127e8da5 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1873,19 +1873,6 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>>       BUG_ON(v->is_initialised);
>>   
>>   #ifdef CONFIG_ARM_64
>> -    /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
>> -    if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT )
>> -    {
>> -        printk("Platform does not support 32-bit domain\n");
>> -        return -EINVAL;
>> -    }
>> -
>> -    if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) )
>> -    {
>> -        printk("SVE is not available for 32-bit domain\n");
>> -        return -EINVAL;
>> -    }
>> -
>>       if ( is_64bit_domain(d) )
>>           vcpu_switch_to_aarch64_mode(v);
>>   
>> @@ -1983,6 +1970,10 @@ static int __init construct_dom0(struct domain *d)
>>       if ( rc < 0 )
>>           return rc;
>>   
>> +    rc = arm64_set_domain_type(&kinfo);
>> +    if ( rc < 0 )
>> +        return rc;
>> +
>>       return construct_hwdom(&kinfo, NULL);
>>   }
>>   
>> @@ -1994,10 +1985,6 @@ int __init construct_hwdom(struct kernel_info *kinfo,
>>   
>>       iommu_hwdom_init(d);
>>   
>> -#ifdef CONFIG_ARM_64
>> -    /* type must be set before allocate_memory */
>> -    d->arch.type = kinfo->arch.type;
>> -#endif
>>       find_gnttab_region(d, kinfo);
>>       if ( is_domain_direct_mapped(d) )
>>           allocate_memory_11(d, kinfo);
>> diff --git a/xen/arch/arm/include/asm/arm32/domain.h b/xen/arch/arm/include/asm/arm32/domain.h
>> index 1bd0735c9194..30e8818ff2ae 100644
>> --- a/xen/arch/arm/include/asm/arm32/domain.h
>> +++ b/xen/arch/arm/include/asm/arm32/domain.h
>> @@ -3,11 +3,23 @@
>>   #ifndef ARM_ARM32_DOMAIN_H
>>   #define ARM_ARM32_DOMAIN_H
>>   
>> +struct kernel_info;
>> +
>>   /* Arm32 always runs guests in AArch32 mode */
>>   
>>   #define is_32bit_domain(d) ((void)(d), 1)
>>   #define is_64bit_domain(d) ((void)(d), 0)
>>   
>> +static inline bool is_aarch32_enabled(void)
>> +{
>> +    return true;
>> +}
>> +
>> +static inline int arm64_set_domain_type(struct kernel_info *kinfo)
>> +{
>> +    return 0;
>> +}
>> +
>>   #endif /* ARM_ARM32_DOMAIN_H */
>>   
>>   /*
>> diff --git a/xen/arch/arm/include/asm/arm64/domain.h b/xen/arch/arm/include/asm/arm64/domain.h
>> index 1a2d73950bf0..bebcbc582f97 100644
>> --- a/xen/arch/arm/include/asm/arm64/domain.h
>> +++ b/xen/arch/arm/include/asm/arm64/domain.h
>> @@ -3,6 +3,10 @@
>>   #ifndef ARM_ARM64_DOMAIN_H
>>   #define ARM_ARM64_DOMAIN_H
>>   
>> +#include 
>> +
>> +struct kernel_info;
>> +
>>   /*
>>    * Returns true if guest execution state is AArch32
>>    *
>> @@ -17,6 +21,25 @@
>>    */
>>   #define is_64bit_domain(d) ((d)->arch.type == DOMAIN_64BIT)
>>   
>> +/*
>> + * Arm64 declares AArch32 (32bit) Execution State support in the
>> + * Processor Feature Registers (PFR0), but also can be disabled manually.
>> + */
>> +static inline bool is_aarch32_enabled(void)
>> +{
>> +    return IS_ENABLED(CONFIG_ARM64_AARCH32) && cpu_has_el1_32;
>> +}
>> +
>> +/*
>> + * Set domain type from struct kernel_info which defines guest Execution
>> + * State AArch32/AArch64 during regular dom0 or predefined (dom0less)
>> + * domains creation .
> 
> Extra space before full stop

ok

> 
>> + * Type must be set before allocate_memory or create vcpus.
>> + *
>> + * @kinfo: pointer to the kinfo structure.
>> + */
>> +int arm64_set_domain_type(struct kernel_info *kinfo);
>> +
>>   #endif /* ARM_ARM64_DOMAIN_H */
>>   
>>   /*
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index bb35afe56cec..c29573f0ffec 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -530,7 +530,7 @@ static int __init init_xen_cap_info(void)
>>   #ifdef CONFIG_ARM_64
>>       safe_strcat(xen_cap_info, "xen-3.0-aarch64 ");
>>   #endif
>> -    if ( cpu_has_aarch32 )
>> +    if ( is_aarch32_enabled() )
>>           safe_strcat(xen_cap_info, "xen-3.0-armv7l ");
>>   
>>       return 0;
> 

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:10:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:10:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110806.1459841 (Exim 4.92)
	(envelope-from )
	id 1uuGIB-0003No-U8; Thu, 04 Sep 2025 20:10:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110806.1459841; Thu, 04 Sep 2025 20:10:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuGIB-0003Nh-RU; Thu, 04 Sep 2025 20:10:47 +0000
Received: by outflank-mailman (input) for mailman id 1110806;
 Thu, 04 Sep 2025 20:10: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 1uuG9Z-00062f-LY
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:53 +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 fc9a8875-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:46 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:44 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: fc9a8875-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BcZfJwGOeWkeZWnRHdDU98e4EBvnBTvThScltWxOeMnnTH1T9l+jfo3lWp5CVNsPqTLE7Gc9n3XtwKkEszDxp+5Fdh6VjJKT1tHIZwGT5yehnL90I/d659ugQzX2/Np1CGr1f8PMc8M0naUB7yNMLrvYyb6gV0iZH8oSDeY/Y9caj5rT0VoB0f4NOeIB0knsQ0i/jFHYEjzlX1DURjvibeLCArD4Ym8sm0vFPtQ8o2oyhunU5JIv0NPqfnCJfcQZ/HFqhsqHm8lqqCHSMDCisDWEqPe891FuzzvP+PmGioB4OaaE2Noj37w693BpK393KbDVe4V46tOjJf2uxYM9Xg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hSF+SSgp9NTSL/mvRgla4zB2nDCGmCDzkRuguIvCksg=;
 b=SER+UUlg2TUJULP101HWrMgJo25oMCoIrb75ERJfCl+uUbcKWTiUoEAbSJlx9HPzgKxU1YzGRz3nUVtETVOKVJCvWOyHxIW0BQgmVNfIxdD1m5ix/dm30R+2+C8XvPw1bZFdRf0QsD2MnHxt0DorM+oYDVHCkFn7wpCNsab2ccZgttqPVJjyhpdvtEJwMDkyCnJogI3ljlFOM2O4HP7joLIrhQOXDZCvY8Qvup4k6rB27CjpFEGKLez8+1ee6HH6w01uX8wAcyjeJvl0koqzBVBU1Tg+wOgS2KoNtxLDSl+aPXusFzIRCmgYnPtQAiWxEeI7XG14lRcPmYgrpR4gCw==
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=hSF+SSgp9NTSL/mvRgla4zB2nDCGmCDzkRuguIvCksg=;
 b=Wzon4+wT3vQ9kqdX6RdnfT9LgmbiPeQX48IFw5v148+39YaubEyFc79cXVpAp6D4Moifrgmc/b/OZWczI0+eLnHSmIj+U+MdyVh/8bZiYPkI53l5CUbK5cME/g1YOT2MvK0Vxk32bjNRk0R7J3SWzojlMEJ2Oj7w9VwCfrt9BZMADpBU0td3MR58jTIQwyUznAfwihxxDYo+ZdqLkcqA/GV7Yzfpeh8QdGbc9Gj/bZw8alqmqW3+ANwwijn2+JoXtqLMPtNzsClNQU8OzOrL3ym/JB2J81UNivL4VDmodfm2cs95MF/bawAiBD+zbRb8S4QO3ZoCDiB3AU+EoWhztA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko 
Subject: [PATCH v7 09/12] xen/arm: domain_build/dom0less-build: adjust domains
 config to support eSPIs
Thread-Topic: [PATCH v7 09/12] xen/arm: domain_build/dom0less-build: adjust
 domains config to support eSPIs
Thread-Index: AQHcHda8LDtFOW/3qkm3ftvPZ5C2DA==
Date: Thu, 4 Sep 2025 20:01:44 +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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: a99e4868-fa2e-430d-c702-08ddebeddf60
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:
 =?iso-8859-1?Q?pRpJdWAYBbkbuUjvbDvbojz0a72ckKxq0681DDRyUovYashxj5VVRzMEnb?=
 =?iso-8859-1?Q?17C4KesmQaZjOYTR1pCULSHJxYglwBU6DsGP8Xg//bLqaxFr57ceOBSR0b?=
 =?iso-8859-1?Q?SY7+L8vFWq60k02eNKfjoTrAcI1RRq2O0mntsB982WdDz5US3u5KLmDYdc?=
 =?iso-8859-1?Q?IWSFY2Wr94tkB4hJcN19HCcw7jhOxsMM+tCogHVF8U5dX2LYiDDAOTa/Xx?=
 =?iso-8859-1?Q?WRSRB6IU0ooczakoZE5xsvAmR7wR0jPPdP8dVfCGEUJLYk9bnkc4m3e7ON?=
 =?iso-8859-1?Q?PQsNrj/rSdj+d+d6ctRuGTLE4K37BfjeBULiyPokLkrxjZRa1S2Be3eG6w?=
 =?iso-8859-1?Q?EXOfNZb6bdR6/SyC37Z0UntXyIui0Bj0JyRyHFOhUEHUVVcsHdfhJabUJ0?=
 =?iso-8859-1?Q?M3nMxmUjN58tDnRwwVS5hWj545ZanfoTBIQm6LJG34EViJvuUorXQkZPhF?=
 =?iso-8859-1?Q?wuo8sQVSdpZxFKt5Sm/DIPdLBcmVfAUzGDGpIBd0PY2fhDlCDv2Ppw/sU0?=
 =?iso-8859-1?Q?8Omt/PZ7aIP+cOmBTxzAyS8eKH/avGGvOAVkchZBG63SRdGT1LdS8DcM6O?=
 =?iso-8859-1?Q?jdLyc3FoKqgvnUMWcfaxi4FF6ejQvGsrGNDDmhcnb6PRDrMNu/JB5FDCju?=
 =?iso-8859-1?Q?9jhNne8D6wVM9yAjhKx3nIb54syjYHllFDl4rYECxCJJ216SK+jk9bpTmz?=
 =?iso-8859-1?Q?V9gaXC6yYhFtYkWITWg9oKXDbied5fSvTb2IqTkEVqA3xKD4lcPGM8zx7Q?=
 =?iso-8859-1?Q?zdFjv1f7V3dBX5Har7UZVozH91HZ4dW9gUBhWnd9+32dV84HYV2rj+l482?=
 =?iso-8859-1?Q?AXVdd1VGBhh+V1l67mmeR6LNmuxC2+LC4Tziq/HNI2htnFsk7APbu/iCTl?=
 =?iso-8859-1?Q?5CEAyDm6nx7zL18/8Mk/xfsKjc+CsXOjieMIFUwgfkGzX758ooFFRXJv37?=
 =?iso-8859-1?Q?AicuoouS8/+1o0BSnhHpVqJHATOSw/ieUXKdnDXXdIn/1vThC76HePPAaF?=
 =?iso-8859-1?Q?xLusyg/k6bob39jZ13rjI9nAoAB1i/8pTPncbSr5Md0t0j7z4wPaMusLKD?=
 =?iso-8859-1?Q?R1RyPYZPEvpDg+qtNMGdq/IqiZBUv366WsrfZ7Yul9s6X0qhpKj2Mu9ghr?=
 =?iso-8859-1?Q?HuVTacYHZJ9ICVjqxY3XicZs2SWUajYBIyDzdSw9RfpeDfrQRjYo7fI3rA?=
 =?iso-8859-1?Q?n1K7N8b5hRrhXuw5IMk4zx+J8mWGMnH06XQ0fFl+mGj9/sYQBXcUJ3fAdB?=
 =?iso-8859-1?Q?UVu2YM2RPY0tRijVZdfL7PTJj1Ux28H+ddxVo/A03nJ4yNxBGzU2qf37XA?=
 =?iso-8859-1?Q?oaD/MsFf2pyvveAI9Lu1AJXNjruaBgSfMfsWYQA7UGas0zt0mVwDuEk59Q?=
 =?iso-8859-1?Q?Jf3sNR8xT8vlDW653+PyFwycETlPYmbOmfR+PRfN7KsUhFLYfqG+ed/LCF?=
 =?iso-8859-1?Q?731qNeo/c5jSBQm+ik5UxFbQlvhwB37LApjk0opIR0ooomfEYd/T/D97tG?=
 =?iso-8859-1?Q?fGeuJz4QDy7RnG5oBJ8oUeWcA5cqnFcaVeL8gEVUtwSQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?gsl4dGxxVFzZBdKXV85gHu574In6RyIDAInsAuIMiwOkvfsmIHzc8DSvq3?=
 =?iso-8859-1?Q?1EB8qPqzuwBxUk/yBdl5YUXwVD1sLGJ2kKlCudTfGjCwB49IxTtZ9msbk3?=
 =?iso-8859-1?Q?sd9hN3HAsgmWzZVTnrZIiyljfuJtb/H6VkDpXYG6e5pSrtxyHM9NGjMD29?=
 =?iso-8859-1?Q?+Z4BE+qPevlzIj9UWMZwwvsyB2V0hNcBzvGv5PZLWvyC4cbGXeFqt3+ISB?=
 =?iso-8859-1?Q?5s+B9HfHPH+Ge/SLQWydsTeRszrXqcQLKivmQEr63JcZoS26g4pusb73YU?=
 =?iso-8859-1?Q?+fs7wS588zFFYX969U4UPHY4ECEi+JXvJKzh8oVQCb7xyTtGbDzSMzZBmz?=
 =?iso-8859-1?Q?zlX+cOOl/g5ZUJG1TFWZXSqeX41sBN/8d8r4/5CfW5JOfEafyWiLFtGUf9?=
 =?iso-8859-1?Q?3sCV5zjEV5ABs5mCFqM27+F9zehtzH7R6qFRrDUpT9DbXE8FxHvxjsXp+J?=
 =?iso-8859-1?Q?xUHzDO33bXdodQ3FCybHjC2MOxbXxUOTu/NaHUkjHc2wqk/+hdrAr273T7?=
 =?iso-8859-1?Q?T2cZr4bo5KxbyAlmI8ZPYhwJ5UteEowCUrUL1pt+G+u7lJnGmvxpquxgfH?=
 =?iso-8859-1?Q?vuUSlNOgc6n76EZJ2dZ+mhnKMHwEDuCx39QwTGnIujKW7UDGftK9nULCmO?=
 =?iso-8859-1?Q?xaxMXgcCKDPoeahP3Vh6ojSN7Bl3yU8gMwj1tUbuytoX2QNtwG/KLnZFnz?=
 =?iso-8859-1?Q?lrY7pzzX3wW7hnp9FF3C2Ti355i+20325lX4c8akBxbfBj/PyM3+g7vfjD?=
 =?iso-8859-1?Q?Netxtp/ul4W8UtZmFhWDZHw0/9fafPyapWIpCc69YYQ0O9mupPLXQKGatc?=
 =?iso-8859-1?Q?NG0eANug/cRlJWz0dazu+n63QmltGqfEPrtJlVeoFIeMxf9qhMmHG/Zlfx?=
 =?iso-8859-1?Q?rVYKXXHToXleRwM1y1teT+FTMP6YI7JIrXM20UFvg0VWLRptu96c62Udo5?=
 =?iso-8859-1?Q?D1xbahs2p2Gzb4t75JLG6kPCMfuniemP38RX3gNHE/qXdhij8KDWDX19qX?=
 =?iso-8859-1?Q?mo62MD7Jzqmwy65yc3Fd+f1X7ShZaRL9dCpWRpS9jSf42N17UCNqeBG5zr?=
 =?iso-8859-1?Q?U6rCwvucIgEEFcY7ihmPZe3Fxzt8ulA0e8yrehtbFKGWZ/EiP77VStsadB?=
 =?iso-8859-1?Q?MwH5IbrUOmpJrk9fDYczW40KZY1VGnJRJqPWBvMMfKeiU73q112k+9LpNv?=
 =?iso-8859-1?Q?OVWlyLeSJF/QeRJKuDmK9ynBUCguLdVR5gHx18z1JPe5vKfXdVR1qtpTr/?=
 =?iso-8859-1?Q?kpoTTMcaY84tLySYh+F3gizfCnacgX2biWL/38upsGJWn2Ngqf7+mLSm7x?=
 =?iso-8859-1?Q?QbEvXCljp/F5/uww8JuIjsNteudUJg8Rae+pHTO306kmG1al+go9gRVYby?=
 =?iso-8859-1?Q?6e3ccErL069wVy3NOVIFQdWp1C/zSpEpJAzEHbSQKk/vfRq2WzJzJ+/yH1?=
 =?iso-8859-1?Q?0ujRUKluF8fbFMBDKrp+ZuRMKmKeyFgIne9oEllcKUCfZnTDMwlxkjUsII?=
 =?iso-8859-1?Q?FBtcTzPCr4Mo/ZGBby73alI/YSzZ2JBlyZhkqcMPLXz9BymLb5143k4OMr?=
 =?iso-8859-1?Q?pEM7XnT57qt+8srHvSmlsJSaQbjHaibCqp7zuXcqCk6SJBwx3QWhXQVR7W?=
 =?iso-8859-1?Q?THIxXia/jyx9GuqIzo1tGPSsn+DLToy2wts2X7/ibqFqlsWiLSQ+PKoJ2x?=
 =?iso-8859-1?Q?L72BnkIbjZJ6pIkg1vY=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a99e4868-fa2e-430d-c702-08ddebeddf60
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:44.3473
 (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: YdS7FWtQDIArBfufOUftoTYLC4keLvfBXb2oxkVDzY4PJj7KC8c5B5jGw4uZLKPEf7pCPVqh0ydVS9Q1uD3tE6vOUq/MbAkcnsn2RPC8Ldk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

The Dom0 and DomUs logic for the dom0less configuration in create_dom0()
and arch_create_domUs() should account for extended SPIs when supported
by the hardware and enabled with CONFIG_GICV3_ESPI. These changes ensure
proper calculation of the maximum number of SPIs and eSPIs available to
Dom0 and DomUs in dom0less setups.

When eSPIs are supported by the hardware and CONFIG_GICV3_ESPI is enabled, =
the
maximum number of eSPI interrupts is calculated using the ESPI_BASE_INTID
offset (4096) and is limited to 1024, with 32 IRQs subtracted. To ensure
compatibility with non-Dom0 domains, this adjustment is applied by the
toolstack during domain creation, while for Dom0 or DomUs in Dom0, it is
handled directly during VGIC initialization. If eSPIs are not supported, th=
e
calculation defaults to using the standard SPI range, with a maximum value =
of
992 interrupt lines, as it works currently.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V7:
- no changes

Changes in V6:
- minor: updated the commit message

Changes in V5:
- fixed minor nits, no functional changes: updated the comment to make
  it clearer and corrected a misspelling
- added reviewed-by from Volodymyr Babchuk and from Oleksandr Tyshchenko

Changes in V4:
- consolidated the eSPI and SPI logic into a new inline function,
  vgic_def_nr_spis. Without eSPI support (either due to config being
  disabled or hardware not supporting it), it will return the regular SPI
  range, as it works currently. There are no functional changes compared
  with the previous patch version
- removed VGIC_DEF_MAX_SPI macro, to reduce the number of ifdefs

Changes in V3:
- renamed macro VGIC_DEF_NR_ESPIS to more appropriate VGIC_DEF_MAX_SPI
- added eSPI initialization for dom0less setups
- fixed comment with mentions about dom0less builds
- fixed formatting for lines with more than 80 symbols
- updated commit message

Changes in V2:
- no changes
---
 xen/arch/arm/dom0less-build.c   |  2 +-
 xen/arch/arm/domain_build.c     |  2 +-
 xen/arch/arm/include/asm/vgic.h | 19 +++++++++++++++++++
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 69b9ea22ce..02d5559102 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -285,7 +285,7 @@ void __init arch_create_domUs(struct dt_device_node *no=
de,
     {
         int vpl011_virq =3D GUEST_VPL011_SPI;
=20
-        d_cfg->arch.nr_spis =3D VGIC_DEF_NR_SPIS;
+        d_cfg->arch.nr_spis =3D vgic_def_nr_spis();
=20
         /*
          * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d91a71acfd..39eea0be00 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2054,7 +2054,7 @@ void __init create_dom0(void)
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
     dom0_cfg.arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
-    dom0_cfg.arch.nr_spis =3D VGIC_DEF_NR_SPIS;
+    dom0_cfg.arch.nr_spis =3D vgic_def_nr_spis();
     dom0_cfg.arch.tee_type =3D tee_get_type();
     dom0_cfg.max_vcpus =3D dom0_max_vcpus();
=20
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index caffea092b..24a4a968c3 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -357,6 +357,25 @@ extern void vgic_check_inflight_irqs_pending(struct vc=
pu *v,
 /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
 #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
=20
+static inline unsigned int vgic_def_nr_spis(void)
+{
+#ifdef CONFIG_GICV3_ESPI
+    /*
+     * Check if the hardware supports extended SPIs (even if the appropria=
te
+     * config is set). If not, the common SPI range will be used. Otherwis=
e
+     * return the maximum eSPI INTID, supported by HW GIC, subtracted by 3=
2.
+     * For Dom0 and started at boot time DomUs we will add back this value
+     * during VGIC initialization. This ensures consistent handling for Do=
m0
+     * and other domains. For the regular SPI range interrupts in this cas=
e,
+     * the maximum value of VGIC_DEF_NR_SPIS will be used.
+     */
+    if ( gic_number_espis() > 0 )
+        return ESPI_BASE_INTID + min(gic_number_espis(), 1024U) - 32;
+#endif
+
+    return VGIC_DEF_NR_SPIS;
+}
+
 extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
=20
 static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:11:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:11:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110820.1459851 (Exim 4.92)
	(envelope-from )
	id 1uuGIO-0003pz-8M; Thu, 04 Sep 2025 20:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110820.1459851; Thu, 04 Sep 2025 20: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 1uuGIO-0003pp-32; Thu, 04 Sep 2025 20:11:00 +0000
Received: by outflank-mailman (input) for mailman id 1110820;
 Thu, 04 Sep 2025 20:10:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuG9i-00062f-M8
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:02:02 +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 00734357-89ca-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:53 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:51 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: 00734357-89ca-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K8f0gH35+5sa01sCh7h9Rkr9tUwQrt43EOoJY8KRVQPwIkXxxcBGAamoVnUU6V1lHCxyQu5GREbEDipfOdXjOCVKN8CcO87ig/yG6K2OfZlObP8jYlV0M7DrihVOBZHgT+B4EBuPYaU2OdHNp/TT8zM90a+kSC764Vl4u7gzqLrAAdcT41t6JfZrQLu2mXaoqeyMGEHSig4cX4I9+N7CBhCZzVmiHUDtZo1jW0r2fmFrRSFbjotEfMA/Ty7E8Foa14HyUbv0iWbNoRYeRpeKR4V2CyiTYG+p+sIEK1PZCUWT3/cYNCKSLMqFCZCnnFaFPZtBpzeHMVhGA8wcaF2wGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=APCi5+B8JdVl+YRWSgmdXC3fYo66EiTHOdPIrONfa4Q=;
 b=nc/+zPD3rKKRBOyxEe+k3NkY2I0A36+dqSy340Xa2cSsOVXqqTRbydtBloWD0uQLzcmSdbr8JQXaptwR46ypYx26cIABC5UipDtnxnI7Qgpz0h0rP+BMZcIaEQFrOcbpJLRMXv+5zUG1xO4JCUxSue25uPQCh3gCZrMDzdjJ0/pt6J96PlcL/lEAKalT5V/1+8lFeojkNHWRfuBEri+vIiJC1mG74gESxtxk9yyiIYBbmTWYDoNLvk7WMQWksn2bVPLm5+wocs96gwyDDMQOmX+2dIv9RJT5gNUxnUyBF5sGsbo40/lP+AOP+r6WUlUtEGgw44aga7E5qowI6WDuGg==
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=APCi5+B8JdVl+YRWSgmdXC3fYo66EiTHOdPIrONfa4Q=;
 b=vDL3sG5AycgPE+KKQRJ6fgY31CV33ce7VywTeuEu1OnSwJ5gWESzfyvXUTxBOE7BPBiBVJgteMsjodvTNqLhhX021D+ug+w8H37uyhOLaVSvLhY/BmKV2u3e6MPmksnFRn3v4llph5e6Dl4mtCHy/1beAkB6IuzpeEMv0CRTJwNhFfVkT0hnlE8T5m1KjT7DBuPlIluBn++imcRBniZevMT1v2d/vl8WVOHtys4pmWyANh+Ye+fUJhfxwd5urgkRIgvS9G52xzeFNFoWQCW8/45ukCanI/9FTiiKG7D2K9ikZ3+IFJqEyQfWiKher4HaFqi9/wXsCVXPslZOLtPbQg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v7 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI support
Thread-Topic: [PATCH v7 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI
 support
Thread-Index: AQHcHdbB9wlNQ1oV4kGWY7CqZflnXg==
Date: Thu, 4 Sep 2025 20:01:51 +0000
Message-ID:
 <90060a66131b799fc14249e4f3e71a0a04fede55.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 5e082a27-2672-433b-9af5-08ddebede3c8
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:
 =?iso-8859-1?Q?Tf1pamZ3Jzq7w+w/luTqu7C7TtP7VKX7nyIsKfm1v+uldFY/v1+4K2+zyC?=
 =?iso-8859-1?Q?b6E8oOIIshrLTn16HAmCs2UP1ckRqNRSDSw0pKLb8AHyX664jcHXEbAPQ0?=
 =?iso-8859-1?Q?WVC1dT28aNQ3/kwrVt7c0JCyHAzwmWNeRoSK3FM1nDBktJzTlfSmUrjK6/?=
 =?iso-8859-1?Q?P8jKFNmpbk2JZuA87x8K0hM97rXYnm3MF+ZuEsS211Qzds691i+/L3r1dR?=
 =?iso-8859-1?Q?BMeD6zRnms00WuNdP5ZC1z40AAuW1vnHxXJMU/0aQ8JdAdGRefjjgGVWKb?=
 =?iso-8859-1?Q?cGnexcFMCyQ1llhKyXQEPzukKu+lxhslyk6e8tjmmSCZUOzusP/lT4cqaD?=
 =?iso-8859-1?Q?bb2ZXtgIpmF173DCNurMoJHtgpn8lxsW4ZtooMd/5RwKcuODw+6ClOZxGU?=
 =?iso-8859-1?Q?0DARmuOm8M+Y0hG1PxIK6HmDnvwUecbw5SUiwUeH0s4U1hm7PG/fWEQl83?=
 =?iso-8859-1?Q?sJefjjoEl0rarzO5po31QJT0xqLQR24TJDMBCHmetsS9yJqFiW0AkszIDJ?=
 =?iso-8859-1?Q?cvTQ5tEUf9PK6/V+t5p6WACcMrBnddNhQrgEp010wevZNwLGvZo5+nMgZc?=
 =?iso-8859-1?Q?UOi9dM4ukTqK6BgiCiUtt1bjsujjXKQmhlCUxJCn45N96ARCv/lFhYgKq9?=
 =?iso-8859-1?Q?cbaehfXQ6eHfMnMJtXFz8pLEAlu6d07GNp+q9heJW92onjBGE/8/S0IAT7?=
 =?iso-8859-1?Q?ksU9fOupQaxRJ1letMGIR7x0tjUnEXRbkbqXfwlRXjwPuPIGbcyvU+iRhc?=
 =?iso-8859-1?Q?iudP7VCJhzbeBLyoyyp6pyf23Wyo8riRJILIELjcyUNO/gOEtXdtRVbySu?=
 =?iso-8859-1?Q?uNtVxXBzOqSW81Qh3ZmRuFIvRH7Zc0dIUjT0gsHdeEUJRkhC5JFNrbSlzd?=
 =?iso-8859-1?Q?LAmtkhF86nhAHv31ijijc6k2Oyv1LwT9iOjIeFRKe07sw5U/8Apb4F7uiI?=
 =?iso-8859-1?Q?vaFLbAx5ccZeWp9reswi+LY+7CztfFVL8Kvpbti6mBM0XJIvyz3zjf3PD7?=
 =?iso-8859-1?Q?Whhg21UcuIEtxh3ipa1eH5mzV2zKglhwSrxYas8Ve4E/MH5yE6vn5WODDM?=
 =?iso-8859-1?Q?ELIEVqBNrTYP3qdssOE7/XGTWKnYH7z0C1BYgomrU0Ob4PRD3aDLkMuowM?=
 =?iso-8859-1?Q?qEDrYENB7q5NDAZpZMDBPBDmqQi6Bg6ZhFJC+LTFtKAKbWCXz5MR6lJ5kW?=
 =?iso-8859-1?Q?3gS+daT0pQm0euCzB9ZmM9DOjH4GUyORAMLT/GVUEj13Zu4WSgvnZ8zcng?=
 =?iso-8859-1?Q?wgRnfnDI+O/sLIR5gGPeJ1WAiVXdedyrVPXqKYIMFvhB+62HpF18B3a8uM?=
 =?iso-8859-1?Q?zIhz9IzJDoXDJ+ermdIWznTyJQLvPaUOFmrFvv4n57cYjvjuHGA3Lqp6AG?=
 =?iso-8859-1?Q?cvLtX8KoMUfMF7hgM/zM1sMP4jTfgyfbg4bQGH3gZjxC41rw1o8OWqd17H?=
 =?iso-8859-1?Q?bwmPnV2KLJtfmBBSLYPREk5z5HExktitrd97NpTjUARQOmaDdMygf+3URD?=
 =?iso-8859-1?Q?c=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?2YNbWijHOfvfyIyR8V2elKEtwQLL4/kv0eLTaTjN6qcdo/ILXp+UMfgnTK?=
 =?iso-8859-1?Q?VtRS3aK0R8Muwdk6l22BFgc6IjAjZYl0/OjxgifP33+FKp9x9KMAOdl4OV?=
 =?iso-8859-1?Q?TrwxIP0itji3tiIKZF3fGYUEJNY1piD1mkrxYgNHxVR/PS2H2GAHlLC32H?=
 =?iso-8859-1?Q?v65N0ncmG2EumapF29fFvmMoVVN+x13lUm+WydF4I1dQX/c2JSOzAOafQT?=
 =?iso-8859-1?Q?/yNguD9hq4qKSC4pqkNyVWMA2Bsj+693b+dBp0QTGOY4z3PN1NO4ALWEZo?=
 =?iso-8859-1?Q?eqcM9ZB4dk8exf73t0rw7rxl/zGpouguZRAa9p6Yfm7vy9/F0RXh6BHXwK?=
 =?iso-8859-1?Q?PV09CiwS2rRSfWmRcyfcYHO4XerwA39FRDGdmUdXVNAONu0UFXupsvKkYA?=
 =?iso-8859-1?Q?u71AJVCxt2rTGeKwIwxlcUnieWZU5nXn0T22hmIo5c86Xj3ey1iqjKv98A?=
 =?iso-8859-1?Q?PjHTtWc6OnBUDhgHXACKLE72S9gLsPYOWvKf3jpCpGfUfe8PPtAi/6wOj5?=
 =?iso-8859-1?Q?CUuaVToGKXD9sUD46Y1gjwih5ys2qE68cjAO+GBmN281Mj/Nl/5vaOe5P2?=
 =?iso-8859-1?Q?WDZ7NuzseC4PCsC7LNHYnqbLglj4lmhfgYaskcsz+kK/pKFMRo/ePPYHWf?=
 =?iso-8859-1?Q?/tcMhTbLuQ6e/n5wmGmrhcmtdP23B4hstmYz6ZFMmGglnxrNI7o3Mvvq9y?=
 =?iso-8859-1?Q?J1OQkAD0s/hLK/kgID3VOxSeK0nQj4dlTGvpWAOPFgOt6XltvZzup4UPVR?=
 =?iso-8859-1?Q?pcbjvsGETVxShzM4L+vRiEdmNHmnv+/MPEbqltqi0yHqF2vPjaoWZJ65IR?=
 =?iso-8859-1?Q?/wEb+tx1tbTKTAUZdVyW3Ot3TIo9rkiD+sJVAkgFvSmWD8VujXHlwNGt5Q?=
 =?iso-8859-1?Q?SB4/1QjQfxoh2YT98CljzvBuBDBR9vlqvz+Ymg18EIE6I/CCcIQX7osaop?=
 =?iso-8859-1?Q?Du+G0A7f4gT44ZZBVYWQA36OX992wsNPO4SnPFqqiF6lQyYXTlHqyg73l8?=
 =?iso-8859-1?Q?d6qS60UOjGoQvsWJybyrV6heedczDeS+UhHakuID2qxx1r4/arIvB/39UK?=
 =?iso-8859-1?Q?bs6tn56mUIFyAY9wQblnesy9rmbZURNyodssyGX1g44wOA3G46GQeXaqcl?=
 =?iso-8859-1?Q?FzqNqTbUOMU7sKWuz6E2hHPpDxhU846bR6KvUfQ/xolzCopn4WMGMALZmo?=
 =?iso-8859-1?Q?sHsdfaoOvXGqdbB8Q8opV1EZh4Za+cOg9Dp/JDfmd3ABtN16Y1LREvpk1I?=
 =?iso-8859-1?Q?MHFiLM/cyGHteMj/8jaqAue23hb4Uzyedco/Qdyn638CuVaPwk6CjRfc8W?=
 =?iso-8859-1?Q?4k93jXWyq0zjdIev8YYuLtezzHVvOeHzEd6W1q0d9rAq9zvhyG5l4Mcw6I?=
 =?iso-8859-1?Q?czEzIb+inyK7nIMI7q5G506gpJyoJ8VEBrk45yS9estJP5Su6TrF4tqhyz?=
 =?iso-8859-1?Q?gCa1ahubbUA3m1A1/DOnY49+ZrFz5LAVq7hZQjJYOCVzhmXJF5bevMwyT4?=
 =?iso-8859-1?Q?PADuCGcCPgGRqQe4pweMJCFS/sak1DeSfQGaQNlhVHeYW5KsVP/jLSce/7?=
 =?iso-8859-1?Q?G5LlWYBtHx8rIow4Ut+9fVx7rL92pfKrasrPXKw4AX2mdTl/C+CZ3Chg67?=
 =?iso-8859-1?Q?rQ5p6f6bdcim9CAd0UH6CKUjCiLr61OwsdTPDgwn93klSX8CPSyjyRdCWR?=
 =?iso-8859-1?Q?oc1coHcu72TS8akGS/0=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e082a27-2672-433b-9af5-08ddebede3c8
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:51.7319
 (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: mxDC8u3ma911H84UcMfxmn3ycCR+a36odQtqbmRqWFByP56PCrTZRNj2JwcY/bYEpEbRefpFN96sPxsoE752zDpK+QPOlg9HMzVgaFzZ0Yw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

The GICv3.1 eSPI (Extended Shared Peripheral Interrupts) range is
already supported with CONFIG_GICV3_ESPI enabled, so this feature should
be mentioned in CHANGELOG.md.

Signed-off-by: Leonid Komarianskyi 
Acked-by: Oleksii Kurochko

---
Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- extended changelog update with a brief explanation of what eSPI is
- added acked-by from Oleksii Kurochko, which was received for V3:
  https://lore.kernel.org/xen-devel/bce5e07c-eee7-481b-a833-4d5d8bbce78f@gm=
ail.com/

Changes in V4:
- no changes

Changes in V3:
- introduced this patch
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5f31ca08fe..31b4ded444 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -29,6 +29,8 @@ The format is based on [Keep a Changelog](https://keepach=
angelog.com/en/1.0.0/)
=20
  - On Arm:
     - Ability to enable stack protector
+    - GICv3.1 eSPI (Extended Shared Peripheral Interrupts) support for Xen
+      and guest domains.
=20
 ### Removed
  - On x86:
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:11:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:11:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110837.1459861 (Exim 4.92)
	(envelope-from )
	id 1uuGIX-0004M3-DR; Thu, 04 Sep 2025 20:11:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110837.1459861; Thu, 04 Sep 2025 20: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 1uuGIX-0004Lu-AC; Thu, 04 Sep 2025 20:11:09 +0000
Received: by outflank-mailman (input) for mailman id 1110837;
 Thu, 04 Sep 2025 20:11: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 1uuG9e-00062f-Ln
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:58 +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 fdc7263f-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:49 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:47 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20: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: fdc7263f-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iGh7ce6t98TKWKP+DlkkKCEmKJE3p8LJEAkteex3YEeTHL3XHYCR/gz+xMROBvazMOpsS82+kBr2zU7QrJ4fW7GHJjn+PsVu0/xuCjtMRkveAltqx2s8f1DLO4TbW//KY5qkyzBjwFF/y1+7phqBO0DHDCPC9LDlEy32hjZetTzMj7lm/t9jHwYbue/D2ifsnLPMXLu/wZOExmohQ9G8KG4Dz4uKxZjjQHkvIzM3TyfRBCYHGCjO1/lbp0wi8k26P0PcgdL/ezYjKUrQJ25NFyW7WgXJIgm74lHheOzih88gF89oD3PGZthJdaKR0fED8LcmT23Y27mqh6Iq9I9vAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ulbjelc154dqs7jw4b5uy0AtSPGi8WMKNq3cnXML3hY=;
 b=BmITs1d6sKzZqZztufdlfmCLOLD8XDXKVZ1AS9U7tp0jDamLLnnLsalmbYaxm+7j5arJOuCqYot3kUQOhImdMWU/ciRVoCvH4alehD6KLAWhE9w96CI91PuyN4HZW5KIx9G7YzykpOyM2tieIq1W/B5OtHhoQhoOw1wQXl+ZVECR89siFNLkUIPg7rH30L4qj0KwsYerJnvfuQFN3x98X0bitVFI/nQoa1jHLJeaDM7SPx26l0/FPzjnpjlqcmJCxSjFwXELZQjHe/HoOu8b3/2fow8+qpuE3Ewy2kPaQQ/gXfS3xlWOgOVOGqMMlfKe0aFh7H+MTGNjdLoVB6SC+A==
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=ulbjelc154dqs7jw4b5uy0AtSPGi8WMKNq3cnXML3hY=;
 b=SzI9HKZO42jZxFwcePkUUomQDAAIgvoLrBmQuueCh4dsUlmZojgkth2Np5Cu65i5jScoDMfnbmVkJI8fQSS18yUeaiu6MBZdOJFiYewl93Ykz0QyI3IpSwPOVkHdt/xaGoIgGkxJfaO+JNXSjfKu+cJ2H+TPWKbUkxnolA0vqBVEi36Hd0OJwQ76a2QdwRSKBuZAepV+dkDE/t1223y/uFO2FMM9HFy9+NmH26Ht4XERuHnhXebPFE2oaHFUi4V3nd4b1u90tmaR3QZNhgA7dD5oMrTyPIhi+OFfoYxZV43Nzf5LMNe/GfVQ1w+pyBlQxe/2GP88US4nAavrU8KbVg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	
Subject: [PATCH v7 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Topic: [PATCH v7 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Index: AQHcHda+wKKiul+Vs0aU6H1MBrjnQQ==
Date: Thu, 4 Sep 2025 20:01:47 +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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 9b03d8a4-834d-48e9-78b3-08ddebede104
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:
 =?iso-8859-1?Q?bB/RJFutLZf4m7xPDTLxaVCT+jcMHbzZCmd0eZvi25FlZQmkDPQi4RfDG8?=
 =?iso-8859-1?Q?2Sh/7Ie4Bgyij41Hwnw5NWiH4XOW56tiVU2o8ndIVVJIInIk/EIIM2ReSL?=
 =?iso-8859-1?Q?cdM8WKZh6b2wR1D2/nxIKI9TD161Z8hRSPqzo39S3InazP+t5WamXcywOB?=
 =?iso-8859-1?Q?B/PSehMUmJZp7OSdZGF0adgEq+81Nj2z8v3uzACNVlRMvHpB2CYnOZ/4Dv?=
 =?iso-8859-1?Q?0X/fe9okiueuMXXy8iKOI2RaySS3wh63XKOT45PFFUfUEuNYF+g2X6ZcFj?=
 =?iso-8859-1?Q?i9b5G6HPT4tvWgs5t+KyaGh8H2SjIZK6DBURvxIGPf4qizcKFrX3Zx/i+T?=
 =?iso-8859-1?Q?DjwmXbB9KLFS+M5Gjozdz/Ycx+YrnhmAusIc8MdhyEYivBNEfG6P0iN28S?=
 =?iso-8859-1?Q?fwq9zfMha4vv20KcUpHUhT38e8oGl0vPDi/iSA2DRi+iZau/9b81T3xMbU?=
 =?iso-8859-1?Q?Y3lPoWumT2F8d1yuetR4QonBdtmNKyhYz58z91wunQ70NIowhwYDawmllO?=
 =?iso-8859-1?Q?UeHIW1iyb3rFr/y4AywWZy+AbXoPBV58FVBw6aNK3ixFkpuyNGZ7fa+un/?=
 =?iso-8859-1?Q?VSg3q8IIc6HjBKTXGQ0vMOXqlv5Jk+hHtpVwTlep1RzWt/eq+rlon/t+Ma?=
 =?iso-8859-1?Q?jw2HY9FE6TIhSXI9C0B7Wtk77fv+i0+xXsERtYL6Fg+bgUDarsKbZGVM9i?=
 =?iso-8859-1?Q?GMhI0Jdmne6a6G/BIAq+rsz9KIUK+XYI6A7rBnzXbthiNttU8XNP7zbTHe?=
 =?iso-8859-1?Q?FsxRAI0dRDKc7OeMEhQ8OQmX30NcMAHom6j2jgUSbuYcCYA4jdUCpii5Ms?=
 =?iso-8859-1?Q?7PHTqdiYxEH5n9R9JCem8n91UeHSj447yzGPsxIq29KIY9q4FZ1jTjOs2t?=
 =?iso-8859-1?Q?HreUnz57Ahk43BXV2/EdMEXSFltwkf1VHhqeGWHhJ2XGge2O7DSqZGd69N?=
 =?iso-8859-1?Q?ZZ2r8vQW7rss/lJTn4nCKTchHevV7fuDegCwbVshRHuGTfGH9Vcr9i9cKQ?=
 =?iso-8859-1?Q?ZDvqmugqGSPpc72RmLboeOshJ2LbHHki8vXAM7iS7jlYsq6GJBgvvMA6Wp?=
 =?iso-8859-1?Q?KqJUf5XdbH1nQExLnwNNR9Ktt/+LxUTLy6Dbhy41AakHOrQbBpPp4hULFw?=
 =?iso-8859-1?Q?HFRhjaKYGnXFsPyX0jL1GMFdL3hz5pWs69uW5Y0rP6JxXe/uLEHh71sVnC?=
 =?iso-8859-1?Q?a0ta0pcRMP+ZxxT5ifZFkuHfgIcbwpJikMH4x7LNdPkbGsw8FGY9/owKuB?=
 =?iso-8859-1?Q?KLp9TTQ6CXyo3rmYjqPeQGmzFyZ0kM8G+M5Dn3pYhH1sH1nz5nvsqXOtig?=
 =?iso-8859-1?Q?il/FjM3M12cmCX/2NiNWTt8EGyU2lgBLFeIRAJUZ8a+Rr3/mvJ0X20/AGZ?=
 =?iso-8859-1?Q?8yuPrd/IOKa5VAZJdSj1PAvdztHnSZMcB8HAg9aNXh0YygDa3o2oR5DYqp?=
 =?iso-8859-1?Q?rtUjwoh5VLxOgBFIYWBuk3DS83bySPBVLe/+kqre/LwryjO1UtDCtu9HxQ?=
 =?iso-8859-1?Q?DPjlx6gFf8hd3vAk0cD5C1TvKTNmaSD1veZRxdhxKh9A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?Bj4uHUIWxBFKfexArwet4w5B0sjbQudkZFEdmsAkb2FQ2zogRpx+pe/ywG?=
 =?iso-8859-1?Q?y2gbgTZ7503nN86sqmmR3sAc+i4l/z/NA15264OZFie7yn6uO/wt0VX14M?=
 =?iso-8859-1?Q?4AEZZdqmYJGZ2vAMYYysPYuLT02asaTZNEGt6iz91txzEGadSJ8jOMmY+k?=
 =?iso-8859-1?Q?RyBrsgTgMWK+kIgsOGx1aX+it/2uqkOwVbW1tDCv/a6XsDNJyWo4/jeeEw?=
 =?iso-8859-1?Q?fycQXVjaKiUUGwhV/O2FM/Nt5MP5cjQkgLSxcuY+A1uXVnYuuW5q4HF6Ne?=
 =?iso-8859-1?Q?ozKSgqrC4qPQ+MvN7tNke54X1qA09f0TB6Cd7wAZbZ57/weugy+HU6EgB5?=
 =?iso-8859-1?Q?1PtCV9Wum3k8g6hvLb+mwMjbJG3SbhnYXZYUc6CZNBfXJXQxWGH8EYr+Kd?=
 =?iso-8859-1?Q?FdXOGjF1nUeDmUkX7B6XMduXX3hfdTlBtgWXe1OGKaTHM5Q1dmBOuZhdOe?=
 =?iso-8859-1?Q?XCjZkDngihmDSepbsDWWXSKgbjabJc+xsXxaX1QfRNbx9nUuq2cibRRwtB?=
 =?iso-8859-1?Q?G5WMz4R1vIUsh5+3zhFkNuWiD7nqVTjgr9hzB5iOa4PrqoXvJi250KKW4A?=
 =?iso-8859-1?Q?TiGx5tSRfqE9HcehKTzet+Qlns4pWSm3b8y5+5P/0uPx//GNd498f71YQ7?=
 =?iso-8859-1?Q?CNKaSm6vkj+rrhyZLdlmGEbbt2M4FIPCCvYxSdQZLw5Cyy7nUn+cr1LO4l?=
 =?iso-8859-1?Q?yhf5GsF4pFP9OAkVFwiIbx46rAN/eXns/Clx/Sj6frUrPHMrv661Ez3pZ+?=
 =?iso-8859-1?Q?v7ZUIaWkwgjNyB/nmcGsSJnFe0gVzkAHboHW1LfNFO0fhJ3J/An+QDPMAc?=
 =?iso-8859-1?Q?WM39xKBykw0IToywFSpJb5Ydz5wjfCG83H2pa1yIrtwdOnHDLEKV3/p1e9?=
 =?iso-8859-1?Q?rq8H0P6YxBnNxHi/xgbEnKWNTHSeD5Ssefy4uRgH6geUZFONQtrKuoAQ1I?=
 =?iso-8859-1?Q?tWrPqo8+ie94xGZ4HHZ3WWoOlXgxySwhPhY6WTs3T5Q4dvCDgkr+fGiJ1I?=
 =?iso-8859-1?Q?Uk8nolvYoAR4gWp8VuK180tsUwczC5qb8PTiqs0uy+sTcxnSoubuvmrVWH?=
 =?iso-8859-1?Q?ea1ehntl32ApwOUXNsJrAwhx6G6g3g7WI7Ij1SrT+7GxiC0giQNzJHoCjq?=
 =?iso-8859-1?Q?n1jX5eII3VgufdSzZZjLecifkFm37KeElUaHYjv28oHl4OoGs3M+KRa475?=
 =?iso-8859-1?Q?vCaAawujtG6N9/0iXGmmuoSHUurwWFtOWAhCoqsSM0z0TpjC1ec1YRieFI?=
 =?iso-8859-1?Q?RbtN/uBSkzyKlXnLjk7+q/+c1CXVArCfhXsDji9FoTjiZLjwUZ/NJMsdjZ?=
 =?iso-8859-1?Q?p66/Os44k7YwJ0Uluuj3nuQpPGBRSyMWWOmMmcG4OQRBSPkL6QVHD33OkR?=
 =?iso-8859-1?Q?ocBPj5H5vs4DX7LngPL++p4HAkRx0WlhBooyyaP6oVhYRe4jTr4ekx44TR?=
 =?iso-8859-1?Q?oveSitiQUHF6YWiw7UfkDpPcjAWXm7shrckjHJg/pngA3s9FbAfC07obUY?=
 =?iso-8859-1?Q?utCQ7ljxuvssEj+CkkZHKi/qTPwEY3jnaVWeJEX120heO2KL8Y1Tkt6p12?=
 =?iso-8859-1?Q?YytDrVfRcnV9h7SE1W8leLj+hYA47IaXqQUhvpYqL96DNeoXmTwqZG8IoJ?=
 =?iso-8859-1?Q?lOFG62LY5VCMr/8b4o71T+8WpdAEEmDWKo4lop9F3orYn/dpFsXPzU8v0H?=
 =?iso-8859-1?Q?vklvS2bdV3sn910o6ls=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b03d8a4-834d-48e9-78b3-08ddebede104
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:47.1224
 (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: Ray5WYfmUamo04/wwyWZSlGt90foHIrqJEVlTC8UE8AKmO9FiKU0UDkwXYag/bhvahTAKECfcWJrMGL8H6MNZuJYcIUte++QbWMReW2keRI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
following a similar approach to the handling of regular SPIs.

The eSPI registers, previously located in reserved address ranges,
are now adjusted to support MMIO read and write operations correctly
when CONFIG_GICV3_ESPI is enabled.

The availability of eSPIs and the number of emulated extended SPIs
for guest domains is reported by setting the appropriate bits in the
GICD_TYPER register, based on the number of eSPIs requested by the
domain and supported by the hardware. In cases where the configuration
option is disabled, the hardware does not support eSPIs, or the domain
does not request such interrupts, the functionality remains unchanged.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V7:
- minor: renamed vgic_get_rank to vgic_common_rank_offset
- minor: updated comment for vgic_common_rank_offset
- minor: restored comment for vgic_store_irouter
- minor: added sanity checks with asserts to helper functions
- added reviewed-by from Oleksandr Tyshchenko

Changes in V6:
- introduced helper functions: vgic_get_rank and vgic_get_reg_offset to
  avoid boilerplate code and simplify changes
- fixed index initialization in the previous patch ([08/12] xen/arm:
  vgic: add resource management for extended SPIs) and removed index
  conversion for vgic_enable_irqs(), vgic_disable_irqs(),
  vgic_set_irqs_pending(), and vgic_check_inflight_irqs_pending()
- grouped SPI and eSPI registers
- updated the comment for vgic_store_irouter to reflect parameter
  changes
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch

Changes in V5:
- since eSPI-specific defines and macros are now available even when the
  appropriate config is disabled, this allows us to remove many
  #ifdef guards and reuse the existing code for regular SPIs for eSPIs as
  well, as eSPIs are processed similarly. This improves code readability
  and consolidates the register ranges for SPIs and eSPIs in a single
  place, simplifying future changes or fixes for SPIs and their
  counterparts from the extended range
- moved vgic_ext_rank_offset() from
  [08/12] xen/arm: vgic: add resource management for extended SPIs
  as the function was unused before this patch
- added stub implementation of vgic_ext_rank_offset() when CONFIG_GICV3_ESP=
I=3Dn
- removed unnecessary defines for reserved ranges, which were introduced in
  V4 to reduce the number of #ifdefs. The issue is now resolved by
  allowing the use of SPI-specific offsets and reworking the logic

Changes in V4:
- added missing RAZ and write ignore eSPI-specific registers ranges:
  GICD_NSACRnE and GICD_IGRPMODRnE
- changed previously reserved range to cover GICD_NSACRnE and
  GICD_IGRPMODRnE
- introduced GICD_RESERVED_RANGE_START/END defines to remove
  hardcoded values and reduce the number of ifdefs
- fixed reserved ranges with eSPI option enabled: added missing range
  0x0F30-0x0F7C
- updated the logic for domains that do not support eSPI, but Xen is
  compiled with the eSPI option. Now, prior to other MMIO checks, we
  verify whether eSPI is available for the domain or not. If not, it
  behaves as it does currently - RAZ and WI
- fixed print for GICD_ICACTIVERnE
- fixed new lines formatting for switch-case

Changes in V3:
- changed vgic_store_irouter parameters - instead of offset virq is
  used, to remove the additional bool espi parameter and simplify
  checks. Also, adjusted parameters for regular SPI. Since the offset
  parameter was used only for calculating virq number and then reused for
  finding rank offset, it will not affect functionality.
- fixed formatting for goto lables - added newlines after condition
- fixed logs for GICD_ISACTIVERnE and GICD_ICACTIVERnE handlers
- removed #ifdefs in 2 places where they were adjacent and could be merged

Changes in V2:
- add missing rank index conversion for pending and inflight irqs
---
 xen/arch/arm/include/asm/vgic.h |   4 +
 xen/arch/arm/vgic-v3.c          | 203 +++++++++++++++++++++++++-------
 xen/arch/arm/vgic.c             |  22 ++++
 3 files changed, 185 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 24a4a968c3..31b3d3e5ec 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -324,6 +324,10 @@ extern struct vgic_irq_rank *vgic_rank_offset(struct v=
cpu *v,
                                               unsigned int b,
                                               unsigned int n,
                                               unsigned int s);
+extern struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v,
+                                                  unsigned int b,
+                                                  unsigned int n,
+                                                  unsigned int s);
 extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int ir=
q);
 extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4369c55177..8b1c8eef80 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -107,17 +107,12 @@ static uint64_t vgic_fetch_irouter(struct vgic_irq_ra=
nk *rank,
 /*
  * Store an IROUTER register in a convenient way and migrate the vIRQ
  * if necessary. This function only deals with IROUTER32 and onwards.
- *
- * Note the offset will be aligned to the appropriate boundary.
  */
 static void vgic_store_irouter(struct domain *d, struct vgic_irq_rank *ran=
k,
-                               unsigned int offset, uint64_t irouter)
+                               unsigned int virq, uint64_t irouter)
 {
     struct vcpu *new_vcpu, *old_vcpu;
-    unsigned int virq;
-
-    /* There is 1 vIRQ per IROUTER */
-    virq =3D offset / NR_BYTES_PER_IROUTER;
+    unsigned int offset;
=20
     /*
      * The IROUTER0-31, used for SGIs/PPIs, are reserved and should
@@ -673,6 +668,36 @@ write_reserved:
     return 1;
 }
=20
+/*
+ * The assumption is that offsets below espi_base are for
+ * regular SPI, while those at or above are for eSPI.
+ */
+static inline struct vgic_irq_rank *vgic_common_rank_offset(struct vcpu *v=
,
+                                                            unsigned int b=
,
+                                                            uint32_t reg,
+                                                            unsigned int s=
,
+                                                            uint32_t spi_b=
ase,
+                                                            uint32_t espi_=
base)
+{
+    ASSERT(spi_base < espi_base);
+
+    if ( reg < espi_base )
+        return vgic_rank_offset(v, b, reg - spi_base, s);
+    else
+        return vgic_ext_rank_offset(v, b, reg - espi_base, s);
+}
+
+static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base=
,
+                                           uint32_t espi_base)
+{
+    ASSERT(spi_base < espi_base);
+
+    if ( reg < espi_base )
+        return reg - spi_base;
+    else
+        return reg - espi_base;
+}
+
 static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu =
*v,
                                             mmio_info_t *info, uint32_t re=
g,
                                             register_t *r)
@@ -685,13 +710,17 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     {
     case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* We do not implement security extensions for guests, read zero *=
/
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
         goto read_as_zero;
=20
     case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ISENAB=
LER,
+                                       GICD_ISENABLERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
         vgic_lock_rank(v, rank, flags);
         *r =3D vreg_reg32_extract(rank->ienable, info);
@@ -699,8 +728,10 @@ static int __vgic_v3_distr_common_mmio_read(const char=
 *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ICENAB=
LER,
+                                       GICD_ICENABLERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
         vgic_lock_rank(v, rank, flags);
         *r =3D vreg_reg32_extract(rank->ienable, info);
@@ -710,22 +741,29 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     /* Read the pending status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
     case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
         goto read_as_zero;
=20
     /* Read the active status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
         goto read_as_zero;
=20
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
     {
-        uint32_t ipriorityr;
+        uint32_t ipriorityr, offset;
         uint8_t rank_index;
=20
         if ( dabt.size !=3D DABT_BYTE && dabt.size !=3D DABT_WORD ) goto b=
ad_width;
-        rank =3D vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 8, reg, DABT_WORD, GICD_IPRIOR=
ITYR,
+                                       GICD_IPRIORITYRnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
-        rank_index =3D REG_RANK_INDEX(8, reg - GICD_IPRIORITYR, DABT_WORD)=
;
+        offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORIT=
YRnE);
+        rank_index =3D REG_RANK_INDEX(8, offset, DABT_WORD);
=20
         vgic_lock_rank(v, rank, flags);
         ipriorityr =3D ACCESS_ONCE(rank->ipriorityr[rank_index]);
@@ -737,14 +775,17 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     }
=20
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
     {
-        uint32_t icfgr;
+        uint32_t icfgr, offset;
=20
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 2, reg, DABT_WORD, GICD_ICFGR,
+                                       GICD_ICFGRnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
+        offset =3D vgic_get_reg_offset(reg, GICD_ICFGR, GICD_ICFGRnE);
         vgic_lock_rank(v, rank, flags);
-        icfgr =3D rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR, DABT_WORD=
)];
+        icfgr =3D rank->icfg[REG_RANK_INDEX(2, offset, DABT_WORD)];
         vgic_unlock_rank(v, rank, flags);
=20
         *r =3D vreg_reg32_extract(icfgr, info);
@@ -782,12 +823,16 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
     {
     case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* We do not implement security extensions for guests, write ignor=
e */
         goto write_ignore_32;
=20
     case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ISENAB=
LER,
+                                       GICD_ISENABLERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
         vgic_lock_rank(v, rank, flags);
         tr =3D rank->ienable;
@@ -797,8 +842,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ICENAB=
LER,
+                                       GICD_ICENABLERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
         vgic_lock_rank(v, rank, flags);
         tr =3D rank->ienable;
@@ -808,8 +855,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISPENDR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ISPEND=
R,
+                                       GICD_ISPENDRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
=20
         vgic_set_irqs_pending(v, r, rank->index);
@@ -817,8 +866,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICPENDR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ICPEND=
R,
+                                       GICD_ICPENDRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
=20
         vgic_check_inflight_irqs_pending(v, rank->index, r);
@@ -826,28 +877,42 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
         goto write_ignore;
=20
     case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        printk(XENLOG_G_ERR
-               "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER=
%d\n",
-               v, name, r, reg - GICD_ISACTIVER);
+        if ( reg < GICD_ISACTIVERnE )
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ISACT=
IVER%d\n",
+                   v, name, r, reg - GICD_ISACTIVER);
+        else
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ISACT=
IVER%dE\n",
+                   v, name, r, reg - GICD_ISACTIVERnE);
         return 0;
=20
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-        printk(XENLOG_G_ERR
-               "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER=
%d\n",
-               v, name, r, reg - GICD_ICACTIVER);
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+        if ( reg < GICD_ICACTIVERnE )
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ICACT=
IVER%d\n",
+                   v, name, r, reg - GICD_ICACTIVER);
+        else
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ICACT=
IVER%dE\n",
+                   v, name, r, reg - GICD_ICACTIVERnE);
         goto write_ignore_32;
=20
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
     {
-        uint32_t *ipriorityr, priority;
+        uint32_t *ipriorityr, priority, offset;
=20
         if ( dabt.size !=3D DABT_BYTE && dabt.size !=3D DABT_WORD ) goto b=
ad_width;
-        rank =3D vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 8, reg, DABT_WORD, GICD_IPRIOR=
ITYR,
+                                       GICD_IPRIORITYRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORIT=
YRnE);
         vgic_lock_rank(v, rank, flags);
-        ipriorityr =3D &rank->ipriorityr[REG_RANK_INDEX(8, reg - GICD_IPRI=
ORITYR,
-                                                      DABT_WORD)];
+        ipriorityr =3D &rank->ipriorityr[REG_RANK_INDEX(8, offset, DABT_WO=
RD)];
         priority =3D ACCESS_ONCE(*ipriorityr);
         vreg_reg32_update(&priority, r, info);
         ACCESS_ONCE(*ipriorityr) =3D priority;
@@ -859,17 +924,23 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
         goto write_ignore_32;
=20
     case VRANGE32(GICD_ICFGR + 4, GICD_ICFGRN): /* PPI + SPIs */
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    {
+        uint32_t offset;
+
         /* ICFGR1 for PPI's, which is implementation defined
            if ICFGR1 is programmable or not. We chose to program */
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 2, reg, DABT_WORD, GICD_ICFGR,
+                                       GICD_ICFGRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(reg, GICD_ICFGR, GICD_ICFGRnE);
         vgic_lock_rank(v, rank, flags);
-        vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR,
-                                                     DABT_WORD)],
+        vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, offset, DABT_WORD)=
],
                           r, info);
         vgic_unlock_rank(v, rank, flags);
         return 1;
+    }
=20
     default:
         printk(XENLOG_G_ERR
@@ -1129,6 +1200,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, m=
mio_info_t *info,
             typer |=3D GICD_TYPE_LPIS;
=20
         typer |=3D (v->domain->arch.vgic.intid_bits - 1) << GICD_TYPE_ID_B=
ITS_SHIFT;
+#ifdef CONFIG_GICV3_ESPI
+        if ( v->domain->arch.vgic.nr_espis > 0 )
+        {
+            /* Set eSPI support bit for the domain */
+            typer |=3D GICD_TYPER_ESPI;
+            /* Set ESPI range bits */
+            typer |=3D (DIV_ROUND_UP(v->domain->arch.vgic.nr_espis, 32) - =
1)
+                       << GICD_TYPER_ESPI_RANGE_SHIFT;
+        }
+#endif
=20
         *r =3D vreg_reg32_extract(typer, info);
=20
@@ -1194,6 +1275,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, m=
mio_info_t *info,
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /*
          * Above all register are common with GICR and GICD
          * Manage in common
@@ -1201,6 +1292,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mm=
io_info_t *info,
         return __vgic_v3_distr_common_mmio_read("vGICD", v, info, gicd_reg=
, r);
=20
     case VRANGE32(GICD_NSACR, GICD_NSACRN):
+    case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN):
         /* We do not implement security extensions for guests, read zero *=
/
         goto read_as_zero_32;
=20
@@ -1216,27 +1308,30 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, =
mmio_info_t *info,
         /* Replaced with GICR_ISPENDR0. So ignore write */
         goto read_as_zero_32;
=20
-    case VRANGE32(0x0F30, 0x60FC):
+    case VRANGE32(0x0F30, 0x0FFC):
         goto read_reserved;
=20
     case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019):
+    case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):
     {
         uint64_t irouter;
+        uint32_t offset;
=20
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
-                                DABT_DOUBLE_WORD);
+        rank =3D vgic_common_rank_offset(v, 64, gicd_reg, DABT_DOUBLE_WORD=
,
+                                       GICD_IROUTER, GICD_IROUTERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
+        offset =3D vgic_get_reg_offset(gicd_reg, GICD_IROUTER, GICD_IROUTE=
RnE);
         vgic_lock_rank(v, rank, flags);
-        irouter =3D vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER);
+        irouter =3D vgic_fetch_irouter(rank, offset);
         vgic_unlock_rank(v, rank, flags);
=20
         *r =3D vreg_reg64_extract(irouter, info);
=20
         return 1;
     }
-
-    case VRANGE32(0x7FE0, 0xBFFC):
+    case VRANGE32(0x3700, 0x60FC):
+    case VRANGE32(0xA004, 0xBFFC):
         goto read_reserved;
=20
     case VRANGE32(0xC000, 0xFFCC):
@@ -1382,12 +1477,23 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v,=
 mmio_info_t *info,
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* Above registers are common with GICR and GICD
          * Manage in common */
         return __vgic_v3_distr_common_mmio_write("vGICD", v, info,
                                                  gicd_reg, r);
=20
     case VRANGE32(GICD_NSACR, GICD_NSACRN):
+    case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN):
         /* We do not implement security extensions for guests, write ignor=
e */
         goto write_ignore_32;
=20
@@ -1405,26 +1511,35 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v,=
 mmio_info_t *info,
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
         return 0;
=20
-    case VRANGE32(0x0F30, 0x60FC):
+    case VRANGE32(0x0F30, 0x0FFC):
         goto write_reserved;
=20
     case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019):
+    case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):
     {
         uint64_t irouter;
+        unsigned int offset, virq;
=20
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
-                                DABT_DOUBLE_WORD);
+        rank =3D vgic_common_rank_offset(v, 64, gicd_reg, DABT_DOUBLE_WORD=
,
+                                       GICD_IROUTER, GICD_IROUTERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(gicd_reg, GICD_IROUTER, GICD_IROUTE=
RnE);
         vgic_lock_rank(v, rank, flags);
-        irouter =3D vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER);
+        irouter =3D vgic_fetch_irouter(rank, offset);
         vreg_reg64_update(&irouter, r, info);
-        vgic_store_irouter(v->domain, rank, gicd_reg - GICD_IROUTER, irout=
er);
+        /* There is 1 vIRQ per IROUTER */
+        if ( gicd_reg < GICD_IROUTERnE )
+            virq =3D offset / NR_BYTES_PER_IROUTER;
+        else
+            virq =3D espi_idx_to_intid(offset / NR_BYTES_PER_IROUTER);
+        vgic_store_irouter(v->domain, rank, virq, irouter);
         vgic_unlock_rank(v, rank, flags);
         return 1;
     }
=20
-    case VRANGE32(0x7FE0, 0xBFFC):
+    case VRANGE32(0x3700, 0x60FC):
+    case VRANGE32(0xA004, 0xBFFC):
         goto write_reserved;
=20
     case VRANGE32(0xC000, 0xFFCC):
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 878daa71d4..3efe23e01a 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -170,6 +170,18 @@ int domain_vgic_register(struct domain *d, unsigned in=
t *mmio_count)
 }
=20
 #ifdef CONFIG_GICV3_ESPI
+/*
+ * The function behavior is the same as for regular SPIs (vgic_rank_offset=
),
+ * but it operates with extended SPI ranks.
+ */
+struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b,
+                                           unsigned int n, unsigned int s)
+{
+    unsigned int rank =3D REG_RANK_NR(b, (n >> s));
+
+    return vgic_get_rank(v, rank + EXT_RANK_MIN);
+}
+
 static unsigned int vgic_num_spi_lines(struct domain *d)
 {
     return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
@@ -210,6 +222,16 @@ static unsigned int vgic_num_spi_lines(struct domain *=
d)
     return d->arch.vgic.nr_spis;
 }
=20
+/*
+ * It is expected that, in the case of CONFIG_GICV3_ESPI=3Dn, the function=
 will
+ * return NULL. In this scenario, mmio_read/mmio_write will be treated as
+ * RAZ/WI, as expected.
+ */
+struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b,
+                                           unsigned int n, unsigned int s)
+{
+    return NULL;
+}
 #endif
=20
 static unsigned int vgic_num_alloc_irqs(struct domain *d)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:11:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:11:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110842.1459871 (Exim 4.92)
	(envelope-from )
	id 1uuGIb-0004kg-Qs; Thu, 04 Sep 2025 20:11:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110842.1459871; Thu, 04 Sep 2025 20: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 1uuGIb-0004kP-Mo; Thu, 04 Sep 2025 20:11:13 +0000
Received: by outflank-mailman (input) for mailman id 1110842;
 Thu, 04 Sep 2025 20: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 1uuG9g-00062f-M5
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:02:00 +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 ff3cc75a-89c9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:01:51 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:49 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20: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: ff3cc75a-89c9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qQpxAiXhYi0FOL43BE/vyRI5vVaoTe9nD4O6LCqo855OiUoKpG770NozZ/pH7C5f1fHEAy3LnR7jKnmg+TiCgLv30YiFDkKxC/QgxQBlDFUmldgrPcg/UF/uHn6GJxYHWzflmze4lODosRuhCbMQE3sLif2eJLdmKjBbMKG9Nqh8NclHcl0iVkODEnm/yUN7bCJC1KOwF/SNrikOwRBH7AsLu97cbYkYDqGz793SlufxmmXXhUZznl1AQ9sw/FE8Cuump5Wy1tFQpbh0/IUm66jIVjqZItgoWmqL4o6TVn7RAvpF7QrJf/QfqpJED2tfWmoGXidCyDXdybUZyrFehA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ujJFLWmitcsII9Trys4sWi3B0EXAvym/os6h93KEm9U=;
 b=E1s5EPVmePhHDNAOsL+yIiFO09BrOp1g6q8XNIzBWAm2bkbBBWVbzlwwsoTgxn060Iw3jSbRK2kJ8aoyyTsWpcttvVs1MRvMVgrmwl7QytA6ZJA2D641MMnMDMVU8JVSSL8NM0mvUG7KjicCpZ7DAh4fzm1b3SyR7m9VChDEcQU2NqheyOn3VHM3xB/jFNCKYeLGoPbgXtjTDAwawFhOwIw2ZCWgrPH60hwAvKcC3Xo7sfzLFGyFJAiGcS1Ckpg9+GRXfZ2Bk+QKcPNKTMRHc9c+mb7mR1cpMNckhVsQAsicHo3n5M5qGsOc/bgJs6/KXeIfbX9o7p9TZoWXZnNZAQ==
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=ujJFLWmitcsII9Trys4sWi3B0EXAvym/os6h93KEm9U=;
 b=WtRwJb/6CvGNEg8PgUCq1pB7MDyKx6WsOFmWdP0qAbrMG0Q6cDuN/cDAIsFh7MFKf3u1xlYgHSizuU3G1/vGtL3AhZ7Sj8rjMFl3WggM/MYB8rRY6DBtuUq1i8pI4dNpiO5iNG13qx5+yQgAMunDzTuUSj3mA+RDVj6S8ztoI4Zp9mKOE3J1qGH9/6j4k4XrOcsRPYQ3L/vxs46xnhhmy3NVe1bChuQhToQ/yiBAFLArKHvQofEgG4vncKooVwJoNCSmOfmbYq5qwb3m50S3sHY6ePEKdUj7161el/Vb5n/fAwO1j98jPQFuNFhJ+3nUNpYNIqivr1v7OXnLqw4jbA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Anthony PERARD 
Subject: [PATCH v7 11/12] doc/man: update description for nr_spis with eSPI
Thread-Topic: [PATCH v7 11/12] doc/man: update description for nr_spis with
 eSPI
Thread-Index: AQHcHda/fAGGraP6Q0Ofqx0FuB+e7w==
Date: Thu, 4 Sep 2025 20:01:49 +0000
Message-ID:
 <9a6568f7f470af79ee324b481983d2353554e9f1.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: b162c01c-f86f-4c04-05b3-08ddebede26f
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:
 =?iso-8859-1?Q?X+b/vA6jeeNhxPeF6XYjLlTX0nbjLStNYov8L9NxcYoIXlGCt98SAlaSpW?=
 =?iso-8859-1?Q?jQK6dY7K8J23A4nwGIVM7IHaN4OTAvGJKPjSfHAOtnwVZYpm4956tL687Q?=
 =?iso-8859-1?Q?SJO22oUWmUx8zutiIDIgA63OZXL0vyQ95jhEMgnAJ+XCFz7beCQtfWznsI?=
 =?iso-8859-1?Q?Tva4lV1rBKHoHaKYcQIQ+jM/o5cN8ubxCN4/AKoQQHvW377GFPCeP12p4X?=
 =?iso-8859-1?Q?ViHsz3up4YeJmoK7ae70Y+JPSQuOPOif5rFswtS3+If1JuTmoEQRhtRGNh?=
 =?iso-8859-1?Q?/cgwDqM0q2O9cbQL0/ic/P7s14VD0NrFcPL20vqzHiWMIxq31y05pRyqXG?=
 =?iso-8859-1?Q?MBPhzcC7XUZE8cFvLQI/0vGcjfqG0yBqlKFq1j1Sg9NN+h4bz2HaU1vIe2?=
 =?iso-8859-1?Q?1099gniGBGPscnX2ebTWz9I/hQdAo9b2X6tjJxHUsg9eLFcJyza5EM63ui?=
 =?iso-8859-1?Q?I1Jyo0tAaGe3umcDKouu61/yqYQcgjGnNREgxVnZZSSv+kFquXwcBXsokO?=
 =?iso-8859-1?Q?EcywIj5zz9DZpTbJNZD+Z0eMA6aARNPonpQPkWknu0OcsRcJStjICyvew9?=
 =?iso-8859-1?Q?I54zgoxSVQmPTZY6z8Ymv7I148Vde0XvGub0OVS/Rnb8bJJx0Ndncld5OG?=
 =?iso-8859-1?Q?QPDRdRHmwDbeH7vfxSl4gkKrfkZrQ2JYhlI7Thj+YsJoU6AcOYZECYldPe?=
 =?iso-8859-1?Q?wb4Sp8hovysiMeLSXgV8bXmmci1qu0XzGlvjIYRocbky7Z0OkHZ7Os5Gz0?=
 =?iso-8859-1?Q?pxT/b8rdivGRUqtinzqHXrmojsVgupdbB4petHKw3f9Byii6eEbmQF0GlR?=
 =?iso-8859-1?Q?w/aXPLhTYcCh4yCcIH14ncIkfPoVszIhm2zSO4BUGXmnu0Enbn0gF/MItm?=
 =?iso-8859-1?Q?xhlM0Zs11qNGA88Y1MNsqGPWInNaEXMB3qljdhQdkrT8f8Jl36zEkxYX0u?=
 =?iso-8859-1?Q?JDa8K/zqFdBZULZbq0fpcIObBIfO4z9J4kdfcv3ZvVCgnfFg+hj2ABolm6?=
 =?iso-8859-1?Q?kC1oYE3ZIfzKS0q9MV1R2Q/G3ocvrKbPjJgFaLOq9e2JHKHeJiZplAa2dJ?=
 =?iso-8859-1?Q?K+wRPiTqjMsoitEYBZFApdx7pMY2y3hFcTQfOGBRfov/iouwL/gTpmXRPx?=
 =?iso-8859-1?Q?ATUR/lBSOSbU/kwqVFoPKp8Jre+H3XIho2kMt9P2KqE6kArDcvgCv4vK6x?=
 =?iso-8859-1?Q?vRB3i5UYz6dzKX1gtBVamxSUADZcqamc16whLrwkS4HfdSZmZZYauDkOiF?=
 =?iso-8859-1?Q?rTxHhOknKXmvJnp892gsxFNFXoReOez1YxELbz9vO5/SF0ZEC8V+Sff1lk?=
 =?iso-8859-1?Q?Y7Nd3l/SmPaEGQWOmN2yfhKHuQxbrOMx9Yh9B+sMmEAor9aRkG3rd9k14Y?=
 =?iso-8859-1?Q?1dRsSIMtJ3NgL4G6JbIWPjVO0m4M94y9qkZ/cTS/LSXYn1hXPJMun/ItX5?=
 =?iso-8859-1?Q?feVoiGm02OiBvwI96GAWni8M/jhxthPqK7MztKfo/BC6OZWYTxNjpuVBpe?=
 =?iso-8859-1?Q?6Z+VK1QzEgK1RcfN//hD06q9jZferYG10+m9PHW4V80WV2J+rlXY6I2zNd?=
 =?iso-8859-1?Q?/RiE+BU=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?0arlFU7DnPFZUE0SiClLvMR1tZ62p/ToLLOluCdMyDe/bLAmJY7Wo5JI/h?=
 =?iso-8859-1?Q?0i4/LgGr04VnJDijiNjUPM1I4or6D8IOLaTjavsLNQ5pza45FSy7jsp8hm?=
 =?iso-8859-1?Q?qokZET5xXMhVBtnnF27GfF8J2AaSUfcNy5BjTSF+JcN/S+hH/UGnbhxLDi?=
 =?iso-8859-1?Q?msQ4waUP5/odHn8NXtOQL4GkB+6Ks+lObVIFwvFi0Zzh0LpjgeRUYDhJ6V?=
 =?iso-8859-1?Q?rATe+Y18WFR0s1Q/p+mAUO0D8xGg+cIFy98sfdkXK7LXrA+RfecNkIzkzu?=
 =?iso-8859-1?Q?0RfFNT5Na2Lw4D4uemigoaXIm0sT15s+r6/FXgUK9Eh+7df3N/S0OC6bS/?=
 =?iso-8859-1?Q?48A4G7OCZHCe3C4UiGXyTj29kpqcgIoCRJs0eu6NGOMFp9KDTSQDeLdZX5?=
 =?iso-8859-1?Q?6R2MpyjaazPWjYWJ6S4prmvPCH0Aawzp382RKFHvgYHQaI+uX59lgQMJpW?=
 =?iso-8859-1?Q?TWnWv/Fbb4Tcd4sFDTolYNfq8+lCpzbMLE2zoLwDfJY9BPhUi24m/Q7ZEM?=
 =?iso-8859-1?Q?aksZBerad1uj3KSrIjqn8/duiHZOf5IU7FZGKrYMty5v02qJRiGj9d98PW?=
 =?iso-8859-1?Q?TYVM6z063bVoqiWCLujKOtC0TX6H6tbuHONQwLGWUkElE4JQAxwf74w6Nf?=
 =?iso-8859-1?Q?8/6FQ8zBytId7lhThyHVkBSp+FiSqYFxB83OiloisUcnCSEgIKp9sGG+ag?=
 =?iso-8859-1?Q?BZKYcFe6cZb3l36U29CGTR5SItvHyQARg0Z2XHNfCh+xQ0DrPDLT7ZS3Zs?=
 =?iso-8859-1?Q?gNsGOcdqid30rX0DCS86VSc73jd1S8NLxZJEuDDIrUZYQ+q0HUzMconU/P?=
 =?iso-8859-1?Q?nIG0MENJIfHB8Couy4pziRcGq9eXugnd4nMt0lpf1Sd6m15CwHzVElpaTm?=
 =?iso-8859-1?Q?GP6Gm/qSzIwds2xBrq799o3ggjW/ijzyiPzTeIRkuGuTZAS4o8rkyiSJub?=
 =?iso-8859-1?Q?CaK7FGhYsdXZxC/fFfs6ZCnURgAQPL2kWDInQ9ulNqDK6CI/TPXHAFoFHL?=
 =?iso-8859-1?Q?B+DpNmng7UudhaKr4uWo6TdL5AHnEqmSRsXQEIfWzA22EBdv4VVWnL/r+N?=
 =?iso-8859-1?Q?hbw619QrcqW95XGLksFDeyvbgxrGwZtVjWCNwBcGIYbsmisZnp6U+dTPj5?=
 =?iso-8859-1?Q?NBjMrhkBy+jyLjZQqYiju54+dn7uDMpYpeeth0C/SsC+ZLIX9IUu8Ykt9j?=
 =?iso-8859-1?Q?eFiEaPe3vxAW6CaWS1PwRZty88cboHupJZpTWa4Am9L98bSZQuQCjaybXZ?=
 =?iso-8859-1?Q?qH1wpHXOiLFTiGnFRjwk9jdYRtZv1AvZNQbpkzIH8XdCF9gEvKGGbuZbtL?=
 =?iso-8859-1?Q?8aLOLHA6aWsyODvlBhtltpXrjvCb6+b6aLSQhgym6Ra1ZZZv8rZ1mQFXma?=
 =?iso-8859-1?Q?TcalfmN4dkCVTv0cOIx29eQq/ywYgTZJaaR/50BOdBYzOJM3nmoei1K0KX?=
 =?iso-8859-1?Q?cpBymge9YpaKT9BwYci1DaD/3mSn4sWQ8PAH54CBzp/ENTu2slbjoMk+5j?=
 =?iso-8859-1?Q?qWNXJEb71yd/37Kbbw5oZyH2sAR4tDLZDySFmumzKIT6kv10aKh3DkHZVJ?=
 =?iso-8859-1?Q?NCUsyPtIhicAwWM9THSPihrNv3MAxc0jMYOzzMq3LdMNWipGFB7VBmCiX3?=
 =?iso-8859-1?Q?tdwxBuixfY9GS4EYaEd7Zd+GQzcWEMyJ98wBq1jBa8OryBo2pRPzWnoG/F?=
 =?iso-8859-1?Q?qAMlZhQ5lNXMeyMSVjs=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b162c01c-f86f-4c04-05b3-08ddebede26f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:49.5120
 (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: GLD4iIN7uzfRC7rQJdlX1lNbhLHjvFKyHt03ro0bE2YI0V9so0VLyu6w1gMDvba33pGXsGfJl/e/id3hPC/thphsN7m5hIdzGOOs+C8HUas=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

Since eSPI support has been introduced, update the documentation with
the appropriate description.

Signed-off-by: Leonid Komarianskyi 

---
The discussion is ongoing and can be addressed in V5.
Clarification is needed from the maintainers.
Link:
- https://lore.kernel.org/xen-devel/87y0r4z717.fsf@epam.com/

Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- no changes

Changes in V4:
- introduced this patch
---
 docs/man/xl.cfg.5.pod.in | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 5362fb0e9a..292ab10331 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3072,11 +3072,14 @@ interval of colors (such as "0-4").
 =3Ditem B
=20
 An optional integer parameter specifying the number of SPIs (Shared
-Peripheral Interrupts) to allocate for the domain. Max is 960 SPIs. If
-the `nr_spis` parameter is not specified, the value calculated by the tool=
stack
-will be used for the domain. Otherwise, the value specified by the `nr_spi=
s`
-parameter will be used. The number of SPIs should match the highest interr=
upt
-ID that will be assigned to the domain.
+Peripheral Interrupts) to allocate for the domain. Max is 960 for regular =
SPIs
+or 5088 for eSPIs (Extended SPIs). The eSPIs includes an additional 1024 S=
PIs
+from the eSPI range (4096 to 5119) if the hardware supports extended SPIs
+(GICv3.1+) and CONFIG_GICV3_ESPI is enabled. If the `nr_spis` parameter is=
 not
+specified, the value calculated by the toolstack will be used for the doma=
in.
+Otherwise, the value specified by the `nr_spis` parameter will be used. Th=
e
+number of SPIs should match the highest interrupt ID that will be assigned=
 to
+the domain.
=20
 =3Ditem B
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:11:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:11:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110844.1459876 (Exim 4.92)
	(envelope-from )
	id 1uuGIc-0004nA-3x; Thu, 04 Sep 2025 20:11:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110844.1459876; Thu, 04 Sep 2025 20: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 1uuGIb-0004lj-V8; Thu, 04 Sep 2025 20:11:13 +0000
Received: by outflank-mailman (input) for mailman id 1110844;
 Thu, 04 Sep 2025 20:11:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuG9N-0005Me-6B
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:01:41 +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 f8d7a7d0-89c9-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:01:40 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GV2PR03MB10974.eurprd03.prod.outlook.com (2603:10a6:150:27a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 20:01:38 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 20:01: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: f8d7a7d0-89c9-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f8CtVA3ikhWGidGWf+Defmzlw49+ayybGOn+0QQcCjxviKqgPSY58Xk92OKosdLY6exxyUbpukseqkqYusUDNNadzIi7H+smF46p7kr6LbhML5auBbqX68PLcGw6XzqYXlyjJvOLITUevv6Jgq+3Yr3yPsySNFg1yd2goDE/rTHMq/FD3EbnA/1ce50bAffCtW9wDfUlwcoydbK/pOZ+0rgyLXBtDdrdfU5lexrc81O7PeJmyROZjAfzRuIqwyyLPZ71FfdHArPYyCPd1glA/hVKkpcgt6FaZmCijoj9ym0WF/hiKn09n4Jyvhfn2ZAbpkcv7yi2YnHTJKzd18KLdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CVVaVjfnAm7dR2ZDj4Evcs3pc7jrZDaoUZKh2SDsNqk=;
 b=oKZcepzG2qQFkzecupw4khWpi9hM0epE9jjsOaLUeku74lhc0fkVVYcRpwj6smoZHShcDgDs1yFwlbC6XFo1jSl9hTqOenUxZSV5H4J8bweizsZmfHclpGE9hzHmB7d1JpExrFLxzTaCEiJi5Szn/dhaD4/yQ7OWTJmKc+P4AfoPT4S9+Z/X/c0ZJUK3B3xh0pRgOelQUqqySoCpFcedlyUJzN+faLpmAZ3GwO/b5NQdBRt1nA0gVjaECyB9ocoG3bfQb22z7bPfGWuKDOUbV0IuTEWms5/uHVotogqriPFSidWMrxtJVMniNja8gXiYQXbiegg3tDMLvSzjR1uaKQ==
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=CVVaVjfnAm7dR2ZDj4Evcs3pc7jrZDaoUZKh2SDsNqk=;
 b=nBAqqO7QwyibApI+0YXmsctvYHbKd3gFH92aXuLxg4T5oXDzL9yksUUTTAepIS27AAOrweDbNb7gLrx9W/dNpJhwZHS4NHnF6xqvJkLbi8Ez3CRISeJJE0Q/ZGQ9DSstgadhDRIie7mwXQ6xOfdCg75PTGDA7g4KHsYtej9p1ceWS+F/UsFfvrJpVGp6qLM7wHewtGV+ta4EkTVwub2Pyo6RswzYFbdwlSPE22PMIZZkqgDKoIiIrcEXGJFTkSG3r3DiRrbvfEBoG5uTwCputVNeUKeoXYN6FtobAtYh3CRcEx5Dx0sFUhBWFZBZLwm05E5f/sDdSNGnnKPaA5xkxw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk 
Subject: [PATCH v7 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow
 eSPI processing
Thread-Topic: [PATCH v7 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to
 allow eSPI processing
Thread-Index: AQHcHda5M+j2hoU+tUCyZeWEwznwMA==
Date: Thu, 4 Sep 2025 20:01:38 +0000
Message-ID:
 <4a5c8a903c7b03716ea8c76b3e1dafd529a8684e.1757015865.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|GV2PR03MB10974:EE_
x-ms-office365-filtering-correlation-id: 5a186009-ca7e-4c7b-af29-08ddebeddbd6
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:
 =?iso-8859-1?Q?MUGn3C54CYBZNcuhqD88gq9kEUv+R6osyJnlOejlsN60G55ugBR6ROJBCA?=
 =?iso-8859-1?Q?oM6bBTCKhs0YNNhpUBqHy/vPj12fv460DZojX4IiiNh8UKMzzqmD4YHcI1?=
 =?iso-8859-1?Q?VZzebuNVWSNCRnCl+DnzBVtLAmFKbDON9NUrSXSa3oxuPY14UEWD1LgpBu?=
 =?iso-8859-1?Q?sIRMYYDHXzbi/HPCJ0XE3Uo/HWcUI0LlCE6CQaD60T9kHFFLmr/aUoFF7o?=
 =?iso-8859-1?Q?tdsmaL75yQXirhhE2wk8EoMBiIxFbfKNbMNIdxTAaf2gAvJQoMPG+po58W?=
 =?iso-8859-1?Q?l9SLuGWDw7gExRjz8BIE7iLPYsHkASFRb0XrgcYHp7UC8Ty0spaX4/CEM+?=
 =?iso-8859-1?Q?ja8hL4kFAe3nAALWrCev6u4oyvH324kXBktMbM2waAxgFsAyEB4NFsRSes?=
 =?iso-8859-1?Q?GHAfJ3wGQGZmUPExpu/mULmQX7TgX2QAAoJmmDWgKZfAH6+fru4JZgTSFx?=
 =?iso-8859-1?Q?srFTyomXSuOq71V+soswuvPTklPN7JG1NZFCCJ0neYmBLBRC7fbciIVdaD?=
 =?iso-8859-1?Q?5CUgoSNLCcdaJ3DQM3vz3jKI47gTjsNvdtxbHXjQSM8c+doma4dWS4OA1G?=
 =?iso-8859-1?Q?xnFseOA+a/8LzwLAdOYwQZTL8ZTWVS2M8ShFbEwmBNiIovWXXfEqzrE530?=
 =?iso-8859-1?Q?UaB7UYUqF5bohWEbZQOyZGzP2y61i4hh77+hqf1+91zOrEwD/2ZNTmCNyh?=
 =?iso-8859-1?Q?B4UqO5+Ja0pLv3+PzRiYN1OLTk90eNfO28QhQ0VYRdGNtC9M1O9Yf9MTyQ?=
 =?iso-8859-1?Q?1XcrSAKwjcnaWfFKruGXsLbPrlHIRuB72nzYKV1E37Bl7zeqC5ZFYY9QQW?=
 =?iso-8859-1?Q?JH1tqkgxVmFydSJ5I2AeIMoWt2m5IKj35Wm6uZkE9NVRriBQ5MlSy7232G?=
 =?iso-8859-1?Q?+MxznFrQmtiThHoOpWCisZCsFDh7Iazriogujwn+wSbQL8RAVkZeHmIMSK?=
 =?iso-8859-1?Q?eweNkw6ggcdLGiTPkDQ2Tx/NThZraUm0JEF8f4ifPh0LmF7UBriPh9DRF1?=
 =?iso-8859-1?Q?qSTPWBhnpSh6+HGG2kG9R8dIkHXFVpBzXdwNB5wHS3hG2zeB7Xe3C3Wkf+?=
 =?iso-8859-1?Q?Ij8Xmui3NppPeC0Hk1KqR2A5ehmJRHPhkEeHI632W4i+YGQ5rrddrGsq1q?=
 =?iso-8859-1?Q?pfwFsAdRK4E9GRoNDe33gY8PaSrAmMKvj1y944S4947DFHxUs+nTIndJCb?=
 =?iso-8859-1?Q?2f0EHCKasSNasQuk56FlsuG4QMNhY0b6ErB0ppkvywZR2i2Y95UP8CKIGZ?=
 =?iso-8859-1?Q?z/bP1o5ROYFehYCDhwYgsm1BfZlV/BSzTXBV5RBQtwZ2GGfPufAf4fmWyR?=
 =?iso-8859-1?Q?OuBprGVdbYX3C7VFH4EaJLxhH1zWN9dIm5MDGyUKc4GmAOIxkhlC980GQr?=
 =?iso-8859-1?Q?ObYF5EA+IZXQy/pH4xqhgx6FUeY3rhev8InH3I8tC3ZyfaPw9rj0tWKnV4?=
 =?iso-8859-1?Q?rGoJ14KD7W2voY3PekhOZq9pGPbu8zQuCNvwXdTpc1hyKb2aGpmRVrJiiC?=
 =?iso-8859-1?Q?guVbMjEz5apG38O2Dp844JG29WROJlURd2LylGxXr3bw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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:
 =?iso-8859-1?Q?Yx1aCgEMza9iMivl+XOfGTzLiFAJyN+8NDeM4SvHhCMozZENU4BcBqP4To?=
 =?iso-8859-1?Q?pYvnx0vSgTyrhNMz2G1qLzfNCi3AApPzsAYLWMUEe1LeLCkn3UkTvcQ0lT?=
 =?iso-8859-1?Q?f4jfQUD0rhPM+ZECzDqK4B5Nnjt+E/ix8q12/6t6fcDczGe+EI+qtRwcgy?=
 =?iso-8859-1?Q?RD4tOJ7tE1VrojMpWeDSjVzTU5EYp8W2yorP7y+dMtlnDiT0BlZefLMwqn?=
 =?iso-8859-1?Q?NjIh8qMdrPnWhv7nHwB41gVMSPizJRmRGm9nrBaKlGKdxAh9lEemMnEejD?=
 =?iso-8859-1?Q?pOOw/svPKaVjo31dqNdhBm2cx1oVT+icjxcXbTzh9CuKSiNsItkRn+8j35?=
 =?iso-8859-1?Q?8slFHZKtPWsnr80NW8MY8lytz8605CKlCVGRSTXvREmTsGxX4+3HjCi5I0?=
 =?iso-8859-1?Q?WHZc6VpbI6MTCvT/tq+HoBN1JL7eiz0uW37I/0B4u58FePnx13dZlA4zMX?=
 =?iso-8859-1?Q?AeYR5rldtETUI6jIM/qqDuKqKrBmB+1+djDclGSTkxm1IYb3ABbpOZIBg+?=
 =?iso-8859-1?Q?ljqi+nNwfbn5YA+Qft3oLxhnnycgPu+hM9X9kyK/n4MEByEpiNLC2usKK9?=
 =?iso-8859-1?Q?4ZFUlNO2HliThfB+JymTqPT6/LyjGf/4gbvbNINgc/0fG2GQleffSqMGVX?=
 =?iso-8859-1?Q?WJvB+BJaN727wkWWfQijuhF9rcGyqH0HyYeVqpjy/y0AbfrPgJeXpcqQWk?=
 =?iso-8859-1?Q?miplFhCCVITnBaQOjCv+zniJY6nrsgRJukUGKVythGEUZFOjN0UKSCl6HI?=
 =?iso-8859-1?Q?iEz7aapct1jXheG9eIwrJ+5KMpwjweYdyK+eKirL61NZcA2iiudn5MXuII?=
 =?iso-8859-1?Q?Q2zEWhKd+6IzZhh9RGb/kt30KMJnYqu+nc8B+qFDzBnWqsU6T2E+h0MfJj?=
 =?iso-8859-1?Q?lSiAbFT43zRzab5KCzFf8Aocy9IslWCwbobAMvzOD2WVWeZGtuHzhpG9oq?=
 =?iso-8859-1?Q?C3mNtWRZvhyLKxT9zTjLzCcT91z76rY5QbzeLW1t/GvgoXicI5UGbYzjlM?=
 =?iso-8859-1?Q?3DY1YBeTD55TWoLdGO2+SmUg4T9WOsdbrjgX6Utvu6dbsSiWACjPY8J/HS?=
 =?iso-8859-1?Q?1VKN7eqG6HZI8tZ3KnKDKpC3Pqhz/eYhi5WI5Wc35I8dl9XiYMg7aUpkNR?=
 =?iso-8859-1?Q?n8pLFcHFKqbNxA6rSogWILDcE63DbfJ9R34EkWXmCiluVRLSW/basIaZUj?=
 =?iso-8859-1?Q?JFrRsDbfymjb6ZnwlYR5lPS+1qEkahn4AZAH2J6OtmvJtFtohDtV+oRKlN?=
 =?iso-8859-1?Q?gnP9VRn4EKXbNFyNMhVyiaSgIRhNPmolEfaD7cV0XXCmqrA0FzqWnNbeY9?=
 =?iso-8859-1?Q?EluA/Dzeo5Hf9zHnnTYS4Lfr1CV9C2cyyM93G16aLXGLb4EJSlgLK1+fog?=
 =?iso-8859-1?Q?jDMeaqVAzY4+XvH5NqfRmFCT8syP3khtTPNJM9lcVIlDHyXw2mMBgVzkYG?=
 =?iso-8859-1?Q?ttE41e4ewVcquhKR0ogw62PcwIX6TZrdbrPkrVv7rbRhDRExZweBal3Zbd?=
 =?iso-8859-1?Q?oHt35ZJMh1OcM5Cps6r1bcW1LWiQ52/7EYRKfJFg+3Vvdymo7iKgqWEwST?=
 =?iso-8859-1?Q?4u663q+lsbUah6MPNffBAAAxLOMXVdLokuuzD4vOHsRHXoRafAQEM8xMsU?=
 =?iso-8859-1?Q?gMcAtoSDjUgA6ztfNAkgcSxrYdbqAGxqFMBPaw+8nd/m6uB2baApou/+GA?=
 =?iso-8859-1?Q?u9nJbzkSfUMO4k84pNQ=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a186009-ca7e-4c7b-af29-08ddebeddbd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:01:38.4314
 (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: rANL223sGaMFArN0HQNC/lRwT5LRA9R+9As0eIDRFRMGYA0zVhxN0gktlnPZKEocj/atw4CZ6679UEvZneJtCX2ZNB2CmY0u6pbc1YhOZGQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10974

To properly deactivate physical eSPI routed to a domain and allow them to
be retriggered after the initial trigger, the LR needs to be updated. The
current implementation ignores interrupts outside the range specified by
the mask 0x3FF, which only covers IRQ numbers up to 1023. To enable
processing of eSPI interrupts, this patch updates the mask to 0x1FFF.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 

---
Changes in V7:
- added reviewed-by from Volodymyr Babchuk

Changes in V6:
- updated mask to 0x1fff to avoid confusion
- updated commit message
- removed reviewed-by as new changes requires additional confirmation
  from reviewers

Changes in V5:
- no changes

Changes in V4:
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- no changes

Changes in V2:
- remove unnecessary CONFIG_GICV3_ESPI ifdef guard
---
 xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index 3370b4cd52..c373b94d19 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -211,7 +211,7 @@
 #define ICH_LR_VIRTUAL_SHIFT         0
 #define ICH_LR_CPUID_MASK            0x7
 #define ICH_LR_CPUID_SHIFT           10
-#define ICH_LR_PHYSICAL_MASK         0x3ff
+#define ICH_LR_PHYSICAL_MASK         0x1fff
 #define ICH_LR_PHYSICAL_SHIFT        32
 #define ICH_LR_STATE_MASK            0x3
 #define ICH_LR_STATE_SHIFT           62
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:16:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:16:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110889.1459891 (Exim 4.92)
	(envelope-from )
	id 1uuGNM-0006SF-Om; Thu, 04 Sep 2025 20:16:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110889.1459891; Thu, 04 Sep 2025 20:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuGNM-0006S8-La; Thu, 04 Sep 2025 20:16:08 +0000
Received: by outflank-mailman (input) for mailman id 1110889;
 Thu, 04 Sep 2025 20:16: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 1uuGNL-0006S2-MH
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:16:07 +0000
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com
 [2607:f8b0:4864:20::b30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc064b6d-89cb-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 22:16:05 +0200 (CEST)
Received: by mail-yb1-xb30.google.com with SMTP id
 3f1490d57ef6-e96ee32f86bso1691551276.0
 for ; Thu, 04 Sep 2025 13:16:05 -0700 (PDT)
Received: from [10.138.34.110]
 (h96-60-249-169.cncrtn.broadband.dynamic.tds.net. [96.60.249.169])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e9bbe05caf7sm2552164276.18.2025.09.04.13.16.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 13:16: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: fc064b6d-89cb-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757016964; x=1757621764; 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=A1k1lpYZuAqu4iz5Acx22WmfknhU7xGNoe09fZSn97o=;
        b=eNOmMQT21QluU0UbXMCkgCU3SgZafcJkNjZf79VTPkeVitCR1kDnu/sv8FMrBOoCSv
         s7UeXShri9s7Nfg0loBu+CSNg8Gg1Iq/wHhtOJ9qLxraq6hk5xP22cdLEtfWUT0W/re7
         z8Rc3dTnpAU+V8EFG843K8d1VTGOIlxgeBwZbMJNN/VKSsY3/0kAx/Npj8i5zHGUw2Us
         OSJOwLMPIPF62uDhZnPsxdx3oBM4dk7876/QVoHgQDfVEzaqqYOE1BVGyxf0Stwpphvc
         OZMEdlDGwH0MVhI2VpDMqcdOKeIVkF/O6xpUutxe1JOUfBl0fuLnP0qgJKjuM0fqgk+4
         MQyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757016964; x=1757621764;
        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=A1k1lpYZuAqu4iz5Acx22WmfknhU7xGNoe09fZSn97o=;
        b=dEewyNQykWzpRnkPvtUCsm+W8jOmbNuG1HFXtMeXt8ID3oj10hhhPCPt0sYqqlZUf+
         +bkuaSAg9OpPU3eHJTlgdIJYuKzqYP/uOVfXmSlbogsUe//kvWgWgFEkCRFnUy4KpaTL
         4aCtUUvlA5g1ABVlXd10l/kxXUYv7vr7HcENGG4fEoyIwmu2dCVkXL+/fi/kHbTRnfGZ
         ZjnN0lXnrAL+7jhFjD4RsE2oyquFnGrnTrwWfAcTQ4qnW2aSFxitmrvI+C9JlgF1v1Yt
         bYoR5aowzv5RQ5KnwCzAbZCeHppAGhmioWt0fQX6GDf854wbbfMZSCgrNGISW5xzIwWX
         894Q==
X-Forwarded-Encrypted: i=1; AJvYcCXOjc9LlccSLgUa/M722tv5yCE+vb42PRONhxEYhpApaTTjQg+/m+mkjLD3QugPq0kLSuQPyPVXp3M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YycHS/UCKGOq6/M2PWnS/q33y1PQ/rgO/m3Ju2Lb754qy++HvvU
	GDenA/zS/HNlKMVTlChqJJiycg34tL4oXNXEXX9SFn/CKhImz2MkMiq7
X-Gm-Gg: ASbGnctLfgUXcuZAC9nZD1EZwgQOpzkSuBjG/0ArO9B2mC5nz/LN2O3JVeB1hNEpZ/e
	ZrPEAKN54BJI+ymfhj54MgiwPX8M3gfWIDfeKavQ70z45neEUYNhri93n3R1qaiorChVa1XysYP
	NSu5Zc9Nk2BTVunptFJLnu4gZl/6ggiMQKRl/oyxBtfJYUfAcebvlp/jL1ob7V86iQUh/iAy2yN
	NuKesNOJSTzgqedvowSoeOtPatJ3IcjVQZijnJPuz3DTunXMz2eQtV00ni6a26BRTY37I0Z4bxg
	6FVHCVxa/deFy/gdaWxBtV62TdoZIPc4vGYjGRudLs3Mo98CM2OiYjFcA/psM6U/xXy3L3v0VwH
	PbgPW74gpzD3KeGteG0WczLJg55Oq4QKYxXh7HhJQ5e+vIahTrgf5KBqeq95AUrbVnhXu4GZgxR
	Fm30xvK5xBdoJN8oJ197FpB83oRpO3B/pkbbs=
X-Google-Smtp-Source: AGHT+IEQ6QpDFY00OJTcHDsZe1WTRw9DiYaC0dp4ClZOE6GYH7FgsYFa4Oh6myK/B3hrR63vP03Mkw==
X-Received: by 2002:a05:6902:722:b0:e9d:6f90:4ea2 with SMTP id 3f1490d57ef6-e9d6f906b97mr3317218276.41.1757016964039;
        Thu, 04 Sep 2025 13:16:04 -0700 (PDT)
Message-ID: <4bfee720-f117-4ac5-8cf8-8d9e718f6694@gmail.com>
Date: Thu, 4 Sep 2025 16:15:46 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v17 0/4] xen/domain: domain ID allocation
To: dmukhin@xen.org, 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,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Simon Gaiser 
References: <20250829232132.3460081-1-dmukhin@ford.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: <20250829232132.3460081-1-dmukhin@ford.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------fGDeXpi1SQjm1isRPik0W30H"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------fGDeXpi1SQjm1isRPik0W30H
Content-Type: multipart/mixed; boundary="------------VK0TclJNYd1AGnbUk6dwDcHa";
 protected-headers="v1"
From: Demi Marie Obenour 
To: dmukhin@xen.org, 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,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Simon Gaiser 
Message-ID: <4bfee720-f117-4ac5-8cf8-8d9e718f6694@gmail.com>
Subject: Re: [PATCH v17 0/4] xen/domain: domain ID allocation
References: <20250829232132.3460081-1-dmukhin@ford.com>
In-Reply-To: <20250829232132.3460081-1-dmukhin@ford.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=

--------------VK0TclJNYd1AGnbUk6dwDcHa
Content-Type: multipart/mixed; boundary="------------dtq6rM3YkqTpyjNH1vW088nB"

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

On 8/29/25 19:21, dmukhin@xen.org wrote:
> Patch 1 introduces new domid_{alloc,free} calls.
> Patch 2 is a prep change for domain ID allocator test.
> Patch 3 introduces some basic testing for domain ID allocator.
> Patch 4 adjusts create_dom0() messages (use %pd).
>=20
> Link to v16: https://lore.kernel.org/xen-devel/20250812223024.2364749-1=
-dmukhin@ford.com/
> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/2012378054
>=20
> Denis Mukhin (4):
>   xen/domain: unify domain ID allocation
>   tools/include: move xc_bitops.h to xen-tools/bitops.h
>   tools/tests: introduce unit tests for domain ID allocator
>   xen/domain: update create_dom0() messages
>=20
>  .../xen-tools/bitops.h}                       | 16 +++-
>  tools/libs/ctrl/xc_misc.c                     | 13 +--
>  tools/libs/guest/xg_dom_elfloader.c           |  1 -
>  tools/libs/guest/xg_dom_hvmloader.c           |  1 -
>  tools/libs/guest/xg_private.h                 |  2 +-
>  tools/libs/guest/xg_sr_common.h               |  2 -
>  tools/tests/Makefile                          |  1 +
>  tools/tests/domid/.gitignore                  |  2 +
>  tools/tests/domid/Makefile                    | 88 +++++++++++++++++
>  tools/tests/domid/harness.h                   | 54 +++++++++++
>  tools/tests/domid/test-domid.c                | 95 +++++++++++++++++++=

>  xen/arch/arm/domain_build.c                   | 13 ++-
>  xen/arch/x86/setup.c                          | 11 ++-
>  xen/common/Makefile                           |  1 +
>  xen/common/device-tree/dom0less-build.c       | 15 +--
>  xen/common/domain.c                           |  2 +
>  xen/common/domctl.c                           | 43 ++-------
>  xen/common/domid.c                            | 95 +++++++++++++++++++=

>  xen/include/xen/domain.h                      |  3 +
>  xen/lib/find-next-bit.c                       |  5 +
>  20 files changed, 397 insertions(+), 66 deletions(-)
>  rename tools/{libs/ctrl/xc_bitops.h =3D> include/xen-tools/bitops.h} (=
84%)
>  create mode 100644 tools/tests/domid/.gitignore
>  create mode 100644 tools/tests/domid/Makefile
>  create mode 100644 tools/tests/domid/harness.h
>  create mode 100644 tools/tests/domid/test-domid.c
>  create mode 100644 xen/common/domid.c

Would it make sense to support virtualizing the domain ID space?
That would allow the toolstack to only allow a domain to communicate
with other domains of its choosing, rather than with any domain XSM
permits.  This would also allow avoiding domain ID reuse problems,
because a virtual domain ID would stay valid even after the domain
it refers to no longer exists.  It would need to be explicitly released
by the guest kernel before it could refer to a different domain.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------dtq6rM3YkqTpyjNH1vW088nB
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-----

--------------dtq6rM3YkqTpyjNH1vW088nB--

--------------VK0TclJNYd1AGnbUk6dwDcHa--

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

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

iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmi583sACgkQszaHOrMp
8lOjTg/+LyCf1NTwzeWd4/3LxkSgwtOdaTEUN5y+XiR7pb3F4PU7sILOpsogpPeu
+eQK715qqREW1vtqnSan6TVLUqEq+g7qi9cUv7neNnn9fB9Jwf8lcEmRmscoSKl4
m6tT5YgJ7DF6NOwXEMYqKa/HQviE+VZffA1y35jdIBpPtVSB1KbhVS6c1PntyA4G
EiBRJIHx8kppx7HLVeEN6k8upGKMJM6iaXUoxUMAJ5E37PXk1e1wOiAbheu7Nab/
efbaWBmPrFSsK2TQBxW1lCyWpbe3rXU8oaANZ3N770vnpNZIMlRiVhYJVZH4wfhb
Pqg0e5/792SvfsWHFig720BH1VNpgRfQ0tQAaABwxJjwnXzochqKJ7r907G3PvL5
6KVmE0tXcaoG35i7UXEgSJ2vMIDFOR7/IAmiZxR/E3eYxcxm9+5VP7eyh0P90m1n
fkc1fPSNXmaiwWSUWL20PKQItvAcGUetsIqlC0P8jqaG+G9ZbwpSJytWf10oHGYP
Do2dRLSYIxtjswanas7mmjO3Z2BsgiuBL4yxsw81LRDhIsh52bFX7rkCHUyK6ZAY
rld/lp6mwvo1GpafgsrP5Oq848+0Frd3df0uXTWwDpc0n3gB7GUiZNguytOi3IwI
fED/96xZZFaZy5M0FKPmtpf3IMSwcKae4WakuTcW0n8Aqny7o30=
=sFsa
-----END PGP SIGNATURE-----

--------------fGDeXpi1SQjm1isRPik0W30H--


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:36:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:36:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110912.1459902 (Exim 4.92)
	(envelope-from )
	id 1uuGgg-0001f5-GD; Thu, 04 Sep 2025 20:36:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110912.1459902; Thu, 04 Sep 2025 20:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuGgg-0001ey-Au; Thu, 04 Sep 2025 20:36:06 +0000
Received: by outflank-mailman (input) for mailman id 1110912;
 Thu, 04 Sep 2025 20: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 1uuGge-0001es-Ju
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:36:04 +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 c5caf916-89ce-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:36: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 A11E160292;
 Thu,  4 Sep 2025 20:36:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B781C4CEF4;
 Thu,  4 Sep 2025 20:35: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: c5caf916-89ce-11f0-9d12-b5c5bf9af7f9
Date: Thu, 4 Sep 2025 21:35:56 +0100
From: Catalin Marinas 
To: Jinjie Ruan 
Cc: will@kernel.org, oleg@redhat.com, sstabellini@kernel.org,
	mark.rutland@arm.com, ada.coupriediaz@arm.com, mbenes@suse.cz,
	broonie@kernel.org, anshuman.khandual@arm.com, ryan.roberts@arm.com,
	chenl311@chinatelecom.cn, liaochang1@huawei.com,
	kristina.martsenko@arm.com, leitao@debian.org, ardb@kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8 0/8] arm64: entry: Convert to generic irq entry
Message-ID: 
References: <20250815030633.448613-1-ruanjinjie@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250815030633.448613-1-ruanjinjie@huawei.com>

On Fri, Aug 15, 2025 at 11:06:25AM +0800, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the generic entry which makes
> maintainers' work easier and codes more elegant. So also convert arm64
> to use the generic entry infrastructure from kernel/entry/* by
> switching it to generic IRQ entry first, which will make PREEMPT_DYNAMIC
> and PREEMPT_LAZY use the generic entry common code and remove a lot of
> duplicate code.
> 
> Since commit a70e9f647f50 ("entry: Split generic entry into generic
> exception and syscall entry") split the generic entry into generic irq
> entry and generic syscall entry, it is time to convert arm64 to use
> the generic irq entry. And ARM64 will be completely converted to generic
> entry in the upcoming patch series.
> 
> The main convert steps are as follows:
> - Split generic entry into generic irq entry and generic syscall to
>   make the single patch more concentrated in switching to one thing.
> - Make arm64 easier to use irqentry_enter/exit().
> - Make arm64 closer to the PREEMPT_DYNAMIC code of generic entry.
> - Switch to generic irq entry.

I had a read through the patches and this first step looks fine to me.
If Ada or Mark don't spot any problems, I think the series is a
candidate for 6.18.

Acked-by: Catalin Marinas 


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:57:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:57:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110941.1459927 (Exim 4.92)
	(envelope-from )
	id 1uuH0w-0004z0-9Z; Thu, 04 Sep 2025 20:57:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110941.1459927; Thu, 04 Sep 2025 20: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 1uuH0w-0004yt-6T; Thu, 04 Sep 2025 20:57:02 +0000
Received: by outflank-mailman (input) for mailman id 1110941;
 Thu, 04 Sep 2025 20:57:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuH0u-0004yn-Om
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:57:00 +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 b2e6031a-89d1-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:56:59 +0200 (CEST)
Received: from DU5PR03MB10441.eurprd03.prod.outlook.com (2603:10a6:10:516::14)
 by GV1PR03MB10848.eurprd03.prod.outlook.com (2603:10a6:150:211::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 20:56:56 +0000
Received: from DU5PR03MB10441.eurprd03.prod.outlook.com
 ([fe80::eeb8:470:6260:e5f4]) by DU5PR03MB10441.eurprd03.prod.outlook.com
 ([fe80::eeb8:470:6260:e5f4%7]) with mapi id 15.20.9094.016; Thu, 4 Sep 2025
 20:56: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: b2e6031a-89d1-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dQqMa0+8mrLA/eYEtabjOTvR/hJ2pCrAj8fHG3gWdGm+fguk6tFxq8jE/j4c+VZNmlvF1h9V2cV2FgN5FdmjsO4AuBOVF5KwFa5mpwoYFdHxOigbPyo+uTwT8xGgzdX+JgfhL5jc2zz+FIjE59iUYZDcSNiOZq0GaiD9WC8lFFNqFZhg1gWHHxy7jUihp+Ze2ccG3tLxhKT9Cp0Fe1wD8FpWBz+bdPWNGE/BB2exjQ2isORlHyO1r7hJ9xmZ6YArwaJR+PdrVs70HvpTwbXL5D5sgu6iNukOCA4EZONU6muCi6+/O8kE8Kbux3+ByMzsuk/wyBVCqIzfa6YNmqbBrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iJ62jjtDXFCR/N9BXriVKCpNGVnWmAERYE+0vgER46w=;
 b=CGGvMS9gzslx4AI2UTm0eGLrNBzBjjpiRfKIHTHhgjY6jRD7hTO4ihx2KYsj+oXHZ8pue6K8UcsXzaxrPJU1OM24DLgh5mNzeTklJA8eN6zao6w80wPD96pDbZc+5hB4yZtik07QxDe/F+z7EvLslryjxeWML8ofwCIPeBq6HaFFI2DgZFtt20lutpW7NtjoII23VhOb7m8eqam+0sv2sc7tiVCkrIaBrn5dQF2diepWi4sSpk7OCNg+5jjl8whalJz7n5kusXFNDf3puaut32KFCi9G04S6WYeoTXP6QPaN7SRGXqk9gavjA3UYV52JO9+C/2cdYcx/2cLOwa+5XQ==
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=iJ62jjtDXFCR/N9BXriVKCpNGVnWmAERYE+0vgER46w=;
 b=svg4Epiwv/y/3ZvvbMOjCksOZgAtruMvcW3mk9vbwgkBi99XuI/DZRMxdC6Hjas7O6bSeEyDb4T2yJmVrMU90/OoyrF/ggVTePN7SCL1aollzv/5tUAe+VKzXeDLTslr4k99GbqjtYkXmEOo79zp0/AFo+7Uhwr8PjEqrtvjTcZg7E90xtInMQ7zHyrlj6nWOLQDK9QCTzjF96Y2TeDNp66GXAcynkdCXy7BABZ7YSCQ2GVhCqcUxz8auKXeTs2pzXURJ8ghDoiY6rLg7PF6hgWDIMBZi7mmimG6x3d0mZZRMf1+M7VxqIeoRY9dks8KpMM4bIXrZlGxbuhLpsGhFQ==
From: Volodymyr Babchuk 
To: Leonid Komarianskyi 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: Re: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Topic: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHday7CnqNZBtjUqzi3kcZcIrsg==
Date: Thu, 4 Sep 2025 20:56:56 +0000
Message-ID: <87h5xirl66.fsf@epam.com>
References: 
	<8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
In-Reply-To:
 <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
	(Leonid Komarianskyi's message of "Thu, 4 Sep 2025 20:01:24 +0000")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU5PR03MB10441:EE_|GV1PR03MB10848:EE_
x-ms-office365-filtering-correlation-id: b84c6401-81f5-4202-2772-08ddebf595a4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?fPOjfEQv7g9qjW+tH0+OZaViLRNLo8JVrXsvwQbneXxJuWUZUUwpNj1aTi?=
 =?iso-8859-1?Q?ZqZXRCRAJaxzvlHoc0Q6u2qZiA2CP67QBenbENiAGEzdd2MOMahQC1rfyQ?=
 =?iso-8859-1?Q?sZLgCnHDoRKXchDboxbNMEh+pvuAQfMgn+zp/lFHjJ0PGUaVWAMop3JaqC?=
 =?iso-8859-1?Q?LryHzNjtmqVLV939r36L1nw2VT8MuwsCy8zbg300XRwzjf/XbO9V0E4Iqc?=
 =?iso-8859-1?Q?2c9ulG/sYSHWPzo+JU0FS8wCCyWGLa6+/xEsrOtR59KWq26ZlFyKJ6POpc?=
 =?iso-8859-1?Q?6O2XxRYxUEqQYZjPyi8EhosbVaWS0meH9fEExpYMooMeY1Ng16APbye0qe?=
 =?iso-8859-1?Q?upC7Ak4oaACUaIhBlG/Jp8uOsXeyQ7gl94AxPTCXkiutOeKebAwLFIjMkk?=
 =?iso-8859-1?Q?M1EKkEuLlyFXRGdN9ViNR8ZpMaJl7ycBZmMwj3IyS6u7lF0Giw6nYZaPHr?=
 =?iso-8859-1?Q?LUvpqT290TuWuNNK34GYF9HfIGUQ/JrQnA4bE69coJlNRdTeZJzJS9igVE?=
 =?iso-8859-1?Q?HXKKpBCPfOHYxJfy6jS9mfzIQVyZZTCU2HzQjnRa3gJOw8OEWO5tNCRLta?=
 =?iso-8859-1?Q?0B6+xbbjpcfn0A4lok5LsCKFmf/1t8Yz0BY5CvH5wb3/1fRLFme+KuNdnh?=
 =?iso-8859-1?Q?vOJ9O7Xt0OE8HlhRuoSmbApI11uBL6S8JFkTf/WLRlnpYvKJ6PZGq4nbJc?=
 =?iso-8859-1?Q?CVO3urJGbLaHAR4aLTO7W3i4r1TWUCZViEgG5z7pVhSbkD/uI2Fsqe92z3?=
 =?iso-8859-1?Q?umnz/iZfnFRjR/XATUFirhFrlR3hN98V/7Ido2u4/8i+la/uAJU8mfwirF?=
 =?iso-8859-1?Q?1AjL3DOtEsLrPT9JXk92Wq/TgRf95XLkfKJhpZ7TiGQyesESGMIwuoH9xt?=
 =?iso-8859-1?Q?jXhjli1sLT6hLla6oS4LnmX6BlmBwzSXLljMeCCl1YXLEM6kTwIWRejxBr?=
 =?iso-8859-1?Q?tQGqfpafMOE8fRwAThkxPxQB2Bm6/xl8dkp8m1PcBA3mPbsUUO1uJUNFEs?=
 =?iso-8859-1?Q?CJtZu9jOJhiBKHzkSKwYtFUMdM79rbc6fWx/NYOW6wtr5jVjymDwBT8mLN?=
 =?iso-8859-1?Q?ZRt/6FEpzpV5ccE6QKPLrgaQ+kzI1/V/Zz+bKejkAq8JeB0blxugKvRPmB?=
 =?iso-8859-1?Q?3af1cBrZTAA3IG7EQW2N9UEa2OKTXI38oetMX9L4B1hQMsOslOoXnJIN15?=
 =?iso-8859-1?Q?smLzNtJcKwfqnrFjwkzuC/h43nZa6Tn+uJ9jXigKo+aP1hkqqwOWXKuZdO?=
 =?iso-8859-1?Q?ewyB2YRTnqaYUcdG+RW/pSH0BdpOnolv7o4Ib+A81RSD9oU1xhFCZO2Q72?=
 =?iso-8859-1?Q?3lT0MpV4F+bY4luf0xJqt/Gi/n3o1jarS7wyC2QTku4cljwFJP7rUU17ym?=
 =?iso-8859-1?Q?Z1Z/Z+q5tjFKzQylkXqFBJchcUrWgc+tkFeXaM6PvRkx3QnCuRWv4LT9zK?=
 =?iso-8859-1?Q?6uARRPsitOvJIulL+MdwT5Fkp7J5M84a4jMOrV8jwfIyor7JO2V10P4K4m?=
 =?iso-8859-1?Q?RmqWZ5Qwx51Km+ve1AsbGlXMrmKXt8/Nnvw9Rqb9/MfA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10441.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?ty4VBh6bl5NPzrBXmkeneZyojhZtNc6Y+AycjHUdVyT8YMze3ulFis78oG?=
 =?iso-8859-1?Q?UFaL+T9PZLnntXO5XutYVLnZSmNAxZHL3g0+KekP/0QRtXdkkCqIvJFtI/?=
 =?iso-8859-1?Q?+AO6DScQm22EZagTPufsRBW3KiIDwEyphRr5BgphDWng432HnJ2EW+E0JI?=
 =?iso-8859-1?Q?+AEVDIGZ+TOoTp58O83YXTvcOx5FyhB+GGWEG4KxhGpYyQXQWiI726Bhdx?=
 =?iso-8859-1?Q?nmHG7AveVplz8GCvv1s2H7Pa97TFO3cQCLHzFerTuJaJugriUgraUvBW7d?=
 =?iso-8859-1?Q?kln8Irzj8e4aopCShCAqftnBff4jbcq6VsQh8mi8AGMK/M6BW/NraZjHqn?=
 =?iso-8859-1?Q?gFJiPnPYTtFTCi4Bj1tH41QwjQYTJZ5eihz2Rp6qUGL3FLGGyCFVnJJdsV?=
 =?iso-8859-1?Q?9oUVfp9+2DQUhNcqvTsoNuI4RTzsH4SNqAqjo2+THJTVkVmW7MMolCYAhZ?=
 =?iso-8859-1?Q?8A5qbwn3+Lf2iNAVozDVzihpAkQNscxRfNcdlGxR6dj0M+bPR6qqcpx7oi?=
 =?iso-8859-1?Q?3LVAjZxNvfPEU9yn4bjqgDT+/zuKdMIL71BJ6Y2YST/GsetLnQxxM6ueC5?=
 =?iso-8859-1?Q?MVfdTEm7YbBS1wUZL5duAS5kdZyZWzx8UFSU3fDjQMa+GSiwtjOqF/ukxF?=
 =?iso-8859-1?Q?egi1Or19Fq3ZF2ts6+HVS68ZnZ78sFZ4KPLCZeZ4Up3cxqsIfh1umI6bTJ?=
 =?iso-8859-1?Q?jbpRcCBN54r3Bv0x7ft9GOXGDjCgMSq7GeLBqa0RxUeTSWl6gKoOLOyfNP?=
 =?iso-8859-1?Q?iKSXZbICfKekL3hqaEBIgM4pRVZi7h/9AgY5caaZPLTm/EHP4o+flQk0zw?=
 =?iso-8859-1?Q?qvsyrO6Yb0bpODpLsiqqrdGE47ImFu9npG0bMPzzro9UeEUIWHXA5lQoK3?=
 =?iso-8859-1?Q?TAt94Qthr4ZHys7lv+ZqlQm+VW/LWtgw8BY1HMfwRl4A+7brawzjYpMrXp?=
 =?iso-8859-1?Q?OVqqYyG0kMMxacagwLiI0KxibM3+mMyX01NQLt2mZtlFLDqb+lq16PpJcw?=
 =?iso-8859-1?Q?GnWZV/vHOtxeElQ6UD/zdQeFIGnHmN2+TXgnCLxQgERagDLeE3VqBCKBji?=
 =?iso-8859-1?Q?UyOqalASSuYODvDMDZPWiMNkhettxzkHtjxuGO5ROY6gfU1en2PgnHay+p?=
 =?iso-8859-1?Q?QHr9mbvaMpKYlA9woGnnTyASuMhmdrkfdHcir/rvtH8YcZI8tFIFyxbO01?=
 =?iso-8859-1?Q?Bj6fxE/SbHru1K2gKgzo2aXmMu5MjN9jM3skB1vqfU8+wjXUR17M+pi0F5?=
 =?iso-8859-1?Q?y+xylZxzqF4vBdZZZVFP20bRZ9e0pDUcIrs36r/jVROiJJaR/cE2rx3+fM?=
 =?iso-8859-1?Q?Xs6c6uNq899t2ywlT+qjJsY6jgwUJqdkmiumr/+C2i84ZjpcWpAg/COi+0?=
 =?iso-8859-1?Q?HQ3V003ZGPGA+5cVVa0UBr9aispvsVVcoTOB/JkKBKS111qlsVqcbUbx7g?=
 =?iso-8859-1?Q?Sj7zFAivGmztRVesvan7liJuQZdFl7+GgHPdB08j5xt4CbWlLImsEiFT/u?=
 =?iso-8859-1?Q?ABT0bUgwByc/1+lzvJ8nKaf9AwLZDX9gPhE2gg+DGBP1NwWSPPORgsejRq?=
 =?iso-8859-1?Q?0807Tn2pSnFsCq1HfMXz0mqOJ9TgF0SH6K9GddeSnydnDBzBvwmy2HBokB?=
 =?iso-8859-1?Q?ZhtGW2nlDPG6rtZ2JyTkw4oSwDzkBWmdzaX56dFQJ5JHiPDJpIjjFkUw?=
 =?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: DU5PR03MB10441.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b84c6401-81f5-4202-2772-08ddebf595a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:56:56.6304
 (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: NP3W/d5GIwCbTJs5qFrCYuqlKoPD/aUCTRIRrXOZmQB38en7f+hBT5Og4LPrO04nJTZjt3w5M0Lma/bI3gNYPAODefW7A31KcQEPOcE+siQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10848

Hi Leonid,

Leonid Komarianskyi  writes:

> Currently, Xen does not support eSPI interrupts, leading
> to a data abort when such interrupts are defined in the DTS.
>
> This patch introduces a separate array to initialize up to
> 1024 interrupt descriptors in the eSPI range and adds the
> necessary defines and helper function. These changes lay the
> groundwork for future implementation of full eSPI interrupt
> support. As this GICv3.1 feature is not required by all vendors,
> all changes are guarded by ifdefs, depending on the corresponding
> Kconfig option.
>
> Signed-off-by: Leonid Komarianskyi 

Reviewed-by: Volodymyr Babchuk 

>
> ---
> Changes in V7:
> - fixed the condition in the is_espi assert for non-eSPI builds: the
>   previous condition was mistakenly added with a wrong check and led to
>   triggering asserts for all non-eSPI INTIDs, when it should be triggered
>   in this case in the other way around
> - minor: used is_espi() in the espi_intid_to_idx() ASSERT, as is_espi
>   performs the same verification
>
> Changes in V6:
> - added an assert in is_espi() when CONFIG_GICV3_ESPI=3Dn to ensure that
>   out-of-range array resources are not accessed, e.g., in __irq_to_desc()
> - removed unnecessary parentheses in is_espi()
> - converted helper macro to inline functions and added sanity checks
>   with ASSERTs to them
> - defined espi_to_desc for non-eSPI builds as a prototype
> - updates the comments
> - used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs
>
> Changes in V5:
> - no functional changes introduced by this version compared with V4, only
>   minor fixes and removal of ifdefs for macroses
> - added TODO comment, suggested by Oleksandr Tyshchenko
> - changed int to unsigned int for irqs
> - removed ifdefs for eSPI-specific defines and macros to reduce the
>   number of ifdefs and code duplication in further changes
> - removed reviewed-by as moving defines from ifdefs requires additional
>   confirmation from reviewers
>
> Changes in V4:
> - removed redundant line with 'default n' in Kconfig, as it is disabled
>   by default, without explicit specification
> - added reviewed-by from Volodymyr Babchuk
>
> Changes in V3:
> - introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
>   case of using NR_IRQS for espi_desc array
> - implemented helper functions espi_to_desc and init_espi_data to make
>   it possible to add stubs with the same name, and as a result, reduce
>   the number of #ifdefs
> - disable CONFIG_GICV3_ESPI default value to n
>
> Changes in V2:
> - use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
> - remove unnecessary comment for nr_irqs initialization
> ---
>  xen/arch/arm/Kconfig           |  8 +++++
>  xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
>  xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
>  3 files changed, 96 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 17df147b25..43b05533b1 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -135,6 +135,14 @@ config GICV3
>  	  Driver for the ARM Generic Interrupt Controller v3.
>  	  If unsure, use the default setting.
> =20
> +config GICV3_ESPI
> +	bool "Extended SPI range support"
> +	depends on GICV3 && !NEW_VGIC
> +	help
> +	  Allow Xen and domains to use interrupt numbers from the extended SPI
> +	  range, from 4096 to 5119. This feature is introduced in GICv3.1
> +	  architecture.
> +
>  config HAS_ITS
>          bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPO=
RTED
>          depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/ir=
q.h
> index 5bc6475eb4..2ff2d07d6d 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>  #define SPI_MAX_INTID   1019
>  #define LPI_OFFSET      8192
> =20
> +#define ESPI_BASE_INTID 4096
> +#define ESPI_MAX_INTID  5119
> +#define NR_ESPI_IRQS    1024
> +
>  /* LPIs are always numbered starting at 8192, so 0 is a good invalid cas=
e. */
>  #define INVALID_LPI     0
> =20
> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>  #define INVALID_IRQ     1023
> =20
>  extern const unsigned int nr_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +/* This will cover the eSPI range, to allow asignmant of eSPIs to domain=
s. */
> +#define nr_static_irqs (ESPI_MAX_INTID + 1)
> +#else
>  #define nr_static_irqs NR_IRQS
> +#endif
> =20
>  struct irq_desc;
>  struct irqaction;
> @@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
>      return irq >=3D LPI_OFFSET;
>  }
> =20
> +static inline bool is_espi(unsigned int irq)
> +{
> +#ifdef CONFIG_GICV3_ESPI
> +    return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID;
> +#else
> +    /*
> +     * The function should not be called for eSPIs when CONFIG_GICV3_ESP=
I is
> +     * disabled. Returning false allows the compiler to optimize the cod=
e
> +     * when the config is disabled, while the assert ensures that out-of=
-range
> +     * array resources are not accessed, e.g., in __irq_to_desc().
> +     */
> +    ASSERT(!(irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID));
> +    return false;
> +#endif
> +}
> +
> +static inline unsigned int espi_intid_to_idx(unsigned int intid)
> +{
> +    ASSERT(is_espi(intid));
> +    return intid - ESPI_BASE_INTID;
> +}
> +
> +static inline unsigned int espi_idx_to_intid(unsigned int idx)
> +{
> +    ASSERT(idx <=3D NR_ESPI_IRQS);
> +    return idx + ESPI_BASE_INTID;
> +}
> +
>  #define domain_pirq_to_irq(d, pirq) (pirq)
> =20
>  bool is_assignable_irq(unsigned int irq);
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index b8eccfc924..c934d39bf6 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -19,7 +19,9 @@
>  #include 
>  #include 
> =20
> -const unsigned int nr_irqs =3D NR_IRQS;
> +const unsigned int nr_irqs =3D IS_ENABLED(CONFIG_GICV3_ESPI) ?
> +                                        (ESPI_MAX_INTID + 1) :
> +                                        NR_IRQS;
> =20
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
> @@ -46,6 +48,50 @@ void irq_end_none(struct irq_desc *irq)
>  }
> =20
>  static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
> +#ifdef CONFIG_GICV3_ESPI
> +/* TODO: Consider allocating an array dynamically */
> +static irq_desc_t espi_desc[NR_ESPI_IRQS];
> +
> +static struct irq_desc *espi_to_desc(unsigned int irq)
> +{
> +    return &espi_desc[espi_intid_to_idx(irq)];
> +}
> +
> +static int __init init_espi_data(void)
> +{
> +    unsigned int irq;
> +
> +    for ( irq =3D ESPI_BASE_INTID; irq <=3D ESPI_MAX_INTID; irq++ )
> +    {
> +        struct irq_desc *desc =3D irq_to_desc(irq);
> +        int rc =3D init_one_irq_desc(desc);
> +
> +        if ( rc )
> +            return rc;
> +
> +        desc->irq =3D irq;
> +        desc->action  =3D NULL;
> +    }
> +
> +    return 0;
> +}
> +#else
> +/*
> + * Defined as a prototype as it should not be called if CONFIG_GICV3_ESP=
I=3Dn.
> + * Without CONFIG_GICV3_ESPI, the additional 1024 IRQ descriptors will n=
ot
> + * be defined, and thus, they cannot be used. Unless INTIDs from the eSP=
I
> + * range are mistakenly defined in Xen DTS when the appropriate config i=
s
> + * disabled, this function will not be reached because is_espi will retu=
rn
> + * false for non-eSPI INTIDs.
> + */
> +struct irq_desc *espi_to_desc(unsigned int irq);
> +
> +static int __init init_espi_data(void)
> +{
> +    return 0;
> +}
> +#endif
> +
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
> =20
>  struct irq_desc *__irq_to_desc(unsigned int irq)
> @@ -53,6 +99,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
>      if ( irq < NR_LOCAL_IRQS )
>          return &this_cpu(local_irq_desc)[irq];
> =20
> +    if ( is_espi(irq) )
> +        return espi_to_desc(irq);
> +
>      return &irq_desc[irq-NR_LOCAL_IRQS];
>  }
> =20
> @@ -79,7 +128,7 @@ static int __init init_irq_data(void)
>          desc->action  =3D NULL;
>      }
> =20
> -    return 0;
> +    return init_espi_data();
>  }
> =20
>  static int init_local_irq_data(unsigned int cpu)

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 20:58:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 20:58:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110952.1459937 (Exim 4.92)
	(envelope-from )
	id 1uuH2l-0005VA-K6; Thu, 04 Sep 2025 20:58:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110952.1459937; Thu, 04 Sep 2025 20:58: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 1uuH2l-0005V3-H9; Thu, 04 Sep 2025 20:58:55 +0000
Received: by outflank-mailman (input) for mailman id 1110952;
 Thu, 04 Sep 2025 20:58: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 1uuH2k-0005Ux-3x
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 20:58:54 +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 f63e5b21-89d1-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 22:58:52 +0200 (CEST)
Received: from DU5PR03MB10441.eurprd03.prod.outlook.com (2603:10a6:10:516::14)
 by GV1PR03MB10848.eurprd03.prod.outlook.com (2603:10a6:150:211::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Thu, 4 Sep
 2025 20:58:47 +0000
Received: from DU5PR03MB10441.eurprd03.prod.outlook.com
 ([fe80::eeb8:470:6260:e5f4]) by DU5PR03MB10441.eurprd03.prod.outlook.com
 ([fe80::eeb8:470:6260:e5f4%7]) with mapi id 15.20.9094.016; Thu, 4 Sep 2025
 20:58: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: f63e5b21-89d1-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PaP7bvoYa+GfxuB3jTl9Pu5qbBGa60WkNwLduECwjtMWyt8aw0qj5tkdVEaH9kDrkWqeyCUtcMDACSCCgOq8i9d0sWvxFna12CcQIzoNH67g97T2AIz/tYuUR9u/eE66kKPgD1uz0SpM+Zo9u5Y5C1ud9LS59EKAA6us6GprtEpxxiZodlLicjRzsigY1gZKlQj3bSbTWjnk4SmL2o2jDQWEm0yGAMrvYjQ1Ie4tdlUzgOq6tBFijFQpgUhp32N9WX29YQ5Lf7phT6fh+fuhNVELGy3+kbXuwO3bulQEL7BeVfzjLa5NvtjmHLkwfYB7wxsTV1GxDpBv26gLkWbMiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MCu1e7+rs5Fohg4UFecIRKOUZ+4F/AqnfVDw9iSbt/E=;
 b=hLpLZ+5CNbIqPcmzav5veQRq0fhh9PasABIoICne7ujmZt5RtAqRPEprReb0SQPvzE+Id4c5e42uE3zYbWzLjgkqcIvU9mHadClSu63Cf6gCqolJpQ3hA0pu3SMfNqao6YonNHO+hy6PHnCMezwPM4zsxtBofOrL5xvKH2YQIDCvfi8jFMT5S3NmAAYOYccwKj/Akv40c5UU1iH6upKz7wEbh5qlUCoAQCBgzyZlrTI288rl6OJQ9P8RmtVcsHP2qHDazlRa6gXuQm1Wl4vJt0lRiGtyjTBU7O/Cpc/fswXuFFC1qTfgJ+9/p7t2t3T4hOXcRV5uLhiWt7PFD/XyDA==
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=MCu1e7+rs5Fohg4UFecIRKOUZ+4F/AqnfVDw9iSbt/E=;
 b=c+LKxhDBxYWB0+zMyR7pEZZOs2EGUktV5npLytaqHhU2JbSumnVvublznRmDyIwVuocx+zew5TjZOoYa3qDWPn+1u8JknNSneYVhKQN6vMLPBUOoXZZJwOI2xcgHuXrCt7jF7meL1EEd8+9NsCGRQNLvrqukQ7O7P72xkZmYTj/eSnK8Bqwji/6OVPWD3Bo0FCYrxtnlgMsnHLhb8gNzZwjdCJhIqAkq8+hwWf47cvFIqA5Lxq18yfTN+u98BS/vZmtfa/WbbPSLQVeVNTMlwopsbSd3pLYGJf2TzFOLP0I/y84BV0PvMiI6CnWUl0H+wp2oXL7rqFO9VbvWCLx8HA==
From: Volodymyr Babchuk 
To: Leonid Komarianskyi 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Oleksandr
 Tyshchenko 
Subject: Re: [PATCH v7 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Topic: [PATCH v7 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcHda81q3nGPOsmUqt6+f7nPiAvw==
Date: Thu, 4 Sep 2025 20:58:47 +0000
Message-ID: <87bjnqrl2x.fsf@epam.com>
References: 
	<5b34940bbc90c4144f4d91880524f452d974d14a.1757015865.git.leonid_komarianskyi@epam.com>
In-Reply-To:
 <5b34940bbc90c4144f4d91880524f452d974d14a.1757015865.git.leonid_komarianskyi@epam.com>
	(Leonid Komarianskyi's message of "Thu, 4 Sep 2025 20:01:42 +0000")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU5PR03MB10441:EE_|GV1PR03MB10848:EE_
x-ms-office365-filtering-correlation-id: b8de6de4-1306-49c4-0fee-08ddebf5d7c0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?41Sa8CyewuDbiEW+qGMOSJbSOcuGybkzU78i+vRENZWeRsp61XI0HmvgOl?=
 =?iso-8859-1?Q?Ht9QPXjjRFPFIXiuuNf6fOSxt1nGcfAggEq6L9gK1i8na6oYRL2v0aNrgX?=
 =?iso-8859-1?Q?jVquepxbimC3WWLrLAJ5H/tEDDiGIG1hMCba10TIz2rkDPt14Sy5cOQBON?=
 =?iso-8859-1?Q?AwFWhAxhJLxLfHtER0nelj6lN5Ah685Sjxxlvaq7MDfp7VvQtnVe/bk5mp?=
 =?iso-8859-1?Q?cKSQKRkDL7HZUEBfpq+MtBxVZ/Mc/11azTvHqsrCSz5NbnZcksFpRKDuXb?=
 =?iso-8859-1?Q?rQaXEllNSOkqWRdgQdgPgxC1aalOEfHC9jLCQDqoq8qBqEBud/BaDaCWD3?=
 =?iso-8859-1?Q?UMYiVw8vXpkxgIec/WGIzccLRfoRaGgdD6fvoMi0q5TlPUEo51She3mGPK?=
 =?iso-8859-1?Q?anrzmlAQb+1gbxXfDL41VoL24K7SgYk9aNrmczFfbGlpLVZXb8HnvhP1SP?=
 =?iso-8859-1?Q?XbkCkXMjOMCzp5WJyv9XBMCDUF84Uu7yBPuQzPgYpvWiVPRlhs2Am1ok2A?=
 =?iso-8859-1?Q?QweohMRiraoq90/7FymGxgBb8+MuD500v7qC0FtI5nsxRLsdnMb7e6s3zt?=
 =?iso-8859-1?Q?9rC+bofg3EbmyxbcHtmshd2nYOjir1kPyAf3SsU1/881ZHIcbAMq3Z89pr?=
 =?iso-8859-1?Q?62MB1rnuypqucC3ovGLe2AH8qaM/UBQJrAH1C9VO1n9wk+9bTaX7AM4mYi?=
 =?iso-8859-1?Q?mpaS9GqKq2AEvNnWErkBjcBC3PZeb4eG7rDZkS1vPhzVPHcIYDTIFTw8aZ?=
 =?iso-8859-1?Q?wWpdnY1UFYgTIKPZFlYoe+4U7/tbZxqPF5L4pjI7wPqGC8BIAyLESA+42l?=
 =?iso-8859-1?Q?obdj+F/5Tew5dvKopYVQEkq+k11kpNxJZRQDMcqzeboU6nTciHKbKAL25n?=
 =?iso-8859-1?Q?L4m06b3REYfzCQFh4tCL9/z2tHy4y20x/sm2HBSUZZp6vFsUYKNdj8I0n9?=
 =?iso-8859-1?Q?oDCsjdCXlZS1AJW/I49/8wHjLzQr8bADfmsT+uD3IqmurvXi+Ri7Y4fZjW?=
 =?iso-8859-1?Q?Jaxlqlx3EnWR+9+wo1dmg8RGXo+GaZutziPIE+eMRq62EfpbdNqLRfvYRa?=
 =?iso-8859-1?Q?xLVbtpDJhiq9Q7YDYNEf1O4C8jyA1JofiXzvrXDZmk+2u7qf5mIXBAuiCG?=
 =?iso-8859-1?Q?9V1q3QPWb79wXK7Q+63ssW9UtRIy6dpmuau7EMuLr6Ybw+hPoIxEwsMb6S?=
 =?iso-8859-1?Q?hZ5QwpGab3qxJ3o5TGowJx1Pt17pxCq8mgBsjkgPPoSlSlSiLF097kGRLW?=
 =?iso-8859-1?Q?TLkYRNbRgGpdbUDspMdNcO6Cglu3lrkD1qW9BhYPfWG3SskAXlTUmqSuDg?=
 =?iso-8859-1?Q?B4OcPdWidU+G2r5VIxVD4lbjqFvFGcP8PS3Z8O8PSLsxsu0Ydy2wx5tkQf?=
 =?iso-8859-1?Q?CN4kfbBfVXg1w56NV8JU6duLKr/HhCPUUfe/up4guRUyG2NNt3I3tj2VmV?=
 =?iso-8859-1?Q?fed5+ybV6RBgJba9gX4XZOLJdLMUNDnBDk1wZXNDt1bHtLDjktaP8otx3E?=
 =?iso-8859-1?Q?yoFgiFbKlFOR5TkmZXR/LuST6ufYZhwrYiw2gZxQowJA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10441.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?cjz31rBH1RJsFfhAUIVjWWtmOZqkPO6Ab7xjZiE1lUcJmjhEbnWx+GOzkI?=
 =?iso-8859-1?Q?wlDnY1HYecgzv3cFLnn9NHL+R7EmU8Vayl7XkiJEWmwJpmBqNlJsJ/Hb+a?=
 =?iso-8859-1?Q?fl7/VgPqUs+a6XYldk0xas/Vx79U+ZtHHJM8YsEWo2NDcUCVTm7CvUEiEA?=
 =?iso-8859-1?Q?y69vrPVIWPNa8zciQS5IEG4W+x1u4keLcMbK3X6SPdQR/b0+MQrjg87UtQ?=
 =?iso-8859-1?Q?vbkmsH4ySuoUikR6jdy0f0h9BD/VTl35+ckuMW0VbdOk5+oNKSdBlAeGIq?=
 =?iso-8859-1?Q?kswEwHrzD+5p1c4HSifV61rpTe71UjNW1o1cGhAQHTy2nG0oYkY5AF8UU5?=
 =?iso-8859-1?Q?SxvmMyQbPt56MSqrlYPgxwdTpg+Z/FBhys+bI2hwMjfiFI3g4qR0VVKpyu?=
 =?iso-8859-1?Q?FM5kkZk1F/sS8xznXJ6iiEO75mk6PIWnlxN3l+KNau01PRsrZKpvw6pzVQ?=
 =?iso-8859-1?Q?kvOvk+aCdDDAHorhoMdvEUUBpzaqU1o7VLkF3cWbdiWhkUN1qGyfwhFuxl?=
 =?iso-8859-1?Q?t/uVPsbyUkNM7xKXlTvgYM6TZXGIxlMq2HwYUpDvuryZVwxniMhQgF2+vY?=
 =?iso-8859-1?Q?C+tb99nakRMivW3Uq6dsstQBsGurvONbl0L5ShE+XJdcay/gsYeQS/Hdh2?=
 =?iso-8859-1?Q?+aStOjBe/pVro7LxFg+ayVk4fkGt17SEk1pmI8hxMUtP0Bbl+fgOnDXCjk?=
 =?iso-8859-1?Q?TljcLAqIRAFGvmHKBWXenQc039QKhTKeOW1BVmGbZTL6THOKeaMfLuymld?=
 =?iso-8859-1?Q?X2MdjOqDzW/IMuMP6M0CPC+ZEyMXWt7rk9LYasjjl6EMhZF4PqClbgHjch?=
 =?iso-8859-1?Q?JyAYz7FRPOJ2j+pARqm3Wa+1Aka4DJa0+T79FKcxhPeTdC9u5o6Ha8JeTD?=
 =?iso-8859-1?Q?s8RD5xaWmEl00VkCm9f08rRQgba8LJDQCEOyCX5tVXAoGgNyipCnM78YfR?=
 =?iso-8859-1?Q?01Do1jfmL4NdBGk2t2hUKH5AdUU7Lvlquq1+xi/o4nesXY76u+gYndyx7n?=
 =?iso-8859-1?Q?RJgAg6QRmwIO5wq/5BAvrJ5i9B4HD3vTrcQ6mrTwKtDDiCHBlGp65vo024?=
 =?iso-8859-1?Q?1v7knby/m+dYcqHvYdiWGb/AxYBrn3ELRizYu8UcuOMKc5zhblPhPKAsrm?=
 =?iso-8859-1?Q?v1hcUu8rsXyJiKmqrGFdjJjnohcc71wjK6G7d8UyQrEcdUG5A/XtSCRUM3?=
 =?iso-8859-1?Q?X9/SojIa5SmXi0MqYTq6vLXTA2EiPZTBZwU6h6kHkOXZD/nardg2oEaV1a?=
 =?iso-8859-1?Q?m0pywSbmAWBMa/dcqCOGxT9udEfM6CRjJcsNYPMThd9J5iH9UOk6io0Hc3?=
 =?iso-8859-1?Q?AT8qOyTnUasNzFma+EUQHIQl0FSIfXdJcve+wc4MMkh4yIr0LCnhfvv6K3?=
 =?iso-8859-1?Q?qieQ/Ax/94eoiqK6wtnHQjRyDpNoF50Tm1TAazMAABgNmA7H6RgPibFA4m?=
 =?iso-8859-1?Q?tWgRqBPkaAvJn5KkVYD81BItTlsJGKYDjMqmCEzk7FgYF7XJaMOPkNoSYl?=
 =?iso-8859-1?Q?uWI5u2+Dd7f5GSYBaFhDj1z7k1dEqWhVG0J83RRW414KmBVbkgnjrsDKUC?=
 =?iso-8859-1?Q?MC1wMvNSo7NOEeI9CPJcW9ZmM5Z0PgaGdvOOOUNsMg/nE2NebUsKWeEvN9?=
 =?iso-8859-1?Q?WhM54P/Ir8SibND2Vkzo/PcALBxHiko4ruDzvLSkrkl7ejGGah39diKg?=
 =?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: DU5PR03MB10441.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8de6de4-1306-49c4-0fee-08ddebf5d7c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2025 20:58:47.5174
 (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: l7t+fOC635mfe8OyiUShwM5NF2rfnT3nHu+I4aw3vvcarLnse0cJWBsp5+wtLqJnUFDEeDP8cF9zNK9nPbDU+ytOY8RCT4Jk+14U5nTEn0E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10848



Leonid Komarianskyi  writes:

> This change introduces resource management in the VGIC to handle
> extended SPIs introduced in GICv3.1. The pending_irqs and
> allocated_irqs arrays are resized to support the required
> number of eSPIs, based on what is supported by the hardware and
> requested by the guest. A new field, ext_shared_irqs, is added
> to the VGIC structure to store information about eSPIs, similar
> to how shared_irqs is used for regular SPIs.
>
> Since the eSPI range starts at INTID 4096 and INTIDs between 1025
> and 4095 are reserved, helper macros are introduced to simplify the
> transformation of indices and to enable easier access to eSPI-specific
> resources. These changes prepare the VGIC for processing eSPIs as
> required by future functionality.
>
> The initialization and deinitialization paths for vgic have been updated
> to allocate and free these resources appropriately. Additionally,
> updated handling of INTIDs greater than 1024, passed from the toolstack
> during domain creation, and verification logic ensures only valid SPI or
> eSPI INTIDs are used.
>
> The existing SPI behavior remains unaffected when guests do not request
> eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
> option is disabled.
>
> Signed-off-by: Leonid Komarianskyi 
> Reviewed-by: Oleksandr Tyshchenko 

Reviewed-by: Volodymyr Babchuk 

>
> ---
> Changes in V7:
> - minor: changed hardcoded value of 32 to NR_LOCAL_IRQS
> - minor: used local variable idx in spi_to_pending() and vgic_reserve_vir=
q()
> - minor: added a comment for allocated_irqs and pending_irqs with index
>   mappings
> - added reviewed-by from Oleksandr Tyshchenko
>
> Changes for V6:
> - introduced a new function for index to virq conversion, idx_to_virq.
>   This allows the removal of eSPI-specific functions and enables the
>   reuse of existing code for regular SPIs
> - fixed the return value of vgic_allocate_virq in the case of eSPI
> - updated the error message in route_irq_to_guest(). To simplify it and
>   avoid overcomplicating with INTID ranges, propose removing the
>   information about the max number of IRQs
> - fixed eSPI rank initialization to avoid using EXT_RANK_IDX2NUM for
>   converting the eSPI rank to the extended range
> - updated the recalculation logic to avoid the nr_spis > 1020 -
>   NR_LOCAL_IRQS check when nr_spis is reassigned in the case of eSPI
> - fixed formatting issues for macros
> - minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
>   into appropriate inline functions introduced in the previous patch
> - minor change: changed int to unsigned int for nr_espis
>
> Changes in V5:
> - removed the has_espi field because it can be determined by checking
>   whether domain->arch.vgic.nr_espis is zero or not
> - since vgic_ext_rank_offset is not used in this patch, it has been
>   moved to the appropriate patch in the patch series, which implements
>   vgic eSPI registers emulation and requires this function
> - removed ifdefs for eSPI-specific macros to reduce the number of ifdefs
>   and code duplication in further changes
> - fixed minor nit: used %pd for printing domain with its ID
>
> Changes in V4:
> - added has_espi field to simplify determining whether a domain is able
>   to operate with eSPI
> - fixed formatting issues and misspellings
>
> Changes in V3:
> - fixed formatting for lines with more than 80 symbols
> - introduced helper functions to be able to use stubs in case of
>   CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of
>   #ifdefs
> - fixed checks for nr_spis in domain_vgic_init
> - updated comment about nr_spis adjustments with dom0less mention
> - moved comment with additional explanations before checks
> - used unsigned int for indexes since they cannot be negative
> - removed unnecessary parentheses
> - move vgic_ext_rank_offset to the below ifdef guard, to reduce the
>   number of ifdefs
>
> Changes in V2:
> - change is_espi_rank to is_valid_espi_rank to verify whether the array
>   element ext_shared_irqs exists. The previous version, is_espi_rank,
>   only checked if the rank index was less than the maximum possible eSPI
>   rank index, but this could potentially result in accessing a
>   non-existing array element. To address this, is_valid_espi_rank was
>   introduced, which ensures that the required eSPI rank exists
> - move gic_number_espis to
>   xen/arm: gicv3: implement handling of GICv3.1 eSPI
> - update vgic_is_valid_irq checks to allow operating with eSPIs
> - remove redundant newline in vgic_allocate_virq
> ---
>  xen/arch/arm/include/asm/vgic.h |  26 ++++-
>  xen/arch/arm/irq.c              |   3 +-
>  xen/arch/arm/vgic.c             | 180 +++++++++++++++++++++++++++++---
>  3 files changed, 193 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/v=
gic.h
> index 3e7cbbb196..caffea092b 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -144,11 +144,25 @@ struct vgic_dist {
>      spinlock_t lock;
>      uint32_t ctlr;
>      int nr_spis; /* Number of SPIs */
> -    unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
> +    /*
> +     * Bitmap of allocated IRQs with the following index mapping:
> +     * Local IRQs [0..31]
> +     * Regular SPIs [32..nr_spis + 31]
> +     * Optional, if supported:
> +     * Extended SPIs [nr_spis + 32..nr_spis + nr_espis + 31]
> +     */
> +    unsigned long *allocated_irqs;
>      struct vgic_irq_rank *shared_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +    struct vgic_irq_rank *ext_shared_irqs;
> +    unsigned int nr_espis; /* Number of extended SPIs */
> +#endif
>      /*
>       * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> -     * struct arch_vcpu.
> +     * struct arch_vcpu. The index mapping is as follows:
> +     * Regular SPIs [0..nr_spis - 1]
> +     * Optional, if supported:
> +     * eSPIs [nr_spis..nr_spis + nr_espis - 1]
>       */
>      struct pending_irq *pending_irqs;
>      /* Base address for guest GIC */
> @@ -243,6 +257,14 @@ struct vgic_ops {
>  /* Number of ranks of interrupt registers for a domain */
>  #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
> =20
> +#ifdef CONFIG_GICV3_ESPI
> +#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis + 31) / 32)
> +#endif
> +#define EXT_RANK_MIN (ESPI_BASE_INTID / 32)
> +#define EXT_RANK_MAX ((ESPI_MAX_INTID + 31) / 32)
> +#define EXT_RANK_NUM2IDX(num) ((num) - EXT_RANK_MIN)
> +#define EXT_RANK_IDX2NUM(idx) ((idx) + EXT_RANK_MIN)
> +
>  #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
>  #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
> =20
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index c934d39bf6..c2f1ceb91f 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -494,8 +494,7 @@ int route_irq_to_guest(struct domain *d, unsigned int=
 virq,
>      if ( !vgic_is_valid_line(d, virq) )
>      {
>          printk(XENLOG_G_ERR
> -               "the vIRQ number %u is too high for domain %u (max =3D %u=
)\n",
> -               irq, d->domain_id, vgic_num_irqs(d));
> +               "invalid vIRQ number %u for domain %pd\n", irq, d);
>          return -EINVAL;
>      }
> =20
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 2bbf4d99aa..878daa71d4 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -25,11 +25,61 @@
>  #include 
> =20
> =20
> +static inline unsigned int idx_to_virq(struct domain *d, unsigned int id=
x)
> +{
> +    if ( idx >=3D vgic_num_irqs(d) )
> +        return espi_idx_to_intid(idx - vgic_num_irqs(d));
> +
> +    return idx;
> +}
> +
>  bool vgic_is_valid_line(struct domain *d, unsigned int virq)
>  {
> +#ifdef CONFIG_GICV3_ESPI
> +    if ( virq >=3D ESPI_BASE_INTID &&
> +         virq < espi_idx_to_intid(d->arch.vgic.nr_espis) )
> +        return true;
> +#endif
> +
>      return virq < vgic_num_irqs(d);
>  }
> =20
> +#ifdef CONFIG_GICV3_ESPI
> +/*
> + * Since eSPI indexes start from 4096 and numbers from 1024 to
> + * 4095 are forbidden, we need to check both lower and upper
> + * limits for ranks.
> + */
> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int ran=
k)
> +{
> +    return rank >=3D EXT_RANK_MIN &&
> +           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d);
> +}
> +
> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
> +                                                       unsigned int rank=
)
> +{
> +    return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]=
;
> +}
> +
> +#else
> +static inline bool is_valid_espi_rank(struct domain *d, unsigned int ran=
k)
> +{
> +    return false;
> +}
> +
> +/*
> + * This function is stub and will not be called if CONFIG_GICV3_ESPI=3Dn=
,
> + * because in this case, is_valid_espi_rank will always return false.
> + */
> +static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
> +                                                       unsigned int rank=
)
> +{
> +    ASSERT_UNREACHABLE();
> +    return NULL;
> +}
> +#endif
> +
>  static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
>                                                    unsigned int rank)
>  {
> @@ -37,6 +87,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struc=
t vcpu *v,
>          return v->arch.vgic.private_irqs;
>      else if ( rank <=3D DOMAIN_NR_RANKS(v->domain) )
>          return &v->domain->arch.vgic.shared_irqs[rank - 1];
> +    else if ( is_valid_espi_rank(v->domain, rank) )
> +        return vgic_get_espi_rank(v, rank);
>      else
>          return NULL;
>  }
> @@ -117,6 +169,54 @@ int domain_vgic_register(struct domain *d, unsigned =
int *mmio_count)
>      return 0;
>  }
> =20
> +#ifdef CONFIG_GICV3_ESPI
> +static unsigned int vgic_num_spi_lines(struct domain *d)
> +{
> +    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
> +}
> +
> +static int init_vgic_espi(struct domain *d)
> +{
> +    unsigned int i, idx;
> +
> +    if ( d->arch.vgic.nr_espis =3D=3D 0 )
> +        return 0;
> +
> +    d->arch.vgic.ext_shared_irqs =3D
> +        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d));
> +    if ( d->arch.vgic.ext_shared_irqs =3D=3D NULL )
> +        return -ENOMEM;
> +
> +    for ( i =3D d->arch.vgic.nr_spis, idx =3D 0;
> +          i < vgic_num_spi_lines(d); i++, idx++ )
> +        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i],
> +                              espi_idx_to_intid(idx));
> +
> +    for ( i =3D 0; i < DOMAIN_NR_EXT_RANKS(d); i++ )
> +        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i],
> +                       EXT_RANK_IDX2NUM(i), 0);
> +
> +    return 0;
> +}
> +
> +#else
> +static int init_vgic_espi(struct domain *d)
> +{
> +    return 0;
> +}
> +
> +static unsigned int vgic_num_spi_lines(struct domain *d)
> +{
> +    return d->arch.vgic.nr_spis;
> +}
> +
> +#endif
> +
> +static unsigned int vgic_num_alloc_irqs(struct domain *d)
> +{
> +    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS;
> +}
> +
>  int domain_vgic_init(struct domain *d, unsigned int nr_spis)
>  {
>      int i;
> @@ -133,7 +233,39 @@ int domain_vgic_init(struct domain *d, unsigned int =
nr_spis)
> =20
>      /* Limit the number of virtual SPIs supported to (1020 - 32) =3D 988=
  */
>      if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
> +#ifndef CONFIG_GICV3_ESPI
>          return -EINVAL;
> +#else
> +    {
> +        /*
> +         * During domain creation, the dom0less DomUs code or toolstack
> +         * specifies the maximum INTID, which is defined in the domain
> +         * config subtracted by 32 to cover the local IRQs (please see
> +         * the comment to VGIC_DEF_NR_SPIS). To compute the actual numbe=
r
> +         * of eSPI that will be usable for, add back 32 (NR_LOCAL_IRQS).
> +         */
> +        nr_spis +=3D NR_LOCAL_IRQS;
> +        if ( nr_spis > espi_idx_to_intid(NR_ESPI_IRQS) )
> +            return -EINVAL;
> +
> +        if ( nr_spis >=3D ESPI_BASE_INTID )
> +        {
> +            unsigned int nr_espis =3D min(nr_spis - ESPI_BASE_INTID, 102=
4U);
> +
> +            /* Verify if GIC HW can handle provided INTID */
> +            if ( nr_espis > gic_number_espis() )
> +                return -EINVAL;
> +
> +            d->arch.vgic.nr_espis =3D nr_espis;
> +            /* Set the maximum available number for regular SPIs */
> +            nr_spis =3D VGIC_DEF_NR_SPIS;
> +        }
> +        else
> +        {
> +            return -EINVAL;
> +        }
> +    }
> +#endif
> =20
>      d->arch.vgic.nr_spis =3D nr_spis;
> =20
> @@ -145,7 +277,7 @@ int domain_vgic_init(struct domain *d, unsigned int n=
r_spis)
>          return -ENOMEM;
> =20
>      d->arch.vgic.pending_irqs =3D
> -        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
> +        xzalloc_array(struct pending_irq, vgic_num_spi_lines(d));
>      if ( d->arch.vgic.pending_irqs =3D=3D NULL )
>          return -ENOMEM;
> =20
> @@ -156,12 +288,16 @@ int domain_vgic_init(struct domain *d, unsigned int=
 nr_spis)
>      for ( i =3D 0; i < DOMAIN_NR_RANKS(d); i++ )
>          vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0);
> =20
> +    ret =3D init_vgic_espi(d);
> +    if ( ret )
> +        return ret;
> +
>      ret =3D d->arch.vgic.handler->domain_init(d);
>      if ( ret )
>          return ret;
> =20
>      d->arch.vgic.allocated_irqs =3D
> -        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
> +        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d=
)));
>      if ( !d->arch.vgic.allocated_irqs )
>          return -ENOMEM;
> =20
> @@ -182,9 +318,12 @@ void domain_vgic_free(struct domain *d)
>      int i;
>      int ret;
> =20
> -    for ( i =3D 0; i < (d->arch.vgic.nr_spis); i++ )
> +    for ( i =3D NR_LOCAL_IRQS; i < vgic_num_alloc_irqs(d); i++ )
>      {
> -        struct pending_irq *p =3D spi_to_pending(d, i + 32);
> +        struct pending_irq *p;
> +        unsigned int virq =3D idx_to_virq(d, i);
> +
> +        p =3D spi_to_pending(d, virq);
> =20
>          if ( p->desc )
>          {
> @@ -198,6 +337,9 @@ void domain_vgic_free(struct domain *d)
>      if ( d->arch.vgic.handler )
>          d->arch.vgic.handler->domain_free(d);
>      xfree(d->arch.vgic.shared_irqs);
> +#ifdef CONFIG_GICV3_ESPI
> +    xfree(d->arch.vgic.ext_shared_irqs);
> +#endif
>      xfree(d->arch.vgic.pending_irqs);
>      xfree(d->arch.vgic.allocated_irqs);
>  }
> @@ -323,10 +465,12 @@ void arch_move_irqs(struct vcpu *v)
>       */
>      ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
> =20
> -    for ( i =3D 32; i < vgic_num_irqs(d); i++ )
> +    for ( i =3D NR_LOCAL_IRQS; i < vgic_num_alloc_irqs(d); i++ )
>      {
> -        v_target =3D vgic_get_target_vcpu(v, i);
> -        p =3D irq_to_pending(v_target, i);
> +        unsigned int virq =3D idx_to_virq(d, i);
> +
> +        v_target =3D vgic_get_target_vcpu(v, virq);
> +        p =3D irq_to_pending(v_target, virq);
> =20
>          if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p-=
>status) )
>              irq_set_affinity(p->desc, cpu_mask);
> @@ -539,15 +683,22 @@ struct pending_irq *irq_to_pending(struct vcpu *v, =
unsigned int irq)
>      else if ( is_lpi(irq) )
>          n =3D v->domain->arch.vgic.handler->lpi_to_pending(v->domain, ir=
q);
>      else
> -        n =3D &v->domain->arch.vgic.pending_irqs[irq - 32];
> +        n =3D spi_to_pending(v->domain, irq);
>      return n;
>  }
> =20
>  struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq)
>  {
> +    unsigned int idx;
> +
>      ASSERT(irq >=3D NR_LOCAL_IRQS);
> =20
> -    return &d->arch.vgic.pending_irqs[irq - 32];
> +    if ( is_espi(irq) )
> +        idx =3D espi_intid_to_idx(irq) + d->arch.vgic.nr_spis;
> +    else
> +        idx =3D irq - NR_LOCAL_IRQS;
> +
> +    return &d->arch.vgic.pending_irqs[idx];
>  }
> =20
>  void vgic_clear_pending_irqs(struct vcpu *v)
> @@ -665,10 +816,15 @@ bool vgic_emulate(struct cpu_user_regs *regs, union=
 hsr hsr)
> =20
>  bool vgic_reserve_virq(struct domain *d, unsigned int virq)
>  {
> +    unsigned int idx =3D virq;
> +
>      if ( !vgic_is_valid_line(d, virq) )
>          return false;
> =20
> -    return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
> +    if ( is_espi(virq) )
> +        idx =3D espi_intid_to_idx(virq) + vgic_num_irqs(d);
> +
> +    return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs);
>  }
> =20
>  int vgic_allocate_virq(struct domain *d, bool spi)
> @@ -685,7 +841,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
>      else
>      {
>          first =3D 32;
> -        end =3D vgic_num_irqs(d);
> +        end =3D vgic_num_alloc_irqs(d);
>      }
> =20
>      /*
> @@ -700,7 +856,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
>      }
>      while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
> =20
> -    return virq;
> +    return idx_to_virq(d, virq);
>  }
> =20
>  void vgic_free_virq(struct domain *d, unsigned int virq)

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 21:52:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 21:52:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111000.1459947 (Exim 4.92)
	(envelope-from )
	id 1uuHry-0004Ya-IF; Thu, 04 Sep 2025 21:51:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111000.1459947; Thu, 04 Sep 2025 21: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 1uuHry-0004YT-Ej; Thu, 04 Sep 2025 21:51:50 +0000
Received: by outflank-mailman (input) for mailman id 1111000;
 Thu, 04 Sep 2025 21:51: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 1uuHrw-0004YN-IE
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 21:51:48 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20606.outbound.protection.outlook.com
 [2a01:111:f403:2409::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59b317c5-89d9-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 23:51:45 +0200 (CEST)
Received: from DM5PR08CA0027.namprd08.prod.outlook.com (2603:10b6:4:60::16) by
 LV8PR12MB9359.namprd12.prod.outlook.com (2603:10b6:408:1fe::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Thu, 4 Sep
 2025 21:51:42 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:4:60:cafe::94) by DM5PR08CA0027.outlook.office365.com
 (2603:10b6:4:60::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Thu,
 4 Sep 2025 21:51:41 +0000
Received: from SATLEXMB03.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.9094.14 via Frontend Transport; Thu, 4 Sep 2025 21:51:40 +0000
Received: from satlexmb10.amd.com (10.181.42.219) 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, 4 Sep
 2025 16:51:40 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Thu, 4 Sep
 2025 14:51:40 -0700
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; Thu, 4 Sep 2025 16:51: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: 59b317c5-89d9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I4v23K34jSdDo+Z1EeNzPUuflJHL4PKh6/ZjgawiYBc31yS4nauZtETFBeuahCj3SqXsuWdr2Wu7WDnxLjDNwVzUoWsDQ4bI89XxPnFs6knjeek7dqKefzwn2PqdH7hbwfBeYNXJMJL5OWcNboSVAd8vTj0gPl0OPpk4wXPdM13j8867Ve8h/5Nuq4IVCgKT19QEbeTzV9nc2D/kUcGIaYpDEJsBe5ZVT89NF8as3Bu4YjoOwpDrrfDdLZKp0OOYl2ljndyI1Yeloh7jxucZpMWfWi8J095xdmsS1zZ8/zUTeR7B+rw2kLzPlGUEYimYmG2gHbkYw/7MVrddt7+lZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=02vFATc04fcvMY/aHiuyddySZsR9XJNjuJlXKYQkPow=;
 b=WDuozskEZwU/GAeZ9Z7KLMKURvTsqeR21Pb3lKYiVfbQho5QJ4SRO8LxHMvIjUDYp0NnPjLKiUnZuM3jSkvAzsomo2P/6fGXfEb1UnvrWKsbkRRpnkxEe8ukwwfqi546yGeOsALiIk3mvIhEikKjyCBflfgK612Ks8muVKUxMp2cgLxFoB/Ob6mZljOkMEYZMKMT9vr5Xga99I0Jw4AcCBZGViBVFpVqye7Aa3wUT5AoOXIQAsSxzK9eKzKhu6msqT08g43/jOhaAx2e6lJZ8a/JDl+ObbYdyfd+huGK5smYzjsM/AeeEOfcai7cKKi/TDxHsEjBtxi/CxX+U07wRw==
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=02vFATc04fcvMY/aHiuyddySZsR9XJNjuJlXKYQkPow=;
 b=Vyio3uJJTehZJRjKXlxqiviplKHe7N7BnfPhDLco2wIeFiulYQA4F/krdDl/E24/2Vn7wa71SiFGzf6q912wcFhlx4NMZofGc8+ffGpbzV5p/e7sd950ulGrSgWodsMbi3jv7iZgkLZGrxuuAqk+rsgjlH8AuR5aGjQWoUxD2hE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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 , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/apic: Avoid infinite loop in io_apic_level_ack_pending()
Date: Thu, 4 Sep 2025 17:51:37 -0400
Message-ID: <20250904215137.135529-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF00017099:EE_|LV8PR12MB9359:EE_
X-MS-Office365-Filtering-Correlation-Id: 8c9237c9-ddab-4a76-5470-08ddebfd3b49
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?olw2FMSwCZP15ET8T/0POEWZjrpexP+5rurZNev4zhEDzuhxnZiJYj1cGipW?=
 =?us-ascii?Q?fmYSxUVi+0DC/rPzqPnpb/tFd4vVzkMxfPIXH3G00fJ6R59IT89KFFnWgtw7?=
 =?us-ascii?Q?KLqOs/Diebvo8CRKWSgA3yBLJw0DP7oEW1axR8+Glylmb9vNpZAzv7JJm5rn?=
 =?us-ascii?Q?3D/PToZQaV6XbHrgAaiboKSVqntGgsgFdox1wJoEH6alrQ/CgWVMfudwJLHw?=
 =?us-ascii?Q?Re/48TGl3FTOsiMkz14A+euga5mwe1Sg7E0ffYNjdP9A3RVAE9LFW+a8OUdL?=
 =?us-ascii?Q?UwNcIzjQUXO95vAunt4PIjMMl7yZXuYPiUVS10xpW5tFPrYh6hWyccpTr95U?=
 =?us-ascii?Q?zR2v4HxeL2boZ8RU8T38jPtKclJ7S24vJKPZSWXsGekRsiFR8EInrPDIhI/h?=
 =?us-ascii?Q?8Pztd2oO7BA55kQ0N3Szz6TR0TNLUqksKyymGa7Kg1kSdlqgRwXXfVvyK8cx?=
 =?us-ascii?Q?Yi1R/PxLy3pBSbL9b5V792Q4jpfE3TbYo4URv1r5NCUtuAv4/bT3Nk8jEkws?=
 =?us-ascii?Q?j8k8eu1Lp0/eNHkhdIw1ZlKdyfTN9tBxcWGg+F5hLG9a+b4f1reOEv1o8xCs?=
 =?us-ascii?Q?s8Kk1xficZlvxU5+Gf5qB4SSRTbRxcw91+5yNI8WpZ+y/P4rTyEeKvMBAXMQ?=
 =?us-ascii?Q?mpsjL7zSCLVFYnDNiVwjK5ow07r7/A/DelYBzGErgVZm/H5rkHYKgU4qJpCN?=
 =?us-ascii?Q?YyuX2CcQr5U+MDT2wdgsldhjWM+TSby4YPAsoevnWJQbhz+QZHHz4pOKfngR?=
 =?us-ascii?Q?DS18cGk8h99WP60jk0/mVf4O/IcrSyTWun8EwPFCCLITjm7m8rNs3D2qmXBa?=
 =?us-ascii?Q?wXFQVKpKfJ1G9BhzU+XjC0xpdqxe05m5orB+0Q3Z/buP78hOP2Kf1AqoZ1MD?=
 =?us-ascii?Q?Ev2y59LRACwd9r3KZazJFKuE+egMnAyKXwJdFGxN+G72PW8DYauCHiNIwHlI?=
 =?us-ascii?Q?6nfZAVoG+I+wSqUXu3FVMnE2quvMB/M6JcytrSur4d5i95HziN4mSMYeJUTN?=
 =?us-ascii?Q?NCiYjBTr/O/RUjfF077q+pOLnDoAbzazdE+/ExnVcyaUEBGOdVUfkGW1oEsr?=
 =?us-ascii?Q?iI/87GpTNAoSF7kxeo8FoAaP8w5DIxLBJGOq/e8L9ce5NW3YCQe0Ei0cBoKc?=
 =?us-ascii?Q?qHyVQwiuVL98OuE3jZMaixx6MJWvrRsLv+s/h9QozKRavHDNmrvhiq2dMkZO?=
 =?us-ascii?Q?pKS7yM2ZfZ7Ns8XcqC06K17MyYrdN1TVvh052naw4VgSoNBRbjHtNf4hvr3n?=
 =?us-ascii?Q?iJydnXMzRjbm2NOansEpc1Igb6WlH0QK3CKB0xbaaA/gfhcl53ce/9jS7eQQ?=
 =?us-ascii?Q?tq29aHFFs38yZv09FMdT5DWNY53E2Cqwghub+Mh+dVm4SKu/yxSomriTwO5h?=
 =?us-ascii?Q?zG7Z8CFjhCHqtO7VF70MapH6Gh5L3RQPxY9o9aKEvS9cUvZzmLE4aeAZWg3B?=
 =?us-ascii?Q?DMNtk35iNm1jPpbmF7Lww4lHNh7XmALVdkmwWF3mTh+44tI5PogEItzbMr8B?=
 =?us-ascii?Q?ga+xk4W3xb0h1xDYOUBHuG52XXQDCQgjEtm5?=
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: 04 Sep 2025 21:51:40.9628
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c9237c9-ddab-4a76-5470-08ddebfd3b49
X-MS-Exchange-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:
	DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9359

io_apic_level_ack_pending() will end up in an infinite loop if
entry->pin == -1.  entry does not change, so it will keep reading -1.

Switched to breaking out of the loop.

Fixes: f821102450a1 ("x86: IRQ Migration logic enhancement.")
Signed-off-by: Jason Andryuk 
---
Noticed during code inspection.
---
 xen/arch/x86/io_apic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 17e6827f4b..b21f0515f5 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1715,7 +1715,7 @@ static bool io_apic_level_ack_pending(unsigned int irq)
 
         pin = entry->pin;
         if (pin == -1)
-            continue;
+            break;
         reg = io_apic_read(entry->apic, 0x10 + pin*2);
         /* Is the remote IRR bit set? */
         if (reg & IO_APIC_REDIR_REMOTE_IRR) {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 04 21:53:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 21:53:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111011.1459957 (Exim 4.92)
	(envelope-from )
	id 1uuHtT-00053D-RT; Thu, 04 Sep 2025 21:53:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111011.1459957; Thu, 04 Sep 2025 21: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 1uuHtT-000536-OS; Thu, 04 Sep 2025 21:53:23 +0000
Received: by outflank-mailman (input) for mailman id 1111011;
 Thu, 04 Sep 2025 21:53: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 1uuHtS-00052u-IV
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 21:53:22 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2417::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91d66909-89d9-11f0-9d12-b5c5bf9af7f9;
 Thu, 04 Sep 2025 23:53:20 +0200 (CEST)
Received: from DS7PR03CA0124.namprd03.prod.outlook.com (2603:10b6:5:3b4::9) by
 SJ5PPFA5F0E981D.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::99d)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.28; Thu, 4 Sep
 2025 21:53:16 +0000
Received: from DS1PEPF0001709A.namprd05.prod.outlook.com
 (2603:10b6:5:3b4:cafe::2d) by DS7PR03CA0124.outlook.office365.com
 (2603:10b6:5:3b4::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9073.27 via Frontend Transport; Thu,
 4 Sep 2025 21:53:16 +0000
Received: from SATLEXMB03.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.9094.14 via Frontend Transport; Thu, 4 Sep 2025 21:53:16 +0000
Received: from satlexmb07.amd.com (10.181.42.216) 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, 4 Sep
 2025 16:53:15 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Thu, 4 Sep
 2025 14:53:15 -0700
Received: from [172.31.134.167] (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, 4 Sep 2025 16:53: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: 91d66909-89d9-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NCg8Met6HEC96Lfkz2cLhNO7FaFbYTOEd67tLi358+VxazoNlHUEE2FRl6Sh6m/BP/JTM4FHR7Jiw652dttj6jwuHTZlQ+Fqaoyrp52bnptkvtPJ9ChzxUSAyNIw7+6va2H5NjePKdCA/o5T7IXbx9YkS9Xhe8H7J96Fi3VVMhLnP5qIC4ogoCdPShwUfqQFi7C0ReoIaPGv6dkIJirYBHeLGD/eb4cvhXPCNDUAE018qbNOynnReief8O0WdwTaHJWZ0+imqp4XIIt4iJag8f1ygRwve9onsrzGDMGeDEm7eV7XElmvCCUVDJtOxKPM/R6MNWbDgXtVeQ9ONgr14A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zLg0Bop3g9RNrWHcZaV6FS1fa74+VJ9gCzTt5m86b3c=;
 b=RHxLlJb7z2Ec/8pyPgEsSCiQkuRzAXx1afAHePUBqQjF750p1pZMg7XtE/kSTSayEuZG5aF+8YlPEiPYMvq8GUeAkCjU13mfLIPbSnrvOfVr6MGTxObcTnL5BbleFVF5Ck458gyBwMDgoiM/F4tvKsi2XXDHIjqLyYKZd1kGk8Jxk9KlMDHnXiaBMX3WoWcMUfFe2nTI0qfqTabS4MxEYSB09bCZgTneW5lpBlxYJVOhNhckyY4wJdOEjjd52BlF4JIJRlJ5n7pP9wboyKBcaSZjk34/WzH6963fLvsyIHx10CdsWvrPb7k1ssCVVx8FQ17LXdFI/l+ZAgAwuGf6GQ==
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=zLg0Bop3g9RNrWHcZaV6FS1fa74+VJ9gCzTt5m86b3c=;
 b=Iq8a42HzSPwYPA7tUo6W4E3Pb6Qi2azdyxc2xXqrRRGRwY028apX8ee3Yla1njxtxiwrEGqQHajgbYH/VEeNPp/x8ejpprNUGco+K6mh0GrGwRevoIVki2Cy6CPs2R0yaqAVPmZ+Bm7yo8ykLjFuBh6vAO4BD1VzTVrQp7t7/iU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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, 4 Sep 2025 17:53:14 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jason Andryuk 
Subject: Re: [PATCH] symbols: discard stray file symbols
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?= 
References: <2412a7a0-bdcd-4647-8ea2-8d2a927dcde3@suse.com>
Content-Language: en-US
In-Reply-To: <2412a7a0-bdcd-4647-8ea2-8d2a927dcde3@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: DS1PEPF0001709A:EE_|SJ5PPFA5F0E981D:EE_
X-MS-Office365-Filtering-Correlation-Id: d797facf-dfa3-42b3-fdab-08ddebfd7415
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?MUJuUnNzaGNsbDJLUjNQMktqdW1IMjM4ejU4bzZzZjd0SWdHNWdOTTQ0RkNY?=
 =?utf-8?B?MytpSDE5ck0rZTB3bUpyWjJGbHpmOGExWm9lTmxBV2dpaWxxc3hBK1MvMXg3?=
 =?utf-8?B?MjY5bGJjSEhQUHkyamVaWENmbHMyVmFiMllsT1dsQ3RNazAwVVVGU01sUXRX?=
 =?utf-8?B?Tjh1eWRBdjcrd3FFVlM1L1M0Y1FYTXhIOUl0Q1Q3MFZRNHkyMWIxZWJxK2xo?=
 =?utf-8?B?dERCd0p0bEtuWGZyeVZGN05td1lRVk1tVUJHSng1TU1rR0RTMnQycVA2d1ZC?=
 =?utf-8?B?NnNVTndkdXVvMVRQamtpN3pWQUQrU3dERXkybWh6Q0VXZDRocG9OWC85bFp3?=
 =?utf-8?B?dHNCVWVCbFk0c0tWYVQrZkE0YWN6MU4vL291ZFN2Tjhybnl0dGlabHRya056?=
 =?utf-8?B?NElsL2ZaWDdDRWZUQWZQa2NDVkp2UGx0QjY5V1gvSDhjcVNaY0pOUE9FZUhu?=
 =?utf-8?B?S2Fsc0NpZGhPY3ByZGgvV3d3Mm96VDBMYU9ESElrOENXZGNQb0JyVHZPdmxX?=
 =?utf-8?B?WDkzNnI5bVVSR2lTVVExOXViMU5FNHFLbDB2YjZxSkwvbTFmRE5Vb2tvWlB1?=
 =?utf-8?B?S0ZncnRSY202VC92YWIwODFpcWhZWExSd0JIK05vUW1JZ2tjZDJTa2tVbUxI?=
 =?utf-8?B?TlR3TFBLV29aZ3pEaDgrdjJvbXJuODgyOUJKcWRCNFNKaDM4WmlKYWw0T3U4?=
 =?utf-8?B?VTY4ODU2WTR3Q2NTSVNCVEVtdmpLUTZzUmx6MUJMa25sT2k4NWpGUHNLOTVs?=
 =?utf-8?B?TnZyR2tLM3l1QlNVK1BqbnJURmNBODFxWG56KzZOdDlSQzF5N3VBdUZGV1or?=
 =?utf-8?B?UllVeEdRSHZtQi9YbFM4QmpESnFJaVJ2Z1RBQ2xSQ3JaaEtxNzZEcjFKTnFt?=
 =?utf-8?B?ek5SNkVMMThreGVrSExEUEsyRUdLZmpNcGQ4aEduMHZsMTZ3Z3g3Y3I0R0or?=
 =?utf-8?B?SUJiUDkwdmd0clhkeHJDTnhwNXNSYzBXUHVZTWQwV2wzRlkrTytMY0tVcmww?=
 =?utf-8?B?aFQwd2djT1ozRlhONEMrZDBaRWc1Mk5hKzhkY3g5aC8vb1hGSDVxczhvZEtX?=
 =?utf-8?B?OHlyOGMzbTVKV3NqQjUraHF6eXpNSGhiT1N3bGdXNWVVTHBiWDhvWEpjcnhq?=
 =?utf-8?B?SVN1UmpMckVJeVpodjBqb1hMVWl3UTN3UHh6bE5IVDEwL3RZbkE5Y2Z4UlFk?=
 =?utf-8?B?UUFKQVlXSmZwOFVaZkJRMTFFR3EwdllNZ0tpd3d6dTdMYzhERlRtYjJ3SWh6?=
 =?utf-8?B?NEZ2eE1VUGFMSUV3eXovOW5SbnRPWUR3RC9uMDFlZEVIbUdnTlNHYThoL0FR?=
 =?utf-8?B?YzNNMFM5akFJMjBXSVRTSHZ3U3pWT0E0NDB4akF2N3lTU1dNWE1MTFR6ZTQ2?=
 =?utf-8?B?Z2NpdDQ0aTM1NFdJR1lMS2pyazIvU3VpOFJmVWhXaWQ5VmFYZzlURkVFM3RL?=
 =?utf-8?B?ZGd1NklhdytTU0F5WUh5dnRHV1doQ2xhSEdQbXFZL2ZQSmU3elplUW83bEpm?=
 =?utf-8?B?L2U4QTdjZmlka3NhWmsyUWR3Wit6N2g1bFBLVE9EcDhIeDZlS1U5a0hjZklN?=
 =?utf-8?B?VjRVU2RLRU9HMGNsV3VwYmM0dTk2eDlDU3F3ei9IcmlLTmw2cmhneW4vWGxz?=
 =?utf-8?B?UEwvREl5WDZWRkJpUEpGVnFOQXpGcE1wZklCOHkvWWk4MUtoTk9QaS9KV0lh?=
 =?utf-8?B?NDVUV2pLWXZFK1lrQmoxZUp0RnA0bDArU1JxNmxkNXBYWnpZQXpST0t2WTJO?=
 =?utf-8?B?L0VlRWJxUkRTTndVRkJXc09ERHYySEwzTjQvWmxxSHFoWWFaVUxKUEY2ZXVH?=
 =?utf-8?B?dTRuQWI2azVGWFdWN05WMER5ak9IaUFZNElEekc5OTFjZjRES1pGWk90aGU4?=
 =?utf-8?B?N3A3Tk04OE5DV3RBQzNweVNqQVR0UUlKcEx1eFpHdkdCM2lXZzhYdTVzdXlq?=
 =?utf-8?B?WjBNQTB3cUZvWVMxK1lUTVdIb2w1MXdVWjdpbEIraXVhVXN4SUxsZVpJVk9X?=
 =?utf-8?B?TW94Rm02SDFKWGdJQ1FGZXJjeUZGTXBTWHEvUmlSbXpKUnpKamRHZGd4TDdO?=
 =?utf-8?Q?0h71yR?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 21:53:16.2571
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d797facf-dfa3-42b3-fdab-08ddebfd7415
X-MS-Exchange-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:
	DS1PEPF0001709A.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPFA5F0E981D

On 2025-04-16 05:00, Jan Beulich wrote:
> By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
> when linking xen.efi. Due to the nature of file symbols in COFF symbol
> tables (see the code comment) the symbols_offsets[] entries for such
> symbols would cause assembler warnings regarding value truncation. Of
> course the resulting entries would also be both meaningless and useless.
> Add a heuristic to get rid of them, really taking effect only when
> --all-symbols is specified (otherwise these symbols are discarded
> anyway).
> 
> Signed-off-by: Jan Beulich 
> ---
> Factor 2 may in principle still be too small: We zap what looks like
> real file symbols already in read_symbol(), so table_cnt doesn't really
> reflect the number of symbol table entries encountered. It has proven to
> work for me in practice though, with still some leeway left.
> 
> --- a/xen/tools/symbols.c
> +++ b/xen/tools/symbols.c
> @@ -213,6 +213,16 @@ static int symbol_valid(struct sym_entry
>   	if (strstr((char *)s->sym + offset, "_compiled."))
>   		return 0;
>   
> +	/* At least GNU ld 2.25 may emit bogus file symbols referencing a
> +	 * section name while linking xen.efi. In COFF symbol tables the
> +	 * "value" of file symbols is a link (symbol table index) to the next
> +	 * file symbol. Since file (and other) symbols (can) come with one
> +	 * (or in principle more) auxiliary symbol table entries, the value in
> +	 * this heuristic is bounded to twice the number of symbols we have
> +	 * found. See also read_symbol() as to the '?' checked for here. */
> +	if (s->sym[0] == '?' && s->sym[1] == '.' && s->addr < table_cnt * 2)
> +		return 0;
> +
>   	return 1;
>   }

I looked at this.  It'll drop symbols, but I don't know enough to give 
an R-b.  I can't give an actionable A-b either.   Maybe someone else can 
chime in.

Maybe this is just showing my lack of knowledge, but could any symbol 
starting "?." be considered invalid?  I don't think I've ever seen any 
like that.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Sep 04 22:15:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Sep 2025 22:15:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111034.1459966 (Exim 4.92)
	(envelope-from )
	id 1uuIEL-0007rL-D7; Thu, 04 Sep 2025 22:14:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111034.1459966; Thu, 04 Sep 2025 22:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuIEL-0007rE-AW; Thu, 04 Sep 2025 22:14:57 +0000
Received: by outflank-mailman (input) for mailman id 1111034;
 Thu, 04 Sep 2025 22:14: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 1uuIEJ-0007r8-AC
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 22:14:55 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 94353f84-89dc-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 00:14:52 +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 2977D1596;
 Thu,  4 Sep 2025 15:14:43 -0700 (PDT)
Received: from [10.57.58.14] (unknown [10.57.58.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 46B793F63F;
 Thu,  4 Sep 2025 15:14: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: 94353f84-89dc-11f0-9809-7dc792cee155
Message-ID: <75db1f58-98b3-463c-af4f-2ce9878cba9f@arm.com>
Date: Fri, 5 Sep 2025 00:14:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
To: Lorenzo Stoakes 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , linux-arm-kernel@lists.infradead.org,
 linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
 <22131943-3f92-4f5a-be28-7b668c07a25c@lucifer.local>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <22131943-3f92-4f5a-be28-7b668c07a25c@lucifer.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04/09/2025 19:28, Lorenzo Stoakes wrote:
> Hi Kevin,
>
> This is causing a build failure:
>
> In file included from ./include/linux/mm.h:31,
>                  from mm/userfaultfd.c:8:
> mm/userfaultfd.c: In function ‘move_present_ptes’:
> ./include/linux/pgtable.h:247:41: error: statement with no effect [-Werror=unused-value]
>   247 | #define arch_enter_lazy_mmu_mode()      (LAZY_MMU_DEFAULT)
>       |                                         ^
> mm/userfaultfd.c:1103:9: note: in expansion of macro ‘arch_enter_lazy_mmu_mode’
>  1103 |         arch_enter_lazy_mmu_mode();
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/pgtable.h:248:54: error: expected expression before ‘)’ token
>   248 | #define arch_leave_lazy_mmu_mode(state) ((void)(state))
>       |                                                      ^
> mm/userfaultfd.c:1141:9: note: in expansion of macro ‘arch_leave_lazy_mmu_mode’
>  1141 |         arch_leave_lazy_mmu_mode();
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~
>
> It seems you haven't carefully checked call sites here, please do very
> carefully recheck these - I see Yeoreum reported a mising kasan case, so I
> suggest you just aggressively grep this + make sure you've covered all
> bases :)

I did check all call sites pretty carefully and of course build-tested,
but my series is based on v6.17-rc4 - just like the calls Yeoreum
mentioned, the issue is that those calls are in mm-stable but not in
mainline :/ I suppose I should post a v2 rebased on mm-stable ASAP then?

- Kevin


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 03:43:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 03:43:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111177.1459989 (Exim 4.92)
	(envelope-from )
	id 1uuNMG-0002Ct-Le; Fri, 05 Sep 2025 03:43:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111177.1459989; Fri, 05 Sep 2025 03:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuNMG-0002Cl-Hd; Fri, 05 Sep 2025 03:43:28 +0000
Received: by outflank-mailman (input) for mailman id 1111177;
 Fri, 05 Sep 2025 03:43: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 1uuNMF-0002Ce-Cg
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 03:43:27 +0000
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [2607:f8b0:4864:20::b2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 749e2de6-8a0a-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 05:43:16 +0200 (CEST)
Received: by mail-yb1-xb2f.google.com with SMTP id
 3f1490d57ef6-e94d678e116so1909009276.2
 for ; Thu, 04 Sep 2025 20:43:16 -0700 (PDT)
Received: from [10.138.34.110]
 (h96-60-249-169.cncrtn.broadband.dynamic.tds.net. [96.60.249.169])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e9bbdf57cc0sm2793700276.13.2025.09.04.20.43.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 20:43: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: 749e2de6-8a0a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757043795; x=1757648595; 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=2zQhNvAcIHUkjaejeDu6urO9HeyOmYI1JdYTW0V/6oU=;
        b=TFKyB0tmDI3fRicnCm4hOmQXBFd8ZY1jTDj3m+OCQmYPPpENuVPiCoNv1/cDnFq8bo
         vonRyO6QYKaqnqzJZgQPxz1dDEBXToLJtDZjhNfMn03z6d4X4PwcPKPlHinqi62bmyvG
         L9S8s927RDxZQZwEKnT4VTNCF40ON5UKRKS1gitWW/mem/tLlxqiHjalCSVtyQPibuTB
         Rhj+UB2LSWsSTLhYiYKV62OlT0sC0lu4YHXAH2XHTzshJJg/kQm1c04xcGv5JlFnov68
         CMeY4Yuda9TCr1wtiYwEe/FZf6FL7qPzIM5rCOcdoWObErldIM+o4GBTS2PTmvdwCjSB
         6iXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757043795; x=1757648595;
        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=2zQhNvAcIHUkjaejeDu6urO9HeyOmYI1JdYTW0V/6oU=;
        b=hOSqwMx2+igg0oIIG7HB2BFI1aGobgERJpTHddobuYtYyvtCbUTi/7xYJAoKJS/Irh
         PJ30a09UrbluWiyLCBOqhM6POJ07tIKP2A4hwpfGCEVMUt1SuAHnqhiaFLcnEURmSXVl
         HC6nzmNoPTHOhOWiZoP3ikt3U37FJOFFySGPtLvGwH5ScYU1LX6iRZucka+GnEvkfl9U
         Adyq9QX9RKcuVeCKSef1kQXNyLw7GOBl01CWYMLrC4lS5sDpKvYuFi2J29RNcCxADsfS
         EuK0rdFP3+QsBPOeHhqpLtmo7kULt1VUBtbZgTS7v3tZXSCndsyjIWEcIMeWbp/Ylt2U
         4WMA==
X-Forwarded-Encrypted: i=1; AJvYcCV7xQG78UEKPXcZUeSH8+dz5MvDcpmaRHhKzIk3u104ipNSsJudO2ruRRmUFClMUcOkc2BC/cprf9A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxU4OwxlCNlJaSM4oA7AQWYnFABu6ZFN1214eCLXdtCFIIDjXve
	iZe28NZkPXIAdM9YeYFfxuPWNhBuE6td2tg/NevxRGoyxsT6OT49aqC0MsyedUxv
X-Gm-Gg: ASbGncvhCBFmfkkOlw3mxxEe/LNiW2N4n02uqsK1qABPyL/oM/yGNLkcoNHftecKJXm
	zOErlWeD6VVcoFQu/fjMKDfUgOPsnXr6cjHUJsA4uscRVXhLDunOkptx1YJnyGcOxf7GrTu6PIL
	gP84nk3gGbsZg/ZIW3l/OyC36U1Ds+glmNq/rBuzY+80sisPApzEyxA+BOTeE+7OlDApLYvs6JM
	Q1SThmhWzU9tp3bADx2OVi5lPR2VcaSAgQMfe/9dv6xV7AYAdD2XQ7z44EqdPi2iF6TdeFoThyW
	ydNvgzbzhz7iEjBi87PcKi14EVPQ9qrcxuy8DPujF2EauKtWJ+sNJ9KJX7kucK5zG6weipvqMTW
	KZqSbh4TO7CmWSaMPXhDUA3A/8QJ7EQyz7OOxKZLYYzq14qCmiWzRtEUkOrWgTu1nv689QCborn
	Zt6HO25HT9oQpsTejfEwkStDJj/lnvBRRhGG29GgAuqjEeUw==
X-Google-Smtp-Source: AGHT+IFbcywim/ULfHO/sn87UU4dLggomtkc8jsuIJQ1l1Jw8gj1yKhtsqyk1CSkx1R1/iv719bTOA==
X-Received: by 2002:a25:8684:0:b0:e97:55f4:3ed3 with SMTP id 3f1490d57ef6-e98a5828076mr19183633276.28.1757043795268;
        Thu, 04 Sep 2025 20:43:15 -0700 (PDT)
Message-ID: <5a6bf835-6c87-4e1d-adfb-a932fa1d7581@gmail.com>
Date: Thu, 4 Sep 2025 23:43:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
To: Grygorii Strashko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.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: <20250806094929.293658-4-grygorii_strashko@epam.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0I9vwDPw0jL26fHBaNe0sM2c"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0I9vwDPw0jL26fHBaNe0sM2c
Content-Type: multipart/mixed; boundary="------------gP1rC7XyTbFWFX13NBMyz0eO";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Grygorii Strashko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
Message-ID: <5a6bf835-6c87-4e1d-adfb-a932fa1d7581@gmail.com>
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
In-Reply-To: <20250806094929.293658-4-grygorii_strashko@epam.com>

--------------gP1rC7XyTbFWFX13NBMyz0eO
Content-Type: multipart/mixed; boundary="------------IwzRKAGR9ZilgszFKbC2Z0QT"

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

On 8/6/25 05:49, Grygorii Strashko wrote:
> From: Grygorii Strashko 
>=20
> Now Arm64 AArch32 guest support is always enabled and built-in while no=
t
> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
> support might not be needed (Arm64 AArch32 is used quite rarely in embe=
dded
> systems). More over, when focusing on safety certification, AArch32 rel=
ated
> code in Xen leaves a gap in terms of coverage that cannot really be
> justified in words. This leaves two options: either support it (lots of=

> additional testing, requirements and documents would be needed) or comp=
ile
> it out.
>=20
> Hence, this patch introduces basic support to allow make Arm64
> AArch32 guest support optional. The following changes are introduced:
>=20
> - Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable=

>   Arm64 AArch32 guest support (default y)
>=20
> - Introduce is_aarch32_enabled() helper which accounts Arm64 HW capabil=
ity
>   and CONFIG_ARM64_AARCH32 setting
>=20
> - Introduce arm64_set_domain_type() to configure Arm64 domain type in
>   unified way instead of open coding (d)->arch.type, and account
>   CONFIG_ARM64_AARCH32 configuration.
>=20
> - toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 i=
s
>   disabled.
>=20
> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>   AArch32 is disabled.
>=20
> - Set Arm64 domain type to DOMAIN_64BIT by default.
>   - the Arm Xen boot code is handling this case properly already;
>   - for toolstack case the XEN_DOMCTL_set_address_size hypercall handli=
ng
>     updated to forcibly configure domain type regardless of current dom=
ain
>     type configuration, so toolstack behavior is unchanged.
>=20
> With CONFIG_ARM64_AARCH32=3Dn the Xen will reject AArch32 guests (kerne=
ls) if
> configured by user in the following way:
> - Xen boot will fail with panic during dom0 or dom0less domains creatio=
n
> - toolstack domain creation will be rejected due to xc_dom_compat_check=
()
>   failure.
>=20
> Making Arm64 AArch32 guest support open further possibilities for build=

> optimizations of Arm64 AArch32 guest support code.
>=20
> Signed-off-by: Grygorii Strashko 
> ---
> changes in v2:
> - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 s=
upport
> - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work w=
ith any
>   initial domain type set (32bit or 64 bit)
> - fix comments related to macro parameters evaluation issues
> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>   AArch32 is disabled
>=20
>  xen/arch/arm/Kconfig                    |  7 ++++
>  xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++--=

>  xen/arch/arm/arm64/domctl.c             | 16 +++++----
>  xen/arch/arm/arm64/vsysreg.c            |  9 +++++
>  xen/arch/arm/domain.c                   |  9 +++++
>  xen/arch/arm/domain_build.c             | 21 +++--------
>  xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
>  xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
>  xen/arch/arm/setup.c                    |  2 +-
>  9 files changed, 119 insertions(+), 26 deletions(-)
>=20
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index a0c816047427..bf6dd73caf73 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
>  	help
>  	  This option enables PCI device passthrough
> =20
> +config ARM64_AARCH32
> +	bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTE=
D
> +	depends on ARM_64
> +	default y
> +	help
> +	  This option enables AArch32 Guests on ARM64.
> +
>  endmenu
Why UNSUPPORTED?  A safety-certified build of Xen should only be using
security-supported features.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------IwzRKAGR9ZilgszFKbC2Z0QT
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-----

--------------IwzRKAGR9ZilgszFKbC2Z0QT--

--------------gP1rC7XyTbFWFX13NBMyz0eO--

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

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

iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmi6XEwACgkQszaHOrMp
8lOMaxAAkFg4L8d7fVNX/HCDNBpDZ1ZZcMeM7100zkxBBHoacHgcG7Pd+TgnwPV9
cqjlVPCKsLmeB/M8CVeu5qn4GvYJeF4x0OarNt/LwVJIxwtiZBZ2v8uFdygy6kXA
6QGKx+FQl9ES6GCAnRhIbZyOi7tpn1tMEI/QYGpPfsNK9YZ3o8Mg9y7/GHxyCGca
ixTEgbBbVJ7pHPhpA3qrEII3IM9bAgNalVdMmiB/kzZLbw03tMKKrtgLcLjfzLTt
+DUtThg/hTTH7Ulec7LDEfvOGV36qAfYWdwviQiVf7gvOoNmJokFSfhNObk2QYTL
w5geqQsWtKiTzHIr6FNYVKV6tlImIHotsBq99A8xHPoPmLuruZq+9jWQ9iNESJhe
VNaXv6F2xTkACdfbMZELwE6Zh9m9KscutE38eqzPgu6oHllPXU4Q/GI5Ev0Lw8tu
5s0bEHtdLAMMRo3hdPtv73kAD8NAEHdAZYLGm6JQmiVXzsxluzI2IhkKqfRp3Z9j
8OBBlJ1A6XAI6KRqT1LvzvSdg/cmXcAUStpoPB65kizwwibLr2dxvdugyA6OkzZN
yBGZ0/i3cyqRRdUJpUT1Wc/cYor1J5l/UWv6/yrPfpVzEaK+YbxOj+JxXz87KhxU
z6Hx3WeDj7Vqku1Gfvbqvdz1nRDe7iYud7WdjGxY6DMKO7+Kf98=
=gX/d
-----END PGP SIGNATURE-----

--------------0I9vwDPw0jL26fHBaNe0sM2c--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 03:47:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 03:47:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111192.1459998 (Exim 4.92)
	(envelope-from )
	id 1uuNQ2-0002oY-6M; Fri, 05 Sep 2025 03:47:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111192.1459998; Fri, 05 Sep 2025 03:47:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuNQ2-0002oR-3m; Fri, 05 Sep 2025 03:47:22 +0000
Received: by outflank-mailman (input) for mailman id 1111192;
 Fri, 05 Sep 2025 03:47: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 1uuNQ1-0002oL-D3
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 03:47:21 +0000
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [2607:f8b0:4864:20::b2c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 05365e4e-8a0b-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 05:47:19 +0200 (CEST)
Received: by mail-yb1-xb2c.google.com with SMTP id
 3f1490d57ef6-e98b7071cc9so1738693276.3
 for ; Thu, 04 Sep 2025 20:47:19 -0700 (PDT)
Received: from [10.138.34.110]
 (h96-60-249-169.cncrtn.broadband.dynamic.tds.net. [96.60.249.169])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e9bbdf22ff7sm2828105276.5.2025.09.04.20.47.17
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 20:47: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: 05365e4e-8a0b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757044038; x=1757648838; darn=lists.xenproject.org;
        h=autocrypt:subject:from:to:content-language:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mS96W1ucccxZFOwlQruoJzC6cMM2RSuJ0wxmye6Uyls=;
        b=j4whAQUmrG2rKhzo6/N7ZYaUS28x9CKcF0SQBgU4YU3hkj6jY1TTOnl/GdkrwBA+Pj
         M9cmzgYprhVSQ0wsT38fk4PsfT82O8aCmOIe0GZua98NtlLURQqp+yeSJoYRqO8jbGrf
         cEkEa98iizh8zV/DAMiQDNR6c+LT0OLSQrs0cYxCP+TqKLpUHhF60Nfiy8SYZPX/nZGI
         fqHkHbW2HJJmIo/ZYd+SLF23nTirUJDqXmvPxDDhXuHjcw/gijrL8b7Ct8UkcZR2iJy7
         jZEsuXMwpWJSShKD18SW/lQ+gfNOb/qiDshavx9+77jDfBQQVq30KhNEiNW8oGN2XlK+
         7B8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757044038; x=1757648838;
        h=autocrypt: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=mS96W1ucccxZFOwlQruoJzC6cMM2RSuJ0wxmye6Uyls=;
        b=vUqeOwZff0+ic8O51TRndijTrXfoKMzMf9YYE36OUk4X3hbipKcjFnHCKd7PcmUSnj
         u/6PSHnGUVjJ5I+cC4Xjzms3JzYxVncH9Kxji2HDuA4JfR1UNRgkuM48YU8OcVjWGEyT
         rTvOY+M+jKrnl9p/S47TJMGgFzVQXO8fui5818BbNXTZeWLpH+x4/8bhVIffBFPDJq0H
         o9uKhhN59k7MHAnZe5wp3BhALUBhUB7CAIH4VaTuHtbFpI+hSLvvVmYqV8hh/b4L/5D1
         vBAtipthEmpGOb/hhARsOFemqy2ShrVcfLtvQ9zPXsAFc7Pb6Rn4pBjEmvUIZcNyoBZK
         dHFA==
X-Gm-Message-State: AOJu0YwxXQSGgdJQQkX4b1nkNrP3zIiO/O066TBYbimVVVD6aiNbl6mW
	8xe3anLUERljgrsoiZvHKIPXrbPQGckA246/WEeTclV9KLuYBvcTtbujFAcxkXhW
X-Gm-Gg: ASbGncus14JuIRjvAqNKcy4sG/7ge08g7FKOPIZgeDrLY+jfBTF+o1AEwBUEhdPYbkn
	5p2cv9t0/tG0KYAVcrLATnx+v7xHdWl8cz/e9p2/wYEwccuHmstxOLqw4Ri7kADyy4i71//8fWE
	evyxpy9aDNv2KPL/mGPOft/Zyf5YYni+Dg+j6ASOO8d7i00FoIZNi2vrfpSKjX41IrdA4LyDX9P
	Vccpk08blkIrLtotfTvuq2BFJvoaZ7cYkNqNOm2ib46+lxQLl7cAGjM4ZhOxi2+NOi2m0ECsXwh
	L0x+UVpoqhrg7SPBqCWDiCrm0p5CC87H2y+vizqxupLvYmqBgcS9iXYH8N2pm4EE91qtkZoNdnN
	nK97d6w+crRvgQVZrPzkJUPVbrtXL6NTZjS/GXLk+5V+EwzDduVXXVDxBR6z9Vr9ac/JGAmozZs
	ClaUqotU9nT23h1QB9JL9gpBK/+7jn5goAesY=
X-Google-Smtp-Source: AGHT+IEa1EYM13YEuhnYKcKYljUv5PgUN2yu4/o9aROoMbsKZ1ZPHSQtgNsPiRSMR6HvyTspfDsO7Q==
X-Received: by 2002:a05:6902:cc7:b0:e97:9be:73be with SMTP id 3f1490d57ef6-e98a575e3e4mr22958398276.3.1757044037918;
        Thu, 04 Sep 2025 20:47:17 -0700 (PDT)
Message-ID: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
Date: Thu, 4 Sep 2025 23:47:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen developer discussion 
From: Demi Marie Obenour 
Subject: Differentiating "For experts only" and "Not security supported" in
 Kconfig
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
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------1o0Wfu10x02TqmkeJ17VjS3Y"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------1o0Wfu10x02TqmkeJ17VjS3Y
Content-Type: multipart/mixed; boundary="------------N6cJIZGTd8tpaPzmS9v4NSPu";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Xen developer discussion 
Message-ID: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
Subject: Differentiating "For experts only" and "Not security supported" in
 Kconfig

--------------N6cJIZGTd8tpaPzmS9v4NSPu
Content-Type: multipart/mixed; boundary="------------OPogiCWfzJbN0nwobuzsoTg9"

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

Right now, both EXPERT and UNSUPPORTED options are
not security supported.  However, this seems to be
causing problems for safety-certified use-cases.

Specifically, disabling AMD or Intel support is certainly
something that should fall under EXPERT IMO, as it is a
great way to produce a Xen binary that will not boot on
a large fraction of hardware.  However, I see no fundamental
reason it should not be security supported.  Not security
supporting it means that those producing safety-certified
builds of Xen (which, presumably, are some of the most
security-critical there are!) are having to use
security-unsupported configurations.

This definitely does not seem right to me.  Safety
certification and security support should go hand in hand,
not conflict with each other!  Is there a plan to address this?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)

--------------OPogiCWfzJbN0nwobuzsoTg9
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-----

--------------OPogiCWfzJbN0nwobuzsoTg9--

--------------N6cJIZGTd8tpaPzmS9v4NSPu--

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

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

iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmi6XUIACgkQszaHOrMp
8lOKww//RQJKEjNfMphB0GpYr2s523uqvvcQYcZ9dPLXL/fL71LToIwp2mFS7Egm
pUMtgZc9bmD+EyvT910YcN4Lp6aDDB2oXfyyEGv53z6kA+IH4k+DOJ82MDmg972h
fLFsyh3NKblfr3s9d8ap6jqXefVXuH2k8Da1RtY6ryFW8A4LyFssV6oqdcwbVZjI
q603LHxpKuOxlBdbYDToQMXzCzaT+N7rrvRak0VXS8mQZSjky+ezXVmpvGlDEvsv
R3zcB80S+8ZxRAGHMWHNmBom1Rj9mjWJWDGB085fe0F4yYF5In8qY6Pb3j5v9pB/
FwKnLd+AfjTn70Z1672a8X4e+8rNh75bHsPc+3MSEf2lD0zlADYTRpdM3FgQ1GhF
bHLq79bayvRjDH4TvlN8ECCwTJCRgz9NCKj3osP5Hu7QRA2/5vfKVHcSi8kEU16R
AjCJA0ixQbb1HiMb0SmFNmj3qSlrMDcXSmRmiGMDB98Tjenw71GFtRD0dRofDN3P
KZj/96+py+K/kzljnummUBLbUqAXgfi+Cf+4S8/2vyXRXQLZdjXTgj546IKAtoMo
4um0EQ2rAOv5Fv+rVUohnNZPfn0iao0fw2ywItL/anEI13b85/6sDVMUFIOiobMJ
B7J3ilPZQP+ISW8/iy3jyyO/lsfa6P5/sNhjui207fuZzzdrnMM=
=/NgF
-----END PGP SIGNATURE-----

--------------1o0Wfu10x02TqmkeJ17VjS3Y--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 05:16:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 05:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111245.1460009 (Exim 4.92)
	(envelope-from )
	id 1uuOno-0005BW-Bo; Fri, 05 Sep 2025 05:16:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111245.1460009; Fri, 05 Sep 2025 05:16: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 1uuOno-0005BP-8h; Fri, 05 Sep 2025 05:16:00 +0000
Received: by outflank-mailman (input) for mailman id 1111245;
 Fri, 05 Sep 2025 05:15: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 1uuOnm-0005BI-Ts
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 05:15:59 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20615.outbound.protection.outlook.com
 [2a01:111:f403:2414::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 664a9e84-8a17-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 07:15:56 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SJ2PR12MB7797.namprd12.prod.outlook.com (2603:10b6:a03:4c5::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Fri, 5 Sep
 2025 05:15:52 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%7]) with mapi id 15.20.9052.019; Fri, 5 Sep 2025
 05:15: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: 664a9e84-8a17-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fAR0GRmpsEAeDgOWcarU+ySLJklYMnKhFntJrx92dM8PHot/Lr8X6UmLXIDGRcSnapEB5ranQIfZL44zrvkUZJf0ebwuJRpUChbHgcyGumXqmzBH8kVzmfppJfp8kwUgNXJniejyWfZGSckFuCUKi1+6SalNSRonqAREsw2JtDMZxYzs47aTosmJliXzLRdqU9En/8/AGWnA1la/DS4TDXYxFoxQRMzROeEgiyy2xB3AEuKqvcWcy/IQZN9B8jGZNCskmlVCYKUt1Jujq0H4Zo/xB4jlgDD3APVJtc9csvVD12kQaxuztHxlS8KFw/V4dPH+QQS6XecHNwdhf/gIFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=25TSxxpc/yKR0BI3bLf7jxtJlYkUUgZSQqBrYBmClow=;
 b=r9HjQr6j2i46g1fh2Djd6Eg5joXQEpcPtGPTRDJFnwfrMJsCWuNgVMSIDi29DhAxWKJMH/tiyjR7z4yLkL2Ck5aBl5tWznz6cbbnESYif2lZgkUpt7ovzlu5rQanJ/Ob/CSLqr3uksNPj3XPW2TSwjm/iOONXdXzLaqEOSBnDTTnLFwozGjTDzfOtl8LOCHs+w8y5bjMdsRm3tNtTMazPizOzIDVw8+iMLu+pEcFo8FadxhpP3MsrU+MggS18zR7Oz8ZsTG1dW14Fnwb9nrlQ/VN+QLIboQIGf41zNUgziH0/UPdxtthYubmCxFfsX856msF9o8Rxy8tIfcHPHyorA==
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=25TSxxpc/yKR0BI3bLf7jxtJlYkUUgZSQqBrYBmClow=;
 b=Jh4qUTjhmmrJgxBwDDY4Sgr/G7JUXBnX9svJib2rEzCuidVtUv1p/qfGKsIQdWEo0IQi4f26ybOq/7n5pKWdCYsFFmzBI9lTZOuE00wJTsCB4pDxYgk+w+4hcDi/FA4VfLUcmdaQTr4Q4+KcaNm0vAt2nupDrD6fCjr50z9/cFQ=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: Andrew Cooper ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Anthony PERARD
	, "Orzel, Michal" , Julien
 Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in
 passive mode
Thread-Topic: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC
 in passive mode
Thread-Index: AQHcHWYoaQVmnKMmQ0CpiPNNytQ3NLSC7UgAgAEbxuA=
Date: Fri, 5 Sep 2025 05:15:51 +0000
Message-ID:
 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-3-Penny.Zheng@amd.com>
 <7e769952-a906-4a3e-af27-26faa76f6dd4@suse.com>
In-Reply-To: <7e769952-a906-4a3e-af27-26faa76f6dd4@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-09-05T05:00:05.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_|SJ2PR12MB7797:EE_
x-ms-office365-filtering-correlation-id: 5c9bbe19-f284-48b4-5e22-08ddec3b487b
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?YitpTDlURStZMFhjWWRZYXNkN2FJcThqeHNWTThhUjBtMTNCQXFpQkFzR3Fa?=
 =?utf-8?B?SDJjbG9XU2tpT0RFQzdRWDVhYytDWlhDRjVjK2ZnVll4M2RVOU4zamR4L1Yy?=
 =?utf-8?B?dUhuTmd5TmUzSVh5UmVkZHBKZ2RxZDJud0FzUVNOb3F0enp6SmpGTzVFY2Nj?=
 =?utf-8?B?ZUlmNy8wOVlJVS8wRncvVlY0L0doVEhBRVhVaDIwTUVZcTc1dUFTajJwYkVL?=
 =?utf-8?B?a24ya3Q5VEsydjlVRVhnRkhLZUpxRVhZY0NhdzkxK1BCOXorNG00OTRZSXBm?=
 =?utf-8?B?OXdCRThlRFZTN0RrTFlCUXFRWmdIYXk4NUtZbE5lbU16d2pXMWtUay9pU05H?=
 =?utf-8?B?VW5jR1ZodUJnK2RJVGQrZXZJY2c2N3U4ay9iMnNVYmVDUVRNTnU2a2dHQjh3?=
 =?utf-8?B?RjE3Z0U0OUJyeE1ldGhKcjZHQjlmWG5Ja1ZLeWNJd3ZyZG51Mjg3NnZ1Yi96?=
 =?utf-8?B?a2xFQ0VIS2crU2hlRlE3S2E4N3VDRC9YYjV6YlVOODJWTnFpV3gzWDJub24v?=
 =?utf-8?B?c0hOd0RFSkxFNVlsTTFJTyt5MDZOTzNzaG1Ta1g5cWtkc3IzVDl6ZVpEbUZo?=
 =?utf-8?B?SG81VDAycUMyRGw2d3lRalFaT1p1aXRsa1YraEtJZ05KUmFOM3NMSGRzQld1?=
 =?utf-8?B?ZHd0S0dNaFMrajFWUnhvV1lETjNRVjZzMjNpRXRBTUVib0V2aHFwcW9sQUlw?=
 =?utf-8?B?M2xkNklkWXk4WXdsSE9MaFNkRk9GSzY2Y1JNNFdlckxkVFhLSEthaUk2TTZl?=
 =?utf-8?B?aUtwZUNUOGQ1NndZeWdINjRlNk5Rd0hWcy9ubUlONTNaRmQyN1prSVpCbE01?=
 =?utf-8?B?NkZrTTFxa0Z1ZzdDTjgxODVoUlFONzkweWJJS0tpTVZrRU4rNG9pRWEwVFZk?=
 =?utf-8?B?WXd1WHdmY2E3dFRtOHlhOVRnZWtwbUJLem1UK0hVVzIzZ2hhVmFWMExBSVRp?=
 =?utf-8?B?WXl4NWpLN1lsUVRudE9Ocy9NVHVaQ0RPOXk2N29FOWdXbnl4RHp6TlZ2WWs3?=
 =?utf-8?B?ckRpV2dsQlNMNGZtRVBER0VORWxtQUgzVDFaeUV3dFJRdTllcFdWYXNVS2NS?=
 =?utf-8?B?MVV3NXN6UnBLdHFQWEFxTGVacnlxS24yWE9zT3RyRERmN2ttTDlGVGpGN3ln?=
 =?utf-8?B?VGZydmlIUWdEVTNtaGtZWU1RQ3ZuRldxbGhXamp0eERBL0d1a29mL0FLTUZK?=
 =?utf-8?B?NURRRnBtN1VMY3lmT0lDRVA4aUtWckp1L0JOdkh0MnZPWUdFd3AvcXhjS3BF?=
 =?utf-8?B?RzJLbHIzM0dNRU5NNnFZaXRXLzRaSnV4a25KYzllZFRtNkd4RXIzTjZFSlFX?=
 =?utf-8?B?SlZHL0d3M09xV0FEQThLaEJ4TGFtRmJINFRHSVNRdFdWZG9hblM2L3BubEtK?=
 =?utf-8?B?dnM5NmxRV1RDRHFSZ1c2MlBZYnRZTm5tQzZnRlNwbVI5VTVYQ2Y3V3dybWpx?=
 =?utf-8?B?MEN2OW9WZDBmc3UvM29QZjlROHRPajNtVjdLaWdjb3RuTHlHdXFGVGZWMlpo?=
 =?utf-8?B?WTdUN1NjbjlhMjdRVjFGWWN0V2JLRUNKNUFIcHhiV3daV1B0aTMxM2pMV2RR?=
 =?utf-8?B?TnBpVmplYzBVMnlKbTNuNWVUTzFBTUsyR1l5VnF2OGpDSDVGWWZGZnRPSk1u?=
 =?utf-8?B?cnJTSS8vR3hCZ21IdUZBbTJFYmFwMVB4d0xmOXhBdmRENkhtMzB3WTR3RFpi?=
 =?utf-8?B?Z1ZEZlNSeWQ0em94dU81Tm1CNXFCOGR5TDg3SjJ6NVRVOGhZVks5bVdXYzBX?=
 =?utf-8?B?YXZ2M29wNFpGMHdMNVg2TFQ3VWhpM2Q0OFl2dU1BNHBpYjUzdC84blNlZ2l5?=
 =?utf-8?B?VDNsMU1tM0F6MnZYRnJhN1orWlFvaXVTSHVxQURnOUo1RVFGcm5xRGZlQTN0?=
 =?utf-8?B?SVdUSkdKa0sxdDdvRVhaTjN1N2RYZlRGRVNTTGY1eGNMc0FpWjdpT1B6ME52?=
 =?utf-8?B?M1JURmd5MjVlQTVBM2pER0V4ZEhtamRMNzh5S0NVUFZKS0xkZHVyb09NWEhU?=
 =?utf-8?B?cEh2bTY1bE93PT0=?=
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?ZnM4eE02UEFUMFpZTnFlUVoxalJ1VEtrY2RjYnRYM0QreGx1THpSaGpoT1ZT?=
 =?utf-8?B?czAwWWtncGhGQWZtQ3M3ZkkrbXZkd09QYTg1bVg0TFdEWFR2UjVRdUJtTENr?=
 =?utf-8?B?Yy82YmlwRWd1YTNQNTJNN1BzcmxHU3NVN0FMK1Y1ZFE0YUVuU290TEZHd2RO?=
 =?utf-8?B?UHBhMkdNQUdIZEtnZ3JudW9CL2ZXdGdraVlkN2YrbWdLVUxNZ0tmb2FreWhZ?=
 =?utf-8?B?bUVJbjEzZzhqaW1jMWxpbjhnK3FMZy9rZHFFSGQ4YUo0K1ZjV0RtRXgrTXhT?=
 =?utf-8?B?R1FKZFAxMm5FdnpaU3RPL3JHZU1HWW5hYW5JRUZxd2JtN2xxelUzbm9CajJv?=
 =?utf-8?B?cXRSQVp5Yzg1K0xYR2JLTW9janpwNTh5RFdLeGdod0RpVVdubWJXeC8zenpw?=
 =?utf-8?B?K2NRdEdhcEdKS0NqS2I0aVJ5MDRycVZIY2hwUnJpTHczK3pZajBMTWZjQXpG?=
 =?utf-8?B?TkNYWmhDS0VGbnNrRnNOMmtwMk44TXh5Um4rWGY4REtaNmlnbGo4eG4yUC95?=
 =?utf-8?B?YTUzRFlNZ3lZOHNsQ3ROZVhMOU1GS1UrNlNDZldFK2NRak1PdFhOdW9USnd5?=
 =?utf-8?B?NXJBUWJJTUFTaXlWTnJBak8yOXdNUWp2OW5sVndSdFpTOEVnMkZWUGRnOE85?=
 =?utf-8?B?eUMwNVErZ0h4V1JxQXF4L3BPMGpmTTZOcWsxU2M2TGo2RHdpYlQvL0hnQkdF?=
 =?utf-8?B?QUNwVTNKSnIrUXdvbDd1dkFnell2TXRPWkVDUjg2a3NXUlRJUlczblZqRWpl?=
 =?utf-8?B?TUVNdldoTmFFS3dCdU9pa3lCVk4zWWozUGJDems5YlJWcEZRTUZsb2NzOEs2?=
 =?utf-8?B?UXdkZnJ2NlhOaVFTMGM4d08xazl0eGpmNmF2VVg4WkdCd1U4a1M2ZUx0Qzdj?=
 =?utf-8?B?dlE4UTlaZUtFQ21tY0FNTElaWDVibzlvNVhrYmxDSktGMWRGeHRhZ1Jta2hV?=
 =?utf-8?B?QmNKNEJaSnBMeXBPWVoyL0lGNzYxM3FYaG5YMVA0Y2l1dnp2bXMwTHVud2M1?=
 =?utf-8?B?ZjR1amdFK0g4N3Nyb2lQSWIzUXlkb2Q1UVMvOGxRaG9DSUlVSzNTVUQ1Rnc5?=
 =?utf-8?B?bSthMkhlbEpLREtDZ3lKdzRSM3BYS0Qrc0g5OXBqNUpoek9pQ3RUcEhVYy94?=
 =?utf-8?B?Zng1ZnFocHRpQS9SVlRhdnJDZUZPQjAreGNZR3pqSi9BSUhhZE16VWdyL2lv?=
 =?utf-8?B?c2Q1TFZ6TlR6bHFYU0h6VlpPY3E0b3BjMUQwb3RHMWkxN3RqV0huaktZSmdU?=
 =?utf-8?B?dWI5K21zRlJKRWxhYW9XK1M4QmRQWEtCTEdlZEZzQVhtVmZsalFnK3hBQlpx?=
 =?utf-8?B?TTRqS2I0THdTUnBEU3BhVTNQSGRkdnhUUk1IejkyMDF4ZTNKdkNLc3lxNWda?=
 =?utf-8?B?eUFDZW9sclRXOS9Sai85S0pEcnhqMjhCTDZjS0ducjF1UGtPQVNud29Hc0JF?=
 =?utf-8?B?SlZQWEhrOWE1M0NVSHpEbnNVU1pWNy9Wb1hJVGVWSEJON3RMNGc1dnVlK1l1?=
 =?utf-8?B?Q2lCK0NvVlV6SzV1b05xNWtjTXFONzNuV0tRdHJDUmgwdm5KMnV3MVZCclI3?=
 =?utf-8?B?YjNqQ0RoOElxQ29ZY1hVODNLWlNEVHVxVFpJTUxsVUFUYjFjNWpOQkg5bDNL?=
 =?utf-8?B?VFo0UmdRY3BpTnNENDlYV1VMTW5JeU9PdmU3R0ROR2UvKzI3a010VDR4bE9I?=
 =?utf-8?B?M1BiNHFSMHRWVHkzRUU1SFJES1N2RU5RYTQwUk45dCtwdTRPSlNiYlZ0T05I?=
 =?utf-8?B?aW5TazhkRmh4b0h5T0FVS2tadGpvZzdJM0x2S0hVNkljMXhSeTV4YTVMN0Qw?=
 =?utf-8?B?Q0ZQRE02MVpmQ1RBQlltN0ZubkpIY1BYS1Fua0dXczdhQnpSTWVrYmZabHRw?=
 =?utf-8?B?bnk2clFqQm9IMjhUTzV5ZEV1ZzFLMit6bUE3aUI5ajJUODQ2clVZdUlmUFlO?=
 =?utf-8?B?dmcrcHJQNjJCc1NzMkdhbUhyTzBFN09UczFtQ1laMkU0eHdBOGlWMlNsVWVT?=
 =?utf-8?B?a1BobVJnMGhiZ0ZkN2ttS2Y1U1VJYzZiMWZHd2w0OHd2cGdqS244Rk13YjBx?=
 =?utf-8?B?SVFOSm5EYlF2VFk3QlpVZXpmcWZrNU9wd1c2dVgrZDVBL2VlTXVrMFRNb3Ar?=
 =?utf-8?Q?+u2w=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: 5c9bbe19-f284-48b4-5e22-08ddec3b487b
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 05:15:51.9358
 (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: PhM3rWGGjT+lLO5NDUrEI/5JDqxJG7C5iiiImn/S4LHuP+rhFJJE3vHwX1gMHaPjVo2wKAl4ArA+J3d/0NwVgA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7797

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgNCwg
MjAyNSA4OjA0IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+
IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1
IE1vbm7DqQ0KPiA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9u
eS5wZXJhcmRAdmF0ZXMudGVjaD47IE9yemVsLA0KPiBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQu
Y29tPjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFN0ZWZhbm8NCj4gU3RhYmVsbGlu
aSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9y
Zw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY5IDIvOF0geGVuL2NwdWZyZXE6IGltcGxlbWVudCBh
bWQtY3BwYyBkcml2ZXIgZm9yIENQUEMgaW4NCj4gcGFzc2l2ZSBtb2RlDQo+DQo+IE9uIDA0LjA5
LjIwMjUgMDg6MzUsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+IGFtZC1jcHBjIGlzIHRoZSBBTUQg
Q1BVIHBlcmZvcm1hbmNlIHNjYWxpbmcgZHJpdmVyIHRoYXQgaW50cm9kdWNlcyBhDQo+ID4gbmV3
IENQVSBmcmVxdWVuY3kgY29udHJvbCBtZWNoYW5pc20uIFRoZSBuZXcgbWVjaGFuaXNtIGlzIGJh
c2VkIG9uDQo+ID4gQ29sbGFib3JhdGl2ZSBQcm9jZXNzb3IgUGVyZm9ybWFuY2UgQ29udHJvbCAo
Q1BQQykgd2hpY2ggaXMgYSBmaW5lcg0KPiA+IGdyYWluIGZyZXF1ZW5jeSBtYW5hZ2VtZW50IHRo
YW4gbGVnYWN5IEFDUEkgaGFyZHdhcmUgUC1TdGF0ZXMuDQo+ID4gQ3VycmVudCBBTUQgQ1BVIHBs
YXRmb3JtcyBhcmUgdXNpbmcgdGhlIEFDUEkgUC1zdGF0ZXMgZHJpdmVyIHRvIG1hbmFnZQ0KPiA+
IENQVSBmcmVxdWVuY3kgYW5kIGNsb2NrcyB3aXRoIHN3aXRjaGluZyBvbmx5IGluIDMgUC1zdGF0
ZXMsIHdoaWxlIHRoZQ0KPiA+IG5ldyBhbWQtY3BwYyBhbGxvd3MgYSBtb3JlIGZsZXhpYmxlLCBs
b3ctbGF0ZW5jeSBpbnRlcmZhY2UgZm9yIFhlbiB0bw0KPiA+IGRpcmVjdGx5IGNvbW11bmljYXRl
IHRoZSBwZXJmb3JtYW5jZSBoaW50cyB0byBoYXJkd2FyZS4NCj4gPg0KPiA+ICJhbWQtY3BwYyIg
ZHJpdmVyIGlzIHJlc3BvbnNpYmxlIGZvciBpbXBsZW1lbnRpbmcgQ1BQQyBpbiBwYXNzaXZlDQo+
ID4gbW9kZSwgd2hpY2ggc3RpbGwgbGV2ZXJhZ2VzIFhlbiBnb3Zlcm5vcnMgc3VjaCBhcyAqb25k
ZW1hbmQqLA0KPiA+ICpwZXJmb3JtYW5jZSosIGV0YywgdG8gY2FsY3VsYXRlIHRoZSBwZXJmb3Jt
YW5jZSBoaW50cy4gSW4gdGhlIGZ1dHVyZSwNCj4gPiB3ZSB3aWxsIGludHJvZHVjZSBhbiBhZHZh
bmNlZCBhY3RpdmUgbW9kZSB0byBlbmFibGUgYXV0b25vbW91cyBwZXJmb3JtZW5jZQ0KPiBsZXZl
bCBzZWxlY3Rpb24uDQo+ID4NCj4gPiBGaWVsZCBlcHAsIGVuZXJneSBwZXJmb3JtYW5jZSBwcmVm
ZXJlbmNlLCB3aGljaCBvbmx5IGhhcyBtZWFuaW5nIHdoZW4NCj4gPiBhY3RpdmUgbW9kZSBpcyBl
bmFibGVkIGFuZCB3aWxsIGJlIGludHJvZHVjZWQgbGF0ZXIgaW4gZGV0YWlscywgc28gd2UNCj4g
PiByZWFkIHByZS1kZWZpbmVkIEJJT1MgdmFsdWUgZm9yIGl0IGluIHBhc3NpdmUgbW9kZS4NCj4g
Pg0KPiA+IFNpZ25lZC1vZmYtYnk6IFBlbm55IFpoZW5nIDxQZW5ueS5aaGVuZ0BhbWQuY29tPg0K
PiA+IEFja2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+DQo+IFdpdGgg
dGhlIGlzc3VlIEkgaGFkIHBvaW50ZWQgb3V0LCBsZWFkaW5nIHRvIC4uLg0KPg0KPiA+IC0tLQ0K
PiA+IHY4IC0+IHY5DQo+ID4gLSBlbWJlZCBzdHJ1Y3QgYW1kX2NwcGNfZHJ2X2RhdGF7fSBpbnRv
IHN0cnVjdCBjcHVmcmVxX3BvbGljeXt9DQo+DQo+IC4uLiB0aGlzIGNoYW5nZSwgSSB0aGluayB0
aGUgdGFnIHdvdWxkIGhhdmUgbmVlZGVkIHRvIGJlIGRyb3BwZWQuDQo+DQoNClVuZGVyc3Rvb2Qs
IHdpbGwgcmVtb3ZlDQoNCj4gPiArc3RhdGljIHZvaWQgY2ZfY2hlY2sgYW1kX2NwcGNfd3JpdGVf
cmVxdWVzdF9tc3JzKHZvaWQgKmluZm8pIHsNCj4gPiArICAgIGNvbnN0IHN0cnVjdCBhbWRfY3Bw
Y19kcnZfZGF0YSAqZGF0YSA9IGluZm87DQo+ID4gKw0KPiA+ICsgICAgd3Jtc3JsKE1TUl9BTURf
Q1BQQ19SRVEsIGRhdGEtPnJlcS5yYXcpOyB9DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBhbWRf
Y3BwY193cml0ZV9yZXF1ZXN0KHVuc2lnbmVkIGludCBjcHUsDQo+ID4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhLA0KPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgbWluX3BlcmYsIHVp
bnQ4X3QgZGVzX3BlcmYsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dWludDhfdCBtYXhfcGVyZiwgdWludDhfdCBlcHApIHsNCj4gPiArICAgIHVpbnQ2NF90IHByZXYg
PSBkYXRhLT5yZXEucmF3Ow0KPiA+ICsNCj4gPiArICAgIGRhdGEtPnJlcS5taW5fcGVyZiA9IG1p
bl9wZXJmOw0KPiA+ICsgICAgZGF0YS0+cmVxLm1heF9wZXJmID0gbWF4X3BlcmY7DQo+ID4gKyAg
ICBkYXRhLT5yZXEuZGVzX3BlcmYgPSBkZXNfcGVyZjsNCj4gPiArICAgIGRhdGEtPnJlcS5lcHAg
PSBlcHA7DQo+ID4gKw0KPiA+ICsgICAgaWYgKCBwcmV2ID09IGRhdGEtPnJlcS5yYXcgKQ0KPiA+
ICsgICAgICAgIHJldHVybjsNCj4gPiArDQo+ID4gKyAgICBvbl9zZWxlY3RlZF9jcHVzKGNwdW1h
c2tfb2YoY3B1KSwgYW1kX2NwcGNfd3JpdGVfcmVxdWVzdF9tc3JzLA0KPiA+ICsgZGF0YSwgMSk7
DQo+DQo+IFdpdGggImNwdSIgY29taW5nIGZyb20gLi4uDQo+DQo+ID4gK30NCj4gPiArDQo+ID4g
K3N0YXRpYyBpbnQgY2ZfY2hlY2sgYW1kX2NwcGNfY3B1ZnJlcV90YXJnZXQoc3RydWN0IGNwdWZy
ZXFfcG9saWN5ICpwb2xpY3ksDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdW5zaWduZWQgaW50IHRhcmdldF9mcmVxLA0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByZWxhdGlvbikgew0K
PiA+ICsgICAgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhID0gcG9saWN5LT51LmFtZF9j
cHBjOw0KPiA+ICsgICAgdWludDhfdCBkZXNfcGVyZjsNCj4gPiArICAgIGludCByZXM7DQo+ID4g
Kw0KPiA+ICsgICAgaWYgKCB1bmxpa2VseSghdGFyZ2V0X2ZyZXEpICkNCj4gPiArICAgICAgICBy
ZXR1cm4gMDsNCj4gPiArDQo+ID4gKyAgICByZXMgPSBhbWRfY3BwY19raHpfdG9fcGVyZihkYXRh
LCB0YXJnZXRfZnJlcSwgJmRlc19wZXJmKTsNCj4gPiArICAgIGlmICggcmVzICkNCj4gPiArICAg
ICAgICByZXR1cm4gcmVzOw0KPiA+ICsNCj4gPiArICAgIC8qDQo+ID4gKyAgICAgKiBIYXZpbmcg
YSBwZXJmb3JtYW5jZSBsZXZlbCBsb3dlciB0aGFuIHRoZSBsb3dlc3Qgbm9ubGluZWFyDQo+ID4g
KyAgICAgKiBwZXJmb3JtYW5jZSBsZXZlbCwgc3VjaCBhcywgbG93ZXN0X3BlcmYgPD0gcGVyZiA8
PSBsb3dlc3Rfbm9ubGluZXJfcGVyZiwNCj4gPiArICAgICAqIG1heSBhY3R1YWxseSBjYXVzZSBh
biBlZmZpY2llbmN5IHBlbmFsdHksIFNvIHdoZW4gZGVjaWRpbmcgdGhlIG1pbl9wZXJmDQo+ID4g
KyAgICAgKiB2YWx1ZSwgd2UgcHJlZmVyIGxvd2VzdCBub25saW5lYXIgcGVyZm9ybWFuY2Ugb3Zl
ciBsb3dlc3QgcGVyZm9ybWFuY2UuDQo+ID4gKyAgICAgKi8NCj4gPiArICAgIGFtZF9jcHBjX3dy
aXRlX3JlcXVlc3QocG9saWN5LT5jcHUsIGRhdGEsDQo+ID4gKyBkYXRhLT5jYXBzLmxvd2VzdF9u
b25saW5lYXJfcGVyZiwNCj4NCj4gLi4uIGhlcmUsIGhvdyBjYW4gdGhpcyB3b3JrIHdoZW4gdGhp
cyBwYXJ0aWN1bGFyIENQVSBpc24ndCBvbmxpbmUgYW55bW9yZT8NCg0KT25jZSBhbnkgcHJvY2Vz
c29yIGluIHRoZSBkb21haW4gZ2V0cyBvZmZsaW5lLCB0aGUgZ292ZXJub3Igd2lsbCBzdG9wLCB0
aGVuIC50YXJnZXQoKSBjb3VsZCBub3QgYmUgaW52b2tlZCBhbnkgbW9yZToNCmBgYA0KICAgICAg
ICBpZiAoIGh3X2FsbCB8fCBjcHVtYXNrX3dlaWdodChjcHVmcmVxX2RvbS0+bWFwKSA9PSBkb21h
aW5faW5mby0+bnVtX3Byb2Nlc3NvcnMgKQ0KICAgICAgICAgICAgICAgIF9fY3B1ZnJlcV9nb3Zl
cm5vcihwb2xpY3ksIENQVUZSRVFfR09WX1NUT1ApOw0KYGBgDQoNCj4NCj4gPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZGVzX3BlcmYsIGRhdGEtPmNhcHMuaGlnaGVzdF9wZXJmLA0KPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBQcmUtZGVmaW5lZCBCSU9TIHZhbHVlIGZv
ciBwYXNzaXZlIG1vZGUgKi8NCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVyX2Nw
dShlcHBfaW5pdCwgcG9saWN5LT5jcHUpKTsNCj4gPiArICAgIHJldHVybiAwOw0KPiA+ICt9DQo+
ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBjZl9jaGVjayBhbWRfY3BwY19pbml0X21zcnModm9pZCAq
aW5mbykgew0KPiA+ICsgICAgc3RydWN0IGNwdWZyZXFfcG9saWN5ICpwb2xpY3kgPSBpbmZvOw0K
PiA+ICsgICAgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhID0gcG9saWN5LT51LmFtZF9j
cHBjOw0KPiA+ICsgICAgdWludDY0X3QgdmFsOw0KPiA+ICsgICAgdW5zaWduZWQgaW50IG1pbl9m
cmVxID0gMCwgbm9taW5hbF9mcmVxID0gMCwgbWF4X2ZyZXE7DQo+ID4gKw0KPiA+ICsgICAgLyog
UGFja2FnZSBsZXZlbCBNU1IgKi8NCj4gPiArICAgIHJkbXNybChNU1JfQU1EX0NQUENfRU5BQkxF
LCB2YWwpOw0KPg0KPiBIZXJlIHlvdSBjbGFyaWZ5IHRoZSBzY29wZSwgeWV0IHdoYXQgYWJvdXQg
Li4uDQo+DQo+ID4gKyAgICAvKg0KPiA+ICsgICAgICogT25seSB3aGVuIEVuYWJsZSBiaXQgaXMg
b24sIHRoZSBoYXJkd2FyZSB3aWxsIGNhbGN1bGF0ZSB0aGUgcHJvY2Vzc29y4oCZcw0KPiA+ICsg
ICAgICogcGVyZm9ybWFuY2UgY2FwYWJpbGl0aWVzIGFuZCBpbml0aWFsaXplIHRoZSBwZXJmb3Jt
YW5jZSBsZXZlbCBmaWVsZHMgaW4NCj4gPiArICAgICAqIHRoZSBDUFBDIGNhcGFiaWxpdHkgcmVn
aXN0ZXJzLg0KPiA+ICsgICAgICovDQo+ID4gKyAgICBpZiAoICEodmFsICYgQU1EX0NQUENfRU5B
QkxFKSApDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgdmFsIHw9IEFNRF9DUFBDX0VOQUJMRTsN
Cj4gPiArICAgICAgICB3cm1zcmwoTVNSX0FNRF9DUFBDX0VOQUJMRSwgdmFsKTsNCj4gPiArICAg
IH0NCj4gPiArDQo+ID4gKyAgICByZG1zcmwoTVNSX0FNRF9DUFBDX0NBUDEsIGRhdGEtPmNhcHMu
cmF3KTsNCj4NCj4gLi4uIHRoaXMgYW5kIC4uLg0KPg0KR09WX0dFVEFWRyk7DQo+ID4gKw0KPiA+
ICsgICAgLyogU3RvcmUgcHJlLWRlZmluZWQgQklPUyB2YWx1ZSBmb3IgcGFzc2l2ZSBtb2RlICov
DQo+ID4gKyAgICByZG1zcmwoTVNSX0FNRF9DUFBDX1JFUSwgdmFsKTsNCj4NCj4gLi4uIHRoaXM/
DQo+DQoNClRoZXkgYXJlIGFsbCBQZXItdGhyZWFkIE1TUi4gSSdsbCBhZGQgZGVzY3JpcHRpb25z
Lg0KDQo+ID4gK3N0YXRpYyBpbnQgY2ZfY2hlY2sgYW1kX2NwcGNfY3B1ZnJlcV9jcHVfaW5pdChz
dHJ1Y3QgY3B1ZnJlcV9wb2xpY3kNCj4gPiArKnBvbGljeSkgew0KPiA+ICsgICAgdW5zaWduZWQg
aW50IGNwdSA9IHBvbGljeS0+Y3B1Ow0KPiA+ICsgICAgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRh
ICpkYXRhOw0KPiA+ICsNCj4gPiArICAgIGRhdGEgPSB4dnphbGxvYyhzdHJ1Y3QgYW1kX2NwcGNf
ZHJ2X2RhdGEpOw0KPiA+ICsgICAgaWYgKCAhZGF0YSApDQo+ID4gKyAgICAgICAgcmV0dXJuIC1F
Tk9NRU07DQo+ID4gKyAgICBwb2xpY3ktPnUuYW1kX2NwcGMgPSBkYXRhOw0KPiA+ICsNCj4gPiAr
ICAgIGRhdGEtPmNwcGNfZGF0YSA9ICZwcm9jZXNzb3JfcG1pbmZvW2NwdV0tPmNwcGNfZGF0YTsN
Cj4gPiArDQo+ID4gKyAgICBvbl9zZWxlY3RlZF9jcHVzKGNwdW1hc2tfb2YoY3B1KSwgYW1kX2Nw
cGNfaW5pdF9tc3JzLCBwb2xpY3ksIDEpOw0KPiA+ICsNCj4gPiArICAgIC8qDQo+ID4gKyAgICAg
KiBUaGUgZW5hYmxlIGJpdCBpcyBzdGlja3ksIGFzIHdlIG5lZWQgdG8gZW5hYmxlIGl0IGF0IHRo
ZSB2ZXJ5IGZpcnN0DQo+ID4gKyAgICAgKiBiZWdpbmluZywgYmVmb3JlIENQUEMgY2FwYWJpbGl0
eSB2YWx1ZXMgc2FuaXR5IGNoZWNrLg0KPiA+ICsgICAgICogSWYgZXJyb3IgcGF0aCBpcyB0YWtl
biBlZmZlY3RpdmUsIG5vdCBvbmx5IGFtZC1jcHBjIGNwdWZyZXEgY29yZSBmYWlscw0KPiA+ICsg
ICAgICogdG8gaW5pdGlhbGl6ZSwgYnV0IGFsc28gd2UgY291bGQgbm90IGZhbGwgYmFjayB0byBs
ZWdhY3kgUC1zdGF0ZXMNCj4gPiArICAgICAqIGRyaXZlciwgaXJyZXNwZWN0aXZlIG9mIHRoZSBj
b21tYW5kIGxpbmUgc3BlY2lmeWluZyBhIGZhbGxiYWNrIG9wdGlvbi4NCj4gPiArICAgICAqLw0K
PiA+ICsgICAgaWYgKCBkYXRhLT5lcnIgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGFtZF9j
cHBjX2VycihjcHUsICJDb3VsZCBub3QgaW5pdGlhbGl6ZSBjcHVmcmVxIGNvcmUgaW4gQ1BQQyBt
b2RlXG4iKTsNCj4gPiArICAgICAgICBhbWRfY3BwY19jcHVmcmVxX2NwdV9leGl0KHBvbGljeSk7
DQo+ID4gKyAgICAgICAgcmV0dXJuIGRhdGEtPmVycjsNCj4NCj4gYW1kX2NwcGNfY3B1ZnJlcV9j
cHVfZXhpdCgpIGhhcyBhbHJlYWR5IGZyZWVkIHdoYXQgZGF0YSBwb2ludHMgdG8uDQo+DQoNClRy
dWUsIEknbGwgcmVjb3JkIHRoZSBlcnJvciBpbmZvDQoNCj4gPiAtLS0gYS94ZW4vaW5jbHVkZS9h
Y3BpL2NwdWZyZXEvY3B1ZnJlcS5oDQo+ID4gKysrIGIveGVuL2luY2x1ZGUvYWNwaS9jcHVmcmVx
L2NwdWZyZXEuaA0KPiA+IEBAIC02Myw2ICs2Myw3IEBAIHN0cnVjdCBwZXJmX2xpbWl0cyB7ICB9
Ow0KPiA+DQo+ID4gIHN0cnVjdCBod3BfZHJ2X2RhdGE7DQo+ID4gK3N0cnVjdCBhbWRfY3BwY19k
cnZfZGF0YTsNCj4gPiAgc3RydWN0IGNwdWZyZXFfcG9saWN5IHsNCj4gPiAgICAgIGNwdW1hc2tf
dmFyX3QgICAgICAgY3B1czsgICAgICAgICAgLyogYWZmZWN0ZWQgQ1BVcyAqLw0KPiA+ICAgICAg
dW5zaWduZWQgaW50ICAgICAgICBzaGFyZWRfdHlwZTsgICAvKiBBTlkgb3IgQUxMIGFmZmVjdGVk
IENQVXMNCj4gPiBAQCAtODUsNiArODYsOSBAQCBzdHJ1Y3QgY3B1ZnJlcV9wb2xpY3kgew0KPiA+
ICAgICAgdW5pb24gew0KPiA+ICAjaWZkZWYgQ09ORklHX0lOVEVMDQo+ID4gICAgICAgICAgc3Ry
dWN0IGh3cF9kcnZfZGF0YSAqaHdwOyAvKiBEcml2ZXIgZGF0YSBmb3IgSW50ZWwgSFdQICovDQo+
ID4gKyNlbmRpZg0KPiA+ICsjaWZkZWYgQ09ORklHX0FNRA0KPiA+ICsgICAgICAgIHN0cnVjdCBh
bWRfY3BwY19kcnZfZGF0YSAqYW1kX2NwcGM7IC8qIERyaXZlciBkYXRhIGZvciBBTUQNCj4gPiAr
Q1BQQyAqLw0KPiA+ICAjZW5kaWYNCj4gPiAgICAgIH0gdTsNCj4gPiAgfTsNCj4NCj4gU2FtZSBj
b21tZW50cyBoZXJlIGFzIGZvciB0aGUgSFdQIHBhdGNoLg0KDQpNYXkgSSBhc2sgd2h5IHN0cnVj
dHVyZSBvdmVyIHBvaW50ZXIgaGVyZT8NCg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 06:23:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 06:23:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111288.1460038 (Exim 4.92)
	(envelope-from )
	id 1uuPqz-0005Ic-CH; Fri, 05 Sep 2025 06:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111288.1460038; Fri, 05 Sep 2025 06: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 1uuPqz-0005IV-9W; Fri, 05 Sep 2025 06:23:21 +0000
Received: by outflank-mailman (input) for mailman id 1111288;
 Fri, 05 Sep 2025 06:23:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuPqx-0005IP-OY
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 06:23:19 +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 cdcc5e01-8a20-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 08:23:14 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b00a9989633so326477866b.0
 for ; Thu, 04 Sep 2025 23:23:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62069b79e1asm2360526a12.26.2025.09.04.23.23.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 23:23: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: cdcc5e01-8a20-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757053394; x=1757658194; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0XL1zHInmGojjeRUhBMCy2TvZcZvWB0YbUBSwAeXgzI=;
        b=Zk3x0YKeTLvO9O1CpT0eEZXvu09Rch5+hDPkk2DIoDmVFierFzC3zSiqju2ZOQQH95
         mjsIdrntY7tFYfz9Yu00bMgHRAi/7XWYpqdHPYojKq2VJjAXQmHogyoo8KKqfwQB0ag+
         qXEWvnUlSOJDStpngQPYZRJlQYinICbwwURsHqqpMgOL5Y8FfepTfowgCUjNxCMDSibs
         Tb0atjc2ZFJXXh8c/iHjs/5rRwXWDnssoqqvA8vdDVBVN5E1QLsSmxA0Ch6rAfxxp5y8
         p4V4M+LbgLiS8mqaDlzUoWRWW+O+cq+oW74xpPiZS77+PPE3IsK4lsEN9ne92KhWjvK9
         CtSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757053394; x=1757658194;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0XL1zHInmGojjeRUhBMCy2TvZcZvWB0YbUBSwAeXgzI=;
        b=lgH09YIgiG/ZLVrNssxVJWgK6BEwZUuf/UmU6KyhPTOtdMpuefAmCheliRoN0v8dmj
         bgpZ35FyHuNeox/6OGUVCGA/Jy2OSjL9u7EFQq8YLCmbHlMxBjyFa7oTX8vbBwvpRGE8
         CcIlpHKI0YU6WVGdsHSqcEUX3s5/hOF1ptXcclPPWqgnyFuEid+YXd6kILhNqmRJjoc3
         Z03r3kRrHAzv9u5tXutjcMR18ClOuW2oQlHXzIAJXDVtyB2G+rJbouu4zAgDOc7PtrWa
         9BI4nalj+ySaFKBLQ64PMmqP42Cd5n5jNb5fdYX1gSS86QhWp8O9cwUp3UcftQ3paf85
         iZnQ==
X-Forwarded-Encrypted: i=1; AJvYcCXHcZ7zYWk3IFBwRomGeOU6808bhl+XXQM+mvaBmqMNq8MAQfQ8vr9Q/NkN/CasAHmhtar5qznzaqc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNy4xFYU6E/b64uoy9Oewdbgg/eTmLs2nEzgI2dREQI/1OSiOG
	fejJKtCEdGy7OgB9BmU4i22Yyfi/dm8xPhC46zy/tOvJOwxsXntSU3eeoMjZz77lMw==
X-Gm-Gg: ASbGncvWIwzVB0jCiuyGhOb96Gymx4T1Kd8WLwh+Bw9H4BhyMKgQ3gDr4DQAoxqabWk
	g4SgZ4cCIoRniEy2Tjh0GPiuvZ7CFzgPT6x+VXjlgDsLXV6nA4jo1WsQqctz+eMQcFMeG8EadyQ
	920ZrnsOjoTdWLka6RQrssBNVqw3F9jMagYUzNMZW7bgNJ+jAKH8PYRjMjwysytSU/+mBw1oiTw
	pxDwujJhD+Xx04iFIhy+ip9F20hXC78vbXfSXarVouKFBuWkz+ztoRjEOU23loHbr7iq9men5iD
	uiAQmqtEogu+AuDLDkqs6iWolKty2WpuldAtI6GhYN4D1aI3n0fHPHhpa6I2S3S0cSAyWzmd/Rr
	nVo0S2i0fPYZwyz5m8Jf2THFHX05f9BAh6p9kabAQEfLK9U1ZfaWuns0nP8me31Fc6I/TJGO+7X
	q61b3DKWgJXYqM7w+sqQ==
X-Google-Smtp-Source: AGHT+IHVsKSNhsh56RQRb/AxWk/aKmJ0b5TbP3rgYupuCmH0SR3PGaADG0Fi8roKJnazg/0oOFazXQ==
X-Received: by 2002:a17:907:6ea3:b0:afe:ac57:f0be with SMTP id a640c23a62f3a-b04932a677cmr262986566b.31.1757053394017;
        Thu, 04 Sep 2025 23:23:14 -0700 (PDT)
Message-ID: <4534a58a-b7c9-4571-a459-c3ec3d28ca49@suse.com>
Date: Fri, 5 Sep 2025 08:23:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] symbols: discard stray file symbols
To: Jason Andryuk 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" 
References: <2412a7a0-bdcd-4647-8ea2-8d2a927dcde3@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.09.2025 23:53, Jason Andryuk wrote:
> On 2025-04-16 05:00, Jan Beulich wrote:
>> By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
>> when linking xen.efi. Due to the nature of file symbols in COFF symbol
>> tables (see the code comment) the symbols_offsets[] entries for such
>> symbols would cause assembler warnings regarding value truncation. Of
>> course the resulting entries would also be both meaningless and useless.
>> Add a heuristic to get rid of them, really taking effect only when
>> --all-symbols is specified (otherwise these symbols are discarded
>> anyway).
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> Factor 2 may in principle still be too small: We zap what looks like
>> real file symbols already in read_symbol(), so table_cnt doesn't really
>> reflect the number of symbol table entries encountered. It has proven to
>> work for me in practice though, with still some leeway left.
>>
>> --- a/xen/tools/symbols.c
>> +++ b/xen/tools/symbols.c
>> @@ -213,6 +213,16 @@ static int symbol_valid(struct sym_entry
>>   	if (strstr((char *)s->sym + offset, "_compiled."))
>>   		return 0;
>>   
>> +	/* At least GNU ld 2.25 may emit bogus file symbols referencing a
>> +	 * section name while linking xen.efi. In COFF symbol tables the
>> +	 * "value" of file symbols is a link (symbol table index) to the next
>> +	 * file symbol. Since file (and other) symbols (can) come with one
>> +	 * (or in principle more) auxiliary symbol table entries, the value in
>> +	 * this heuristic is bounded to twice the number of symbols we have
>> +	 * found. See also read_symbol() as to the '?' checked for here. */
>> +	if (s->sym[0] == '?' && s->sym[1] == '.' && s->addr < table_cnt * 2)
>> +		return 0;
>> +
>>   	return 1;
>>   }
> 
> I looked at this.  It'll drop symbols, but I don't know enough to give 
> an R-b.  I can't give an actionable A-b either.   Maybe someone else can 
> chime in.
> 
> Maybe this is just showing my lack of knowledge, but could any symbol 
> starting "?." be considered invalid?  I don't think I've ever seen any 
> like that.

With quotation, almost any symbol name can appear in principle. I wouldn't
want to judge symbol validity by its name. What's more important here,
though, is that sym[0] isn't part of the name; it's the symbol's type as
taken from nm's output. We're therefore heuristically looking at symbols
of unknown type with a dot as the first character (as section names would
conventionally have it).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 06:45:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 06:45:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111310.1460048 (Exim 4.92)
	(envelope-from )
	id 1uuQBi-00083P-TX; Fri, 05 Sep 2025 06:44:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111310.1460048; Fri, 05 Sep 2025 06: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 1uuQBi-00083I-Qx; Fri, 05 Sep 2025 06:44:46 +0000
Received: by outflank-mailman (input) for mailman id 1111310;
 Fri, 05 Sep 2025 06:44:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuQBh-00083C-Iq
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 06:44:45 +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 ce3433e0-8a23-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 08:44:44 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-b047f28a83dso259910166b.2
 for ; Thu, 04 Sep 2025 23: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
 a640c23a62f3a-b0307435422sm1501587866b.78.2025.09.04.23.44.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Sep 2025 23: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: ce3433e0-8a23-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757054683; x=1757659483; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bQ6NgGmyUr4WcOILQVxU1LZax48OJGEDQdBZLekTbPE=;
        b=DFg1Q9i4+jUNuG8RObQQmSBCcyymlhfcz7+nl4PtYiOXU6AiVnQBAo+YJa8/QyMABs
         jYdMt4Ls7/CWtresViuL66v9a9BKaysOtMlTu8RvnRgiiLUViC8F67YGcuF6osYO8r+1
         Ghe8L+F/wqU6t7KJrfgk55TYuW8MeN/AVVc9NVsqxZ5HFSIfiI3I3hwTuxhQVvcBDo4X
         MY7YSk7qqJ9k2GSJrsQgipMQl3JGy/dW0NjpGn1xwZXGblEp1P2XLvvjriD93/BKA1Z3
         O6akn5DIhprYnvaFZp53QJc7f77O53dxBDx9BHFx2pjNXpVR8PYCFJGMAUZFxp7IQZf1
         YwEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757054683; x=1757659483;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bQ6NgGmyUr4WcOILQVxU1LZax48OJGEDQdBZLekTbPE=;
        b=mM4erfzZd0UFMm7plkwXb52eXv+nKNKs8yNbeaCV5lb2Ws9y8n0wvr05GzhjinYYRe
         Tt2+i6EOvJuuUuiGn0S0v/5+Q54Dwg2+GCZEFXbAmXMsyV8pf10UKaBmpN5IaAMVHBeT
         aXQiRpQ0LPX+lfffsHEKRPKrd7ASNS6YU8tUw++L2c3mk9rzxKp7IaxNOn5jsI25NBx2
         y8FonmYVO1We03xfvHEpobLi3Kgq2dJQxSYQ0uEajFIadQzJks4+AXmY26f0xkGG3R7u
         hJa9p+ddicTha94yBYB+91XzNVS3h+3go3c5JGZNN7m7KGiywo2m6gz1UKli02npTDgO
         mmlw==
X-Forwarded-Encrypted: i=1; AJvYcCUHInab91Rdqs1lJb5HKw3WZpTnA6u9xWFhUKuCKntggsr2noxSMfoDuvv3Clu7A+tWfLGUQWeI9cY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEkAKtIJ1WH9gVTWX+Jm10IOsAvDXwxDRGsXde6GCWTZwf6t4j
	pm8A13rMTzSFS9r30UNh/1Td04g8O+nCHA73qDIk1rUjwXB70FuDMFMz/hv08DbqeQ==
X-Gm-Gg: ASbGnctfCi5cxkXvn5rpq8Lc7kp6hcWeObNhGoQilcMaWOKi7gSla6nA7bPc/x/ZgF6
	yypbPw+u3/IqrkplrgjiF5hgNOsaeXjiq4lHUxO0Dzj7wciIRNPuWbLnTpsSEOdbtZtdLnqR7dH
	CRVuAEflSdrtSoAIR2k04dNKCAowgv2xHnsyJOwBJVxmuAY5AJwJpkghUm/ff/I7X7t1vObLSqX
	ua13phMd7yfAvRhAdEdmxNG4eZ36i2wurFeUKYPhfQTQZO3AiB/yEVpULTvcFqoEDFcS5+tU4zn
	9CAn3Z4iSdih0TieWrOma5gZG4TZWizbpE+j0WNZc+IK167EV8CBGVi5xCGULUVwrxr49iS7Wn5
	s/9jFB2WSoxaARBp4hNytntPZIn8yvXKLVVY1m/zAN5eVkCkQN+TkGinzp4Gah3xgEA7ux6ukBn
	Reff78WDs=
X-Google-Smtp-Source: AGHT+IGGz95khelF8gPOlY3aaf55yjJKT/GDxsHX0f1z36rfwxu6Q2P7L/Ge2w3fwErrxseHLNOPNw==
X-Received: by 2002:a17:907:7e8e:b0:b04:3402:393e with SMTP id a640c23a62f3a-b0434023f95mr1619092466b.31.1757054683051;
        Thu, 04 Sep 2025 23:44:43 -0700 (PDT)
Message-ID: <4f2ff564-e64a-4d0e-b123-d85b81f10929@suse.com>
Date: Fri, 5 Sep 2025 08:44:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in
 passive mode
To: "Penny, Zheng" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-3-Penny.Zheng@amd.com>
 <7e769952-a906-4a3e-af27-26faa76f6dd4@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.09.2025 07:15, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, September 4, 2025 8:04 PM
>>
>> On 04.09.2025 08:35, Penny Zheng wrote:
>>> +static void cf_check amd_cppc_write_request_msrs(void *info) {
>>> +    const struct amd_cppc_drv_data *data = info;
>>> +
>>> +    wrmsrl(MSR_AMD_CPPC_REQ, data->req.raw); }
>>> +
>>> +static void amd_cppc_write_request(unsigned int cpu,
>>> +                                   struct amd_cppc_drv_data *data,
>>> +                                   uint8_t min_perf, uint8_t des_perf,
>>> +                                   uint8_t max_perf, uint8_t epp) {
>>> +    uint64_t prev = data->req.raw;
>>> +
>>> +    data->req.min_perf = min_perf;
>>> +    data->req.max_perf = max_perf;
>>> +    data->req.des_perf = des_perf;
>>> +    data->req.epp = epp;
>>> +
>>> +    if ( prev == data->req.raw )
>>> +        return;
>>> +
>>> +    on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs,
>>> + data, 1);
>>
>> With "cpu" coming from ...
>>
>>> +}
>>> +
>>> +static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
>>> +                                            unsigned int target_freq,
>>> +                                            unsigned int relation) {
>>> +    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
>>> +    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;
>>> +
>>> +    /*
>>> +     * Having a performance level lower than the lowest nonlinear
>>> +     * performance level, such as, lowest_perf <= perf <= lowest_nonliner_perf,
>>> +     * may actually cause an efficiency penalty, So when deciding the min_perf
>>> +     * value, we prefer lowest nonlinear performance over lowest performance.
>>> +     */
>>> +    amd_cppc_write_request(policy->cpu, data,
>>> + data->caps.lowest_nonlinear_perf,
>>
>> ... here, how can this work when this particular CPU isn't online anymore?
> 
> Once any processor in the domain gets offline, the governor will stop, then .target() could not be invoked any more:
> ```
>         if ( hw_all || cpumask_weight(cpufreq_dom->map) == domain_info->num_processors )
>                 __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> ```

I can't bring the code in line with what you say.

>>> +                           des_perf, data->caps.highest_perf,
>>> +                           /* Pre-defined BIOS value for passive mode */
>>> +                           per_cpu(epp_init, policy->cpu));
>>> +    return 0;
>>> +}
>>> +
>>> +static void cf_check amd_cppc_init_msrs(void *info) {
>>> +    struct cpufreq_policy *policy = info;
>>> +    struct amd_cppc_drv_data *data = policy->u.amd_cppc;
>>> +    uint64_t val;
>>> +    unsigned int min_freq = 0, nominal_freq = 0, max_freq;
>>> +
>>> +    /* Package level MSR */
>>> +    rdmsrl(MSR_AMD_CPPC_ENABLE, val);
>>
>> Here you clarify the scope, yet what about ...
>>
>>> +    /*
>>> +     * Only when Enable bit is on, the hardware will calculate the processor’s
>>> +     * performance capabilities and initialize the performance level fields in
>>> +     * the CPPC capability registers.
>>> +     */
>>> +    if ( !(val & AMD_CPPC_ENABLE) )
>>> +    {
>>> +        val |= AMD_CPPC_ENABLE;
>>> +        wrmsrl(MSR_AMD_CPPC_ENABLE, val);
>>> +    }
>>> +
>>> +    rdmsrl(MSR_AMD_CPPC_CAP1, data->caps.raw);
>>
>> ... this and ...
>>
> GOV_GETAVG);
>>> +
>>> +    /* Store pre-defined BIOS value for passive mode */
>>> +    rdmsrl(MSR_AMD_CPPC_REQ, val);
>>
>> ... this?
> 
> They are all Per-thread MSR. I'll add descriptions.

If they're per-thread, coordination will be yet more difficult if any domain
had more than one thread in it. So question again: Is it perhaps disallowed
by the spec for there to be any "domain" covering more than a single thread?

>>> --- a/xen/include/acpi/cpufreq/cpufreq.h
>>> +++ b/xen/include/acpi/cpufreq/cpufreq.h
>>> @@ -63,6 +63,7 @@ struct perf_limits {  };
>>>
>>>  struct hwp_drv_data;
>>> +struct amd_cppc_drv_data;
>>>  struct cpufreq_policy {
>>>      cpumask_var_t       cpus;          /* affected CPUs */
>>>      unsigned int        shared_type;   /* ANY or ALL affected CPUs
>>> @@ -85,6 +86,9 @@ struct cpufreq_policy {
>>>      union {
>>>  #ifdef CONFIG_INTEL
>>>          struct hwp_drv_data *hwp; /* Driver data for Intel HWP */
>>> +#endif
>>> +#ifdef CONFIG_AMD
>>> +        struct amd_cppc_drv_data *amd_cppc; /* Driver data for AMD
>>> +CPPC */
>>>  #endif
>>>      } u;
>>>  };
>>
>> Same comments here as for the HWP patch.
> 
> May I ask why structure over pointer here?

Efficiency: Less allocations, and one less indirection level. For relatively
small structures you also want to consider the storage overhead of the extra
pointer.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 06:51:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 06:51:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111322.1460058 (Exim 4.92)
	(envelope-from )
	id 1uuQHy-0001Cy-Im; Fri, 05 Sep 2025 06:51:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111322.1460058; Fri, 05 Sep 2025 06: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 1uuQHy-0001Cr-Fv; Fri, 05 Sep 2025 06:51:14 +0000
Received: by outflank-mailman (input) for mailman id 1111322;
 Fri, 05 Sep 2025 06:51: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 1uuQHx-0001Cl-Su
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 06:51:13 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20614.outbound.protection.outlook.com
 [2a01:111:f403:2408::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b58ea329-8a24-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 08:51:11 +0200 (CEST)
Received: from CH2PR17CA0008.namprd17.prod.outlook.com (2603:10b6:610:53::18)
 by IA0PR12MB9047.namprd12.prod.outlook.com (2603:10b6:208:402::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Fri, 5 Sep
 2025 06:51:06 +0000
Received: from CH2PEPF00000147.namprd02.prod.outlook.com (2603:10b6:610:53::4)
 by CH2PR17CA0008.outlook.office365.com (2603:10b6:610:53::18) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.19
 via Frontend Transport; Fri, 5 Sep 2025 06:51:06 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000147.mail.protection.outlook.com (10.167.244.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9094.14 via Frontend Transport; Fri, 5 Sep 2025 06:51:06 +0000
Received: from satlexmb10.amd.com (10.181.42.219) 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, 5 Sep
 2025 01:51:05 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Thu, 4 Sep
 2025 23:51:05 -0700
Received: from [10.252.147.171] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 5 Sep 2025 01:51: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: b58ea329-8a24-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qqvYLna2QzK1Qx9X6Y/R28oj33gZeu2AdSnDLKMTvvWtvpPSKTjvNvSufc+QLVZXnmmAXzc8Hr6cwtt/8dsYuB+iu2c1lJRfkddOUqNDSDPcl9PhZxJrUaQlaOIKobsJ1bPkWpNWhTLWfV/9E1MoHsP2DCBwO6Zi5dJSQGBdougeXqxZHlBsibuY6Cx+B6X0w0YsP7SH/m228PXnCwacDF3O8bz1Ask8WEMDLXE6FBr2jl1JJmlnNI0FsTk7XPGcrw9UwohmHmeYwbaMbi7VX5MqmB7470+AvirK6Spo4MbgM4mQ/BK0y3xoTSQWYXn15Afbd/dAIpTa1mHEOu210Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gw8OpFmjYlLvB4ag+NUsAeV5I9duKpiiR0K6V3keekU=;
 b=rWUGBcJT7lYu8u8h1/SwsMY47/LfmHaETXkrak5Jd2px7oEDYYHH8LEfajJe3SBfVLiKXMBBM/zO7GqoCTBOUZR5aEygACwK2qdF777DzVo67BA5ezEb9/ssKSjNr9Klay+fPHUAuxXSxSuzXb+fme7nogKY0qXdNhQXHQIIpBlqzyxx4UzyEctyamPDGwUYZjaNRbiEtwGIxRwCCde3rIHk0fgGcHIvxPSIFv2bp3KCowz6n/yKhKfM3+4EfbpbeGJ5k2I1Xrd0wPkYGgMVzV/i5XT0SsxX0ncUcUMuLmcw2t3CWnKMzL4KxGPSWSSV8g+lzf/IwNtWzFhKavvx3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Gw8OpFmjYlLvB4ag+NUsAeV5I9duKpiiR0K6V3keekU=;
 b=KYOJpxQuBlE7NWqxwqNrAnMLCIDbJR4eOi/5qKuGzusXFvU7tIrcOqz/k8Zb97cfonGxNAzQUf4jIaP9owPOky/SukcZRFZIcWfpRhVnIWrX7gXALCE/mvN4R2VUQ74BRposbg5qIkk6Ce8wrhkV1B92I8G44dUAT2rv5p5j3jo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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, 5 Sep 2025 08:51:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Differentiating "For experts only" and "Not security supported"
 in Kconfig
To: Demi Marie Obenour , Xen developer discussion
	
References: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000147:EE_|IA0PR12MB9047:EE_
X-MS-Office365-Filtering-Correlation-Id: e22bccf0-7fbe-4c27-c454-08ddec48966c
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?dWtSeE1vSWFpRWx4QUZxMk5INGZ3Q09uVENDTlVXeXNwTERtejNSNW94UmNU?=
 =?utf-8?B?alE2aVBOQlBQYnE3bDdrZzBZRjI5WTFPL0RlMEdBNTVIV1BpeGNGaXFTQldJ?=
 =?utf-8?B?R1JCZVlMWEg5SisrblE5aXBLNDBic0RVMzVsdC9Ycnh4MUpBNHZyQlFyNGM5?=
 =?utf-8?B?cTI1UVBTOUhkdnJEa0YzTWNJNkpua1BmY21kZzNZY25MMkxoUXIyNXhpRzZ4?=
 =?utf-8?B?elpaOTYzdXJVclFXd2JpL1FqS29sMG1ZU3Jxek9LaUVaczZhSVd2T1IwZEpL?=
 =?utf-8?B?b1RBckVsRkZ5MEVkTFBhWi9MZG91eldheW5QUlpYdWlVc0orN2dCdWMzN253?=
 =?utf-8?B?ZnRDVzVaMGdtNkJzOGg2Y3dFUndsbHkyb3J5Uzc3b0ZwSHQ1TmhoallDaXEx?=
 =?utf-8?B?VUlsQXVTa0xUa0FWNXZwUVNIaVNrd0JXcWszUEY1SVlCdTlxeDNzM1ZwcTB3?=
 =?utf-8?B?eDFtT1U0VzNOVkoxSDJITnp4cUUzZHN4R0NBUmpDM3N2L3NJLysyR0JhNjFO?=
 =?utf-8?B?Y1JKMEJER0wvU2tBaVJBUFh5dkpMcWNhTU1CQWVvSERHUEJGT0IzRGtVYjg1?=
 =?utf-8?B?L3k0SDJSSmxSa2w3bXNOUEE4Nzc2dGxBZ0NhNVU2WXFJN0JXdDZzVVU5QStK?=
 =?utf-8?B?eFd6M2ZPdnhjL1JjeGNCRjJuME5EWmhCYlJST2RRVzg3d2ZlL0pHUms0bDR2?=
 =?utf-8?B?VDVZMHNuS3Q0WExZaFV4K1VwZmpaakxLNE0vYjdURGlPUVBGZWpwQUVGaFhh?=
 =?utf-8?B?TUhZclpRUnZPSUpJd1ROUzJRNkVCVERBVEhvMlNZQWZObnMxN3lPc3hiMmFT?=
 =?utf-8?B?ejJHOEpJZlM1R2pIdkFGRzlpZjE5ejZNUnNiUG1VeVMxMEc3MHQzNDlEUjZ5?=
 =?utf-8?B?UkJhQjc1M1pwZXZmWEh3akk3cFZPNFU5ZnFBbTNscjRVRm5RL2FvWXFBWjl4?=
 =?utf-8?B?OUpCOSthRFJ6YXM4VkNrZ1FHaVVXM0RrZGEzdFNVcld5Zlk1WStJUHF2NmM3?=
 =?utf-8?B?QXp3NHZ5MEErKzAxT2ZtWHFFekh2V1VxdndObHdNMEJBMzA3UmZVR1N1aWxo?=
 =?utf-8?B?dGRhY0l5Q3hsZ0JBYUNLMW5wMTRWcUFOeEtkT2NROWp2MkZYNzNvT1lzWUs5?=
 =?utf-8?B?eS9ESnFKWC9MWjNyZFpXYmgxQk02YlJHeFJYNlFXUUw5WS9XaitqUHNkZ2xC?=
 =?utf-8?B?SG9RYWp0WEw5enQzenFyWThGb255QitNdmNGR1g0YUJZVlUzNjNCdFZhQ2VQ?=
 =?utf-8?B?LzVrSStKV0ZLUFE1M2FoSU1yTFhBRVUzdVFUUERDTEpGdEZEOWhUNlJieXJD?=
 =?utf-8?B?R05aMHYrRVE0SmNkNy9yNmhNck41c2k1QWRiVkpvK2ZhQXh6VHJOTWprdjZt?=
 =?utf-8?B?eDlVU0ZJbk8zK2JYdWhtb2JBdTNGZFJUa2plYy9DSlc2OWRZd252OXYyRDJP?=
 =?utf-8?B?aDRJdHRzajdYYWlrUUt0NVluZ1prZndsWE02UjlBKzQ2c3EvckMrbG9CaWpG?=
 =?utf-8?B?VEZTMHg4c3Z5K2dlSi90THJNQkJ0OUV6SUE3cHE1eDJiek1ZcHUxVmhhdnVU?=
 =?utf-8?B?c3l4ZmpJOUwrVXNrdzg2MGt3VE01cGg1bnVpZnZiL2REV3cxNEtQcXVUeDBI?=
 =?utf-8?B?d0M3NHlOQVRsQlRDeEcxTFU0S1JNQU9WNXZxNUNZTWpYQVBCZENGYmo1Qi9i?=
 =?utf-8?B?M3BCUDhHTC9nK0FubjZBa1ZRaHRYdDBxQktaZU9vSkYrK2M2bjU4OUsxcldx?=
 =?utf-8?B?eHNLb1RBNnVKQjMyRmJ2RmdoWW50TG1PeGtyUlpZNUtocjVuN25QWHpHSU5v?=
 =?utf-8?B?b0I3eGRFMHBtK3p2QVhGUTBDZ3RwMG5UckRpWjZUeTdqaUZlVStpMGVnUGgz?=
 =?utf-8?B?R29rNDV1RTJsU1AyaERvZ0NOYUtoZ1dNQnRiMFdpTTQ4SCtQWm1LL2hjUmZ4?=
 =?utf-8?B?S0E0d1NFY1JqOGVHelBGczQ2bUc2cmgvbFBGQ29tSlJTQ2lHZ25UaXJLRE43?=
 =?utf-8?B?dEVCdHZidlhTSUxLTjhjamNkVEtVMU5HQWZnTXF1aFRDV2docS9GVzY1R3M1?=
 =?utf-8?Q?ePdOF/?=
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: 05 Sep 2025 06:51:06.1447
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e22bccf0-7fbe-4c27-c454-08ddec48966c
X-MS-Exchange-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:
	CH2PEPF00000147.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB9047



On 05/09/2025 05:47, Demi Marie Obenour wrote:
> Right now, both EXPERT and UNSUPPORTED options are
> not security supported.  However, this seems to be
> causing problems for safety-certified use-cases.
> 
> Specifically, disabling AMD or Intel support is certainly
> something that should fall under EXPERT IMO, as it is a
> great way to produce a Xen binary that will not boot on
> a large fraction of hardware.  However, I see no fundamental
> reason it should not be security supported.  Not security
> supporting it means that those producing safety-certified
> builds of Xen (which, presumably, are some of the most
> security-critical there are!) are having to use
> security-unsupported configurations.
> 
> This definitely does not seem right to me.  Safety
> certification and security support should go hand in hand,
> not conflict with each other!  Is there a plan to address this?
What makes you say that? Functional safety and security, although often
intertwined differ in focus areas and objectives. Functional safety aims
at reducing the risk of unintended hazards caused by malfunction of system
components, whereas security is about reducing the risk of intentional threats.
There are different standards for safety and security. Current AMD safety work
focuses on ISO26262 and IEC61508 but there are security standards like ISO/SAE
21434.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:04:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:04:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111336.1460068 (Exim 4.92)
	(envelope-from )
	id 1uuQVA-000342-Mg; Fri, 05 Sep 2025 07:04:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111336.1460068; Fri, 05 Sep 2025 07: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 1uuQVA-00033v-Jb; Fri, 05 Sep 2025 07:04:52 +0000
Received: by outflank-mailman (input) for mailman id 1111336;
 Fri, 05 Sep 2025 07:04:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuQV9-00033p-B6
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:04:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuQV8-007otw-1N;
 Fri, 05 Sep 2025 07:04:50 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuQV8-00GhXj-1M;
 Fri, 05 Sep 2025 07: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" 
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=hm+6mOUUCuI9jDi17Rwk/pp1Mc2zlId/fn8fNgio+lA=; b=yoO2wjcQAjW+TirBc4fPG7IiZC
	+0TDcf0CkMLTl/FRh7PQK6rufSwPVzjENw8BIOElr5e19+eHIdvRG2ZLY70GwJMG0wuGEG6PP3ymS
	saasFj0cXL5Z7HOroMI15g/E9AYJSUS6R0irfdIWooFdSJ/dye3gvC7K7b5CGb0pXZAE=;
Message-ID: <9e69e282-ea6b-4d4d-ae3c-27c4d3b7ccf4@xen.org>
Date: Fri, 5 Sep 2025 08:04:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
Content-Language: en-GB
To: Grygorii Strashko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
From: Julien Grall 
In-Reply-To: <20250806094929.293658-4-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Grygorii,

On 06/08/2025 10:49, Grygorii Strashko wrote:
> From: Grygorii Strashko 
> 
> Now Arm64 AArch32 guest support is always enabled and built-in while not
> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this

typo s/exmaple/example/

> support might not be needed (Arm64 AArch32 is used quite rarely in embedded
> systems). 


 > More over, when focusing on safety certification, AArch32 related> 
code in Xen leaves a gap in terms of coverage that cannot really be
> justified in words. This leaves two options: either support it (lots of
> additional testing, requirements and documents would be needed) or compile
> it out.

To clarify my understanding, what you are removing is support for 32-bit 
EL1. But 32-bit EL0 will still be supported. Is that correct?

[...]

> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>    AArch32 is disabled.

A guest is not allowed to switch bitness. So I am not sure why we need 
to hide EL1. Depending on the answer above, you might need to hide EL0 
and have more code (TBC) to prevent 32-bit EL0 running.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111356.1460078 (Exim 4.92)
	(envelope-from )
	id 1uuQar-0004cB-9M; Fri, 05 Sep 2025 07:10:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111356.1460078; Fri, 05 Sep 2025 07: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 1uuQar-0004c4-6L; Fri, 05 Sep 2025 07:10:45 +0000
Received: by outflank-mailman (input) for mailman id 1111356;
 Fri, 05 Sep 2025 07:10:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuQap-0004bw-Gr
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:10:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuQao-007p1d-33;
 Fri, 05 Sep 2025 07:10:43 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuQao-00GhnD-3A;
 Fri, 05 Sep 2025 07:10: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=Q3hmwYzlnHdqTiNPtPRmTAfQw1xTRe6hVjOxE1ArniE=; b=JfunKLpQVXE0PJw0U6MGOZgqdw
	jQVSswu5thaO2SEvm6jEmczRmGRVChMcfvAYX36a/WUgEA8MVi0BQ/e+C1HMPCcmMCKxQaQGHyQKC
	Q/Qwjz3lHu4aKHizU56PXuIYUWYBM4ZuQfwDZqGYA6trPrX5UDev6sI3socfk6cZuWFI=;
Message-ID: <3a487f5c-0837-46b4-ad17-410a4a4bc78a@xen.org>
Date: Fri, 5 Sep 2025 08:10:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
From: Julien Grall 
In-Reply-To: <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 04/09/2025 21:01, Leonid Komarianskyi wrote:
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
> index 5bc6475eb4..2ff2d07d6d 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>   #define SPI_MAX_INTID   1019
>   #define LPI_OFFSET      8192
>   
> +#define ESPI_BASE_INTID 4096
> +#define ESPI_MAX_INTID  5119
> +#define NR_ESPI_IRQS    1024
> +
>   /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */
>   #define INVALID_LPI     0
>   
> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>   #define INVALID_IRQ     1023
>   
>   extern const unsigned int nr_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +/* This will cover the eSPI range, to allow asignmant of eSPIs to domains. */

Typo: s/asignmant/assignment/

[...]

> Unless INTIDs from the eSPI
> + * range are mistakenly defined in Xen DTS when the appropriate config is
> + * disabled, this function will not be reached because is_espi will return
> + * false for non-eSPI INTIDs.

I am still confused with this paragraph. How is this function can be 
reached if it is compiled out? Surely, if the DT is misconfigured, we 
should get an error when trying to route the interrupt. No? If so, can 
you point me to that code?

Cheers,

-- 
aJulien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:11:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:11:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111367.1460089 (Exim 4.92)
	(envelope-from )
	id 1uuQc0-0005Cq-I4; Fri, 05 Sep 2025 07:11:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111367.1460089; Fri, 05 Sep 2025 07:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuQc0-0005Cj-FO; Fri, 05 Sep 2025 07:11:56 +0000
Received: by outflank-mailman (input) for mailman id 1111367;
 Fri, 05 Sep 2025 07:11:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuQbz-0005Cd-7k
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:11:55 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062b.outbound.protection.outlook.com
 [2a01:111:f403:200a::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 93df585b-8a27-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 09:11:45 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DS0PR12MB8293.namprd12.prod.outlook.com (2603:10b6:8:f3::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.17; Fri, 5 Sep 2025 07:11:40 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%7]) with mapi id 15.20.9052.019; Fri, 5 Sep 2025
 07:11: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: 93df585b-8a27-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BtaeE/qsWyF+Maa3tspRJP15Y+90q9EXi2ini9rfTfIwlIKIeMvW9I+XM/UeeCCJV86k2sn6XGwB84wlJvz6nfIVbMwSmOen3V23tRUfwvv0em5jE83HxBpJUsdwRfmXP1m1nLDF6acfIKYleXtJOB99u9XCep7y9/9feqNmFu7/9bXg7d4E+ctrE4AvT2fjQvD2hFxNFs1q7GCMZV0jvsfinvfOKcR6ez1M8/5ur4qMYl4eXskwK3hFyV5Bwp4I5hOwuAILxemTgPyMmcx5qo0jN6EiR1X8PC4qA3hXLtYW0evo0AQWRzmYb14Txl/eNZ7lwbGRPJ11nM/upclsJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nHGi6zbgHkLU1ZLPoLcYtWxoeAcJ5MGH6pc7mdfbh+k=;
 b=UdCFIZoJfOFUACbW2aPeJ4CkToqW1B8YiaFIveGwN3y9A1SwluHxYeYgij1GjRJa5MnmV7qXmeUiAbthB6ivWiDCFxdeFs1sYTd4vQOmQBAB0x0feUEj5HkFU6nS3FtocrivWJRSGuyCBtvE71i26jYdXNlWyd1GKem+AMRWoZYHAIKeJ2u016XtSlwvpByH4JID9ucoeIwmaEfuqbDgmhNhvFc5GvEyhHF/RThVcc5M9h2g1IAxUgqhqN26YFMyNP74PhduSrtap0/DrIL/ZKIF6ArQNqJbaYOUw29tiRTwOgylCOp9XYwba+PDyBhCiSrIlLxV8jmRaBRXJFzDXw==
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=nHGi6zbgHkLU1ZLPoLcYtWxoeAcJ5MGH6pc7mdfbh+k=;
 b=5EvlJWYkSRiwgByp6v6nT1qfZwW7+ho/GFWjqydmudRBVBxogZf2KAlHjzgPLse0V0YJI+NUDnXStc5Q918JSkBky04Pc0zhymwkKfkipBEtrR0CRouif44XWqq+pdtPWJvkdQufYqVCsxT/ss2A1z0uBJLCTyVjpATPlhO+cXc=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: Andrew Cooper ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Anthony PERARD
	, "Orzel, Michal" , Julien
 Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in
 passive mode
Thread-Topic: [PATCH v9 2/8] xen/cpufreq: implement amd-cppc driver for CPPC
 in passive mode
Thread-Index: AQHcHWYoaQVmnKMmQ0CpiPNNytQ3NLSC7UgAgAEbxuCAAB1BAIAAAG6g
Date: Fri, 5 Sep 2025 07:11:40 +0000
Message-ID:
 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-3-Penny.Zheng@amd.com>
 <7e769952-a906-4a3e-af27-26faa76f6dd4@suse.com>
 
 <4f2ff564-e64a-4d0e-b123-d85b81f10929@suse.com>
In-Reply-To: <4f2ff564-e64a-4d0e-b123-d85b81f10929@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-09-05T07:11:34.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_|DS0PR12MB8293:EE_
x-ms-office365-filtering-correlation-id: cae7acd7-9e87-4396-e55d-08ddec4b762c
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?WUt3MkI5aVovZmoySGFobTl1dnlFZUdneVkvYytIaXp1NGF0SGJ3KzF0b214?=
 =?utf-8?B?QjVEWkUyTGlubm9xZHNWSUE1QXdVUFhlclVuRVdtQ1l0aCtRRmRNS0FHZEJa?=
 =?utf-8?B?UzJrZ1V2SFg2NjVzYzJYVHRKczc2a2RxalNDQmZyUVhTVDd5TkZ2a0tzckV1?=
 =?utf-8?B?b0lLMVJXczliU1A5bDdRMStpZVZWSENuOER0UDA5OGNMWG5FcjI3OVVDSEhI?=
 =?utf-8?B?enRISVJXMEIvbGpoUXpueTVnMFJYK0Q2NVpuRVBlaTl4Q3JQVXdVWFp6QTM1?=
 =?utf-8?B?TWU2dXBieDgzNmRUNVpPMlNPWmhEM2ZYYlFYUVZoaTRnL3NXVlQ5RFc0dHg4?=
 =?utf-8?B?QURBaUV0bjZiSzJ1SW9CYzJTUmpPalIxZGgyNXpCNk12aWVlMXVVck51ckVP?=
 =?utf-8?B?azc3R29lSmtHQU4xT2dpRjJ3RzBzdHdvRlNFc0h3T0MzbzJwd3k1UllrYVlq?=
 =?utf-8?B?UjFPaUcrVTdtRGVIV3F1Qno4T0ZQQThCd2Vhb1NrSFBtVzNESGJhZ0t4ajdE?=
 =?utf-8?B?NzJkZmIyK0hNOURnZFViUmFDS256d3h4OU1SM2c2bGpEU1gvT2pIUk9oZEp5?=
 =?utf-8?B?UXdqN0Z2VnNETjh6NWV6UXJYZ0tYTEVzTDRMcDNYNG1ZVHVmWDBnZ1VneW5Y?=
 =?utf-8?B?SEExcC9vWHBkaXdYQjd0YTk1UDAwalExYzlkRHRHOERJY2RRY09hb2U5RXJu?=
 =?utf-8?B?L2hCUjdxVFk4UHhmc1RtdXVSVFNnYWNJZjRZNi9oODZPaUpVWEpFNXIwamZB?=
 =?utf-8?B?YlFvWHVzL3RXRTloaGIyMmp2MWY1SHhYeGlnd1YvVUJVb2w2Um9DRWxSS0pD?=
 =?utf-8?B?WlplY3NTeFFzZXJuL1R6dVhLNjJpSnovRlpUckZmWmZwUUczdE4wZ3pYQkx0?=
 =?utf-8?B?UnRRakd6ckFpYVFvN2ZjVTl5Z0hxRjNaNTV1VFoxR29uOThHRHRoVEltYU5S?=
 =?utf-8?B?OXUyZHlVWENvb2MvMGsrYzh6LzVRZloyNWNXNFJoL1ZCdmZMd0lNYnpubitL?=
 =?utf-8?B?dTZNc002Z1dDY3kweTlGZ0ZldFNtYTlmQ1JYVVVOU1Q4SVFiTStZTU1PR20x?=
 =?utf-8?B?VFVoQ2pPNWxjU1doYmRBZitNWFdqUFAxTzdNRjd5eVJxZXFHeUhIVkdrc0xk?=
 =?utf-8?B?cEp5dStCMFJPMnUva0kvK29KTlJNaEYxbzR0eVRRRzFZODhrK3VMdDRWaUV2?=
 =?utf-8?B?KzJNb1FtdlNjNDJDb0N4anFiMnFOVk5HbXQxWFZ2Q1JDSEM4WXNEa0E2aklK?=
 =?utf-8?B?TkhhL2pqM3RISnphd0pZOU1YSUZOY1hLWlhUQm9qbFhIVWxmTEdaRndoa3Js?=
 =?utf-8?B?NkVZTThsVG5TMnZDSnpCSnlIdnY1d1FKMC83eEljL1Q3bU9tQXZwYlNlMUI5?=
 =?utf-8?B?LzNXTWJmWE9vZTh5bVQ4Kyt6ZEpNb1E3VXU0KzhITndua3V6Z1RFNlFYeHRK?=
 =?utf-8?B?Y254dUxQTnJ6UktBWHBHU04wa3FLVWdNbFNDZ1NZUm5ZWENwQS9HR1pYOUNt?=
 =?utf-8?B?NjlnRDh6MGFzTVpGU3JtMUw4eTRyaVNGUDgyNlVGWGZJWHBzMVNCRmd3MnQx?=
 =?utf-8?B?MWUzbkUwYms3Vm4vYmtFaGR6VEdIMnhPZVZLVUY3YnRPSWpsVDRJb0JRYWdo?=
 =?utf-8?B?THpkZVdzOGJVWFNoNlNQU2xBM1M4Q1FnYWpiUXFaZjJ0K2kzYTN5S2VxeW0x?=
 =?utf-8?B?UFJCVUhJZGlaeUsvL09wTHB0NnhIS216c2FqamdpTklwV0RVTmlPckhoNWJK?=
 =?utf-8?B?QjJZckNDbU5YTG5HSzZTanVjOGJNWmlsdVpJNTcyREtPTVpzOVRnWkdka2pq?=
 =?utf-8?B?dW5HNGZNS0JnNWpkMkxiUG03Y05NVENVTkR3eFdaY3k2N2o0NkFLWFBwS2FC?=
 =?utf-8?B?NHN3Z0FTL1I0QU5iWHdjdmdOaVh3NkZZc3daY2JoMkRlTTAvTTByR2F3dGcz?=
 =?utf-8?B?SXgzZDh6eWJmYzhDN3Q3WWdMbXo1VmpqdXZTZlhuVUhFM3lFYW9rZDVHc2k2?=
 =?utf-8?B?d2h0T3c1ZWZRPT0=?=
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?Z2t0NlFLWlE2U1lFOXdLSHJteUhoZENkZWFFVW9RZnp4M1kvYjA1aDF6dzlZ?=
 =?utf-8?B?aE03Tk5adUQwTmFFMUgwRzBlT3dXb2RZa2ZhKzMwTXpOclBHRi9zc2M5L29x?=
 =?utf-8?B?SXc1Z1Nnank4dVR6My82SmtPc3BCM0VRa1NwNFI1eHN5ZlNFbTlJdHVrdEtL?=
 =?utf-8?B?QWlQSW5ERUFvNGNRNE5vb2FTSGgwMkdXMTVVYkJnNXdWL3NKSjJza0NSSVdz?=
 =?utf-8?B?S0NiSWNrUHZSWUNibWwwTElrRnp2MDhXNFh3T1pWUGFWemFCcER6ekZzWVpu?=
 =?utf-8?B?U1o5K0kvVXd3SjBLY2RpclF0M09tRGJhRm9xSUM1V2JJMXQvQ2VjT2IrTWFB?=
 =?utf-8?B?K1pRenUyVVF2aTRKN2YybUlid1pmUW1KdlpVTDBBY3RDWjFJUW42REhDWTJj?=
 =?utf-8?B?NlFkaXgzOGlibWY3VU5VRGNQZno3TXovY2VaNCtFK2xHSVN6akR3SUhqUE5w?=
 =?utf-8?B?S3p1V05IV1JnbCtTWUdKU3g4RUxQK0lkZ1UwNnNoUmxRRFNFamJYQk50cGxn?=
 =?utf-8?B?MGdOTmkrcHVYSW1qK2hCZTJPNkJDQ2JDa0hPa3BGaEVXZTk4djZRNzZFY3ZG?=
 =?utf-8?B?MVFsMzdHVEZ5YW1pNk5Hc0hrbEJlazdBek5FUjdoL3YzZC9aYUticnRmaTFl?=
 =?utf-8?B?RzUyOHNRb1p2SURtQy90Z0RCWFVEUGRTQ2EvSGU2emNQd0lHc2xobkV5aHFD?=
 =?utf-8?B?dnlDRVFsemZxWnZ3TVgramVGRUZGQ3Z3RjNZeXlwZXJtbDh1VWpsTStkRkVn?=
 =?utf-8?B?alNFUlJVUVlHVGNJYTk0VGhoeEN2eEZZKzRxaGhGNHJpME5HY2dSTnhNUFZp?=
 =?utf-8?B?a2xRc1pPU3RNRFcrR29ObDhwbW9CbzhQMk1RYyt1bm5DbkttOGw5NSt0czdN?=
 =?utf-8?B?MUh4Z1FHaU9FMm1rdUZRanM1MncraWxwNGZMcExRZDJCamkvWkRYcGIwaUht?=
 =?utf-8?B?K1ZsNStEUUtRM3A3OGN0YWg5ZDV3dEVRN05VUzZ5UVR4UEhrRDR6SERuSG5y?=
 =?utf-8?B?N0xFRkQ0V3dLckRrNmhQVEROT3MyQm80ZjBpZnN1RVF1MXVDL09QZ0dNeGZV?=
 =?utf-8?B?cDdMc0MvV0tBUjVMNERjdzhvM0ZGd1lRNUJ3MUdxOGNGc3pYQUxqRFpPQ2xP?=
 =?utf-8?B?VGNtQk1RZTQ0ZmpFcDg4bmR3R2xwbUZZKytJZnpPY1VCc241VHcwekZaZ3hI?=
 =?utf-8?B?TzlRRU9Pd0VJMUJQWi9jV0ZBVXFSb0VXNEljcVFYdnRqTHpCMWVqQUt5c2lB?=
 =?utf-8?B?Wkg5aVlESlVXTWZITEhoSHZVV1FEWHpURkJBYloySTJXdzRvZWY4VC9hbm8w?=
 =?utf-8?B?ZGZUbDJFVXVxRFg5dDFiYjVJS1lKczVERnE2M3NweXJwcEV3aXNVOTMzVTZ4?=
 =?utf-8?B?Ry9UcVBWWi9wdjgxaTJJVU9BM3RpUjQ4Znl6ZE04Z2I5NHFPeUNyRFd3TEc3?=
 =?utf-8?B?VW5hb1ZHMTFsUGxRNERLRU5wbTd0N3o2UVppL1BnaHBLRHJLYndScHdmMytp?=
 =?utf-8?B?Mk9HL0dsQm8zbGVIVytyZndWZ1hxUjAvbnNKM2thQThsU3lnTnFHeU5xZU9F?=
 =?utf-8?B?Q05hYkFXTStaRDM1dzFla0F1K2IvQUt1WlNJYXF4c2tXUU5BWlJsdFpEVjFB?=
 =?utf-8?B?am45bHpzUk5zTTA3R2VPVlpLSUxwdExnay9YMmxrVVBVWWVSN3NiQ0Q2Y1lJ?=
 =?utf-8?B?d3hOdWtOUUZiSXI3aXYvMUdFVjhCY2I0YUQ4WjRxa1NFRHozdHRTK3RIcjlK?=
 =?utf-8?B?dGd5aW1yWWt4em9JR3l3LytXalFIUHAzdzZiSGtKVXVwTW5pYkJJQmtlQ3Nh?=
 =?utf-8?B?ZWxCU0J4TnpLY2QrSGtxUnhnOUMxQ2JraEcrQjh5dFM5ZDdKdlJpdmFMam9V?=
 =?utf-8?B?NUNab0xHRFZFY1pCdTNQWXMzWnVRcU9XZ3Z3U2VMcURMTjdPKytVT2xGeEd3?=
 =?utf-8?B?S1NvbUdOZjZRaVl1dkFxQjA0bXF1bzMrbjlMS3RHTmY5Z3NhSmtFQ01RRVF4?=
 =?utf-8?B?TTA2bFRNSDllOE1MNVpMZGRBZFFsbEpjQ2NMcU5tTmpwUSs0MmRFOStJVUxx?=
 =?utf-8?B?aUFQR1B6Z0tTdjl2c2V0THVHS3NOUkIvTFB4eXF1NFRVTkl3QmUxcEZIZnpE?=
 =?utf-8?Q?+etg=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: cae7acd7-9e87-4396-e55d-08ddec4b762c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 07:11:40.5603
 (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: Zi0gbfJDCncwHOOpTzsezX5h7BUjczDFFcuftqX/cjRwFQCHCIC+vYnYccFGbRdbrtQggi3kxvO0iUeLW+b3SA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8293

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDUsIDIw
MjUgMjo0NSBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD
YzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBN
b25uw6kNCj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgQW50aG9ueSBQRVJBUkQgPGFudGhvbnku
cGVyYXJkQHZhdGVzLnRlY2g+OyBPcnplbCwNCj4gTWljaGFsIDxNaWNoYWwuT3J6ZWxAYW1kLmNv
bT47IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+OyBTdGVmYW5vDQo+IFN0YWJlbGxpbmkg
PHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OSAyLzhdIHhlbi9jcHVmcmVxOiBpbXBsZW1lbnQgYW1k
LWNwcGMgZHJpdmVyIGZvciBDUFBDIGluDQo+IHBhc3NpdmUgbW9kZQ0KPg0KPiBPbiAwNS4wOS4y
MDI1IDA3OjE1LCBQZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4+IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4g
U2VudDogVGh1cnNkYXksIFNlcHRlbWJlciA0LCAyMDI1IDg6MDQgUE0NCj4gPj4NCj4gPj4gT24g
MDQuMDkuMjAyNSAwODozNSwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4+PiArc3RhdGljIHZvaWQg
Y2ZfY2hlY2sgYW1kX2NwcGNfd3JpdGVfcmVxdWVzdF9tc3JzKHZvaWQgKmluZm8pIHsNCj4gPj4+
ICsgICAgY29uc3Qgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhID0gaW5mbzsNCj4gPj4+
ICsNCj4gPj4+ICsgICAgd3Jtc3JsKE1TUl9BTURfQ1BQQ19SRVEsIGRhdGEtPnJlcS5yYXcpOyB9
DQo+ID4+PiArDQo+ID4+PiArc3RhdGljIHZvaWQgYW1kX2NwcGNfd3JpdGVfcmVxdWVzdCh1bnNp
Z25lZCBpbnQgY3B1LA0KPiA+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
c3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhLA0KPiA+Pj4gKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgdWludDhfdCBtaW5fcGVyZiwgdWludDhfdCBkZXNfcGVyZiwNCj4g
Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgbWF4X3BlcmYs
IHVpbnQ4X3QgZXBwKSB7DQo+ID4+PiArICAgIHVpbnQ2NF90IHByZXYgPSBkYXRhLT5yZXEucmF3
Ow0KPiA+Pj4gKw0KPiA+Pj4gKyAgICBkYXRhLT5yZXEubWluX3BlcmYgPSBtaW5fcGVyZjsNCj4g
Pj4+ICsgICAgZGF0YS0+cmVxLm1heF9wZXJmID0gbWF4X3BlcmY7DQo+ID4+PiArICAgIGRhdGEt
PnJlcS5kZXNfcGVyZiA9IGRlc19wZXJmOw0KPiA+Pj4gKyAgICBkYXRhLT5yZXEuZXBwID0gZXBw
Ow0KPiA+Pj4gKw0KPiA+Pj4gKyAgICBpZiAoIHByZXYgPT0gZGF0YS0+cmVxLnJhdyApDQo+ID4+
PiArICAgICAgICByZXR1cm47DQo+ID4+PiArDQo+ID4+PiArICAgIG9uX3NlbGVjdGVkX2NwdXMo
Y3B1bWFza19vZihjcHUpLCBhbWRfY3BwY193cml0ZV9yZXF1ZXN0X21zcnMsDQo+ID4+PiArIGRh
dGEsIDEpOw0KPiA+Pg0KPiA+PiBXaXRoICJjcHUiIGNvbWluZyBmcm9tIC4uLg0KPiA+Pg0KPiA+
Pj4gK30NCj4gPj4+ICsNCj4gPj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGFtZF9jcHBjX2NwdWZy
ZXFfdGFyZ2V0KHN0cnVjdCBjcHVmcmVxX3BvbGljeSAqcG9saWN5LA0KPiA+Pj4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHRhcmdldF9m
cmVxLA0KPiA+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dW5zaWduZWQgaW50IHJlbGF0aW9uKSB7DQo+ID4+PiArICAgIHN0cnVjdCBhbWRfY3BwY19kcnZf
ZGF0YSAqZGF0YSA9IHBvbGljeS0+dS5hbWRfY3BwYzsNCj4gPj4+ICsgICAgdWludDhfdCBkZXNf
cGVyZjsNCj4gPj4+ICsgICAgaW50IHJlczsNCj4gPj4+ICsNCj4gPj4+ICsgICAgaWYgKCB1bmxp
a2VseSghdGFyZ2V0X2ZyZXEpICkNCj4gPj4+ICsgICAgICAgIHJldHVybiAwOw0KPiA+Pj4gKw0K
PiA+Pj4gKyAgICByZXMgPSBhbWRfY3BwY19raHpfdG9fcGVyZihkYXRhLCB0YXJnZXRfZnJlcSwg
JmRlc19wZXJmKTsNCj4gPj4+ICsgICAgaWYgKCByZXMgKQ0KPiA+Pj4gKyAgICAgICAgcmV0dXJu
IHJlczsNCj4gPj4+ICsNCj4gPj4+ICsgICAgLyoNCj4gPj4+ICsgICAgICogSGF2aW5nIGEgcGVy
Zm9ybWFuY2UgbGV2ZWwgbG93ZXIgdGhhbiB0aGUgbG93ZXN0IG5vbmxpbmVhcg0KPiA+Pj4gKyAg
ICAgKiBwZXJmb3JtYW5jZSBsZXZlbCwgc3VjaCBhcywgbG93ZXN0X3BlcmYgPD0gcGVyZiA8PQ0K
PiBsb3dlc3Rfbm9ubGluZXJfcGVyZiwNCj4gPj4+ICsgICAgICogbWF5IGFjdHVhbGx5IGNhdXNl
IGFuIGVmZmljaWVuY3kgcGVuYWx0eSwgU28gd2hlbiBkZWNpZGluZyB0aGUgbWluX3BlcmYNCj4g
Pj4+ICsgICAgICogdmFsdWUsIHdlIHByZWZlciBsb3dlc3Qgbm9ubGluZWFyIHBlcmZvcm1hbmNl
IG92ZXIgbG93ZXN0IHBlcmZvcm1hbmNlLg0KPiA+Pj4gKyAgICAgKi8NCj4gPj4+ICsgICAgYW1k
X2NwcGNfd3JpdGVfcmVxdWVzdChwb2xpY3ktPmNwdSwgZGF0YSwNCj4gPj4+ICsgZGF0YS0+Y2Fw
cy5sb3dlc3Rfbm9ubGluZWFyX3BlcmYsDQo+ID4+DQo+ID4+IC4uLiBoZXJlLCBob3cgY2FuIHRo
aXMgd29yayB3aGVuIHRoaXMgcGFydGljdWxhciBDUFUgaXNuJ3Qgb25saW5lIGFueW1vcmU/DQo+
ID4NCj4gPiBPbmNlIGFueSBwcm9jZXNzb3IgaW4gdGhlIGRvbWFpbiBnZXRzIG9mZmxpbmUsIHRo
ZSBnb3Zlcm5vciB3aWxsIHN0b3AsDQo+IHRoZW4gLnRhcmdldCgpIGNvdWxkIG5vdCBiZSBpbnZv
a2VkIGFueSBtb3JlOg0KPiA+IGBgYA0KPiA+ICAgICAgICAgaWYgKCBod19hbGwgfHwgY3B1bWFz
a193ZWlnaHQoY3B1ZnJlcV9kb20tPm1hcCkgPT0gZG9tYWluX2luZm8tDQo+ID5udW1fcHJvY2Vz
c29ycyApDQo+ID4gICAgICAgICAgICAgICAgIF9fY3B1ZnJlcV9nb3Zlcm5vcihwb2xpY3ksIENQ
VUZSRVFfR09WX1NUT1ApOyBgYGANCj4NCj4gSSBjYW4ndCBicmluZyB0aGUgY29kZSBpbiBsaW5l
IHdpdGggd2hhdCB5b3Ugc2F5Lg0KDQpPbmx5IHByb2Nlc3NvcnMgaW4gdGhlIGRvbWFpbiBhcmUg
YWxsIG9ubGluZSwgdGhlIHdlaWdodCBlcXVhdGVzIHRvIHRoZSAibnVtX3Byb2Nlc3NvcnMiLiBU
aGF0IGlzLCBnb3Zlcm5vciBzdG9wcyB3aGVuIHRoZSAqZmlyc3QqIHByb2Nlc3NvciB0cmllcyB0
byBvZmZsaW5lLg0KSWYgZ292IHN0b3BzLCBjcHVmcmVxLT50YXJnZXQoKSB3aWxsIG5vdCBiZSBl
eGVjdXRlZCBhbnkgbW9yZS4NCkFsc28sIGluIF9fY3B1ZnJlcV9kcml2ZXJfdGFyZ2V0KCksIHdl
IHdpbGwgZG8gdGhlIGNwdV9vbmxpbmUocG9saWN5LT5jcHUpIGNoZWNrIHRvIGVuc3VyZSByZWdp
c3RlcmVkIGNwdSBpbiBwb2xpY3ktPmNwdSBpcyBvbmxpbmUNCg0KPg0KPiA+Pj4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGRlc19wZXJmLCBkYXRhLT5jYXBzLmhpZ2hlc3RfcGVyZiwNCj4g
Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBQcmUtZGVmaW5lZCBCSU9TIHZhbHVl
IGZvciBwYXNzaXZlIG1vZGUgKi8NCj4gPj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICBw
ZXJfY3B1KGVwcF9pbml0LCBwb2xpY3ktPmNwdSkpOw0KPiA+Pj4gKyAgICByZXR1cm4gMDsNCj4g
Pj4+ICt9DQo+ID4+PiArDQo+ID4+PiArc3RhdGljIHZvaWQgY2ZfY2hlY2sgYW1kX2NwcGNfaW5p
dF9tc3JzKHZvaWQgKmluZm8pIHsNCj4gPj4+ICsgICAgc3RydWN0IGNwdWZyZXFfcG9saWN5ICpw
b2xpY3kgPSBpbmZvOw0KPiA+Pj4gKyAgICBzdHJ1Y3QgYW1kX2NwcGNfZHJ2X2RhdGEgKmRhdGEg
PSBwb2xpY3ktPnUuYW1kX2NwcGM7DQo+ID4+PiArICAgIHVpbnQ2NF90IHZhbDsNCj4gPj4+ICsg
ICAgdW5zaWduZWQgaW50IG1pbl9mcmVxID0gMCwgbm9taW5hbF9mcmVxID0gMCwgbWF4X2ZyZXE7
DQo+ID4+PiArDQo+ID4+PiArICAgIC8qIFBhY2thZ2UgbGV2ZWwgTVNSICovDQo+ID4+PiArICAg
IHJkbXNybChNU1JfQU1EX0NQUENfRU5BQkxFLCB2YWwpOw0KPiA+Pg0KPiA+PiBIZXJlIHlvdSBj
bGFyaWZ5IHRoZSBzY29wZSwgeWV0IHdoYXQgYWJvdXQgLi4uDQo+ID4+DQo+ID4+PiArICAgIC8q
DQo+ID4+PiArICAgICAqIE9ubHkgd2hlbiBFbmFibGUgYml0IGlzIG9uLCB0aGUgaGFyZHdhcmUg
d2lsbCBjYWxjdWxhdGUgdGhlIHByb2Nlc3NvcuKAmXMNCj4gPj4+ICsgICAgICogcGVyZm9ybWFu
Y2UgY2FwYWJpbGl0aWVzIGFuZCBpbml0aWFsaXplIHRoZSBwZXJmb3JtYW5jZSBsZXZlbCBmaWVs
ZHMgaW4NCj4gPj4+ICsgICAgICogdGhlIENQUEMgY2FwYWJpbGl0eSByZWdpc3RlcnMuDQo+ID4+
PiArICAgICAqLw0KPiA+Pj4gKyAgICBpZiAoICEodmFsICYgQU1EX0NQUENfRU5BQkxFKSApDQo+
ID4+PiArICAgIHsNCj4gPj4+ICsgICAgICAgIHZhbCB8PSBBTURfQ1BQQ19FTkFCTEU7DQo+ID4+
PiArICAgICAgICB3cm1zcmwoTVNSX0FNRF9DUFBDX0VOQUJMRSwgdmFsKTsNCj4gPj4+ICsgICAg
fQ0KPiA+Pj4gKw0KPiA+Pj4gKyAgICByZG1zcmwoTVNSX0FNRF9DUFBDX0NBUDEsIGRhdGEtPmNh
cHMucmF3KTsNCj4gPj4NCj4gPj4gLi4uIHRoaXMgYW5kIC4uLg0KPiA+Pg0KPiA+IEdPVl9HRVRB
VkcpOw0KPiA+Pj4gKw0KPiA+Pj4gKyAgICAvKiBTdG9yZSBwcmUtZGVmaW5lZCBCSU9TIHZhbHVl
IGZvciBwYXNzaXZlIG1vZGUgKi8NCj4gPj4+ICsgICAgcmRtc3JsKE1TUl9BTURfQ1BQQ19SRVEs
IHZhbCk7DQo+ID4+DQo+ID4+IC4uLiB0aGlzPw0KPiA+DQo+ID4gVGhleSBhcmUgYWxsIFBlci10
aHJlYWQgTVNSLiBJJ2xsIGFkZCBkZXNjcmlwdGlvbnMuDQo+DQo+IElmIHRoZXkncmUgcGVyLXRo
cmVhZCwgY29vcmRpbmF0aW9uIHdpbGwgYmUgeWV0IG1vcmUgZGlmZmljdWx0IGlmIGFueSBkb21h
aW4gaGFkIG1vcmUNCj4gdGhhbiBvbmUgdGhyZWFkIGluIGl0LiBTbyBxdWVzdGlvbiBhZ2Fpbjog
SXMgaXQgcGVyaGFwcyBkaXNhbGxvd2VkIGJ5IHRoZSBzcGVjIGZvcg0KPiB0aGVyZSB0byBiZSBh
bnkgImRvbWFpbiIgY292ZXJpbmcgbW9yZSB0aGFuIGEgc2luZ2xlIHRocmVhZD8NCj4NCg0KSSds
bCBkb3VibGUtY2hlY2sgd2l0aCB0aGUgaGFyZHdhcmUgdGVhbSBhYm91dCBpdC4NCg0KQWxzbywg
bWF5YmUgeGVuIGN1cnJlbnQgY29kZSBpcyBhbHJlYWR5IG92ZXJpbmcgU1dfQU5ZIGNvb3JkaW5h
dGlvbi4gQXMgZm9yIFNXX0FOWSBjb29yZGluYXRpb24gdHlwZSwgdGhlIE9TIG5lZWRzIHRvIGNv
b3JkaW5hdGUgdGhlIHN0YXRlIGZvciBhbGwgcHJvY2Vzc29ycyBpbiB0aGUgZG9tYWluIGJ5IG1h
a2luZyBhIHN0YXRlIHJlcXVlc3Qgb24gdGhlIGNvbnRyb2wgaW50ZXJmYWNlIG9mICpvbmx5IG9u
ZSogcHJvY2Vzc29yIGluIHRoZSBkb21haW4uIEluIFhlbiwgaWcsIHRoZSAib25seSBvbmUiIGlz
IHRoZSBjcHUgcmVnaXN0ZXJlZCBpbiBwb2xpY3ktPmNwdS4NCkJ1dCBmb3IgIlNXX0FMTCIsIHRo
ZSBPU1BNIGNvb3JkaW5hdGVzIHRoZSBzdGF0ZSBmb3IgYWxsIHByb2Nlc3NvcnMgaW4gdGhlIGRv
bWFpbiBieSBtYWtpbmcgdGhlIHNhbWUgc3RhdGUgcmVxdWVzdCBvbiB0aGUgY29udHJvbCBpbnRl
cmZhY2Ugb2YgKmVhY2ggcHJvY2Vzc29yIiBpbiB0aGUgZG9tYWluLCBJIGhhdmVuJ3Qgc2VlIGFu
eSBjb2RlcyBjb29yZGluYXRpbmcgdGhlIHN5bmNocm9uaXphdGlvbiBpbiBYZW4NCg0KPiBKYW4N
Cg==


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:22:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:22:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111382.1460106 (Exim 4.92)
	(envelope-from )
	id 1uuQmc-000735-I9; Fri, 05 Sep 2025 07:22:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111382.1460106; Fri, 05 Sep 2025 07: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 1uuQmc-00072y-FJ; Fri, 05 Sep 2025 07:22:54 +0000
Received: by outflank-mailman (input) for mailman id 1111382;
 Fri, 05 Sep 2025 07:22:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuQma-00072s-Sy
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:22:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuQma-007pIH-0U;
 Fri, 05 Sep 2025 07:22:52 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuQma-00GiTo-0R;
 Fri, 05 Sep 2025 07:22:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=gop+oxj4bO8artlzo8X4bb3Kxw3+M0m0HtSiUqEXQJE=; b=s28Vm1XLuhnpo7KwOC0Jd+/Swy
	QCYy/zfDpVKO+FgszAuDvlpzL/VpzZSX/zf1j2ZrPcGRw9t51cEJswgbfAPTJM+qXYiOKm5I1vc+D
	3TIMIFRveDb9F4Homy1Rn6hiZOvwJvXjalDDh+Y+MZ6YuVYtWTrBevoGsMT+hRQEumjM=;
Message-ID: <820704d0-4047-4f02-a058-01daba2765f1@xen.org>
Date: Fri, 5 Sep 2025 08:22:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 04/09/2025 21:01, Leonid Komarianskyi wrote:
> +#ifdef CONFIG_GICV3_ESPI
> +unsigned int gic_number_espis(void)
> +{
> +    return gic_hw_ops->info->nr_espi;
> +}
> +
> +static void __init gicv3_dist_espi_common_init(uint32_t type)
> +{
> +    unsigned int espi_nr, i;
> +
> +    espi_nr = min(1024U, GICD_TYPER_ESPIS_NUM(type));
> +    gicv3_info.nr_espi = espi_nr;
> +    /* The GIC HW doesn't support eSPI, so we can leave from here */
> +    if ( gicv3_info.nr_espi == 0 )
> +        return;
> +
> +    printk("GICv3: %d eSPI lines\n", gicv3_info.nr_espi);

Style: nr_espi is unsigned. So it should be %u. Can be fixed on commit 
if there is nothing else major to change.

> +
> +    /* The configuration for eSPIs is similar to that for regular SPIs */
> +    for ( i = 0; i < espi_nr; i += 16 )
> +        writel_relaxed(0, GICD + GICD_ICFGRnE + (i / 16) * 4);
> +
> +    for ( i = 0; i < espi_nr; i += 4 )
> +        writel_relaxed(GIC_PRI_IRQ_ALL,
> +                       GICD + GICD_IPRIORITYRnE + (i / 4) * 4);
> +
> +    for ( i = 0; i < espi_nr; i += 32 )
> +    {
> +        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLERnE + (i / 32) * 4);

Sorry I only spotted now.

The goal of gicv3_dist_espi_common_init() is to make sure the GIC is in 
a sane state for Xen (the previous OS or firmware may have left some 
state). Now the firmware may decide to use eSPI but not Xen (e.g. 
because CONFIG_ESPI=n).

This would means we may have eSPI interrupts that may be enabled and 
pending. So as soon as we re-enable the GIC we may receive interrupts we 
can't handle. So I think we may need to initialize the eSPI part of the 
distributor unconditionally. What do you think?


This could be handled as a follow-up but within the timeframe of Xen 
4.21. So for this patch:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:23:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:23:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111395.1460117 (Exim 4.92)
	(envelope-from )
	id 1uuQnC-0007aU-Ve; Fri, 05 Sep 2025 07:23:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111395.1460117; Fri, 05 Sep 2025 07:23:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuQnC-0007aN-Ro; Fri, 05 Sep 2025 07:23:30 +0000
Received: by outflank-mailman (input) for mailman id 1111395;
 Fri, 05 Sep 2025 07:23:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuQnC-0007aH-CF
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:23:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuQnB-007pKi-2F;
 Fri, 05 Sep 2025 07:23:29 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuQnB-00GiUT-2D;
 Fri, 05 Sep 2025 07:23:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=AtJ887wmxWLfsHZXOhrGSKBxCXzV07vT2QcFkyzVjsM=; b=qu84HmV9R4MjY1qt0Q4PTFJYHh
	pDNSprFE/Ang3KrcG29de4E/a3DsKIBAwtqV2dA0aqoroOy4lPxjVe9TnsnKiuDhD1ZP3HHxVihTc
	hhtwvjvtk/UtKcFqSK3vfhfqQOCV4uy96hPf7BjDwW+/BtBF8yKXLHSo4KgGiLBNl/+8=;
Message-ID: 
Date: Fri, 5 Sep 2025 08:23:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to
 allow eSPI processing
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <4a5c8a903c7b03716ea8c76b3e1dafd529a8684e.1757015865.git.leonid_komarianskyi@epam.com>
From: Julien Grall 
In-Reply-To: <4a5c8a903c7b03716ea8c76b3e1dafd529a8684e.1757015865.git.leonid_komarianskyi@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 04/09/2025 21:01, Leonid Komarianskyi wrote:
> To properly deactivate physical eSPI routed to a domain and allow them to
> be retriggered after the initial trigger, the LR needs to be updated. The
> current implementation ignores interrupts outside the range specified by
> the mask 0x3FF, which only covers IRQ numbers up to 1023. To enable
> processing of eSPI interrupts, this patch updates the mask to 0x1FFF.
> 
> Signed-off-by: Leonid Komarianskyi 
> Reviewed-by: Volodymyr Babchuk 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:27:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:27:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111406.1460127 (Exim 4.92)
	(envelope-from )
	id 1uuQrH-0008Cr-Eh; Fri, 05 Sep 2025 07:27:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111406.1460127; Fri, 05 Sep 2025 07:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuQrH-0008Ck-Bk; Fri, 05 Sep 2025 07:27:43 +0000
Received: by outflank-mailman (input) for mailman id 1111406;
 Fri, 05 Sep 2025 07:27:42 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuQrG-0008Ce-Dr
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:27:42 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuQrF-007pOq-2L;
 Fri, 05 Sep 2025 07:27:41 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuQrF-00Gikf-2U;
 Fri, 05 Sep 2025 07:27: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=QFX2putu/RDCBUCn5pVOzHH3BMrtSBtgTYaiU+R6VbQ=; b=FVTBqH9hmgzGDiPXutvbgZ6rJf
	vt1YDqdDGoGdNqx87TE2IBtwuDbkDLcyP1qUgJymBTn22ZGRLX6Cec2QOxk511xQi/ljq6+j7Crsy
	WRGvNoiro/wmt0nhFEzPwre89hM5HsiO9hI6TgiR/f8kup+vml37po572i2x0r6pViv8=;
Message-ID: <6f06ffc2-ada1-4b2e-ae36-a3244e1c0da7@xen.org>
Date: Fri, 5 Sep 2025 08:27:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
References: 
 <5b34940bbc90c4144f4d91880524f452d974d14a.1757015865.git.leonid_komarianskyi@epam.com>
From: Julien Grall 
In-Reply-To: <5b34940bbc90c4144f4d91880524f452d974d14a.1757015865.git.leonid_komarianskyi@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 04/09/2025 21:01, Leonid Komarianskyi wrote:
> This change introduces resource management in the VGIC to handle
> extended SPIs introduced in GICv3.1. The pending_irqs and
> allocated_irqs arrays are resized to support the required
> number of eSPIs, based on what is supported by the hardware and
> requested by the guest. A new field, ext_shared_irqs, is added
> to the VGIC structure to store information about eSPIs, similar
> to how shared_irqs is used for regular SPIs.
> 
> Since the eSPI range starts at INTID 4096 and INTIDs between 1025
> and 4095 are reserved, helper macros are introduced to simplify the
> transformation of indices and to enable easier access to eSPI-specific
> resources. These changes prepare the VGIC for processing eSPIs as
> required by future functionality.
> 
> The initialization and deinitialization paths for vgic have been updated
> to allocate and free these resources appropriately. Additionally,
> updated handling of INTIDs greater than 1024, passed from the toolstack
> during domain creation, and verification logic ensures only valid SPI or
> eSPI INTIDs are used.
> 
> The existing SPI behavior remains unaffected when guests do not request
> eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
> option is disabled.
> 
> Signed-off-by: Leonid Komarianskyi 
> Reviewed-by: Oleksandr Tyshchenko 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:28:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111415.1460137 (Exim 4.92)
	(envelope-from )
	id 1uuQs1-0000FN-Ov; Fri, 05 Sep 2025 07:28:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111415.1460137; Fri, 05 Sep 2025 07:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuQs1-0000FG-L5; Fri, 05 Sep 2025 07:28:29 +0000
Received: by outflank-mailman (input) for mailman id 1111415;
 Fri, 05 Sep 2025 07:28:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuQs0-0000F6-J0
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:28:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuQrz-007pRr-2n;
 Fri, 05 Sep 2025 07:28:28 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuQrz-00GioC-2v;
 Fri, 05 Sep 2025 07:28:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=gIBPNaziA6biKrZeOx0UTR7gu3T1mb/qz3J6yftXYMs=; b=IfqPTFuJs6rjF9XRBi515RZvB5
	ReNVYBG3OT8ZncuayEB1PUL6+mTGE5tYneMaGpgFjOorS0oZs8hePvfEevJFfYC9qnoYzIXSO+5ia
	0FOFjVVkj/uqgHosq00u5V9/UY5IFNEKZLqVA4L0oqodgXOrQy0yJdBcGRBlMZFEPvuo=;
Message-ID: <66adb789-9fd5-4326-a25b-88093195dc05@xen.org>
Date: Fri, 5 Sep 2025 08:28:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 09/12] xen/arm: domain_build/dom0less-build: adjust
 domains config to support eSPIs
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 04/09/2025 21:01, Leonid Komarianskyi wrote:
> The Dom0 and DomUs logic for the dom0less configuration in create_dom0()
> and arch_create_domUs() should account for extended SPIs when supported
> by the hardware and enabled with CONFIG_GICV3_ESPI. These changes ensure
> proper calculation of the maximum number of SPIs and eSPIs available to
> Dom0 and DomUs in dom0less setups.
> 
> When eSPIs are supported by the hardware and CONFIG_GICV3_ESPI is enabled, the
> maximum number of eSPI interrupts is calculated using the ESPI_BASE_INTID
> offset (4096) and is limited to 1024, with 32 IRQs subtracted. To ensure
> compatibility with non-Dom0 domains, this adjustment is applied by the
> toolstack during domain creation, while for Dom0 or DomUs in Dom0, it is
> handled directly during VGIC initialization. If eSPIs are not supported, the
> calculation defaults to using the standard SPI range, with a maximum value of
> 992 interrupt lines, as it works currently.
> 
> Signed-off-by: Leonid Komarianskyi 
> Reviewed-by: Volodymyr Babchuk 
> Reviewed-by: Oleksandr Tyshchenko 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:34:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:34:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111426.1460147 (Exim 4.92)
	(envelope-from )
	id 1uuQxM-00022L-AO; Fri, 05 Sep 2025 07:34:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111426.1460147; Fri, 05 Sep 2025 07: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 1uuQxM-00022E-6s; Fri, 05 Sep 2025 07:34:00 +0000
Received: by outflank-mailman (input) for mailman id 1111426;
 Fri, 05 Sep 2025 07:33:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuQxK-000228-BP
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:33:58 +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 adf612b3-8a2a-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 09:33:56 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-b042ec947e4so250199566b.0
 for ; Fri, 05 Sep 2025 00:33:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aff0681aefdsm1750775766b.8.2025.09.05.00.33.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 00: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: adf612b3-8a2a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757057635; x=1757662435; 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=+IamgSgOSDZJJTJne4X2KDi6QWTao6/yjSD4czr+mSQ=;
        b=WXwCIVKOtw1pS6452CU3y+BnBm54L0SLqRJI/EeeMc1Aj2jqzyaR0tfz0YyJ92Qu3z
         nQkX/5s2FkIWUG8NskmOmd8pRTATBYdRU/VJ93EkEMiPhh7CsTG4dbNY52xk1nb/gIDy
         jb3tHiE4Jcb8OBgbpkbbilW/D06ruNG9so3kMkq4lJDx9miH7sJ0iS70zJo6cj7vRiYp
         pYaiXnsbnx+0AgVotfFVCHMk/kYUYK/IfUXuduhV6VmVLA1zjW1KcGxQZhf34YFU4fVC
         zWGOxkwEFK3LlgJAibKOa9TnC8YTsNeyWoJHhiYES+uRSM+Wo8VM8oBQeeVJh8BoXEqp
         Er8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757057635; x=1757662435;
        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=+IamgSgOSDZJJTJne4X2KDi6QWTao6/yjSD4czr+mSQ=;
        b=sVQDMHAvYfviAO1ChdUYamdpaWHd5n4HJ/OIUzoZya51lEJQ5/qakVTc+95oeTPufk
         UXmynS2f/AvBXPZYFazYmwXVVTH64LGI9u53A73Bxy+YZXlZ4M6lRnaSpZglPYiyn5a3
         Zr8gOKY+/x+I0yuHYyXlBmzsMQuMax5M33/v4ltmm2iIH9Qo3UiS92o4Mmu0njpKtAZ6
         p3yHWbjz5putblxbz/oUxRBBv8eABe+skjKSotPfKbPhx12H5EP3UkM0DbvQswskHubT
         XXnjRMAenaG2moHuIhHTod1UnJeZG71V2gZNV1pvRBVe/J0i9KwazUa/6KMX8i/tLSQ+
         ZWJg==
X-Gm-Message-State: AOJu0Yz+W0j+TGsn0siNJMXE75VITbjM/uZ/PgQszJfdYDeDa8m3EzRx
	v2bxVm0vkgccLGfkRw6wVdUw23OWrgpv6Kukg5xDTXFMhqp5lR2jVb9/WsifIf0XHA==
X-Gm-Gg: ASbGncvqj+nce4CCQ9N431JZJF5BwhqF/Kzhouy0pFa+pVRajTzKuaUab/dxH6QOsn9
	WaifvW4cOBGd8rjE9FONEc56e4wskHm7hfeFL5sfBZKON+KT8w7EYLL4ow6ptQrhRjxUshaEd23
	kJIunIPM0akFQVE+yE4KVF/QHTB249UV+YeFPCuer+hUMSpKc9QZ6LlTXI9tNcm6BDBIex0PMqQ
	G9rqPZdZ5EQPUNUcF8I/kQ1Y7vS0K0dpN017rs0+KNZhqRr1QXPHF9QG1oQC/2BEN1NPjkyrQ2W
	1+/ckvN1G9d+LmrgC+rklZDy3eB/hFL78U9V5jXvE7lfMHBB1sscoWS1Mh9TwAtIAX1iw2gyidp
	HQ/iexTHImk5bBheN2o1oOKCR3ptfGyK/qpzr+CwnxzsYMENhDWW5BITCLKZA11Tb095fr3LzN9
	CIhO7qMOY=
X-Google-Smtp-Source: AGHT+IFQdGlfdHAGjaBWeOBAVnpWXeV4l9niFxW8pqDzeDT/mynZFscW0Csf8HiKcTicLzvKXuXgxA==
X-Received: by 2002:a17:907:fdc1:b0:afe:b878:a175 with SMTP id a640c23a62f3a-b01d97a0c24mr2390793266b.46.1757057635482;
        Fri, 05 Sep 2025 00:33:55 -0700 (PDT)
Message-ID: <1161dc03-2ebe-479a-bf48-80efc3b9be03@suse.com>
Date: Fri, 5 Sep 2025 09:33:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Differentiating "For experts only" and "Not security supported"
 in Kconfig
To: Demi Marie Obenour 
References: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
Content-Language: en-US
Cc: Xen developer discussion 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.09.2025 05:47, Demi Marie Obenour wrote:
> Right now, both EXPERT and UNSUPPORTED options are
> not security supported.  However, this seems to be
> causing problems for safety-certified use-cases.
> 
> Specifically, disabling AMD or Intel support is certainly
> something that should fall under EXPERT IMO, as it is a
> great way to produce a Xen binary that will not boot on
> a large fraction of hardware.  However, I see no fundamental
> reason it should not be security supported.  Not security
> supporting it means that those producing safety-certified
> builds of Xen (which, presumably, are some of the most
> security-critical there are!) are having to use
> security-unsupported configurations.
> 
> This definitely does not seem right to me.  Safety
> certification and security support should go hand in hand,
> not conflict with each other!  Is there a plan to address this?

Something that isn't security supported upstream still can be security
supported by a downstream. For upstream, we simply need to somehow
limit scope. Any extension of scope will need to come with respective
justification. Yet if done so, I wouldn't see a reason why we shouldn't
at least properly consider such a proposal.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:38:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:38:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111436.1460157 (Exim 4.92)
	(envelope-from )
	id 1uuR21-0002c9-QS; Fri, 05 Sep 2025 07:38:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111436.1460157; Fri, 05 Sep 2025 07:38: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 1uuR21-0002c2-Ns; Fri, 05 Sep 2025 07:38:49 +0000
Received: by outflank-mailman (input) for mailman id 1111436;
 Fri, 05 Sep 2025 07:38:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuR1z-0002bw-KL
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:38:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuR1y-007pfU-2r;
 Fri, 05 Sep 2025 07:38:47 +0000
Received: from [2a02:8012:3a1:0:2cb0:b4e5:ef93:763c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuR1y-00GjJM-2x;
 Fri, 05 Sep 2025 07: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=AINSE6YAmpQQJZ9jrU/yj8i6gWbwwbn5QxhDricQllY=; b=j9SPoNmM1FYOmrnkEIgZjP3TjU
	qIXugV1enDG34QMXaOtVBROGLDv4ESUT1FpS83Su1hJCM7kPc+EJnc3UEb1wOC/ASS8fkWTpSNTow
	vOR6B+fZtcCjXhKlufr82ixD/rfvUuJn0i/6fiHHduINneiv94gE4yotWSODtqAN92O0=;
Message-ID: <25532b75-eb66-4cba-9a8b-6e71c16e607f@xen.org>
Date: Fri, 5 Sep 2025 08:38:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Leonid,

On 04/09/2025 21:01, Leonid Komarianskyi wrote:
> Implemented support for GICv3.1 extended SPI registers for vGICv3,
> allowing the emulation of eSPI-specific behavior for guest domains.
> The implementation includes read and write emulation for eSPI-related
> registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
> following a similar approach to the handling of regular SPIs.
> 
> The eSPI registers, previously located in reserved address ranges,
> are now adjusted to support MMIO read and write operations correctly
> when CONFIG_GICV3_ESPI is enabled.
> 
> The availability of eSPIs and the number of emulated extended SPIs
> for guest domains is reported by setting the appropriate bits in the
> GICD_TYPER register, based on the number of eSPIs requested by the
> domain and supported by the hardware. In cases where the configuration
> option is disabled, the hardware does not support eSPIs, or the domain
> does not request such interrupts, the functionality remains unchanged.
> 
> Signed-off-by: Leonid Komarianskyi 
> Reviewed-by: Oleksandr Tyshchenko 

This patch looks definitely better. Thanks for the rework!

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 07:39:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 07:39:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111445.1460166 (Exim 4.92)
	(envelope-from )
	id 1uuR2q-00036c-28; Fri, 05 Sep 2025 07:39:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111445.1460166; Fri, 05 Sep 2025 07:39: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 1uuR2p-00036V-Vq; Fri, 05 Sep 2025 07:39:39 +0000
Received: by outflank-mailman (input) for mailman id 1111445;
 Fri, 05 Sep 2025 07:39: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 1uuR2o-00036C-Sy
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 07:39:38 +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 7916f9c8-8a2b-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 09:39:37 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-b0418f6fc27so285613966b.3
 for ; Fri, 05 Sep 2025 00:39:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aff15fccad1sm1599532166b.108.2025.09.05.00.39.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 00: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: 7916f9c8-8a2b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757057976; x=1757662776; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bxBl2+ipg4oH2IDTr8qT5pfOuU6yISDJu4FyOB9afXU=;
        b=fG3BcqRJMFhdWFEFFEoFzadPD8w3G7WCvnkbsJszzQtuuzRSlWif7iqh6FxJ+k2OVA
         r8OldJXGTZGXtYdhGOAiIvHptCx1Ulr47DSqU1bWj6r6ySkcY2ZvGbG3jDXwSLZbTeAL
         hCW3kszq6KO8PHq2WoPqerFb8p3Qg/bvLROQDU6AiEkzm1gz0id0Cy2Auq6HDLVR5uKR
         th2syas34aDay6flEXsiBH0HEceIPRAFYPUZ25j9w2GZXsnKzuMzKMv8icUFF1oRn0Ij
         OQUs8hYWRAk5r3mqPBuvZ6hi66LF/C0aNA8w1BvYUvqds4OkvYZp+Na2AOoWx7Rq17kc
         htCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757057976; x=1757662776;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bxBl2+ipg4oH2IDTr8qT5pfOuU6yISDJu4FyOB9afXU=;
        b=ttXYMRyBabQjYjO5mGyLIaAMhXUiD01F9rQhZc7maGxVgpU2Kp7BW1vC7UAxJGw5ll
         WAxYLDYNafydX8rECdA0N16kfPPlfzu52b4rwSraWHKWRav7cyXNi6Pp9Q+DBN3Vkxno
         fVy2gMjDED1tZG/YPybnLKN7FewlSarkXOQd4SNA+MNHrvsiYENhho5LzBQr4MI7hdSv
         93SSytkNzWK3+ojGsiFjubb1puJ+TY53Iyb0x/IwLOo+sPH2OoJpUzlPfVcuKLqWfxRJ
         htvmJyITpo33PO23QD9OBd0GMHPvwV1MM93DXdHA84ZttHcIujnakZbFKS7VmUMttpqk
         Wkpw==
X-Forwarded-Encrypted: i=1; AJvYcCU1UKwRKWGd4bPr+TMootTAJ5anDPpr2cFQGMV8LMrJeM0yVFiCiXe3RaAfpJv6cjzkx84co+NDvTQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSplUvA+ZFha/IruLcN2W/3tbwFMh7lN5uFPMpXr9pNcpSLcfY
	LOcw79UsxPDzwvSQZ6umCGhjJL56/tmYnTZzSoq2VLm0XfU+v3rQerUXe4Yg5dVlDQ==
X-Gm-Gg: ASbGncvUTDmEyWl/2pxROGUUw0dK39B9qChckEo4aA1X8poeTb/vcvabi0PR9Xy431s
	hqe1uWFWwgUIIrYGq8eAJQYWyOMpK5V9mrjW1FZT1AHm9aipcTBUYXZTWDLkBT7vIDlvg1zR3Cd
	e2Vxv0E+xDWp5P7TJWIXKFI/EJsanUaI6pBxISKTPHx2NomTqlpO9CiZVn5OwJiLpmjSh5ScKPN
	7xwCPCqV44GLpci0HMDWBWqsMKdGKg7LxwntNlvxId1BCpsau7Vs8H0AjfNbdHq/embboxD3cgE
	bBAqp3ip8ICfA9ep5Vsp2W7yfPqLBIn55bOAF5pQSVzeN9J0ox0cmHo4xoXsbKnyK/UGmSGsXzS
	1TPsIo9voVd6csLf/KoiP9H3czLukmBc8Tl/UjcVLSlFogMeuJeeJWb6FNV1iAiWy+6MeQ7d96H
	3SbYk5JOJ/aAjIqp9iKQ==
X-Google-Smtp-Source: AGHT+IHzooTQPQZReUjjuhvLyKkqPUEUG27QiHszwkIqz3kc0qVgX5iNh7WmeM93i8N/6xFJncdUYA==
X-Received: by 2002:a17:907:7f89:b0:afe:d62a:f053 with SMTP id a640c23a62f3a-b01d8a322c4mr2213506966b.10.1757057976376;
        Fri, 05 Sep 2025 00:39:36 -0700 (PDT)
Message-ID: <57fedb53-18b7-4d81-acc8-2756a899ef90@suse.com>
Date: Fri, 5 Sep 2025 09:39:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/apic: Avoid infinite loop in
 io_apic_level_ack_pending()
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250904215137.135529-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: <20250904215137.135529-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 23:51, Jason Andryuk wrote:
> io_apic_level_ack_pending() will end up in an infinite loop if
> entry->pin == -1.  entry does not change, so it will keep reading -1.
> 
> Switched to breaking out of the loop.
> 
> Fixes: f821102450a1 ("x86: IRQ Migration logic enhancement.")
> Signed-off-by: Jason Andryuk 
> ---
> Noticed during code inspection.

Well spotted, just that ...

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1715,7 +1715,7 @@ static bool io_apic_level_ack_pending(unsigned int irq)
>  
>          pin = entry->pin;
>          if (pin == -1)
> -            continue;
> +            break;

... we shouldn't terminate the loop here, but rather continue with the next
entry in the list (if any). Hence presumably why "continue" was used, without
achieving the intended effect.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 08:15:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 08:15:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111492.1460177 (Exim 4.92)
	(envelope-from )
	id 1uuRbK-0000tY-1Q; Fri, 05 Sep 2025 08:15:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111492.1460177; Fri, 05 Sep 2025 08:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuRbJ-0000tR-Uj; Fri, 05 Sep 2025 08:15:17 +0000
Received: by outflank-mailman (input) for mailman id 1111492;
 Fri, 05 Sep 2025 08:15:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuRbI-0000tL-KH
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 08:15:16 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73b74268-8a30-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 10:15:15 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-61cebce2f78so1375738a12.1
 for ; Fri, 05 Sep 2025 01:15:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-61cfc1c7dfesm16150230a12.7.2025.09.05.01.15.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 01:15: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: 73b74268-8a30-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757060115; x=1757664915; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2VsriFXGsBt9nqoCLaquLayjIb1I6ZvvllaP7w5kKmY=;
        b=dFlJUSZ4a9FN/p6jYaVskzVbuS9W+s1LoS8SY0rVoc16KpXCo9SqPoyIGp0/wZ6tIs
         FKIwdptu/ygMVxhzCyh3iK2l2Y/FcLyrjvOx6lKO+2+IJ3QbNpCVKftnPLen7fw1EwGn
         W4Z5Hk7MTEZ5Tet3it9yeC7ZlMlnGc+XAyqv4QTA143gP5F4bVcOSiQEMMdLPa5z76AT
         JjzKbrqgG9kXHeSmUAOfP6gQQksmAbimZn4s6tgZKoWdtDBtedoQp+SOA/L4ORTYG9R9
         NQm1O8VdnAAjy7nzZEufcV7Ol/qksYVLGplbLq+yrPXk1aeH/IM61qaRabLUdtfDiklj
         9vFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757060115; x=1757664915;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2VsriFXGsBt9nqoCLaquLayjIb1I6ZvvllaP7w5kKmY=;
        b=UxD+K/Gf1LzTyFbH25IuayqFQDNn1kn/DWn3sc0aWVCGW2nT+u4dATO/3GuiSVdaDA
         L60v9DQGN7ptE54Y1qiyq/t4141RtjfOJWLYuaaJ1NEjlbSJCl/ITbPEhFSXWvh0S6XR
         AwWUZse+rEvAtIvKW4HVPiQa80Z8jq0G/07zxXXPLy0WRzzt2ZkxSbSymo1O21fkJBZd
         qAY8dvFqtDZ3ZSmpd1pv9gvNkI8gUm+ezmH9IhQjfKu0PddgHn5J45dSJ20OzPaet6VI
         eGuU2flFb7Lkl9aVrTgf0X0EINJckoNkAQj4CNCpSl1sjHTfEFoxIhK5nalavAZfAXhx
         2Icg==
X-Forwarded-Encrypted: i=1; AJvYcCUgoGC9tihX84LyCqFjsw9XNOxqmeRmN276r1Z/a9DhbXO83w+t0kEZa78+qHlPBe103eZy/hoLaf0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxTsY3AI5UbjHGPNPs7AXncTnH9fro4YkRhSOCfBLR7D/sULT59
	/FQ0MVGmUJguRl521gK2ABZ8KAirDu0JxT2Z9Xih8a/msvF1bMrTVexRt509S/5e4Q==
X-Gm-Gg: ASbGncvlBjwNJW8ROzgZRCtorRnWEhz6uMGngyWEdjly5MR92hTMRIZc2fRcT3LaVmr
	jeUQqS0QgY4QbqtEXnwaeSvvO1PkZgqigtd3wx/CKWymkCXzSQNZQqjyFrJr+SEamzdsHIiRNZH
	O+27e6WG4AvHaEuEy6KKnG9hambl4aODYylPHK73ko7Zl0Pc8EwYWx0YAkOuDnmZyFpGyMj8PLf
	u+OXf/HH/EPqnY5rqH4mYBe9EqVjXSlClHHJtUSs5EPHDsJ1sYB6GdGZRc/bNfJ+54RYSMUJcPf
	rrSVmNj1cUHXSRO8hOPHHbc1tXVmi6B7L9ouZOxNpmIk2wflS49LD1F/ObsuCgM2MDqJpD+00n5
	tOsjtYJr+NcXQcJTCUs6FgsO1E0gGWc93qm398yHnYRKpHH79Fn6tDqjRLRstkH+wdHlISFIvrY
	1/JxCyn/+EVulwiUfQ7Q==
X-Google-Smtp-Source: AGHT+IHlyKTzV4EUsZfsWyXI7udscmyHy3ubo4wwqYDCMt5o9V1aM2EVFuwCR+GKUQsEgiKh/NkTpw==
X-Received: by 2002:a05:6402:2115:b0:61c:5b95:c8b2 with SMTP id 4fb4d7f45d1cf-61d26d8503fmr20631034a12.22.1757060114770;
        Fri, 05 Sep 2025 01:15:14 -0700 (PDT)
Message-ID: 
Date: Fri, 5 Sep 2025 10:15:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250904114202.2722478-1-marmarek@invisiblethingslab.com>
 <488408be-4728-4666-89a5-ac5b438bdbf5@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.09.2025 16:27, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 04, 2025 at 02:58:20PM +0200, Jan Beulich wrote:
>> On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote:
>>> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
>>> available in earlier toolchain versions. But use it together with
>>> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
>>> still contains some paths in out-of-tree builds.
>>
>> I consider it wrong not to use -ffile-prefix-map when available. That
>> already covers more than "debug" and "macro", and it may gain further
>> functionality.
> 
> I asked about that on v1 and got ambiguous answer suggesting the opposite:
> https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#m74a8883835e30fb74a85b07a7b14507ee52e7c65

Ambiguous answer(s)? There's no reply to that mail of yours, and I don't
see how the conclusion drawn fits my earlier comment. That was more
towards what I did in v1 of my patch - fall back to the more widely
supported option when the less widely available one can't be used.

>>> --- a/tools/Makefile
>>> +++ b/tools/Makefile
>>> @@ -1,4 +1,4 @@
>>> -XEN_ROOT = $(CURDIR)/..
>>> +XEN_ROOT = $(realpath $(CURDIR)/..)
>>>  
>>>  export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
>>>  
>>> diff --git a/tools/Rules.mk b/tools/Rules.mk
>>> index 725c3c32e9a2..428fce094819 100644
>>> --- a/tools/Rules.mk
>>> +++ b/tools/Rules.mk
>>> @@ -166,6 +166,8 @@ endif
>>>  CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
>>>  CFLAGS += $(CFLAGS-y)
>>>  
>>> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.)
>>
>> Here and below - no need to use cc-option-add for -fdebug-prefix-map,
>> which all permissible compilers support.
> 
> Ok.
> 
>> Further, again as per reply to Andrew on the thread hanging off of my
>> patch - I don't view it as desirable to leave the tools/ prefix in
>> place, or e.g. for libraries, the entire tools/libs// part.
>> Imo every binary should have only the path (if any) from its own source
>> root left. (And yes, how to deal with e.g. shared include files isn't
>> quite clear to me, yet. Maybe we actually need to pass two options.)
> 
> I don't think it's valid to strip arbitrary prefixes from debug symbols,
> especially in tools. This will break some automated tools that try to match
> coredumps (and similar) to source code and sometimes even debug symbols
> too. But even for manual usage, having to jump between directories (I'm
> not sure if gdb supports multiple source dirs at once?)

Pretty necessarily: When debugging you might easily cross project boundaries.

> just because you
> happen to debug a binary that use more of libraries isn't exactly
> desirable.
> I think the paths in debug symbols and similar should match the layout
> in the source repository, not a subset of it.

Well, okay, we disagree here. To me, xen.git really is an agglomeration of
too many things in a single repo. If things were properly split, you'd end
up with what I'm asking for anyway.

> Theoretically this doesn't apply to the hypervisor yet, as I'm not aware
> of any tool processing xen memory dumps automatically (and those for
> manual usage are quite unstable, to say the least...). But I don't think
> it's an excuse to have incomplete paths in there, just to save few
> bytes?
> The only case where I can see it would make some sense is out of tree
> build, where indeed it's about just the hypervisor, not the toolstack
> (IMO due to the build system limitation, but well...). But at the same
> time, having different path variant depending on it-tree/out-of-tree
> build feels weird.

Which is why I'm arguing for the dropping of the xen/ prefixes, as that's
how things come out in in-tree builds.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 09:34:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 09:34:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111532.1460195 (Exim 4.92)
	(envelope-from )
	id 1uuSqA-00021o-Hl; Fri, 05 Sep 2025 09:34:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111532.1460195; Fri, 05 Sep 2025 09:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuSqA-00021h-F6; Fri, 05 Sep 2025 09:34:42 +0000
Received: by outflank-mailman (input) for mailman id 1111532;
 Fri, 05 Sep 2025 09:34:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuSq8-00021Y-Il
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 09:34:40 +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 85a4d901-8a3b-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 11:34:30 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU2PR03MB8123.eurprd03.prod.outlook.com (2603:10a6:10:2f2::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Fri, 5 Sep
 2025 09:34:27 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9073.026; Fri, 5 Sep 2025
 09:34: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: 85a4d901-8a3b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pwoadAddVtSlf5TRRWUUiO4LEr2C0DUluhdHx0Z6S8OWkQ5Fljsu6q2YX7iXZoDWAaM37W4TeKoJvLVj2YZdd4/Tg7wyAnZsZQGgqlTiyOpPCzR6XtruRr8rlKWMSM1v7soUfvqAToqVYi1hqN31WxWTo66SG75NJ38zeoaxeivFWb1KqfWqtCDZfLzXBycGZ5pSqokgncyInU3muu0AtCMoCBi7kv71OeJtkaVhejp3M6aTGFKv8/9D6Rj9Ka5qaj0QrHDgFIB9BemMzyHF9WGb95Gopmkyl8XARJpBk8AlCTUgEDyS6TVIUqYxTCeloZRe3zfSOs7XkEFB7ismFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=R0vdsizoTTNdQW4TPL8DV4kDDbBU8+G0QEf8xk3DF7M=;
 b=V/Yd1nKmKwJyYpDnW3dxxDcP9fzwwezCv9caosOKFF9NMOK5q8qIWZqy5r9QeZ8il0WRuQQqscVCQFf0hP7FmpkVrBJ04gu0qUCUZCUIMIH/v1ZCjfD4kKsYy9O+KHwcHAPSbna44piFYdgHOlxnnKUgex6/c3NvJM8a6ELvtdcUI8JJt9RmsroK0QrsqilXEtWAF9HhMc2D7w8p2k0aUR4ZF4y2O+GAHqIGAxH5wkXLTliifN3fY9UY/R/93MjotoQO5WVUjxH2sSexivNzKlO2gtXoO8SG6Ag5QScR3hvIdcb6QDAqOp2fSwUVhMAlqZ0HGW/pBOtJb4tQvGjLNg==
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=R0vdsizoTTNdQW4TPL8DV4kDDbBU8+G0QEf8xk3DF7M=;
 b=RpR9rathARpIO1ekOQx3hoKB+fgwP/kxy5T2iahMPw8rdCJrp1pXCJMTFnvQCFEz0vHMRapJh3rS0O7KbXKfv/I/0H+T9R1ryJHXS+LfZkiod8qapdinsKA0hTiazeaYcnCDtXtgwPLLbyVjVQUoFngwaMFexnHS57eHVclz/ZUqiIWhb216+CTQR238nMvkU90NLYHO8u2X0o1vNxot8Qdf0j+QBVEmbW84ZAEQS2t5Ga9yJeYUjt/zhC42/Sp/6VqnUyJGeP0QgHU3Gdo/1I12Tm64PH2wV/J0wrvARHL9Fqo4Ow8uMFIg7XEHaJCPCmMtqi+3CRxgLVj4j1vRSA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <974cdd98-01cd-4df8-ab72-367fe5ec7514@epam.com>
Date: Fri, 5 Sep 2025 12:34:25 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
To: Julien Grall ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
 <9e69e282-ea6b-4d4d-ae3c-27c4d3b7ccf4@xen.org>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <9e69e282-ea6b-4d4d-ae3c-27c4d3b7ccf4@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0173.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b7::16) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DU2PR03MB8123:EE_
X-MS-Office365-Filtering-Correlation-Id: a1cf0304-1bd0-4e2f-dd28-08ddec5f67d3
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?VzhFZ3FReGRpUzM0YmN0M0dTUE9XUVJ5VG1JSGdZSGt6Y1U4NmZYRG1ZaUps?=
 =?utf-8?B?MUJyUU1GVUpFMjVQUllkWXB6QzNBbkd2ZnNVNHJaM2FXdDdLR1Z0ODc4Y2xI?=
 =?utf-8?B?YUxBN2h0enhwQnhXdENWUHVoMkRVUnEzSW10NWZpbm9Td3lLNkc0V2VBNE5X?=
 =?utf-8?B?cHhUQ29xVHhSOVpKWExJc3RLWWZGVkFCTEZLRm5nZ0NXbHhKNmlvMTZEeEF3?=
 =?utf-8?B?MEcwc0wwdCt3QmxmeGdKc0ZrL3FZZzNJYUZNNFRiWWxnUzZacHRYckU2eW5U?=
 =?utf-8?B?NGhFVHRMcjFCcmZDbzRxVHcvNitISm1xQm1WZFZrVzNyKzRVTUNkckI1OTZ5?=
 =?utf-8?B?TjN0V1EvbWREMElqYmFjWFZUMXRuRy9KMUtuODN2Y2MraHZucEZvZitUUTJX?=
 =?utf-8?B?U1Y2WTB6REpnT1g1MmFGSk1FMmlBdU01Y0xlRWRBVkEvSnU5ZDA2ekd1bXY2?=
 =?utf-8?B?RjB2UXRuM1RmcjVwbG1CUUdWR0hDbVVoWEw1dGU5K3diVU1MYWZ0clVxUHkv?=
 =?utf-8?B?cVN1eU9ERy9SNVptNW52dHVKd3VZbXJ3QjhUbEpBK2l3NUFOT3MvNkdvSUg0?=
 =?utf-8?B?S0xDajBQTjBpVW5zYkgzRnM1MGRSWDluWnRqbDJLM2ZIVTlaOGh0aFBmUVJh?=
 =?utf-8?B?RXZvNDZqTU9zaVlzOTUrN3gydVBUWDQvRi9VWUxNZ3V0bnBvUm40bHluSnNJ?=
 =?utf-8?B?K3J4TmxQazREK3VLdTdtdFUxRTlDQ3JxWk1MY1dPZGdGb25YNUhGU3JQUHN6?=
 =?utf-8?B?OVBkdTE5UkVMajg5K0FvdEQrc083MFFITlFScW1SWmN3c1oyY2p6WkhOdHo1?=
 =?utf-8?B?VGN1cGdIRjE4S21DMTRGSjhvNS9mZU04bWFnNVYzT3Rrd3RwTVRVYTY0VHow?=
 =?utf-8?B?UDB0bTRqQTBnbEdlbFdORjBodnBDZkRRSTV2aUp0a0Rsek9kdmxsM2N6UC8r?=
 =?utf-8?B?cW1BMmc5dDh4MU9VSUxzUXY1SEsydkg4SUxZbk45N0FVWWhGWGp1VmVNWXFX?=
 =?utf-8?B?VStCMU0rOGZoaTY1Q2lvUHNFZFYwcjZ2K000QVZHQUZBWlpWNzZOUGxsQWtE?=
 =?utf-8?B?ZldqbmpWanB6Y3JtOTF0SFFNb1JEMTNiWE43V05GU1V6ZEx6OTFSa3NWdjh6?=
 =?utf-8?B?REFEOWhSMzFKMXA3di9qQ0tWRWdlY3FMMzcrRW1lZzAwUWtacndrbGZIaVYy?=
 =?utf-8?B?WjgzaFJqOEEvZ05iVUt1OUtEVVRwSWFIRVpMWlo3RHNpNFJiOXl6UzVSNHlw?=
 =?utf-8?B?clNZOG9Bc1JKZUc5cERicHJLWGVVdkozVnVQejVVN0hnUk9CM3FHQktPUUtF?=
 =?utf-8?B?ZjBQbEpNT3k3c2ZUZks5MEhkOE4rV2M0OXl1cXBja2IxZHFGblY5UWZqSkZS?=
 =?utf-8?B?L0tPWVpCYWRGVWxjTU1wS0UveXBtSXlKTE1QeFZqWkUwcnJxSHBVNVh4b2Y4?=
 =?utf-8?B?Y1gwMHg3RDZaWTh5NlA2TFRmSTJwWEhIQXozNGRvRFk2cCsrbGZiKzgrZTBU?=
 =?utf-8?B?NWRrY3NaNFhvbjh5dzV6N2ZJQkwxS3NUUUJaUmt1bnMwNGhTL1ZtcDlSd0tH?=
 =?utf-8?B?VHN5aERaQVhjR0QxaklrYmNyb21rbzdSSVprc1cvTmxQNm52K1hIaHJPYUts?=
 =?utf-8?B?UnBURjQra3c3M09GQnJEOU1BQXY5aDQvZXlJQkY1cjZma0JzK1YvLzBSOGNl?=
 =?utf-8?B?aDU5dTZFV1RXM0ZKUXRna2lpdlNjUVFpNkl5Yi9iK0duZUtxWlk0eWxTbmxY?=
 =?utf-8?B?ZS9ka1RSOHJ4a1RuYi90TE9CdmpmNkZWRzA3NlU4enlPazNFQ0NLNWxTYlov?=
 =?utf-8?B?WkVxREpScGRXK0h6U093TXR0Mk42Y2hjSGhlZHFwUnJzYjJLbUswMHJtakRi?=
 =?utf-8?B?cGoydHZZeEprSlZmR3NPbmhDWHR1bGZMa3EycjhmR0xOL3FBV3d3NXgrUmov?=
 =?utf-8?Q?lbhXrV0EQqU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SFprRkJKRmRTQUdTTE8vdURyclZyUXNJc0tsbDZRTEZmVmxycUJQaWpUMVZr?=
 =?utf-8?B?cWJvL2J4OEp1ZkxkL0syazlGYlZ2REdyR0dHRzdqbnJiV2Fsb2hac3A2UHFy?=
 =?utf-8?B?N29qd000aXpvT1JiTHVmTVJjWERvRFlrRytBcnF0MnhtU1dSRTJENzdtb25w?=
 =?utf-8?B?SWYvbDRnVFhjdFQ5cUVhektaOHhHdGxCYUhxdDJweXFOcWdTdTZaS0dBY1Fn?=
 =?utf-8?B?TXpXSTUzZUhNKzhBa012dDhCTUhNbkRlVlRIcUpxQkFEOXNoUmdrU0I2cHBI?=
 =?utf-8?B?dnl6RGdvOERpWXpZa2RRd1N1S3Y2NmFsRVJNQkpoZnJtN293N2J2RTRHa1I0?=
 =?utf-8?B?bkNUVG42WGRkOUI4QXJZUEM3YTMxUjlTMWkvL1o5S2x4dmRSYlkzMXRDRTFV?=
 =?utf-8?B?WitIemhmVTJ4bm45aXNUOVJUUVNHZmN2MTBJc0J1a1BsUkl0MXlVNG1laTZZ?=
 =?utf-8?B?bzg2WjRKTnlmSXNEbDVCeHBsbEdpd2dyU2RBNzNFLy9vYUg5akhmdUlpd3JP?=
 =?utf-8?B?aUROL1RLM09ncm1xL0UyV3AyTHRsbnVNSlNaenVLSFpzZ1FvOG5YK1RYY29u?=
 =?utf-8?B?d3pXYUllckpCd2hGZjZMbGxFMVRGdU01cmc1VFRQUk9lVUQrejdhakxZYVp6?=
 =?utf-8?B?M1FQWWU4V0RLc0NxUVVTOWpMWDdyR1Z5bVovcitOZGorUGp2R1VqenhhUVpH?=
 =?utf-8?B?MXViQnVVRkpaQ0h1VzM2aG93bS9aRHk4U0Z0Vy9sRnRCTXVCYWdwQUJoWitD?=
 =?utf-8?B?bmVSY1A3aUNTbDRPdXgwc2FHTmlsWG9QSWVPY29uY3lFVlpWYm1OZE5SWHdq?=
 =?utf-8?B?WUxIY2NoZHhjb1dLMTdJUHFDUlQrb1JhVy84cXllNWZCaHF5azdVUmE0clpo?=
 =?utf-8?B?ay9EaFNPblZ3Q3pkRElnMFgrZ3ZZa2djbFBGMTc0eSthYlJvT0Q3cnRhQUxB?=
 =?utf-8?B?NVdLRUFkYTllMWt5WXdPRW50MVNkQ2d6Y3ZqTzV1UGx5RlkybmRlcWIyTUly?=
 =?utf-8?B?ci8ybDcvTE4xQVdQK1RiRGtGcEdjNnZweHBPUXN1L25ONS9pWDgzZ0xLOHpm?=
 =?utf-8?B?V1JYZGlJV0J1R0htSks0ekgxWnl5dmtrZDd0WFo3VTZYTXZ6eUpUT1AvYlN2?=
 =?utf-8?B?c2F6bS9pWVFOVWFENExoNE9ZK2xvYU4xTittWUNnN0hjMWs1Tng4YVhoNitG?=
 =?utf-8?B?Mm55WkRkd3pxQjhoR1FKTW9GTHNHWUhWTDFqQXpsM3pvUWU3Qmg5WXoweXF3?=
 =?utf-8?B?NjBVWDNpcUFKZDhNSHhYQXp6K1VGK1k0MUdkRkYwRkxxcTJTYXB3VmFoMUxI?=
 =?utf-8?B?YzN0VVAxOU5YRnpTOXYxUnRua1FWeXBmT2ZMS3BhL0x4VGtwcnBBSU8rRXFz?=
 =?utf-8?B?clJ6b010V3d0Y3hmWHMwU05KM3Z5aXBSQVRxc1VHd1hmT1JqNTJneTZYeTNw?=
 =?utf-8?B?UVAwVkx5OGgzeWR3OW5Bb0N0eWdyc0hVNEF0ZVZKaXZycjBSbVIvd0dLTUNq?=
 =?utf-8?B?VUZVZWdKZngyZjhoS09hNytHTmhTWHd1YVdyOVJ6aXp4R3YzWXRITFNKVlgw?=
 =?utf-8?B?aktiUnFFQXhlYmVrY2dwc29WWTJra0ZiRVVFRmxFOTlsTGJLZm91UmdzeE1J?=
 =?utf-8?B?cVZwMk9FU1EwZmdkT0xEa3hubDFQUDBjYXFxUnFUcmNFOWgycnFOeG1hK0JR?=
 =?utf-8?B?MGJWWWExd3NFUnVETUNydUU0eFZjWmRzeFFTTzBxdWJteWIrRVFKdnRZenhF?=
 =?utf-8?B?YkNwR3hNUE9PS3hGK0J3ME9lZVRCSmxZSy9JeXFtK2toMXVhL2g1a2ZWSkNZ?=
 =?utf-8?B?d1QvS04wKzJJYVduaTJQU01LKzJmWHpEWmJRL3FFM1ExNjRheDVLQlRXaWRC?=
 =?utf-8?B?amhiU0pWUklWckp3d1QwcmNnNUZMRkxRUzVrZ2k0L0VISzRzd3NoVjYrSHlU?=
 =?utf-8?B?RUtrKzluU05OdE5xQ0FLenRyaXg5dnFydUFNNjVwR3RkcGVYRFJMaEZYWXdR?=
 =?utf-8?B?eUxUUzFkN28xOE9ESnBDNGtiZWZWQzJsT1lkUzhrejZYSExIU2xlVVRpa2Nl?=
 =?utf-8?B?c3Y3U2RGblJQa1N2NWZYeE1XUkYveW1sL0FVeWpYS2xnckF6NTRPK3l6SlZT?=
 =?utf-8?B?WWtnZjU0VW5tdjdJS0NtMGlBR2swTElHZ08yOWdIdEMzWkVpV01Tb1pSWGw2?=
 =?utf-8?B?MUE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a1cf0304-1bd0-4e2f-dd28-08ddec5f67d3
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 09:34:26.6123
 (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: 3VafR+10kLl5Mg21HpUgEpyqm3xw6sU2TXgjUMNULeKQ/r1H6kELnsyL6rI/87uXycSAPf48n8L7efNO8I97IsC8N6WZQavhefOTXMESGbY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB8123

Hi Julien,

On 05.09.25 10:04, Julien Grall wrote:
> Hi Grygorii,
> 
> On 06/08/2025 10:49, Grygorii Strashko wrote:
>> From: Grygorii Strashko 
>>
>> Now Arm64 AArch32 guest support is always enabled and built-in while not
>> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
> 
> typo s/exmaple/example/

ok

> 
>> support might not be needed (Arm64 AArch32 is used quite rarely in embedded
>> systems). 
> 
> 
>> More over, when focusing on safety certification, AArch32 related
>> code in Xen leaves a gap in terms of coverage that cannot really be
>> justified in words. This leaves two options: either support it (lots of
>> additional testing, requirements and documents would be needed) or compile
>> it out.
> 
> To clarify my understanding, what you are removing is support for 32-bit EL1. But 32-bit EL0 will still be supported. Is that correct?

Yes. The 32-bit EL0 is still supported
(and was tested by creating domain with AArch64 kernel and AArch32 EL0 rootfs).

I will update Kconfig description.

> 
> [...]
> 
>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>    AArch32 is disabled.
> 
> A guest is not allowed to switch bitness. So I am not sure why we need to hide EL1.

I can drop code chunk which changes ID_AA64PFR0_EL1. Right?

> Depending on the answer above, you might need to hide EL0 and have more code (TBC) to prevent 32-bit EL0 running.

EL0 is supported.

Thank you for you comments.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 09:35:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 09:35:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111542.1460205 (Exim 4.92)
	(envelope-from )
	id 1uuSqx-0002Ud-RE; Fri, 05 Sep 2025 09:35:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111542.1460205; Fri, 05 Sep 2025 09:35: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 1uuSqx-0002UW-Nw; Fri, 05 Sep 2025 09:35:31 +0000
Received: by outflank-mailman (input) for mailman id 1111542;
 Fri, 05 Sep 2025 09:35: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 1uuSqw-0002NE-GT
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 09:35:30 +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 a920ec9c-8a3b-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 11:35:29 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU2PR03MB8123.eurprd03.prod.outlook.com (2603:10a6:10:2f2::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Fri, 5 Sep
 2025 09:35:27 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9073.026; Fri, 5 Sep 2025
 09:35: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: a920ec9c-8a3b-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lo+xccx5SHSwszIPHuMjAG8N6M1VkDwGXCgxoRBksTXGm0fPmCq5Zksgm9cQ9eeEoraHxQZrtgZdvfAM675lhXowFPBHM4pha0IIfKVDvhwpqeu1pJoAtOcO0I9l8yCUYNcE3fv2CrwhKjfcm49EA14lSbetHj6BxxgbnrQBbCqp2JLS9limFd/9COUINS0tlxcdmrPscK+i6+7TRVVJbskSnWyOI9mex9HV8HTkhfL7sDj2wShmmK3TpprdP6Yp3owzGtxjqspebAFELWuRQ5yWeUvrYLxBAFJ1W0vddF3gscIsILlJz27rpdAjdA93RigGxz2PeIhwsWXsIPmiQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wmw7ki22RAI6GES44O1JMEk0m1T8j6pS5BRQwp8PvbU=;
 b=b9MyZ3+qZyK79/2s1GlTpfr8tCu5V0AfJbB+9Dm7axOO+saTvWqiZqPhzRZ7PB0csFAJHXbciX9FXkiiDZiWKFQ7x9sM9d3oztZDzShQll/pY2yRwRQol/RxwJ/f7RNotwMPaJ7fb9iEWzYS1yEuXJMQUv34qBH8KHkzGR2UgcRixfrZeGg8cRwatnVGPrpc2Z5sEW9585wIkGOcqve71GOFszBV7ONXCwxTkZJB9h9Tg04mThBYSpN+ygbkh2kZKJvWZMIUdlehkgbCeSHG24Yhg0vzIfnjcXv68AUaI5rSMbpz/PveNJ1UqZCev5T4c0ws6pCxS/eVoKNW0ZSfqw==
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=wmw7ki22RAI6GES44O1JMEk0m1T8j6pS5BRQwp8PvbU=;
 b=ZSYvAypnZae4qepZqRQzL4FvaCgTiEDlxnaf37aBzQuyOLC9gMdoTQ7q03x8Ij0jEgqhihwhbyoUo0jEe5dUrThOwyV0MOGjKGuzZjPjGZ5QBr/TAK6CT9o9Ms20EpNUCgVPe0usxOIfRlRkxC3m04+YOYUVfwbJ7RDBhurBkefqgLn4WJWfPBkMJVa/Pv1C9eWowx1cnDh+cUHXH+JNqM2hFD1eK3YHjDK+2I9HB71QicqX1rrBsSt2tP3etqAk0Y8+T1NLqfsMfjh2oqF1Xd5o4g+/AVNUo/MZNkOxzb5cB1/VEiNaDDpJIGsjFnyA/zc5bVeLDopL7kpebRpU1Q==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <8d95776e-e97b-4674-94d7-9ab98be0e337@epam.com>
Date: Fri, 5 Sep 2025 12:35:25 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
To: Demi Marie Obenour ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
 <5a6bf835-6c87-4e1d-adfb-a932fa1d7581@gmail.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <5a6bf835-6c87-4e1d-adfb-a932fa1d7581@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0178.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b7::6) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DU2PR03MB8123:EE_
X-MS-Office365-Filtering-Correlation-Id: 2eec6fd5-84c6-46f4-18f5-08ddec5f8bdb
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?S1k1SjVsbS9RazJqaXVEcHk0Nk4rYnNXaGtjTk9qZzlmSitrUTZvdDJDWk9G?=
 =?utf-8?B?T0lTZEVwMkJHUUZzMHEvOTZyU1dQMTltWnpOMkdQcDI4LytyNSsyc092UnVo?=
 =?utf-8?B?TnBFamkyTk1GUXpEUHNTYmdZZGhXWkdHd0YrUEVuV3BNSlhHVWo3VXU3MXAx?=
 =?utf-8?B?MXNYSzgvaWNwK0hEclpsc0grNTJyakpHS3NvY0VLZ0VBOEJQVXFJSFQxaGpW?=
 =?utf-8?B?ZUJVTVhZQjlHWU1UNHJ2cTdzNDZWQ1FCRkFlTFZOQWI3NERKNXMzSnBOS1FM?=
 =?utf-8?B?bGxoWFlqV1ZoTFpNbGxpcnR4ejJNR3dvTWJkZ2JMNGNvNVg3cWhCY0pucjMz?=
 =?utf-8?B?alVJNkhoZHlzTjhKR1ZQdEUvRnBKSUxUV0VFOEY0ekpiOTgwaHhCbXB6NUN1?=
 =?utf-8?B?Uk14aENRNmREQm5ZU0JOOFpOOWFsb0xLaHN1dFhYbjJIVmltdFdnZWttVFJt?=
 =?utf-8?B?dis2N084QVU2OUl0S3hZdmJMQkJJaktPb003MDJSY0JnR2MvWm1mako1Y1Uw?=
 =?utf-8?B?cTErSVpZaURqTjIyK1Q2L1gyMVdwL3UzQTBwYVN6WTF3djdzOXl6ZEdsTHpu?=
 =?utf-8?B?bmcza0pIc0J3bHd1QkFiVXQzU0hGaDU3ZlJZdWcvZDRIRkpHVVFvd3VMbXFG?=
 =?utf-8?B?L21VS2pvOWNVckFQNldYQVVkQ3NYNjNUN0xKYjNrdFhaOTNFRUtwQ0xmZ1p5?=
 =?utf-8?B?MXVMQ0xIWnZCNWVRYzc2OWk2dG01V2dkWUtoWGt3TXdiZXp5ZVQ5K3FrMXFI?=
 =?utf-8?B?aE11TVo0TG9aZytydmJNUUxCZENLamdObmhmY3poRWxFVW92VldmdEFMOG55?=
 =?utf-8?B?eTI4R3Jka1JZclI0SGdMT3ZhMzZYdjlRZ242emwxRWo2QWsyOFFLd0Z6VUwx?=
 =?utf-8?B?SlIyUU5ibGxxSkxnYWFJeU0ybXpUcFgwZUdRaVVzR0lHOWtsUTdlZldKSG5l?=
 =?utf-8?B?RVQ0SHYyWFNRM2VlMkFYT0dBZlBkbjNrcGdPa1RyMER0alpnWnY0dE03cnE0?=
 =?utf-8?B?Ujh0a1NvY0pXTmJoOUhwYldXOWRIQTBmSEp2a01IdGdNVytLMHdXUlFHTVht?=
 =?utf-8?B?RWhRUS9CUUZ1a2ZTVzYzTGpVYmRxSkxNMGV3aDVGMmhEdG9CaUoxY2o5SGJn?=
 =?utf-8?B?bmpjYmF5cWNnZWZIT2pQa3ZaR1FlUm9tRll6U1NoVk10TnNsanl2NHRUTzB4?=
 =?utf-8?B?Q2JkTGxwdzlhVzlsejd1NUx3NmJWb1IvOVRndWFxTzluMkNDTkxPYlloNWw3?=
 =?utf-8?B?cFpKdGdvM0xnbk0rbEowcXdta0JGMGR4R01vbitzQVFqWExsN25ZRGY1Yjg5?=
 =?utf-8?B?Y0F6YVBZM0NQdzlKNVR3Y0JHVEFhMHN6aTFVNVMvQ1VFb01HWHV0K0tFZFRs?=
 =?utf-8?B?VzN0T2c4U0NtL2tUb3laVithMXU2eGthajY5ODJ3SDg1ZFB0TVR4MXh0OU9v?=
 =?utf-8?B?QU81Z2pTZ3V2cUhUUi8vZURFRTlPTzR2Y29LU3paTHNyZFlDNVBOSHVxR3lq?=
 =?utf-8?B?SWt3ZEVaaUkyZ1ZBeGJoU1pKQVZ2UHpYc21Dc3pXcEhOT2FzYWNTbXI2SVV1?=
 =?utf-8?B?UFU2T2U2N0tIYjQrTmIwTUxjcWhyT2VYb3lkaE51ODIvT0tENWxCR2JrR1N6?=
 =?utf-8?B?OFJxdUpESmN5UEJET3crL0hGYVp2RG04MVBrbEZzaEorTFQwOENBbE4zRTlt?=
 =?utf-8?B?eFFMT1VJUEpUVC8rc3VhdVBzYi9rUDBqdmlYM1ZWZUY3TWVHay9BWGxPUzU5?=
 =?utf-8?B?eVpPZGE2Z3lXMDVrSnJ2NElvM3VjZ2Z5c3ovR0xjVXo3dzU0T3RzNmRSN0Vv?=
 =?utf-8?B?SWpPZ3I4ek5pTFExWTFpOWpqdVZJSmV0VWYwV25rTlFyM0MyREVRQlQ3eC9K?=
 =?utf-8?B?Wkk5VHRaR3RxeTJGbGJDTWU2a1ZjQ3B6MC9iaEdvYXBPMGxhWG9aS2RHYkdL?=
 =?utf-8?Q?FOTj+fJMxhQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?V2xOdSt5V1lyQXozUzByQ1M4L05LcEtZQk9RNWhrZnpwV1R2Z0RGTmEyMlhF?=
 =?utf-8?B?dEtpb2o2SU5vRm1CNkhwc1AzREd5UExSMUFjL0NVeGFWYXVzV09vVURzczJk?=
 =?utf-8?B?UmlwNWtNQzFKMzJSazRXZUM5WnNBeVh5bzdpVndGYTFDbk9OQ3VoM1kySzZ5?=
 =?utf-8?B?SzR6eUtWeC9zRFl0L2V5ejZreDMwT0cxdjg3eUgyODYzN1BYQ09MSWNrdFdB?=
 =?utf-8?B?ZWVWQk9Xb1JYam80Y0NSK0xZcmpUTTltQU9wQkEyV2szT3NsTTJiQVA3WDBs?=
 =?utf-8?B?M0YzTlFjWTFNVUVVaWFyOUhDNWN3NmZiQldXaEM0dUNHQ0dkdTFzOWp6c1hk?=
 =?utf-8?B?MTVjOUR3b01NOSsrVVVQb2JkeW9vNkk0aHhoT1hZZGswdFJpc2ZBdGdobWF2?=
 =?utf-8?B?Y3A3Y1JqeGxkVU9Na1dWSVBJVzJUdWJNbFdNVi9mSmowNUU2dzZ6SmYxRVk1?=
 =?utf-8?B?ZU5iNWVScFd5WFlHRTVWWlRLbGtqUVRuSlJDam9OY3hBNHl6RTZGcmd6dzA0?=
 =?utf-8?B?SVE1TUlsL3hXeG5wdWF0QlVRbnlrSW51QnVRQzhmR3hPbSs5MkdaSTRqMjgy?=
 =?utf-8?B?SXZHRUtrWENFcUxWRTBaQzhxYUl1QjdsZkpEaWFxOFdFVFA5RWFtNlFGUnM5?=
 =?utf-8?B?ejFQTWxoQzNFemtPRkV6Q2dMS0JsakoxTUg1djdqbW9aTGNVVXRiZ1h6YzF5?=
 =?utf-8?B?MnJCU0l6c3lqZDF5ZTBQN2JpRG9WZCtPQTl3VHpjMkV6UTBnVFhXck5kSEVE?=
 =?utf-8?B?cFI4TFdWdnRHSDRreXVrQmp0Y1g2SW5IWkRhK1ZEYzk2WTV1OUNVYjltdzc1?=
 =?utf-8?B?ek5YUWFyb1V6ZHFiMnVlMjRCWTNTeThURWZFWjRobXowb3VaNG9YUnJvZUMx?=
 =?utf-8?B?ZEdhYTd6K3FSVUJBWjZzUi9hYTUyTjNIMnNNQS9INFZjbFpjM2xwY0tydFZi?=
 =?utf-8?B?ZVpsdXpnYjhMcFRYSVhnK1p6VXp6QkdPSUtiTEZMWkZXR05mZG41Sy96VVM2?=
 =?utf-8?B?eDhBNCtKNStxSnd3Nm9JMUtNSzhNd0dEQURqeGVydmFtbFhaazFSNTdWejVk?=
 =?utf-8?B?YVF3dFZDYzR1bGhzSU5HQVNPSTliNGFpU2NyVXBzZytUMUJiRUcyelB4Q0F3?=
 =?utf-8?B?VHAvZFdSQ0lHZ01na0o1MTdEdEdHUzBWcFhocUlKVTVHSmtjcVptRXJjY1Z2?=
 =?utf-8?B?ZDFDYkRBOTkyQkN2N1FwRHJTMllXbFZZZkdTbzgvREhvbmEwTXpDRENhaUJ2?=
 =?utf-8?B?dFNTMVQxUDY1MDZDV2lLVFhhejJ2MG1RUFJUMTRYMGVZVEJmYzBCNC8yd29l?=
 =?utf-8?B?NlZERHExRFR0VjNPRWJiL1FaTW12ejZqY21FbXluWnZUZ3JqSWQ1c04yeWR3?=
 =?utf-8?B?K0ltM2V1bmxSTHQ0Qy9qYmpqeDdmT3dlc0U5eUFNTHF2U0F1MTlIRU15SWU0?=
 =?utf-8?B?ZnhDVUh0TWc5blk4WW16Zk1INUxydTQ0eXUwTktkTlJiQTAvaDlram9BVkRl?=
 =?utf-8?B?RlZMU0dMamhyTnI0emF3UG9kRjhyN1hBeE9URFhyMWhNV3doczFIYmFvU3dw?=
 =?utf-8?B?aWlDRElSQXRZalIvM1EybkxPd3J5dVFjLzNXWENTeHcwaUdOeDdNNjFVQTRP?=
 =?utf-8?B?L2lZYlArbElGS2VxRUxpbExoVkVsZXBGSlZQZm1kREF3dCtGNDhCU2lDTjQy?=
 =?utf-8?B?dkJYMkdMZy9jZXBkMWg3blRLa1JVZW1TWjJCMG5OTEM5OWkrNnFPYTN3allM?=
 =?utf-8?B?bWs0eUk3enEwS3lzVE4vS2t6eFh5RmxPUlJlSzNEMUNadkR0dVhkZmg0cUYr?=
 =?utf-8?B?VUQxelNCaE44T0lpNmtHd2trT3NhNE5YRTYveHpuaUdwT1FUNXQvTDIxdkh5?=
 =?utf-8?B?MVJidEZUK2h5QWpCYWhHalpGbkdBRnRubjNEcE9iUHF3ZE9kV2ZYR0pZOW1j?=
 =?utf-8?B?SFJSRmJQODNONnQ1NEtTMW5EMnppekRjb3hxZWo0K21uTnFPdklMeHNjQUgy?=
 =?utf-8?B?dVRHUHZ1cytCZmx2aER6SHNtM24zZktLbTlkbU5reWNpSlIwR3RqZys4QUFo?=
 =?utf-8?B?aVBsNDZLajlBOGd6MFhYektyenRRdVY0bS91WXVobytxNVBQc1d5a1F4M2Ni?=
 =?utf-8?B?ei9jSXNZeCs0UnRlZzV4Z3Qxa250QzFReDRwUzJOekdUTkk4MVNJNDErN2Zo?=
 =?utf-8?B?Qnc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2eec6fd5-84c6-46f4-18f5-08ddec5f8bdb
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 09:35:27.0384
 (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: TmvIt2ORoZew1M4P6aNhACy17lW9w1mVCiEnfo2w9iQT1acmvJsBqkJoVGmen0PKRDmiq9c1yXY8E85y3iNQrjYQMcRKJlOH5HnDx0SXPa8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB8123

Hi Demi,

On 05.09.25 06:43, Demi Marie Obenour wrote:
> On 8/6/25 05:49, Grygorii Strashko wrote:
>> From: Grygorii Strashko 
>>
>> Now Arm64 AArch32 guest support is always enabled and built-in while not
>> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
>> support might not be needed (Arm64 AArch32 is used quite rarely in embedded
>> systems). More over, when focusing on safety certification, AArch32 related
>> code in Xen leaves a gap in terms of coverage that cannot really be
>> justified in words. This leaves two options: either support it (lots of
>> additional testing, requirements and documents would be needed) or compile
>> it out.
>>
>> Hence, this patch introduces basic support to allow make Arm64
>> AArch32 guest support optional. The following changes are introduced:
>>
>> - Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
>>    Arm64 AArch32 guest support (default y)
>>
>> - Introduce is_aarch32_enabled() helper which accounts Arm64 HW capability
>>    and CONFIG_ARM64_AARCH32 setting
>>
>> - Introduce arm64_set_domain_type() to configure Arm64 domain type in
>>    unified way instead of open coding (d)->arch.type, and account
>>    CONFIG_ARM64_AARCH32 configuration.
>>
>> - toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 is
>>    disabled.
>>
>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>    AArch32 is disabled.
>>
>> - Set Arm64 domain type to DOMAIN_64BIT by default.
>>    - the Arm Xen boot code is handling this case properly already;
>>    - for toolstack case the XEN_DOMCTL_set_address_size hypercall handling
>>      updated to forcibly configure domain type regardless of current domain
>>      type configuration, so toolstack behavior is unchanged.
>>
>> With CONFIG_ARM64_AARCH32=n the Xen will reject AArch32 guests (kernels) if
>> configured by user in the following way:
>> - Xen boot will fail with panic during dom0 or dom0less domains creation
>> - toolstack domain creation will be rejected due to xc_dom_compat_check()
>>    failure.
>>
>> Making Arm64 AArch32 guest support open further possibilities for build
>> optimizations of Arm64 AArch32 guest support code.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>> changes in v2:
>> - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 support
>> - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with any
>>    initial domain type set (32bit or 64 bit)
>> - fix comments related to macro parameters evaluation issues
>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>    AArch32 is disabled
>>
>>   xen/arch/arm/Kconfig                    |  7 ++++
>>   xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++--
>>   xen/arch/arm/arm64/domctl.c             | 16 +++++----
>>   xen/arch/arm/arm64/vsysreg.c            |  9 +++++
>>   xen/arch/arm/domain.c                   |  9 +++++
>>   xen/arch/arm/domain_build.c             | 21 +++--------
>>   xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
>>   xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
>>   xen/arch/arm/setup.c                    |  2 +-
>>   9 files changed, 119 insertions(+), 26 deletions(-)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index a0c816047427..bf6dd73caf73 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
>>   	help
>>   	  This option enables PCI device passthrough
>>   
>> +config ARM64_AARCH32
>> +	bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTED
>> +	depends on ARM_64
>> +	default y
>> +	help
>> +	  This option enables AArch32 Guests on ARM64.
>> +
>>   endmenu
> Why UNSUPPORTED?  A safety-certified build of Xen should only be using
> security-supported features.

I'd probably introduced a confusion here due to my limited experience with
Xen upstream, sorry for that.

What I've tried to note with "UNSUPPORTED" is that it's new option, which allows to
change default Xen cfg.

After re-checking existing Kconfig files - I think correct way will be:
- change dependency to EXPERT
- remove "UNSUPPORTED"

Will it be ok?


Thank you for you comments.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 09:47:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 09:47:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111557.1460215 (Exim 4.92)
	(envelope-from )
	id 1uuT2a-0004LR-0X; Fri, 05 Sep 2025 09:47:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111557.1460215; Fri, 05 Sep 2025 09:47: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 1uuT2Z-0004LK-TF; Fri, 05 Sep 2025 09:47:31 +0000
Received: by outflank-mailman (input) for mailman id 1111557;
 Fri, 05 Sep 2025 09: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 1uuT2Y-0004LE-GO
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 09:47:30 +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 5275ef4b-8a3d-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 11:47:24 +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 5858E7UF022544;
 Fri, 5 Sep 2025 09:46:31 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 48usurfkcd-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 09:46:31 +0000 (GMT)
Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5859bi0p009310;
 Fri, 5 Sep 2025 09:46:30 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 48usurfkc7-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 09:46:30 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5856Gg3M013959;
 Fri, 5 Sep 2025 09:46:29 GMT
Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 48veb3rk09-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 09:46:28 +0000
Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com
 [10.20.54.103])
 by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 5859kQ0M52101484
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 5 Sep 2025 09:46:26 GMT
Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id BCE5220040;
 Fri,  5 Sep 2025 09:46:26 +0000 (GMT)
Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id AF00220063;
 Fri,  5 Sep 2025 09:46:24 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.111.88.103])
 by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri,  5 Sep 2025 09:46:24 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5275ef4b-8a3d-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=6wm0ttcidOnuuW+7W5s4enprUWnKXF
	XXBpVS5cSOiYc=; b=VMha2oUbllfJfLMtOLr57qJJz6vzFJD7LJ8gk5XShnJjc7
	IbrZHVpXb0CrQB5ykpgaxxSFsvvfNEanPBHuuHOGbETD14NXO2pqfL1MNf784mVy
	uvjiyf12/QVwQ2mZmkqASP9O1WaaViYltK6jPW1ia7fc4z77ZZIcxHNd6zZP5Nha
	CbH/zL34/kidtMFkhDHPIOsMEJbRBMwe8T8wEPT/Ddq6WBOoaLYfsZ8bm+i7vTSv
	P1GmCBCUdyPpWD67R2YaTENZDIlFGnxT+oj4rEpMuGkVtfQCqHsL9/re90DkKZLP
	0DLbyK939ud6LvSGoOT7rBnWZkhI2AUGLtGlCZgg==
Date: Fri, 5 Sep 2025 11:46:23 +0200
From: Alexander Gordeev 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/7] Nesting support for lazy MMU mode
Message-ID: <9fd076c7-f163-4b92-8201-d8a259a338c1-agordeev@linux.ibm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-1-kevin.brodsky@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwODMwMDAzMCBTYWx0ZWRfX0b7vKa9wIqUd
 15JIKVxY/eFyoNy0/rx0rVDv/Yc4PB6ogniG6U5JZlC8qyn8Y0NgFv6oYYbeCaWjZF7P/Etub/q
 /XnEYzafYNkoOrYQMbqj6nFHYpYxymufPYjcGAjaRnVt2jxUzS3zPb6lpNjC6s5Oxrs0WYMRvbR
 dBvy+J/7pMy+teTA+x9T/E6ggkXyizQGe//4AxcBxcrhCKNqzem6rRKcxJLTefmrfU0CU2VW6uC
 5x2JqlOAMSNtXM1AfGSytrxIFOr2S3XPEdTEP1QyOTNlKzTtGtrjaWkIbxQVZc7XyWa9Ggbdnl8
 wkgYg373aI71Rh0ZOzmEr1tWX4M68Yz9HwoQbCiqMpeXkMBa3EZ9mW+HowhL506x5+1yPvl4rLU
 90pIQxaV
X-Proofpoint-GUID: NmMecPGQNEFV5Z6yet56qjNF4vqqAdRy
X-Proofpoint-ORIG-GUID: 1xCeVzb0bz4EbY7yd5ySncyf5nvF03Hn
X-Authority-Analysis: v=2.4 cv=Ao/u3P9P c=1 sm=1 tr=0 ts=68bab177 cx=c_pps
 a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8
 a=PE-dCK3ueRk4C2obWmcA:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-05_02,2025-09-04_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 clxscore=1011 phishscore=0 impostorscore=0 priorityscore=1501 spamscore=0
 suspectscore=0 bulkscore=0 adultscore=0 malwarescore=0 classifier=typeunknown
 authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1
 engine=8.19.0-2507300000 definitions=main-2508300030

On Thu, Sep 04, 2025 at 01:57:29PM +0100, Kevin Brodsky wrote:

Hi Kevin,

> When the lazy MMU mode was introduced eons ago, it wasn't made clear
> whether such a sequence was legal:
> 
> 	arch_enter_lazy_mmu_mode()
> 	...
> 		arch_enter_lazy_mmu_mode()
> 		...
> 		arch_leave_lazy_mmu_mode()
> 	...
> 	arch_leave_lazy_mmu_mode()

I did not take too deep - sorry if you already answered this.
Quick question - whether a concern Ryan expressed is addressed
in general case?

https://lore.kernel.org/all/3cad01ea-b704-4156-807e-7a83643917a8@arm.com/

	enter_lazy_mmu
		for_each_pte {
			read/modify-write pte

			alloc_page
				enter_lazy_mmu
					make page valid
				exit_lazy_mmu

			write_to_page
		}
	exit_lazy_mmu


This example only works because lazy_mmu doesn't support nesting. The "make page
valid" operation is completed by the time of the inner exit_lazy_mmu so that the
page can be accessed in write_to_page. If nesting was supported, the inner
exit_lazy_mmu would become a nop and write_to_page would explode.


...

Thanks!


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:05:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:05:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111580.1460235 (Exim 4.92)
	(envelope-from )
	id 1uuTKC-0007i0-I9; Fri, 05 Sep 2025 10:05:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111580.1460235; Fri, 05 Sep 2025 10: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 1uuTKC-0007ht-Fa; Fri, 05 Sep 2025 10:05:44 +0000
Received: by outflank-mailman (input) for mailman id 1111580;
 Fri, 05 Sep 2025 10: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 1uuTKA-0007UD-H8
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10: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 e14de3ae-8a3f-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 12:05:41 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b0454d63802so327912166b.2
 for ; Fri, 05 Sep 2025 03:05:41 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b046aa92242sm589136366b.59.2025.09.05.03.05.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Sep 2025 03:05: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: e14de3ae-8a3f-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757066741; x=1757671541; 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=OPitMHA0jLlZD3e3Xgx2NPRkFt8Wh9k4Wg+0HJuHEqU=;
        b=bGm0NIwLyFnpLCxUnOPWqDFkOBgmfltuYulANuRMHYEG52EWvFNfu46Th8oNa6x4OV
         lUJLquGKLOR4GoqZfa1Xn+/YrgOrX0bgBLX2MPZbq0LpREi7WaxxTs9PvUia1KmJErAg
         6PMFfPX6z7sraViBoWSbQP0pUL8rmFVfAStpQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757066741; x=1757671541;
        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=OPitMHA0jLlZD3e3Xgx2NPRkFt8Wh9k4Wg+0HJuHEqU=;
        b=dtPMd2cBEnL4UTFsJYpbi4W3y3sJJqzR07ZduiSQ+JHMZgoZ00nPiieKE7AK4WOnw+
         ZH158G6fJgtNiLzG5HiI9PPNaQNIRh0eZ2w7wefZEQ84fm4MZB4naJCGv1G5J9Tj+Yi7
         lnaH5pxGxd5jzcT4nWpw0qZsv//r31sul3CZ/yAZjlEjmbb9Rad9phXWZeKOOJF2OQwl
         U7CmDLYq54J4fOIoSW9JWkmIsQM+TSWZcpeOmOl8tqhfqzaNK8bhqv6Z5vfU1aGGuAQd
         lWwEm4yQ8rdvGi8UtqeowBoE/tN49zNjatf965DOfdq+lDJoe1VoyfxiHW3NsN98M7lm
         hhCA==
X-Gm-Message-State: AOJu0YyXkBVRUVF/6+a34j65s9q+17ZjInaucCh4vyojjgT1RBYSbICi
	Y01kEGvNtRHi5NZUffCqvqaFoctA5TSsNVCPcu/noh5wIoo7Tu7hvhxOPIzTM5K2x9jUSm9q1TI
	1QN5iCXs=
X-Gm-Gg: ASbGncvey2oqCghkoiQ1BDT80PmgnLzAxBqiSNw/Rf25n6nib+WhgbiXvwiQoOfNSW5
	X2UUiRVFi2NUwA+xE7snc2YFdR4gJFnZvM9hHIAsozDNIiMxrT1XrakynbJvM27C2a2IKA1IC/K
	ktdBM972icd6Az5eHFYXjL2Ea3rTdF0KYVLq1ei1soR07ndlnaR8qP/FAgv1MA1tYlWkfD9LFEG
	PJDvEjn1m8Cu1QZw7N4q5xGLTqQlL/CBwt2/gAAT9Y7umoAR8vCgixKNXDbOM0kEqxGYt9DG0zG
	K4xoAzwc7VWIuV66yHdSFOIFzglKNwDE75LXbOA/exxBgWE9AIeB86qYPMNxjF3SdzBOfDDYc+m
	V8nE2CrMXAW+gTld3vU+mtQyMsdQFBNtkLhlniea8QihItw==
X-Google-Smtp-Source: AGHT+IG1Mp//cjVox34ogFLm0En43L8JoN3VGqJiPNeWa/nib+CJdPJRUSpYH13i8vQV5m4EM4JLHg==
X-Received: by 2002:a17:907:72d5:b0:afe:a6d3:b4a2 with SMTP id a640c23a62f3a-b01d8a39b3fmr2307105066b.11.1757066740796;
        Fri, 05 Sep 2025 03:05:40 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 0/2] efi: Support Shim LoadImage
Date: Fri,  5 Sep 2025 10:05:30 +0000
Message-ID: 
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Support Shim LoadImage protocol but keep Shim Lock for compatibility

https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2023640279

Gerald Elder-Vass (1):
  efi: Support using Shim's LoadImage protocol

Ross Lagerwall (1):
  efi: Add a function to check if Secure Boot mode is enabled

 xen/common/efi/boot.c    | 83 ++++++++++++++++++++++++++++++++++++----
 xen/common/efi/runtime.c |  1 +
 xen/include/xen/efi.h    |  2 +
 3 files changed, 78 insertions(+), 8 deletions(-)

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:05:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:05:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111579.1460225 (Exim 4.92)
	(envelope-from )
	id 1uuTKB-0007UV-C6; Fri, 05 Sep 2025 10:05:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111579.1460225; Fri, 05 Sep 2025 10: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 1uuTKB-0007UO-9Z; Fri, 05 Sep 2025 10:05:43 +0000
Received: by outflank-mailman (input) for mailman id 1111579;
 Fri, 05 Sep 2025 10:05:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuTKA-0007UC-7P
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:05:42 +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 de61d3f4-8a3f-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 12:05:37 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by PA4PR03MB8295.eurprd03.prod.outlook.com (2603:10a6:102:260::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Fri, 5 Sep
 2025 10:05:33 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Fri, 5 Sep 2025
 10:05: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: de61d3f4-8a3f-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zPPymxeUQLhU6h7Au1yUzCnjdfxamn9tHtSrgag7Sgulz/lhVQqXfeYMC1WmvSapqdWOMMvfrkRlJ75xNS/u4jGaCBjUOSf9s7IPCytINofk3d7Q0Pz/8xrgdMcAvTq2q2mdIl4IcWMjpD0cpN5LisUs7+N+qUYub6qkIxRAp57DtKpeSXAgmHWYb+LvbBFgXRkwpOkjVTXFCwJ6VMT+vFeqbNGFCsZbCMWbK0W1BPud+4g9qt6/zA5/DnBsWTYHufsmZS5U4SD7mzf6MBJrhKS8BeicCkViTBu8pU1LmgmR2/ITt1ivNO2NWBaIjF/Z2Kif0KwxPYBjwdmvUWq7jQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DdungOsxOzp7BSzikz/ChkxnYS9pubO+hZKQjxzrfWc=;
 b=hbsJisVAfCKHTADzzI7Bum1+dGo9tfGtThi4sMxbt5xk1bpWAWgpUzJZlVzNM8rPcbP2Ea1kimj+tf30CLKSHNB5Dt+skN3Zz/dAIGkgYcZ+H0S3VC9XLR21qunyS7phGxoiH9LS4BL/n//PCPbT3k6nVA9WBOhWIlQy2WxhibDarEecPlDjxtLhXwkUtkub3r2Ps3F85GIaET1qdK6q4IuaSR1nUnQZ2zH1idYSR1A7Q6D8w+DANYay0syh5KOMs9pPf9/PK6hbMH48tozE7dBLqAZgqrA/Z8QyY0Hvi1XUNt37E9urzJ5C0lRxLcVPSId3VTUStOixRdsaEl3RYQ==
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=DdungOsxOzp7BSzikz/ChkxnYS9pubO+hZKQjxzrfWc=;
 b=Jrl6n6TM1n3aUg48zZ2Mx/PeKzkulxc/aQXs/KT8CdwOxIDVLPDqhqBboG68c7ZP55oJsYknLDdtzNIKHJlz9HqLwCbmA971jNfMhM6wOjNYsB8+Y0IkPPzEmIVc2FxaiSkW6pPqsF/o5HbtMtEExA8fxzBJBIud66EUFQKj9ts3YNIxWn6RaYNTDT5L88XRd0Kzpo/R6XMQrh680m+PVEemIhxnWGseJXInqdZA7kXWi+3yadjl5/g41zsj92PqJzn3e/a/A+b/wuahTxtLeDoJouAZU0x7pKEpz4K2dS3D3T9rXL2XmM/Nl04CYtZAP5CwByz2lgkY0qmdpOcFcg==
From: Leonid Komarianskyi 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: "olekstysh@gmail.com" , Stefano Stabellini
	, Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk 
Subject: Re: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Topic: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcHdaxzH0gJHOWB0uscg50WGUPx7SELLEAgAAw3YA=
Date: Fri, 5 Sep 2025 10:05:33 +0000
Message-ID: <00bfaf5c-c502-4792-a426-015f72dfc2db@epam.com>
References: 
 <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
 <3a487f5c-0837-46b4-ad17-410a4a4bc78a@xen.org>
In-Reply-To: <3a487f5c-0837-46b4-ad17-410a4a4bc78a@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: GV2PR03MB8678:EE_|PA4PR03MB8295:EE_
x-ms-office365-filtering-correlation-id: 3b216163-e876-41a7-1f7d-08ddec63c0ce
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?MU5zZnI5RDNXV0RBWHVUZGlUL2lFZEFaR29GOHFiVy8rOTBzSTJxOVFpK1lC?=
 =?utf-8?B?cmFBWmF5WjBiR21BL09ZZnR6ZTlCMWZ4ajczZW9ER2pSay9xMk4wMDdhQ3ZV?=
 =?utf-8?B?bWdDdkh2YUMwY2RSbEp0SkFxY3dqY0N3eVdWRFFCWldLQ0FBVXBJQmtrQnV2?=
 =?utf-8?B?Znp1NyswTHp2elMvT1BqY1ZWQUhFeGloQXF5NklNQklVbSsxTDRKZmpaOFRE?=
 =?utf-8?B?empKMkVNMGkzOTNUamlLamliMnB3SGdwcmlTZXdvdGZZc2h0YVhpUk1Mak9a?=
 =?utf-8?B?L3RtejRCODdhSUp3eHFNaHI1U1ZiZFNyeDZ2TTlra1ZldHpWL3R4bU1SWCtQ?=
 =?utf-8?B?cmJqRkNIdGg4aEpwdk82OUp0eU9QMms5K2tRVUVwUUVDcC9YSGpUaTRUTzUv?=
 =?utf-8?B?dVk4dElQUk1hc2IzYTJEdmRKTTdSay96RmlVMW9zYlcxa1B2K1gxK0VOK2Z2?=
 =?utf-8?B?VlBEVE03eFpVazRCSGZXbHM1VHBETFExQWNoQUVkeTZVeDZHcnFjMWhRWktQ?=
 =?utf-8?B?UHVxV1VEa0xpa0dRenRZNVRMK2FMdmRpaTVHamJaZkIwbWhRMnB5b3krdVI2?=
 =?utf-8?B?a0dtOEFjMFg1elRBQUc2cTVoRUhDMURhZTk1MU0wLyt0U3dRN3hTSU5YQjNR?=
 =?utf-8?B?TXdjdnBXZGdJYjB5cXE2djB6djdxblJqb0Y3Q01GM2hwRnJ6dDN1TWdjVU9Q?=
 =?utf-8?B?THo1YnlFSldNYWNaeEljLzU0cmYxM2habXlMWDBpNkY4c0RsdHdHc0grNnU4?=
 =?utf-8?B?ckRyK2RpamhFcTBVME5sL1Q4L3RhUHJSckVmbHBzbGQ1Q3hXc3dMdVdDVDhO?=
 =?utf-8?B?R2xzcXJ5NUFRdWI2MldsTzdoUUlyTFB0Vk9QYUIyNjhzbk5RUVRhaThLZVFM?=
 =?utf-8?B?MXRoT2lFVkpFenR0ZGNCb3NhNDJRWmtkM3p6dlEwVVptbTRHbzl2dnk1cCtp?=
 =?utf-8?B?TTRmNXZHMUphQW1hZzM3L0pxZElzZVIrWWZlakd4dzdNM0UvYjNCTWp6SGRi?=
 =?utf-8?B?R2hiNVZ3MXdGa0xNalRHQmJOZGVYbXRLR2VXZGFNZTl3V09rLzR2aGN1TFg3?=
 =?utf-8?B?OFNER2twN1R3ZFhzUGszT25QbEV3Uy9TOEJsMkdvbCtTOHhqV2dQWUJod0RT?=
 =?utf-8?B?YTNXbm9IN3llbDU2WTlaamtVNkxGVlFnUkxFR3l4TFkwaXIyOFhBaER6MFdJ?=
 =?utf-8?B?TC9OL3EvUUltRm45NFdDNks0blhoYkpvN2ZkbnF3SVFzMmFPNnovUWU1UDBC?=
 =?utf-8?B?WTVrTjNUNlE5NU1sTXdJTFY4TklPV0cwNWVNcDltMVpFMFhkODZoMU1nMS9I?=
 =?utf-8?B?UUN1dWZOWmoyOWRqa05qdm03bjRUcys5azVLcHdOSElHYjljYm1XWFFPNnVO?=
 =?utf-8?B?MmFjdmJEREhsZWFPVE91bEFYMmxsWUVGMTlhQVJ1WkVQWU12cXVGZXVzWGZJ?=
 =?utf-8?B?VmVSa1Z1WnlOcVRZajFpV3ArdFcwajJxVXh1SjRhRXpxRStqaW1JNy95MnhN?=
 =?utf-8?B?TUtnRitlWCt1SjNMbnJhWGJMKzRpNGhJRWgvYnBiQnNDTmdQbUg5Vld3Uysr?=
 =?utf-8?B?MnBiT01mWHVzQ3QyaXBrdmE1dDd5cU4wa01FblZHS2xSN053MnlzS2M1Qytz?=
 =?utf-8?B?NE1RT2xkMkxlN3VRaWZxTUdsa3JaVkV1WDYxczdoR1pYZVRaM3VkMVZ6STZk?=
 =?utf-8?B?L2NZUlRWSWNKNHRSbXRuUFF0OHdSMnFrVWtnamgwdzVKRHF5Z3ZIemdGMFB0?=
 =?utf-8?B?NmhXNk91SW5DbTNoN1Z5blc5OHVMbmpUbjQxOWVEWDBpU0E1RW1rL2labW1M?=
 =?utf-8?B?emRZcDkwQzJGZllqUjl4VXhHTnBpZE91bmtrWU5JTDZrNzFoaUdHMlZzeTUr?=
 =?utf-8?B?UEhPdXpxRFBGYmcwT2ZJaE9VcmNUSWlSeXluTDNGM1RYaEx0RXd5NlFmSU9w?=
 =?utf-8?B?bmtVaWdkL1BLRDUwenY3UFBoalhnY1R6ckV5RWwvc2FqSmtGQUhsZUxuZ09O?=
 =?utf-8?B?LzFFZlNOMXhnPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?b3FZN1dDYm1peVJ6WmhGQUUzaGJ6WGtqTlUyZ1JlRWxFV3VuK2tFZ1NUaVZq?=
 =?utf-8?B?ZlRMRFg3UkhnZ08wNFk5Z2piYTMzbTdBT0VTL2lPMG9YL3VXVTg1TUhvUkx1?=
 =?utf-8?B?ckZGNW5yYXVvWjhNaWg1K0RmUTNLMkM0ZlI5VHp0UEZvSlNMQXV1UkpFaFNS?=
 =?utf-8?B?VENJNnZ3ZWVLTTF2QWRuUkJacTdkYWNmUm5ZY1dsSXp2dHB2b0hsdzkxU3Vz?=
 =?utf-8?B?bjVwR2FhVUdQOVVsYmlRV1BYWGs0Q2cwRy9iOUdMdWZsRzBQem8xMXB2UXRY?=
 =?utf-8?B?allaeHdvcXdEQzRhdUlFWEEyVENyZjErQUZ0MG56VEpneXBJSEEzcTFodVp1?=
 =?utf-8?B?aUl4R2N1OE0xNjZXREsvalZzUncweHlFU3A5NnRwUW5HMFZQa0lyT2FwcHFu?=
 =?utf-8?B?YVM3MWZCMmt2d0NlWjJNdHFBdk9HOVpBTTNRV2drR2Z3UUorbERrQzNRUmM3?=
 =?utf-8?B?MTJNaC9EUUFpMUVKUWpIbzMvMXM5ZDdOb3poNTBwS3dzSUU5cy9wQ1BVc00y?=
 =?utf-8?B?Sm5kdnErU1Y4N1k5QjJCYjlQdlNjZ3c5bjVzSTc4WjdMNWs2b3QxZU5FQW90?=
 =?utf-8?B?cEZWZE5PRkxaVzR5YlZLTGdpK3JKUm5uelBzbWRWS085cTF1N3REQjlKclVV?=
 =?utf-8?B?dGdJYXNYeU5hbStwdWxNVTJXaEt2QytUS0ZiamJNTUgwUU9OTnRHa1g3OE0v?=
 =?utf-8?B?ZHZMZXhJU2U1TEFPWDU0a0dxQzhDM0Y5Y1NnY3BMd2IrbTJDa3BmTmJqL0k0?=
 =?utf-8?B?RXVrQTE3dUJFNGg3U0FudzJkeVhPY0M0NWFYaHl3R3RCVXY3MHNpNUhyUVUz?=
 =?utf-8?B?YnN0UjE3Z2RTVTR4T0hyTFFJMnFiam1aSGJ4c3Vuc0MyOTk3TjRNYWV3T0pu?=
 =?utf-8?B?aHAxS2dXaTd4UXFIOEZMRS9YaUtjMHNRNjdOYXU2U0JMbkdxcVZKbVpCWlZF?=
 =?utf-8?B?NjV5YXJCNWJXRHpINFFnZjlLR29GanVweisxTEZSYTg5UEFSeFk0OHQrakpV?=
 =?utf-8?B?aXBwYXA1TFlXejlDb05hMVMzRVowejVxMUFybzYwd1dBWjROQktUR0FRaDNL?=
 =?utf-8?B?TnVlREJTMEpLTUltU0htOVYralEwbTRhLzlqdU44V1pUbkRNUVN5RFd1cnhX?=
 =?utf-8?B?cmRVK1NJNGdRWWdFNDFieHVDTkNUTW90STM1R1lNcUJRcVhFc3JBd2tudXVu?=
 =?utf-8?B?c3Vhbks4U0VzUDNMZG9wRzQxUkl4OEl6aENoUFRXeXhWbHpXQlhGbjM4SGFN?=
 =?utf-8?B?T0hXL3o5SUhaeWs2OTNzUjIxL0MzYmpFem4xQXZrUW1sN2d3OFU4L0tKTzFD?=
 =?utf-8?B?cHNtdWVUcHB2QVByUXpJbkRCL25TMWhBWDRJZWZaREM2M3BzRloxTVNZTmJ1?=
 =?utf-8?B?UnZOU0FZcEVtUDIvSXRrMUJodnpWNVZ5aWx1dmJ3WGx5d2lFUkxrNjd1RW9M?=
 =?utf-8?B?NEs0dkdseHhtTFBYQXFzVnN1ZloxRXVDWGtIL05IOUVRb1dGZGtBVkJsUlh2?=
 =?utf-8?B?T0VwbmJOWGdpc3FldlArclRhSmp5eG5NMXVodUw1bzNoRklTUm5vamRxVFBS?=
 =?utf-8?B?Rjd1Mk83TUlJTjI5dXRNcWlOcUMyMEtEeGdnQ1dINSs3TjVXZWNhOG1OeFFQ?=
 =?utf-8?B?M0NaaEsxTElRNjVaeVppR0g1Qm95Z05UQStVbldvb3RnUGNUSksvMWRQUWtK?=
 =?utf-8?B?alFmK3l0NFpSYjZQVG92VlhxQjVUeWhZaVZ2bzJBMHdCSmFqTy9lc0RBZ0NW?=
 =?utf-8?B?OHFCMzNCUTQvY2lPQ2dubktrTjVZNWtQSXphazlhWitGR0paR3NXam1qcFJn?=
 =?utf-8?B?RTh4SG05YWF5ckhCL0lvMFJydllkdS9RQzVMM3YrZUVMQzZOem93bjhjb1Fu?=
 =?utf-8?B?MkhhdG9vc2hIYlFGRXE5cWdMdjZORGVFRjM3TXF1Qm84dDk2cVFrbks4ZEZZ?=
 =?utf-8?B?MDZoQmVzUjF4dTdiSk95b3Y3ZXkydTBqRjBSQjZQWjY3NURNZG1ZVUp3cHpi?=
 =?utf-8?B?SG8vTW5xN21wNkhhd1UwNWtNTVVsTmgzUkFEUE80WWgxNzJmSEdBUzBlMFQ3?=
 =?utf-8?B?cllqSDlsczdiRXBFd1hhY21WZi9ZSFBCL3V5MHZMZnYzWjlVaVlHUUJvblhM?=
 =?utf-8?B?SU4rLzE4K2VrSFR1a3BiRktSb3c3YnhuNXJvK3BDZytDTDhIZkxVT1lTY1hB?=
 =?utf-8?Q?nnEtwkRPd3NjWveyyEkDCjE=3D?=
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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b216163-e876-41a7-1f7d-08ddec63c0ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 10:05:33.6329
 (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: /oO6h2wPOVnIKfL0apTxr4B6+J4Gch6oXWoKQedDnJO/9NTF5SmO7PvX8k9g1aH9H2S4ItO6SH1fYMEte6dG80dEC0N5+8PEQadOZnbHJq0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB8295

SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4NCg0KT24gMDUuMDkuMjUg
MTA6MTAsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgTGVvbmlkLA0KPiANCj4gT24gMDQvMDkv
MjAyNSAyMTowMSwgTGVvbmlkIEtvbWFyaWFuc2t5aSB3cm90ZToNCj4+IGRpZmYgLS1naXQgYS94
ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaXJxLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS8gDQo+
PiBhc20vaXJxLmgNCj4+IGluZGV4IDViYzY0NzVlYjQuLjJmZjJkMDdkNmQgMTAwNjQ0DQo+PiAt
LS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaXJxLmgNCj4+ICsrKyBiL3hlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9pcnEuaA0KPj4gQEAgLTMyLDYgKzMyLDEwIEBAIHN0cnVjdCBhcmNoX2ly
cV9kZXNjIHsNCj4+IMKgICNkZWZpbmUgU1BJX01BWF9JTlRJRMKgwqAgMTAxOQ0KPj4gwqAgI2Rl
ZmluZSBMUElfT0ZGU0VUwqDCoMKgwqDCoCA4MTkyDQo+PiArI2RlZmluZSBFU1BJX0JBU0VfSU5U
SUQgNDA5Ng0KPj4gKyNkZWZpbmUgRVNQSV9NQVhfSU5USUTCoCA1MTE5DQo+PiArI2RlZmluZSBO
Ul9FU1BJX0lSUVPCoMKgwqAgMTAyNA0KPj4gKw0KPj4gwqAgLyogTFBJcyBhcmUgYWx3YXlzIG51
bWJlcmVkIHN0YXJ0aW5nIGF0IDgxOTIsIHNvIDAgaXMgYSBnb29kIGludmFsaWQgDQo+PiBjYXNl
LiAqLw0KPj4gwqAgI2RlZmluZSBJTlZBTElEX0xQScKgwqDCoMKgIDANCj4+IEBAIC0zOSw3ICs0
MywxMiBAQCBzdHJ1Y3QgYXJjaF9pcnFfZGVzYyB7DQo+PiDCoCAjZGVmaW5lIElOVkFMSURfSVJR
wqDCoMKgwqAgMTAyMw0KPj4gwqAgZXh0ZXJuIGNvbnN0IHVuc2lnbmVkIGludCBucl9pcnFzOw0K
Pj4gKyNpZmRlZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gKy8qIFRoaXMgd2lsbCBjb3ZlciB0aGUg
ZVNQSSByYW5nZSwgdG8gYWxsb3cgYXNpZ25tYW50IG9mIGVTUElzIHRvIA0KPj4gZG9tYWlucy4g
Ki8NCj4gDQo+IFR5cG86IHMvYXNpZ25tYW50L2Fzc2lnbm1lbnQvDQo+IA0KPiBbLi4uXQ0KPiAN
Cj4+IFVubGVzcyBJTlRJRHMgZnJvbSB0aGUgZVNQSQ0KPj4gKyAqIHJhbmdlIGFyZSBtaXN0YWtl
bmx5IGRlZmluZWQgaW4gWGVuIERUUyB3aGVuIHRoZSBhcHByb3ByaWF0ZSANCj4+IGNvbmZpZyBp
cw0KPj4gKyAqIGRpc2FibGVkLCB0aGlzIGZ1bmN0aW9uIHdpbGwgbm90IGJlIHJlYWNoZWQgYmVj
YXVzZSBpc19lc3BpIHdpbGwgDQo+PiByZXR1cm4NCj4+ICsgKiBmYWxzZSBmb3Igbm9uLWVTUEkg
SU5USURzLg0KPiANCj4gSSBhbSBzdGlsbCBjb25mdXNlZCB3aXRoIHRoaXMgcGFyYWdyYXBoLiBI
b3cgaXMgdGhpcyBmdW5jdGlvbiBjYW4gYmUgDQo+IHJlYWNoZWQgaWYgaXQgaXMgY29tcGlsZWQg
b3V0PyBTdXJlbHksIGlmIHRoZSBEVCBpcyBtaXNjb25maWd1cmVkLCB3ZSANCj4gc2hvdWxkIGdl
dCBhbiBlcnJvciB3aGVuIHRyeWluZyB0byByb3V0ZSB0aGUgaW50ZXJydXB0LiBObz8gSWYgc28s
IGNhbiANCj4geW91IHBvaW50IG1lIHRvIHRoYXQgY29kZT8NCj4gDQo+IENoZWVycywNCj4gDQoN
Ck9oLCBzb3JyeSwgdGhlIHNlY29uZCBwYXJ0IG9mIHRoZSBjb21tZW50IGlzIHJlZHVuZGFudCB3
aXRoIHRoZSBjdXJyZW50IA0KaW1wbGVtZW50YXRpb24uIEl0IHdhcyBjb3JyZWN0IHdoZW4gdGhl
IGZ1bmN0aW9uIGhhZCBhbiBpbXBsZW1lbnRhdGlvbiANCmFuZCByZXR1cm5lZCBOVUxMLiBUaGUg
Y29ycmVjdCBjb21tZW50IGlzOg0KDQpEZWZpbmVkIGFzIGEgcHJvdG90eXBlIGFzIGl0IHNob3Vs
ZCBub3QgYmUgY2FsbGVkIGlmIA0KQ09ORklHX0dJQ1YzX0VTUEk9bi4gV2l0aG91dCBDT05GSUdf
R0lDVjNfRVNQSSwgdGhlIGFkZGl0aW9uYWwgMTAyNCBJUlEgDQpkZXNjcmlwdG9ycyB3aWxsIG5v
dCBiZSBkZWZpbmVkLCBhbmQgdGh1cywgdGhleSBjYW5ub3QgYmUgdXNlZC4NCg0KU2hvdWxkIEkg
cHJlcGFyZSBWOCB3aXRoIHRoZSBjb21tZW50IGZpeCwgb3IgY2FuIHRoaXMgYmUgY29ycmVjdGVk
IG9uIA0KY29tbWl0Pw0KDQpCZXN0IHJlZ2FyZHMsDQpMZW9uaWQNCg==


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:05:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:05:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111582.1460245 (Exim 4.92)
	(envelope-from )
	id 1uuTKN-00082p-Qk; Fri, 05 Sep 2025 10:05:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111582.1460245; Fri, 05 Sep 2025 10: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 1uuTKN-00082g-NO; Fri, 05 Sep 2025 10:05:55 +0000
Received: by outflank-mailman (input) for mailman id 1111582;
 Fri, 05 Sep 2025 10: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 1uuTKL-0007UD-SO
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:05:53 +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 e815086c-8a3f-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 12:05:53 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-afeec747e60so354193166b.0
 for ; Fri, 05 Sep 2025 03:05:53 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b046aa92242sm589136366b.59.2025.09.05.03.05.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Sep 2025 03: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: e815086c-8a3f-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757066752; x=1757671552; darn=lists.xenproject.org;
        h=content-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=nvL7dCg6gz41KLkkd+Vk+H26Dav9pYh+JfZNG4PSTr0=;
        b=gUycLGnAA+6cGM73AS2MVGb5JJXjiPq4uJRmbFMCavHi0AXqUB9TONaPSNlGdpQ5Xk
         Yc4hwhUZ0EqZ/5qnjQ23truSthRd0qOPcKAn2vIa2/aFpD2f7yvtJfHn5ezmIdfYY6Yg
         GstCt+EKyC7XoLnC8G+tmJOoh3f03eIoA4tFg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757066752; x=1757671552;
        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=nvL7dCg6gz41KLkkd+Vk+H26Dav9pYh+JfZNG4PSTr0=;
        b=vlzqIXliilw+94z3olcKROrGlSGA/ziSm2uuoGT995O4EhSoJshreZYgs4c/Gp0nIF
         d1HcZhrqHLvk86PT1o2URzOgR5hTV3YC0ner2sBWeXo1FMQV87kqem98P99SLHjHuciF
         29EBAxOMoQ34Gm3pYIVUM/ybdE+rheIJwFaFCheCNTpqGIQo7VMrsqAQs5MF0Ai3lyzJ
         uf5dHSfW9sokNKKji5xkY4ZajRPohiW67mgF7DxbLy9FeRVo+S/ZE6H0xYELaSC5PyeF
         Q5Fsdq2zhdQYRgq7Iyw14lLdeyfABWJTrtATXlbAdS3//21qckpuYKXPWVG6FYC6Af2k
         uofQ==
X-Gm-Message-State: AOJu0Yx7Vvu9xMoSSrx4IVTeh/r9iwb4W1mL1uZNeZfh+/aLvQw8rBB+
	S0Tu47EgB9e13wE1j7+9Z6jagbT1Lfuypp5tsAWA7p4YsJIa8V9c39rGxWBR7J/e5A9kJUXa08l
	NYFRc33g=
X-Gm-Gg: ASbGncvZ0fFxXK8J0KwUBAqRt6/s8cmOzPb5zsV94tkGj1riosx+bLiPkYABsJzPU6G
	7Noyo9nB46L2/F+kIddhOBWPmy7zbKw893BaX6jMc9+/gKBiViBeLbu2BBbmdcp7Fk6MCKu6AD/
	4+mGsbQvv7iOXO3S+iRcBXA/ICgoITUDT3T+zo9AnIyeeIfAdKCSOFOOgtImaIck+FbKaep6LVe
	esfJcc6Qv2pX9OWAjqgeSaDUYBAm1o4pOYXE0wWNbKSe8yHR2u87DFcB8rwMFgElUgKTIrA7JgZ
	Th3qJESnnErGHpae29dlhVASgrNjuACzj8omfrXa21XY3YnGIFV7syNb1FC0GfLNMgv2+zwpJAa
	/tB6xyxMgtMq0B7hwufUtzb9szeak/0Y9PMTdKK4570/1cXYB0fykm4Xs
X-Google-Smtp-Source: AGHT+IHxVphbpBuI4g2ZTf16WcGhGFm1UvYvPW/G3/Q2xyoOu6/oo/ZQyapkcieYrWlN1utMsOAxJQ==
X-Received: by 2002:a17:907:9406:b0:b04:4aa9:eec8 with SMTP id a640c23a62f3a-b044aaa4b0cmr1412828666b.17.1757066752259;
        Fri, 05 Sep 2025 03:05:52 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Ross Lagerwall ,
	Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 1/2] efi: Add a function to check if Secure Boot mode is enabled
Date: Fri,  5 Sep 2025 10:05:31 +0000
Message-ID: <12c18a6d0c3cbbe17cee19f9fb4501d614c23ec3.1757066332.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

Also cache it to avoid needing to repeatedly ask the firmware.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Gerald Elder-Vass 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 

v3:
- Fix build on ARM
---
 xen/common/efi/boot.c    | 24 ++++++++++++++++++++++++
 xen/common/efi/runtime.c |  1 +
 xen/include/xen/efi.h    |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e12fa1a7ec04..e7e3dffa7ddc 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
                    " last line will be ignored.\r\n");
 }
 
+static void __init init_secure_boot_mode(void)
+{
+    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
+    EFI_STATUS status;
+    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;
@@ -915,6 +937,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 42386c6bde42..30d649ca5c1b 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -41,6 +41,7 @@ void efi_rs_leave(struct efi_rs_state *state);
 unsigned int __read_mostly efi_num_ct;
 const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
 
+bool __ro_after_init efi_secure_boot;
 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 623ed2ccdf31..723cb8085270 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -36,6 +36,8 @@ static inline bool efi_enabled(unsigned int feature)
 }
 #endif
 
+extern bool efi_secure_boot;
+
 void efi_init_memory(void);
 bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
 bool efi_rs_using_pgtables(void);
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:05:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:05:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111583.1460255 (Exim 4.92)
	(envelope-from )
	id 1uuTKP-0008Jg-7q; Fri, 05 Sep 2025 10:05:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111583.1460255; Fri, 05 Sep 2025 10:05: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 1uuTKP-0008JX-4D; Fri, 05 Sep 2025 10:05:57 +0000
Received: by outflank-mailman (input) for mailman id 1111583;
 Fri, 05 Sep 2025 10: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 1uuTKN-0007UC-Ul
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10: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 e8b27d3d-8a3f-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 12:05:54 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b042cc39551so350006966b.0
 for ; Fri, 05 Sep 2025 03:05:54 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b046aa92242sm589136366b.59.2025.09.05.03.05.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Sep 2025 03: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: e8b27d3d-8a3f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757066753; x=1757671553; darn=lists.xenproject.org;
        h=content-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=jFZPIyv8H4QpNXncD0fLMakmtwdcF6geMMtEdUBtCi0=;
        b=iqnWYmtZM9StToG99kxQA8XvqSwssKTkX0YqXbHor56a+6SalalQkwyOo3RoBJBglC
         Q8EOEU4SmAq42XLbKjbssUt31o9Q8BSmGJ3he1Nwq75rcbnp1fmm6ymaVhQs0pTJfhqF
         CA08cBRRkjsBjijk1mfS2vabRWgoAtsE1YC/o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757066753; x=1757671553;
        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=jFZPIyv8H4QpNXncD0fLMakmtwdcF6geMMtEdUBtCi0=;
        b=qtSJhGUhRcwTIJtFmH5ncL/w09VeoaVe8LnrykoJqhTwgKx6FEMsQKf9ZECL2CJ6Bb
         ZIC62kKQfxSuKzlM0qSJVuGfT6wbRDc0n973Y5btNzYeZEMDwBDJi0EUKs5gkP3uEcHm
         qCcb9we9qNSI3OkKYx8t0PIEVYYh9XfUu2Os8OAt8MVN/JdgJJzIM9sz5MPzSL48mwcL
         Ripb/brPQfTbCGJBew/BnJCBCXHLxmWEKEte7BPC46dwPUzj8Ou/gLKbYqHIyjV36uOt
         XWAVj9C/YT9gJj7J/tMgzvXFnLr9XyFoivCT7UZXAlPBSaLxqxVeR6Px8dGLOkAjbqJG
         BI6w==
X-Gm-Message-State: AOJu0YxGHWiiC507u4kTFS8O/YyCSGR4liwj60qDtM4582oDKzeRLPsp
	NKL5o2w14onjmzRuRZWml6Gfyeni2DeyuLXCB5/NWLgelcf+9i/dK26XQEPisr7raezmh/43FUs
	13B6OjrE=
X-Gm-Gg: ASbGncuavkKWpM1PPkW1Lmuc+Q636NFmzzJoAOzkagbgGq2yFxiJ5rhRwny0kw1vYO7
	UykTxBNTehhkAUIW5AL9R4o7W5FzvFYFpzxKw1hIu5izqZwo/SseVKXtP7ouTxkG/yC5dYzk7zx
	VW3J5VcAUhhc5WA1IBBmA9EvdF8M+fVeoHJIRq6oRxGJsaP6EW6NX8C1ZXpMOPejDuqkoM4Uw9x
	BjbRD/ZYcmyvXSOOC3pgytQbSD3aMcz6HifI+vUxXiWMD6amFOh4oE0/KXJepzsLyxIm3LxulRn
	HVQuGfIJ+ov2VnwIpFIz0ki5eFu1umREBh86SlPlShjNWd5M1cj0/kgP/AvKNUCf8zNrk3wWE5S
	SNIUXFPKuHZNJpooJI8vkNS9O9N5LmCjvHbDo+JhS48I8lleeIiW3xQw4
X-Google-Smtp-Source: AGHT+IH1uJXgc+Og0UAYVQaB/CKdTRswzWM/Ns9vG0UwIwswegVos1qeIoJ7Tku7FNeKt/rXmG0zfA==
X-Received: by 2002:a17:907:720d:b0:b04:5a68:8686 with SMTP id a640c23a62f3a-b045a688d92mr1293084266b.4.1757066753266;
        Fri, 05 Sep 2025 03:05:53 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	Kevin Lampis ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 2/2] efi: Support using Shim's LoadImage protocol
Date: Fri,  5 Sep 2025 10:05:32 +0000
Message-ID: <7f4a47d5dacf5b2db2ddd2ac72c5e0f236f9be46.1757066332.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The existing Verify functionality of the Shim lock protocol is
deprecated and will be removed, the alternative it to use the LoadImage
interface to perform the verification.

When the loading is successful we won't be using the newly loaded image
(as of yet) so we must then immediately unload the image to clean up.

If the LoadImage protocol isn't available then fall back to the Shim
Lock (Verify) interface.

Log when the kernel is not verified and fail if this occurs
when secure boot mode is enabled.

Signed-off-by: Gerald Elder-Vass 
Signed-off-by: Kevin Lampis 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 

v3:
- Use Shim Image by default, fall back to Shim Lock
---
 xen/common/efi/boot.c | 59 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e7e3dffa7ddc..1f63473d264d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -38,6 +38,8 @@
   { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} }
 #define SHIM_LOCK_PROTOCOL_GUID \
   { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} }
+#define SHIM_IMAGE_LOADER_GUID \
+  { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} }
 #define APPLE_PROPERTIES_PROTOCOL_GUID \
   { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} }
 #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
@@ -70,6 +72,13 @@ typedef struct {
     EFI_SHIM_LOCK_VERIFY Verify;
 } EFI_SHIM_LOCK_PROTOCOL;
 
+typedef struct _SHIM_IMAGE_LOADER {
+    EFI_IMAGE_LOAD LoadImage;
+    EFI_IMAGE_START StartImage;
+    EFI_EXIT Exit;
+    EFI_IMAGE_UNLOAD UnloadImage;
+} SHIM_IMAGE_LOADER;
+
 struct _EFI_APPLE_PROPERTIES;
 
 typedef EFI_STATUS
@@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
     return gop_mode;
 }
 
+static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
+{
+    static EFI_GUID __initdata shim_image_guid = SHIM_IMAGE_LOADER_GUID;
+    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
+    SHIM_IMAGE_LOADER *shim_loader;
+    EFI_HANDLE loaded_kernel;
+    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
+    EFI_STATUS status;
+    bool verified = false;
+
+    /* Look for LoadImage first */
+    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
+                                           (void **)&shim_loader)) )
+    {
+        status = shim_loader->LoadImage(false, ImageHandle, NULL,
+                                        (void *)kernel.ptr, kernel.size,
+                                        &loaded_kernel);
+        if ( !EFI_ERROR(status) )
+            verified = true;
+
+        /* LoadImage performed verification, now clean up with UnloadImage */
+        shim_loader->UnloadImage(loaded_kernel);
+    }
+
+    /* else fall back to Shim Lock */
+    if ( !verified &&
+         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
+                                           (void **)&shim_lock)) &&
+         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
+        verified = true;
+
+    if ( !verified )
+    {
+        PrintStr(L"Kernel was not verified\n");
+
+        if ( efi_secure_boot )
+            blexit(L"Failed to verify kernel");
+    }
+}
+
 static void __init efi_tables(void)
 {
     unsigned int i;
@@ -1334,13 +1383,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
                                       EFI_SYSTEM_TABLE *SystemTable)
 {
     static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
-    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
     EFI_LOADED_IMAGE *loaded_image;
     EFI_STATUS status;
     unsigned int i;
     CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL;
     UINTN gop_mode = ~0;
-    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
     union string section = { NULL }, name;
     bool base_video = false;
@@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
      * device tree through the efi_check_dt_boot function, in this stage
      * 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 )
-        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
+    if ( kernel.ptr && !kernel_verified )
+        efi_verify_kernel(ImageHandle);
 
     efi_arch_edd();
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:10:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:10:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111620.1460265 (Exim 4.92)
	(envelope-from )
	id 1uuTOX-00029i-NO; Fri, 05 Sep 2025 10:10:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111620.1460265; Fri, 05 Sep 2025 10:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuTOX-00029b-Ke; Fri, 05 Sep 2025 10:10:13 +0000
Received: by outflank-mailman (input) for mailman id 1111620;
 Fri, 05 Sep 2025 10:10:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuTOW-00029V-23
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:10:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuTOV-007tRl-1C;
 Fri, 05 Sep 2025 10:10:11 +0000
Received: from [2a02:8012:3a1:0:9f:253:13d3:5d9d]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuTOV-00Gs9s-16;
 Fri, 05 Sep 2025 10:10:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=SOfyh9JD2Fcl6HSxOt3lF99rAao8mJmQTxYNdIE8CvI=; b=BBa0WkEMF80NurcmZV90qlxIrb
	PlKWZzBEKSTWblj9v3WPxion7gdcUMHilAZ/BqttlVBBmI/Nb0JN1GCNYt591qww2IZlU0gfCcrZ9
	pBC/e6NlA0Sl4nvdf4HhxFR38frdsVr971LynJ127Vvijd+FvORiHycsk/v0EBl/47C0=;
Message-ID: <3ffc2a0e-b8f8-4e89-833b-8308dcdb8fbf@xen.org>
Date: Fri, 5 Sep 2025 11:10:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
 <3a487f5c-0837-46b4-ad17-410a4a4bc78a@xen.org>
 <00bfaf5c-c502-4792-a426-015f72dfc2db@epam.com>
From: Julien Grall 
In-Reply-To: <00bfaf5c-c502-4792-a426-015f72dfc2db@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 05/09/2025 11:05, Leonid Komarianskyi wrote:
> On 05.09.25 10:10, Julien Grall wrote:
>> Hi Leonid,
>>
>> On 04/09/2025 21:01, Leonid Komarianskyi wrote:
>>> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/
>>> asm/irq.h
>>> index 5bc6475eb4..2ff2d07d6d 100644
>>> --- a/xen/arch/arm/include/asm/irq.h
>>> +++ b/xen/arch/arm/include/asm/irq.h
>>> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>>>    #define SPI_MAX_INTID   1019
>>>    #define LPI_OFFSET      8192
>>> +#define ESPI_BASE_INTID 4096
>>> +#define ESPI_MAX_INTID  5119
>>> +#define NR_ESPI_IRQS    1024
>>> +
>>>    /* LPIs are always numbered starting at 8192, so 0 is a good invalid
>>> case. */
>>>    #define INVALID_LPI     0
>>> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>>>    #define INVALID_IRQ     1023
>>>    extern const unsigned int nr_irqs;
>>> +#ifdef CONFIG_GICV3_ESPI
>>> +/* This will cover the eSPI range, to allow asignmant of eSPIs to
>>> domains. */
>>
>> Typo: s/asignmant/assignment/
>>
>> [...]
>>
>>> Unless INTIDs from the eSPI
>>> + * range are mistakenly defined in Xen DTS when the appropriate
>>> config is
>>> + * disabled, this function will not be reached because is_espi will
>>> return
>>> + * false for non-eSPI INTIDs.
>>
>> I am still confused with this paragraph. How is this function can be
>> reached if it is compiled out? Surely, if the DT is misconfigured, we
>> should get an error when trying to route the interrupt. No? If so, can
>> you point me to that code?
>>
>> Cheers,
>>
> 
> Oh, sorry, the second part of the comment is redundant with the current
> implementation. It was correct when the function had an implementation
> and returned NULL. The correct comment is:
> 
> Defined as a prototype as it should not be called if
> CONFIG_GICV3_ESPI=n. Without CONFIG_GICV3_ESPI, the additional 1024 IRQ
> descriptors will not be defined, and thus, they cannot be used.
> 
> Should I prepare V8 with the comment fix, or can this be corrected on
> commit?

I should be able to update it while committing.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:27:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:27:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111645.1460275 (Exim 4.92)
	(envelope-from )
	id 1uuTfa-0004fV-4v; Fri, 05 Sep 2025 10:27:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111645.1460275; Fri, 05 Sep 2025 10: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 1uuTfa-0004fO-15; Fri, 05 Sep 2025 10:27:50 +0000
Received: by outflank-mailman (input) for mailman id 1111645;
 Fri, 05 Sep 2025 10:27: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 1uuTfY-0004ek-A3
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:27:48 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f533653a-8a42-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 12:27:43 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by AM9PR03MB7217.eurprd03.prod.outlook.com (2603:10a6:20b:26d::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Fri, 5 Sep
 2025 10:27:41 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.017; Fri, 5 Sep 2025
 10:27: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: f533653a-8a42-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CZbEINSlfnAJR2A8TlseX7rD0GrcvF63FPJ/c58KrW0TqoIL0ksg4Ezwa6X2JpO7/rSHWnldmjRkpVuvPO74I6aKwq47zH/CRsWqHv5dki3KsQ0rr/6v7RMdNI7KHgVNESraTeSERrrAh13AbsOAtBnJ818FtIqaVwD9Aq4BpvliMGHQoCUzqchPhhXeIzFGi1iv9HsUo0Rku+0O0mmIwjLRvjDSzZVsNG+kp+N4NaF5GfAmFm5O0AG5oU+PioP9JqBYYALgomO9qV1DUdII2zrDHVA/6jIXXzo21agE5BAdZrtOQICkry2zkQD6UkHvKBob1578fObp4AVE986BDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SyaXlZlue/VSvNKKuFYSywkqSORzXhWatkdZNX0Rm1A=;
 b=Bz+G6QWjzRtGv/bQam+5w0WLk0Md5HOi+zQN849J742A64RxgLXyP8ZRxnX6nsqoZRc2WlgUZXulUClbjiBiVVEfRTFdPAgS1Xo+DO4Mza/o5ZPw1cDb86B2p1y5guUGQDCRwVj1hYjwVI3yXq8kfK0Q7IK4jL5iaHf7llnTP2ByvkWw1VrmJIGt+GIYxFhvLacjxbeBktSvGf3Fs4xnf15mnV88KuFx226yqs1ntr7lwyR62G49R8QHY0vnFinl9MY27NVI+4u4DiGCqSedxrAwgpW0v+QzXOUpdbsq8nxoR260RKvOEHkq8nhM7whHqFexsLdzB8ZwSJSONTxaPw==
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=SyaXlZlue/VSvNKKuFYSywkqSORzXhWatkdZNX0Rm1A=;
 b=m6OCxWC+kBghuQXwV8EWoBmt06ZmeZpwXyikmKFmrV3j7UXwc7lSp/vakSPdThHHxwQRXXeJwu8/06KbeGu2JJ+RxnN1Q2F0VooPWRMhQpLgNgJxqxvjOowQQlyOUeYDZE7UzZU4GNiLq5l7ADszK/e0mIdCyLZydSk/mNJ2LOvc/8NzQJiKtPVrXEOcilTMXHTHddS1TC1Y6BVXxBvZlbcERKnkHBn0z0NtG20g+rzatuqqSC8OXy7re4NrO4xfCfOL/zVgh4dd9V10nl9NcdCxoI5TAQPukX4Q0P6JyFYoXSJGlnhY3h7G6QeWydheiGtnRY3GLSk1KZRm/lk42Q==
From: Leonid Komarianskyi 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: "olekstysh@gmail.com" , Stefano Stabellini
	, Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk ,
	Oleksandr Tyshchenko 
Subject: Re: [PATCH v7 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Topic: [PATCH v7 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Index: AQHcHdazISYJ96ARO0ihPlIvp7RWE7SEMBaAgAAzpgA=
Date: Fri, 5 Sep 2025 10:27:41 +0000
Message-ID: <0843182f-2299-4942-b8f3-339b1f13db6f@epam.com>
References: 
 
 <820704d0-4047-4f02-a058-01daba2765f1@xen.org>
In-Reply-To: <820704d0-4047-4f02-a058-01daba2765f1@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: GV2PR03MB8678:EE_|AM9PR03MB7217:EE_
x-ms-office365-filtering-correlation-id: 25b7685d-1c47-4175-c501-08ddec66d804
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?NXBzTENqVTdCdFFHdHZpL2hoTHBkSHdYaG03WjJhSzROaXFzbkNyUGVwWk92?=
 =?utf-8?B?RElZckwrODJpN0xZN3hnanl2Umh3M2RkRElYbXZsUFRESGVweHdNbEFqZXhC?=
 =?utf-8?B?WDRLZzZnZGtnUklsTmpoUGpQM0xxZGxhZGZaZk9uVU5QN0RtSXovMlJYaENF?=
 =?utf-8?B?akN4WmJySEQwQVJDT3h6OVpVcnhuc1pZTlJ4dXB2S3pnRTJCdjU3YnU0Unha?=
 =?utf-8?B?YUNCSE5hZ0FrZkhpRHpISXVXaEo2TEVpN0xudm53SFlqU2FDalc5MnJ6ZTlj?=
 =?utf-8?B?OWlGQXZpbVF5WGpHckNNWWpmOHVOSlBGcmhxRmdXZ25zdVZkYWtsckVOU1BK?=
 =?utf-8?B?SW9Ea2VaMDFlNXlaSmhkSHlhSW1ONmVrcGNwcThlMEZEQnl2UTZNdHEyRWZZ?=
 =?utf-8?B?QUtSV2haNHIvRFFMc3M5cXFCSGpjRjZuZ1UwRk9veEhFVURZNnBoNXB5NDRj?=
 =?utf-8?B?L2MwcWQwUXUrd0JSc3JWN2hmaytMUnQyaE9PUW1uQkFub1ovWkNYVUc0a3pa?=
 =?utf-8?B?OTF2cmR5U0tOL2ZOaHZwcUZBQUU0em9pdm82c2ZNZUV4cUhjNUJySVJGTU1V?=
 =?utf-8?B?RzVQNEZIdVUwOHRuUGQ5SGowenFWUWNGdzZONjFPdEg5SWY3M0xXUldDMDhG?=
 =?utf-8?B?a2VINVhuTmlzWnVIY1lHVVVabjltaW02dG9JbStmWmJ4RURWKzVQR01hVUZs?=
 =?utf-8?B?RXN6YmxaclZ0YVJ3akRKMWpkQW1MSlMzZnJFN09Lcys0Z2F1M3dWejBycWRM?=
 =?utf-8?B?Vm05dzZvWmhhTjMzdUMwVkdiSlE3MWVKME1SNzVTWkFzaGZGSlJJRW13M21T?=
 =?utf-8?B?SWdMZ2lDdWRva2hLMmRzSWoxK0RzaW5pSC9nOCt3L0pPa3FJMTZCNFNreUsy?=
 =?utf-8?B?M1RKOXl3eWVtNWlWT09rbVJkbjRrcERXd2hRT2ZXRGozTHdYSytueko2L0Q0?=
 =?utf-8?B?SVAveHVmRHBTZVlCQUxENlR3dGIrYU1NclNFRWR2b1ZGMUJWNUtYMyt5UjRU?=
 =?utf-8?B?Q294UDJuUDEyclhEZWRqY0ZCNDJYTVBHVERscmVhOGxVLzhEb0FUTk9BNnNH?=
 =?utf-8?B?MndJZTFvbERRK2Q5UlRGUVlxNFpQblFNdzIxRVF2U2lOeDVVeUNlMkc0WjRh?=
 =?utf-8?B?SGk0cDZ3azBJTm0wUGVjSHBPWjEzMy9wYzVjZ2szay83dk1yT3lQamhXZSt0?=
 =?utf-8?B?ZzBVSjN5bmhwTE0wcXJuelhIUWVoY243cWo0cUJnTTdVc1ZTd2tPNC80QlhK?=
 =?utf-8?B?eWlpVTM5ZUNieFIzcUxLVEcwdTZOSC85MTBKT2RUUTV4b0srbmRZa2J1c1JD?=
 =?utf-8?B?MWRIbVRhNDU0TEp1T0V2VjVRVUZ5Z3N2R3BQa3c5bEprOEszWWxIZ0IzQmhY?=
 =?utf-8?B?S2ltZHU4Ky9yMXVlYnF2Z096R1VxTGMwOXN4V2dUQ0I0TW5jeU4zOUNtMkw3?=
 =?utf-8?B?bTVzbnR3RkZiVGxVSTBHMzlRdmxoTm9JaUR1VDJ2cVRTcFJWN1Raa25jRUw0?=
 =?utf-8?B?K010VjU3VWVwYTJDbWxWVzNxWDE1ZXFUVDRmSWJFZVR0M0s5NklEcGhTODF0?=
 =?utf-8?B?amtkcU4wZ0FmY05oWXNhV1k3YVdtNW1URVhoVHdWZGFXRG5KSWhQek9QWmFB?=
 =?utf-8?B?M3RUQmZ1bHlaQU5jMEl2Z0ptVE8vTEhCUzVqL3JlWkdUejgwbSsvRG00bHFO?=
 =?utf-8?B?cEhLUXJSczFYZTRselZaWmFyNWNPWForbjZVZGhEMUF0RHVlL2lHTFRiTHM0?=
 =?utf-8?B?RGRVNmhDQVBGQmVYMFFGTGZCcWtPTll5Z1ZkdkRielIrRnlhZFVrb0tCeXNW?=
 =?utf-8?B?UEFBTHNUKzhLUmM2dmsxYmtSTU1RRkp2ZlpKd2dVdmYvdnkrZWU2ZXpqdG5n?=
 =?utf-8?B?NUZ0bTQzYVBtb0w4RklRelJOUUVsYkl3bnJmMlIyNWpBTEg3cXFnYUNZTlhE?=
 =?utf-8?B?SXkyVG53UFltL2RuaENyZXVLaWJiUDNqMmtBaXNOVXBWZlMwTUEvaEVsVkh5?=
 =?utf-8?B?TUJKN3NDeDRRPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.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?ZHBlVHVibEhlcWtCNzZFa0lzSkpzQXZ0TEUwRkt4dUYrOFpkMkRXRTZkc1Z4?=
 =?utf-8?B?eVozeWw1LzRHMURmRkl1UUxHd3Y3RU9CSHlSQzRnOWdNMXZ3WllxUkR1NWJz?=
 =?utf-8?B?dkNQMzZIU3dBdmw0RlUrLy8wQjhoZTBuUXAvZW53anNNNVVJejYrNkRDWnNT?=
 =?utf-8?B?MU1sQW9kc216dTNiczllVDlwZk9DM2RtWjR3RUQrb0tZN2tPeVJLTVRQcEtT?=
 =?utf-8?B?b3NMYWtyQVBRbEhEOUVIN2tKeWF3TllxQ2VZMzVwd1dGSjVvMjNlLzlkblFy?=
 =?utf-8?B?TE1GcUVwaXBqbUhJYmpvVUdLczViUlUvVnJQQ2dYYllBcUJsMjRJcjRBMk9y?=
 =?utf-8?B?VzFnU09PdktGSVN4NUNTS05hYWV6L0ZmSUFGb0VkUW5SWWpLTlNTeDdYREVs?=
 =?utf-8?B?cWtVNUtHRThQOU1iT0lmaFphS2kyaXFNZjgwUDZZZE9qSS9XcGFBa0hqMmd5?=
 =?utf-8?B?OWVmVS9qaDI1ampucVJvQUttVEYzN01nS1lFQnhpRmxCUG41dTNpSlJackRo?=
 =?utf-8?B?VnByWThiN1NMVUdlY1NBRjhreTF1em01a3hma3lheDM1by8wZzJWNnFLcVNt?=
 =?utf-8?B?UGJzRVlkZmVaY05HY2ZsSUk1QmpPZWRLdUhJVm13bWZNUGFQKy9xNHl0cXJ2?=
 =?utf-8?B?eWRYWXEzbDlsVjZRR3FWTGJ4YXp2MmxjcVVuMkpTREVWZGp4YlA2L2NmL01s?=
 =?utf-8?B?ZmxFQjNYc3A4OENqNVVxUHNTSHl0SXdMTmRHRkpuajhUOWJBdWVDdzhDa0Y3?=
 =?utf-8?B?VDJyaXZpakhrR0dUVXZrdUNmYlgrZUZqT3ZxclhYYjJNK1BqMG9vTnI2MWFx?=
 =?utf-8?B?a1hpbGpQQllCWEdKWGNQRURBZWF5YXJTd2EwbFBVZ2ZGcExjaXJBaUVncjhY?=
 =?utf-8?B?ZG5uZlMwZFRvVFMvTDhJeElXSkQxcEpLdXkveVYrbEtBSXJSNU5rMSt4aUhJ?=
 =?utf-8?B?UUlJMTZjYTNGaTdZejZBY1F4eFRhSDQxMitPd0oyaituNGsyRjZlTGc3ZHZ0?=
 =?utf-8?B?MFh6QnVkeDZaZzlYRTY2WFlXR2FyUWxBeTFKcDhsZTJKUTNDRDF6SmlNd254?=
 =?utf-8?B?RVpRWGJvdTdkQTFlUmwvcnZZMXBMVGlUVUx4bG5WRlhQdmFDYnhnUTRqVU1u?=
 =?utf-8?B?VHgybVZOTlNDL25kUXF2R3FqM29lK1M5cVpmRWhTd2R0L3N5QmxFVFdpdkdL?=
 =?utf-8?B?UkFrV0JEUzRDUFhKeHJMenBZOWVCSnNXNnU3QUE2ODlvcnpIRW1Eb0F4RU43?=
 =?utf-8?B?czdWU0FzYWtlWWxOQlo1QkRlOVNiRmdTQUNHVG9CSHhUU3JTWGV2VmVQZmk0?=
 =?utf-8?B?VVpSaDBqdEVHOFlCOGR2Mi9QQkhSYzVXamhyaXFRc0k3a2xyaW5kUG9Oa3JC?=
 =?utf-8?B?L1lzRVl1R3RzSWIvRWVsTmMrb3VRSi9qU2tNNVFxZ1lBWkNFZENqMlpQUjVV?=
 =?utf-8?B?bHF2KzBVSUNFRTM1OUoycHAvYmJ0VXR5c0NocXBNeHJRWDZtRHZ4UFZYUjE3?=
 =?utf-8?B?cEd3dXFZSmlPem5wU244cmRpbnp4VXYxS25zSkNqYWhTUkIyZmk1Vk91Mkw4?=
 =?utf-8?B?SVRpdWNnb1pUbzN1N0g1YkdaZUhHOWlQa0N1WWxhRktEd3pSUFBFUW5PaGlK?=
 =?utf-8?B?YU92eUNaYU41dU1zMnp1T3JsM0N2ZHkwc3NMVGVCa1cwaWVDcjFtMkxRY1Zy?=
 =?utf-8?B?cE5hZzc3NWtlc2lXVmMzOTl6MCtKMnVuK3E5bHY0bkNPbS9pSWFkQUtyTEdR?=
 =?utf-8?B?TWcvSXpOQXpWV3RGanJ6ODhFQ1hHR3lxV2hnZU9MVGZvZ3BRWDJuYWs2MzUw?=
 =?utf-8?B?WWc0cGMvSTIrVHk4ZmM3Y2ZaNjh3VGM4UEU0TVNocVpTSUFKRGVOVzNNeitD?=
 =?utf-8?B?RFhjVkdPNUhWUFA1RW42ZCtSOFVvK2J1YXRGSWQzQzVJVUdGdWl2dHgwNzAr?=
 =?utf-8?B?OS81TFBSVTZRMmd0S1hzUVRhc2JxVmRQVFVlOU9Ec3lvdVUxRXptTDRSU0VW?=
 =?utf-8?B?eDM4Z2FpR3FWVzgrWWJsVWVJVlFDWVQ4TEY1eERSajBnYnpzUWphZFFOTGx4?=
 =?utf-8?B?ZWNRQTFyQkNOU1JFaTVISE83NmQreDFFVFI0QlFJS2xidFZ6STl1MStIc2tu?=
 =?utf-8?B?aDFQRkFQeWxYK0RQUElMeUhKTFRFSTNETmJrL29wL2pIdXl3bFFBZEF0YURD?=
 =?utf-8?Q?okTAeazcvpOYIXgXFNCuDp4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <45812AF33532C54E8A7D5D4D399596F2@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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25b7685d-1c47-4175-c501-08ddec66d804
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 10:27:41.1201
 (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: xKV1JlmG0f/ZI2rWHU3dRT4ckUZiozu+YrvIYHbejBj7sVg1N7Jam31rU5WkKZ6jaKWYhnrp0pZN3VcWAOyF4+lx3kVB9NSdjk5vfGW0/eo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7217

SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgYW5kIEFCLg0KDQpPbiAw
NS4wOS4yNSAxMDoyMiwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiBIaSBMZW9uaWQsDQo+IA0KPiBP
biAwNC8wOS8yMDI1IDIxOjAxLCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0KPj4gKyNpZmRl
ZiBDT05GSUdfR0lDVjNfRVNQSQ0KPj4gK3Vuc2lnbmVkIGludCBnaWNfbnVtYmVyX2VzcGlzKHZv
aWQpDQo+PiArew0KPj4gK8KgwqDCoCByZXR1cm4gZ2ljX2h3X29wcy0+aW5mby0+bnJfZXNwaTsN
Cj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9jb21t
b25faW5pdCh1aW50MzJfdCB0eXBlKQ0KPj4gK3sNCj4+ICvCoMKgwqAgdW5zaWduZWQgaW50IGVz
cGlfbnIsIGk7DQo+PiArDQo+PiArwqDCoMKgIGVzcGlfbnIgPSBtaW4oMTAyNFUsIEdJQ0RfVFlQ
RVJfRVNQSVNfTlVNKHR5cGUpKTsNCj4+ICvCoMKgwqAgZ2ljdjNfaW5mby5ucl9lc3BpID0gZXNw
aV9ucjsNCj4+ICvCoMKgwqAgLyogVGhlIEdJQyBIVyBkb2Vzbid0IHN1cHBvcnQgZVNQSSwgc28g
d2UgY2FuIGxlYXZlIGZyb20gaGVyZSAqLw0KPj4gK8KgwqDCoCBpZiAoIGdpY3YzX2luZm8ubnJf
ZXNwaSA9PSAwICkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm47DQo+PiArDQo+PiArwqDCoMKg
IHByaW50aygiR0lDdjM6ICVkIGVTUEkgbGluZXNcbiIsIGdpY3YzX2luZm8ubnJfZXNwaSk7DQo+
IA0KPiBTdHlsZTogbnJfZXNwaSBpcyB1bnNpZ25lZC4gU28gaXQgc2hvdWxkIGJlICV1LiBDYW4g
YmUgZml4ZWQgb24gY29tbWl0IA0KPiBpZiB0aGVyZSBpcyBub3RoaW5nIGVsc2UgbWFqb3IgdG8g
Y2hhbmdlLg0KPiANCj4+ICsNCj4+ICvCoMKgwqAgLyogVGhlIGNvbmZpZ3VyYXRpb24gZm9yIGVT
UElzIGlzIHNpbWlsYXIgdG8gdGhhdCBmb3IgcmVndWxhciANCj4+IFNQSXMgKi8NCj4+ICvCoMKg
wqAgZm9yICggaSA9IDA7IGkgPCBlc3BpX25yOyBpICs9IDE2ICkNCj4+ICvCoMKgwqDCoMKgwqDC
oCB3cml0ZWxfcmVsYXhlZCgwLCBHSUNEICsgR0lDRF9JQ0ZHUm5FICsgKGkgLyAxNikgKiA0KTsN
Cj4+ICsNCj4+ICvCoMKgwqAgZm9yICggaSA9IDA7IGkgPCBlc3BpX25yOyBpICs9IDQgKQ0KPj4g
K8KgwqDCoMKgwqDCoMKgIHdyaXRlbF9yZWxheGVkKEdJQ19QUklfSVJRX0FMTCwNCj4+ICvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBHSUNEICsgR0lDRF9JUFJJ
T1JJVFlSbkUgKyAoaSAvIDQpICogNCk7DQo+PiArDQo+PiArwqDCoMKgIGZvciAoIGkgPSAwOyBp
IDwgZXNwaV9ucjsgaSArPSAzMiApDQo+PiArwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCB3
cml0ZWxfcmVsYXhlZChHRU5NQVNLKDMxLCAwKSwgR0lDRCArIEdJQ0RfSUNFTkFCTEVSbkUgKyAo
aSAvIA0KPj4gMzIpICogNCk7DQo+IA0KPiBTb3JyeSBJIG9ubHkgc3BvdHRlZCBub3cuDQo+IA0K
PiBUaGUgZ29hbCBvZiBnaWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQoKSBpcyB0byBtYWtlIHN1
cmUgdGhlIEdJQyBpcyBpbiANCj4gYSBzYW5lIHN0YXRlIGZvciBYZW4gKHRoZSBwcmV2aW91cyBP
UyBvciBmaXJtd2FyZSBtYXkgaGF2ZSBsZWZ0IHNvbWUgDQo+IHN0YXRlKS4gTm93IHRoZSBmaXJt
d2FyZSBtYXkgZGVjaWRlIHRvIHVzZSBlU1BJIGJ1dCBub3QgWGVuIChlLmcuIA0KPiBiZWNhdXNl
IENPTkZJR19FU1BJPW4pLg0KPiANCj4gVGhpcyB3b3VsZCBtZWFucyB3ZSBtYXkgaGF2ZSBlU1BJ
IGludGVycnVwdHMgdGhhdCBtYXkgYmUgZW5hYmxlZCBhbmQgDQo+IHBlbmRpbmcuIFNvIGFzIHNv
b24gYXMgd2UgcmUtZW5hYmxlIHRoZSBHSUMgd2UgbWF5IHJlY2VpdmUgaW50ZXJydXB0cyB3ZSAN
Cj4gY2FuJ3QgaGFuZGxlLiBTbyBJIHRoaW5rIHdlIG1heSBuZWVkIHRvIGluaXRpYWxpemUgdGhl
IGVTUEkgcGFydCBvZiB0aGUgDQo+IGRpc3RyaWJ1dG9yIHVuY29uZGl0aW9uYWxseS4gV2hhdCBk
byB5b3UgdGhpbms/DQo+IA0KPiANCj4gVGhpcyBjb3VsZCBiZSBoYW5kbGVkIGFzIGEgZm9sbG93
LXVwIGJ1dCB3aXRoaW4gdGhlIHRpbWVmcmFtZSBvZiBYZW4gDQo+IDQuMjEuIFNvIGZvciB0aGlz
IHBhdGNoOg0KPiANCj4gQWNrZWQtYnk6IEp1bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+
DQo+IA0KPiBDaGVlcnMsDQo+IA0KDQpZZXMsIHRoYXQncyBhIHJlYWxseSBnb29kIHBvaW50IGFi
b3V0IGZpcm13YXJlIGluaXRpYWxpemF0aW9uIC0gSSBkaWQgDQpub3QgdGhpbmsgYWJvdXQgdGhh
dC4gSW4gdGhhdCBjYXNlLCB3ZSBqdXN0IG5lZWQgdG8gbW92ZSB0aGUgbnJfZXNwaSANCmZpZWxk
IG91dCBvZiB0aGUgaWZkZWYsIHJlbW92ZSB0aGUgc3R1YnMgZm9yIA0KZ2ljdjNfZGlzdF9lc3Bp
X2NvbW1vbl9pbml0KCkgYW5kIGdpY3YzX2Rpc3RfZXNwaV9pbml0X2FmZigpLCBhbmQgcmVtb3Zl
IA0KdGhlIGlmZGVmIGZvciB0aGVzZSBmdW5jdGlvbnMuIFRoZSB2ZXJpZmljYXRpb25zIGF0IHRo
ZSBiZWdpbm5pbmcgb2YgDQpnaWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQoKSBzaG91bGQgd29y
ayBjb3JyZWN0bHksIHNpbXBseSByZXR1cm5pbmcgMCANCm9uIHBsYXRmb3JtcyB3aXRob3V0IGVT
UEkuDQoNCkkgd2lsbCBwcmVwYXJlIGEgZm9sbG93LXVwIHBhdGNoIGZvciB0aGlzLg0KDQpCZXN0
IHJlZ2FyZHMsDQpMZW9uaWQNCg==


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:36:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:36:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111671.1460284 (Exim 4.92)
	(envelope-from )
	id 1uuTnh-0006Xl-Rt; Fri, 05 Sep 2025 10:36:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111671.1460284; Fri, 05 Sep 2025 10:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuTnh-0006Xe-P2; Fri, 05 Sep 2025 10:36:13 +0000
Received: by outflank-mailman (input) for mailman id 1111671;
 Fri, 05 Sep 2025 10:36:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuTng-0006XY-Mq
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:36:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuTnf-007twT-38;
 Fri, 05 Sep 2025 10:36:12 +0000
Received: from [2a02:8012:3a1:0:9f:253:13d3:5d9d]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuTnf-00GtMN-30;
 Fri, 05 Sep 2025 10:36: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=JXReLwgsT9ZZj6+RNbLB7uHd+/xhwOST9Y7n2BmkH7E=; b=O4bcbYlMO/IEkQosQIsWbc82oE
	cJDDJjFyIXBqW74Flwen0npq1QyWcbgZFS7AvuwyPYKtThJ0cwGCbva3NVDQw3bImNyNV9l/RnN8I
	/RXxgCA0umHb3JB/M9sh9Qa463vImpGsPjyquJ4koCwoN/FYgQs5AFsKstywPjV28dSQ=;
Message-ID: 
Date: Fri, 5 Sep 2025 11:36:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Content-Language: en-GB
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: "olekstysh@gmail.com" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksandr Tyshchenko 
References: 
 
 <820704d0-4047-4f02-a058-01daba2765f1@xen.org>
 <0843182f-2299-4942-b8f3-339b1f13db6f@epam.com>
From: Julien Grall 
In-Reply-To: <0843182f-2299-4942-b8f3-339b1f13db6f@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Leonid,

On 05/09/2025 11:27, Leonid Komarianskyi wrote:
> On 05.09.25 10:22, Julien Grall wrote:
>> Hi Leonid,
>>
>> On 04/09/2025 21:01, Leonid Komarianskyi wrote:
>>> +#ifdef CONFIG_GICV3_ESPI
>>> +unsigned int gic_number_espis(void)
>>> +{
>>> +    return gic_hw_ops->info->nr_espi;
>>> +}
>>> +
>>> +static void __init gicv3_dist_espi_common_init(uint32_t type)
>>> +{
>>> +    unsigned int espi_nr, i;
>>> +
>>> +    espi_nr = min(1024U, GICD_TYPER_ESPIS_NUM(type));
>>> +    gicv3_info.nr_espi = espi_nr;
>>> +    /* The GIC HW doesn't support eSPI, so we can leave from here */
>>> +    if ( gicv3_info.nr_espi == 0 )
>>> +        return;
>>> +
>>> +    printk("GICv3: %d eSPI lines\n", gicv3_info.nr_espi);
>>
>> Style: nr_espi is unsigned. So it should be %u. Can be fixed on commit
>> if there is nothing else major to change.
>>
>>> +
>>> +    /* The configuration for eSPIs is similar to that for regular
>>> SPIs */
>>> +    for ( i = 0; i < espi_nr; i += 16 )
>>> +        writel_relaxed(0, GICD + GICD_ICFGRnE + (i / 16) * 4);
>>> +
>>> +    for ( i = 0; i < espi_nr; i += 4 )
>>> +        writel_relaxed(GIC_PRI_IRQ_ALL,
>>> +                       GICD + GICD_IPRIORITYRnE + (i / 4) * 4);
>>> +
>>> +    for ( i = 0; i < espi_nr; i += 32 )
>>> +    {
>>> +        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLERnE + (i /
>>> 32) * 4);
>>
>> Sorry I only spotted now.
>>
>> The goal of gicv3_dist_espi_common_init() is to make sure the GIC is in
>> a sane state for Xen (the previous OS or firmware may have left some
>> state). Now the firmware may decide to use eSPI but not Xen (e.g.
>> because CONFIG_ESPI=n).
>>
>> This would means we may have eSPI interrupts that may be enabled and
>> pending. So as soon as we re-enable the GIC we may receive interrupts we
>> can't handle. So I think we may need to initialize the eSPI part of the
>> distributor unconditionally. What do you think?
>>
>>
>> This could be handled as a follow-up but within the timeframe of Xen
>> 4.21. So for this patch:
>>
>> Acked-by: Julien Grall 
>>
>> Cheers,
>>
> 
> Yes, that's a really good point about firmware initialization - I did
> not think about that. In that case, we just need to move the nr_espi
> field out of the ifdef, remove the stubs for
> gicv3_dist_espi_common_init() and gicv3_dist_espi_init_aff(), and remove
> the ifdef for these functions. The verifications at the beginning of
> gicv3_dist_espi_common_init() should work correctly, simply returning 0
> on platforms without eSPI.

I don't think we need all of these. We just need to ensure the 
interrupts are disabled and deactivated. So no need to reset the 
affinity or even moving the field moving the field out of the ifdef.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:36:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:36:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111683.1460295 (Exim 4.92)
	(envelope-from )
	id 1uuToL-00075n-7O; Fri, 05 Sep 2025 10:36:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111683.1460295; Fri, 05 Sep 2025 10: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 1uuToL-00075g-4L; Fri, 05 Sep 2025 10:36:53 +0000
Received: by outflank-mailman (input) for mailman id 1111683;
 Fri, 05 Sep 2025 10:36: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 1uuToJ-0006nu-0S
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:36: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 3ac8c3e0-8a44-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 12:36:49 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3dea538b826so1609855f8f.2
 for ; Fri, 05 Sep 2025 03:36:49 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45dd2df4c8dsm53969085e9.15.2025.09.05.03.36.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 03:36: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: 3ac8c3e0-8a44-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757068609; x=1757673409; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0b/snmQel6GVfLUUnAfLYoIg8AnHVTJIn6Xol2J2nlM=;
        b=saCuCcvlwo6+1PPmelAAvdXtLbOPSvIIX9c+bEqNTr+rVh6JCGlQ+6yp0lW9/1s8NU
         KPLlCe6HDoYul4wd8MpmtvLUWFeL7BQ9uyq6DdZYd4s5uyKgz8bk3+Gd4m84JWR506Qb
         /WgPvMnxKGYtiKXE5+0GCBM8IVnmci4V08u6w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757068609; x=1757673409;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0b/snmQel6GVfLUUnAfLYoIg8AnHVTJIn6Xol2J2nlM=;
        b=deLemWxsw4Jszi6icwKtN2hNG4aEb890XGxahAjhigKUOH+u1ao3X+JRhGjq993usi
         kAmEoJP0PCBK5QLGSsDtBq+k1cfR7L4y+3nESNBM0i7hHo67jlN3ounmJx4q++JVNXuw
         GnxnfH3/hCJwXs55g1XqIPSDCYMrIeM1Xbg6FoNgKcJJsrlQSwuJxQxeT/QU0gNQv1jH
         1Mcd6xjVbISzkU56ZJxitOYc6KBikSwyjHJpK/PxRU/xzvByBjBDmmuY2ECzjd+tIPIt
         q2F7RfLUYumXgasRdm3aNYKft5haMnwHaDyRUShVQDuBZ6q/xLz+hOLxq2Y2qTuF+sYe
         BI2Q==
X-Gm-Message-State: AOJu0YxJTNLostqvR1y0gnTeB08J/MUi0q3XshLFflN0Om6lttQxA1ue
	PyDFMYuRUmKYAG/0TYJlC5TDuzEcE8JW9SZ6BglmXBgrFe2uluYBsiFDsYHBorXfdgDgKBcaO5a
	ghVIF
X-Gm-Gg: ASbGncs5RgEVQO9gApwfzsNoGwnZ7O2VtDRFjv6w5NAEHDEGmQwhbHrqOv1SHLhrklT
	sqHGBP39qaF0RTvK3SpSF5UKHauKbHyMSxRv6fH1rGcZ7AaxI3WSH1OB0J5+ihZ68tz5GFP2jrx
	+IluGaEwkE9cVV9W2C9EyZOoU9zBBCZS4VP6k+YMDRmB94lrquipEsGjf1ADUbuVG8CUdauEjAW
	DOu5l1Hd3rbmYEvlrTwOHScM7+R7Z0WrkBFWlzb9JDfBKgqDZ0rSvKRZHX03F7qefYbMxzI1mB0
	2KdR/KeZEPjMAMRzhPJHZobpF6vUMT2am07EmXWYBjaTdOjSZ/GKeeOSwZuS189gUU1ymlkY5+M
	xZSX6JSq9lF/QNn3KYRAJiaLeiOqDgUqgp+Ule8oUyN2IAJdjvugvX2e2/Es1+CTg7uwJ
X-Google-Smtp-Source: AGHT+IHyU1/v76uEaQ33dRdFEarsypMpUL874bW4ArXsJt36UMJ9N4R4yRH3pyY5PnVKrnhKliTRXw==
X-Received: by 2002:a05:6000:420c:b0:3dc:21a1:8c6a with SMTP id ffacd0b85a97d-3dc21a18ca1mr10187524f8f.11.1757068608735;
        Fri, 05 Sep 2025 03:36:48 -0700 (PDT)
Message-ID: <6940b548-18b8-4507-bb75-617378fe090c@citrix.com>
Date: Fri, 5 Sep 2025 11:36:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [misra] Re: [PATCH v3 1/2] efi: Add a function to check if Secure
 Boot mode is enabled
To: Xen-devel ,
 Nicola Vetrini ,
 Dmytro Prokopchuk1 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Jan Beulich , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Gerald Elder-Vass 
References: 
 <12c18a6d0c3cbbe17cee19f9fb4501d614c23ec3.1757066332.git.gerald.elder-vass@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: <12c18a6d0c3cbbe17cee19f9fb4501d614c23ec3.1757066332.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/09/2025 11:05 am, Gerald Elder-Vass wrote:
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e12fa1a7ec04..e7e3dffa7ddc 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
>                     " last line will be ignored.\r\n");
>  }
>  
> +static void __init init_secure_boot_mode(void)
> +{
> +    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
> +    EFI_STATUS status;
> +    uint8_t data = 0;
> +    UINTN size = sizeof(data);
> +    UINT32 attr = 0;
> +
> +    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
> +                                 &size, &data);

This turns out to be a MISRA R7.4 violation, complaining about casing a
string literal to a non-const pointer.

The real problem here is that the EFI spec.  GetVariable() ought to take
a const CHAR16 *, but doesn't.

We could fix this with:

diff --git a/xen/include/efi/efiapi.h b/xen/include/efi/efiapi.h
index a616d1238aa4..56775d553109 100644
--- a/xen/include/efi/efiapi.h
+++ b/xen/include/efi/efiapi.h
@@ -224,7 +224,7 @@ VOID
 typedef
 EFI_STATUS
 (EFIAPI *EFI_GET_VARIABLE) (
-    IN CHAR16                       *VariableName,
+    IN const CHAR16                 *VariableName,
     IN EFI_GUID                     *VendorGuid,
     OUT UINT32                      *Attributes OPTIONAL,
     IN OUT UINTN                    *DataSize,

but I fear this might get some objections.

I don't think we want to be deviating every use of GetVariable() for a
problem ultimately outside of our control.

Another option would be to have a wrapper for GetVariable() which does
the cast once, which lets us deviate in one place only.

Thoughts?

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:44:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:44:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111696.1460306 (Exim 4.92)
	(envelope-from )
	id 1uuTvX-0000YQ-17; Fri, 05 Sep 2025 10:44:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111696.1460306; Fri, 05 Sep 2025 10:44: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 1uuTvW-0000YJ-SO; Fri, 05 Sep 2025 10:44:18 +0000
Received: by outflank-mailman (input) for mailman id 1111696;
 Fri, 05 Sep 2025 10:44:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuTvV-0000YD-Nx
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:44:17 +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 44fe058d-8a45-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 12:44:16 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-6228de280ccso13501a12.3
 for ; Fri, 05 Sep 2025 03:44: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-b041d7107d9sm1368452466b.4.2025.09.05.03.44.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 03:44: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: 44fe058d-8a45-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757069056; x=1757673856; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SwUSFm5NnSz+qANY7euZXluaZusjbdZg+ebSEO2SD8w=;
        b=bDpVgll+kpHONVEtJfTM8Sbjrxuj4qxqmalt8y8WycBwWsV3YjBU4CYeKY3TebByGO
         hRLkePsURLcMYbk2I2F3N9gLaGb7YpnIPk4Zd26pIGidUlrTb8vckDt1UR6pLDHblNCx
         mcoxP08fcibV35FHmj1H0tuYECNjOwc2ISi9h3nkHkuZXBUaKLSPWQyX3DmK40dUHnNQ
         WB42TxMf6w+vfa2coaowU/+DozplqEPy1yhNb+uU88+0ZK9GToxtH1Z3f66gh0D+Qm/E
         mIet7Qpcr9BsWz0+MUUyEG2Br4mTdYzTG0FmX9CH2p6OxME/RLaU7jIFVmoBFOss2hyo
         4YzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757069056; x=1757673856;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SwUSFm5NnSz+qANY7euZXluaZusjbdZg+ebSEO2SD8w=;
        b=kkH3AI/faTDT14JTHw3RTY3gKnNtYSXV4QLDDjWuWI4vl18Jb2MYuGPzSk7JH3m6Ni
         tAI94FEb/Fdw0fR4fU8+nsClcpNIhxYagV8dE4bxCNGYZcXh9yIrsKatP2XkOcq7WAO2
         6AlmBavlJzLvSzoNgnu/E2IzhhoOMqJp25MNSWPz0LKoZrWiTFye7pOmtlS1IirwEYIE
         96SD/cTZfZFUX6IncoRKHHkZyusDpVgNHDQO/yB0S4Qjcv7zpLhrUVwycet49LqXoPD7
         EUZY1jQgbUpdfek5jV9WPIbmARtsDMtQxy5yuXWR/pjsCbECb9Auq8kNLMbqpCLFaPcf
         XEng==
X-Forwarded-Encrypted: i=1; AJvYcCW4Fo8Q0ip6VtTi6TH/fT2BrIF4GleO4MJ4OmLskePzsiqxAJNbw1NeEfp9oZWw2GZtAtmml1EPu58=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4A10trvwa321G0jXQl0VbT2MtJppqJab6+TyCj1G9J4m7MivL
	XzH20Ss49Agx54ShdW1h5JjmCtVaNxHgrcXQt9a1oRhLwkl9qaPsWZg1o57PgVzaGw==
X-Gm-Gg: ASbGnctfzci8guhONVWnNPYtFKE+v5+PH/Mmo8jB2f41TLylqfbpZjfos6k0jvweuLk
	PEvlhf/jq+zE4ELLLgUcvUdRQHLdnn0TDWNuzRpv17qQlY/HkqvKejI9L99fX2IcP7t89AHefdr
	blLxHM9XUODIiP4a0kOafY5ufwNnG9KbLx8MQIClW9MzPYqk3AF8IYuYNNV65vDf8sdrVsQmv8b
	Tj6YKzmPqF61BDCnVBLyh/OYTkojMoN8exc1NF9d/PrBsBy26n1jKFQ0iUz1aZjEAfCwVF/c5zU
	t7tSvqalLNhWfMoH3D2EZt6AO6lGULkdtw+12Inf6FUEA7+t7XsQIIwl1odfI5/qUoDMDveUU7L
	5fnFzPsWOCfsVCoKPX9xxipTRpX1Hbs0WM39xDRJZThRK7NPbvOq5YiPZQEj0kK1RE+CKOLgmvF
	2824PSvZQ=
X-Google-Smtp-Source: AGHT+IGFWlVTAH8cy07+cniQjYQj2+LbYruGSs3jNhiSN4O5iloq+6nghZmq3NRIjlf+8kmA9K23/Q==
X-Received: by 2002:a17:907:8690:b0:b04:95da:d2de with SMTP id a640c23a62f3a-b0495dae9b4mr222076266b.6.1757069055699;
        Fri, 05 Sep 2025 03:44:15 -0700 (PDT)
Message-ID: <8df5e7b1-6eee-44dd-b8c3-f38cc5322f98@suse.com>
Date: Fri, 5 Sep 2025 12:44:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [misra] Re: [PATCH v3 1/2] efi: Add a function to check if Secure
 Boot mode is enabled
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Gerald Elder-Vass ,
 Xen-devel ,
 Nicola Vetrini ,
 Dmytro Prokopchuk1 
References: 
 <12c18a6d0c3cbbe17cee19f9fb4501d614c23ec3.1757066332.git.gerald.elder-vass@cloud.com>
 <6940b548-18b8-4507-bb75-617378fe090c@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: <6940b548-18b8-4507-bb75-617378fe090c@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.09.2025 12:36, Andrew Cooper wrote:
> On 05/09/2025 11:05 am, Gerald Elder-Vass wrote:
>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>> index e12fa1a7ec04..e7e3dffa7ddc 100644
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
>>                     " last line will be ignored.\r\n");
>>  }
>>  
>> +static void __init init_secure_boot_mode(void)
>> +{
>> +    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
>> +    EFI_STATUS status;
>> +    uint8_t data = 0;
>> +    UINTN size = sizeof(data);
>> +    UINT32 attr = 0;
>> +
>> +    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
>> +                                 &size, &data);
> 
> This turns out to be a MISRA R7.4 violation, complaining about casing a
> string literal to a non-const pointer.
> 
> The real problem here is that the EFI spec.  GetVariable() ought to take
> a const CHAR16 *, but doesn't.
> 
> We could fix this with:
> 
> diff --git a/xen/include/efi/efiapi.h b/xen/include/efi/efiapi.h
> index a616d1238aa4..56775d553109 100644
> --- a/xen/include/efi/efiapi.h
> +++ b/xen/include/efi/efiapi.h
> @@ -224,7 +224,7 @@ VOID
>  typedef
>  EFI_STATUS
>  (EFIAPI *EFI_GET_VARIABLE) (
> -    IN CHAR16                       *VariableName,
> +    IN const CHAR16                 *VariableName,
>      IN EFI_GUID                     *VendorGuid,
>      OUT UINT32                      *Attributes OPTIONAL,
>      IN OUT UINTN                    *DataSize,
> 
> but I fear this might get some objections.

The interface lacking the const in principle means that we can't rely on
there being implementations which actually do fiddle with the string.
Hence ...

> I don't think we want to be deviating every use of GetVariable() for a
> problem ultimately outside of our control.
> 
> Another option would be to have a wrapper for GetVariable() which does
> the cast once, which lets us deviate in one place only.

... this doesn't look like a viable route to me. (Nor a scalable one,
as down the road we then may need more such wrappers.)

> Thoughts?

Why not instead use

    static CHAR16 __initdata str_SecureBoot[] = L"SecureBoot";

and be done?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:51:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:51:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111718.1460316 (Exim 4.92)
	(envelope-from )
	id 1uuU2h-0002S4-Mf; Fri, 05 Sep 2025 10:51:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111718.1460316; Fri, 05 Sep 2025 10:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuU2h-0002Rx-ID; Fri, 05 Sep 2025 10:51:43 +0000
Received: by outflank-mailman (input) for mailman id 1111718;
 Fri, 05 Sep 2025 10:51: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 1uuU2g-0002Qg-6I
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:51:42 +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 4e0a3e15-8a46-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 12:51:41 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-45b7d485173so13546315e9.0
 for ; Fri, 05 Sep 2025 03:51:41 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45dd6891d23sm27568405e9.4.2025.09.05.03.51.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 03:51: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: 4e0a3e15-8a46-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757069500; x=1757674300; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=J1vkSr2t6WIe007U0hN4zE2xrDMsQfgN77xiEgUWtok=;
        b=t0rfV8fmag+BjZmPZnphgiE2JIUhHrvEXBzgiwCvZTiu/AaZeXoVgz1O8Su3d1VprH
         LFVfZZkQIId2VNZKAlep/b3h19PURYo5tNDHv6kN8D3XpVNc33XFxrFXIY5Z0hUhuEFL
         ek2VVNQFloVs8RJHYRog+DNi4OZ4nBsSAl7Bs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757069500; x=1757674300;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=J1vkSr2t6WIe007U0hN4zE2xrDMsQfgN77xiEgUWtok=;
        b=uDz3EWid5dymAF4m4gHJnyhYDDLizFveY+cGj85sHiXzRUWz8iM7U9dpbTIhoHpsIz
         GLtp+VJO8kO9fwCq/bO2X5bq8llm14j2huNmo9TgYMFUawWHls8R1105LLgwSaHM1Udb
         ijRe7uPxGw5ZYYlKxPH/ebjaTP8XbKbQaVwcQ13JJ8hUa6iV/OJM8kVjzToNLGt96Laa
         CFZp35bNhmFs1pyJBvsq0ilzVjVtNqcUOrzkTPpVYdvjzaPZjgyhNTJCbWb77k5vnka7
         9xv4+EPkoKLsZfsw7MLua50nTip3ylifECQzhtuWXhoAuzLmwD+PtEIxkzS+5ocQHFna
         oNMw==
X-Forwarded-Encrypted: i=1; AJvYcCVaNTvtLxbUyvzHmUQYrtuzM24z73Z7w8omaHFI7yv1lCIePKvKvV1tThAnn/V8S4Gx4vaZaEuUpGo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMB54sIMjGd2JA1uk+4O5Jv1EH9DSYoccKQKHqltyQwcBtexfu
	j0xpBYID6cENDxD6YuYVOgcJ2shXTqLkSUPXFnJZhPmDEuHjt5D8tSwCT6XQAI7zo9Y=
X-Gm-Gg: ASbGnctANpjuyzraL3VjZNxeNUoKF1bnibJMwtyJw/UStiHYlE0m4zRD4Kbi28OrOii
	/XYm3L30XcN6kyONqkQiYxOZkWXeRPVdtK7NCE91PH0qD6fmt2Vce7l+LV82IelYOtczFgMPzOI
	Ax25HrBsODXa+cCuTOkMVBRcT6ZJzVw+d1pDu0n+KT66W+TCmTypGmCm2anlUDXUbht6yBPWFWw
	444093qO3lyFHroAPuaNHy2YBX5Ix9wonvzURzNBAMdiU9QZFYfCeyUtgYCp+odJSx6lMUhhvYK
	99wCzOMCA86TsZheQq35LZXjXYZw5UtSpC32GVK5P7TVRPtp316wCOyNhKoal2uhHMKT4E+0c8J
	qA5UMvc4bYrZ7nxdc8Yp0QtwMli4F9A9gS9F9/0a6dwndcQ3TXmsCL0bDEAj+j7AvX3I4QDmWgN
	V0X/U=
X-Google-Smtp-Source: AGHT+IGC3/GzerY5lXb19L18mOsXn6cD3Iuz3vumiXAfSi8joG82hUYTSp1kyNc69dnJ2+WYc/ul5A==
X-Received: by 2002:a05:600c:35d3:b0:45d:d96e:6176 with SMTP id 5b1f17b1804b1-45ddbffc944mr4530615e9.25.1757069500416;
        Fri, 05 Sep 2025 03:51:40 -0700 (PDT)
Message-ID: <122c88cc-98b6-4c36-86fd-b624fa73b020@citrix.com>
Date: Fri, 5 Sep 2025 11:51:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [misra] Re: [PATCH v3 1/2] efi: Add a function to check if Secure
 Boot mode is enabled
To: Jan Beulich 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Gerald Elder-Vass ,
 Xen-devel ,
 Nicola Vetrini ,
 Dmytro Prokopchuk1 
References: 
 <12c18a6d0c3cbbe17cee19f9fb4501d614c23ec3.1757066332.git.gerald.elder-vass@cloud.com>
 <6940b548-18b8-4507-bb75-617378fe090c@citrix.com>
 <8df5e7b1-6eee-44dd-b8c3-f38cc5322f98@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: <8df5e7b1-6eee-44dd-b8c3-f38cc5322f98@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/09/2025 11:44 am, Jan Beulich wrote:
> On 05.09.2025 12:36, Andrew Cooper wrote:
>> On 05/09/2025 11:05 am, Gerald Elder-Vass wrote:
>>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>>> index e12fa1a7ec04..e7e3dffa7ddc 100644
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
>>>                     " last line will be ignored.\r\n");
>>>  }
>>>  
>>> +static void __init init_secure_boot_mode(void)
>>> +{
>>> +    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
>>> +    EFI_STATUS status;
>>> +    uint8_t data = 0;
>>> +    UINTN size = sizeof(data);
>>> +    UINT32 attr = 0;
>>> +
>>> +    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
>>> +                                 &size, &data);
>> This turns out to be a MISRA R7.4 violation, complaining about casing a
>> string literal to a non-const pointer.
>>
>> The real problem here is that the EFI spec.  GetVariable() ought to take
>> a const CHAR16 *, but doesn't.
>>
>> We could fix this with:
>>
>> diff --git a/xen/include/efi/efiapi.h b/xen/include/efi/efiapi.h
>> index a616d1238aa4..56775d553109 100644
>> --- a/xen/include/efi/efiapi.h
>> +++ b/xen/include/efi/efiapi.h
>> @@ -224,7 +224,7 @@ VOID
>>  typedef
>>  EFI_STATUS
>>  (EFIAPI *EFI_GET_VARIABLE) (
>> -    IN CHAR16                       *VariableName,
>> +    IN const CHAR16                 *VariableName,
>>      IN EFI_GUID                     *VendorGuid,
>>      OUT UINT32                      *Attributes OPTIONAL,
>>      IN OUT UINTN                    *DataSize,
>>
>> but I fear this might get some objections.
> The interface lacking the const in principle means that we can't rely on
> there being implementations which actually do fiddle with the string.

Well, the IN and absence of OUT does mean this in practice.

> Hence ...
>
>> I don't think we want to be deviating every use of GetVariable() for a
>> problem ultimately outside of our control.
>>
>> Another option would be to have a wrapper for GetVariable() which does
>> the cast once, which lets us deviate in one place only.
> ... this doesn't look like a viable route to me. (Nor a scalable one,
> as down the road we then may need more such wrappers.)
>
>> Thoughts?
> Why not instead use
>
>     static CHAR16 __initdata str_SecureBoot[] = L"SecureBoot";
>
> and be done?

I suppose, but that's still awkward to use.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 10:55:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 10:55:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111733.1460324 (Exim 4.92)
	(envelope-from )
	id 1uuU66-00036a-75; Fri, 05 Sep 2025 10:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111733.1460324; Fri, 05 Sep 2025 10:55: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 1uuU66-00036T-4W; Fri, 05 Sep 2025 10:55:14 +0000
Received: by outflank-mailman (input) for mailman id 1111733;
 Fri, 05 Sep 2025 10:55: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 1uuU64-00036N-H8
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 10:55:12 +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 ca9bb988-8a46-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 12:55:11 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfout.stl.internal (Postfix) with ESMTP id 52D041D00481;
 Fri,  5 Sep 2025 06:55:09 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Fri, 05 Sep 2025 06:55:09 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 5 Sep 2025 06:55:07 -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: ca9bb988-8a46-11f0-9d12-b5c5bf9af7f9
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=1757069709;
	 x=1757156109; bh=hKIFy0OKwxWfXQIowWpFuRO3eTQrakoMYWSH+0AcxNU=; b=
	WtY4XCaAQolLukdvMMvVdjDqFQ461w2Jz3BImDWkG1y8G1eoWmTm1afXoEXeFGfQ
	3BzoYClekrHdYeyF+gMAoNqVbD+++70i/9pvdL4h557z1fBGEUvkG3ZZiO5hMFpj
	91oHEWJamx2qAeEVrW/SVXn3u1GpfTVrNSkh+E4P4drOIU9+HC7bUr4URkUiOwtB
	P24d1QEWCuu2uiWgOHrgTzIRaazwOM5/XGLvu188MqagvPbK5ElweecJ7D4PZKWs
	eWVFElI/zfUGdh5IupbEPC5Z0wMuCOg1EbbveOA+izl7wUejQOugPQ8eAELlC8we
	DGrJuWxOPrWPIR5CeQ0ZwA==
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=
	1757069709; x=1757156109; bh=hKIFy0OKwxWfXQIowWpFuRO3eTQrakoMYWS
	H+0AcxNU=; b=XPLZz7r8b8K66emBC+mX9I9UtiPditzifV48nWLMX6iA9/GalnY
	a3T3xsdaIu4Eu9yXccT/RTBcZiLOMLXmpbgomAvzNNGi/jU6NsWPTO/WM6vhAprn
	7aUpCjdSo6IfdOTUVwFrp6eWH2hAz72cXzbHk8EWWu+ikglIFenGZgyaXrkQ87z8
	9Vyh7YIGQzVD8VG8qQql0SHwXiW4h/PLqR068duS69tWm24XkXwq26caXbMnnE37
	/9ozEhboiyw6Nv/aVrkTU4cG0CkIRDh+UHX3iNMJ2xPeeO92vplT4nvxhrrFB2OO
	sx5fMhrGZ1q7YOrAap0vhng+u3D8Ci4RMyA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekjeduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepieeluddvkeej
    ueekhfffteegfeeiffefjeejvdeijedvgfejheetuddvkeffudeinecuffhomhgrihhnpe
    hkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr
    ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd
    gtohhmpdhnsggprhgtphhtthhopeekpdhmohguvgepshhmthhpohhuthdprhgtphhtthho
    pehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrph
    gvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopegrnhgurhgvfidrtghoohhp
    vghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlse
    grmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthht
    oheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepshhsthgrsg
    gvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlhes
    lhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 5 Sep 2025 12:55:05 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor
Message-ID: 
References: <20250904114202.2722478-1-marmarek@invisiblethingslab.com>
 <488408be-4728-4666-89a5-ac5b438bdbf5@suse.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TqfnIgzKmzVj48kq"
Content-Disposition: inline
In-Reply-To: 


--TqfnIgzKmzVj48kq
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Sep 2025 12:55:05 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor

On Fri, Sep 05, 2025 at 10:15:12AM +0200, Jan Beulich wrote:
> On 04.09.2025 16:27, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, Sep 04, 2025 at 02:58:20PM +0200, Jan Beulich wrote:
> >> On 04.09.2025 13:41, Marek Marczykowski-G=C3=B3recki wrote:
> >>> Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's
> >>> available in earlier toolchain versions. But use it together with
> >>> -fmacro-prefix-map (if available) for hypervisor build, otherwise it
> >>> still contains some paths in out-of-tree builds.
> >>
> >> I consider it wrong not to use -ffile-prefix-map when available. That
> >> already covers more than "debug" and "macro", and it may gain further
> >> functionality.
> >=20
> > I asked about that on v1 and got ambiguous answer suggesting the opposi=
te:
> > https://lore.kernel.org/xen-devel/0370c0eb1fd9ac00acab016792132fa0b943d=
384.1742317309.git-series.marmarek@invisiblethingslab.com/T/#m74a8883835e30=
fb74a85b07a7b14507ee52e7c65
>=20
> Ambiguous answer(s)? There's no reply to that mail of yours,

I mean your email to which I responded.

> and I don't
> see how the conclusion drawn fits my earlier comment. That was more
> towards what I did in v1 of my patch - fall back to the more widely
> supported option when the less widely available one can't be used.
>=20
> >>> --- a/tools/Makefile
> >>> +++ b/tools/Makefile
> >>> @@ -1,4 +1,4 @@
> >>> -XEN_ROOT =3D $(CURDIR)/..
> >>> +XEN_ROOT =3D $(realpath $(CURDIR)/..)
> >>> =20
> >>>  export PKG_CONFIG_DIR =3D $(CURDIR)/pkg-config
> >>> =20
> >>> diff --git a/tools/Rules.mk b/tools/Rules.mk
> >>> index 725c3c32e9a2..428fce094819 100644
> >>> --- a/tools/Rules.mk
> >>> +++ b/tools/Rules.mk
> >>> @@ -166,6 +166,8 @@ endif
> >>>  CFLAGS-$(CONFIG_X86_32) +=3D $(call cc-option,$(CC),-mno-tls-direct-=
seg-refs)
> >>>  CFLAGS +=3D $(CFLAGS-y)
> >>> =20
> >>> +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=3D$(realpath $(XEN=
_ROOT))=3D.)
> >>
> >> Here and below - no need to use cc-option-add for -fdebug-prefix-map,
> >> which all permissible compilers support.
> >=20
> > Ok.
> >=20
> >> Further, again as per reply to Andrew on the thread hanging off of my
> >> patch - I don't view it as desirable to leave the tools/ prefix in
> >> place, or e.g. for libraries, the entire tools/libs// part.
> >> Imo every binary should have only the path (if any) from its own source
> >> root left. (And yes, how to deal with e.g. shared include files isn't
> >> quite clear to me, yet. Maybe we actually need to pass two options.)
> >=20
> > I don't think it's valid to strip arbitrary prefixes from debug symbols,
> > especially in tools. This will break some automated tools that try to m=
atch
> > coredumps (and similar) to source code and sometimes even debug symbols
> > too. But even for manual usage, having to jump between directories (I'm
> > not sure if gdb supports multiple source dirs at once?)
>=20
> Pretty necessarily: When debugging you might easily cross project boundar=
ies.
>=20
> > just because you
> > happen to debug a binary that use more of libraries isn't exactly
> > desirable.
> > I think the paths in debug symbols and similar should match the layout
> > in the source repository, not a subset of it.
>=20
> Well, okay, we disagree here. To me, xen.git really is an agglomeration of
> too many things in a single repo. If things were properly split, you'd end
> up with what I'm asking for anyway.

To give specific example: Fedora installs source files in
/usr/src/debug/(package name) and then does debuginfo postprocessing to
point at that path. Debian does pretty much the same, and I'm sure many
other distributions too. Now, if you strip part of the path from debug
symbols, they will not point at the correct source location.
Of course Fedora/Debian/etc package can apply a patch to adjust it (as
it's currently supplying -fdebug-prefix-map via CFLAGS), but IMO forcing
every distribution to basically undo upstream change is a wrong move.

> > Theoretically this doesn't apply to the hypervisor yet, as I'm not aware
> > of any tool processing xen memory dumps automatically (and those for
> > manual usage are quite unstable, to say the least...). But I don't think
> > it's an excuse to have incomplete paths in there, just to save few
> > bytes?
> > The only case where I can see it would make some sense is out of tree
> > build, where indeed it's about just the hypervisor, not the toolstack
> > (IMO due to the build system limitation, but well...). But at the same
> > time, having different path variant depending on it-tree/out-of-tree
> > build feels weird.
>=20
> Which is why I'm arguing for the dropping of the xen/ prefixes, as that's
> how things come out in in-tree builds.
>=20
> Jan

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi6wYkACgkQ24/THMrX
1yzzNgf9GP2zBm7of9MCMIXNHy7gMPxlcVV/PCQxudG+RPi6gtjdTeKW5QSlHtbI
hb50Kkrqa20oN5AIN6seeTgLpxtlXYj1sa9Ht8uTyDd40i9DBi72vjATSwTemhoz
B9E2NTShQ7PG9Ow/jrYQ97LKAntDCOScEhDOr16i2FX5C6R4++ejBSbmt6gY3q+o
7lxiuyMUaSCn/53nT1yKuYA1oGYMU5hdBDtrunEYQS0PYdhVrTxrn29YZWaSlnM0
jYea+iMyah9XG6IbmuY67HWyKtVRNRVTMbu1alizcVleukgHsQpGvpEA5EWLF3xl
QpkEo1lNPQrtDw+SUVsRfha+XjaX+A==
=A/Mn
-----END PGP SIGNATURE-----

--TqfnIgzKmzVj48kq--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:00:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:00:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111744.1460335 (Exim 4.92)
	(envelope-from )
	id 1uuUAq-0004e1-M7; Fri, 05 Sep 2025 11:00:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111744.1460335; Fri, 05 Sep 2025 11: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 1uuUAq-0004du-In; Fri, 05 Sep 2025 11:00:08 +0000
Received: by outflank-mailman (input) for mailman id 1111744;
 Fri, 05 Sep 2025 11:00: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 1uuUAo-0004Y9-I4
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:00:06 +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 79b86be9-8a47-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 13:00:03 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-55f6aef1a7dso2104857e87.0
 for ; Fri, 05 Sep 2025 04:00:03 -0700 (PDT)
Received: from [192.168.0.110] ([91.123.151.69])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5608ace9c65sm1724233e87.85.2025.09.05.04.00.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 04:00: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: 79b86be9-8a47-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757070003; x=1757674803; 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=4ATHxwcXpiDoyxqeD5LGIv8Hu24v++edbEYnNg5KOn8=;
        b=ZgPtM04DG3R8A9SN1cK3zpOoZME+dojT2ZBZSr/AwsFD2JzUR0CYSxIdJRoyrwZefU
         LlTIuNjfYcpSdO0+gg3UKaWO5XzWddhqhmNtLmPQwdpIFowtmNZNYJ/HIpRApE2M8N9G
         kjVz2h5w2ZAo+0DbbmvmrIydSWV7BtLhKwvrYQUD868Qg1McmJ15669KF9fO0XM+zSTt
         P+gffjXq5557jNba+jJS/L8pevfmHNeDXp96PebU1Nmr2g5fk/qkJSJOhFFLty5Vi3rt
         HGpQUchIpsNR9n2XD54OD20oPPpGdHwkBKb5S54NUluyRqp6I7mjP4tThAKiaIPStJG8
         2gUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757070003; x=1757674803;
        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=4ATHxwcXpiDoyxqeD5LGIv8Hu24v++edbEYnNg5KOn8=;
        b=VKGuEkrSw6e0aceXMsP6RxgJix9nBA+XUmrXkqxPtgWpOWSlV60cQEzNtQ0js6alYG
         tdeqbrJ6N7hZiV3ThPvfexXZB+zx197ObHdD4WP6YDsDCptNgimmxinnJ9oK2xgzf2v1
         QTXubY7Dub+Qog5O8Q4R8aGsTtbEz/YrrcpgqiWngB0Pe79RILeEWjhnn9dTXawqkY2N
         IOYpuFYASCGsJzcv3wybdvuG/fdLS0YVhNvSZUUXSmj08YCifzxrrpIFksmTaChgTgAJ
         d0AWObBTJbsrp+g+lA6zA9vnsB+GaCrugMREoqml+H/lLYldZWfsj87ex4aexSAL6kCc
         WHWg==
X-Forwarded-Encrypted: i=1; AJvYcCWoXY4o7dxeiK+OqQTaoiqH8fv9s9iT0XI2VqF+Fp14ooxEFjJIfQNHEwaXfJNJCAdN2OU8aqbikNw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzScYPThBItlnIKZ0x+TjI8UTj3u+lN1Rpd9NuvfpvxObv16aa
	38valChIu1dFWs9/V/OBabhIt8Xx3DIKXBfvVMYQFk3QkIvjk+F1quz+
X-Gm-Gg: ASbGnctq7V5lO17G+aC/BxKqB7CjuaiQ0U9ZIqo1AviE4Gh6gLXcSdOWMbMs3ID4gQK
	4Rkl2mGWGkHL4CSvLBLw0gy1/E9eiLljxeXgLj4f+xedDgoIBESCdIPD5QMC0Q7Q7EBNnl8IHYO
	8HAGjpbZrn1fKi68/L7Ps68V35n2B6oEoDyOp5RegbquQ9dhVAS9dIG9q2y69GE0M3rA9LXfGH5
	mg+qjgEdpC3e7608eethks5mWvBC5u7EOl7jiAZxlM8kQVman6AF//wQi6PSEHx/vvgvBG6mJmd
	s8IW74ocDbsHXhrmLmqf2ftmEKvpzBT6dfAjUx/CcEmxPJbOasW0UkfSzZejnqMFZT6a/UmKw4q
	3pJFfz8GbEznUfsOo1cixvU/8TA==
X-Google-Smtp-Source: AGHT+IH9c+ItgqW7/BDbWjmuw+5+iGZksBfSYHlZUobtJnQI5qjDF290FD9AjHSO75BZ+Gz5Fq8lOQ==
X-Received: by 2002:ac2:51c5:0:b0:55f:6d28:bcee with SMTP id 2adb3069b0e04-55f70995b0amr6640820e87.34.1757070002828;
        Fri, 05 Sep 2025 04:00:02 -0700 (PDT)
Message-ID: <67b05b3e-becc-419b-b960-ac39c785118c@gmail.com>
Date: Fri, 5 Sep 2025 14:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
To: Leonid Komarianskyi ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
Content-Language: en-US
From: Oleksandr Tyshchenko 
In-Reply-To: <8b43ad89380261c3a3bbd0bc943461226d9cf0ce.1757015865.git.leonid_komarianskyi@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 04.09.25 23:01, Leonid Komarianskyi wrote:

Hello Leonid

> Currently, Xen does not support eSPI interrupts, leading
> to a data abort when such interrupts are defined in the DTS.
> 
> This patch introduces a separate array to initialize up to
> 1024 interrupt descriptors in the eSPI range and adds the
> necessary defines and helper function. These changes lay the
> groundwork for future implementation of full eSPI interrupt
> support. As this GICv3.1 feature is not required by all vendors,
> all changes are guarded by ifdefs, depending on the corresponding
> Kconfig option.
> 
> Signed-off-by: Leonid Komarianskyi 


Reviewed-by: Oleksandr Tyshchenko 

Initially I was slightly worried about ...

> 
> ---
> Changes in V7:
> - fixed the condition in the is_espi assert for non-eSPI builds: the
>    previous condition was mistakenly added with a wrong check and led to
>    triggering asserts for all non-eSPI INTIDs, when it should be triggered
>    in this case in the other way around
> - minor: used is_espi() in the espi_intid_to_idx() ASSERT, as is_espi
>    performs the same verification
> 
> Changes in V6:
> - added an assert in is_espi() when CONFIG_GICV3_ESPI=n to ensure that
>    out-of-range array resources are not accessed, e.g., in __irq_to_desc()
> - removed unnecessary parentheses in is_espi()
> - converted helper macro to inline functions and added sanity checks
>    with ASSERTs to them
> - defined espi_to_desc for non-eSPI builds as a prototype
> - updates the comments
> - used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs
> 
> Changes in V5:
> - no functional changes introduced by this version compared with V4, only
>    minor fixes and removal of ifdefs for macroses
> - added TODO comment, suggested by Oleksandr Tyshchenko
> - changed int to unsigned int for irqs
> - removed ifdefs for eSPI-specific defines and macros to reduce the
>    number of ifdefs and code duplication in further changes
> - removed reviewed-by as moving defines from ifdefs requires additional
>    confirmation from reviewers
> 
> Changes in V4:
> - removed redundant line with 'default n' in Kconfig, as it is disabled
>    by default, without explicit specification
> - added reviewed-by from Volodymyr Babchuk
> 
> Changes in V3:
> - introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
>    case of using NR_IRQS for espi_desc array
> - implemented helper functions espi_to_desc and init_espi_data to make
>    it possible to add stubs with the same name, and as a result, reduce
>    the number of #ifdefs
> - disable CONFIG_GICV3_ESPI default value to n
> 
> Changes in V2:
> - use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
> - remove unnecessary comment for nr_irqs initialization
> ---
>   xen/arch/arm/Kconfig           |  8 +++++
>   xen/arch/arm/include/asm/irq.h | 37 ++++++++++++++++++++++++
>   xen/arch/arm/irq.c             | 53 ++++++++++++++++++++++++++++++++--
>   3 files changed, 96 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 17df147b25..43b05533b1 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -135,6 +135,14 @@ config GICV3
>   	  Driver for the ARM Generic Interrupt Controller v3.
>   	  If unsure, use the default setting.
>   
> +config GICV3_ESPI
> +	bool "Extended SPI range support"
> +	depends on GICV3 && !NEW_VGIC
> +	help
> +	  Allow Xen and domains to use interrupt numbers from the extended SPI
> +	  range, from 4096 to 5119. This feature is introduced in GICv3.1
> +	  architecture.
> +
>   config HAS_ITS
>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>           depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
> index 5bc6475eb4..2ff2d07d6d 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -32,6 +32,10 @@ struct arch_irq_desc {
>   #define SPI_MAX_INTID   1019
>   #define LPI_OFFSET      8192
>   
> +#define ESPI_BASE_INTID 4096
> +#define ESPI_MAX_INTID  5119
> +#define NR_ESPI_IRQS    1024
> +
>   /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */
>   #define INVALID_LPI     0
>   
> @@ -39,7 +43,12 @@ struct arch_irq_desc {
>   #define INVALID_IRQ     1023
>   
>   extern const unsigned int nr_irqs;
> +#ifdef CONFIG_GICV3_ESPI
> +/* This will cover the eSPI range, to allow asignmant of eSPIs to domains. */
> +#define nr_static_irqs (ESPI_MAX_INTID + 1)
> +#else
>   #define nr_static_irqs NR_IRQS
> +#endif
>   
>   struct irq_desc;
>   struct irqaction;
> @@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
>       return irq >= LPI_OFFSET;
>   }
>   
> +static inline bool is_espi(unsigned int irq)
> +{
> +#ifdef CONFIG_GICV3_ESPI
> +    return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID;
> +#else
> +    /*
> +     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is
> +     * disabled. Returning false allows the compiler to optimize the code
> +     * when the config is disabled, while the assert ensures that out-of-range
> +     * array resources are not accessed, e.g., in __irq_to_desc().
> +     */
> +    ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID));
> +    return false;
> +#endif
> +}
> +
> +static inline unsigned int espi_intid_to_idx(unsigned int intid)
> +{
> +    ASSERT(is_espi(intid));
> +    return intid - ESPI_BASE_INTID;
> +}
> +
> +static inline unsigned int espi_idx_to_intid(unsigned int idx)
> +{
> +    ASSERT(idx <= NR_ESPI_IRQS);

  ... this assert.

The system defines that there are only 1024 (NR_ESPI_IRQS) eSPIs, which 
map to indices 0 through 1023. An idx of 1024 is an invalid eSPI index. 
The assert would allow idx = 1024 to pass, and the helper would then 
return an invalid interrupt ID of 5120 (1024 + 4096). But, as I 
understand, you chose "<=" instead of "<" to be able to also pass 
NR_ESPI_IRQS/gic_number_espis() to calculate a "one-past-the-end" 
interrupt ID, which can then be used as an exclusive upper bound for 
range checks in the code.

By looking at how it is used within the series, I did not notice obvious 
issues.

> +    return idx + ESPI_BASE_INTID;
> +}
> +
>   #define domain_pirq_to_irq(d, pirq) (pirq)
>   
>   bool is_assignable_irq(unsigned int irq);
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index b8eccfc924..c934d39bf6 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -19,7 +19,9 @@
>   #include 
>   #include 
>   
> -const unsigned int nr_irqs = NR_IRQS;
> +const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ?
> +                                        (ESPI_MAX_INTID + 1) :
> +                                        NR_IRQS;
>   
>   static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>   static DEFINE_SPINLOCK(local_irqs_type_lock);
> @@ -46,6 +48,50 @@ void irq_end_none(struct irq_desc *irq)
>   }
>   
>   static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
> +#ifdef CONFIG_GICV3_ESPI
> +/* TODO: Consider allocating an array dynamically */
> +static irq_desc_t espi_desc[NR_ESPI_IRQS];
> +
> +static struct irq_desc *espi_to_desc(unsigned int irq)
> +{
> +    return &espi_desc[espi_intid_to_idx(irq)];
> +}
> +
> +static int __init init_espi_data(void)
> +{
> +    unsigned int irq;
> +
> +    for ( irq = ESPI_BASE_INTID; irq <= ESPI_MAX_INTID; irq++ )
> +    {
> +        struct irq_desc *desc = irq_to_desc(irq);
> +        int rc = init_one_irq_desc(desc);
> +
> +        if ( rc )
> +            return rc;
> +
> +        desc->irq = irq;
> +        desc->action  = NULL;
> +    }
> +
> +    return 0;
> +}
> +#else
> +/*
> + * Defined as a prototype as it should not be called if CONFIG_GICV3_ESPI=n.
> + * Without CONFIG_GICV3_ESPI, the additional 1024 IRQ descriptors will not
> + * be defined, and thus, they cannot be used. Unless INTIDs from the eSPI
> + * range are mistakenly defined in Xen DTS when the appropriate config is
> + * disabled, this function will not be reached because is_espi will return
> + * false for non-eSPI INTIDs.
> + */
> +struct irq_desc *espi_to_desc(unsigned int irq);
> +
> +static int __init init_espi_data(void)
> +{
> +    return 0;
> +}
> +#endif
> +
>   static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>   
>   struct irq_desc *__irq_to_desc(unsigned int irq)
> @@ -53,6 +99,9 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
>       if ( irq < NR_LOCAL_IRQS )
>           return &this_cpu(local_irq_desc)[irq];
>   
> +    if ( is_espi(irq) )
> +        return espi_to_desc(irq);
> +
>       return &irq_desc[irq-NR_LOCAL_IRQS];
>   }
>   
> @@ -79,7 +128,7 @@ static int __init init_irq_data(void)
>           desc->action  = NULL;
>       }
>   
> -    return 0;
> +    return init_espi_data();
>   }
>   
>   static int init_local_irq_data(unsigned int cpu)



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:01:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:01:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111755.1460345 (Exim 4.92)
	(envelope-from )
	id 1uuUBt-0005E5-UZ; Fri, 05 Sep 2025 11:01:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111755.1460345; Fri, 05 Sep 2025 11: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 1uuUBt-0005Dy-RX; Fri, 05 Sep 2025 11:01:13 +0000
Received: by outflank-mailman (input) for mailman id 1111755;
 Fri, 05 Sep 2025 11: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 1uuUBs-0005Dr-3P
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:01:12 +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 9e054c3f-8a47-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 13:01:05 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id CACB4442A6;
 Fri,  5 Sep 2025 11:01:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2257C4CEF1;
 Fri,  5 Sep 2025 11:00:53 +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: 9e054c3f-8a47-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757070063;
	bh=YZ1wTIYoB930tSA5MeqtdhO0LxdCLchTUQFtsum00QY=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=U7+DnpZ0s1JKbZszxSjLy0wzG4FuSPqezXeI+JVM+MWhXKMk7hbSMLMR/Ap70xViw
	 Grd6dhed7yIRR8Yu73fJN0N7pkSYFsDBBJo92L9gty0NMlP0j/ofYzR8Udwhhqz0oh
	 CUbTDNzSsrto9aiXPTcXZ/bGs5k+wjoB6qyCquH8g/JPTbP7OqDNsG+bte2OrVpi4n
	 zx6H4iTAqk8cmGshjWzK/jnlqFQq/hJysU/x9N1c9QnwDh2XIGq4oxaydCWq1cwWGV
	 2fRPyoqYacVZpZfy0SFEibM7KjqfNwOBpyIxsFAfubouuDw7Z5Ombt9MKgcN6WzQfQ
	 4CK8xb4S08BQg==
Date: Fri, 5 Sep 2025 14:00:50 +0300
From: Mike Rapoport 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/7] mm: remove arch_flush_lazy_mmu_mode()
Message-ID: 
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-2-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-2-kevin.brodsky@arm.com>

On Thu, Sep 04, 2025 at 01:57:30PM +0100, Kevin Brodsky wrote:
> This function has only ever been used in arch/x86, so there is no
> need for other architectures to implement it. Remove it from
> linux/pgtable.h and all architectures besides x86.
> 
> The arm64 implementation is not empty but it is only called from
> arch_leave_lazy_mmu_mode(), so we can simply fold it there.
> 
> Signed-off-by: Kevin Brodsky 

Acked-by: Mike Rapoport (Microsoft) 

> ---
>  arch/arm64/include/asm/pgtable.h                   | 9 +--------
>  arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 2 --
>  arch/sparc/include/asm/tlbflush_64.h               | 1 -
>  arch/x86/include/asm/pgtable.h                     | 3 ++-
>  include/linux/pgtable.h                            | 1 -
>  5 files changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index abd2dee416b3..728d7b6ed20a 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -101,21 +101,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
>  	set_thread_flag(TIF_LAZY_MMU);
>  }
>  
> -static inline void arch_flush_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(void)
>  {
>  	if (in_interrupt())
>  		return;
>  
>  	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
>  		emit_pte_barriers();
> -}
> -
> -static inline void arch_leave_lazy_mmu_mode(void)
> -{
> -	if (in_interrupt())
> -		return;
>  
> -	arch_flush_lazy_mmu_mode();
>  	clear_thread_flag(TIF_LAZY_MMU);
>  }
>  
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> index 146287d9580f..176d7fd79eeb 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> @@ -55,8 +55,6 @@ static inline void arch_leave_lazy_mmu_mode(void)
>  	preempt_enable();
>  }
>  
> -#define arch_flush_lazy_mmu_mode()      do {} while (0)
> -
>  extern void hash__tlbiel_all(unsigned int action);
>  
>  extern void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize,
> diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
> index 8b8cdaa69272..cd144eb31bdd 100644
> --- a/arch/sparc/include/asm/tlbflush_64.h
> +++ b/arch/sparc/include/asm/tlbflush_64.h
> @@ -44,7 +44,6 @@ 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)
>  
>  /* Local cpu only.  */
>  void __flush_tlb_all(void);
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index e33df3da6980..14fd672bc9b2 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -117,7 +117,8 @@ extern pmdval_t early_pmd_flags;
>  #define pte_val(x)	native_pte_val(x)
>  #define __pte(x)	native_make_pte(x)
>  
> -#define arch_end_context_switch(prev)	do {} while(0)
> +#define arch_end_context_switch(prev)	do {} while (0)
> +#define arch_flush_lazy_mmu_mode()	do {} while (0)
>  #endif	/* CONFIG_PARAVIRT_XXL */
>  
>  static inline pmd_t pmd_set_flags(pmd_t pmd, pmdval_t set)
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 4c035637eeb7..8848e132a6be 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -234,7 +234,6 @@ static inline int pmd_dirty(pmd_t pmd)
>  #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)
>  #endif
>  
>  #ifndef pte_batch_hint
> -- 
> 2.47.0
> 

-- 
Sincerely yours,
Mike.


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:14:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:14:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111779.1460355 (Exim 4.92)
	(envelope-from )
	id 1uuUOP-0007Oq-3w; Fri, 05 Sep 2025 11:14:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111779.1460355; Fri, 05 Sep 2025 11:14:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuUOP-0007Oj-1G; Fri, 05 Sep 2025 11:14:09 +0000
Received: by outflank-mailman (input) for mailman id 1111779;
 Fri, 05 Sep 2025 11:14: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 1uuUON-0007Od-TS
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:14:07 +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 6ce9bbff-8a49-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 13:14:02 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 8DCAF7A047F;
 Fri,  5 Sep 2025 07:14:00 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Fri, 05 Sep 2025 07:14:00 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 5 Sep 2025 07:13: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: 6ce9bbff-8a49-11f0-9809-7dc792cee155
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=1757070840;
	 x=1757157240; bh=2gUJQvwKTk9w1wg8VRkiY5l8wLd2YIUqfy1haDWQtCw=; b=
	YxGirV0x1khglL8Yyd8fnkOzOgKdD/6gI8UJiHbduxk78ZF7LLqo0gKlaHgLggup
	W5EF6t0PzsBFgE7O8E8rmMw+i3FmrJzl5Dj0v1CvZb9P/3cBeZ9JR8qtRuWD3Nds
	KsyZtlPoO85RqedkhCx6IUAbuOYw8p0EffFTIYFSW9rDROoNAHDIzw+1tFaXcweM
	IkAG9Ly3P/C/VOCBGwrCFyP/PFHRat521JOdykIyq7FT3FbG12GOERovaOcCQIf5
	Wt/ZbZuKZEG1fyicnoiftGhU6VJ4NYTXALrQ/OyNCuhf39p+5K1sAr8DtXO1oN3G
	//ZKGH9rMfheF+saCoGiUg==
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=
	1757070840; x=1757157240; bh=2gUJQvwKTk9w1wg8VRkiY5l8wLd2YIUqfy1
	haDWQtCw=; b=WZFzSaZbQpoYUIVeSzMvo4w6s96aqDBxhgyK8mMpnSh3jOT5bRj
	BZty3+CAo757Zm5//n7Cvr9pGrhqTM9NAqhA/RFjWbPWeeUeq2orrXDtLmQg7FLm
	HTAtSUNXOr5hksXVwLglPDP00pnjzg3m1gE+iTqKa+WkECLGEWAWGwXwYUo/35Ue
	YDD9AHTCjoI6wvoXYOeRPRLYnh2JiVLnGQ4oIWgMkFGutLr/QV+KCF8R9IXGpfVZ
	O6xRmAm/3HJPtXLC46eHjp2Noqw1AmUtVyLuIoFJMeYwz7T1lsMFjrN7CPx1oWd3
	C4j/sT8ICZVlB+WSf9PK0ZzRwJS8niAdEqA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekjeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddupdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhs
    segtlhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi
    gvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepkhgvvhhinhdrlhgrmhhpihhssegt
    lhhouhgurdgtohhmpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluh
    htihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdp
    rhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtg
    hpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphht
    thhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhopehjuhhlih
    gvnhesgigvnhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 5 Sep 2025 13:13:56 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	Kevin Lampis ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 2/2] efi: Support using Shim's LoadImage protocol
Message-ID: 
References: 
 <7f4a47d5dacf5b2db2ddd2ac72c5e0f236f9be46.1757066332.git.gerald.elder-vass@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ZEJWihP4AAxfnDTA"
Content-Disposition: inline
In-Reply-To: <7f4a47d5dacf5b2db2ddd2ac72c5e0f236f9be46.1757066332.git.gerald.elder-vass@cloud.com>


--ZEJWihP4AAxfnDTA
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Sep 2025 13:13:56 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	Kevin Lampis ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 2/2] efi: Support using Shim's LoadImage protocol

On Fri, Sep 05, 2025 at 10:05:32AM +0000, Gerald Elder-Vass wrote:
> The existing Verify functionality of the Shim lock protocol is
> deprecated and will be removed, the alternative it to use the LoadImage
> interface to perform the verification.
>=20
> When the loading is successful we won't be using the newly loaded image
> (as of yet) so we must then immediately unload the image to clean up.
>=20
> If the LoadImage protocol isn't available then fall back to the Shim
> Lock (Verify) interface.
>=20
> Log when the kernel is not verified and fail if this occurs
> when secure boot mode is enabled.
>=20
> Signed-off-by: Gerald Elder-Vass 
> Signed-off-by: Kevin Lampis 
> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monn=C3=A9" 
> CC: Stefano Stabellini 
>=20
> v3:
> - Use Shim Image by default, fall back to Shim Lock
> ---
>  xen/common/efi/boot.c | 59 +++++++++++++++++++++++++++++++++++++------
>  1 file changed, 51 insertions(+), 8 deletions(-)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e7e3dffa7ddc..1f63473d264d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -38,6 +38,8 @@
>    { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0x=
e3, 0x94} }
>  #define SHIM_LOCK_PROTOCOL_GUID \
>    { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x=
8b, 0x23} }
> +#define SHIM_IMAGE_LOADER_GUID \
> +  { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x=
55, 0xab} }
>  #define APPLE_PROPERTIES_PROTOCOL_GUID \
>    { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x=
3a, 0xe0} }
>  #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
> @@ -70,6 +72,13 @@ typedef struct {
>      EFI_SHIM_LOCK_VERIFY Verify;
>  } EFI_SHIM_LOCK_PROTOCOL;
> =20
> +typedef struct _SHIM_IMAGE_LOADER {
> +    EFI_IMAGE_LOAD LoadImage;
> +    EFI_IMAGE_START StartImage;
> +    EFI_EXIT Exit;
> +    EFI_IMAGE_UNLOAD UnloadImage;
> +} SHIM_IMAGE_LOADER;
> +
>  struct _EFI_APPLE_PROPERTIES;
> =20
>  typedef EFI_STATUS
> @@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS=
_OUTPUT_PROTOCOL *gop,
>      return gop_mode;
>  }
> =20
> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> +{
> +    static EFI_GUID __initdata shim_image_guid =3D SHIM_IMAGE_LOADER_GUI=
D;
> +    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_GUI=
D;
> +    SHIM_IMAGE_LOADER *shim_loader;
> +    EFI_HANDLE loaded_kernel;
> +    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> +    EFI_STATUS status;
> +    bool verified =3D false;
> +
> +    /* Look for LoadImage first */
> +    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
> +                                           (void **)&shim_loader)) )
> +    {
> +        status =3D shim_loader->LoadImage(false, ImageHandle, NULL,
> +                                        (void *)kernel.ptr, kernel.size,
> +                                        &loaded_kernel);
> +        if ( !EFI_ERROR(status) )
> +            verified =3D true;
> +
> +        /* LoadImage performed verification, now clean up with UnloadIma=
ge */
> +        shim_loader->UnloadImage(loaded_kernel);

Is UnloadImage really appropriate even if LoadImage failed?

> +    }
> +
> +    /* else fall back to Shim Lock */
> +    if ( !verified &&
> +         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> +                                           (void **)&shim_lock)) &&
> +         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
> +        verified =3D true;
> +
> +    if ( !verified )
> +    {
> +        PrintStr(L"Kernel was not verified\n");
> +
> +        if ( efi_secure_boot )
> +            blexit(L"Failed to verify kernel");

Better be more explicit why it's fatal, like "Refusing to boot
unverified kernel with UEFI SecureBoot enabled".

> +    }
> +}
> +
>  static void __init efi_tables(void)
>  {
>      unsigned int i;
> @@ -1334,13 +1383,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE =
ImageHandle,
>                                        EFI_SYSTEM_TABLE *SystemTable)
>  {
>      static EFI_GUID __initdata loaded_image_guid =3D LOADED_IMAGE_PROTOC=
OL;
> -    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_GUI=
D;
>      EFI_LOADED_IMAGE *loaded_image;
>      EFI_STATUS status;
>      unsigned int i;
>      CHAR16 *file_name, *cfg_file_name =3D NULL, *options =3D NULL;
>      UINTN gop_mode =3D ~0;
> -    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL;
>      union string section =3D { NULL }, name;
>      bool base_video =3D false;
> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE I=
mageHandle,
>       * device tree through the efi_check_dt_boot function, in this stage
>       * 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 )
> -        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
> +    if ( kernel.ptr && !kernel_verified )
> +        efi_verify_kernel(ImageHandle);
> =20
>      efi_arch_edd();
> =20
> --=20
> 2.47.3
>=20

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi6xfQACgkQ24/THMrX
1yxK6Qf+PMGpqTAa2Afbd119yRf0dxtTIuWQtaLGvHW1rmI+qfqH9la4FeXYU3d6
M2tT+O6+3TGmyf8qMyfAic8llWBPJ++vYSHuZUxGwO5JnrPEuFdi/CgEcWs8AXrJ
kkpx7ae5Pzom5BmVGmYjZ0keoFxCgJmETnWB/7joGmXAYBma58XPq1XZKxsb3nBc
quzvzqHx+s45bgiXG/D7Y3Uf3WQnhkrAJa9wBU1jm+QswxWRcVG8z3VrDaz494sw
nUYul0hPkhjvDx7Diw9z6XTIyrBjJqyVFN948oUrsHUcgQgA6QRZWU/awTHBt2Rl
EDmV4gCC8kfdyzyLhLnmMh6I6bHojw==
=ASyp
-----END PGP SIGNATURE-----

--ZEJWihP4AAxfnDTA--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:14:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:14:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111780.1460365 (Exim 4.92)
	(envelope-from )
	id 1uuUOS-0007dC-BX; Fri, 05 Sep 2025 11:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111780.1460365; Fri, 05 Sep 2025 11:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuUOS-0007d5-8D; Fri, 05 Sep 2025 11:14:12 +0000
Received: by outflank-mailman (input) for mailman id 1111780;
 Fri, 05 Sep 2025 11:14:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuUOR-0007Od-L2
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:14:11 +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 6fad0fa3-8a49-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 13:14:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id D8DF860280;
 Fri,  5 Sep 2025 11:14:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93F34C4CEF1;
 Fri,  5 Sep 2025 11:13: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: 6fad0fa3-8a49-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757070844;
	bh=kDpzhB/6Cz5cknkR7vg25nX23vQb619EzR6gJMWg0zE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=ihMD5UipqP42+z3YN+MrXn99n6Ycd3YsueOx6CaMNo+hdxO5RgsqI0SQxPdExPL3V
	 BxsONFBqcXHbav7x1SkdqIDD48PmtLWsgPm58G0QlMiay/oaIVskT0KF8NuPaK9VFd
	 /7wzkSZr/Kf5WRucMN8/UCNMZojnjOtaAmAF95Bjf8RmpqIT1ej5HygOv9JaajJW8G
	 3sqfezMFb01ibM/+0hkAjFN8sRUuYHQxj5dBVnj+if/YJu29wWq859HwQBz6EYrcmA
	 3EU4AmTwTsfLSifdqQkLCIzFzeBG/3X8Ze/ePLiEQWW6Tfu9V10hDtY4xQjiB241cI
	 b5217/1pBB0Eg==
Date: Fri, 5 Sep 2025 14:13:50 +0300
From: Mike Rapoport 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 7/7] mm: update lazy_mmu documentation
Message-ID: 
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-8-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-8-kevin.brodsky@arm.com>

On Thu, Sep 04, 2025 at 01:57:36PM +0100, Kevin Brodsky wrote:
> We now support nested lazy_mmu sections on all architectures
> implementing the API. Update the API comment accordingly.
> 
> Signed-off-by: Kevin Brodsky 

Acked-by: Mike Rapoport (Microsoft) 

> ---
>  include/linux/pgtable.h | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 6932c8e344ab..be0f059beb4d 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -228,8 +228,18 @@ static inline int pmd_dirty(pmd_t pmd)
>   * 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.
> + * held, but for kernel PTE updates, no lock is held). The mode cannot be used
> + * in interrupt context.
> + *
> + * Calls may be nested: an arch_{enter,leave}_lazy_mmu_mode() pair may be called
> + * while the lazy MMU mode has already been enabled. An implementation should
> + * handle this using the state returned by enter() and taken by the matching
> + * leave() call; the LAZY_MMU_{DEFAULT,NESTED} flags can be used to indicate
> + * whether this enter/leave pair is nested inside another or not. (It is up to
> + * the implementation to track whether the lazy MMU mode is enabled at any point
> + * in time.) The expectation is that leave() will flush any batched state
> + * unconditionally, but only leave the lazy MMU mode if the passed state is not
> + * LAZY_MMU_NESTED.
>   */
>  #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>  typedef int lazy_mmu_state_t;
> -- 
> 2.47.0
> 

-- 
Sincerely yours,
Mike.


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:19:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:19:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111801.1460374 (Exim 4.92)
	(envelope-from )
	id 1uuUTY-0008Um-UC; Fri, 05 Sep 2025 11:19:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111801.1460374; Fri, 05 Sep 2025 11:19: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 1uuUTY-0008Uf-Rb; Fri, 05 Sep 2025 11:19:28 +0000
Received: by outflank-mailman (input) for mailman id 1111801;
 Fri, 05 Sep 2025 11:19: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 1uuUTX-0008UJ-Cn
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:19:27 +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 2ded8b1f-8a4a-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 13:19:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 89B416027B;
 Fri,  5 Sep 2025 11:19:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4C27C4CEF1;
 Fri,  5 Sep 2025 11:19: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: 2ded8b1f-8a4a-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757071164;
	bh=RHLqjtmoQ09sM+x+rrDllENxQeIkKdioDv+JW9P+Aos=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=A/QIh2ddmPQW9GbhkGscvwZJAOdlvRvh05eTseLWqDi0NqX5VoUz3c+rFGi5te6gs
	 FeVf6cxesM0g4NssvOVujDWyj9mrdK8LpKlTGDp/6FZss2dq4STW6zOMrER9uue5m7
	 gYM0YJqrGGelTJTg/Wae0ezZ+Ln5Z9a7rQdsrtvsC5aJMkzJDUejnZeo9niA5S9ZsO
	 rAiiZhiID4hhFyLR0EPR+sXVy1LHpEREWSJ9XWSwcd0WYCKy66BICmsJmvPOks/99s
	 KUtvAv0iw5WXUoAptM66b1336WnWvdA8iRqYrawyqjKazn3DqpgdPmx5ld20pIZHkT
	 94jShf4NQqhcQ==
Date: Fri, 5 Sep 2025 14:19:11 +0300
From: Mike Rapoport 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-3-kevin.brodsky@arm.com>

On Thu, Sep 04, 2025 at 01:57:31PM +0100, Kevin Brodsky wrote:
> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> (taking and returning no value). This is proving problematic in
> situations where leave() needs to restore some context back to its
> original state (before enter() was called). In particular, this
> makes it difficult to support the nesting of lazy_mmu sections -
> leave() does not know whether the matching enter() call occurred
> while lazy_mmu was already enabled, and whether to disable it or
> not.
> 
> This patch gives all architectures the chance to store local state
> while inside a lazy_mmu section by making enter() return some value,
> storing it in a local variable, and having leave() take that value.
> That value is typed lazy_mmu_state_t - each architecture defining
> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> For now we define it as int everywhere, which is sufficient to
> support nesting.
> 
> The diff is unfortunately rather large as all the API changes need
> to be done atomically. Main parts:
> 
> * Changing the prototypes of arch_{enter,leave}_lazy_mmu_mode()
>   in generic and arch code, and introducing lazy_mmu_state_t.
> 
> * Introducing LAZY_MMU_{DEFAULT,NESTED} for future support of
>   nesting. enter() always returns LAZY_MMU_DEFAULT for now.
>   (linux/mm_types.h is not the most natural location for defining
>   those constants, but there is no other obvious header that is
>   accessible where arch's implement the helpers.)
> 
> * Changing all lazy_mmu sections to introduce a lazy_mmu_state
>   local variable, having enter() set it and leave() take it. Most of
>   these changes were generated using the Coccinelle script below.
> 
> @@
> @@
> {
> + lazy_mmu_state_t lazy_mmu_state;
> ...
> - arch_enter_lazy_mmu_mode();
> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> ...
> - arch_leave_lazy_mmu_mode();
> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> ...
> }
> 
> Note: it is difficult to provide a default definition of
> lazy_mmu_state_t for architectures implementing lazy_mmu, because
> that definition would need to be available in
> arch/x86/include/asm/paravirt_types.h and adding a new generic
>  #include there is very tricky due to the existing header soup.
> 
> Signed-off-by: Kevin Brodsky 

Acked-by: Mike Rapoport (Microsoft) 

-- 
Sincerely yours,
Mike.


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:22:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:22:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111812.1460384 (Exim 4.92)
	(envelope-from )
	id 1uuUWi-0001vI-BR; Fri, 05 Sep 2025 11:22:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111812.1460384; Fri, 05 Sep 2025 11:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuUWi-0001vB-8S; Fri, 05 Sep 2025 11:22:44 +0000
Received: by outflank-mailman (input) for mailman id 1111812;
 Fri, 05 Sep 2025 11:22: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 1uuUWg-0001v5-VS
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:22:43 +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 a1ca5121-8a4a-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 13:22:40 +0200 (CEST)
Received: from pps.filterd (m0246632.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 585Atpui006187;
 Fri, 5 Sep 2025 11:21:49 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 48yxa5820x-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 05 Sep 2025 11:21:49 +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 5859Jbcn031751; Fri, 5 Sep 2025 11:21:48 GMT
Received: from nam02-dm3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2063.outbound.protection.outlook.com [40.107.95.63])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 48uqrk43ru-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 05 Sep 2025 11:21:48 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by CY8PR10MB6490.namprd10.prod.outlook.com (2603:10b6:930:5e::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Fri, 5 Sep
 2025 11:21:42 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.9094.016; Fri, 5 Sep 2025
 11:21:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1ca5121-8a4a-11f0-9d12-b5c5bf9af7f9
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=VfYT8qiL6P9H+Gdmwok375ndqrcm78qnzXxVUER5Pls=; b=
	X9KIvjGB6s3m/8eVELV2Y0Uj9AK0GfftfUPQbvTzs0d3wiTD04T8mlmhl2Dhu53N
	0hE8a5pAb+I9QH1SrekSuOJ4oVL5yq6QlVXrkxRAb7YwelRalqrUmlgSFtz/BZZU
	GwOw4fdZl5xqOPKoeLOLuXRvG+vk8n8brX1Qk/x6WXwSRfziKYQhrWVjZ+MmXowR
	yW//TrwwEgB3arH8YUqFOhscUpH7M9wesuAaUz7O+qrS32tDAprClh71WngM4qjz
	iAqLX//9kjK70BUBlRsrO0D4DIJBee3PdjplCIAQnqZene+T70o8htVYMNi5zKC1
	lUjP5LyDuGdPWQI9rVgrWA==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wfq+mklH47m3TYK891DkNf79pJW9c7Oafj8VO2mAWylGKFpmWRF8q1R3asX26nToEwQNFfBvTUr4xC/2oodA5YXAzZ/K/qmOgoJigJQYzkVxeTXcYul8fXQqXBIlFN+xjvWtsJ6MP6rQ5+CrL9FZlGIuw/rg3xqjyhGB5SiraDxmKYIr/xUH8Uc6E6UhFF5gzQvfKKd2BYKxpwGljGfm4Fcp7oRkLWu8KrPSxYub2nL6oYyTAfFybPU34KxvZNlgRVymlOMsrmFa1n/JgfYu1D1Ob4ScCP94s7WOvA2XplCTDHQRNS19zHiqIm2myX26pk/Ihq8bvh/3jsfU9oYIHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VfYT8qiL6P9H+Gdmwok375ndqrcm78qnzXxVUER5Pls=;
 b=kGcaepnnvNKiuZ+n/lrC4qmvEMmH5qxCp/ELcFBoySlSoMMlBR9vGUz5JYhBk6Fzqo6HHCvzpiw1YRJT6Yc0xeto9ruF1YJ+HpbgQWuTBzYPM2kUS8IpbidP+5XbUsct3KXMgij1QZWlI/wmF38EPgzH5ZTjZusH6VY0vCZNeoQP0xyhzSovQ/kDaq76QxfLa8hlScd43GfacRBeE/xqkAV4WgMn77pGZwYp3nwK9WY5aggcwWrJPpI4YjgyIhTU11K4TOXnHIhFuF0iR3hGEgT04UVJZejr24r8+9MzP+F7vaEr0lPUARpoweKlYzPcdnoRvg7oS31RXkVC1ozEUQ==
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=VfYT8qiL6P9H+Gdmwok375ndqrcm78qnzXxVUER5Pls=;
 b=JfCWt8ToCMUCik3uBuDD1c/0K2xZCJQfuRataG1hRAJrvKFmw1WhED4wY/PqOX3EpHZlG/h8WS9fJ41OvyHv5NcIABYpbY3ZT2Vd+FfxD8uiPqftWispmcUOK9jNpRUlB8UYEs1SRwOtbGxV+l1RIQV8yMkfUYhaXo7qZHrYawQ=
Date: Fri, 5 Sep 2025 12:21:40 +0100
From: Lorenzo Stoakes 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Alexander Gordeev ,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: <2aed0b3b-1a70-4c89-9177-8de4fabb2237@lucifer.local>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
 <22131943-3f92-4f5a-be28-7b668c07a25c@lucifer.local>
 <75db1f58-98b3-463c-af4f-2ce9878cba9f@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <75db1f58-98b3-463c-af4f-2ce9878cba9f@arm.com>
X-ClientProxiedBy: LO4P123CA0035.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:151::22) To DM4PR10MB8218.namprd10.prod.outlook.com
 (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|CY8PR10MB6490:EE_
X-MS-Office365-Filtering-Correlation-Id: 9188d4c6-3a6f-4c1d-293a-08ddec6e63f9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K1FTQnRwZHZJb0RJdy91SkdJR0Vlc1pIQnpHM0tJc0RDNHJoTVMwemlSZElw?=
 =?utf-8?B?NWZBWHpBZEdic2Nsa0Zkbk94a1ExU1FNZXdJVDhkNzRZRFFOTkszOUR4dGVJ?=
 =?utf-8?B?NGpKN0VCVElpbHA2aWNJd3RsclRBYTMvdk9lem9HK3lHWVZicnEwTHN5UnRW?=
 =?utf-8?B?RW0xaXJBb09vREk3cnBQNUo4M2Faemp6MEJ0aTVFaUJRekVSVEdHa05zc3JQ?=
 =?utf-8?B?UWRBMzJtOFhyMzQvWkNaaitucEtUWWh2MFJiZGYwUFRhN01Edm4vLzJydGZG?=
 =?utf-8?B?b1AwWUoxTTRGMmVuQWYrUFN5aExkM1R2NHUraUY2cHpvS3dudSt0anFCbHFY?=
 =?utf-8?B?K0J1WWpDcXJKTGtYd2p3VlZMMEFURWVuZkF0ci9hT3NCODdtMkVLOTU4dlMw?=
 =?utf-8?B?R0VZajlLWmNNWk0wMjhNbjBEb21xZlVIc3QwL2Q1akpTc2RZTVpjTUhvV1I2?=
 =?utf-8?B?dDF4bytyKzFHOVQyU2VwNFZKYzZ1blFUYXlYd3J0VW9pbnhGMmY1TjlGWjhJ?=
 =?utf-8?B?QXhSeXFXVjBKMnhFRFIzZHYvVE1TcERwRS9NZzhRcmVEUWMzZWgzVnEzeWRU?=
 =?utf-8?B?QUVBVWJrdWlabHVOMjNqRGV0UDBPWVFTN005ajgyUUlwbVVJdWtLYlE2RTB4?=
 =?utf-8?B?NUJ4c1R3UjR0WmhWb1E5VzhuWWtZV0h5QjBJK2Izek5CWDFDb1NHSVlRbnB4?=
 =?utf-8?B?WEV6UmVlYWErdjYwSVRZWit2M1JDZWpmUWVrYlFLTGZyOGNCWjdsbHlhcjhy?=
 =?utf-8?B?TGJWUDNSeExnMWMyR3RvZmcrY01QN2JuYllNRVBVUUMrL0pPRzZTVGdJc0pJ?=
 =?utf-8?B?S0dxbkN4NXBCMGFsU2hpL0x5ajBtSUphM2V5Z3AzcmcvbWZJNWtSS1ZGN0VO?=
 =?utf-8?B?Snp3Q245QlduZ1E4RHhpNmszemIveEVUMlE4UU1aV08zN0RCdHdWMTBWYUor?=
 =?utf-8?B?S1BWM2JaWlRjUlIzUXlmS3JqdkZTMEhGVFM5WCtjL3dvbWpxdFlMRElqZmsw?=
 =?utf-8?B?QTh5UFBXYU1udU0vbWJidmg5NTkvYkpsY213Q0ZwRlhDSndYYXN3dUk0YTJp?=
 =?utf-8?B?ODRKVW0yQUxuam5GUGVlZjVXY1YxNFlUSUxwTkU3V0pzUTRiZjcvaW1YQ1JV?=
 =?utf-8?B?a2hEbXk3QWhsTEJSeXVxOXZnejdmOXFjQ0hzdjY1OS9sY2d3ZlVWTytnSDN6?=
 =?utf-8?B?Z2Q2bjc0SkxjOFdQME9KYk1GTEdoUXdVaWF2WDYwSTF5S1g0MUlMQlBzbEk5?=
 =?utf-8?B?cW1WY2FOekR5Y2svUTd4dDZselM5eUVHR2FIN0Jqa0ZwQ1VVdzNUSWpzQzNo?=
 =?utf-8?B?R1hqNWxFRUh3cEZ5V054TGlXdmxqaVJTUmxLY2VBemRhOE01N3RML0dCcnRp?=
 =?utf-8?B?b1JkUzZOejFyT3A0cmkxV0tYWURlNTRNNWVjOTlKMzZlVENEM1Bka3lGWkkr?=
 =?utf-8?B?c0JPL2gzK3gwRkw5cWUwbHJNRWxvZlRpSUNtRUVHRXcrU3QwVDBQV0c2cHpa?=
 =?utf-8?B?RzhvVDdUZnhQaC81R2pPeHUxdHlsclNKSnBNTldTSlBpWGFjLzM5K0ZKZEY4?=
 =?utf-8?B?U2lNY2lEc2l0Qm5YOEZ3VS9tdHlnaHhTaHZpT3FNSVhoRWhzeEsza3k1LzJE?=
 =?utf-8?B?Wnp4L1p2dmxhZC9idFhxeElETTRPcXVXdFZpMWNIUk91c1MxcVhCY2N2c0E1?=
 =?utf-8?B?OEU3L3ZUVnRJRVdGMkNQMXY5dmdVTnZjNjhlZnlOSkJJVEJINlloM05oR3RT?=
 =?utf-8?B?QThZcDJ3SnpSajBid3FnV3RxNEQ4R3hpNHBhL1NXWTdIdGoxMGlZNi9DQ3NP?=
 =?utf-8?B?eWZLMkZzUUxqMGtVbXpWbFhzM0t4YTA4bzFORkROemFsT2RKS1h2U0taMS95?=
 =?utf-8?B?aW56ZzZxdzdHb3NNdGZyblpYaVV5WTJXeithbW1nWDQ1K0xTaU9tRjdTVk42?=
 =?utf-8?Q?si905wpf4iw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bTdpekJCR0tTRkdMRmlQNnhjMTRkaDZqZnNWc3JQRVA5ZHRDNGNhZS9vYkQ1?=
 =?utf-8?B?TzhwaFRzOEFCWWJYaDV2alk2bklhU0V1eWxtS2VYZ0JGelFDK1JCai8rT29I?=
 =?utf-8?B?OXl5bVhFVThhcFpPSHJuWmluVHBOYVJYVXNReUk3bGpLK1Qvd2hCYmhaOWxz?=
 =?utf-8?B?U0FVa3Y1TDcyRnJpc1QxRTdEU3BIMEJQWlB2TmxncG14MFpTNzhXSThHUHVC?=
 =?utf-8?B?YmJsOWhXaE9jSUkrdjdGSnFscHQvZjZNWG1xVmNReVk2aXQ3N3E3ODV5Zi9I?=
 =?utf-8?B?REpXNURxU3pLU2lJUkcvWVgxNGYvMDNFb09kNVgxWEtESlE3a2JKZkNleXlp?=
 =?utf-8?B?WEhGdldMR3lsSVB5M2IwellxcHkwYlFNOVNYam5UcnNUZEcrZm5heFNNMkg0?=
 =?utf-8?B?Rnh6aEtiaGpWc3Q2SVBSMlpXRkVIYWxCNVpNMVIvSk4yL1ZrelFCQ21mdmxn?=
 =?utf-8?B?UHRaMU5QTUMzZU9HWUZBSnprQ0MrTTVReVdzQU9NN2JPY1R1dEM5YlJkZEpz?=
 =?utf-8?B?TldUdUxUNFN3MnB1VmZic2p0aVdJck1kMk9rTGNNaTRtMlBkaHlGWHJEL0Z1?=
 =?utf-8?B?SlNPaVRJcVZiYkVjMGREZzQ1TlloOFlialBxQmhsWWp6dWVrUDVTVlh4Nmgz?=
 =?utf-8?B?ZmtXNngrT1dTNWsvRXNuUExST24vbWg2eVYxTndHZmVMaUN2dGJ2MmVpRWsr?=
 =?utf-8?B?N0tScGF4VG1xVHdMRGZ2cW93WkRtd3kzTEN2cFZsYnJxRUpHWXhObzMyM3BH?=
 =?utf-8?B?WFd3dmZJME1pM2FLS2FHSE1jdXNEUzBCd0ZEUlF0b3pLc09ITE9ZNmhvTHpD?=
 =?utf-8?B?MmhoZDMzejl6SVZtU0YxSFU3OElBQjlDWjZIMzNETzRPS2VHK2d2UVRScHQ5?=
 =?utf-8?B?TnM1YjJKSS9DdjEyTnlmS1BDWUJHM2xRWlFrMmQzZTV1bStRakNWQ1h2dTlv?=
 =?utf-8?B?NkNDeGFwVEFDTU9mckh3VGNkZ0FDVWQrY2lWUlZxMVVuTWxHeXlmaE8yKzhk?=
 =?utf-8?B?OHVoUFkwMVZpd25COWlnK0t0SjVBRjFidVVRVldtSEZ2ZEtUVnlRQVR2NDZH?=
 =?utf-8?B?OTVnSlNtU2NJa1daUndoa05MRFFSV3BoQkxNTHVhTDdIajd5UnhRRUc4OXIw?=
 =?utf-8?B?SGM0VWRvbm1PbFdKSlNGcHBwRkJSRjhRcTBjUkZXb2tBNXFMdkhodjgwZmVC?=
 =?utf-8?B?dlpVUTBhVDlDSFJQZFZzNU1mK2k3UXFnOXJIekRzWHJmMThKanpmN0VWRG9X?=
 =?utf-8?B?bnVaQ3dhS1Q5OWNVb05QLzdKbG4ydW03MDErWC83S1ZzbkhmeWlHWUF3d1hv?=
 =?utf-8?B?WER3bXQxRnVpdFBKUHZqcVYxMmZHd3ZvM1VXYnorMzNGVTFhTmtpQ2xrdGlr?=
 =?utf-8?B?eS9tTHRtZEpZTHlnMHA1QnRTVWpjeExRRHB5RmEwMjBkalBhaW9iRjJCL2M0?=
 =?utf-8?B?Njg3TkhIWTFUdnVXVGlMaTdHY0Nuc2NsN2Z6NkRZMEhFbDNuTWZsWElWSm1I?=
 =?utf-8?B?UHRYYklZTGhqaFBMdEMvemtRMkNISVV3RFVkS3lCenFaVTJSb0VpSENLV0Jy?=
 =?utf-8?B?cFZJd2NpV0lKQ3owUy9XT3RGRUYvMEx4Q2tVaTBEakZQalZKK3FLeVV5c01Z?=
 =?utf-8?B?NVBBb21NbnZKdCtjMmJYUWVDNEVaVTRNblFMOU1rbThFbUtvY3gwWW91aU92?=
 =?utf-8?B?aXRFNTBMVCtqaVFKK2JSajlWQytwWjRQWTZSRDMvbWc3dE1Wa3VNaUlUOW5U?=
 =?utf-8?B?QzJRWFA3VFNobkl6ZytIZGxMK3krSnB2TnhoOUxaMzJpTmlDTVFVUGZ1Y3Rk?=
 =?utf-8?B?SnBVNUhhYnY1enV4dGhISzNNWnlOdzkybkZIeHVjTEh4VmovamdMb240SHc0?=
 =?utf-8?B?RFBtSG9KeVhoOGkvUUUzNThibmJIbnJPbVczaTFNckRhUkpnUnBsbkZwVGtV?=
 =?utf-8?B?WWR5TDhzdE9uSTh4UXEzZjdrV3h4YTdOVFRnR3VjbWVFVVVuaW96ZkNLNlFG?=
 =?utf-8?B?UTJNMG5EMzFSc0hRUGNxWjVWZHh5aktoWHE4bWNPZnNoRlEyVmJpN3JlMUZ5?=
 =?utf-8?B?OWx5bXRXRGZpU3V0bmNZR1piYWRvSXJuZnkwb294MXc5TFhQM0g3VXVhZ0lO?=
 =?utf-8?B?YnVRcUhlUFBVcFFYaFhhUUd6Wk1xWThOdm1ISzZmODhUd2dGN0VHUExkc2Ni?=
 =?utf-8?B?ZEE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	+H+MnG0MzlV28CfTZwtVBqeniqmbeAuuQEV1j/bIYC0VUrW0o1rUIyiOAAGrKt3wQWgnX7aAjAzRUmX8bMfyzpREmTJw04Y/FDrUlS0Ktu6E9cck8DMK/isG+pkVlQ4Vd9mHmOw1c8L6h2n8D+gIWqU7Ixlcv9EJcY68mNheTyCWJNl872+GHkvPkyaj/xs9anojfdvsggaW0p9UzfUwrUe712xRnf+lyomW3S0YtsgHnOVaZ1Ytb9CpX3YRrBNqB8LUbGQqd2Bq7ytwZCcvmKg6PiCnRoq6ProIZ79Tb16OsgtZ8ldEoihXHi1sujLmuUTaCgK9jo1HxN1uMv95HyAsMyuaK1Qw1ESVwJUTk8vrH/CamOrmqE0aCV9ADxXdVdTeuSg0GQQZCoZlNylz+50qp0G3qwfK0x828nwfEqH8CbMlGDtezgAKr6sjg5J8VQWcQPp64qA1pM9E/veiwztUtWGx3De0hM7W6XBQBhpiEEhKMl8ZnqbUL/58CxNwC/Rki9czIx97CRFe3JYjLR1v5uFzP55eyjcpQK6tcbi+R4ox+Zri/UjEPtAZMlYxpMkteDXom+OWbySTUNBKUaHwRSHceyJ0PA9YC3gwnnE=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9188d4c6-3a6f-4c1d-293a-08ddec6e63f9
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 11:21:42.4944
 (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: uNNJqs671MYZAjuv5Zr5Mjp5pVCBe6WUyMnyVG1/S8HHjeVw93AB9eBlmZF2VI7pDRRkxRQamugpxbfg/Q3mKk/PXXKCFDMfuSj8o5pM3Xg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB6490
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-05_03,2025-09-04_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=329 adultscore=0
 suspectscore=0 malwarescore=0 spamscore=0 mlxscore=0 bulkscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2508110000 definitions=main-2509050110
X-Authority-Analysis: v=2.4 cv=eJgTjGp1 c=1 sm=1 tr=0 ts=68bac7cd b=1 cx=c_pps
 a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10
 a=yJojWOMRYYMA:10 a=GoEa3M9JfhUA:10 a=k1SCJAmto4eHJbuJHFYA:9
 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 cc=ntf awl=host:12069
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA1MDEwNCBTYWx0ZWRfX5qv89sWPDMV1
 F57kCpQE+MwIistTZZ+4byOmmuI3AGNmtiZpQoLQW3ViSWY8KNxB93lIrEYu2C/dBuY85hpdA4P
 fTtZSdaCNqB2xE111Rc96P+xShPASgwjR3B6WTtvIm4FI15yrTJvb1dpzgNmPXo331PcS+R1UYK
 l4B+1iBYEpX4wUVJn3v2xPYagd75TkQsjm1SMj9vzpp3gqT9f1H7lFtvBFHiS4vR+xhBCByXJqn
 KSPEn0Q5urrdJ/9E1rf6bzuX3HuEx3fFS7JEoboCxwqsIfER4/XJtDsXEN3/AH/JsZG2QtB3noa
 Jsuhvrnd4MRGDHThKViSA57AKFTo4xHIXkqvSx7oRKHSySMnXS16a/X3KYlOhq1HjQJltzn8AAs
 0NkYTToq/U1ZWYMiHXPGRigZ5f3bsg==
X-Proofpoint-ORIG-GUID: gt5OMWPnzOu2BeR76CxwORufPMzOUA98
X-Proofpoint-GUID: gt5OMWPnzOu2BeR76CxwORufPMzOUA98

On Fri, Sep 05, 2025 at 12:14:39AM +0200, Kevin Brodsky wrote:
> On 04/09/2025 19:28, Lorenzo Stoakes wrote:
> > Hi Kevin,
> >
> > This is causing a build failure:
> >
> > In file included from ./include/linux/mm.h:31,
> >                  from mm/userfaultfd.c:8:
> > mm/userfaultfd.c: In function ‘move_present_ptes’:
> > ./include/linux/pgtable.h:247:41: error: statement with no effect [-Werror=unused-value]
> >   247 | #define arch_enter_lazy_mmu_mode()      (LAZY_MMU_DEFAULT)
> >       |                                         ^
> > mm/userfaultfd.c:1103:9: note: in expansion of macro ‘arch_enter_lazy_mmu_mode’
> >  1103 |         arch_enter_lazy_mmu_mode();
> >       |         ^~~~~~~~~~~~~~~~~~~~~~~~
> > ./include/linux/pgtable.h:248:54: error: expected expression before ‘)’ token
> >   248 | #define arch_leave_lazy_mmu_mode(state) ((void)(state))
> >       |                                                      ^
> > mm/userfaultfd.c:1141:9: note: in expansion of macro ‘arch_leave_lazy_mmu_mode’
> >  1141 |         arch_leave_lazy_mmu_mode();
> >       |         ^~~~~~~~~~~~~~~~~~~~~~~~
> >
> > It seems you haven't carefully checked call sites here, please do very
> > carefully recheck these - I see Yeoreum reported a mising kasan case, so I
> > suggest you just aggressively grep this + make sure you've covered all
> > bases :)
>
> I did check all call sites pretty carefully and of course build-tested,
> but my series is based on v6.17-rc4 - just like the calls Yeoreum
> mentioned, the issue is that those calls are in mm-stable but not in
> mainline :/ I suppose I should post a v2 rebased on mm-stable ASAP then?

You should really base on mm-new.

You need to account for everything that is potentially going to go
upstream. mm-stable is generally not actually populated all too well until
shortly before merge window anyway.

>
> - Kevin

Thanks, Lorenzo


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 11:38:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 11:38:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111827.1460394 (Exim 4.92)
	(envelope-from )
	id 1uuUm2-0003vX-Ml; Fri, 05 Sep 2025 11:38:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111827.1460394; Fri, 05 Sep 2025 11:38: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 1uuUm2-0003vQ-Ja; Fri, 05 Sep 2025 11:38:34 +0000
Received: by outflank-mailman (input) for mailman id 1111827;
 Fri, 05 Sep 2025 11:38: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 1uuUm0-0003vK-TZ
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 11:38:33 +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 d4abd682-8a4c-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 13:38:25 +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 585AtxlR004280;
 Fri, 5 Sep 2025 11:37:26 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 48yx2jg3jv-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 05 Sep 2025 11:37:25 +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 5859Jc49026155; Fri, 5 Sep 2025 11:37:24 GMT
Received: from nam12-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2075.outbound.protection.outlook.com [40.107.237.75])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 48uqrcw92u-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 05 Sep 2025 11:37:24 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by CH0PR10MB5001.namprd10.prod.outlook.com (2603:10b6:610:c2::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Fri, 5 Sep
 2025 11:37:16 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.9094.016; Fri, 5 Sep 2025
 11:37: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: d4abd682-8a4c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2025-04-25; bh=SbkDXHUl3oiXFJv0so
	7ZQL70BEA76gG0eDXK4p6frbw=; b=gXCQ2czkuFqWkFOQGOAsyG4VJ6mHO/eWNI
	Qjiow/4vFa2mnZFMNUb45FtPGxMLPYjKmjpigYsEdj6YCUbTwyI/2BSV+VOg/rfS
	niSyS0rNAanbQlItLHMu1qMnDGwMhu5uLWHLPnqfdUgppQle0KvTsE2dPSB+juCn
	ox9MrHgfnaR2CZS9PGjXs3KRjK8XvKd8KLl5sgTqk6JxrhxNoVkOLF9xZf7o6W/7
	rfynIfqJq+IkG+rsw0JCMrTQ087dqE/0wwXBDjeloPlmzvriGYInNxHz9IpEMi7r
	o4V3YZPjZxVXPaX+sji7uO3o7SnxDPxKzicHERiDNN7gbIeVfMow==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Yuo/vYE1qoNnnOsr+h5h8sIllc8rhwGL9vQOFs6W07j0ROVPlB0XjzzapwOHcXVSML6q8Jjw+VTaZvNiwpI4cNSLu3n3i5SAROIHTzlONG2zybLB5WK46fvnvmFM+6pb8eFkKzOnj7dj3N20cQ7mOySdAD3AkPzGrfHOpIPuweE7TUFh1wV9IWhlxFEBMn/G0WLSBSuNG7RDboS6f7K8URrT9VV2afIZ23R9drT6xnPQeDBrZXYLumIba34Sy9Wtotppj+NpDCmgLgPrBXH7YqMlD1ZOPrZu/BJRQkmD4RYKLQmqJ82YnZEUfDS5NCzP1aSnBWRRWEysXv6fQeBu7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SbkDXHUl3oiXFJv0so7ZQL70BEA76gG0eDXK4p6frbw=;
 b=hSFRwcNtOO0k43BgdaUZXPS3QYbD1DySv7NldOlt5hbNALhYa5p8BV1UhGTD0AgUARJYR8+9Q/r6pKK1rKeNGWWUFc2pKma0ii6hl6dEnP8uXpspeCfnQrMCPbzl75p9pF0E04x8enqU2SsZM4quzJdKdZ5T/0mnAPyvY6uE7dmel3jxzQ2dCqqbUppBbN+rpQhQ+pSU0ZgTuQaMsbOt9ZkyySbKQVuC8Kjliug6x/duVD8SwKtkacvelseNCXigNMDFur6FIXJZjCEObea5YpK1vK/775RKWe0b0IJiNoP7+saMgUc+cHdgX2SUNh9cwpH6PQ2qCl63XECU8+2IQA==
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=SbkDXHUl3oiXFJv0so7ZQL70BEA76gG0eDXK4p6frbw=;
 b=nfkDbjY/56XkUFZ6ixYsiQ9F8cp2XvOoIc1cqrtjJOR2Sph38zxN0xew53nJeeBhbg8+xiXokPmh51rTsgpUl8JAJOeaJBhiqdXV9TypbpWKxN4Fl/jrqpYfdqRJBijU1Yopmr9m8u6PkXXnA4SAV9Ag+PvwEYRS7H/c+hDbs+U=
Date: Fri, 5 Sep 2025 12:37:14 +0100
From: Lorenzo Stoakes 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Alexander Gordeev ,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
 <22131943-3f92-4f5a-be28-7b668c07a25c@lucifer.local>
 <75db1f58-98b3-463c-af4f-2ce9878cba9f@arm.com>
 <2aed0b3b-1a70-4c89-9177-8de4fabb2237@lucifer.local>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2aed0b3b-1a70-4c89-9177-8de4fabb2237@lucifer.local>
X-ClientProxiedBy: LO4P265CA0018.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2ad::11) To DM4PR10MB8218.namprd10.prod.outlook.com
 (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|CH0PR10MB5001:EE_
X-MS-Office365-Filtering-Correlation-Id: fc49c42b-a1b0-46e5-9486-08ddec7090cd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?C6XAMNQV/QDaDHTxLITrg66EQd18uZGYd/ta1lZfl72etSjxoV1fDX5k4UeI?=
 =?us-ascii?Q?+15JMn9uF1aduCMUHCnssuowQ8ZZV4dcOLRy6Z/LmAcfvM2/lmf2kiiLygD5?=
 =?us-ascii?Q?J9jqA3nXJ/n9QduD+G5UaCbC1aaruMmiq7T28uZYf7E19jvw4YH+kndKQ+9S?=
 =?us-ascii?Q?0R9ESstJcDQuHn31cA89g8d1upwcBJpOklYyvqNcFOzc0qkK+kuW2G6eooGd?=
 =?us-ascii?Q?t3G4rH7/GvrZ1b8vjw/+1J5p0dBw8IEmeHPSeIfvlHJh/YIFL3ndLqqe/lQd?=
 =?us-ascii?Q?tpiHC0yuqfsZNdsRlEe8Yb3EcnCmFAoT7FZB5Ot3A9xqwiK7eD0jhRczskw7?=
 =?us-ascii?Q?J/HcLor7zKg+8LSvx0jzaIGPqQNnd9awPVzcnn8xObhrZCKbGPfi7dIL1wtm?=
 =?us-ascii?Q?qiRoJOVVXqm4StNRLMo5Sb9x7BLO3Aut0Ty8RsgIQS1/BDjL8rX18LL5F98+?=
 =?us-ascii?Q?2BOFh8NW6r/vcl1q2YgdRAPfxo4tfo1PraTOY2iRBq5WMsJdJIEqi2mDlKhP?=
 =?us-ascii?Q?R70I6ns2JLVxQTesrXK/apL/BK090jFNqxgPXl+KeTcNGKdet//Xl2DQPEPY?=
 =?us-ascii?Q?zBsQA6jQu+6ikU9Z9Ouuh8b20Qco5sTa4U77bI30SRIGLqcMNuew8gnkwK11?=
 =?us-ascii?Q?9lihNecT9YGyvCq0KoLupwgUIeR68dBsF/dbIgWnMzghIlvSI5WTeMLMTXSC?=
 =?us-ascii?Q?WZ/qvjqHaXVbaXgstUgchTTrBPKBxj/+HXNomSyKSwJHmSl5Upr15z1dMNXn?=
 =?us-ascii?Q?SdbUeaanQbKhUlXEaKZwwbBo2Wfv/mecEV6uvX1/gVMghD+93vrlXZ8PpQJG?=
 =?us-ascii?Q?BHJWZapVPnfCuGp47Q2096m/vWVEk7afkqZnUhf+LIWCGd8gRIoNiG1nnFXC?=
 =?us-ascii?Q?ZYJ137sXe9fbw1Mm8ONbXsR3aSrS6mlx9IrrYKwirt5ce8sen6uNQ5f6QjTx?=
 =?us-ascii?Q?rxo1YaRtxDjqVaX4ivkOA+n28G4FkImIdAgleziPvyu66g53p6tuL2a4kqQb?=
 =?us-ascii?Q?PiebBKFMygzA9ifU1PLy7XQpK1Vr8S138xq5rQa7Vg7oeRPX28CbtAoYZCLS?=
 =?us-ascii?Q?gspDqQYMgIpZvLaXdN4QY0cMJRPDjv1cShPzorSn+JWbScZqLRNcHlan99B4?=
 =?us-ascii?Q?H5Nvnzc87Tl7/zoaEWSlbsz+mozj51Jpi0flDD/Dvyx6eWlAghQ+8i9bXFgg?=
 =?us-ascii?Q?7qVeRsykqbhbXTT6gwiT2TGtDkv5PnoOGHIaDHwtuujf/la5HKqnKOb5+r5A?=
 =?us-ascii?Q?0pP2vp83dHsHA7nFQBpTBw89PxCHXIqv+KvaW7i+5J8ZBNFtKhf1jXEDriMB?=
 =?us-ascii?Q?oNT1kQPKGQcCcPKA1FDTKqzyPBVcaRf4teFbGU2ic9mE+G7Q6ffC7138SOou?=
 =?us-ascii?Q?qEzu9S1BL30TsPIo5ivGQqq8VO3Yuy8keEFY1XmMN1BGFGEJ82I4xUqB6ce8?=
 =?us-ascii?Q?kBuvoBGTRA8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?NL3QSfZfb5DnlPEhZub+gSkfJ+BWZtnZZ16Bwfp1HQCBd3g2RRAQTsDQ3qxL?=
 =?us-ascii?Q?vAG3UXN71aJKKOlnsNbscucGOB4nVjatuqII+2vx8dbqpHsXzWQALLQKhIcU?=
 =?us-ascii?Q?UevAY2MeLQ5YmF4QulGwgnplZCzDOadZo+1yp3byqXjGgPFsOaXwbs1IKlAH?=
 =?us-ascii?Q?vernW/mcjk2zvuYTUdinnJrvMSIbfXNRu8P9S55LUhJ+f1qUOLYVn7vUe2HR?=
 =?us-ascii?Q?2gsxnDTh1no6FweUt2gNdSfwVGBxb6nmVGD1vuUdioMx6NYMGPj+nT5JbN8D?=
 =?us-ascii?Q?BfhiKdwoi9E2CWpaa9IqB3rU6sP6ya9Ckv20vDT+xfS0xjfnXrOAcSsEQsZM?=
 =?us-ascii?Q?2G8X+8s04pHx8fNE5XX4hBmCSxdPJtgO0PvxUD909lWJJWAIxb2V7XNF+680?=
 =?us-ascii?Q?a3+KutrB+8zh7AGvKNTjdodBvNpvNc8EhcVXl/bP86342ZOqu5IDgnOCXGPs?=
 =?us-ascii?Q?vAIxfxos7fH3E1JqAU8P9qX43wFud2u1mEVYHkUntsIQj2ge3T/+gPOyx0ch?=
 =?us-ascii?Q?iRZqH8rcFtBMSuK/nXgjexMMXf22SCep3SM2eOdvf3h0LrlcMaaoa12rYWeg?=
 =?us-ascii?Q?pe95AiSE3GdjJrN8+loq+WeffTgC+GBFmfJrqcdaxHW4gFMpGyHioKaPqsL4?=
 =?us-ascii?Q?x8yVUPSrM5gBNM1htT6trnDbZMGwoShU5G/IIj9p8xc5Bq19lRi8F5VHv/Z1?=
 =?us-ascii?Q?4mkFydP9W3na38/zRaj/8xt9DGORQNlsXbLjSJYUE8pMmXeJBhjBioI3vgqP?=
 =?us-ascii?Q?iHl+5v9YVtwiFJJ3n+nDhFOR3I8iaeVo0bc0Teq+gGITw2GUPXpuZ/nZbH72?=
 =?us-ascii?Q?hAyE2VMQqH6oJGx9SpZD1mX/1/VTUVnrGv6Lvew5KMPwTGMxG1MXiVOvfHE7?=
 =?us-ascii?Q?HLepnw6w2+as1h9MknFwi8UClZWCoWvkKk/AdY+T/YaUcdod0rLqxIwPO4ni?=
 =?us-ascii?Q?Pem1vJ3wzqCjS7LgoVbSoBQQrSVstBf92kzAqPhmj+lgJy3N8nUri9R6wEMV?=
 =?us-ascii?Q?U9qs2D1ORo1M6QMgaxZKKAj2zqCE2TAhvI7ecUqBoNEmy50R5EHUzi3zh80M?=
 =?us-ascii?Q?kaZ6uEz8LfpR7sy0YuSZQ8ho27rwKsCWQqNedLrfAqFkWPljV+ZArPGCY2LJ?=
 =?us-ascii?Q?WkafYUGDwJW6DFgGwk4ImX5CERbdTgiNk0wuJg//bkz2vkHGex+qTjz61e6U?=
 =?us-ascii?Q?WxiGzEtDSvkylucTk+J5Wh6kfjOM0M6TY9FRRCvZGv8Ibx8MLoL/KqJKCIGg?=
 =?us-ascii?Q?3vCcm7lBR5lfZ7GeS//yrmEypIfdpFO73uyM2DFHKkK9nb8nlT+vwvE5+z66?=
 =?us-ascii?Q?MEiNNNdAQTpTnC9ZGXC42ACBAw5jJqXAoLQG749A9NSsMNhmB7YIwHK4w/lE?=
 =?us-ascii?Q?uf4B8+l0nqb9v7nCdHu5MJxs9oh79rc1l+R0d/Ht+bhMhkz3wRIUAi5SptEW?=
 =?us-ascii?Q?LAH0jvZVMS6NBu9S8ijJPTE5xIi6jOgv+BSEyNlFnAhQEOeu1qu3XDEjygMx?=
 =?us-ascii?Q?O9VzD2klIMBl+l7RRubfRM2I/Bck1qzyKSgTx6qJNnNjcbgkF9nyLoNHh+sV?=
 =?us-ascii?Q?VPM++gOlmS/d6vw5T/4wsPl6OpA4EgMHT8qoD9AhvvNnRauMWHJB4dxlX0T9?=
 =?us-ascii?Q?qQ=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	c+bZnZftEnXUmrYBBtIHppAP7GjdenmPBTwY2niEPjZS8f8lG0Y5fZPbWTVr/6Tm/cprcgLOQYF082ErfEa0GVc5dSYT4aoox8vKBLXhrT9wheEqbIPL9PmDSMSJM5/1chmvEOK9etxpCIMS5ZXXpWuYB0nureMz0QMLNfuNebITzSYUUfIGu0SI9M4wqa9dO7Np95tbc8gq9oAm/IfzjsMHAf8C+38ly8vmse8+fCGsiQahqj89F3ODHduPPxxO1MsEirpWZiBIkiY72sbLwuo3WFUYDFVTWZbUcxw1voqmPyzF0xjN1WWHe+fypuNl/C8Zcog8ZHxNdELFL+I/SAOfSJSCsS4FQr/gc2kNyNxGp6dNb+9zwW319IN1Jw1P/lHVn1e3cpKsYov6L0barzkge8TU1wUu6r4LxXBhvWNciu5WBy1EKdwwYV86HlC22SRbLYrUEF7BqCNM6iEHuhk/4q3VM0NgztG23Al6ctRrqATovkkdukm/IM5YFpT2NyjJnidpTORYMyPS24YDQZ1kanswGTa9UgFvVo+lO9Z55Q9C2jJCuAZmQShdqoBZQKaF+iMiqS/ZqJq3K5bJsZnyzG8lS/4UnqaA68rFlLs=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fc49c42b-a1b0-46e5-9486-08ddec7090cd
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 11:37:16.7458
 (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: +dNlOAEL0eaf+T6kt230J0oqZ0K0THABh0XEsdPQ5Fmgo9UKpuIXSertBETPG1zVM69EDPWZr6xXvzpju9ofaDNdS68EHjw9ljOCGXy8lRg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB5001
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-05_03,2025-09-04_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=529 adultscore=0
 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 malwarescore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2508110000 definitions=main-2509050113
X-Authority-Analysis: v=2.4 cv=S5LZwJsP c=1 sm=1 tr=0 ts=68bacb75 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10
 a=yJojWOMRYYMA:10 a=GoEa3M9JfhUA:10 a=k0bjli3dSpF5586gfPcA:9
 a=CjuIK1q_8ugA:10 a=zgiPjhLxNE0A:10 cc=ntf awl=host:13602
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA1MDA5OSBTYWx0ZWRfX9Y/AFm3+mYEA
 BgFw3Tsl7UbWYEwf/W+zGPl3aTIcZpGOVy2T0gPrnTAk3CxgotAmHIbS0rWpOYLLghsPGMVW7MB
 sh9zW3CtRXTBmkTB1Sxs0LiKKV4WbJLZtVokaf25Bvxg3uXto3de6S/m9E7A+lz1uGeCKWnyD5G
 2gAJJv3nXJLjXl7ZQva/AthbJNNXqpxrHVlh9rnRPpcp5FuWw/aPckCKfSNK5660NMmLhX4TD4Y
 ZOal5O686U3QhuEoODfU3revcacsCW56DiVgideABrDqPIILIhbUh6GQhjPy8xtLyEM/VTbAvm+
 pjGgoydk+CErPng9eB7X9gH9VDrQsWZsCFMb+SntZSOWmQdzLahdyFQK2Zg9teB8RhQj3T9oScV
 qODw5Q/rjr2opmSks2701j8vw4CeIg==
X-Proofpoint-GUID: L_lVgzNe9MXAU-MQbQYbTCyXie_sA9if
X-Proofpoint-ORIG-GUID: L_lVgzNe9MXAU-MQbQYbTCyXie_sA9if

On Fri, Sep 05, 2025 at 12:21:40PM +0100, Lorenzo Stoakes wrote:
> You should really base on mm-new.
>
> You need to account for everything that is potentially going to go
> upstream. mm-stable is generally not actually populated all too well until
> shortly before merge window anyway.

Just to note that mm-unstable is also fine. Despite its name, it's substantially
more stable than mm-new, which can even break the build and appears to have no
checks performed on it at all.

But mm-new is the most uptodate version of all the mm code.

Thanks, Lorenzo


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:09:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:09:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111853.1460405 (Exim 4.92)
	(envelope-from )
	id 1uuVFf-00006K-3U; Fri, 05 Sep 2025 12:09:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111853.1460405; Fri, 05 Sep 2025 12:09: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 1uuVFf-00006D-0W; Fri, 05 Sep 2025 12:09:11 +0000
Received: by outflank-mailman (input) for mailman id 1111853;
 Fri, 05 Sep 2025 12:09: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 1uuVFe-000067-01
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:09:10 +0000
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com
 [2607:f8b0:4864:20::b34])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fddc9ab-8a51-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 14:09:08 +0200 (CEST)
Received: by mail-yb1-xb34.google.com with SMTP id
 3f1490d57ef6-e9d923fd113so1097311276.2
 for ; Fri, 05 Sep 2025 05:09:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1fddc9ab-8a51-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757074147; x=1757678947; 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=L6dcVvKAjwoIBqTuMR0NE2EE5ndirTQgrU2ANAIeNgA=;
        b=fw4HcMhVXC6f6htpP2IPYHbPQuNRefKrC3KoN3SGqOrBUBZHbPZyngVStm7HX6dm5Q
         KDRjkeNlOASlDEQkODXhEJf+4isabZuM5Gpbr8EcpLizw+M+3pu63flimnwgqgsYf9Xj
         fWiDBhGtG/C1ElqwWMPDQupg5ulNL+3vXng8c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757074147; x=1757678947;
        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=L6dcVvKAjwoIBqTuMR0NE2EE5ndirTQgrU2ANAIeNgA=;
        b=wxaEHMvg5M5LNACGqIVWvBEbW5ZUWpJPEgs3a3+XGcQNx0TLoHK9QBOirt9BLWqQQc
         Xj/qPU4+5rge2M/DlXxNkfUH7DQqCcMbQuq5jW83Gb40qPdW/OGub1i/bgNQ0JSf4/2q
         dmuNF9zLZ3isHYkS2+gMRwXqxloEYU3zK36JLpP91PLbiI6iQkinTHaowHEIFKj7/nQ9
         Hpzi9f4Iz3NzWRhE+9fLDehu5QTkwETk7NFBPYM4P8lhayOxDiH5EaucmpjZZD2MKysa
         5lhxzmPV7GiyM8+Fbne4f72VZX4EHOQx+4m/+0Bz/7V+HlmQJyB6JmSlg+lDYr2WPR7O
         wECw==
X-Gm-Message-State: AOJu0YyFOpKWUCQMC/rNgDHnMDjDDLkQWw04+jplt+PbSntg+wZ99FBP
	/L/ecGtfnCKSU5OS5/pvrBLJIc3Wkrd9chakL+gamrwLJpxC1q1MdliCE387asGKacycRu2htcc
	sCru9xiLFmu1AhNPlH3bghBgWfTKe30vSgZR5AWvswg==
X-Gm-Gg: ASbGnctG9Bmcu9hI79k09SmdXesMibWs5MzfTyCFjxofaeiLYSvjyokJvgxnLNhO+eq
	SfrEGExzN3Tfyn2C/390mbnCUwuT0yAUXbpnK4d2ECJX/ui0i1tlLzTIH67bNM7VjpDQisacaAr
	/MDxyUJy85I/anrOcQOeyvC+IpOtM9svrI2GYQY8y+U3g+o7w9EyrBT5hniX+h6xjSehPN9OZkl
	wi07w==
X-Google-Smtp-Source: AGHT+IGPkPU0/y/W/HItoasQxFHnB19hgGcm+FlRZOntsVBR4e7rU/aQTLwEO4BKBAbipW+SQvFUE3hvSI+kFliePQ8=
X-Received: by 2002:a05:690e:23cf:b0:5fb:de81:ae9d with SMTP id
 956f58d0204a3-60175b908b6mr4486433d50.10.1757074147092; Fri, 05 Sep 2025
 05:09:07 -0700 (PDT)
MIME-Version: 1.0
References: 
 <7f4a47d5dacf5b2db2ddd2ac72c5e0f236f9be46.1757066332.git.gerald.elder-vass@cloud.com>
 
In-Reply-To: 
From: Gerald Elder-Vass 
Date: Fri, 5 Sep 2025 13:08:54 +0100
X-Gm-Features: Ac12FXwD_uvT_uxrnZk5YZSh7zaujGQOvfRmBsphzZDrdmDZ9bFjz2-Ox-5ZuDQ
Message-ID: 
Subject: Re: [PATCH v3 2/2] efi: Support using Shim's LoadImage protocol
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: Xen-devel , Kevin Lampis , 
	"Daniel P. Smith" , Jan Beulich , 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: multipart/alternative; boundary="00000000000061cc84063e0cb461"

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

 

>  Is UnloadImage really appropriate even if LoadImage failed?
Yes, LoadImage can "fail" in a number of ways, some of which do load
the image into the EFI_HANDLE (e.g. image verification failure -
image is loaded then the verification fails and returns an error)
So UnloadImage is needed in many cases, I've intentionally ignored
its return value as it will only unload an image if there is an image to
unload.

> Better be more explicit why it's fatal, like "Refusing to boot
>unverified kernel with UEFI SecureBoot enabled".
I agree! Will update!

Thanks!

*Gerald Elder-Vass*
Senior Software Engineer

XenServer
Cambridge, UK


www.cloud.com


On Fri, Sep 5, 2025 at 12:14=E2=80=AFPM Marek Marczykowski-G=C3=B3recki <
marmarek@invisiblethingslab.com> wrote:

> On Fri, Sep 05, 2025 at 10:05:32AM +0000, Gerald Elder-Vass wrote:
> > The existing Verify functionality of the Shim lock protocol is
> > deprecated and will be removed, the alternative it to use the LoadImage
> > interface to perform the verification.
> >
> > When the loading is successful we won't be using the newly loaded image
> > (as of yet) so we must then immediately unload the image to clean up.
> >
> > If the LoadImage protocol isn't available then fall back to the Shim
> > Lock (Verify) interface.
> >
> > Log when the kernel is not verified and fail if this occurs
> > when secure boot mode is enabled.
> >
> > Signed-off-by: Gerald Elder-Vass 
> > Signed-off-by: Kevin Lampis 
> > ---
> > CC: Marek Marczykowski-G=C3=B3recki 
> > CC: "Daniel P. Smith" 
> > CC: Jan Beulich 
> > CC: Andrew Cooper 
> > CC: Anthony PERARD 
> > CC: Michal Orzel 
> > CC: Julien Grall 
> > CC: "Roger Pau Monn=C3=A9" 
> > CC: Stefano Stabellini 
> >
> > v3:
> > - Use Shim Image by default, fall back to Shim Lock
> > ---
> >  xen/common/efi/boot.c | 59 +++++++++++++++++++++++++++++++++++++------
> >  1 file changed, 51 insertions(+), 8 deletions(-)
> >
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index e7e3dffa7ddc..1f63473d264d 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -38,6 +38,8 @@
> >    { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20,
> 0xe3, 0x94} }
> >  #define SHIM_LOCK_PROTOCOL_GUID \
> >    { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd,
> 0x8b, 0x23} }
> > +#define SHIM_IMAGE_LOADER_GUID \
> > +  { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a,
> 0x55, 0xab} }
> >  #define APPLE_PROPERTIES_PROTOCOL_GUID \
> >    { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30,
> 0x3a, 0xe0} }
> >  #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
> > @@ -70,6 +72,13 @@ typedef struct {
> >      EFI_SHIM_LOCK_VERIFY Verify;
> >  } EFI_SHIM_LOCK_PROTOCOL;
> >
> > +typedef struct _SHIM_IMAGE_LOADER {
> > +    EFI_IMAGE_LOAD LoadImage;
> > +    EFI_IMAGE_START StartImage;
> > +    EFI_EXIT Exit;
> > +    EFI_IMAGE_UNLOAD UnloadImage;
> > +} SHIM_IMAGE_LOADER;
> > +
> >  struct _EFI_APPLE_PROPERTIES;
> >
> >  typedef EFI_STATUS
> > @@ -1047,6 +1056,46 @@ static UINTN __init
> efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> >      return gop_mode;
> >  }
> >
> > +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> > +{
> > +    static EFI_GUID __initdata shim_image_guid =3D SHIM_IMAGE_LOADER_G=
UID;
> > +    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_G=
UID;
> > +    SHIM_IMAGE_LOADER *shim_loader;
> > +    EFI_HANDLE loaded_kernel;
> > +    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> > +    EFI_STATUS status;
> > +    bool verified =3D false;
> > +
> > +    /* Look for LoadImage first */
> > +    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
> > +                                           (void **)&shim_loader)) )
> > +    {
> > +        status =3D shim_loader->LoadImage(false, ImageHandle, NULL,
> > +                                        (void *)kernel.ptr, kernel.siz=
e,
> > +                                        &loaded_kernel);
> > +        if ( !EFI_ERROR(status) )
> > +            verified =3D true;
> > +
> > +        /* LoadImage performed verification, now clean up with
> UnloadImage */
> > +        shim_loader->UnloadImage(loaded_kernel);
>
> Is UnloadImage really appropriate even if LoadImage failed?
>
> > +    }
> > +
> > +    /* else fall back to Shim Lock */
> > +    if ( !verified &&
> > +         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> > +                                           (void **)&shim_lock)) &&
> > +         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
> > +        verified =3D true;
> > +
> > +    if ( !verified )
> > +    {
> > +        PrintStr(L"Kernel was not verified\n");
> > +
> > +        if ( efi_secure_boot )
> > +            blexit(L"Failed to verify kernel");
>
> Better be more explicit why it's fatal, like "Refusing to boot
> unverified kernel with UEFI SecureBoot enabled".
>
> > +    }
> > +}
> > +
> >  static void __init efi_tables(void)
> >  {
> >      unsigned int i;
> > @@ -1334,13 +1383,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDL=
E
> ImageHandle,
> >                                        EFI_SYSTEM_TABLE *SystemTable)
> >  {
> >      static EFI_GUID __initdata loaded_image_guid =3D
> LOADED_IMAGE_PROTOCOL;
> > -    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_G=
UID;
> >      EFI_LOADED_IMAGE *loaded_image;
> >      EFI_STATUS status;
> >      unsigned int i;
> >      CHAR16 *file_name, *cfg_file_name =3D NULL, *options =3D NULL;
> >      UINTN gop_mode =3D ~0;
> > -    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> >      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL;
> >      union string section =3D { NULL }, name;
> >      bool base_video =3D false;
> > @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE
> ImageHandle,
> >       * device tree through the efi_check_dt_boot function, in this sta=
ge
> >       * 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
> EFI_SUCCESS )
> > -        PrintErrMesg(L"Dom0 kernel image could not be verified",
> status);
> > +    if ( kernel.ptr && !kernel_verified )
> > +        efi_verify_kernel(ImageHandle);
> >
> >      efi_arch_edd();
> >
> > --
> > 2.47.3
> >
>
> --
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab
>

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




<forgot to use reply all!>
>=C2=A0

Is UnloadImage really appropriate even if LoadImage failed?
Yes, LoadImage can "fail" in a number of=
 ways, some of which do load
the image into the EFI_=
HANDLE (e.g. image verification failure -=C2=A0
imag=
e is loaded then the verification fails and returns an error)
<=
div>So UnloadImage is needed in many cases, I've intentionally ig=
nored=C2=A0
its return value as it will only unload =
an image if there is an image to unload.

>
Better be more explicit why it's fatal, like "Refusing to boot
=
>unverified kernel with UEFI SecureBoot enabled".
=
I agree! Will update!

Thanks!
=


Gerald Elder-Vass
Senior Software Engineer

XenServer
Cambridge, UK




On Fri, Sep 5, 2025 at 12:14=E2=80=AFPM=
 Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com> wrote:
On Fri, Sep 05, 2025 at 10:05:3=
2AM +0000, Gerald Elder-Vass wrote:

> The existing Verify functionality of the Shim lock protocol is

> deprecated and will be removed, the alternative it to use the LoadImag=
e

> interface to perform the verification.

> 

> When the loading is successful we won't be using the newly loaded =
image

> (as of yet) so we must then immediately unload the image to clean up.<=
br>
> 

> If the LoadImage protocol isn't available then fall back to the Sh=
im

> Lock (Verify) interface.

> 

> Log when the kernel is not verified and fail if this occurs

> when secure boot mode is enabled.

> 

> Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>

> Signed-off-by: Kevin Lampis <kevin.lampis@cloud.com>

> ---

> CC: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com&=
gt;

> CC: "Daniel P. Smith" <dpsmith@apertussolutions.com>

> CC: Jan Beulich <jbeulich@suse.com>

> CC: Andrew Cooper <andrew.cooper3@citrix.com>

> CC: Anthony PERARD <anthony.perard@vates.tech>

> CC: Michal Orzel <michal.orzel@amd.com>

> CC: Julien Grall <julien@xen.org>

> CC: "Roger Pau Monn=C3=A9" <roger.pau@citrix.com>

> CC: Stefano Stabellini <sstabellini@kernel.org>

> 

> v3:

> - Use Shim Image by default, fall back to Shim Lock

> ---

>=C2=A0 xen/common/efi/boot.c | 59 +++++++++++++++++++++++++++++++++++++=
------

>=C2=A0 1 file changed, 51 insertions(+), 8 deletions(-)

> 

> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c

> index e7e3dffa7ddc..1f63473d264d 100644

> --- a/xen/common/efi/boot.c

> +++ b/xen/common/efi/boot.c

> @@ -38,6 +38,8 @@

>=C2=A0 =C2=A0 { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0=
xcf, 0x20, 0xe3, 0x94} }

>=C2=A0 #define SHIM_LOCK_PROTOCOL_GUID \

>=C2=A0 =C2=A0 { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0=
x10, 0xdd, 0x8b, 0x23} }

> +#define SHIM_IMAGE_LOADER_GUID \

> +=C2=A0 { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, =
0x3a, 0x55, 0xab} }

>=C2=A0 #define APPLE_PROPERTIES_PROTOCOL_GUID \

>=C2=A0 =C2=A0 { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0=
xab, 0x30, 0x3a, 0xe0} }

>=C2=A0 #define EFI_SYSTEM_RESOURCE_TABLE_GUID=C2=A0 =C2=A0 \

> @@ -70,6 +72,13 @@ typedef struct {

>=C2=A0 =C2=A0 =C2=A0 EFI_SHIM_LOCK_VERIFY Verify;

>=C2=A0 } EFI_SHIM_LOCK_PROTOCOL;

>=C2=A0 

> +typedef struct _SHIM_IMAGE_LOADER {

> +=C2=A0 =C2=A0 EFI_IMAGE_LOAD LoadImage;

> +=C2=A0 =C2=A0 EFI_IMAGE_START StartImage;

> +=C2=A0 =C2=A0 EFI_EXIT Exit;

> +=C2=A0 =C2=A0 EFI_IMAGE_UNLOAD UnloadImage;

> +} SHIM_IMAGE_LOADER;

> +

>=C2=A0 struct _EFI_APPLE_PROPERTIES;

>=C2=A0 

>=C2=A0 typedef EFI_STATUS

> @@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPH=
ICS_OUTPUT_PROTOCOL *gop,

>=C2=A0 =C2=A0 =C2=A0 return gop_mode;

>=C2=A0 }

>=C2=A0 

> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)

> +{

> +=C2=A0 =C2=A0 static EFI_GUID __initdata shim_image_guid =3D SHIM_IMA=
GE_LOADER_GUID;

> +=C2=A0 =C2=A0 static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK=
_PROTOCOL_GUID;

> +=C2=A0 =C2=A0 SHIM_IMAGE_LOADER *shim_loader;

> +=C2=A0 =C2=A0 EFI_HANDLE loaded_kernel;

> +=C2=A0 =C2=A0 EFI_SHIM_LOCK_PROTOCOL *shim_lock;

> +=C2=A0 =C2=A0 EFI_STATUS status;

> +=C2=A0 =C2=A0 bool verified =3D false;

> +

> +=C2=A0 =C2=A0 /* Look for LoadImage first */

> +=C2=A0 =C2=A0 if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_ima=
ge_guid, NULL,

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(void **)&shim_loader)) )

> +=C2=A0 =C2=A0 {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 status =3D shim_loader->LoadImage(fals=
e, ImageHandle, NULL,

> +=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 (voi=
d *)kernel.ptr, kernel.size,

> +=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 &=
;loaded_kernel);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !EFI_ERROR(status) )

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 verified =3D true;

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* LoadImage performed verification, now =
clean up with UnloadImage */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 shim_loader->UnloadImage(loaded_kernel=
);



Is UnloadImage really appropriate even if LoadImage failed?



> +=C2=A0 =C2=A0 }

> +

> +=C2=A0 =C2=A0 /* else fall back to Shim Lock */

> +=C2=A0 =C2=A0 if ( !verified &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(efi_bs->LocateProtoco=
l(&shim_lock_guid, NULL,

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(void **)&shim_lock)) &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(shim_lock->Verify(ker=
nel.ptr, kernel.size)) )

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 verified =3D true;

> +

> +=C2=A0 =C2=A0 if ( !verified )

> +=C2=A0 =C2=A0 {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 PrintStr(L"Kernel was not verified\n=
");

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( efi_secure_boot )

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 blexit(L"Failed to ver=
ify kernel");



Better be more explicit why it's fatal, like "Refusing to boot

unverified kernel with UEFI SecureBoot enabled".



> +=C2=A0 =C2=A0 }

> +}

> +

>=C2=A0 static void __init efi_tables(void)

>=C2=A0 {

>=C2=A0 =C2=A0 =C2=A0 unsigned int i;

> @@ -1334,13 +1383,11 @@ void EFIAPI __init noreturn efi_start(EFI_HAND=
LE ImageHandle,

>=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 EFI_S=
YSTEM_TABLE *SystemTable)

>=C2=A0 {

>=C2=A0 =C2=A0 =C2=A0 static EFI_GUID __initdata loaded_image_guid =3D L=
OADED_IMAGE_PROTOCOL;

> -=C2=A0 =C2=A0 static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK=
_PROTOCOL_GUID;

>=C2=A0 =C2=A0 =C2=A0 EFI_LOADED_IMAGE *loaded_image;

>=C2=A0 =C2=A0 =C2=A0 EFI_STATUS status;

>=C2=A0 =C2=A0 =C2=A0 unsigned int i;

>=C2=A0 =C2=A0 =C2=A0 CHAR16 *file_name, *cfg_file_name =3D NULL, *optio=
ns =3D NULL;

>=C2=A0 =C2=A0 =C2=A0 UINTN gop_mode =3D ~0;

> -=C2=A0 =C2=A0 EFI_SHIM_LOCK_PROTOCOL *shim_lock;

>=C2=A0 =C2=A0 =C2=A0 EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL;

>=C2=A0 =C2=A0 =C2=A0 union string section =3D { NULL }, name;

>=C2=A0 =C2=A0 =C2=A0 bool base_video =3D false;

> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDL=
E ImageHandle,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* device tree through the efi_check_dt_boot =
function, in this stage

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* verify it.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*/

> -=C2=A0 =C2=A0 if ( kernel.ptr &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!kernel_verified &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(efi_bs->LocateProtoco=
l(&shim_lock_guid, NULL,

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(void **)&shim_lock)) &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(status =3D shim_lock->Verify(ke=
rnel.ptr, kernel.size)) !=3D EFI_SUCCESS )

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 PrintErrMesg(L"Dom0 kernel image cou=
ld not be verified", status);

> +=C2=A0 =C2=A0 if ( kernel.ptr && !kernel_verified )

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 efi_verify_kernel(ImageHandle);

>=C2=A0 

>=C2=A0 =C2=A0 =C2=A0 efi_arch_edd();

>=C2=A0 

> -- 

> 2.47.3

> 



-- 

Best Regards,

Marek Marczykowski-G=C3=B3recki

Invisible Things Lab



--00000000000061cc84063e0cb461--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:10:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:10:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111863.1460416 (Exim 4.92)
	(envelope-from )
	id 1uuVGy-0001XW-Fm; Fri, 05 Sep 2025 12:10:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111863.1460416; Fri, 05 Sep 2025 12: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 1uuVGy-0001XP-BF; Fri, 05 Sep 2025 12:10:32 +0000
Received: by outflank-mailman (input) for mailman id 1111863;
 Fri, 05 Sep 2025 12: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 1uuVGx-0001XF-1D
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:10:31 +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 50d8651c-8a51-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 14:10:30 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-b0454d63802so346344066b.2
 for ; Fri, 05 Sep 2025 05:10:30 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047a90387esm449572366b.0.2025.09.05.05.10.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Sep 2025 05:10: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: 50d8651c-8a51-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757074229; x=1757679029; 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=8crF7tA8X8rS5SsOrxDZg6mAqCFfsL8KpASg5b0qYF4=;
        b=iIuTUu3jNAS5Qb8M33IDFKL1ozST3IQOIxPxgL5wO3IZqXqW5ByGvthclG3MqqEr4X
         UxKOT6/sRTWG44IQzmMOWkpS71LHvftjefYSVWGeyW7F9u58MttIBuTDT3l/S3Mv5jsh
         heiJPsx9/8QhRr0EyE5oozX2OsMLDh4d+joKE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757074229; x=1757679029;
        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=8crF7tA8X8rS5SsOrxDZg6mAqCFfsL8KpASg5b0qYF4=;
        b=KxUM+m7OMB/nyjUyU/K1QqkaxxfnZ76VlnPexe82yblQqtIe7+2nEfmAwXwT4kbGCk
         mE1/DSw8XTRsq9UymQvqtB+zu7F+IW6BiWTrmW5gnww8lLBw+bPf9TdSZPn3lkD59pyi
         CrpurlBCFge9JaXFuEZB+AkF3T46jMPws7Q0NvQ2KX186AGRgDuwaIKx4v2jFFJFJi7o
         cNPdPVfSwwbVsMCoCCCaBn6CMgiX+3kraVJ9p/E1sQmoad7ueUhDTsT4vwUsI+cW8NUX
         UYeHAs3nOYIbAQAkFzUnaZdD83CkpIVjJb6WCtomR3/Bzm8J9/v1ESQCIz6npA2lkeNl
         NMqA==
X-Gm-Message-State: AOJu0YxWNWj1fGaMKEFFDZLsEbtgKY0lIEycSJn0AMOMw8y245wFvRhP
	eru3hpeJrxxMF8TLfbiSj/tTpWgp4PooUHJI8w5x2D92jmMIRXuGKzHw4cAzGqhAm9xhscASAgI
	BAttY8iY=
X-Gm-Gg: ASbGncu38JiKd8/GNRZnbCH7510Mzs6UcwfCMjSVbHCuBTdr9iSo4fJLCjrG7lCb/RE
	eaoy5S26dnEltWkkPv+waaTJ5EPHLWeN3AqSdBTncHrvVBTvoFQ4qoKyfgo8aoNE+yD8VLS4Z17
	ypfcpIVXkHZXZtkc9dZFFNNEgNOfN7rMZnEehj1cZCFepW7VosNcdVqBDoBdahWzjPAaIbGT0ht
	8ATP9vlDB0qxLFAb93WB9KUpZTYyYSGXK3Vz6ab7P6OnPNZcbRwImkIjGFp93Ol4zKvHjBxniSn
	DCARvfZhIB8VNXBk1KuyqfJjYMMT3guxSwx8m4QM868wkLEKa375wsxVnd3G26fA/HKOwGBMKRt
	eRup7kOy/pe1v+KTwTY6U3BNjPZo4ltnfYNPdjDRbujfiKTDa8pOU2dUq
X-Google-Smtp-Source: AGHT+IEeKMxfRq7U488RdLBJJu/9JCSt+X6cbrSK6sM8m9YlWylMRCGg7LNRKpgvm9xPt8Jkvqxa+Q==
X-Received: by 2002:a17:907:7f8d:b0:b04:4147:9f81 with SMTP id a640c23a62f3a-b044147a275mr1482781166b.21.1757074229402;
        Fri, 05 Sep 2025 05:10:29 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 0/2] efi: Support Shim LoadImage
Date: Fri,  5 Sep 2025 12:10:16 +0000
Message-ID: 
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Support Shim LoadImage protocol but keep Shim Lock for compatibility

https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2023841743

Gerald Elder-Vass (1):
  efi: Support using Shim's LoadImage protocol

Ross Lagerwall (1):
  efi: Add a function to check if Secure Boot mode is enabled

 xen/common/efi/boot.c    | 83 ++++++++++++++++++++++++++++++++++++----
 xen/common/efi/runtime.c |  1 +
 xen/include/xen/efi.h    |  2 +
 3 files changed, 78 insertions(+), 8 deletions(-)

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:10:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:10:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111864.1460426 (Exim 4.92)
	(envelope-from )
	id 1uuVGz-0001lw-NE; Fri, 05 Sep 2025 12:10:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111864.1460426; Fri, 05 Sep 2025 12:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuVGz-0001lj-I6; Fri, 05 Sep 2025 12:10:33 +0000
Received: by outflank-mailman (input) for mailman id 1111864;
 Fri, 05 Sep 2025 12:10: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 1uuVGy-0001XF-7x
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:10:32 +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 51c69798-8a51-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 14:10:31 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-62105d21297so1814811a12.0
 for ; Fri, 05 Sep 2025 05:10:31 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047a90387esm449572366b.0.2025.09.05.05.10.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Sep 2025 05:10: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: 51c69798-8a51-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757074231; x=1757679031; darn=lists.xenproject.org;
        h=content-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=tCVJ1KtX77UItly9lfbYD00bh6qlTFzOOOkAnWGmFuk=;
        b=kQ6h/I8+vbMBtzZB/GJRvYnwAAmD1ZvA+FXC6mV0TuVwn64rpuERoMDY1fHLgp2fVQ
         GaTq5OkWyM5kLlBhM+3bKVoJJmvOPQwm3rH+YI5fyynky2kQ70cAwQh91Be/o82MLOK5
         fhSRP2lazWo/NKveWOwVodns9+nwu/B8JUh2g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757074231; x=1757679031;
        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=tCVJ1KtX77UItly9lfbYD00bh6qlTFzOOOkAnWGmFuk=;
        b=fU18seaKzkl6QZupvyjvweowa3H4fOqkk/dIefiNDHaM4wsG4F0o78fYF06hrAKUXc
         JsAuGrm1JNA7CHNZihlJzH9KdE+U0dvjgDJGSlwvsXwxlsAbaTW7Np+KU9Pc9glsKbt0
         CNWfzyJM1I9zAa+7tgxyxqJk4J5Z6Uxrpee8blx73xTHF6EEJg1vNnp2GRI/rOTmrMui
         cGs0IA/XNmFVqj7YMZIXpA6lIqWdKShhPFoONz41tch/2vS2ZA/EMAZqkVGSh6oFnSpD
         2ZR0aLL4SdQ/4wGawMpMxGL0Bl9BP4JiXZ2aEfjQmcuSJgXKNOWrh0RGNGKhW4oeMYWe
         TcVw==
X-Gm-Message-State: AOJu0Yy9Hq2v1hy4SGAw8X9mstI4czIxPfTKEAvf4FThqS+wAbPsaxpK
	tYzAZBlnwoTstFsvkj9ay94bexHi1ocB96rYHD5yPm06TiwiXAMi2Ig2ZXQhBXEBb349oM6RcOf
	Si+mwP0M=
X-Gm-Gg: ASbGncsDTVPq1OU6XF1caC+laCI5XZ81JRqSosfbFSe4386TeCvXBellZCFS7lYqOMQ
	2bv+JqOCuPGHL2CDNyZcCCZvA17r0GDlNNruAe3nvoow8cW2/QP8FWQZzMFsInG0JW5okhTI798
	/TlFjfES7ZZPdfBqHYSlTbnC8Rh2aX9Ou3TR3JglKIyU8KZZy1Xo9Cw10IxrA0PbDcnzaoURFpb
	P0mQDNky4p9jhuZwmEd0MGi/NghBFmO2vQMjtNWILPkjb0cLW0pSqwj2MqFw4A2l1hB0qDJCzFY
	li9mUNelOprVEH45C9W1h/lDUTvX156idFZR6kIEMVyJTtcJ9n6izzXeLMkGA6M1Vb1F9hbCK1h
	Ej/vXSp8bMpKyFoVHDazUVpcxG7pf0dUnTiy4I41ReIToBEIxz+LGER4c
X-Google-Smtp-Source: AGHT+IENBxJABnMmW4ISKgXr8W7vnZ5lpxYqmjnJ5E8PfEVXu/fSQwGXbfJLQi+hkIeQwACG+sp88g==
X-Received: by 2002:a17:906:fa1b:b0:b02:8bf2:3fa0 with SMTP id a640c23a62f3a-b028bf241e3mr1904808066b.58.1757074230974;
        Fri, 05 Sep 2025 05:10:30 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	Kevin Lampis ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 2/2] efi: Support using Shim's LoadImage protocol
Date: Fri,  5 Sep 2025 12:10:18 +0000
Message-ID: <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The existing Verify functionality of the Shim lock protocol is
deprecated and will be removed, the alternative it to use the LoadImage
interface to perform the verification.

When the loading is successful we won't be using the newly loaded image
(as of yet) so we must then immediately unload the image to clean up.

If the LoadImage protocol isn't available then fall back to the Shim
Lock (Verify) interface.

Log when the kernel is not verified and fail if this occurs
when secure boot mode is enabled.

Signed-off-by: Gerald Elder-Vass 
Signed-off-by: Kevin Lampis 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 

v4:
- Updated error message when failing due to lack of verification

v3:
- Use Shim Image by default, fall back to Shim Lock
---
 xen/common/efi/boot.c | 59 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index ccbfc401f7ba..0a72c293301d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -38,6 +38,8 @@
   { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} }
 #define SHIM_LOCK_PROTOCOL_GUID \
   { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} }
+#define SHIM_IMAGE_LOADER_GUID \
+  { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} }
 #define APPLE_PROPERTIES_PROTOCOL_GUID \
   { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} }
 #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
@@ -70,6 +72,13 @@ typedef struct {
     EFI_SHIM_LOCK_VERIFY Verify;
 } EFI_SHIM_LOCK_PROTOCOL;
 
+typedef struct _SHIM_IMAGE_LOADER {
+    EFI_IMAGE_LOAD LoadImage;
+    EFI_IMAGE_START StartImage;
+    EFI_EXIT Exit;
+    EFI_IMAGE_UNLOAD UnloadImage;
+} SHIM_IMAGE_LOADER;
+
 struct _EFI_APPLE_PROPERTIES;
 
 typedef EFI_STATUS
@@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
     return gop_mode;
 }
 
+static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
+{
+    static EFI_GUID __initdata shim_image_guid = SHIM_IMAGE_LOADER_GUID;
+    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
+    SHIM_IMAGE_LOADER *shim_loader;
+    EFI_HANDLE loaded_kernel;
+    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
+    EFI_STATUS status;
+    bool verified = false;
+
+    /* Look for LoadImage first */
+    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
+                                           (void **)&shim_loader)) )
+    {
+        status = shim_loader->LoadImage(false, ImageHandle, NULL,
+                                        (void *)kernel.ptr, kernel.size,
+                                        &loaded_kernel);
+        if ( !EFI_ERROR(status) )
+            verified = true;
+
+        /* LoadImage performed verification, now clean up with UnloadImage */
+        shim_loader->UnloadImage(loaded_kernel);
+    }
+
+    /* else fall back to Shim Lock */
+    if ( !verified &&
+         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
+                                           (void **)&shim_lock)) &&
+         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
+        verified = true;
+
+    if ( !verified )
+    {
+        PrintStr(L"Kernel was not verified\n");
+
+        if ( efi_secure_boot )
+            blexit(L"Refusing to boot unverified kernel with UEFI SecureBoot enabled");
+    }
+}
+
 static void __init efi_tables(void)
 {
     unsigned int i;
@@ -1334,13 +1383,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
                                       EFI_SYSTEM_TABLE *SystemTable)
 {
     static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
-    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
     EFI_LOADED_IMAGE *loaded_image;
     EFI_STATUS status;
     unsigned int i;
     CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL;
     UINTN gop_mode = ~0;
-    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
     union string section = { NULL }, name;
     bool base_video = false;
@@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
      * device tree through the efi_check_dt_boot function, in this stage
      * 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 )
-        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
+    if ( kernel.ptr && !kernel_verified )
+        efi_verify_kernel(ImageHandle);
 
     efi_arch_edd();
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:10:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:10:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111865.1460431 (Exim 4.92)
	(envelope-from )
	id 1uuVH0-0001sy-5d; Fri, 05 Sep 2025 12:10:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111865.1460431; Fri, 05 Sep 2025 12:10: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 1uuVH0-0001rS-1H; Fri, 05 Sep 2025 12:10:34 +0000
Received: by outflank-mailman (input) for mailman id 1111865;
 Fri, 05 Sep 2025 12:10: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 1uuVGz-0001iM-F2
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:10:33 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 515ca69b-8a51-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 14:10:31 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-61cebce2f78so1814739a12.1
 for ; Fri, 05 Sep 2025 05:10:31 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047a90387esm449572366b.0.2025.09.05.05.10.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Sep 2025 05:10: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: 515ca69b-8a51-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757074230; x=1757679030; darn=lists.xenproject.org;
        h=content-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=Qq7pBlMXUzk196SSVpwT+2Y0XyUckyvg3sSuOL3yYf4=;
        b=gOGP1qEYYq7EEtpmICf0ecrBvXetnZTvd/GFS5rcbA/UBJxSm29pHjjy6U+vvxsHcM
         va0uk6KGqpVhiLokYGrIzcTxnGtEG03Z0irBNOUvJA0oOTws+GSwvawgU07pD7nLCJFX
         TKIJnakWYQydUU9fMusGq4krcUTqeSTuVq964=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757074230; x=1757679030;
        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=Qq7pBlMXUzk196SSVpwT+2Y0XyUckyvg3sSuOL3yYf4=;
        b=pkUtaRnxP0MOkLXWsHyJyEuTCpnlmpGmwAIotp06B9v9NJPEKd/Z1HdkeDVIyAEulc
         wEGooaFBE4t/tE3DF6oIf7fly6o6Gtxv5w1O8IC1xbUDqAoqLdXCP4JwN1gFaySdbWCT
         uY8iCb3VYx61JJ+WpyBkhdtJacGsrq7DaAYvaNSYlIrtvc97pJbkNGyyHnz4zIrL8bv/
         u3xyNO6uaVf7V28x7nKeqkRpRPPBv49s5hxfwmmHZ0QHvF5utv3VAsXG1wRSsAmytKBm
         H02ej+XqQzck1I6sIMXDyn3NYg3JUicQNc4ml/FqveRBgYpqh+HJajiPrWZ8lLLXrVDw
         A6ow==
X-Gm-Message-State: AOJu0YwkD7NeTJSoYTQgZXbLuS7YlU79QjlWFFWazUibY8pdZALhA9we
	FnDyNX9W3nRGr0sSE5/A8dV7WlAukA8u2C7+5MkJiiUH229gUk+0oNI8FkQ7aXv+29ZlmKNctji
	XS2NRxWU=
X-Gm-Gg: ASbGncu/lwtFpLQ7xXKJKu39v6tXIO31m/ggyq2NCaG1lfeN6Hs2/wjC8xGZQ69rkgB
	2EPHXrSpFsmmTTqDMUFkikPnPAH3Cu8PLujhi2sHtg07Kt5OqcByY86JAAw4M1V+P9RqbdwAU2f
	iYJGPGkcMc5HZ5ErR33tDAnfZPMJqe1ENAbP3Hdwbv0+bqsh9aK6FPmPQeQUcl4gaF8Kpey/iwM
	t5LJQvKK74Tzjb5S9OXARwl4lqLL2vhs6stdgVSijku4sor3RNC5kf3z4aRdmvMPFg/cYCxG+JN
	AYScPpMNl2zqiZpyLrQ/R9kpPJ2/737umwRY187nAglM3sfNtdOeA7+bjSU1dNqrVHEPA3TQ8t/
	XO3fzAzZbowau55eCS8yPIHDmpb6dLglxhmAnTm52XCuXu1tHROtgJoy4
X-Google-Smtp-Source: AGHT+IEYIENivCBYfWiF16ynv9kaKCpeL4Aeae5riBc6o5Trad7rO87ISKFzxQnqcX6pDfXZ65ce5Q==
X-Received: by 2002:a17:907:c14:b0:afe:fbee:88a with SMTP id a640c23a62f3a-b01f20bc537mr2355837466b.59.1757074230244;
        Fri, 05 Sep 2025 05:10:30 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Ross Lagerwall ,
	Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode is enabled
Date: Fri,  5 Sep 2025 12:10:17 +0000
Message-ID: <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

Also cache it to avoid needing to repeatedly ask the firmware.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Gerald Elder-Vass 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 

v4:
- Fix MISRA warning regarding SecureBoot string
v3:
- Fix build on ARM
---
 xen/common/efi/boot.c    | 24 ++++++++++++++++++++++++
 xen/common/efi/runtime.c |  1 +
 xen/include/xen/efi.h    |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e12fa1a7ec04..ccbfc401f7ba 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
                    " last line will be ignored.\r\n");
 }
 
+static void __init init_secure_boot_mode(void)
+{
+    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
+    static CHAR16 __initdata str_SecureBoot[] = L"SecureBoot";
+    EFI_STATUS status;
+    uint8_t data = 0;
+    UINTN size = sizeof(data);
+    UINT32 attr = 0;
+
+    status = efi_rs->GetVariable(str_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;
@@ -915,6 +937,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 42386c6bde42..30d649ca5c1b 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -41,6 +41,7 @@ void efi_rs_leave(struct efi_rs_state *state);
 unsigned int __read_mostly efi_num_ct;
 const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
 
+bool __ro_after_init efi_secure_boot;
 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 623ed2ccdf31..723cb8085270 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -36,6 +36,8 @@ static inline bool efi_enabled(unsigned int feature)
 }
 #endif
 
+extern bool efi_secure_boot;
+
 void efi_init_memory(void);
 bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
 bool efi_rs_using_pgtables(void);
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111879.1460444 (Exim 4.92)
	(envelope-from )
	id 1uuVHM-0002tN-CZ; Fri, 05 Sep 2025 12:10:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111879.1460444; Fri, 05 Sep 2025 12:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuVHM-0002tG-9p; Fri, 05 Sep 2025 12:10:56 +0000
Received: by outflank-mailman (input) for mailman id 1111879;
 Fri, 05 Sep 2025 12:10: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 1uuVHL-0001XF-ON
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:10:55 +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 5f51c157-8a51-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 14:10:54 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB7352.eurprd03.prod.outlook.com
 (2603:10a6:20b:2e8::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 5 Sep
 2025 12:10:52 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.9094.018; Fri, 5 Sep 2025
 12:10: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: 5f51c157-8a51-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sW5Snc4UmwpWJirlP0cuRBw28bi+LqZvfg4RGxBL5hOcFTFz+LhECW0ytZAOE/3qrWezyz8cgsw5RKPVEZAZXq7zvgRoJl0ZYctW+oqy+5/WUziQi2hDdYIGNM1D49cMwgJDiZE0YaIwakKawny09u+wWlJi1pCooUyZKrKI5qUj1up2RzwyxfisFzML+VZka2v+SJ92iFRm7/kdZR+fb3fjDnv1VvB7EdSh3hc3h1BCp7if54LtRxjIVVGGjXrq5NGQapADrvzVNgxQimseJKhXDQPs6Z6qk+epA7y5zhvgL4/NLFoGjZ+02pDKU6vK51ToHn/J5q5+rfLmwLoHbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zVHrUv1HLYFkWeYJcqq6TRl5KnEXLxpIk0HHERA93jY=;
 b=YwUBKNrCzRpKpApoa46Xh/jKuwkDY0lpQvutpP0aXsMRuHkY676MZXzCEZEyOb3qMHA7z/BWjX0AihItJd+kUfkq561P9Kq4aGgeg/iwECtRniFmsuzKEF7WPGcXK0BLHiP2vCyu4jEyuGGlb5nKF7m5r4NFho2fd9459mSz6YwKiHyjqgf9tY9hR0DlXJ5aiatBkXCEnx3XJaL2qfcbI2TKqiCaRaM6JSCsW7dlS8jr9hXxwDBEynue/pKEeaEAjbvO2WnP/pdNSoHMYy4W4QK7BaIIHLpDzVNJebtDmjO3LQu59Dht14frvrwZGnQ5YgSpEQPeB/FujIFjHjHtEA==
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=zVHrUv1HLYFkWeYJcqq6TRl5KnEXLxpIk0HHERA93jY=;
 b=Wkztak4dcVR6KrsVa5GVmQGlnPoDmGpYipXFsWY8rfxjdsFH9f15DINhDsEoWEaKTe5uZz3WKjBh3F2lK62cFbF3bJPO50JPQdlIxgZ15fvQnPUG2C9cVAq8qsilG8Ckq8MWaz2W9IMlWzVQDLoC12hP1yt+yZsByD15xR43LoPVqCXjxvH03uP9nKsw2oOnCQoD025fBEtxKlUD0J/vWzkfutmPoF1oWcmf1e5nRXJtSCqqS+YmOsP80zejrgnlL8AOj3tCcaNEt1sZX+8XIP5TKUKIGbRbj8fHC70+m9LrlnpYiPaonOQDWp4k0o29PYD4bZUCFJQEWZ0015/+cw==
From: Volodymyr Babchuk 
To: Grygorii Strashko 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Subject: Re: [PATCH v2 1/4] xen/arm: split set_domain_type() between
 arm64/arm32
Thread-Topic: [PATCH v2 1/4] xen/arm: split set_domain_type() between
 arm64/arm32
Thread-Index: AQHcBrdwRN56SCuvyEipomT5fYlVlA==
Date: Fri, 5 Sep 2025 12:10:52 +0000
Message-ID: <87tt1hqeus.fsf@epam.com>
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
	<20250806094929.293658-2-grygorii_strashko@epam.com>
	<87bjo13976.fsf@epam.com>	<2cdcd8a6-0f14-4a4e-ac56-f0c33763ad53@epam.com>
In-Reply-To: <2cdcd8a6-0f14-4a4e-ac56-f0c33763ad53@epam.com> (Grygorii
	Strashko's message of "Thu, 4 Sep 2025 23:09:35 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS8PR03MB7352:EE_
x-ms-office365-filtering-correlation-id: 14e6f3ae-f329-441a-09f0-08ddec75423c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|42112799006|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?pZL8f3rJQxeHFOdjcNst/gX8xNwtLEd8h/w0tiQUDR4N/lcNZfnT0tt6Ga?=
 =?iso-8859-1?Q?MNL+Eajdgf8I0YZJevBFvaPJbijPqEnwdLm7HVnrQkCu/SIgEVM3yhGMDF?=
 =?iso-8859-1?Q?1wApQWG8ZeahI1QWmWFGkP7wTx0iaiHGS8ktamNnHL1lKiY5fW4Luqfni4?=
 =?iso-8859-1?Q?U/9Y0YK9AdgrypjJqoZuc9W5C2KVZQaSEPMqqdgAzQbAZPstehlwEkhWLk?=
 =?iso-8859-1?Q?9vrQS2w/I/TG3CvODsJYDhQJyYvZ1JiPoscG7XCOqze5t1znlCwlE2LI95?=
 =?iso-8859-1?Q?MhSbrMZjdJoG/bAqP7ouji0lCvApzpNaj6+XY/2d5LNo1Cnh7JavnCPWQw?=
 =?iso-8859-1?Q?hOOGlCrhM9BzR36YrMlmK510L4U1TjgksKhJ7fKJLAM+1nq0P9VdT4Wo//?=
 =?iso-8859-1?Q?JIywbeVKgnjWlySXKXzeNBfgGIa7jWQUsY73mRBjJeVj1CEZuF3DIsBUbg?=
 =?iso-8859-1?Q?qGkNkp7R+Mzt+wuOEuHjzt4EFkkr8s0iuhxXBDC9glx/8h7wyu4CjYeHkP?=
 =?iso-8859-1?Q?dXvV0Yf2fhWAQ+NsLuELGefq0kieRO96h7wnHB9i8NmPYoIWAUDnG71lWw?=
 =?iso-8859-1?Q?LMocjgiQV6OlA8bKfdPj9B6I7sW7uPnVNqpKj2MLc8aJB+duzwz0+oIvI0?=
 =?iso-8859-1?Q?Ub/ZfmkfgMoJQrJm0xHCKSB/5x0PofWTuM5qD48D2FoEJdve5n5Pao2ty2?=
 =?iso-8859-1?Q?t5K9abKbAHizovI4/5VODdyWteuig0aqgcjjmLkmERfmOETaS8l0IZyRr7?=
 =?iso-8859-1?Q?E9xzvLxIHgXrDBT0jrtrppvnT5B6uGAQeGENMcWQgalPtFx3YgzlABq7mF?=
 =?iso-8859-1?Q?og97iCglx4Uo2wHjXPY4fIit8Bem3uXMj7+jLT6gtoVuSIwZqfQhC+qzC6?=
 =?iso-8859-1?Q?NccpENFepkT060S4hbTDJGUzsvU9smJkdDwZtM2Zih88OnnMtjPaDIP3Zt?=
 =?iso-8859-1?Q?RGhusDc5SbJM54ZBGY81uxsJRxW5YMJrJaupKcPKFg5ytjfRC2i+sSkE2/?=
 =?iso-8859-1?Q?jmGTWz4aar3cE4Hu1ZKVu6BLyjLxtWcjvRjE9uaVQ85i6VI7vhjMsgFUrZ?=
 =?iso-8859-1?Q?+g6y+Rk9qHyD6QhdOcadHMFLCe0X8PnPw8Sq8enpdNXZelTAuBoLEGYJo5?=
 =?iso-8859-1?Q?ZZFS7rFAbG7OKOTbgP/0wuY5IYMZtyW33Y055fLhtM5cIwJOBmOVt3o9Y/?=
 =?iso-8859-1?Q?G83HViChx+LMaltYoooXRb7ZcVkJs80wQPmMsg3GZl6333UqscFo0/6rjV?=
 =?iso-8859-1?Q?cN/UkzK6MNiT/+hqr9ZFtymINA0ec0k/EknkGiJfNvgNF0tWsaaS1js/lR?=
 =?iso-8859-1?Q?Oll9zgQ3eWLDlIv+I2FeryzTrUv2dOZCQJ/k7c0o2/grxiLVqO9PzUr5QY?=
 =?iso-8859-1?Q?eMjgfVdrGiHWprBAhNgxiiV2Cx5s0kqVwPMVIkPLSmOiMuREWdLztpFHhK?=
 =?iso-8859-1?Q?Y6hryKANDb+8G6OIVrYbhBheag7TqgFoKmljaLFXaG0uXLDtrnLIFie7SQ?=
 =?iso-8859-1?Q?jwk6moRVtIHR4+wrfitLCFuwGJDF2agyvaMMhgaVoZ9g=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(42112799006)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?/KbwqlyLXGpEOmfrGvbqUb6sqLrw7ikNBK9p7KqzQRaTyCg8IjxAWBGmu6?=
 =?iso-8859-1?Q?WQpcks6u9hgdXG1sN/Gds8WDcnq9yU4d6GEisWKkwr9flSllXOYlQ2oeOr?=
 =?iso-8859-1?Q?Ioz19JSBvftd3J3S88tVDrQqUOG3/kbpBY1S5kbAnw/INZhQzzgx+YdDwq?=
 =?iso-8859-1?Q?RBpeRr6bbuIzb1i/JuyhE3a6SFkAbRZfJKcU8i6U2EG3v4PKA5xoplIEb9?=
 =?iso-8859-1?Q?kzX7aVwTWKm10EHyu3A3mwJjI9bGan3LIV9sxQhZ0uoImL3/B3eZGb0awK?=
 =?iso-8859-1?Q?eyZnSpN6bkwDIuUht+ijIU3LvgOmMew2b4rCo4B0BMtyIlyD16YaHxEOk8?=
 =?iso-8859-1?Q?EQnPGHRIfxrkgAzswYORsBGhWhSYkWkJ+r8rIdpURH2mSlSpNNkxNMapwg?=
 =?iso-8859-1?Q?0II6j0GK70ZKWvnjoqd2nGho3bMbgWCfiJPRgOj2+yGXF2i5T/rwdTQmRy?=
 =?iso-8859-1?Q?siuBZiqRyvc2mHJG1AAUdjJX54p/gnV9Cy2mFMiqHoI/FCUY5yfWO2k9LU?=
 =?iso-8859-1?Q?455NsaagOLxSEW16lyMFC28t8X4UaJDsQWyWwb5Xs9LjLOBI4mvfaN5fPr?=
 =?iso-8859-1?Q?zx7ZadDp9SHUOYSKjIEVzIyuovChDLnPpvsNVkO2tRYw5tvpPCLeeZ/ggP?=
 =?iso-8859-1?Q?ZPx1aPpa9aAqpJsPouGi6ayJPE/sQ76wmewFuyWKQY9R3zMByuLUyEnPiv?=
 =?iso-8859-1?Q?lt7HRVtPXFmQTceTpRg8OBJX1y28PUTJQ5GyP4rqBqfuqurpmB3o6ix9wz?=
 =?iso-8859-1?Q?/unZlPa7A0pVjGsQ8m394hMHpj6LXED3WN29J5SbEFe6e913bwOmOJLB4S?=
 =?iso-8859-1?Q?AoB0VkLWLHRmoLm2ZSa0IOATZwS1AN0txLSFF83D4fKkii9CFjomY4zqKO?=
 =?iso-8859-1?Q?yWHZHm1PZjIj8G3gVANI45aDD96TdpjoR4cQ1DZO5raldJixM0Phh+92Th?=
 =?iso-8859-1?Q?3dwiJr1MrJq66/wep4L94Di1/DvfMNJ84um7CD5belZ2/OjDmx/yOtvqfw?=
 =?iso-8859-1?Q?/+bxET+X3pJ/8P8t3qEGt3rG8olmWDvwwHGXdBll2Yu8uS8ZEr9JqDwFNs?=
 =?iso-8859-1?Q?GW0TciUKhrrImUcwYBsZnt+M1NusY+HfTNSEzC4DTzpApWBu2m+ym72tGe?=
 =?iso-8859-1?Q?tD2nTfL+tsizGkS9c/SqKCAM9n7spgoFZ5fTAWb13WGaZbCeu/VD+y1H5K?=
 =?iso-8859-1?Q?efaB/kvSBmmlz0qxlZJg8QHPgZIH11nJtNIwU5i8oB/YDvZOe/3I/Sex1I?=
 =?iso-8859-1?Q?cRFLieh08kf+Fc358vLdaEZ2DtZit1oD8IPttYtzalLadjDNESIxRVUxTt?=
 =?iso-8859-1?Q?wvNXnpBL9BqYt3j3LYt2o5ZnT/RHBd67NK89yW4/ro24xlZ3h3saOZKJlC?=
 =?iso-8859-1?Q?MH+7rVVxczvlLmRbf2WEGfjvLjps9TdJSag0gE1UocwYBYA6emqbKBoX9U?=
 =?iso-8859-1?Q?bXAZaW3ID8p9mW+Aso1omN05HvXAIHpbY7iKW8c7dWGQa5yMyEw1d/H0tn?=
 =?iso-8859-1?Q?cYbKSZ7jQTBbb/m04AMvBHk9nEfhw52QITG4tHOysYNBmGoqVO5h0djyR7?=
 =?iso-8859-1?Q?PsikaFA85yF6eXMEkjnxszviGzpvxbFMXdJuKuKGoB9viHODapN8yQVlCU?=
 =?iso-8859-1?Q?DzGD4pvkmCWzdTVZYNGm26ceTy5PkRCUmi3ERc2ydBO0BArtvJScbKQQ?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14e6f3ae-f329-441a-09f0-08ddec75423c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 12:10:52.2499
 (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: SYJj1fSM3SjINg/EVhmm9YgKwGnGvq2jYSqtQKqcJYp8952+2LhAeHxFZynUkBaLhyaB8u6l1ommOHUKZdvfoZW79D6eRTI4Md/UM/IuWeI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7352


Hi Grygorii,

Grygorii Strashko  writes:

> On 27.08.25 03:22, Volodymyr Babchuk wrote:
>> Hi,
>> Grygorii Strashko  writes:
>>=20
>>> From: Grygorii Strashko 
>>>
>>> Split set_domain_type() between Arm64/Arm32 sub-arches as
>>> set_domain_type() implementation is going to be extended for Arm64.
>>>
>>> Signed-off-by: Grygorii Strashko 
>>> ---
>>> v2:
>>> - no changes, rebase
>>>
>>>   xen/arch/arm/arm32/Makefile       |  1 +
>>>   xen/arch/arm/arm32/domain-build.c | 22 ++++++++++++++++++++++
>>>   xen/arch/arm/arm64/Makefile       |  1 +
>>>   xen/arch/arm/arm64/domain-build.c | 24 ++++++++++++++++++++++++
>>>   xen/arch/arm/dom0less-build.c     | 14 --------------
>>>   xen/include/xen/dom0less-build.h  |  8 ++++++++
>>>   6 files changed, 56 insertions(+), 14 deletions(-)
>>>   create mode 100644 xen/arch/arm/arm32/domain-build.c
>>>   create mode 100644 xen/arch/arm/arm64/domain-build.c
>> Is it really worth to create two more source files just for one
>> function? Maybe it is better to use already existing
>> xen/arch/arm/arm*/domain.c ?
>
> It seems a common approach used for splitting ARM subarch code.
> code from arch/arm/A.c goes in
>  -> arch/arm/arm32/A.c
>  -> arch/arm/arm64/A.c
> (just "-" is used vs "_")

Yeah, my point was that both arch/arm/arm32/domain.c and
arch/arm/arm64/domain.c already exists, so you don't have to create a
new files. But this is up to you, actually. I'll be fine with either
approach, just wanted to mentioned that there is another way.

[...]

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:15:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:15:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111903.1460454 (Exim 4.92)
	(envelope-from )
	id 1uuVLP-0003vH-T9; Fri, 05 Sep 2025 12:15:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111903.1460454; Fri, 05 Sep 2025 12:15: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 1uuVLP-0003vA-QN; Fri, 05 Sep 2025 12:15:07 +0000
Received: by outflank-mailman (input) for mailman id 1111903;
 Fri, 05 Sep 2025 12:15: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 1uuVLO-0003v4-7P
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:15:06 +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 f4970159-8a51-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 14:15:05 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS2PR03MB9718.eurprd03.prod.outlook.com
 (2603:10a6:20b:60e::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Fri, 5 Sep
 2025 12:15:02 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.9094.018; Fri, 5 Sep 2025
 12:15: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: f4970159-8a51-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fylubzj9I4qaqfmcddEnreXVHB1EIi6Z1hRLI5YrQBgALImT4GQNjwkbRdCBr0ETFOmb+pxu8AzPCJJ+w4ehnaI/C3DD3Hyjti0Y14SoCyCzPVmmcUIF+BGY7xm5mnG6lGl9/+2NzWytbv4DjatuCEFhepOpq1g1pv0WW17hgVvt7sCwXhpw9jgVYSYEdKcgvC67p7jA/8ZwGeZW0PzeBpOerRngb0/iBm3hmX0Hhn72Ipp29RKA8XdhK4v5QlYvP8yXfHSeaUIcHh9dkhHRRpq4YtLo1hueHBAEPG5eNbchzwJCgogreLtjfprYWqkSVaNltcpXF488NpnMv3VQ6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZIuV1UJMoTUBWSq9aNFDeQqYn9FhdU2VmLoRfc3gCh4=;
 b=ZDxHDi+Fcm6R30ojjgXPzyAR6Awn55kJ7Y4EK0RKWilK4cdbErwHWm86sl+yP0bkbZrXNgleWkG5/Q0btEQKlQc13SsuPfgKF8QBPx9J9Wj1lNjg0IGE3RebekEffiUMbdX4+vgnoJm63EezuiiU1Nw54u7MkNXp10atXOgnzLpU9bYyTO9AY7oXleoUdOZ0hUeJfVgDMQsKVG7GkRoaN+vg+gP0MnRuCSpJvJ7zqUCSh3ycpVhXwapE0M0eSYglHnSGtjjAiNj6SEoVfly7R5rk5oCKg6U6kF1SyRFda1BqIWJ6f1arG15p4jfyUY5+X+gdJh+0MMPqOhjpJ1Ebjw==
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=ZIuV1UJMoTUBWSq9aNFDeQqYn9FhdU2VmLoRfc3gCh4=;
 b=Qhos2ALzxU2xP1kJpZ2FiLrTEkviT3ZLRsiOkDcZhShdYajNe5TNgSqwc+bu/yVpQxeLZNQGjKhO9X0/zpn+mJvqEkOod+Q0Xwrww1i47AyD5iBsOz+GHbUo4Ol/fcjKqu4VNaCI/4xoh+uR2L4h5lBrap4rkGR9FPxjAUgl7nyN1Ch53D4d4TtmJyJmSBa0KqlQEhxJaTl1906y2hew7cKhsZaB8nnioNda968DRBX9n1ENrOkUqQgjEFkFrA/IqMkS+ohuY4WSqRgCrBVZH4xtjGvCPA6U5I+lyv8Pfk0syTQNa7tLPoOz7jyeqMoKmpTk3pSYMqfcLXm3L1YCaQ==
From: Volodymyr Babchuk 
To: Grygorii Strashko 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel 
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
Thread-Topic: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
Thread-Index: AQHcBrdwMT62m9IEakijYkjoB+xNdw==
Date: Fri, 5 Sep 2025 12:15:02 +0000
Message-ID: <87o6rpqent.fsf@epam.com>
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
	<20250806094929.293658-4-grygorii_strashko@epam.com>
	<87ms7l39gl.fsf@epam.com>	<540abaa2-9946-40b8-bf49-b54e4f7a1393@epam.com>
In-Reply-To: <540abaa2-9946-40b8-bf49-b54e4f7a1393@epam.com> (Grygorii
	Strashko's message of "Thu, 4 Sep 2025 23:09:45 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS2PR03MB9718:EE_
x-ms-office365-filtering-correlation-id: 3767692f-1c30-4c0f-7603-08ddec75d791
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|42112799006|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Zd4NSFCJKrxFXFPrxoZgdwgXSkgAJApYRPMQFSuWYl50mnnNejzftqjGWq?=
 =?iso-8859-1?Q?xoRQ2iyrCl23Cy8ETYTrx+HEIJvlkHsXJfYxHe2DByIV9k+GAbXQKajdMs?=
 =?iso-8859-1?Q?BBd5uOtXcvfRkTpk45cojP+77WavcZBRNX7NQwG3o1WcT/0Sgp4IfMKYMK?=
 =?iso-8859-1?Q?SfM/t2eeoh9XpxLFPjGveHSw7lsd9QefM9JVq2G7FeekWVorD0VPg8VDCM?=
 =?iso-8859-1?Q?eE94Hmm5Yy19RBDoICes3nwujG8//f4p1ALFVD/bzGglPJs5V5c51duXcS?=
 =?iso-8859-1?Q?m6UUyxRwnkZVXPVTDZmnwljjWfVzBsQ/m9nvX4xAzi5J4kEaU/lZBxrjBM?=
 =?iso-8859-1?Q?YsKamIB5S5RNyPmWLYKLbDaE4z3FYGWJxupRN47MQmkqSNS8/AZUvp0mnK?=
 =?iso-8859-1?Q?614SeoStgqOp1mYOv5RTl9xShkgiH3lLSLtpU3vDHl+H+NbdX5usEeKuOA?=
 =?iso-8859-1?Q?ZS377ScpUzTw1rVr/4dnH8CQX1yulaiPNzNvUCf+1T8DbtMfmtzQnIEah6?=
 =?iso-8859-1?Q?HdAgfwrTpa/jCxxR7uXgj4jbOIgFBHnWnicw3q1q63em6d7QcbonjnIZJQ?=
 =?iso-8859-1?Q?HDndpao/9rJVrLgKXOWMNrzyCi3fRktw3ctOtgHIEmvRqgvuBhGgB1Tpin?=
 =?iso-8859-1?Q?zy3YEM+3sWK5jatq8kYgxbt0PL1mHSucPNBVWd3xfEHo5oTtjzn2/J0mJO?=
 =?iso-8859-1?Q?9TMdOVmz73g0W8Jp6hJq0CZtXpu6Za7qbhxeAYRW3N59JH47D7QKah0H+9?=
 =?iso-8859-1?Q?eao5/xA62RO8Advx9ZoWHlcJtrjnIILae30dhRfOVBestTZYuMd3sDul0M?=
 =?iso-8859-1?Q?66VdyMfG1glUAjjNfxml+r8iID9pFaOKjyIhCFT+bcFmA96FTdrAMrysd+?=
 =?iso-8859-1?Q?829pA8+WzqBJUMqa/FUgkw1IOM5S8DhK0bbc/uJuDGsLhBUIRNfNKGbhnX?=
 =?iso-8859-1?Q?gRdFpKh8Zs3z5sI9iLhV+1eB68i1znVLDvNi+jJDB6PEAWpVriWoHHo+y3?=
 =?iso-8859-1?Q?GejjKtqBsUDVlr7byy9xJ1Sq4p8sQuNcEvk11grUMfOAExntjmhsOMwt+s?=
 =?iso-8859-1?Q?NyAZaX+LugXuA46nifZ3WK5EEPgLi+hRTH0ZvzuWjnfDWaro9BOJEXwZtj?=
 =?iso-8859-1?Q?lU772dBcfDIGox4piEibWREQC90kBOlOCwINtFIQMh8Pbgc5VsNQI899+O?=
 =?iso-8859-1?Q?I00ThzhiiBAt413wISmG7L9dlOfxo3BV+gMm9G16AllwVwb+PYZPFRNvg/?=
 =?iso-8859-1?Q?9dGlG1igrn/sILk/bHDNXJCo6eMGQi1Q1EsYrrNQlMmJkGozLjsGhf+5lH?=
 =?iso-8859-1?Q?5cfAa5hdTfUbyp6vHsFzQ+68faf43yGheKYaY5wkt09JSEadtNmO6pZ89k?=
 =?iso-8859-1?Q?wiu0bKOXc79lYuwJbNre3i9WFo9Dx1ICIRpJLUe0vVfhrIyfNtl3WC7OKw?=
 =?iso-8859-1?Q?aYO6O+mD/HcrqOdDVuP5iQDUXyY6GL0emuuGiIy3bo/gj+0yDHcI4GIkBs?=
 =?iso-8859-1?Q?Ra/IPKgpP3+dX9mdcKIOViK7F3PKeERP5aiCIdaBsSjQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(42112799006)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?WSyYaVbIkg4yfFqP5Md0WXGcbX8gRU5gpDfAnVqUIQ6kmIH7bD1XotCKt4?=
 =?iso-8859-1?Q?aDnAYf0oPpboacE+x4bgIn9LtRoWBr7Ye7EgOaeP8N5LXJC73Yhh5q6zxo?=
 =?iso-8859-1?Q?IyfJrS4+wh2/mdYlvWnmXEGinUQeB6UshfNqOf73jCT2N2VWe02kEiMuwm?=
 =?iso-8859-1?Q?4QoyBU5LJu0J45Rmaiwv9L1IsNk9REWUjYJ7+NO5ZhY9riU4Irymq6SwJH?=
 =?iso-8859-1?Q?uj/cbEYChI8ZC3Dh79Y0IOUKzf+zumiA0k2uWqYKc+Fhc3E/hdzXA0QHtZ?=
 =?iso-8859-1?Q?WqJZ/+fcs1gkt5jpT6IlolLHFT6tE2iwzY42jPHNjeZ5qdRWVLvsXAbzeJ?=
 =?iso-8859-1?Q?yc5Cg42U6dZKTlCAg3NJ+1fo+NP27SfUQAag/hVvgmqkBo4DprV51hvBuY?=
 =?iso-8859-1?Q?wF/ymY8FLDeLq5eFfw4Cag5PICq6bNXBZaSdoFzKdYKScYaLaX+216jJkb?=
 =?iso-8859-1?Q?vxgzIxaaWxvITx8X6hq33N/fBeOpP7sXHZGMvTCRNFUBm0ibLHcSNKAzwk?=
 =?iso-8859-1?Q?xKHfPdUNLY09Zw8S4MaY8bCEKKteviYAv34Rxbt3NClUXXWEfl1jaoCux1?=
 =?iso-8859-1?Q?UPCBd9yTC65Hl3UxmLKXnQKxT9+/CnUxg+0nNchPVKzFXMda6OsVBCHNpJ?=
 =?iso-8859-1?Q?G3nXwpbOmcTUM7rwd4+mMUUH5rvxD0SP83LE3w1t0757gi+1puMzEz2EsC?=
 =?iso-8859-1?Q?WpaQy4eiKbHCtWeNurZ/SyEXMTto7qtGGvmuFJ+L37L20/byYRIzEIAE8u?=
 =?iso-8859-1?Q?jMIGmyyjs1rGt21qHGTbTd1bG9mV2vAy4vDTeSVMhzv22Nb3xoZ5WATHIX?=
 =?iso-8859-1?Q?OnywdGPmUlVL0vw3jaRf1RWjd+lwHd6m0PTQh+14iaxje/g3QfQ9dW2k6H?=
 =?iso-8859-1?Q?HkTqUmCUXylrGS0fPsFrt+2HIwL1yEz6KQarRewIBxDEqUu95BjZT9SEGh?=
 =?iso-8859-1?Q?r7LH63rt3Vx3XCkxMuHYku3lm69eFyZBXiN5jQNsr/69gDgeTw66X4frq3?=
 =?iso-8859-1?Q?415g82GSbLzCMgKnd/VycX1P/4mMXB7OEvyz+7P98Pkyy35ZyAFLJHUozy?=
 =?iso-8859-1?Q?1TrLohcSyxcfqQkvnJNGwq3XKFZ/PJo7AyQ4VB/vc9oUfu/NZv4TjQZ3uZ?=
 =?iso-8859-1?Q?l+hLN0mKol4j0RiGhERASSi3I/AfIGM8EGH8/66hQBWoZDwSQ1WtGEF54T?=
 =?iso-8859-1?Q?L/QsCMca2eDhb0FUgArBh/LmWiDl+xS31RiopvFjFxUchCzpKwydaWqB4j?=
 =?iso-8859-1?Q?Vgb3cdnYseb7XSQo20BY9cepncN2i/ZonAje8iehpAetVmKLPQ6u7kDhy2?=
 =?iso-8859-1?Q?eQpywjS/UvBq+VGbwWSlSx/WFUF4Lk5JZanvDFg2znKUMUOQJar9FHI8WL?=
 =?iso-8859-1?Q?4cK3WpK6JC+nlQNbWV6kQmC7fIRWWa8FL/Tt48Pm2IHBQfcOi1eU3dA7uH?=
 =?iso-8859-1?Q?Q1mCvwRhjUc6eQXxCj382FLPFDKd+14YxjI4UZiqu4LOAFqtlRYXW229Q4?=
 =?iso-8859-1?Q?nyllGPbmbMOI0JRoV4i8wSrUjZKRCOdWdxXl/0cXljFCZ1BqZZQAbqN1ud?=
 =?iso-8859-1?Q?fJJdNRBYPHHmmLlcDxebmPAL+cSXpo1qCYyp9VceMAEXk5g6EoTUi7njuA?=
 =?iso-8859-1?Q?15WYBiPgEr7JoVp2taDriA9CoOnDCMpiENL0XgtC+E62BT95T2sGzHeg?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3767692f-1c30-4c0f-7603-08ddec75d791
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 12:15:02.8313
 (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: d6gWgOQUn2s37FbrusUIQVlt+lqx9enrDSorawxSNf5SVOmd+RLYDJW6/v2iOfTte4/Yj/yjZeuvM8Yso1Qwy/QeM/wct5SuujMG5MHnRX4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9718

Hi,

Grygorii Strashko  writes:

> On 27.08.25 03:16, Volodymyr Babchuk wrote:
>> Hi Grygorii,
>> Grygorii Strashko  writes:
>>=20
>>> From: Grygorii Strashko 
>>>
>>> Now Arm64 AArch32 guest support is always enabled and built-in while no=
t
>>> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
>>> support might not be needed (Arm64 AArch32 is used quite rarely in embe=
dded
>>> systems). More over, when focusing on safety certification, AArch32 rel=
ated
>>> code in Xen leaves a gap in terms of coverage that cannot really be
>>> justified in words. This leaves two options: either support it (lots of
>>> additional testing, requirements and documents would be needed) or comp=
ile
>>> it out.
>>>
>>> Hence, this patch introduces basic support to allow make Arm64
>>> AArch32 guest support optional. The following changes are introduced:
>>>
>>> - Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
>>>    Arm64 AArch32 guest support (default y)
>>>
>>> - Introduce is_aarch32_enabled() helper which accounts Arm64 HW capabil=
ity
>>>    and CONFIG_ARM64_AARCH32 setting
>>>
>>> - Introduce arm64_set_domain_type() to configure Arm64 domain type in
>>>    unified way instead of open coding (d)->arch.type, and account
>>>    CONFIG_ARM64_AARCH32 configuration.
>>>
>>> - toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 i=
s
>>>    disabled.
>>>
>>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>>    AArch32 is disabled.
>>>
>>> - Set Arm64 domain type to DOMAIN_64BIT by default.
>>>    - the Arm Xen boot code is handling this case properly already;
>>>    - for toolstack case the XEN_DOMCTL_set_address_size hypercall handl=
ing
>>>      updated to forcibly configure domain type regardless of current do=
main
>>>      type configuration, so toolstack behavior is unchanged.
>>>
>>> With CONFIG_ARM64_AARCH32=3Dn the Xen will reject AArch32 guests (kerne=
ls) if
>>> configured by user in the following way:
>>> - Xen boot will fail with panic during dom0 or dom0less domains creatio=
n
>>> - toolstack domain creation will be rejected due to xc_dom_compat_check=
()
>>>    failure.
>>>
>>> Making Arm64 AArch32 guest support open further possibilities for build
>>> optimizations of Arm64 AArch32 guest support code.
>>>
>>> Signed-off-by: Grygorii Strashko 
>>> ---
>>> changes in v2:
>>> - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 s=
upport
>>> - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work w=
ith any
>>>    initial domain type set (32bit or 64 bit)
>>> - fix comments related to macro parameters evaluation issues
>>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>>    AArch32 is disabled
>>>
>>>   xen/arch/arm/Kconfig                    |  7 ++++
>>>   xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++-=
-
>>>   xen/arch/arm/arm64/domctl.c             | 16 +++++----
>>>   xen/arch/arm/arm64/vsysreg.c            |  9 +++++
>>>   xen/arch/arm/domain.c                   |  9 +++++
>>>   xen/arch/arm/domain_build.c             | 21 +++--------
>>>   xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
>>>   xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
>>>   xen/arch/arm/setup.c                    |  2 +-
>>>   9 files changed, 119 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index a0c816047427..bf6dd73caf73 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
>>>   	help
>>>   	  This option enables PCI device passthrough
>>>   +config ARM64_AARCH32
>>> +	bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTE=
D
>> But aarch32 guests are supported... I understand that you wanted to
>> say
>> "Disabling aarch32 support is unsupported". But currently this entry
>> reads backwards. I think it should be reworded better. But I have no
>> idea - how to do this.
>
> I think "(UNSUPPORTED)" can be just dropped. Is it ok?

As I understand, If you want this feature to be eventually certified, it
should not be UNSUPPORTED nor EXPERIMENTAL.


[...]

>>> @@ -21,14 +26,14 @@ static long switch_mode(struct domain *d, enum doma=
in_type type)
>>>           return -EINVAL;
>>>       if ( domain_tot_pages(d) !=3D 0 )
>>>           return -EBUSY;
>>> -    if ( d->arch.type =3D=3D type )
>>> -        return 0;
>>>         d->arch.type =3D type;
>>>   -    if ( is_64bit_domain(d) )
>>> -        for_each_vcpu(d, v)
>>> +    for_each_vcpu(d, v)
>>> +        if ( is_64bit_domain(d) )
>> Do you really need to check domain type for every vCPU? I think that
>> original variant was better.
>>=20
>>>               vcpu_switch_to_aarch64_mode(v);
>>> +        else
>>> +            vcpu_switch_to_aarch32_mode(v);
>
> Do you mean like below?
>
>     if ( is_64bit_domain(d) )
>         for_each_vcpu(d, v)
>             vcpu_switch_to_aarch64_mode(v);
>     else
>         for_each_vcpu(d, v)
>             vcpu_switch_to_aarch32_mode(v);
>
>

Yep, something like that.

[...]


--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:21:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:21:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111929.1460465 (Exim 4.92)
	(envelope-from )
	id 1uuVRR-0005f0-Kf; Fri, 05 Sep 2025 12:21:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111929.1460465; Fri, 05 Sep 2025 12:21: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 1uuVRR-0005et-H4; Fri, 05 Sep 2025 12:21:21 +0000
Received: by outflank-mailman (input) for mailman id 1111929;
 Fri, 05 Sep 2025 12:21: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 1uuVIL-0001iM-Da
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:11:57 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 81825d51-8a51-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 14:11:52 +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 F0A1B153B;
 Fri,  5 Sep 2025 05:11:42 -0700 (PDT)
Received: from [10.57.60.42] (unknown [10.57.60.42])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 65F093F63F;
 Fri,  5 Sep 2025 05: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: 81825d51-8a51-11f0-9809-7dc792cee155
Message-ID: <66335cf3-d49d-4b27-a37b-0a8a5e2c5d78@arm.com>
Date: Fri, 5 Sep 2025 14:11:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] Nesting support for lazy MMU mode
To: Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , linux-arm-kernel@lists.infradead.org,
 linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <9fd076c7-f163-4b92-8201-d8a259a338c1-agordeev@linux.ibm.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <9fd076c7-f163-4b92-8201-d8a259a338c1-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05/09/2025 11:46, Alexander Gordeev wrote:
> On Thu, Sep 04, 2025 at 01:57:29PM +0100, Kevin Brodsky wrote:
>
> Hi Kevin,
>
>> When the lazy MMU mode was introduced eons ago, it wasn't made clear
>> whether such a sequence was legal:
>>
>> 	arch_enter_lazy_mmu_mode()
>> 	...
>> 		arch_enter_lazy_mmu_mode()
>> 		...
>> 		arch_leave_lazy_mmu_mode()
>> 	...
>> 	arch_leave_lazy_mmu_mode()
> I did not take too deep - sorry if you already answered this.
> Quick question - whether a concern Ryan expressed is addressed
> in general case?

The short answer is yes - it's good that you're asking because I failed
to clarify this in the cover letter!

> https://lore.kernel.org/all/3cad01ea-b704-4156-807e-7a83643917a8@arm.com/
>
> 	enter_lazy_mmu
> 		for_each_pte {
> 			read/modify-write pte
>
> 			alloc_page
> 				enter_lazy_mmu
> 					make page valid
> 				exit_lazy_mmu
>
> 			write_to_page
> 		}
> 	exit_lazy_mmu
>
> 
> This example only works because lazy_mmu doesn't support nesting. The "make page
> valid" operation is completed by the time of the inner exit_lazy_mmu so that the
> page can be accessed in write_to_page. If nesting was supported, the inner
> exit_lazy_mmu would become a nop and write_to_page would explode.
> 

Further down in the cover letter I refer to the approach Catalin
suggested [4]. This was in fact in response to this concern from Ryan.
The key point is: leave() keeps the lazy MMU mode enabled if it is
nested, but it flushes any batched state *unconditionally*, regardless
of nesting level. See patch 3-6 on the practical implementation of this;
patch 7 also spells it out in the documentation.

Hope that clarifies the situation!

- Kevin

[4] https://lore.kernel.org/all/aEhKSq0zVaUJkomX@arm.com/


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:23:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:23:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111940.1460474 (Exim 4.92)
	(envelope-from )
	id 1uuVT0-0006Cd-UT; Fri, 05 Sep 2025 12:22:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111940.1460474; Fri, 05 Sep 2025 12:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuVT0-0006CW-RM; Fri, 05 Sep 2025 12:22:58 +0000
Received: by outflank-mailman (input) for mailman id 1111940;
 Fri, 05 Sep 2025 12:22:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuVSz-0006CM-9v
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:22:57 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 0cc6460b-8a53-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 14:22:55 +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 2012D153B;
 Fri,  5 Sep 2025 05:22:46 -0700 (PDT)
Received: from [10.57.60.42] (unknown [10.57.60.42])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D7BF93F63F;
 Fri,  5 Sep 2025 05:22: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: 0cc6460b-8a53-11f0-9809-7dc792cee155
Message-ID: 
Date: Fri, 5 Sep 2025 14:22:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
To: Lorenzo Stoakes 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , linux-arm-kernel@lists.infradead.org,
 linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
 <22131943-3f92-4f5a-be28-7b668c07a25c@lucifer.local>
 <75db1f58-98b3-463c-af4f-2ce9878cba9f@arm.com>
 <2aed0b3b-1a70-4c89-9177-8de4fabb2237@lucifer.local>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05/09/2025 13:37, Lorenzo Stoakes wrote:
> On Fri, Sep 05, 2025 at 12:21:40PM +0100, Lorenzo Stoakes wrote:
>> You should really base on mm-new.
>>
>> You need to account for everything that is potentially going to go
>> upstream. mm-stable is generally not actually populated all too well until
>> shortly before merge window anyway.
> Just to note that mm-unstable is also fine. Despite its name, it's substantially
> more stable than mm-new, which can even break the build and appears to have no
> checks performed on it at all.

Thanks for the overview - I had a general idea about those branches but
I wasn't sure what the standard practice was. I'll rebase on mm-unstable
to start with.

- Kevin


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 12:53:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 12:53:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1111981.1460484 (Exim 4.92)
	(envelope-from )
	id 1uuVwq-0001tX-7R; Fri, 05 Sep 2025 12:53:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1111981.1460484; Fri, 05 Sep 2025 12:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuVwq-0001tQ-4P; Fri, 05 Sep 2025 12:53:48 +0000
Received: by outflank-mailman (input) for mailman id 1111981;
 Fri, 05 Sep 2025 12:53: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 1uuVwp-0001tK-5U
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 12:53:47 +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 5b8ac6d6-8a57-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 14:53:45 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-45dda7d87faso4073625e9.2
 for ; Fri, 05 Sep 2025 05:53:45 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3cf3458a67fsm4334066f8f.62.2025.09.05.05.53.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 05:53: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: 5b8ac6d6-8a57-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757076825; x=1757681625; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=si9qQCwIJBugiLUvuKF99IHWOHJ6ZkxN6J1JHrdifGs=;
        b=jr5hw1qbw/xHtaTU/PTaKTq/QeaLu3/EbQNjIk5pZacU53mKGvYvLBjQLs/KVjmZoE
         Mgmu+x5mGL8aqGRitujFCWvCFjq/1hK8XHDK7Yyo+iL8ODQnu8itfBD8/vA/QvysVN14
         pGoIaggjmK82lc/Vdg8QvrJdoQD7Ggdw0YSZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757076825; x=1757681625;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=si9qQCwIJBugiLUvuKF99IHWOHJ6ZkxN6J1JHrdifGs=;
        b=tHvRuacOfPzn3oq+2gdniend/GmmQaOzND4x/sK/fno8ynFHJBvaP0TI7+/0Escanb
         X8RRy/USXU0r10QSn9oJrXznYyeEZm9E+9hCxiHfooeFl+PVg/5vtz50ZkJUSxoP5d2y
         QACiDe5o+enqKdRhodSvQ5jVosR3FR0ScGSqlyss0Od/V6LHZXjm2sfk7fW8u02mfvR0
         ge8fmE8fb2OatFbElCFnz/fuVvi4mL04Xr+myEIUOHSZUfHQWB7uNqS+Wklz9BPD/BC4
         LTEwy2wgCRpquhkWeIe4bvLWWjwEZu+nx2l9Lzn24Qo4Z6vK5088uSvLvceoFyytJaC5
         csXw==
X-Forwarded-Encrypted: i=1; AJvYcCX3UfsaYtbLl5oFPGCh06aO3NXUBKDp3sWTXMc9tnnGJZ9sadYv6YL34H/nSzjV24/qFsWqLZF4B9g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxsjfCRKlCqEMH8BvDkDne+f2jMtRfudS9dA0jF1h6Xzizx9YRC
	1De+J94X/Usec83fp4yq/ZewMcMn4H0Ite0ZVSC/VS7XLpZFK89h4/aLMS3FfS1ShoQ=
X-Gm-Gg: ASbGncv+n+vio6FpwHkNvI6mV4aOhRxGQi65clmtXtXWuIums6kDeRxgx11rox5hFK7
	u9etqGqBsjQwuYEUVmJ70SXYnB0Mc+7rqCS+Z9scIH62NJdlFZZdi2UAgp26Rz/j2YF0xp3i2lb
	/TBfX0MC0z7G/UH/xP6QQ3M9AuoH7QtEkB0w5RKM7DcD3x0lR2IX2auCxkTAKzB/CTEfV1q2quj
	dvTYx64NAsqwwLMg6/PhAJbvRnp/XpTf40Zyb3qsXKYVurJVVw64p7s9MeZEwMFzgJXFJKX4CHm
	uStRViO/uPeZvVl+JZZ0SwZt6lbdXEeH8SH411KYEE5OVRdxnaRF6BTchiVqEpSjIpg6fc39s5/
	CaVpiqpPdKxhSyn6YF3aqlwVN1wqRoSoTp8nRuY9B9E5vhXb3eYbmxlpJJZStDpS38vsbWumQyB
	dwn6U=
X-Google-Smtp-Source: AGHT+IEsPmjs/ej6BkUItdPmxuuWxTLBEkcqaSxZgGTtFQEaKELIeZFklcT4NvDNqYp9w5rZLOsf6g==
X-Received: by 2002:a05:600c:1c0e:b0:459:e466:1bec with SMTP id 5b1f17b1804b1-45cb5871c12mr68592605e9.2.1757076824576;
        Fri, 05 Sep 2025 05:53:44 -0700 (PDT)
Message-ID: 
Date: Fri, 5 Sep 2025 13:53:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
To: Gerald Elder-Vass ,
 Xen-devel 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Jan Beulich , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@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: <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05/09/2025 1:10 pm, Gerald Elder-Vass wrote:
> From: Ross Lagerwall 
>
> Also cache it to avoid needing to repeatedly ask the firmware.
>
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Gerald Elder-Vass 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 13:07:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 13:07:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112001.1460495 (Exim 4.92)
	(envelope-from )
	id 1uuWAE-0003cy-Ch; Fri, 05 Sep 2025 13:07:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112001.1460495; Fri, 05 Sep 2025 13:07: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 1uuWAE-0003cr-9R; Fri, 05 Sep 2025 13:07:38 +0000
Received: by outflank-mailman (input) for mailman id 1112001;
 Fri, 05 Sep 2025 13:07:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuWAC-0003cl-Ud
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 13:07:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuWAC-007x8c-1L;
 Fri, 05 Sep 2025 13:07:36 +0000
Received: from [2a02:8012:3a1:0:9f:253:13d3:5d9d]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuWAC-00H1sz-1J;
 Fri, 05 Sep 2025 13:07: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=bhWQ5boihjzjB/CqJBYJUAjfcczXgA/RlON/+Ky0ejM=; b=OymO6Qh3wRlulaERdnGxFit25n
	nKC7yA96lgAuw0XEfSYQVOK0AxfOUV3S2ET9RL+3inSe4qwR8MwP/dVZtImaNbk945IWhB5PKWNMk
	ulo6erlXoE7kI5gLfXSgPpfzTSPQ4HCRLKuKmEY0BjNbdpP63LtHJnFbJ3l/ffuTh23I=;
Message-ID: <1b27dc46-4d5c-4c6d-8976-0f9b98d11d6b@xen.org>
Date: Fri, 5 Sep 2025 14:07:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
Content-Language: en-GB
To: Volodymyr Babchuk ,
 Grygorii Strashko 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
 <87ms7l39gl.fsf@epam.com> <540abaa2-9946-40b8-bf49-b54e4f7a1393@epam.com>
 <87o6rpqent.fsf@epam.com>
From: Julien Grall 
In-Reply-To: <87o6rpqent.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 05/09/2025 13:15, Volodymyr Babchuk wrote:
> Hi,
> 
> Grygorii Strashko  writes:
> 
>> On 27.08.25 03:16, Volodymyr Babchuk wrote:
>>> Hi Grygorii,
>>> Grygorii Strashko  writes:
>>>
>>>> From: Grygorii Strashko 
>>>>
>>>> Now Arm64 AArch32 guest support is always enabled and built-in while not
>>>> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
>>>> support might not be needed (Arm64 AArch32 is used quite rarely in embedded
>>>> systems). More over, when focusing on safety certification, AArch32 related
>>>> code in Xen leaves a gap in terms of coverage that cannot really be
>>>> justified in words. This leaves two options: either support it (lots of
>>>> additional testing, requirements and documents would be needed) or compile
>>>> it out.
>>>>
>>>> Hence, this patch introduces basic support to allow make Arm64
>>>> AArch32 guest support optional. The following changes are introduced:
>>>>
>>>> - Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
>>>>     Arm64 AArch32 guest support (default y)
>>>>
>>>> - Introduce is_aarch32_enabled() helper which accounts Arm64 HW capability
>>>>     and CONFIG_ARM64_AARCH32 setting
>>>>
>>>> - Introduce arm64_set_domain_type() to configure Arm64 domain type in
>>>>     unified way instead of open coding (d)->arch.type, and account
>>>>     CONFIG_ARM64_AARCH32 configuration.
>>>>
>>>> - toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 is
>>>>     disabled.
>>>>
>>>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>>>     AArch32 is disabled.
>>>>
>>>> - Set Arm64 domain type to DOMAIN_64BIT by default.
>>>>     - the Arm Xen boot code is handling this case properly already;
>>>>     - for toolstack case the XEN_DOMCTL_set_address_size hypercall handling
>>>>       updated to forcibly configure domain type regardless of current domain
>>>>       type configuration, so toolstack behavior is unchanged.
>>>>
>>>> With CONFIG_ARM64_AARCH32=n the Xen will reject AArch32 guests (kernels) if
>>>> configured by user in the following way:
>>>> - Xen boot will fail with panic during dom0 or dom0less domains creation
>>>> - toolstack domain creation will be rejected due to xc_dom_compat_check()
>>>>     failure.
>>>>
>>>> Making Arm64 AArch32 guest support open further possibilities for build
>>>> optimizations of Arm64 AArch32 guest support code.
>>>>
>>>> Signed-off-by: Grygorii Strashko 
>>>> ---
>>>> changes in v2:
>>>> - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 support
>>>> - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with any
>>>>     initial domain type set (32bit or 64 bit)
>>>> - fix comments related to macro parameters evaluation issues
>>>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>>>     AArch32 is disabled
>>>>
>>>>    xen/arch/arm/Kconfig                    |  7 ++++
>>>>    xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++--
>>>>    xen/arch/arm/arm64/domctl.c             | 16 +++++----
>>>>    xen/arch/arm/arm64/vsysreg.c            |  9 +++++
>>>>    xen/arch/arm/domain.c                   |  9 +++++
>>>>    xen/arch/arm/domain_build.c             | 21 +++--------
>>>>    xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
>>>>    xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
>>>>    xen/arch/arm/setup.c                    |  2 +-
>>>>    9 files changed, 119 insertions(+), 26 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>> index a0c816047427..bf6dd73caf73 100644
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
>>>>    	help
>>>>    	  This option enables PCI device passthrough
>>>>    +config ARM64_AARCH32
>>>> +	bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTED
>>> But aarch32 guests are supported... I understand that you wanted to
>>> say
>>> "Disabling aarch32 support is unsupported". But currently this entry
>>> reads backwards. I think it should be reworded better. But I have no
>>> idea - how to do this.
>>
>> I think "(UNSUPPORTED)" can be just dropped. Is it ok?
> 
> As I understand, If you want this feature to be eventually certified, it
> should not be UNSUPPORTED nor EXPERIMENTAL.

The certification is somewhat irrelevant to the decision of the state of 
the feature. Instead, the decision should be based on the criteria based 
in SUPPORT.MD (see "Status"). If it is experimental/unsupported, then 
what's missing to make it supported?

In addition to that, there is the "EXPERT" mode. This was introduced 
mainly to allow the user to tailor the Kconfig but also limit to what we 
security support. This is to reduce the amount of workload on the 
security team when it comes to decide on whether we need to issue an XSA 
(the more possibility, the more difficult it becomes).

There has been discussion on providing a small set of config (one could 
be for certification purpose) that would be security supported. But I 
don't think we come to a conclusion yet.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 14:23:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 14:23:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112038.1460504 (Exim 4.92)
	(envelope-from )
	id 1uuXLc-0004VO-HE; Fri, 05 Sep 2025 14:23:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112038.1460504; Fri, 05 Sep 2025 14:23: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 1uuXLc-0004VH-Ed; Fri, 05 Sep 2025 14:23:28 +0000
Received: by outflank-mailman (input) for mailman id 1112038;
 Fri, 05 Sep 2025 14:23: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 1uuXLb-0004V6-83
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 14:23:27 +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 e18fb50a-8a63-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 16:23:24 +0200 (CEST)
Received: from BY5PR04CA0024.namprd04.prod.outlook.com (2603:10b6:a03:1d0::34)
 by BL1PR12MB5756.namprd12.prod.outlook.com (2603:10b6:208:393::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 5 Sep
 2025 14:23:17 +0000
Received: from CO1PEPF000075ED.namprd03.prod.outlook.com
 (2603:10b6:a03:1d0:cafe::cd) by BY5PR04CA0024.outlook.office365.com
 (2603:10b6:a03:1d0::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.18 via Frontend Transport; Fri,
 5 Sep 2025 14:23:16 +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.9094.14 via Frontend Transport; Fri, 5 Sep 2025 14:23:16 +0000
Received: from satlexmb07.amd.com (10.181.42.216) 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, 5 Sep
 2025 09:23:16 -0500
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Fri, 5 Sep
 2025 07:23:13 -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: e18fb50a-8a63-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hclL765Ah+0nwN5jTe5vSFVeNcLQbEE7xAftUwlvsu9QfBTnad6zIkthz2V3n+j++9wgFkBibvcBu2Pg2s4lnwK8LBotO8j2+JH2VFK3LWd3JI9oZXtQrnGksxLDAQV5FDhI48Twahq18juTJz4GdfyCcPBAT5hK/w/47yc1uW+hbwTHdmZDolI7RfQLsvPQHHT3VMjFZr7ZzvBkVM+0USsY2zAhUHaD23q6Ziq6frm5PQXGeAV9rEnY50zTPUjJxWOIAN3EGGShBxGndodMBiIF8qtl6YcxGm7p3D1vA4N309RVuPXiaN9xsXmZ1CZ/2hIwyfRpxc3EfbC70B6c+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=vBMpyFtOkrIZHsOBkab5BX5XX/KDsJxINZyIGOe9kc8=;
 b=JeIntKn1U47FS8eDW8XdxoRODbml8oOEIu2ROG3S8zffnkthy3Bnh6HVQ45vkV9suUKakmT9YZSriiE3UC/YiZOYJNKb+XdASaBV9OgfyAe/XoZ820+jXTMWI9A+c9wKdSFp3TmM5SsLd8F+QTCG/aUwQMjpkjSBxhT94QA0we/2nY5nSpSagm7Esah/zSXE/6H+fK81AZVNp8ub0II4CKz5fl/EU6whFD8K357YnoabWKajVopvU2h3Yb3964XQAVa2TFmfXyCWnNTEDU3zUk2zmfnzu2r6wWFj49/FHSGMbY85W8H4sT/eoUwCeBq+SDUC9I3W5fdLAMDx8c/Akg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vBMpyFtOkrIZHsOBkab5BX5XX/KDsJxINZyIGOe9kc8=;
 b=Mt/Nz1PZoBaD/rDIwSj+JX0z6MPT/n2LqGphLcCplDfv9JXoR76YJuU1qlG72u7fE7PXHg0k9AFwIUEn26v/3eW6TCgfZwN9tynSM3KNPgVjpYa6rSMre0Mdkype2xZVHd6NJFGc96HkOzpuzIFoP8f+Ek0S6Y70or8ivKu4IV0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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, 5 Sep 2025 16:23:12 +0200
Message-ID: 
CC: , ,
	, , ,
	, , ,
	=?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=
	, Simon Gaiser
	, Xen-devel
	
Subject: Re: [PATCH v17 0/4] xen/domain: domain ID allocation
From: Alejandro Vallejo 
To: Demi Marie Obenour , ,
	
X-Mailer: aerc 0.20.1
References: <20250829232132.3460081-1-dmukhin@ford.com>
 <4bfee720-f117-4ac5-8cf8-8d9e718f6694@gmail.com>
In-Reply-To: <4bfee720-f117-4ac5-8cf8-8d9e718f6694@gmail.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000075ED:EE_|BL1PR12MB5756:EE_
X-MS-Office365-Filtering-Correlation-Id: 14cd9070-c99c-4f7f-1e1a-08ddec87c187
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|7416014|376014|82310400026|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?a1N3dGFkcVFpWTkrNDNnc09RQ2tvSjRMaTVxbFZra0diRWMyNmJLMkVPeVhD?=
 =?utf-8?B?U2ZmRStuVmIxNmdWQUpyZW9lNS9sMWFkU1lQYUcrNi9CZld0eWtqeXF5eGQr?=
 =?utf-8?B?ZlgrUFcxV2hpVTFYMG9XMkVVYmFpM2hxTWZ5OWdtS08yN1lwZ2hWZWEwck1J?=
 =?utf-8?B?KythOWF4eVJnUkxvdkFsM1JCT3cxaXhJV0dmOXF4Qk1jOHloU3BRVmVlOXMv?=
 =?utf-8?B?TERYSUtvVEdqcU9aRkhkZWxreEN5RzBpUVNSckp3SGdubS9NRDgzZFRPalV4?=
 =?utf-8?B?UlFnVFplcjJDR2s2QXRERXhucW5oWnU5NGRidWgvTVEya3U4cHFiRGZvdExl?=
 =?utf-8?B?VWdUSjVZZE04QWhEZmtESG9peW9rUStQSFFSdmZRdjFEbEpmalltNWcyT1p5?=
 =?utf-8?B?NGJYcXgrczEyR0Q0MmhZdHhvR3RTaXFKS2NzMDcvNnBBeGRVVllzRnJvNDU4?=
 =?utf-8?B?UnpiamMzWC9VUGlPWG54ZkVPZXc3dHQvN2swOHhXUXlZTmFMbFVtb3Y5N1RK?=
 =?utf-8?B?RWQ5K083a2x4NG1LWjNydnpkeTFwTXVHT0NteFpGSGU0UEdWQUwwQXVjSVNy?=
 =?utf-8?B?VnlyTjgyaEpOS0lDak4zSTNBR0I3UlluSDdrTTBvcThLbkpETEJTL0VLbzMw?=
 =?utf-8?B?Qy92aGc0UC9GdFQ5aHJIMEM3RlY4RDIwY2tKVGZML1BCbmg0QjJxRndlS2h4?=
 =?utf-8?B?K0FORlc4aGZWSk40T1Z5VVZ2RExUdzFmcjlpVm9iaUJxYlRvYXNpbUlNR0Jh?=
 =?utf-8?B?MUhQUndPTnRHVDhsQk41TXArNHp5b3REaWV4WGFoa2xqODg2Um5raTErRzJk?=
 =?utf-8?B?VG9uWk11RVJ0S24weXJLUTI4QVBvWDF1dkMzYmtzeXVEUkhqRCtSanRMa084?=
 =?utf-8?B?aUpGam9PSmpEWVp1MkpNc1NZRDN3alBrbDE3dGQycm1KMnEyWFE3RGp2M2FM?=
 =?utf-8?B?djdVeUMrdCtGSlRJb25IVVZmVHE5YlcraER2Z0piQjkvclhOM2haVWY1c3ZJ?=
 =?utf-8?B?Qyt5RHFGYi90dlF2SjQ0bWdxZm5GaHpLakNlNmI4RUJlVTZDeW9ITjJCZHNH?=
 =?utf-8?B?QkZlMjdNaWg1cjNvN3FHbmtnMkFqYzdwdml6aUJsaWR6K3MzREVMQWlNTllW?=
 =?utf-8?B?aG43ZXJMNzRPTUd1LzcxQS9BOUZnMUNJU1ZRN3FlYUxXcTk2cTFZZHczdURO?=
 =?utf-8?B?ZTdhTmdkcExLY2I2RUNZWloyMlJEcy8yK1JZZ3BuYlpDRGlRMDQvMFRKaWxK?=
 =?utf-8?B?SlE0UzhKVDZydW5kcXUySURmblZvbm5xekpiTkJtWHU1eTJwelR0dElFUmw5?=
 =?utf-8?B?ZFQ4UVJFckVSQjF3OWtleFpNb29OWHFSTE1kcllwbTYrZXpnQWRGYkVjUGVF?=
 =?utf-8?B?ekJTL3lWMGlkdHBQaHJrQ2RwZkluaGJka3FCYVFlaHNsclMrZjNBOE5oc1Ri?=
 =?utf-8?B?K01UNlhTeitHNUFNN3dXWFlFakpjdGZYT2NpVXV2em43UU9qR0I5T2NNVHBN?=
 =?utf-8?B?V0J5NVgxaU4yMUxmaWJ6TU5pWEJ4SlJUY1BzKzB3ZTZJRnhIblZLd1Q4VFhO?=
 =?utf-8?B?K0ZUV2FlVUVhc1VMNlJSbFRPQ202VUwyQnJxb2pZbk9LQzIxMkpvcDR0a1Jn?=
 =?utf-8?B?TllzOGxFTkYyQlpmWGxBSThJWmpRelZPdEs1YitsZVVPWW9MZ21kVi9Yb3pH?=
 =?utf-8?B?YmE5Z29Ca05IOHVOYlp3UlJyYkh0cXRkcnVtZ21SMXBuZE1vMmM1NXRnVUlz?=
 =?utf-8?B?blhPVWpsVUJxdlE2TFRaMG1lVDJ4cExBdEJ6c2grZ0VjU2tiaHlabHU5Q1pY?=
 =?utf-8?B?azNkUnF5ZldiU2RxWmUrMHJpMUNKd3lLWVV2MEtwWFpGbSs2Ykt4bllDTm9Y?=
 =?utf-8?B?RWxJdVk3bkxZMUI4blFlaFcyY1NXMEFKcHhyTFhOVmpOalJjU1JLdXhacTVH?=
 =?utf-8?B?WXk1Rzdodm5DeTViRmpCYWlPVVcvdWxXQTFUR2M2VUlNWmRacEJQNnhHdzFQ?=
 =?utf-8?Q?tpV8xog6KJD5KxkmRNmiOVXFa+RAnw=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(7416014)(376014)(82310400026)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 14:23:16.6736
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 14cd9070-c99c-4f7f-1e1a-08ddec87c187
X-MS-Exchange-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: BL1PR12MB5756

On Thu Sep 4, 2025 at 10:15 PM CEST, Demi Marie Obenour wrote:
> On 8/29/25 19:21, dmukhin@xen.org wrote:
>> Patch 1 introduces new domid_{alloc,free} calls.
>> Patch 2 is a prep change for domain ID allocator test.
>> Patch 3 introduces some basic testing for domain ID allocator.
>> Patch 4 adjusts create_dom0() messages (use %pd).
>>=20
>> Link to v16: https://lore.kernel.org/xen-devel/20250812223024.2364749-1-=
dmukhin@ford.com/
>> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipeline=
s/2012378054
>>=20
>> Denis Mukhin (4):
>>   xen/domain: unify domain ID allocation
>>   tools/include: move xc_bitops.h to xen-tools/bitops.h
>>   tools/tests: introduce unit tests for domain ID allocator
>>   xen/domain: update create_dom0() messages
>>=20
>>  .../xen-tools/bitops.h}                       | 16 +++-
>>  tools/libs/ctrl/xc_misc.c                     | 13 +--
>>  tools/libs/guest/xg_dom_elfloader.c           |  1 -
>>  tools/libs/guest/xg_dom_hvmloader.c           |  1 -
>>  tools/libs/guest/xg_private.h                 |  2 +-
>>  tools/libs/guest/xg_sr_common.h               |  2 -
>>  tools/tests/Makefile                          |  1 +
>>  tools/tests/domid/.gitignore                  |  2 +
>>  tools/tests/domid/Makefile                    | 88 +++++++++++++++++
>>  tools/tests/domid/harness.h                   | 54 +++++++++++
>>  tools/tests/domid/test-domid.c                | 95 +++++++++++++++++++
>>  xen/arch/arm/domain_build.c                   | 13 ++-
>>  xen/arch/x86/setup.c                          | 11 ++-
>>  xen/common/Makefile                           |  1 +
>>  xen/common/device-tree/dom0less-build.c       | 15 +--
>>  xen/common/domain.c                           |  2 +
>>  xen/common/domctl.c                           | 43 ++-------
>>  xen/common/domid.c                            | 95 +++++++++++++++++++
>>  xen/include/xen/domain.h                      |  3 +
>>  xen/lib/find-next-bit.c                       |  5 +
>>  20 files changed, 397 insertions(+), 66 deletions(-)
>>  rename tools/{libs/ctrl/xc_bitops.h =3D> include/xen-tools/bitops.h} (8=
4%)
>>  create mode 100644 tools/tests/domid/.gitignore
>>  create mode 100644 tools/tests/domid/Makefile
>>  create mode 100644 tools/tests/domid/harness.h
>>  create mode 100644 tools/tests/domid/test-domid.c
>>  create mode 100644 xen/common/domid.c
>
> Would it make sense to support virtualizing the domain ID space?
> That would allow the toolstack to only allow a domain to communicate
> with other domains of its choosing, rather than with any domain XSM
> permits.  This would also allow avoiding domain ID reuse problems,
> because a virtual domain ID would stay valid even after the domain
> it refers to no longer exists.  It would need to be explicitly released
> by the guest kernel before it could refer to a different domain.

I'd be all-in for something like that. For context, this is something we
briefly touched on over lunch on the last Xen Summit (it was Juergen, Marek=
 you
and I, I think?). Regardless, this series is only tangentially related. Eve=
n if
you do have several domclusters, you'd still need a per-cluster allocator o=
f
domids. For something like domcluster-namespaces to work, we'd need to exte=
nd
createdomain to also take a domcluster-id, then the unique domain identifie=
r
comes from a domcluster-id+domid.

I tried shortly after we discussed it to sketch out a credible plan to gett=
ing
there, but there were more wrinkles than I expected. You'd definitely want =
some
domains to be in several namespaces at the same time (The hwdom, at least),
which involves some refcounting I was unsure how to do. Not a major show-st=
opper
but I hate refcounts with the intensity of a power plant.

grants also become more complicated when you have a domain in several
namespaces, because now you need several grant tables per domain (one per
namespace). The ultimate consequence of this means that if dom0 wants to cr=
eate
a new domcluster and bind itself to it, now it needs to create a NEW grant =
table
for itself. Xen is also unaware of this multi-grant table shenanigans so th=
at
needs accounting for too.

Then there's adjustments to be done on the maptrack.

So. I'd really like for this to become a reality, but it requires someone w=
ith
time to do it to sit down and walk down the rabbit hole. It was definitely
far deeper than I expected it to be. It doesn't seem to be untractably deep=
,
but deep enough that I don't want to do it in my spare time. It'd require
coordinated changes at least in Linux, Xen and the toolstack.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 15:49:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 15:49:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112087.1460515 (Exim 4.92)
	(envelope-from )
	id 1uuYge-0005TP-CF; Fri, 05 Sep 2025 15:49:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112087.1460515; Fri, 05 Sep 2025 15:49: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 1uuYge-0005TI-8X; Fri, 05 Sep 2025 15:49:16 +0000
Received: by outflank-mailman (input) for mailman id 1112087;
 Fri, 05 Sep 2025 15:49: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 1uuYgc-0005Sh-UY
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 15:49:14 +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 dc12aad4-8a6f-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 17:49:09 +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 585AgQoa017948;
 Fri, 5 Sep 2025 15:48:31 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 48usurhfn9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 15:48:31 +0000 (GMT)
Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 585FkhKr005421;
 Fri, 5 Sep 2025 15:48:30 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 48usurhfmf-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 15:48:30 +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 585D0Hpj019442;
 Fri, 5 Sep 2025 15:48:29 GMT
Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227])
 by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 48vd4na0hb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 15:48:29 +0000
Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com
 [10.20.54.103])
 by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 585FmRQ252298180
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 5 Sep 2025 15:48:27 GMT
Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id CB1582004E;
 Fri,  5 Sep 2025 15:48:26 +0000 (GMT)
Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 4EE2320043;
 Fri,  5 Sep 2025 15:48:25 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.111.48.240])
 by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri,  5 Sep 2025 15:48:25 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dc12aad4-8a6f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=mCfoUYLMC6HNsYLC2Cmci4imZfw/Ws
	ROhnMAP3rAWN8=; b=DRFTEJUzUMLxbxYuAXuLuwNqrzv8c+DrkFqe89wjY27c9F
	HPKmwnL0ffbZLOY3Rz5gz7HsHuFYQX6DqipN3T17S7pXXoPQ0OUX26rpw2bM2Ta4
	HCoGI8+peE6wgvdwt4ZhOwwGmSI9acpU5CBc496pJ6Kl9gzxQDChu/+1O6PlEWaS
	HHHSSQvfm9GSge31HtdVFwim+meO0SH5sOxV9j5RYTRpeOEqPos2duD1GYvhAUwk
	Y1ASxol3ifR8yNeQRkjgWqPhocL/iRqrC9el8+zCXSORnp/lvdaNXU7o8ETDqd86
	PWf/tQ2g4yPndZLt/k4Lq6iGIW8zebN60vYAGngw==
Date: Fri, 5 Sep 2025 17:48:23 +0200
From: Alexander Gordeev 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/7] x86/xen: support nested lazy_mmu sections (again)
Message-ID: 
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-5-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-5-kevin.brodsky@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwODMwMDAzMCBTYWx0ZWRfX5iXkXHtPokV2
 s58RZ7e813edv+vWWoqJUrrtWQXbub6NiX58yP1v9mbmzE5GTo4wfrfFkR/YZ/MbCR+iaBSdaCX
 adCNlkxNA/nEsZ3agSOH3KgEWq38b6wGZtWAzoLq+mKBzCvbn/uEMkBgl3O9f5obeDeeWy94B3P
 LgKQGohc5o/PIli23EYmnTGZI+Oj8pYgiOworIhg3wrM4u606YHplewCbIn1zTW8AdxtJuUJDYA
 iMBC7cL5Ca1p2IQg+1kqXYCy73F3DoQq/aCn8/pSszhndcjXi11V8uX0tGswVehF3dhVd7AerLt
 JrqhsabJDFJw5fzoqnl1EhDRooO7y32BwqH5cYOjZy4q0rOcELXv53bz54YHJ9HbXtIGc4qdlip
 ckpxcnXd
X-Proofpoint-GUID: u6h_butZCR90wxuVu6ifBPi5r4KK37UM
X-Proofpoint-ORIG-GUID: HU44fewV-eZEBpYhS3NFrN8FS6mJ4q6n
X-Authority-Analysis: v=2.4 cv=Ao/u3P9P c=1 sm=1 tr=0 ts=68bb064f cx=c_pps
 a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=36QzpkCBnVJsay_x71QA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-05_05,2025-09-04_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 clxscore=1015 phishscore=0 impostorscore=0 priorityscore=1501 spamscore=0
 suspectscore=0 bulkscore=0 adultscore=0 malwarescore=0 classifier=typeunknown
 authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1
 engine=8.19.0-2507300000 definitions=main-2508300030

On Thu, Sep 04, 2025 at 01:57:33PM +0100, Kevin Brodsky wrote:
...
> -static void xen_enter_lazy_mmu(void)
> +static lazy_mmu_state_t xen_enter_lazy_mmu(void)
>  {
> +	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
> +		return LAZY_MMU_NESTED;
> +
>  	enter_lazy(XEN_LAZY_MMU);
> +	return LAZY_MMU_DEFAULT;
>  }
>  
>  static void xen_flush_lazy_mmu(void)
> @@ -2167,11 +2171,12 @@ static void __init xen_post_allocator_init(void)
>  	pv_ops.mmu.write_cr3 = &xen_write_cr3;
>  }
>  
> -static void xen_leave_lazy_mmu(void)
> +static void xen_leave_lazy_mmu(lazy_mmu_state_t state)
>  {
>  	preempt_disable();
>  	xen_mc_flush();
> -	leave_lazy(XEN_LAZY_MMU);
> +	if (state != LAZY_MMU_NESTED)
> +		leave_lazy(XEN_LAZY_MMU);

Based on xen_enter_lazy_mmu(), whether this condition needs to be
executed with the preemption disabled?

Or may be this_cpu_read(xen_lazy_mode) + enter_lazy(XEN_LAZY_MMU)
should be executed with the preemption disabled?

>  	preempt_enable();
>  }

Thanks!


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 15:53:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 15:53:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112096.1460524 (Exim 4.92)
	(envelope-from )
	id 1uuYl0-00071n-RX; Fri, 05 Sep 2025 15:53:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112096.1460524; Fri, 05 Sep 2025 15:53: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 1uuYl0-00071g-Ow; Fri, 05 Sep 2025 15:53:46 +0000
Received: by outflank-mailman (input) for mailman id 1112096;
 Fri, 05 Sep 2025 15:53: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 1uuYkz-00071a-7M
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 15:53:45 +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 7f2efbbf-8a70-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 17:53:43 +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 5858qiX8001199;
 Fri, 5 Sep 2025 15:52:50 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 48wshfcpx3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 15:52:50 +0000 (GMT)
Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 585Fmcsp012235;
 Fri, 5 Sep 2025 15:52:49 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 48wshfcpwy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 15:52:49 +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 585FmxfV019937;
 Fri, 5 Sep 2025 15:52:48 GMT
Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226])
 by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 48vbmujcy7-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 05 Sep 2025 15:52:48 +0000
Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com
 [10.20.54.104])
 by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 585Fqke750659768
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 5 Sep 2025 15:52:46 GMT
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 8C56520043;
 Fri,  5 Sep 2025 15:52:46 +0000 (GMT)
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 1DCE620040;
 Fri,  5 Sep 2025 15:52:45 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.111.48.240])
 by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri,  5 Sep 2025 15:52:45 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7f2efbbf-8a70-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=yrKzRKvPlqc1QwFwyTNKlG24n0S3B0
	erGWAU2bVkVqg=; b=qnifUl96cq8S6mdWIUWZY6BIWU8yF2upNweBx/YvMVrUqk
	RurxzzOfjdHTO1vZruHBUGw3vkJ3WeEmWzLy0ib2dt0fUdi9302JluZSn5voqpb9
	tt+K2LZopne4AXw3OGAsBjWP8De3MBm1hwH4/INAMOLsTRAjDmX8jUJ/gKxB4XAc
	KrIlZNUzwzjCaqkU+ZOpln4XrPIJTWESS5y/saIRobaltfDoOVm72NdzSHeS2nKf
	hGMYLo6HZzSBX5xdzjXsfqIsGIlRMWccKTKAhN9S2rP+bQ/qPKUMPRNpVA8A/v6E
	L8fXKTqpSJEYDa6i80pdzLQ72TamFaiRukB8PM0g==
Date: Fri, 5 Sep 2025 17:52:43 +0200
From: Alexander Gordeev 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/7] powerpc/mm: support nested lazy_mmu sections
Message-ID: <074ff6ab-5868-4fde-b5bb-9e17632ad817-agordeev@linux.ibm.com>
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-6-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-6-kevin.brodsky@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: lCd6YOMsS3DuDBadSx3AqoWK9sgWIwBw
X-Authority-Analysis: v=2.4 cv=do3bC0g4 c=1 sm=1 tr=0 ts=68bb0752 cx=c_pps
 a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=j0AthGTrb4EvYsEn83oA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-ORIG-GUID: f87PfJay9odLOn37oqVwjr2CAlcWWHn1
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTAyMDA0MCBTYWx0ZWRfX6sVQx3QDeZVb
 n0/AHQXDAd1IPDvrbQDAZqWNvYoji1vUEPP9JAjcx2sdZwqxFNT8P6jKDiqCdhkxMnGuyNq6xN0
 S8g8X6OMzE3gSb6sI+vSPcwT7zIQgnHlzsA9jiitgokDLD2w11I2lobQd0RzFFdQVPBFq7gLH2W
 w3OGrenK+wBn0voMSBbmNjp1Fjlqy/CSo5Vh9PvP5VNsOgQXuA9fqz0KJ8mfFGOfUfce75STf2p
 eu65lI0DTVxqmjYKeyaFdLRjc3SxwtmZeh1Pe6KdSGdqawAHM6zOfs0r4Yils+ob60NU/kRnAup
 7+9DLLEmBuvBzuYqwqF9czbkIes2bGJOe8p5YqMQ0X/8i+oJ9lIUH4tj2BythK5q2hT0kmdi9nq
 KtlUPSlt
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-05_05,2025-09-04_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 phishscore=0 clxscore=1015 impostorscore=0 bulkscore=0 suspectscore=0
 malwarescore=0 spamscore=0 priorityscore=1501 adultscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509020040

On Thu, Sep 04, 2025 at 01:57:34PM +0100, Kevin Brodsky wrote:
...
>  static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	struct ppc64_tlb_batch *batch;
> +	int lazy_mmu_nested;
>  
>  	if (radix_enabled())
>  		return LAZY_MMU_DEFAULT;
> @@ -39,9 +40,14 @@ static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  	 */
>  	preempt_disable();
>  	batch = this_cpu_ptr(&ppc64_tlb_batch);
> -	batch->active = 1;
> +	lazy_mmu_nested = batch->active;
>  
> -	return LAZY_MMU_DEFAULT;
> +	if (!lazy_mmu_nested) {

Why not just?

	if (!batch->active) {

> +		batch->active = 1;
> +		return LAZY_MMU_DEFAULT;
> +	} else {
> +		return LAZY_MMU_NESTED;
> +	}
>  }
>  
>  static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
> @@ -54,7 +60,10 @@ static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  
>  	if (batch->index)
>  		__flush_tlb_pending(batch);
> -	batch->active = 0;
> +
> +	if (state != LAZY_MMU_NESTED)
> +		batch->active = 0;
> +
>  	preempt_enable();
>  }

Thanks!


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 16:12:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 16:12:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112123.1460535 (Exim 4.92)
	(envelope-from )
	id 1uuZ2s-00021r-9B; Fri, 05 Sep 2025 16:12:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112123.1460535; Fri, 05 Sep 2025 16: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 1uuZ2s-00021k-6U; Fri, 05 Sep 2025 16:12:14 +0000
Received: by outflank-mailman (input) for mailman id 1112123;
 Fri, 05 Sep 2025 16:12:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuZ2r-00021e-0L
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:12:13 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuZ2q-0081Om-1Q
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:12:12 +0000
Received: from mail-vk1-f181.google.com ([209.85.221.181])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uuZ2q-00HCbg-1y
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:12:12 +0000
Received: by mail-vk1-f181.google.com with SMTP id
 71dfb90a1353d-544ad727e87so1834916e0c.2
 for ; Fri, 05 Sep 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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:To:Subject:Message-ID:Date:
	From:MIME-Version; bh=DI5JWH5qM1LPNZ0VXiqV4VaX9KCnlMFHYnnAJNngHHU=; b=JAngV4S
	eMLQP28imoaKyrS8815may6kgEKufkIqH+RMD6vmcRSXYM1iJlc7RggCi8V86yyGp1TttgL+Y9nlS
	4NCe4sp3d5QXwuy/mBJ7Z2BA3zs1IA0STSW9fbTyUQ3Hr24X6Pz6DrSteCKidkNqMIivDtNoI8DAX
	vDJVOPxANw=;
X-Gm-Message-State: AOJu0Yxmzg7fxWcODI9go5DfQac9WihkVYbsJM02H8zKr+frOCp1QKt8
	lh5D+GWSqK5X3ilhQ1q0Snh1cVtaREvHGywJO880Ip/l+DP9RDn0lt/j0S4qCOUko9sDkJ1wagG
	bjm5z7C46Wz7qLMhoZmrz41BT+pIGFs0=
X-Google-Smtp-Source: AGHT+IGyxo9LHvXQSpSuAIBx6nQiCl/ewyYMuSdjJ26/fkJQfWMZOTO61RcFN1QOPfxKRDX9CdSPwiTaMKQjDux1Yig=
X-Received: by 2002:a05:6122:4f82:b0:531:236f:1283 with SMTP id
 71dfb90a1353d-544a024826cmr8562956e0c.10.1757088732182; Fri, 05 Sep 2025
 09:12:12 -0700 (PDT)
MIME-Version: 1.0
From: Cody Zuschlag 
Date: Fri, 5 Sep 2025 18:12:00 +0200
X-Gmail-Original-Message-ID: 
X-Gm-Features: Ac12FXyB3PnexJ6si2VCYqOGyRD-BYzwcUAHS7mSMdygDGE4XfxRqK4JNtkfQ-o
Message-ID: 
Subject: [REMINDER] Avoid automatic warning banners in xen-devel emails
To: xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="000000000000b8809d063e101905"

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

Hi everyone,

Emails to this list *should not include* automatic warning banners like:

WARNING: This message originated outside of [Company Name]=E2=80=A6


We understand these are added automatically by some corporate systems and
aren=E2=80=99t the sender=E2=80=99s intention. However, since *messages are=
 publicly
archived*, these warnings are inaccurate and can be distracting or
misleading. They also clutter replies and make threads harder to follow.

If possible, we encourage contributors to:

   - Request an exception for FOSS mailing lists,
   - Use a company-provided developer address (if available),
   - Or send from a personal address that avoids these banners.


You can find more community guidance here:

   - https://subspace.kernel.org/etiquette.html
   - https://wiki.xenproject.org/wiki/Xen_Users_Netiquette


Thanks everyone for helping keep our discussions clean, readable, and for
being a member of the community!

Best regards,


Cody Zuschlag
Xen Project - Community Manager

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


Hi everyone,

Emails to this list sho=
uld not include automatic warning banners like:

WARNING: This message originated outside =
of [Company Name]=E2=80=A6

We understand these are added au=
tomatically by some corporate systems and aren=E2=80=99t the sender=E2=80=
=99s intention. However, since messages are publicly archived, these=
 warnings are inaccurate and can be distracting or misleading. They also cl=
utter replies and make threads harder to follow.

If possible, we enc=
ourage contributors to:
  • Request an exception for FOSS mailing li=
sts,
  • Use a company-provided developer address (if available),
    • <=
li>Or send from a personal address that avoids these banners.

=
You can find more community guidance here:
Thanks everyone for helping keep our discussions clean, readable, and for =
being a member of the community!

Best regards,

<=
div>

Cody Zuschlag
Xen Project - Community Man=
ager


--000000000000b8809d063e101905--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 16:21:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 16:21:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112135.1460545 (Exim 4.92)
	(envelope-from )
	id 1uuZBO-0003fU-2M; Fri, 05 Sep 2025 16:21:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112135.1460545; Fri, 05 Sep 2025 16:21: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 1uuZBN-0003fN-Vc; Fri, 05 Sep 2025 16:21:01 +0000
Received: by outflank-mailman (input) for mailman id 1112135;
 Fri, 05 Sep 2025 16:21: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 1uuZBM-0003fH-Ga
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:21:01 +0000
Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com
 [210.118.77.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4c0047a8-8a74-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 18:20:56 +0200 (CEST)
Received: from eucas1p1.samsung.com (unknown [182.198.249.206])
 by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id
 20250905162054euoutp02e77d244e0cafd5d952c3328dee47f20d~ib14B25gK1750017500euoutp02R;
 Fri,  5 Sep 2025 16:20:54 +0000 (GMT)
Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by
 eucas1p1.samsung.com (KnoxPortal) with ESMTPA id
 20250905162053eucas1p1b9fec0adff4c7d35b6b6add1249d881b~ib13cmmn22364123641eucas1p1e;
 Fri,  5 Sep 2025 16:20:53 +0000 (GMT)
Received: from [106.210.134.192] (unknown [106.210.134.192]) by
 eusmtip1.samsung.com (KnoxPortal) with ESMTPA id
 20250905162051eusmtip1e4d21f9bc61a423579ce48c4e618b6af~ib11sI1Nb2344623446eusmtip1s;
 Fri,  5 Sep 2025 16:20:51 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c0047a8-8a74-11f0-9d12-b5c5bf9af7f9
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250905162054euoutp02e77d244e0cafd5d952c3328dee47f20d~ib14B25gK1750017500euoutp02R
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;
	s=mail20170921; t=1757089254;
	bh=r+uJO0KPgHoqZtk4UB2d6cw6Lk6DbEyEjBWC0P92zgA=;
	h=Date:Subject:To:Cc:From:In-Reply-To:References:From;
	b=BH1gDTlm5/u+/rXGc9JT+K9NjInJASEOMUNJK2lpN97zPJKhgFZ4BwyWAKG5fWJ4U
	 SwthcsWnGvBGq4ZFisO0dXzRvPNenkJ22SKsGAEN3TZeM/LeDo1/zUbv9zcz1Jnd3W
	 ZVdWIWrJTUMJGFYQL2lzvf5ASBpb6d4tBQU3KY7E=
Message-ID: <7557f31e-1504-4f62-b00b-70e25bb793cb@samsung.com>
Date: Fri, 5 Sep 2025 18:20:51 +0200
MIME-Version: 1.0
User-Agent: Betterbird (Windows)
Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based
 API
To: Jason Gunthorpe , Leon Romanovsky 
Cc: Abdiel Janulgue , Alexander Potapenko
	, Alex Gaynor , Andrew Morton
	, Christoph Hellwig , Danilo
	Krummrich , iommu@lists.linux.dev, Jason Wang
	, Jens Axboe , Joerg Roedel
	, Jonathan Corbet , Juergen Gross
	, kasan-dev@googlegroups.com, Keith Busch
	, linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan
	, Masami Hiramatsu , Michael
	Ellerman , "Michael S. Tsirkin" , Miguel
	Ojeda , Robin Murphy ,
	rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano
	Stabellini , Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Content-Language: en-US
From: Marek Szyprowski 
In-Reply-To: <20250829131625.GK9469@nvidia.com>
Content-Transfer-Encoding: 8bit
X-CMS-MailID: 20250905162053eucas1p1b9fec0adff4c7d35b6b6add1249d881b
X-Msg-Generator: CA
Content-Type: text/plain; charset="utf-8"
X-RootMTR: 20250829131641eucas1p2ddd687e4e8c16a2bc64a293b6364fa6f
X-EPHeader: CA
X-CMS-RootMailID: 20250829131641eucas1p2ddd687e4e8c16a2bc64a293b6364fa6f
References: 
	
	<20250829131625.GK9469@nvidia.com>

On 29.08.2025 15:16, Jason Gunthorpe wrote:
> On Tue, Aug 19, 2025 at 08:36:44PM +0300, Leon Romanovsky wrote:
>
>> This series does the core code and modern flows. A followup series
>> will give the same treatment to the legacy dma_ops implementation.
> I took a quick check over this to see that it is sane.  I think using
> phys is an improvement for most of the dma_ops implemenations.
>
>    arch/sparc/kernel/pci_sun4v.c
>    arch/sparc/kernel/iommu.c
>      Uses __pa to get phys from the page, never touches page
>
>    arch/alpha/kernel/pci_iommu.c
>    arch/sparc/mm/io-unit.c
>    drivers/parisc/ccio-dma.c
>    drivers/parisc/sba_iommu.c
>      Does page_addres() and later does __pa on it. Doesn't touch struct page
>
>    arch/x86/kernel/amd_gart_64.c
>    drivers/xen/swiotlb-xen.c
>    arch/mips/jazz/jazzdma.c
>      Immediately does page_to_phys(), never touches struct page
>
>    drivers/vdpa/vdpa_user/vduse_dev.c
>      Does page_to_phys() to call iommu_map()
>
>    drivers/xen/grant-dma-ops.c
>      Does page_to_pfn() and nothing else
>
>    arch/powerpc/platforms/ps3/system-bus.c
>     This is a maze but I think it wants only phys and the virt is only
>     used for debug prints.
>
> The above all never touch a KVA and just want a phys_addr_t.
>
> The below are touching the KVA somehow:
>
>    arch/sparc/mm/iommu.c
>    arch/arm/mm/dma-mapping.c
>      Uses page_address to cache flush, would be happy with phys_to_virt()
>      and a PhysHighMem()
>
>    arch/powerpc/kernel/dma-iommu.c
>    arch/powerpc/platforms/pseries/vio.c
>     Uses iommu_map_page() which wants phys_to_virt(), doesn't touch
>     struct page
>
>    arch/powerpc/platforms/pseries/ibmebus.c
>      Returns phys_to_virt() as dma_addr_t.
>
> The two PPC ones are weird, I didn't figure out how that was working..
>
> It would be easy to make map_phys patches for about half of these, in
> the first grouping. Doing so would also grant those arches
> map_resource capability.
>
> Overall I didn't think there was any reduction in maintainability in
> these places. Most are improvements eliminating code, and some are
> just switching to phys_to_virt() from page_address(), which we could
> further guard with DMA_ATTR_MMIO and a check for highmem.

Thanks for this summary.

However I would still like to get an answer for the simple question - 
why all this work cannot be replaced by a simple use of dma_map_resource()?

I've checked the most advertised use case in 
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio 
and I still don't see the reason why it cannot be based 
on dma_map_resource() API? I'm aware of the little asymmetry of the 
client calls is such case, indeed it is not preety, but this should work 
even now:

phys = phys_vec[i].paddr;

if (is_mmio)
     dma_map_resource(phys, len, ...);
else
     dma_map_page(phys_to_page(phys), offset_in_page(phys), ...);

What did I miss?

I'm not against this rework, but I would really like to know the 
rationale. I know that the 2-step dma-mapping API also use phys 
addresses and this is the same direction.

This patchset focuses only on the dma_map_page -> dma_map_phys rework. 
There are also other interfaces, like dma_alloc_pages() and so far 
nothing has been proposed for them so far.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 16:22:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 16:22:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112144.1460554 (Exim 4.92)
	(envelope-from )
	id 1uuZCM-0004Au-Bu; Fri, 05 Sep 2025 16:22:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112144.1460554; Fri, 05 Sep 2025 16: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 1uuZCM-0004An-98; Fri, 05 Sep 2025 16:22:02 +0000
Received: by outflank-mailman (input) for mailman id 1112144;
 Fri, 05 Sep 2025 16: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 1uuZCL-0004AY-KO
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:22:01 +0000
Received: from mailout2.w1.samsung.com (unknown [210.118.77.12])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6c38e7c4-8a74-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 18:21:50 +0200 (CEST)
Received: from eucas1p2.samsung.com (unknown [182.198.249.207])
 by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id
 20250905162148euoutp02604d107873dc75c605be1c2733dda215~ib2qaX6dY1912019120euoutp02_;
 Fri,  5 Sep 2025 16:21:48 +0000 (GMT)
Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by
 eucas1p2.samsung.com (KnoxPortal) with ESMTPA id
 20250905162147eucas1p221ca4e33b0e6396d02908377c6c5b919~ib2pcEwbH0974409744eucas1p2p;
 Fri,  5 Sep 2025 16:21:47 +0000 (GMT)
Received: from [106.210.134.192] (unknown [106.210.134.192]) by
 eusmtip2.samsung.com (KnoxPortal) with ESMTPA id
 20250905162145eusmtip2342879dbc38ddfe0bbff0062e179f725~ib2nn8yb40979609796eusmtip2i;
 Fri,  5 Sep 2025 16:21:45 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c38e7c4-8a74-11f0-9809-7dc792cee155
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250905162148euoutp02604d107873dc75c605be1c2733dda215~ib2qaX6dY1912019120euoutp02_
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;
	s=mail20170921; t=1757089308;
	bh=SihwygswkUbDkI6TEnNcbeL2/U8m9DIalmjgcknmvOM=;
	h=Date:Subject:To:Cc:From:In-Reply-To:References:From;
	b=TMub8T2AywFu0rH6DpstDybTJowRFDNOBYLDkp6Xzd7qGqwZ8ouj39Pirm529DkBN
	 NnHkZVznzmV8UpKTT429M04YfUlrnl7jwCyuT5my78L0ccVnDyJcAFZshVqjrwHKoZ
	 N2bRFb+07AkY+pQ3ta9ua+sPeKgv85ar3t0gyurM=
Message-ID: <087e7f3d-1e0d-4efe-822f-72d16d161a60@samsung.com>
Date: Fri, 5 Sep 2025 18:21:44 +0200
MIME-Version: 1.0
User-Agent: Betterbird (Windows)
Subject: Re: [PATCH v5 07/16] dma-mapping: convert dma_direct_*map_page to
 be phys_addr_t based
To: Leon Romanovsky 
Cc: Leon Romanovsky , Jason Gunthorpe ,
	Abdiel Janulgue , Alexander Potapenko
	, Alex Gaynor , Andrew Morton
	, Christoph Hellwig , Danilo
	Krummrich , David Hildenbrand ,
	iommu@lists.linux.dev, Jason Wang , Jens Axboe
	, Joerg Roedel , Jonathan Corbet
	, Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan
	, Masami Hiramatsu , Michael
	Ellerman , "Michael S. Tsirkin" , Miguel
	Ojeda , Robin Murphy ,
	rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano
	Stabellini , Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Content-Language: en-US
From: Marek Szyprowski 
In-Reply-To: <6b2f4cb436c98d6342db69e965a5621707b9711f.1756822782.git.leon@kernel.org>
Content-Transfer-Encoding: 7bit
X-CMS-MailID: 20250905162147eucas1p221ca4e33b0e6396d02908377c6c5b919
X-Msg-Generator: CA
Content-Type: text/plain; charset="utf-8"
X-RootMTR: 20250902144935eucas1p253de9e94315de54325cc61dea9c76490
X-EPHeader: CA
X-CMS-RootMailID: 20250902144935eucas1p253de9e94315de54325cc61dea9c76490
References: 
	
	<6b2f4cb436c98d6342db69e965a5621707b9711f.1756822782.git.leon@kernel.org>

On 02.09.2025 16:48, Leon Romanovsky wrote:
> From: Leon Romanovsky 
>
> Convert the DMA direct mapping functions to accept physical addresses
> directly instead of page+offset parameters. The functions were already
> operating on physical addresses internally, so this change eliminates
> the redundant page-to-physical conversion at the API boundary.
>
> The functions dma_direct_map_page() and dma_direct_unmap_page() are
> renamed to dma_direct_map_phys() and dma_direct_unmap_phys() respectively,
> with their calling convention changed from (struct page *page,
> unsigned long offset) to (phys_addr_t phys).
>
> Architecture-specific functions arch_dma_map_page_direct() and
> arch_dma_unmap_page_direct() are similarly renamed to
> arch_dma_map_phys_direct() and arch_dma_unmap_phys_direct().
>
> The is_pci_p2pdma_page() checks are replaced with DMA_ATTR_MMIO checks
> to allow integration with dma_direct_map_resource and dma_direct_map_phys()
> is extended to support MMIO path either.
>
> Reviewed-by: Jason Gunthorpe 
> Signed-off-by: Leon Romanovsky 
> ---
>   arch/powerpc/kernel/dma-iommu.c |  4 +--
>   include/linux/dma-map-ops.h     |  8 ++---
>   kernel/dma/direct.c             |  6 ++--
>   kernel/dma/direct.h             | 57 +++++++++++++++++++++------------
>   kernel/dma/mapping.c            |  8 ++---
>   5 files changed, 49 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index 4d64a5db50f3..0359ab72cd3b 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -14,7 +14,7 @@
>   #define can_map_direct(dev, addr) \
>   	((dev)->bus_dma_limit >= phys_to_dma((dev), (addr)))
>   
> -bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr)
> +bool arch_dma_map_phys_direct(struct device *dev, phys_addr_t addr)
>   {
>   	if (likely(!dev->bus_dma_limit))
>   		return false;
> @@ -24,7 +24,7 @@ bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr)
>   
>   #define is_direct_handle(dev, h) ((h) >= (dev)->archdata.dma_offset)
>   
> -bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t dma_handle)
> +bool arch_dma_unmap_phys_direct(struct device *dev, dma_addr_t dma_handle)
>   {
>   	if (likely(!dev->bus_dma_limit))
>   		return false;
> diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
> index f48e5fb88bd5..71f5b3025415 100644
> --- a/include/linux/dma-map-ops.h
> +++ b/include/linux/dma-map-ops.h
> @@ -392,15 +392,15 @@ void *arch_dma_set_uncached(void *addr, size_t size);
>   void arch_dma_clear_uncached(void *addr, size_t size);
>   
>   #ifdef CONFIG_ARCH_HAS_DMA_MAP_DIRECT
> -bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr);
> -bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t dma_handle);
> +bool arch_dma_map_phys_direct(struct device *dev, phys_addr_t addr);
> +bool arch_dma_unmap_phys_direct(struct device *dev, dma_addr_t dma_handle);
>   bool arch_dma_map_sg_direct(struct device *dev, struct scatterlist *sg,
>   		int nents);
>   bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist *sg,
>   		int nents);
>   #else
> -#define arch_dma_map_page_direct(d, a)		(false)
> -#define arch_dma_unmap_page_direct(d, a)	(false)
> +#define arch_dma_map_phys_direct(d, a)		(false)
> +#define arch_dma_unmap_phys_direct(d, a)	(false)
>   #define arch_dma_map_sg_direct(d, s, n)		(false)
>   #define arch_dma_unmap_sg_direct(d, s, n)	(false)
>   #endif
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 24c359d9c879..fa75e3070073 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -453,7 +453,7 @@ void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl,
>   		if (sg_dma_is_bus_address(sg))
>   			sg_dma_unmark_bus_address(sg);
>   		else
> -			dma_direct_unmap_page(dev, sg->dma_address,
> +			dma_direct_unmap_phys(dev, sg->dma_address,
>   					      sg_dma_len(sg), dir, attrs);
>   	}
>   }
> @@ -476,8 +476,8 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
>   			 */
>   			break;
>   		case PCI_P2PDMA_MAP_NONE:
> -			sg->dma_address = dma_direct_map_page(dev, sg_page(sg),
> -					sg->offset, sg->length, dir, attrs);
> +			sg->dma_address = dma_direct_map_phys(dev, sg_phys(sg),
> +					sg->length, dir, attrs);
>   			if (sg->dma_address == DMA_MAPPING_ERROR) {
>   				ret = -EIO;
>   				goto out_unmap;
> diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
> index d2c0b7e632fc..3f4792910604 100644
> --- a/kernel/dma/direct.h
> +++ b/kernel/dma/direct.h
> @@ -80,42 +80,57 @@ static inline void dma_direct_sync_single_for_cpu(struct device *dev,
>   		arch_dma_mark_clean(paddr, size);
>   }
>   
> -static inline dma_addr_t dma_direct_map_page(struct device *dev,
> -		struct page *page, unsigned long offset, size_t size,
> -		enum dma_data_direction dir, unsigned long attrs)
> +static inline dma_addr_t dma_direct_map_phys(struct device *dev,
> +		phys_addr_t phys, size_t size, enum dma_data_direction dir,
> +		unsigned long attrs)
>   {
> -	phys_addr_t phys = page_to_phys(page) + offset;
> -	dma_addr_t dma_addr = phys_to_dma(dev, phys);
> +	dma_addr_t dma_addr;
>   
>   	if (is_swiotlb_force_bounce(dev)) {
> -		if (is_pci_p2pdma_page(page))
> -			return DMA_MAPPING_ERROR;
> +		if (attrs & DMA_ATTR_MMIO)
> +			goto err_overflow;
> +
>   		return swiotlb_map(dev, phys, size, dir, attrs);
>   	}
>   
> -	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
> -	    dma_kmalloc_needs_bounce(dev, size, dir)) {
> -		if (is_pci_p2pdma_page(page))
> -			return DMA_MAPPING_ERROR;
> -		if (is_swiotlb_active(dev))
> -			return swiotlb_map(dev, phys, size, dir, attrs);
> -
> -		dev_WARN_ONCE(dev, 1,
> -			     "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
> -			     &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
> -		return DMA_MAPPING_ERROR;
> +	if (attrs & DMA_ATTR_MMIO) {
> +		dma_addr = phys;
> +		if (unlikely(dma_capable(dev, dma_addr, size, false)))

"!dma_capable(dev, dma_addr, size, false)" in the above line.

It took me a while to find this after noticing that this patchset breaks booting some of me test systems.


> +			goto err_overflow;
> +	} else {
> +		dma_addr = phys_to_dma(dev, phys);
> +		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
> +		    dma_kmalloc_needs_bounce(dev, size, dir)) {
> +			if (is_swiotlb_active(dev))
> +				return swiotlb_map(dev, phys, size, dir, attrs);
> +
> +			goto err_overflow;
> +		}
>   	}
>   
> -	if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> +	if (!dev_is_dma_coherent(dev) &&
> +	    !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
>   		arch_sync_dma_for_device(phys, size, dir);
>   	return dma_addr;
> +
> +err_overflow:
> +	dev_WARN_ONCE(
> +		dev, 1,
> +		"DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
> +		&dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
> +	return DMA_MAPPING_ERROR;
>   }
>   
> -static inline void dma_direct_unmap_page(struct device *dev, dma_addr_t addr,
> +static inline void dma_direct_unmap_phys(struct device *dev, dma_addr_t addr,
>   		size_t size, enum dma_data_direction dir, unsigned long attrs)
>   {
> -	phys_addr_t phys = dma_to_phys(dev, addr);
> +	phys_addr_t phys;
> +
> +	if (attrs & DMA_ATTR_MMIO)
> +		/* nothing to do: uncached and no swiotlb */
> +		return;
>   
> +	phys = dma_to_phys(dev, addr);
>   	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
>   		dma_direct_sync_single_for_cpu(dev, addr, size, dir);
>   
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 58482536db9b..80481a873340 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -166,8 +166,8 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
>   		return DMA_MAPPING_ERROR;
>   
>   	if (dma_map_direct(dev, ops) ||
> -	    arch_dma_map_page_direct(dev, phys + size))
> -		addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
> +	    arch_dma_map_phys_direct(dev, phys + size))
> +		addr = dma_direct_map_phys(dev, phys, size, dir, attrs);
>   	else if (use_dma_iommu(dev))
>   		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
>   	else
> @@ -187,8 +187,8 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
>   
>   	BUG_ON(!valid_dma_direction(dir));
>   	if (dma_map_direct(dev, ops) ||
> -	    arch_dma_unmap_page_direct(dev, addr + size))
> -		dma_direct_unmap_page(dev, addr, size, dir, attrs);
> +	    arch_dma_unmap_phys_direct(dev, addr + size))
> +		dma_direct_unmap_phys(dev, addr, size, dir, attrs);
>   	else if (use_dma_iommu(dev))
>   		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
>   	else

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 16:27:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 16:27:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112164.1460565 (Exim 4.92)
	(envelope-from )
	id 1uuZHE-0004sX-2v; Fri, 05 Sep 2025 16:27:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112164.1460565; Fri, 05 Sep 2025 16: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 1uuZHD-0004sQ-Vc; Fri, 05 Sep 2025 16:27:03 +0000
Received: by outflank-mailman (input) for mailman id 1112164;
 Fri, 05 Sep 2025 16: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 1uuZHB-0004sK-MT
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:27:02 +0000
Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com
 [210.118.77.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 258a5ffb-8a75-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 18:26:59 +0200 (CEST)
Received: from eucas1p1.samsung.com (unknown [182.198.249.206])
 by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id
 20250905162659euoutp0209439914e512e98f87c7003f3b7cb2ad~ib7L2Tvq02121121211euoutp02j;
 Fri,  5 Sep 2025 16:26:59 +0000 (GMT)
Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by
 eucas1p1.samsung.com (KnoxPortal) with ESMTPA id
 20250905162658eucas1p1a568426150516afc440f0b45dae6597c~ib7LZwBNr2591525915eucas1p15;
 Fri,  5 Sep 2025 16:26:58 +0000 (GMT)
Received: from [106.210.134.192] (unknown [106.210.134.192]) by
 eusmtip2.samsung.com (KnoxPortal) with ESMTPA id
 20250905162656eusmtip2af2311515d499a88f1b631068b965d1d~ib7JPIWTy2564625646eusmtip2E;
 Fri,  5 Sep 2025 16:26:56 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 258a5ffb-8a75-11f0-9809-7dc792cee155
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250905162659euoutp0209439914e512e98f87c7003f3b7cb2ad~ib7L2Tvq02121121211euoutp02j
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;
	s=mail20170921; t=1757089619;
	bh=JratdkJhfp1iQGSSFRxxu72lgWMqyE2NX54DSFPZHRY=;
	h=Date:Subject:To:Cc:From:In-Reply-To:References:From;
	b=k7Zmm/l4ml+LB1qItvZOEqZY+Sox4+FPDDVEoRVLzx1Wvrm8UN4/WmasRnz/XdrC4
	 Uz3NPTnr8v6KtMSyeOqg/plUlqcNjUQLJ68wa1aVQkIC0f+6gNInm3vAulUU4bbtBs
	 bFH/HZYMbbkZGGDU62q/7lnZ1i5322h/6rAkdcfU=
Message-ID: 
Date: Fri, 5 Sep 2025 18:26:55 +0200
MIME-Version: 1.0
User-Agent: Betterbird (Windows)
Subject: Re: [PATCH v4 03/16] dma-debug: refactor to use physical addresses
 for page mapping
To: Leon Romanovsky 
Cc: Leon Romanovsky , Jason Gunthorpe ,
	Abdiel Janulgue , Alexander Potapenko
	, Alex Gaynor , Andrew Morton
	, Christoph Hellwig , Danilo
	Krummrich , iommu@lists.linux.dev, Jason Wang
	, Jens Axboe , Joerg Roedel
	, Jonathan Corbet , Juergen Gross
	, kasan-dev@googlegroups.com, Keith Busch
	, linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan
	, Masami Hiramatsu , Michael
	Ellerman , "Michael S. Tsirkin" , Miguel
	Ojeda , Robin Murphy ,
	rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano
	Stabellini , Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Content-Language: en-US
From: Marek Szyprowski 
In-Reply-To: <478d5b7135008b3c82f100faa9d3830839fc6562.1755624249.git.leon@kernel.org>
Content-Transfer-Encoding: 7bit
X-CMS-MailID: 20250905162658eucas1p1a568426150516afc440f0b45dae6597c
X-Msg-Generator: CA
Content-Type: text/plain; charset="utf-8"
X-RootMTR: 20250819173739eucas1p104ee9e80546f92ef250115edd799fc6d
X-EPHeader: CA
X-CMS-RootMailID: 20250819173739eucas1p104ee9e80546f92ef250115edd799fc6d
References: 
	
	<478d5b7135008b3c82f100faa9d3830839fc6562.1755624249.git.leon@kernel.org>

On 19.08.2025 19:36, Leon Romanovsky wrote:
> From: Leon Romanovsky 
>
> Convert the DMA debug infrastructure from page-based to physical address-based
> mapping as a preparation to rely on physical address for DMA mapping routines.
>
> The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and
> changes its signature to accept a phys_addr_t parameter instead of struct page
> and offset. Similarly, debug_dma_unmap_page() becomes debug_dma_unmap_phys().
> A new dma_debug_phy type is introduced to distinguish physical address mappings
> from other debug entry types. All callers throughout the codebase are updated
> to pass physical addresses directly, eliminating the need for page-to-physical
> conversion in the debug layer.
>
> This refactoring eliminates the need to convert between page pointers and
> physical addresses in the debug layer, making the code more efficient and
> consistent with the DMA mapping API's physical address focus.
>
> Reviewed-by: Jason Gunthorpe 
> Signed-off-by: Leon Romanovsky 

This change needs to be based on top of this patch 
https://lore.kernel.org/all/20250828-dma-debug-fix-noncoherent-dma-check-v1-1-76e9be0dd7fc@oss.qualcomm.com 
so the easiest way would be to rebase this patchset onto 
https://web.git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git/log/?h=dma-mapping-fixes 
branch (resolving conflicts is trivial) for the next version.

> ---
>   Documentation/core-api/dma-api.rst |  4 ++--
>   kernel/dma/debug.c                 | 28 +++++++++++++++++-----------
>   kernel/dma/debug.h                 | 16 +++++++---------
>   kernel/dma/mapping.c               | 15 ++++++++-------
>   4 files changed, 34 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst
> index 3087bea715ed..ca75b3541679 100644
> --- a/Documentation/core-api/dma-api.rst
> +++ b/Documentation/core-api/dma-api.rst
> @@ -761,7 +761,7 @@ example warning message may look like this::
>   	[] find_busiest_group+0x207/0x8a0
>   	[] _spin_lock_irqsave+0x1f/0x50
>   	[] check_unmap+0x203/0x490
> -	[] debug_dma_unmap_page+0x49/0x50
> +	[] debug_dma_unmap_phys+0x49/0x50
>   	[] nv_tx_done_optimized+0xc6/0x2c0
>   	[] nv_nic_irq_optimized+0x73/0x2b0
>   	[] handle_IRQ_event+0x34/0x70
> @@ -855,7 +855,7 @@ that a driver may be leaking mappings.
>   dma-debug interface debug_dma_mapping_error() to debug drivers that fail
>   to check DMA mapping errors on addresses returned by dma_map_single() and
>   dma_map_page() interfaces. This interface clears a flag set by
> -debug_dma_map_page() to indicate that dma_mapping_error() has been called by
> +debug_dma_map_phys() to indicate that dma_mapping_error() has been called by
>   the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
>   this flag is still set, prints warning message that includes call trace that
>   leads up to the unmap. This interface can be called from dma_mapping_error()
> diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
> index e43c6de2bce4..da6734e3a4ce 100644
> --- a/kernel/dma/debug.c
> +++ b/kernel/dma/debug.c
> @@ -39,6 +39,7 @@ enum {
>   	dma_debug_sg,
>   	dma_debug_coherent,
>   	dma_debug_resource,
> +	dma_debug_phy,
>   };
>   
>   enum map_err_types {
> @@ -141,6 +142,7 @@ static const char *type2name[] = {
>   	[dma_debug_sg] = "scatter-gather",
>   	[dma_debug_coherent] = "coherent",
>   	[dma_debug_resource] = "resource",
> +	[dma_debug_phy] = "phy",
>   };
>   
>   static const char *dir2name[] = {
> @@ -1201,9 +1203,8 @@ void debug_dma_map_single(struct device *dev, const void *addr,
>   }
>   EXPORT_SYMBOL(debug_dma_map_single);
>   
> -void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
> -			size_t size, int direction, dma_addr_t dma_addr,
> -			unsigned long attrs)
> +void debug_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
> +		int direction, dma_addr_t dma_addr, unsigned long attrs)
>   {
>   	struct dma_debug_entry *entry;
>   
> @@ -1218,19 +1219,24 @@ void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
>   		return;
>   
>   	entry->dev       = dev;
> -	entry->type      = dma_debug_single;
> -	entry->paddr	 = page_to_phys(page) + offset;
> +	entry->type      = dma_debug_phy;
> +	entry->paddr	 = phys;
>   	entry->dev_addr  = dma_addr;
>   	entry->size      = size;
>   	entry->direction = direction;
>   	entry->map_err_type = MAP_ERR_NOT_CHECKED;
>   
> -	check_for_stack(dev, page, offset);
> +	if (!(attrs & DMA_ATTR_MMIO)) {
> +		struct page *page = phys_to_page(phys);
> +		size_t offset = offset_in_page(page);
>   
> -	if (!PageHighMem(page)) {
> -		void *addr = page_address(page) + offset;
> +		check_for_stack(dev, page, offset);
>   
> -		check_for_illegal_area(dev, addr, size);
> +		if (!PageHighMem(page)) {
> +			void *addr = page_address(page) + offset;
> +
> +			check_for_illegal_area(dev, addr, size);
> +		}
>   	}
>   
>   	add_dma_entry(entry, attrs);
> @@ -1274,11 +1280,11 @@ void debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>   }
>   EXPORT_SYMBOL(debug_dma_mapping_error);
>   
> -void debug_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
> +void debug_dma_unmap_phys(struct device *dev, dma_addr_t dma_addr,
>   			  size_t size, int direction)
>   {
>   	struct dma_debug_entry ref = {
> -		.type           = dma_debug_single,
> +		.type           = dma_debug_phy,
>   		.dev            = dev,
>   		.dev_addr       = dma_addr,
>   		.size           = size,
> diff --git a/kernel/dma/debug.h b/kernel/dma/debug.h
> index f525197d3cae..76adb42bffd5 100644
> --- a/kernel/dma/debug.h
> +++ b/kernel/dma/debug.h
> @@ -9,12 +9,11 @@
>   #define _KERNEL_DMA_DEBUG_H
>   
>   #ifdef CONFIG_DMA_API_DEBUG
> -extern void debug_dma_map_page(struct device *dev, struct page *page,
> -			       size_t offset, size_t size,
> -			       int direction, dma_addr_t dma_addr,
> +extern void debug_dma_map_phys(struct device *dev, phys_addr_t phys,
> +			       size_t size, int direction, dma_addr_t dma_addr,
>   			       unsigned long attrs);
>   
> -extern void debug_dma_unmap_page(struct device *dev, dma_addr_t addr,
> +extern void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr,
>   				 size_t size, int direction);
>   
>   extern void debug_dma_map_sg(struct device *dev, struct scatterlist *sg,
> @@ -55,14 +54,13 @@ extern void debug_dma_sync_sg_for_device(struct device *dev,
>   					 struct scatterlist *sg,
>   					 int nelems, int direction);
>   #else /* CONFIG_DMA_API_DEBUG */
> -static inline void debug_dma_map_page(struct device *dev, struct page *page,
> -				      size_t offset, size_t size,
> -				      int direction, dma_addr_t dma_addr,
> -				      unsigned long attrs)
> +static inline void debug_dma_map_phys(struct device *dev, phys_addr_t phys,
> +				      size_t size, int direction,
> +				      dma_addr_t dma_addr, unsigned long attrs)
>   {
>   }
>   
> -static inline void debug_dma_unmap_page(struct device *dev, dma_addr_t addr,
> +static inline void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr,
>   					size_t size, int direction)
>   {
>   }
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 107e4a4d251d..4c1dfbabb8ae 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -157,6 +157,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
>   		unsigned long attrs)
>   {
>   	const struct dma_map_ops *ops = get_dma_ops(dev);
> +	phys_addr_t phys = page_to_phys(page) + offset;
>   	dma_addr_t addr;
>   
>   	BUG_ON(!valid_dma_direction(dir));
> @@ -165,16 +166,15 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
>   		return DMA_MAPPING_ERROR;
>   
>   	if (dma_map_direct(dev, ops) ||
> -	    arch_dma_map_page_direct(dev, page_to_phys(page) + offset + size))
> +	    arch_dma_map_page_direct(dev, phys + size))
>   		addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
>   	else if (use_dma_iommu(dev))
>   		addr = iommu_dma_map_page(dev, page, offset, size, dir, attrs);
>   	else
>   		addr = ops->map_page(dev, page, offset, size, dir, attrs);
>   	kmsan_handle_dma(page, offset, size, dir);
> -	trace_dma_map_page(dev, page_to_phys(page) + offset, addr, size, dir,
> -			   attrs);
> -	debug_dma_map_page(dev, page, offset, size, dir, addr, attrs);
> +	trace_dma_map_page(dev, phys, addr, size, dir, attrs);
> +	debug_dma_map_phys(dev, phys, size, dir, addr, attrs);
>   
>   	return addr;
>   }
> @@ -194,7 +194,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
>   	else
>   		ops->unmap_page(dev, addr, size, dir, attrs);
>   	trace_dma_unmap_page(dev, addr, size, dir, attrs);
> -	debug_dma_unmap_page(dev, addr, size, dir);
> +	debug_dma_unmap_phys(dev, addr, size, dir);
>   }
>   EXPORT_SYMBOL(dma_unmap_page_attrs);
>   
> @@ -712,7 +712,8 @@ struct page *dma_alloc_pages(struct device *dev, size_t size,
>   	if (page) {
>   		trace_dma_alloc_pages(dev, page_to_virt(page), *dma_handle,
>   				      size, dir, gfp, 0);
> -		debug_dma_map_page(dev, page, 0, size, dir, *dma_handle, 0);
> +		debug_dma_map_phys(dev, page_to_phys(page), size, dir,
> +				   *dma_handle, 0);
>   	} else {
>   		trace_dma_alloc_pages(dev, NULL, 0, size, dir, gfp, 0);
>   	}
> @@ -738,7 +739,7 @@ void dma_free_pages(struct device *dev, size_t size, struct page *page,
>   		dma_addr_t dma_handle, enum dma_data_direction dir)
>   {
>   	trace_dma_free_pages(dev, page_to_virt(page), dma_handle, size, dir, 0);
> -	debug_dma_unmap_page(dev, dma_handle, size, dir);
> +	debug_dma_unmap_phys(dev, dma_handle, size, dir);
>   	__dma_free_pages(dev, size, page, dma_handle, dir);
>   }
>   EXPORT_SYMBOL_GPL(dma_free_pages);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 16:51:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 16:51:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112185.1460575 (Exim 4.92)
	(envelope-from )
	id 1uuZeQ-0000lu-TM; Fri, 05 Sep 2025 16:51:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112185.1460575; Fri, 05 Sep 2025 16: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 1uuZeQ-0000ln-QE; Fri, 05 Sep 2025 16:51:02 +0000
Received: by outflank-mailman (input) for mailman id 1112185;
 Fri, 05 Sep 2025 16: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 1uuZeP-0000be-BT
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:51: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 7f84f444-8a78-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 18:51: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 1C43F43A6C;
 Fri,  5 Sep 2025 16:50:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 291F0C4CEF1;
 Fri,  5 Sep 2025 16:50: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: 7f84f444-8a78-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757091058;
	bh=ed7tjh37WUsiWKbFsXU4Fz4LWP9OYuSxI0T6PtehL5I=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Hkj6jwvLxKggBm5BaYRmXNHFJSTzS4j//v2v297B9zbvAb6zaXk3ye+d7kJpzYt+i
	 pVjGPf+glYmCMY8ZXxKqFzfErZn5vYpuxstgE5z7K6bWjnB52Zu2pWhWX8YpcE0TZ3
	 wqpQ/atJ+vA0oyDRUVNRdo8I0NXlm4wfllQDaEaUhi9U9aEo4xqnHh2mcEuBjTyxog
	 A1t4vtOjJmcxMXWsrEs0iDeQq9drkmd4Whjs7cSHTOvVKn09EIzsL7m+VCMmXlxsZx
	 LFVA53bS5HpTQKBuuE67ybcB5j6vm/3A//si20RgKUC4Z6Fe/u+7Z/FKOCjsOXLxSF
	 Mdr++eBA7BRQw==
Date: Fri, 5 Sep 2025 19:50:51 +0300
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	Keith Busch , linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 07/16] dma-mapping: convert dma_direct_*map_page to be
 phys_addr_t based
Message-ID: <20250905165051.GA25881@unreal>
References: 
 
 <6b2f4cb436c98d6342db69e965a5621707b9711f.1756822782.git.leon@kernel.org>
 <087e7f3d-1e0d-4efe-822f-72d16d161a60@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <087e7f3d-1e0d-4efe-822f-72d16d161a60@samsung.com>

On Fri, Sep 05, 2025 at 06:21:44PM +0200, Marek Szyprowski wrote:
> On 02.09.2025 16:48, Leon Romanovsky wrote:
> > From: Leon Romanovsky 
> >
> > Convert the DMA direct mapping functions to accept physical addresses
> > directly instead of page+offset parameters. The functions were already
> > operating on physical addresses internally, so this change eliminates
> > the redundant page-to-physical conversion at the API boundary.
> >
> > The functions dma_direct_map_page() and dma_direct_unmap_page() are
> > renamed to dma_direct_map_phys() and dma_direct_unmap_phys() respectively,
> > with their calling convention changed from (struct page *page,
> > unsigned long offset) to (phys_addr_t phys).
> >
> > Architecture-specific functions arch_dma_map_page_direct() and
> > arch_dma_unmap_page_direct() are similarly renamed to
> > arch_dma_map_phys_direct() and arch_dma_unmap_phys_direct().
> >
> > The is_pci_p2pdma_page() checks are replaced with DMA_ATTR_MMIO checks
> > to allow integration with dma_direct_map_resource and dma_direct_map_phys()
> > is extended to support MMIO path either.
> >
> > Reviewed-by: Jason Gunthorpe 
> > Signed-off-by: Leon Romanovsky 
> > ---
> >   arch/powerpc/kernel/dma-iommu.c |  4 +--
> >   include/linux/dma-map-ops.h     |  8 ++---
> >   kernel/dma/direct.c             |  6 ++--
> >   kernel/dma/direct.h             | 57 +++++++++++++++++++++------------
> >   kernel/dma/mapping.c            |  8 ++---
> >   5 files changed, 49 insertions(+), 34 deletions(-)

<...>

> > -	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
> > -	    dma_kmalloc_needs_bounce(dev, size, dir)) {
> > -		if (is_pci_p2pdma_page(page))
> > -			return DMA_MAPPING_ERROR;
> > -		if (is_swiotlb_active(dev))
> > -			return swiotlb_map(dev, phys, size, dir, attrs);
> > -
> > -		dev_WARN_ONCE(dev, 1,
> > -			     "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
> > -			     &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
> > -		return DMA_MAPPING_ERROR;
> > +	if (attrs & DMA_ATTR_MMIO) {
> > +		dma_addr = phys;
> > +		if (unlikely(dma_capable(dev, dma_addr, size, false)))
> 
> "!dma_capable(dev, dma_addr, size, false)" in the above line.
> 
> It took me a while to find this after noticing that this patchset breaks booting some of me test systems.

Ohh, sorry, I overlooked it. Do you expect from me v6?

Thanks


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 16:55:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 16:55:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112197.1460585 (Exim 4.92)
	(envelope-from )
	id 1uuZiY-0001NI-DJ; Fri, 05 Sep 2025 16:55:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112197.1460585; Fri, 05 Sep 2025 16:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuZiY-0001NB-A2; Fri, 05 Sep 2025 16:55:18 +0000
Received: by outflank-mailman (input) for mailman id 1112197;
 Fri, 05 Sep 2025 16:55: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 1uuZiV-0001N3-VK
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 16:55:16 +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 14eb23e2-8a79-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 18:55:10 +0200 (CEST)
Received: from DS7PR03CA0303.namprd03.prod.outlook.com (2603:10b6:8:2b::19) by
 DS2PR12MB9709.namprd12.prod.outlook.com (2603:10b6:8:276::18) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.19; Fri, 5 Sep 2025 16:55:04 +0000
Received: from DS2PEPF00003445.namprd04.prod.outlook.com
 (2603:10b6:8:2b:cafe::e1) by DS7PR03CA0303.outlook.office365.com
 (2603:10b6:8:2b::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.19 via Frontend Transport; Fri,
 5 Sep 2025 16:55:04 +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.9094.14 via Frontend Transport; Fri, 5 Sep 2025 16:55:04 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 5 Sep
 2025 11:53:17 -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, 5 Sep
 2025 11:53:16 -0500
Received: from drvdevbldsrv2.amd.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; Fri, 5 Sep 2025 11:53: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: 14eb23e2-8a79-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xvZRFe36vrYyAPLOeonfYj77oebZ/hCcdMV5taaPptgQdcoR2Ryqh+Y3Wr2M/VjEA8od6QzjrA+b4Ym9KebyPF13gU2ebJFGp/GOPwdMSuLTLkGzmkwjODZSM/6lQ50qMlKtmJKAf2nOQWBhoZlZ25cm+NEk4YYiDqHO/KoKGvkpm/vqgbI8W4BJjHsbMifGoDTMXcpyKxb28jz7SVa1gTpYHoq1IwEYYJ5z0PF8MaWRFkJVSUH2vy3m/RJCTLmjWMniIRsE42U210k16Ark/mSLtPcMzdSl7P9LBvtiHgRig7INMx4fwF6pjRt/BCmF+5Hbje841OPLVH6u7BKTCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sZ4DTlzlIKd/12RtkgLudAGUzA4uI4t07+Tf0C6Wtno=;
 b=O1sXlC0DxiHgaayd9JFn8pLgoy/t5iThwtuynItmsr0x9szOLZUTFStAt1Hfh7WZxk7ynV1Z49bopX5wiX7uvF5bJQZTCUcTsBOcb7ihQrqjvbiChE9hlCjqSidRh1PwQ91p9qeO7cLMUhco6hr+sdfO9ZEW7SWe/4ucNb3PFcGjWqVYtXYY6/WfOaCxHRV4wFfTPIP4WcA7vczw0SD/5oZYJo0onxBiWr46HFDV4+m2XC+Q/y+Uuxq8PsS4OQm+1eaSjEoAMJfwNSj966EeCAq3VJIbAzIdhB/JY4eTqfwth4QgGrwJp/1AQjtxVZ30pOy3quK0f8OGDxEWeaHvFw==
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=sZ4DTlzlIKd/12RtkgLudAGUzA4uI4t07+Tf0C6Wtno=;
 b=ORJh2Xx8egdNWe3z+oIDTRJRCqCoFlA9BFoNft8x2oV41CHcuwVhM+VLzzCqp7ITMOEeF38//jYYfhFnvH+41rIrPe/eAOVzXkrYBSvrhMdJYOjpMjjSw8oJEVj6w+/pelJXiPw7dSzLWpYV7I2Ma91FDgxmuYGQpzhHGZ7xkwk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: Soham Dandapat 
To: 
CC: , Soham Dandapat , "Jan
 Beulich" , Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Soham Dandapat
	
Subject: [PATCH] x86/mcheck: allow varying bank counts per CPU
Date: Fri, 5 Sep 2025 22:22:12 +0530
Message-ID: <20250905165212.96843-1-Soham.Dandapat@amd.com>
X-Mailer: git-send-email 2.17.1
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF00003445:EE_|DS2PR12MB9709:EE_
X-MS-Office365-Filtering-Correlation-Id: ed350cef-1cf9-4239-4c45-08ddec9cf5e5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|30052699003|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?ToCT4UYXx0Vqkx7TanqLWEjKJOZxjYEdpvFZAMNPyJ02VrGpRcSCMqxzM/YQ?=
 =?us-ascii?Q?hoDGlN+eroLFgyC4Py0MK17Y7clU0bPqiN77giRXm6Ovpy77D1ix+cx0u9bh?=
 =?us-ascii?Q?pXKwzDDZYPuLfh80+OtG2CLG3yvaDwsCzoY8RVr1IbMZ0QWLGYSkLvVop2XS?=
 =?us-ascii?Q?efLEjVBFyQp+URveRUWyY3g/O4Clc4x+uUcdtZPGWb/2e9+QAS644pjgeePK?=
 =?us-ascii?Q?fxijk9SHgiTpUP4R2byvs5bxUvjdpcuz2MqFdompJhAcPLV1lXxIFePATZzp?=
 =?us-ascii?Q?XHzvYIRi48g24Tr4gcgfm+mqb6SFUDQ20TBJuSDyHzEAfHbUfPSX3D8Tp1OH?=
 =?us-ascii?Q?uv3Bh1HbdPLE/Ve0XMrfe6i6jKiQt+0Js79+I3x9OVFu5PKnbsvSK8xdyfth?=
 =?us-ascii?Q?OPdLlBRfFs5AiwlRtksmfzobz3wJ/SYbAbC+Vlv0astYGoWlLhEDDKfMt34z?=
 =?us-ascii?Q?Kzj0wECEGe7FNbl7jKEHFf1lULl4Ra5e+g5j1OzHR65BwV7Mwl3eq0iRnQvr?=
 =?us-ascii?Q?gSWPPCcKttQKO37b8BlQMFg5XFv/+u2HYLfweiHGut9Z44sMmhp4WpGDldCN?=
 =?us-ascii?Q?sOxSdo1l31JARHtzu7JRu3BHXGPXbsxeLRCHJzLby9VXO2UANTk6MaaQ66ZJ?=
 =?us-ascii?Q?JwbGYL3wfoFtpEjxnUeNjR/q25JW9w3JYV6NO5cLTLU/R5A9sb3k+YXa18HL?=
 =?us-ascii?Q?Ulyk5a4awoOsJemD9zLXZyoeDDuTZZKQXhpXPE30xGDw7sbnYHhtmpyrpe+U?=
 =?us-ascii?Q?lEvwIwuv+ibM/ltBaWlxVtgy18wF+IoLS9/aAX+H55a+8rA5g/zGJhZ2ltYr?=
 =?us-ascii?Q?nzKJCs/AinJvVWxJXceD+n+Ops6UisbKDMcV2cVqFTQp8gca2VvQiodJXp7J?=
 =?us-ascii?Q?GWa+mHnQlcJBKqBP0/GjNB+FsFz3clEhCquIyqQ7xPfgE+eXa6Z6rz4BkOXn?=
 =?us-ascii?Q?I3PXE5m9m9hNmecw4DyZQeDvsSmWQEZt2nyk80Gn7iWwuLBJm3eEmhoMu6y4?=
 =?us-ascii?Q?BKMA+vBbM4F4iTji37y/RIkolBN8E1/sdnVt+GpLOBZDLE9oexyuzfv4F4cV?=
 =?us-ascii?Q?pKjwDC9H7UX3NU5QVJ7fMsFTch+juEZwdhqrRvrn/HKMNUWXlXj0y+K0HD1B?=
 =?us-ascii?Q?hgzVmOZTCkXxivz9AbCydi5Nj5RuyL/CUJweC9rKr0NsoF33W/UohYymww2U?=
 =?us-ascii?Q?s6544AQWe6ectMQ/iRjMBxcphUs0aQESS2xshkEAGC88TmfA7m1EQucy35y4?=
 =?us-ascii?Q?4yuOlGnIJfoQXA2X3L8Qtu+mjAVwv+Jxp2h5p0yP4HHUSObkgZth2c5Rtl+0?=
 =?us-ascii?Q?gAYhj9DAFO7t0uCBTov21FXlCT8Z10m8L8HNdYENDZ5nWROboaWcOY/lL4Qm?=
 =?us-ascii?Q?/ueDvNSJRwmBqnXHp8FEwogdGugbRs+hxol9/pOU+2kkOWizCiHdc+T00dq0?=
 =?us-ascii?Q?PtJC84nbQTsyhD2/LxBbE9DySfH5HBtuI5KQjdPVh0aOAvBPqpKRJUO+lkvK?=
 =?us-ascii?Q?cvVKdmh9SQBvVEMy6Iol/OErYemNGQ4cIIRW?=
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)(30052699003)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 16:55:04.0162
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ed350cef-1cf9-4239-4c45-08ddec9cf5e5
X-MS-Exchange-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: DS2PR12MB9709

In mca_cap_init function,the mcabanks_alloc allocates and
initializes an mca_banks structure for managing MCA banks,
setting up a bank map and storing the specified or default number
of banks.

After this we will call mcabanks_set(i, mca_allbanks);
The mcabanks_set function sets a specific bit in the bank_map of
an mca_banks structure, provided the structure, its bank_map, and
the bit index are valid.

At the end, we will call
mcabanks_free(xchg(&mca_allbanks, all));
This function is thread safe and does below:
   1. Atomically exchanges the value of "mca_allbanks" with "all"
   2. Returns the old value that was previously in "mca_allbanks"
So, when we will call mcabanks_free , that will free the memory.

The problem is that mcabanks_set(i, mca_allbanks) function is updating
mca_allbanks which will be freed via mcabanks_free later. This means
new mca_allbanks instance("all") will never get chance to update
it's bank_map.

Due to this when we will collect log from mcheck_mca_logout function ,
the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
and MCA logs will not be collected for any bank.

The fix is to solve this problem.

Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU")
Signed-off-by: Soham Dandapat 
---
 xen/arch/x86/cpu/mcheck/mce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 9028ccde54..84238cd0ef 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -663,7 +663,7 @@ static int mca_cap_init(void)
         if ( !all )
             return -ENOMEM;
         for ( i = 0; i < nr; i++ )
-            mcabanks_set(i, mca_allbanks);
+            mcabanks_set(i, all);
         mcabanks_free(xchg(&mca_allbanks, all));
     }
 
-- 
2.17.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 17:02:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 17:02:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112221.1460596 (Exim 4.92)
	(envelope-from )
	id 1uuZpP-0003Hf-8M; Fri, 05 Sep 2025 17:02:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112221.1460596; Fri, 05 Sep 2025 17: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 1uuZpP-0003HY-4R; Fri, 05 Sep 2025 17:02:23 +0000
Received: by outflank-mailman (input) for mailman id 1112221;
 Fri, 05 Sep 2025 17:02: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 1uuZpO-0003HS-3z
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 17:02:22 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20611.outbound.protection.outlook.com
 [2a01:111:f403:2414::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1452846f-8a7a-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 19:02:19 +0200 (CEST)
Received: from BN1PR12CA0022.namprd12.prod.outlook.com (2603:10b6:408:e1::27)
 by DS0PR12MB8478.namprd12.prod.outlook.com (2603:10b6:8:15a::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 5 Sep
 2025 17:02:16 +0000
Received: from BN3PEPF0000B373.namprd21.prod.outlook.com
 (2603:10b6:408:e1:cafe::1a) by BN1PR12CA0022.outlook.office365.com
 (2603:10b6:408:e1::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.17 via Frontend Transport; Fri,
 5 Sep 2025 17:02:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B373.mail.protection.outlook.com (10.167.243.170) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.9137.0 via Frontend Transport; Fri, 5 Sep 2025 17:02:15 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 5 Sep
 2025 12:02:14 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1748.10; Fri, 5 Sep
 2025 10:02:14 -0700
Received: from [172.31.134.167] (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, 5 Sep 2025 12:02: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: 1452846f-8a7a-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lgp0f5NTj/clHJ/iDK9xGIstouy1suiZl1L41kWcB9smXn7tlKPH+EBr0+a7ykcxrOjpkCU65sh/4+S3B+vDsCW/ZU61dBSS+C+sfEbAjlRA3UHN6WpagAsWHk0hDR/FNGvVPA43HQMWdR1LtqIJRAW35NKQeUmjLJ+7jwIeIEp3YyI1PPDCEbmYrd65YfXyJLAkk8ToyAZydF6N8UUU+YaEUSNfqx0LmutV8kqgYD97Asg81W0wH0hnLuRuLK2cjJdKSdTVREGWnrjFHbsqIPl5SlGAouzlOhWAwIXPRtxQ82jhUn760D00wXm2Ys7O0a5PcBWAL3vRdvxCV5vFAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=49cIEEYcoroeeY4iXCoKC2U9YVC/+LfllgFiGaDkGBY=;
 b=iAnqUNe9pBytNoJqn7NdodrsgY86dy5NHM3FTGjDoiYIZK16SWdBw7eSVA7v85MGmOPbgcBk2uZozunBeTGoCtSdZXV4s//FHDbIZg0c3zHo6YPsu0YNMy9WfX+zvAU81Fpxzu4lmPrqClOS1Cwu4e0MnNpWe/7Onpqy5oSxqs6GJ09gbTib22mwSWleeAO21GXwkF+gV4IGTGTYSmafJGuinu+IT/1iAn/LUYDNryDD0CYgDjAMdT7hvTbEcdcT0FWKxPxX0ESwjLzDTL0JiTX80R7GILFly9BqMgGZduGVZBOCir9uK4oSu4nIUC5EziIJ9G08AQcuDHlge/Hg/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=49cIEEYcoroeeY4iXCoKC2U9YVC/+LfllgFiGaDkGBY=;
 b=aFf0EqFem0PQbKIBlPsjfrTXMltUUKpdQOKDX0dTi/tc4u9lCR/vbbrfsEDnmCuAjXiun+BmJRcLG3ikSimg7Ow3DxjQp9pBzlJDM6pJEr0JVFW41v9RzMxcFMMddFQtrrrHJpCXMsl8uCRW3gBWQ4SAhJp1JGmkgDtLbf/k2aU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: <32f89ab8-9742-4bc8-a5ef-848b66e788b2@amd.com>
Date: Fri, 5 Sep 2025 13:02:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/mcheck: allow varying bank counts per CPU
To: Soham Dandapat , 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250905165212.96843-1-Soham.Dandapat@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250905165212.96843-1-Soham.Dandapat@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B373:EE_|DS0PR12MB8478:EE_
X-MS-Office365-Filtering-Correlation-Id: 779b2aec-0cbd-4941-2dd3-08ddec9df6d1
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?V2lHaDBITThnOVNuM29iRktKZUh1TEl0SlJGNVJXNVR4Y1dwVUEyd3BIbXRo?=
 =?utf-8?B?bEZTY2VCaCtQVlhFekpSRmNac1VBZDFtSUUrQnNLcitJSmx5SkE0d3hpelpH?=
 =?utf-8?B?Qkl4TmNzYVd3VFk3ZEhzM0lUd294Y0ZrcytEVmVOWmhHYWRzaVFVby9aT2k4?=
 =?utf-8?B?U3RWNUxsaXFyQTBudkhaUURwckQrVlgyVERheStzRFovQjk0YjYwZU41VHM2?=
 =?utf-8?B?MFJpOU9Pc2VFNnBnVWtoeW1QOGU0RmFwV2R6YUY4a244cnkraG5XMTVTcWRn?=
 =?utf-8?B?RzU3d0VTWFByOFhZbGV6UDRITTRpVjVTOHIva1kxS0Q1R2ZKbjRKZWhYN3Vw?=
 =?utf-8?B?WEs0elZIWGxVL1BrbDlmL2lWVy9GVjRhOGx2UkFTT2xwb3Rmc09wZWZPdmJV?=
 =?utf-8?B?RlB1cXV4djI4MjBYNVo1Qnp5eGZITFZzTVd0NTB4a1hBWk5Uc0YyN3RKWGp4?=
 =?utf-8?B?SGo0RXpIN0xQUHdRUXk5RTlwSTl4Q1FncEthcWZWRjlLUVczajg0VEVmblJQ?=
 =?utf-8?B?S3laZytsRVhndEV2MFNzWXVZR05NUmIyRzVzcTEzODFoYTVNZiszSTdkT0tV?=
 =?utf-8?B?TWV6U2lyUnFWcTFrblZhUkJBanV2a2ErQ0s2NFp5K2tFVEtHcTZVUGJERFJx?=
 =?utf-8?B?Ykp0Wi82dW94V1cvbXRaZk1qWGFIZ3JsOVRNQTloWkNXS2tOL3FheXBsWW5M?=
 =?utf-8?B?SWs0bjJYOTFLYkMzdlRzeDVqaXpIQUhZMHZ5dVQzSnoreiswSUc0LzJXVW54?=
 =?utf-8?B?a1IxdWZYWC9XYUFidmJJTCtXaHJiWHFMbm8zY3dzWWxiakVyNERWWnFBTThM?=
 =?utf-8?B?RkhneFBwVzVWeGZtME5QOHpoQVNlK1gzWlo3WDhSVWt5bkpSNXdXazVnQ3l5?=
 =?utf-8?B?OHcxeDdiaFpZWSthUVVGMjRWd2tjb0I2TjRWdkR1OVlRREZraHVPUTc5cllO?=
 =?utf-8?B?YloyY2JRelNjdm9vZkVKQ3RsUGMxRmJhZzRqb3Q5WmdRdjMyRUdySVlDS2ts?=
 =?utf-8?B?RzFuaTlMU3E3ZFBmbEVrVGFpZlliU3ZqMldBK2tYb3NyaCtwK2NYSHpveDBU?=
 =?utf-8?B?djJWK1VRcGhNNW04WUFSem1CZmtYZmJqWHVPeDhKaHF6WjJISTcvc3VwY0Ro?=
 =?utf-8?B?dmVEVHQ1T3JSN2ZlUXU1ODRIb1Y4OTRUZXc3UTc1OG9XZFhDREVVakpDQlgx?=
 =?utf-8?B?L1U1QSt1K0RKOUFaSW1menZZdXQ2eWJyR3FMMlhUYW52WVpPWEF0MmhsRzVo?=
 =?utf-8?B?VWhCVXd2YWJUT3Q3anIyQkpaR3o2T0U0cGhYVUxoczlWU0F2cUUzYkMyYVl0?=
 =?utf-8?B?Rk1DeFNOTm9oaExFU3dLeXJxdW4xRFRZdDZkM2hJZFhsRnlETDVMY0d5SFpJ?=
 =?utf-8?B?Y0xRczl0dzFLUEhoYy80b2sxcDhESitNSkFKQUE4V1RhdTlsNE5GVW03dVZZ?=
 =?utf-8?B?ckNqUU1JbWtIQmRuRkhWdDJQUmRTb3VUSnhwRlRqNWVLcVp2a3U4REdNc09r?=
 =?utf-8?B?UUp3TGU2KzFVWWdVYjEyMjBDcWVMQ2Q4NFQ0a3pjZTFVYlJTUVZZR3V6eFk5?=
 =?utf-8?B?akZhaUdxVTF6WVp5NTZCOU9aVWEzcFg5Nm9CSUJpdkFlWGxraGtMQnRqS21T?=
 =?utf-8?B?bUZCUk1LSk54Qjd1d1VWL0ExMkt2RFBUYm5qdjg0WDd5VEJIdm9zOGIyMGhs?=
 =?utf-8?B?enBJVC8yVngvbEw2WlB2L1ZLeGp5anpGcDlVTTFYci9WSUhSamgxczg4MlBj?=
 =?utf-8?B?Ym5ENU03MjEzSVMwOGo0NTZ4LzhxMG5vREFrYWNIaWYxQUNpMmEwTFNvYWhV?=
 =?utf-8?B?V3diVGJKbXFaZlhmSU9uVzVjczEvb3F4T25ldTdKdlFTejd4dm5vZFBYcnZG?=
 =?utf-8?B?YlcydldXMi9zazNPY3lrQmdhK1dvUTNLWi90VG02c1pzemNHWmpJZ1NGUm1r?=
 =?utf-8?B?OUMxR1k5bUJWOURXUGpGWUJPWmI0eDNoU3E2NkZoWm4yY0t3UGVpSlZHbXpE?=
 =?utf-8?Q?3jmKzz7m5Q8lhX/nCBPrMfTR7mfM+w=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:;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 Sep 2025 17:02:15.0986
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 779b2aec-0cbd-4941-2dd3-08ddec9df6d1
X-MS-Exchange-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:
	BN3PEPF0000B373.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8478



On 2025-09-05 12:52, Soham Dandapat wrote:
> In mca_cap_init function,the mcabanks_alloc allocates and
> initializes an mca_banks structure for managing MCA banks,
> setting up a bank map and storing the specified or default number
> of banks.
> 
> After this we will call mcabanks_set(i, mca_allbanks);
> The mcabanks_set function sets a specific bit in the bank_map of
> an mca_banks structure, provided the structure, its bank_map, and
> the bit index are valid.
> 
> At the end, we will call
> mcabanks_free(xchg(&mca_allbanks, all));
> This function is thread safe and does below:
>     1. Atomically exchanges the value of "mca_allbanks" with "all"
>     2. Returns the old value that was previously in "mca_allbanks"
> So, when we will call mcabanks_free , that will free the memory.
> 
> The problem is that mcabanks_set(i, mca_allbanks) function is updating
> mca_allbanks which will be freed via mcabanks_free later. This means
> new mca_allbanks instance("all") will never get chance to update
> it's bank_map.
> 
> Due to this when we will collect log from mcheck_mca_logout function ,
> the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
> and MCA logs will not be collected for any bank.
> 
> The fix is to solve this problem.
> 
> Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU")
> Signed-off-by: Soham Dandapat 

Reviewed-by: Jason Andryuk 

Maybe the patch subject should be "x86/mcheck: Fix mca bank 
initialization" to differentiate from the Fixes commit?

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 17:39:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 17:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112233.1460605 (Exim 4.92)
	(envelope-from )
	id 1uuaOw-0007UR-TS; Fri, 05 Sep 2025 17:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112233.1460605; Fri, 05 Sep 2025 17: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 1uuaOw-0007UK-Pr; Fri, 05 Sep 2025 17:39:06 +0000
Received: by outflank-mailman (input) for mailman id 1112233;
 Fri, 05 Sep 2025 17: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 1uuaOv-0007UE-9R
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 17:39:05 +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 32c066b0-8a7f-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 19:38:57 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 7274460218;
 Fri,  5 Sep 2025 17:38:55 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AA22C4CEF1;
 Fri,  5 Sep 2025 17: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: 32c066b0-8a7f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757093935;
	bh=RwgI6iOiiGGaVq5ryV0ZWpJOK9YgvvrfbQAyHKlknns=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Ld3/+CXFzo5ZlgBaEJAAJ7n8ftGIf1vPmYVyQ1Q0lHbk30C+f/zGBCjYcCjqKGMkP
	 ws0j93C+g7AZ/Qe51tbRHlFMkxmG8V2HiTKDDiIWpTC2x67XRe77cJRX2O/0Emokq3
	 empFPEdzGq6Yu1WtRJ7c3H3VguQh/C6NxRnBxnFK+dgTB/PoKfshLNhSffqo96FEeK
	 5gqAp6J/XAgqm8C64dBl5bC3cJKCuXlyMRuLkxNADtvKhMqMkGQ2Y7tGhP772p1Ynd
	 b5DRxNZc712LsAvfWwUYrOIy6AN49OJHPTqpk5krnaWlYW3AAU/MPcrMbpxJdoJz6O
	 DAfHVEkZTDmug==
Date: Fri, 5 Sep 2025 20:38:50 +0300
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	iommu@lists.linux.dev, Jason Wang ,
	Jens Axboe , Joerg Roedel ,
	Jonathan Corbet , Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250905173850.GB25881@unreal>
References: 
 
 <20250829131625.GK9469@nvidia.com>
 <7557f31e-1504-4f62-b00b-70e25bb793cb@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7557f31e-1504-4f62-b00b-70e25bb793cb@samsung.com>

On Fri, Sep 05, 2025 at 06:20:51PM +0200, Marek Szyprowski wrote:
> On 29.08.2025 15:16, Jason Gunthorpe wrote:
> > On Tue, Aug 19, 2025 at 08:36:44PM +0300, Leon Romanovsky wrote:
> >
> >> This series does the core code and modern flows. A followup series
> >> will give the same treatment to the legacy dma_ops implementation.
> > I took a quick check over this to see that it is sane.  I think using
> > phys is an improvement for most of the dma_ops implemenations.
> >
> >    arch/sparc/kernel/pci_sun4v.c
> >    arch/sparc/kernel/iommu.c
> >      Uses __pa to get phys from the page, never touches page
> >
> >    arch/alpha/kernel/pci_iommu.c
> >    arch/sparc/mm/io-unit.c
> >    drivers/parisc/ccio-dma.c
> >    drivers/parisc/sba_iommu.c
> >      Does page_addres() and later does __pa on it. Doesn't touch struct page
> >
> >    arch/x86/kernel/amd_gart_64.c
> >    drivers/xen/swiotlb-xen.c
> >    arch/mips/jazz/jazzdma.c
> >      Immediately does page_to_phys(), never touches struct page
> >
> >    drivers/vdpa/vdpa_user/vduse_dev.c
> >      Does page_to_phys() to call iommu_map()
> >
> >    drivers/xen/grant-dma-ops.c
> >      Does page_to_pfn() and nothing else
> >
> >    arch/powerpc/platforms/ps3/system-bus.c
> >     This is a maze but I think it wants only phys and the virt is only
> >     used for debug prints.
> >
> > The above all never touch a KVA and just want a phys_addr_t.
> >
> > The below are touching the KVA somehow:
> >
> >    arch/sparc/mm/iommu.c
> >    arch/arm/mm/dma-mapping.c
> >      Uses page_address to cache flush, would be happy with phys_to_virt()
> >      and a PhysHighMem()
> >
> >    arch/powerpc/kernel/dma-iommu.c
> >    arch/powerpc/platforms/pseries/vio.c
> >     Uses iommu_map_page() which wants phys_to_virt(), doesn't touch
> >     struct page
> >
> >    arch/powerpc/platforms/pseries/ibmebus.c
> >      Returns phys_to_virt() as dma_addr_t.
> >
> > The two PPC ones are weird, I didn't figure out how that was working..
> >
> > It would be easy to make map_phys patches for about half of these, in
> > the first grouping. Doing so would also grant those arches
> > map_resource capability.
> >
> > Overall I didn't think there was any reduction in maintainability in
> > these places. Most are improvements eliminating code, and some are
> > just switching to phys_to_virt() from page_address(), which we could
> > further guard with DMA_ATTR_MMIO and a check for highmem.
> 
> Thanks for this summary.
> 
> However I would still like to get an answer for the simple question - 
> why all this work cannot be replaced by a simple use of dma_map_resource()?
> 
> I've checked the most advertised use case in 
> https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio 
> and I still don't see the reason why it cannot be based 
> ondma_map_resource() API? I'm aware of thelittle asymmetry of the 
> client calls is such case, indeed it is not preety, but this should work 
> even now:
> 
> phys = phys_vec[i].paddr;
> 
> if (is_mmio)
>   dma_map_resource(phys, len, ...);
> else
>   dma_map_page(phys_to_page(phys), offset_in_page(phys), ...);
> 
> What did I miss?

"Even now" can't work mainly because both of these interfaces don't
support p2p case (PCI_P2PDMA_MAP_BUS_ADDR).

It is unclear how to extend them without introducing new functions
and/or changing whole kernel. In PCI_P2PDMA_MAP_BUS_ADDR case, there
is no struct page, so dma_map_page() is unlikely to be possible to
extend and dma_map_resource() has no direct way to access PCI
bus_offset. In theory, it is doable, but will be layer violation as DMA
will need to rely on PCI layer for address calculations.

If we don't extend, in general case (for HMM, RDMA and NVMe) end result will be something like that:
if (...PCI_P2PDMA_MAP_BUS_ADDR)
  pci_p2pdma_bus_addr_map
else if (mmio)
  dma_map_resource
else              <- this case is not applicable to VFIO-DMABUF
  dma_map_page

In case, we will somehow extend these functions to support it, we will
lose very important optimization where we are performing one IOTLB
sync for whole DMABUF region == dma_iova_state, and I was told that
it is very large region.

  103         for (i = 0; i < priv->nr_ranges; i++) {
  <...>
  107                 } else if (dma_use_iova(state)) {
  108                         ret = dma_iova_link(attachment->dev, state,
  109                                             phys_vec[i].paddr, 0,
  110                                             phys_vec[i].len, dir, attrs);
  111                         if (ret)
  112                                 goto err_unmap_dma;
  113
  114                         mapped_len += phys_vec[i].len;
  <...>
  132         }
  133
  134         if (state && dma_use_iova(state)) {
  135                 WARN_ON_ONCE(mapped_len != priv->size);
  136                 ret = dma_iova_sync(attachment->dev, state, 0, mapped_len);

> 
> I'm notagainst this rework, but I would really like to know the 
> rationale. I know that the 2-step dma-mapping API also use phys 
> addresses and this is the same direction.

This series is continuation of 2-step dma-mapping API. The plan to
provide dma_map_phys() was from the beginning.

Thanks


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 17:43:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 17:43:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112244.1460614 (Exim 4.92)
	(envelope-from )
	id 1uuaTL-0000jR-BU; Fri, 05 Sep 2025 17:43:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112244.1460614; Fri, 05 Sep 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 1uuaTL-0000jK-8z; Fri, 05 Sep 2025 17:43:39 +0000
Received: by outflank-mailman (input) for mailman id 1112244;
 Fri, 05 Sep 2025 17:43:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uuaTJ-0000jE-EM
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 17:43:37 +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 d627d7c6-8a7f-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 19:43:31 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by SJ1PR12MB6265.namprd12.prod.outlook.com (2603:10b6:a03:458::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 5 Sep
 2025 17:43:26 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9094.017; Fri, 5 Sep 2025
 17:43: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: d627d7c6-8a7f-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rmQBnyGgLjdP99D8mr1ZZogFkvBu1GxixVCgMdOsUWxb7Y7dqG5e+koq3mTeMPTToZgitqTT6e1UglS7EbP4Rw9TUv9UnB90iMWx0RLnpSdBkLknwifgJ1DNtR9E933WXvlc/V5xJ7OAvMdnk3f6v2JVKVglxVOY34+bvJvnTI0LsHB0nn6Z9EfrwT3k7Y7OHjApHh14YlyE9fO2PIn2zBJL8aZxaNf+CWSu4cVMEeF+1ot5e3511WnUG42G185AlKfOy+r4WoEcWrFAUgHChpIOAwdiVWsWUj5VEvvYEV0MM84KpdabrtEiHLn72sLP3bN4pBYFNb6p4ozf9FEN0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vILuWYAAHp1MhRoYT7hppsLaBLiTCuQw0wAnrfxfM18=;
 b=VxD8f7g/AHWTj4kRyxL+bwM6OhT6Mq+UQdCsG9L/NC1IDywcIcLByLEBSsh0gzCeBPbtpAqcrmM701hHjqznNoZxyMnwKdhXdxnPJsQ3TkGH6L4u/rL7RUVTralSADDnDRv6iZA3Ty5pC2mR4nI3fosiRGUJmkno6cs8lhx0UUFjpR0jcfPizdAQmWDSLIwdg7qsukogILm7siHujIfBUzcDUkUFMk9jIipTBRQWiCJxofamNzt7GQUab8VyMViLupZfb2UcHLtRyc9bPMZegqAD71c+Vf6SJkBy+l4OBEyMOJfDCflXzkRURoji3f7Xebtb+0vvCTtB6NyV2ALP7w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vILuWYAAHp1MhRoYT7hppsLaBLiTCuQw0wAnrfxfM18=;
 b=hep32/RkEYW+ok3gUCMJe4RtW6SgpBDdBVE8CHVUTzQCa5m5v/1yx87NmAhrs1K5hhzKD4b52iUL0I88kmVtUEGPWQUl5/akQe4PFC7jj3GgLtelFz6U2KmwrI4ZvIR0yKtLmIuuc1rZIUOWnuNC53CKj/bM1Fyxk+7EH30TgVpz9Fq9/B/rTeRXDKZOnoDCwHfDs9JjhednG2648vJ8op2lBrZ5h/IUJa6jNMf5IRJOTUzflxRbmiCBALaZ/RYo7DNQOvrzShcEl0WZ6wagOzPxGkjK0M8fl61w1MvbhqX4sAYaY6Qkwt3tRDp0Z6yA4hTPuOTJy3IRT7aQfbAb9w==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Fri, 5 Sep 2025 14:43:24 -0300
From: Jason Gunthorpe 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	iommu@lists.linux.dev, Jason Wang ,
	Jens Axboe , Joerg Roedel ,
	Jonathan Corbet , Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250905174324.GI616306@nvidia.com>
References: 
 
 <20250829131625.GK9469@nvidia.com>
 <7557f31e-1504-4f62-b00b-70e25bb793cb@samsung.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7557f31e-1504-4f62-b00b-70e25bb793cb@samsung.com>
X-ClientProxiedBy: YT4P288CA0088.CANP288.PROD.OUTLOOK.COM
 (2603:10b6:b01:d0::21) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|SJ1PR12MB6265:EE_
X-MS-Office365-Filtering-Correlation-Id: 170388cd-19af-4e89-c8e6-08ddeca3b7e5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dnhUVWFhVWdmcThFZmlyQS96TlhJNjEzcXhwUm5sU1lSSFcxdkYwUWhkNG9P?=
 =?utf-8?B?Y3lobithTmZ2SzdianR2NEQ5Sy9IYUMzclFBeExOekUxV3poRXExMEtSc3Ro?=
 =?utf-8?B?bFAvWUNqRUhyaUxmQ1BYM2o5dDYrMFpUeUl0N0p0WXppVm9LZ3BzM2RLQnBC?=
 =?utf-8?B?ZFE5U1QwMFg5Wmd4TUs5UE5sRnNubUFSdHZsVGJQQnRxT2I1cDM1MkN4Yy8v?=
 =?utf-8?B?UXRKVHRWd2RyN3Z3QStUU1RUSjlQR2U3aFN2S0tnSk9EOWxpZHpsaHRyMHpZ?=
 =?utf-8?B?emg4TUdSdVRkMitYelIvMmlUY3daV0RmRXFCbFpRSGFHeTA4a1UvQzBPSElF?=
 =?utf-8?B?Ynh5NHRjQ1FmZlZyOXhueUR4Wml2aEloNUZpRnF3bytpRWJPNEZzeEVZK3Rl?=
 =?utf-8?B?dERBdHZMWjFzak9xNklUQmRYaWlFR1pQMW81Wkw4VEZWcThXQ2tkOFFKeFZD?=
 =?utf-8?B?VzhsR2hJSDBCMy9qQnk0YXMxZ092Q0tvZ3dhWW9XVnZkZHpNTnBvL3BmMVJ5?=
 =?utf-8?B?eTBVVHREU1dwOGhieWNGQUNFa0pCRjJCS21KTENxb1JsQ0kzNzM2TWJkV0xH?=
 =?utf-8?B?eUVuazZjMGc1Zk9CVlRKS1IrQjBhSG9CN1R3d3pGbjNUR1p1Y1RSQmpiTkEx?=
 =?utf-8?B?RENUTkI5OU1zS0IwaFlJaFRHNk84UWJacGhNNXowQ3pQR1oxYzhhTFRmZXov?=
 =?utf-8?B?YmFTUGRqbS82MEYyanI0eW9ydllVREJHL3RsU040VGxQMFpsdXNYN0czRVll?=
 =?utf-8?B?RXNacE1BSDN4cXNLNnZneDh3RVBoM1lnaWI1RFhDMUpvK3cvVlltWTAwWVBP?=
 =?utf-8?B?ZjArMnoyQVMyTGxHVFFMajRRMTlwdy8zaDNFMmpvYVdXSGFzK3ppL0ZIY0xL?=
 =?utf-8?B?elRFdjdZNDZjUmwzTTNsamFNbUJPeU05cHBxV2l5c1Z3QU5VemhMaFZzOVV0?=
 =?utf-8?B?Z2JMckpUTXBRckJKZ1VQeHRHaFcrUFpnNUNOcG0rUVBHM01SOVNONEpzZktN?=
 =?utf-8?B?MEtMZ1FEc0ExWVNkTXB0V2wzc2gxQnZmUExidWU4TERrOEJqYWV0WnliamQ1?=
 =?utf-8?B?UDRFRnoyazMrUlNYN0hvK2dnc0QrVy9mNHJzN0xZKzBIY05wRlJBWWxzc2VO?=
 =?utf-8?B?NE9iNnhISHV1YWlGWHNNVUdmQm5CSjh1cmY1M2lKcXRDY0ljdWNLRXFldXdw?=
 =?utf-8?B?ME1yR2Jtd1dYclVHVzNocmtYQTZJNTF2b3VuQU1Tb2YwUnRFNmsvN0ZaWlJT?=
 =?utf-8?B?VmM5dURBT3hKYVM4K2xjQWFCdkZZUW9lRFhwV1pRblQ2V2tsZ01OTzdwSlhU?=
 =?utf-8?B?QXdlaW81bEZjYmNzaktzOFNJa3BSRWZ3STFQTzBJYVJjYWxDTHVFRlIrRFU0?=
 =?utf-8?B?NnBpTjhpZWZ5MFZSRjg3REJEd1I0TVM2c3RsZkFITjNKRDN6QWVKbUxhSS9R?=
 =?utf-8?B?K25aVGZCMDR5anZrQ0daa0VoTWJEYnV1SEx2YXdWMkw0QjFsMzNrWHMyS0VX?=
 =?utf-8?B?YkdaWUhhYVh4R2J2Mzc4eUVCMEVoRVE2S2F4am1KZ3lYUE1rM2N5Q3ZtNno3?=
 =?utf-8?B?WjhiTlNBZWlUUjVHSDc2c09XZ0NYeEczYkdmdWprQ3BNWDhtWkVQUHR1UWt3?=
 =?utf-8?B?UkgrZWg0clpiODVzK29QcXhPWWYyL1dRYjZtbzFVSllENUtoVklEdXR2NHU2?=
 =?utf-8?B?RTM0VEJXTndHVmVLVEJWQ1ZaT3dpREpTMWdHM0RrTDFZMlh2UmNPM0gzNVR2?=
 =?utf-8?B?ZU9aMy9kSi81RU95TUxtbzVJT08xYWxGUkRObGVCUTF0TWhjeFVYRWg5L1Zh?=
 =?utf-8?B?NS93YWN1MEk0RU02bkFXaVFWd05Wa2NMZS9BR1FsMk9nMHk5VlBBcy9zY0tM?=
 =?utf-8?B?M0F0Tmw0T3NxRlMzZzhVVjlLSXpiRU1JSk1XRVJtdC9rbWg3L3hFb1JOMHBp?=
 =?utf-8?Q?dAcJtJ7InDQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZDhuamJtcWlrMFVvN3U5bzl1djN2Q25JSm9lZnFIT0tReXVQQlhTQ0lTUnlj?=
 =?utf-8?B?VE5raGZ4cXExVmtCbEpTdTE2am1PYXJjTm8yY3N4VVhTcXJTdEFvcTh3ZGVT?=
 =?utf-8?B?WkFQSzYxSWJFMUhmZE5CQ0pFL0lwM2hUM21uU2xQcUtvcjJBSllJdmJlbitO?=
 =?utf-8?B?MEtNaG4zS043Y25oY0NDZnphWFJSUGVyOEwzOHRLRWFGSHNVdC8rQTIwS1Nx?=
 =?utf-8?B?MHduWi8vRVZDZlZVMGFwQzBjNi93SW5UcTVMa2FQb082V25BNFpKYXdaWDY3?=
 =?utf-8?B?L3UrYm80UkhBTk9GeG1WajFHckpkeUZ3VWY3MjF2d2dWcytJK0V4VWFNQmxh?=
 =?utf-8?B?UkdtV3JlZUU4NkNKajFDbnkyWExMTUJZaHA4c2tWbTZwOWpiWXBtcUpXbWRD?=
 =?utf-8?B?VkR4ckVmVFdPallkdEo5YjUxRDhaR0pxNzhPQlgxd2JFZnVobjhqbGE2Q3pP?=
 =?utf-8?B?aXpWTXV1NU5CL0lqSUdwb2FkdnBvQVN2dVRxNmlOY3BEaFhjZERXbVQwMVo3?=
 =?utf-8?B?b3UyRFlnZHplRDNpRzVwNWxnZUxFVEt1U0VPd01EOFNMaHZQcDJoZ0wwa2R1?=
 =?utf-8?B?WWlIYWFlV3dBcy8ydlFLb2F0YWplMy9kSmllZ3BPR3dIdlcvWGJ4M056cUZz?=
 =?utf-8?B?UERXamJwV05oUnprTTZzQ1dkTk5FYTRBMG16N3dFa2xPSUE0eXFSQXcwNjFa?=
 =?utf-8?B?Z1lXRUU0Z2hERmNCR1ByVFFiUk5jZzJZQ2pvMURLcjU2bDYzTERWUWtCTm8w?=
 =?utf-8?B?ak1XQzBTb21vQXZCcHRXYjQyTmRVOGtTSzlMNlpFVVpxUU9oUEUwZStBWmdB?=
 =?utf-8?B?T3A3OW5CV3QrL2p5a3h2cGRBeFVKVnozaVNESTVaUmlJSDR2OTdyZzFrRGRh?=
 =?utf-8?B?ZmJwVTdFTys1SjRLeldIcFJEQ1RPQWlLOUhEK2FBc0U5L2hSSm9lOXZITHJn?=
 =?utf-8?B?N2xOVVo0UWw4RFRpZE5iZS9rYlpNYVk2WDcwZVNCR2RXZ0xzK3hzNElBLzA5?=
 =?utf-8?B?U3FNN2FpT0Z0bEk1NWtTdXk5cDNQUm4wd0RzallzaklCSTdLcXViSitmYTF1?=
 =?utf-8?B?bnhYbzdnMHQxd3hwRi8wRGlPSkJ5d0xzSnMwN0tmQ2hVelpZcEZYaEt4b0hS?=
 =?utf-8?B?TjFZeDUwUVhZdVpmQmtrNHNQNXV1SGFsSFFaUWJDK0RRdjJSVVBMQWYvYzB6?=
 =?utf-8?B?NkQxNU8reERzajYwNkozUEpjWFBxOEZrN3BLeHF6aEh6TjNDMjZVR2diUGtl?=
 =?utf-8?B?ZVpFWmZYYXAvdjRiamZmY0FGWGs1SUFlR21Dc1pvMzZ4cHdrZ2V2ZmNXZHlj?=
 =?utf-8?B?VktRenFIRjl3YTA0SkMvYTR4SHVoWkticVdLcVVzaHRnZmZBYXVCWnRkV2kw?=
 =?utf-8?B?bUFqbmlYd0tqUGlqR3dGUExFVlFQMjM1VWZGK3hadkpsWXdGS2pSQ0h3d3Iv?=
 =?utf-8?B?VnMveDQ3SUhqb2VwaWJOVHJQNFg4Zmh4TGRBSDlRbklKK28yaEM3V05mY0Fh?=
 =?utf-8?B?N0QvNzdoRUVTU0NMaEFqMFlTSzVPb0N2bVlSR2JEWVBCVmdmR1BxZ1Nuc2NQ?=
 =?utf-8?B?U3ovdWQ4L3RFWmJVZ0tWbEJ1ODhmakVrNU45RzM2cVZZZWRFSWx3MlBMME5z?=
 =?utf-8?B?Z0ZiRTVkYXA1dmNIVVY5dDl4RGlkRVFQZmE3L0wwSXJVVVVzY2JmeXgwK0Z5?=
 =?utf-8?B?OTBHbGM4a2QvbFNIT05mK0pBTzBHSU5PbUtiRHNWVk0xdWFIcmtyTjMyY2lD?=
 =?utf-8?B?ZFZJM3BJa2lkZ0ZmSFk1RXZJdituTitIOTcwd1NzQ21YenlnWkdlWXBkQWJq?=
 =?utf-8?B?SmdVU1hEdnBsVlF3Y2J1OXYrUkdEZlM2cTRLRi9QUUFIT2hXUnJnNWs3L3JQ?=
 =?utf-8?B?YkVCdlIvUzR2ZEwxV3hBc1p0WVdLSHlOcU1PWUNUWDgrL3c3YUMweDRNMXVi?=
 =?utf-8?B?enJYdDA5bHF2bWE3eGZqNEQ1UDlOcENyQXFVaFIrMHNyc1cyakQzK3hXL3R4?=
 =?utf-8?B?c2VTSEdnVUkzS1dEUlVtWWhjNEVBaktzRWxCOCtMeVpqL3pMT20yZG00T1hC?=
 =?utf-8?B?R2F1dmpxaC9jY0lodTZIWHJ2czYxVkJKa3kxWnNTS053ZG11Mm5RZk5vUFA2?=
 =?utf-8?Q?fPXI=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 170388cd-19af-4e89-c8e6-08ddeca3b7e5
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 17:43:26.7235
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: J6B6cBXSQbyRzIh+uShpttmXlQ1roo6BeAEy92OWbRCVfTXsxw7FpfzT+ScCWlKU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6265

On Fri, Sep 05, 2025 at 06:20:51PM +0200, Marek Szyprowski wrote:

> I've checked the most advertised use case in 
> https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio
> and I still don't see the reason why it cannot be based 
> on dma_map_resource() API? I'm aware of the little asymmetry of the 
> client calls is such case, indeed it is not preety, but this should work 
> even now:
> 
> phys = phys_vec[i].paddr;
> 
> if (is_mmio)
>      dma_map_resource(phys, len, ...);
> else
>      dma_map_page(phys_to_page(phys), offset_in_page(phys), ...);
> 
> What did I miss?

I have a somewhat different answer than Leon..

The link path would need a resource variation too:

+			ret = dma_iova_link(attachment->dev, state,
+					    phys_vec[i].paddr, 0,
+					    phys_vec[i].len, dir, attrs);
+			if (ret)
+				goto err_unmap_dma;
+
+			mapped_len += phys_vec[i].len;

It is an existing bug that we don't properly handle all details of
MMIO for link.

Since this is already a phys_addr_t I wouldn't strongly argue that
should be done by adding ATTR_MMIO to dma_iova_link().

If you did that, then you'd still want a dma_(un)map_phys() helper
that handled ATTR_MMIO too. It could be an inline "if () resource else
page" wrapper like you say.

So API wise I think we have the right design here.

I think the question you are asking is how much changing to the
internals of the DMA API do you want to do to make ATTR_MMIO.

It is not zero, but there is some minimum that is less than this.

So reason #1 much of this ATTR_MMIO is needed anyhow. Being consistent
and unifying the dma_map_resource path with ATTR_MMIO should improve
the long term maintainability of the code. We already uncovered paths
where map_resource is not behaving consistently with map_page and it
is unclear if these are bugs or deliberate.

Reason #2 we do actually want to get rid of struct page usage to help
advance Matthew's work. This means we want to build a clean struct
page less path for IO. Meaning we can do phys to virt, or kmap phys,
but none of: phys to page, page to virt, page to phys. Stopping at a
phys based public API and then leaving all the phys to page/etc
conversions hidden inside is not enough.

This is why I was looking at the dma_ops path, to see just how much
page usage there is, and I found very little. So this dream is
achievable and with this series we are there for ARM64 and x86
environments.

> This patchset focuses only on the dma_map_page -> dma_map_phys rework. 
> There are also other interfaces, like dma_alloc_pages() and so far 
> nothing has been proposed for them so far.

That's because they already have non-page alternatives.

Allmost all places call dma_alloc_noncoherent():

static inline void *dma_alloc_noncoherent(struct device *dev, size_t size,
		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
{
	struct page *page = dma_alloc_pages(dev, size, dma_handle, dir, gfp);
	return page ? page_address(page) : NULL;

Which is KVA based.

There is only one user I found of alloc_pages:

drivers/firewire/ohci.c:                ctx->pages[i] = dma_alloc_pages(dev, PAGE_SIZE, &dma_addr,

And it deliberately uses page->private:

		set_page_private(ctx->pages[i], dma_addr);

So it is correct to use the struct page API.

Some usages of dma_alloc_noncontiguous() can be implemented using the
dma_iova_link() flow like drivers/vfio/pci/mlx5/cmd.c shows by using
alloc_pages_bulk() for the allocator. We don't yet have a 'dma alloc
link' operation though, and there are only 4 users of
dma_alloc_noncontiguous()..

Jason


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 18:31:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 18:31:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112283.1460625 (Exim 4.92)
	(envelope-from )
	id 1uubDQ-0007dJ-T6; Fri, 05 Sep 2025 18:31:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112283.1460625; Fri, 05 Sep 2025 18: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 1uubDQ-0007dC-P5; Fri, 05 Sep 2025 18:31:16 +0000
Received: by outflank-mailman (input) for mailman id 1112283;
 Fri, 05 Sep 2025 18:31: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 1uubDO-0007d5-KA
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 18:31:14 +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 78bb5216-8a86-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 20:31:00 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU0PR03MB8551.eurprd03.prod.outlook.com (2603:10a6:10:3e2::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Fri, 5 Sep
 2025 18:30:58 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9073.026; Fri, 5 Sep 2025
 18: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: 78bb5216-8a86-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=grw8OoeqFWzY2kWJhdx43YBJH1IZ297GbluVT7aLdfXUnr+jr5qAFyGl1NAT6YogwCbucpk+9ScNA/SOVgIdS6Q1NV+H/bLHBTqkNdwUcr1l71rsylEnH+yExqe7nSXOaakOVEWu6Q6LoawvXMZPJ7RMj1NWA3QC3Rd2kKxKN6ss1NNUkkYe+Ika6Ny07S5PJrI68oNZqIlLHCOZvaHQk5eF4eljsC3pWWL9KrlSngchLke/5u3aULUxLax+Yjcc0j16zPOm+m1S0fltHn4R3PfzfmYT5eQ0yd9wQ9vIhnfesqzjTC/+gzrubWkcKEpnawE5nA+qihc/yvd9ETr6sg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TcedgvUfzEoVTbTnQolZsWuqm45lXszulgJq2t5d1UY=;
 b=s94zzmFV++hbBoclP8t+OMu7BrOLqY94vMwaBxLj9zZTWX5aXbu0v4/vTQX87l//358y9j/Plocz1IS3jVUX3T0mBhxQQIUfMi7k6dWM0q639UOGuCIwB1FG7EsZCgC9kCp0XKrLUtiRmeRyKDs/5JhWwJC9neFSGys+1rydyWgqu2jD4uRfFEHCx5/CKmdg2rN4zlAbbfvcEc6cHx1DeAbS3gIuDWaWPlg8Z6T2tXd2iH1DNbBtEH3pUMxQP7goSR5T4Ro+BGlKGK9iS1JRUQnZIqjuFPITvFJuYahyGU2qtMurFAJShsWIUb2r7XLlr/SNd8mFY+bbSVmOdOg2tw==
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=TcedgvUfzEoVTbTnQolZsWuqm45lXszulgJq2t5d1UY=;
 b=Ao+xuiioEw7MLRPD6J2vv6wNvSVBhGJ13XjxucjzXGwQZqVR/YKwYSuN/0Lnbdlr0njeCyJSQsdZQWPUW1qiJ3aWuR8GDN6sCfuk8FBkvvDPi4xhExtb2Qktw28k2VcYykGse/IsILEaPdNrvgy5kGNK53xilNGOFAFO12+IWafOWAgfUseoL9/Ie0aegZET8eW2qRMFruJbeLsVqNvEknnxptBiVy9RMzOE8fNpQUzph7CJhx/uJdic3VPjwS9NdXhMBYRpBiT42+RugPKGx44d7G1b3DQ+7Qxip5KMuSNrhW2N0RhanoSpK08CcQX5eKsY17LxhxYv1syrw89wOg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <99fd1f8c-03b5-482b-b421-ba17f4b17e17@epam.com>
Date: Fri, 5 Sep 2025 21:30:56 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm64: allow to make aarch32 support optional
To: Julien Grall ,
 Volodymyr Babchuk 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksandr Tyshchenko 
References: <20250806094929.293658-1-grygorii_strashko@epam.com>
 <20250806094929.293658-4-grygorii_strashko@epam.com>
 <87ms7l39gl.fsf@epam.com> <540abaa2-9946-40b8-bf49-b54e4f7a1393@epam.com>
 <87o6rpqent.fsf@epam.com> <1b27dc46-4d5c-4c6d-8976-0f9b98d11d6b@xen.org>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <1b27dc46-4d5c-4c6d-8976-0f9b98d11d6b@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: WA0P291CA0006.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::18) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DU0PR03MB8551:EE_
X-MS-Office365-Filtering-Correlation-Id: 830199fe-8712-427f-ceec-08ddecaa5b5c
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?Q3lSbzNmQi82SHRPWG9FS2VZb1BCZlUzNGlKQkRTdDRFMzI3eWFPZHNJMk5h?=
 =?utf-8?B?djdMaURoa3llOVFyVnhuOGVyNVpVZStrR1JvTVVSOTBuWW9MRWpuaGFqRW43?=
 =?utf-8?B?ZmhRQnNDNWRWR1NxcmVkMWEzc0dVbjhjZS9EWWhwOUxhSFBXeVVhWCtJSVhl?=
 =?utf-8?B?TUZ6ek1oWnJKZEE3VGxwd09mNzNrT2RVUW1PQjVDVmwzeHU2eXlhTmdDNmlr?=
 =?utf-8?B?NW4xN2thQXpCbWZvZFlhWi93VjNneGU3MHg1VjZVWnYzaVZoZWFQaWNSODJY?=
 =?utf-8?B?OThMMjVGOVZMSVAyakxDK2YwR25QMStmWUdkR3NoN1JSajVUUllIY01MT1dy?=
 =?utf-8?B?VWIwdTA3UkxocVpIUlpRakhHVHhHK0J1QXRibnMwV0RORGs3aU9KaTFHNDBP?=
 =?utf-8?B?d2Erc2dBcXpxU044MUVwWXpOMW5hRmFYa3pubDR1ZVVpU3dIUytlZnVjaUhv?=
 =?utf-8?B?U0JLam1OUXNiZThzWnNMV2hSclJiSHdHRFoxV0cvTWEzZDMwczZWQm5pR0VD?=
 =?utf-8?B?cmoxMTFsenhvMkh2UmNRc3FCZ21BQ1N0UmMzMlk3Z05GNnVPYjRNdXE3cWp0?=
 =?utf-8?B?RFR0S21lVnlENW05TVBvOEw1TUdXbzJQZE9HU1JCU3ZaL3dPaS85NXBoU2JQ?=
 =?utf-8?B?RDR2eFdpeEo2NC8xOG1iL21jWEdUd1A3cjdjcDZNNzNLWk5QVmZPaGEwTmtp?=
 =?utf-8?B?aHdJVTRhdVhZaUJ1NlZpTFdyY2pEQ0xCSkljak9DODBFanBHWm1MMDI5blhQ?=
 =?utf-8?B?em05SEJzWlR3QXNqV3FtNWQ1K1hIaUVpRGlyWHNHMDJ2MHNqVDdaWTM2TkxJ?=
 =?utf-8?B?TGs2NnJDRW9PeXplcFpGUXBMQ2FtaVQvdFd5dGNpSzZLcHd6VThCcWNmTDZ4?=
 =?utf-8?B?OTRsRHpFTW5BUEhRTG96QnIyUFl5aDFmSGlZRk1ERHl3aEF2ZzA2YmFGSjhE?=
 =?utf-8?B?K0Ntb29aQ2V1bjVVT0xDSklTdmtiamdUeHU1RXpNVXphbkhvYzc2a0ZDMlda?=
 =?utf-8?B?T0QwejVpdWtBTGREMy92RldYMWo2NWcxQTR0R3Z3V00wSUt6enhTTlBvVC9y?=
 =?utf-8?B?ZlU2OEY1cXRQdFVSK1U1NTc3SzhreC9VTXMzekxUNW9WR2x4QmRWUlhTNFBM?=
 =?utf-8?B?K3BZNlpYZTl2UUtYTXYxUGRWSEZpdTEyR2cyVSthRE53TXY2NnhRZ1Q3UGhQ?=
 =?utf-8?B?ajIxL3UwbklkbWRPekVmcVFlRnpqSWQyVjhSbDZLVkJZTnpnTE01Z0pYWjh2?=
 =?utf-8?B?S3ZlWlVQMi9UL3hlUUh5d2swRXdzYlBiU05JZFpzSHZLWTdHcHp6NFE1Mzdj?=
 =?utf-8?B?Q09TK3pheVh1OE5QV2xlTExDbHVHVnA4bFFGd0s5U3A3aDlQMVp1UkVnYVpX?=
 =?utf-8?B?MFNOeGFmSjVORUwxNW5QeDRnVndkbmN3QXJCcnZhVXVyN2pGOUNPOHZ5VmQ4?=
 =?utf-8?B?VnRzK3M0SFBXTmlpVzdmUkprTytWbWE5aGdURTBtSWQ1cHVIQXVMeHJDdVM5?=
 =?utf-8?B?VU9oMEM3ZEpVY0tvWkhKaTdnVGU1VldjQVNGZGRNaGdSbXBvRFQ0NWFhQkFs?=
 =?utf-8?B?N2NydkFJNDlEckU2dGRxVm03S2RiUmtvWGM5U3RYWnRHc2xGUjBJMnhtSVMz?=
 =?utf-8?B?c05Zek9ESlZCNlFUYnhHVUoxUWhXZGJDZ2ptVmZqa2VKRFV4cVN5MUlrcmlz?=
 =?utf-8?B?NnlGOXpLOEZvMnQ3T0pGREdrVFlPczRlS1FzZDB4SlFsV3FGdUF4bG1mTEtq?=
 =?utf-8?B?VHlWQ2xKVGdZSmdHd3Rab1J2L0tnM1ZzQktlRkxreTFxMndGa1JBMktXMDdm?=
 =?utf-8?B?Y09zU0MvUlVOb1liTlp5NTdzMW5BcEt4TEpsTG1QUWRVaFNKdlNETEtQVzlK?=
 =?utf-8?B?UXVhTXNjTHljemJsNUQycXpjWUhSeUx3c2xxWXlIQlJUMHEwZWFJRzQ3ZDRs?=
 =?utf-8?Q?xp/oTWg2268=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Y0xRb1RhTnhmbkprbWtHMjQ0R3czcjVQMG9RUWxqaFZFeWcyTEtiVmQzL0w2?=
 =?utf-8?B?K1BUQVBWZTFDYzl4a25lV1M5REJ1VVNVM0liSE1LbVJSbXdXYXlTa25DTkVN?=
 =?utf-8?B?SG5nZU1QS3RYSWlMaGFmT29sdmh3QUI0T2lVVnRWUyt1UVdxM05ra1g3RzQ2?=
 =?utf-8?B?UG5Wb1I4ZlNzNnJwaGpaYWxvaDl0UjlJOVlRTnBRSXE2R0JqOUt1QkR0NHVZ?=
 =?utf-8?B?WGUweURwSXRicm8wVG9Hb0ZvNzVPRDR1Wnh6c1drdUJLTnRHUW94Y2pTRkZu?=
 =?utf-8?B?djdlVHBESFUwcDNTWUtyM090S3RjUGlpcHNnRGMxWCtKVnMxTzNiMGJGTWUy?=
 =?utf-8?B?MFUzOGNHTm9SU0J3UHdRejVKZzBRcEovUTNFaVVEVnB5RzcyZU1KUG80akJU?=
 =?utf-8?B?TWNpMkp6bE92MDdoVGgzNm90RU11Z1N6WnR6NnE0WDFCcFFCaTNDTm4vSDRY?=
 =?utf-8?B?YllsYkNhTzR3d0JpSm1CZVEvalZ2cUR1Z2FFNzZkNHF4N3NNZ3ZuQzFpdHox?=
 =?utf-8?B?VllQNzBBeGtZSXJMZDhxZTRoQUg3ckJzcGFFMHBWeHJ1QTZuM0FBajQ3UzZo?=
 =?utf-8?B?LzNkeGNteGJMeFVjMjBlK3lTUWVmb0phUHV2U00wcHdwYVdpQ2pjQmVqTUZt?=
 =?utf-8?B?UUVLM3lHRWExQW9uVDVObHRmdGhndVpCUlJhYTRwNFUyYTlJWXRLZllUSisv?=
 =?utf-8?B?cGNkNFkzMzRBRG9uc21WMkVmTmZlbWxVQ1BIQ0JrbU9hT0tiSjFBVSt5MzJS?=
 =?utf-8?B?Q1k2SXZyNlRMeHZTcE01cDdUOXdjZVJyYWo1NEhoUCtWWjExRmJzbmpUS3BX?=
 =?utf-8?B?dWdhcXlneE5BUkxMS29lZlY3cWQ5LzBYd0NnVldidEFKeGllWmNSLzBIWE1T?=
 =?utf-8?B?Mm94NWl3NFA1dEJtMGplb2o3UFpoeE93U3ZzT0gzWmtKc2ZIdDhGVVJTcnlG?=
 =?utf-8?B?OEZSbTRmS0NYSnNEcGhaNW9LM1hUNjRPbnZybmpZREt3dExmRDRyUG9TclBu?=
 =?utf-8?B?dlhtWWR3azZRcHVBRzNISkVqd0puSk1ZWVN0a1NFYUpNN3BJYVEzZWRWWVNq?=
 =?utf-8?B?dVl5NWhRRFdTekNEUEhFcmMzNkkzWlZlUFdacVkwYXpCaHduYytlOHgxSllS?=
 =?utf-8?B?Y0pucEhEakpHYU5vd1JiRFZFK3A0MTJsRVIySnZmLy80amlzNmZSMnM5OUNX?=
 =?utf-8?B?RWdxdnNIR3FsY3BNaVYyV0FBaWtLYTBZeG5pdXQyenNtb3dkOGVuZWhXbjhN?=
 =?utf-8?B?bTBodFVHOVRtbXVGT3JTQUllY2t6M1R3V1MxWmp5a2ZMTUIrWVduN0tSY3No?=
 =?utf-8?B?NUc2Wk83TnVmRDdHc3c3MHBNL2RJaTMra3VSS1ZCQ1NyYXczZHdPdFZyOTdZ?=
 =?utf-8?B?YmtuYS8wVmF5YXByNnZiRkdiMldqaFV0SytVeENtc0pwaXBaZGJ0c3lzS2Rm?=
 =?utf-8?B?WWNrMUVFTHFERUlRQU5WOTBJVnluaFV6enZRRGNBcHFKY0ZTZzJYSjJDN2Fw?=
 =?utf-8?B?M2xZYXJSNjQrNGp6TTRBaUlOVEtRZHl4YzhMSFpXb0phZmNWYXRraklRSHp6?=
 =?utf-8?B?amZxTUl6cU5CU3hWTnJzcnRJajBhMDVnQWE2YWZSRWluYVNnU01tbXEzSlVk?=
 =?utf-8?B?TWNNZG9XSng2ZDdlRU5VM1I4dmR4WWFpblZjMUVZVFlNQlBVSWlrZlVXbEtm?=
 =?utf-8?B?aXRtcjRXYjJCN1dUVitkb2h4MlRtL2txcFZnUnBOb3BaSTB4MlBtN3I0MUpl?=
 =?utf-8?B?YmdGQmlSbFhFbHFhOWlhTm9FbkNhMlhGTHJhSStaVEhNU080QjR0NDY2L29Y?=
 =?utf-8?B?dDlubjJkSUtWczFIanlhYkFkTUlZeWE3UGFpYzVTa2NWbnJZYzRZa29HM0dt?=
 =?utf-8?B?TkJNVnZJRHh1bDNuMVNJUjFnTUY3ZmlsV0xYbm9nUzM0Z0FIeGt3TmdhZkFE?=
 =?utf-8?B?UmxDMzR3Zi9UM1A1MGdvNFNFbjh5MkFmQnZ6M1JyTktWTkhWUHEwK2NLYUNp?=
 =?utf-8?B?NXlPN1MrNU1td1lxT05xNGJwWi93STY5alhFZGRxbmFVak1lV3BtVHdDd2NS?=
 =?utf-8?B?alp4SlltZThTanNqOVZXQ1p6Rnh6UzVUaUg1NE1kSUtycFJROEVsSUJWS3Z2?=
 =?utf-8?B?clplb3VzQTN5UmRldEJjUnVrelpIc0Z4V0tsN0ViYXRpSFk2cE1wVVRDanFx?=
 =?utf-8?B?SFE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 830199fe-8712-427f-ceec-08ddecaa5b5c
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 18:30:57.9989
 (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: gq7oHEB5a1bXOTVUzouWnK10mdneXaSpGZsqzCkqFCrpuDmZA+Gf4Wo8ZkNJB9fWJ7MUMSTh4U+fCVePhdu03mzxsCmYaiJw7V1bZN1z4aQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8551

Hi

On 05.09.25 16:07, Julien Grall wrote:
> 
> 
> On 05/09/2025 13:15, Volodymyr Babchuk wrote:
>> Hi,
>>
>> Grygorii Strashko  writes:
>>
>>> On 27.08.25 03:16, Volodymyr Babchuk wrote:
>>>> Hi Grygorii,
>>>> Grygorii Strashko  writes:
>>>>
>>>>> From: Grygorii Strashko 
>>>>>
>>>>> Now Arm64 AArch32 guest support is always enabled and built-in while not
>>>>> all Arm64 platforms supports AArch32 (for exmaple on Armv9A) or this
>>>>> support might not be needed (Arm64 AArch32 is used quite rarely in embedded
>>>>> systems). More over, when focusing on safety certification, AArch32 related
>>>>> code in Xen leaves a gap in terms of coverage that cannot really be
>>>>> justified in words. This leaves two options: either support it (lots of
>>>>> additional testing, requirements and documents would be needed) or compile
>>>>> it out.
>>>>>
>>>>> Hence, this patch introduces basic support to allow make Arm64
>>>>> AArch32 guest support optional. The following changes are introduced:
>>>>>
>>>>> - Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
>>>>>     Arm64 AArch32 guest support (default y)
>>>>>
>>>>> - Introduce is_aarch32_enabled() helper which accounts Arm64 HW capability
>>>>>     and CONFIG_ARM64_AARCH32 setting
>>>>>
>>>>> - Introduce arm64_set_domain_type() to configure Arm64 domain type in
>>>>>     unified way instead of open coding (d)->arch.type, and account
>>>>>     CONFIG_ARM64_AARCH32 configuration.
>>>>>
>>>>> - toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 is
>>>>>     disabled.
>>>>>
>>>>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>>>>     AArch32 is disabled.
>>>>>
>>>>> - Set Arm64 domain type to DOMAIN_64BIT by default.
>>>>>     - the Arm Xen boot code is handling this case properly already;
>>>>>     - for toolstack case the XEN_DOMCTL_set_address_size hypercall handling
>>>>>       updated to forcibly configure domain type regardless of current domain
>>>>>       type configuration, so toolstack behavior is unchanged.
>>>>>
>>>>> With CONFIG_ARM64_AARCH32=n the Xen will reject AArch32 guests (kernels) if
>>>>> configured by user in the following way:
>>>>> - Xen boot will fail with panic during dom0 or dom0less domains creation
>>>>> - toolstack domain creation will be rejected due to xc_dom_compat_check()
>>>>>     failure.
>>>>>
>>>>> Making Arm64 AArch32 guest support open further possibilities for build
>>>>> optimizations of Arm64 AArch32 guest support code.
>>>>>
>>>>> Signed-off-by: Grygorii Strashko 
>>>>> ---
>>>>> changes in v2:
>>>>> - use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 support
>>>>> - rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with any
>>>>>     initial domain type set (32bit or 64 bit)
>>>>> - fix comments related to macro parameters evaluation issues
>>>>> - do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
>>>>>     AArch32 is disabled
>>>>>
>>>>>    xen/arch/arm/Kconfig                    |  7 ++++
>>>>>    xen/arch/arm/arm64/domain-build.c       | 46 +++++++++++++++++++++++--
>>>>>    xen/arch/arm/arm64/domctl.c             | 16 +++++----
>>>>>    xen/arch/arm/arm64/vsysreg.c            |  9 +++++
>>>>>    xen/arch/arm/domain.c                   |  9 +++++
>>>>>    xen/arch/arm/domain_build.c             | 21 +++--------
>>>>>    xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
>>>>>    xen/arch/arm/include/asm/arm64/domain.h | 23 +++++++++++++
>>>>>    xen/arch/arm/setup.c                    |  2 +-
>>>>>    9 files changed, 119 insertions(+), 26 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>>> index a0c816047427..bf6dd73caf73 100644
>>>>> --- a/xen/arch/arm/Kconfig
>>>>> +++ b/xen/arch/arm/Kconfig
>>>>> @@ -266,6 +266,13 @@ config PCI_PASSTHROUGH
>>>>>        help
>>>>>          This option enables PCI device passthrough
>>>>>    +config ARM64_AARCH32
>>>>> +    bool "AArch32 Guests support on on ARM64 (UNSUPPORTED)" if UNSUPPORTED
>>>> But aarch32 guests are supported... I understand that you wanted to
>>>> say
>>>> "Disabling aarch32 support is unsupported". But currently this entry
>>>> reads backwards. I think it should be reworded better. But I have no
>>>> idea - how to do this.
>>>
>>> I think "(UNSUPPORTED)" can be just dropped. Is it ok?
>>
>> As I understand, If you want this feature to be eventually certified, it
>> should not be UNSUPPORTED nor EXPERIMENTAL.
> 
> The certification is somewhat irrelevant to the decision of the state of the feature. 
> Instead, the decision should be based on the criteria based in SUPPORT.MD (see "Status"). 
> If it is experimental/unsupported, then what's missing to make it supported?
> 
> In addition to that, there is the "EXPERT" mode. This was introduced mainly to allow the user
> to tailor the Kconfig but also limit to what we security support. This is to reduce the amount
> of workload on the security team when it comes to decide on whether we need to issue an XSA
> (the more possibility, the more difficult it becomes).

If I understood comments about Kconfig option correctly (which I might not be):
- Not sure if it can be called a "feature" it rather optimization (enabled optionally)
- From my point of view it's basically completed
- The "Arm64 AArch32 guest support" is not mentioned SUPPORT.MD

I'm not sure what support level can be considered for "Arm64 AArch32 guest support"
hence there was no related Kconfig option before.

if treat "Arm64 AArch32 guest support" as : "Supported"
(a) by default ARM64_AARCH32=y, so no changes in Xen default behavior or interfaces
(b) switching to ARM64_AARCH32=n might change status and seems fall under
    "EXPERT and DEBUG Kconfig options are not security supported."

if treat status other than "Supported" - probably no need to depend from EXPERT.

I'm going to change dependency to EXPERT in the next version.

> 
> There has been discussion on providing a small set of config (one could be for certification purpose)
> that would be security supported. But I don't think we come to a conclusion yet.

Thanks a lot for your comments.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 19:05:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 19:05:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112313.1460635 (Exim 4.92)
	(envelope-from )
	id 1uubkC-0003j6-CO; Fri, 05 Sep 2025 19:05:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112313.1460635; Fri, 05 Sep 2025 19: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 1uubkC-0003iz-8f; Fri, 05 Sep 2025 19:05:08 +0000
Received: by outflank-mailman (input) for mailman id 1112313;
 Fri, 05 Sep 2025 19:05: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 1uubkB-0003it-BO
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 19:05: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 3989a3fe-8a8b-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 21:05:02 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3e46fac8421so672258f8f.2
 for ; Fri, 05 Sep 2025 12:05:02 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3d0a1f807f9sm31600377f8f.38.2025.09.05.12.05.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 12: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: 3989a3fe-8a8b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757099101; x=1757703901; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6nzf2l82j6ghu3fUKUCxp+1Esp+rN4o4BInmeEEC9F0=;
        b=kFlr0+e+nmoVZMW4Gj2io6kLrnKTeZvRvji75cK7p5kXExsF6IhH8NpeORAfOKHKkz
         JML+U1Bdoh/kxVdW1yAK5YhxiIt0tekjAeyzmXh2XdDTVexNhIKGdvowkeP/vOILxCVM
         QQWslmZSguclj0VEnfOKX27W+z+x3aYUDD8Jo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757099101; x=1757703901;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6nzf2l82j6ghu3fUKUCxp+1Esp+rN4o4BInmeEEC9F0=;
        b=qLZM3sraquY86fmMM9U/U/GH10qbSJM4W3oGKw1dbDll11L5eYObV9StKjyKXLHgxo
         u9MLSSsH08mRludQCuhJbcWNeooL4RTum/mFCLuq2UgmBK8mng+C8BLa/na+RxMj2UYR
         b3KjN/+6aTQqx9uukbuA+ZlDy1iRzCzTQyQeeoFh1HtdpO6pUx7tUoe6dvQqZk58x3pR
         Hq072AhcRqxEBi4y5dy1P+npkvJWhY2FqIGYb9FyKsBpPW/zc0flgbJQHwnTrGP5qLy1
         Hd9tsZkyHpuoGvXhm1UOyT2w/hycwRKnt0OZ9KX1hZc1QqNB5mUBIFVlj+dE1MUiW6ih
         X+PA==
X-Forwarded-Encrypted: i=1; AJvYcCU+pHHSYoph9uimUU9U4zRoX5WhNNmF0LkC2JYzoIOJbYwX3Z9OpKIMp3s3Q6LXyyENFfYiy6NmqG4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzivL7D+Hq65d8CRZkOPftGrqi5f+uhfgY3wOwRop3UeymtH7n9
	wxONXz8U1WpuLyAQcNCTYwRfRGSBHFe4zeUybVztxVtL+KX5PjFe1T1wneozqh1FRgY=
X-Gm-Gg: ASbGncsNHzw/OasZTjWshb8Hs8MOz7J1/nxn4f71m3bMhuRGxe6CAGF7Mt8MkvzYgEy
	ftgFS990GJmb02Nf23ZeKWzNJiHoVN4AP4VTQvRaMTpQD/f3+MB/sdemGFeLFZbEzsr1mLwImdT
	3mVSlypea5tSzhEik4tE9MzjwfrE7R/UizuUNZ6q3vnsdpdGA4i0kfO7MhiYrRL9HolPqAGszpO
	aYLGPpQxe3GveODOQfYjS19cjtdXjoLoavUltgiHyt/eAT/zygZbwjab98MvzGVYYtGZe6SQopr
	nYSODyWrU642t0B/SP9krXEXULU/25h1eNnzRGEh3flBduaQlUjyrrqUqpux8E/9eDQ+m15/C9j
	yRclGRqzsq4gtJNZqdivfIk4e7drz6cGxcyiScALFofM19SQeqYLACirNxOGWK9rRfzFRsO/Iih
	14c2oY5+u+a8TfQg==
X-Google-Smtp-Source: AGHT+IFXw+piYTULfvnwMt5iJjLe7sKHtFOvyw5kuX+qmAGBbI3a88bs3bGXordQ7q26yfwDV5/mzA==
X-Received: by 2002:a05:6000:2307:b0:3ce:f9b7:4db with SMTP id ffacd0b85a97d-3d1de6a8dc5mr20101714f8f.24.1757099101387;
        Fri, 05 Sep 2025 12:05:01 -0700 (PDT)
Message-ID: <79893688-1ee1-4fb5-8703-c2f3b7d3da40@citrix.com>
Date: Fri, 5 Sep 2025 20:04:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/2] efi: Support using Shim's LoadImage protocol
To: Gerald Elder-Vass ,
 Xen-devel 
Cc: Kevin Lampis ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Jan Beulich , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: 
 <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@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: <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/09/2025 1:10 pm, Gerald Elder-Vass wrote:
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index ccbfc401f7ba..0a72c293301d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>      return gop_mode;
>  }
>  
> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> +{
> +    static EFI_GUID __initdata shim_image_guid = SHIM_IMAGE_LOADER_GUID;
> +    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
> +    SHIM_IMAGE_LOADER *shim_loader;
> +    EFI_HANDLE loaded_kernel;
> +    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> +    EFI_STATUS status;
> +    bool verified = false;
> +
> +    /* Look for LoadImage first */
> +    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
> +                                           (void **)&shim_loader)) )
> +    {
> +        status = shim_loader->LoadImage(false, ImageHandle, NULL,
> +                                        (void *)kernel.ptr, kernel.size,
> +                                        &loaded_kernel);
> +        if ( !EFI_ERROR(status) )
> +            verified = true;
> +
> +        /* LoadImage performed verification, now clean up with UnloadImage */

I think this wants a bit of the explanation given in reply to v3. 
Something like:

/* Always unload the image.  We only wanted LoadImage to perform
verification anyway, and in the case of a failure, there may still be
cleanup needing to be performed. */

I can fix this on commit if there are no other concerns.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 19:14:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 19:14:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1110415.1460645 (Exim 4.92)
	(envelope-from )
	id 1uubte-0005Qj-A8; Fri, 05 Sep 2025 19:14:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1110415.1460645; Fri, 05 Sep 2025 19:14: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 1uubte-0005Qc-7P; Fri, 05 Sep 2025 19:14:54 +0000
Received: by outflank-mailman (input) for mailman id 1110415;
 Thu, 04 Sep 2025 15:07: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 1uuBYb-0007H4-Bn
 for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 15:07:25 +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 dbad5e69-89a0-11f0-9809-7dc792cee155;
 Thu, 04 Sep 2025 17:07:22 +0200 (CEST)
Received: from AS4PR10CA0022.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5d8::6)
 by AS8PR08MB8707.eurprd08.prod.outlook.com (2603:10a6:20b:563::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Thu, 4 Sep
 2025 15:07:13 +0000
Received: from AMS1EPF00000049.eurprd04.prod.outlook.com
 (2603:10a6:20b:5d8:cafe::5d) by AS4PR10CA0022.outlook.office365.com
 (2603:10a6:20b:5d8::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.18 via Frontend Transport; Thu,
 4 Sep 2025 15:07:13 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS1EPF00000049.mail.protection.outlook.com (10.167.16.133) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.14
 via Frontend Transport; Thu, 4 Sep 2025 15:07:12 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20) by GV2PR08MB7931.eurprd08.prod.outlook.com
 (2603:10a6:150:a8::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.29; Thu, 4 Sep
 2025 15:06:37 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739]) by GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739%7]) with mapi id 15.20.9094.017; Thu, 4 Sep 2025
 15:06: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: dbad5e69-89a0-11f0-9809-7dc792cee155
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=RRlmswNYw0YOipr//mRpYd/reSU/5NRxw30PBJGTon9anEyMIOSZQjaNpXkjOjjRbGTtEQy1LMOiDTp6/ClLKV0LZsl1BkkQvOV5Adw7Uohh/2z1ELl860X+Os4YazCcwgQHfkJ6ykDVRYt03rJwothBz8FoSNxNIGZ1dCtaxIVJVJZ6Rv9gIPexT6tKZcqwcOFeWPdWI7DwUW7IcMAHnmLabutt6t5D6DwjmrqmEdzyOkC3WuMLPTP1m+OBOhjlOpec1ThVtULkgi2s/aU1Df+rPr/5Rs0tq0b/rP/dRV6Mgn/JNGio2ywhBGg0Ta9SUBbxZxu3+cxB0c8X8k7ZSA==
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=ugMn6oKEOjYHvg+0JhztaCK4sS5GJrjKq1+zAszikv8=;
 b=dAqiET0B80bzPJqY8/daLtl2aRt/Hmx68fTJqzIzPmna5LA468SqpjByVHon+C8nTLRzReJwP337LDWr35iq6Pc+H48d+y4qBrJJfrziCFKp5ohAP9hBySjKqCncCmeu0aDbRIcqYNn+aNOzLU/oytPFvgG6ZWiqhxX1nixrmBF6o24H9wy+bOgAf/XbDGyugnWPKGOUEVBJeNxJ3Y2n5R7Qe/U/8uvFgDghr1F4IIHCd4ke0YulxsjKoRoMeObcRkzHLKqnOVEJitkEA1sV+J4JhjdOIsbuRc7FZNNG/uVRkGSzvbrSSghridN/x8sk5c6PHLqr9RIpSSyltc3cgQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kvack.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=ugMn6oKEOjYHvg+0JhztaCK4sS5GJrjKq1+zAszikv8=;
 b=LRWnoAS4upeeqL+XK9H58yDq9mFd29Y2NQngw/n+OEZPL+N1SnAEkE/sen2AJjWkWc9ruuBwGNFxZrS3MDQ8znmb2CO6uFZE5xnspfAuzDHYyWB70dLkGtn08MZG8ga6JLfGTeArH4pnEbzSV7qpDd/bLJUdEo7nV1r6jroJL7c=
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=PNcXir66EFUivE5clc5Kj8Y9Rz+0DWm/A373kSs+iebfIc9rr25ByZJhBpdgff8TZ4DtCeMF/P02kCpoGKMcQf28fAIruQOKw0LV5Wf8GRJ7ViAJBmWh/NnqxsjVhk+N9cobDfTdB+VuMGeuobntNZqEYh6Lm4hCndJh2EHLDseZzwf2XI77Y4cKjzCTdwJosS0BSHP77cm5fR6dG1eGOXSatEYOarp8g+I1IzLo1Ce9vVmDREyP/9HJCiliAt/5O0rtGpbMtw3nY+eh4SVyGMyYSLxBY57mZ3l7QWJlgJLeVqiMsvZ5o94eQqDYJRDiUQw8WwUeTTKHmoIi9WgkUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ugMn6oKEOjYHvg+0JhztaCK4sS5GJrjKq1+zAszikv8=;
 b=s74UxJYBgmpT9hChaomY4S8CEYa+GSCxLK0kH7cYwU9MFQO2o9y+yVNp2IUhMO+rS/Q/LsbkZG/3AYeef8v7IAG1o+j0mUOHwX4MWJnJ2u/QfJKpe8bjS3Ev/CW+f3ISZZWVCSSnrZFKGXDUTN2yR8FEb9LbIgfHsSjOOviYnwmukiRSxXgxVUx6q/Mm45xd0QAX3bcP7PisrIt1EUVCouZjM8kFvKmwmnLuWbJINHZbkSJIlNmGAVt7z7ZN2GhfK6VKx6fvpvG0zfn2LEY/py/KXP5M4ZohDN2u1j0Wl+nD9HADmvp47zzKrs/agXfJ/qWldIC74iDL0rUnr1GW+A==
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=ugMn6oKEOjYHvg+0JhztaCK4sS5GJrjKq1+zAszikv8=;
 b=LRWnoAS4upeeqL+XK9H58yDq9mFd29Y2NQngw/n+OEZPL+N1SnAEkE/sen2AJjWkWc9ruuBwGNFxZrS3MDQ8znmb2CO6uFZE5xnspfAuzDHYyWB70dLkGtn08MZG8ga6JLfGTeArH4pnEbzSV7qpDd/bLJUdEo7nV1r6jroJL7c=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Date: Thu, 4 Sep 2025 16:06:33 +0100
From: Yeoreum Yun 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-3-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250904125736.3918646-3-kevin.brodsky@arm.com>
X-ClientProxiedBy: LO4P123CA0125.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:192::22) To GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	GV1PR08MB10521:EE_|GV2PR08MB7931:EE_|AMS1EPF00000049:EE_|AS8PR08MB8707:EE_
X-MS-Office365-Filtering-Correlation-Id: 733721fb-8f1d-4d71-3e22-08ddebc4b9f6
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|7416014|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?HI9BmywBGI+n6E5v4HCTATtyI6GatboYoOMoqPuBaCSmw2JJ27VT9Hohu+iA?=
 =?us-ascii?Q?Q8/p6GDZTO/IepPkUFwqphXLyK5aoufFTG1QN++6L+WOMSaJ7cEepXvA5MW6?=
 =?us-ascii?Q?/ybcrsoZ/FXa8rotI3lJ7/f8Q5HHrg3T6Mh825cNgtV1aOk0WfddyBo9rRXz?=
 =?us-ascii?Q?dWTt7TzuqAFrMkoUvGVt96fmn6k1S4G/x7TC66zzXYWBVqDj7wJfBTP3y8bb?=
 =?us-ascii?Q?Y6zOIuJVdakxZD9HxQO2SUUXIUlsYL2tBM5HJ47yJhPMfauz3tthSy3fWEvA?=
 =?us-ascii?Q?5q61/g4tIaLZT9F0hWOJ+WCsTl7z4BFAyNIzWKInkXiDTrDgCqbneiUcGQ2O?=
 =?us-ascii?Q?jZq3B3b9Zo/qaJ+GFtYVJ2YUrTB4wgiVC09Zasg5AfHMmO57CV3QS89aFlcz?=
 =?us-ascii?Q?ESKIImLmQN6uf8ykJOVpsy1lP6jBLuI3GDlskuFCXWWbvUWWViTwGmJ8aPbg?=
 =?us-ascii?Q?L2wHIokcPh/qrZPgJncOdMSIHL0Rf08j4d0EDCVV9Auv7h0ZeOIULc//6RhD?=
 =?us-ascii?Q?p8dLnv9AY4+/ua3MzHbwKhDgVNf5ccJSnVg7+nr88JdMclEQZxgINb9ele2I?=
 =?us-ascii?Q?nMUf1URSoGbLZyZ4+20qKlCYmEjIvEwOm6NFG6ezyYWTLNy38+qvXvokCIh9?=
 =?us-ascii?Q?o00oQKPE3YOSK1rDGv5ru+gKPqpMHkPWPAR/fPTxpw1fGnHivtlojfS00aG9?=
 =?us-ascii?Q?Afee/XrPFJ37loCXrXtRtvv9NL4cEKGOFgc3vS8phYsBYzWgst2MTAm7lfpg?=
 =?us-ascii?Q?dlG+F0i5DZ2JyK0wxSkheteJh13Pc1dG6IW4UjwfDAZbFsiyMM33YzS0hDka?=
 =?us-ascii?Q?IgXziV6gP1kw4twNXhbSbPo98i5xX/06VIRE1nkFF/bDRrL9b2H+5ERKwoQM?=
 =?us-ascii?Q?5e7m19ADpEckviOHaiWsOJJ24tpPL6iYchnCOqlBlcamC5X8kro7jn0OTgHE?=
 =?us-ascii?Q?HBNv2xdUpanMy/kT3LocGK8uvpJIQ00xnLulN70MQ/ZLVIRIBP2PrQkF54Fg?=
 =?us-ascii?Q?Yy+f47p1p7FmyS24iCckAGmzDzcBEH1uCfJOvGxbNGmFdzwrB8YhVIHUaxsr?=
 =?us-ascii?Q?Pc03p+WP9rW2pDwNRlkCr7BW8pfVH/HhxVU1yC7yBPzLqX00t8NxZ4YEVmEg?=
 =?us-ascii?Q?ylYKqX8mreruUT0hGzdRofWu5pbQGDckTglgEa2LEyhiPGHwTfV55/sfxhOZ?=
 =?us-ascii?Q?+Bfx+s46Dg87A/cRUUaz/5TnAktt/g1bwIGzG1t+qShv6eRl6JsgZJC63Y/H?=
 =?us-ascii?Q?l+1kbTCvw1YUfkZe7FH4k5cJcd/ShHLKK1W8rZFGtxPjeih14Il6DlQjH2Vv?=
 =?us-ascii?Q?lE9U+DOikJP7YrEcpm6NCXdSN+e4LscaVxlA6KkkaSS5GCs/tSbBXJKJHkGM?=
 =?us-ascii?Q?bEn5qkoQWv31I8ElhVy9g9ljYipcT/X8nmKr3kKEQQte9LK0lUF68yv3ubp5?=
 =?us-ascii?Q?RUIl/DLS/+Y=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR08MB10521.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB7931
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF00000049.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	94765155-63eb-44c6-8cee-08ddebc4a4dd
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|14060799003|82310400026|35042699022|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?+jyVZRQaCFISNpIDYoLrLGIy5S3t01y85fxSI5EcZRsEUSaB8AUX2gNcb4Fv?=
 =?us-ascii?Q?g4ObXTrD+QP9TolZX8IdLjx4mBrVcdrwpjA7yqhBKrx4XepJdPVYGj4XZ/gg?=
 =?us-ascii?Q?bvCRMTFjvyKhuV7Qu5eWD6yEZkhcee2QvLazYptS03wIdFCKwPhCnGWE/igx?=
 =?us-ascii?Q?X+L1xdGg037FFc+TzlHm72TJcayIqeP7g2wC1KO8Q0FmlNDd+Msj4biuX1Hz?=
 =?us-ascii?Q?9MEyO0B3n7VFL+r4FK0toKX+pmqO9lzCoWNeV3DqRkkkMcLfWk3apJfWTu11?=
 =?us-ascii?Q?maq37/Gdf+Mgd9E4E3vI57aVv3E3Z1uVcdeHxZ0LJU9aBTC1n/mx77ug6MxS?=
 =?us-ascii?Q?YhHZ1k6+UXUfB81UzBKiRV6y0UjgOq/ZzeZBmX5vr9YzMNW/ih3JYM65Nsrh?=
 =?us-ascii?Q?gAnQi8DR12m6NXvOdM6HSreta6lK8JHLgCTeCGvyd4inq4yx33I8HnuvIKNO?=
 =?us-ascii?Q?h1PJyg83pW5Xxq6XonyAQyGaPCVwBc7xA3Jriu4LhVO2LQlOoI6HLmR0ilzF?=
 =?us-ascii?Q?wNOEceme3dmS9xj3S1k4sCgjHOrRcj/rWPdkD5hNfE6dTNIHEHSuklktNVM8?=
 =?us-ascii?Q?NMrJKmWBGj9URUktULMMziOZAJqVuVdGNPyNfhZBnhGR3cjIkipHco22kDR7?=
 =?us-ascii?Q?IVErC0uxwMCxhUy7jVytiyH4OP2A2qZ8b4SXR/+Nj0vWpcP4dEgNILXILkEB?=
 =?us-ascii?Q?U/91TFpS/WmopxItWEqRXgPGZMw9EK7YsCK+dCxzZQBouOIj0qOlb56aYAMN?=
 =?us-ascii?Q?VfOnMzOf2CRoXBhUmSJ21Ye22xr4xPhJOJsDnjC4AlPgl/fwCPZ+PWprIalG?=
 =?us-ascii?Q?IXmbs3saq+0iZ/Xg9qFFq6hN/r8uUdUQOTblzEzx0Qnil20KihMD9ccMyv4e?=
 =?us-ascii?Q?7UyIiohAvTb593pW/tMFUlDNOh+wzaTMvz5GDzfoCxIzqQ+XSOkD3h51T+NT?=
 =?us-ascii?Q?CKRMjzOab1ipT+aRR/qydM01qiEbR8n/thAG4uq+LeSCZMQeSWZaQ1Ivb8JB?=
 =?us-ascii?Q?dJfKqJEV9K0C7sXf/BK7brj4Nt6DwzBQKYq/Bg/ylHPLo7jCdFiOSFS7hKBr?=
 =?us-ascii?Q?N54+wbBg3TL2yuY4VxOgOJnIHke4kjHBXE9lSC3QFULU+gjPaZ4SREsbsVjg?=
 =?us-ascii?Q?7BFoICmBihDX8fSRX/fF2h2YL6oyKB+DxYQI8wGRKwMoJr7Wv3wPFzQKRFR0?=
 =?us-ascii?Q?CC1PCcLBoSNdU5kvRqeS5k8jN78CDTEjLX+Uyy+NEn2Ze1lSkYF/XT1QVeYH?=
 =?us-ascii?Q?lHB0de9zuckX1aY+WJIbfDZ1TYhWTAVuahbu12N+F+AudRK15iUUBdFNGkub?=
 =?us-ascii?Q?bxHzoVHtKvL2ERJqP+T424MJ9GLEeFkGZ21f77rZGsI9xm4Brq4wnqKVnUEL?=
 =?us-ascii?Q?mvt3i5mmUG1OOlL3Wl4WawjuKoYo6rKr/Z2Y0oXiZMZDXGmrIjJQeWzhiIat?=
 =?us-ascii?Q?NlS+0364npsWTqv/ZUJzq0oQbb7LmUWI8aOYmvUODXcWnlPL5UqxwmIhb0iv?=
 =?us-ascii?Q?9T0pp8IbuR0Q4DL9DMWgfrvtSOV4bWSOHlen?=
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)(14060799003)(82310400026)(35042699022)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2025 15:07:12.1297
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 733721fb-8f1d-4d71-3e22-08ddebc4b9f6
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:
	AMS1EPF00000049.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8707

Hi Kevin,

[...]
> Signed-off-by: Kevin Brodsky 
> ---
>  arch/arm64/include/asm/pgtable.h              | 10 +++++++---
>  .../include/asm/book3s/64/tlbflush-hash.h     |  9 ++++++---
>  arch/powerpc/mm/book3s64/hash_tlb.c           | 10 ++++++----
>  arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +++--
>  arch/sparc/include/asm/tlbflush_64.h          |  5 +++--
>  arch/sparc/mm/tlb.c                           |  6 ++++--
>  arch/x86/include/asm/paravirt.h               |  6 ++++--
>  arch/x86/include/asm/paravirt_types.h         |  2 ++
>  arch/x86/xen/enlighten_pv.c                   |  2 +-
>  arch/x86/xen/mmu_pv.c                         |  2 +-
>  fs/proc/task_mmu.c                            |  5 +++--
>  include/linux/mm_types.h                      |  3 +++
>  include/linux/pgtable.h                       |  6 ++++--
>  mm/madvise.c                                  | 20 ++++++++++---------
>  mm/memory.c                                   | 20 +++++++++++--------
>  mm/migrate_device.c                           |  5 +++--
>  mm/mprotect.c                                 |  5 +++--
>  mm/mremap.c                                   |  5 +++--
>  mm/vmalloc.c                                  | 15 ++++++++------
>  mm/vmscan.c                                   | 15 ++++++++------
>  20 files changed, 97 insertions(+), 59 deletions(-)

I think you miss the mm/kasan/shadow.c

But here, the usage is like:

static int kasan_populate_vmalloc_pte()
{
	...
	arch_leave_lazy_mmu_mode();
	...
	arch_enter_lazy_mmu_mode();
	...
}

Might be you can call the arch_leave_lazy_mmu_mode() with LAZY_MMU_DEFAULT
in here since I think kasan_populate_vmalloc_pte() wouldn't be called
nestly.

[...]

Thanks.

--
Sincerely,
Yeoreum Yun


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 19:59:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 19:59:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112346.1460655 (Exim 4.92)
	(envelope-from )
	id 1uucaS-00024g-J3; Fri, 05 Sep 2025 19:59:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112346.1460655; Fri, 05 Sep 2025 19: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 1uucaS-00024Z-Fs; Fri, 05 Sep 2025 19:59:08 +0000
Received: by outflank-mailman (input) for mailman id 1112346;
 Fri, 05 Sep 2025 19:59: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 1uucaR-00024T-8p
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 19:59:07 +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 c3324319-8a92-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 21:59:00 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfhigh.phl.internal (Postfix) with ESMTP id D82F714000F2;
 Fri,  5 Sep 2025 15:58:58 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Fri, 05 Sep 2025 15:58:58 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 5 Sep 2025 15:58:56 -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: c3324319-8a92-11f0-9809-7dc792cee155
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=1757102338;
	 x=1757188738; bh=yqI0DkiqFignuWCWjqEs7djqwvdCihcKW6BCeRfMemY=; b=
	lVsT1dbQxPAmU0PnRd037Y7yEOIfwQUN2cyapOy016wlF2uTxawI4DKE3feQsz0P
	4yMaBXmzPsoLsRNjZBq9KaYPxUf+gDWsyoR4zBlsAJX/N7HWaT4/l0d0yEbsn5jz
	VWZglElSv27z8QsSuKLz1bjUGZ8gqtZdrDgtNo0/VdZuTmhKYtl9P0b8kzuNi+wO
	0GaRVGNnUMJYeDwsC4ocXRKVVMX7DbGDaiZZZx3ljFi8qYQz1a2KRydFbiutniaG
	saewg+3vzN1KxqysbR4dOQtevreYGuKUGoyT1wVXbzt0heT/6MEZxsDx9QGKEnxv
	NXLbzeoM2JurgaFXVYAlHQ==
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=
	1757102338; x=1757188738; bh=yqI0DkiqFignuWCWjqEs7djqwvdCihcKW6B
	CeRfMemY=; b=RrEYRdMr1eqf7PxQi3iJv8Icm5HtRKBHiGo4/7KQzxZQGjTKwSs
	roZE5f8djtv1X1l4GXElkpOUv53MscDrEYD4xC+33QqKIqOe6QPeDq/M5fHmt+6H
	59r47etlq9wgm1QUG6jF4ux/+KAKrx9PgBF71euwvpjp1hV6lIQ9mcANgTmnmKkm
	I9YgPGiqGbu29WSfAO4Q9nqY2MZvHS8ckxtOp7GDc6PiYts50wRSyMaqI7Hw1GBL
	b8Na6UCsd91gimibYSqfFcx0o37UYuQtJ5tSspNo+Y8SFCI3r1e4yUPrxU/Iac+l
	UZVcGBNRyiHxN1rjmesZ9rqemXa0AHiUpDw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeljeelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddupdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhs
    segtlhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi
    gvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprhhoshhsrdhlrghgvghrfigrlhhl
    segtihhtrhhigidrtghomhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhssh
    holhhuthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgt
    ohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomh
    dprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhr
    tghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjh
    hulhhivghnseigvghnrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 5 Sep 2025 21:58:54 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	Ross Lagerwall ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
Message-ID: 
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="A/iiYqqFR0gfBTD0"
Content-Disposition: inline
In-Reply-To: <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>


--A/iiYqqFR0gfBTD0
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Sep 2025 21:58:54 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	Ross Lagerwall ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled

On Fri, Sep 05, 2025 at 12:10:17PM +0000, Gerald Elder-Vass wrote:
> From: Ross Lagerwall 
>=20
> Also cache it to avoid needing to repeatedly ask the firmware.
>=20
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Gerald Elder-Vass 

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

> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monn=C3=A9" 
> CC: Stefano Stabellini 
>=20
> v4:
> - Fix MISRA warning regarding SecureBoot string
> v3:
> - Fix build on ARM
> ---
>  xen/common/efi/boot.c    | 24 ++++++++++++++++++++++++
>  xen/common/efi/runtime.c |  1 +
>  xen/include/xen/efi.h    |  2 ++
>  3 files changed, 27 insertions(+)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e12fa1a7ec04..ccbfc401f7ba 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
>                     " last line will be ignored.\r\n");
>  }
> =20
> +static void __init init_secure_boot_mode(void)
> +{
> +    static EFI_GUID __initdata gv_uuid =3D EFI_GLOBAL_VARIABLE;
> +    static CHAR16 __initdata str_SecureBoot[] =3D L"SecureBoot";
> +    EFI_STATUS status;
> +    uint8_t data =3D 0;
> +    UINTN size =3D sizeof(data);
> +    UINT32 attr =3D 0;
> +
> +    status =3D efi_rs->GetVariable(str_SecureBoot, &gv_uuid, &attr, &siz=
e, &data);
> +
> +    if ( status =3D=3D EFI_NOT_FOUND ||
> +         (status =3D=3D EFI_SUCCESS &&
> +          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RU=
NTIME_ACCESS) &&

FYI, I was unsure if checking this is a good idea, but UEFI spec does
define exactly those attributes for the "SecureBoot" variable, so it
sounds okay.

> +          size =3D=3D 1 && data =3D=3D 0) )
> +        /* Platform does not support Secure Boot or it's disabled. */
> +        efi_secure_boot =3D false;
> +    else
> +        /* Everything else play it safe and assume enabled. */
> +        efi_secure_boot =3D true;
> +}
> +
>  static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *Sy=
stemTable)
>  {
>      efi_ih =3D ImageHandle;
> @@ -915,6 +937,8 @@ static void __init efi_init(EFI_HANDLE ImageHandle, E=
FI_SYSTEM_TABLE *SystemTabl
> =20
>      StdOut =3D SystemTable->ConOut;
>      StdErr =3D SystemTable->StdErr ?: StdOut;
> +
> +    init_secure_boot_mode();
>  }
> =20
>  static void __init efi_console_set_mode(void)
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index 42386c6bde42..30d649ca5c1b 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -41,6 +41,7 @@ void efi_rs_leave(struct efi_rs_state *state);
>  unsigned int __read_mostly efi_num_ct;
>  const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
> =20
> +bool __ro_after_init efi_secure_boot;
>  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 623ed2ccdf31..723cb8085270 100644
> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -36,6 +36,8 @@ static inline bool efi_enabled(unsigned int feature)
>  }
>  #endif
> =20
> +extern bool efi_secure_boot;
> +
>  void efi_init_memory(void);
>  bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
>  bool efi_rs_using_pgtables(void);
> --=20
> 2.47.3
>=20

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi7QP4ACgkQ24/THMrX
1ywnnAf/ctBMx4R4WhP9RCPd7wtaG8d6QE7/TzYXF/KL2C1p94RfhFiyD/kut9xD
PJd3R4DShlJljr44nURCdA0dBt4hUpV5Kt2dQ0M+VHT4oZkAH0D9b/hgRgWQDzJy
sQSzgi21MNAKkctGNIEKGDAoxCa9PJzaRMlry7stAEy5mH09pBj/2MUXewq4Fy5/
sCH+1c2/v2Kau7ecpPpM0VlU4yBzHKfRpNhz05VY9xp/QXzzcPxUrzw6Mte5qpiq
rSRBD5SKxNQ/EuGQ5gi8baaChtq5E/hM6JKTLgiA8UmtEdZu3nP266GPm2YjBofq
19farN4c+W7kQqwWiStMKHWrM/oHEA==
=b7bR
-----END PGP SIGNATURE-----

--A/iiYqqFR0gfBTD0--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 20:03:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 20:03:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112357.1460665 (Exim 4.92)
	(envelope-from )
	id 1uuceR-0003is-1s; Fri, 05 Sep 2025 20:03:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112357.1460665; Fri, 05 Sep 2025 20:03: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 1uuceQ-0003il-Uz; Fri, 05 Sep 2025 20:03:14 +0000
Received: by outflank-mailman (input) for mailman id 1112357;
 Fri, 05 Sep 2025 20:03: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 1uuceP-0003if-VK
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 20:03:13 +0000
Received: from fhigh-a8-smtp.messagingengine.com
 (fhigh-a8-smtp.messagingengine.com [103.168.172.159])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 59e17d9b-8a93-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 22:03:12 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 17AA21400166;
 Fri,  5 Sep 2025 16:03:12 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Fri, 05 Sep 2025 16:03:12 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 5 Sep 2025 16:03: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: 59e17d9b-8a93-11f0-9d12-b5c5bf9af7f9
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=1757102592;
	 x=1757188992; bh=yTJmYk2jAFBxEe0tEVUQwPU5zQxCRQdlLX4xJPUKZ6A=; b=
	LeVWsQp6yrQ+6Hxzq8fZV6CPhoE+XFPBSo0TFdemCmtunjz2lZKAJHgmnCnSB/N7
	AsQx9SwoINwZKaKnvOjlF/WUs1UbAkwTtmBmll0uzs11ed+6/b/S5dJhvPKG5scO
	wrTKUwxdstLZz3NjdEQKOycmNlgoOilc52BI0GfeLDlkzCzRwU1kpWsGNma+V1cY
	i933SIvx0gDKXIstIF5YvklT6AT4QjS/7yf3dPjyKU0JRDcz9Drco39qOzYA3LeZ
	XkQPnAbULidFVhwGcaGE3FKQk3jwQrwJ3YQ+4z/W0P6Yqyna1iIeoNFoNf7IxYy1
	IuK6rY52gUsssozWXciU+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=
	1757102592; x=1757188992; bh=yTJmYk2jAFBxEe0tEVUQwPU5zQxCRQdlLX4
	xJPUKZ6A=; b=FhRgkFt8a1tIs2VxJAm6UgeXZdBtOcCwnhFR4VW1TknlgawEB8d
	Rk/yTZ5uUhqr764wHznvqNThwCSkrWtjh4dyS8XP62WekAc/Yp+x21Ie5AfS35hJ
	/4ht4MTsgrPCQaeersq2LYgzVoGz/Dp0B07gHeOlp+mikOUTZxxlzY0endvG0RiX
	CTeE/og36PpMN53EZ9hPdgN2c7ViSiy9RW0dZXOFZXYzpGzKl3TxsLl+HsoHDiv6
	a0QrmI7bkbNo7TiPk9BZzIzNfRJNJtuY6iUoqeDnfob037EMK2Dh6zizqpFuS6YJ
	v/iDcf4uYp6u97RWtOExa97yu/Vvwe/97vQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdelkedtucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddupdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhs
    segtlhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi
    gvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepkhgvvhhinhdrlhgrmhhpihhssegt
    lhhouhgurdgtohhmpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluh
    htihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdp
    rhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtg
    hpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphht
    thhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhopehjuhhlih
    gvnhesgigvnhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 5 Sep 2025 22:03:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	Kevin Lampis ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v4 2/2] efi: Support using Shim's LoadImage protocol
Message-ID: 
References: 
 <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="DFPUPugwv6mACCPu"
Content-Disposition: inline
In-Reply-To: <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@cloud.com>


--DFPUPugwv6mACCPu
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Sep 2025 22:03:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	Kevin Lampis ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v4 2/2] efi: Support using Shim's LoadImage protocol

On Fri, Sep 05, 2025 at 12:10:18PM +0000, Gerald Elder-Vass wrote:
> The existing Verify functionality of the Shim lock protocol is
> deprecated and will be removed, the alternative it to use the LoadImage
> interface to perform the verification.
>=20
> When the loading is successful we won't be using the newly loaded image
> (as of yet) so we must then immediately unload the image to clean up.
>=20
> If the LoadImage protocol isn't available then fall back to the Shim
> Lock (Verify) interface.
>=20
> Log when the kernel is not verified and fail if this occurs
> when secure boot mode is enabled.
>=20
> Signed-off-by: Gerald Elder-Vass 
> Signed-off-by: Kevin Lampis 


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

Preferably with comment adjustment as suggested by Andrew.

> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monn=C3=A9" 
> CC: Stefano Stabellini 
>=20
> v4:
> - Updated error message when failing due to lack of verification
>=20
> v3:
> - Use Shim Image by default, fall back to Shim Lock
> ---
>  xen/common/efi/boot.c | 59 +++++++++++++++++++++++++++++++++++++------
>  1 file changed, 51 insertions(+), 8 deletions(-)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index ccbfc401f7ba..0a72c293301d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -38,6 +38,8 @@
>    { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0x=
e3, 0x94} }
>  #define SHIM_LOCK_PROTOCOL_GUID \
>    { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x=
8b, 0x23} }
> +#define SHIM_IMAGE_LOADER_GUID \
> +  { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x=
55, 0xab} }
>  #define APPLE_PROPERTIES_PROTOCOL_GUID \
>    { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x=
3a, 0xe0} }
>  #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
> @@ -70,6 +72,13 @@ typedef struct {
>      EFI_SHIM_LOCK_VERIFY Verify;
>  } EFI_SHIM_LOCK_PROTOCOL;
> =20
> +typedef struct _SHIM_IMAGE_LOADER {
> +    EFI_IMAGE_LOAD LoadImage;
> +    EFI_IMAGE_START StartImage;
> +    EFI_EXIT Exit;
> +    EFI_IMAGE_UNLOAD UnloadImage;
> +} SHIM_IMAGE_LOADER;
> +
>  struct _EFI_APPLE_PROPERTIES;
> =20
>  typedef EFI_STATUS
> @@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS=
_OUTPUT_PROTOCOL *gop,
>      return gop_mode;
>  }
> =20
> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> +{
> +    static EFI_GUID __initdata shim_image_guid =3D SHIM_IMAGE_LOADER_GUI=
D;
> +    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_GUI=
D;
> +    SHIM_IMAGE_LOADER *shim_loader;
> +    EFI_HANDLE loaded_kernel;
> +    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> +    EFI_STATUS status;
> +    bool verified =3D false;
> +
> +    /* Look for LoadImage first */
> +    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
> +                                           (void **)&shim_loader)) )
> +    {
> +        status =3D shim_loader->LoadImage(false, ImageHandle, NULL,
> +                                        (void *)kernel.ptr, kernel.size,
> +                                        &loaded_kernel);
> +        if ( !EFI_ERROR(status) )
> +            verified =3D true;
> +
> +        /* LoadImage performed verification, now clean up with UnloadIma=
ge */
> +        shim_loader->UnloadImage(loaded_kernel);
> +    }
> +
> +    /* else fall back to Shim Lock */
> +    if ( !verified &&
> +         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> +                                           (void **)&shim_lock)) &&
> +         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
> +        verified =3D true;
> +
> +    if ( !verified )
> +    {
> +        PrintStr(L"Kernel was not verified\n");
> +
> +        if ( efi_secure_boot )
> +            blexit(L"Refusing to boot unverified kernel with UEFI Secure=
Boot enabled");
> +    }
> +}
> +
>  static void __init efi_tables(void)
>  {
>      unsigned int i;
> @@ -1334,13 +1383,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE =
ImageHandle,
>                                        EFI_SYSTEM_TABLE *SystemTable)
>  {
>      static EFI_GUID __initdata loaded_image_guid =3D LOADED_IMAGE_PROTOC=
OL;
> -    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_GUI=
D;
>      EFI_LOADED_IMAGE *loaded_image;
>      EFI_STATUS status;
>      unsigned int i;
>      CHAR16 *file_name, *cfg_file_name =3D NULL, *options =3D NULL;
>      UINTN gop_mode =3D ~0;
> -    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop =3D NULL;
>      union string section =3D { NULL }, name;
>      bool base_video =3D false;
> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE I=
mageHandle,
>       * device tree through the efi_check_dt_boot function, in this stage
>       * 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 )
> -        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
> +    if ( kernel.ptr && !kernel_verified )
> +        efi_verify_kernel(ImageHandle);
> =20
>      efi_arch_edd();
> =20
> --=20
> 2.47.3
>=20

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi7QfwACgkQ24/THMrX
1ywdpgf+MwRbdFKr4yxFkRsX6My6MtYx7RtTm3q9euEz+yyj6V0Ua3y7j0FC9s97
fuUeiIHqTDAXWL2aELUTTgQXAHGuqk2xlbKBu0cHoo2wVy7kqtm5FKgGb/rqEk00
TGWy4d+FpmgwM+M+PZx7JK4Ql2PIrfD2Lzgw9EpLIH0rbxSIESJ5ZGdB5zeHuBCx
FbDBuPWSy4M9bwAfP2V86MNdAUWjVa9dfG75Fk0Oddvnfms+ERDW59YeqtI6Huxo
N8TuwOUgiDblI7a+xi1WVxXdkY+J9HLvUFIhv7DlW06dlDmdc7mgS/H4VB8ouSFV
t/pWEvDGOP70c66gTOXLhJZtA1ffZg==
=2FuS
-----END PGP SIGNATURE-----

--DFPUPugwv6mACCPu--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 20:35:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 20:35:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112387.1460675 (Exim 4.92)
	(envelope-from )
	id 1uud94-0007k8-AP; Fri, 05 Sep 2025 20:34:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112387.1460675; Fri, 05 Sep 2025 20:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uud94-0007k1-7Y; Fri, 05 Sep 2025 20:34:54 +0000
Received: by outflank-mailman (input) for mailman id 1112387;
 Fri, 05 Sep 2025 20:34:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uud93-0007jv-MT
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 20:34:53 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2412::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c2a04292-8a97-11f0-9809-7dc792cee155;
 Fri, 05 Sep 2025 22:34:47 +0200 (CEST)
Received: from BN9PR03CA0716.namprd03.prod.outlook.com (2603:10b6:408:ef::31)
 by DS0PR12MB8218.namprd12.prod.outlook.com (2603:10b6:8:f2::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 5 Sep
 2025 20:34:38 +0000
Received: from BL02EPF0001A108.namprd05.prod.outlook.com
 (2603:10b6:408:ef:cafe::8a) by BN9PR03CA0716.outlook.office365.com
 (2603:10b6:408:ef::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.20 via Frontend Transport; Fri,
 5 Sep 2025 20:34:38 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A108.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.9094.14 via Frontend Transport; Fri, 5 Sep 2025 20:34:38 +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, 5 Sep
 2025 15:34:37 -0500
Received: from [172.31.134.167] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 5 Sep 2025 15:34: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: c2a04292-8a97-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=chK6wPY/LmsWa33NJA5hoy5dryqTW5HjaIYVtmuFkJqWC3bg4fsA7dQBiOphIhgYqW/NrryuQiMFKsUPyaUwnO9qXimmUnk1RECHy+gkAKTeM5LmLC9EX2oifvAeAP9JafUDVAoaqfBzG4TFE3RqVOE5PAvOeA0Ca5Z8HliiAj9KAPH4hY7XQjCr7FdkAFTouaBcTy5ODS8JUUVvYn6IkVyqhVz6mkscoM3SXF7S/05KeNeO/vbUjdnFmtBwmZPpr7N3A0BwmINbDdLY4+VmDX2cN/H5PQa9Bm/pb+UT1LBkglJb39Yk4/uLX69qCy78l//VULw05sDcp8CxWIhJCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yXR19HnIZvKmkNP3t9Sh2qCcg+esTHU0+stLKmvAasM=;
 b=FZQ8wnGc5z3t4BxZWfHKX5x50XJvSlYejtAvsJVyw8GAMM+ffTs/PDrBoJq1rGXZAt0kOi2F24g4qeMqW2fOxRfuowTkas3xRSyy/xWWAWKeGRkCpv0kq4X9rs74zygY3QMQrafUfaoVLQkIQEQrd1IRXx3IaT3aWGSUjsAYxNFpXWhTauL4V/9pyV49eUMHFiBi+ZMG+llIIpwq5wghzNeVqENENSGYXQbdzIHHE3l3IB71/M44koyVWEYeGfk/lTS/K6w+xSDwp0pq6szKLIjDNVAsf9CySVF2QZL/JrhOEfD3tQmVIdS3lgoKyr5pOCgMypL2nYixvRwH3zyZOA==
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=yXR19HnIZvKmkNP3t9Sh2qCcg+esTHU0+stLKmvAasM=;
 b=jnpgQmfOAIba6oOTIbg6qBt6MFKghiLE2v+TctCJA1oftC6XSHPZrV3WXT+We6pWxn3OA0gWxPBWF39A02u0yjG7c1Nwi7A/s2FAVAaKIBoiZwibcyt/V2ngq7vV9VDy2Y8upp7F9IueS46lbDdLbaRIOMcaikdd8tQdXnUgJOU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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, 5 Sep 2025 16:34:32 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/apic: Avoid infinite loop in
 io_apic_level_ack_pending()
To: Jan Beulich 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	
References: <20250904215137.135529-1-jason.andryuk@amd.com>
 <57fedb53-18b7-4d81-acc8-2756a899ef90@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <57fedb53-18b7-4d81-acc8-2756a899ef90@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: BL02EPF0001A108:EE_|DS0PR12MB8218:EE_
X-MS-Office365-Filtering-Correlation-Id: 75620421-e07e-4b9e-4cc6-08ddecbba25d
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?Y1RCWHZUNlREM0Y5K254d1o4dHc0UENnY0oxWU5kejhtZUN4OHNVQUlMSWMx?=
 =?utf-8?B?QkpnU2JSallXVFJydUZBUUIxNlRPZ01xSUlJUGxHNjRlcHFyTlFLUFVSSmww?=
 =?utf-8?B?YTZWVE8vTXRaaFN4MDBER3g2c2dNYis1MUxjUTh1K1VkSU9RK1hsczRNODFv?=
 =?utf-8?B?cVRzeUVpNDVXY1VmOG51clhUbXlqNUp3aDFCTms5SUZjOVF6bVYwMHV2cDRl?=
 =?utf-8?B?MXoybUZSUVByNDZiek1TeVlZUEs2T2ptSWduQ2E3bmdnNzlYa01XaCtEYVBF?=
 =?utf-8?B?WE45S25sNCtUWU1CdkVMdDdhejdPL3UxN1luTjlwdTBmRUZMV3luYWdXT0F3?=
 =?utf-8?B?R05aMktkb0N2L3Q5aCszSGNPS3dIUHl4a2xYWUdyczloOVRyNTJZY0Vhbk1P?=
 =?utf-8?B?YWFpVzhOK2NlYVNoTjEvWVd6Z2EwalZJVktDWVNQYmJFSHFidEVKMmZWYnRP?=
 =?utf-8?B?ZkVqZ1FKU0pFdlNGODJFd3IwcmFWRjB2Z1Q5eVZHOFRBa0FuNEpBazY0bEox?=
 =?utf-8?B?UnF0aUYyc1lwQ0JTNksyUGxBSmhhWmZQbjh6SWw5YjFGTndIVkd1dHBjUSt4?=
 =?utf-8?B?SFlVR0lEbjFaWHQ3ZkJ6OWEwRWFPd1QvNVBDdVFrUWNLTE9GSXFjeWFDS0hL?=
 =?utf-8?B?UlNwbFV2Sk1xdFZIcWlaenBxenJLcCt1Y1RSZ3pkZTc1dTVlTm0rb1RGbktB?=
 =?utf-8?B?OE5sMnFFOVNMbklwWndaQjFHYldqZzVCeFUxN3FPY3VGaXZWTndEaGQvcGlv?=
 =?utf-8?B?WCtkMmZaRWRLUVlaOXVQbmxxeGlGZ2N5OHV3eEhScWg3bk5IdFJoWWkxNUdO?=
 =?utf-8?B?aVZZWkV3R2hXa3RLeUJ3cUk4VVlPbGxHc28ybXZWS0Rxa3ZJTVduTWVJVGlJ?=
 =?utf-8?B?S3RPbEh4ZEVQZlZaa24zLzR1aDFmalNiVkpoNVR6REtuZVFjaktlYkVsdVVv?=
 =?utf-8?B?QUxzeklUVEhMVk8zbHphT2VaVnJIV0Z3SzgwMVl6QXU4YlhyUVkwL0hxeklQ?=
 =?utf-8?B?WVpCQk9HODdHQWRYVWg2NFE0bnErVzN0a3lBVGE5S244K2J4RGY2ZjMwRjRK?=
 =?utf-8?B?Nmw3ZUVzY1ZYK1I2MUhPRGt6U1lPOTlUa1BnbFNhRTlTL2JFcjhqSEFiLzM4?=
 =?utf-8?B?YTBGTVpRY3lhUlBxbXkzdFZaM1ZDaWJDUktJNGV6L1k4cjU0eFE3cWQ2K3JY?=
 =?utf-8?B?Sm9vUGM5TkFPM2Q4eTFKejEyemJBYjhqTlBONFl0bEMrM0tEWG5jK20yZDJu?=
 =?utf-8?B?TzhpbVU3MUJudUNqakJzc3FPSHIwUjJBV2hmd1NmemR3SXJHWHFhZW5qRHNr?=
 =?utf-8?B?SmlyVktCRHJMa2F2LzRGRHpBSzFTOEVkVjFSTWZkTVgrbHVSRTZPQjgrby84?=
 =?utf-8?B?MGtOOS9aZVVyZGd0YUxWVEhscmh6NUU4ZjRCQ2duc1ZIVWtadmt4TmtzNzBK?=
 =?utf-8?B?Q0FzbDZJMmh0VytaTjVoWnhqdk9vRkEyUWpPdmI0STliMUVsK2NFemJhMUlq?=
 =?utf-8?B?ZkZPQUFwait0aUlJZ0FZaVpBeiszV21qaGRBRXdSUHQ3VEp5WXNWQzczbS9t?=
 =?utf-8?B?MWVDNG0vU204M3VTYjdUK2JlVFhmY1NPdTJPNENqOEovRkRpNkM3MEJoN21K?=
 =?utf-8?B?eklqVjExbHJoQXlGVG5mSTJXVjdQcDVxaWZpbzN4VW5FQUlTdXI0cVk5NVBs?=
 =?utf-8?B?a3Y2Qkl0cG1aTXY2U0k4My9SYmRaeG1KZHEwUWQzYmcrVG0xblByaFZ2QVpL?=
 =?utf-8?B?K2pMTDFsbjQ0VFZaRWwrVTVzUVh4VHU5cjV6YktKYjBQc1Irdk0velRmZDJJ?=
 =?utf-8?B?ODg0WEp2Y0lRdE5RektUTXNlMGZDU2hXeXdUYkZlVEtTZUxKazRlMDh5ZjRS?=
 =?utf-8?B?T1llZGNJUmFPcXIvRnpNRU1lZzVtWXF6RVZwdndSbWhOdmxXYlo1YUNXYWR1?=
 =?utf-8?B?aFcvRWEzWHlrbXFoZnBtVTZyRWQ2ckdTQTFLekRYaWJJcGdoWnZmUlB6L21i?=
 =?utf-8?B?dmZqSGsyd29Uc1hvSTg4Y1RheW1UYVNPOHc1WFZDUUM1TldJeVdzR3dUeGxn?=
 =?utf-8?Q?z5p5tt?=
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: 05 Sep 2025 20:34:38.3108
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75620421-e07e-4b9e-4cc6-08ddecbba25d
X-MS-Exchange-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:
	BL02EPF0001A108.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8218

On 2025-09-05 03:39, Jan Beulich wrote:
> On 04.09.2025 23:51, Jason Andryuk wrote:
>> io_apic_level_ack_pending() will end up in an infinite loop if
>> entry->pin == -1.  entry does not change, so it will keep reading -1.
>>
>> Switched to breaking out of the loop.
>>
>> Fixes: f821102450a1 ("x86: IRQ Migration logic enhancement.")
>> Signed-off-by: Jason Andryuk 
>> ---
>> Noticed during code inspection.
> 
> Well spotted, just that ...
> 
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -1715,7 +1715,7 @@ static bool io_apic_level_ack_pending(unsigned int irq)
>>   
>>           pin = entry->pin;
>>           if (pin == -1)
>> -            continue;
>> +            break;
> 
> ... we shouldn't terminate the loop here, but rather continue with the next
> entry in the list (if any). Hence presumably why "continue" was used, without
> achieving the intended effect.

Ok, makes sense.  Though after the sending the patch, I was wondering if 
it was an unreachable condition, and we should not end up here with pin 
== -1.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 20:51:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 20:51:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112414.1460685 (Exim 4.92)
	(envelope-from )
	id 1uudP8-0002Hi-OA; Fri, 05 Sep 2025 20:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112414.1460685; Fri, 05 Sep 2025 20: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 1uudP8-0002Hb-Ke; Fri, 05 Sep 2025 20:51:30 +0000
Received: by outflank-mailman (input) for mailman id 1112414;
 Fri, 05 Sep 2025 20: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 1uudP7-0002HU-Dg
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 20:51:29 +0000
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com
 [2607:f8b0:4864:20::b2a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1774cecb-8a9a-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 22:51:28 +0200 (CEST)
Received: by mail-yb1-xb2a.google.com with SMTP id
 3f1490d57ef6-e98b75eb577so2927427276.1
 for ; Fri, 05 Sep 2025 13:51:28 -0700 (PDT)
Received: from [10.138.34.110]
 (h96-60-249-169.cncrtn.broadband.dynamic.tds.net. [96.60.249.169])
 by smtp.gmail.com with ESMTPSA id
 956f58d0204a3-5ff87842768sm2723248d50.4.2025.09.05.13.51.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 13:51: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: 1774cecb-8a9a-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757105486; x=1757710286; 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=JeN0112/O9mGCqpZUtIp8qBVLLwEqrXatii0JDgHg6E=;
        b=EamuwudYu30Uv6aMB3PpKDK6wZO2LUsvE8oMRH6jijsSa3OtE1gi5oVzDA+B7Tqn3T
         NflM/fF7jMPPVjJ8XYi3O4KpHhQ2zw504Qpnd3mmpb6ayZkC3tTawNoBPOql65htyxi7
         yZD2gctdp9mAbYnjl6a+CkP+lqJteL2fIMXQ9aqCxIvVxS5+vfSt0YtA/KuOpfNbyKFH
         Dn71UHWOduFHqap5dzNu2OKF511fcvEaWHMrA1wCt9MVUX8PovFAxkxfz6UnnCzyS/5L
         SJgPZcE+hPzyLkAWF82+dFkAGFpraJ3CIMHg2J+bcX/73aQqgC0X5mq7W/KWBwM8dTms
         MZmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757105486; x=1757710286;
        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=JeN0112/O9mGCqpZUtIp8qBVLLwEqrXatii0JDgHg6E=;
        b=cEggaavKy8JR2mzPSC/0Msyg17kfWjqC0Tqkao0BO6njDVN9p1Q+I9FvlEWCpUSl+G
         l+REwNaV83zVT187aOez3mOmG3aqKd2n8mQF/7fndKudy8M/c99cjfEtQ3qQaGcTzVhs
         0LMyAwVVToyJT+4r0hK/EVeyYc/JH0SsnkIYb6dRFWbcT5FrfTLgJfiC4WM1VyUCrh59
         QRrtjMNGxHiYSN6CIoF7PYF6Nixm2G67WpYYDLxiHY4sHda09xmNxge+z8tpqwZPDFlj
         6VaGV8Jyo6xWGRW6mjkqPmM5KW8nTatdJP1ks3A7qyc+l6Z86KqfjexP6CQppFzP2d2t
         lNpg==
X-Forwarded-Encrypted: i=1; AJvYcCUUiEGi6aq0u19l/9wAwqdE+k/xL0eFo2x3DTrBDhM7Gq9ESDN+F3WVqZypung5W86OZQHmZW+5Py4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxS5xp0HB7NORSE8FVYczG5Uvu3vTQdkmwprO6Emio0titE103j
	kkRPSwV8OwSD2/VPxV8eNWRNovrpiCgN3r8vK7yu52avhGXJgNnRhRv/YQwydstI
X-Gm-Gg: ASbGncuqVKxy3B5x6qQF92zo/jWqjXpvA89BLYgv1AfAnKM0HNB57jJKbdbtcOxl9tf
	EbVGEXiYi80PI+Xl6If08NO0kekwBxUV4nV/M00Arg6iFT/BpKZU+WASwuFjIEVac8h2wCm/lCN
	HTCAhgtR2mmChQ3U30Iojy5nIwjw2OB5WrhvG/CZOfYG43YwKM2foGizIlHorx6uNLJ6jj0GftO
	C0NiC3odteMWQyqiuuFxT1aFdQKsbvLbJqW+JKPIXAZo/uKeUMvVHzzw5p4tQbv5mnDHzByE3kc
	Y3NSTMbhKvUX3vIF7XQ3Zk18TdNwyXDNcOfkJCWpuIPR29ogsmgqAgRKmZsVL208SHmUwIfmbLb
	ew3tfcx/cmBkuM/FrpQjG6YdOABc8PRVQ58jNSbjt57H9jwcHPoA6lZ5p3nr3KLMzXcdbr39lxG
	Jtyw9A8nGyvbP4BIveuV0ySGQdJc69pQtS8bc=
X-Google-Smtp-Source: AGHT+IGxFFhZ7d+rOP3tOnijd9pUgG0fL7hxlvF5mCUiFHFqhTshJAC54k2PH7kpaKuOVgkSFCM2aA==
X-Received: by 2002:a05:690e:14f:b0:5fd:a734:b1cc with SMTP id 956f58d0204a3-60b65b932b0mr3689177d50.7.1757105486538;
        Fri, 05 Sep 2025 13:51:26 -0700 (PDT)
Message-ID: <4e0e58d4-77d9-4ad9-a60c-8f9279343ad6@gmail.com>
Date: Fri, 5 Sep 2025 16:51:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Differentiating "For experts only" and "Not security supported"
 in Kconfig
To: "Orzel, Michal" ,
 Xen developer discussion ,
 Stefano Stabellini 
References: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.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="------------LHvWTvTsQs0OIonExLRQVWdW"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------LHvWTvTsQs0OIonExLRQVWdW
Content-Type: multipart/mixed; boundary="------------kOp2WMNrbqeZ0DJJSNONCX0U";
 protected-headers="v1"
From: Demi Marie Obenour 
To: "Orzel, Michal" ,
 Xen developer discussion ,
 Stefano Stabellini 
Message-ID: <4e0e58d4-77d9-4ad9-a60c-8f9279343ad6@gmail.com>
Subject: Re: Differentiating "For experts only" and "Not security supported"
 in Kconfig
References: <88efc685-507b-433f-a6d7-9c96987a0567@gmail.com>
 
In-Reply-To: 

--------------kOp2WMNrbqeZ0DJJSNONCX0U
Content-Type: multipart/mixed; boundary="------------X1vgGKErD4Dj9XOMJvNKETYo"

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

On 9/5/25 02:51, Orzel, Michal wrote:
>=20
>=20
> On 05/09/2025 05:47, Demi Marie Obenour wrote:
>> Right now, both EXPERT and UNSUPPORTED options are
>> not security supported.  However, this seems to be
>> causing problems for safety-certified use-cases.
>>
>> Specifically, disabling AMD or Intel support is certainly
>> something that should fall under EXPERT IMO, as it is a
>> great way to produce a Xen binary that will not boot on
>> a large fraction of hardware.  However, I see no fundamental
>> reason it should not be security supported.  Not security
>> supporting it means that those producing safety-certified
>> builds of Xen (which, presumably, are some of the most
>> security-critical there are!) are having to use
>> security-unsupported configurations.
>>
>> This definitely does not seem right to me.  Safety
>> certification and security support should go hand in hand,
>> not conflict with each other!  Is there a plan to address this?
> What makes you say that? Functional safety and security, although often=

> intertwined differ in focus areas and objectives. Functional safety aim=
s
> at reducing the risk of unintended hazards caused by malfunction of sys=
tem
> components, whereas security is about reducing the risk of intentional =
threats.
> There are different standards for safety and security. Current AMD safe=
ty work
> focuses on ISO26262 and IEC61508 but there are security standards like =
ISO/SAE
> 21434.
There have been cases of vehicles being compromised remotely.
Intentionally reducing the security of a system in the name of
safety does not seem like a good tradeoff compared to achieving
both, especially when (as here) the problem is purely a procedural
one and not technical.

A car that can be hijacked by a remote attacker is not safe, and
cars have been recalled in the past because of this.  My
understanding is that AMD's threat model includes the
non-certified OSs being compromised, so safety requires security
(though not the other way around).
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------X1vgGKErD4Dj9XOMJvNKETYo
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-----

--------------X1vgGKErD4Dj9XOMJvNKETYo--

--------------kOp2WMNrbqeZ0DJJSNONCX0U--

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

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

iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmi7TUkACgkQszaHOrMp
8lP/EQ//XWY/OXKicTxaVHErRPvigvr8fbQ1M8g791oDhtfvq4PqvHen2z8C4YIf
oVoyJYvpzUfmRKz2Jjfba3QDgp1GaW1npMfduHk6nofT+1QeTMHEqT2MVtwZ8aRz
DT10/TIyzSUVOM9tz35M6A835/Kk2a267l2v5PYnexLEs3ZeT+5R4jYxTvCU4Hnk
Yj/dShumZYYaiGM/UwaKv/fxq7yW66vyMidGA8OptKeesqgXLLu/OnalWd+9gwLu
6sVKEMEpMEQwaJb8opQSXXZTv5+V6gy7mJqIraeZpcNLlYxqKiJOQs4v7Q0MMztM
QjaayFXTHUjjwWIXiVV0mtgseu0kDdvl1zgJ8+Z/VUWqHg+WaX+e0wkcegzMxQDq
yotQ5DlPiiD/m4RIyR75eGynJcyGXBOGcnvLoaZIfhxgPTUeUGOq282ka02Nonms
7g/PARotiKBKBL19xdpELD4m2FuOJsBKDLBoTcmyF83wdstcFzdEiZc1cLIhX+wi
Q5mFoj5fdeHDv9rVkcgdpxLTZPH6XdorcriJGku6sKl5MGyjksB2HobbklqSmf13
YK5brUzsLKEGffunjN1hAg16L3nQLu2GmyXRUDiwISlIEIjCt0R4S+TvUBYKxwmX
DdhkRcZ5ot2he8nhxQmjyIS9jICeM5/pvJ244eiFDGXdWijp5sQ=
=JekK
-----END PGP SIGNATURE-----

--------------LHvWTvTsQs0OIonExLRQVWdW--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 21:25:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 21:25:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112435.1460695 (Exim 4.92)
	(envelope-from )
	id 1uudvu-0006Rj-7h; Fri, 05 Sep 2025 21:25:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112435.1460695; Fri, 05 Sep 2025 21:25: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 1uudvu-0006Rc-4R; Fri, 05 Sep 2025 21:25:22 +0000
Received: by outflank-mailman (input) for mailman id 1112435;
 Fri, 05 Sep 2025 21:25: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 1uudvs-0006RV-DV
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 21:25:20 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d2ac37b3-8a9e-11f0-9d12-b5c5bf9af7f9;
 Fri, 05 Sep 2025 23:25:19 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3d1bf79d758so2351838f8f.1
 for ; Fri, 05 Sep 2025 14:25:19 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3cf34494776sm32541561f8f.61.2025.09.05.14.25.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Sep 2025 14: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: d2ac37b3-8a9e-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757107519; x=1757712319; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Q7tDA6jdB85mRys2PmAwe8qXmmWoioadjWK0AoRRit0=;
        b=oNucCXJk+jpPXFJAJfppykWH8QHP2ev67CC1pK7q39NYHfTuwx9epfuGZKrtLZ0H3w
         fEE+MDwc0GxgZeUgqhdKDCFmBB+7DBKiComZQ07RouI7GhqxSmg/vOpaFx6/2qWgu258
         oLXyXGuV8+ooedafK5rn8DUGMeT+dmjI5NVAc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757107519; x=1757712319;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Q7tDA6jdB85mRys2PmAwe8qXmmWoioadjWK0AoRRit0=;
        b=MvBkyyV30BwpO8w1stpwkqNDLQxZ+DmEOeSgnt5U1rVn1EQZvn4g56bGWNXkffJWZb
         jaHbesnpyDjUjcyF1QUbnuZ761gP9HoQQkYXe9rYZrOzVAzXSVHDgzFCmivQCScx20gO
         0juoQagf7t1js8VomzuHUS+8P+i2vbEeJom3Npc1jUrRw3p21YH8BkQYSPVSqw5MQSC4
         ZhKfoUxb/f/tjAEQ2iT/aUzHzZlv5/VgM0IVYUilBfo8d/DF9w+eZgIQBOhsK6tzGLuz
         KCoHrtoBGQoDudxDw1/dFVNhHtkAKlvnqmWDvMTCRRLCRn5uvcV7UcD6hn5uNFGlInlf
         2P6w==
X-Forwarded-Encrypted: i=1; AJvYcCVkXtw0j5+WK7omvZC8CES4a+Dhs8z0WeNzGdyXKkfhZsPzHW/bFYICpd/vCSaaZXGvc2iw2E1kgtM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxwwnC5alzqwOPlQW69c5ABk4ZSCPl00w9aD30Yezao3OiagvSk
	dN1sop8J9nw4l5TCZDc9fZARBmVhRI1etmROf3PXqRTeTK+aUBHvYP34D4RBxZHa5B2/WVB2WZn
	5pvPK
X-Gm-Gg: ASbGncvPneCIrpf/coteR3E+QB0dRucnKc1OiuCx1YH3LeP7b1yTZ/qqvSzklNKxVTH
	AABCVlXcXk/WMMqLrSFI8L2jAnuLRhaOByPpKOJpMQ8ocbd5f16kGlUBRg9NJKhirKGYsk9VXSW
	3O5Afs07kO2UP++tRhsusKjkHB4EOAhdWr1mZ2vDaiWu/YHNmFhGtaiGlmpcMHTbVg85Oxj93os
	mVwMO/fe9S9xfnL5dj+6h9SAZ6UI5pxtJVcUXAFP/BXTAdOMDwJ7JrbwiYpfjx9KCan+s7SiVCP
	g2LsCflJL3TlT71ct/OHObUGvBADmROEejEl2B12Vm/8MPJ79I6MNSJXtydsm103jrfYkeUyrmd
	ue1lehW5zzEDgxck01dyvER2iEOigO7G/RGxl1Lyl8fsHeJZexWsu+TmcqlDNRrz2Ekc0fhZ7xI
	646mw=
X-Google-Smtp-Source: AGHT+IETsDPwbjWyiR1GwCNEk2ci6jKKbex9Wfx/K7iZRWIFftkOuAx9tyqLHfGK/Lt8ubwxExd1vg==
X-Received: by 2002:a05:6000:26c6:b0:3c9:fc3c:3aa3 with SMTP id ffacd0b85a97d-3e64625776amr20662f8f.40.1757107518713;
        Fri, 05 Sep 2025 14:25:18 -0700 (PDT)
Message-ID: 
Date: Fri, 5 Sep 2025 22:25:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/libs: Use superpages where possible on
 migrate/resume
To: Frediano Ziglio ,
 xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Juergen Gross , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250902105625.28552-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: <20250902105625.28552-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/09/2025 11:56 am, Frediano Ziglio wrote:
> Try to allocate larger order pages.
> With some test memory program stressing TLB (many small random
> memory accesses) you can get 15% performance improves.
> On the first memory iteration the sender is currently sending
> memory in 4mb aligned chunks which allows the receiver to
> allocate most pages as 2mb superpages instead of single 4kb pages.
> This works even for HVM where the first 2mb contains some holes.
> This change does not handle 1gb superpages as this will require
> change in the protocol to preallocate space.
>
> Signed-off-by: Frediano Ziglio 

This was given a release ack, which should have been retained.

> ---
> Changes since v1:
> - updated commit message and subject;
> - change the implementation detecting possible 2mb pages inside
>   the packet sent allowing more 2mb superpages.
> ---
>  tools/libs/guest/xg_sr_restore.c | 77 ++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>
> diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c
> index 06231ca826..f2018299a7 100644
> --- a/tools/libs/guest/xg_sr_restore.c
> +++ b/tools/libs/guest/xg_sr_restore.c
> @@ -129,6 +129,80 @@ static int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
>      return 0;
>  }
>  
> +#if defined(__i386__) || defined(__x86_64__)
> +/* Order of the smallest superpage */
> +#define SMALL_SUPERPAGE_ORDER 9
> +#else
> +#error Define SMALL_SUPERPAGE_ORDER for this platform
> +#endif
> +
> +static unsigned int populate_order(struct xc_sr_context *ctx,
> +                                   unsigned int original_count,
> +                                   xen_pfn_t *pfns, xen_pfn_t *mfns,
> +                                   int order)
> +{
> +    size_t i = original_count, num_superpages;
> +    xen_pfn_t prev = 0, order_mask = ~((~(xen_pfn_t)0) << order);
> +    xen_pfn_t *const indexes_end = mfns + original_count;
> +    xen_pfn_t *indexes = indexes_end;
> +    unsigned int count = 0;
> +
> +    while ( i > 0 )
> +    {
> +        --i;
> +        ++count;
> +        if ( pfns[i] != prev - 1 )
> +            count = 1;
> +
> +        /*
> +         * Is this the start of a contiguous and aligned number
> +         * of pages ?
> +         */
> +        if ( (pfns[i] & order_mask) == 0 && count > order_mask )
> +            *--indexes = i;

Consider receiving a PAGE_DATA packet formed of {some 4k, 2M, more 4k},
which can occur from the 2nd pass onwards.

You do not know that the mfn at the end of the input list was part of a
superpage, and therefore safe to clobber.

I expect this works in practice because the first pass is always
aligned, and subsequent passes are astronomically unlikely to have a
full 2M be dirty.

> +
> +        prev = pfns[i];
> +    }
> +
> +    count = original_count;
> +
> +    /* No superpages found */
> +    if ( indexes == indexes_end )
> +        return count;
> +    num_superpages = indexes_end - indexes;
> +
> +    /* Build list of PFNs that will be updated with MFNs */
> +    mfns = indexes - num_superpages;
> +    for ( i = 0; i < num_superpages; ++i )
> +        mfns[i] = pfns[indexes[i]];
> +
> +    /* Try to allocate, fallback to single pages */
> +    if ( xc_domain_populate_physmap_exact(
> +         ctx->xch, ctx->domid, num_superpages, order, 0, mfns) )
> +        return count;
> +
> +    /* Scan all MFNs allocated */
> +    for ( i = 0; i < num_superpages; ++i )
> +    {
> +        const xen_pfn_t mfn = mfns[i];
> +        const xen_pfn_t pfn = pfns[indexes[i]];
> +
> +        /* Check valid */
> +        if ( mfn == INVALID_MFN )
> +            continue;
> +
> +        /* Update PFNs using callback */
> +        for ( size_t j = 0; j <= order_mask; ++j )
> +            ctx->restore.ops.set_gfn(ctx, pfn + j, mfn + j);
> +
> +        /* remove from 4kb pages list */
> +        count -= order_mask + 1;
> +        memmove(pfns + indexes[i], pfns + indexes[i] + order_mask + 1,
> +                sizeof(*pfns) * (count - indexes[i]));

This in particular is horrible to follow, and is double processing the
data that ...

> +    }
> +    return count;
> +}
> +
>  /*
>   * Given a set of pfns, obtain memory from Xen to fill the physmap for the
>   * unpopulated subset.  If types is NULL, no page type checking is performed
> @@ -163,6 +237,9 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned int count,

... was set up just up here.

Have this loop scan forwards to pick out superpages, and deal with them
without putting them into the 4k list.  Don't even worry about trying to
collapse 2 hypercalls into 1; that's a marginal optimisation and the
flamegraphs showed that these hypercalls didn't even register compared
to the other overheads.

It will be a simpler patch, and easier to follow.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:01:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:01:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112456.1460705 (Exim 4.92)
	(envelope-from )
	id 1uueV3-00033y-10; Fri, 05 Sep 2025 22:01:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112456.1460705; Fri, 05 Sep 2025 22:01: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 1uueV2-00033r-Tt; Fri, 05 Sep 2025 22:01:40 +0000
Received: by outflank-mailman (input) for mailman id 1112456;
 Fri, 05 Sep 2025 22: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 1uueV1-00032r-DN
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:01:39 +0000
Received: from sender3-of-o50.zoho.com (sender3-of-o50.zoho.com
 [136.143.184.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e487d7c2-8aa3-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 00:01:37 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1757109687852185.963518623823;
 Fri, 5 Sep 2025 15:01: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: e487d7c2-8aa3-11f0-9d12-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; t=1757109690; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=boqs4QylBKzZHRmmYiho2A0YcLRaJbYtJPclLj8VxYiCkZD4qR9BVlLzqMAsuQtTt00cWSolGLO8rOap1DpQDKdeAAR16DBwV70F0viYU2PzHAj5bMh8d6yesm2ELgTGBSORvKt/kMlWNwKvDQUGGPQCiwaWLEcS7D/WmJ/a/xo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757109690; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=8L+EHnK0q6dte/hfCAknQn7thqJFz+eAfxwfsypDOpg=; 
	b=iinOD5lmoPIF95MKF9QdqGFBShFvmlSvWMl4FMAzUZiSYISAzqIGnalD45s6pFfP5N8ZpqWb7caW4PugP799OolqjgqlKkXwtVKV4TXvSsMJw1qI2dD8nK2CBcXUuI6A9m+qwKp833Y0nkSQyXjXC+1eWHe7UH1CetX9Jlhltjk=
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=1757109689;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Content-Type:Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Message-Id:Reply-To;
	bh=8L+EHnK0q6dte/hfCAknQn7thqJFz+eAfxwfsypDOpg=;
	b=OHc21ik3a6Rxc0I/aPRMpyCDKnLC6Gypu1+HidoD9TGzXON8jRcLbzQzoNgNe04w
	3RIFDVrn1aqdz38EPPHAd0kaGwixLjhQjP/RFR2OBviS9lH960B6fX3ptVs7CbfI04U
	8f9dWOc8WkQmXItLcR14mU0JoeUhgJc6ehP3/+bc=
Content-Type: multipart/alternative;
 boundary="------------KgpkQQUcUT8uNV0gnwgvxhI2"
Message-ID: <7b36e8fe-c19d-40eb-b1d7-d869cdfb1a28@apertussolutions.com>
Date: Fri, 5 Sep 2025 18:01:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] xen/flask: limit sidtable size
To: Jan Beulich , Sergiy Kibrik 
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: <20250901105231.1570041-1-Sergiy_Kibrik@epam.com>
 
Content-Language: en-US
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: 
X-ZohoMailClient: External

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

Hi Sergiy,

If you don't mind, please CC me directly, as I am the only XSM 
maintainer for which you will need my Ack. And for whatever reason, I 
cannot find the v2 post in my xen-devel folder. If you want to resend me 
v2, it would be greatly appreciated.

V/r,
Daniel P. Smith
Apertus Solutions, LLC

On 9/2/25 05:41, Jan Beulich wrote:
> On 01.09.2025 12:52, Sergiy Kibrik wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS
>>   
>>   	  If unsure, say Y.
>>   
>> +config XSM_FLASK_SIDTABLE_ORDER
>> +	int "Maximum number of security identifiers (base-2 exponent)" if EXPERT
>> +	range 4 32
>> +	default 32
> When 32 is chosen (i.e. also the default when the prompt is hidden), ...
>
>> --- a/xen/xsm/flask/ss/sidtab.c
>> +++ b/xen/xsm/flask/ss/sidtab.c
>> @@ -14,6 +14,8 @@
>>   #include "security.h"
>>   #include "sidtab.h"
>>   
>> +#define SID_LIMIT ((1UL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1)
> ... for Arm32 I expect either already the compiler will not like this construct,
> or the latest an UBSAN checker would object.
>
> Jan
--------------KgpkQQUcUT8uNV0gnwgvxhI2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
Hi Sergiy,

    
If you don't mind, please CC me directly, as I am the only XSM
      maintainer for which you will need my Ack. And for whatever
      reason, I cannot find the v2 post in my xen-devel folder. If you
      want to resend me v2, it would be greatly appreciated. 

    

    
V/r,
Daniel P. Smith
Apertus Solutions, LLC

    
On 9/2/25 05:41, Jan Beulich wrote:

    

    

      
On 01.09.2025 12:52, Sergiy Kibrik wrote:


      

        
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS
 
 	  If unsure, say Y.
 
+config XSM_FLASK_SIDTABLE_ORDER
+	int "Maximum number of security identifiers (base-2 exponent)" if EXPERT
+	range 4 32
+	default 32


      

      
When 32 is chosen (i.e. also the default when the prompt is hidden), ...



      

        
--- a/xen/xsm/flask/ss/sidtab.c
+++ b/xen/xsm/flask/ss/sidtab.c
@@ -14,6 +14,8 @@
 #include "security.h"
 #include "sidtab.h"
 
+#define SID_LIMIT ((1UL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1)


      

      
... for Arm32 I expect either already the compiler will not like this construct,
or the latest an UBSAN checker would object.

Jan


    

  
  


--------------KgpkQQUcUT8uNV0gnwgvxhI2--


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:05:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:05:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112467.1460715 (Exim 4.92)
	(envelope-from )
	id 1uueYu-0003dL-GV; Fri, 05 Sep 2025 22:05:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112467.1460715; Fri, 05 Sep 2025 22:05: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 1uueYu-0003dE-Dg; Fri, 05 Sep 2025 22:05:40 +0000
Received: by outflank-mailman (input) for mailman id 1112467;
 Fri, 05 Sep 2025 22:05:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uueYt-0003d8-CI
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:05:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uueYr-0088Xc-2Y;
 Fri, 05 Sep 2025 22:05:38 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uueYr-0000rO-2B;
 Fri, 05 Sep 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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=N9BhIsW6Yjq0ySvhS7rzG8xH0TH0/z3tG+y5P7+uCe4=; b=
	C4ww9JlrEtP+T/aaV38+n7wIPFjO970XbHCN7QxgDPAtSoG3TVl0GjH9mc/J/vv5X6RvMYp+5mGos
	ZlkjrWA6xwToAHVSzJvA1vsQ13kkvZyEip2Rs23qWQ5WWx0Qw2hZbk40Fi7K/glM7hTdR9nHATA8D
	3AsKGC6ScM9/Kb1M4=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:05:36 -0700
To: Stefano Stabellini 
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 05/15] emul/ns16x50: implement EIR/IIR registers
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-6-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 01:14:03PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
> > Add interrupt enable register emulation (EIR) and interrupt identity reason
> 
> EIR->IER

Whooops, thanks.

> 
> > (IIR) register emulation to the I/O port handler.
> > 
> > Also add routines for asserting/deasserting the virtual ns16x50 interrupt
> > line as a dependent on IIR code.
> > 
> > Poke ns16x50_irq_check() on every I/O register access because the emulator
> > does not have clock emulation anyway (e.g. for baud rate emulation).
> > 
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v4:
> > - new patch
> > ---
> >  xen/common/emul/vuart/ns16x50.c | 177 +++++++++++++++++++++++++++++++-
> >  1 file changed, 176 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > index f9f307a4ad24..20597cc36b35 100644
> > --- a/xen/common/emul/vuart/ns16x50.c
> > +++ b/xen/common/emul/vuart/ns16x50.c
> > @@ -85,9 +85,131 @@ struct vuart_ns16x50 {
> >      spinlock_t lock;                    /* Protection */
> >  };
> >  
> > +static bool ns16x50_fifo_rx_empty(const struct vuart_ns16x50 *vdev)
> > +{
> > +    const struct xencons_interface *cons = &vdev->cons;
> > +
> > +    return cons->in_prod == cons->in_cons;
> > +}
> 
> there is no ring so far so I would not add ns16x50_fifo_rx_empty for now

Ack.

> 
> 
> >  static inline uint8_t cf_check ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> >  {
> > -    return 0;
> > +    return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
> > +}
> > +
> > +static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
> > +{
> > +    return vdev->regs[UART_LSR] & UART_LSR_MASK;
> > +}
> > +
> > +static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
> > +{
> > +    return !ns16x50_fifo_rx_empty(vdev);
> > +}
> > +
> > +static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
> > +{
> > +    return vdev->regs[NS16X50_REGS_NUM + UART_IIR] & UART_IIR_THR;
> > +}
> > +
> > +static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
> > +{
> > +    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
> > +}
> > +
> > +/*
> > + * Get the interrupt identity reason.
> > + *
> > + * IIR is re-calculated once called, because ns16x50 always reports high
> > + * priority events first.
> > + * regs[NS16X50_REGS_NUM + UART_IIR] is used to store THR reason only.
> > + */
> > +static uint8_t ns16x50_iir_get(const struct vuart_ns16x50 *vdev)
> > +{
> > +    /*
> > +     * Interrupt identity reasons by priority.
> > +     * NB: high priority are at lower indexes below.
> > +     */
> > +    static const struct {
> > +        bool (*check)(const struct vuart_ns16x50 *vdev);
> > +        uint8_t ier;
> > +        uint8_t iir;
> > +    } iir_by_prio[] = {
> > +        [0] = { ns16x50_iir_check_lsi, UART_IER_ELSI,   UART_IIR_LSI },
> > +        [1] = { ns16x50_iir_check_rda, UART_IER_ERDAI,  UART_IIR_RDA },
> > +        [2] = { ns16x50_iir_check_thr, UART_IER_ETHREI, UART_IIR_THR },
> > +        [3] = { ns16x50_iir_check_msi, UART_IER_EMSI,   UART_IIR_MSI },
> > +    };
> > +    const uint8_t *regs = vdev->regs;
> > +    uint8_t iir = 0;
> > +    unsigned int i;
> > +
> > +    /*
> > +     * NB: every interaction w/ ns16x50 registers (except DLAB=1) goes
> > +     * through that call.
> > +     */
> > +    ASSERT(spin_is_locked(&vdev->lock));
> > +
> > +    for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ )
> > +    {
> > +        if ( (regs[UART_IER] & iir_by_prio[i].ier) &&
> > +             iir_by_prio[i].check(vdev) )
> > +            break;
> > +
> > +    }
> > +    if ( i == ARRAY_SIZE(iir_by_prio) )
> > +        iir |= UART_IIR_NOINT;
> > +    else
> > +        iir |= iir_by_prio[i].iir;
> > +
> > +    if ( regs[UART_FCR] & UART_FCR_ENABLE )
> > +        iir |= UART_IIR_FE;
> > +
> > +    return iir;
> > +}
> > +
> > +static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
> > +{
> > +    struct domain *d = vdev->owner;
> > +    const struct vuart_info *info = vdev->info;
> > +    int vector;
> > +
> > +    if ( has_vpic(d) ) /* HVM */
> > +        vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
> > +    else
> > +        ASSERT_UNREACHABLE();
> > +
> > +    ns16x50_debug(vdev, "IRQ#%d vector %d assert\n", info->irq, vector);
> > +}
> > +
> > +static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
> > +{
> > +    struct domain *d = vdev->owner;
> > +    const struct vuart_info *info = vdev->info;
> > +
> > +    if ( has_vpic(d) ) /* HVM */
> > +        hvm_isa_irq_deassert(d, info->irq);
> > +    else
> > +        ASSERT_UNREACHABLE();
> > +
> > +    ns16x50_debug(vdev, "IRQ#%d deassert\n", info->irq);
> > +}
> > +
> > +/*
> > + * Assert/deassert virtual ns16x50 interrupt line.
> > + */
> > +static void ns16x50_irq_check(const struct vuart_ns16x50 *vdev)
> > +{
> > +    uint8_t iir = ns16x50_iir_get(vdev);
> > +    const struct vuart_info *info = vdev->info;
> > +
> > +    if ( iir & UART_IIR_NOINT )
> > +        ns16x50_irq_assert(vdev);
> 
> It is a bit strange that if "NOINT" is set, we raise the interrupt

Yes, that is wrong.
Thank you!

> 
> 
> > +    else
> > +        ns16x50_irq_deassert(vdev);
> > +
> > +    ns16x50_debug(vdev, "IRQ#%d IIR 0x%02x %s\n", info->irq, iir,
> > +                  (iir & UART_IIR_NOINT) ? "deassert" : "assert");
> >  }
> >  
> >  /*
> > @@ -102,6 +224,29 @@ static int ns16x50_io_write8(
> >  
> >      if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
> >          regs[NS16X50_REGS_NUM + reg] = val;
> > +    else
> > +    {
> > +        switch ( reg )
> > +        {
> > +        case UART_IER:
> > +            /*
> > +             * NB: Make sure THR interrupt is re-triggered once guest OS
> > +             * re-enabled ETHREI in EIR.
> 
> EIR->IER

Will fix.

> 
> 
> > +             */
> > +            if ( val & regs[UART_IER] & UART_IER_ETHREI )
> > +                regs[NS16X50_REGS_NUM + UART_IIR] |= UART_IIR_THR;
> 
> I am confused by this. Shouldn't it be :
> 
> if ( (val & UART_IER_ETHREI) && !(regs[UART_IER] & UART_IER_ETHREI) )
> 
> Meaning set UART_IIR_THR if ETHREI goes 0->1 ?

That is by design to re-toggle the UART_IIR_THR since there's no baud
rate emulation.

> 
> 
> > +            regs[UART_IER] = val & UART_IER_MASK;
> > +
> > +            break;
> > +
> > +        default:
> > +            rc = -EINVAL;
> > +            break;
> > +        }
> > +
> > +        ns16x50_irq_check(vdev);
> > +    }
> >  
> >      return rc;
> >  }
> > @@ -164,6 +309,29 @@ static int ns16x50_io_read8(
> >  
> >      if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
> >          val = regs[NS16X50_REGS_NUM + reg];
> > +    else {
> > +        switch ( reg )
> > +        {
> > +        case UART_IER:
> > +            val = regs[UART_IER];
> > +            break;
> > +
> > +        case UART_IIR: /* RO */
> > +            val = ns16x50_iir_get(vdev);
> > +
> > +            /* NB: clear IIR scratch location */
> > +            if ( val & UART_IIR_THR )
> > +                regs[NS16X50_REGS_NUM + UART_IIR] &= ~UART_IIR_THR;
> 
> Maybe add an in-code comment why it is a good idea to clear THR here

Will fix.

> 
> 
> > +
> > +            break;
> > +
> > +        default:
> > +            rc = -EINVAL;
> > +            break;
> > +        }
> > +
> > +        ns16x50_irq_check(vdev);
> > +    }
> >  
> >      *data = val;
> >  
> > @@ -314,8 +482,15 @@ static int ns16x50_init(void *arg)
> >      vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
> >      vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
> >  
> > +    /* ns16x50 shall assert UART_IIR_THR whenever transmitter is empty. */
> > +    vdev->regs[NS16X50_REGS_NUM + UART_IIR] = UART_IIR_THR;
> > +
> >      register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
> >  
> > +    spin_lock(&vdev->lock);
> > +    ns16x50_irq_check(vdev);
> > +    spin_unlock(&vdev->lock);
> > +
> >      return 0;
> >  }
> >  
> > -- 
> > 2.51.0
> > 


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:20:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:20:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112495.1460724 (Exim 4.92)
	(envelope-from )
	id 1uuemv-0006KM-MQ; Fri, 05 Sep 2025 22:20:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112495.1460724; Fri, 05 Sep 2025 22:20: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 1uuemv-0006KF-J6; Fri, 05 Sep 2025 22:20:09 +0000
Received: by outflank-mailman (input) for mailman id 1112495;
 Fri, 05 Sep 2025 22:20:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuemu-0006K9-I5
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:20:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuems-0088oN-2x;
 Fri, 05 Sep 2025 22:20:07 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uuems-0001bQ-2f;
 Fri, 05 Sep 2025 22:20:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=Xfe4sXcyxst4Wy7udHhaBB4jDIOWl5jiVyvbmgjRVLk=; b=
	NsRdYAeIeSQDHMwRMtx7bwYM6WTkPaqyk/MwJvW11IwhqaBP/60tZNIZn/1i8hqgpU1ZBIy+CtYHr
	EAXOh93XwWN9dIF6cZ/xNvoDdvcPAyxxRw/+6sMR+NroqlmTA4wQBBTLDnLdGuE98WNo163eJuK5M
	X2y37NzYREdnDM6TE=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:20:05 -0700
To: Stefano Stabellini 
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 06/15] emul/ns16x50: implement THR/RBR registers
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-7-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 01:28:41PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
> > Add RBR/THR registers emulation to the I/O port handlder.
> > 
> > Also, add RX/TX FIFO management code since RBR depends on RX FIFO and
> > THR depends on TX FIFO.
> > 
> > FIFOs are not emulated as per UART specs for simplicity (not need to emulate
> > baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
> > NS16750 (64 bytes).
> > 
> > FIFOs are emulated by means of using xencons_interface which conveniently
> > provides primitives for buffer management and later can be used for
> > inter-domain communication similarly to vpl011.
> > 
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v4:
> > - new patch
> > ---
> >  xen/common/emul/vuart/ns16x50.c | 135 ++++++++++++++++++++++++++++++++
> >  1 file changed, 135 insertions(+)
> > 
> > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > index 20597cc36b35..efb2f4c6441c 100644
> > --- a/xen/common/emul/vuart/ns16x50.c
> > +++ b/xen/common/emul/vuart/ns16x50.c
> > @@ -92,6 +92,119 @@ static bool ns16x50_fifo_rx_empty(const struct vuart_ns16x50 *vdev)
> >      return cons->in_prod == cons->in_cons;
> >  }
> >  
> > +static bool ns16x50_fifo_rx_full(const struct vuart_ns16x50 *vdev)
> > +{
> > +    const struct xencons_interface *cons = &vdev->cons;
> > +
> > +    return cons->in_prod - cons->in_cons == ARRAY_SIZE(cons->in);
> > +}
> > +
> > +static void ns16x50_fifo_rx_reset(struct vuart_ns16x50 *vdev)
> > +{
> > +    struct xencons_interface *cons = &vdev->cons;
> > +
> > +    cons->in_cons = cons->in_prod;
> > +}
> > +
> > +static int ns16x50_fifo_rx_getchar(struct vuart_ns16x50 *vdev)
> > +{
> > +    struct xencons_interface *cons = &vdev->cons;
> > +    int rc;
> > +
> > +    if ( ns16x50_fifo_rx_empty(vdev) )
> > +    {
> > +        ns16x50_debug(vdev, "RX FIFO empty\n");
> > +        rc = -ENODATA;
> > +    }
> > +    else
> > +    {
> > +        rc = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
> > +        cons->in_cons++;
> > +    }
> > +
> > +    return rc;
> 
> The signed integer to char conversion here is not great from a MISRA
> perspective. I think it would be better to keep rc as success/failure
> return value and take the read char as a pointer parameter.

Ack.

> 
> 
> > +}
> > +
> > +static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
> > +{
> > +    struct xencons_interface *cons = &vdev->cons;
> > +    int rc;
> > +
> > +    /*
> > +     * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents
> > +     * of the THR.
> > +     */
> > +    if ( ns16x50_fifo_rx_full(vdev) )
> > +    {
> > +        ns16x50_debug(vdev, "RX FIFO full; resetting\n");
> > +        ns16x50_fifo_rx_reset(vdev);
> > +        rc = -ENOSPC;
> > +    }
> > +    else
> > +        rc = 0;
> > +
> > +    cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c;
> > +    cons->in_prod++;
> > +
> > +    return rc;
> > +}
> > +
> > +static bool ns16x50_fifo_tx_empty(const struct vuart_ns16x50 *vdev)
> > +{
> > +    const struct xencons_interface *cons = &vdev->cons;
> > +
> > +    return cons->out_prod == cons->out_cons;
> > +}
> > +
> > +static void ns16x50_fifo_tx_reset(struct vuart_ns16x50 *vdev)
> > +{
> > +    struct xencons_interface *cons = &vdev->cons;
> > +
> > +    cons->out_prod = 0;
> > +    ASSERT(cons->out_cons == cons->out_prod);
> 
> I am not sure about this.. why resetting the out_prod index? In theory
> it could keep increasing until wrap around and still go forward thanks
> to the mask

I used TX buffer not as a FIFO but as a large buffer for simplicity...

I have reworked that into a normal circular buffer in v6.

> 
> 
> > +}
> > +
> > +/*
> > + * Flush cached output to Xen console.
> > + */
> > +static void ns16x50_fifo_tx_flush(struct vuart_ns16x50 *vdev)
> > +{
> > +    struct xencons_interface *cons = &vdev->cons;
> > +    struct domain *d = vdev->owner;
> > +
> > +    if ( ns16x50_fifo_tx_empty(vdev) )
> > +        return;
> > +
> > + UART_IIR_THR   ASSERT(cons->out_prod < ARRAY_SIZE(cons->out));
> > +    cons->out[cons->out_prod] = '\0';
> 
> should use MASK_XENCONS_IDX to access the array

Ack.

> 
> 
> > +    cons->out_prod++;
> > +
> > +    guest_printk(d, guest_prefix "%s", cons->out);
> > +
> > +    ns16x50_fifo_tx_reset(vdev);
> 
> set UART_IIR_THR and call ns16x50_irq_check ?

I moved that to the I/O handler calling ns16x50_fifo_tx_flush() instead,
because ns16x50_fifo_tx_flush() can be called during vuart destroy,
and there's no need to emulate IRQs at domain destroy.

> 
> 
> > +}
> > +
> > +/*
> > + * Accumulate guest OS output before sending to Xen console.
> > + */
> > +static void ns16x50_fifo_tx_putchar(struct vuart_ns16x50 *vdev, char ch)
> > +{
> > +    struct xencons_interface *cons = &vdev->cons;
> > +
> > +    if ( !is_console_printable(ch) )
> > +        return;
> > +
> > +    if ( ch != '\0' )
> > +    {
> > +        cons->out[cons->out_prod] = ch;
> 
> should use MASK_XENCONS_IDX to access the array

Ack.

> 
> 
> > +        cons->out_prod++;
> > +    }
> > +
> > +    if ( cons->out_prod == ARRAY_SIZE(cons->out) - 1 ||
> > +         ch == '\n' || ch == '\0' )
> > +        ns16x50_fifo_tx_flush(vdev);
> > +}
> > +
> >  static inline uint8_t cf_check ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> >  {
> >      return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
> > @@ -228,6 +341,16 @@ static int ns16x50_io_write8(
> >      {
> >          switch ( reg )
> >          {
> > +        case UART_THR:
> > +            if ( regs[UART_MCR] & UART_MCR_LOOP )
> > +                rc = ns16x50_fifo_rx_putchar(vdev, val);
> > +            else
> > +                ns16x50_fifo_tx_putchar(vdev, val);
> 
> should UART_IIR_THR be cleared here?

Yes, thanks for the catch!

> 
> 
> > +            rc = 0;
> > +
> > +            break;
> > +
> >          case UART_IER:
> >              /*
> >               * NB: Make sure THR interrupt is re-triggered once guest OS
> > @@ -312,6 +435,14 @@ static int ns16x50_io_read8(
> >      else {
> >          switch ( reg )
> >          {
> > +        case UART_RBR:
> > +            rc = ns16x50_fifo_rx_getchar(vdev);
> > +            if ( rc >= 0 )
> > +                val = (uint8_t)rc;
> 
> Empty fifo check?

Will do.

> 
> 
> > +            rc = 0;
> > +            break;
> > +
> >          case UART_IER:
> >              val = regs[UART_IER];
> >              break;
> > @@ -499,6 +630,10 @@ static void cf_check ns16x50_deinit(void *arg)
> >      struct vuart_ns16x50 *vdev = arg;
> >  
> >      ASSERT(vdev);
> > +
> > +    spin_lock(&vdev->lock);
> > +    ns16x50_fifo_tx_flush(vdev);
> > +    spin_unlock(&vdev->lock);
> >  }
> >  
> >  static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info)
> > -- 
> > 2.51.0
> > 


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:29:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:29:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112507.1460735 (Exim 4.92)
	(envelope-from )
	id 1uuew0-000731-IJ; Fri, 05 Sep 2025 22:29:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112507.1460735; Fri, 05 Sep 2025 22:29: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 1uuew0-00072u-FG; Fri, 05 Sep 2025 22:29:32 +0000
Received: by outflank-mailman (input) for mailman id 1112507;
 Fri, 05 Sep 2025 22:29:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuevz-00072o-DF
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:29:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuevy-0088zC-00;
 Fri, 05 Sep 2025 22:29:30 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uuevx-0002CS-2z;
 Fri, 05 Sep 2025 22:29:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=REYTDTUYkn/978evtZltzG59+rC8/AC8/F3zDIATo+k=; b=
	ZbFnijt97/ro+jb9tbUBXoF4jA5ycemRKVaFgw0RwA3lzumF8z4mOQxUqTi6RXx/Z9NghzOIXvv9G
	Z9wpJuuRAjaKeMmIRc58VrDxaSbWfs5cHHdVvbQwlRAQzHYPfauF5sx5VIp3rQ83wK4Yfds2Amu3N
	NoKqOj2Yebf7APsEs=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:29:29 -0700
To: Stefano Stabellini 
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 06/15] emul/ns16x50: implement THR/RBR registers
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-7-dmukhin@ford.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 01:34:39PM -0700, Stefano Stabellini wrote:
> On Fri, 29 Aug 2025, Stefano Stabellini wrote:
> > On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > > From: Denis Mukhin  
> > > 
> > > Add RBR/THR registers emulation to the I/O port handlder.
> > > 
> > > Also, add RX/TX FIFO management code since RBR depends on RX FIFO and
> > > THR depends on TX FIFO.
> > > 
> > > FIFOs are not emulated as per UART specs for simplicity (not need to emulate
> > > baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
> > > NS16750 (64 bytes).
> > > 
> > > FIFOs are emulated by means of using xencons_interface which conveniently
> > > provides primitives for buffer management and later can be used for
> > > inter-domain communication similarly to vpl011.
> > > 
> > > Signed-off-by: Denis Mukhin 
> > > ---
> > > Changes since v4:
> > > - new patch
> > > ---
> > >  xen/common/emul/vuart/ns16x50.c | 135 ++++++++++++++++++++++++++++++++
> > >  1 file changed, 135 insertions(+)
> > > 
> > > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > > index 20597cc36b35..efb2f4c6441c 100644
> > > --- a/xen/common/emul/vuart/ns16x50.c
> > > +++ b/xen/common/emul/vuart/ns16x50.c
> > > @@ -92,6 +92,119 @@ static bool ns16x50_fifo_rx_empty(const struct vuart_ns16x50 *vdev)
> > >      return cons->in_prod == cons->in_cons;
> > >  }
> > >  
> > > +static bool ns16x50_fifo_rx_full(const struct vuart_ns16x50 *vdev)
> > > +{
> > > +    const struct xencons_interface *cons = &vdev->cons;
> > > +
> > > +    return cons->in_prod - cons->in_cons == ARRAY_SIZE(cons->in);
> > > +}
> > > +
> > > +static void ns16x50_fifo_rx_reset(struct vuart_ns16x50 *vdev)
> > > +{
> > > +    struct xencons_interface *cons = &vdev->cons;
> > > +
> > > +    cons->in_cons = cons->in_prod;
> > > +}
> > > +
> > > +static int ns16x50_fifo_rx_getchar(struct vuart_ns16x50 *vdev)
> > > +{
> > > +    struct xencons_interface *cons = &vdev->cons;
> > > +    int rc;
> > > +
> > > +    if ( ns16x50_fifo_rx_empty(vdev) )
> > > +    {
> > > +        ns16x50_debug(vdev, "RX FIFO empty\n");
> > > +        rc = -ENODATA;
> > > +    }
> > > +    else
> > > +    {
> > > +        rc = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
> > > +        cons->in_cons++;
> > > +    }
> > > +
> > > +    return rc;
> > 
> > The signed integer to char conversion here is not great from a MISRA
> > perspective. I think it would be better to keep rc as success/failure
> > return value and take the read char as a pointer parameter.
> > 
> > 
> > > +}
> > > +
> > > +static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
> > > +{
> > > +    struct xencons_interface *cons = &vdev->cons;
> > > +    int rc;
> > > +
> > > +    /*
> > > +     * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents
> > > +     * of the THR.
> > > +     */
> > > +    if ( ns16x50_fifo_rx_full(vdev) )
> > > +    {
> > > +        ns16x50_debug(vdev, "RX FIFO full; resetting\n");
> > > +        ns16x50_fifo_rx_reset(vdev);
> > > +        rc = -ENOSPC;
> > > +    }
> > > +    else
> > > +        rc = 0;
> > > +
> > > +    cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c;
> > > +    cons->in_prod++;
> > > +
> > > +    return rc;
> > > +}
> > > +
> > > +static bool ns16x50_fifo_tx_empty(const struct vuart_ns16x50 *vdev)
> > > +{
> > > +    const struct xencons_interface *cons = &vdev->cons;
> > > +
> > > +    return cons->out_prod == cons->out_cons;
> > > +}
> > > +
> > > +static void ns16x50_fifo_tx_reset(struct vuart_ns16x50 *vdev)
> > > +{
> > > +    struct xencons_interface *cons = &vdev->cons;
> > > +
> > > +    cons->out_prod = 0;
> > > +    ASSERT(cons->out_cons == cons->out_prod);
> > 
> > I am not sure about this.. why resetting the out_prod index? In theory
> > it could keep increasing until wrap around and still go forward thanks
> > to the mask
> 
> I get it now .. it is because it is called from ns16x50_fifo_tx_flush
> right after printing to the real console.
> 
> I think it is better to simply do:
> 
>   cons->out_cons = cons->out_prod;
> 
> which effectively clears out the whole buffer. It is dangerous to do:

That was OK to use TX buffer in such awkward manner because of the assertions
and buffer size checks. I reworked that part in v6.

> 
>   cons->out_prod = 0;
> 
> without also doing:
> 
>   cons->out_cons = 0;
> 
> Also, if ns16x50_fifo_tx_flush is the only caller of
> ns16x50_fifo_tx_reset, I would open code the implementation directly
> inside ns16x50_fifo_tx_flush to make it more obvious.

The will be another callsite for ns16x50_fifo_tx_reset() - FCR (in v6).

> 
> 
> > > +}
> > > +
> > > +/*
> > > + * Flush cached output to Xen console.
> > > + */
> > > +static void ns16x50_fifo_tx_flush(struct vuart_ns16x50 *vdev)
> > > +{
> > > +    struct xencons_interface *cons = &vdev->cons;
> > > +    struct domain *d = vdev->owner;
> > > +
> > > +    if ( ns16x50_fifo_tx_empty(vdev) )
> > > +        return;
> > > +
> > > + UART_IIR_THR   ASSERT(cons->out_prod < ARRAY_SIZE(cons->out));
> > > +    cons->out[cons->out_prod] = '\0';
> > 
> > should use MASK_XENCONS_IDX to access the array
> > 
> > 
> > > +    cons->out_prod++;
> > > +
> > > +    guest_printk(d, guest_prefix "%s", cons->out);
> > > +
> > > +    ns16x50_fifo_tx_reset(vdev);
> > 
> > set UART_IIR_THR and call ns16x50_irq_check ?
> > 
> > 
> > > +}
> 


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:33:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:33:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112525.1460745 (Exim 4.92)
	(envelope-from )
	id 1uuezp-0000Cd-53; Fri, 05 Sep 2025 22:33:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112525.1460745; Fri, 05 Sep 2025 22: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 1uuezp-0000CW-24; Fri, 05 Sep 2025 22:33:29 +0000
Received: by outflank-mailman (input) for mailman id 1112525;
 Fri, 05 Sep 2025 22:33:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuezn-0000CQ-Qq
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:33:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuezm-00894h-1w;
 Fri, 05 Sep 2025 22:33:26 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uuezm-0002Pq-1r;
 Fri, 05 Sep 2025 22:33: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=vKkKEq91YPtWCfB8OjxhVAxgHU3Ca3IXZSEt2vQMv9Y=; b=
	6/KM+KljAHqPx0mmqWIwfwKxR73YLQUh4Q+ySado7AxcXqKkUih8MeJQYBcUkncTxoWJeKfotU6I9
	ktAHCWxQ9U2MCrA3maqv0xfaT0JnxJzz0MEJvFMd2EZAKb3lxAWdCb/h/5MAckY8Ef0Hajb6hbDms
	sr3yF6FwWYWl+SYUs=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:33:25 -0700
To: Stefano Stabellini 
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 07/15] emul/ns16x50: implement FCR register
 (write-only)
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-8-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 01:38:02PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
> > Add emulation logic for FCR register.
> > 
> > Note, that does not hooks FIFO interrupt moderation to the FIFO management
> > code.
> > 
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v4:
> > - new patch
> > ---
> >  xen/common/emul/vuart/ns16x50.c | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > index efb2f4c6441c..65ca96dd8bd3 100644
> > --- a/xen/common/emul/vuart/ns16x50.c
> > +++ b/xen/common/emul/vuart/ns16x50.c
> > @@ -363,6 +363,30 @@ static int ns16x50_io_write8(
> >  
> >              break;
> >  
> > +        case UART_FCR: /* WO */
> > +            if ( val & UART_FCR_RESERVED0 )
> > +                ns16x50_warn(vdev, "FCR: attempt to set reserved bit: %x\n",
> > +                             UART_FCR_RESERVED0);
> > +
> > +            if ( val & UART_FCR_RESERVED1 )
> > +                ns16x50_warn(vdev, "FCR: attempt to set reserved bit: %x\n",
> > +                             UART_FCR_RESERVED1);
> > +
> > +            if ( val & UART_FCR_CLRX )
> > +                ns16x50_fifo_rx_reset(vdev);
> > +
> > +            if ( val & UART_FCR_CLTX )
> > +                ns16x50_fifo_tx_flush(vdev);
> 
> Should UART_FCR_CLTX actually emit data or only clear the buffer?

Yes, thanks; should be just "tx_reset".

> 
> set UART_IIR_THR ?

Will do, thanks.

> 
> 
> > +
> > +            if ( val & UART_FCR_ENABLE )
> > +                val &= UART_FCR_ENABLE | UART_FCR_DMA | UART_FCR_TRG_MASK;
> > +            else
> > +                val = 0;
> > +
> > +            regs[UART_FCR] = val;
> 
> 
> ns16x50_irq_check ?

ns16x50_irq_check() is poked after the switch statement.

> 
> 
> > +            break;
> > +
> >          default:
> >              rc = -EINVAL;
> >              break;
> > -- 
> > 2.51.0
> > 


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:38:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:38:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112536.1460754 (Exim 4.92)
	(envelope-from )
	id 1uuf50-0000oP-ML; Fri, 05 Sep 2025 22:38:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112536.1460754; Fri, 05 Sep 2025 22: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 1uuf50-0000oI-JF; Fri, 05 Sep 2025 22:38:50 +0000
Received: by outflank-mailman (input) for mailman id 1112536;
 Fri, 05 Sep 2025 22:38:49 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuf4z-0000oC-9h
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:38:49 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuf4x-0089B3-1y;
 Fri, 05 Sep 2025 22:38:47 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uuf4x-0002eW-1T;
 Fri, 05 Sep 2025 22: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=dzneURA8vti5ojuxgj0vW2yNxwtq7QqNS1t9q98Bv8Q=; b=
	HBzxG13PjjP7bPARLuS0NJ3d5bn+UcXj0NtKHnzVwFNoWR5z9kX4kCybBCGbG9hgDqMum36fY5lNV
	VGeyZPdKv9PFGCxiZShAIAASAruUCUoB5ypWH6Vqq/v1kAJGrXsI9ah4vAdNDMJcxymcSbNP1Y9QN
	OZa363wp+RXT/Z1AM=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:38:46 -0700
To: Stefano Stabellini 
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 13/15] x86/domain: enable per-domain I/O port bitmaps
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-14-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 02:43:18PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
> > Current design enables all HVM domains share the same I/O port bitmap.
> > 
> > It is necessary for domains crafting its own I/O port address space depending
> > on the user configuration.
> > 
> > Ensure NS16550 emulator does not share I/O ports with the physical I/O ports,
> > which is essential for emulation in PVH hwdom case (dom0).
> > 
> > Not a functional change.
> > 
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v4:
> > - new patch 
> > - Link tp v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-4-dmukhin@ford.com/
> > ---
> >  xen/arch/x86/Makefile                    |   1 +
> >  xen/arch/x86/dom0_build.c                | 111 +--------------
> >  xen/arch/x86/hvm/hvm.c                   |  35 +----
> >  xen/arch/x86/hvm/nestedhvm.c             |   8 +-
> >  xen/arch/x86/hvm/quirks.c                |   3 -
> >  xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
> >  xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
> >  xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
> >  xen/arch/x86/include/asm/hvm/support.h   |   2 -
> >  xen/arch/x86/include/asm/iocap.h         |   2 +
> >  xen/arch/x86/ioport.c                    | 163 +++++++++++++++++++++++
> >  xen/arch/x86/pv/dom0_build.c             |   4 +
> >  xen/common/emul/vuart/ns16x50.c          |  11 ++
> >  13 files changed, 200 insertions(+), 149 deletions(-)
> >  create mode 100644 xen/arch/x86/ioport.c
> > 
> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index 9d67ea7cd4a8..5726ecc180eb 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -44,6 +44,7 @@ obj-y += msi.o
> >  obj-y += msr.o
> >  obj-$(CONFIG_INDIRECT_THUNK) += indirect-thunk.o
> >  obj-$(CONFIG_RETURN_THUNK) += indirect-thunk.o
> > +obj-y += ioport.o
> >  obj-$(CONFIG_PV) += ioport_emulate.o
> >  obj-y += irq.o
> >  obj-$(CONFIG_KEXEC) += machine_kexec.o
> > diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> > index 0b467fd4a4fc..26202b33345c 100644
> > --- a/xen/arch/x86/dom0_build.c
> > +++ b/xen/arch/x86/dom0_build.c
> > @@ -298,9 +298,6 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
> >      return 0;
> >  }
> >  
> > -static char __initdata opt_dom0_ioports_disable[200] = "";
> > -string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
> > -
> >  static bool __initdata ro_hpet = true;
> >  boolean_param("ro-hpet", ro_hpet);
> >  
> > @@ -433,122 +430,20 @@ unsigned long __init dom0_compute_nr_pages(
> >      return nr_pages;
> >  }
> >  
> > -static void __init process_dom0_ioports_disable(struct domain *dom0)
> > -{
> > -    unsigned long io_from, io_to;
> > -    char *t, *s = opt_dom0_ioports_disable;
> > -    const char *u;
> > -
> > -    if ( *s == '\0' )
> > -        return;
> > -
> > -    while ( (t = strsep(&s, ",")) != NULL )
> > -    {
> > -        io_from = simple_strtoul(t, &u, 16);
> > -        if ( u == t )
> > -        {
> > -        parse_error:
> > -            printk("Invalid ioport range <%s> "
> > -                   "in dom0_ioports_disable, skipping\n", t);
> > -            continue;
> > -        }
> > -
> > -        if ( *u == '\0' )
> > -            io_to = io_from;
> > -        else if ( *u == '-' )
> > -            io_to = simple_strtoul(u + 1, &u, 16);
> > -        else
> > -            goto parse_error;
> > -
> > -        if ( (*u != '\0') || (io_to < io_from) || (io_to >= 65536) )
> > -            goto parse_error;
> > -
> > -        printk("Disabling dom0 access to ioport range %04lx-%04lx\n",
> > -            io_from, io_to);
> > -
> > -        if ( ioports_deny_access(dom0, io_from, io_to) != 0 )
> > -            BUG();
> > -    }
> > -}
> > -
> > +/* Modify I/O memory access permissions. */
> >  int __init dom0_setup_permissions(struct domain *d)
> >  {
> >      unsigned long mfn;
> > -    unsigned int i, offs;
> > -    int rc;
> > +    unsigned int i;
> > +    int rc = 0;
> >  
> >      if ( pv_shim )
> >          return 0;
> >  
> > -    /* The hardware domain is initially permitted full I/O capabilities. */
> > -    rc = ioports_permit_access(d, 0, 0xFFFF);
> >      rc |= iomem_permit_access(d, 0UL,
> >                                PFN_DOWN(1UL << domain_max_paddr_bits(d)) - 1);
> >      rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
> >  
> > -    /* Modify I/O port access permissions. */
> > -
> > -    for ( offs = 0, i = ISOLATE_LSB(i8259A_alias_mask) ?: 2;
> > -          offs <= i8259A_alias_mask; offs += i )
> > -    {
> > -        if ( offs & ~i8259A_alias_mask )
> > -            continue;
> > -        /* Master Interrupt Controller (PIC). */
> > -        rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
> > -        /* Slave Interrupt Controller (PIC). */
> > -        rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
> > -    }
> > -
> > -    /* ELCR of both PICs. */
> > -    rc |= ioports_deny_access(d, 0x4D0, 0x4D1);
> > -
> > -    /* Interval Timer (PIT). */
> > -    for ( offs = 0, i = ISOLATE_LSB(pit_alias_mask) ?: 4;
> > -          offs <= pit_alias_mask; offs += i )
> > -        if ( !(offs & ~pit_alias_mask) )
> > -            rc |= ioports_deny_access(d, PIT_CH0 + offs, PIT_MODE + offs);
> > -
> > -    /* PIT Channel 2 / PC Speaker Control. */
> > -    rc |= ioports_deny_access(d, 0x61, 0x61);
> > -
> > -    /* INIT# and alternative A20M# control. */
> > -    rc |= ioports_deny_access(d, 0x92, 0x92);
> > -
> > -    /* IGNNE# control. */
> > -    rc |= ioports_deny_access(d, 0xF0, 0xF0);
> > -
> > -    /* ACPI PM Timer. */
> > -    if ( pmtmr_ioport )
> > -        rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
> > -
> > -    /* Reset control. */
> > -    rc |= ioports_deny_access(d, 0xCF9, 0xCF9);
> > -
> > -    /* PCI configuration space (NB. 0xCF8 has special treatment). */
> > -    rc |= ioports_deny_access(d, 0xCFC, 0xCFF);
> > -
> > -#ifdef CONFIG_HVM
> > -    if ( is_hvm_domain(d) )
> > -    {
> > -        /* ISA DMA controller, channels 0-3 (incl possible aliases). */
> > -        rc |= ioports_deny_access(d, 0x00, 0x1F);
> > -        /* ISA DMA controller, page registers (incl various reserved ones). */
> > -        rc |= ioports_deny_access(d, 0x80 + !!hvm_port80_allowed, 0x8F);
> > -        /* ISA DMA controller, channels 4-7 (incl usual aliases). */
> > -        rc |= ioports_deny_access(d, 0xC0, 0xDF);
> > -
> > -        /* HVM debug console IO port. */
> > -        rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
> > -                                  XEN_HVM_DEBUGCONS_IOPORT);
> > -        if ( amd_acpi_c1e_quirk )
> > -            rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
> > -    }
> > -#endif
> > -    /* Command-line I/O ranges. */
> > -    process_dom0_ioports_disable(d);
> > -
> > -    /* Modify I/O memory access permissions. */
> > -
> >      /* Local APIC. */
> >      if ( mp_lapic_addr != 0 )
> >      {
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 26760cf995df..12736fc61c11 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -51,6 +51,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -81,14 +82,6 @@ integer_param("hvm_debug", opt_hvm_debug_level);
> >  
> >  struct hvm_function_table __ro_after_init hvm_funcs;
> >  
> > -/*
> > - * The I/O permission bitmap is globally shared by all HVM guests except
> > - * the hardware domain which needs a more permissive one.
> > - */
> > -#define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
> > -unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > -    hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
> > -
> >  /* Xen command-line option to enable HAP */
> >  static bool __initdata opt_hap_enabled = true;
> >  boolean_param("hap", opt_hap_enabled);
> > @@ -205,15 +198,6 @@ static int __init cf_check hvm_enable(void)
> >      if ( opt_hvm_fep )
> >          warning_add(warning_hvm_fep);
> >  
> > -    /*
> > -     * Allow direct access to the PC debug ports 0x80 and 0xed (they are
> > -     * often used for I/O delays, but the vmexits simply slow things down).
> > -     */
> > -    memset(hvm_io_bitmap, ~0, sizeof(hvm_io_bitmap));
> > -    if ( hvm_port80_allowed )
> > -        __clear_bit(0x80, hvm_io_bitmap);
> > -    __clear_bit(0xed, hvm_io_bitmap);
> > -
> >      register_cpu_notifier(&cpu_nfb);
> >  
> >      return 0;
> > @@ -645,19 +629,12 @@ int hvm_domain_initialise(struct domain *d,
> >  
> >      rwlock_init(&d->arch.hvm.pl_time->pt_migrate);
> >  
> > -    /* Set the default IO Bitmap. */
> > -    if ( is_hardware_domain(d) )
> > +    rc = ioports_setup_access(d);
> > +    if ( rc )
> >      {
> > -        d->arch.hvm.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
> > -        if ( d->arch.hvm.io_bitmap == NULL )
> > -        {
> > -            rc = -ENOMEM;
> > -            goto fail1;
> > -        }
> > -        memset(d->arch.hvm.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
> > +        printk("%pd failed to setup I/O bitmap: %d\n", d, rc);
> > +        goto fail1;
> >      }
> > -    else
> > -        d->arch.hvm.io_bitmap = hvm_io_bitmap;
> >  
> >      register_g2m_portio_handler(d);
> >      register_vpci_portio_handler(d);
> > @@ -684,6 +661,8 @@ int hvm_domain_initialise(struct domain *d,
> >          break;
> >      }
> >  
> > +    BUG_ON(!d->arch.ioport_caps);
> > +
> >      vpic_init(d);
> >  
> >      rc = vioapic_init(d);
> > diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
> > index bddd77d8109b..d4e03123d910 100644
> > --- a/xen/arch/x86/hvm/nestedhvm.c
> > +++ b/xen/arch/x86/hvm/nestedhvm.c
> > @@ -107,7 +107,7 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
> >   * The users of the bitmap patterns are in SVM/VMX specific code.
> >   *
> >   * bitmap        port 0x80  port 0xed
> > - * hvm_io_bitmap cleared    cleared
> > + * hvm.io_bitmap cleared    cleared
> >   * iomap[0]      cleared    set
> >   * iomap[1]      set        cleared
> >   * iomap[2]      set        set
> > @@ -115,7 +115,7 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
> >  
> >  static int __init cf_check nestedhvm_setup(void)
> >  {
> > -    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
> > +    /* Same format and size as hvm.io_bitmap (Intel needs only 2 pages). */
> >      unsigned nr = cpu_has_vmx ? 2 : 3;
> >      unsigned int i, order = get_order_from_pages(nr);
> >  
> > @@ -165,7 +165,7 @@ static int __init cf_check nestedhvm_setup(void)
> >  __initcall(nestedhvm_setup);
> >  
> >  unsigned long *
> > -nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed)
> > +nestedhvm_vcpu_iomap_get(struct vcpu *v, bool ioport_80, bool ioport_ed)
> >  {
> >      int i;
> >  
> > @@ -174,7 +174,7 @@ nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed)
> >  
> >      if (ioport_80 == 0) {
> >          if (ioport_ed == 0)
> > -            return hvm_io_bitmap;
> > +            return v->domain->arch.hvm.io_bitmap;
> >          i = 0;
> >      } else {
> >          if (ioport_ed == 0)
> > diff --git a/xen/arch/x86/hvm/quirks.c b/xen/arch/x86/hvm/quirks.c
> > index 9202f5a47fe9..f4d95441fcff 100644
> > --- a/xen/arch/x86/hvm/quirks.c
> > +++ b/xen/arch/x86/hvm/quirks.c
> > @@ -73,9 +73,6 @@ static int __init cf_check check_port80(void)
> >  
> >      dmi_check_system(hvm_no_port80_dmi_table);
> >  
> > -    if ( !hvm_port80_allowed )
> > -        __set_bit(0x80, hvm_io_bitmap);
> > -
> >      return 0;
> >  }
> >  __initcall(check_port80);
> > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
> > index dc2b6a42534a..cc8500b61665 100644
> > --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> > @@ -381,7 +381,7 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
> >          hvm_unmap_guest_frame(ns_viomap, 0);
> >      }
> >  
> > -    svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
> > +    svm->ns_iomap = nestedhvm_vcpu_iomap_get(v, ioport_80, ioport_ed);
> >  
> >      nv->nv_ioport80 = ioport_80;
> >      nv->nv_ioportED = ioport_ed;
> > diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> > index e4f3a5fe4c71..4da3e6e90e6c 100644
> > --- a/xen/arch/x86/hvm/vmx/vvmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> > @@ -554,7 +554,7 @@ unsigned long *_shadow_io_bitmap(struct vcpu *v)
> >      port80 = bitmap[0x80 >> 3] & (1 << (0x80 & 0x7)) ? 1 : 0;
> >      portED = bitmap[0xed >> 3] & (1 << (0xed & 0x7)) ? 1 : 0;
> >  
> > -    return nestedhvm_vcpu_iomap_get(port80, portED);
> > +    return nestedhvm_vcpu_iomap_get(v, port80, portED);
> >  }
> >  
> >  static void update_msrbitmap(struct vcpu *v, uint32_t shadow_ctrl)
> > @@ -622,7 +622,7 @@ void nvmx_update_exec_control(struct vcpu *v, u32 host_cntrl)
> >               * L1 VMM doesn't intercept IO instruction.
> >               * Use host configuration and reset IO_BITMAP
> >               */
> > -            bitmap = hvm_io_bitmap;
> > +            bitmap = v->domain->arch.hvm.io_bitmap;
> >          }
> >          else {
> >              /* use IO bitmap */
> > diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm.h b/xen/arch/x86/include/asm/hvm/nestedhvm.h
> > index ea2c1bc328c7..d691ccb07dd6 100644
> > --- a/xen/arch/x86/include/asm/hvm/nestedhvm.h
> > +++ b/xen/arch/x86/include/asm/hvm/nestedhvm.h
> > @@ -50,7 +50,8 @@ int nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa,
> >                                      struct npfec npfec);
> >  
> >  /* IO permission map */
> > -unsigned long *nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed);
> > +unsigned long *nestedhvm_vcpu_iomap_get(struct vcpu *v,
> > +                                        bool ioport_80, bool ioport_ed);
> >  
> >  /* Misc */
> >  #define nestedhvm_paging_mode_hap(v) (!!nhvm_vmcx_hap_enabled(v))
> > diff --git a/xen/arch/x86/include/asm/hvm/support.h b/xen/arch/x86/include/asm/hvm/support.h
> > index 2a7ba36af06f..7e36d00cc188 100644
> > --- a/xen/arch/x86/include/asm/hvm/support.h
> > +++ b/xen/arch/x86/include/asm/hvm/support.h
> > @@ -41,8 +41,6 @@ extern unsigned int opt_hvm_debug_level;
> >  #define HVM_DBG_LOG(level, _f, _a...) do {} while (0)
> >  #endif
> >  
> > -extern unsigned long hvm_io_bitmap[];
> > -
> >  enum hvm_translation_result {
> >      HVMTRANS_okay,
> >      HVMTRANS_bad_linear_to_gfn,
> > diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
> > index f948b7186e95..1083f6171cf7 100644
> > --- a/xen/arch/x86/include/asm/iocap.h
> > +++ b/xen/arch/x86/include/asm/iocap.h
> > @@ -22,6 +22,8 @@
> >  #define cache_flush_permitted(d) \
> >      (has_arch_io_resources(d) || has_arch_pdevs(d))
> >  
> > +int ioports_setup_access(struct domain *d);
> > +
> >  static inline int ioports_permit_access(struct domain *d, unsigned long s,
> >                                          unsigned long e)
> >  {
> > diff --git a/xen/arch/x86/ioport.c b/xen/arch/x86/ioport.c
> > new file mode 100644
> > index 000000000000..dbcd52d37a4f
> > --- /dev/null
> > +++ b/xen/arch/x86/ioport.c
> > @@ -0,0 +1,163 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Guest I/O port address space configuration.
> > + *
> > + * Copyright 2025 Ford Motor Company
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static char __initdata opt_dom0_ioports_disable[200] = "";
> > +string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
> > +
> > +/*
> > + * The I/O permission bitmap size.
> > + * See: comment in nestedhvm_setup()
> > + */
> > +#define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
> > +
> > +/* Hide user-defined I/O ports from the guest OS. */
> > +static void process_dom0_ioports_disable(struct domain *dom0)
> > +{
> > +    unsigned long io_from, io_to;
> > +    char *t, *s = opt_dom0_ioports_disable;
> > +    const char *u;
> > +
> > +    if ( *s == '\0' )
> > +        return;
> > +
> > +    while ( (t = strsep(&s, ",")) != NULL )
> > +    {
> > +        io_from = simple_strtoul(t, &u, 16);
> > +        if ( u == t )
> > +        {
> > +        parse_error:
> > +            printk("Invalid ioport range <%s> "
> > +                   "in dom0_ioports_disable, skipping\n", t);
> > +            continue;
> > +        }
> > +
> > +        if ( *u == '\0' )
> > +            io_to = io_from;
> > +        else if ( *u == '-' )
> > +            io_to = simple_strtoul(u + 1, &u, 16);
> > +        else
> > +            goto parse_error;
> > +
> > +        if ( (*u != '\0') || (io_to < io_from) || (io_to >= 65536) )
> > +            goto parse_error;
> > +
> > +        printk("Disabling dom0 access to ioport range %04lx-%04lx\n",
> > +            io_from, io_to);
> > +
> > +        if ( ioports_deny_access(dom0, io_from, io_to) != 0 )
> > +            BUG();
> > +    }
> > +}
> > +
> > +/* Set the default IO Bitmap. */
> > +int ioports_setup_access(struct domain *d)
> > +{
> > +    unsigned int i, offs;
> > +    int rc;
> > +
> > +    if ( pv_shim )
> > +        return 0;
> > +
> > +#ifdef CONFIG_HVM
> > +    d->arch.hvm.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
> > +    if ( d->arch.hvm.io_bitmap == NULL )
> > +        return -ENOMEM;
> > +
> > +    memset(d->arch.hvm.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
> > +
> > +    if ( !is_hardware_domain(d) )
> > +    {
> > +        /*
> > +         * Allow direct access to the PC debug ports 0x80 and 0xed (they are
> > +         * often used for I/O delays, but the vmexits simply slow things down).
> > +         */
> > +        if ( hvm_port80_allowed )
> > +            __clear_bit(0x80, d->arch.hvm.io_bitmap);
> > +
> > +        __clear_bit(0xed, d->arch.hvm.io_bitmap);
> > +
> > +        return 0;
> > +    }
> > +#endif
> > +
> > +    /* The hardware domain is initially permitted full I/O capabilities. */
> > +    rc = ioports_permit_access(d, 0, 0xFFFF);
> > +
> > +    /* Modify I/O port access permissions. */
> > +
> > +    for ( offs = 0, i = ISOLATE_LSB(i8259A_alias_mask) ?: 2;
> > +          offs <= i8259A_alias_mask; offs += i )
> > +    {
> > +        if ( offs & ~i8259A_alias_mask )
> > +            continue;
> > +        /* Master Interrupt Controller (PIC). */
> > +        rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
> > +        /* Slave Interrupt Controller (PIC). */
> > +        rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
> > +    }
> > +
> > +    /* ELCR of both PICs. */
> > +    rc |= ioports_deny_access(d, 0x4D0, 0x4D1);
> > +
> > +    /* Interval Timer (PIT). */
> > +    for ( offs = 0, i = ISOLATE_LSB(pit_alias_mask) ?: 4;
> > +          offs <= pit_alias_mask; offs += i )
> > +        if ( !(offs & ~pit_alias_mask) )
> > +            rc |= ioports_deny_access(d, PIT_CH0 + offs, PIT_MODE + offs);
> > +
> > +    /* PIT Channel 2 / PC Speaker Control. */
> > +    rc |= ioports_deny_access(d, 0x61, 0x61);
> > +
> > +    /* INIT# and alternative A20M# control. */
> > +    rc |= ioports_deny_access(d, 0x92, 0x92);
> > +
> > +    /* IGNNE# control. */
> > +    rc |= ioports_deny_access(d, 0xF0, 0xF0);
> > +
> > +    /* ACPI PM Timer. */
> > +    if ( pmtmr_ioport )
> > +        rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
> > +
> > +    /* Reset control. */
> > +    rc |= ioports_deny_access(d, 0xCF9, 0xCF9);
> > +
> > +    /* PCI configuration space (NB. 0xCF8 has special treatment). */
> > +    rc |= ioports_deny_access(d, 0xCFC, 0xCFF);
> > +
> > +#ifdef CONFIG_HVM
> > +    if ( is_hvm_domain(d) )
> > +    {
> > +        /* ISA DMA controller, channels 0-3 (incl possible aliases). */
> > +        rc |= ioports_deny_access(d, 0x00, 0x1F);
> > +        /* ISA DMA controller, page registers (incl various reserved ones). */
> > +        rc |= ioports_deny_access(d, 0x80 + !!hvm_port80_allowed, 0x8F);
> > +        /* ISA DMA controller, channels 4-7 (incl usual aliases). */
> > +        rc |= ioports_deny_access(d, 0xC0, 0xDF);
> > +
> > +        /* HVM debug console IO port. */
> > +        rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
> > +                                  XEN_HVM_DEBUGCONS_IOPORT);
> > +        if ( amd_acpi_c1e_quirk )
> > +            rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
> > +    }
> > +#endif
> > +
> > +    /* Command-line I/O ranges. */
> > +    process_dom0_ioports_disable(d);
> > +
> > +    return rc;
> > +}
> > diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
> > index 21158ce1812e..2b8b4d869ee7 100644
> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -17,6 +17,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1033,6 +1034,9 @@ static int __init dom0_construct(const struct boot_domain *bd)
> >      if ( test_bit(XENFEAT_supervisor_mode_kernel, parms.f_required) )
> >          panic("Dom0 requires supervisor-mode execution\n");
> >  
> > +    rc = ioports_setup_access(d);
> > +    BUG_ON(rc != 0);
> > +
> >      rc = dom0_setup_permissions(d);
> >      BUG_ON(rc != 0);
> >  
> > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > index 5c1be854b544..8860f25ffdeb 100644
> > --- a/xen/common/emul/vuart/ns16x50.c
> > +++ b/xen/common/emul/vuart/ns16x50.c
> > @@ -780,9 +780,20 @@ static int ns16x50_init(void *arg)
> >      struct vuart_ns16x50 *vdev = arg;
> >      const struct vuart_info *info = vdev->info;
> >      struct domain *d = vdev->owner;
> > +    int rc;
> >  
> >      ASSERT(vdev);
> >  
> > +    /* Disallow sharing physical I/O port */
> > +    rc = ioports_deny_access(d, info->base_addr,
> > +                             info->base_addr + info->size - 1);
> 
> I would be tempted to move ioports_deny_access to hvm_domain_initialise
> before vuart_init

I thought about it originally, but I decided to keep vuart setup in one place.

> 
> 
> > +    if ( rc )
> > +    {
> > +        ns16x50_err(info, " virtual I/O port range [0x%04lx"PRIx64"..0x%04lx"PRIx64"]: conflict w/ physical range\n",
> > +                    info->base_addr, info->base_addr + info->size - 1);
> 
> 0x%04lx"PRIx64 seems wrong

Agreed, will fix, thanks.

> 
> 
> > +        return rc;
> > +    }
> > +
> >      /* NB: report 115200 baud rate. */
> >      vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
> >      vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
> > -- 
> > 2.51.0
> > 


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:43:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:43:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112557.1460765 (Exim 4.92)
	(envelope-from )
	id 1uuf9N-0002M3-6F; Fri, 05 Sep 2025 22:43:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112557.1460765; Fri, 05 Sep 2025 22: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 1uuf9N-0002Lw-2Y; Fri, 05 Sep 2025 22:43:21 +0000
Received: by outflank-mailman (input) for mailman id 1112557;
 Fri, 05 Sep 2025 22:43:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uuf9L-0002Lq-VK
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:43:19 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uuf9K-0089HM-2I;
 Fri, 05 Sep 2025 22:43:18 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uuf9K-00038z-29;
 Fri, 05 Sep 2025 22:43:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=dlW4ptRpskViitNkkthGRQ+k4S21ADWUgDwEaKKdZmw=; b=
	ELuWVtp9uGzqaOT0Qf4KEy9KVyhvfw0osl+QBCoGTlMqZYKy8ntb4yfng3aRxkk3iOAefWRn1yk5a
	abij5LCSeiXDHeCW8hTnjWCu9kcHeBukGDid9shQ6Y5SAQd4A0DDkbiE0R1EzxIxu0RL3tCbKxRhp
	T2NrzXTjJdGCvzhjY=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:43:17 -0700
To: Stefano Stabellini 
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 14/15] xen/domain: allocate d->irq_caps before
 arch-specific initialization
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-15-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 02:46:29PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
[..]
> >  
> > +    /* Disallow sharing physical IRQ */
> > +    rc = irq_deny_access(d, info->irq);
> > +    if ( rc )
> > +    {
> > +        ns16x50_err(info, "virtual IRQ#%d: conflict w/ physical IRQ: %d\n",
> > +                    info->irq, rc);
> > +        return rc;
> > +    }
> 
> Also this one I wonder if it could be in hvm_domain_initialise, it would
> make more sense to keep the irq_deny_access there, compared to here
> which is supposed to be a generic emulator

I think it is better to have all vuart initialization in one place, at least
until MMIO-based variant is not available. Current code is x86-specific (port
handlers and IRQ emulation), there will be some changes to make code a generic
NS16550 emulator.


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 22:54:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 22:54:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112571.1460775 (Exim 4.92)
	(envelope-from )
	id 1uufK7-00045p-AZ; Fri, 05 Sep 2025 22:54:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112571.1460775; Fri, 05 Sep 2025 22:54: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 1uufK7-00045i-6k; Fri, 05 Sep 2025 22:54:27 +0000
Received: by outflank-mailman (input) for mailman id 1112571;
 Fri, 05 Sep 2025 22:54:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufK6-00045c-HJ
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 22:54:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufK5-0089V3-0k;
 Fri, 05 Sep 2025 22:54:25 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufK5-0003on-0S;
 Fri, 05 Sep 2025 22:54: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=47ePpJhRuJW5EXdaEotAg4TP76Fryf9vbpsXrXvFJyw=; b=
	qM3Gz0bgJ56boc7l5smR5v+tg4hNTbXJk8x0mVWgHFsH/pOmt6oHCPl4/W2l5pCr1hWEBbmAolAX7
	c0T4TQrRloKhFnnZh7204LI2YA1l4f3ACF/fB2YWv7Fx7numZRTUnyU20Q/mbztKMjiSVHZFknU8H
	hScJM5vhfx65DPric=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 15:54:24 -0700
To: Stefano Stabellini 
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 15/15] emul/ns16x50: implement IRQ emulation via
 vIOAPIC
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-16-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Aug 29, 2025 at 03:21:13PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
> > PVH domains use vIOAPIC, not vPIC and NS16550 emulates ISA IRQs which cannot
> > be asserted on vIOAPIC.
> 
> One option is to enable the vPIT for PVH domains when the NS16550
> emulator is enabled. Would that resolve the problem? That would be a
> simpler solution compared to adding IRQ_EMU because the IRQ_* logic is
> already quite complex.

vPIC? (PIT is timer).

I tried to enable vPIC for hwdom, but there's some more work to make it work
:-/

> 
> Alternatively...
[..]
> 
> > --- a/xen/arch/x86/hvm/vioapic.c
> > +++ b/xen/arch/x86/hvm/vioapic.c
> > @@ -177,6 +177,16 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi, unsigned int trig,
> >  
> >      ASSERT(is_hardware_domain(currd));
> >  
> > +    /*
> > +     * Interrupt is claimed by one of the platform virtual devices (e.g.
> > +     * NS16550); do nothing.
> > +     */
> > +    write_lock(&currd->event_lock);
> > +    ret = domain_irq_to_emuirq(currd, gsi);
> > +    write_unlock(&currd->event_lock);
> > +    if ( ret != IRQ_UNBOUND )
> > +        return 0;
> 
> ..alternatively, we could have an add-hoc check here? Not very nice but
> at least it would be very simple.
> 
> In other words, adding vPIT is preferable in my opinion but as a second
> option I would consider an ad-hoc check. I would try to avoid adding
> IRQ_EMU -- that should be the last resort in my view.

In my opinion, IRQ_EMU falls into category of an ad-hoc.

I think vioapic_hwdom_map_gsi() should not depend on the presence of certain
virtual devices but rely on some global flag, e.g. via quering
domain_irq_to_emuirq() infra.


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:01:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:01:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112585.1460792 (Exim 4.92)
	(envelope-from )
	id 1uufR2-0005mt-38; Fri, 05 Sep 2025 23:01:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112585.1460792; Fri, 05 Sep 2025 23: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 1uufR2-0005mm-0G; Fri, 05 Sep 2025 23:01:36 +0000
Received: by outflank-mailman (input) for mailman id 1112585;
 Fri, 05 Sep 2025 23:01:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uufR0-0005mQ-TH
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:01:34 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2415::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41f88c2d-8aac-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 01:01:29 +0200 (CEST)
Received: from SJ0PR13CA0133.namprd13.prod.outlook.com (2603:10b6:a03:2c6::18)
 by IA0PPF04DCE520E.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bc5) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 5 Sep
 2025 23:01:23 +0000
Received: from SN1PEPF0002BA52.namprd03.prod.outlook.com
 (2603:10b6:a03:2c6:cafe::49) by SJ0PR13CA0133.outlook.office365.com
 (2603:10b6:a03:2c6::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.7 via Frontend Transport; Fri, 5
 Sep 2025 23:01:22 +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.9094.14 via Frontend Transport; Fri, 5 Sep 2025 23:01:21 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 5 Sep
 2025 18:01:21 -0500
Received: from ubuntu-20.04.2-arm64.shared (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, 5 Sep 2025 18:01: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: 41f88c2d-8aac-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=smZvHJG61cCBWlYzq0HdJhsdlIJn0wQMSd0r18lXGWg10ba8AY6YPUZ6R2mvYg3Dp46eT8YkyDV1cIU1OjhPYWyvaa09zbGplgNa2vJDJ2wToIdYgDZ7TPFfyh0z1XJ6+8gAngPnpgeSf6RPizlXKcS47CtTsZR2tbM4ZFrqvUPxL0L2XqMi1vBQ7sW3uwyh4cqv91CwwoiBbAxVq1rlQUR+jnSRyEjNC6h1M/oA2OKICggGJYS5PrFzUhoDbMeerDgBaZS/vI6+PKxZDYjWijQsXrko0yxAORyeDEvRF/wVGzX7Kyb3H9app4S6HD118d+Cobn/mgCTbL4W3xxxnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=urw86vEP5XP4TfLRn0BEWIyixbASdSjSHwutCjQC5mY=;
 b=wynd2fdRPY5n4lQggGnSTGXvylKZUpEqBIiXxmoFGYEJKgweLiUZ5uN1+qEZw9upqNJ1v2oi/9JoC8Izd4ZbVZ9943LzyCxcLXUTKdfzqMB3sJD/34lp4k1hC3PJ8xE7fZnN8E1DztWtxU+R2SkPsg17AOrahSS71gdDZr6hzYpvEtE+IOB+k/NX8dDySTCUMXN0PZI80+oS643tqBFUai+rZ6hTIiDKP8Tmg7RcG06DAI/Vx4h9fH78trlwscgCO61DAwdAdIPbpQXkuj7OU8x5Cq2CSHXbzenMsxJaYneKZOFvvpQVtvH2N5U+WfcZthL/SrI+jWgbQ+G29LRR0g==
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=urw86vEP5XP4TfLRn0BEWIyixbASdSjSHwutCjQC5mY=;
 b=rChykOvpBFnk/XsChKbBQ6Aig4+GtLGHlk7aZ5Imh6yeqMqpxVA5NVQWzwasmxb2FMmfOqmOqIVMh8pUN1mJx6mmfxuNgpF2zOwTFcMRN2unPvj363GdJi01CY5YXVCu79u0a6LWwJAYLO8Cp01Byxdzmbf2X3kubnXf+A/InxI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.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: Fri, 5 Sep 2025 16:01:15 -0700
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: 
CC: Stefano Stabellini ,
	, ,
	, , ,
	, , 
Subject: Re: [PATCH v5 15/15] emul/ns16x50: implement IRQ emulation via
 vIOAPIC
In-Reply-To: 
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com> <20250828235409.2835815-16-dmukhin@ford.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Received-SPF: None (SATLEXMB04.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA52:EE_|IA0PPF04DCE520E:EE_
X-MS-Office365-Filtering-Correlation-Id: 226e5b11-2895-47a1-139f-08ddecd021bc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?5d/Ymsoh3Q56SHOcmeGphMNlxWdKsBlc/kqKxn9CXNF+XN3Oyu5sI1SYcj1f?=
 =?us-ascii?Q?Q3pUITA5F+YOQ7v0lSd6tBuenj6Wlle+LvV8/lXiQu4T3Qe688ZqA1Dizaz7?=
 =?us-ascii?Q?HvA6+iL+zt3VsMwoBqeg2NAIOIwu30vDhepajRq88hQWUf+n/cOpXU6fvVbP?=
 =?us-ascii?Q?JIxMi3qN3QRGqUUkgYm+KetAvGnTvBb0Ae8hQinwvgLxC5lThXSRbGrooZxL?=
 =?us-ascii?Q?iVVYJzWDmDsU9ltlp2RkK+4t15/+pP5H+tsodAIk7T5cXqJnglOPu7MThp9B?=
 =?us-ascii?Q?cDnrSyoEI2rit25+DPikppPs3fUd8xbHNAWaFZyJB/lh24JwQh2qKdSixQ5f?=
 =?us-ascii?Q?uXqN6pqN5D5U1w7Vii3T6qZBzwC2/L0JGY+7D/cXoHz2eEkixL2eZ3m7hdYp?=
 =?us-ascii?Q?gkjbSXbottDyFUGaOqZ9b4zTVnSTfQGauVyssHwUXSHAC/9/0p+ofIGAB8cu?=
 =?us-ascii?Q?98QyJFRXQi1m8JcDc1mYojgFX11ptxn3Imuc7ruNsKi0mWXE0ISajaGE2W7f?=
 =?us-ascii?Q?H9XQsDYsLHD8H0n1VtHCQHg/kO4LFAnMhRpC4uh3W4Ate+H0PsBjpNnmZt3Q?=
 =?us-ascii?Q?UgZ+n/tW9o5S7mR7NZ6aEsfcNg4s9qKn/xQbfreHRY9/DYgGdnetbuo9q1I9?=
 =?us-ascii?Q?9NSc48+k1l28H5uaXp1cyr21k7Ck57ZAmmZA2xKt+vhli7VQVgBxm6S4HKwP?=
 =?us-ascii?Q?lF7WNBXcG/jkknBCYeW+OSju+Bawt8+8Y82b+hTtEmla7Q+bMNLQUTUgS+5C?=
 =?us-ascii?Q?2xm/AWej4HSkbfpoZNnahzNoZGl9mRUlXOgfkNcSU/yNzj8F0HD52cldNArX?=
 =?us-ascii?Q?WR641eCfj6Pz4TsjViww0loi//C6br2v+QvDQUclGNEe/eLyAFEEFjFucztN?=
 =?us-ascii?Q?XyWL2nJ2l5dOQCM1jWDpHI0Gv2e+Jc/uITU6ysgE0iRs2+QozXimWwyrUJqH?=
 =?us-ascii?Q?Pus/uHG/pQdLXf1EMtLO1D427gpXTwtU/b8G0KYqD05NFHHv9nhKSXO0h2oJ?=
 =?us-ascii?Q?LRQ/gnI5SvKYXz0+TVfG4BF4JnXjTNgAO7LKh5rp53RlZ7tDC2l7jdsKQsi1?=
 =?us-ascii?Q?Z7yXj7I5ZPtUkxOeMJdU5ybSz1grc63ibIixeqLpC9JxywWVb6ay78bK6DMh?=
 =?us-ascii?Q?dJRpKQTKcnV20MS1u1GD45+pOC4j9vu88AlB1MZqxyl9/Xqg5lvyIdJLFliv?=
 =?us-ascii?Q?bunegtfygpmdnhdbMR/AFY186ZX3Xb7knTMW00eIdHC01R5/idSQxEkpSR4v?=
 =?us-ascii?Q?de7vA3WcAQyyNooxW7uxb9fEe2uAH8RVwNXQuD71qPneR8cX1UpLDmSMI782?=
 =?us-ascii?Q?dnKcotT3Zspu8niIQxee8WXsuMSFVX/El1W2DJoID0L4RpFP7PXOyqo+Frsx?=
 =?us-ascii?Q?M1921rh7BHaR8IopNCSaBfEJg3FI30rBRZr3mxd/K1LzTye1Ham00kmusJMl?=
 =?us-ascii?Q?u2srUr+Hn6RAnOCOeJSaChfa7t8vtiWc4HuG1FHeKpGmOENJchALzUzgn61V?=
 =?us-ascii?Q?DvDZYnzSTbk5KLeDZ9WRaqGmTuLjoeBa697Q?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2025 23:01:21.9160
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 226e5b11-2895-47a1-139f-08ddecd021bc
X-MS-Exchange-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: IA0PPF04DCE520E

On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> On Fri, Aug 29, 2025 at 03:21:13PM -0700, Stefano Stabellini wrote:
> > On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > > From: Denis Mukhin  
> > > 
> > > PVH domains use vIOAPIC, not vPIC and NS16550 emulates ISA IRQs which cannot
> > > be asserted on vIOAPIC.
> > 
> > One option is to enable the vPIT for PVH domains when the NS16550
> > emulator is enabled. Would that resolve the problem? That would be a
> > simpler solution compared to adding IRQ_EMU because the IRQ_* logic is
> > already quite complex.
> 
> vPIC? (PIT is timer).
> 
> I tried to enable vPIC for hwdom, but there's some more work to make it work
> :-/
> 
> > 
> > Alternatively...
> [..]
> > 
> > > --- a/xen/arch/x86/hvm/vioapic.c
> > > +++ b/xen/arch/x86/hvm/vioapic.c
> > > @@ -177,6 +177,16 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi, unsigned int trig,
> > >  
> > >      ASSERT(is_hardware_domain(currd));
> > >  
> > > +    /*
> > > +     * Interrupt is claimed by one of the platform virtual devices (e.g.
> > > +     * NS16550); do nothing.
> > > +     */
> > > +    write_lock(&currd->event_lock);
> > > +    ret = domain_irq_to_emuirq(currd, gsi);
> > > +    write_unlock(&currd->event_lock);
> > > +    if ( ret != IRQ_UNBOUND )
> > > +        return 0;
> > 
> > ..alternatively, we could have an add-hoc check here? Not very nice but
> > at least it would be very simple.
> > 
> > In other words, adding vPIT is preferable in my opinion but as a second
> > option I would consider an ad-hoc check. I would try to avoid adding
> > IRQ_EMU -- that should be the last resort in my view.
> 
> In my opinion, IRQ_EMU falls into category of an ad-hoc.
> 
> I think vioapic_hwdom_map_gsi() should not depend on the presence of certain
> virtual devices but rely on some global flag, e.g. via quering
> domain_irq_to_emuirq() infra.

Hi Denis, the reason why IRQ_EMU is dangerous is that there are a bunch
of checks emuirq != IRQ_PT and also emuirq != IRQ_MSI_EMU which I don't
know if they would still behave correctly after the introduction of
IRQ_EMU.

I would prefer to avoid the problem if possible...


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:09:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:09:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112596.1460803 (Exim 4.92)
	(envelope-from )
	id 1uufYt-0006O7-S2; Fri, 05 Sep 2025 23:09:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112596.1460803; Fri, 05 Sep 2025 23:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uufYt-0006O0-P6; Fri, 05 Sep 2025 23:09:43 +0000
Received: by outflank-mailman (input) for mailman id 1112596;
 Fri, 05 Sep 2025 23:09:42 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufYs-0006Nu-2p
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:09:42 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufYr-0089q6-1z;
 Fri, 05 Sep 2025 23:09:41 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufYr-0004XY-1n;
 Fri, 05 Sep 2025 23:09: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=Fg/0JxIYvStP1qtDpSryR7zUxh5KKChKQZ4wWVtdWSc=; b=
	x3gPr8nZoGxhPc8p3YQ2eIxC6CUQCm9alHFQ754HcjeLHScA03XrLsqzj26HMiRil78y6Ovq+PSmK
	RP99/Cvz/kZM1kb+Pl/aJYzwxMSYmDSgTS4BewXHNqs91XZTIc8jbgXFRjAVVVzDdHaqMA3BIuXS7
	uNIGm/lpWfaX96Lkg=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 16:09:40 -0700
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Subject: Re: [PATCH v2] x86: Fix AMD_SVM and INTEL_VMX dependency
Message-ID: 
References: <20250902074048.12094-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250902074048.12094-1-michal.orzel@amd.com>

On Tue, Sep 02, 2025 at 09:40:48AM +0200, Michal Orzel wrote:
> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
> INTEL_VMX on INTEL. This dependency was reflected using 'if' next to a
> prompt which is incorrect as it that deals only with the visibility of the
> given Kconfig option. This makes it impossible to e.g. disable INTEL_VMX
> when INTEL is disabled (option is hidden). Fix it while keeping the
> possibility of e.g. enabling INTEL_VMX when INTEL is disabled.
> 
> Fixes: e3ed540f2e9f ("x86/hvm: add HVM-specific Kconfig")
> Signed-off-by: Michal Orzel 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:19:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:19:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112606.1460812 (Exim 4.92)
	(envelope-from )
	id 1uufiD-00082E-M4; Fri, 05 Sep 2025 23:19:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112606.1460812; Fri, 05 Sep 2025 23:19: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 1uufiD-000827-JR; Fri, 05 Sep 2025 23:19:21 +0000
Received: by outflank-mailman (input) for mailman id 1112606;
 Fri, 05 Sep 2025 23:19:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufiC-000821-M8
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:19:20 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufiA-008A27-27;
 Fri, 05 Sep 2025 23:19:18 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufiA-0004py-1j;
 Fri, 05 Sep 2025 23:19:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=HarwgU/ebD3NnpAVWy3W47LnLP6H4RNJf1DstkD4+2o=; b=
	UKZKlXYnmU4s1ZF1UxwPQsYgcvYlwmLLrX3qrQDj2as7x93lVrh+gSAwJ8P8t/vRWzb8FwFUx4eTH
	YghAaEUJDeXxv0biUbrekKiQHtEIukvgBO5LLVdxRcZW/M+jQojs83CkXCPwOc6LGtWsGGZGM+HVN
	trffvMsG/cpEiW+ww=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 16:19:17 -0700
To: Anthony PERARD 
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 v17 3/4] tools/tests: introduce unit tests for domain ID
 allocator
Message-ID: 
References: <20250829232132.3460081-1-dmukhin@ford.com>
 <20250829232132.3460081-4-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Thu, Sep 04, 2025 at 03:50:38PM +0200, Anthony PERARD wrote:
> On Fri, Aug 29, 2025 at 04:21:31PM -0700, dmukhin@xen.org wrote:
> > diff --git a/tools/tests/domid/Makefile b/tools/tests/domid/Makefile
> > new file mode 100644
> > index 000000000000..22f1f15d11db
> > --- /dev/null
> > +++ b/tools/tests/domid/Makefile
> > +# NB: $1 cannot be a list
> 
> Why not? It would be the same as writing the rule multiple time for
> different targets.
> 
> Is about my comment on "prerequisite" on v16? In this rule, "harness.h"
> is a prerequisite.

Sorry for late response.

I see the series is already comitted (thanks!)
I will send a fixup patch for that, since this fragment can be re-used in new
tests.

> 
> > +define emit-harness-nested-rule
> > +$(1): $(CURDIR)/harness.h
> > +	mkdir -p $$(@D);
> > +	ln -sf $$< $$@;
> > +
> > +endef
> > diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
> > new file mode 100644
> > index 000000000000..5915c4699a5c
> > --- /dev/null
> > +++ b/tools/tests/domid/test-domid.c
> > +
> > +#include 
> > +
> > +#include "harness.h"
> > +
> > +#define verify(exp, fmt, args...) \
> > +while (!(exp)) { \
> > +    printf(fmt, ## args); \
> > +    exit(EX_SOFTWARE); \
> 
> We never used any of "EX_*" macro, or even . I'm not sure
> it's a good idea to introduce such use where exit(1) would have been
> more than enough but sysexits.h seems to be available on BSD so it's
> probably fine. It would be nice to change that to exit(1) and remove
> sysexits.h.

re: sysexits.h: muscle memory.
I can fix this up too in a follow on patch, please let me know.

> 
> Anyway, patch looks good enough so:
> Reviewed-by: Anthony PERARD 

Thanks!


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112629.1460833 (Exim 4.92)
	(envelope-from )
	id 1uufpy-0001RU-Pq; Fri, 05 Sep 2025 23:27:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112629.1460833; Fri, 05 Sep 2025 23: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 1uufpy-0001RN-N2; Fri, 05 Sep 2025 23:27:22 +0000
Received: by outflank-mailman (input) for mailman id 1112629;
 Fri, 05 Sep 2025 23:27:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufpw-0001D3-5F
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:20 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufpv-008AAR-1f;
 Fri, 05 Sep 2025 23:27:19 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufpv-0005Cq-1W;
 Fri, 05 Sep 2025 23: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=MYkyC6HYAaTUnjoaK5ptXN+ThND9+Vyev3ekOb2IdWs=; b=xvoeLoJZGZHuCKx2sFifB+DACp
	3ZajkUZdufXzQrU1RtfyA3KBzWWw3frwXnuaByOFGCNivT0ozEAHgDS3Q/DjX/jL7Brs9Kmh+1MO9
	KmDrkBg2qzULo5xzGEGV8kGeruFJFZYR82vHZHvydO8j1kh2oLl4aM3rDrUlOlFknrmI=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 01/15] emul/vuart: introduce framework for UART emulators
Date: Fri,  5 Sep 2025 16:27:00 -0700
Message-ID: <20250905232715.440758-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

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_VUART_FRAMEWORK, which will be
automatically enabled once the user enables any UART emulator.

Current implementation supports maximum of one vUART of each kind per domain.

Use new domain_has_vuart() in the console driver code to check whether to
forward console input to the domain using vUART.

Enable console forwarding over vUART for hardware domains with a vUART. That
enables console forwarding to dom0 on x86, since console can be forwarded only
to Xen, dom0 and pvshim on x86 as of now.

Note: existing vUARTs are deliberately *not* hooked to the new framework to
minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" (i.e.
minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified.

No functional changes for non-x86 architectures.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- addressed v5 feedback
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-2-dmukhin@ford.com/
---
 xen/arch/arm/xen.lds.S         |   1 +
 xen/arch/ppc/xen.lds.S         |   1 +
 xen/arch/riscv/xen.lds.S       |   1 +
 xen/arch/x86/xen.lds.S         |   1 +
 xen/common/Kconfig             |   2 +
 xen/common/Makefile            |   1 +
 xen/common/emul/Kconfig        |   6 ++
 xen/common/emul/Makefile       |   1 +
 xen/common/emul/vuart/Kconfig  |   6 ++
 xen/common/emul/vuart/Makefile |   1 +
 xen/common/emul/vuart/vuart.c  | 157 +++++++++++++++++++++++++++++++++
 xen/common/keyhandler.c        |   3 +
 xen/drivers/char/console.c     |   6 +-
 xen/include/xen/sched.h        |   4 +
 xen/include/xen/serial.h       |   3 +
 xen/include/xen/vuart.h        | 116 ++++++++++++++++++++++++
 xen/include/xen/xen.lds.h      |  10 +++
 17 files changed, 319 insertions(+), 1 deletion(-)
 create mode 100644 xen/common/emul/Kconfig
 create mode 100644 xen/common/emul/Makefile
 create mode 100644 xen/common/emul/vuart/Kconfig
 create mode 100644 xen/common/emul/vuart/Makefile
 create mode 100644 xen/common/emul/vuart/vuart.c
 create mode 100644 xen/include/xen/vuart.h

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index db17ff1efa98..cd05b18770f4 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -58,6 +58,7 @@ SECTIONS
        *(.rodata)
        *(.rodata.*)
        VPCI_ARRAY
+       VUART_ARRAY
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 1de0b77fc6b9..f9d4e5b0dcd8 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -52,6 +52,7 @@ SECTIONS
         *(.rodata)
         *(.rodata.*)
         VPCI_ARRAY
+        VUART_ARRAY
         *(.data.rel.ro)
         *(.data.rel.ro.*)
 
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index edcadff90bfe..59dcaa5fef9a 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -47,6 +47,7 @@ SECTIONS
         *(.rodata)
         *(.rodata.*)
         VPCI_ARRAY
+        VUART_ARRAY
         *(.data.rel.ro)
         *(.data.rel.ro.*)
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 966e514f2034..d877b93a6964 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -132,6 +132,7 @@ SECTIONS
        *(.rodata)
        *(.rodata.*)
        VPCI_ARRAY
+       VUART_ARRAY
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 76f9ce705f7a..78a32b69e2b2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -676,4 +676,6 @@ config PM_STATS
 	  Enable collection of performance management statistics to aid in
 	  analyzing and tuning power/performance characteristics of the system
 
+source "common/emul/Kconfig"
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 0c7d0f5d46e1..8c8462565050 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += domid.o
+obj-y += emul/
 obj-y += event_2l.o
 obj-y += event_channel.o
 obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o
diff --git a/xen/common/emul/Kconfig b/xen/common/emul/Kconfig
new file mode 100644
index 000000000000..7c6764d1756b
--- /dev/null
+++ b/xen/common/emul/Kconfig
@@ -0,0 +1,6 @@
+menu "Domain Emulation Features"
+	visible if EXPERT
+
+source "common/emul/vuart/Kconfig"
+
+endmenu
diff --git a/xen/common/emul/Makefile b/xen/common/emul/Makefile
new file mode 100644
index 000000000000..ae0b575c3901
--- /dev/null
+++ b/xen/common/emul/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VUART_FRAMEWORK) += vuart/
diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig
new file mode 100644
index 000000000000..ce1b976b7da7
--- /dev/null
+++ b/xen/common/emul/vuart/Kconfig
@@ -0,0 +1,6 @@
+config VUART_FRAMEWORK
+	bool
+
+menu "UART Emulation"
+
+endmenu
diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makefile
new file mode 100644
index 000000000000..97f792dc6641
--- /dev/null
+++ b/xen/common/emul/vuart/Makefile
@@ -0,0 +1 @@
+obj-y += vuart.o
diff --git a/xen/common/emul/vuart/vuart.c b/xen/common/emul/vuart/vuart.c
new file mode 100644
index 000000000000..3dfcba217248
--- /dev/null
+++ b/xen/common/emul/vuart/vuart.c
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * UART emulator framework.
+ *
+ * Copyright 2025 Ford Motor Company
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define for_each_emulator(e) \
+    for ( e = vuart_array_start; e < vuart_array_end; e++ )
+
+extern const struct vuart_emulator vuart_array_start[];
+extern const struct vuart_emulator vuart_array_end[];
+
+static const struct vuart_emulator *
+vuart_match_by_compatible(const struct domain *d, const char *compat)
+{
+    const struct vuart_emulator *emulator;
+
+    for_each_emulator(emulator)
+        if ( emulator->compatible &&
+             !strncmp(compat, emulator->compatible,
+                      strlen(emulator->compatible)) )
+            return emulator;
+
+    return NULL;
+}
+
+const static struct vuart *
+vuart_find_by_console_permission(const struct domain *d)
+{
+    const struct vuart *vuart = d->console.vuart;
+
+    if ( !vuart || !vuart->emulator || !vuart->emulator->put_rx ||
+         !(vuart->flags & VUART_CONSOLE_INPUT))
+        return NULL;
+
+    return vuart;
+}
+
+struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long addr,
+                                     unsigned long size)
+{
+    struct vuart *vuart = d->console.vuart;
+
+    if ( !vuart || !vuart->info )
+        return NULL;
+
+    if ( addr >= vuart->info->base_addr &&
+         addr + size - 1 <= vuart->info->base_addr + vuart->info->size - 1 )
+        return vuart;
+
+    return NULL;
+}
+
+int vuart_init(struct domain *d, struct vuart_info *info)
+{
+    const struct vuart_emulator *emulator;
+    struct vuart *vuart;
+    int rc;
+
+    if ( d->console.vuart )
+        return -EBUSY;
+
+    emulator = vuart_match_by_compatible(d, info->compatible);
+    if ( !emulator )
+        return -ENODEV;
+
+    vuart = xzalloc(typeof(*vuart));
+    if ( !vuart )
+        return -ENOMEM;
+
+    vuart->info = xvzalloc(typeof(*info));
+    if ( !vuart->info )
+    {
+        rc = -ENOMEM;
+        goto err_out;
+    }
+    memcpy(vuart->info, info, sizeof(*info));
+
+    vuart->vdev = emulator->alloc(d, vuart->info);
+    if ( IS_ERR(vuart->vdev) )
+    {
+        rc = PTR_ERR(vuart->vdev);
+        goto err_out;
+    }
+
+    vuart->emulator = emulator;
+    vuart->owner = d;
+    vuart->flags |= VUART_CONSOLE_INPUT;
+
+    d->console.input_allowed = true;
+    d->console.vuart = vuart;
+
+    return 0;
+
+ err_out:
+    if ( vuart )
+        xvfree(vuart->info);
+    xvfree(vuart);
+
+    return rc;
+}
+
+/*
+ * Release any resources taken by UART emulators.
+ *
+ * NB: no flags are cleared, since currently exit() is called only during
+ * domain destroy.
+ */
+void vuart_deinit(struct domain *d)
+{
+    struct vuart *vuart = d->console.vuart;
+
+    if ( vuart )
+    {
+        vuart->emulator->free(vuart->vdev);
+        xvfree(vuart->info);
+    }
+    XVFREE(d->console.vuart);
+}
+
+void vuart_dump_state(const struct domain *d)
+{
+    struct vuart *vuart = d->console.vuart;
+
+    if ( vuart )
+        vuart->emulator->dump_state(vuart->vdev);
+}
+
+/*
+ * Put character to the *first* suitable emulated UART's FIFO.
+ */
+int vuart_put_rx(struct domain *d, char c)
+{
+    const struct vuart *vuart = vuart_find_by_console_permission(d);
+
+    return vuart ? vuart->emulator->put_rx(vuart->vdev, c) : -ENODEV;
+}
+
+bool domain_has_vuart(const struct domain *d)
+{
+    return vuart_find_by_console_permission(d);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index cb6df2823b00..156e64d9eb58 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static unsigned char keypress_key;
@@ -352,6 +353,8 @@ static void cf_check dump_domains(unsigned char key)
                            v->periodic_period / 1000000);
             }
         }
+
+        vuart_dump_state(d);
     }
 
     for_each_domain ( d )
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9bd5b4825da6..d5164897a776 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86
 #include 
@@ -596,11 +597,12 @@ static void __serial_rx(char c)
     if ( !d )
         return;
 
-    if ( is_hardware_domain(d) )
+    if ( is_hardware_domain(d) && !domain_has_vuart(d) )
     {
         /*
          * 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) != SERIAL_RX_SIZE )
             serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
@@ -611,6 +613,8 @@ static void __serial_rx(char c)
          */
         send_global_virq(VIRQ_CONSOLE);
     }
+    else if ( domain_has_vuart(d) )
+        rc = vuart_put_rx(d, c);
 #ifdef CONFIG_SBSA_VUART_CONSOLE
     else
         /* Deliver input to the emulated UART. */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 02bdc256ce37..613f4596e33d 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -660,6 +661,9 @@ struct domain
     struct {
         /* Permission to take ownership of the physical console input. */
         bool input_allowed;
+#ifdef CONFIG_VUART_FRAMEWORK
+        struct vuart *vuart;
+#endif
     } console;
 } __aligned(PAGE_SIZE);
 
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 8e1844555208..123eee67df35 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -36,6 +36,9 @@ struct vuart_info {
     unsigned long data_off;     /* Data register offset */
     unsigned long status_off;   /* Status register offset */
     unsigned long status;       /* Ready status value */
+    unsigned int irq;           /* Interrupt */
+    char compatible[16];        /* Compatible string */
+    char name[16];              /* User-friendly name */
 };
 
 struct serial_port {
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
new file mode 100644
index 000000000000..54f2f29f3f4a
--- /dev/null
+++ b/xen/include/xen/vuart.h
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * UART emulator framework.
+ *
+ * Copyright 2025 Ford Motor Company
+ */
+
+#ifndef XEN_VUART_H
+#define XEN_VUART_H
+
+#include 
+#include 
+
+struct vuart_emulator;
+
+enum {
+    VUART_CONSOLE_INPUT = BIT(0, U), /* Physical console input forwarding. */
+};
+
+
+/*
+ * FIXME: #ifdef is temporary to avoid clash with
+ *   arch/arm/include/asm/domain.h
+ */
+#ifdef CONFIG_VUART_FRAMEWORK
+struct vuart {
+    const struct vuart_emulator *emulator;
+    struct vuart_info *info;
+    struct domain *owner;
+    uint32_t flags;
+    void *vdev;
+};
+#endif
+
+struct vuart_emulator {
+    /* UART compatible string. Cannot be NULL or empty. */
+    const char *compatible;
+
+    /*
+     * Allocate emulated UART state (RX/TX FIFOs, locks, initialize registers,
+     * hook I/O handlers, etc.)
+     * Cannot be NULL.
+     */
+    void *(*alloc)(struct domain *d, const struct vuart_info *info);
+
+    /*
+     * Release resources used to emulate UART state (flush RX/TX FIFOs, unhook
+     * I/O handlers, etc.).
+     * Cannot be NULL.
+     */
+    void (*free)(void *arg);
+
+    /*
+     * Print emulated UART state, including registers, on the console.
+     * Can be NULL.
+     */
+    void (*dump_state)(void *arg);
+
+    /*
+     * Place character to the emulated RX FIFO.
+     * Used to forward physical console input to the guest OS.
+     * Can be NULL.
+     */
+    int (*put_rx)(void *arg, char c);
+};
+
+#define VUART_REGISTER(name, x) \
+    static const struct vuart_emulator name##_entry \
+        __used_section(".data.rel.ro.vuart") = x
+
+struct vuart *vuart_find_by_io_range(struct domain *d,
+                                     unsigned long base_addr,
+                                     unsigned long size);
+
+int vuart_put_rx(struct domain *d, char c);
+
+#ifdef CONFIG_VUART_FRAMEWORK
+
+int vuart_init(struct domain *d, struct vuart_info *info);
+void vuart_deinit(struct domain *d);
+void vuart_dump_state(const struct domain *d);
+bool domain_has_vuart(const struct domain *d);
+
+#else
+
+static inline int vuart_init(struct domain *d, struct vuart_info *info)
+{
+    return 0;
+}
+
+static inline void vuart_deinit(struct domain *d)
+{
+}
+
+static inline void vuart_dump_state(const struct domain *d)
+{
+}
+
+static inline bool domain_has_vuart(const struct domain *d)
+{
+    return false;
+}
+
+#endif /* CONFIG_VUART_FRAMEWORK */
+
+#endif /* XEN_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/xen.lds.h b/xen/include/xen/xen.lds.h
index b126dfe88792..2d65f32ddad3 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -194,4 +194,14 @@
 #define VPCI_ARRAY
 #endif
 
+#ifdef CONFIG_VUART_FRAMEWORK
+#define VUART_ARRAY              \
+       . = ALIGN(POINTER_ALIGN); \
+       vuart_array_start = .;    \
+       *(.data.rel.ro.vuart)     \
+       vuart_array_end = .;
+#else
+#define VUART_ARRAY
+#endif
+
 #endif /* __XEN_LDS_H__ */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112631.1460853 (Exim 4.92)
	(envelope-from )
	id 1uufq0-0001th-At; Fri, 05 Sep 2025 23:27:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112631.1460853; Fri, 05 Sep 2025 23:27: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 1uufq0-0001tR-53; Fri, 05 Sep 2025 23:27:24 +0000
Received: by outflank-mailman (input) for mailman id 1112631;
 Fri, 05 Sep 2025 23:27:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufpy-0001R9-FT
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:22 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufpx-008AAl-2a;
 Fri, 05 Sep 2025 23:27:22 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufpx-0005Cy-2T;
 Fri, 05 Sep 2025 23:27: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=a/PKwkvx+jRfizPoTGFi+ZYi2s0jTs51XDlTfdQiefc=; b=NU8wi0uDuTeYxPBth12ouKpgqn
	3doxCkbMyORTJZ1lDYrN7PSMUW8RKxO2an3Mstd3CLAXSOuySjk4lQwMPiBDNVCjpc/UNCqgPVP6Y
	bBa44ogdVmpQFmG+UQaq38mV9dO9Wtpna9lZnYHRZPIBSxPEmSRV49BlzfkoYNdTF55M=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 03/15] emul/ns16x50: implement emulator stub
Date: Fri,  5 Sep 2025 16:27:02 -0700
Message-ID: <20250905232715.440758-4-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

The change is the first on the way on introducing minimally functional
NS16550-compatible UART emulator.

Define UART state and a set of emulated registers.

Implement alloc/free vUART hooks.

Stub out I/O port handler.

Add initialization of the NS16x50-compatible UART emulator state machine.

Plumb debug logging.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- v5 feedback
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-4-dmukhin@ford.com/
---
 xen/arch/x86/hvm/hvm.c          |  21 ++
 xen/common/emul/vuart/Kconfig   |  19 ++
 xen/common/emul/vuart/Makefile  |   1 +
 xen/common/emul/vuart/ns16x50.c | 366 ++++++++++++++++++++++++++++++++
 4 files changed, 407 insertions(+)
 create mode 100644 xen/common/emul/vuart/ns16x50.c

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a1d..91c971f11e14 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -689,6 +690,22 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc != 0 )
         goto fail1;
 
+    /* Limit NS16550 emulator for dom0 only for now. */
+    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && is_hardware_domain(d) )
+    {
+        struct vuart_info info = {
+            .name       = "COM2",
+            .compatible = "ns16550",
+            .base_addr  = 0x2f8,
+            .size       = 8,
+            .irq        = 3,
+        };
+
+        rc = vuart_init(d, &info);
+        if ( rc )
+            goto out_vioapic_deinit;
+    }
+
     stdvga_init(d);
 
     rtc_init(d);
@@ -712,6 +729,8 @@ int hvm_domain_initialise(struct domain *d,
     return 0;
 
  fail2:
+    vuart_deinit(d);
+ out_vioapic_deinit:
     vioapic_deinit(d);
  fail1:
     if ( is_hardware_domain(d) )
@@ -774,6 +793,8 @@ void hvm_domain_destroy(struct domain *d)
     if ( hvm_funcs.domain_destroy )
         alternative_vcall(hvm_funcs.domain_destroy, d);
 
+    vuart_deinit(d);
+
     vioapic_deinit(d);
 
     XFREE(d->arch.hvm.pl_time);
diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig
index ce1b976b7da7..a27d7ca135af 100644
--- a/xen/common/emul/vuart/Kconfig
+++ b/xen/common/emul/vuart/Kconfig
@@ -3,4 +3,23 @@ config VUART_FRAMEWORK
 
 menu "UART Emulation"
 
+config VUART_NS16X50
+	bool "NS16550-compatible UART Emulator" if EXPERT
+	depends on X86 && HVM
+	select VUART_FRAMEWORK
+	default n
+	help
+	  In-hypervisor NS16x50 UART emulation.
+
+	  Only legacy PC COM2 port is emulated.
+
+	  This is strictly for testing purposes (such as early HVM guest console),
+	  and not appropriate for use in production.
+
+config VUART_NS16X50_DEBUG
+	bool "NS16550-compatible UART Emulator Debugging"
+	depends on VUART_NS16X50 && DEBUG
+	help
+	  Enable development debugging.
+
 endmenu
diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makefile
index 97f792dc6641..fe904f6cb65d 100644
--- a/xen/common/emul/vuart/Makefile
+++ b/xen/common/emul/vuart/Makefile
@@ -1 +1,2 @@
 obj-y += vuart.o
+obj-$(CONFIG_VUART_NS16X50) += ns16x50.o
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
new file mode 100644
index 000000000000..0462a961e785
--- /dev/null
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -0,0 +1,366 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * NS16550-compatible UART Emulator.
+ *
+ * See:
+ * - Serial and UART Tutorial:
+ *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-uart_en.pdf
+ * - UART w/ 16 byte FIFO:
+ *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
+ * - UART w/ 64 byte FIFO:
+ *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
+ *
+ * Limitations:
+ * - Only x86;
+ * - Only Xen console as a backend, no inter-domain communication (similar to
+ *   vpl011 on Arm);
+ * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
+ * - No baud rate emulation (reports 115200 baud to the guest OS);
+ * - No FIFO-less mode emulation;
+ * - No RX FIFO interrupt moderation (FCR) emulation;
+ * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
+ *   friends);
+ * - No ISA IRQ sharing allowed;
+ * - No MMIO-based UART emulation.
+ */
+
+#define pr_prefix               "ns16x50"
+#define pr_fmt(fmt)             pr_prefix ": " fmt
+
+#ifdef CONFIG_VUART_NS16X50_DEBUG
+#define guest_prefix            "FROM GUEST "
+#define ns16x50_log_level       2
+#else
+#define guest_prefix            ""
+#define ns16x50_log_level       0
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define ns16x50_log(n, lvl, vdev, fmt, args...) \
+do { \
+    if ( ns16x50_log_level >= n ) \
+        gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \
+} while (0)
+
+#define ns16x50_err(vdev, fmt, args...) \
+    ns16x50_log(0, XENLOG_ERR, vdev, fmt, ## args)
+#define ns16x50_warn(vdev, fmt, args...) \
+    ns16x50_log(1, XENLOG_WARNING, vdev, fmt, ## args)
+#define ns16x50_info(vdev, fmt, args...) \
+    ns16x50_log(2, XENLOG_INFO, vdev, fmt, ## args)
+#define ns16x50_debug(vdev, fmt, args...) \
+    ns16x50_log(3, XENLOG_DEBUG, vdev, fmt, ## args)
+
+/*
+ * Number of supported registers in the UART.
+ */
+#define NS16X50_REGS_NUM        (UART_SCR + 1)
+
+/*
+ * Number of emulated registers.
+ *
+ * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=0.
+ * - DLAB=1, R/W, DLL            = NS16X50_REGS_NUM + 0
+ * - DLAB=1, R/W, DLM            = NS16X50_REGS_NUM + 1
+ * -         R/O, IIR (IIR_THR)  = NS16X50_REGS_NUM + 2
+ */
+#define NS16X50_EMU_REGS_NUM    (NS16X50_REGS_NUM + 3)
+
+/*
+ * Virtual ns16x50 device state.
+ */
+struct vuart_ns16x50 {
+    uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */
+    const struct vuart_info *info;      /* UART description */
+    struct domain *owner;               /* Owner domain */
+    const char *name;                   /* Device name */
+    spinlock_t lock;                    /* Protection */
+    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
+};
+
+static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
+{
+    return 0;
+}
+
+/*
+ * Emulate 8-bit write access to ns16x50 register.
+ */
+static int ns16x50_io_write8(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+/*
+ * Emulate 16-bit write access to ns16x50 register.
+ * NB: some guest OSes use outw() to access UART_DLL.
+ */
+static int ns16x50_io_write16(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
+{
+    int rc = -EINVAL;
+
+    return rc;
+}
+
+/*
+ * Emulate write access to ns16x50 register.
+ */
+static int ns16x50_io_write(
+    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
+{
+    int rc;
+
+    switch ( size )
+    {
+    case 1:
+        rc = ns16x50_io_write8(vdev, reg, (uint8_t *)data);
+        break;
+
+    case 2:
+        rc = ns16x50_io_write16(vdev, reg, (uint16_t *)data);
+        break;
+
+    default:
+        rc = -EINVAL;
+        break;
+    }
+
+    return rc;
+}
+
+/*
+ * Emulate 8-bit read access to ns16x50 register.
+ */
+static int ns16x50_io_read8(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
+{
+    uint8_t val = 0xff;
+    int rc = 0;
+
+    *data = val;
+
+    return rc;
+}
+
+/*
+ * Emulate 16-bit read access to ns16x50 register.
+ */
+static int ns16x50_io_read16(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
+{
+    uint16_t val = 0xffff;
+    int rc = -EINVAL;
+
+    *data = val;
+
+    return rc;
+}
+
+/*
+ * Emulate read access to ns16x50 register.
+ */
+static int ns16x50_io_read(
+    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
+{
+    int rc;
+
+    switch ( size )
+    {
+    case 1:
+        rc = ns16x50_io_read8(vdev, reg, (uint8_t *)data);
+        break;
+
+    case 2:
+        rc = ns16x50_io_read16(vdev, reg, (uint16_t *)data);
+        break;
+
+    default:
+        *data = 0xffffffff;
+        rc = -EINVAL;
+        break;
+    }
+
+    return rc;
+}
+
+/*
+ * Emulate I/O access to ns16x50 register.
+ * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled.
+ */
+static int cf_check ns16x50_io_handle(
+    int dir, unsigned int addr, unsigned int size, uint32_t *data)
+{
+#define op(dir)     (((dir) == IOREQ_WRITE) ? 'W' : 'R')
+    struct domain *d = rcu_lock_current_domain();
+    struct vuart *vuart = vuart_find_by_io_range(d, addr, size);
+    struct vuart_ns16x50 *vdev;
+    const struct domain *owner;
+    const struct vuart_info *info;
+    uint32_t reg;
+    unsigned dlab;
+    int rc;
+
+    if ( !vuart || !vuart->vdev )
+    {
+        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
+               op(dir), addr, size);
+
+        ASSERT_UNREACHABLE();
+        goto out;
+    }
+    vdev = vuart->vdev;
+
+    owner = vuart->owner;
+    ASSERT(owner);
+    if ( d != owner )
+    {
+        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domain %pv\n",
+                    op(dir), addr, size, d);
+
+        ASSERT_UNREACHABLE();
+        goto out;
+    }
+
+    info = vuart->info;
+    ASSERT(info);
+    reg = addr - info->base_addr;
+    if ( !IS_ALIGNED(reg, size) )
+    {
+        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
+                    op(dir), addr, size);
+        goto out;
+    }
+
+    dlab = ns16x50_dlab_get(vdev);
+    if ( reg >= NS16X50_REGS_NUM )
+    {
+        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": not implemented\n",
+                    op(dir), addr, size, dlab, reg, *data);
+        goto out;
+    }
+
+    spin_lock(&vdev->lock);
+
+    if ( dir == IOREQ_WRITE )
+    {
+        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
+                      op(dir), addr, size, dlab, reg, *data);
+        rc = ns16x50_io_write(vdev, reg, size, data);
+    }
+    else
+    {
+        rc = ns16x50_io_read(vdev, reg, size, data);
+        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
+                      op(dir), addr, size, dlab, reg, *data);
+    }
+    if ( rc < 0 )
+        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": unsupported access\n",
+                    op(dir), addr, size, dlab, reg, *data);
+
+    spin_unlock(&vdev->lock);
+
+out:
+    rcu_unlock_domain(d);
+
+    return X86EMUL_OKAY;
+#undef op
+}
+
+static int ns16x50_init(void *arg)
+{
+    struct vuart_ns16x50 *vdev = arg;
+    const struct vuart_info *info = vdev->info;
+    struct domain *d = vdev->owner;
+
+    ASSERT(vdev);
+
+    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
+
+    return 0;
+}
+
+static void cf_check ns16x50_deinit(void *arg)
+{
+    struct vuart_ns16x50 *vdev = arg;
+
+    ASSERT(vdev);
+}
+
+static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info)
+{
+    struct vuart_ns16x50 *vdev;
+    int rc;
+
+    if ( !info )
+        return ERR_PTR(-EINVAL);
+
+    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
+    {
+        ns16x50_err(info, "already registered\n");
+        return ERR_PTR(-EBUSY);
+    }
+
+    if ( !is_hvm_domain(d) )
+    {
+        ns16x50_err(info, "not an HVM domain\n");
+        return ERR_PTR(-ENOSYS);
+    }
+
+    vdev = xvzalloc(typeof(*vdev));
+    if ( !vdev )
+    {
+        ns16x50_err(info, "failed to allocate memory\n");
+        return ERR_PTR(-ENOMEM);
+    }
+
+    spin_lock_init(&vdev->lock);
+    vdev->name = info->name;
+    vdev->owner = d;
+    vdev->info = info;
+
+    rc = ns16x50_init(vdev);
+    if ( rc )
+        return ERR_PTR(rc);
+
+    return vdev;
+}
+
+static void cf_check ns16x50_free(void *arg)
+{
+    if ( arg )
+        ns16x50_deinit(arg);
+
+    xvfree(arg);
+}
+
+#define ns16x50_emulator                \
+{                                       \
+    .compatible = "ns16550",            \
+    .alloc      = ns16x50_alloc,        \
+    .free       = ns16x50_free,         \
+    .dump_state = NULL,                 \
+    .put_rx     = NULL,                 \
+}
+
+VUART_REGISTER(ns16x50, ns16x50_emulator);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112628.1460823 (Exim 4.92)
	(envelope-from )
	id 1uufpw-0001DG-FG; Fri, 05 Sep 2025 23:27:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112628.1460823; Fri, 05 Sep 2025 23: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 1uufpw-0001D9-CZ; Fri, 05 Sep 2025 23:27:20 +0000
Received: by outflank-mailman (input) for mailman id 1112628;
 Fri, 05 Sep 2025 23:27:19 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufpv-0001Cx-CE
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:19 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufpu-008AAL-1r;
 Fri, 05 Sep 2025 23:27:18 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufpu-0005Cj-1F;
 Fri, 05 Sep 2025 23:27:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date:
	Subject:Cc:To:From; bh=p2aQd0QGVDb1N/Ju05/FKFe7cqr0M5bme5n+2GJS1Mo=; b=ymy3rz
	nhq+3wR43e5mCaoduoD4RMd4kfcBWR+ktN//oU8f4+ij4Uwa60ihQDDHB2UAZZVHhtwJsdUAc9g6T
	HllBFx1+Hxa7BPPhsK/P6YUvOMB+qPIB6elbXD4WYDFK4f6A9XmpzicE8CLD5LYKP4Z6b20W2ShwE
	+XNINaC+qzQ=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 00/15] x86: introduce NS16550-compatible UART emulator
Date: Fri,  5 Sep 2025 16:26:59 -0700
Message-ID: <20250905232715.440758-1-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
guest OS bring up in the embedded setups.

This patch series introduces initial in-hypervisor emulator for
NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.

In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
early guest firmware and OS bringup debugging, because it eliminates
dependency on the external emulator (qemu) being operational by the time
domains are created.

The emulator also allows to forward the physical console input to the x86
domain which is useful when a system has only one physical UART for early
debugging and this UART is owned by Xen.

By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O port
0x2f8, IRQ#3 in guest OS (legacy COM2). Legacy COM resources cannot be
selected at built-time or via per-domain xl configuration in this initial
submission.

CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities useful
for NS16550 emulator development/debugging (disabled by default).

The NS16550 emulator is disabled in default x86 configuration and goes under
CONFIG_EXPERT in Kconfig.

Limitations
===========
- Only x86;
- Only legacy COM2 resources, custom I/O ports/IRQs are not supported;
- Only Xen console as a backend, no inter-domain communication (similar to
  vpl011 on Arm);
- Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
- No toolstack integration;
- No baud rate emulation (reports 115200 baud to the guest OS);
- No FIFO-less mode emulation;
- No RX FIFO interrupt moderation (FCR) emulation;
- No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
  friends);
- No MMIO-based UART emulation.

Series
======

  Patch 1 introduces the new vUART framework, that is the code originally
  posted here:
    https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@ford.com/
  Required for emulator.

  Patch 2 adds missing NS16550 definitions, required for emulator.

  Patch 3 introduces the basic emulator skeleton - state machine
  initialization stubs, I/O port handler stub, logging, etc.

  Patches 4-11 incrementally populate the minimal NS16550 register emulation.

  Patch 12 hooks vUART state debugging (disabled by default).

  Pathes 13-15 introduce necessary changes to enable NS16550 on dom0 (and PVH).

Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2024756493
Link to branch: https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-ns8250-v6?ref_type=heads

Testing
=======

  ```shell
  echo CONFIG_EXPERT=y >> .config
  echo CONFIG_VUART_NS16X50=y >> .config
  make olddefconfig
  ```
  COM2 (0x2f8) resources are used by default.

  To test w/ virtual COM2, the guest kernel parameters should contain
  something like the following:
    earlycon=uart,io,0x2f8,115200n8 console=uart,io,0x2f8,115200n8

  HVM
  ---
  Tested only boot of HVM linux guest with OVMF as the virtual firmware.
  SeaBIOS as a virtual firmware is not tested.

  PVH (dom0)
  ----------
  Xen is able to forward physical console input to the domain with virtual
  NS16550. To switch the console focus press Ctrl+aaa.
  Console switch is limited on x86 to dom0 and Xen (fixes pending).

Changes since v5:
- Split THR/RBR into two separate patches.
- Addressed feedback from v5.
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-1-dmukhin@ford.com/

Changes since v4:
- Split the series to make it simpler to review.
- Addressed feedback from v4.
- Dropped xl changes, which I will submit separately.
- Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-1-dmukhin@ford.com/

Changes since v3:
- Reduced the blast radius of the series, thanks to reviews, individual
  aspects (like console focus) touched in v3 moved to separate threads.
- Kept the UART emulator framework since I need to redo some of emulator code
  and there's more-or-less agreement on it (where to place, naming, scope).
- Applied the feedback from
    https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/
- Link to v3: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/

Changes since v2:
- renamed emulator s/NS8250/NS16550/g
- reduced the patch series after addressing v2 feedback
- introduced driver framework for UART emulators
- unified guest OS printouts across all available UART emulators
- Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/

Changes since v1:
- dropped kmalloc/kfree aliases
- fixed ECLAIR jobs (thanks Andrew Cooper)
- addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
- moved NS8250 debugging stubs into its own patch
- added fix for https://gitlab.com/xen-project/xen/-/issues/184
- Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com

Denis Mukhin (15):
  emul/vuart: introduce framework for UART emulators
  xen/8250-uart: update definitions
  emul/ns16x50: implement emulator stub
  emul/ns16x50: implement DLL/DLM registers
  emul/ns16x50: implement SCR register
  emul/ns16x50: implement IER/IIR registers
  emul/ns16x50: implement LCR/LSR registers
  emul/ns16x50: implement MCR/MSR registers
  emul/ns16x50: implement RBR register
  emul/ns16x50: implement THR register
  emul/ns16x50: implement FCR register (write-only)
  emul/ns16550: implement dump_state() hook
  x86/domain: enable per-domain I/O port bitmaps
  xen/domain: allocate d->irq_caps before arch-specific initialization
  emul/ns16x50: implement IRQ emulation via vIOAPIC

 xen/arch/arm/xen.lds.S                   |   1 +
 xen/arch/ppc/xen.lds.S                   |   1 +
 xen/arch/riscv/xen.lds.S                 |   1 +
 xen/arch/x86/Makefile                    |   1 +
 xen/arch/x86/dom0_build.c                | 112 +--
 xen/arch/x86/hvm/dom0_build.c            |   7 +
 xen/arch/x86/hvm/hvm.c                   |  56 +-
 xen/arch/x86/hvm/nestedhvm.c             |   8 +-
 xen/arch/x86/hvm/quirks.c                |   3 -
 xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
 xen/arch/x86/hvm/vioapic.c               |  10 +
 xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
 xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
 xen/arch/x86/include/asm/hvm/support.h   |   2 -
 xen/arch/x86/include/asm/iocap.h         |   2 +
 xen/arch/x86/include/asm/irq.h           |   8 +
 xen/arch/x86/ioport.c                    | 163 ++++
 xen/arch/x86/irq.c                       |   8 +
 xen/arch/x86/pv/dom0_build.c             |   7 +
 xen/arch/x86/xen.lds.S                   |   1 +
 xen/common/Kconfig                       |   2 +
 xen/common/Makefile                      |   1 +
 xen/common/domain.c                      |   8 +-
 xen/common/emul/Kconfig                  |   6 +
 xen/common/emul/Makefile                 |   1 +
 xen/common/emul/vuart/Kconfig            |  25 +
 xen/common/emul/vuart/Makefile           |   2 +
 xen/common/emul/vuart/ns16x50.c          | 984 +++++++++++++++++++++++
 xen/common/emul/vuart/vuart.c            | 157 ++++
 xen/common/keyhandler.c                  |   3 +
 xen/drivers/char/console.c               |   6 +-
 xen/drivers/char/ns16550.c               |  16 +-
 xen/drivers/passthrough/x86/hvm.c        |  11 +-
 xen/include/xen/8250-uart.h              |  50 +-
 xen/include/xen/sched.h                  |   4 +
 xen/include/xen/serial.h                 |   3 +
 xen/include/xen/vuart.h                  | 116 +++
 xen/include/xen/xen.lds.h                |  10 +
 38 files changed, 1634 insertions(+), 171 deletions(-)
 create mode 100644 xen/arch/x86/ioport.c
 create mode 100644 xen/common/emul/Kconfig
 create mode 100644 xen/common/emul/Makefile
 create mode 100644 xen/common/emul/vuart/Kconfig
 create mode 100644 xen/common/emul/vuart/Makefile
 create mode 100644 xen/common/emul/vuart/ns16x50.c
 create mode 100644 xen/common/emul/vuart/vuart.c
 create mode 100644 xen/include/xen/vuart.h

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112630.1460840 (Exim 4.92)
	(envelope-from )
	id 1uufpz-0001Ue-4M; Fri, 05 Sep 2025 23:27:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112630.1460840; Fri, 05 Sep 2025 23: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 1uufpy-0001Tp-T2; Fri, 05 Sep 2025 23:27:22 +0000
Received: by outflank-mailman (input) for mailman id 1112630;
 Fri, 05 Sep 2025 23:27:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufpx-0001Qb-93
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufpw-008AAa-28;
 Fri, 05 Sep 2025 23:27:20 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufpw-0005Cu-1y;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=BLpK09VTDg88f7evdVDCZeeMR5D19RIklWweqNvteTE=; b=B3yHWL2D8KrVQOzUca14u0fQ/r
	Z1XbAhgdfMP6xZpMdCJlLmAjoxj5x5Z4dqTvA9M8L8nXzsv607MCjND/0YJsUeHjwzewx6pRzEdP2
	/T5rxeeTKKAmDQxoQ/CUdp4tKjJjtTMqm6xRcnWyl6YGaSfha8bnydcDo7Y4A3XQouSU=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 02/15] xen/8250-uart: update definitions
Date: Fri,  5 Sep 2025 16:27:01 -0700
Message-ID: <20250905232715.440758-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Added missing definitions needed for NS16550 UART emulator.

Newly introduced MSR definitions re-used in the existing ns16550 driver.

Also, corrected FCR DMA definition bit#3 (0x08) as per:
  https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
See "7.7.2 FIFO Control Register (FCR)".

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- fixed commentaries
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-3-dmukhin@ford.com/
---
 xen/drivers/char/ns16550.c  | 16 ++++++------
 xen/include/xen/8250-uart.h | 50 ++++++++++++++++++++++++++++++-------
 2 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index df7fff7f81df..0e80fadbb894 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -388,7 +388,7 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port)
 
     /* Check this really is a 16550+. Otherwise we have no FIFOs. */
     if ( uart->fifo_size <= 1 &&
-         ((ns_read_reg(uart, UART_IIR) & 0xc0) == 0xc0) &&
+         ((ns_read_reg(uart, UART_IIR) & UART_IIR_FE) == UART_IIR_FE) &&
          ((ns_read_reg(uart, UART_FCR) & UART_FCR_TRG14) == UART_FCR_TRG14) )
         uart->fifo_size = 16;
 }
@@ -728,20 +728,20 @@ static int __init check_existence(struct ns16550 *uart)
      * Mask out IER[7:4] bits for test as some UARTs (e.g. TL
      * 16C754B) allow only to modify them if an EFR bit is set.
      */
-    scratch2 = ns_read_reg(uart, UART_IER) & 0x0f;
-    ns_write_reg(uart,UART_IER, 0x0F);
-    scratch3 = ns_read_reg(uart, UART_IER) & 0x0f;
+    scratch2 = ns_read_reg(uart, UART_IER) & UART_IER_MASK;
+    ns_write_reg(uart, UART_IER, UART_IER_MASK);
+    scratch3 = ns_read_reg(uart, UART_IER) & UART_IER_MASK;
     ns_write_reg(uart, UART_IER, scratch);
-    if ( (scratch2 != 0) || (scratch3 != 0x0F) )
+    if ( (scratch2 != 0) || (scratch3 != UART_IER_MASK) )
         return 0;
 
     /*
      * Check to see if a UART is really there.
      * Use loopback test mode.
      */
-    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | 0x0A);
-    status = ns_read_reg(uart, UART_MSR) & 0xF0;
-    return (status == 0x90);
+    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | UART_MCR_RTS | UART_MCR_OUT2);
+    status = ns_read_reg(uart, UART_MSR) & UART_MSR_STATUS;
+    return (status == (UART_MSR_CTS | UART_MSR_DCD));
 }
 
 #ifdef CONFIG_HAS_PCI
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index d13352940c13..bbbffb14d320 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SCR          0x07    /* Scratch pad          */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -42,6 +43,8 @@
 #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
 #define UART_IER_ELSI     0x04    /* rx line status       */
 #define UART_IER_EMSI     0x08    /* MODEM status         */
+#define UART_IER_MASK \
+    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
 
 /* Interrupt Identification Register */
 #define UART_IIR_NOINT    0x01    /* no interrupt pending */
@@ -51,12 +54,19 @@
 #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
 #define UART_IIR_MSI      0x00    /*  - MODEM status      */
 #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
+#define UART_IIR_FE       0xc0    /* FIFO enabled (2 bits) */
 
 /* FIFO Control Register */
-#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
-#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
-#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
-#define UART_FCR_DMA      0x10    /* enter DMA mode       */
+#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
+#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
+#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
+#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */
+#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
+#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */
+#define UART_FCR_RTB0       BIT(6, U)   /* receiver trigger bit #0 */
+#define UART_FCR_RTB1       BIT(7, U)   /* receiver trigger bit #1 */
+#define UART_FCR_TRG_MASK   (UART_FCR_RTB0 | UART_FCR_RTB1)
+
 #define UART_FCR_TRG1     0x00    /* Rx FIFO trig lev 1   */
 #define UART_FCR_TRG4     0x40    /* Rx FIFO trig lev 4   */
 #define UART_FCR_TRG8     0x80    /* Rx FIFO trig lev 8   */
@@ -96,11 +106,32 @@
 #define UART_LCR_CONF_MODE_B	0xBF		/* Configuration mode B */
 
 /* Modem Control Register */
-#define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
-#define UART_MCR_RTS      0x02    /* Request to Send      */
-#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
-#define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
-#define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
+#define UART_MCR_DTR            BIT(0, U)   /* Data Terminal Ready  */
+#define UART_MCR_RTS            BIT(1, U)   /* Request to Send      */
+#define UART_MCR_OUT1           BIT(2, U)   /* Output #1 */
+#define UART_MCR_OUT2           BIT(3, U)   /* Output #2 */
+#define UART_MCR_LOOP           BIT(4, U)   /* Enable loopback test mode */
+#define UART_MCR_RESERVED0      BIT(5, U)   /* Reserved #0 */
+#define UART_MCR_TCRTLR         BIT(6, U)   /* Access TCR/TLR (TI16C752, EFR[4]=1) */
+#define UART_MCR_RESERVED1      BIT(7, U)   /* Reserved #1 */
+#define UART_MCR_MASK \
+    (UART_MCR_DTR | UART_MCR_RTS | \
+     UART_MCR_OUT1 | UART_MCR_OUT2 | \
+     UART_MCR_LOOP | UART_MCR_TCRTLR)
+
+/* Modem Status Register */
+#define UART_MSR_DCTS           BIT(0, U)   /* Change in CTS */
+#define UART_MSR_DDSR           BIT(1, U)   /* Change in DSR */
+#define UART_MSR_TERI           BIT(2, U)   /* Change in RI */
+#define UART_MSR_DDCD           BIT(3, U)   /* Change in DCD */
+#define UART_MSR_CTS            BIT(4, U)
+#define UART_MSR_DSR            BIT(5, U)
+#define UART_MSR_RI             BIT(6, U)
+#define UART_MSR_DCD            BIT(7, U)
+#define UART_MSR_CHANGE \
+    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
+#define UART_MSR_STATUS \
+    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
 
 /* Line Status Register */
 #define UART_LSR_DR       0x01    /* Data ready           */
@@ -111,6 +142,7 @@
 #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
 #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
 #define UART_LSR_ERR      0x80    /* Error                */
+#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)
 
 /* These parity settings can be ORed directly into the LCR. */
 #define UART_PARITY_NONE  (0<<3)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112632.1460863 (Exim 4.92)
	(envelope-from )
	id 1uufq1-00029o-O9; Fri, 05 Sep 2025 23:27:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112632.1460863; Fri, 05 Sep 2025 23:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uufq1-00029Z-Jb; Fri, 05 Sep 2025 23:27:25 +0000
Received: by outflank-mailman (input) for mailman id 1112632;
 Fri, 05 Sep 2025 23:27:23 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufpz-0001hz-GU
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:23 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufpy-008AAw-2t;
 Fri, 05 Sep 2025 23:27:23 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufpy-0005D2-2q;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=euQ/8vNf5GpufgF2TZgbk8vUuC32iTlLIUaYRtS1M14=; b=boyOdTz8V0yH9S5Ab4iNInZzSA
	CvM6uB7BqGhXl6uRwbofX+8i5Abqh/O+kx3PDbg5zVMPYdI/w7SXC1OXkHUnN+h49RX9LlFtdLwzJ
	6VCPJ5lmiF+XDvV7gOEc8zqLSEkQl5KLVeW9A8u/sR0Rq6wiPulswMuVKG/p3eikRi2A=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 04/15] emul/ns16x50: implement DLL/DLM registers
Date: Fri,  5 Sep 2025 16:27:03 -0700
Message-ID: <20250905232715.440758-5-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add DLL/DLM registers emulation.

DLL/DLM registers report hardcoded 115200 baud rate to the guest OS.

Add stub for ns16x50_dlab_get() helper.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- dropped ns16x50_dlab_get() hunk (moved to emulator stub)
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-5-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 0462a961e785..7f479a5be4a2 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -97,8 +97,13 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 static int ns16x50_io_write8(
     struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
 {
+    uint8_t *regs = vdev->regs;
+    uint8_t val = *data;
     int rc = 0;
 
+    if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
+        regs[NS16X50_REGS_NUM + reg] = val;
+
     return rc;
 }
 
@@ -109,8 +114,16 @@ static int ns16x50_io_write8(
 static int ns16x50_io_write16(
     struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
 {
+    uint16_t val = *data;
     int rc = -EINVAL;
 
+    if ( ns16x50_dlab_get(vdev) && reg == UART_DLL )
+    {
+        vdev->regs[NS16X50_REGS_NUM + UART_DLL] = val & 0xff;
+        vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (val >> 8) & 0xff;
+        rc = 0;
+    }
+
     return rc;
 }
 
@@ -146,9 +159,13 @@ static int ns16x50_io_write(
 static int ns16x50_io_read8(
     struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
 {
+    uint8_t *regs = vdev->regs;
     uint8_t val = 0xff;
     int rc = 0;
 
+    if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
+        val = regs[NS16X50_REGS_NUM + reg];
+
     *data = val;
 
     return rc;
@@ -163,6 +180,13 @@ static int ns16x50_io_read16(
     uint16_t val = 0xffff;
     int rc = -EINVAL;
 
+    if ( ns16x50_dlab_get(vdev) && reg == UART_DLL )
+    {
+        val = vdev->regs[NS16X50_REGS_NUM + UART_DLM] << 8 |
+              vdev->regs[NS16X50_REGS_NUM + UART_DLL];
+        rc = 0;
+    }
+
     *data = val;
 
     return rc;
@@ -280,12 +304,17 @@ out:
 
 static int ns16x50_init(void *arg)
 {
+    const uint16_t divisor = (UART_CLOCK_HZ / 115200) >> 4;
     struct vuart_ns16x50 *vdev = arg;
     const struct vuart_info *info = vdev->info;
     struct domain *d = vdev->owner;
 
     ASSERT(vdev);
 
+    /* NB: report 115200 baud rate. */
+    vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
+    vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
+
     register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
 
     return 0;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112633.1460873 (Exim 4.92)
	(envelope-from )
	id 1uufq3-0002P9-0T; Fri, 05 Sep 2025 23:27:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112633.1460873; Fri, 05 Sep 2025 23: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 1uufq2-0002OF-Ss; Fri, 05 Sep 2025 23:27:26 +0000
Received: by outflank-mailman (input) for mailman id 1112633;
 Fri, 05 Sep 2025 23:27:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq0-00020R-Ld
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufpz-008AB8-3C;
 Fri, 05 Sep 2025 23:27:24 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufpz-0005D6-39;
 Fri, 05 Sep 2025 23: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=UmQzHfQSoeUK3EyjGre7Frz+a/7pj0V41RdQZawNalI=; b=R2Ldlmao5TsX5jjH26E1hrRT+N
	fMqbNTrmUfZ9T+vahssMVk1I9wk0stagNbzZ6DCviCCfeZb4u0t6FBRdOt+tKqkYsqbbru/Llh7DP
	Fythg9UWdSIP0tz8R34kAsVn6P5yLMoP8nXHDHYMcs+NeC3A5HE/lCra8LrjRjR6T8EA=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 05/15] emul/ns16x50: implement SCR register
Date: Fri,  5 Sep 2025 16:27:04 -0700
Message-ID: <20250905232715.440758-6-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add SCR register emulation to the I/O port handler.
Firmware (e.g. OVMF) may use SCR during the guest OS boot.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- moved earlier in the series to simplify I/O handler population in
  the follow on patches
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-11-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 7f479a5be4a2..51ec85e57627 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -103,6 +103,20 @@ static int ns16x50_io_write8(
 
     if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
         regs[NS16X50_REGS_NUM + reg] = val;
+    else
+    {
+        switch ( reg )
+        {
+        /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
+        case UART_SCR:
+            regs[UART_SCR] = val;
+            break;
+
+        default:
+            rc = -EINVAL;
+            break;
+        }
+    }
 
     return rc;
 }
@@ -165,6 +179,19 @@ static int ns16x50_io_read8(
 
     if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
         val = regs[NS16X50_REGS_NUM + reg];
+    else
+    {
+        switch ( reg )
+        {
+        case UART_SCR:
+            val = regs[UART_SCR];
+            break;
+
+        default:
+            rc = -EINVAL;
+            break;
+        }
+    }
 
     *data = val;
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112634.1460878 (Exim 4.92)
	(envelope-from )
	id 1uufq3-0002Se-CD; Fri, 05 Sep 2025 23:27:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112634.1460878; Fri, 05 Sep 2025 23: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 1uufq3-0002SL-6k; Fri, 05 Sep 2025 23:27:27 +0000
Received: by outflank-mailman (input) for mailman id 1112634;
 Fri, 05 Sep 2025 23:27:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq1-00029m-Ky
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq1-008ABJ-0F;
 Fri, 05 Sep 2025 23:27:25 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq1-0005DA-0C;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=fu1wH8axdO9Xp+ceQdcC/+izkB5lgAddWuqh9BIqll0=; b=bwea3ctxQQOh7UunFyJLzy2ygL
	NZ3ytO+Gm1Ebm3oJW6QtcrdBqROvEq07jdQEg2/CKDbHwe0jxBFWr83CKzOYRO7rg3f9dpuf0Uq5T
	6kn+al4qtzr/n7uypoKvae66fcAPaNgl8AJ0ARqhzz7yXna0R5Qk0t4m1JdGAM1dHFRA=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 06/15] emul/ns16x50: implement IER/IIR registers
Date: Fri,  5 Sep 2025 16:27:05 -0700
Message-ID: <20250905232715.440758-7-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add interrupt enable register emulation (IER) and interrupt identity reason
(IIR) register emulation to the I/O port handler.

Also add routines for asserting/deasserting the virtual ns16x50 interrupt
line as a dependent on IIR code.

Poke ns16x50_irq_check() on every I/O register access because the emulator
does not have clock emulation anyway (e.g. for baud rate emulation).

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- stubbed out ns16x50_iir_check_xxx()
- dropped UART_IIR_THR handling (moved to THR register patch)
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-6-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 135 ++++++++++++++++++++++++++++++++
 1 file changed, 135 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 51ec85e57627..a7429c84c36e 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -91,6 +91,121 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
     return 0;
 }
 
+static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+/*
+ * Get the interrupt identity reason.
+ *
+ * IIR is re-calculated once called, because ns16x50 always reports high
+ * priority events first.
+ * regs[NS16X50_REGS_NUM + UART_IIR] is used to store THR reason only.
+ */
+static uint8_t ns16x50_iir_get(const struct vuart_ns16x50 *vdev)
+{
+    /*
+     * Interrupt identity reasons by priority.
+     * NB: high priority are at lower indexes below.
+     */
+    static const struct {
+        bool (*check)(const struct vuart_ns16x50 *vdev);
+        uint8_t ier;
+        uint8_t iir;
+    } iir_by_prio[] = {
+        [0] = { ns16x50_iir_check_lsi, UART_IER_ELSI,   UART_IIR_LSI },
+        [1] = { ns16x50_iir_check_rda, UART_IER_ERDAI,  UART_IIR_RDA },
+        [2] = { ns16x50_iir_check_thr, UART_IER_ETHREI, UART_IIR_THR },
+        [3] = { ns16x50_iir_check_msi, UART_IER_EMSI,   UART_IIR_MSI },
+    };
+    const uint8_t *regs = vdev->regs;
+    uint8_t iir = 0;
+    unsigned int i;
+
+    /*
+     * NB: every interaction w/ ns16x50 registers (except DLAB=1) goes
+     * through that call.
+     */
+    ASSERT(spin_is_locked(&vdev->lock));
+
+    for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ )
+    {
+        if ( (regs[UART_IER] & iir_by_prio[i].ier) &&
+             iir_by_prio[i].check(vdev) )
+            break;
+
+    }
+    if ( i == ARRAY_SIZE(iir_by_prio) )
+        iir |= UART_IIR_NOINT;
+    else
+        iir |= iir_by_prio[i].iir;
+
+    if ( regs[UART_FCR] & UART_FCR_ENABLE )
+        iir |= UART_IIR_FE;
+
+    return iir;
+}
+
+static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
+{
+    struct domain *d = vdev->owner;
+    const struct vuart_info *info = vdev->info;
+    int vector;
+
+    if ( has_vpic(d) )
+        vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
+    else
+        ASSERT_UNREACHABLE();
+
+    ns16x50_debug(vdev, "IRQ#%d vector %d assert\n", info->irq, vector);
+}
+
+static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
+{
+    struct domain *d = vdev->owner;
+    const struct vuart_info *info = vdev->info;
+
+    if ( has_vpic(d) )
+        hvm_isa_irq_deassert(d, info->irq);
+    else
+        ASSERT_UNREACHABLE();
+
+    ns16x50_debug(vdev, "IRQ#%d deassert\n", info->irq);
+}
+
+/*
+ * Assert/deassert virtual ns16x50 interrupt line.
+ */
+static void ns16x50_irq_check(const struct vuart_ns16x50 *vdev)
+{
+    uint8_t iir = ns16x50_iir_get(vdev);
+    const struct vuart_info *info = vdev->info;
+
+    if ( iir & UART_IIR_NOINT )
+        ns16x50_irq_deassert(vdev);
+    else
+        ns16x50_irq_assert(vdev);
+
+    ns16x50_debug(vdev, "IRQ#%d IIR 0x%02x %s\n", info->irq, iir,
+                  (iir & UART_IIR_NOINT) ? "deassert" : "assert");
+}
+
 /*
  * Emulate 8-bit write access to ns16x50 register.
  */
@@ -107,6 +222,10 @@ static int ns16x50_io_write8(
     {
         switch ( reg )
         {
+        case UART_IER:
+            regs[UART_IER] = val & UART_IER_MASK;
+            break;
+
         /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
         case UART_SCR:
             regs[UART_SCR] = val;
@@ -116,6 +235,8 @@ static int ns16x50_io_write8(
             rc = -EINVAL;
             break;
         }
+
+        ns16x50_irq_check(vdev);
     }
 
     return rc;
@@ -183,6 +304,14 @@ static int ns16x50_io_read8(
     {
         switch ( reg )
         {
+        case UART_IER:
+            val = regs[UART_IER];
+            break;
+
+        case UART_IIR: /* RO */
+            val = ns16x50_iir_get(vdev);
+            break;
+
         case UART_SCR:
             val = regs[UART_SCR];
             break;
@@ -191,6 +320,8 @@ static int ns16x50_io_read8(
             rc = -EINVAL;
             break;
         }
+
+        ns16x50_irq_check(vdev);
     }
 
     *data = val;
@@ -344,6 +475,10 @@ static int ns16x50_init(void *arg)
 
     register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
 
+    spin_lock(&vdev->lock);
+    ns16x50_irq_check(vdev);
+    spin_unlock(&vdev->lock);
+
     return 0;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112635.1460882 (Exim 4.92)
	(envelope-from )
	id 1uufq3-0002YK-NY; Fri, 05 Sep 2025 23:27:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112635.1460882; Fri, 05 Sep 2025 23: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 1uufq3-0002Vy-F0; Fri, 05 Sep 2025 23:27:27 +0000
Received: by outflank-mailman (input) for mailman id 1112635;
 Fri, 05 Sep 2025 23:27:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq2-0002Mw-Ml
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq2-008ABU-0T;
 Fri, 05 Sep 2025 23:27:26 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq2-0005DE-0R;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=hb3mt55KoPzpt9PYPd0ysWNPG2aT/CyfcVL0JIYVlkQ=; b=egcgATVzCVnVonFV7aSCnoEZUZ
	J1PTMh1fvax3B/REWv1D9Sl1wfCOW+oWa/WPlNCbORewzcS3nyiVhjLaR3OPH2cJoT1jhHFPIOE7m
	FFaI/DQuSOBCIk2kuwPOPYEvSkWXDBQe62ZzFHCcoVfymL3+vHqax06eNixTALW3GcFk=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 07/15] emul/ns16x50: implement LCR/LSR registers
Date: Fri,  5 Sep 2025 16:27:06 -0700
Message-ID: <20250905232715.440758-8-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add LCR/LSR registers implementation to the I/O port handler.

Add implementation of ns16x50_dlab_get() and ns16x50_iir_check_lsi().

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- Moved earlier in the series so follow on patches (THR/RBR) could make use of
  LSR bits more naturally
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-9-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index a7429c84c36e..9d1fe0284362 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -88,12 +88,12 @@ struct vuart_ns16x50 {
 
 static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 {
-    return 0;
+    return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
 }
 
 static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return vdev->regs[UART_LSR] & UART_LSR_MASK;
 }
 
 static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
@@ -226,11 +226,16 @@ static int ns16x50_io_write8(
             regs[UART_IER] = val & UART_IER_MASK;
             break;
 
+        case UART_LCR:
+            regs[UART_LCR] = val;
+            break;
+
         /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
         case UART_SCR:
             regs[UART_SCR] = val;
             break;
 
+        case UART_LSR: /* RO */
         default:
             rc = -EINVAL;
             break;
@@ -312,6 +317,15 @@ static int ns16x50_io_read8(
             val = ns16x50_iir_get(vdev);
             break;
 
+        case UART_LCR:
+            val = regs[UART_LCR];
+            break;
+
+        case UART_LSR:
+            val = regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
+            regs[UART_LSR] = val & ~UART_LSR_MASK;
+            break;
+
         case UART_SCR:
             val = regs[UART_SCR];
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112636.1460900 (Exim 4.92)
	(envelope-from )
	id 1uufq5-00031B-Ar; Fri, 05 Sep 2025 23:27:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112636.1460900; Fri, 05 Sep 2025 23: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 1uufq4-00030M-V4; Fri, 05 Sep 2025 23:27:28 +0000
Received: by outflank-mailman (input) for mailman id 1112636;
 Fri, 05 Sep 2025 23:27:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq3-0002ZE-Lu
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq3-008ABf-0o;
 Fri, 05 Sep 2025 23:27:27 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq3-0005DI-0m;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=lacCZFGmXlDfnSAS6hfC6DHktgzcKHiHe+PObjndGXg=; b=G1pmnoo+ZEN+TcIqdFDsQKGgdJ
	/FWLeg0iGHix2iDuRi7baQP0ogmDPvUJRw4ImgEaZvvRGI0SXTSDeyylCrx4RcKqZzkKcxLudUQz4
	x/4SLMrstkpsstf3VrTMp0lYGWCz8De8XFbMJgRCS1YCGifOYrBxBuFiwwkPXQOOIc2A=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 08/15] emul/ns16x50: implement MCR/MSR registers
Date: Fri,  5 Sep 2025 16:27:07 -0700
Message-ID: <20250905232715.440758-9-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add MCR/MSR registers emulation to the I/O port handler.

Add implementation of ns16x50_iir_check_msi().

Signed-off-by: Denis Mukhin 
---
Changes in v5:
- Moved earlier in the series
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-10-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 62 ++++++++++++++++++++++++++++++++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 9d1fe0284362..a8ec9f6c3a04 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -108,7 +108,7 @@ static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
 
 static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
 }
 
 /*
@@ -230,12 +230,63 @@ static int ns16x50_io_write8(
             regs[UART_LCR] = val;
             break;
 
+        case UART_MCR: {
+            uint8_t msr_curr, msr_next, msr_delta;
+
+            msr_curr = regs[UART_MSR];
+            msr_next = 0;
+            msr_delta = 0;
+
+            if ( val & UART_MCR_RESERVED0 )
+                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x\n",
+                             UART_MCR_RESERVED0);
+
+            if ( val & UART_MCR_TCRTLR )
+                ns16x50_warn(vdev, "MCR: not supported: %x\n",
+                             UART_MCR_TCRTLR);
+
+            if ( val & UART_MCR_RESERVED1 )
+                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x\n",
+                             UART_MCR_RESERVED1);
+
+            /* Set modem status */
+            if ( val & UART_MCR_LOOP )
+            {
+                if ( val & UART_MCR_DTR )
+                    msr_next |= UART_MSR_DSR;
+                if ( val & UART_MCR_RTS )
+                    msr_next |= UART_MSR_CTS;
+                if ( val & UART_MCR_OUT1 )
+                    msr_next |= UART_MSR_RI;
+                if ( val & UART_MCR_OUT2 )
+                    msr_next |= UART_MSR_DCD;
+            }
+            else
+                msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
+
+            /* Calculate changes in modem status */
+            if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
+                msr_delta |= UART_MSR_DCTS;
+            if ( (msr_curr & UART_MSR_DSR) ^ (msr_next & UART_MSR_DSR) )
+                msr_delta |= UART_MSR_DDSR;
+            if ( (msr_curr & UART_MSR_RI)  & (msr_next & UART_MSR_RI) )
+                msr_delta |= UART_MSR_TERI;
+            if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
+                msr_delta |= UART_MSR_DDCD;
+
+            regs[UART_MCR] = val & UART_MCR_MASK;
+            regs[UART_MSR] = msr_next | msr_delta;
+
+            break;
+        }
+
         /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
         case UART_SCR:
             regs[UART_SCR] = val;
             break;
 
         case UART_LSR: /* RO */
+        case UART_MSR: /* RO */
         default:
             rc = -EINVAL;
             break;
@@ -321,11 +372,20 @@ static int ns16x50_io_read8(
             val = regs[UART_LCR];
             break;
 
+        case UART_MCR:
+            val = regs[UART_MCR];
+            break;
+
         case UART_LSR:
             val = regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
             regs[UART_LSR] = val & ~UART_LSR_MASK;
             break;
 
+        case UART_MSR:
+            val = regs[UART_MSR];
+            regs[UART_MSR] &= ~UART_MSR_CHANGE;
+            break;
+
         case UART_SCR:
             val = regs[UART_SCR];
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112637.1460910 (Exim 4.92)
	(envelope-from )
	id 1uufq6-0003P9-IY; Fri, 05 Sep 2025 23:27:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112637.1460910; Fri, 05 Sep 2025 23:27: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 1uufq6-0003OG-Ca; Fri, 05 Sep 2025 23:27:30 +0000
Received: by outflank-mailman (input) for mailman id 1112637;
 Fri, 05 Sep 2025 23:27:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq4-0002x4-PL
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq4-008ABr-15;
 Fri, 05 Sep 2025 23:27:28 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq4-0005DM-12;
 Fri, 05 Sep 2025 23:27:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=WS5zJJrZC73EleKCg8ae2WORbb1w+LMvbUphJXaEKpA=; b=jNWrRxuNVdg6IdrqX02mQgeaLh
	9i2kbBLF2tQf/yS4UWx8xi4u02rnPFtwimxiMqeclPlnu7RhMTz1P7svgzN58dM/MuOZe4+MPdzs2
	w5s83fTbNIwgKaYh5yBve9JnS2qw8d7UBL7De14jV80wtdZATPqkWS2gzjKv6GAnaGqA=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 09/15] emul/ns16x50: implement RBR register
Date: Fri,  5 Sep 2025 16:27:08 -0700
Message-ID: <20250905232715.440758-10-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add RBR register emulation to the I/O port handlder.

Add RX FIFO management code since RBR depends on RX FIFO.

RX FIFO is not emulated as per UART specs for simplicity (not need to emulate
baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
NS16750 (64 bytes).

RX FIFO is emulated by means of using xencons_interface which conveniently
provides primitives for buffer management and later can be used for
inter-domain communication similarly to vpl011.

Add UART_LSR_DR handling since it depends on RBR register access.

Finally, implement put_rx() vUART hook for placing a character into the
emulated RX FIFO from console driver. That implements physical console
forwarding to the guest OS over emulated NS16550.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- new patch
- Link to v5 (both THR/RBR): https://lore.kernel.org/xen-devel/20250828235409.2835815-7-dmukhin@ford.com/
- Link to v5 (rx_put): https://lore.kernel.org/xen-devel/20250828235409.2835815-12-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 121 +++++++++++++++++++++++++++++++-
 1 file changed, 119 insertions(+), 2 deletions(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index a8ec9f6c3a04..cac5128f0573 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -86,6 +86,68 @@ struct vuart_ns16x50 {
     struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
 };
 
+static bool ns16x50_fifo_rx_empty(const struct vuart_ns16x50 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->in_prod == cons->in_cons;
+}
+
+static bool ns16x50_fifo_rx_full(const struct vuart_ns16x50 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->in_prod - cons->in_cons == ARRAY_SIZE(cons->in);
+}
+
+static void ns16x50_fifo_rx_reset(struct vuart_ns16x50 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    cons->in_cons = cons->in_prod;
+}
+
+/*
+ * Transfer character from RX FIFO and return the RX FIFO status after the
+ * transfer.
+ */
+static int ns16x50_fifo_rx_getchar(struct vuart_ns16x50 *vdev, uint8_t *ptr)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    if ( ns16x50_fifo_rx_empty(vdev) )
+        return -ENODATA;
+
+    *ptr = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
+    cons->in_cons++;
+
+    return ns16x50_fifo_rx_empty(vdev) ? -ENODATA : 0;
+}
+
+static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
+{
+    struct xencons_interface *cons = &vdev->cons;
+    int rc;
+
+    /*
+     * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents
+     * of the THR.
+     */
+    if ( ns16x50_fifo_rx_full(vdev) )
+    {
+        ns16x50_debug(vdev, "RX FIFO full; resetting\n");
+        ns16x50_fifo_rx_reset(vdev);
+        rc = -ENOSPC;
+    }
+    else
+        rc = 0;
+
+    cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c;
+    cons->in_prod++;
+
+    return rc;
+}
+
 static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 {
     return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
@@ -98,7 +160,7 @@ static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
 
 static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return !ns16x50_fifo_rx_empty(vdev);
 }
 
 static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
@@ -360,6 +422,17 @@ static int ns16x50_io_read8(
     {
         switch ( reg )
         {
+        case UART_RBR:
+            /* NB: do not forget to clear overrun condition */
+            regs[UART_LSR] &= ~UART_LSR_OE;
+
+            if ( ns16x50_fifo_rx_getchar(vdev, &val) )
+                regs[UART_LSR] &= ~UART_LSR_DR;
+            else
+                regs[UART_LSR] |= UART_LSR_DR;
+
+            break;
+
         case UART_IER:
             val = regs[UART_IER];
             break;
@@ -610,13 +683,57 @@ static void cf_check ns16x50_free(void *arg)
     xvfree(arg);
 }
 
+static int cf_check ns16x50_put_rx(void *arg, char ch)
+{
+    struct vuart_ns16x50 *vdev = arg;
+    uint8_t *regs;
+    uint8_t dlab;
+    int rc = -EBUSY;
+
+    spin_lock(&vdev->lock);
+
+    dlab = ns16x50_dlab_get(vdev);
+    regs = vdev->regs;
+
+    if ( dlab )
+        ns16x50_debug(vdev, "THR/RBR access disabled: DLAB=1\n");
+    else if ( regs[UART_MCR] & UART_MCR_LOOP )
+        ns16x50_debug(vdev, "THR/RBR access disabled: loopback mode\n");
+    else
+    {
+        const struct domain *d = vdev->owner;
+
+        /*
+         * Echo the user input on Xen console iff Xen console input is owned
+         * by ns16x50 domain.
+         * NB: use 'console_timestamps=none' to disable Xen timestamps.
+         */
+        if ( is_console_printable(ch) )
+            guest_printk(d, "%c", ch);
+
+        if ( ns16x50_fifo_rx_putchar(vdev, ch) )
+            regs[UART_LSR] |= UART_LSR_OE;
+
+        regs[UART_LSR] |= UART_LSR_DR;
+
+        /* TODO: check FCR when to fire an interrupt */
+        ns16x50_irq_check(vdev);
+
+        rc = 0;
+    }
+
+    spin_unlock(&vdev->lock);
+
+    return rc;
+}
+
 #define ns16x50_emulator                \
 {                                       \
     .compatible = "ns16550",            \
     .alloc      = ns16x50_alloc,        \
     .free       = ns16x50_free,         \
     .dump_state = NULL,                 \
-    .put_rx     = NULL,                 \
+    .put_rx     = ns16x50_put_rx,       \
 }
 
 VUART_REGISTER(ns16x50, ns16x50_emulator);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112638.1460919 (Exim 4.92)
	(envelope-from )
	id 1uufq7-0003V3-Eh; Fri, 05 Sep 2025 23:27:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112638.1460919; Fri, 05 Sep 2025 23:27: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 1uufq6-0003TV-Sy; Fri, 05 Sep 2025 23:27:30 +0000
Received: by outflank-mailman (input) for mailman id 1112638;
 Fri, 05 Sep 2025 23:27:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq5-0003Gd-RP
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:29 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq5-008AC6-1Z;
 Fri, 05 Sep 2025 23:27:29 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq5-0005DQ-1V;
 Fri, 05 Sep 2025 23:27:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=H6Jsk6o0mPE6CkIqUYbOmKkRmoSPy4kytmL3+MJblb8=; b=hAKeWQc5fQbyKAWWfsxPT2V4il
	qo1Sw8jQGZOdOCoJAhbjlfTv2UVT4ZFG0zBVcVMWnml8M8C+/cO2nJzedz/iGBXKZctnTORvtZXII
	xr/LHyQCvERV0DRxNpfSl9NxEf3gZFm6CWow4pFQBOTb4Dq2nsrhO94bUsN4oPTcVCRM=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 10/15] emul/ns16x50: implement THR register
Date: Fri,  5 Sep 2025 16:27:09 -0700
Message-ID: <20250905232715.440758-11-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add THR register emulation to the I/O port handlder.

Add TX FIFO management code since THR depends on TX FIFO.

TX FIFOs is not emulated as per UART specs for simplicity (not need to emulate
baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
NS16750 (64 bytes).

TX FIFOs is emulated by using xencons_interface which conveniently provides
primitives for buffer management and later can be used for inter-domain
communication similarly to vpl011.

Add UART_IIR_THR interrupt reason handling since it depends on THR register
access.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- new patch
- Link to v5 (both THR/RBR): https://lore.kernel.org/xen-devel/20250828235409.2835815-7-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 103 +++++++++++++++++++++++++++++++-
 1 file changed, 102 insertions(+), 1 deletion(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index cac5128f0573..987d4c06e23b 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -148,6 +148,66 @@ static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
     return rc;
 }
 
+static bool ns16x50_fifo_tx_full(const struct vuart_ns16x50 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->out_prod - cons->out_cons == ARRAY_SIZE(cons->out);
+}
+
+static void ns16x50_fifo_tx_reset(struct vuart_ns16x50 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    cons->out_cons = cons->out_prod;
+}
+
+/*
+ * Flush cached output to Xen console.
+ */
+static void ns16x50_fifo_tx_flush(struct vuart_ns16x50 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+    struct domain *d = vdev->owner;
+    XENCONS_RING_IDX i, n, len = cons->out_prod - cons->out_cons;
+
+    ASSERT(len <= ARRAY_SIZE(cons->out));
+    if ( !len )
+        return;
+
+    i = MASK_XENCONS_IDX(cons->out_cons, cons->out);
+    n = min_t(XENCONS_RING_IDX, len, ARRAY_SIZE(cons->out) - i);
+    if ( n )
+        guest_printk(d, guest_prefix "%.*s", n, &cons->out[i]);
+
+    i = 0;
+    n = len - n;
+    if ( n )
+        guest_printk(d, guest_prefix "%.*s", n, &cons->out[i]);
+
+    cons->out_cons += len;
+}
+
+/*
+ * Accumulate guest OS output before sending to Xen console.
+ */
+static void ns16x50_fifo_tx_putchar(struct vuart_ns16x50 *vdev, char ch)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    if ( !is_console_printable(ch) )
+        return;
+
+    if ( !ns16x50_fifo_tx_full(vdev) )
+    {
+        cons->out[MASK_XENCONS_IDX(cons->out_prod, cons->out)] = ch;
+        cons->out_prod++;
+    }
+
+    if ( ch == '\n' || ch == '\0' || ns16x50_fifo_tx_full(vdev) )
+        ns16x50_fifo_tx_flush(vdev);
+}
+
 static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 {
     return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
@@ -165,7 +225,7 @@ static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
 
 static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return vdev->regs[NS16X50_REGS_NUM + UART_IIR] & UART_IIR_THR;
 }
 
 static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
@@ -284,7 +344,31 @@ static int ns16x50_io_write8(
     {
         switch ( reg )
         {
+        case UART_THR:
+            if ( regs[UART_MCR] & UART_MCR_LOOP )
+            {
+                if ( ns16x50_fifo_rx_putchar(vdev, val) )
+                    regs[UART_LSR] |= UART_LSR_OE;
+
+                regs[UART_LSR] |= UART_LSR_DR;
+            }
+            else
+            {
+                ns16x50_fifo_tx_putchar(vdev, val);
+                regs[NS16X50_REGS_NUM + UART_IIR] |= UART_IIR_THR;
+            }
+
+            break;
+
         case UART_IER:
+            /*
+             * NB: Make sure THR interrupt is re-triggered once guest OS
+             * re-enables ETHREI in IER since all THR writes are immediate,
+             * there's no baud rate emulation.
+             */
+            if ( val & regs[UART_IER] & UART_IER_ETHREI )
+                regs[NS16X50_REGS_NUM + UART_IIR] |= UART_IIR_THR;
+
             regs[UART_IER] = val & UART_IER_MASK;
             break;
 
@@ -439,6 +523,16 @@ static int ns16x50_io_read8(
 
         case UART_IIR: /* RO */
             val = ns16x50_iir_get(vdev);
+
+            /*
+             * Since there's no baud rate emulation, transmits are immediate
+             * to the guest. Clear IIR scratch location to make sure there
+             * will be interrupt generated once guest re-enabled ETHREI in
+             * IER.
+             */
+            if ( val & UART_IIR_THR )
+                regs[NS16X50_REGS_NUM + UART_IIR] &= ~UART_IIR_THR;
+
             break;
 
         case UART_LCR:
@@ -620,6 +714,9 @@ static int ns16x50_init(void *arg)
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
 
+    /* Report UART is ready to transmit. */
+    vdev->regs[NS16X50_REGS_NUM + UART_IIR] = UART_IIR_THR;
+
     register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
 
     spin_lock(&vdev->lock);
@@ -634,6 +731,10 @@ static void cf_check ns16x50_deinit(void *arg)
     struct vuart_ns16x50 *vdev = arg;
 
     ASSERT(vdev);
+
+    spin_lock(&vdev->lock);
+    ns16x50_fifo_tx_flush(vdev);
+    spin_unlock(&vdev->lock);
 }
 
 static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112641.1460926 (Exim 4.92)
	(envelope-from )
	id 1uufq8-0003th-S1; Fri, 05 Sep 2025 23:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112641.1460926; Fri, 05 Sep 2025 23: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 1uufq8-0003rI-MI; Fri, 05 Sep 2025 23:27:32 +0000
Received: by outflank-mailman (input) for mailman id 1112641;
 Fri, 05 Sep 2025 23:27:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq7-0003Va-3X
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq6-008ACK-1u;
 Fri, 05 Sep 2025 23:27:30 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq6-0005DU-1r;
 Fri, 05 Sep 2025 23:27:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=wv/+ypHhGLMV6T5qoOflVazYUaQF2ZGJkFc9G2aHE+8=; b=IBQMlSmOQUHnzX6idaVqBKZYxe
	vZZNoMMLUOSwVsBnngL4NfcWCTtHchJWcT2QaVJ+zkj0My5S2qV1GXu3BN1xobXT7dEqIeV6hH8+1
	ZjsSzq1iZ/yUHCT5DSIt6G59tg70P3d4gF2pHZyJI5FF5fniix8kURhlOS+nnKTCGysU=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 11/15] emul/ns16x50: implement FCR register (write-only)
Date: Fri,  5 Sep 2025 16:27:10 -0700
Message-ID: <20250905232715.440758-12-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add emulation logic for FCR register.

Note, that does not hook FIFO interrupt moderation to the FIFO management
code for simplicity.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- fixed UART_FCR_CLRX and UART_FCR_CLTX handling
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-8-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 987d4c06e23b..3fc1112709df 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -372,6 +372,36 @@ static int ns16x50_io_write8(
             regs[UART_IER] = val & UART_IER_MASK;
             break;
 
+        case UART_FCR: /* WO */
+            if ( val & UART_FCR_RESERVED0 )
+                ns16x50_warn(vdev, "FCR: attempt to set reserved bit: %x\n",
+                             UART_FCR_RESERVED0);
+
+            if ( val & UART_FCR_RESERVED1 )
+                ns16x50_warn(vdev, "FCR: attempt to set reserved bit: %x\n",
+                             UART_FCR_RESERVED1);
+
+            if ( val & UART_FCR_CLRX )
+            {
+                ns16x50_fifo_rx_reset(vdev);
+                regs[UART_LSR] &= ~UART_LSR_DR;
+            }
+
+            if ( val & UART_FCR_CLTX )
+            {
+                ns16x50_fifo_tx_reset(vdev);
+                regs[NS16X50_REGS_NUM + UART_IIR] |= UART_IIR_THR;
+            }
+
+            if ( val & UART_FCR_ENABLE )
+                val &= UART_FCR_ENABLE | UART_FCR_DMA | UART_FCR_TRG_MASK;
+            else
+                val = 0;
+
+            regs[UART_FCR] = val;
+
+            break;
+
         case UART_LCR:
             regs[UART_LCR] = val;
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112643.1460938 (Exim 4.92)
	(envelope-from )
	id 1uufqA-0004Df-CT; Fri, 05 Sep 2025 23:27:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112643.1460938; Fri, 05 Sep 2025 23:27: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 1uufqA-0004C5-1A; Fri, 05 Sep 2025 23:27:34 +0000
Received: by outflank-mailman (input) for mailman id 1112643;
 Fri, 05 Sep 2025 23:27:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq8-0003lL-82
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq7-008ACU-2B;
 Fri, 05 Sep 2025 23:27:31 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq7-0005DY-2A;
 Fri, 05 Sep 2025 23: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=u2jdc7rLZ93+UT0tmBIy3UeulgEZY7zZ1DBAZKI8/+g=; b=us44G4mHhQkzqi+a5rTigbberW
	DnTiESUfEPrrt/+dqdcPnY+djyikMBzPjhNUgfvQefLwkIwxvgNpdQmHu2ijFn0KXgidlXHwroc7i
	Yu1ryjQ5U6MP2GTTDbd9gnou7KFoFOJxghmL3ozDz77Jtx/swpPAQ7kBW39sIordgTXo=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 12/15] emul/ns16550: implement dump_state() hook
Date: Fri,  5 Sep 2025 16:27:11 -0700
Message-ID: <20250905232715.440758-13-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Implement dump_state() vUART hook for debugging UART state machine over Xen
console. dump_state() prints state of all emulated registers (including
state-less IIR) and state of RX/TX FIFOs.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- Fixed printouts formatters
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-13-dmukhin@ford.com/
---
 xen/common/emul/vuart/ns16x50.c | 59 ++++++++++++++++++++++++++++++++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 3fc1112709df..a4fa3a9be713 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -648,6 +648,58 @@ static int ns16x50_io_read(
     return rc;
 }
 
+static void cf_check ns16x50_dump_state(void *arg)
+{
+#ifdef CONFIG_VUART_NS16X50_DEBUG
+    struct vuart_ns16x50 *vdev = arg;
+    const struct domain *d = vdev->owner;
+    const struct vuart_info *info = vdev->info;
+    const struct xencons_interface *cons;
+    const uint8_t *regs;
+
+    if ( !vdev )
+        return;
+
+    /* Allow printing state in case of a deadlock. */
+    if ( !spin_trylock(&vdev->lock) )
+        return;
+
+    cons = &vdev->cons;
+    regs = &vdev->regs[0];
+
+    printk("Virtual " pr_prefix " (%s) I/O port 0x%04x IRQ#%d owner %pd\n",
+            vdev->name, info->base_addr, info->irq, d);
+
+    printk("  RX FIFO size %ld in_prod %d in_cons %d used %d\n",
+            ARRAY_SIZE(cons->in), cons->in_prod, cons->in_cons,
+            cons->in_prod - cons->in_cons);
+
+    printk("  TX FIFO size %ld out_prod %d out_cons %d used %d\n",
+            ARRAY_SIZE(cons->out), cons->out_prod, cons->out_cons,
+            cons->out_prod - cons->out_cons);
+
+    printk("  %02"PRIx8" RBR %02"PRIx8" THR %02"PRIx8" DLL %02"PRIx8" DLM %02"PRIx8"\n",
+            UART_RBR,
+            cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)],
+            cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)],
+            regs[NS16X50_REGS_NUM + UART_DLL],
+            regs[NS16X50_REGS_NUM + UART_DLM]);
+
+    printk("  %02"PRIx8" IER %02"PRIx8"\n", UART_IER, regs[UART_IER]);
+
+    printk("  %02"PRIx8" FCR %02"PRIx8" IIR %02"PRIx8"\n",
+            UART_FCR, regs[UART_FCR], ns16x50_iir_get(vdev));
+
+    printk("  %02"PRIx8" LCR %02"PRIx8"\n", UART_LCR, regs[UART_LCR]);
+    printk("  %02"PRIx8" MCR %02"PRIx8"\n", UART_MCR, regs[UART_MCR]);
+    printk("  %02"PRIx8" LSR %02"PRIx8"\n", UART_LSR, regs[UART_LSR]);
+    printk("  %02"PRIx8" MSR %02"PRIx8"\n", UART_MSR, regs[UART_MSR]);
+    printk("  %02"PRIx8" SCR %02"PRIx8"\n", UART_SCR, regs[UART_SCR]);
+
+    spin_unlock(&vdev->lock);
+#endif /* CONFIG_VUART_NS16X50_DEBUG */
+}
+
 /*
  * Emulate I/O access to ns16x50 register.
  * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled.
@@ -724,6 +776,9 @@ static int cf_check ns16x50_io_handle(
 
     spin_unlock(&vdev->lock);
 
+    if ( ns16x50_log_level >= 3 )
+        ns16x50_dump_state(vdev);
+
 out:
     rcu_unlock_domain(d);
 
@@ -854,6 +909,8 @@ static int cf_check ns16x50_put_rx(void *arg, char ch)
     }
 
     spin_unlock(&vdev->lock);
+    if ( ns16x50_log_level >= 3 )
+        ns16x50_dump_state(vdev);
 
     return rc;
 }
@@ -863,7 +920,7 @@ static int cf_check ns16x50_put_rx(void *arg, char ch)
     .compatible = "ns16550",            \
     .alloc      = ns16x50_alloc,        \
     .free       = ns16x50_free,         \
-    .dump_state = NULL,                 \
+    .dump_state = ns16x50_dump_state,   \
     .put_rx     = ns16x50_put_rx,       \
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112645.1460947 (Exim 4.92)
	(envelope-from )
	id 1uufqC-0004do-PP; Fri, 05 Sep 2025 23:27:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112645.1460947; Fri, 05 Sep 2025 23: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 1uufqC-0004br-5t; Fri, 05 Sep 2025 23:27:36 +0000
Received: by outflank-mailman (input) for mailman id 1112645;
 Fri, 05 Sep 2025 23:27:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufq9-00046l-Ft
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:33 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufq8-008ACh-30;
 Fri, 05 Sep 2025 23:27:33 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufq8-0005Dc-2d;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=sRCoyJrQXJ7kAPK0GzF+5VS6TdNQm9twBbzHI7FmCnI=; b=GA9Mna5+ZgkBUKCB1+gPFUFdmH
	vynHYi5zImLsAS9xjU9hycKmGDBlMVWNxM6NiBmuxN+LxchDjk+Pz5YE+k79hDvIXezdLXPXg2mWI
	c23bf5LIgukj0oLTdoz8aqxlWgLkEPpKhqX7tp1ogcVD5E/jAmpfPfeqrKVtog9+RpMw=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 13/15] x86/domain: enable per-domain I/O port bitmaps
Date: Fri,  5 Sep 2025 16:27:12 -0700
Message-ID: <20250905232715.440758-14-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Current design enables all HVM domains share the same I/O port bitmap.

It is necessary for domains crafting its own I/O port address space depending
on the user configuration.

Ensure NS16550 emulator does not share I/O ports with the physical I/O ports,
which is essential for emulation in PVH hwdom case (dom0).

Not a functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- fixed printout formatters in ns16x50_init()
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-14-dmukhin@ford.com/
---
 xen/arch/x86/Makefile                    |   1 +
 xen/arch/x86/dom0_build.c                | 111 +--------------
 xen/arch/x86/hvm/hvm.c                   |  35 +----
 xen/arch/x86/hvm/nestedhvm.c             |   8 +-
 xen/arch/x86/hvm/quirks.c                |   3 -
 xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
 xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
 xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
 xen/arch/x86/include/asm/hvm/support.h   |   2 -
 xen/arch/x86/include/asm/iocap.h         |   2 +
 xen/arch/x86/ioport.c                    | 163 +++++++++++++++++++++++
 xen/arch/x86/pv/dom0_build.c             |   4 +
 xen/common/emul/vuart/ns16x50.c          |  11 ++
 13 files changed, 200 insertions(+), 149 deletions(-)
 create mode 100644 xen/arch/x86/ioport.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d7aed7d92c15..85a8475e126c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -44,6 +44,7 @@ obj-y += msi.o
 obj-y += msr.o
 obj-$(CONFIG_INDIRECT_THUNK) += indirect-thunk.o
 obj-$(CONFIG_RETURN_THUNK) += indirect-thunk.o
+obj-y += ioport.o
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4fc..26202b33345c 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -298,9 +298,6 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
     return 0;
 }
 
-static char __initdata opt_dom0_ioports_disable[200] = "";
-string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
-
 static bool __initdata ro_hpet = true;
 boolean_param("ro-hpet", ro_hpet);
 
@@ -433,122 +430,20 @@ unsigned long __init dom0_compute_nr_pages(
     return nr_pages;
 }
 
-static void __init process_dom0_ioports_disable(struct domain *dom0)
-{
-    unsigned long io_from, io_to;
-    char *t, *s = opt_dom0_ioports_disable;
-    const char *u;
-
-    if ( *s == '\0' )
-        return;
-
-    while ( (t = strsep(&s, ",")) != NULL )
-    {
-        io_from = simple_strtoul(t, &u, 16);
-        if ( u == t )
-        {
-        parse_error:
-            printk("Invalid ioport range <%s> "
-                   "in dom0_ioports_disable, skipping\n", t);
-            continue;
-        }
-
-        if ( *u == '\0' )
-            io_to = io_from;
-        else if ( *u == '-' )
-            io_to = simple_strtoul(u + 1, &u, 16);
-        else
-            goto parse_error;
-
-        if ( (*u != '\0') || (io_to < io_from) || (io_to >= 65536) )
-            goto parse_error;
-
-        printk("Disabling dom0 access to ioport range %04lx-%04lx\n",
-            io_from, io_to);
-
-        if ( ioports_deny_access(dom0, io_from, io_to) != 0 )
-            BUG();
-    }
-}
-
+/* Modify I/O memory access permissions. */
 int __init dom0_setup_permissions(struct domain *d)
 {
     unsigned long mfn;
-    unsigned int i, offs;
-    int rc;
+    unsigned int i;
+    int rc = 0;
 
     if ( pv_shim )
         return 0;
 
-    /* The hardware domain is initially permitted full I/O capabilities. */
-    rc = ioports_permit_access(d, 0, 0xFFFF);
     rc |= iomem_permit_access(d, 0UL,
                               PFN_DOWN(1UL << domain_max_paddr_bits(d)) - 1);
     rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
 
-    /* Modify I/O port access permissions. */
-
-    for ( offs = 0, i = ISOLATE_LSB(i8259A_alias_mask) ?: 2;
-          offs <= i8259A_alias_mask; offs += i )
-    {
-        if ( offs & ~i8259A_alias_mask )
-            continue;
-        /* Master Interrupt Controller (PIC). */
-        rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
-        /* Slave Interrupt Controller (PIC). */
-        rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
-    }
-
-    /* ELCR of both PICs. */
-    rc |= ioports_deny_access(d, 0x4D0, 0x4D1);
-
-    /* Interval Timer (PIT). */
-    for ( offs = 0, i = ISOLATE_LSB(pit_alias_mask) ?: 4;
-          offs <= pit_alias_mask; offs += i )
-        if ( !(offs & ~pit_alias_mask) )
-            rc |= ioports_deny_access(d, PIT_CH0 + offs, PIT_MODE + offs);
-
-    /* PIT Channel 2 / PC Speaker Control. */
-    rc |= ioports_deny_access(d, 0x61, 0x61);
-
-    /* INIT# and alternative A20M# control. */
-    rc |= ioports_deny_access(d, 0x92, 0x92);
-
-    /* IGNNE# control. */
-    rc |= ioports_deny_access(d, 0xF0, 0xF0);
-
-    /* ACPI PM Timer. */
-    if ( pmtmr_ioport )
-        rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
-
-    /* Reset control. */
-    rc |= ioports_deny_access(d, 0xCF9, 0xCF9);
-
-    /* PCI configuration space (NB. 0xCF8 has special treatment). */
-    rc |= ioports_deny_access(d, 0xCFC, 0xCFF);
-
-#ifdef CONFIG_HVM
-    if ( is_hvm_domain(d) )
-    {
-        /* ISA DMA controller, channels 0-3 (incl possible aliases). */
-        rc |= ioports_deny_access(d, 0x00, 0x1F);
-        /* ISA DMA controller, page registers (incl various reserved ones). */
-        rc |= ioports_deny_access(d, 0x80 + !!hvm_port80_allowed, 0x8F);
-        /* ISA DMA controller, channels 4-7 (incl usual aliases). */
-        rc |= ioports_deny_access(d, 0xC0, 0xDF);
-
-        /* HVM debug console IO port. */
-        rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
-                                  XEN_HVM_DEBUGCONS_IOPORT);
-        if ( amd_acpi_c1e_quirk )
-            rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
-    }
-#endif
-    /* Command-line I/O ranges. */
-    process_dom0_ioports_disable(d);
-
-    /* Modify I/O memory access permissions. */
-
     /* Local APIC. */
     if ( mp_lapic_addr != 0 )
     {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 91c971f11e14..93109db77283 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -81,14 +82,6 @@ integer_param("hvm_debug", opt_hvm_debug_level);
 
 struct hvm_function_table __ro_after_init hvm_funcs;
 
-/*
- * The I/O permission bitmap is globally shared by all HVM guests except
- * the hardware domain which needs a more permissive one.
- */
-#define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
-unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
-    hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
-
 /* Xen command-line option to enable HAP */
 static bool __initdata opt_hap_enabled = true;
 boolean_param("hap", opt_hap_enabled);
@@ -205,15 +198,6 @@ static int __init cf_check hvm_enable(void)
     if ( opt_hvm_fep )
         warning_add(warning_hvm_fep);
 
-    /*
-     * Allow direct access to the PC debug ports 0x80 and 0xed (they are
-     * often used for I/O delays, but the vmexits simply slow things down).
-     */
-    memset(hvm_io_bitmap, ~0, sizeof(hvm_io_bitmap));
-    if ( hvm_port80_allowed )
-        __clear_bit(0x80, hvm_io_bitmap);
-    __clear_bit(0xed, hvm_io_bitmap);
-
     register_cpu_notifier(&cpu_nfb);
 
     return 0;
@@ -645,19 +629,12 @@ int hvm_domain_initialise(struct domain *d,
 
     rwlock_init(&d->arch.hvm.pl_time->pt_migrate);
 
-    /* Set the default IO Bitmap. */
-    if ( is_hardware_domain(d) )
+    rc = ioports_setup_access(d);
+    if ( rc )
     {
-        d->arch.hvm.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
-        if ( d->arch.hvm.io_bitmap == NULL )
-        {
-            rc = -ENOMEM;
-            goto fail1;
-        }
-        memset(d->arch.hvm.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
+        printk("%pd failed to setup I/O bitmap: %d\n", d, rc);
+        goto fail1;
     }
-    else
-        d->arch.hvm.io_bitmap = hvm_io_bitmap;
 
     register_g2m_portio_handler(d);
     register_vpci_portio_handler(d);
@@ -684,6 +661,8 @@ int hvm_domain_initialise(struct domain *d,
         break;
     }
 
+    BUG_ON(!d->arch.ioport_caps);
+
     vpic_init(d);
 
     rc = vioapic_init(d);
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index bddd77d8109b..d4e03123d910 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -107,7 +107,7 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
  * The users of the bitmap patterns are in SVM/VMX specific code.
  *
  * bitmap        port 0x80  port 0xed
- * hvm_io_bitmap cleared    cleared
+ * hvm.io_bitmap cleared    cleared
  * iomap[0]      cleared    set
  * iomap[1]      set        cleared
  * iomap[2]      set        set
@@ -115,7 +115,7 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
 
 static int __init cf_check nestedhvm_setup(void)
 {
-    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
+    /* Same format and size as hvm.io_bitmap (Intel needs only 2 pages). */
     unsigned nr = cpu_has_vmx ? 2 : 3;
     unsigned int i, order = get_order_from_pages(nr);
 
@@ -165,7 +165,7 @@ static int __init cf_check nestedhvm_setup(void)
 __initcall(nestedhvm_setup);
 
 unsigned long *
-nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed)
+nestedhvm_vcpu_iomap_get(struct vcpu *v, bool ioport_80, bool ioport_ed)
 {
     int i;
 
@@ -174,7 +174,7 @@ nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed)
 
     if (ioport_80 == 0) {
         if (ioport_ed == 0)
-            return hvm_io_bitmap;
+            return v->domain->arch.hvm.io_bitmap;
         i = 0;
     } else {
         if (ioport_ed == 0)
diff --git a/xen/arch/x86/hvm/quirks.c b/xen/arch/x86/hvm/quirks.c
index 9202f5a47fe9..f4d95441fcff 100644
--- a/xen/arch/x86/hvm/quirks.c
+++ b/xen/arch/x86/hvm/quirks.c
@@ -73,9 +73,6 @@ static int __init cf_check check_port80(void)
 
     dmi_check_system(hvm_no_port80_dmi_table);
 
-    if ( !hvm_port80_allowed )
-        __set_bit(0x80, hvm_io_bitmap);
-
     return 0;
 }
 __initcall(check_port80);
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index dc2b6a42534a..cc8500b61665 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -381,7 +381,7 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
         hvm_unmap_guest_frame(ns_viomap, 0);
     }
 
-    svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
+    svm->ns_iomap = nestedhvm_vcpu_iomap_get(v, ioport_80, ioport_ed);
 
     nv->nv_ioport80 = ioport_80;
     nv->nv_ioportED = ioport_ed;
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index e4f3a5fe4c71..4da3e6e90e6c 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -554,7 +554,7 @@ unsigned long *_shadow_io_bitmap(struct vcpu *v)
     port80 = bitmap[0x80 >> 3] & (1 << (0x80 & 0x7)) ? 1 : 0;
     portED = bitmap[0xed >> 3] & (1 << (0xed & 0x7)) ? 1 : 0;
 
-    return nestedhvm_vcpu_iomap_get(port80, portED);
+    return nestedhvm_vcpu_iomap_get(v, port80, portED);
 }
 
 static void update_msrbitmap(struct vcpu *v, uint32_t shadow_ctrl)
@@ -622,7 +622,7 @@ void nvmx_update_exec_control(struct vcpu *v, u32 host_cntrl)
              * L1 VMM doesn't intercept IO instruction.
              * Use host configuration and reset IO_BITMAP
              */
-            bitmap = hvm_io_bitmap;
+            bitmap = v->domain->arch.hvm.io_bitmap;
         }
         else {
             /* use IO bitmap */
diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm.h b/xen/arch/x86/include/asm/hvm/nestedhvm.h
index ea2c1bc328c7..d691ccb07dd6 100644
--- a/xen/arch/x86/include/asm/hvm/nestedhvm.h
+++ b/xen/arch/x86/include/asm/hvm/nestedhvm.h
@@ -50,7 +50,8 @@ int nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa,
                                     struct npfec npfec);
 
 /* IO permission map */
-unsigned long *nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed);
+unsigned long *nestedhvm_vcpu_iomap_get(struct vcpu *v,
+                                        bool ioport_80, bool ioport_ed);
 
 /* Misc */
 #define nestedhvm_paging_mode_hap(v) (!!nhvm_vmcx_hap_enabled(v))
diff --git a/xen/arch/x86/include/asm/hvm/support.h b/xen/arch/x86/include/asm/hvm/support.h
index 2a7ba36af06f..7e36d00cc188 100644
--- a/xen/arch/x86/include/asm/hvm/support.h
+++ b/xen/arch/x86/include/asm/hvm/support.h
@@ -41,8 +41,6 @@ extern unsigned int opt_hvm_debug_level;
 #define HVM_DBG_LOG(level, _f, _a...) do {} while (0)
 #endif
 
-extern unsigned long hvm_io_bitmap[];
-
 enum hvm_translation_result {
     HVMTRANS_okay,
     HVMTRANS_bad_linear_to_gfn,
diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
index f948b7186e95..1083f6171cf7 100644
--- a/xen/arch/x86/include/asm/iocap.h
+++ b/xen/arch/x86/include/asm/iocap.h
@@ -22,6 +22,8 @@
 #define cache_flush_permitted(d) \
     (has_arch_io_resources(d) || has_arch_pdevs(d))
 
+int ioports_setup_access(struct domain *d);
+
 static inline int ioports_permit_access(struct domain *d, unsigned long s,
                                         unsigned long e)
 {
diff --git a/xen/arch/x86/ioport.c b/xen/arch/x86/ioport.c
new file mode 100644
index 000000000000..dbcd52d37a4f
--- /dev/null
+++ b/xen/arch/x86/ioport.c
@@ -0,0 +1,163 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Guest I/O port address space configuration.
+ *
+ * Copyright 2025 Ford Motor Company
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static char __initdata opt_dom0_ioports_disable[200] = "";
+string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
+
+/*
+ * The I/O permission bitmap size.
+ * See: comment in nestedhvm_setup()
+ */
+#define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
+
+/* Hide user-defined I/O ports from the guest OS. */
+static void process_dom0_ioports_disable(struct domain *dom0)
+{
+    unsigned long io_from, io_to;
+    char *t, *s = opt_dom0_ioports_disable;
+    const char *u;
+
+    if ( *s == '\0' )
+        return;
+
+    while ( (t = strsep(&s, ",")) != NULL )
+    {
+        io_from = simple_strtoul(t, &u, 16);
+        if ( u == t )
+        {
+        parse_error:
+            printk("Invalid ioport range <%s> "
+                   "in dom0_ioports_disable, skipping\n", t);
+            continue;
+        }
+
+        if ( *u == '\0' )
+            io_to = io_from;
+        else if ( *u == '-' )
+            io_to = simple_strtoul(u + 1, &u, 16);
+        else
+            goto parse_error;
+
+        if ( (*u != '\0') || (io_to < io_from) || (io_to >= 65536) )
+            goto parse_error;
+
+        printk("Disabling dom0 access to ioport range %04lx-%04lx\n",
+            io_from, io_to);
+
+        if ( ioports_deny_access(dom0, io_from, io_to) != 0 )
+            BUG();
+    }
+}
+
+/* Set the default IO Bitmap. */
+int ioports_setup_access(struct domain *d)
+{
+    unsigned int i, offs;
+    int rc;
+
+    if ( pv_shim )
+        return 0;
+
+#ifdef CONFIG_HVM
+    d->arch.hvm.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
+    if ( d->arch.hvm.io_bitmap == NULL )
+        return -ENOMEM;
+
+    memset(d->arch.hvm.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
+
+    if ( !is_hardware_domain(d) )
+    {
+        /*
+         * Allow direct access to the PC debug ports 0x80 and 0xed (they are
+         * often used for I/O delays, but the vmexits simply slow things down).
+         */
+        if ( hvm_port80_allowed )
+            __clear_bit(0x80, d->arch.hvm.io_bitmap);
+
+        __clear_bit(0xed, d->arch.hvm.io_bitmap);
+
+        return 0;
+    }
+#endif
+
+    /* The hardware domain is initially permitted full I/O capabilities. */
+    rc = ioports_permit_access(d, 0, 0xFFFF);
+
+    /* Modify I/O port access permissions. */
+
+    for ( offs = 0, i = ISOLATE_LSB(i8259A_alias_mask) ?: 2;
+          offs <= i8259A_alias_mask; offs += i )
+    {
+        if ( offs & ~i8259A_alias_mask )
+            continue;
+        /* Master Interrupt Controller (PIC). */
+        rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
+        /* Slave Interrupt Controller (PIC). */
+        rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
+    }
+
+    /* ELCR of both PICs. */
+    rc |= ioports_deny_access(d, 0x4D0, 0x4D1);
+
+    /* Interval Timer (PIT). */
+    for ( offs = 0, i = ISOLATE_LSB(pit_alias_mask) ?: 4;
+          offs <= pit_alias_mask; offs += i )
+        if ( !(offs & ~pit_alias_mask) )
+            rc |= ioports_deny_access(d, PIT_CH0 + offs, PIT_MODE + offs);
+
+    /* PIT Channel 2 / PC Speaker Control. */
+    rc |= ioports_deny_access(d, 0x61, 0x61);
+
+    /* INIT# and alternative A20M# control. */
+    rc |= ioports_deny_access(d, 0x92, 0x92);
+
+    /* IGNNE# control. */
+    rc |= ioports_deny_access(d, 0xF0, 0xF0);
+
+    /* ACPI PM Timer. */
+    if ( pmtmr_ioport )
+        rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
+
+    /* Reset control. */
+    rc |= ioports_deny_access(d, 0xCF9, 0xCF9);
+
+    /* PCI configuration space (NB. 0xCF8 has special treatment). */
+    rc |= ioports_deny_access(d, 0xCFC, 0xCFF);
+
+#ifdef CONFIG_HVM
+    if ( is_hvm_domain(d) )
+    {
+        /* ISA DMA controller, channels 0-3 (incl possible aliases). */
+        rc |= ioports_deny_access(d, 0x00, 0x1F);
+        /* ISA DMA controller, page registers (incl various reserved ones). */
+        rc |= ioports_deny_access(d, 0x80 + !!hvm_port80_allowed, 0x8F);
+        /* ISA DMA controller, channels 4-7 (incl usual aliases). */
+        rc |= ioports_deny_access(d, 0xC0, 0xDF);
+
+        /* HVM debug console IO port. */
+        rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
+                                  XEN_HVM_DEBUGCONS_IOPORT);
+        if ( amd_acpi_c1e_quirk )
+            rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
+    }
+#endif
+
+    /* Command-line I/O ranges. */
+    process_dom0_ioports_disable(d);
+
+    return rc;
+}
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 21158ce1812e..2b8b4d869ee7 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1033,6 +1034,9 @@ static int __init dom0_construct(const struct boot_domain *bd)
     if ( test_bit(XENFEAT_supervisor_mode_kernel, parms.f_required) )
         panic("Dom0 requires supervisor-mode execution\n");
 
+    rc = ioports_setup_access(d);
+    BUG_ON(rc != 0);
+
     rc = dom0_setup_permissions(d);
     BUG_ON(rc != 0);
 
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index a4fa3a9be713..7c4affe98533 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -792,9 +792,20 @@ static int ns16x50_init(void *arg)
     struct vuart_ns16x50 *vdev = arg;
     const struct vuart_info *info = vdev->info;
     struct domain *d = vdev->owner;
+    int rc;
 
     ASSERT(vdev);
 
+    /* Disallow sharing physical I/O port */
+    rc = ioports_deny_access(d, info->base_addr,
+                             info->base_addr + info->size - 1);
+    if ( rc )
+    {
+        ns16x50_err(info, " virtual I/O port range [0x%04lx..0x%04lx]: conflict w/ physical range\n",
+                    info->base_addr, info->base_addr + info->size - 1);
+        return rc;
+    }
+
     /* NB: report 115200 baud rate. */
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112647.1460954 (Exim 4.92)
	(envelope-from )
	id 1uufqD-0004kK-T1; Fri, 05 Sep 2025 23:27:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112647.1460954; Fri, 05 Sep 2025 23: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 1uufqC-0004j6-Uv; Fri, 05 Sep 2025 23:27:36 +0000
Received: by outflank-mailman (input) for mailman id 1112647;
 Fri, 05 Sep 2025 23:27:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufqA-0004HV-De
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufqA-008ACs-05;
 Fri, 05 Sep 2025 23:27:34 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufqA-0005Dg-04;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=kdR4+D2HTw7sqqj0HNahqkkhzpwH2jMWlfFIDzxZevA=; b=VME4w8rPFIRkvrv6atSbQYGNhs
	0kMQUp/RAjELNTLais/tj1W5WJZWZQnzQSq+78Yaje5xgmSr7H7U4fPs04obNgvxgO1RS+tMTb0Oa
	dn+3nmvjMo883tmFIFqSjO5ZRFCNEkB879c9VE9P9Alv+T81gwynHnnLkol1N+L+UCBM=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 14/15] xen/domain: allocate d->irq_caps before arch-specific initialization
Date: Fri,  5 Sep 2025 16:27:13 -0700
Message-ID: <20250905232715.440758-15-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Make sure that NS16550 emulator does not share virtual device IRQ with the
physical one. This is needed for enabling NS16550 emulator for PVH hwdom
(dom0).

To do that, move per-domain interrupt rangeset allocation before arch-specific
code. Add irqs_setup_access() to setup the initial rangeset.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- n/a
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-15-dmukhin@ford.com/
---
 xen/arch/x86/dom0_build.c       | 1 -
 xen/arch/x86/hvm/dom0_build.c   | 7 +++++++
 xen/arch/x86/include/asm/irq.h  | 2 ++
 xen/arch/x86/irq.c              | 8 ++++++++
 xen/arch/x86/pv/dom0_build.c    | 3 +++
 xen/common/domain.c             | 8 ++++++--
 xen/common/emul/vuart/ns16x50.c | 9 +++++++++
 7 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 26202b33345c..9dc87efbf3e8 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -442,7 +442,6 @@ int __init dom0_setup_permissions(struct domain *d)
 
     rc |= iomem_permit_access(d, 0UL,
                               PFN_DOWN(1UL << domain_max_paddr_bits(d)) - 1);
-    rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
 
     /* Local APIC. */
     if ( mp_lapic_addr != 0 )
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 5551f9044836..245a42dec9aa 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1348,6 +1348,13 @@ int __init dom0_construct_pvh(const struct boot_domain *bd)
          */
         pvh_setup_mmcfg(d);
 
+        rc = irqs_setup_access(d);
+        if ( rc )
+        {
+            printk("%pd unable to setup IRQ rangeset: %d\n", d, rc);
+            return rc;
+        }
+
         /*
          * Setup permissions early so that calls to add MMIO regions to the
          * p2m as part of vPCI setup don't fail due to permission checks.
diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h
index 8c81f66434a8..8bffec3bbfee 100644
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -231,4 +231,6 @@ int allocate_and_map_gsi_pirq(struct domain *d, int index, int *pirq_p);
 int allocate_and_map_msi_pirq(struct domain *d, int index, int *pirq_p,
                               int type, struct msi_info *msi);
 
+int irqs_setup_access(struct domain *d);
+
 #endif /* _ASM_HW_IRQ_H */
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 556134f85aa0..079277be719d 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -3046,3 +3046,11 @@ int allocate_and_map_msi_pirq(struct domain *d, int index, int *pirq_p,
 
     return ret;
 }
+
+int irqs_setup_access(struct domain *d)
+{
+    if ( is_hardware_domain(d) )
+        return irqs_permit_access(d, 1, nr_irqs_gsi - 1);
+
+    return 0;
+}
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 2b8b4d869ee7..1a092b802833 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -1037,6 +1037,9 @@ static int __init dom0_construct(const struct boot_domain *bd)
     rc = ioports_setup_access(d);
     BUG_ON(rc != 0);
 
+    rc = irqs_setup_access(d);
+    BUG_ON(rc != 0);
+
     rc = dom0_setup_permissions(d);
     BUG_ON(rc != 0);
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 775c33928585..edf76b02e1a1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -952,6 +952,11 @@ struct domain *domain_create(domid_t domid,
     radix_tree_init(&d->pirq_tree);
 #endif
 
+    err = -ENOMEM;
+    d->irq_caps = rangeset_new(d, "Interrupts", 0);
+    if ( !d->irq_caps )
+        goto fail;
+
     if ( (err = arch_domain_create(d, config, flags)) != 0 )
         goto fail;
     init_status |= INIT_arch;
@@ -961,8 +966,7 @@ struct domain *domain_create(domid_t domid,
 
     err = -ENOMEM;
     d->iomem_caps = rangeset_new(d, "I/O Memory", RANGESETF_prettyprint_hex);
-    d->irq_caps   = rangeset_new(d, "Interrupts", 0);
-    if ( !d->iomem_caps || !d->irq_caps )
+    if ( !d->iomem_caps )
         goto fail;
 
     if ( (err = xsm_domain_create(XSM_HOOK, d, config->ssidref)) != 0 )
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 7c4affe98533..bcbd765b815d 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -806,6 +806,15 @@ static int ns16x50_init(void *arg)
         return rc;
     }
 
+    /* Disallow sharing physical IRQ */
+    rc = irq_deny_access(d, info->irq);
+    if ( rc )
+    {
+        ns16x50_err(info, "virtual IRQ#%d: conflict w/ physical IRQ: %d\n",
+                    info->irq, rc);
+        return rc;
+    }
+
     /* NB: report 115200 baud rate. */
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:27:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:27:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112649.1460961 (Exim 4.92)
	(envelope-from )
	id 1uufqF-0005Fj-Vr; Fri, 05 Sep 2025 23:27:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112649.1460961; Fri, 05 Sep 2025 23:27: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 1uufqF-0005CQ-AU; Fri, 05 Sep 2025 23:27:39 +0000
Received: by outflank-mailman (input) for mailman id 1112649;
 Fri, 05 Sep 2025 23:27:35 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufqB-0004Ts-IH
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:27:35 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufqB-008AD3-0N;
 Fri, 05 Sep 2025 23:27:35 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufqB-0005Dk-0M;
 Fri, 05 Sep 2025 23:27: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=3mwBazL9kANwQ3BnZxsZTOwFxpPGlCvixHJoTT4Lu2c=; b=YlcGtW3+chCoHlxxDwnt0y8l13
	sIv7ttz6hYQ0OurpgLhVhQQ95/EEVfqYbKSPaCNFXpLDqoRK9x4EhwXNcY1QoefMyQGYtiDIBbkwn
	PP+ivJWyufaoLcSB930NB9DcAHQbiKxUbejx0DWCnT0ZsYP6pZw8hLqWWjd144N3aIJc=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v6 15/15] emul/ns16x50: implement IRQ emulation via vIOAPIC
Date: Fri,  5 Sep 2025 16:27:14 -0700
Message-ID: <20250905232715.440758-16-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

PVH domains use vIOAPIC, not vPIC and NS16550 emulates ISA IRQs which cannot
be asserted on vIOAPIC.

{map,unmap}_domain_pirq_emuirq() infrastructure is modified by adding new
type of interrupt resources 'IRQ_EMU' which means 'emulated device IRQ'
(similarly to IRQ_MSI_EMU).

This is necessary to for IOAPIC emulation code to skip IRQ->PIRQ mapping
(vioapic_hwdom_map_gsi()) when guest OS unmasks vIOAPIC pin corresponding to
virtual device's IRQ.

Also, hvm_gsi_eoi() is modified to trigger assertion in hvm_gsi_deassert()
path for ISA IRQs.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- did cosmetic renaming and dropped unneeded changes
- fixed ns16x50_irq_assert() and ns16x50_irq_deassert() as per Jan's
  suggestion in v4 (missed to address in v5)
- fixed __hvm_dpci_eoi()
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-16-dmukhin@ford.com/
---
 xen/arch/x86/hvm/vioapic.c        | 10 ++++++++++
 xen/arch/x86/include/asm/irq.h    |  6 ++++++
 xen/common/emul/vuart/ns16x50.c   | 28 ++++++++++++++++++++++++++++
 xen/drivers/passthrough/x86/hvm.c | 11 ++++++++++-
 4 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index 7c725f9e471f..6314874b64f7 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -177,6 +177,16 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi, unsigned int trig,
 
     ASSERT(is_hardware_domain(currd));
 
+    /*
+     * Interrupt is claimed by one of the platform virtual devices (e.g.
+     * NS16550); do nothing.
+     */
+    write_lock(&currd->event_lock);
+    ret = is_domain_emuirq_claimed(currd, gsi);
+    write_unlock(&currd->event_lock);
+    if ( ret )
+        return 0;
+
     /* Interrupt has been unmasked, bind it now. */
     ret = mp_register_gsi(gsi, trig, pol);
     if ( ret == -EEXIST )
diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h
index 8bffec3bbfee..bdbe700274e9 100644
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -168,6 +168,11 @@ void free_domain_pirqs(struct domain *d);
 int map_domain_emuirq_pirq(struct domain *d, int pirq, int emuirq);
 int unmap_domain_pirq_emuirq(struct domain *d, int pirq);
 
+#define domain_emuirq_claim(d, irq)     map_domain_emuirq_pirq(d, irq, IRQ_EMU)
+#define domain_emuirq_unclaim(d, irq)   unmap_domain_pirq_emuirq(d, irq)
+#define is_domain_emuirq_claimed(d, irq) \
+    (domain_pirq_to_emuirq(d, irq) != IRQ_UNBOUND)
+
 /* Evacuate interrupts assigned to CPUs not present in the CPU online map. */
 void fixup_irqs(void);
 void fixup_eoi(void);
@@ -221,6 +226,7 @@ void cleanup_domain_irq_mapping(struct domain *d);
 #define IRQ_UNBOUND (-1)
 #define IRQ_PT      (-2)
 #define IRQ_MSI_EMU (-3)
+#define IRQ_EMU     (-4)
 
 bool cpu_has_pending_apic_eoi(void);
 
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index bcbd765b815d..723b1b0bb55d 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -292,6 +292,8 @@ static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
 
     if ( has_vpic(d) )
         vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
+    else if ( has_vioapic(d) )
+        vector = hvm_ioapic_assert(d, info->irq, false);
     else
         ASSERT_UNREACHABLE();
 
@@ -305,6 +307,8 @@ static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
 
     if ( has_vpic(d) )
         hvm_isa_irq_deassert(d, info->irq);
+    else if ( has_vioapic(d) )
+        hvm_ioapic_deassert(d, info->irq);
     else
         ASSERT_UNREACHABLE();
 
@@ -815,6 +819,17 @@ static int ns16x50_init(void *arg)
         return rc;
     }
 
+    /* Claim virtual IRQ */
+    write_lock(&d->event_lock);
+    rc = domain_emuirq_claim(d, info->irq);
+    write_unlock(&d->event_lock);
+    if ( rc )
+    {
+        ns16x50_err(info, "virtual IRQ#%d: cannot claim: %d\n",
+                    info->irq, rc);
+        return rc;
+    }
+
     /* NB: report 115200 baud rate. */
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
@@ -834,9 +849,22 @@ static int ns16x50_init(void *arg)
 static void cf_check ns16x50_deinit(void *arg)
 {
     struct vuart_ns16x50 *vdev = arg;
+    const struct vuart_info *info;
+    struct domain *d;
+    int rc;
 
     ASSERT(vdev);
 
+    d = vdev->owner;
+    info = vdev->info;
+
+    write_lock(&d->event_lock);
+    rc = domain_emuirq_unclaim(d, info->irq);
+    write_unlock(&d->event_lock);
+    if ( rc )
+        ns16x50_err(vdev, "virtual IRQ#%d: cannot unclaim: %d\n",
+                    info->irq, rc);
+
     spin_lock(&vdev->lock);
     ns16x50_fifo_tx_flush(vdev);
     spin_unlock(&vdev->lock);
diff --git a/xen/drivers/passthrough/x86/hvm.c b/xen/drivers/passthrough/x86/hvm.c
index a2ca7e0e570c..20641194561f 100644
--- a/xen/drivers/passthrough/x86/hvm.c
+++ b/xen/drivers/passthrough/x86/hvm.c
@@ -922,7 +922,16 @@ static void __hvm_dpci_eoi(struct domain *d,
 
 static void hvm_gsi_eoi(struct domain *d, unsigned int gsi)
 {
-    struct pirq *pirq = pirq_info(d, gsi);
+    struct pirq *pirq;
+
+    /* Check if GSI is claimed by one of the virtual devices. */
+    if ( is_domain_emuirq_claimed(d, gsi) )
+    {
+        hvm_gsi_deassert(d, gsi);
+        return;
+    }
+
+    pirq = pirq_info(d, gsi);
 
     /* Check if GSI is actually mapped. */
     if ( !pirq_dpci(pirq) )
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:34:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112821.1460982 (Exim 4.92)
	(envelope-from )
	id 1uufwV-00030V-Rh; Fri, 05 Sep 2025 23:34:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112821.1460982; Fri, 05 Sep 2025 23: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 1uufwV-00030O-PA; Fri, 05 Sep 2025 23:34:07 +0000
Received: by outflank-mailman (input) for mailman id 1112821;
 Fri, 05 Sep 2025 23:34:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufwU-00030I-DU
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:34:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufwS-008ANg-2G;
 Fri, 05 Sep 2025 23:34:04 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufwS-0005QN-22;
 Fri, 05 Sep 2025 23:34:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=fE7dfamD3/y6Do8P8KllY6vbBuhY9YcldmKhoAUq324=; b=
	ozGLzVylFoCz98McC8cnuTlnSVXrPs7Mrsdilm3NwQM/G18moXeHzuYG7YMYz4jT0K3orJtVOjb+z
	Yz7o2DUF1DzsJRomFvAWq0R5wK+9sGmP89irMyW9JC9jeOj/VW/w9E3j2Gdx+GaP2C8wxUROoDxz6
	FGUvPW1ZmgY8z+XLs=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 16:34:03 -0700
To: Jan Beulich 
Cc: Stefano Stabellini ,
	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
Subject: Re: [PATCH v5 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-4-dmukhin@ford.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Tue, Sep 02, 2025 at 11:36:19AM +0200, Jan Beulich wrote:
> On 29.08.2025 21:57, Stefano Stabellini wrote:
> > On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> >> +static void cf_check ns16x50_free(void *arg)
> >> +{
> >> +    struct vuart_ns16x50 *vdev = arg;
> >> +
> >> +    if ( vdev )
> >> +        ns16x50_deinit(vdev);
> >> +
> >> +    XVFREE(vdev);
> > 
> > XVFREE should only be called if ( vdev )
> 
> Why would this be? Like free(), both xfree() and xvfree() are fine to be
> called with a NULL pointer. What's odd here is that the uppercase form (the
> wrapper macro) is used - clearing the local variable is pointless when it
> is about to go out of scope anyway.

Thank you for remark!
I switched the code to xvfree() in v6


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:34:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:34:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112829.1460992 (Exim 4.92)
	(envelope-from )
	id 1uufx0-0003T5-3n; Fri, 05 Sep 2025 23:34:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112829.1460992; Fri, 05 Sep 2025 23: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 1uufx0-0003Sy-10; Fri, 05 Sep 2025 23:34:38 +0000
Received: by outflank-mailman (input) for mailman id 1112829;
 Fri, 05 Sep 2025 23:34:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uufwy-0003Sm-Lp
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:34:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uufwx-008AO2-10;
 Fri, 05 Sep 2025 23:34:35 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uufwx-0005QU-0t;
 Fri, 05 Sep 2025 23:34: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=awcIl7NCsITYjFzyd6+CIfJ2lT+m+hjAFmrdSiEFxXo=; b=
	YfvswKdw5V/sLO9tJ3GC2wzt7OPtqwunatsx8XIfC0wAslISISLlP6bBJgQlpn3hk4n82Tutlptkc
	53sdf+AvdOjrmrxQArdS9hZ3vuoTBdiuIo+TXRiiDzpyrh7XwbV/tgs/BNkBuJXKUta5XWxy4bWDZ
	1qtHSDSncjU5N9vRg=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 16:34:34 -0700
To: Jan Beulich 
Cc: Stefano Stabellini ,
	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
Subject: Re: [PATCH v5 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-4-dmukhin@ford.com>
 
 
 <7a9210e1-d579-48e1-99ca-1685d7561529@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7a9210e1-d579-48e1-99ca-1685d7561529@suse.com>

On Tue, Sep 02, 2025 at 11:32:31AM +0200, Jan Beulich wrote:
> On 02.09.2025 01:11, dmukhin@xen.org wrote:
> > On Fri, Aug 29, 2025 at 12:57:43PM -0700, Stefano Stabellini wrote:
> >> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> >>> --- a/xen/common/emul/vuart/Kconfig
> >>> +++ b/xen/common/emul/vuart/Kconfig
> >>> @@ -3,4 +3,22 @@ config VUART_FRAMEWORK
> >>>  
> >>>  menu "UART Emulation"
> >>>  
> >>> +config VUART_NS16X50
> >>> +	bool "NS16550-compatible UART Emulator" if EXPERT
> >>> +	depends on X86 && HVM
> >>> +	select VUART_FRAMEWORK
> >>
> >> default n
> > 
> > Ack
> 
> No "default n" should ever be put anywhere; it's simply redundant.

Kept code as is in v6.


From xen-devel-bounces@lists.xenproject.org Fri Sep 05 23:45:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Sep 2025 23:45:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112841.1461003 (Exim 4.92)
	(envelope-from )
	id 1uug70-0005tI-07; Fri, 05 Sep 2025 23:44:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112841.1461003; Fri, 05 Sep 2025 23:44: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 1uug6z-0005tB-Te; Fri, 05 Sep 2025 23:44:57 +0000
Received: by outflank-mailman (input) for mailman id 1112841;
 Fri, 05 Sep 2025 23:44:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uug6y-0005t5-3I
 for xen-devel@lists.xenproject.org; Fri, 05 Sep 2025 23:44:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uug6w-008AZj-2H;
 Fri, 05 Sep 2025 23:44:54 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uug6w-00069c-23;
 Fri, 05 Sep 2025 23:44:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=WqWhclai22VZ72GVJYlnH55sI1NxoxgfvAPmP7D1fSA=; b=
	SlSXs3Fx9uyNRPjHwJg5CywjB8hdGLaqe0YZTMTDurQpmC1LBGZKkmLgYe6WqWLQG1SbVDrufdy2w
	Lwu3eGiPTgykU4dp7u4ROUJtdrva9mCaWlCARQN4+9hym+O9YKcgr5QQiIXF1t8pMBp/l0OCJxGCp
	9XX5tq19REFyw6AzU=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 16:44:53 -0700
To: Stefano Stabellini 
Cc: Stefano Stabellini ,
	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 15/15] emul/ns16x50: implement IRQ emulation via
 vIOAPIC
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-16-dmukhin@ford.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 05, 2025 at 04:01:15PM -0700, Stefano Stabellini wrote:
> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> > On Fri, Aug 29, 2025 at 03:21:13PM -0700, Stefano Stabellini wrote:
> > > On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > > > From: Denis Mukhin  
> > > > 
> > > > PVH domains use vIOAPIC, not vPIC and NS16550 emulates ISA IRQs which cannot
> > > > be asserted on vIOAPIC.
> > > 
> > > One option is to enable the vPIT for PVH domains when the NS16550
> > > emulator is enabled. Would that resolve the problem? That would be a
> > > simpler solution compared to adding IRQ_EMU because the IRQ_* logic is
> > > already quite complex.
> > 
> > vPIC? (PIT is timer).
> > 
> > I tried to enable vPIC for hwdom, but there's some more work to make it work
> > :-/
> > 
> > > 
> > > Alternatively...
> > [..]
> > > 
> > > > --- a/xen/arch/x86/hvm/vioapic.c
> > > > +++ b/xen/arch/x86/hvm/vioapic.c
> > > > @@ -177,6 +177,16 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi, unsigned int trig,
> > > >  
> > > >      ASSERT(is_hardware_domain(currd));
> > > >  
> > > > +    /*
> > > > +     * Interrupt is claimed by one of the platform virtual devices (e.g.
> > > > +     * NS16550); do nothing.
> > > > +     */
> > > > +    write_lock(&currd->event_lock);
> > > > +    ret = domain_irq_to_emuirq(currd, gsi);
> > > > +    write_unlock(&currd->event_lock);
> > > > +    if ( ret != IRQ_UNBOUND )
> > > > +        return 0;
> > > 
> > > ..alternatively, we could have an add-hoc check here? Not very nice but
> > > at least it would be very simple.
> > > 
> > > In other words, adding vPIT is preferable in my opinion but as a second
> > > option I would consider an ad-hoc check. I would try to avoid adding
> > > IRQ_EMU -- that should be the last resort in my view.
> > 
> > In my opinion, IRQ_EMU falls into category of an ad-hoc.
> > 
> > I think vioapic_hwdom_map_gsi() should not depend on the presence of certain
> > virtual devices but rely on some global flag, e.g. via quering
> > domain_irq_to_emuirq() infra.
> 
> Hi Denis, the reason why IRQ_EMU is dangerous is that there are a bunch
> of checks emuirq != IRQ_PT and also emuirq != IRQ_MSI_EMU which I don't
> know if they would still behave correctly after the introduction of
> IRQ_EMU.

!= IRQ_PT checks (arch/x86/irq.c) are done from map_domain_emuirq_pirq()
and unmap_domain_pirq_emuirq() which I use for IRQ_EMU case.

Those checks are needed to correctly allocate an "ad-hoc flag" in a radix
"IRQ_EMU" tree, i.e. IRQ_EMU case is handled correctly.

!= IRQ_MSI_EMU check (there's only one in arch/x86/hvm/irq.c) is done from
hvm_inject_msi(), it guarantees that IRQ_EMU case is handled correctly.

> 
> I would prefer to avoid the problem if possible...


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 00:07:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 00:07:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112852.1461014 (Exim 4.92)
	(envelope-from )
	id 1uugSm-0002IA-D1; Sat, 06 Sep 2025 00:07:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112852.1461014; Sat, 06 Sep 2025 00: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 1uugSm-0002I3-9M; Sat, 06 Sep 2025 00:07:28 +0000
Received: by outflank-mailman (input) for mailman id 1112852;
 Sat, 06 Sep 2025 00:07:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uugSl-0002Hx-QA
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 00:07:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uugSj-008Bba-2y;
 Sat, 06 Sep 2025 00:07:26 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uugSj-00073l-2l;
 Sat, 06 Sep 2025 00:07: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=ESXK1kCG5jcwXm2b5h+fHdnxlmhubehYPJseWVKNRpE=; b=
	k01ehEm5nJQqShYaZwKjvrgtMaa/CBtFw3zyH/hi0TZwTXLiLHfa/YTGZRO3D4ZMOhnckg0nPAT4M
	tAYn96Jey+el+sfKCtMxnD1jXv/BcsLO59Pq0CPm/EjcDLOXlJ8ha8OjqHjCQ2kt6mKsjltQKB3I9
	CekfAR9LoVqUwtd80=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 17:07:24 -0700
To: Jan Beulich 
Cc: Stefano Stabellini ,
	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
Subject: Re: [PATCH v5 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250828235409.2835815-1-dmukhin@ford.com>
 <20250828235409.2835815-4-dmukhin@ford.com>
 
 
 <7a9210e1-d579-48e1-99ca-1685d7561529@suse.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 05, 2025 at 04:34:34PM -0700, dmukhin@xen.org wrote:
> On Tue, Sep 02, 2025 at 11:32:31AM +0200, Jan Beulich wrote:
> > On 02.09.2025 01:11, dmukhin@xen.org wrote:
> > > On Fri, Aug 29, 2025 at 12:57:43PM -0700, Stefano Stabellini wrote:
> > >> On Thu, 28 Aug 2025, dmukhin@xen.org wrote:
> > >>> --- a/xen/common/emul/vuart/Kconfig
> > >>> +++ b/xen/common/emul/vuart/Kconfig
> > >>> @@ -3,4 +3,22 @@ config VUART_FRAMEWORK
> > >>>  
> > >>>  menu "UART Emulation"
> > >>>  
> > >>> +config VUART_NS16X50
> > >>> +	bool "NS16550-compatible UART Emulator" if EXPERT
> > >>> +	depends on X86 && HVM
> > >>> +	select VUART_FRAMEWORK
> > >>
> > >> default n
> > > 
> > > Ack
> > 
> > No "default n" should ever be put anywhere; it's simply redundant.
> 
> Kept code as is in v6.

Sorry, v6 has "default n" update which I need to remove.


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 00:18:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 00:18:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112877.1461022 (Exim 4.92)
	(envelope-from )
	id 1uugd5-0004Ff-Cm; Sat, 06 Sep 2025 00:18:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112877.1461022; Sat, 06 Sep 2025 00:18: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 1uugd5-0004FY-9y; Sat, 06 Sep 2025 00:18:07 +0000
Received: by outflank-mailman (input) for mailman id 1112877;
 Sat, 06 Sep 2025 00:18: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 1uugd4-0004F5-49
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 00:18:06 +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 f321782c-8ab6-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 02:18: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 CAEFC4484B;
 Sat,  6 Sep 2025 00:18:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 451EDC4CEF5;
 Sat,  6 Sep 2025 00:17: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: f321782c-8ab6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757117880;
	bh=wbwKxHFqpiEhDUFV1KXEKYeNC+13Ffjf3eWfwXwwTCA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FCDNdgHfjsYckpWvXJz2BGhihyiQEV4mleja+OQMsNNNL05h4/MF5RSI6BhnHVLJG
	 b5jGXJsJToGMWlbrWRKMhfSMR6VI8cTmV7g2U9KrF/ACBgOdfnNiQ2rUnrLak8d+po
	 BpTuFlFUovmujnx1BR0XwBWMBd20TzpQeN6UuH3RlKodzUOuwDC3PXHzAMq6IKTg4Q
	 j1LYDQOpX9UUqZhkqz3PmuturXmynIRXW4L7rOS9doN5XCfTcAXwMFeJ6WpbLO108u
	 0FLJ+El93VAvYEycp8MkSO3RrkE4Lus/B1ZoRB6jRNuW40ryC4vLHypZDlhbYA0HGA
	 YzjY3UyYZNw3w==
Date: Fri, 5 Sep 2025 17:17:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Leonid Komarianskyi 
cc: "xen-devel@lists.xenproject.org" , 
    "olekstysh@gmail.com" , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Anthony PERARD , 
    Oleksii Kurochko , 
    Community Manager 
Subject: Re: [PATCH v7 00/12] Introduce eSPI support
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

Hi Leonid,

I was about to commit this but unfortunately it is introducing MISRA
regressions. See:
https://gitlab.com/xen-project/people/sstabellini/xen/-/tree/ppp6?ref_type=heads

https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11265005118

Compared this result:
https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp6/ARM64/11265005118/PROJECT.ecd;/by_service.html#service&kind

Against upstream staging:
https://eclair-analysis-logs.xenproject.org/fs/space/XEN.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/ARM64/11264772605/PROJECT.ecd;/by_service.html#service&kind

It is introducing a couple of easy-to-fix 16.3 issues and also a couple
of new 16.4 issues. They should be all easy to fix. It is also
introducing three new 13.2 issues and one 18.1 but I haven't looked
closely into those. Please address them.


Oleksii,

Technically, the series is fully acked and ready to be committed. From a
risk perspective, I would be comfortable committing it now with the
outstanding MISRA regressions, leaving Leonid to fix them over the next
few days. However, I have not done so because it would make it harder to
spot the MISRA regressions due to the way the scanner works (it
compares against the previous version).

I suggest we allow this series to be committed in the next couple of
days, once Leonid addresses the regressions, even though it would
technically be past the feature freeze.

Cheers,

Stefano

P.S.

Leonid, you might want to check my commits because I fixed a couple of
things on commit, in addition to adding the various acked-by tags.


On Thu, 4 Sep 2025, Leonid Komarianskyi wrote:
> Hello everyone!
> 
> V6 contains an issue for debug builds with CONFIG_GICV3_ESPI=n due to a
> mistake in the ASSERT() condition in the is_espi() function. This patch
> series fixes the issue and also includes minor fixes according to the
> review of V6.
> 
> Summarized description:
> This patch series adds support for the extended shared peripheral
> interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
> and guest domains. The implementation uses a generic approach to handle
> eSPIs, similar to regular SPIs, while maintaining compatibility with the
> existing SPI range. Functionality remains unchanged for setups that do
> not require eSPIs.
> 
> The series includes:
> 1) General refactoring of common IRQ operations with GIC registers to
> improve code readability, simplify further maintenance and prepare the
> key functions for eSPI implementation.
> 2) Introducing a new Kconfig option (default n) to enable or disable
> eSPI support. Disabling this option prevents unnecessary resource
> allocation for setups that do not require eSPIs.
> 3) Adding additional resources to store required information and operate
> with up to 1024 interrupts from eSPI range.
> 4) Adjusting assertions and checks to pass verification for INTIDs in
> the eSPI range.
> 5) Configuration of eSPI-specific registers during GIC initialization
> for systems with GICv3.1+ hardware.
> 6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
> access and operate within the eSPI's INTIDs.
> 7) Updating documentation and CHANGELOG to reflect the changes made for eSPI
> support.
> 
> Also, to simplify reviewing, please find below link to unsquashed patches, that
> are on top of every patch, that is changed in the series, compared to V6:
> https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7-unsquashed/
> 
> Github branch with patch series:
> https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7/
> 
> Changes in V7:
> - individual changes in patches
> 
> Link on V6:
> - https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00296.html
> 
> Changes in V6:
> - individual changes in patches
> 
> Link on V5:
> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.html
> 
> Changes in V5:
> - individual changes in patches
> 
> Link on V4:
> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.html
> 
> Changes in V4:
> - added a patch for documentation
> - individual changes in patches
> 
> Link on V3:
> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.html
> 
> Changes in V3:
> - added a patch to update CHANGELOG.md
> - individual changes in patches
> 
> Link on V2:
> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.html
> 
> Changes in V2:
> - added 2 more patches to implement helper
>   functions for gic/vgic:
>   xen/arm: gic: implement helper functions for INTID checks
>   xen/arm: vgic: implement helper functions for virq checks
> - removed 2 patches:
>   xen/arm/irq: allow assignment/releasing of eSPI interrupts
>   xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
>   since their functionality can be moved to appropriate patches after
>   introducing patches with helper functions
> - individual changes in patches
> 
> Link on V1:
> - https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.html
> 
> Leonid Komarianskyi (12):
>   xen/arm: gicv3: refactor obtaining GIC addresses for common operations
>   xen/arm: gic: implement helper functions for INTID checks
>   xen/arm: vgic: implement helper functions for virq checks
>   xen/arm/irq: add handling for IRQs in the eSPI range
>   xen/arm: gicv3: implement handling of GICv3.1 eSPI
>   xen/arm/irq: allow eSPI processing in the gic_interrupt function
>   xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
>   xen/arm: vgic: add resource management for extended SPIs
>   xen/arm: domain_build/dom0less-build: adjust domains config to support
>     eSPIs
>   xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
>   doc/man: update description for nr_spis with eSPI
>   CHANGELOG.md: add mention of GICv3.1 eSPI support
> 
>  CHANGELOG.md                           |   2 +
>  docs/man/xl.cfg.5.pod.in               |  13 +-
>  xen/arch/arm/Kconfig                   |   8 +
>  xen/arch/arm/dom0less-build.c          |   2 +-
>  xen/arch/arm/domain_build.c            |   2 +-
>  xen/arch/arm/gic-v3.c                  | 195 +++++++++++++++++++----
>  xen/arch/arm/gic.c                     |   8 +-
>  xen/arch/arm/include/asm/gic.h         |  28 ++++
>  xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
>  xen/arch/arm/include/asm/irq.h         |  38 +++++
>  xen/arch/arm/include/asm/vgic.h        |  56 ++++++-
>  xen/arch/arm/irq.c                     |  62 +++++++-
>  xen/arch/arm/vgic-v3.c                 | 203 ++++++++++++++++++-----
>  xen/arch/arm/vgic.c                    | 212 +++++++++++++++++++++++--
>  xen/arch/arm/vgic/vgic.c               |   5 +
>  15 files changed, 762 insertions(+), 112 deletions(-)
> 
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 00:33:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 00:33:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112897.1461033 (Exim 4.92)
	(envelope-from )
	id 1uugsC-0007L3-Ld; Sat, 06 Sep 2025 00:33:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112897.1461033; Sat, 06 Sep 2025 00:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uugsC-0007Kw-Ip; Sat, 06 Sep 2025 00:33:44 +0000
Received: by outflank-mailman (input) for mailman id 1112897;
 Sat, 06 Sep 2025 00:33:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uugsB-0007Ki-0W
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 00:33:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uugsA-008C89-0B;
 Sat, 06 Sep 2025 00:33:42 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uugs9-000869-2v;
 Sat, 06 Sep 2025 00:33: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=GS34SKp1X4/mxc/EDFunZtSXF2DxGAoV21zbmVdse1o=; b=
	Reo4dC35fCPYF8965EdcY6GIHGsqPgasexwj2HE5EiXarEBome1x2jASqaIygQZ2AlEhwEFjn6XsI
	FOo3sEpgSaTFlqVYvmehnWrE+q8lPMDt+kL5lhi/UkLA3rWWHkpd4kfoJmZSRKaC8C6FM37l5rjK5
	rdVViWhbgsEVYFpMM=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 17:33:40 -0700
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
	julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
	sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v6 00/15] x86: introduce NS16550-compatible UART emulator
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>

On Fri, Sep 05, 2025 at 04:26:59PM -0700, dmukhin@xen.org wrote:
> 
>   HVM
>   ---
>   Tested only boot of HVM linux guest with OVMF as the virtual firmware.
>   SeaBIOS as a virtual firmware is not tested.

Sorry, current series will enable the emulator for hwdom PVH only.
To enable the emulator for HVM, an extra change is neeed.


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 00:34:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 00:34:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112910.1461042 (Exim 4.92)
	(envelope-from )
	id 1uugtI-0007tD-Up; Sat, 06 Sep 2025 00:34:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112910.1461042; Sat, 06 Sep 2025 00: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 1uugtI-0007t6-SC; Sat, 06 Sep 2025 00:34:52 +0000
Received: by outflank-mailman (input) for mailman id 1112910;
 Sat, 06 Sep 2025 00:34:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uugtH-0007st-16
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 00:34:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uugtG-008C9V-1V;
 Sat, 06 Sep 2025 00:34:50 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uugtG-00089F-1J;
 Sat, 06 Sep 2025 00:34:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=iSm66fenvOChSunebt9Y+9D1XsGDMumnX4/SzFp5LNU=; b=
	rOn/bwSIZYAyCO+QR8/Y+eIDjirCc8ICy/LB+vWYsOl0YBhVBTzyeYPlWvRm9pS447jJkwED/r0VC
	76JGe38Eqk5yk/rkbcmWsLRqpUG2+BOr8+h74FMinHgKTiiuuSoVwStxv9PJ7y3SpGtyd7mKX4vUK
	u0m/PFLr2GeAPi5ZU=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 17:34:49 -0700
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
	julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
	sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v6 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-4-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250905232715.440758-4-dmukhin@ford.com>

On Fri, Sep 05, 2025 at 04:27:02PM -0700, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
[..]
> --- a/xen/common/emul/vuart/Kconfig
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -3,4 +3,23 @@ config VUART_FRAMEWORK
>  
>  menu "UART Emulation"
>  
> +config VUART_NS16X50
> +	bool "NS16550-compatible UART Emulator" if EXPERT
> +	depends on X86 && HVM
> +	select VUART_FRAMEWORK
> +	default n

Forgot to drop 'default n'

> +	help
> +	  In-hypervisor NS16x50 UART emulation.
> +
> +	  Only legacy PC COM2 port is emulated.
> +
> +	  This is strictly for testing purposes (such as early HVM guest console),
> +	  and not appropriate for use in production.
> +


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 01:42:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 01:42:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112941.1461052 (Exim 4.92)
	(envelope-from )
	id 1uuhwf-0007Tw-Jt; Sat, 06 Sep 2025 01:42:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112941.1461052; Sat, 06 Sep 2025 01:42: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 1uuhwf-0007Tp-Ge; Sat, 06 Sep 2025 01:42:25 +0000
Received: by outflank-mailman (input) for mailman id 1112941;
 Sat, 06 Sep 2025 01:42: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 1uuhwe-0007Tj-8H
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 01:42:24 +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 b82dd12f-8ac2-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 03:42:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id D91F943F10;
 Sat,  6 Sep 2025 01:42:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81AB8C4CEF1;
 Sat,  6 Sep 2025 01:42: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: b82dd12f-8ac2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757122935;
	bh=ZhGYbmi2VEH/v5eVOEwAtGTcOpfqj9aGKUpfVmDVoeI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IdfwKahc0WeteXHCiOIx4WTo04uQbYOO2f9gr5EaMCbMaHx1Qc/YUTrcBSxN87bEY
	 S2GJg91ZttBbo6h9xi4hgGPGjg+JuQeXMgZ9YkZjhXvT8RMnN7RTi7mWJmBn2HJnz9
	 96nQi9ts19QdtFcZ3tYFMIZwAm0s3AFhVka3Wde9rxKsOOCN73A4+FbB4O66q0naqT
	 o9RQhL7hAWYWGlTRXbtyPdu6OIxn2PZkqYPtB2fkMYrweSv7wzpfloF7tmQwlUiJ0K
	 l/LOq7+BhtN48eiMZUbDexjL9+UYCQ6C1/zLX4HUXNQS9Zj4tc6kwFBZ+PbVLSOlqi
	 F8Lt9kvAL8MzQ==
Date: Fri, 5 Sep 2025 18:42:13 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 06/15] emul/ns16x50: implement IER/IIR registers
In-Reply-To: <20250905232715.440758-7-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-7-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, 5 Sep 2025, dmukhin@xen.org wrote:
> +/*
> + * Get the interrupt identity reason.
> + *
> + * IIR is re-calculated once called, because ns16x50 always reports high
> + * priority events first.
> + * regs[NS16X50_REGS_NUM + UART_IIR] is used to store THR reason only.
> + */
> +static uint8_t ns16x50_iir_get(const struct vuart_ns16x50 *vdev)
> +{
> +    /*
> +     * Interrupt identity reasons by priority.
> +     * NB: high priority are at lower indexes below.
> +     */
> +    static const struct {
> +        bool (*check)(const struct vuart_ns16x50 *vdev);
> +        uint8_t ier;
> +        uint8_t iir;
> +    } iir_by_prio[] = {
> +        [0] = { ns16x50_iir_check_lsi, UART_IER_ELSI,   UART_IIR_LSI },
> +        [1] = { ns16x50_iir_check_rda, UART_IER_ERDAI,  UART_IIR_RDA },
> +        [2] = { ns16x50_iir_check_thr, UART_IER_ETHREI, UART_IIR_THR },
> +        [3] = { ns16x50_iir_check_msi, UART_IER_EMSI,   UART_IIR_MSI },
> +    };
> +    const uint8_t *regs = vdev->regs;
> +    uint8_t iir = 0;
> +    unsigned int i;
> +
> +    /*
> +     * NB: every interaction w/ ns16x50 registers (except DLAB=1) goes
> +     * through that call.
> +     */
> +    ASSERT(spin_is_locked(&vdev->lock));
> +
> +    for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ )
> +    {
> +        if ( (regs[UART_IER] & iir_by_prio[i].ier) &&
> +             iir_by_prio[i].check(vdev) )
> +            break;
> +
> +    }
> +    if ( i == ARRAY_SIZE(iir_by_prio) )
> +        iir |= UART_IIR_NOINT;
> +    else
> +        iir |= iir_by_prio[i].iir;
> +
> +    if ( regs[UART_FCR] & UART_FCR_ENABLE )
> +        iir |= UART_IIR_FE;
> +
> +    return iir;
> +}
> +
> +static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
> +{
> +    struct domain *d = vdev->owner;
> +    const struct vuart_info *info = vdev->info;
> +    int vector;
> +
> +    if ( has_vpic(d) )
> +        vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
> +    else
> +        ASSERT_UNREACHABLE();

This seems dangerous as there are guests without vpic


> +    ns16x50_debug(vdev, "IRQ#%d vector %d assert\n", info->irq, vector);
> +}
> +
> +static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
> +{
> +    struct domain *d = vdev->owner;
> +    const struct vuart_info *info = vdev->info;
> +
> +    if ( has_vpic(d) )
> +        hvm_isa_irq_deassert(d, info->irq);
> +    else
> +        ASSERT_UNREACHABLE();

also here


> +    ns16x50_debug(vdev, "IRQ#%d deassert\n", info->irq);
> +}



From xen-devel-bounces@lists.xenproject.org Sat Sep 06 01:42:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 01:42:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112942.1461062 (Exim 4.92)
	(envelope-from )
	id 1uuhwl-0007iQ-Qy; Sat, 06 Sep 2025 01:42:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112942.1461062; Sat, 06 Sep 2025 01: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 1uuhwl-0007iJ-Nz; Sat, 06 Sep 2025 01:42:31 +0000
Received: by outflank-mailman (input) for mailman id 1112942;
 Sat, 06 Sep 2025 01:42: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 1uuhwj-0007Tj-Rl
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 01:42:29 +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 be9a03df-8ac2-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 03:42: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 BE096602AB;
 Sat,  6 Sep 2025 01:42:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BC05C4CEF1;
 Sat,  6 Sep 2025 01:42: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: be9a03df-8ac2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757122946;
	bh=6xqp9cjx3BzDJ3XJ7gGNSnkBn3Og11f1EICkfE1liBs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Ac1HSdyTQcZynGrwmlU+q9b2pS4QaUIA/JN37mR2++7FimrP9cJchQDmdJ1pZEkiW
	 vPpUUaEOIxBTQhLBPaTzEuFI59iBJjTQzJa3SQHRWsoG/7pEekK7eHdErQSDP4DAPO
	 9uPyEpKlRlN1TkIKupkxVlPHig+s53IHquYRNFROnyAY7KZhTTnanL8BWFRnY3vGjJ
	 giMZKihWUSXt202LQP+6McIzry9TsUB2QKcc2xGX8AlGXD/108z1+Uj2gDB5qlivsW
	 a3hRDbhNqS3O4dM7Av7Qdk9pre1uHDQE+gxP5Y7/OSVIalP8ymWW1ExRYOUTwxIK2i
	 3HhaASAs3eyLw==
Date: Fri, 5 Sep 2025 18:42:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 08/15] emul/ns16x50: implement MCR/MSR registers
In-Reply-To: <20250905232715.440758-9-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-9-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add MCR/MSR registers emulation to the I/O port handler.
> 
> Add implementation of ns16x50_iir_check_msi().
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes in v5:
> - Moved earlier in the series
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-10-dmukhin@ford.com/
> ---
>  xen/common/emul/vuart/ns16x50.c | 62 ++++++++++++++++++++++++++++++++-
>  1 file changed, 61 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> index 9d1fe0284362..a8ec9f6c3a04 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -108,7 +108,7 @@ static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
>  
>  static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
>  {
> -    return false;
> +    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
>  }
>  
>  /*
> @@ -230,12 +230,63 @@ static int ns16x50_io_write8(
>              regs[UART_LCR] = val;
>              break;
>  
> +        case UART_MCR: {
> +            uint8_t msr_curr, msr_next, msr_delta;
> +
> +            msr_curr = regs[UART_MSR];
> +            msr_next = 0;
> +            msr_delta = 0;
> +
> +            if ( val & UART_MCR_RESERVED0 )
> +                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x\n",
> +                             UART_MCR_RESERVED0);
> +
> +            if ( val & UART_MCR_TCRTLR )
> +                ns16x50_warn(vdev, "MCR: not supported: %x\n",
> +                             UART_MCR_TCRTLR);
> +
> +            if ( val & UART_MCR_RESERVED1 )
> +                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x\n",
> +                             UART_MCR_RESERVED1);
> +
> +            /* Set modem status */
> +            if ( val & UART_MCR_LOOP )
> +            {
> +                if ( val & UART_MCR_DTR )
> +                    msr_next |= UART_MSR_DSR;
> +                if ( val & UART_MCR_RTS )
> +                    msr_next |= UART_MSR_CTS;
> +                if ( val & UART_MCR_OUT1 )
> +                    msr_next |= UART_MSR_RI;
> +                if ( val & UART_MCR_OUT2 )
> +                    msr_next |= UART_MSR_DCD;
> +            }
> +            else
> +                msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
> +
> +            /* Calculate changes in modem status */
> +            if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> +                msr_delta |= UART_MSR_DCTS;
> +            if ( (msr_curr & UART_MSR_DSR) ^ (msr_next & UART_MSR_DSR) )
> +                msr_delta |= UART_MSR_DDSR;
> +            if ( (msr_curr & UART_MSR_RI)  & (msr_next & UART_MSR_RI) )
> +                msr_delta |= UART_MSR_TERI;

Should this be:

if ( (msr_curr & UART_MSR_RI) && !(msr_next & UART_MSR_RI) )
    msr_delta |= UART_MSR_TERI;

?


> +            if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
> +                msr_delta |= UART_MSR_DDCD;
> +
> +            regs[UART_MCR] = val & UART_MCR_MASK;
> +            regs[UART_MSR] = msr_next | msr_delta;
> +
> +            break;
> +        }



From xen-devel-bounces@lists.xenproject.org Sat Sep 06 01:59:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 01:59:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112963.1461072 (Exim 4.92)
	(envelope-from )
	id 1uuiDL-0001KZ-6U; Sat, 06 Sep 2025 01:59:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112963.1461072; Sat, 06 Sep 2025 01:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuiDL-0001KS-3r; Sat, 06 Sep 2025 01:59:39 +0000
Received: by outflank-mailman (input) for mailman id 1112963;
 Sat, 06 Sep 2025 01: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 1uuiDJ-0001K6-Sq
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 01:59:37 +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 228aa08b-8ac5-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 03:59:35 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 7FF4340235;
 Sat,  6 Sep 2025 01:59:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DA97C4CEF1;
 Sat,  6 Sep 2025 01:59: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: 228aa08b-8ac5-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757123973;
	bh=W2xF6dFNqGHeSkThUdFZmzfdp8upCwIkO04CllFZZ2A=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mESRxTFTHRi8d9duvn7rKdHFxPBDVfXYmbdokhdMGppw8R5syedbXhryvyzJMcq8x
	 plfVYcLyBZwy+ewkOYeXDkWSj+Ixs7h4XGEri338qrZ3dbzb6h9X18mnkjX5mzXmLq
	 jO+Z6Yw5VToOGugPLKx0+p16gagvj9hFq5NK9OSdktV5ouBFclDqsqow6vNJQD8VTa
	 5ALlIyvesfPdifYA1MX/knxvnHauvocyKggXsLVWQlQlwKhx5nKiGQ3RDQ74Wumf+i
	 zpUj/oXc12XC7ylMKhRvJHF0RPJvqpDgS5UwPXVo5L+Gn51Clcngo0SUlduOBM7QV0
	 8tWp/CXFoLXxA==
Date: Fri, 5 Sep 2025 18:59:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 10/15] emul/ns16x50: implement THR register
In-Reply-To: <20250905232715.440758-11-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-11-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add THR register emulation to the I/O port handlder.
> 
> Add TX FIFO management code since THR depends on TX FIFO.
> 
> TX FIFOs is not emulated as per UART specs for simplicity (not need to emulate
> baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
> NS16750 (64 bytes).
> 
> TX FIFOs is emulated by using xencons_interface which conveniently provides
> primitives for buffer management and later can be used for inter-domain
> communication similarly to vpl011.
> 
> Add UART_IIR_THR interrupt reason handling since it depends on THR register
> access.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - new patch
> - Link to v5 (both THR/RBR): https://lore.kernel.org/xen-devel/20250828235409.2835815-7-dmukhin@ford.com/
> ---
>  xen/common/emul/vuart/ns16x50.c | 103 +++++++++++++++++++++++++++++++-
>  1 file changed, 102 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> index cac5128f0573..987d4c06e23b 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -148,6 +148,66 @@ static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
>      return rc;
>  }
>  
> +static bool ns16x50_fifo_tx_full(const struct vuart_ns16x50 *vdev)
> +{
> +    const struct xencons_interface *cons = &vdev->cons;
> +
> +    return cons->out_prod - cons->out_cons == ARRAY_SIZE(cons->out);
> +}
> +
> +static void ns16x50_fifo_tx_reset(struct vuart_ns16x50 *vdev)
> +{
> +    struct xencons_interface *cons = &vdev->cons;
> +
> +    cons->out_cons = cons->out_prod;
> +}
> +
> +/*
> + * Flush cached output to Xen console.
> + */
> +static void ns16x50_fifo_tx_flush(struct vuart_ns16x50 *vdev)
> +{
> +    struct xencons_interface *cons = &vdev->cons;
> +    struct domain *d = vdev->owner;
> +    XENCONS_RING_IDX i, n, len = cons->out_prod - cons->out_cons;
> +
> +    ASSERT(len <= ARRAY_SIZE(cons->out));
> +    if ( !len )
> +        return;
> +
> +    i = MASK_XENCONS_IDX(cons->out_cons, cons->out);
> +    n = min_t(XENCONS_RING_IDX, len, ARRAY_SIZE(cons->out) - i);
> +    if ( n )
> +        guest_printk(d, guest_prefix "%.*s", n, &cons->out[i]);
> +
> +    i = 0;
> +    n = len - n;
> +    if ( n )
> +        guest_printk(d, guest_prefix "%.*s", n, &cons->out[i]);
> +
> +    cons->out_cons += len;
> +}
> +
> +/*
> + * Accumulate guest OS output before sending to Xen console.
> + */
> +static void ns16x50_fifo_tx_putchar(struct vuart_ns16x50 *vdev, char ch)
> +{
> +    struct xencons_interface *cons = &vdev->cons;
> +
> +    if ( !is_console_printable(ch) )
> +        return;
> +
> +    if ( !ns16x50_fifo_tx_full(vdev) )
> +    {
> +        cons->out[MASK_XENCONS_IDX(cons->out_prod, cons->out)] = ch;
> +        cons->out_prod++;
> +    }
> +
> +    if ( ch == '\n' || ch == '\0' || ns16x50_fifo_tx_full(vdev) )
> +        ns16x50_fifo_tx_flush(vdev);
> +}
> +
>  static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
>  {
>      return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
> @@ -165,7 +225,7 @@ static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
>  
>  static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
>  {
> -    return false;
> +    return vdev->regs[NS16X50_REGS_NUM + UART_IIR] & UART_IIR_THR;
>  }
>  
>  static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
> @@ -284,7 +344,31 @@ static int ns16x50_io_write8(
>      {
>          switch ( reg )
>          {
> +        case UART_THR:
> +            if ( regs[UART_MCR] & UART_MCR_LOOP )
> +            {
> +                if ( ns16x50_fifo_rx_putchar(vdev, val) )
> +                    regs[UART_LSR] |= UART_LSR_OE;
> +
> +                regs[UART_LSR] |= UART_LSR_DR;
> +            }
> +            else
> +            {
> +                ns16x50_fifo_tx_putchar(vdev, val);
> +                regs[NS16X50_REGS_NUM + UART_IIR] |= UART_IIR_THR;
> +            }
> +            break;
> +
>          case UART_IER:
> +            /*
> +             * NB: Make sure THR interrupt is re-triggered once guest OS
> +             * re-enables ETHREI in IER since all THR writes are immediate,
> +             * there's no baud rate emulation.
> +             */
> +            if ( val & regs[UART_IER] & UART_IER_ETHREI )
> +                regs[NS16X50_REGS_NUM + UART_IIR] |= UART_IIR_THR;
> +
>              regs[UART_IER] = val & UART_IER_MASK;
>              break;
>  
> @@ -439,6 +523,16 @@ static int ns16x50_io_read8(
>  
>          case UART_IIR: /* RO */
>              val = ns16x50_iir_get(vdev);
> +
> +            /*
> +             * Since there's no baud rate emulation, transmits are immediate
> +             * to the guest. Clear IIR scratch location to make sure there
> +             * will be interrupt generated once guest re-enabled ETHREI in
> +             * IER.
> +             */
> +            if ( val & UART_IIR_THR )
> +                regs[NS16X50_REGS_NUM + UART_IIR] &= ~UART_IIR_THR;

Why clear UART_IIR_THR here?

UART_IIR_THR should be set if the out buffer is not full and should not
be set of the out buffer is full?

Given that the only function adding to out is ns16x50_fifo_tx_putchar,
and given that ns16x50_fifo_tx_putchar clears the out buffer when full
by calling ns16x50_fifo_tx_flush if ns16x50_fifo_tx_full, then basically
we can keep UART_IIR_THR set all the time?


>              break;
>  
>          case UART_LCR:
> @@ -620,6 +714,9 @@ static int ns16x50_init(void *arg)
>      vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & 0xff;
>      vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & 0xff;
>  
> +    /* Report UART is ready to transmit. */
> +    vdev->regs[NS16X50_REGS_NUM + UART_IIR] = UART_IIR_THR;
> +
>      register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
>  
>      spin_lock(&vdev->lock);



From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:02:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:02:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112978.1461082 (Exim 4.92)
	(envelope-from )
	id 1uuiFj-0003NV-NN; Sat, 06 Sep 2025 02:02:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112978.1461082; Sat, 06 Sep 2025 02:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuiFj-0003NO-Jc; Sat, 06 Sep 2025 02:02:07 +0000
Received: by outflank-mailman (input) for mailman id 1112978;
 Sat, 06 Sep 2025 02:02: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 1uuiFi-0003NI-7o
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:02:06 +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 7b0bb0c7-8ac5-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 04:02: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 58A2044829;
 Sat,  6 Sep 2025 02:02:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C881DC4CEF1;
 Sat,  6 Sep 2025 02:02: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: 7b0bb0c7-8ac5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124122;
	bh=7Uqa/pwTHg69/TzQdTBJirXnKmKfaDfOswWNDS97PBU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NlQHCcpmu2UBybR7Zy/4MCbX4mw+8egIWFDZjgR1DNT/1mEG/qXJvr8El2eY1VBt2
	 jLj03pMzDCZab1OlegQ3DQkFWWZGdBYcrDslHBivaN5WCAkbxMzES6LwoNIxE4w3D1
	 ViXiKj0+4PqzptSScT1WujXwS/YYMifGuqyRQvxolFo0hSBunYFgaFEylUQldTyUYg
	 zeoerWu3Xn+vu69YS/23P/Yauen9ceGS6+92Q/17QLs1WFI3e8IhKlyOy7buz8Dhgr
	 6f/SqYFB6bfW7YCqyg3Vmqnx7SX7DnoSTnobukZgfU+P+rO/l75Yo4zcSURj4re0/+
	 g4MGD2hFV01Cw==
Date: Fri, 5 Sep 2025 19:01:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: oleksii.kurochko@gmail.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com, dmukhin@xen.org
Subject: Re: [PATCH v6 00/15] x86: introduce NS16550-compatible UART
 emulator
In-Reply-To: <20250905232715.440758-1-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Oleksii and all,

I would like to consider patches 1-12 of this patch series for 4.21,
pending the few minor comments I made addressed.


On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
> guest OS bring up in the embedded setups.
> 
> This patch series introduces initial in-hypervisor emulator for
> NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.
> 
> In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
> early guest firmware and OS bringup debugging, because it eliminates
> dependency on the external emulator (qemu) being operational by the time
> domains are created.
> 
> The emulator also allows to forward the physical console input to the x86
> domain which is useful when a system has only one physical UART for early
> debugging and this UART is owned by Xen.
> 
> By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O port
> 0x2f8, IRQ#3 in guest OS (legacy COM2). Legacy COM resources cannot be
> selected at built-time or via per-domain xl configuration in this initial
> submission.
> 
> CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities useful
> for NS16550 emulator development/debugging (disabled by default).
> 
> The NS16550 emulator is disabled in default x86 configuration and goes under
> CONFIG_EXPERT in Kconfig.
> 
> Limitations
> ===========
> - Only x86;
> - Only legacy COM2 resources, custom I/O ports/IRQs are not supported;
> - Only Xen console as a backend, no inter-domain communication (similar to
>   vpl011 on Arm);
> - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
> - No toolstack integration;
> - No baud rate emulation (reports 115200 baud to the guest OS);
> - No FIFO-less mode emulation;
> - No RX FIFO interrupt moderation (FCR) emulation;
> - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
>   friends);
> - No MMIO-based UART emulation.
> 
> Series
> ======
> 
>   Patch 1 introduces the new vUART framework, that is the code originally
>   posted here:
>     https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@ford.com/
>   Required for emulator.
> 
>   Patch 2 adds missing NS16550 definitions, required for emulator.
> 
>   Patch 3 introduces the basic emulator skeleton - state machine
>   initialization stubs, I/O port handler stub, logging, etc.
> 
>   Patches 4-11 incrementally populate the minimal NS16550 register emulation.
> 
>   Patch 12 hooks vUART state debugging (disabled by default).
> 
>   Pathes 13-15 introduce necessary changes to enable NS16550 on dom0 (and PVH).
> 
> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2024756493
> Link to branch: https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-ns8250-v6?ref_type=heads
> 
> Testing
> =======
> 
>   ```shell
>   echo CONFIG_EXPERT=y >> .config
>   echo CONFIG_VUART_NS16X50=y >> .config
>   make olddefconfig
>   ```
>   COM2 (0x2f8) resources are used by default.
> 
>   To test w/ virtual COM2, the guest kernel parameters should contain
>   something like the following:
>     earlycon=uart,io,0x2f8,115200n8 console=uart,io,0x2f8,115200n8
> 
>   HVM
>   ---
>   Tested only boot of HVM linux guest with OVMF as the virtual firmware.
>   SeaBIOS as a virtual firmware is not tested.
> 
>   PVH (dom0)
>   ----------
>   Xen is able to forward physical console input to the domain with virtual
>   NS16550. To switch the console focus press Ctrl+aaa.
>   Console switch is limited on x86 to dom0 and Xen (fixes pending).
> 
> Changes since v5:
> - Split THR/RBR into two separate patches.
> - Addressed feedback from v5.
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-1-dmukhin@ford.com/
> 
> Changes since v4:
> - Split the series to make it simpler to review.
> - Addressed feedback from v4.
> - Dropped xl changes, which I will submit separately.
> - Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-1-dmukhin@ford.com/
> 
> Changes since v3:
> - Reduced the blast radius of the series, thanks to reviews, individual
>   aspects (like console focus) touched in v3 moved to separate threads.
> - Kept the UART emulator framework since I need to redo some of emulator code
>   and there's more-or-less agreement on it (where to place, naming, scope).
> - Applied the feedback from
>     https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/
> - Link to v3: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/
> 
> Changes since v2:
> - renamed emulator s/NS8250/NS16550/g
> - reduced the patch series after addressing v2 feedback
> - introduced driver framework for UART emulators
> - unified guest OS printouts across all available UART emulators
> - Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/
> 
> Changes since v1:
> - dropped kmalloc/kfree aliases
> - fixed ECLAIR jobs (thanks Andrew Cooper)
> - addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
> - moved NS8250 debugging stubs into its own patch
> - added fix for https://gitlab.com/xen-project/xen/-/issues/184
> - Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com
> 
> Denis Mukhin (15):
>   emul/vuart: introduce framework for UART emulators
>   xen/8250-uart: update definitions
>   emul/ns16x50: implement emulator stub
>   emul/ns16x50: implement DLL/DLM registers
>   emul/ns16x50: implement SCR register
>   emul/ns16x50: implement IER/IIR registers
>   emul/ns16x50: implement LCR/LSR registers
>   emul/ns16x50: implement MCR/MSR registers
>   emul/ns16x50: implement RBR register
>   emul/ns16x50: implement THR register
>   emul/ns16x50: implement FCR register (write-only)
>   emul/ns16550: implement dump_state() hook
>   x86/domain: enable per-domain I/O port bitmaps
>   xen/domain: allocate d->irq_caps before arch-specific initialization
>   emul/ns16x50: implement IRQ emulation via vIOAPIC
> 
>  xen/arch/arm/xen.lds.S                   |   1 +
>  xen/arch/ppc/xen.lds.S                   |   1 +
>  xen/arch/riscv/xen.lds.S                 |   1 +
>  xen/arch/x86/Makefile                    |   1 +
>  xen/arch/x86/dom0_build.c                | 112 +--
>  xen/arch/x86/hvm/dom0_build.c            |   7 +
>  xen/arch/x86/hvm/hvm.c                   |  56 +-
>  xen/arch/x86/hvm/nestedhvm.c             |   8 +-
>  xen/arch/x86/hvm/quirks.c                |   3 -
>  xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
>  xen/arch/x86/hvm/vioapic.c               |  10 +
>  xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
>  xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
>  xen/arch/x86/include/asm/hvm/support.h   |   2 -
>  xen/arch/x86/include/asm/iocap.h         |   2 +
>  xen/arch/x86/include/asm/irq.h           |   8 +
>  xen/arch/x86/ioport.c                    | 163 ++++
>  xen/arch/x86/irq.c                       |   8 +
>  xen/arch/x86/pv/dom0_build.c             |   7 +
>  xen/arch/x86/xen.lds.S                   |   1 +
>  xen/common/Kconfig                       |   2 +
>  xen/common/Makefile                      |   1 +
>  xen/common/domain.c                      |   8 +-
>  xen/common/emul/Kconfig                  |   6 +
>  xen/common/emul/Makefile                 |   1 +
>  xen/common/emul/vuart/Kconfig            |  25 +
>  xen/common/emul/vuart/Makefile           |   2 +
>  xen/common/emul/vuart/ns16x50.c          | 984 +++++++++++++++++++++++
>  xen/common/emul/vuart/vuart.c            | 157 ++++
>  xen/common/keyhandler.c                  |   3 +
>  xen/drivers/char/console.c               |   6 +-
>  xen/drivers/char/ns16550.c               |  16 +-
>  xen/drivers/passthrough/x86/hvm.c        |  11 +-
>  xen/include/xen/8250-uart.h              |  50 +-
>  xen/include/xen/sched.h                  |   4 +
>  xen/include/xen/serial.h                 |   3 +
>  xen/include/xen/vuart.h                  | 116 +++
>  xen/include/xen/xen.lds.h                |  10 +
>  38 files changed, 1634 insertions(+), 171 deletions(-)
>  create mode 100644 xen/arch/x86/ioport.c
>  create mode 100644 xen/common/emul/Kconfig
>  create mode 100644 xen/common/emul/Makefile
>  create mode 100644 xen/common/emul/vuart/Kconfig
>  create mode 100644 xen/common/emul/vuart/Makefile
>  create mode 100644 xen/common/emul/vuart/ns16x50.c
>  create mode 100644 xen/common/emul/vuart/vuart.c
>  create mode 100644 xen/include/xen/vuart.h
> 
> -- 
> 2.51.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:02:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:02:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112981.1461093 (Exim 4.92)
	(envelope-from )
	id 1uuiG1-0003kK-Un; Sat, 06 Sep 2025 02:02:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112981.1461093; Sat, 06 Sep 2025 02: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 1uuiG1-0003kD-RI; Sat, 06 Sep 2025 02:02:25 +0000
Received: by outflank-mailman (input) for mailman id 1112981;
 Sat, 06 Sep 2025 02:02:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuiG0-0003NI-Dc
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:02:24 +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 86b13ce8-8ac5-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 04:02:22 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 3F25E602AB;
 Sat,  6 Sep 2025 02:02:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A35A1C4CEF4;
 Sat,  6 Sep 2025 02:02:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 86b13ce8-8ac5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124140;
	bh=d6Te6hH8K/CXA2JkttFsqJgILOB9+FPtcTIS+69iQJo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Eej6CrhXDBPKMqCTWAPM7pswhOoX5GlnsVYk+NTn8OIf5Q5swavkpUusDlgfSS4jR
	 wlKoKhRVgnaD9bXbPYVs4wA2pI+mJFqyXIxO4+jIUnwMEdqPyj3DGtpaCPnRCHC6aG
	 T460zn8VXQCYwhECKzsRifW4KCnn06Sy+/kGa4uRw4Jji44Oq07bmdPhVU3/B6dAoZ
	 Cwd5YlHBq+sG6zQMzaUryF8UXpFxUStH5lEkCOXnhU7nxt4r+k264mCEMgnmyiJJO0
	 UwYiN34HaEIhHED6nAMTnKoaj2M65uU56Kd1WkN2UdCOD1JjXE/EBQeV0eMrLxGvss
	 nyfQ/qsERHZpg==
Date: Fri, 5 Sep 2025 19:02:18 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 01/15] emul/vuart: introduce framework for UART
 emulators
In-Reply-To: <20250905232715.440758-2-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-2-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> 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_VUART_FRAMEWORK, which will be
> automatically enabled once the user enables any UART emulator.
> 
> Current implementation supports maximum of one vUART of each kind per domain.
> 
> Use new domain_has_vuart() in the console driver code to check whether to
> forward console input to the domain using vUART.
> 
> Enable console forwarding over vUART for hardware domains with a vUART. That
> enables console forwarding to dom0 on x86, since console can be forwarded only
> to Xen, dom0 and pvshim on x86 as of now.
> 
> Note: existing vUARTs are deliberately *not* hooked to the new framework to
> minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" (i.e.
> minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified.
> 
> No functional changes for non-x86 architectures.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:02:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:02:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1112991.1461103 (Exim 4.92)
	(envelope-from )
	id 1uuiGJ-0004Ey-5y; Sat, 06 Sep 2025 02:02:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1112991.1461103; Sat, 06 Sep 2025 02: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 1uuiGJ-0004Er-2T; Sat, 06 Sep 2025 02:02:43 +0000
Received: by outflank-mailman (input) for mailman id 1112991;
 Sat, 06 Sep 2025 02: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 1uuiGH-0003fo-MH
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:02:41 +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 9139125c-8ac5-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 04:02:40 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 9FDF4446E3;
 Sat,  6 Sep 2025 02:02:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47DAFC4CEF1;
 Sat,  6 Sep 2025 02:02: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: 9139125c-8ac5-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124159;
	bh=Xjv8zsn6t6upPBXo7AwxfEaVReWFjpRaSlleI3E1EXQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=azvZqXiOzP49jRJCYjwoUOYfiFsPNgajY89Mg5bqKLrdNp/5IFUbXGjc7/Ueiwze4
	 uOUzCYYH6Waj9ShgAkZ1VPw+pb9WPnf43LlG/sgZKgZCeseAP5yTxolw6hFBXsZxZw
	 16C5t04OkQrsC7AV+UzRYi/bZELK3WqxwraLfSTXAVASTAIbX8zFnPteUVYtGvj6ED
	 H+q0G3n9OkOsb/tV4/ACDtyLRnyxs74rNbvfLNJ6z6oGtUtz6ZMIJSvRjm1jW3qyl+
	 g4xkaHqqcmbEC2VxkajXz+LZJruIdWtndJ4nyhstUzAjpocK/M765PbiK1FghpGM6s
	 FKGCprhqImFcw==
Date: Fri, 5 Sep 2025 19:02:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 02/15] xen/8250-uart: update definitions
In-Reply-To: <20250905232715.440758-3-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Added missing definitions needed for NS16550 UART emulator.
> 
> Newly introduced MSR definitions re-used in the existing ns16550 driver.
> 
> Also, corrected FCR DMA definition bit#3 (0x08) as per:
>   https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> See "7.7.2 FIFO Control Register (FCR)".
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:03:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113008.1461113 (Exim 4.92)
	(envelope-from )
	id 1uuiH1-0004rH-Dk; Sat, 06 Sep 2025 02:03:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113008.1461113; Sat, 06 Sep 2025 02:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuiH1-0004rA-AM; Sat, 06 Sep 2025 02:03:27 +0000
Received: by outflank-mailman (input) for mailman id 1113008;
 Sat, 06 Sep 2025 02:03: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 1uuiGz-0003NI-EV
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:03:25 +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 aabbf665-8ac5-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 04:03:23 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 5B6B9437B8;
 Sat,  6 Sep 2025 02:03:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1198FC4CEF1;
 Sat,  6 Sep 2025 02:03: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: aabbf665-8ac5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124202;
	bh=/P271jzFbbaiVYtvMFy5+v9ACveQ4+jmMCL1lvvSP6s=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DpZxNR0tMWnTuWsQbx5Zau3OUPf5XvC47s5VY7cfZOlo3bPCuzr70AZXfgKxxT9Ey
	 EMZRHepXbvnaR09HPpfS3WizAj9Z3q1+tgricyMMNWG0qcxWyPGx6AMh/+R2LuVFs+
	 MCBJ6JXU7FfXtnKESLQhDvQJWH6NjzzE+1ih9NtqXlMJVftEh1NXoHyVYcO3QD/2a7
	 ObNNBKC+Ts/btCnZO5hOOHFolsWlM53irwer+t/sBpU6GVDvaVQQZLi/V5UXcJBhIs
	 OMX2Bj6B79yuEbJ4AJKAfEhnudYn/ohDJTIFYeZSpt9tiO/UlFoEND1W0y55DjhXk4
	 s3wHeXN9OX5og==
Date: Fri, 5 Sep 2025 19:03:19 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 03/15] emul/ns16x50: implement emulator stub
In-Reply-To: <20250905232715.440758-4-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> The change is the first on the way on introducing minimally functional
> NS16550-compatible UART emulator.
> 
> Define UART state and a set of emulated registers.
> 
> Implement alloc/free vUART hooks.
> 
> Stub out I/O port handler.
> 
> Add initialization of the NS16x50-compatible UART emulator state machine.
> 
> Plumb debug logging.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - v5 feedback
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-4-dmukhin@ford.com/
> ---
>  xen/arch/x86/hvm/hvm.c          |  21 ++
>  xen/common/emul/vuart/Kconfig   |  19 ++
>  xen/common/emul/vuart/Makefile  |   1 +
>  xen/common/emul/vuart/ns16x50.c | 366 ++++++++++++++++++++++++++++++++
>  4 files changed, 407 insertions(+)
>  create mode 100644 xen/common/emul/vuart/ns16x50.c
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 23bd7f078a1d..91c971f11e14 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -689,6 +690,22 @@ int hvm_domain_initialise(struct domain *d,
>      if ( rc != 0 )
>          goto fail1;
>  
> +    /* Limit NS16550 emulator for dom0 only for now. */
> +    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && is_hardware_domain(d) )
> +    {
> +        struct vuart_info info = {
> +            .name       = "COM2",
> +            .compatible = "ns16550",
> +            .base_addr  = 0x2f8,
> +            .size       = 8,
> +            .irq        = 3,
> +        };
> +
> +        rc = vuart_init(d, &info);
> +        if ( rc )
> +            goto out_vioapic_deinit;
> +    }
> +
>      stdvga_init(d);
>  
>      rtc_init(d);
> @@ -712,6 +729,8 @@ int hvm_domain_initialise(struct domain *d,
>      return 0;
>  
>   fail2:
> +    vuart_deinit(d);
> + out_vioapic_deinit:
>      vioapic_deinit(d);
>   fail1:
>      if ( is_hardware_domain(d) )
> @@ -774,6 +793,8 @@ void hvm_domain_destroy(struct domain *d)
>      if ( hvm_funcs.domain_destroy )
>          alternative_vcall(hvm_funcs.domain_destroy, d);
>  
> +    vuart_deinit(d);
> +
>      vioapic_deinit(d);
>  
>      XFREE(d->arch.hvm.pl_time);
> diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig
> index ce1b976b7da7..a27d7ca135af 100644
> --- a/xen/common/emul/vuart/Kconfig
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -3,4 +3,23 @@ config VUART_FRAMEWORK
>  
>  menu "UART Emulation"
>  
> +config VUART_NS16X50
> +	bool "NS16550-compatible UART Emulator" if EXPERT
> +	depends on X86 && HVM
> +	select VUART_FRAMEWORK
> +	default n
> +	help
> +	  In-hypervisor NS16x50 UART emulation.
> +
> +	  Only legacy PC COM2 port is emulated.
> +
> +	  This is strictly for testing purposes (such as early HVM guest console),
> +	  and not appropriate for use in production.
> +
> +config VUART_NS16X50_DEBUG
> +	bool "NS16550-compatible UART Emulator Debugging"
> +	depends on VUART_NS16X50 && DEBUG
> +	help
> +	  Enable development debugging.

There is a question about adding the kconfig option early in the series.
I think it would be best to add it as last patch


>  endmenu



From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:03:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113011.1461122 (Exim 4.92)
	(envelope-from )
	id 1uuiHD-0005Bc-LF; Sat, 06 Sep 2025 02:03:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113011.1461122; Sat, 06 Sep 2025 02:03: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 1uuiHD-0005BV-IE; Sat, 06 Sep 2025 02:03:39 +0000
Received: by outflank-mailman (input) for mailman id 1113011;
 Sat, 06 Sep 2025 02:03: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 1uuiHC-0003fo-Di
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:03:38 +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 b34e2eed-8ac5-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 04:03:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id D105E602AA;
 Sat,  6 Sep 2025 02:03:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58E80C4CEF1;
 Sat,  6 Sep 2025 02:03: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: b34e2eed-8ac5-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124216;
	bh=u7jvCHtjfqjeHz50dxl7gey5SAHRExQB7ApX8Uwy3yw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=MtFpfAR0mQMCI8jHBRVpeYeUyb1KG4+mjGGlIi2OZ0wzsKIm9M1K1jnzku6VSqWQW
	 voVq77jNEIzjXO6ldpY0JiNCrAsuO3RKjC9v3M2gflxhwKdVFPDe7zlbg02Tx2cAQE
	 szDrDw9so4hfCL26dS2DFHtoU2+vXo+RPACv5ZSHx2yJRspIF6GZnKODXFt2qCrGsr
	 5OEj/K8PLNcH0lpym0CYP9d/rhopfSd0ZWeMqGjNJpZxRCQwisJIKaAZqwC3WHvrBq
	 UzbA7MDyZxxF/GAFJgfGLzXuYH4iy7o1A+wMV+zmMPBWkhQ3a558y7zJ8cPWur+KjZ
	 wrWkln/u3FRkA==
Date: Fri, 5 Sep 2025 19:03:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 04/15] emul/ns16x50: implement DLL/DLM registers
In-Reply-To: <20250905232715.440758-5-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add DLL/DLM registers emulation.
> 
> DLL/DLM registers report hardcoded 115200 baud rate to the guest OS.
> 
> Add stub for ns16x50_dlab_get() helper.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:04:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:04:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113023.1461133 (Exim 4.92)
	(envelope-from )
	id 1uuiI6-0005tT-Tc; Sat, 06 Sep 2025 02:04:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113023.1461133; Sat, 06 Sep 2025 02:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuiI6-0005tM-Qn; Sat, 06 Sep 2025 02:04:34 +0000
Received: by outflank-mailman (input) for mailman id 1113023;
 Sat, 06 Sep 2025 02: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 1uuiI6-0005tC-1J
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:04:34 +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 d3d25beb-8ac5-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 04: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 4EE52602AB;
 Sat,  6 Sep 2025 02:04:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7B34C4CEF1;
 Sat,  6 Sep 2025 02: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: d3d25beb-8ac5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124271;
	bh=MN9iE+ACriliq8eOvUZtL3YrcpXe2K/Fab03rvBg17I=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Q7K8NgFv5rFTjdJbx70j2CeQI2AEYNW97k3CD5+iEhBBLOsT0xE7jMjwgoFrVqb/m
	 9Y6pqz9dQhU6sgj+opo9FpzD7dC/w2eG3HheugGwCvJQlToeoEee5g6xeMvdy0IJtf
	 JZskLSD/9rF7MXL5LVmkDw0mE55D8yar6WrL5VgXtkte6rjkUntfAkfharSIwyG1ek
	 VeFLq76DpsC/fuzHSmUV1tVNLOa09VEPr188Xc68dL9PuJBEn2s76gzXx9Zn5PX6nG
	 1Dbui20XYCvAexB0Jfgro+ETCwBgBrWag9UdmdWx4KMAVf+SVnsmCuuJLKubysy2qJ
	 7+fG/pLotWI1g==
Date: Fri, 5 Sep 2025 19:04:28 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 09/15] emul/ns16x50: implement RBR register
In-Reply-To: <20250905232715.440758-10-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-10-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add RBR register emulation to the I/O port handlder.
> 
> Add RX FIFO management code since RBR depends on RX FIFO.
> 
> RX FIFO is not emulated as per UART specs for simplicity (not need to emulate
> baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
> NS16750 (64 bytes).
> 
> RX FIFO is emulated by means of using xencons_interface which conveniently
> provides primitives for buffer management and later can be used for
> inter-domain communication similarly to vpl011.
> 
> Add UART_LSR_DR handling since it depends on RBR register access.
> 
> Finally, implement put_rx() vUART hook for placing a character into the
> emulated RX FIFO from console driver. That implements physical console
> forwarding to the guest OS over emulated NS16550.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:04:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:04:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113026.1461142 (Exim 4.92)
	(envelope-from )
	id 1uuiIL-0006J0-7x; Sat, 06 Sep 2025 02:04:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113026.1461142; Sat, 06 Sep 2025 02: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 1uuiIL-0006It-5V; Sat, 06 Sep 2025 02:04:49 +0000
Received: by outflank-mailman (input) for mailman id 1113026;
 Sat, 06 Sep 2025 02:04: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 1uuiIK-0005tC-05
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:04:48 +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 dc43226c-8ac5-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 04:04:46 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 6DC82602AA;
 Sat,  6 Sep 2025 02:04:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBA72C4CEF1;
 Sat,  6 Sep 2025 02: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: dc43226c-8ac5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124285;
	bh=z99ETD8Pz6tniWOzx+rgCWKpN5O5JaorEAJ2xal6oi4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lEnIQOrW6MFJygCTXwy5JWQOF42qa4HDL7cvnIUrP7/EExatz3UJryjLRraxbP2Zk
	 RHRmxQmAx6GM7Jtyrt7/6NeRZfrUiFMtc5mXxUZbxktG+SDlDUC6RfF1zc9CIhEcf0
	 3EtK6bruJfrepUZX7Goy0cVoVi9WsAUqB4ARrgggQRIWCu3o9iU/l7MSoBPtpUfEBA
	 mqvW12bmT1hsoiTpyjMz5PYnhCg3ZaEpk1sA99KBxrs53GEHiuzzN27yZ0bFAEq/zH
	 5fclpPqafzQXLE4+yfAb3kaVX9rYMMfdLNVyDg5zDa/LUiwte2lzYYXJlAvnWcNWFI
	 uIFTaGBVCHHTg==
Date: Fri, 5 Sep 2025 19:04:42 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 11/15] emul/ns16x50: implement FCR register
 (write-only)
In-Reply-To: <20250905232715.440758-12-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-12-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add emulation logic for FCR register.
> 
> Note, that does not hook FIFO interrupt moderation to the FIFO management
> code for simplicity.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:10:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:10:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113046.1461152 (Exim 4.92)
	(envelope-from )
	id 1uuiOD-00085g-TH; Sat, 06 Sep 2025 02:10:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113046.1461152; Sat, 06 Sep 2025 02:10: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 1uuiOD-00085Z-Qh; Sat, 06 Sep 2025 02:10:53 +0000
Received: by outflank-mailman (input) for mailman id 1113046;
 Sat, 06 Sep 2025 02:10: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 1uuiHf-0003fo-DZ
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:04:07 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c48ee632-8ac5-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 04:04:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id C3CD4602AA;
 Sat,  6 Sep 2025 02:04:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45D6CC4CEF1;
 Sat,  6 Sep 2025 02:04: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: c48ee632-8ac5-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124245;
	bh=vYQfNKzaebPiy42F94xlB5QfiWEZKOWL7g71nFr4UfM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LHyyKZ8YKN039xNkuDZhN/ncAHzWWWkbbuYVQo74V7y2a+qmWlv90MXK2dGQCBdOH
	 kJaQmN68JeN09Vx3TgCdlc4emmUFmAgH2Wru4O8qmwTuDvkiLC8ICzTWPAUbYZTdcj
	 I/BLC7BInh++Lfrk446wtHsEn9rgIDMA1P06GHRHS0ljvfNFfal/0uvYD6349YGOlX
	 R2e+bzWLamCC/wbWqoJMA0ZqnoGluFYrzeSe5CE8TRhzQEo/JPsz2FB7OquHt53KDD
	 9ZdPW06aoNDUQEiJ70i5oRl1ynHnWJw9L5+sK1PFJ3Y8huahqOhWWETWMbLMRb4NOM
	 o0H3Wa5ubx6KQ==
Date: Fri, 5 Sep 2025 19:04:03 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 07/15] emul/ns16x50: implement LCR/LSR registers
In-Reply-To: <20250905232715.440758-8-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-8-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add LCR/LSR registers implementation to the I/O port handler.
> 
> Add implementation of ns16x50_dlab_get() and ns16x50_iir_check_lsi().
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - Moved earlier in the series so follow on patches (THR/RBR) could make use of
>   LSR bits more naturally
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-9-dmukhin@ford.com/
> ---
>  xen/common/emul/vuart/ns16x50.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> index a7429c84c36e..9d1fe0284362 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -88,12 +88,12 @@ struct vuart_ns16x50 {
>  
>  static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
>  {
> -    return 0;
> +    return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
>  }
>  
>  static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
>  {
> -    return false;
> +    return vdev->regs[UART_LSR] & UART_LSR_MASK;
>  }
>  
>  static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
> @@ -226,11 +226,16 @@ static int ns16x50_io_write8(
>              regs[UART_IER] = val & UART_IER_MASK;
>              break;
>  
> +        case UART_LCR:
> +            regs[UART_LCR] = val;
> +            break;
> +
>          /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
>          case UART_SCR:
>              regs[UART_SCR] = val;
>              break;
>  
> +        case UART_LSR: /* RO */
>          default:
>              rc = -EINVAL;
>              break;
> @@ -312,6 +317,15 @@ static int ns16x50_io_read8(
>              val = ns16x50_iir_get(vdev);
>              break;
>  
> +        case UART_LCR:
> +            val = regs[UART_LCR];
> +            break;
> +
> +        case UART_LSR:
> +            val = regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
> +            regs[UART_LSR] = val & ~UART_LSR_MASK;
> +            break;
> +
>          case UART_SCR:
>              val = regs[UART_SCR];
>              break;
> -- 
> 2.51.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 02:11:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 02:11:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113058.1461163 (Exim 4.92)
	(envelope-from )
	id 1uuiOa-0000HI-5E; Sat, 06 Sep 2025 02:11:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113058.1461163; Sat, 06 Sep 2025 02: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 1uuiOa-0000HA-2f; Sat, 06 Sep 2025 02:11:16 +0000
Received: by outflank-mailman (input) for mailman id 1113058;
 Sat, 06 Sep 2025 02:11:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuiHT-0003fo-BX
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 02:03:55 +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 bcd926c6-8ac5-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 04:03: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 D2B3B602AA;
 Sat,  6 Sep 2025 02:03:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 333AAC4CEF1;
 Sat,  6 Sep 2025 02:03: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: bcd926c6-8ac5-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757124232;
	bh=Oc6nLx3LZyJ3Vgd1+j9sMVOJun+AvB2Kh2JB/3vy/wc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bVKIRc8M8FZpG+Y4ZTLH2SNQRZTstSnRHNo6jvqsYVrJ3+1BUwY1mXu8Wug1dmHlr
	 27qRobkrwzollhPQJKnmvUXARQ+Nb9vRGREz8NA5XR8nPr8XIyCjGSnn8OwkkUpgX+
	 Ck9Hjy//LJACc5ZK6hx8Gli2fGouCaVA7k6sHGhN9S0KfqcqkoLYGynQW23lC7AqIZ
	 BlYix/gvgidO1/xnPUxQtjPVi3Mc60OD2Oh/TCzmah0CJLfmUiEgffK5cuHeKipxr1
	 ho7sYZ8irXFDyt+YfY0pib/LVpyaeusQj07qDAfDVjtu9rGJ15Rl0pL6iGwCAL3rNo
	 8EtHzTzTC9/1A==
Date: Fri, 5 Sep 2025 19:03:49 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
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 05/15] emul/ns16x50: implement SCR register
In-Reply-To: <20250905232715.440758-6-dmukhin@ford.com>
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-6-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, 5 Sep 2025, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add SCR register emulation to the I/O port handler.
> Firmware (e.g. OVMF) may use SCR during the guest OS boot.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 04:18:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 04:18:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113115.1461173 (Exim 4.92)
	(envelope-from )
	id 1uukNa-0006aZ-R2; Sat, 06 Sep 2025 04:18:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113115.1461173; Sat, 06 Sep 2025 04: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 1uukNa-0006aS-NS; Sat, 06 Sep 2025 04:18:22 +0000
Received: by outflank-mailman (input) for mailman id 1113115;
 Sat, 06 Sep 2025 04:18:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uukNZ-0006aM-7j
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 04:18:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uukNX-009RfV-1W;
 Sat, 06 Sep 2025 04:18:19 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uukNX-000JQ0-1C;
 Sat, 06 Sep 2025 04:18: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=FFHTHv+ciDFyK8pkM0/CoPbfpYr0LBC0kpQLqatYuNY=; b=
	IWrlr0MQLmmD2KYQ1A6qbR23VAIodfM7Uj5HvGz9JofSIuUd9I00XnxebQf0RSdIYqHS9uuVjKu2V
	C7FUaI2F1uCRnrn6jFyhXc0MFpPGD2Q2v8GKYSSKNnzp1BYzCVHpninw6gjUuMFX1t26diguZMjB3
	a7pXMgEPqFgWTzfXc=;
From: dmukhin@xen.org
Date: Fri, 5 Sep 2025 21:18:18 -0700
To: Stefano Stabellini 
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 v6 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-4-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 05, 2025 at 07:03:19PM -0700, Stefano Stabellini wrote:
> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
[..]
> > --- a/xen/common/emul/vuart/Kconfig
> > +++ b/xen/common/emul/vuart/Kconfig
> > @@ -3,4 +3,23 @@ config VUART_FRAMEWORK
> >  
> >  menu "UART Emulation"
> >  
> > +config VUART_NS16X50
> > +	bool "NS16550-compatible UART Emulator" if EXPERT
> > +	depends on X86 && HVM
> > +	select VUART_FRAMEWORK
> > +	default n
> > +	help
> > +	  In-hypervisor NS16x50 UART emulation.
> > +
> > +	  Only legacy PC COM2 port is emulated.
> > +
> > +	  This is strictly for testing purposes (such as early HVM guest console),
> > +	  and not appropriate for use in production.
> > +
> > +config VUART_NS16X50_DEBUG
> > +	bool "NS16550-compatible UART Emulator Debugging"
> > +	depends on VUART_NS16X50 && DEBUG
> > +	help
> > +	  Enable development debugging.
> 
> There is a question about adding the kconfig option early in the series.
> I think it would be best to add it as last patch

Will do.


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 09:43:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 09:43:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113245.1461183 (Exim 4.92)
	(envelope-from )
	id 1uupS1-0001nS-AI; Sat, 06 Sep 2025 09:43:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113245.1461183; Sat, 06 Sep 2025 09: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 1uupS1-0001nG-4P; Sat, 06 Sep 2025 09:43:17 +0000
Received: by outflank-mailman (input) for mailman id 1113245;
 Sat, 06 Sep 2025 09: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 1uupRz-0001nA-Hj
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 09:43:15 +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 e844744b-8b05-11f0-9d12-b5c5bf9af7f9;
 Sat, 06 Sep 2025 11:43:13 +0200 (CEST)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-336bbcebca9so22143291fa.1
 for ; Sat, 06 Sep 2025 02:43: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: e844744b-8b05-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757151793; x=1757756593; 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=v+Zc1u3wNGutrzluMMDe2HzAOEZk9VtUjtw4Tciae38=;
        b=AN/JVtRZ5Sou4E/My1Cm6U4l7zh6CGfXmARL9t0q/8M75lP/GwAsq40I/7YV2Lk5/2
         h6o7K37TupwK9BgOM0TcampCj9IgDHt0LEIqYfkywXQ/mTeK9v08PhaN+nY6ccTfOOWz
         MgKeY8ukorfzN8N/a+5Y0np7w0o72mwkfbmOzdTJ3aloNupDI7/0/UtmeJGu9QFl1bZy
         ODrAlWM3orXSgX/sLiJojmaYuhd4r+gi/QxJhiQOU1XkNJy7/L2G0jCFuV9D0/vRngFL
         +Bvt39ft0gRH7BnX0M+9y4qzpjZJ/P6ICL958cRY7kNUFm6qNZfeIwcvm+fWsZskw3yh
         v+dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757151793; x=1757756593;
        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=v+Zc1u3wNGutrzluMMDe2HzAOEZk9VtUjtw4Tciae38=;
        b=Al9b8tCn/t7N6bZL2oqbiswBKXYX3eX4M/2K8wEdkNbXvfOnAqvT/0h5FsW6iu/gNk
         X1PXbrE7SKyPrMvA0fDDzkw8vrSDp72AyaTL8+VOFn/SNy7zlhhsMsgf++3408fUM8HN
         +pkGMQfG6ecMMhUmk8s/4CYkbWtZcN0unN5EkU+Nw6+OGEOOh20TMswTiJfkUrCVM48E
         b2Wo0PAQRuSuNkEGvXhAcBs1dRGgrrzhnqiftnvmpgWu2YMzoP5Ys7gbpDagQefReFjL
         oWmN2AWhd6WtdPAPwrMWST3Q4BUzj1u4goNskdMWGh4QR8zpd/7EBdHIj2YU7ZU9UnoC
         YqPA==
X-Gm-Message-State: AOJu0YwHEAyi6pDXiLVlqvoStL/q5SmzomAL258PfHo5DDx3z3OQPNkC
	GgjDG1YQKCAU/Eiqmj1klM8hLpmy2+2TUxLphVuYDnLbyhOEbHWKOHABFpq7E6C6At7hAde5j8w
	5S01Jcpy8yhbARM72KdZULSSNfYMTL9s=
X-Gm-Gg: ASbGncuMO23ExnGnJ/aJ2T+X2Jxrb9+UUXvLHXezHMo/5gLHCNS9jv9BrBExYYb0hRO
	QI0cS2aAXiwj5HmKWFkFaLSFiLzw8aV3blhwrvFoQvdwdY3eVqsUCjm6vLQ+oDSgO3E7ktpQqyr
	sZKYzs5OsdjSAhSDbfaadU748Je6Q7SxdwqwHg4VLWbYYM8xXUoyVFWTO9gGwcLnwlx7YSKvLDu
	BY4Vz7DLFHzI/3W
X-Google-Smtp-Source: AGHT+IEj8ZS0bnC7ShiMi5ftpWknGhpGlWtjdT+iNb1i0z9s4gykyOVa0IfAH8pxiraG0nxoVKyycN8YhCeoE7RzI4M=
X-Received: by 2002:a05:651c:1548:b0:338:1286:bc77 with SMTP id
 38308e7fff4ca-33b59e16fa3mr3844491fa.42.1757151792761; Sat, 06 Sep 2025
 02:43:12 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-2-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-2-dmukhin@ford.com>
From: Mykola Kvach 
Date: Sat, 6 Sep 2025 12:43:01 +0300
X-Gm-Features: Ac12FXwY9U_CFxU36zATL1J0dnUQ1tT21Drj94ZFsAkPA-GNK7ogl98TYjOnSQ4
Message-ID: 
Subject: Re: [PATCH v6 01/15] emul/vuart: introduce framework for UART emulators
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Sat, Sep 6, 2025 at 2:27=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> 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_VUART_FRAMEWORK, which will be
> automatically enabled once the user enables any UART emulator.
>
> Current implementation supports maximum of one vUART of each kind per dom=
ain.
>
> Use new domain_has_vuart() in the console driver code to check whether to
> forward console input to the domain using vUART.
>
> Enable console forwarding over vUART for hardware domains with a vUART. T=
hat
> enables console forwarding to dom0 on x86, since console can be forwarded=
 only
> to Xen, dom0 and pvshim on x86 as of now.
>
> Note: existing vUARTs are deliberately *not* hooked to the new framework =
to
> minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" =
(i.e.
> minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified.
>
> No functional changes for non-x86 architectures.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - addressed v5 feedback
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-2-=
dmukhin@ford.com/
> ---
>  xen/arch/arm/xen.lds.S         |   1 +
>  xen/arch/ppc/xen.lds.S         |   1 +
>  xen/arch/riscv/xen.lds.S       |   1 +
>  xen/arch/x86/xen.lds.S         |   1 +
>  xen/common/Kconfig             |   2 +
>  xen/common/Makefile            |   1 +
>  xen/common/emul/Kconfig        |   6 ++
>  xen/common/emul/Makefile       |   1 +
>  xen/common/emul/vuart/Kconfig  |   6 ++
>  xen/common/emul/vuart/Makefile |   1 +
>  xen/common/emul/vuart/vuart.c  | 157 +++++++++++++++++++++++++++++++++
>  xen/common/keyhandler.c        |   3 +
>  xen/drivers/char/console.c     |   6 +-
>  xen/include/xen/sched.h        |   4 +
>  xen/include/xen/serial.h       |   3 +
>  xen/include/xen/vuart.h        | 116 ++++++++++++++++++++++++
>  xen/include/xen/xen.lds.h      |  10 +++
>  17 files changed, 319 insertions(+), 1 deletion(-)
>  create mode 100644 xen/common/emul/Kconfig
>  create mode 100644 xen/common/emul/Makefile
>  create mode 100644 xen/common/emul/vuart/Kconfig
>  create mode 100644 xen/common/emul/vuart/Makefile
>  create mode 100644 xen/common/emul/vuart/vuart.c
>  create mode 100644 xen/include/xen/vuart.h
>
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index db17ff1efa98..cd05b18770f4 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -58,6 +58,7 @@ SECTIONS
>         *(.rodata)
>         *(.rodata.*)
>         VPCI_ARRAY
> +       VUART_ARRAY
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
>
> diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
> index 1de0b77fc6b9..f9d4e5b0dcd8 100644
> --- a/xen/arch/ppc/xen.lds.S
> +++ b/xen/arch/ppc/xen.lds.S
> @@ -52,6 +52,7 @@ SECTIONS
>          *(.rodata)
>          *(.rodata.*)
>          VPCI_ARRAY
> +        VUART_ARRAY
>          *(.data.rel.ro)
>          *(.data.rel.ro.*)
>
> diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
> index edcadff90bfe..59dcaa5fef9a 100644
> --- a/xen/arch/riscv/xen.lds.S
> +++ b/xen/arch/riscv/xen.lds.S
> @@ -47,6 +47,7 @@ SECTIONS
>          *(.rodata)
>          *(.rodata.*)
>          VPCI_ARRAY
> +        VUART_ARRAY
>          *(.data.rel.ro)
>          *(.data.rel.ro.*)
>
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 966e514f2034..d877b93a6964 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -132,6 +132,7 @@ SECTIONS
>         *(.rodata)
>         *(.rodata.*)
>         VPCI_ARRAY
> +       VUART_ARRAY
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 76f9ce705f7a..78a32b69e2b2 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -676,4 +676,6 @@ config PM_STATS
>           Enable collection of performance management statistics to aid i=
n
>           analyzing and tuning power/performance characteristics of the s=
ystem
>
> +source "common/emul/Kconfig"
> +
>  endmenu
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 0c7d0f5d46e1..8c8462565050 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) +=3D device-tree/
>  obj-$(CONFIG_IOREQ_SERVER) +=3D dm.o
>  obj-y +=3D domain.o
>  obj-y +=3D domid.o
> +obj-y +=3D emul/
>  obj-y +=3D event_2l.o
>  obj-y +=3D event_channel.o
>  obj-$(CONFIG_EVTCHN_FIFO) +=3D event_fifo.o
> diff --git a/xen/common/emul/Kconfig b/xen/common/emul/Kconfig
> new file mode 100644
> index 000000000000..7c6764d1756b
> --- /dev/null
> +++ b/xen/common/emul/Kconfig
> @@ -0,0 +1,6 @@
> +menu "Domain Emulation Features"
> +       visible if EXPERT
> +
> +source "common/emul/vuart/Kconfig"
> +
> +endmenu
> diff --git a/xen/common/emul/Makefile b/xen/common/emul/Makefile
> new file mode 100644
> index 000000000000..ae0b575c3901
> --- /dev/null
> +++ b/xen/common/emul/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VUART_FRAMEWORK) +=3D vuart/
> diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfi=
g
> new file mode 100644
> index 000000000000..ce1b976b7da7
> --- /dev/null
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -0,0 +1,6 @@
> +config VUART_FRAMEWORK
> +       bool
> +
> +menu "UART Emulation"
> +
> +endmenu
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> new file mode 100644
> index 000000000000..97f792dc6641
> --- /dev/null
> +++ b/xen/common/emul/vuart/Makefile
> @@ -0,0 +1 @@
> +obj-y +=3D vuart.o
> diff --git a/xen/common/emul/vuart/vuart.c b/xen/common/emul/vuart/vuart.=
c
> new file mode 100644
> index 000000000000..3dfcba217248
> --- /dev/null
> +++ b/xen/common/emul/vuart/vuart.c
> @@ -0,0 +1,157 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UART emulator framework.
> + *
> + * Copyright 2025 Ford Motor Company
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define for_each_emulator(e) \
> +    for ( e =3D vuart_array_start; e < vuart_array_end; e++ )
> +
> +extern const struct vuart_emulator vuart_array_start[];
> +extern const struct vuart_emulator vuart_array_end[];
> +
> +static const struct vuart_emulator *
> +vuart_match_by_compatible(const struct domain *d, const char *compat)
> +{
> +    const struct vuart_emulator *emulator;
> +
> +    for_each_emulator(emulator)
> +        if ( emulator->compatible &&
> +             !strncmp(compat, emulator->compatible,
> +                      strlen(emulator->compatible)) )
> +            return emulator;
> +
> +    return NULL;
> +}
> +
> +const static struct vuart *
> +vuart_find_by_console_permission(const struct domain *d)

Other functions that search for a console (e.g., by compatible string or IO
range) take an argument to specify what to search by. Here,
vuart_find_by_console_permission takes no argument and just checks a single
flag. It might be clearer to either add a flags argument to make it general=
,
or rename the function to reflect that it checks only this one permission f=
lag.

> +{
> +    const struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( !vuart || !vuart->emulator || !vuart->emulator->put_rx ||

Looking at vuart_init, vuart->emulator is always set when vuart is valid.
So the vuart->emulator check seems redundant.

If it is truly needed, the same check should also appear in
vuart_dump_state and vuart_deinit. Otherwise, for consistency we
could safely assume vuart->emulator is non-NULL after vuart_init.

> +         !(vuart->flags & VUART_CONSOLE_INPUT))
> +        return NULL;
> +
> +    return vuart;
> +}
> +
> +struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long add=
r,
> +                                     unsigned long size)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( !vuart || !vuart->info )

Is it possible to have a valid vuart pointer without a valid info pointer?

> +        return NULL;
> +
> +    if ( addr >=3D vuart->info->base_addr &&
> +         addr + size - 1 <=3D vuart->info->base_addr + vuart->info->size=
 - 1 )
> +        return vuart;
> +
> +    return NULL;
> +}
> +
> +int vuart_init(struct domain *d, struct vuart_info *info)
> +{
> +    const struct vuart_emulator *emulator;
> +    struct vuart *vuart;
> +    int rc;
> +
> +    if ( d->console.vuart )
> +        return -EBUSY;
> +
> +    emulator =3D vuart_match_by_compatible(d, info->compatible);
> +    if ( !emulator )
> +        return -ENODEV;
> +
> +    vuart =3D xzalloc(typeof(*vuart));
> +    if ( !vuart )
> +        return -ENOMEM;
> +
> +    vuart->info =3D xvzalloc(typeof(*info));
> +    if ( !vuart->info )
> +    {
> +        rc =3D -ENOMEM;
> +        goto err_out;
> +    }
> +    memcpy(vuart->info, info, sizeof(*info));
> +
> +    vuart->vdev =3D emulator->alloc(d, vuart->info);
> +    if ( IS_ERR(vuart->vdev) )
> +    {
> +        rc =3D PTR_ERR(vuart->vdev);
> +        goto err_out;
> +    }
> +
> +    vuart->emulator =3D emulator;
> +    vuart->owner =3D d;
> +    vuart->flags |=3D VUART_CONSOLE_INPUT;
> +
> +    d->console.input_allowed =3D true;
> +    d->console.vuart =3D vuart;
> +
> +    return 0;
> +
> + err_out:
> +    if ( vuart )

As far as I can see, it isn=E2=80=99t possible to reach this point when vua=
rt
is NULL. The err_out label is only jumped to after vuart has been
successfully allocated, so the check if (vuart) is redundant.

> +        xvfree(vuart->info);
> +    xvfree(vuart);
> +
> +    return rc;
> +}
> +
> +/*
> + * Release any resources taken by UART emulators.
> + *
> + * NB: no flags are cleared, since currently exit() is called only durin=
g
> + * domain destroy.
> + */
> +void vuart_deinit(struct domain *d)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart )
> +    {
> +        vuart->emulator->free(vuart->vdev);
> +        xvfree(vuart->info);
> +    }
> +    XVFREE(d->console.vuart);
> +}
> +
> +void vuart_dump_state(const struct domain *d)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart )
> +        vuart->emulator->dump_state(vuart->vdev);
> +}
> +
> +/*
> + * Put character to the *first* suitable emulated UART's FIFO.
> + */

This comment could be a single line since it doesn=E2=80=99t exceed 80 char=
acters.

> +int vuart_put_rx(struct domain *d, char c)
> +{
> +    const struct vuart *vuart =3D vuart_find_by_console_permission(d);

If vuart_deinit has already been called, is it possible that vuart
points to freed memory here or in other places?

Should we add reference counting or locks to protect against such
use-after-free, or are we relying on higher-level mechanisms to
guarantee that these structs aren=E2=80=99t freed while vuart is accessed?

Should we also check whether the domain is currently being
destroyed and avoid putting new characters into the emulated UART
in that case?

If we are relying on some upper-level mechanism, I think it deserves a
comment somewhere to make that guarantee explicit.

> +
> +    return vuart ? vuart->emulator->put_rx(vuart->vdev, c) : -ENODEV;
> +}
> +
> +bool domain_has_vuart(const struct domain *d)
> +{
> +    return vuart_find_by_console_permission(d);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index cb6df2823b00..156e64d9eb58 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  static unsigned char keypress_key;
> @@ -352,6 +353,8 @@ static void cf_check dump_domains(unsigned char key)
>                             v->periodic_period / 1000000);
>              }
>          }
> +
> +        vuart_dump_state(d);
>      }
>
>      for_each_domain ( d )
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9bd5b4825da6..d5164897a776 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_X86
>  #include 
> @@ -596,11 +597,12 @@ static void __serial_rx(char c)
>      if ( !d )
>          return;
>
> -    if ( is_hardware_domain(d) )
> +    if ( is_hardware_domain(d) && !domain_has_vuart(d) )
>      {
>          /*
>           * Deliver input to the hardware domain buffer, unless it is
>           * already full.
> +         * NB: must be the first check: hardware domain may have emulate=
d UART.
>           */
>          if ( (serial_rx_prod - serial_rx_cons) !=3D SERIAL_RX_SIZE )
>              serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] =3D c;
> @@ -611,6 +613,8 @@ static void __serial_rx(char c)
>           */
>          send_global_virq(VIRQ_CONSOLE);
>      }
> +    else if ( domain_has_vuart(d) )
> +        rc =3D vuart_put_rx(d, c);
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
>      else
>          /* Deliver input to the emulated UART. */
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 02bdc256ce37..613f4596e33d 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -660,6 +661,9 @@ struct domain
>      struct {
>          /* Permission to take ownership of the physical console input. *=
/
>          bool input_allowed;
> +#ifdef CONFIG_VUART_FRAMEWORK
> +        struct vuart *vuart;
> +#endif
>      } console;
>  } __aligned(PAGE_SIZE);
>
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 8e1844555208..123eee67df35 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -36,6 +36,9 @@ struct vuart_info {
>      unsigned long data_off;     /* Data register offset */
>      unsigned long status_off;   /* Status register offset */
>      unsigned long status;       /* Ready status value */
> +    unsigned int irq;           /* Interrupt */
> +    char compatible[16];        /* Compatible string */
> +    char name[16];              /* User-friendly name */
>  };
>
>  struct serial_port {
> diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
> new file mode 100644
> index 000000000000..54f2f29f3f4a
> --- /dev/null
> +++ b/xen/include/xen/vuart.h
> @@ -0,0 +1,116 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UART emulator framework.
> + *
> + * Copyright 2025 Ford Motor Company
> + */
> +
> +#ifndef XEN_VUART_H
> +#define XEN_VUART_H
> +
> +#include 
> +#include 
> +
> +struct vuart_emulator;
> +
> +enum {
> +    VUART_CONSOLE_INPUT =3D BIT(0, U), /* Physical console input forward=
ing. */
> +};
> +
> +
> +/*
> + * FIXME: #ifdef is temporary to avoid clash with
> + *   arch/arm/include/asm/domain.h
> + */
> +#ifdef CONFIG_VUART_FRAMEWORK
> +struct vuart {
> +    const struct vuart_emulator *emulator;
> +    struct vuart_info *info;
> +    struct domain *owner;
> +    uint32_t flags;
> +    void *vdev;
> +};
> +#endif
> +
> +struct vuart_emulator {
> +    /* UART compatible string. Cannot be NULL or empty. */
> +    const char *compatible;
> +
> +    /*
> +     * Allocate emulated UART state (RX/TX FIFOs, locks, initialize regi=
sters,
> +     * hook I/O handlers, etc.)
> +     * Cannot be NULL.
> +     */
> +    void *(*alloc)(struct domain *d, const struct vuart_info *info);
> +
> +    /*
> +     * Release resources used to emulate UART state (flush RX/TX FIFOs, =
unhook
> +     * I/O handlers, etc.).
> +     * Cannot be NULL.
> +     */
> +    void (*free)(void *arg);
> +
> +    /*
> +     * Print emulated UART state, including registers, on the console.
> +     * Can be NULL.
> +     */
> +    void (*dump_state)(void *arg);
> +
> +    /*
> +     * Place character to the emulated RX FIFO.
> +     * Used to forward physical console input to the guest OS.
> +     * Can be NULL.
> +     */
> +    int (*put_rx)(void *arg, char c);
> +};
> +
> +#define VUART_REGISTER(name, x) \
> +    static const struct vuart_emulator name##_entry \
> +        __used_section(".data.rel.ro.vuart") =3D x
> +
> +struct vuart *vuart_find_by_io_range(struct domain *d,
> +                                     unsigned long base_addr,
> +                                     unsigned long size);
> +
> +int vuart_put_rx(struct domain *d, char c);
> +
> +#ifdef CONFIG_VUART_FRAMEWORK
> +
> +int vuart_init(struct domain *d, struct vuart_info *info);
> +void vuart_deinit(struct domain *d);
> +void vuart_dump_state(const struct domain *d);
> +bool domain_has_vuart(const struct domain *d);
> +
> +#else
> +
> +static inline int vuart_init(struct domain *d, struct vuart_info *info)
> +{
> +    return 0;
> +}
> +
> +static inline void vuart_deinit(struct domain *d)
> +{
> +}
> +
> +static inline void vuart_dump_state(const struct domain *d)
> +{
> +}
> +
> +static inline bool domain_has_vuart(const struct domain *d)
> +{
> +    return false;
> +}
> +
> +#endif /* CONFIG_VUART_FRAMEWORK */
> +
> +#endif /* XEN_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/xen.lds.h b/xen/include/xen/xen.lds.h
> index b126dfe88792..2d65f32ddad3 100644
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -194,4 +194,14 @@
>  #define VPCI_ARRAY
>  #endif
>
> +#ifdef CONFIG_VUART_FRAMEWORK
> +#define VUART_ARRAY              \
> +       . =3D ALIGN(POINTER_ALIGN); \
> +       vuart_array_start =3D .;    \
> +       *(.data.rel.ro.vuart)     \
> +       vuart_array_end =3D .;
> +#else
> +#define VUART_ARRAY
> +#endif
> +
>  #endif /* __XEN_LDS_H__ */
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 14:57:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 14:57:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113388.1461213 (Exim 4.92)
	(envelope-from )
	id 1uuuLt-000365-Qz; Sat, 06 Sep 2025 14:57:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113388.1461213; Sat, 06 Sep 2025 14:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uuuLt-00035x-MB; Sat, 06 Sep 2025 14:57:17 +0000
Received: by outflank-mailman (input) for mailman id 1113388;
 Sat, 06 Sep 2025 14: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 1uuuLt-00035r-50
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 14:57:17 +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 c628eb1a-8b31-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 16:57:14 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-5607c2f1598so3169386e87.3
 for ; Sat, 06 Sep 2025 07:57: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: c628eb1a-8b31-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757170634; x=1757775434; 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=rlTtPpR8RMUC4GLRdCF17L/D6D1eCOR6eggI+Sb6QQo=;
        b=mpHV1dNmOAx2k9vApy3NU17BWy+sif21oA/xS0gCa77WxoWj7S0/Cc/2zxhBH+Iz02
         amwslk7ACGFGo228fmqLBHILsnad5ycvKzbGMAfGjhwULTNCztjCw5o2MHxJpaps8+PP
         EAx5hA4W4OP3ACIZA+930gZVUqomUigJC49mq/QwRQ3KuHcI+VPKQ2lGZGMXJJd8dfrU
         1pX/h7juBUAPem8IV0FDCK8w0IB2NxsTE1y9y7teYj4SbvkwaLh7QTXWrAxys9WS3PPS
         rf0n9WYvqBtx2Qd61/pe2e/tbiX4Zyaebp31kYxDaef9YUqzZ8wyOrc56VOZsPPwujvN
         WxpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757170634; x=1757775434;
        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=rlTtPpR8RMUC4GLRdCF17L/D6D1eCOR6eggI+Sb6QQo=;
        b=f4eMinzNrAXx7N0Dq5efJfgHGsYFkagVKwQ4No9uSV/e0dfxvSvT06/Vb794okWIcZ
         4Jjz6osmCMnrJBSmrwinSiYjhIv7mA9avWp3JE9XE4un0MGZdrRYYyJIDLXfUwVpWiP0
         xYps+NrM/JS2WqsB8EhxdGETnZpWE1BbJhmzDrgRkwj12RNrkX6I3DyffE+bHOzIkKBA
         2tJ2xiL1H8Q9fF9OYeq/Zs7w6UVIi2SZTt1JOUPcEYEVKxXrLyKUrNedDifkd8UxmwHz
         q2UNcX/VhA+tXFyoTYU7jsE68fZmWy28PD9lAH4ObLfRadx0SfH0SuIjdIYouyuZTFES
         qoUA==
X-Gm-Message-State: AOJu0YwNJpt4tVJGMY1kZQ1ENwzOx1engqI/r5h6xXICu5aRcoFMFjcQ
	9tYpawq9VchxWPEa7+GBcUojoHfOnFbgGV/Tt+drKrsnhxwpot2sy8hmPtPfW/VjPntOgf/Odxs
	GacFN0wyfk1jEHkuRDGuCxOzOTYtfYhI=
X-Gm-Gg: ASbGncuKCZcnNgO4Sl3i+E56NNKy4LJT5ED9gL08iqorTf/D6Ah6AwQ4neBLNo0Iitv
	dyTzr2lUbJ3P1eSFpSFed1IYawpKN//8x5HpVfhbycvcJMRsdWVzWIXAqtmxTHt00XCxQ+9FEgH
	RoA+q6snnE/07GdXSVCqCjEoYemKAYQd7Rugb9a6htIaf/9Zy3RPadW/O07MnxxMgNbMiqdLfiG
	CBA98reRuEvO8LW
X-Google-Smtp-Source: AGHT+IGhDVdgvLzKa2HyBz0qq5oOFERCsLsXvgi6NDVo2FuFblqT8roa9JrD++8b/B6RJ6B7rN23IvKeoPLzH1gGegs=
X-Received: by 2002:a05:6512:2c94:b0:55f:5f7e:9ba8 with SMTP id
 2adb3069b0e04-56260e42a9bmr751287e87.31.1757170633509; Sat, 06 Sep 2025
 07:57:13 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-3-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-3-dmukhin@ford.com>
From: Mykola Kvach 
Date: Sat, 6 Sep 2025 17:57:02 +0300
X-Gm-Features: Ac12FXyc8lz7iWirGMSYGarP0BTW1dpBGjMlRbLpsTyjpI_JlGf_ZMxMzTGeWu0
Message-ID: 
Subject: Re: [PATCH v6 02/15] xen/8250-uart: update definitions
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Sat, Sep 6, 2025 at 2:27=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Added missing definitions needed for NS16550 UART emulator.
>
> Newly introduced MSR definitions re-used in the existing ns16550 driver.
>
> Also, corrected FCR DMA definition bit#3 (0x08) as per:
>   https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> See "7.7.2 FIFO Control Register (FCR)".
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - fixed commentaries
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-3-=
dmukhin@ford.com/
> ---
>  xen/drivers/char/ns16550.c  | 16 ++++++------
>  xen/include/xen/8250-uart.h | 50 ++++++++++++++++++++++++++++++-------
>  2 files changed, 49 insertions(+), 17 deletions(-)
>
> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
> index df7fff7f81df..0e80fadbb894 100644
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -388,7 +388,7 @@ static void __init cf_check ns16550_init_preirq(struc=
t serial_port *port)
>
>      /* Check this really is a 16550+. Otherwise we have no FIFOs. */
>      if ( uart->fifo_size <=3D 1 &&
> -         ((ns_read_reg(uart, UART_IIR) & 0xc0) =3D=3D 0xc0) &&
> +         ((ns_read_reg(uart, UART_IIR) & UART_IIR_FE) =3D=3D UART_IIR_FE=
) &&
>           ((ns_read_reg(uart, UART_FCR) & UART_FCR_TRG14) =3D=3D UART_FCR=
_TRG14) )
>          uart->fifo_size =3D 16;
>  }
> @@ -728,20 +728,20 @@ static int __init check_existence(struct ns16550 *u=
art)
>       * Mask out IER[7:4] bits for test as some UARTs (e.g. TL
>       * 16C754B) allow only to modify them if an EFR bit is set.
>       */
> -    scratch2 =3D ns_read_reg(uart, UART_IER) & 0x0f;
> -    ns_write_reg(uart,UART_IER, 0x0F);
> -    scratch3 =3D ns_read_reg(uart, UART_IER) & 0x0f;
> +    scratch2 =3D ns_read_reg(uart, UART_IER) & UART_IER_MASK;
> +    ns_write_reg(uart, UART_IER, UART_IER_MASK);
> +    scratch3 =3D ns_read_reg(uart, UART_IER) & UART_IER_MASK;
>      ns_write_reg(uart, UART_IER, scratch);
> -    if ( (scratch2 !=3D 0) || (scratch3 !=3D 0x0F) )
> +    if ( (scratch2 !=3D 0) || (scratch3 !=3D UART_IER_MASK) )
>          return 0;
>
>      /*
>       * Check to see if a UART is really there.
>       * Use loopback test mode.
>       */
> -    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | 0x0A);
> -    status =3D ns_read_reg(uart, UART_MSR) & 0xF0;
> -    return (status =3D=3D 0x90);
> +    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | UART_MCR_RTS | UART_MCR=
_OUT2);
> +    status =3D ns_read_reg(uart, UART_MSR) & UART_MSR_STATUS;
> +    return (status =3D=3D (UART_MSR_CTS | UART_MSR_DCD));
>  }
>
>  #ifdef CONFIG_HAS_PCI
> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> index d13352940c13..bbbffb14d320 100644
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,6 +32,7 @@
>  #define UART_MCR          0x04    /* Modem control        */
>  #define UART_LSR          0x05    /* line status          */
>  #define UART_MSR          0x06    /* Modem status         */
> +#define UART_SCR          0x07    /* Scratch pad          */
>  #define UART_USR          0x1f    /* Status register (DW) */
>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=3D1) */
>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=3D1) */
> @@ -42,6 +43,8 @@
>  #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
>  #define UART_IER_ELSI     0x04    /* rx line status       */
>  #define UART_IER_EMSI     0x08    /* MODEM status         */
> +#define UART_IER_MASK \
> +    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
>
>  /* Interrupt Identification Register */
>  #define UART_IIR_NOINT    0x01    /* no interrupt pending */
> @@ -51,12 +54,19 @@
>  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
>  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
>  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> +#define UART_IIR_FE       0xc0    /* FIFO enabled (2 bits) */
>
>  /* FIFO Control Register */
> -#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> -#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> -#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> +#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
> +#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
> +#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
> +#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */
> +#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
> +#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */
> +#define UART_FCR_RTB0       BIT(6, U)   /* receiver trigger bit #0 */
> +#define UART_FCR_RTB1       BIT(7, U)   /* receiver trigger bit #1 */
> +#define UART_FCR_TRG_MASK   (UART_FCR_RTB0 | UART_FCR_RTB1)

Thanks for the patch. I noticed that in this changeset some bit
definitions (e.g. UART_FCR_*) were rewritten using the BIT(n, U)
macro, while others (e.g. UART_IER_* and rest of UART_FCR_*) are
still left as plain hex values (0x01, 0x02, etc.), even though they
are also powers of two.

Could you clarify the reasoning behind this choice? From a reader=E2=80=99s
perspective it looks inconsistent. Would it make sense to either:

  - update all of them to use BIT() for consistency, or
  - keep the existing style unchanged in this patch and move a full
    conversion to BIT() into a separate cleanup patch?

This would make the codebase easier to follow.

> +
>  #define UART_FCR_TRG1     0x00    /* Rx FIFO trig lev 1   */
>  #define UART_FCR_TRG4     0x40    /* Rx FIFO trig lev 4   */
>  #define UART_FCR_TRG8     0x80    /* Rx FIFO trig lev 8   */
> @@ -96,11 +106,32 @@
>  #define UART_LCR_CONF_MODE_B   0xBF            /* Configuration mode B *=
/
>
>  /* Modem Control Register */
> -#define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
> -#define UART_MCR_RTS      0x02    /* Request to Send      */
> -#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
> -#define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
> -#define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=3D=
1) */
> +#define UART_MCR_DTR            BIT(0, U)   /* Data Terminal Ready  */
> +#define UART_MCR_RTS            BIT(1, U)   /* Request to Send      */
> +#define UART_MCR_OUT1           BIT(2, U)   /* Output #1 */
> +#define UART_MCR_OUT2           BIT(3, U)   /* Output #2 */
> +#define UART_MCR_LOOP           BIT(4, U)   /* Enable loopback test mode=
 */
> +#define UART_MCR_RESERVED0      BIT(5, U)   /* Reserved #0 */
> +#define UART_MCR_TCRTLR         BIT(6, U)   /* Access TCR/TLR (TI16C752,=
 EFR[4]=3D1) */
> +#define UART_MCR_RESERVED1      BIT(7, U)   /* Reserved #1 */
> +#define UART_MCR_MASK \
> +    (UART_MCR_DTR | UART_MCR_RTS | \
> +     UART_MCR_OUT1 | UART_MCR_OUT2 | \
> +     UART_MCR_LOOP | UART_MCR_TCRTLR)
> +
> +/* Modem Status Register */
> +#define UART_MSR_DCTS           BIT(0, U)   /* Change in CTS */
> +#define UART_MSR_DDSR           BIT(1, U)   /* Change in DSR */
> +#define UART_MSR_TERI           BIT(2, U)   /* Change in RI */
> +#define UART_MSR_DDCD           BIT(3, U)   /* Change in DCD */
> +#define UART_MSR_CTS            BIT(4, U)
> +#define UART_MSR_DSR            BIT(5, U)
> +#define UART_MSR_RI             BIT(6, U)
> +#define UART_MSR_DCD            BIT(7, U)
> +#define UART_MSR_CHANGE \
> +    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
> +#define UART_MSR_STATUS \
> +    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
>
>  /* Line Status Register */
>  #define UART_LSR_DR       0x01    /* Data ready           */
> @@ -111,6 +142,7 @@
>  #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
>  #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
>  #define UART_LSR_ERR      0x80    /* Error                */
> +#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)
>
>  /* These parity settings can be ORed directly into the LCR. */
>  #define UART_PARITY_NONE  (0<<3)
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 20:37:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 20:37:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113539.1461223 (Exim 4.92)
	(envelope-from )
	id 1uuzfM-0007u2-UV; Sat, 06 Sep 2025 20:37:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113539.1461223; Sat, 06 Sep 2025 20:37: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 1uuzfM-0007tt-O6; Sat, 06 Sep 2025 20:37:44 +0000
Received: by outflank-mailman (input) for mailman id 1113539;
 Sat, 06 Sep 2025 20:37:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uuzfL-0007tn-Kp
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 20:37:43 +0000
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [2a00:1450:4864:20::235])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 55695828-8b61-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 22:37:41 +0200 (CEST)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-336cee72f40so28305561fa.2
 for ; Sat, 06 Sep 2025 13:37: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: 55695828-8b61-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757191060; x=1757795860; 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=cl9wBI2qiAIO2fcJPMTYS8NlpunnhlluqBZRo3cmsXw=;
        b=DYGAus1GHRuJEj/XM8vVN7o+sKHOGQkAJ/BN2u4OgACvji/prI4QvSoqW4VwGLoOyt
         PC5OA2H1XvL3QeKQpGSd3HANQm6pimUfxE+rZyEYIH+hYJZ70is8thz7budh5EI8vXtf
         EHWzOMffCqBIQ/6qZaHwIHe2fKCQSzddi218VFI12cKC5GMJCitKL4L6aRzpWDQ4UFgX
         qR0ucR6qOPHJRIltmnd06dlmgGsjp2kKYLznIHq1HCH+Xss232umPgBdbjnbhCOr9KN5
         avFnPx60uSMG0wGlbYJ0EadhGss65ayKYYNDGrtLx0zs85IhnipjNH2ML8N0VhNimyrd
         Xz2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757191060; x=1757795860;
        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=cl9wBI2qiAIO2fcJPMTYS8NlpunnhlluqBZRo3cmsXw=;
        b=M/w0LFjypv9/pTgoaajZLaspl8BTAsUTmuHNZMtgngIcbrVe/qFG25pxOsg4lrdS/k
         t0a9FQOGau2lWF6PaXzdAXGI/x745E4Q9sPcLUUgpQpy3Bkztaemz4yDl9/mxjZ40zTb
         6IBM73COOALOZJ/qiOV72pxR5cX8gjkXr9lEAjd6nps+BoRkwonCQZbRvDfzJujZhWxg
         081evtlASUcd75NQUUk4AF9bfjoh+Lq3ITgQWVn7nAuVhnjBcF27UAhH9F3nblXlMIEn
         ih6U2dQN5RQIhzkC5t3hPFyJkQ9kZAs04SU7d3qZ4qBHGnfsjylWMo7o/QFIoHSMWyRM
         PG1A==
X-Gm-Message-State: AOJu0YwirZGSmKWOJChs6VIxuOzb2MrZe4et1pkw9z4Raa7kori/1BEF
	cWwbWbPnseA6OjfLIl5PD/v16Ia2sn31S7lRwlvnwMAFlcsxILUIBwQY4IGbcvrEWn7TSG9OPdL
	eTlBFbI+/yMYBR7zs1YfQwyMoKxVfoBA=
X-Gm-Gg: ASbGnctTGYOan8hKZ3Qd8XFXkvNNOUHCAM9medx14ETDHVIF8+/k3XrGOfpFv6jqC7o
	jh1mKGXhrwAh4n7prYeRWSsyx6LfC7sicoJsSG6mQRfSYvpYqjV9IBTXhunDZSrMuoLTFx3ELJ6
	U8oBmMhEvzooKPimPUP2f4zc/l3smkfMYpmL7q85S1lX1SBqNTvqttgimNWh7wcFeqEA7M/Yc0o
	z6M10NkSn346sPG
X-Google-Smtp-Source: AGHT+IEIY+AvuQvPoLyvrchQFhBGu/c84ta+/bkHThsmV2FD7p7LawJ85ywsTp5Ooj8mEjm51eJPLU3hDHhBEORXlFY=
X-Received: by 2002:a2e:b8c4:0:b0:336:8c3d:fb0a with SMTP id
 38308e7fff4ca-33b5cccbf9fmr7823661fa.21.1757191060073; Sat, 06 Sep 2025
 13:37:40 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-4-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-4-dmukhin@ford.com>
From: Mykola Kvach 
Date: Sat, 6 Sep 2025 23:37:28 +0300
X-Gm-Features: Ac12FXw3bETyQXRwYP9XXoROfQO_ek4xeb76iacmdeHoMDsVYkGPDklAS4oYJTM
Message-ID: 
Subject: Re: [PATCH v6 03/15] emul/ns16x50: implement emulator stub
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Sat, Sep 6, 2025 at 2:27=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> The change is the first on the way on introducing minimally functional
> NS16550-compatible UART emulator.
>
> Define UART state and a set of emulated registers.
>
> Implement alloc/free vUART hooks.
>
> Stub out I/O port handler.
>
> Add initialization of the NS16x50-compatible UART emulator state machine.
>
> Plumb debug logging.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - v5 feedback
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-4-=
dmukhin@ford.com/
> ---
>  xen/arch/x86/hvm/hvm.c          |  21 ++
>  xen/common/emul/vuart/Kconfig   |  19 ++
>  xen/common/emul/vuart/Makefile  |   1 +
>  xen/common/emul/vuart/ns16x50.c | 366 ++++++++++++++++++++++++++++++++
>  4 files changed, 407 insertions(+)
>  create mode 100644 xen/common/emul/vuart/ns16x50.c
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 23bd7f078a1d..91c971f11e14 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 

I noticed that this include ...

> +#include 

... is out of alphabetical order. All other includes in this block
are correctly sorted.

>  #include 
>  #include 
>  #include 
> @@ -689,6 +690,22 @@ int hvm_domain_initialise(struct domain *d,
>      if ( rc !=3D 0 )
>          goto fail1;
>
> +    /* Limit NS16550 emulator for dom0 only for now. */
> +    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && is_hardware_domain(d) )

Currently, the Xen glossary defines a "hardware domain" as:

    A domain, commonly dom0, which shares responsibility with Xen
    about the system as a whole.

It has been historically correct to treat is_hardware_domain(d) as
equivalent to dom0. However, according to patch series [1], this is
no longer guaranteed:

    "Setting hardware domain as domid 0 is removed."

After these changes, the assumption that hardware domain always equals
dom0 may not hold. As a result, the above comment in the code could
become misleading. Consider updating it to something like:

    /* Limit NS16550 emulator to the hardware domain only for now */

to reflect the new semantics.

> +    {
> +        struct vuart_info info =3D {
> +            .name       =3D "COM2",
> +            .compatible =3D "ns16550",
> +            .base_addr  =3D 0x2f8,
> +            .size       =3D 8,
> +            .irq        =3D 3,
> +        };

Consider defining COM2 base address and IRQ in a shared header
(e.g., VUART_COM2_BASE and VUART_COM2_IRQ) rather than using
the magic numbers 0x2f8 and 3 here. This would allow reuse in
`__start_xen` and other places, and makes the code clearer and
easier to maintain.

> +
> +        rc =3D vuart_init(d, &info);
> +        if ( rc )
> +            goto out_vioapic_deinit;
> +    }
> +
>      stdvga_init(d);
>
>      rtc_init(d);
> @@ -712,6 +729,8 @@ int hvm_domain_initialise(struct domain *d,
>      return 0;
>
>   fail2:
> +    vuart_deinit(d);
> + out_vioapic_deinit:
>      vioapic_deinit(d);
>   fail1:
>      if ( is_hardware_domain(d) )
> @@ -774,6 +793,8 @@ void hvm_domain_destroy(struct domain *d)
>      if ( hvm_funcs.domain_destroy )
>          alternative_vcall(hvm_funcs.domain_destroy, d);
>
> +    vuart_deinit(d);
> +
>      vioapic_deinit(d);
>
>      XFREE(d->arch.hvm.pl_time);
> diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfi=
g
> index ce1b976b7da7..a27d7ca135af 100644
> --- a/xen/common/emul/vuart/Kconfig
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -3,4 +3,23 @@ config VUART_FRAMEWORK
>
>  menu "UART Emulation"
>
> +config VUART_NS16X50
> +       bool "NS16550-compatible UART Emulator" if EXPERT
> +       depends on X86 && HVM
> +       select VUART_FRAMEWORK
> +       default n
> +       help
> +         In-hypervisor NS16x50 UART emulation.
> +
> +         Only legacy PC COM2 port is emulated.
> +
> +         This is strictly for testing purposes (such as early HVM guest =
console),
> +         and not appropriate for use in production.
> +
> +config VUART_NS16X50_DEBUG
> +       bool "NS16550-compatible UART Emulator Debugging"
> +       depends on VUART_NS16X50 && DEBUG
> +       help
> +         Enable development debugging.
> +
>  endmenu
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> index 97f792dc6641..fe904f6cb65d 100644
> --- a/xen/common/emul/vuart/Makefile
> +++ b/xen/common/emul/vuart/Makefile
> @@ -1 +1,2 @@
>  obj-y +=3D vuart.o
> +obj-$(CONFIG_VUART_NS16X50) +=3D ns16x50.o
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> new file mode 100644
> index 000000000000..0462a961e785
> --- /dev/null
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -0,0 +1,366 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS16550-compatible UART Emulator.
> + *
> + * See:
> + * - Serial and UART Tutorial:
> + *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-u=
art_en.pdf
> + * - UART w/ 16 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> + * - UART w/ 64 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
> + *
> + * Limitations:
> + * - Only x86;
> + * - Only Xen console as a backend, no inter-domain communication (simil=
ar to
> + *   vpl011 on Arm);
> + * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
> + * - No baud rate emulation (reports 115200 baud to the guest OS);
> + * - No FIFO-less mode emulation;
> + * - No RX FIFO interrupt moderation (FCR) emulation;
> + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> + *   friends);
> + * - No ISA IRQ sharing allowed;
> + * - No MMIO-based UART emulation.
> + */
> +
> +#define pr_prefix               "ns16x50"
> +#define pr_fmt(fmt)             pr_prefix ": " fmt
> +
> +#ifdef CONFIG_VUART_NS16X50_DEBUG
> +#define guest_prefix            "FROM GUEST "
> +#define ns16x50_log_level       2
> +#else
> +#define guest_prefix            ""
> +#define ns16x50_log_level       0
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define ns16x50_log(n, lvl, vdev, fmt, args...) \
> +do { \
> +    if ( ns16x50_log_level >=3D n ) \
> +        gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \
> +} while (0)
> +
> +#define ns16x50_err(vdev, fmt, args...) \
> +    ns16x50_log(0, XENLOG_ERR, vdev, fmt, ## args)
> +#define ns16x50_warn(vdev, fmt, args...) \
> +    ns16x50_log(1, XENLOG_WARNING, vdev, fmt, ## args)
> +#define ns16x50_info(vdev, fmt, args...) \
> +    ns16x50_log(2, XENLOG_INFO, vdev, fmt, ## args)
> +#define ns16x50_debug(vdev, fmt, args...) \
> +    ns16x50_log(3, XENLOG_DEBUG, vdev, fmt, ## args)
> +
> +/*
> + * Number of supported registers in the UART.
> + */
> +#define NS16X50_REGS_NUM        (UART_SCR + 1)
> +
> +/*
> + * Number of emulated registers.
> + *
> + * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=
=3D0.
> + * - DLAB=3D1, R/W, DLL            =3D NS16X50_REGS_NUM + 0
> + * - DLAB=3D1, R/W, DLM            =3D NS16X50_REGS_NUM + 1
> + * -         R/O, IIR (IIR_THR)  =3D NS16X50_REGS_NUM + 2
> + */
> +#define NS16X50_EMU_REGS_NUM    (NS16X50_REGS_NUM + 3)
> +
> +/*
> + * Virtual ns16x50 device state.
> + */
> +struct vuart_ns16x50 {
> +    uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */
> +    const struct vuart_info *info;      /* UART description */
> +    struct domain *owner;               /* Owner domain */
> +    const char *name;                   /* Device name */
> +    spinlock_t lock;                    /* Protection */
> +    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
> +};
> +
> +static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> +{
> +    return 0;
> +}
> +
> +/*
> + * Emulate 8-bit write access to ns16x50 register.
> + */
> +static int ns16x50_io_write8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    int rc =3D 0;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit write access to ns16x50 register.
> + * NB: some guest OSes use outw() to access UART_DLL.
> + */
> +static int ns16x50_io_write16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    int rc =3D -EINVAL;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate write access to ns16x50 register.
> + */
> +static int ns16x50_io_write(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_write8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_write16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 8-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    uint8_t val =3D 0xff;

Instead of hardcoding 0xff here, consider using UINT8_MAX. This makes
it clear that the value is the maximum for uint8_t and avoids magic
numbers.

Similarly, in other places where constants for 16-bit or 32-bit
unsigned integers are used, it would be good to replace them with
UINT16_MAX and UINT32_MAX respectively for consistency and clarity.

> +    int rc =3D 0;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    uint16_t val =3D 0xffff;
> +    int rc =3D -EINVAL;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate read access to ns16x50 register.
> + */
> +static int ns16x50_io_read(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_read8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_read16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        *data =3D 0xffffffff;
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate I/O access to ns16x50 register.
> + * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is en=
abled.
> + */
> +static int cf_check ns16x50_io_handle(
> +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> +{
> +#define op(dir)     (((dir) =3D=3D IOREQ_WRITE) ? 'W' : 'R')

Instead of defining the op(dir) macro, it might be cleaner to compute
the direction character once at the beginning, e.g.:

    const char dir_char =3D (dir =3D=3D IOREQ_WRITE) ? 'W' : 'R';

and then use dir_char in printk()/debug. This avoids the local macro
and makes the code easier to follow.

> +    struct domain *d =3D rcu_lock_current_domain();
> +    struct vuart *vuart =3D vuart_find_by_io_range(d, addr, size);
> +    struct vuart_ns16x50 *vdev;
> +    const struct domain *owner;
> +    const struct vuart_info *info;
> +    uint32_t reg;
> +    unsigned dlab;
> +    int rc;
> +
> +    if ( !vuart || !vuart->vdev )
> +    {
> +        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
> +               op(dir), addr, size);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +    vdev =3D vuart->vdev;
> +
> +    owner =3D vuart->owner;
> +    ASSERT(owner);
> +    if ( d !=3D owner )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domai=
n %pv\n",
> +                    op(dir), addr, size, d);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +
> +    info =3D vuart->info;
> +    ASSERT(info);
> +    reg =3D addr - info->base_addr;
> +    if ( !IS_ALIGNED(reg, size) )
> +    {
> +        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
> +                    op(dir), addr, size);
> +        goto out;
> +    }
> +
> +    dlab =3D ns16x50_dlab_get(vdev);
> +    if ( reg >=3D NS16X50_REGS_NUM )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"=
PRIx32": not implemented\n",
> +                    op(dir), addr, size, dlab, reg, *data);
> +        goto out;
> +    }
> +
> +    spin_lock(&vdev->lock);
> +
> +    if ( dir =3D=3D IOREQ_WRITE )
> +    {
> +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"P=
RIx32"\n",
> +                      op(dir), addr, size, dlab, reg, *data);
> +        rc =3D ns16x50_io_write(vdev, reg, size, data);

AFAICT ns16x50_io_read() and ns16x50_io_write() have identical
signatures. Would it be cleaner to store them in an array of
function pointers and call through that, e.g.:

    rc =3D ns16x50_io_op[dir =3D=3D IOREQ_WRITE](vdev, reg, size, data);

This would avoid the if/else block here.

> +    }
> +    else
> +    {
> +        rc =3D ns16x50_io_read(vdev, reg, size, data);
> +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"P=
RIx32"\n",
> +                      op(dir), addr, size, dlab, reg, *data);

The ns16x50_debug() call is duplicated in both branches of the
IOREQ_WRITE check, differing only in whether it's placed before or
after the access. Would it make sense to move this debug print
outside the condition, so the same code is used for both read and
write paths (assuming the "data"  is not modified during a write)?

> +    }
> +    if ( rc < 0 )
> +        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"PRI=
x32": unsupported access\n",
> +                    op(dir), addr, size, dlab, reg, *data);

The ns16x50_err() call doesn=E2=80=99t require holding vdev->lock, so it wo=
uld
be cleaner to move it after spin_unlock(). That way the critical section
is shorter.

> +
> +    spin_unlock(&vdev->lock);
> +
> +out:
> +    rcu_unlock_domain(d);
> +
> +    return X86EMUL_OKAY;
> +#undef op
> +}
> +
> +static int ns16x50_init(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +    const struct vuart_info *info =3D vdev->info;
> +    struct domain *d =3D vdev->owner;
> +
> +    ASSERT(vdev);
> +
> +    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
> +
> +    return 0;
> +}
> +
> +static void cf_check ns16x50_deinit(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +
> +    ASSERT(vdev);
> +}
> +
> +static void * cf_check ns16x50_alloc(struct domain *d, const struct vuar=
t_info *info)
> +{
> +    struct vuart_ns16x50 *vdev;
> +    int rc;
> +
> +    if ( !info )
> +        return ERR_PTR(-EINVAL);
> +
> +    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
> +    {
> +        ns16x50_err(info, "already registered\n");
> +        return ERR_PTR(-EBUSY);
> +    }
> +
> +    if ( !is_hvm_domain(d) )

Currently, ns16x50_alloc() first calls vuart_find_by_io_range() and
only afterwards checks if the domain is an HVM domain. Wouldn=E2=80=99t it
be more logical to perform the HVM check first? If the console is
only available for HVM domains, the extra check for an uninitialized
vuart field seems unnecessary.

> +    {
> +        ns16x50_err(info, "not an HVM domain\n");
> +        return ERR_PTR(-ENOSYS);
> +    }
> +
> +    vdev =3D xvzalloc(typeof(*vdev));
> +    if ( !vdev )
> +    {
> +        ns16x50_err(info, "failed to allocate memory\n");
> +        return ERR_PTR(-ENOMEM);
> +    }
> +
> +    spin_lock_init(&vdev->lock);
> +    vdev->name =3D info->name;
> +    vdev->owner =3D d;
> +    vdev->info =3D info;
> +
> +    rc =3D ns16x50_init(vdev);
> +    if ( rc )

If ns16x50_init(vdev) fails, vdev should be freed with xvfree() to
avoid a memory leak.

Currently, ns16x50_init() always returns 0. If it is not planned to
return other values in the future, it may be simpler to make the
function return void, avoiding the need for the rc variable and
conditional checks.

> +        return ERR_PTR(rc);
> +
> +    return vdev;
> +}
> +
> +static void cf_check ns16x50_free(void *arg)
> +{
> +    if ( arg )
> +        ns16x50_deinit(arg);
> +
> +    xvfree(arg);
> +}
> +
> +#define ns16x50_emulator                \
> +{                                       \
> +    .compatible =3D "ns16550",            \
> +    .alloc      =3D ns16x50_alloc,        \
> +    .free       =3D ns16x50_free,         \
> +    .dump_state =3D NULL,                 \

dump_state is set to NULL, but vuart_dump_state() in the previous
commit does not check this pointer. If all commits up to this one
are applied and domain state is dumped, this could result in a
NULL pointer dereference and crash the hypervisor.

Consider adding a NULL check in vuart_dump_state() or initializing
dump_state properly.

> +    .put_rx     =3D NULL,                 \
> +}
> +
> +VUART_REGISTER(ns16x50, ns16x50_emulator);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 2.51.0
>
>

[1] https://patchew.org/Xen/20250416212911.410946-1-jason.andryuk@amd.com/

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 21:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 21:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113554.1461232 (Exim 4.92)
	(envelope-from )
	id 1uv0Ct-0004Ll-FO; Sat, 06 Sep 2025 21:12:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113554.1461232; Sat, 06 Sep 2025 21: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 1uv0Ct-0004Le-CI; Sat, 06 Sep 2025 21:12:23 +0000
Received: by outflank-mailman (input) for mailman id 1113554;
 Sat, 06 Sep 2025 21: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 1uv0Cs-0004LY-KL
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 21:12:22 +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 2cad02a1-8b66-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 23:12:20 +0200 (CEST)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-336c2194a65so25711781fa.2
 for ; Sat, 06 Sep 2025 14:12: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: 2cad02a1-8b66-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757193140; x=1757797940; 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=P1YUNJZqPjxHJSc8Jg7VGMsUgSR+kl5Uak2Fz4Fd8n4=;
        b=Ux4Tap3Pa+4oki6lEyt82hP2H43cZ+amUhl5FrfCl6Qdoxt8h9eoPQXDU4KOU+toO1
         Q2Ba3DpCrwXuF+6uwZmK17wIkU9cZwcXFEQz/yCKr4agOv/UKJ7aKNedDW70YI6VYkMz
         dvMzwhehzmPMErZkgslXRnQK0YdXKmrMmJAblDe8snpkdZqMPpiqSaWe9lYhpRNExzXw
         NWn+aWH1pAn3CevBouqPKnMWE03AOf7NTXmOe0esdNXLm9dSvRcj5FnCAo8QhES7+ioV
         axD2208BbP0UEWrPuCh7tnnXgC+zah1PCIOCCWPu8jcE2aaDUeTxszytDLqIUbXwo+1d
         YLTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757193140; x=1757797940;
        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=P1YUNJZqPjxHJSc8Jg7VGMsUgSR+kl5Uak2Fz4Fd8n4=;
        b=jQkCfL0/Onk57MnJ7VW+gzfH1KOh7GrYBzwhj+G+x3xqgvKjOrNkW4fTfMlaZAF7gI
         mFz0neLaR9LWfKXgZCzfID5ubW9fIFrnjrE6Zs2sHSAr377gzTis1VzGOPVBKCrFbJ9Z
         1L40Z7CYUHIvkoa4Z/uhHsO5pr5IDVQ7+wRPQ/ZaRn8N3vU2Mzi2gxYEBkpnD09o5DKp
         J1VGyotpPfriJx83QHyLT97yL840Fo3WZPfbZKRtvRPYNoJ1R2iaZA/4uGZlqjsvPxZT
         EgOM2tSJTfE99wRhUySP15+I58QXzAf8Zlj9vWudWEbyc0byUOAb5s9pt3gXrqTaryml
         UaLA==
X-Gm-Message-State: AOJu0YwwrUTNumUJskkk4yQ3p9bWdT2Pnbx1MUGlb1px8xhpe7dHnMfT
	uQeZ4y9GodLnIb6a2qn6buaism+p+phOTMQGaz7HzFZiYNORpFXWO1lLRXveZ866GJDeLTIbCd4
	/jCo4iB99/8zmF57WgndQdL630fMNGh4=
X-Gm-Gg: ASbGncvazgxGWg+43APb8LusxpdkoDqnjoNPrC9FhaQ6RMvopHS3UDcpNT/krLGepm7
	kbas2rYTWx3KUHXrSVFmaQJ5yUEBymGWAx0DCQtzOb2ZYdynaqmJMPevJmtGMPoRIF9wUobWhp0
	21ow5FmFNbKlzy9bCI7L0mvpTxnm0PdcICzdEu3hh6xPcbib6e8DJy5+TmBdZPl0IcFuLCiK1L1
	s5cK8vfkT0KKug3
X-Google-Smtp-Source: AGHT+IFyz5ci8gEnwgRws8nKH5t7vD2VIn2E2Srz/SNYPxV2Ga/dN/uf47xVpaowL5rS1P34xCJTh75Q4EF/UYHJEPg=
X-Received: by 2002:a2e:a78a:0:b0:336:e102:95fd with SMTP id
 38308e7fff4ca-33b52b71809mr8925441fa.29.1757193139287; Sat, 06 Sep 2025
 14:12:19 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-5-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-5-dmukhin@ford.com>
From: Mykola Kvach 
Date: Sun, 7 Sep 2025 00:12:08 +0300
X-Gm-Features: Ac12FXwGHdVJ_iZIvTssQsbw4bPxufgrKp0zubMpLRCiBqTjWitvVG3Dwh_bXvE
Message-ID: 
Subject: Re: [PATCH v6 04/15] emul/ns16x50: implement DLL/DLM registers
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Sat, Sep 6, 2025 at 3:11=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add DLL/DLM registers emulation.
>
> DLL/DLM registers report hardcoded 115200 baud rate to the guest OS.
>
> Add stub for ns16x50_dlab_get() helper.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - dropped ns16x50_dlab_get() hunk (moved to emulator stub)
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-5-=
dmukhin@ford.com/
> ---
>  xen/common/emul/vuart/ns16x50.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index 0462a961e785..7f479a5be4a2 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -97,8 +97,13 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns1=
6x50 *vdev)
>  static int ns16x50_io_write8(
>      struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
>  {
> +    uint8_t *regs =3D vdev->regs;
> +    uint8_t val =3D *data;
>      int rc =3D 0;
>
> +    if ( ns16x50_dlab_get(vdev) && (reg =3D=3D UART_DLL || reg =3D=3D UA=
RT_DLM) )
> +        regs[NS16X50_REGS_NUM + reg] =3D val;

Some documentation (e.g., DesignWare DW_apb_uart Databook, v3.04a)
notes that if the Divisor Latch Registers (DLL and DLH) are set to
zero, the baud clock is disabled and no serial communications occur.

Should we handle the zero-divisor case to emulate this behavior more
accurately?

> +
>      return rc;
>  }
>
> @@ -109,8 +114,16 @@ static int ns16x50_io_write8(
>  static int ns16x50_io_write16(
>      struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
>  {
> +    uint16_t val =3D *data;
>      int rc =3D -EINVAL;
>
> +    if ( ns16x50_dlab_get(vdev) && reg =3D=3D UART_DLL )
> +    {
> +        vdev->regs[NS16X50_REGS_NUM + UART_DLL] =3D val & 0xff;
> +        vdev->regs[NS16X50_REGS_NUM + UART_DLM] =3D (val >> 8) & 0xff;

Instead of hardcoding 0xff here (and in similar lines below), consider
using UINT8_MAX. This makes it explicit that the value is the maximum
for a uint8_t and avoids magic numbers.

> +        rc =3D 0;
> +    }
> +
>      return rc;
>  }
>
> @@ -146,9 +159,13 @@ static int ns16x50_io_write(
>  static int ns16x50_io_read8(
>      struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
>  {
> +    uint8_t *regs =3D vdev->regs;
>      uint8_t val =3D 0xff;
>      int rc =3D 0;
>
> +    if ( ns16x50_dlab_get(vdev) && (reg =3D=3D UART_DLL || reg =3D=3D UA=
RT_DLM) )
> +        val =3D regs[NS16X50_REGS_NUM + reg];
> +
>      *data =3D val;
>
>      return rc;
> @@ -163,6 +180,13 @@ static int ns16x50_io_read16(
>      uint16_t val =3D 0xffff;
>      int rc =3D -EINVAL;
>
> +    if ( ns16x50_dlab_get(vdev) && reg =3D=3D UART_DLL )
> +    {
> +        val =3D vdev->regs[NS16X50_REGS_NUM + UART_DLM] << 8 |
> +              vdev->regs[NS16X50_REGS_NUM + UART_DLL];
> +        rc =3D 0;
> +    }
> +
>      *data =3D val;
>
>      return rc;
> @@ -280,12 +304,17 @@ out:
>
>  static int ns16x50_init(void *arg)
>  {
> +    const uint16_t divisor =3D (UART_CLOCK_HZ / 115200) >> 4;
>      struct vuart_ns16x50 *vdev =3D arg;
>      const struct vuart_info *info =3D vdev->info;
>      struct domain *d =3D vdev->owner;
>
>      ASSERT(vdev);
>
> +    /* NB: report 115200 baud rate. */
> +    vdev->regs[NS16X50_REGS_NUM + UART_DLL] =3D divisor & 0xff;
> +    vdev->regs[NS16X50_REGS_NUM + UART_DLM] =3D (divisor >> 8) & 0xff;
> +
>      register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
>
>      return 0;
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Sat Sep 06 21:24:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Sep 2025 21:24:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113565.1461244 (Exim 4.92)
	(envelope-from )
	id 1uv0Om-0005yT-Hj; Sat, 06 Sep 2025 21:24:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113565.1461244; Sat, 06 Sep 2025 21:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uv0Om-0005yM-Di; Sat, 06 Sep 2025 21:24:40 +0000
Received: by outflank-mailman (input) for mailman id 1113565;
 Sat, 06 Sep 2025 21:24: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 1uv0Ol-0005yG-3p
 for xen-devel@lists.xenproject.org; Sat, 06 Sep 2025 21:24:39 +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 e3c141b8-8b67-11f0-9809-7dc792cee155;
 Sat, 06 Sep 2025 23:24:36 +0200 (CEST)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-55f7cd8ec2cso4131192e87.2
 for ; Sat, 06 Sep 2025 14:24: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: e3c141b8-8b67-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757193876; x=1757798676; 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=5Zbvt6oOBwV3PGgfK6/FgHYGh+bR/uoLcr6FyocAarY=;
        b=Dr/GQGRg6GFtDaAuOwYGrWDRIPyyfdjswk582I2Kih9iVsKBPQNltLVtyz0d9acV6r
         0bGgc5nW0YCbS5CTbBxypTLQBaFB7dyQSD7uyisksA5KWjxh9svNBVv0/VfbiesFSdFc
         mp/+ed2yThAMwpAE5nmGl6PuhrMxZYuZ2KKO8woiD+4z/CUFy22QAXjKvseMPsX6vIew
         HPcIhVWNyUnhYfQPi2KXsGtth+sZgf6ETAxaqYX3TFeNJKinVLqMYWFYee/7gQNtjxuY
         rL64EdgL7JQb7r+AaaTWKNwln0cPxW9NC+jIysApeOoKv0+dt83b0TTnD+kNGpu9a+wJ
         dpow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757193876; x=1757798676;
        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=5Zbvt6oOBwV3PGgfK6/FgHYGh+bR/uoLcr6FyocAarY=;
        b=sgwDBeiGz4Asg2fyVBxQrBTMqIWhBP98G7wYsvre5nY0Z4VQW+EjGbD4VeTkMVgoHB
         VW5ISDtu+oclpa3EI3T8iA+nTHyyihdkLUI6yxxJe1/obyc8XqGfwzuSA99dBwDcKTT/
         9Q096+P05Tzj/pRxYV5Tt7gpYohjKTZtYohmxkV5FdJJ9bTnrVDBNLCB+59BUZOFowqd
         sAuQ10HqZRlOVaVe0cKQ/c2YDyBP6UOu67IEziH8g+WP79ZFr0awg4M03jgUazblVJej
         1oWjLa73BWAVnH/8gM9UUEGKiup2qsrJo/XHFnx/tIju7u6kxCV1dcIbQScKel2aZuDL
         Zf8A==
X-Gm-Message-State: AOJu0Yx4ScmHRSJAzMltGqkswb/EyzMaeX9VTLOLr5RiWgeamFg4a/dx
	p4qsGF1OVFcNDWSnwJMYGmhrby9oIkirDRNDHqi1WrxZOZRSO/1vjFQZKbga3S6qS9IwTHij9uM
	k+05yyIa900hLhqgamp10l71vJHPEywc=
X-Gm-Gg: ASbGnct6gw5MeMCjzrYiN+HCYa5rA0Sk9pIu0lhOJ6uTxF5vG6CYGbprmaXan5GBXB+
	fycybhS3jxu4U9iBkN1Qo/gr7YAtxMPkf51CrvISYTp4xmyav0v/BxiRVUxhiWf1vVzgLMvwA0U
	8ggWB54LvA4DGUJA6mBR6cXbbIkmXbFzuHZjBKllCG9qFmZ2QYJADVh5AX/iZqKa2kKuRrXRec9
	DzTtg==
X-Google-Smtp-Source: AGHT+IH4t02xrH24g6DqccWlzjGa/TZfpXr/VusbElSTvXa/ScX1Pj2e1rPmwzPp0a2+iua7sHdORv9grupx41kjj9M=
X-Received: by 2002:a05:6512:138a:b0:560:8484:a92e with SMTP id
 2adb3069b0e04-5625f5355ffmr1048505e87.15.1757193876041; Sat, 06 Sep 2025
 14:24:36 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-6-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-6-dmukhin@ford.com>
From: Mykola Kvach 
Date: Sun, 7 Sep 2025 00:24:24 +0300
X-Gm-Features: Ac12FXxMBmI9d_pQVABD4456xopwScZyRU_4MxZyPpF7J5sXNqXylvrhfWhkFu8
Message-ID: 
Subject: Re: [PATCH v6 05/15] emul/ns16x50: implement SCR register
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Sat, Sep 6, 2025 at 2:27=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add SCR register emulation to the I/O port handler.
> Firmware (e.g. OVMF) may use SCR during the guest OS boot.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - moved earlier in the series to simplify I/O handler population in
>   the follow on patches
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-11=
-dmukhin@ford.com/
> ---
>  xen/common/emul/vuart/ns16x50.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index 7f479a5be4a2..51ec85e57627 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -103,6 +103,20 @@ static int ns16x50_io_write8(
>
>      if ( ns16x50_dlab_get(vdev) && (reg =3D=3D UART_DLL || reg =3D=3D UA=
RT_DLM) )
>          regs[NS16X50_REGS_NUM + reg] =3D val;
> +    else
> +    {
> +        switch ( reg )
> +        {
> +        /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
> +        case UART_SCR:
> +            regs[UART_SCR] =3D val;
> +            break;
> +
> +        default:
> +            rc =3D -EINVAL;

In the previous commit, when ns16x50_dlab_get() was zero and UART_DLL
or UART_DLM was accessed, the function returned 0. With this commit,
the behavior changes: now an -EINVAL error is returned for both DLL
and DLM when ns16x50_dlab_get() is zero.

Should this be fixed in the previous commit, or is this change
intentional in this one? Note that for 16-bit accesses you already
return an error when ns16x50_dlab_get() is zero, so the behavior is
inconsistent for 8-bit accesses to DLL/DLM.

> +            break;
> +        }
> +    }
>
>      return rc;
>  }
> @@ -165,6 +179,19 @@ static int ns16x50_io_read8(
>
>      if ( ns16x50_dlab_get(vdev) && (reg =3D=3D UART_DLL || reg =3D=3D UA=
RT_DLM) )
>          val =3D regs[NS16X50_REGS_NUM + reg];
> +    else
> +    {
> +        switch ( reg )
> +        {
> +        case UART_SCR:
> +            val =3D regs[UART_SCR];
> +            break;
> +
> +        default:
> +            rc =3D -EINVAL;
> +            break;
> +        }
> +    }
>
>      *data =3D val;
>
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Sun Sep 07 09:16:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 09:16:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1113912.1461253 (Exim 4.92)
	(envelope-from )
	id 1uvBVr-0002Uh-G1; Sun, 07 Sep 2025 09:16:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1113912.1461253; Sun, 07 Sep 2025 09: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 1uvBVr-0002UO-B1; Sun, 07 Sep 2025 09:16:43 +0000
Received: by outflank-mailman (input) for mailman id 1113912;
 Sun, 07 Sep 2025 09: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 1uvBVq-0002UI-7D
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 09:16:42 +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 5d3c5aa6-8bcb-11f0-9d12-b5c5bf9af7f9;
 Sun, 07 Sep 2025 11:16: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-out2.suse.de (Postfix) with ESMTPS id B38596792C;
 Sun,  7 Sep 2025 09:16: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 6D45113675;
 Sun,  7 Sep 2025 09:16: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 rFHoGHdNvWhkcAAAD6G6ig
 (envelope-from ); Sun, 07 Sep 2025 09:16: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: 5d3c5aa6-8bcb-11f0-9d12-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757236600; 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=Ev5L/dwy/jG5Pl410mx4qKsRn3g6LOMAgJW8IZdok8k=;
	b=QbuBQnGITvl4m/tDDzI7iTWZdvEixLKbfVVPX180V7+f09DFugY7HYfWg6u95Le/KYZ/Uo
	B3YfWgYJRwUNPIUjEgVKh+Q9bq1nujg0ksFponS+Pu6RGtmy9uLVds1dLXOCQRg9mzB1ja
	k+ER9DGIQ88gKef3JxVlpldrQ5Jlelc=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=TtawrOVA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757236599; 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=Ev5L/dwy/jG5Pl410mx4qKsRn3g6LOMAgJW8IZdok8k=;
	b=TtawrOVAE5/ntr7xPRhKqW6xOPCp/60Y5u1UAnHYMdI28D1djraWTT/fumCDxDoTbgkZ2t
	oU6/BKoS6AT82YfYYkDwVYfP4958Ooatwna4gwiWwnZWytHeJ2VR9CpTOiC0mzxLsiCayn
	9jexupIJ8gFlvViUZ4hUQlpnBzA4RB8=
Message-ID: <3a78bf70-2588-47bf-947b-7da9db6b072b@suse.com>
Date: Sun, 7 Sep 2025 11:16:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
From: Juergen Gross 
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 
References: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-jgross@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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------trpub4uqq7UT2GfFDpIMyhMY"
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: B38596792C
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [-6.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,suse.com:email]
X-Spam-Score: -6.41

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------trpub4uqq7UT2GfFDpIMyhMY
Content-Type: multipart/mixed; boundary="------------pdM9f86IgsFm9ZrCc0dugDTw";
 protected-headers="v1"
From: Juergen Gross 
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 
Message-ID: <3a78bf70-2588-47bf-947b-7da9db6b072b@suse.com>
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
References: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-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=

--------------pdM9f86IgsFm9ZrCc0dugDTw
Content-Type: multipart/mixed; boundary="------------a7OMCbclef6r8MBzEq47OFV6"

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

T24gOC8yMC8yNSAwODowNSwgSnVlcmdlbiBHcm9zcyB3cm90ZToNCj4gUGluZz8NCj4gDQo+
IE9uIDMwLjA3LjI1IDE0OjIzLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gTGl2ZSB1cGRh
dGUgaXMgbm93IHdvcmtpbmcgd2l0aCB0aGUgUFZIIHZhcmlhbnQgb2YgeGVuc3RvcmUtc3R1
YmRvbS4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3Vz
ZS5jb20+DQo+PiAtLS0NCj4+IFYyOg0KPj4gLSBuZXcgcGF0Y2gNCj4+IC0tLQ0KPj4gwqAg
U1VQUE9SVC5tZCB8IDIgKy0NCj4+IMKgIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigr
KSwgMSBkZWxldGlvbigtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS9TVVBQT1JULm1kIGIvU1VQ
UE9SVC5tZA0KPj4gaW5kZXggNmE4MmE5MjE4OS4uZWI0NGVlODVmZCAxMDA2NDQNCj4+IC0t
LSBhL1NVUFBPUlQubWQNCj4+ICsrKyBiL1NVUFBPUlQubWQNCj4+IEBAIC0yODAsNyArMjgw
LDcgQEAgb3IgaXRzZWxmIHdpbGwgbm90IGJlIHJlZ2FyZGVkIGEgc2VjdXJpdHkgaXNzdWUu
DQo+PiDCoCAjIyMgQyB4ZW5zdG9yZSBzdHViZG9tIFBWSA0KPj4gwqDCoMKgwqDCoCBTdGF0
dXM6IFN1cHBvcnRlZA0KPj4gLcKgwqDCoCBTdGF0dXMsIExpdmV1cGRhdGU6IE5vdCBpbXBs
ZW1lbnRlZA0KPj4gK8KgwqDCoCBTdGF0dXMsIExpdmV1cGRhdGU6IFN1cHBvcnRlZA0KPj4g
wqAgIyMjIE9DYW1sIHhlbnN0b3JlZCBkYWVtb24NCj4gDQoNCkFuZCA0MCBkYXlzIGFmdGVy
IHNlbmRpbmcgb3V0OiBQSU5HPw0KDQoNCkp1ZXJnZW4NCg==
--------------a7OMCbclef6r8MBzEq47OFV6
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-----

--------------a7OMCbclef6r8MBzEq47OFV6--

--------------pdM9f86IgsFm9ZrCc0dugDTw--

--------------trpub4uqq7UT2GfFDpIMyhMY
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/Ey8FAmi9TXcFAwAAAAAACgkQsN6d1ii/Ey9k
WQf7BYFuWxMeLOPrzL6JT4w+xYag1uFV73A+8bu/rvc9wamIWWODgC5hXkessWyZNuBmd1igbwYt
f9mLWQ4w3szHigpPMbBiJHxw6jFaXN/jLzOAwNJLPAfUvYiWRTvFbCbBPZ2jjUdcmI5Wn5ms852p
fmQ2otC4KBi7RRhO/8GVybvzPwISZ70sFJ56Cm5173uDT3DcQM5HjG/NNYQV+UPvDYOK/QRUqJpX
nTU2LP7R3DVnOb95QiU5hBXuRJRNNI6EJRA5xoAFQNcR2hu3IGQaA++n7P17ZKU4V1Sw3PZdrgZt
XqAv6BmZFa634wz0J6xCEyB6UPx2YYdZp8aerCTqHA==
=p7Hh
-----END PGP SIGNATURE-----

--------------trpub4uqq7UT2GfFDpIMyhMY--


From xen-devel-bounces@lists.xenproject.org Sun Sep 07 14:25:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 14:25:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114065.1461263 (Exim 4.92)
	(envelope-from )
	id 1uvGKh-0003AS-AT; Sun, 07 Sep 2025 14:25:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114065.1461263; Sun, 07 Sep 2025 14: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 1uvGKh-0003AK-5y; Sun, 07 Sep 2025 14:25:31 +0000
Received: by outflank-mailman (input) for mailman id 1114065;
 Sun, 07 Sep 2025 14:25: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 1uvGKf-0003AE-PQ
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 14:25:30 +0000
Received: from fhigh-a3-smtp.messagingengine.com
 (fhigh-a3-smtp.messagingengine.com [103.168.172.154])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7cf0e277-8bf6-11f0-9809-7dc792cee155;
 Sun, 07 Sep 2025 16:25:23 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id C2941140003F;
 Sun,  7 Sep 2025 10:25:21 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Sun, 07 Sep 2025 10:25:21 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 7 Sep 2025 10:25: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: 7cf0e277-8bf6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sakamocchi.jp;
	 h=cc:cc:content-type:content-type:date:date:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:reply-to
	:subject:subject:to:to; s=fm1; t=1757255121; x=1757341521; bh=G/
	EPaorfj+fFyTEHaVMF0Aq5nU/5YHn8ZldlmV9nSRU=; b=LxAEL1hA32JcJEnG98
	oeJWFJW96Ab1ZdHJgGFlspwkJEj8Aiavk+dntTuQR94KmnDxtmALl7CB+fX7pbmo
	zvwHV9izosIpgEyayMmq4HTHRSL2iK4fMKWHMvvD41vWIEJCTnEIIqxOvjqUMPdN
	FaaZNPb2cDEYVHxVXwipUcCnSOWtlHTWUV9b7UKVDN46YphS5bUyXSD3O2FSIvg3
	JUD1TcNnZpGiXsQ7MCTj1TVHQ3ohhj+xY79FbL/+BRd7wIICp8XkFAHyKTyD/8lm
	yl+rKrALxeGxgT5Cn2F0n3Vujw7PsQdn7K1EKLloRiZFtuJG1JI5PkcjOkt6ZukQ
	tPFQ==
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:reply-to:subject:subject:to:to
	:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
	1757255121; x=1757341521; bh=G/EPaorfj+fFyTEHaVMF0Aq5nU/5YHn8Zld
	lmV9nSRU=; b=gkkyoHxlYwH2iEfC+POnjbirfwG9a7+WNBFdUULpIUfCF6QwBKD
	CXcsXkweDWwsQzN7Gd/GbXOk1SV+QIJUgWkOe1GLc0VVeUYBy346pR/YD304mG7z
	1ztsB7KcR9c74q1QJaQIjsplL9rOCD+fGXEZYd3b1CaBQnjtDDPbNZDWICkLf5pp
	E+qxogYXjT9un6LXfyJoljBVnMPFxj2E3BW22x2ShtmyGXx44gZthxk9ic+CJ+5v
	xe6lmL0VZ16DWgsUqgTs96f66G7saKooHJEnRz+Yld+xGqzw4yGMu+xPzsXFPe8w
	GNdDDSQNNRcQqEmj5hrowrarHbImiv5H7QA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddugeekkecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfggtggujgesthdtredttddtvdenucfhrhhomhepvfgrkhgrshhhihcu
    ufgrkhgrmhhothhouceoohdqthgrkhgrshhhihesshgrkhgrmhhotggthhhirdhjpheqne
    cuggftrfgrthhtvghrnhepveehudehueekveelteevkeevkeeiudfgtdeivdehjeetffdt
    vdeukeekheeitdetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
    hfrhhomhepohdqthgrkhgrshhhihesshgrkhgrmhhotggthhhirdhjphdpnhgspghrtghp
    thhtohepfeeipdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjghhgsehnvhhiug
    hirgdrtghomhdprhgtphhtthhopehmrdhsiiihphhrohifshhkihesshgrmhhsuhhnghdr
    tghomhdprhgtphhtthhopegrsgguihgvlhdrjhgrnhhulhhguhgvsehgmhgrihhlrdgtoh
    hmpdhrtghpthhtohepghhlihguvghrsehgohhoghhlvgdrtghomhdprhgtphhtthhopegr
    lhgvgidrghgrhihnohhrsehgmhgrihhlrdgtohhmpdhrtghpthhtoheprghkphhmsehlih
    hnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhopehhtghhsehlshhtrdgu
    vgdprhgtphhtthhopegurghkrheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepihhomh
    hmuheslhhishhtshdrlhhinhhugidruggvvh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: ie8e14432:Fastmail
Date: Sun, 7 Sep 2025 23:25:09 +0900
From: Takashi Sakamoto 
To: Jason Gunthorpe 
Cc: Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	iommu@lists.linux.dev, Jason Wang ,
	Jens Axboe , Joerg Roedel ,
	Jonathan Corbet , Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,	virtualization@lists.linux.dev,
 Will Deacon ,	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250907142509.GA507575@workstation.local>
Mail-Followup-To: Jason Gunthorpe ,
	Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	iommu@lists.linux.dev, Jason Wang ,
	Jens Axboe , Joerg Roedel ,
	Jonathan Corbet , Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,	virtualization@lists.linux.dev,
 Will Deacon ,	xen-devel@lists.xenproject.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250905174324.GI616306@nvidia.com>

Hi,

I'm a present maintainer of Linux FireWire subsystem, and recent years
have been working to modernize the subsystem.

On Fri, Sep 05, 2025 at 14:43:24PM -0300, Jason Gunthorpe wrote:
> There is only one user I found of alloc_pages:
>
> drivers/firewire/ohci.c:                ctx->pages[i] = dma_alloc_pages(dev, PAGE_SIZE, &dma_addr,
>
> And it deliberately uses page->private:
>
>		set_page_private(ctx->pages[i], dma_addr);
>
> So it is correct to use the struct page API.

I've already realized it, and it is in my TODO list to use modern
alternative APIs to replace it (but not yet). If you know some
candidates for this purpose, it is really helpful to accomplish it.


Regards

Takashi Sakamoto


From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:15:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114126.1461308 (Exim 4.92)
	(envelope-from )
	id 1uvI3C-0000UF-5E; Sun, 07 Sep 2025 16:15:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114126.1461308; Sun, 07 Sep 2025 16:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvI3B-0000Sc-Sn; Sun, 07 Sep 2025 16:15:33 +0000
Received: by outflank-mailman (input) for mailman id 1114126;
 Sun, 07 Sep 2025 16:15: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 1uvI3A-00009z-MC
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:15:32 +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 dd7dec0c-8c05-11f0-9809-7dc792cee155;
 Sun, 07 Sep 2025 18:15:26 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-6188b793d21so5740718a12.3
 for ; Sun, 07 Sep 2025 09:15:26 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.15.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09: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: dd7dec0c-8c05-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261726; x=1757866526; darn=lists.xenproject.org;
        h=content-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=iO5tUDv0U0MxdgWnoUNF5wlhakSsj8V4mCcgx1zPxGY=;
        b=Sk+rhqyTkocQRRGYQwdCD2mzvcbK5xh4F6JrfTQb7UEfpGhXYdaBs/bRR488lu5Or8
         0HCV23bkSc7QKkukR3acqrMHxg+ySAr9UuICfdsCZAEAYGbben7/I6R0bSteilH1aKDM
         iTddId3Q9zj5ZEXGWOQ+tf/lwaKL85eNKEDxQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261726; x=1757866526;
        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=iO5tUDv0U0MxdgWnoUNF5wlhakSsj8V4mCcgx1zPxGY=;
        b=K7XH1nBo5McfS/5QHoQmyY/1ONDqZNKfEJL+Mwvz4AlhGvUiu/ZxvUzTGXxb604Xhg
         djVPCt4aJmoq4sP95HqvRhOBdjo13VyrkmyV5AIDXitd6KmPso+imEvJ/b7340jG3L2G
         /LANt2XXJ0WdAQzlcXRYAhCFk9fVv1rx2OJ4YyqF56DuKNaXcuTBZvZpapRVR3V+2XVL
         p+nKFp4o4Fh7CXKuspbcJJAoG8oST8rrGkSMW4sSug/9ORxlWinaOtAyNSMVreXKqzdT
         9q9BSxFr6d5h2C6q7OLGuvMTqUWt8pw+C7mJtBJRUCrzEdZKb2GcivLzPgQncai1WSaZ
         k/YA==
X-Gm-Message-State: AOJu0YwgCWyG4PolYd3uzW1JuyPY+m0RsSkHR8u2iNcdI0l3gkfvw0rJ
	1asykPCgDwbpFzH54C/Y2YOKe5f5y9BtQ1YxUfOJMAVkzs7TU3+RX7PRCgB0IcpRCymgKouEsXz
	ie6QMqwY=
X-Gm-Gg: ASbGnctGaCN/q4IVBb0gltruo215y1iI+6ZToWEnZB0I3nSuOvr9QrDlHyGq57qTkmZ
	N3vDU8Zu8+5OQ3bzaISriwVd4/wBL/4uhsHUgoSRB8YGeCvB4fpL6J4nYSpajGZHMGlwRT7oBny
	2i3wITSWUEHBqjdd+CcXvBPIQ7TtQ1nqYvbYhaCxho+liVF/r7lWjbHi+/r3jt8ldRn0DFL7ujJ
	wYlA6G63hbHN6UoUSo4ecNXl4o2km2HtpxDewruLPqNSzIvgEo5QETahdTShMDM4PNa3VFoXWUh
	b3F1QeC2DYVpfE7Ll791WjspFqIFKPQPJlKyT2OI5Dea/pD8bwK1L7SrBtGiV4YTNSfc3UA+CDu
	CaJOGA28PeH4HEclN7ns96tkaywFpVUUBzfB5UWw0xUiIUi530I4t8gCLtjpiOhjDpvs=
X-Google-Smtp-Source: AGHT+IFM6Na4mCbdidqmq1mkUoDlkb/7C0nB0sqhQlVjW4irCLtDIf0HY6HTI0p1oz5LZmv7Xrwnvg==
X-Received: by 2002:a17:906:3185:b0:b04:b435:fc6b with SMTP id a640c23a62f3a-b04b43602bamr371349866b.60.1757261725991;
        Sun, 07 Sep 2025 09:15:25 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Shawn Anastasio ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko ,
	Jan Beulich 
Subject: [PATCH v3 1/7] xen/numa: Add per_node() variables paralleling per_cpu() variables
Date: Sun,  7 Sep 2025 18:15:16 +0200
Message-ID: <2a2e557f84ba4785f3f8788d31d3edf64e689da0.1757261045.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

During the review of the 3rd commit of the NUMA claims v1 series, it
was found to be concerning (performance-wise) add add another array
like this that randomly written from all nodes:

+/* Per-node counts of free pages */
+static unsigned long pernode_avail_pages[MAX_NUMNODES];

As solution, it was suggested to introduce per_node() paralleling
per_cpu(), or (less desirable) to make sure one particular cache
line would only ever be written from a single node.

It was mentioned that node_need_scrub[] could/should use it, and
I assume others may benefit too.

per_cpu() is a simple standard blueprint that is easy to copy, add
per_node(), paralleling per_cpu() as the preferred suggestion:

It is entirely derived from per_cpu(), with a few differences:

- No add/remove callback: Nodes are onlined on boot and never offlined.

- As per_node(avail_pages) and pernode(outstanding_claims) are used by
  the buddy allocator itself, and the buddy allocator is used to alloc
  the per_node() memory from the local NUMA node, there is a catch:

  per_node() must already be working to have a working buddy allocator:

  - Init per_node() before the buddy allocator is ready as it needs
    to be setup before its use, e.g. to init per_node(avail_pages)!

  Use an early static __initdata array during early boot and migrate
  it to the NUMA-node-local xenheap before we enable the secondary CPUs.

Cc: Jan Beulich 
Signed-off-by: Bernhard Kaindl 

---
Changes:
- This is patch is new in v3 to resolve the the suggestion from the review.
- The previous patch #2 is removed from the series as not required,
  which is best visualized by how claims are used:

  - Claim needed memory
  - Allocate all domain memory
  - Cancel a possible leftover claim
  - Finish building the domain and unpause it.

  As it makes no sense to repeat "Claim needed memory" at any time,
  the change made had no practical significance.  It can be applied
  later as a tiny, not important cleanup, e.g. with multi-node claims.

Implementation note on this patch (not needed for the commit message):

Instead of the __initdata array, I tried to alloc bootmem, but it
caused paging_init() to panic with not enough memory for p2m on a
very large 4-Socket, 480 pCPU, 4TiB RAM host (or it caused boot to
hang after the microcode updates of the 480 pCPUs)

The static __initdata array is freed after init and does not affect
bootmem allocation.

PPS: Yes, node_need_scrub[] should use it too, do it after this series.
---
 xen/arch/arm/xen.lds.S    |  1 +
 xen/arch/ppc/xen.lds.S    |  1 +
 xen/arch/riscv/xen.lds.S  |  1 +
 xen/arch/x86/xen.lds.S    |  1 +
 xen/common/numa.c         | 53 ++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/numa.h    | 15 +++++++++++
 xen/include/xen/xen.lds.h |  8 ++++++
 7 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index db17ff1efa..d296a95dd3 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -176,6 +176,7 @@ SECTIONS
        *(.bss.stack_aligned)
        *(.bss.page_aligned)
        PERCPU_BSS
+       PERNODE_BSS
        *(.bss .bss.*)
        . = ALIGN(POINTER_ALIGN);
        __bss_end = .;
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 1de0b77fc6..29d1b5da58 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -151,6 +151,7 @@ SECTIONS
         *(.bss.stack_aligned)
         *(.bss.page_aligned)
         PERCPU_BSS
+        PERNODE_BSS
         *(.bss .bss.*)
         . = ALIGN(POINTER_ALIGN);
         __bss_end = .;
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index edcadff90b..e154427353 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -146,6 +146,7 @@ SECTIONS
         *(.bss.stack_aligned)
         *(.bss.page_aligned)
         PERCPU_BSS
+        PERNODE_BSS
         *(.sbss .sbss.* .bss .bss.*)
         . = ALIGN(POINTER_ALIGN);
         __bss_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 966e514f20..95040cd516 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -327,6 +327,7 @@ SECTIONS
        __bss_start = .;
        *(.bss.page_aligned*)
        PERCPU_BSS
+       PERNODE_BSS
        *(.bss .bss.*)
        . = ALIGN(POINTER_ALIGN);
        __bss_end = .;
diff --git a/xen/common/numa.c b/xen/common/numa.c
index ad75955a16..5e66471159 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -320,6 +320,51 @@ static bool __init nodes_cover_memory(void)
     return true;
 }
 
+/* Defined on the BSS in xen.lds.S, used for area sizes and relative offsets */
+extern const char __pernode_start[];
+extern const char __pernode_end[];
+
+unsigned long __read_mostly __pernode_offset[MAX_NUMNODES];
+
+#define EARLY_PERNODE_AREA_SIZE (SMP_CACHE_BYTES)
+
+static char early_pernode_area[MAX_NUMNODES][EARLY_PERNODE_AREA_SIZE]
+    __initdata __cacheline_aligned;
+
+/* per_node() needs to be ready before the first alloc call using the heap */
+static void __init early_init_pernode_areas(void)
+{
+    unsigned int node;
+
+    if (__pernode_end - __pernode_start > EARLY_PERNODE_AREA_SIZE)
+        panic("per_node() area too small, increase EARLY_PERNODE_AREA_SIZE");
+
+    for_each_online_node(node)
+        __pernode_offset[node] = early_pernode_area[node] - __pernode_start;
+}
+
+/* Before going SMP, migrate the per_node memory areas to their NUMA nodes */
+static int __init init_pernode_areas(void)
+{
+    const int pernode_size = __pernode_end - __pernode_start;  /* size in BSS */
+    unsigned int node;
+
+    for_each_online_node(node)
+    {
+        char *p = alloc_xenheap_pages(get_order_from_bytes(pernode_size),
+                                      MEMF_node(node));
+
+        if ( !p )
+            return -ENOMEM;
+        /* migrate the pernode data from the bootmem area to the xenheap */
+        memcpy(p, early_pernode_area[node], SMP_CACHE_BYTES);
+        __pernode_offset[node] = p - __pernode_start;
+    }
+    return 0;
+}
+
+presmp_initcall(init_pernode_areas);
+
 /* Use discovered information to actually set up the nodes. */
 static bool __init numa_process_nodes(paddr_t start, paddr_t end)
 {
@@ -617,7 +662,7 @@ static int __init numa_emulation(unsigned long start_pfn,
 }
 #endif
 
-void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
+static void __init init_nodes(unsigned long start_pfn, unsigned long end_pfn)
 {
     unsigned int i;
     paddr_t start = pfn_to_paddr(start_pfn);
@@ -656,6 +701,12 @@ void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
     setup_node_bootmem(0, start, end);
 }
 
+void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
+{
+    init_nodes(start_pfn, end_pfn);
+    early_init_pernode_areas(); /* With all nodes registered, init per_node() */
+}
+
 void numa_add_cpu(unsigned int cpu)
 {
     cpumask_set_cpu(cpu, &node_to_cpumask[cpu_to_node(cpu)]);
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index f6c1f27ca1..729c400d64 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -152,4 +152,19 @@ static inline nodeid_t mfn_to_nid(mfn_t mfn)
 
 #define page_to_nid(pg) mfn_to_nid(page_to_mfn(pg))
 
+/* Per NUMA node data area handling based on per-cpu data area handling. */
+extern unsigned long __pernode_offset[];
+
+#define DECLARE_PER_NODE(type, name) \
+    extern __typeof__(type) pernode__ ## name
+
+#define __DEFINE_PER_NODE(attr, type, name) \
+    attr __typeof__(type) pernode_ ## name
+
+#define DEFINE_PER_NODE(type, name) \
+    __DEFINE_PER_NODE(__section(".bss.pernode"), type, _ ## name)
+
+#define per_node(var, node)  \
+    (*RELOC_HIDE(&pernode__##var, __pernode_offset[node]))
+
 #endif /* _XEN_NUMA_H */
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index b126dfe887..a32423dcec 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -174,6 +174,14 @@
 #define LOCK_PROFILE_DATA
 #endif
 
+/* Per-node BSS for declaring per_node vars, based on per_cpu, but simpler */
+#define PERNODE_BSS                \
+       . = ALIGN(PAGE_SIZE);       \
+       __pernode_start = .;        \
+       *(.bss.pernode)             \
+       . = ALIGN(SMP_CACHE_BYTES); \
+       __pernode_end = .;          \
+
 #define PERCPU_BSS                 \
        . = ALIGN(PAGE_SIZE);       \
        __per_cpu_start = .;        \
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:15:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114124.1461293 (Exim 4.92)
	(envelope-from )
	id 1uvI3B-0000Ds-4H; Sun, 07 Sep 2025 16:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114124.1461293; Sun, 07 Sep 2025 16:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvI3B-0000Dl-1T; Sun, 07 Sep 2025 16:15:33 +0000
Received: by outflank-mailman (input) for mailman id 1114124;
 Sun, 07 Sep 2025 16:15: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 1uvI39-0008Bo-8a
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:15:31 +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 dfdd860c-8c05-11f0-9d13-b5c5bf9af7f9;
 Sun, 07 Sep 2025 18:15:30 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b04163fe08dso630038666b.3
 for ; Sun, 07 Sep 2025 09:15:30 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.15.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:15: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: dfdd860c-8c05-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261730; x=1757866530; darn=lists.xenproject.org;
        h=content-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=+wb0w+Ib0HchtKtOoJZ/15uDzicml5JsFwuf7VKWvmc=;
        b=QblKeUDN3D+i0ATssUC5GbNyu+48pXHKeNp1FCY7cx6QBOVWPw29S9WsAMAeEqGJM/
         qrj+VbOeLBC/c2rshq/EreJVUQZIE3tNRHqib3hFVK3zpf2dh91YTcjGTusorN3FjYY0
         D3HtTIxV/xagi95chCOY74jJJJXM8Ji+92pZQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261730; x=1757866530;
        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=+wb0w+Ib0HchtKtOoJZ/15uDzicml5JsFwuf7VKWvmc=;
        b=s1AYt+ePzy5a2iMHXfIb1RdmTs0hStbZtH5fhT8Qs5+DHEG0maRZHrfRJpPtPF/qpA
         /WFdcq2oYHzXTeAIFhgdJ/iBf6Fyrzr4JlyapqMSRDbMo9XUFt6dPDQPD/wbj8ZX+1LO
         h5X/LefUNCUI0kShFtHU6W4g8zMbXP2df9VDMO2Wc9Kiu+ksTCZtR/IrsuK8tEhiHvst
         E1PA6C2i+ZSjh3Fcx8aZ4r5cPnQ82SifSkrdQYyp9LvLxxPRGU7BSZnxiQUg/GjjDP6d
         ybvCScy4IcrSpYc7TYHfeKSRuqipzEh0X06tqBqPEFDSAeX83xHdcnv8PUozKMKljry4
         8MZA==
X-Gm-Message-State: AOJu0YwY8Es4+rAdbvF23sv+BN5w+6sJvwYjjUr0JNkRX1ptcUIbaDE1
	acmOqyCTMG7fW5EvdOV/13qzF5NYSSCF+vkxhPg6CaP0AFLyho91GdTDzGYpCFb2mAuH01Bi6gV
	HTnsCawE=
X-Gm-Gg: ASbGncs7pEa1VzyPnKtjuHR6YvGMLvcMxYQQCSDELaOwAL8nfJqbwmFCcprr08B9mMn
	imzoccsYKyYN8aFJoGt1gtGvTutAimPLsK72wgA1QUhwOJKkzsoe69lTtmOm2VyUm/7EpR0F9eN
	d51Lw7AQoRZmVQ5Xv1y7RbipXMs7GhlUDs+zB7oyGv7Y2WZCfSv5DMamf3VKg+Ng+avTO21Kd/0
	yDEYcQr6hoAj0udbucsrj3mHJiJGauWa9qbXM+9yIP+/Nzt9XcMlQg4mv/zsL5DsiX6fyh/Hrnd
	WeHY9NEqoEofyGdChGGWyC9YmoLCDXV7UuFXTcxLf1bZyVStrXt9X0M+xDZs1iWOXEIlPzFUKm8
	mG3lv5s0f5TW/qFEcYHKl6sI3NFezQ1U6fDIxHcz3sT0rATsProvO9q75JhF0oDmJqC0=
X-Google-Smtp-Source: AGHT+IGJpDSkkIcfCORJaJVTeHzgRf+E7BrBIiM6Xe5wOoPEEV56CMMZIVXBq/xg2FvjtqZ9Wxu4/w==
X-Received: by 2002:a17:906:d54a:b0:b04:827c:9139 with SMTP id a640c23a62f3a-b04b16e4f4dmr432603466b.65.1757261729960;
        Sun, 07 Sep 2025 09:15:29 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 4/7] xen/page_alloc: Add staking a NUMA node claim for a domain
Date: Sun,  7 Sep 2025 18:15:19 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update domain_set_outstanding_pages() to domain_claim_pages() for
staking claims for domains on NUMA nodes:

domain_claim_pages() is a handler for claiming pages, where its former
name suggested that it just sets the domain's outstanding claims.

Actually, three different code locations do perform just this task:

Fix this using a helper to avoid repeating yourself (an anti-pattern)
for just only updating the domain's outstanding pages is added as well:

It removes the need to repeat the same sequence of operations at three
diffent places and helps to have a single location for adding multi-node
claims. It also makes the code much shorter and easier to follow.

Fix the meaning of the claims argument of domain_claim_pages()
for NUMA-node claims:

- For NUMA-node claims, we need to claim defined amounts of memory
  on different NUMA nodes. Previously, the argument was a "reservation"
  and the claim was made on the difference between d->tot_pages and
  the reservations. Of course, the argument needed to be > d->tot_pages.

  This interacs badly with NUMA claims:
  NUMA node claims are not related to potentially already allocated
  memory and reducing the claim by already allocated memory would
  not work in case d->tot_pages already has some amount of pages.

- Fix this by simply claiming the given amount of pages.

- Update the legacy caller of domain_claim_pages() accordingly by
  moving the reduction of the claim by d->tot_pages to it:

  No change for the users of the legacy hypercall, and a usable
  interface for staking NUMA claims.

Signed-off-by: Bernhard Kaindl 
Signed-off-by: Alejandro Vallejo 

---
Changes in v3:

- Renamed domain_set_outstanding_pages() and add check from review.
- Reorganized v3, v4 and v5 as per review to avoid non-functional
  changes:
  - Combined patch v2#2 with v2#5 into a consolidated patch.
  - Moved the unrelated changes for domain_adjust_tot_pages() to #5.
---
 xen/common/domain.c     |  2 +-
 xen/common/memory.c     | 15 ++++++-
 xen/common/page_alloc.c | 93 ++++++++++++++++++++++++++++-------------
 xen/include/xen/mm.h    |  3 +-
 xen/include/xen/sched.h |  1 +
 5 files changed, 81 insertions(+), 33 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 775c339285..6ee9f23b10 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1247,7 +1247,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_claim_pages(d, NUMA_NO_NODE, 0);
         /* fallthrough */
     case DOMDYING_dying:
         rc = domain_teardown(d);
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 3688e6dd50..3371edec11 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1682,7 +1682,20 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         rc = xsm_claim_pages(XSM_PRIV, d);
 
         if ( !rc )
-            rc = domain_set_outstanding_pages(d, reservation.nr_extents);
+        {
+            unsigned long new_claim = reservation.nr_extents;
+
+            /*
+             * For backwards compatibility, keep the meaning of nr_extents:
+             * it is the target number of pages for the domain.
+             * In case memory for the domain was allocated before, we must
+             * substract the already allocated pages from the reservation.
+             */
+            if ( new_claim )
+                new_claim -= domain_tot_pages(d);
+
+            rc = domain_claim_pages(d, NUMA_NO_NODE, new_claim);
+        }
 
         rcu_unlock_domain(d);
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b8acb500da..bbb34994b7 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -492,6 +492,30 @@ DEFINE_PER_NODE(unsigned long, avail_pages);
 
 static DEFINE_SPINLOCK(heap_lock);
 static long outstanding_claims; /* total outstanding claims by all domains */
+DECLARE_PER_NODE(long, outstanding_claims);
+DEFINE_PER_NODE(long, outstanding_claims);
+
+#define domain_has_node_claim(d) (d->claim_node != NUMA_NO_NODE)
+
+static inline bool insufficient_memory(unsigned long request, nodeid_t node)
+{
+    return per_node(avail_pages, node) -
+           per_node(outstanding_claims, node) < request;
+}
+
+/*
+ * Adjust the claim of a domain host-wide and if set, for the claimed node
+ *
+ * All callers already hold d->page_alloc_lock and the heap_lock.
+ */
+static inline void domain_adjust_outstanding_claim(struct domain *d, long pages)
+{
+    outstanding_claims += pages;   /* Update the host-wide-outstanding claims */
+    d->outstanding_pages += pages; /* Update the domain's outstanding claims */
+
+    if ( domain_has_node_claim(d) ) /* Update the claims of that node */
+        per_node(outstanding_claims, d->claim_node) += pages;
+}
 
 static unsigned long avail_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi, unsigned int node)
@@ -529,7 +553,7 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
     /*
      * 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
+     * domain_claim_pages below
      *
      * If the domain has no outstanding claims (or we freed pages instead),
      * we don't update outstanding claims and skip the claims adjustment.
@@ -544,18 +568,37 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
      * If allocated > outstanding, reduce the claims only by outstanding pages.
      */
     adjustment = min(d->outstanding_pages + 0UL, pages + 0UL);
-    d->outstanding_pages -= adjustment;
-    outstanding_claims -= adjustment;
+
+    domain_adjust_outstanding_claim(d, -adjustment);
     spin_unlock(&heap_lock);
 
 out:
     return d->tot_pages;
 }
 
-int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
+/*
+ * Stake claim for memory for future allocations of a domain.
+ *
+ * The claim is an abstract stake on future memory allocations,
+ * no actual memory is allocated at this point. Instead, it guarantees
+ * that future allocations up to the claim's size will succeed.
+ *
+ * If node == NUMA_NO_NODE, the claim is host-wide.
+ * Otherwise, it is local to the specific NUMA node defined by d->claim_node.
+ *
+ * It should normally only ever be before allocating the memory of the domain.
+ * When libxenguest code has finished populating the memory of the domain, it
+ * cleans up any remaining by passing of 0 to release any outstanding claims.
+ *
+ * Returns 0 on success, -EINVAL if the request is invalid,
+ * or -ENOMEM if the claim cannot be satisfied in available memory.
+ */
+int domain_claim_pages(struct domain *d, nodeid_t node, unsigned long claim)
 {
-    int ret = -ENOMEM;
-    unsigned long claim, avail_pages;
+    int ret = -EINVAL;
+
+    if ( node != NUMA_NO_NODE && !node_online(node) )
+        goto out; /* passed node is not valid */
 
     /*
      * take the domain's page_alloc_lock, else all d->tot_page adjustments
@@ -565,45 +608,35 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
     nrspin_lock(&d->page_alloc_lock);
     spin_lock(&heap_lock);
 
-    /* pages==0 means "unset" the claim. */
-    if ( pages == 0 )
+    /* claim==0 means "unset" the claim. */
+    if ( claim == 0 )
     {
-        outstanding_claims -= d->outstanding_pages;
-        d->outstanding_pages = 0;
+        domain_adjust_outstanding_claim(d, -d->outstanding_pages);
         ret = 0;
         goto out;
     }
 
     /* only one active claim per domain please */
     if ( d->outstanding_pages )
-    {
-        ret = -EINVAL;
         goto out;
-    }
 
-    /* disallow a claim not exceeding domain_tot_pages() or above max_pages */
-    if ( (pages <= domain_tot_pages(d)) || (pages > d->max_pages) )
-    {
-        ret = -EINVAL;
+    /* If we allocated for the domain already, the claim is on top of that. */
+    if ( (domain_tot_pages(d) + claim) > d->max_pages )
         goto out;
-    }
 
-    /* how much memory is available? */
-    avail_pages = total_avail_pages;
-
-    avail_pages -= outstanding_claims;
+    ret = -ENOMEM;
+    /* Check if the host-wide available memory is sufficent for this claim */
+    if ( claim > total_avail_pages - outstanding_claims )
+        goto out;
 
-    /*
-     * Note, if domain has already allocated memory before making a claim
-     * then the claim must take domain_tot_pages() into account
-     */
-    claim = pages - domain_tot_pages(d);
-    if ( claim > avail_pages )
+    /* Check if the node's available memory is insufficient for this claim */
+    if ( node != NUMA_NO_NODE && insufficient_memory(node, claim) )
         goto out;
 
     /* yay, claim fits in available memory, stake the claim, success! */
-    d->outstanding_pages = claim;
-    outstanding_claims += d->outstanding_pages;
+    d->claim_node = node;
+    domain_adjust_outstanding_claim(d, claim);
+
     ret = 0;
 
 out:
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index b968f47b87..52c12c5783 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -131,7 +132,7 @@ int populate_pt_range(unsigned long virt, unsigned long nr_mfns);
 /* Claim handling */
 unsigned long __must_check domain_adjust_tot_pages(struct domain *d,
     long pages);
-int domain_set_outstanding_pages(struct domain *d, unsigned long pages);
+int domain_claim_pages(struct domain *d, nodeid_t node, unsigned long pages);
 void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages);
 
 /* Domain suballocator. These functions are *not* interrupt-safe.*/
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 02bdc256ce..9b91261f20 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -405,6 +405,7 @@ struct domain
     unsigned int     outstanding_pages; /* pages claimed but not possessed */
     unsigned int     max_pages;         /* maximum value for domain_tot_pages() */
     unsigned int     extra_pages;       /* pages not included in domain_tot_pages() */
+    nodeid_t         claim_node;        /* NUMA_NO_NODE for host-wide claims */
 
 #ifdef CONFIG_MEM_SHARING
     atomic_t         shr_pages;         /* shared pages */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:15:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114122.1461272 (Exim 4.92)
	(envelope-from )
	id 1uvI35-0008C1-Ke; Sun, 07 Sep 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 1114122.1461272; Sun, 07 Sep 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 1uvI35-0008Bu-Hf; Sun, 07 Sep 2025 16:15:27 +0000
Received: by outflank-mailman (input) for mailman id 1114122;
 Sun, 07 Sep 2025 16:15:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvI34-0008Bo-Nn
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:15:26 +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 dcd7729c-8c05-11f0-9d13-b5c5bf9af7f9;
 Sun, 07 Sep 2025 18:15:25 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-afeec747e60so683260166b.0
 for ; Sun, 07 Sep 2025 09:15:25 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.15.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:15: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: dcd7729c-8c05-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261725; x=1757866525; 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=5ezfHQkZRgwNN2gzCEv+A/jxev3TmSiaVQoYBLd7h10=;
        b=FTlmOSDXzt4ldWlKu+LaekPrneSIWzgehubBg0f42exHUymL/W3nflMmVUZWuw2adX
         1Q6i1NyfnmdqQLl0Po6IhV4hFjiJ5BTWzvQBwBsAbvaRFVKjUmV4d7hUg4Wb9kABNetT
         LeZWuMT3e5BI0v4rVthH62+oa1QT6lgksg/Nk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261725; x=1757866525;
        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=5ezfHQkZRgwNN2gzCEv+A/jxev3TmSiaVQoYBLd7h10=;
        b=M/sP46RShGOs+oKrFEu5n4clip9Vm798krH0ZPqXloH+l2TvZEpriktUQD2sZ/1iLA
         m9SEZHrdmoJrba+q1TiPUmaHvxNh/td2Jv6TwZFT7ks3g+2v6IRY4iYsE/WOVA16s21c
         MbQjqYXiqENch3kDY81BDz7bf6mL419p8ZXiGxjnZ0VQ13bhpW+woBL9E56NVbh0O48n
         7QQu3L0WeX+siF557Ej4NpKYmoi9EP6KAR+1eKxe3B387yPsPYhx4uk+OHPKTjDoFnrE
         lf2TgfWm8N4oSj0LezeIkiSkq9ou62BjjTFERRV9b0cu0k9aUaKjJp9kBJ6xoXqQTp52
         xWIA==
X-Gm-Message-State: AOJu0Yz17Gw3o6gXoiKeh2bwaivssGkCTmUXBxicR3ZKW6C7nagsrSxj
	r1WntB7rpirhKI8wFLHbXQZ1aMtVI+PHX1ni0viRQSp0xIkLksOqOpkaHlSuCKZiZt1nPQGo0Rr
	C48bp620=
X-Gm-Gg: ASbGncvDau3SljdIKS0eJ+C/U1jpsWoCdEhFiuwo8o40f8+hHsCn9gIwzUmBoljv/ui
	lk0hVzHyARTI9RG1C8/qqltmi0B9XK/gveOSnzpdRA8fgSnhdmky0ZmSVDbcfIf8p8o4VlIdeFK
	IQmtW3d8wJHodNTs7/zpOaPCl6lcB1/leqfZi0vXEiT2EKWUq4mzP2klHOsN49MyN6eTqwVycPw
	Ku/4IOx54A7Ra4EQ1e6Q6GkAKmbJtZcV7tbdGnoHLjxQ55V0dVRwq0pOlCcIB5wdOIxPhrzgQMG
	wxefyDNLaXX9bgsXiX8nBY5VVCKp42qiowAFy1/NFjxY9jMvlIp1veclQMrMgxPLU9zxPYFCOmH
	Gd2/PTqE6Am5lMbF8AjGbd8beeKS+f0YbO/ejjugs/HjCn/McGhUDvmq0ye+2pAkiUNi8kGNl7m
	3RJAd0BLXXyG8O
X-Google-Smtp-Source: AGHT+IFK1Pe3+ZYgImGiwkHHpHKoJBnz9eqq7tqStkhMp5Zv+TvNnMxmS4N/sanA+hcxJlqlDcJlRA==
X-Received: by 2002:a17:907:983:b0:b04:8420:b6ef with SMTP id a640c23a62f3a-b04b16d713bmr515034466b.61.1757261724844;
        Sun, 07 Sep 2025 09:15:24 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	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 ,
	Tamas K Lengyel ,
	"Daniel P. Smith" ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott 
Subject: [PATCH v3 0/7] NUMA: Add per-node domain-memory claims
Date: Sun,  7 Sep 2025 18:15:15 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

XEN_DOMCTL_claim_memory - New Hypercall to claim memory for a domain
to improve NUMA awareness when allocating its system memory.

In tests with AMD Genoa, we achived 22% higer VM density compared
to spreading memory across all NUMA nodes for the same Speedometer
web application benchmark score, so this can enable significant
savings for server hosting (more details below).

The author of v1 is Alejandro Vallejo (he moved to AMD since).
Six months have passed, and the last review comment that I found
for it was 2 months ago.

General introduction:
---------------------

Xen supports claiming an amount of memory for a domain ahead of
allocating it to ensure that it is available for allocation.

On NUMA hosts, the same assurance is needed on a per-NUMA-node basis
to ensure optimal placement of domain memory on the correct NUMA node:

Performance test results:
-------------------------

Using "bootstorm" tests, when large VMs are booted in parallel.
Unless carefully planned, memory may be allocated on remote NUMA nodes.
It increases the memory latency experienced by applications and
degrades their performance.

NUMA claims allow for ensuring that all memory for a domain can be
allocated on the claimed NUMA node. We achieved a 15% improvement
in Speedometer performance tests and a 22% increase in VMs on AMD
Genoa while maintaining the same Speedometer score compared to
spreading the system memory of the domains across all NUMA nodes.

One out of 5 to 7 servers is not needed and could serve extra capacity.
Server and server room upgrades can be delayed, and money paid
for hosting and/or running servers can be saved.

Principle of operation:
-----------------------

Besides the NUMA node claim, host-wide exist already
and are implemented in libxl and libxenguest as well:

1. Call domain_create(); the claim is associated with this domain only.

2. Claim the needed amount of memory

   domain_set_outstanding_pages():

   - Sets d->outstanding_claims to the claimed memory
     (and with this series, also sets d->claim_node to the node)

   - Adds the new claim to per_node(outstanding_claims), with this series
   - Adds the new claim to the host-wide outstanding_claims
  
   - This prevents get_free_buddy() from allocating from NUMA nodes.
     When the amount of unclaimed memory is lower than the given request
     unless the memory is allocated for a domain with sufficient claim

3. Allocate for the domain

   alloc_heap_pages() and get_free_buddy():

   - If d->outstanding_claims is sufficient for the allocation
     (and with this series, d->claim_node matches the node the alloc from).
     Then, the allocation may continue on the node.

     domain_adjust_tot_pages() consumes part of the allocated amount:

     - Reduces d->outstanding_claims
     - Reduces per_node(outstanding_claims), with this series
     - Reduces the host-wide "outstanding_claims" variable
  
4. Cancel a possible leftover claim
5. Finish building the domain and unpause it to let it boot

We will implement multi-node claims as well, and I updated the design
to be more flexible to prepare for multi-node claims. This new hypercall
API supports multi-node claims, but the internal changes needed are
beyond what is feasible for this implementation to introduce node claims.

Overview the changes since v1:
------------------------------

Following the review's suggestion, patches should be consolidated
by the functionality they implement and not split into preparatory
changes without any function.

I agree with this change:

It makes the progression of the patches more logical to follow
as each patch serves a tangible purpose. Yes, this makes comparing
previous review comments more difficult, but the benefit of a more
consolidated series outweighs that of course.

I used Patchew (links below) to find any review comments as as some
comments were only posted 2 months ago, while the series was posted
6 months ago.

Having undergone this refactor, it may be more appropriate
to consider this submission for warranting fresh review.

More details on the changes in commits:
---------------------------------------

- #1 is new: Implemented the suggestion from review for per_node()
- #2 was new as v2#1 (moved it as here as #1 is more important)
- #3 has only minor adjustments from review and do use per_node()
- #4, has many changes and expanded comments to answer
      and explain questions that were raised while reviewing it.
      A small hunk from it was moved to #6, as it forms the basis
      of the rewritten 6/7.
- #6 was refactored with new code from v2 to fix an issue.
- #7 is unchanged after adding it in v2 as the new hypercall.

Where the old code moved:

- v1#1 is removed as the review said to remove it.
  (The #define was moved to where it is used)
- v1#2 is merged into #4 to consolidate the patches for the same code.
- v1#3 is split into #4 and #5 as per the review suggestion to move code.
- v1#4 received the parts of #5 related to staking NUMA claims.
- v1#5 was split into #3 and #4 and got the changes for adjust_tot_pages()
- v1#6 was refactored with code to fix an issue to protect the claims
- v1#7 is removed as setting the d->node_affinity
  caused Xen panics due to a locking issue (diagnosed by Roger).
  Setting d->node_affinity does not claim pages that should not have been included in the submitted series.
- v1#8 is removed as I switched to the new hypercall requested by Roger.
- v1#9-11 are removed for the same reason:

  For NUMA-node claims, we no longer pass a single NUMA node
  when we want to consume the claimed memory. Instead,
  d->node_affinity mask is already used when allocating
  by get_free_buddy(). Likewise, there is also no further
  use for claim_on_node in xl.cfg

I hope that this gives a good overview of the changes.
These are the Patchew links I used to check for review comments:

v1: https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@cloud.com/
v2: https://patchew.org/Xen/cover.1755341947.git.bernhard.kaindl@cloud.com/

Personal message:
-----------------

As I haven't posted any "hello" message yet, I think it is necessary that
I also write about myself: I worked on the Linux kernel and other things
like the SLES for S/390 and zSeries (IBM mainframe) for S.u.S.E.
Afterwards, I ported Linux (including the kernel and bootloaders) to a tested,
certified and assessed safety infrastructure that ensures your safety when
travelling by rail on tracks with track-side infrastructure built by one of
the two largest rail infrastructure companies worldwide.


Bernhard Kaindl (7):
  xen/numa: Add per_node() variables paralleling per_cpu() variables
  xen/page_alloc: Simplify domain_adjust_tot_pages() further
  xen/page_alloc: Add and track per_node(avail_pages)
  xen/page_alloc: Add staking a NUMA node claim for a domain
  xen/page_alloc: Pass node to adjust_tot_pages and check it
  xen/page_alloc: Protect claimed memory against other allocations
  xen: New hypercall to claim memory using XEN_DOMCTL_claim_memory

 tools/flask/policy/modules/dom0.te  |   1 +
 tools/flask/policy/modules/xen.if   |   1 +
 tools/include/xenctrl.h             |   4 +
 tools/libs/ctrl/xc_domain.c         |  42 +++++++
 tools/ocaml/libs/xc/xenctrl.ml      |   9 ++
 tools/ocaml/libs/xc/xenctrl.mli     |   9 ++
 tools/ocaml/libs/xc/xenctrl_stubs.c |  21 ++++
 xen/arch/arm/xen.lds.S              |   1 +
 xen/arch/ppc/xen.lds.S              |   1 +
 xen/arch/riscv/xen.lds.S            |   1 +
 xen/arch/x86/mm.c                   |   3 +-
 xen/arch/x86/mm/mem_sharing.c       |   4 +-
 xen/arch/x86/xen.lds.S              |   1 +
 xen/common/domain.c                 |  31 +++++-
 xen/common/domctl.c                 |   8 ++
 xen/common/grant_table.c            |   4 +-
 xen/common/memory.c                 |  18 ++-
 xen/common/numa.c                   |  53 ++++++++-
 xen/common/page_alloc.c             | 163 ++++++++++++++++++++--------
 xen/include/public/domctl.h         |  17 +++
 xen/include/xen/domain.h            |   2 +
 xen/include/xen/mm.h                |   5 +-
 xen/include/xen/numa.h              |  15 +++
 xen/include/xen/sched.h             |   1 +
 xen/include/xen/xen.lds.h           |   8 ++
 xen/xsm/flask/hooks.c               |   3 +
 xen/xsm/flask/policy/access_vectors |   2 +
 27 files changed, 370 insertions(+), 58 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:15:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114123.1461283 (Exim 4.92)
	(envelope-from )
	id 1uvI38-0008Pp-T4; Sun, 07 Sep 2025 16:15:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114123.1461283; Sun, 07 Sep 2025 16:15: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 1uvI38-0008Pi-Q3; Sun, 07 Sep 2025 16:15:30 +0000
Received: by outflank-mailman (input) for mailman id 1114123;
 Sun, 07 Sep 2025 16:15: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 1uvI37-0008Bo-Cg
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:15:29 +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 dec10a8d-8c05-11f0-9d13-b5c5bf9af7f9;
 Sun, 07 Sep 2025 18:15:29 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-afcb7a16441so539136666b.2
 for ; Sun, 07 Sep 2025 09:15:29 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.15.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:15: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: dec10a8d-8c05-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261728; x=1757866528; darn=lists.xenproject.org;
        h=content-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=UXFQDBB6LNVrlSbSbsw2cgbvIju27z1SvRMin6hDLRc=;
        b=V5OR4Hpa9L48OaH7msaicdAZ0GfBmbBpf7uQNSv4XR0OTyhF8MFSWrHcqC8f0rItdm
         AkllrfoAXiuidGEiHffOmxVMOFy1hZLNGT5QHUgCdjGscIlNhcDq8O+ca8B8OWy/3Aki
         lmkm1c9VvEqUHXjX63L+6O+Hfo+sBXFZmpuXk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261728; x=1757866528;
        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=UXFQDBB6LNVrlSbSbsw2cgbvIju27z1SvRMin6hDLRc=;
        b=jVuJd35+PRqJLKc0pdhjmFG8teZH0MGcYzYH3okqi4MfbX2Kja5yVywGqxgTKDY97x
         mfQ9H7Gbv6b40od/qq4XlXpxuJHnY+0opH3yzwBQ+N8rX8oBN7yvWAI8Wxk3ru5VlGHE
         4pSvjFpIcZu0m8Ks3Ott3mudSM30x0zcN22J+qsFfCo3vkCSI6RCx8/G5DRWz5wcdOV6
         UanCRC2YrI8ZgFLm3enrsTmRiIVrSaILo0QCjrnMBm/x7dzQIYRvG5+9EEiJeZolCEdi
         Jxv2rH1SQt/Np4+KJCG/BkDwYVuCrcxQOK1D/8OMVFuNmAbJB1SbpKBPVFs+kwjKuIwb
         iE/Q==
X-Gm-Message-State: AOJu0YzE7NgBxFqrgjBQMaOPaMI3UK4W1YJ+FbLLbL3D1IEwKCllEkuP
	XErlwzzA8gzY4Ygk9v215yuezaELrjIoIYC+3QFBQl443e02/XVZsBtaC1z3KcGW3pbDvTtZfI8
	tAay7WBo=
X-Gm-Gg: ASbGncuybRQ3dlzsKy0c3rdW3UlpvvUmq/8mMKFUybXFKgMTtyXIzvWUs7/jigsWLAk
	JEyWeELBPaoyGjQpPQCrOnMW5/GeAkyx4qm57JbVbLL4v+adRGSuTWwGcnpFtJ7uGxS7RR9OjBH
	cXwgIj2W4oWps6Xsa5BnPApxjlxz7oO/LQC8ov3Y9+kQ5XOPSx8gSbLuOhe6jXgzvYwiVaKvtKQ
	HSSDkiJXX0u+g/bF70L9FZDbo8qK1KbdYjTEEW5qNJXHa9gYdi8WFeYa9CGc0ZWz6l5GUu9em1t
	i/BPFUeA/oHwNtBhv+BRJmWvrcxN+FbGAbP3mU7W1fpoBGjflTkCVF6pBUwxQcXgtSw5Jkd6riW
	Iydr6pt7aHVGd838R8U2X0tdUcXFsctifOt6/G0Rakj77HCQwAs6c709aJ8CdTuQvX0+vNlZPuY
	DrGA==
X-Google-Smtp-Source: AGHT+IHuGGshBE11UswiTAVCGXRupZTuoOG9Ht4DWbahk+TZ+ISigvCdYg80rgu+VSa57mx1WUdvqg==
X-Received: by 2002:a17:907:3f21:b0:afc:cc64:86da with SMTP id a640c23a62f3a-b04b14f5015mr511931166b.26.1757261728217;
        Sun, 07 Sep 2025 09:15:28 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 3/7] xen/page_alloc: Add and track per_node(avail_pages)
Date: Sun,  7 Sep 2025 18:15:18 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Alejandro Vallejo 

The static per-NUMA-node count of free pages is the sum of free memory
in all zones of a node. It's an optimisation to avoid doing that operation
frequently in the following patches that introduce per-NUMA-node claims.

Signed-off-by: Alejandro Vallejo 
Signed-off-by: Bernhard Kaindl 

---
Changes in v2:
- Added ASSERT(per_node(avail_pages, node) >= request) as requested
  during review by Roger: Comment by me: As we have

  ASSERT(avail[node][zone] >= request);

  directly before it, the request is already valid, so this checks
  that per_node(avail_pages, node) is not mis-accounted too low.

Changes in v3:
- Converted from static array to use per_node(avail_pages, node)
---
 xen/common/page_alloc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index e056624583..b8acb500da 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -486,6 +486,10 @@ static unsigned long node_need_scrub[MAX_NUMNODES];
 static unsigned long *avail[MAX_NUMNODES];
 static long total_avail_pages;
 
+/* Per-NUMA-node counts of free pages */
+DECLARE_PER_NODE(unsigned long, avail_pages);
+DEFINE_PER_NODE(unsigned long, avail_pages);
+
 static DEFINE_SPINLOCK(heap_lock);
 static long outstanding_claims; /* total outstanding claims by all domains */
 
@@ -1074,6 +1078,8 @@ static struct page_info *alloc_heap_pages(
 
     ASSERT(avail[node][zone] >= request);
     avail[node][zone] -= request;
+    ASSERT(per_node(avail_pages, node) >= request);
+    per_node(avail_pages, node) -= request;
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
@@ -1234,6 +1240,8 @@ static int reserve_offlined_page(struct page_info *head)
             continue;
 
         avail[node][zone]--;
+        ASSERT(per_node(avail_pages, node) > 0);
+        per_node(avail_pages, node)--;
         total_avail_pages--;
         ASSERT(total_avail_pages >= 0);
 
@@ -1558,6 +1566,7 @@ static void free_heap_pages(
     }
 
     avail[node][zone] += 1 << order;
+    per_node(avail_pages, node) += 1 << order;
     total_avail_pages += 1 << order;
     if ( need_scrub )
     {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:15:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114125.1461298 (Exim 4.92)
	(envelope-from )
	id 1uvI3B-0000Hj-El; Sun, 07 Sep 2025 16:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114125.1461298; Sun, 07 Sep 2025 16:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvI3B-0000HI-A4; Sun, 07 Sep 2025 16:15:33 +0000
Received: by outflank-mailman (input) for mailman id 1114125;
 Sun, 07 Sep 2025 16:15: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 1uvI39-00009z-WC
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:15:32 +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 de1eaa83-8c05-11f0-9809-7dc792cee155;
 Sun, 07 Sep 2025 18:15:27 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b04b869abb9so149718866b.1
 for ; Sun, 07 Sep 2025 09:15:27 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.15.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:15: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: de1eaa83-8c05-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261727; x=1757866527; darn=lists.xenproject.org;
        h=content-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=PTaeCc0jJZ6v4SiJ+F55XnFvKWiZFrzoLZItww1E4jk=;
        b=PLN5XU9236vTRSXxf7AxvIsH1VkzJekntmRLSYgdMzlznr/lrxrb80EFEJXDdzhenk
         E/kXwI0bEbUQ/n6669oUhU6OCrHfM2oMs+bxD2WOzg6p/UZoB7q39ta0lCFfq9DNq0uZ
         3X54wqcL6JdqvbxBI+tib5bSyaACGO3zVConY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261727; x=1757866527;
        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=PTaeCc0jJZ6v4SiJ+F55XnFvKWiZFrzoLZItww1E4jk=;
        b=OcxMg/4cMolaInqKr2DFPwnAN2pRsLcFO0ps0stJwWutwMLvmbHSvsJfBoHYWT9oiF
         in83eABDiXtbLkQVK72ZTpXtHraszwpO5u8K44WXFMTSov6e400T2yRM5AW30O5tUjJV
         zz1iU/oYRGt3X2tqy2UtIK7SDGPtbdpQejRByT7VmgShAgqDvvZ/I7vFW81Ijn97odOK
         ii1R0v8Ahl7WWYtfhCvPgXW3pcvM2BxXLhy8OuWFUXMFdNHrEDsrjdiEuTwOwJKvmcrb
         OWW2FDq948FdxqG0Jj25LKJrl0xnkPFID9XQAE7813B86UBvJCRIBxMutNRMCCiRTb65
         VB/Q==
X-Gm-Message-State: AOJu0YyyHjrxkGWJjWMUAHUomUB08fal8dw+iLBkiAstKLDErhF89pqG
	vhwxUzjmjm3aFSiaF4J2XNuy/74z9GwuKWd1FdaKp2HBb1N6TADyIKdj3m/vqB6N1TD01kTDWt6
	aYLkTivE=
X-Gm-Gg: ASbGncssaNeR0KuoroW7tfBb4xTqo0jz2XffUjWHrWLwuniwuktsXVX+qyBUAbbFvGZ
	Iva+2KCZGe4BFlpSlY/5nm74IQALnIeko1/tXN6KqtqwxLEL7q3QubagPhMTrtkZaGOmh2Eh1xk
	NivjA4aNoFfDDSgT5l7xHF6Guo6oUMMQdpUYU4pp3x/QcKkR+7qWNAPPRO4BsiMGllK3GKfR2Ca
	X3SzEtjvq0q8jNyEXQ7zI0TCosbqIRJGvd5FilRSLhy5CaKIiV7nQgG07sdp5R2/jy+js+LFMHx
	wk2kLxk4D1xwP0pyHm/apmdAASwFAxUs1qshtyYCmvNvD3M8OjKa7U53aPEJOS4CBPlT1dMRBHF
	VopplWXvaN5HNWAEatJ6RjSTiDhxWYaqZ9amxjwonUccWHE7fbTw7VGzVxhOC7MTFutI=
X-Google-Smtp-Source: AGHT+IGQR9/J0pflFoZP8fpXWuEulGdjHQl4gGCXU4y13Rc3B7e+E6dWfnhdFZpDe8pf22mP59uS4g==
X-Received: by 2002:a17:906:99c5:b0:b04:848f:a0b7 with SMTP id a640c23a62f3a-b04b1663cb3mr468611066b.41.1757261727086;
        Sun, 07 Sep 2025 09:15:27 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [PATCH v3 2/7] xen/page_alloc: Simplify domain_adjust_tot_pages() further
Date: Sun,  7 Sep 2025 18:15:17 +0200
Message-ID: <15ae395c6933e74da0cdd8f9d71d349a7bfad3f3.1757261045.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When domain memory is allocated, domain_adjust_tot_pages(),
also reduces the outstanding claim.

Replace the checks to not over-reduce the claim beyond 0
by using min() which prevents the claim to become negative
(and also not be over-conumed for the node and globally)

Cc: Jan Beulich 
Signed-off-by: Bernhard Kaindl 

---
Changes:
- Was added as 2/7 in v2, the review by Jan Beulich is applied.
---
 xen/common/page_alloc.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1f67b88a89..e056624583 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -510,8 +510,15 @@ static unsigned long avail_heap_pages(
     return free_pages;
 }
 
+/*
+ * Update the total number of pages and outstanding claims of a domain.
+ * - When pages were freed, we do not increase outstanding claims.
+ * - On a domain's claims update, global outstanding_claims are updated as well.
+ */
 unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
 {
+    unsigned long adjustment;
+
     ASSERT(rspin_is_locked(&d->page_alloc_lock));
     d->tot_pages += pages;
 
@@ -519,23 +526,22 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
      * 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 the domain has no outstanding claims (or we freed pages instead),
+     * we don't update outstanding claims and skip the claims adjustment.
      */
     if ( !d->outstanding_pages || pages <= 0 )
         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. */
-        outstanding_claims -= d->outstanding_pages;
-        d->outstanding_pages = 0;
-    }
-    else
-    {
-        outstanding_claims -= pages;
-        d->outstanding_pages -= pages;
-    }
+    /*
+     * Reduce claims by outstanding claims or pages (whichever is smaller):
+     * If allocated > outstanding, reduce the claims only by outstanding pages.
+     */
+    adjustment = min(d->outstanding_pages + 0UL, pages + 0UL);
+    d->outstanding_pages -= adjustment;
+    outstanding_claims -= adjustment;
     spin_unlock(&heap_lock);
 
 out:
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:17:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:17:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114166.1461323 (Exim 4.92)
	(envelope-from )
	id 1uvI4i-0002H4-Fj; Sun, 07 Sep 2025 16:17:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114166.1461323; Sun, 07 Sep 2025 16:17: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 1uvI4i-0002Gx-CA; Sun, 07 Sep 2025 16:17:08 +0000
Received: by outflank-mailman (input) for mailman id 1114166;
 Sun, 07 Sep 2025 16:17: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 1uvI4g-0002Gl-UL
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:17:07 +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 17f8bfc5-8c06-11f0-9809-7dc792cee155;
 Sun, 07 Sep 2025 18:17:05 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-afcb7ae31caso616594566b.3
 for ; Sun, 07 Sep 2025 09:17:05 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.16.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:17: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: 17f8bfc5-8c06-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261824; x=1757866624; darn=lists.xenproject.org;
        h=content-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=6FiQwP0VdUGmMFkU0uIYAV7JnXqoktiIQH9nuSROebE=;
        b=NMW6bFbACu43o7wvBgzu33iydiwRwevxL/DzodDQONkl39IhPYtKpC6KbfiDq2r+1J
         6gpiveF/YsP90HxaV2kTAnqdm9UxLGOBCrw66FgkKbhXPd1Htt5Qb8u2E2vuZnpRngBq
         5sALD2zbaGX8qfd/ZiZeiH4WRA5u1T9hU/d+k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261824; x=1757866624;
        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=6FiQwP0VdUGmMFkU0uIYAV7JnXqoktiIQH9nuSROebE=;
        b=FvRYSUKHmRlRJiVuHCsKNUS2IBQZ5/fv+XyIo+yoNxk8uszgGJ5kSuD6hjPqCk3W2J
         mw5M6afPNx5IC/qg1dGeg65r2urHOm11u5Mw/SW9+XbjXm5mFNPpAT4/9meYvS0AhWuw
         eXGz4PbtsrWUjwkKaZEQsUUAkMK7wbCE4pM/9hsbIvTAnA6tuBPe2me6TYiH+w2Hi+3o
         6zpdIVfcROjYbqQ+XYRlRv+IGNkQGYiQfKayfXdWXZXX8+OpGMQMkPoMrb0AyVmwj2gD
         eGABnwjIP/B6Yq2VfbxAJwCmxX8Ce92MD++xkS/lsy9h6C5zFi8UkcvQ9TH9tSCbZsaZ
         vCvA==
X-Gm-Message-State: AOJu0YyPnr+BUy2rf7jJeebbmfOz9EgbCMldQRR3anuZbKPmAj+0bH6P
	Vhmwh+TsY6hsvXD6nXs1dO3D1INeV1x9wx8Zntoa2JgGv4Wt4biOGN2GIcW9jSsP+Kf2hk6keSO
	xlcsCmwE=
X-Gm-Gg: ASbGncv4HhjyGMrIYccHjLVTgfpFluru0d1UXWBrmUIoRpAoAiZz4hKR+QgJz/JPx7+
	SXV+U7j1n8ayZA9PPqknyTCl6dyvT1oekukq3oqxVJNiQe1e+wpDBr3rwCFN/Sg35uHXZFrFJj7
	71mRHDRCXcZJtRdYZInJbIOTaaxvSXfRXAXbRx5t6TJ85Dkc3ZhPAuQKx8g0esqTAYgj+tMt4Pk
	vkO4vsqJn5SOb7wytfMuM2Lu+nz2dJBWcGFrYdAGfS65N7jLP/lPO4gd2fzOnHs41oV1TwRuSX2
	nAjjBqkvVbtYzmmHzM6ZTjkNpa0x8J5EkNs6vsOv95s8uXfUPES6YNiMRnhzT4dgKEEk2pamMVU
	hebjqBNLdczpz0oakyeQVPdgg8Mfl4zfAhqDlnjAX0h8ysrzV/PUo//USCM9PQPJSQnQ=
X-Google-Smtp-Source: AGHT+IHQ41CzQUwsGmIiJ1de/f1zmmWKWPxtBh6Y9WUIDTwFCa8uQ+VvzK+oXvx3Q1NVWFYCh8wBSw==
X-Received: by 2002:a17:907:6d0d:b0:b04:ae7c:703e with SMTP id a640c23a62f3a-b04b140a770mr473628766b.24.1757261823683;
        Sun, 07 Sep 2025 09:17:03 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	"Daniel P. Smith" ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott 
Subject: [PATCH v3 7/7] xen: New hypercall to claim memory using XEN_DOMCTL_claim_memory
Date: Sun,  7 Sep 2025 18:15:22 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the new hypercall requested during the review of the v1 series
do not require changing the API for multi-node claims.

The hypercall receives a number of claims, intented to be one claim per
NUMA node, and limited to one claim for now. The changes to update the
NUMA claims management to handle updating the claims for multiple
NUMA nodes of a domain at once are deferred to the next series.

Cc: Alejandro Vallejo 
Signed-off-by: Bernhard Kaindl 

---
Changes in v3:
- As a review to check nr_claims to be > 0 (but uint = superflous),
  but to avoid a raised eyebrow, add "> 0", which the compiler will
  optimise away anyway.
---
 tools/flask/policy/modules/dom0.te  |  1 +
 tools/flask/policy/modules/xen.if   |  1 +
 tools/include/xenctrl.h             |  4 +++
 tools/libs/ctrl/xc_domain.c         | 42 +++++++++++++++++++++++++++++
 tools/ocaml/libs/xc/xenctrl.ml      |  9 +++++++
 tools/ocaml/libs/xc/xenctrl.mli     |  9 +++++++
 tools/ocaml/libs/xc/xenctrl_stubs.c | 21 +++++++++++++++
 xen/common/domain.c                 | 29 ++++++++++++++++++++
 xen/common/domctl.c                 |  8 ++++++
 xen/include/public/domctl.h         | 17 ++++++++++++
 xen/include/xen/domain.h            |  2 ++
 xen/xsm/flask/hooks.c               |  3 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 13 files changed, 148 insertions(+)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index ad2b4f9ea7..8801cb24f2 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -105,6 +105,7 @@ allow dom0_t dom0_t:domain2 {
 	get_cpu_policy
 	dt_overlay
 	get_domain_state
+	claim_memory
 };
 allow dom0_t dom0_t:resource {
 	add
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index ef7d8f438c..8e2dceb505 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -98,6 +98,7 @@ define(`create_domain_common', `
 		vuart_op
 		set_llc_colors
 		get_domain_state
+		claim_memory
 	};
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 965d3b585a..43ece3f2a7 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2660,6 +2660,10 @@ int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
                              const uint32_t *llc_colors,
                              uint32_t num_llc_colors);
 
+int xc_domain_claim_memory(xc_interface *xch, uint32_t domid,
+                           uint32_t nr_claims,
+                           const memory_claim_t *claims);
+
 #if defined(__arm__) || defined(__aarch64__)
 int xc_dt_overlay(xc_interface *xch, void *overlay_fdt,
                   uint32_t overlay_fdt_size, uint8_t overlay_op);
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index 2ddc3f4f42..e022b76430 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -2229,6 +2229,48 @@ out:
 
     return ret;
 }
+
+/*
+ * Claim memory for a domain. A Domain can only have one type of claim:
+ *
+ * If the number of claims is 0, existing claims are cancelled.
+ * Updating claims is not supported, cancel the existing claim first.
+ *
+ * Memory allocations consume the outstanding claim and if not enough memory is
+ * free, the allocation must be satisfied from the remaining outstanding claim.
+ */
+int xc_domain_claim_memory(xc_interface *xch, uint32_t domid,
+                           uint32_t nr_claims,
+                           const memory_claim_t *claims)
+{
+    struct xen_domctl domctl = {
+        .cmd = XEN_DOMCTL_claim_memory,
+        .domain = domid,
+        .u.claim_memory.nr_claims = nr_claims,
+    };
+    int ret;
+    DECLARE_HYPERCALL_BUFFER(struct xen_domctl_claim_memory, buffer);
+
+    /* Use an array to not need changes for multi-node claims in the future */
+    if ( nr_claims > 0 )
+    {
+        size_t bytes = sizeof(memory_claim_t) * nr_claims;
+
+        buffer = xc_hypercall_buffer_alloc(xch, buffer, bytes);
+        if ( buffer == NULL )
+        {
+            PERROR("Could not allocate memory for xc_domain_claim_memory");
+            return -1;
+        }
+        memcpy(buffer, claims, bytes);
+        set_xen_guest_handle(domctl.u.claim_memory.claims, buffer);
+    }
+
+    ret = do_domctl(xch, &domctl);
+    xc_hypercall_buffer_free(xch, buffer);
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 97108b9d86..c8692fb169 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -370,6 +370,15 @@ external domain_deassign_device: handle -> domid -> (int * int * int * int) -> u
 external domain_test_assign_device: handle -> domid -> (int * int * int * int) -> bool
   = "stub_xc_domain_test_assign_device"
 
+type claim =
+  {
+    node: int;
+    nr_pages: int64;
+  }
+
+external domain_claim_memory: handle -> domid -> int -> claim array -> unit
+  = "stub_xc_domain_claim_memory"
+
 external version: handle -> version = "stub_xc_version_version"
 external version_compile_info: handle -> compile_info
   = "stub_xc_version_compile_info"
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 9fccb2c2c2..82d59fc80d 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -297,6 +297,15 @@ external domain_deassign_device: handle -> domid -> (int * int * int * int) -> u
 external domain_test_assign_device: handle -> domid -> (int * int * int * int) -> bool
   = "stub_xc_domain_test_assign_device"
 
+type claim =
+  {
+    node: int;
+    nr_pages: int64;
+  }
+
+external domain_claim_memory: handle -> domid -> int -> claim array -> unit
+  = "stub_xc_domain_claim_memory"
+
 external version : handle -> version = "stub_xc_version_version"
 external version_compile_info : handle -> compile_info
   = "stub_xc_version_compile_info"
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c b/tools/ocaml/libs/xc/xenctrl_stubs.c
index ac2a7537d6..53f56c5437 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -1435,6 +1435,27 @@ CAMLprim value stub_xc_watchdog(value xch_val, value domid, value timeout)
 	CAMLreturn(Val_int(ret));
 }
 
+/* Claim memory for a domain. See xc_domain_claim_memory() for details. */
+CAMLprim value stub_xc_domain_claim_memory(value xch_val, value domid,
+                                           value num_claims, value desc)
+{
+	CAMLparam4(xch_val, domid, num_claims, desc);
+	xc_interface *xch = xch_of_val(xch_val);
+	int i, retval, nr_claims = Int_val(num_claims);
+	memory_claim_t claim[nr_claims];
+
+	for (i = 0; i < nr_claims; i++) {
+		claim[i].node = Int_val(Field(desc, i*2));
+		claim[i].nr_pages = Int64_val(Field(desc, i*2 + 1));
+	}
+
+	retval = xc_domain_claim_memory(xch, Int_val(domid), nr_claims, claim);
+	if (retval < 0)
+		failwith_xc(xch);
+
+	CAMLreturn(Val_unit);
+}
+
 /*
  * Local variables:
  *  indent-tabs-mode: t
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6ee9f23b10..39f1c3718c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -267,6 +267,35 @@ int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
     return rc;
 }
 
+/* XEN_DOMCTL_claim_memory: Claim an amount of memory for a domain */
+int claim_memory(struct domain *d, const struct xen_domctl_claim_memory *uinfo)
+{
+    memory_claim_t claim;
+    int rc;
+
+    switch ( uinfo->nr_claims )
+    {
+        case 0:
+            /* Cancel existing claim. */
+            rc = domain_claim_pages(d, 0, 0);
+            break;
+
+        case 1:
+            /* Only single node claims supported at the moment. */
+            if ( copy_from_guest(&claim, uinfo->claims, 1) )
+                return -EFAULT;
+
+            rc = domain_claim_pages(d, claim.node, claim.nr_pages);
+            break;
+
+        default:
+            rc = -EOPNOTSUPP;
+            break;
+    }
+
+    return rc;
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 71e712c1f3..cf9537b02c 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -863,6 +863,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
         break;
 
+    case XEN_DOMCTL_claim_memory:
+        ret = xsm_claim_pages(XSM_PRIV, d);
+        if ( ret )
+            break;
+
+        ret = claim_memory(d, &op->u.claim_memory);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8f6708c0a7..1cebbb878e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1276,6 +1276,21 @@ struct xen_domctl_get_domain_state {
     uint64_t unique_id;      /* Unique domain identifier. */
 };
 
+struct xen_memory_claim {
+    unsigned int node;      /* NUMA node, XC_NUMA_NO_NODE for a host claim */
+    unsigned long nr_pages; /* Number of pages to claim */
+};
+typedef struct xen_memory_claim memory_claim_t;
+DEFINE_XEN_GUEST_HANDLE(memory_claim_t);
+
+/* XEN_DOMCTL_claim_memory: Claim an amount of memory for a domain */
+struct xen_domctl_claim_memory {
+    /* IN: array of memory claims */
+    XEN_GUEST_HANDLE_64(memory_claim_t) claims;
+    /* IN: number of claims */
+    unsigned int nr_claims;
+};
+
 struct xen_domctl {
 /* Stable domctl ops: interface_version is required to be 0.  */
     uint32_t cmd;
@@ -1368,6 +1383,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_gsi_permission                88
 #define XEN_DOMCTL_set_llc_colors                89
 #define XEN_DOMCTL_get_domain_state              90 /* stable interface */
+#define XEN_DOMCTL_claim_memory                  91
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1436,6 +1452,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_llc_colors    set_llc_colors;
         struct xen_domctl_get_domain_state  get_domain_state;
+        struct xen_domctl_claim_memory      claim_memory;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 8aab05ae93..cd3e933fbf 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -195,4 +195,6 @@ extern bool vmtrace_available;
 
 extern bool vpmu_is_available;
 
+int claim_memory(struct domain *d, const struct xen_domctl_claim_memory *uinfo);
+
 #endif /* __XEN_DOMAIN_H__ */
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index b0308e1b26..6b2535b666 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -853,6 +853,9 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_set_llc_colors:
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_LLC_COLORS);
 
+    case XEN_DOMCTL_claim_memory:
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CLAIM_MEMORY);
+
     default:
         return avc_unknown_permission("domctl", cmd);
     }
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 51a1577a66..87338b5c2a 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -259,6 +259,8 @@ class domain2
     set_llc_colors
 # XEN_DOMCTL_get_domain_state
     get_domain_state
+# XEN_DOMCTL_claim_memory
+    claim_memory
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:20:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:20:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114194.1461344 (Exim 4.92)
	(envelope-from )
	id 1uvI8K-0004JQ-DA; Sun, 07 Sep 2025 16:20:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114194.1461344; Sun, 07 Sep 2025 16: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 1uvI8K-0004JB-8V; Sun, 07 Sep 2025 16:20:52 +0000
Received: by outflank-mailman (input) for mailman id 1114194;
 Sun, 07 Sep 2025 16:20:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvI42-00009z-Nd
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:16:26 +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 00344c93-8c06-11f0-9809-7dc792cee155;
 Sun, 07 Sep 2025 18:16:25 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b046f6fb230so604182166b.1
 for ; Sun, 07 Sep 2025 09:16:25 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.16.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:16: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: 00344c93-8c06-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261784; x=1757866584; darn=lists.xenproject.org;
        h=content-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=vBTzAM9dJn/x75BZsxvktFF5ekUsBrdK+iYKuv7j92Y=;
        b=Ehd7Nxq1zVQLYJAv33FDslPZN7BVOQLT/G0L4euiksG3FNcFkQ0utT+d1mf0dMLsEV
         K+1SeIu2+IakYyBvM2k+6mlxir91mMcQORLcJFiiv9AnAmuUKlVmeap/+Vttj6g1U1lr
         lKvqmT0A24Yf+zGEXN7UtgGI8nRpelsjoMgVI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261784; x=1757866584;
        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=vBTzAM9dJn/x75BZsxvktFF5ekUsBrdK+iYKuv7j92Y=;
        b=iE9jbJd4dFA8ve0fXZfkI8An9z9BfuMcS+SEukz2Qdg58X90CMSluIDRO36NqBBxNi
         vhJvpCJQX/FcXvb6k1TYLtO/0YPjie0DJCE7TVsGMZT7hpgCXRK8CRPaFOQgI1UuKNiU
         oZOTpbZqUWX+j5TfCmXp2PKX0TGMZV+MK+IWez3rN+9nDRs/U18rKYf+oiovXZAgYbhG
         ZHpNdelNolHE8XmoAlT8/afMq5x3KVLSGNPPJllaWNZG2orbekyUDxmKjd4gKP26JBB2
         UVsLarcyHYJR4rPGbD4QEnHvmHDSEwUvJOt6prIDKe/2RD8KQ4R7MBA2wPSWfjKg+G1J
         11Fg==
X-Gm-Message-State: AOJu0Yzj3jBlSERwNX7qLmAyMKapd0SNaBJFsqFegjbpbvewly0n2SkR
	QB5skVRTa9Db4fq/wlqWizs8nFpH28zui2bp9ImyjzsOAUqKG0qHBmr+g8Gnn2mR8vtuXaEwY2m
	n047UIUY=
X-Gm-Gg: ASbGncsIzNlbmovo48jc4vgobIdQjBp/ENa1qIfqAqCGLX1do5k+d+tPvl1zMQW8zAY
	BmF39m30e+LwuiTmdzcV82ACHWj47JlK/GoOhGi4ZdZvf0ckv1r4KJNowS2pecXnfFTPVICG2A8
	jpbZT1v35Rfnjl1+Oe0vKKVxro2AvkOGklQV3r6U9kozVxQfyKGvqtEvMVmMOWYicpeAvx93oNv
	vJEaeiqmO5VvH3wPnUqtr7tIVKbstKxYtp/CoZvHjBfa537elEgQcRn01LSxoqwYSR9E0KxQSqi
	ok/9cRCpfnp5LpDQsypQ2b9O1lk7C8ODcYSt34AxNTJfmNpuJQcb+kekGQ4zJzT1U8zMVJHz6AN
	8uPbQT9YVH1v51fgyj276vGNienp97C60TBWymEvfl5cUnwJ3KeEIbwznHcbLf9hEvUMsZdybBw
	k4iA==
X-Google-Smtp-Source: AGHT+IFNkJmollUYz0E9myq+0ab1Fzt9pFOg5uIHhtER2VpUj1FgGRJDBcAtjSl+tX9M37Qw/YC6FA==
X-Received: by 2002:a17:907:805:b0:afe:94d7:7283 with SMTP id a640c23a62f3a-b04932a2452mr1010424466b.32.1757261784279;
        Sun, 07 Sep 2025 09:16:24 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 6/7] xen/page_alloc: Protect claimed memory against other allocations
Date: Sun,  7 Sep 2025 18:15:21 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Extend get_free_buddy() to only allocate from nodes with enough
unclaimed memory left, unless the allocation is made by a domain
with sufficient claims on this node to cover the allocation.

Signed-off-by: Marcus Granado 
Signed-off-by: Alejandro Vallejo 
Signed-off-by: Bernhard Kaindl 

---
Changes in v3:

Rewritten based on a check by Marcus Granado which needs to be inside
the NUMA node loop of get_free_buddy() to only allow it to allocating
from NUMA nodes with enough unclaimed memory.

It was originally only intented for when looping over all NUMA nodes,
but the check also needs to be done when falling back to other nodes:

I updated the check to be generic: Now, it used for all requests by
integrating the check of the claim of the domain from Alejandro's
can_alloc() helper into it.

This fixes the issue that when falling back from a nodemask to allocate
from (based on MEMF_get_node(memflags) or from d->node_affinity):

When falling back to other NUMA nodes, still only allocate from nodes
with enough unclaimed memory left, unless the allocation is made by
a domain with sufficient claims on this node to cover the allocation.

This makes the can_alloc() helper function obsolete, as the needed
checks are done for the NUMA nodes as they are considered, not only
for the orignally requested NUMA node (not just before searching).
---
 xen/common/page_alloc.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index ebf41a1b33..b866076b78 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -980,9 +980,19 @@ static struct page_info *get_free_buddy(unsigned int zone_lo,
     {
         zone = zone_hi;
         do {
-            /* Check if target node can support the allocation. */
-            if ( !avail[node] || (avail[node][zone] < (1UL << order)) )
-                continue;
+            unsigned long request = 1UL << order;
+            /*
+             * Check if this node is currently suitable for this allocation.
+             * 1. It has sufficient memory in the requested zone and the
+             * 2. request must fit in the unclaimed memory of the node minus
+             *    outstanding claims, unless the allocation is made by a domain
+             *    with sufficient node-claimed memory to cover the allocation.
+             */
+            if ( !avail[node] || (avail[node][zone] < request) ||
+                 (insufficient_memory(node, request) &&
+                  (!d || node != d->claim_node ||     /* a domain with claims */
+                   request > d->outstanding_pages)) ) /* claim covers request */
+                continue;  /* next zone/node if insufficient memory or claims */
 
             /* Find smallest order which can satisfy the request. */
             for ( j = order; j <= MAX_ORDER; j++ )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 16:20:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 16:20:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114188.1461334 (Exim 4.92)
	(envelope-from )
	id 1uvI8I-00043b-50; Sun, 07 Sep 2025 16:20:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114188.1461334; Sun, 07 Sep 2025 16: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 1uvI8H-00043U-Vy; Sun, 07 Sep 2025 16:20:49 +0000
Received: by outflank-mailman (input) for mailman id 1114188;
 Sun, 07 Sep 2025 16: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 1uvI41-00009z-NJ
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 16:16:25 +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 ffa40c74-8c05-11f0-9809-7dc792cee155;
 Sun, 07 Sep 2025 18:16:24 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b04b869abb9so149781466b.1
 for ; Sun, 07 Sep 2025 09:16:24 -0700 (PDT)
Received: from MinisforumBD795m.phoenix-carat.ts.net
 ([2a02:1748:f7df:8cb1:5474:d7c3:6edd:e683])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b047b61cf00sm908263766b.15.2025.09.07.09.15.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 07 Sep 2025 09:16: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: ffa40c74-8c05-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757261783; x=1757866583; darn=lists.xenproject.org;
        h=content-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=kxqBH4UoXF5zKcyV4oRkehvh5BG1QBuBGrUOn4bw4TQ=;
        b=BaMyCOjDkwGZ2u73dbJ7SgDKbTt37YCQOSWkDjTDW/EGETYm2x8weqpPjSDcgHnSyz
         BIz77+tfhymkXZusWhxoBn31kwQo3DOc8PuPyfTOg8MK0DUFw1fzT35BJ/AZwi2Z4X3K
         lxiHHHwRlCBKjpmCV5Gkr+r0wvRtnZj3sjqMU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757261783; x=1757866583;
        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=kxqBH4UoXF5zKcyV4oRkehvh5BG1QBuBGrUOn4bw4TQ=;
        b=VkHOKXqVAIEm2BQI5wdYdUIFvFzxJq59IaW8fNcgZlU7wsdlBnqjrNC2vn4miyylnj
         SEYnEmw1UWcUU4jbqTVzAslL1u4ZF8KRPYpYq5gA4oksgo2puMzf8F6guCMz3QEtwX7T
         SyoYLIjAfOgz8DqRhQgsW0LzbQzxt7mkceIcnUdHePByuu0x1E+bWpJEYEtAhoGV57/H
         wRUGC3fW8la9vqXHix3xxlPwswtMkgBx+O68rhBpvnL1pgAi+QbuM9y4UIssasMm+6eB
         YB9Dyne7vTO1fcwQ4K6dL/cNoPp4Xxeh67KzzvlX7CVPRZkW8B/iGKvvjhXz8tZ38c6T
         BrtQ==
X-Gm-Message-State: AOJu0Yzp6qpredsVDAGtxLNT7TTH82gyb7ddFnGaNqlvsHDHxu+4L5bU
	BefLffoBfXYN4YWkqftM90NHj2zEOysPALUQmyUnzqVlA0e5atAoZGA87ovrAj7hSQjNPLDysLL
	HvEZVkTk=
X-Gm-Gg: ASbGnctTPup+qfU4eopObUYAO5dl7hrPdQCs/CqY+9LBKAzck5JAt8J9R+91kTCBmhb
	Vmz1CRIUhJ9mVdl35Ow/3oYo+Js0Moz7061TrsOlpaObR4S27iKHYXTqTwJCa8OP1t725Cl8BxK
	TrcQTAHnJ8oDRwaHoX+Glzwu4qF1augqeAjBJ+e8DPIwOGZxlC093YQ6sPWMIwOGrp9PmH3zM05
	v/qBfkDWv1MBsgFa+PIiVyS9iH+AFieb9Zj3fEtPoT7jCOqDgzvYWWjKS2VuCaZxUgVNjqu+Xsb
	G16Gp3ObCnPa2SwYjbF+V7QPq/a0/ut388Uyv4qAqPaUGO31pn8qkP7OSwk0ANhozaQ66sziKM2
	2o6MWhFPM26bE+v0Ry7PjAL7N3tU31vbJJLiYy4kQ5op8hbwuYT2GFmK3C3/c0PgwGbFybQaloG
	3XZA==
X-Google-Smtp-Source: AGHT+IGHe1uaFOFNYQ4DJtikarPhM2GREyUd/9dIGycR1RQtQQeD3n91MRtwwnizdTXOOCUvQtLQmw==
X-Received: by 2002:a17:906:d54b:b0:b04:53cc:4400 with SMTP id a640c23a62f3a-b04b14a198emr528981066b.27.1757261783273;
        Sun, 07 Sep 2025 09:16:23 -0700 (PDT)
From: Bernhard Kaindl 
To: xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
	Bernhard Kaindl ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Tamas K Lengyel 
Subject: [PATCH v3 5/7] xen/page_alloc: Pass node to adjust_tot_pages and check it
Date: Sun,  7 Sep 2025 18:15:20 +0200
Message-ID: <80adbc587f6acf6bae05bf66016ffecb532f8877.1757261045.git.bernhard.kaindl@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

domain_adjust_tot_pages() consumes remaining claims as pages
are allocated, now also from the claimed node.

Update it to skip consuming the outstanding claims when the page
was allocated from a different NUMA node.

This in itself would not be critically needed as the page should
only be allocated from a different NUMA node in case the target
node has no available memory, but for multi-node claims, we need
to reduce the outstanding claims only on the NUMA node the page
was allocated from.

For this, we need to pass the NUMA node of the allocated page,
so we can use it to perform this check (and in the future update
the claim only on the NUMA node the page was allocated from)

Signed-off-by: Alejandro Vallejo 
Signed-off-by: Bernhard Kaindl 

---
- Reorganized v3, v4 and v5 as per review to avoid non-functional
  changes:
  - Split from patch v2#3 and merged the related changed from v2#5
    into a consolidated patch.
---
 xen/arch/x86/mm.c             |  3 ++-
 xen/arch/x86/mm/mem_sharing.c |  4 ++--
 xen/common/grant_table.c      |  4 ++--
 xen/common/memory.c           |  3 ++-
 xen/common/page_alloc.c       | 21 ++++++++++++++++-----
 xen/include/xen/mm.h          |  2 +-
 6 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b929d15d00..b0f654e02e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4442,7 +4442,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 4787b27964..15b8a3a9d9 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/grant_table.c b/xen/common/grant_table.c
index cf131c43a1..8fea75dbb2 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2405,7 +2405,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);
 
         /*
@@ -2431,7 +2431,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 3371edec11..4c54ce5ede 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -775,7 +775,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));
                 nrspin_unlock(&d->page_alloc_lock);
 
                 if ( drop_dom_ref )
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index bbb34994b7..ebf41a1b33 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -542,8 +542,11 @@ static unsigned long avail_heap_pages(
  * Update the total number of pages and outstanding claims of a domain.
  * - When pages were freed, we do not increase outstanding claims.
  * - On a domain's claims update, global outstanding_claims are updated as well.
+ * - If the domain's claim is on a NUMA node, we only update outstanding claims
+ *   of the domain and the node, when the allocation is from the same NUMA node.
  */
-unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
+unsigned long domain_adjust_tot_pages(struct domain *d, nodeid_t node,
+                                      long pages)
 {
     unsigned long adjustment;
 
@@ -557,8 +560,12 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
      *
      * If the domain has no outstanding claims (or we freed pages instead),
      * we don't update outstanding claims and skip the claims adjustment.
+     *
+     * Else, a page was allocated: But if the domain has a node_claim and
+     * the page was allocated from a different node, don't update claims.
      */
-    if ( !d->outstanding_pages || pages <= 0 )
+    if ( !d->outstanding_pages || pages <= 0 ||
+         (domain_has_node_claim(d) && d->claim_node != node) )
         goto out;
 
     spin_lock(&heap_lock);
@@ -2662,6 +2669,8 @@ int assign_pages(
 
     if ( !(memflags & MEMF_no_refcount) )
     {
+        nodeid_t node = page_to_nid(&pg[0]);
+
         if ( unlikely(d->tot_pages + nr < nr) )
         {
             gprintk(XENLOG_INFO,
@@ -2672,8 +2681,9 @@ int assign_pages(
             rc = -E2BIG;
             goto out;
         }
+        ASSERT(node == page_to_nid(&pg[nr - 1]));
 
-        if ( unlikely(domain_adjust_tot_pages(d, nr) == nr) )
+        if ( unlikely(domain_adjust_tot_pages(d, node, nr) == nr) )
             get_knownalive_domain(d);
     }
 
@@ -2806,7 +2816,8 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
                 }
             }
 
-            drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
+            drop_dom_ref = !domain_adjust_tot_pages(d, NUMA_NO_NODE,
+                                                    -(1 << order));
 
             rspin_unlock(&d->page_alloc_lock);
 
@@ -3012,7 +3023,7 @@ void free_domstatic_page(struct page_info *page)
 
     arch_free_heap_page(d, page);
 
-    drop_dom_ref = !domain_adjust_tot_pages(d, -1);
+    drop_dom_ref = !domain_adjust_tot_pages(d, NUMA_NO_NODE, -1);
 
     unprepare_staticmem_pages(page, 1, scrub_debug);
 
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 52c12c5783..5a5252fc69 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -131,7 +131,7 @@ mfn_t xen_map_to_mfn(unsigned long va);
 int populate_pt_range(unsigned long virt, unsigned long nr_mfns);
 /* Claim handling */
 unsigned long __must_check domain_adjust_tot_pages(struct domain *d,
-    long pages);
+    nodeid_t node, long pages);
 int domain_claim_pages(struct domain *d, nodeid_t node, unsigned long pages);
 void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 07 20:28:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Sep 2025 20:28:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114312.1461353 (Exim 4.92)
	(envelope-from )
	id 1uvM0A-0006pr-35; Sun, 07 Sep 2025 20:28:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114312.1461353; Sun, 07 Sep 2025 20:28:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvM09-0006pj-UG; Sun, 07 Sep 2025 20:28:41 +0000
Received: by outflank-mailman (input) for mailman id 1114312;
 Sun, 07 Sep 2025 20:28: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 1uvM08-0006pd-Hd
 for xen-devel@lists.xenproject.org; Sun, 07 Sep 2025 20:28:40 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3cc5d9ad-8c29-11f0-9d13-b5c5bf9af7f9;
 Sun, 07 Sep 2025 22:28:39 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DB8PR03MB6153.eurprd03.prod.outlook.com (2603:10a6:10:142::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Sun, 7 Sep
 2025 20:28:35 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.018; Sun, 7 Sep 2025
 20: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: 3cc5d9ad-8c29-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Di2e3C6ssJHcLmqg00m+3W9xzznQJ9s4Pb6Rw0/OqMYs85tqHpvy8mEJlFixlv/v2Tsc51BwfEgLsJj8zCGg7079oW2Rq39/ikaW2R8mM79H05oK7ApeKj/0Nt0mNEJRSQgJCLoPFI7eDJI4Xg7+dEGQvAz+YkoaivazQNrPrTKOCbm2clP+I4n1x0FvU4dxSWxwbocCVFJF8E71oq1F0b1BHp4GPcbmAYrgN32oXrOkUAg3FraEhCYhvCxgcmqCcdaUmvZLpxlGFxNT8HMCEyO76y+ASuZQPR4ZGj9aM+RiWN8Tnh7YWXM62vTBZuhrSemWF6ypx24f2asYJlO3ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=l3l2Y7gHfL5eSmA1215hHkIci4eb3jEdnMCO9tns+fE=;
 b=euDNLsogL6L5vXCZFOesBE/Muy8VroZ28WOtOg2Z470bAfG+/raq9dBQ4qL++HUxxsdAJOrLYkncFNYVWVKcT3xJMi41MIKgUwLZFxZgbFZhxnblCpMtAAOiuEVpVNO/xrqio+nTb7dvskUTpFF4CHu5CxBrvj3AtmUTGJovMTfpI3V62JPzJmK/e/d8XdzMMmmO8w8C9vsY/TklOcBU67qDYn51uHH14mJj86K7LO8gIZj38ckYB9Dkjp0Z6fwEMvuiVnXnMh22X+QiEGW8LPHoKnX6bdB7Ui4slG8Zqt3LYZUn6CH3QTh6XmQvMzecaaKMVHo19F+Xi/HYZxPkAQ==
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=l3l2Y7gHfL5eSmA1215hHkIci4eb3jEdnMCO9tns+fE=;
 b=kIcodGp6zB6Fe2rsU4yqw9a/0Kqsg97Rxwg4iCYLrLWkkeCE+12Qq2QbJ1MawwswTH5QI/leq05l9ZQMYUCqJpqMskORkQqnsK61owmsRLFAO8W1uBx+0NDqhd1ZhSYU1BSSvniaDlBCtjbjaJpz1K82GNmOBr749MnrWq6Jqn0bENnzdOAv+fHthw64FiWAjxpQP8U8aHPmi4ZrwhJdvx7oBRuCHDmEOpwwD4zmS7MB1f3ogIPdRlcapcPaCOf+v2I3UTIJiy9jp4uKLNCS7v65dr5g5BEeG1J/qUKNLimLCFseHoMNFvMiuItpbDtZ3F51PVb05rIHK4Hv6gP9hA==
From: Leonid Komarianskyi 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" ,
	"olekstysh@gmail.com" , Julien Grall ,
	Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Anthony PERARD , Oleksii Kurochko
	, Community Manager
	
Subject: Re: [PATCH v7 00/12] Introduce eSPI support
Thread-Topic: [PATCH v7 00/12] Introduce eSPI support
Thread-Index: AQHcHdai+Ac/NEuVikikoMKerzFsQrSFS7aAgALkkoA=
Date: Sun, 7 Sep 2025 20:28:34 +0000
Message-ID: <374b7296-bfc0-4a4d-8f2c-b148c29c0517@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: GV2PR03MB8678:EE_|DB8PR03MB6153:EE_
x-ms-office365-filtering-correlation-id: 72267a4d-0123-4798-9d8b-08ddee4d1ea6
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?OTlLdGhIY05FTmhzYjdIN0NjMWJqWTdwNUFQUElUcUtrb0d1amdJNjFzOUpX?=
 =?utf-8?B?b0lnSTNqS3VmYXlud3Z5OVBYRjVJNFhycVA1U0UxYTVlRjJNVVJsLzZUeStX?=
 =?utf-8?B?eUtjZ3h4M1pNYkFtdnpXYnQ3UmE1QllFTG9WOE8zODViTG15UVBuQjJjNktw?=
 =?utf-8?B?VzZBS3ZKV2M1RWhEUmFCUEpEKytDYnpzZXJRUzlHWkpQVTFiczYrcVh0Z0lQ?=
 =?utf-8?B?clNOSEQrVGMzNUJnSDVuaS9HM0R2VXBiQWEzMHNBRC9lQnJnMncweVdhVW1w?=
 =?utf-8?B?NzNXVUlyV0FOTDIzUUpJNTB5UWlhTUtoSDYyNzVjQU1sWFFUWE85MGhhN3VK?=
 =?utf-8?B?STROZmM4bDJ4c0s5bm9SVDZlUXBQSXVXNGtDYWVSVDk2dm1Qa0YzclFQMExD?=
 =?utf-8?B?Ly8xLytrVWxxZFJVMFdRUlhqdmt5ejBTUlRKR1BoTFBGdDVINWNscGRSeWRN?=
 =?utf-8?B?NGdMRkR2dWlZRmZ1cmh4WnpNa1NhdStsbkdaWHFhTWl5SU9tZEd5a1JPSEor?=
 =?utf-8?B?OUdNaTZGbkdYbzVVeE5vdVhJeHN6b2FUa1NUK1VZeWdNb2pIeE5MUkEzVkRK?=
 =?utf-8?B?L212Mk5KQm1aWFp2ZnhWbW9HMlVpQjRmVjd2QXh4UTJrRytmUkFhQ05WMEZv?=
 =?utf-8?B?aER3cmZqdHRBY0l0alc0bnFsak5BVlMvV1F6cktZWXZUZThncTlVdGQ5TGJu?=
 =?utf-8?B?Q0lqTEhRVzFrdE50eWZxOWRFTlQxcFUxTGc1cXNZLzVCalBpWlo4RnhXYXN4?=
 =?utf-8?B?ZnY2eGU3ajFIS3R6eWdjNnZ5Mm1JZjEwMDIrYk9MTnZOZkZCSVFjQytWeUNN?=
 =?utf-8?B?blcrOENMYlErZENCNStQc01SbUZqNG51ckJmL0NhK09Scjd5UkgwTFZ1OHJ3?=
 =?utf-8?B?c1dWMEZqbWlLeTFLSlloY0ZXV0ZzaVJoOUpsQU1vNHZlS2xPM3k3dE50VmV6?=
 =?utf-8?B?VEhQcXlNbHNPTExMWHdWaDZjalN3eWpOdTdXSTB4RERLRnNLOFV4UTFmNElq?=
 =?utf-8?B?VUxobVNFUnhUU1dESjUwM1VyaldkQ1E3WXMyU1VWVGtkdGM0cXNZSnkxcEpQ?=
 =?utf-8?B?M2UvUGRGNGpRVEpCcGFVbzZreUg3UEk4R25kbnFWbVpIaXlUSFhnTmNFVTJI?=
 =?utf-8?B?aGd5VFBLZXJzNUVmRTFaekxybDQyZHJ3V0hsMVlkbGp6eGdaQm5WYW5MWktT?=
 =?utf-8?B?cmlLS3E5S3dVNEREbjFmVXRwT3BBK2x4TkorM0hQeGhTU0prMDdqK1Zna04z?=
 =?utf-8?B?blpwTmRwMW1QUFpnN25seVM3UVJTSVcrWUFiRk1xOW1Ka1pBWjcyejNrWDVu?=
 =?utf-8?B?YTZYVkNKMmdlMmR3VWlEZnlNOG5mcVkrRExkakl1YS9rTnZSSFNCRDBJR2lE?=
 =?utf-8?B?U1ZtVWxRZFMxUVlLdGFPYjIyOERCM1RJbE1IUllFU2pqSzVyU1M1cVpiUkVY?=
 =?utf-8?B?WjRsRTNDaUp1cmpwbnVxZW9xa1NidG5PdGY1c0FvKzc2OFY5NlhTZUR0Z01o?=
 =?utf-8?B?R3pDWnU1RVEvdjVUYklhaGNCQTVzR3VYOXMrbTFpUXAxRVNIS094OWhEVFdn?=
 =?utf-8?B?OUhnVFFEYlpHTmFRQUsra2JHOHBUaWpjcVRJS0RrM1pBSkVUMWFpSWdlZ1pC?=
 =?utf-8?B?Ymt6YTVZQ0tzakU5K0VCUnN1Y3JOaWZYay9yWEIzczFkVER6SGZnQmtGb1Mx?=
 =?utf-8?B?dEVHQnBiMWV2WlFGUnNPNXVMaHRwTkhwUUxyeWpOaXZKWmt1ajliai9Na0lQ?=
 =?utf-8?B?Q1hqQXUwWmpxVFF1RXV5TDRLeHoxWE5VKzZ2aXc4NWZ5YnNoUWZlU0IyNXJB?=
 =?utf-8?B?Q01HNm90Zm0rQjhOL2dRNDNXMldzMzdqQUU2b1BwMXhqUVRUMUpEdnpERnlw?=
 =?utf-8?B?M0h4SjBTamZsSFJiM3NYSTRTNzdmaStURVdSWGMyWkg2eTZHWHZZaWZOb0xk?=
 =?utf-8?Q?cHjefHWO1GY=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NHRvSEVpVzhmbEhTWDhTbXBYajhyZWJSUEhHVEhmQVlJRUEwL3ZiVnVvRE1Q?=
 =?utf-8?B?QTB6dnFPWlI5MlN5VWl3M3Yybm9UYnkrOVZHc2pVYmJDcUlMdGwxbjR5TUc5?=
 =?utf-8?B?OTU5TkJKL0ZRdFE0L1BseFVBMS9IRUNUd2dKTDR6UjRsUUVXcFZzdDB2K1Bl?=
 =?utf-8?B?OXMydHpkVzVJYytZczRkbVY4dmxtMFltc2RzRTJVZFp0Ulg0REFDc2lENDJp?=
 =?utf-8?B?eEZFRTRvSzREajU0TTJCaFhhWEN3dmRjd0RtNkh2Wkhab1duSTVDSnp1dnd5?=
 =?utf-8?B?YldHQlRFNEpmOG5KYkd1dHVoTkNSRHJwNFE3bjdFVENIMDdEMEt2NjNjR3dD?=
 =?utf-8?B?NCsvRGhDWXZOT1FGdXlIVGZCUmFRTngvdWkvWnVwQUtzdTdSZHMvSHhFT09j?=
 =?utf-8?B?TXRsdmYvVWwyZlh6bHlMaG4wekJUUzYxVXA5Y1FST0VsdjRWZE5GWElHcmZF?=
 =?utf-8?B?THo3engzTEs2Q21QaVhpQzNleW5CbjFHUFlCYVBPazV2TUFiR0xBL3lGbGh1?=
 =?utf-8?B?Z25KYkd5MjVZbVpOVjVQaFg5eUMrc2JwZU5uMWxrQXVoNjFJZ1l2TnFNZnIr?=
 =?utf-8?B?bFp3ekRrd2pObHN3K2s0bnBQNTBnN3RTUWFLb1A1NUNFRUltdER6L0hUb2R2?=
 =?utf-8?B?QnE1OXp2bHpPN1UzUmdCejd3aWJHZktZV3FKVlR4VXQyUTRGc2loNEtqSGMv?=
 =?utf-8?B?R3NDSzRtUEV5UEphZU5zekU3ajRCVk85UnVGd0JZOUUyWk9SMGVDbmh1a3ds?=
 =?utf-8?B?UFJtdVBuaXJoYnZFU1JlUkJiS1FTenoxek5XbzlTUTdmRHhvZzFzUmxlUzlo?=
 =?utf-8?B?cWdtNWRidzh6UHlvUFp6eXpsNUdzQ25SSGRoWmxkN1ZiUnJDV1RDOWF3RFRF?=
 =?utf-8?B?MVlQeW9sRFdOQjg0bTRBYW5RTk04R1UxZGd5aVA3MFFCZEN0V25kckpVc2E2?=
 =?utf-8?B?cFcrN3dtTWptdU95QytLWTZsNGhhUHJFWndkOE9hWjRzT1BPSkQ4M1M0Nk0v?=
 =?utf-8?B?QzdSMjZNUTdGQjdXYzhCWWUvT2s3ZkVWUnRFajJsOHRuZ0V4RENKZS9Rek5T?=
 =?utf-8?B?NzJmem1lZlBBS3lWQ2JUT2tka1YvQmVDdFRVSVJZdFJhNmE3aEg3cWt4ekZW?=
 =?utf-8?B?aXRwZXFhSEtNcnJRZjY0QlFMRkFhSVJlaWxaSWFVWGdMcUZ5L0VFZkpCQTg4?=
 =?utf-8?B?Y3VtTWk1Y01XaTdlQXpGOWk3SXQram85U3g5WC95MHhDM3lpN05IUTFXc0hx?=
 =?utf-8?B?TUM0cGJ5Qk8wSUc3VGZ2U0tWSWEwTnNmLzhMM1lBaG9VK2tFejdxNmNEYzFz?=
 =?utf-8?B?OTZMbC9pRlRFR0FRblpFdGdVajMzb2hsdGg0ZWt3eE5wWDE5RUh2RzRKV1ht?=
 =?utf-8?B?cW8zWFJxRVBYZ2V5NmwvYWZGUTBpbncrZmNkRWNUV1FTMzhid2hEMDV2UjZU?=
 =?utf-8?B?UkxWcnVxbTlWdWJSVHhjRFl0VGVhMWRZUzhyRFhONm5ORVlSZ1k5cnpEaW5m?=
 =?utf-8?B?K0Q1TDd4RWdWNzNTVTlwcUF5RVN2YUx3VlVDZitKTGo0amZhaWdlTWhia09w?=
 =?utf-8?B?U0hhd0NLZVVuTzR1cnNmMm1pYjVwRG9sQ3lpbFVvR2poSndzMFdMdVU0VWth?=
 =?utf-8?B?MWw0TlJla3AwUExxNXl4TzdOWDJVNWVGT0x3OWV4RERVMnBpQ0t2RnpCTnI1?=
 =?utf-8?B?eE5iR1NYOFhyRHRObS9IZXdFQStyVG5pUjBtbDR1K3NZZ0lyUi8rS1pPdjE3?=
 =?utf-8?B?TlgrbVlZRDFtVjNxb2E4SDZXdktmR2VPOVZkZDB4UXVJaklsZkNPOVZwSGJF?=
 =?utf-8?B?bVlsNXQ5R3N2ZWlYSGJVK0NwNW1tM2hlS3hZd0M0Zm9zTXR1N2kzb0E2ejhV?=
 =?utf-8?B?cW14YVNjNVJhVC9GaE5GaTgzTStySXNvckNwVjBHUDU2clNOTkVmbmM0NFZ0?=
 =?utf-8?B?MW01ZGwzVjRiUXRERXlaSEo0Q2htUSt0N01vVGFNckh1a2pCOU9qaUh6WlBy?=
 =?utf-8?B?TkxCZURoQnlTNVV5cXgvQnFMNmIvbmxEWDFKamdEOWRXcGtDNlk2cFVSdVdm?=
 =?utf-8?B?Vk1VQXJ4bEtYcDUxS3VOUjhhZzd3ZGR3Z280Q0R0VlhyVk85cFpoVXc4cDRq?=
 =?utf-8?B?VHhWeG1xWEs4VnNsSmdhN1BjVkkvWXVoRXI4Y1RkMzZUN0RiTmkzdGFkUlZv?=
 =?utf-8?Q?Hc13EbBf92CfwuTJCSndFaU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2BD9648EB8C03F4185C7B1C31F189788@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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 72267a4d-0123-4798-9d8b-08ddee4d1ea6
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2025 20:28:35.0426
 (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: 2Q2f86T40VKxmeoS6dvFUweX12QscnQIkSom6UkvrFUtz2tpDEA29e7ivbEd0UxTm9Ggu9/a7J2srr4u57dbpdqYGVaDMLKIaF3WoVYGwyo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6153

SGVsbG8gU3RlZmFubywNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBmb3IgcHJv
dmlkaW5nIHRoZSBFY2xhaXIgcmVwb3J0cy4NCg0KT24gMDYuMDkuMjUgMDM6MTcsIFN0ZWZhbm8g
U3RhYmVsbGluaSB3cm90ZToNCj4gSGkgTGVvbmlkLA0KPg0KPiBJIHdhcyBhYm91dCB0byBjb21t
aXQgdGhpcyBidXQgdW5mb3J0dW5hdGVseSBpdCBpcyBpbnRyb2R1Y2luZyBNSVNSQQ0KPiByZWdy
ZXNzaW9ucy4gU2VlOg0KPiBodHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxlL3Nz
dGFiZWxsaW5pL3hlbi8tL3RyZWUvcHBwNj9yZWZfdHlwZT1oZWFkcw0KPg0KPiBodHRwczovL2dp
dGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxlL3NzdGFiZWxsaW5pL3hlbi8tL2pvYnMvMTEyNjUw
MDUxMTgNCj4NCj4gQ29tcGFyZWQgdGhpcyByZXN1bHQ6DQo+IGh0dHBzOi8vZWNsYWlyLWFuYWx5
c2lzLWxvZ3MueGVucHJvamVjdC5vcmcvZnMvdmFyL2xvY2FsL2VjbGFpci94ZW4tcHJvamVjdC5l
Y2RmL3hlbi1wcm9qZWN0L3Blb3BsZS9zc3RhYmVsbGluaS94ZW4vRUNMQUlSX25vcm1hbC9wcHA2
L0FSTTY0LzExMjY1MDA1MTE4L1BST0pFQ1QuZWNkOy9ieV9zZXJ2aWNlLmh0bWwjc2VydmljZSZr
aW5kDQo+DQo+IEFnYWluc3QgdXBzdHJlYW0gc3RhZ2luZzoNCj4gaHR0cHM6Ly9lY2xhaXItYW5h
bHlzaXMtbG9ncy54ZW5wcm9qZWN0Lm9yZy9mcy9zcGFjZS9YRU4uZWNkZi94ZW4tcHJvamVjdC9o
YXJkd2FyZS94ZW4vRUNMQUlSX25vcm1hbC9zdGFnaW5nL0FSTTY0LzExMjY0NzcyNjA1L1BST0pF
Q1QuZWNkOy9ieV9zZXJ2aWNlLmh0bWwjc2VydmljZSZraW5kDQo+DQo+IEl0IGlzIGludHJvZHVj
aW5nIGEgY291cGxlIG9mIGVhc3ktdG8tZml4IDE2LjMgaXNzdWVzIGFuZCBhbHNvIGEgY291cGxl
DQo+IG9mIG5ldyAxNi40IGlzc3Vlcy4gVGhleSBzaG91bGQgYmUgYWxsIGVhc3kgdG8gZml4LiBJ
dCBpcyBhbHNvDQo+IGludHJvZHVjaW5nIHRocmVlIG5ldyAxMy4yIGlzc3VlcyBhbmQgb25lIDE4
LjEgYnV0IEkgaGF2ZW4ndCBsb29rZWQNCj4gY2xvc2VseSBpbnRvIHRob3NlLiBQbGVhc2UgYWRk
cmVzcyB0aGVtLg0KPg0KDQpSZWdhcmRpbmcgdGhlIE1JU1JBIDE2LjMvMTYuNCB2aW9sYXRpb25z
IGFuZCAxMy4yIGNhdXRpb25zIC0gdGhlcmUgYXJlDQpubyBxdWVzdGlvbnMgZnJvbSBteSBzaWRl
LiBJIGhhdmUgZml4ZWQgdGhlbSBhbmQgd2lsbCBzZW5kIHRoZSB1cGRhdGVkDQpWOCAod2l0aCB0
eXBvIGZpeGVzLCBhZGRlZCBhY2tlZC9yZXZpZXdlZC1ieSB0YWdzLCBldGMuKS4gSG93ZXZlciwg
SQ0Kd291bGQgbGlrZSB0byBjbGFyaWZ5IHJlZ2FyZGluZyB0aGUgTUlTUkEgMTguMSBjYXV0aW9u
IHJlZ3Jlc3Npb24gYW5kDQpyZXZpZXcgcHJvY2VzcyBydWxlczoNCg0KTUlTUkEgMTguMSBjYXV0
aW9uOg0KDQp4ZW4vYXJjaC9hcm0vaXJxLmM6MTA1LjEzLTEwNS4zOTogWzhdIGFjY2VzcyBvZiAn
aXJxX2Rlc2MnIGF0IGFuDQpvdmVyZmxvd2luZyBpbmRleCwgd2hpbGUgaXQgaG9sZHMgb25seSA5
OTIgJ3N0cnVjdCBpcnFfZGVzYycgZWxlbWVudHMNCg0KQWN0dWFsbHksIHRoZXJlIGlzIG5vIG5l
dyByZWFsIGlzc3VlIGhlcmUsIGJlY2F1c2UgdGhlIG1haW5saW5lDQppcnFfZGVzYygpIGN1cnJl
bnRseSBkb2VzIG5vdCBoYXZlIHVwcGVyIGxpbWl0IGNoZWNrcyBmb3IgSVJRczoNCg0Kc3RydWN0
IGlycV9kZXNjICpfX2lycV90b19kZXNjKHVuc2lnbmVkIGludCBpcnEpDQp7DQogICAgIGlmICgg
aXJxIDwgTlJfTE9DQUxfSVJRUyApDQogICAgICAgICByZXR1cm4gJnRoaXNfY3B1KGxvY2FsX2ly
cV9kZXNjKVtpcnFdOw0KDQogICAgIHJldHVybiAmaXJxX2Rlc2NbaXJxLU5SX0xPQ0FMX0lSUVNd
Ow0KfQ0KDQouLi4gYXMgYSByZXN1bHQgRWNsYWlyIGRvZXMgbm90IHNwb3QgYW55IGlzc3VlcyBp
biB0aGlzIGNvZGUgYWNjb3JkaW5nDQp0byB0aGUgc3RhZ2luZyByZXBvcnQuIEFzIEkgdW5kZXJz
dGFuZCwgaXQgdHJpZ2dlcnMgb24gcGF0Y2hlcyB3aXRoIGVTUEkNCmJlY2F1c2UgSSBpbnRyb2R1
Y2VkIG5ldyBjaGVja3MgZm9yIHRoZSBlU1BJIElOVElEIHJhbmdlLCB3aGljaCBzaG91bGQNCm5v
dCBiZSB1c2VkIHdpdGhvdXQgQ09ORklHX0dJQ1YzX0VTUEk9eS4NCg0KQWxzbywgYSBzaW1pbGFy
IGlzc3VlIHdpdGggaW52YWxpZCBJTlRJRHMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgdGhyZWFkOg0K
DQpodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIw
MjUtMDkvbXNnMDA0MDEuaHRtbA0KDQpMb25nIHN0b3J5IHNob3J0OiB0aGUgbWFpbmxpbmUgWGVu
IGN1cnJlbnRseSBhbGxvd3MgZGVmaW5pbmcgaW52YWxpZA0KSU5USURzIGluIHRoZSBYZW4gRFRT
IGFuZCBjcmFzaGVzIGluIF9faXJxX3RvX2Rlc2MoKSB3aGVuIGF0dGVtcHRpbmcgdG8NCm9wZXJh
dGUgb24gYW4gaW52YWxpZCBpbnRlcnJ1cHQgbnVtYmVyLg0KDQpJIGhhdmUgcHJlcGFyZWQgYSBm
aXggZm9yIHRoZSAxOC4xIGNhdXRpb24sIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgaXQNCmlz
IHdvcnRoIGFwcGx5aW5nIGp1c3QgdG8gYWRkcmVzcyB0aGUgRWNsYWlyIHJlcG9ydCAoaWYgaXQg
aXMgbm90IGNyaXRpY2FsKToNCmh0dHBzOi8vZ2l0aHViLmNvbS9MS29tYXJ5YW5za2l5L3hlbi9j
b21taXQvYWY1ZDlhNDgzMzAyZjdiY2ZhYWRiZWZiODVmNWU0ZWUzNWY2Y2IzYg0KDQpTbywgY291
bGQgeW91IHBsZWFzZSBjbGFyaWZ5IHdoaWNoIG9wdGlvbiB3b3VsZCBiZSBiZXR0ZXI6DQoxKSBM
ZWF2ZSB0aGUgY29kZSBhcyBpdCBpcyBmb3Igbm93LCBhY2NlcHRpbmcgdGhlIE1JU1JBIGNhdXRp
b24gZnJvbQ0KRWNsYWlyIGFuZCBmaXggdGhlIGlzc3VlIGxhdGVyIGluIHRoZSBjb250ZXh0IG9m
IGFkZHJlc3NpbmcgWGVuIGNyYXNoaW5nDQp3aXRoIGludmFsaWQgSU5USURzIGFuZCBpbXBsZW1l
bnRpbmcgZHluYW1pYyBhbGxvY2F0aW9uIG9mIGlycV9kZXNjX3QgYXJyYXk7DQoyKSBBcHBseSB0
aGUgZml4IG5vdyAod2hpbGUgYWxzbyBwbGFubmluZyB0byBhZGRyZXNzIHRoZSBpbnZhbGlkIElO
VElEDQppc3N1ZSBpbiB0aGUgZnV0dXJlKQ0KDQoNClJlZ2FyZGluZyB0aGUgcmV2aWV3IHByb2Nl
c3M6DQpTaG91bGQgSSByZW1vdmUgdGhlICdyZXZpZXdlZC1ieScgdGFncyBmcm9tIHRoZSBwYXRj
aGVzIHdoZXJlIEkgYWRkZWQNCm1pc3NpbmcgYnJlYWtzICh3aXRoIHRoZSBjb3JyZXNwb25kaW5n
IGNvZGUgdXBkYXRlcykgb3IgaW50cm9kdWNlZA0KdmFyaWFibGVzIHRvIGZpeCBNSVNSQSBpc3N1
ZXM/IEkgYW0gYXNraW5nIGJlY2F1c2UgdGhlc2UgYXJlIGNvZGUNCmNoYW5nZXMsIGFuZCBJIGFt
IG5vdCBzdXJlIGlmIEkgc2hvdWxkIGxlYXZlIHRoZSBSQiB0YWdzIGluIHRoaXMgY2FzZS4NCg0K
Pg0KPiBPbGVrc2lpLA0KPg0KPiBUZWNobmljYWxseSwgdGhlIHNlcmllcyBpcyBmdWxseSBhY2tl
ZCBhbmQgcmVhZHkgdG8gYmUgY29tbWl0dGVkLiBGcm9tIGENCj4gcmlzayBwZXJzcGVjdGl2ZSwg
SSB3b3VsZCBiZSBjb21mb3J0YWJsZSBjb21taXR0aW5nIGl0IG5vdyB3aXRoIHRoZQ0KPiBvdXRz
dGFuZGluZyBNSVNSQSByZWdyZXNzaW9ucywgbGVhdmluZyBMZW9uaWQgdG8gZml4IHRoZW0gb3Zl
ciB0aGUgbmV4dA0KPiBmZXcgZGF5cy4gSG93ZXZlciwgSSBoYXZlIG5vdCBkb25lIHNvIGJlY2F1
c2UgaXQgd291bGQgbWFrZSBpdCBoYXJkZXIgdG8NCj4gc3BvdCB0aGUgTUlTUkEgcmVncmVzc2lv
bnMgZHVlIHRvIHRoZSB3YXkgdGhlIHNjYW5uZXIgd29ya3MgKGl0DQo+IGNvbXBhcmVzIGFnYWlu
c3QgdGhlIHByZXZpb3VzIHZlcnNpb24pLg0KPg0KPiBJIHN1Z2dlc3Qgd2UgYWxsb3cgdGhpcyBz
ZXJpZXMgdG8gYmUgY29tbWl0dGVkIGluIHRoZSBuZXh0IGNvdXBsZSBvZg0KPiBkYXlzLCBvbmNl
IExlb25pZCBhZGRyZXNzZXMgdGhlIHJlZ3Jlc3Npb25zLCBldmVuIHRob3VnaCBpdCB3b3VsZA0K
PiB0ZWNobmljYWxseSBiZSBwYXN0IHRoZSBmZWF0dXJlIGZyZWV6ZS4NCj4NCj4gQ2hlZXJzLA0K
Pg0KPiBTdGVmYW5vDQo+DQo+IFAuUy4NCj4NCj4gTGVvbmlkLCB5b3UgbWlnaHQgd2FudCB0byBj
aGVjayBteSBjb21taXRzIGJlY2F1c2UgSSBmaXhlZCBhIGNvdXBsZSBvZg0KPiB0aGluZ3Mgb24g
Y29tbWl0LCBpbiBhZGRpdGlvbiB0byBhZGRpbmcgdGhlIHZhcmlvdXMgYWNrZWQtYnkgdGFncy4N
Cj4NCj4NCj4gT24gVGh1LCA0IFNlcCAyMDI1LCBMZW9uaWQgS29tYXJpYW5za3lpIHdyb3RlOg0K
Pj4gSGVsbG8gZXZlcnlvbmUhDQo+Pg0KPj4gVjYgY29udGFpbnMgYW4gaXNzdWUgZm9yIGRlYnVn
IGJ1aWxkcyB3aXRoIENPTkZJR19HSUNWM19FU1BJPW4gZHVlIHRvIGENCj4+IG1pc3Rha2UgaW4g
dGhlIEFTU0VSVCgpIGNvbmRpdGlvbiBpbiB0aGUgaXNfZXNwaSgpIGZ1bmN0aW9uLiBUaGlzIHBh
dGNoDQo+PiBzZXJpZXMgZml4ZXMgdGhlIGlzc3VlIGFuZCBhbHNvIGluY2x1ZGVzIG1pbm9yIGZp
eGVzIGFjY29yZGluZyB0byB0aGUNCj4+IHJldmlldyBvZiBWNi4NCj4+DQo+PiBTdW1tYXJpemVk
IGRlc2NyaXB0aW9uOg0KPj4gVGhpcyBwYXRjaCBzZXJpZXMgYWRkcyBzdXBwb3J0IGZvciB0aGUg
ZXh0ZW5kZWQgc2hhcmVkIHBlcmlwaGVyYWwNCj4+IGludGVycnVwdCAoZVNQSSkgcmFuZ2UgKElO
VElEcyA0MDk2LTUxMTkgWzJdKHJhbmdlcyBvZiBJTlRJRHMpKSBmb3IgWGVuDQo+PiBhbmQgZ3Vl
c3QgZG9tYWlucy4gVGhlIGltcGxlbWVudGF0aW9uIHVzZXMgYSBnZW5lcmljIGFwcHJvYWNoIHRv
IGhhbmRsZQ0KPj4gZVNQSXMsIHNpbWlsYXIgdG8gcmVndWxhciBTUElzLCB3aGlsZSBtYWludGFp
bmluZyBjb21wYXRpYmlsaXR5IHdpdGggdGhlDQo+PiBleGlzdGluZyBTUEkgcmFuZ2UuIEZ1bmN0
aW9uYWxpdHkgcmVtYWlucyB1bmNoYW5nZWQgZm9yIHNldHVwcyB0aGF0IGRvDQo+PiBub3QgcmVx
dWlyZSBlU1BJcy4NCj4+DQo+PiBUaGUgc2VyaWVzIGluY2x1ZGVzOg0KPj4gMSkgR2VuZXJhbCBy
ZWZhY3RvcmluZyBvZiBjb21tb24gSVJRIG9wZXJhdGlvbnMgd2l0aCBHSUMgcmVnaXN0ZXJzIHRv
DQo+PiBpbXByb3ZlIGNvZGUgcmVhZGFiaWxpdHksIHNpbXBsaWZ5IGZ1cnRoZXIgbWFpbnRlbmFu
Y2UgYW5kIHByZXBhcmUgdGhlDQo+PiBrZXkgZnVuY3Rpb25zIGZvciBlU1BJIGltcGxlbWVudGF0
aW9uLg0KPj4gMikgSW50cm9kdWNpbmcgYSBuZXcgS2NvbmZpZyBvcHRpb24gKGRlZmF1bHQgbikg
dG8gZW5hYmxlIG9yIGRpc2FibGUNCj4+IGVTUEkgc3VwcG9ydC4gRGlzYWJsaW5nIHRoaXMgb3B0
aW9uIHByZXZlbnRzIHVubmVjZXNzYXJ5IHJlc291cmNlDQo+PiBhbGxvY2F0aW9uIGZvciBzZXR1
cHMgdGhhdCBkbyBub3QgcmVxdWlyZSBlU1BJcy4NCj4+IDMpIEFkZGluZyBhZGRpdGlvbmFsIHJl
c291cmNlcyB0byBzdG9yZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBhbmQgb3BlcmF0ZQ0KPj4gd2l0
aCB1cCB0byAxMDI0IGludGVycnVwdHMgZnJvbSBlU1BJIHJhbmdlLg0KPj4gNCkgQWRqdXN0aW5n
IGFzc2VydGlvbnMgYW5kIGNoZWNrcyB0byBwYXNzIHZlcmlmaWNhdGlvbiBmb3IgSU5USURzIGlu
DQo+PiB0aGUgZVNQSSByYW5nZS4NCj4+IDUpIENvbmZpZ3VyYXRpb24gb2YgZVNQSS1zcGVjaWZp
YyByZWdpc3RlcnMgZHVyaW5nIEdJQyBpbml0aWFsaXphdGlvbg0KPj4gZm9yIHN5c3RlbXMgd2l0
aCBHSUN2My4xKyBoYXJkd2FyZS4NCj4+IDYpIEVuYWJsZXMgZVNQSSBNTUlPIGVtdWxhdGlvbiBm
b3IgdkdJQywgYWxsb3dpbmcgZ3Vlc3QgZG9tYWlucyB0bw0KPj4gYWNjZXNzIGFuZCBvcGVyYXRl
IHdpdGhpbiB0aGUgZVNQSSdzIElOVElEcy4NCj4+IDcpIFVwZGF0aW5nIGRvY3VtZW50YXRpb24g
YW5kIENIQU5HRUxPRyB0byByZWZsZWN0IHRoZSBjaGFuZ2VzIG1hZGUgZm9yIGVTUEkNCj4+IHN1
cHBvcnQuDQo+Pg0KPj4gQWxzbywgdG8gc2ltcGxpZnkgcmV2aWV3aW5nLCBwbGVhc2UgZmluZCBi
ZWxvdyBsaW5rIHRvIHVuc3F1YXNoZWQgcGF0Y2hlcywgdGhhdA0KPj4gYXJlIG9uIHRvcCBvZiBl
dmVyeSBwYXRjaCwgdGhhdCBpcyBjaGFuZ2VkIGluIHRoZSBzZXJpZXMsIGNvbXBhcmVkIHRvIFY2
Og0KPj4gaHR0cHM6Ly9naXRodWIuY29tL0xLb21hcnlhbnNraXkveGVuL2NvbW1pdHMvZXNwaS1z
dXBwb3J0LW1hc3Rlci11cHN0cmVhbS12Ny11bnNxdWFzaGVkLw0KPj4NCj4+IEdpdGh1YiBicmFu
Y2ggd2l0aCBwYXRjaCBzZXJpZXM6DQo+PiBodHRwczovL2dpdGh1Yi5jb20vTEtvbWFyeWFuc2tp
eS94ZW4vY29tbWl0cy9lc3BpLXN1cHBvcnQtbWFzdGVyLXVwc3RyZWFtLXY3Lw0KPj4NCj4+IENo
YW5nZXMgaW4gVjc6DQo+PiAtIGluZGl2aWR1YWwgY2hhbmdlcyBpbiBwYXRjaGVzDQo+Pg0KPj4g
TGluayBvbiBWNjoNCj4+IC0gaHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9hcmNoaXZlcy9o
dG1sL3hlbi1kZXZlbC8yMDI1LTA5L21zZzAwMjk2Lmh0bWwNCj4+DQo+PiBDaGFuZ2VzIGluIFY2
Og0KPj4gLSBpbmRpdmlkdWFsIGNoYW5nZXMgaW4gcGF0Y2hlcw0KPj4NCj4+IExpbmsgb24gVjU6
DQo+PiAtIGh0dHBzOi8vbGlzdHMueGVucHJvamVjdC5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2
ZWwvMjAyNS0wOC9tc2cwMjA4Ni5odG1sDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWNToNCj4+IC0gaW5k
aXZpZHVhbCBjaGFuZ2VzIGluIHBhdGNoZXMNCj4+DQo+PiBMaW5rIG9uIFY0Og0KPj4gLSBodHRw
czovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDgv
bXNnMDE3NjcuaHRtbA0KPj4NCj4+IENoYW5nZXMgaW4gVjQ6DQo+PiAtIGFkZGVkIGEgcGF0Y2gg
Zm9yIGRvY3VtZW50YXRpb24NCj4+IC0gaW5kaXZpZHVhbCBjaGFuZ2VzIGluIHBhdGNoZXMNCj4+
DQo+PiBMaW5rIG9uIFYzOg0KPj4gLSBodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDgvbXNnMDE2MjguaHRtbA0KPj4NCj4+IENoYW5nZXMg
aW4gVjM6DQo+PiAtIGFkZGVkIGEgcGF0Y2ggdG8gdXBkYXRlIENIQU5HRUxPRy5tZA0KPj4gLSBp
bmRpdmlkdWFsIGNoYW5nZXMgaW4gcGF0Y2hlcw0KPj4NCj4+IExpbmsgb24gVjI6DQo+PiAtIGh0
dHBzOi8vbGlzdHMueGVucHJvamVjdC5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAyNS0w
OC9tc2cwMDM3Mi5odG1sDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMjoNCj4+IC0gYWRkZWQgMiBtb3Jl
IHBhdGNoZXMgdG8gaW1wbGVtZW50IGhlbHBlcg0KPj4gICAgZnVuY3Rpb25zIGZvciBnaWMvdmdp
YzoNCj4+ICAgIHhlbi9hcm06IGdpYzogaW1wbGVtZW50IGhlbHBlciBmdW5jdGlvbnMgZm9yIElO
VElEIGNoZWNrcw0KPj4gICAgeGVuL2FybTogdmdpYzogaW1wbGVtZW50IGhlbHBlciBmdW5jdGlv
bnMgZm9yIHZpcnEgY2hlY2tzDQo+PiAtIHJlbW92ZWQgMiBwYXRjaGVzOg0KPj4gICAgeGVuL2Fy
bS9pcnE6IGFsbG93IGFzc2lnbm1lbnQvcmVsZWFzaW5nIG9mIGVTUEkgaW50ZXJydXB0cw0KPj4g
ICAgeGVuL2FybTogZ2ljL2lycTogcGVybWl0IHJvdXRpbmcgb2YgZVNQSSBpbnRlcnJ1cHRzIHRv
IFhlbiBhbmQgZG9tYWlucw0KPj4gICAgc2luY2UgdGhlaXIgZnVuY3Rpb25hbGl0eSBjYW4gYmUg
bW92ZWQgdG8gYXBwcm9wcmlhdGUgcGF0Y2hlcyBhZnRlcg0KPj4gICAgaW50cm9kdWNpbmcgcGF0
Y2hlcyB3aXRoIGhlbHBlciBmdW5jdGlvbnMNCj4+IC0gaW5kaXZpZHVhbCBjaGFuZ2VzIGluIHBh
dGNoZXMNCj4+DQo+PiBMaW5rIG9uIFYxOg0KPj4gLSBodHRwczovL2xpc3RzLnhlbnByb2plY3Qu
b3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDcvbXNnMDE4MDkuaHRtbA0KPj4NCj4+
IExlb25pZCBLb21hcmlhbnNreWkgKDEyKToNCj4+ICAgIHhlbi9hcm06IGdpY3YzOiByZWZhY3Rv
ciBvYnRhaW5pbmcgR0lDIGFkZHJlc3NlcyBmb3IgY29tbW9uIG9wZXJhdGlvbnMNCj4+ICAgIHhl
bi9hcm06IGdpYzogaW1wbGVtZW50IGhlbHBlciBmdW5jdGlvbnMgZm9yIElOVElEIGNoZWNrcw0K
Pj4gICAgeGVuL2FybTogdmdpYzogaW1wbGVtZW50IGhlbHBlciBmdW5jdGlvbnMgZm9yIHZpcnEg
Y2hlY2tzDQo+PiAgICB4ZW4vYXJtL2lycTogYWRkIGhhbmRsaW5nIGZvciBJUlFzIGluIHRoZSBl
U1BJIHJhbmdlDQo+PiAgICB4ZW4vYXJtOiBnaWN2MzogaW1wbGVtZW50IGhhbmRsaW5nIG9mIEdJ
Q3YzLjEgZVNQSQ0KPj4gICAgeGVuL2FybS9pcnE6IGFsbG93IGVTUEkgcHJvY2Vzc2luZyBpbiB0
aGUgZ2ljX2ludGVycnVwdCBmdW5jdGlvbg0KPj4gICAgeGVuL2FybTogZ2ljdjM6IG1vZGlmeSBJ
Q0hfTFJfUEhZU0lDQUxfTUFTSyB0byBhbGxvdyBlU1BJIHByb2Nlc3NpbmcNCj4+ICAgIHhlbi9h
cm06IHZnaWM6IGFkZCByZXNvdXJjZSBtYW5hZ2VtZW50IGZvciBleHRlbmRlZCBTUElzDQo+PiAg
ICB4ZW4vYXJtOiBkb21haW5fYnVpbGQvZG9tMGxlc3MtYnVpbGQ6IGFkanVzdCBkb21haW5zIGNv
bmZpZyB0byBzdXBwb3J0DQo+PiAgICAgIGVTUElzDQo+PiAgICB4ZW4vYXJtOiB2Z2ljLXYzOiBh
ZGQgZW11bGF0aW9uIG9mIEdJQ3YzLjEgZVNQSSByZWdpc3RlcnMNCj4+ICAgIGRvYy9tYW46IHVw
ZGF0ZSBkZXNjcmlwdGlvbiBmb3IgbnJfc3BpcyB3aXRoIGVTUEkNCj4+ICAgIENIQU5HRUxPRy5t
ZDogYWRkIG1lbnRpb24gb2YgR0lDdjMuMSBlU1BJIHN1cHBvcnQNCj4+DQo+PiAgIENIQU5HRUxP
Ry5tZCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAyICsNCj4+ICAgZG9jcy9tYW4veGwu
Y2ZnLjUucG9kLmluICAgICAgICAgICAgICAgfCAgMTMgKy0NCj4+ICAgeGVuL2FyY2gvYXJtL0tj
b25maWcgICAgICAgICAgICAgICAgICAgfCAgIDggKw0KPj4gICB4ZW4vYXJjaC9hcm0vZG9tMGxl
c3MtYnVpbGQuYyAgICAgICAgICB8ICAgMiArLQ0KPj4gICB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1
aWxkLmMgICAgICAgICAgICB8ICAgMiArLQ0KPj4gICB4ZW4vYXJjaC9hcm0vZ2ljLXYzLmMgICAg
ICAgICAgICAgICAgICB8IDE5NSArKysrKysrKysrKysrKysrKysrLS0tLQ0KPj4gICB4ZW4vYXJj
aC9hcm0vZ2ljLmMgICAgICAgICAgICAgICAgICAgICB8ICAgOCArLQ0KPj4gICB4ZW4vYXJjaC9h
cm0vaW5jbHVkZS9hc20vZ2ljLmggICAgICAgICB8ICAyOCArKysrDQo+PiAgIHhlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9naWNfdjNfZGVmcy5oIHwgIDQwICsrKystDQo+PiAgIHhlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9pcnEuaCAgICAgICAgIHwgIDM4ICsrKysrDQo+PiAgIHhlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS92Z2ljLmggICAgICAgIHwgIDU2ICsrKysrKy0NCj4+ICAgeGVuL2FyY2gv
YXJtL2lycS5jICAgICAgICAgICAgICAgICAgICAgfCAgNjIgKysrKysrKy0NCj4+ICAgeGVuL2Fy
Y2gvYXJtL3ZnaWMtdjMuYyAgICAgICAgICAgICAgICAgfCAyMDMgKysrKysrKysrKysrKysrKysr
LS0tLS0NCj4+ICAgeGVuL2FyY2gvYXJtL3ZnaWMuYyAgICAgICAgICAgICAgICAgICAgfCAyMTIg
KysrKysrKysrKysrKysrKysrKysrKystLQ0KPj4gICB4ZW4vYXJjaC9hcm0vdmdpYy92Z2ljLmMg
ICAgICAgICAgICAgICB8ICAgNSArDQo+PiAgIDE1IGZpbGVzIGNoYW5nZWQsIDc2MiBpbnNlcnRp
b25zKCspLCAxMTIgZGVsZXRpb25zKC0pDQo+Pg0KPj4gLS0NCj4+IDIuMzQuMQ0KPj4NCg0KQmVz
dCByZWdhcmRzLA0KTGVvbmlkDQo=


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 02:36:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 02:36:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114453.1461363 (Exim 4.92)
	(envelope-from )
	id 1uvRjR-00063T-Gx; Mon, 08 Sep 2025 02:35:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114453.1461363; Mon, 08 Sep 2025 02: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 1uvRjR-00063K-C0; Mon, 08 Sep 2025 02:35:49 +0000
Received: by outflank-mailman (input) for mailman id 1114453;
 Mon, 08 Sep 2025 02:35:48 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvRjQ-00063E-4G
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 02:35:48 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvRjO-00D1cA-1E;
 Mon, 08 Sep 2025 02:35:46 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvRjO-0032lO-03;
 Mon, 08 Sep 2025 02:35: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=XeQFr5LJiZfsCHspSSZcJv8YjQXYLhlC4Q1QlJJdnic=; b=
	bnCF/7jKifXUMlszmRn98x2a5nJZWOkZdKpcR4acB7r3ELfZ/8Tvwa6Gv909uyO12towKbjqlISh/
	Lw4qxhS4skP0OUHw4N7Q3EF36gIUjX2+lwYXdgwtjgwHICmBxlCTP1DVBtetN5kygDL6R7ZkNFwat
	G0gsByvLmTSLh4GTw=;
From: dmukhin@xen.org
Date: Sun, 7 Sep 2025 19:35:45 -0700
To: Stefano Stabellini 
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 v6 08/15] emul/ns16x50: implement MCR/MSR registers
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-9-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 05, 2025 at 06:42:23PM -0700, Stefano Stabellini wrote:
> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
[..]
> > +            /* Calculate changes in modem status */
> > +            if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> > +                msr_delta |= UART_MSR_DCTS;
> > +            if ( (msr_curr & UART_MSR_DSR) ^ (msr_next & UART_MSR_DSR) )
> > +                msr_delta |= UART_MSR_DDSR;
> > +            if ( (msr_curr & UART_MSR_RI)  & (msr_next & UART_MSR_RI) )
> > +                msr_delta |= UART_MSR_TERI;
> 
> Should this be:
> 
> if ( (msr_curr & UART_MSR_RI) && !(msr_next & UART_MSR_RI) )
>     msr_delta |= UART_MSR_TERI;
> 
> ?

Thanks for the catch!

TL16C550C spec (7.7.10 Modem Status Register (MSR)) says TERI is set on
RI's 0->1 transition:

   if ( !(msr_curr & UART_MSR_RI) && (msr_next & UART_MSR_RI) )


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 02:37:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 02:37:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114464.1461373 (Exim 4.92)
	(envelope-from )
	id 1uvRkz-0006ZG-Pv; Mon, 08 Sep 2025 02:37:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114464.1461373; Mon, 08 Sep 2025 02:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvRkz-0006Z9-MS; Mon, 08 Sep 2025 02:37:25 +0000
Received: by outflank-mailman (input) for mailman id 1114464;
 Mon, 08 Sep 2025 02:37:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvRkz-0006Z3-AQ
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 02:37:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvRkx-00D1dL-35;
 Mon, 08 Sep 2025 02:37:24 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvRkx-0032oH-2v;
 Mon, 08 Sep 2025 02:37: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=1JnmaM64m5deykk9pXOMOarxzpQksjh+tlOOJDuej+A=; b=
	EFR88S09qaqP1ZjhStKrRpiDKEvkDUtFlcUuAERDio6RIluIT/VHNYxGWLwW/31Icdz3+q/BiKJ3f
	Bnz07Xwb/hOJwPOozGmytfjyuZf/jVwlgUjPluREjT276Ih0n9dv+ScpQhxcdkW5wJ5jDblsDRfid
	T+G3sL7A8ODqgwxR8=;
From: dmukhin@xen.org
Date: Sun, 7 Sep 2025 19:37:23 -0700
To: Stefano Stabellini 
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 v6 06/15] emul/ns16x50: implement IER/IIR registers
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-7-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 05, 2025 at 06:42:13PM -0700, Stefano Stabellini wrote:
> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
[..]
> > +static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
> > +{
> > +    struct domain *d = vdev->owner;
> > +    const struct vuart_info *info = vdev->info;
> > +    int vector;
> > +
> > +    if ( has_vpic(d) )
> > +        vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
> > +    else
> > +        ASSERT_UNREACHABLE();
> 
> This seems dangerous as there are guests without vpic

Agreed; will update.


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 02:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 02:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114479.1461383 (Exim 4.92)
	(envelope-from )
	id 1uvRxl-0000hc-Sa; Mon, 08 Sep 2025 02:50:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114479.1461383; Mon, 08 Sep 2025 02: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 1uvRxl-0000hV-PX; Mon, 08 Sep 2025 02:50:37 +0000
Received: by outflank-mailman (input) for mailman id 1114479;
 Mon, 08 Sep 2025 02:50:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvRxl-0000hP-0z
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 02:50:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvRxj-00D1wl-2b;
 Mon, 08 Sep 2025 02:50:36 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvRxj-0033rs-2D;
 Mon, 08 Sep 2025 02:50: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=hIv4ykq8ac5blmGw/LxJFPOEr5vgHwq5Zrw9UqPrRio=; b=
	1MiXjEco+hXgMNfLrEX/eOS94NBciA9y8/XMjgkUT/hV/dYyTWgyxAxzTHg+z/k1ltM1yv+BBUhT1
	M67KP6T9RdzezkqrLEBgcv8Qdi5iuS1T4QT+1kBfGWgEZKaGY6rxHJp7YQQypQe7dwmBe7UTkNSsg
	FpuiKsAnOboQNzp3o=;
From: dmukhin@xen.org
Date: Sun, 7 Sep 2025 19:50:34 -0700
To: Stefano Stabellini 
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 v6 10/15] emul/ns16x50: implement THR register
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-11-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 05, 2025 at 06:59:30PM -0700, Stefano Stabellini wrote:
> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
[..]
> > @@ -439,6 +523,16 @@ static int ns16x50_io_read8(
> >  
> >          case UART_IIR: /* RO */
> >              val = ns16x50_iir_get(vdev);
> > +
> > +            /*
> > +             * Since there's no baud rate emulation, transmits are immediate
> > +             * to the guest. Clear IIR scratch location to make sure there
> > +             * will be interrupt generated once guest re-enabled ETHREI in
> > +             * IER.
> > +             */
> > +            if ( val & UART_IIR_THR )
> > +                regs[NS16X50_REGS_NUM + UART_IIR] &= ~UART_IIR_THR;
> 
> Why clear UART_IIR_THR here?
> 
> UART_IIR_THR should be set if the out buffer is not full and should not
> be set of the out buffer is full?

Now that the THR/FCR register emulation _may_ clear UART_IIR_THR, clearing
UART_IIR_THR here is not needed. 

Thanks for the catch!

> 
> Given that the only function adding to out is ns16x50_fifo_tx_putchar,
> and given that ns16x50_fifo_tx_putchar clears the out buffer when full
> by calling ns16x50_fifo_tx_flush if ns16x50_fifo_tx_full, then basically
> we can keep UART_IIR_THR set all the time?


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 03:15:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 03:15:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114489.1461392 (Exim 4.92)
	(envelope-from )
	id 1uvSMD-0003wI-OQ; Mon, 08 Sep 2025 03:15:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114489.1461392; Mon, 08 Sep 2025 03: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 1uvSMD-0003wB-Lo; Mon, 08 Sep 2025 03:15:53 +0000
Received: by outflank-mailman (input) for mailman id 1114489;
 Mon, 08 Sep 2025 03:15:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvSMC-0003w5-NQ
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 03:15:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvSMB-00D3HK-0P;
 Mon, 08 Sep 2025 03:15:51 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvSMA-003539-2g;
 Mon, 08 Sep 2025 03:15:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=b02hY5xdTXgGaW/vnijrXuVWCcO0U4LAszGpLLLq9Zc=; b=
	qaFkG+dDQCU7C0UTOjPd8krRbf4rxMKV2F/h7MrtOJatsa4dtPD/BP3VO0MDwQ5fQnjH4VBMR5CqI
	RBq0/gvHuEunRNH2ahGZv5MMbjXomK4A4o++UtIzRyBUfncTtZOhOLGIjODl+gncz9Oyw2RyzDBgW
	M5pk1tBOvSn6Rj0IQ=;
From: dmukhin@xen.org
Date: Sun, 7 Sep 2025 20:15:49 -0700
To: Stefano Stabellini 
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 v6 10/15] emul/ns16x50: implement THR register
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-11-dmukhin@ford.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Sun, Sep 07, 2025 at 07:50:34PM -0700, dmukhin@xen.org wrote:
> On Fri, Sep 05, 2025 at 06:59:30PM -0700, Stefano Stabellini wrote:
> > On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> > > From: Denis Mukhin  
> [..]
> > > @@ -439,6 +523,16 @@ static int ns16x50_io_read8(
> > >  
> > >          case UART_IIR: /* RO */
> > >              val = ns16x50_iir_get(vdev);
> > > +
> > > +            /*
> > > +             * Since there's no baud rate emulation, transmits are immediate
> > > +             * to the guest. Clear IIR scratch location to make sure there
> > > +             * will be interrupt generated once guest re-enabled ETHREI in
> > > +             * IER.
> > > +             */
> > > +            if ( val & UART_IIR_THR )
> > > +                regs[NS16X50_REGS_NUM + UART_IIR] &= ~UART_IIR_THR;
> > 
> > Why clear UART_IIR_THR here?
> > 
> > UART_IIR_THR should be set if the out buffer is not full and should not
> > be set of the out buffer is full?
> 
> Now that the THR/FCR register emulation _may_ clear UART_IIR_THR, clearing
> UART_IIR_THR here is not needed. 
> 
> Thanks for the catch!

Clarification: I reworked the code to report UART_IIR_THR based on
ns16x50_fifo_tx_full() status.

> 
> > 
> > Given that the only function adding to out is ns16x50_fifo_tx_putchar,
> > and given that ns16x50_fifo_tx_putchar clears the out buffer when full
> > by calling ns16x50_fifo_tx_flush if ns16x50_fifo_tx_full, then basically
> > we can keep UART_IIR_THR set all the time?
> 


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 03:37:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 03:37:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114503.1461403 (Exim 4.92)
	(envelope-from )
	id 1uvSh6-0006gh-Ee; Mon, 08 Sep 2025 03:37:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114503.1461403; Mon, 08 Sep 2025 03:37: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 1uvSh6-0006ga-Br; Mon, 08 Sep 2025 03:37:28 +0000
Received: by outflank-mailman (input) for mailman id 1114503;
 Mon, 08 Sep 2025 03:37:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvSh4-0006gU-Mt
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 03:37:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvSh3-00D3lx-0s;
 Mon, 08 Sep 2025 03:37:25 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvSh2-0035zp-30;
 Mon, 08 Sep 2025 03:37: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=e59sqOczWYhxASSpbuj8sGhJWnsSzTU2AAPRal8vFYA=; b=IkiijazLAHxujJJxOXE5mKE6HR
	SOPCETJbcXWViqQ4T/bVJjYxwklJN+6rV5oxCWwNJTgtewX1HgA5dCd/VfjwkVa0epw4C3hSIVOGp
	ZQozgP9iEVWLoXSuAatFMVn4BK+nc/8tvBn60Dpv/dt3DdzO0YNqGpmyVgM76itxwp+0=;
From: dmukhin@xen.org
Date: Sun, 7 Sep 2025 20:37:24 -0700
To: Mykola Kvach 
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 05/15] emul/ns16x50: implement SCR register
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-6-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 Sun, Sep 07, 2025 at 12:24:24AM +0300, Mykola Kvach wrote:
> Hi Denis,
> 
> On Sat, Sep 6, 2025 at 2:27 AM  wrote:
> >
> > From: Denis Mukhin 
> >
> > Add SCR register emulation to the I/O port handler.
> > Firmware (e.g. OVMF) may use SCR during the guest OS boot.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v5:
> > - moved earlier in the series to simplify I/O handler population in
> >   the follow on patches
> > - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-11-dmukhin@ford.com/
> > ---
> >  xen/common/emul/vuart/ns16x50.c | 27 +++++++++++++++++++++++++++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > index 7f479a5be4a2..51ec85e57627 100644
> > --- a/xen/common/emul/vuart/ns16x50.c
> > +++ b/xen/common/emul/vuart/ns16x50.c
> > @@ -103,6 +103,20 @@ static int ns16x50_io_write8(
> >
> >      if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
> >          regs[NS16X50_REGS_NUM + reg] = val;
> > +    else
> > +    {
> > +        switch ( reg )
> > +        {
> > +        /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
> > +        case UART_SCR:
> > +            regs[UART_SCR] = val;
> > +            break;
> > +
> > +        default:
> > +            rc = -EINVAL;
> 
> In the previous commit, when ns16x50_dlab_get() was zero and UART_DLL
> or UART_DLM was accessed, the function returned 0. With this commit,
> the behavior changes: now an -EINVAL error is returned for both DLL
> and DLM when ns16x50_dlab_get() is zero.
> 
> Should this be fixed in the previous commit, or is this change
> intentional in this one? Note that for 16-bit accesses you already
> return an error when ns16x50_dlab_get() is zero, so the behavior is
> inconsistent for 8-bit accesses to DLL/DLM.

I agree, it makes sense to move the switch() block with default register
handling to the previous DLL/DLM commit; will update.

Thanks!


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 06:39:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 06:39:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114564.1461413 (Exim 4.92)
	(envelope-from )
	id 1uvVXG-0002RM-GL; Mon, 08 Sep 2025 06:39:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114564.1461413; Mon, 08 Sep 2025 06:39:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvVXG-0002RE-B3; Mon, 08 Sep 2025 06:39:30 +0000
Received: by outflank-mailman (input) for mailman id 1114564;
 Mon, 08 Sep 2025 06:39: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 1uvVXF-0002R1-36
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 06:39:29 +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 8e71b9ce-8c7e-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 08:39:23 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b042cc39551so730897766b.0
 for ; Sun, 07 Sep 2025 23:39: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-b0445cb9296sm1598441266b.61.2025.09.07.23.39.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 07 Sep 2025 23:39: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: 8e71b9ce-8c7e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757313563; x=1757918363; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Bp8HBR7B4LrQDoIvCixnbA7tVhRaSijprmRgaRuLK48=;
        b=WOJtB41koFB8wcUs6tfxD39RoUOQYQTBwpdnaiFNG3QHlAJC6s87n+8pT1kyNpcxhh
         CmR/rlvAxidM3yU4dq7o8A6LNj8tpZPWSjK2n1rIaMbjPy29aEK4J26/zUZhNFzDn07q
         UE2IIwYmvJGw4zVXkuZGazbyd/fsY0Hu++rYQYjYyITc3O5SAenEWxAaulttys6Heebn
         NCNgAgJTmZFXVeZLJ+e4ZkGpdPtnbSgQVwhn/1a2S/uOIUDWFc5i0SaSznfCzpiB8Prf
         f+VOBx3IazQ2oai+24WcQaFiDFh0ILYTDAAqxvTFsp+dxUnpXPSkIvkceR2qPPFOomM3
         AeyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757313563; x=1757918363;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Bp8HBR7B4LrQDoIvCixnbA7tVhRaSijprmRgaRuLK48=;
        b=WMkKefn8F8pxJbpbzl4KdWaR9fh4PpFa9KxrmLyfJFjTCrwNmJffq2SDXVTaoxOIOY
         lLnFHWKXqIUuO0i2zOWdrZF6gYqicFzt5dK6VxUpquf6d3AxUuKCaRMriepZNG6MDeWv
         jTmgBPcf7AXy5yyN/PPFPSim4XUJAPsZX1xZPcu3De1bP7KT0Sekq0JHbsJ9DJWrGbiT
         sJqfmTIffusrluv+c9AbTcp0/lVlVnh+Soat2NNuoZHcoLscY+qsxC/Dq7eIJRYYn1P+
         /Obsi+xK49N6fFxRt+Jdckxsa/XjBYKrBLEMx+IcHEShuPmc8NC1k5BRETAG23/WdIva
         pMgw==
X-Forwarded-Encrypted: i=1; AJvYcCVMYC+20QWLL/dJuAPTotmjIDtmyE2cfzZ5fT4OiaAhxUpuv6hsgeBOfSnQqFa5bNVbsuiUumeZ1XM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxqkDHQ3QTLlFYY0DAnN1DGGmcWQsDtvCxJwFSXgpq02LI7fTPL
	privALNCgHJyP/SLgvOq9TZ3tLD/u8YE2f6LforqTX+vgNM58mfL9hP2nXN8M1ztGg==
X-Gm-Gg: ASbGncsjVzIgxxAg8Yi5NDk65Yq69Fs2Ijlym9P0HWjPRg41swAkyoyEufqvsj8xB1Z
	z5fiagnu7wPnZl3xR6stqndeh9lMh5rknJNNbF2d6jdNTCb52Hp1zOV3bbxFnQvItEYGeZnLcLw
	5QfYVcn1Qmfunte7Xkjpd6hI4gLvh31d21HP9jjaWt2iHO2hGbpZYFe7rlbraN2/JQRwmi2b6xQ
	jZuI/5Bc1tgSTrX+GivrwHx/QZmeKnxeaPTbtn7gKUZ24DVrxllAt1lOXoMwx3e44q8/UkVhgES
	i/1uU9b8mY7QOV6xfUXSY82zAVb6sycN3ilH/1WP6e7HpfxmNthUHUnnSxC3ofqQsN0i2pFj2QV
	DTKYGYzGXU4WBd5lFDNwRSS79Drf2PzXrAQUtSQh6OCUAw5tTFNjpCTpQW2wF6EvhHH6057m7Ou
	nwzfBUf51fBtda1deaxA==
X-Google-Smtp-Source: AGHT+IGAHohBA3R7J0N1DDaHRrVZCreIwFn5O97Zt0sTrKiV3fzBZgQNMc8oJfZ+jnAawsSk9Jwgzg==
X-Received: by 2002:a17:906:6a04:b0:b04:6264:cf7c with SMTP id a640c23a62f3a-b04b16dd3bfmr659070566b.44.1757313562737;
        Sun, 07 Sep 2025 23:39:22 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 08:39:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/apic: Avoid infinite loop in
 io_apic_level_ack_pending()
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250904215137.135529-1-jason.andryuk@amd.com>
 <57fedb53-18b7-4d81-acc8-2756a899ef90@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.09.2025 22:34, Jason Andryuk wrote:
> On 2025-09-05 03:39, Jan Beulich wrote:
>> On 04.09.2025 23:51, Jason Andryuk wrote:
>>> io_apic_level_ack_pending() will end up in an infinite loop if
>>> entry->pin == -1.  entry does not change, so it will keep reading -1.
>>>
>>> Switched to breaking out of the loop.
>>>
>>> Fixes: f821102450a1 ("x86: IRQ Migration logic enhancement.")
>>> Signed-off-by: Jason Andryuk 
>>> ---
>>> Noticed during code inspection.
>>
>> Well spotted, just that ...
>>
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -1715,7 +1715,7 @@ static bool io_apic_level_ack_pending(unsigned int irq)
>>>   
>>>           pin = entry->pin;
>>>           if (pin == -1)
>>> -            continue;
>>> +            break;
>>
>> ... we shouldn't terminate the loop here, but rather continue with the next
>> entry in the list (if any). Hence presumably why "continue" was used, without
>> achieving the intended effect.
> 
> Ok, makes sense.  Though after the sending the patch, I was wondering if 
> it was an unreachable condition, and we should not end up here with pin 
> == -1.

I can't exclude that, but other code (e.g. add_pin_to_irq()) also deal with
this case.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 06:41:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 06:41:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114575.1461423 (Exim 4.92)
	(envelope-from )
	id 1uvVZF-0003vc-On; Mon, 08 Sep 2025 06:41:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114575.1461423; Mon, 08 Sep 2025 06:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvVZF-0003vV-Lv; Mon, 08 Sep 2025 06:41:33 +0000
Received: by outflank-mailman (input) for mailman id 1114575;
 Mon, 08 Sep 2025 06:41:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvVZD-0003u7-Qe
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 06:41:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvVZC-00D8eL-16;
 Mon, 08 Sep 2025 06:41:30 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvVZC-003G39-0b;
 Mon, 08 Sep 2025 06:41: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=Hcilh4XarxLGkR/XmXPgpiioSEjlcB8Ro1sgkDWwIVI=; b=M1IA2GHV9JuhBaXm0r//r18t1Z
	uiegjch7DzIf6FzfC/UP0nUlWqtabjhAmbxTh/N0tBT5TFhYZ0y9hQt7bxivdvVvi04YxF1Rt38I/
	8D03EmvficKxDAe0nyqjYp365Mtqj1Po0ikVDHv/8SdDUxqOLT1enkLlmZt6WsqpLWh0=;
From: dmukhin@xen.org
Date: Sun, 7 Sep 2025 23:41:29 -0700
To: Mykola Kvach 
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 04/15] emul/ns16x50: implement DLL/DLM registers
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-5-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 Sun, Sep 07, 2025 at 12:12:08AM +0300, Mykola Kvach wrote:
> Hi Denis,
> 
> On Sat, Sep 6, 2025 at 3:11 AM  wrote:
> >
> > From: Denis Mukhin 
> >
> > Add DLL/DLM registers emulation.
> >
> > DLL/DLM registers report hardcoded 115200 baud rate to the guest OS.
> >
> > Add stub for ns16x50_dlab_get() helper.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v5:
> > - dropped ns16x50_dlab_get() hunk (moved to emulator stub)
> > - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-5-dmukhin@ford.com/
> > ---
> >  xen/common/emul/vuart/ns16x50.c | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
> > index 0462a961e785..7f479a5be4a2 100644
> > --- a/xen/common/emul/vuart/ns16x50.c
> > +++ b/xen/common/emul/vuart/ns16x50.c
> > @@ -97,8 +97,13 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> >  static int ns16x50_io_write8(
> >      struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> >  {
> > +    uint8_t *regs = vdev->regs;
> > +    uint8_t val = *data;
> >      int rc = 0;
> >
> > +    if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
> > +        regs[NS16X50_REGS_NUM + reg] = val;
> 
> Some documentation (e.g., DesignWare DW_apb_uart Databook, v3.04a)
> notes that if the Divisor Latch Registers (DLL and DLH) are set to
> zero, the baud clock is disabled and no serial communications occur.
> 
> Should we handle the zero-divisor case to emulate this behavior more
> accurately?

Good idea, thanks!
I will plumb zero-divisor logic into RBR/THR handling.

> 
> > +
> >      return rc;
> >  }
> >
> > @@ -109,8 +114,16 @@ static int ns16x50_io_write8(
> >  static int ns16x50_io_write16(
> >      struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> >  {
> > +    uint16_t val = *data;
> >      int rc = -EINVAL;
> >
> > +    if ( ns16x50_dlab_get(vdev) && reg == UART_DLL )
> > +    {
> > +        vdev->regs[NS16X50_REGS_NUM + UART_DLL] = val & 0xff;
> > +        vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (val >> 8) & 0xff;
> 
> Instead of hardcoding 0xff here (and in similar lines below), consider
> using UINT8_MAX. This makes it explicit that the value is the maximum
> for a uint8_t and avoids magic numbers.

Thanks for suggestion!
Will update.


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:16:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:16:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114593.1461432 (Exim 4.92)
	(envelope-from )
	id 1uvW6w-00085f-Fh; Mon, 08 Sep 2025 07:16:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114593.1461432; Mon, 08 Sep 2025 07:16: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 1uvW6w-00085Y-DB; Mon, 08 Sep 2025 07:16:22 +0000
Received: by outflank-mailman (input) for mailman id 1114593;
 Mon, 08 Sep 2025 07:16:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvW6v-00085S-Ey
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:16:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvW6t-00D9Ti-2d;
 Mon, 08 Sep 2025 07:16:20 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvW6t-003JRU-2L;
 Mon, 08 Sep 2025 07:16: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=R4a1KEWzdUb7m/MZk5nH0esNuTV5ImuyIj7AA2rSAYY=; b=u6vv2y4qqMg/K8rdRt0Zrjowzp
	9IKmj0QzLYFjm08w5lWXfDvNxfrGc5JEUPakGbYPhX+a3D5taSshcXiQO8W+rVyVvG9cBIJiTciC5
	qXxtudCFMbvUucr0UgA2dp9s+HnQhVhXkFYsLz2XfUrkU+DSO2j4IfJuar8iYJ/fFbFQ=;
From: dmukhin@xen.org
Date: Mon, 8 Sep 2025 00:16:18 -0700
To: Mykola Kvach 
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 01/15] emul/vuart: introduce framework for UART
 emulators
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-2-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 Sat, Sep 06, 2025 at 12:43:01PM +0300, Mykola Kvach wrote:
> Hi Denis,
> 
> On Sat, Sep 6, 2025 at 2:27 AM  wrote:
[..]
> > +
> > +const static struct vuart *
> > +vuart_find_by_console_permission(const struct domain *d)
> 
> Other functions that search for a console (e.g., by compatible string or IO
> range) take an argument to specify what to search by. Here,
> vuart_find_by_console_permission takes no argument and just checks a single
> flag. It might be clearer to either add a flags argument to make it general,
> or rename the function to reflect that it checks only this one permission flag.

Agreed, will update.
Thanks for the suggestion.

> 
> > +{
> > +    const struct vuart *vuart = d->console.vuart;
> > +
> > +    if ( !vuart || !vuart->emulator || !vuart->emulator->put_rx ||
> 
> Looking at vuart_init, vuart->emulator is always set when vuart is valid.
> So the vuart->emulator check seems redundant.

Ack.

> 
> If it is truly needed, the same check should also appear in
> vuart_dump_state and vuart_deinit. Otherwise, for consistency we
> could safely assume vuart->emulator is non-NULL after vuart_init.

Agreed, will update.

> 
> > +         !(vuart->flags & VUART_CONSOLE_INPUT))
> > +        return NULL;
> > +
> > +    return vuart;
> > +}
> > +
> > +struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long addr,
> > +                                     unsigned long size)
> > +{
> > +    struct vuart *vuart = d->console.vuart;
> > +
> > +    if ( !vuart || !vuart->info )
> 
> Is it possible to have a valid vuart pointer without a valid info pointer?

Yes, the vuart->info check is redundant, will drop.

> 
> > +        return NULL;
> > +
> > +    if ( addr >= vuart->info->base_addr &&
> > +         addr + size - 1 <= vuart->info->base_addr + vuart->info->size - 1 )
> > +        return vuart;
> > +
> > +    return NULL;
> > +}
> > +
> > +int vuart_init(struct domain *d, struct vuart_info *info)
> > +{
> > +    const struct vuart_emulator *emulator;
> > +    struct vuart *vuart;
> > +    int rc;
> > +
> > +    if ( d->console.vuart )
> > +        return -EBUSY;
> > +
> > +    emulator = vuart_match_by_compatible(d, info->compatible);
> > +    if ( !emulator )
> > +        return -ENODEV;
> > +
> > +    vuart = xzalloc(typeof(*vuart));
> > +    if ( !vuart )
> > +        return -ENOMEM;
> > +
> > +    vuart->info = xvzalloc(typeof(*info));
> > +    if ( !vuart->info )
> > +    {
> > +        rc = -ENOMEM;
> > +        goto err_out;
> > +    }
> > +    memcpy(vuart->info, info, sizeof(*info));
> > +
> > +    vuart->vdev = emulator->alloc(d, vuart->info);
> > +    if ( IS_ERR(vuart->vdev) )
> > +    {
> > +        rc = PTR_ERR(vuart->vdev);
> > +        goto err_out;
> > +    }
> > +
> > +    vuart->emulator = emulator;
> > +    vuart->owner = d;
> > +    vuart->flags |= VUART_CONSOLE_INPUT;
> > +
> > +    d->console.input_allowed = true;
> > +    d->console.vuart = vuart;
> > +
> > +    return 0;
> > +
> > + err_out:
> > +    if ( vuart )
> 
> As far as I can see, it isn’t possible to reach this point when vuart
> is NULL. The err_out label is only jumped to after vuart has been
> successfully allocated, so the check if (vuart) is redundant.

Right, thanks.

> 
> > +        xvfree(vuart->info);
> > +    xvfree(vuart);
> > +
> > +    return rc;
> > +}
> > +
> > +/*
> > + * Release any resources taken by UART emulators.
> > + *
> > + * NB: no flags are cleared, since currently exit() is called only during
> > + * domain destroy.
> > + */
> > +void vuart_deinit(struct domain *d)
> > +{
> > +    struct vuart *vuart = d->console.vuart;
> > +
> > +    if ( vuart )
> > +    {
> > +        vuart->emulator->free(vuart->vdev);
> > +        xvfree(vuart->info);
> > +    }
> > +    XVFREE(d->console.vuart);
> > +}
> > +
> > +void vuart_dump_state(const struct domain *d)
> > +{
> > +    struct vuart *vuart = d->console.vuart;
> > +
> > +    if ( vuart )
> > +        vuart->emulator->dump_state(vuart->vdev);
> > +}
> > +
> > +/*
> > + * Put character to the *first* suitable emulated UART's FIFO.
> > + */
> 
> This comment could be a single line since it doesn’t exceed 80 characters.

I will update the comment.

> 
> > +int vuart_put_rx(struct domain *d, char c)
> > +{
> > +    const struct vuart *vuart = vuart_find_by_console_permission(d);
> 
> If vuart_deinit has already been called, is it possible that vuart
> points to freed memory here or in other places?
> 
> Should we add reference counting or locks to protect against such
> use-after-free, or are we relying on higher-level mechanisms to
> guarantee that these structs aren’t freed while vuart is accessed?

That should be covered with rcu_{un,}lock_domain() calls.

But a dedicated vUART lock will be needed in the future series (vpl011 and
hwdom vuart plumbing into the new framework).

> 
> Should we also check whether the domain is currently being
> destroyed and avoid putting new characters into the emulated UART
> in that case?

There's only one callsite currently (in the console driver) and it is
guaranteed that domain will not be destroyed during the call.

> 
> If we are relying on some upper-level mechanism, I think it deserves a
> comment somewhere to make that guarantee explicit.

Agree, will add some explanations.

Thanks!


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:32:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114612.1461443 (Exim 4.92)
	(envelope-from )
	id 1uvWMU-0002TS-Tg; Mon, 08 Sep 2025 07:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114612.1461443; Mon, 08 Sep 2025 07: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 1uvWMU-0002TL-Q6; Mon, 08 Sep 2025 07:32:26 +0000
Received: by outflank-mailman (input) for mailman id 1114612;
 Mon, 08 Sep 2025 07: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 1uvWMT-0002TF-3U
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:32:25 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id f3651fed-8c85-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 09:32:19 +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 4F1201692;
 Mon,  8 Sep 2025 00:32:10 -0700 (PDT)
Received: from [10.57.58.69] (unknown [10.57.58.69])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5A2713F63F;
 Mon,  8 Sep 2025 00: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: f3651fed-8c85-11f0-9809-7dc792cee155
Message-ID: <16a63f8a-fe9f-4a65-be45-7260858734bd@arm.com>
Date: Mon, 8 Sep 2025 09:32:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/7] x86/xen: support nested lazy_mmu sections (again)
To: Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , linux-arm-kernel@lists.infradead.org,
 linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-5-kevin.brodsky@arm.com>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05/09/2025 17:48, Alexander Gordeev wrote:
> On Thu, Sep 04, 2025 at 01:57:33PM +0100, Kevin Brodsky wrote:
> ...
>> -static void xen_enter_lazy_mmu(void)
>> +static lazy_mmu_state_t xen_enter_lazy_mmu(void)
>>  {
>> +	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
>> +		return LAZY_MMU_NESTED;
>> +
>>  	enter_lazy(XEN_LAZY_MMU);
>> +	return LAZY_MMU_DEFAULT;
>>  }
>>  
>>  static void xen_flush_lazy_mmu(void)
>> @@ -2167,11 +2171,12 @@ static void __init xen_post_allocator_init(void)
>>  	pv_ops.mmu.write_cr3 = &xen_write_cr3;
>>  }
>>  
>> -static void xen_leave_lazy_mmu(void)
>> +static void xen_leave_lazy_mmu(lazy_mmu_state_t state)
>>  {
>>  	preempt_disable();
>>  	xen_mc_flush();
>> -	leave_lazy(XEN_LAZY_MMU);
>> +	if (state != LAZY_MMU_NESTED)
>> +		leave_lazy(XEN_LAZY_MMU);
> Based on xen_enter_lazy_mmu(), whether this condition needs to be
> executed with the preemption disabled?

AFAIU xen_mc_flush() needs preemption to be disabled. I don't think
{enter,leave}_lazy() do, but this patch doesn't introduce any change
from that perspective. I suppose it doesn't hurt that
xen_leave_lazy_mmu() calls leave_lazy() with preemption disabled.

> Or may be this_cpu_read(xen_lazy_mode) + enter_lazy(XEN_LAZY_MMU)
> should be executed with the preemption disabled?

Adding another this_cpu_read(xen_lazy_mode) in xen_enter_lazy_mmu()
shouldn't change the situation, i.e. preemption should still be safe. If
preemption occurs in the middle of that function,
xen_{start,end}_context_switch() will do the right thing to save/restore
xen_lazy_mode.

- Kevin


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:32:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:32:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114615.1461453 (Exim 4.92)
	(envelope-from )
	id 1uvWMm-0002oa-4q; Mon, 08 Sep 2025 07:32:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114615.1461453; Mon, 08 Sep 2025 07:32: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 1uvWMm-0002oT-1w; Mon, 08 Sep 2025 07:32:44 +0000
Received: by outflank-mailman (input) for mailman id 1114615;
 Mon, 08 Sep 2025 07:32: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 1uvWMk-0002lu-QV
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:32:42 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 00a2eb0b-8c86-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 09:32:41 +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 88AA2169C;
 Mon,  8 Sep 2025 00:32:32 -0700 (PDT)
Received: from [10.57.58.69] (unknown [10.57.58.69])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CFA563F63F;
 Mon,  8 Sep 2025 00:32: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: 00a2eb0b-8c86-11f0-9d13-b5c5bf9af7f9
Message-ID: <1f822d8b-eb46-4998-b1c1-9996d70e1958@arm.com>
Date: Mon, 8 Sep 2025 09:32:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/7] powerpc/mm: support nested lazy_mmu sections
To: Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , linux-arm-kernel@lists.infradead.org,
 linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20250904125736.3918646-1-kevin.brodsky@arm.com>
 <20250904125736.3918646-6-kevin.brodsky@arm.com>
 <074ff6ab-5868-4fde-b5bb-9e17632ad817-agordeev@linux.ibm.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <074ff6ab-5868-4fde-b5bb-9e17632ad817-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05/09/2025 17:52, Alexander Gordeev wrote:
> On Thu, Sep 04, 2025 at 01:57:34PM +0100, Kevin Brodsky wrote:
> ...
>>  static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>>  {
>>  	struct ppc64_tlb_batch *batch;
>> +	int lazy_mmu_nested;
>>  
>>  	if (radix_enabled())
>>  		return LAZY_MMU_DEFAULT;
>> @@ -39,9 +40,14 @@ static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>>  	 */
>>  	preempt_disable();
>>  	batch = this_cpu_ptr(&ppc64_tlb_batch);
>> -	batch->active = 1;
>> +	lazy_mmu_nested = batch->active;
>>  
>> -	return LAZY_MMU_DEFAULT;
>> +	if (!lazy_mmu_nested) {
> Why not just?
>
> 	if (!batch->active) {

Very fair question! I think the extra variable made sense in an earlier
version of that patch, but now it's used only once and doesn't really
improve readability either. Will remove it in v2, also in patch 6
(basically the same code). Thanks!

- Kevin


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:40:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:40:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114633.1461472 (Exim 4.92)
	(envelope-from )
	id 1uvWUV-0004kt-2n; Mon, 08 Sep 2025 07:40:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114633.1461472; Mon, 08 Sep 2025 07:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvWUU-0004km-Vz; Mon, 08 Sep 2025 07:40:42 +0000
Received: by outflank-mailman (input) for mailman id 1114633;
 Mon, 08 Sep 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 1uvWUT-0004k6-NL
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:40:41 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 1d889460-8c87-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 09:40:39 +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 751C0169C;
 Mon,  8 Sep 2025 00:40:30 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 20C3A3F63F;
 Mon,  8 Sep 2025 00: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: 1d889460-8c87-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/7] mm: remove arch_flush_lazy_mmu_mode()
Date: Mon,  8 Sep 2025 08:39:25 +0100
Message-ID: <20250908073931.4159362-2-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This function has only ever been used in arch/x86, so there is no
need for other architectures to implement it. Remove it from
linux/pgtable.h and all architectures besides x86.

The arm64 implementation is not empty but it is only called from
arch_leave_lazy_mmu_mode(), so we can simply fold it there.

Acked-by: Mike Rapoport (Microsoft) 
Signed-off-by: Kevin Brodsky 
---
 arch/arm64/include/asm/pgtable.h                   | 9 +--------
 arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 2 --
 arch/sparc/include/asm/tlbflush_64.h               | 1 -
 arch/x86/include/asm/pgtable.h                     | 3 ++-
 include/linux/pgtable.h                            | 1 -
 5 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index abd2dee416b3..728d7b6ed20a 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -101,21 +101,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
 	set_thread_flag(TIF_LAZY_MMU);
 }
 
-static inline void arch_flush_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(void)
 {
 	if (in_interrupt())
 		return;
 
 	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
 		emit_pte_barriers();
-}
-
-static inline void arch_leave_lazy_mmu_mode(void)
-{
-	if (in_interrupt())
-		return;
 
-	arch_flush_lazy_mmu_mode();
 	clear_thread_flag(TIF_LAZY_MMU);
 }
 
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 146287d9580f..176d7fd79eeb 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -55,8 +55,6 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	preempt_enable();
 }
 
-#define arch_flush_lazy_mmu_mode()      do {} while (0)
-
 extern void hash__tlbiel_all(unsigned int action);
 
 extern void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize,
diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
index 8b8cdaa69272..cd144eb31bdd 100644
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -44,7 +44,6 @@ 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)
 
 /* Local cpu only.  */
 void __flush_tlb_all(void);
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index e33df3da6980..14fd672bc9b2 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -117,7 +117,8 @@ extern pmdval_t early_pmd_flags;
 #define pte_val(x)	native_pte_val(x)
 #define __pte(x)	native_make_pte(x)
 
-#define arch_end_context_switch(prev)	do {} while(0)
+#define arch_end_context_switch(prev)	do {} while (0)
+#define arch_flush_lazy_mmu_mode()	do {} while (0)
 #endif	/* CONFIG_PARAVIRT_XXL */
 
 static inline pmd_t pmd_set_flags(pmd_t pmd, pmdval_t set)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 94249e671a7e..8d6007123cdf 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -234,7 +234,6 @@ static inline int pmd_dirty(pmd_t pmd)
 #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)
 #endif
 
 #ifndef pte_batch_hint
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:40:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:40:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114632.1461464 (Exim 4.92)
	(envelope-from )
	id 1uvWUP-0004W2-TI; Mon, 08 Sep 2025 07:40:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114632.1461464; Mon, 08 Sep 2025 07:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvWUP-0004Vv-P7; Mon, 08 Sep 2025 07:40:37 +0000
Received: by outflank-mailman (input) for mailman id 1114632;
 Mon, 08 Sep 2025 07:40:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvWUN-0004Vn-VO
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:40:35 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 1a96c655-8c87-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 09:40:34 +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 7E6E91692;
 Mon,  8 Sep 2025 00:40:25 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23BFF3F63F;
 Mon,  8 Sep 2025 00:40: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: 1a96c655-8c87-11f0-9d13-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/7] Nesting support for lazy MMU mode
Date: Mon,  8 Sep 2025 08:39:24 +0100
Message-ID: <20250908073931.4159362-1-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When the lazy MMU mode was introduced eons ago, it wasn't made clear
whether such a sequence was legal:

	arch_enter_lazy_mmu_mode()
	...
		arch_enter_lazy_mmu_mode()
		...
		arch_leave_lazy_mmu_mode()
	...
	arch_leave_lazy_mmu_mode()

It seems fair to say that nested calls to
arch_{enter,leave}_lazy_mmu_mode() were not expected, and most
architectures never explicitly supported it.

Ryan Roberts' series from March [1] attempted to prevent nesting from
ever occurring, and mostly succeeded. Unfortunately, a corner case
(DEBUG_PAGEALLOC) may still cause nesting to occur on arm64. Ryan
proposed [2] to address that corner case at the generic level but this
approach received pushback; [3] then attempted to solve the issue on
arm64 only, but it was deemed too fragile.

It feels generally fragile to rely on lazy_mmu sections not to nest,
because callers of various standard mm functions do not know if the
function uses lazy_mmu itself. This series therefore performs a U-turn
and adds support for nested lazy_mmu sections, on all architectures.

The main change enabling nesting is patch 2, following the approach
suggested by Catalin Marinas [4]: have enter() return some state and
the matching leave() take that state. In this series, the state is only
used to handle nesting, but it could be used for other purposes such as
restoring context modified by enter(); the proposed kpkeys framework
would be an immediate user [5].

Patch overview:

* Patch 1: general cleanup - not directly related, but avoids any doubt
  regarding the expected behaviour of arch_flush_lazy_mmu_mode() outside
  x86

* Patch 2: main API change, no functional change

* Patch 3-6: nesting support for all architectures that support lazy_mmu

* Patch 7: clarification that nesting is supported in the documentation

Patch 4-6 are technically not required at this stage since nesting is
only observed on arm64, but they ensure future correctness in case
nesting is (re)introduced in generic paths. For instance, it could be
beneficial in some configurations to enter lazy_mmu set_ptes() once
again.

This series has been tested by running the mm kselfetsts on arm64 with
DEBUG_PAGEALLOC and KFENCE. It was also build-tested on other
architectures (with and without XEN_PV on x86).

- Kevin

[1] https://lore.kernel.org/all/20250303141542.3371656-1-ryan.roberts@arm.com/
[2] https://lore.kernel.org/all/20250530140446.2387131-1-ryan.roberts@arm.com/
[3] https://lore.kernel.org/all/20250606135654.178300-1-ryan.roberts@arm.com/
[4] https://lore.kernel.org/all/aEhKSq0zVaUJkomX@arm.com/
[5] https://lore.kernel.org/linux-hardening/20250815085512.2182322-19-kevin.brodsky@arm.com/
---
Changelog

v1..v2:
- Rebased on mm-unstable.
- Patch 2: handled new calls to enter()/leave(), clarified how the "flush"
  pattern (leave() followed by enter()) is handled.
- Patch 5,6: removed unnecessary local variable [Alexander Gordeev's
  suggestion].
- Added Mike Rapoport's Acked-by.

v1: https://lore.kernel.org/all/20250904125736.3918646-1-kevin.brodsky@arm.com/
---
Cc: Alexander Gordeev 
Cc: Andreas Larsson 
Cc: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Christophe Leroy 
Cc: Dave Hansen 
Cc: David Hildenbrand 
Cc: "David S. Miller" 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jann Horn 
Cc: Juergen Gross 
Cc: "Liam R. Howlett" 
Cc: Lorenzo Stoakes 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Thomas Gleixner 
Cc: Vlastimil Babka 
Cc: Will Deacon 
Cc: Yeoreum Yun 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparclinux@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
Kevin Brodsky (7):
  mm: remove arch_flush_lazy_mmu_mode()
  mm: introduce local state for lazy_mmu sections
  arm64: mm: fully support nested lazy_mmu sections
  x86/xen: support nested lazy_mmu sections (again)
  powerpc/mm: support nested lazy_mmu sections
  sparc/mm: support nested lazy_mmu sections
  mm: update lazy_mmu documentation

 arch/arm64/include/asm/pgtable.h              | 34 ++++++-------------
 .../include/asm/book3s/64/tlbflush-hash.h     | 22 ++++++++----
 arch/powerpc/mm/book3s64/hash_tlb.c           | 10 +++---
 arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +--
 arch/sparc/include/asm/tlbflush_64.h          |  6 ++--
 arch/sparc/mm/tlb.c                           | 17 +++++++---
 arch/x86/include/asm/paravirt.h               |  8 ++---
 arch/x86/include/asm/paravirt_types.h         |  6 ++--
 arch/x86/include/asm/pgtable.h                |  3 +-
 arch/x86/xen/enlighten_pv.c                   |  2 +-
 arch/x86/xen/mmu_pv.c                         | 13 ++++---
 fs/proc/task_mmu.c                            |  5 +--
 include/linux/mm_types.h                      |  3 ++
 include/linux/pgtable.h                       | 21 +++++++++---
 mm/kasan/shadow.c                             |  4 +--
 mm/madvise.c                                  | 20 ++++++-----
 mm/memory.c                                   | 20 ++++++-----
 mm/migrate_device.c                           |  5 +--
 mm/mprotect.c                                 |  5 +--
 mm/mremap.c                                   |  5 +--
 mm/userfaultfd.c                              |  5 +--
 mm/vmalloc.c                                  | 15 ++++----
 mm/vmscan.c                                   | 15 ++++----
 23 files changed, 148 insertions(+), 101 deletions(-)


base-commit: b024763926d2726978dff6588b81877d000159c1
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:40:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:40:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114635.1461483 (Exim 4.92)
	(envelope-from )
	id 1uvWUa-000545-Fp; Mon, 08 Sep 2025 07:40:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114635.1461483; Mon, 08 Sep 2025 07:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvWUa-00053w-As; Mon, 08 Sep 2025 07:40:48 +0000
Received: by outflank-mailman (input) for mailman id 1114635;
 Mon, 08 Sep 2025 07:40:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvWUZ-0004k6-4k
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:40:47 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 20afcf27-8c87-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 09:40:44 +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 B33CE1762;
 Mon,  8 Sep 2025 00:40:35 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1EDB53F63F;
 Mon,  8 Sep 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: 20afcf27-8c87-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Date: Mon,  8 Sep 2025 08:39:26 +0100
Message-ID: <20250908073931.4159362-3-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
(taking and returning no value). This is proving problematic in
situations where leave() needs to restore some context back to its
original state (before enter() was called). In particular, this
makes it difficult to support the nesting of lazy_mmu sections -
leave() does not know whether the matching enter() call occurred
while lazy_mmu was already enabled, and whether to disable it or
not.

This patch gives all architectures the chance to store local state
while inside a lazy_mmu section by making enter() return some value,
storing it in a local variable, and having leave() take that value.
That value is typed lazy_mmu_state_t - each architecture defining
__HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
For now we define it as int everywhere, which is sufficient to
support nesting.

The diff is unfortunately rather large as all the API changes need
to be done atomically. Main parts:

* Changing the prototypes of arch_{enter,leave}_lazy_mmu_mode()
  in generic and arch code, and introducing lazy_mmu_state_t.

* Introducing LAZY_MMU_{DEFAULT,NESTED} for future support of
  nesting. enter() always returns LAZY_MMU_DEFAULT for now.
  (linux/mm_types.h is not the most natural location for defining
  those constants, but there is no other obvious header that is
  accessible where arch's implement the helpers.)

* Changing all lazy_mmu sections to introduce a lazy_mmu_state
  local variable, having enter() set it and leave() take it. Most of
  these changes were generated using the following Coccinelle script:

@@
@@
{
+ lazy_mmu_state_t lazy_mmu_state;
...
- arch_enter_lazy_mmu_mode();
+ lazy_mmu_state = arch_enter_lazy_mmu_mode();
...
- arch_leave_lazy_mmu_mode();
+ arch_leave_lazy_mmu_mode(lazy_mmu_state);
...
}

* In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
  lazy_mmu is already enabled, and it temporarily disables it by
  calling leave() and then enter() again. Here we want to ensure
  that any operation between the leave() and enter() calls is
  completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
  leave() to fully disable lazy_mmu. enter() will then re-enable it
  - this achieves the expected behaviour, whether nesting occurred
  before that function was called or not.

Note: it is difficult to provide a default definition of
lazy_mmu_state_t for architectures implementing lazy_mmu, because
that definition would need to be available in
arch/x86/include/asm/paravirt_types.h and adding a new generic
 #include there is very tricky due to the existing header soup.

Acked-by: Mike Rapoport (Microsoft) 
Signed-off-by: Kevin Brodsky 
---
 arch/arm64/include/asm/pgtable.h              | 10 +++++++---
 .../include/asm/book3s/64/tlbflush-hash.h     |  9 ++++++---
 arch/powerpc/mm/book3s64/hash_tlb.c           | 10 ++++++----
 arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +++--
 arch/sparc/include/asm/tlbflush_64.h          |  5 +++--
 arch/sparc/mm/tlb.c                           |  6 ++++--
 arch/x86/include/asm/paravirt.h               |  6 ++++--
 arch/x86/include/asm/paravirt_types.h         |  2 ++
 arch/x86/xen/enlighten_pv.c                   |  2 +-
 arch/x86/xen/mmu_pv.c                         |  2 +-
 fs/proc/task_mmu.c                            |  5 +++--
 include/linux/mm_types.h                      |  3 +++
 include/linux/pgtable.h                       |  6 ++++--
 mm/kasan/shadow.c                             |  4 ++--
 mm/madvise.c                                  | 20 ++++++++++---------
 mm/memory.c                                   | 20 +++++++++++--------
 mm/migrate_device.c                           |  5 +++--
 mm/mprotect.c                                 |  5 +++--
 mm/mremap.c                                   |  5 +++--
 mm/userfaultfd.c                              |  5 +++--
 mm/vmalloc.c                                  | 15 ++++++++------
 mm/vmscan.c                                   | 15 ++++++++------
 22 files changed, 102 insertions(+), 63 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 728d7b6ed20a..816197d08165 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -81,7 +81,9 @@ static inline void queue_pte_barriers(void)
 }
 
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
-static inline void arch_enter_lazy_mmu_mode(void)
+typedef int lazy_mmu_state_t;
+
+static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	/*
 	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
@@ -96,12 +98,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
 	 */
 
 	if (in_interrupt())
-		return;
+		return LAZY_MMU_DEFAULT;
 
 	set_thread_flag(TIF_LAZY_MMU);
+
+	return LAZY_MMU_DEFAULT;
 }
 
-static inline void arch_leave_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	if (in_interrupt())
 		return;
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 176d7fd79eeb..c9f1e819e567 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -25,13 +25,14 @@ DECLARE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
 extern void __flush_tlb_pending(struct ppc64_tlb_batch *batch);
 
 #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
+typedef int lazy_mmu_state_t;
 
-static inline void arch_enter_lazy_mmu_mode(void)
+static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	struct ppc64_tlb_batch *batch;
 
 	if (radix_enabled())
-		return;
+		return LAZY_MMU_DEFAULT;
 	/*
 	 * apply_to_page_range can call us this preempt enabled when
 	 * operating on kernel page tables.
@@ -39,9 +40,11 @@ static inline void arch_enter_lazy_mmu_mode(void)
 	preempt_disable();
 	batch = this_cpu_ptr(&ppc64_tlb_batch);
 	batch->active = 1;
+
+	return LAZY_MMU_DEFAULT;
 }
 
-static inline void arch_leave_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	struct ppc64_tlb_batch *batch;
 
diff --git a/arch/powerpc/mm/book3s64/hash_tlb.c b/arch/powerpc/mm/book3s64/hash_tlb.c
index 21fcad97ae80..ee664f88e679 100644
--- a/arch/powerpc/mm/book3s64/hash_tlb.c
+++ b/arch/powerpc/mm/book3s64/hash_tlb.c
@@ -189,6 +189,7 @@ void hash__tlb_flush(struct mmu_gather *tlb)
  */
 void __flush_hash_table_range(unsigned long start, unsigned long end)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int hugepage_shift;
 	unsigned long flags;
 
@@ -205,7 +206,7 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
 	 * way to do things but is fine for our needs here.
 	 */
 	local_irq_save(flags);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; start < end; start += PAGE_SIZE) {
 		pte_t *ptep = find_init_mm_pte(start, &hugepage_shift);
 		unsigned long pte;
@@ -217,12 +218,13 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
 			continue;
 		hpte_need_flush(&init_mm, start, ptep, pte, hugepage_shift);
 	}
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	local_irq_restore(flags);
 }
 
 void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte;
 	pte_t *start_pte;
 	unsigned long flags;
@@ -237,7 +239,7 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
 	 * way to do things but is fine for our needs here.
 	 */
 	local_irq_save(flags);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	start_pte = pte_offset_map(pmd, addr);
 	if (!start_pte)
 		goto out;
@@ -249,6 +251,6 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
 	}
 	pte_unmap(start_pte);
 out:
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	local_irq_restore(flags);
 }
diff --git a/arch/powerpc/mm/book3s64/subpage_prot.c b/arch/powerpc/mm/book3s64/subpage_prot.c
index ec98e526167e..4720f9f321af 100644
--- a/arch/powerpc/mm/book3s64/subpage_prot.c
+++ b/arch/powerpc/mm/book3s64/subpage_prot.c
@@ -53,6 +53,7 @@ void subpage_prot_free(struct mm_struct *mm)
 static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
 			     int npages)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pgd_t *pgd;
 	p4d_t *p4d;
 	pud_t *pud;
@@ -73,13 +74,13 @@ static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
 	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
 	if (!pte)
 		return;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; npages > 0; --npages) {
 		pte_update(mm, addr, pte, 0, 0, 0);
 		addr += PAGE_SIZE;
 		++pte;
 	}
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(pte - 1, ptl);
 }
 
diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
index cd144eb31bdd..02c93a4e6af5 100644
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -40,10 +40,11 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
 void flush_tlb_kernel_range(unsigned long start, unsigned long end);
 
 #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
+typedef int lazy_mmu_state_t;
 
 void flush_tlb_pending(void);
-void arch_enter_lazy_mmu_mode(void);
-void arch_leave_lazy_mmu_mode(void);
+lazy_mmu_state_t arch_enter_lazy_mmu_mode(void);
+void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state);
 
 /* Local cpu only.  */
 void __flush_tlb_all(void);
diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index a35ddcca5e76..bf5094b770af 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -50,16 +50,18 @@ void flush_tlb_pending(void)
 	put_cpu_var(tlb_batch);
 }
 
-void arch_enter_lazy_mmu_mode(void)
+lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	struct tlb_batch *tb;
 
 	preempt_disable();
 	tb = this_cpu_ptr(&tlb_batch);
 	tb->active = 1;
+
+	return LAZY_MMU_DEFAULT;
 }
 
-void arch_leave_lazy_mmu_mode(void)
+void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index b5e59a7ba0d0..65a0d394fba1 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -527,12 +527,14 @@ static inline void arch_end_context_switch(struct task_struct *next)
 }
 
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
-static inline void arch_enter_lazy_mmu_mode(void)
+static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
 	PVOP_VCALL0(mmu.lazy_mode.enter);
+
+	return LAZY_MMU_DEFAULT;
 }
 
-static inline void arch_leave_lazy_mmu_mode(void)
+static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
 	PVOP_VCALL0(mmu.lazy_mode.leave);
 }
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 37a8627d8277..bc1af86868a3 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -41,6 +41,8 @@ struct pv_info {
 };
 
 #ifdef CONFIG_PARAVIRT_XXL
+typedef int lazy_mmu_state_t;
+
 struct pv_lazy_ops {
 	/* Set deferred update mode, used for batching operations. */
 	void (*enter)(void);
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 26bbaf4b7330..a245ba47a631 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -426,7 +426,7 @@ static void xen_start_context_switch(struct task_struct *prev)
 	BUG_ON(preemptible());
 
 	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
 		set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES);
 	}
 	enter_lazy(XEN_LAZY_CPU);
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2a4a8deaf612..2039d5132ca3 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2140,7 +2140,7 @@ static void xen_flush_lazy_mmu(void)
 	preempt_disable();
 
 	if (xen_get_lazy_mode() == XEN_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
 		arch_enter_lazy_mmu_mode();
 	}
 
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ced01cf3c5ab..02aa55f83bae 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -2682,6 +2682,7 @@ static int pagemap_scan_thp_entry(pmd_t *pmd, unsigned long start,
 static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 				  unsigned long end, struct mm_walk *walk)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct pagemap_scan_private *p = walk->private;
 	struct vm_area_struct *vma = walk->vma;
 	unsigned long addr, flush_end = 0;
@@ -2700,7 +2701,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 		return 0;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	if ((p->arg.flags & PM_SCAN_WP_MATCHING) && !p->vec_out) {
 		/* Fast path for performing exclusive WP */
@@ -2770,7 +2771,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 	if (flush_end)
 		flush_tlb_range(vma, start, addr);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(start_pte, ptl);
 
 	cond_resched();
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 275e8060d918..143d819c1386 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1489,6 +1489,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm);
 extern void tlb_gather_mmu_fullmm(struct mmu_gather *tlb, struct mm_struct *mm);
 extern void tlb_finish_mmu(struct mmu_gather *tlb);
 
+#define LAZY_MMU_DEFAULT	0
+#define LAZY_MMU_NESTED		1
+
 struct vm_fault;
 
 /**
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 8d6007123cdf..df0eb898b3fc 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -232,8 +232,10 @@ static inline int pmd_dirty(pmd_t pmd)
  * 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)
+typedef int lazy_mmu_state_t;
+
+#define arch_enter_lazy_mmu_mode()	(LAZY_MMU_DEFAULT)
+#define arch_leave_lazy_mmu_mode(state)	((void)(state))
 #endif
 
 #ifndef pte_batch_hint
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index 5d2a876035d6..60b1b72f5ce1 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -305,7 +305,7 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
 	pte_t pte;
 	int index;
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
 
 	index = PFN_DOWN(addr - data->start);
 	page = data->pages[index];
@@ -482,7 +482,7 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
 	pte_t pte;
 	int none;
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
 
 	spin_lock(&init_mm.page_table_lock);
 	pte = ptep_get(ptep);
diff --git a/mm/madvise.c b/mm/madvise.c
index 35ed4ab0d7c5..72c032f2cf56 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -357,6 +357,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				unsigned long addr, unsigned long end,
 				struct mm_walk *walk)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct madvise_walk_private *private = walk->private;
 	struct mmu_gather *tlb = private->tlb;
 	bool pageout = private->pageout;
@@ -455,7 +456,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	if (!start_pte)
 		return 0;
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
 		nr = 1;
 		ptent = ptep_get(pte);
@@ -463,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 		if (++batch_count == SWAP_CLUSTER_MAX) {
 			batch_count = 0;
 			if (need_resched()) {
-				arch_leave_lazy_mmu_mode();
+				arch_leave_lazy_mmu_mode(lazy_mmu_state);
 				pte_unmap_unlock(start_pte, ptl);
 				cond_resched();
 				goto restart;
@@ -499,7 +500,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				if (!folio_trylock(folio))
 					continue;
 				folio_get(folio);
-				arch_leave_lazy_mmu_mode();
+				arch_leave_lazy_mmu_mode(lazy_mmu_state);
 				pte_unmap_unlock(start_pte, ptl);
 				start_pte = NULL;
 				err = split_folio(folio);
@@ -510,7 +511,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				if (!start_pte)
 					break;
 				flush_tlb_batched_pending(mm);
-				arch_enter_lazy_mmu_mode();
+				lazy_mmu_state = arch_enter_lazy_mmu_mode();
 				if (!err)
 					nr = 0;
 				continue;
@@ -558,7 +559,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	}
 
 	if (start_pte) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(lazy_mmu_state);
 		pte_unmap_unlock(start_pte, ptl);
 	}
 	if (pageout)
@@ -657,6 +658,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 
 {
 	const cydp_t cydp_flags = CYDP_CLEAR_YOUNG | CYDP_CLEAR_DIRTY;
+	lazy_mmu_state_t lazy_mmu_state;
 	struct mmu_gather *tlb = walk->private;
 	struct mm_struct *mm = tlb->mm;
 	struct vm_area_struct *vma = walk->vma;
@@ -677,7 +679,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!start_pte)
 		return 0;
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	for (; addr != end; pte += nr, addr += PAGE_SIZE * nr) {
 		nr = 1;
 		ptent = ptep_get(pte);
@@ -727,7 +729,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 				if (!folio_trylock(folio))
 					continue;
 				folio_get(folio);
-				arch_leave_lazy_mmu_mode();
+				arch_leave_lazy_mmu_mode(lazy_mmu_state);
 				pte_unmap_unlock(start_pte, ptl);
 				start_pte = NULL;
 				err = split_folio(folio);
@@ -738,7 +740,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 				if (!start_pte)
 					break;
 				flush_tlb_batched_pending(mm);
-				arch_enter_lazy_mmu_mode();
+				lazy_mmu_state = arch_enter_lazy_mmu_mode();
 				if (!err)
 					nr = 0;
 				continue;
@@ -778,7 +780,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	if (nr_swap)
 		add_mm_counter(mm, MM_SWAPENTS, nr_swap);
 	if (start_pte) {
-		arch_leave_lazy_mmu_mode();
+		arch_leave_lazy_mmu_mode(lazy_mmu_state);
 		pte_unmap_unlock(start_pte, ptl);
 	}
 	cond_resched();
diff --git a/mm/memory.c b/mm/memory.c
index d9de6c056179..a60aae069f1e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1207,6 +1207,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	       pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
 	       unsigned long end)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct mm_struct *dst_mm = dst_vma->vm_mm;
 	struct mm_struct *src_mm = src_vma->vm_mm;
 	pte_t *orig_src_pte, *orig_dst_pte;
@@ -1254,7 +1255,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
 	orig_src_pte = src_pte;
 	orig_dst_pte = dst_pte;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		nr = 1;
@@ -1323,7 +1324,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	} while (dst_pte += nr, src_pte += nr, addr += PAGE_SIZE * nr,
 		 addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(orig_src_pte, src_ptl);
 	add_mm_rss_vec(dst_mm, rss);
 	pte_unmap_unlock(orig_dst_pte, dst_ptl);
@@ -1822,6 +1823,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 				unsigned long addr, unsigned long end,
 				struct zap_details *details)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	bool force_flush = false, force_break = false;
 	struct mm_struct *mm = tlb->mm;
 	int rss[NR_MM_COUNTERS];
@@ -1842,7 +1844,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		return addr;
 
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	do {
 		bool any_skipped = false;
 
@@ -1874,7 +1876,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		direct_reclaim = try_get_and_clear_pmd(mm, pmd, &pmdval);
 
 	add_mm_rss_vec(mm, rss);
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 
 	/* Do the actual TLB flush before dropping ptl */
 	if (force_flush) {
@@ -2811,6 +2813,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			unsigned long addr, unsigned long end,
 			unsigned long pfn, pgprot_t prot)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte, *mapped_pte;
 	spinlock_t *ptl;
 	int err = 0;
@@ -2818,7 +2821,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 	mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
 	if (!pte)
 		return -ENOMEM;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	do {
 		BUG_ON(!pte_none(ptep_get(pte)));
 		if (!pfn_modify_allowed(pfn, prot)) {
@@ -2828,7 +2831,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 		set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
 		pfn++;
 	} while (pte++, addr += PAGE_SIZE, addr != end);
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(mapped_pte, ptl);
 	return err;
 }
@@ -3117,6 +3120,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 				     pte_fn_t fn, void *data, bool create,
 				     pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte, *mapped_pte;
 	int err = 0;
 	spinlock_t *ptl;
@@ -3135,7 +3139,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			return -EINVAL;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	if (fn) {
 		do {
@@ -3148,7 +3152,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 	}
 	*mask |= PGTBL_PTE_MODIFIED;
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 
 	if (mm != &init_mm)
 		pte_unmap_unlock(mapped_pte, ptl);
diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index abd9f6850db6..833ce5eafa40 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -59,6 +59,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 				   unsigned long end,
 				   struct mm_walk *walk)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct migrate_vma *migrate = walk->private;
 	struct folio *fault_folio = migrate->fault_page ?
 		page_folio(migrate->fault_page) : NULL;
@@ -110,7 +111,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 	ptep = pte_offset_map_lock(mm, pmdp, addr, &ptl);
 	if (!ptep)
 		goto again;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	for (; addr < end; addr += PAGE_SIZE, ptep++) {
 		struct dev_pagemap *pgmap;
@@ -287,7 +288,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 	if (unmapped)
 		flush_tlb_range(walk->vma, start, end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(ptep - 1, ptl);
 
 	return 0;
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 113b48985834..7bba651e5aa3 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -273,6 +273,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 		struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr,
 		unsigned long end, pgprot_t newprot, unsigned long cp_flags)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte, oldpte;
 	spinlock_t *ptl;
 	long pages = 0;
@@ -293,7 +294,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 		target_node = numa_node_id();
 
 	flush_tlb_batched_pending(vma->vm_mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 	do {
 		nr_ptes = 1;
 		oldpte = ptep_get(pte);
@@ -439,7 +440,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 			}
 		}
 	} while (pte += nr_ptes, addr += nr_ptes * PAGE_SIZE, addr != end);
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(pte - 1, ptl);
 
 	return pages;
diff --git a/mm/mremap.c b/mm/mremap.c
index 35de0a7b910e..a562d8cf1eee 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -193,6 +193,7 @@ static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr
 static int move_ptes(struct pagetable_move_control *pmc,
 		unsigned long extent, pmd_t *old_pmd, pmd_t *new_pmd)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	struct vm_area_struct *vma = pmc->old;
 	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
 	struct mm_struct *mm = vma->vm_mm;
@@ -256,7 +257,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
 	if (new_ptl != old_ptl)
 		spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
 	flush_tlb_batched_pending(vma->vm_mm);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	for (; old_addr < old_end; old_ptep += nr_ptes, old_addr += nr_ptes * PAGE_SIZE,
 		new_ptep += nr_ptes, new_addr += nr_ptes * PAGE_SIZE) {
@@ -301,7 +302,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
 		}
 	}
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	if (force_flush)
 		flush_tlb_range(vma, old_end - len, old_end);
 	if (new_ptl != old_ptl)
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 50aaa8dcd24c..6ee71ba68b12 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -1076,6 +1076,7 @@ static long move_present_ptes(struct mm_struct *mm,
 			      struct folio **first_src_folio, unsigned long len,
 			      struct anon_vma *src_anon_vma)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int err = 0;
 	struct folio *src_folio = *first_src_folio;
 	unsigned long src_start = src_addr;
@@ -1100,7 +1101,7 @@ static long move_present_ptes(struct mm_struct *mm,
 	/* It's safe to drop the reference now as the page-table is holding one. */
 	folio_put(*first_src_folio);
 	*first_src_folio = NULL;
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	while (true) {
 		orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte);
@@ -1138,7 +1139,7 @@ static long move_present_ptes(struct mm_struct *mm,
 			break;
 	}
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	if (src_addr > src_start)
 		flush_tlb_range(src_vma, src_start, src_addr);
 
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 4249e1e01947..9fc86ddf1711 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -95,6 +95,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			phys_addr_t phys_addr, pgprot_t prot,
 			unsigned int max_page_shift, pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte;
 	u64 pfn;
 	struct page *page;
@@ -105,7 +106,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	if (!pte)
 		return -ENOMEM;
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		if (unlikely(!pte_none(ptep_get(pte)))) {
@@ -131,7 +132,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 		pfn++;
 	} while (pte += PFN_DOWN(size), addr += size, addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	*mask |= PGTBL_PTE_MODIFIED;
 	return 0;
 }
@@ -354,12 +355,13 @@ int ioremap_page_range(unsigned long addr, unsigned long end,
 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			     pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	pte_t *pte;
 	pte_t ptent;
 	unsigned long size = PAGE_SIZE;
 
 	pte = pte_offset_kernel(pmd, addr);
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 #ifdef CONFIG_HUGETLB_PAGE
@@ -378,7 +380,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 		WARN_ON(!pte_none(ptent) && !pte_present(ptent));
 	} while (pte += (size >> PAGE_SHIFT), addr += size, addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	*mask |= PGTBL_PTE_MODIFIED;
 }
 
@@ -514,6 +516,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 		unsigned long end, pgprot_t prot, struct page **pages, int *nr,
 		pgtbl_mod_mask *mask)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int err = 0;
 	pte_t *pte;
 
@@ -526,7 +529,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!pte)
 		return -ENOMEM;
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		struct page *page = pages[*nr];
@@ -548,7 +551,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 		(*nr)++;
 	} while (pte++, addr += PAGE_SIZE, addr != end);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	*mask |= PGTBL_PTE_MODIFIED;
 
 	return err;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index ca9e1cd3cd68..2872497a0453 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3514,6 +3514,7 @@ static void walk_update_folio(struct lru_gen_mm_walk *walk, struct folio *folio,
 static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 			   struct mm_walk *args)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int i;
 	bool dirty;
 	pte_t *pte;
@@ -3543,7 +3544,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 		return false;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 restart:
 	for (i = pte_index(start), addr = start; addr != end; i++, addr += PAGE_SIZE) {
 		unsigned long pfn;
@@ -3584,7 +3585,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 	if (i < PTRS_PER_PTE && get_next_vma(PMD_MASK, PAGE_SIZE, args, &start, &end))
 		goto restart;
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	pte_unmap_unlock(pte, ptl);
 
 	return suitable_to_scan(total, young);
@@ -3593,6 +3594,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area_struct *vma,
 				  struct mm_walk *args, unsigned long *bitmap, unsigned long *first)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int i;
 	bool dirty;
 	pmd_t *pmd;
@@ -3625,7 +3627,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
 	if (!spin_trylock(ptl))
 		goto done;
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	do {
 		unsigned long pfn;
@@ -3672,7 +3674,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
 
 	walk_update_folio(walk, last, gen, dirty);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 	spin_unlock(ptl);
 done:
 	*first = -1;
@@ -4220,6 +4222,7 @@ static void lru_gen_age_node(struct pglist_data *pgdat, struct scan_control *sc)
  */
 bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 {
+	lazy_mmu_state_t lazy_mmu_state;
 	int i;
 	bool dirty;
 	unsigned long start;
@@ -4271,7 +4274,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 		}
 	}
 
-	arch_enter_lazy_mmu_mode();
+	lazy_mmu_state = arch_enter_lazy_mmu_mode();
 
 	pte -= (addr - start) / PAGE_SIZE;
 
@@ -4305,7 +4308,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 
 	walk_update_folio(walk, last, gen, dirty);
 
-	arch_leave_lazy_mmu_mode();
+	arch_leave_lazy_mmu_mode(lazy_mmu_state);
 
 	/* feedback from rmap walkers to page table walkers */
 	if (mm_state && suitable_to_scan(i, young))
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:40:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:40:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114637.1461493 (Exim 4.92)
	(envelope-from )
	id 1uvWUd-0005Ni-T2; Mon, 08 Sep 2025 07:40:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114637.1461493; Mon, 08 Sep 2025 07: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 1uvWUd-0005NQ-O6; Mon, 08 Sep 2025 07:40:51 +0000
Received: by outflank-mailman (input) for mailman id 1114637;
 Mon, 08 Sep 2025 07:40: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 1uvWUc-0004Vn-Ky
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:40:50 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 23a9796a-8c87-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 09:40:49 +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 AEDB91764;
 Mon,  8 Sep 2025 00:40:40 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5A6C13F63F;
 Mon,  8 Sep 2025 00:40: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: 23a9796a-8c87-11f0-9d13-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 3/7] arm64: mm: fully support nested lazy_mmu sections
Date: Mon,  8 Sep 2025 08:39:27 +0100
Message-ID: <20250908073931.4159362-4-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Despite recent efforts to prevent lazy_mmu sections from nesting, it
remains difficult to ensure that it never occurs - and in fact it
does occur on arm64 in certain situations (CONFIG_DEBUG_PAGEALLOC).
Commit 1ef3095b1405 ("arm64/mm: Permit lazy_mmu_mode to be nested")
made nesting tolerable on arm64, but without truly supporting it:
the inner leave() call clears TIF_LAZY_MMU, disabling the batching
optimisation before the outer section ends.

Now that the lazy_mmu API allows enter() to pass through a state to
the matching leave() call, we can actually support nesting. If
enter() is called inside an active lazy_mmu section, TIF_LAZY_MMU
will already be set, and we can then return LAZY_MMU_NESTED to
instruct the matching leave() call not to clear TIF_LAZY_MMU.

The only effect of this patch is to ensure that TIF_LAZY_MMU (and
therefore the batching optimisation) remains set until the outermost
lazy_mmu section ends. leave() still emits barriers if needed,
regardless of the nesting level, as the caller may expect any
page table changes to become visible when leave() returns.

Signed-off-by: Kevin Brodsky 
---
 arch/arm64/include/asm/pgtable.h | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 816197d08165..602feda97dc4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -85,24 +85,14 @@ typedef int lazy_mmu_state_t;
 
 static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
-	/*
-	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
-	 * does happen with CONFIG_DEBUG_PAGEALLOC, where a page allocation
-	 * inside a lazy_mmu_mode section (such as zap_pte_range()) will change
-	 * permissions on the linear map with apply_to_page_range(), which
-	 * re-enters lazy_mmu_mode. So we tolerate nesting in our
-	 * implementation. The first call to arch_leave_lazy_mmu_mode() will
-	 * flush and clear the flag such that the remainder of the work in the
-	 * outer nest behaves as if outside of lazy mmu mode. This is safe and
-	 * keeps tracking simple.
-	 */
+	int lazy_mmu_nested;
 
 	if (in_interrupt())
 		return LAZY_MMU_DEFAULT;
 
-	set_thread_flag(TIF_LAZY_MMU);
+	lazy_mmu_nested = test_and_set_thread_flag(TIF_LAZY_MMU);
 
-	return LAZY_MMU_DEFAULT;
+	return lazy_mmu_nested ? LAZY_MMU_NESTED : LAZY_MMU_DEFAULT;
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
@@ -113,7 +103,8 @@ static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
 		emit_pte_barriers();
 
-	clear_thread_flag(TIF_LAZY_MMU);
+	if (state != LAZY_MMU_NESTED)
+		clear_thread_flag(TIF_LAZY_MMU);
 }
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:40:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:40:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114644.1461503 (Exim 4.92)
	(envelope-from )
	id 1uvWUk-0005s8-7Q; Mon, 08 Sep 2025 07:40:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114644.1461503; Mon, 08 Sep 2025 07:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvWUk-0005rt-2b; Mon, 08 Sep 2025 07:40:58 +0000
Received: by outflank-mailman (input) for mailman id 1114644;
 Mon, 08 Sep 2025 07:40: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 1uvWUi-0004k6-Gn
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:40:56 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 26a4c947-8c87-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 09:40: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 ACC311BCA;
 Mon,  8 Sep 2025 00:40:45 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 589A33F63F;
 Mon,  8 Sep 2025 00:40: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: 26a4c947-8c87-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
Date: Mon,  8 Sep 2025 08:39:28 +0100
Message-ID: <20250908073931.4159362-5-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode")
originally introduced support for nested lazy sections (LAZY_MMU and
LAZY_CPU). It later got reverted by commit c36549ff8d84 as its
implementation turned out to be intolerant to preemption.

Now that the lazy_mmu API allows enter() to pass through a state to
the matching leave() call, we can support nesting again for the
LAZY_MMU mode in a preemption-safe manner. If xen_enter_lazy_mmu() is
called inside an active lazy_mmu section, xen_lazy_mode will already
be set to XEN_LAZY_MMU and we can then return LAZY_MMU_NESTED to
instruct the matching xen_leave_lazy_mmu() call to leave
xen_lazy_mode unchanged.

The only effect of this patch is to ensure that xen_lazy_mode
remains set to XEN_LAZY_MMU until the outermost lazy_mmu section
ends. xen_leave_lazy_mmu() still calls xen_mc_flush()
unconditionally.

Signed-off-by: Kevin Brodsky 
---
 arch/x86/include/asm/paravirt.h       |  6 ++----
 arch/x86/include/asm/paravirt_types.h |  4 ++--
 arch/x86/xen/mmu_pv.c                 | 11 ++++++++---
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 65a0d394fba1..4ecd3a6b1dea 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -529,14 +529,12 @@ static inline void arch_end_context_switch(struct task_struct *next)
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
 static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 {
-	PVOP_VCALL0(mmu.lazy_mode.enter);
-
-	return LAZY_MMU_DEFAULT;
+	return PVOP_CALL0(lazy_mmu_state_t, mmu.lazy_mode.enter);
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 {
-	PVOP_VCALL0(mmu.lazy_mode.leave);
+	PVOP_VCALL1(mmu.lazy_mode.leave, state);
 }
 
 static inline void arch_flush_lazy_mmu_mode(void)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index bc1af86868a3..b7c567ccbf32 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -45,8 +45,8 @@ typedef int lazy_mmu_state_t;
 
 struct pv_lazy_ops {
 	/* Set deferred update mode, used for batching operations. */
-	void (*enter)(void);
-	void (*leave)(void);
+	lazy_mmu_state_t (*enter)(void);
+	void (*leave)(lazy_mmu_state_t);
 	void (*flush)(void);
 } __no_randomize_layout;
 #endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2039d5132ca3..6e5390ff06a5 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2130,9 +2130,13 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
 #endif
 }
 
-static void xen_enter_lazy_mmu(void)
+static lazy_mmu_state_t xen_enter_lazy_mmu(void)
 {
+	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
+		return LAZY_MMU_NESTED;
+
 	enter_lazy(XEN_LAZY_MMU);
+	return LAZY_MMU_DEFAULT;
 }
 
 static void xen_flush_lazy_mmu(void)
@@ -2167,11 +2171,12 @@ static void __init xen_post_allocator_init(void)
 	pv_ops.mmu.write_cr3 = &xen_write_cr3;
 }
 
-static void xen_leave_lazy_mmu(void)
+static void xen_leave_lazy_mmu(lazy_mmu_state_t state)
 {
 	preempt_disable();
 	xen_mc_flush();
-	leave_lazy(XEN_LAZY_MMU);
+	if (state != LAZY_MMU_NESTED)
+		leave_lazy(XEN_LAZY_MMU);
 	preempt_enable();
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:41:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:41:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114649.1461513 (Exim 4.92)
	(envelope-from )
	id 1uvWUo-0006DJ-Ei; Mon, 08 Sep 2025 07:41:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114649.1461513; Mon, 08 Sep 2025 07:41: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 1uvWUo-0006D2-AH; Mon, 08 Sep 2025 07:41:02 +0000
Received: by outflank-mailman (input) for mailman id 1114649;
 Mon, 08 Sep 2025 07:41: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 1uvWUn-0004k6-Tz
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:41:01 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 2994595e-8c87-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 09:40: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 AE1BA2A2A;
 Mon,  8 Sep 2025 00:40:50 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 538FB3F63F;
 Mon,  8 Sep 2025 00:40: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: 2994595e-8c87-11f0-9809-7dc792cee155
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 5/7] powerpc/mm: support nested lazy_mmu sections
Date: Mon,  8 Sep 2025 08:39:29 +0100
Message-ID: <20250908073931.4159362-6-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The lazy_mmu API now allows nested sections to be handled by arch
code: enter() can return a flag if called inside another lazy_mmu
section, so that the matching call to leave() leaves any
optimisation enabled.

This patch implements that new logic for powerpc: if there is an
active batch, then enter() returns LAZY_MMU_NESTED and the matching
leave() leaves batch->active set. The preempt_{enable,disable} calls
are left untouched as they already handle nesting themselves.

TLB flushing is still done in leave() regardless of the nesting
level, as the caller may rely on it whether nesting is occurring or
not.

Signed-off-by: Kevin Brodsky 
---
 arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index c9f1e819e567..e92bce2efca6 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -39,9 +39,13 @@ static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 	 */
 	preempt_disable();
 	batch = this_cpu_ptr(&ppc64_tlb_batch);
-	batch->active = 1;
 
-	return LAZY_MMU_DEFAULT;
+	if (!batch->active) {
+		batch->active = 1;
+		return LAZY_MMU_DEFAULT;
+	} else {
+		return LAZY_MMU_NESTED;
+	}
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
@@ -54,7 +58,10 @@ static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 
 	if (batch->index)
 		__flush_tlb_pending(batch);
-	batch->active = 0;
+
+	if (state != LAZY_MMU_NESTED)
+		batch->active = 0;
+
 	preempt_enable();
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:41:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:41:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114656.1461523 (Exim 4.92)
	(envelope-from )
	id 1uvWUs-0006eG-Ma; Mon, 08 Sep 2025 07:41:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114656.1461523; Mon, 08 Sep 2025 07: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 1uvWUs-0006e3-JM; Mon, 08 Sep 2025 07:41:06 +0000
Received: by outflank-mailman (input) for mailman id 1114656;
 Mon, 08 Sep 2025 07:41: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 1uvWUr-0004Vn-Qq
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:41:05 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 2c8b214c-8c87-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 09:41:04 +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 A803E2C46;
 Mon,  8 Sep 2025 00:40:55 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 553163F63F;
 Mon,  8 Sep 2025 00:40: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: 2c8b214c-8c87-11f0-9d13-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 6/7] sparc/mm: support nested lazy_mmu sections
Date: Mon,  8 Sep 2025 08:39:30 +0100
Message-ID: <20250908073931.4159362-7-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The lazy_mmu API now allows nested sections to be handled by arch
code: enter() can return a flag if called inside another lazy_mmu
section, so that the matching call to leave() leaves any
optimisation enabled.

This patch implements that new logic for sparc: if there is an
active batch, then enter() returns LAZY_MMU_NESTED and the matching
leave() leaves batch->active set. The preempt_{enable,disable} calls
are left untouched as they already handle nesting themselves.

TLB flushing is still done in leave() regardless of the nesting
level, as the caller may rely on it whether nesting is occurring or
not.

Signed-off-by: Kevin Brodsky 
---
 arch/sparc/mm/tlb.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index bf5094b770af..fdc33438b85f 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -56,9 +56,13 @@ lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
 
 	preempt_disable();
 	tb = this_cpu_ptr(&tlb_batch);
-	tb->active = 1;
 
-	return LAZY_MMU_DEFAULT;
+	if (!tb->active) {
+		tb->active = 1;
+		return LAZY_MMU_DEFAULT;
+	} else {
+		return LAZY_MMU_NESTED;
+	}
 }
 
 void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
@@ -67,7 +71,10 @@ void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
 
 	if (tb->tlb_nr)
 		flush_tlb_pending();
-	tb->active = 0;
+
+	if (state != LAZY_MMU_NESTED)
+		tb->active = 0;
+
 	preempt_enable();
 }
 
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 07:41:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 07:41:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114661.1461533 (Exim 4.92)
	(envelope-from )
	id 1uvWUy-0007Cx-23; Mon, 08 Sep 2025 07:41:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114661.1461533; Mon, 08 Sep 2025 07:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvWUx-0007Bm-UT; Mon, 08 Sep 2025 07:41:11 +0000
Received: by outflank-mailman (input) for mailman id 1114661;
 Mon, 08 Sep 2025 07:41: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 1uvWUw-0004Vn-CG
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 07:41:10 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 2f8933a6-8c87-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 09:41:09 +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 A58261692;
 Mon,  8 Sep 2025 00:41:00 -0700 (PDT)
Received: from e123572-lin.arm.com (e123572-lin.cambridge.arm.com
 [10.1.194.54])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5128D3F63F;
 Mon,  8 Sep 2025 00: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: 2f8933a6-8c87-11f0-9d13-b5c5bf9af7f9
From: Kevin Brodsky 
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Kevin Brodsky ,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" ,
	Ingo Molnar ,
	Jann Horn ,
	Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko ,
	Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka ,
	Will Deacon ,
	Yeoreum Yun ,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 7/7] mm: update lazy_mmu documentation
Date: Mon,  8 Sep 2025 08:39:31 +0100
Message-ID: <20250908073931.4159362-8-kevin.brodsky@arm.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

We now support nested lazy_mmu sections on all architectures
implementing the API. Update the API comment accordingly.

Acked-by: Mike Rapoport (Microsoft) 
Signed-off-by: Kevin Brodsky 
---
 include/linux/pgtable.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index df0eb898b3fc..85cd1fdb914f 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -228,8 +228,18 @@ static inline int pmd_dirty(pmd_t pmd)
  * 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.
+ * held, but for kernel PTE updates, no lock is held). The mode cannot be used
+ * in interrupt context.
+ *
+ * Calls may be nested: an arch_{enter,leave}_lazy_mmu_mode() pair may be called
+ * while the lazy MMU mode has already been enabled. An implementation should
+ * handle this using the state returned by enter() and taken by the matching
+ * leave() call; the LAZY_MMU_{DEFAULT,NESTED} flags can be used to indicate
+ * whether this enter/leave pair is nested inside another or not. (It is up to
+ * the implementation to track whether the lazy MMU mode is enabled at any point
+ * in time.) The expectation is that leave() will flush any batched state
+ * unconditionally, but only leave the lazy MMU mode if the passed state is not
+ * LAZY_MMU_NESTED.
  */
 #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
 typedef int lazy_mmu_state_t;
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:29:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:29:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114769.1461582 (Exim 4.92)
	(envelope-from )
	id 1uvXFX-0006Xy-23; Mon, 08 Sep 2025 08:29:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114769.1461582; Mon, 08 Sep 2025 08:29: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 1uvXFW-0006Xr-Ve; Mon, 08 Sep 2025 08:29:18 +0000
Received: by outflank-mailman (input) for mailman id 1114769;
 Mon, 08 Sep 2025 08:29: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 1uvXFV-0006Xl-Bf
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:29:17 +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 e7d6120d-8c8d-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 10:29:15 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-55f646b1db8so4733298e87.0
 for ; Mon, 08 Sep 2025 01:29: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: e7d6120d-8c8d-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757320155; x=1757924955; 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=m5XwgX+w7vmzVe5+ogaENu7bH4qu0T48FtMnCVFLfY4=;
        b=R167wZWqbWsw17FLwA1mGsCxmmOY4Q/B0bH+27gPi2n2EMOnG+eHP/bmWck3gDqvEp
         QoFD0ZNfxqZDTpUL4fZy20jtBizq4oY2xuC65U7PuPivmjYBFQWwL1tUGs6IQHXsEBD/
         jCCngg9piJm4DmBsMBOVo9DTv1vjKtRtxuUs8WfeLUXdYQYVZ/ZZiN9+Ztk+Vknszvqe
         +tdZPK+BdH9twvZunMxhdOqrKf85DofAA0hYb+JibjUGXDCDFRYEK2cgzACRt0ds+VSh
         KhAQEFoFjw68W2YQaqiRESsCKblCQidEKicikHU047nTtRs/Z4n8WSfueCFn9GBNg/qv
         /00g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757320155; x=1757924955;
        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=m5XwgX+w7vmzVe5+ogaENu7bH4qu0T48FtMnCVFLfY4=;
        b=r8UmE/IhaPCk44edGrn4cYx6C6EGW3fVw/p895QpdcvFkVbwkvavlWFyQCUUz/k6Tk
         QY+2z/eIdViTGiYHsMuzxBRKKpU03nc+8wvyV2XMf2vQIZmtjEhr3iwnFkuonDGn8diL
         Eac1kgvjTKo5WgNb9SqyDYrWJR62jtYyS9jXu6xUlM9fw+0oRfAv9ZxVtYyk6N0E6ZcE
         LzhYbvxcP/n8rNxns7Dlp2gh1jhmIB1NVKprZc/ZP4MjzH1NsDZUutudSaWjpgjSP2j0
         /jGjt5VG5ocCaLsNZnJ5cknU3GjtgWbooBDadzmWE7Vpw9BLSCYsTjUEmNhg2Pyljea/
         QxMQ==
X-Gm-Message-State: AOJu0Yx0T2ORoI3+1s0TW7L23xdso7OjjPbkJnulQthT+Kh7St7XtLRq
	daCvE4/R3W5d5qKeGrbnvpT0Pm39Yv5t5/+BBp4uUHxYU5DKaP4k5z53CuwOGmvMY0dYe1a9ne8
	FvaYfaegS/M7By3qze5z237oLMLDZ2Ac=
X-Gm-Gg: ASbGncvg3vVBJHHS7cU3CDubVJZh7NmlDjTk1hQ1NaGJWEWWM4XWNT4kW8k+ON7btgi
	kbYCdch7ZvX1HdOXR5jNctGN9jbr2+8djk7KJ61nSil3QztDlUL5mezG30mfDlQ2fOdLg5SfkU9
	IKZGj9cEMglYPxbXqpmVarw6oElU2t3Qp6k1de5gBMiyZayjTBjTpCFUBdhqR4A3M7i75/4O0Xt
	y6Sg3qc5JPRgPcb
X-Google-Smtp-Source: AGHT+IGoMiaXmcfr4Hi9v6a6nMwYkPHfSsTfQ+/1kCZKnaZik9KVG3luzVtvUhxih+tFzOzYRcVFiJyWyjcUVZa+uq4=
X-Received: by 2002:a05:6512:401e:b0:55f:6a6a:4955 with SMTP id
 2adb3069b0e04-562617e64e8mr1592662e87.25.1757320154891; Mon, 08 Sep 2025
 01:29:14 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-2-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-2-dmukhin@ford.com>
From: Mykola Kvach 
Date: Mon, 8 Sep 2025 11:29:03 +0300
X-Gm-Features: Ac12FXyoFFwNYZip4VI_yxIiWiRQJRn59GrkYOIN-Vhs7VgxM6zhB_kFqnnULsI
Message-ID: 
Subject: Re: [PATCH v6 01/15] emul/vuart: introduce framework for UART emulators
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 6, 2025 at 2:27=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> 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_VUART_FRAMEWORK, which will be
> automatically enabled once the user enables any UART emulator.
>
> Current implementation supports maximum of one vUART of each kind per dom=
ain.
>
> Use new domain_has_vuart() in the console driver code to check whether to
> forward console input to the domain using vUART.
>
> Enable console forwarding over vUART for hardware domains with a vUART. T=
hat
> enables console forwarding to dom0 on x86, since console can be forwarded=
 only
> to Xen, dom0 and pvshim on x86 as of now.
>
> Note: existing vUARTs are deliberately *not* hooked to the new framework =
to
> minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" =
(i.e.
> minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified.
>
> No functional changes for non-x86 architectures.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - addressed v5 feedback
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-2-=
dmukhin@ford.com/
> ---
>  xen/arch/arm/xen.lds.S         |   1 +
>  xen/arch/ppc/xen.lds.S         |   1 +
>  xen/arch/riscv/xen.lds.S       |   1 +
>  xen/arch/x86/xen.lds.S         |   1 +
>  xen/common/Kconfig             |   2 +
>  xen/common/Makefile            |   1 +
>  xen/common/emul/Kconfig        |   6 ++
>  xen/common/emul/Makefile       |   1 +
>  xen/common/emul/vuart/Kconfig  |   6 ++
>  xen/common/emul/vuart/Makefile |   1 +
>  xen/common/emul/vuart/vuart.c  | 157 +++++++++++++++++++++++++++++++++
>  xen/common/keyhandler.c        |   3 +
>  xen/drivers/char/console.c     |   6 +-
>  xen/include/xen/sched.h        |   4 +
>  xen/include/xen/serial.h       |   3 +
>  xen/include/xen/vuart.h        | 116 ++++++++++++++++++++++++
>  xen/include/xen/xen.lds.h      |  10 +++
>  17 files changed, 319 insertions(+), 1 deletion(-)
>  create mode 100644 xen/common/emul/Kconfig
>  create mode 100644 xen/common/emul/Makefile
>  create mode 100644 xen/common/emul/vuart/Kconfig
>  create mode 100644 xen/common/emul/vuart/Makefile
>  create mode 100644 xen/common/emul/vuart/vuart.c
>  create mode 100644 xen/include/xen/vuart.h
>
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index db17ff1efa98..cd05b18770f4 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -58,6 +58,7 @@ SECTIONS
>         *(.rodata)
>         *(.rodata.*)
>         VPCI_ARRAY
> +       VUART_ARRAY
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
>
> diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
> index 1de0b77fc6b9..f9d4e5b0dcd8 100644
> --- a/xen/arch/ppc/xen.lds.S
> +++ b/xen/arch/ppc/xen.lds.S
> @@ -52,6 +52,7 @@ SECTIONS
>          *(.rodata)
>          *(.rodata.*)
>          VPCI_ARRAY
> +        VUART_ARRAY
>          *(.data.rel.ro)
>          *(.data.rel.ro.*)
>
> diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
> index edcadff90bfe..59dcaa5fef9a 100644
> --- a/xen/arch/riscv/xen.lds.S
> +++ b/xen/arch/riscv/xen.lds.S
> @@ -47,6 +47,7 @@ SECTIONS
>          *(.rodata)
>          *(.rodata.*)
>          VPCI_ARRAY
> +        VUART_ARRAY
>          *(.data.rel.ro)
>          *(.data.rel.ro.*)
>
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 966e514f2034..d877b93a6964 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -132,6 +132,7 @@ SECTIONS
>         *(.rodata)
>         *(.rodata.*)
>         VPCI_ARRAY
> +       VUART_ARRAY
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 76f9ce705f7a..78a32b69e2b2 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -676,4 +676,6 @@ config PM_STATS
>           Enable collection of performance management statistics to aid i=
n
>           analyzing and tuning power/performance characteristics of the s=
ystem
>
> +source "common/emul/Kconfig"
> +
>  endmenu
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 0c7d0f5d46e1..8c8462565050 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) +=3D device-tree/
>  obj-$(CONFIG_IOREQ_SERVER) +=3D dm.o
>  obj-y +=3D domain.o
>  obj-y +=3D domid.o
> +obj-y +=3D emul/
>  obj-y +=3D event_2l.o
>  obj-y +=3D event_channel.o
>  obj-$(CONFIG_EVTCHN_FIFO) +=3D event_fifo.o
> diff --git a/xen/common/emul/Kconfig b/xen/common/emul/Kconfig
> new file mode 100644
> index 000000000000..7c6764d1756b
> --- /dev/null
> +++ b/xen/common/emul/Kconfig
> @@ -0,0 +1,6 @@
> +menu "Domain Emulation Features"
> +       visible if EXPERT
> +
> +source "common/emul/vuart/Kconfig"
> +
> +endmenu
> diff --git a/xen/common/emul/Makefile b/xen/common/emul/Makefile
> new file mode 100644
> index 000000000000..ae0b575c3901
> --- /dev/null
> +++ b/xen/common/emul/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VUART_FRAMEWORK) +=3D vuart/
> diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfi=
g
> new file mode 100644
> index 000000000000..ce1b976b7da7
> --- /dev/null
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -0,0 +1,6 @@
> +config VUART_FRAMEWORK
> +       bool

If VUART_FRAMEWORK has no dependencies, it can be enabled on any
architecture. For example, I tried enabling it on arm64 and the build
fails:

  ./include/xen/vuart.h:26:8: error: redefinition of =E2=80=98struct vuart=
=E2=80=99

Should this config be restricted (e.g. "depends on X86") or the code
adjusted to handle non-x86 architectures properly?

> +
> +menu "UART Emulation"
> +
> +endmenu
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> new file mode 100644
> index 000000000000..97f792dc6641
> --- /dev/null
> +++ b/xen/common/emul/vuart/Makefile
> @@ -0,0 +1 @@
> +obj-y +=3D vuart.o
> diff --git a/xen/common/emul/vuart/vuart.c b/xen/common/emul/vuart/vuart.=
c
> new file mode 100644
> index 000000000000..3dfcba217248
> --- /dev/null
> +++ b/xen/common/emul/vuart/vuart.c
> @@ -0,0 +1,157 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UART emulator framework.
> + *
> + * Copyright 2025 Ford Motor Company
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define for_each_emulator(e) \
> +    for ( e =3D vuart_array_start; e < vuart_array_end; e++ )
> +
> +extern const struct vuart_emulator vuart_array_start[];
> +extern const struct vuart_emulator vuart_array_end[];
> +
> +static const struct vuart_emulator *
> +vuart_match_by_compatible(const struct domain *d, const char *compat)
> +{
> +    const struct vuart_emulator *emulator;
> +
> +    for_each_emulator(emulator)
> +        if ( emulator->compatible &&
> +             !strncmp(compat, emulator->compatible,
> +                      strlen(emulator->compatible)) )
> +            return emulator;
> +
> +    return NULL;
> +}
> +
> +const static struct vuart *
> +vuart_find_by_console_permission(const struct domain *d)

During the first review of this patch I thought you planned to add a
searching procedure into this and the next function in one of the later
commits. However, looking at the series now, it seems these functions
remain unchanged and don=E2=80=99t actually perform any searching.

Do you think the current names are accurate, or would it make sense to
rename them to better reflect their purpose?

> +{
> +    const struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( !vuart || !vuart->emulator || !vuart->emulator->put_rx ||
> +         !(vuart->flags & VUART_CONSOLE_INPUT))
> +        return NULL;
> +
> +    return vuart;
> +}
> +
> +struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long add=
r,
> +                                     unsigned long size)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( !vuart || !vuart->info )
> +        return NULL;
> +
> +    if ( addr >=3D vuart->info->base_addr &&
> +         addr + size - 1 <=3D vuart->info->base_addr + vuart->info->size=
 - 1 )
> +        return vuart;
> +
> +    return NULL;
> +}
> +
> +int vuart_init(struct domain *d, struct vuart_info *info)
> +{
> +    const struct vuart_emulator *emulator;
> +    struct vuart *vuart;
> +    int rc;
> +
> +    if ( d->console.vuart )
> +        return -EBUSY;
> +
> +    emulator =3D vuart_match_by_compatible(d, info->compatible);
> +    if ( !emulator )
> +        return -ENODEV;
> +
> +    vuart =3D xzalloc(typeof(*vuart));
> +    if ( !vuart )
> +        return -ENOMEM;
> +
> +    vuart->info =3D xvzalloc(typeof(*info));
> +    if ( !vuart->info )
> +    {
> +        rc =3D -ENOMEM;
> +        goto err_out;
> +    }
> +    memcpy(vuart->info, info, sizeof(*info));
> +
> +    vuart->vdev =3D emulator->alloc(d, vuart->info);
> +    if ( IS_ERR(vuart->vdev) )
> +    {
> +        rc =3D PTR_ERR(vuart->vdev);
> +        goto err_out;
> +    }
> +
> +    vuart->emulator =3D emulator;
> +    vuart->owner =3D d;
> +    vuart->flags |=3D VUART_CONSOLE_INPUT;
> +
> +    d->console.input_allowed =3D true;
> +    d->console.vuart =3D vuart;
> +
> +    return 0;
> +
> + err_out:
> +    if ( vuart )
> +        xvfree(vuart->info);
> +    xvfree(vuart);
> +
> +    return rc;
> +}
> +
> +/*
> + * Release any resources taken by UART emulators.
> + *
> + * NB: no flags are cleared, since currently exit() is called only durin=
g
> + * domain destroy.
> + */
> +void vuart_deinit(struct domain *d)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart )
> +    {
> +        vuart->emulator->free(vuart->vdev);
> +        xvfree(vuart->info);
> +    }
> +    XVFREE(d->console.vuart);
> +}
> +
> +void vuart_dump_state(const struct domain *d)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart )
> +        vuart->emulator->dump_state(vuart->vdev);
> +}
> +
> +/*
> + * Put character to the *first* suitable emulated UART's FIFO.
> + */
> +int vuart_put_rx(struct domain *d, char c)
> +{
> +    const struct vuart *vuart =3D vuart_find_by_console_permission(d);
> +
> +    return vuart ? vuart->emulator->put_rx(vuart->vdev, c) : -ENODEV;
> +}
> +
> +bool domain_has_vuart(const struct domain *d)
> +{
> +    return vuart_find_by_console_permission(d);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index cb6df2823b00..156e64d9eb58 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  static unsigned char keypress_key;
> @@ -352,6 +353,8 @@ static void cf_check dump_domains(unsigned char key)
>                             v->periodic_period / 1000000);
>              }
>          }
> +
> +        vuart_dump_state(d);
>      }
>
>      for_each_domain ( d )
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9bd5b4825da6..d5164897a776 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_X86
>  #include 
> @@ -596,11 +597,12 @@ static void __serial_rx(char c)
>      if ( !d )
>          return;
>
> -    if ( is_hardware_domain(d) )
> +    if ( is_hardware_domain(d) && !domain_has_vuart(d) )
>      {
>          /*
>           * Deliver input to the hardware domain buffer, unless it is
>           * already full.
> +         * NB: must be the first check: hardware domain may have emulate=
d UART.
>           */
>          if ( (serial_rx_prod - serial_rx_cons) !=3D SERIAL_RX_SIZE )
>              serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] =3D c;
> @@ -611,6 +613,8 @@ static void __serial_rx(char c)
>           */
>          send_global_virq(VIRQ_CONSOLE);
>      }
> +    else if ( domain_has_vuart(d) )
> +        rc =3D vuart_put_rx(d, c);
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
>      else
>          /* Deliver input to the emulated UART. */
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 02bdc256ce37..613f4596e33d 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -660,6 +661,9 @@ struct domain
>      struct {
>          /* Permission to take ownership of the physical console input. *=
/
>          bool input_allowed;
> +#ifdef CONFIG_VUART_FRAMEWORK
> +        struct vuart *vuart;
> +#endif
>      } console;
>  } __aligned(PAGE_SIZE);
>
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 8e1844555208..123eee67df35 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -36,6 +36,9 @@ struct vuart_info {
>      unsigned long data_off;     /* Data register offset */
>      unsigned long status_off;   /* Status register offset */
>      unsigned long status;       /* Ready status value */
> +    unsigned int irq;           /* Interrupt */
> +    char compatible[16];        /* Compatible string */
> +    char name[16];              /* User-friendly name */
>  };
>
>  struct serial_port {
> diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
> new file mode 100644
> index 000000000000..54f2f29f3f4a
> --- /dev/null
> +++ b/xen/include/xen/vuart.h
> @@ -0,0 +1,116 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UART emulator framework.
> + *
> + * Copyright 2025 Ford Motor Company
> + */
> +
> +#ifndef XEN_VUART_H
> +#define XEN_VUART_H
> +
> +#include 
> +#include 
> +
> +struct vuart_emulator;
> +
> +enum {
> +    VUART_CONSOLE_INPUT =3D BIT(0, U), /* Physical console input forward=
ing. */
> +};
> +
> +
> +/*
> + * FIXME: #ifdef is temporary to avoid clash with
> + *   arch/arm/include/asm/domain.h
> + */
> +#ifdef CONFIG_VUART_FRAMEWORK
> +struct vuart {
> +    const struct vuart_emulator *emulator;
> +    struct vuart_info *info;
> +    struct domain *owner;
> +    uint32_t flags;
> +    void *vdev;
> +};
> +#endif
> +
> +struct vuart_emulator {
> +    /* UART compatible string. Cannot be NULL or empty. */
> +    const char *compatible;
> +
> +    /*
> +     * Allocate emulated UART state (RX/TX FIFOs, locks, initialize regi=
sters,
> +     * hook I/O handlers, etc.)
> +     * Cannot be NULL.
> +     */
> +    void *(*alloc)(struct domain *d, const struct vuart_info *info);
> +
> +    /*
> +     * Release resources used to emulate UART state (flush RX/TX FIFOs, =
unhook
> +     * I/O handlers, etc.).
> +     * Cannot be NULL.
> +     */
> +    void (*free)(void *arg);
> +
> +    /*
> +     * Print emulated UART state, including registers, on the console.
> +     * Can be NULL.
> +     */
> +    void (*dump_state)(void *arg);
> +
> +    /*
> +     * Place character to the emulated RX FIFO.
> +     * Used to forward physical console input to the guest OS.
> +     * Can be NULL.
> +     */
> +    int (*put_rx)(void *arg, char c);
> +};
> +
> +#define VUART_REGISTER(name, x) \
> +    static const struct vuart_emulator name##_entry \
> +        __used_section(".data.rel.ro.vuart") =3D x
> +
> +struct vuart *vuart_find_by_io_range(struct domain *d,
> +                                     unsigned long base_addr,
> +                                     unsigned long size);
> +
> +int vuart_put_rx(struct domain *d, char c);
> +
> +#ifdef CONFIG_VUART_FRAMEWORK
> +
> +int vuart_init(struct domain *d, struct vuart_info *info);
> +void vuart_deinit(struct domain *d);
> +void vuart_dump_state(const struct domain *d);
> +bool domain_has_vuart(const struct domain *d);
> +
> +#else
> +
> +static inline int vuart_init(struct domain *d, struct vuart_info *info)
> +{
> +    return 0;
> +}
> +
> +static inline void vuart_deinit(struct domain *d)
> +{
> +}
> +
> +static inline void vuart_dump_state(const struct domain *d)
> +{
> +}
> +
> +static inline bool domain_has_vuart(const struct domain *d)
> +{
> +    return false;
> +}
> +
> +#endif /* CONFIG_VUART_FRAMEWORK */
> +
> +#endif /* XEN_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/xen.lds.h b/xen/include/xen/xen.lds.h
> index b126dfe88792..2d65f32ddad3 100644
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -194,4 +194,14 @@
>  #define VPCI_ARRAY
>  #endif
>
> +#ifdef CONFIG_VUART_FRAMEWORK
> +#define VUART_ARRAY              \
> +       . =3D ALIGN(POINTER_ALIGN); \
> +       vuart_array_start =3D .;    \
> +       *(.data.rel.ro.vuart)     \
> +       vuart_array_end =3D .;
> +#else
> +#define VUART_ARRAY
> +#endif
> +
>  #endif /* __XEN_LDS_H__ */
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:32:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:32:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114786.1461594 (Exim 4.92)
	(envelope-from )
	id 1uvXIi-0008Bk-Ly; Mon, 08 Sep 2025 08:32:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114786.1461594; Mon, 08 Sep 2025 08: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 1uvXIi-0008Bd-HC; Mon, 08 Sep 2025 08:32:36 +0000
Received: by outflank-mailman (input) for mailman id 1114786;
 Mon, 08 Sep 2025 08:32:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvXIg-0008BX-RS
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:32:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvXIf-00DBfz-1X;
 Mon, 08 Sep 2025 08:32:33 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvXIf-003Nfv-12;
 Mon, 08 Sep 2025 08:32: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=NBtc1R411wMyE9pDeaEoLzklekDODEKk+Z3S2fXg3yM=; b=6P1/hnnaxYl7Uqy21sr2sVw9a8
	LOAImOKjmoT6oswAK3+vy1VJ4SFdMEiLUQBP3sQKZs9wmvydps+3ioxsh1GxGQhFZ+PoY7Plqg5KL
	dOdpo1j3W0HSpj45ihgO3Xl+7ah4CmaYO9B2hfNv2/2N7KWO3PHGjcSvrP/GHk/oBDxI=;
From: dmukhin@xen.org
Date: Mon, 8 Sep 2025 01:32:32 -0700
To: Mykola Kvach 
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 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-4-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 Sat, Sep 06, 2025 at 11:37:28PM +0300, Mykola Kvach wrote:
> Hi Denis,
> 
> On Sat, Sep 6, 2025 at 2:27 AM  wrote:
> >
> > From: Denis Mukhin 
> >
> > The change is the first on the way on introducing minimally functional
> > NS16550-compatible UART emulator.
> >
> > Define UART state and a set of emulated registers.
> >
> > Implement alloc/free vUART hooks.
> >
> > Stub out I/O port handler.
> >
> > Add initialization of the NS16x50-compatible UART emulator state machine.
> >
> > Plumb debug logging.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v5:
> > - v5 feedback
> > - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-4-dmukhin@ford.com/
> > ---
> >  xen/arch/x86/hvm/hvm.c          |  21 ++
> >  xen/common/emul/vuart/Kconfig   |  19 ++
> >  xen/common/emul/vuart/Makefile  |   1 +
> >  xen/common/emul/vuart/ns16x50.c | 366 ++++++++++++++++++++++++++++++++
> >  4 files changed, 407 insertions(+)
> >  create mode 100644 xen/common/emul/vuart/ns16x50.c
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 23bd7f078a1d..91c971f11e14 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> 
> I noticed that this include ...
> 
> > +#include 
> 
> ... is out of alphabetical order. All other includes in this block
> are correctly sorted.

Thanks, will update.

> 
> >  #include 
> >  #include 
> >  #include 
> > @@ -689,6 +690,22 @@ int hvm_domain_initialise(struct domain *d,
> >      if ( rc != 0 )
> >          goto fail1;
> >
> > +    /* Limit NS16550 emulator for dom0 only for now. */
> > +    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && is_hardware_domain(d) )
> 
> Currently, the Xen glossary defines a "hardware domain" as:
> 
>     A domain, commonly dom0, which shares responsibility with Xen
>     about the system as a whole.
> 
> It has been historically correct to treat is_hardware_domain(d) as
> equivalent to dom0. However, according to patch series [1], this is
> no longer guaranteed:
> 
>     "Setting hardware domain as domid 0 is removed."
> 
> After these changes, the assumption that hardware domain always equals
> dom0 may not hold. As a result, the above comment in the code could
> become misleading. Consider updating it to something like:
> 
>     /* Limit NS16550 emulator to the hardware domain only for now */
> 
> to reflect the new semantics.

I adjusted the code a bit so that it is possible to test vUART for
either hwdom or domU; will remove the comment in v7.

> 
> > +    {
> > +        struct vuart_info info = {
> > +            .name       = "COM2",
> > +            .compatible = "ns16550",
> > +            .base_addr  = 0x2f8,
> > +            .size       = 8,
> > +            .irq        = 3,
> > +        };
> 
> Consider defining COM2 base address and IRQ in a shared header
> (e.g., VUART_COM2_BASE and VUART_COM2_IRQ) rather than using
> the magic numbers 0x2f8 and 3 here. This would allow reuse in
> `__start_xen` and other places, and makes the code clearer and
> easier to maintain.

PC platform resources are standard and not going to change, so
I think it is satisfactory to use hardcoded numbers here:
   COM1 - 0x3f8 / IRQ#4
   COM2 - 0x2f8 / IRQ#3
   COM3 - 0x3fe / IRQ#4
   COM4 - 0x2fe / IRQ#3

Other PC I/O ports still use hardcoded values, e.g. dom0_setup_permissions().

Anyway, this code will change again, once xl support is plumbed.
So, I would keep that as is for now...

[..]
> > +/*
> > + * Emulate 8-bit read access to ns16x50 register.
> > + */
> > +static int ns16x50_io_read8(
> > +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> > +{
> > +    uint8_t val = 0xff;
> 
> Instead of hardcoding 0xff here, consider using UINT8_MAX. This makes
> it clear that the value is the maximum for uint8_t and avoids magic
> numbers.
> 
> Similarly, in other places where constants for 16-bit or 32-bit
> unsigned integers are used, it would be good to replace them with
> UINT16_MAX and UINT32_MAX respectively for consistency and clarity.

Agreed, will do.
Thanks.

[..]
> > +/*
> > + * Emulate I/O access to ns16x50 register.
> > + * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled.
> > + */
> > +static int cf_check ns16x50_io_handle(
> > +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> > +{
> > +#define op(dir)     (((dir) == IOREQ_WRITE) ? 'W' : 'R')
> 
> Instead of defining the op(dir) macro, it might be cleaner to compute
> the direction character once at the beginning, e.g.:
> 
>     const char dir_char = (dir == IOREQ_WRITE) ? 'W' : 'R';
> 
> and then use dir_char in printk()/debug. This avoids the local macro
> and makes the code easier to follow.

Thanks for suggestion.
Will update.

> 
> > +    struct domain *d = rcu_lock_current_domain();
> > +    struct vuart *vuart = vuart_find_by_io_range(d, addr, size);
> > +    struct vuart_ns16x50 *vdev;
> > +    const struct domain *owner;
> > +    const struct vuart_info *info;
> > +    uint32_t reg;
> > +    unsigned dlab;
> > +    int rc;
> > +
> > +    if ( !vuart || !vuart->vdev )
> > +    {
> > +        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
> > +               op(dir), addr, size);
> > +
> > +        ASSERT_UNREACHABLE();
> > +        goto out;
> > +    }
> > +    vdev = vuart->vdev;
> > +
> > +    owner = vuart->owner;
> > +    ASSERT(owner);
> > +    if ( d != owner )
> > +    {
> > +        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domain %pv\n",
> > +                    op(dir), addr, size, d);
> > +
> > +        ASSERT_UNREACHABLE();
> > +        goto out;
> > +    }
> > +
> > +    info = vuart->info;
> > +    ASSERT(info);
> > +    reg = addr - info->base_addr;
> > +    if ( !IS_ALIGNED(reg, size) )
> > +    {
> > +        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
> > +                    op(dir), addr, size);
> > +        goto out;
> > +    }
> > +
> > +    dlab = ns16x50_dlab_get(vdev);
> > +    if ( reg >= NS16X50_REGS_NUM )
> > +    {
> > +        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": not implemented\n",
> > +                    op(dir), addr, size, dlab, reg, *data);
> > +        goto out;
> > +    }
> > +
> > +    spin_lock(&vdev->lock);
> > +
> > +    if ( dir == IOREQ_WRITE )
> > +    {
> > +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
> > +                      op(dir), addr, size, dlab, reg, *data);
> > +        rc = ns16x50_io_write(vdev, reg, size, data);
> 
> AFAICT ns16x50_io_read() and ns16x50_io_write() have identical
> signatures. Would it be cleaner to store them in an array of
> function pointers and call through that, e.g.:
> 
>     rc = ns16x50_io_op[dir == IOREQ_WRITE](vdev, reg, size, data);
> 
> This would avoid the if/else block here.

I remember I tried this way, but eventually decided to keep just direct calls
for simplicity.

> 
> > +    }
> > +    else
> > +    {
> > +        rc = ns16x50_io_read(vdev, reg, size, data);
> > +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
> > +                      op(dir), addr, size, dlab, reg, *data);
> 
> The ns16x50_debug() call is duplicated in both branches of the
> IOREQ_WRITE check, differing only in whether it's placed before or
> after the access. Would it make sense to move this debug print
> outside the condition, so the same code is used for both read and
> write paths (assuming the "data"  is not modified during a write)?

Yep, that will work, thanks!

> 
> > +    }
> > +    if ( rc < 0 )
> > +        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": unsupported access\n",
> > +                    op(dir), addr, size, dlab, reg, *data);
> 
> The ns16x50_err() call doesn’t require holding vdev->lock, so it would
> be cleaner to move it after spin_unlock(). That way the critical section
> is shorter.

Ack.

> 
> > +
> > +    spin_unlock(&vdev->lock);
> > +
> > +out:
> > +    rcu_unlock_domain(d);
> > +
> > +    return X86EMUL_OKAY;
> > +#undef op
> > +}
> > +
> > +static int ns16x50_init(void *arg)
> > +{
> > +    struct vuart_ns16x50 *vdev = arg;
> > +    const struct vuart_info *info = vdev->info;
> > +    struct domain *d = vdev->owner;
> > +
> > +    ASSERT(vdev);
> > +
> > +    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
> > +
> > +    return 0;
> > +}
> > +
> > +static void cf_check ns16x50_deinit(void *arg)
> > +{
> > +    struct vuart_ns16x50 *vdev = arg;
> > +
> > +    ASSERT(vdev);
> > +}
> > +
> > +static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info)
> > +{
> > +    struct vuart_ns16x50 *vdev;
> > +    int rc;
> > +
> > +    if ( !info )
> > +        return ERR_PTR(-EINVAL);
> > +
> > +    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
> > +    {
> > +        ns16x50_err(info, "already registered\n");
> > +        return ERR_PTR(-EBUSY);
> > +    }
> > +
> > +    if ( !is_hvm_domain(d) )
> 
> Currently, ns16x50_alloc() first calls vuart_find_by_io_range() and
> only afterwards checks if the domain is an HVM domain. Wouldn’t it
> be more logical to perform the HVM check first? If the console is
> only available for HVM domains, the extra check for an uninitialized
> vuart field seems unnecessary.

Ack.

> 
> > +    {
> > +        ns16x50_err(info, "not an HVM domain\n");
> > +        return ERR_PTR(-ENOSYS);
> > +    }
> > +
> > +    vdev = xvzalloc(typeof(*vdev));
> > +    if ( !vdev )
> > +    {
> > +        ns16x50_err(info, "failed to allocate memory\n");
> > +        return ERR_PTR(-ENOMEM);
> > +    }
> > +
> > +    spin_lock_init(&vdev->lock);
> > +    vdev->name = info->name;
> > +    vdev->owner = d;
> > +    vdev->info = info;
> > +
> > +    rc = ns16x50_init(vdev);
> > +    if ( rc )
> 
> If ns16x50_init(vdev) fails, vdev should be freed with xvfree() to
> avoid a memory leak.

Whoops, thanks.

> 
> Currently, ns16x50_init() always returns 0. If it is not planned to
> return other values in the future, it may be simpler to make the
> function return void, avoiding the need for the rc variable and
> conditional checks.

There will be non-zero return values in the future.

> 
> > +        return ERR_PTR(rc);
> > +
> > +    return vdev;
> > +}
> > +
> > +static void cf_check ns16x50_free(void *arg)
> > +{
> > +    if ( arg )
> > +        ns16x50_deinit(arg);
> > +
> > +    xvfree(arg);
> > +}
> > +
> > +#define ns16x50_emulator                \
> > +{                                       \
> > +    .compatible = "ns16550",            \
> > +    .alloc      = ns16x50_alloc,        \
> > +    .free       = ns16x50_free,         \
> > +    .dump_state = NULL,                 \
> 
> dump_state is set to NULL, but vuart_dump_state() in the previous
> commit does not check this pointer. If all commits up to this one
> are applied and domain state is dumped, this could result in a
> NULL pointer dereference and crash the hypervisor.

Thanks; will fix vuart.c

> 
> Consider adding a NULL check in vuart_dump_state() or initializing
> dump_state properly.
> 
> > +    .put_rx     = NULL,                 \
> > +}
> > +
> > +VUART_REGISTER(ns16x50, ns16x50_emulator);
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: "BSD"
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> > --
> > 2.51.0
> >
> >
> 
> [1] https://patchew.org/Xen/20250416212911.410946-1-jason.andryuk@amd.com/
> 
> Best regards,
> Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:36:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114797.1461603 (Exim 4.92)
	(envelope-from )
	id 1uvXMZ-0000L7-4T; Mon, 08 Sep 2025 08:36:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114797.1461603; Mon, 08 Sep 2025 08: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 1uvXMZ-0000L0-0t; Mon, 08 Sep 2025 08:36:35 +0000
Received: by outflank-mailman (input) for mailman id 1114797;
 Mon, 08 Sep 2025 08:36:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvXMX-0000Ku-Oq
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:36:33 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvXMW-00DBmK-1t;
 Mon, 08 Sep 2025 08:36:32 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvXMW-003ORt-1N;
 Mon, 08 Sep 2025 08:36:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=CuKI6tX4kCuN5h4cZY0A4GhYdrc3+o5Tvu+0C27UWg0=; b=d34zrKecFBTg5To9z/s1tHX21/
	Ir1YStfm7BDHYVTcceoLeeHAEq5/NPSWJ43oiyCCsbc2HZ2ielxcWm0AV+eoD0AMZ9RwuFCYspjx7
	8BPIGRgaCnoBpt4XogdKTXpgcPlePaa4TzdI6HERknkNkG3ysNoEYRj4PifYrpS8F3J0=;
From: dmukhin@xen.org
Date: Mon, 8 Sep 2025 01:36:31 -0700
To: Mykola Kvach 
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 02/15] xen/8250-uart: update definitions
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-3-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 Sat, Sep 06, 2025 at 05:57:02PM +0300, Mykola Kvach wrote:
> Hi Denis,
> 
> On Sat, Sep 6, 2025 at 2:27 AM  wrote:
[..]
> >  /* FIFO Control Register */
> > -#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> > -#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> > -#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> > -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> > +#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
> > +#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
> > +#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
> > +#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */
> > +#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
> > +#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */
> > +#define UART_FCR_RTB0       BIT(6, U)   /* receiver trigger bit #0 */
> > +#define UART_FCR_RTB1       BIT(7, U)   /* receiver trigger bit #1 */
> > +#define UART_FCR_TRG_MASK   (UART_FCR_RTB0 | UART_FCR_RTB1)
> 
> Thanks for the patch. I noticed that in this changeset some bit
> definitions (e.g. UART_FCR_*) were rewritten using the BIT(n, U)
> macro, while others (e.g. UART_IER_* and rest of UART_FCR_*) are
> still left as plain hex values (0x01, 0x02, etc.), even though they
> are also powers of two.
> 
> Could you clarify the reasoning behind this choice? From a reader’s
> perspective it looks inconsistent. Would it make sense to either:
> 
>   - update all of them to use BIT() for consistency, or
>   - keep the existing style unchanged in this patch and move a full
>     conversion to BIT() into a separate cleanup patch?
> 
> This would make the codebase easier to follow.

I find BIT() notation is more readable than raw bitmasks.
But I agree that definitions should be consistently updated.

Will update to the raw masks instead of BIT() in v7.


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:37:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:37:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114806.1461612 (Exim 4.92)
	(envelope-from )
	id 1uvXNH-0000p1-C5; Mon, 08 Sep 2025 08:37:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114806.1461612; Mon, 08 Sep 2025 08:37:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvXNH-0000ou-9I; Mon, 08 Sep 2025 08:37:19 +0000
Received: by outflank-mailman (input) for mailman id 1114806;
 Mon, 08 Sep 2025 08:37: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 1uvXNF-0000co-Nk
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:37:17 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0638dfa0-8c8f-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 10:37:16 +0200 (CEST)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-336cdca667aso30569091fa.0
 for ; Mon, 08 Sep 2025 01:37: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: 0638dfa0-8c8f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757320636; x=1757925436; 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=XeNNjwSB6pIhXass0CdICHduh4IgyrAcA69H6gI/ENA=;
        b=WE9WxhhWdSImUj66eWhHljAex27LM508EO1RIQPPJSJJzeu3yJGFvkJ2hlCwGjV1g1
         eg3tgh7Zk1JWD39Z/Klhq4wWGU7/2WlvEPW46Bf7wlXK2efLSqtwApJbGAtwbP3htPJQ
         yKJ/DWAqKPibNo1WJzRo12JVT/1MXJ87f/8sYyPUX1ASlQ5f2zGXbqzCD8sbjl+XHCtN
         DvutnGTfpA94givYOpHTcjHfWj6tMalz8gjVKKCLxZltBPiVntNLqAZEJ1lDhTjkhu5V
         ZPCQho4H9CpBmvFcwy3suriytbqrME0MSGMwwonUo6YVCAVqU2T++oRPecuiFxgF7dR9
         1qlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757320636; x=1757925436;
        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=XeNNjwSB6pIhXass0CdICHduh4IgyrAcA69H6gI/ENA=;
        b=P0h1XLuU9wbbbvIvkSKVuTA+dsIS02bsor47IwdIkhC8SwZ/zhqpYiMnXCzxPlPxUz
         6z1ORz9hLvOiSiEEzF14mti70t/+cuIKUqgihu3on5P0X3rNkshsCv2T+sbGSbKag6c4
         2MU7XxsmmYpTU11YMH/2uAlwzUa1njawKWUMgI3nzZMV4aARJcDOX8e6ne8WbXPxTBWY
         hKM0hBpERgwuN55JfsVPwXaOAmP88V73g0xA9JkuuTuxpTgnxdIHsCp4TNpu+I2nh+IM
         /iPwU9J2TUe4vtWPvGzK7sPxxSw7Gnkdodf78pz7mrqMK0TH7Wj6dvSc30RvmUWWhwWi
         dkZQ==
X-Gm-Message-State: AOJu0YxBdaf6yHdaWkSIZI48cLbRBivdjdnCutrvZPXaVjPZDfKwNG//
	8KA6kt2apQwt5Do/Y0uAfzzUdU3leRezs/hBdCVHCy+yMhfGwECP+j/RxXujKN6mcgS8m+6r0YM
	qtxzKdT2mchAP3LBGiofIC9kv0ginX8Y=
X-Gm-Gg: ASbGncvC3AhIEcPY8LA5ARJPbh1l/i+s0Z/m3LIP7eMeiuTBUV5PBsKn3miq4d2G4+f
	eB13z1JAAg4bpr/8PUe50D2iTdCEAHw1a89aphV/rqASQZy9aQ3AA3arRa/Un/gmkzZbNoJcYWB
	kNwxvGP97de8qsZm2/hsp25iLAMnFCbHAgqK2u8S3UHsdcYHBCaCbd544qQO3Zrakzaokzg8o9j
	PN19A==
X-Google-Smtp-Source: AGHT+IG23nMgMyhXf0HW3N+BOu56CoTemJBRiA+9uejA00v0VYKm/t/UvnD1W3fn46rW/ubqX40OgADICDlwkyJzUCA=
X-Received: by 2002:a05:651c:19a5:b0:337:f63a:fa28 with SMTP id
 38308e7fff4ca-33b52891afcmr23008371fa.20.1757320635423; Mon, 08 Sep 2025
 01:37:15 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> <20250905232715.440758-4-dmukhin@ford.com>
In-Reply-To: <20250905232715.440758-4-dmukhin@ford.com>
From: Mykola Kvach 
Date: Mon, 8 Sep 2025 11:37:03 +0300
X-Gm-Features: Ac12FXyj5CcSETlzCr3TdDFIjG198G5XFZKdnARSIl1Ap8H7SYmeg80_81K2UJQ
Message-ID: 
Subject: Re: [PATCH v6 03/15] emul/ns16x50: implement emulator stub
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Sat, Sep 6, 2025 at 2:27=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> The change is the first on the way on introducing minimally functional
> NS16550-compatible UART emulator.
>
> Define UART state and a set of emulated registers.
>
> Implement alloc/free vUART hooks.
>
> Stub out I/O port handler.
>
> Add initialization of the NS16x50-compatible UART emulator state machine.
>
> Plumb debug logging.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - v5 feedback
> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-4-=
dmukhin@ford.com/
> ---
>  xen/arch/x86/hvm/hvm.c          |  21 ++
>  xen/common/emul/vuart/Kconfig   |  19 ++
>  xen/common/emul/vuart/Makefile  |   1 +
>  xen/common/emul/vuart/ns16x50.c | 366 ++++++++++++++++++++++++++++++++
>  4 files changed, 407 insertions(+)
>  create mode 100644 xen/common/emul/vuart/ns16x50.c
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 23bd7f078a1d..91c971f11e14 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -689,6 +690,22 @@ int hvm_domain_initialise(struct domain *d,
>      if ( rc !=3D 0 )
>          goto fail1;
>
> +    /* Limit NS16550 emulator for dom0 only for now. */
> +    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && is_hardware_domain(d) )
> +    {
> +        struct vuart_info info =3D {
> +            .name       =3D "COM2",
> +            .compatible =3D "ns16550",
> +            .base_addr  =3D 0x2f8,
> +            .size       =3D 8,
> +            .irq        =3D 3,
> +        };
> +
> +        rc =3D vuart_init(d, &info);
> +        if ( rc )
> +            goto out_vioapic_deinit;
> +    }
> +
>      stdvga_init(d);
>
>      rtc_init(d);
> @@ -712,6 +729,8 @@ int hvm_domain_initialise(struct domain *d,
>      return 0;
>
>   fail2:
> +    vuart_deinit(d);
> + out_vioapic_deinit:
>      vioapic_deinit(d);
>   fail1:
>      if ( is_hardware_domain(d) )
> @@ -774,6 +793,8 @@ void hvm_domain_destroy(struct domain *d)
>      if ( hvm_funcs.domain_destroy )
>          alternative_vcall(hvm_funcs.domain_destroy, d);
>
> +    vuart_deinit(d);
> +
>      vioapic_deinit(d);
>
>      XFREE(d->arch.hvm.pl_time);
> diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfi=
g
> index ce1b976b7da7..a27d7ca135af 100644
> --- a/xen/common/emul/vuart/Kconfig
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -3,4 +3,23 @@ config VUART_FRAMEWORK
>
>  menu "UART Emulation"
>
> +config VUART_NS16X50
> +       bool "NS16550-compatible UART Emulator" if EXPERT
> +       depends on X86 && HVM

Currently VUART_NS16X50 depends on X86, so the code is only
usable on x86. Are there any plans to support this vUART on non-x86
architectures (e.g. ARM, where some UARTs are also ns16550-compatible)?

If not, wouldn=E2=80=99t it be more appropriate to move the ns16x50-specifi=
c
implementation into x86-specific directories instead of common?

> +       select VUART_FRAMEWORK
> +       default n
> +       help
> +         In-hypervisor NS16x50 UART emulation.
> +
> +         Only legacy PC COM2 port is emulated.
> +
> +         This is strictly for testing purposes (such as early HVM guest =
console),
> +         and not appropriate for use in production.
> +
> +config VUART_NS16X50_DEBUG
> +       bool "NS16550-compatible UART Emulator Debugging"
> +       depends on VUART_NS16X50 && DEBUG
> +       help
> +         Enable development debugging.
> +
>  endmenu
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> index 97f792dc6641..fe904f6cb65d 100644
> --- a/xen/common/emul/vuart/Makefile
> +++ b/xen/common/emul/vuart/Makefile
> @@ -1 +1,2 @@
>  obj-y +=3D vuart.o
> +obj-$(CONFIG_VUART_NS16X50) +=3D ns16x50.o
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> new file mode 100644
> index 000000000000..0462a961e785
> --- /dev/null
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -0,0 +1,366 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS16550-compatible UART Emulator.
> + *
> + * See:
> + * - Serial and UART Tutorial:
> + *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-u=
art_en.pdf
> + * - UART w/ 16 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> + * - UART w/ 64 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
> + *
> + * Limitations:
> + * - Only x86;
> + * - Only Xen console as a backend, no inter-domain communication (simil=
ar to
> + *   vpl011 on Arm);
> + * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
> + * - No baud rate emulation (reports 115200 baud to the guest OS);
> + * - No FIFO-less mode emulation;
> + * - No RX FIFO interrupt moderation (FCR) emulation;
> + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> + *   friends);
> + * - No ISA IRQ sharing allowed;
> + * - No MMIO-based UART emulation.
> + */
> +
> +#define pr_prefix               "ns16x50"
> +#define pr_fmt(fmt)             pr_prefix ": " fmt
> +
> +#ifdef CONFIG_VUART_NS16X50_DEBUG
> +#define guest_prefix            "FROM GUEST "
> +#define ns16x50_log_level       2
> +#else
> +#define guest_prefix            ""
> +#define ns16x50_log_level       0
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define ns16x50_log(n, lvl, vdev, fmt, args...) \
> +do { \
> +    if ( ns16x50_log_level >=3D n ) \
> +        gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \
> +} while (0)
> +
> +#define ns16x50_err(vdev, fmt, args...) \
> +    ns16x50_log(0, XENLOG_ERR, vdev, fmt, ## args)
> +#define ns16x50_warn(vdev, fmt, args...) \
> +    ns16x50_log(1, XENLOG_WARNING, vdev, fmt, ## args)
> +#define ns16x50_info(vdev, fmt, args...) \
> +    ns16x50_log(2, XENLOG_INFO, vdev, fmt, ## args)
> +#define ns16x50_debug(vdev, fmt, args...) \
> +    ns16x50_log(3, XENLOG_DEBUG, vdev, fmt, ## args)
> +
> +/*
> + * Number of supported registers in the UART.
> + */
> +#define NS16X50_REGS_NUM        (UART_SCR + 1)
> +
> +/*
> + * Number of emulated registers.
> + *
> + * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=
=3D0.
> + * - DLAB=3D1, R/W, DLL            =3D NS16X50_REGS_NUM + 0
> + * - DLAB=3D1, R/W, DLM            =3D NS16X50_REGS_NUM + 1
> + * -         R/O, IIR (IIR_THR)  =3D NS16X50_REGS_NUM + 2
> + */
> +#define NS16X50_EMU_REGS_NUM    (NS16X50_REGS_NUM + 3)
> +
> +/*
> + * Virtual ns16x50 device state.
> + */
> +struct vuart_ns16x50 {
> +    uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */
> +    const struct vuart_info *info;      /* UART description */
> +    struct domain *owner;               /* Owner domain */
> +    const char *name;                   /* Device name */
> +    spinlock_t lock;                    /* Protection */
> +    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
> +};
> +
> +static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> +{
> +    return 0;
> +}
> +
> +/*
> + * Emulate 8-bit write access to ns16x50 register.
> + */
> +static int ns16x50_io_write8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    int rc =3D 0;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit write access to ns16x50 register.
> + * NB: some guest OSes use outw() to access UART_DLL.
> + */
> +static int ns16x50_io_write16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    int rc =3D -EINVAL;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate write access to ns16x50 register.
> + */
> +static int ns16x50_io_write(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_write8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_write16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 8-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    uint8_t val =3D 0xff;
> +    int rc =3D 0;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    uint16_t val =3D 0xffff;
> +    int rc =3D -EINVAL;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate read access to ns16x50 register.
> + */
> +static int ns16x50_io_read(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_read8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_read16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        *data =3D 0xffffffff;
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate I/O access to ns16x50 register.
> + * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is en=
abled.
> + */
> +static int cf_check ns16x50_io_handle(
> +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> +{
> +#define op(dir)     (((dir) =3D=3D IOREQ_WRITE) ? 'W' : 'R')
> +    struct domain *d =3D rcu_lock_current_domain();
> +    struct vuart *vuart =3D vuart_find_by_io_range(d, addr, size);
> +    struct vuart_ns16x50 *vdev;
> +    const struct domain *owner;
> +    const struct vuart_info *info;
> +    uint32_t reg;
> +    unsigned dlab;
> +    int rc;
> +
> +    if ( !vuart || !vuart->vdev )
> +    {
> +        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
> +               op(dir), addr, size);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +    vdev =3D vuart->vdev;
> +
> +    owner =3D vuart->owner;
> +    ASSERT(owner);
> +    if ( d !=3D owner )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domai=
n %pv\n",
> +                    op(dir), addr, size, d);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +
> +    info =3D vuart->info;
> +    ASSERT(info);
> +    reg =3D addr - info->base_addr;
> +    if ( !IS_ALIGNED(reg, size) )
> +    {
> +        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
> +                    op(dir), addr, size);
> +        goto out;
> +    }
> +
> +    dlab =3D ns16x50_dlab_get(vdev);
> +    if ( reg >=3D NS16X50_REGS_NUM )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"=
PRIx32": not implemented\n",
> +                    op(dir), addr, size, dlab, reg, *data);
> +        goto out;
> +    }
> +
> +    spin_lock(&vdev->lock);
> +
> +    if ( dir =3D=3D IOREQ_WRITE )
> +    {
> +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"P=
RIx32"\n",
> +                      op(dir), addr, size, dlab, reg, *data);
> +        rc =3D ns16x50_io_write(vdev, reg, size, data);
> +    }
> +    else
> +    {
> +        rc =3D ns16x50_io_read(vdev, reg, size, data);
> +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"P=
RIx32"\n",
> +                      op(dir), addr, size, dlab, reg, *data);
> +    }
> +    if ( rc < 0 )
> +        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"PRI=
x32": unsupported access\n",
> +                    op(dir), addr, size, dlab, reg, *data);
> +
> +    spin_unlock(&vdev->lock);
> +
> +out:
> +    rcu_unlock_domain(d);
> +
> +    return X86EMUL_OKAY;
> +#undef op
> +}
> +
> +static int ns16x50_init(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +    const struct vuart_info *info =3D vdev->info;
> +    struct domain *d =3D vdev->owner;
> +
> +    ASSERT(vdev);
> +
> +    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
> +
> +    return 0;
> +}
> +
> +static void cf_check ns16x50_deinit(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +
> +    ASSERT(vdev);
> +}
> +
> +static void * cf_check ns16x50_alloc(struct domain *d, const struct vuar=
t_info *info)
> +{
> +    struct vuart_ns16x50 *vdev;
> +    int rc;
> +
> +    if ( !info )
> +        return ERR_PTR(-EINVAL);
> +
> +    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
> +    {
> +        ns16x50_err(info, "already registered\n");
> +        return ERR_PTR(-EBUSY);
> +    }
> +
> +    if ( !is_hvm_domain(d) )
> +    {
> +        ns16x50_err(info, "not an HVM domain\n");
> +        return ERR_PTR(-ENOSYS);
> +    }
> +
> +    vdev =3D xvzalloc(typeof(*vdev));
> +    if ( !vdev )
> +    {
> +        ns16x50_err(info, "failed to allocate memory\n");
> +        return ERR_PTR(-ENOMEM);
> +    }
> +
> +    spin_lock_init(&vdev->lock);
> +    vdev->name =3D info->name;
> +    vdev->owner =3D d;
> +    vdev->info =3D info;
> +
> +    rc =3D ns16x50_init(vdev);
> +    if ( rc )
> +        return ERR_PTR(rc);
> +
> +    return vdev;
> +}
> +
> +static void cf_check ns16x50_free(void *arg)
> +{
> +    if ( arg )
> +        ns16x50_deinit(arg);
> +
> +    xvfree(arg);
> +}
> +
> +#define ns16x50_emulator                \
> +{                                       \
> +    .compatible =3D "ns16550",            \
> +    .alloc      =3D ns16x50_alloc,        \
> +    .free       =3D ns16x50_free,         \
> +    .dump_state =3D NULL,                 \
> +    .put_rx     =3D NULL,                 \
> +}
> +
> +VUART_REGISTER(ns16x50, ns16x50_emulator);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:43:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:43:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114821.1461623 (Exim 4.92)
	(envelope-from )
	id 1uvXTQ-0002be-5H; Mon, 08 Sep 2025 08:43:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114821.1461623; Mon, 08 Sep 2025 08:43:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvXTQ-0002bX-1h; Mon, 08 Sep 2025 08:43:40 +0000
Received: by outflank-mailman (input) for mailman id 1114821;
 Mon, 08 Sep 2025 08:43:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvXTP-0002bP-DD
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:43:39 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e99f65be-8c8f-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 10:43:37 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-625e1ef08eeso2974133a12.1
 for ; Mon, 08 Sep 2025 01:43: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
 4fb4d7f45d1cf-621421b9debsm6779778a12.34.2025.09.08.01.43.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 01:43: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: e99f65be-8c8f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757321017; x=1757925817; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=b0nDHKaeoz1QYx+ZwowmXvaJ8rOOeqvrhUCk/FJfyII=;
        b=BgjSI14vyJvXiWOnr2PmiwPt3Mjv5u1duMPEuQtzdTnPr6Szne5U0m+iT4B30lSkmz
         rkgUi4M6Cir01xL2NSb9q8DpRr9nCTdN2mlR4nGFxBEewvXPmRZnmZrQ9fu4brWMr5YD
         874Ru7ePDLLCDpqoTEnN1hNY2So9j43tjcbrVutk9X1KA/EKKDfrPiXkByzjUEhwhY9j
         ORyYRBm86KTJb/Kc1kp9TwlPEgSAlTUFya8bkzqo6W2zt/LYC6h1HeFBX/ZAIuUVQzyq
         00nFr2N02MxGKYthEUhdqv4k0YCPQ+oix/OxtoVie/cX25tTmrNc7PDpDj7vctOY+eqr
         MjXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757321017; x=1757925817;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=b0nDHKaeoz1QYx+ZwowmXvaJ8rOOeqvrhUCk/FJfyII=;
        b=ry3g57RmnJJ2JTnzwuzeuyyGGcejmRjMbPtOJ87r0kqhr1xbqEpJPnAIztUstJXoNb
         I4QsAhoVhcL/1YMZashUwnwxokIsgpiCs1iBoqMqUEMenm3+BNiWSAv/Fz6RYmUKl7jV
         k2qY5beGZWZLJZhRQx6t+0+oB2ukp0U2kB7FCPFxOBrztQcYeFVWh0SpYpx0hm28K7L0
         P474SnA6C/Ws6tMu2kSq41QGd0KK0XTEDULSBp538G5EliB+sDZnBABjoJVD+TOii24C
         +vY90tW6VPvTcxAhf91E73/8EktPkQq1uOpbQB4hetEtluwOSfeZ7BXvDMJtdMcgL+aR
         Kh9w==
X-Gm-Message-State: AOJu0YxCaT6ltMGLYY+rpNkN7rLAuoxST6lZfn6T7dUpDmMvFVE/nXOh
	Npms25bhiEI0typwlZR10XA/wS7fbTHaHmlXqpxK8D1s1BYYp3GRqtzliV7498nziw==
X-Gm-Gg: ASbGncvsycJz+X8T9tlVW37S9748I0t90ZHMYi7xVNiXIsQyfC9wlpPlOvN9VdVubvU
	0nuxZVj9KI25yAvIYfUnMuVlI2IjK+sqeanS6BjLm3yhFuCJOTomN4IhBMXHq2jtSNbjQ7pjDLw
	Lw7Ao8aM7ri756AO6wLQxSJIX+eIzSymONVz8LYrNxH+cX4HjrKP+rD1sw7KnhkqA3raMq7QQZb
	bGJbYZ/9Iw71H3ZLXtGnmRqPZzssM8LcXbvPS1BbMxt8OBeRiZiI+3Yi8Ta+ztZgSyfU3KOxbBj
	Cf/0MdrJlxxeXnYRuIRY8fBPllKl50UXSk0w49/XesvsLLhyRzgIESLa78uGQuC3RzcMbmp1vfo
	fWWTRabMZhmBesZ435fwXOXhbv6nMnzBan/PBEybC83rdUUsvCCqIoK/urkboBY5sWk37TTKKI1
	2GUdZHRnBpwOU6Tb9bJg==
X-Google-Smtp-Source: AGHT+IFxRgU/O6XzNkIs4N2e4o7PfEEyfx21d4QIFdL7I91XJRtJDWduYMo/8C23DlwtxcZnW3Nqbg==
X-Received: by 2002:a05:6402:5254:b0:61c:d330:77e7 with SMTP id 4fb4d7f45d1cf-6237abddc02mr7040611a12.6.1757321017374;
        Mon, 08 Sep 2025 01:43:37 -0700 (PDT)
Message-ID: <89198ef2-fab9-4a3b-9b94-54912cbefe91@suse.com>
Date: Mon, 8 Sep 2025 10:43:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 01/15] emul/vuart: introduce framework for UART
 emulators
To: Mykola Kvach 
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,
 dmukhin@xen.org
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.09.2025 10:29, Mykola Kvach wrote:
> On Sat, Sep 6, 2025 at 2:27 AM  wrote:
>> --- /dev/null
>> +++ b/xen/common/emul/vuart/Kconfig
>> @@ -0,0 +1,6 @@
>> +config VUART_FRAMEWORK
>> +       bool
> 
> If VUART_FRAMEWORK has no dependencies, it can be enabled on any
> architecture. For example, I tried enabling it on arm64 and the build
> fails:
> 
>   ./include/xen/vuart.h:26:8: error: redefinition of ‘struct vuart’
> 
> Should this config be restricted (e.g. "depends on X86") or the code
> adjusted to handle non-x86 architectures properly?

"depends on" isn't very useful when there's no prompt. An arch selecting
such an option will need to make sure things actually build when enabled.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:49:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:49:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114831.1461632 (Exim 4.92)
	(envelope-from )
	id 1uvXYl-0003En-Nl; Mon, 08 Sep 2025 08:49:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114831.1461632; Mon, 08 Sep 2025 08: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 1uvXYl-0003Eg-LE; Mon, 08 Sep 2025 08:49:11 +0000
Received: by outflank-mailman (input) for mailman id 1114831;
 Mon, 08 Sep 2025 08: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 1uvXYk-0003EY-63
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:49: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 aee59b4c-8c90-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 10:49:08 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b04163fe08dso713173666b.3
 for ; Mon, 08 Sep 2025 01:49:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b046f2dda22sm1222083766b.40.2025.09.08.01.49.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 01: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: aee59b4c-8c90-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757321348; x=1757926148; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GHjvfqIdRjsQX9nzawMApA8YdsCDCCCvniMT+kzyowc=;
        b=Exv6ApFUZ3D2GNa+0hIDmN6QhfxDhrtJLwl5nje/0Jcqc5lndfxz5EuqShuYivXyh9
         gWLcALFb69PZXcUOCCp11qDe26Zf5x/67nImn+X3q8+oOhhLMZZajmb0XcdlJnsDjSwR
         4aMaYQR1HmfCYY4U74zgGnE+xh8j+GQuOPL3CanO4fk+YBgPQm4DJbQT7m/t1FWiTKk5
         vCpxuz2c3zpVHkT4gJANU8mPkawfztdiyQIbzFzUwokMRTm385TKX9WQRBrs3gnkgizQ
         mB5N8NnZBJRnmhaxHJ1RqRARUo2xZ+l07mNSv9F6Hlr4EzPd72ROhNb+DqoaEekl3F66
         c5FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757321348; x=1757926148;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GHjvfqIdRjsQX9nzawMApA8YdsCDCCCvniMT+kzyowc=;
        b=Hj44SSJ/PxY1M88nFq9bp/7Ts/HUGQdSfJqFpFfXcjIcgbUT/dzQr/g3jCkXc/y/xI
         KbzXs19/YSEeAB1l5rN3AbQJF9qG+Bjptp5FyN7ZhsmxEmwdHR215boHRC/qUI7y+qIz
         wTWK7xTgZ8ePksMDBoxYq9AgpGliditZvBE72rAMovcatOasERA+/fJ1AjbaKLPA5IE1
         n2hlRRCuxLMr/O5r5csVVfAuvLVzfhMQfL0dPscihAAoWwwsISo5clTQ6416EgYDMFdd
         kTRoSQDjRET7k8qdgsPUtZrlsYsb5a1cEse7by9xWcC/PjTgyn1N20iz0k5Chljhyo77
         cdsQ==
X-Forwarded-Encrypted: i=1; AJvYcCXZZEWQceFU15wetFe+kGYA4YQ/cpGfCUjQyKPL+LKDF7hS3VqsUuehhGGpobEuTq508K5Nb1zcYyk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQj0R4AQfveFBsyjZp52nIYYFikG3tDUzx0rMrhSjytnBfR2n6
	dXA8BLds63PyyJGlSDfQOkxtTDEttd7MoQtpfxQuSKjpjIgo35gJ0V3YX6vjbodZEQ==
X-Gm-Gg: ASbGncs7hJhsrR+lskQx8WxFiVttb372YueSDCEJb2HELpPjHqzi/d06FIXWSEQo2W4
	60oidkzJWwHgV7S1H2PtVgMr5vHyWJ3ASVVzO/YAqbFVTmdm5VLAbGVYlcCh6NNkmKbvdJ8ZHyb
	/TLuO7WVm02gRv5ajepf/s7Bo0A3nruD5zI3RY4G5YPQljQIEi5StVpBcW+AQwycLsddptpI5mH
	AVVwuBcMHf5kmfTdcg6kEk6KYKLV1XGKoe/mtAF4PwVz0hX4FedO5+AZ+ERTGSPyLkctmVwWTTl
	W+Alf02i0WQ6sC/K8dHHp/lCtWT2+Dze/KlmUapSDcuiafEmCY3LNDi8yxckRkT45TDSmZgyU8K
	3N6iqbR8yeFpdbtSBdyalvGPuIEfMSNU5UqIuJFpLTRp0SRhrG/vdpJF9RUkPx7S+jvotXn/z48
	DJEYxj1Eebha0KFxdBcg==
X-Google-Smtp-Source: AGHT+IHGx/7oyJnhms5xQlnV9t2WXi/MUPA5VvbuwbG9Ia77TPFSMieQ9S6E8B+YN8qM5mF7I7BbCA==
X-Received: by 2002:a17:906:eec3:b0:b04:7514:f9c4 with SMTP id a640c23a62f3a-b04b167d1cemr652353666b.43.1757321348314;
        Mon, 08 Sep 2025 01:49:08 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 10:49:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
To: Gerald Elder-Vass 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@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: <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.09.2025 14:10, Gerald Elder-Vass wrote:
> From: Ross Lagerwall 
> 
> Also cache it to avoid needing to repeatedly ask the firmware.
> 
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Gerald Elder-Vass 
> ---
> CC: Marek Marczykowski-Górecki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monné" 
> CC: Stefano Stabellini 
> 
> v4:
> - Fix MISRA warning regarding SecureBoot string
> v3:
> - Fix build on ARM
> ---
>  xen/common/efi/boot.c    | 24 ++++++++++++++++++++++++
>  xen/common/efi/runtime.c |  1 +
>  xen/include/xen/efi.h    |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e12fa1a7ec04..ccbfc401f7ba 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *file)
>                     " last line will be ignored.\r\n");
>  }
>  
> +static void __init init_secure_boot_mode(void)
> +{
> +    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
> +    static CHAR16 __initdata str_SecureBoot[] = L"SecureBoot";
> +    EFI_STATUS status;
> +    uint8_t data = 0;
> +    UINTN size = sizeof(data);

Unlike here, ...

> +    UINT32 attr = 0;
> +
> +    status = efi_rs->GetVariable(str_SecureBoot, &gv_uuid, &attr, &size, &data);
> +
> +    if ( status == EFI_NOT_FOUND ||
> +         (status == EFI_SUCCESS &&
> +          attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&

(Nit: Overlong line.)

> +          size == 1 && data == 0) )

... any reason it's literal 1 here?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 08:57:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 08:57:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114843.1461646 (Exim 4.92)
	(envelope-from )
	id 1uvXgH-00059S-GZ; Mon, 08 Sep 2025 08:56:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114843.1461646; Mon, 08 Sep 2025 08:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvXgH-00059L-E0; Mon, 08 Sep 2025 08:56:57 +0000
Received: by outflank-mailman (input) for mailman id 1114843;
 Mon, 08 Sep 2025 08:56: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 1uvXgF-00059F-Mf
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 08:56:55 +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 c40073c3-8c91-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 10:56:53 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6263d0e4b94so3097054a12.3
 for ; Mon, 08 Sep 2025 01:56: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
 a640c23a62f3a-b04709b3effsm1230356566b.5.2025.09.08.01.56.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 01:56: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: c40073c3-8c91-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757321813; x=1757926613; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Y3Oj13E/8iwlGqxNJRLrxfjHufoWXuRWkz35ljJcAxo=;
        b=CoNdOlEh9FcEq0hxHzbtNrfLhTeXbPTRTRGVQkF6Mxayyog9LooRKzsWZ9I6QkHuXW
         HcfhuebyYsV5uvRdy6TcZ/A7C+pnmfUeKxzrTxqGTQzN7M++hfgYqWD0p0gzBo3Bx3Go
         hJloJSTSwN2pA6t/mnLPalJrzXWIefQdKUw1ctLskq/DN6fH9Gt7dxDAqAbBXomozlnY
         8kuWWDuzLEOZgdbYCmuBNlFHubwQrUvNOwZWjGwfbLNYB6zLMwT3CG8D7WUyZkDdr6Ks
         zUIvuci7TBIngqluesADLS+ZOYO79xZp2W29OJlk9TdrJXCS64wjTsI8vd9ntLyDXwZi
         zbKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757321813; x=1757926613;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Y3Oj13E/8iwlGqxNJRLrxfjHufoWXuRWkz35ljJcAxo=;
        b=a/9nARB/rR+VY7pp30z92+nltrAshh3tLFfOP0NbpW9Eewz6OGUi7icSN2HNS84sfy
         xl/q9swvwEfmZlTHZofCF8Ay9y3gJuG3248A3dyt02w8nkeVXm9FCmyqVpfnbJmXetwv
         pxR5Pt5n7k71hu2dRuv6cOrKnRsjqHK5qvwcMTSjh5+kI1DEE+aNnvfeRTZBilYfBfmV
         HH63yGA5gdAN/nMv3t+aNyaeallSxo0jJG1v3Abk6vA8RG2ZYO7cxa34uzq2N2BVhd4w
         8MXh+ZvlC5J02kFEg6O8TakDaBurCPzR5yILQbVfLKRq/3mhxSw5Tr1wYPD7D+sQClKU
         xCDA==
X-Forwarded-Encrypted: i=1; AJvYcCWI20GhSJpa1tQeAzIaXVkXu/VUx50OdCWLPtrN/Rfom2HOPmueFEKRg9Tf77uytD0ANWUVDnoryOI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFlUJC36K7uMdq8QF6h6ko2VMXGswMa1aCLPGxTRf0yrXz4tO6
	XwsJPpM9rmZUDZgNIRTBqtKnmIgkPGH/gJcp8RWnet20litHuoVBRR5Hd7pxLoK9mg==
X-Gm-Gg: ASbGncuXypxFcY8b4voY4hp6ALrnOSgqwsmDE4qwNwrciB5Y/wB1lhWStXsxcrBBLJJ
	4WzJ16bIneDt6AEuvPRVgjL984INdF0wxlVETbl0Z28Sx6a1ELKKhxlv6moOoYSyk5dutpcpPN7
	Sk0dbb77yQsaBooIvivs6j3T8aZeTwLtedu0v1hMISZJgYyo8iCzeaHKsRUcwYxdHTUQGJp4O1T
	KeDrIA3neTCqkfPcYh2nId2UoXT1+9z2g/kIFLaBuRs1rlaGGsYCtwESk+xB7rZ2QsPuCYYOY0j
	+uQW/1zRAvwbozwBQRJLplqvs2VVLcA1xOe1tn9UtKL5031sveWJT2gnM5ZjrgIhnpD8yMyyRky
	TgatkwNZc/dQF9Wir83LghbIXutYxGZEKtfe5Fo5APdadxdOgqp1aQPW5r3t1hc0AYimEfDpI//
	nCJhbUIMua0mr6xxh3tA==
X-Google-Smtp-Source: AGHT+IFf6FpZO6cyWpcxo7Ko6NZ7qThjf3QzFX4rgMALkIbN5x0R8dWzA4WGMsrltvbBnDsvO5GZAw==
X-Received: by 2002:a17:907:3dac:b0:afe:9e58:7550 with SMTP id a640c23a62f3a-b04b140cfe6mr710473466b.19.1757321812961;
        Mon, 08 Sep 2025 01:56:52 -0700 (PDT)
Message-ID: <6647009f-a1f8-4cf0-923a-c04f0a59106a@suse.com>
Date: Mon, 8 Sep 2025 10:56:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/2] efi: Support using Shim's LoadImage protocol
To: Gerald Elder-Vass 
Cc: Kevin Lampis ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: 
 <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@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: <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.09.2025 14:10, Gerald Elder-Vass wrote:
> @@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>      return gop_mode;
>  }
>  
> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> +{
> +    static EFI_GUID __initdata shim_image_guid = SHIM_IMAGE_LOADER_GUID;
> +    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
> +    SHIM_IMAGE_LOADER *shim_loader;
> +    EFI_HANDLE loaded_kernel;
> +    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> +    EFI_STATUS status;
> +    bool verified = false;
> +
> +    /* Look for LoadImage first */
> +    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
> +                                           (void **)&shim_loader)) )
> +    {
> +        status = shim_loader->LoadImage(false, ImageHandle, NULL,
> +                                        (void *)kernel.ptr, kernel.size,
> +                                        &loaded_kernel);
> +        if ( !EFI_ERROR(status) )
> +            verified = true;
> +
> +        /* LoadImage performed verification, now clean up with UnloadImage */
> +        shim_loader->UnloadImage(loaded_kernel);
> +    }
> +
> +    /* else fall back to Shim Lock */
> +    if ( !verified &&
> +         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> +                                           (void **)&shim_lock)) &&
> +         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )

As already said on an earlier version, the use of !EFI_ERROR() here is a
behavioral change from ...

> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
>       * device tree through the efi_check_dt_boot function, in this stage
>       * 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 )

... checking for EFI_SUCCESS alone here. There's also nothing in the
description justifying the change. (See the various EFI_WARN_* that exist.)

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:04:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:04:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114859.1461662 (Exim 4.92)
	(envelope-from )
	id 1uvXnW-0006zP-A9; Mon, 08 Sep 2025 09:04:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114859.1461662; Mon, 08 Sep 2025 09:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvXnW-0006zI-5c; Mon, 08 Sep 2025 09:04:26 +0000
Received: by outflank-mailman (input) for mailman id 1114859;
 Mon, 08 Sep 2025 09:04: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 1uvXnU-0006zC-Sh
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:04:24 +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 cfeff4ea-8c92-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:04:23 +0200 (CEST)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-336b071e806so36069761fa.1
 for ; Mon, 08 Sep 2025 02:04: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: cfeff4ea-8c92-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757322263; x=1757927063; 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=3H+NDhuBzFU7/0BQZrmGJSHfPYagzaqwE55SgUvWRTw=;
        b=D030oT/yViWgCOr1TTDui7Ibwwrwgmiu1IFDO+BrH95P5QiuR0jlHc2eng9r4Wrv7r
         Zx6rH1/GLJhE+EFg/Gx8JUvQyVw1WGCZWFZvUDMChz0vhG7zychTUIiWylLnTcnRKfoe
         9rYv0sf5fbWh4odK5ULFROC4rB/Kt26CQw46aJK8/pzenjXPlDbdgtBgVItH4Mm3Lyyp
         kBPVuVefZjZ5y+Qi9wf5K9/KFouqIgIe9ujy1x6Fpvx3rAF+HCEAA6/6HqsvcVi8Lr72
         CERrGKabAEWTkPT9acA5xIZwcFVbp2u2YMp+N/70ZRSCWfcrg41f3Km0VHCstm8sCNSw
         LL5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757322263; x=1757927063;
        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=3H+NDhuBzFU7/0BQZrmGJSHfPYagzaqwE55SgUvWRTw=;
        b=Y/QFIwpi6F8RCRKsaScCLJqO0c6LyQdTiOB+3qrf7KR5sviGOUgj7aYjuKsWU+F0Xc
         VSyNt/NVHEDuXyG7rTjxUEe+rq4hZsAUcaj2YBwEZmVSBeVwLhkp7kBBIE4VVkQ5HxiS
         qHlqtZKRGPv9fxOlzCCqA7WmDuZRYgaNTdYJJWoXuHbxwwpwY4y/xOfdYrbxNmN/ENDr
         +QPRlSuHfQjpcys3nCv1NmaygB9as5wWp39/0owg8SqkrfcMcQWXo+EfaFVS/p0coQb8
         EXMEGHIP9k0AKn1ybjWC1TSNiJ+n4nPObA1jnBEd1o4O2OqQh4TZJ9zn2wfZGzoxiK0O
         PVlA==
X-Forwarded-Encrypted: i=1; AJvYcCWq90G9SoiJ6VTO440Q2VJL+myb2OgodojoNKgO8PbkLbyXQdXlxU40G7bUKbK6P1SnTPjmcWJK+Q8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyFKqyJHTLGhkcm8A5Tvz5AvFMt6wo5EbFvbpPbvXvz0uI7jGlj
	r7DTifNh5SgaLYRc65qAGLlmMzlFIFYsOje2DdN6Xn4RQHX3L8/AEzJObkvrbyhL4BGwgelz0EA
	sYk3FqyzSdSSeFDvTjPcPpaJDUfUUURs=
X-Gm-Gg: ASbGncs09ADijldGy7OkGl6nq2PN7oxl1DvXoEJyfXPiiZQE75/7kgNDSYXLMUq86Ls
	8x5oVng9YIk1whDABAuGFeKeUuvfQQeGxpYAySqx0T859LeFVwaZONPEskLMtxDxxMhn+kJEU+U
	ZiRoEkMPn5XRePMEaA7P7KqiGmdyMWNho/loF/05Qwb88scDC2xJhHwQ90vn6DGXf7aRnBp/tvc
	ioh2Q==
X-Google-Smtp-Source: AGHT+IGvNiFAE25gOTt4VJbBRIxBdBf3jcVvF8AQIzxMcgOhwIzmR4+M/t5xlE7CZH5GseplTGCMUQfdYQPfIlAX+FE=
X-Received: by 2002:a05:651c:400d:b0:338:2ef:649b with SMTP id
 38308e7fff4ca-33b553ae8c8mr14965711fa.27.1757322262299; Mon, 08 Sep 2025
 02:04:22 -0700 (PDT)
MIME-Version: 1.0
References: <20250905232715.440758-1-dmukhin@ford.com> 
In-Reply-To: 
From: Mykola Kvach 
Date: Mon, 8 Sep 2025 12:04:10 +0300
X-Gm-Features: Ac12FXxkizsrO_ZopBmBLCyD-WlOSVLeyqe3PlqMM4Zxdj8bhhg91L1jgdKhxG4
Message-ID: 
Subject: Re: [PATCH v6 00/15] x86: introduce NS16550-compatible UART emulator
To: Stefano Stabellini 
Cc: oleksii.kurochko@gmail.com, xen-devel@lists.xenproject.org, 
	andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, 
	julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com, 
	dmukhin@xen.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis and Stefano

I=E2=80=99d like to acknowledge the significant effort that went into this =
patch
series -- it=E2=80=99s clear that a lot of work has been invested.

On Sat, Sep 6, 2025 at 5:02=E2=80=AFAM Stefano Stabellini
 wrote:
>
> Oleksii and all,
>
> I would like to consider patches 1-12 of this patch series for 4.21,
> pending the few minor comments I made addressed.

Although I am neither a maintainer nor an official reviewer for this
project, I have looked over some of the first patches in the series. In my
opinion, the series is not yet ready for merging.

Even if my review is set aside, the changes are largely x86-specific and
produce the most impact on this architecture. I believe that before
merging, one of the x86 maintainers (or at least a trusted reviewer for
x86, if available) should carefully review these patches.

>
>
> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
> > x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support=
 x86
> > guest OS bring up in the embedded setups.
> >
> > This patch series introduces initial in-hypervisor emulator for
> > NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.
> >
> > In parallel domain creation scenario (hyperlaunch), NS16550 emulator he=
lps
> > early guest firmware and OS bringup debugging, because it eliminates
> > dependency on the external emulator (qemu) being operational by the tim=
e
> > domains are created.
> >
> > The emulator also allows to forward the physical console input to the x=
86
> > domain which is useful when a system has only one physical UART for ear=
ly
> > debugging and this UART is owned by Xen.
> >
> > By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O po=
rt
> > 0x2f8, IRQ#3 in guest OS (legacy COM2). Legacy COM resources cannot be
> > selected at built-time or via per-domain xl configuration in this initi=
al
> > submission.
> >
> > CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities usef=
ul
> > for NS16550 emulator development/debugging (disabled by default).
> >
> > The NS16550 emulator is disabled in default x86 configuration and goes =
under
> > CONFIG_EXPERT in Kconfig.
> >
> > Limitations
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > - Only x86;
> > - Only legacy COM2 resources, custom I/O ports/IRQs are not supported;
> > - Only Xen console as a backend, no inter-domain communication (similar=
 to
> >   vpl011 on Arm);
> > - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
> > - No toolstack integration;
> > - No baud rate emulation (reports 115200 baud to the guest OS);
> > - No FIFO-less mode emulation;
> > - No RX FIFO interrupt moderation (FCR) emulation;
> > - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> >   friends);
> > - No MMIO-based UART emulation.
> >
> > Series
> > =3D=3D=3D=3D=3D=3D
> >
> >   Patch 1 introduces the new vUART framework, that is the code original=
ly
> >   posted here:
> >     https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@=
ford.com/
> >   Required for emulator.
> >
> >   Patch 2 adds missing NS16550 definitions, required for emulator.
> >
> >   Patch 3 introduces the basic emulator skeleton - state machine
> >   initialization stubs, I/O port handler stub, logging, etc.
> >
> >   Patches 4-11 incrementally populate the minimal NS16550 register emul=
ation.
> >
> >   Patch 12 hooks vUART state debugging (disabled by default).
> >
> >   Pathes 13-15 introduce necessary changes to enable NS16550 on dom0 (a=
nd PVH).
> >
> > Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/2024756493
> > Link to branch: https://gitlab.com/xen-project/people/dmukhin/xen/-/tre=
e/vuart-ns8250-v6?ref_type=3Dheads
> >
> > Testing
> > =3D=3D=3D=3D=3D=3D=3D
> >
> >   ```shell
> >   echo CONFIG_EXPERT=3Dy >> .config
> >   echo CONFIG_VUART_NS16X50=3Dy >> .config
> >   make olddefconfig
> >   ```
> >   COM2 (0x2f8) resources are used by default.
> >
> >   To test w/ virtual COM2, the guest kernel parameters should contain
> >   something like the following:
> >     earlycon=3Duart,io,0x2f8,115200n8 console=3Duart,io,0x2f8,115200n8
> >
> >   HVM
> >   ---
> >   Tested only boot of HVM linux guest with OVMF as the virtual firmware=
.
> >   SeaBIOS as a virtual firmware is not tested.
> >
> >   PVH (dom0)
> >   ----------
> >   Xen is able to forward physical console input to the domain with virt=
ual
> >   NS16550. To switch the console focus press Ctrl+aaa.
> >   Console switch is limited on x86 to dom0 and Xen (fixes pending).
> >
> > Changes since v5:
> > - Split THR/RBR into two separate patches.
> > - Addressed feedback from v5.
> > - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-=
1-dmukhin@ford.com/
> >
> > Changes since v4:
> > - Split the series to make it simpler to review.
> > - Addressed feedback from v4.
> > - Dropped xl changes, which I will submit separately.
> > - Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-=
1-dmukhin@ford.com/
> >
> > Changes since v3:
> > - Reduced the blast radius of the series, thanks to reviews, individual
> >   aspects (like console focus) touched in v3 moved to separate threads.
> > - Kept the UART emulator framework since I need to redo some of emulato=
r code
> >   and there's more-or-less agreement on it (where to place, naming, sco=
pe).
> > - Applied the feedback from
> >     https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@f=
ord.com/
> > - Link to v3: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v=
3-v1-0-c5d36b31d66c@ford.com/
> >
> > Changes since v2:
> > - renamed emulator s/NS8250/NS16550/g
> > - reduced the patch series after addressing v2 feedback
> > - introduced driver framework for UART emulators
> > - unified guest OS printouts across all available UART emulators
> > - Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v=
1-0-e9aa923127eb@ford.com/
> >
> > Changes since v1:
> > - dropped kmalloc/kfree aliases
> > - fixed ECLAIR jobs (thanks Andrew Cooper)
> > - addressed console forwarding on arm32 and arm64 (thanks to Luca Fance=
llu)
> > - moved NS8250 debugging stubs into its own patch
> > - added fix for https://gitlab.com/xen-project/xen/-/issues/184
> > - Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-8=
7b9a8375b7a@ford.com
> >
> > Denis Mukhin (15):
> >   emul/vuart: introduce framework for UART emulators
> >   xen/8250-uart: update definitions
> >   emul/ns16x50: implement emulator stub
> >   emul/ns16x50: implement DLL/DLM registers
> >   emul/ns16x50: implement SCR register
> >   emul/ns16x50: implement IER/IIR registers
> >   emul/ns16x50: implement LCR/LSR registers
> >   emul/ns16x50: implement MCR/MSR registers
> >   emul/ns16x50: implement RBR register
> >   emul/ns16x50: implement THR register
> >   emul/ns16x50: implement FCR register (write-only)
> >   emul/ns16550: implement dump_state() hook
> >   x86/domain: enable per-domain I/O port bitmaps
> >   xen/domain: allocate d->irq_caps before arch-specific initialization
> >   emul/ns16x50: implement IRQ emulation via vIOAPIC
> >
> >  xen/arch/arm/xen.lds.S                   |   1 +
> >  xen/arch/ppc/xen.lds.S                   |   1 +
> >  xen/arch/riscv/xen.lds.S                 |   1 +
> >  xen/arch/x86/Makefile                    |   1 +
> >  xen/arch/x86/dom0_build.c                | 112 +--
> >  xen/arch/x86/hvm/dom0_build.c            |   7 +
> >  xen/arch/x86/hvm/hvm.c                   |  56 +-
> >  xen/arch/x86/hvm/nestedhvm.c             |   8 +-
> >  xen/arch/x86/hvm/quirks.c                |   3 -
> >  xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
> >  xen/arch/x86/hvm/vioapic.c               |  10 +
> >  xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
> >  xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
> >  xen/arch/x86/include/asm/hvm/support.h   |   2 -
> >  xen/arch/x86/include/asm/iocap.h         |   2 +
> >  xen/arch/x86/include/asm/irq.h           |   8 +
> >  xen/arch/x86/ioport.c                    | 163 ++++
> >  xen/arch/x86/irq.c                       |   8 +
> >  xen/arch/x86/pv/dom0_build.c             |   7 +
> >  xen/arch/x86/xen.lds.S                   |   1 +
> >  xen/common/Kconfig                       |   2 +
> >  xen/common/Makefile                      |   1 +
> >  xen/common/domain.c                      |   8 +-
> >  xen/common/emul/Kconfig                  |   6 +
> >  xen/common/emul/Makefile                 |   1 +
> >  xen/common/emul/vuart/Kconfig            |  25 +
> >  xen/common/emul/vuart/Makefile           |   2 +
> >  xen/common/emul/vuart/ns16x50.c          | 984 +++++++++++++++++++++++
> >  xen/common/emul/vuart/vuart.c            | 157 ++++
> >  xen/common/keyhandler.c                  |   3 +
> >  xen/drivers/char/console.c               |   6 +-
> >  xen/drivers/char/ns16550.c               |  16 +-
> >  xen/drivers/passthrough/x86/hvm.c        |  11 +-
> >  xen/include/xen/8250-uart.h              |  50 +-
> >  xen/include/xen/sched.h                  |   4 +
> >  xen/include/xen/serial.h                 |   3 +
> >  xen/include/xen/vuart.h                  | 116 +++
> >  xen/include/xen/xen.lds.h                |  10 +
> >  38 files changed, 1634 insertions(+), 171 deletions(-)
> >  create mode 100644 xen/arch/x86/ioport.c
> >  create mode 100644 xen/common/emul/Kconfig
> >  create mode 100644 xen/common/emul/Makefile
> >  create mode 100644 xen/common/emul/vuart/Kconfig
> >  create mode 100644 xen/common/emul/vuart/Makefile
> >  create mode 100644 xen/common/emul/vuart/ns16x50.c
> >  create mode 100644 xen/common/emul/vuart/vuart.c
> >  create mode 100644 xen/include/xen/vuart.h
> >
> > --
> > 2.51.0
> >
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:08:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:08:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114873.1461671 (Exim 4.92)
	(envelope-from )
	id 1uvXrc-0000QC-Tb; Mon, 08 Sep 2025 09:08:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114873.1461671; Mon, 08 Sep 2025 09: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 1uvXrc-0000Px-Nm; Mon, 08 Sep 2025 09:08:40 +0000
Received: by outflank-mailman (input) for mailman id 1114873;
 Mon, 08 Sep 2025 09:08: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 1uvXrb-0000Pr-AD
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:08:39 +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 67e26256-8c93-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:08:38 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b0472bd218bso648864666b.1
 for ; Mon, 08 Sep 2025 02: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
 a640c23a62f3a-b040d44c9adsm2138413466b.9.2025.09.08.02.08.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 02: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: 67e26256-8c93-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757322517; x=1757927317; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WEpQWJAguHNxZnf5RskzNGHiQ7p8CvADHoDg7CzPj7o=;
        b=Bq4/pcEnUKpjpsdjteCiwvkJ9caw57YGGGrmtGGaPqjvOP7o8e/GS61irq70qo8NLX
         Gpo3lGDPP42psmTblFAfyPvncfsK9Th2lJssfFpoIgEgOjhd5ZPY+j2B9rTIWMrnYZiH
         bj9Cw6EZZWYDYIyY4/f5lo2RlT0p3Du01OgpI6XVnQUr9idwp8gSoBaiK2iR2LSWDIGC
         NQSK5qqwzY1Hn4XvNI8wYhjMODrXT/Ozyi15r+Zx7UKaf+bRDI62Xx3LHY/Cd9FnR6KE
         D9xSyfpr+w0q2WjdKf6pdSP5IHm6OamMaW5OujKe21TJSq5f/tq0r7T5pMY3y5oMN53P
         zdBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757322517; x=1757927317;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WEpQWJAguHNxZnf5RskzNGHiQ7p8CvADHoDg7CzPj7o=;
        b=K1dlRnLqug6m8Q6QnKYWv6jkBEQmK88NkFqoTomcQt9nZgIc13Gdq1oxPS8/n8KvgI
         e8xt97oFJ06LNEDqUqXG4xyh9A8/wOeEj32lO0GM0mx0bcEm4G7WIvP0bGytpMaZCpoC
         ixv+L38ZDtf1wChK5/T1VUBVfDRTxmgNB0fdOuitwe5c1D+Sburhd7PjbsMPQpucVnjc
         Iwn4NWWPwoDH4Nnp4N3umUpgKcqRZmrru9Ps1kegFANZ0ZhRP2X9veCfl2t5gDu2qRli
         KCfYeNbTwAzG/9CQaQSqWl0/ZsTPc/0W0C3a9WFvrRoKtBzefAf+WOtEp8Lwbab/hTgM
         4trA==
X-Forwarded-Encrypted: i=1; AJvYcCWU9iri2SFkUj05GwQdWp+VuHxUzmf/L8r36pPyIASZGchPZ2Ojl1/S/E1sEnQtTkNLUTyEGUgT8sc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyhzy05Myh3K0aIy8fvq+o642vHfvmVFB5tlqwps3+aH/FdwVbQ
	Ed3VadV9IRku6yBXEfdPS8CL0jTSolrqw2zpWtQ+kFyIpLQ/UilfT5SD65VGpbQSKA==
X-Gm-Gg: ASbGnctXKrjK4TUfHsZ9yBdCX6RBRNLZd0CrsEIpNOnSfBVA1UV3ISwU49iBtC0JIlq
	xAgcT8y6yEMfEu+0oNNUh6B/c+cHfAuNQFJAJtl7644T5AzqjMKscjQSh0BULBxJqXw/BbCeDEe
	2y5gGgkIYxTnd35AhDZ23r/a4OynCVwyUQ+xG1/VqAysc6f4PSg6czzrbJAdalTlU6iMj3xHkF5
	sSioZhckIPOmRaud0LyiJCLUbGW9rNuHjz3NkPbW1OhCiPiwsKfK8h7TSF7dhqlJZu1xo/lBYUW
	/UB2IZ0vlVk3KjwsUjeBkFA2WPEwJriy/ZOcQ4TXEWFl1MzO3Pn0ppw32VWva+nxC3PLzG1HZJM
	6CTebvcv3IYOCsosZ2ZBIOBtl3OiCEh+E2ZNDeBHmrS0zAIPHag+h93KN8dpQTCJpwuxXoZszQe
	y66b9alAs=
X-Google-Smtp-Source: AGHT+IEW4wwj4VNlz0B5HbTxnvcFvYP81avxbkLEMWkrCUvZv4sXjXpZbEAB0fYPq1fPULOgS3qxMA==
X-Received: by 2002:a17:907:1c10:b0:b04:1a80:35b9 with SMTP id a640c23a62f3a-b04b13cd575mr676078766b.12.1757322517466;
        Mon, 08 Sep 2025 02:08:37 -0700 (PDT)
Message-ID: <89d0b668-537b-4ee4-8cda-e0d95d9eed90@suse.com>
Date: Mon, 8 Sep 2025 11:08:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/mcheck: allow varying bank counts per CPU
To: Jason Andryuk ,
 Soham Dandapat 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250905165212.96843-1-Soham.Dandapat@amd.com>
 <32f89ab8-9742-4bc8-a5ef-848b66e788b2@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: <32f89ab8-9742-4bc8-a5ef-848b66e788b2@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.09.2025 19:02, Jason Andryuk wrote:
> 
> 
> On 2025-09-05 12:52, Soham Dandapat wrote:
>> In mca_cap_init function,the mcabanks_alloc allocates and
>> initializes an mca_banks structure for managing MCA banks,
>> setting up a bank map and storing the specified or default number
>> of banks.
>>
>> After this we will call mcabanks_set(i, mca_allbanks);
>> The mcabanks_set function sets a specific bit in the bank_map of
>> an mca_banks structure, provided the structure, its bank_map, and
>> the bit index are valid.
>>
>> At the end, we will call
>> mcabanks_free(xchg(&mca_allbanks, all));
>> This function is thread safe and does below:
>>     1. Atomically exchanges the value of "mca_allbanks" with "all"
>>     2. Returns the old value that was previously in "mca_allbanks"
>> So, when we will call mcabanks_free , that will free the memory.
>>
>> The problem is that mcabanks_set(i, mca_allbanks) function is updating
>> mca_allbanks which will be freed via mcabanks_free later. This means
>> new mca_allbanks instance("all") will never get chance to update
>> it's bank_map.
>>
>> Due to this when we will collect log from mcheck_mca_logout function ,
>> the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
>> and MCA logs will not be collected for any bank.
>>
>> The fix is to solve this problem.
>>
>> Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU")
>> Signed-off-by: Soham Dandapat 
> 
> Reviewed-by: Jason Andryuk 
> 
> Maybe the patch subject should be "x86/mcheck: Fix mca bank 
> initialization" to differentiate from the Fixes commit?

That's still more generic than wanted. How about "x86/mcheck: fix
mca_allbanks updating"? With a more concise title (which can be
adjusted while committing, so long as there's agreement):
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:22:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:22:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114886.1461680 (Exim 4.92)
	(envelope-from )
	id 1uvY4m-0003Os-WC; Mon, 08 Sep 2025 09:22:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114886.1461680; Mon, 08 Sep 2025 09:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvY4m-0003Ol-Td; Mon, 08 Sep 2025 09:22:16 +0000
Received: by outflank-mailman (input) for mailman id 1114886;
 Mon, 08 Sep 2025 09: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 1uvY4m-0003Of-7z
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:22:16 +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 4e07cbe1-8c95-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 11:22:14 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b043a33b060so649902266b.1
 for ; Mon, 08 Sep 2025 02:22: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
 a640c23a62f3a-b042c7b3671sm1889634366b.42.2025.09.08.02.22.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 02:22: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: 4e07cbe1-8c95-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757323333; x=1757928133; 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=To+fyq1+DsW+Z7hPJvmq0jsMSUnqGvpSSfICJdqPr84=;
        b=Pu1fS/qIN5HN2datNm1Nj4uM/d1j2fbd2DLIm1Yw2STcVUR+g5u2F5sXIkFBffZcRY
         pO01KQMUNfodPDHx0ZQMZGjL+PAPwaUvmXYFE42U17M3KXyuPTX4uWfS/yPV/2bjiTdv
         HX0393ly6wYNVElSroMIqqqxuWg6zpPLCXrl/CKm4IJMTbTf0K0oyRgeFJaMQbb5fLSi
         ro7TMufXKn6iwae0TCToKlIByXJhFk+SV1JGgQrVaeODwwlAeqBhT3VEiP09ccHg71ka
         9/wBPFAoJ2wAkmmLKyTPmOmDNhyQBKbwAiLGRxkVAC67rKj3BA5KQFhvc36wp7/zGfjY
         7w3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757323333; x=1757928133;
        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=To+fyq1+DsW+Z7hPJvmq0jsMSUnqGvpSSfICJdqPr84=;
        b=C0xdWNcomCaEUTFD5QX9pau8ZzwIQNhNYGUHdRrmwQz3ThuSfr6Z1VWfLxeXbkh5s6
         Yorj3ogh+l7qX+O9+pJjV9+80Aaw47nK3u9Hi5xAcnJSOI0aF5W0BXegwKL+tukbSDFG
         DzMmDAAMPYZXf8ruylxqNZ+UkW281/AbdVHpwOx9dPXnR+5ScbmAkXpfWqbQnI9qvbV3
         vLHXKSORM677FYVifaAUVaEA3RJF/5XDvzEKvQc9BMw7sieNp4rxHJ8oMh+7g6w7xfDe
         hK187Meio/jFT0caZ6r0YGKFpZwfePXRQV+70IUqrJYhMkPj4EL18u+mCuRRc+rh4Yo+
         ADfA==
X-Gm-Message-State: AOJu0YwFOrWnehFYsXeV+UlcUVGMMcdKK+dbh51c99pQA8dkQf7vdE98
	ijZRlB9fjxdscvky0vDBTb1rvX8GdwR4yUsiuu5sve0ECjxr705rPVHIvgkcmsdfL9Rv8q9tssb
	0eh8=
X-Gm-Gg: ASbGncsuCLNUWoMYu0c3v6eGkApGiO8d+AxfGMnTmvd4EiWQRRL1zDlQ6WwW/wNBvuv
	UHUvMtFTRA6ej0x42DFtSmMygXAfofuP3ENKWV/jWGvWxnewosGasVxCqNBaFEjTazb+5dFJOEK
	+p0DnkqUWKy/6I/afYJJ45GwIYUWuGXreS2ungT0fq3k6XzaUl6sWSfh8oAfDP6MvFjGWO32K/0
	8KJU7cAkMGsMA5/Lb+bLbUFFPN26vEoHISZ5ivT9dQ8GJfYSseTm42Ti8/iTZPM5TbAQnF3R4eA
	u6P6TTSIdSDlAuZHXUAGteizsACzQgn1m3mji0WAU+WAXng2VfAOHbySaCtwey44OZEiI86nWrX
	8/korlJOSYaM6avy81t8RhKRk919oQH2NRSrEp8/bSSTErljaI3LbjA8Vz43pOPYfCQjxt/7/Ob
	PegQiPZI32jadLojdNrg==
X-Google-Smtp-Source: AGHT+IFqSMQ4+y9luPqZJq3VrSrWEw/FSiwLEj+ID/hfLNdG0MjUPZP9FX/bLo1s0qyXjoT7vdT+lQ==
X-Received: by 2002:a17:907:3ccb:b0:b04:3a46:c4f2 with SMTP id a640c23a62f3a-b04b1702e94mr699330766b.48.1757323333074;
        Mon, 08 Sep 2025 02:22:13 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 11:22:12 +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] symbols: fix xensyms_read() hitting the final "end" symbol
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

A new "no (more) symbol" path there was lacking a necessary unlock.

Fixes: d3b637fba31b ("symbols: arrange to know where functions end")
Coverity ID: 1665212
Signed-off-by: Jan Beulich 

--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -202,7 +202,10 @@ int xensyms_read(uint32_t *symnum, char
     {
         ++next_offset;
         if ( ++*symnum == symbols_num_addrs )
+        {
+            spin_unlock(&symbols_mutex);
             goto no_symbol;
+        }
     }
 
     *type = symbols_get_symbol_type(next_offset);


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:31:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:31:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114903.1461691 (Exim 4.92)
	(envelope-from )
	id 1uvYD9-00055c-PP; Mon, 08 Sep 2025 09:30:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114903.1461691; Mon, 08 Sep 2025 09: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 1uvYD9-00055V-Mb; Mon, 08 Sep 2025 09:30:55 +0000
Received: by outflank-mailman (input) for mailman id 1114903;
 Mon, 08 Sep 2025 09:30: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 1uvYD8-00055P-KD
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:30:54 +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 80df22ad-8c96-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 11:30:48 +0200 (CEST)
Received: from CWLP265CA0536.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:18d::18)
 by DU0PR08MB8729.eurprd08.prod.outlook.com (2603:10a6:10:403::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 09:30:39 +0000
Received: from AM4PEPF00027A69.eurprd04.prod.outlook.com
 (2603:10a6:400:18d:cafe::ae) by CWLP265CA0536.outlook.office365.com
 (2603:10a6:400:18d::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 09:30:39 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A69.mail.protection.outlook.com (10.167.16.87) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.13
 via Frontend Transport; Mon, 8 Sep 2025 09:30:38 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20) by PAWPR08MB10043.eurprd08.prod.outlook.com
 (2603:10a6:102:363::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 09:30:03 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739]) by GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739%7]) with mapi id 15.20.9094.018; Mon, 8 Sep 2025
 09:30: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: 80df22ad-8c96-11f0-9809-7dc792cee155
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=iGpmBvfufjmOJ3JFsg1iU8dH7VRNNQK5puR6tGHMSABfhyBYpT31H6j6gFscbC7woUa4R3VBOUdmB/oaW+sYBJsknYcLi/8Owefx3D0OdF/BB6zdwwfi8S9OHHrjE7mVQswC1UmYKfC3HYn+hhJoUyjK3J4QtSktf0ue0hCLeaGwtzeHX0HZYUBZYjlxA+xe2pYaWtNby0VtQ6bCoGlDDNdlYr47qpK1Ik70fb6fy27ZfzsHwzjR8Out/qVyz51ViOPXXZTQxMirbn7GQKE7KP5ZTOIfoMWUykGamwbK3+IzPBx9sxUZNyHSmYz7vrDOTym9eSktXO9n1mHdfOPh7A==
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=vOUWWA/OEL3p0X7QghuOVP3ekc85NorR1xQs8c+jbtE=;
 b=QfXAAzycbnFV0ohmdZkanrjEfvt8XiiVf8p87d3+aMzSv4X2YBnHGrYeSxWDK71Tj7HsZ+TqiEnqswrU3qf+QUG/+ZXvl9dfQjmgPfE5jhACYVcKk+uzVPLNgOU90CpqqjznoiYf4w7P4+xoDrMXiEP33OFfbdimg3So8p0AB8DFX+U7Ml2IZ8bjCCmsfms+QFikwFvsRq+KmNUFM/ArRJYsAIfOU7IMiwOZtc7pOU7vekMMgylMucE+87CEnZ8GO+/gy9iJ83HWoku3kSGmF7ZtNasa0YiQBBp+kvHJYhYiQdxDLY+Tgth7wtb4CeDDSJaiQQ3BNTLbv0dp2EkPIQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kvack.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=vOUWWA/OEL3p0X7QghuOVP3ekc85NorR1xQs8c+jbtE=;
 b=QXEMMy0jbf8+cJwrQCLoZ+L2M/et+OVOUFWxToDX+d8MDQ/2RVcJaV9llBTR5oV5mrxkrhrAP4e+VV8iMsQA8o1PzMKxHVfGm8rvISCmL/Hyl0SdhlI8H4fLCyUxLRQ+wnBA8mqGrFbJrAgJn7r6ILJ/LkX/TEVXxgx3YLSHEyU=
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=xoX2Dbq0kHw/BHmBV26uWb8hs95iiOCAj2a/rJpBuDMhN5dL/Ssziqb9zeIM9/waLCHYvGCrfKduV7Fmj8Tz4DJquXymLD38rlPneK9YfMBp/1kaE0zUdu4kRGwkCmxPA/EkjPWwPfYh0PWEmj8zRlptjuQlzcJ2rv8b6g+hstvfkEbDA0HFIHZGuo+fs9kxcwsSArm8PEdNBBaKcWTVT5VrI9RbCbRiEJmTwaqsTPk1ejUguWNbI0rRnK0dM8r4gTaNNLB22opFnIsDsycbYdhA2wYIFkXNWYLWaBm2OmJ1/qEx06s6KZpRxmN+opw7wYEGmaHZSh4WKiyV8Y8i7g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vOUWWA/OEL3p0X7QghuOVP3ekc85NorR1xQs8c+jbtE=;
 b=NUtcRawChS5qDt8PnMtuLkR7MJj30sNUZxcPsJ77C35mpsOPVYrUbOx6zpJ6udsxPA62SnMtndz8sfgJOynqlOEuO8hD/9O6ulLFt4kmaKvY3iNSNPprw+3qo8KlrDjKcf34TusnQsbhon6MjJPtrRYV5dPl8b1SfSB6yzSx/FWNAKSpOfoqv+Gdmh2NjSlsjFvBQtiPGhZJSqNSdf+6pptFc8PMZt//FdBDqKyAhIPGINFEyycGhKJ6v2sCwRVQ5p4i/2UBqKlE7CUhtIbT33DniBxcNQJVtmGmN+1Pvg4U2SXBa6TbEf73dYZCVzipw/f1jq2qM/vz4KKYEZ5poQ==
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=vOUWWA/OEL3p0X7QghuOVP3ekc85NorR1xQs8c+jbtE=;
 b=QXEMMy0jbf8+cJwrQCLoZ+L2M/et+OVOUFWxToDX+d8MDQ/2RVcJaV9llBTR5oV5mrxkrhrAP4e+VV8iMsQA8o1PzMKxHVfGm8rvISCmL/Hyl0SdhlI8H4fLCyUxLRQ+wnBA8mqGrFbJrAgJn7r6ILJ/LkX/TEVXxgx3YLSHEyU=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Date: Mon, 8 Sep 2025 10:29:58 +0100
From: Yeoreum Yun 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/7] mm: remove arch_flush_lazy_mmu_mode()
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-2-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250908073931.4159362-2-kevin.brodsky@arm.com>
X-ClientProxiedBy: LO4P123CA0123.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:192::20) To GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	GV1PR08MB10521:EE_|PAWPR08MB10043:EE_|AM4PEPF00027A69:EE_|DU0PR08MB8729:EE_
X-MS-Office365-Filtering-Correlation-Id: 3b09db62-edf5-4d92-90d8-08ddeeba5f8d
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|7416014|366016|1800799024;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?f1IJZJHljl45/WtULoZQyk3Ik1Ezhox9xuh0cfix+5mYbsmGZpqELCPQxXVT?=
 =?us-ascii?Q?JdaCBzxgHkEafJMNZ8etA8dIwVwCFwwP8UfEsDxrZmpftLfbq6SRkOw86d57?=
 =?us-ascii?Q?6/Lf0ssxB9ktwpwPOshc5DxX9XPge+drJyf3q6r+uuxddcAxALxRbbDJdJ8K?=
 =?us-ascii?Q?+stEODE02G/qo+qHMCQojV4N3Y9HFRJbWj+QtFnPd/l+2OIWpAewB9do9lH9?=
 =?us-ascii?Q?fI57egw1nc26OnvIgOfhUAlF7ZumcQ0c+yxsK4MLPNUjBi/y4W8JVsG0C4k3?=
 =?us-ascii?Q?KsI/2XKmjB7Ur58FnOFLaxg8vfMfbfJCuI0qSOHabLXgFDGGJw+xd/cuUbz6?=
 =?us-ascii?Q?vmdblVkx+Aul3uY6mqrZnhC7PjMHtLK/xqGF5DA+jMNXM1EipyfWL+hWO+UP?=
 =?us-ascii?Q?c3cUVITbvu+X3KJVcXx/D6yUivYOE/sZYmEAwa8rIlgi6xA3zgI6mgn2YEHY?=
 =?us-ascii?Q?bET/Q8yX++QM3dCrD5/ULKuj1SRvRpaCIZpHCHTcdNHsGp5RE03SCpvkoP0+?=
 =?us-ascii?Q?6yMAuGzaMcXqE+lEB7A62w7YBp/+8CRbk/LuxoksKGBJlOJOBwHRZtRerNO0?=
 =?us-ascii?Q?k6QLAhCXMeWgGIcPihTzcxya8fs/3jR/Chkg08zFXr1VBoakEATGQBTaqn8C?=
 =?us-ascii?Q?tejt36oa48uVWDqA2RgZsU5Hw6SJc9PLlBMf5TBM3xTlbheKZ5/K9xkils4p?=
 =?us-ascii?Q?4Qw3HkjxK6xfxKakeS984EqbORRHkGwNVZIYnFXK0y8nFjF9mSQj0Mmrjey2?=
 =?us-ascii?Q?qmGAvnYXA8MWBC918bfvrMJsud4MjxFvsK8JJ16uVZqs6QjJHKSeYxlHaTIg?=
 =?us-ascii?Q?BfNxIwmy6aALHpON+MS9FCZbnB0etI7+V4d+5yiFgWE2RTOdJj1sNcVTivtv?=
 =?us-ascii?Q?MzyDCdAQ/Nb1y7aQGpree22MS4RHtSBg2+n82Y/AO/+tDRRIa1VR9RdPAd/E?=
 =?us-ascii?Q?yRRVtLVUrCfacMTRrdBqWv0p/ihxsQ2a1hYToOyfxpYmwEb1UzuK+xa11+32?=
 =?us-ascii?Q?jlEAx2v5mTUlf9LkXNMH1fsDR5uanV1AhnCXUnDo2vIpxACtVPR1b6PCN0W2?=
 =?us-ascii?Q?LPXqdgE2qyec5NsVYnvwbk3Eo7V7T+nk9N/9E+qotNquxWmRRrF7Hd29OTo9?=
 =?us-ascii?Q?yOnZtOXOI5B51ssW6bnVzu9wmebVh7QaYPe9sp78Ggkf54Unk0RbrcuVKHrt?=
 =?us-ascii?Q?rUEnFPSMRQPScQQrq9TsBpvVSNx/iYq4Mr0NjOgLoX3nW/MzR4kfePAxtfVA?=
 =?us-ascii?Q?ewqNogWsqTMa1Kp/YR6ofF/8hiwV6q7SJW0+b96Ghy7dmi87XCoRNrLNoopL?=
 =?us-ascii?Q?MPKPjGVVuV3X5o9JG7dBM47BEPsGlMZPVURyA32eLLsXqII+qu9OOMbl5nIK?=
 =?us-ascii?Q?0Y9d152DKvfDq3qKPsegtLB8VMJ5kg4HPJDNSjF17E0pBzeYHNzpKKdpB5CU?=
 =?us-ascii?Q?FfZ887dUCtA=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR08MB10521.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10043
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A69.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	ee929ebe-d05a-4cf7-3e2b-08ddeeba499b
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|35042699022|376014|82310400026|14060799003|1800799024|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?XTb55XNyCTqw7LDqiWySGgdu8y8jTXVniS46YcPt9jbJRNZ4aUcoSxeP0MxR?=
 =?us-ascii?Q?sFxcDq45q8TvxsRfrrzGY4F/QvRTwySlH2c9xHkqN2NglQ+EjEHzdN9ebkQf?=
 =?us-ascii?Q?JR3GLhvuwpPlKTJg5LuWH0+N60leOmqBg5SHfloEdrc575UJCnEqcHQacroe?=
 =?us-ascii?Q?1C7ASUHtuLkO6V++csVTZMfU4+mFWLXNU0Kbi9Uaa/CU674Ti2fbbGzzfEW7?=
 =?us-ascii?Q?XwHPce863w2bpPuiWG1+lxGopvXGh8eGUHAGoNcHNiNC72tHQag+EvWeMn/4?=
 =?us-ascii?Q?thUrEHJaZVRcoOdxQFAJrMIAmwJaBesH5+MfH74xFDK8WSbvUzZlN69AKvso?=
 =?us-ascii?Q?oUfV+Q2zwwK7yNnQzJ1do5bJyKqC+R1off5ZHvFefhryM/cU0FwS2rwcNXyd?=
 =?us-ascii?Q?f80Ufep7/YH6QaSrvRaL8wr1doa2aB5ro7oZ1jMvYC7VUwZIDY7nZTZ7/4dp?=
 =?us-ascii?Q?o3twL6IiVcP6eHFu2JsN5mUuH2ES9ChHR7V6B+H7gUu8XVWuJhD3jS49RNg8?=
 =?us-ascii?Q?K+IrgwC0ZcQhZoTj0CQ5pMZdIncNmvr6cy27OpIxf8fknBYcST8+8v6PnBzc?=
 =?us-ascii?Q?F+qv9TV0EyDZI0q6QsHQrXwD6zEBhYY2zhfJxvPbatGzyaUHB7KPnqRs9FBn?=
 =?us-ascii?Q?M9dvOlfXArybqocu71KPEFxnkWWvMWaRTOZfPbjZmszfS4O9nad98tyQhSU6?=
 =?us-ascii?Q?bLsuUAGadUVeNz7TYU4AGZ6GvKh9ElYb9BtxEebNChNjwZv1IdNcxFVjgfIp?=
 =?us-ascii?Q?4ibZmq9WJdpjgsvtxVSEGnvjGyAL+/pR2bwvrDQq6fTgCHFSlf8oifiDbPTZ?=
 =?us-ascii?Q?P4y2mVUWLuKK1h04PU04TIew45CrLwROGRgR2+dO6xCsW1PpUlRa5x096IdO?=
 =?us-ascii?Q?wSII2fJUMaj3fR7wH6GJMHbTeK8K6lLl64ZDSeHi7aUXeob+f+Bvb/6BLseg?=
 =?us-ascii?Q?/LB/F0cWG5+UpArGtyslxwKuopiyP+doRlqhnHOZXO2nCbh/fBzxdeCsO5gp?=
 =?us-ascii?Q?w/mGh8TfhQM+BhVBwBkiXHdxrJNqFu3mq0kx28eUk//EGGkP0/WP+Y7Pq2ge?=
 =?us-ascii?Q?juWhhL8SGmo2BLUWdJZPHLh3NIxcrA84OYMeYxTgBX0hYTjTO5TQP0CbCTmW?=
 =?us-ascii?Q?bf4LoO0su2o5mvQ60j0AOEZvVgEDNcmSR9ywi6mJp2ZbJ7BtnNPOEznukGGG?=
 =?us-ascii?Q?kL8qye7rDTpbf+ZsCUHmEzyGoW0/A4VfbanRP9UWb70NSa+396GrOxVbztdI?=
 =?us-ascii?Q?Av7JuUtT4FMavr2pw6hdXiI6ry0Neu5RShlkfcf94tVuG1KcLstk8G4DZ6LL?=
 =?us-ascii?Q?JZekreDRt1Xu3e1joR+HuwRwTUNEvjYFPMeBHEyyEbO70mKOC34ALC6WbJFA?=
 =?us-ascii?Q?DfIVQ6+hI65vqP1xzeDB0/X3Sqp0MYw7tk0UNp3hgZ+EsUnzn+9MrWuFOnYu?=
 =?us-ascii?Q?XzFLf1ltXHYReEC+RZL6Rluruqv5zcsvsk2LPNZmBQWfXGqsnNYd9k1Wrl8J?=
 =?us-ascii?Q?l4I7qm3IuWZ2dfQk/AvHjn8N8HR6ppCClWS1?=
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)(376014)(82310400026)(14060799003)(1800799024)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 09:30:38.9917
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b09db62-edf5-4d92-90d8-08ddeeba5f8d
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:
	AM4PEPF00027A69.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8729

Reviewed-by: Yeoreum Yun 

On Mon, Sep 08, 2025 at 08:39:25AM +0100, Kevin Brodsky wrote:
> This function has only ever been used in arch/x86, so there is no
> need for other architectures to implement it. Remove it from
> linux/pgtable.h and all architectures besides x86.
>
> The arm64 implementation is not empty but it is only called from
> arch_leave_lazy_mmu_mode(), so we can simply fold it there.
>
> Acked-by: Mike Rapoport (Microsoft) 
> Signed-off-by: Kevin Brodsky 
> ---
>  arch/arm64/include/asm/pgtable.h                   | 9 +--------
>  arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 2 --
>  arch/sparc/include/asm/tlbflush_64.h               | 1 -
>  arch/x86/include/asm/pgtable.h                     | 3 ++-
>  include/linux/pgtable.h                            | 1 -
>  5 files changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index abd2dee416b3..728d7b6ed20a 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -101,21 +101,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
>  	set_thread_flag(TIF_LAZY_MMU);
>  }
>
> -static inline void arch_flush_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(void)
>  {
>  	if (in_interrupt())
>  		return;
>
>  	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
>  		emit_pte_barriers();
> -}
> -
> -static inline void arch_leave_lazy_mmu_mode(void)
> -{
> -	if (in_interrupt())
> -		return;
>
> -	arch_flush_lazy_mmu_mode();
>  	clear_thread_flag(TIF_LAZY_MMU);
>  }
>
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> index 146287d9580f..176d7fd79eeb 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> @@ -55,8 +55,6 @@ static inline void arch_leave_lazy_mmu_mode(void)
>  	preempt_enable();
>  }
>
> -#define arch_flush_lazy_mmu_mode()      do {} while (0)
> -
>  extern void hash__tlbiel_all(unsigned int action);
>
>  extern void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize,
> diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
> index 8b8cdaa69272..cd144eb31bdd 100644
> --- a/arch/sparc/include/asm/tlbflush_64.h
> +++ b/arch/sparc/include/asm/tlbflush_64.h
> @@ -44,7 +44,6 @@ 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)
>
>  /* Local cpu only.  */
>  void __flush_tlb_all(void);
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index e33df3da6980..14fd672bc9b2 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -117,7 +117,8 @@ extern pmdval_t early_pmd_flags;
>  #define pte_val(x)	native_pte_val(x)
>  #define __pte(x)	native_make_pte(x)
>
> -#define arch_end_context_switch(prev)	do {} while(0)
> +#define arch_end_context_switch(prev)	do {} while (0)
> +#define arch_flush_lazy_mmu_mode()	do {} while (0)
>  #endif	/* CONFIG_PARAVIRT_XXL */
>
>  static inline pmd_t pmd_set_flags(pmd_t pmd, pmdval_t set)
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 94249e671a7e..8d6007123cdf 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -234,7 +234,6 @@ static inline int pmd_dirty(pmd_t pmd)
>  #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)
>  #endif
>
>  #ifndef pte_batch_hint
> --
> 2.47.0
>

--
Sincerely,
Yeoreum Yun


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:31:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:31:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114904.1461701 (Exim 4.92)
	(envelope-from )
	id 1uvYDH-0005MD-4I; Mon, 08 Sep 2025 09:31:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114904.1461701; Mon, 08 Sep 2025 09: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 1uvYDH-0005M5-1T; Mon, 08 Sep 2025 09:31:03 +0000
Received: by outflank-mailman (input) for mailman id 1114904;
 Mon, 08 Sep 2025 09: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 1uvYDF-0005Ke-46
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:31:01 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 869eb4cf-8c96-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:30:58 +0200 (CEST)
Received: from DUZPR01CA0147.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4bd::29) by DU0PR08MB9028.eurprd08.prod.outlook.com
 (2603:10a6:10:474::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Mon, 8 Sep
 2025 09:30:53 +0000
Received: from DB5PEPF00014B9D.eurprd02.prod.outlook.com
 (2603:10a6:10:4bd:cafe::60) by DUZPR01CA0147.outlook.office365.com
 (2603:10a6:10:4bd::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 09:31:06 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB5PEPF00014B9D.mail.protection.outlook.com (10.167.8.164) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.13
 via Frontend Transport; Mon, 8 Sep 2025 09:30:52 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20) by PAWPR08MB10043.eurprd08.prod.outlook.com
 (2603:10a6:102:363::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 09:30:17 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739]) by GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739%7]) with mapi id 15.20.9094.018; Mon, 8 Sep 2025
 09:30: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: 869eb4cf-8c96-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=V4+y9aWBQR/UgO4zrl9iPaUVywcw0ABT9A4SrUh53QITKBCODBaQm1peW3whXuuNc3Kp+rHUu0QEkx58tPWjFRP29TnQI3snyH0oKNbNyReoeKTRLoSCP/OPEd8UpuyT5vk6jBzJoOqCLz2DttvuHfTTkj9zaJCcoNxxZy76jDJVARKJHwnx4xvb9TvvvIaYYhqhslAmlJ06WMMVZU28lImf/WgAjXB0XUnIaR+bW1DWcHuJZYsKWJDY0vbisZVdn7UkLpZqGGleEGKXHG5jKJn9q76vm4AzeHFYBKotEFQ7YvsBxJsKtnXh9r4aopZ6w6K865IXcFqacprvirKfRg==
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=DaYvtMCUc7HaNytTiGoaGdb5sm3gkswZa1sIoxK/VHs=;
 b=BDK4Qz0YNURXoeBFf2bQt3US3Vam/PVYZ1ztwhYr+A1MQ76z2wswcVBbcb8/udumFvX9OnW4tjCBIwIWfhzIqMXnO+SGv8lwLuHxE03+K9zX6AoW5KmK7h0nX5Ys0wk7RGS7tBo/wHAacEdRkrSqAop4adLaUpQGi61PxmeFReqsUBACLXEPQn9Xm9DIqOOjHN8Pq5JJkEQbKsl//1tiIDVRUVvU3f32fBObkRpXh2pw+ddw21yti/Q4qAUbyoqJDoemQ8rXH06bnWUZBKR4VuFeYoSZhQ2Bk2PCdMVy+WHMBwp1ve0QIh/XZt7KIEqMTGdZ+lBTUjzb5st3ELvqJw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kvack.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=DaYvtMCUc7HaNytTiGoaGdb5sm3gkswZa1sIoxK/VHs=;
 b=Wh23FTZVJTJ4PiEO4ZD8Jt1IpjCT20c5CCxFkFqV8CpQ/nQLoYh3wS4keuWcQvL6FigrK5lcNrmRcM5uK1iHtDWhSnW0XTy0y/SCNFGR/4F6sQ8SA6oLBuF6zdffQA6CFRaIiD+Zm+fnqrN38+LqmDP9hz78k3eBIYiF53lWyW8=
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=IRE4Yj+dIkZcWT9RHtrqQC56LFsJ+wa5D7SA0NFXB6Z2MDQIWbwxM3YNZexbN6GvBrGt8Cx/HBQP6MJDDrNZNpF9+ISE2OGIPalvh5qu78OZTx0phjFNFn+EQ34ARcA+om3M5Yz40BmiVvRbN//ty3Kw1Onvt88iog0sLOQ9zpy3/0kOK3RvP6bYVDjfkV87iCgoITftVyxTZjvl7AiSXRtf9L+1Z9/xD+a0N1pNvwOtVr+A0UyU+N/lvsxqz4uxTbzHdLtqdJsmleIh882oyuM2JwiyOysMMaiV0Eg8kTmvjvTV2Iq+a2fCmqkBH5H6SWmtjURSRqQTdvfojN9Nww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DaYvtMCUc7HaNytTiGoaGdb5sm3gkswZa1sIoxK/VHs=;
 b=w4g8PNMh29awP19Bf1kek5RX1p1y0joC4WASy+K0AS6SrQ48CbnzUtShUdrkjTi197q7pi8ieEOapGmYBQG9O49WCMRGOEEEzeCmtwyaTcWif6uL542lMAi7SfcHpoCD0k637eQC6hRtoZlWVvk+aRdSgRvWB1HoOhOiHYMdKfCdRvwbeEJDGSCX2BNA8KY4Tz/woG3OdzvHiMZGY4sMHiSIryhvg7rpCrCHt1PtkaZrW5TbONNH1D6oJAeuXlxFXH9DkleaZvJw6Cbk6aYK9nH8Cm+XeG6spr5MOgnS4l263cyeqN+zqOs5pHOXiQtRA77jxhTQaF15D0/wqT9JQA==
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=DaYvtMCUc7HaNytTiGoaGdb5sm3gkswZa1sIoxK/VHs=;
 b=Wh23FTZVJTJ4PiEO4ZD8Jt1IpjCT20c5CCxFkFqV8CpQ/nQLoYh3wS4keuWcQvL6FigrK5lcNrmRcM5uK1iHtDWhSnW0XTy0y/SCNFGR/4F6sQ8SA6oLBuF6zdffQA6CFRaIiD+Zm+fnqrN38+LqmDP9hz78k3eBIYiF53lWyW8=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Date: Mon, 8 Sep 2025 10:30:13 +0100
From: Yeoreum Yun 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250908073931.4159362-3-kevin.brodsky@arm.com>
X-ClientProxiedBy: LO4P123CA0290.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:196::7) To GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	GV1PR08MB10521:EE_|PAWPR08MB10043:EE_|DB5PEPF00014B9D:EE_|DU0PR08MB9028:EE_
X-MS-Office365-Filtering-Correlation-Id: f1176267-698c-40c2-a70a-08ddeeba6787
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|7416014|366016|1800799024;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?m12OBJz4DgyCQa2k6ZLmk+HJ2jLRYl61cXrmMEJu+WwUgZyevuVPBCh2gTtI?=
 =?us-ascii?Q?Ew1TZp+enB65S00uzuB2gHtKfVCcN04CDi3V+Swg/awrB+tIo9b0qOeXVcL3?=
 =?us-ascii?Q?pshYKcu52n/OQN3YPBplfwmVkGN/i66amgYGX1Q/ryLK3IApyphBoOsnSuWE?=
 =?us-ascii?Q?WBL9MfVyB8H6VErm8hSyQMdqbKE80XLbKgv083ZbNC3WGVAWxJGR8PZQnKws?=
 =?us-ascii?Q?IVCNd2HcEQ4hk1hlyY3+COc9gV9d471OH2GGNBGh0BwNSF5PQ40t5JJomhq3?=
 =?us-ascii?Q?L6wVVGGpwlUblnv4hS4e2Se2HfoKdhwDMCzfHnIPUZSjTg01E/n2APgsIDJ5?=
 =?us-ascii?Q?/5vKUdq+FzH/TcXUVbF1ySP+NWlMYn9fzDuzSLDROR/1b6SBSfm9dl3QBbYK?=
 =?us-ascii?Q?UWdgFcX5f4+SO0RDbNUxkxE+Oy+YmykpPxpk+FsOSMX6gk1hYiRCnieveKrW?=
 =?us-ascii?Q?9L8LL+OMJHjTyx8N7dAeX+7444V+l7/bh+yDe99Ai3Rz78uZ+DLsf5+P9Taa?=
 =?us-ascii?Q?KCfS6p8OrrHQpTkASFpa4C2J6LjYIp2WYrY85+GOse+VOt5xh5K9p250TSXH?=
 =?us-ascii?Q?3vAtWtLbsyq5BNmz7MqZPyNqND+eChI7K1ukx5viRpFT4w/jy7eMpeUek/9F?=
 =?us-ascii?Q?sHOp+tjyZfe8jXf49GQ1cj7q2VOgUuxAfopwYscjp0RPk5gs35p/gbkH4t1P?=
 =?us-ascii?Q?3CcUEuYJwpCU1FPwdF4jb/mCSV+OnP8q2S69PErr+Z2xEcoHE09PQyto49Lz?=
 =?us-ascii?Q?hNn2+ZpvmA96XfqflhDb8JWwQquEtHiLF+z08P/CLemSdbZMD1Sf5CNqy3G0?=
 =?us-ascii?Q?NKputRXvSvNvurwZs/8xEe4HfWmPM8/Vaw1fxZwDSYqR8YqL/qPE4RaFzf0R?=
 =?us-ascii?Q?eoEIx7XPAur+e5LRZAqk88YRWITZ2s6df5CYEmnWIh07lboW1ZvW/HvABGal?=
 =?us-ascii?Q?9Sos5aDyQ94aNjDC3/VfCOkGyHvx28VZzzXJLqTZCJPUkTjlBAmLat+HW6L5?=
 =?us-ascii?Q?+G/0ZkVlXQBYIBfk5P2o7m8tpQGXS23c6F0w6yDd42ETs03qGJBo0m27iaFQ?=
 =?us-ascii?Q?sjnam8KN/PC1Vd88jTiJR62PWN0MiRau9tfUXHmP34nDNU0Yh2+I4f25Xoq1?=
 =?us-ascii?Q?zlC1dM6707600CjkrB0tUmZhG80zqlzqB/1ij/4XcsgHNhMC1jwKsAYW7jpE?=
 =?us-ascii?Q?vTSwyqL0UXbk+/CwLQ64mN73cYxUOh/BzlE45KRD4i5KL0OQ7ILjPg6kR0Yc?=
 =?us-ascii?Q?8fy83rqlnV/O13JM0XmZd72/W/v9vI7gAVg45WeMXvoxFHFVsFBCfMUVPquE?=
 =?us-ascii?Q?tqnuRmsyeYKFRE+5r8JX2/jx6QtaCVqUxqGiw6ovJaPJxe+agpi8RNpcIRAW?=
 =?us-ascii?Q?KfmA3OIgi8ctpmeMXDbKx0MMzZR4rqL9sWsZKfpwcGW02kX37FVmRPGex8Bm?=
 =?us-ascii?Q?J2LEJqgx12U=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR08MB10521.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10043
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B9D.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	d15ea810-a166-446a-3d72-08ddeeba5284
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|36860700013|1800799024|14060799003|35042699022|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?7GhoUjxOZ1KvT67RUa7dMl4fEObc4B6Xj5OyXxXvbToeauikOOG3DZEPN1Ls?=
 =?us-ascii?Q?si6vE635w5I97yHyAhgBBKdLVrj2fAMFZmFjpIoiVJPki5opEc00kvDJBblZ?=
 =?us-ascii?Q?ORDr8m7YP9zaaDrkX4nWlH26MX9IuJR69X/JmdmghwxbxiBSx9f+JdBzRf5y?=
 =?us-ascii?Q?W6XFcQRkIirPijIvCY8Y6dBsRlKGNbarQe/eBREc+BEX4aUCOnbJH6xZufH9?=
 =?us-ascii?Q?OZKXXtuN9BlhKspULvD/N7AfRZpIuH189eycWxamnAaS/2Cr7YG3aRo4h+ws?=
 =?us-ascii?Q?DVNxFo1qRjSOe7opOgP3BSazZocDCcUJuzHQP4Kp1sBaGDaeeuzs4hD+VNNw?=
 =?us-ascii?Q?weo2R5BfrcxxMFuxs+mqCsjyjSMzSN4fQAIyNPJHiujpKh1Yz4UX762m7j1N?=
 =?us-ascii?Q?5Q1gxofYIQcBKkdaQ0ZcngJezsb95FThh2xbRmVWqiU9yIXdn/8fAdFmxDRO?=
 =?us-ascii?Q?t15J/eSQCbDAX6xPxKfKrI8ofKaYD5MBnjVI/ijhnRGaAJoQ+qSEJzdACF2r?=
 =?us-ascii?Q?BOlPLwvOsLOShROGxvtsxNFLK6qaUZwGb770xMxSeasSVicvC6GrANiFiasX?=
 =?us-ascii?Q?KlxNf8r9fm3QRf10RdK0lalKi6k8nW37SySsdfNInwYRCLU3QqD7RmnDohYm?=
 =?us-ascii?Q?gDwJmisGPleh8qU5mhGN8w22aeTaalJ6+TFZAc22YUeJx20br5VS1MVU6/je?=
 =?us-ascii?Q?YrG23FJKf87rhSq0D0gqD3SC+qrdkLZi3DWa++sRczmY0OkfUWjM6lJfXVez?=
 =?us-ascii?Q?GrFxycqACOkJhUYorCn5OpsWM0aXgULjj7e7IgnWRMtChK61X4zN7x15UznW?=
 =?us-ascii?Q?zSc32nxUGCkUBGxcVmeI40BRrf807d0VbL4Z5RfBo7gmaznz/hjrVb8bypJS?=
 =?us-ascii?Q?tJRJARgvNnZKn8TkGq3p8yrDP86kzbojP02OcDN/VlQV3Wy2Ou3+vaPJ023I?=
 =?us-ascii?Q?HqiNQH3PsP2KS7OwVC/Je3JNs8+pfffPe3sTX0uscZfMsm6lHNeqNYT+MLw9?=
 =?us-ascii?Q?YVabD/oTpUvJuvmrwKLjgW9A69TFSyTbjfW/hNSkyQZZ/wN+Xm5NVBKTIhBu?=
 =?us-ascii?Q?o/uH/x21ZP/ew+dkR6q3Gt/sCi+xAmdMBOt0YMwijx0h8pD+euTyV0PGj1gW?=
 =?us-ascii?Q?2BmKtkgHeMNQYFPQJJv8Ol2gCyCFjkZcLFLkB6FACz4xTA7l2DBiqhvCb9Pd?=
 =?us-ascii?Q?Kr5d9ZZV5Y2w+7KO8x/oLaNncUZV29+HmZXwZJRSIXTfYrDPa4mkintDVR0s?=
 =?us-ascii?Q?ATyNapr8HYnvP1S3+40GbxuCiq7NnaVAzUV21KPEmA44oQ9isVDWkLJvt/gh?=
 =?us-ascii?Q?OATi4g46rdVIaPTSOby4c4GiWKA1KZBO4mP21IWge8c2sPICDUeKz/uTQ23H?=
 =?us-ascii?Q?VAc8XJN+raf1yYL1Hocp33zY4p4WezF55C2F/rNJhjaZvufY5m2V7fwgXhPz?=
 =?us-ascii?Q?2Q5PGh9c4VUsO88lHiYkPvTMQnh32DsMYSuNMdShEHDPCEUgBOMHZw5YddW0?=
 =?us-ascii?Q?8QzLEHcbxf/U/Ws4ZYeuzXF+rUsobf1HoZxX?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700013)(1800799024)(14060799003)(35042699022)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 09:30:52.3665
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f1176267-698c-40c2-a70a-08ddeeba6787
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:
	DB5PEPF00014B9D.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9028

Reviewed-by: Yeoreum Yun 

On Mon, Sep 08, 2025 at 08:39:26AM +0100, Kevin Brodsky wrote:
> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> (taking and returning no value). This is proving problematic in
> situations where leave() needs to restore some context back to its
> original state (before enter() was called). In particular, this
> makes it difficult to support the nesting of lazy_mmu sections -
> leave() does not know whether the matching enter() call occurred
> while lazy_mmu was already enabled, and whether to disable it or
> not.
>
> This patch gives all architectures the chance to store local state
> while inside a lazy_mmu section by making enter() return some value,
> storing it in a local variable, and having leave() take that value.
> That value is typed lazy_mmu_state_t - each architecture defining
> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> For now we define it as int everywhere, which is sufficient to
> support nesting.
>
> The diff is unfortunately rather large as all the API changes need
> to be done atomically. Main parts:
>
> * Changing the prototypes of arch_{enter,leave}_lazy_mmu_mode()
>   in generic and arch code, and introducing lazy_mmu_state_t.
>
> * Introducing LAZY_MMU_{DEFAULT,NESTED} for future support of
>   nesting. enter() always returns LAZY_MMU_DEFAULT for now.
>   (linux/mm_types.h is not the most natural location for defining
>   those constants, but there is no other obvious header that is
>   accessible where arch's implement the helpers.)
>
> * Changing all lazy_mmu sections to introduce a lazy_mmu_state
>   local variable, having enter() set it and leave() take it. Most of
>   these changes were generated using the following Coccinelle script:
>
> @@
> @@
> {
> + lazy_mmu_state_t lazy_mmu_state;
> ...
> - arch_enter_lazy_mmu_mode();
> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> ...
> - arch_leave_lazy_mmu_mode();
> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> ...
> }
>
> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
>   lazy_mmu is already enabled, and it temporarily disables it by
>   calling leave() and then enter() again. Here we want to ensure
>   that any operation between the leave() and enter() calls is
>   completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
>   leave() to fully disable lazy_mmu. enter() will then re-enable it
>   - this achieves the expected behaviour, whether nesting occurred
>   before that function was called or not.
>
> Note: it is difficult to provide a default definition of
> lazy_mmu_state_t for architectures implementing lazy_mmu, because
> that definition would need to be available in
> arch/x86/include/asm/paravirt_types.h and adding a new generic
>  #include there is very tricky due to the existing header soup.
>
> Acked-by: Mike Rapoport (Microsoft) 
> Signed-off-by: Kevin Brodsky 
> ---
>  arch/arm64/include/asm/pgtable.h              | 10 +++++++---
>  .../include/asm/book3s/64/tlbflush-hash.h     |  9 ++++++---
>  arch/powerpc/mm/book3s64/hash_tlb.c           | 10 ++++++----
>  arch/powerpc/mm/book3s64/subpage_prot.c       |  5 +++--
>  arch/sparc/include/asm/tlbflush_64.h          |  5 +++--
>  arch/sparc/mm/tlb.c                           |  6 ++++--
>  arch/x86/include/asm/paravirt.h               |  6 ++++--
>  arch/x86/include/asm/paravirt_types.h         |  2 ++
>  arch/x86/xen/enlighten_pv.c                   |  2 +-
>  arch/x86/xen/mmu_pv.c                         |  2 +-
>  fs/proc/task_mmu.c                            |  5 +++--
>  include/linux/mm_types.h                      |  3 +++
>  include/linux/pgtable.h                       |  6 ++++--
>  mm/kasan/shadow.c                             |  4 ++--
>  mm/madvise.c                                  | 20 ++++++++++---------
>  mm/memory.c                                   | 20 +++++++++++--------
>  mm/migrate_device.c                           |  5 +++--
>  mm/mprotect.c                                 |  5 +++--
>  mm/mremap.c                                   |  5 +++--
>  mm/userfaultfd.c                              |  5 +++--
>  mm/vmalloc.c                                  | 15 ++++++++------
>  mm/vmscan.c                                   | 15 ++++++++------
>  22 files changed, 102 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 728d7b6ed20a..816197d08165 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -81,7 +81,9 @@ static inline void queue_pte_barriers(void)
>  }
>
>  #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> -static inline void arch_enter_lazy_mmu_mode(void)
> +typedef int lazy_mmu_state_t;
> +
> +static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	/*
>  	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
> @@ -96,12 +98,14 @@ static inline void arch_enter_lazy_mmu_mode(void)
>  	 */
>
>  	if (in_interrupt())
> -		return;
> +		return LAZY_MMU_DEFAULT;
>
>  	set_thread_flag(TIF_LAZY_MMU);
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -static inline void arch_leave_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	if (in_interrupt())
>  		return;
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> index 176d7fd79eeb..c9f1e819e567 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
> @@ -25,13 +25,14 @@ DECLARE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
>  extern void __flush_tlb_pending(struct ppc64_tlb_batch *batch);
>
>  #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> +typedef int lazy_mmu_state_t;
>
> -static inline void arch_enter_lazy_mmu_mode(void)
> +static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	struct ppc64_tlb_batch *batch;
>
>  	if (radix_enabled())
> -		return;
> +		return LAZY_MMU_DEFAULT;
>  	/*
>  	 * apply_to_page_range can call us this preempt enabled when
>  	 * operating on kernel page tables.
> @@ -39,9 +40,11 @@ static inline void arch_enter_lazy_mmu_mode(void)
>  	preempt_disable();
>  	batch = this_cpu_ptr(&ppc64_tlb_batch);
>  	batch->active = 1;
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -static inline void arch_leave_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	struct ppc64_tlb_batch *batch;
>
> diff --git a/arch/powerpc/mm/book3s64/hash_tlb.c b/arch/powerpc/mm/book3s64/hash_tlb.c
> index 21fcad97ae80..ee664f88e679 100644
> --- a/arch/powerpc/mm/book3s64/hash_tlb.c
> +++ b/arch/powerpc/mm/book3s64/hash_tlb.c
> @@ -189,6 +189,7 @@ void hash__tlb_flush(struct mmu_gather *tlb)
>   */
>  void __flush_hash_table_range(unsigned long start, unsigned long end)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int hugepage_shift;
>  	unsigned long flags;
>
> @@ -205,7 +206,7 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
>  	 * way to do things but is fine for our needs here.
>  	 */
>  	local_irq_save(flags);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; start < end; start += PAGE_SIZE) {
>  		pte_t *ptep = find_init_mm_pte(start, &hugepage_shift);
>  		unsigned long pte;
> @@ -217,12 +218,13 @@ void __flush_hash_table_range(unsigned long start, unsigned long end)
>  			continue;
>  		hpte_need_flush(&init_mm, start, ptep, pte, hugepage_shift);
>  	}
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	local_irq_restore(flags);
>  }
>
>  void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte;
>  	pte_t *start_pte;
>  	unsigned long flags;
> @@ -237,7 +239,7 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
>  	 * way to do things but is fine for our needs here.
>  	 */
>  	local_irq_save(flags);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	start_pte = pte_offset_map(pmd, addr);
>  	if (!start_pte)
>  		goto out;
> @@ -249,6 +251,6 @@ void flush_hash_table_pmd_range(struct mm_struct *mm, pmd_t *pmd, unsigned long
>  	}
>  	pte_unmap(start_pte);
>  out:
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	local_irq_restore(flags);
>  }
> diff --git a/arch/powerpc/mm/book3s64/subpage_prot.c b/arch/powerpc/mm/book3s64/subpage_prot.c
> index ec98e526167e..4720f9f321af 100644
> --- a/arch/powerpc/mm/book3s64/subpage_prot.c
> +++ b/arch/powerpc/mm/book3s64/subpage_prot.c
> @@ -53,6 +53,7 @@ void subpage_prot_free(struct mm_struct *mm)
>  static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
>  			     int npages)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pgd_t *pgd;
>  	p4d_t *p4d;
>  	pud_t *pud;
> @@ -73,13 +74,13 @@ static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
>  	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
>  	if (!pte)
>  		return;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; npages > 0; --npages) {
>  		pte_update(mm, addr, pte, 0, 0, 0);
>  		addr += PAGE_SIZE;
>  		++pte;
>  	}
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(pte - 1, ptl);
>  }
>
> diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
> index cd144eb31bdd..02c93a4e6af5 100644
> --- a/arch/sparc/include/asm/tlbflush_64.h
> +++ b/arch/sparc/include/asm/tlbflush_64.h
> @@ -40,10 +40,11 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
>  void flush_tlb_kernel_range(unsigned long start, unsigned long end);
>
>  #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> +typedef int lazy_mmu_state_t;
>
>  void flush_tlb_pending(void);
> -void arch_enter_lazy_mmu_mode(void);
> -void arch_leave_lazy_mmu_mode(void);
> +lazy_mmu_state_t arch_enter_lazy_mmu_mode(void);
> +void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state);
>
>  /* Local cpu only.  */
>  void __flush_tlb_all(void);
> diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
> index a35ddcca5e76..bf5094b770af 100644
> --- a/arch/sparc/mm/tlb.c
> +++ b/arch/sparc/mm/tlb.c
> @@ -50,16 +50,18 @@ void flush_tlb_pending(void)
>  	put_cpu_var(tlb_batch);
>  }
>
> -void arch_enter_lazy_mmu_mode(void)
> +lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	struct tlb_batch *tb;
>
>  	preempt_disable();
>  	tb = this_cpu_ptr(&tlb_batch);
>  	tb->active = 1;
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -void arch_leave_lazy_mmu_mode(void)
> +void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
>
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index b5e59a7ba0d0..65a0d394fba1 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -527,12 +527,14 @@ static inline void arch_end_context_switch(struct task_struct *next)
>  }
>
>  #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
> -static inline void arch_enter_lazy_mmu_mode(void)
> +static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
>  	PVOP_VCALL0(mmu.lazy_mode.enter);
> +
> +	return LAZY_MMU_DEFAULT;
>  }
>
> -static inline void arch_leave_lazy_mmu_mode(void)
> +static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  {
>  	PVOP_VCALL0(mmu.lazy_mode.leave);
>  }
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 37a8627d8277..bc1af86868a3 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -41,6 +41,8 @@ struct pv_info {
>  };
>
>  #ifdef CONFIG_PARAVIRT_XXL
> +typedef int lazy_mmu_state_t;
> +
>  struct pv_lazy_ops {
>  	/* Set deferred update mode, used for batching operations. */
>  	void (*enter)(void);
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 26bbaf4b7330..a245ba47a631 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -426,7 +426,7 @@ static void xen_start_context_switch(struct task_struct *prev)
>  	BUG_ON(preemptible());
>
>  	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
>  		set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES);
>  	}
>  	enter_lazy(XEN_LAZY_CPU);
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 2a4a8deaf612..2039d5132ca3 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2140,7 +2140,7 @@ static void xen_flush_lazy_mmu(void)
>  	preempt_disable();
>
>  	if (xen_get_lazy_mode() == XEN_LAZY_MMU) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
>  		arch_enter_lazy_mmu_mode();
>  	}
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index ced01cf3c5ab..02aa55f83bae 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -2682,6 +2682,7 @@ static int pagemap_scan_thp_entry(pmd_t *pmd, unsigned long start,
>  static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  				  unsigned long end, struct mm_walk *walk)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct pagemap_scan_private *p = walk->private;
>  	struct vm_area_struct *vma = walk->vma;
>  	unsigned long addr, flush_end = 0;
> @@ -2700,7 +2701,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  		return 0;
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	if ((p->arg.flags & PM_SCAN_WP_MATCHING) && !p->vec_out) {
>  		/* Fast path for performing exclusive WP */
> @@ -2770,7 +2771,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>  	if (flush_end)
>  		flush_tlb_range(vma, start, addr);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(start_pte, ptl);
>
>  	cond_resched();
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 275e8060d918..143d819c1386 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1489,6 +1489,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm);
>  extern void tlb_gather_mmu_fullmm(struct mmu_gather *tlb, struct mm_struct *mm);
>  extern void tlb_finish_mmu(struct mmu_gather *tlb);
>
> +#define LAZY_MMU_DEFAULT	0
> +#define LAZY_MMU_NESTED		1
> +
>  struct vm_fault;
>
>  /**
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8d6007123cdf..df0eb898b3fc 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -232,8 +232,10 @@ static inline int pmd_dirty(pmd_t pmd)
>   * 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)
> +typedef int lazy_mmu_state_t;
> +
> +#define arch_enter_lazy_mmu_mode()	(LAZY_MMU_DEFAULT)
> +#define arch_leave_lazy_mmu_mode(state)	((void)(state))
>  #endif
>
>  #ifndef pte_batch_hint
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index 5d2a876035d6..60b1b72f5ce1 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -305,7 +305,7 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>  	pte_t pte;
>  	int index;
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
>
>  	index = PFN_DOWN(addr - data->start);
>  	page = data->pages[index];
> @@ -482,7 +482,7 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>  	pte_t pte;
>  	int none;
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(LAZY_MMU_DEFAULT);
>
>  	spin_lock(&init_mm.page_table_lock);
>  	pte = ptep_get(ptep);
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 35ed4ab0d7c5..72c032f2cf56 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -357,6 +357,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  				unsigned long addr, unsigned long end,
>  				struct mm_walk *walk)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct madvise_walk_private *private = walk->private;
>  	struct mmu_gather *tlb = private->tlb;
>  	bool pageout = private->pageout;
> @@ -455,7 +456,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  	if (!start_pte)
>  		return 0;
>  	flush_tlb_batched_pending(mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
>  		nr = 1;
>  		ptent = ptep_get(pte);
> @@ -463,7 +464,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  		if (++batch_count == SWAP_CLUSTER_MAX) {
>  			batch_count = 0;
>  			if (need_resched()) {
> -				arch_leave_lazy_mmu_mode();
> +				arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  				pte_unmap_unlock(start_pte, ptl);
>  				cond_resched();
>  				goto restart;
> @@ -499,7 +500,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  				if (!folio_trylock(folio))
>  					continue;
>  				folio_get(folio);
> -				arch_leave_lazy_mmu_mode();
> +				arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  				pte_unmap_unlock(start_pte, ptl);
>  				start_pte = NULL;
>  				err = split_folio(folio);
> @@ -510,7 +511,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  				if (!start_pte)
>  					break;
>  				flush_tlb_batched_pending(mm);
> -				arch_enter_lazy_mmu_mode();
> +				lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  				if (!err)
>  					nr = 0;
>  				continue;
> @@ -558,7 +559,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  	}
>
>  	if (start_pte) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  		pte_unmap_unlock(start_pte, ptl);
>  	}
>  	if (pageout)
> @@ -657,6 +658,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>
>  {
>  	const cydp_t cydp_flags = CYDP_CLEAR_YOUNG | CYDP_CLEAR_DIRTY;
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct mmu_gather *tlb = walk->private;
>  	struct mm_struct *mm = tlb->mm;
>  	struct vm_area_struct *vma = walk->vma;
> @@ -677,7 +679,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (!start_pte)
>  		return 0;
>  	flush_tlb_batched_pending(mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	for (; addr != end; pte += nr, addr += PAGE_SIZE * nr) {
>  		nr = 1;
>  		ptent = ptep_get(pte);
> @@ -727,7 +729,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  				if (!folio_trylock(folio))
>  					continue;
>  				folio_get(folio);
> -				arch_leave_lazy_mmu_mode();
> +				arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  				pte_unmap_unlock(start_pte, ptl);
>  				start_pte = NULL;
>  				err = split_folio(folio);
> @@ -738,7 +740,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  				if (!start_pte)
>  					break;
>  				flush_tlb_batched_pending(mm);
> -				arch_enter_lazy_mmu_mode();
> +				lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  				if (!err)
>  					nr = 0;
>  				continue;
> @@ -778,7 +780,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (nr_swap)
>  		add_mm_counter(mm, MM_SWAPENTS, nr_swap);
>  	if (start_pte) {
> -		arch_leave_lazy_mmu_mode();
> +		arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  		pte_unmap_unlock(start_pte, ptl);
>  	}
>  	cond_resched();
> diff --git a/mm/memory.c b/mm/memory.c
> index d9de6c056179..a60aae069f1e 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1207,6 +1207,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	       pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
>  	       unsigned long end)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct mm_struct *dst_mm = dst_vma->vm_mm;
>  	struct mm_struct *src_mm = src_vma->vm_mm;
>  	pte_t *orig_src_pte, *orig_dst_pte;
> @@ -1254,7 +1255,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
>  	orig_src_pte = src_pte;
>  	orig_dst_pte = dst_pte;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		nr = 1;
> @@ -1323,7 +1324,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	} while (dst_pte += nr, src_pte += nr, addr += PAGE_SIZE * nr,
>  		 addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(orig_src_pte, src_ptl);
>  	add_mm_rss_vec(dst_mm, rss);
>  	pte_unmap_unlock(orig_dst_pte, dst_ptl);
> @@ -1822,6 +1823,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  				unsigned long addr, unsigned long end,
>  				struct zap_details *details)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	bool force_flush = false, force_break = false;
>  	struct mm_struct *mm = tlb->mm;
>  	int rss[NR_MM_COUNTERS];
> @@ -1842,7 +1844,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  		return addr;
>
>  	flush_tlb_batched_pending(mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	do {
>  		bool any_skipped = false;
>
> @@ -1874,7 +1876,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  		direct_reclaim = try_get_and_clear_pmd(mm, pmd, &pmdval);
>
>  	add_mm_rss_vec(mm, rss);
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>
>  	/* Do the actual TLB flush before dropping ptl */
>  	if (force_flush) {
> @@ -2811,6 +2813,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			unsigned long addr, unsigned long end,
>  			unsigned long pfn, pgprot_t prot)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte, *mapped_pte;
>  	spinlock_t *ptl;
>  	int err = 0;
> @@ -2818,7 +2821,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
>  	if (!pte)
>  		return -ENOMEM;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	do {
>  		BUG_ON(!pte_none(ptep_get(pte)));
>  		if (!pfn_modify_allowed(pfn, prot)) {
> @@ -2828,7 +2831,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  		set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
>  		pfn++;
>  	} while (pte++, addr += PAGE_SIZE, addr != end);
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(mapped_pte, ptl);
>  	return err;
>  }
> @@ -3117,6 +3120,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  				     pte_fn_t fn, void *data, bool create,
>  				     pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte, *mapped_pte;
>  	int err = 0;
>  	spinlock_t *ptl;
> @@ -3135,7 +3139,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			return -EINVAL;
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	if (fn) {
>  		do {
> @@ -3148,7 +3152,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	}
>  	*mask |= PGTBL_PTE_MODIFIED;
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>
>  	if (mm != &init_mm)
>  		pte_unmap_unlock(mapped_pte, ptl);
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index abd9f6850db6..833ce5eafa40 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -59,6 +59,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>  				   unsigned long end,
>  				   struct mm_walk *walk)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct migrate_vma *migrate = walk->private;
>  	struct folio *fault_folio = migrate->fault_page ?
>  		page_folio(migrate->fault_page) : NULL;
> @@ -110,7 +111,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>  	ptep = pte_offset_map_lock(mm, pmdp, addr, &ptl);
>  	if (!ptep)
>  		goto again;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	for (; addr < end; addr += PAGE_SIZE, ptep++) {
>  		struct dev_pagemap *pgmap;
> @@ -287,7 +288,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>  	if (unmapped)
>  		flush_tlb_range(walk->vma, start, end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(ptep - 1, ptl);
>
>  	return 0;
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 113b48985834..7bba651e5aa3 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -273,6 +273,7 @@ static long change_pte_range(struct mmu_gather *tlb,
>  		struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr,
>  		unsigned long end, pgprot_t newprot, unsigned long cp_flags)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte, oldpte;
>  	spinlock_t *ptl;
>  	long pages = 0;
> @@ -293,7 +294,7 @@ static long change_pte_range(struct mmu_gather *tlb,
>  		target_node = numa_node_id();
>
>  	flush_tlb_batched_pending(vma->vm_mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  	do {
>  		nr_ptes = 1;
>  		oldpte = ptep_get(pte);
> @@ -439,7 +440,7 @@ static long change_pte_range(struct mmu_gather *tlb,
>  			}
>  		}
>  	} while (pte += nr_ptes, addr += nr_ptes * PAGE_SIZE, addr != end);
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(pte - 1, ptl);
>
>  	return pages;
> diff --git a/mm/mremap.c b/mm/mremap.c
> index 35de0a7b910e..a562d8cf1eee 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -193,6 +193,7 @@ static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr
>  static int move_ptes(struct pagetable_move_control *pmc,
>  		unsigned long extent, pmd_t *old_pmd, pmd_t *new_pmd)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	struct vm_area_struct *vma = pmc->old;
>  	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
>  	struct mm_struct *mm = vma->vm_mm;
> @@ -256,7 +257,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
>  	if (new_ptl != old_ptl)
>  		spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
>  	flush_tlb_batched_pending(vma->vm_mm);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	for (; old_addr < old_end; old_ptep += nr_ptes, old_addr += nr_ptes * PAGE_SIZE,
>  		new_ptep += nr_ptes, new_addr += nr_ptes * PAGE_SIZE) {
> @@ -301,7 +302,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
>  		}
>  	}
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	if (force_flush)
>  		flush_tlb_range(vma, old_end - len, old_end);
>  	if (new_ptl != old_ptl)
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index 50aaa8dcd24c..6ee71ba68b12 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -1076,6 +1076,7 @@ static long move_present_ptes(struct mm_struct *mm,
>  			      struct folio **first_src_folio, unsigned long len,
>  			      struct anon_vma *src_anon_vma)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int err = 0;
>  	struct folio *src_folio = *first_src_folio;
>  	unsigned long src_start = src_addr;
> @@ -1100,7 +1101,7 @@ static long move_present_ptes(struct mm_struct *mm,
>  	/* It's safe to drop the reference now as the page-table is holding one. */
>  	folio_put(*first_src_folio);
>  	*first_src_folio = NULL;
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	while (true) {
>  		orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte);
> @@ -1138,7 +1139,7 @@ static long move_present_ptes(struct mm_struct *mm,
>  			break;
>  	}
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	if (src_addr > src_start)
>  		flush_tlb_range(src_vma, src_start, src_addr);
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 4249e1e01947..9fc86ddf1711 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -95,6 +95,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  			phys_addr_t phys_addr, pgprot_t prot,
>  			unsigned int max_page_shift, pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte;
>  	u64 pfn;
>  	struct page *page;
> @@ -105,7 +106,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	if (!pte)
>  		return -ENOMEM;
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		if (unlikely(!pte_none(ptep_get(pte)))) {
> @@ -131,7 +132,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  		pfn++;
>  	} while (pte += PFN_DOWN(size), addr += size, addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  	return 0;
>  }
> @@ -354,12 +355,13 @@ int ioremap_page_range(unsigned long addr, unsigned long end,
>  static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  			     pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	pte_t *pte;
>  	pte_t ptent;
>  	unsigned long size = PAGE_SIZE;
>
>  	pte = pte_offset_kernel(pmd, addr);
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  #ifdef CONFIG_HUGETLB_PAGE
> @@ -378,7 +380,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  		WARN_ON(!pte_none(ptent) && !pte_present(ptent));
>  	} while (pte += (size >> PAGE_SHIFT), addr += size, addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  }
>
> @@ -514,6 +516,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  		unsigned long end, pgprot_t prot, struct page **pages, int *nr,
>  		pgtbl_mod_mask *mask)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int err = 0;
>  	pte_t *pte;
>
> @@ -526,7 +529,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (!pte)
>  		return -ENOMEM;
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		struct page *page = pages[*nr];
> @@ -548,7 +551,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  		(*nr)++;
>  	} while (pte++, addr += PAGE_SIZE, addr != end);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	*mask |= PGTBL_PTE_MODIFIED;
>
>  	return err;
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index ca9e1cd3cd68..2872497a0453 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3514,6 +3514,7 @@ static void walk_update_folio(struct lru_gen_mm_walk *walk, struct folio *folio,
>  static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  			   struct mm_walk *args)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int i;
>  	bool dirty;
>  	pte_t *pte;
> @@ -3543,7 +3544,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  		return false;
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>  restart:
>  	for (i = pte_index(start), addr = start; addr != end; i++, addr += PAGE_SIZE) {
>  		unsigned long pfn;
> @@ -3584,7 +3585,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  	if (i < PTRS_PER_PTE && get_next_vma(PMD_MASK, PAGE_SIZE, args, &start, &end))
>  		goto restart;
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	pte_unmap_unlock(pte, ptl);
>
>  	return suitable_to_scan(total, young);
> @@ -3593,6 +3594,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
>  static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area_struct *vma,
>  				  struct mm_walk *args, unsigned long *bitmap, unsigned long *first)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int i;
>  	bool dirty;
>  	pmd_t *pmd;
> @@ -3625,7 +3627,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
>  	if (!spin_trylock(ptl))
>  		goto done;
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	do {
>  		unsigned long pfn;
> @@ -3672,7 +3674,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area
>
>  	walk_update_folio(walk, last, gen, dirty);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>  	spin_unlock(ptl);
>  done:
>  	*first = -1;
> @@ -4220,6 +4222,7 @@ static void lru_gen_age_node(struct pglist_data *pgdat, struct scan_control *sc)
>   */
>  bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
>  {
> +	lazy_mmu_state_t lazy_mmu_state;
>  	int i;
>  	bool dirty;
>  	unsigned long start;
> @@ -4271,7 +4274,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
>  		}
>  	}
>
> -	arch_enter_lazy_mmu_mode();
> +	lazy_mmu_state = arch_enter_lazy_mmu_mode();
>
>  	pte -= (addr - start) / PAGE_SIZE;
>
> @@ -4305,7 +4308,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
>
>  	walk_update_folio(walk, last, gen, dirty);
>
> -	arch_leave_lazy_mmu_mode();
> +	arch_leave_lazy_mmu_mode(lazy_mmu_state);
>
>  	/* feedback from rmap walkers to page table walkers */
>  	if (mm_state && suitable_to_scan(i, young))
> --
> 2.47.0
>

--
Sincerely,
Yeoreum Yun


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:31:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:31:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114907.1461711 (Exim 4.92)
	(envelope-from )
	id 1uvYDT-0005mw-FB; Mon, 08 Sep 2025 09:31:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114907.1461711; Mon, 08 Sep 2025 09:31: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 1uvYDT-0005mo-CL; Mon, 08 Sep 2025 09:31:15 +0000
Received: by outflank-mailman (input) for mailman id 1114907;
 Mon, 08 Sep 2025 09:31: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 1uvYDR-0005Ke-BQ
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:31:13 +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 8f2bd52e-8c96-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:31:12 +0200 (CEST)
Received: from AM0PR10CA0019.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::29)
 by DB9PR08MB7771.eurprd08.prod.outlook.com (2603:10a6:10:397::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.17; Mon, 8 Sep
 2025 09:31:08 +0000
Received: from AM4PEPF00027A5F.eurprd04.prod.outlook.com
 (2603:10a6:208:17c:cafe::cf) by AM0PR10CA0019.outlook.office365.com
 (2603:10a6:208:17c::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 09:31:08 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A5F.mail.protection.outlook.com (10.167.16.74) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.13
 via Frontend Transport; Mon, 8 Sep 2025 09:31:06 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20) by DB5PR08MB10163.eurprd08.prod.outlook.com
 (2603:10a6:10:4a2::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 09:30:33 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739]) by GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739%7]) with mapi id 15.20.9094.018; Mon, 8 Sep 2025
 09: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: 8f2bd52e-8c96-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=PhoHYCGu+IVt8ylPivj9rNzrNKAGhdqmTANALmKCXAVAZXVGUgbubEQXajlethE5pwoC2QC3LNhqbVIud7rBskTWNQ8GCMuBgQMogo1PnO2o39bhp+3wRCfcpmmYi9MgYPEqOmQ6AIbyeE9DGkWZeTm7YYn/1IMHr0FTglczLvpgQTbYlqCV5Bs6jZMn4sE+6mss3YV7R+R86AMnoUXtx4tufCwvN1Jp/m06zrP3FIIf3BABT4GSiBCMk+5JSv1n+BxTIz5OgDsv4dY3ezqohxAdm5hRxMSXTHgj4mGZ0BifwCONBfi1sNRTr6/IjOrM1C1DyBHgHf9u2nxSBKV2Qw==
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=MKTinqRY9lAauBy2OZ6xKaVx1KArO4xGTgKQBxwBbBU=;
 b=n8Eme9DMXzXHq+v6jprIkWaToz4ew0hGv4IOG/L9Z66Zp++jakaqXCM78jVq1M41wS8Ff0jKB4Vm5tEMg9MAg4ao45ex16wmWWGPlCFPMlvcE1R3DIM2AUhXBuDVqeJBvqBSQFnPM2QOTzdkgA8Y+K4s464Ybx0vDrUKua5aLigSdgr4xcxdSfyZ6HEL7StX72e0SpyvPOD7bXuNY8YRLkm3LVHu6Oaao87IWXvRyou/gOfMPGbUfYwV19fPiLEYBRPxVLxiThb+1AHyvbakpB/DV5K9UvBurus/F3rZAOrBauMvmvl6c49M5p3T+Snuol1pK6PBRBvqJgb8eU37HQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kvack.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=MKTinqRY9lAauBy2OZ6xKaVx1KArO4xGTgKQBxwBbBU=;
 b=UlEu1qeTuLU99L0jDNP9Tj9KGou1+VjTpBZ14XV7wc0hQ7Hr9YwF0HHwVcUMfqIS6RqJagjaT1uQ38oVyGg0vn8ctXolBclT261k3QVEJO9QhlqL04PlfFV4BB/XWIaZMisk2GkyXBtn3fmN4zH/exk7RUJ3FovG0GWOzPXK2K0=
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=JD6aR2JTcCSzlmcmkxP0JuYyrJKOmFes4KgPYG9jU+TtHX+5KZLWOXvcYFCNYPAjprpslWYb17vHW0JHSgx6nbEl/Tg0ar3ccarocg5ScFpyGajStJifvlClUHYRdxod2aqsmdzVGhUpzk65y6OFpXwXwPM8OpGUJIaLPdWNxpgDQbn7YBWOTWv7wVFUCLM2XvAkV3DZ2Fpbze8srmJ1gGrBjec7opGhkDjij5oLDc4QxvvSSRECmz9GLiLjFBd7TdhZfr97NDnYBXmGcjB5V9UVtedqKAjbi6km/qSjpPH3tIZx2BwTAqIsQChZneYDIDumL4pJ4ahmHNQK6ariRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MKTinqRY9lAauBy2OZ6xKaVx1KArO4xGTgKQBxwBbBU=;
 b=AV1nazIXpxD8dOmXWvBV9esB0nB9F8zbiw5TR1Fae0gD48znvAcKRq2qAJY00vCCR+hsRqn4vMip6Z+6QsNQy1IpAv2dNce9Gr+h4LPie1SMpzx8AHJ18eS6m+CuBiDg50ynT/TdVfGDYxVEO5D8h3IG+i4R5e2PPFaBztK7oaqTZuWkV9qA/q5o/l5MLJyg/NjQC72SWVy598pGSfW+EV1d8GoQt1dqtDjIo+o1GTw5RmS7QbGMBsLW4qhyunEu/67i8skJNQYpWpT/Ls2ANl0IxU8k/4AfWtlJTj2QYuop+trjV8GZUYeKZd2HvbsPEO4oKPCx6QFsnCpJW/l8Ig==
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=MKTinqRY9lAauBy2OZ6xKaVx1KArO4xGTgKQBxwBbBU=;
 b=UlEu1qeTuLU99L0jDNP9Tj9KGou1+VjTpBZ14XV7wc0hQ7Hr9YwF0HHwVcUMfqIS6RqJagjaT1uQ38oVyGg0vn8ctXolBclT261k3QVEJO9QhlqL04PlfFV4BB/XWIaZMisk2GkyXBtn3fmN4zH/exk7RUJ3FovG0GWOzPXK2K0=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Date: Mon, 8 Sep 2025 10:30:29 +0100
From: Yeoreum Yun 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/7] arm64: mm: fully support nested lazy_mmu sections
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-4-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250908073931.4159362-4-kevin.brodsky@arm.com>
X-ClientProxiedBy: LO2P123CA0080.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:138::13) To GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	GV1PR08MB10521:EE_|DB5PR08MB10163:EE_|AM4PEPF00027A5F:EE_|DB9PR08MB7771:EE_
X-MS-Office365-Filtering-Correlation-Id: 06fcb68d-f2eb-4a24-3b41-08ddeeba6fe9
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|7416014|366016;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?it1tKmtR7Py1gVtoYXNfYSfDXfCTSoF5KePThOLsKwNhBb0t2nOdf3sjhwQC?=
 =?us-ascii?Q?x0IeafrD84/hO/FHY6uvnyRGJ+u8nLWRbhtkzuEWvEzlw6tZLRTUZu6O23rz?=
 =?us-ascii?Q?9XuBr32+fJBVIaq+zC3LGBgMBkEz87Xa2QrAl6sS1PCUx+SD3wigaZ/weWpo?=
 =?us-ascii?Q?05NvBYoqvOvMzQY4drqPDgNzJYWyWyUmCgKCLikbs3t3dfYlM8X3yR6W5O+N?=
 =?us-ascii?Q?zfV/MvIX5sg0O2HxuzQdtH2h7fehNfKYrMMwJoL4SkuTmlmjYlHFrwNaD0a0?=
 =?us-ascii?Q?svqLsgVZUtS0gLtdVVflXF+lBOx6QXl9RIi5EqDPus9rkqQmjcDSMv5XZldP?=
 =?us-ascii?Q?6IlEfzW697AQRMtu0NNTwMBtKHNFEZaByAuFVJrPvFjhtBSb/zoYvhdHZ8Xn?=
 =?us-ascii?Q?JvcVMPAHdn51QwRlg5opROsjwwt9qYI/k2wRE4FJpei/UFUvAn/AXdQv8QzU?=
 =?us-ascii?Q?xBxelWe3xMX9ugub8LTKkOBk5Uz9z5pUxtdBCMFIF3fT8SL1PR7oSbUUZVlC?=
 =?us-ascii?Q?HorqNDrmCMwCOZGNx5marwvRP1qx06PLgseXfmp7b18/EWwBh1JXy13tMk8I?=
 =?us-ascii?Q?uVZaY0YEwJXVB2NMyhyrKEGPbc1eo3xtEYaWHmuaAJTYwPslL+elm5a6Gb/Z?=
 =?us-ascii?Q?QI0IfiIWj8i/IbTryDZxXWkWLCzXjzT8Dggojgsl1p4mBd4vL1qqQp3/7rKA?=
 =?us-ascii?Q?rt7vpjP/kWfr5noW6PMhyLY2jLrfZdUTAvwbneA3NNXypxOmJHbBBiXCWQY3?=
 =?us-ascii?Q?sPnL1KaSePiIKNFs6kGPWoZlT8nX+HfTmcaCq1nbDuCrzIvJcZhQdJpHdMB5?=
 =?us-ascii?Q?aCi7mGoPoz2P+pUi47ZW1sSPA9U6wY/E62e7hB8jgIPEndZ4DgN9aHbxR149?=
 =?us-ascii?Q?SeXH2L/yaRVFQlyU70V2cTEndc5CRQVCfXeNKYzPC/5HhYzD1ujThValSA3z?=
 =?us-ascii?Q?yh0ZGV+TXk70DwfQj869Ayt6Tjpry/gbYtatQ8+Sh9L0xLFzJ7180MpmSvus?=
 =?us-ascii?Q?5M92Z7dD2D6FBL4M5P2fV14gvrJ1S/GLz/tr1l689FoN5Bd01YEwAmcQSGG7?=
 =?us-ascii?Q?eTU4Q5jLB6AHfpwl6p8VkFrUy3lUjBvNNuJJ/K1nCsTCLQNfuxXlCRVEPVz/?=
 =?us-ascii?Q?IR3deRi+O7REGxBP0IH0p0oqLZ1726RoSBws5jlG1OY3pynnCioPAKDEBJ1+?=
 =?us-ascii?Q?Psye2rkNkEFnyZq+IxUdwVdzzWkSJfu0PdYMwQ0FbBRYW4giDlPZL/yyKD4w?=
 =?us-ascii?Q?YfjgJ7hNj9myNYxDdvHQPYBXwEN5o3dpDkrvU+Fg8FbGU+qmAmZT9yQCo1Gi?=
 =?us-ascii?Q?Mvi28bzhKf56zK4T62er4pGw8bylvrNxuZnUinAhyD0o+IWpf3sh6kUfYwP3?=
 =?us-ascii?Q?0eP/EnYZsEl1LkIpl3JpPkPhX2w0aghis84KriRW9C6gHfUbD1VVi2Na0gg3?=
 =?us-ascii?Q?2YWaeamKrBM=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR08MB10521.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10163
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A5F.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	98fa7b09-e451-4cd2-b9d5-08ddeeba5bbb
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|7416014|14060799003|35042699022|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?XIlQ9ifH7ju2PwQbAQtwpuDhs1zvHSY5Q9c/JLA1fTVt7k7P7AhqalRBpogq?=
 =?us-ascii?Q?n23PzHld4mllrggqsqN87Xn4uyJhars3wHWdUXVsd08cyKtZMK1LBm3Elyma?=
 =?us-ascii?Q?yONCNqdymnlR8FEfkM5nPz83lVQB1Ya3vrLjFEK9TIFxeGdggJPzUhdu9eFW?=
 =?us-ascii?Q?qcqHyi8+kNDvfM6uHVsSyU6LNjN7XMX1duX3J5K6/SuiXE12sTVjZHRr4mbC?=
 =?us-ascii?Q?+3rZGppHYLfl10zIdvLBCpeGzq3RPxlsss4GfWYoK5XCXUimrn4oE5BrxzlM?=
 =?us-ascii?Q?n3n6lJ1LMK3UdwBaQL7MiDQFwzy7pc4dRXAqWMWlZxqa/V0288pDL9qaF30H?=
 =?us-ascii?Q?1yOXpz8bX1zA6A7cwXWwLbvo3+mX75x+BbiJMxKWJF9HjZIwCEuZNpr5sVzU?=
 =?us-ascii?Q?mVgWeAA57Q6gHyCA6c9KolLEpSsa/NVUlCfW8g1QIATlp770CaeUFsa7tPJ3?=
 =?us-ascii?Q?J1OzqKh9i+W14KTsN+wBMMcd/1EQwfD8xpKDi98XuWFppDHg+dFxoXkxt0TX?=
 =?us-ascii?Q?ywuwX32AGP2PZYz/xSeqzKpLzkiOO/xoZu0tnE4486q4tkOxMttjPIhYqST8?=
 =?us-ascii?Q?h8JMZiRqFqbTGiP5UqC45bYmJdNOHDwdPfTdTIborjqJ61C0hyaTgD+p0Nd7?=
 =?us-ascii?Q?7iHNHzZTrsh63Q2mAkJPGnD6wVl9uFXV7rQfJny51I4QcE5T1TU7CxLcox3Z?=
 =?us-ascii?Q?Vi2adVuDpO7eny5R0VYa5RYxi2ZrBdyOMGxl62aX7OpKG9c8+j1PinPNdjuK?=
 =?us-ascii?Q?MJrGp7bx7YBMB0En/WjG+son3KX4GZDnsINK1JF2Kq34/r78W81S2C1pF78r?=
 =?us-ascii?Q?1NLY480+m4j+IpizA9zOnLLLR01cUAFXIfD/5o8QQuR98TrFWA2iug/b6Qfa?=
 =?us-ascii?Q?SIJseVUuNKQnamYJrv/T+7unMhcbSeoEiIEDlObBaTIzRuguSghQGikI7nak?=
 =?us-ascii?Q?Px/ODwTlJRl5AucoWnkzLE+YjZsBHv0jweNW7VmnZDJ1P7yJ0PyKCXZdkfU7?=
 =?us-ascii?Q?BZy3Es18yAl2V4xxuGSVAQzNtngHI8TwqBJoAU4RC5ow1NqwI2CuxS/4C/1Y?=
 =?us-ascii?Q?JAGOdyhOTpzO27b6JAuiYpmjrJXe0XN+tzI7vP2oeFLaERfMlDNxWJDXRFGZ?=
 =?us-ascii?Q?cuDorEPRN+zGiKTcTRl8GEJcpTmNo1ZAPDrAvLbbKmGdDXl24feuo9tgrfcS?=
 =?us-ascii?Q?dyhWzl1k9/gv4n6SarBhJMVWQ57KCH9QsoObzOg/TTAmQETtX1FbgO1ZBekk?=
 =?us-ascii?Q?djJtKMEH8+pFbQ3FrckWJQdBs4P9u0mxI7QjfTp2mYZI7sr9yqe1l5G30Tdy?=
 =?us-ascii?Q?sv5JzjI26Wbq4RcV3ncvi42PbY2ghesUaqvs8oJPljQ8A+r8ddumX70M8CLd?=
 =?us-ascii?Q?pfONQU2zEO1QXJkH1KXjaEV7zWK2J/GnKQHAAmqIlYsYX/mla4XejN3SxmW/?=
 =?us-ascii?Q?QlW156kyFTWmV7in9HMPc0zJCd9zcxmXEGTuIpX8WPDsqNWbepd3+1mnBJAB?=
 =?us-ascii?Q?cHkfy/T/UXsyHS+PSLvvh5rbz9Y4sQwo02ki?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(7416014)(14060799003)(35042699022)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 09:31:06.4414
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 06fcb68d-f2eb-4a24-3b41-08ddeeba6fe9
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:
	AM4PEPF00027A5F.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7771

Reviewed-by: Yeoreum Yun 

On Mon, Sep 08, 2025 at 08:39:27AM +0100, Kevin Brodsky wrote:
> Despite recent efforts to prevent lazy_mmu sections from nesting, it
> remains difficult to ensure that it never occurs - and in fact it
> does occur on arm64 in certain situations (CONFIG_DEBUG_PAGEALLOC).
> Commit 1ef3095b1405 ("arm64/mm: Permit lazy_mmu_mode to be nested")
> made nesting tolerable on arm64, but without truly supporting it:
> the inner leave() call clears TIF_LAZY_MMU, disabling the batching
> optimisation before the outer section ends.
>
> Now that the lazy_mmu API allows enter() to pass through a state to
> the matching leave() call, we can actually support nesting. If
> enter() is called inside an active lazy_mmu section, TIF_LAZY_MMU
> will already be set, and we can then return LAZY_MMU_NESTED to
> instruct the matching leave() call not to clear TIF_LAZY_MMU.
>
> The only effect of this patch is to ensure that TIF_LAZY_MMU (and
> therefore the batching optimisation) remains set until the outermost
> lazy_mmu section ends. leave() still emits barriers if needed,
> regardless of the nesting level, as the caller may expect any
> page table changes to become visible when leave() returns.
>
> Signed-off-by: Kevin Brodsky 
> ---
>  arch/arm64/include/asm/pgtable.h | 19 +++++--------------
>  1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 816197d08165..602feda97dc4 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -85,24 +85,14 @@ typedef int lazy_mmu_state_t;
>
>  static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>  {
> -	/*
> -	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
> -	 * does happen with CONFIG_DEBUG_PAGEALLOC, where a page allocation
> -	 * inside a lazy_mmu_mode section (such as zap_pte_range()) will change
> -	 * permissions on the linear map with apply_to_page_range(), which
> -	 * re-enters lazy_mmu_mode. So we tolerate nesting in our
> -	 * implementation. The first call to arch_leave_lazy_mmu_mode() will
> -	 * flush and clear the flag such that the remainder of the work in the
> -	 * outer nest behaves as if outside of lazy mmu mode. This is safe and
> -	 * keeps tracking simple.
> -	 */
> +	int lazy_mmu_nested;
>
>  	if (in_interrupt())
>  		return LAZY_MMU_DEFAULT;
>
> -	set_thread_flag(TIF_LAZY_MMU);
> +	lazy_mmu_nested = test_and_set_thread_flag(TIF_LAZY_MMU);
>
> -	return LAZY_MMU_DEFAULT;
> +	return lazy_mmu_nested ? LAZY_MMU_NESTED : LAZY_MMU_DEFAULT;
>  }
>
>  static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
> @@ -113,7 +103,8 @@ static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>  	if (test_and_clear_thread_flag(TIF_LAZY_MMU_PENDING))
>  		emit_pte_barriers();
>
> -	clear_thread_flag(TIF_LAZY_MMU);
> +	if (state != LAZY_MMU_NESTED)
> +		clear_thread_flag(TIF_LAZY_MMU);
>  }
>
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> --
> 2.47.0
>

--
Sincerely,
Yeoreum Yun


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:33:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:33:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114940.1461720 (Exim 4.92)
	(envelope-from )
	id 1uvYFZ-0006mc-Qo; Mon, 08 Sep 2025 09:33:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114940.1461720; Mon, 08 Sep 2025 09:33: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 1uvYFZ-0006mV-NU; Mon, 08 Sep 2025 09:33:25 +0000
Received: by outflank-mailman (input) for mailman id 1114940;
 Mon, 08 Sep 2025 09:33: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 1uvYFZ-0006mP-6W
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:33:25 +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 ddc4cbb3-8c96-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:33:24 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-56088927dcbso5198159e87.3
 for ; Mon, 08 Sep 2025 02:33: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: ddc4cbb3-8c96-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757324004; x=1757928804; 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=aMwsIgKn4wUaEskwvBxZtpRU7mhGPnrjI7rs056tFNg=;
        b=d3V8fyayMhoYM3HWAMoENiQrSz0QWPeJRYa91mgNdm2TpLIhhLQJ+OHj2mMtU5B4hk
         MUDKaDOoWqy8nps45A3W6tHsfhQWDaW12M9QFffVZ5Gapa8OTf7e0Ifs/R5szSHRBPM6
         MhqkPNO/Bo571V8Hk51jIC1U/wAYoGx0BJWnJCKpyrp5ZGAs38UFe0EBOcUP3Dh4YvBs
         ggfMbvuDTloU+Imu6DpqZQKyB7HtRvKLIYp5Oy6jzLUW21BR59RufDW4Xf9CHmlLPzf/
         In0+WdREqKVyv0DDcYs2qXdrj6XB8eNDyqxuK2b2rKMB42wATPaX1j3vRR4ZU7rsz5d0
         afww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757324004; x=1757928804;
        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=aMwsIgKn4wUaEskwvBxZtpRU7mhGPnrjI7rs056tFNg=;
        b=GxMtqmEe07BzpRhW+WcTYHNLfIrgi5ToEm+vMQ3EHiZnz+vU00MO4kfy9Wo4Q4QEW7
         YD4qKNXYaxXIX8/FEZRtiJAeflo8IRxqoY1LGNGfWboM/XfcCO+fh9fomakADeCUFuBU
         RRucQJxxseo7NwCopAIX4gn3yLbjAvJefpMeLvsbpFi/wUFdixAY1EZ5kcMOtZyBRpAV
         N5ekRnTSlkjqWRdhf0GT3G6ZlkDN5HE3o+kzaOQoF70waGZQkvCJNl8nG9aEQvGF5tWO
         7+9FIHyvWaw1LdW2bLaDtHKZnCNQOjqW6C2H4IWPYrWICX27j6zBkOE+MiTRqNYR9mQJ
         IXXA==
X-Gm-Message-State: AOJu0YzHRnlzljwLRsZQhRUCT/0wCbqXJvLB8pHMKSjioPuY+sWJSGxG
	fF43k7aNwcdZI88PuMzmHOm0yYPY+2Q7NsXm9BTT7wZhElbRanY+CAtcOSvVIpNeza1Jbz+bjxf
	d3ybWTOla3SmqW2NypusOg5WYW0Iq2HE=
X-Gm-Gg: ASbGncuP+x1ouN2bQJa3D+WqpDyKXQikcbEZQzuFgeHbnIjDS+JrP2vncPeMvi+oNdj
	wJ5ajysp/N8iauE/c5bD1N49oyyMe518NwG7d0ZJNaR0mgHL65Q6zvO8UNNExuZf8UMd3z8/acD
	gDvTsgE3tjjyvgN9+61whGTebca/GVk2jfDB2nZkQ7S++30ZV81fmjRGaXfbCA4865v7FIA0PJI
	NpOagIBIhjl4q8T
X-Google-Smtp-Source: AGHT+IEmgyBkUVkOmQ4lE7SXlGjIq1NWBD1MGxHCxdtMxYnhMjSPohPUF0IDKYUMXDuqoBjlx98GzRjud2Xprx8KcD0=
X-Received: by 2002:a05:6512:230b:b0:55f:6831:6f01 with SMTP id
 2adb3069b0e04-562617e6c0emr1724073e87.40.1757324003489; Mon, 08 Sep 2025
 02:33:23 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Mykola Kvach 
Date: Mon, 8 Sep 2025 12:33:10 +0300
X-Gm-Features: Ac12FXxqyH6WF70_HfUbrzDkULlc2J6-iRJwDnwuwDMatnVmPC2JT7Oa0hQjSXs
Message-ID: 
Subject: Re: [PATCH] symbols: fix xensyms_read() hitting the final "end" symbol
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?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Mon, Sep 8, 2025 at 12:22=E2=80=AFPM Jan Beulich  wro=
te:
>
> A new "no (more) symbol" path there was lacking a necessary unlock.
>
> Fixes: d3b637fba31b ("symbols: arrange to know where functions end")
> Coverity ID: 1665212
> Signed-off-by: Jan Beulich 
>
> --- a/xen/common/symbols.c
> +++ b/xen/common/symbols.c
> @@ -202,7 +202,10 @@ int xensyms_read(uint32_t *symnum, char
>      {
>          ++next_offset;
>          if ( ++*symnum =3D=3D symbols_num_addrs )
> +        {
> +            spin_unlock(&symbols_mutex);
>              goto no_symbol;
> +        }
>      }
>
>      *type =3D symbols_get_symbol_type(next_offset);
>

Reviewed-by: Mykola Kvach 

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:35:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:35:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114950.1461731 (Exim 4.92)
	(envelope-from )
	id 1uvYHs-0007JR-6K; Mon, 08 Sep 2025 09:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114950.1461731; Mon, 08 Sep 2025 09:35: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 1uvYHs-0007JK-3J; Mon, 08 Sep 2025 09:35:48 +0000
Received: by outflank-mailman (input) for mailman id 1114950;
 Mon, 08 Sep 2025 09:35:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvYHr-0007JA-DC
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:35:47 +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 32421f1a-8c97-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:35:46 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aff0775410eso745177166b.0
 for ; Mon, 08 Sep 2025 02:35: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-b04279a59ffsm1902705566b.60.2025.09.08.02.35.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 02: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: 32421f1a-8c97-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757324145; x=1757928945; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vAWbVGFOyVbyku9ekhHyfh442nJbdOdcBzWpnssbG5A=;
        b=CMdBN4J2cMPtA5cr5RqE294PS558EnKFBwcWB1ncISFVL2FWsDPNIIZi+BTC8Wxw1v
         njWw+dMIPmLuK/LGlulX4f6g7qpZqDnAoDhQgGIvUEMn/IgrowXQ+oJzY3sdWrBkn3Zr
         A+tSzbgGxBXFGuHzXoz/z96YkkFEeghpudKr0QgYxjJdv02Vp0WyMdocsA4PnnY/rzIf
         gA5fOWbZqxtr4Pq3HETDrHpgvvW4bjhXN4xMjK1ZiTbNfdI0oIZAm/yPE8p26l4SG708
         vlEuKDnyxZlfPVG9XmuhqUTZANp7yDYfIhuECia29h+tCHlXVcN0QiDGj3s92eJZjGUi
         T3rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757324145; x=1757928945;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vAWbVGFOyVbyku9ekhHyfh442nJbdOdcBzWpnssbG5A=;
        b=FPNL04PG/6tRm7C1Qknduwg59qIr8azhYygoRJLrMGh9U6SqS0eKtzyz75FF3Ckyh6
         GbX1c+OGf7JcJvvavjuupJ2136nInzv0GaQtq0ZShITQPBmHmbeiB2/fWqmP4umqMMDt
         x+RKiEenNBzv+/eYD5Jp1Ucr9rX690wi7etWroYlgCKmOzJEBb4Au/voRNEpeEIUKhUK
         FIwCnGwokQg5IPfVbmL0uhCQgFNv4Z5e6rxLLcZml/+nWWTm6lEjm7Q0ITZbm14ULrqV
         75zqsQiuynM+s9YTXEAQP5znuLcSiEtswxRZ4dJx4JswcJZUe0Rcr7GfMnPsJ/5nZFFC
         wfxA==
X-Forwarded-Encrypted: i=1; AJvYcCUvilQ6b6TRJvwoyediYzdqJ8H2qVRgzR/saXfmhct1A+5mKK9GldZgLaW49L+pp1km+EskGc1Iq4E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzd1fFB5r18m9FJHY0emtBz/9Usx5cTzRMH69LDox1FFOQ6wmx+
	D69MVpKp0tw2jkltj5kNaOjwK4OYyT869vlFqEq+pKfVQFtW6uOu5aLAXfTgEMQohg==
X-Gm-Gg: ASbGnctmHvV/JqDIQPbNHpQfKD8ibmJ6s7AZ6YOiz0jmkHyjQwTnfzTkFGbia4s1q92
	12F2Qxfi/rIrTpAenVSFKyJtqKJvVMfDRvMrK6tmTUy122tdBehKyLZCP1EPLXeyQWXY0YnW7U4
	ifnFgUdMfu0S8VbyaoR07TVeAKGQ/Uz7j6AkKJBW0WswgZp7j/hvUfJPTGKO/bnX4E+qpgidz/f
	bjWo4EURmogk+RPmjVM3UCLliVZJyoVurTCIgDkeNZS09AP/T6p7ocPbU31RtRiF5XqAcGlC+4f
	Gnw0gnj6KD5YDQk5fG4OflWnJPthjjrcoKF5lYxgDqSBQ0deFpOu3tIZEahg9xqGJYxeSyuANJi
	Yis/XCC/A2+UNQxKF+ElJmmdp2lS8KjPUWAxpgtMkLaPu5RlYc0DTi63qJDwyFf7/HR/S0LL8nF
	S26mYComM=
X-Google-Smtp-Source: AGHT+IGTuMXtVjPISB1s7aGMxTgzZ489AnseGOsTbQpR3w/49IpmHYrsZYszaZZLrBSOa4FZz7dJBg==
X-Received: by 2002:a17:907:3f92:b0:afe:d4b0:c0bf with SMTP id a640c23a62f3a-b04931f4c34mr1289895866b.17.1757324145337;
        Mon, 08 Sep 2025 02:35:45 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 11:35:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
To: Jason Andryuk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Penny Zheng 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@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.09.2025 20:53, Jason Andryuk wrote:
> On 2025-09-04 07:50, Jan Beulich wrote:
>> On 04.09.2025 08:35, Penny Zheng wrote:
>>> @@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct cpufreq_policy *policy,
>>>                                          unsigned int relation)
>>>   {
>>>       unsigned int cpu = policy->cpu;
>>> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
>>> +    struct hwp_drv_data *data = policy->u.hwp;
>>>       /* Zero everything to ensure reserved bits are zero... */
>>>       union hwp_request hwp_req = { .raw = 0 };
>>
>> Further down in this same function we have
>>
>>      on_selected_cpus(cpumask_of(cpu), hwp_write_request, policy, 1);
>>
>> That's similarly problematic when the CPU denoted by policy->cpu isn't
>> online anymore. (It's not quite clear whether all related issues would
>> want fixing together, or in multiple patches.)
>>
>>> @@ -350,7 +349,7 @@ static void hwp_get_cpu_speeds(struct cpufreq_policy *policy)
>>>   static void cf_check hwp_init_msrs(void *info)
>>>   {
>>>       struct cpufreq_policy *policy = info;
>>> -    struct hwp_drv_data *data = this_cpu(hwp_drv_data);
>>> +    struct hwp_drv_data *data = policy->u.hwp;
>>>       uint64_t val;
>>>   
>>>       /*
>>> @@ -426,15 +425,14 @@ static int cf_check hwp_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>>   
>>>       policy->governor = &cpufreq_gov_hwp;
>>>   
>>> -    per_cpu(hwp_drv_data, cpu) = data;
>>> +    policy->u.hwp = data;
>>>   
>>>       on_selected_cpus(cpumask_of(cpu), hwp_init_msrs, policy, 1);
>>
>> If multiple CPUs are in a domain, not all of them will make it here. By
>> implication the MSRs accessed by hwp_init_msrs() would need to have wider
>> than thread scope. The SDM, afaics, says nothing either way in this regard
>> in the Architectural MSRs section. Later model-specific tables have some
>> data.
> 
> When I wrote the HWP driver, I expected there to be per-cpu 
> hwp_drv_data.  policy->cpu looked like the correct way to identify each 
> CPU.  I was unaware of the idea of cpufreq_domains, and didn't intend 
> there to be any sharing.
> 
>> Which gets me back to my original question: Is "sharing" actually possible
>> for HWP? Note further how there are both HWP_REQUEST and HWP_REQUEST_PKG
>> MSRs, for example. Which one is (to be) used looks to be controlled by
>> HWP_CTL.PKG_CTL_POLARITY.
> 
> I was aware of the Package Level MSRs, but chose not to support them. 
> Topology information didn't seem readily available to the driver, and 
> using non-Package Level MSRs is needed for backwards compatibility anyway.
> 
> I don't have access to an HWP system, so I cannot check if processors 
> share a domain.  I'd feel a little silly if I only ever wrote to CPU 0 :/
> 
> I have no proof, but I want to say that at some point I had debug 
> statements and saw hwp_cpufreq_target() called for each CPU.
> 
> Maybe forcing hw_all=1 in cpufreq_add_cpu()/cpufreq_del_cpu() would 
> ensure per-cpu policies?

No, domain info is handed to us from ACPI (_PSD). That's what
cpufreq_add_cpu() evaluates. Therefore if there was evidence that HWP (and
CPPC) can only ever have single-CPU domains, we could refuse such _PSD
being handed to us (ideally already in set_px_pminfo()). But I don't think
we can just go and override what we were told. I fear though that the mere
existence of a package-level (alternative) MSR suggests that such
configurations might be possible.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:36:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:36:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114953.1461740 (Exim 4.92)
	(envelope-from )
	id 1uvYI7-0007hM-Fs; Mon, 08 Sep 2025 09:36:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114953.1461740; Mon, 08 Sep 2025 09: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 1uvYI7-0007hD-DQ; Mon, 08 Sep 2025 09:36:03 +0000
Received: by outflank-mailman (input) for mailman id 1114953;
 Mon, 08 Sep 2025 09:36: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 1uvYI5-0007dH-OP
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:36:01 +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 38669b95-8c97-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 11:35:56 +0200 (CEST)
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-e9d5e41c670so3911386276.0
 for ; Mon, 08 Sep 2025 02:35: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: 38669b95-8c97-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757324156; x=1757928956; 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=VmNQj5CvzMm3+mVyvgID5aOJAeNFb9zTblKtJiTor2I=;
        b=TL/HRPCeqDoz1b2MdPMpufnUbAIv3Ttqn0LtlNJoiatk7gNRIqaos6hA8C5QG5nyox
         qZv6A3lC/ipDOjgFRJkGVFLfM1GSqOOdqp9/fYiT07P9kf1u43YTQ8RfCWIyXq3UBfYg
         d1R89Jh0ACaYi+GoeliPz23ImtxhmZfpwHguk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757324156; x=1757928956;
        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=VmNQj5CvzMm3+mVyvgID5aOJAeNFb9zTblKtJiTor2I=;
        b=Q8UbIjVPELZcbXGh2CLMT/u+HvK2aNzlFnfwHWLlm5zKkTu4P8tFXUcgXQ+KU7yIXU
         L7SsBBYd4Pj0OrY7uUBJMWIzmg46HV3/m08oNwvYlC5dtluNfEmMETTCg0kcjHeupOfN
         xBXZVuU9hQ/BeaaUQr2jE2zkZSRNbJ1sGYcQYZdLnRUKlo4gSgObXZlyIebKtMNqaWHh
         0WBGym9kdVDV8AVFgFVF6Hcy2I4mKpe9LNrYeOYgiPQynfjM8v/pNeQ9BA/bdE08R5hz
         lxW4lj20Sq+aBUPgZH/BfVF15Ny2vAOQAwQ0rL4QW2vYFk8dq5OT/Hm5JA60uz027ZGr
         SL+Q==
X-Forwarded-Encrypted: i=1; AJvYcCX9Arbwu60m0S3v5KTIflrCZVf5v60EaZoghynZPaBiArPVw/8ImDx2J0BPBTHRTyaMJ/C2ELjICzI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLS1n92nG2xsX3oODFSu2Ke+oNA/znMvUYGE2FRdqeAtfkm5Bc
	OupgQm16jK0bjqOnGOmxaViEZ0PstRHN/2gT1X2i4wHGNCcNCcv72dZYNUdZtzmsoKXrRRFcBho
	RynrkwvI4oM/Z4faG/aEzk6E8VSz3Gm8h/AsyYeXMvA==
X-Gm-Gg: ASbGncumZ8MWCC7kI+qk/PQTcmCymSiW4vmhPcX4RCrk/SLIZ7Vf52jhJ1QKj5nIxEo
	yH/dLgMgZ6G1zabiwLrfwchtR8S2kvR27xdbv7sOB/BBRqo/SbIlHg6xMoQQUsiIkr5NcOkEReG
	LoTdAOZHX0cjpKHa1cyCZJ9qqZqN6Be0WkSBNlz2WldDNKEX7dajZvLZhXTg0T1u8UAf4Tsd5JG
	sXZc2xR9NoY+zR6b98x07bCnMRIlPOoS9XBvLLq
X-Google-Smtp-Source: AGHT+IElmatWT17jYWsW+gUSp/ZDRToxQ2dIgLj9ktdeVpGM1UhetYGY2AJ4XLEcUtbelrsOzoa+UhGMz7Rt+Fqp+ko=
X-Received: by 2002:a05:6902:2304:b0:e97:b32:fa5c with SMTP id
 3f1490d57ef6-e9f685ad47bmr6332215276.49.1757324155607; Mon, 08 Sep 2025
 02:35:55 -0700 (PDT)
MIME-Version: 1.0
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
 
In-Reply-To: 
From: Gerald Elder-Vass 
Date: Mon, 8 Sep 2025 10:35:44 +0100
X-Gm-Features: AS18NWDOw7R2YJ1ONaLccNozwnaHV0Wy5EqpPDFZJL9g1LnuJ7Z2Srq8_BrT58Y
Message-ID: 
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
To: Jan Beulich 
Cc: Ross Lagerwall , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	"Daniel P. Smith" , Andrew Cooper , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Xen-devel 
Content-Type: multipart/alternative; boundary="0000000000000cfec2063e46ea56"

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

>> +          size =3D=3D 1 && data =3D=3D 0) )
>
>... any reason it's literal 1 here?

The size variable is also used as output from GetVariable and we should
verify that the size of the returned data is as expected, it is simply one
byte so probably not worth defining any macros to make it clearer


*Gerald Elder-Vass*
Senior Software Engineer

XenServer
Cambridge, UK

On Mon, Sep 8, 2025 at 9:49=E2=80=AFAM Jan Beulich  wrot=
e:

> On 05.09.2025 14:10, Gerald Elder-Vass wrote:
> > From: Ross Lagerwall 
> >
> > Also cache it to avoid needing to repeatedly ask the firmware.
> >
> > Signed-off-by: Ross Lagerwall 
> > Signed-off-by: Gerald Elder-Vass 
> > ---
> > CC: Marek Marczykowski-G=C3=B3recki 
> > CC: "Daniel P. Smith" 
> > CC: Jan Beulich 
> > CC: Andrew Cooper 
> > CC: Anthony PERARD 
> > CC: Michal Orzel 
> > CC: Julien Grall 
> > CC: "Roger Pau Monn=C3=A9" 
> > CC: Stefano Stabellini 
> >
> > v4:
> > - Fix MISRA warning regarding SecureBoot string
> > v3:
> > - Fix build on ARM
> > ---
> >  xen/common/efi/boot.c    | 24 ++++++++++++++++++++++++
> >  xen/common/efi/runtime.c |  1 +
> >  xen/include/xen/efi.h    |  2 ++
> >  3 files changed, 27 insertions(+)
> >
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index e12fa1a7ec04..ccbfc401f7ba 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file
> *file)
> >                     " last line will be ignored.\r\n");
> >  }
> >
> > +static void __init init_secure_boot_mode(void)
> > +{
> > +    static EFI_GUID __initdata gv_uuid =3D EFI_GLOBAL_VARIABLE;
> > +    static CHAR16 __initdata str_SecureBoot[] =3D L"SecureBoot";
> > +    EFI_STATUS status;
> > +    uint8_t data =3D 0;
> > +    UINTN size =3D sizeof(data);
>
> Unlike here, ...
>
> > +    UINT32 attr =3D 0;
> > +
> > +    status =3D efi_rs->GetVariable(str_SecureBoot, &gv_uuid, &attr,
> &size, &data);
> > +
> > +    if ( status =3D=3D EFI_NOT_FOUND ||
> > +         (status =3D=3D EFI_SUCCESS &&
> > +          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS |
> EFI_VARIABLE_RUNTIME_ACCESS) &&
>
> (Nit: Overlong line.)
>
> > +          size =3D=3D 1 && data =3D=3D 0) )
>
> ... any reason it's literal 1 here?
>
> Jan
>

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


>> +=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 size =3D=3D 1 && data =3D=3D 0) )
>
>... any reason it's literal 1 here?

The size variable is also used as output =
from GetVariable and we should verify that the size of the returned data is=
 as expected, it is simply one byte so probably not worth defining any macr=
os to make it clearer

=

Gerald Elder-Vass
Senior Software Engin=
eer

XenServer
Cambridge, UK
<=
/div>

On Mon, Sep 8, 2025 at 9:49=E2=80=AFAM Jan=
 Beulich <jbeulich@suse.com>=
 wrote:
On 05.09=
.2025 14:10, Gerald Elder-Vass wrote:

> From: Ross Lagerwall <ross.lagerwall@citrix.com>

> 

> Also cache it to avoid needing to repeatedly ask the firmware.

> 

> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>

> Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>

> ---

> CC: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com&=
gt;

> CC: "Daniel P. Smith" <dpsmith@apertussolutions.com>

> CC: Jan Beulich <jbeulich@suse.com>

> CC: Andrew Cooper <andrew.cooper3@citrix.com>

> CC: Anthony PERARD <anthony.perard@vates.tech>

> CC: Michal Orzel <michal.orzel@amd.com>

> CC: Julien Grall <julien@xen.org>

> CC: "Roger Pau Monn=C3=A9" <roger.pau@citrix.com>

> CC: Stefano Stabellini <sstabellini@kernel.org>

> 

> v4:

> - Fix MISRA warning regarding SecureBoot string

> v3:

> - Fix build on ARM

> ---

>=C2=A0 xen/common/efi/boot.c=C2=A0 =C2=A0 | 24 ++++++++++++++++++++++++=


>=C2=A0 xen/common/efi/runtime.c |=C2=A0 1 +

>=C2=A0 xen/include/xen/efi.h=C2=A0 =C2=A0 |=C2=A0 2 ++

>=C2=A0 3 files changed, 27 insertions(+)

> 

> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c

> index e12fa1a7ec04..ccbfc401f7ba 100644

> --- a/xen/common/efi/boot.c

> +++ b/xen/common/efi/boot.c

> @@ -901,6 +901,28 @@ static void __init pre_parse(const struct file *f=
ile)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0" last line will be ignored.\r\n");

>=C2=A0 }

>=C2=A0 

> +static void __init init_secure_boot_mode(void)

> +{

> +=C2=A0 =C2=A0 static EFI_GUID __initdata gv_uuid =3D EFI_GLOBAL_VARIA=
BLE;

> +=C2=A0 =C2=A0 static CHAR16 __initdata str_SecureBoot[] =3D L"Se=
cureBoot";

> +=C2=A0 =C2=A0 EFI_STATUS status;

> +=C2=A0 =C2=A0 uint8_t data =3D 0;

> +=C2=A0 =C2=A0 UINTN size =3D sizeof(data);



Unlike here, ...



> +=C2=A0 =C2=A0 UINT32 attr =3D 0;

> +

> +=C2=A0 =C2=A0 status =3D efi_rs->GetVariable(str_SecureBoot, &=
gv_uuid, &attr, &size, &data);

> +

> +=C2=A0 =C2=A0 if ( status =3D=3D EFI_NOT_FOUND ||

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(status =3D=3D EFI_SUCCESS &&am=
p;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attr =3D=3D (EFI_VARIABLE_BOOTSERV=
ICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&



(Nit: Overlong line.)



> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size =3D=3D 1 && data =3D=
=3D 0) )



... any reason it's literal 1 here?



Jan




--0000000000000cfec2063e46ea56--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:36:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:36:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114960.1461751 (Exim 4.92)
	(envelope-from )
	id 1uvYIF-00086C-N2; Mon, 08 Sep 2025 09:36:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114960.1461751; Mon, 08 Sep 2025 09:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvYIF-000863-K9; Mon, 08 Sep 2025 09:36:11 +0000
Received: by outflank-mailman (input) for mailman id 1114960;
 Mon, 08 Sep 2025 09:36: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 1uvYDo-0005Ke-Is
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:31:36 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d130a47-8c96-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:31:35 +0200 (CEST)
Received: from AS4P189CA0038.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:5dd::10)
 by GVXPR08MB11319.eurprd08.prod.outlook.com (2603:10a6:150:2c0::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 09:31:30 +0000
Received: from AM2PEPF0001C70A.eurprd05.prod.outlook.com
 (2603:10a6:20b:5dd:cafe::6b) by AS4P189CA0038.outlook.office365.com
 (2603:10a6:20b:5dd::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 09:31:29 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM2PEPF0001C70A.mail.protection.outlook.com (10.167.16.198) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.13
 via Frontend Transport; Mon, 8 Sep 2025 09:31:28 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20) by DB5PR08MB10163.eurprd08.prod.outlook.com
 (2603:10a6:10:4a2::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 09:30:46 +0000
Received: from GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739]) by GV1PR08MB10521.eurprd08.prod.outlook.com
 ([fe80::d430:4ef9:b30b:c739%7]) with mapi id 15.20.9094.018; Mon, 8 Sep 2025
 09:30: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: 9d130a47-8c96-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=UvOwiHbBnOmW354gh9MfuzVl9m+dVZNamvM/jJBSe9xwP17V4DLACbCQQMl/G9AHUBMD4oOAqxApOciJNIyxmpRj790aMCbxAHS7NtvgXm5Hgc6hXf7TSH+a+C8AYpq4ToYul8bXHby53dytu0Ke83ZxAIAzHxOdoIa5wOajJTnEEEThgqU90kq7tumL+kdK5Y4kAxPS6HRvTVJYXLlymVUodqG62f74iMLbuO1FVxudeRZLmnJZieP9Vu8Ru4vNpZdFcA+9ur/0yC1L8FG/bAfXOPu2NIwz0p2wStFC0FmmSHBzbTpmulX1C4RLrERMFJylYemT70wFu6PiIQpo8Q==
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=9ca+HaUjALnyCJht2ic4lnms/jl5V6Hbxrc4FeHuxbs=;
 b=Bz48cn1uFO6w4D//XSm27KqDG1xYH0uv4qRhmH9jYyCtlQHmPfHMsEumWory/Xeia5JuWRA+hCKCfJai32JI3pOCMJ7Yl98O/rCxBeMHnmXBcO+6WjS4krbmcOXdRnAskTwdJITXIAAih7O286fWSjYxjR0pBr0ATDiN7CPs/JSXaJCb+vUc6OxRJ3+5/VK9HHieKtEILcwUCEgL8LOUhpxjfP7mqEmesB3V5nKrqS8pnSKYmYCUkeb13JJ2OEpp0V0qYP3c4m7WJ/+zuZ9Oc/UEZz8YnNAQDPO8VTLttD5Ck04ymkm8zghzjj5nxlM/dsaDywc8ex/qOVWTFulzeQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kvack.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=9ca+HaUjALnyCJht2ic4lnms/jl5V6Hbxrc4FeHuxbs=;
 b=i2y6ickjg+BBy46UgPnTXqLouzMa5P0nREgbgRVdgxF3m6V0l9nWs2HisbdG2Qx497sMUm1qL6MIGuczu9g1hWaIGroCs9VsGcWmjPhPQh3SiW/knxTlMOnzcWrajXrGJFdstQoviKZnjrgXOyASLacyaxp5U0mnhYP9MIj7Yr8=
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=GzcY3S/NwHk8YU5gaMzhhD43VmzVbu70esFVbh4NJIWCf6AAeQODSri1HTzaDoXIGK4E6BVCjH6jKTFquvzLkqDSgnBWBM7pUbsbEw0ZK7VVhl4Etv2/xBKkZjpyQwmt/ZFcqFH3942Yo4DTkt36cCLWuw1UMLxN+sDJPW3lPJbdtCMu/WT9ty3mzLl2RcNVZ4qx0x1JC2N/kpI6e3p/VV6qVctkSCuyQPV8wbUO3NOeErgGAOwvjU/N1cIsiRwHzWfDl+Dpi4Z+N7O5B9vGg5YxzZZWWNw5AS5umljUdCXr2ytoKyY67GVUv0CunOxgOCIwSsRYZZMZo1Yrscsr7g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9ca+HaUjALnyCJht2ic4lnms/jl5V6Hbxrc4FeHuxbs=;
 b=w3/A5pq11Dv4TfL+I1HTtYpi6gfV4BAbolYwPzZ82nQqrJ46Hci4tKNw+9sDqjvI1A8RCIFl5s4rfQnxKQ1hVc60+6UCvqLoVYk0Oc6Qkpp1qQLBBVlwTCDjMP2c85hQ/FE+rkloofVCSaonDUVCLZT9iWQ8sKJKTS7DK9QZ0TF1ekk748/rvbz17kXESVtFklxtTbYZc1l8gupbQl0qwCF9266ClFBZIzl2uow2AZsDyiAgsypmJHJ6tt0Ji5uKJ6VX/SfBCdEG+/cWNSjcEZebTyYp+PXCIK22WB79ZtIsFfToSahGcygIOn32pP7DvinmVzqqbBLcVo9vOM/1hQ==
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=9ca+HaUjALnyCJht2ic4lnms/jl5V6Hbxrc4FeHuxbs=;
 b=i2y6ickjg+BBy46UgPnTXqLouzMa5P0nREgbgRVdgxF3m6V0l9nWs2HisbdG2Qx497sMUm1qL6MIGuczu9g1hWaIGroCs9VsGcWmjPhPQh3SiW/knxTlMOnzcWrajXrGJFdstQoviKZnjrgXOyASLacyaxp5U0mnhYP9MIj7Yr8=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Date: Mon, 8 Sep 2025 10:30:42 +0100
From: Yeoreum Yun 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Alexander Gordeev ,
	Andreas Larsson ,
	Andrew Morton ,
	Boris Ostrovsky ,
	Borislav Petkov ,
	Catalin Marinas ,
	Christophe Leroy ,
	Dave Hansen ,
	David Hildenbrand ,
	"David S. Miller" ,
	"H. Peter Anvin" , Ingo Molnar ,
	Jann Horn , Juergen Gross ,
	"Liam R. Howlett" ,
	Lorenzo Stoakes ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Michal Hocko , Mike Rapoport ,
	Nicholas Piggin ,
	Peter Zijlstra ,
	Ryan Roberts ,
	Suren Baghdasaryan ,
	Thomas Gleixner ,
	Vlastimil Babka , Will Deacon ,
	linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 7/7] mm: update lazy_mmu documentation
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-8-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250908073931.4159362-8-kevin.brodsky@arm.com>
X-ClientProxiedBy: LO0P123CA0001.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:354::10) To GV1PR08MB10521.eurprd08.prod.outlook.com
 (2603:10a6:150:163::20)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	GV1PR08MB10521:EE_|DB5PR08MB10163:EE_|AM2PEPF0001C70A:EE_|GVXPR08MB11319:EE_
X-MS-Office365-Filtering-Correlation-Id: 7fb38d49-76cb-44c8-0ea8-08ddeeba7cf2
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|7416014|366016;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?mc/DZxczjZ5Tw2y2bRBKf0jJHfY+1cMA183gNizjtcemH+ZB6krdHoCtKs9R?=
 =?us-ascii?Q?rEJZs/LC5FySiZNsw3OEze6JaYBGi0ZCo5Y1i+wUqAxrxi/xLg0+b2PW0Gan?=
 =?us-ascii?Q?Hu/+9PDxEcA77rBe/Yh7D/Az17HYKu40TcOSRu1P+US5HSyCfQoOvi5ELPRq?=
 =?us-ascii?Q?5eZeUGNgNMkn/ZFX0b/UZiwiOJxyeBoHNR6n2mjRMx2Flr5aZ7V2fn6EwsXg?=
 =?us-ascii?Q?dvOpVtROyIAbWwS5fLKl1j0EOvJEjrK4auYck66gcxAPyT5Y6tPl2g66UJsj?=
 =?us-ascii?Q?Z2fJYGN1+lbSrhHwQTY6EVbjuaZxGTzNc5n0nUsAPp13uW/w/JgGL3mI7ifw?=
 =?us-ascii?Q?7OMQ2ua7VlYXlN2MyEqT0h96Lju0H5zfEX3qa/RAkU11sek6lCiemA0VuNPl?=
 =?us-ascii?Q?NuDR6Yln525bAPXGEeMySiMCrnAzqOy3MQtW+cLPZl1uUlFXm79ls38/EVxf?=
 =?us-ascii?Q?+8985IkQv4MwD0DNH/810b63nObzJTpG8mCsfoM7NoI3Y2xEHjXJ4UWCyFmw?=
 =?us-ascii?Q?n3Lf5n0u97GnsoY1ZWsQRT3A3kwfX2UiQ/JxjDsL1/HV/1GCd2D5fTwJyxje?=
 =?us-ascii?Q?r+UdHO34piBXqaDHtUrD9WJ9X2Te1LpCZWRrkLmirVg7TF8SD1C586L2faBE?=
 =?us-ascii?Q?s8MYWY+q/+wAtCm5r/LR1G2subFbmR6YBERC3NkG1AjC4EtkqHCrWbIpDFqK?=
 =?us-ascii?Q?Yp0kv4+CbLK1qrcmI3TrXsoYf60aI1eWziINMLyV7aaGzJr9dH01VqqvJgHd?=
 =?us-ascii?Q?GI2fBNpbd3z2ox8ki8ZB56AJrbs480Lve32YosjzL4HGtswerOjeenSABtOf?=
 =?us-ascii?Q?WBl6unX6bePwxK4Nyf2zDhwq9ofO8k/pOPab68TPd4FgEO/lA6+8pOxcVcC6?=
 =?us-ascii?Q?nH78oMLuowaLLtIXM+IoPLqRl9peIcogbwjmYUxCHmBLrDJrrT6+8dFwEMs7?=
 =?us-ascii?Q?xOIvat6w/nNGERI4HOUjfhc6im/VEYmpMAJhKkh/ltgnbQqGCdZouyTFOQgW?=
 =?us-ascii?Q?s3J0cA4fqHVrIS4SJwPevCqg+iuYqMUSSxHA1qQrePuEPuAeodE9uX10tZnR?=
 =?us-ascii?Q?9WvNrlYf0fiIoON6+9hJWzDaa8EDhDE4ZdPuLXWD2vQIzaFklWrjyTrYLNtu?=
 =?us-ascii?Q?TT78A/By49svFpkhHxJZO/7jMSkcKgxCRaA/luU/uYr9a801PnD0E257pvHS?=
 =?us-ascii?Q?DJ4KK6Qd+NcRDVeM2oEMdCKngB4DYGjsVxdAuxAcPcve6w2BsoAs6WQ3Tky0?=
 =?us-ascii?Q?2Bn/tBJteswJYy5tOUPIdsP4xbVCbB8AXSlXf8NxSvSIWcC+D34DnphRjFUR?=
 =?us-ascii?Q?cg0P1/M//myZDtL3vDQhP85m5gCoFPifWkrCBHVxIWGN4HvWiGzEZFG0bu2L?=
 =?us-ascii?Q?Q6Ik/xyCfc/tylrShjryeRisEg3lMfj0ExlOKia3+jqeDHXqWlB++yhQWpcM?=
 =?us-ascii?Q?6WSLbvrg5cM=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR08MB10521.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10163
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM2PEPF0001C70A.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	6d139c24-8f97-4caf-4e9c-08ddeeba63f9
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|14060799003|82310400026|35042699022|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?neAHsbAqzGVc+6f1QfzwFSYXmgTFhynXySmqSOUOfWAEVwIUmXC0nNW3/pph?=
 =?us-ascii?Q?g2QffH8PQ6rsZauFr72jEs7DSijJGKF86Ppxg4pZZPFNI7WKH9+X+rnoZ9KX?=
 =?us-ascii?Q?yjsN08UDNuDMGSIF66rUFI5Ik89737JO/y88Ou6FFToRL3XoBFIt0yWtoLx8?=
 =?us-ascii?Q?8Zp4SVzaYhBismrLCQEP1ckRaZ1xWnKejd4z/r6CmV+KnWU7yRvLcvxHOhaF?=
 =?us-ascii?Q?mD1265XStw5+KXZ3FcAFWqeLY6OdOnHw9XK8jL+kI3zGWWZFHUW13WSfBtPc?=
 =?us-ascii?Q?HZyhkxLeNtMFstzOatYrXjuSb7mYOjcMDpVKOo4TkaBjc61jv+85C3oGlyny?=
 =?us-ascii?Q?uLQSxFSUeWxQY2Z6CoA5FhvACIGH6XYh9QPLQ7tLm4xTIoEpFRRn7TxE8J8S?=
 =?us-ascii?Q?Zga0w5tdla8rXWTuPwLj/+oL68N9sSohs1AVSgBpGl6shyIYKeYMczcWWjpf?=
 =?us-ascii?Q?gFdb1oXHkzy349XLyb7/P4Zl34QpR8GE94DII5E498Kk2xgKuUlBIYa9/DUN?=
 =?us-ascii?Q?F/gBuwiOiZQyfOQqvVWrh4SZ4HeXVFwT97ZKIubI6H5NKVJ0nzbeadpTftf2?=
 =?us-ascii?Q?JLAMwPbSCR01iwbw6w6ubmBqv6AHMNkaXGqjOUqo1p7W/gb4AOUrBEyxxwxM?=
 =?us-ascii?Q?D+31RaFA+HeXm+wB9qFMpL9XEgGSseA6d7sBz4sfRKA/43JygfXGLZ65IGNB?=
 =?us-ascii?Q?qj84vNOIX1ZxAj0y1go4tX7tR47/Uj5zXfDMePdSt6wUEkoWmiLFHh2zwpPx?=
 =?us-ascii?Q?S8iHAHC9cLk8BMu4BzsnP7orbYQJcI7RQhMYS9ZwSjU5oyuyraFX2ps3aIKd?=
 =?us-ascii?Q?gYwCkZdpzUizRXxbGnR/q2hCGiASYVhSNrdLK5/ohfM9LWEsi/MscoD6VeZ7?=
 =?us-ascii?Q?v+2zYRPhEz/ZFfw8VwPr9Gyy0rJUef09se3IFnjfKDAFPbhDQRUoOjv6SAC5?=
 =?us-ascii?Q?5QvL0mdbE61uTsEy2UzP4NpF7DLMRQWZFguYU3PBphjIwhHPECfM9efzm53s?=
 =?us-ascii?Q?v+2SC5xbeq8nj6umOGZ2CcFn/qQEjPiOkk6mF3vC6eXT9rHE36HrQsgCF/gI?=
 =?us-ascii?Q?SNNQCcq9DUOO8ZDf19nBL4U6h3pCDWXOyt+vu43Op1tI1LBkx2+qsB4CoHa0?=
 =?us-ascii?Q?Wbww+E6aPS3ljau0xTW00ez6I1nsUoHud1Z27o1MZHUGcq/stZzS8liDgX6t?=
 =?us-ascii?Q?1nA9Xyj86K0/lkmsGLhYGKHpgvs3qCHgZms//M2XcYbrsWiZJEp4abVyCi3z?=
 =?us-ascii?Q?u+snfaYEaOGuU/cBW2aJc/NXRkP0Sb1QXbZnLCaX3yXTP9Gv7POCgyFyVyqj?=
 =?us-ascii?Q?9N2I7vpHRQ6i1JNK+KioENRtKhudHbDARCZvVmdi47TKZobIuENzAj37wWpy?=
 =?us-ascii?Q?FDx7Y/ZLmBNGCUlZx/C04X6Pu1xxFiy4m6PMAoP2tYkmOwFmEAAg4lIBV3M3?=
 =?us-ascii?Q?H5Z7XSt8amoqOPD3uLm+p3dCjjJbP2SKk5HVoDzomHKO1WsZ7ybBrotmNVUJ?=
 =?us-ascii?Q?KBv3UuvOgymoWvm+Uy0OdW1Hr77qDqT07sbO?=
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)(14060799003)(82310400026)(35042699022)(376014)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 09:31:28.3034
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fb38d49-76cb-44c8-0ea8-08ddeeba7cf2
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:
	AM2PEPF0001C70A.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11319

Reviewed-by: Yeoreum Yun 

On Mon, Sep 08, 2025 at 08:39:31AM +0100, Kevin Brodsky wrote:
> We now support nested lazy_mmu sections on all architectures
> implementing the API. Update the API comment accordingly.
>
> Acked-by: Mike Rapoport (Microsoft) 
> Signed-off-by: Kevin Brodsky 
> ---
>  include/linux/pgtable.h | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index df0eb898b3fc..85cd1fdb914f 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -228,8 +228,18 @@ static inline int pmd_dirty(pmd_t pmd)
>   * 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.
> + * held, but for kernel PTE updates, no lock is held). The mode cannot be used
> + * in interrupt context.
> + *
> + * Calls may be nested: an arch_{enter,leave}_lazy_mmu_mode() pair may be called
> + * while the lazy MMU mode has already been enabled. An implementation should
> + * handle this using the state returned by enter() and taken by the matching
> + * leave() call; the LAZY_MMU_{DEFAULT,NESTED} flags can be used to indicate
> + * whether this enter/leave pair is nested inside another or not. (It is up to
> + * the implementation to track whether the lazy MMU mode is enabled at any point
> + * in time.) The expectation is that leave() will flush any batched state
> + * unconditionally, but only leave the lazy MMU mode if the passed state is not
> + * LAZY_MMU_NESTED.
>   */
>  #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>  typedef int lazy_mmu_state_t;
> --
> 2.47.0
>
>

--
Sincerely,
Yeoreum Yun


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:42:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:42:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1114987.1461761 (Exim 4.92)
	(envelope-from )
	id 1uvYNt-0001mu-BY; Mon, 08 Sep 2025 09:42:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1114987.1461761; Mon, 08 Sep 2025 09: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 1uvYNt-0001mn-7f; Mon, 08 Sep 2025 09:42:01 +0000
Received: by outflank-mailman (input) for mailman id 1114987;
 Mon, 08 Sep 2025 09:41: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 1uvYNr-0001mh-Mt
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:41:59 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0fbbf0d6-8c98-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 11:41:57 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-62221568039so3265952a12.0
 for ; Mon, 08 Sep 2025 02:41: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
 4fb4d7f45d1cf-622ac41b1d6sm5447520a12.32.2025.09.08.02.41.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 02:41: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: 0fbbf0d6-8c98-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757324517; x=1757929317; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YdCnBPWj7Y1Qdy/d2R6kjaN8gf65DHmCfaEnsK0LXzs=;
        b=PTku73G7LIqpIlt28/4SeuWX9H+cxw2KpqoJoTrUaQmK+RyymTdxBmBI8WLjHrQhse
         gS44BVTydPFLAl5VS86BxVEBXUNh8BEQ0Hko4xJGNZMagI9lRezUD7yBRKmn3ohFS+is
         VdYz6MpxbEfrqHEPW2PADASnvBJmPkh/8dLLqmaQSgS6p5cMpt/IeOyJVy1XSld3lYij
         V4frSN3T/kiePKepVJYJJFf4mlFybhe/lNnVp2j/BxULB0G8B2DiBkXgSnxDwDC+9x3A
         zISQJ+iFCda68EixfpHNp9i/wED2FmFx/4HwMYP08vxMbwMSRb2Koq7YIV4Kt5bTkJzw
         6wvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757324517; x=1757929317;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YdCnBPWj7Y1Qdy/d2R6kjaN8gf65DHmCfaEnsK0LXzs=;
        b=peexjVyVT7iqykcsTIegeTjmAtINaFrzKLgr+k17eAVzgZ87KvuKe4ATxkVLI/Vv6U
         XoUJGbJ2fD7PRjxbSTzsJ3b5Jx8oWOQvP5Xd98hqYVo8nPe417LKBwL71MG4zg3dJKLl
         xuNsEjDPMlMhPuAYTNF/X7QlLOxzT5DPcJxacYPuTvu3el+bENM2jULLRfLn0lVSitUX
         qdWzCsL+E++qJdoTzlm7qGd0Acl9/8uQ/RoqGUP/cClghLn5IgBzwbPFJQ7cKPXemExr
         Wm9jAiD0bIjud+a42S+Xa/+nqE/Pj6+l8D1+/ZPFeRGueoUQ3L1szNjs7g35vzVmAdHJ
         pRoA==
X-Forwarded-Encrypted: i=1; AJvYcCX6wLuw16/wDU5/GGh+k0G5Cmfiu8MX0hCYC6TJyZd84MDm9n1/iruV6Fe8HcPQ3N6Xbx0AbwIurB4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzCS58W/+KIXUTa0/oLaBsenbMHRzUKaG3aYKJJjiuzjPjKTwQ
	cryl+M8cGRlo0aGVkjI5JPdZFXybdyZ1rBzvdAye+nh2UAwz0sbsj5+N8mYrEOcxVg==
X-Gm-Gg: ASbGncuHnOwuQ5kJBYdJA/QCVNchSn3E9OtphJeK/mPn3UZD918hIP+d5trLdVSeuZp
	OUthL7j8iD3/8w31NeaSxnymOtGBtuOWqvhyKs13ZrRx9ztMS2MvzXhtWEARR6Ml0empmNZRtIO
	AudprX6dyyXONMw31xTN39wdRHBdVhhYMyl2NokU2hX446gFotqwkIpQr/3dqJH/mbCirf8GyuD
	KmxZWXx6JRke9yd8zeTFYl6ffkrrl7CAAqKcKTJq2XfKXTKqqiBchiCTTCBd0cychFnzFAJTgGA
	+EgZAvmW4u6/IhzPndK5dkpRlXyyvPAGD6jEDh+QTHNDtqKPYa78r19Wb4eBOZQIBjwb5ib3/zj
	pHptpsDDEN3tWahk6SduFGKZP1V8n6v/QW1Q44tYtqc2/BAzqTRL7zr57AO00WGgEyEllbRXs8v
	FNxYguJ+c=
X-Google-Smtp-Source: AGHT+IFt9noQxm44zpfwQ0pHuUqSK720WXSiFzCBmJ8n2/GZQ4EMSgk5rBbK38L11/h10Cmm5Uci7w==
X-Received: by 2002:a05:6402:2553:b0:61e:d3d8:9377 with SMTP id 4fb4d7f45d1cf-62373df688emr6400692a12.9.1757324517112;
        Mon, 08 Sep 2025 02:41:57 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 11:41:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
To: Gerald Elder-Vass 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.09.2025 11:35, Gerald Elder-Vass wrote:
>>> +          size == 1 && data == 0) )
>>
>> ... any reason it's literal 1 here?
> 
> The size variable is also used as output from GetVariable and we should
> verify that the size of the returned data is as expected, it is simply one
> byte so probably not worth defining any macros to make it clearer

I don't understand this reply. Why would the initializer of the variable
use one thing (sizeof()) and the checking of the variable another (literal
1)? Even consistently using 1 would already be better imo; consistently
using sizeof() is what I think would be best.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:44:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:44:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115002.1461770 (Exim 4.92)
	(envelope-from )
	id 1uvYQ7-0002Np-RJ; Mon, 08 Sep 2025 09:44:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115002.1461770; Mon, 08 Sep 2025 09:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvYQ7-0002Ni-OK; Mon, 08 Sep 2025 09:44:19 +0000
Received: by outflank-mailman (input) for mailman id 1115002;
 Mon, 08 Sep 2025 09:44: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 1uvYQ6-0002Nc-Ml
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:44:18 +0000
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com
 [2607:f8b0:4864:20::b34])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 62ca0b44-8c98-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 11:44:17 +0200 (CEST)
Received: by mail-yb1-xb34.google.com with SMTP id
 3f1490d57ef6-e9d6cb1df67so3098687276.1
 for ; Mon, 08 Sep 2025 02:44: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: 62ca0b44-8c98-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757324656; x=1757929456; 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=LRv9xXnqBppOLm6ep710A8MEaXq8DwLigxo6yffIagA=;
        b=FYIN4oj6nBa2rtTPxszmKXBUJpXd+rM//9nj+bujjWygPf+wTSpIWUDrCjvlHOrt0d
         blmAKKCkAYORcG5xxh/5lzCZ+gBql4ST3mHATV/jFBIDsdJ7+N0yr+QEd3/eiskMskVd
         ZY4fl5uoHPw2QZuSY4FH0KSos4yQUybiPERyA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757324656; x=1757929456;
        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=LRv9xXnqBppOLm6ep710A8MEaXq8DwLigxo6yffIagA=;
        b=uiq+wvVc9FsRhb6ZI3fu/PxacD/GaUYiJi96eMqXYN/iA/umOj6+ykjxDlodguQS57
         OyiyzH5yA/Vk3QgKSgRXCKv2uqwoqgel8CsmaRnH4wj59FQV2r4xSgPqQR18h+BAkHI3
         Eh7LUlVZqlq4o2a23pq96k2PwZdsOfOHXXYSsYz/e811A13wFqIcQr26On+bvOi7Rm40
         Op3xDXWSwHjPzIOA5Fb+ARUHxiNH4A4xcQWb2ygq7s+P26Eut1WPle3k5Cr7Ycow73RM
         8pRfz697fbJNMxS7nogqZFrIrFVkDsVlmVFBSSwnqbQKgyOSLitzVEZYBE4MooD+dw7H
         yaHA==
X-Forwarded-Encrypted: i=1; AJvYcCUonfLgO7i3+Xz/aB1YnA20sHGAj2XVQ3ALEBVmnSAydxK3dgf3QbEchqXRfrY3iVOO9fpL4lHtAbk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyE/PVWcoVTD58nBDXNdhsoxNRVvhs41vSWlo2/NIUvDpsXuMPN
	fTDKZQLGUXKxlzqc1NQq+dKo+y3XKIpIfJQbiTSobYGk845OY19WgWO9qoSx1GabRf6KYRdV+yL
	mKQgiYVeDJKhUlnlVUYI47IOjOGnHqwspJKttBopHjg==
X-Gm-Gg: ASbGncsky9XCLeti0q9HsZbJZ9ER6dUj3ra1b2XJakalo9htGddnPYXN0pxcg33hvzp
	w5gp6jmGlP4d3/izAqUbQglLZt9UyUABwJZ8he3CaSEWiutGrEXzmAfVot5MvztRvGq8niev6ko
	ujq3QKFeVJ+e3V/mod6rg2FFF+XeoA/MwHZSGXbPF/y4PS4jM7Ir8AQOOjFAgW/6lgbjxXJH56J
	fYgA32m7KlXXfaU
X-Google-Smtp-Source: AGHT+IHt5NAdOp8KILqDzaClGtMsAd/9fJPpEpYr7mqS0v+/tXhrR6jL1Aw9KyX6kOPWl5huP0DrJQhgIrlV3vl7Lhg=
X-Received: by 2002:a05:6902:102a:b0:e93:4ce0:c1e4 with SMTP id
 3f1490d57ef6-e9f6798ffa6mr6157579276.30.1757324656436; Mon, 08 Sep 2025
 02:44:16 -0700 (PDT)
MIME-Version: 1.0
References: 
 <93ffff66c08d05bc2d912be1831954911e17a27c.1757071716.git.gerald.elder-vass@cloud.com>
 <6647009f-a1f8-4cf0-923a-c04f0a59106a@suse.com>
In-Reply-To: <6647009f-a1f8-4cf0-923a-c04f0a59106a@suse.com>
From: Gerald Elder-Vass 
Date: Mon, 8 Sep 2025 10:44:05 +0100
X-Gm-Features: AS18NWDODnBlrUOf1ACCnkkPhhPutlitMCUN0sKBZWoz8pfFeKfZtgNbxw1zWvM
Message-ID: 
Subject: Re: [PATCH v4 2/2] efi: Support using Shim's LoadImage protocol
To: Jan Beulich 
Cc: Kevin Lampis , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	"Daniel P. Smith" , Andrew Cooper , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Xen-devel 
Content-Type: multipart/alternative; boundary="000000000000e763d9063e4707b3"

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

>As already said on an earlier version, the use of !EFI_ERROR() here is a
>behavioral change from ...
>
>> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE
ImageHandle,
>>       * device tree through the efi_check_dt_boot function, in this stag=
e
>>       * 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
EFI_SUCCESS )
>
>... checking for EFI_SUCCESS alone here. There's also nothing in the
>description justifying the change. (See the various EFI_WARN_* that exist.=
)

You're correct! The EFI_WARN_* responses should all be treated as failures,
I'll revert that particular change in the patch series

*Gerald Elder-Vass*
Senior Software Engineer

XenServer
Cambridge, UK


On Mon, Sep 8, 2025 at 9:56=E2=80=AFAM Jan Beulich  wrot=
e:

> On 05.09.2025 14:10, Gerald Elder-Vass wrote:
> > @@ -1047,6 +1056,46 @@ static UINTN __init
> efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> >      return gop_mode;
> >  }
> >
> > +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> > +{
> > +    static EFI_GUID __initdata shim_image_guid =3D SHIM_IMAGE_LOADER_G=
UID;
> > +    static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_G=
UID;
> > +    SHIM_IMAGE_LOADER *shim_loader;
> > +    EFI_HANDLE loaded_kernel;
> > +    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> > +    EFI_STATUS status;
> > +    bool verified =3D false;
> > +
> > +    /* Look for LoadImage first */
> > +    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
> > +                                           (void **)&shim_loader)) )
> > +    {
> > +        status =3D shim_loader->LoadImage(false, ImageHandle, NULL,
> > +                                        (void *)kernel.ptr, kernel.siz=
e,
> > +                                        &loaded_kernel);
> > +        if ( !EFI_ERROR(status) )
> > +            verified =3D true;
> > +
> > +        /* LoadImage performed verification, now clean up with
> UnloadImage */
> > +        shim_loader->UnloadImage(loaded_kernel);
> > +    }
> > +
> > +    /* else fall back to Shim Lock */
> > +    if ( !verified &&
> > +         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> > +                                           (void **)&shim_lock)) &&
> > +         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
>
> As already said on an earlier version, the use of !EFI_ERROR() here is a
> behavioral change from ...
>
> > @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE
> ImageHandle,
> >       * device tree through the efi_check_dt_boot function, in this sta=
ge
> >       * 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
> EFI_SUCCESS )
>
> ... checking for EFI_SUCCESS alone here. There's also nothing in the
> description justifying the change. (See the various EFI_WARN_* that exist=
.)
>
> Jan
>

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


>As already said on an earlier version, the use of=
 !EFI_ERROR() here is a
>behavioral change from ...
>
=
>> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_H=
ANDLE ImageHandle,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0* device tree thro=
ugh the efi_check_dt_boot function, in this stage

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0* verify it.

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0*/
>> -=C2=A0 =C2=A0 if ( kerne=
l.ptr &&
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!kernel_ver=
ified &&

>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(efi_bs->LocatePro=
tocol(&shim_lock_guid, NULL,
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(void **)&shim_lock=
)) &&
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(status =3D sh=
im_lock->Verify(kernel.ptr, kernel.size)) !=3D EFI_SUCCESS )
>
=
>... checking for EFI_SUCCESS alone here. There's also nothin=
g in the
>description justifying the change. (See the various EFI_WAR=
N_* that exist.)

<=
div>You're correct! The EFI_WARN_* responses should all be treated as f=
ailures, I'll revert that particular change in the patch series

Gerald Elder-Vass<=
/div>
Senior Software Engineer

XenServer
=

Cambridge, UK


On Mon, Sep 8, 2025 at 9:56=
=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wrote:
On 05.09.2025 14:10, Gerald Elder-Vass wrote:

> @@ -1047,6 +1056,46 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPH=
ICS_OUTPUT_PROTOCOL *gop,

>=C2=A0 =C2=A0 =C2=A0 return gop_mode;

>=C2=A0 }

>=C2=A0 

> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)

> +{

> +=C2=A0 =C2=A0 static EFI_GUID __initdata shim_image_guid =3D SHIM_IMA=
GE_LOADER_GUID;

> +=C2=A0 =C2=A0 static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK=
_PROTOCOL_GUID;

> +=C2=A0 =C2=A0 SHIM_IMAGE_LOADER *shim_loader;

> +=C2=A0 =C2=A0 EFI_HANDLE loaded_kernel;

> +=C2=A0 =C2=A0 EFI_SHIM_LOCK_PROTOCOL *shim_lock;

> +=C2=A0 =C2=A0 EFI_STATUS status;

> +=C2=A0 =C2=A0 bool verified =3D false;

> +

> +=C2=A0 =C2=A0 /* Look for LoadImage first */

> +=C2=A0 =C2=A0 if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_ima=
ge_guid, NULL,

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(void **)&shim_loader)) )

> +=C2=A0 =C2=A0 {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 status =3D shim_loader->LoadImage(fals=
e, ImageHandle, NULL,

> +=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 (voi=
d *)kernel.ptr, kernel.size,

> +=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 &=
;loaded_kernel);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !EFI_ERROR(status) )

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 verified =3D true;

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* LoadImage performed verification, now =
clean up with UnloadImage */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 shim_loader->UnloadImage(loaded_kernel=
);

> +=C2=A0 =C2=A0 }

> +

> +=C2=A0 =C2=A0 /* else fall back to Shim Lock */

> +=C2=A0 =C2=A0 if ( !verified &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(efi_bs->LocateProtoco=
l(&shim_lock_guid, NULL,

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(void **)&shim_lock)) &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(shim_lock->Verify(ker=
nel.ptr, kernel.size)) )



As already said on an earlier version, the use of !EFI_ERROR() here is a
behavioral change from ...



> @@ -1591,12 +1638,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDL=
E ImageHandle,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* device tree through the efi_check_dt_boot =
function, in this stage

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* verify it.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*/

> -=C2=A0 =C2=A0 if ( kernel.ptr &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!kernel_verified &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!EFI_ERROR(efi_bs->LocateProtoco=
l(&shim_lock_guid, NULL,

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(void **)&shim_lock)) &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(status =3D shim_lock->Verify(ke=
rnel.ptr, kernel.size)) !=3D EFI_SUCCESS )



... checking for EFI_SUCCESS alone here. There's also nothing in the
description justifying the change. (See the various EFI_WARN_* that exist.)=




Jan




--000000000000e763d9063e4707b3--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:45:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:45:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115015.1461780 (Exim 4.92)
	(envelope-from )
	id 1uvYRa-0002tI-4z; Mon, 08 Sep 2025 09:45:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115015.1461780; Mon, 08 Sep 2025 09:45: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 1uvYRa-0002tB-21; Mon, 08 Sep 2025 09:45:50 +0000
Received: by outflank-mailman (input) for mailman id 1115015;
 Mon, 08 Sep 2025 09:45:49 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvYRZ-0002t2-9W
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:45:49 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvYRY-0000is-0j;
 Mon, 08 Sep 2025 09:45:48 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvYRY-0001He-0E;
 Mon, 08 Sep 2025 09:45:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=X9oAsv6G13ucz5Dw61cD/LKtcJhmND9b2ShsybDBP0Q=; b=r/1VMfemFGv+3dWdLI/HJFWSXW
	8YTgiHqCm8/c/mbxQ87ERHmsYI7YWJvRUDRE6Up1JiHn5CrDSpzSdF+aoDSlYa0zQ5LOq1xNyoJt1
	VYULqF0vAdKcW+rOdrbrWXU+u5Hof1miKSu7NePh0hX0YKkNo4hfaJIeCD5Me1TWvH/Q=;
From: dmukhin@xen.org
Date: Mon, 8 Sep 2025 02:45:46 -0700
To: Mykola Kvach 
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 01/15] emul/vuart: introduce framework for UART
 emulators
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-2-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, Sep 08, 2025 at 11:29:03AM +0300, Mykola Kvach wrote:
> On Sat, Sep 6, 2025 at 2:27 AM  wrote:
[..]
> > +++ b/xen/common/emul/vuart/Kconfig
> > @@ -0,0 +1,6 @@
> > +config VUART_FRAMEWORK
> > +       bool
> 
> If VUART_FRAMEWORK has no dependencies, it can be enabled on any
> architecture. For example, I tried enabling it on arm64 and the build
> fails:
> 
>   ./include/xen/vuart.h:26:8: error: redefinition of ‘struct vuart’
> 
> Should this config be restricted (e.g. "depends on X86") or the code
> adjusted to handle non-x86 architectures properly?

Yes, missed that; the code is for x86 only for now.
`struct vuart` on Arm corresponds to simple MMIO-based UART emulator for
hwdom's earlyprintk.

Arm part is pending:
  https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/

Most of the feedback resolved locally, but I need to wait for the other series to land

[..]
> > +static const struct vuart_emulator *
> > +vuart_match_by_compatible(const struct domain *d, const char *compat)
> > +{
> > +    const struct vuart_emulator *emulator;
> > +
> > +    for_each_emulator(emulator)
> > +        if ( emulator->compatible &&
> > +             !strncmp(compat, emulator->compatible,
> > +                      strlen(emulator->compatible)) )
> > +            return emulator;
> > +
> > +    return NULL;
> > +}
> > +
> > +const static struct vuart *
> > +vuart_find_by_console_permission(const struct domain *d)
> 
> During the first review of this patch I thought you planned to add a
> searching procedure into this and the next function in one of the later
> commits. However, looking at the series now, it seems these functions
> remain unchanged and don’t actually perform any searching.
> 
> Do you think the current names are accurate, or would it make sense to
> rename them to better reflect their purpose?

Arm has two vUART emulators enabled by default, so there will be at least two
vUARTs and some search in vuart.c.

I scoped x86 portion of the change into the current series, Arm is to follow,
since I have pending series to plumb vpl011 (i.e. SBSA) and hwdom vuart (i.e.
early dtuart) into that new framework. There will be some adjustments in
vuart.c


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:50:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:50:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115031.1461791 (Exim 4.92)
	(envelope-from )
	id 1uvYVm-0004mE-Lw; Mon, 08 Sep 2025 09:50:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115031.1461791; Mon, 08 Sep 2025 09:50: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 1uvYVm-0004m7-IH; Mon, 08 Sep 2025 09:50:10 +0000
Received: by outflank-mailman (input) for mailman id 1115031;
 Mon, 08 Sep 2025 09:50: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 1uvYVl-0004m1-33
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:50:09 +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 337ccff3-8c99-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 11:50:07 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45cb659e858so28715445e9.2
 for ; Mon, 08 Sep 2025 02:50:07 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45b6f30fe02sm506065895e9.18.2025.09.08.02.50.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 02:50: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: 337ccff3-8c99-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757325006; x=1757929806; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vAbXrVFx1N9qzSUrDKSkA07ICdV0MWA216vF/dShUCw=;
        b=lGVIzy4bDxwXID6mdHvaHINe5elRGSU8yTkGRO/WLaO8W1k26s3FRd1ISWNH99+bLd
         Z3GQA5qrafNn+8vb83GIP3BFzla6urE1CN2CQgFWXpmOAnytQWs3Qd2kB081jfatV5tK
         nh1QVAisB+ufb4zKM+lPlJ8l8LK7TXEMj4jj0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757325006; x=1757929806;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vAbXrVFx1N9qzSUrDKSkA07ICdV0MWA216vF/dShUCw=;
        b=xFfXwQgVw6X1f+mzSbxUwCXQhOIwbIesLC8m5Fl9He8GE1rW7zisqybWPYlbDgiYnw
         XJLf0t4kQtIC3ZTslo1pKEWM7p8cvvFoZhsF90aMNHEyDjiV8fTKmfBIT0I62wGeeaHH
         acshnnrKQNs9IW/aIisb/LAmbMSm9575UX1OGl5R9gCWdvklRc40mVJXhOnSuhK1lT9x
         CtzPpp/mRGjxfrBhAThlg6u0wASVnq+o3R2k6F3DJDMBKmfUnrOlnzCBzJcbx3fuDAED
         PeQMRVURTZ28HUQCtYLFX3uVu+tzyY3VD1AMnFx0aZbwDSZZ0zfM0YReMAbC6yHRhnQv
         PJJg==
X-Forwarded-Encrypted: i=1; AJvYcCWoneTVLhPqrFVL063AP18TW6/Y9howkrlLENKH3JHmX1A1lINSdDUkUztjGC2Ch9SYMv8pF4ADAM4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJNdrHHIHnlFKhQO5EsU9R5GOfomdEgmyhN8MIvsrOfq25ItKi
	0Ok57RMq1W6nRQ0leYLRDXNDsaQqmZ+FBaLRpPkurGsqVJ0++zt2kzx8lbyfOLFIWmc=
X-Gm-Gg: ASbGncsNWcTKad8WwfJiz2iGZm+TRTgH2FJ6lrfb/m+Db2Oz/D6zvBMERzJGOTXA+mQ
	S7lAzu8GLCrUn4A+/voog+0sYEb1kMt9WVotMzwThzLntkPQgzSvreCCoJ56UuOwzCD410ZckY1
	fQisboXLT8wA2eNMNDhGEI3qySR8Jj8QTq+fyS34prt1m8rHB2ZsPoF5bSppiq06CE3qxlSfjXH
	plV+i05G6XSrnQdHv7D2gHoz2VrM+CW4cNdJrV/UdMRk44cgs408TZhM3PQCQ1i6a95QB/lyvfU
	f0PwcE3UAuBAyX6zz4kRHwFq/Kz5bSfU4y4f5WOex2Rmpz5+FMWpH1r7593YzeuoW5p3hGr7ic4
	Uvi1vjtyZYN4D4tEzys9/VOi5BPR1BLExBlT1gK7N6clXMugrjks0HnLi9rpBLt5CqHPykPINHY
	hbPDI=
X-Google-Smtp-Source: AGHT+IHmfmaKU0Wbd+gpu/74Lh8oQIiBjUi1YStCv3+qzRLav0Agz3OedRTsrnu4ot0YiFFll8u2Ag==
X-Received: by 2002:a05:600c:4453:b0:45b:9c37:6c92 with SMTP id 5b1f17b1804b1-45dddef02f7mr60014535e9.31.1757325006561;
        Mon, 08 Sep 2025 02:50:06 -0700 (PDT)
Message-ID: <4b651048-10f2-4184-bd6a-e6d7a5b64565@citrix.com>
Date: Mon, 8 Sep 2025 10:50:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] symbols: fix xensyms_read() hitting the final "end"
 symbol
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 08/09/2025 10:22 am, Jan Beulich wrote:
> A new "no (more) symbol" path there was lacking a necessary unlock.
>
> Fixes: d3b637fba31b ("symbols: arrange to know where functions end")
> Coverity ID: 1665212
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:53:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:53:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115041.1461801 (Exim 4.92)
	(envelope-from )
	id 1uvYYg-0005Ks-1u; Mon, 08 Sep 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 1115041.1461801; Mon, 08 Sep 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 1uvYYf-0005Kl-Ve; Mon, 08 Sep 2025 09:53:09 +0000
Received: by outflank-mailman (input) for mailman id 1115041;
 Mon, 08 Sep 2025 09:53: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 1uvYYe-0005Kf-UX
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:53:09 +0000
Received: from fout-b5-smtp.messagingengine.com
 (fout-b5-smtp.messagingengine.com [202.12.124.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c0ed4e3-8c99-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 11:53:03 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfout.stl.internal (Postfix) with ESMTP id ADD0A1D00068;
 Mon,  8 Sep 2025 05:53:01 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Mon, 08 Sep 2025 05:53:02 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 8 Sep 2025 05:52: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: 9c0ed4e3-8c99-11f0-9809-7dc792cee155
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=1757325181;
	 x=1757411581; bh=cR7RUvZMenD1jeAwc6PFFl10oTT3YqXfPHHL/bwY6t8=; b=
	efJm/QJUyTdh+au/mDtGCVin62X+OTKoszpfRer1aBaNgor2xCGCYSUP3HaazHup
	0buCiAQhszuqXxgONHbemIkorg/HUvQVqPrcNFKeheVFeZj+oaJg/tNjxiQDwoh0
	z1Fe4w4lijxVoFyZVkp1mS3fgz6Vsb9ALCk1fTGHTJXMT9O/KfCAT9hpFausnOuw
	r3FMwWp+KpuEMDK7h7JK5gc2GJDIpFC6Oh2M8FtFPLv9HTpA/jWrlcSFzvl0yqIS
	XYUWt+UW+d0gMGxl68iOnxOpMd5ra81hmphUotPjcYQo2iuxWRAOxpVmC8VUHix0
	XWrpf0WkvynaAixeA5nIcg==
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=
	1757325181; x=1757411581; bh=cR7RUvZMenD1jeAwc6PFFl10oTT3YqXfPHH
	L/bwY6t8=; b=g58cze0DMI7Uk6qQFPssGI3mUiCmF0yUCiFIOtfZCPztQMY0v9S
	grycycPp3995DINOPqqc4vJYdcI/t44LjYBjcGUlAmZ1OBrj3jk5HGMrbGB3CxJM
	eJb6qgmi1+qKK4g+5PQqFKMcRYCMx31F2rFBvpvOwRDHk1Z6roLr0IolV9fd3T/j
	ZWDphALbVu+Qa7lHVhx4Fod0672H7X8MpKvxEvjm2+D0Fh2tT0pLCC9y2MBBPWif
	mPc5xBJBoq/faMgzkJsPCinjg1c6VT/A4898PgaTWyIXOAmzdQTUnxhmASBhOD7w
	hth0ft0Nv546dTjsgpxJmviALQ0QmXhFzbw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddujedvvdcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeduuddpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho
    mhdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhssegtlhhouhgurdgtoh
    hmpdhrtghpthhtoheprhhoshhsrdhlrghgvghrfigrlhhlsegtihhtrhhigidrtghomhdp
    rhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdrtghomh
    dprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhr
    tghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtph
    htthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhopehjuhhl
    ihgvnhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigi
    drtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 8 Sep 2025 11:52:57 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Gerald Elder-Vass ,
	Ross Lagerwall ,
	"Daniel P. Smith" ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
Message-ID: 
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="WArpHYyzDXvmIVQj"
Content-Disposition: inline
In-Reply-To: 


--WArpHYyzDXvmIVQj
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Sep 2025 11:52:57 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Gerald Elder-Vass ,
	Ross Lagerwall ,
	"Daniel P. Smith" ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled

On Mon, Sep 08, 2025 at 11:41:55AM +0200, Jan Beulich wrote:
> On 08.09.2025 11:35, Gerald Elder-Vass wrote:
> >>> +          size =3D=3D 1 && data =3D=3D 0) )
> >>
> >> ... any reason it's literal 1 here?
> >=20
> > The size variable is also used as output from GetVariable and we should
> > verify that the size of the returned data is as expected, it is simply =
one
> > byte so probably not worth defining any macros to make it clearer
>=20
> I don't understand this reply. Why would the initializer of the variable
> use one thing (sizeof()) and the checking of the variable another (literal
> 1)? Even consistently using 1 would already be better imo; consistently
> using sizeof() is what I think would be best.

'size' as input value is the allocated size of the data parameter, so
makes sense to be sizeof(data). IOW, 'size' as the input value comes
=66rom the size of the 'data' variable, while the output value check comes
=66rom UEFI spec. While the size of the 'data' variable should match the
spec, IMO changing its type (to a wider one) should not break the
behavior here.

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmi+p3kACgkQ24/THMrX
1ywVqAf/dxDyv8lw6FnoT5OcEwtuInoXnylyxZMhsFu/XF554KvnGTZusr6e2mH8
nN7ADPdxVcKMIj1nudKe6iEFA4RmxOeMdP622+qlsC9oLoRCsPi5XrgQzqTGgYBh
KQZJrDMbVkCtfPbNjdKDneZiHluY/5oY5Dh4Vhq6uy1qZsxUoAS2NCv+uNKTRKZG
KnzWWiiP0DVehe1+JkYNom19rIFng1l7nK3AeKHKATmB65No5SzOdehbWC6hauK8
XWji6z0s1mKZaUdStfKc6M8R+Lu984xsO17SBeCdAZcIvrGWSUeORsWBq43AsFmF
/qNJrdL/QvdigKjjLiTF3REoDBN9ZA==
=BNds
-----END PGP SIGNATURE-----

--WArpHYyzDXvmIVQj--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 09:59:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 09:59:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115055.1461811 (Exim 4.92)
	(envelope-from )
	id 1uvYef-0006Vi-R1; Mon, 08 Sep 2025 09:59:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115055.1461811; Mon, 08 Sep 2025 09: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 1uvYef-0006Vb-OU; Mon, 08 Sep 2025 09:59:21 +0000
Received: by outflank-mailman (input) for mailman id 1115055;
 Mon, 08 Sep 2025 09:59:20 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvYee-0006VV-E4
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 09:59:20 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvYed-0000zy-1Q;
 Mon, 08 Sep 2025 09:59:19 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvYed-0001pP-1M;
 Mon, 08 Sep 2025 09:59: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=ponBd/BvXf8SRYR0F16CgS3Bp6jEb5iKyZNyjPltp8o=; b=vdOXSidGM8JPSxwqpHms88wnmp
	AdBotisDuxRkTWH3RMScVtib1X0rJyOdK5ASSrNxinQGfH6hccVf8/imTndoduV+Odj2Pwxfd/SM1
	GX65re3qVuaXhut/ESwK8fuLuXJH9mJ7LU4s+calcY3EvPOhWHqtBZ2gmQO4rFfB/qUU=;
From: dmukhin@xen.org
Date: Mon, 8 Sep 2025 02:59:18 -0700
To: Mykola Kvach 
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 03/15] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>
 <20250905232715.440758-4-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, Sep 08, 2025 at 11:37:03AM +0300, Mykola Kvach wrote:
> > --- a/xen/common/emul/vuart/Kconfig
> > +++ b/xen/common/emul/vuart/Kconfig
> > @@ -3,4 +3,23 @@ config VUART_FRAMEWORK
> >
> >  menu "UART Emulation"
> >
> > +config VUART_NS16X50
> > +       bool "NS16550-compatible UART Emulator" if EXPERT
> > +       depends on X86 && HVM
> 
> Currently VUART_NS16X50 depends on X86, so the code is only
> usable on x86. Are there any plans to support this vUART on non-x86
> architectures (e.g. ARM, where some UARTs are also ns16550-compatible)?

The plan is to add MMIO-based implementation for x86 first.

> 
> If not, wouldn’t it be more appropriate to move the ns16x50-specific
> implementation into x86-specific directories instead of common?

There was discussion on that and the agreement is to move all vUARTs into
  common/emul/vuart

and start using common/emul as a placeholder for common emulation code,
including vPCI.


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 10:02:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 10:02:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115065.1461821 (Exim 4.92)
	(envelope-from )
	id 1uvYhN-000861-7K; Mon, 08 Sep 2025 10:02:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115065.1461821; Mon, 08 Sep 2025 10: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 1uvYhN-00085u-4k; Mon, 08 Sep 2025 10:02:09 +0000
Received: by outflank-mailman (input) for mailman id 1115065;
 Mon, 08 Sep 2025 10:02: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 1uvYhM-00085o-FP
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 10:02:08 +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 e0110cad-8c9a-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 12:02:06 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-622b4b14a75so4413567a12.1
 for ; Mon, 08 Sep 2025 03:02:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6248711bfe8sm4680231a12.20.2025.09.08.03.02.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 03:02: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: e0110cad-8c9a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757325725; x=1757930525; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ondTFiHWY2mZVcmZM7yDM+yK/Cw/QYhytB/lqUAJTAU=;
        b=cVQRxZVEfj7/tuloCrQAgttH94F0qmPPOdX/yzMf+dA1y+MQV50orhx6bgwbjxDzNW
         D4vYHF7OF8vypRV5+tL2vDAPldnVqvvA650fnQlMexlF7IO0J8/kbxt5TEE3XcETH/ze
         a5lvUi5R280ADHSebAuL8a3oth8rYw2hwD6zFOXJ4bcZhVhoj+am6au/wN46SjI5uKwI
         hXAg2dzRyfwoS2hyPcZ3fsUY5pPMvV4R9fT6rsiNmsHjvUbDiTGks/dBhfbxNtzF56+s
         QFmk6/sL/5P+0Zk08978t/fqcjDZ2IHyIuoMhbZyPXwFgNU+y0n0Pn1qZxvFkenxJPux
         msjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757325726; x=1757930526;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ondTFiHWY2mZVcmZM7yDM+yK/Cw/QYhytB/lqUAJTAU=;
        b=QEfgdkeVaUSPn65FB7r5xxxoJ/Q2WpQB27mQhNK83h6UFuvKszzNts7w6RtBDQm+N1
         XzRaRSERIu0HEUY6xJKUwWuJSpEWRFMKGIR20qhB/M2X0D5jMJC+RbZO5Yd1RCRIEqjX
         F/lRRtpbOBPPy2atFbUh8SCRy6sUBWyXLFD/utvSK3xy11Ey7GnP6FDZVvH+M6erljjy
         KonMPQSNG/S0pKHQbmw6DRBqxsOiju1yvBRT46/Rx/4ciRebgofxcakg6JzVDYcSrRzF
         vthDJ9xAuoVcikrGah+mrTSROMFBoDGz5/NMLpfK+9QB+u00ohiNWvZX8RM08uO8jD+O
         AfsQ==
X-Forwarded-Encrypted: i=1; AJvYcCXGJTM9WlQ77UA0pF7FfCFgTWhHPkXgsOFPTE+T1vGU8iternUMgD+gQDcoB7u+tI5CCguYfwa0w7U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6TIhddWqM7AQmqO+nk+I7e01I/oiLxRntGcuEsRf/SDFrspTl
	s89adEMX56wfGGA8eKu8WuHxhM5aU6rkCrNJx9JQDoD/EDf5jS/01Ok5eZ91CB41UVJafwjP5w6
	kAA0=
X-Gm-Gg: ASbGncu099fGLBf+mIbT89wOd3ON7qYQ3CT6ni51aEMI5qCNxgta+xIPDdJCJUUw8uO
	A4LqahFDEeO5l+gOaiV5QOyJ2BUS6kbTEDvgpJ4PKc+QxIANgPe1lSCYWIjsGiuXbhvl1SWbpmj
	6X3P4rCaKgi1Z8CpKNZ1PE0nVepY4p5f28tQ2bOq9djyvTECZejBxwwYRAWm+dOdWAfDTKL6+8X
	ybbMlTbixZXqZY7VCO8X1eJoLDn31mAvB4OW5sKdaJ7xmArmF6dKadsFDkDXMSjpuqg59a/+3ge
	ZQkwKLfpuI+U7IdFiV2gbOkFTCRMCt9Rj7kr82yu7kzs1TV43iqYZRBRg905ySnjnKAatC1GAav
	EzztItrOG9CBIqrGlT3rtm1Fin/IGidkwOAcl32fAm5dAd/x0siWJavysZ5LYfHBlO7VT3VkRJG
	aLo5Xox+o=
X-Google-Smtp-Source: AGHT+IHMQ5WdwKWqvhqrXAdoHEwjg2azK0ZTvwpC3hHoLPRipxOWdTBKT7gZpxZR9druekND9xCzkg==
X-Received: by 2002:a05:6402:3514:b0:628:f072:2f18 with SMTP id 4fb4d7f45d1cf-628f07235eemr2021763a12.3.1757325725210;
        Mon, 08 Sep 2025 03:02:05 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 12:02:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
To: "Penny, Zheng" 
Cc: "Andryuk, Jason" ,
 "xen-devel@lists.xenproject.org" 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@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

(re-adding the list)

On 05.09.2025 06:58, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, September 4, 2025 7:51 PM
>> To: Penny, Zheng ; Andryuk, Jason
>> 
>> Cc: Andrew Cooper ; Roger Pau Monné
>> ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct cpufreq_policy{}
>>
>> On 04.09.2025 08:35, Penny Zheng wrote:
>>> For cpus sharing one cpufreq domain, cpufreq_driver.init() is only
>>> invoked on the firstcpu, so current per-CPU hwp driver data struct
>>> hwp_drv_data{} actually fails to be allocated for cpus other than the
>>> first one. There is no need to make it per-CPU.
>>> We embed struct hwp_drv_data{} into struct cpufreq_policy{}, then cpus
>>> could share the hwp driver data allocated for the firstcpu, like the
>>> way they share struct cpufreq_policy{}. We also make it a union, with
>>> "hwp", and later "amd-cppc" as a sub-struct.
>>
>> And ACPI, as per my patch (which then will need re-basing).
>>
>>> Suggested-by: Jan Beulich 
>>
>> Not quite, this really is Reported-by: as it's a bug you fix, and in turn it also wants to
>> gain a Fixes: tag. This also will need backporting.
>>
>> It would also have been nice if you had Cc-ed Jason right away, seeing that this
>> code was all written by him.
>>
>>> @@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct
>> cpufreq_policy *policy,
>>>                                         unsigned int relation)  {
>>>      unsigned int cpu = policy->cpu;
>>> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
>>> +    struct hwp_drv_data *data = policy->u.hwp;
>>>      /* Zero everything to ensure reserved bits are zero... */
>>>      union hwp_request hwp_req = { .raw = 0 };
>>
>> Further down in this same function we have
>>
>>     on_selected_cpus(cpumask_of(cpu), hwp_write_request, policy, 1);
>>
>> That's similarly problematic when the CPU denoted by policy->cpu isn't online
>> anymore. (It's not quite clear whether all related issues would want fixing together,
>> or in multiple patches.)
> 
> Checking the logic in cpufreq_del_cpu(), once any processor in the
> domain gets offline, the governor will stop.

Yet with HWP and CPPC drivers being governor-less, how would that matter?

> That is to say, only all processors in the domain are online, cpufreq driver could still be effective. Which is also complies to the description in _PSD ACPI SPEC for "Num Processors" [1]:
> ```
> The number of processors belonging to the domain for this logical processor’s P-states. OSPM will not start performing power state transitions to a particular P-state until this number of processors belonging to the same domain have been detected and started.
> ```
> [1] https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html?highlight=cppc#pstatedependency-package-values
> 
> I know that AMD CPPC is obeying the _PSD dependency relation too, even if both CPPC Request register (ccd[15:0]_lthree0_core[7:0]_thread[1:0]; MSRC001_02B3) and CPPC Capability Register (_ccd[15:0]_lthree0_core[7:0]_thread[1:0]; MSRC001_02B0) is Per-thread MSR.
> I don't have the hardware to test "sharing" logic. All my platform says "HW_ALL" in _PSD.

Aiui that's not mandated by the CPU spec, though. Plus HW_ALL still doesn't say
anything about the scope/size of each domain.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 10:19:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 10:19:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115078.1461831 (Exim 4.92)
	(envelope-from )
	id 1uvYxs-00026X-Hk; Mon, 08 Sep 2025 10:19:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115078.1461831; Mon, 08 Sep 2025 10:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvYxs-00026Q-Ey; Mon, 08 Sep 2025 10:19:12 +0000
Received: by outflank-mailman (input) for mailman id 1115078;
 Mon, 08 Sep 2025 10:19: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 1uvYxr-00026K-JN
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 10:19:11 +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 426de74c-8c9d-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 12:19:10 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b04abcc1356so297430366b.0
 for ; Mon, 08 Sep 2025 03:19: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
 a640c23a62f3a-b04a87dfb42sm666639566b.106.2025.09.08.03.19.09
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 03:19: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: 426de74c-8c9d-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757326750; x=1757931550; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vqlIlLrREZy6vf5sB6Mz2Bo11MWdZx9Z2caIehqzh30=;
        b=Tas0FG6V/9Ud+HBn4ki3hclBHHGzR6Rk7gCtqTSJ0ewqX2D6riW7B8f3oYkpxALLV5
         0n7MsayVrY0rRcfs8fVL6ccB/sq+nbVo24HP0SEe2jtPpIr71utlGWJtqbzKmLjWR5eL
         wFJKptQaczWmiJ7zoIUbFaQnvBX01oEBdXxCSKx2kue+y5FuKsH45pld12dUFkUsGh9b
         iaa2qFODM0YKUJ+0WCHFUQh3hIRtM3VFJtyAqfMHebF1CTwTRjqAqxYjrg89KVedb5Da
         HC6+5JWeKF5IWLmtESR0m5u17QLWh/9s4NtefDi+b/a1Rb2Fx36iAlyl17cz07Js9PNg
         7DHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757326750; x=1757931550;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vqlIlLrREZy6vf5sB6Mz2Bo11MWdZx9Z2caIehqzh30=;
        b=LG05Vez/oRffHl67CGOed6+EOupTuI9EJChsK1oZgsRRE0g9b5oqwXrCJPM89iIN5N
         SYzYeSDZdK/SYUmEX+j6YvOaSWhDgRTdc0jA8xohQJYjK2WR6ZWNIu1K0K0Kc2qKOChU
         ietqPkedk0zQqQt69H/LPWD+87ffotZW7kmnMoLsWXNZQ/LdsGxzlfkgqfcz/uU3OGF7
         XwdMZA8w5VsbWT1fum7ZXD8jUIHOxSPnM8J5AOwEkEHqckpkjixwnA8NBz73ioB3Me0o
         cC3jxBGHTq43QGCalSBtVjFwQgTfneSsbqZDSWjQAiFfZVbv3K9i65MgcbuHTZ/HTNoy
         uPxQ==
X-Gm-Message-State: AOJu0YzftzP7MG3cfUt0QB7iglQYX2nKgpAiJR7wYIr20wH5kdV4Ot6w
	S/gRlQ+qt+GkNvCc2/VKXHdWJwwAH2STcHWczL+dXov0ko1blHe/oTFEXZwWbJ1ii2+xODXLvnq
	SGyo=
X-Gm-Gg: ASbGncvuV4KlGdBinrR2vD8e7Kn4/ijXWwOnBhwwal1eFlTfHXR+BOU7yOjcKiAe9eJ
	KEn1G2hPNQ5YqmqwFKlL77LqOsWWukuFjJTbos0q01ONKwIrGptQ8HQ7MInH3WoKf93XyoItlKe
	ejfSjPz0D42W58Ma6906m2v0ogX0Kd2A/ugPNnJt3g/yUXNVhWGQKE1xjSPJXALL77q/9lmvqw6
	iBfRiI5g8xgDs/zZN22nZsDp+bRAFmdLNCvTOfUh926ED0TBiQv/jPJBaZJWDE+b0ZTDgoeFZwI
	B1MVyxv5V/RX1Rvh1cX02YqMnsooiNwjF8GT0WxMt84Q8cc07JrkjYRNc6RDgsZWxQWRtbsUqR7
	Q4hA7Yv0S3DnedBg41axAPzgNOwonVybOJx8gsIJNqhkSFAk7a8INPVFvZ5Q42b9hUWOFmWx/R8
	kB1mKoUi8=
X-Google-Smtp-Source: AGHT+IFpPI6oIOrxtcYp8L83cONSiu7I6uMenaZ/i17bVyinv2mQ0L33iNPAJwdDUhm/xD7JMTRvIw==
X-Received: by 2002:a17:907:3cc9:b0:b04:6e60:4df1 with SMTP id a640c23a62f3a-b04b17672femr737388566b.53.1757326749903;
        Mon, 08 Sep 2025 03:19:09 -0700 (PDT)
Message-ID: <77361e51-dcb8-40e2-a526-9ff90ba942a2@suse.com>
Date: Mon, 8 Sep 2025 12:19:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: New Defects reported by Coverity Scan for XenProject
To: "xen-devel@lists.xenproject.org" 
References: <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.09.2025 16:37, scan-admin@coverity.com wrote:
> ** CID 1665362:       Integer handling issues  (INTEGER_OVERFLOW)
> /xen/lib/find-next-bit.c: 104           in find_next_zero_bit()
> 
> 
> _____________________________________________________________________________________________
> *** CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
> /xen/lib/find-next-bit.c: 104             in find_next_zero_bit()
> 98     	}
> 99     	if (!size)
> 100     		return result;
> 101     	tmp = *p;
> 102     
> 103     found_first:
>>>>     CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>     Expression "0xffffffffffffffffUL << size", where "size" is known to be equal to 63, overflows the type of "0xffffffffffffffffUL << size", which is type "unsigned long".
> 104     	tmp |= ~0UL << size;
> 105     	if (tmp == ~0UL)	/* Are any bits zero? */
> 106     		return result + size;	/* Nope. */
> 107     found_middle:
> 108     	return result + ffz(tmp);
> 109     }

I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply
0x8000000000000000UL, isn't it? Where's the overflow there? There also
cannot be talk of a 32-bit build, or else ~0UL would have been transformed
to 0xffffffffUL.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 11:04:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 11:04:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115105.1461841 (Exim 4.92)
	(envelope-from )
	id 1uvZfu-0000Q6-Q0; Mon, 08 Sep 2025 11:04:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115105.1461841; Mon, 08 Sep 2025 11: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 1uvZfu-0000Pz-N2; Mon, 08 Sep 2025 11:04:42 +0000
Received: by outflank-mailman (input) for mailman id 1115105;
 Mon, 08 Sep 2025 11:04: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 1uvZfs-0000Pn-Uz
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 11:04:41 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2409::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99ab401d-8ca3-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 13:04:34 +0200 (CEST)
Received: from BN9PR03CA0324.namprd03.prod.outlook.com (2603:10b6:408:112::29)
 by CH3PR12MB9342.namprd12.prod.outlook.com (2603:10b6:610:1cb::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Mon, 8 Sep
 2025 11:04:27 +0000
Received: from BN2PEPF000044A5.namprd04.prod.outlook.com
 (2603:10b6:408:112:cafe::4) by BN9PR03CA0324.outlook.office365.com
 (2603:10b6:408:112::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 11:04:27 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BN2PEPF000044A5.mail.protection.outlook.com (10.167.243.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Mon, 8 Sep 2025 11:04:27 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 8 Sep
 2025 04:04:19 -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: 99ab401d-8ca3-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vQosuGEdP0xUXIxvexabIEIj9j5xT6guWNl2dZjdV4CsXpRmnAi6YRcFnldeTWBoBAkD74LnReS+bKIFVMjNOM0YYZ1iIOnpkyxjB0UDbMWJfyEmjQmn1j1qbrNX3IOSbxRYFli7xqdlPwJ28CJLVtqn2PuZdfZJb971U59G+FI489nqymt+A9mAn9QYcFkwKY/w8D3Ezn28UiirBOSWnG65usRqAzx/JNcqjN9/jJLx1CTiyqzsvQpeo0VIxW3QKiYRa1LKsA9L+ATGZKFZDH9w6bzDhVFVfR/4SxP8kWZ2O11P3XNPxssXCNeuFiJFW9Msk87YbWVbtZJap0Qquw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YAJKJjn3gN+PFICaW0C0tCKi0gSp+GCZeCXOdStbLo8=;
 b=owCtyE1hbLLWFoWj5rgUE/FQxxKKydHNHYWiIfmgxD6NavS8OxQwCPuFBR3qRMdPq8FMBTLgdeweVc0tmYgRPXXG8Xzx7+Yme9/OYV1qH2AafnWnvcKYCxIC750TZ1GJGMjk3HbdjxENT0HrjWwOnt7WZv7nm1GEGQviqsIZ7tRZ7941iChLAbIxBzsT1StnQwEb4lpSz5xz67mQUSBZ6Vwwl4Ws3KmUoo/+mJC2ZZy8xECESDS66QYLE6Sbj7N+Nux1ogDCKPDuOU09IQX4OIpuuvMQYkNAVZrKCVcsqBIaKBv206HtRqyRhR0rvsDg7L4dus9qpEyGm6kiSfVSZg==
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=YAJKJjn3gN+PFICaW0C0tCKi0gSp+GCZeCXOdStbLo8=;
 b=Br8L68cZs2OhjwgV+guCLtjw15+Oy8RLdgPxPOqZsZYiyH6opuuF/K3CarasGBCJui0Bk3Nr0t+TEF9jh97phgUaHSWTMTDKUoFc2kLVJWbqR3BXIHAU3iZ2eNv75kJeEOGWvhHgSTL6aRyvKpa4PiTBnGe4NH3yhlRVF/JDs0Y=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 8 Sep 2025 13:04:18 +0200
Message-ID: 
CC: Xen-devel 
Subject: Re: New Defects reported by Coverity Scan for XenProject
From: Alejandro Vallejo 
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
X-Mailer: aerc 0.20.1
References: <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail> <77361e51-dcb8-40e2-a526-9ff90ba942a2@suse.com>
In-Reply-To: <77361e51-dcb8-40e2-a526-9ff90ba942a2@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A5:EE_|CH3PR12MB9342:EE_
X-MS-Office365-Filtering-Correlation-Id: 0b681e41-3148-4069-72c7-08ddeec77a79
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?M1NNektEZHhZSmQwTUFkMFovOS9yZHVXdklhanhrQWM1eE9GRlBHeHRWT2hy?=
 =?utf-8?B?dEFPSGJiMHZxSm02bWpibjFlWFFHNFlzc2tMbG9nWVFCUjhCQm9lYktCSnR4?=
 =?utf-8?B?ajhJSDVrMFFsSndwV1NIUTdkVmp6UzA5YkxTWTl2OW5CMGEwM051YzNXWWpX?=
 =?utf-8?B?V3ZEMnJGYVpWQ3FNZUNDVmQ3eTlhZEJBWHFOcVBUdzFPZlplR09zb050VEFU?=
 =?utf-8?B?dWlWUzcybkdHT1h6WE16SGxyR04raVBRUXZXWm1rc1NQUE84djlpNTBXWDBW?=
 =?utf-8?B?ZThJb1pTM3dMN0dodzZVRXVUeWZyVFdETzMwSW80d2JndUNaSEVGQlFKZStx?=
 =?utf-8?B?YWxJWERYdUdFUlZvQUJHQVA4ZjdxSTZ6QkFieTl3c2xUUEQxei9YOVFuR2g5?=
 =?utf-8?B?WFBPWnY5NU8vKzJPR0lJQ1kvWTBCMGZwVHdvTnVhVTdTQ0ZmZHgxL1packM5?=
 =?utf-8?B?ZkRwN1MwVDcydU9QUnQ5STJNOTA2QkJWdCthcnF0UUs4eWpJSWQ4Z05aNTdk?=
 =?utf-8?B?UDlCeGpVbFBhSHplSWlpbFc4M2dML3o5Zm5WaVRtK0p2RHVsRThnQmpiTFRR?=
 =?utf-8?B?MUFoY0ZmRitRU2JuZHcxSDdQV0hHR3JzS05oWjNlbFl0Lzh5bDRmVllNZ3ZC?=
 =?utf-8?B?aVV3dUpyYUhPSjZ4NXBtMFdJL2o2dEtFbTgxbVBObTJnUmpCSlJ2WW1mbFV2?=
 =?utf-8?B?NDlIemxtLytsNDlpYmlVcjFER2szbkI5YU40ejQ1bWkxTWNoYWtlbWV4YWhC?=
 =?utf-8?B?Z3VCT3NoSG9zanBUOUMxWGdyaDN5eW5jOVpQNTBGbENSSmd6MmpydGFtaFNX?=
 =?utf-8?B?eFVjam9yZytIbTBjbGhzc0pTWGJXMVp1MVoydi82U3ZJWW56b0tHS3NmZWtE?=
 =?utf-8?B?WmU5Y3JoZ1lubzZ6Tko4ajJnMlRFM1d5bnMyb2lLUVpJcWk1Qlp1V3dGS3RR?=
 =?utf-8?B?QzFtbFFCWTJtZjRRSEwxU21TZFhRSGdpTkl2R0hBeU40cVFTbHVSTTBvVWhy?=
 =?utf-8?B?cG5OaXFRb2VuUk4wREw3OExuTWhhSDNKNkg3OUxPeUNzSlFFb1B0VG1CeUV2?=
 =?utf-8?B?Z0E4SlUxb3lKcXcxQVdKbFk1amtRWHVpQmcvU1NJYWlPT0xmT2Z6L2VVK3pT?=
 =?utf-8?B?VnZ1dVRUaFZTaHlvQmVoeUhjeEtubDA0ZGNVSkQrZ2FFUm9aR2lNeTBySEgy?=
 =?utf-8?B?UFBVbkZvK3kwUFNqbFVYVEhHeEt6SndHVmhXUkNoNVRPUkIxU3pROXI4TVdi?=
 =?utf-8?B?bWlxNjZqM25CKzBsUXJrQ21tN0ZCaFc0YTRnZHkramZCeFZhbG5TZzFJdy9L?=
 =?utf-8?B?N3pmUzRmbWtUdTM2ajFNdGtWV3plWStiM3dvZXZHUmIvYW41QStMallEUEt1?=
 =?utf-8?B?akZweTI2b0lPYWpDVGdiN1JwSjFxZ3RsT0szN2pUeTRVM3JhWHdKRlR1YWJx?=
 =?utf-8?B?VWpYRFphRHhxTnJXZmpmMDROQ3RGbVArWmJkTE5ZMlpSRzl2TGZVNnl2RWdp?=
 =?utf-8?B?OVRTTFlKeVJRM0svVHlmTWhtUnNaNGFUa2l1QkQ3QjNnMjlwVDM2R1hCUzhF?=
 =?utf-8?B?d3RlODFrcFBsY2FkTFlWdXQ1d1RRcXlEeXhia1VWd24vUmhxV21JejAzcnY5?=
 =?utf-8?B?YlVUV3hyOGxPalZpWjM3c01DWVhJcWlXaVc0b2dlV0V2Qm1WMDJ2MlJ1dzhX?=
 =?utf-8?B?eHp6WEtJZHZzSTB2Z3hUNmluSVZWejJ5V1drYlc3TGd6dnI1aTFUOGhZcnBy?=
 =?utf-8?B?WEljUWFTejhXQmR3RWJzOExMb2sxRDlsV2pPQktWcE5aSlZNcXQyYnlvOVVh?=
 =?utf-8?B?NnpqMzFFTXovMFpacU5zZVAzMk0xSk5qSTNvMlFnOHFENXA4c2FCNXpSVkFn?=
 =?utf-8?B?c0YyN1F3WEQ0Szh5bkkzL05MK0h6eUZMbk9PM2JUZG9TcmpyTXJYWm1mUExs?=
 =?utf-8?B?NGxGNWZabCtydjVjRFZ3VEtHSENLRzhPc2ZzMDdieis2SlZ3N1BNeG1nMkJv?=
 =?utf-8?B?bmQwMlJjbmNYbXEzRXV2azUzYXBNL2ZsdFdjY2JpNW9QVmg4UEluS3N0YXlK?=
 =?utf-8?Q?+saqQa?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 08 Sep 2025 11:04:27.6745
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b681e41-3148-4069-72c7-08ddeec77a79
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9342

On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
> On 07.09.2025 16:37, scan-admin@coverity.com wrote:
>> ** CID 1665362:       Integer handling issues  (INTEGER_OVERFLOW)
>> /xen/lib/find-next-bit.c: 104           in find_next_zero_bit()
>>=20
>>=20
>> ________________________________________________________________________=
_____________________
>> *** CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>> /xen/lib/find-next-bit.c: 104             in find_next_zero_bit()
>> 98     	}
>> 99     	if (!size)
>> 100     		return result;
>> 101     	tmp =3D *p;
>> 102    =20
>> 103     found_first:
>>>>>     CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>>     Expression "0xffffffffffffffffUL << size", where "size" is known =
to be equal to 63, overflows the type of "0xffffffffffffffffUL << size", wh=
ich is type "unsigned long".
>> 104     	tmp |=3D ~0UL << size;
>> 105     	if (tmp =3D=3D ~0UL)	/* Are any bits zero? */
>> 106     		return result + size;	/* Nope. */
>> 107     found_middle:
>> 108     	return result + ffz(tmp);
>> 109     }
>
> I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply
> 0x8000000000000000UL, isn't it? Where's the overflow there? There also
> cannot be talk of a 32-bit build, or else ~0UL would have been transforme=
d
> to 0xffffffffUL.
>
> Jan

The offending line LGTM too.

The only credible explanation I can think of is Coverity flagging discarded=
 1s
on left shifts as loss of precision.

If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it hap=
py,
but surely that error would flare up with all uses of GENMASK() too?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 11:25:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 11:25:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115121.1461851 (Exim 4.92)
	(envelope-from )
	id 1uvZzz-0003MH-Ek; Mon, 08 Sep 2025 11:25:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115121.1461851; Mon, 08 Sep 2025 11: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 1uvZzz-0003MA-B4; Mon, 08 Sep 2025 11:25:27 +0000
Received: by outflank-mailman (input) for mailman id 1115121;
 Mon, 08 Sep 2025 11:25: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 1uvZzx-0003M3-F5
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 11:25:25 +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 7ff12e24-8ca6-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 13:25:18 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-6228de280a4so3932014a12.2
 for ; Mon, 08 Sep 2025 04:25: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-62069b79e1asm8836284a12.26.2025.09.08.04.25.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 04:25: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: 7ff12e24-8ca6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757330718; x=1757935518; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OiFr1LYblUUTJ4e+zUF6icTV6yBufld5nKKTUGNHAEQ=;
        b=KMzpK56AfhR2DvdK/wToLoCyVD1+C/gY+kXSzIXyUF9bUgrO/0xwcYK+0BFKqdMVkS
         Id8MqPUTZ1XA+JkU2QUXzV81p5tdCzjlE3jB6KXqKCdAk/9u05En1Uzor9qUPQnUgwVo
         +RIZNbh7Q0UWHTCn8qcjRPmLA3sPV8fCgPVkvBJtQR7eTgJ3yd2Or+CyJcGChsF7DnEI
         oGhAxixBwlh2YRMZXFlC1pZidcsOqhGn1hPa7+vHTuhUGVVJcg9o2c5XJXbQE7ppFujR
         CmklUHRIe0y/dx56a2rSXfu8YLl8AcOEbfcWX6wcPxVIgr0D/LUEtDKV4k75NBg6UHhb
         LmPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757330718; x=1757935518;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OiFr1LYblUUTJ4e+zUF6icTV6yBufld5nKKTUGNHAEQ=;
        b=FCewLIH1AIbIMFti/iMaIEPAElIX1y5+LNjGwpaFynH8Thi0xuRbHHjt0912R18WC+
         1FdC2a/su4hbnlXdG653sIYc+TpcM0afJYv7nsU6xTkR7PFyPZ7lxO1HBSHuZyLcgYHP
         NR7aLfKJuFrnyFDKNOzPZe2Q/nY2J7ZtFr5+SpfY/jgdA/1RcKlEjeOa6v1/T/WLNbng
         cnbjc2ggmQexb3uOguu52lpKS0SvhCKVkEY/rLHfV+yy7N1um2ZxEG3gVSrEsXg1CE0g
         WAmmpxwiQ1x1XcVztIVtBZDlUfEvc2Tbr/oCedf9quyXRKl0mM/tXYAL8MMmYI48jj3e
         UAeA==
X-Gm-Message-State: AOJu0Yza+xgKAdHjkMtbsT48EEtmua8t3LG6SyNATXTE4KL1Y3YnvyaV
	2LFGWiKqwreu1f70g17k5TvTSLDomFtYdQD3w7DTzdZVpbZ3P4fPRV4Jm+Tdyl07UQ==
X-Gm-Gg: ASbGncui/uBfTfvGan3F3K7RNWMIC7AgkWDENxu4KgHEI5NSNHe6Vw57uS5jIVQF8Ty
	rb6hLf1D1Qt8EFYkiZYA7R6fi9DGsf97Or8G2956WYGJQHFgJ7bLm4K3UBu5CiTUKj4b0bWZwMy
	4jiW2d9UsPtf5ViDd16fBYvZVOPw2ua22/HoNq9eaP2LABoPKwqiihB+bZ7bCZZ5mfBzNVLCsTH
	ro3PsqaL2XPkh87TSaXxAJbwDuAUxC2Lw67fRG6E+tbM1GdXBOBkdTCLHIKJggHzUp3spK3JZ+T
	0ZXDSsjlLxnyhIJkA56ZZnV0AZC2UmZ7SeXJ/tuysURDt7aDGzmrzCJhfbT+ET1+7o+b7NF1u2z
	Sk020Q3HkghquHz3O9nv2TpSEFHFbOZlE9Q0FSy44YyfSW10BBp4JEUC0YkaA/JV3jYHsfRs6Bj
	nDazMHuuZyQE9BibjD8A==
X-Google-Smtp-Source: AGHT+IHDE8sjl6WMATI1HbhMNyg5V/ZCXtsQAsmJy6c0l1s3+Tl2sQkeuUNniU6U10JTX1vjWLf6HA==
X-Received: by 2002:a05:6402:27d1:b0:627:9d08:97a6 with SMTP id 4fb4d7f45d1cf-6279d089899mr3680143a12.18.1757330718101;
        Mon, 08 Sep 2025 04:25:18 -0700 (PDT)
Message-ID: <9e474109-7aa1-42b9-9fa6-31c4ef0fb856@suse.com>
Date: Mon, 8 Sep 2025 13:25:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: New Defects reported by Coverity Scan for XenProject
To: Alejandro Vallejo 
Cc: "xen-devel@lists.xenproject.org" 
References: <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail>
 <77361e51-dcb8-40e2-a526-9ff90ba942a2@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 08.09.2025 13:04, Alejandro Vallejo wrote:
> On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
>> On 07.09.2025 16:37, scan-admin@coverity.com wrote:
>>> ** CID 1665362:       Integer handling issues  (INTEGER_OVERFLOW)
>>> /xen/lib/find-next-bit.c: 104           in find_next_zero_bit()
>>>
>>>
>>> _____________________________________________________________________________________________
>>> *** CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>> /xen/lib/find-next-bit.c: 104             in find_next_zero_bit()
>>> 98     	}
>>> 99     	if (!size)
>>> 100     		return result;
>>> 101     	tmp = *p;
>>> 102     
>>> 103     found_first:
>>>>>>     CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>>>     Expression "0xffffffffffffffffUL << size", where "size" is known to be equal to 63, overflows the type of "0xffffffffffffffffUL << size", which is type "unsigned long".
>>> 104     	tmp |= ~0UL << size;
>>> 105     	if (tmp == ~0UL)	/* Are any bits zero? */
>>> 106     		return result + size;	/* Nope. */
>>> 107     found_middle:
>>> 108     	return result + ffz(tmp);
>>> 109     }
>>
>> I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply
>> 0x8000000000000000UL, isn't it? Where's the overflow there? There also
>> cannot be talk of a 32-bit build, or else ~0UL would have been transformed
>> to 0xffffffffUL.
> 
> The offending line LGTM too.
> 
> The only credible explanation I can think of is Coverity flagging discarded 1s
> on left shifts as loss of precision.
> 
> If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it happy,
> but surely that error would flare up with all uses of GENMASK() too?

And with any other non-zero values of "size" here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 11:28:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 11:28:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115139.1461860 (Exim 4.92)
	(envelope-from )
	id 1uva2g-0003yk-QH; Mon, 08 Sep 2025 11:28:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115139.1461860; Mon, 08 Sep 2025 11: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 1uva2g-0003yd-Ni; Mon, 08 Sep 2025 11:28:14 +0000
Received: by outflank-mailman (input) for mailman id 1115139;
 Mon, 08 Sep 2025 11: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 1uva2e-0003wI-LB
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 11:28:12 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20628.outbound.protection.outlook.com
 [2a01:111:f403:2414::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5c774a5-8ca6-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 13:28:10 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB7716.namprd12.prod.outlook.com (2603:10b6:610:145::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Mon, 8 Sep
 2025 11:28:07 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9094.018; Mon, 8 Sep 2025
 11:28: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: e5c774a5-8ca6-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ktKrC/W+jM7OQU0krCxwTM3kG+tJpKHL0MDaf3R5+ihBegPSO/dD7XuEFkh69o/xENEK99VDESPLGUbsObJ39pja+VvnwMzYZUYeEu61Y4TKLIwkxk/E30CtpdE6/f91Py3gg2uP+G/x3T1o0LSTmScvNZYqV4ohnMgRiqVGio48HcTRxlbAVZUIIGwx6sTlZWh3Yn0hKAYrEMnJhdPxW/IkpQ51jnyogykspVYaY+eKLns1WhSWUhg0sJ+QSkI5unbAOplDU6ShmHAqvwS1mx5da/cPqafclR7YWOz5Z2xppkFzBvRHV6aQVZpRI52RRDwUTwU+unxS8hoFD5nQRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PoyQ8x6p+g7RdYaUQhtMj32/uMJDm9PKSEEcEs6idxU=;
 b=sj9QD2VPg97KDE2eYmTS5ONyguCBDn/212ZoCwJGpH8VGzmlo+18BgdDcEa1qH8ssgUsJXvZSIxcTBwdADURsRrcwuEGAVSQN2qVxcbpLBS3b+sKZPrXtAyl/cHlg7CI2H9w3NCsLQOEUDGMzAkDd5sbBgUDuaDeXnklfuWCfcrBAOXVt3VjZK/gpLmFk4XzGhOE9B9etEaIZ+M/8xwYMQb6GCMkqjxsz0hYP6OgOF+o1P0B8NxlT9FXz1d1bcM/imPzXn49piZywqw/nwF5u0EiQHNcIQxltBvTVSq+uqzUwAt+sDL4nIcSjaQWL13bR0Z4MBPJPCUKEZcYy1G6bA==
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=PoyQ8x6p+g7RdYaUQhtMj32/uMJDm9PKSEEcEs6idxU=;
 b=rdMnglztLVf/D+2utui4yOB2O5yvkna1YNKJJFscjMNMd8Whjvuf8y5QvASg9aNuiY63/XlE1ZohKPTr4HF6xxinn1N8jQuh34knvmXR+wq0f5zIIijrhKiDrA9g0FZ2dzz6j4PJmZeaINfIKE61MvxrJ4MOdFzn+TbOXoH3hMg=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Andryuk, Jason" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
Thread-Topic: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
Thread-Index: AQHcHWYoX5yLBs91qkCeYarmDUxFSLSC6XqAgAD6+DCABTACAIAADuWA
Date: Mon, 8 Sep 2025 11:28:07 +0000
Message-ID:
 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@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-09-08T11:27:56.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_|CH3PR12MB7716:EE_
x-ms-office365-filtering-correlation-id: 6579c82f-1b58-4308-faae-08ddeecac88b
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?VnQ4RGVZd2dzMWR5c3VQdGpYU1pNWHZvS2tjdXhSY2FMVUdKQUlSb2xqNi9y?=
 =?utf-8?B?eXVjS2x1ZEF5dVIrVC82bUFsK2ZjQTBqM2hCZnhzcjlqZVF6T2VybHNhY2dU?=
 =?utf-8?B?a2JUYWZEdExpNmtlUmN2Q3FCRlVRMy9zOXcvdXI0dnZUMVlJMEZrR0pvazc4?=
 =?utf-8?B?YWxUcjBBa3VyTTBqZmUrL1ZaK2kzN1JqYVpIYncyY1VDblZxS01MdFhQS3o5?=
 =?utf-8?B?OFlSbVFIcE9sMnFxZGpyMzdLNm1JaGQ3dmVESjNSbVc1ZWtYSWh2OXRLVzFv?=
 =?utf-8?B?SWJNbE4rbDQzWWpRcVh2Znk2VGdITFNva0xpVjMxM0MxT0lHcnFkcnYyUDdo?=
 =?utf-8?B?amNrcnAvbXFnVVFiN1pRc2ZQMXpzeEZVellsSnlhOTFmMFc1WFppTC9kQnVS?=
 =?utf-8?B?QXpUZlBmRnhYSTBRNmw3Z0ZMR1dYWHF5RC9JSkEyRjFhTTduU3BCLzJRMmtO?=
 =?utf-8?B?R0o1UjhjUHRrMFVDS1hxU0tlMi8wM3p3VU1Yc3lZckxUUHlnSUJoNUpyQnRw?=
 =?utf-8?B?V2gwbmdqM2xHNllpTFVETEc1a0dkazcwUWpSbjNYRjJKTmhJeEtmN29HZkFr?=
 =?utf-8?B?UEd6VTNyY1d6d2Ezb3owbDMvM2dxakVWTE1QeU9EV3F6NXlQK2dKb3Nmc3I3?=
 =?utf-8?B?cmpVbU1BN2toNnZUWlpzNS9ENURITnlnRjhUajJXNkJOcFd5dmJmUFhPY3Ev?=
 =?utf-8?B?UWd5am93MXVScFRyKzk3b0M3dzZaUjJoa1Z0b0I4N2dkV2xkQjZRYXJNWjVK?=
 =?utf-8?B?Umt0RUo2TUpYUlkwRktiQlA5dmZEaEJEUkREZTNzdjNwRC9QRTh2M0ErQzNx?=
 =?utf-8?B?cEpSc3dYUEpVT01LWFFKVUhyQVJ6d0h1ajBxb0ozWjcvZ3FyMWg2RTZLd0F1?=
 =?utf-8?B?OXI4UERzREVxckxmUmp5U2haMHhZeFRGdndGZm81VVpkVFBubm9vTU1YaXBU?=
 =?utf-8?B?Y1JZR05qQU5IZkpsRXZ5NzAwTy9hbGN4V3EyVDFzL1dZTFRFd1R3QTVxb0Z4?=
 =?utf-8?B?RVNPYVJpYVpmK3kyZEtnUlhZWjZUK1Fqem1ZNmF4UEhNbDBNNWFjS21yNWpx?=
 =?utf-8?B?UUtTelJqN2h2Ylh0RndBZnI4cUNRZXFIb1Y0NTdBQ21qOHAvMzB3NWovaFBz?=
 =?utf-8?B?ZEdFUFR0bGJRS3VHbDUzbS9wVldTTGxyc1lseTJnU0JCRk5aVmtHSVUxSlFQ?=
 =?utf-8?B?WVZxekpycUhYUmRlWlROM2hxS0Z5UTZIOEh5SmIvNDFoc3l3SFk1NHFUNlli?=
 =?utf-8?B?Smo1S3dhREF1OFl5aHpjbE9VekNJN01hU2trdXhGZTJIckNmTE90M1JEZ0ZS?=
 =?utf-8?B?b3F5T2x4Yk0yR0pQYkpYS1EzWDgyMDkxbHdYUndaUVkrcmkraU82ZDFlQVBF?=
 =?utf-8?B?ZmxLRHd2SkFsK2dDMkxzM2xFQlh4VHdha0tERkp6eW54UlpuRXdiU1MvaEN0?=
 =?utf-8?B?YnZRU3lEQnd2WGs3aHFBYjhid3RkblU1NTVxNWNSdGxheDZqMXkxNUFVQVY0?=
 =?utf-8?B?V3JFNjN3ZEEyVXlST3dqb2VqenIzSmpXSlJCOUNRV084NEMvQXNjeEVhcStC?=
 =?utf-8?B?dzNSeXJmNmI1T0JGUXlsQWJSVUNiR0NSakdGc3VZVUEwV0Q3VjVTOU9Jay9W?=
 =?utf-8?B?em9JdUNoYjBCTzVrNTJqMWUrNHVNc3M2T01GcG5oNW5RV3FHN3RBTjhGODRF?=
 =?utf-8?B?ZStjV2cyd0pZblhyU3dKcUQ5dWV6Ri9QcHBkSE0zUU8xWno1N20vTG9qOWI3?=
 =?utf-8?B?NVBvUmRpblFYUEtoeVVsTjk4bEkzRjgrZEIrZVYyN1poVmd3L3JGMGswSk5L?=
 =?utf-8?B?T3IrbUNJSVlsbEIxSUorL2FCeTdDdzZDdUhkQ0Z3cUxyUlFHSXZVYVJWbmtH?=
 =?utf-8?B?aWpkL0dhSUpoU3h0OUtRWHBKa2lHNkxwbFBVUVZJYkVHdnFTOEplbVRqOWZP?=
 =?utf-8?Q?E5yKydR3wFc=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?RVZSd3VSTmtlemE4ckNDalBFbWtVWFZ5YjBxRlJmOEZ2ZWZHRkZySmNjckhW?=
 =?utf-8?B?Q1pvU2dLQTFQNng3cXU5VFhUNkE1MGlta29QRVladGdVc3RlZ2ZGWXFQWUxK?=
 =?utf-8?B?RWhheTAwZC9WTEJscDNEb3hvV1FJdDNQaldHQmp3a1ppbnZaSDczellVenVH?=
 =?utf-8?B?ajM3Q0hBbW40emY3NVVZNFBRcmtFdDBUeFFHYjJpMmZUTXNqMzE0aEJWajFa?=
 =?utf-8?B?MzJFUUhvbno0S1M4bTFVTXltYXlmMlU3ejd6UThWU1laVW4wdUpNTk9WTGJr?=
 =?utf-8?B?R2RScnFINmhuL2tDcjJaUTFoQXVSN3AzSGRYWThZUFY4aWtNR1VtSE84QlQz?=
 =?utf-8?B?emtYamxaYlVpdVpFZ1VFaWE3U0NuWTBTM0YzR0VWK3M1Q3FPS0Q4VUM2MTQ2?=
 =?utf-8?B?WjhkOE5CUENKd2F5anBVU3Mxd0ZaYVE2V3pTcDBCcnEvamFvYTVxWXVJWW9T?=
 =?utf-8?B?OEFpTmF5Qm9hOGx5c1JWZTJ5RkY5OE90MzhQdDg1dS9JYnA2eDBJdmNCMFZ1?=
 =?utf-8?B?VzYvQkJnSEFuSFJNNUVNYndwUXRScDFXTytZaEx1ODZvOGFmMzYvU2tMeWha?=
 =?utf-8?B?U3NzQ0gwVnE4MEZpbVVzdHUrS29QRHA4blJBOUFjQlFyalhzeGtRZEdBaG5N?=
 =?utf-8?B?Wmx1NjNsVDc1TmJiRFRsY2JIcVRHTXJzVTh5QU9mMEpPeGRTaGRMV1ZPZE43?=
 =?utf-8?B?eWgwL0JxM0ZZQ0Y0SHJ5MDV5L0RiZVFUVHNuMmlvQzZFYXdOOG5qQ0tSQnUv?=
 =?utf-8?B?VTJMYnRZWUYvTjltUGprTDVocXM5QTgwS3RPNk81MHp0L2tIeGF1ZzFaRzJR?=
 =?utf-8?B?MU9ibXp4Znl4b0pRMUVnUzhXb2tCaDYwQk84L29uNTVwS3YvOHFQK1VEY05W?=
 =?utf-8?B?bGxta2JmYnROUm5XNE1jL3JjbUlyZWx2Nm0rUVpZcnVIdmNId0gwN08zYnly?=
 =?utf-8?B?V3Z4cDJoV1lWZU1rMTZaM2FYQ2lpNEdLYTFDQzVOdWJsc1FQWXA2aExJclg4?=
 =?utf-8?B?ajl5SkE2enhvMnJTSFpEaGdHMW9tN0kraXV1S1NDZlB3YVhQekYyMkJTcEZy?=
 =?utf-8?B?d0pYK3lCbFEvQURGV2RiRVZCMVBUcE9wU3NOdzlIc0xKdXdMVERCakFYd2cv?=
 =?utf-8?B?ZTBmOGJEWWlLUklGVHZsUk11by96TXYvOVlwaHNkUjl0UXY4a2dWYmtMclAr?=
 =?utf-8?B?Z3EycWt0alRZYkFBN0pkUnhEQkZKelprd2hVc2oyZFV1UmRQRm03RHNkdnZ0?=
 =?utf-8?B?YXlhNFZzQ1FpbHBpNTJUQUpHTURNTUtpdjF2Nm9TcTVmZmczekZpK3J1TmlR?=
 =?utf-8?B?TFVXRjE1eTZvQ2kyMEJlckNkMWhKTklRS3NIa0VOdi9jSXJhQVArbUFVQi9a?=
 =?utf-8?B?eTNPUU5DbjIyU2orbjBFczBOSUI3VUNMZGJaRDJxY1lMaG1GTHdBYWlxc2RS?=
 =?utf-8?B?UzVTSXlaN29QbUxhZlpBNmdzTnFBUHd6T1hJbEp1MDdCc0VwV2tvVnAwU2NS?=
 =?utf-8?B?V2dIYVQ1cGRESkNJNnNyRzgzSmNKUUV2TUlXQ0dQTCtVR3d2NnZUVWN6cEtK?=
 =?utf-8?B?aXUzaW45WUJNREdhbEdTMm9iK2JQaTZZc2MxVDh0ZmkvS1hkOWo3YnZLOWlE?=
 =?utf-8?B?ZlJPcDhSSEcrS2FJQktoSEVKbWtPTzZyQ1Z0YVVaakVROGpkS1BKY3B0QWhk?=
 =?utf-8?B?cU9MQUlhLzQ2N1dNZlMxRVo2cUhCRWVlaVVRM0pqUURFY21nVFNPcDU5MFhj?=
 =?utf-8?B?c2FaYlBIL3U5MjQ3SWI0dUs0L0pQUkExMjNnZlJ4ajcwVXNObTY0VjV4V2tx?=
 =?utf-8?B?V251eUxiSVFOVnZPWXJRVGZsQlpEcWtoeXdGWkN6MWg1WTRsTm4wSm5VWlNT?=
 =?utf-8?B?dzJiRGtYdTNwS3hSQkN6eC84WWQxcTRxRDJpcnVJZ1VsTVZCTDFiZmczUFhq?=
 =?utf-8?B?ZTE4SXBZQ0wrb3RocDV4Y2plTmR3WGc1dG0rWmtuQ3dIbmw5L2NaTy83YWhV?=
 =?utf-8?B?eG91dm9laFNjL21vUUNDUUhKMDBFNGNReUxIYWR2ci8rcWZhOUdiczMxbkhL?=
 =?utf-8?B?NnBLT00yTi9yYisvV1NLbUV2cVFYSHM0ZVNjSFR4TzQ1RVpQdHNqUTIwcGc0?=
 =?utf-8?Q?Qu+8=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: 6579c82f-1b58-4308-faae-08ddeecac88b
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2025 11:28:07.1695
 (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: 9vAk5xjWLK1Ur+8P7JT11t5hXWpv76dvwAigs1kLjjDMksS16GD2s3T0R0dBz5UxdrhtUnNH3xqN5bV5RuXRHQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7716

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDgsIDIw
MjUgNjowMiBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD
YzogQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNvbT47IHhlbi1kZXZlbEBsaXN0
cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY5IDEvOF0geGVuL2NwdWZy
ZXE6IGVtYmVkIGh3cCBpbnRvIHN0cnVjdCBjcHVmcmVxX3BvbGljeXt9DQo+DQo+IChyZS1hZGRp
bmcgdGhlIGxpc3QpDQo+DQo+IE9uIDA1LjA5LjIwMjUgMDY6NTgsIFBlbm55LCBaaGVuZyB3cm90
ZToNCj4gPiBbUHVibGljXQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4+IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4gU2VudDogVGh1
cnNkYXksIFNlcHRlbWJlciA0LCAyMDI1IDc6NTEgUE0NCj4gPj4gVG86IFBlbm55LCBaaGVuZyA8
cGVubnkuemhlbmdAYW1kLmNvbT47IEFuZHJ5dWssIEphc29uDQo+ID4+IDxKYXNvbi5BbmRyeXVr
QGFtZC5jb20+DQo+ID4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPjsgUm9nZXIgUGF1IE1vbm7DqQ0KPiA+PiA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyB4ZW4t
ZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OSAx
LzhdIHhlbi9jcHVmcmVxOiBlbWJlZCBod3AgaW50byBzdHJ1Y3QNCj4gPj4gY3B1ZnJlcV9wb2xp
Y3l7fQ0KPiA+Pg0KPiA+PiBPbiAwNC4wOS4yMDI1IDA4OjM1LCBQZW5ueSBaaGVuZyB3cm90ZToN
Cj4gPj4+IEZvciBjcHVzIHNoYXJpbmcgb25lIGNwdWZyZXEgZG9tYWluLCBjcHVmcmVxX2RyaXZl
ci5pbml0KCkgaXMgb25seQ0KPiA+Pj4gaW52b2tlZCBvbiB0aGUgZmlyc3RjcHUsIHNvIGN1cnJl
bnQgcGVyLUNQVSBod3AgZHJpdmVyIGRhdGEgc3RydWN0DQo+ID4+PiBod3BfZHJ2X2RhdGF7fSBh
Y3R1YWxseSBmYWlscyB0byBiZSBhbGxvY2F0ZWQgZm9yIGNwdXMgb3RoZXIgdGhhbg0KPiA+Pj4g
dGhlIGZpcnN0IG9uZS4gVGhlcmUgaXMgbm8gbmVlZCB0byBtYWtlIGl0IHBlci1DUFUuDQo+ID4+
PiBXZSBlbWJlZCBzdHJ1Y3QgaHdwX2Rydl9kYXRhe30gaW50byBzdHJ1Y3QgY3B1ZnJlcV9wb2xp
Y3l7fSwgdGhlbg0KPiA+Pj4gY3B1cyBjb3VsZCBzaGFyZSB0aGUgaHdwIGRyaXZlciBkYXRhIGFs
bG9jYXRlZCBmb3IgdGhlIGZpcnN0Y3B1LA0KPiA+Pj4gbGlrZSB0aGUgd2F5IHRoZXkgc2hhcmUg
c3RydWN0IGNwdWZyZXFfcG9saWN5e30uIFdlIGFsc28gbWFrZSBpdCBhDQo+ID4+PiB1bmlvbiwg
d2l0aCAiaHdwIiwgYW5kIGxhdGVyICJhbWQtY3BwYyIgYXMgYSBzdWItc3RydWN0Lg0KPiA+Pg0K
PiA+PiBBbmQgQUNQSSwgYXMgcGVyIG15IHBhdGNoICh3aGljaCB0aGVuIHdpbGwgbmVlZCByZS1i
YXNpbmcpLg0KPiA+Pg0KPiA+Pj4gU3VnZ2VzdGVkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+DQo+ID4+DQo+ID4+IE5vdCBxdWl0ZSwgdGhpcyByZWFsbHkgaXMgUmVwb3J0ZWQt
Ynk6IGFzIGl0J3MgYSBidWcgeW91IGZpeCwgYW5kIGluDQo+ID4+IHR1cm4gaXQgYWxzbyB3YW50
cyB0byBnYWluIGEgRml4ZXM6IHRhZy4gVGhpcyBhbHNvIHdpbGwgbmVlZCBiYWNrcG9ydGluZy4N
Cj4gPj4NCj4gPj4gSXQgd291bGQgYWxzbyBoYXZlIGJlZW4gbmljZSBpZiB5b3UgaGFkIENjLWVk
IEphc29uIHJpZ2h0IGF3YXksDQo+ID4+IHNlZWluZyB0aGF0IHRoaXMgY29kZSB3YXMgYWxsIHdy
aXR0ZW4gYnkgaGltLg0KPiA+Pg0KPiA+Pj4gQEAgLTI1OSw3ICsyNTgsNyBAQCBzdGF0aWMgaW50
IGNmX2NoZWNrIGh3cF9jcHVmcmVxX3RhcmdldChzdHJ1Y3QNCj4gPj4gY3B1ZnJlcV9wb2xpY3kg
KnBvbGljeSwNCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1
bnNpZ25lZCBpbnQgcmVsYXRpb24pICB7DQo+ID4+PiAgICAgIHVuc2lnbmVkIGludCBjcHUgPSBw
b2xpY3ktPmNwdTsNCj4gPj4+IC0gICAgc3RydWN0IGh3cF9kcnZfZGF0YSAqZGF0YSA9IHBlcl9j
cHUoaHdwX2Rydl9kYXRhLCBjcHUpOw0KPiA+Pj4gKyAgICBzdHJ1Y3QgaHdwX2Rydl9kYXRhICpk
YXRhID0gcG9saWN5LT51Lmh3cDsNCj4gPj4+ICAgICAgLyogWmVybyBldmVyeXRoaW5nIHRvIGVu
c3VyZSByZXNlcnZlZCBiaXRzIGFyZSB6ZXJvLi4uICovDQo+ID4+PiAgICAgIHVuaW9uIGh3cF9y
ZXF1ZXN0IGh3cF9yZXEgPSB7IC5yYXcgPSAwIH07DQo+ID4+DQo+ID4+IEZ1cnRoZXIgZG93biBp
biB0aGlzIHNhbWUgZnVuY3Rpb24gd2UgaGF2ZQ0KPiA+Pg0KPiA+PiAgICAgb25fc2VsZWN0ZWRf
Y3B1cyhjcHVtYXNrX29mKGNwdSksIGh3cF93cml0ZV9yZXF1ZXN0LCBwb2xpY3ksIDEpOw0KPiA+
Pg0KPiA+PiBUaGF0J3Mgc2ltaWxhcmx5IHByb2JsZW1hdGljIHdoZW4gdGhlIENQVSBkZW5vdGVk
IGJ5IHBvbGljeS0+Y3B1DQo+ID4+IGlzbid0IG9ubGluZSBhbnltb3JlLiAoSXQncyBub3QgcXVp
dGUgY2xlYXIgd2hldGhlciBhbGwgcmVsYXRlZA0KPiA+PiBpc3N1ZXMgd291bGQgd2FudCBmaXhp
bmcgdG9nZXRoZXIsIG9yIGluIG11bHRpcGxlIHBhdGNoZXMuKQ0KPiA+DQo+ID4gQ2hlY2tpbmcg
dGhlIGxvZ2ljIGluIGNwdWZyZXFfZGVsX2NwdSgpLCBvbmNlIGFueSBwcm9jZXNzb3IgaW4gdGhl
DQo+ID4gZG9tYWluIGdldHMgb2ZmbGluZSwgdGhlIGdvdmVybm9yIHdpbGwgc3RvcC4NCj4NCj4g
WWV0IHdpdGggSFdQIGFuZCBDUFBDIGRyaXZlcnMgYmVpbmcgZ292ZXJub3ItbGVzcywgaG93IHdv
dWxkIHRoYXQgbWF0dGVyPw0KDQpJbiBDUFBDIHBhc3NpdmUgbW9kZSwgd2UgYXJlIHN0aWxsIHJl
bHlpbmcgb24gZ292ZXJub3IgdG8gZG8gcGVyZm9ybWFuY2UgdHVuaW5nLg0KSW4gQ1BQQyBhY3Rp
dmUgbW9kZSwgeWVzLCBpdCBpcyBnb3Zlcm5vci1sZXNzLCBob3cgYWJvdXQgd2UgZGlzYWJsZSB0
aGUgQ1BQQy1lbmFibGUgYml0IGZvciB0aGUgb2ZmbGluZSBjcHVzPw0KDQo+IHN0aWxsIGJlIGVm
ZmVjdGl2ZS4gV2hpY2ggaXMgYWxzbyBjb21wbGllcyB0byB0aGUgZGVzY3JpcHRpb24gaW4gX1BT
RCBBQ1BJIFNQRUMgZm9yDQo+ICJOdW0gUHJvY2Vzc29ycyIgWzFdOg0KPiA+IGBgYA0KPiA+IFRo
ZSBudW1iZXIgb2YgcHJvY2Vzc29ycyBiZWxvbmdpbmcgdG8gdGhlIGRvbWFpbiBmb3IgdGhpcyBs
b2dpY2FsIHByb2Nlc3NvcuKAmXMgUC0NCj4gc3RhdGVzLiBPU1BNIHdpbGwgbm90IHN0YXJ0IHBl
cmZvcm1pbmcgcG93ZXIgc3RhdGUgdHJhbnNpdGlvbnMgdG8gYSBwYXJ0aWN1bGFyIFAtc3RhdGUN
Cj4gdW50aWwgdGhpcyBudW1iZXIgb2YgcHJvY2Vzc29ycyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUg
ZG9tYWluIGhhdmUgYmVlbiBkZXRlY3RlZA0KPiBhbmQgc3RhcnRlZC4NCj4gPiBgYGANCj4gPiBb
MV0NCj4gPiBodHRwczovL3VlZmkub3JnL3NwZWNzL0FDUEkvNi41LzA4X1Byb2Nlc3Nvcl9Db25m
aWd1cmF0aW9uX2FuZF9Db250cm9sDQo+ID4gLmh0bWw/aGlnaGxpZ2h0PWNwcGMjcHN0YXRlZGVw
ZW5kZW5jeS1wYWNrYWdlLXZhbHVlcw0KPiA+DQo+ID4gSSBrbm93IHRoYXQgQU1EIENQUEMgaXMg
b2JleWluZyB0aGUgX1BTRCBkZXBlbmRlbmN5IHJlbGF0aW9uIHRvbywgZXZlbiBpZg0KPiBib3Ro
IENQUEMgUmVxdWVzdCByZWdpc3RlciAoY2NkWzE1OjBdX2x0aHJlZTBfY29yZVs3OjBdX3RocmVh
ZFsxOjBdOw0KPiBNU1JDMDAxXzAyQjMpIGFuZCBDUFBDIENhcGFiaWxpdHkgUmVnaXN0ZXINCj4g
KF9jY2RbMTU6MF1fbHRocmVlMF9jb3JlWzc6MF1fdGhyZWFkWzE6MF07IE1TUkMwMDFfMDJCMCkg
aXMgUGVyLXRocmVhZCBNU1IuDQo+ID4gSSBkb24ndCBoYXZlIHRoZSBoYXJkd2FyZSB0byB0ZXN0
ICJzaGFyaW5nIiBsb2dpYy4gQWxsIG15IHBsYXRmb3JtIHNheXMgIkhXX0FMTCINCj4gaW4gX1BT
RC4NCj4NCj4gQWl1aSB0aGF0J3Mgbm90IG1hbmRhdGVkIGJ5IHRoZSBDUFUgc3BlYywgdGhvdWdo
LiBQbHVzIEhXX0FMTCBzdGlsbCBkb2Vzbid0IHNheQ0KPiBhbnl0aGluZyBhYm91dCB0aGUgc2Nv
cGUvc2l6ZSBvZiBlYWNoIGRvbWFpbi4NCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 11:31:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 11:31:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115149.1461871 (Exim 4.92)
	(envelope-from )
	id 1uva60-0005Tn-7Q; Mon, 08 Sep 2025 11:31:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115149.1461871; Mon, 08 Sep 2025 11:31: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 1uva60-0005Tg-46; Mon, 08 Sep 2025 11:31:40 +0000
Received: by outflank-mailman (input) for mailman id 1115149;
 Mon, 08 Sep 2025 11:31: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 1uva5z-0005TZ-KL
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 11:31:39 +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 61a5fe1c-8ca7-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 13:31:37 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-b043da5a55fso563461066b.0
 for ; Mon, 08 Sep 2025 04:31: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
 a640c23a62f3a-b042fcae867sm1840918466b.58.2025.09.08.04.31.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 04:31: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: 61a5fe1c-8ca7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757331097; x=1757935897; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6ChsJASznYJonQA/Njmso6wdUcVt+OwkSQTY44xwqQ8=;
        b=JcoCYlmQSQPMYH3CmTahUFsIkxNAExxD0FjQXlgd2cj7sIopSxiWyhPHCQFaPmd8DY
         ttL3h7uOB8FeRv2FRmFEGnANGQr2IFfYbYuVhCgjjq6JJXZsu6bh/NanWVTG9KE/nway
         SBEf+qJpVifFN9L7jeVAtstWJBjaMicyxqIlt3lnK5ff6HQ9IULJrqaRX4wYyZA4eD3w
         U7tVmCJo8Wly/K/fjHq9fYHVIwNPRu+G4iBFk7E6kWCni7lreIrdvFZHwJFuKxAHylE8
         93wPCZMZSwr/AenVWALEX/eJGJZQoOL7lWp48L2YAv9q7oNXhF4r7tdr76EA5v9J/pDZ
         fMHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757331097; x=1757935897;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6ChsJASznYJonQA/Njmso6wdUcVt+OwkSQTY44xwqQ8=;
        b=p6tZQ4hcuAURYJnE/MkkYZNh9trOY+BU4AjRtun/7H0zJaUUiiTmQW9/Jyo+qdes92
         oY9mKhODBoVoPi13AgXEDcybGrwGiihc26JNfg1H+u9zL+mpksCH9ewT2/kl/sypZcqM
         eVlk4L35QBu3z86ydgRtN5iVC0G6198/Y9m+6OKypIf5cIgtnJVOdZfitNU4Xdm/yjpf
         mDP56fei4RrL6K+9kcnsVaZ/YPWKx4C5kn4k01HtxSau82GwQHUwUla5frbBSJg2fG7R
         aO5oYL62245MRNNNedvxd5vw4XfIlKi1qhtwMP4rEhMVgpbLeLKZA8JwvunB8Y3dKybn
         NMQQ==
X-Forwarded-Encrypted: i=1; AJvYcCVbr/dBuLTB7JmfyjfNm/Q4vtFWygsTHMPOTsp+aqqaJGgHQ+Q9Epxuuek5nC1/imW1mqIOdBd10zQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdR7Sdu7XPUyf0ThNVHqF8tpk+MKu5txTajlt6xc0p7HMLAoYb
	8w2lBNZeDwEP6EfWyChxledN8Ebnk7m/SLvegkuei6ndiNoOUsVNo/panSysDpXPiw==
X-Gm-Gg: ASbGncspxRGRkWyGh6AU6BOCVE1Nn9ojyv7Wn0fEN+NIbfCNUn/ZoiXKMjHvz6bvDLf
	x58Fc1Wh4MTiZDJvg3Rrzr0Jh9SRrzBAy2UjEnzrjSK9rSKIhXJb91L7jCd5ycL18nzvRyfSTF+
	KcYc0IqQqxM/zKJyN0wS0DUJ/NzEEhnCIDo+eVSlf1TmKC+7zmoIG3CingbHjl7cTYDqfBQV8GR
	bLm8+CGLnV9GnPr0DJ1Zz5qb3k2I8zSBFY9dKpSiI/u5XDIuczsamOmuteYioAFlUXTxOzbjXtn
	jmOD+pHiWHCIndXKJYffPoFkDKzqeqdI6/07ZpXD4nN3QDuJu0N6+g1vb+hGDLuCMIxb9Fa81uH
	12O0yVyCqZ6MlEVg9IqIsvZP69LtZX8gS2WUe8co6UVdGn3Xvmc+6IrbRjIGHRs/i9HaRjGjQ2S
	1mFWwiOJEn7H5dqcNmQA==
X-Google-Smtp-Source: AGHT+IFSvyv1Vaz/+kqLO3e26IA45pl/JDuserIDeKkHKEi98EUgW81rOD5EZ/1Ut8Et0Pheo/WUXg==
X-Received: by 2002:a17:907:5ce:b0:afe:a6d3:b4a2 with SMTP id a640c23a62f3a-b04b13d2117mr784185566b.11.1757331096736;
        Mon, 08 Sep 2025 04:31:36 -0700 (PDT)
Message-ID: <6f70da02-c331-4332-b609-68a258d8e630@suse.com>
Date: Mon, 8 Sep 2025 13:31:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
To: "Penny, Zheng" 
Cc: "Andryuk, Jason" ,
 "xen-devel@lists.xenproject.org" 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@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 08.09.2025 13:28, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, September 8, 2025 6:02 PM
>> To: Penny, Zheng 
>> Cc: Andryuk, Jason ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct cpufreq_policy{}
>>
>> (re-adding the list)
>>
>> On 05.09.2025 06:58, Penny, Zheng wrote:
>>> [Public]
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Thursday, September 4, 2025 7:51 PM
>>>> To: Penny, Zheng ; Andryuk, Jason
>>>> 
>>>> Cc: Andrew Cooper ; Roger Pau Monné
>>>> ; xen-devel@lists.xenproject.org
>>>> Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
>>>> cpufreq_policy{}
>>>>
>>>> On 04.09.2025 08:35, Penny Zheng wrote:
>>>>> For cpus sharing one cpufreq domain, cpufreq_driver.init() is only
>>>>> invoked on the firstcpu, so current per-CPU hwp driver data struct
>>>>> hwp_drv_data{} actually fails to be allocated for cpus other than
>>>>> the first one. There is no need to make it per-CPU.
>>>>> We embed struct hwp_drv_data{} into struct cpufreq_policy{}, then
>>>>> cpus could share the hwp driver data allocated for the firstcpu,
>>>>> like the way they share struct cpufreq_policy{}. We also make it a
>>>>> union, with "hwp", and later "amd-cppc" as a sub-struct.
>>>>
>>>> And ACPI, as per my patch (which then will need re-basing).
>>>>
>>>>> Suggested-by: Jan Beulich 
>>>>
>>>> Not quite, this really is Reported-by: as it's a bug you fix, and in
>>>> turn it also wants to gain a Fixes: tag. This also will need backporting.
>>>>
>>>> It would also have been nice if you had Cc-ed Jason right away,
>>>> seeing that this code was all written by him.
>>>>
>>>>> @@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct
>>>> cpufreq_policy *policy,
>>>>>                                         unsigned int relation)  {
>>>>>      unsigned int cpu = policy->cpu;
>>>>> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
>>>>> +    struct hwp_drv_data *data = policy->u.hwp;
>>>>>      /* Zero everything to ensure reserved bits are zero... */
>>>>>      union hwp_request hwp_req = { .raw = 0 };
>>>>
>>>> Further down in this same function we have
>>>>
>>>>     on_selected_cpus(cpumask_of(cpu), hwp_write_request, policy, 1);
>>>>
>>>> That's similarly problematic when the CPU denoted by policy->cpu
>>>> isn't online anymore. (It's not quite clear whether all related
>>>> issues would want fixing together, or in multiple patches.)
>>>
>>> Checking the logic in cpufreq_del_cpu(), once any processor in the
>>> domain gets offline, the governor will stop.
>>
>> Yet with HWP and CPPC drivers being governor-less, how would that matter?
> 
> In CPPC passive mode, we are still relying on governor to do performance tuning.
> In CPPC active mode, yes, it is governor-less, how about we disable the CPPC-
> enable bit for the offline cpus?

Didn't you say that's a sticky bit? Plus how would this help with the issue
at hand?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 12:27:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 12:27:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115176.1461887 (Exim 4.92)
	(envelope-from )
	id 1uvaxJ-0003Sy-9d; Mon, 08 Sep 2025 12:26:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115176.1461887; Mon, 08 Sep 2025 12:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvaxJ-0003Sr-79; Mon, 08 Sep 2025 12:26:45 +0000
Received: by outflank-mailman (input) for mailman id 1115176;
 Mon, 08 Sep 2025 12:26:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvaxH-0003Sl-Js
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 12:26:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvaxH-000499-0u;
 Mon, 08 Sep 2025 12:26:43 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (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 1uvaxH-0009sv-0l;
 Mon, 08 Sep 2025 12:26: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-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=BwOSZGgZjqFAteTl5Je24LHMAr0oxKtArk45OrKFtno=; b=q4ns9vVZvsir8RIgY7zewQpUUp
	2w27jMnnjjYAvMCjkOamDYnU1otxocKYZVUXPIpVsx1JcsAOHRakbXiUtO0yhAaHifKlHiE4BH2TV
	bHCvsTCpjTpjFe2k7+PPFjLb0duA4pDQKlobKlVUoM9iXrjlsSi1eIJtS00C7fb+qXOM=;
Date: Mon, 8 Sep 2025 14:26:40 +0200
From: Anthony PERARD 
To: Jason Andryuk 
Cc: Jan Beulich ,
	"xen-devel@lists.xenproject.org" ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH] libxl: respect unset video_memkb for Dom0
Message-ID: 
References: <719c456b-927d-41c3-b28d-135a895958dd@suse.com>
 <01f134a0-46fb-40d8-924d-79ab864352e9@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01f134a0-46fb-40d8-924d-79ab864352e9@amd.com>

On Wed, Aug 27, 2025 at 09:12:50PM -0400, Jason Andryuk wrote:
> On 2025-08-27 01:56, Jan Beulich wrote:
> > Without this, Dom0 will have have a curiously off-by-1 target_memkb
> > value displayed by "xl list -l".
> > 
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Jason Andryuk 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 12:40:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 12:40:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115198.1461901 (Exim 4.92)
	(envelope-from )
	id 1uvbAG-00066e-Dd; Mon, 08 Sep 2025 12:40:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115198.1461901; Mon, 08 Sep 2025 12: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 1uvbAG-00066X-Aq; Mon, 08 Sep 2025 12:40:08 +0000
Received: by outflank-mailman (input) for mailman id 1115198;
 Mon, 08 Sep 2025 12:40:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvbAE-00066R-OX
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 12:40:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvbAE-0004Oh-1Z;
 Mon, 08 Sep 2025 12:40:06 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (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 1uvbAE-000AqQ-1Q;
 Mon, 08 Sep 2025 12:40:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=LKrQf42PX7PPTfH1KO/Y9I8QjeGk+y1kUYYQZKxEP0w=; b=0vlEO8y6HHLg6PKRaSaMxk84oG
	AYvnx8fdewIejU2VDBVyyoDDD/wIOkBnE3YYYFoufYBY8EfLbx+BErtk+3xJu9FfORsGKBg7vSGfo
	Xmp4HIKor55Y8NLcMBFSS8mCGXEcgEi6qCD5IJQf17RwKUzh7z8ZGXR2fPutMWHFRJrQ=;
Date: Mon, 8 Sep 2025 14:40:04 +0200
From: Anthony PERARD 
To: Jason Andryuk 
Cc: Jan Beulich ,
	"xen-devel@lists.xenproject.org" ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH] libxl: preserve errno in libxl__xcinfo2xlinfo()
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Wed, Aug 27, 2025 at 09:16:38PM -0400, Jason Andryuk wrote:
> On 2025-08-27 01:57, Jan Beulich wrote:
> > Callers observing errors elsewhere may be confused by the ENOSYS that
> > the Flask operation would yield on a Flask-disabled hypervisor.
> > 
> > Signed-off-by: Jan Beulich 
> > ---
> > Of course I don't know whether clobbering errno is perhaps deemed "fine"
> > in libxl.
> 
> I wonder if it would be better to special case libxl_flask_sid_to_context()
> to preserve errno on ENOSYS.  flask returning ENOSYS is common, but
> libxl_flask_sid_to_context() can legitimately have error.

Well, errno=ENOSYS gives information about why
libxl_flask_sid_to_context() returns an error. 
They are multiple error code for returns libxl_*() functions but they
aren't really check. We often rely on errno to print an error message.
And in this case, libxl_flask_sid_to_context() doesn't event return a
proper libxl_error value.

> I guess this is fine if we want to use this approach:
> 
> Reviewed-by: Jason Andryuk 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 12:45:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 12:45:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115208.1461912 (Exim 4.92)
	(envelope-from )
	id 1uvbFh-0006gl-0Z; Mon, 08 Sep 2025 12:45:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115208.1461912; Mon, 08 Sep 2025 12: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 1uvbFg-0006ge-UF; Mon, 08 Sep 2025 12:45:44 +0000
Received: by outflank-mailman (input) for mailman id 1115208;
 Mon, 08 Sep 2025 12:45: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 1uvbFe-0006gY-RC
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 12:45:42 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20613.outbound.protection.outlook.com
 [2a01:111:f403:200a::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b6fbf782-8cb1-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 14:45:37 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by BN7PPF915F74166.namprd12.prod.outlook.com
 (2603:10b6:40f:fc02::6d9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Mon, 8 Sep
 2025 12:45:29 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9094.017; Mon, 8 Sep 2025
 12:45: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: b6fbf782-8cb1-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RdxQVyLbcPIzsM6sX7q8x7QmTn6cnd1lfXvY+FyzL1eEYsJhq9FOb6iapvK1Vz5owlYgWdY9IcbGDYG8U3EX3/aLA0nDcCYTJC7wHenAsnAO4Czyl77gaCg7SpKYxFc8vCEpuna490IbfIxsgf/ViI+4fzVEemqsS3aVW9Y2MZhLbVZX/uF/wNgSpbNCUvPBsT3kU7vL621wcjdrvJSbzaGGNtfbB6NLqSbDi0YipLdWfMOWLkamlIDFiHR9w25kDbwO3pu7Wt69fsWct0/Y9gw6jnJwFKcl+JSZ7v3pWCEiKmz6+YXiu/WBXR8/4CyQC2eB+n0kBVADV5jrPd0Tzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kVtJy3VxH0BzMR5kUXXhlP/z9wRsHc79lEhpuG67Dec=;
 b=o3stciIRY0cSJ/aOoKNOmkPUysvopr5Wx/viD+gEzJmMnFkak7IdVhQbwrw7tsvA6T0FYwu2yQ5Nwoyj9qlnzkWKTaMRsALckATri7XTNhou0MLIyx2PuHCYXgCae/ZCpiwvzum50SCvDdvYJ4RAuY+eym69GzWs317bloT3QfKrPljCpgtlwN9FbC+UElJQ9nliFQDE2C/dHiswGGaVahPyeZI/oP7dvf56EbFJdVUZTHCqKDWGl3FY8GPa0201Ebw/riZkCBLrxZ0fJZQfdLnHV7BMPixp9lP7coa48gsTnOOWWAkA9bdBVWwItKKN47qeov3W/7ZsaJHd45YQhQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kVtJy3VxH0BzMR5kUXXhlP/z9wRsHc79lEhpuG67Dec=;
 b=TTXRCLKbvDNzd5KMxBGwU4icKF5zN/F9rZAVOPQTpmAe2H1urLUqSZ2vgAtmyfMBWf2HsCCEc4/WtbChsSNi/3Pv1Zjk4Hw/+mt+mAwb/ciAqfptFuWataPLXR/6jj9igzgfifaMhvXm2ezJ1OpLfQ6e2qbAr7QTqZ77/fkcJxFV/bBTDr1R6ILLENwXsFGUIay1tWYhYlgNNt9JznW+pdjZ1NeaJ4gwuVbS8dzJhOiLGhFS/5QRDDAetxRUDr7ApoBQvjvcnk/iLP4GU5Wki5LlxIOK4JHlJVE6cLyfmXQCp9wzQYACVXV12CbG7qHf++PrC5Zn1ciQzJNCTG1moA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Mon, 8 Sep 2025 09:45:26 -0300
From: Jason Gunthorpe 
To: Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	iommu@lists.linux.dev, Jason Wang ,
	Jens Axboe , Joerg Roedel ,
	Jonathan Corbet , Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250908124526.GW616306@nvidia.com>
References: <20250905174324.GI616306@nvidia.com>
 <20250907142509.GA507575@workstation.local>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250907142509.GA507575@workstation.local>
X-ClientProxiedBy: YT4PR01CA0305.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:b01:10e::13) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|BN7PPF915F74166:EE_
X-MS-Office365-Filtering-Correlation-Id: a297ed27-88a7-4d5b-a32b-08ddeed59743
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|1800799024|366016|921020;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?+6uZKrS/rFG7MRbc+Kg/J4Ot96foh2BlZEiEN1Gc4OuIi39qI6yHkY4PEkfG?=
 =?us-ascii?Q?jA/PRoUyT1q+EIGXzX7t0ApHKIxeYDeEAl20/rgmrNPntcmc8Iivg+AMC3Lw?=
 =?us-ascii?Q?WOAXYZ1L6evCFL9T/bmJmFODQWdI2MH4oHxaX1HopkzRh91IxyGj+9peL8RV?=
 =?us-ascii?Q?9fSFLbno4AmTJ1fSiEIyyohEE064gEroDSm8XNq/MB8OEEMKSIj0TriT3Ssw?=
 =?us-ascii?Q?VortqCOKPGT2hv8cT1JPF44pejI0n1LsWAyFLR1gutdbrehx8vokd3u6KVqI?=
 =?us-ascii?Q?GgPqNSiI3YrCnTVCk+Tz3GPC0uJ5ZIw2yNL/us3HAvbtqxm100PlHVaPKdYe?=
 =?us-ascii?Q?2V7O9MKWWOQeDozXhmfBSqmAUYFqt1oH5vl0hq4APA24BfIXU+HWhyrEsuz+?=
 =?us-ascii?Q?wq0KXWfVrz0k82RLqVQZ/J4eKXhnTPDrOA7AaaickgYp0gQu1EwhU7ifJqHV?=
 =?us-ascii?Q?rqQ23Oqz9AD/ntgir855KqvA3s5THBgyckszj+V270BVldG2vBOQkZhkBQia?=
 =?us-ascii?Q?e/Tr7EoOPpmzkqHbtsiw0H68hrG0eqMTcuE6RCl6X8SmIa+hl/4V2lg41ndB?=
 =?us-ascii?Q?EuqxZyKqlPaSw2MjBw8QvvlvhUWWiUpC97XjmiGOrmU5+WoChm8Zts5NOuVt?=
 =?us-ascii?Q?A8Ki/8+2p7ahT+pimvRT2prrUpAQcHs5cA/Fx4PDgspNgL/FwIU7g7Hccb+H?=
 =?us-ascii?Q?aqiEjctDv2j+q294LXOSulq2fbOjnK1RZtOSSVSPy1WhZZ1Alz3sTuPF99tO?=
 =?us-ascii?Q?udZXTc4yis+0F+KaFGNDjVCDRJc+lOAocmfLdbmKFPwbbIjX3mPFE7zajQd5?=
 =?us-ascii?Q?qfo7G1Gfvl2ydc15Lpk0AS5qoTk9zwU54HbX9pg74pg8KTlE5hRf+Pa5ocmO?=
 =?us-ascii?Q?cHlGOnwIcdwg2nys8IcpbhTR9gkPhnBbid/BFf6fcWoN3cpUWYOylZPFUk03?=
 =?us-ascii?Q?HywyUTCqV/tnz1EUkeEfa291hPquovP6yvS2pL9GrerxVbQaXpVgzcTJLbIg?=
 =?us-ascii?Q?+8EYx0FmnXIPtYM4tFEY3dbme+u69ebfrxAQIKIQVCNwN+nDWv0FHN5t7hbf?=
 =?us-ascii?Q?RzY9nK7LKxC9CAhWPmtD/3kHWAlIPWMC61O7+alpounDIUmQRJl3h+RGct+y?=
 =?us-ascii?Q?6eCVWNGJZe+TjhGMDjxpT33n6ZSxSyUd84vSC8czzPWG4JS/IhDOzsvQ7yDq?=
 =?us-ascii?Q?56yBS+5JjbfIywsP/qiEAV728XS198lNNAFaAmKvHE9QknNxJQTLoX29Kgl8?=
 =?us-ascii?Q?5WqbAaDpYtAJhHDkND5bkNY455cdXsjt0XTjDWEbD9A1p/r6J4Yf7kIXShZF?=
 =?us-ascii?Q?/IouUBTbEb9MU4sDMEZz8eKXYjmBhmh/Da085uGm9qmpvGAmnhn/4G5G2r+R?=
 =?us-ascii?Q?jOMfKZc3Z1rR6MN+r7VxpOBLd+Th1pqOiT7cDdD8m9TfkRZoSjdxvivtFHft?=
 =?us-ascii?Q?YZW6miCbA+sYYRu1iRXK+Yn5tSAnkNiRV8QX/Ztjw3FUI5xRUysfEA=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?VaRDYGzlyPZ446X9cUFcoyBn4ZNwDpZl+Wn1SszX+e8axirqjy+8nBXqF20N?=
 =?us-ascii?Q?9aKtqeEbs0Jq8B7NCS/khSfonEox/eWnFHb6kOf966QYkVg/ET8FoUvKKqBs?=
 =?us-ascii?Q?V3SUQYRMwHo9y8uXX3e/RdmPF/pmvKhvdm0Spa61mTHuGNXRojfrkkKuaOSU?=
 =?us-ascii?Q?h8XBNpQ8CHYvnI0fJHnJc2RyhrnvyE/7KZ1ah9zOSyDw2D6SqGFiMN5S454N?=
 =?us-ascii?Q?9CUDie0XpqHCbhArrhnYqWk5yEPecvZDL/ADhpHbKH+XYubEnKJZraeW4uor?=
 =?us-ascii?Q?8lEdL7JGpHDvrxXJ2JFAXFwbTCLSVPFx+xVqa1N1ByLX1AIjkCTQXU9th90X?=
 =?us-ascii?Q?Z2YrgDTc9Lq2tLjCMN6A6a08AckBGfEaFnPnABhrWuGD6Dx/DUECxnxL4Smm?=
 =?us-ascii?Q?j180nsWWH0EKFvhP/fwJuixzWKoj1gQL4jWDtJBormM/nSEDvS2OKF+4SVZ9?=
 =?us-ascii?Q?zxK2/RCBGAAdzl8uV0xrBNNFkpkRAnlez7v2PCxpTEzfAuollRpheC1xqfht?=
 =?us-ascii?Q?3HjN8M0xDa4a0wr8CW65uMdG1gwwRt9qrU5jnaWgT2n5gicGXcRSAdrRhx2a?=
 =?us-ascii?Q?/XmGx/189f0TGjStS02vZHAtQ3L5vtToX4bGwAKFAUq479985fhUESmNttMA?=
 =?us-ascii?Q?6Q2vmD6vLFaWZGjjpAY3kTV5LVzOtcFf7w16oM+Hddu70x29LoG42kbaNSGm?=
 =?us-ascii?Q?1lJm3SXmb2ykDFOcSeYoT/GONUv2ewDZqf7gh4rs8oA1HHXhs5UqzY2r3QJQ?=
 =?us-ascii?Q?/VOjHqme64F4KM8eT/nGkZeryj3tBQZ00Om5sH++YOs4GxP4TthE7mjG9o1/?=
 =?us-ascii?Q?+NREwv4TdTRck4CFdchOtToNAVaFsdjRNTXm6iC4oYgvGhvrKLBErUBPlCJI?=
 =?us-ascii?Q?wM6BKktsOqabF1AcVFQDveUBB2ClsKavMm1QNxk7j1UDVX6t0mZUvW8c0AWL?=
 =?us-ascii?Q?WLBJfWnMeOHkFjgkxv8t8rAbh6zXRa4kufED8fRgRu6RJ8Q0rg4V81zwsWQT?=
 =?us-ascii?Q?MwbMgIvsOD+RH4YMG85gaI87L8e4duL2bwy3WNN0OLmdqp33FDZ/e4D97/GJ?=
 =?us-ascii?Q?0CXch8MTyrNJvUgn3Ngw98JmGAOCsAAcutZbuaLFNbdfEBQVicuoUpHDnIyg?=
 =?us-ascii?Q?QGZFX8AolMrtqoIKanyrjxkT9NbIT+G0mDhu5k2puPxH+HKCAAqSUi7cmpiC?=
 =?us-ascii?Q?0yMmruH1U6FSi9mmYUfHUd5wY9LGYJGPiGtc2LQZx6wYSmVeVdp8bWT04woR?=
 =?us-ascii?Q?Y2RtqT6jhSLWiIxIAfZJE+xzPzLHyCBCRVL1/0s1ZJyqd54qkpczi5Ee4MhE?=
 =?us-ascii?Q?EhR+5d9FZQG6oAWosn95jIuApoA/2+iVxkRbpYQMoQJDUzegBmVqovtmhCbS?=
 =?us-ascii?Q?G9bErnrTylhfFf0su/qLKauImRiYfpG2bv15tp1wxP6EIrokn7NqJBrpF2fV?=
 =?us-ascii?Q?dsytqeOyByJ1NKoQ3EBtGBe2ts4yIFdPjYbAd7U5CCARf9OsQF01liBQECFV?=
 =?us-ascii?Q?lmxnQJL/+8WPn4LrX61pDLzje5ZofXzt0MPyPqqFj6keh/m1o8Rf/X29YzX7?=
 =?us-ascii?Q?pyTTDKVvBwcaN+fjkt4=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a297ed27-88a7-4d5b-a32b-08ddeed59743
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 12:45:29.4369
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: MpjeEYUBSzxhLqO+CFbT2nbSUFImadVFjjLPJK1baSpu1/pO2lfM5uOGwpCMQBKu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF915F74166

On Sun, Sep 07, 2025 at 11:25:09PM +0900, Takashi Sakamoto wrote:
> Hi,
> 
> I'm a present maintainer of Linux FireWire subsystem, and recent years
> have been working to modernize the subsystem.
> 
> On Fri, Sep 05, 2025 at 14:43:24PM -0300, Jason Gunthorpe wrote:
> > There is only one user I found of alloc_pages:
> >
> > drivers/firewire/ohci.c:                ctx->pages[i] = dma_alloc_pages(dev, PAGE_SIZE, &dma_addr,
> >
> > And it deliberately uses page->private:
> >
> >		set_page_private(ctx->pages[i], dma_addr);
> >
> > So it is correct to use the struct page API.
> 
> I've already realized it, and it is in my TODO list to use modern
> alternative APIs to replace it (but not yet). If you know some
> candidates for this purpose, it is really helpful to accomplish it.

I think for now it is probably OKish, but in the medium/longer term
this probably wants to have its own memdesc like other cases.

Ie instead of using page->private you'd have a

struct ohci_desc {
	unsigned long __page_flags;
	dma_addr_t dma_addr;
[..]
};

And instead of using page->private you'd use ohci_desc::dma_addr.

This would require changing dma_alloc_pages() to be able to allocate
the frozen memdescs..

Which we are not quite there yet, but maybe come back to this in 2026?

Jason


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 12:46:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 12:46:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115216.1461922 (Exim 4.92)
	(envelope-from )
	id 1uvbGO-00078p-98; Mon, 08 Sep 2025 12:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115216.1461922; Mon, 08 Sep 2025 12: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 1uvbGO-00078i-6M; Mon, 08 Sep 2025 12:46:28 +0000
Received: by outflank-mailman (input) for mailman id 1115216;
 Mon, 08 Sep 2025 12:46:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvbGN-00078V-Pj
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 12:46:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvbGM-0004Vk-27;
 Mon, 08 Sep 2025 12:46:26 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (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 1uvbGM-000BSV-26;
 Mon, 08 Sep 2025 12: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" 
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=g8Wde7otiGDvQnOxBP+3ihDVLWXYjQowItN+OPEMf+M=; b=7FcG5par7DyTtjWgGOk3qRIKxR
	T9iJ3cTO3V0/A5ioBZwVsEvihvJoe1v+upQTT9Em+9bF0WYacYyqV6BsReTL4Uva/ElaqWVuA/GyX
	xF/U3cbDKktwUWvSoHFCr73hjnC4xnk7QGJ86KoAoFvGm9IrI0OqlaZU5bdWdyM9/ODQ=;
Date: Mon, 8 Sep 2025 14:46:24 +0200
From: Anthony PERARD 
To: Jason Andryuk 
Cc: Jan Beulich ,
	"xen-devel@lists.xenproject.org" ,
	Anthony PERARD 
Subject: Re: [PATCH] libxl: except Dom0 from setting PoD target
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Wed, Aug 27, 2025 at 09:08:10PM -0400, Jason Andryuk wrote:
> On 2025-08-27 01:53, Jan Beulich wrote:
> > Dom0 is never started in PoD mode, and hence it can at "best" do harm if
> > we try to set a PoD target for it.
> > 
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Jason Andryuk 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 12:49:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 12:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115227.1461931 (Exim 4.92)
	(envelope-from )
	id 1uvbIv-0007jn-L0; Mon, 08 Sep 2025 12:49:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115227.1461931; Mon, 08 Sep 2025 12:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvbIv-0007jg-IU; Mon, 08 Sep 2025 12:49:05 +0000
Received: by outflank-mailman (input) for mailman id 1115227;
 Mon, 08 Sep 2025 12:49:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvbIu-0007ja-B0
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 12:49:04 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20627.outbound.protection.outlook.com
 [2a01:111:f403:2407::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 31cec0c1-8cb2-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 14:49:02 +0200 (CEST)
Received: from BY3PR10CA0027.namprd10.prod.outlook.com (2603:10b6:a03:255::32)
 by MN0PR12MB5737.namprd12.prod.outlook.com (2603:10b6:208:370::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.27; Mon, 8 Sep
 2025 12:48:58 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com
 (2603:10b6:a03:255:cafe::b5) by BY3PR10CA0027.outlook.office365.com
 (2603:10b6:a03:255::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 12:48:58 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Mon, 8 Sep 2025 12:48:57 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 8 Sep
 2025 05:48:56 -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: 31cec0c1-8cb2-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wPWn8qIgSkTf1qQnPkxNlH+nSpl9bg445X8+3OS6QM4ynDLv1VRU6D7JdFw2bLibjPo55bgvSrzq1cWBcMmatI11BNiJbeHZLGb3y2cquaSSwVRPy5K7lk9wHktgoBzWb0QQKHxoaqB2cgRXstm0Ehj1lsweCGCj4MkoM50Oz4IF7DqQSml//cfmDfI2oyBGeS/v9WiQ3O0/2pM6e+pv+EVZ6BjQFRWQny8ne2YC3z5/AcsTBGAhvjJUuQbZU1m4ff+DzhPNtHV4gplw00NAKDWgTHb+NxSavk8Bovz8LtZlzr67PmezgxrepWnPW0L9TY6vhXkj3CR5a8frMSQ42Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZGJ3macmuZXuTtMYG3B2beZsSs4EKXW6dNRScVRlVrs=;
 b=Q5n0slTRXBTKCJ/u1ID0gJX3bZ3XVUwPaG6c/TwK6ydpjD3IXltKO0wx+rOspU+CcHK+feNhq2MOa6Eu+/i/KOKTswv/FKJapQCv6c3zI0+eDX6nsqnYLatIECqTYphSmKR/2ugQqhxlsiO5CvqZ3vHXErw66a2287JMh+37w1cUw3St77B4ThfMzTe9zZ8IRY93h+TBWPiwsB+rlHRDz2vx/p4nFpuWged1gpO4D+WbI/v3FLMG+KL++gGaHJ33U5whA0xMTSn/LHuVZBppiYvXDJ/JjJ9u31u4qmx34IYop2x+3lo+isLtY6HrljIWiHX+3fMnKk0EuZ0qN3B/4w==
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=ZGJ3macmuZXuTtMYG3B2beZsSs4EKXW6dNRScVRlVrs=;
 b=Ycco47IDBmQYFj4UoAZL4NRcs3Ca5nZX0L+f2gLSWFahasT3W3BAzm0L0BRey5vyXT5wO1Hy+0rIq3PI1NV1k83xMxL0+Ibcct4SEga08Ekm+dNgV1wPh+aXzMj27FDL4zuiE2H3yskM0iVxyt2qh7WYffmg6m+Ckc7de3PD0XQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 8 Sep 2025 14:48:55 +0200
Message-ID: 
CC: "xen-devel@lists.xenproject.org" 
Subject: Re: New Defects reported by Coverity Scan for XenProject
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail> <77361e51-dcb8-40e2-a526-9ff90ba942a2@suse.com>  <9e474109-7aa1-42b9-9fa6-31c4ef0fb856@suse.com>
In-Reply-To: <9e474109-7aa1-42b9-9fa6-31c4ef0fb856@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CDE:EE_|MN0PR12MB5737:EE_
X-MS-Office365-Filtering-Correlation-Id: 11ee33da-6898-4052-dcb6-08ddeed613ed
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?T3J5V2t2cUNIeThreStDOEdua25OM29ZdThRTWZFVVRFTnZHVDZKS25FWlJk?=
 =?utf-8?B?OU9MMnBWNEpkZnB0TjJHRkdnWU8vZUduLy9oK3dqamY5bWptS1Y3ejdIYTVu?=
 =?utf-8?B?enJabU5BQ0JjQXU5NWl3SUVkVUI1S2lTS0dEL0lMK29aZDZMVnZ2dkZ0dklz?=
 =?utf-8?B?ekVWMTZxL1dyRENCbzk3N1RtdWx1SUNjcnRtZDFxRWhsTFNBUHlqMTJOcXVV?=
 =?utf-8?B?TndHdmdoQWsvWnd3UlN4aC9xQUtQZVRrUWxpRzl4WTZtUUJ0ZE5pTU9OWDFF?=
 =?utf-8?B?REMyWXJYczFQZ0w5UmxJZ2luZDhaRmswd2tPMXpjRjhLbzEyUFpFbW91Wk1I?=
 =?utf-8?B?V0xMVWluSTEzWFBOSFJaSTJ2cXRTTTBPZE5lYUxDS28zbFNDQmNETzBRbVVU?=
 =?utf-8?B?aHJES0FCZHNrM21KMkloZjdHK1JiMHk0bVo5NlA2a2lwTWl4cEFDUnRLY2h6?=
 =?utf-8?B?anowSTUrT3RibGdlR1liK3JHV1JyVmpMZS9PRDRnZ2IrY2JKc05EZWZ1ZXJG?=
 =?utf-8?B?RGRRbEZDY0JvdU5DbEVneFF5NGZOeXlaamdJNDJlMThJVnQzbGJ4c0daclpq?=
 =?utf-8?B?bGdIYS80UytkR1FsSWNEc0kzUXFuQURGZGN3S2ZTM1ZySjJ1dC9XK3MzUDBQ?=
 =?utf-8?B?SHBZK3BYa2MxVmFFWTJqMjJPdUtqOUVhdWlRalorNnFjeVh3SnJwTE8va3hN?=
 =?utf-8?B?dlRzT1ZMQmlDaUJTWS8wdWhWQ3M2RzhiakQzZnBEOUhlMjhROUFSUVNPemRs?=
 =?utf-8?B?SjVaaXpQMjN3elVnc2RuVVFVRHJVaDh5SXhCMXhUUUhydlQvcVZJS0FjRW1a?=
 =?utf-8?B?SklhSFpwRUVQMzZxTkFHOTcxaGN1NU1lMEs0Y2hKKy9NOUdJRjdOdG5zRUQ5?=
 =?utf-8?B?a09KK1ZCdUxvWXp0L1JvQlZLOVR3aWtaV2t5eEdFUkJGckZwVlhRL3NZOER5?=
 =?utf-8?B?T0lGdU5tWWNJU1pBZUNNZEttRHZNM2lQOXA1L1QzQ1FxZDZKTVZKenNqSVJt?=
 =?utf-8?B?b0VMVm1kbkVEQzZtQXhxOUN4M2daVDZxU1hTSkJWbFN0SzZyK3QybHR1SG5O?=
 =?utf-8?B?MXV5UHd1QlV5TTBjNDVXb1BPRVdGRVV3TnZ4c3RkVnJsVXBHUTI3djI0UHFL?=
 =?utf-8?B?OWR1elBmcVJCengxdFZaQS9CNjM4ODhoL1p0bUNBUEhMSEo5dXlpMHpONlJG?=
 =?utf-8?B?Z2FHb1pMMGhMNCtSeS9YMGprbFBVZHVZdU5FMEVIdXg0cUJXZitOSVo2T3hr?=
 =?utf-8?B?TmZNMmIybm5maHAxUVNMb21Ham5kWjZ0QjlMKzNxaXVNMmVjak9CVjNtR1Fr?=
 =?utf-8?B?NFFQekU3bURpUS9QRmVEcDFVdmpKS3A5MGlPc2dYeTl2YjRBZWtFenlpYk9V?=
 =?utf-8?B?UTdWNjg3YmRzc1JnM0FnVGYrT3kxYy9kUW9TVSs3bzh3c0ZoZjJwNStuS3dG?=
 =?utf-8?B?TUZ2TDJXaC91dHZxMUxkMHVOc0lQYWwyUUpuNEpnUUVlOVpGaFRNbWRBRTJp?=
 =?utf-8?B?Zmp3Sy95bzJHSkNZbVFPWjJjNDdtaG5udW1Bd0NPWXlFUTNNMytscHIxcmo1?=
 =?utf-8?B?U3dsM1NETVZ2dFRzOGhUbXJMSGdVeFVjdEdqSEFoUm5DNTJLbVR4eW95WGgw?=
 =?utf-8?B?VXFOcHJLeEwxVDNVL0dJMGFpKzRpRlFtbGszd0h6ZFNhK241Ky9jYXk3TG9U?=
 =?utf-8?B?SHBrdmQ4ZjluUWl0bWVROXdZZ0loVU9peVI5SlJJMUNlZmVQdFJ5aWhQTEps?=
 =?utf-8?B?YXdFWndid1NMWkV1ZTNtaWFOVDBXUnlYUlVIMG85TzlxS01PMUZkckFkaWEv?=
 =?utf-8?B?TkRKYzgwanFiMW5YdUdhTm00b2pCR0c4R0tEbUM5bDNDVlZ3bjBmRDBHQmg5?=
 =?utf-8?B?WGJuc3I1ZHdCSW1idjQ4VlJKVFNHVk0wN0FGTmJkNmUwcEJVSXJEK0FnT2pF?=
 =?utf-8?B?dGtaLzFSVE50RkRNbHk0VjNvc1BvbXUxbVE1Z1I3RkFwY1VFandjUDFHSUg1?=
 =?utf-8?B?YkIvV2N0cDdvWTRiaGNiSXRuN2F0UThkbUE1MDBDWUJFTlJ1cW5qUUExa090?=
 =?utf-8?Q?DEFNvu?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 08 Sep 2025 12:48:57.9912
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 11ee33da-6898-4052-dcb6-08ddeed613ed
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5737

On Mon Sep 8, 2025 at 1:25 PM CEST, Jan Beulich wrote:
> On 08.09.2025 13:04, Alejandro Vallejo wrote:
>> On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
>>> On 07.09.2025 16:37, scan-admin@coverity.com wrote:
>>>> ** CID 1665362:       Integer handling issues  (INTEGER_OVERFLOW)
>>>> /xen/lib/find-next-bit.c: 104           in find_next_zero_bit()
>>>>
>>>>
>>>> ______________________________________________________________________=
_______________________
>>>> *** CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>> /xen/lib/find-next-bit.c: 104             in find_next_zero_bit()
>>>> 98     	}
>>>> 99     	if (!size)
>>>> 100     		return result;
>>>> 101     	tmp =3D *p;
>>>> 102    =20
>>>> 103     found_first:
>>>>>>>     CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW=
)
>>>>>>>     Expression "0xffffffffffffffffUL << size", where "size" is know=
n to be equal to 63, overflows the type of "0xffffffffffffffffUL << size", =
which is type "unsigned long".
>>>> 104     	tmp |=3D ~0UL << size;
>>>> 105     	if (tmp =3D=3D ~0UL)	/* Are any bits zero? */
>>>> 106     		return result + size;	/* Nope. */
>>>> 107     found_middle:
>>>> 108     	return result + ffz(tmp);
>>>> 109     }
>>>
>>> I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simpl=
y
>>> 0x8000000000000000UL, isn't it? Where's the overflow there? There also
>>> cannot be talk of a 32-bit build, or else ~0UL would have been transfor=
med
>>> to 0xffffffffUL.
>>=20
>> The offending line LGTM too.
>>=20
>> The only credible explanation I can think of is Coverity flagging discar=
ded 1s
>> on left shifts as loss of precision.
>>=20
>> If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it =
happy,
>> but surely that error would flare up with all uses of GENMASK() too?
>
> And with any other non-zero values of "size" here.
>
> Jan

Is this the only issue flagged? Or are there any others of the same kind? I=
t
might me easier to spot a pattern with a larger dataset.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 13:17:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 13:17:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115249.1461942 (Exim 4.92)
	(envelope-from )
	id 1uvbkO-0003T9-Sb; Mon, 08 Sep 2025 13:17:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115249.1461942; Mon, 08 Sep 2025 13:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvbkO-0003T2-Q0; Mon, 08 Sep 2025 13:17:28 +0000
Received: by outflank-mailman (input) for mailman id 1115249;
 Mon, 08 Sep 2025 13:17:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvbkN-0003Sw-BN
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 13:17:27 +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 294ab4b7-8cb6-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 15:17:25 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6188b6f7f15so4929125a12.2
 for ; Mon, 08 Sep 2025 06:17: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
 4fb4d7f45d1cf-61cfc1c7848sm23317077a12.2.2025.09.08.06.17.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 06:17: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: 294ab4b7-8cb6-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757337445; x=1757942245; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oPjaEpvTu6rko2XUhBcvGErTTY+OtKHGX7I/mSyLgKU=;
        b=ARLo+bg9PrS2g6enGY3IzMrr6eqdEbydyrqQByYl6FPdkz8cp4HHWGP0iUqJGppeMR
         piF4xu+638zDMmhM4gLeZlURENQwnpoUbj2QQQ2Hke+e7V1E/kzNF/IGBNfvtr4OqXxR
         VkEFuyfzDM96cNfYrfZKCf9fJKzbDGFzgaFB3PM9MfTs7sCBdW5QwslId+byqyWpZqE9
         QImSdNOFvgLL2Ung82goiRVqLpkJ6kveBAV6g2ee0Iir7GkdMxZDQ8NJSC7Wp4rSxgVl
         6K2AeQlenU2Jd7txmmiS8XTuar5c19KpDvfF6LeBIOdAYgyJYJa3W46Alp7aY0ucm5zu
         z1Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757337445; x=1757942245;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oPjaEpvTu6rko2XUhBcvGErTTY+OtKHGX7I/mSyLgKU=;
        b=BaVKoiPKK/FnvG5LCxYKKkba5OweQ4lws2WKtfvrKFSbe2IsryMHYnfF5+vCFIS4Sp
         mbdETZzmZAfRbOFqSodPuaelSxr/mGWY+nRpn3rj3DDgeYdfgK2MXVI2hctL8bMY0gbc
         JXf/rFsaa3mdOcatEzIf5gmFqHi41Bf2bo/T7k5f0IUx8EXqoNJb+xSsCLgQ23qLfkjk
         JfON7Y4LfHM/5PnFyJ+rM3E8tr5zUnMVSSv4m0kWVWpFvpnEm6U0X336q8s6dQONBhcm
         ZSpETYQ5WOsx1yPAgtcCdXlm/m9ZvgBfCK4nqKT2x0xeoSLzc4mIe7bonaiuDXj1KeIV
         PDIA==
X-Gm-Message-State: AOJu0Yz30Wrg0Tb1MYnyouxRPLFhdzdaG/WRdQpEeuAQzMOpfiDUs+W2
	H/L4w4PXsb/Y/mLg9qsVtGLJoN1u6udRqcaaM6NnVNz6sovBQ/AZxAZ8/z6Z9X7KSg==
X-Gm-Gg: ASbGncuTi0eYsKEamRkdkXqaPbOApEOwAKPwSAeugerCfn7ScXgXoTYB6+LhVWdVL/g
	mPlYPcf0RQLVoXhHGYGUeYTwIjWg66WemOFSTjR5u7ntcRu2TDZNqmZpQEWIh7NVKHb0wO8q9E7
	8EIEOhsbdnfN/gpxBWpkhNK8LMHKAj0rYsFYjd+HATlZtqM/HnaZb/DYjjul5jcw7/Vznqu03OK
	NoKbaoRCLEX2VrxZ8BfIlNMXbb/cCmxko26UlOmgn8giRfwdu2YhC81kvwZcIArAxqEuJs0Wg3U
	E2WEUNzXI0zT8cAOTK7tvLd68Ijt/6mRgyjtlPDMWxDfFsmBI87nR0AZ8qK7BsE9JVCL6qSpOzy
	SNiaH1zMSZXheCn107rO7XFTHIVkCDtD5Fo0ilU8jK6WOW8WHMEP7uYZqkDe61MdfpcYpvhImzU
	uCypnGOnw=
X-Google-Smtp-Source: AGHT+IGVHhbBsSa6puYaNYWGUjL3z9PHFIXgqRau4l+taVUPFu0BE+ktgHGAKpQgQjG5w+10OtPBJw==
X-Received: by 2002:a05:6402:21d1:b0:61c:5343:8f29 with SMTP id 4fb4d7f45d1cf-62377109cf2mr6292414a12.21.1757337444795;
        Mon, 08 Sep 2025 06:17:24 -0700 (PDT)
Message-ID: <97e033e6-4d6d-4452-b9d5-70b351a1a5a8@suse.com>
Date: Mon, 8 Sep 2025 15:17:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: New Defects reported by Coverity Scan for XenProject
To: Alejandro Vallejo 
Cc: "xen-devel@lists.xenproject.org" 
References: <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail>
 <77361e51-dcb8-40e2-a526-9ff90ba942a2@suse.com>
 
 <9e474109-7aa1-42b9-9fa6-31c4ef0fb856@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 08.09.2025 14:48, Alejandro Vallejo wrote:
> On Mon Sep 8, 2025 at 1:25 PM CEST, Jan Beulich wrote:
>> On 08.09.2025 13:04, Alejandro Vallejo wrote:
>>> On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
>>>> On 07.09.2025 16:37, scan-admin@coverity.com wrote:
>>>>> ** CID 1665362:       Integer handling issues  (INTEGER_OVERFLOW)
>>>>> /xen/lib/find-next-bit.c: 104           in find_next_zero_bit()
>>>>>
>>>>>
>>>>> _____________________________________________________________________________________________
>>>>> *** CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>> /xen/lib/find-next-bit.c: 104             in find_next_zero_bit()
>>>>> 98     	}
>>>>> 99     	if (!size)
>>>>> 100     		return result;
>>>>> 101     	tmp = *p;
>>>>> 102     
>>>>> 103     found_first:
>>>>>>>>     CID 1665362:         Integer handling issues  (INTEGER_OVERFLOW)
>>>>>>>>     Expression "0xffffffffffffffffUL << size", where "size" is known to be equal to 63, overflows the type of "0xffffffffffffffffUL << size", which is type "unsigned long".
>>>>> 104     	tmp |= ~0UL << size;
>>>>> 105     	if (tmp == ~0UL)	/* Are any bits zero? */
>>>>> 106     		return result + size;	/* Nope. */
>>>>> 107     found_middle:
>>>>> 108     	return result + ffz(tmp);
>>>>> 109     }
>>>>
>>>> I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply
>>>> 0x8000000000000000UL, isn't it? Where's the overflow there? There also
>>>> cannot be talk of a 32-bit build, or else ~0UL would have been transformed
>>>> to 0xffffffffUL.
>>>
>>> The offending line LGTM too.
>>>
>>> The only credible explanation I can think of is Coverity flagging discarded 1s
>>> on left shifts as loss of precision.
>>>
>>> If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it happy,
>>> but surely that error would flare up with all uses of GENMASK() too?
>>
>> And with any other non-zero values of "size" here.
> 
> Is this the only issue flagged? Or are there any others of the same kind? It
> might me easier to spot a pattern with a larger dataset.

I've seen only this one report.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 13:40:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 13:40:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115259.1461953 (Exim 4.92)
	(envelope-from )
	id 1uvc6G-0006vS-LI; Mon, 08 Sep 2025 13:40:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115259.1461953; Mon, 08 Sep 2025 13:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvc6G-0006ux-Fv; Mon, 08 Sep 2025 13:40:04 +0000
Received: by outflank-mailman (input) for mailman id 1115259;
 Mon, 08 Sep 2025 13:40: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 1uvc6E-0006Nv-KD
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 13:40:02 +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 4a0df8ef-8cb9-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 15:39:50 +0200 (CEST)
Received: from CH0PR03CA0399.namprd03.prod.outlook.com (2603:10b6:610:11b::18)
 by DS0PR12MB6558.namprd12.prod.outlook.com (2603:10b6:8:d2::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 13:39:45 +0000
Received: from CH3PEPF00000010.namprd04.prod.outlook.com
 (2603:10b6:610:11b:cafe::18) by CH0PR03CA0399.outlook.office365.com
 (2603:10b6:610:11b::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 13:39:45 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CH3PEPF00000010.mail.protection.outlook.com (10.167.244.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Mon, 8 Sep 2025 13:39:44 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 8 Sep
 2025 06:39:43 -0700
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 8 Sep
 2025 06:39:43 -0700
Received: from [192.168.29.198] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 8 Sep 2025 06:39:42 -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: 4a0df8ef-8cb9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wc0/sOH8Mqt7iBi8p3JGK521OAWo/21FS0rMkrIkJ6ohdcIFC12ck379bOAi/EgcYT7QjmC+2ByZpIsyrk8MXzdYvFcqAaSlqEwIhdR4DbEUmO5cDQmH7xQHYSyr+nVV2sPI74PX2n1f08gwyHo1yrPxdMECbFTaEVMZpVTe8+vRBgVuXQmC9SyiUJxdj6jDyvtiGGJPgCgzoih+JBrMCTHWJ+UZ5B1h9iSBGBy866fPAQegCYWl9/2cJrELOn8TpRuvwGSQ+U9NjI7mH6BvzRQ8YPRGGTdyHsTI6kASq2r0rVxODfH0jqcYsxpdUNPOb/TTUdduN9McvaP0JqfT6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=u03ZaRyk2iNmWtEBJ5W6eTxBCizcl+7Kw5AqzdepHzA=;
 b=eaxU99lyiedyFlutxm014HnoqSHglqD2xaeW7fI5R1hZX/Fz1Qv9qHyMFcoBx7bSNQVlILzaTb4Mh4q6A8mgERTBX7YDwXtgdwJIw3VeXTwp72qVoGXBxEWby0s9wu9WrvgzH0zOhgTowNoBcjv3Y1uHlmhSFzRLn+WFLPzvOFbkDf6wEQ9MtHgwDAiEKlEYKfYB7oDNujlSdPOF5R2OXbexPnrn015FUapm9/4iA825CPlGoU89d0yAEuaM+npJX5in5LZ0XE1CSTau4GWQH8bNBVaGwoRjsXCulrsw0ygBwhi6nQBHN+mXh+xb3aZ7vfZQSK7tiRglyCuyahktaA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip
 is 165.204.84.17) smtp.rcpttodomain=suse.com 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=u03ZaRyk2iNmWtEBJ5W6eTxBCizcl+7Kw5AqzdepHzA=;
 b=kpNw24vbC1roY96sMDrYSQLn0YLyXXbeOSrJ9hQbYzZdwo/AKOO2yTWrrJVzKrhBxmxxO6w/r9lJxCLTKrFpKcY5TBjAL+6eSGQVUVD4t8VEOiK3fcAJrJGmdu86DDScwYsMHSTJCrGM001RrG6FvzzafjUTOgQFDKIEdmrHA7Y=
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)
Message-ID: 
Date: Mon, 8 Sep 2025 09:39:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/mcheck: allow varying bank counts per CPU
To: Jan Beulich , Soham Dandapat 
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	
References: <20250905165212.96843-1-Soham.Dandapat@amd.com>
 <32f89ab8-9742-4bc8-a5ef-848b66e788b2@amd.com>
 <89d0b668-537b-4ee4-8cda-e0d95d9eed90@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <89d0b668-537b-4ee4-8cda-e0d95d9eed90@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: CH3PEPF00000010:EE_|DS0PR12MB6558:EE_
X-MS-Office365-Filtering-Correlation-Id: b2434193-8241-4790-5408-08ddeedd2b85
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?cnZjK3pWRkVBdDduS3hrSmRwajgyQ1V3dndVSWNBYW04czZMQjBXVlJhL3c3?=
 =?utf-8?B?eWJNYmFWMWZpbmlrY1FxQVVXaU16a2FSSmhpQ1hxcWlib0pQU3ppTXV4Y0FP?=
 =?utf-8?B?UllvNnY0dWpDd01MeTZtNnQxSDZIN3JHc0dPMzBVYWNVUGdONjB2TEo1MGtx?=
 =?utf-8?B?eHk4ZU9ZY1g5TUxML3YvQ2E3Sk1Rb1dMVUh5SDNQZks2bE5UeHQvK2hDWHlF?=
 =?utf-8?B?bk9VZzJZRllUdWJnLzJVd0pxdzBGRUh2dTE4a0I0K2NtZW5TTjBIbENjTkpF?=
 =?utf-8?B?bjZPVFNMRzl5MjdTK0gxdHlEZ1hCSUdMbmNWUjNRUytmNW5leFBxVkNvWjA5?=
 =?utf-8?B?emdqWS9jeVA3a2NMUm1EWGw0dHp4Yi8vUndERVIycjZPRk1NbHlyc0o5cW5x?=
 =?utf-8?B?ZjE1NmQ3Y1hrNzdzcytxUGNQT2pscGprdkZrQmxrMHZHTWdjVEhnT0M1MFMx?=
 =?utf-8?B?MnphbTRJUHYycGlQYmVMNFF0cEZUWW1MQzNvQkl4MkFpajZ1dnVOVjVIdmlh?=
 =?utf-8?B?aXBwdDBQSW5pemZydEZTem9SV29vOVdSa2hvZEJRR3NMaFZIVnZucXJsRCsv?=
 =?utf-8?B?MW93KzVERGMyd1pUS0Z4NWpBV0E1c3AzcjZXUkpUam96U1pCR3VNaUN2NEM3?=
 =?utf-8?B?aUxiZURnc2p6RUxlVFVlaXVFdzFSVnVxYTlYR084WmxTNjg1Sm14TEdhVldw?=
 =?utf-8?B?NWtNa1dGRFlTUXN6eS9YQWZxS3hVZlZwdW04enZ1QWQxMXN1dnE1bkhSdDlr?=
 =?utf-8?B?SUtzTEdGQmdseGI1cmt1L3BkbkNCbkJsVnptdU9iS0pvRzRYeFd3NzRLei8w?=
 =?utf-8?B?K0RmbExiZnBXTVdmTFhKMzZTMEFRajNHQ0VOZVdjZjhwS0k4Zzk4dkNvSzVG?=
 =?utf-8?B?MkhTZmNnTkZEcUpTTnRCVEk3cnQwQzRoY0pUcGJ2dDVSd3NUL3pxQ3RLVHRa?=
 =?utf-8?B?eVQ5YU1DV3BpK2taM09MNjlQdE1sV1NoOXhMb0dSMVhaMk41ZDRNOHBLR0Zw?=
 =?utf-8?B?UzBhRWttSm5vd2hjL3lyTGdGYWpFa0cvdS82UTJQekFMY0RSTXdwckZEbFR1?=
 =?utf-8?B?N1IrajFxalR1L29NZG1ZMjh0VDhJOVdVeUFDc0xkOEJUTVhqdHErK0FNSnNY?=
 =?utf-8?B?eU9Vem1ZMVBsR29xS05ncXJjTTNqM3pIek5ZMHVWRVViN2JOL1Y1SFdKTENx?=
 =?utf-8?B?QnZCTUNxTGlubnZsc0dnRHZ0cVNXbzE0VXBFb3VsY2JVMGlKOCtYN2d5ZEh3?=
 =?utf-8?B?WTVtU1pUK0lBZm9NN290Skk3OVUzVnN2eUpVS3BtMGFKNlVNWmdwOUt3QjZ1?=
 =?utf-8?B?Y2twZ1hJQTRiTE9DazVlYkJLSWNZTjFUMlpYaHFzUnBqZVhNVzZsdVNUVXBS?=
 =?utf-8?B?MnJqNXh1aFNvOXlzUkQvV3FYeW1aSXRUQlhnUXljaXdGSW5KWkxoWGRXYk96?=
 =?utf-8?B?Z2RRNE43OG1Ub3dVdG01VGVMcTRZU29WcDJWV0ZkaGIwUmtub3I1a1NrNktq?=
 =?utf-8?B?UmQxeWRCeFBMVkpHMDlZRFRUdEVsakdibjg1ekxHUVRYSWh5QlB3T3lJSjNk?=
 =?utf-8?B?Z01ya0lpNTNSLzhnZ2Y3QWVvenZWK09zSUNzVGpZalJBeGlsNGlTckxHMC9x?=
 =?utf-8?B?NU9GRTFIcmdqdVRZUjBkSWpNR3pVOWdYY1dzc0xGeVkyTTh6VnBFaDZRK0lY?=
 =?utf-8?B?RTN0UEVEMlRpaFRKTWIrUTEydjVjdEdDVTR4ZnZhTHJuNnI4cGFKUzVTWkRk?=
 =?utf-8?B?by9TRmVXTjlhK2k3SUM1YzlZbFl4bUNJZGV5V1c1WVRKcHR6aXljUndKTENK?=
 =?utf-8?B?NVRqTGZpY1JiL1Vqd0VFQzFkNVdyOC9iYjdPb3hoT2d0OFdMWFVySDQ3OHU2?=
 =?utf-8?B?NmZOOTBrUDZlTjIrTWtCaDd5dlYrUEd3WmZWSkRpL3BnTkFGOXVrSVJQcWJj?=
 =?utf-8?B?M3dRa29tUnZtUElVaHBSRnEwZlJuM1dnbDg0WmNBUnN1MUU3eHpJUC9yY21H?=
 =?utf-8?B?dCsxQVVVSkNnQlNlTng1aHhQeUpua0Rpc0Z0alF0bGN5L1VxaTA1RDNsSEl1?=
 =?utf-8?Q?zkK0mS?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 08 Sep 2025 13:39:44.1200
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b2434193-8241-4790-5408-08ddeedd2b85
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000010.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6558

On 2025-09-08 05:08, Jan Beulich wrote:
> On 05.09.2025 19:02, Jason Andryuk wrote:
>>
>>
>> On 2025-09-05 12:52, Soham Dandapat wrote:
>>> In mca_cap_init function,the mcabanks_alloc allocates and
>>> initializes an mca_banks structure for managing MCA banks,
>>> setting up a bank map and storing the specified or default number
>>> of banks.
>>>
>>> After this we will call mcabanks_set(i, mca_allbanks);
>>> The mcabanks_set function sets a specific bit in the bank_map of
>>> an mca_banks structure, provided the structure, its bank_map, and
>>> the bit index are valid.
>>>
>>> At the end, we will call
>>> mcabanks_free(xchg(&mca_allbanks, all));
>>> This function is thread safe and does below:
>>>      1. Atomically exchanges the value of "mca_allbanks" with "all"
>>>      2. Returns the old value that was previously in "mca_allbanks"
>>> So, when we will call mcabanks_free , that will free the memory.
>>>
>>> The problem is that mcabanks_set(i, mca_allbanks) function is updating
>>> mca_allbanks which will be freed via mcabanks_free later. This means
>>> new mca_allbanks instance("all") will never get chance to update
>>> it's bank_map.
>>>
>>> Due to this when we will collect log from mcheck_mca_logout function ,
>>> the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
>>> and MCA logs will not be collected for any bank.
>>>
>>> The fix is to solve this problem.
>>>
>>> Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU")
>>> Signed-off-by: Soham Dandapat 
>>
>> Reviewed-by: Jason Andryuk 
>>
>> Maybe the patch subject should be "x86/mcheck: Fix mca bank
>> initialization" to differentiate from the Fixes commit?
> 
> That's still more generic than wanted. How about "x86/mcheck: fix
> mca_allbanks updating"? With a more concise title (which can be
> adjusted while committing, so long as there's agreement):
> Reviewed-by: Jan Beulich 

Your suggestion sounds good to me.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:11:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:11:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115283.1461962 (Exim 4.92)
	(envelope-from )
	id 1uvcaS-00032w-Rb; Mon, 08 Sep 2025 14:11:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115283.1461962; Mon, 08 Sep 2025 14: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 1uvcaS-00032p-Oq; Mon, 08 Sep 2025 14:11:16 +0000
Received: by outflank-mailman (input) for mailman id 1115283;
 Mon, 08 Sep 2025 14:11:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvcaR-00032j-GN
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:11:15 +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 a967d5e5-8cbd-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 16:11:06 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b049bd81ce5so545150066b.1
 for ; Mon, 08 Sep 2025 07:11:07 -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-b04279a59ffsm1944788466b.60.2025.09.08.07.11.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 07: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: a967d5e5-8cbd-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757340666; x=1757945466; 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=LZ4LKQMdwxZDnuWaDQYBpnyDtKMzx4kkjPJ67hL4DO4=;
        b=nGt37FuNInFMLOkUyawcM/7DXud6id7Sy0epq9rLfmpEDG0eEQBr0u/a+I08i1vzkB
         WjCO8mmMrnYuWCr/1KZAe3fu5MQAK62SsgVdAKZUQJCu0aAX+U5ZW/FwyrQcFlrVQYTF
         6QuUky01khOOAN/kuRIyLe3ka1jle7FQr+rbD4QsmhCilMzwbK9/ejSUvJxfxASqcr4x
         63BqWNhTYatfyl/oxQo275u+4SXtfgH1J1AyYm7HCmGkdlJlOC1vbP9vkxmoEn0Hc88W
         u84c3edwSyk0tP9LZ96Pqz8G3TGTWeku+Ef6aILyctapmdqIAuqnjevg4hsM2GDWNXNz
         O4hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757340666; x=1757945466;
        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=LZ4LKQMdwxZDnuWaDQYBpnyDtKMzx4kkjPJ67hL4DO4=;
        b=AThxH+QBmlkQ65k/7Isb7wkV/H0DlmJCFzZWIxT55sC9yEq6z/fyjFD8xF4ERjVKNh
         dn+RFpbYYDViKwbIwwMCQl73rl7wxkmext0p/eKafSzWQFy5MZ5UipD163gjkCkbYVEm
         zUs2dyLu0v9HuN82zC0Zcl4eqFkCw8+H3cNWPatZP7JplPQOeWx4es9SsPsQwUMjrBMP
         kiqV5xkgemL1bdiWFd2M5kAnr1bfa5MzUhuSW3UCfYwk9FU5YANeHk0ewBjjATVzzTy3
         s5xONNtovdavo1Iuyrj87HF9+hYoFqA16ZULe1uNzXjVg0XFHQvW+9yGDWJ/DMmlH4Si
         9XaQ==
X-Forwarded-Encrypted: i=1; AJvYcCU/+4udmzHxiBD3hgqBq+M24k5vOnEzPYRMriwPQrODkd2L6Aps6S3CEVSc+bSjg4q9p3XCQFmeVyA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwCE6nahyVq0KvYLOlv4qyQIyNzpYXTaPFiFSmi70m0ejNlpPwX
	4inCiKZhnbSjmeyS84wXgJbUIBDZbxFbc73ZR9Mc46k7b9cLKkgIgr5w
X-Gm-Gg: ASbGnctZ4+mefAjzuaZpaJ31NMCPWl+vsIxE6vicJFRpTdINalUyFJxB5GazOyTUW/Y
	22aHYiqc93AU0eloNbim7Aws3Fa2HwTm9fprNQ0JRoxcsuFMTZvsf8cNeG8ohswj4HBAVEm/hT5
	eJZQUAhCi+DSVRmYB6wkclSC2JKZJF/rTFF1hEA6TMfgo2HJsabj+fsKnQG65P2vL6qqt+3pv1N
	RGKV0qYZn/xraJilbU4DPHs1u8Ooo3/vXB2J2XWwMRcFTdt3RTiHynsAMNZkrmTrJEsAtmeljnd
	6etqgEzcMBav0i9SMufDdOviPdv/ypkMKURnyCgo0/J87txGYbfYyZJbE7j3dgh1FCPNfGBbJOi
	/ANSF7ZKuTooC12njSNA0+fIDckfdYdt7ED2QijUmyuA5VdUSr65FvRvEaAZrhkaGrugIPoTmJ1
	ksYd36oQI=
X-Google-Smtp-Source: AGHT+IGDSTO2JbaZR60pQvyiHWjWXt1pzI8JMJ4Xmfa4HislaGZbABwMdRGpiNTy66l41lGHdiibuQ==
X-Received: by 2002:a17:907:3f8c:b0:b04:7514:f9ce with SMTP id a640c23a62f3a-b049307f5edmr1204976266b.2.1757340665994;
        Mon, 08 Sep 2025 07:11:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------9ZeOuM06A0eBtsmxEG5pDP7Y"
Message-ID: 
Date: Mon, 8 Sep 2025 16:11:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini 
Cc: 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 
References: 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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

Hello everyone,

Based on the message from the previous version, the MISRA issues have been fixed,
and aside from one remaining documentation patch ("docs: arm: add docs for SCMI
over SMC calls forwarding driver"), the patch series appears to be ready.

I believe we can consider including it in 4.21. We should have sufficient time
to address any bugs that may arise.

By the way, it would also be good to prepare a CHANGELOG patch.

Does anyone have any objections?

Best regards,
  Oleksii

On 9/4/25 4:21 PM, Oleksii Moisieiev wrote:
> Inroducing V9 patch series  on top of the Xen version 4.20-rc2
> which includes implementation of the SCI SCMI SMC single-agent support.
>
> This patch series is the first chunk of the
> "xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
> be found at [0]
>
> SCMI-multiagent support will be provided as the followup patch series.
>
> [0]https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/
>
> Patch 1 "xen/arm: add generic SCI subsystem"
> - rebased and refactored
> - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
> instead of custom,
>    linker sections based implementation.
> - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
> dom0 code directly.
> - RFC changes in XEN_DOMCTL_assign_device OP processing
> - Introduce arch_handle_passthrough_prop call to handle arm specific
> nodes
>
> Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
> - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI
> over SMC calls
> handling layer") be used under sci subsystem.
> - no functional changes in general
>
> Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
> This is new change which allows passthrough SCMI SMC, single agent interface to
> guest domain
> cover use case "thin Dom0 with guest domain, which serves as Driver domain".
> See patch commit message for full description.
>
> Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
> driver
> - add documentation section for Simple Arm SCMI over SMC calls
> forwarding driver.
>
> Code can be found at:
> https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5
>
> [1] RFC v2:
> http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/
> [2] RFC v3:
> https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927-1-grygorii_strashko@epam.com
> SCMI spec:
> https://developer.arm.com/documentation/den0056/e/?lang=en
>
> SCMI bindings:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
>
> Reference EL3 FW:
> RPI5:https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
> Renesas v4h:
> https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/
>
> base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)
>
> Changes in v9:
> - change input param name for sci_handle_call function to match MISRA rules
> - update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule
>
> Changes in v8:
> - reneregated {helpers/types}.gen.go, dropped unneeded parameters
>
> Changes in v7:
> - fix sci_handl_call to make changes more readable
> - fix build error when DOM0LESS_BUILD is disabled (removed
>   arch_handle_passthrough_prop from the header)
> - sort headers in alphabetical order in sci.h
> - sort headers in scmi-smc.c file
> - Fix commit description.
> - Move scmi-smc-passthrough definition to match alphaberical order
> - remove unneeded initialization with NULL
> - changed u64 to uint64_t
> - Send warning if iomem permit access was failed
> - fixed typos
>
> Changes in v6:
> - rebase on top of the latest master
> - fix return value of sci_dt_finalize() call
> - add R-b tag
> - added generated helpers and types go files
> - rename cmdline parameter to scmi-smc-passthrough
> - fix goto tag in parse_arm_sci_config
> - add link to the scmi bindings used in the doc
> - remove mentions about HVC calls from doc
> - rename cmdline parameter to scmi-smc-passthrough
>
> Changes in v5:
> - update Maintainers file. Set role as a Reviewer
> - rebased on the latest master branch
> - Introduce arch_handle_passthrough_prop call to handle arm specific nodes
> - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
> - rename dom0_scmi_smc_passthrough in documentation
>
> Changes in v4:
> - fix SPDX-License
> - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
> - move XEN_DOMCTL_assign_device code in separate patch
> - Add documentation for SCI SCMI drivers
> - xl.cfg doc
> - fix comments from Stefano Stabellini
> - fix toolstack code as sugested by Anthony PERARD
>    - use MATCH_OPTION()
>    - move arm_sci struct and cfg params in "arch_arm"
> - add SCMI passthrough for dom0less case
>
> Grygorii Strashko (3):
>    xen/arm: scmi-smc: update to be used under sci subsystem
>    xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
>    docs: arm: add docs for SCMI over SMC calls forwarding driver
>
> Oleksii Moisieiev (1):
>    xen/arm: add generic SCI subsystem
>
>   MAINTAINERS                                   |   6 +
>   .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
>   docs/hypervisor-guide/arm/index.rst           |   9 +
>   docs/hypervisor-guide/index.rst               |   1 +
>   docs/man/xl.cfg.5.pod.in                      |  34 +++
>   docs/misc/arm/device-tree/booting.txt         |  15 ++
>   docs/misc/xen-command-line.pandoc             |   9 +
>   tools/golang/xenlight/helpers.gen.go          |  35 +++
>   tools/golang/xenlight/types.gen.go            |  11 +
>   tools/include/libxl.h                         |   5 +
>   tools/libs/light/libxl_arm.c                  |  14 ++
>   tools/libs/light/libxl_types.idl              |  10 +
>   tools/xl/xl_parse.c                           |  36 ++++
>   xen/arch/arm/device.c                         |   5 +
>   xen/arch/arm/dom0less-build.c                 |  40 ++++
>   xen/arch/arm/domain.c                         |  12 +-
>   xen/arch/arm/domain_build.c                   |   8 +
>   xen/arch/arm/firmware/Kconfig                 |  25 ++-
>   xen/arch/arm/firmware/Makefile                |   1 +
>   xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
>   xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
>   xen/arch/arm/include/asm/domain.h             |   5 +
>   xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
>   xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
>   xen/arch/arm/vsmc.c                           |   4 +-
>   xen/common/device-tree/dom0less-build.c       |   4 +
>   xen/include/asm-generic/device.h              |   1 +
>   xen/include/public/arch-arm.h                 |   5 +
>   xen/include/xen/dom0less-build.h              |   3 +
>   29 files changed, 982 insertions(+), 85 deletions(-)
>   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/include/asm/firmware/sci.h
>   delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
>
--------------9ZeOuM06A0eBtsmxEG5pDP7Y
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
Hello everyone,

    
Based on the message from the previous version, the MISRA issues have been fixed,
and aside from one remaining documentation patch ("docs: arm: add docs for SCMI
over SMC calls forwarding driver"), the patch series appears to be ready.

    
I believe we can consider including it in 4.21. We should have sufficient time
to address any bugs that may arise.

    
By the way, it would also be good to prepare a CHANGELOG patch.

    
Does anyone have any objections?

    
Best regards,
 Oleksii

    

    
On 9/4/25 4:21 PM, Oleksii Moisieiev
      wrote:

    

    

      
Inroducing V9 patch series  on top of the Xen version 4.20-rc2
which includes implementation of the SCI SCMI SMC single-agent support.

This patch series is the first chunk of the
"xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
be found at [0]

SCMI-multiagent support will be provided as the followup patch series.

[0] https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/

Patch 1 "xen/arm: add generic SCI subsystem"
- rebased and refactored
- introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
instead of custom,
  linker sections based implementation.
- added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
dom0 code directly.
- RFC changes in XEN_DOMCTL_assign_device OP processing
- Introduce arch_handle_passthrough_prop call to handle arm specific
nodes

Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
- update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI
over SMC calls
handling layer") be used under sci subsystem.
- no functional changes in general

Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
This is new change which allows passthrough SCMI SMC, single agent interface to
guest domain
cover use case "thin Dom0 with guest domain, which serves as Driver domain".
See patch commit message for full description.

Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
driver
- add documentation section for Simple Arm SCMI over SMC calls
forwarding driver.

Code can be found at:
https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5

[1] RFC v2:
http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/
[2] RFC v3:
https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927-1-grygorii_strashko@epam.com
SCMI spec:
https://developer.arm.com/documentation/den0056/e/?lang=en

SCMI bindings:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml

Reference EL3 FW:
RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
Renesas v4h:
https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/

base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)

Changes in v9:
- change input param name for sci_handle_call function to match MISRA rules
- update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule

Changes in v8:
- reneregated {helpers/types}.gen.go, dropped unneeded parameters

Changes in v7:
- fix sci_handl_call to make changes more readable
- fix build error when DOM0LESS_BUILD is disabled (removed
 arch_handle_passthrough_prop from the header)
- sort headers in alphabetical order in sci.h
- sort headers in scmi-smc.c file
- Fix commit description.
- Move scmi-smc-passthrough definition to match alphaberical order
- remove unneeded initialization with NULL
- changed u64 to uint64_t
- Send warning if iomem permit access was failed
- fixed typos

Changes in v6:
- rebase on top of the latest master
- fix return value of sci_dt_finalize() call
- add R-b tag
- added generated helpers and types go files
- rename cmdline parameter to scmi-smc-passthrough
- fix goto tag in parse_arm_sci_config
- add link to the scmi bindings used in the doc
- remove mentions about HVC calls from doc
- rename cmdline parameter to scmi-smc-passthrough

Changes in v5:
- update Maintainers file. Set role as a Reviewer
- rebased on the latest master branch
- Introduce arch_handle_passthrough_prop call to handle arm specific nodes
- rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
- rename dom0_scmi_smc_passthrough in documentation

Changes in v4:
- fix SPDX-License
- rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
- move XEN_DOMCTL_assign_device code in separate patch
- Add documentation for SCI SCMI drivers
- xl.cfg doc
- fix comments from Stefano Stabellini
- fix toolstack code as sugested by Anthony PERARD
  - use MATCH_OPTION()
  - move arm_sci struct and cfg params in "arch_arm"
- add SCMI passthrough for dom0less case

Grygorii Strashko (3):
  xen/arm: scmi-smc: update to be used under sci subsystem
  xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
  docs: arm: add docs for SCMI over SMC calls forwarding driver

Oleksii Moisieiev (1):
  xen/arm: add generic SCI subsystem

 MAINTAINERS                                   |   6 +
 .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
 docs/hypervisor-guide/arm/index.rst           |   9 +
 docs/hypervisor-guide/index.rst               |   1 +
 docs/man/xl.cfg.5.pod.in                      |  34 +++
 docs/misc/arm/device-tree/booting.txt         |  15 ++
 docs/misc/xen-command-line.pandoc             |   9 +
 tools/golang/xenlight/helpers.gen.go          |  35 +++
 tools/golang/xenlight/types.gen.go            |  11 +
 tools/include/libxl.h                         |   5 +
 tools/libs/light/libxl_arm.c                  |  14 ++
 tools/libs/light/libxl_types.idl              |  10 +
 tools/xl/xl_parse.c                           |  36 ++++
 xen/arch/arm/device.c                         |   5 +
 xen/arch/arm/dom0less-build.c                 |  40 ++++
 xen/arch/arm/domain.c                         |  12 +-
 xen/arch/arm/domain_build.c                   |   8 +
 xen/arch/arm/firmware/Kconfig                 |  25 ++-
 xen/arch/arm/firmware/Makefile                |   1 +
 xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
 xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
 xen/arch/arm/include/asm/domain.h             |   5 +
 xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
 xen/arch/arm/vsmc.c                           |   4 +-
 xen/common/device-tree/dom0less-build.c       |   4 +
 xen/include/asm-generic/device.h              |   1 +
 xen/include/public/arch-arm.h                 |   5 +
 xen/include/xen/dom0less-build.h              |   3 +
 29 files changed, 982 insertions(+), 85 deletions(-)
 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/include/asm/firmware/sci.h
 delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h



    

  


--------------9ZeOuM06A0eBtsmxEG5pDP7Y--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:12:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:12:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115295.1461973 (Exim 4.92)
	(envelope-from )
	id 1uvcbF-0003Ys-93; Mon, 08 Sep 2025 14:12:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115295.1461973; Mon, 08 Sep 2025 14:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvcbF-0003Yl-4s; Mon, 08 Sep 2025 14:12:05 +0000
Received: by outflank-mailman (input) for mailman id 1115295;
 Mon, 08 Sep 2025 14:12: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 1uvcbD-0003Pu-IB
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:12:03 +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 ca148e11-8cbd-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 16:12:01 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b0415e03e25so619682466b.0
 for ; Mon, 08 Sep 2025 07: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
 a640c23a62f3a-b0470f11088sm1238911966b.111.2025.09.08.07.11.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 07: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: ca148e11-8cbd-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757340721; x=1757945521; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ge1iyHHTlaM4s1ETZlW2q1Im8RFT7Hpk7sY6IEPE3Bc=;
        b=TAx5SD2VsR6JuwDIo6t4N3YvrYiywC9B3JX4/6uIOJ0bQFlymvDVa0N/IU6b5ZNnew
         hJRvoxZXeyg2WCT8RLiQ1BoWNMb6cbiozoI+2DiUtJs9MKK5sH/N3Pl9qw7v/7pyuiIN
         C0qri4ptAPtr4GvJszq4GGUuTLWRgZSp3r8gBAB1GiGOXH2wRA1uUeps8zJqKuHcyp+g
         qs+lJfDrJMt8+7Cj8yYEZ28YdSEdixQpQBogKl7/w63xG7o1BqQUms9+UfzYgIX+hc3Q
         HoXWwVHkgk6lKTr6Z1o3uQWLUuHUjreFWRDiXeXf2O2Q1jLl6UaNb1PC93xoWyFz8+IT
         QIFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757340721; x=1757945521;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ge1iyHHTlaM4s1ETZlW2q1Im8RFT7Hpk7sY6IEPE3Bc=;
        b=T5DkNXF/g9aVCjT0ci1d3FVQdsLvpeNrEwr0Nc/TS8PGR/YOHuYunGzlXiM7+oP921
         XA08ehlLEKqN2dCGMYaNbnZS2K3U4PQvpSHn6WerqrNgdLJK78Bczkx64wWp3qWzNtBH
         9T4cG5ER8qSQ7QWdwvID+eMOgRTbvqKmtA7s8/XodCJwTmLZ/nTHigBxE1aKK5lWPZH5
         looYXjB3D6/KEdP6FC1H7AgO9aIPFGv47+PbLS1ziyrLt8nceTchUempzFgEXNZS8f7n
         dmC2nTFPuNvwief9kr+fcSKqgSBBVWs+qeO0lx9p19x1klgMh0Y9D9POFODkv8NQLElx
         i5eQ==
X-Forwarded-Encrypted: i=1; AJvYcCWwciCMW6XZUfzfRCCrkErwZUBBgtKbRmEMvYATrDamv+D3734FwXNGvQK2lSux69I2R15wpFgiqxI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBJ3RmuE2JeHDBeDcIzI2db7L1doLOaZFzDif7n0ZnpAx0u7SU
	ORNaG/Ys7CYbFYYjgLFTtqACkfu5ReW6ij7fLw+2I/GFZXPJR0hhv1Itz9vY0yCNBA==
X-Gm-Gg: ASbGncva6Ufa2xBocRvxsFF9TjyIF4kQHHL6UF3GjtcS2Mwo/QznJeR2qWlzM3Mymp4
	27+Zy6pfa5NUEKSKXSBxPN1CcEqpcomaDyEru14sO4lx5mkVObO6dovgJ+hRAGPW4/rdJuN4zxK
	2ZNmfsNNbF3E/B83Z9WVlVpgygJugW4wcRyqF7YDtUJ2vfjTexIN/PLCIGPv7JwBBAe8bVzYtyZ
	4JAUTnq5AFzZH4jkT7zMuFCu0pRoRGohi/acEE7035NZ/QgXLNs3dr3G9JLTvlcQEPWsrm2dRuO
	t1j3sy4clCyk++njxo91DP+QACex91hMVRWP0fhnXthMovQH84paw9gHZkGz2A6xgGrpFTziu4R
	aqbsLOoPxvrQY6QDgGLrDAZ0D6M4geilCxoAuWH7VFg/67OsWHY/1w4YBkI34xCP/sejAKuOGjg
	kHH5BwvkkSHlQhYbhUmQ==
X-Google-Smtp-Source: AGHT+IEivTXhx/++/qoAsdmqe8PiAEFkfJd/UObwawZmR2YVftE/x4hbgDmYZ8FB+Ugv1u1FIj+S1g==
X-Received: by 2002:a17:907:890d:b0:b04:9ad9:5b2c with SMTP id a640c23a62f3a-b04b140d270mr698827966b.25.1757340720914;
        Mon, 08 Sep 2025 07:12:00 -0700 (PDT)
Message-ID: 
Date: Mon, 8 Sep 2025 16:11:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/7] xen/numa: Add per_node() variables paralleling
 per_cpu() variables
To: Bernhard Kaindl 
Cc: Alejandro Vallejo ,
 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: 
 <2a2e557f84ba4785f3f8788d31d3edf64e689da0.1757261045.git.bernhard.kaindl@cloud.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2a2e557f84ba4785f3f8788d31d3edf64e689da0.1757261045.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.09.2025 18:15, Bernhard Kaindl wrote:
> During the review of the 3rd commit of the NUMA claims v1 series, it
> was found to be concerning (performance-wise) add add another array
> like this that randomly written from all nodes:
> 
> +/* Per-node counts of free pages */
> +static unsigned long pernode_avail_pages[MAX_NUMNODES];
> 
> As solution, it was suggested to introduce per_node() paralleling
> per_cpu(), or (less desirable) to make sure one particular cache
> line would only ever be written from a single node.
> 
> It was mentioned that node_need_scrub[] could/should use it, and
> I assume others may benefit too.
> 
> per_cpu() is a simple standard blueprint that is easy to copy, add
> per_node(), paralleling per_cpu() as the preferred suggestion:
> 
> It is entirely derived from per_cpu(), with a few differences:
> 
> - No add/remove callback: Nodes are onlined on boot and never offlined.
> 
> - As per_node(avail_pages) and pernode(outstanding_claims) are used by
>   the buddy allocator itself, and the buddy allocator is used to alloc
>   the per_node() memory from the local NUMA node, there is a catch:
> 
>   per_node() must already be working to have a working buddy allocator:
> 
>   - Init per_node() before the buddy allocator is ready as it needs
>     to be setup before its use, e.g. to init per_node(avail_pages)!
> 
>   Use an early static __initdata array during early boot and migrate
>   it to the NUMA-node-local xenheap before we enable the secondary CPUs.

Hmm, this is awkward, especially the need to update the offsets. See
comment further down. This aspect may put under question whether the
underlying idea was actually a good one.

> Cc: Jan Beulich 

Cc: here is a little odd, for my taste at least. This may want to be
Requested-by:.

> Signed-off-by: Bernhard Kaindl 
> 
> ---
> Changes:
> - This is patch is new in v3 to resolve the the suggestion from the review.
> - The previous patch #2 is removed from the series as not required,
>   which is best visualized by how claims are used:
> 
>   - Claim needed memory
>   - Allocate all domain memory
>   - Cancel a possible leftover claim
>   - Finish building the domain and unpause it.
> 
>   As it makes no sense to repeat "Claim needed memory" at any time,
>   the change made had no practical significance.  It can be applied
>   later as a tiny, not important cleanup, e.g. with multi-node claims.
> 
> Implementation note on this patch (not needed for the commit message):
> 
> Instead of the __initdata array, I tried to alloc bootmem, but it
> caused paging_init() to panic with not enough memory for p2m on a
> very large 4-Socket, 480 pCPU, 4TiB RAM host (or it caused boot to
> hang after the microcode updates of the 480 pCPUs)

That's odd, but without any details it's hard to make a suggestion.

> --- a/xen/common/numa.c
> +++ b/xen/common/numa.c
> @@ -320,6 +320,51 @@ static bool __init nodes_cover_memory(void)
>      return true;
>  }
>  
> +/* Defined on the BSS in xen.lds.S, used for area sizes and relative offsets */
> +extern const char __pernode_start[];
> +extern const char __pernode_end[];

May I suggest to use unsigned char throughout?

> +unsigned long __read_mostly __pernode_offset[MAX_NUMNODES];

With what you say in the description as to differences from per-CPU data,
this can be __ro_after_init, I expect?

> +#define EARLY_PERNODE_AREA_SIZE (SMP_CACHE_BYTES)

On what basis was this chosen? And how would we, at build time, notice when
this became too small?

> +static char early_pernode_area[MAX_NUMNODES][EARLY_PERNODE_AREA_SIZE]
> +    __initdata __cacheline_aligned;
> +
> +/* per_node() needs to be ready before the first alloc call using the heap */
> +static void __init early_init_pernode_areas(void)
> +{
> +    unsigned int node;
> +
> +    if (__pernode_end - __pernode_start > EARLY_PERNODE_AREA_SIZE)

Nit: Style.

> +        panic("per_node() area too small, increase EARLY_PERNODE_AREA_SIZE");
> +
> +    for_each_online_node(node)
> +        __pernode_offset[node] = early_pernode_area[node] - __pernode_start;

percpu_init_areas() poisons all slots, i.e. unused ones will remain poisoned.
I think something like that is wanted here, too.

> +}
> +
> +/* Before going SMP, migrate the per_node memory areas to their NUMA nodes */
> +static int __init init_pernode_areas(void)

This lacks cf_check, for its use with presmp_initcall() below.

> +{
> +    const int pernode_size = __pernode_end - __pernode_start;  /* size in BSS */

Why plain int? The value can't go negative.

> +    unsigned int node;
> +
> +    for_each_online_node(node)
> +    {
> +        char *p = alloc_xenheap_pages(get_order_from_bytes(pernode_size),
> +                                      MEMF_node(node));

Is per-node data really in need of being page granular? (Question also
applies to the new linker script construct.) Then again I realize we still
don't really have NUMA-aware sub-page-allocator functions. So a comment
here may have to do for now.

Further, like done for CPU0, imo node 0 will want to use the .bss area,
rather than having something allocated for it. That would partly address
the non-NUMA related comment given elsewhere.

> +        if ( !p )
> +            return -ENOMEM;

How's this going to work? Initcalls don't really have their return values
checked, iirc.

> +        /* migrate the pernode data from the bootmem area to the xenheap */

Nit (style): Capital letter at start of comment please.

> +        memcpy(p, early_pernode_area[node], SMP_CACHE_BYTES);

This SMP_CACHE_BYTES (which really means to be EARLY_PERNODE_AREA_SIZE aiui)
wants to become a suitable ARRAY_SIZE().

This also doesn't look to be safe towards an interrupt kicking in, when
sooner or later some interrupt handling code may also access per-node
data.

> +        __pernode_offset[node] = p - __pernode_start;
> +    }
> +    return 0;
> +}
> +
> +presmp_initcall(init_pernode_areas);

Nit: We prefer no blank line between the function and such an annotation.

> @@ -617,7 +662,7 @@ static int __init numa_emulation(unsigned long start_pfn,
>  }
>  #endif
>  
> -void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
> +static void __init init_nodes(unsigned long start_pfn, unsigned long end_pfn)
>  {
>      unsigned int i;
>      paddr_t start = pfn_to_paddr(start_pfn);
> @@ -656,6 +701,12 @@ void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
>      setup_node_bootmem(0, start, end);
>  }
>  
> +void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
> +{
> +    init_nodes(start_pfn, end_pfn);
> +    early_init_pernode_areas(); /* With all nodes registered, init per_node() */
> +}

This file is built only when CONFIG_NUMA=y. Non-NUMA configurations, however,
also need to have a working per_node(), with only ever 0 passed in as the node
ID.

> --- a/xen/include/xen/numa.h
> +++ b/xen/include/xen/numa.h
> @@ -152,4 +152,19 @@ static inline nodeid_t mfn_to_nid(mfn_t mfn)
>  
>  #define page_to_nid(pg) mfn_to_nid(page_to_mfn(pg))
>  
> +/* Per NUMA node data area handling based on per-cpu data area handling. */
> +extern unsigned long __pernode_offset[];
> +
> +#define DECLARE_PER_NODE(type, name) \
> +    extern __typeof__(type) pernode__ ## name
> +
> +#define __DEFINE_PER_NODE(attr, type, name) \
> +    attr __typeof__(type) pernode_ ## name

I would suggest to omit this as long as there's just a single use.

> +#define DEFINE_PER_NODE(type, name) \
> +    __DEFINE_PER_NODE(__section(".bss.pernode"), type, _ ## name)
> +
> +#define per_node(var, node)  \
> +    (*RELOC_HIDE(&pernode__##var, __pernode_offset[node]))

I'm glad you didn't add this_node() (yet). As per discussion with Andrew earlier
today, there may want to be a comment here as to its absence, explaining that
what "this node" is first needs determining. There can, after all, be a CPU, a
memory, and a device view. While for devices we may not want to use this_node(),
for memory it may well happen. Hence something entirely CPU-centric may not work.

Furthermore Andrew pointed out that the ACPI exposed granularity may not be
sufficient for all purposes. He suggested to make clear here that for the time
being all of this is entirely SRAT based. (Iirc there was some DT work towards
supporting NUMA there as well, but my impression is that this work was abandoned.)

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:14:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:14:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115308.1461982 (Exim 4.92)
	(envelope-from )
	id 1uvcds-0004Bt-KP; Mon, 08 Sep 2025 14:14:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115308.1461982; Mon, 08 Sep 2025 14: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 1uvcds-0004Bm-HX; Mon, 08 Sep 2025 14:14:48 +0000
Received: by outflank-mailman (input) for mailman id 1115308;
 Mon, 08 Sep 2025 14:14: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 1uvcdr-0004Bg-3E
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:14:47 +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 269d2fd3-8cbe-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 16:14:36 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-b0431c12df3so772541566b.1
 for ; Mon, 08 Sep 2025 07:14:36 -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-61cfc1c7a10sm22747185a12.5.2025.09.08.07.14.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 07:14: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: 269d2fd3-8cbe-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757340876; x=1757945676; 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=KNegjNmEZ9mXa2wP9a2k2r3tsR6hBXVwLbrDTxk/LG4=;
        b=hMuzW4Lixs5yu9tvDuVeVL3VBud/UuQuMRLogEizt7J6plFbBKf2wqJ/SBgIM4ewvR
         q+2hB3smk5yl0uThLeQNX0WLHO+9cQW6AUZXUIUGiLYIeTxiXRY15YTnOcLu9ngJ08JT
         X3HKCu9I74lz2PH2CeFC/MmxzrQ6ZqMhTdW2AeThEvD5DhlDWDoE4J7fIJC/FHyWiGQz
         EhuZXey3hrNwduDsEBxBQRVnNRjRp7mqWls39n74sOtwoJMKWeRxOPJxBYsbcz5nBXul
         HMcYYx37ZFrDkcGMgkVlIjgiIjEDJSZbRzgvDhr+zMY+qOXhOT7gLoe8WLbbrwWtClQO
         Fz/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757340876; x=1757945676;
        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=KNegjNmEZ9mXa2wP9a2k2r3tsR6hBXVwLbrDTxk/LG4=;
        b=l1TG4BP5Q7DMpxkVO8azfe06jkN1YmYaXSVf9YBMeFVhMc8TGX4H2e8f0vzKM14PV4
         fvaUKUMObUpjZNFCimAExhcwPNWhxXvi0q1LRfmtJhG+cv9M0ycKW8eIhoIaalI8JTBS
         Rz85M3gaQzCMCEj2X1SLnay6xs1zBKWYiN/De/sKuPjU/iECqC8xo+YAlHmyIWe6NQD7
         Eyh0PRc64Lt9jNW+33G0kjUXmmlPB8iFynVeQMQZr1/Ho/PK+jPr4n9DYFsyL4wWN+tL
         Wma2MLi+hvyGXjrYlAPSymH+9uql0JYuce//T+4IylZvoA04pfVLci+670CEaufWnN4d
         oT2g==
X-Gm-Message-State: AOJu0YzabIKcx7pVNouzezLZmTOUZsfoonQVLen4Cde2mKNDy6mkNFv0
	u8UfMGbhsSJARL43AqM9ph6MQNpC2ieNd/9QUZoelUsy15Z+uU3x/zTE
X-Gm-Gg: ASbGnctkJwQQlCcPqyDMRzToH1fFOj3ycfVkWz9oAbeMi/UnY/0/sNhqe1dLINhQ/fh
	PsliPPToDecSwz5c2fbNARexqNw8hAcrY2QRSeQbTwarLRd0X3vEsiPRqYIME6UXrzAPWwScTWB
	cqKUm5l2CiJxc05TCFe27pMGsCRzAryvpAvNPKhqk0+ZHjopne59fHtOViyDZK6q28YRQnbaxyN
	RTwD4N2ipg/57cbTSamabgyvDUd9GSJkMq9Tbdqj72HzSGEVinkqvu/VeVExbn68vtAeamibejW
	mUPu/DZJwdLiX6h6Hs1eG+FlWUSdvw1nMU6VQaZ0MVFuH1tX+CIZDE2+OyipJhipXkuRcn9k8qe
	NqIE3DUpUGuUlT8hvf/8IgeK6WYUUeBe+yrMvRIE2PPSLKTxRCzy+VLY6LM63sbsbNBYU+eDKfH
	OcTlFe8Ds=
X-Google-Smtp-Source: AGHT+IHoGK3ZsoIvRUjqB3AsjdnaDoM9jc9iXpQx1Ow7S4JzpLGgCcEyML8vZ5rae6BpjxnOdbnhpA==
X-Received: by 2002:a17:906:fe0c:b0:b04:7708:ee36 with SMTP id a640c23a62f3a-b04b13c8c2dmr803511366b.9.1757340875958;
        Mon, 08 Sep 2025 07:14:35 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------HlzBhsLQrd1xKNgWvngjZygp"
Message-ID: <5cb8fdc8-9ea9-471b-bb07-ede3d27c575b@gmail.com>
Date: Mon, 8 Sep 2025 16:14:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 00/12] Introduce eSPI support
To: Stefano Stabellini ,
 Leonid Komarianskyi 
Cc: "xen-devel@lists.xenproject.org" ,
 "olekstysh@gmail.com" , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD ,
 Community Manager 
References: 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/6/25 2:17 AM, Stefano Stabellini wrote:
> Hi Leonid,
>
> I was about to commit this but unfortunately it is introducing MISRA
> regressions. See:
> https://gitlab.com/xen-project/people/sstabellini/xen/-/tree/ppp6?ref_type=heads
>
> https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11265005118
>
> Compared this result:
> https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp6/ARM64/11265005118/PROJECT.ecd;/by_service.html#service&kind
>
> Against upstream staging:
> https://eclair-analysis-logs.xenproject.org/fs/space/XEN.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/ARM64/11264772605/PROJECT.ecd;/by_service.html#service&kind
>
> It is introducing a couple of easy-to-fix 16.3 issues and also a couple
> of new 16.4 issues. They should be all easy to fix. It is also
> introducing three new 13.2 issues and one 18.1 but I haven't looked
> closely into those. Please address them.
>
>
> Oleksii,
>
> Technically, the series is fully acked and ready to be committed. From a
> risk perspective, I would be comfortable committing it now with the
> outstanding MISRA regressions, leaving Leonid to fix them over the next
> few days. However, I have not done so because it would make it harder to
> spot the MISRA regressions due to the way the scanner works (it
> compares against the previous version).
>
> I suggest we allow this series to be committed in the next couple of
> days, once Leonid addresses the regressions, even though it would
> technically be past the feature freeze.

If there is no any strong objects, it sounds good to me to give couple
of days to fix the regressions and then commit this patch series.

~ Oleksii

>
> Cheers,
>
> Stefano
>
> P.S.
>
> Leonid, you might want to check my commits because I fixed a couple of
> things on commit, in addition to adding the various acked-by tags.
>
>
> On Thu, 4 Sep 2025, Leonid Komarianskyi wrote:
>> Hello everyone!
>>
>> V6 contains an issue for debug builds with CONFIG_GICV3_ESPI=n due to a
>> mistake in the ASSERT() condition in the is_espi() function. This patch
>> series fixes the issue and also includes minor fixes according to the
>> review of V6.
>>
>> Summarized description:
>> This patch series adds support for the extended shared peripheral
>> interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
>> and guest domains. The implementation uses a generic approach to handle
>> eSPIs, similar to regular SPIs, while maintaining compatibility with the
>> existing SPI range. Functionality remains unchanged for setups that do
>> not require eSPIs.
>>
>> The series includes:
>> 1) General refactoring of common IRQ operations with GIC registers to
>> improve code readability, simplify further maintenance and prepare the
>> key functions for eSPI implementation.
>> 2) Introducing a new Kconfig option (default n) to enable or disable
>> eSPI support. Disabling this option prevents unnecessary resource
>> allocation for setups that do not require eSPIs.
>> 3) Adding additional resources to store required information and operate
>> with up to 1024 interrupts from eSPI range.
>> 4) Adjusting assertions and checks to pass verification for INTIDs in
>> the eSPI range.
>> 5) Configuration of eSPI-specific registers during GIC initialization
>> for systems with GICv3.1+ hardware.
>> 6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
>> access and operate within the eSPI's INTIDs.
>> 7) Updating documentation and CHANGELOG to reflect the changes made for eSPI
>> support.
>>
>> Also, to simplify reviewing, please find below link to unsquashed patches, that
>> are on top of every patch, that is changed in the series, compared to V6:
>> https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7-unsquashed/
>>
>> Github branch with patch series:
>> https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7/
>>
>> Changes in V7:
>> - individual changes in patches
>>
>> Link on V6:
>> -https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00296.html
>>
>> Changes in V6:
>> - individual changes in patches
>>
>> Link on V5:
>> -https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.html
>>
>> Changes in V5:
>> - individual changes in patches
>>
>> Link on V4:
>> -https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.html
>>
>> Changes in V4:
>> - added a patch for documentation
>> - individual changes in patches
>>
>> Link on V3:
>> -https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.html
>>
>> Changes in V3:
>> - added a patch to update CHANGELOG.md
>> - individual changes in patches
>>
>> Link on V2:
>> -https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.html
>>
>> Changes in V2:
>> - added 2 more patches to implement helper
>>    functions for gic/vgic:
>>    xen/arm: gic: implement helper functions for INTID checks
>>    xen/arm: vgic: implement helper functions for virq checks
>> - removed 2 patches:
>>    xen/arm/irq: allow assignment/releasing of eSPI interrupts
>>    xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
>>    since their functionality can be moved to appropriate patches after
>>    introducing patches with helper functions
>> - individual changes in patches
>>
>> Link on V1:
>> -https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.html
>>
>> Leonid Komarianskyi (12):
>>    xen/arm: gicv3: refactor obtaining GIC addresses for common operations
>>    xen/arm: gic: implement helper functions for INTID checks
>>    xen/arm: vgic: implement helper functions for virq checks
>>    xen/arm/irq: add handling for IRQs in the eSPI range
>>    xen/arm: gicv3: implement handling of GICv3.1 eSPI
>>    xen/arm/irq: allow eSPI processing in the gic_interrupt function
>>    xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
>>    xen/arm: vgic: add resource management for extended SPIs
>>    xen/arm: domain_build/dom0less-build: adjust domains config to support
>>      eSPIs
>>    xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
>>    doc/man: update description for nr_spis with eSPI
>>    CHANGELOG.md: add mention of GICv3.1 eSPI support
>>
>>   CHANGELOG.md                           |   2 +
>>   docs/man/xl.cfg.5.pod.in               |  13 +-
>>   xen/arch/arm/Kconfig                   |   8 +
>>   xen/arch/arm/dom0less-build.c          |   2 +-
>>   xen/arch/arm/domain_build.c            |   2 +-
>>   xen/arch/arm/gic-v3.c                  | 195 +++++++++++++++++++----
>>   xen/arch/arm/gic.c                     |   8 +-
>>   xen/arch/arm/include/asm/gic.h         |  28 ++++
>>   xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
>>   xen/arch/arm/include/asm/irq.h         |  38 +++++
>>   xen/arch/arm/include/asm/vgic.h        |  56 ++++++-
>>   xen/arch/arm/irq.c                     |  62 +++++++-
>>   xen/arch/arm/vgic-v3.c                 | 203 ++++++++++++++++++-----
>>   xen/arch/arm/vgic.c                    | 212 +++++++++++++++++++++++--
>>   xen/arch/arm/vgic/vgic.c               |   5 +
>>   15 files changed, 762 insertions(+), 112 deletions(-)
>>
>> -- 
>> 2.34.1
>>
--------------HlzBhsLQrd1xKNgWvngjZygp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/6/25 2:17 AM, Stefano Stabellini
      wrote:

    

    

      
Hi Leonid,

I was about to commit this but unfortunately it is introducing MISRA
regressions. See:
https://gitlab.com/xen-project/people/sstabellini/xen/-/tree/ppp6?ref_type=heads

https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11265005118

Compared this result:
https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp6/ARM64/11265005118/PROJECT.ecd;/by_service.html#service&kind

Against upstream staging:
https://eclair-analysis-logs.xenproject.org/fs/space/XEN.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/ARM64/11264772605/PROJECT.ecd;/by_service.html#service&kind

It is introducing a couple of easy-to-fix 16.3 issues and also a couple
of new 16.4 issues. They should be all easy to fix. It is also
introducing three new 13.2 issues and one 18.1 but I haven't looked
closely into those. Please address them.


Oleksii,

Technically, the series is fully acked and ready to be committed. From a
risk perspective, I would be comfortable committing it now with the
outstanding MISRA regressions, leaving Leonid to fix them over the next
few days. However, I have not done so because it would make it harder to
spot the MISRA regressions due to the way the scanner works (it
compares against the previous version).

I suggest we allow this series to be committed in the next couple of
days, once Leonid addresses the regressions, even though it would
technically be past the feature freeze.

    

    
If there is no any strong objects, it sounds good to me to give couple
of days to fix the regressions and then commit this patch series.

~ Oleksii


    

      

Cheers,

Stefano

P.S.

Leonid, you might want to check my commits because I fixed a couple of
things on commit, in addition to adding the various acked-by tags.


On Thu, 4 Sep 2025, Leonid Komarianskyi wrote:


      

        
Hello everyone!

V6 contains an issue for debug builds with CONFIG_GICV3_ESPI=n due to a
mistake in the ASSERT() condition in the is_espi() function. This patch
series fixes the issue and also includes minor fixes according to the
review of V6.

Summarized description:
This patch series adds support for the extended shared peripheral
interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
and guest domains. The implementation uses a generic approach to handle
eSPIs, similar to regular SPIs, while maintaining compatibility with the
existing SPI range. Functionality remains unchanged for setups that do
not require eSPIs.

The series includes:
1) General refactoring of common IRQ operations with GIC registers to
improve code readability, simplify further maintenance and prepare the
key functions for eSPI implementation.
2) Introducing a new Kconfig option (default n) to enable or disable
eSPI support. Disabling this option prevents unnecessary resource
allocation for setups that do not require eSPIs.
3) Adding additional resources to store required information and operate
with up to 1024 interrupts from eSPI range.
4) Adjusting assertions and checks to pass verification for INTIDs in
the eSPI range.
5) Configuration of eSPI-specific registers during GIC initialization
for systems with GICv3.1+ hardware.
6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
access and operate within the eSPI's INTIDs.
7) Updating documentation and CHANGELOG to reflect the changes made for eSPI
support.

Also, to simplify reviewing, please find below link to unsquashed patches, that
are on top of every patch, that is changed in the series, compared to V6:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7-unsquashed/

Github branch with patch series:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7/

Changes in V7:
- individual changes in patches

Link on V6:
- https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00296.html

Changes in V6:
- individual changes in patches

Link on V5:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.html

Changes in V5:
- individual changes in patches

Link on V4:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.html

Changes in V4:
- added a patch for documentation
- individual changes in patches

Link on V3:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.html

Changes in V3:
- added a patch to update CHANGELOG.md
- individual changes in patches

Link on V2:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.html

Changes in V2:
- added 2 more patches to implement helper
  functions for gic/vgic:
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
- removed 2 patches:
  xen/arm/irq: allow assignment/releasing of eSPI interrupts
  xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
  since their functionality can be moved to appropriate patches after
  introducing patches with helper functions
- individual changes in patches

Link on V1:
- https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.html

Leonid Komarianskyi (12):
  xen/arm: gicv3: refactor obtaining GIC addresses for common operations
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
  xen/arm/irq: add handling for IRQs in the eSPI range
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
  xen/arm/irq: allow eSPI processing in the gic_interrupt function
  xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
  xen/arm: vgic: add resource management for extended SPIs
  xen/arm: domain_build/dom0less-build: adjust domains config to support
    eSPIs
  xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
  doc/man: update description for nr_spis with eSPI
  CHANGELOG.md: add mention of GICv3.1 eSPI support

 CHANGELOG.md                           |   2 +
 docs/man/xl.cfg.5.pod.in               |  13 +-
 xen/arch/arm/Kconfig                   |   8 +
 xen/arch/arm/dom0less-build.c          |   2 +-
 xen/arch/arm/domain_build.c            |   2 +-
 xen/arch/arm/gic-v3.c                  | 195 +++++++++++++++++++----
 xen/arch/arm/gic.c                     |   8 +-
 xen/arch/arm/include/asm/gic.h         |  28 ++++
 xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
 xen/arch/arm/include/asm/irq.h         |  38 +++++
 xen/arch/arm/include/asm/vgic.h        |  56 ++++++-
 xen/arch/arm/irq.c                     |  62 +++++++-
 xen/arch/arm/vgic-v3.c                 | 203 ++++++++++++++++++-----
 xen/arch/arm/vgic.c                    | 212 +++++++++++++++++++++++--
 xen/arch/arm/vgic/vgic.c               |   5 +
 15 files changed, 762 insertions(+), 112 deletions(-)

-- 
2.34.1



      

    

  


--------------HlzBhsLQrd1xKNgWvngjZygp--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:19:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:19:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115324.1461993 (Exim 4.92)
	(envelope-from )
	id 1uvciD-0004wU-8m; Mon, 08 Sep 2025 14:19:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115324.1461993; Mon, 08 Sep 2025 14: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 1uvciD-0004wN-4j; Mon, 08 Sep 2025 14:19:17 +0000
Received: by outflank-mailman (input) for mailman id 1115324;
 Mon, 08 Sep 2025 14:19: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 1uvciC-0004wH-G4
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:19:16 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc9384c7-8cbe-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 16:19:15 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-6263d0e4b94so3851078a12.3
 for ; Mon, 08 Sep 2025 07:19:15 -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-aff0681aefdsm2507185466b.8.2025.09.08.07.19.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 07:19: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: cc9384c7-8cbe-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757341155; x=1757945955; 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=Lbe8QKSIU3o79OXS///q+DjnP7EZq18ayU20B7dhrM0=;
        b=R+vNnddtPPu+RIDBBrLicu4js1v93yxyx19S+xmxzljyEtk+Y8Cw+yLgS4Lzi7/xSa
         UONbNBvRyn30oB5p1WMc2c7Rd2EozhDB4aBSbQHAudc6tVUTKDtfcSsHt6hBc4+JLBzu
         O7z7iHM6/9zwhpIH1z5iToh+qZ+DoiFWypFRCzVHi1k56D3g2MiVwSn5fNqVMMC+/tuB
         DhImmG/UarvM+WZS5BK3aQihhdjtZrUzgAQyPRrWIJPusPELeiXE5TjH9ac+Ta9uCBeF
         /51stHXcUK9u1BX63g24McPDje51WB/hhtUa7o5YP8srkY8nBdPXKQxG2P7V7Hz0Af3p
         SPQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757341155; x=1757945955;
        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=Lbe8QKSIU3o79OXS///q+DjnP7EZq18ayU20B7dhrM0=;
        b=i/cmL84/tZu+ZYOdgHPJjIdUl5mziOsygeKPR8UlcoJaxLJKfcGy0qJBtHbHohVPJN
         sDL5xs8+Mb4pa+MJ9O7lJvRpFif5K2aaXTYRgmLwmmHcKisFD6D6vl94SZx3ZjzqmZs/
         VCeGFH/wbLyK/wZ/VpDepk5uUXLEF5OV8XJn6cEWqu7FT9FywAng7FLMDF99Z82uLwCd
         LJJd2dft6asVCO5/5A+v5ve+Tg9sB4rZ2p36OLlRgJOJdCeCnY+tqkPPhnwApNL0PwFd
         YCg9aSfTgV8ax1fL0r4xUCp6odHosXbJGRgNzG9pg6U2DEUzQDfMmTlAWMGGlNqXDurR
         wigg==
X-Gm-Message-State: AOJu0Yxty0MarVMy0CAPUETDM4ofW92QnkFTpcrhL12XA9uBoJ0knSpP
	JMpS/d7v/H7uLh0l0dOEfprXsSzGvvqqA/j5phwNPJYctdPzQKZFZV6X
X-Gm-Gg: ASbGncv1IAH/gYCjKaaRXr4Jna+wfoPvRIjsUSjxG1UI3FazHZh7s/adE1MnQuJORhR
	xmVMkS2de7DUguJBCTnsKTKeQykboJv9WdmtyYxLvslF/0PKink/GIg6DJh9x2rrz6gEQ5/pZAJ
	22OaY75+nOuGihdMC0nv32CBkX4TkOST8NncSRkhNjxWIfv/tTE9zdVpEyx+01ZgBbLp6p7P4H/
	zY6+kzTBoPoYwsvH2/l5UCwTYuTALYQ9tnAPp5/BcM6U+2xb+gJPvwE8FhfrVLNhQM+YMBo4DMP
	kIXKGSCaM1cs/WXDPqJ0XEefwdGVMP0PhVtfVycfbWC4du7TGLsC/tL/YUhkevabvRdxG/Yfmyc
	OAao1iAOKTgeZvSO87kHO9DOHKwgV3vZ3dZWECntHLdWAKnRmyKlt+O/UFV1qlBTUHLm3cKg+67
	bT6ilbiJE=
X-Google-Smtp-Source: AGHT+IE1wBXI9qyXo7M9D553RjuOpUoEmW292MJ/8y0g3scG9Yipgcfvqa1hkpPClg/csBTiJ1i8aA==
X-Received: by 2002:a17:907:1ca7:b0:af9:6bfb:58b7 with SMTP id a640c23a62f3a-b04b13cd4f7mr672350066b.5.1757341154729;
        Mon, 08 Sep 2025 07:19:14 -0700 (PDT)
Message-ID: <8dd6a815-0987-40f4-8afe-d4955fe5394d@gmail.com>
Date: Mon, 8 Sep 2025 16:19:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 00/15] x86: introduce NS16550-compatible UART emulator
To: Mykola Kvach ,
 Stefano Stabellini 
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, dmukhin@xen.org
References: <20250905232715.440758-1-dmukhin@ford.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 9/8/25 11:04 AM, Mykola Kvach wrote:
> Hi Denis and Stefano
>
> I’d like to acknowledge the significant effort that went into this patch
> series -- it’s clear that a lot of work has been invested.
>
> On Sat, Sep 6, 2025 at 5:02 AM Stefano Stabellini
>  wrote:
>> Oleksii and all,
>>
>> I would like to consider patches 1-12 of this patch series for 4.21,
>> pending the few minor comments I made addressed.
> Although I am neither a maintainer nor an official reviewer for this
> project, I have looked over some of the first patches in the series. In my
> opinion, the series is not yet ready for merging.
>
> Even if my review is set aside, the changes are largely x86-specific and
> produce the most impact on this architecture. I believe that before
> merging, one of the x86 maintainers (or at least a trusted reviewer for
> x86, if available) should carefully review these patches.
>
>>
>> On Fri, 5 Sep 2025, dmukhin@xen.org wrote:
>>> x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
>>> guest OS bring up in the embedded setups.
>>>
>>> This patch series introduces initial in-hypervisor emulator for
>>> NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.
>>>
>>> In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
>>> early guest firmware and OS bringup debugging, because it eliminates
>>> dependency on the external emulator (qemu) being operational by the time
>>> domains are created.
>>>
>>> The emulator also allows to forward the physical console input to the x86
>>> domain which is useful when a system has only one physical UART for early
>>> debugging and this UART is owned by Xen.
>>>
>>> By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O port
>>> 0x2f8, IRQ#3 in guest OS (legacy COM2). Legacy COM resources cannot be
>>> selected at built-time or via per-domain xl configuration in this initial
>>> submission.
>>>
>>> CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities useful
>>> for NS16550 emulator development/debugging (disabled by default).
>>>
>>> The NS16550 emulator is disabled in default x86 configuration and goes under
>>> CONFIG_EXPERT in Kconfig.
>>>
>>> Limitations
>>> ===========
>>> - Only x86;
>>> - Only legacy COM2 resources, custom I/O ports/IRQs are not supported;
>>> - Only Xen console as a backend, no inter-domain communication (similar to
>>>    vpl011 on Arm);
>>> - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
>>> - No toolstack integration;
>>> - No baud rate emulation (reports 115200 baud to the guest OS);
>>> - No FIFO-less mode emulation;
>>> - No RX FIFO interrupt moderation (FCR) emulation;
>>> - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
>>>    friends);
>>> - No MMIO-based UART emulation.
>>>
>>> Series
>>> ======
>>>
>>>    Patch 1 introduces the new vUART framework, that is the code originally
>>>    posted here:
>>>      https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@ford.com/
>>>    Required for emulator.
>>>
>>>    Patch 2 adds missing NS16550 definitions, required for emulator.
>>>
>>>    Patch 3 introduces the basic emulator skeleton - state machine
>>>    initialization stubs, I/O port handler stub, logging, etc.
>>>
>>>    Patches 4-11 incrementally populate the minimal NS16550 register emulation.
>>>
>>>    Patch 12 hooks vUART state debugging (disabled by default).
>>>
>>>    Pathes 13-15 introduce necessary changes to enable NS16550 on dom0 (and PVH).
>>>
>>> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2024756493
>>> Link to branch: https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-ns8250-v6?ref_type=heads
>>>
>>> Testing
>>> =======
>>>
>>>    ```shell
>>>    echo CONFIG_EXPERT=y >> .config
>>>    echo CONFIG_VUART_NS16X50=y >> .config
>>>    make olddefconfig
>>>    ```
>>>    COM2 (0x2f8) resources are used by default.
>>>
>>>    To test w/ virtual COM2, the guest kernel parameters should contain
>>>    something like the following:
>>>      earlycon=uart,io,0x2f8,115200n8 console=uart,io,0x2f8,115200n8
>>>
>>>    HVM
>>>    ---
>>>    Tested only boot of HVM linux guest with OVMF as the virtual firmware.
>>>    SeaBIOS as a virtual firmware is not tested.
>>>
>>>    PVH (dom0)
>>>    ----------
>>>    Xen is able to forward physical console input to the domain with virtual
>>>    NS16550. To switch the console focus press Ctrl+aaa.
>>>    Console switch is limited on x86 to dom0 and Xen (fixes pending).
>>>
>>> Changes since v5:
>>> - Split THR/RBR into two separate patches.
>>> - Addressed feedback from v5.
>>> - Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-1-dmukhin@ford.com/
>>>
>>> Changes since v4:
>>> - Split the series to make it simpler to review.
>>> - Addressed feedback from v4.
>>> - Dropped xl changes, which I will submit separately.
>>> - Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-1-dmukhin@ford.com/
>>>
>>> Changes since v3:
>>> - Reduced the blast radius of the series, thanks to reviews, individual
>>>    aspects (like console focus) touched in v3 moved to separate threads.
>>> - Kept the UART emulator framework since I need to redo some of emulator code
>>>    and there's more-or-less agreement on it (where to place, naming, scope).
>>> - Applied the feedback from
>>>      https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/
>>> - Link to v3: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/
>>>
>>> Changes since v2:
>>> - renamed emulator s/NS8250/NS16550/g
>>> - reduced the patch series after addressing v2 feedback
>>> - introduced driver framework for UART emulators
>>> - unified guest OS printouts across all available UART emulators
>>> - Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/
>>>
>>> Changes since v1:
>>> - dropped kmalloc/kfree aliases
>>> - fixed ECLAIR jobs (thanks Andrew Cooper)
>>> - addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
>>> - moved NS8250 debugging stubs into its own patch
>>> - added fix for https://gitlab.com/xen-project/xen/-/issues/184
>>> - Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com
>>>
>>> Denis Mukhin (15):
>>>    emul/vuart: introduce framework for UART emulators
>>>    xen/8250-uart: update definitions
>>>    emul/ns16x50: implement emulator stub
>>>    emul/ns16x50: implement DLL/DLM registers
>>>    emul/ns16x50: implement SCR register
>>>    emul/ns16x50: implement IER/IIR registers
>>>    emul/ns16x50: implement LCR/LSR registers
>>>    emul/ns16x50: implement MCR/MSR registers
>>>    emul/ns16x50: implement RBR register
>>>    emul/ns16x50: implement THR register
>>>    emul/ns16x50: implement FCR register (write-only)
>>>    emul/ns16550: implement dump_state() hook
>>>    x86/domain: enable per-domain I/O port bitmaps
>>>    xen/domain: allocate d->irq_caps before arch-specific initialization
>>>    emul/ns16x50: implement IRQ emulation via vIOAPIC
>>>
>>>   xen/arch/arm/xen.lds.S                   |   1 +
>>>   xen/arch/ppc/xen.lds.S                   |   1 +
>>>   xen/arch/riscv/xen.lds.S                 |   1 +
>>>   xen/arch/x86/Makefile                    |   1 +
>>>   xen/arch/x86/dom0_build.c                | 112 +--
>>>   xen/arch/x86/hvm/dom0_build.c            |   7 +
>>>   xen/arch/x86/hvm/hvm.c                   |  56 +-
>>>   xen/arch/x86/hvm/nestedhvm.c             |   8 +-
>>>   xen/arch/x86/hvm/quirks.c                |   3 -
>>>   xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
>>>   xen/arch/x86/hvm/vioapic.c               |  10 +
>>>   xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
>>>   xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
>>>   xen/arch/x86/include/asm/hvm/support.h   |   2 -
>>>   xen/arch/x86/include/asm/iocap.h         |   2 +
>>>   xen/arch/x86/include/asm/irq.h           |   8 +
>>>   xen/arch/x86/ioport.c                    | 163 ++++
>>>   xen/arch/x86/irq.c                       |   8 +
>>>   xen/arch/x86/pv/dom0_build.c             |   7 +
>>>   xen/arch/x86/xen.lds.S                   |   1 +
>>>   xen/common/Kconfig                       |   2 +
>>>   xen/common/Makefile                      |   1 +
>>>   xen/common/domain.c                      |   8 +-
>>>   xen/common/emul/Kconfig                  |   6 +
>>>   xen/common/emul/Makefile                 |   1 +
>>>   xen/common/emul/vuart/Kconfig            |  25 +
>>>   xen/common/emul/vuart/Makefile           |   2 +
>>>   xen/common/emul/vuart/ns16x50.c          | 984 +++++++++++++++++++++++
>>>   xen/common/emul/vuart/vuart.c            | 157 ++++
>>>   xen/common/keyhandler.c                  |   3 +
>>>   xen/drivers/char/console.c               |   6 +-
>>>   xen/drivers/char/ns16550.c               |  16 +-
>>>   xen/drivers/passthrough/x86/hvm.c        |  11 +-
>>>   xen/include/xen/8250-uart.h              |  50 +-
>>>   xen/include/xen/sched.h                  |   4 +
>>>   xen/include/xen/serial.h                 |   3 +
>>>   xen/include/xen/vuart.h                  | 116 +++
>>>   xen/include/xen/xen.lds.h                |  10 +
>>>   38 files changed, 1634 insertions(+), 171 deletions(-)
>>>   create mode 100644 xen/arch/x86/ioport.c
>>>   create mode 100644 xen/common/emul/Kconfig
>>>   create mode 100644 xen/common/emul/Makefile
>>>   create mode 100644 xen/common/emul/vuart/Kconfig
>>>   create mode 100644 xen/common/emul/vuart/Makefile
>>>   create mode 100644 xen/common/emul/vuart/ns16x50.c
>>>   create mode 100644 xen/common/emul/vuart/vuart.c
>>>   create mode 100644 xen/include/xen/vuart.h
>>>
>>> --
>>> 2.51.0
>>>
> Best regards,
> Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:21:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:21:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115338.1462002 (Exim 4.92)
	(envelope-from )
	id 1uvckI-0006Ph-J7; Mon, 08 Sep 2025 14:21:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115338.1462002; Mon, 08 Sep 2025 14:21: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 1uvckI-0006Pa-GG; Mon, 08 Sep 2025 14:21:26 +0000
Received: by outflank-mailman (input) for mailman id 1115338;
 Mon, 08 Sep 2025 14:21: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 1uvckH-0006PU-EZ
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:21:25 +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 16e607db-8cbf-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 16:21:20 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AM0PR03MB6226.eurprd03.prod.outlook.com (2603:10a6:20b:15c::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Mon, 8 Sep
 2025 14:21: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%6]) with mapi id 15.20.9094.016; Mon, 8 Sep 2025
 14:21: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: 16e607db-8cbf-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xWdQyAYPT72dhboSXrTHTCeC8HCjcmFJFxfNYoM9vPyArIFHz8oqzAC/owUq8VW+M377jE1os2eZkUs3tymqn+f12u8gNytO31Na4pymOuuGjSDgKEClyogs57SAWsKAasunsVb9FlZCFRBLxPO0QI/GN9JJot24gtDKDemshYucnrxP09ArN0j98MKpzsgWnxUGNj1Ysf1c2S2fOnhuUJRQP6etUjInFmAeqtQnKh2jb93OCfNCkIFfgILx7dAX1fXKhmQm+BWOBdaUXJW06VJg+dkcLIVSMnkJ/PaS+aUnvSlzTu74NYX2SEBaTEqTjNwBOgTw37TE8Z3Wu+TAUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T7XIpzDMhQo0UGRoonUrL8hYhkoFqR0FMvF0miXxjWI=;
 b=s4Ti7iVJhXNRkE6ZN1SIy9hdSlQV7iwJgWqZtDwYDaNBee82yTF0i6G+lYqFQFtrvcMvdlATY0W6HUOHBROk+tNdULW6hFp03SSbrHCvD8hQm1XY99n05cBfdlUQ12WgyDteM5MZmUzxry2LKs0RC7mdJUzLLMti5b2Sj132rSk8q12JqsWFX2mlFn03dTKpihWFYcN/mrqXgiZgFBJm3twtiZdViRB0zGJoHN/qRmIxIXGcrKMPtVK9UyXaZieNUflj67WOp61MAyjFbkQChGmddrMsOuyrDXvFiT6DQxOB9FXaB1+6UAYoENWzVWh3eps1/lySMlhuCwAsRyh/LA==
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=T7XIpzDMhQo0UGRoonUrL8hYhkoFqR0FMvF0miXxjWI=;
 b=Xd/BNmuSCzcpbEIHMtym3rZHZrRF65XBOMNRdgKUA1+ImRNBbvq2K9RiuGolMkdxjBTkd4JFE3mixMOEG9uGfFDnY7RV0+r/E0hei78uzVJcKfA7ZeUUhN1OhXYdQV9tg47bauq81d4HYO5hij4Q3pGopWd773/03DyBi2yXgZjoNuqS5wvtmVPcS0dxpPVgNnfdscGK4lRUFl5680Kg+91pCMxqa8dxsxTY2Cs6HLzG3LpPwIdTydo6dzjMMY/GtX71QS3dUyb5teRnZBxQd8OhAN1TwPwe4m1qllw3O+XckLZuIDey4d17OoQ9ROzjcTFfoOWAYEnHZSEd/6oqTQ==
From: Oleksii Moisieiev 
To: Oleksii Kurochko ,
	"xen-devel@lists.xenproject.org" , Stefano
 Stabellini 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
Thread-Topic: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC
 single-agent support
Thread-Index: AQHcHaczzFSreK7re0KgM50DbxoBaLSJWYOAgAAC2AA=
Date: Mon, 8 Sep 2025 14:21:16 +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: PAVPR03MB8946:EE_|AM0PR03MB6226:EE_
x-ms-office365-filtering-correlation-id: 157ec55d-3fcc-45c0-0c7e-08ddeee2f90f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bzBDTnVpanVGSy9IdE5tTFRXR3VaYWNqQVhIZTJBaEMyUWdCUHRJeDA2RkhV?=
 =?utf-8?B?aDBQMlFYaG5oMUoxVU5abFBJMkFTZDhWUmZhay85RlltL2hXR2VkUHVEN0JZ?=
 =?utf-8?B?SWo1UmVKMllkZU82ckNERmdMWkVQamM5d0RTbWhSQldsZmZSUnRiMkdXa3hz?=
 =?utf-8?B?QUJpUUJMVUhjMjBsYjFQekI5VE5mWmU5bm1FK2htazQvU3BIbGpoUEVrRXJY?=
 =?utf-8?B?QlBSVGhaRytYTXNFVEFjN250amdRUW4yWTlLVldlNzhnd3VCUkd3bkQ3U2V1?=
 =?utf-8?B?UUg1U1hMdTRJcmdNcnFGQTdzVXp1ZXpMcElEOXlZL2JJQm1JQlFBWWdZSTUv?=
 =?utf-8?B?RmViZXBSRFlpVjBpbnJETjhKdFU2V2d1MEpLYmxTWklEbURNaGR3SHdjOC9z?=
 =?utf-8?B?eUJieUY4YVpMTDloSDc2d3RaT2phNFJXZElsZkJ0VGxHRy9XSGVXOTZrUmtR?=
 =?utf-8?B?bVZFOU5UWEtBUk5Oc0Rmc2RaY3JLSXBUOEl0RWt4OTdUb2s2UHRXTitWVG9q?=
 =?utf-8?B?clgxZHl5UGs5M1NjcW9OT0pJdVpiZUtsc2g5blFqeHRKSFpxdFkvTVo3K2Jj?=
 =?utf-8?B?ak5PS3VsdjJHRHA2bDhYT0xkRzhCZFhYUkRTVUlDZkNmZXlXVTdoWjhsK0h0?=
 =?utf-8?B?YXg1clFleVhzNzJ5aEZlT3g5OE1lMXpVZEFINVNNbktNeEhHWVFGQ2Nselpz?=
 =?utf-8?B?b3Zuem1UWWtEVHh6bzdYY0txZWs3bGMzcXhzd3RpUDlzWGRlamI4R2p5MmIx?=
 =?utf-8?B?bEYwNGFiWDdsRUNqUG9QTFhZY21FUG1SczVqUmdpNHdlc09neXVKd2VydTRS?=
 =?utf-8?B?OEpKTklmaWNCNkFsOXRpZzlJcU8xY3FyelYyUFRTU3IzN04rYVZEYUd6ay81?=
 =?utf-8?B?TXdCZjRNZGQ3anVVRTNwTHJCQ0NzWHBDMkZaTlRnYjVxN1FmTFJQSUxMMlN0?=
 =?utf-8?B?YnNaNDdXb2JDQ0Y0ZytQSnVLNUNKOHBoWThvbDgvMEtDTm9Ycjc3K2xGa1FB?=
 =?utf-8?B?S1RYSnpvN1NTVk52U3FNa2VlU3d6V0dhLytUWTlSRzZEVndZazh2aFRpaWdP?=
 =?utf-8?B?VHRPZmRzSVREVlpKRDc4TWZLdThVS2tOa2RpZStOV1M2MzVpL0JIemFIRFpN?=
 =?utf-8?B?bkNYdFp0bk8ybWJlSUcxTzJkSDBNWCt6MzcrZXR5RllKOWNWWTM0ZXBUZTZa?=
 =?utf-8?B?dTBsR3Y5VGJRelh4NXFoamk0NEJPTHh2dHdhdDlzbytRMHNuZnlhdVhWaCtR?=
 =?utf-8?B?djlHd1pJM0ZDYnNDbzFSaWdLdkJKd0p1R2thbXl5UFl0aGNremk5L3Y0bjRH?=
 =?utf-8?B?ZDg1ZnZDbU83R0w5UG1ERWY4SEd1N3JNbjhudXV3T01yTC9RTCtHMEVPQ0ZJ?=
 =?utf-8?B?b3lVaUp3QnNtWVg0ZUhNMHh5V0pqbFdEWE1PSkl4ekhFM1NXdy9jYVpSa2Fm?=
 =?utf-8?B?ZkhERVNrMi9RYkw1cmhoekMyMHhoZUxSOTJMQXZvK3dqemlJTzBsbUUvTGtS?=
 =?utf-8?B?QVdaVXVnLzFoSkxGNld1aFBBVWtjc1ljQXd2V2F0S1hKWUFseU5JeXF5NUZV?=
 =?utf-8?B?bnBMZjF3SHoyY05XVCtkWWVvWk53MmVWWmpKOVJVSzJzN0NwS1lxcVAyUzZQ?=
 =?utf-8?B?bitieEJjNnhjSlhIZUtHcGI3MHUrenV3YUJwUEU2VE45WjFkVFFtMm1ZWWJa?=
 =?utf-8?B?UGdCRTkxWlNXWlJ0ZmM3eUJFSU5lV0VyM1Biem9IVHQ5YlF5RFpTK2xJbnlU?=
 =?utf-8?B?YnpBQ2FZVHRKVENRa0NCaEdxdytOTkhPZnhxNW9PaWF0MytIUmphUDJicDVj?=
 =?utf-8?B?aWl4SDVaNThhclBPNHNJNnEyNkNLNlJzVU9lbStUY0sxb3B2VW5rK0xGTG1t?=
 =?utf-8?B?VHgvc1FBcyt1ZnhJRWRFR3hyYUFlcGtud2c4TUxzWHhDcUQvczVwK0NZSUEw?=
 =?utf-8?Q?YxRozUosiLo=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)(7416014)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Um5VcUh6NThnN1N4dEp5WnNYQWdPL3Y5RjNYTVo1SHRvZ04rNmVGR1BPRm03?=
 =?utf-8?B?UDJsdXJmZ1U3cDNWb3l0VmpsWHVrZjNBZEh0SU1aQ2xJSDFqbjJ1RWY5RnM1?=
 =?utf-8?B?R1dGbTgyVjB0cmFtMmFDT2tYc0tTWWpuVml5VXphTjZrLy8yYnNsU3pUMlBl?=
 =?utf-8?B?a0dPUS85RUJ3N21oNjRkTGRnc1cweXV3amdaY1FET1dkaWp4VGM2RTluTlI4?=
 =?utf-8?B?OXdra3lpUHhodEdGWTM4R2FqRVFTenNHTE9jWURabnpWSytkT2xpelZZMGhZ?=
 =?utf-8?B?aWVnb0RmYTlMbEkyUnVJWWFMOWFDZ1F1WGIyNzFralcyenAzNGYxYWR5Njc4?=
 =?utf-8?B?T2ZJU0krd0tmZUV0YVpjN21nakUwRXFrb1pSTHlHRXJEeDI5azZ5R2k0L1Rt?=
 =?utf-8?B?V3ljRkdMRmVTTWJrRkNTTW9BK29xTk9hbFFocEZoWk9pNW1hRkJPREZDeXQv?=
 =?utf-8?B?aHdBb1h3cDVNYnN1T3k3Rk1sZHhDV2hadkdYMC9kMjRYVEkwY2l1OWFRZUZ2?=
 =?utf-8?B?RHluQzlBT2ZsbStNUEVENzk0d3VNVitqTml1ZWYzN3hxQ2p5TzM0a05NMHIy?=
 =?utf-8?B?ZUIzTGhJMEtZeE9nV2ptRTRvRUdkNzNuVDc5Q28xc1M2a0hoRzZGVlFTV2VB?=
 =?utf-8?B?R2lobHkrVlVnRTc2dytBaTlkK2tWTEgyVlZPR2RITCtDclhqT2MxZ1FGNFFY?=
 =?utf-8?B?MklKSGV3b2xEbFQwTElNTVJGWmI1L3BadGJ3ckhkNzlYQTQ5S2FFMjV3Tytz?=
 =?utf-8?B?ZGl4WFlJRk44ZEhhZFE1VzJxS2NsdFRxODNsOHdlZDFjeTg4Y3pFV21oVXZa?=
 =?utf-8?B?YlRrR2p1amRrMkdaS2VtVUxEcUVpOSsvUFFZYXV0OVFpUU1Bamg3Um9kMVAy?=
 =?utf-8?B?V3RLb1pWVE9vT3MzS0Jyd0JQcHVrMGxMZitTb2VQcHNoM3JwSHBVV0JRaWhK?=
 =?utf-8?B?aTdZMy9sbHg0MUFwdk1zTXMrNzlSdHlHWUcrS1FZeDdybTlyUnhHQUJRNFM3?=
 =?utf-8?B?amJKSEhXWFdwQkJ5cjhvRFZ2Z2xuMEZhelB0Ymc3OXRqdkRQckJnTVBsWUcv?=
 =?utf-8?B?dFp2ME4yWjlwdWNLK1NLRWo5dm9qaVNnam5TZ3czcDZSS1pGYkV1akR6M2xT?=
 =?utf-8?B?OER0N285RThySk1iMzNPT3dHVE5HbjF5S2RGbHV2VUpZZksza0QxTkNWSEYr?=
 =?utf-8?B?WElreWxQbmVSVXlsM3hpVDBPRGlCbk9GeDBwMytvelU5SmgyRURWdHZPUzN4?=
 =?utf-8?B?TmREL2p6L3RlTDUraWRwdjlZaFZreUQ1YmZyWm8xeUV0bDF3d0hBNy8rY3NG?=
 =?utf-8?B?Q20wZ2tONmpzVkZmMjdxOERvWG9sa1dqa3NBT3pWVkt0VnJZTTNQOTJDR0Rw?=
 =?utf-8?B?VjE5WnNzZ2tGWWtWbGRKRUZlRDNITU5iSDcrSHpDQThxTXhKY0QweEo3MWJv?=
 =?utf-8?B?TmdwZEgweG9GeFBoWU9qQlVGZGxVQmNBUy83RmZvMzJPbGJ2NUpsOHRrOGtV?=
 =?utf-8?B?QWx0MEhYdyt2a25Hd0U0TGdmd2VWRERZcFIzazdIanJKVU1URWhCQmpFNjlE?=
 =?utf-8?B?ZmJuTXZtYW9zK2VEM1BkeHFxc1FIbHdvdS9ja0Q3OVR0K1QzOGp4bkJsQ3Iw?=
 =?utf-8?B?N1V0U0M0dVhWTG4yQnVucUZBNFkwTitMRzIybUloUTBEa3hDNmJyaGRjclV2?=
 =?utf-8?B?YXlCdXp0Vmd5T2dpblI3cG5pNlVURmg3ejRRUlFhYmlQMGs3bFV1UGJib3FJ?=
 =?utf-8?B?RXFKRHgrTjJMbElvT1JaMnM3VXNsV1hjdnFCR1hCS1VGeENmTUI3NDNHeEox?=
 =?utf-8?B?Ly9wTlpUeFBpeStqSmlKMVJDeDRyMnRWcklhTzQ0a3QvTUp4amF3U1orUzFz?=
 =?utf-8?B?M25zUlU3d2tqZ1Jxc242VUJaREk5dThpYXV5YkNEVlFJWmNEaE9HMEUrZTRa?=
 =?utf-8?B?R1dMSVcxU0xCenhMUVM3ZnpqcFRHd2lpdjVvcDdJcittR2k4NlJBb1FrQVRN?=
 =?utf-8?B?bUtabDByNmRRMHNON0tLdUxTYzhvZ3VRWHdRVXA4ankzdWRXWk1sYTFHMzI1?=
 =?utf-8?B?bW5nNkJBaXljenplbUpyeHJING5EcHo2WDJJTnlKc1JPYU5kVnVzUDc1ZThx?=
 =?utf-8?B?U0ZtWVR0UDZJNUxGK0lqMVIzcWViQWczLzlBTUdJWi8zT0g2WWdDaUVieWhI?=
 =?utf-8?B?SEE9PQ==?=
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: 157ec55d-3fcc-45c0-0c7e-08ddeee2f90f
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2025 14:21:16.4645
 (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: dhaR7hzaENchWTONfpX39CSsomyhsW4Mfb7Ujwpq46B6UFSRDuXxVHpfwduCfgJYACqYJsKY+uJh3YyEbyUgq9QxAcVfhROLoobGIRAUUnw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB6226

SGkgT2xla3NpaSwNCg0KT24gMDgvMDkvMjAyNSAxNzoxMSwgT2xla3NpaSBLdXJvY2hrbyB3cm90
ZToNCj4gSGVsbG8gZXZlcnlvbmUsDQo+IEJhc2VkIG9uIHRoZSBtZXNzYWdlIGZyb20gdGhlIHBy
ZXZpb3VzIHZlcnNpb24sIHRoZSBNSVNSQSBpc3N1ZXMgaGF2ZSBiZWVuIGZpeGVkLA0KPiBhbmQg
YXNpZGUgZnJvbSBvbmUgcmVtYWluaW5nIGRvY3VtZW50YXRpb24gcGF0Y2ggKCJkb2NzOiBhcm06
IGFkZCBkb2NzIGZvciBTQ01JDQo+IG92ZXIgU01DIGNhbGxzIGZvcndhcmRpbmcgZHJpdmVyIiks
IHRoZSBwYXRjaCBzZXJpZXMgYXBwZWFycyB0byBiZSByZWFkeS4NCkl0IHNlZW1zIHRvIG1lIHRo
YXQgSSBoYXZlIGZpeGVkIGFsbCBjb21tZW50cyBmb3IgdGhlIGRvY3VtZW50YXRpb24gDQpwYXRj
aC4gRGlkIEkgbWlzcyBzb21ldGhpbmc/IFdoeSBkbyB5b3UgdGhpbmsgaXQncyBub3QgcmVhZHkg
Zm9yIG1lcmdlPw0KPiBJIGJlbGlldmUgd2UgY2FuIGNvbnNpZGVyIGluY2x1ZGluZyBpdCBpbiA0
LjIxLiBXZSBzaG91bGQgaGF2ZSBzdWZmaWNpZW50IHRpbWUNCj4gdG8gYWRkcmVzcyBhbnkgYnVn
cyB0aGF0IG1heSBhcmlzZS4NCj4gQnkgdGhlIHdheSwgaXQgd291bGQgYWxzbyBiZSBnb29kIHRv
IHByZXBhcmUgYSBDSEFOR0VMT0cgcGF0Y2guDQpJcyBpdCBnb2luZyB0byBiZSBjaGFuZ2VkIGR1
cmluZyByZWxlYXNlIHByb2Nlc3Mgb3IgaXQgcmVxdWlyZXMgc2VwYXJhdGUgDQpwYXRjaCB0byBi
ZSBzZW50Pw0KPiBEb2VzIGFueW9uZSBoYXZlIGFueSBvYmplY3Rpb25zPw0KPiBCZXN0IHJlZ2Fy
ZHMsDQo+ICAgT2xla3NpaQ0KPiBPbiA5LzQvMjUgNDoyMSBQTSwgT2xla3NpaSBNb2lzaWVpZXYg
d3JvdGU6DQo+PiBJbnJvZHVjaW5nIFY5IHBhdGNoIHNlcmllcyAgb24gdG9wIG9mIHRoZSBYZW4g
dmVyc2lvbiA0LjIwLXJjMg0KPj4gd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2YgdGhl
IFNDSSBTQ01JIFNNQyBzaW5nbGUtYWdlbnQgc3VwcG9ydC4NCj4+DQo+PiBUaGlzIHBhdGNoIHNl
cmllcyBpcyB0aGUgZmlyc3QgY2h1bmsgb2YgdGhlDQo+PiAieGVuL2FybTogc2NtaTogaW50cm9k
dWNlIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBzdXBwb3J0IiB3aGljaCBjYW4NCj4+IGJlIGZv
dW5kIGF0IFswXQ0KPj4NCj4+IFNDTUktbXVsdGlhZ2VudCBzdXBwb3J0IHdpbGwgYmUgcHJvdmlk
ZWQgYXMgdGhlIGZvbGxvd3VwIHBhdGNoIHNlcmllcy4NCj4+DQo+PiBbMF1odHRwczovL2xvcmUu
a2VybmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMTc1MzE4NDQ4Ny5naXQub2xla3NpaV9tb2lzaWVp
ZXZAZXBhbS5jb20vDQo+Pg0KPj4gUGF0Y2ggMSAieGVuL2FybTogYWRkIGdlbmVyaWMgU0NJIHN1
YnN5c3RlbSINCj4+IC0gcmViYXNlZCBhbmQgcmVmYWN0b3JlZA0KPj4gLSBpbnRyb2R1Y2VkIERF
VklDRV9BUk1fU0NJIERUIGRldmljZSBjbGFzcyBhbmQgdXNlZCBmb3IgU0NJIGRyaXZlcnMgcHJv
YmluZw0KPj4gaW5zdGVhZCBvZiBjdXN0b20sDQo+PiAgICBsaW5rZXIgc2VjdGlvbnMgYmFzZWQg
aW1wbGVtZW50YXRpb24uDQo+PiAtIGFkZGVkIFNDSSBBUEkgZm9yIERvbTAgRFQgaGFuZGxpbmcs
IGluc3RlYWQgb2YgbWFuaXB1bGF0aW5nIHdpdGggQVJNIGFyY2gNCj4+IGRvbTAgY29kZSBkaXJl
Y3RseS4NCj4+IC0gUkZDIGNoYW5nZXMgaW4gWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlIE9QIHBy
b2Nlc3NpbmcNCj4+IC0gSW50cm9kdWNlIGFyY2hfaGFuZGxlX3Bhc3N0aHJvdWdoX3Byb3AgY2Fs
bCB0byBoYW5kbGUgYXJtIHNwZWNpZmljDQo+PiBub2Rlcw0KPj4NCj4+IFBhdGNoIDIgInhlbi9h
cm06IHNjbWktc21jOiB1cGRhdGUgdG8gYmUgdXNlZCB1bmRlciBzY2kgc3Vic3lzdGVtIg0KPj4g
LSB1cGRhdGUgZHJpdmVyIGludHJvZHVjZWQgYnkgY29tbWl0IDNlMzIyYmVmOGJjMCAoInhlbi9h
cm06IGZpcm13YXJlOiBBZGQgU0NNSQ0KPj4gb3ZlciBTTUMgY2FsbHMNCj4+IGhhbmRsaW5nIGxh
eWVyIikgYmUgdXNlZCB1bmRlciBzY2kgc3Vic3lzdGVtLg0KPj4gLSBubyBmdW5jdGlvbmFsIGNo
YW5nZXMgaW4gZ2VuZXJhbA0KPj4NCj4+IFBhdGNoIDMgInhlbi9hcm06IHNjbWktc21jOiBwYXNz
dGhyb3VnaCBTQ01JIFNNQyB0byBndWVzdCBkb21haW4NCj4+IFRoaXMgaXMgbmV3IGNoYW5nZSB3
aGljaCBhbGxvd3MgcGFzc3Rocm91Z2ggU0NNSSBTTUMsIHNpbmdsZSBhZ2VudCBpbnRlcmZhY2Ug
dG8NCj4+IGd1ZXN0IGRvbWFpbg0KPj4gY292ZXIgdXNlIGNhc2UgInRoaW4gRG9tMCB3aXRoIGd1
ZXN0IGRvbWFpbiwgd2hpY2ggc2VydmVzIGFzIERyaXZlciBkb21haW4iLg0KPj4gU2VlIHBhdGNo
IGNvbW1pdCBtZXNzYWdlIGZvciBmdWxsIGRlc2NyaXB0aW9uLg0KPj4NCj4+IFBhdGNoIDQgLSBk
b2NzOiBhcm06IGFkZCBkb2NzIGZvciBTQ01JIG92ZXIgU01DIGNhbGxzIGZvcndhcmRpbmcNCj4+
IGRyaXZlcg0KPj4gLSBhZGQgZG9jdW1lbnRhdGlvbiBzZWN0aW9uIGZvciBTaW1wbGUgQXJtIFND
TUkgb3ZlciBTTUMgY2FsbHMNCj4+IGZvcndhcmRpbmcgZHJpdmVyLg0KPj4NCj4+IENvZGUgY2Fu
IGJlIGZvdW5kIGF0Og0KPj4gaHR0cHM6Ly9naXRodWIuY29tL29sZWtzaWltb2lzaWVpZXYveGVu
L3RyZWUvc2NtaV91cHN0cnY1DQo+Pg0KPj4gWzFdIFJGQyB2MjoNCj4+IGh0dHA6Ly9wYXRjaHdv
cmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9jb3Zlci9jb3Zlci4xNjQ0MzQxNjM1Lmdp
dC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCj4+IFsyXSBSRkMgdjM6DQo+PiBodHRwczov
L3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVuLWRldmVsL3BhdGNoLzIwMjUwMzExMTEx
NjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbQ0KPj4gU0NNSSBzcGVjOg0K
Pj4gaHR0cHM6Ly9kZXZlbG9wZXIuYXJtLmNvbS9kb2N1bWVudGF0aW9uL2RlbjAwNTYvZS8/bGFu
Zz1lbg0KPj4NCj4+IFNDTUkgYmluZGluZ3M6DQo+PiBodHRwczovL3dlYi5naXQua2VybmVsLm9y
Zy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3RyZWUvRG9jdW1l
bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Zpcm13YXJlL2FybSxzY21pLnlhbWwNCj4+IGh0
dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxk
cy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvYWNjZXNz
LWNvbnRyb2xsZXJzL2FjY2Vzcy1jb250cm9sbGVycy55YW1sDQo+Pg0KPj4gUmVmZXJlbmNlIEVM
MyBGVzoNCj4+IFJQSTU6aHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvYXJtLXRydXN0ZWQt
ZmlybXdhcmUvY29tbWl0cy9ycGk1X2Rldi8NCj4+IFJlbmVzYXMgdjRoOg0KPj4gaHR0cHM6Ly9n
aXRodWIuY29tL0dyeWdpcmlpUy9hcm0tdHJ1c3RlZC1maXJtd2FyZS9jb21taXRzL3JjYXJfZ2Vu
NF92Mi43X3Y0eC1zY21pX3VwZC8NCj4+DQo+PiBiYXNlLWNvbW1pdDogZGJlNjBmMjQ0YyAoVXBk
YXRlIFhlbiB0byA0LjIxLCAyMDI1LTAyLTIxKQ0KPj4NCj4+IENoYW5nZXMgaW4gdjk6DQo+PiAt
IGNoYW5nZSBpbnB1dCBwYXJhbSBuYW1lIGZvciBzY2lfaGFuZGxlX2NhbGwgZnVuY3Rpb24gdG8g
bWF0Y2ggTUlTUkEgcnVsZXMNCj4+IC0gdXBkYXRlIGRvbXVfZHRfc2NpX3BhcnNlIGRlY2xhcmF0
aW9uIHRvIG1hdGNoIE1DM0EyLlI4LjQgTUlTUkEgcnVsZQ0KPj4NCj4+IENoYW5nZXMgaW4gdjg6
DQo+PiAtIHJlbmVyZWdhdGVkIHtoZWxwZXJzL3R5cGVzfS5nZW4uZ28sIGRyb3BwZWQgdW5uZWVk
ZWQgcGFyYW1ldGVycw0KPj4NCj4+IENoYW5nZXMgaW4gdjc6DQo+PiAtIGZpeCBzY2lfaGFuZGxf
Y2FsbCB0byBtYWtlIGNoYW5nZXMgbW9yZSByZWFkYWJsZQ0KPj4gLSBmaXggYnVpbGQgZXJyb3Ig
d2hlbiBET00wTEVTU19CVUlMRCBpcyBkaXNhYmxlZCAocmVtb3ZlZA0KPj4gICBhcmNoX2hhbmRs
ZV9wYXNzdGhyb3VnaF9wcm9wIGZyb20gdGhlIGhlYWRlcikNCj4+IC0gc29ydCBoZWFkZXJzIGlu
IGFscGhhYmV0aWNhbCBvcmRlciBpbiBzY2kuaA0KPj4gLSBzb3J0IGhlYWRlcnMgaW4gc2NtaS1z
bWMuYyBmaWxlDQo+PiAtIEZpeCBjb21taXQgZGVzY3JpcHRpb24uDQo+PiAtIE1vdmUgc2NtaS1z
bWMtcGFzc3Rocm91Z2ggZGVmaW5pdGlvbiB0byBtYXRjaCBhbHBoYWJlcmljYWwgb3JkZXINCj4+
IC0gcmVtb3ZlIHVubmVlZGVkIGluaXRpYWxpemF0aW9uIHdpdGggTlVMTA0KPj4gLSBjaGFuZ2Vk
IHU2NCB0byB1aW50NjRfdA0KPj4gLSBTZW5kIHdhcm5pbmcgaWYgaW9tZW0gcGVybWl0IGFjY2Vz
cyB3YXMgZmFpbGVkDQo+PiAtIGZpeGVkIHR5cG9zDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NjoNCj4+
IC0gcmViYXNlIG9uIHRvcCBvZiB0aGUgbGF0ZXN0IG1hc3Rlcg0KPj4gLSBmaXggcmV0dXJuIHZh
bHVlIG9mIHNjaV9kdF9maW5hbGl6ZSgpIGNhbGwNCj4+IC0gYWRkIFItYiB0YWcNCj4+IC0gYWRk
ZWQgZ2VuZXJhdGVkIGhlbHBlcnMgYW5kIHR5cGVzIGdvIGZpbGVzDQo+PiAtIHJlbmFtZSBjbWRs
aW5lIHBhcmFtZXRlciB0byBzY21pLXNtYy1wYXNzdGhyb3VnaA0KPj4gLSBmaXggZ290byB0YWcg
aW4gcGFyc2VfYXJtX3NjaV9jb25maWcNCj4+IC0gYWRkIGxpbmsgdG8gdGhlIHNjbWkgYmluZGlu
Z3MgdXNlZCBpbiB0aGUgZG9jDQo+PiAtIHJlbW92ZSBtZW50aW9ucyBhYm91dCBIVkMgY2FsbHMg
ZnJvbSBkb2MNCj4+IC0gcmVuYW1lIGNtZGxpbmUgcGFyYW1ldGVyIHRvIHNjbWktc21jLXBhc3N0
aHJvdWdoDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NToNCj4+IC0gdXBkYXRlIE1haW50YWluZXJzIGZp
bGUuIFNldCByb2xlIGFzIGEgUmV2aWV3ZXINCj4+IC0gcmViYXNlZCBvbiB0aGUgbGF0ZXN0IG1h
c3RlciBicmFuY2gNCj4+IC0gSW50cm9kdWNlIGFyY2hfaGFuZGxlX3Bhc3N0aHJvdWdoX3Byb3Ag
Y2FsbCB0byBoYW5kbGUgYXJtIHNwZWNpZmljIG5vZGVzDQo+PiAtIHJlbmFtZSBkb20wX3NjbWlf
c21jX3Bhc3N0aHJvdWdoIHRvIHNjbWlfc21jX3Bhc3N0aHJvdWdoDQo+PiAtIHJlbmFtZSBkb20w
X3NjbWlfc21jX3Bhc3N0aHJvdWdoIGluIGRvY3VtZW50YXRpb24NCj4+DQo+PiBDaGFuZ2VzIGlu
IHY0Og0KPj4gLSBmaXggU1BEWC1MaWNlbnNlDQo+PiAtIHJlbmFtZSBERVZJQ0VfQVJNX1NDSSBE
VCBkZXZpY2UgY2xhc3MgdG8gRklSTVdBUkVfREVWSUNFDQo+PiAtIG1vdmUgWEVOX0RPTUNUTF9h
c3NpZ25fZGV2aWNlIGNvZGUgaW4gc2VwYXJhdGUgcGF0Y2gNCj4+IC0gQWRkIGRvY3VtZW50YXRp
b24gZm9yIFNDSSBTQ01JIGRyaXZlcnMNCj4+IC0geGwuY2ZnIGRvYw0KPj4gLSBmaXggY29tbWVu
dHMgZnJvbSBTdGVmYW5vIFN0YWJlbGxpbmkNCj4+IC0gZml4IHRvb2xzdGFjayBjb2RlIGFzIHN1
Z2VzdGVkIGJ5IEFudGhvbnkgUEVSQVJEDQo+PiAgICAtIHVzZSBNQVRDSF9PUFRJT04oKQ0KPj4g
ICAgLSBtb3ZlIGFybV9zY2kgc3RydWN0IGFuZCBjZmcgcGFyYW1zIGluICJhcmNoX2FybSINCj4+
IC0gYWRkIFNDTUkgcGFzc3Rocm91Z2ggZm9yIGRvbTBsZXNzIGNhc2UNCj4+DQo+PiBHcnlnb3Jp
aSBTdHJhc2hrbyAoMyk6DQo+PiAgICB4ZW4vYXJtOiBzY21pLXNtYzogdXBkYXRlIHRvIGJlIHVz
ZWQgdW5kZXIgc2NpIHN1YnN5c3RlbQ0KPj4gICAgeGVuL2FybTogc2NtaS1zbWM6IHBhc3N0aHJv
dWdoIFNDTUkgU01DIHRvIGRvbWFpbiwgc2luZ2xlIGFnZW50DQo+PiAgICBkb2NzOiBhcm06IGFk
ZCBkb2NzIGZvciBTQ01JIG92ZXIgU01DIGNhbGxzIGZvcndhcmRpbmcgZHJpdmVyDQo+Pg0KPj4g
T2xla3NpaSBNb2lzaWVpZXYgKDEpOg0KPj4gICAgeGVuL2FybTogYWRkIGdlbmVyaWMgU0NJIHN1
YnN5c3RlbQ0KPj4NCj4+ICAgTUFJTlRBSU5FUlMgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICA2ICsNCj4+ICAgLi4uL2FybS9maXJtd2FyZS9hcm0tc2NtaS5yc3QgICAgICAg
ICAgICAgICAgIHwgMTgwICsrKysrKysrKysrKysrKysNCj4+ICAgZG9jcy9oeXBlcnZpc29yLWd1
aWRlL2FybS9pbmRleC5yc3QgICAgICAgICAgIHwgICA5ICsNCj4+ICAgZG9jcy9oeXBlcnZpc29y
LWd1aWRlL2luZGV4LnJzdCAgICAgICAgICAgICAgIHwgICAxICsNCj4+ICAgZG9jcy9tYW4veGwu
Y2ZnLjUucG9kLmluICAgICAgICAgICAgICAgICAgICAgIHwgIDM0ICsrKw0KPj4gICBkb2NzL21p
c2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0ICAgICAgICAgfCAgMTUgKysNCj4+ICAgZG9j
cy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jICAgICAgICAgICAgIHwgICA5ICsNCj4+ICAg
dG9vbHMvZ29sYW5nL3hlbmxpZ2h0L2hlbHBlcnMuZ2VuLmdvICAgICAgICAgIHwgIDM1ICsrKw0K
Pj4gICB0b29scy9nb2xhbmcveGVubGlnaHQvdHlwZXMuZ2VuLmdvICAgICAgICAgICAgfCAgMTEg
Kw0KPj4gICB0b29scy9pbmNsdWRlL2xpYnhsLmggICAgICAgICAgICAgICAgICAgICAgICAgfCAg
IDUgKw0KPj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jICAgICAgICAgICAgICAgICAg
fCAgMTQgKysNCj4+ICAgdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwgICAgICAgICAg
ICAgIHwgIDEwICsNCj4+ICAgdG9vbHMveGwveGxfcGFyc2UuYyAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgIDM2ICsrKysNCj4+ICAgeGVuL2FyY2gvYXJtL2RldmljZS5jICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICA1ICsNCj4+ICAgeGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMg
ICAgICAgICAgICAgICAgIHwgIDQwICsrKysNCj4+ICAgeGVuL2FyY2gvYXJtL2RvbWFpbi5jICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgIDEyICstDQo+PiAgIHhlbi9hcmNoL2FybS9kb21haW5f
YnVpbGQuYyAgICAgICAgICAgICAgICAgICB8ICAgOCArDQo+PiAgIHhlbi9hcmNoL2FybS9maXJt
d2FyZS9LY29uZmlnICAgICAgICAgICAgICAgICB8ICAyNSArKy0NCj4+ICAgeGVuL2FyY2gvYXJt
L2Zpcm13YXJlL01ha2VmaWxlICAgICAgICAgICAgICAgIHwgICAxICsNCj4+ICAgeGVuL2FyY2gv
YXJtL2Zpcm13YXJlL3NjaS5jICAgICAgICAgICAgICAgICAgIHwgMTU0ICsrKysrKysrKysrKysr
DQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy5jICAgICAgICAgICAgICB8IDE5
NCArKysrKysrKysrKysrLS0tLQ0KPj4gICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZG9tYWlu
LmggICAgICAgICAgICAgfCAgIDUgKw0KPj4gICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmly
bXdhcmUvc2NpLmggICAgICAgfCAyMDAgKysrKysrKysrKysrKysrKysrDQo+PiAgIHhlbi9hcmNo
L2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY21pLXNtYy5oICB8ICA0MSAtLS0tDQo+PiAgIHhl
bi9hcmNoL2FybS92c21jLmMgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNCArLQ0KPj4g
ICB4ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBsZXNzLWJ1aWxkLmMgICAgICAgfCAgIDQgKw0K
Pj4gICB4ZW4vaW5jbHVkZS9hc20tZ2VuZXJpYy9kZXZpY2UuaCAgICAgICAgICAgICAgfCAgIDEg
Kw0KPj4gICB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaCAgICAgICAgICAgICAgICAgfCAg
IDUgKw0KPj4gICB4ZW4vaW5jbHVkZS94ZW4vZG9tMGxlc3MtYnVpbGQuaCAgICAgICAgICAgICAg
fCAgIDMgKw0KPj4gICAyOSBmaWxlcyBjaGFuZ2VkLCA5ODIgaW5zZXJ0aW9ucygrKSwgODUgZGVs
ZXRpb25zKC0pDQo+PiAgIGNyZWF0ZSBtb2RlIDEwMDY0NCBkb2NzL2h5cGVydmlzb3ItZ3VpZGUv
YXJtL2Zpcm13YXJlL2FybS1zY21pLnJzdA0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgZG9jcy9o
eXBlcnZpc29yLWd1aWRlL2FybS9pbmRleC5yc3QNCj4+ICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhl
bi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2Fy
Y2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oDQo+PiAgIGRlbGV0ZSBtb2RlIDEwMDY0
NCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NtaS1zbWMuaA0KPj4NCg==


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:23:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:23:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115355.1462011 (Exim 4.92)
	(envelope-from )
	id 1uvcm2-00072b-3R; Mon, 08 Sep 2025 14:23:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115355.1462011; Mon, 08 Sep 2025 14:23: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 1uvcm2-00072U-0i; Mon, 08 Sep 2025 14:23:14 +0000
Received: by outflank-mailman (input) for mailman id 1115355;
 Mon, 08 Sep 2025 14:23: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 1uvcm0-00072M-Nu
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:23:12 +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 58b372d7-8cbf-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 16:23:10 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-afcb7a16441so674297466b.2
 for ; Mon, 08 Sep 2025 07:23:10 -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-aff12a6b404sm2389136766b.88.2025.09.08.07.23.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 07:23: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: 58b372d7-8cbf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757341390; x=1757946190; 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=t2J04C54WHB2YgdKhT+s3TJDuvNRnA5qAvN3ckQ2EXc=;
        b=Xq3E5WiEOKNIYg9ty4VNehchKOb1TiW2OUyRp8UDMrJEXYmS4m9lUxpb6EZrDcHxio
         MDEX4YepaMAcAy6JHa5k36ROqfSr0aVzBnCW5uf8UwqRJE9Ml1pOlbH8M6VwMrTrLN8V
         A6HDEOl5WP2goGEMpqo7DikwlPhoLSI0zGXv59uMdVNerDMlwDdecOG0zdYx1E0C2huB
         WJ9Gf9ydO/a9YtSPf48xzz7dwHgb0i1ZNuEYIh+pvIO4b3+3VlxLSRrstAfqOxInAaok
         oXEsWZiJkxZuBnLPL9k1+/+cDtWOprvtdQL90qkKdNKuMvRWLDZ2tPKINB4movIMVgrP
         3p5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757341390; x=1757946190;
        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=t2J04C54WHB2YgdKhT+s3TJDuvNRnA5qAvN3ckQ2EXc=;
        b=Wql5gq0yMbpgh+J8WybvZ6QXB0bbjvv4uPSMNr8tV252adEIciD2ZwUKq94AwazvSM
         5KxwL2GPA3FYIkrr5Bf4FQNs37P4G/trxzghimqyHl8I/EmNeCbPvo9n3qVJ6QqtPE4e
         FdLfTuW4h+UcrfXAxC2/F0FsBnXB6VbdTDLBnAdIv6c4YNjykc8i5WWUE5ZDVePPMZmz
         akLmmG7ZpECgEvvRoEJFuyOQ6+22rKhsgjQpfofWC3IV7+ryOhmYqS8Tt+xicRRJHQCs
         A5Nmc3p24gUAuPeNyJl2unviK1BnjRYIUvnT6DhRSB//fOeSNl4ZZ9I/BQWD1Sr4SAme
         gapQ==
X-Gm-Message-State: AOJu0YzDF0YmFlOKgMnFBLiau/qkWE1nxsHL2j9tkuaVMVMYiff1BZMa
	MWXJh05+Fl/fsR4w0ehU6P0EvSeYZFDVf6dA3ufkXyIkRpQaHnNqId/R
X-Gm-Gg: ASbGnctanRBgCIgEoWDbJ2bfDC+e5q3LOTD3EWPEm0eiXRy54Q9uF0bpQLfyqQCfonZ
	obFvbUJIYkmdcJ4bHd6GD78Q1tSBzeGOC/KmgVCs03a0qCQog1spMaNWeR+nb4txCC0Zt2+LRpt
	kOFhHACVCZf1YGroe3N87LlVpBWbTFdarEkC67TxzP21CKhpjWLfkLuh6Fu2DnRHUJvPS2aSdkN
	oGu3hAsTsXNSihzhKiVQ+29VvcWzzEX7R5iC9KarNYdyrbeQXugIwKkIL58cjSNH11sLZfl/4Tk
	nRrBLEyQ5kFvXSiIK5Nujq4Z8risny6Wu2wIE0RqZT8UYjkrWb2Hmp3Ge8YZfKJkfGDdVkeUCvO
	hvJnonyYlHB61ntTkzryCUbimk+hK/A6d614QWnUb+4SLjBiqCuuxvIyIG6O5fDsrYc0CeSMkwH
	IvvKbv3oo=
X-Google-Smtp-Source: AGHT+IEFmO9av6pwjcoX8SFGMe2bGCjUOm9oZqgqMi+SuNag9Ie58Dadwk+xbA0Xe0sJuof+gtP76A==
X-Received: by 2002:a17:907:60cd:b0:b04:37ca:77e7 with SMTP id a640c23a62f3a-b04b1701a0amr736180866b.44.1757341389575;
        Mon, 08 Sep 2025 07:23:09 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------B0k0jQ02Q6YalU4PRH5xLGzA"
Message-ID: 
Date: Mon, 8 Sep 2025 16:23:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 00/15] x86: introduce NS16550-compatible UART emulator
To: Mykola Kvach ,
 Stefano Stabellini 
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, dmukhin@xen.org
References: <20250905232715.440758-1-dmukhin@ford.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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

Hello Everyone,

On 9/8/25 11:04 AM, Mykola Kvach wrote:
> Hi Denis and Stefano
>
> I’d like to acknowledge the significant effort that went into this patch
> series -- it’s clear that a lot of work has been invested.
>
> On Sat, Sep 6, 2025 at 5:02 AM Stefano Stabellini
>  wrote:
>> Oleksii and all,
>>
>> I would like to consider patches 1-12 of this patch series for 4.21,
>> pending the few minor comments I made addressed.
> Although I am neither a maintainer nor an official reviewer for this
> project, I have looked over some of the first patches in the series. In my
> opinion, the series is not yet ready for merging.
>
> Even if my review is set aside, the changes are largely x86-specific and
> produce the most impact on this architecture. I believe that before
> merging, one of the x86 maintainers (or at least a trusted reviewer for
> x86, if available) should carefully review these patches.

I agree with this point. Considering that this part is being moved to
common code, it would be helpful to get some input from the x86 maintainers.

Also, since the entire patch series is not yet ready, I think it makes
sense at this stage of development to either have the whole series reviewed
or postpone it to 4.22. (The last one is preferred at the current stage of
development)

~ Oleksii


>>
>> On Fri, 5 Sep 2025,dmukhin@xen.org wrote:
>>> x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
>>> guest OS bring up in the embedded setups.
>>>
>>> This patch series introduces initial in-hypervisor emulator for
>>> NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.
>>>
>>> In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
>>> early guest firmware and OS bringup debugging, because it eliminates
>>> dependency on the external emulator (qemu) being operational by the time
>>> domains are created.
>>>
>>> The emulator also allows to forward the physical console input to the x86
>>> domain which is useful when a system has only one physical UART for early
>>> debugging and this UART is owned by Xen.
>>>
>>> By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O port
>>> 0x2f8, IRQ#3 in guest OS (legacy COM2). Legacy COM resources cannot be
>>> selected at built-time or via per-domain xl configuration in this initial
>>> submission.
>>>
>>> CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities useful
>>> for NS16550 emulator development/debugging (disabled by default).
>>>
>>> The NS16550 emulator is disabled in default x86 configuration and goes under
>>> CONFIG_EXPERT in Kconfig.
>>>
>>> Limitations
>>> ===========
>>> - Only x86;
>>> - Only legacy COM2 resources, custom I/O ports/IRQs are not supported;
>>> - Only Xen console as a backend, no inter-domain communication (similar to
>>>    vpl011 on Arm);
>>> - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
>>> - No toolstack integration;
>>> - No baud rate emulation (reports 115200 baud to the guest OS);
>>> - No FIFO-less mode emulation;
>>> - No RX FIFO interrupt moderation (FCR) emulation;
>>> - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
>>>    friends);
>>> - No MMIO-based UART emulation.
>>>
>>> Series
>>> ======
>>>
>>>    Patch 1 introduces the new vUART framework, that is the code originally
>>>    posted here:
>>>      https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@ford.com/
>>>    Required for emulator.
>>>
>>>    Patch 2 adds missing NS16550 definitions, required for emulator.
>>>
>>>    Patch 3 introduces the basic emulator skeleton - state machine
>>>    initialization stubs, I/O port handler stub, logging, etc.
>>>
>>>    Patches 4-11 incrementally populate the minimal NS16550 register emulation.
>>>
>>>    Patch 12 hooks vUART state debugging (disabled by default).
>>>
>>>    Pathes 13-15 introduce necessary changes to enable NS16550 on dom0 (and PVH).
>>>
>>> Link to CI:https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2024756493
>>> Link to branch:https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-ns8250-v6?ref_type=heads
>>>
>>> Testing
>>> =======
>>>
>>>    ```shell
>>>    echo CONFIG_EXPERT=y >> .config
>>>    echo CONFIG_VUART_NS16X50=y >> .config
>>>    make olddefconfig
>>>    ```
>>>    COM2 (0x2f8) resources are used by default.
>>>
>>>    To test w/ virtual COM2, the guest kernel parameters should contain
>>>    something like the following:
>>>      earlycon=uart,io,0x2f8,115200n8 console=uart,io,0x2f8,115200n8
>>>
>>>    HVM
>>>    ---
>>>    Tested only boot of HVM linux guest with OVMF as the virtual firmware.
>>>    SeaBIOS as a virtual firmware is not tested.
>>>
>>>    PVH (dom0)
>>>    ----------
>>>    Xen is able to forward physical console input to the domain with virtual
>>>    NS16550. To switch the console focus press Ctrl+aaa.
>>>    Console switch is limited on x86 to dom0 and Xen (fixes pending).
>>>
>>> Changes since v5:
>>> - Split THR/RBR into two separate patches.
>>> - Addressed feedback from v5.
>>> - Link to v5:https://lore.kernel.org/xen-devel/20250828235409.2835815-1-dmukhin@ford.com/
>>>
>>> Changes since v4:
>>> - Split the series to make it simpler to review.
>>> - Addressed feedback from v4.
>>> - Dropped xl changes, which I will submit separately.
>>> - Link to v4:https://lore.kernel.org/xen-devel/20250731192130.3948419-1-dmukhin@ford.com/
>>>
>>> Changes since v3:
>>> - Reduced the blast radius of the series, thanks to reviews, individual
>>>    aspects (like console focus) touched in v3 moved to separate threads.
>>> - Kept the UART emulator framework since I need to redo some of emulator code
>>>    and there's more-or-less agreement on it (where to place, naming, scope).
>>> - Applied the feedback from
>>>      https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/
>>> - Link to v3:https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/
>>>
>>> Changes since v2:
>>> - renamed emulator s/NS8250/NS16550/g
>>> - reduced the patch series after addressing v2 feedback
>>> - introduced driver framework for UART emulators
>>> - unified guest OS printouts across all available UART emulators
>>> - Link to v2:https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/
>>>
>>> Changes since v1:
>>> - dropped kmalloc/kfree aliases
>>> - fixed ECLAIR jobs (thanks Andrew Cooper)
>>> - addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
>>> - moved NS8250 debugging stubs into its own patch
>>> - added fix forhttps://gitlab.com/xen-project/xen/-/issues/184
>>> - Link to v1:https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com
>>>
>>> Denis Mukhin (15):
>>>    emul/vuart: introduce framework for UART emulators
>>>    xen/8250-uart: update definitions
>>>    emul/ns16x50: implement emulator stub
>>>    emul/ns16x50: implement DLL/DLM registers
>>>    emul/ns16x50: implement SCR register
>>>    emul/ns16x50: implement IER/IIR registers
>>>    emul/ns16x50: implement LCR/LSR registers
>>>    emul/ns16x50: implement MCR/MSR registers
>>>    emul/ns16x50: implement RBR register
>>>    emul/ns16x50: implement THR register
>>>    emul/ns16x50: implement FCR register (write-only)
>>>    emul/ns16550: implement dump_state() hook
>>>    x86/domain: enable per-domain I/O port bitmaps
>>>    xen/domain: allocate d->irq_caps before arch-specific initialization
>>>    emul/ns16x50: implement IRQ emulation via vIOAPIC
>>>
>>>   xen/arch/arm/xen.lds.S                   |   1 +
>>>   xen/arch/ppc/xen.lds.S                   |   1 +
>>>   xen/arch/riscv/xen.lds.S                 |   1 +
>>>   xen/arch/x86/Makefile                    |   1 +
>>>   xen/arch/x86/dom0_build.c                | 112 +--
>>>   xen/arch/x86/hvm/dom0_build.c            |   7 +
>>>   xen/arch/x86/hvm/hvm.c                   |  56 +-
>>>   xen/arch/x86/hvm/nestedhvm.c             |   8 +-
>>>   xen/arch/x86/hvm/quirks.c                |   3 -
>>>   xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
>>>   xen/arch/x86/hvm/vioapic.c               |  10 +
>>>   xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
>>>   xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
>>>   xen/arch/x86/include/asm/hvm/support.h   |   2 -
>>>   xen/arch/x86/include/asm/iocap.h         |   2 +
>>>   xen/arch/x86/include/asm/irq.h           |   8 +
>>>   xen/arch/x86/ioport.c                    | 163 ++++
>>>   xen/arch/x86/irq.c                       |   8 +
>>>   xen/arch/x86/pv/dom0_build.c             |   7 +
>>>   xen/arch/x86/xen.lds.S                   |   1 +
>>>   xen/common/Kconfig                       |   2 +
>>>   xen/common/Makefile                      |   1 +
>>>   xen/common/domain.c                      |   8 +-
>>>   xen/common/emul/Kconfig                  |   6 +
>>>   xen/common/emul/Makefile                 |   1 +
>>>   xen/common/emul/vuart/Kconfig            |  25 +
>>>   xen/common/emul/vuart/Makefile           |   2 +
>>>   xen/common/emul/vuart/ns16x50.c          | 984 +++++++++++++++++++++++
>>>   xen/common/emul/vuart/vuart.c            | 157 ++++
>>>   xen/common/keyhandler.c                  |   3 +
>>>   xen/drivers/char/console.c               |   6 +-
>>>   xen/drivers/char/ns16550.c               |  16 +-
>>>   xen/drivers/passthrough/x86/hvm.c        |  11 +-
>>>   xen/include/xen/8250-uart.h              |  50 +-
>>>   xen/include/xen/sched.h                  |   4 +
>>>   xen/include/xen/serial.h                 |   3 +
>>>   xen/include/xen/vuart.h                  | 116 +++
>>>   xen/include/xen/xen.lds.h                |  10 +
>>>   38 files changed, 1634 insertions(+), 171 deletions(-)
>>>   create mode 100644 xen/arch/x86/ioport.c
>>>   create mode 100644 xen/common/emul/Kconfig
>>>   create mode 100644 xen/common/emul/Makefile
>>>   create mode 100644 xen/common/emul/vuart/Kconfig
>>>   create mode 100644 xen/common/emul/vuart/Makefile
>>>   create mode 100644 xen/common/emul/vuart/ns16x50.c
>>>   create mode 100644 xen/common/emul/vuart/vuart.c
>>>   create mode 100644 xen/include/xen/vuart.h
>>>
>>> --
>>> 2.51.0
>>>
> Best regards,
> Mykola
--------------B0k0jQ02Q6YalU4PRH5xLGzA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
Hello Everyone,



    
On 9/8/25 11:04 AM, Mykola Kvach wrote:

    

    

      
Hi Denis and Stefano

I’d like to acknowledge the significant effort that went into this patch
series -- it’s clear that a lot of work has been invested.

On Sat, Sep 6, 2025 at 5:02 AM Stefano Stabellini
<sstabellini@kernel.org> wrote:


      

        
Oleksii and all,

I would like to consider patches 1-12 of this patch series for 4.21,
pending the few minor comments I made addressed.


      

      
Although I am neither a maintainer nor an official reviewer for this
project, I have looked over some of the first patches in the series. In my
opinion, the series is not yet ready for merging.

Even if my review is set aside, the changes are largely x86-specific and
produce the most impact on this architecture. I believe that before
merging, one of the x86 maintainers (or at least a trusted reviewer for
x86, if available) should carefully review these patches.


    

    
I agree with this point. Considering that this part is being moved to
common code, it would be helpful to get some input from the x86 maintainers.

    
Also, since the entire patch series is not yet ready, I think it makes
sense at this stage of development to either have the whole series reviewed
or postpone it to 4.22. (The last one is preferred at the current stage of
development)


    
~ Oleksii




    

      

      

        

On Fri, 5 Sep 2025, dmukhin@xen.org wrote:


        

          
x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
guest OS bring up in the embedded setups.

This patch series introduces initial in-hypervisor emulator for
NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.

In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
early guest firmware and OS bringup debugging, because it eliminates
dependency on the external emulator (qemu) being operational by the time
domains are created.

The emulator also allows to forward the physical console input to the x86
domain which is useful when a system has only one physical UART for early
debugging and this UART is owned by Xen.

By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O port
0x2f8, IRQ#3 in guest OS (legacy COM2). Legacy COM resources cannot be
selected at built-time or via per-domain xl configuration in this initial
submission.

CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities useful
for NS16550 emulator development/debugging (disabled by default).

The NS16550 emulator is disabled in default x86 configuration and goes under
CONFIG_EXPERT in Kconfig.

Limitations
===========
- Only x86;
- Only legacy COM2 resources, custom I/O ports/IRQs are not supported;
- Only Xen console as a backend, no inter-domain communication (similar to
  vpl011 on Arm);
- Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
- No toolstack integration;
- No baud rate emulation (reports 115200 baud to the guest OS);
- No FIFO-less mode emulation;
- No RX FIFO interrupt moderation (FCR) emulation;
- No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
  friends);
- No MMIO-based UART emulation.

Series
======

  Patch 1 introduces the new vUART framework, that is the code originally
  posted here:
    https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@ford.com/
  Required for emulator.

  Patch 2 adds missing NS16550 definitions, required for emulator.

  Patch 3 introduces the basic emulator skeleton - state machine
  initialization stubs, I/O port handler stub, logging, etc.

  Patches 4-11 incrementally populate the minimal NS16550 register emulation.

  Patch 12 hooks vUART state debugging (disabled by default).

  Pathes 13-15 introduce necessary changes to enable NS16550 on dom0 (and PVH).

Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2024756493
Link to branch: https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-ns8250-v6?ref_type=heads

Testing
=======

  ```shell
  echo CONFIG_EXPERT=y >> .config
  echo CONFIG_VUART_NS16X50=y >> .config
  make olddefconfig
  ```
  COM2 (0x2f8) resources are used by default.

  To test w/ virtual COM2, the guest kernel parameters should contain
  something like the following:
    earlycon=uart,io,0x2f8,115200n8 console=uart,io,0x2f8,115200n8

  HVM
  ---
  Tested only boot of HVM linux guest with OVMF as the virtual firmware.
  SeaBIOS as a virtual firmware is not tested.

  PVH (dom0)
  ----------
  Xen is able to forward physical console input to the domain with virtual
  NS16550. To switch the console focus press Ctrl+aaa.
  Console switch is limited on x86 to dom0 and Xen (fixes pending).

Changes since v5:
- Split THR/RBR into two separate patches.
- Addressed feedback from v5.
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-1-dmukhin@ford.com/

Changes since v4:
- Split the series to make it simpler to review.
- Addressed feedback from v4.
- Dropped xl changes, which I will submit separately.
- Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-1-dmukhin@ford.com/

Changes since v3:
- Reduced the blast radius of the series, thanks to reviews, individual
  aspects (like console focus) touched in v3 moved to separate threads.
- Kept the UART emulator framework since I need to redo some of emulator code
  and there's more-or-less agreement on it (where to place, naming, scope).
- Applied the feedback from
    https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/
- Link to v3: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/

Changes since v2:
- renamed emulator s/NS8250/NS16550/g
- reduced the patch series after addressing v2 feedback
- introduced driver framework for UART emulators
- unified guest OS printouts across all available UART emulators
- Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/

Changes since v1:
- dropped kmalloc/kfree aliases
- fixed ECLAIR jobs (thanks Andrew Cooper)
- addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
- moved NS8250 debugging stubs into its own patch
- added fix for https://gitlab.com/xen-project/xen/-/issues/184
- Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com

Denis Mukhin (15):
  emul/vuart: introduce framework for UART emulators
  xen/8250-uart: update definitions
  emul/ns16x50: implement emulator stub
  emul/ns16x50: implement DLL/DLM registers
  emul/ns16x50: implement SCR register
  emul/ns16x50: implement IER/IIR registers
  emul/ns16x50: implement LCR/LSR registers
  emul/ns16x50: implement MCR/MSR registers
  emul/ns16x50: implement RBR register
  emul/ns16x50: implement THR register
  emul/ns16x50: implement FCR register (write-only)
  emul/ns16550: implement dump_state() hook
  x86/domain: enable per-domain I/O port bitmaps
  xen/domain: allocate d->irq_caps before arch-specific initialization
  emul/ns16x50: implement IRQ emulation via vIOAPIC

 xen/arch/arm/xen.lds.S                   |   1 +
 xen/arch/ppc/xen.lds.S                   |   1 +
 xen/arch/riscv/xen.lds.S                 |   1 +
 xen/arch/x86/Makefile                    |   1 +
 xen/arch/x86/dom0_build.c                | 112 +--
 xen/arch/x86/hvm/dom0_build.c            |   7 +
 xen/arch/x86/hvm/hvm.c                   |  56 +-
 xen/arch/x86/hvm/nestedhvm.c             |   8 +-
 xen/arch/x86/hvm/quirks.c                |   3 -
 xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
 xen/arch/x86/hvm/vioapic.c               |  10 +
 xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
 xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
 xen/arch/x86/include/asm/hvm/support.h   |   2 -
 xen/arch/x86/include/asm/iocap.h         |   2 +
 xen/arch/x86/include/asm/irq.h           |   8 +
 xen/arch/x86/ioport.c                    | 163 ++++
 xen/arch/x86/irq.c                       |   8 +
 xen/arch/x86/pv/dom0_build.c             |   7 +
 xen/arch/x86/xen.lds.S                   |   1 +
 xen/common/Kconfig                       |   2 +
 xen/common/Makefile                      |   1 +
 xen/common/domain.c                      |   8 +-
 xen/common/emul/Kconfig                  |   6 +
 xen/common/emul/Makefile                 |   1 +
 xen/common/emul/vuart/Kconfig            |  25 +
 xen/common/emul/vuart/Makefile           |   2 +
 xen/common/emul/vuart/ns16x50.c          | 984 +++++++++++++++++++++++
 xen/common/emul/vuart/vuart.c            | 157 ++++
 xen/common/keyhandler.c                  |   3 +
 xen/drivers/char/console.c               |   6 +-
 xen/drivers/char/ns16550.c               |  16 +-
 xen/drivers/passthrough/x86/hvm.c        |  11 +-
 xen/include/xen/8250-uart.h              |  50 +-
 xen/include/xen/sched.h                  |   4 +
 xen/include/xen/serial.h                 |   3 +
 xen/include/xen/vuart.h                  | 116 +++
 xen/include/xen/xen.lds.h                |  10 +
 38 files changed, 1634 insertions(+), 171 deletions(-)
 create mode 100644 xen/arch/x86/ioport.c
 create mode 100644 xen/common/emul/Kconfig
 create mode 100644 xen/common/emul/Makefile
 create mode 100644 xen/common/emul/vuart/Kconfig
 create mode 100644 xen/common/emul/vuart/Makefile
 create mode 100644 xen/common/emul/vuart/ns16x50.c
 create mode 100644 xen/common/emul/vuart/vuart.c
 create mode 100644 xen/include/xen/vuart.h

--
2.51.0



        

        

      

      
Best regards,
Mykola


    

  


--------------B0k0jQ02Q6YalU4PRH5xLGzA--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 14:31:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 14:31:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115366.1462021 (Exim 4.92)
	(envelope-from )
	id 1uvcuK-0000Qp-RU; Mon, 08 Sep 2025 14:31:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115366.1462021; Mon, 08 Sep 2025 14:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvcuK-0000Qi-Os; Mon, 08 Sep 2025 14:31:48 +0000
Received: by outflank-mailman (input) for mailman id 1115366;
 Mon, 08 Sep 2025 14:31: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 1uvcuJ-0000Qa-K3
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 14:31:47 +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 8c273081-8cc0-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 16:31:46 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-afcb7ae6ed0so715500066b.3
 for ; Mon, 08 Sep 2025 07:31:46 -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-aff0681aefdsm2509065866b.8.2025.09.08.07.31.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 07:31: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: 8c273081-8cc0-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757341906; x=1757946706; 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=gTnAGsvaRP34XBIxc1sSDELAPuvbtMj5Wn5Vr704pRY=;
        b=EkQZ2uzjpABWYjOOZkMFg9AT02JuVjpf2TzlU5T+SfbYnG4MZMlCqKBwaQ5kWjM5I4
         cJ5M3zJi9aBteNE/ooAyfG5dhaMJsnzkZX3GGyCecNf7VucXCpwbbVfZYemc2zU77rtD
         +6P4+MzBcTdJ8fTjEklKt2k6LhNLIZsIpFpHHa4ZbeCBTcl2jrHdArP2zZUNcbrR5qOU
         DAXiR5quAy3yx4No3FgH73E3QJSgqJnL3tpMrYRsoQJUnyghsEIuwsW47IMYU0xgfzZd
         ySYbrDrPHLh9OJtXeQJyGl0AHUWB0U+clG16N9rmgk96yYniA5aGbJN+Bayyv466z+LJ
         Sw+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757341906; x=1757946706;
        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=gTnAGsvaRP34XBIxc1sSDELAPuvbtMj5Wn5Vr704pRY=;
        b=pveSkGT4qctUG+NcUtBzHQh0is+/t7eNnLecMyQnUEShePeAe5HaQVsumRyMHPkhxM
         kte0cBP5IGRDhLUk3xxVELAYpr+NJU7UGHPMslRjKSVMskmND8REovO8roWMoZ9u9iz8
         klwArK04DotNrN77RO4XOPfz25ZIx9K2I5oNIpvDz0goAk2qD2vxpz3ohDQ1DJjg5DFy
         g8n+hsj/FVmGwldA0uPmswt2XX/med8ko4JMU3uCXdeAALFGyrAZvgiG1c0MaazT/vBP
         UUQQt8hwdVQrj47M7oBdKDy8PUDtTVoV+sLpl7YspqWE9o4BYI8nRV4OKdkyUmh8SECI
         6ZEw==
X-Forwarded-Encrypted: i=1; AJvYcCW/hNH/5Y4UZRTJQhWT62z0Ih1oG0eBDpZVhUYbUEruKAIkTPifJFMpIYV2MsAKHERlGRa8ggpP3kU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzP5oZzfRz0eIQ2LWk6Y1yvV0KA+q3/9BmQr4hs92YSA9qcPU7e
	a6WEFOg6/EhXYirivTtTIYOsAwXUMMAs9IubEbfp82cXreVX3MgxoZ/s
X-Gm-Gg: ASbGncvVPLPyilHGZYahJehH2xLY1YuZOsJeXyXVPRRdd+qRJ06W2XrMj2RZgZBHU9M
	chfjAQZUa3jyE08VerDoQ2lBdAFgqtnuDXpo8GvW0SUtMrrg9yN13sG9k4TAV7HcqVDiu2TTk9l
	r91X+JNfsX5fSCMAGR4HGYAknK6ksSiVQ2JgrLaHCSZMMqoWYbKkHIkwxI71TYH4Z2yRAo/2WWY
	F77janyo7Bz3Rv68G8w55Uz46xEFIIMXLO1HsWf/drO8GzWHH5qqx8dhqQX37f1/2+sJxBU7tlT
	2U4zvMSHLHKfK3UaUjvx2oILUDVn1L/QW5k2gLzMihznmBHjNvwPUch03rU9rv5WwKFybJB75tS
	e3ht/BfjmDVcDIl5ktJrUOr+Js4G9ffT4doEcqtQ5O75XvSk4Hkslj9o4OlYy4xp4QR44yLsWwq
	Nn6y5wHvjjeH1HD0ZClw==
X-Google-Smtp-Source: AGHT+IEAobtqTdYEVKPJKy53dUqk7nnvS2fcUPLvmFMEqXl+JTNfFfUGlOWdQnHpvHZ2m9xodYOllg==
X-Received: by 2002:a17:907:da0:b0:b04:93f7:8b55 with SMTP id a640c23a62f3a-b04b14529eamr802968766b.21.1757341904856;
        Mon, 08 Sep 2025 07:31:44 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------NOS1zJdU5q70T088PNc98hq0"
Message-ID: <5bc8844d-fcde-48a0-9992-0f1a105a563e@gmail.com>
Date: Mon, 8 Sep 2025 16:31:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini 
Cc: 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 
References: 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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

Hello Oleksii,

On 9/8/25 4:21 PM, Oleksii Moisieiev wrote:
> On 08/09/2025 17:11, Oleksii Kurochko wrote:
>> Hello everyone,
>> Based on the message from the previous version, the MISRA issues have been fixed,
>> and aside from one remaining documentation patch ("docs: arm: add docs for SCMI
>> over SMC calls forwarding driver"), the patch series appears to be ready.
> It seems to me that I have fixed all comments for the documentation
> patch. Did I miss something? Why do you think it's not ready for merge?

I don't see any proper/Reviewed-by/ or/Acked-by/ tags, only/Signed-off-by/:
   Signed-off-by: Grygorii Strashko
   Signed-off-by: Oleksii Moisieiev

Am I missing something?

>> I believe we can consider including it in 4.21. We should have sufficient time
>> to address any bugs that may arise.
>> By the way, it would also be good to prepare a CHANGELOG patch.
> Is it going to be changed during release process or it requires separate
> patch to be sent?

I'm not entirely sure I understand the first part of the sentence correctly,
but both options could work (IIUC).

I can send an update to the CHANGELOG as part of the release process,
but I'm also fine if you prefer to send a separate patch or apply a new patch
to this series using the Message-ID.

Please let me know which option you prefer.

~ Oleksii

>> Does anyone have any objections?
>> Best regards,
>>    Oleksii
>> On 9/4/25 4:21 PM, Oleksii Moisieiev wrote:
>>> Inroducing V9 patch series  on top of the Xen version 4.20-rc2
>>> which includes implementation of the SCI SCMI SMC single-agent support.
>>>
>>> This patch series is the first chunk of the
>>> "xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
>>> be found at [0]
>>>
>>> SCMI-multiagent support will be provided as the followup patch series.
>>>
>>> [0]https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/
>>>
>>> Patch 1 "xen/arm: add generic SCI subsystem"
>>> - rebased and refactored
>>> - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
>>> instead of custom,
>>>     linker sections based implementation.
>>> - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
>>> dom0 code directly.
>>> - RFC changes in XEN_DOMCTL_assign_device OP processing
>>> - Introduce arch_handle_passthrough_prop call to handle arm specific
>>> nodes
>>>
>>> Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
>>> - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI
>>> over SMC calls
>>> handling layer") be used under sci subsystem.
>>> - no functional changes in general
>>>
>>> Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
>>> This is new change which allows passthrough SCMI SMC, single agent interface to
>>> guest domain
>>> cover use case "thin Dom0 with guest domain, which serves as Driver domain".
>>> See patch commit message for full description.
>>>
>>> Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
>>> driver
>>> - add documentation section for Simple Arm SCMI over SMC calls
>>> forwarding driver.
>>>
>>> Code can be found at:
>>> https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5
>>>
>>> [1] RFC v2:
>>> http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/
>>> [2] RFC v3:
>>> https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927-1-grygorii_strashko@epam.com
>>> SCMI spec:
>>> https://developer.arm.com/documentation/den0056/e/?lang=en
>>>
>>> SCMI bindings:
>>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
>>>
>>> Reference EL3 FW:
>>> RPI5:https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
>>> Renesas v4h:
>>> https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/
>>>
>>> base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)
>>>
>>> Changes in v9:
>>> - change input param name for sci_handle_call function to match MISRA rules
>>> - update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule
>>>
>>> Changes in v8:
>>> - reneregated {helpers/types}.gen.go, dropped unneeded parameters
>>>
>>> Changes in v7:
>>> - fix sci_handl_call to make changes more readable
>>> - fix build error when DOM0LESS_BUILD is disabled (removed
>>>    arch_handle_passthrough_prop from the header)
>>> - sort headers in alphabetical order in sci.h
>>> - sort headers in scmi-smc.c file
>>> - Fix commit description.
>>> - Move scmi-smc-passthrough definition to match alphaberical order
>>> - remove unneeded initialization with NULL
>>> - changed u64 to uint64_t
>>> - Send warning if iomem permit access was failed
>>> - fixed typos
>>>
>>> Changes in v6:
>>> - rebase on top of the latest master
>>> - fix return value of sci_dt_finalize() call
>>> - add R-b tag
>>> - added generated helpers and types go files
>>> - rename cmdline parameter to scmi-smc-passthrough
>>> - fix goto tag in parse_arm_sci_config
>>> - add link to the scmi bindings used in the doc
>>> - remove mentions about HVC calls from doc
>>> - rename cmdline parameter to scmi-smc-passthrough
>>>
>>> Changes in v5:
>>> - update Maintainers file. Set role as a Reviewer
>>> - rebased on the latest master branch
>>> - Introduce arch_handle_passthrough_prop call to handle arm specific nodes
>>> - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
>>> - rename dom0_scmi_smc_passthrough in documentation
>>>
>>> Changes in v4:
>>> - fix SPDX-License
>>> - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
>>> - move XEN_DOMCTL_assign_device code in separate patch
>>> - Add documentation for SCI SCMI drivers
>>> - xl.cfg doc
>>> - fix comments from Stefano Stabellini
>>> - fix toolstack code as sugested by Anthony PERARD
>>>     - use MATCH_OPTION()
>>>     - move arm_sci struct and cfg params in "arch_arm"
>>> - add SCMI passthrough for dom0less case
>>>
>>> Grygorii Strashko (3):
>>>     xen/arm: scmi-smc: update to be used under sci subsystem
>>>     xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
>>>     docs: arm: add docs for SCMI over SMC calls forwarding driver
>>>
>>> Oleksii Moisieiev (1):
>>>     xen/arm: add generic SCI subsystem
>>>
>>>    MAINTAINERS                                   |   6 +
>>>    .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
>>>    docs/hypervisor-guide/arm/index.rst           |   9 +
>>>    docs/hypervisor-guide/index.rst               |   1 +
>>>    docs/man/xl.cfg.5.pod.in                      |  34 +++
>>>    docs/misc/arm/device-tree/booting.txt         |  15 ++
>>>    docs/misc/xen-command-line.pandoc             |   9 +
>>>    tools/golang/xenlight/helpers.gen.go          |  35 +++
>>>    tools/golang/xenlight/types.gen.go            |  11 +
>>>    tools/include/libxl.h                         |   5 +
>>>    tools/libs/light/libxl_arm.c                  |  14 ++
>>>    tools/libs/light/libxl_types.idl              |  10 +
>>>    tools/xl/xl_parse.c                           |  36 ++++
>>>    xen/arch/arm/device.c                         |   5 +
>>>    xen/arch/arm/dom0less-build.c                 |  40 ++++
>>>    xen/arch/arm/domain.c                         |  12 +-
>>>    xen/arch/arm/domain_build.c                   |   8 +
>>>    xen/arch/arm/firmware/Kconfig                 |  25 ++-
>>>    xen/arch/arm/firmware/Makefile                |   1 +
>>>    xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
>>>    xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
>>>    xen/arch/arm/include/asm/domain.h             |   5 +
>>>    xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
>>>    xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
>>>    xen/arch/arm/vsmc.c                           |   4 +-
>>>    xen/common/device-tree/dom0less-build.c       |   4 +
>>>    xen/include/asm-generic/device.h              |   1 +
>>>    xen/include/public/arch-arm.h                 |   5 +
>>>    xen/include/xen/dom0less-build.h              |   3 +
>>>    29 files changed, 982 insertions(+), 85 deletions(-)
>>>    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/include/asm/firmware/sci.h
>>>    delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
>>>
--------------NOS1zJdU5q70T088PNc98hq0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
Hello Oleksii,


    
On 9/8/25 4:21 PM, Oleksii Moisieiev
      wrote:


    

      
On 08/09/2025 17:11, Oleksii Kurochko wrote:


      

        
Hello everyone,
Based on the message from the previous version, the MISRA issues have been fixed,
and aside from one remaining documentation patch ("docs: arm: add docs for SCMI
over SMC calls forwarding driver"), the patch series appears to be ready.


      

      
It seems to me that I have fixed all comments for the documentation 
patch. Did I miss something? Why do you think it's not ready for merge?

    

    
I don't see any proper Reviewed-by or Acked-by tags, only Signed-off-by:
  Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
  Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>

Am I missing something?


    

    

      

      

        
I believe we can consider including it in 4.21. We should have sufficient time
to address any bugs that may arise.
By the way, it would also be good to prepare a CHANGELOG patch.


      

      
Is it going to be changed during release process or it requires separate 
patch to be sent?

    

    
I'm not entirely sure I understand the first part of the sentence correctly,
but both options could work (IIUC).

    
I can send an update to the CHANGELOG as part of the release process,
but I'm also fine if you prefer to send a separate patch or apply a new patch
to this series using the Message-ID.

Please let me know which option you prefer.

~ Oleksii



    

      

      

        
Does anyone have any objections?
Best regards,
  Oleksii
On 9/4/25 4:21 PM, Oleksii Moisieiev wrote:


        

          
Inroducing V9 patch series  on top of the Xen version 4.20-rc2
which includes implementation of the SCI SCMI SMC single-agent support.

This patch series is the first chunk of the
"xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
be found at [0]

SCMI-multiagent support will be provided as the followup patch series.

[0]https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/

Patch 1 "xen/arm: add generic SCI subsystem"
- rebased and refactored
- introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
instead of custom,
   linker sections based implementation.
- added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
dom0 code directly.
- RFC changes in XEN_DOMCTL_assign_device OP processing
- Introduce arch_handle_passthrough_prop call to handle arm specific
nodes

Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
- update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI
over SMC calls
handling layer") be used under sci subsystem.
- no functional changes in general

Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
This is new change which allows passthrough SCMI SMC, single agent interface to
guest domain
cover use case "thin Dom0 with guest domain, which serves as Driver domain".
See patch commit message for full description.

Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
driver
- add documentation section for Simple Arm SCMI over SMC calls
forwarding driver.

Code can be found at:
https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5

[1] RFC v2:
http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/
[2] RFC v3:
https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927-1-grygorii_strashko@epam.com
SCMI spec:
https://developer.arm.com/documentation/den0056/e/?lang=en

SCMI bindings:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml

Reference EL3 FW:
RPI5:https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
Renesas v4h:
https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/

base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)

Changes in v9:
- change input param name for sci_handle_call function to match MISRA rules
- update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule

Changes in v8:
- reneregated {helpers/types}.gen.go, dropped unneeded parameters

Changes in v7:
- fix sci_handl_call to make changes more readable
- fix build error when DOM0LESS_BUILD is disabled (removed
  arch_handle_passthrough_prop from the header)
- sort headers in alphabetical order in sci.h
- sort headers in scmi-smc.c file
- Fix commit description.
- Move scmi-smc-passthrough definition to match alphaberical order
- remove unneeded initialization with NULL
- changed u64 to uint64_t
- Send warning if iomem permit access was failed
- fixed typos

Changes in v6:
- rebase on top of the latest master
- fix return value of sci_dt_finalize() call
- add R-b tag
- added generated helpers and types go files
- rename cmdline parameter to scmi-smc-passthrough
- fix goto tag in parse_arm_sci_config
- add link to the scmi bindings used in the doc
- remove mentions about HVC calls from doc
- rename cmdline parameter to scmi-smc-passthrough

Changes in v5:
- update Maintainers file. Set role as a Reviewer
- rebased on the latest master branch
- Introduce arch_handle_passthrough_prop call to handle arm specific nodes
- rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
- rename dom0_scmi_smc_passthrough in documentation

Changes in v4:
- fix SPDX-License
- rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
- move XEN_DOMCTL_assign_device code in separate patch
- Add documentation for SCI SCMI drivers
- xl.cfg doc
- fix comments from Stefano Stabellini
- fix toolstack code as sugested by Anthony PERARD
   - use MATCH_OPTION()
   - move arm_sci struct and cfg params in "arch_arm"
- add SCMI passthrough for dom0less case

Grygorii Strashko (3):
   xen/arm: scmi-smc: update to be used under sci subsystem
   xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
   docs: arm: add docs for SCMI over SMC calls forwarding driver

Oleksii Moisieiev (1):
   xen/arm: add generic SCI subsystem

  MAINTAINERS                                   |   6 +
  .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
  docs/hypervisor-guide/arm/index.rst           |   9 +
  docs/hypervisor-guide/index.rst               |   1 +
  docs/man/xl.cfg.5.pod.in                      |  34 +++
  docs/misc/arm/device-tree/booting.txt         |  15 ++
  docs/misc/xen-command-line.pandoc             |   9 +
  tools/golang/xenlight/helpers.gen.go          |  35 +++
  tools/golang/xenlight/types.gen.go            |  11 +
  tools/include/libxl.h                         |   5 +
  tools/libs/light/libxl_arm.c                  |  14 ++
  tools/libs/light/libxl_types.idl              |  10 +
  tools/xl/xl_parse.c                           |  36 ++++
  xen/arch/arm/device.c                         |   5 +
  xen/arch/arm/dom0less-build.c                 |  40 ++++
  xen/arch/arm/domain.c                         |  12 +-
  xen/arch/arm/domain_build.c                   |   8 +
  xen/arch/arm/firmware/Kconfig                 |  25 ++-
  xen/arch/arm/firmware/Makefile                |   1 +
  xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
  xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
  xen/arch/arm/include/asm/domain.h             |   5 +
  xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
  xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
  xen/arch/arm/vsmc.c                           |   4 +-
  xen/common/device-tree/dom0less-build.c       |   4 +
  xen/include/asm-generic/device.h              |   1 +
  xen/include/public/arch-arm.h                 |   5 +
  xen/include/xen/dom0less-build.h              |   3 +
  29 files changed, 982 insertions(+), 85 deletions(-)
  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/include/asm/firmware/sci.h
  delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h



        

      

    

  


--------------NOS1zJdU5q70T088PNc98hq0--


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 15:30:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 15:30:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115394.1462032 (Exim 4.92)
	(envelope-from )
	id 1uvdos-00005d-VN; Mon, 08 Sep 2025 15:30:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115394.1462032; Mon, 08 Sep 2025 15: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 1uvdos-00005V-Sa; Mon, 08 Sep 2025 15:30:14 +0000
Received: by outflank-mailman (input) for mailman id 1115394;
 Mon, 08 Sep 2025 15:30: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 1uvdor-00005O-8y
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 15:30:13 +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 b33b962b-8cc8-11f0-9809-7dc792cee155;
 Mon, 08 Sep 2025 17:30:08 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AM9PR03MB6850.eurprd03.prod.outlook.com (2603:10a6:20b:2dd::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Mon, 8 Sep
 2025 15:30:05 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9094.016; Mon, 8 Sep 2025
 15:30: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: b33b962b-8cc8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fUIOx/X5+lF/hEV2xKxIzKOjEtCqV6h0Oi8PYPj7uHv1rG7XZj22whgljVqejahtTcg8vqMOjbTUxr4HAWKUVSQR6OtuoDpBQxlSwHhZ7x/qkHJBa506hY8qCvIQyLCeKxql1wCGr5i6ympb+430IBis1bj8qQa74Etl5jr9ogy77EnHgW9CWMlLea+Px6Tm+iGqgmS55Ap5sYsXjJheuKyIB/j7NCNvzCzA3xwbtDQCLtBo85lkMbh2d0Q2OEoBTE0YVMwyRO+A1zowuF+53EE7UUDQZK5GFHayVfA3zBhWLE/fIBGvyC4qafQVtxx8JJhtLXV40grwqXFkxAr+fQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DtRI3CwvtHt/pVDL3t/9fNTT5Irk0ITL3afcRpnstds=;
 b=U0YT3WF1LYLHc0cBUikGY/jkYieEciYNT2ZXwkkXbnGLn3CC3UgLZ9dgmZcQXU+7e3+Lh6m7qxGebFPKmd7lUbCpl5Ic9UKN0aPbSXbM01VT1FCzLgfVWnxsnNSuPyIqaQYDh6EbvWYgUmWSJu5sF6h3RIM0bGd8hrSelXuWuNPZI1CXd/OM44H01wtPhbA0Ah8T7jbvEAjWTOanv0EUwkSG5ZoiZQ475uxgyMRt/tDg5VcupLexTR34IJOUpgvB6Twy63rXlNzeVO7VJeiltVosksPIjN8ou+4NIJ+Ng9JxaNBKMqUb6BSqzBt1uOGCafEtemqm38IdC/g3JGwzrg==
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=DtRI3CwvtHt/pVDL3t/9fNTT5Irk0ITL3afcRpnstds=;
 b=NAUlacQDG+xGd0Y4l4bqsIblCGT5/K4VQrgac+MNJtlAD+bbskFcSnw+CEOIvHzPtej8cxYCa+jt6dZdj4gZhO60hcqB3mNDgu0svRsjN1cyfScXJKFFXnEcPyHnXb8xk/daWKmh1dEpuUY5w+nOcnhI+cI00KYizVIkVBlhcud6ZaOyqP0qISUCCudtbQ0+r0JEwkKSvuVZESdN7I0hV6zhwU0xym+VaOZxBkWEbOucW5/ym4xGUbDQ5TWP7O+VJ2nl55zQuoNbk7FWak3IaDyg7zYVWWKP/NpLzppJMOOWI6/yXTIZMTVhUwzBNBI2bWzJUVpLprJIYC7eXKNwIg==
From: Oleksii Moisieiev 
To: Oleksii Kurochko ,
	"xen-devel@lists.xenproject.org" , Stefano
 Stabellini 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
Thread-Topic: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC
 single-agent support
Thread-Index: AQHcHaczzFSreK7re0KgM50DbxoBaLSJWYOAgAAC2ACAAALtAIAAEE2A
Date: Mon, 8 Sep 2025 15:30:05 +0000
Message-ID: <062bd466-012a-454a-85ab-1b597c40e4ab@epam.com>
References: 
 
 
 <5bc8844d-fcde-48a0-9992-0f1a105a563e@gmail.com>
In-Reply-To: <5bc8844d-fcde-48a0-9992-0f1a105a563e@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_|AM9PR03MB6850:EE_
x-ms-office365-filtering-correlation-id: d6122b15-8f38-4c04-a24e-08ddeeec95e9
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?NkZhVjAxVEVOTUJVY2ZtVlB3SFRqYTBkWmtKZnR1UTNLOGNjZHNaVFI0dmdt?=
 =?utf-8?B?WVFQbW50K3dEckx6Y1AzQ0FqM3A3SE1NQXg5TGNJUkZRQ1pab04yTFlmbDNy?=
 =?utf-8?B?MlhXVEFkam5yR0VIaFVzMzVoTnZmQi8zc0xaS2VUQWxHUStPMCtab0VxVmRi?=
 =?utf-8?B?NTZyZzBHRGxTb1VQeTNKMnYzVXVnWUtPaTQ4clpsd253ZXUrMmtWeEJtWW5L?=
 =?utf-8?B?Zy9NV0JGellIR1NmRnFqSU4zUFh3cGJHMWRHVCsrSTkvcmFDc1ZTOGN3ZzNL?=
 =?utf-8?B?NUFFRWQweG1DK2U2MmVwL3BGZG8wcDd0QzFZL3ZkNFIvY2YvU1lieWNEejBD?=
 =?utf-8?B?MWI2UWJXK3BJK0lxYnFobFkyVjdyaERYSEVCM2YrRjRrN3BvT3cxS0FCTHhJ?=
 =?utf-8?B?NGpkMTI5VWw2YjlDbDV5Z2xRTFFpOERRV3ZXSXgwcG1DbFN5bXJvRi9pdHo1?=
 =?utf-8?B?Ulgrb1FiZHY4MmFmUjZUb2phZElvcXl3YmtuSnhWdmFKUlpLc1Urckh3VU9F?=
 =?utf-8?B?WURja3Y0S0x5Y05ISGVseHhOUG82dm9ZNFJBOU5VTStKQUtEcTVuY3I5L2JK?=
 =?utf-8?B?cnZPTjNaU0FwYWhUd0tYbjJhSk9kc1NReWs3ekpDZGtwb1dHL09MLzdidDVY?=
 =?utf-8?B?ZlZSeUxqYm1FcGdCa1pQMEMzeGtaa3hHYVRpQlRBVndqL08zVVpFblNSczdq?=
 =?utf-8?B?ekY5bU55MUpkazdGai92M0pyN0pQOUpHR2thNDJmUE5VVlBTa2djdU1NZ1kx?=
 =?utf-8?B?amRRTE42REd5bnozdC9tQVpZczJoWEdRV2taSERKSk5ucEpWcEhtazdvcGdt?=
 =?utf-8?B?UWdGTm9XRUZlYWJ2MUVxTEZjL1NSczdYU1hoYlR5eUNnczZpZmZYOTdPc2h5?=
 =?utf-8?B?dDMwQ3A0YjBLOEkvdk5pQWpGMDQ5TDhpU2MwL2VJeThmU2QxVEgxTGFmcmFh?=
 =?utf-8?B?TENHbXJZYkVyQjRMUFU5Wi9LN0dQbXNIeHpzZnV0Yk83Yi9HajZ4L3FrNGRn?=
 =?utf-8?B?YS9xc0ZndDhEaFErYzc1emc3RWpoUmorTVE0S0thbG1NTXRjLzNkT2lRUVJh?=
 =?utf-8?B?YmMwYnpjTDVkVDd2VlFuS2dGSHpzYld0ZWpzWFBaM0cxaUIyUnBrdVRnNy9r?=
 =?utf-8?B?Z1U1dzVoR2RmN2xEd1VCNCtiSytGL2plL2UrcjlNc2dFc0hKMHk4RStqQ1lM?=
 =?utf-8?B?L1RKS2UzZEVpcWFTbWVpUjhyODcxcUNSTEpxRzBEM2l3ZXhKWEFia0krem42?=
 =?utf-8?B?YnlJcDRKUGg4NThydmduQVo5UmpCVjI4MzA5NHFsaGJUcTBUYXdyNDZOclZr?=
 =?utf-8?B?UGljSVNVbXJUZHNpd3NnUzhiT081Zm5aU0tRL2ZaTndpUnIwdEhTNFQyZ1hZ?=
 =?utf-8?B?WXdIbUtwTE51TWE3dno1S3JNT3FOZ1c2ei82bFA3T3poSU1uS1JPVkRBN3NW?=
 =?utf-8?B?V0tScEYwVHV4L21IVVhwVFVsWi9Rd3hiUHJGcHJyRHlBdFltTi9Wc2JObUpm?=
 =?utf-8?B?TlJZUW4zc3l1QjNjSkNZakRHVWE5V0N3emtRMTg5Zk5aeVNyd0VOSjhQMTlw?=
 =?utf-8?B?UDNyWnYxUEw2bHpQVWkzWDhmY2lORitYbCswdlgwVFVvVmpZL2lQYk5hWEc0?=
 =?utf-8?B?N1BxQUo3aUtoT1VlOXdjNHBweHh2MS9kUlZING5ieXNDU1ovRWszajJVZEd1?=
 =?utf-8?B?ZW5WZ3lrV21zVTgrU042a1ltQk5QYWRTRlBDMHBHR0pMZEszRXU4MDRUM0U2?=
 =?utf-8?B?TzVITkp4K2w5Nkl4VFdLTlpKNEJIVUZtUU1kWHR3MzNWY2g4QkQ2UCsvS0V2?=
 =?utf-8?B?ZmFvOWhXaFRFTEtNa3gyNE84QkxiT1BVd2pCTWRCV2JnalZ0OXhqT2FnKzVB?=
 =?utf-8?B?WTAwQ2QvUW1OQ2xNQkNjckM4ZVE1ZHRwcHNzM0huSXF5V0FBbzViSm0zdmF5?=
 =?utf-8?Q?kFu+OYb32nU=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?S1dLRENsL3I0YTBMbFB6STVmS2kzSlNkRmlTbHo0VC9zeTExc2V2TC9UdjZE?=
 =?utf-8?B?Q3V5MVBMZjhTbVNxUzZmK3p4bjQ4UEpYU2NvekNlSFZ6ZDVXM2gxck1USVhD?=
 =?utf-8?B?TkNlVVgzTkFWaXBTa0hsc01Na2dNRExLdllzUFhEVEkvZmZlZVRyWnZTOWtX?=
 =?utf-8?B?ZVZua3o3RWx4VUFxZ1lYV1EyT0Jkbm52S0xCeSsrVURxeFpwZ25BS1BMUmZv?=
 =?utf-8?B?QTFKZUgwdk1JcWdMc3ZvZ1V3d3FVQU00dlNvYzhRaDZpb2RsWkpUOHRNVThp?=
 =?utf-8?B?aW1QaWowUy9sZU1tZWRaTmg0ZmdRUXRKcU11RXZYWGQ4dGt1VytsNiswQ2t1?=
 =?utf-8?B?YlZpVlFZbWZYRUMwWnZ2eENFZGozVW4xREsxM25jYTFQYllJUWxWS0dEeWhR?=
 =?utf-8?B?S3VjMm1nWUVxYThoa3g5Zy9IWDYyenlTbXN2d1VHUDBnQnpBNForRkVjUmxv?=
 =?utf-8?B?dWZwc1BNZUxkaFZDcHU3dUprZXduYXJXNDBhdEE3MDdISzlJVk5rSWZOMTRs?=
 =?utf-8?B?UVlKUDl5QUJrbkFOeHE0d1hCZTVtYWhSbFNKQWJJcWpSY1NnbWRrVHJzdUN4?=
 =?utf-8?B?VUxkZmg1d1V2RkdGU0h5M091dkU1R1NXVFZIOWw0TU5ZNjFXRWRON1Rlc24y?=
 =?utf-8?B?Lzc4MWwycC8veDR1dkNzOXk1UWlVcG9sZVhPZi9waVJrcHU1ZXRnZG9jQnJZ?=
 =?utf-8?B?K0FXbk5IeXJVeTJNbFovZ3FBcXpRTzNWMmpGUVVsbC90VjFkM25HeXRCckRm?=
 =?utf-8?B?WjhiQXFDSUpCUjl6dWQxWTJDMm9VbXB0VkVBMEpHdzlodjlsKzAvdlplQ0Za?=
 =?utf-8?B?UmxVYVRYMjVvSktzNVhkY25JdWFzQVZhNnlScE5VTHpHUk9scW5sclZabG9r?=
 =?utf-8?B?TVpZQ3lkbS9SRE1GUWdtYWhVYWZXWnh0K3lScFBhd0lpVDN3bmtpNEhSSm56?=
 =?utf-8?B?M0ZaRjNYOXo1VVRPWEtUUTdHQ1p4V21EL3VFb3h1aHlMRUJTbEJwb2JBUGNk?=
 =?utf-8?B?UXc0TUlvNi9QdFRoajBpNkVGZUFLK2NPaEprbVB4bVQ2Z2F5TnpSSWMyRURt?=
 =?utf-8?B?VGdYdURKVjFUdWpMVHZNOHQyWDFvMDEwQTU5YktaYm5TclkwZWhxS1hmWjdy?=
 =?utf-8?B?Rjk5a3lHTFh0SEJQNkVDWVNlTFRKWmpROHpraWxzNE92WEJncUdZajA3bERq?=
 =?utf-8?B?V09nT29RVXlxVWdieVQ4ZFMyNHZFTkQrWndNSy9LelA0QmFRQjJPbWs0SVh4?=
 =?utf-8?B?OHY1TVh6RzU0L0ZoWTRaRG9DaUwyMUJYaCtyZUc2VnJEckdiRVI3YmlrVVc3?=
 =?utf-8?B?MVkrcHB2SThjZGNQU0xIbjVQZ0o3VFhidGhFWWxWM1NDclNXdFBZbSsvV25U?=
 =?utf-8?B?YUpDVG5QZmR6TzRzaDNaVCtsQm14RGlMWTQyeE5oSnRGWCt1V0M3cFFmWnV2?=
 =?utf-8?B?ZmtTQUJDb1g2cXNUUFRvNnJDdVVhckp5Wm1NS0M1bDNuT3JaYy9VMUozMDB2?=
 =?utf-8?B?RXdIVTc0b01USDV1c01EQUNJdTRSTXZkc0pzamJoQnlyaTVzekZBRDhYcS81?=
 =?utf-8?B?N042ZFhUcEJSVVVlOWU1VEFZeE1hY0dJajFjS0pib045alV1SlVtek1Mc1lO?=
 =?utf-8?B?TnNOSlczc2ZxL3Z5VWRvTmJrTUUraHdWZFpURU9JRlp3Z3dmTjJwTU5mYXUy?=
 =?utf-8?B?TzlUMEdPdGZReXlvZ1EzcG1Ob3RCaFhWTjR2N2oxY0dBRXFUZk8vMmplbzE1?=
 =?utf-8?B?Y2RJUUI0bkI0bVVVbytLanN6dU01SXMzcVVPQmN0QklDMVZ5SDF6d2xmN25U?=
 =?utf-8?B?V3Nvcks1M21FeCs4dmpMNTlJTmdadVhyN05pakRxQk91VGp3T1RxeDdhVEJi?=
 =?utf-8?B?RnBaWkxXZzlYcjdrTTF1MjJOVEV3MDdjWEdJNk5NNElaOEp1NEdDK2dXQlVi?=
 =?utf-8?B?SEJIWUxBRVd3V3RJcENwNWZuUEdJamt3ZnFjc0p6RTJ1SVVMTzVIMG9ZV1pO?=
 =?utf-8?B?d0VzVmhMMEV6aG0yMFM0dEVmTTNNeE14ZkFTOUs2ZTl0NUFGK1RBZlZ6VVBN?=
 =?utf-8?B?QU9xZnloS1ZSeE5IdjRvd0lLQnZFeFFQOXViSjhnRHFzdlVrM1pDQ3kyOVZO?=
 =?utf-8?B?MmJHWThRS3NBZHVBMTZ5REtFdUxqaXc0TVRXTUh1MXhxc3dYMitFMDNrdUg0?=
 =?utf-8?B?aUE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <07789722C62FA641B02EFC7C4D2F87E6@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: d6122b15-8f38-4c04-a24e-08ddeeec95e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2025 15:30:05.0636
 (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: Bs4nqpgX4bZGmVSR1FHDgIWeq2qMMVMLDoogzrVqZAFoe76R+u9nGaRDmL23Mrnx6wrVxKG/2wa1atlvIKfmks2xbjinT1ENT/yz/srGGBo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB6850

DQoNCk9uIDA4LzA5LzIwMjUgMTc6MzEsIE9sZWtzaWkgS3Vyb2Noa28gd3JvdGU6DQo+IEhlbGxv
IE9sZWtzaWksDQo+IE9uIDkvOC8yNSA0OjIxIFBNLCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToN
Cj4+IE9uIDA4LzA5LzIwMjUgMTc6MTEsIE9sZWtzaWkgS3Vyb2Noa28gd3JvdGU6DQo+Pj4gSGVs
bG8gZXZlcnlvbmUsDQo+Pj4gQmFzZWQgb24gdGhlIG1lc3NhZ2UgZnJvbSB0aGUgcHJldmlvdXMg
dmVyc2lvbiwgdGhlIE1JU1JBIGlzc3VlcyBoYXZlIGJlZW4gZml4ZWQsDQo+Pj4gYW5kIGFzaWRl
IGZyb20gb25lIHJlbWFpbmluZyBkb2N1bWVudGF0aW9uIHBhdGNoICgiZG9jczogYXJtOiBhZGQg
ZG9jcyBmb3IgU0NNSQ0KPj4+IG92ZXIgU01DIGNhbGxzIGZvcndhcmRpbmcgZHJpdmVyIiksIHRo
ZSBwYXRjaCBzZXJpZXMgYXBwZWFycyB0byBiZSByZWFkeS4NCj4+IEl0IHNlZW1zIHRvIG1lIHRo
YXQgSSBoYXZlIGZpeGVkIGFsbCBjb21tZW50cyBmb3IgdGhlIGRvY3VtZW50YXRpb24NCj4+IHBh
dGNoLiBEaWQgSSBtaXNzIHNvbWV0aGluZz8gV2h5IGRvIHlvdSB0aGluayBpdCdzIG5vdCByZWFk
eSBmb3IgbWVyZ2U/DQo+IEkgZG9uJ3Qgc2VlIGFueSBwcm9wZXIvUmV2aWV3ZWQtYnkvIG9yL0Fj
a2VkLWJ5LyB0YWdzLCBvbmx5L1NpZ25lZC1vZmYtYnkvOg0KPiAgICBTaWduZWQtb2ZmLWJ5OiBH
cnlnb3JpaSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4gICAgU2lnbmVk
LW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXY8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+
DQo+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQpTdGVmYW5vIGFkZGVkIGhpcyBSLUIgaW4gdjY6
DQpodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvYWxwaW5lLkRFQi4yLjIyLjM5NC4y
NTA4MjgxNDM2MDEwLjg3NTdAdWJ1bnR1LWxpbnV4LTIwLTA0LWRlc2t0b3AvDQoNCkhhdmVuJ3Qg
YWRkZWQgdGhpcyBSLUIgdGFnIG1hbnVhbGx5IGJlY2F1c2Ugb2YgdGhlIGZvbGxvd2luZyBjb21t
ZW50IHRvIA0KdGhlIGZpcnN0IHBhdGNoOg0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRl
dmVsL2FscGluZS5ERUIuMi4yMi4zOTQuMjUwODI4MTQzMTE4MC44NzU3QHVidW50dS1saW51eC0y
MC0wNC1kZXNrdG9wLw0KPj4+IEkgYmVsaWV2ZSB3ZSBjYW4gY29uc2lkZXIgaW5jbHVkaW5nIGl0
IGluIDQuMjEuIFdlIHNob3VsZCBoYXZlIHN1ZmZpY2llbnQgdGltZQ0KPj4+IHRvIGFkZHJlc3Mg
YW55IGJ1Z3MgdGhhdCBtYXkgYXJpc2UuDQo+Pj4gQnkgdGhlIHdheSwgaXQgd291bGQgYWxzbyBi
ZSBnb29kIHRvIHByZXBhcmUgYSBDSEFOR0VMT0cgcGF0Y2guDQo+PiBJcyBpdCBnb2luZyB0byBi
ZSBjaGFuZ2VkIGR1cmluZyByZWxlYXNlIHByb2Nlc3Mgb3IgaXQgcmVxdWlyZXMgc2VwYXJhdGUN
Cj4+IHBhdGNoIHRvIGJlIHNlbnQ/DQo+IEknbSBub3QgZW50aXJlbHkgc3VyZSBJIHVuZGVyc3Rh
bmQgdGhlIGZpcnN0IHBhcnQgb2YgdGhlIHNlbnRlbmNlIGNvcnJlY3RseSwNCj4gYnV0IGJvdGgg
b3B0aW9ucyBjb3VsZCB3b3JrIChJSVVDKS4NCj4gSSBjYW4gc2VuZCBhbiB1cGRhdGUgdG8gdGhl
IENIQU5HRUxPRyBhcyBwYXJ0IG9mIHRoZSByZWxlYXNlIHByb2Nlc3MsDQo+IGJ1dCBJJ20gYWxz
byBmaW5lIGlmIHlvdSBwcmVmZXIgdG8gc2VuZCBhIHNlcGFyYXRlIHBhdGNoIG9yIGFwcGx5IGEg
bmV3IHBhdGNoDQo+IHRvIHRoaXMgc2VyaWVzIHVzaW5nIHRoZSBNZXNzYWdlLUlELg0KPg0KPiBQ
bGVhc2UgbGV0IG1lIGtub3cgd2hpY2ggb3B0aW9uIHlvdSBwcmVmZXIuDQo+DQo+IH4gT2xla3Np
aQ0KSSB3b3VsZCBiZSBncmF0ZWZ1bCBpZiB5b3UgY291bGQgaW5jbHVkZSBhbiB1cGRhdGUgdG8g
dGhlDQpDSEFOR0VMT0cgYXMgcGFydCBvZiB0aGUgcmVsZWFzZSBwcm9jZXNzLg0KPj4+IERvZXMg
YW55b25lIGhhdmUgYW55IG9iamVjdGlvbnM/DQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+ICAgIE9s
ZWtzaWkNCj4+PiBPbiA5LzQvMjUgNDoyMSBQTSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+
Pj4+IElucm9kdWNpbmcgVjkgcGF0Y2ggc2VyaWVzICBvbiB0b3Agb2YgdGhlIFhlbiB2ZXJzaW9u
IDQuMjAtcmMyDQo+Pj4+IHdoaWNoIGluY2x1ZGVzIGltcGxlbWVudGF0aW9uIG9mIHRoZSBTQ0kg
U0NNSSBTTUMgc2luZ2xlLWFnZW50IHN1cHBvcnQuDQo+Pj4+DQo+Pj4+IFRoaXMgcGF0Y2ggc2Vy
aWVzIGlzIHRoZSBmaXJzdCBjaHVuayBvZiB0aGUNCj4+Pj4gInhlbi9hcm06IHNjbWk6IGludHJv
ZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCIgd2hpY2ggY2FuDQo+Pj4+IGJl
IGZvdW5kIGF0IFswXQ0KPj4+Pg0KPj4+PiBTQ01JLW11bHRpYWdlbnQgc3VwcG9ydCB3aWxsIGJl
IHByb3ZpZGVkIGFzIHRoZSBmb2xsb3d1cCBwYXRjaCBzZXJpZXMuDQo+Pj4+DQo+Pj4+IFswXWh0
dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzUzMTg0NDg3LmdpdC5vbGVr
c2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCj4+Pj4NCj4+Pj4gUGF0Y2ggMSAieGVuL2FybTogYWRk
IGdlbmVyaWMgU0NJIHN1YnN5c3RlbSINCj4+Pj4gLSByZWJhc2VkIGFuZCByZWZhY3RvcmVkDQo+
Pj4+IC0gaW50cm9kdWNlZCBERVZJQ0VfQVJNX1NDSSBEVCBkZXZpY2UgY2xhc3MgYW5kIHVzZWQg
Zm9yIFNDSSBkcml2ZXJzIHByb2JpbmcNCj4+Pj4gaW5zdGVhZCBvZiBjdXN0b20sDQo+Pj4+ICAg
ICBsaW5rZXIgc2VjdGlvbnMgYmFzZWQgaW1wbGVtZW50YXRpb24uDQo+Pj4+IC0gYWRkZWQgU0NJ
IEFQSSBmb3IgRG9tMCBEVCBoYW5kbGluZywgaW5zdGVhZCBvZiBtYW5pcHVsYXRpbmcgd2l0aCBB
Uk0gYXJjaA0KPj4+PiBkb20wIGNvZGUgZGlyZWN0bHkuDQo+Pj4+IC0gUkZDIGNoYW5nZXMgaW4g
WEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlIE9QIHByb2Nlc3NpbmcNCj4+Pj4gLSBJbnRyb2R1Y2Ug
YXJjaF9oYW5kbGVfcGFzc3Rocm91Z2hfcHJvcCBjYWxsIHRvIGhhbmRsZSBhcm0gc3BlY2lmaWMN
Cj4+Pj4gbm9kZXMNCj4+Pj4NCj4+Pj4gUGF0Y2ggMiAieGVuL2FybTogc2NtaS1zbWM6IHVwZGF0
ZSB0byBiZSB1c2VkIHVuZGVyIHNjaSBzdWJzeXN0ZW0iDQo+Pj4+IC0gdXBkYXRlIGRyaXZlciBp
bnRyb2R1Y2VkIGJ5IGNvbW1pdCAzZTMyMmJlZjhiYzAgKCJ4ZW4vYXJtOiBmaXJtd2FyZTogQWRk
IFNDTUkNCj4+Pj4gb3ZlciBTTUMgY2FsbHMNCj4+Pj4gaGFuZGxpbmcgbGF5ZXIiKSBiZSB1c2Vk
IHVuZGVyIHNjaSBzdWJzeXN0ZW0uDQo+Pj4+IC0gbm8gZnVuY3Rpb25hbCBjaGFuZ2VzIGluIGdl
bmVyYWwNCj4+Pj4NCj4+Pj4gUGF0Y2ggMyAieGVuL2FybTogc2NtaS1zbWM6IHBhc3N0aHJvdWdo
IFNDTUkgU01DIHRvIGd1ZXN0IGRvbWFpbg0KPj4+PiBUaGlzIGlzIG5ldyBjaGFuZ2Ugd2hpY2gg
YWxsb3dzIHBhc3N0aHJvdWdoIFNDTUkgU01DLCBzaW5nbGUgYWdlbnQgaW50ZXJmYWNlIHRvDQo+
Pj4+IGd1ZXN0IGRvbWFpbg0KPj4+PiBjb3ZlciB1c2UgY2FzZSAidGhpbiBEb20wIHdpdGggZ3Vl
c3QgZG9tYWluLCB3aGljaCBzZXJ2ZXMgYXMgRHJpdmVyIGRvbWFpbiIuDQo+Pj4+IFNlZSBwYXRj
aCBjb21taXQgbWVzc2FnZSBmb3IgZnVsbCBkZXNjcmlwdGlvbi4NCj4+Pj4NCj4+Pj4gUGF0Y2gg
NCAtIGRvY3M6IGFybTogYWRkIGRvY3MgZm9yIFNDTUkgb3ZlciBTTUMgY2FsbHMgZm9yd2FyZGlu
Zw0KPj4+PiBkcml2ZXINCj4+Pj4gLSBhZGQgZG9jdW1lbnRhdGlvbiBzZWN0aW9uIGZvciBTaW1w
bGUgQXJtIFNDTUkgb3ZlciBTTUMgY2FsbHMNCj4+Pj4gZm9yd2FyZGluZyBkcml2ZXIuDQo+Pj4+
DQo+Pj4+IENvZGUgY2FuIGJlIGZvdW5kIGF0Og0KPj4+PiBodHRwczovL2dpdGh1Yi5jb20vb2xl
a3NpaW1vaXNpZWlldi94ZW4vdHJlZS9zY21pX3Vwc3RydjUNCj4+Pj4NCj4+Pj4gWzFdIFJGQyB2
MjoNCj4+Pj4gaHR0cDovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVuLWRldmVsL2Nv
dmVyL2NvdmVyLjE2NDQzNDE2MzUuZ2l0Lm9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tLw0KPj4+
PiBbMl0gUkZDIHYzOg0KPj4+PiBodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3Qv
eGVuLWRldmVsL3BhdGNoLzIwMjUwMzExMTExNjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hr
b0BlcGFtLmNvbQ0KPj4+PiBTQ01JIHNwZWM6DQo+Pj4+IGh0dHBzOi8vZGV2ZWxvcGVyLmFybS5j
b20vZG9jdW1lbnRhdGlvbi9kZW4wMDU2L2UvP2xhbmc9ZW4NCj4+Pj4NCj4+Pj4gU0NNSSBiaW5k
aW5nczoNCj4+Pj4gaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJu
ZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9i
aW5kaW5ncy9maXJtd2FyZS9hcm0sc2NtaS55YW1sDQo+Pj4+IGh0dHBzOi8vd2ViLmdpdC5rZXJu
ZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9E
b2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvYWNjZXNzLWNvbnRyb2xsZXJzL2FjY2Vz
cy1jb250cm9sbGVycy55YW1sDQo+Pj4+DQo+Pj4+IFJlZmVyZW5jZSBFTDMgRlc6DQo+Pj4+IFJQ
STU6aHR0cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvYXJtLXRydXN0ZWQtZmlybXdhcmUvY29t
bWl0cy9ycGk1X2Rldi8NCj4+Pj4gUmVuZXNhcyB2NGg6DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNv
bS9HcnlnaXJpaVMvYXJtLXRydXN0ZWQtZmlybXdhcmUvY29tbWl0cy9yY2FyX2dlbjRfdjIuN192
NHgtc2NtaV91cGQvDQo+Pj4+DQo+Pj4+IGJhc2UtY29tbWl0OiBkYmU2MGYyNDRjIChVcGRhdGUg
WGVuIHRvIDQuMjEsIDIwMjUtMDItMjEpDQo+Pj4+DQo+Pj4+IENoYW5nZXMgaW4gdjk6DQo+Pj4+
IC0gY2hhbmdlIGlucHV0IHBhcmFtIG5hbWUgZm9yIHNjaV9oYW5kbGVfY2FsbCBmdW5jdGlvbiB0
byBtYXRjaCBNSVNSQSBydWxlcw0KPj4+PiAtIHVwZGF0ZSBkb211X2R0X3NjaV9wYXJzZSBkZWNs
YXJhdGlvbiB0byBtYXRjaCBNQzNBMi5SOC40IE1JU1JBIHJ1bGUNCj4+Pj4NCj4+Pj4gQ2hhbmdl
cyBpbiB2ODoNCj4+Pj4gLSByZW5lcmVnYXRlZCB7aGVscGVycy90eXBlc30uZ2VuLmdvLCBkcm9w
cGVkIHVubmVlZGVkIHBhcmFtZXRlcnMNCj4+Pj4NCj4+Pj4gQ2hhbmdlcyBpbiB2NzoNCj4+Pj4g
LSBmaXggc2NpX2hhbmRsX2NhbGwgdG8gbWFrZSBjaGFuZ2VzIG1vcmUgcmVhZGFibGUNCj4+Pj4g
LSBmaXggYnVpbGQgZXJyb3Igd2hlbiBET00wTEVTU19CVUlMRCBpcyBkaXNhYmxlZCAocmVtb3Zl
ZA0KPj4+PiAgICBhcmNoX2hhbmRsZV9wYXNzdGhyb3VnaF9wcm9wIGZyb20gdGhlIGhlYWRlcikN
Cj4+Pj4gLSBzb3J0IGhlYWRlcnMgaW4gYWxwaGFiZXRpY2FsIG9yZGVyIGluIHNjaS5oDQo+Pj4+
IC0gc29ydCBoZWFkZXJzIGluIHNjbWktc21jLmMgZmlsZQ0KPj4+PiAtIEZpeCBjb21taXQgZGVz
Y3JpcHRpb24uDQo+Pj4+IC0gTW92ZSBzY21pLXNtYy1wYXNzdGhyb3VnaCBkZWZpbml0aW9uIHRv
IG1hdGNoIGFscGhhYmVyaWNhbCBvcmRlcg0KPj4+PiAtIHJlbW92ZSB1bm5lZWRlZCBpbml0aWFs
aXphdGlvbiB3aXRoIE5VTEwNCj4+Pj4gLSBjaGFuZ2VkIHU2NCB0byB1aW50NjRfdA0KPj4+PiAt
IFNlbmQgd2FybmluZyBpZiBpb21lbSBwZXJtaXQgYWNjZXNzIHdhcyBmYWlsZWQNCj4+Pj4gLSBm
aXhlZCB0eXBvcw0KPj4+Pg0KPj4+PiBDaGFuZ2VzIGluIHY2Og0KPj4+PiAtIHJlYmFzZSBvbiB0
b3Agb2YgdGhlIGxhdGVzdCBtYXN0ZXINCj4+Pj4gLSBmaXggcmV0dXJuIHZhbHVlIG9mIHNjaV9k
dF9maW5hbGl6ZSgpIGNhbGwNCj4+Pj4gLSBhZGQgUi1iIHRhZw0KPj4+PiAtIGFkZGVkIGdlbmVy
YXRlZCBoZWxwZXJzIGFuZCB0eXBlcyBnbyBmaWxlcw0KPj4+PiAtIHJlbmFtZSBjbWRsaW5lIHBh
cmFtZXRlciB0byBzY21pLXNtYy1wYXNzdGhyb3VnaA0KPj4+PiAtIGZpeCBnb3RvIHRhZyBpbiBw
YXJzZV9hcm1fc2NpX2NvbmZpZw0KPj4+PiAtIGFkZCBsaW5rIHRvIHRoZSBzY21pIGJpbmRpbmdz
IHVzZWQgaW4gdGhlIGRvYw0KPj4+PiAtIHJlbW92ZSBtZW50aW9ucyBhYm91dCBIVkMgY2FsbHMg
ZnJvbSBkb2MNCj4+Pj4gLSByZW5hbWUgY21kbGluZSBwYXJhbWV0ZXIgdG8gc2NtaS1zbWMtcGFz
c3Rocm91Z2gNCj4+Pj4NCj4+Pj4gQ2hhbmdlcyBpbiB2NToNCj4+Pj4gLSB1cGRhdGUgTWFpbnRh
aW5lcnMgZmlsZS4gU2V0IHJvbGUgYXMgYSBSZXZpZXdlcg0KPj4+PiAtIHJlYmFzZWQgb24gdGhl
IGxhdGVzdCBtYXN0ZXIgYnJhbmNoDQo+Pj4+IC0gSW50cm9kdWNlIGFyY2hfaGFuZGxlX3Bhc3N0
aHJvdWdoX3Byb3AgY2FsbCB0byBoYW5kbGUgYXJtIHNwZWNpZmljIG5vZGVzDQo+Pj4+IC0gcmVu
YW1lIGRvbTBfc2NtaV9zbWNfcGFzc3Rocm91Z2ggdG8gc2NtaV9zbWNfcGFzc3Rocm91Z2gNCj4+
Pj4gLSByZW5hbWUgZG9tMF9zY21pX3NtY19wYXNzdGhyb3VnaCBpbiBkb2N1bWVudGF0aW9uDQo+
Pj4+DQo+Pj4+IENoYW5nZXMgaW4gdjQ6DQo+Pj4+IC0gZml4IFNQRFgtTGljZW5zZQ0KPj4+PiAt
IHJlbmFtZSBERVZJQ0VfQVJNX1NDSSBEVCBkZXZpY2UgY2xhc3MgdG8gRklSTVdBUkVfREVWSUNF
DQo+Pj4+IC0gbW92ZSBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZpY2UgY29kZSBpbiBzZXBhcmF0ZSBw
YXRjaA0KPj4+PiAtIEFkZCBkb2N1bWVudGF0aW9uIGZvciBTQ0kgU0NNSSBkcml2ZXJzDQo+Pj4+
IC0geGwuY2ZnIGRvYw0KPj4+PiAtIGZpeCBjb21tZW50cyBmcm9tIFN0ZWZhbm8gU3RhYmVsbGlu
aQ0KPj4+PiAtIGZpeCB0b29sc3RhY2sgY29kZSBhcyBzdWdlc3RlZCBieSBBbnRob255IFBFUkFS
RA0KPj4+PiAgICAgLSB1c2UgTUFUQ0hfT1BUSU9OKCkNCj4+Pj4gICAgIC0gbW92ZSBhcm1fc2Np
IHN0cnVjdCBhbmQgY2ZnIHBhcmFtcyBpbiAiYXJjaF9hcm0iDQo+Pj4+IC0gYWRkIFNDTUkgcGFz
c3Rocm91Z2ggZm9yIGRvbTBsZXNzIGNhc2UNCj4+Pj4NCj4+Pj4gR3J5Z29yaWkgU3RyYXNoa28g
KDMpOg0KPj4+PiAgICAgeGVuL2FybTogc2NtaS1zbWM6IHVwZGF0ZSB0byBiZSB1c2VkIHVuZGVy
IHNjaSBzdWJzeXN0ZW0NCj4+Pj4gICAgIHhlbi9hcm06IHNjbWktc21jOiBwYXNzdGhyb3VnaCBT
Q01JIFNNQyB0byBkb21haW4sIHNpbmdsZSBhZ2VudA0KPj4+PiAgICAgZG9jczogYXJtOiBhZGQg
ZG9jcyBmb3IgU0NNSSBvdmVyIFNNQyBjYWxscyBmb3J3YXJkaW5nIGRyaXZlcg0KPj4+Pg0KPj4+
PiBPbGVrc2lpIE1vaXNpZWlldiAoMSk6DQo+Pj4+ICAgICB4ZW4vYXJtOiBhZGQgZ2VuZXJpYyBT
Q0kgc3Vic3lzdGVtDQo+Pj4+DQo+Pj4+ICAgIE1BSU5UQUlORVJTICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgNiArDQo+Pj4+ICAgIC4uLi9hcm0vZmlybXdhcmUvYXJtLXNj
bWkucnN0ICAgICAgICAgICAgICAgICB8IDE4MCArKysrKysrKysrKysrKysrDQo+Pj4+ICAgIGRv
Y3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vaW5kZXgucnN0ICAgICAgICAgICB8ICAgOSArDQo+Pj4+
ICAgIGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9pbmRleC5yc3QgICAgICAgICAgICAgICB8ICAgMSAr
DQo+Pj4+ICAgIGRvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgICB8
ICAzNCArKysNCj4+Pj4gICAgZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCAg
ICAgICAgIHwgIDE1ICsrDQo+Pj4+ICAgIGRvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRv
YyAgICAgICAgICAgICB8ICAgOSArDQo+Pj4+ICAgIHRvb2xzL2dvbGFuZy94ZW5saWdodC9oZWxw
ZXJzLmdlbi5nbyAgICAgICAgICB8ICAzNSArKysNCj4+Pj4gICAgdG9vbHMvZ29sYW5nL3hlbmxp
Z2h0L3R5cGVzLmdlbi5nbyAgICAgICAgICAgIHwgIDExICsNCj4+Pj4gICAgdG9vbHMvaW5jbHVk
ZS9saWJ4bC5oICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA1ICsNCj4+Pj4gICAgdG9vbHMv
bGlicy9saWdodC9saWJ4bF9hcm0uYyAgICAgICAgICAgICAgICAgIHwgIDE0ICsrDQo+Pj4+ICAg
IHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgICB8ICAxMCArDQo+
Pj4+ICAgIHRvb2xzL3hsL3hsX3BhcnNlLmMgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAz
NiArKysrDQo+Pj4+ICAgIHhlbi9hcmNoL2FybS9kZXZpY2UuYyAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgNSArDQo+Pj4+ICAgIHhlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jICAgICAg
ICAgICAgICAgICB8ICA0MCArKysrDQo+Pj4+ICAgIHhlbi9hcmNoL2FybS9kb21haW4uYyAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAxMiArLQ0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZG9tYWlu
X2J1aWxkLmMgICAgICAgICAgICAgICAgICAgfCAgIDggKw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0v
ZmlybXdhcmUvS2NvbmZpZyAgICAgICAgICAgICAgICAgfCAgMjUgKystDQo+Pj4+ICAgIHhlbi9h
cmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZSAgICAgICAgICAgICAgICB8ICAgMSArDQo+Pj4+ICAg
IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyAgICAgICAgICAgICAgICAgICB8IDE1NCArKysr
KysrKysrKysrKw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMuYyAgICAg
ICAgICAgICAgfCAxOTQgKysrKysrKysrKysrKy0tLS0NCj4+Pj4gICAgeGVuL2FyY2gvYXJtL2lu
Y2x1ZGUvYXNtL2RvbWFpbi5oICAgICAgICAgICAgIHwgICA1ICsNCj4+Pj4gICAgeGVuL2FyY2gv
YXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oICAgICAgIHwgMjAwICsrKysrKysrKysrKysr
KysrKw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NtaS1zbWMu
aCAgfCAgNDEgLS0tLQ0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vdnNtYy5jICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfCAgIDQgKy0NCj4+Pj4gICAgeGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20w
bGVzcy1idWlsZC5jICAgICAgIHwgICA0ICsNCj4+Pj4gICAgeGVuL2luY2x1ZGUvYXNtLWdlbmVy
aWMvZGV2aWNlLmggICAgICAgICAgICAgIHwgICAxICsNCj4+Pj4gICAgeGVuL2luY2x1ZGUvcHVi
bGljL2FyY2gtYXJtLmggICAgICAgICAgICAgICAgIHwgICA1ICsNCj4+Pj4gICAgeGVuL2luY2x1
ZGUveGVuL2RvbTBsZXNzLWJ1aWxkLmggICAgICAgICAgICAgIHwgICAzICsNCj4+Pj4gICAgMjkg
ZmlsZXMgY2hhbmdlZCwgOTgyIGluc2VydGlvbnMoKyksIDg1IGRlbGV0aW9ucygtKQ0KPj4+PiAg
ICBjcmVhdGUgbW9kZSAxMDA2NDQgZG9jcy9oeXBlcnZpc29yLWd1aWRlL2FybS9maXJtd2FyZS9h
cm0tc2NtaS5yc3QNCj4+Pj4gICAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRvY3MvaHlwZXJ2aXNvci1n
dWlkZS9hcm0vaW5kZXgucnN0DQo+Pj4+ICAgIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9h
cm0vZmlybXdhcmUvc2NpLmMNCj4+Pj4gICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KPj4+PiAgICBkZWxldGUgbW9kZSAxMDA2NDQg
eGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjbWktc21jLmgNCj4+Pj4NCg==


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 16:57:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 16:57:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115435.1462042 (Exim 4.92)
	(envelope-from )
	id 1uvfB0-0001k5-3b; Mon, 08 Sep 2025 16:57:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115435.1462042; Mon, 08 Sep 2025 16:57: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 1uvfB0-0001jy-0s; Mon, 08 Sep 2025 16:57:10 +0000
Received: by outflank-mailman (input) for mailman id 1115435;
 Mon, 08 Sep 2025 16:57: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 1uvfAy-0001js-La
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 16:57:08 +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 d924340f-8cd4-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 18:57:06 +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 588GtrmC030795;
 Mon, 8 Sep 2025 16:56:13 GMT
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4922x900t3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 08 Sep 2025 16:56:13 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 588GEuwU038737; Mon, 8 Sep 2025 16:56:11 GMT
Received: from mw6pr02cu001.outbound.protection.outlook.com
 (mail-westus2azon11012070.outbound.protection.outlook.com [52.101.48.70])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 490bd8fn0a-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 08 Sep 2025 16:56:11 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by DM6PR10MB4298.namprd10.prod.outlook.com (2603:10b6:5:21f::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Mon, 8 Sep
 2025 16:56:08 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.9094.021; Mon, 8 Sep 2025
 16:56:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d924340f-8cd4-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2025-04-25; bh=hddoNg68YCWE3kyPD3
	LjrA/JuV3JBC1RzVFPhW5prWE=; b=E4O1Tzx2zQMeJB36a6RdC1LcTQuqqJ9rIg
	vlhB4yD5SzHx0dqVgvB/BVJ9hU2FFXp2eRvyhX8xJahRkAI9Exk1lPD7TUkL0087
	B8eKqYFA3Y4tWvuMGjJI9K4INHrgCcuVBceHNi6tMSst9QsUEP8TVVnIRg+ZsGvD
	kdKmnp64MW9uyI024pxz8ZRka1Dp4mfAIdtYHod3S1g79r9P+cv2ZOPNrgdkbg71
	jlDJtNwxYRWulC52yuiIScWOhYODOB8BFCXc7dKNybPvsGFCmE8nvr8DG6m8obtX
	4VOMEZ/WQHMUYyUGkVTuQ68kD8I8RVHPx+rIWQpAZd4Y61P0WHQg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XlOiHnG53DYXYPjs4XZFIlBaJNrxCIoo2KpgP85/oGZ6wC9+q2gxovJTXS3PZeH/UIwkd5SDyoff0KaagX0qQNkEcSeG4h3Md7UAqFxFoaGAK4WINx9MoTQWoMmBb7nH5KU3uZ78OfJNlSyJF09sRl+XDZ9G/4etvto2jk6jvRZ3JnTggjn7HL6nO6onMGpPuhWk4i6CT9KDQHkLhAmTZXhuG++C3jPZ0ALiduj7Ktwcnxf2iMww/Lkujla8qaFE9yCzhZESs+Gk5hiyJIrGr53CZdt57eWipC6UQVlnjMoPiuaakTL5JXU9pBy86PO25ZJzWLqZk/g/vk8tttrpBQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hddoNg68YCWE3kyPD3LjrA/JuV3JBC1RzVFPhW5prWE=;
 b=LJEPZEX1XC/m7jncDboCIyHVwoNTEdD7/6ZossyXLKZo2NqNoT1wllB/qGpLqW2j3q/r83Eg9Dr24ljooTWGHMIrwGLS0uwiCY1Tzzk+nyk2y1In1XbZK0Lb9s+NcmpoZV/zlC3mm9UFXhYJdsafHzrfI/EHIDm06itazyy+17WJHKt/EbJplsnSZ1YfHxX41nZXAzILYvT3fuoV/yCPTdqaot/CLikAd0o4SSMWNhjBC4UKR3IrJzfX0oDnwpVkB1xQwl+aPnLNHf8/IGRNvKj32x7EIRdU28jAibb1ebxuiUCmwRl58jebt/cZPyXCQgDx4fF4KRbn57KCjt9dLw==
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=hddoNg68YCWE3kyPD3LjrA/JuV3JBC1RzVFPhW5prWE=;
 b=NNMvgjq0Rk3fyx1FVku0zkiPAhALGXQhYOEDt42jTqKKsxflmPSy9eS0SI0i3JRQs5NHWRVDroWstswbc13rem3kHfeoSJp+j9wA09ISc6PVZYMYsBUfneSpLLWpkIRuNShdieMJPnhDu+fJIzrWFxiCD0qCLOVzY41ryioOS2U=
Date: Mon, 8 Sep 2025 17:56:05 +0100
From: Lorenzo Stoakes 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Alexander Gordeev ,
        Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        David Hildenbrand ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
X-ClientProxiedBy: LO2P123CA0047.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::35)
 To DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|DM6PR10MB4298:EE_
X-MS-Office365-Filtering-Correlation-Id: c91ef47f-a0b1-4b9b-260d-08ddeef89b59
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Uw5gE/UWfacTBzmIU3Kab+tYqNRz/UMcDB4h1gJDKyQmw0AB0TdT71XInStR?=
 =?us-ascii?Q?qCQ5wfETPal0qkecWZHkqjI/5SZT0hcLbGwsar1PLJrHo1WdyLa/SX08MKRz?=
 =?us-ascii?Q?YSMIa+Ou0bH82CdpQj4QUG35EOWTpsk0c+jlMEDVGpjdlV4P2Zkd+tFK6wwj?=
 =?us-ascii?Q?x4ZJp7epLw+UHpTE5Ts+iafHnd/ngjf90ZeTpx2788B7a63h7vqdYH3bvYZr?=
 =?us-ascii?Q?C2OzT113M3YjxIrQRCLINs97BjyYc5KlDXTrr+uY0U/DZ4LA16sdBOYHK2yq?=
 =?us-ascii?Q?iVnCHY4fj26fzUGldqTy6ie3aBDo7wjyvx/VWmtGPcWbQVsj+x4W6p/0kIUm?=
 =?us-ascii?Q?n5T7LKZ4Hj+/PH2t7q0sPcIug75XUI5iOqTzOf21i9CGikLCZG/z1SzM3psP?=
 =?us-ascii?Q?hu4cAJuhowAtNVAYaIHuZH4GBPgxABuUS9p+nwODJld5BXCuF7Weyor9ccv2?=
 =?us-ascii?Q?hbQXcjoFaRICOJASfmHrlkqHbNm4AwUx/KUu6JgCg50Pw7MDU0eu/7DlsqNe?=
 =?us-ascii?Q?bS0cUIV4VgR0dnAN7PMuNOTPcB5DDuVTxW4Ed0+tBJlcjNle+X44e2m1ubxe?=
 =?us-ascii?Q?9hA40YQH3sTXC4NczvhxSnrbKzZKNa4m1NLR8tGDmjCGouazj4OgdJAt85ou?=
 =?us-ascii?Q?5WWuryIuA+ir1N7iPWGt0Z5INSumZUkNP7TjWn311UcW4hOln2hvZo4f8bfC?=
 =?us-ascii?Q?g3rBaUY4hnuXG3rCf54AeqKegIGs4lpd3Sj0aMML2qrncLpxgtH1rV1XnwaG?=
 =?us-ascii?Q?l5ig+Kntm2zc8GsDs/rmCGobWkkvYsqNN1iRwg01DtJzMUZLvaBTb872Q2Ps?=
 =?us-ascii?Q?BQRAPX3Yd3fWiKiab83loXdKxQXTh4p9f3JMbLVaZogJJ26N5sZg4t2ZRGpL?=
 =?us-ascii?Q?5ytLSez7wpRQKqQsSAoEtNEpVlzlDGAoHfuEointddwtbTIrz1WTDIZOGJL9?=
 =?us-ascii?Q?OURY/+h5IexQSkKIs4j6pZZDdTJ3nL6lNHBC0za75UEZvwjM3uSUJPzHJsI5?=
 =?us-ascii?Q?4pjdCdibH+hdu+2Lg90N6hmxbS/Pm1+CKKOdrrQEipDHYZQRQX+m3bGhykaD?=
 =?us-ascii?Q?YMQzCM7uhS1Y/9pbUJ/oE098R76Hd34Yjv1QIcnQbJD+lDirhQ3j1shXRoMP?=
 =?us-ascii?Q?21z3vVGnGs75NrAlONrJnCSXwVh3e5t6I2b+AmDSbw+6mE4ulNcTNKyDZdSd?=
 =?us-ascii?Q?4HIIJGZaKOLMnhwLg4rqwZpOx0FTYPZTbAfUraDVVuyQWF4F0YE/YNWXkoUC?=
 =?us-ascii?Q?7a8UCCGeo+FrqTZuCnWRVC6z9iZQwLdcqDlKAY5yludMWW4/Zb3VkFQLVASb?=
 =?us-ascii?Q?m/fg2I7DS1nNVfO8u0Cd+Dfc7iMlMpQMvAiQs8ZvUJx0toaY0wNdZ6BcrODL?=
 =?us-ascii?Q?fv5O4GLHu88GQ4uuoWO3923jGfIjqyUYhGG4FiGWgYaD9EwtaX02LUlieNOu?=
 =?us-ascii?Q?YXQw4F4HtIA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?b+0XZJpy/tRTqr/EckM/RsWTmBZHEynf2LnspsiqMlPSlVkSNYXEMY2eMt5x?=
 =?us-ascii?Q?Wb3Lic9dxnQGzcgtZ57is/wp4mLIJdwOdWNOWvyQ9eSdInMN+50UkLW1+LA5?=
 =?us-ascii?Q?knllEjAidx2lekUAZHocNrn51qRHqQd2fipCOZuUtUcu9dCm1y6YUb692Elt?=
 =?us-ascii?Q?9yb6F3JOp3CC4mWLPEYxC1xlh13H45X4dIZX7Gil3kuhHVYC0Lugl4I6poLu?=
 =?us-ascii?Q?zReVFSLe/FLvPhDIfJI2J8K+oNL+sLwS23hyrds431V7Cs1i5CwgwlQzIgc1?=
 =?us-ascii?Q?1WqEEpFVoT/kSl0DN0jWK26/bt6IWYE9oP4Ihm8bjOxRZl/exKxOBKeq2VML?=
 =?us-ascii?Q?hIWPdlKaqfOd/ItmFFrnpulmxb0jgIiys0vKlYeebdT6p03EuI8d9ftl8fh4?=
 =?us-ascii?Q?NPEzCdJoLxC2r6DvIuZLoQAtg+MhDt5uaGqrbNqIaV1M/Sgr8ssb6nVGby0D?=
 =?us-ascii?Q?Gd+5TS4NITomZlvjILOhGLGRZsZKgXRzHSzk+ltBMoBynydAWdi1Yh7iMiRA?=
 =?us-ascii?Q?qoFw4DKw3hB2GWeTbbCE6n1+XauyKI/fm6jhm100dZI7ETajLakjTIUwdXXi?=
 =?us-ascii?Q?NB/X86W05UaEP11+AXH7vp7+Ry3cxhMrbgCNK9/gkKni35MbZJq2xQbo+e1u?=
 =?us-ascii?Q?sU6lR1rJ0k7yyTwY7ELgxDwkEBdEpX17mE//y8Fa4y36XGepzlup3UTEBjW6?=
 =?us-ascii?Q?qqo6qXw5FJO+3+LgzMHo6rZE1h922YCy3aXi2R9nV/Y+midNC8tV6fMP3b4q?=
 =?us-ascii?Q?GDN4XvURmqZLvGqzz7o04x6LTqcdpKDlMc5KexKVRxmA03jRpv7oq4KsTxHR?=
 =?us-ascii?Q?GMrle6H8fcSYOCpCJAh1NDvjaL8hKPg+fpzFTGHb2IYiPPgtDJg3IAIqDJds?=
 =?us-ascii?Q?2K8E5sjmCRjiWWqbxZxLcZw9JKNM76AmziCqpjyMnqIIwQqv4Z6uIOb6u0rT?=
 =?us-ascii?Q?KIt4uYzwIEYYuHsOIOO8QYFhKlcI3GfJ8y+vqxVhdLrxx7zHBef8/ZcjRAoR?=
 =?us-ascii?Q?nenuqhyQ9W3Yrf5Q9FTMfZ0dP1qmq9mZRaLiNQUyHs0/SGCQ75G3Pz80UNbl?=
 =?us-ascii?Q?3AwOFDAOtFugKUYOQUuEGoGWVXmX0sLOQ4ZmBDfOhYGJSotWguZU2tkXnYWm?=
 =?us-ascii?Q?5v9l3qjRf6w3Ue6cHY64VH2jYZR1i89Q/YvtPPLKnGmVudRhXmRBY1vF9s+p?=
 =?us-ascii?Q?uresRVlJ963SXRFWBUpi5e5y6POFByPsHpGvl3LwwK9liLK4eAWtt+Dxm07F?=
 =?us-ascii?Q?//aypZBiwABymweqdKRrDfXKFTbosQCoe13nZ7nfstbKRmYWHxQsqXCnDz+R?=
 =?us-ascii?Q?kp6Gk4RgQ2I5KTUO5gi9MSn7Sk9fDMwOnDxlg+0IPjGwc/Ttyh8Nsbu1piVD?=
 =?us-ascii?Q?TAlcBnOe3xjw/ot8GE2uKFklVguJ3zJczoGh/caGiDKEYxuFBFJeTwzu/9/K?=
 =?us-ascii?Q?Zd4TYBKy0I6YCL79cexP4CIWuaBvp7QuTs2h4kjwXjUEEA+rhOVbVhoxFo/M?=
 =?us-ascii?Q?v2JIVfG3UKhZIulSrIX9uqXRResrq+gkLMSBS57h4CY5zmWltj+s3y+0qmuS?=
 =?us-ascii?Q?SOnspik3wNvsrQZuNIhxbbL/B35qGKewdXsHOW5ijZeC1pz0iu+Txfv1o4ma?=
 =?us-ascii?Q?FA=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	UR4mv6xbIgnXDbxUKR1cqkGCF9s05k+wwmTHIrIFO5CKUFcv77M94vqYbNzlgAzhNKKxN7fIuxyW8blF2IwtWOp7+OiWcsvcVR4Jjsi5Urx3Egf4CSOLZGsm94SPJ3OqkxHnbL97cccyRWbKM+VitYIit+R0XD8E4c/w1EYMkfWiR6oq40fX7BOAImwwoRf0STGe64txPPo/sjnbN/9DS0vF0ZNTciJYT/KtqZQWNBYl26Kb5qj7C5lVwjLC1aWv9miyzwDSPZWYnKsO1UfEq/V5bnkRN8eBdnw9gVIeweRHQFpoVAlPjwNVbII1YfT6DHXifh9mCEpYaT8qNZyPcZla5MuNdMpQssD1Kq4+nA9HCP9uONXLtHjGDJR+UE/8kxc8c3hU5AKoXN3pm3atEy98RotwePffbLFVhd1BVKehQQjfbs0CdFcHfAx4C94lmnCLZTccY7uM0F47FCY8gKY2uoEPhkx0cTFr6m6GfzncnOXIUAMInvxeZj53IuG1lrvY3f8mPxhD0iIPiRq42xm9q3aaN63LFKZH9Iqjsxy+T04+V25sqD/1eJv8uP7mQ+LPk88/iTBiU+EWlhMHqVFsaeRqk37UK4h7hbbIoiY=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c91ef47f-a0b1-4b9b-260d-08ddeef89b59
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 16:56:08.2835
 (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: 3QqS1aWvcaNPuIzqj1Yo/pzXTYiiEiVwAawKlvv3/bbWiK+1Ki/2zFIy89Yuxtcuy/Rzw+iQOTC0rn+K38XYja991P0ETzdn/i89m1Y59/E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4298
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-08_06,2025-09-08_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0
 mlxlogscore=591 adultscore=0 spamscore=0 phishscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2508110000
 definitions=main-2509080168
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA4MDE2NiBTYWx0ZWRfXyaW/OwKuwQSl
 9BDOTG9eq7bCeECLT5T94THvm3HZRn0vc3/GM+elgpQU5gwb/T5q/DxC8EXbqB6v5xeDMRZRVof
 ZsvJqwfftNUQ5wDVlTGF/O5Qg65Cd3CmetGzHut65epSpMwT0cD/Bfrz1T9SnvUepy4sQfkG8Us
 iMKHRC6f+eUg55QXRBzpjGOAPZyMQGwqvQ1yezohayyCqzWyq8sQH9j9nVh+2SxnQZvHiJB9WD1
 GAnq8Qryj9kL2sZv2mYc+qDCNVvk/uT1gXnfW4Sf5MzxAelWOqjM3iUw/IyebuXkACLrtgpPRQS
 ERA+tTeGJ+CdDIP5wlIsx9lqS5FOkc/9ZH9x/qKGV1G2aZpATR0eUNytAL8tMBQYqabuhKuKhOF
 ApKFIIFBF9tBBqmfH0Z8L/ck3egP5w==
X-Proofpoint-GUID: mOOjE0NbEMAQs1zzcMm6ACvYQS3XCFFR
X-Proofpoint-ORIG-GUID: mOOjE0NbEMAQs1zzcMm6ACvYQS3XCFFR
X-Authority-Analysis: v=2.4 cv=LYY86ifi c=1 sm=1 tr=0 ts=68bf0aad b=1 cx=c_pps
 a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10
 a=yJojWOMRYYMA:10 a=GoEa3M9JfhUA:10 a=XiB1ofsnmaN9j6wyxJcA:9
 a=CjuIK1q_8ugA:10 cc=ntf awl=host:12068


On Mon, Sep 08, 2025 at 08:39:24AM +0100, Kevin Brodsky wrote:
> When the lazy MMU mode was introduced eons ago, it wasn't made clear
> whether such a sequence was legal:
>
> 	arch_enter_lazy_mmu_mode()
> 	...
> 		arch_enter_lazy_mmu_mode()
> 		...
> 		arch_leave_lazy_mmu_mode()
> 	...
> 	arch_leave_lazy_mmu_mode()
>
> It seems fair to say that nested calls to
> arch_{enter,leave}_lazy_mmu_mode() were not expected, and most
> architectures never explicitly supported it.


This is compiling with CONFIG_USERFAULTFD at all commits and series is
compiling with allmodconfig plus all mm selftests are passing so from my
side this looks good, thanks for addressing issues and rebasing! :)

Cheers, Lorenzo


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 20:07:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 20:07:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115506.1462063 (Exim 4.92)
	(envelope-from )
	id 1uvi8W-0007Na-BG; Mon, 08 Sep 2025 20:06:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115506.1462063; Mon, 08 Sep 2025 20: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 1uvi8W-0007NT-8Y; Mon, 08 Sep 2025 20:06:48 +0000
Received: by outflank-mailman (input) for mailman id 1115506;
 Mon, 08 Sep 2025 20:06:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvi8V-0007NL-9Z
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 20:06:47 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2009::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 571dce00-8cef-11f0-9d13-b5c5bf9af7f9;
 Mon, 08 Sep 2025 22:06:44 +0200 (CEST)
Received: from CH2PR12MB4022.namprd12.prod.outlook.com (2603:10b6:610:22::13)
 by CY8PR12MB7684.namprd12.prod.outlook.com (2603:10b6:930:87::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Mon, 8 Sep
 2025 20:06:41 +0000
Received: from CH2PR12MB4022.namprd12.prod.outlook.com
 ([fe80::2f2b:54c8:a3e2:bf72]) by CH2PR12MB4022.namprd12.prod.outlook.com
 ([fe80::2f2b:54c8:a3e2:bf72%4]) with mapi id 15.20.9094.021; Mon, 8 Sep 2025
 20:06: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: 571dce00-8cef-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GrurOpLctZ6fAFy9jnrkkiT0yPm9pS2ce5GZeyi/MAAVo1H+jxU9OeqVmm01iZzZh2lcUWLrpm7G4wVjmvtvZ2im2FLCzD2/fL4grAyfiyi7aEmUh+ZgmfIKyO3DJ8EbFAA96IIFyppAs1Ab5OEo2A0vaPnqRoge1lqVwpLPkTtyGtowGd0i8aEyUHH+vvC1vnRnZMuDcFgcPQT/CC/7CXtjca314koicYOxSe9pU3/o+dZVYpB96wgK7ny6Hj7Al0cMJGcr4WED+vIKlObr2lzWbCrcG+mz35kKG9e1HKgxq/0NJxJnSb0d1h4J6cRb/PqZoX0gom+QIze66KxCxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=m98ee3vJ1r7l9MHJtQV/bgza4sKMbM4tmf/7OOM8wvI=;
 b=X5kjlXUYNLlpIj2BjN1c17fAv1FslerAxENx9KTF+LH+cqLqQWS14cQPEskKVL8QER68mwfoUa9B9j3OjCFP/2vAtvLfEXieX0Xo/pffEGFwiajiFXChkupZmLF0LsZdmUn1bl+kQ6L5be56Y2ClhfmwdteTmd++jAvrZSbuYMzQ8Rd1/MzHPad86IZnvF9bpulrQIYnKpEAibkZYB59WaNGQQKpr0TPytBsa8oK3Y1N2sPN9GNgHKgLA0RI3jvRrtO5gr8bwroyl5ojJem9uKix/yskuFowI5BJLacocoqRSvLCea0tBFXnaN+ck9h6OZhAFd1F/15lEW5c7KafDA==
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=m98ee3vJ1r7l9MHJtQV/bgza4sKMbM4tmf/7OOM8wvI=;
 b=UE2hi7f20LYznRh9f8b1+bzmJ6+uBOp6hWEsN5PPOk/fRGi16z2cO0fin9Xxt8jgJrhP36PGZloi1fuoiDt6g+0KQ2CFneuMztV9genqgpV+ilc/++ANsM4Lgaejn93n9ZLdOE1DXByxsMBeRtTCPxpU9QPL12dPaRvkIbPIOEE=
From: "Dandapat, Soham" 
To: "Andryuk, Jason" , Jan Beulich 
CC: Andrew Cooper ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH] x86/mcheck: allow varying bank counts per CPU
Thread-Topic: [PATCH] x86/mcheck: allow varying bank counts per CPU
Thread-Index: AQHcHoXdH9CZOm3Bdk+HDpewzgmH0bSE0JqAgAQyqwCAAEu9gIAAaWVg
Date: Mon, 8 Sep 2025 20:06:40 +0000
Message-ID:
 
References: <20250905165212.96843-1-Soham.Dandapat@amd.com>
 <32f89ab8-9742-4bc8-a5ef-848b66e788b2@amd.com>
 <89d0b668-537b-4ee4-8cda-e0d95d9eed90@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-09-08T20:04:27.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: CH2PR12MB4022:EE_|CY8PR12MB7684:EE_
x-ms-office365-filtering-correlation-id: f735a736-2e57-4f5a-df16-08ddef133992
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?a1V1bHZLTGVQRHJIRmlGYmQ3SmJLY2dyZW5pZ0ZuaG9VUTNXSUpKZ3RXaUE0?=
 =?utf-8?B?azVHSkVwTHZjQXkrRFJvbDFZZThVb2NHUzFMZDZiU2pFb3E2d0hYdDNUckp1?=
 =?utf-8?B?ZHBkZGlRanBHTTh1OFhEUVZaSGgwdmF4OHdXdmxZcWNaY3lmRXZIZEN5ajMz?=
 =?utf-8?B?L3UyaFFIdmRDa0Y0WGpWdjRFbWh5SEJqc3VQUjRBZ09KUlhvSVRDT1RJOENK?=
 =?utf-8?B?MjVmekVRL205YTEySEhyUjJOM3REYzhOSkpmSE1LVlNjdUcxUk1VUnlYYlIw?=
 =?utf-8?B?VU5YeUVGWkNtd0F5U1pEd0QzaERkWDJXUmZFVVRrMWkvS3h0NnBOQkw3OTN5?=
 =?utf-8?B?VTFtZkJZczA2eDgzQkRMUVlGZ3kyR1Q3czc2SDgvaEFpWkdwU2tMVVZyZDQv?=
 =?utf-8?B?N0phUU91NWc5TWpReExMaDZhNm94TWIrOVFHNFhxL01kdUxxaC8rcGdDYlFu?=
 =?utf-8?B?T1J3TEYyN2IrOE05R1Y3MThvT2dmUkUxUE1nYTg2c2E1eWVzcS9JVzMvaHZ6?=
 =?utf-8?B?SjRpM2c1ZGVTTllGZzEvYWJ3ck5OQy9mL0NlbkFkS1RuNEVmUnlqMUtDVmRs?=
 =?utf-8?B?MnNQM3FJSUxDZEpFenE0TEc0ZG9BOXVBMFU1NFdMbTJhTXdvUXc1dW9yOUY5?=
 =?utf-8?B?cTZxaWxIWExxdy9YVTIzOWsxZFpvRDd3eUVJbFJkcURnZmVyTDV0Y2FOa1pj?=
 =?utf-8?B?bHp5U1VSMEc4bnhidW50Q1BGTG14WU5peHJpN1ExNzNMNldJQ2JTY0VZcDdh?=
 =?utf-8?B?SzlKeWh3WklXVVdUNmRHVHBGS2szQ1hWcHpDdDVWMnNXdWk3YUt6STJNZG8y?=
 =?utf-8?B?bmUrdlVrZUI3eUp4bC85TFBpajJOTHFKOHVhN3NBZDB4c1JQcHljNEhUeFJh?=
 =?utf-8?B?a1IrU2QzN1gwb2YrY0d4d2ovSDNOYUMrZFlDZjJWT21EREdNTzB2RmZ0Y01K?=
 =?utf-8?B?N1RSazB5TVpYTjFQWlNmWWhqWGFRSzB0YnNTMmdZbHMvZWNmMjF4dktOZU8z?=
 =?utf-8?B?ek1aRE5IaHBDYStOUmphemxMbElmN0JISHZZZ0lGNEVSNFFxdEYvR2x0c2FP?=
 =?utf-8?B?YTZ4Z0tVYkNqMlg0Q0k3TEZFdW93eW1XVmZPcFo2ay9CK3hoRnNscU5HOWov?=
 =?utf-8?B?T1J4V0hSaXdYUmtKTm4vOWpCMWJwKzlVRXJ3RjFiOG1IcDBUay9hZTZyM24x?=
 =?utf-8?B?NnZ4SC9hUzBqYnc1bVg5czJMaldxdCtYN2pqVzUveDNTd3VhbzdDbTErcG9B?=
 =?utf-8?B?dzdOQ0FtN0h1NjdUb0txTXQ0MkU2NkVjYnArc0pxV05JMmVTSTdVeUpWVnFs?=
 =?utf-8?B?dldaV0o1LzhQTENSZ3hUNE9iR2lMT0l4REM0QldrYjJuaDhFQjVhbndvVGtj?=
 =?utf-8?B?SUx4a2JkRmhaVldRejZ0SkZ2alFiM1dWeS9xbHRmK3ZQVXQ1TS8waUJ0a3Ay?=
 =?utf-8?B?R1BmNzkvVkRqY3Z1YU9MT05QTWFKVVdNMzVWUUVmV0k4K1R5cjN6cFp1WHgx?=
 =?utf-8?B?cVIrZ0hvNXJWWHBoanZKSFA3bERFRWovODlmdEdvUzB4VGd4WU5TdlRmUU44?=
 =?utf-8?B?L3FRNjZzdHAwVHVVdmNDMmZ1cUsvdTZwT0hyMFhPZFN5eFV6N01ZL200M3Jv?=
 =?utf-8?B?VUdKMVFYMjVrc1o2Z29ZOUhZRDErQTRmQjhXeUNFdXVhMmkwb3pKYTZWVHBI?=
 =?utf-8?B?TFF0b1h4alRPZEx0b2dSQU5UZWhES2tLbnQ1aEtXbFFoRGMzVUhHZFdHK1pz?=
 =?utf-8?B?R0hVY2RVS012b2VFVlNNRFlTL3pqN0FSM2tBYXc0U29EMnNaMy9LNmR5Mkhu?=
 =?utf-8?B?a1kvQ3RlNVBFVDN4WG4vaThkSGttTUxqckpnWEpJZGNmS1RrR25nU2xiWTlM?=
 =?utf-8?B?aTJGVlBXc2NGeGgrWW14ZlNvc3kvN3RVUy9FU0FlR09yNUo4aTI4SGJSc1BE?=
 =?utf-8?B?SncyUjlETS9sVFUzbEE1dmhJd1J5ZDFXZjlSWjdtcXhrU04zZGluWFRGZzJz?=
 =?utf-8?B?TDMzWk9pSS9BPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR12MB4022.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?TTF2WUdXS2hmYStHczNXSHFxdk1jLzZlTWhqRUQ0L0JSQVBMbmxQeFhlZ2Nz?=
 =?utf-8?B?K2haVGR1U1VyZUVyMTM5Y01xOGViOFd5RXBoSHBCdFFPSEFYV21PaVlRdWE1?=
 =?utf-8?B?RDJUd1pKbkxhOWtzWHVYbzNMYnZzVU9ETzJtbGh5S1R2TmprTFdtVmZLUXdK?=
 =?utf-8?B?M1paa0QzSzMzNXZLVnFScVBrQnljWFR3RTQ1cDJSOVRtdjNEc2hUNzk5Q2tB?=
 =?utf-8?B?TUlKdG83bWp5bDkwMlFTQ2c3M0VrK0hweGJ3U2tDcVVudWNEYmtKVG1LdVM5?=
 =?utf-8?B?TFJvV1JBQWYrMDVMOEVJWkFhWGdQVDBFYjVOVWtyRVZ3eEs5MVhORFBtakRD?=
 =?utf-8?B?TlY3ckhkZ0pycTJRVW1RV3dYcHJuVkZ1a0Q4SUxxbXFBcE9OOEg5N0hEdis0?=
 =?utf-8?B?SCtRNUlaZk8wMUNVTTJ2dC9TT3MyVk1Wa2lFWVBsc3ZRN0M4cWt6QVpKc0Mw?=
 =?utf-8?B?a0Rmc1BJS0Fyb1ZzQUU5blM3UlFBMzY3VGsvMTVHMElobDIvQXFjbmN1TERh?=
 =?utf-8?B?Q0xheGd0K09yMU1sYm50WHoxODZBTENxMVZkZEtBTlFTdU85NFQ3eHg1N0tt?=
 =?utf-8?B?UzFLZk9Nd0JPZkttNmdlVk85NWswTUlQSW1yYXY4eHZvWnoxTmZWY0lWRzl5?=
 =?utf-8?B?SzVUSWFiaVBRQmhhMCttWEJBRENUNzdPY0FaVEVWY2dSQmtTbk1CZ2dXVngy?=
 =?utf-8?B?VWtxZVVSM0hreDd6aWtEamxZQUFTZVNSSDJpeWEvclQ2REw1TXlkbUtWSjFh?=
 =?utf-8?B?OTZFaFV4VXB5SWNhRXFEd1BRWEhWbGZnV1hPL3RNN1NlMFVaQk5heTB6am10?=
 =?utf-8?B?Vkk4VE9FK2hwRjhYQ1ZSL3drUDRHM2phYnRTYS9SRlBkdDQ0UkFCWUswSkFT?=
 =?utf-8?B?VkNDMzMycEc4L2xna3RJcENHbGhROXpSc21kckYrUHhpTjNPaVY4NkJiSWNt?=
 =?utf-8?B?OFFsMUxDbjIrSGxQRmJ4SFVkUW5jUzdWRkNCdFNndm83N0YwdEloalBwbGtW?=
 =?utf-8?B?b1J4d1c1Q1hYUHpCWWNHQjA1bTNRZDJPOVZBamVoVzN2Z0ttN0NKQUVveHJl?=
 =?utf-8?B?SXpBbkk3dXpqbVhINFZtRmZsa3dQZjhrZ0Q3OEg0dnY1ODVvLzAwOFg4SEZB?=
 =?utf-8?B?M3NpRkNDdXRZckZnRDRNQitERUFWbDlxczRhTUZVdFdvSlluZ2hhYWlpTHlj?=
 =?utf-8?B?SFNtZDV4aytEbkZiTkdzSmdDY2h0YnduZnJodG9jL2N5ZDBFODFaclhSRTM2?=
 =?utf-8?B?dVBQa2ZIdHZ2NDQzY1JodzN3d1dhK28yMXdUVTgyVUZLN0FYdmlHNUQzYkx1?=
 =?utf-8?B?UjhCNUNuU0JkMmVJL0h3TnVRRWsvZEpYWEhWcVJEQ0VteGdDeEZnQ21NdFRS?=
 =?utf-8?B?VURHWk9PWXd2QldqRjYxakdVb3dhaTM4VXhCV25BUkVGYWZIemhrckNQR2FP?=
 =?utf-8?B?alJLWVBLYkluN1dkNmp4bnhOYWZKYVpZTTlBVDNEMW9tVk9nSE5kU0NSZTd2?=
 =?utf-8?B?aStUemY3UldHbXJ6c1pZMGJCak1YeUF1bUhxQXBIUUdLMXA5OTJvSHFZaE1Y?=
 =?utf-8?B?YVB1dUNsZ1RJYW1MWU1FdWxORXpuUTNxQThxNmtvVm5KWmV0QUxMM0xyaTJZ?=
 =?utf-8?B?Si9pZEJBR09lVGFSdmdqaVQ4djFxZ1dOWENRSytzQlNjWDhUTWNXY1lHQitI?=
 =?utf-8?B?SjllWjNibkJpMGNURnFuNkcwcU80TmZhaEtwSm9aSDJoYVRpaVExbnQreVMz?=
 =?utf-8?B?YVNjRE5IY1JBNTU3eWpHRzdUclBHUGhjeHQwUTlhVDJQUnVJRm5lNzFPNXoz?=
 =?utf-8?B?WkNoTDRROHVkWDhJNWhuTFdRS1FNYlRLbXErOUVXNEthdzAzZEFyd2JBd2JS?=
 =?utf-8?B?V0Uyd3B3UTU4dUVGWTFNcytIY2NkanVmMzlTa3ExL1RxZkF1WEFTSHB6Wm5r?=
 =?utf-8?B?SmVSYlFKUGYvSlBOTjhQbGkxTW9BRWxZckRqMllXQU1DYW54dVFOUnFFeXVi?=
 =?utf-8?B?U3RZdHlGQWNQdmJNd0wwS3dhRFpacjdsdHJEU0NWNGVwNXR2d2tNSS83eTRz?=
 =?utf-8?B?YmdmWkNEbzlGOFhMaHBOVVZ2RktjUXRXeTI3VHM0N2FlQnJ3VW0vQ1lLZ29s?=
 =?utf-8?Q?4oL8=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: CH2PR12MB4022.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f735a736-2e57-4f5a-df16-08ddef133992
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2025 20:06:40.5479
 (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: ZN6x0Y6YWWFmeykkO2mwhRXlz6xveT34gz/YIWV5AU2kHTkO8NyVzvFGT/GbovNhpxTOULKQtUu0Rt2/lzwk1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7684

W1B1YmxpY10NCg0KSGkgSmFuICwgSmFzb24gLA0KDQpTdWdnZXN0aW9uIHNvdW5kcyBnb29kIHRv
IG1lIC4gSSBhbSBvayB3aXRoIHRoYXQgLg0KDQpUaGFua3MsDQpTb2hhbQ0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmFzb24gQW5kcnl1ayA8amFzb24uYW5kcnl1a0BhbWQu
Y29tPg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgOCwgMjAyNSA3OjEwIFBNDQpUbzogSmFuIEJl
dWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPjsgRGFuZGFwYXQsIFNvaGFtIDxTb2hhbS5EYW5kYXBh
dEBhbWQuY29tPg0KQ2M6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+
OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IHhlbi1kZXZlbEBsaXN0
cy54ZW5wcm9qZWN0Lm9yZw0KU3ViamVjdDogUmU6IFtQQVRDSF0geDg2L21jaGVjazogYWxsb3cg
dmFyeWluZyBiYW5rIGNvdW50cyBwZXIgQ1BVDQoNCk9uIDIwMjUtMDktMDggMDU6MDgsIEphbiBC
ZXVsaWNoIHdyb3RlOg0KPiBPbiAwNS4wOS4yMDI1IDE5OjAyLCBKYXNvbiBBbmRyeXVrIHdyb3Rl
Og0KPj4NCj4+DQo+PiBPbiAyMDI1LTA5LTA1IDEyOjUyLCBTb2hhbSBEYW5kYXBhdCB3cm90ZToN
Cj4+PiBJbiBtY2FfY2FwX2luaXQgZnVuY3Rpb24sdGhlIG1jYWJhbmtzX2FsbG9jIGFsbG9jYXRl
cyBhbmQNCj4+PiBpbml0aWFsaXplcyBhbiBtY2FfYmFua3Mgc3RydWN0dXJlIGZvciBtYW5hZ2lu
ZyBNQ0EgYmFua3MsIHNldHRpbmcNCj4+PiB1cCBhIGJhbmsgbWFwIGFuZCBzdG9yaW5nIHRoZSBz
cGVjaWZpZWQgb3IgZGVmYXVsdCBudW1iZXIgb2YgYmFua3MuDQo+Pj4NCj4+PiBBZnRlciB0aGlz
IHdlIHdpbGwgY2FsbCBtY2FiYW5rc19zZXQoaSwgbWNhX2FsbGJhbmtzKTsgVGhlDQo+Pj4gbWNh
YmFua3Nfc2V0IGZ1bmN0aW9uIHNldHMgYSBzcGVjaWZpYyBiaXQgaW4gdGhlIGJhbmtfbWFwIG9m
IGFuDQo+Pj4gbWNhX2JhbmtzIHN0cnVjdHVyZSwgcHJvdmlkZWQgdGhlIHN0cnVjdHVyZSwgaXRz
IGJhbmtfbWFwLCBhbmQgdGhlDQo+Pj4gYml0IGluZGV4IGFyZSB2YWxpZC4NCj4+Pg0KPj4+IEF0
IHRoZSBlbmQsIHdlIHdpbGwgY2FsbA0KPj4+IG1jYWJhbmtzX2ZyZWUoeGNoZygmbWNhX2FsbGJh
bmtzLCBhbGwpKTsgVGhpcyBmdW5jdGlvbiBpcyB0aHJlYWQNCj4+PiBzYWZlIGFuZCBkb2VzIGJl
bG93Og0KPj4+ICAgICAgMS4gQXRvbWljYWxseSBleGNoYW5nZXMgdGhlIHZhbHVlIG9mICJtY2Ff
YWxsYmFua3MiIHdpdGggImFsbCINCj4+PiAgICAgIDIuIFJldHVybnMgdGhlIG9sZCB2YWx1ZSB0
aGF0IHdhcyBwcmV2aW91c2x5IGluICJtY2FfYWxsYmFua3MiDQo+Pj4gU28sIHdoZW4gd2Ugd2ls
bCBjYWxsIG1jYWJhbmtzX2ZyZWUgLCB0aGF0IHdpbGwgZnJlZSB0aGUgbWVtb3J5Lg0KPj4+DQo+
Pj4gVGhlIHByb2JsZW0gaXMgdGhhdCBtY2FiYW5rc19zZXQoaSwgbWNhX2FsbGJhbmtzKSBmdW5j
dGlvbiBpcw0KPj4+IHVwZGF0aW5nIG1jYV9hbGxiYW5rcyB3aGljaCB3aWxsIGJlIGZyZWVkIHZp
YSBtY2FiYW5rc19mcmVlIGxhdGVyLg0KPj4+IFRoaXMgbWVhbnMgbmV3IG1jYV9hbGxiYW5rcyBp
bnN0YW5jZSgiYWxsIikgd2lsbCBuZXZlciBnZXQgY2hhbmNlIHRvDQo+Pj4gdXBkYXRlIGl0J3Mg
YmFua19tYXAuDQo+Pj4NCj4+PiBEdWUgdG8gdGhpcyB3aGVuIHdlIHdpbGwgY29sbGVjdCBsb2cg
ZnJvbSBtY2hlY2tfbWNhX2xvZ291dCBmdW5jdGlvbg0KPj4+ICwgdGhlIGNvbmRpdGlvbiAiaWYg
KCAhbWNhYmFua3NfdGVzdChpLCBiYW5rbWFzaykgKSIgd2lsbCBhbHdheXMNCj4+PiBmYWlscyBh
bmQgTUNBIGxvZ3Mgd2lsbCBub3QgYmUgY29sbGVjdGVkIGZvciBhbnkgYmFuay4NCj4+Pg0KPj4+
IFRoZSBmaXggaXMgdG8gc29sdmUgdGhpcyBwcm9ibGVtLg0KPj4+DQo+Pj4gRml4ZXM6IDU2MGNm
NDE4Yzg0NSAoIng4Ni9tY2hlY2s6IGFsbG93IHZhcnlpbmcgYmFuayBjb3VudHMgcGVyDQo+Pj4g
Q1BVIikNCj4+PiBTaWduZWQtb2ZmLWJ5OiBTb2hhbSBEYW5kYXBhdCA8c29oYW0uZGFuZGFwYXRA
YW1kLmNvbT4NCj4+DQo+PiBSZXZpZXdlZC1ieTogSmFzb24gQW5kcnl1ayA8amFzb24uYW5kcnl1
a0BhbWQuY29tPg0KPj4NCj4+IE1heWJlIHRoZSBwYXRjaCBzdWJqZWN0IHNob3VsZCBiZSAieDg2
L21jaGVjazogRml4IG1jYSBiYW5rDQo+PiBpbml0aWFsaXphdGlvbiIgdG8gZGlmZmVyZW50aWF0
ZSBmcm9tIHRoZSBGaXhlcyBjb21taXQ/DQo+DQo+IFRoYXQncyBzdGlsbCBtb3JlIGdlbmVyaWMg
dGhhbiB3YW50ZWQuIEhvdyBhYm91dCAieDg2L21jaGVjazogZml4DQo+IG1jYV9hbGxiYW5rcyB1
cGRhdGluZyI/IFdpdGggYSBtb3JlIGNvbmNpc2UgdGl0bGUgKHdoaWNoIGNhbiBiZQ0KPiBhZGp1
c3RlZCB3aGlsZSBjb21taXR0aW5nLCBzbyBsb25nIGFzIHRoZXJlJ3MgYWdyZWVtZW50KToNCj4g
UmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCg0KWW91ciBzdWdn
ZXN0aW9uIHNvdW5kcyBnb29kIHRvIG1lLg0KDQpUaGFua3MsDQpKYXNvbg0K


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115538.1462124 (Exim 4.92)
	(envelope-from )
	id 1uvj9b-0000FT-AL; Mon, 08 Sep 2025 21:11:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115538.1462124; Mon, 08 Sep 2025 21:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9b-0000FG-5Z; Mon, 08 Sep 2025 21:11:59 +0000
Received: by outflank-mailman (input) for mailman id 1115538;
 Mon, 08 Sep 2025 21:11:58 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9Z-0008QT-Um
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:57 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9Z-000FT2-1m;
 Mon, 08 Sep 2025 21:11:57 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9Z-000gMD-1x;
 Mon, 08 Sep 2025 21:11: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=TefMi+8qYWJ3sWp2Jmhd2ppEtx/E0etNYFj1pW73ooo=; b=RMrlGjVZwWJhwisdIpfyGQezh/
	j8FyprAHyc3RVkYgK75iO9XUlEb0qzIUafCBitw5W9uK7ove5z4B8g4I+/xloaXFZRIK3umNtUu+E
	+yxga2J46i5Km9ti7PzcwdCiKZq84Az/cyKeO9LM4mSWQid53qBKYoNulhHaA1gR4vSI=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 05/16] emul/ns16x50: implement SCR register
Date: Mon,  8 Sep 2025 14:11:38 -0700
Message-ID: <20250908211149.279143-6-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add SCR register emulation to the I/O port handler.
Firmware (e.g. OVMF) may use SCR during the guest OS boot.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- default handling of non-DLL/DLM registers moved to the previous patch
---
 xen/common/emul/vuart/ns16x50.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index da8583a1dc93..5643ef4cc01e 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -106,6 +106,11 @@ static int ns16x50_io_write8(
     {
         switch ( reg )
         {
+        /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
+        case UART_SCR:
+            regs[UART_SCR] = val;
+            break;
+
         default:
             rc = -EINVAL;
             break;
@@ -177,6 +182,10 @@ static int ns16x50_io_read8(
     {
         switch ( reg )
         {
+        case UART_SCR:
+            val = regs[UART_SCR];
+            break;
+
         default:
             rc = -EINVAL;
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115534.1462084 (Exim 4.92)
	(envelope-from )
	id 1uvj9X-0007jx-5K; Mon, 08 Sep 2025 21:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115534.1462084; Mon, 08 Sep 2025 21:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9X-0007jq-2J; Mon, 08 Sep 2025 21:11:55 +0000
Received: by outflank-mailman (input) for mailman id 1115534;
 Mon, 08 Sep 2025 21:11:53 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9V-0007WA-Az
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:53 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9U-000FSB-2w;
 Mon, 08 Sep 2025 21:11:52 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9U-000gJy-35;
 Mon, 08 Sep 2025 21:11: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=qtj1opA8VkUAwTTzkkLeUXZOZ7qNdbdQYOa9K1xcC1Q=; b=tMspcYbtuIWeGzDIyTx++hdG1K
	UbyBmS8gKQrHrsLo/rG2JULC1rKMVOvb1I3c5QCK+GMdRU1KShCIxW9OzhM7Uz/0Qj42ZUS0es81u
	0h5crhOHhQ8nsq12QUSbFtLtRMURXylaz0E7NJiNepKL2ZftI4V0JIE+s4HLxeZgBXdc=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 01/16] emul/vuart: introduce framework for UART emulators
Date: Mon,  8 Sep 2025 14:11:34 -0700
Message-ID: <20250908211149.279143-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

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_VUART_FRAMEWORK, which will be
automatically enabled once the user enables any UART emulator.

Current implementation supports maximum of one vUART of each kind per domain.

Use new domain_has_vuart() in the console driver code to check whether to
forward console input to the domain using vUART.

Enable console forwarding over vUART for hardware domains with a vUART. That
enables console forwarding to dom0 on x86, since console can be forwarded only
to Xen, dom0 and pvshim on x86 as of now.

Note: existing vUARTs are deliberately *not* hooked to the new framework to
minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" (i.e.
minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified.

No functional changes for non-x86 architectures.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- addresses Mykola's feedback
- some renaming (vuart_find_by_flags())
- added extra checks to put_rx and dump_state
- fixed vuart_init() error path
- simplified some checks during vUART state 'search'
---
 xen/arch/arm/xen.lds.S         |   1 +
 xen/arch/ppc/xen.lds.S         |   1 +
 xen/arch/riscv/xen.lds.S       |   1 +
 xen/arch/x86/xen.lds.S         |   1 +
 xen/common/Kconfig             |   2 +
 xen/common/Makefile            |   1 +
 xen/common/emul/Kconfig        |   6 ++
 xen/common/emul/Makefile       |   1 +
 xen/common/emul/vuart/Kconfig  |   6 ++
 xen/common/emul/vuart/Makefile |   1 +
 xen/common/emul/vuart/vuart.c  | 165 +++++++++++++++++++++++++++++++++
 xen/common/keyhandler.c        |   3 +
 xen/drivers/char/console.c     |   6 +-
 xen/include/xen/sched.h        |   4 +
 xen/include/xen/serial.h       |   3 +
 xen/include/xen/vuart.h        | 115 +++++++++++++++++++++++
 xen/include/xen/xen.lds.h      |  10 ++
 17 files changed, 326 insertions(+), 1 deletion(-)
 create mode 100644 xen/common/emul/Kconfig
 create mode 100644 xen/common/emul/Makefile
 create mode 100644 xen/common/emul/vuart/Kconfig
 create mode 100644 xen/common/emul/vuart/Makefile
 create mode 100644 xen/common/emul/vuart/vuart.c
 create mode 100644 xen/include/xen/vuart.h

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index db17ff1efa98..cd05b18770f4 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -58,6 +58,7 @@ SECTIONS
        *(.rodata)
        *(.rodata.*)
        VPCI_ARRAY
+       VUART_ARRAY
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 1de0b77fc6b9..f9d4e5b0dcd8 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -52,6 +52,7 @@ SECTIONS
         *(.rodata)
         *(.rodata.*)
         VPCI_ARRAY
+        VUART_ARRAY
         *(.data.rel.ro)
         *(.data.rel.ro.*)
 
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index edcadff90bfe..59dcaa5fef9a 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -47,6 +47,7 @@ SECTIONS
         *(.rodata)
         *(.rodata.*)
         VPCI_ARRAY
+        VUART_ARRAY
         *(.data.rel.ro)
         *(.data.rel.ro.*)
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 966e514f2034..d877b93a6964 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -132,6 +132,7 @@ SECTIONS
        *(.rodata)
        *(.rodata.*)
        VPCI_ARRAY
+       VUART_ARRAY
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 76f9ce705f7a..78a32b69e2b2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -676,4 +676,6 @@ config PM_STATS
 	  Enable collection of performance management statistics to aid in
 	  analyzing and tuning power/performance characteristics of the system
 
+source "common/emul/Kconfig"
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 0c7d0f5d46e1..8c8462565050 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += domid.o
+obj-y += emul/
 obj-y += event_2l.o
 obj-y += event_channel.o
 obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o
diff --git a/xen/common/emul/Kconfig b/xen/common/emul/Kconfig
new file mode 100644
index 000000000000..7c6764d1756b
--- /dev/null
+++ b/xen/common/emul/Kconfig
@@ -0,0 +1,6 @@
+menu "Domain Emulation Features"
+	visible if EXPERT
+
+source "common/emul/vuart/Kconfig"
+
+endmenu
diff --git a/xen/common/emul/Makefile b/xen/common/emul/Makefile
new file mode 100644
index 000000000000..ae0b575c3901
--- /dev/null
+++ b/xen/common/emul/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VUART_FRAMEWORK) += vuart/
diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig
new file mode 100644
index 000000000000..ce1b976b7da7
--- /dev/null
+++ b/xen/common/emul/vuart/Kconfig
@@ -0,0 +1,6 @@
+config VUART_FRAMEWORK
+	bool
+
+menu "UART Emulation"
+
+endmenu
diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makefile
new file mode 100644
index 000000000000..97f792dc6641
--- /dev/null
+++ b/xen/common/emul/vuart/Makefile
@@ -0,0 +1 @@
+obj-y += vuart.o
diff --git a/xen/common/emul/vuart/vuart.c b/xen/common/emul/vuart/vuart.c
new file mode 100644
index 000000000000..ba89d608aeb2
--- /dev/null
+++ b/xen/common/emul/vuart/vuart.c
@@ -0,0 +1,165 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * UART emulator framework.
+ *
+ * Copyright 2025 Ford Motor Company
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define for_each_emulator(e) \
+    for ( e = vuart_array_start; e < vuart_array_end; e++ )
+
+extern const struct vuart_emulator vuart_array_start[];
+extern const struct vuart_emulator vuart_array_end[];
+
+static const struct vuart_emulator *
+vuart_match_by_compatible(const struct domain *d, const char *compat)
+{
+    const struct vuart_emulator *emulator;
+
+    for_each_emulator(emulator)
+        if ( emulator->compatible &&
+             !strncmp(compat, emulator->compatible,
+                      strlen(emulator->compatible)) )
+            return emulator;
+
+    return NULL;
+}
+
+const static struct vuart *
+vuart_find_by_flags(const struct domain *d, unsigned int flags)
+{
+    const struct vuart *vuart = d->console.vuart;
+
+    if ( vuart && (vuart->flags & flags) )
+        return vuart;
+
+    return NULL;
+}
+
+struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long addr,
+                                     unsigned long size)
+{
+    struct vuart *vuart = d->console.vuart;
+
+    if ( vuart &&
+         addr >= vuart->info->base_addr &&
+         addr + size - 1 <= vuart->info->base_addr + vuart->info->size - 1 )
+        return vuart;
+
+    return NULL;
+}
+
+int vuart_init(struct domain *d, const struct vuart_info *info)
+{
+    const struct vuart_emulator *emulator;
+    struct vuart *vuart;
+    int rc;
+
+    if ( d->console.vuart )
+        return -EBUSY;
+
+    emulator = vuart_match_by_compatible(d, info->compatible);
+    if ( !emulator )
+        return -ENODEV;
+
+    vuart = xzalloc(typeof(*vuart));
+    if ( !vuart )
+        return -ENOMEM;
+
+    vuart->info = xvzalloc(typeof(*vuart->info));
+    if ( !vuart->info )
+    {
+        rc = -ENOMEM;
+        goto err_out1;
+    }
+    memcpy(vuart->info, info, sizeof(*info));
+
+    vuart->vdev = emulator->alloc(d, vuart->info);
+    if ( IS_ERR(vuart->vdev) )
+    {
+        rc = PTR_ERR(vuart->vdev);
+        goto err_out2;
+    }
+
+    vuart->emulator = emulator;
+    vuart->owner = d;
+    vuart->flags |= VUART_CONSOLE_INPUT;
+
+    d->console.input_allowed = true;
+    d->console.vuart = vuart;
+
+    return 0;
+
+ err_out2:
+    xvfree(vuart->info);
+ err_out1:
+    xvfree(vuart);
+
+    return rc;
+}
+
+/*
+ * Release any resources taken by UART emulators.
+ *
+ * NB: no flags are cleared, since currently exit() is called only during
+ * domain destroy.
+ */
+void vuart_deinit(struct domain *d)
+{
+    struct vuart *vuart = d->console.vuart;
+
+    if ( vuart )
+    {
+        vuart->emulator->free(vuart->vdev);
+        xvfree(vuart->info);
+    }
+    XVFREE(d->console.vuart);
+}
+
+/*
+ * Print emulated UART state on the console.
+ *
+ * Must be called under rcu_lock_domain().
+ */
+void vuart_dump_state(const struct domain *d)
+{
+    struct vuart *vuart = d->console.vuart;
+
+    if ( vuart && vuart->emulator->dump_state )
+        vuart->emulator->dump_state(vuart->vdev);
+}
+
+/*
+ * Put character to the first emulated UART's FIFO with the physical console
+ * forwarding enabled.
+ *
+ * Must be called under rcu_lock_domain().
+ */
+int vuart_put_rx(struct domain *d, char c)
+{
+    const struct vuart *vuart = vuart_find_by_flags(d, VUART_CONSOLE_INPUT);
+
+    if ( vuart && vuart->emulator->put_rx )
+        return vuart->emulator->put_rx(vuart->vdev, c);
+
+    return  -ENODEV;
+}
+
+bool domain_has_vuart(const struct domain *d)
+{
+    return vuart_find_by_flags(d, VUART_CONSOLE_INPUT);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index cb6df2823b00..156e64d9eb58 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static unsigned char keypress_key;
@@ -352,6 +353,8 @@ static void cf_check dump_domains(unsigned char key)
                            v->periodic_period / 1000000);
             }
         }
+
+        vuart_dump_state(d);
     }
 
     for_each_domain ( d )
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9bd5b4825da6..d5164897a776 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86
 #include 
@@ -596,11 +597,12 @@ static void __serial_rx(char c)
     if ( !d )
         return;
 
-    if ( is_hardware_domain(d) )
+    if ( is_hardware_domain(d) && !domain_has_vuart(d) )
     {
         /*
          * 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) != SERIAL_RX_SIZE )
             serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
@@ -611,6 +613,8 @@ static void __serial_rx(char c)
          */
         send_global_virq(VIRQ_CONSOLE);
     }
+    else if ( domain_has_vuart(d) )
+        rc = vuart_put_rx(d, c);
 #ifdef CONFIG_SBSA_VUART_CONSOLE
     else
         /* Deliver input to the emulated UART. */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 02bdc256ce37..613f4596e33d 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -660,6 +661,9 @@ struct domain
     struct {
         /* Permission to take ownership of the physical console input. */
         bool input_allowed;
+#ifdef CONFIG_VUART_FRAMEWORK
+        struct vuart *vuart;
+#endif
     } console;
 } __aligned(PAGE_SIZE);
 
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 8e1844555208..123eee67df35 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -36,6 +36,9 @@ struct vuart_info {
     unsigned long data_off;     /* Data register offset */
     unsigned long status_off;   /* Status register offset */
     unsigned long status;       /* Ready status value */
+    unsigned int irq;           /* Interrupt */
+    char compatible[16];        /* Compatible string */
+    char name[16];              /* User-friendly name */
 };
 
 struct serial_port {
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
new file mode 100644
index 000000000000..55828f8498ce
--- /dev/null
+++ b/xen/include/xen/vuart.h
@@ -0,0 +1,115 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * UART emulator framework.
+ *
+ * Copyright 2025 Ford Motor Company
+ */
+
+#ifndef XEN_VUART_H
+#define XEN_VUART_H
+
+#include 
+#include 
+
+struct vuart_emulator;
+
+enum {
+    VUART_CONSOLE_INPUT = BIT(0, U), /* Physical console input forwarding. */
+};
+
+/*
+ * FIXME: #ifdef is temporary to avoid clash with
+ *   arch/arm/include/asm/domain.h
+ */
+#ifdef CONFIG_VUART_FRAMEWORK
+struct vuart {
+    const struct vuart_emulator *emulator;
+    struct vuart_info *info;
+    struct domain *owner;
+    unsigned int flags;
+    void *vdev;
+};
+#endif
+
+struct vuart_emulator {
+    /* UART compatible string. Cannot be NULL or empty. */
+    const char *compatible;
+
+    /*
+     * Allocate emulated UART state (RX/TX FIFOs, locks, initialize registers,
+     * hook I/O handlers, etc.)
+     * Cannot be NULL.
+     */
+    void *(*alloc)(struct domain *d, const struct vuart_info *info);
+
+    /*
+     * Release resources used to emulate UART state (flush RX/TX FIFOs, unhook
+     * I/O handlers, etc.).
+     * Cannot be NULL.
+     */
+    void (*free)(void *arg);
+
+    /*
+     * Print emulated UART state, including registers, on the console.
+     * Can be NULL.
+     */
+    void (*dump_state)(void *arg);
+
+    /*
+     * Place character to the emulated RX FIFO.
+     * Used to forward physical console input to the guest OS.
+     * Can be NULL.
+     */
+    int (*put_rx)(void *arg, char c);
+};
+
+#define VUART_REGISTER(name, x) \
+    static const struct vuart_emulator name##_entry \
+        __used_section(".data.rel.ro.vuart") = x
+
+struct vuart *vuart_find_by_io_range(struct domain *d,
+                                     unsigned long base_addr,
+                                     unsigned long size);
+
+int vuart_put_rx(struct domain *d, char c);
+
+#ifdef CONFIG_VUART_FRAMEWORK
+
+int vuart_init(struct domain *d, const struct vuart_info *info);
+void vuart_deinit(struct domain *d);
+void vuart_dump_state(const struct domain *d);
+bool domain_has_vuart(const struct domain *d);
+
+#else
+
+static inline int vuart_init(struct domain *d, const struct vuart_info *info)
+{
+    return 0;
+}
+
+static inline void vuart_deinit(struct domain *d)
+{
+}
+
+static inline void vuart_dump_state(const struct domain *d)
+{
+}
+
+static inline bool domain_has_vuart(const struct domain *d)
+{
+    return false;
+}
+
+#endif /* CONFIG_VUART_FRAMEWORK */
+
+#endif /* XEN_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/xen.lds.h b/xen/include/xen/xen.lds.h
index b126dfe88792..2d65f32ddad3 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -194,4 +194,14 @@
 #define VPCI_ARRAY
 #endif
 
+#ifdef CONFIG_VUART_FRAMEWORK
+#define VUART_ARRAY              \
+       . = ALIGN(POINTER_ALIGN); \
+       vuart_array_start = .;    \
+       *(.data.rel.ro.vuart)     \
+       vuart_array_end = .;
+#else
+#define VUART_ARRAY
+#endif
+
 #endif /* __XEN_LDS_H__ */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115539.1462131 (Exim 4.92)
	(envelope-from )
	id 1uvj9b-0000Mq-Sq; Mon, 08 Sep 2025 21:11:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115539.1462131; Mon, 08 Sep 2025 21:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9b-0000Kl-Mq; Mon, 08 Sep 2025 21:11:59 +0000
Received: by outflank-mailman (input) for mailman id 1115539;
 Mon, 08 Sep 2025 21:11:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9a-0000E8-Vi
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:58 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9a-000FTE-26;
 Mon, 08 Sep 2025 21:11:58 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9a-000gMH-2K;
 Mon, 08 Sep 2025 21:11: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=UpqDmrURqhicTlP+xGJnrT1Wd61lJrVuEW9MZuV9LUw=; b=QJ+W5RoOargplJeMWgu+XCccUz
	wZJBB6qyLmwA6PakBbMOh8500+D+mgMfVMPDgHPZa+OZ+1SGo2fo3OIGrZuQUuI5j7qmTXKN26yCk
	91RDoRYIJxLN6G66S7CZlRJkXeYy3HRRx+GeUjjYcAXXbOLUFQ8ld2hXjiPr35WrAJP8=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 06/16] emul/ns16x50: implement IER/IIR registers
Date: Mon,  8 Sep 2025 14:11:39 -0700
Message-ID: <20250908211149.279143-7-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add interrupt enable register emulation (IER) and interrupt identity reason
(IIR) register emulation to the I/O port handler.

Also add routines for asserting/deasserting the virtual ns16x50 interrupt
line as a dependent on IIR code. vPIC case is implemented (HVM), vIOAPIC
case is stubbed out (for follow on PVH).

Poke ns16x50_irq_check() on every I/O register access because the emulator
does not have clock emulation anyway (e.g. for baud rate emulation).

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- removed asserts for !has_vpic() paths
---
 xen/common/emul/vuart/ns16x50.c | 138 ++++++++++++++++++++++++++++++++
 1 file changed, 138 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 5643ef4cc01e..664d799ddaee 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -90,6 +90,124 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
     return 0;
 }
 
+static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
+{
+    return false;
+}
+
+/*
+ * Get the interrupt identity reason.
+ *
+ * IIR is re-calculated once called, because ns16x50 always reports high
+ * priority events first.
+ */
+static uint8_t ns16x50_iir_get(const struct vuart_ns16x50 *vdev)
+{
+    /*
+     * Interrupt identity reasons by priority.
+     * NB: high priority are at lower indexes below.
+     */
+    static const struct {
+        bool (*check)(const struct vuart_ns16x50 *vdev);
+        uint8_t ier;
+        uint8_t iir;
+    } iir_by_prio[] = {
+        [0] = { ns16x50_iir_check_lsi, UART_IER_ELSI,   UART_IIR_LSI },
+        [1] = { ns16x50_iir_check_rda, UART_IER_ERDAI,  UART_IIR_RDA },
+        [2] = { ns16x50_iir_check_thr, UART_IER_ETHREI, UART_IIR_THR },
+        [3] = { ns16x50_iir_check_msi, UART_IER_EMSI,   UART_IIR_MSI },
+    };
+    const uint8_t *regs = vdev->regs;
+    uint8_t iir = 0;
+    unsigned int i;
+
+    /*
+     * NB: every interaction w/ ns16x50 registers (except DLAB=1) goes
+     * through that call.
+     */
+    ASSERT(spin_is_locked(&vdev->lock));
+
+    for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ )
+    {
+        if ( (regs[UART_IER] & iir_by_prio[i].ier) &&
+             iir_by_prio[i].check(vdev) )
+            break;
+
+    }
+    if ( i == ARRAY_SIZE(iir_by_prio) )
+        iir |= UART_IIR_NOINT;
+    else
+        iir |= iir_by_prio[i].iir;
+
+    if ( regs[UART_FCR] & UART_FCR_ENABLE )
+        iir |= UART_IIR_FE;
+
+    return iir;
+}
+
+static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
+{
+    struct domain *d = vdev->owner;
+    const struct vuart_info *info = vdev->info;
+    int vector;
+
+    if ( has_vpic(d) )
+        vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
+    else if ( has_vioapic(d) )
+        /* TODO */
+    else
+        ASSERT_UNREACHABLE();
+
+    ns16x50_debug(vdev, "IRQ#%d vector %d assert\n", info->irq, vector);
+}
+
+static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
+{
+    struct domain *d = vdev->owner;
+    const struct vuart_info *info = vdev->info;
+
+    if ( has_vpic(d) )
+        hvm_isa_irq_deassert(d, info->irq);
+    else if ( has_vioapic(d) )
+        /* TODO */
+    else
+        ASSERT_UNREACHABLE();
+
+    ns16x50_debug(vdev, "IRQ#%d deassert\n", info->irq);
+}
+
+/*
+ * Assert/deassert virtual ns16x50 interrupt line.
+ */
+static void ns16x50_irq_check(const struct vuart_ns16x50 *vdev)
+{
+    uint8_t iir = ns16x50_iir_get(vdev);
+    const struct vuart_info *info = vdev->info;
+
+    if ( iir & UART_IIR_NOINT )
+        ns16x50_irq_deassert(vdev);
+    else
+        ns16x50_irq_assert(vdev);
+
+    ns16x50_debug(vdev, "IRQ#%d IIR 0x%02x %s\n", info->irq, iir,
+                  (iir & UART_IIR_NOINT) ? "deassert" : "assert");
+}
+
 /*
  * Emulate 8-bit write access to ns16x50 register.
  */
@@ -106,6 +224,10 @@ static int ns16x50_io_write8(
     {
         switch ( reg )
         {
+        case UART_IER:
+            regs[UART_IER] = val & UART_IER_MASK;
+            break;
+
         /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
         case UART_SCR:
             regs[UART_SCR] = val;
@@ -115,6 +237,8 @@ static int ns16x50_io_write8(
             rc = -EINVAL;
             break;
         }
+
+        ns16x50_irq_check(vdev);
     }
 
     return rc;
@@ -182,6 +306,14 @@ static int ns16x50_io_read8(
     {
         switch ( reg )
         {
+        case UART_IER:
+            val = regs[UART_IER];
+            break;
+
+        case UART_IIR: /* RO */
+            val = ns16x50_iir_get(vdev);
+            break;
+
         case UART_SCR:
             val = regs[UART_SCR];
             break;
@@ -190,6 +322,8 @@ static int ns16x50_io_read8(
             rc = -EINVAL;
             break;
         }
+
+        ns16x50_irq_check(vdev);
     }
 
     *data = val;
@@ -342,6 +476,10 @@ static int ns16x50_init(void *arg)
 
     register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
 
+    spin_lock(&vdev->lock);
+    ns16x50_irq_check(vdev);
+    spin_unlock(&vdev->lock);
+
     return 0;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115540.1462145 (Exim 4.92)
	(envelope-from )
	id 1uvj9d-0000jW-7J; Mon, 08 Sep 2025 21:12:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115540.1462145; Mon, 08 Sep 2025 21:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9d-0000ik-0y; Mon, 08 Sep 2025 21:12:01 +0000
Received: by outflank-mailman (input) for mailman id 1115540;
 Mon, 08 Sep 2025 21:12:00 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9c-0000Sw-23
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:00 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9b-000FTS-2Q;
 Mon, 08 Sep 2025 21:11:59 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9b-000gML-2e;
 Mon, 08 Sep 2025 21:11: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=zvzWLhOV/JuCu2mvge1tqyEd27KupA6wAEV4H8Ytz2o=; b=RC3FU9fvNVrQUef+qZ8kprTEBT
	hcpe1q7LW4fQYlQnGo+yjlbxuADdqEJrUYMEur6/Mng/Ic4GC7ZwJqULvMiQcfLqFPUIG4cYk7dfH
	3/9/uwNi57vf5TUGOA4M1s2iw0JHdsxn+ZeSA906NFtmb2/7B4/qnau6m/of+Q71YyOk=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 07/16] emul/ns16x50: implement LCR/LSR registers
Date: Mon,  8 Sep 2025 14:11:40 -0700
Message-ID: <20250908211149.279143-8-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add LCR/LSR registers implementation to the I/O port handler.

Add implementation of ns16x50_dlab_get() and ns16x50_iir_check_lsi().

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- n/a
---
 xen/common/emul/vuart/ns16x50.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 664d799ddaee..0831a576cd9e 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -87,12 +87,12 @@ struct vuart_ns16x50 {
 
 static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 {
-    return 0;
+    return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
 }
 
 static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return vdev->regs[UART_LSR] & UART_LSR_MASK;
 }
 
 static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
@@ -228,11 +228,16 @@ static int ns16x50_io_write8(
             regs[UART_IER] = val & UART_IER_MASK;
             break;
 
+        case UART_LCR:
+            regs[UART_LCR] = val;
+            break;
+
         /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
         case UART_SCR:
             regs[UART_SCR] = val;
             break;
 
+        case UART_LSR: /* RO */
         default:
             rc = -EINVAL;
             break;
@@ -314,6 +319,15 @@ static int ns16x50_io_read8(
             val = ns16x50_iir_get(vdev);
             break;
 
+        case UART_LCR:
+            val = regs[UART_LCR];
+            break;
+
+        case UART_LSR:
+            val = regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
+            regs[UART_LSR] = val & ~UART_LSR_MASK;
+            break;
+
         case UART_SCR:
             val = regs[UART_SCR];
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115535.1462091 (Exim 4.92)
	(envelope-from )
	id 1uvj9X-0007qp-K2; Mon, 08 Sep 2025 21:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115535.1462091; Mon, 08 Sep 2025 21:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9X-0007pP-Ed; Mon, 08 Sep 2025 21:11:55 +0000
Received: by outflank-mailman (input) for mailman id 1115535;
 Mon, 08 Sep 2025 21:11:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9W-0007g9-Hb
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:54 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9W-000FSM-0J;
 Mon, 08 Sep 2025 21:11:54 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9W-000gK2-0U;
 Mon, 08 Sep 2025 21: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=ScRE3g8jVmbQQYHS5u6EzEGBByXpDzH+16MqZDTV2QA=; b=SHNIZw8PuWMOdsmDTnYETDo1QS
	klbIfNDdyd+svI1DElYh8m7wO2zafd0+hnHN+ivmRyfphzI5KoDyTumkeIVue0muN6BuTNHLQf5mj
	0tJ6p3QPKnAbVVqqvYCA7BqNSyI1/fRkOKjOQ+Xw9HykDa6PhfJMk1U56Cfil547TY+w=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 02/16] xen/8250-uart: update definitions
Date: Mon,  8 Sep 2025 14:11:35 -0700
Message-ID: <20250908211149.279143-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Added missing definitions needed for NS16550 UART emulator.

Newly introduced MSR definitions re-used in the existing ns16550 driver.

Also, corrected FCR DMA definition bit#3 (0x08) as per:
  https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
See "7.7.2 FIFO Control Register (FCR)".

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- used raw bitmasks instead of BIT() for consistency
---
 xen/drivers/char/ns16550.c  | 16 ++++++++--------
 xen/include/xen/8250-uart.h | 36 ++++++++++++++++++++++++++++++++++--
 2 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index df7fff7f81df..0e80fadbb894 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -388,7 +388,7 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port)
 
     /* Check this really is a 16550+. Otherwise we have no FIFOs. */
     if ( uart->fifo_size <= 1 &&
-         ((ns_read_reg(uart, UART_IIR) & 0xc0) == 0xc0) &&
+         ((ns_read_reg(uart, UART_IIR) & UART_IIR_FE) == UART_IIR_FE) &&
          ((ns_read_reg(uart, UART_FCR) & UART_FCR_TRG14) == UART_FCR_TRG14) )
         uart->fifo_size = 16;
 }
@@ -728,20 +728,20 @@ static int __init check_existence(struct ns16550 *uart)
      * Mask out IER[7:4] bits for test as some UARTs (e.g. TL
      * 16C754B) allow only to modify them if an EFR bit is set.
      */
-    scratch2 = ns_read_reg(uart, UART_IER) & 0x0f;
-    ns_write_reg(uart,UART_IER, 0x0F);
-    scratch3 = ns_read_reg(uart, UART_IER) & 0x0f;
+    scratch2 = ns_read_reg(uart, UART_IER) & UART_IER_MASK;
+    ns_write_reg(uart, UART_IER, UART_IER_MASK);
+    scratch3 = ns_read_reg(uart, UART_IER) & UART_IER_MASK;
     ns_write_reg(uart, UART_IER, scratch);
-    if ( (scratch2 != 0) || (scratch3 != 0x0F) )
+    if ( (scratch2 != 0) || (scratch3 != UART_IER_MASK) )
         return 0;
 
     /*
      * Check to see if a UART is really there.
      * Use loopback test mode.
      */
-    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | 0x0A);
-    status = ns_read_reg(uart, UART_MSR) & 0xF0;
-    return (status == 0x90);
+    ns_write_reg(uart, UART_MCR, UART_MCR_LOOP | UART_MCR_RTS | UART_MCR_OUT2);
+    status = ns_read_reg(uart, UART_MSR) & UART_MSR_STATUS;
+    return (status == (UART_MSR_CTS | UART_MSR_DCD));
 }
 
 #ifdef CONFIG_HAS_PCI
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index d13352940c13..a8a26b64689e 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SCR          0x07    /* Scratch pad          */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -42,6 +43,8 @@
 #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
 #define UART_IER_ELSI     0x04    /* rx line status       */
 #define UART_IER_EMSI     0x08    /* MODEM status         */
+#define UART_IER_MASK \
+    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
 
 /* Interrupt Identification Register */
 #define UART_IIR_NOINT    0x01    /* no interrupt pending */
@@ -51,12 +54,19 @@
 #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
 #define UART_IIR_MSI      0x00    /*  - MODEM status      */
 #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
+#define UART_IIR_FE       0xc0    /* FIFO enabled (2 bits) */
 
 /* FIFO Control Register */
 #define UART_FCR_ENABLE   0x01    /* enable FIFO          */
 #define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
 #define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
-#define UART_FCR_DMA      0x10    /* enter DMA mode       */
+#define UART_FCR_DMA      0x08    /* enter DMA mode       */
+#define UART_FCR_RSRVD0   0x10    /* reserved; always 0   */
+#define UART_FCR_RSRVD1   0x20    /* reserved; always 0   */
+#define UART_FCR_RTB0     0x40    /* receiver trigger bit #0 */
+#define UART_FCR_RTB1     0x80    /* receiver trigger bit #1 */
+#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)
+
 #define UART_FCR_TRG1     0x00    /* Rx FIFO trig lev 1   */
 #define UART_FCR_TRG4     0x40    /* Rx FIFO trig lev 4   */
 #define UART_FCR_TRG8     0x80    /* Rx FIFO trig lev 8   */
@@ -98,9 +108,30 @@
 /* Modem Control Register */
 #define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
 #define UART_MCR_RTS      0x02    /* Request to Send      */
-#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
+#define UART_MCR_OUT1     0x04    /* Output #1 */
+#define UART_MCR_OUT2     0x08    /* Output #2 */
 #define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
+#define UART_MCR_RSRVD0   0x20    /* Reserved #0 */
 #define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
+#define UART_MCR_RSRVD1   0x80    /* Reserved #1 */
+#define UART_MCR_MASK \
+    (UART_MCR_DTR | UART_MCR_RTS | \
+     UART_MCR_OUT1 | UART_MCR_OUT2 | \
+     UART_MCR_LOOP | UART_MCR_TCRTLR)
+
+/* Modem Status Register */
+#define UART_MSR_DCTS     0x01    /* Change in CTS */
+#define UART_MSR_DDSR     0x02    /* Change in DSR */
+#define UART_MSR_TERI     0x04    /* Change in RI */
+#define UART_MSR_DDCD     0x08    /* Change in DCD */
+#define UART_MSR_CTS      0x10
+#define UART_MSR_DSR      0x20
+#define UART_MSR_RI       0x40
+#define UART_MSR_DCD      0x80
+#define UART_MSR_CHANGE \
+    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
+#define UART_MSR_STATUS \
+    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
 
 /* Line Status Register */
 #define UART_LSR_DR       0x01    /* Data ready           */
@@ -111,6 +142,7 @@
 #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
 #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
 #define UART_LSR_ERR      0x80    /* Error                */
+#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)
 
 /* These parity settings can be ORed directly into the LCR. */
 #define UART_PARITY_NONE  (0<<3)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115533.1462075 (Exim 4.92)
	(envelope-from )
	id 1uvj9V-0007WN-Vn; Mon, 08 Sep 2025 21:11:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115533.1462075; Mon, 08 Sep 2025 21:11: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 1uvj9V-0007WG-Rg; Mon, 08 Sep 2025 21:11:53 +0000
Received: by outflank-mailman (input) for mailman id 1115533;
 Mon, 08 Sep 2025 21:11:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9U-0007W4-Em
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9T-000FS0-2v;
 Mon, 08 Sep 2025 21:11:51 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9T-000gJu-2i;
 Mon, 08 Sep 2025 21:11:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date:
	Subject:Cc:To:From; bh=gFl0pRnNZtxdAQg1cH6a2vl8FVoMMNPhvd73iF81Bqg=; b=s5plSy
	eBY98SlAnKiuPKEhC87k3fqn6JQLp/bK8olYIb4As6Kb+yMR0ZXiemaIYUpTguPLG2rcshBeK2Ep8
	6Y7BuzFYcGZ4YrYzs4E/pzbGRpYFhHlR9ZjEnAKfLLxBpg4407fN2qxquwN8/E+ZI70M6dZvDJzV8
	qVRT1uL03FQ=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 00/16] x86: introduce NS16550-compatible UART emulator
Date: Mon,  8 Sep 2025 14:11:33 -0700
Message-ID: <20250908211149.279143-1-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

x86 port of Xen lacks vUART facility similar to Arm's vpl011 to support x86
guest OS bring up in the embedded setups.

This patch series introduces initial in-hypervisor emulator for
NS8250/NS16x50-compatible UARTs under CONFIG_VUART_NS16X50.

In parallel domain creation scenario (hyperlaunch), NS16550 emulator helps
early guest firmware and OS bringup debugging, because it eliminates
dependency on the external emulator (qemu) being operational by the time
domains are created.

The emulator also allows to forward the physical console input to the x86
domain which is useful when a system has only one physical UART for early
debugging and this UART is owned by Xen.

By default, CONFIG_VUART_NS16X50 enables emulation of NS16550 at I/O port
0x3f8, IRQ#4 in guest OS (legacy COM1). Legacy COM resources can be selected
at run-time via temporary and undocumented switch 'vuart='.

CONFIG_VUART_NS16X50_DEBUG enables some extra debugging facilities useful
for NS16550 emulator development/debugging (disabled by default).

The NS16550 emulator is disabled in default x86 configuration and goes under
CONFIG_EXPERT in Kconfig.

Limitations
===========
- Only x86;
- Only legacy COM resources, custom I/O ports/IRQs are not supported;
- Only Xen console as a backend, no inter-domain communication (similar to
  vpl011 on Arm);
- Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
- No toolstack integration;
- No baud rate emulation (reports 115200 baud to the guest OS);
- No FIFO-less mode emulation;
- No RX FIFO interrupt moderation (FCR) emulation;
- No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
  friends);
- No MMIO-based UART emulation.

Series
======

  Patch 1 introduces the new vUART framework, that is the code originally
  posted here:
    https://lore.kernel.org/xen-devel/20250624035443.344099-16-dmukhin@ford.com/
  Required for emulator.

  Patch 2 adds missing NS16550 definitions, required for emulator.

  Patch 3 introduces the basic emulator skeleton - state machine
  initialization stubs, I/O port handler stub, logging, etc.

  Patches 4-11 incrementally populate the minimal NS16550 register emulation.

  Patch 12 adds Kconfig for enabling minimal NS16550 UART (disabled by default).

  Patch 13 hooks vUART state debugging (disabled by default).

  Pathes 14-16 introduce necessary changes to enable NS16550 on dom0 (and PVH).

Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2028388344
Link to branch: https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-ns8250-v7?ref_type=heads

Testing
=======

  ```shell
  echo CONFIG_EXPERT=y >> .config
  echo CONFIG_VUART_NS16X50=y >> .config
  make olddefconfig
  ```

  To test w/ virtual COM2, the guest kernel parameters should contain
  something like the following:
    earlycon=uart,io,0x2f8,115200n8 console=uart,io,0x2f8,115200n8

  Xen command line should have:
    vuart=,com2

  HVM
  ---
  Tested only boot of HVM linux guest with OVMF as the virtual firmware.
  SeaBIOS as a virtual firmware is not tested.

  PVH (dom0)
  ----------
  Xen is able to forward physical console input to the domain with virtual
  NS16550. To switch the console focus press Ctrl+aaa.
  Console switch is limited on x86 to dom0 and Xen (fixes pending).

Changes since v6:
- Addressed feedback from v6, mainly DLL, THRE interrupt reason handling and
  fixups in vuart.c and ns16x50.c. Also plumbed new temporary swicth 'vuart='
  for ease of testing (CI unit test jobs are pending).
- Link to v6:  https://lore.kernel.org/xen-devel/20250905232715.440758-1-dmukhin@ford.com/

Changes since v5:
- Split THR/RBR into two separate patches.
- Addressed feedback from v5.
- Link to v5: https://lore.kernel.org/xen-devel/20250828235409.2835815-1-dmukhin@ford.com/

Changes since v4:
- Split the series to make it simpler to review.
- Addressed feedback from v4.
- Dropped xl changes, which I will submit separately.
- Link to v4: https://lore.kernel.org/xen-devel/20250731192130.3948419-1-dmukhin@ford.com/

Changes since v3:
- Reduced the blast radius of the series, thanks to reviews, individual
  aspects (like console focus) touched in v3 moved to separate threads.
- Kept the UART emulator framework since I need to redo some of emulator code
  and there's more-or-less agreement on it (where to place, naming, scope).
- Applied the feedback from
    https://lore.kernel.org/xen-devel/20250624035443.344099-1-dmukhin@ford.com/
- Link to v3: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d66c@ford.com/

Changes since v2:
- renamed emulator s/NS8250/NS16550/g
- reduced the patch series after addressing v2 feedback
- introduced driver framework for UART emulators
- unified guest OS printouts across all available UART emulators
- Link to v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/

Changes since v1:
- dropped kmalloc/kfree aliases
- fixed ECLAIR jobs (thanks Andrew Cooper)
- addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu)
- moved NS8250 debugging stubs into its own patch
- added fix for https://gitlab.com/xen-project/xen/-/issues/184
- Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com

Denis Mukhin (16):
  emul/vuart: introduce framework for UART emulators
  xen/8250-uart: update definitions
  emul/ns16x50: implement emulator stub
  emul/ns16x50: implement DLL/DLM registers
  emul/ns16x50: implement SCR register
  emul/ns16x50: implement IER/IIR registers
  emul/ns16x50: implement LCR/LSR registers
  emul/ns16x50: implement MCR/MSR registers
  emul/ns16x50: implement RBR register
  emul/ns16x50: implement THR register
  emul/ns16x50: implement FCR register (write-only)
  emul/ns16550: implement dump_state() hook
  emul/ns16x50: add Kconfig options
  x86/domain: enable per-domain I/O port bitmaps
  xen/domain: allocate d->irq_caps before arch-specific initialization
  emul/ns16x50: implement IRQ emulation via vIOAPIC

 xen/arch/arm/xen.lds.S                   |   1 +
 xen/arch/ppc/xen.lds.S                   |   1 +
 xen/arch/riscv/xen.lds.S                 |   1 +
 xen/arch/x86/Makefile                    |   1 +
 xen/arch/x86/dom0_build.c                | 112 +--
 xen/arch/x86/hvm/dom0_build.c            |   7 +
 xen/arch/x86/hvm/hvm.c                   | 110 ++-
 xen/arch/x86/hvm/nestedhvm.c             |   8 +-
 xen/arch/x86/hvm/quirks.c                |   3 -
 xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
 xen/arch/x86/hvm/vioapic.c               |  10 +
 xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
 xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
 xen/arch/x86/include/asm/hvm/support.h   |   2 -
 xen/arch/x86/include/asm/iocap.h         |   2 +
 xen/arch/x86/include/asm/irq.h           |   8 +
 xen/arch/x86/ioport.c                    | 163 ++++
 xen/arch/x86/irq.c                       |   8 +
 xen/arch/x86/pv/dom0_build.c             |   7 +
 xen/arch/x86/xen.lds.S                   |   1 +
 xen/common/Kconfig                       |   2 +
 xen/common/Makefile                      |   1 +
 xen/common/domain.c                      |   8 +-
 xen/common/emul/Kconfig                  |   6 +
 xen/common/emul/Makefile                 |   1 +
 xen/common/emul/vuart/Kconfig            |  25 +
 xen/common/emul/vuart/Makefile           |   2 +
 xen/common/emul/vuart/ns16x50.c          | 970 +++++++++++++++++++++++
 xen/common/emul/vuart/vuart.c            | 165 ++++
 xen/common/keyhandler.c                  |   3 +
 xen/drivers/char/console.c               |   6 +-
 xen/drivers/char/ns16550.c               |  16 +-
 xen/drivers/passthrough/x86/hvm.c        |  11 +-
 xen/include/xen/8250-uart.h              |  36 +-
 xen/include/xen/sched.h                  |   4 +
 xen/include/xen/serial.h                 |   3 +
 xen/include/xen/vuart.h                  | 115 +++
 xen/include/xen/xen.lds.h                |  10 +
 38 files changed, 1674 insertions(+), 164 deletions(-)
 create mode 100644 xen/arch/x86/ioport.c
 create mode 100644 xen/common/emul/Kconfig
 create mode 100644 xen/common/emul/Makefile
 create mode 100644 xen/common/emul/vuart/Kconfig
 create mode 100644 xen/common/emul/vuart/Makefile
 create mode 100644 xen/common/emul/vuart/ns16x50.c
 create mode 100644 xen/common/emul/vuart/vuart.c
 create mode 100644 xen/include/xen/vuart.h

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115536.1462104 (Exim 4.92)
	(envelope-from )
	id 1uvj9Y-0008Bl-Ou; Mon, 08 Sep 2025 21:11:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115536.1462104; Mon, 08 Sep 2025 21:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9Y-0008Bc-Lf; Mon, 08 Sep 2025 21:11:56 +0000
Received: by outflank-mailman (input) for mailman id 1115536;
 Mon, 08 Sep 2025 21:11:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9X-0007uw-Nj
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9X-000FSc-18;
 Mon, 08 Sep 2025 21:11:55 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9X-000gKq-1K;
 Mon, 08 Sep 2025 21:11: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=1FdFTRNsjH5U9rDP4kQAUpXOlwuD271Mac2A8wU+UVw=; b=5ZzkpER2wQKhBha22yOLu1C5DQ
	l4XWikl2jK8dKsP+A860LeeFf9qmsNy1wElQuGGM9LzAjAbWq7zwWzHM67+qEqNQmmLcZprJ9v6kf
	eHQ+Cs4IEh1eJzrvA3SbyDpjMfZB2cKxgI6HD4GyAsC6Yee+IEG8VsBqQVXj5aPwPq0s=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 03/16] emul/ns16x50: implement emulator stub
Date: Mon,  8 Sep 2025 14:11:36 -0700
Message-ID: <20250908211149.279143-4-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

The change is the first on the way on introducing minimally functional
NS16550-compatible UART emulator.

Only one domain, defined via 'vuart=' parameter, will have UART emulator
initially. The command line option is not documented yet because of the plan
to adjust this code for vUART configuration via xl.

Define UART state and a set of emulated registers.

Implement alloc/free vUART hooks.

Stub out I/O port handler.

Add initialization of the NS16x50-compatible UART emulator state machine.

Plumb debug logging.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- feedback from Mykola
- added temporary 'vuart=' run-time option to enable emulator for certain
  domain for ease of testing
---
 xen/arch/x86/hvm/hvm.c          |  75 +++++++
 xen/common/emul/vuart/Makefile  |   1 +
 xen/common/emul/vuart/ns16x50.c | 364 ++++++++++++++++++++++++++++++++
 3 files changed, 440 insertions(+)
 create mode 100644 xen/common/emul/vuart/ns16x50.c

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a1d..363c010f8dcc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -107,6 +108,67 @@ static const char __initconst warning_hvm_fep[] =
 static bool __initdata opt_altp2m_enabled;
 boolean_param("altp2m", opt_altp2m_enabled);
 
+/* Enable NS16550 emulator for certain domain only. */
+static int __read_mostly opt_vuart_domid = -1;
+
+#ifdef CONFIG_VUART_NS16X50
+static int __read_mostly opt_vuart_id;
+static int __init cf_check parse_vuart_param(const char *s)
+{
+    if ( !isdigit(*s) )
+        return -EINVAL;
+
+    opt_vuart_domid = simple_strtoul(s, &s, 0);
+
+    if ( *s != ':' )
+        return 0;
+
+    if ( strncmp(s, "com", 3) )
+        return -EINVAL;
+
+    opt_vuart_id = *(s + 3) - '1';
+    if ( opt_vuart_id < 0 || opt_vuart_id > 3 )
+        return -EINVAL;
+
+    return 0;
+}
+custom_param("vuart", parse_vuart_param);
+
+static const struct vuart_info *get_vuart_info(struct domain *d)
+{
+#define PC_UART(n,p,i) { \
+    .name = n, \
+    .compatible = "ns16550", \
+    .base_addr = p, \
+    .size = 8, \
+    .irq = i, \
+}
+    static const struct vuart_info pc_uarts[4] =
+    {
+        PC_UART("com1", 0x3f8, 4),
+        PC_UART("com2", 0x2f8, 3),
+        PC_UART("com3", 0x3fe, 4),
+        PC_UART("com4", 0x2fe, 3),
+    };
+    unsigned i;
+
+    for ( i = 0; i < ARRAY_SIZE(pc_uarts); i++ )
+        if ( i == opt_vuart_id )
+            break;
+
+    if ( i != ARRAY_SIZE(pc_uarts) )
+        return &pc_uarts[i];
+
+    return NULL;
+#undef PC_UART
+}
+#else
+static const struct vuart_info *get_vuart_info(struct domain *d)
+{
+    return NULL;
+}
+#endif /* CONFIG_VUART_NS16X50 */
+
 static int cf_check cpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -689,6 +751,15 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc != 0 )
         goto fail1;
 
+    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && d->domain_id == opt_vuart_domid )
+    {
+        const struct vuart_info *info = get_vuart_info(d);
+
+        rc = vuart_init(d, info);
+        if ( rc )
+            goto out_vioapic_deinit;
+    }
+
     stdvga_init(d);
 
     rtc_init(d);
@@ -712,6 +783,8 @@ int hvm_domain_initialise(struct domain *d,
     return 0;
 
  fail2:
+    vuart_deinit(d);
+ out_vioapic_deinit:
     vioapic_deinit(d);
  fail1:
     if ( is_hardware_domain(d) )
@@ -774,6 +847,8 @@ void hvm_domain_destroy(struct domain *d)
     if ( hvm_funcs.domain_destroy )
         alternative_vcall(hvm_funcs.domain_destroy, d);
 
+    vuart_deinit(d);
+
     vioapic_deinit(d);
 
     XFREE(d->arch.hvm.pl_time);
diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makefile
index 97f792dc6641..fe904f6cb65d 100644
--- a/xen/common/emul/vuart/Makefile
+++ b/xen/common/emul/vuart/Makefile
@@ -1 +1,2 @@
 obj-y += vuart.o
+obj-$(CONFIG_VUART_NS16X50) += ns16x50.o
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
new file mode 100644
index 000000000000..a3bdf9f415ca
--- /dev/null
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -0,0 +1,364 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * NS16550-compatible UART Emulator.
+ *
+ * See:
+ * - Serial and UART Tutorial:
+ *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-uart_en.pdf
+ * - UART w/ 16 byte FIFO:
+ *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
+ * - UART w/ 64 byte FIFO:
+ *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
+ *
+ * Limitations:
+ * - Only x86;
+ * - Only Xen console as a backend, no inter-domain communication (similar to
+ *   vpl011 on Arm);
+ * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
+ * - No baud rate emulation (reports 115200 baud to the guest OS);
+ * - No FIFO-less mode emulation;
+ * - No RX FIFO interrupt moderation (FCR) emulation;
+ * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
+ *   friends);
+ * - No ISA IRQ sharing allowed;
+ * - No MMIO-based UART emulation.
+ */
+
+#define pr_prefix               "ns16x50"
+#define pr_fmt(fmt)             pr_prefix ": " fmt
+
+#ifdef CONFIG_VUART_NS16X50_DEBUG
+#define guest_prefix            "FROM GUEST "
+#define ns16x50_log_level       2
+#else
+#define guest_prefix            ""
+#define ns16x50_log_level       0
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define ns16x50_log(n, lvl, vdev, fmt, args...) \
+do { \
+    if ( ns16x50_log_level >= n ) \
+        gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \
+} while (0)
+
+#define ns16x50_err(vdev, fmt, args...) \
+    ns16x50_log(0, XENLOG_ERR, vdev, fmt, ## args)
+#define ns16x50_warn(vdev, fmt, args...) \
+    ns16x50_log(1, XENLOG_WARNING, vdev, fmt, ## args)
+#define ns16x50_info(vdev, fmt, args...) \
+    ns16x50_log(2, XENLOG_INFO, vdev, fmt, ## args)
+#define ns16x50_debug(vdev, fmt, args...) \
+    ns16x50_log(3, XENLOG_DEBUG, vdev, fmt, ## args)
+
+/*
+ * Number of supported registers in the UART.
+ */
+#define NS16X50_REGS_NUM        (UART_SCR + 1)
+
+/*
+ * Number of emulated registers.
+ *
+ * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=0.
+ * - DLAB=1, R/W, DLL         = (NS16X50_REGS_NUM + 0)
+ * - DLAB=1, R/W, DLM         = (NS16X50_REGS_NUM + 1)
+ */
+#define NS16X50_EMU_REGS_NUM    (NS16X50_REGS_NUM + 2)
+
+/*
+ * Virtual ns16x50 device state.
+ */
+struct vuart_ns16x50 {
+    uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */
+    const struct vuart_info *info;      /* UART description */
+    struct domain *owner;               /* Owner domain */
+    const char *name;                   /* Device name */
+    spinlock_t lock;                    /* Protection */
+    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
+};
+
+static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
+{
+    return 0;
+}
+
+/*
+ * Emulate 8-bit write access to ns16x50 register.
+ */
+static int ns16x50_io_write8(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
+{
+    int rc = 0;
+
+    return rc;
+}
+
+/*
+ * Emulate 16-bit write access to ns16x50 register.
+ * NB: some guest OSes use outw() to access UART_DLL.
+ */
+static int ns16x50_io_write16(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
+{
+    int rc = -EINVAL;
+
+    return rc;
+}
+
+/*
+ * Emulate write access to ns16x50 register.
+ */
+static int ns16x50_io_write(
+    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
+{
+    int rc;
+
+    switch ( size )
+    {
+    case 1:
+        rc = ns16x50_io_write8(vdev, reg, (uint8_t *)data);
+        break;
+
+    case 2:
+        rc = ns16x50_io_write16(vdev, reg, (uint16_t *)data);
+        break;
+
+    default:
+        rc = -EINVAL;
+        break;
+    }
+
+    return rc;
+}
+
+/*
+ * Emulate 8-bit read access to ns16x50 register.
+ */
+static int ns16x50_io_read8(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
+{
+    uint8_t val = UINT8_MAX;
+    int rc = 0;
+
+    *data = val;
+
+    return rc;
+}
+
+/*
+ * Emulate 16-bit read access to ns16x50 register.
+ */
+static int ns16x50_io_read16(
+    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
+{
+    uint16_t val = UINT16_MAX;
+    int rc = -EINVAL;
+
+    *data = val;
+
+    return rc;
+}
+
+/*
+ * Emulate read access to ns16x50 register.
+ */
+static int ns16x50_io_read(
+    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
+{
+    int rc;
+
+    switch ( size )
+    {
+    case 1:
+        rc = ns16x50_io_read8(vdev, reg, (uint8_t *)data);
+        break;
+
+    case 2:
+        rc = ns16x50_io_read16(vdev, reg, (uint16_t *)data);
+        break;
+
+    default:
+        *data = UINT32_MAX;
+        rc = -EINVAL;
+        break;
+    }
+
+    return rc;
+}
+
+/*
+ * Emulate I/O access to ns16x50 register.
+ * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled.
+ */
+static int cf_check ns16x50_io_handle(
+    int dir, unsigned int addr, unsigned int size, uint32_t *data)
+{
+    const char op = (dir == IOREQ_WRITE) ? 'W' : 'R';
+    struct domain *d = rcu_lock_current_domain();
+    struct vuart *vuart = vuart_find_by_io_range(d, addr, size);
+    struct vuart_ns16x50 *vdev;
+    const struct domain *owner;
+    const struct vuart_info *info;
+    uint32_t reg;
+    unsigned dlab;
+    int rc;
+
+    if ( !vuart )
+    {
+        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
+               op, addr, size);
+
+        ASSERT_UNREACHABLE();
+        goto out;
+    }
+
+    vdev = vuart->vdev;
+    ASSERT(vdev);
+
+    owner = vuart->owner;
+    ASSERT(owner);
+
+    if ( d != owner )
+    {
+        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domain %pv\n",
+                    op, addr, size, d);
+
+        ASSERT_UNREACHABLE();
+        goto out;
+    }
+
+    info = vuart->info;
+    ASSERT(info);
+
+    reg = addr - info->base_addr;
+    if ( !IS_ALIGNED(reg, size) )
+    {
+        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
+                    op, addr, size);
+        goto out;
+    }
+
+    dlab = ns16x50_dlab_get(vdev);
+    if ( reg >= NS16X50_REGS_NUM )
+    {
+        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": not implemented\n",
+                    op, addr, size, dlab, reg, *data);
+        goto out;
+    }
+
+    spin_lock(&vdev->lock);
+
+    if ( dir == IOREQ_WRITE )
+        rc = ns16x50_io_write(vdev, reg, size, data);
+    else
+        rc = ns16x50_io_read(vdev, reg, size, data);
+
+    spin_unlock(&vdev->lock);
+
+    if ( rc == 0 )
+        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
+                      op, addr, size, dlab, reg, *data);
+    else
+        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32": unsupported access\n",
+                    op, addr, size, dlab, reg, *data);
+
+out:
+    rcu_unlock_domain(d);
+
+    return X86EMUL_OKAY;
+}
+
+static int ns16x50_init(void *arg)
+{
+    struct vuart_ns16x50 *vdev = arg;
+    const struct vuart_info *info = vdev->info;
+    struct domain *d = vdev->owner;
+
+    ASSERT(vdev);
+
+    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
+
+    return 0;
+}
+
+static void cf_check ns16x50_deinit(void *arg)
+{
+    struct vuart_ns16x50 *vdev = arg;
+
+    ASSERT(vdev);
+}
+
+static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info)
+{
+    struct vuart_ns16x50 *vdev;
+    int rc;
+
+    if ( !is_hvm_domain(d) )
+    {
+        ns16x50_err(info, "not an HVM domain\n");
+        return ERR_PTR(-ENOSYS);
+    }
+
+    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
+    {
+        ns16x50_err(info, "already registered\n");
+        return ERR_PTR(-EBUSY);
+    }
+
+    vdev = xvzalloc(typeof(*vdev));
+    if ( !vdev )
+    {
+        ns16x50_err(info, "failed to allocate memory\n");
+        return ERR_PTR(-ENOMEM);
+    }
+
+    spin_lock_init(&vdev->lock);
+    vdev->name = info->name;
+    vdev->owner = d;
+    vdev->info = info;
+
+    rc = ns16x50_init(vdev);
+    if ( rc )
+    {
+        xvfree(vdev);
+        return ERR_PTR(rc);
+    }
+
+    return vdev;
+}
+
+static void cf_check ns16x50_free(void *arg)
+{
+    if ( arg )
+        ns16x50_deinit(arg);
+
+    xvfree(arg);
+}
+
+#define ns16x50_emulator                \
+{                                       \
+    .compatible = "ns16550",            \
+    .alloc      = ns16x50_alloc,        \
+    .free       = ns16x50_free,         \
+    .dump_state = NULL,                 \
+    .put_rx     = NULL,                 \
+}
+
+VUART_REGISTER(ns16x50, ns16x50_emulator);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115537.1462115 (Exim 4.92)
	(envelope-from )
	id 1uvj9a-0008QR-3e; Mon, 08 Sep 2025 21:11:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115537.1462115; Mon, 08 Sep 2025 21:11: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 1uvj9Z-0008QI-To; Mon, 08 Sep 2025 21:11:57 +0000
Received: by outflank-mailman (input) for mailman id 1115537;
 Mon, 08 Sep 2025 21:11:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9Y-0008DO-Su
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:11:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9Y-000FSp-1Q;
 Mon, 08 Sep 2025 21:11:56 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9Y-000gKu-1d;
 Mon, 08 Sep 2025 21:11: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=NWRpmqJhOTOIY3zhSnhQ9LFHXgJeUqzoWYVvV58DwuQ=; b=QfQCzboiEv5kPwQ8hac1qgJUSu
	WVT/GvMWfIpHz9k78XZcH5ZjiWa0/w3fE0w+ifdBNX1vYlvmkYN8zxvgnmrnS2TiEmvpU/jAlGYK/
	b9CiyvuZljKoLIOkOO2Gpspcp9y58R1u42i8fEpj4L12/LRDZvmH5oK4A7FCJrLVpx8Q=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 04/16] emul/ns16x50: implement DLL/DLM registers
Date: Mon,  8 Sep 2025 14:11:37 -0700
Message-ID: <20250908211149.279143-5-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add DLL/DLM registers emulation.

DLL/DLM registers report hardcoded 115200 baud rate to the guest OS.

Add stub for ns16x50_dlab_get() helper.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- added default registers handling for non-DLL/DLM accesses
- used UINT8_MAX
---
 xen/common/emul/vuart/ns16x50.c | 47 +++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index a3bdf9f415ca..da8583a1dc93 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -96,8 +96,22 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 static int ns16x50_io_write8(
     struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
 {
+    uint8_t *regs = vdev->regs;
+    uint8_t val = *data;
     int rc = 0;
 
+    if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
+        regs[NS16X50_REGS_NUM + reg] = val;
+    else
+    {
+        switch ( reg )
+        {
+        default:
+            rc = -EINVAL;
+            break;
+        }
+    }
+
     return rc;
 }
 
@@ -108,8 +122,16 @@ static int ns16x50_io_write8(
 static int ns16x50_io_write16(
     struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
 {
+    uint16_t val = *data;
     int rc = -EINVAL;
 
+    if ( ns16x50_dlab_get(vdev) && reg == UART_DLL )
+    {
+        vdev->regs[NS16X50_REGS_NUM + UART_DLL] = val & UINT8_MAX;
+        vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (val >> 8) & UINT8_MAX;
+        rc = 0;
+    }
+
     return rc;
 }
 
@@ -145,9 +167,22 @@ static int ns16x50_io_write(
 static int ns16x50_io_read8(
     struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
 {
+    uint8_t *regs = vdev->regs;
     uint8_t val = UINT8_MAX;
     int rc = 0;
 
+    if ( ns16x50_dlab_get(vdev) && (reg == UART_DLL || reg == UART_DLM) )
+        val = regs[NS16X50_REGS_NUM + reg];
+    else
+    {
+        switch ( reg )
+        {
+        default:
+            rc = -EINVAL;
+            break;
+        }
+    }
+
     *data = val;
 
     return rc;
@@ -162,6 +197,13 @@ static int ns16x50_io_read16(
     uint16_t val = UINT16_MAX;
     int rc = -EINVAL;
 
+    if ( ns16x50_dlab_get(vdev) && reg == UART_DLL )
+    {
+        val = vdev->regs[NS16X50_REGS_NUM + UART_DLM] << 8 |
+              vdev->regs[NS16X50_REGS_NUM + UART_DLL];
+        rc = 0;
+    }
+
     *data = val;
 
     return rc;
@@ -278,12 +320,17 @@ out:
 
 static int ns16x50_init(void *arg)
 {
+    const uint16_t divisor = (UART_CLOCK_HZ / 115200) >> 4;
     struct vuart_ns16x50 *vdev = arg;
     const struct vuart_info *info = vdev->info;
     struct domain *d = vdev->owner;
 
     ASSERT(vdev);
 
+    /* NB: report 115200 baud rate. */
+    vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & UINT8_MAX;
+    vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & UINT8_MAX;
+
     register_portio_handler(d, info->base_addr, info->size, ns16x50_io_handle);
 
     return 0;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115541.1462154 (Exim 4.92)
	(envelope-from )
	id 1uvj9f-00016g-FO; Mon, 08 Sep 2025 21:12:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115541.1462154; Mon, 08 Sep 2025 21:12: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 1uvj9f-00016P-AW; Mon, 08 Sep 2025 21:12:03 +0000
Received: by outflank-mailman (input) for mailman id 1115541;
 Mon, 08 Sep 2025 21:12:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9d-0000kF-4U
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9c-000FTf-2g;
 Mon, 08 Sep 2025 21:12:00 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9c-000gMQ-2t;
 Mon, 08 Sep 2025 21:12: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=mgBIXJuIz84mlcqZHiPSZTYiEqMID1sT7aaSFn+Fx+Y=; b=63xdtqy6k03JSFof0Lbgh4XeuR
	ULTNEZGFh9DRKh7kf/CV7uOWmckNLYqbfkwDzXbCazUMUk42eF6sj6K5LvvtVvUwlHiCQgQDNsQnR
	hnW1ip1rPrqyA/aH4vExgy6ojzr9wcL6kWpLurWwYJpmyfPVbstN+o1QGdFHZftj+NWE=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 08/16] emul/ns16x50: implement MCR/MSR registers
Date: Mon,  8 Sep 2025 14:11:41 -0700
Message-ID: <20250908211149.279143-9-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add MCR/MSR registers emulation to the I/O port handler.

Add implementation of ns16x50_iir_check_msi().

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- fixed UART_MSR_TERI handling
---
 xen/common/emul/vuart/ns16x50.c | 62 ++++++++++++++++++++++++++++++++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 0831a576cd9e..fdc20124d4c9 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -107,7 +107,7 @@ static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
 
 static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
 }
 
 /*
@@ -232,12 +232,63 @@ static int ns16x50_io_write8(
             regs[UART_LCR] = val;
             break;
 
+        case UART_MCR: {
+            uint8_t msr_curr, msr_next, msr_delta;
+
+            msr_curr = regs[UART_MSR];
+            msr_next = 0;
+            msr_delta = 0;
+
+            if ( val & UART_MCR_RSRVD0 )
+                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x\n",
+                             UART_MCR_RSRVD0);
+
+            if ( val & UART_MCR_TCRTLR )
+                ns16x50_warn(vdev, "MCR: not supported: %x\n",
+                             UART_MCR_TCRTLR);
+
+            if ( val & UART_MCR_RSRVD1 )
+                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x\n",
+                             UART_MCR_RSRVD1);
+
+            /* Set modem status */
+            if ( val & UART_MCR_LOOP )
+            {
+                if ( val & UART_MCR_DTR )
+                    msr_next |= UART_MSR_DSR;
+                if ( val & UART_MCR_RTS )
+                    msr_next |= UART_MSR_CTS;
+                if ( val & UART_MCR_OUT1 )
+                    msr_next |= UART_MSR_RI;
+                if ( val & UART_MCR_OUT2 )
+                    msr_next |= UART_MSR_DCD;
+            }
+            else
+                msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
+
+            /* Calculate changes in modem status */
+            if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
+                msr_delta |= UART_MSR_DCTS;
+            if ( (msr_curr & UART_MSR_DSR) ^ (msr_next & UART_MSR_DSR) )
+                msr_delta |= UART_MSR_DDSR;
+            if ( !(msr_curr & UART_MSR_RI) && (msr_next & UART_MSR_RI) )
+                msr_delta |= UART_MSR_TERI;
+            if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
+                msr_delta |= UART_MSR_DDCD;
+
+            regs[UART_MCR] = val & UART_MCR_MASK;
+            regs[UART_MSR] = msr_next | msr_delta;
+
+            break;
+        }
+
         /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
         case UART_SCR:
             regs[UART_SCR] = val;
             break;
 
         case UART_LSR: /* RO */
+        case UART_MSR: /* RO */
         default:
             rc = -EINVAL;
             break;
@@ -323,11 +374,20 @@ static int ns16x50_io_read8(
             val = regs[UART_LCR];
             break;
 
+        case UART_MCR:
+            val = regs[UART_MCR];
+            break;
+
         case UART_LSR:
             val = regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
             regs[UART_LSR] = val & ~UART_LSR_MASK;
             break;
 
+        case UART_MSR:
+            val = regs[UART_MSR];
+            regs[UART_MSR] &= ~UART_MSR_CHANGE;
+            break;
+
         case UART_SCR:
             val = regs[UART_SCR];
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115542.1462159 (Exim 4.92)
	(envelope-from )
	id 1uvj9g-0001BX-10; Mon, 08 Sep 2025 21:12:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115542.1462159; Mon, 08 Sep 2025 21:12: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 1uvj9f-0001AG-Nw; Mon, 08 Sep 2025 21:12:03 +0000
Received: by outflank-mailman (input) for mailman id 1115542;
 Mon, 08 Sep 2025 21:12:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9e-0000zQ-53
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9d-000FU1-2x;
 Mon, 08 Sep 2025 21:12:01 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9d-000gMV-3B;
 Mon, 08 Sep 2025 21:12: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=sJw6viqpsDfMS5MRma9QK/++3SeyoW0ownBjjeYeZKo=; b=Zqr8zJltVqZnjQMSoCh8s/n1nd
	+xuQYSproeuFQMambh3zctjtcQW64xcEIRma5q/s4hI7FmFGIYPU+XtPnX9Nxuu+rGZ/1NkXYzHew
	YsVmI/C5mtSEsEd8Z/256c+5QN0GkArjOCIlBP9tJ+ohtvhAumN64SR3dFQb+99ZeCt0=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 09/16] emul/ns16x50: implement RBR register
Date: Mon,  8 Sep 2025 14:11:42 -0700
Message-ID: <20250908211149.279143-10-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add RBR register emulation to the I/O port handlder.

Add RX FIFO management code since RBR depends on RX FIFO.

RX FIFO is not emulated as per UART specs for simplicity (not need to emulate
baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
NS16750 (64 bytes).

RX FIFO is emulated by means of using xencons_interface which conveniently
provides primitives for buffer management and later can be used for
inter-domain communication similarly to vpl011.

Account for DLL == 0: in this case, disable receiver.

Add UART_LSR_DR handling since it depends on RBR register access.

Finally, implement put_rx() vUART hook for placing a character into the
emulated RX FIFO from console driver. That implements physical console
forwarding to the guest OS over emulated NS16550.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- added DLL == 0 case handling as per Mykola's suggestion
---
 xen/common/emul/vuart/ns16x50.c | 134 +++++++++++++++++++++++++++++++-
 1 file changed, 132 insertions(+), 2 deletions(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index fdc20124d4c9..250411e0a7d8 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -9,6 +9,8 @@
  *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
  * - UART w/ 64 byte FIFO:
  *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
+ * - DesignWare DW_apb_uart Databook, v4.02a:
+ *     https://iccircle.com/static/upload/img20240313113905.pdf
  *
  * Limitations:
  * - Only x86;
@@ -85,6 +87,74 @@ struct vuart_ns16x50 {
     struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
 };
 
+static bool ns16x50_fifo_rx_empty(const struct vuart_ns16x50 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->in_prod == cons->in_cons;
+}
+
+static bool ns16x50_fifo_rx_full(const struct vuart_ns16x50 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->in_prod - cons->in_cons == ARRAY_SIZE(cons->in);
+}
+
+static void ns16x50_fifo_rx_reset(struct vuart_ns16x50 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    cons->in_cons = cons->in_prod;
+}
+
+/*
+ * Transfer character from RX FIFO and return the RX FIFO status after the
+ * transfer.
+ */
+static int ns16x50_fifo_rx_getchar(struct vuart_ns16x50 *vdev, uint8_t *ptr)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    if ( ns16x50_fifo_rx_empty(vdev) )
+        return -ENODATA;
+
+    *ptr = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
+    cons->in_cons++;
+
+    return ns16x50_fifo_rx_empty(vdev) ? -ENODATA : 0;
+}
+
+static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
+{
+    struct xencons_interface *cons = &vdev->cons;
+    int rc;
+
+    /*
+     * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents
+     * of the THR.
+     */
+    if ( ns16x50_fifo_rx_full(vdev) )
+    {
+        ns16x50_debug(vdev, "RX FIFO full; resetting\n");
+        ns16x50_fifo_rx_reset(vdev);
+        rc = -ENOSPC;
+    }
+    else
+        rc = 0;
+
+    cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c;
+    cons->in_prod++;
+
+    return rc;
+}
+
+static bool ns16x50_is_running(const struct vuart_ns16x50 *vdev)
+{
+    /* DLL set to 0 disables serial communication. */
+    return vdev->regs[NS16X50_REGS_NUM + UART_DLL];
+}
+
 static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
 {
     return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
@@ -97,7 +167,7 @@ static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *vdev)
 
 static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return !ns16x50_fifo_rx_empty(vdev);
 }
 
 static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
@@ -362,6 +432,20 @@ static int ns16x50_io_read8(
     {
         switch ( reg )
         {
+        case UART_RBR:
+            if ( !ns16x50_is_running(vdev) )
+                break;
+
+            /* NB: do not forget to clear overrun condition */
+            regs[UART_LSR] &= ~UART_LSR_OE;
+
+            if ( ns16x50_fifo_rx_getchar(vdev, &val) )
+                regs[UART_LSR] &= ~UART_LSR_DR;
+            else
+                regs[UART_LSR] |= UART_LSR_DR;
+
+            break;
+
         case UART_IER:
             val = regs[UART_IER];
             break;
@@ -611,13 +695,59 @@ static void cf_check ns16x50_free(void *arg)
     xvfree(arg);
 }
 
+static int cf_check ns16x50_put_rx(void *arg, char ch)
+{
+    struct vuart_ns16x50 *vdev = arg;
+    uint8_t *regs;
+    uint8_t dlab;
+    int rc = -EBUSY;
+
+    spin_lock(&vdev->lock);
+
+    dlab = ns16x50_dlab_get(vdev);
+    regs = vdev->regs;
+
+    if ( !ns16x50_is_running(vdev) )
+        ns16x50_debug(vdev, "THR/RBR access disabled: DLL == 0\n");
+    else if ( dlab )
+        ns16x50_debug(vdev, "THR/RBR access disabled: DLAB=1\n");
+    else if ( regs[UART_MCR] & UART_MCR_LOOP )
+        ns16x50_debug(vdev, "THR/RBR access disabled: loopback mode\n");
+    else
+    {
+        const struct domain *d = vdev->owner;
+
+        /*
+         * Echo the user input on Xen console iff Xen console input is owned
+         * by ns16x50 domain.
+         * NB: use 'console_timestamps=none' to disable Xen timestamps.
+         */
+        if ( is_console_printable(ch) )
+            guest_printk(d, "%c", ch);
+
+        if ( ns16x50_fifo_rx_putchar(vdev, ch) )
+            regs[UART_LSR] |= UART_LSR_OE;
+
+        regs[UART_LSR] |= UART_LSR_DR;
+
+        /* TODO: check FCR when to fire an interrupt */
+        ns16x50_irq_check(vdev);
+
+        rc = 0;
+    }
+
+    spin_unlock(&vdev->lock);
+
+    return rc;
+}
+
 #define ns16x50_emulator                \
 {                                       \
     .compatible = "ns16550",            \
     .alloc      = ns16x50_alloc,        \
     .free       = ns16x50_free,         \
     .dump_state = NULL,                 \
-    .put_rx     = NULL,                 \
+    .put_rx     = ns16x50_put_rx,       \
 }
 
 VUART_REGISTER(ns16x50, ns16x50_emulator);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115543.1462166 (Exim 4.92)
	(envelope-from )
	id 1uvj9g-0001Iy-Rh; Mon, 08 Sep 2025 21:12:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115543.1462166; Mon, 08 Sep 2025 21:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9g-0001Fi-8N; Mon, 08 Sep 2025 21:12:04 +0000
Received: by outflank-mailman (input) for mailman id 1115543;
 Mon, 08 Sep 2025 21:12:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9f-000164-7u
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9f-000FUE-01;
 Mon, 08 Sep 2025 21:12:03 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9f-000gN1-0G;
 Mon, 08 Sep 2025 21:12: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=b4hUxqYghrvWW5yLlDTNdgPS7IjF5GT2QqKNV0EctlI=; b=JkzGM+cpJE/hIL99ZEjDEJcHoH
	vkoNQIP/dyxrYsu5nhCithcAwxfUYQLUS7gngL77ITVYpL0r+M1SqzjE6QnVVZIQp29ciVAqT7iTp
	QMgUIJvFNj8p0PQBzJIiBeCA44D8O/i8+r2E15UUxTxNIp0am0JLwQ0DTYvO2mWJ5W1Q=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 10/16] emul/ns16x50: implement THR register
Date: Mon,  8 Sep 2025 14:11:43 -0700
Message-ID: <20250908211149.279143-11-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add THR register emulation to the I/O port handlder.

Add TX FIFO management code since THR depends on TX FIFO.

TX FIFOs is not emulated as per UART specs for simplicity (not need to emulate
baud rate). Emulator does not emulate NS8250 (no FIFO), NS16550a (16 bytes) or
NS16750 (64 bytes).

TX FIFOs is emulated by using xencons_interface which conveniently provides
primitives for buffer management and later can be used for inter-domain
communication similarly to vpl011.

Account for DLL == 0: in this case, disable transmitter.

Add UART_IIR_THR interrupt reason handling since it depends on THR register
access.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- added DLL == 0 case handling as per Mykola's suggestion
- dropped UART_IIR_THR clearing in UART_IIR register emulation in ns16x50_io_write8()
- simplified UART_IIR_THR handling
- updated ns16x50_iir_check_thr()
---
 xen/common/emul/vuart/ns16x50.c | 82 ++++++++++++++++++++++++++++++++-
 1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 250411e0a7d8..137ce08f4e1d 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -149,6 +149,66 @@ static int ns16x50_fifo_rx_putchar(struct vuart_ns16x50 *vdev, char c)
     return rc;
 }
 
+static bool ns16x50_fifo_tx_full(const struct vuart_ns16x50 *vdev)
+{
+    const struct xencons_interface *cons = &vdev->cons;
+
+    return cons->out_prod - cons->out_cons == ARRAY_SIZE(cons->out);
+}
+
+static void ns16x50_fifo_tx_reset(struct vuart_ns16x50 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    cons->out_cons = cons->out_prod;
+}
+
+/*
+ * Flush cached output to Xen console.
+ */
+static void ns16x50_fifo_tx_flush(struct vuart_ns16x50 *vdev)
+{
+    struct xencons_interface *cons = &vdev->cons;
+    struct domain *d = vdev->owner;
+    XENCONS_RING_IDX i, n, len = cons->out_prod - cons->out_cons;
+
+    ASSERT(len <= ARRAY_SIZE(cons->out));
+    if ( !len )
+        return;
+
+    i = MASK_XENCONS_IDX(cons->out_cons, cons->out);
+    n = min_t(XENCONS_RING_IDX, len, ARRAY_SIZE(cons->out) - i);
+    if ( n )
+        guest_printk(d, guest_prefix "%.*s", n, &cons->out[i]);
+
+    i = 0;
+    n = len - n;
+    if ( n )
+        guest_printk(d, guest_prefix "%.*s", n, &cons->out[i]);
+
+    cons->out_cons += len;
+}
+
+/*
+ * Accumulate guest OS output before sending to Xen console.
+ */
+static void ns16x50_fifo_tx_putchar(struct vuart_ns16x50 *vdev, char ch)
+{
+    struct xencons_interface *cons = &vdev->cons;
+
+    if ( !is_console_printable(ch) )
+        return;
+
+    if ( !ns16x50_fifo_tx_full(vdev) )
+    {
+        cons->out[MASK_XENCONS_IDX(cons->out_prod, cons->out)] = ch;
+        cons->out_prod++;
+    }
+
+    if ( ch == '\n' || ch == '\0' || ns16x50_fifo_tx_full(vdev) )
+        ns16x50_fifo_tx_flush(vdev);
+}
+
 static bool ns16x50_is_running(const struct vuart_ns16x50 *vdev)
 {
     /* DLL set to 0 disables serial communication. */
@@ -172,7 +232,7 @@ static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *vdev)
 
 static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
 {
-    return false;
+    return !ns16x50_fifo_tx_full(vdev);
 }
 
 static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
@@ -294,6 +354,22 @@ static int ns16x50_io_write8(
     {
         switch ( reg )
         {
+        case UART_THR:
+            if ( !ns16x50_is_running(vdev) )
+                break;
+
+            if ( regs[UART_MCR] & UART_MCR_LOOP )
+            {
+                if ( ns16x50_fifo_rx_putchar(vdev, val) )
+                    regs[UART_LSR] |= UART_LSR_OE;
+
+                regs[UART_LSR] |= UART_LSR_DR;
+            }
+            else
+                ns16x50_fifo_tx_putchar(vdev, val);
+
+            break;
+
         case UART_IER:
             regs[UART_IER] = val & UART_IER_MASK;
             break;
@@ -646,6 +722,10 @@ static void cf_check ns16x50_deinit(void *arg)
     struct vuart_ns16x50 *vdev = arg;
 
     ASSERT(vdev);
+
+    spin_lock(&vdev->lock);
+    ns16x50_fifo_tx_flush(vdev);
+    spin_unlock(&vdev->lock);
 }
 
 static void * cf_check ns16x50_alloc(struct domain *d, const struct vuart_info *info)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115545.1462180 (Exim 4.92)
	(envelope-from )
	id 1uvj9i-0001mh-FE; Mon, 08 Sep 2025 21:12:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115545.1462180; Mon, 08 Sep 2025 21: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 1uvj9i-0001ke-4k; Mon, 08 Sep 2025 21:12:06 +0000
Received: by outflank-mailman (input) for mailman id 1115545;
 Mon, 08 Sep 2025 21:12:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9g-0001J0-Dc
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9g-000FUS-0K;
 Mon, 08 Sep 2025 21:12:04 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9g-000gNA-0Y;
 Mon, 08 Sep 2025 21:12: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=jOrpkPK6Y2sHbIx1Zg9cP39ItjKVIpi7DD14BHDTv7c=; b=Lfpk1ztSq/H6d4MF6OefdVvZPK
	w0S23FSr2I7VTRlJ3WqXyhnrHSQi6Wi0Y/eYi7ID25udDhzcaU1A1ii4O4KYNs1HreBVQL10atV0S
	RVOISIqsZ1fyb1yANVnZij9IYm/AxoGDn1JaMyvOvMfocfx3+pwVU04CBFB9HkNw0QBQ=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 11/16] emul/ns16x50: implement FCR register (write-only)
Date: Mon,  8 Sep 2025 14:11:44 -0700
Message-ID: <20250908211149.279143-12-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add emulation logic for FCR register.

Note, that does not hook FIFO interrupt moderation to the FIFO management
code for simplicity.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- dropped UART_IIR_THR handling from UART_FCR_CLTX case
---
 xen/common/emul/vuart/ns16x50.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 137ce08f4e1d..a92df6923aa5 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -374,6 +374,33 @@ static int ns16x50_io_write8(
             regs[UART_IER] = val & UART_IER_MASK;
             break;
 
+        case UART_FCR: /* WO */
+            if ( val & UART_FCR_RSRVD0 )
+                ns16x50_warn(vdev, "FCR: attempt to set reserved bit: %x\n",
+                             UART_FCR_RSRVD0);
+
+            if ( val & UART_FCR_RSRVD1 )
+                ns16x50_warn(vdev, "FCR: attempt to set reserved bit: %x\n",
+                             UART_FCR_RSRVD1);
+
+            if ( val & UART_FCR_CLRX )
+            {
+                ns16x50_fifo_rx_reset(vdev);
+                regs[UART_LSR] &= ~UART_LSR_DR;
+            }
+
+            if ( val & UART_FCR_CLTX )
+                ns16x50_fifo_tx_reset(vdev);
+
+            if ( val & UART_FCR_ENABLE )
+                val &= UART_FCR_ENABLE | UART_FCR_DMA | UART_FCR_TRG_MASK;
+            else
+                val = 0;
+
+            regs[UART_FCR] = val;
+
+            break;
+
         case UART_LCR:
             regs[UART_LCR] = val;
             break;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115548.1462186 (Exim 4.92)
	(envelope-from )
	id 1uvj9j-0001w4-DY; Mon, 08 Sep 2025 21:12:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115548.1462186; Mon, 08 Sep 2025 21:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9i-0001u1-R9; Mon, 08 Sep 2025 21:12:06 +0000
Received: by outflank-mailman (input) for mailman id 1115548;
 Mon, 08 Sep 2025 21:12:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9h-0001ZP-Eu
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9h-000FUh-0d;
 Mon, 08 Sep 2025 21:12:05 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9h-000gNK-0r;
 Mon, 08 Sep 2025 21: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=QW9I8ZuXBd/H3nKRB+tcF6FvOZaI6qXJPw/5aA/9wEw=; b=IJaIKbhghKRi/SM12NScR/FphI
	s/Rly6SBlOFXqgntn1c8D5VaEMrgqlSxjqF6UixnMd4Y2mt+ybpVS+vI7Qy0NJ2PMX5odVIlUUjES
	yNIZQQehjJoDscx1Jv3fuKaGu6reRySzIVv7T/QgjjY1wDgZuwzQ8NMnlhh6eA1/y+P8=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 12/16] emul/ns16550: implement dump_state() hook
Date: Mon,  8 Sep 2025 14:11:45 -0700
Message-ID: <20250908211149.279143-13-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Implement dump_state() vUART hook for debugging UART state machine over Xen
console. dump_state() prints state of all emulated registers (including
state-less IIR) and state of RX/TX FIFOs.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- n/a
---
 xen/common/emul/vuart/ns16x50.c | 59 ++++++++++++++++++++++++++++++++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index a92df6923aa5..c341f012d005 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -640,6 +640,58 @@ static int ns16x50_io_read(
     return rc;
 }
 
+static void cf_check ns16x50_dump_state(void *arg)
+{
+#ifdef CONFIG_VUART_NS16X50_DEBUG
+    struct vuart_ns16x50 *vdev = arg;
+    const struct domain *d = vdev->owner;
+    const struct vuart_info *info = vdev->info;
+    const struct xencons_interface *cons;
+    const uint8_t *regs;
+
+    if ( !vdev )
+        return;
+
+    /* Allow printing state in case of a deadlock. */
+    if ( !spin_trylock(&vdev->lock) )
+        return;
+
+    cons = &vdev->cons;
+    regs = &vdev->regs[0];
+
+    printk("Virtual " pr_prefix " (%s) I/O port 0x%04x IRQ#%d owner %pd\n",
+            vdev->name, info->base_addr, info->irq, d);
+
+    printk("  RX FIFO size %ld in_prod %d in_cons %d used %d\n",
+            ARRAY_SIZE(cons->in), cons->in_prod, cons->in_cons,
+            cons->in_prod - cons->in_cons);
+
+    printk("  TX FIFO size %ld out_prod %d out_cons %d used %d\n",
+            ARRAY_SIZE(cons->out), cons->out_prod, cons->out_cons,
+            cons->out_prod - cons->out_cons);
+
+    printk("  %02"PRIx8" RBR %02"PRIx8" THR %02"PRIx8" DLL %02"PRIx8" DLM %02"PRIx8"\n",
+            UART_RBR,
+            cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)],
+            cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)],
+            regs[NS16X50_REGS_NUM + UART_DLL],
+            regs[NS16X50_REGS_NUM + UART_DLM]);
+
+    printk("  %02"PRIx8" IER %02"PRIx8"\n", UART_IER, regs[UART_IER]);
+
+    printk("  %02"PRIx8" FCR %02"PRIx8" IIR %02"PRIx8"\n",
+            UART_FCR, regs[UART_FCR], ns16x50_iir_get(vdev));
+
+    printk("  %02"PRIx8" LCR %02"PRIx8"\n", UART_LCR, regs[UART_LCR]);
+    printk("  %02"PRIx8" MCR %02"PRIx8"\n", UART_MCR, regs[UART_MCR]);
+    printk("  %02"PRIx8" LSR %02"PRIx8"\n", UART_LSR, regs[UART_LSR]);
+    printk("  %02"PRIx8" MSR %02"PRIx8"\n", UART_MSR, regs[UART_MSR]);
+    printk("  %02"PRIx8" SCR %02"PRIx8"\n", UART_SCR, regs[UART_SCR]);
+
+    spin_unlock(&vdev->lock);
+#endif /* CONFIG_VUART_NS16X50_DEBUG */
+}
+
 /*
  * Emulate I/O access to ns16x50 register.
  * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is enabled.
@@ -709,6 +761,9 @@ static int cf_check ns16x50_io_handle(
 
     spin_unlock(&vdev->lock);
 
+    if ( ns16x50_log_level >= 3 )
+        ns16x50_dump_state(vdev);
+
     if ( rc == 0 )
         ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=%d %02"PRIx32" 0x%08"PRIx32"\n",
                       op, addr, size, dlab, reg, *data);
@@ -844,6 +899,8 @@ static int cf_check ns16x50_put_rx(void *arg, char ch)
     }
 
     spin_unlock(&vdev->lock);
+    if ( ns16x50_log_level >= 3 )
+        ns16x50_dump_state(vdev);
 
     return rc;
 }
@@ -853,7 +910,7 @@ static int cf_check ns16x50_put_rx(void *arg, char ch)
     .compatible = "ns16550",            \
     .alloc      = ns16x50_alloc,        \
     .free       = ns16x50_free,         \
-    .dump_state = NULL,                 \
+    .dump_state = ns16x50_dump_state,   \
     .put_rx     = ns16x50_put_rx,       \
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115549.1462196 (Exim 4.92)
	(envelope-from )
	id 1uvj9k-0002Kn-Qs; Mon, 08 Sep 2025 21:12:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115549.1462196; Mon, 08 Sep 2025 21:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9k-0002Io-LB; Mon, 08 Sep 2025 21:12:08 +0000
Received: by outflank-mailman (input) for mailman id 1115549;
 Mon, 08 Sep 2025 21:12:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9i-0001qT-Hl
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9i-000FUt-0w;
 Mon, 08 Sep 2025 21:12:06 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9i-000gNQ-1A;
 Mon, 08 Sep 2025 21:12: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=KkUN0OllhKW27ZmsCBHTtMD+F/9dKnn+1KTiUiwT17c=; b=GbGd+yPlZZoKbzzS07p93lgEKd
	/XZqka49ao5ewWmTypg9sYU4phrlCfNqN+m1E/I6ATWtAkUxLj73rA7X57HPCylyyr9Q9vb4PkpWo
	2PbzxoE11vg7Quxvny1g5Fn3hvcYiiFttggU2fx6GUYMhvyFlbejQLc3Qz3JyREeIsV8=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 13/16] emul/ns16x50: add Kconfig options
Date: Mon,  8 Sep 2025 14:11:46 -0700
Message-ID: <20250908211149.279143-14-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add initial Kconfig options configure NS16550-capable emulator.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- new patch
---
 xen/common/emul/vuart/Kconfig | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfig
index ce1b976b7da7..9a49a6528b5a 100644
--- a/xen/common/emul/vuart/Kconfig
+++ b/xen/common/emul/vuart/Kconfig
@@ -3,4 +3,23 @@ config VUART_FRAMEWORK
 
 menu "UART Emulation"
 
+config VUART_NS16X50
+	bool "NS16550-compatible UART Emulator" if EXPERT
+	depends on X86 && HVM
+	select VUART_FRAMEWORK
+	help
+	  In-hypervisor NS16550-compatible UART emulation.
+
+	  Only one legacy PC COM port is emulated for domain with a certain ID
+	  (set via 'vuart-domid=' command line setting).
+
+	  This is strictly for testing purposes (such as early HVM guest console),
+	  and not appropriate for use in production.
+
+config VUART_NS16X50_DEBUG
+	bool "Development: NS16550-compatible UART Emulator Debugging"
+	depends on VUART_NS16X50 && DEBUG
+	help
+	  Enable development debugging.
+
 endmenu
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115553.1462208 (Exim 4.92)
	(envelope-from )
	id 1uvj9m-0002km-Om; Mon, 08 Sep 2025 21:12:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115553.1462208; Mon, 08 Sep 2025 21: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 1uvj9m-0002i6-AN; Mon, 08 Sep 2025 21:12:10 +0000
Received: by outflank-mailman (input) for mailman id 1115553;
 Mon, 08 Sep 2025 21:12:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9j-00023q-MO
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9j-000FV9-1X;
 Mon, 08 Sep 2025 21:12:07 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9j-000gNW-1U;
 Mon, 08 Sep 2025 21: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=bDnknz7r88crgl/cPA1cLrvLlvrN6IJa2LZ7XeWLxFY=; b=5R2c/NewHRd1WLlL/YZ719Dfzg
	s+zc/RpjjywnrIRSJ0Tu5WlRb4JNFYPB2rJ4XCg5rRka1yqh5vNuW/8tp/V9lRmpmBdHxYUhwFAnu
	+mPjSskJkNDpPHD4Wf+9oPpUWnodUVntU+MgBxoIROSUiKABfRPPd4JLyfGw7aQhRPyc=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 14/16] x86/domain: enable per-domain I/O port bitmaps
Date: Mon,  8 Sep 2025 14:11:47 -0700
Message-ID: <20250908211149.279143-15-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Current design enables all HVM domains share the same I/O port bitmap.

It is necessary for domains crafting its own I/O port address space depending
on the user configuration.

Ensure NS16550 emulator does not share I/O ports with the physical I/O ports,
which is essential for emulation in PVH hwdom case (dom0).

Not a functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- n/a
---
 xen/arch/x86/Makefile                    |   1 +
 xen/arch/x86/dom0_build.c                | 111 +--------------
 xen/arch/x86/hvm/hvm.c                   |  35 +----
 xen/arch/x86/hvm/nestedhvm.c             |   8 +-
 xen/arch/x86/hvm/quirks.c                |   3 -
 xen/arch/x86/hvm/svm/nestedsvm.c         |   2 +-
 xen/arch/x86/hvm/vmx/vvmx.c              |   4 +-
 xen/arch/x86/include/asm/hvm/nestedhvm.h |   3 +-
 xen/arch/x86/include/asm/hvm/support.h   |   2 -
 xen/arch/x86/include/asm/iocap.h         |   2 +
 xen/arch/x86/ioport.c                    | 163 +++++++++++++++++++++++
 xen/arch/x86/pv/dom0_build.c             |   4 +
 xen/common/emul/vuart/ns16x50.c          |  11 ++
 13 files changed, 200 insertions(+), 149 deletions(-)
 create mode 100644 xen/arch/x86/ioport.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d7aed7d92c15..85a8475e126c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -44,6 +44,7 @@ obj-y += msi.o
 obj-y += msr.o
 obj-$(CONFIG_INDIRECT_THUNK) += indirect-thunk.o
 obj-$(CONFIG_RETURN_THUNK) += indirect-thunk.o
+obj-y += ioport.o
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4fc..26202b33345c 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -298,9 +298,6 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
     return 0;
 }
 
-static char __initdata opt_dom0_ioports_disable[200] = "";
-string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
-
 static bool __initdata ro_hpet = true;
 boolean_param("ro-hpet", ro_hpet);
 
@@ -433,122 +430,20 @@ unsigned long __init dom0_compute_nr_pages(
     return nr_pages;
 }
 
-static void __init process_dom0_ioports_disable(struct domain *dom0)
-{
-    unsigned long io_from, io_to;
-    char *t, *s = opt_dom0_ioports_disable;
-    const char *u;
-
-    if ( *s == '\0' )
-        return;
-
-    while ( (t = strsep(&s, ",")) != NULL )
-    {
-        io_from = simple_strtoul(t, &u, 16);
-        if ( u == t )
-        {
-        parse_error:
-            printk("Invalid ioport range <%s> "
-                   "in dom0_ioports_disable, skipping\n", t);
-            continue;
-        }
-
-        if ( *u == '\0' )
-            io_to = io_from;
-        else if ( *u == '-' )
-            io_to = simple_strtoul(u + 1, &u, 16);
-        else
-            goto parse_error;
-
-        if ( (*u != '\0') || (io_to < io_from) || (io_to >= 65536) )
-            goto parse_error;
-
-        printk("Disabling dom0 access to ioport range %04lx-%04lx\n",
-            io_from, io_to);
-
-        if ( ioports_deny_access(dom0, io_from, io_to) != 0 )
-            BUG();
-    }
-}
-
+/* Modify I/O memory access permissions. */
 int __init dom0_setup_permissions(struct domain *d)
 {
     unsigned long mfn;
-    unsigned int i, offs;
-    int rc;
+    unsigned int i;
+    int rc = 0;
 
     if ( pv_shim )
         return 0;
 
-    /* The hardware domain is initially permitted full I/O capabilities. */
-    rc = ioports_permit_access(d, 0, 0xFFFF);
     rc |= iomem_permit_access(d, 0UL,
                               PFN_DOWN(1UL << domain_max_paddr_bits(d)) - 1);
     rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
 
-    /* Modify I/O port access permissions. */
-
-    for ( offs = 0, i = ISOLATE_LSB(i8259A_alias_mask) ?: 2;
-          offs <= i8259A_alias_mask; offs += i )
-    {
-        if ( offs & ~i8259A_alias_mask )
-            continue;
-        /* Master Interrupt Controller (PIC). */
-        rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
-        /* Slave Interrupt Controller (PIC). */
-        rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
-    }
-
-    /* ELCR of both PICs. */
-    rc |= ioports_deny_access(d, 0x4D0, 0x4D1);
-
-    /* Interval Timer (PIT). */
-    for ( offs = 0, i = ISOLATE_LSB(pit_alias_mask) ?: 4;
-          offs <= pit_alias_mask; offs += i )
-        if ( !(offs & ~pit_alias_mask) )
-            rc |= ioports_deny_access(d, PIT_CH0 + offs, PIT_MODE + offs);
-
-    /* PIT Channel 2 / PC Speaker Control. */
-    rc |= ioports_deny_access(d, 0x61, 0x61);
-
-    /* INIT# and alternative A20M# control. */
-    rc |= ioports_deny_access(d, 0x92, 0x92);
-
-    /* IGNNE# control. */
-    rc |= ioports_deny_access(d, 0xF0, 0xF0);
-
-    /* ACPI PM Timer. */
-    if ( pmtmr_ioport )
-        rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
-
-    /* Reset control. */
-    rc |= ioports_deny_access(d, 0xCF9, 0xCF9);
-
-    /* PCI configuration space (NB. 0xCF8 has special treatment). */
-    rc |= ioports_deny_access(d, 0xCFC, 0xCFF);
-
-#ifdef CONFIG_HVM
-    if ( is_hvm_domain(d) )
-    {
-        /* ISA DMA controller, channels 0-3 (incl possible aliases). */
-        rc |= ioports_deny_access(d, 0x00, 0x1F);
-        /* ISA DMA controller, page registers (incl various reserved ones). */
-        rc |= ioports_deny_access(d, 0x80 + !!hvm_port80_allowed, 0x8F);
-        /* ISA DMA controller, channels 4-7 (incl usual aliases). */
-        rc |= ioports_deny_access(d, 0xC0, 0xDF);
-
-        /* HVM debug console IO port. */
-        rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
-                                  XEN_HVM_DEBUGCONS_IOPORT);
-        if ( amd_acpi_c1e_quirk )
-            rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
-    }
-#endif
-    /* Command-line I/O ranges. */
-    process_dom0_ioports_disable(d);
-
-    /* Modify I/O memory access permissions. */
-
     /* Local APIC. */
     if ( mp_lapic_addr != 0 )
     {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 363c010f8dcc..1fc16a22e157 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -81,14 +82,6 @@ integer_param("hvm_debug", opt_hvm_debug_level);
 
 struct hvm_function_table __ro_after_init hvm_funcs;
 
-/*
- * The I/O permission bitmap is globally shared by all HVM guests except
- * the hardware domain which needs a more permissive one.
- */
-#define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
-unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
-    hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
-
 /* Xen command-line option to enable HAP */
 static bool __initdata opt_hap_enabled = true;
 boolean_param("hap", opt_hap_enabled);
@@ -266,15 +259,6 @@ static int __init cf_check hvm_enable(void)
     if ( opt_hvm_fep )
         warning_add(warning_hvm_fep);
 
-    /*
-     * Allow direct access to the PC debug ports 0x80 and 0xed (they are
-     * often used for I/O delays, but the vmexits simply slow things down).
-     */
-    memset(hvm_io_bitmap, ~0, sizeof(hvm_io_bitmap));
-    if ( hvm_port80_allowed )
-        __clear_bit(0x80, hvm_io_bitmap);
-    __clear_bit(0xed, hvm_io_bitmap);
-
     register_cpu_notifier(&cpu_nfb);
 
     return 0;
@@ -706,19 +690,12 @@ int hvm_domain_initialise(struct domain *d,
 
     rwlock_init(&d->arch.hvm.pl_time->pt_migrate);
 
-    /* Set the default IO Bitmap. */
-    if ( is_hardware_domain(d) )
+    rc = ioports_setup_access(d);
+    if ( rc )
     {
-        d->arch.hvm.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
-        if ( d->arch.hvm.io_bitmap == NULL )
-        {
-            rc = -ENOMEM;
-            goto fail1;
-        }
-        memset(d->arch.hvm.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
+        printk("%pd failed to setup I/O bitmap: %d\n", d, rc);
+        goto fail1;
     }
-    else
-        d->arch.hvm.io_bitmap = hvm_io_bitmap;
 
     register_g2m_portio_handler(d);
     register_vpci_portio_handler(d);
@@ -745,6 +722,8 @@ int hvm_domain_initialise(struct domain *d,
         break;
     }
 
+    BUG_ON(!d->arch.ioport_caps);
+
     vpic_init(d);
 
     rc = vioapic_init(d);
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index bddd77d8109b..d4e03123d910 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -107,7 +107,7 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
  * The users of the bitmap patterns are in SVM/VMX specific code.
  *
  * bitmap        port 0x80  port 0xed
- * hvm_io_bitmap cleared    cleared
+ * hvm.io_bitmap cleared    cleared
  * iomap[0]      cleared    set
  * iomap[1]      set        cleared
  * iomap[2]      set        set
@@ -115,7 +115,7 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
 
 static int __init cf_check nestedhvm_setup(void)
 {
-    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
+    /* Same format and size as hvm.io_bitmap (Intel needs only 2 pages). */
     unsigned nr = cpu_has_vmx ? 2 : 3;
     unsigned int i, order = get_order_from_pages(nr);
 
@@ -165,7 +165,7 @@ static int __init cf_check nestedhvm_setup(void)
 __initcall(nestedhvm_setup);
 
 unsigned long *
-nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed)
+nestedhvm_vcpu_iomap_get(struct vcpu *v, bool ioport_80, bool ioport_ed)
 {
     int i;
 
@@ -174,7 +174,7 @@ nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed)
 
     if (ioport_80 == 0) {
         if (ioport_ed == 0)
-            return hvm_io_bitmap;
+            return v->domain->arch.hvm.io_bitmap;
         i = 0;
     } else {
         if (ioport_ed == 0)
diff --git a/xen/arch/x86/hvm/quirks.c b/xen/arch/x86/hvm/quirks.c
index 9202f5a47fe9..f4d95441fcff 100644
--- a/xen/arch/x86/hvm/quirks.c
+++ b/xen/arch/x86/hvm/quirks.c
@@ -73,9 +73,6 @@ static int __init cf_check check_port80(void)
 
     dmi_check_system(hvm_no_port80_dmi_table);
 
-    if ( !hvm_port80_allowed )
-        __set_bit(0x80, hvm_io_bitmap);
-
     return 0;
 }
 __initcall(check_port80);
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index dc2b6a42534a..cc8500b61665 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -381,7 +381,7 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
         hvm_unmap_guest_frame(ns_viomap, 0);
     }
 
-    svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
+    svm->ns_iomap = nestedhvm_vcpu_iomap_get(v, ioport_80, ioport_ed);
 
     nv->nv_ioport80 = ioport_80;
     nv->nv_ioportED = ioport_ed;
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index e4f3a5fe4c71..4da3e6e90e6c 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -554,7 +554,7 @@ unsigned long *_shadow_io_bitmap(struct vcpu *v)
     port80 = bitmap[0x80 >> 3] & (1 << (0x80 & 0x7)) ? 1 : 0;
     portED = bitmap[0xed >> 3] & (1 << (0xed & 0x7)) ? 1 : 0;
 
-    return nestedhvm_vcpu_iomap_get(port80, portED);
+    return nestedhvm_vcpu_iomap_get(v, port80, portED);
 }
 
 static void update_msrbitmap(struct vcpu *v, uint32_t shadow_ctrl)
@@ -622,7 +622,7 @@ void nvmx_update_exec_control(struct vcpu *v, u32 host_cntrl)
              * L1 VMM doesn't intercept IO instruction.
              * Use host configuration and reset IO_BITMAP
              */
-            bitmap = hvm_io_bitmap;
+            bitmap = v->domain->arch.hvm.io_bitmap;
         }
         else {
             /* use IO bitmap */
diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm.h b/xen/arch/x86/include/asm/hvm/nestedhvm.h
index ea2c1bc328c7..d691ccb07dd6 100644
--- a/xen/arch/x86/include/asm/hvm/nestedhvm.h
+++ b/xen/arch/x86/include/asm/hvm/nestedhvm.h
@@ -50,7 +50,8 @@ int nestedhvm_hap_nested_page_fault(struct vcpu *v, paddr_t *L2_gpa,
                                     struct npfec npfec);
 
 /* IO permission map */
-unsigned long *nestedhvm_vcpu_iomap_get(bool ioport_80, bool ioport_ed);
+unsigned long *nestedhvm_vcpu_iomap_get(struct vcpu *v,
+                                        bool ioport_80, bool ioport_ed);
 
 /* Misc */
 #define nestedhvm_paging_mode_hap(v) (!!nhvm_vmcx_hap_enabled(v))
diff --git a/xen/arch/x86/include/asm/hvm/support.h b/xen/arch/x86/include/asm/hvm/support.h
index 2a7ba36af06f..7e36d00cc188 100644
--- a/xen/arch/x86/include/asm/hvm/support.h
+++ b/xen/arch/x86/include/asm/hvm/support.h
@@ -41,8 +41,6 @@ extern unsigned int opt_hvm_debug_level;
 #define HVM_DBG_LOG(level, _f, _a...) do {} while (0)
 #endif
 
-extern unsigned long hvm_io_bitmap[];
-
 enum hvm_translation_result {
     HVMTRANS_okay,
     HVMTRANS_bad_linear_to_gfn,
diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
index f948b7186e95..1083f6171cf7 100644
--- a/xen/arch/x86/include/asm/iocap.h
+++ b/xen/arch/x86/include/asm/iocap.h
@@ -22,6 +22,8 @@
 #define cache_flush_permitted(d) \
     (has_arch_io_resources(d) || has_arch_pdevs(d))
 
+int ioports_setup_access(struct domain *d);
+
 static inline int ioports_permit_access(struct domain *d, unsigned long s,
                                         unsigned long e)
 {
diff --git a/xen/arch/x86/ioport.c b/xen/arch/x86/ioport.c
new file mode 100644
index 000000000000..dbcd52d37a4f
--- /dev/null
+++ b/xen/arch/x86/ioport.c
@@ -0,0 +1,163 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Guest I/O port address space configuration.
+ *
+ * Copyright 2025 Ford Motor Company
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static char __initdata opt_dom0_ioports_disable[200] = "";
+string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
+
+/*
+ * The I/O permission bitmap size.
+ * See: comment in nestedhvm_setup()
+ */
+#define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
+
+/* Hide user-defined I/O ports from the guest OS. */
+static void process_dom0_ioports_disable(struct domain *dom0)
+{
+    unsigned long io_from, io_to;
+    char *t, *s = opt_dom0_ioports_disable;
+    const char *u;
+
+    if ( *s == '\0' )
+        return;
+
+    while ( (t = strsep(&s, ",")) != NULL )
+    {
+        io_from = simple_strtoul(t, &u, 16);
+        if ( u == t )
+        {
+        parse_error:
+            printk("Invalid ioport range <%s> "
+                   "in dom0_ioports_disable, skipping\n", t);
+            continue;
+        }
+
+        if ( *u == '\0' )
+            io_to = io_from;
+        else if ( *u == '-' )
+            io_to = simple_strtoul(u + 1, &u, 16);
+        else
+            goto parse_error;
+
+        if ( (*u != '\0') || (io_to < io_from) || (io_to >= 65536) )
+            goto parse_error;
+
+        printk("Disabling dom0 access to ioport range %04lx-%04lx\n",
+            io_from, io_to);
+
+        if ( ioports_deny_access(dom0, io_from, io_to) != 0 )
+            BUG();
+    }
+}
+
+/* Set the default IO Bitmap. */
+int ioports_setup_access(struct domain *d)
+{
+    unsigned int i, offs;
+    int rc;
+
+    if ( pv_shim )
+        return 0;
+
+#ifdef CONFIG_HVM
+    d->arch.hvm.io_bitmap = _xmalloc(HVM_IOBITMAP_SIZE, PAGE_SIZE);
+    if ( d->arch.hvm.io_bitmap == NULL )
+        return -ENOMEM;
+
+    memset(d->arch.hvm.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
+
+    if ( !is_hardware_domain(d) )
+    {
+        /*
+         * Allow direct access to the PC debug ports 0x80 and 0xed (they are
+         * often used for I/O delays, but the vmexits simply slow things down).
+         */
+        if ( hvm_port80_allowed )
+            __clear_bit(0x80, d->arch.hvm.io_bitmap);
+
+        __clear_bit(0xed, d->arch.hvm.io_bitmap);
+
+        return 0;
+    }
+#endif
+
+    /* The hardware domain is initially permitted full I/O capabilities. */
+    rc = ioports_permit_access(d, 0, 0xFFFF);
+
+    /* Modify I/O port access permissions. */
+
+    for ( offs = 0, i = ISOLATE_LSB(i8259A_alias_mask) ?: 2;
+          offs <= i8259A_alias_mask; offs += i )
+    {
+        if ( offs & ~i8259A_alias_mask )
+            continue;
+        /* Master Interrupt Controller (PIC). */
+        rc |= ioports_deny_access(d, 0x20 + offs, 0x21 + offs);
+        /* Slave Interrupt Controller (PIC). */
+        rc |= ioports_deny_access(d, 0xA0 + offs, 0xA1 + offs);
+    }
+
+    /* ELCR of both PICs. */
+    rc |= ioports_deny_access(d, 0x4D0, 0x4D1);
+
+    /* Interval Timer (PIT). */
+    for ( offs = 0, i = ISOLATE_LSB(pit_alias_mask) ?: 4;
+          offs <= pit_alias_mask; offs += i )
+        if ( !(offs & ~pit_alias_mask) )
+            rc |= ioports_deny_access(d, PIT_CH0 + offs, PIT_MODE + offs);
+
+    /* PIT Channel 2 / PC Speaker Control. */
+    rc |= ioports_deny_access(d, 0x61, 0x61);
+
+    /* INIT# and alternative A20M# control. */
+    rc |= ioports_deny_access(d, 0x92, 0x92);
+
+    /* IGNNE# control. */
+    rc |= ioports_deny_access(d, 0xF0, 0xF0);
+
+    /* ACPI PM Timer. */
+    if ( pmtmr_ioport )
+        rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3);
+
+    /* Reset control. */
+    rc |= ioports_deny_access(d, 0xCF9, 0xCF9);
+
+    /* PCI configuration space (NB. 0xCF8 has special treatment). */
+    rc |= ioports_deny_access(d, 0xCFC, 0xCFF);
+
+#ifdef CONFIG_HVM
+    if ( is_hvm_domain(d) )
+    {
+        /* ISA DMA controller, channels 0-3 (incl possible aliases). */
+        rc |= ioports_deny_access(d, 0x00, 0x1F);
+        /* ISA DMA controller, page registers (incl various reserved ones). */
+        rc |= ioports_deny_access(d, 0x80 + !!hvm_port80_allowed, 0x8F);
+        /* ISA DMA controller, channels 4-7 (incl usual aliases). */
+        rc |= ioports_deny_access(d, 0xC0, 0xDF);
+
+        /* HVM debug console IO port. */
+        rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
+                                  XEN_HVM_DEBUGCONS_IOPORT);
+        if ( amd_acpi_c1e_quirk )
+            rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
+    }
+#endif
+
+    /* Command-line I/O ranges. */
+    process_dom0_ioports_disable(d);
+
+    return rc;
+}
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 21158ce1812e..2b8b4d869ee7 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1033,6 +1034,9 @@ static int __init dom0_construct(const struct boot_domain *bd)
     if ( test_bit(XENFEAT_supervisor_mode_kernel, parms.f_required) )
         panic("Dom0 requires supervisor-mode execution\n");
 
+    rc = ioports_setup_access(d);
+    BUG_ON(rc != 0);
+
     rc = dom0_setup_permissions(d);
     BUG_ON(rc != 0);
 
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index c341f012d005..ea34c3ae598a 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -783,9 +783,20 @@ static int ns16x50_init(void *arg)
     struct vuart_ns16x50 *vdev = arg;
     const struct vuart_info *info = vdev->info;
     struct domain *d = vdev->owner;
+    int rc;
 
     ASSERT(vdev);
 
+    /* Disallow sharing physical I/O port */
+    rc = ioports_deny_access(d, info->base_addr,
+                             info->base_addr + info->size - 1);
+    if ( rc )
+    {
+        ns16x50_err(info, " virtual I/O port range [0x%04lx..0x%04lx]: conflict w/ physical range\n",
+                    info->base_addr, info->base_addr + info->size - 1);
+        return rc;
+    }
+
     /* NB: report 115200 baud rate. */
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & UINT8_MAX;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & UINT8_MAX;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115554.1462214 (Exim 4.92)
	(envelope-from )
	id 1uvj9o-00033Z-Jd; Mon, 08 Sep 2025 21:12:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115554.1462214; Mon, 08 Sep 2025 21: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 1uvj9n-00030o-No; Mon, 08 Sep 2025 21:12:11 +0000
Received: by outflank-mailman (input) for mailman id 1115554;
 Mon, 08 Sep 2025 21:12:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9k-0002L2-Ng
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9k-000FVM-1s;
 Mon, 08 Sep 2025 21:12:08 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9k-000gNe-27;
 Mon, 08 Sep 2025 21:12: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:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=2EIgKUJ6qf0RiPOYjpi3onfm0JU2Yq54wzXSyn3SuHQ=; b=pT7tt06uHlD/3fRZmHZr8/lEaY
	srf21/NDSqLw48HMOMSwwra/+LUhoZr+aPDqKD/SyDl0W3l+sg8mynD7jKEVCoIyZ78vUyditFcwx
	YQ3w1tZXpHzrQyZRMfbZjlpUXzb1p3mk4THrznmJuE2+ESWTwoi0giJk08ZrJFDNjZsw=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 15/16] xen/domain: allocate d->irq_caps before arch-specific initialization
Date: Mon,  8 Sep 2025 14:11:48 -0700
Message-ID: <20250908211149.279143-16-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Make sure that NS16550 emulator does not share virtual device IRQ with the
physical one. This is needed for enabling NS16550 emulator for PVH hwdom
(dom0).

To do that, move per-domain interrupt rangeset allocation before arch-specific
code. Add irqs_setup_access() to setup the initial rangeset.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- n/a
---
 xen/arch/x86/dom0_build.c       | 1 -
 xen/arch/x86/hvm/dom0_build.c   | 7 +++++++
 xen/arch/x86/include/asm/irq.h  | 2 ++
 xen/arch/x86/irq.c              | 8 ++++++++
 xen/arch/x86/pv/dom0_build.c    | 3 +++
 xen/common/domain.c             | 8 ++++++--
 xen/common/emul/vuart/ns16x50.c | 9 +++++++++
 7 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 26202b33345c..9dc87efbf3e8 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -442,7 +442,6 @@ int __init dom0_setup_permissions(struct domain *d)
 
     rc |= iomem_permit_access(d, 0UL,
                               PFN_DOWN(1UL << domain_max_paddr_bits(d)) - 1);
-    rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
 
     /* Local APIC. */
     if ( mp_lapic_addr != 0 )
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 5551f9044836..245a42dec9aa 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1348,6 +1348,13 @@ int __init dom0_construct_pvh(const struct boot_domain *bd)
          */
         pvh_setup_mmcfg(d);
 
+        rc = irqs_setup_access(d);
+        if ( rc )
+        {
+            printk("%pd unable to setup IRQ rangeset: %d\n", d, rc);
+            return rc;
+        }
+
         /*
          * Setup permissions early so that calls to add MMIO regions to the
          * p2m as part of vPCI setup don't fail due to permission checks.
diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h
index 8c81f66434a8..8bffec3bbfee 100644
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -231,4 +231,6 @@ int allocate_and_map_gsi_pirq(struct domain *d, int index, int *pirq_p);
 int allocate_and_map_msi_pirq(struct domain *d, int index, int *pirq_p,
                               int type, struct msi_info *msi);
 
+int irqs_setup_access(struct domain *d);
+
 #endif /* _ASM_HW_IRQ_H */
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 556134f85aa0..079277be719d 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -3046,3 +3046,11 @@ int allocate_and_map_msi_pirq(struct domain *d, int index, int *pirq_p,
 
     return ret;
 }
+
+int irqs_setup_access(struct domain *d)
+{
+    if ( is_hardware_domain(d) )
+        return irqs_permit_access(d, 1, nr_irqs_gsi - 1);
+
+    return 0;
+}
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 2b8b4d869ee7..1a092b802833 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -1037,6 +1037,9 @@ static int __init dom0_construct(const struct boot_domain *bd)
     rc = ioports_setup_access(d);
     BUG_ON(rc != 0);
 
+    rc = irqs_setup_access(d);
+    BUG_ON(rc != 0);
+
     rc = dom0_setup_permissions(d);
     BUG_ON(rc != 0);
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 775c33928585..edf76b02e1a1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -952,6 +952,11 @@ struct domain *domain_create(domid_t domid,
     radix_tree_init(&d->pirq_tree);
 #endif
 
+    err = -ENOMEM;
+    d->irq_caps = rangeset_new(d, "Interrupts", 0);
+    if ( !d->irq_caps )
+        goto fail;
+
     if ( (err = arch_domain_create(d, config, flags)) != 0 )
         goto fail;
     init_status |= INIT_arch;
@@ -961,8 +966,7 @@ struct domain *domain_create(domid_t domid,
 
     err = -ENOMEM;
     d->iomem_caps = rangeset_new(d, "I/O Memory", RANGESETF_prettyprint_hex);
-    d->irq_caps   = rangeset_new(d, "Interrupts", 0);
-    if ( !d->iomem_caps || !d->irq_caps )
+    if ( !d->iomem_caps )
         goto fail;
 
     if ( (err = xsm_domain_create(XSM_HOOK, d, config->ssidref)) != 0 )
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index ea34c3ae598a..6bd58ba5540b 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -797,6 +797,15 @@ static int ns16x50_init(void *arg)
         return rc;
     }
 
+    /* Disallow sharing physical IRQ */
+    rc = irq_deny_access(d, info->irq);
+    if ( rc )
+    {
+        ns16x50_err(info, "virtual IRQ#%d: conflict w/ physical IRQ: %d\n",
+                    info->irq, rc);
+        return rc;
+    }
+
     /* NB: report 115200 baud rate. */
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & UINT8_MAX;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & UINT8_MAX;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 21:12:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 21:12:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115556.1462223 (Exim 4.92)
	(envelope-from )
	id 1uvj9q-0003IR-1W; Mon, 08 Sep 2025 21:12:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115556.1462223; Mon, 08 Sep 2025 21:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvj9o-0003Ct-Pk; Mon, 08 Sep 2025 21:12:12 +0000
Received: by outflank-mailman (input) for mailman id 1115556;
 Mon, 08 Sep 2025 21:12:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvj9l-0002aN-RZ
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 21:12:09 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvj9l-000FVX-2F;
 Mon, 08 Sep 2025 21:12:09 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uvj9l-000gNi-2T;
 Mon, 08 Sep 2025 21: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References:
	In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=QgoMqHbu0tUc+lVtvyYl2w5a013VrqpmgCwPwd2nRFw=; b=sOqZXpCXdQNe+SfB8ANsxd7Vn4
	ZxrzEB4O/VMXSs0Fr3nr5FmWbheVLjFkqlmzUFrSF1+D0tmWM43cGV0CSvKydOw7dY9AbSw45y7M6
	FsI9G9nOelJVlrFjztHRmbcjYGVEGob1snavNNwQppzgnhaWoUNvvV0i+b7LRE+TMm6E=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v7 16/16] emul/ns16x50: implement IRQ emulation via vIOAPIC
Date: Mon,  8 Sep 2025 14:11:49 -0700
Message-ID: <20250908211149.279143-17-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250908211149.279143-1-dmukhin@ford.com>
References: <20250908211149.279143-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

PVH domains use vIOAPIC, not vPIC and NS16550 emulates ISA IRQs which cannot
be asserted on vIOAPIC.

{map,unmap}_domain_pirq_emuirq() infrastructure is modified by adding new
type of interrupt resources 'IRQ_EMU' which means 'emulated device IRQ'
(similarly to IRQ_MSI_EMU).

This is necessary to for IOAPIC emulation code to skip IRQ->PIRQ mapping
(vioapic_hwdom_map_gsi()) when guest OS unmasks vIOAPIC pin corresponding to
virtual device's IRQ.

Also, hvm_gsi_eoi() is modified to trigger assertion in hvm_gsi_deassert()
path for ISA IRQs.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- n/a
---
 xen/arch/x86/hvm/vioapic.c        | 10 ++++++++++
 xen/arch/x86/include/asm/irq.h    |  6 ++++++
 xen/common/emul/vuart/ns16x50.c   | 28 ++++++++++++++++++++++++++--
 xen/drivers/passthrough/x86/hvm.c | 11 ++++++++++-
 4 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index 7c725f9e471f..6314874b64f7 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -177,6 +177,16 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi, unsigned int trig,
 
     ASSERT(is_hardware_domain(currd));
 
+    /*
+     * Interrupt is claimed by one of the platform virtual devices (e.g.
+     * NS16550); do nothing.
+     */
+    write_lock(&currd->event_lock);
+    ret = is_domain_emuirq_claimed(currd, gsi);
+    write_unlock(&currd->event_lock);
+    if ( ret )
+        return 0;
+
     /* Interrupt has been unmasked, bind it now. */
     ret = mp_register_gsi(gsi, trig, pol);
     if ( ret == -EEXIST )
diff --git a/xen/arch/x86/include/asm/irq.h b/xen/arch/x86/include/asm/irq.h
index 8bffec3bbfee..bdbe700274e9 100644
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -168,6 +168,11 @@ void free_domain_pirqs(struct domain *d);
 int map_domain_emuirq_pirq(struct domain *d, int pirq, int emuirq);
 int unmap_domain_pirq_emuirq(struct domain *d, int pirq);
 
+#define domain_emuirq_claim(d, irq)     map_domain_emuirq_pirq(d, irq, IRQ_EMU)
+#define domain_emuirq_unclaim(d, irq)   unmap_domain_pirq_emuirq(d, irq)
+#define is_domain_emuirq_claimed(d, irq) \
+    (domain_pirq_to_emuirq(d, irq) != IRQ_UNBOUND)
+
 /* Evacuate interrupts assigned to CPUs not present in the CPU online map. */
 void fixup_irqs(void);
 void fixup_eoi(void);
@@ -221,6 +226,7 @@ void cleanup_domain_irq_mapping(struct domain *d);
 #define IRQ_UNBOUND (-1)
 #define IRQ_PT      (-2)
 #define IRQ_MSI_EMU (-3)
+#define IRQ_EMU     (-4)
 
 bool cpu_has_pending_apic_eoi(void);
 
diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16x50.c
index 6bd58ba5540b..081d2639aa7a 100644
--- a/xen/common/emul/vuart/ns16x50.c
+++ b/xen/common/emul/vuart/ns16x50.c
@@ -299,7 +299,7 @@ static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
     if ( has_vpic(d) )
         vector = hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
     else if ( has_vioapic(d) )
-        /* TODO */
+        vector = hvm_ioapic_assert(d, info->irq, false);
     else
         ASSERT_UNREACHABLE();
 
@@ -314,7 +314,7 @@ static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
     if ( has_vpic(d) )
         hvm_isa_irq_deassert(d, info->irq);
     else if ( has_vioapic(d) )
-        /* TODO */
+        hvm_ioapic_deassert(d, info->irq);
     else
         ASSERT_UNREACHABLE();
 
@@ -806,6 +806,17 @@ static int ns16x50_init(void *arg)
         return rc;
     }
 
+    /* Claim virtual IRQ */
+    write_lock(&d->event_lock);
+    rc = domain_emuirq_claim(d, info->irq);
+    write_unlock(&d->event_lock);
+    if ( rc )
+    {
+        ns16x50_err(info, "virtual IRQ#%d: cannot claim: %d\n",
+                    info->irq, rc);
+        return rc;
+    }
+
     /* NB: report 115200 baud rate. */
     vdev->regs[NS16X50_REGS_NUM + UART_DLL] = divisor & UINT8_MAX;
     vdev->regs[NS16X50_REGS_NUM + UART_DLM] = (divisor >> 8) & UINT8_MAX;
@@ -822,9 +833,22 @@ static int ns16x50_init(void *arg)
 static void cf_check ns16x50_deinit(void *arg)
 {
     struct vuart_ns16x50 *vdev = arg;
+    const struct vuart_info *info;
+    struct domain *d;
+    int rc;
 
     ASSERT(vdev);
 
+    d = vdev->owner;
+    info = vdev->info;
+
+    write_lock(&d->event_lock);
+    rc = domain_emuirq_unclaim(d, info->irq);
+    write_unlock(&d->event_lock);
+    if ( rc )
+        ns16x50_err(vdev, "virtual IRQ#%d: cannot unclaim: %d\n",
+                    info->irq, rc);
+
     spin_lock(&vdev->lock);
     ns16x50_fifo_tx_flush(vdev);
     spin_unlock(&vdev->lock);
diff --git a/xen/drivers/passthrough/x86/hvm.c b/xen/drivers/passthrough/x86/hvm.c
index a2ca7e0e570c..20641194561f 100644
--- a/xen/drivers/passthrough/x86/hvm.c
+++ b/xen/drivers/passthrough/x86/hvm.c
@@ -922,7 +922,16 @@ static void __hvm_dpci_eoi(struct domain *d,
 
 static void hvm_gsi_eoi(struct domain *d, unsigned int gsi)
 {
-    struct pirq *pirq = pirq_info(d, gsi);
+    struct pirq *pirq;
+
+    /* Check if GSI is claimed by one of the virtual devices. */
+    if ( is_domain_emuirq_claimed(d, gsi) )
+    {
+        hvm_gsi_deassert(d, gsi);
+        return;
+    }
+
+    pirq = pirq_info(d, gsi);
 
     /* Check if GSI is actually mapped. */
     if ( !pirq_dpci(pirq) )
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 08 22:40:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 22:40:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115741.1462243 (Exim 4.92)
	(envelope-from )
	id 1uvkXH-0006ZT-PF; Mon, 08 Sep 2025 22:40:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115741.1462243; Mon, 08 Sep 2025 22:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvkXH-0006ZM-MN; Mon, 08 Sep 2025 22:40:31 +0000
Received: by outflank-mailman (input) for mailman id 1115741;
 Mon, 08 Sep 2025 22:40: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 1uvkXG-0006ZG-Sg
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 22:40:30 +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 cf1d8bf2-8d04-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 00:40: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 59F4C60051;
 Mon,  8 Sep 2025 22:40:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EDB6C4CEF1;
 Mon,  8 Sep 2025 22:40: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: cf1d8bf2-8d04-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757371223;
	bh=AOM+t17SXxNjyLepjNXD/zpSs8Cpqp5i+7KamT7weIk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aquZhuA7fmM4jd93gSfZtEawARmFxQBxvUG6dMZOFAeVQFuYXgIwATS2Daoqp6g55
	 A/Cb1YxMbdvkBaHogY9yjb4NomlEhWzZpCJcQnoNolZYtsK7DTHl+gXC5zakXwsw3g
	 +Cdn60aWuJdT3nblSbVFv2/xwL02TkcqISA+sHFKKde+DPVcgFOm+bzR4aTtkxcmdf
	 GQBar19ZpDH6gtW2ZYGSVDEVGKCmhc4J+AnReAVgBU3bf9P0pSyF1qr+8DcowVsQSX
	 Kd5Cx1TP1LnFEaCmOVaCUWP8jBv8/yoYWuECYE7y+vdNj+edCavE6hDPnSJeW1WOjy
	 k7rNnftCSmkjw==
Date: Mon, 8 Sep 2025 15:40:19 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Oleksii Kurochko , 
    "xen-devel@lists.xenproject.org" , 
    Stefano Stabellini , 
    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: [PATCH v9 0/4] xen/arm: scmi: introduce SCI SCMI SMC single-agent
 support
In-Reply-To: <062bd466-012a-454a-85ab-1b597c40e4ab@epam.com>
Message-ID: 
References:    <5bc8844d-fcde-48a0-9992-0f1a105a563e@gmail.com> <062bd466-012a-454a-85ab-1b597c40e4ab@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi all,

Just a quick note to say that this series is committed.

Oleksii M you might want to check that everything is in order.

Cheers,

Stefano


On Mon, 8 Sep 2025, Oleksii Moisieiev wrote:
> On 08/09/2025 17:31, Oleksii Kurochko wrote:
> > Hello Oleksii,
> > On 9/8/25 4:21 PM, Oleksii Moisieiev wrote:
> >> On 08/09/2025 17:11, Oleksii Kurochko wrote:
> >>> Hello everyone,
> >>> Based on the message from the previous version, the MISRA issues have been fixed,
> >>> and aside from one remaining documentation patch ("docs: arm: add docs for SCMI
> >>> over SMC calls forwarding driver"), the patch series appears to be ready.
> >> It seems to me that I have fixed all comments for the documentation
> >> patch. Did I miss something? Why do you think it's not ready for merge?
> > I don't see any proper/Reviewed-by/ or/Acked-by/ tags, only/Signed-off-by/:
> >    Signed-off-by: Grygorii Strashko
> >    Signed-off-by: Oleksii Moisieiev
> >
> > Am I missing something?
> Stefano added his R-B in v6:
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2508281436010.8757@ubuntu-linux-20-04-desktop/
> 
> Haven't added this R-B tag manually because of the following comment to 
> the first patch:
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2508281431180.8757@ubuntu-linux-20-04-desktop/
> >>> I believe we can consider including it in 4.21. We should have sufficient time
> >>> to address any bugs that may arise.
> >>> By the way, it would also be good to prepare a CHANGELOG patch.
> >> Is it going to be changed during release process or it requires separate
> >> patch to be sent?
> > I'm not entirely sure I understand the first part of the sentence correctly,
> > but both options could work (IIUC).
> > I can send an update to the CHANGELOG as part of the release process,
> > but I'm also fine if you prefer to send a separate patch or apply a new patch
> > to this series using the Message-ID.
> >
> > Please let me know which option you prefer.
> >
> > ~ Oleksii
> I would be grateful if you could include an update to the
> CHANGELOG as part of the release process.
> >>> Does anyone have any objections?
> >>> Best regards,
> >>>    Oleksii
> >>> On 9/4/25 4:21 PM, Oleksii Moisieiev wrote:
> >>>> Inroducing V9 patch series  on top of the Xen version 4.20-rc2
> >>>> which includes implementation of the SCI SCMI SMC single-agent support.
> >>>>
> >>>> This patch series is the first chunk of the
> >>>> "xen/arm: scmi: introduce SCI SCMI SMC multi-agent support" which can
> >>>> be found at [0]
> >>>>
> >>>> SCMI-multiagent support will be provided as the followup patch series.
> >>>>
> >>>> [0]https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/
> >>>>
> >>>> Patch 1 "xen/arm: add generic SCI subsystem"
> >>>> - rebased and refactored
> >>>> - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
> >>>> instead of custom,
> >>>>     linker sections based implementation.
> >>>> - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
> >>>> dom0 code directly.
> >>>> - RFC changes in XEN_DOMCTL_assign_device OP processing
> >>>> - Introduce arch_handle_passthrough_prop call to handle arm specific
> >>>> nodes
> >>>>
> >>>> Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
> >>>> - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI
> >>>> over SMC calls
> >>>> handling layer") be used under sci subsystem.
> >>>> - no functional changes in general
> >>>>
> >>>> Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
> >>>> This is new change which allows passthrough SCMI SMC, single agent interface to
> >>>> guest domain
> >>>> cover use case "thin Dom0 with guest domain, which serves as Driver domain".
> >>>> See patch commit message for full description.
> >>>>
> >>>> Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
> >>>> driver
> >>>> - add documentation section for Simple Arm SCMI over SMC calls
> >>>> forwarding driver.
> >>>>
> >>>> Code can be found at:
> >>>> https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv5
> >>>>
> >>>> [1] RFC v2:
> >>>> http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/
> >>>> [2] RFC v3:
> >>>> https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927-1-grygorii_strashko@epam.com
> >>>> SCMI spec:
> >>>> https://developer.arm.com/documentation/den0056/e/?lang=en
> >>>>
> >>>> SCMI bindings:
> >>>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> >>>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
> >>>>
> >>>> Reference EL3 FW:
> >>>> RPI5:https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
> >>>> Renesas v4h:
> >>>> https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/
> >>>>
> >>>> base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)
> >>>>
> >>>> Changes in v9:
> >>>> - change input param name for sci_handle_call function to match MISRA rules
> >>>> - update domu_dt_sci_parse declaration to match MC3A2.R8.4 MISRA rule
> >>>>
> >>>> Changes in v8:
> >>>> - reneregated {helpers/types}.gen.go, dropped unneeded parameters
> >>>>
> >>>> Changes in v7:
> >>>> - fix sci_handl_call to make changes more readable
> >>>> - fix build error when DOM0LESS_BUILD is disabled (removed
> >>>>    arch_handle_passthrough_prop from the header)
> >>>> - sort headers in alphabetical order in sci.h
> >>>> - sort headers in scmi-smc.c file
> >>>> - Fix commit description.
> >>>> - Move scmi-smc-passthrough definition to match alphaberical order
> >>>> - remove unneeded initialization with NULL
> >>>> - changed u64 to uint64_t
> >>>> - Send warning if iomem permit access was failed
> >>>> - fixed typos
> >>>>
> >>>> Changes in v6:
> >>>> - rebase on top of the latest master
> >>>> - fix return value of sci_dt_finalize() call
> >>>> - add R-b tag
> >>>> - added generated helpers and types go files
> >>>> - rename cmdline parameter to scmi-smc-passthrough
> >>>> - fix goto tag in parse_arm_sci_config
> >>>> - add link to the scmi bindings used in the doc
> >>>> - remove mentions about HVC calls from doc
> >>>> - rename cmdline parameter to scmi-smc-passthrough
> >>>>
> >>>> Changes in v5:
> >>>> - update Maintainers file. Set role as a Reviewer
> >>>> - rebased on the latest master branch
> >>>> - Introduce arch_handle_passthrough_prop call to handle arm specific nodes
> >>>> - rename dom0_scmi_smc_passthrough to scmi_smc_passthrough
> >>>> - rename dom0_scmi_smc_passthrough in documentation
> >>>>
> >>>> Changes in v4:
> >>>> - fix SPDX-License
> >>>> - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
> >>>> - move XEN_DOMCTL_assign_device code in separate patch
> >>>> - Add documentation for SCI SCMI drivers
> >>>> - xl.cfg doc
> >>>> - fix comments from Stefano Stabellini
> >>>> - fix toolstack code as sugested by Anthony PERARD
> >>>>     - use MATCH_OPTION()
> >>>>     - move arm_sci struct and cfg params in "arch_arm"
> >>>> - add SCMI passthrough for dom0less case
> >>>>
> >>>> Grygorii Strashko (3):
> >>>>     xen/arm: scmi-smc: update to be used under sci subsystem
> >>>>     xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
> >>>>     docs: arm: add docs for SCMI over SMC calls forwarding driver
> >>>>
> >>>> Oleksii Moisieiev (1):
> >>>>     xen/arm: add generic SCI subsystem
> >>>>
> >>>>    MAINTAINERS                                   |   6 +
> >>>>    .../arm/firmware/arm-scmi.rst                 | 180 ++++++++++++++++
> >>>>    docs/hypervisor-guide/arm/index.rst           |   9 +
> >>>>    docs/hypervisor-guide/index.rst               |   1 +
> >>>>    docs/man/xl.cfg.5.pod.in                      |  34 +++
> >>>>    docs/misc/arm/device-tree/booting.txt         |  15 ++
> >>>>    docs/misc/xen-command-line.pandoc             |   9 +
> >>>>    tools/golang/xenlight/helpers.gen.go          |  35 +++
> >>>>    tools/golang/xenlight/types.gen.go            |  11 +
> >>>>    tools/include/libxl.h                         |   5 +
> >>>>    tools/libs/light/libxl_arm.c                  |  14 ++
> >>>>    tools/libs/light/libxl_types.idl              |  10 +
> >>>>    tools/xl/xl_parse.c                           |  36 ++++
> >>>>    xen/arch/arm/device.c                         |   5 +
> >>>>    xen/arch/arm/dom0less-build.c                 |  40 ++++
> >>>>    xen/arch/arm/domain.c                         |  12 +-
> >>>>    xen/arch/arm/domain_build.c                   |   8 +
> >>>>    xen/arch/arm/firmware/Kconfig                 |  25 ++-
> >>>>    xen/arch/arm/firmware/Makefile                |   1 +
> >>>>    xen/arch/arm/firmware/sci.c                   | 154 ++++++++++++++
> >>>>    xen/arch/arm/firmware/scmi-smc.c              | 194 +++++++++++++----
> >>>>    xen/arch/arm/include/asm/domain.h             |   5 +
> >>>>    xen/arch/arm/include/asm/firmware/sci.h       | 200 ++++++++++++++++++
> >>>>    xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 ----
> >>>>    xen/arch/arm/vsmc.c                           |   4 +-
> >>>>    xen/common/device-tree/dom0less-build.c       |   4 +
> >>>>    xen/include/asm-generic/device.h              |   1 +
> >>>>    xen/include/public/arch-arm.h                 |   5 +
> >>>>    xen/include/xen/dom0less-build.h              |   3 +
> >>>>    29 files changed, 982 insertions(+), 85 deletions(-)
> >>>>    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/include/asm/firmware/sci.h
> >>>>    delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
> >>>>
> 


From xen-devel-bounces@lists.xenproject.org Mon Sep 08 23:52:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Sep 2025 23:52:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115766.1462257 (Exim 4.92)
	(envelope-from )
	id 1uvlea-0006Zt-Sm; Mon, 08 Sep 2025 23:52:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115766.1462257; Mon, 08 Sep 2025 23:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvlea-0006Zm-Po; Mon, 08 Sep 2025 23:52:08 +0000
Received: by outflank-mailman (input) for mailman id 1115766;
 Mon, 08 Sep 2025 23:52: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 1uvleZ-0006ZN-D5
 for xen-devel@lists.xenproject.org; Mon, 08 Sep 2025 23:52:07 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2414::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cfc9c391-8d0e-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 01:52:01 +0200 (CEST)
Received: from DS7P220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:1ca::7) by
 CH2PR12MB4183.namprd12.prod.outlook.com (2603:10b6:610:7a::24) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.22; Mon, 8 Sep 2025 23:51:55 +0000
Received: from CY4PEPF0000E9D0.namprd03.prod.outlook.com
 (2603:10b6:8:1ca:cafe::8) by DS7P220CA0005.outlook.office365.com
 (2603:10b6:8:1ca::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Mon,
 8 Sep 2025 23:51:53 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CY4PEPF0000E9D0.mail.protection.outlook.com (10.167.241.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Mon, 8 Sep 2025 23:51:55 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 8 Sep
 2025 16:51:54 -0700
Received: from ubuntu-20.04.2-arm64.shared (10.180.168.240) by
 satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17 via Frontend Transport; Mon, 8 Sep 2025 16:51:53 -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: cfc9c391-8d0e-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U6+x4N2D6KVyvPw3c08CMuZl+7ghpZSmX7cQB+iWIRd+zvagXdsZJobKtf/BV2RhxXy27fut6bLsIG8yx8y/r67HOmI+YEe9tZKNRjULZ+e752gt1k93xvncDd+EfKuM2dQ47Wl5Q26abbBkEfahXu+BmvykSIT0HMnC6+IOmkxRHPYVccMbiafPj7Yk+RaXt8SA2w9SbQtBuifvUev3oHqPgg9xtsUFmc9Qh85rbmfor/J8QgrxZDJUpL5rjjKYJKOMmnCJ5HdbuiKytOJEfjN9PGcPwFcYQyBXQFtbgTLFZYUPOwj6vDn8Q9Ef1PtYnQRekK/rs8lKkCgq1BuUkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SxfbD5t4AAmavriFKCaj/6pnOKSAkpFeOYbctAmbv3k=;
 b=Po5d9S/9VVMY8ZMEjt2MzcycknpAyTVO0q1ckbVw1AtjmHkPcfa8ZQQgz1hEIZWA/J2Tf5GoPN8hBDy385IeI8TCHfTTzfWAwYNx2BoGMSVMI1vF7WZxkPRmz1bsDpAf7S3gdTEA/Ebdiy9sI9FbowO5kkjgqFND9wo/4hvIuJGliMsJzMvflypvJSm5i/vUyR+HxSlp36aql/llh9ZTTrkmvIopKX3akBtFUvGrZVavRon6+0P8ndIylZ04OKSluBWjI4/iGmWiWXn8ZT210ZQLyG5tgKyI24L4yckYR52KbvUTWyiWa6kaG2py1MMv8KDvUMTYFLhNyqQ2Lq9mpg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SxfbD5t4AAmavriFKCaj/6pnOKSAkpFeOYbctAmbv3k=;
 b=wagYQW/nI1242r/EnlU8XbaRMR/GufMWhIw00nt+UjOR/SwTW8JQm7MB6pNXMR1euS94+MGi7MpEDg02AbQ0AeViByYl5ie+nZMnvZzDrouAfJykoIBxL7UKcEj1vs1NJSVTNUOVbSkidqYL5tz6jCyftpAKaXJa1XRQV0FgqJk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Date: Mon, 8 Sep 2025 16:51:53 -0700
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
CC: Mykola Kvach , Stefano Stabellini
	, ,
	, ,
	, , ,
	, , 
Subject: Re: [PATCH v6 00/15] x86: introduce NS16550-compatible UART
 emulator
In-Reply-To: 
Message-ID: 
References: <20250905232715.440758-1-dmukhin@ford.com>   
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="8323329-174628289-1757375514=:1405870"
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D0:EE_|CH2PR12MB4183:EE_
X-MS-Office365-Filtering-Correlation-Id: b6f0d964-c8e1-42c5-f642-08ddef32b10f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|7416014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cjJSQkNzdTZTMC9UUm4xYTE2ZTg0UUhLbm9GRnFRVm5ibHRCRDhqSzdjWURZ?=
 =?utf-8?B?ZnZFT1FldkpxK1A4SlBzRWtKQm5QVjNwRzZhYmhGOTZZbkh0TTdRVTNSY2Zu?=
 =?utf-8?B?OHQ3N3JnWHBDcDk0aDJ0anBIazFJRldiRzBoc0ovb1pTTEVRaXlqbGQ3SWFQ?=
 =?utf-8?B?OHl6OEhSbUlZSzh0c0FLd2pPWUVOS1lDeFd4QWhLWWlVemVvM3h1YTAwdzJq?=
 =?utf-8?B?WGFiWEQzMXBBZUEwNzl1REdJYTVVOFhCbEo0WDQ5Rkc3SER4azY2RmgwR3Ar?=
 =?utf-8?B?dE9LclltN3VaaHI5TTZKeUF4ZzhpcDJtYlNuNHpOYlVGMmxQS1Rxa0R1TGl3?=
 =?utf-8?B?MGRiYlFmTzk1ZnhzNXFTT0NhbFJlVE9aRW4zODZXSldsd2gzQnoxUnFmUWdh?=
 =?utf-8?B?M0QxQlZmTW9IbzZuVDhLdkhXZThWb0ZrN2NyWXhiK3FrU2cyUTFJTmhxQkEv?=
 =?utf-8?B?YURmSWVTbm9hWUFjZzMxc0plL1pGc1lYL0ZLWHFIcDc4ODZzTU9KUFFTak5X?=
 =?utf-8?B?NjlYVzc4eHZwUHFuSEpVSHNvZjBrS20rWjh4Y1FwSHNTcnZvWlk4S1ljdGVm?=
 =?utf-8?B?dEdqcitFaUNzT3RoNUwxS0F0RDdZNVJXd21TZ2lXMG5vQjRqWVJZc1ZpWWs4?=
 =?utf-8?B?UWJ0blNOckxXcVEyVC9tR0VCK0xxUDdRemV0RjZyYjdSNkx0aXlNTTRjem1U?=
 =?utf-8?B?c1NoaFd2SW8zaFFoZ2NLTUNRK0RYM1VDOEprU1JKUjJFK3ZuZ2VWSUIvTXFh?=
 =?utf-8?B?TWRtVWlaN3h1bnZ4MkFUQm05OVcxVG1CbWV4Tm5BcFh0cWVFQktrY0p4SDd2?=
 =?utf-8?B?ZE13UzUrY1lBZ21sTmJuOThJUG8xNkU4YnlERjB3OW1hOS9xOUFublVTQ1du?=
 =?utf-8?B?akxhbmdzRHhZYmk2TGJLTXF6cHYxYnNKVm01KzRDK1lnbVlCK0pCdzZhZXlR?=
 =?utf-8?B?bE1TRWFPR0pRN2lwSFBSN2VyYWJvMmg1THFiT0lnQ0QyMGN4NUk0bE5acXZX?=
 =?utf-8?B?Njd6UHVCbDRLNnl1S0RzY0Nnd0JHU2wzdXdNdlFmVHdXMW9KOFFrSkhYMk9n?=
 =?utf-8?B?K2svOVh4Ni9udWdYOWJsRk9hVEduQTQvakNYUG1PZnlRekJ4cmphWHhuYlRj?=
 =?utf-8?B?b0RpbVBobGdFeUdqWUhGNmRTZTk1UDNiNEE3WUlVNFEyS0xQaVpZN3QyVFBE?=
 =?utf-8?B?Uy81YStxQmljUkprSkxGNmg3eG1kREtxaisvbWhkeXppTU9KRFJJWWhaekZy?=
 =?utf-8?B?R21WQnAzeDh0WEx2YjRMT0N4MEtFQmZKbkdDaUg0L3UvTXlRa0pIUmxPeEJn?=
 =?utf-8?B?RXBrdGNON1EzU1FCR3pqK1NzWjFtZXFxeDFDbnNMZFBhLzd1WHkxSVhCNTU1?=
 =?utf-8?B?WThySmVpaVM0TnNqcmpiTjkvZUNlcTJ4OGtzOFNSKzY2eVVxL0UyWmxzMkNy?=
 =?utf-8?B?YVhtc1BZb2pjbVgwOWdySFZWbDRCUmkyWXI5aHFyNkZIYndRS3FTNUFsMGZ5?=
 =?utf-8?B?SVZCK3ZGMW5RaVRDLzZmaU1WSk8yV1dYa004Qjlrd0xieW85T2hFaWsxbE1z?=
 =?utf-8?B?RGVtbmsxTWFJUTRUblp4OW8xTmtTbGhoTWd5VW1uYm1BREZEcVVKVlVTZCtS?=
 =?utf-8?B?ZHFQUW8vTHNJWkdOcUxMOWhNVXZNWW01ZGdJUUdBZmVCVENIdXhQT2hWZzRN?=
 =?utf-8?B?YXg3YVdvaENUWWI5WlYrUDZyQVRuSm5jbWIwWTdpdkVsbkg1Y3dKQnZVb1lY?=
 =?utf-8?B?Qzhpd1pVRG41ZEY3SnBBbG03cDl6ZnhvSlEzUVNTYTY1Qkc4NU04V0xZQk9v?=
 =?utf-8?B?eHpGSlpndDU0MWtzTWVhNE12ZUNSKzNSL2RRL0hlRjRtQUtYNzA3RlAyamlv?=
 =?utf-8?B?Y0diL3NtSjFUNWVoWEpoWnYxcXAvcEp6MXVTME1yWk11TEcrQmxqSkhZMUJP?=
 =?utf-8?B?alNtUFkvV3FpYUg5RkF3NSsrRERlZnBCOGp3UVRSdHhEcFVxcmNsUUcyMXBX?=
 =?utf-8?B?OEtpYlJFcFIrelNONzEvSlQxUk5RRzVIaDJsSGxSYTc1d3dvbW5jK0Uxai9H?=
 =?utf-8?Q?N+SSVe?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(7416014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 23:51:55.3623
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b6f0d964-c8e1-42c5-f642-08ddef32b10f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D0.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4183

--8323329-174628289-1757375514=:1405870
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 8 Sep 2025, Oleksii Kurochko wrote:
> Hello Everyone,
> 
> On 9/8/25 11:04 AM, Mykola Kvach wrote:
> 
> Hi Denis and Stefano
> 
> I’d like to acknowledge the significant effort that went into this patch
> series -- it’s clear that a lot of work has been invested.
> 
> On Sat, Sep 6, 2025 at 5:02 AM Stefano Stabellini
>  wrote:
> 
> Oleksii and all,
> 
> I would like to consider patches 1-12 of this patch series for 4.21,
> pending the few minor comments I made addressed.
> 
> Although I am neither a maintainer nor an official reviewer for this
> project, I have looked over some of the first patches in the series. In my
> opinion, the series is not yet ready for merging.
> 
> Even if my review is set aside, the changes are largely x86-specific and
> produce the most impact on this architecture. I believe that before
> merging, one of the x86 maintainers (or at least a trusted reviewer for
> x86, if available) should carefully review these patches.
> 
> I agree with this point. Considering that this part is being moved to
> common code, it would be helpful to get some input from the x86 maintainers.
> 
> Also, since the entire patch series is not yet ready, I think it makes
> sense at this stage of development to either have the whole series reviewed
> or postpone it to 4.22. (The last one is preferred at the current stage of
> development)

Even with x86 review, it would be difficult to get the whole series
merged now. If it is all or nothing, then I suggest we wait for 4.22.
--8323329-174628289-1757375514=:1405870--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 00:10:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 00:10:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115784.1462267 (Exim 4.92)
	(envelope-from )
	id 1uvlwV-0001eZ-7R; Tue, 09 Sep 2025 00:10:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115784.1462267; Tue, 09 Sep 2025 00: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 1uvlwV-0001eS-4j; Tue, 09 Sep 2025 00:10:39 +0000
Received: by outflank-mailman (input) for mailman id 1115784;
 Tue, 09 Sep 2025 00: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 1uvlwT-0001eM-HR
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 00:10:37 +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 67dabca3-8d11-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 02:10:35 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id AF06A40770;
 Tue,  9 Sep 2025 00:10:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24987C4CEF1;
 Tue,  9 Sep 2025 00:10: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: 67dabca3-8d11-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757376633;
	bh=YgoZWQQJmWUo7bCUBFqAZOOGn9GzTDDXpPCzKCZ+oio=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=teL9MhdykjWH9HhMeI/9Hc3mQINBrskNXRU+9iHOthI9AYm73iNyuGJYCVuDzME9l
	 +YBtCEwb86+T3EKLu6SUKQFxBASCgTFdAUEqcogJUmskjIU0YLDLrXUPFQib6WDByr
	 psncamMOKM0gvhIccFCLG+07fTfex6S/Br0eCgHwP1xIQCatffb1gai01XjJO2YMAv
	 nlF7xEhr6s8iIpOBTPtpCR23LIp2awCipqhlbYd60FFgz5aBhXXN0N9nbQ1kVW7snv
	 mxCFfECT/IOWB6gX/gpg2jxmkL/vqVWnXRaUGE48SHN+f5a9oQ8q/6awSmS77K0ROa
	 p2BSt7WhupkxA==
Date: Mon, 8 Sep 2025 17:10:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Leonid Komarianskyi 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    "olekstysh@gmail.com" , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Anthony PERARD , 
    Oleksii Kurochko , 
    Community Manager 
Subject: Re: [PATCH v7 00/12] Introduce eSPI support
In-Reply-To: <374b7296-bfc0-4a4d-8f2c-b148c29c0517@epam.com>
Message-ID: 
References:   <374b7296-bfc0-4a4d-8f2c-b148c29c0517@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 7 Sep 2025, Leonid Komarianskyi wrote:
> Hello Stefano,
> 
> Thank you for your comments and for providing the Eclair reports.
> 
> On 06.09.25 03:17, Stefano Stabellini wrote:
> > Hi Leonid,
> >
> > I was about to commit this but unfortunately it is introducing MISRA
> > regressions. See:
> > https://gitlab.com/xen-project/people/sstabellini/xen/-/tree/ppp6?ref_type=heads
> >
> > https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/11265005118
> >
> > Compared this result:
> > https://eclair-analysis-logs.xenproject.org/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp6/ARM64/11265005118/PROJECT.ecd;/by_service.html#service&kind
> >
> > Against upstream staging:
> > https://eclair-analysis-logs.xenproject.org/fs/space/XEN.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/ARM64/11264772605/PROJECT.ecd;/by_service.html#service&kind
> >
> > It is introducing a couple of easy-to-fix 16.3 issues and also a couple
> > of new 16.4 issues. They should be all easy to fix. It is also
> > introducing three new 13.2 issues and one 18.1 but I haven't looked
> > closely into those. Please address them.
> >
> 
> Regarding the MISRA 16.3/16.4 violations and 13.2 cautions - there are
> no questions from my side. I have fixed them and will send the updated
> V8 (with typo fixes, added acked/reviewed-by tags, etc.).

Thanks!


> However, I
> would like to clarify regarding the MISRA 18.1 caution regression and
> review process rules:
> 
> MISRA 18.1 caution:
> 
> xen/arch/arm/irq.c:105.13-105.39: [8] access of 'irq_desc' at an
> overflowing index, while it holds only 992 'struct irq_desc' elements
> 
> Actually, there is no new real issue here, because the mainline
> irq_desc() currently does not have upper limit checks for IRQs:
> 
> struct irq_desc *__irq_to_desc(unsigned int irq)
> {
>      if ( irq < NR_LOCAL_IRQS )
>          return &this_cpu(local_irq_desc)[irq];
> 
>      return &irq_desc[irq-NR_LOCAL_IRQS];
> }
> 
> ... as a result Eclair does not spot any issues in this code according
> to the staging report. As I understand, it triggers on patches with eSPI
> because I introduced new checks for the eSPI INTID range, which should
> not be used without CONFIG_GICV3_ESPI=y.
> 
> Also, a similar issue with invalid INTIDs was discussed in the thread:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00401.html
> 
> Long story short: the mainline Xen currently allows defining invalid
> INTIDs in the Xen DTS and crashes in __irq_to_desc() when attempting to
> operate on an invalid interrupt number.
> 
> I have prepared a fix for the 18.1 caution, but I am not sure whether it
> is worth applying just to address the Eclair report (if it is not critical):
> https://github.com/LKomaryanskiy/xen/commit/af5d9a483302f7bcfaadbefb85f5e4ee35f6cb3b
> 
> So, could you please clarify which option would be better:
> 1) Leave the code as it is for now, accepting the MISRA caution from
> Eclair and fix the issue later in the context of addressing Xen crashing
> with invalid INTIDs and implementing dynamic allocation of irq_desc_t array;
> 2) Apply the fix now (while also planning to address the invalid INTID
> issue in the future)

I am happy to apply the fix now as part of the series


> Regarding the review process:
> Should I remove the 'reviewed-by' tags from the patches where I added
> missing breaks (with the corresponding code updates) or introduced
> variables to fix MISRA issues? I am asking because these are code
> changes, and I am not sure if I should leave the RB tags in this case.

Please keep them

> >
> > Oleksii,
> >
> > Technically, the series is fully acked and ready to be committed. From a
> > risk perspective, I would be comfortable committing it now with the
> > outstanding MISRA regressions, leaving Leonid to fix them over the next
> > few days. However, I have not done so because it would make it harder to
> > spot the MISRA regressions due to the way the scanner works (it
> > compares against the previous version).
> >
> > I suggest we allow this series to be committed in the next couple of
> > days, once Leonid addresses the regressions, even though it would
> > technically be past the feature freeze.
> >
> > Cheers,
> >
> > Stefano
> >
> > P.S.
> >
> > Leonid, you might want to check my commits because I fixed a couple of
> > things on commit, in addition to adding the various acked-by tags.
> >
> >
> > On Thu, 4 Sep 2025, Leonid Komarianskyi wrote:
> >> Hello everyone!
> >>
> >> V6 contains an issue for debug builds with CONFIG_GICV3_ESPI=n due to a
> >> mistake in the ASSERT() condition in the is_espi() function. This patch
> >> series fixes the issue and also includes minor fixes according to the
> >> review of V6.
> >>
> >> Summarized description:
> >> This patch series adds support for the extended shared peripheral
> >> interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
> >> and guest domains. The implementation uses a generic approach to handle
> >> eSPIs, similar to regular SPIs, while maintaining compatibility with the
> >> existing SPI range. Functionality remains unchanged for setups that do
> >> not require eSPIs.
> >>
> >> The series includes:
> >> 1) General refactoring of common IRQ operations with GIC registers to
> >> improve code readability, simplify further maintenance and prepare the
> >> key functions for eSPI implementation.
> >> 2) Introducing a new Kconfig option (default n) to enable or disable
> >> eSPI support. Disabling this option prevents unnecessary resource
> >> allocation for setups that do not require eSPIs.
> >> 3) Adding additional resources to store required information and operate
> >> with up to 1024 interrupts from eSPI range.
> >> 4) Adjusting assertions and checks to pass verification for INTIDs in
> >> the eSPI range.
> >> 5) Configuration of eSPI-specific registers during GIC initialization
> >> for systems with GICv3.1+ hardware.
> >> 6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
> >> access and operate within the eSPI's INTIDs.
> >> 7) Updating documentation and CHANGELOG to reflect the changes made for eSPI
> >> support.
> >>
> >> Also, to simplify reviewing, please find below link to unsquashed patches, that
> >> are on top of every patch, that is changed in the series, compared to V6:
> >> https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7-unsquashed/
> >>
> >> Github branch with patch series:
> >> https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v7/
> >>
> >> Changes in V7:
> >> - individual changes in patches
> >>
> >> Link on V6:
> >> - https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00296.html
> >>
> >> Changes in V6:
> >> - individual changes in patches
> >>
> >> Link on V5:
> >> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.html
> >>
> >> Changes in V5:
> >> - individual changes in patches
> >>
> >> Link on V4:
> >> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.html
> >>
> >> Changes in V4:
> >> - added a patch for documentation
> >> - individual changes in patches
> >>
> >> Link on V3:
> >> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.html
> >>
> >> Changes in V3:
> >> - added a patch to update CHANGELOG.md
> >> - individual changes in patches
> >>
> >> Link on V2:
> >> - https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.html
> >>
> >> Changes in V2:
> >> - added 2 more patches to implement helper
> >>    functions for gic/vgic:
> >>    xen/arm: gic: implement helper functions for INTID checks
> >>    xen/arm: vgic: implement helper functions for virq checks
> >> - removed 2 patches:
> >>    xen/arm/irq: allow assignment/releasing of eSPI interrupts
> >>    xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
> >>    since their functionality can be moved to appropriate patches after
> >>    introducing patches with helper functions
> >> - individual changes in patches
> >>
> >> Link on V1:
> >> - https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.html
> >>
> >> Leonid Komarianskyi (12):
> >>    xen/arm: gicv3: refactor obtaining GIC addresses for common operations
> >>    xen/arm: gic: implement helper functions for INTID checks
> >>    xen/arm: vgic: implement helper functions for virq checks
> >>    xen/arm/irq: add handling for IRQs in the eSPI range
> >>    xen/arm: gicv3: implement handling of GICv3.1 eSPI
> >>    xen/arm/irq: allow eSPI processing in the gic_interrupt function
> >>    xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
> >>    xen/arm: vgic: add resource management for extended SPIs
> >>    xen/arm: domain_build/dom0less-build: adjust domains config to support
> >>      eSPIs
> >>    xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
> >>    doc/man: update description for nr_spis with eSPI
> >>    CHANGELOG.md: add mention of GICv3.1 eSPI support
> >>
> >>   CHANGELOG.md                           |   2 +
> >>   docs/man/xl.cfg.5.pod.in               |  13 +-
> >>   xen/arch/arm/Kconfig                   |   8 +
> >>   xen/arch/arm/dom0less-build.c          |   2 +-
> >>   xen/arch/arm/domain_build.c            |   2 +-
> >>   xen/arch/arm/gic-v3.c                  | 195 +++++++++++++++++++----
> >>   xen/arch/arm/gic.c                     |   8 +-
> >>   xen/arch/arm/include/asm/gic.h         |  28 ++++
> >>   xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
> >>   xen/arch/arm/include/asm/irq.h         |  38 +++++
> >>   xen/arch/arm/include/asm/vgic.h        |  56 ++++++-
> >>   xen/arch/arm/irq.c                     |  62 +++++++-
> >>   xen/arch/arm/vgic-v3.c                 | 203 ++++++++++++++++++-----
> >>   xen/arch/arm/vgic.c                    | 212 +++++++++++++++++++++++--
> >>   xen/arch/arm/vgic/vgic.c               |   5 +
> >>   15 files changed, 762 insertions(+), 112 deletions(-)
> >>
> >> --
> >> 2.34.1
> >>
> 
> Best regards,
> Leonid
> 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 02:16:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 02:16:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115802.1462278 (Exim 4.92)
	(envelope-from )
	id 1uvnu5-0006rt-Qq; Tue, 09 Sep 2025 02:16:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115802.1462278; Tue, 09 Sep 2025 02:16:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvnu5-0006rm-O7; Tue, 09 Sep 2025 02:16:17 +0000
Received: by outflank-mailman (input) for mailman id 1115802;
 Tue, 09 Sep 2025 02: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 1uvnu4-0006re-ME
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 02:16:16 +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 f05f1541-8d22-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 04:16: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 26F3543E29;
 Tue,  9 Sep 2025 02:16:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07D67C4CEF1;
 Tue,  9 Sep 2025 02:16: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: f05f1541-8d22-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1757384164;
	bh=xKkpvDQWGBF1SNQMUrwQak6dbS7+Kaawp2n8VZWz+M4=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Ji+MvIMJjnCzrm7JJouZjdcrryC08RI/Y6GwKlm7FmWFFjuLZhlIDnztPmdSccd+S
	 XVAieks/t16/1DrhnW8YjQQ5RGHB69prkFM4EIJDH7kM1ar3vtf0c34VBvQ5OpxJXk
	 jgytnzkbwbD6aEm0RBJgjRvCRYzqKtlr879Qt3uE=
Date: Mon, 8 Sep 2025 19:16:02 -0700
From: Andrew Morton 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Alexander Gordeev
 , Andreas Larsson , Boris
 Ostrovsky , Borislav Petkov ,
 Catalin Marinas , Christophe Leroy
 , Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" , Ingo Molnar
 , Jann Horn , Juergen Gross
 , "Liam R. Howlett" , Lorenzo
 Stoakes , Madhavan Srinivasan
 , Michael Ellerman , Michal Hocko
 , Mike Rapoport , Nicholas Piggin
 , Peter Zijlstra , Ryan Roberts
 , Suren Baghdasaryan , Thomas
 Gleixner , Vlastimil Babka , Will
 Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
Message-Id: <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
In-Reply-To: <20250908073931.4159362-1-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon,  8 Sep 2025 08:39:24 +0100 Kevin Brodsky  wrote:

> The main change enabling nesting is patch 2, following the approach
> suggested by Catalin Marinas [4]: have enter() return some state and
> the matching leave() take that state. 

This is so totally the correct way.  Thanks.


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 05:41:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 05:41:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115821.1462288 (Exim 4.92)
	(envelope-from )
	id 1uvr6D-0006Vy-Ec; Tue, 09 Sep 2025 05:41:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115821.1462288; Tue, 09 Sep 2025 05: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 1uvr6D-0006Vq-AW; Tue, 09 Sep 2025 05:41:01 +0000
Received: by outflank-mailman (input) for mailman id 1115821;
 Tue, 09 Sep 2025 05:41: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 1uvr6C-0006Vk-1s
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 05:41:00 +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 8f13f1ae-8d3f-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 07:40:58 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 0BE5E601EF;
 Tue,  9 Sep 2025 05:40:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA0D0C4CEF4;
 Tue,  9 Sep 2025 05:40: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: 8f13f1ae-8d3f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1757396455;
	bh=fLT6sZq3hOuocdqB+Er3MIxGIa7A226lDCyWybWeKb0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=ac3AtU0MqGUoC9Eky+9KyLtx9biLH0jbhomUAhOb9ruR7c2j0fSSNnyF7J5pqgv3k
	 foKu3tqX/cVrmmALEDgQok2HJxXlYlCuqYu52g6qJkaq/U2HxlfxN2JIs/wIPe9xj/
	 lJgOpn+VQzJMFZkYputFzcFbXsTrbwF4GLqtj+KE=
Date: Mon, 8 Sep 2025 22:40:54 -0700
From: Andrew Morton 
To: Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Alexander Gordeev
 , Andreas Larsson , Boris
 Ostrovsky , Borislav Petkov ,
 Catalin Marinas , Christophe Leroy
 , Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" , Ingo Molnar
 , Jann Horn , Juergen Gross
 , "Liam R. Howlett" , Lorenzo
 Stoakes , Madhavan Srinivasan
 , Michael Ellerman , Michal Hocko
 , Mike Rapoport , Nicholas Piggin
 , Peter Zijlstra , Ryan Roberts
 , Suren Baghdasaryan , Thomas
 Gleixner , Vlastimil Babka , Will
 Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-Id: <20250908224054.0a1969b493d8a837addd782e@linux-foundation.org>
In-Reply-To: <20250908073931.4159362-3-kevin.brodsky@arm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
	<20250908073931.4159362-3-kevin.brodsky@arm.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon,  8 Sep 2025 08:39:26 +0100 Kevin Brodsky  wrote:

> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> (taking and returning no value). This is proving problematic in
> situations where leave() needs to restore some context back to its
> original state (before enter() was called). In particular, this
> makes it difficult to support the nesting of lazy_mmu sections -
> leave() does not know whether the matching enter() call occurred
> while lazy_mmu was already enabled, and whether to disable it or
> not.
> 
> This patch gives all architectures the chance to store local state
> while inside a lazy_mmu section by making enter() return some value,
> storing it in a local variable, and having leave() take that value.
> That value is typed lazy_mmu_state_t - each architecture defining
> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> For now we define it as int everywhere, which is sufficient to
> support nesting.
> 
> The diff is unfortunately rather large as all the API changes need
> to be done atomically. Main parts:

This has a build error:

  CC      arch/x86/kernel/asm-offsets.s
In file included from ./arch/x86/include/asm/irqflags.h:102,
                 from ./include/linux/irqflags.h:18,
                 from ./include/linux/spinlock.h:59,
                 from ./include/linux/swait.h:7,
                 from ./include/linux/completion.h:12,
                 from ./include/linux/crypto.h:15,
                 from arch/x86/kernel/asm-offsets.c:9:
./arch/x86/include/asm/paravirt.h: In function 'arch_enter_lazy_mmu_mode':
./arch/x86/include/asm/paravirt.h:534:16: error: 'LAZY_MMU_DEFAULT' undeclared (first use in this function)
  534 |         return LAZY_MMU_DEFAULT;
      |                ^~~~~~~~~~~~~~~~
./arch/x86/include/asm/paravirt.h:534:16: note: each undeclared identifier is re

which gets fixed up later in the series.


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 06:30:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 06:30:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115832.1462298 (Exim 4.92)
	(envelope-from )
	id 1uvrrX-0003lf-PH; Tue, 09 Sep 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 1115832.1462298; Tue, 09 Sep 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 1uvrrX-0003lY-M2; Tue, 09 Sep 2025 06:29:55 +0000
Received: by outflank-mailman (input) for mailman id 1115832;
 Tue, 09 Sep 2025 06:29: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 1uvrrV-0003lQ-Rp
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 06:29:53 +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 5f0a76d0-8d46-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 08:29:43 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-55f753ec672so5928364e87.2
 for ; Mon, 08 Sep 2025 23:29: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: 5f0a76d0-8d46-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757399383; x=1758004183; 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=6EfhFX4EPnLTi9YabeTCEqkgK8LItjVconuUeEtWqAA=;
        b=ikaxbMo6HoM0JB15r+oxmf+B+i6N96XLjsXGn8RrzDt90wvg+NtHw5bm5DsXvX2aBW
         h4WxmwNhhc1xKWYoF7zD5gvYEetfVHeYjcCTjuitjYMP/lTB+9cGxO7AUhPnnJtgK1Qj
         xemS+0ZtrGQEMVvJ36NunbSTqcuar2iuJ+maY7bw5SU6kw1cAnAxr91wvGfSC6kKdnw8
         WWpTGHe+HQG4wgyuUdybHh4U8oTdDMVerInR1sfQrjuCAWsY/2IjbC8kZVsv0rFbuhl9
         uLNwmMv2hlTTOI2req8s52WsGBe22xBY43FQar6BaYlRj6wLtHdhNyQG9qlYtgPxwHSW
         Nrew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757399383; x=1758004183;
        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=6EfhFX4EPnLTi9YabeTCEqkgK8LItjVconuUeEtWqAA=;
        b=a2HKYP1GYCTTp0363B+cDq6SLEXi8jVGXpW+HmmHroLBz4X7K3qr7jHq0Jb+RRJOLy
         DT4s0tacgaSe64PcKxrNJAtwJuR5knUgSKiPk0FxAtKgE3QJI9K84UT89B1q+Z3mrnLn
         IO6b1QGWBpKxJO03/EddPp1KxQOAJ/35WUmkb0WUKpvBcgdbxJi98Lp4jk2UGnQocywS
         izebL+RIULs6inoYqunIVLPBEPcKwqGvMKj3UPMZF9IfbW2lLyKVAn63sbr0dgjXAH4v
         CjYPbowbheoll26jVa5xTI2EqJQvkua8mSLUAJRUSBZQ3+Xgg3m9ZuINF9sTZtbbr/mz
         jMiw==
X-Forwarded-Encrypted: i=1; AJvYcCVeciYX7m8ZN3YsP7F1pQllnogiEwVWh+3QbMW3nWMv7DwfBNwDSclPec45bgUrAQjh2oxCpDa1R0w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxtgw8ek1DRfHZoNAty+6FFVNtVcz0D3L8BehWnFu9bGrW92ahZ
	0lo/Z+afgnEP0uU37p+82Jvq97OeVLxJe8IH3TDcvHGo+T3Gh8deI0nzlDQsUmI9yfMHOydxsvh
	R7aFpnDbSsDOVhoSCaRoQLcQ5glHAjTU=
X-Gm-Gg: ASbGncsYNLiaXv29SYb4byWMFk3YpvCXOfcVxFyaT+sfajnaPgsEZ9tKJmE2OMmhK/g
	PrldFEPWFNXj8gz46Vjx1wq3cuIe10aA6aYrimtk/HpMeFLQBWcWxgskOL+JhfmV/pLbn20OsLM
	VekoprKV9VNhNm1mWFjfNJlOqOxV7huwpKZqkLVKnFYK8XjQ7uGH6SWEkPAa8QFjvVo+H4JeuVW
	8W6Pw2sjhGucFT2jEByWxVU26c=
X-Google-Smtp-Source: AGHT+IEZi7L5Kp4FAyb0YJRiuQ3mktbQ5k5+TR21BPDwymSXAYH1CiA8503weYI5HEC5134lOqhvQqiGTFS0YPI+0T4=
X-Received: by 2002:a05:6512:318e:b0:55f:6580:8160 with SMTP id
 2adb3069b0e04-562618e1416mr3126576e87.42.1757399382292; Mon, 08 Sep 2025
 23:29:42 -0700 (PDT)
MIME-Version: 1.0
References:  <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com>
  
In-Reply-To: 
From: Mykola Kvach 
Date: Tue, 9 Sep 2025 09:29:30 +0300
X-Gm-Features: Ac12FXyHOZa75W805XZrPLNNtZjbcvTtaz-ssbdZKnfGryAhd1KpzBKlM6lhY58
Message-ID: 
Subject: Re: [PATCH v6 11/13] 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?= , 
	Saeed Nowshadi , Mykyta Poturai , 
	Mykola Kvach , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Wed, Sep 3, 2025 at 7:31=E2=80=AFAM Mykola Kvach  wrote:
>
> Hi Jan,
>
> On Tue, Sep 2, 2025 at 5:33=E2=80=AFPM Jan Beulich  wr=
ote:
> >
> > On 02.09.2025 00:10, Mykola Kvach wrote:
> > > --- a/xen/common/domain.c
> > > +++ b/xen/common/domain.c
> > > @@ -1317,7 +1317,11 @@ int domain_shutdown(struct domain *d, u8 reaso=
n)
> > >          d->shutdown_code =3D reason;
> > >      reason =3D d->shutdown_code;
> > >
> > > +#if defined(CONFIG_SYSTEM_SUSPEND) && defined(CONFIG_ARM)
> > > +    if ( reason !=3D SHUTDOWN_suspend && is_hardware_domain(d) )
> > > +#else
> > >      if ( is_hardware_domain(d) )
> > > +#endif
> > >          hwdom_shutdown(reason);
> >
> > I still don't follow why Arm-specific code needs to live here. If this
> > can't be properly abstracted, then at the very least I'd expect some
> > code comment here, or at the very, very least something in the descript=
ion.
>
> Looks like I missed your comment about this in the previous version of
> the patch series.
>
> >
> > From looking at hwdom_shutdown() I get the impression that it doesn't
> > expect to be called with SHUTDOWN_suspend, yet then the question is why=
 we
> > make it into domain_shutdown() with that reason code.
>
> Thank you for the question, it is a good one.
>
> Thinking about it, with the current implementation (i.e. when the HW doma=
in
> requests system suspend), we don't really need to call domain_shutdown().
> It would be enough to pause the last running vCPU (the current one) just =
to
> make sure that we don't return control to the domain after exiting from t=
he
> hvc trap on the PSCI SYSTEM_SUSPEND command. We also need to set
> shutting_down to ensure that any asynchronous code or timer callbacks
> behave properly during suspend (i.e. skip their normal actions).

If we avoid calling domain_shutdown() for the hardware domain during
suspend, we would need to duplicate most of its logic except for the
hwdom_shutdown() call, which is not ideal.

To improve this, I suggest introducing a helper function:

    static inline bool need_hwdom_shutdown(const struct domain *d, u8 reaso=
n)
    {
        if ( IS_ENABLED(CONFIG_SYSTEM_SUSPEND) && IS_ENABLED(CONFIG_ARM) )
            return is_hardware_domain(d) && reason !=3D SHUTDOWN_suspend;

        return is_hardware_domain(d);
    }

Then, in domain_shutdown(), we can call need_hwdom_shutdown() instead
of directly checking is_hardware_domain(d). This keeps the logic
readable and avoids code duplication.

What do you think about this approach?

>
> However, if we consider a setup with two separate domains -- one control =
and
> one HW -- where the control domain makes the final decision about system
> suspend, then we would need to call __domain_finalise_shutdown() during t=
he
> HW domain suspend in order to notify the control domain that the HW domai=
n
> state has changed. The control domain would then check this state and cal=
l
> system suspend for itself after confirming that all other domains are in =
a
> suspended state.
>
> I already added a TODO about moving this logic to the control domain. So,=
 at
> first sight (unless I am missing something), we can avoid extra modificat=
ions
> inside domain_shutdown() and simply avoid calling it in case of HW domain=
.
>
> >
> > Jan
>
> Best regards,
> Mykola

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 06:58:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 06:58:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115855.1462311 (Exim 4.92)
	(envelope-from )
	id 1uvsIc-00084N-0S; Tue, 09 Sep 2025 06:57:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115855.1462311; Tue, 09 Sep 2025 06:57: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 1uvsIb-00084G-Tw; Tue, 09 Sep 2025 06:57:53 +0000
Received: by outflank-mailman (input) for mailman id 1115855;
 Tue, 09 Sep 2025 06: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 1uvsIZ-000848-Li
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 06:57:51 +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 4bfc2c66-8d4a-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 08:57:49 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b0472bd218bso802573666b.1
 for ; Mon, 08 Sep 2025 23:57: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
 a640c23a62f3a-b0410a65a68sm2249823266b.110.2025.09.08.23.57.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 08 Sep 2025 23:57: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: 4bfc2c66-8d4a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757401069; x=1758005869; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AedlcGDLqdRSDwDh8sGmChq6MV0cbTpATfkdtg6njIk=;
        b=FAN5u3xsic+JUMJps+UG/3BkGUKqHkuAg7CGuOTKC89rH/h4y3TDnUDS4TpJnrE9td
         d0uzJGipOtvo0sOMPi8E6FbfGLI84VP/3TmWqyo+uPqUzIb6l9MK3w3bj/VwThSs7a16
         FGAYhyPv/1iY4s5cvWabc9AtdsFIL9xA6jPLocNkPl4xVwlJ+bwT/J8QKc5ZJD3Hfxc3
         IWSJ2P3j2PDs9rYYZQHIksxQ/Uie2+EoVvHF5Newh1fIA3YD6k9F7haxMA89eUulpp4L
         4J/O9WLJoe1WjZYXsAnV0MDf9Gk9enMD5IRdgnIhF4KiODHetZPN/ozkgOndfDjdvDb5
         FRHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757401069; x=1758005869;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AedlcGDLqdRSDwDh8sGmChq6MV0cbTpATfkdtg6njIk=;
        b=ffVqJqGa+YH2ud8qzKtuk9grZUL5dbxjRKrQEynWJzOtkoEf5/ymQ/pnuNyXhK6L3n
         qhv9pJEfrW6xPo2tpH0xf+jWqk3wAk6VCxJImi/CWUp8izzWGDRLqzat6ogpToWn01fc
         qLyyInbuWC7cwTctD7ABMVSpH+aG/7QYm1F2QYlUx2yiADy6LrApWQwVmQ4P9pmAGetj
         IAZ+nzS2SNYw/c+q3p6WW/p8N8dCPVdGFoQDDBAJVhMWZcQoCkee8tGSDZ15h+QpPsFx
         50uSeufB4L7Fch95Mfd7MF4J/2Kmozct9jNavG5SBV5Jo45942yiQ2zxE917xcAhXB3j
         uwaw==
X-Forwarded-Encrypted: i=1; AJvYcCUoGY5FjyRJacAUZa6GjDTqJlSH/m60Yy2jdiT5SB2seljNOwoJinp8fVFoS/Dowr64Or9Ab/rwH+0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyN0vF3E7sSlQ0uFcpApL3sZaONvAbABIfF0mT8hacFgRqGLc7q
	zvnUyi92FgIpnjnTB7qRZ4AdDSeq0anmimNp0PrLaZylY1tuPeuiBJONV3dMZ6RL4w==
X-Gm-Gg: ASbGncu4WZ2/6rxF5/zGEHzfJFIkDWUbsH0qNUhoqja+0Sg0BQYfVclAqFlmqJcnvGm
	j+Uu0dUOQuig7GNSeaQhf7UtQHiglBS4p20q92wPLBsmGznc5bgK41upHcQix1rGoARG4wKa4xb
	gyfI7ABclK/1SiyTDl8Ecwx7xSQSGWcOdN9jDYAgqxbRQDurlostEV+M7+NbF0wOlkrhXITS6Rf
	QcDhvWjF/HWwaOey0GF+shReejKoWFxpzQrCzoKFC4mZqfU13hH3W3/pu7QI9CH9O5oVMn/WF61
	2/2UYHef3rKo5eGbhgXehfNlB460bFOjqUJ+qyDFvPLWcI6gUTjumkawPv4Uw3x+7uwDkdtsgNW
	UW+d5OHYh9SMbxnPOTvpT8XknVxknN29ed7Sy1igN0wbjr0C6YZCJb6pPrYZxJogIUTR4Ddo1F6
	kfjXN5xjJTnE+SWosrvg==
X-Google-Smtp-Source: AGHT+IEQQWUt+8z+RpzQuIzfM5VmlITE+nJynGsnk1LiI0T+lwHySFQJ1pRULSv5sjW/3VhLjerrKQ==
X-Received: by 2002:a17:907:9955:b0:b07:6537:264c with SMTP id a640c23a62f3a-b076537276cmr188524566b.37.1757401068504;
        Mon, 08 Sep 2025 23:57:48 -0700 (PDT)
Message-ID: <21f2f6e1-cbf7-4b36-bbba-bffc2dab3422@suse.com>
Date: Tue, 9 Sep 2025 08:57:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 11/13] 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?= ,
 Saeed Nowshadi ,
 Mykyta Poturai ,
 Mykola Kvach , xen-devel@lists.xenproject.org
References: 
 <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09.09.2025 08:29, Mykola Kvach wrote:
> On Wed, Sep 3, 2025 at 7:31 AM Mykola Kvach  wrote:
>> On Tue, Sep 2, 2025 at 5:33 PM Jan Beulich  wrote:
>>> On 02.09.2025 00:10, Mykola Kvach wrote:
>>>> --- a/xen/common/domain.c
>>>> +++ b/xen/common/domain.c
>>>> @@ -1317,7 +1317,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);
>>>
>>> I still don't follow why Arm-specific code needs to live here. If this
>>> can't be properly abstracted, then at the very least I'd expect some
>>> code comment here, or at the very, very least something in the description.
>>
>> Looks like I missed your comment about this in the previous version of
>> the patch series.
>>
>>>
>>> From looking at hwdom_shutdown() I get the impression that it doesn't
>>> expect to be called with SHUTDOWN_suspend, yet then the question is why we
>>> make it into domain_shutdown() with that reason code.
>>
>> Thank you for the question, it is a good one.
>>
>> Thinking about it, with the current implementation (i.e. when the HW domain
>> requests system suspend), we don't really need to call domain_shutdown().
>> It would be enough to pause the last running vCPU (the current one) just to
>> make sure that we don't return control to the domain after exiting from the
>> hvc trap on the PSCI SYSTEM_SUSPEND command. We also need to set
>> shutting_down to ensure that any asynchronous code or timer callbacks
>> behave properly during suspend (i.e. skip their normal actions).
> 
> If we avoid calling domain_shutdown() for the hardware domain during
> suspend, we would need to duplicate most of its logic except for the
> hwdom_shutdown() call, which is not ideal.

That is, you effectively take back what you said earlier (as to not needing
to call domain_shutdown())?

> To improve this, I suggest introducing a helper function:
> 
>     static inline bool need_hwdom_shutdown(const struct domain *d, u8 reason)
>     {
>         if ( IS_ENABLED(CONFIG_SYSTEM_SUSPEND) && IS_ENABLED(CONFIG_ARM) )
>             return is_hardware_domain(d) && reason != SHUTDOWN_suspend;
> 
>         return is_hardware_domain(d);
>     }

If I see a call to a function of this name, I'd expect the "hardware
domain" nature already having been checked. I.e. a call site would
rather look like

    if ( is_hardware_domain(d) && need_hwdom_shutdown(d, reason) )
        ...;

> Then, in domain_shutdown(), we can call need_hwdom_shutdown() instead
> of directly checking is_hardware_domain(d). This keeps the logic
> readable and avoids code duplication.
> 
> What do you think about this approach?

Well, there's still the CONFIG_ARM check in there that I would like to
see gone. (As a nit, the use of u8 would also want to go away.)

Furthermore with continuing to (ab)use domain_shutdown() also for the
suspend case (Dom0 isn't really shut down when suspending, aiui), you
retain the widening of the issue with the bogus setting of
d->is_shutting_down (and hence the need for later clearing the flag
again) that I mentioned elsewhere. (Yes, I remain of the opinion that
you don't need to sort that as a prereq to your work, yet at the same
time I think the goal should be to at least not make a bad situation
worse.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 07:42:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 07:42:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115866.1462322 (Exim 4.92)
	(envelope-from )
	id 1uvszh-0005wt-4Q; Tue, 09 Sep 2025 07:42:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115866.1462322; Tue, 09 Sep 2025 07:42: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 1uvszh-0005wm-1C; Tue, 09 Sep 2025 07:42:25 +0000
Received: by outflank-mailman (input) for mailman id 1115866;
 Tue, 09 Sep 2025 07:42: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 1uvszg-0005wg-1d
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 07:42:24 +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 846e9651-8d50-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 09:42:22 +0200 (CEST)
Received: from SJ0PR13CA0173.namprd13.prod.outlook.com (2603:10b6:a03:2c7::28)
 by DS0PR12MB7728.namprd12.prod.outlook.com (2603:10b6:8:13a::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 07:42:18 +0000
Received: from CY4PEPF0000FCC1.namprd03.prod.outlook.com
 (2603:10b6:a03:2c7:cafe::6a) by SJ0PR13CA0173.outlook.office365.com
 (2603:10b6:a03:2c7::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.13 via Frontend Transport; Tue,
 9 Sep 2025 07:42:18 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000FCC1.mail.protection.outlook.com (10.167.242.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Tue, 9 Sep 2025 07:42:17 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 9 Sep
 2025 00:42:16 -0700
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17
 via Frontend Transport; Tue, 9 Sep 2025 00:42:15 -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: 846e9651-8d50-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HpCWpkkbSN4u7Yo0RRkLXjJYUXd3RSw46zE8sTgfssXaSXMvcCWDNmR0rrXKquKYruPHbSyK0wJ/pt8VLBJaJ8bEeBFntqsrFvyuTUDIPMGDdmgiHv8e/fVBGMwDzQ1Xf6KNWe48ai7uCzlRTkE+QBkf6wC+DY3qgqK5Y6w0uUlTIn6RZ08spftsM+kXkgo0P2xnp0LfF4XoaLqkokOvcliiMOY9LUJLw37JLjn60xB5Tly1jQOmaSp5SUnwlwqgyPMuK8k39OWC+kD42YueCxd0p++E8s5gbZgXNcbd8WU6S1of3ESL8qeD47B2GN03l3mOCMKJXjqokMUYW1/NoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MR7vzHeHpkiZA8Ij/yUkkenqrBbLVUu1GJxFj31LfGA=;
 b=FVLLYSAmV6BJ71PUatiZsSIStOb9UlBQkzkJhTMt1ughfbnSpqzskKLkbmIZj0Q0AvEJm3Il+dXkxt06xbTRxe6BihTG0JsBonIb6I6ltzPORBBjSdMRRk6lBTAYciWvpKLpSA7FyEhTDHqTzOX40UYn+cyuv38MBGR2gnKUtK55PUN6H6Cnf2iaSosqGwlSlJfI6KIEFDxkpiqoOMqeVPL2FfodJXQM/wcfJ/WdNg+QJt6WnKFq4ns4BFoVmLBUvo/0RTgsBiUhACvfNyQQE8/3htNq2t6BXZBREPYQ/IohuZTagm4ru6ux7RyVxBDah3YsIWt4MU8YSzH6uZUJMw==
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=MR7vzHeHpkiZA8Ij/yUkkenqrBbLVUu1GJxFj31LfGA=;
 b=wUTZO3hFqPVwIEy5t6BpW/ienDL6spea2oW2bM75m4vypdWG1sDq4kY0YUhefPiyBPWnFrKGs6xsKxxpvVapFtQls6HYc2ROTDxjsGuHyEbqeg55L9e4t8tIzYzjud6A7JQw309jGGzLqqhuRD7Fcezd6OycMQ7Hs+eETPy8TDU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Michal Orzel 
To: 
CC: , Michal Orzel 
Subject: [ImageBuilder] Use LOAD_CMD by default if not specified in load_file()
Date: Tue, 9 Sep 2025 09:41:41 +0200
Message-ID: <20250909074141.7356-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC1:EE_|DS0PR12MB7728:EE_
X-MS-Office365-Filtering-Correlation-Id: 46f742a6-98b0-4add-974f-08ddef746683
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?CD9ZJMAfPxVasvv0h23QHvXwQQl8ggqDNK/PFRM/I5ggH6AlDl3j9g4iZDaS?=
 =?us-ascii?Q?Y+sgsdYEH3talqz30ksV0h7TvQgF2cJRjoecjG5aJoci639phftJqHQqzv0P?=
 =?us-ascii?Q?4xeNmxt9FUS3tsJVq7eLMxd/1c9toSam6FRtpMHyFqsjbCu6JndiEjFhZ+ef?=
 =?us-ascii?Q?/PaAmmY5reQbILk88Iw/fAaFl9pTlESybMAK/cHwqBMsHDsQER30eKDpIp6n?=
 =?us-ascii?Q?BpzrCEQ8eNayzQmYsn/hRderJkmtCjYISZFAOGl0DWfmEFCd7Hs21/amWgKY?=
 =?us-ascii?Q?6wn8QcI1StXArRG3J/dFQ3gTSbapSJOTBoK/tvqTteTeWOxf4tnFL0xliA8g?=
 =?us-ascii?Q?0566JkNC8w+W/c8HMI+8w95FT4B2fhnsm+Qjq2f2j46+ctsFH9Bqb5ID3qBP?=
 =?us-ascii?Q?ua08SF3DyXyDmEQoXIe6taGXSeTAEQAn82Jti6OuBNoWan8LwMmyhXmeRJEI?=
 =?us-ascii?Q?bR0goRS7m3hCKEA2jM4Yqtdh2nDZlhztSq8UyOBVlw5Ov3ND9yJpSXKLEJwq?=
 =?us-ascii?Q?MD1T5uYumMrSsXL8cJTgOIW02oFok8hyqEC8nDYFSF3rAkaTa/nQDQovHnJ/?=
 =?us-ascii?Q?GZb8JISe8rlZmWpMTMutPq3FVIukB822tRs/ZPGYQ+sIb1eRBhDMzj13g2t6?=
 =?us-ascii?Q?WhSDnQs+C5rI+rhPCF/f5RcAQ+h1/Po4BR1x5l9J91RvyFm1vlAT0rErD4Ev?=
 =?us-ascii?Q?GLFW5U8W1x/IfgialXtFfVUFysT9KJh//bNS+poUaS4iyte9LcMtMUIv7zCA?=
 =?us-ascii?Q?Ns8xwHltoYXi9CVi+oDGpWp8D/m8nX8s0BagLT/nDpzlxiVwh0XS74Sidp/Y?=
 =?us-ascii?Q?MI4yu5+3ei6qqpuF8ajc0Ui9ud08gVYA+5BTmpkydVjwa3n4F0c6/fww4JQW?=
 =?us-ascii?Q?1sK+h6WwTzdfJT9+MijlsYdG0Cxk4W9IRnwXdsof4TD2kgr4+4CRYoNTwBV/?=
 =?us-ascii?Q?6czgJQ2uP/ZgFW+Fwku3OmAF+09JWF0LGtAY7tR4WF+F1onchDv+a5hrS6E2?=
 =?us-ascii?Q?8HdqPAPg1S+bRZ+Ad9UhFB4iCUQo4IV+BpAhz+UIEPup8yNSv+ACPDyauSF/?=
 =?us-ascii?Q?d8zp7j7jYytFfSkGFPk253wLcm3E/yhVY+Z6bGnYF7ZAZJuf9qeEVgeU1fr2?=
 =?us-ascii?Q?8ARpB0zVd+TeCd6RXjbj7s2lemDG+x25ls5XD+duSS/lknq36BbQWHdWD3lD?=
 =?us-ascii?Q?g/82HKT/KkHxsCwJRRHOFcm4JGeIV4Wo1MGUiq2R65yDFzt68W0GovyZWcWj?=
 =?us-ascii?Q?glzQJJs7NOWSitvEU6lq2fYl0ZGn9qjTR/fx+bNeVAphVMU/bCc8BRAjj00m?=
 =?us-ascii?Q?WMOtQEB+t+rOfoEANwgya+5Mt8DAsJ2evvHBms7fMVRT2JyrofvNdM7K+3OF?=
 =?us-ascii?Q?K79SbEa/Zu+3u/8r+E2/XtPwfyv2Q8QYKNlFH5Djo8QKzHTSJ3C0MLzoPFWb?=
 =?us-ascii?Q?CMYeLf1WVjSbi+ff92xb0rBx61yCF2uS33PGIPcdGH5uVaqfV4U9PXmSsUcb?=
 =?us-ascii?Q?zAwwcdP8tBTbcVpkPDVLLhqqR2xhroaDAP23?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 09 Sep 2025 07:42:17.0728
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 46f742a6-98b0-4add-974f-08ddef746683
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCC1.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7728

Commit 061d6782756f modified load_file() to take load command as
argument but did not change all the invocations (e.g. loading standalone
Linux, bitstream, etc.) which broke the output script (load command
empty). Fix it by defaulting to LOAD_CMD if not specified.

Fixes: 061d6782756f ("Add config option to use separate load commands for Xen, DOM0 and DOMU binaries")
Signed-off-by: Michal Orzel 
---
 scripts/uboot-script-gen | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index 849b8f939e81..4f9261035d73 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -736,6 +736,12 @@ function load_file()
     local base="$(realpath $PWD)"/
     local relative_path=${absolute_path#"$base"}
 
+    # Default to LOAD_CMD if not specified
+    if test -z "${load_cmd}"
+    then
+        load_cmd="${LOAD_CMD}"
+    fi
+
     if test "$FIT"
     then
         echo "imxtract \$fit_addr $fit_scr_name $memaddr" >> $UBOOT_SOURCE
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 08:14:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 08:14:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115888.1462331 (Exim 4.92)
	(envelope-from )
	id 1uvtUs-0001u7-Na; Tue, 09 Sep 2025 08:14:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115888.1462331; Tue, 09 Sep 2025 08:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvtUs-0001u0-Kq; Tue, 09 Sep 2025 08:14:38 +0000
Received: by outflank-mailman (input) for mailman id 1115888;
 Tue, 09 Sep 2025 08:14: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 1uvtUr-0001tt-PZ
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 08:14:37 +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 0622135a-8d55-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 10:14:36 +0200 (CEST)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-337f6cdaf2cso39805151fa.2
 for ; Tue, 09 Sep 2025 01:14: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: 0622135a-8d55-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757405676; x=1758010476; 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=NSOcl2lQrpQOBUV/otn8F3Hh70moqQjNoxI4z5jDjVE=;
        b=HtYdzmK/3YgfwTH0e4Q3kD4Fkl/9/dE7z++25vJw+X9/7DqKzZnwMP2nOTeQC50oE8
         H5svL/vnSrpTNWBUYarWL64oHTRFdCxiIJwnH/x7Mo0Zo2JJBv1umuRJE1C/esHw/3S3
         tjJjmqT3+hDweggvtWvngtlFyW8SVtrOaNCV+yPj6ZW1brH+B9jZR05kYGc4BpNx2jX+
         /P1HBE5GQvU4w3AEni0QC1MTJiyT9F2/OxoFzZ0949C4KVFsW0FWAyax/mdJfI3VdjOg
         GGVRYvb/yAVF27M5z97m23Ob91aO7MGIX+V1mn/EzahuBQLUU1vB4IPRrINR8nGDErak
         f4Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757405676; x=1758010476;
        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=NSOcl2lQrpQOBUV/otn8F3Hh70moqQjNoxI4z5jDjVE=;
        b=V3Rvcka0C/lPut/IYoOX2opPJgvmPNMvHcT0v3JyY1uKYHcSv0eze8zACHbszeZ5Sr
         9YGQdlrXKy5Su8GS02foaLjJiYHACJe03RnUXewexadtYyi9aMOAYQkM1ePNxsMlrUyY
         Qhyp/ROCulNvfMVbbDOw3v24F++L326dN7c0wmW2q0qZ2JiDyXUecjBjAR7ZX/F7V2vp
         hHkX7In+G4ME8HBTvlmVxowjQO3Ygk/eDUQ5vsefFHEo/Y91nX6f4DelxelPM+x+b303
         +sinr+PLn2vRZH1Nyu2mKLrn01Q11G334gQyXLhAE/XDXW9n9un7N0tUuMQNETTkanJH
         UxCw==
X-Forwarded-Encrypted: i=1; AJvYcCUTBIDdN1lDEWlTct95YARjOX35eQnBoGNDijA7U/5kIOESIAVjOicmpwbWl+EguMwoiBR/BSLi1xM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxbd8vO00L/SjBzjU7TYyaC0C9T3j+sm8L2fR8cdiAk4UJW9raW
	0Dr9VZhvjaABO/us1mDfF2dzo+dDx4/JJa0AnOkLhuXq90cStvdH1aqj8iwUF3t9n0H8/4ooGho
	0nJiE7WUQE3VtGCfRIXo2Im95IzKyzP8=
X-Gm-Gg: ASbGncv7ip7S9ZuWXoFv4eH8CXCaVIE021gHjdD5LOkwpaDDVQ3xSvohshUkaBY770U
	O4OZw5xdxh3Hpgamkw21vpydwZp9ORqfBKYdTv6uhMeW6sxZfCfg39tw+RdKOQcO3gNl5cMDm02
	iFn7XH9lSCLhO3XBTl5jZmiBgQ9Qvxsrq4Edd9kLWW8uOIKSO2q9sPysyL5lblK4Yf6RUGOTKIT
	kCY2Q==
X-Google-Smtp-Source: AGHT+IE9kEU0uZJRPdgQRQ4m7VOm6GOPEkr+AWRiE1dXUs1tKXb0MOL3pJNiprO1Y65NiMddtc3V54qxLdFIvNGjKb8=
X-Received: by 2002:a05:651c:50f:b0:32a:6e77:3e57 with SMTP id
 38308e7fff4ca-33b56ad9de6mr27060271fa.21.1757405675366; Tue, 09 Sep 2025
 01:14:35 -0700 (PDT)
MIME-Version: 1.0
References:  <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com>
  
  <21f2f6e1-cbf7-4b36-bbba-bffc2dab3422@suse.com>
In-Reply-To: <21f2f6e1-cbf7-4b36-bbba-bffc2dab3422@suse.com>
From: Mykola Kvach 
Date: Tue, 9 Sep 2025 11:14:23 +0300
X-Gm-Features: Ac12FXy20zCFqXZDLJZTwC66AIFdRf8kpTF9hKINCh8ac-o-7VuSmQRi1NAIOpM
Message-ID: 
Subject: Re: [PATCH v6 11/13] 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?= , 
	Saeed Nowshadi , Mykyta Poturai , 
	Mykola Kvach , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for the fast response.

On Tue, Sep 9, 2025 at 9:57=E2=80=AFAM Jan Beulich  wrot=
e:
>
> On 09.09.2025 08:29, Mykola Kvach wrote:
> > On Wed, Sep 3, 2025 at 7:31=E2=80=AFAM Mykola Kvach  wrote:
> >> On Tue, Sep 2, 2025 at 5:33=E2=80=AFPM Jan Beulich =
 wrote:
> >>> On 02.09.2025 00:10, Mykola Kvach wrote:
> >>>> --- a/xen/common/domain.c
> >>>> +++ b/xen/common/domain.c
> >>>> @@ -1317,7 +1317,11 @@ int domain_shutdown(struct domain *d, u8 reas=
on)
> >>>>          d->shutdown_code =3D reason;
> >>>>      reason =3D d->shutdown_code;
> >>>>
> >>>> +#if defined(CONFIG_SYSTEM_SUSPEND) && defined(CONFIG_ARM)
> >>>> +    if ( reason !=3D SHUTDOWN_suspend && is_hardware_domain(d) )
> >>>> +#else
> >>>>      if ( is_hardware_domain(d) )
> >>>> +#endif
> >>>>          hwdom_shutdown(reason);
> >>>
> >>> I still don't follow why Arm-specific code needs to live here. If thi=
s
> >>> can't be properly abstracted, then at the very least I'd expect some
> >>> code comment here, or at the very, very least something in the descri=
ption.
> >>
> >> Looks like I missed your comment about this in the previous version of
> >> the patch series.
> >>
> >>>
> >>> From looking at hwdom_shutdown() I get the impression that it doesn't
> >>> expect to be called with SHUTDOWN_suspend, yet then the question is w=
hy we
> >>> make it into domain_shutdown() with that reason code.
> >>
> >> Thank you for the question, it is a good one.
> >>
> >> Thinking about it, with the current implementation (i.e. when the HW d=
omain
> >> requests system suspend), we don't really need to call domain_shutdown=
().
> >> It would be enough to pause the last running vCPU (the current one) ju=
st to
> >> make sure that we don't return control to the domain after exiting fro=
m the
> >> hvc trap on the PSCI SYSTEM_SUSPEND command. We also need to set
> >> shutting_down to ensure that any asynchronous code or timer callbacks
> >> behave properly during suspend (i.e. skip their normal actions).
> >
> > If we avoid calling domain_shutdown() for the hardware domain during
> > suspend, we would need to duplicate most of its logic except for the
> > hwdom_shutdown() call, which is not ideal.
>
> That is, you effectively take back what you said earlier (as to not needi=
ng
> to call domain_shutdown())?

Sure. Looking more closely, I see that for the vCPUs, for example, many fla=
gs
are checked. In the case of the control domain initializing shutdown, I nee=
d
to see the __domain_finalise_shutdown() call.

We currently don=E2=80=99t have any functionality inside arch_domain_shutdo=
wn()
for ARM, but it would be nice to have it in the future. Calling
domain_shutdown() for every domain makes the code more consistent.

The flow for all domains will be the same during suspend, at least within
Xen=E2=80=99s internal code.

>
> > To improve this, I suggest introducing a helper function:
> >
> >     static inline bool need_hwdom_shutdown(const struct domain *d, u8 r=
eason)
> >     {
> >         if ( IS_ENABLED(CONFIG_SYSTEM_SUSPEND) && IS_ENABLED(CONFIG_ARM=
) )
> >             return is_hardware_domain(d) && reason !=3D SHUTDOWN_suspen=
d;
> >
> >         return is_hardware_domain(d);
> >     }
>
> If I see a call to a function of this name, I'd expect the "hardware
> domain" nature already having been checked. I.e. a call site would
> rather look like
>
>     if ( is_hardware_domain(d) && need_hwdom_shutdown(d, reason) )
>         ...;
>

For me, the name simply indicates whether we need to call
hwdom_shutdown() or not, and I expect it to perform the check for whether
the domain is a hardware domain inside the function itself.

> > Then, in domain_shutdown(), we can call need_hwdom_shutdown() instead
> > of directly checking is_hardware_domain(d). This keeps the logic
> > readable and avoids code duplication.
> >
> > What do you think about this approach?
>
> Well, there's still the CONFIG_ARM check in there that I would like to
> see gone. (As a nit, the use of u8 would also want to go away.)

We could combine your proposal from v5 of this patch series, i.e., using th=
e
HAS_HWDOM_SUSPEND extra config together with this helper function:

    static inline bool need_hwdom_shutdown(const struct domain *d)
    {
        bool is_hw_dom =3D is_hardware_domain(d);

        if ( !IS_ENABLED(CONFIG_HAS_HWDOM_SUSPEND) )
            return is_hw_dom && d->shutdown_code !=3D SHUTDOWN_suspend;

        return is_hw_dom;
    }

As for the second argument (reason), I can extract it directly from the
domain structure, as is done in the function above.

>
> Furthermore with continuing to (ab)use domain_shutdown() also for the
> suspend case (Dom0 isn't really shut down when suspending, aiui), you
> retain the widening of the issue with the bogus setting of
> d->is_shutting_down (and hence the need for later clearing the flag
> again) that I mentioned elsewhere. (Yes, I remain of the opinion that
> you don't need to sort that as a prereq to your work, yet at the same
> time I think the goal should be to at least not make a bad situation
> worse.)

>From the perspective of ARM logic inside Xen, we perform the exact same
shutdown steps as for other domains, except that in the end we need to
call Xen suspend.

For a domain with a toolstack, it is possible to have a running Xen
watchdog service. For example, if we have systemd, it can be easily stopped
from the guest because we have hooks and can perform some actions before
suspend.

The same story applies to a Linux kernel driver: if it has PM ops installed
for the Xen watchdog driver, nothing bad happens.

However, in the case of using init.d, it isn=E2=80=99t easy to stop the Xen=
 WDT
automatically right before suspend. Therefore, Xen code has an extra check
(see domain_watchdog_timeout) where it checks the is_shutting_down flag
and does nothing if it is set.

The is_shutting_down flag is easily reset on Xen resume via a
domain_resume call, so I don=E2=80=99t see any problems with that.

>
> Jan

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:00:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:00:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115917.1462362 (Exim 4.92)
	(envelope-from )
	id 1uvuDJ-00085s-Ak; Tue, 09 Sep 2025 09:00:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115917.1462362; Tue, 09 Sep 2025 09: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 1uvuDJ-00085l-7P; Tue, 09 Sep 2025 09:00:33 +0000
Received: by outflank-mailman (input) for mailman id 1115917;
 Tue, 09 Sep 2025 09: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 1uvuDH-00085f-NQ
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:00:31 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6eb1b69c-8d5b-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:00:29 +0200 (CEST)
Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com
 [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-562-qku-7RXjMb6mQF5z-uRibg-1; Tue, 09 Sep 2025 05:00:27 -0400
Received: by mail-wm1-f71.google.com with SMTP id
 5b1f17b1804b1-45a15f10f31so35597445e9.0
 for ; Tue, 09 Sep 2025 02:00:26 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e752238997sm1838274f8f.37.2025.09.09.02.00.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:00: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: 6eb1b69c-8d5b-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757408428;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=FFaNWFCl2wdsjl/T84rwbCzslw/ZOsn9DcOtT4QWrC0=;
	b=O8XofVYIRJ7JdydV/AcXJE6OL/CzP5apt68h114P/51brpsJaH1b/Lk9wp9D3jOzjTm5bj
	SyY3GBBRZRzFnFY7fcz8XB/q8rGkqbGxoqAOTaUA7SNVtSB4zIzNQ1/e+SGFAGkJkKXwxK
	BxXiUxINIGEbRczdgB4W20L0dgBeFxg=
X-MC-Unique: qku-7RXjMb6mQF5z-uRibg-1
X-Mimecast-MFC-AGG-ID: qku-7RXjMb6mQF5z-uRibg_1757408426
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757408426; x=1758013226;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=FFaNWFCl2wdsjl/T84rwbCzslw/ZOsn9DcOtT4QWrC0=;
        b=r/rJHgXv5vbILGDEo8tU8Sax7SU8WVkA5F9QjYqEkS9rcF77TdOPorJoZxyQ+Vtr9p
         axy1ODVt/m28GlsxF3Rzk2zXklrJfc0Dp6bpLmoMDwajr1dByW21TQeNLB0bktVqES1/
         hByPuZqiIi+kHEO5sQK6KuS6rB2uRL+zMFDMzm70CbwOrCeLC4mjnWrKfp1tenYlPpXC
         z15kuvqknEBRmK9WcyPCUd//kmF+ZljMY6ychNBi8h/cXMvmLTLZWcOlKll2jl0xDil2
         M2AMj48vBN1cX9a0Jx5cyD0/Zxszk5T/fgCbGdAHMDfE2AjRmLhGfKt9kPDbReob89Hc
         HHGg==
X-Forwarded-Encrypted: i=1; AJvYcCWG38Cl6OjaeQK4QFzVR2WZVUXBG/do5n3c5xUh3zGH/S8C4kq7YbOv5zOyDwds4sjWcsyrY56Getg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0nhUT6Fli7x3UmoZWRdhzqdkikHE5ZXiI1PplZOf9npPIICFa
	QBafjt8lBTYtTsIhqVoQAvvdoEXeB5OYJxmdYjgtn3ZrGE2lpgQ/yjgbs95SwZ1Gl8D749wSK3i
	NuN7BkXtiSotsRNAgrav1kSXNuOKXpkMUcK8uH4ILC6qvIYuZt9O6RLauImB8m9C9klVk
X-Gm-Gg: ASbGnctLM2ewatmjNaLsJ9hY8Lf8p70mmS3/rpPfUoHjfLfa5cFGaZCLlpPykeAtFVn
	mp6fAFliKGNZyRdQ2kbxKu5TYPJkCzOtsE5SebB5or3ftSOyCCJ9+2XjSMLzHnq0493SmGbnVvG
	VA1C+xY75Us1S1wzEK+Skdal86TaotZp79+iLgy3ptztJSeVbv53b5TtBqmiBrwMlt0EnlZ2sL3
	bJN1sY5NDFzzMxDeXdnbJvF2HSwAcI5mQMdYCQmCi5cLTdQFa0eI+KOXqhDaKDnyjHa2PhrXNkf
	p0xevIp/s5ofLZj8sU6fWxBTGrTMTtuiwqLJTt2ozO/OqAZjV0m4K4bzjkk3aiis/i4FI4dmoFO
	lnJa6LDC5BUB20lR9hdhAPMBNMOViOayN4NNeHrgbW22kfQtD7qo1PGpbAzmOqRaf1kw=
X-Received: by 2002:a05:6000:250c:b0:3e0:b982:ca49 with SMTP id ffacd0b85a97d-3e627a7cc9bmr9939824f8f.2.1757408425692;
        Tue, 09 Sep 2025 02:00:25 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHjFbjC0Ku1RkV979c1EkKILIgMIbFwdRAtmt79V1a4P0VkSugVjLkyPMCm81yr9ZzkyWnCIw==
X-Received: by 2002:a05:6000:250c:b0:3e0:b982:ca49 with SMTP id ffacd0b85a97d-3e627a7cc9bmr9939756f8f.2.1757408425189;
        Tue, 09 Sep 2025 02:00:25 -0700 (PDT)
Message-ID: <97b8023e-90ad-425d-8645-c3dd258e0ff8@redhat.com>
Date: Tue, 9 Sep 2025 11:00:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/7] mm: remove arch_flush_lazy_mmu_mode()
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-2-kevin.brodsky@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <20250908073931.4159362-2-kevin.brodsky@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 0hWWTitszB2IQ0sKJh4zL8UAeSoCBqCH8HxlFdBt4L8_1757408426
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08.09.25 09:39, Kevin Brodsky wrote:
> This function has only ever been used in arch/x86, so there is no
> need for other architectures to implement it. Remove it from
> linux/pgtable.h and all architectures besides x86.
> 
> The arm64 implementation is not empty but it is only called from
> arch_leave_lazy_mmu_mode(), so we can simply fold it there.
> 
> Acked-by: Mike Rapoport (Microsoft) 
> Signed-off-by: Kevin Brodsky 
> ---

Acked-by: David Hildenbrand 

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:06:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:06:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115928.1462372 (Exim 4.92)
	(envelope-from )
	id 1uvuIX-0000Er-Ss; Tue, 09 Sep 2025 09:05:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115928.1462372; Tue, 09 Sep 2025 09:05: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 1uvuIX-0000Ek-Q2; Tue, 09 Sep 2025 09:05:57 +0000
Received: by outflank-mailman (input) for mailman id 1115928;
 Tue, 09 Sep 2025 09:05:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvuIX-0000Ee-8C
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:05:57 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 3098bc18-8d5c-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:05: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 E25F015A1;
 Tue,  9 Sep 2025 02:05:44 -0700 (PDT)
Received: from [10.57.60.124] (unknown [10.57.60.124])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A7EF13F63F;
 Tue,  9 Sep 2025 02: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: 3098bc18-8d5c-11f0-9d13-b5c5bf9af7f9
Message-ID: 
Date: Tue, 9 Sep 2025 11:05:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Andrew Morton 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 <20250908224054.0a1969b493d8a837addd782e@linux-foundation.org>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <20250908224054.0a1969b493d8a837addd782e@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 07:40, Andrew Morton wrote:
> On Mon,  8 Sep 2025 08:39:26 +0100 Kevin Brodsky  wrote:
>
>> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
>> (taking and returning no value). This is proving problematic in
>> situations where leave() needs to restore some context back to its
>> original state (before enter() was called). In particular, this
>> makes it difficult to support the nesting of lazy_mmu sections -
>> leave() does not know whether the matching enter() call occurred
>> while lazy_mmu was already enabled, and whether to disable it or
>> not.
>>
>> This patch gives all architectures the chance to store local state
>> while inside a lazy_mmu section by making enter() return some value,
>> storing it in a local variable, and having leave() take that value.
>> That value is typed lazy_mmu_state_t - each architecture defining
>> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
>> For now we define it as int everywhere, which is sufficient to
>> support nesting.
>>
>> The diff is unfortunately rather large as all the API changes need
>> to be done atomically. Main parts:
> This has a build error:
>
>   CC      arch/x86/kernel/asm-offsets.s
> In file included from ./arch/x86/include/asm/irqflags.h:102,
>                  from ./include/linux/irqflags.h:18,
>                  from ./include/linux/spinlock.h:59,
>                  from ./include/linux/swait.h:7,
>                  from ./include/linux/completion.h:12,
>                  from ./include/linux/crypto.h:15,
>                  from arch/x86/kernel/asm-offsets.c:9:
> ./arch/x86/include/asm/paravirt.h: In function 'arch_enter_lazy_mmu_mode':
> ./arch/x86/include/asm/paravirt.h:534:16: error: 'LAZY_MMU_DEFAULT' undeclared (first use in this function)
>   534 |         return LAZY_MMU_DEFAULT;
>       |                ^~~~~~~~~~~~~~~~
> ./arch/x86/include/asm/paravirt.h:534:16: note: each undeclared identifier is re
>
> which gets fixed up later in the series.

Oh indeed good catch! I don't think there's an easy way to fix this
cleanly due to the header soup. Since it's just a temporary change, I
suggest:

diff --git a/arch/x86/include/asm/paravirt.h
b/arch/x86/include/asm/paravirt.h
index 65a0d394fba1..67b9549b4255 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -531,7 +531,7 @@ static inline lazy_mmu_state_t
arch_enter_lazy_mmu_mode(void)
 {
     PVOP_VCALL0(mmu.lazy_mode.enter);
 
-    return LAZY_MMU_DEFAULT;
+    return 0; /* LAZY_MMU_DEFAULT */
 }
 
 static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)


That will generate a trivial conflict with patch 4, naturally.

Should I send a v3 with that change?

- Kevin


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:07:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:07:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115939.1462382 (Exim 4.92)
	(envelope-from )
	id 1uvuKI-0000sZ-7G; Tue, 09 Sep 2025 09:07:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115939.1462382; Tue, 09 Sep 2025 09:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvuKI-0000sS-41; Tue, 09 Sep 2025 09:07:46 +0000
Received: by outflank-mailman (input) for mailman id 1115939;
 Tue, 09 Sep 2025 09:07: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 1uvuKH-0000sM-9s
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:07:45 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 70cbc60f-8d5c-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 11:07:42 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-408-qxE-bB9NMR-o3888PTzrmw-1; Tue, 09 Sep 2025 05:07:40 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-45b99c18484so22653515e9.1
 for ; Tue, 09 Sep 2025 02:07:40 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45df16070bdsm5517555e9.3.2025.09.09.02.07.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:07: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: 70cbc60f-8d5c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757408861;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=wfLFN6eNqIPI3eYn2mOCbZpQPxjwFCGNIowHmmpIIeQ=;
	b=Flnv04g4BCDwhTa3Te2nd4UcEtZikSvaj5bIKeDTdNkORNU8G53l+63BLDD1z0tdO/t4AY
	hTXVsahiww91T+h9AzU9219OYaYlO/xUk/I78X1fGMDzOXQ5ObK6+lJO/owirQqlWgYF61
	yVyy4I8tKYgg3Slx7xjqomJpeyXUm4g=
X-MC-Unique: qxE-bB9NMR-o3888PTzrmw-1
X-Mimecast-MFC-AGG-ID: qxE-bB9NMR-o3888PTzrmw_1757408859
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757408859; x=1758013659;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wfLFN6eNqIPI3eYn2mOCbZpQPxjwFCGNIowHmmpIIeQ=;
        b=tZ6r3j0yPMKSUG0x55O5jH+GfKLxySVfP+TMJwIFjQ3lUI6SxgW9B16hFmuKqVUF6W
         6rbBAAXzOgb+g1dHO3ipmxGIFAAtIRG5ZQ1UusgOz5I86zw6cqpJjLcpuesgAGyB4nRF
         BndU4Zqv08LHF3fiqgVbSguf9iCPx31bYLQEWusmqp9835tFqjHVoAxI8i1wbWEVfujv
         iH8o//3VVaUQB6oFYiF2GrEByt6IfSKvFpvvwEWUUrGmzrerVNmYEMQlXFCja+kR5F+N
         fmUCuTA5Q6n40WPyNqAGeR5cOS3grY2vX5VRZFrHdWTvUkFTP/2Z70yA20snC0ELIwd6
         BUlw==
X-Forwarded-Encrypted: i=1; AJvYcCUJOk7ziRP6LlVuAkYa+frbmDneYIGB9NksmYzktlSRGs/zOjtv11yNeAgvoU489Wp6USflveOgtjY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzkJv6ARF41fS4aSRN8jGJQA0ou3lxqpAEbacVtxhtbPy+9K3f1
	TU97tvqfDng7jHxBS7QrPydUPb077Fw2ff1p3+8Gkroe8DyklMnqmFFhxmYLG3cQ7jzXGHC3mxN
	79p3AzvjDv7YvHYjyW3hYnJEVJnxjp1bS2Qmja8m/z4KbSeMiUSdPJZ2rid9IhYQHd/iA
X-Gm-Gg: ASbGncuNcswOizsTzfP5+53njK9jE40/owr1NalUc01N8qwEY5esCVPC8zGDTPpODGj
	CW7Sx09t5cUUIPcYu54+wajucLrmHLzr8Lz+JJCAZWTxB1kQU7SVsOaYF1eB6cW0bR0af/v/+Ol
	4wtl95labDUqilumfxGmnDB5CLu8CKYMfSueJOjh9UOcdzztjAdF1Dg96HQZXPOA25DGyU58jJS
	lssr4ZvglZKqowrrqek5KSzoDnHRSdDYjJb4KKa3GoWINgEGN2U7t7ZjBae5TSpc8zUyqXRw2sz
	kNsdmwHiRro+S8ecPOGmN1UBWpBFlaFQST4CPnm4KyJga5BDMPC7EVQNE4tG73vBx649bBmtYA4
	1/RlTEM1KKXuVBoLUHy/8xjmjw5dVvnM9/AJMYDWCH37eK3jKRzK7+khzeoK9DTZ4uDU=
X-Received: by 2002:a05:600c:1387:b0:45d:d2cd:de36 with SMTP id 5b1f17b1804b1-45dddeb8e9emr100153065e9.12.1757408858973;
        Tue, 09 Sep 2025 02:07:38 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHXDnypB5wJ5rDn/zJEyHS9xO4uduYWB/+gBqRR8sdBFWJ0cHWyM3HNnqaB+9K2c1SmVJ00yg==
X-Received: by 2002:a05:600c:1387:b0:45d:d2cd:de36 with SMTP id 5b1f17b1804b1-45dddeb8e9emr100152415e9.12.1757408858433;
        Tue, 09 Sep 2025 02:07:38 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 11:07:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <20250908073931.4159362-3-kevin.brodsky@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: ofowYUwi3nipU8VjQyCalhHwXz4A3QG1QVnx2nvSgv0_1757408859
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08.09.25 09:39, Kevin Brodsky wrote:
> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> (taking and returning no value). This is proving problematic in
> situations where leave() needs to restore some context back to its
> original state (before enter() was called). In particular, this
> makes it difficult to support the nesting of lazy_mmu sections -
> leave() does not know whether the matching enter() call occurred
> while lazy_mmu was already enabled, and whether to disable it or
> not.
> 
> This patch gives all architectures the chance to store local state
> while inside a lazy_mmu section by making enter() return some value,
> storing it in a local variable, and having leave() take that value.
> That value is typed lazy_mmu_state_t - each architecture defining
> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> For now we define it as int everywhere, which is sufficient to
> support nesting.
> 
> The diff is unfortunately rather large as all the API changes need
> to be done atomically. Main parts:
> 
> * Changing the prototypes of arch_{enter,leave}_lazy_mmu_mode()
>    in generic and arch code, and introducing lazy_mmu_state_t.
> 
> * Introducing LAZY_MMU_{DEFAULT,NESTED} for future support of
>    nesting. enter() always returns LAZY_MMU_DEFAULT for now.
>    (linux/mm_types.h is not the most natural location for defining
>    those constants, but there is no other obvious header that is
>    accessible where arch's implement the helpers.)
> 
> * Changing all lazy_mmu sections to introduce a lazy_mmu_state
>    local variable, having enter() set it and leave() take it. Most of
>    these changes were generated using the following Coccinelle script:
> 
> @@
> @@
> {
> + lazy_mmu_state_t lazy_mmu_state;
> ...
> - arch_enter_lazy_mmu_mode();
> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> ...
> - arch_leave_lazy_mmu_mode();
> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> ...
> }
> 
> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
>    lazy_mmu is already enabled, and it temporarily disables it by
>    calling leave() and then enter() again. Here we want to ensure
>    that any operation between the leave() and enter() calls is
>    completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
>    leave() to fully disable lazy_mmu. enter() will then re-enable it
>    - this achieves the expected behaviour, whether nesting occurred
>    before that function was called or not.
> 
> Note: it is difficult to provide a default definition of
> lazy_mmu_state_t for architectures implementing lazy_mmu, because
> that definition would need to be available in
> arch/x86/include/asm/paravirt_types.h and adding a new generic
>   #include there is very tricky due to the existing header soup.

Yeah, I was wondering about exactly that.

In particular because LAZY_MMU_DEFAULT etc resides somewehere compeltely 
different.

Which raises the question: is using a new type really of any benefit here?

Can't we just use an "enum lazy_mmu_state" and call it a day?

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:11:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:11:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115950.1462391 (Exim 4.92)
	(envelope-from )
	id 1uvuNQ-0002MF-LG; Tue, 09 Sep 2025 09:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115950.1462391; Tue, 09 Sep 2025 09:11:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvuNQ-0002M8-If; Tue, 09 Sep 2025 09:11:00 +0000
Received: by outflank-mailman (input) for mailman id 1115950;
 Tue, 09 Sep 2025 09:10:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvuNP-0002M2-Bz
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:10:59 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id e2e7a1ab-8d5c-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 11:10:53 +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 4A03615A1;
 Tue,  9 Sep 2025 02:10:44 -0700 (PDT)
Received: from [10.57.60.124] (unknown [10.57.60.124])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 358583F63F;
 Tue,  9 Sep 2025 02:10: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: e2e7a1ab-8d5c-11f0-9809-7dc792cee155
Message-ID: <652720ae-131e-4de0-bc65-e5c1bdc46186@arm.com>
Date: Tue, 9 Sep 2025 11:10:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
To: Lorenzo Stoakes 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08/09/2025 18:56, Lorenzo Stoakes wrote:
> On Mon, Sep 08, 2025 at 08:39:24AM +0100, Kevin Brodsky wrote:
>> When the lazy MMU mode was introduced eons ago, it wasn't made clear
>> whether such a sequence was legal:
>>
>> 	arch_enter_lazy_mmu_mode()
>> 	...
>> 		arch_enter_lazy_mmu_mode()
>> 		...
>> 		arch_leave_lazy_mmu_mode()
>> 	...
>> 	arch_leave_lazy_mmu_mode()
>>
>> It seems fair to say that nested calls to
>> arch_{enter,leave}_lazy_mmu_mode() were not expected, and most
>> architectures never explicitly supported it.
>
> This is compiling with CONFIG_USERFAULTFD at all commits and series is
> compiling with allmodconfig plus all mm selftests are passing so from my
> side this looks good, thanks for addressing issues and rebasing! :)

Great thank you for that extensive testing, very appreciated! Shall I
add your Reviewed-by to the whole series?

- Kevin


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:14:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:14:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115964.1462402 (Exim 4.92)
	(envelope-from )
	id 1uvuQQ-0002yv-6m; Tue, 09 Sep 2025 09:14:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115964.1462402; Tue, 09 Sep 2025 09:14: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 1uvuQQ-0002yo-3x; Tue, 09 Sep 2025 09:14:06 +0000
Received: by outflank-mailman (input) for mailman id 1115964;
 Tue, 09 Sep 2025 09: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 1uvuQP-0002yh-0h
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:14:05 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5408d3a7-8d5d-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:14:04 +0200 (CEST)
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
 [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-604-2QWh8-6FM-mlnEavdm33LQ-1; Tue, 09 Sep 2025 05:14:01 -0400
Received: by mail-wr1-f72.google.com with SMTP id
 ffacd0b85a97d-3df9f185b82so2311359f8f.1
 for ; Tue, 09 Sep 2025 02:14:00 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e75223f2e5sm1797097f8f.52.2025.09.09.02.13.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:13: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: 5408d3a7-8d5d-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757409242;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=/IUdjMztn2lEK5HOnU9D0CF10p+pvtJH5MIMXBxLW58=;
	b=WnN4WZnCN9L6XZ8KpTuaFuShuJAk177LcXneJLpvhFNovuWB2PLkKxpw4J9MmVwJHNZ4te
	Iyd8Ec3F8yamTmcz+TH8iAq4YnE64EVANC2VjG+12GT1u11RLnn5cxikBP0DAvEHVZazxw
	6CalgVhWxEa59b7aYz2VHDBh9hFbIEc=
X-MC-Unique: 2QWh8-6FM-mlnEavdm33LQ-1
X-Mimecast-MFC-AGG-ID: 2QWh8-6FM-mlnEavdm33LQ_1757409240
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757409240; x=1758014040;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/IUdjMztn2lEK5HOnU9D0CF10p+pvtJH5MIMXBxLW58=;
        b=wtw5+gDv62/8nlLbJMQh1I4QanBRN4gPSteDA4Qi8noU10KDq3ZDqYixr2tBKnJdXO
         VEk0a3k8DhdTuq5DHO7yedc34T5vtNN3mewNJSDvv6s16PCICmQ/4CIREm6dVp9B2T4l
         Ja1SRKAstwrkvMGBqa7TDukcYdS3sIYUN33q4NkWt/kQadCG1YRj5FshUTGRSrkGhdPM
         rR/CCvmmilOMx69uoDEIKtwBXP2glOFqhbtg3/Q6if3gRRb5FYKQmCkdDgEeFo6v1SKV
         PjCis5mCEcq5j8S8npCphzE5ov3gzLyLR0eDVrrlo4aCvGF84QQuTGdcTDBHLtTK+Z+1
         bPiQ==
X-Forwarded-Encrypted: i=1; AJvYcCXBE86d5HZtEKVsvXUkt+Dh+aVi44kG+SbtQBouvkeIgF6u0UUY+BG/t1XY+qYyHOJTwo3qKPSoaOM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxLdDlyWAvl2Mif4sr87YbfMFsNmZUHtpTzJKYSUvs39zqY2Ag2
	yvVBCZaxtm9k369dyxzrw6qx70sLyKPAT4NT10Vtc3fJqRhD+BuvQgJBgSUgW+OlSyKPEvH1CzT
	r0V/cI1yNEJZRsJ2uuuESbsTtvvkqWrScsacnP3TxQJr3ORQUjKBvqz7XqLDOu71fldz9
X-Gm-Gg: ASbGncshxhIT5OUfWz63sWLW2Q5nGu6zPPXTRhWeckZUhw6bkP9PE+k8Tl89xXjURfp
	axCW0Ct1d5Pxp/gHOxiuTJSjEqaRLZ0ys5aJYaTYEPeD7ANouLhHfY4Dba5Txhfz13tzhybMF8P
	Z3CNy0mASFp2+aM0zf0r6N2k5FG9s4MPZtWbskzHLeMxQj/BgmbsC8MFWG9zJU32D9/ImEIEmTw
	3RILBV3NvxrAwP5JxW488JRUH8B11Kg2dXsdPpEFR0JdbVNYIHkT2el+WpsJXN8euCT2Ush8Y8E
	mLKErBp+LUBx6HTQf+Wmy7MGSk/3J1MrLutRKed0YDjaCcc/DujqfFrzLMjKj8r9ThsbTW0voCV
	6wvg8kIXRydX7O0g6uHMQAs+LaZgQaR/KE/fB24g/Dp5+e0yBnFTxaJMFQEFeeG6vLtQ=
X-Received: by 2002:a05:6000:3101:b0:3e3:59cc:65ba with SMTP id ffacd0b85a97d-3e64374208dmr2787722f8f.50.1757409239562;
        Tue, 09 Sep 2025 02:13:59 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEhnq/C72ezwSRJLO4zISvano2xfvFhth932RgVfDh+sCEuObRa/4tJAM3JVWrXDipaf397Wg==
X-Received: by 2002:a05:6000:3101:b0:3e3:59cc:65ba with SMTP id ffacd0b85a97d-3e64374208dmr2787666f8f.50.1757409238983;
        Tue, 09 Sep 2025 02:13:58 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 11:13:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <20250908073931.4159362-5-kevin.brodsky@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: d-3RKdZktTwp3m1YxwjPi8H-GneAv4-RIaT20cwaGUw_1757409240
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08.09.25 09:39, Kevin Brodsky wrote:
> Commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode")
> originally introduced support for nested lazy sections (LAZY_MMU and
> LAZY_CPU). It later got reverted by commit c36549ff8d84 as its
> implementation turned out to be intolerant to preemption.
> 
> Now that the lazy_mmu API allows enter() to pass through a state to
> the matching leave() call, we can support nesting again for the
> LAZY_MMU mode in a preemption-safe manner. If xen_enter_lazy_mmu() is
> called inside an active lazy_mmu section, xen_lazy_mode will already
> be set to XEN_LAZY_MMU and we can then return LAZY_MMU_NESTED to
> instruct the matching xen_leave_lazy_mmu() call to leave
> xen_lazy_mode unchanged.
> 
> The only effect of this patch is to ensure that xen_lazy_mode
> remains set to XEN_LAZY_MMU until the outermost lazy_mmu section
> ends. xen_leave_lazy_mmu() still calls xen_mc_flush()
> unconditionally.
> 
> Signed-off-by: Kevin Brodsky 
> ---
>   arch/x86/include/asm/paravirt.h       |  6 ++----
>   arch/x86/include/asm/paravirt_types.h |  4 ++--
>   arch/x86/xen/mmu_pv.c                 | 11 ++++++++---
>   3 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 65a0d394fba1..4ecd3a6b1dea 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -529,14 +529,12 @@ static inline void arch_end_context_switch(struct task_struct *next)
>   #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>   static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>   {
> -	PVOP_VCALL0(mmu.lazy_mode.enter);
> -
> -	return LAZY_MMU_DEFAULT;
> +	return PVOP_CALL0(lazy_mmu_state_t, mmu.lazy_mode.enter);
>   }
>   
>   static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>   {
> -	PVOP_VCALL0(mmu.lazy_mode.leave);
> +	PVOP_VCALL1(mmu.lazy_mode.leave, state);
>   }
>   
>   static inline void arch_flush_lazy_mmu_mode(void)
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index bc1af86868a3..b7c567ccbf32 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -45,8 +45,8 @@ typedef int lazy_mmu_state_t;
>   
>   struct pv_lazy_ops {
>   	/* Set deferred update mode, used for batching operations. */
> -	void (*enter)(void);
> -	void (*leave)(void);
> +	lazy_mmu_state_t (*enter)(void);
> +	void (*leave)(lazy_mmu_state_t);
>   	void (*flush)(void);
>   } __no_randomize_layout;
>   #endif
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 2039d5132ca3..6e5390ff06a5 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2130,9 +2130,13 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
>   #endif
>   }
>   
> -static void xen_enter_lazy_mmu(void)
> +static lazy_mmu_state_t xen_enter_lazy_mmu(void)
>   {
> +	if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
> +		return LAZY_MMU_NESTED;
> +

You mention above "preemption-safe manner" above, so I am wondering,
what if we get preempted immediately after doing the this_cpu_read() and 
get scheduled on another CPU?

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:14:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:14:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115970.1462411 (Exim 4.92)
	(envelope-from )
	id 1uvuQq-0003Qi-EX; Tue, 09 Sep 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 1115970.1462411; Tue, 09 Sep 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 1uvuQq-0003Qb-BO; Tue, 09 Sep 2025 09:14:32 +0000
Received: by outflank-mailman (input) for mailman id 1115970;
 Tue, 09 Sep 2025 09:14:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvuQo-0002yh-DJ
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:14:30 +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 63d4fd37-8d5d-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:14:29 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-61cd6089262so8536327a12.3
 for ; Tue, 09 Sep 2025 02:14: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-62c01ae5f75sm904162a12.46.2025.09.09.02.14.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:14: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: 63d4fd37-8d5d-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757409269; x=1758014069; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AaqUvhKbg0nt20i9a+zwlFhmXiGYUUJ5SzK6ujdfPj4=;
        b=dizkRh3aZv+hdo0eBvl4uNBSTb/yE0bV/5ct67wKvJ4jFdPmyJarEEL5FJ7W4b56Zi
         RS9Y8xHvkVZGPL30vVHcck+dSbVxkd0oYowTWDuUlzwf+oCogjqtnUd0tmPmXo45/UhA
         INgdTV6SL48Z/F1KrMC8WxqYlbWXuPHlkP9Mq6Mt45tMxLxkAdgJnL6paVkbvqcBf/ej
         4grX7DPueycje6ZJvVLI5jwC3g8ZcxaeJaWaQdaycAKe5CETV0FkPMyOTBNIAQQP+HDz
         Plf9basSLD5Flr7yXv3BZg7SJu5JqODiG5a1V9UWOJCUvVMLGQP38kHBRwe2IbDDPDtf
         vh8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757409269; x=1758014069;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AaqUvhKbg0nt20i9a+zwlFhmXiGYUUJ5SzK6ujdfPj4=;
        b=OAtHZhznECEeAhOaBv79DbM6KfzPMo5qwW1klgZA0vTJecHItaoIncaXIG4N088Y/r
         gGdRyLOXKFegL5ebHo+NUZ3lMm0ejT/wfvw/l6QLiWGseCpzfkQTUw4Y7PfonJ2Q80sl
         3zF7zkB3KSVlXn5M2HbVfKOK5p6bm7kGp5QTXo7LM5RtfkSAkzlQNvwy1FxxaCyzTSzK
         X/zf6wJEBeVWpQtkWLbueg5ZSRqsUwqLciMv5BtRc8iF+D6QEeBsygxWJ5HfGp2sM9p2
         o2Lq0y5N582I1pH1ugipmO7WssyhmF4kXXYI+DQwV5m3oY+Ly6dqy3O6ooYVH9aN1nfY
         Mtdw==
X-Forwarded-Encrypted: i=1; AJvYcCVa9TJ/hOOuh3tO38J1UpbA+JR3Ff6zVnfU0ARhMJRkfLXay1TVvBkjqp6SRzcnnZIO1hgbMXEOie4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yws6zM+KgkTKQU+V6HKVNxOMzp4Ev0ss9mvkOyowFARe9/SaJxR
	TFM7zzOcmcoUJ7nZiiYoHY+02ZVNno2iaLfg3n4Q1SoBa68S79Lotf0vZMCw9YSg1g==
X-Gm-Gg: ASbGncusMIfmxuyCCssvvm5OAnDAfnZn4eC1uw07dWDO/6hBbTvQmWW85t3gLRjoyKd
	Pr1YWoziYYYdIlTQY/pXTbQQXseSkRS+Cy5TR1PQeEDErNl/ySxhN6JbJKvoU5jCX/XroIuozsv
	Wlpi281QJ2AW2ZP5/P78HHdnCGZBKq0T3UmV0lG0cAKu1O8G//31rJ5zoNH09dwbCuDBSPmVGUZ
	GsradZsGSbB+gMQX2x3++qgSXipSbXEJjLvHYHkVz+5sFfNnxKNfJDPciVh3V8GAu6JyhkTZH99
	AlO/YKitxnS6obKbXg7m4w8+Qu4M5Owd2KWJGpyZAM47wwVrTE3EVlkgPWY2ID67l0+tK2Rh7Hf
	OT6i7EepJQWepLPLrFzVxddHPM76JHF5mBE24kYMaE33ton928R1RhhTGgkiZ3SZGkwBqWyhHkv
	6jB1mc1Sma0qxTCjxZFA==
X-Google-Smtp-Source: AGHT+IFE0pTSExnZ28gMsqbCjxublwg3r6djMMaZsey5QKd4ongsGi0UribDMX+V3EBIogPngX3pzQ==
X-Received: by 2002:a05:6402:2685:b0:61d:dd9:20db with SMTP id 4fb4d7f45d1cf-6237c048793mr9317216a12.31.1757409268890;
        Tue, 09 Sep 2025 02:14:28 -0700 (PDT)
Message-ID: <646f7070-83c7-45ce-a4c9-c59cd39a33c5@suse.com>
Date: Tue, 9 Sep 2025 11:14:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 11/13] 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?= ,
 Saeed Nowshadi ,
 Mykyta Poturai ,
 Mykola Kvach , xen-devel@lists.xenproject.org
References: 
 <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com>
 
 
 
 <21f2f6e1-cbf7-4b36-bbba-bffc2dab3422@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.09.2025 10:14, Mykola Kvach wrote:
> On Tue, Sep 9, 2025 at 9:57 AM Jan Beulich  wrote:
>> On 09.09.2025 08:29, Mykola Kvach wrote:
>>> Then, in domain_shutdown(), we can call need_hwdom_shutdown() instead
>>> of directly checking is_hardware_domain(d). This keeps the logic
>>> readable and avoids code duplication.
>>>
>>> What do you think about this approach?
>>
>> Well, there's still the CONFIG_ARM check in there that I would like to
>> see gone. (As a nit, the use of u8 would also want to go away.)
> 
> We could combine your proposal from v5 of this patch series, i.e., using the
> HAS_HWDOM_SUSPEND extra config together with this helper function:
> 
>     static inline bool need_hwdom_shutdown(const struct domain *d)
>     {
>         bool is_hw_dom = is_hardware_domain(d);
> 
>         if ( !IS_ENABLED(CONFIG_HAS_HWDOM_SUSPEND) )
>             return is_hw_dom && d->shutdown_code != SHUTDOWN_suspend;
> 
>         return is_hw_dom;
>     }

Maybe. Yet then the next thing striking me as odd is the redundant
checking of is_hw_dom. Why not simply

{
    if ( !is_hardware_domain(d) )
        return false;

    return IS_ENABLED(CONFIG_HAS_HWDOM_SUSPEND) || d->shutdown_code != SHUTDOWN_suspend;
}

Yet as said - my expectation is anyway that the is_hardware_domain() check
would live in the caller.

> As for the second argument (reason), I can extract it directly from the
> domain structure, as is done in the function above.

Looks like a misunderstanding: I don't mind the function parameter. But
the "u8" type shouldn't be used anymore in new code; that's uint8_t now.

>> Furthermore with continuing to (ab)use domain_shutdown() also for the
>> suspend case (Dom0 isn't really shut down when suspending, aiui), you
>> retain the widening of the issue with the bogus setting of
>> d->is_shutting_down (and hence the need for later clearing the flag
>> again) that I mentioned elsewhere. (Yes, I remain of the opinion that
>> you don't need to sort that as a prereq to your work, yet at the same
>> time I think the goal should be to at least not make a bad situation
>> worse.)
> 
> From the perspective of ARM logic inside Xen, we perform the exact same
> shutdown steps as for other domains, except that in the end we need to
> call Xen suspend.

Which, as said, feels wrong. Domains to be revived after resume aren't
really shut down, so imo they should never have ->is_shutting_down set.

> For a domain with a toolstack, it is possible to have a running Xen
> watchdog service. For example, if we have systemd, it can be easily stopped
> from the guest because we have hooks and can perform some actions before
> suspend.
> 
> The same story applies to a Linux kernel driver: if it has PM ops installed
> for the Xen watchdog driver, nothing bad happens.
> 
> However, in the case of using init.d, it isn’t easy to stop the Xen WDT
> automatically right before suspend. Therefore, Xen code has an extra check
> (see domain_watchdog_timeout) where it checks the is_shutting_down flag
> and does nothing if it is set.

I don't understand how these watchdog considerations come into play here.

> The is_shutting_down flag is easily reset on Xen resume via a
> domain_resume call, so I don’t see any problems with that.

You did read my earlier mail though, regarding concerns towards the clearing
of that flag once it was set? (You must have, since iirc you even asked [1]
whether you're expected to address those issues up front.)

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2025-08/msg02057.html


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:22:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115987.1462432 (Exim 4.92)
	(envelope-from )
	id 1uvuYD-0005U4-Gc; Tue, 09 Sep 2025 09:22:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115987.1462432; Tue, 09 Sep 2025 09:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvuYD-0005Tv-Dk; Tue, 09 Sep 2025 09:22:09 +0000
Received: by outflank-mailman (input) for mailman id 1115987;
 Tue, 09 Sep 2025 09:22: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 1uvuYC-0005TO-1o
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:22:08 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 731103a1-8d5e-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 11:22:05 +0200 (CEST)
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
 [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-381-fx5GjJQJN0KGkv1x5gtcpA-1; Tue, 09 Sep 2025 05:21:59 -0400
Received: by mail-wr1-f72.google.com with SMTP id
 ffacd0b85a97d-3df19a545c2so3899904f8f.3
 for ; Tue, 09 Sep 2025 02:21:59 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45b98e77231sm303120095e9.12.2025.09.09.02.21.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:21: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: 731103a1-8d5e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757409724;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=yZ7mpSu7Vyx7D7KzsRAEX4kah9GPWTLG09gnV5krCYA=;
	b=fmJeNe05aDh+QLAyGSmDxr5jGvK1npaqXcStJOkt+ytPw/fJF4WzVllFHlELcfC5jIfyZb
	RNc8mMJ5A+oux1tineuHgGjF7SBhUjsKAZUl1Jq35bA7YwkHdsDGUybBemN3uk+HS4+mAJ
	JCa0le23r58vqWhS/mnMFVj7W098lkI=
X-MC-Unique: fx5GjJQJN0KGkv1x5gtcpA-1
X-Mimecast-MFC-AGG-ID: fx5GjJQJN0KGkv1x5gtcpA_1757409719
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757409717; x=1758014517;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=yZ7mpSu7Vyx7D7KzsRAEX4kah9GPWTLG09gnV5krCYA=;
        b=ntehK+cBn/+iA8817DOU3TSlJCSaQlXTLOFInbGpXzDgfYeCz/fgYHcwU1LYz7Rmym
         esXSxxGMhuS2QCMFVHVqJ7mrF0s0fme/DxAVDIRwQ5qhOWRYMjbvrvYNNrbvz4iVqjoc
         t/eCgsMZVQWEFkOiUH+TVhLbVH2y+fzcwIiFHyMSxRakNISs/jVcKZGJ5xhRE5uwFmW+
         FkUJ7nln1vzeOzPJC6wOyG64YksKLrZaR+cYOoE06XtuNVmYJyW/VdxS2Wn8HADFNBDg
         KG17b88a33iMAlBYAOsL2ArqeY5lbDo8oEl1RcJOrR099annTjzouARrDTdYKmfGsXbm
         1xhw==
X-Forwarded-Encrypted: i=1; AJvYcCXmN4FrY7EYPTs9O3+wWIEYaXZbmHbQTxsY69SWlEOHRa/h9I+5w3+p6JzWys7lk2WsYzrWUhnCy2E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyxNBO9vBhM7wbhFkunKDFfEuqO6QRX8/StmcFniIhFaB4RNxJ/
	qV1BJrwCyiX4nOWRKK1MKku8UIqYOlY9AeZ4+blk8TK7ZsKP4h4THUG0dpKst4cYTV2csHM5Tw0
	DAcsDxoZ3BFfE8v65Vq5av4g82ZxdSRuJdGTZYh8+Gnl/5uCiNxd13OdM6d646MLf+P7s
X-Gm-Gg: ASbGnctmz0M7ZcjDrD5cSKjdzKLmEdTbtzJNJ21QGWSAu8hAp89FWtMwRcL6NUROmwu
	xfx/x4/1SB5/S9pD4y9V0TdIqR6TUdeqk9U5MDkTdS7rZaVgrcB7jpeZlD/KbzCKluuC5IQKrmf
	ePDvEQDEsobS1FtMIOogeY1Szg7gvDb8j8plTQUxK8diBueofmOqtRmjm0+qrwDoDPyiB7e3Z/Q
	xaNizVYAsbN9m7HIg3pIf1oPVzUi1tM7cFLliyK+/J0mYLfHL6tCVkv7EeWlIG0+W6BvCLSIcLO
	SBcIWo2nLZlU+lYCZLBGWHWUm7kB1P9Nhjvup+AKH4J1aqxb6Y69c8Wvd7740ZudpOsW+LyW1W6
	ahj1ECpnWbvP1DvesmSuYmTIiLCzXvEKFaOrjtId82ostbrEweFapl0jUVjtgqjphjQs=
X-Received: by 2002:a05:6000:d0e:b0:3e7:4fb7:4e9 with SMTP id ffacd0b85a97d-3e74fb7050cmr2433461f8f.47.1757409717595;
        Tue, 09 Sep 2025 02:21:57 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFHaiuV2XNAb2KzSftztUT7DW61EOo5r3IILYTR3cBriEgdDR9uMZbXOjouMq5dEBDNTmzUKg==
X-Received: by 2002:a05:6000:d0e:b0:3e7:4fb7:4e9 with SMTP id ffacd0b85a97d-3e74fb7050cmr2433419f8f.47.1757409717177;
        Tue, 09 Sep 2025 02:21:57 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 11:21:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
To: Andrew Morton ,
 Kevin Brodsky 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: O9LlzzASwtXmZtSpXao8PSlPdEowBia80dxdKKt7AR0_1757409719
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09.09.25 04:16, Andrew Morton wrote:
> On Mon,  8 Sep 2025 08:39:24 +0100 Kevin Brodsky  wrote:
> 
>> The main change enabling nesting is patch 2, following the approach
>> suggested by Catalin Marinas [4]: have enter() return some state and
>> the matching leave() take that state.
> 
> This is so totally the correct way.  Thanks.

Staring at this, I wonder if we could alternatively handle it like 
pagefault_disable()/pagefault_enable(), having something like 
current->lazy_mmu_enabled.

We wouldn't have to worry about preemption in that case I guess (unless 
the arch has special requirements).

Not sure if that was already discussed, just a thought.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:22:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1115986.1462422 (Exim 4.92)
	(envelope-from )
	id 1uvuY7-0005F4-6C; Tue, 09 Sep 2025 09:22:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1115986.1462422; Tue, 09 Sep 2025 09:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvuY7-0005Ex-2v; Tue, 09 Sep 2025 09:22:03 +0000
Received: by outflank-mailman (input) for mailman id 1115986;
 Tue, 09 Sep 2025 09:22:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvuY6-0005Er-K6
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:22:02 +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 70b9b4d6-8d5e-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:22:01 +0200 (CEST)
Received: by mail-yb1-xb2e.google.com with SMTP id
 3f1490d57ef6-ea0297e9cd4so1791470276.3
 for ; Tue, 09 Sep 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: 70b9b4d6-8d5e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757409720; x=1758014520; 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=Ed7LZ2xg4GvAWyGx7uRH5GevbRcowu1w3Knng+7fX9k=;
        b=Ao1ngiwao41StB2An+KPh4oFNSe/SfPGNIG/blGUZtsYrlnnULR8eJMiQB7MJWdbwT
         48TGfL/5WXAeQbfRx6P7SA+IGd/SJd8WAtxQVjNHNK1PFqwZpUKQlLd30bDOStW+NwJD
         LJGEPGEwqRHmxmOTjlL43zE1PjIPuZsvbYago=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757409720; x=1758014520;
        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=Ed7LZ2xg4GvAWyGx7uRH5GevbRcowu1w3Knng+7fX9k=;
        b=bpTqG92dcW5Jt6MW7MPSrcFubJSJgNU2TcUhDUMKOyMQ/cvTNGAUz7kmjKtjnyYTJs
         V7RCNcsVaCQ1JVfklLVmVyRhXoAEg3gwi8gwQ3UXDZaSfza/bDu0xU5OeqpFOlD8j/qw
         PCkQ5y1Ug3sEz3XCDY022sXNRHuTBL4MwtDCrOCd9PVUbsP8Hj+kN2VUQYvnjhCR6KSN
         DbQWYgIsG9T6PNyDBxbYw8gUljt1/wHqmJ7BkY3fiqUqSTPq2dPDqnAYPH2gSZgXQuK8
         zCrRBIOIl8QQ4ZjxpE9/SW7zh7FRuG0bWwBlvErG4fH80gDxRIzDoyyhby5UrJ3u+WyR
         V/Rw==
X-Forwarded-Encrypted: i=1; AJvYcCUc7R1SVKoU6Qnxcs9Aactsu53tWuDgfAWHitBsqD2tItapUvTmzjtLgrbiG2xrrMk+y8wBy42M0Z0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwDvXzEkCBgGQWnbRVsU8r2TJddOVjZLXrK6mho4Dy6yrKVnjmP
	OE+fbxKPLnDv2rzTx5aAGBtzxA9GmHO5SVs609lnDU5DQ0QsGwEWUhaHBrQ0T0Q7grvL4a0SXOp
	cNxBmAMw03eC9l+t3zvwMWebpMn4jKaxGK89qAfXVAjdJKp6xCJhx2kz4YA==
X-Gm-Gg: ASbGncupeWa1OWyGIur7X3cqujlHMsm5g3NcN3oC590Mkn96sz4A+JKzUbi5/eYIigN
	XgluD/g1I1dxNvm6fXT5a4T+NI6iEUX3ea7snveP4tnFsR8iFRXvdnkjJ2Z23xQIA80Z5TFtCxy
	1Bv/Qs8fRjYQUBSDLy+/pLcDkkNdhuiVDOxNtADFFXkKN9gzHHSwpav0zPC80h7y38MWNFlHvTo
	Zn4hQ==
X-Google-Smtp-Source: AGHT+IFkUInW1d9tToYDaO3KHKozP6J1/Vp9+e6EVZXMA+bRp2vl05Nn8fAQ4vTZThtusnO0rLY/Y8Y2mHdkQzlq9e8=
X-Received: by 2002:a05:6902:2b0e:b0:ea0:f4c6:5812 with SMTP id
 3f1490d57ef6-ea0f4d5ad88mr6585449276.32.1757409719783; Tue, 09 Sep 2025
 02:21:59 -0700 (PDT)
MIME-Version: 1.0
References: 
 <8d66f9ce2c9c352794c0c144f6e00d0a9d465dbe.1757071716.git.gerald.elder-vass@cloud.com>
  
  
In-Reply-To: 
From: Gerald Elder-Vass 
Date: Tue, 9 Sep 2025 10:21:49 +0100
X-Gm-Features: AS18NWCLnFQ8EaKYaAKaD_Lme80PLQ_otAAs_onfwJQPt3WB5jCMDoan9Nfp0Ss
Message-ID: 
Subject: Re: [PATCH v4 1/2] efi: Add a function to check if Secure Boot mode
 is enabled
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: Jan Beulich , Ross Lagerwall , 
	"Daniel P. Smith" , Andrew Cooper , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Xen-devel 
Content-Type: multipart/alternative; boundary="00000000000012b5a2063e5ad6ba"

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

 > On Mon, Sep 08, 2025 at 11:41:55AM +0200, Jan Beulich wrote:
> > On 08.09.2025 11:35, Gerald Elder-Vass wrote:
> > >>> +          size =3D=3D 1 && data =3D=3D 0) )
> > >>
> > >> ... any reason it's literal 1 here?
> > >
> > > The size variable is also used as output from GetVariable and we
should
> > > verify that the size of the returned data is as expected, it is
simply one
> > > byte so probably not worth defining any macros to make it clearer
> >
> > I don't understand this reply. Why would the initializer of the variabl=
e
> > use one thing (sizeof()) and the checking of the variable another
(literal
> > 1)? Even consistently using 1 would already be better imo; consistently
> > using sizeof() is what I think would be best.
>
 > 'size' as input value is the allocated size of the data parameter, so
> makes sense to be sizeof(data). IOW, 'size' as the input value comes
> from the size of the 'data' variable, while the output value check comes
> from UEFI spec. While the size of the 'data' variable should match the
>spec, IMO changing its type (to a wider one) should not break the
>behavior here.

 The UEFI spec defines the "SecureBoot" global variable as an 8-bit unsigne=
d
integer, in the event the size of the data used for output was not large
enough to
contain the output then it would return an EFI_BUFFER_TOO_SMALL status
(which the function would then interpret as "play it safe and assume
enabled").

The "SecureBoot" variable is defined:
https://uefi.org/specs/UEFI/2.11/03_Boot_Manager.html#globally-defined-vari=
ables

So I believe we are correct in using uint8_t here


*Gerald Elder-Vass*
Senior Software Engineer

XenServer
Cambridge, UK


On Mon, Sep 8, 2025 at 10:53=E2=80=AFAM Marek Marczykowski-G=C3=B3recki <
marmarek@invisiblethingslab.com> wrote:

> On Mon, Sep 08, 2025 at 11:41:55AM +0200, Jan Beulich wrote:
> > On 08.09.2025 11:35, Gerald Elder-Vass wrote:
> > >>> +          size =3D=3D 1 && data =3D=3D 0) )
> > >>
> > >> ... any reason it's literal 1 here?
> > >
> > > The size variable is also used as output from GetVariable and we shou=
ld
> > > verify that the size of the returned data is as expected, it is simpl=
y
> one
> > > byte so probably not worth defining any macros to make it clearer
> >
> > I don't understand this reply. Why would the initializer of the variabl=
e
> > use one thing (sizeof()) and the checking of the variable another
> (literal
> > 1)? Even consistently using 1 would already be better imo; consistently
> > using sizeof() is what I think would be best.
>
> 'size' as input value is the allocated size of the data parameter, so
> makes sense to be sizeof(data). IOW, 'size' as the input value comes
> from the size of the 'data' variable, while the output value check comes
> from UEFI spec. While the size of the 'data' variable should match the
> spec, IMO changing its type (to a wider one) should not break the
> behavior here.
>
> --
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab
>

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



>

On Mon, Sep 08, 2025 at 11:41:55AM +0200, Jan Beul=
ich wrote:

>

> On 08.09.2025 11:35, Gerald Elder-Vass wrote:=


>

> >>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 size =3D=3D 1 && data =3D=3D 0) )

>

> >>

>

> >> ... any reason it's literal 1 he=
re?

>

> >=C2=A0

>

> > The size variable is also used as output=
 from GetVariable and we should

>

> > verify that the size of the returned dat=
a is as expected, it is simply one

>

> > byte so probably not worth defining any =
macros to make it clearer

>

>=C2=A0

>

> I don't understand this reply. Why would =
the initializer of the variable

>

> use one thing (sizeof()) and the checking of =
the variable another (literal

>

> 1)? Even consistently using 1 would already b=
e better imo; consistently

>

> using sizeof() is what I think would be best.=


>


=C2=A0>

'size' as input value is the allocated size of the data parameter, =
so

>

makes sense to be sizeof(data). IOW, 'size' as the input value come=
s

>

from the size of the 'data' variable, while the output value check =
comes

>

from UEFI spec. While the size of the 'data' variable should match =
the
>spec, IMO changing its type (to a wider one) should not break th=
e
>behavior here.

=C2=A0The UEFI spec define=
s the "SecureBoot" global variable as an 8-bit unsigned
integer, in the event the size of the data used for output was not large e=
nough to
contain the output then it would return an EFI_BUFFER_TO=
O_SMALL status
(which the function would then interpret as "=
play it safe and assume enabled").

The "=
SecureBoot" variable is defined:

So I believe we are correct in using uint8_t here=



Gerald Elder-Vass
Senior Software Engineer

XenServer
Cambridge, UK


On Mon, Sep 8, 2025 at 10:53=E2=80=AFAM Marek=
 Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com> wrote:
On Mon, Sep 08, 2025 at 11:41:55AM +0=
200, Jan Beulich wrote:

> On 08.09.2025 11:35, Gerald Elder-Vass wrote:

> >>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size =3D=3D 1 &&a=
mp; data =3D=3D 0) )

> >>

> >> ... any reason it's literal 1 here?

> > 

> > The size variable is also used as output from GetVariable and we =
should

> > verify that the size of the returned data is as expected, it is s=
imply one

> > byte so probably not worth defining any macros to make it clearer=


> 

> I don't understand this reply. Why would the initializer of the va=
riable

> use one thing (sizeof()) and the checking of the variable another (lit=
eral

> 1)? Even consistently using 1 would already be better imo; consistentl=
y

> using sizeof() is what I think would be best.



'size' as input value is the allocated size of the data parameter, =
so

makes sense to be sizeof(data). IOW, 'size' as the input value come=
s

from the size of the 'data' variable, while the output value check =
comes

from UEFI spec. While the size of the 'data' variable should match =
the

spec, IMO changing its type (to a wider one) should not break the

behavior here.



-- 

Best Regards,

Marek Marczykowski-G=C3=B3recki

Invisible Things Lab




--00000000000012b5a2063e5ad6ba--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:23:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:23:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116009.1462442 (Exim 4.92)
	(envelope-from )
	id 1uvuZ4-0006Hf-Om; Tue, 09 Sep 2025 09:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116009.1462442; Tue, 09 Sep 2025 09: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 1uvuZ4-0006HY-M3; Tue, 09 Sep 2025 09:23:02 +0000
Received: by outflank-mailman (input) for mailman id 1116009;
 Tue, 09 Sep 2025 09:23: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 1uvuZ3-0005TO-R2
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:23:01 +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 94249bc5-8d5e-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 11:23:00 +0200 (CEST)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-336dc57f562so46876701fa.1
 for ; Tue, 09 Sep 2025 02:23: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: 94249bc5-8d5e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757409779; x=1758014579; 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=cJyj+hFKDpc6wM9Ol3UGAzK2l2BetfGoSNjvrhxxzio=;
        b=R5Ucl98O+r7DOmSGCarqBf0S5fE+IslvA8l4ej2DVT3Cz69iq5jbu/nitVv5OV97Np
         mP66TAMeeYDIiLH9ePohRyes4ZXzE4jSGbdTXNe4CMAh5zhjbyXWZ4A//QSpZPLI18xX
         dMoYEivwHdgIfcVQEt1qMIY1xiDm8UDDdGsqBiGwsig1iUUhvYqVVrwe2flnhofsa0yA
         rRXXCJzVzrFOlVVM7Eyc/nCULhbzRF+EhcW9Ie/DfFarsLXLFfImnaBnzg6Ho3B3Cl4w
         KqNyQ4cpLWa7k88cHqVHcy7dUVGJj5zgPF3qURVgCciWpszpUGcMIUSKQ0GLqU/M7xix
         iQGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757409779; x=1758014579;
        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=cJyj+hFKDpc6wM9Ol3UGAzK2l2BetfGoSNjvrhxxzio=;
        b=mQkG3FLIfGyLkvi/JRCZnrPn/BDcAB09NcilHzssO4Vsiu8gVh+Jzou3LMEHMyk6K3
         NQzEAiqFMMJwlBWszrK+5QhLWvsozae1YVmD82EKQS1nXrTR/FOkEmPf9xI0iuc7KJQL
         oVnQdKEFsYzljgophvwqi3Pg2o4dFNc/roiRk8oxTGvBZdsMerPHrAYd0c/R1VVLpD6I
         +AyCu6leYu6f7xNhBvtagMLImo2dVmVYu9fZmHursCoPGeCALl6ziSC5jjhaDglxOdj8
         ZVB+e4mh3pscXwDnjtQBskb6dYvE5umTTQzzCCesPH7OoHWppbr2kQMLFlesWw+NxoBU
         SfgA==
X-Gm-Message-State: AOJu0Ywtgvt+pIcC2KRTmJx59NZ8pv6jEutSRpDRHDLu9cf2gpQv9Pri
	ReKaKOo4+mvcVk1eGu9C8v1+F0ybXXew6Z2BalcYxJuhWb3sv1qyGc/j6764e4dGWpKL8MQr+G4
	YIpSp+KhYh44ICRnzGpfhKyIUfQDAPqNKU+i4
X-Gm-Gg: ASbGncsjIprq9sMOgZQHZGlkwKba5jUDNyejByogaLc+ejpj1eNX+Kw0618bSbG8bLC
	Pz7vNosXyFaQ5n3gKMxfyWcJeCxq25jkG/wOZSKQaEtQ90xI1Vvx/ngCV9mPxPK0TPFb9jtxcER
	7p0RAg8hCnRU7rdq9kMki+sE+6PlwXcYRiDAfidqLB1irJWmPCOraHmUhdVQP5eedI2CalBiXuB
	8jXMftNJUyIP50Q
X-Google-Smtp-Source: AGHT+IEQvbgwfZ7T3cFvFrIpxppRoaNArl7mF0+jrhXYxSL3eytsIk6K1cWZnjJddyR0zhqYfWliz+FyUJrQ64LE6/s=
X-Received: by 2002:a2e:a418:0:b0:336:9d4e:6b8b with SMTP id
 38308e7fff4ca-3381e790afemr33075311fa.20.1757409779062; Tue, 09 Sep 2025
 02:22:59 -0700 (PDT)
MIME-Version: 1.0
References: <20250909074141.7356-1-michal.orzel@amd.com>
In-Reply-To: <20250909074141.7356-1-michal.orzel@amd.com>
From: Mykola Kvach 
Date: Tue, 9 Sep 2025 12:22:48 +0300
X-Gm-Features: Ac12FXzzPJYHh1OI-G5Y1M6tyRSYDBIKJQAqLI1tolsbBptoNvb-LRfQzO94YfA
Message-ID: 
Subject: Re: [ImageBuilder] Use LOAD_CMD by default if not specified in load_file()
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michal,

Thank you for the patch and the detailed explanation.

On Tue, Sep 9, 2025 at 10:42=E2=80=AFAM Michal Orzel =
 wrote:
>
> Commit 061d6782756f modified load_file() to take load command as
> argument but did not change all the invocations (e.g. loading standalone
> Linux, bitstream, etc.) which broke the output script (load command
> empty). Fix it by defaulting to LOAD_CMD if not specified.
>
> Fixes: 061d6782756f ("Add config option to use separate load commands for=
 Xen, DOM0 and DOMU binaries")
> Signed-off-by: Michal Orzel 
> ---
>  scripts/uboot-script-gen | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> index 849b8f939e81..4f9261035d73 100755
> --- a/scripts/uboot-script-gen
> +++ b/scripts/uboot-script-gen
> @@ -736,6 +736,12 @@ function load_file()
>      local base=3D"$(realpath $PWD)"/
>      local relative_path=3D${absolute_path#"$base"}
>
> +    # Default to LOAD_CMD if not specified
> +    if test -z "${load_cmd}"
> +    then
> +        load_cmd=3D"${LOAD_CMD}"
> +    fi
> +

I was wondering if we could use a slightly more concise notation here, like=
:
: "${load_cmd:=3D$LOAD_CMD}"

It does the same thing but is a bit more idiomatic for Bash scripts.

>      if test "$FIT"
>      then
>          echo "imxtract \$fit_addr $fit_scr_name $memaddr" >> $UBOOT_SOUR=
CE
> --
> 2.43.0
>
>

Thanks again for your work on this!

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:30:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:30:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116022.1462452 (Exim 4.92)
	(envelope-from )
	id 1uvufm-0007KJ-EH; Tue, 09 Sep 2025 09:29:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116022.1462452; Tue, 09 Sep 2025 09:29: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 1uvufm-0007KC-BW; Tue, 09 Sep 2025 09:29:58 +0000
Received: by outflank-mailman (input) for mailman id 1116022;
 Tue, 09 Sep 2025 09:29: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 1uvufk-0007K5-6y
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:29:56 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2408::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89e0c727-8d5f-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 11:29:53 +0200 (CEST)
Received: from BYAPR04CA0027.namprd04.prod.outlook.com (2603:10b6:a03:40::40)
 by BY5PR12MB4161.namprd12.prod.outlook.com (2603:10b6:a03:209::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 09:29:47 +0000
Received: from SJ1PEPF00001CE5.namprd03.prod.outlook.com
 (2603:10b6:a03:40:cafe::b2) by BYAPR04CA0027.outlook.office365.com
 (2603:10b6:a03:40::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Tue,
 9 Sep 2025 09:29:47 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Tue, 9 Sep 2025 09:29:47 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Tue, 9 Sep
 2025 02:29:46 -0700
Received: from satlexmb07.amd.com (10.181.42.216) 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, 9 Sep
 2025 04:29:46 -0500
Received: from [10.252.147.171] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Tue, 9 Sep 2025 02:29:45 -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: 89e0c727-8d5f-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pAz+JszSFLosjqWukHn4QfgaG1kOwNVOGN/PZDY8Pn6L0fZvNxVYVcKljnL+qzlNvc430f5s1IURApNOeUFUDnAq9XtWlXgAfST2i2NbU+eE9+KGx5AnfujIoXSDauxZ3DxNjhCT6MjGT04JJ4eE2Gn2kUt259k9mk+rvEo6WHO7tjQJ1zxvUXBYMjkQ81b6VekBQmcsUhUOhXFhmtVyIdS/sQ08oQ33mALqhXd+OdJum883WBqljuAZG01JcbvEuC/sWn63kG/vTj1ND6R8pkH3yNgMHDthtYyDVhaUyPeN8FWZWz1o3koeEq5Brd9cMTGD6aTRWK8UrPqLJhYcxw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xiWPo5rjWNA/PBVIm8tPUmXe+XE3l74Vgdg0+9VU4WA=;
 b=WJjXrFpJX+X+Z5BLRMBKViM238swwC27hcmol6YdqTsMATRq7uhgngja+jUiL9W9m6ZosTHZPnMYHpfJcDuCRfCJC83uGFhZZ7b/s4ZccDSq5bKQIwgqGDEWdM+F0C52f/de5gIt56v0tHMCMt/yK1m16HoyebX1csSlfbDOo311YIFDyU84j4EtivEmjjxj0HZjCxuDeUtUh7dfGlb80QP1QsnpHzmha21viPOSw+JYlYzRk6BuoSAd/KboOvlENXQQYlOtiyKxBm43BZqDXJgKKVAfDBmchLUybDwgVxuh34SUQNjUHBHMYoTvp5rU6xgTFqj0aheLBXa0fgwevA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xiWPo5rjWNA/PBVIm8tPUmXe+XE3l74Vgdg0+9VU4WA=;
 b=XSJN6Va+NRRGsW4JYMmY77bFTZsUz7Nv89YT7RbAWgdppjRrfFeiOPPXmZF+W1X2zA8qvaQ0+JvtGqiJC5QQT0+ZNXQ/gF15PdTpfPFnGXbzJ1hj20psK8Qgiiqhl3Wq7Jjo785LBZUY8QwajKTOnti8o+x/Q6M4L6vYT9Gz86o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <0330174b-bda4-44fc-825b-6a680070b9dd@amd.com>
Date: Tue, 9 Sep 2025 11:29:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [ImageBuilder] Use LOAD_CMD by default if not specified in
 load_file()
To: Mykola Kvach 
CC: , 
References: <20250909074141.7356-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
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: SJ1PEPF00001CE5:EE_|BY5PR12MB4161:EE_
X-MS-Office365-Filtering-Correlation-Id: 385fd41a-cfbd-4b67-52b0-08ddef836b4f
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?MXluOEZyMENNZ3VLRHovaW1iMG5vYWIwa2kwVnAva1BsbjFvZVM2blkzb3JP?=
 =?utf-8?B?blJ0MGRSRGN3MXEvYTZ2N0lpaTRnWm9uajJkSnQzdzZMSDAwdDVsbkRkV2xl?=
 =?utf-8?B?TzRaalNOK0ZJa0Qvd2F5M3FXSEcwL2VZMzJQcmFBNDBrajl0dUxLT045a0hN?=
 =?utf-8?B?elFubmUycWpVbnVLMm5qT1Z4M0FNMFFxWTZzcmRIZWxyQVlaQkEvM0tQWjdP?=
 =?utf-8?B?alJ5TGNjUlN2Y2pvN2xlNzZlNDB5aVcyZGhwVmJ2TzdUMzBXSDdZOUlXZ0RJ?=
 =?utf-8?B?WGd5ZjV2aG11OWxYcmtVcDdKaUtBT25sVXJGbXFCR3M0MmpNNlV0TlVHWEtE?=
 =?utf-8?B?UkJlMlFqZ1hTbHBKcGdWM2dPK1FseUpLR211SlNreXdEZ29aNGt2R0gvYURz?=
 =?utf-8?B?SE1xdWdUWG9NNGhsUEtWSTgyZ0NaSGdQQTRrdjhZYUJCQ2NiK2FDRnNkTDVP?=
 =?utf-8?B?bEJ6YnZhNEowOFJDZGpDSE1XcmZLRnU5eUluNmh6bGYwSlVEMnBiRVl1REY2?=
 =?utf-8?B?TlErMjJjWGlNWldFYk8raTFzUERYRXpaNE05Wk41aTRqZlkyNEtmZ0NUOUF3?=
 =?utf-8?B?Vk9PcjhvM1duK0tCckxqOXE5bytZVUN5NExIMi9oV2xMSm1uRFJoU2wxNW04?=
 =?utf-8?B?QVExU0JYbFgyanluMW82V0hIbDh0TG9VUnlmYTg0QnRkbnV3U1dTNWhKVmI2?=
 =?utf-8?B?emU2K2txWm1zRlorZEZWQXRRVWxtN3dXa2hjanduYlVZcGd3SmdvOTdyOGpG?=
 =?utf-8?B?VmpyNysraFJkZU54V3RlTEpJRERPRmg5c3RzSlpYV1p2M09Ta2ZETTdWYkNU?=
 =?utf-8?B?UFZwT3k4dVJsUEJYc1psalp1MXM2STdQWXYxQUVTWk9TSjl2WFZKMmVuZXRH?=
 =?utf-8?B?alI5MENqTFI0anduUVBRSzArS3U5aWZGK2NkSTJHZW5rUlFBNE1jVkpiVDFm?=
 =?utf-8?B?Q2dKSmltQU5uMWZQZGRXa21EUysyaTdBRGNtTWlNdE0yeXduNTRDekMrMGg0?=
 =?utf-8?B?MDJoZGdKSWtYUVlTbFFBM3AwaElzdXdPOC9XRVl5UkJDVjdUTWhLTmVYMTdu?=
 =?utf-8?B?VUc5alJIdVpzSHdramFhOEw2OGNXdmpaK2pCTnZhQ0NTNHJUWTcxRDhoaTBV?=
 =?utf-8?B?MkNEZEQwWVREMzJXMDlzb2NFUG9sdXE2YVpuZmlESTFCakpOZWl3TzVzUnFE?=
 =?utf-8?B?bEtUODFmemVyS1lUcjJMaTNGZzlkRG5DVlA0TTAreGovb2dHVGFyZ2h5YlJD?=
 =?utf-8?B?WFFaZ25OZHBqcWVyelcvdDVvVTRiR0RnQUhFcllxZWhFMVRUSkFlV2lqNmNq?=
 =?utf-8?B?eFRNRUpWWVZWMUV4ckFUT0dUdXRUbHdwcFRhcDhyLzJVOEdWbDROYzhGeTFo?=
 =?utf-8?B?ZUlMcnkxNEVnajAzY0lqdVJhVmN6SjIwMm0rcDFWZGx3K2VFWDU5QzFhL3pX?=
 =?utf-8?B?VzViQi9hTmxVcE1wVEk4eUVrSjRjaWFGc2Jvb0FGM2hNQjlPaDdaQmtUeXlP?=
 =?utf-8?B?VjE1K054d2s5WHExYkZvNGdVQ1VKVmRDcnp0SWw3ZDlDeURtQXdFdGxmU3V1?=
 =?utf-8?B?M1dxMUpFM3N6V1U4cUxhOXlPMy9WbzREdmxBOFBRd3lpZzhOMUtOYW83V1Vw?=
 =?utf-8?B?VDhtVVUvSFJOZHN1LzRzOFRkVEhSYlNQK1VHT1YrQnM3UkNQSDFreE1BeStL?=
 =?utf-8?B?aFpGK3hQdmZzREh2K2JqcXF4M2R4NnVPZTdINTQ3Y0pLSHpKUUVOaWRUamhx?=
 =?utf-8?B?VW9IUUVQVElDckRiSS9Fc2JqbHhidkhLOU45SDBadkxOYWpjMEZwYjVaNS9x?=
 =?utf-8?B?UC9ITFFOTkVDNHpSUVNqZjZaaW5Ec29HNGNDT2JMQzY5RUo1QnpiRStxbkJr?=
 =?utf-8?B?Yjg2UkdLbTljZ3VRVjZZdGh4ZmpUWjF2dHJKSWxXYTlER2lEQnJPbDNuV3Rs?=
 =?utf-8?B?U2NtVmZJUnZPYWtON3JtNlFFTG52emh5WFhHYnd6UW5Pbys4bDlnSnpwZ1Q2?=
 =?utf-8?B?eXc4blMzbFEzZnhVVnkxQ3dXZWx2ZHkxNVdrdFE1aTlFRUZmb1orT2hGcDdz?=
 =?utf-8?Q?KNkXet?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 09 Sep 2025 09:29:47.5266
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 385fd41a-cfbd-4b67-52b0-08ddef836b4f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CE5.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4161



On 09/09/2025 11:22, Mykola Kvach wrote:
> Hi Michal,
> 
> Thank you for the patch and the detailed explanation.
> 
> On Tue, Sep 9, 2025 at 10:42 AM Michal Orzel  wrote:
>>
>> Commit 061d6782756f modified load_file() to take load command as
>> argument but did not change all the invocations (e.g. loading standalone
>> Linux, bitstream, etc.) which broke the output script (load command
>> empty). Fix it by defaulting to LOAD_CMD if not specified.
>>
>> Fixes: 061d6782756f ("Add config option to use separate load commands for Xen, DOM0 and DOMU binaries")
>> Signed-off-by: Michal Orzel 
>> ---
>>  scripts/uboot-script-gen | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
>> index 849b8f939e81..4f9261035d73 100755
>> --- a/scripts/uboot-script-gen
>> +++ b/scripts/uboot-script-gen
>> @@ -736,6 +736,12 @@ function load_file()
>>      local base="$(realpath $PWD)"/
>>      local relative_path=${absolute_path#"$base"}
>>
>> +    # Default to LOAD_CMD if not specified
>> +    if test -z "${load_cmd}"
>> +    then
>> +        load_cmd="${LOAD_CMD}"
>> +    fi
>> +
> 
> I was wondering if we could use a slightly more concise notation here, like:
> : "${load_cmd:=$LOAD_CMD}"
> 
> It does the same thing but is a bit more idiomatic for Bash scripts.
Some time ago, Stefano requested me to use a simpler notation in ImageBuilder,
so that it's immediately clear what the script does. Therefore I followed this
suggestion here as well. I will let him choose what suits the project best.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:37:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:37:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116037.1462461 (Exim 4.92)
	(envelope-from )
	id 1uvunE-0000tg-8T; Tue, 09 Sep 2025 09:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116037.1462461; Tue, 09 Sep 2025 09:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvunE-0000tZ-5d; Tue, 09 Sep 2025 09:37:40 +0000
Received: by outflank-mailman (input) for mailman id 1116037;
 Tue, 09 Sep 2025 09:37:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvunC-0000tT-Fa
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:37:38 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ee32ea7-8d60-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:37:37 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-45b9c35bc0aso47545205e9.2
 for ; Tue, 09 Sep 2025 02:37:37 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45de16b8b58sm129214985e9.4.2025.09.09.02.37.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:37: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: 9ee32ea7-8d60-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757410656; x=1758015456; 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=4XElcJECP7+8ySi8fl9eJbEz4NEzPyATGv+tov1ERLQ=;
        b=RuBTTaKL5fExD4lQtjccYn2yVMpduaKieDvDwKYTEcEZd2BT6gSt0DRb3gfBllZ70a
         NlP1auvMBrQou5QVXVAx9VQycN3+I1bg8o2AAo9po5ceiqUn4QOlY93xfu0RPSgfqer5
         zuh1wssWqLxuWzaIYLz7JWWzr23k2xaMWrv9EFZfOhzKFUpR9TtrJBnX1w5IVEVsQDHc
         G1X/zG/Qv1Jat8YzVtdnwpeeWo2sTCkObIXC+XLRf6LyRLi3HXuo1yiql6nyJFX3JuiI
         kK0rpaxom6eEAaEZa/ZXbLDggl11hk2Z3T2NSV/lvlNcAj+S4nYxFpKHpPB/RFxElIxH
         1lTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757410656; x=1758015456;
        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=4XElcJECP7+8ySi8fl9eJbEz4NEzPyATGv+tov1ERLQ=;
        b=j9VYzpfkHOVB6aI9JoZPfaXu+V8cqqP2mNHN+v0KXyGAv1BE+7LcyGZ9waDQGdeewm
         c/gVqhs9WHOALXhW3eOBlGaExxnLAE1saj97d32Zx2OMLrAOmgB9i0wIVNctPGmmlKRj
         X7AYbegBqxrKHPFkGWOJf+f+xnnmGzo3kikVfVSZ6cTaxcxBvoATTF1g7Rdclbz6PxTf
         o8p1bvYnUUpPV8ZJxCBK2HIeHOqh3fdpBooDBUQHG5B+pO6qte0eel0t6tutQIeF9oln
         E8OJF+Mdu7cNZFLrQgLpPDdex+6jIcFjM2kkuCNKZHB/VUjabUl+a5TRjCzlwt+6o1dV
         UHbw==
X-Forwarded-Encrypted: i=1; AJvYcCWQCtoy34zqovsGbmAutBYLdckGoddbWcFIUsqeIItqj8zebq5O5/t2U5oOZ7Ka+fSK6ygZcMGRwgY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwI9bjtM94R/ar+IYGPULqic2UQ0Z57p4YyKvf6V8Z+evEBKU3w
	dcnacKshDR3V3WRWb8Mgu2aMpOlRdlZl8a8LTRDCHDLrRH4lR8gq8l28UkGKzRKFY/4=
X-Gm-Gg: ASbGncvUxqqkkdQHFOOCAUDUSpQs/iQwS0uHSNv8mnVuQwgu55adqcnOlv6pNYi5Gy2
	nuyg8E3/sAPGFnB/jYuJI4GwFnhzSoSITNNAo73O0uzJVcoW4/sqkgtpstJfIhZ8vymgoln1k6w
	WiXW7AGocyVfcpnDqbH+fbKyK/0Ze87ZFDTqPs4QyBw2PxVrnFJEKd+zLqC5Dxom3Yh8KmeWDFq
	pKNTqAE9vTnUJnOCQQ404CrdqB+SGttSxG9aFF/K5RUzsY3g+pdMDQ/f20wzZvHsSCMvr+3sdOQ
	MdgsH+CyrI3N87OkDGGr3A5u/Kb6CSPkdGVYTpwomLIQlrRtEkeYCDp+U/7orRIXU6n6bIJNZWd
	FYHDv553HU5ZfpJwMg0gE+lnELbPLjl1pQ5h6fyj4+fMuPeU6jzlJqxF4HwSJPb2v2dRJ2vvIxb
	ybVGaGXEIYPuAQCJnIsh5jLmJz6PWLSqFx7X8qV4YS9mod
X-Google-Smtp-Source: AGHT+IHwqTpyjN6Kpfprj3lvyaI65S9KlfYJXUJjVo+3/81P0K/21tdQcXIRqnFGfxS9vPLVolXDMQ==
X-Received: by 2002:a05:600c:1c9d:b0:45d:e135:6bb2 with SMTP id 5b1f17b1804b1-45de1356cc4mr75349405e9.21.1757410656405;
        Tue, 09 Sep 2025 02:37:36 -0700 (PDT)
Message-ID: <360712fa-f7a0-4674-acc4-76f79141fe4f@suse.com>
Date: Tue, 9 Sep 2025 11:37:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
To: David Hildenbrand ,
 Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.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="------------BeYvUArs7t07H8bFnKjaf7a6"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------BeYvUArs7t07H8bFnKjaf7a6
Content-Type: multipart/mixed; boundary="------------N21H8u063pzOozrNPbZG8YaJ";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: David Hildenbrand ,
 Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Message-ID: <360712fa-f7a0-4674-acc4-76f79141fe4f@suse.com>
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.com>
 
In-Reply-To: 

--------------N21H8u063pzOozrNPbZG8YaJ
Content-Type: multipart/mixed; boundary="------------ku0itVfiK1E3s3Do8zg7Z645"

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

T24gMDkuMDkuMjUgMTE6MTMsIERhdmlkIEhpbGRlbmJyYW5kIHdyb3RlOg0KPiBPbiAwOC4w
OS4yNSAwOTozOSwgS2V2aW4gQnJvZHNreSB3cm90ZToNCj4+IENvbW1pdCA0OTE0N2JlYjBj
Y2IgKCJ4ODYveGVuOiBhbGxvdyBuZXN0aW5nIG9mIHNhbWUgbGF6eSBtb2RlIikNCj4+IG9y
aWdpbmFsbHkgaW50cm9kdWNlZCBzdXBwb3J0IGZvciBuZXN0ZWQgbGF6eSBzZWN0aW9ucyAo
TEFaWV9NTVUgYW5kDQo+PiBMQVpZX0NQVSkuIEl0IGxhdGVyIGdvdCByZXZlcnRlZCBieSBj
b21taXQgYzM2NTQ5ZmY4ZDg0IGFzIGl0cw0KPj4gaW1wbGVtZW50YXRpb24gdHVybmVkIG91
dCB0byBiZSBpbnRvbGVyYW50IHRvIHByZWVtcHRpb24uDQo+Pg0KPj4gTm93IHRoYXQgdGhl
IGxhenlfbW11IEFQSSBhbGxvd3MgZW50ZXIoKSB0byBwYXNzIHRocm91Z2ggYSBzdGF0ZSB0
bw0KPj4gdGhlIG1hdGNoaW5nIGxlYXZlKCkgY2FsbCwgd2UgY2FuIHN1cHBvcnQgbmVzdGlu
ZyBhZ2FpbiBmb3IgdGhlDQo+PiBMQVpZX01NVSBtb2RlIGluIGEgcHJlZW1wdGlvbi1zYWZl
IG1hbm5lci4gSWYgeGVuX2VudGVyX2xhenlfbW11KCkgaXMNCj4+IGNhbGxlZCBpbnNpZGUg
YW4gYWN0aXZlIGxhenlfbW11IHNlY3Rpb24sIHhlbl9sYXp5X21vZGUgd2lsbCBhbHJlYWR5
DQo+PiBiZSBzZXQgdG8gWEVOX0xBWllfTU1VIGFuZCB3ZSBjYW4gdGhlbiByZXR1cm4gTEFa
WV9NTVVfTkVTVEVEIHRvDQo+PiBpbnN0cnVjdCB0aGUgbWF0Y2hpbmcgeGVuX2xlYXZlX2xh
enlfbW11KCkgY2FsbCB0byBsZWF2ZQ0KPj4geGVuX2xhenlfbW9kZSB1bmNoYW5nZWQuDQo+
Pg0KPj4gVGhlIG9ubHkgZWZmZWN0IG9mIHRoaXMgcGF0Y2ggaXMgdG8gZW5zdXJlIHRoYXQg
eGVuX2xhenlfbW9kZQ0KPj4gcmVtYWlucyBzZXQgdG8gWEVOX0xBWllfTU1VIHVudGlsIHRo
ZSBvdXRlcm1vc3QgbGF6eV9tbXUgc2VjdGlvbg0KPj4gZW5kcy4geGVuX2xlYXZlX2xhenlf
bW11KCkgc3RpbGwgY2FsbHMgeGVuX21jX2ZsdXNoKCkNCj4+IHVuY29uZGl0aW9uYWxseS4N
Cj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBLZXZpbiBCcm9kc2t5IDxrZXZpbi5icm9kc2t5QGFy
bS5jb20+DQo+PiAtLS0NCj4+IMKgIGFyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmjC
oMKgwqDCoMKgwqAgfMKgIDYgKystLS0tDQo+PiDCoCBhcmNoL3g4Ni9pbmNsdWRlL2FzbS9w
YXJhdmlydF90eXBlcy5oIHzCoCA0ICsrLS0NCj4+IMKgIGFyY2gveDg2L3hlbi9tbXVfcHYu
Y8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgMTEgKysrKysrKystLS0NCj4+
IMKgIDMgZmlsZXMgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkN
Cj4+DQo+PiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaCBi
L2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmgNCj4+IGluZGV4IDY1YTBkMzk0ZmJh
MS4uNGVjZDNhNmIxZGVhIDEwMDY0NA0KPj4gLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9hc20v
cGFyYXZpcnQuaA0KPj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaA0K
Pj4gQEAgLTUyOSwxNCArNTI5LDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBhcmNoX2VuZF9j
b250ZXh0X3N3aXRjaChzdHJ1Y3QgDQo+PiB0YXNrX3N0cnVjdCAqbmV4dCkNCj4+IMKgICNk
ZWZpbmXCoCBfX0hBVkVfQVJDSF9FTlRFUl9MQVpZX01NVV9NT0RFDQo+PiDCoCBzdGF0aWMg
aW5saW5lIGxhenlfbW11X3N0YXRlX3QgYXJjaF9lbnRlcl9sYXp5X21tdV9tb2RlKHZvaWQp
DQo+PiDCoCB7DQo+PiAtwqDCoMKgIFBWT1BfVkNBTEwwKG1tdS5sYXp5X21vZGUuZW50ZXIp
Ow0KPj4gLQ0KPj4gLcKgwqDCoCByZXR1cm4gTEFaWV9NTVVfREVGQVVMVDsNCj4+ICvCoMKg
wqAgcmV0dXJuIFBWT1BfQ0FMTDAobGF6eV9tbXVfc3RhdGVfdCwgbW11LmxhenlfbW9kZS5l
bnRlcik7DQo+PiDCoCB9DQo+PiDCoCBzdGF0aWMgaW5saW5lIHZvaWQgYXJjaF9sZWF2ZV9s
YXp5X21tdV9tb2RlKGxhenlfbW11X3N0YXRlX3Qgc3RhdGUpDQo+PiDCoCB7DQo+PiAtwqDC
oMKgIFBWT1BfVkNBTEwwKG1tdS5sYXp5X21vZGUubGVhdmUpOw0KPj4gK8KgwqDCoCBQVk9Q
X1ZDQUxMMShtbXUubGF6eV9tb2RlLmxlYXZlLCBzdGF0ZSk7DQo+PiDCoCB9DQo+PiDCoCBz
dGF0aWMgaW5saW5lIHZvaWQgYXJjaF9mbHVzaF9sYXp5X21tdV9tb2RlKHZvaWQpDQo+PiBk
aWZmIC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaCBiL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtLyANCj4+IHBhcmF2aXJ0X3R5cGVzLmgNCj4+IGluZGV4IGJj
MWFmODY4NjhhMy4uYjdjNTY3Y2NiZjMyIDEwMDY0NA0KPj4gLS0tIGEvYXJjaC94ODYvaW5j
bHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaA0KPj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9h
c20vcGFyYXZpcnRfdHlwZXMuaA0KPj4gQEAgLTQ1LDggKzQ1LDggQEAgdHlwZWRlZiBpbnQg
bGF6eV9tbXVfc3RhdGVfdDsNCj4+IMKgIHN0cnVjdCBwdl9sYXp5X29wcyB7DQo+PiDCoMKg
wqDCoMKgIC8qIFNldCBkZWZlcnJlZCB1cGRhdGUgbW9kZSwgdXNlZCBmb3IgYmF0Y2hpbmcg
b3BlcmF0aW9ucy4gKi8NCj4+IC3CoMKgwqAgdm9pZCAoKmVudGVyKSh2b2lkKTsNCj4+IC3C
oMKgwqAgdm9pZCAoKmxlYXZlKSh2b2lkKTsNCj4+ICvCoMKgwqAgbGF6eV9tbXVfc3RhdGVf
dCAoKmVudGVyKSh2b2lkKTsNCj4+ICvCoMKgwqAgdm9pZCAoKmxlYXZlKShsYXp5X21tdV9z
dGF0ZV90KTsNCj4+IMKgwqDCoMKgwqAgdm9pZCAoKmZsdXNoKSh2b2lkKTsNCj4+IMKgIH0g
X19ub19yYW5kb21pemVfbGF5b3V0Ow0KPj4gwqAgI2VuZGlmDQo+PiBkaWZmIC0tZ2l0IGEv
YXJjaC94ODYveGVuL21tdV9wdi5jIGIvYXJjaC94ODYveGVuL21tdV9wdi5jDQo+PiBpbmRl
eCAyMDM5ZDUxMzJjYTMuLjZlNTM5MGZmMDZhNSAxMDA2NDQNCj4+IC0tLSBhL2FyY2gveDg2
L3hlbi9tbXVfcHYuYw0KPj4gKysrIGIvYXJjaC94ODYveGVuL21tdV9wdi5jDQo+PiBAQCAt
MjEzMCw5ICsyMTMwLDEzIEBAIHN0YXRpYyB2b2lkIHhlbl9zZXRfZml4bWFwKHVuc2lnbmVk
IGlkeCwgcGh5c19hZGRyX3QgDQo+PiBwaHlzLCBwZ3Byb3RfdCBwcm90KQ0KPj4gwqAgI2Vu
ZGlmDQo+PiDCoCB9DQo+PiAtc3RhdGljIHZvaWQgeGVuX2VudGVyX2xhenlfbW11KHZvaWQp
DQo+PiArc3RhdGljIGxhenlfbW11X3N0YXRlX3QgeGVuX2VudGVyX2xhenlfbW11KHZvaWQp
DQo+PiDCoCB7DQo+PiArwqDCoMKgIGlmICh0aGlzX2NwdV9yZWFkKHhlbl9sYXp5X21vZGUp
ID09IFhFTl9MQVpZX01NVSkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gTEFaWV9NTVVf
TkVTVEVEOw0KPj4gKw0KPiANCj4gWW91IG1lbnRpb24gYWJvdmUgInByZWVtcHRpb24tc2Fm
ZSBtYW5uZXIiIGFib3ZlLCBzbyBJIGFtIHdvbmRlcmluZywNCj4gd2hhdCBpZiB3ZSBnZXQg
cHJlZW1wdGVkIGltbWVkaWF0ZWx5IGFmdGVyIGRvaW5nIHRoZSB0aGlzX2NwdV9yZWFkKCkg
YW5kIGdldCANCj4gc2NoZWR1bGVkIG9uIGFub3RoZXIgQ1BVPw0KPiANCg0KVGhpcyBzaG91
bGQgc3RpbGwgYmUgY29ycmVjdDogcHJlZW1wdGlvbiBuZWVkcyBhIGNvbnRleHQgc3dpdGNo
IHRvIGhhcHBlbiwNCnNvIHhlbl9zdGFydF9jb250ZXh0X3N3aXRjaCgpIGFuZCB4ZW5fZW5k
X2NvbnRleHRfc3dpdGNoKCkgYXJlIGludm9sdmVkLg0KVGhvc2UgYXJlIGRlYWxpbmcgd2l0
aCB0aGlzIHByb2JsZW0gYnkgZG9pbmcgdGhlIHJpZ2h0IHRoaW5nIGluIHRoZSBvbGQNCmFu
ZCB0aGUgbmV3IGNvbnRleHQuDQoNCg0KSnVlcmdlbg0K
--------------ku0itVfiK1E3s3Do8zg7Z645
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-----

--------------ku0itVfiK1E3s3Do8zg7Z645--

--------------N21H8u063pzOozrNPbZG8YaJ--

--------------BeYvUArs7t07H8bFnKjaf7a6
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/Ey8FAmi/9V4FAwAAAAAACgkQsN6d1ii/Ey+F
eAf+JATQ71kRnWaomTj1xL+hfmy+uZt/wVyu3xYTMbJ9EWKIHTJr/D1HsJgdDwE2A5eGGzTSCd5X
PY69tcvWQHLYqi689FgEbCGN2InjvaAtQncZecnR47pyIeYp5IctlX9bkH2BeRw5LrV22rRdLwXn
gBiHVv8Hc7Q0U5MdAfWlYld7f60jjKOL7nrkPnuycfxdXE6LRoKXvavgkczfj3OUfxLpJKN2eUNz
De7Ot1NAH2KSq5mx7560580j0QE1cyJwru6S14unms+MyjlcBxiNtEeRRskOwuPAJ4m8c7CapmbD
/rYnIaeNCRqVGx0NPnojTaMCE+tMExv1H15wHlWA3w==
=5cPm
-----END PGP SIGNATURE-----

--------------BeYvUArs7t07H8bFnKjaf7a6--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:41:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:41:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116053.1462472 (Exim 4.92)
	(envelope-from )
	id 1uvuqp-0002Qr-RB; Tue, 09 Sep 2025 09:41:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116053.1462472; Tue, 09 Sep 2025 09:41: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 1uvuqp-0002Qk-Nf; Tue, 09 Sep 2025 09:41:23 +0000
Received: by outflank-mailman (input) for mailman id 1116053;
 Tue, 09 Sep 2025 09:41: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 1uvuqp-0002Qe-7T
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:41:23 +0000
Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com
 [148.163.158.5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2452ae64-8d61-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:41:22 +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 58983LO1017978;
 Tue, 9 Sep 2025 09:40:44 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490acqxs3x-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 09:40:44 +0000 (GMT)
Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5899HIXj021030;
 Tue, 9 Sep 2025 09:40:43 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 490acqxs3v-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 09:40:43 +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 5896bOAX008428;
 Tue, 9 Sep 2025 09:40:42 GMT
Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 49109pjf7r-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 09:40:42 +0000
Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com
 [10.20.54.100])
 by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 5899eexO52167112
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 9 Sep 2025 09:40:40 GMT
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 604B32004D;
 Tue,  9 Sep 2025 09:40:40 +0000 (GMT)
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 8D98620043;
 Tue,  9 Sep 2025 09:40:38 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.87.149.210])
 by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue,  9 Sep 2025 09:40:38 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2452ae64-8d61-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=zWcQIXAgSZE3jCftx8qMBMf1VpUurI
	YqH9HodqEjE0k=; b=ERAKr2/0b+85Gl0gJGPChBwQF66LW3Oi2PTpVHT0S9O3cT
	Ogh6Obsb22mSDB6RKtFvicQxQH7Em5A8oD0I5nxAwaNb8/uo3nlQzflgWHoDaI73
	HJYbO2EM++BmL63dYswiKyf3DCl4sC43LQKUJvgYSzJoqo9flhIr4HpJX5FgSugx
	nxkpTZzhMCKXzjU82MrRkLPjYDbZe873Vx7Wql1XT2f1I7N0MW1XZjVRPa59K2LD
	VV7jPCPICsB1PgyR4Skp/kJKJN0V5UfeoBSNtFq2eg9a3cWAGVbhYaW2tp1HOhpP
	+lYn2f2O6UcFcD/48WOX69CsC02e71Jd9O9OLeiA==
Date: Tue, 9 Sep 2025 11:40:37 +0200
From: Alexander Gordeev 
To: David Hildenbrand 
Cc: Kevin Brodsky , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: CdA-H8SVNxdbZ5nTnrwiW_1I0UR-iy8D
X-Authority-Analysis: v=2.4 cv=Mp1S63ae c=1 sm=1 tr=0 ts=68bff61c cx=c_pps
 a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=xmnICLmBNk8AszDsb_MA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-ORIG-GUID: uTrJRk-Nt5us74ILiXCJ7SL_HOQZhnLx
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDAwMCBTYWx0ZWRfXy71df+5jjUw/
 ntr+yICfUeQPRObSlyN3Yh1y4xhRnHGHhZFfRZCcvuRAacCykIbiLJkHQ30eUBJKOGl10TSIS42
 +3nIeLTG23/y6JszEVZ1Ed+b1iNk9DDxZsvwkIfCXfzVoNJXgV1cawSe1+N/vBFlEkK7ENOmW+P
 5QFev+/ePpqxVRniHssrBkwoaFfvkZZLW/2f9hVQyEtzMR8VsnBMkGYw6WFkufIgIXN5VkhAYVQ
 X+97jjddjBhYGKbSAHhaXMbOCL2qCKM7v5sv/V5bw5Wl8DJ9XDeAuCQ/41VgYzOkHMOtqD+ztQw
 0x/7e9psYHEV7vlYlvzJw+aRJnWLrm5gVwmA8e51Z46BZm3hlJcuLkZtLVQrCNNUZn7EXpW7Hgp
 /9u+P9X3
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-08_06,2025-09-08_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 impostorscore=0 malwarescore=0 clxscore=1011 phishscore=0 spamscore=0
 adultscore=0 priorityscore=1501 bulkscore=0 suspectscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509060000

On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
> On 08.09.25 09:39, Kevin Brodsky wrote:
> > arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> > (taking and returning no value). This is proving problematic in
> > situations where leave() needs to restore some context back to its
> > original state (before enter() was called). In particular, this
> > makes it difficult to support the nesting of lazy_mmu sections -
> > leave() does not know whether the matching enter() call occurred
> > while lazy_mmu was already enabled, and whether to disable it or
> > not.
> > 
> > This patch gives all architectures the chance to store local state
> > while inside a lazy_mmu section by making enter() return some value,
> > storing it in a local variable, and having leave() take that value.
> > That value is typed lazy_mmu_state_t - each architecture defining
> > __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> > For now we define it as int everywhere, which is sufficient to
> > support nesting.
...
> > {
> > + lazy_mmu_state_t lazy_mmu_state;
> > ...
> > - arch_enter_lazy_mmu_mode();
> > + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> > ...
> > - arch_leave_lazy_mmu_mode();
> > + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> > ...
> > }
> > 
> > * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
> >    lazy_mmu is already enabled, and it temporarily disables it by
> >    calling leave() and then enter() again. Here we want to ensure
> >    that any operation between the leave() and enter() calls is
> >    completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
> >    leave() to fully disable lazy_mmu. enter() will then re-enable it
> >    - this achieves the expected behaviour, whether nesting occurred
> >    before that function was called or not.
> > 
> > Note: it is difficult to provide a default definition of
> > lazy_mmu_state_t for architectures implementing lazy_mmu, because
> > that definition would need to be available in
> > arch/x86/include/asm/paravirt_types.h and adding a new generic
> >   #include there is very tricky due to the existing header soup.
> 
> Yeah, I was wondering about exactly that.
> 
> In particular because LAZY_MMU_DEFAULT etc resides somewehere compeltely
> different.
> 
> Which raises the question: is using a new type really of any benefit here?
> 
> Can't we just use an "enum lazy_mmu_state" and call it a day?

I could envision something completely different for this type on s390,
e.g. a pointer to a per-cpu structure. So I would really ask to stick
with the current approach.

> -- 
> Cheers
> 
> David / dhildenb

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:42:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:42:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116063.1462481 (Exim 4.92)
	(envelope-from )
	id 1uvurW-0002uR-2J; Tue, 09 Sep 2025 09:42:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116063.1462481; Tue, 09 Sep 2025 09: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 1uvurV-0002uK-Vf; Tue, 09 Sep 2025 09:42:05 +0000
Received: by outflank-mailman (input) for mailman id 1116063;
 Tue, 09 Sep 2025 09: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 1uvurU-0002Qe-W6
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:42:05 +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 3e26afb6-8d61-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:42:04 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-45dd505a1dfso31643795e9.2
 for ; Tue, 09 Sep 2025 02:42:04 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e752238832sm1864553f8f.31.2025.09.09.02.42.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02: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: 3e26afb6-8d61-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757410924; x=1758015724; 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=SjRoDXFIQA5duWfB2MZCu0jToXiY+NtBhO/biBCm3yY=;
        b=erNeJY+Y1Ox9IwmNDpAQ1FJhAdIBNRTng2KAm7VcxpeHpVjguL9fXpYHlWu08D4VfF
         k6394F5RAr37NavGU2xDLK4AnZ8HfV51EPVKQtli2oXZFiP+AbtgZiXJNMCXnI7DaL/0
         31VxeZpwFPKVPFP3tDiJIqe/R53hZkQmOcXCYLSA4NCS69VSaoFBBP/s9yqNETeykxky
         n/GA25ziEot5gzQ8BOEqpJL1R0dzNNiHsCWfC42iXoYyNVN3mdgyeXwQ/lyauR7DKBrq
         0RRVXfrziEIhryxmcZxYwKwVl5DYMWsNQ77FB4E9ouYPOVzlx4Lq/0anPTtYruS6ykBJ
         LFBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757410924; x=1758015724;
        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=SjRoDXFIQA5duWfB2MZCu0jToXiY+NtBhO/biBCm3yY=;
        b=plE3HS3siURpzVdGa4X7jhZabPSs79PLXyA8OV00e1O/ca/e+/RLC4xTOjLJFg94pY
         PuuduoPYQy22PzZpXN1K7AnxE4t+UNn/bVlorco81007wQz3ucGfuDTVD3r3zR3jFyke
         Gg7/is5SjngEwx+o9OFgIqRGQCvr0rfieXEMbJm5iY/1HX6R2J04KMak3pM/tqSqat/C
         HQFoERJaSFOy4F3QF5dgWHV2sYiZOmPny7jULrc9QDx/mYrTULyMyp23U87EyLZUpgbt
         CQF77bxs3bLlE+m+6annfzLd/FdXikjLoZMVMs0Vb/hK9W7CIUWt1TVW1wxFPTUzYZBZ
         qWBA==
X-Forwarded-Encrypted: i=1; AJvYcCVmuVrSOI91cdukFZHv0uLm2ZY+jIMvLk4BdkuCjNy9rDSVcJJ6lj2oPBRzabrH+eZzruUk7dJJGeo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxr9QQ4MHeAak5ldsn/i2RdtbLHDg27twAOWOoDbV5L82thGLY7
	coJp30WZ8zVC8e/03zQmc6ufiuAmEZUU/MCXbZl1nvL/nmZxwNgvoS3OCgLKag281wM=
X-Gm-Gg: ASbGncurBB0k8g0SciGN6s4oXUMx6BzzQe1fLzTPfvzQs8xWaLh2x6yr/+xqUvLWwPF
	UFLYoMXQ+WjToB/rr1y+dfT5CWNY9zvxifyVfXFxqcjRfwZbexxXBE3KfI8cU9oCigQvL9VGS4s
	N0eqORv7H3QKo8hcpKplTDGLRG60v93IWbVLqmzKofOPInJD3FE7SXD8TDoZS7I9z0OWE7c0oye
	Znm/FRg9yXu4eYj7qGf9OvT8tdVkMZBGHIKmI9uYkrRHzdtrNJTbsqj8oD+cZoAHg4I6EWf4Ujj
	z7N89voZMSxFjtHzt8ZPGc0ySVAGwnjvQ7W9TuFuLzltQkXBBI0XeClOQtmrASAaXN/jd/sbItl
	zjHrrKmb4J7eAgiL/1ymM43Ik/cdQghEiOYtzKi6lEDo+HjQhobbEZ5qrxkxS6VfJ+tpFcBdG7+
	NFUmlfICSPNfom/RPhHsz6ClEFnhJ+Mi9wpshAj1Dzw3nQpGWHsIg3WBA=
X-Google-Smtp-Source: AGHT+IENj+1E2T8r/gDXDQF+CsCcmRvQT/1w4yxsS7gi6iQW38MFrgfpZ1CxcgavO4g+sqDlHTXLsg==
X-Received: by 2002:a05:6000:2c0d:b0:3e7:441e:c9e1 with SMTP id ffacd0b85a97d-3e7441ecde8mr6021132f8f.18.1757410923604;
        Tue, 09 Sep 2025 02:42:03 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 11:42:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.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: <20250908073931.4159362-5-kevin.brodsky@arm.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------6t70nAkYkpQ5fhIc00dD9qVa"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------6t70nAkYkpQ5fhIc00dD9qVa
Content-Type: multipart/mixed; boundary="------------0NiQUpv1CWC70bbdwQmMvvwT";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.com>
In-Reply-To: <20250908073931.4159362-5-kevin.brodsky@arm.com>

--------------0NiQUpv1CWC70bbdwQmMvvwT
Content-Type: multipart/mixed; boundary="------------4l0ODE8pZhEM8pbolfSSghyw"

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

T24gMDguMDkuMjUgMDk6MzksIEtldmluIEJyb2Rza3kgd3JvdGU6DQo+IENvbW1pdCA0OTE0
N2JlYjBjY2IgKCJ4ODYveGVuOiBhbGxvdyBuZXN0aW5nIG9mIHNhbWUgbGF6eSBtb2RlIikN
Cj4gb3JpZ2luYWxseSBpbnRyb2R1Y2VkIHN1cHBvcnQgZm9yIG5lc3RlZCBsYXp5IHNlY3Rp
b25zIChMQVpZX01NVSBhbmQNCj4gTEFaWV9DUFUpLiBJdCBsYXRlciBnb3QgcmV2ZXJ0ZWQg
YnkgY29tbWl0IGMzNjU0OWZmOGQ4NCBhcyBpdHMNCj4gaW1wbGVtZW50YXRpb24gdHVybmVk
IG91dCB0byBiZSBpbnRvbGVyYW50IHRvIHByZWVtcHRpb24uDQo+IA0KPiBOb3cgdGhhdCB0
aGUgbGF6eV9tbXUgQVBJIGFsbG93cyBlbnRlcigpIHRvIHBhc3MgdGhyb3VnaCBhIHN0YXRl
IHRvDQo+IHRoZSBtYXRjaGluZyBsZWF2ZSgpIGNhbGwsIHdlIGNhbiBzdXBwb3J0IG5lc3Rp
bmcgYWdhaW4gZm9yIHRoZQ0KPiBMQVpZX01NVSBtb2RlIGluIGEgcHJlZW1wdGlvbi1zYWZl
IG1hbm5lci4gSWYgeGVuX2VudGVyX2xhenlfbW11KCkgaXMNCj4gY2FsbGVkIGluc2lkZSBh
biBhY3RpdmUgbGF6eV9tbXUgc2VjdGlvbiwgeGVuX2xhenlfbW9kZSB3aWxsIGFscmVhZHkN
Cj4gYmUgc2V0IHRvIFhFTl9MQVpZX01NVSBhbmQgd2UgY2FuIHRoZW4gcmV0dXJuIExBWllf
TU1VX05FU1RFRCB0bw0KPiBpbnN0cnVjdCB0aGUgbWF0Y2hpbmcgeGVuX2xlYXZlX2xhenlf
bW11KCkgY2FsbCB0byBsZWF2ZQ0KPiB4ZW5fbGF6eV9tb2RlIHVuY2hhbmdlZC4NCj4gDQo+
IFRoZSBvbmx5IGVmZmVjdCBvZiB0aGlzIHBhdGNoIGlzIHRvIGVuc3VyZSB0aGF0IHhlbl9s
YXp5X21vZGUNCj4gcmVtYWlucyBzZXQgdG8gWEVOX0xBWllfTU1VIHVudGlsIHRoZSBvdXRl
cm1vc3QgbGF6eV9tbXUgc2VjdGlvbg0KPiBlbmRzLiB4ZW5fbGVhdmVfbGF6eV9tbXUoKSBz
dGlsbCBjYWxscyB4ZW5fbWNfZmx1c2goKQ0KPiB1bmNvbmRpdGlvbmFsbHkuDQo+IA0KPiBT
aWduZWQtb2ZmLWJ5OiBLZXZpbiBCcm9kc2t5IDxrZXZpbi5icm9kc2t5QGFybS5jb20+DQoN
ClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVl
cmdlbg0K
--------------4l0ODE8pZhEM8pbolfSSghyw
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-----

--------------4l0ODE8pZhEM8pbolfSSghyw--

--------------0NiQUpv1CWC70bbdwQmMvvwT--

--------------6t70nAkYkpQ5fhIc00dD9qVa
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/Ey8FAmi/9mkFAwAAAAAACgkQsN6d1ii/Ey80
SAgAiJl65x111bqE27qLDXwGxB+GHINdgm+I0ml8OZ3XtcdZfY5Bn8HD+AFRa9lSJsdUCcklLH88
S/XTNIYun/KfdgyVrC8qkhA6upKCQ0rpmnpVnLRbhGIAfdA1IzOEVv2DasQOSUIW2FrnDMHnIM5j
9+GsXLikB0D+M5Sev7kMHqH0v6VpecDZxbEu6/sLpb/M/HFFLElALOu7Hyc50kf9HcdEFGeRGWGS
zeCAhFKiMqstJpK5XcvR/Gt9WVh9pNNhIyYYHfDfImt28tyiC90MYW+bnoykmn4S2v3yVQOo5qbZ
Ejwt4zi2ksSSuPgsa0AerARvR/6wjZwPfi35XC3Gfw==
=Ew/s
-----END PGP SIGNATURE-----

--------------6t70nAkYkpQ5fhIc00dD9qVa--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:55:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:55:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116082.1462492 (Exim 4.92)
	(envelope-from )
	id 1uvv48-00058Z-61; Tue, 09 Sep 2025 09:55:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116082.1462492; Tue, 09 Sep 2025 09:55: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 1uvv48-00058S-2T; Tue, 09 Sep 2025 09:55:08 +0000
Received: by outflank-mailman (input) for mailman id 1116082;
 Tue, 09 Sep 2025 09:55:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uvv46-00058M-OW
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:55:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvv46-001ca5-0J;
 Tue, 09 Sep 2025 09:55:06 +0000
Received: from [209.198.129.181] (helo=[10.1.3.247])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uvv46-001LdI-04;
 Tue, 09 Sep 2025 09:55: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" 
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=4SujrD6ZKDF9UPrtlsdWHGcCQTkfGbtTnGMd/vGAlYs=; b=LhhqRHWoOjeV9IZ6i2x0zRFcmD
	LOP0aL867ThOoYy4neBqomFniY5Vb6HsqN410+9QmedDgS4hyBqL19dkuB9GDwQjdOifIkrk9sFJH
	RXwdA2sqVmPxuzax7XnectWyGuW4XWb9+QEJgMLx/qWBeSThwg0Wj93TdKwcz/xPjUoo=;
Message-ID: 
Date: Tue, 9 Sep 2025 10:55:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
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: 
 <3e237c5256054a88b1c099d85d8bd1a602bba230.1756995595.git.oleksii_moisieiev@epam.com>
From: Julien Grall 
In-Reply-To: <3e237c5256054a88b1c099d85d8bd1a602bba230.1756995595.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

While going through the list of recently committed patches, I noticed 
some changes in the relinquish code.


On 04/09/2025 15:21, Oleksii Moisieiev wrote:
> @@ -1103,6 +1109,10 @@ int domain_relinquish_resources(struct domain *d)
>           ret = relinquish_p2m_mapping(d);
>           if ( ret )
>               return ret;

Style: There is a missing newline.

> +    PROGRESS(sci):

I don't quite understand why the sci relinquish was added right in the 
middle of the P2M relinquish logic. At least to me, it makes more sense 
to be closer to TEE (because this is firmware subsystem) and possibly 
even before releasing any devices.

Can you clarify why you chose this placement?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:55:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116090.1462502 (Exim 4.92)
	(envelope-from )
	id 1uvv4w-0005ak-DO; Tue, 09 Sep 2025 09:55:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116090.1462502; Tue, 09 Sep 2025 09:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvv4w-0005ad-Ac; Tue, 09 Sep 2025 09:55:58 +0000
Received: by outflank-mailman (input) for mailman id 1116090;
 Tue, 09 Sep 2025 09:55: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 1uvv4v-0005M3-72
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:55:57 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d93ca41-8d63-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 11:55:55 +0200 (CEST)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-336badc713dso36166471fa.2
 for ; Tue, 09 Sep 2025 02:55: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: 2d93ca41-8d63-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757411755; x=1758016555; 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=trXNkOUb+e4XWjKZ+g8FxQRzSN+vByLHBANdxnRnM8A=;
        b=M6yC8wxFLWo5YkWavOpzoA1vnYi6+88WqYt8oq01/H/iktJ8Q97lCrXFAF7yvLrgUG
         JCM4dKdE6jsj3uyrhrOtfY82Miwt7OK4kNBraVndY1545NmBw+lxFWvNYWxUDajsjbWG
         rXf2CSViDVFfEQvo53Qjk+V39X2LnRld2hEdROcy44lEGKC7jab18CcCMxvadWv+4Dc8
         rXXi/GFCDsSsulENT3PysXDCGIsK1b9zS5aouzKTS5J0/dgenvgJDiAbsh+MJzhtpsLn
         6v8EHXWWG3uiyw0SCD2bX/JRhEstKvuNOFhzCek2z9TWkbMYo4vDIaw/SfKIE0qJRYGC
         58jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757411755; x=1758016555;
        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=trXNkOUb+e4XWjKZ+g8FxQRzSN+vByLHBANdxnRnM8A=;
        b=qxiT8olv7kIQx5deGvDLyx0WJSADRKJpmnVDFwTUochVK1Rbbvl5hJZb3Pwy1VqpBW
         IholnnINxG8t1B4EIsKd9gmNjwj+YZf2Mlc0/1G4NzLh+KjZ3hd/qy6DzB9A2qnlpCQr
         /z1mvu08ud3KNs289hpsop0GBeEls2GFjDh5UaBT3iu9eEMAyBdK/XSYFrs2Xmzw6HLl
         IKQdrWaz38ngKos2fRpIHBtZSrcWMaa0j9iVIW7D4OAPLMByMz33AhVPKS2wingBFqhU
         vTitJbJYCtn7+wyp/ZfQIP7JBBn+3WMczY1lcX7YlYd0cO9OhbUceWl/AZgK94JlrDfq
         zcHQ==
X-Forwarded-Encrypted: i=1; AJvYcCX7u0rrNkFVimLjBKhyWjitYjVMe3lV2vgRh4H/V6Go39XAoFBG4JApHE179f8ldNiISexNxPO6mc8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy7pFUopji8B6UxDRp9lHfNzPzCisd+ibHmY9L7OsDppzbY6u0a
	U9Alvbo4a4nhgiHMwUhjb1azvpt50kIWq3jyFziPB9JNpyY48CDs9SjIOei9thf208EkWgJJgg4
	GA00HOAHeaH38b3Am2lfXsRUWcCegCLg=
X-Gm-Gg: ASbGnctGKKvdeEXxiTxv02xkfvnLFW1UkkIFrJ3TErLbHhlrjLG9C+TJuRnyDkew5jK
	08aTPIKzReMJJ+SFq7EpaQEsILfLPOB4qN/tcv9HbB9O1EZmszCM0qUtRttul4bnc4cX1DfARwm
	Vsf1eV7HI8K3nzTOMPKL0JHav2mhcGV4R4Ow3bP39Z0IBClg5v1xIW6lRhEJ5OLg+LaLUWZdh8a
	iccdw==
X-Google-Smtp-Source: AGHT+IHWN396RlsCN2AtLwcY/ltGIzaTsHCF4Kver2D1CeqvTtQwuaDSIyAv+1pNu+C9lik7gbkIUQtsQyDDMA5CKG4=
X-Received: by 2002:a05:651c:40c1:b0:336:e081:6696 with SMTP id
 38308e7fff4ca-33b553af561mr23768571fa.44.1757411754657; Tue, 09 Sep 2025
 02:55:54 -0700 (PDT)
MIME-Version: 1.0
References:  <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com>
  
 
 <21f2f6e1-cbf7-4b36-bbba-bffc2dab3422@suse.com> 
 <646f7070-83c7-45ce-a4c9-c59cd39a33c5@suse.com>
In-Reply-To: <646f7070-83c7-45ce-a4c9-c59cd39a33c5@suse.com>
From: Mykola Kvach 
Date: Tue, 9 Sep 2025 12:55:42 +0300
X-Gm-Features: Ac12FXw7f66_aXTP4qfTo6cSLYYfczfsBJ-PIzV1kM6Q8D2-UxdQ3s_h1HkskKg
Message-ID: 
Subject: Re: [PATCH v6 11/13] 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?= , 
	Saeed Nowshadi , Mykyta Poturai , 
	Mykola Kvach , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for your detailed comments and suggestions =E2=80=94 much appreciate=
d.

On Tue, Sep 9, 2025 at 12:14=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 09.09.2025 10:14, Mykola Kvach wrote:
> > On Tue, Sep 9, 2025 at 9:57=E2=80=AFAM Jan Beulich  =
wrote:
> >> On 09.09.2025 08:29, Mykola Kvach wrote:
> >>> Then, in domain_shutdown(), we can call need_hwdom_shutdown() instead
> >>> of directly checking is_hardware_domain(d). This keeps the logic
> >>> readable and avoids code duplication.
> >>>
> >>> What do you think about this approach?
> >>
> >> Well, there's still the CONFIG_ARM check in there that I would like to
> >> see gone. (As a nit, the use of u8 would also want to go away.)
> >
> > We could combine your proposal from v5 of this patch series, i.e., usin=
g the
> > HAS_HWDOM_SUSPEND extra config together with this helper function:
> >
> >     static inline bool need_hwdom_shutdown(const struct domain *d)
> >     {
> >         bool is_hw_dom =3D is_hardware_domain(d);
> >
> >         if ( !IS_ENABLED(CONFIG_HAS_HWDOM_SUSPEND) )
> >             return is_hw_dom && d->shutdown_code !=3D SHUTDOWN_suspend;
> >
> >         return is_hw_dom;
> >     }
>
> Maybe. Yet then the next thing striking me as odd is the redundant
> checking of is_hw_dom. Why not simply
>
> {
>     if ( !is_hardware_domain(d) )
>         return false;
>
>     return IS_ENABLED(CONFIG_HAS_HWDOM_SUSPEND) || d->shutdown_code !=3D =
SHUTDOWN_suspend;
> }
>
> Yet as said - my expectation is anyway that the is_hardware_domain() chec=
k
> would live in the caller.

Ack.

>
> > As for the second argument (reason), I can extract it directly from the
> > domain structure, as is done in the function above.
>
> Looks like a misunderstanding: I don't mind the function parameter. But
> the "u8" type shouldn't be used anymore in new code; that's uint8_t now.

Oh, got it.
I just used the same type as in domain_shutdown().

>
> >> Furthermore with continuing to (ab)use domain_shutdown() also for the
> >> suspend case (Dom0 isn't really shut down when suspending, aiui), you
> >> retain the widening of the issue with the bogus setting of
> >> d->is_shutting_down (and hence the need for later clearing the flag
> >> again) that I mentioned elsewhere. (Yes, I remain of the opinion that
> >> you don't need to sort that as a prereq to your work, yet at the same
> >> time I think the goal should be to at least not make a bad situation
> >> worse.)
> >
> > From the perspective of ARM logic inside Xen, we perform the exact same
> > shutdown steps as for other domains, except that in the end we need to
> > call Xen suspend.
>
> Which, as said, feels wrong. Domains to be revived after resume aren't
> really shut down, so imo they should never have ->is_shutting_down set.

I believe this is out of scope for this series;
actually, the same applies to shutdown_code.

>
> > For a domain with a toolstack, it is possible to have a running Xen
> > watchdog service. For example, if we have systemd, it can be easily sto=
pped
> > from the guest because we have hooks and can perform some actions befor=
e
> > suspend.
> >
> > The same story applies to a Linux kernel driver: if it has PM ops insta=
lled
> > for the Xen watchdog driver, nothing bad happens.
> >
> > However, in the case of using init.d, it isn=E2=80=99t easy to stop the=
 Xen WDT
> > automatically right before suspend. Therefore, Xen code has an extra ch=
eck
> > (see domain_watchdog_timeout) where it checks the is_shutting_down flag
> > and does nothing if it is set.
>
> I don't understand how these watchdog considerations come into play here.

I=E2=80=99m just trying to explain why we still need to set this flag
even for HW domain.

>
> > The is_shutting_down flag is easily reset on Xen resume via a
> > domain_resume call, so I don=E2=80=99t see any problems with that.
>
> You did read my earlier mail though, regarding concerns towards the clear=
ing
> of that flag once it was set? (You must have, since iirc you even asked [=
1]
> whether you're expected to address those issues up front.)

As far as I understand, this issue is relevant to x86, and I believe
it is out of scope for this series.

See my previous message here:
https://lists.xen.org/archives/html/xen-devel/2025-08/msg02127.html

I will prepare a separate patch series to address it.

>
> Jan
>
> [1] https://lists.xen.org/archives/html/xen-devel/2025-08/msg02057.html

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 09:57:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 09:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116105.1462512 (Exim 4.92)
	(envelope-from )
	id 1uvv5w-0006Gl-Rl; Tue, 09 Sep 2025 09:57:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116105.1462512; Tue, 09 Sep 2025 09:57:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvv5w-0006Ge-Nl; Tue, 09 Sep 2025 09:57:00 +0000
Received: by outflank-mailman (input) for mailman id 1116105;
 Tue, 09 Sep 2025 09:56:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvv5v-0006GY-HC
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 09:56:59 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 523225e5-8d63-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 11:56:58 +0200 (CEST)
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
 [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-42-o90Z3dI_OpWxzfEadYHFyw-1; Tue, 09 Sep 2025 05:56:53 -0400
Received: by mail-wm1-f72.google.com with SMTP id
 5b1f17b1804b1-45b96c2f4ccso32051005e9.0
 for ; Tue, 09 Sep 2025 02:56:53 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45df16b2971sm5934435e9.7.2025.09.09.02.56.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 02:56: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: 523225e5-8d63-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757411816;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=v9v9HEY+peb6y/djARujyPjanSQs6bY1lozPYtVGaPg=;
	b=Tzu7DdkvQzs7M1WEFk9+yZ2wOjVaifo7TX98jxaeX/rSaERnI2FL3cQ/eEyudYaLMHNbo4
	zp06tZLvLJEYPrqheo7YjReLalxFlvyPABOUVR310KyBUFZH+rgTLO+ROhjD7p0uWyJ9VA
	aFZyY6Hy5lOSV+WbwReHvZRAKJRQBpU=
X-MC-Unique: o90Z3dI_OpWxzfEadYHFyw-1
X-Mimecast-MFC-AGG-ID: o90Z3dI_OpWxzfEadYHFyw_1757411812
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757411812; x=1758016612;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=v9v9HEY+peb6y/djARujyPjanSQs6bY1lozPYtVGaPg=;
        b=N/uC8UCdod014vMb9xgH7O7VzPF3akgXSRA3xLAZ3rc2wC3qrmni/7JsagRLfyLnrA
         GR1QZUJs20fNYdYt0QwjzG8Q7eZo3P2GwXWD2lbP6wk++TQir9qNA8ytRcMb+KOCv5XR
         /oYQxxrlK5+6PlEgHsgkZpxTQUxoUZ8GGYCWYR9Qd/yzmdpmuR8fMzp/ryZIe0Bm2ZiT
         fvQhoztCd2SEGHSojAVKGsDK1oeSu/UTzz6uw+1sj/2IQ8dxkSjMd7ueBqXlERJ9ryle
         POmivZhkPMMPDiKK9Bs8EBheTc0O0LwcGKd8YPOaNHVg2hSn/Fn1eMjkL8ROmV3+PRom
         oMug==
X-Forwarded-Encrypted: i=1; AJvYcCVE+RVRJcMZayEDf1It2nVqT70MJOwnerfUbVFVlRpWKKuOECvR5Na06m4c8DIGZY8Y0KlAhVjivqQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwkUzyIZHepx4D9LdyIUrF0PqJz8oqH4dbg9ZxwKOZSYnfY9XFF
	phiiQf7ypxVQ/WNkAYolQlafqfv143UE1Ul1WkOj8u7/kN2V1zt5E9ILNLw2G4PT+aFjvkoJkB4
	bmXxby3iQvti/AhXBlKZ3KF5q11BCQcJCI9iI9SWm9htLiqyXlEXDIOmPngW982vcqcnI
X-Gm-Gg: ASbGnctR3w/K4OilNbJN4lZdTV3QGsI3YRj4mjE91blH46DL/Mo0IQ7jETFOdCeZJ9J
	J5/g1rp1pre1SSPnBrqaRL43rWDOs5+cI3gsu9JUDcnHbTa8QMFQZIYQI8f/QfhhzrzM1boDQJA
	4BhD6DVFVqy/3784eAj5HYuTmQrdvzl7yoJBDlzl5pH4wVPon24Vw4z/sz7Bx2Q7Jj7alL8M1Ok
	ELDUmd3X5pEAphv+lvWB4FTyfOiMP8kUOL6X+RJaHCMBTtLSSmqNLj1UVU3stS03F1i8BUd+3nQ
	GA5Q/Sx9UZNeC2ojf9fkgFKvxjtzMiNc4Wl9niIHzIkCmoiz7BUbkmIrQziNMah4lZBBJJDUfHm
	GnUi51re7nORhWf+28+cMnDnX8N9UuGojFUIy1epgHGqibrtxSnU4i3Jk9N5P4eixzwE=
X-Received: by 2002:a05:600c:3b83:b0:450:6b55:cf91 with SMTP id 5b1f17b1804b1-45de3c20088mr82989955e9.6.1757411811940;
        Tue, 09 Sep 2025 02:56:51 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHxA/lg+jOMLOS5VKnviegUlnV1FAVtarDrgFAYvQcjN5JtjPJvVcivfNI/KeNLfzLwRHX8LA==
X-Received: by 2002:a05:600c:3b83:b0:450:6b55:cf91 with SMTP id 5b1f17b1804b1-45de3c20088mr82989315e9.6.1757411811384;
        Tue, 09 Sep 2025 02:56:51 -0700 (PDT)
Message-ID: <57f49b72-2126-48f0-a4ef-4b138bd0bead@redhat.com>
Date: Tue, 9 Sep 2025 11:56:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.com>
 
 <360712fa-f7a0-4674-acc4-76f79141fe4f@suse.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <360712fa-f7a0-4674-acc4-76f79141fe4f@suse.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: yQhwREWW_c3o_KuNxbl9WhqiXQ11EO85Hwpv6RtB-N0_1757411812
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 09.09.25 11:37, Jürgen Groß wrote:
> On 09.09.25 11:13, David Hildenbrand wrote:
>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>> Commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode")
>>> originally introduced support for nested lazy sections (LAZY_MMU and
>>> LAZY_CPU). It later got reverted by commit c36549ff8d84 as its
>>> implementation turned out to be intolerant to preemption.
>>>
>>> Now that the lazy_mmu API allows enter() to pass through a state to
>>> the matching leave() call, we can support nesting again for the
>>> LAZY_MMU mode in a preemption-safe manner. If xen_enter_lazy_mmu() is
>>> called inside an active lazy_mmu section, xen_lazy_mode will already
>>> be set to XEN_LAZY_MMU and we can then return LAZY_MMU_NESTED to
>>> instruct the matching xen_leave_lazy_mmu() call to leave
>>> xen_lazy_mode unchanged.
>>>
>>> The only effect of this patch is to ensure that xen_lazy_mode
>>> remains set to XEN_LAZY_MMU until the outermost lazy_mmu section
>>> ends. xen_leave_lazy_mmu() still calls xen_mc_flush()
>>> unconditionally.
>>>
>>> Signed-off-by: Kevin Brodsky 
>>> ---
>>>    arch/x86/include/asm/paravirt.h       |  6 ++----
>>>    arch/x86/include/asm/paravirt_types.h |  4 ++--
>>>    arch/x86/xen/mmu_pv.c                 | 11 ++++++++---
>>>    3 files changed, 12 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
>>> index 65a0d394fba1..4ecd3a6b1dea 100644
>>> --- a/arch/x86/include/asm/paravirt.h
>>> +++ b/arch/x86/include/asm/paravirt.h
>>> @@ -529,14 +529,12 @@ static inline void arch_end_context_switch(struct
>>> task_struct *next)
>>>    #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>>>    static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>>>    {
>>> -    PVOP_VCALL0(mmu.lazy_mode.enter);
>>> -
>>> -    return LAZY_MMU_DEFAULT;
>>> +    return PVOP_CALL0(lazy_mmu_state_t, mmu.lazy_mode.enter);
>>>    }
>>>    static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>>>    {
>>> -    PVOP_VCALL0(mmu.lazy_mode.leave);
>>> +    PVOP_VCALL1(mmu.lazy_mode.leave, state);
>>>    }
>>>    static inline void arch_flush_lazy_mmu_mode(void)
>>> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/
>>> paravirt_types.h
>>> index bc1af86868a3..b7c567ccbf32 100644
>>> --- a/arch/x86/include/asm/paravirt_types.h
>>> +++ b/arch/x86/include/asm/paravirt_types.h
>>> @@ -45,8 +45,8 @@ typedef int lazy_mmu_state_t;
>>>    struct pv_lazy_ops {
>>>        /* Set deferred update mode, used for batching operations. */
>>> -    void (*enter)(void);
>>> -    void (*leave)(void);
>>> +    lazy_mmu_state_t (*enter)(void);
>>> +    void (*leave)(lazy_mmu_state_t);
>>>        void (*flush)(void);
>>>    } __no_randomize_layout;
>>>    #endif
>>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>>> index 2039d5132ca3..6e5390ff06a5 100644
>>> --- a/arch/x86/xen/mmu_pv.c
>>> +++ b/arch/x86/xen/mmu_pv.c
>>> @@ -2130,9 +2130,13 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t
>>> phys, pgprot_t prot)
>>>    #endif
>>>    }
>>> -static void xen_enter_lazy_mmu(void)
>>> +static lazy_mmu_state_t xen_enter_lazy_mmu(void)
>>>    {
>>> +    if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
>>> +        return LAZY_MMU_NESTED;
>>> +
>>
>> You mention above "preemption-safe manner" above, so I am wondering,
>> what if we get preempted immediately after doing the this_cpu_read() and get
>> scheduled on another CPU?
>>
> 
> This should still be correct: preemption needs a context switch to happen,
> so xen_start_context_switch() and xen_end_context_switch() are involved.
> Those are dealing with this problem by doing the right thing in the old
> and the new context.

Thanks, that makes sense. Would be valuable to add that detail to the 
patch description.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:05:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:05:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116118.1462522 (Exim 4.92)
	(envelope-from )
	id 1uvvEV-0008PV-LV; Tue, 09 Sep 2025 10:05:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116118.1462522; Tue, 09 Sep 2025 10: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 1uvvEV-0008PO-II; Tue, 09 Sep 2025 10:05:51 +0000
Received: by outflank-mailman (input) for mailman id 1116118;
 Tue, 09 Sep 2025 10:05: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 1uvvEU-0008PI-5H
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:05:50 +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 8c0381c6-8d64-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:05:43 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b0472bd218bso830162866b.1
 for ; Tue, 09 Sep 2025 03:05: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-b0432937e0esm2083736266b.3.2025.09.09.03.05.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 03: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: 8c0381c6-8d64-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757412343; x=1758017143; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Z/XrMut+D9Cnm8FPw8vJFLH7cwvrmfge3Zwb3BCxQQQ=;
        b=MW/tSMvnuBqX4V3h18tWEvPiQTpCta0gnc80oTg+LfNRDwJ/aD7u47EWFhqKnooq92
         SokHCFS47mSiXvmNZA7yCrMm3qXF0Nuq5FPOjYmlP1wm+XWLyQmU9W7OFLFJAXHzZ/4F
         ho5UIHHGopuPfLNtHb23qsRDFWNbY5NAyllnLMiZ5JwAeUooEBzoIx1aLd9GcPVCwvid
         q8Igh5MV3WF1KiKuzJlc5qCW/v77ykDtcyGiXSwG553gYG9i5B/ZUBlIVBp+WNuy36pj
         el/avODtEdSDTD0VJTPoeKVW7pe5YxA+ho6T6d07BU7xV2gBSr2Wmemj74k/f8vakub5
         p2TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757412343; x=1758017143;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Z/XrMut+D9Cnm8FPw8vJFLH7cwvrmfge3Zwb3BCxQQQ=;
        b=YZZ3RzvKFdMgH9KtttX60a9grXwgog5aNE+mcq9EmMlNPXsIQHyDcLGsjUcWae9wF3
         Ce0uOlBeGeU+M/w2ykWFHyhfz7iYqINj69HzAN7BhzJiKfJ5pdb/96Iphh3tCICeqxE0
         hxqcEcLBLCYmaIBOwLEpz3xmzoE22mYPKqD8OQgs6/Hvg/ZX5ErNdc6hTeQoJ3q+Bgoj
         58Lx+LG4tHNsYp8SLtU1wefQNSxGRnFukqgtDQlmOK3wVPq3miANa9qOX6vfOJIdCGFN
         oGLbceA9aC+AbzOp4MlZZDgyOfFzuQq71wXC+EemiXpQExVe8stJBYujTlfPGaDHQzRl
         P+Sg==
X-Forwarded-Encrypted: i=1; AJvYcCUYHE0W3zmtr8r8XYwDZAFDLdYzXakrBA14l+SdP5XxkNWjLa2a1bYkBPabK0+/Q7MP35nQv5DCeaA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJvp+ef6nEiBNUMVzi7PMrq0fgHjsDnmjkL+mAclYmCPqD9R1a
	w5AuTfI0mK5NX4rq1Xcz4rWFfqSfa6RsfSJO6VIb/S113amwTIAyNw24zPvHzEIXeK/XAOvGatR
	hfMs=
X-Gm-Gg: ASbGncuABwyRQ5zuvdBRw0jO6d+DlRPxdcjNL8sZqQWMtQuPi1NAp/gLo6qzQS29nyr
	83/XrrIlp+3tHW/qhqNNIE0weAsYA1PQzHA95zXPRIkdSVXkorNQXD1J17XRYyVUtSNEmmPQuWH
	QE5SSMqRb6aGNe2N89PotuaQe1w/L5xzQKF4kPoPN5Wx6MCHIVNw4hYfpuUOXOsynYJe7fM2/8t
	RxnKzq6c0IoYEugjo6/XLnTOBDooZMZ4cXmJaBr+pPyjfgxPMLf1R9xw1S3Px/jB77W1zsTPGTj
	MPmTb/Pqwj/EYxDvZk3HdvZztpTGdUo5d4PpNA407bNYg0JYMWHTzuse+j/XFA63mPDpsXjESZQ
	WrTSuE+9W3x6bJbtIyPpc8TgqVIoMbEnPA+KPK0TxXgvoKc5g1+d5b1sHlxgtUWbfXvoRzu+9Tx
	a6ZpPWV5L+fwz6r+cP2Q==
X-Google-Smtp-Source: AGHT+IE8Z8B1/P6kZmUQ5rgQHyA0SCZQ8fmLRLC9cnkVDCx1q1e9H8NkRKepTEdhpHGDqV1am71PWQ==
X-Received: by 2002:a17:907:9955:b0:b07:6537:264c with SMTP id a640c23a62f3a-b076537276cmr242371966b.37.1757412342768;
        Tue, 09 Sep 2025 03:05:42 -0700 (PDT)
Message-ID: <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>
Date: Tue, 9 Sep 2025 12:05:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 02/16] xen/8250-uart: update definitions
To: dmukhin@xen.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, xen-devel@lists.xenproject.org
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-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: <20250908211149.279143-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.09.2025 23:11, dmukhin@xen.org wrote:
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,6 +32,7 @@
>  #define UART_MCR          0x04    /* Modem control        */
>  #define UART_LSR          0x05    /* line status          */
>  #define UART_MSR          0x06    /* Modem status         */
> +#define UART_SCR          0x07    /* Scratch pad          */
>  #define UART_USR          0x1f    /* Status register (DW) */
>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
> @@ -42,6 +43,8 @@
>  #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
>  #define UART_IER_ELSI     0x04    /* rx line status       */
>  #define UART_IER_EMSI     0x08    /* MODEM status         */
> +#define UART_IER_MASK \
> +    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)

Here, aiui, ..._MASK covers all known bits. No #define-s for reserved
ones.

> @@ -51,12 +54,19 @@
>  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
>  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
>  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> +#define UART_IIR_FE       0xc0    /* FIFO enabled (2 bits) */
>  
>  /* FIFO Control Register */
>  #define UART_FCR_ENABLE   0x01    /* enable FIFO          */
>  #define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
>  #define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> +#define UART_FCR_DMA      0x08    /* enter DMA mode       */

Question is whether we can actually use the source you indicate as
reference. TL16C550C may already be too different from what a "standard"
16550 is (where admittedly it also looks unclear what "standard" would be,
as I'm unaware of a "canonical" spec).

The source I'm looking at says something entirely different. Maybe we're
better off simply omitting this #define?

> +#define UART_FCR_RSRVD0   0x10    /* reserved; always 0   */
> +#define UART_FCR_RSRVD1   0x20    /* reserved; always 0   */
> +#define UART_FCR_RTB0     0x40    /* receiver trigger bit #0 */
> +#define UART_FCR_RTB1     0x80    /* receiver trigger bit #1 */
> +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)

Continuing from the top comment - here, with the TRG infix, the scope is
clear, too.

> @@ -98,9 +108,30 @@
>  /* Modem Control Register */
>  #define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
>  #define UART_MCR_RTS      0x02    /* Request to Send      */
> -#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
> +#define UART_MCR_OUT1     0x04    /* Output #1 */
> +#define UART_MCR_OUT2     0x08    /* Output #2 */
>  #define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
> +#define UART_MCR_RSRVD0   0x20    /* Reserved #0 */
>  #define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
> +#define UART_MCR_RSRVD1   0x80    /* Reserved #1 */
> +#define UART_MCR_MASK \
> +    (UART_MCR_DTR | UART_MCR_RTS | \
> +     UART_MCR_OUT1 | UART_MCR_OUT2 | \
> +     UART_MCR_LOOP | UART_MCR_TCRTLR)

Here it's again all non-reserved bits. Yet why do we need #define-s for
the two reserved ones here? (Same question for FCR, even if there's no
UART_FCR_MASK.)

> +/* Modem Status Register */
> +#define UART_MSR_DCTS     0x01    /* Change in CTS */
> +#define UART_MSR_DDSR     0x02    /* Change in DSR */
> +#define UART_MSR_TERI     0x04    /* Change in RI */
> +#define UART_MSR_DDCD     0x08    /* Change in DCD */
> +#define UART_MSR_CTS      0x10
> +#define UART_MSR_DSR      0x20
> +#define UART_MSR_RI       0x40
> +#define UART_MSR_DCD      0x80
> +#define UART_MSR_CHANGE \
> +    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
> +#define UART_MSR_STATUS \
> +    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)

Here it's properly two subsets.

> @@ -111,6 +142,7 @@
>  #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
>  #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
>  #define UART_LSR_ERR      0x80    /* Error                */
> +#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)

But what's the deal here? Why would only two of the bits be covered?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:08:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:08:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116129.1462532 (Exim 4.92)
	(envelope-from )
	id 1uvvH8-0000yT-2J; Tue, 09 Sep 2025 10:08:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116129.1462532; Tue, 09 Sep 2025 10: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 1uvvH7-0000yM-VU; Tue, 09 Sep 2025 10:08:33 +0000
Received: by outflank-mailman (input) for mailman id 1116129;
 Tue, 09 Sep 2025 10:08: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 1uvvH6-0000yD-KW
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:08:32 +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 efa2f1c6-8d64-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:08:30 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3c6abcfd142so2672928f8f.2
 for ; Tue, 09 Sep 2025 03:08:30 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45b9bcda91dsm317709275e9.6.2025.09.09.03.08.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 03:08: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: efa2f1c6-8d64-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757412510; x=1758017310; 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=DiDplQj9hx3PvXah5112bj2kShJJIkIE7dUW74ox+yg=;
        b=JcDvh2KQB5WFOadc0t4uZNCWVYya4R8+pvaJHq/tBCp7d05Tns2gX966h3pnSVsGzm
         kSFS3kM/K7jijj490DDTP7zweR84ZCyDwdGL28HNP2gG0ajkFTBAPt5k42npnWurRLbs
         +E0G4g1NyenCO/9RCiK6DJGanKH9vmnjk+Kw3B/FvLULmNQepeS9rCn/6K9aETFHpG6S
         Yvu70LfOe1zQUFvdf+fnXRTStqteL6A7G5/FH+GnIFU1OclxkGbhq3DGQz5JGu2ro2dw
         FQgmsCtziBZ2Du4H+nKRVST+LQZmjpUWKHa1uQss78+/ItM+Rv3Th6T8r/3A0hr3PMlH
         mpfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757412510; x=1758017310;
        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=DiDplQj9hx3PvXah5112bj2kShJJIkIE7dUW74ox+yg=;
        b=gCntyGGImkyWqqxc+X7dNOZPz8Ta0KLNAeTMux7RZGtb1RwCpHrsUkv4IcIblduI6c
         lKVn8iz4zqER3je0ryXU5+qQgsqT9kfN9qLqw47P+aI8kSQjmlioq9bfVLUeLFCwm2vR
         GkuU8vlBwL9eLJf7RLeP2siI76X3szRBlxMzq+vURXS75oZfHfJ8j67m056XH76+pm+E
         TyITCXsXR2YZhz2NpkGTtyVkJhjapoSnI9JoDkGTw5zWoiMe73rUhzN2KsP9emxjlnd7
         9blyhUQPYWYNMUT/dOzxaYahThLGpN9VT85mEkRWQGgaVUeY2MP1OUwa2Cfx11qLOGp3
         a1jg==
X-Forwarded-Encrypted: i=1; AJvYcCWAGPuMEdHFLW4MmQbtbGO4kDm1f68IBb0udOcQxjtGB4vM3A3lpZ6RIUXD6iqv55msHXGoPOfxs7c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNBkE3xGhf2t+bn0SPCKTSv9GcZhzfVZ1U9iCdr6nMoFdDk7Z3
	uVI41H7wRqqRKOIqcsS43C3tsDOK550iFvcgIWeoKBVnt5PevYM0znmAow1AGLojQJc=
X-Gm-Gg: ASbGnct5iUum8QfJIQJb+JAOAq0/slx0FGZSBshYAwbhe8i8XQPZxLCTniHiNe0BSWt
	H7Os+0X6/1P0ecq2qQJlWW82NxO3rm8P7ffXZZRq1Oq4Q31VcXnvJTmiEWm9EL/Ox/H4uekDq75
	INHnFrKg94oaTyTlYWkwWwUry8dw1/jiBdiZmsRSwCcX5guJsZ96kNPlEzdIDaLO1zUdhBYyxaI
	ECC+ze38ThseKwryRtOjAOkI2Sd/wuqt85wxpHiPn9mtTrtdB5PPbvkANZ6UX+lzc9S1yxD1Tht
	+e5lsMlk4WFRjETZcVhNiFQXoUyYbOpyXnZnCL09RHnpi0bDJhjwEOSuDKq3XTwcHcaacXT2Tnq
	Rcw5t1cWphAhRzeMP6etbztP7+VXFL5e6nBOw5006ugDVkQRUXqHFeVN4EkdLSX53UR9pf0Ej4O
	Vcck4MVGXXmbx4zBRC4x6tlqE66iScCn2w6c5RL+vUKiS2NiP6g1hEZfs=
X-Google-Smtp-Source: AGHT+IEbIOzIcWCGsxFeJqTqswoKzFZU8h5ca9ioFsTGk0plA7q521H22LxnzLsjlklRQdzf2ZNlhQ==
X-Received: by 2002:a05:6000:2385:b0:3e4:64b0:a787 with SMTP id ffacd0b85a97d-3e64392d4b3mr7866480f8f.33.1757412509825;
        Tue, 09 Sep 2025 03:08:29 -0700 (PDT)
Message-ID: <5b42a1bf-d46f-42e1-90ef-f20d698828f5@suse.com>
Date: Tue, 9 Sep 2025 12:08:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.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: <20250908073931.4159362-3-kevin.brodsky@arm.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------dpEbV9t2uYfrqqebO0e2knsF"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------dpEbV9t2uYfrqqebO0e2knsF
Content-Type: multipart/mixed; boundary="------------5pXmA0RBOYXCBdtoZQDsU4Hn";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 David Hildenbrand , "David S. Miller"
 , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Message-ID: <5b42a1bf-d46f-42e1-90ef-f20d698828f5@suse.com>
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
In-Reply-To: <20250908073931.4159362-3-kevin.brodsky@arm.com>

--------------5pXmA0RBOYXCBdtoZQDsU4Hn
Content-Type: multipart/mixed; boundary="------------l0nheg3mWWAbvEJzY7GAPskH"

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

T24gMDguMDkuMjUgMDk6MzksIEtldmluIEJyb2Rza3kgd3JvdGU6DQo+IGFyY2hfe2VudGVy
LGxlYXZlfV9sYXp5X21tdV9tb2RlKCkgY3VycmVudGx5IGhhdmUgYSBzdGF0ZWxlc3MgQVBJ
DQo+ICh0YWtpbmcgYW5kIHJldHVybmluZyBubyB2YWx1ZSkuIFRoaXMgaXMgcHJvdmluZyBw
cm9ibGVtYXRpYyBpbg0KPiBzaXR1YXRpb25zIHdoZXJlIGxlYXZlKCkgbmVlZHMgdG8gcmVz
dG9yZSBzb21lIGNvbnRleHQgYmFjayB0byBpdHMNCj4gb3JpZ2luYWwgc3RhdGUgKGJlZm9y
ZSBlbnRlcigpIHdhcyBjYWxsZWQpLiBJbiBwYXJ0aWN1bGFyLCB0aGlzDQo+IG1ha2VzIGl0
IGRpZmZpY3VsdCB0byBzdXBwb3J0IHRoZSBuZXN0aW5nIG9mIGxhenlfbW11IHNlY3Rpb25z
IC0NCj4gbGVhdmUoKSBkb2VzIG5vdCBrbm93IHdoZXRoZXIgdGhlIG1hdGNoaW5nIGVudGVy
KCkgY2FsbCBvY2N1cnJlZA0KPiB3aGlsZSBsYXp5X21tdSB3YXMgYWxyZWFkeSBlbmFibGVk
LCBhbmQgd2hldGhlciB0byBkaXNhYmxlIGl0IG9yDQo+IG5vdC4NCj4gDQo+IFRoaXMgcGF0
Y2ggZ2l2ZXMgYWxsIGFyY2hpdGVjdHVyZXMgdGhlIGNoYW5jZSB0byBzdG9yZSBsb2NhbCBz
dGF0ZQ0KPiB3aGlsZSBpbnNpZGUgYSBsYXp5X21tdSBzZWN0aW9uIGJ5IG1ha2luZyBlbnRl
cigpIHJldHVybiBzb21lIHZhbHVlLA0KPiBzdG9yaW5nIGl0IGluIGEgbG9jYWwgdmFyaWFi
bGUsIGFuZCBoYXZpbmcgbGVhdmUoKSB0YWtlIHRoYXQgdmFsdWUuDQo+IFRoYXQgdmFsdWUg
aXMgdHlwZWQgbGF6eV9tbXVfc3RhdGVfdCAtIGVhY2ggYXJjaGl0ZWN0dXJlIGRlZmluaW5n
DQo+IF9fSEFWRV9BUkNIX0VOVEVSX0xBWllfTU1VX01PREUgaXMgZnJlZSB0byBkZWZpbmUg
aXQgYXMgaXQgc2VlcyBmaXQuDQo+IEZvciBub3cgd2UgZGVmaW5lIGl0IGFzIGludCBldmVy
eXdoZXJlLCB3aGljaCBpcyBzdWZmaWNpZW50IHRvDQo+IHN1cHBvcnQgbmVzdGluZy4NCj4g
DQo+IFRoZSBkaWZmIGlzIHVuZm9ydHVuYXRlbHkgcmF0aGVyIGxhcmdlIGFzIGFsbCB0aGUg
QVBJIGNoYW5nZXMgbmVlZA0KPiB0byBiZSBkb25lIGF0b21pY2FsbHkuIE1haW4gcGFydHM6
DQo+IA0KPiAqIENoYW5naW5nIHRoZSBwcm90b3R5cGVzIG9mIGFyY2hfe2VudGVyLGxlYXZl
fV9sYXp5X21tdV9tb2RlKCkNCj4gICAgaW4gZ2VuZXJpYyBhbmQgYXJjaCBjb2RlLCBhbmQg
aW50cm9kdWNpbmcgbGF6eV9tbXVfc3RhdGVfdC4NCj4gDQo+ICogSW50cm9kdWNpbmcgTEFa
WV9NTVVfe0RFRkFVTFQsTkVTVEVEfSBmb3IgZnV0dXJlIHN1cHBvcnQgb2YNCj4gICAgbmVz
dGluZy4gZW50ZXIoKSBhbHdheXMgcmV0dXJucyBMQVpZX01NVV9ERUZBVUxUIGZvciBub3cu
DQo+ICAgIChsaW51eC9tbV90eXBlcy5oIGlzIG5vdCB0aGUgbW9zdCBuYXR1cmFsIGxvY2F0
aW9uIGZvciBkZWZpbmluZw0KPiAgICB0aG9zZSBjb25zdGFudHMsIGJ1dCB0aGVyZSBpcyBu
byBvdGhlciBvYnZpb3VzIGhlYWRlciB0aGF0IGlzDQo+ICAgIGFjY2Vzc2libGUgd2hlcmUg
YXJjaCdzIGltcGxlbWVudCB0aGUgaGVscGVycy4pDQo+IA0KPiAqIENoYW5naW5nIGFsbCBs
YXp5X21tdSBzZWN0aW9ucyB0byBpbnRyb2R1Y2UgYSBsYXp5X21tdV9zdGF0ZQ0KPiAgICBs
b2NhbCB2YXJpYWJsZSwgaGF2aW5nIGVudGVyKCkgc2V0IGl0IGFuZCBsZWF2ZSgpIHRha2Ug
aXQuIE1vc3Qgb2YNCj4gICAgdGhlc2UgY2hhbmdlcyB3ZXJlIGdlbmVyYXRlZCB1c2luZyB0
aGUgZm9sbG93aW5nIENvY2NpbmVsbGUgc2NyaXB0Og0KPiANCj4gQEANCj4gQEANCj4gew0K
PiArIGxhenlfbW11X3N0YXRlX3QgbGF6eV9tbXVfc3RhdGU7DQo+IC4uLg0KPiAtIGFyY2hf
ZW50ZXJfbGF6eV9tbXVfbW9kZSgpOw0KPiArIGxhenlfbW11X3N0YXRlID0gYXJjaF9lbnRl
cl9sYXp5X21tdV9tb2RlKCk7DQo+IC4uLg0KPiAtIGFyY2hfbGVhdmVfbGF6eV9tbXVfbW9k
ZSgpOw0KPiArIGFyY2hfbGVhdmVfbGF6eV9tbXVfbW9kZShsYXp5X21tdV9zdGF0ZSk7DQo+
IC4uLg0KPiB9DQo+IA0KPiAqIEluIGEgZmV3IGNhc2VzIChlLmcuIHhlbl9mbHVzaF9sYXp5
X21tdSgpKSwgYSBmdW5jdGlvbiBrbm93cyB0aGF0DQo+ICAgIGxhenlfbW11IGlzIGFscmVh
ZHkgZW5hYmxlZCwgYW5kIGl0IHRlbXBvcmFyaWx5IGRpc2FibGVzIGl0IGJ5DQo+ICAgIGNh
bGxpbmcgbGVhdmUoKSBhbmQgdGhlbiBlbnRlcigpIGFnYWluLiBIZXJlIHdlIHdhbnQgdG8g
ZW5zdXJlDQo+ICAgIHRoYXQgYW55IG9wZXJhdGlvbiBiZXR3ZWVuIHRoZSBsZWF2ZSgpIGFu
ZCBlbnRlcigpIGNhbGxzIGlzDQo+ICAgIGNvbXBsZXRlZCBpbW1lZGlhdGVseTsgZm9yIHRo
YXQgcmVhc29uIHdlIHBhc3MgTEFaWV9NTVVfREVGQVVMVCB0bw0KPiAgICBsZWF2ZSgpIHRv
IGZ1bGx5IGRpc2FibGUgbGF6eV9tbXUuIGVudGVyKCkgd2lsbCB0aGVuIHJlLWVuYWJsZSBp
dA0KPiAgICAtIHRoaXMgYWNoaWV2ZXMgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciwgd2hldGhl
ciBuZXN0aW5nIG9jY3VycmVkDQo+ICAgIGJlZm9yZSB0aGF0IGZ1bmN0aW9uIHdhcyBjYWxs
ZWQgb3Igbm90Lg0KPiANCj4gTm90ZTogaXQgaXMgZGlmZmljdWx0IHRvIHByb3ZpZGUgYSBk
ZWZhdWx0IGRlZmluaXRpb24gb2YNCj4gbGF6eV9tbXVfc3RhdGVfdCBmb3IgYXJjaGl0ZWN0
dXJlcyBpbXBsZW1lbnRpbmcgbGF6eV9tbXUsIGJlY2F1c2UNCj4gdGhhdCBkZWZpbml0aW9u
IHdvdWxkIG5lZWQgdG8gYmUgYXZhaWxhYmxlIGluDQo+IGFyY2gveDg2L2luY2x1ZGUvYXNt
L3BhcmF2aXJ0X3R5cGVzLmggYW5kIGFkZGluZyBhIG5ldyBnZW5lcmljDQo+ICAgI2luY2x1
ZGUgdGhlcmUgaXMgdmVyeSB0cmlja3kgZHVlIHRvIHRoZSBleGlzdGluZyBoZWFkZXIgc291
cC4NCj4gDQo+IEFja2VkLWJ5OiBNaWtlIFJhcG9wb3J0IChNaWNyb3NvZnQpIDxycHB0QGtl
cm5lbC5vcmc+DQo+IFNpZ25lZC1vZmYtYnk6IEtldmluIEJyb2Rza3kgPGtldmluLmJyb2Rz
a3lAYXJtLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNl
LmNvbT4gIyBhcmNoL3g4Ng0KDQoNCkp1ZXJnZW4NCg==
--------------l0nheg3mWWAbvEJzY7GAPskH
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-----

--------------l0nheg3mWWAbvEJzY7GAPskH--

--------------5pXmA0RBOYXCBdtoZQDsU4Hn--

--------------dpEbV9t2uYfrqqebO0e2knsF
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/Ey8FAmi//JsFAwAAAAAACgkQsN6d1ii/Ey/C
1wf/cnsOcbouTosXpOkMhBjr243f1nECaiPmx1oWx83zmSC4SlVt0VJFI2hpjqlZZn3kk+T+f/BY
riH1vti+7aji2EwTeUjuL+sruFDv5+lCOefk6+b46OZl2eNVp8VbrcgJzJ6kv6KhdqWIaK9xQg5E
y78GsOvALgfkC9dMGlo3V0JpBT/NhIqVX0CkLTytEiz6z4/WyGI49id3c1cDHnLo4umVXEElO7Rb
LFId0sWhskdjaRvSWuUHTzL9F8u0j0NAwfiI4CZUIhTmeuOnhk9p6MM3dso8MBODi0QhzlxCbFUn
PT0KWq6tyl6iW7RcH025OPh/I+hvKsP+LkQeTxcTXA==
=nAef
-----END PGP SIGNATURE-----

--------------dpEbV9t2uYfrqqebO0e2knsF--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:09:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:09:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116136.1462542 (Exim 4.92)
	(envelope-from )
	id 1uvvHd-0001QV-DK; Tue, 09 Sep 2025 10:09:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116136.1462542; Tue, 09 Sep 2025 10:09: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 1uvvHd-0001QO-AU; Tue, 09 Sep 2025 10:09:05 +0000
Received: by outflank-mailman (input) for mailman id 1116136;
 Tue, 09 Sep 2025 10:09:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvvHb-0000yD-Mv
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:03 +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 0237b04d-8d65-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:09:02 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU2PR03MB7893.eurprd03.prod.outlook.com (2603:10a6:10:2d4::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:08:53 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:08: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: 0237b04d-8d65-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=omEUrg/XbaUHKpfYoPmbGElcyFtC5vq5indSLP+Pz+LaqnEVJlxfoR2g+wdOnEGBkAJmf/9OpsobNwJWCQc4obMwgg35bUtDptm1DFAnC++2kV7thGB4/lRd/G94I6pQTQhGWcLAmIwxKhed7u/bAZARxlxZ7GL9MTTA4J6JuY5qaiATxONuKiRHdSItePGvqie/auKgbHIfC70PzrjqoQdrElswPtanC5pLGrtCfKo/2cq5pVclrmZ6ui2VhScFBez4wLZjeMVwZ9n1PlauibRZWZgvUoCwI80HqReMOAqGT993VfXRExlVfnVu2+KGi/X33kWHRnOZeuqYZjlExg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i8WGyl1yidaLg3rKtLJxyTTs4lP5VzK1RvtJpl8LAn0=;
 b=WExsGLF5mFYXqZv18r6p8ZxM/u5KgntoMSsRnhttTNDl6Ge0XDgEH8cpF13/QcOZfU+SwQNLX5twTFf62pn9Yb8Rcrm3F7jbyocVIjTc3dT/7eSuluLAPfPfN6BZWcojKAODowzXKVV9l/lkFX47QfiNj3FuO5BODEso6XZA1ZkgIDsZul1W6Y8g4qcKQvnO6aCXkug9W+nuww2NIUGCPhDsOGg/kyEaK4/5cB33FRj/Rv8wuoYJs6p/pMHs0LuSic4X06+frlU9s9R9uv2TFaJbuASkNURZAy9szJjdwh3w2eGg/im6EtY2u22huz8zHEKQbhHMOhWx4PEKlRgGTw==
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=i8WGyl1yidaLg3rKtLJxyTTs4lP5VzK1RvtJpl8LAn0=;
 b=OAnX1miPs9wp0zODsYmePCp//O9dlMSz6pUPw0NQtrtf/kswt47Wvij3uyie+6Qrk9Qm7cETP3YZn5EOYXSJbx6ey41j2YMQ7EsMc2x0qbmi6NacsMt0fmDpMSslWRKkp/j7+Un4rVlbOGWw5IGtI+5sekhxzGLPPvHl//xOBwbUv4e9GTo/jjMffGGK8PaADiy8k13Si8kKQmnR5uXzLVCHiYHFHn6dyyCgjwmyzq246r1A082JYweP97YO4HE/ByIkdyZ93CdnnHkr59GBaAwKJti060KrAF4irextFrkOrMsLugdCK4W6ZdkND92kjcka2T2XZONvt9QtgZu9cA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Anthony PERARD ,
	Oleksii Kurochko , Community Manager
	
Subject: [PATCH v8 00/12] Introduce eSPI support
Thread-Topic: [PATCH v8 00/12] Introduce eSPI support
Thread-Index: AQHcIXG+403Qxbn1OkerAmJTri8mkg==
Date: Tue, 9 Sep 2025 10:08:52 +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: GV2PR03MB8678:EE_|DU2PR03MB7893:EE_
x-ms-office365-filtering-correlation-id: 19642122-27f1-442c-422a-08ddef88e100
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?kkp9X7WEhdK/eBSMEyhGnM3BIrfbCp4OxQx+4wPDelELh09q1YIWStKiTw?=
 =?iso-8859-1?Q?qvkKESYLPLNkt1kSOXkAhkPNJA2/Jribghjrt3/+1rRmQu8qcTeR2vCKOd?=
 =?iso-8859-1?Q?xglWSWAbikvCOmk9nUTSF5ferbrM+SjjMQHf7DSBjDeMvyeZR9G7ZmpE1Y?=
 =?iso-8859-1?Q?0p8xamBXi1iGhQ83FEFzo+ByE8egcx+MoUwNYYItRzbCR61y1FyX+QuuPf?=
 =?iso-8859-1?Q?hQHaCuB0MTNq9NWPuenK4ydtpBDpJ0hVkDR9v34nlRlmChUMQrIAwCEOvG?=
 =?iso-8859-1?Q?wXZ7XwlSaUh1ipHH2EXB9/Gk5TxfOChViOe35BNSPUjU0SiRhdseRnABeq?=
 =?iso-8859-1?Q?M1yrb3YnWFV5fAkxKmzaSTWBidpG3NcNY8KMfS9dkh4ViNuRIddUqMwuz8?=
 =?iso-8859-1?Q?wu2ZoTkEK5C4lJ8td8G2A9aZxxhYZtWCLJPZHprj+/3D39UkH9mAls1oB9?=
 =?iso-8859-1?Q?+V+YijlLZ+BEqgBAvEgrJJPhaD0PxndfjtDktdaH+F3fnTATKhDZVpNoqk?=
 =?iso-8859-1?Q?jXQsVivqNNlAxZYSHf9X9hXMHac6aL5diwY/7HUN4DzQGWPBA9YYtVYmDH?=
 =?iso-8859-1?Q?kQtzu0VtE0HGIDQWvVKzYt/Bz2Pl7nh26jjcX3Ncx8Cgw6X/41MHRQEhIC?=
 =?iso-8859-1?Q?dAA/tLQYcnAUikLgfO6OXWaTO9uG1jXM5XDL/KaUq6LTa2GNYtZi/iYkeZ?=
 =?iso-8859-1?Q?zlIT+4WkDab81U9I0xPp5UcI3FBG1ZZsIS2CIOXI9UelPibFysdzuBQLw4?=
 =?iso-8859-1?Q?P7brV8nHjQ7F4mA7SLPZ4k4/UpvotnxVhBRYloPNsIFX3YCfZAn0Lvcp8r?=
 =?iso-8859-1?Q?T120S501yRgep0aD773mDBaBqpd2CPJiTztagcFAFSXudA1xsVuUtfRRWD?=
 =?iso-8859-1?Q?R3CCgoutdE1p3y/T6pSTCUZU9H2WBigNDyRxziwjS6l14C0wn8XcsiSduq?=
 =?iso-8859-1?Q?wXHMv5ApQSxocRBfLuU/+gwTpWaszu/tKOndOothfeTZfL3snCwzT1+vCw?=
 =?iso-8859-1?Q?GkNp8PrrgPYSUV3VhGfo2M7u6QwDZFW+z9tw1NjFdnOS/1zi+nXCt000l4?=
 =?iso-8859-1?Q?AcJzTQWV/HOmD1oYypMO9K0Zu8Po647eSGJ27mhQe2BayBqiS/AHtVP/nF?=
 =?iso-8859-1?Q?svdA9UnfgzD8ZVTD0o14feotBp7dzwcG9uozJOBz7B7QKLERBehY1NEMeW?=
 =?iso-8859-1?Q?P6GomfWFG4Zaas2kA0L2JWypF2t0AZku1EOQtRJS8aDsaKYSvaJTVesvJa?=
 =?iso-8859-1?Q?Dfnf86NbSVB0t0Aez+w5lMg9iLKg+9F+/4curKAskGmFjJOCouSlDZqiig?=
 =?iso-8859-1?Q?F6lFNvBVa8CRo7hAWySYqy4+Ly/FdHsxwnt0hwax4MiGwmX1vJukW4OQQF?=
 =?iso-8859-1?Q?f7RGEOA0ckbT+FBV4SiJ00IWauFb1HJUBsgFfmi8j/cn7+EPBx/HDwbyDQ?=
 =?iso-8859-1?Q?5T6pwfuB2aDAG28ujFAyrSLhjH1oExljG0OIg6b7tJgq3EropSXyFa64dE?=
 =?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:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?1YbYUsQpHbRugWlc8ZvSPXkm4ROJAXO5FMFhz/GH4tyMga8OSDFOCPxgZy?=
 =?iso-8859-1?Q?v5yxqAdlqyQlNNL1/8kvyRQ3SNl0soQB8+2GXt5xzCPixJ7iyjLngG5t51?=
 =?iso-8859-1?Q?TCNnxypEjB5r7gAoljsP34klUs/2idcY6vMQdMLpnAzoYcppQAd2Y3ORi+?=
 =?iso-8859-1?Q?LVgilsIw3HPTfKAqQzVWWk1Dchpx40kTNIl3Lap2AD+vulNJmtrWwcNY7z?=
 =?iso-8859-1?Q?IP69p09AvEl6Ze6CaVfIuALMvXUDJQIqZB1zlJppzHFJwV8rSgUcAxBnGQ?=
 =?iso-8859-1?Q?W2elQnQ1KEinV6N3U8XOQiUn7jj0tNao7KTTifYeJmavanz+Vj+o8QA9qt?=
 =?iso-8859-1?Q?R/a/mpHtogZI/3M49vO4uaQtY4yT289nOsBtv4aOI6om+7JauwD5ir4DIu?=
 =?iso-8859-1?Q?OSJ714LU9f3/ehd8gxG6M0FeV9VxowAYbeDhESyZ4sLloGmXyD/LIVQ80n?=
 =?iso-8859-1?Q?8SKGS6of7mag0v7QStGnvPKW8sa05PZUYXj+Co27z25q+oDYYOMx65QfMO?=
 =?iso-8859-1?Q?f+4qOYo19g5GHVBAlEeFth7WLj2qUPGf9ogz+6X/UyGGEGuwfPed4kPjIb?=
 =?iso-8859-1?Q?EN5cx9ekjHLo5SNANjREmy3tU4YCF+o6IdsbvW64GOC9gddbsoZ2IoXokc?=
 =?iso-8859-1?Q?wFiiDl/OnCxqIvcQ5wrc13JbzI6gL6bcLn9DgWkQ8lUWs7wkPKDLtvGhA2?=
 =?iso-8859-1?Q?aspWc/nMc9OA6UfxJYo3krOhlvzzEiqVX/wwDNRC1+XV0rbZSXE4N8LueV?=
 =?iso-8859-1?Q?6+SXQnaWHFifHXC67QKsHLtJdJtdXASocoPWbVOvGIF9D4N0/wZJLMHV/X?=
 =?iso-8859-1?Q?FI3sysK+uVM3p9hA30oWaBadl+4SdKfUr+S0viPEsJUObYI59YBuxgpmOd?=
 =?iso-8859-1?Q?XpbszY0ICuif889BLb9MkXBwPaDRvu67RtCld2BjkUBFLxWXQphef6xQyj?=
 =?iso-8859-1?Q?ke4+aDAJ39GtbhcsQfbQ32SbFYGcvW0iYLbfeb+KNigVi5yA/yp21XoZKY?=
 =?iso-8859-1?Q?CKR3KvcC+Sl1KmGKtyOVsySgDR0femujxsBm0B7NGZYQEl4TMUc/rsynLT?=
 =?iso-8859-1?Q?ZVcMD1LnSY0HrKPkVF7apeX+jOcMR7ayfa/qLhuptj2bVRSYeISSk+As8r?=
 =?iso-8859-1?Q?ILTvcpEDR43qAS2QDe2rn4LK2OHxQ5CYvDk+Wn8hU1XJPEUk5A/LeO2HC5?=
 =?iso-8859-1?Q?1KCiPvTbJ1UFnqLDETgTfsFLfL6gv/2KdZIo/6+nRud4ooZSS4g9j9icSx?=
 =?iso-8859-1?Q?ojVXhoJjBayy+dbHKbDACcFxXCTKwB0KUKffnku72Er3tgTsgRAwSbHU5V?=
 =?iso-8859-1?Q?kaUG3zcFU/QcH9W49wNFlOHoiFdrKraYzmk8axwOcK7thvFmO+T1d9KqGB?=
 =?iso-8859-1?Q?DvAau4Y0x66ne+wOuoVbzFqVXLEl0RgnacuzGq6sdTV3RzekFMSFcaMuGr?=
 =?iso-8859-1?Q?M3SsCFXS0F6rK4lh48G9P+lzUjFdM1QaCIcaGkm3PE8YcFtEazFDobglgx?=
 =?iso-8859-1?Q?rMfC6JT1YrEyFP5ycoscY3MLl1guCQsmRgCk4fEYJl9HHGqmqOggzbYrRY?=
 =?iso-8859-1?Q?iYcEXN74jNW50Mi1hLjG8ZijvcKnC6m1xA7KJidJ3U9qt+mKI13Jy7n/SE?=
 =?iso-8859-1?Q?qeAXRxCdXuBXyb8jF6KS3B8PlrVla/r+e415pqvm/URbiJhLALMz02CQ?=
 =?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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19642122-27f1-442c-422a-08ddef88e100
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:08:52.5420
 (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: ZxeVf+FKdxwEYP8cKNDgE/isv8+dp6i0lWUadY9kwoBH7VUaVBCrAvOGTpb9G0VqhzYvioe6MPdI7KW/06Sx9EslP84Y7dK2/+mTUQtiV40=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB7893

Hello everyone!

This is V8 of the patch series that introduces eSPI (Extended SPI) support.
Compared to V7, it mainly includes fixes for MISRA rules violations and
cautions, several minor changes, and the addition of Reviewed-by/Acked-by t=
ags.

The series includes:
1) General refactoring of common IRQ operations with GIC registers to
improve code readability, simplify further maintenance and prepare the
key functions for eSPI implementation.
2) Introducing a new Kconfig option (default n) to enable or disable
eSPI support. Disabling this option prevents unnecessary resource
allocation for setups that do not require eSPIs.
3) Adding additional resources to store required information and operate
with up to 1024 interrupts from eSPI range.
4) Adjusting assertions and checks to pass verification for INTIDs in
the eSPI range.
5) Configuration of eSPI-specific registers during GIC initialization
for systems with GICv3.1+ hardware.
6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
access and operate within the eSPI's INTIDs.
7) Updating documentation and CHANGELOG to reflect the changes made for eSP=
I
support.

Also, to simplify reviewing, please find below link to unsquashed patches, =
that
are on top of every patch, that is changed in the series, compared to V7:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v=
8-unsquashed-v2/

Github branch with patch series:
https://github.com/LKomaryanskiy/xen/commits/espi-support-master-upstream-v=
8/

Changes in V8:
- individual changes in patches

Link on V7:
- https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00405.htm=
l

Changes in V7:
- individual changes in patches

Link on V6:
- https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00296.htm=
l

Changes in V6:
- individual changes in patches

Link on V5:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg02086.htm=
l

Changes in V5:
- individual changes in patches

Link on V4:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01767.htm=
l

Changes in V4:
- added a patch for documentation
- individual changes in patches

Link on V3:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg01628.htm=
l

Changes in V3:
- added a patch to update CHANGELOG.md
- individual changes in patches

Link on V2:
- https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00372.htm=
l

Changes in V2:
- added 2 more patches to implement helper
  functions for gic/vgic:
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
- removed 2 patches:
  xen/arm/irq: allow assignment/releasing of eSPI interrupts
  xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
  since their functionality can be moved to appropriate patches after
  introducing patches with helper functions
- individual changes in patches

Link on V1:
- https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.htm=
l


Leonid Komarianskyi (12):
  xen/arm: gicv3: refactor obtaining GIC addresses for common operations
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
  xen/arm/irq: add handling for IRQs in the eSPI range
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
  xen/arm/irq: allow eSPI processing in the gic_interrupt function
  xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
  xen/arm: vgic: add resource management for extended SPIs
  xen/arm: domain_build/dom0less-build: adjust domains config to support
    eSPIs
  xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
  doc/man: update description for nr_spis with eSPI
  CHANGELOG.md: add mention of GICv3.1 eSPI support

 CHANGELOG.md                           |   2 +
 docs/man/xl.cfg.5.pod.in               |  13 +-
 xen/arch/arm/Kconfig                   |   8 +
 xen/arch/arm/dom0less-build.c          |   2 +-
 xen/arch/arm/domain_build.c            |   2 +-
 xen/arch/arm/gic-v3.c                  | 209 +++++++++++++++++++----
 xen/arch/arm/gic.c                     |   8 +-
 xen/arch/arm/include/asm/gic.h         |  28 ++++
 xen/arch/arm/include/asm/gic_v3_defs.h |  40 ++++-
 xen/arch/arm/include/asm/irq.h         |  38 +++++
 xen/arch/arm/include/asm/vgic.h        |  56 ++++++-
 xen/arch/arm/irq.c                     |  55 +++++-
 xen/arch/arm/vgic-v3.c                 | 203 +++++++++++++++++-----
 xen/arch/arm/vgic.c                    | 222 +++++++++++++++++++++++--
 xen/arch/arm/vgic/vgic.c               |   5 +
 15 files changed, 777 insertions(+), 114 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:09:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:09:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116137.1462551 (Exim 4.92)
	(envelope-from )
	id 1uvvHf-0001f6-KU; Tue, 09 Sep 2025 10:09:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116137.1462551; Tue, 09 Sep 2025 10:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvHf-0001ez-HX; Tue, 09 Sep 2025 10:09:07 +0000
Received: by outflank-mailman (input) for mailman id 1116137;
 Tue, 09 Sep 2025 10:09: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 1uvvHd-0000yD-HK
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:05 +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 0371b46f-8d65-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:09:03 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU2PR03MB7893.eurprd03.prod.outlook.com (2603:10a6:10:2d4::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:08:55 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:08: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: 0371b46f-8d65-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lCMkPLkiebnoGEUsZdfAIOAnGkswz7aqufMZ4FNsm/X4GjuoCDUD4D+6y1YwadkZc4o9jKs64RAEG+E/4RAzNe/aCtSwyAQqQz5WLV6R/ke4SjdeIyzPofBlDZI2lF2+31Ns5GiqXlRU64ZBcicT2c7t+ZUxGaTzPBDwsV9OKpiTdOh2axQYgryUCj1nRHZq6EUsie01d4EVe9iG6z2PgYTIbEuWLaEmt8qBFu+o7wYXrlBS5Zpcv10BfZk2Of4ZMJkyk68xnQAGlmh6ELu+O0bFJV+hwuh6OlpYkAkY1CsYh7h1UdyHdmc68iJb0I1SiQYVtfiNgSxTdBFQeiIIjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JwZr1vV1Q96H6HEtTxKLX5tqmoYStsOduUB7RTj1ALk=;
 b=oSOEbeZTNIzj55WWbkKz5swRaamXVAF/WFjQLENGpNjsuNm1UtXYwKA3w9TgznsqYv/7aNXQlbV3tACQrkVAZFR3J0AKVhzVdcKszWxYUwzrcG9Dovg9aa74vdE0vPhYldGFqOn6+WBkSe4PmVT52FJ7GD+kFUJCkLXizwvaeDG+aJQl3wWYGqkRb9StQ1apURDVNfO/MtgmIh5qfKRKcuxIskU8qkbt/n+rcKXkNJ5C0DuTn1v10zbfp3utrEwrjnuxHli2for+qed2cd4Q91PrTZ8Mjkh1SbTUVwFdf5BG3zvCG0AG7BmTxIkM8vcKO4kvXDc6bdOuiWsvcQztkA==
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=JwZr1vV1Q96H6HEtTxKLX5tqmoYStsOduUB7RTj1ALk=;
 b=mrkTWNmfo9B1JoADNc3gwqELeOtqE+vmy3elF1Notr4/rL7akUh/bTn/SxdFTjFqxzy8e/KJeEZDl0sz1hbLpxIfMhk2ULaOOkxe8JV2KwnrOluRkGexGh4HzNK03k7BERMUtDaWRq4kMYrjbGEi4hCvdrs/elLUV78h93K5BjdzjnXqrovzVAwQ0IaZUNywtxVXJs5pie53iNPbRFMyeanoUfBsY2/5B8gADf7RkQWg5kcoTrgkoZf1Pp8jjIf8wVvgbp0Mq307D38DnR0EgR4CxLNpgw6zwv1LMJ8CjH8KknGl3oXApw8GQrcKVmruIjcLUZC/b/fr2koEyuCz1w==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko , Julien Grall
	
Subject: [PATCH v8 01/12] xen/arm: gicv3: refactor obtaining GIC addresses for
 common operations
Thread-Topic: [PATCH v8 01/12] xen/arm: gicv3: refactor obtaining GIC
 addresses for common operations
Thread-Index: AQHcIXHA9a7hs9OcpEuwEnF/MObXqg==
Date: Tue, 9 Sep 2025 10:08:55 +0000
Message-ID:
 <8a3d9390b8d4ed9c9af0465f27fe6866e6535162.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU2PR03MB7893:EE_
x-ms-office365-filtering-correlation-id: c0650e2e-65b4-466b-cf35-08ddef88e2b4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?R3WYXPD8xUIg31Btg+/lDq0oWnFVLPLIhRZAQRDm83s/ygmR8SPowuJpgb?=
 =?iso-8859-1?Q?Q+e6KtMQdSFb0wO473WScFb7OOsXe/ZFsDgTqc5Fca5hsGnHkMP7glqH3i?=
 =?iso-8859-1?Q?vRCGF98LXDlqoA4dk92wwVXCI2/Ux7Cy9PnBMc7Aet0tgNMA0srSw30i/I?=
 =?iso-8859-1?Q?lMuDZc9aIyx5O1lbO8AM1N0s7Hw+nyTD0Fot5hXMZXhix+EaXiavgYcDKo?=
 =?iso-8859-1?Q?KzfTgJY3+KRC/8xYN6XJx9noayz1b5FU5T9eRJUgsNqJRTC+Qi1CqA9pBo?=
 =?iso-8859-1?Q?bKV+YLDtfPvybwCbsxIE6t/f8VwhzR2+EtdourWOABNkm3/RrRJj1SVLCG?=
 =?iso-8859-1?Q?Y0bMuqJOmX6d1SCDCosG4gl4vNKMWBkUEkSBHkgbS5O0MEqokdSJmrvuW/?=
 =?iso-8859-1?Q?UODw9so61ZZWfoHwkMHW4pJeTVY6RTNAB5XDq2CTZRi76L3iQr3Lo38y3i?=
 =?iso-8859-1?Q?Fq1tSi4FGEELjylUejKnWBmGlExFevLeZT9SsLEK05PbN1ymynqFl+qJtF?=
 =?iso-8859-1?Q?G9TxiycljC7zc0CusWRgjdwVHtk3XTKlqM6JZuUCOKfeR9qpeSg/z+h4s4?=
 =?iso-8859-1?Q?t298RCQp085akkdvbu4HSG4k8MGD79EFnIt4/n22TDMGR2COvIU+A3rzyl?=
 =?iso-8859-1?Q?lkiDC+8WP48mOzewOpgedyUv5CpOVZisnmUKF/uN86xQYYiDm0f3JTIW1v?=
 =?iso-8859-1?Q?UMIhlLUUBADwtHQvEwscWjET3tob0zK07s50uR6KdzyMoIwQtnf17wB8A1?=
 =?iso-8859-1?Q?1fvBabHUOXkgbiA3PCprme5xpAKfjWtK4yVXqPTVWT6Mo1k6yvG9ODxQUd?=
 =?iso-8859-1?Q?AfwnLF3vWHfZgsFRbMjjaxk6pAf4bVklCkQF9aM7XNReYVGRLNM2anK/1z?=
 =?iso-8859-1?Q?KGEIDKjKyhLku1fSQq0XY6E6rS+RpC+sIkIq+2FIdvWJIZbyCpV1qVB4M7?=
 =?iso-8859-1?Q?Zsd1afsW6DkzoA++wy5J+hG20QA0GPFZ7JD2FX7UjyYzoFfxz9a8j+MrBC?=
 =?iso-8859-1?Q?XyE5q/sqws6SRFzhkIY+7p+TSVcdejC7kPZ1Li2roFGypzrfIWUu7lVeyq?=
 =?iso-8859-1?Q?Ng5CM6fetMLgwGZpO0oNASbdNe+LnBmemiy7lHLO7OrLBkCzNI27E0QdeR?=
 =?iso-8859-1?Q?JT82HgTh+Mezgb9tlS38kpcHRHiMtGW/5xZ7ep70THEfxTc9/LfKdpu+HW?=
 =?iso-8859-1?Q?zow5wx2u0ccAp4ubOW2HN9xOeSKnCoWhlOJgY5z9mCm/57IJSrIDcJAg3U?=
 =?iso-8859-1?Q?8m7ZY7bOPQkQL4HVZJ+Li7dXxRR7K4cFQJpssaZcbWKT3aj4p0QawLwhxh?=
 =?iso-8859-1?Q?Lo/n8X1SeApG+OgHoaNn0W0WWovrkyU/N/qHCGPeC9qIdiykyr8rV7Ox4K?=
 =?iso-8859-1?Q?LZfE3uFHL69keo9JOcjkrwkafzsD5oRl0WQXxKxrjSxWbe3AivGTE0yC0D?=
 =?iso-8859-1?Q?oXJM9K6PqIOt4+pQjUe8/JgqkmKuAlF+PKxW88YJvWBGEwMVcsPTA7zynO?=
 =?iso-8859-1?Q?K9XjcjgQ5Mtz+GkKDskBMLzmWzVtmc6e5uCSlrtIkMDA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?XTkEcE2c/HWTI9d062Wyujo3U/txi1DuNXxpiJprrYFdbE9RRinPeJgxW8?=
 =?iso-8859-1?Q?RMv0NHE7hFEbDaSuCyE/V8Fia1BHxKmjzyENSr1UhsfTXEn/pgK+/xZW4q?=
 =?iso-8859-1?Q?XAIxRTcPK7lkg/QCURrxvUedHW9nCuUrpb+yrhHyVH9orvR+NcBK31WOXk?=
 =?iso-8859-1?Q?zAjWXqZfS9vA6DYm3HkUzTkQ4yMiKa+Z6K8kHQHeU7zb/7rVs9uaMAV6Pi?=
 =?iso-8859-1?Q?Xg0/DH79q3H58oY9ahUVT16GV0AxF/57uMkZ9jsA2csSz1XzcHO3p95cY2?=
 =?iso-8859-1?Q?JBf+wu3VFPVJ/ZDVOp95W/qNJwGPDFKS+Tm2u/FkOuXguHnJf/qz2Evk5u?=
 =?iso-8859-1?Q?HVOFusRD2Qz6sL7bHL+crbHl4HU1yRLhb/szPDnui/z8TnaaE5gRW3MpPj?=
 =?iso-8859-1?Q?8+orWF5wdZUO/qZw3M954qjxeczNG0Uj40PBV98Ug1JzMzzyenvc5sPOh8?=
 =?iso-8859-1?Q?x4DxMIIAb/yGYKwOBrt+OtpdwazHhpRM1TNeD9rnVSyNQACexMn4ojeoB8?=
 =?iso-8859-1?Q?Z88i4HesjoVgp5r/k93CfKcYhmJ8AFAuM+ZGvO13S1eBl5YFvSaeTKqJpn?=
 =?iso-8859-1?Q?2/eiW78lNjNSsC3CUzdOf8aNDORJN1Ja82hrmN0oXrk486KL+HvgfCRIlN?=
 =?iso-8859-1?Q?Wc0tg2whNBCTXgTMpdzzgEGTenMtY/31PGn4uinP/ff6B1jqs7729miR3n?=
 =?iso-8859-1?Q?ESr3LXZIUho1nLPX1/V/DCRbdiG75rgKdUZAuNASV/OVkpEzH1tjnGtj2X?=
 =?iso-8859-1?Q?U8/lWeQG6ZF7Mquz4bOPZfgUm/z1o8ul+NYMPmLfdfluDy5e61Q1bJ/hAH?=
 =?iso-8859-1?Q?HvXnsxKDgxroTVNUu1Y3esjFJpvt/mD5KSWPrAM8s4+D5ntOjIkdaxFDet?=
 =?iso-8859-1?Q?xk5PrJOg79xGdiT+5RzSgF4yfcvl3IMuu9tuQWzfFIEsEIQ9FBJGBdsWar?=
 =?iso-8859-1?Q?Mx682O/A245il3TJWxkCLr4Ro7zS17Zqh3iGRNbaMg7dTYpBRT9jBX9CB3?=
 =?iso-8859-1?Q?mYQPFfiVDYh6KOhZwyh9qv2L/9geTTEKS8Mz5Y6ZMoUjEYQOpPK1FSqM1X?=
 =?iso-8859-1?Q?QnAJBJAbreDG0AqPyKnxU8KmOg+d59dNihLx51IYASrQzG6By/qIfjDDSj?=
 =?iso-8859-1?Q?IsbfydgGA0/EvoaadlozbKlWKmAuzzolss0/cluWg8RicTQaBpRux+4ev+?=
 =?iso-8859-1?Q?bsK2rmoYWCPgPKpfp82Rix/kV0CJz8Ocjcma2YDNd8KLSARzzQdudfnsQ5?=
 =?iso-8859-1?Q?EvzCjtrcOP9nimzGuVPQB7kSerVWgg5Rw4+JSDUkaiNsFJZd5nK9wzesyM?=
 =?iso-8859-1?Q?D4mvTAPn3KQXW+Jls8LF0oRxMra6N5zs5dd1Vgjdp8G8KSwPkyBZ+AV9bV?=
 =?iso-8859-1?Q?5c0h6yA5HFftt9cjR2o0gQJcJ1fGUmwf7pGOVn1MJGi3A3iHBjRq8EQ0zJ?=
 =?iso-8859-1?Q?aUGplfvMUc2ZIalGXztROrbS/jOHhIsU+xZCi/T2WHGADdGz8bnvBVy/WY?=
 =?iso-8859-1?Q?rBMiW/4uz8RfST/KaVKZUU1Pi9YhetaoeWmQt8L2u0xJIx7IcIkaoXcdSC?=
 =?iso-8859-1?Q?GKMEJa9j/mCQP6/Ce6Abv+hK6bwuQPTp1E3ErQ6/+7LSZLpUADX0nnLPCg?=
 =?iso-8859-1?Q?+pA/lhycD4D5bnuP/MzLfIfgnQBze3mBqjtlO7t1fioOmiNMHazZ3dSeYQ?=
 =?iso-8859-1?Q?/BXkv00rjtmLYhZlbjI=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0650e2e-65b4-466b-cf35-08ddef88e2b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:08:55.4274
 (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: 4PaAd6W9p0RpU5tQXZb5jFPmV97j+VF3pwYc2Pgm9GWK3T/9zpZLjBaD9nHjCSY3DjvXSvablzRg3P9Po3Tm2wjYBtYFhV8++5kImWIzsjg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB7893

Currently, many common functions perform the same operations to calculate
GIC register addresses. This patch consolidates the similar code into
a separate helper function to improve maintainability and reduce duplicatio=
n.
This refactoring also simplifies the implementation of eSPI support in futu=
re
changes.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 

---
Changes in V8:
- add missing breaks in switch-case (fixing 2 violations of
  MC3A2.R16.3)
- no functional changes: moved the get_addr_by_offset() call in
  gicv3_irq_set_affinity() under appropriate check, as it should not be
  called for local IRQs
- minor: add comments for default cases (fixing 3 violations of
  MC3A2.R16.4)
- minor: evaluate mask to variable in gicv3_peek_irq() (fixing 2
  cautions of MC3A2.R13.2)

Changes in V7:
- no changes

Changes in V6:
- no functional changes, just fixing minor nit: changed u32 to uint32_t
  in get_addr_by_offset()
- added reviewed-by from Oleksandr Tyshchenko

Changes in V5:
- fixed a minor nit: changed %d to %u in the warning message because the
  IRQ number cannot be less than zero
- added acked-by from Julien Grall

Changes in V4:
- no changes

Changes in V3:
- changed panic() in get_addr_by_offset() to printing warning and
  ASSERT_UNREACHABLE()
- added verification of return pointer from get_addr_by_offset() in the
  callers
- moved invocation of get_addr_by_offset() from spinlock guards, since
  it is not necessarry
- added RB from Volodymyr Babchuk

Changes in V2:
- no changes
---
 xen/arch/arm/gic-v3.c          | 126 +++++++++++++++++++++++----------
 xen/arch/arm/include/asm/irq.h |   1 +
 2 files changed, 91 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index cd3e1acf79..2fdd96dbb1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -445,17 +445,72 @@ static void gicv3_dump_state(const struct vcpu *v)
     }
 }
=20
+static void __iomem *get_addr_by_offset(struct irq_desc *irqd, uint32_t of=
fset)
+{
+    switch ( irqd->irq )
+    {
+    case 0 ... (NR_GIC_LOCAL_IRQS - 1):
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+        case GICD_ICENABLER:
+        case GICD_ISPENDR:
+        case GICD_ICPENDR:
+        case GICD_ISACTIVER:
+        case GICD_ICACTIVER:
+            return (GICD_RDIST_SGI_BASE + offset);
+        case GICD_ICFGR:
+            return (GICD_RDIST_SGI_BASE + GICR_ICFGR1);
+        case GICD_IPRIORITYR:
+            return (GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + irqd->irq);
+        default:
+            /* Invalid register offset for local IRQs */
+            break;
+        }
+        break;
+    case NR_GIC_LOCAL_IRQS ... SPI_MAX_INTID:
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+        case GICD_ICENABLER:
+        case GICD_ISPENDR:
+        case GICD_ICPENDR:
+        case GICD_ISACTIVER:
+        case GICD_ICACTIVER:
+            return (GICD + offset + (irqd->irq / 32) * 4);
+        case GICD_ICFGR:
+            return (GICD + GICD_ICFGR + (irqd->irq / 16) * 4);
+        case GICD_IROUTER:
+            return (GICD + GICD_IROUTER + irqd->irq * 8);
+        case GICD_IPRIORITYR:
+            return (GICD + GICD_IPRIORITYR + irqd->irq);
+        default:
+            /* Invalid register offset for SPIs */
+            break;
+        }
+        break;
+    default:
+        /* Invalid INTID */
+        break;
+    }
+
+    /* Something went wrong, we shouldn't be able to reach here */
+    printk(XENLOG_WARNING "GICv3: WARNING: Invalid offset 0x%x for IRQ#%u"=
,
+           offset, irqd->irq);
+    ASSERT_UNREACHABLE();
+
+    return NULL;
+}
+
 static void gicv3_poke_irq(struct irq_desc *irqd, u32 offset, bool wait_fo=
r_rwp)
 {
     u32 mask =3D 1U << (irqd->irq % 32);
-    void __iomem *base;
+    void __iomem *addr =3D get_addr_by_offset(irqd, offset);
=20
-    if ( irqd->irq < NR_GIC_LOCAL_IRQS )
-        base =3D GICD_RDIST_SGI_BASE;
-    else
-        base =3D GICD;
+    if ( addr =3D=3D NULL )
+        return;
=20
-    writel_relaxed(mask, base + offset + (irqd->irq / 32) * 4);
+    writel_relaxed(mask, addr);
=20
     if ( wait_for_rwp )
         gicv3_wait_for_rwp(irqd->irq);
@@ -463,15 +518,13 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32=
 offset, bool wait_for_rwp)
=20
 static bool gicv3_peek_irq(struct irq_desc *irqd, u32 offset)
 {
-    void __iomem *base;
-    unsigned int irq =3D irqd->irq;
+    uint32_t mask =3D 1U << (irqd->irq % 32);
+    void __iomem *addr =3D get_addr_by_offset(irqd, offset);
=20
-    if ( irq >=3D NR_GIC_LOCAL_IRQS)
-        base =3D GICD + (irq / 32) * 4;
-    else
-        base =3D GICD_RDIST_SGI_BASE;
+    if ( addr =3D=3D NULL )
+        return false;
=20
-    return !!(readl(base + offset) & (1U << (irq % 32)));
+    return !!(readl(addr) & mask);
 }
=20
 static void gicv3_unmask_irq(struct irq_desc *irqd)
@@ -558,30 +611,28 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cp=
u)
 static void gicv3_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
     uint32_t cfg, actual, edgebit;
-    void __iomem *base;
-    unsigned int irq =3D desc->irq;
+    void __iomem *addr;
=20
     /* SGI's are always edge-triggered not need to call GICD_ICFGR0 */
-    ASSERT(irq >=3D NR_GIC_SGI);
+    ASSERT(desc->irq >=3D NR_GIC_SGI);
=20
-    spin_lock(&gicv3.lock);
+    addr =3D get_addr_by_offset(desc, GICD_ICFGR);
+    if ( addr =3D=3D NULL )
+        return;
=20
-    if ( irq >=3D NR_GIC_LOCAL_IRQS)
-        base =3D GICD + GICD_ICFGR + (irq / 16) * 4;
-    else
-        base =3D GICD_RDIST_SGI_BASE + GICR_ICFGR1;
+    spin_lock(&gicv3.lock);
=20
-    cfg =3D readl_relaxed(base);
+    cfg =3D readl_relaxed(addr);
=20
-    edgebit =3D 2u << (2 * (irq % 16));
+    edgebit =3D 2u << (2 * (desc->irq % 16));
     if ( type & IRQ_TYPE_LEVEL_MASK )
         cfg &=3D ~edgebit;
     else if ( type & IRQ_TYPE_EDGE_BOTH )
         cfg |=3D edgebit;
=20
-    writel_relaxed(cfg, base);
+    writel_relaxed(cfg, addr);
=20
-    actual =3D readl_relaxed(base);
+    actual =3D readl_relaxed(addr);
     if ( ( cfg & edgebit ) ^ ( actual & edgebit ) )
     {
         printk(XENLOG_WARNING "GICv3: WARNING: "
@@ -600,16 +651,13 @@ static void gicv3_set_irq_type(struct irq_desc *desc,=
 unsigned int type)
 static void gicv3_set_irq_priority(struct irq_desc *desc,
                                    unsigned int priority)
 {
-    unsigned int irq =3D desc->irq;
-
-    spin_lock(&gicv3.lock);
+    void __iomem *addr =3D get_addr_by_offset(desc, GICD_IPRIORITYR);
=20
-    /* Set priority */
-    if ( irq < NR_GIC_LOCAL_IRQS )
-        writeb_relaxed(priority, GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + =
irq);
-    else
-        writeb_relaxed(priority, GICD + GICD_IPRIORITYR + irq);
+    if ( addr =3D=3D NULL )
+        return;
=20
+    spin_lock(&gicv3.lock);
+    writeb_relaxed(priority, addr);
     spin_unlock(&gicv3.lock);
 }
=20
@@ -1273,6 +1321,14 @@ static void gicv3_irq_set_affinity(struct irq_desc *=
desc, const cpumask_t *mask)
 {
     unsigned int cpu;
     uint64_t affinity;
+    void __iomem *addr;
+
+    if ( desc->irq < NR_GIC_LOCAL_IRQS )
+        return;
+
+    addr =3D get_addr_by_offset(desc, GICD_IROUTER);
+    if ( addr =3D=3D NULL )
+        return;
=20
     ASSERT(!cpumask_empty(mask));
=20
@@ -1282,9 +1338,7 @@ static void gicv3_irq_set_affinity(struct irq_desc *d=
esc, const cpumask_t *mask)
     affinity =3D gicv3_mpidr_to_affinity(cpu);
     /* Make sure we don't broadcast the interrupt */
     affinity &=3D ~GICD_IROUTER_SPI_MODE_ANY;
-
-    if ( desc->irq >=3D NR_GIC_LOCAL_IRQS )
-        writeq_relaxed_non_atomic(affinity, (GICD + GICD_IROUTER + desc->i=
rq * 8));
+    writeq_relaxed_non_atomic(affinity, addr);
=20
     spin_unlock(&gicv3.lock);
 }
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index fce7e42a33..5bc6475eb4 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -29,6 +29,7 @@ struct arch_irq_desc {
  */
 #define NR_IRQS		1024
=20
+#define SPI_MAX_INTID   1019
 #define LPI_OFFSET      8192
=20
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case.=
 */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:09:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:09:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116138.1462559 (Exim 4.92)
	(envelope-from )
	id 1uvvHg-0001mi-5j; Tue, 09 Sep 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 1116138.1462559; Tue, 09 Sep 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 1uvvHg-0001mT-0C; Tue, 09 Sep 2025 10:09:08 +0000
Received: by outflank-mailman (input) for mailman id 1116138;
 Tue, 09 Sep 2025 10:09: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 1uvvHe-0001My-T7
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:06 +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 04c357ab-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:06 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:08:59 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:08: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: 04c357ab-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g1upfLNI3NhaKvMGgTF98nX55TQGyHkLX7rI0dXOEY7xuY8znvbB/8zrG6Zprc8+Oi+pFnoqtN2cc/n7vqmEGwnDvILR24DjIj1NZ8UTEx9NYmehCfv9Zai4S4m5XRmkxBFnBioU/mHKoOjNI10Xt0BeB23I9NSKh1nt3Q+L03pBV5bPcXOJDCG6NBeQ9TVs+IplCadJdvr71GqNb4t+6+K77OzywSE9Dp/1Be/PrDT3V4U4KqqmkPjNncTsLxn81AacsqVdisg5vyimMKtZL8ZolIvs1fd3hIwn6S7bwL7BJMFxNtQDII/jYPRsJZvakkCszk+NyVp2cDg5tv5PuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E+cNpr8L6MC8jcvfDetjjAbGfgyiOuFSGmAfyQYgrRk=;
 b=xg8ep6huOTTUnV+5546fLZJaAs9e7Pct5hbHAK5eb4N4dXgRIucQ4g+C4k229tg0ywegQhK0T6lDJ6O7I8nYwQxWV/hGZ5ks08orC72kxZsyZ/FZza630ZnfHFFDlJNgG7BEv0k8UGGfuUosmML3ZgRVA2pwWBZqcCkKcSO7euWUn21i1jBv9//1bRlyrzFGHxxo7moqstu3/sSDVayiB0yIi6XT6VtRfKQcDDEiucsuid4ZaPk77+u7HGdTwTebxfeaQjDok8tGWtm9Tbeq/3rPpPwqLdtiIpIDelfbI0AHiUXupe38JKHYYzpTCbNpspIce8Yo7ArFuJwdaEMbmA==
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=E+cNpr8L6MC8jcvfDetjjAbGfgyiOuFSGmAfyQYgrRk=;
 b=nRzjHsthRS198CRKZCYlMUyEnaqRaroW5LcciP6wQKaoDCQ6IjLgPJGCzeJ4QV452hRF12GnMcvuWreROfOM1HkRT3KLIRnW2/fXvOcAceKrRDXZW2UAWHR14gXTB8G6XX//JTjFZwCBKvFTtDvklNk+YMh+fS1+gVjgZjwXB48m7MAgURLj7ebO0ujqxN2XHvd0BngBCLcxviJapmV7uLbW9t3ih4KuSU9f7pLphuPQLT6a2Yo2+ALCnbYYhxLALYJkEiMuYc/sk40fTaxTXfZ4uajg5rJPycQmFTat9alp8ujbsX/69IJLFvv/vQkPR/4vDpwQdD0dRWHWE9pvzw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v8 02/12] xen/arm: gic: implement helper functions for INTID
 checks
Thread-Topic: [PATCH v8 02/12] xen/arm: gic: implement helper functions for
 INTID checks
Thread-Index: AQHcIXHC+ua0MD6H9EigKiS7S0iu2A==
Date: Tue, 9 Sep 2025 10:08:59 +0000
Message-ID:
 <453217b044f35378076eff292ffb5a2ba54f516f.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: a5b05688-4e93-4661-2183-08ddef88e4fa
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?9Pwkb5ku9GkwtrkUwaQlSYCcq3KU5WTgLTAbc/SGwA95NyKvFsLnCB5TVq?=
 =?iso-8859-1?Q?QEqsnbCTFwn9pkb8F2khFJRYpapRkDLir7nj88wg+dVxJ4rL2COLhhjw9P?=
 =?iso-8859-1?Q?YgnLABEEffJeliAB73hV62YkkZgwYKcjb+4vTEo7AcQFBERZtWHs+eI9Ry?=
 =?iso-8859-1?Q?JuZfHhuylGBjobZWoaTNr/IvQLOBnAHosGjQzdydFxdNMMrdYaeTT38q+V?=
 =?iso-8859-1?Q?iJ7FoRDlMWdxO6NJ1UkhEqOwucAMmGaaS6BP5uAX8LTjlOTzvDyVeh/vBw?=
 =?iso-8859-1?Q?LyPbaFmuwKHQusdYVEjzpia6gWEGt0VXqoVJM5STtk7V275vWvgGXn08lL?=
 =?iso-8859-1?Q?IJx4ANacUgrMdEJM7tPIfvOOLSrZlAHCWFP4reVPh67R1fK2dvrzjzPI05?=
 =?iso-8859-1?Q?tga2Pg7cCHTtDBVclcsVwgqMGYDqDOH8ZQ4RaqZ33oAMuiVImhRHnkPgds?=
 =?iso-8859-1?Q?8Gdaqkv894hOrRmiZ8O7XEMM7U5NckqZzsgYfXeXfApRQ3xLxJTq9+rVCA?=
 =?iso-8859-1?Q?eefRzvtTgJX0d7cv8iynp2137IZBnDC6w1iZIQxoYF4qGxtRhuPT2o0WZ+?=
 =?iso-8859-1?Q?kEPGNFesPW3aTUz+mzNW/iWeMI04jwYXAzO+qQO16qYFd45cv77tCqfJa0?=
 =?iso-8859-1?Q?r9IOxEpECi9d4SfyP1h86l+LcOa0CT+uyA4O6KORY9FkxUBvs5kKuuuKtp?=
 =?iso-8859-1?Q?HQp+diLDwXJK1/WWSBqVU9nrPGunTA2eKh2jP8D2imlOjh+XLf7GtmeWy9?=
 =?iso-8859-1?Q?ZalrW8zbLk52teSpH0MuL9eLD0KLZElVubEiwaCiQpIgfPm2Ski+NmEHTa?=
 =?iso-8859-1?Q?dwMqMHOypIRu0qDCdoYf3Wn7ue7+GMNm8xcvFiJlv31wazUrECWwR34sOt?=
 =?iso-8859-1?Q?EaT5sqfISZD77mug0R1LnZvee+vdT0c3jqC7GSX/NE9mQPQnzMN4lWLdq2?=
 =?iso-8859-1?Q?NeqRD3ohz1xTAcklwQNpuMo4py57Pn831Zy2q00rAfDi7Pbo7AAX12FaKQ?=
 =?iso-8859-1?Q?xLabCDu9dRCaYWcKPVMrCMup5Zqlcz9Uj7EBV5IiE9siA0hhZzjNo7cnGZ?=
 =?iso-8859-1?Q?gT49cfJRW/2EtNI/4J+Mz6/Lul9YgEC3n6f8MzA5zmMjV5ESevG+6LrYZS?=
 =?iso-8859-1?Q?D3YWEezC98N3GhplmjTfvfbQTwczNtJ5sGWfdZlyiinxQzKCxXbjJNwLFF?=
 =?iso-8859-1?Q?XtV44chtQP2/K7pDLnXIvmVQGO3sn+3iCwdZZeodwaIKJbKnIcphm3ur3P?=
 =?iso-8859-1?Q?ugaf3WdXK1qnzWqg5GkpcxMwB9rmHlqeZYBgVsHEMnspWPhCS7RLyTkFi+?=
 =?iso-8859-1?Q?t3O2FDxiq4K3iBiQHdSkSTS5mI0T2OHsiibwlxQ4KZP6bnhpswLvtFzdGB?=
 =?iso-8859-1?Q?z/o5aZzO4ky3rzTfAh2V8ci4uFzNNEgD0ZiLpIZqg8pr+lP/Cp66A8CaA+?=
 =?iso-8859-1?Q?dFsgmzai1+WEXSLV9TReT5FPzPr1ECkImlzEkIrwqeW4YpVSd0L5Y/4HJN?=
 =?iso-8859-1?Q?30TfnBGHWcv6T38QSC0ePIPeyrYjtIKTEQvE6h222jIKXnPL8iRUT5raZ6?=
 =?iso-8859-1?Q?JUmuQnU=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?EjBLxemdkagfrHS5qDMY78NTPckw76JIueZLA6zU0nK/HDbTa8FEu6WHdc?=
 =?iso-8859-1?Q?xHpapCPxpFZ8eH8kORRbO+86t777nLRceIyhmGYd1HTFOhNhiw5CH7qyKb?=
 =?iso-8859-1?Q?WB4//VMueOmK5JZhBtX2cZ/9UnXjeiZkPwTd67E1HXqHnNa8CtdXgPaLk0?=
 =?iso-8859-1?Q?sHlW76h7wkcTXSo8Z/W/YORo63ab2qh0cI5zjvuy3T/Ekq4d3aJdfdkfjn?=
 =?iso-8859-1?Q?VN4e/7Jg4zJEKhBHltykkfDxU4mr4u/auDuDzSwaR22iCBmf/FJXfbXcb4?=
 =?iso-8859-1?Q?GWOYYVMrhpfdhcEGuoJBfl0Z3jH6b0/KUQ9rMtbqj10zOokGng8CAKQjbz?=
 =?iso-8859-1?Q?A11+yGPWdi3Nz4eU7wPuQwDJG1lLP6Vj0a698vH9c3u1tPjvcWp6I4VP1g?=
 =?iso-8859-1?Q?sbUQG4Fq3M19kINsbWLBZiU/1yZQx9h557FCO3Y6VdsMfWwO3z8fyMLwIy?=
 =?iso-8859-1?Q?QDa+PEJjOlA4wrjkqob7CJXdmWaarHEYmNkfwn8wDX+rHzU07mPPNlZdim?=
 =?iso-8859-1?Q?LsBVwLoCH3TkcZ3L7hqpn9nKlAJMVp8iLQ33Z6k40fB95Q1853oo47tTPt?=
 =?iso-8859-1?Q?4a2uAeD4NGODdxr3PW/94slYoVyfY2nLXDjgrnz1zjNyfY1tbKZMhFFkml?=
 =?iso-8859-1?Q?7uO4PNdaRAG7GSxSpLEC/M8RkJARWg85uizuiIgcZLpBmEn3AqyO8/cqjV?=
 =?iso-8859-1?Q?WQXtha8ZU4q2CgmKSRs9zHs1hJQNW2awf1EcpN4S3k7Z81icY84iDj30+s?=
 =?iso-8859-1?Q?fX53MLvu3ZxbXxRkoJsX1lBkhFDC/IIZPX4M3PFdkT4xiyX2po/7hbjvmn?=
 =?iso-8859-1?Q?Iwmkj6ZUz7I/u7GXJUtAxDwrVt/0NgmGDFFNM3X2N6j9aQvJfRfqFV97x6?=
 =?iso-8859-1?Q?ESb/BI7timxilcpW9eY8w7uFbOIR6d81CLNiSUpyHwQUo7r3E7Z6IVjzR3?=
 =?iso-8859-1?Q?vmtyPvxiMg5YT8JqyC4EKlVXAoHERuIXLYPVE4sbmibhMjqX1YqfW5EQBi?=
 =?iso-8859-1?Q?2/WFTcLay9Y5jPi+VYA1bwv1IsH9LF+2Ztw9Vyd5lslW5Bi4Spyro1eFdg?=
 =?iso-8859-1?Q?2PN34XWhx356ugL/Vgf0CYr1yK5U9bV+Fksiq+8oSXh5cbclf5FOiGCTEJ?=
 =?iso-8859-1?Q?1UjzGcgcAzFxtpj39t95nmavQoT1M5rzerTTHrf5E0yhBQONyWCaph5Dgu?=
 =?iso-8859-1?Q?RHnp1Eyg+fya9u448A1AacsRr+ADceMKyuYAsTB9NPCOerIcqymvg82euk?=
 =?iso-8859-1?Q?MvvoVtvfAhxIN2q5evmsHnfHeRiVIuEhOuOm8EGYzorTG9/iv1HvRt24xS?=
 =?iso-8859-1?Q?gzGgttVVjPrar39VT0cLSb1FAg31OIOVHp7VobLUMAhHwztmwFxR5/Pqn/?=
 =?iso-8859-1?Q?YLKRDwcB3UG1CRG7p+kApFF+sCYo20bfgUemM+VffXZuVGttqHPMX9XjfS?=
 =?iso-8859-1?Q?yCSEm+iaL+uFX4RqH3fqLOvnvuQ62JahiNFF2HhvqH8/pH537rmSNa8E6q?=
 =?iso-8859-1?Q?9rGIytc3gdIKqX82/j6uzkq0EWqHaNUHm8itY8N9MD0tMGqhCtCmrgX646?=
 =?iso-8859-1?Q?kAagbKc39kG0ezOxSmhGKyWibdBEd1JiD5iLVWkdIz4zNuVLIM//OEG6dg?=
 =?iso-8859-1?Q?2k1YNc/o9Iya8NpsKLhbqe1O+gC7TrPGn+jsB2iPvzDNLbmrkQs8FqicJl?=
 =?iso-8859-1?Q?j6brtWTn7eB0PCIzWXw=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5b05688-4e93-4661-2183-08ddef88e4fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:08:59.2218
 (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: XMFjln359MZ02dwHM0BrROTIttngBI9fPm976hndjY/xdqUqOp04dHbJ81vYkQZVyfaZWx75xrf6EJ+hO5dJmHRDq3UP6Z6gf2mCD0ZR3To=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

Introduced two new helper functions: gic_is_valid_line and
gic_is_spi. The first function helps determine whether an IRQ
number is less than the number of lines supported by hardware. The
second function additionally checks if the IRQ number falls within the
SPI range. Also, updated the appropriate checks to use these new helper
functions.

The current checks for the real GIC are very similar to those for the
vGIC but serve a different purpose. For GIC-related code, the interrupt
numbers should be validated based on whether the hardware can operate
with such interrupts. On the other hand, for the vGIC, the indexes must
also be verified to ensure they are available for a specific domain. The
first reason for introducing these helper functions is to avoid
potential confusion with vGIC-related checks. The second reason is to
consolidate similar code into separate functions, which can be more
easily extended by additional conditions, e.g., when implementing
extended SPI interrupts.

The changes, which replace open-coded checks with the use of the new
helper functions, do not introduce any functional changes, as the helper
functions follow the current IRQ index verification logic.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V8:
- no changes

Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- fixed a minor nit: moved the existing comment to the line above to fix
  formatting that exceeded 80 characters
- added acked-by from Julien Grall

Changes in V4:
- removed redundant parentheses
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- renamed gic_is_valid_irq to gic_is_valid_line and gic_is_shared_irq to
  gic_is_spi
- updated commit message

Changes in V2:
- introduced this patch
---
 xen/arch/arm/gic.c             | 3 ++-
 xen/arch/arm/include/asm/gic.h | 9 +++++++++
 xen/arch/arm/irq.c             | 2 +-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e80fe0ca24..4bb11960ee 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -111,7 +111,8 @@ static void gic_set_irq_priority(struct irq_desc *desc,=
 unsigned int priority)
 void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(priority <=3D 0xff);     /* Only 8 bits of priority */
-    ASSERT(desc->irq < gic_number_lines());/* Can't route interrupts that =
don't exist */
+    /* Can't route interrupts that don't exist */
+    ASSERT(gic_is_valid_line(desc->irq));
     ASSERT(test_bit(_IRQ_DISABLED, &desc->status));
     ASSERT(spin_is_locked(&desc->lock));
=20
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.=
h
index 541f0eeb80..3fcee42675 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,6 +306,15 @@ extern void gic_dump_vgic_info(struct vcpu *v);
=20
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
+static inline bool gic_is_valid_line(unsigned int irq)
+{
+    return irq < gic_number_lines();
+}
+
+static inline bool gic_is_spi(unsigned int irq)
+{
+    return irq >=3D NR_LOCAL_IRQS && gic_is_valid_line(irq);
+}
=20
 /* IRQ translation function for the device tree */
 int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 03fbb90c6c..7dd5a2a453 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -415,7 +415,7 @@ err:
 bool is_assignable_irq(unsigned int irq)
 {
     /* For now, we can only route SPIs to the guest */
-    return (irq >=3D NR_LOCAL_IRQS) && (irq < gic_number_lines());
+    return gic_is_spi(irq);
 }
=20
 /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:09:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:09:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116141.1462572 (Exim 4.92)
	(envelope-from )
	id 1uvvHm-0002Gr-DI; Tue, 09 Sep 2025 10:09:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116141.1462572; Tue, 09 Sep 2025 10: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 1uvvHm-0002Ge-8p; Tue, 09 Sep 2025 10:09:14 +0000
Received: by outflank-mailman (input) for mailman id 1116141;
 Tue, 09 Sep 2025 10: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 1uvvHl-0000yD-EH
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:13 +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 080b1def-8d65-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:09:11 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:04 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10: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: 080b1def-8d65-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IFnXnyC044293d5HarcTYfiD6Nj17po/M4zEOOimhiDdbMe830egJmNDbe84SUmXhMmlp7Vm1I6m7M0VMq9rIvRfKnOPYl0re9oH2ZyhsSQ2CaMhX9XrmSxrD7GGM+N9S6xhHfnOwqVw4cbQISEIg2MhWrO5+VIR1Gg8lguXRtunYc9MeTyjJTUoZ+Za24CNHTFu7Kdrqfu4kcTMrkMpN0CwyxVROyLaYnpCzNkur/bztt4mO/WQ1Je/XRj7+RJxzJXPDAsAiwt1aR8pJfRC0wAMYJBeG6TAgh3bfaPVoAkitcjo7PXxoqe7u6fN+cYXP6uAKk4VQ7ZAPpXMIuQ0rA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xv5ZWIsrcJ4zb7XYvjHbnGF/lBjKmuT3JyKBNigSOws=;
 b=jcAqF2RrWb7100MMCKrwEfzHr7ZxwKn0xQC+ynuTvOQPzJMCYq+jsyJGGwoMhW1IMOmEOk7uWWXIVSlTRbkCvIcxNjRHx1ypuH9wnaLR4de0EgPRoPz88cWdwt0EgtfQjVsvQCX/QJtz5EAHzaUgnQtZp83mYKrJeyJLuUBMS6roUTRFzh4xm2GJRUXYi/7iXv2/ndJ6ETA7AUlriSBb2IsW8X0Bu1g5TWDrjQHj9np16ZMHbLNiBhwwGx1nk9F4qBFcJjvmc8BVxPSXEtOVCOhZ3hAP49SqZD/2DPaDRt4R5PBmVwuP7UHYTVdGQxSNozpTGrrtTG9fzeVjIEYboA==
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=xv5ZWIsrcJ4zb7XYvjHbnGF/lBjKmuT3JyKBNigSOws=;
 b=Td1Mc4j8txDKfAam4k0MnjKJ71eeu/+QTVMHQ4dXR0AaLc40aGuAtt4BX4K9Z9BqYz9x2GGpXqfes0DpLquJqfY3BRMbjlwVFD0ptHOZyCrpGbSh4Igat3O/iXGIhtBycS7Kzn7rK/pSieFKiFO960KuUEYjFJ+rjldyW7fcnyeJKy2IX5l1zGWibRw+vOyqvvUbWyqGABCseYYYa1TXX6+7QjglHCOIzE5V5uyuFM4s1Sb7KxBr6W+INJsNJ/75DF4EmBIyKahfRE+7K5lpnJytZHKW2lp+6jF9HJSpF/sbhjnFopmQfAuNwjrjpz3nP962FqaVTiY5yc08ABZlAQ==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	, Volodymyr Babchuk
	, Julien Grall 
Subject: [PATCH v8 03/12] xen/arm: vgic: implement helper functions for virq
 checks
Thread-Topic: [PATCH v8 03/12] xen/arm: vgic: implement helper functions for
 virq checks
Thread-Index: AQHcIXHFOoWNA+Jrv0+WsW/ukByhRA==
Date: Tue, 9 Sep 2025 10:09:04 +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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: f7e14e74-db11-4f06-5232-08ddef88e814
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?PiFgSY1dSkoeCfVNHgUWJWVjy52YNzPN5ipVLTkCaq202XJPkjF6PFj1dt?=
 =?iso-8859-1?Q?NaJM+mnK4l4gkJX66+673NIUHr3nEkjT9kZLlr7YaYzckzAnkbAJvEmt6Z?=
 =?iso-8859-1?Q?7hbg+LmrAWIciK+zh51RD0gZ8lDsfU/RaHXTey9iNgKlQMzV2qXeTGXauf?=
 =?iso-8859-1?Q?ez7PzDbhEKTJ2wxd9/j9hAOzn4jv/aqJSIGnySGfZ2F/LL2e4RVo2kvJJA?=
 =?iso-8859-1?Q?ZQuRbGxgFHH09vO9mJGi735cY2+v7r/qCjaaXhjTg2ebit3T/2CxP0KSge?=
 =?iso-8859-1?Q?EAe8u0xjskpmMbtC5R7u6jhC7nixAGKiKdRrBLlIOIIDf813XSwIwqTRig?=
 =?iso-8859-1?Q?wlKRaFF4N9UXflxAhEgQHvZvdeYpIyWnMO9TIorEPQUTFuyZ8+RHXMlkmG?=
 =?iso-8859-1?Q?n3Rx1RaYcosRzlmDNITLv90DcJ9QcFVsg2OgWD/RL5ADEhjdUlwDO14UMJ?=
 =?iso-8859-1?Q?R8emaZMrejL6Db5dSfPvV6pOvvhdrKqeGgwnFf8Wvaz0p2P4BAF/7YkSoR?=
 =?iso-8859-1?Q?VaEsKXK3eAcKG9yQ3cWqBKxyknv960rK/w20Js6M14efB/gnQPWlZ1paOp?=
 =?iso-8859-1?Q?qJXph0fO7EE8XntJDm1XHmPQRUVUrJ1yXB1A4Kw9Id1uAY61SrUxzKkJkh?=
 =?iso-8859-1?Q?GQyLz+7l4rI1h7Sw/95xmxQL4yu2ii2uuizKIniAT1Zeaw7dqAM693RrWg?=
 =?iso-8859-1?Q?B6r6x0n3OvCrZkHfNrp1LIHPCrUqbyJx+mqsZ82BF3/sZKJTFCaFFbawG4?=
 =?iso-8859-1?Q?F9rDFs9zgM+e4KBPE+DBWCPCV6Pm3Ulb5lUVHH/ODShICWxNnF1XznN8O4?=
 =?iso-8859-1?Q?vM950hRMCvWBBx7gk0+dzylwWLorD2MaMFlSKmmspdWpy7plyC2ply33vK?=
 =?iso-8859-1?Q?ZlhbrGvtjHI7eLfrlU16YXrT4hFTikGu0KuKwRXnV6sCWSExIGILbIuu4M?=
 =?iso-8859-1?Q?pUfDicG9+JUzUutb9Ffu99GmMzVdfCPwIU31U1du0OOYJGk0ugT9Qo0ldp?=
 =?iso-8859-1?Q?9jyd0Ga16DMng8usBhq2i0zV8pkV+Q0b6pV+ICDGF+DAT0x0R+p9VVNkrK?=
 =?iso-8859-1?Q?teckTQxovtP6gQsw+0mhkHnCqrC7kIoHMDUcSi+ho9xvnJg1AeTKIcgL+m?=
 =?iso-8859-1?Q?YHnaBFLxRW0EWFiWD/xFs3JFiCO6zQrNNYKgxwxnJMeWNpMy2FtwjBkOqB?=
 =?iso-8859-1?Q?oP3LNGnHt+o05mEolr+kdPzx+CH1IQubh401gXZNH0PvWOgZn3wqLzzbKO?=
 =?iso-8859-1?Q?wi98T/ZclLXCgGlgWpUCdL+cPufNWukBvGxkR9qfoy58uGcaqsOIvCcdk7?=
 =?iso-8859-1?Q?NvCy1zZiQRK2DG9sn0h1x5gAZUngNub44o3Qkcmn8yortJbqFHP2lNUKea?=
 =?iso-8859-1?Q?B8dxRKmhIcbdXv1gXPRHcYs1Q4/ipLbVP6aVA4Yr+ndbpqIqpg+XBr2Q9Q?=
 =?iso-8859-1?Q?wbejJJjWgs3RmbBIn4ruLyXGIfOFmrMfFyWHb1eRmNSDDz4DISb6RIUNrn?=
 =?iso-8859-1?Q?n+9fSx/QLcj9qzoU9CvGexmYtxLkh5T75N2ddW3xRNTavCw+IpNgUrDuz4?=
 =?iso-8859-1?Q?Z/iygSE=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?0bTVJUjpEwy4hA65+8J9DXveYmh9jkh+HIm1+0wegLKdSU4FlkafX0W1Dg?=
 =?iso-8859-1?Q?AnAS/HUovJWlYjPJ7NGQQ5iaRstr19yewE3l+nk0wfEo4WnmsbcwFb0I/n?=
 =?iso-8859-1?Q?PRUJ7UptFS1Y6KiNV+mRGxwnPsIZPuR1fY2YJw8i1sJ4Y+q8vJ8qgz4Pff?=
 =?iso-8859-1?Q?Zf24cSXLPUBJ6+Y653BTxN0Pg26Q/jjdRa3NiTq2Zsg48PraIFxb/iIQ3/?=
 =?iso-8859-1?Q?cejxy3bJjDAp0El8zNg2hpSjvLo6skTeZ6mRvF+v8+ZQoByxPMGf+BpdQV?=
 =?iso-8859-1?Q?YIF4bPogHWvozeq1ERKfcQCDXggYCnapwY2QRGTdF7Im/naCPrK6v3o18I?=
 =?iso-8859-1?Q?8tymuWetNvSk6kt00ln0WESiLRu2gwQGBCJb2+g12zHI+Sb+9f0tiFXhoG?=
 =?iso-8859-1?Q?jhCCG8YbpcUwD3GnlVOF5YzdGO0UQPlFQvLR4ZeeB9QEp1JA785mpZ1kFz?=
 =?iso-8859-1?Q?E6KRx6T+3mbNJR7NdiQI7qeWihaMXEdw6/+bno7lVjihg8JDOVObAK1yCF?=
 =?iso-8859-1?Q?rDpivID0WWZiUKmuckE4OuBz/6tgwD1BeHltTrdKaxxtaQ7KV6e+gEobc2?=
 =?iso-8859-1?Q?uPkNYsy5Sz271aEly06WdESjLIb/6Ug9AwV+Nz6mjiQRa7asq4AQpI5aZb?=
 =?iso-8859-1?Q?94pjX7Pm2b8SOr9XDtuxM8H5z/o1g7JUGb3TVcS64v8IQ0fmqADssnC7rY?=
 =?iso-8859-1?Q?4dEDb2KnO3tFz5B6oTXWRYGcEZEpjfyzRQyYhdteRnJTdrJCuDoHbmCEpc?=
 =?iso-8859-1?Q?BTdzRCWv2sOXvIt/6F/oWkkAKqVLX9vKtJoIx/U9cJxdzznnst5rHEVdRY?=
 =?iso-8859-1?Q?Hzvq2NUDlrKtMZqEnBn0GyPNdR5earnHusbMwzyfUkklnmzy/qkI+w6R4p?=
 =?iso-8859-1?Q?uSy6xQJ+Ih+aDGfFON/OfdM55DdnD9Tmt2fR19mSfnC9ZBqutBR5X8MFI/?=
 =?iso-8859-1?Q?tjOL7lkSjSA2c+bFmfN/CSvaeTwf2PzsaReHq39EQUd849NqalR1dI/vwB?=
 =?iso-8859-1?Q?XTDQ0IjLao7Cc1uwO32VdBE+M80x8dpdKzyC5Ndgvu3ebOuh1jvvnan+v9?=
 =?iso-8859-1?Q?nMTTV9drFPWX0xorSez49aPRgIyDW7wgperZKdoKmBkL4CMThzCzFStZBc?=
 =?iso-8859-1?Q?XcDmeojqBUavVv0B+seCw8mzNanNN4Oc9ccCJl48zVHbQxyMYA6RzYLnTX?=
 =?iso-8859-1?Q?xYnzY8gQz4hqrC92Z6ID6F1nFsSaf5zIzoO3vO5nCL20lTIvW4AfZeCgUx?=
 =?iso-8859-1?Q?LN9XkYGkmfYIsj+dUXn84CKGNoMWr4yOsIdtKnDWWivTTIOEF2vWnrq3N/?=
 =?iso-8859-1?Q?tCBBp6G/790KYMUv0K2G6SJ8eohdTA27qr1NTLutRfyMqG6a1c6Q7tIw1U?=
 =?iso-8859-1?Q?FZslRGPS6821w/Rl+PJcHCnPh+ObQJbkcS4RpaVmPj9qDEfPlbAgoy22Al?=
 =?iso-8859-1?Q?XpXhym/MJyU36mT61kWAbWcjB0zFiC6QXdv8fCJOHEDX0kcK5Z0YOr+qGv?=
 =?iso-8859-1?Q?1gMM32MD8oz2tpsVRC808RjNSB0KYI9XF9Hyl0lNWUc6RdOvyF5pf8Nmop?=
 =?iso-8859-1?Q?2RMy7g5y/QavIAtUw0yxX6BJo06k3P6Lh4D7nWh3iDjbceN9ig0MMcgV5D?=
 =?iso-8859-1?Q?KyN3Ojbly2bPHRVky2EYZieqAWgYtuQ0a+SIn7J2EB03VouR7GTTtq7MUy?=
 =?iso-8859-1?Q?LLPzgL6wJdvuvnIxWCQ=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f7e14e74-db11-4f06-5232-08ddef88e814
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:04.4505
 (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: nx52c8qtqhIHrRJI19+eHAZjyPHm5q5GF9R11nCi/028TsLshohcr/3Jv4BSVeK46qwdj7MfwEWKROuLf17ZY0AeI1/cWl8uWogN8oJ5kzI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

Introduced two new helper functions for vGIC: vgic_is_valid_line and
vgic_is_spi. The functions are similar to the newly introduced
gic_is_valid_line and gic_is_spi, but they verify whether a vIRQ
is available for a specific domain, while GIC-specific functions
validate INTIDs for the real GIC hardware. For example, the GIC may
support all 992 SPI lines, but the domain may use only some part of them
(e.g., 640), depending on the highest IRQ number defined in the domain
configuration. Therefore, for vGIC-related code and checks, the
appropriate functions should be used. Also, updated the appropriate
checks to use these new helper functions.

The purpose of introducing new helper functions for vGIC is essentially
the same as for GIC: to avoid potential confusion with GIC-related
checks and to consolidate similar code into separate functions, which
can be more easily extended by additional conditions, e.g., when
implementing extended SPI interrupts.

Only the validation change in vgic_inject_irq may affect existing
functionality, as it currently checks whether the vIRQ is less than or
equal to vgic_num_irqs. Since IRQ indexes start from 0 (where 32 is the
first SPI), the check should behave consistently with similar logic in
other places and should check if the vIRQ number is less than
vgic_num_irqs. The remaining changes, which replace open-coded checks
with the use of these new helper functions, do not introduce any
functional changes, as the helper functions follow the current vIRQ
index verification logic.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V8:
- no changes

Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- added reviewed-by from Oleksandr Tyshchenko and from Volodymyr Babchuk
- added acked-by from Julien Grall

Changes in V4:
- removed redundant parentheses

Changes in V3:
- renamed vgic_is_valid_irq to vgic_is_valid_line and vgic_is_shared_irq
  to vgic_is_spi
- added vgic_is_valid_line implementation for new-vgic, because
  vgic_is_valid_line is called from generic code. It is necessary to fix
  the build for new-vgic.
- updated commit message

Changes in V2:
- introduced this patch
---
 xen/arch/arm/gic.c              |  3 +--
 xen/arch/arm/include/asm/vgic.h |  7 +++++++
 xen/arch/arm/irq.c              |  4 ++--
 xen/arch/arm/vgic.c             | 10 ++++++++--
 xen/arch/arm/vgic/vgic.c        |  5 +++++
 5 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4bb11960ee..9469c9d08c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -134,8 +134,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned i=
nt virq,
=20
     ASSERT(spin_is_locked(&desc->lock));
     /* Caller has already checked that the IRQ is an SPI */
-    ASSERT(virq >=3D 32);
-    ASSERT(virq < vgic_num_irqs(d));
+    ASSERT(vgic_is_spi(d, virq));
     ASSERT(!is_lpi(virq));
=20
     ret =3D vgic_connect_hw_irq(d, NULL, virq, desc, true);
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 35c0c6a8b0..3e7cbbb196 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -335,6 +335,13 @@ extern void vgic_check_inflight_irqs_pending(struct vc=
pu *v,
 /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
 #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
=20
+extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
+
+static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
+{
+    return virq >=3D NR_LOCAL_IRQS && vgic_is_valid_line(d, virq);
+}
+
 /*
  * Allocate a guest VIRQ
  *  - spi =3D=3D 0 =3D> allocate a PPI. It will be the same on every vCPU
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 7dd5a2a453..b8eccfc924 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -442,7 +442,7 @@ int route_irq_to_guest(struct domain *d, unsigned int v=
irq,
     unsigned long flags;
     int retval =3D 0;
=20
-    if ( virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_valid_line(d, virq) )
     {
         printk(XENLOG_G_ERR
                "the vIRQ number %u is too high for domain %u (max =3D %u)\=
n",
@@ -560,7 +560,7 @@ int release_guest_irq(struct domain *d, unsigned int vi=
rq)
     int ret;
=20
     /* Only SPIs are supported */
-    if ( virq < NR_LOCAL_IRQS || virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_spi(d, virq) )
         return -EINVAL;
=20
     desc =3D vgic_get_hw_irq_desc(d, NULL, virq);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index c563ba93af..2bbf4d99aa 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -24,6 +24,12 @@
 #include 
 #include 
=20
+
+bool vgic_is_valid_line(struct domain *d, unsigned int virq)
+{
+    return virq < vgic_num_irqs(d);
+}
+
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)
 {
@@ -582,7 +588,7 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, =
unsigned int virq,
     if ( !v )
     {
         /* The IRQ needs to be an SPI if no vCPU is specified. */
-        ASSERT(virq >=3D 32 && virq <=3D vgic_num_irqs(d));
+        ASSERT(vgic_is_spi(d, virq));
=20
         v =3D vgic_get_target_vcpu(d->vcpu[0], virq);
     };
@@ -659,7 +665,7 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr=
 hsr)
=20
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
-    if ( virq >=3D vgic_num_irqs(d) )
+    if ( !vgic_is_valid_line(d, virq) )
         return false;
=20
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 6cabd0496d..b2c0e1873a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -718,6 +718,11 @@ bool vgic_reserve_virq(struct domain *d, unsigned int =
virq)
     return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
 }
=20
+bool vgic_is_valid_line(struct domain *d, unsigned int virq)
+{
+    return virq < vgic_num_irqs(d);
+}
+
 int vgic_allocate_virq(struct domain *d, bool spi)
 {
     int first, end;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:09:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:09:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116144.1462582 (Exim 4.92)
	(envelope-from )
	id 1uvvHr-0002ee-RT; Tue, 09 Sep 2025 10:09:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116144.1462582; Tue, 09 Sep 2025 10:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvHr-0002eQ-No; Tue, 09 Sep 2025 10:09:19 +0000
Received: by outflank-mailman (input) for mailman id 1116144;
 Tue, 09 Sep 2025 10:09:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvvHq-0001My-EZ
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:18 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0bb086af-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:17 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:11 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 0bb086af-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YpdVPZseqiZb+jjjCmdhSOSUKkKUnoQB7hOYBSiWtFt2QpA0IFYKXov6mha4LvYecu18cA32W6o4tvglZMxP2AcOObUQ/EngQtwiNTH+/Mkp7KbV25j1jjHfM37BtBgBprPdKk9J9QWvI/R3iezuJ68IgF43PQr9OndILzHiFJ0vUAwXVR7DFcJlQMgMiEG7weBF0GELlVbA0R8gJl+9Z1OEaJdhih6+ounPJGmqNcjP7nDGtKNZLTGiVBTXoea6PO/wRZDNTzMOKC+OjsgOlpfiz+Zky6XxBz5I9KHdpxhdmTM0Rk7Yw0e/exPWzYnogzB7TnzoWX5Fp1l7bKyuYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/4PYhi77IQgahxEQTGPMvFa33vUCsdzd8Q2rC0SD60M=;
 b=nNDO4Mndavx8auNyc5cxs5fG8MOcapr6C1PrOjeYwrJYrtq2wRmrUzuqK41i2qSdspn22pTgk9RhaSdXdjzlRdIezRahnrqBq3nqBOV41r5ke49eWZW6arsf6T2omgWPUGjvjeYBP9ObOZxN37zNlrZJ+dRXn5VQY1P9kwn0FPwDkCzVoMZdt2tPJ0kVTQkl7+CBTnbOoG90n3PTnv3ExB2GoFn/wMhZiILI9CvBkB676YcmWKxpwhC0uedwVPwjZJ250nbOnaHSjqNlLmquQW5tTQqXjPw12CZn1lNItlcx/VnwIYUTsPIUeRit0S2wSBUk79bF6SoLAOOa9CqLRA==
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=/4PYhi77IQgahxEQTGPMvFa33vUCsdzd8Q2rC0SD60M=;
 b=DlqRnzhKdTwkqtpKyBwK0wm4rDiwiefLyLb6shumhhF83aIc4DoD3YWUklTM5b21coArLMUYj5sH7cYsTM0qr1ufMHoYrV93ae6MtNAJVQG1uOIXEYtXsI3xcXGKjvyX1jlxLlPZzzdimjsa3ggyI94VkNJeDEiCodwA4R3QN8EO4TxP8Ad2ESvDfznR9FOi16w6HWM3iQ3NqHic9aZbaIW9me102soNYjlp7aJR3ihVeeCsC+pTjrjk+dZkbDR6PLID1r1zRHQQx18GwHgAshOsp/QUc9uIg+8FYEkdniaaM4QtqrUqYKEK4Aq0hZ4wT/8il/trVr5xLwO/AdRPQw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko 
Subject: [PATCH v8 04/12] xen/arm/irq: add handling for IRQs in the eSPI range
Thread-Topic: [PATCH v8 04/12] xen/arm/irq: add handling for IRQs in the eSPI
 range
Thread-Index: AQHcIXHJOikwNnexEE+HQmODShsy3Q==
Date: Tue, 9 Sep 2025 10:09:11 +0000
Message-ID:
 <6e356dde3a90bff04bc3a8ec0a3a490780f55e0d.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: 5c274eff-0147-4b8d-e507-08ddef88ec2f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Il8JF79mDwfX4ku2zNHNf51fVG5B8tZci+BBkTwK1J+Z5GO8Tc/hg8/n19?=
 =?iso-8859-1?Q?PjvpKO14/zHd2Z2eAGzL/TTbom+L0w9nXvV58HWWL10S1GZIyuO1hN0I1A?=
 =?iso-8859-1?Q?T8S2LiTv/MO/jhvmKyjKbmA8rIRWQq7ZTTbdwPA7Pz6CXcwU6LNOpmcVOj?=
 =?iso-8859-1?Q?uOcyOQKJllozQUcJwkQ59fwCpc5DKkN/b8RnmVSurP8uGRAPNS7lLC199s?=
 =?iso-8859-1?Q?lV6shwvxVg7+71LFYuKztoW+4T/1AF41KxzLR7B3WijdxYBsPvTqyAetZ4?=
 =?iso-8859-1?Q?aN5nGFJXX+0eLt0wzJ64STEIkMYmfxC2iTvWJwe8+98EwmYFYNVDIEzGew?=
 =?iso-8859-1?Q?sUtuiWsH6KQe8bb5sZubgOQq7RE4NsGypNLNOdw61h57hGum/Fo7owpaDx?=
 =?iso-8859-1?Q?xfXziJ03fwzDhEDvt5hZnk9iTUn+dsQsf9BYUeb2lqfRKLEtO8gBTh6Vld?=
 =?iso-8859-1?Q?PV6B3k31iT1dNmm5NJaxFA6LxxqLX2kF6MPrZmwW/pdAbMzGM5pyRkkbwE?=
 =?iso-8859-1?Q?2Y2S7/sTHqzhBSWT0+ae639ghUqa5eRXpqXogkK5KroYhukXTSnHtyeTg2?=
 =?iso-8859-1?Q?T0uC1i9Ln50LgzG5oAZljzSEdBTfYcm7YtpMVDyyWwDwDuglBVXeScgHum?=
 =?iso-8859-1?Q?ZD2t4HiDTx4o3J86ncG9q0sZwanbx70F7mgbgUP8GUZ+DSorhkK9H0Bfqk?=
 =?iso-8859-1?Q?RKj3bzILJMQGNapYdCwUyNE7jbXpEIyVyl/ACxwkvRxRr5JA+4Uut+ghXc?=
 =?iso-8859-1?Q?idYc7EGysfnXU+qYdt1jENFKl7VFtCJbrMPX3daZtchPprq93Lh9L5K0+v?=
 =?iso-8859-1?Q?QI1LkVziuw8QIyOdqnXTAJ7PKxkbgvW4s6A54oi+0DU1ImRnsckvhjNv9N?=
 =?iso-8859-1?Q?X5/S0lKXKk+nOGHSBd2J7Y9BuINYjvEosfeMlcK80MmmoZK6e9M4Xk+QZG?=
 =?iso-8859-1?Q?2tcrie/rN1UfQsTe9/DvBwSZFjBoT8tlFuIQLzNgrBFtuwY0GOzddliKEV?=
 =?iso-8859-1?Q?MT0D4323dsDDI17lgv9w5rTfUzFu3QLv/dxUdyLK9EYbo4tM4IzxlFR76n?=
 =?iso-8859-1?Q?Haw3EmGASSKC3JKatoIMZ363WLKEDODAW4pHgGsBuJ3PKyMjZ/EmauRrzs?=
 =?iso-8859-1?Q?2dmW6RuyqiG+DrQxLcOj9IuxRph8l4KD4LeivuHXAseNhVk3zHPrS/WtmM?=
 =?iso-8859-1?Q?Z9BOhV/rhDz/EfJO1055tDGlKur9TlL3FYejQoB8lc1q0P+uZ0AC5tqWRi?=
 =?iso-8859-1?Q?8Xhc2DlE9UjpHUCEiGQvGZoemfqf6kFM6APZ9hscoqAWz7MlXGaPhMB9l5?=
 =?iso-8859-1?Q?/pO2VwmaIud6MmHdRVckQ/2R704PbcU3GsDxjf0Ftp7VJxAm3kpX4ZiYZi?=
 =?iso-8859-1?Q?4Q/x9E0tJHYfbzXx0mS1S5HnOhOMJHvki9I5+fzvwzp7op5Mub6u/3UUbT?=
 =?iso-8859-1?Q?SJ1RdcUIQ7J3HIlsZ4QsmA5mnEcG1eWB1iYVfeeraltPRnQXupogiH6WWk?=
 =?iso-8859-1?Q?zP2MNX6oKFexb/b7iIUu/Kk5P933+sfraCksWbMHDJl2Y/fRITYDDCQWAk?=
 =?iso-8859-1?Q?6/XgT0k=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?wrMFG8Rqi/tmDNRGpp1Hj+VWl27Et5p/PvdEX5w+6hsf9iqmR1oLGolocS?=
 =?iso-8859-1?Q?Nulw+2NaM9yOnpF2yA+RHAckBNA8Cn1I8d7Lg4s2SpIxn7wWib/MEX9NF0?=
 =?iso-8859-1?Q?KaE5kana0sHFHsvP8HLfRHsxWJYzp1eBzFpEp+M5K6NAP9S8j1PipgOiWJ?=
 =?iso-8859-1?Q?fF+bl3dLhiox+Kh/lNAiiDrriLR4H1GCkvDVhjMKKPpdCnZoSlFnExllZK?=
 =?iso-8859-1?Q?yIcHKW0ifuXtTHhZb2rycv6Da6abJXt3kzR7gaFVRq1mdiwLVSXRMLWtgV?=
 =?iso-8859-1?Q?/QywzHzdu3PSJ+/pvXTauZDiMhoyOHXIgPo0urozE3AYm95p+NnEm6JkJm?=
 =?iso-8859-1?Q?IGeMBM8SPEcQSn5blIGr4IH61DIztrQ6IkAa4+fTX9cS7Wo/K1bIwveWiO?=
 =?iso-8859-1?Q?Af+Zy+mbyGd9liLKkeHXuoFnKnfCzzac6ZxyimXwbBxgERKBIq97DdljAB?=
 =?iso-8859-1?Q?k08e+ER1sAIE2RCyemBntV9qbARpP1TlhTfofzas7b18yWoywXU9Y4xNig?=
 =?iso-8859-1?Q?OVsyQ/yIkijx08wxh9EHRXSNr2o0trVxMzZ8qGDO3LsqVlFGq0axhA1s1Q?=
 =?iso-8859-1?Q?A0NgXL7TdVT+twrK7E9EmFNyPpGJK6OfZLKyPtOuznqbENMq+qe2Aal7ML?=
 =?iso-8859-1?Q?TwUesVPq1vrQohqLaLcAms9cz45TfPW2NsO39evbAJR2ZRgoOWln4GLTG+?=
 =?iso-8859-1?Q?ho2/brhxQH9FXTxYV78Z7/g1jDCZhsXn3eYYtgH9igkrHpFbhU2wMEBWLz?=
 =?iso-8859-1?Q?A956ph2qWHZ8GWswWuriPuRsnQWwr25gR/XFPoMCiLAg0ChQuO68AbuuT+?=
 =?iso-8859-1?Q?OMr1hSF52D9aeCDRGjI/fdTFvReW3EV5bfQJfOsik1TUdGp/GVwdI/AfkA?=
 =?iso-8859-1?Q?XOiNbvJeon6r4J6S0Zy1oLzuoo8giKwjTaT5BqLKofvhFKaHBtrvdStAX7?=
 =?iso-8859-1?Q?Lld5WqgNdfBEEyJHjfiJ7zIHxAyY/yhoY7LBY8BrR3fP+htukH54EWq+uM?=
 =?iso-8859-1?Q?IHrVFhfcYQqUeK8dXhoJT89SXAHNHqQvTq193ch+FUWYT+dlS6D6QKt5xM?=
 =?iso-8859-1?Q?Av+wTeIbNvVgJLqboNid4eDTqqyJ+Lad96hxTXT3toTVR0h0CyjnFICxqd?=
 =?iso-8859-1?Q?Vskkv0afABb1R4S90LoMAfTqVyTAni2RnoTyShVmUbfb7l+a5rRULzcF+S?=
 =?iso-8859-1?Q?HhQ1r5oMtChR8XIAA9MC6LI0dTcrV4sjShbMYtkCWWsyetvbPN5qAI+xiB?=
 =?iso-8859-1?Q?ABjrWALm2u/qVpfHX4aDvtsFCZqnNhxtOc8pYzDBFfd3XbELTC5TMo+0MM?=
 =?iso-8859-1?Q?YxpmyvWFlkSAtaDFb7q6HmXiDmFwx4NrbFhOC3sGxGmwfpukgQx6gEaeyn?=
 =?iso-8859-1?Q?rKHvcOLqgSS7eNzvfZO3CN6gGeexLEM/tAOdVaitiS5zy/1Qg6ZWvMpFos?=
 =?iso-8859-1?Q?0IztBqz983B8KfRWHNiUmkAuxMgCtdAy19tMT6iVj7C4Jf+oF4CMDl25HK?=
 =?iso-8859-1?Q?DYiVUhpDmTcXGb6xH05kTFpcYjNRbE+GyhWtFlK0ZOugoe/QC6VNHZsKT+?=
 =?iso-8859-1?Q?BEBUEp2Gg3Z9tnXSZPGDgP0hlbvVc8gNP1zAYB/aaGF/3+QR6aCbrAjY8r?=
 =?iso-8859-1?Q?WqJnY0Gij3VZt6ViZX5EDY7SXz2yUVsFYDAIC8ZLYKqNuwSNPfcnae6tsD?=
 =?iso-8859-1?Q?RiR3cgCG2RwixZOi260=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c274eff-0147-4b8d-e507-08ddef88ec2f
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:11.3354
 (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: +hD25DzUOQr2gMuzeT2+FKg4O7Pj6N8otL/cDPyR3qsu8PJKyOXf3pYIyKFHQ5x/B4PBYUqmo51m/Lys0X5skoUlS9/U/nLnyG+yeS6/1RQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

Currently, Xen does not support eSPI interrupts, leading
to a data abort when such interrupts are defined in the DTS.

This patch introduces a separate array to initialize up to
1024 interrupt descriptors in the eSPI range and adds the
necessary defines and helper function. These changes lay the
groundwork for future implementation of full eSPI interrupt
support. As this GICv3.1 feature is not required by all vendors,
all changes are guarded by ifdefs, depending on the corresponding
Kconfig option.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 

---
Changes in V8:
- minor: fixed typo (s/asignmant/assignment/)
- minor: removed the non-relevant part of the comment
- fixed MISRA caution of 18.1 while moving is_espi() check under
  #ifdef and as a result avoid caution with overflowing index.
  Also, removed prototype of espi_to_desc() for builds with
  CONFIG_GICV3_ESPI=3Dn, as it is not needed now.
- added reviewed-by from from Volodymyr Babchuk and Oleksandr Tyshchenko

Changes in V7:
- fixed the condition in the is_espi assert for non-eSPI builds: the
  previous condition was mistakenly added with a wrong check and led to
  triggering asserts for all non-eSPI INTIDs, when it should be triggered
  in this case in the other way around
- minor: used is_espi() in the espi_intid_to_idx() ASSERT, as is_espi
  performs the same verification

Changes in V6:
- added an assert in is_espi() when CONFIG_GICV3_ESPI=3Dn to ensure that
  out-of-range array resources are not accessed, e.g., in __irq_to_desc()
- removed unnecessary parentheses in is_espi()
- converted helper macro to inline functions and added sanity checks
  with ASSERTs to them
- defined espi_to_desc for non-eSPI builds as a prototype
- updates the comments
- used the IS_ENABLED(CONFIG_GICV3_ESPI) macro to initialize nr_irqs

Changes in V5:
- no functional changes introduced by this version compared with V4, only
  minor fixes and removal of ifdefs for macroses
- added TODO comment, suggested by Oleksandr Tyshchenko
- changed int to unsigned int for irqs
- removed ifdefs for eSPI-specific defines and macros to reduce the
  number of ifdefs and code duplication in further changes
- removed reviewed-by as moving defines from ifdefs requires additional
  confirmation from reviewers

Changes in V4:
- removed redundant line with 'default n' in Kconfig, as it is disabled
  by default, without explicit specification
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- introduced a new define NR_ESPI_IRQS to avoid confusion, like in the
  case of using NR_IRQS for espi_desc array
- implemented helper functions espi_to_desc and init_espi_data to make
  it possible to add stubs with the same name, and as a result, reduce
  the number of #ifdefs
- disable CONFIG_GICV3_ESPI default value to n

Changes in V2:
- use (ESPI_MAX_INTID + 1) instead of (ESPI_BASE_INTID + NR_IRQS)
- remove unnecessary comment for nr_irqs initialization
---
 xen/arch/arm/Kconfig           |  8 ++++++
 xen/arch/arm/include/asm/irq.h | 37 +++++++++++++++++++++++++++
 xen/arch/arm/irq.c             | 46 ++++++++++++++++++++++++++++++++--
 3 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 17df147b25..43b05533b1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -135,6 +135,14 @@ config GICV3
 	  Driver for the ARM Generic Interrupt Controller v3.
 	  If unsure, use the default setting.
=20
+config GICV3_ESPI
+	bool "Extended SPI range support"
+	depends on GICV3 && !NEW_VGIC
+	help
+	  Allow Xen and domains to use interrupt numbers from the extended SPI
+	  range, from 4096 to 5119. This feature is introduced in GICv3.1
+	  architecture.
+
 config HAS_ITS
         bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORT=
ED
         depends on GICV3 && !NEW_VGIC && !ARM_32
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index 5bc6475eb4..09788dbfeb 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -32,6 +32,10 @@ struct arch_irq_desc {
 #define SPI_MAX_INTID   1019
 #define LPI_OFFSET      8192
=20
+#define ESPI_BASE_INTID 4096
+#define ESPI_MAX_INTID  5119
+#define NR_ESPI_IRQS    1024
+
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case.=
 */
 #define INVALID_LPI     0
=20
@@ -39,7 +43,12 @@ struct arch_irq_desc {
 #define INVALID_IRQ     1023
=20
 extern const unsigned int nr_irqs;
+#ifdef CONFIG_GICV3_ESPI
+/* This will cover the eSPI range, to allow assignment of eSPIs to domains=
. */
+#define nr_static_irqs (ESPI_MAX_INTID + 1)
+#else
 #define nr_static_irqs NR_IRQS
+#endif
=20
 struct irq_desc;
 struct irqaction;
@@ -55,6 +64,34 @@ static inline bool is_lpi(unsigned int irq)
     return irq >=3D LPI_OFFSET;
 }
=20
+static inline bool is_espi(unsigned int irq)
+{
+#ifdef CONFIG_GICV3_ESPI
+    return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID;
+#else
+    /*
+     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI =
is
+     * disabled. Returning false allows the compiler to optimize the code
+     * when the config is disabled, while the assert ensures that out-of-r=
ange
+     * array resources are not accessed.
+     */
+    ASSERT(!(irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID));
+    return false;
+#endif
+}
+
+static inline unsigned int espi_intid_to_idx(unsigned int intid)
+{
+    ASSERT(is_espi(intid));
+    return intid - ESPI_BASE_INTID;
+}
+
+static inline unsigned int espi_idx_to_intid(unsigned int idx)
+{
+    ASSERT(idx <=3D NR_ESPI_IRQS);
+    return idx + ESPI_BASE_INTID;
+}
+
 #define domain_pirq_to_irq(d, pirq) (pirq)
=20
 bool is_assignable_irq(unsigned int irq);
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index b8eccfc924..80befc2913 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -19,7 +19,9 @@
 #include 
 #include 
=20
-const unsigned int nr_irqs =3D NR_IRQS;
+const unsigned int nr_irqs =3D IS_ENABLED(CONFIG_GICV3_ESPI) ?
+                                        (ESPI_MAX_INTID + 1) :
+                                        NR_IRQS;
=20
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
@@ -46,6 +48,41 @@ void irq_end_none(struct irq_desc *irq)
 }
=20
 static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
+#ifdef CONFIG_GICV3_ESPI
+/* TODO: Consider allocating an array dynamically */
+static irq_desc_t espi_desc[NR_ESPI_IRQS];
+
+static struct irq_desc *espi_to_desc(unsigned int irq)
+{
+    return &espi_desc[espi_intid_to_idx(irq)];
+}
+
+static int __init init_espi_data(void)
+{
+    unsigned int irq;
+
+    for ( irq =3D ESPI_BASE_INTID; irq <=3D ESPI_MAX_INTID; irq++ )
+    {
+        struct irq_desc *desc =3D irq_to_desc(irq);
+        int rc =3D init_one_irq_desc(desc);
+
+        if ( rc )
+            return rc;
+
+        desc->irq =3D irq;
+        desc->action  =3D NULL;
+    }
+
+    return 0;
+}
+#else
+
+static int __init init_espi_data(void)
+{
+    return 0;
+}
+#endif
+
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
=20
 struct irq_desc *__irq_to_desc(unsigned int irq)
@@ -53,6 +90,11 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
     if ( irq < NR_LOCAL_IRQS )
         return &this_cpu(local_irq_desc)[irq];
=20
+#ifdef CONFIG_GICV3_ESPI
+    if ( is_espi(irq) )
+        return espi_to_desc(irq);
+#endif
+
     return &irq_desc[irq-NR_LOCAL_IRQS];
 }
=20
@@ -79,7 +121,7 @@ static int __init init_irq_data(void)
         desc->action  =3D NULL;
     }
=20
-    return 0;
+    return init_espi_data();
 }
=20
 static int init_local_irq_data(unsigned int cpu)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:09:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:09:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116155.1462592 (Exim 4.92)
	(envelope-from )
	id 1uvvHz-0003JU-3A; Tue, 09 Sep 2025 10:09:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116155.1462592; Tue, 09 Sep 2025 10:09: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 1uvvHy-0003JL-W7; Tue, 09 Sep 2025 10:09:26 +0000
Received: by outflank-mailman (input) for mailman id 1116155;
 Tue, 09 Sep 2025 10:09:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvvHw-0001My-U0
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:25 +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 0e769569-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:22 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:16 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 0e769569-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Bo4J9qJQhJp7Hnqaqm8Xo+NCzo8HLwm2doy1rvo4VPOJSV+Eo9/Wd3Q8r9MK38JNWgt3sQlhhr91/ewR3CUv7tWQOhuu+Ig1/eE/P7tAvRohbnoq8kxGGnoffxqUT5d0f912X+pNDjy0wZ4IMIYetJAxZTeArNxF8o7o5uhE0mlfRgWFLxZj5LC0xiCYver6b5m9X9IQMhVAlAREpq7pvXyoUxe/buVQ3/fRSXoBo5yD6jGlg4sti4i/esqPqx4o17PVLxtUwt3nbktcxDMZC+4PZRgOJeSwtSLQ86D0YoXdN0ZkFwatmp0k5PYczQLgRkL50Gh6gzfJOdZxgZtACw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=77VmsMWkYw2kko3f++NVL2YCmHBnjCG/xskj3x8x9yg=;
 b=FE1gIM4vRZ9oEaZDRWBioNHHSbf290THqdkh/E1cPu3hELmxZXY2TBfQJuZJDWKARV3lBmiM8zOgdvRjXDJ2KeDa+iVxg2dnnyAwNA570q7cQEIMRuz/2sajH+GmhPhpqUTLqFXT4ZOb39pIPJt4MhaDosuY4iGIaU9kyJBvfV1TFEX9I+3QvbAxhlvpUCja/XBmdsGX/aYr1tFCYau32TeZL9LvHovfcieUPOJZXzGaxfOws+354t/qvddDorTvPW19G8YQe20rg3ApR+Np++GTL3o65cJCpIRwLSQ50cig5yPufrr1Wr6aBquUp+G5IKJGmh3K9T+9hicKMTQijg==
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=77VmsMWkYw2kko3f++NVL2YCmHBnjCG/xskj3x8x9yg=;
 b=iEZaeXttR9Np5RriEp0FusLMr9ebLQ5DTMqvRisWsmJ6vvy5Rc3OUyp5lCJjwUj4tO93OUB3RBF44GAIxWTSyoMVXSN8n+ZbdQGVu5ELe9rInGoax4lPQil5ExiXBG1qjBURvACIV4vywYJrlklC9Z2+WSTuiWt38PJY3UHT594RXwzwovJJSggfPHR6cEWjjBmksK8qit4JRV1c+gifGzvEEP6Xk1XSgmdROVW2ad0KAxsjd99h6TqAA3WUii1gU5ja1DF/3AuuVQMkVE1YmMshJMcMNFeXg2HL7cLeGsbMJxGHrZjih7oEelfJ5TPSK+5re6pfDiFd3lZ/RMzuqg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	, Julien Grall 
Subject: [PATCH v8 05/12] xen/arm: gicv3: implement handling of GICv3.1 eSPI
Thread-Topic: [PATCH v8 05/12] xen/arm: gicv3: implement handling of GICv3.1
 eSPI
Thread-Index: AQHcIXHMU/gntH9UQEOAUqiND1Mh1A==
Date: Tue, 9 Sep 2025 10:09:16 +0000
Message-ID:
 <186b85b8c01eef4b708397f369e6b2c886c6ae61.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: 9dbdd22a-f338-4d83-ee08-08ddef88ef5e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?dUqQDaybj2o9fFLX1Jl26dYGgWuWYnZKwJwDpTfeI4v9H2qtWAgOQMh1Qw?=
 =?iso-8859-1?Q?0rxBXWMgZrhjCnyrCpFOoNIcgIDC5acLsAuSmsep+QY/zFcg5iO6yIVcLu?=
 =?iso-8859-1?Q?gEXHnHaJTcsybBhSYHIaloFZ1jZiIUuEUHD1BFZXff4mAU42rSydnSZk1X?=
 =?iso-8859-1?Q?aeWUHq5HA/Thr5GQpI91jkfpfDgdgUZH8U42hPmZVEgxKNlYY16R4pOpn3?=
 =?iso-8859-1?Q?xit0QWMtaZP1/xnkLj2xVCAap+OViweubXJZdyVgIRhTlUk7KbPmPMBzW1?=
 =?iso-8859-1?Q?lBzr7ZuORij4bBibAqYDKkT4gIcXQOFamkuzCEtqCYLLIvAoB8eaf6uVdy?=
 =?iso-8859-1?Q?hBYcWpvlKHcow0X+7y3W0/Bm/hrJa/xlI6q/GYoTPXSwFe1/seis0ZTq4W?=
 =?iso-8859-1?Q?DtCVO7pwPSza/EkcGoIlRfesYKePYT0w/NKxk4gRU9buKqpza28MVVDIwz?=
 =?iso-8859-1?Q?VZe+/BvIvrKRK3aVnKZuHtUte8vJY7PZY67/DPdO+ynL0RJ0LIX0lg8J6k?=
 =?iso-8859-1?Q?uBoowU1e1LG07Ll9TcEFHX4U5yRhqcXeY5XUrXLAnSnnSBWWZeZ/sFpHpa?=
 =?iso-8859-1?Q?4ewaw9LhPIa7y4/O3DXWc7S5+qXdHL1j0MD7SJmI22JIzElYvmc6cXWRiG?=
 =?iso-8859-1?Q?ZuNaHX4yPHaAAVFJ9i2jOKQgicEZg9NL1Xo2WiqWyFsGmQjHWSwAAF7CGn?=
 =?iso-8859-1?Q?fCdlm1wCtsIucaMoLtLPk63TXb3Ja7MNzir6SLlbgJt95kq+ta3/gKj3hJ?=
 =?iso-8859-1?Q?oruErS/vrxv2WDhttqningtRAjVX648iF2E8OZcFssjBAxgJzd1UHR9ATE?=
 =?iso-8859-1?Q?jE6zoDSI3TOGuFKoeTYycNrwN4bBrHDVB8JAwXqFkvVzUISF6rNtUP1iTr?=
 =?iso-8859-1?Q?4HceCSMP8gi9qmuaFL7dnrfBeNuMW8GwT8kwmMkLGiVVw6SpeuNwFPUbVR?=
 =?iso-8859-1?Q?1gFZA4NQoEO7dtMHWzpi0G+nh2z3RkWPBJDAPgnE5wd9Xb6mtc7bDkchnP?=
 =?iso-8859-1?Q?2rX/d82vNf9deJEDh3Vw0WCIihZqYXSjJEBGsIxIYdatcHJcZIGpzKjkaA?=
 =?iso-8859-1?Q?LHo+or+N7L06q4645gIM/dGSDFlPBJ436JBhMF3KYwqJigyXdTThCcnrww?=
 =?iso-8859-1?Q?B1aP7KUBFVz+iZDSCAE0jKz84OYMTODYz1tgpH/ktMso8CyqF+oTowpwDW?=
 =?iso-8859-1?Q?SHxotw28y+dwmKAT0Tv+5U28rl1JA/qNDIDFFzRg3UYtfA6BWF3oD1rpXf?=
 =?iso-8859-1?Q?BUha3Q14xXWgUEV/EtyuQ4LHUouo/+u6np5Neyq0MWd85PoGi88dbBqKKJ?=
 =?iso-8859-1?Q?CUZDArIM/XHZysddTlcYSvlhB2L0zM5afg0NxS01Sz+nYx6v5GV6eHe5ON?=
 =?iso-8859-1?Q?TeFhbz1SZb7s/8FzCUpXca1WJmGxVhORSeRSD+w0QtxNR6kkj+8lNO8G9D?=
 =?iso-8859-1?Q?y4GDtno5EHzHgeqM2/txfU3ZVt4g1b8SwQCCjeVIVsdGgjZZA9bs3wcU8f?=
 =?iso-8859-1?Q?dLe58g36nITPk5GGylBGg4GqZZUmWSLA3ckjDSDp4Cwzz0Vp2U0RMzr6DA?=
 =?iso-8859-1?Q?fwzGTcA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?P7aWIbihhpfDHcpq7eaEjsoTqp4B1rZAFLRKIWBUlmqyz9fWaexpAZ8/dM?=
 =?iso-8859-1?Q?xqAVrlAPZJIm4tZobhJGFtB4ZFT2X45B0hL/i15J8uLsRTJsfLzK0AhIGl?=
 =?iso-8859-1?Q?sRmMIufniR8/WYTujigp7t0eSuKyVJmulQDOf1OJzwfDTkV+3OvL9uUrx0?=
 =?iso-8859-1?Q?/3ZXlJ6PvHIp8271KfJ6kZ2aLHp7f+AJFKGtA/M6aVaMbxdF5ns9wsuype?=
 =?iso-8859-1?Q?54MxMToFXMHpyjnvnw08/LSLeBisoacpgmbTzIzL1kIj9X7HAGhG+1vP4c?=
 =?iso-8859-1?Q?bganqpRKBsZ2ahctM0Tt47sOd2szX03prDO47T2eBttFiXSyU4wSR5Hv0Q?=
 =?iso-8859-1?Q?O7+DbOy3aEseFEpZ9DDw68SUn0OkmWhvL+SRiJrNsuJnO40Ul9I93fKlQ4?=
 =?iso-8859-1?Q?7OPC9QiM5jTHw0CGIVa5/cTFUr90/JDT7aVEEKKK3uQmiMNBh2BW+BIFfP?=
 =?iso-8859-1?Q?pnS3ASz4CU9xSWByWwpHsGiUSmFfxSOJ9dClPxrTVwGRzavAytCqVWx+w4?=
 =?iso-8859-1?Q?wsVda8HhuNcAT5gyTCbEU4VJr9osFJONsdUtrsfBJFTm5PplYffFBKPyTe?=
 =?iso-8859-1?Q?aF28C+YlYD1AzpiijvgpDuhrJ+q5bRR8zdEaO1+uq/b46RDQ0gfVT1m0Kh?=
 =?iso-8859-1?Q?U244kGlnjp60/CVoGk0dPZMEV7Q/lN4tZz6bkDVJTAZL97GFyzen+2BSr5?=
 =?iso-8859-1?Q?0bWYmwSq7MyFzuLg2PnI+Ytmbx9jXNb346Qi6KM45mEXHU1hcIsNSmYJAp?=
 =?iso-8859-1?Q?2zmcVEcxgs1ygFlE6dWFQAN1geKcHPYrhItV6UQjiu5mzhT3zWHJ+4kvuS?=
 =?iso-8859-1?Q?1hGc/Ch/KDoaCrw7JOOkpIgQTLpMIy7fl3W1kC2vqqOZah8TTNyb4eGpFe?=
 =?iso-8859-1?Q?ObvJVXpDwIVKxwpzi3uA01pRCBvrv3IWJSdTJ39naIQz3H4OclvKdzoDNr?=
 =?iso-8859-1?Q?XdkE3TXGZBjfZALBC5Dh/poyqh4TLgzpir3fzc/uJkKGIWOPm61rcqEw8X?=
 =?iso-8859-1?Q?W1ji5UjztmXRT/k1pbgAgLxQd0otTiyOCucMLoDnSKbSnHiSQLRurBY9Zv?=
 =?iso-8859-1?Q?Xwvg7mWr8reHZTrXfh9tCQS/FBYXcEIm4jX0JY49oi3DM9WXfrqc2eG+S5?=
 =?iso-8859-1?Q?0oZXiYVL2wM6BBTkrQn9d/MVXLaXKdY5ITEiA+6uAjQV+TFKPaGoPJGnU1?=
 =?iso-8859-1?Q?+phovsB9j/NdngXqKoPPk/NTo4Zr6ovcj5bFo1/pVAmaC0ZO3jdH/rvpTF?=
 =?iso-8859-1?Q?L7tkJ24MpN68sPTBzCzftTOOhnreC3eu6c9iBG91CM8ggDCdCjKnSOJDzE?=
 =?iso-8859-1?Q?jOClfppmn4nRpGdlyFdcjSUTzoBT8p6GleXr8IA/L6M16yDPqT9bGeWoN4?=
 =?iso-8859-1?Q?Cv4G3PQwqa0NQZ5WC50HEeF/kr3tE5FhWJF981+mv0LWaDUiYnzlKs5ng6?=
 =?iso-8859-1?Q?7mE0ENd22GGcPlXoWsOowy8jqMciN+pM9MK5vDGiw/pZwwQOFbxjYFF7uT?=
 =?iso-8859-1?Q?ICVnXnrVjzyzBIyA0oSq2g75R6xR+6Z/v3YHypEycPAhcl+Zus5B23wl8p?=
 =?iso-8859-1?Q?gMAsWMTxYPwpmXB2SIyGSnq8Qlxh0C00PHf/V3L1rrvuLU85pYfCD+F3BT?=
 =?iso-8859-1?Q?lk9WVg+RjhqRlEOLhQ0f/DX2YwsHNCrtS55oYPkoc7/H5+I671KuOpHZrS?=
 =?iso-8859-1?Q?Je60kKV7CfzG/PtxKw8=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9dbdd22a-f338-4d83-ee08-08ddef88ef5e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:16.6734
 (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: NjZGUeix5PYPmTqkY/vffCkSEeVnzVIwv3FDBqinyAx8E+/Ys0VWmB6AJvDmjaVkHPlj4eHl6/cv6UTckWtBMSbgPqtJtaEqekX6n5n5PXw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

Introduced appropriate register definitions, helper macros,
and initialization of required GICv3.1 distributor registers
to support eSPI. This type of interrupt is handled in the
same way as regular SPI interrupts, with the following
differences:

1) eSPIs can have up to 1024 interrupts, starting from the
beginning of the range, whereas regular SPIs use INTIDs from
32 to 1019, totaling 988 interrupts;
2) eSPIs start at INTID 4096, necessitating additional interrupt
index conversion during register operations.

In case if appropriate config is disabled, or GIC HW doesn't
support eSPI, the existing functionality will remain the same.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 

---
Changes in V8:
- add missing break in switch-case (fixing potential violation of
  MC3A2.R16.3 with CONFIG_GIV3_ESPI=3Dy)
- minor: add comment for default case (fixing potential violation of
  MC3A2.R16.4 with CONFIG_GIV3_ESPI=3Dy)
- minor: as nr_espi is unsigned int, the %u instead of %d is used
- added acked-by from Julien Grall

Changes in V7:
- no changes

Changes in V6:
- removed unnecessary parentheses in gic_is_valid_espi()
- updated gic_is_valid_line(): it now verifies the condition irq <
  gic_number_lines() first, as it is more likely that the irq number
  will be from the non-eSPI range
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch
- added reviewed-by from Oleksandr Tyshchenko

Changes in V5:
- fixed minor nits, no functional changes: changed u32 to uint32_t and
  added a comment noting that the configuration for eSPIs is the same as
  for regular SPIs
- removed ifdefs for eSPI-specific offsets to reduce the number of
  ifdefs and code duplication in further changes
- removed reviewed-by as moving offset from ifdefs requires additional
  confirmation from reviewers

Changes in V4:
- added offsets for GICD_IGRPMODRnE and GICD_NSACRnE that are required
  for vGIC emulation
- added a log banner with eSPI information, similar to the one for
  regular SPI
- added newline after ifdef and before gic_is_valid_line
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- add __init attribute to gicv3_dist_espi_common_init
- change open-codded eSPI register initialization to the appropriate
  gen-mask macro
- fixed formatting for lines with more than 80 symbols
- introduced gicv3_dist_espi_init_aff to be able to use stubs in case of
  CONFIG_GICV3_ESPI disabled
- renamed parameter in the GICD_TYPER_ESPI_RANGE macro to espi_range
  (name was taken from GIC specification) to avoid confusion
- changed type for i variable to unsigned int since it cannot be
  negative

Changes in V2:
- move gic_number_espis function from
  [PATCH 08/10] xen/arm: vgic: add resource management for extended SPIs
  to use it in the newly introduced gic_is_valid_espi
- add gic_is_valid_espi which checks if IRQ number is in supported
  by HW eSPI range
- update gic_is_valid_irq conditions to allow operations with eSPIs
---
 xen/arch/arm/gic-v3.c                  | 85 ++++++++++++++++++++++++++
 xen/arch/arm/include/asm/gic.h         | 21 ++++++-
 xen/arch/arm/include/asm/gic_v3_defs.h | 38 ++++++++++++
 3 files changed, 143 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 2fdd96dbb1..bc07f97c16 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -489,6 +489,38 @@ static void __iomem *get_addr_by_offset(struct irq_des=
c *irqd, uint32_t offset)
             break;
         }
         break;
+#ifdef CONFIG_GICV3_ESPI
+    case ESPI_BASE_INTID ... ESPI_MAX_INTID:
+    {
+        uint32_t irq_index =3D espi_intid_to_idx(irqd->irq);
+
+        switch ( offset )
+        {
+        case GICD_ISENABLER:
+            return (GICD + GICD_ISENABLERnE + (irq_index / 32) * 4);
+        case GICD_ICENABLER:
+            return (GICD + GICD_ICENABLERnE + (irq_index / 32) * 4);
+        case GICD_ISPENDR:
+            return (GICD + GICD_ISPENDRnE + (irq_index / 32) * 4);
+        case GICD_ICPENDR:
+            return (GICD + GICD_ICPENDRnE + (irq_index / 32) * 4);
+        case GICD_ISACTIVER:
+            return (GICD + GICD_ISACTIVERnE + (irq_index / 32) * 4);
+        case GICD_ICACTIVER:
+            return (GICD + GICD_ICACTIVERnE + (irq_index / 32) * 4);
+        case GICD_ICFGR:
+            return (GICD + GICD_ICFGRnE + (irq_index / 16) * 4);
+        case GICD_IROUTER:
+            return (GICD + GICD_IROUTERnE + irq_index * 8);
+        case GICD_IPRIORITYR:
+            return (GICD + GICD_IPRIORITYRnE + irq_index);
+        default:
+            /* Invalid register offset for eSPIs */
+            break;
+        }
+        break;
+    }
+#endif
     default:
         /* Invalid INTID */
         break;
@@ -661,6 +693,55 @@ static void gicv3_set_irq_priority(struct irq_desc *de=
sc,
     spin_unlock(&gicv3.lock);
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+unsigned int gic_number_espis(void)
+{
+    return gic_hw_ops->info->nr_espi;
+}
+
+static void __init gicv3_dist_espi_common_init(uint32_t type)
+{
+    unsigned int espi_nr, i;
+
+    espi_nr =3D min(1024U, GICD_TYPER_ESPIS_NUM(type));
+    gicv3_info.nr_espi =3D espi_nr;
+    /* The GIC HW doesn't support eSPI, so we can leave from here */
+    if ( gicv3_info.nr_espi =3D=3D 0 )
+        return;
+
+    printk("GICv3: %u eSPI lines\n", gicv3_info.nr_espi);
+
+    /* The configuration for eSPIs is similar to that for regular SPIs */
+    for ( i =3D 0; i < espi_nr; i +=3D 16 )
+        writel_relaxed(0, GICD + GICD_ICFGRnE + (i / 16) * 4);
+
+    for ( i =3D 0; i < espi_nr; i +=3D 4 )
+        writel_relaxed(GIC_PRI_IRQ_ALL,
+                       GICD + GICD_IPRIORITYRnE + (i / 4) * 4);
+
+    for ( i =3D 0; i < espi_nr; i +=3D 32 )
+    {
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICENABLERnE + (i / 32) =
* 4);
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_ICACTIVERnE + (i / 32) =
* 4);
+    }
+
+    for ( i =3D 0; i < espi_nr; i +=3D 32 )
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + (i / 32) * =
4);
+}
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity)
+{
+    unsigned int i;
+
+    for ( i =3D 0; i < gicv3_info.nr_espi; i++ )
+        writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * 8)=
;
+}
+#else
+static void __init gicv3_dist_espi_common_init(uint32_t type) { }
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity) { }
+#endif
+
 static void __init gicv3_dist_init(void)
 {
     uint32_t type;
@@ -706,6 +787,8 @@ static void __init gicv3_dist_init(void)
     for ( i =3D NR_GIC_LOCAL_IRQS; i < nr_lines; i +=3D 32 )
         writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4)=
;
=20
+    gicv3_dist_espi_common_init(type);
+
     gicv3_dist_wait_for_rwp();
=20
     /* Turn on the distributor */
@@ -719,6 +802,8 @@ static void __init gicv3_dist_init(void)
=20
     for ( i =3D NR_GIC_LOCAL_IRQS; i < nr_lines; i++ )
         writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTER + i * 8);
+
+    gicv3_dist_espi_init_aff(affinity);
 }
=20
 static int gicv3_enable_redist(void)
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.=
h
index 3fcee42675..3947c8634d 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,9 +306,24 @@ extern void gic_dump_vgic_info(struct vcpu *v);
=20
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
+#ifdef CONFIG_GICV3_ESPI
+extern unsigned int gic_number_espis(void);
+
+static inline bool gic_is_valid_espi(unsigned int irq)
+{
+    return irq >=3D ESPI_BASE_INTID &&
+           irq < espi_idx_to_intid(gic_number_espis());
+}
+#else
+static inline bool gic_is_valid_espi(unsigned int irq)
+{
+    return false;
+}
+#endif
+
 static inline bool gic_is_valid_line(unsigned int irq)
 {
-    return irq < gic_number_lines();
+    return irq < gic_number_lines() || gic_is_valid_espi(irq);
 }
=20
 static inline bool gic_is_spi(unsigned int irq)
@@ -325,6 +340,10 @@ struct gic_info {
     enum gic_version hw_version;
     /* Number of GIC lines supported */
     unsigned int nr_lines;
+#ifdef CONFIG_GICV3_ESPI
+    /* Number of GIC eSPI supported */
+    unsigned int nr_espi;
+#endif
     /* Number of LR registers */
     uint8_t nr_lrs;
     /* Maintenance irq number */
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index 2af093e774..3370b4cd52 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -37,6 +37,44 @@
 #define GICD_IROUTER1019             (0x7FD8)
 #define GICD_PIDR2                   (0xFFE8)
=20
+/* Additional registers for GICv3.1 */
+#define GICD_IGROUPRnE               (0x1000)
+#define GICD_IGROUPRnEN              (0x107C)
+#define GICD_ISENABLERnE             (0x1200)
+#define GICD_ISENABLERnEN            (0x127C)
+#define GICD_ICENABLERnE             (0x1400)
+#define GICD_ICENABLERnEN            (0x147C)
+#define GICD_ISPENDRnE               (0x1600)
+#define GICD_ISPENDRnEN              (0x167C)
+#define GICD_ICPENDRnE               (0x1800)
+#define GICD_ICPENDRnEN              (0x187C)
+#define GICD_ISACTIVERnE             (0x1A00)
+#define GICD_ISACTIVERnEN            (0x1A7C)
+#define GICD_ICACTIVERnE             (0x1C00)
+#define GICD_ICACTIVERnEN            (0x1C7C)
+#define GICD_IPRIORITYRnE            (0x2000)
+#define GICD_IPRIORITYRnEN           (0x23FC)
+#define GICD_ICFGRnE                 (0x3000)
+#define GICD_ICFGRnEN                (0x30FC)
+#define GICD_IGRPMODRnE              (0x3400)
+#define GICD_IGRPMODRnEN             (0x347C)
+#define GICD_NSACRnE                 (0x3600)
+#define GICD_NSACRnEN                (0x36FC)
+#define GICD_IROUTERnE               (0x8000)
+#define GICD_IROUTERnEN              (0x9FFC)
+
+#ifdef CONFIG_GICV3_ESPI
+#define GICD_TYPER_ESPI_SHIFT        8
+#define GICD_TYPER_ESPI_RANGE_SHIFT  27
+#define GICD_TYPER_ESPI_RANGE_MASK   (0x1F)
+#define GICD_TYPER_ESPI              (1U << GICD_TYPER_ESPI_SHIFT)
+#define GICD_TYPER_ESPI_RANGE(espi_range) ((((espi_range) & \
+        GICD_TYPER_ESPI_RANGE_MASK) + 1) * 32)
+#define GICD_TYPER_ESPIS_NUM(typer)    \
+        (((typer) & GICD_TYPER_ESPI) ? \
+        GICD_TYPER_ESPI_RANGE((typer) >> GICD_TYPER_ESPI_RANGE_SHIFT) : 0)
+#endif
+
 /* Common between GICD_PIDR2 and GICR_PIDR2 */
 #define GIC_PIDR2_ARCH_MASK         (0xf0)
 #define GIC_PIDR2_ARCH_GICv3        (0x30)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:16:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:16:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116194.1462602 (Exim 4.92)
	(envelope-from )
	id 1uvvOc-0005sy-VI; Tue, 09 Sep 2025 10:16:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116194.1462602; Tue, 09 Sep 2025 10:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvOc-0005sr-S0; Tue, 09 Sep 2025 10:16:18 +0000
Received: by outflank-mailman (input) for mailman id 1116194;
 Tue, 09 Sep 2025 10:16:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvvI0-0000yD-OK
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:28 +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 11555a8b-8d65-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:09:27 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:21 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 11555a8b-8d65-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OWBYPXR8V/kBGfCmcAFytIuqfgjcuHW/eDrkNm+e5mAiaXZIW6k1GWbuDl+D5F7fxWtKjh9mnt6rgHKEV9AmrcVIsosL1suD/ViGStRdGfrcdV/ewpA7sc0ynD/wbyZeoqGWFD9fYSNzAN2V3RqaqptmYRQNmjj0En+9kUwmLfnUEWs527QQdm4ddyb7PQnsD/Sf61zIyFMOv5B8fgGWLJrY9ZiBFx1oEVzZXZeTcF2ulfgucSQQxo/CPETMaKce7ANJA0HdRUr8pf7teqb4Ima8JUnVLJGcFDb6FDQOVQ2OsFakM105RWF9chUdeiPNdY8V6vr/dUNGAAxvp4YgTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wvjb8Q2MRZ30uBI5D+0Q4eS0/g5NqC7ZCG+VanVMZrk=;
 b=xEohO314ESLcmE5Vs1UuBcxTr9Dh5kR0n4S5DSgXoReyHT1bCqjXRlYaCDIqbx6P3ZORIKnqSDX5idGYophaGvFI0GRFfeeKZvx/0JmXxNZCBjvOiuz5vmxeMFkPZWC3xeMn18CPECm6rJIAEWPtYlXWmutGCsVuUpRroiouufIFg5b2TxTgyPIePjM6nEesllX3qiCCA8HbzyKSmrSbcbAlu4VXe7Ntrsfqc5gSMyc2pWyz0T2Xe13etCJnJ3sclr7MWgaCQTCNP6G2slhUjsSHZT49ochnksBG8V/LoO1TTnX2ff5x0fs0K6CeLZGzxsPpMNHJ5JrfhhP/qt9uaA==
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=Wvjb8Q2MRZ30uBI5D+0Q4eS0/g5NqC7ZCG+VanVMZrk=;
 b=sQGiMWKFmhNVOLRUNuv3AP329xM8642XyhCbocGdxmkLOTHHLumRgn9NflFRswZQoiRWlvkBndm6nNFFLvSsMDwshrEZQDrzVUU/9T0urTA8IZKyUOpMUTXo3Q85PIMuHjXix7iG8RrB2j5JkMIKVyfEAS7Tl8o2Cnkv/Ed4LpaakKCTUf5MM9e/1pRiN1svofyeQDwwWFAM35PlP+KJH72VojCj/ZC0iUNHz/XgFUoljzbDBaRyxg9bCinRfy5Q8GL1GUkO9kgyV2JAoAxMkOs+/KJwmthes7KP0/By27aY9Z5MfMlm5RMJG9KB1QJxifKAYBAAih4tP6TfWgEsAg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v8 06/12] xen/arm/irq: allow eSPI processing in the
 gic_interrupt function
Thread-Topic: [PATCH v8 06/12] xen/arm/irq: allow eSPI processing in the
 gic_interrupt function
Thread-Index: AQHcIXHPX1YLtsRvi0asSCS1zVQdvg==
Date: Tue, 9 Sep 2025 10:09:20 +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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: c22e6002-2518-437d-ae78-08ddef88f1f8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?dpZLcY+27wp0XnLl7hPcXPlxFlWYr4tiiwMty6MDZutWzmUznGl3/R8iuj?=
 =?iso-8859-1?Q?zZmDvF43jKY6zkaxYw6+f2unrHGUoOafl0cRW06UnEVEbdKxrflWd/Y2if?=
 =?iso-8859-1?Q?2RlRqbFk9ymongCLa08Ab81obQcb1Ud+Y0TDJ6kGi0O3ARp45sbf4zyCym?=
 =?iso-8859-1?Q?EUYxzmSh/89mBdzQjfwBhE8RX9y7ELs9aDqynEdW22x3jQ5RiRQZ0mQo8k?=
 =?iso-8859-1?Q?rNN062bliDQ7vXTL4nRK//CwByW4mfUWKQJkVAjRR73IsNaEYfRorteR4x?=
 =?iso-8859-1?Q?EWsCRfchWPTQmIlhWsRM3r+Ky/AHlEUPClxSFjFiXv+5sErVP2jf2F5bS8?=
 =?iso-8859-1?Q?TwC8o3qXfW9Jo+JsgBMa5qas295wSkrHreHju1WkcTbW1+7kg3vZtlqRaE?=
 =?iso-8859-1?Q?T7yUJbW7P1V0OTqm1d71/h4NcV0FtDsdUqJopBwb6iMw2A07a+4tqJ2NBZ?=
 =?iso-8859-1?Q?QE7jtkr21AYCC6vybAaCoqdjzraFbJeiZ7whAfZ70Eql/7eq3NVsyQ2TNG?=
 =?iso-8859-1?Q?RWXi8BAhV0RdzVTk7zQDrasmdCiAbBexQVAThjLZEcVa+oe8HJjDr+k5DJ?=
 =?iso-8859-1?Q?9pCO39l3BO0rdj+f9x8HToYxzZGuW4MemdwPE/Bmb43EFzeDoPq+Qs75BG?=
 =?iso-8859-1?Q?YfkYxS2MMJPfQmRu7PQYBqpkO3hxpswHn3juQpivCAnri7pza90F89J2Eb?=
 =?iso-8859-1?Q?XYqqT0KauTlirUVao181guqjuTpvvOPO0jwrcuX5pXXPr2UEZC+gSoN/qv?=
 =?iso-8859-1?Q?D9zwhNMGQX0CP/lxl8nPt/gQb+LMqofTz1HUj+YUZZw++Qt2L+f+t8XpNk?=
 =?iso-8859-1?Q?WDULbqX6PVUNfByZL5UVsRbddflLMcFe/tWoKV86ZvVuPkGEeMNP0z6Yrn?=
 =?iso-8859-1?Q?7fMZZLPYwHFnCVNqIt9YmxvIqo4Z09ylREtrW9p1OAMxkZ3+Ms4VQmyZj8?=
 =?iso-8859-1?Q?CyV6TU9Hy6HdEhqU64+uz0OTpdvUaEnlj/IlK/2kDk1VlZeI6XVObpnsh9?=
 =?iso-8859-1?Q?snluglIqdEIGN4QFQ4Gis/YqUHHq1EOK9xF1lymHYcYVqur7D1V4cND+Ku?=
 =?iso-8859-1?Q?K2NSpKTzaR/5XaTuYD6dX+ULcMTdm/RMlbJqOFAP7t3jzT5tVKDtBc80J1?=
 =?iso-8859-1?Q?YQc5TxAKVRsY9kwX7ANHBz9PZ93MXEwVGnLXE+zHIGzuXspozvZTPOa6EY?=
 =?iso-8859-1?Q?WP9ud3JWoHS2q1WDRM3Zc+FUgo4QzFMrdMPNhvBrdu6+3MS31nRNEv73op?=
 =?iso-8859-1?Q?HFKlUugI5aQRho7YqRC1+AfHj05gVEnXAW3PylkAG8VnsH4rZfB6cixspv?=
 =?iso-8859-1?Q?xqQCGxClo9LllbYYGILO3rz7sbKKTl4gNwp5zwJk3AjyhwPwJ/KhOOitS4?=
 =?iso-8859-1?Q?lxnsaaIwFDmEhTTxN7ENttmtjZjJaITquTE+D1nJBywrrfmx1zaTyTExhM?=
 =?iso-8859-1?Q?fKO7/pqJKc5QSDWO4c1YJK7hijVCHo5FWvMqu98qukHV4i50CZi0oJEbPr?=
 =?iso-8859-1?Q?qvqYPR1ZIUiqmFshQij4wZFfUHk40o3MrlPYLKu81UXA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?S502qPGptCo2Mw9v70rS7DWlPVsVHnyMHLR0uVsA7k5wJrJSLfEuDqbi6t?=
 =?iso-8859-1?Q?N2AfzJc5VTP9ZdODP0u1a5KwlNYaqxJ8SXY26JEVCPWC3fckV8TcWkIsXh?=
 =?iso-8859-1?Q?jRpgyO2OMp3FxorXzs4d1+bKKKYFyMTyfzkStOUUczb1Po1dxnv7m2lSuG?=
 =?iso-8859-1?Q?93aLX7cp7HjpTVIaSdGUnfXmkTe0FcvvmAiMgYDtq4tH49VgGsDlldXwqK?=
 =?iso-8859-1?Q?Uk0Kgzyx2LvaX1rGqIWH1qwpTN6W3Wh9YrlbXXdkcqStNictBWCdGtfJQH?=
 =?iso-8859-1?Q?1loe8KPifZxOndQWPa4tzA77xcSRU4IeKlKPUPgWDs5noV/f+VFHtONsYm?=
 =?iso-8859-1?Q?vd3mre2ohOHaLPJqWVIFKjik8Xhm43OQBBc+kgZ6XTbEc0KtdZPtfhL3KV?=
 =?iso-8859-1?Q?NxG0PSXVq/sN/jaWHaYR4I6hHUsF47bdfAUA5eSPIFTwRU3N+08XOQDPe7?=
 =?iso-8859-1?Q?GuWr4SpnWhAQSXK9QksVciXURja969RRBSVFicxmVt2Nz4MG7K33SA3u0L?=
 =?iso-8859-1?Q?lZHzZ1eX0p4LC1y36gl+X3/hawSIOTVq9BOjV1m4/muFRUdDJWBRSQviyf?=
 =?iso-8859-1?Q?K+BCl/YV5AlgPfP5efpwAyWeInPHOpkz9o5NVY5nrLK0tJefb1ajqYWaRJ?=
 =?iso-8859-1?Q?9COMR6fHa4sOZIxRUZNNbVJlM2U/bC3qCb3+Tkxtqf9qImiBghSBPptnK/?=
 =?iso-8859-1?Q?vsnSJq3FZuMJhqF/s3ctL2FVUP/s/4HIbopwD37RQL27RATrt3u52ufGg1?=
 =?iso-8859-1?Q?q79uzTOcnvarUtEtdFZ0RUvsR8GL2+W8A07lqHntVRCFAx7+wFVKOeQD2m?=
 =?iso-8859-1?Q?7LNLKVXETW5Ab2Gdiup/4JYKX19DXxJVAcxC1OadcwOLNN6lA8Z+3UD8fU?=
 =?iso-8859-1?Q?0sGM5mgZE8az04AREPcJJlK1gGGsSwBnjl8bdStf0GsSgZnQLq2W8gmKUB?=
 =?iso-8859-1?Q?YWtmzzOgPMyym1idqWVMJuYe+75CWb1pH5sP1r81QmGeP2ZRGOOBCwU88A?=
 =?iso-8859-1?Q?q25v8bRzxeeGbVsgLBn/FgshrsCMUP3/n4RCBUI/V2SlmVB7cDN0TIQI48?=
 =?iso-8859-1?Q?wLzg6aNk/bJNZYptoun8d1B38z1r6IOeUhvyxr9Vex8f02mPaHgqpMKM6X?=
 =?iso-8859-1?Q?3gHIt6ieYFdCkWY7fJQw99VCmfkaHWBu59svvXa0/WSkx5hPRK54uL1x/7?=
 =?iso-8859-1?Q?PbV7i5LLOKYY0jJSVj2/nKOJOBtN30eY99Ia0A0HU/0pEbWkT3KKnnSNO0?=
 =?iso-8859-1?Q?gCTkdrbHtLuN4cWobd50VOU2pXbB2TICKugiCd5i9TUzAGsADviSkyLg1O?=
 =?iso-8859-1?Q?87TLWgWQDV1m/n36q4r5pBPe6WP8pgLW8gwc3tvzhKVn1FdnJFS/vjSEhl?=
 =?iso-8859-1?Q?O/3isKKe3DzI0UGXnRNoEcCrabnR/EPw++VNMyCW5u9UPDz1H9tLeIyAA1?=
 =?iso-8859-1?Q?4SjpXIcM7NP7u7VDbrFz5d0MPgF5fqntbEuJNzF0i/595fBHLgzG3whAC2?=
 =?iso-8859-1?Q?J3E1WhbJF/KmmDQRrnrlUUG5TQt8atqwlKVDxCONAZh6vuA2vc7Ifaz9eH?=
 =?iso-8859-1?Q?1JA2utF3YY6J89JFEt3ou7FMeL7JvhyYX1BIKItW76AAw51X5HNLQgWu2j?=
 =?iso-8859-1?Q?1wsEzkUwe813h9Wu3f7sFjCWfaTWC8ymCqgr+G/hl3V9VD/aet2Tu/TRMI?=
 =?iso-8859-1?Q?jGUeElkUIXP/IT00Ywo=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c22e6002-2518-437d-ae78-08ddef88f1f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:20.9464
 (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: P1giZiPDNqaxiGZFps3l2MW3v7hAFrw8D7hPCsVbf5ckYq1zdti14+F8Mw7BKraUMNjl7HnBo827ZzcLDNWSYk1BY1l7tX1PB+ZMMywoMWk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

The gic_interrupt function is the main handler for processing IRQs.
Currently, due to restrictive checks, it does not process interrupt
numbers greater than 1019. This patch updates the condition to allow
the handling of interrupts from the eSPI range.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V8:
- no changes

Changes in V7:
- no changes

Changes in V6:
- added acked-by from Julien Grall

Changes in V5:
- no changes

Changes in V4:
- fixed commit message
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- no changes

Changes in V2:
- no changes
---
 xen/arch/arm/gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 9469c9d08c..260ee64cca 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -342,7 +342,7 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_f=
iq)
         /* Reading IRQ will ACK it */
         irq =3D gic_hw_ops->read_irq();
=20
-        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) )
+        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(=
irq) )
         {
             isb();
             do_IRQ(regs, irq, is_fiq);
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:18:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:18:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116206.1462612 (Exim 4.92)
	(envelope-from )
	id 1uvvQc-0006Uz-BS; Tue, 09 Sep 2025 10:18:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116206.1462612; Tue, 09 Sep 2025 10:18:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvQc-0006Us-6v; Tue, 09 Sep 2025 10:18:22 +0000
Received: by outflank-mailman (input) for mailman id 1116206;
 Tue, 09 Sep 2025 10:18: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 1uvvIB-0001My-W9
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:40 +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 1756f370-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:37 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:29 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 1756f370-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N04FdM/jONw6MuYWSB7RR7dP1d4TNMMabl3CnqN0E4Qap1ndOhC66VSuPVHr18emG9jMEH/mkkXrrFGXzbtS8G1UThkjs1WrkXND6l9tBQwaI4WAImlyY+37AtvXsg3i6uV4gcUoBS9b/vy6cMNdmfZUIQss9artPxux8n5rQHmbR1fbBeYdjihmDQKrVjIu7uW3qgQrB4/wxTZMtrOSK8WXnxecziituJNlhNSoCjKuvJCYLHgkUEIINXfXOjrWhb0IOSMBs8OwwuXG51raQmfCYMY7lrbKWMPQkxKhuUflKMWu793B8xGUAMxyfaMG+wmGq9fQ/hN0GVToxUegcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WxcOto4JZOafCSrYBo7S3JnuTIEtWhZv/gUMQqkd/uc=;
 b=s9i1/fLSvQ2dctVsZYexmJkaSd79syN32wsSdLVvcaVEhOeAz/VQPXE4YrXxxwId1cYJ5AwSW5KlxHwrdyr4kmba68VsOcFInmwJCDGkEslOKQxqo2ZLP8W4u2r2mBR++Ss6MrPifuq4HlM00iTl+KR4cNVLbAGLdwo8/0va2B3kzZSqdxAN9B/WxWXSPBztHwoXbywEBHwRPaob5142Q7MdDCAXAtjkBvKlk7vEa76WeSOCX5JFWyKCrF8lJL48KLxoZr1b0YjXUryxEbs6vahUpnrroyQDD2cPW9Ii1nCRLYkGhfVKkhCVhuctaio6D+YXC8b7ojMwHexaKdkmWQ==
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=WxcOto4JZOafCSrYBo7S3JnuTIEtWhZv/gUMQqkd/uc=;
 b=aHBH6/0brleD8QQAZ6nyWViPTJ4CFDoCmmzT94e0G4twp2KHP/RW8TN0V309erTb/l/ir0DoiwNO3nUyxZ7rBvRoZYJpGMJ7vxogUQ+k6xokCw8KBWz8DA43Ic5C+EkPqbGeYOK/yiwj9M4sAkuD9wC5ijLY6sKQrvlTRSQqjUY0pBiGJweLLFEUD2+xVwKgThyZTeUz1itAiQxokMhjaBS9KbTbLkQ7yqoOJtepNgdgKKi8RhClNM4t/HtJyaRe99AhEecZ8Jrm6PXhtfDS4OeTe4xtc2CDu/CpmSutzqEaznw2iBfSXfFvgydBe+i/5wx51m1JdxnocxT36rF/0g==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Oleksandr Tyshchenko , Julien Grall
	
Subject: [PATCH v8 09/12] xen/arm: domain_build/dom0less-build: adjust domains
 config to support eSPIs
Thread-Topic: [PATCH v8 09/12] xen/arm: domain_build/dom0less-build: adjust
 domains config to support eSPIs
Thread-Index: AQHcIXHUheH+XMLsykqRJlmFqB5APw==
Date: Tue, 9 Sep 2025 10:09:29 +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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: fca61201-adbb-4b44-bafc-08ddef88f6fd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ob7XRII9bUc3lzCE8ZTG6q7qlVdnQZq9xHb2I5fZ+6KxQL82DX6QyyXIi9?=
 =?iso-8859-1?Q?6SP74P+UZ27beRMw8Hz0tZXaQxbgY7QUwB77T3FwfUyHhXyo+dG2RvNyGK?=
 =?iso-8859-1?Q?VlNTTpH7vXHvO7AgM3toboEzrdZUprRElcKJboQ5mDRL+VuabliikXgsrN?=
 =?iso-8859-1?Q?6PZnm19qYrmcw1YgVbx0XrJEoob9SWOeCFGtbm2Vl1qAiCRsK43KRrG0GI?=
 =?iso-8859-1?Q?pK4ECLHJPhcuvXsGMdNvZi0XWsoaYG/bHS/LXNib2IwJxbe7xr/31T58ER?=
 =?iso-8859-1?Q?e5WurUQpdtStGsBkGYaWiDCOPDfSckxcy+P4Boh65K+PElO1p3u4cO0jH0?=
 =?iso-8859-1?Q?9M+FFV4oYa+OOqoJCJ1KeH3MxCSn1pQ+NMpVwQPn+KlANeoLwGLRc7+PYW?=
 =?iso-8859-1?Q?ndxiaMVS0jvJovN6ZLB/MoIA1p/9OS25r5hhdyNTVRmob4qLZc3T2j9gW8?=
 =?iso-8859-1?Q?1fSUp5P++Z2jqctMu/ktW6A7OfQQ99FYRcbFe4O/djXa9krOl9vt4bzviV?=
 =?iso-8859-1?Q?F0k4T7zvm4BKLtDF17V6scfYdQ6bq6SRrVC3EmyyE2hopjglfaQfYRTWFq?=
 =?iso-8859-1?Q?ee6f5nEedPjamf0XQWDd5A1RK2bTF0ZmCc8b5/i3fz4X1p61d1AcTepJYb?=
 =?iso-8859-1?Q?q5k1d67iHStA+8RxWbtXWz0QXBUzZ0q+vZw9JBrLh5ie41ryObE78ErrQX?=
 =?iso-8859-1?Q?4jh1ZXGzV70D8B5TZDnmmUYs5r6VaK2SYMS9XZphSIpgWsUhkoLLDtW9CT?=
 =?iso-8859-1?Q?JZ/rJL0dvjfP+p3KTZP6VUAsmddWcFUlxn7kya7nOox/k8fGoske+o5S6F?=
 =?iso-8859-1?Q?Y630Ai3i3a41+uQXFDD887RlzxuEnAdRmXDBUsjDwlJG+Ye9+CNQ9Mt53I?=
 =?iso-8859-1?Q?0UCHUW2Qh47uc3DFsccNNLARuyRAGJ5XDyi+eRE61lPhfwXkmK5wGTecL1?=
 =?iso-8859-1?Q?KOwnQx8I+t7AFY8y9OJQPtLTe8Fjktt5/gtuYylXwgbOGHQ6AbTLflLBv2?=
 =?iso-8859-1?Q?hmY3aE6LVFJdaiZUiFhlj0qGSkkst5CeUubrMarMA+661QkKizlcutn1bh?=
 =?iso-8859-1?Q?IG/u43USnEn70gw60kGawZYjDSmJEKw/j1Jlt+5MjNQgMi9HDZyWw4R96n?=
 =?iso-8859-1?Q?/ETf3TRCqvuTUtL9XrsnjYaPWPtPqNH3VqMnYP9gamflhKvJE1zstq1soh?=
 =?iso-8859-1?Q?U4fq9FOAMhNJBf7vm6CsalMA1fyq7r04RIsRJZ5rc938tYFvYIW+aguNbB?=
 =?iso-8859-1?Q?YBJwiG7lrBY4P2JGygYzd6bafE8+cplt0uIzuGill+yGmri6y7vQzh/L9a?=
 =?iso-8859-1?Q?/F/E5Rmp+T2or4s1PzVonhPRYS+8Lc6TYZkaClQOcibnTD/bjDy3NO6Fog?=
 =?iso-8859-1?Q?aLGmNoS2sC4GVkL+tT+RggMELawEFn0+S0OIk4cWA4rTX5MoxOUMvwgV52?=
 =?iso-8859-1?Q?gvsMXEpWANE1GhscusfHwtzrrCpKCQxXb0UUMfJ3BzQwZQghLP+cjfeUAn?=
 =?iso-8859-1?Q?PnAh2ogkKf3RPRcrYH6I73BWt46UgpMsEFQvkdg4NygR9sDgMAYaBfOXgF?=
 =?iso-8859-1?Q?r7SLCvg=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?dJJNcO1VB/3wCqreEVAVeiLO/gDXoYLH6+uGcRhLp1GhbXHYawJ2Kkrx/v?=
 =?iso-8859-1?Q?etmIY7ox4/WYDR0tk/uNFBo3TEmHhSLFJCY8JO+6GDHC1dP/2hO1/JI+uJ?=
 =?iso-8859-1?Q?ARCvJbLRhtCEp4eToag92Oe+tiM32mgPY2DSzVvHjHQPsXh6WJT/Ad/hAb?=
 =?iso-8859-1?Q?aWW4BXbjbGdpRCmk/YUW5JgAsDwS+QneEO7SW+hCCXJVnTsP5QbqB8f1Ks?=
 =?iso-8859-1?Q?ewJwIwCytuZNIz1HitU4YpTWpFawdtE6ZIq+sgclsHirOBywajoCM9N1VN?=
 =?iso-8859-1?Q?4dgOa1Exy6k8O4hDAc1RqDFVPH9CkqHl/avQRsHoKuj9vy48SxUSzGQww9?=
 =?iso-8859-1?Q?KbwH+5bAtFZCyVSz1quCb1QDZha4TKhaX1++k9SHI9kwBqQ38RzOdwdLxm?=
 =?iso-8859-1?Q?YPkJ6s8XwBq8f/sdD43nM4cirGwVD/PJP2sqsVYF5AqoxZU1MPTaVQHQQo?=
 =?iso-8859-1?Q?J4gkieDfkTTmKUYeQHva5cZlr0+rLYAYnQnbv7Bh4szjA0y29V3cSxouu3?=
 =?iso-8859-1?Q?EnqbVFf4MU1YIQLsnFNbPnTMdD8ioA/wL8zDchg8+S/ETawC2diA98liVZ?=
 =?iso-8859-1?Q?ZxpYpMHtf49d4C4yAChv0ZJzl+79hvM9uThTlnAD/GB2yBdeCUn7UXKBLE?=
 =?iso-8859-1?Q?GveSALuE4+ms41YhCWQFeowgufp66n1Wc8OR4OCxgi/GFf/b+nh/20XN57?=
 =?iso-8859-1?Q?PCmMq3TJhPjrekA4EYRWoGVnOqgSWiYSWT+SVc/6oNLvc/vfWOdeFkteSq?=
 =?iso-8859-1?Q?Fv9VooltrvrgOvtl+hS7VtpJQLjAxJ9OEoVIHAFnlqXJAlmCJMMTNMgSR+?=
 =?iso-8859-1?Q?gKJOsPg+DPxZQ6REOk1Al4MyzANAMflrigl780bLTdZcfJBy7kLRw8/9vR?=
 =?iso-8859-1?Q?Q9fYvdT++s/VEWWNduKfLbmOESOAwPMmbIVWklzRQ+mSFoBAkqpQQYimBE?=
 =?iso-8859-1?Q?U5YxoZ9LNqe5GuuBXK/dEx3VEQvddE6//bO5nsiSx2e36vgj1WeDVwGAY6?=
 =?iso-8859-1?Q?ndHB6r3fFDDum8FeBawnKIQjA7HHjlNueGOu1jGEe5va6SsOkcp1JnEAIV?=
 =?iso-8859-1?Q?FI1YqlWJ5onc7CEKdKmTuyjF8qwEh8E2KVlSPDsRvsiwdU1iOw0zhkYk8y?=
 =?iso-8859-1?Q?C0gQiXE43Qed1xFGivLCIlUUAdoF4KBd/5xasi3phG81efERd3HowI7Edk?=
 =?iso-8859-1?Q?G4xh5r0IInD/lXX0hD1oP5m8iPxataRgk1CtAmkJHFqwNPXoMlfM1bZuOV?=
 =?iso-8859-1?Q?nZaiiVoTKP9K0H9IAQZ481oHMvzTRZbcpBAnp4cSXsJ/SO3f2JMa8Y7IBF?=
 =?iso-8859-1?Q?xBvE32qYYhXiSH2+yemiTlVGuOklSXrnRfreyfAJVGFLMz0TuBFmaVrY9y?=
 =?iso-8859-1?Q?flr7cZ19yk7AqsYvM3VCk3MszMP+JD+oGVPapSNHO7boqqOW6fn62V1lSK?=
 =?iso-8859-1?Q?k8QtL3qxuLqilfxY+2KgysVSEGlU/SJ7Z4KVhc/TYDpsJE9URONIcK2nn7?=
 =?iso-8859-1?Q?C5JT+AWNQAxjC5BWplALsbUHCVKp/dogOESxLdkAHjsDHa+y71hknTLpZZ?=
 =?iso-8859-1?Q?x27z82uM4ZcJzvOxiWb6/oHVFkIQP3+SDXaiJDDlAjjMchR57MKkxVw1yf?=
 =?iso-8859-1?Q?w5IDPbVdFI4SvIGzE4nDXzyoV+mijeZEzoZInVXbl/NWUEmByneEsfyvG0?=
 =?iso-8859-1?Q?PFlOCFrAK1N1tPVCme0=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fca61201-adbb-4b44-bafc-08ddef88f6fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:29.4335
 (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: IuUVRybk7ffyirKrUHV6wRGsrp70fQisfLfSHzb8sPe0M1pwkwJZ8rqZekaMAVv3MH+8SfdM7farVzjJO0o8sO+5VMuGz8OPJ+/zvgdROgc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

The Dom0 and DomUs logic for the dom0less configuration in create_dom0()
and arch_create_domUs() should account for extended SPIs when supported
by the hardware and enabled with CONFIG_GICV3_ESPI. These changes ensure
proper calculation of the maximum number of SPIs and eSPIs available to
Dom0 and DomUs in dom0less setups.

When eSPIs are supported by the hardware and CONFIG_GICV3_ESPI is enabled, =
the
maximum number of eSPI interrupts is calculated using the ESPI_BASE_INTID
offset (4096) and is limited to 1024, with 32 IRQs subtracted. To ensure
compatibility with non-Dom0 domains, this adjustment is applied by the
toolstack during domain creation, while for Dom0 or DomUs in Dom0, it is
handled directly during VGIC initialization. If eSPIs are not supported, th=
e
calculation defaults to using the standard SPI range, with a maximum value =
of
992 interrupt lines, as it works currently.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 

---
Changes in V8:
- added acked-by from Julien Grall

Changes in V7:
- no changes

Changes in V6:
- minor: updated the commit message

Changes in V5:
- fixed minor nits, no functional changes: updated the comment to make
  it clearer and corrected a misspelling
- added reviewed-by from Volodymyr Babchuk and from Oleksandr Tyshchenko

Changes in V4:
- consolidated the eSPI and SPI logic into a new inline function,
  vgic_def_nr_spis. Without eSPI support (either due to config being
  disabled or hardware not supporting it), it will return the regular SPI
  range, as it works currently. There are no functional changes compared
  with the previous patch version
- removed VGIC_DEF_MAX_SPI macro, to reduce the number of ifdefs

Changes in V3:
- renamed macro VGIC_DEF_NR_ESPIS to more appropriate VGIC_DEF_MAX_SPI
- added eSPI initialization for dom0less setups
- fixed comment with mentions about dom0less builds
- fixed formatting for lines with more than 80 symbols
- updated commit message

Changes in V2:
- no changes
---
 xen/arch/arm/dom0less-build.c   |  2 +-
 xen/arch/arm/domain_build.c     |  2 +-
 xen/arch/arm/include/asm/vgic.h | 19 +++++++++++++++++++
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 69b9ea22ce..02d5559102 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -285,7 +285,7 @@ void __init arch_create_domUs(struct dt_device_node *no=
de,
     {
         int vpl011_virq =3D GUEST_VPL011_SPI;
=20
-        d_cfg->arch.nr_spis =3D VGIC_DEF_NR_SPIS;
+        d_cfg->arch.nr_spis =3D vgic_def_nr_spis();
=20
         /*
          * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d91a71acfd..39eea0be00 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2054,7 +2054,7 @@ void __init create_dom0(void)
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
     dom0_cfg.arch.gic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
-    dom0_cfg.arch.nr_spis =3D VGIC_DEF_NR_SPIS;
+    dom0_cfg.arch.nr_spis =3D vgic_def_nr_spis();
     dom0_cfg.arch.tee_type =3D tee_get_type();
     dom0_cfg.max_vcpus =3D dom0_max_vcpus();
=20
diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index caffea092b..24a4a968c3 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -357,6 +357,25 @@ extern void vgic_check_inflight_irqs_pending(struct vc=
pu *v,
 /* Default number of vGIC SPIs. 32 are substracted to cover local IRQs. */
 #define VGIC_DEF_NR_SPIS (min(gic_number_lines(), VGIC_MAX_IRQS) - 32)
=20
+static inline unsigned int vgic_def_nr_spis(void)
+{
+#ifdef CONFIG_GICV3_ESPI
+    /*
+     * Check if the hardware supports extended SPIs (even if the appropria=
te
+     * config is set). If not, the common SPI range will be used. Otherwis=
e
+     * return the maximum eSPI INTID, supported by HW GIC, subtracted by 3=
2.
+     * For Dom0 and started at boot time DomUs we will add back this value
+     * during VGIC initialization. This ensures consistent handling for Do=
m0
+     * and other domains. For the regular SPI range interrupts in this cas=
e,
+     * the maximum value of VGIC_DEF_NR_SPIS will be used.
+     */
+    if ( gic_number_espis() > 0 )
+        return ESPI_BASE_INTID + min(gic_number_espis(), 1024U) - 32;
+#endif
+
+    return VGIC_DEF_NR_SPIS;
+}
+
 extern bool vgic_is_valid_line(struct domain *d, unsigned int virq);
=20
 static inline bool vgic_is_spi(struct domain *d, unsigned int virq)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:18:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:18:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116212.1462621 (Exim 4.92)
	(envelope-from )
	id 1uvvQk-0006o3-Hn; Tue, 09 Sep 2025 10:18:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116212.1462621; Tue, 09 Sep 2025 10:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvQk-0006nv-Eh; Tue, 09 Sep 2025 10:18:30 +0000
Received: by outflank-mailman (input) for mailman id 1116212;
 Tue, 09 Sep 2025 10:18:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvvQj-0006mE-8L
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:18:29 +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 53cdaf1d-8d66-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:18:28 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-45b9853e630so50375725e9.0
 for ; Tue, 09 Sep 2025 03:18:28 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45deff57c33sm8146705e9.1.2025.09.09.03.18.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 03:18: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: 53cdaf1d-8d66-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757413107; x=1758017907; 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=A8grYvfhvATeam8Zhil48UBjlD6r5yngkKE3+P2X+wk=;
        b=KJm5lWEQakAHtjLy5TqAbIWFoN/FopDlBa0hF5CGYsZeInythx9I8+lamVFbUZN8mY
         BSAvQmJziiPqTM/8fUH5c/Sehe671Ein1MIuGG3AKF15iiPrhaEobtvd/7z/J0eT6Dgw
         g8qMbPbp3DCezDvsAmdrTL51HZCLaU0Eg3GewEsNEmJn32YBC5sVEPStxI7DTAIczx75
         sPiCQB8Qh0+3NAZrygCvtSk2+jt7CQiCOueII0y8WobL2uQrAu2GEczphcDJTwk7aST8
         K+OJlegJsIqvQ665tQkc6HfnFmZsKxGHrMSnDxhrOGVpFkD9kXX5FQCyRtdkKamrq4gO
         MLzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757413107; x=1758017907;
        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=A8grYvfhvATeam8Zhil48UBjlD6r5yngkKE3+P2X+wk=;
        b=oaMrQ+BSiCKZ9RkBjOeSwRy5L4BR6gNILC0hK8BEPuA2VbrIQvlXOM1RKvX061FzIu
         3y+cC+kUr9dV5bEXlcsslQWuibkzxGiEPEc4ATuEgEM0DxH93dveImMOBYC3puQnlE5a
         h+OTd7M9JdA9XsfWWNkAxgSgThXgtjkzGo6QsY6OW+Ci50KgAoYNtXU62udp4NWtxNK6
         TMf+ImT9KsEV1OMrPnQg5yIY+a9jqXlvT7cltD9DXi8N6/0f2gVjmCq641XXVPEnptTH
         LX2RXF12kKp56r6z3+Qxwu9tjMhIqoPWX+Bj7J4qz2fnoofeJi/7zETzzTcAKM0ml4cM
         tP9w==
X-Forwarded-Encrypted: i=1; AJvYcCVfu+gxVtN6uHs8OqTS3P0hX07SxDDZa7vEWF9+tfh92sOr9e0u38KvNOZZp1duyJDdpiSO8yRzsZw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxL8/HU6GPUSYis1EHr0dd8nkc48QvfkU0ueMbAO6bS540hTRPO
	QbKFXOfNFCDlfrg2YLazkLpFjd7YrA4YJ7jZzhmBP8zKd3fPBSrOPahI0mKWDmFGvJc=
X-Gm-Gg: ASbGncs2G1n4dsrqmXo1z6ZZZvb336rHz6Np776KN3MlUA2VbrfE7cQ2I0Ja1TtX1v0
	t0E2Ss5EGt1azsgm5IG0VD1BS1jXga7IPLxspQ6OAF59cCG1M54Vt7DWh3M7AOrXaLslwmAXnxk
	2pLG2ktWtTDxyY4PKQpquvfIdLKL8ITRqzU8Xj9lT0thLxIz3GBTN1YaInpr94nAdSMRdmHgP8G
	AwCmhEhC6DW4xKH86U+KrzO555yHT3GgpM+2k2/GcnRQLxIJfkS6CRfIeR2ByFyKep1+jgtRDix
	Bjq6cpupg4yvBg67f2yqLadbB9dFQtMF/F/cXCqjRM3upzt+MwvhIMbuvp07jw0m7UhrxOa0vh+
	GD1axVDe10n52gqghRQ8bR44lnesLlAJc2dDaSYThrTPmBQjDtZIlJVSxeLKQ49+csZtv7iIYZw
	UnvYL9sgxfYu7qmfiks9k2FFEGVmrfrpdG/ob1gVZDMCJzpWo2bEHwGmY=
X-Google-Smtp-Source: AGHT+IFq9JnfrgPLbXyCwpmmKqs8DOJtKx0TjiU8QMOqT550rjxiM5W2xaCCLNf3pdnlpziCkYGPZw==
X-Received: by 2002:a05:600c:1987:b0:458:b01c:8f with SMTP id 5b1f17b1804b1-45ddde8a55cmr122253105e9.8.1757413107494;
        Tue, 09 Sep 2025 03:18:27 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 12:18:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/3] xenconsole: Add connection flag
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
 Anthony PERARD 
References: <20250822213946.245307-1-jason.andryuk@amd.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20250822213946.245307-1-jason.andryuk@amd.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------xudSpYz0pr2eOfa5ScIGtHBP"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------xudSpYz0pr2eOfa5ScIGtHBP
Content-Type: multipart/mixed; boundary="------------QXETNBHzrXRFC0bEI9FxNu9F";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Alejandro Vallejo ,
 Anthony PERARD 
Message-ID: 
Subject: Re: [PATCH v2 0/3] xenconsole: Add connection flag
References: <20250822213946.245307-1-jason.andryuk@amd.com>
In-Reply-To: <20250822213946.245307-1-jason.andryuk@amd.com>

--------------QXETNBHzrXRFC0bEI9FxNu9F
Content-Type: multipart/mixed; boundary="------------WyLpkjOUVjMz0vrcyfIXQGB2"

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

T24gMjIuMDguMjUgMjM6MzksIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IEFkZCBhIGNvbm5l
Y3Rpb24gZmxhZyB0byB0aGUgY29uc29sZSBpbnRlcmZhY2UgcGFnZSBzbyBhIGRvbWFpbiBj
YW4gdGVsbA0KPiBpZiBpdCBpcyBjb25uZWN0ZWQgb3Igbm90LiAgVGhpcyBiZWNhbWUgYSBz
ZXJpZXMgaW4gdjIgdG8gYWRkIGZsYWcNCj4gc2V0dGluZyB0byBsaWJ4ZW5ndWVzdC4NCj4g
DQo+IEphc29uIEFuZHJ5dWsgKDMpOg0KPiAgICB4ZW5jb25zb2xlOiBBZGQgY29ubmVjdGlv
biBmbGFnDQo+ICAgIGxpYnMvZ3Vlc3Q6IFNldCBjb25zb2xlIHBhZ2UgdG8gZGlzY29ubmVj
dGVkDQo+ICAgIGxpYnMvZ3Vlc3Q6IFNldCBjb25zb2xlIGFzIGRpc2Nvbm5lY3RlZCBvbiBy
ZXN1bWUNCj4gDQo+ICAgdG9vbHMvY29uc29sZS9kYWVtb24vaW8uYyAgICAgICAgICAgICAg
ICB8ICA0ICsrKw0KPiAgIHRvb2xzL2luY2x1ZGUveGVuZ3Vlc3QuaCAgICAgICAgICAgICAg
ICAgfCAgNCArKysNCj4gICB0b29scy9saWJzL2d1ZXN0L3hnX2RvbV9hcm0uYyAgICAgICAg
ICAgIHwgIDIgKy0NCj4gICB0b29scy9saWJzL2d1ZXN0L3hnX2RvbV9ib290LmMgICAgICAg
ICAgIHwgMzYgKysrKysrKysrKysrKysrKysrKysrKysrDQo+ICAgdG9vbHMvbGlicy9ndWVz
dC94Z19kb21feDg2LmMgICAgICAgICAgICB8ICA2ICsrLS0NCj4gICB0b29scy9saWJzL2d1
ZXN0L3hnX3NyX3Jlc3RvcmVfeDg2X2h2bS5jIHwgIDIgKy0NCj4gICB0b29scy9saWJzL2d1
ZXN0L3hnX3NyX3Jlc3RvcmVfeDg2X3B2LmMgIHwgIDEgKw0KPiAgIHhlbi9pbmNsdWRlL3B1
YmxpYy9pby9jb25zb2xlLmggICAgICAgICAgfCAxMyArKysrKysrKysNCj4gICA4IGZpbGVz
IGNoYW5nZWQsIDYzIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pDQo+IA0KDQpGb3Ig
dGhlIHNlcmllczoNCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNl
LmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------WyLpkjOUVjMz0vrcyfIXQGB2
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-----

--------------WyLpkjOUVjMz0vrcyfIXQGB2--

--------------QXETNBHzrXRFC0bEI9FxNu9F--

--------------xudSpYz0pr2eOfa5ScIGtHBP
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/Ey8FAmi//vIFAwAAAAAACgkQsN6d1ii/Ey9W
5wf/QPwm7dViKRKa9kxpnmMKrlzdzpF2PBnoQAMF1wVw7jakUQwhVhoxS5KpXyFXCS4vCenTMq2s
1Azv1Of1zHAnixOTgTVy2qxfy++bNryaxj8sI7e9TQyu2fIu1r39lI8W1nlkCfvQg5IqiGF66xm0
h40tIY6bKsEUhhhKXHRxdLh1ivamK4Mis6+omeAxd2RaxfqxgJKSi82cDPPjhhP/azZtkgEgI4AQ
NlYzIsIIP2wuZFppUfCY0nGNYDdtyDuEKstzXYYxMsUDBgFCw/U0mOtTs5v/4i34MRgxqWBqO+aK
b225D2vwrKFidJ7lzfG8nDOTGFQPL6r8b+JAyVA9Xg==
=MdWB
-----END PGP SIGNATURE-----

--------------xudSpYz0pr2eOfa5ScIGtHBP--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:19:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:19:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116242.1462632 (Exim 4.92)
	(envelope-from )
	id 1uvvRq-0007eV-2M; Tue, 09 Sep 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 1116242.1462632; Tue, 09 Sep 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 1uvvRp-0007eO-Up; Tue, 09 Sep 2025 10:19:37 +0000
Received: by outflank-mailman (input) for mailman id 1116242;
 Tue, 09 Sep 2025 10:19: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 1uvvII-0000yD-JL
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:46 +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 1bc6b1a4-8d65-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:09:45 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:39 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 1bc6b1a4-8d65-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JArrhoqG+j/InGzMl+jRgyENeuOXAoxBjzdKJ9j6k1KD3Nrq5/U2bcWqdO9ouhnpskcie19X9lfkKCD8sLMYqYo2pGeAo761OK3FNB3VrJeyowMxMNLR/JIHNoLVBnRq0qu9LAOzc/n5D0ILf+uK+NoJiiHsr0MPvxMcljkP7IXSYnBBS0m0VCn5f6UDGKDIJA7jsv4fwxczoouOduFVQTo5sQON6JD6jBTpbbLM8Dw94WNiWDxRjJ8Cb+gGqgNlw1TZikwEANoAAWt5515N15aoGcKyzWVlb1WjrZryvOUHmDTSByFhlDxjdzlQpcgFFC0C2WeadaWH2rnOugIj4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=a7fQLCSN2Xg5hczty36vhSzRR6D7dPrajIYlhliCz/g=;
 b=PTO8uXCjQeAjUXyW/vSA6+TpowNhsrhVSxMeX883Sm5x9Jb1BtqDQOafdudehGndiO4hYNThUawdo4jniiE9zzS1LtHM5ccx7njNeF9CR70IfoowF2tTFzol3G9GQMtz3wh0llcKgEFKGAp6EJERqE/a1M1YGskmf7e4SZdD3HzqkByOu1HVr9PMQXiBeZXb5yaxBF8t4cVycEbww7r2EwzbHPjFjWEuzpJb6nbzwGJNajoM6aERijmAkFHVdToGjti46q9z4fnmUdfOgak2vc7Ge4VrGZR7rElYqHFCnwvDnEAkv4cVGKaCbekffOnvekFl6HV9cPt5kzhxu1PO3A==
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=a7fQLCSN2Xg5hczty36vhSzRR6D7dPrajIYlhliCz/g=;
 b=fm2pDHOmaZUgVL/Nd1EhxOcDq4BQPeS+sdbJeqrU391ZkF5jnO4lzXxfUiZR4ADV3VJP/32My0NVuiH5l+GNF2GsBcUmAaoNaGR4iKn3KlJoODQqaCLlIeLwpCF0Tq4TVfbyPdik18SODrODzuayTadArgkSJ5u7HMvHIUzkxjcPaOwqCT5c4CIfzeHFjrYFTTGXpo/AZ9koEogjICEEM6fzTh2Ki0k+hABJKA63XcDtZ3ABaT7GW2hL1+Ly/iqM75Sloac6whFYP6bDFEQs/1ugGazLMfBc4qam/tW7dYojq+GjdFy8eqqqZpMAqRsohDfnJ89UZRwSMb0+HeyD9Q==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v8 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI support
Thread-Topic: [PATCH v8 12/12] CHANGELOG.md: add mention of GICv3.1 eSPI
 support
Thread-Index: AQHcIXHa6pa5FlfG8EaEsm5Ttfdaow==
Date: Tue, 9 Sep 2025 10:09:39 +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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: 4e55f229-bcb5-435c-868d-08ddef88fcc3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?XMlbbsjYdEhkQmIm76HKPFLZjUGZvXf/KCkIQ/toYIULpV2dAdNT/i95yk?=
 =?iso-8859-1?Q?RZzuz50S/EqNSZR/ghXUWMUTV+Utl5vpNwBurUPT2arxkiQpZ7Xvgw+5QT?=
 =?iso-8859-1?Q?XmPNq7AHbWdNJr15GJX2zLpF8ECnePkwVdTrRbwlrr7yPi+tUhJGNt2JQe?=
 =?iso-8859-1?Q?z1aPdo4WwsXRJ9Trr3z05gV3vVlm/mraSTqYzj3iNB6rkBtHgt742iJO5+?=
 =?iso-8859-1?Q?Gr2P0O0snW9FOv+/TgSmLaea8u2e1uJVpCUhoHk4JIxoIUgg+D37isxDuO?=
 =?iso-8859-1?Q?QU/q489rr2um/SYjvlOc15z44oHRkrBnp/yrls1IWmfwkWhEV0HgZmIUbg?=
 =?iso-8859-1?Q?CAZOaleOcvmPe86zPE51XmGMX13yXoQ8eqTwACwBFH8XqyRD+kK8DjBsCs?=
 =?iso-8859-1?Q?bm3WuZ9mlWZR75lvCaoWQ58Mw2XH037P1kC5m/e+sm2PLX86nN9Iorc+R0?=
 =?iso-8859-1?Q?af/cCwhsKZIDryZSURmSCNLQPjq6OEkFr0nQFbPQ6auqp/gWkyt+NwG99L?=
 =?iso-8859-1?Q?jmSzL7yZIKHrsZbBFcw1ycv2nAFgI0qctEqynJln3+ZG7pkx1pvYWqoetV?=
 =?iso-8859-1?Q?ZkNvU+PHJdk1Vc8V4L55IYp5NS068xcV0dzTyh5WWkJhFMyxOAqPZZNwyf?=
 =?iso-8859-1?Q?fJ4gyzjK+Kv3kPQMq3OepkNe/oxWO46pg41m+nUiPHYUQ9pPdWMZDMK17X?=
 =?iso-8859-1?Q?JISTawS9zfd8bCLWKfrlbC18nEyCnr0JP0KhEbOYiaqTIULct1inyX1/r0?=
 =?iso-8859-1?Q?8tXdG5FVrPDglXVmuDzywhjdd+E747fAH795f5jvruKxsCCBGjpIusHfE+?=
 =?iso-8859-1?Q?ni0h9CiAh4U0JCrEXMFlCQ9lwibPej5a7cFpAn/d+oMcgFAai7PncU6JKp?=
 =?iso-8859-1?Q?xkgumRPsUsfxrnL5YPbcobWAV1eBltEcRqSRW5va8Hg5fVGzDvdnXRziU8?=
 =?iso-8859-1?Q?mt39fUsyM1KjOTKM/PK2b5qbmNV+RZtKVzz/+bj3/X39YaHMWYxPxkzHF/?=
 =?iso-8859-1?Q?0YLrpZ6uhpSdMxdgvPgdiQFQsFQLMefcvVHh/y4q42qm7vSSddmoygV1QF?=
 =?iso-8859-1?Q?JsJKBBqA6VIbzwhQG24xNHFhEWN2IzjWDwDORqkqi/wXe3MVuFSlbubY+H?=
 =?iso-8859-1?Q?n1GFwOfFVbzTeC5G2ra6I4igVMyfBM6wpOtLXAjIBlicYyqLETM8+yCpWx?=
 =?iso-8859-1?Q?sNfdr97vt2EetGkcWZsoFFdaIUrq9vxjmOuUdOikXAxp3tXa3UpU1tTqxr?=
 =?iso-8859-1?Q?xxf04eO64iN6sNtGlwu2jiTuymU9mouNkrdHE2Yclo0zaLDqo5RgeizATj?=
 =?iso-8859-1?Q?lO2TtbJs0fey6+N8ilD18yoPQih7uSMzkDAwxR5tmb8TzoCZa0R8oMFygm?=
 =?iso-8859-1?Q?hLbtdr1NN9U/GcMq/2/SDmgaoe1TfSXGPt9s1fqjXzcuUm6QEOq6E5uoom?=
 =?iso-8859-1?Q?Y6E+Bb6K1cA3MXJEa5v3z3RnMyveOmmQ/w4rExHRnApxNI6BrqpEztlDd/?=
 =?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:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qQ7wJ23txBcY7+Ek+PIXSE3GeZetM1SxCoCBSrIADRAMmlvS9Q75kszJm0?=
 =?iso-8859-1?Q?O0PDqDh4pS4VtI6xchWwvDk8G+zamfj6MyYj7oBbDOTkb0wiKnedd1SHB4?=
 =?iso-8859-1?Q?6t5WWgDcAnr6Qwxt8pYrOadP0g91rB39FYko/b4yrMEeTzCvnapkeXWTAZ?=
 =?iso-8859-1?Q?DHKF4P45M4VnfwCdS2eiXDzuK2QWJWysIZdB4wqpjLzyaV9kUASqTkAEEN?=
 =?iso-8859-1?Q?qRCZ/Bh4SsN8lgF+rpAWo85oJkHCD6NML9tUJYFB6cmPVBkv1Dw9+SDgoW?=
 =?iso-8859-1?Q?lq2O0k6dlwfBDD+wWdkVqpxnBZu4Cy6tIQxGzg5uUKk9D420K0fIRlXafh?=
 =?iso-8859-1?Q?k0uTy9iWWw/JcaRSYqK5qXxHg3a70UjznY0EVDd67pYXY4LAMnbbma4Dr6?=
 =?iso-8859-1?Q?QXE73kY40TNWvtiyhWC8goQvHRA4406CczKILvp/ct1p70CWg32Yx9cCYk?=
 =?iso-8859-1?Q?50XbO/2pQE8cYhB1y39sDOjmoBcVYrCw/mfYWuP1Lj6HFpuoA2st/+zwkO?=
 =?iso-8859-1?Q?ayGJKT1SYtEPUGWbr2R5h5cIxIVggL+wNiKdKjE20msuSzm2C+jx4auMUM?=
 =?iso-8859-1?Q?NZyN4hWnLi0iIYqFkrNNuFF+D433GpUUkP7pMjrVhyvYPjn1tXvM0anIkY?=
 =?iso-8859-1?Q?kcuO5vVx/+BzjKQpwCwg5r8SjYbMScbH49jeg87rCKM4dI6mg5TNb4MhIR?=
 =?iso-8859-1?Q?oq0+yHxK6oOxcg4QUpkDEhjAfxomjBKjaa34sbuQ4N/IaFPI+nmC9txTe7?=
 =?iso-8859-1?Q?dgsJQMexknmFP2kHhncQVduvqZD/dzNPPUgmTaBis92GHdW5RjwLIzpQrf?=
 =?iso-8859-1?Q?n5OdfLcnWmgNBabvQt9AUHz4FkLmqESAXzaSDu0G6DVxQPriszq8kOWlQN?=
 =?iso-8859-1?Q?G9yBzQVXYzT4BmDMskYOOoMdval0kK+Sy5v84QPtQ0KBpcG5etU6XYfIzR?=
 =?iso-8859-1?Q?+k19xcV5HOqJ7lxEn9fxPujbMgBvnGOmYOXJ6zcKAk/i7eYo2Q6JIXPip0?=
 =?iso-8859-1?Q?fZpe3NkEASOtNjVQySBJ/P6hrNuG1NIJnrvE3n5NjhBi6bsfCPx2z+CkbR?=
 =?iso-8859-1?Q?ENcc0SwNJx0Unw3yq+QBhgeckHA3Gt48HfHsWo/iNie0c5Up+VEUgvvVN1?=
 =?iso-8859-1?Q?W7Fc6MbTDmgzzrEt4xq+mH/W45KeDT05FZuxvPBxo8DJtKmFBCQGF3DCDQ?=
 =?iso-8859-1?Q?3tzxgUCmCAyyjamboc1VySDlEDLzTctxQsm5O+QsRstuX1jEgqIQJRawpO?=
 =?iso-8859-1?Q?W6lT4Gt9JKWYXalBBtR6BrJQky9l9Jfpa4RILwVmuaz2BX9376Du3XE7p6?=
 =?iso-8859-1?Q?ULPqX09rTvUHZeDV2TUSRmni1X5Ajoh4gl7BrQ2/4USxmqKoKD34WoAwvu?=
 =?iso-8859-1?Q?ck2ggxMN7moM9C4mj6i/NdOFzzH+L7Qkpp/VD+oy0KA02Tqc2WoNEJ6gDw?=
 =?iso-8859-1?Q?6Xq+S4X7tVo/dh2Tj7In6QcW+GrFj6flELksrNIPFnJU3q4HTQW4ok/ULR?=
 =?iso-8859-1?Q?t1G0ipHU95dvkYes4gmU7cs1O58oEkIOb92LVj86qSTcib4xkrz5uKDL19?=
 =?iso-8859-1?Q?YimzCJXu76Z1Hili3LUVaSwxwM++D6AMr0VvHaTgN+8GLuUwOpLJN9UXF6?=
 =?iso-8859-1?Q?w51Z3lLS9YnhtCV7Rddqy9ZB1ERPsxxnFwZGrIriaRwi+SLyq67nim3LrZ?=
 =?iso-8859-1?Q?JhdrlOwAfS7PoHtW2bU=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e55f229-bcb5-435c-868d-08ddef88fcc3
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:39.1530
 (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: IPAxbgG8LYLAEkfrLssMY4+Uuwau8Z08Gmn+gV+fj5fmytmkMM2jofg2L5/5FJGG9QMPytOx15/S6wLHRnLMNhr3Us4gLyfd7lf8vSV9Er8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

The GICv3.1 eSPI (Extended Shared Peripheral Interrupts) range is
already supported with CONFIG_GICV3_ESPI enabled, so this feature should
be mentioned in CHANGELOG.md.

Signed-off-by: Leonid Komarianskyi 
Acked-by: Oleksii Kurochko

---
Changes in V8:
- no changes

Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- extended changelog update with a brief explanation of what eSPI is
- added acked-by from Oleksii Kurochko, which was received for V3:
  https://lore.kernel.org/xen-devel/bce5e07c-eee7-481b-a833-4d5d8bbce78f@gm=
ail.com/

Changes in V4:
- no changes

Changes in V3:
- introduced this patch
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5f31ca08fe..31b4ded444 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -29,6 +29,8 @@ The format is based on [Keep a Changelog](https://keepach=
angelog.com/en/1.0.0/)
=20
  - On Arm:
     - Ability to enable stack protector
+    - GICv3.1 eSPI (Extended Shared Peripheral Interrupts) support for Xen
+      and guest domains.
=20
 ### Removed
  - On x86:
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:21:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:21:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116258.1462641 (Exim 4.92)
	(envelope-from )
	id 1uvvTY-0000p0-Cz; Tue, 09 Sep 2025 10:21:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116258.1462641; Tue, 09 Sep 2025 10:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvTY-0000ot-AL; Tue, 09 Sep 2025 10:21:24 +0000
Received: by outflank-mailman (input) for mailman id 1116258;
 Tue, 09 Sep 2025 10:21: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 1uvvIW-0000yD-Pm
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:10:00 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 21c02a4c-8d65-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:09:55 +0200 (CEST)
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
 [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-364-F-NoBwFvNVGzEkfavRLWqg-1; Tue, 09 Sep 2025 06:09:53 -0400
Received: by mail-wr1-f72.google.com with SMTP id
 ffacd0b85a97d-3e403b84456so2723067f8f.0
 for ; Tue, 09 Sep 2025 03:09:52 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7522562d1sm1945921f8f.63.2025.09.09.03.09.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 03:09: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: 21c02a4c-8d65-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757412594;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=LqU+WGzmfGncFG5qyai0jHYVSP7TCxKOV9AhHT2zCnc=;
	b=EIH2P8zIcZYkDaCMrxLDGWHfPHP777hlvuk4rjzrd3EWHy82xAVFawnQA0eQ11KfPTUQIw
	mfMilZyTB/IPyohu6Inx1nvoomsXwhxl1TwV8jO+qcFWtUu16n9q54WBAzd+YUCW37T5WO
	MDo4/NDu6ELr7/8Lah8RGtOioePKBS0=
X-MC-Unique: F-NoBwFvNVGzEkfavRLWqg-1
X-Mimecast-MFC-AGG-ID: F-NoBwFvNVGzEkfavRLWqg_1757412592
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757412592; x=1758017392;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LqU+WGzmfGncFG5qyai0jHYVSP7TCxKOV9AhHT2zCnc=;
        b=Gp7QUQfQH6PNhVEkTy9IN3BIV6DrTFMhAnS8UV6TC8f+ul0vNSD31ERvj7B2Vwi1VQ
         +qlLeXOPDabQyaBC2eYUEU6zpJ4YUilV5pyxV5qY2k97cFEdUfUOMSuTPUX/a0W8gYOA
         tqH3VhMJs2lo2ZBlI5dzrjyb5YkmC1U6wv+wySgLgGuDKyenXFlKgh+RSjVGjLLL0FsO
         4EFEPtJkhj1p3MuMM80fuu9WDX/C5gyKdxtYPq0K9f0l89UD42mBLeNvKLfVn+ouXcDq
         XVGg0gaKQL8tvrpdNjD3d8JoABey3znWTU+1Wsq/Hq8aemVavXTw33tpaulfx4wLdwmU
         /NJQ==
X-Forwarded-Encrypted: i=1; AJvYcCUV+BHmEBsXQzMrFMoP9OkQwKJCjorFgOWt+HlXqjyx9CdJ9WSFSsZe+Tpvf+vQRfhA/T/7zcwc9+k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxE3CpQO4T6K1CqKb4GQ4QZd1VRYC1f1RHHdeFhMIq2bTzjLiDA
	kfu/dm8n96KqNSTj6FxbZnC146FdPr16QnoxC6QFQFlFVO6FxrI17s2CHd4+7pd4BNXvMbDPU+B
	ot7T+PVHMTCQ7yIGDLiB2eP6PUchqG7wrlb26qvd2BkAEpZzSAHsFUPAtigE3hgwhRufr
X-Gm-Gg: ASbGncskgl44NGAX/+6dgKcqBO+awMYNYkrCjvTTO6Bn00WsnFViUTGTwc5o0THJjKf
	LsXS/XsVaq5yMpi9IiLjYw2UDQ67M7Yh1xqAf0Fm4+IAB5XjRSdmIEB2pwUbOv1pENCz+y18red
	yH6313Bl/DiQYYfNwqeW9VDQlKQleFt9OJv5ZmJZOvW4PXfMI+2ZwC2tERJKs3y2P8pwQ9n2E4g
	f5MIQWLoF3NCqPMTg+mC7ZrJNYWndBEKkOw92yt7VcgDd4l3APVoT4sDn64PplDRVDtZxGDI76l
	TV/qClU0kvE/x3FdA/549yP7WU7IA5g1M4OhXmhqxCKwZkqprfWbHj/Ehkdo3mzdyouhCHlznH1
	SqpsNq0JOwXhO+BqBbcndr3CFJAnjC4dhm5Vp+199OxViGjzRnSdvhyzUJqIzpVfPUkA=
X-Received: by 2002:adf:8b1b:0:b0:3e6:b06c:5b2b with SMTP id ffacd0b85a97d-3e6b06c5fe0mr6424828f8f.10.1757412591688;
        Tue, 09 Sep 2025 03:09:51 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IE+6kYqxQMhMlrUNgHhh5IEpwCukAjnB2iBRVYizcIa9qqydeyLJ0L3jlngBNKljI3RpH7CHw==
X-Received: by 2002:adf:8b1b:0:b0:3e6:b06c:5b2b with SMTP id ffacd0b85a97d-3e6b06c5fe0mr6424776f8f.10.1757412591141;
        Tue, 09 Sep 2025 03:09:51 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 12:09:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: Kevin Brodsky , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: Q-YV4uTrfg9j_V2TJPjz5Tv31UTnRbFCfU6BHFRoHcQ_1757412592
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09.09.25 11:40, Alexander Gordeev wrote:
> On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
>>> (taking and returning no value). This is proving problematic in
>>> situations where leave() needs to restore some context back to its
>>> original state (before enter() was called). In particular, this
>>> makes it difficult to support the nesting of lazy_mmu sections -
>>> leave() does not know whether the matching enter() call occurred
>>> while lazy_mmu was already enabled, and whether to disable it or
>>> not.
>>>
>>> This patch gives all architectures the chance to store local state
>>> while inside a lazy_mmu section by making enter() return some value,
>>> storing it in a local variable, and having leave() take that value.
>>> That value is typed lazy_mmu_state_t - each architecture defining
>>> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
>>> For now we define it as int everywhere, which is sufficient to
>>> support nesting.
> ...
>>> {
>>> + lazy_mmu_state_t lazy_mmu_state;
>>> ...
>>> - arch_enter_lazy_mmu_mode();
>>> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
>>> ...
>>> - arch_leave_lazy_mmu_mode();
>>> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
>>> ...
>>> }
>>>
>>> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
>>>     lazy_mmu is already enabled, and it temporarily disables it by
>>>     calling leave() and then enter() again. Here we want to ensure
>>>     that any operation between the leave() and enter() calls is
>>>     completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
>>>     leave() to fully disable lazy_mmu. enter() will then re-enable it
>>>     - this achieves the expected behaviour, whether nesting occurred
>>>     before that function was called or not.
>>>
>>> Note: it is difficult to provide a default definition of
>>> lazy_mmu_state_t for architectures implementing lazy_mmu, because
>>> that definition would need to be available in
>>> arch/x86/include/asm/paravirt_types.h and adding a new generic
>>>    #include there is very tricky due to the existing header soup.
>>
>> Yeah, I was wondering about exactly that.
>>
>> In particular because LAZY_MMU_DEFAULT etc resides somewehere compeltely
>> different.
>>
>> Which raises the question: is using a new type really of any benefit here?
>>
>> Can't we just use an "enum lazy_mmu_state" and call it a day?
> 
> I could envision something completely different for this type on s390,
> e.g. a pointer to a per-cpu structure. So I would really ask to stick
> with the current approach.

Would that integrate well with LAZY_MMU_DEFAULT etc?

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:21:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:21:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116261.1462652 (Exim 4.92)
	(envelope-from )
	id 1uvvTj-000194-M1; Tue, 09 Sep 2025 10:21:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116261.1462652; Tue, 09 Sep 2025 10:21: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 1uvvTj-00018w-IE; Tue, 09 Sep 2025 10:21:35 +0000
Received: by outflank-mailman (input) for mailman id 1116261;
 Tue, 09 Sep 2025 10:21: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 1uvvI9-0001My-W4
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:38 +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 15f3f546-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:35 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:27 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 15f3f546-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rXvHfiZ1y8AHdP2QKxcwOv/UDY7xh/Z7oCeafGF7Y+bQb9R9NddZxXDvZfDbsJg01xcOY3eaz1s5HM4J2OpA4Fp/8jjkdKQEMCO83U/Z6P4uWX5HsqePOrlPKlihPVnfWXoh41MOhN3KfkVnQlD9GF15TLAzztyvyUGdDYhpbnH9oJT2gCmKemvcElKMjtnUmNvs45gwUNIHVuGkcGbbU6cJpotdat3gRTKtXprUJamrReimeEN/MjN35wJxsJ+H+FbH1jrqr7L2JSsXiHl4ZJLhvEFAsLia4xUIJ+Ed6wSu95kbquDdbGAuWoMGox8SooJBUJFbrp0sVCngDHyUDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+KSmiu/S9+GDUlRSRi8m0qwuFH79DCF3EJZkKQ62VV4=;
 b=iVp+LzxrazhjGLKSxpM//vomGhWp2wrMW024B399+24JaECsu9c4oqf6FOp7uUMcjs+vO2yGqsstVl5YxSbpINVWNFvpOZIBJQzRyQKYiQy0swCot8h/Vb2C5wfrKajbp/w2AeG5GXShGvfnpm/ryW41j8E2wfp1rnfqJjBvC9sFcljVeN1CJRRQHD1VGNIhYUK/lYVFQyR13mWVciJPShga/YCqOb5krb+6p5Y0OuleD7nuLw/xgAuWBpRKmdhanIExyyMG/cmqXxfFxtgXmrCAZK3vWYpfukp67c4CSiwUIqmKkjZGVqxTTsVsOs4SuppCBIu300pvVhbbPfA+Pg==
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=+KSmiu/S9+GDUlRSRi8m0qwuFH79DCF3EJZkKQ62VV4=;
 b=uYeIQjhpx1PzEEMkkzPDbYbTqanfY6JfIV5hM5UEoXrSmUP8QEok/GJj2TU5YPfo2H3CsAfVtuY2tUpzYKf5jaV1ZMc7frnqjT7x9MZlar5wf3AgZH2W+bem0Mf/EIQJlz2o60acwxaNDh5MlBXjLmmiX4XVdqUTIVKrNwcWFrWgIhxJWIVY9SCEMAUZDFyvwCBVftJBSFYBTI7ZfkQj6IjwgmoCa6y0NeFOJaMB/M5LPuKqMODS9rQcuhhe83u2i47lyTVNapnaac2xzIlkuP/sq3+vHepuY+zBesHLr8tWk36GkajAT9UL5ZwTpSbqnK0o7MAhelXXcbZ+NFCpeA==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	, Volodymyr Babchuk
	, Julien Grall 
Subject: [PATCH v8 08/12] xen/arm: vgic: add resource management for extended
 SPIs
Thread-Topic: [PATCH v8 08/12] xen/arm: vgic: add resource management for
 extended SPIs
Thread-Index: AQHcIXHSFZfGO31880KRZV6MierZkg==
Date: Tue, 9 Sep 2025 10:09:26 +0000
Message-ID:
 <368bb1e6842beac65151f02ee6491fcf8a819c02.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: ffbb3c91-80b4-43f6-5743-08ddef88f57c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Xt6Y00o6LinjQCVbxuyxrjNcjcaB92fKooUxvEW+Jjx2WSoL8v/HMlmHlh?=
 =?iso-8859-1?Q?RVrq1xpyZ+EPdUgNGkAGe7dB4sqGJDijwUr5YhnDHxcyedR+aYvnrSMiZ0?=
 =?iso-8859-1?Q?Prs1tX3cI2/aizjEXE6NPgGk/vtEVsGDPL88CYWrBVUMVh1yrTEKeZHZes?=
 =?iso-8859-1?Q?nQdAkWzjx7tNLGyWK0iORwAQtfM5ZcDTL9dBamtNGvFVNueltSYBqxUsPm?=
 =?iso-8859-1?Q?KZ81R6A+r56WNBKCXat0wkAyERnvMm9QNQTSoU8QH9t3YdtXJUq7KynHDA?=
 =?iso-8859-1?Q?ZPdtblhLAonTIA8pIZ90CiqkU/AATUwp5chlcnCXJdyalJZpDzGh+rcm13?=
 =?iso-8859-1?Q?e71QFStCcwYToxsh4NrsD3E/xccCHwQeQw3qe8vf74PQnLc8Bd/Kpn2ypE?=
 =?iso-8859-1?Q?v2+Y0NeODWRfL/NCXbGLXD1WJ42wCiz9ZDel+K6g+RJs7aw2SmVCfbONA5?=
 =?iso-8859-1?Q?67WDRL3ukAuQUHsuKHp1sIPSnuAak+rwGtuIkCNuVcmYAUl6RZr3cXykDb?=
 =?iso-8859-1?Q?o5YW7pPBSy54njjVugL4bVBaobz+4R1FYQA0f+13olc0Hb2xSmwicwqtNR?=
 =?iso-8859-1?Q?5t61Y5jWsK3R8ST2kOb7BuHIhdN/fdOJ+qwCTvjCr/cTHMS8IzFAmELQNa?=
 =?iso-8859-1?Q?f/OVFJvP16OJP1bavCS5e2JwRF2FbgCRaAZuFEDflaynzvMauQWjYo8BxH?=
 =?iso-8859-1?Q?XSAAyppXKXP7RK6l4ZoZYuPTJt5OkthYF9y+oodHLeeag1nbh4KVP99Uww?=
 =?iso-8859-1?Q?ViihQ7cGIjQLoICTtgBJrQSdxhyLB3tDt8rupByzJRrFDe4tR2u0vLltin?=
 =?iso-8859-1?Q?2z0Au2Pry6HmvGJoMXvXYbIoqwhWLrtmu+rhTCA+ThkKfKXKXDvsTzOYSJ?=
 =?iso-8859-1?Q?PLJJhs4CrWORGtp8MuSxNsY1xWuaLD+3IkASMRjem2ITUIMPCHJGnn23cf?=
 =?iso-8859-1?Q?klVzkkGVu7gCAWLriZ6NoxuFqDmV8BU6yVarrTBN4gOr797efqMmyErlIL?=
 =?iso-8859-1?Q?9rmshxuW17phYnDmeLdFJXz51flD9m31lYggBrZVNGvsknf6O0tqM6dFTR?=
 =?iso-8859-1?Q?2bBeKzPSVh4mGUlFpJnbEmClcHRVUbox8S/5Jw6IJqNV+f0UfxhatEqI/0?=
 =?iso-8859-1?Q?mXHSbCRy4vlVg0KulxZn+F/iXxArab3KsepF29g4QFlsOzcFYZ646ZAJZS?=
 =?iso-8859-1?Q?iBJGxuLkpy/+Im2JzGRouNJB5ToKJt4MJqL7kr5wyiQrMIDSWq2zY6fYeY?=
 =?iso-8859-1?Q?xz2iQ2W2TZTP9xVKPJGnJlrhIF2kMy9Z7etvPoGrWeEoBLz+JG8DjMUWC3?=
 =?iso-8859-1?Q?oFASgTtQsDB2L/VOAvBXveL2CmP7qtstmIMIQa7io6zUO0C8FLtFYQkZio?=
 =?iso-8859-1?Q?JNEi5rD1m6zDIHvqgr2mRDZrEQcJ7FVcUqZ1lY0A6LDh/m6WEnugnRrj3Y?=
 =?iso-8859-1?Q?On+hMdJWMkp2tJnRI60Fl8TTTWaCFxtRDWXz+doXLAFgjkyG/3ZhNDYUcp?=
 =?iso-8859-1?Q?hPAm/sDYbS1f8hcMrH3uuIxSQ4Pr7ZAT+WE31clS+Jxw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?I3ixdCl1N6yGUHcY3cbnG0EL9xhESY4HcY9fqkBgLFdhDGMGD3jWm50TKP?=
 =?iso-8859-1?Q?ZoSKg6lfMZzdsicvwbUjx1ScWF6tv9CgGMK4YikbmUu958gx1IDi3L0DRi?=
 =?iso-8859-1?Q?PfzKKcKQx3JUeyKEdrxRR9dGwX2FbtCm8S2WVMvi5KbT6TiocHtY3BMbl0?=
 =?iso-8859-1?Q?893ZSr1ftJm4E8e0isi/B3ymi0oWMd83mqu6yMmv6FJFtpx8wpPuKlUcIO?=
 =?iso-8859-1?Q?JsFp49EOFQ7PVH6dYXOpt8p72flFtCcs6L9Lazq4SfmWWHeBMM936Oh1iV?=
 =?iso-8859-1?Q?39+Uq0M+4XDkMl/zoOErAL0SxXH0D2sMF0VDS+zvjqCSdeQyC8gnZ7RWRP?=
 =?iso-8859-1?Q?OeyWd5WeKl2nYk8JbjkidSxnrjm3/cqGdASJfnqBOspyQ3y2rB7i3p/ydT?=
 =?iso-8859-1?Q?cjSPVs5FKJ8Xxh83Nvu5Y2AlCAbJRR4yBkCMnuOAfvlW4LZo4DuMmedrIO?=
 =?iso-8859-1?Q?0c/HPwffWWdr8ezJSsilx1rTvjwLQmhLhx5dv2kW8FGCvUrzyp5S+jQ63I?=
 =?iso-8859-1?Q?anpNHUkmE8Dk1yifr6p4Psfy1Bqcz+JHHOL3SrAAmMTnsCYVJ1Sk3e4sgP?=
 =?iso-8859-1?Q?CmhU+rcamINIhr27XipqlVlTLBMcf7wNuTcvO4Z+A3cJ+ZPGc3ho6DLZs2?=
 =?iso-8859-1?Q?j2Kho8WO7NP+mlXKFnR1nv8LnGcw2haiBcpnoX3N/sZd43t4ME9hbydgTN?=
 =?iso-8859-1?Q?n34X22qAgeHJhg6keJOLtJiSXuHG6KWZmlup26YzuWHU+a6gARm9i/0tXH?=
 =?iso-8859-1?Q?XXZJHParMGr2o2kIgMBle6xKPgDXemTiB24RG1mYLrFgy/kepVqEMRxd+K?=
 =?iso-8859-1?Q?gJ48bIHAWoXRTABWQ1S9UqYC83gzaZVSOPidPLgBUxIzvd4XuPflGpbVbI?=
 =?iso-8859-1?Q?gFdAMCZAduxUKza893KMAu9fnBaB53w9tFE20sdbhJ4JO3Y5VUn0vTg81/?=
 =?iso-8859-1?Q?nr222S0eqK/s+0BGdYbiTf/95woPhdWWFSIwgVeb83AMXRrJ4NxFyNmEy1?=
 =?iso-8859-1?Q?LRl8VQwxkAI+2Lx+l2xrHa8Cqay6fTlea9oaO62O6fLdzX+VjzlCcS1xFj?=
 =?iso-8859-1?Q?jp1SSgaOpZI9eH3UmHVnoGY8KPafMGSoLoKdA3Odts4M6CJOii1lsbT5uQ?=
 =?iso-8859-1?Q?ng+5YyVsiRhUOSmWkVwN7v41VtidHeei2ZOoKqiA8M/0VJ508+BBDkyKJw?=
 =?iso-8859-1?Q?cBSm7kmSGcQ8obXuRoLmqRuv+r5t6QNe6me+/wOOyWyxlsdbTf+CosUSX2?=
 =?iso-8859-1?Q?+ZiRcgsHCOuYRDpqRt1vzZNOpQidTTc9USEsyROGEPeyKDP4gDyif0sUcc?=
 =?iso-8859-1?Q?A1tXp9WR+hoU9qrJzx/jEZC7a/tBy0SmrTVxmWRSwqRI/o9vukQZ8M8oks?=
 =?iso-8859-1?Q?nvEBvDuBETnbwXs49HGtKOs5MSWDVe1BrYpn9C82LKQm45gsCj6VzpiOH/?=
 =?iso-8859-1?Q?1nZNIByy4hSfdpV8ZCpRy5UZiPfMTPqKacTETLeh5Wv6u5vH75kXvT/nyU?=
 =?iso-8859-1?Q?Dahais/1r5hrFXlI6DU70lvMgtegBVAlBZ8L2FxLZaCG8X1OebxtkhJmAu?=
 =?iso-8859-1?Q?4krwNUauMRdcOR6ixT9YdlT/bxyIr3Ku3xDSJTSbyCfIhFYdxX6Ypx57Jw?=
 =?iso-8859-1?Q?fCCMXjiWu0AWbuLIYr4P/KrdIhc95D6kFQIALgcEbJB10gQ8cmmjgfYm8Q?=
 =?iso-8859-1?Q?IysfpJ08WYnOzmZ1ZXU=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ffbb3c91-80b4-43f6-5743-08ddef88f57c
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:26.8772
 (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: Bq7w+7OzcTpK5V2kWHaKb05Ta2mbJBCHHprkPuE8K+TmnSony7l+I+At3S9ges+JfdRD2QdDhmc3Zg2/aj34+r8b+tv3PjMZG6ShgE2vUBo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
number of eSPIs, based on what is supported by the hardware and
requested by the guest. A new field, ext_shared_irqs, is added
to the VGIC structure to store information about eSPIs, similar
to how shared_irqs is used for regular SPIs.

Since the eSPI range starts at INTID 4096 and INTIDs between 1025
and 4095 are reserved, helper macros are introduced to simplify the
transformation of indices and to enable easier access to eSPI-specific
resources. These changes prepare the VGIC for processing eSPIs as
required by future functionality.

The initialization and deinitialization paths for vgic have been updated
to allocate and free these resources appropriately. Additionally,
updated handling of INTIDs greater than 1024, passed from the toolstack
during domain creation, and verification logic ensures only valid SPI or
eSPI INTIDs are used.

The existing SPI behavior remains unaffected when guests do not request
eSPIs, GIC hardware does not support them, or the CONFIG_GICV3_ESPI
option is disabled.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V8:
- minor: add variables in vgic_reserve_virq() and spi_to_pending() to
  avoid reading from objects that are possibly affected by order of
  evaluation (fixing 2 cautions of MC3A2.R13.2)
- added reviewed-by from Volodymyr Babchuk
- added acked-by from Julien Grall

Changes in V7:
- minor: changed hardcoded value of 32 to NR_LOCAL_IRQS
- minor: used local variable idx in spi_to_pending() and vgic_reserve_virq(=
)
- minor: added a comment for allocated_irqs and pending_irqs with index
  mappings
- added reviewed-by from Oleksandr Tyshchenko

Changes for V6:
- introduced a new function for index to virq conversion, idx_to_virq.
  This allows the removal of eSPI-specific functions and enables the
  reuse of existing code for regular SPIs
- fixed the return value of vgic_allocate_virq in the case of eSPI
- updated the error message in route_irq_to_guest(). To simplify it and
  avoid overcomplicating with INTID ranges, propose removing the
  information about the max number of IRQs
- fixed eSPI rank initialization to avoid using EXT_RANK_IDX2NUM for
  converting the eSPI rank to the extended range
- updated the recalculation logic to avoid the nr_spis > 1020 -
  NR_LOCAL_IRQS check when nr_spis is reassigned in the case of eSPI
- fixed formatting issues for macros
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch
- minor change: changed int to unsigned int for nr_espis

Changes in V5:
- removed the has_espi field because it can be determined by checking
  whether domain->arch.vgic.nr_espis is zero or not
- since vgic_ext_rank_offset is not used in this patch, it has been
  moved to the appropriate patch in the patch series, which implements
  vgic eSPI registers emulation and requires this function
- removed ifdefs for eSPI-specific macros to reduce the number of ifdefs
  and code duplication in further changes
- fixed minor nit: used %pd for printing domain with its ID

Changes in V4:
- added has_espi field to simplify determining whether a domain is able
  to operate with eSPI
- fixed formatting issues and misspellings

Changes in V3:
- fixed formatting for lines with more than 80 symbols
- introduced helper functions to be able to use stubs in case of
  CONFIG_GICV3_ESPI disabled, and as a result, reduce the number of
  #ifdefs
- fixed checks for nr_spis in domain_vgic_init
- updated comment about nr_spis adjustments with dom0less mention
- moved comment with additional explanations before checks
- used unsigned int for indexes since they cannot be negative
- removed unnecessary parentheses
- move vgic_ext_rank_offset to the below ifdef guard, to reduce the
  number of ifdefs

Changes in V2:
- change is_espi_rank to is_valid_espi_rank to verify whether the array
  element ext_shared_irqs exists. The previous version, is_espi_rank,
  only checked if the rank index was less than the maximum possible eSPI
  rank index, but this could potentially result in accessing a
  non-existing array element. To address this, is_valid_espi_rank was
  introduced, which ensures that the required eSPI rank exists
- move gic_number_espis to
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
- update vgic_is_valid_irq checks to allow operating with eSPIs
- remove redundant newline in vgic_allocate_virq
---
 xen/arch/arm/include/asm/vgic.h |  26 ++++-
 xen/arch/arm/irq.c              |   3 +-
 xen/arch/arm/vgic.c             | 190 ++++++++++++++++++++++++++++++--
 3 files changed, 203 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 3e7cbbb196..caffea092b 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -144,11 +144,25 @@ struct vgic_dist {
     spinlock_t lock;
     uint32_t ctlr;
     int nr_spis; /* Number of SPIs */
-    unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
+    /*
+     * Bitmap of allocated IRQs with the following index mapping:
+     * Local IRQs [0..31]
+     * Regular SPIs [32..nr_spis + 31]
+     * Optional, if supported:
+     * Extended SPIs [nr_spis + 32..nr_spis + nr_espis + 31]
+     */
+    unsigned long *allocated_irqs;
     struct vgic_irq_rank *shared_irqs;
+#ifdef CONFIG_GICV3_ESPI
+    struct vgic_irq_rank *ext_shared_irqs;
+    unsigned int nr_espis; /* Number of extended SPIs */
+#endif
     /*
      * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
-     * struct arch_vcpu.
+     * struct arch_vcpu. The index mapping is as follows:
+     * Regular SPIs [0..nr_spis - 1]
+     * Optional, if supported:
+     * eSPIs [nr_spis..nr_spis + nr_espis - 1]
      */
     struct pending_irq *pending_irqs;
     /* Base address for guest GIC */
@@ -243,6 +257,14 @@ struct vgic_ops {
 /* Number of ranks of interrupt registers for a domain */
 #define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
=20
+#ifdef CONFIG_GICV3_ESPI
+#define DOMAIN_NR_EXT_RANKS(d) (((d)->arch.vgic.nr_espis + 31) / 32)
+#endif
+#define EXT_RANK_MIN (ESPI_BASE_INTID / 32)
+#define EXT_RANK_MAX ((ESPI_MAX_INTID + 31) / 32)
+#define EXT_RANK_NUM2IDX(num) ((num) - EXT_RANK_MIN)
+#define EXT_RANK_IDX2NUM(idx) ((idx) + EXT_RANK_MIN)
+
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
=20
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 80befc2913..c3d4d63d88 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -487,8 +487,7 @@ int route_irq_to_guest(struct domain *d, unsigned int v=
irq,
     if ( !vgic_is_valid_line(d, virq) )
     {
         printk(XENLOG_G_ERR
-               "the vIRQ number %u is too high for domain %u (max =3D %u)\=
n",
-               irq, d->domain_id, vgic_num_irqs(d));
+               "invalid vIRQ number %u for domain %pd\n", irq, d);
         return -EINVAL;
     }
=20
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 2bbf4d99aa..eb22de6aa6 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,11 +25,61 @@
 #include 
=20
=20
+static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx)
+{
+    if ( idx >=3D vgic_num_irqs(d) )
+        return espi_idx_to_intid(idx - vgic_num_irqs(d));
+
+    return idx;
+}
+
 bool vgic_is_valid_line(struct domain *d, unsigned int virq)
 {
+#ifdef CONFIG_GICV3_ESPI
+    if ( virq >=3D ESPI_BASE_INTID &&
+         virq < espi_idx_to_intid(d->arch.vgic.nr_espis) )
+        return true;
+#endif
+
     return virq < vgic_num_irqs(d);
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+/*
+ * Since eSPI indexes start from 4096 and numbers from 1024 to
+ * 4095 are forbidden, we need to check both lower and upper
+ * limits for ranks.
+ */
+static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
+{
+    return rank >=3D EXT_RANK_MIN &&
+           EXT_RANK_NUM2IDX(rank) < DOMAIN_NR_EXT_RANKS(d);
+}
+
+static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
+                                                       unsigned int rank)
+{
+    return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)];
+}
+
+#else
+static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank)
+{
+    return false;
+}
+
+/*
+ * This function is stub and will not be called if CONFIG_GICV3_ESPI=3Dn,
+ * because in this case, is_valid_espi_rank will always return false.
+ */
+static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v,
+                                                       unsigned int rank)
+{
+    ASSERT_UNREACHABLE();
+    return NULL;
+}
+#endif
+
 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v,
                                                   unsigned int rank)
 {
@@ -37,6 +87,8 @@ static inline struct vgic_irq_rank *vgic_get_rank(struct =
vcpu *v,
         return v->arch.vgic.private_irqs;
     else if ( rank <=3D DOMAIN_NR_RANKS(v->domain) )
         return &v->domain->arch.vgic.shared_irqs[rank - 1];
+    else if ( is_valid_espi_rank(v->domain, rank) )
+        return vgic_get_espi_rank(v, rank);
     else
         return NULL;
 }
@@ -117,6 +169,54 @@ int domain_vgic_register(struct domain *d, unsigned in=
t *mmio_count)
     return 0;
 }
=20
+#ifdef CONFIG_GICV3_ESPI
+static unsigned int vgic_num_spi_lines(struct domain *d)
+{
+    return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
+}
+
+static int init_vgic_espi(struct domain *d)
+{
+    unsigned int i, idx;
+
+    if ( d->arch.vgic.nr_espis =3D=3D 0 )
+        return 0;
+
+    d->arch.vgic.ext_shared_irqs =3D
+        xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_EXT_RANKS(d));
+    if ( d->arch.vgic.ext_shared_irqs =3D=3D NULL )
+        return -ENOMEM;
+
+    for ( i =3D d->arch.vgic.nr_spis, idx =3D 0;
+          i < vgic_num_spi_lines(d); i++, idx++ )
+        vgic_init_pending_irq(&d->arch.vgic.pending_irqs[i],
+                              espi_idx_to_intid(idx));
+
+    for ( i =3D 0; i < DOMAIN_NR_EXT_RANKS(d); i++ )
+        vgic_rank_init(&d->arch.vgic.ext_shared_irqs[i],
+                       EXT_RANK_IDX2NUM(i), 0);
+
+    return 0;
+}
+
+#else
+static int init_vgic_espi(struct domain *d)
+{
+    return 0;
+}
+
+static unsigned int vgic_num_spi_lines(struct domain *d)
+{
+    return d->arch.vgic.nr_spis;
+}
+
+#endif
+
+static unsigned int vgic_num_alloc_irqs(struct domain *d)
+{
+    return vgic_num_spi_lines(d) + NR_LOCAL_IRQS;
+}
+
 int domain_vgic_init(struct domain *d, unsigned int nr_spis)
 {
     int i;
@@ -133,7 +233,39 @@ int domain_vgic_init(struct domain *d, unsigned int nr=
_spis)
=20
     /* Limit the number of virtual SPIs supported to (1020 - 32) =3D 988  =
*/
     if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+#ifndef CONFIG_GICV3_ESPI
         return -EINVAL;
+#else
+    {
+        /*
+         * During domain creation, the dom0less DomUs code or toolstack
+         * specifies the maximum INTID, which is defined in the domain
+         * config subtracted by 32 to cover the local IRQs (please see
+         * the comment to VGIC_DEF_NR_SPIS). To compute the actual number
+         * of eSPI that will be usable for, add back 32 (NR_LOCAL_IRQS).
+         */
+        nr_spis +=3D NR_LOCAL_IRQS;
+        if ( nr_spis > espi_idx_to_intid(NR_ESPI_IRQS) )
+            return -EINVAL;
+
+        if ( nr_spis >=3D ESPI_BASE_INTID )
+        {
+            unsigned int nr_espis =3D min(nr_spis - ESPI_BASE_INTID, 1024U=
);
+
+            /* Verify if GIC HW can handle provided INTID */
+            if ( nr_espis > gic_number_espis() )
+                return -EINVAL;
+
+            d->arch.vgic.nr_espis =3D nr_espis;
+            /* Set the maximum available number for regular SPIs */
+            nr_spis =3D VGIC_DEF_NR_SPIS;
+        }
+        else
+        {
+            return -EINVAL;
+        }
+    }
+#endif
=20
     d->arch.vgic.nr_spis =3D nr_spis;
=20
@@ -145,7 +277,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_=
spis)
         return -ENOMEM;
=20
     d->arch.vgic.pending_irqs =3D
-        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
+        xzalloc_array(struct pending_irq, vgic_num_spi_lines(d));
     if ( d->arch.vgic.pending_irqs =3D=3D NULL )
         return -ENOMEM;
=20
@@ -156,12 +288,16 @@ int domain_vgic_init(struct domain *d, unsigned int n=
r_spis)
     for ( i =3D 0; i < DOMAIN_NR_RANKS(d); i++ )
         vgic_rank_init(&d->arch.vgic.shared_irqs[i], i + 1, 0);
=20
+    ret =3D init_vgic_espi(d);
+    if ( ret )
+        return ret;
+
     ret =3D d->arch.vgic.handler->domain_init(d);
     if ( ret )
         return ret;
=20
     d->arch.vgic.allocated_irqs =3D
-        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
+        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_alloc_irqs(d))=
);
     if ( !d->arch.vgic.allocated_irqs )
         return -ENOMEM;
=20
@@ -182,9 +318,12 @@ void domain_vgic_free(struct domain *d)
     int i;
     int ret;
=20
-    for ( i =3D 0; i < (d->arch.vgic.nr_spis); i++ )
+    for ( i =3D NR_LOCAL_IRQS; i < vgic_num_alloc_irqs(d); i++ )
     {
-        struct pending_irq *p =3D spi_to_pending(d, i + 32);
+        struct pending_irq *p;
+        unsigned int virq =3D idx_to_virq(d, i);
+
+        p =3D spi_to_pending(d, virq);
=20
         if ( p->desc )
         {
@@ -198,6 +337,9 @@ void domain_vgic_free(struct domain *d)
     if ( d->arch.vgic.handler )
         d->arch.vgic.handler->domain_free(d);
     xfree(d->arch.vgic.shared_irqs);
+#ifdef CONFIG_GICV3_ESPI
+    xfree(d->arch.vgic.ext_shared_irqs);
+#endif
     xfree(d->arch.vgic.pending_irqs);
     xfree(d->arch.vgic.allocated_irqs);
 }
@@ -323,10 +465,12 @@ void arch_move_irqs(struct vcpu *v)
      */
     ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
=20
-    for ( i =3D 32; i < vgic_num_irqs(d); i++ )
+    for ( i =3D NR_LOCAL_IRQS; i < vgic_num_alloc_irqs(d); i++ )
     {
-        v_target =3D vgic_get_target_vcpu(v, i);
-        p =3D irq_to_pending(v_target, i);
+        unsigned int virq =3D idx_to_virq(d, i);
+
+        v_target =3D vgic_get_target_vcpu(v, virq);
+        p =3D irq_to_pending(v_target, virq);
=20
         if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->s=
tatus) )
             irq_set_affinity(p->desc, cpu_mask);
@@ -539,15 +683,28 @@ struct pending_irq *irq_to_pending(struct vcpu *v, un=
signed int irq)
     else if ( is_lpi(irq) )
         n =3D v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq)=
;
     else
-        n =3D &v->domain->arch.vgic.pending_irqs[irq - 32];
+        n =3D spi_to_pending(v->domain, irq);
     return n;
 }
=20
 struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq)
 {
+    unsigned int idx;
+
     ASSERT(irq >=3D NR_LOCAL_IRQS);
=20
-    return &d->arch.vgic.pending_irqs[irq - 32];
+    if ( is_espi(irq) )
+    {
+        unsigned int nr_spis =3D d->arch.vgic.nr_spis;
+
+        idx =3D espi_intid_to_idx(irq) + nr_spis;
+    }
+    else
+    {
+        idx =3D irq - NR_LOCAL_IRQS;
+    }
+
+    return &d->arch.vgic.pending_irqs[idx];
 }
=20
 void vgic_clear_pending_irqs(struct vcpu *v)
@@ -665,10 +822,19 @@ bool vgic_emulate(struct cpu_user_regs *regs, union h=
sr hsr)
=20
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
+    unsigned int idx =3D virq;
+
     if ( !vgic_is_valid_line(d, virq) )
         return false;
=20
-    return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+    if ( is_espi(virq) )
+    {
+        unsigned int num_regular_irqs =3D vgic_num_irqs(d);
+
+        idx =3D espi_intid_to_idx(virq) + num_regular_irqs;
+    }
+
+    return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs);
 }
=20
 int vgic_allocate_virq(struct domain *d, bool spi)
@@ -685,7 +851,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
     else
     {
         first =3D 32;
-        end =3D vgic_num_irqs(d);
+        end =3D vgic_num_alloc_irqs(d);
     }
=20
     /*
@@ -700,7 +866,7 @@ int vgic_allocate_virq(struct domain *d, bool spi)
     }
     while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
=20
-    return virq;
+    return idx_to_virq(d, virq);
 }
=20
 void vgic_free_virq(struct domain *d, unsigned int virq)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:22:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:22:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116289.1462662 (Exim 4.92)
	(envelope-from )
	id 1uvvUR-00021n-4F; Tue, 09 Sep 2025 10:22:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116289.1462662; Tue, 09 Sep 2025 10:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvUR-00021g-1F; Tue, 09 Sep 2025 10:22:19 +0000
Received: by outflank-mailman (input) for mailman id 1116289;
 Tue, 09 Sep 2025 10:22:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvvI3-0001My-Ur
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:31 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 12a0d1da-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:29 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:23 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 12a0d1da-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yqTAwCKlpOGsE3qP2pCZMtVDz3kE/TVwI7M++Tx9pp8ep41CaYA5ik2LetQIs8cl9mhjHj9+o2y1JsZ/IN6O44230JN3aa6XUtkxGtgznKzFuWiQE+b/CzkVT7zHgC/yYUQ5XDUvtHxCAIKINN83oPC3DJpxN1/IXRqbzLZv4Q7peAJ1YvOzDWJd4xG08aehC/x8WNCJXcSFAKPxXY1i3wTaaBayFW6mkASJBQVFKO7KLolCUYgW41/QysGtR4aPWWw1IESt0gN4mIWdkhM4VaPF0Wlp4Yy1KhIFPAXv1hk4X2Nodv9r/lmcsbh1nZYSDDE7eHBmy4JHnLget06J3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NK2ANacRUU7NJsl4Hbi5dxeY3QEVv3ULJVeqrFBFYdw=;
 b=l4/PK4tdGEbLumBta3OMCSyAh3Omx3Ykx+Kd7kjFHGzKT6oEmhGC0gZABPXCUPBzTYSTtxgfikJft5pQk8lkVNi+/qmhltUhklC3QDcWWmimMzwAXlN2BTiQAVhHCPyViInDBrYDDaO5XpVt07x/iSiM3fYYq5+ngRgEH4EPDHyPAWKHhr8zGv44K98nkKogqRHaeU9zQzUh49MDzg2E/SX0vl1YykA0djcNDtQ4t6hR7vqGsweIe3iNFDsUOoBDGKhYQduvCIn1sIddjSi61UVPwy8iEUYb5QEOIx0RwTccu4xicZVmJBXGSwfkTDnrCq69jJn9OFpWsShPq6xFZQ==
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=NK2ANacRUU7NJsl4Hbi5dxeY3QEVv3ULJVeqrFBFYdw=;
 b=ZO9i2zhMqC5GMNzQ8y8EJaLuDevqTIpLcURYsZipVEq/fTFvQ6OxAir/hznQnLIrFHcmAiv+OK22GAP1hyzPhKMtRhPiWTaYoW8qT0zRr1BmLR91SNHLwChn+wVpTe7exrwOaRGsXnDf1ZxLIR5/KMIi5LfUkDtn+5FEVfPx2e7enD05V96Mz8JF5ZXw4ut7FdQGwgz1i3eQCLm76eVj7IVentgEkCV3x94ia1XGmobOdZxVNHOyP9dmMBJbiBk4glVG3IDEg9pjCCrg8ayrqkU9cdSuJzR93n0UTX1SbQJIYWsKr+1tb6TeWNKotpXNRrcP9RJY5Ay14zh4+DlwLw==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v8 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow
 eSPI processing
Thread-Topic: [PATCH v8 07/12] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to
 allow eSPI processing
Thread-Index: AQHcIXHRRi0flx0W9EqWXyy7VrmvOw==
Date: Tue, 9 Sep 2025 10:09:23 +0000
Message-ID:
 <9479e88988b0c0c2e88d8ba8d2eb210a2cf68c8f.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: eac54e05-469f-46c7-0760-08ddef88f393
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?EuSiUmwqx5vH475IXor8An+8zkkWHPKD9qpJYQsh/bAyrfw8tuR8E2Ripe?=
 =?iso-8859-1?Q?CBILDX7E4rBIDrkZgkoxEZjg2gO3XnHYXCkB8QmZzKn1UbuIyJbOIluifx?=
 =?iso-8859-1?Q?7EE5MIFKC8d8TR2gu32BblXR965JuMKKLzP4huxTLKJyQoBeBgpoT7LiBE?=
 =?iso-8859-1?Q?LQ0M64t9N+iGhvwKA9QdCOr8z+r5mO0bNY684ajDupQdQgOd4gXJ74zclp?=
 =?iso-8859-1?Q?wtVP+Ee97QqLLndHbBGolonX8hrWoSf1KkoZ+ljERQ8fxR1RUFbKBM7Kha?=
 =?iso-8859-1?Q?1Betf0WPfRugt/7Rc4BGR73fTIfkjCEAwjl3xOmToqL4ac6Aj/lSciC1Kk?=
 =?iso-8859-1?Q?5Z6NlZqy0cz+In/1x3q1NWNm+gC1Zw3aDZGn5rRrR/UDJ7dDkyDxv/r8OG?=
 =?iso-8859-1?Q?sK0+MHtK9rYTxSpFSy5KiWkcXavQ5bxEVmKuqK8c/2JUJdovZIq81Zoe3M?=
 =?iso-8859-1?Q?YDY1QAlOr+7t5WWrTZB6gWT5NIjp7SB98Kfm9i36XrHWt87xmDI3taWFHv?=
 =?iso-8859-1?Q?v6FnBR4x8lhlRbkTZe16UcbZyO3NeFRqdDjTPZqhpwzEG0gi7w5OSakQjy?=
 =?iso-8859-1?Q?hr8Gf3Vqeh7W85BKPvichFymETfAxOXZQQVL/zbNZxMhkJ18XvELJexe5F?=
 =?iso-8859-1?Q?VfU1Kxq/XcUpGh9j3l0Va1JvjIHNjubRVIqa0dDSvB8FYKgf/+a5nXYop/?=
 =?iso-8859-1?Q?tgBPVk0qY88zkUV4utBZBhQBNO+w3mqNnQILtGClFRvXudQ9GGA26yXDTZ?=
 =?iso-8859-1?Q?c8oBGyaLrVU3z4jZVuQAHtsBpZg/OVq5HjbR5UFmcqd64chBum5a5COy4L?=
 =?iso-8859-1?Q?L03IxEGj7ZQ/PKwuU9r3ubNP9xF5hZjY04/zUd6CMz11Dc71pCLnMkSYIS?=
 =?iso-8859-1?Q?lsJ9BDYo83ufeLI0IwdIqZCF8LFPkOWQI0eHZqIyL/iKd+KL3jsiH/vqqo?=
 =?iso-8859-1?Q?uJJXlGZCBI0kZjN5boBA32TVOzwflyyeUktH6f9DCuH1FbuaBJ2cD87zXy?=
 =?iso-8859-1?Q?MKC0VaX/ebzxb7/hPCsq+HTYiwzr57SO6IP+1vT3fStI9T+xu5DCtE1l35?=
 =?iso-8859-1?Q?tZpuldFTvLTM9JZz+7mVHc4QBd1JlBkNE6t0jMSu/pOhu2Rfb8vAl+e3nt?=
 =?iso-8859-1?Q?s0c3Lkk/UKdiDuwpk8F+soztLTb/54SIUmURpeUFrG9Xvxz+ZQHvRodsTl?=
 =?iso-8859-1?Q?exJ5N5CqeXd6XJt9FYZDdJd8Pb0niGzc1zWBsVw+td8ZtLokOz2L6nlgqE?=
 =?iso-8859-1?Q?xtgx35sKXEjuPLetWcng6mPu0BStbz6zMTL39TidkQLZjbrLoCSwM4c2D5?=
 =?iso-8859-1?Q?T4/RuDFB8iRWtfDFNz2/1UhpBL8r0BegzC1lOpjrgmzD3Emafq7vyx4dyX?=
 =?iso-8859-1?Q?b2vmh/3r3MhSVspGg0VcKkkehXWN7xwfiZHgk+4d3WSfNjOTw4vv21n9qk?=
 =?iso-8859-1?Q?XVQKF7aCokPlkZ85BGevMxD7LhZAjPmff4ih6DvTcQvkQX6fpgeRz8+Cd3?=
 =?iso-8859-1?Q?q2sX8TMm8yVHPYyvOEGznFcgGHtV902nzHzXVUTboB1w=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?hVPE8nnBEJ5ZNeENMg6/bZ8zCQl3FeXlnFnl9bOUHSiUOU88vLDac0QYcY?=
 =?iso-8859-1?Q?oSrgv8sn9/rDgwWGnv4HwePzvMKN9Tq3gcOvjcls704ZFTacPXJAWjtbHn?=
 =?iso-8859-1?Q?Sf/dB2Ehn258/QRN6qpuAz2dfL6CxwXx+YSzWvtKWFKcHnQA8GTccYkGZg?=
 =?iso-8859-1?Q?R3l7aYlvbKUvf6vsz4j3aypZuifKWNVlJh87de01TJJgIchnQL7+VO735a?=
 =?iso-8859-1?Q?VAPOsviM/yIa7sOLSC/bSqlyfUv1fMPdHvr2n/o4zcXvBg4hMiJgxnkIKM?=
 =?iso-8859-1?Q?ywNe9AfTPfdR0qxkyLxgkInCFkMWmJ71iTjkDy28WnO8OcbLthggYkwMNb?=
 =?iso-8859-1?Q?hDZP1btVvrRC0+KIt+03gXe4WoC/MtE3cETHLkfhirQ7c4Dyza3cn1RcKr?=
 =?iso-8859-1?Q?5UO1eS2DCTRZXK1WSI6Ku6/QX3SEO0UNkA9okXxxrwnmtpOn5EEmiTPICw?=
 =?iso-8859-1?Q?wh/oTqGe5X/NKe++04HtrYcknil6JLKG6Oe5cdZOjyYdZzRlJQxU90O6Po?=
 =?iso-8859-1?Q?vSqBcNXJ4c4ozyGsKhU9RKO6Km7xpxVYSZUzKcV5UG6xrxVusGIxAwTSv5?=
 =?iso-8859-1?Q?dT1yAcOP26RvqsK1tHbNj9Hr4rrBSnxfTncs6Ck4oMNZl6pLEh+y35VfJv?=
 =?iso-8859-1?Q?bCMcu3bq690yxpStfjirBw9nfmDpg7LRmTAKCVz4jDbdVjHbGv2C46cNFU?=
 =?iso-8859-1?Q?ID/cMcbm0Cez1TEeHYDAhrlhZ4ZpyEUqhgnnf3pax8/aQCJ2G2oIjKWEti?=
 =?iso-8859-1?Q?EpV8FkzbYExBBGgtkK6+7qNguB2aB2vXQ6ZJLB+Jt/nfVHZaFAp0iYeuYK?=
 =?iso-8859-1?Q?N9FQxllql50WaN7iHZ6a402hmYmGgXEnhWulG8riInJ7EbTbpSXsQqgMzg?=
 =?iso-8859-1?Q?qVLc9AbtOAyQzQLMjVUwyFTsAabty75wCdY29LZTVJHT6fCxINGOtF+Fr5?=
 =?iso-8859-1?Q?LWl2xpYlj+hWzfply1qD6Sud1TcRFaIbrRdgIK3C7nnyUWNH8Rs3fwsNVK?=
 =?iso-8859-1?Q?iaogTG8bkIcOcrvEh4NaXGQSZbPM8DdLtIkzasA0gK7nzXqOj5Bb0RD+uK?=
 =?iso-8859-1?Q?jV8ScBT8NZ2QDinAH35D1tcQoaLChUXyBgwSbOtUPBgFkt9csA/LNYZsQj?=
 =?iso-8859-1?Q?Esg5MxcRaQkjZIPTnWuBazpU0VmCOxpWVeLAW/8Nqaw+01GDm39wx5Pius?=
 =?iso-8859-1?Q?4u+Wa8qotdbCYDZd/1U/CCJ9oiep4/GhqFWqlaaslfI2kp2yyRfDVJXZHt?=
 =?iso-8859-1?Q?C3+7rWEQw2m9cD/UQnVOJz/uvBM8KXKANQGvd0G9Q3oajsgAVOb3FT9MPU?=
 =?iso-8859-1?Q?5MkJ9lv3ZfvrrP5L79AnLQ/99gWbMc3XFWqsZ3IdNhc3UAXS8+QySDCDiz?=
 =?iso-8859-1?Q?2f33MDqwxP+/jZTqik/04l7/3tIxNKMMia+Q1spx+JYI6VVH/5/R+JHVbE?=
 =?iso-8859-1?Q?KQVYidTRvAkuKG46l9CVbeWC5VYiWSvBZCPcCG0wNk9/ymGpn571zAbUZB?=
 =?iso-8859-1?Q?snwt5IP+o96oPJxymBOlZPQNf0wTFihDvnYMm7TDJz/85q+ei6d/HUEwBC?=
 =?iso-8859-1?Q?LxMO8y3wdZu5H3XBiXxQ0V3fHY4hahYXKpDkMzAn5A2apB4Cf8NfE5HLX2?=
 =?iso-8859-1?Q?Sc4K7zX8qJCY9i5ANA5SNxb0WrWTXSZoSQZQ4uRkvVswtCVfqBHeALQoqY?=
 =?iso-8859-1?Q?HL72Iyamkdse7fQfg+k=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eac54e05-469f-46c7-0760-08ddef88f393
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:23.6993
 (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: S3ZFeX72Y24KAwVkcq8cGk6LwM5/oEJJ8FgzYax1ZOUBtuCPVCGIXCdc6Ka3IdEgcrVXkJDn/iDBSWFR3ilsvTVLqg/z/XLYBmyv8FqSnPs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

To properly deactivate physical eSPI routed to a domain and allow them to
be retriggered after the initial trigger, the LR needs to be updated. The
current implementation ignores interrupts outside the range specified by
the mask 0x3FF, which only covers IRQ numbers up to 1023. To enable
processing of eSPI interrupts, this patch updates the mask to 0x1FFF.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 

---
Changes in V8:
- added acked-by from Julien Grall

Changes in V7:
- added reviewed-by from Volodymyr Babchuk

Changes in V6:
- updated mask to 0x1fff to avoid confusion
- updated commit message
- removed reviewed-by as new changes requires additional confirmation
  from reviewers

Changes in V5:
- no changes

Changes in V4:
- added reviewed-by from Volodymyr Babchuk

Changes in V3:
- no changes

Changes in V2:
- remove unnecessary CONFIG_GICV3_ESPI ifdef guard
---
 xen/arch/arm/include/asm/gic_v3_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index 3370b4cd52..c373b94d19 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -211,7 +211,7 @@
 #define ICH_LR_VIRTUAL_SHIFT         0
 #define ICH_LR_CPUID_MASK            0x7
 #define ICH_LR_CPUID_SHIFT           10
-#define ICH_LR_PHYSICAL_MASK         0x3ff
+#define ICH_LR_PHYSICAL_MASK         0x1fff
 #define ICH_LR_PHYSICAL_SHIFT        32
 #define ICH_LR_STATE_MASK            0x3
 #define ICH_LR_STATE_SHIFT           62
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:24:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:24:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116305.1462672 (Exim 4.92)
	(envelope-from )
	id 1uvvWA-0002gd-Ee; Tue, 09 Sep 2025 10:24:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116305.1462672; Tue, 09 Sep 2025 10:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvvWA-0002gW-Bs; Tue, 09 Sep 2025 10:24:06 +0000
Received: by outflank-mailman (input) for mailman id 1116305;
 Tue, 09 Sep 2025 10:24: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 1uvvIF-0001My-0p
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:43 +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 19a0ce90-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:41 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:32 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 19a0ce90-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qUpP/MS+ebuHOo5APhBg4SpgMgEvuIK86eLkE0M1/iCRjhnRRXubaaO0ALOPTpgv1mBHn8eSMbtrALEmEQuOzSaCixp997POI9a/nlSMkIemzLj5e7Ro7FZT5utoloDQ1jVdlU1q2WsO3UNvfbAI0DhG4qtJHEOP1O34/m9xqb7p+/LN/SccxXhtaPGQQLwNiI+9FLlDLug6mQ3YbEtnikUhBMUXwgcYB85317u0VcSQv5Pomq/oZSRWJ5pXgD5EZ834iliGgCj9Z6pb/eg5ffO6nWxBH+Gr95fCxPpPZFBsflKPHeknb/uHLR3aJRRLExkAOHeTQlLbkYXckJsfqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zEVDDkro/4RLcvAdwGV/VFVy/2GMbS04zF19EjNqqRg=;
 b=jRxqkOTSq6SuFlqJUkNXectJ51oH4zredxiDHqKG9+T7g+BqNY8oyPAVuTGkYX+QTP6YH822EJ1yrb+zzfZ0mQe3DYGcwYtM38N2ehdg24xljO91Bokg8IBG11dx9tc59ZbbytEbTcIUZcz2XqtC23dBi9fq7l259/1FnyLBId+v/BlPPncDBLn0C4XkBGBkNFfIOIpltefVVbhcL6G/mz+morHhLjnI66j75VO2we40c7MmJyqci4xXV89P3wzjOG69R2BlHFf2Kc9pVnCmRMWFgCkXvkEVckODyp+sOn5eyNyU8sTlZtv8Fsb4LBr2OgdMNFij3r1brgyd6i4xGA==
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=zEVDDkro/4RLcvAdwGV/VFVy/2GMbS04zF19EjNqqRg=;
 b=JOWaQcsLEX/DsDiTnV3lhqryLe4qoSpUzgne5cfIkdVT2z/EKFSfVarH87Xg9cpGtIdyO6hMW6VICm1oIIipF998m40lqjFF+UecEHfTGsbJwuSNXMyCVQ9sfvuTqxjYMECr0rRsv+vbMc+Mt1aNaAfJsCiaftaNRoPmo3sv2r0QPTo2dHsjoC8bwywOHan3i4oZ5J9xhCcFMcIo4PRH6FaYxaVzpemPk7qaHHZU6FIlZckLTIYoZEpJiyWes/UwyohLjoT7ByXMPVW474KLKriYsu9mLvTshoGQN7PDtalt/46NE4O0HpriWHv5+qmuSQ6j75+h74MfkVEyGnOFZg==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Oleksandr Tyshchenko
	, Julien Grall 
Subject: [PATCH v8 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Topic: [PATCH v8 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI
 registers
Thread-Index: AQHcIXHV8u4+2vuOCEqK2GduOtSmvw==
Date: Tue, 9 Sep 2025 10:09:31 +0000
Message-ID:
 <9c52c50708132cdd10f9f3b4168b268a19224c62.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: 77c6cf2f-833e-4002-b1df-08ddef88f874
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?7OjUufHjWxVmOGw+w2pOmROAuwBoQAQNL3zqNl/9Vv6tEs1KZ1LNoVkTYf?=
 =?iso-8859-1?Q?V5/gyp+B1G0tCIa4Yfq+RvA1MMsQc8CuQDl9hPjv+yvCOuyX5LPoqpSieg?=
 =?iso-8859-1?Q?E3RafDV+VM4Ob7xIjm/WwLQms4G8ZRhNuoul2tJ2cYN+HU3eSpvP10dxEg?=
 =?iso-8859-1?Q?friC8gxKPF5u4Tjy3EjhBIvfPIlvU6jmDuxarYlYa2pL3KrwR5hLQR5r6I?=
 =?iso-8859-1?Q?+6hTFlD6ghz3cYl+nferJae7H6C5VJBk0VreTe/Zd35lqaF7/AKA87uKyU?=
 =?iso-8859-1?Q?2f8GcMGLGGmC3Nb0D631LXz5nWejBqiyIvISHoDFENLFIKYDRBn0sy+RwK?=
 =?iso-8859-1?Q?CC/RAl93TnNyyqGhZ6P5RWhWW9KrH+odGIy5dgr7NcgLw8i5srG++Femcu?=
 =?iso-8859-1?Q?Eh9HIV9FHKqvJJfzz+fzJ5EUYlNB0AjyIdTNUx9Yk3Ba2WaKrHfiuTXQDM?=
 =?iso-8859-1?Q?G+mksAquQvBwf/nvRxuWHNT28Vedw6iDBLOzEHuRAnJoVrhcU2i0+SQcaC?=
 =?iso-8859-1?Q?Grkq3a6v+sXjFAGqACAPLUuOT9Vywm8AdLkTNkbHIy+4FB+HbmO36r0N7b?=
 =?iso-8859-1?Q?6657WIPJejm2EOM5T5EUZA9QFWO7jJW2weJyGW7cn7bU54L9iullvbtZyX?=
 =?iso-8859-1?Q?hNzp+VGnoEybmBSdELDnfgMos14z93GZrznj9o7qU3o2xB8bxz94dcAvZJ?=
 =?iso-8859-1?Q?m2CIpNlQCTfNeT/hleIDJ5S15cfI1L7Nh7f9bnyE1XhaGCR2dGHx88HxNz?=
 =?iso-8859-1?Q?CRvPwrhrGMD2rE0w1YPa77lPDHDfkzno1q54acaAbJrDg6zvmttRNOA7sn?=
 =?iso-8859-1?Q?F/+6GiHc7IpE40bHn+k5Zlbe5KD/uJKKPbaYT9tOVE7uA0qKCnQ2FzvjlA?=
 =?iso-8859-1?Q?NhTO36PmONIj/zGPJ8e6mg/7A/UTPhKPEaICLgm7ZZxVlesW+YmqaCHlYI?=
 =?iso-8859-1?Q?fb5AZHf0MNcJlxGQVsvBHty83XC2KhdgqnzMmAm1L75U75o02/WnZ7XYi3?=
 =?iso-8859-1?Q?hS4Vk+JCU7OguI28K9aU+TxdyfXhyEi+LpJKgwWEfipwityxu6QIWE3nGm?=
 =?iso-8859-1?Q?IftsMZObjJBGvF9xlpwBYgDv6FuT1KB5/v0NDJy94IHlsCIFONjHP5gMpC?=
 =?iso-8859-1?Q?Npnq0GJYrCFNojre4eCWgAM1YiSuxjUgvrhOJpKyRuitwiA3Leu5ihdN1Q?=
 =?iso-8859-1?Q?4MaaxDFE9UBh4pX8fxzMTP3gDWHDTeEA6kBZqL+tdYkdfLVDrBf2OmXwF/?=
 =?iso-8859-1?Q?m23uaBsQR3em2MSg2k2q+ns+3rY/N2/iMLYbtOHYBXsguJSOhr5gmTMklC?=
 =?iso-8859-1?Q?v4ZxYemJcWs9nvT644bgl0fxyCveeG1I7cE4yX3aWmym9J0CL8hHKJdPvp?=
 =?iso-8859-1?Q?wMxkcn2ayONttS5nCceRNr3fcQu+Buo/9SnP0Locs4Inv+EbhC4zefYcxW?=
 =?iso-8859-1?Q?UsD1adzkfgEQ+DDLL6ftR3X3YhLsy0s9nez1gAtDov5Ljm/9m4BkIGv8VW?=
 =?iso-8859-1?Q?d7L2tHs/MbtTia6yg9npKTil9yI0NiJh4agoKLA0DZxA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qmKqSwlqwoP4kxvDRuxe4sNGbMarEAS0QeP2Dy8ZTn1C7eKn6FXQYiJpXC?=
 =?iso-8859-1?Q?QGUeQFtHkDy6QKzm2herLJIpxKhxKX69p6OkDhh4THdJktunaiRSD6vlH1?=
 =?iso-8859-1?Q?eAF9jGegK3bsjevSSziw5mKDOhJFl93bp3wCT0Ta1MzOVe4TUB9JoJFEG3?=
 =?iso-8859-1?Q?XVfZ+cmvgZalqtPZ4QSpNBCeRgE/i+R7oTFqyjKDDyE6vonm+Qa4jM800A?=
 =?iso-8859-1?Q?WXlPcSugeSBELm5v4TPcXUcAaGh6O9/eMkzJtL3txwGnsybLMm/Sk1Hw4n?=
 =?iso-8859-1?Q?yXOfMXhR5aoCqrvzKz83974cgy96NP1DQv7F+pyoFP1efEXWmVSWVCyZib?=
 =?iso-8859-1?Q?P7b9qnbGiNIQmGpoQtRVgCE2ytrJMTumVsls65z9JHrs3lpWjmzn0JVCFh?=
 =?iso-8859-1?Q?vD6OF9J0CsPw9Jz6bqGRtZQP3rZlkwNu+6Pd3/MSDwvjR07tliPkCeA8Q6?=
 =?iso-8859-1?Q?oKH21HEgtVyE7daVFzCUVHgEYS9FA7bVEe4AGYHOLRabLTF0tIUE96mEt/?=
 =?iso-8859-1?Q?KvaZGd8wI1ybmGp93sRojD3j+T8miXgcPjOlSlF219dG0fCmCMI3faF/RY?=
 =?iso-8859-1?Q?D4mCjdya5A+j4cE9c34WVWafwI5D37+MS4lV6iCtj0BeskAgtv1l+Xt4ye?=
 =?iso-8859-1?Q?b/yFKanIH6vDa/rm8sqVKgV+q+VJt1qcY7vMAESl3Y68TKsiD2Vmj5CgJR?=
 =?iso-8859-1?Q?tYAry2/oGIkbUZbx8gzOxE6H+U0GFuGuHdO9hEobjdmYsjEXYQIjN9HdpX?=
 =?iso-8859-1?Q?mgyYyNMQq04KHS1UKL+2Pi91QKcH13qAta2BudJ8hTJ7D1PfYnd9BsVbzS?=
 =?iso-8859-1?Q?guGuZxCR8FzauteihOWiPUb/I6gMcWbZI6VN3VttZlLxd81jPTS/8MtN6v?=
 =?iso-8859-1?Q?TR+41jUSiRpS4/EaSp/aMGcutw4u+ksC7W1DH/iYXlxcFrUcE2Kxb44BU8?=
 =?iso-8859-1?Q?zS25UqPjKmo+iTSQBH2LWHtn3NXnjmn3wTB7kD1WYF+7giKBEiXut6r9fe?=
 =?iso-8859-1?Q?ELgZco13acRO1uRLcks50OLfXa+K581NqDk9JRbWzI1Fc6q6e6+ocNbgYx?=
 =?iso-8859-1?Q?8ZJALBbIv2i7k8d1weAwXP764em18s9fh7CXtm9/5QkK1A8k4HpxgDtX+m?=
 =?iso-8859-1?Q?O9Tb5MuC3skRcx44JPzls5uoWE8XXZtWuJES2LfxM9HWeheByxe0ne5iZL?=
 =?iso-8859-1?Q?R9iMEs3Vj0IZXv+iDsFlhGCFMEj2Ko851EsnQBc9pL9ouldFQeldz1+klH?=
 =?iso-8859-1?Q?uAhMBI6YzqqDdmzi2xjcUdQ3NjSVkSaf7Tn+28Ja6codAzEZgeJW6iqP72?=
 =?iso-8859-1?Q?eABHvJVcsI7UELZlVsFcGSElYP9lMgJ45YAHmbja+RHx+AxyeT79woQ9ws?=
 =?iso-8859-1?Q?emENlZh9XERuCxYUCy9zm7X9ZdVp1WMvMKn9T/lH9Ev3MLb6usEHdGjtf3?=
 =?iso-8859-1?Q?VL1OJ6Stb0C8wpuC8Ll4Ec+3opg8mVC2DoVK3J6S6GpU5gZzza32JipWg4?=
 =?iso-8859-1?Q?0p2IceClaQ5DZGLCbGOSWsGa4K5bH59f8l+YTKmQqhvzSux/V1DTeihtNN?=
 =?iso-8859-1?Q?bf1MAoM9uuIsDRvrBxqXWnifqZ51ijX5GnoxxKlrwyIdGomzmDPqgd7zLw?=
 =?iso-8859-1?Q?SdJ6dxylx9KPAUCh88ZdNI1UTcBMcNynMqJJrj0siNEOEHk/8hqo2G4PVm?=
 =?iso-8859-1?Q?ruQz4Ya34TtMQX4ME5g=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 77c6cf2f-833e-4002-b1df-08ddef88f874
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:31.8701
 (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: 09M40DvE8kvZqI/XAEDwkeFwezEa+x6/q6MITwck21TKleHPyB5GJWs9N/k+BP3gBem7pETLutO5k25p71DL9M8QJmLWpKafn/H0rfEF/4s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
following a similar approach to the handling of regular SPIs.

The eSPI registers, previously located in reserved address ranges,
are now adjusted to support MMIO read and write operations correctly
when CONFIG_GICV3_ESPI is enabled.

The availability of eSPIs and the number of emulated extended SPIs
for guest domains is reported by setting the appropriate bits in the
GICD_TYPER register, based on the number of eSPIs requested by the
domain and supported by the hardware. In cases where the configuration
option is disabled, the hardware does not support eSPIs, or the domain
does not request such interrupts, the functionality remains unchanged.

Signed-off-by: Leonid Komarianskyi 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 

---
Changes in V8:
- added acked-by from Julien Grall

Changes in V7:
- minor: renamed vgic_get_rank to vgic_common_rank_offset
- minor: updated comment for vgic_common_rank_offset
- minor: restored comment for vgic_store_irouter
- minor: added sanity checks with asserts to helper functions
- added reviewed-by from Oleksandr Tyshchenko

Changes in V6:
- introduced helper functions: vgic_get_rank and vgic_get_reg_offset to
  avoid boilerplate code and simplify changes
- fixed index initialization in the previous patch ([08/12] xen/arm:
  vgic: add resource management for extended SPIs) and removed index
  conversion for vgic_enable_irqs(), vgic_disable_irqs(),
  vgic_set_irqs_pending(), and vgic_check_inflight_irqs_pending()
- grouped SPI and eSPI registers
- updated the comment for vgic_store_irouter to reflect parameter
  changes
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
  into appropriate inline functions introduced in the previous patch

Changes in V5:
- since eSPI-specific defines and macros are now available even when the
  appropriate config is disabled, this allows us to remove many
  #ifdef guards and reuse the existing code for regular SPIs for eSPIs as
  well, as eSPIs are processed similarly. This improves code readability
  and consolidates the register ranges for SPIs and eSPIs in a single
  place, simplifying future changes or fixes for SPIs and their
  counterparts from the extended range
- moved vgic_ext_rank_offset() from
  [08/12] xen/arm: vgic: add resource management for extended SPIs
  as the function was unused before this patch
- added stub implementation of vgic_ext_rank_offset() when CONFIG_GICV3_ESP=
I=3Dn
- removed unnecessary defines for reserved ranges, which were introduced in
  V4 to reduce the number of #ifdefs. The issue is now resolved by
  allowing the use of SPI-specific offsets and reworking the logic

Changes in V4:
- added missing RAZ and write ignore eSPI-specific registers ranges:
  GICD_NSACRnE and GICD_IGRPMODRnE
- changed previously reserved range to cover GICD_NSACRnE and
  GICD_IGRPMODRnE
- introduced GICD_RESERVED_RANGE_START/END defines to remove
  hardcoded values and reduce the number of ifdefs
- fixed reserved ranges with eSPI option enabled: added missing range
  0x0F30-0x0F7C
- updated the logic for domains that do not support eSPI, but Xen is
  compiled with the eSPI option. Now, prior to other MMIO checks, we
  verify whether eSPI is available for the domain or not. If not, it
  behaves as it does currently - RAZ and WI
- fixed print for GICD_ICACTIVERnE
- fixed new lines formatting for switch-case

Changes in V3:
- changed vgic_store_irouter parameters - instead of offset virq is
  used, to remove the additional bool espi parameter and simplify
  checks. Also, adjusted parameters for regular SPI. Since the offset
  parameter was used only for calculating virq number and then reused for
  finding rank offset, it will not affect functionality.
- fixed formatting for goto lables - added newlines after condition
- fixed logs for GICD_ISACTIVERnE and GICD_ICACTIVERnE handlers
- removed #ifdefs in 2 places where they were adjacent and could be merged

Changes in V2:
- add missing rank index conversion for pending and inflight irqs
---
 xen/arch/arm/include/asm/vgic.h |   4 +
 xen/arch/arm/vgic-v3.c          | 203 +++++++++++++++++++++++++-------
 xen/arch/arm/vgic.c             |  22 ++++
 3 files changed, 185 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgi=
c.h
index 24a4a968c3..31b3d3e5ec 100644
--- a/xen/arch/arm/include/asm/vgic.h
+++ b/xen/arch/arm/include/asm/vgic.h
@@ -324,6 +324,10 @@ extern struct vgic_irq_rank *vgic_rank_offset(struct v=
cpu *v,
                                               unsigned int b,
                                               unsigned int n,
                                               unsigned int s);
+extern struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v,
+                                                  unsigned int b,
+                                                  unsigned int n,
+                                                  unsigned int s);
 extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int ir=
q);
 extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsigned int n);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4369c55177..8b1c8eef80 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -107,17 +107,12 @@ static uint64_t vgic_fetch_irouter(struct vgic_irq_ra=
nk *rank,
 /*
  * Store an IROUTER register in a convenient way and migrate the vIRQ
  * if necessary. This function only deals with IROUTER32 and onwards.
- *
- * Note the offset will be aligned to the appropriate boundary.
  */
 static void vgic_store_irouter(struct domain *d, struct vgic_irq_rank *ran=
k,
-                               unsigned int offset, uint64_t irouter)
+                               unsigned int virq, uint64_t irouter)
 {
     struct vcpu *new_vcpu, *old_vcpu;
-    unsigned int virq;
-
-    /* There is 1 vIRQ per IROUTER */
-    virq =3D offset / NR_BYTES_PER_IROUTER;
+    unsigned int offset;
=20
     /*
      * The IROUTER0-31, used for SGIs/PPIs, are reserved and should
@@ -673,6 +668,36 @@ write_reserved:
     return 1;
 }
=20
+/*
+ * The assumption is that offsets below espi_base are for
+ * regular SPI, while those at or above are for eSPI.
+ */
+static inline struct vgic_irq_rank *vgic_common_rank_offset(struct vcpu *v=
,
+                                                            unsigned int b=
,
+                                                            uint32_t reg,
+                                                            unsigned int s=
,
+                                                            uint32_t spi_b=
ase,
+                                                            uint32_t espi_=
base)
+{
+    ASSERT(spi_base < espi_base);
+
+    if ( reg < espi_base )
+        return vgic_rank_offset(v, b, reg - spi_base, s);
+    else
+        return vgic_ext_rank_offset(v, b, reg - espi_base, s);
+}
+
+static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base=
,
+                                           uint32_t espi_base)
+{
+    ASSERT(spi_base < espi_base);
+
+    if ( reg < espi_base )
+        return reg - spi_base;
+    else
+        return reg - espi_base;
+}
+
 static int __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu =
*v,
                                             mmio_info_t *info, uint32_t re=
g,
                                             register_t *r)
@@ -685,13 +710,17 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     {
     case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* We do not implement security extensions for guests, read zero *=
/
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
         goto read_as_zero;
=20
     case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ISENAB=
LER,
+                                       GICD_ISENABLERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
         vgic_lock_rank(v, rank, flags);
         *r =3D vreg_reg32_extract(rank->ienable, info);
@@ -699,8 +728,10 @@ static int __vgic_v3_distr_common_mmio_read(const char=
 *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ICENAB=
LER,
+                                       GICD_ICENABLERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
         vgic_lock_rank(v, rank, flags);
         *r =3D vreg_reg32_extract(rank->ienable, info);
@@ -710,22 +741,29 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     /* Read the pending status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
     case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
         goto read_as_zero;
=20
     /* Read the active status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
         goto read_as_zero;
=20
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
     {
-        uint32_t ipriorityr;
+        uint32_t ipriorityr, offset;
         uint8_t rank_index;
=20
         if ( dabt.size !=3D DABT_BYTE && dabt.size !=3D DABT_WORD ) goto b=
ad_width;
-        rank =3D vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 8, reg, DABT_WORD, GICD_IPRIOR=
ITYR,
+                                       GICD_IPRIORITYRnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
-        rank_index =3D REG_RANK_INDEX(8, reg - GICD_IPRIORITYR, DABT_WORD)=
;
+        offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORIT=
YRnE);
+        rank_index =3D REG_RANK_INDEX(8, offset, DABT_WORD);
=20
         vgic_lock_rank(v, rank, flags);
         ipriorityr =3D ACCESS_ONCE(rank->ipriorityr[rank_index]);
@@ -737,14 +775,17 @@ static int __vgic_v3_distr_common_mmio_read(const cha=
r *name, struct vcpu *v,
     }
=20
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
     {
-        uint32_t icfgr;
+        uint32_t icfgr, offset;
=20
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 2, reg, DABT_WORD, GICD_ICFGR,
+                                       GICD_ICFGRnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
+        offset =3D vgic_get_reg_offset(reg, GICD_ICFGR, GICD_ICFGRnE);
         vgic_lock_rank(v, rank, flags);
-        icfgr =3D rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR, DABT_WORD=
)];
+        icfgr =3D rank->icfg[REG_RANK_INDEX(2, offset, DABT_WORD)];
         vgic_unlock_rank(v, rank, flags);
=20
         *r =3D vreg_reg32_extract(icfgr, info);
@@ -782,12 +823,16 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
     {
     case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* We do not implement security extensions for guests, write ignor=
e */
         goto write_ignore_32;
=20
     case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ISENAB=
LER,
+                                       GICD_ISENABLERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
         vgic_lock_rank(v, rank, flags);
         tr =3D rank->ienable;
@@ -797,8 +842,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICENABLER, GICD_ICENABLERN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICENABLER, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ICENAB=
LER,
+                                       GICD_ICENABLERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
         vgic_lock_rank(v, rank, flags);
         tr =3D rank->ienable;
@@ -808,8 +855,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ISPENDR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ISPEND=
R,
+                                       GICD_ISPENDRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
=20
         vgic_set_irqs_pending(v, r, rank->index);
@@ -817,8 +866,10 @@ static int __vgic_v3_distr_common_mmio_write(const cha=
r *name, struct vcpu *v,
         return 1;
=20
     case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 1, reg - GICD_ICPENDR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 1, reg, DABT_WORD, GICD_ICPEND=
R,
+                                       GICD_ICPENDRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
=20
         vgic_check_inflight_irqs_pending(v, rank->index, r);
@@ -826,28 +877,42 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
         goto write_ignore;
=20
     case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        printk(XENLOG_G_ERR
-               "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER=
%d\n",
-               v, name, r, reg - GICD_ISACTIVER);
+        if ( reg < GICD_ISACTIVERnE )
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ISACT=
IVER%d\n",
+                   v, name, r, reg - GICD_ISACTIVER);
+        else
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ISACT=
IVER%dE\n",
+                   v, name, r, reg - GICD_ISACTIVERnE);
         return 0;
=20
     case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
-        printk(XENLOG_G_ERR
-               "%pv: %s: unhandled word write %#"PRIregister" to ICACTIVER=
%d\n",
-               v, name, r, reg - GICD_ICACTIVER);
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+        if ( reg < GICD_ICACTIVERnE )
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ICACT=
IVER%d\n",
+                   v, name, r, reg - GICD_ICACTIVER);
+        else
+            printk(XENLOG_G_ERR
+                   "%pv: %s: unhandled word write %#"PRIregister" to ICACT=
IVER%dE\n",
+                   v, name, r, reg - GICD_ICACTIVERnE);
         goto write_ignore_32;
=20
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
     {
-        uint32_t *ipriorityr, priority;
+        uint32_t *ipriorityr, priority, offset;
=20
         if ( dabt.size !=3D DABT_BYTE && dabt.size !=3D DABT_WORD ) goto b=
ad_width;
-        rank =3D vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 8, reg, DABT_WORD, GICD_IPRIOR=
ITYR,
+                                       GICD_IPRIORITYRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(reg, GICD_IPRIORITYR, GICD_IPRIORIT=
YRnE);
         vgic_lock_rank(v, rank, flags);
-        ipriorityr =3D &rank->ipriorityr[REG_RANK_INDEX(8, reg - GICD_IPRI=
ORITYR,
-                                                      DABT_WORD)];
+        ipriorityr =3D &rank->ipriorityr[REG_RANK_INDEX(8, offset, DABT_WO=
RD)];
         priority =3D ACCESS_ONCE(*ipriorityr);
         vreg_reg32_update(&priority, r, info);
         ACCESS_ONCE(*ipriorityr) =3D priority;
@@ -859,17 +924,23 @@ static int __vgic_v3_distr_common_mmio_write(const ch=
ar *name, struct vcpu *v,
         goto write_ignore_32;
=20
     case VRANGE32(GICD_ICFGR + 4, GICD_ICFGRN): /* PPI + SPIs */
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    {
+        uint32_t offset;
+
         /* ICFGR1 for PPI's, which is implementation defined
            if ICFGR1 is programmable or not. We chose to program */
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 2, reg - GICD_ICFGR, DABT_WORD);
+        rank =3D vgic_common_rank_offset(v, 2, reg, DABT_WORD, GICD_ICFGR,
+                                       GICD_ICFGRnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(reg, GICD_ICFGR, GICD_ICFGRnE);
         vgic_lock_rank(v, rank, flags);
-        vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGR,
-                                                     DABT_WORD)],
+        vreg_reg32_update(&rank->icfg[REG_RANK_INDEX(2, offset, DABT_WORD)=
],
                           r, info);
         vgic_unlock_rank(v, rank, flags);
         return 1;
+    }
=20
     default:
         printk(XENLOG_G_ERR
@@ -1129,6 +1200,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, m=
mio_info_t *info,
             typer |=3D GICD_TYPE_LPIS;
=20
         typer |=3D (v->domain->arch.vgic.intid_bits - 1) << GICD_TYPE_ID_B=
ITS_SHIFT;
+#ifdef CONFIG_GICV3_ESPI
+        if ( v->domain->arch.vgic.nr_espis > 0 )
+        {
+            /* Set eSPI support bit for the domain */
+            typer |=3D GICD_TYPER_ESPI;
+            /* Set ESPI range bits */
+            typer |=3D (DIV_ROUND_UP(v->domain->arch.vgic.nr_espis, 32) - =
1)
+                       << GICD_TYPER_ESPI_RANGE_SHIFT;
+        }
+#endif
=20
         *r =3D vreg_reg32_extract(typer, info);
=20
@@ -1194,6 +1275,16 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, m=
mio_info_t *info,
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /*
          * Above all register are common with GICR and GICD
          * Manage in common
@@ -1201,6 +1292,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mm=
io_info_t *info,
         return __vgic_v3_distr_common_mmio_read("vGICD", v, info, gicd_reg=
, r);
=20
     case VRANGE32(GICD_NSACR, GICD_NSACRN):
+    case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN):
         /* We do not implement security extensions for guests, read zero *=
/
         goto read_as_zero_32;
=20
@@ -1216,27 +1308,30 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, =
mmio_info_t *info,
         /* Replaced with GICR_ISPENDR0. So ignore write */
         goto read_as_zero_32;
=20
-    case VRANGE32(0x0F30, 0x60FC):
+    case VRANGE32(0x0F30, 0x0FFC):
         goto read_reserved;
=20
     case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019):
+    case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):
     {
         uint64_t irouter;
+        uint32_t offset;
=20
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
-                                DABT_DOUBLE_WORD);
+        rank =3D vgic_common_rank_offset(v, 64, gicd_reg, DABT_DOUBLE_WORD=
,
+                                       GICD_IROUTER, GICD_IROUTERnE);
         if ( rank =3D=3D NULL ) goto read_as_zero;
+        offset =3D vgic_get_reg_offset(gicd_reg, GICD_IROUTER, GICD_IROUTE=
RnE);
         vgic_lock_rank(v, rank, flags);
-        irouter =3D vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER);
+        irouter =3D vgic_fetch_irouter(rank, offset);
         vgic_unlock_rank(v, rank, flags);
=20
         *r =3D vreg_reg64_extract(irouter, info);
=20
         return 1;
     }
-
-    case VRANGE32(0x7FE0, 0xBFFC):
+    case VRANGE32(0x3700, 0x60FC):
+    case VRANGE32(0xA004, 0xBFFC):
         goto read_reserved;
=20
     case VRANGE32(0xC000, 0xFFCC):
@@ -1382,12 +1477,23 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v,=
 mmio_info_t *info,
     case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
     case VRANGE32(GICD_ICFGR, GICD_ICFGRN):
     case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
+    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
+    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
+    case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
+    case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
+    case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
+    case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
+    case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
+    case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
+    case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
+    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
         /* Above registers are common with GICR and GICD
          * Manage in common */
         return __vgic_v3_distr_common_mmio_write("vGICD", v, info,
                                                  gicd_reg, r);
=20
     case VRANGE32(GICD_NSACR, GICD_NSACRN):
+    case VRANGE32(GICD_NSACRnE, GICD_NSACRnEN):
         /* We do not implement security extensions for guests, write ignor=
e */
         goto write_ignore_32;
=20
@@ -1405,26 +1511,35 @@ static int vgic_v3_distr_mmio_write(struct vcpu *v,=
 mmio_info_t *info,
         if ( dabt.size !=3D DABT_WORD ) goto bad_width;
         return 0;
=20
-    case VRANGE32(0x0F30, 0x60FC):
+    case VRANGE32(0x0F30, 0x0FFC):
         goto write_reserved;
=20
     case VRANGE64(GICD_IROUTER32, GICD_IROUTER1019):
+    case VRANGE64(GICD_IROUTERnE, GICD_IROUTERnEN):
     {
         uint64_t irouter;
+        unsigned int offset, virq;
=20
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        rank =3D vgic_rank_offset(v, 64, gicd_reg - GICD_IROUTER,
-                                DABT_DOUBLE_WORD);
+        rank =3D vgic_common_rank_offset(v, 64, gicd_reg, DABT_DOUBLE_WORD=
,
+                                       GICD_IROUTER, GICD_IROUTERnE);
         if ( rank =3D=3D NULL ) goto write_ignore;
+        offset =3D vgic_get_reg_offset(gicd_reg, GICD_IROUTER, GICD_IROUTE=
RnE);
         vgic_lock_rank(v, rank, flags);
-        irouter =3D vgic_fetch_irouter(rank, gicd_reg - GICD_IROUTER);
+        irouter =3D vgic_fetch_irouter(rank, offset);
         vreg_reg64_update(&irouter, r, info);
-        vgic_store_irouter(v->domain, rank, gicd_reg - GICD_IROUTER, irout=
er);
+        /* There is 1 vIRQ per IROUTER */
+        if ( gicd_reg < GICD_IROUTERnE )
+            virq =3D offset / NR_BYTES_PER_IROUTER;
+        else
+            virq =3D espi_idx_to_intid(offset / NR_BYTES_PER_IROUTER);
+        vgic_store_irouter(v->domain, rank, virq, irouter);
         vgic_unlock_rank(v, rank, flags);
         return 1;
     }
=20
-    case VRANGE32(0x7FE0, 0xBFFC):
+    case VRANGE32(0x3700, 0x60FC):
+    case VRANGE32(0xA004, 0xBFFC):
         goto write_reserved;
=20
     case VRANGE32(0xC000, 0xFFCC):
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index eb22de6aa6..3ebdf9953f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -170,6 +170,18 @@ int domain_vgic_register(struct domain *d, unsigned in=
t *mmio_count)
 }
=20
 #ifdef CONFIG_GICV3_ESPI
+/*
+ * The function behavior is the same as for regular SPIs (vgic_rank_offset=
),
+ * but it operates with extended SPI ranks.
+ */
+struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b,
+                                           unsigned int n, unsigned int s)
+{
+    unsigned int rank =3D REG_RANK_NR(b, (n >> s));
+
+    return vgic_get_rank(v, rank + EXT_RANK_MIN);
+}
+
 static unsigned int vgic_num_spi_lines(struct domain *d)
 {
     return d->arch.vgic.nr_spis + d->arch.vgic.nr_espis;
@@ -210,6 +222,16 @@ static unsigned int vgic_num_spi_lines(struct domain *=
d)
     return d->arch.vgic.nr_spis;
 }
=20
+/*
+ * It is expected that, in the case of CONFIG_GICV3_ESPI=3Dn, the function=
 will
+ * return NULL. In this scenario, mmio_read/mmio_write will be treated as
+ * RAZ/WI, as expected.
+ */
+struct vgic_irq_rank *vgic_ext_rank_offset(struct vcpu *v, unsigned int b,
+                                           unsigned int n, unsigned int s)
+{
+    return NULL;
+}
 #endif
=20
 static unsigned int vgic_num_alloc_irqs(struct domain *d)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:24:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:24:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116313.1462681 (Exim 4.92)
	(envelope-from )
	id 1uvvWT-0003Ct-Qx; Tue, 09 Sep 2025 10:24:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116313.1462681; Tue, 09 Sep 2025 10:24: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 1uvvWT-0003Cm-Nw; Tue, 09 Sep 2025 10:24:25 +0000
Received: by outflank-mailman (input) for mailman id 1116313;
 Tue, 09 Sep 2025 10: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 1uvvIG-0001My-0q
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:09:44 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a9ebc25-8d65-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 12:09:42 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by DU4PR03MB10645.eurprd03.prod.outlook.com (2603:10a6:10:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 10:09:36 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%6]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 10:09: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: 1a9ebc25-8d65-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MT2QIuY4zkVz+rPLhRq9WWFVBhKzFEUq8oPdcrFO+gnrWBzV6j/u3pnn0RqHg/uoX0ic2pSnRbViB0e3CuKjqmzQV4KWOeG0NEfaXbmX8ipKTJOJlBlIoRX3dKFgA1if5WGpypoQIdDkJhhhf4GFFctr2oAAaf2stpG9X+fa22hpI5qhj41W064DSQMn3gTqeGd/K+Clc4r0ZrslcW5urRT+glFK2wbfCH4mYf0RGmHtxGvFJIkvUepUzQ036JClJwLsCYUxFK2VSwmjIkJj1n5YevEbOtG3iSRQaBCIk7Qx5JeIAihOqeyoxNbjzW2mMe2OYoAKzGVGIro3sK+PHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=a6bbvzsVUEc+kw99O4LcZ2YuLUneXWZV+PMGOFt5Akg=;
 b=IAFnHISyt+/5FLLj3iNrSsV+198JiIj6D3tFtpOVy1o6hyUo9MFKOycIpR2Z+3UkKhgzHM5zqArSH85Jw8aJkdtzmAsMyt2OqVmXXKew88nm/webnd5gd6PAG1CvgOjlzioCfzdeuEEeGzVRA1fg012ISJ6ypEhhm/RLAcX3QRPFFOyLutr7WfZKI4sRf6Pd5qf6hICdQMDEKPy9P8SRQ/M1h5mp2gHL7/q46N8a7nMRL/FH7R7wJ+SDwhEsOOiDN8drS/yR1JquscDYcCPjn8c8XR6h8VFssvgqgyouLt+I1Hrxb2RSkvXl8sziYA1s2512+NWbUQqkqgSYjFXyGA==
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=a6bbvzsVUEc+kw99O4LcZ2YuLUneXWZV+PMGOFt5Akg=;
 b=mxNcNuhcKlxKCbgB3urZFZy5SWUhg/c8C2IAK5PcEEXKGaRtPn6/wt1xO+H0JUbwLsqpC1O8PkLiY4xhI9rNCCXhx+dYK/HWmWcSnJisURw5D78nhb8mlFIi2pOmTiQMbApnu5drBTwSTvZhfIG9Eys4EVwAtQMyJ1jcTg7n4xeOXR2YLLplU7rdUVR+H/STZSbatrci/0fyjiwkQFixi6CI+wfSAccpAoBFG6LoBE5LfRDs1+pMx/BztgiTFQsK3lGxBmDxas8TlklCcbtisL6ChUaib0PvjdEVuOK1HnIFQ8YV49qx+x8hWwk7bE1vIkPVwjXk4kF0XU8/B8A/kQ==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: "olekstysh@gmail.com" , Leonid Komarianskyi
	, Anthony PERARD 
Subject: [PATCH v8 11/12] doc/man: update description for nr_spis with eSPI
Thread-Topic: [PATCH v8 11/12] doc/man: update description for nr_spis with
 eSPI
Thread-Index: AQHcIXHYUoPCk20zLE631w+3FsPjLA==
Date: Tue, 9 Sep 2025 10:09:35 +0000
Message-ID:
 <06fa3e1c3e6cb938df68e1eeda4c20e7cecb2797.1757412099.git.leonid_komarianskyi@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: GV2PR03MB8678:EE_|DU4PR03MB10645:EE_
x-ms-office365-filtering-correlation-id: 5218fcfb-53c6-4ca8-c4f9-08ddef88fac8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?8jHtXvTPLrAi5yQyx7UQileMi1VyFhAUpoDx/0STJW2q8q70mxeirfW1qu?=
 =?iso-8859-1?Q?6pQYfMp/OFDhFC3FAIC3BfL0k82oRMv4uOfVYt7RIMTiaLrx/N+xgZ3XED?=
 =?iso-8859-1?Q?iQf7ihFWoAFhDqR6Gl2USIlTrLdxUSJ8bZfT4qRc+l+5f5ia/3HhJl+qUH?=
 =?iso-8859-1?Q?WziQPLg8QdtwhbnCK6S/JOEPlUNjNbPQHOIu/M67MXI8R/G1OvTSmD4YoT?=
 =?iso-8859-1?Q?kOsbAcb75nNNQ9lb4Hs626ibELGqLj/zWDhziSex/6sKMltDS0JQdgwYw6?=
 =?iso-8859-1?Q?UAxi4d6bbqPZWGavun951Iz1FLNVssucdDXlYJAufCKwjJYgIG7VgDUljU?=
 =?iso-8859-1?Q?+XoFwIU88pRt2otEpaak+InSorqOJITaj1gseRHKVhUZzA22msmLVFoDwK?=
 =?iso-8859-1?Q?244fdXN8DxtjgtHjJ8Gtr4Tgc2HkWkZmq2B1Q5TCjUg5yMosyNhXtWlsQO?=
 =?iso-8859-1?Q?vRI8ETDTWEot12zJt9bmR3q874y1U2LTz7n3pOA1la+l732EQJFd7Bl9eq?=
 =?iso-8859-1?Q?rzHrqOcBO1FeLFC6ex+u0o5MgPwIyGxo2ZP8fpjvCw7AEiHTc9Ze6OJbgx?=
 =?iso-8859-1?Q?kL3zVOPe58fgqBtFfDpmoBaGPR0c0ar7Y/IC/om1UudH//5cz2rZO3W5EP?=
 =?iso-8859-1?Q?HzILAT0D5R3vWMRvYXq5IY/IVUfsFmUYcOCWeWhU41XuA+TjGxQZBGEv9q?=
 =?iso-8859-1?Q?ISwGOn4blG5jOtY+bjaU1HZaeOLoSBHPYAvNsYmeHcu6Tjm4nXE88nIUtS?=
 =?iso-8859-1?Q?E358Z1OpwOh5v8NxSZP+COY47lITXkCp6Rm8l0keI6nZBcAG5wXTyb719Q?=
 =?iso-8859-1?Q?7y/85GBVI0Y3TV7b0fHmmLNA9V9nq757oXSk60GPVTTt83kMK8MFKJOQcR?=
 =?iso-8859-1?Q?0TKyj8hN31WrpNon+Grw0STXNv59EQO9dXpbanLuLwDzsaFyMf1Fog7XM+?=
 =?iso-8859-1?Q?HeqqHwxohyOFvRRVeH/qg2vjkw2CRfw+Ns7AWbM+27iWnXparqXkfnIUav?=
 =?iso-8859-1?Q?wWQ9BoadWSy90HFIxZvBX0M8aOht5KRnIA5UCdDeHTTkXaca+3qO5ZQxYs?=
 =?iso-8859-1?Q?TkAGDhZWc6G39nMbdeQK06vaKmUWk4BTFch2NKI27HIxdaf3acroJXpRwp?=
 =?iso-8859-1?Q?7O9WjQce5/N2n6Gu/pGO+i/5xG6/6bbcBti4ZjOgDkQu54BNodW6PznrQq?=
 =?iso-8859-1?Q?ek5sFayH+EAtmEZCbP2UniCvk4tuOsiEXHloiMR+FprUQydMazt1dK08Kb?=
 =?iso-8859-1?Q?ho+WEcaoNvfLS3xYDcJKO94UGEF6l5g13aq5moz30I9YTm5fDpmT6U6UFN?=
 =?iso-8859-1?Q?U6ILqcQ2ZeafTP+xWTutMnSHwaR9MsKAIvIVzuaPHEr/YbfTbRkVx1OrvF?=
 =?iso-8859-1?Q?DFtfAV77Qk7x4ktO0AmmHJNMQ79ZEVAg8JTovJimJUwc7zVjo5xLmpCaAd?=
 =?iso-8859-1?Q?P505RCdSVBcAZ6MYoWRPBji3kqIzGSYBUU2X+c4Oo2v1KzsbgV4SPY3v/j?=
 =?iso-8859-1?Q?Bi+E3ZfI4x5q+AIdf80G/Ub7ukQcTp4jfhfxYwNbXcdjpSDLnEmpSDjpW2?=
 =?iso-8859-1?Q?UV9rd8Y=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?asH6YLO914yDlNBkBFr87NZMo9luCkEVAqOB8CQ+Rz1SkNxUoRWYMXQ4z+?=
 =?iso-8859-1?Q?e0tx1DOFeHfiy7Cl2E5hKIrDGsEeNHMOHFb6xJ2b6jSWbNZG9xW7wp3c5e?=
 =?iso-8859-1?Q?B0dDzG2xb5DBUTy/MiXrV+YpdctDucWDpJWBC1p0JBS0RkrBUKKDTR98hJ?=
 =?iso-8859-1?Q?Jbb2bVIDyDRLKiyjXcQiHMobAX7mxOkIlk/vlTjFtyfjfV4rgm36+MFsBy?=
 =?iso-8859-1?Q?csZleBjPvudOwErYAYao3Eved2P/Qo0F084Wbc7AEY1f/TfCPXF9S2rLdS?=
 =?iso-8859-1?Q?6tfWyEfv6li2Ts+Dy/L6f6chzGkOAM3JloBlXS2w/isJUQOep01hpI8mkI?=
 =?iso-8859-1?Q?LHafd6F3/1NWjk0Kdo8xC3m3RC/ygZFR3QQd/LiT2mHyqRRqx2R0d8YuE0?=
 =?iso-8859-1?Q?LAZHn/kKBdke1ot+ysmnG/C46Z/9NMkIgBJDdKlklWArd9W+BvTE+uqeBj?=
 =?iso-8859-1?Q?1xU1V/HMzv/4vqU31kuAG0UgJ66rgCD3onFcyk5iGNX/mUDJux4NJCVHUC?=
 =?iso-8859-1?Q?hWFZMjwZR1js3Gulpni7Gon9l8OyKPAzPf2Sz9nQ88T1Zt12JtQKlDXA2i?=
 =?iso-8859-1?Q?nv4W4LMSBvPRumwhsByK4zfW9GqT6fAoJ/iTuSDQJTs38Et8bhlPlb6GMO?=
 =?iso-8859-1?Q?FEMrEMGVofBfvpx7DNHfl6dc25C2n8iJIurFdmiNTNTQ/UfoTe251XKAu9?=
 =?iso-8859-1?Q?Vm9kNx2FmL3aatzD67rqO/Tb1O/ZmGt8drBFp5buRaGOeti1MQ+3H4SyvO?=
 =?iso-8859-1?Q?C27yBSyGYCZcvWs+lMilTT9nWcShjo+s1nN0Qd6ACcPg23HhNtZAh5Wb+B?=
 =?iso-8859-1?Q?1B+5t2/ceGfv5xuW6ankZwtDlWiyPAB6tHKseEq2HAbohlHr5GR6Acl70w?=
 =?iso-8859-1?Q?t3IskRdLc9qk68D8FN92g1vVsoa1wxRd6JYlBJgSUfBcplcYnOHdvRUoW0?=
 =?iso-8859-1?Q?B/ieVxzSH1BH/K/7RLlbgXCFpxB/o3xNMhoZBtnXG3zLtEQ06mKLA63rXn?=
 =?iso-8859-1?Q?l0K3un+MAD6T/BDgPZ2EldoL64h7ZTENQ0YLsOxINB0WgxdFM8cmKijANc?=
 =?iso-8859-1?Q?p4myz2hK6DMckGthPDJCkVYYCNJGt3xTWQgWe8JQfidZbtC4nvwfITQjkq?=
 =?iso-8859-1?Q?BOzMRz3QsNYesfEwn554zDFPB+detYqB8u42xma0eRW9V4/5MOy6doHGWN?=
 =?iso-8859-1?Q?X6LOu1LDZlLVq3yFCtd4ub8NlVO4/0p2fHXup1ddQtTr5FCkyIFpbwyz8Z?=
 =?iso-8859-1?Q?57gMjry7sL+p2JBgshiu1r2cvgrkykHXhpBHuK3ut1L6cQskf8J3MWSLmO?=
 =?iso-8859-1?Q?HEd8Ds1ZeiFswH8tCIwtgI+D1f4/pXvMG0c+Z6eAcydorqcQl7THaCAcPn?=
 =?iso-8859-1?Q?aAcoP3T6iB9fdpA9jx6xToGs/c0sWe58chNJ+aQLF5P2+yjHXi5d8B/KId?=
 =?iso-8859-1?Q?xqhUvDknpk+WGn74odqGM7NQmN1ag9rxyLJu0P9cJWfR1nuyhoIU9EvF1d?=
 =?iso-8859-1?Q?IPsiu38OGW1NXZ2Svsnwpp8ciU6dpnE1OWFfWobqf04zJZIHfF5nQlZinH?=
 =?iso-8859-1?Q?eNZR4ZV/klo7tWKmOnDCxhjP21agF4vx9grxtwR+/mK+ntbLaQvnuLS5hy?=
 =?iso-8859-1?Q?pqgMahkjHoclXyjG3yILjXSMThAtBqaLv8+EL870x9PAdIlsT+BntiAzIG?=
 =?iso-8859-1?Q?78hd59+NhAx2yd7wOE0=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5218fcfb-53c6-4ca8-c4f9-08ddef88fac8
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2025 10:09:35.8458
 (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: d1Vq5qPbVG7KieHDkr2uEGH5Q6gd4MLUW2ZiQC4qQV0Z0pXZEIctQoViO9Vqm8qDG29rsss8FbtKZt52t+Q5rCAI9Gwgz225amh9J2wQyiM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10645

Since eSPI support has been introduced, update the documentation with
the appropriate description.

Signed-off-by: Leonid Komarianskyi 

---
The discussion is ongoing and can be addressed in V5.
Clarification is needed from the maintainers.
Link:
- https://lore.kernel.org/xen-devel/87y0r4z717.fsf@epam.com/

Changes in V8:
- no changes

Changes in V7:
- no changes

Changes in V6:
- no changes

Changes in V5:
- no changes

Changes in V4:
- introduced this patch
---
 docs/man/xl.cfg.5.pod.in | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 5362fb0e9a..292ab10331 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3072,11 +3072,14 @@ interval of colors (such as "0-4").
 =3Ditem B
=20
 An optional integer parameter specifying the number of SPIs (Shared
-Peripheral Interrupts) to allocate for the domain. Max is 960 SPIs. If
-the `nr_spis` parameter is not specified, the value calculated by the tool=
stack
-will be used for the domain. Otherwise, the value specified by the `nr_spi=
s`
-parameter will be used. The number of SPIs should match the highest interr=
upt
-ID that will be assigned to the domain.
+Peripheral Interrupts) to allocate for the domain. Max is 960 for regular =
SPIs
+or 5088 for eSPIs (Extended SPIs). The eSPIs includes an additional 1024 S=
PIs
+from the eSPI range (4096 to 5119) if the hardware supports extended SPIs
+(GICv3.1+) and CONFIG_GICV3_ESPI is enabled. If the `nr_spis` parameter is=
 not
+specified, the value calculated by the toolstack will be used for the doma=
in.
+Otherwise, the value specified by the `nr_spis` parameter will be used. Th=
e
+number of SPIs should match the highest interrupt ID that will be assigned=
 to
+the domain.
=20
 =3Ditem B
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 10:57:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 10:57:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116342.1462692 (Exim 4.92)
	(envelope-from )
	id 1uvw2n-0000x0-AR; Tue, 09 Sep 2025 10:57:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116342.1462692; Tue, 09 Sep 2025 10:57: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 1uvw2n-0000wt-6g; Tue, 09 Sep 2025 10:57:49 +0000
Received: by outflank-mailman (input) for mailman id 1116342;
 Tue, 09 Sep 2025 10:57: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 1uvw2l-0000wn-9k
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 10:57:47 +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 d0740372-8d6b-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 12:57: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-out1.suse.de (Postfix) with ESMTPS id D28BD33713;
 Tue,  9 Sep 2025 10:57: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 A3FB51388C;
 Tue,  9 Sep 2025 10:57: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 LT2UJiYIwGhgKwAAD6G6ig
 (envelope-from ); Tue, 09 Sep 2025 10: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" 
X-Inumbo-ID: d0740372-8d6b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757415463; 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=cFnHMKKJvw2hNIRz44gCdMjVIEH9NTGpycW1myzuOAs=;
	b=ocixYpl6AVe2j8JrYrDSOCw4ykekhXgRlgZ0kyF3sjF1/lbNYGQmfQ8B32P6YMos9IeVzr
	wLQT7C/N6jUDIR9QUop/hROMVW2CRK79XLgHWNp0NfV/Pb0+sd0Q7ej1hKw5ugckTmrpcL
	wBh7tK2HBUXbjFx9voyOqbQN0Ym78OY=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757415463; 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=cFnHMKKJvw2hNIRz44gCdMjVIEH9NTGpycW1myzuOAs=;
	b=ocixYpl6AVe2j8JrYrDSOCw4ykekhXgRlgZ0kyF3sjF1/lbNYGQmfQ8B32P6YMos9IeVzr
	wLQT7C/N6jUDIR9QUop/hROMVW2CRK79XLgHWNp0NfV/Pb0+sd0Q7ej1hKw5ugckTmrpcL
	wBh7tK2HBUXbjFx9voyOqbQN0Ym78OY=
Message-ID: 
Date: Tue, 9 Sep 2025 12:57:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.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="------------GRqgesMXsTlpWDpme2z20vFJ"
X-Spam-Level: 
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.998];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid];
	RCPT_COUNT_TWELVE(0.00)[34];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	MID_RHS_MATCH_FROM(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[vger.kernel.org,linux.ibm.com,gaisler.com,linux-foundation.org,oracle.com,alien8.de,arm.com,csgroup.eu,linux.intel.com,davemloft.net,zytor.com,redhat.com,google.com,ellerman.id.au,suse.com,kernel.org,gmail.com,infradead.org,linutronix.de,suse.cz,lists.infradead.org,lists.ozlabs.org,lists.xenproject.org];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -6.20

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------GRqgesMXsTlpWDpme2z20vFJ
Content-Type: multipart/mixed; boundary="------------XzcF73Vy0QpbV8oE9lMvMlg0";
 protected-headers="v1"
From: Juergen Gross 
To: David Hildenbrand ,
 Kevin Brodsky , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
In-Reply-To: 

--------------XzcF73Vy0QpbV8oE9lMvMlg0
Content-Type: multipart/mixed; boundary="------------d9o8Vv6o396RywxeHiihFy53"

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

T24gMDkuMDkuMjUgMTE6MDcsIERhdmlkIEhpbGRlbmJyYW5kIHdyb3RlOg0KPiBPbiAwOC4w
OS4yNSAwOTozOSwgS2V2aW4gQnJvZHNreSB3cm90ZToNCj4+IGFyY2hfe2VudGVyLGxlYXZl
fV9sYXp5X21tdV9tb2RlKCkgY3VycmVudGx5IGhhdmUgYSBzdGF0ZWxlc3MgQVBJDQo+PiAo
dGFraW5nIGFuZCByZXR1cm5pbmcgbm8gdmFsdWUpLiBUaGlzIGlzIHByb3ZpbmcgcHJvYmxl
bWF0aWMgaW4NCj4+IHNpdHVhdGlvbnMgd2hlcmUgbGVhdmUoKSBuZWVkcyB0byByZXN0b3Jl
IHNvbWUgY29udGV4dCBiYWNrIHRvIGl0cw0KPj4gb3JpZ2luYWwgc3RhdGUgKGJlZm9yZSBl
bnRlcigpIHdhcyBjYWxsZWQpLiBJbiBwYXJ0aWN1bGFyLCB0aGlzDQo+PiBtYWtlcyBpdCBk
aWZmaWN1bHQgdG8gc3VwcG9ydCB0aGUgbmVzdGluZyBvZiBsYXp5X21tdSBzZWN0aW9ucyAt
DQo+PiBsZWF2ZSgpIGRvZXMgbm90IGtub3cgd2hldGhlciB0aGUgbWF0Y2hpbmcgZW50ZXIo
KSBjYWxsIG9jY3VycmVkDQo+PiB3aGlsZSBsYXp5X21tdSB3YXMgYWxyZWFkeSBlbmFibGVk
LCBhbmQgd2hldGhlciB0byBkaXNhYmxlIGl0IG9yDQo+PiBub3QuDQo+Pg0KPj4gVGhpcyBw
YXRjaCBnaXZlcyBhbGwgYXJjaGl0ZWN0dXJlcyB0aGUgY2hhbmNlIHRvIHN0b3JlIGxvY2Fs
IHN0YXRlDQo+PiB3aGlsZSBpbnNpZGUgYSBsYXp5X21tdSBzZWN0aW9uIGJ5IG1ha2luZyBl
bnRlcigpIHJldHVybiBzb21lIHZhbHVlLA0KPj4gc3RvcmluZyBpdCBpbiBhIGxvY2FsIHZh
cmlhYmxlLCBhbmQgaGF2aW5nIGxlYXZlKCkgdGFrZSB0aGF0IHZhbHVlLg0KPj4gVGhhdCB2
YWx1ZSBpcyB0eXBlZCBsYXp5X21tdV9zdGF0ZV90IC0gZWFjaCBhcmNoaXRlY3R1cmUgZGVm
aW5pbmcNCj4+IF9fSEFWRV9BUkNIX0VOVEVSX0xBWllfTU1VX01PREUgaXMgZnJlZSB0byBk
ZWZpbmUgaXQgYXMgaXQgc2VlcyBmaXQuDQo+PiBGb3Igbm93IHdlIGRlZmluZSBpdCBhcyBp
bnQgZXZlcnl3aGVyZSwgd2hpY2ggaXMgc3VmZmljaWVudCB0bw0KPj4gc3VwcG9ydCBuZXN0
aW5nLg0KPj4NCj4+IFRoZSBkaWZmIGlzIHVuZm9ydHVuYXRlbHkgcmF0aGVyIGxhcmdlIGFz
IGFsbCB0aGUgQVBJIGNoYW5nZXMgbmVlZA0KPj4gdG8gYmUgZG9uZSBhdG9taWNhbGx5LiBN
YWluIHBhcnRzOg0KPj4NCj4+ICogQ2hhbmdpbmcgdGhlIHByb3RvdHlwZXMgb2YgYXJjaF97
ZW50ZXIsbGVhdmV9X2xhenlfbW11X21vZGUoKQ0KPj4gwqDCoCBpbiBnZW5lcmljIGFuZCBh
cmNoIGNvZGUsIGFuZCBpbnRyb2R1Y2luZyBsYXp5X21tdV9zdGF0ZV90Lg0KPj4NCj4+ICog
SW50cm9kdWNpbmcgTEFaWV9NTVVfe0RFRkFVTFQsTkVTVEVEfSBmb3IgZnV0dXJlIHN1cHBv
cnQgb2YNCj4+IMKgwqAgbmVzdGluZy4gZW50ZXIoKSBhbHdheXMgcmV0dXJucyBMQVpZX01N
VV9ERUZBVUxUIGZvciBub3cuDQo+PiDCoMKgIChsaW51eC9tbV90eXBlcy5oIGlzIG5vdCB0
aGUgbW9zdCBuYXR1cmFsIGxvY2F0aW9uIGZvciBkZWZpbmluZw0KPj4gwqDCoCB0aG9zZSBj
b25zdGFudHMsIGJ1dCB0aGVyZSBpcyBubyBvdGhlciBvYnZpb3VzIGhlYWRlciB0aGF0IGlz
DQo+PiDCoMKgIGFjY2Vzc2libGUgd2hlcmUgYXJjaCdzIGltcGxlbWVudCB0aGUgaGVscGVy
cy4pDQo+Pg0KPj4gKiBDaGFuZ2luZyBhbGwgbGF6eV9tbXUgc2VjdGlvbnMgdG8gaW50cm9k
dWNlIGEgbGF6eV9tbXVfc3RhdGUNCj4+IMKgwqAgbG9jYWwgdmFyaWFibGUsIGhhdmluZyBl
bnRlcigpIHNldCBpdCBhbmQgbGVhdmUoKSB0YWtlIGl0LiBNb3N0IG9mDQo+PiDCoMKgIHRo
ZXNlIGNoYW5nZXMgd2VyZSBnZW5lcmF0ZWQgdXNpbmcgdGhlIGZvbGxvd2luZyBDb2NjaW5l
bGxlIHNjcmlwdDoNCj4+DQo+PiBAQA0KPj4gQEANCj4+IHsNCj4+ICsgbGF6eV9tbXVfc3Rh
dGVfdCBsYXp5X21tdV9zdGF0ZTsNCj4+IC4uLg0KPj4gLSBhcmNoX2VudGVyX2xhenlfbW11
X21vZGUoKTsNCj4+ICsgbGF6eV9tbXVfc3RhdGUgPSBhcmNoX2VudGVyX2xhenlfbW11X21v
ZGUoKTsNCj4+IC4uLg0KPj4gLSBhcmNoX2xlYXZlX2xhenlfbW11X21vZGUoKTsNCj4+ICsg
YXJjaF9sZWF2ZV9sYXp5X21tdV9tb2RlKGxhenlfbW11X3N0YXRlKTsNCj4+IC4uLg0KPj4g
fQ0KPj4NCj4+ICogSW4gYSBmZXcgY2FzZXMgKGUuZy4geGVuX2ZsdXNoX2xhenlfbW11KCkp
LCBhIGZ1bmN0aW9uIGtub3dzIHRoYXQNCj4+IMKgwqAgbGF6eV9tbXUgaXMgYWxyZWFkeSBl
bmFibGVkLCBhbmQgaXQgdGVtcG9yYXJpbHkgZGlzYWJsZXMgaXQgYnkNCj4+IMKgwqAgY2Fs
bGluZyBsZWF2ZSgpIGFuZCB0aGVuIGVudGVyKCkgYWdhaW4uIEhlcmUgd2Ugd2FudCB0byBl
bnN1cmUNCj4+IMKgwqAgdGhhdCBhbnkgb3BlcmF0aW9uIGJldHdlZW4gdGhlIGxlYXZlKCkg
YW5kIGVudGVyKCkgY2FsbHMgaXMNCj4+IMKgwqAgY29tcGxldGVkIGltbWVkaWF0ZWx5OyBm
b3IgdGhhdCByZWFzb24gd2UgcGFzcyBMQVpZX01NVV9ERUZBVUxUIHRvDQo+PiDCoMKgIGxl
YXZlKCkgdG8gZnVsbHkgZGlzYWJsZSBsYXp5X21tdS4gZW50ZXIoKSB3aWxsIHRoZW4gcmUt
ZW5hYmxlIGl0DQo+PiDCoMKgIC0gdGhpcyBhY2hpZXZlcyB0aGUgZXhwZWN0ZWQgYmVoYXZp
b3VyLCB3aGV0aGVyIG5lc3Rpbmcgb2NjdXJyZWQNCj4+IMKgwqAgYmVmb3JlIHRoYXQgZnVu
Y3Rpb24gd2FzIGNhbGxlZCBvciBub3QuDQo+Pg0KPj4gTm90ZTogaXQgaXMgZGlmZmljdWx0
IHRvIHByb3ZpZGUgYSBkZWZhdWx0IGRlZmluaXRpb24gb2YNCj4+IGxhenlfbW11X3N0YXRl
X3QgZm9yIGFyY2hpdGVjdHVyZXMgaW1wbGVtZW50aW5nIGxhenlfbW11LCBiZWNhdXNlDQo+
PiB0aGF0IGRlZmluaXRpb24gd291bGQgbmVlZCB0byBiZSBhdmFpbGFibGUgaW4NCj4+IGFy
Y2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmggYW5kIGFkZGluZyBhIG5ldyBn
ZW5lcmljDQo+PiDCoCAjaW5jbHVkZSB0aGVyZSBpcyB2ZXJ5IHRyaWNreSBkdWUgdG8gdGhl
IGV4aXN0aW5nIGhlYWRlciBzb3VwLg0KPiANCj4gWWVhaCwgSSB3YXMgd29uZGVyaW5nIGFi
b3V0IGV4YWN0bHkgdGhhdC4NCj4gDQo+IEluIHBhcnRpY3VsYXIgYmVjYXVzZSBMQVpZX01N
VV9ERUZBVUxUIGV0YyByZXNpZGVzIHNvbWV3ZWhlcmUgY29tcGVsdGVseSBkaWZmZXJlbnQu
DQo+IA0KPiBXaGljaCByYWlzZXMgdGhlIHF1ZXN0aW9uOiBpcyB1c2luZyBhIG5ldyB0eXBl
IHJlYWxseSBvZiBhbnkgYmVuZWZpdCBoZXJlPw0KPiANCj4gQ2FuJ3Qgd2UganVzdCB1c2Ug
YW4gImVudW0gbGF6eV9tbXVfc3RhdGUiIGFuZCBjYWxsIGl0IGEgZGF5Pw0KPiANCg0KVGhl
IGNvbW1lbnQgYWJvdXQgdGhlICJoZWFkZXIgc291cCIgbWFkZSBtZSBsb29rIGludG8gdGhp
cyBwcm9ibGVtOg0KDQpJdCBzZWVtcyBzb21lIG9mIHRoZSAiI2luY2x1ZGUgPGFzbS9wYXJh
dmlydC5oPiIgaW5zdGFuY2VzIGluIHRoZSBjb2RlDQpiYXNlIGNhbiBqdXN0IGJlIGRyb3Bw
ZWQuDQoNCkZvciB0aGUgcmVtYWluaW5nIGNhc2VzIEknZCBsaWtlIHRvIHN1Z2dlc3QgYSBy
ZW9yZyBvZiB0aGUgcmVsYXRlZCBoZWFkZXJzOg0KSW5zdGVhZCBvZiBoYXZpbmcgdGhlIG5v
bi1wYXJhdmlydCBkZWZpbml0aW9uIGluIG9uZSBoZWFkZXIgYW5kIHRoZSBwYXJhdmlydA0K
b25lcyBpbiBwYXJhdmlydC5oLCBtYXliZSBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSBv
bmx5IHRoZSBwYXJhdmlydA0KZ2VuZXJpYyBkZWZpbml0aW9ucyBpbiBwYXJhdmlydC5oIGFu
ZCB0aGUgc3BlY2lmaWMgZnVuY3Rpb25zIGluIHRoZSBoZWFkZXINCmRlZmluaW5nIHRoZSBu
b24tcGFyYXZpcnQgdmFyaWFudC4gVGhpcyB3b3VsZCBwcm9iYWJseSByZXNvbHZlIHRoZSBw
cm9ibGVtDQp3aXRoIHRoZSAic291cCIsIGFzIHBhcmF2aXJ0Lmggd291bGRuJ3QgcmVseSBv
biBzbyBtYW55IG90aGVyIGhlYWRlcnMuDQoNCkknbSBqdXN0IHByZXBhcmluZyBhIHBhdGNo
IGRvaW5nIHRoZSByZW1vdmFsIG9mIHRoZSBub3QgbmVlZGVkIGluY2x1ZGVzLCBidXQNCkkn
ZCBiZSB3aWxsaW5nIHRvIGFkZHJlc3MgdGhlIGRpc2VudGFuZ2xpbmcgYXMgbm90ZWQgYWJv
dmUuDQoNClRob3VnaHRzPw0KDQoNCkp1ZXJnZW4NCg==
--------------d9o8Vv6o396RywxeHiihFy53
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-----

--------------d9o8Vv6o396RywxeHiihFy53--

--------------XzcF73Vy0QpbV8oE9lMvMlg0--

--------------GRqgesMXsTlpWDpme2z20vFJ
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/Ey8FAmjACCYFAwAAAAAACgkQsN6d1ii/Ey+Y
rAf/a4oKv1HBGDLbyN8w9JJ1cvmDi8HCAVfE8JpHcscFZ6WfY0W3x7b2BXcNBGAweVtspi+Khbh7
p2jCnvCaEWA68NFXxp/i+Jgk8dzbtvEga/H/v3E/MysbxG2y5GzDrh03L6TJpzLinkMabDXj2YLh
0dh415a3I+mSGd8oIAETpH0UsCL8f5SSY7jl9NwNPSelfslAY0AjNVQz/DnrmyIr8QfGeyAOuyWN
u1ECkDwVJb/Egirn8Yur5N8Mhsre0q02WSdIQdohQ3RJIcUNCQ3DNTR2vqNXjEf1wEQmU5nMxbnA
dy5/GJfBm79JHqzXY+qTn4mz44Xy8GnnpNtRKt6lZQ==
=I/jH
-----END PGP SIGNATURE-----

--------------GRqgesMXsTlpWDpme2z20vFJ--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 11:29:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 11:29:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116364.1462701 (Exim 4.92)
	(envelope-from )
	id 1uvwX2-0005TC-Nx; Tue, 09 Sep 2025 11:29:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116364.1462701; Tue, 09 Sep 2025 11:29: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 1uvwX2-0005T5-LD; Tue, 09 Sep 2025 11:29:04 +0000
Received: by outflank-mailman (input) for mailman id 1116364;
 Tue, 09 Sep 2025 11:29: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 1uvwX1-0005Sz-EG
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 11:29:03 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 2f010c0b-8d70-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 13:29:01 +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 5CB201424;
 Tue,  9 Sep 2025 04:28:52 -0700 (PDT)
Received: from [10.57.79.24] (unknown [10.57.79.24])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CF8BD3F694;
 Tue,  9 Sep 2025 04:28: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: 2f010c0b-8d70-11f0-9d13-b5c5bf9af7f9
Message-ID: <0fd00f60-d3f1-4c86-925c-6947decb5159@arm.com>
Date: Tue, 9 Sep 2025 13:28:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] x86/xen: support nested lazy_mmu sections (again)
To: David Hildenbrand , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 , linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-5-kevin.brodsky@arm.com>
 
 <360712fa-f7a0-4674-acc4-76f79141fe4f@suse.com>
 <57f49b72-2126-48f0-a4ef-4b138bd0bead@redhat.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <57f49b72-2126-48f0-a4ef-4b138bd0bead@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 11:56, David Hildenbrand wrote:
> On 09.09.25 11:37, Jürgen Groß wrote:
>> On 09.09.25 11:13, David Hildenbrand wrote:
>>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>>> Commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode")
>>>> originally introduced support for nested lazy sections (LAZY_MMU and
>>>> LAZY_CPU). It later got reverted by commit c36549ff8d84 as its
>>>> implementation turned out to be intolerant to preemption.
>>>>
>>>> Now that the lazy_mmu API allows enter() to pass through a state to
>>>> the matching leave() call, we can support nesting again for the
>>>> LAZY_MMU mode in a preemption-safe manner. If xen_enter_lazy_mmu() is
>>>> called inside an active lazy_mmu section, xen_lazy_mode will already
>>>> be set to XEN_LAZY_MMU and we can then return LAZY_MMU_NESTED to
>>>> instruct the matching xen_leave_lazy_mmu() call to leave
>>>> xen_lazy_mode unchanged.
>>>>
>>>> The only effect of this patch is to ensure that xen_lazy_mode
>>>> remains set to XEN_LAZY_MMU until the outermost lazy_mmu section
>>>> ends. xen_leave_lazy_mmu() still calls xen_mc_flush()
>>>> unconditionally.
>>>>
>>>> Signed-off-by: Kevin Brodsky 
>>>> ---
>>>>    arch/x86/include/asm/paravirt.h       |  6 ++----
>>>>    arch/x86/include/asm/paravirt_types.h |  4 ++--
>>>>    arch/x86/xen/mmu_pv.c                 | 11 ++++++++---
>>>>    3 files changed, 12 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/x86/include/asm/paravirt.h
>>>> b/arch/x86/include/asm/paravirt.h
>>>> index 65a0d394fba1..4ecd3a6b1dea 100644
>>>> --- a/arch/x86/include/asm/paravirt.h
>>>> +++ b/arch/x86/include/asm/paravirt.h
>>>> @@ -529,14 +529,12 @@ static inline void
>>>> arch_end_context_switch(struct
>>>> task_struct *next)
>>>>    #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>>>>    static inline lazy_mmu_state_t arch_enter_lazy_mmu_mode(void)
>>>>    {
>>>> -    PVOP_VCALL0(mmu.lazy_mode.enter);
>>>> -
>>>> -    return LAZY_MMU_DEFAULT;
>>>> +    return PVOP_CALL0(lazy_mmu_state_t, mmu.lazy_mode.enter);
>>>>    }
>>>>    static inline void arch_leave_lazy_mmu_mode(lazy_mmu_state_t state)
>>>>    {
>>>> -    PVOP_VCALL0(mmu.lazy_mode.leave);
>>>> +    PVOP_VCALL1(mmu.lazy_mode.leave, state);
>>>>    }
>>>>    static inline void arch_flush_lazy_mmu_mode(void)
>>>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>>> b/arch/x86/include/asm/
>>>> paravirt_types.h
>>>> index bc1af86868a3..b7c567ccbf32 100644
>>>> --- a/arch/x86/include/asm/paravirt_types.h
>>>> +++ b/arch/x86/include/asm/paravirt_types.h
>>>> @@ -45,8 +45,8 @@ typedef int lazy_mmu_state_t;
>>>>    struct pv_lazy_ops {
>>>>        /* Set deferred update mode, used for batching operations. */
>>>> -    void (*enter)(void);
>>>> -    void (*leave)(void);
>>>> +    lazy_mmu_state_t (*enter)(void);
>>>> +    void (*leave)(lazy_mmu_state_t);
>>>>        void (*flush)(void);
>>>>    } __no_randomize_layout;
>>>>    #endif
>>>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>>>> index 2039d5132ca3..6e5390ff06a5 100644
>>>> --- a/arch/x86/xen/mmu_pv.c
>>>> +++ b/arch/x86/xen/mmu_pv.c
>>>> @@ -2130,9 +2130,13 @@ static void xen_set_fixmap(unsigned idx,
>>>> phys_addr_t
>>>> phys, pgprot_t prot)
>>>>    #endif
>>>>    }
>>>> -static void xen_enter_lazy_mmu(void)
>>>> +static lazy_mmu_state_t xen_enter_lazy_mmu(void)
>>>>    {
>>>> +    if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU)
>>>> +        return LAZY_MMU_NESTED;
>>>> +
>>>
>>> You mention above "preemption-safe manner" above, so I am wondering,
>>> what if we get preempted immediately after doing the this_cpu_read()
>>> and get
>>> scheduled on another CPU?
>>>
>>
>> This should still be correct: preemption needs a context switch to
>> happen,
>> so xen_start_context_switch() and xen_end_context_switch() are involved.
>> Those are dealing with this problem by doing the right thing in the old
>> and the new context.
>
> Thanks, that makes sense. Would be valuable to add that detail to the
> patch description. 

That's a fair point, Alexander was also wondering in v1 (and so was I
when I worked on this patch). Will clarify in v3.

- Kevin


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 11:47:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 11:47:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116383.1462711 (Exim 4.92)
	(envelope-from )
	id 1uvwoJ-0008Jg-4J; Tue, 09 Sep 2025 11:46:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116383.1462711; Tue, 09 Sep 2025 11:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvwoJ-0008JZ-1l; Tue, 09 Sep 2025 11:46:55 +0000
Received: by outflank-mailman (input) for mailman id 1116383;
 Tue, 09 Sep 2025 11:46:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvwoI-0008JT-5R
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 11:46:54 +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 ac89f271-8d72-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 13:46:51 +0200 (CEST)
Received: from pps.filterd (m0353725.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5896Wdr4031713;
 Tue, 9 Sep 2025 11:45:56 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490bcsq781-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 11:45:56 +0000 (GMT)
Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 589BTqxc006985;
 Tue, 9 Sep 2025 11:45:55 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490bcsq77y-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 11:45:55 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 589BMn2N001188;
 Tue, 9 Sep 2025 11:45:54 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 491203akyh-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 11:45:54 +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
 589BjqjF8323344
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 9 Sep 2025 11:45:53 GMT
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id D59D020043;
 Tue,  9 Sep 2025 11:45:52 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 247CD20040;
 Tue,  9 Sep 2025 11:45:52 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue,  9 Sep 2025 11:45:52 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ac89f271-8d72-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=CW2dDor0IqMzIAmq0spxwQ7puBTFQt
	VzTFSMyEgoGjA=; b=P7fiZwOZoDl89TYxIoDk4jbhXrf0kjh5+A0apcBU6C2GdT
	340+8Qq55LXFwzCb2OnrGtv2LTms5uaynX6WfkjgKzFQGzs3e9pvZUBahm6iSSWT
	WAluYtYKMO3NEFWsaHTLmzNgjJggCA+UUE8JfV+YFOMHIpa6bduy64J5wPglMBbo
	1st8bDHq/DM0/FJSwtUsBhE7FRmCOK1/CvbO0pfJAVLuQ89IraoJ4ZhEiV9SJGge
	R76Ejpm7X8SvuisIf2tyP1lB+0dxfGRnwYufiviL57J7ea4xGb3TC+Uy45RwDr54
	4cOe5ZFz+UmaDEeE2xXzL/ExCyZXDdsidA5E1ouQ==
Date: Tue, 9 Sep 2025 13:45:50 +0200
From: Alexander Gordeev 
To: David Hildenbrand 
Cc: Kevin Brodsky , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-TM-AS-GCONF: 00
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDAxMCBTYWx0ZWRfXzv0l4od4j6eW
 QmMdktKyBl9+62xDiwDCsXs13FmwdhJ/yKVW0Nx7wmldwiO4Gphv89/+dwt/LpECn2XxOtXfh60
 jKyl21EsFo5dPWLP41rL8yAE8JVwfpPHGCyDSUYtA7sAOdIW58vIVprQ0pXotY+dKbj+gh2UVow
 aUYpiI8EbPfiUOAf+qOVUjNN2gNw6goKU2Itja8LgZVxED1lOakW8e7o8p6kPC5x+5elb/cjfAw
 /8FfQVABacfNl7ZdgYZjcvC3V+L7x+hQVkP58f0SM4yX0U4T+rMqQaJBKGdD5nUVcqnn5OalH7l
 hJOgJuaJEM3zF3TSqJtIp3pJKLVcHjM9sdtipTndXY1FAdeDQTINxSKeTjMqDRhxe/M13RVfvwK
 e7diuTK0
X-Authority-Analysis: v=2.4 cv=SKNCVPvH c=1 sm=1 tr=0 ts=68c01374 cx=c_pps
 a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=sjzYMD-SKWPhrPIpRwUA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-GUID: XopatD14CEfuivKQbcWn3mfk3pBU2G5u
X-Proofpoint-ORIG-GUID: YV8Uas4Jwghz0nGFl4MnfkXLTyTlxDw-
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-09_01,2025-09-08_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 clxscore=1015 spamscore=0 priorityscore=1501 bulkscore=0 malwarescore=0
 adultscore=0 suspectscore=0 impostorscore=0 phishscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509060010

On Tue, Sep 09, 2025 at 12:09:48PM +0200, David Hildenbrand wrote:
> On 09.09.25 11:40, Alexander Gordeev wrote:
> > On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
> > > On 08.09.25 09:39, Kevin Brodsky wrote:
> > > > arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> > > > (taking and returning no value). This is proving problematic in
> > > > situations where leave() needs to restore some context back to its
> > > > original state (before enter() was called). In particular, this
> > > > makes it difficult to support the nesting of lazy_mmu sections -
> > > > leave() does not know whether the matching enter() call occurred
> > > > while lazy_mmu was already enabled, and whether to disable it or
> > > > not.
> > > > 
> > > > This patch gives all architectures the chance to store local state
> > > > while inside a lazy_mmu section by making enter() return some value,
> > > > storing it in a local variable, and having leave() take that value.
> > > > That value is typed lazy_mmu_state_t - each architecture defining
> > > > __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> > > > For now we define it as int everywhere, which is sufficient to
> > > > support nesting.
> > ...
> > > > {
> > > > + lazy_mmu_state_t lazy_mmu_state;
> > > > ...
> > > > - arch_enter_lazy_mmu_mode();
> > > > + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> > > > ...
> > > > - arch_leave_lazy_mmu_mode();
> > > > + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> > > > ...
> > > > }
> > > > 
> > > > * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
> > > >     lazy_mmu is already enabled, and it temporarily disables it by
> > > >     calling leave() and then enter() again. Here we want to ensure
> > > >     that any operation between the leave() and enter() calls is
> > > >     completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
> > > >     leave() to fully disable lazy_mmu. enter() will then re-enable it
> > > >     - this achieves the expected behaviour, whether nesting occurred
> > > >     before that function was called or not.
> > > > 
> > > > Note: it is difficult to provide a default definition of
> > > > lazy_mmu_state_t for architectures implementing lazy_mmu, because
> > > > that definition would need to be available in
> > > > arch/x86/include/asm/paravirt_types.h and adding a new generic
> > > >    #include there is very tricky due to the existing header soup.
> > > 
> > > Yeah, I was wondering about exactly that.
> > > 
> > > In particular because LAZY_MMU_DEFAULT etc resides somewehere compeltely
> > > different.
> > > 
> > > Which raises the question: is using a new type really of any benefit here?
> > > 
> > > Can't we just use an "enum lazy_mmu_state" and call it a day?
> > 
> > I could envision something completely different for this type on s390,
> > e.g. a pointer to a per-cpu structure. So I would really ask to stick
> > with the current approach.
> 
> Would that integrate well with LAZY_MMU_DEFAULT etc?

Hmm... I though the idea is to use LAZY_MMU_* by architectures that
want to use it - at least that is how I read the description above.

It is only kasan_populate|depopulate_vmalloc_pte() in generic code
that do not follow this pattern, and it looks as a problem to me.

> -- 
> Cheers
> 
> David / dhildenb

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 11:48:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 11:48:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116394.1462722 (Exim 4.92)
	(envelope-from )
	id 1uvwpn-0000QI-EE; Tue, 09 Sep 2025 11:48:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116394.1462722; Tue, 09 Sep 2025 11:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvwpn-0000QB-B8; Tue, 09 Sep 2025 11:48:27 +0000
Received: by outflank-mailman (input) for mailman id 1116394;
 Tue, 09 Sep 2025 11:48:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvwpl-0000Q5-Va
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 11:48:25 +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 e3de6404-8d72-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 13:48:23 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b0449b1b56eso804779166b.1
 for ; Tue, 09 Sep 2025 04:48: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-b04670b5eacsm1507551766b.27.2025.09.09.04.48.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 04:48: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: e3de6404-8d72-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757418503; x=1758023303; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=si+TFBWW2d+pAwZZw/WH0jcWpZgvOA1F2Gn4rX/yois=;
        b=fb3QSs4Qyn+v/+nUkfTUWYCBS5Zm4eJxNt72UUJvg5HVDKRLYlXhqwslVXrvElGxmU
         EvcmZUIxrMOOw8gefo6txjUvbJIUJ3EQIvoirankmfuzN+ho4pjYwKDKqS5Vr4pS9vgL
         MX/cf6UTRd9a6gKPIh7hxfX5XRdl/CpynwSsDaQC0KwT2OzoTYlnwpi8ua5mM9wo1uO3
         f8vlW8emrYUfFi16DC+e+/OQ4Jbp9Q3+X6wPms11rs6Nm2k7cOAIBhM8NxMuDhNRQkND
         QD/AeLfWetRMsKitT4qk/n9yKxO/1miU8rbNMoPR1FL4NuMqxNd0JL0YuYaEclreqqAJ
         Q8AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757418503; x=1758023303;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=si+TFBWW2d+pAwZZw/WH0jcWpZgvOA1F2Gn4rX/yois=;
        b=wUTxXgHP2YrFBwuP0UD7eHGyRkB24X+uSbpKAx7Y+8waeITMBvIxsAX2Wn8WUuCgLG
         KNb9EgkjV3bX1v8w9RTsamsjrvpVg/SXOVWUEzN4bg8ereiGn4eRClXFOCn1SQ5RqGZu
         jS3+ffTeGapNQFDqUgPmnUP2t7YTert76NRqxzy+Hi2neCCuKxqL261jrCZiYAJWkwNE
         UYwTji4H3pxb0VzWZTw39f8f6uptn9Lze46W0iC3gndwd0f22YMuEWaOSm5R9yEhoXcP
         63GqTjW6EZEMkOJPEnVhTwf5EnALq5aVW0nkurChfewYNgTMah2PKyq+lIe/YovgY2mm
         YBfg==
X-Forwarded-Encrypted: i=1; AJvYcCXuvI+7/ALg+nUBzfBoQ1ER8xo8BEd+D/5MFAPyE9a1f/UoCTUVI/d4mBMu/NQDvysZ/+EFDyMCygo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAVIMpLStDubnC+X9XF0weQimtdsu7C6bx/xcXnxxA3AHH5CAD
	H+HBsHnhcTgF8tc/vy+nxH/gggu23rf2PQ5JfK68n7i1i5VcYchfA/rKgslRuO+LYA==
X-Gm-Gg: ASbGncsOkOFkxN7rulfCAd15BtjvWoMmb1+PV/0hH17mIJDG5pDsmvoJ0qbSUSyi4PJ
	XcN69G72eV2caFs1HVKWkJXlDI/B8fszLk96ty2/AKscCbLRVDJLhOt5XfzGwfTSv9BnYETaNvl
	qaVRgbEJqqSr9RCZ9iRseGwQ5qcOR7ekhDbYg33cGYc5Eyg0PHH4x1cPlUmjLlJWPAAyRBtwLKE
	ExynOXkEw8nVhylrcuoErUit94tQL7PpoW+7T6eAqh9kodKYrjBsOp00c816Z4jkwQpELuC/0u+
	6888NB0S31Qnuf2kOxeedMs+IiAyEOVpVtqpC6hCqwUX0OftiySwRLm0Njyz/mktKdlIjooQvtC
	Oij++7EDZ1WqztMsjpsYueD/B7cXEPEtxPsfm14exd0vuXnmYUMbypZbqwpsRx7HS5xqc/KrXOi
	RYLINjL+mWFHScgpZoXw==
X-Google-Smtp-Source: AGHT+IHmJ1UoN/YX+YLdWXEnVsMkWdEhlwjct2tncvIE/nnp9Sn84gGnRJldA4LkjqecQuIfysVp6Q==
X-Received: by 2002:a17:907:7f89:b0:b04:725c:bcb with SMTP id a640c23a62f3a-b04b14b7851mr1087810366b.23.1757418503141;
        Tue, 09 Sep 2025 04:48:23 -0700 (PDT)
Message-ID: <370220d9-5ed7-429d-ab9c-2b947911de75@suse.com>
Date: Tue, 9 Sep 2025 13:48:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 11/13] 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?= ,
 Saeed Nowshadi ,
 Mykyta Poturai ,
 Mykola Kvach , xen-devel@lists.xenproject.org
References: 
 <547196292a007ec2bbedd52036e8f8a0cc69c4ea.1756763487.git.mykola_kvach@epam.com>
 
 
 
 <21f2f6e1-cbf7-4b36-bbba-bffc2dab3422@suse.com>
 
 <646f7070-83c7-45ce-a4c9-c59cd39a33c5@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.09.2025 11:55, Mykola Kvach wrote:
> On Tue, Sep 9, 2025 at 12:14 PM Jan Beulich  wrote:
>> On 09.09.2025 10:14, Mykola Kvach wrote:
>>> On Tue, Sep 9, 2025 at 9:57 AM Jan Beulich  wrote:
>>>> Furthermore with continuing to (ab)use domain_shutdown() also for the
>>>> suspend case (Dom0 isn't really shut down when suspending, aiui), you
>>>> retain the widening of the issue with the bogus setting of
>>>> d->is_shutting_down (and hence the need for later clearing the flag
>>>> again) that I mentioned elsewhere. (Yes, I remain of the opinion that
>>>> you don't need to sort that as a prereq to your work, yet at the same
>>>> time I think the goal should be to at least not make a bad situation
>>>> worse.)
>>>
>>> From the perspective of ARM logic inside Xen, we perform the exact same
>>> shutdown steps as for other domains, except that in the end we need to
>>> call Xen suspend.
>>
>> Which, as said, feels wrong. Domains to be revived after resume aren't
>> really shut down, so imo they should never have ->is_shutting_down set.
> 
> I believe this is out of scope for this series;

Yes, but see at the bottom.

> actually, the same applies to shutdown_code.

Not quite sure there.

>>> The is_shutting_down flag is easily reset on Xen resume via a
>>> domain_resume call, so I don’t see any problems with that.
>>
>> You did read my earlier mail though, regarding concerns towards the clearing
>> of that flag once it was set? (You must have, since iirc you even asked [1]
>> whether you're expected to address those issues up front.)
> 
> As far as I understand, this issue is relevant to x86, and I believe
> it is out of scope for this series.

Yes and ...

> See my previous message here:
> https://lists.xen.org/archives/html/xen-devel/2025-08/msg02127.html
> 
> I will prepare a separate patch series to address it.

... thanks. My request to not extend the badness remains though, as to the
series here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 11:49:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 11:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116404.1462732 (Exim 4.92)
	(envelope-from )
	id 1uvwqN-0000tG-Lt; Tue, 09 Sep 2025 11:49:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116404.1462732; Tue, 09 Sep 2025 11:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvwqN-0000t9-J9; Tue, 09 Sep 2025 11:49:03 +0000
Received: by outflank-mailman (input) for mailman id 1116404;
 Tue, 09 Sep 2025 11: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 1uvwqM-0000mB-2G
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 11:49:02 +0000
Received: from fhigh-b7-smtp.messagingengine.com
 (fhigh-b7-smtp.messagingengine.com [202.12.124.158])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f916dc09-8d72-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 13:49:00 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 5F7CA7A014B;
 Tue,  9 Sep 2025 07:48:58 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Tue, 09 Sep 2025 07:48:58 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 9 Sep 2025 07:48:55 -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: f916dc09-8d72-11f0-9d13-b5c5bf9af7f9
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=1757418538;
	 x=1757504938; bh=InuPwEoWWL1ylRxBhIyOeZE7bOkepMVDOxnsG3KOGIk=; b=
	U2P+WsD8y8pGBlankTzVG8r3k6mAxW4e495cTT8uvSAbOIccJuMbeUarXx2TONg5
	YeHUAeS5kTXwO9u7yXHHF/XVFlriz6x474rpbOU2SjaAnoxgdX12ZqCPp3GpMjT5
	tcRgl3JRmhOT7arKaASlAthStYYKNPc7tHHwxqs+h690ljGf1v1nfLMr8fup9tG/
	Ve3LfKg7P19souRpPJ0zyCd1I4jkLoYz4hL4HP+U5TTm0OQdCKRHe3ZllaqaptgA
	ZjWheAnWIuIa6FuJdfpEnXxypJioejcWaakqvMjwucRBUc/GpQYUJvDZutBbMbRh
	ZvvBxxyhA3Zuh9nn+SbeWA==
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=
	1757418538; x=1757504938; bh=InuPwEoWWL1ylRxBhIyOeZE7bOkepMVDOxn
	sG3KOGIk=; b=TkFjVfLKo7CYNJIIxIQGFWTZrrI/C3DMeX0+B8cEc/cu9Wo6CYW
	PYsRuE3LxIi2fbGTZhOEF8vlnuatp4KsieV/3uKvRdshQGj0bc/MaCwyHhLkj4mH
	zznvXVIufHJIp5jA7VDorrbx4y1TuF1XBH5PwuMs8K/xSlzfK6tY6EJvRTWLiR47
	dhEzyFs69uK+qDqrz0RJnyUd8gOR9ESfyJYN18++iP/wxetK4XnKJCV9B78wlX3F
	MpzmuLy2hJur8+oTTGR9gU7eez7FlXnC3JIwahnwou5HBG8tlcERq7qd7uuEwdPm
	2SGJWZAoT/m4vUHcc78ei1SlaGdZ2JMfA9Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvtdefgecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedugedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegt
    ihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvg
    hnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghruges
    vhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurd
    gtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthho
    pehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtih
    htrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdr
    ohhrghdprhgtphhtthhopehsrghnrghsthgrshhiohesrhgrphhtohhrvghnghhinhgvvg
    hrihhnghdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 9 Sep 2025 13:48:53 +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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira ,
	Samuel Thibault ,
	Juergen Gross 
Subject: Re: [PATCH for-4.21 0/5] CI: Add Debian Trixie
Message-ID: 
References: <20250809221206.1260861-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="7ByBE5CgLQp0KhHp"
Content-Disposition: inline
In-Reply-To: <20250809221206.1260861-1-andrew.cooper3@citrix.com>


--7ByBE5CgLQp0KhHp
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Sep 2025 13:48:53 +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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira ,
	Samuel Thibault ,
	Juergen Gross 
Subject: Re: [PATCH for-4.21 0/5] CI: Add Debian Trixie

On Sat, Aug 09, 2025 at 11:12:01PM +0100, Andrew Cooper wrote:
> I know it's past the last-post deadline, but Trixie was only released tod=
ay.
>=20
> In terms of backports, we should at least go back to the bugfix branches.

What is the state of this series? I'm preparing refresh of my various CI
series and some add more jobs on debian-12 - I wonder if I should make
them debian-13 already - but for this I need this series committed...

> Andrew Cooper (5):
>   CI: Trixie containers
>   CI: Update ppc64 to use Debian Trixie
>   CI: Update riscv64 to use Debian Trixie
>   stubdom: Fix -Wimplicit-int in newlib
>   CI: Update x86 to use Debian Trixie
>=20
>  automation/build/debian/13-ppc64le.dockerfile | 37 ++++++++
>  automation/build/debian/13-riscv64.dockerfile | 37 ++++++++
>  automation/build/debian/13-x86_32.dockerfile  | 51 ++++++++++
>  automation/build/debian/13-x86_64.dockerfile  | 74 +++++++++++++++
>  automation/gitlab-ci/build.yaml               | 94 +++++++++++++++----
>  automation/gitlab-ci/test.yaml                | 14 +--
>  stubdom/Makefile                              |  1 +
>  stubdom/newlib-fix-etext.patch                | 23 +++++
>  8 files changed, 306 insertions(+), 25 deletions(-)
>  create mode 100644 automation/build/debian/13-ppc64le.dockerfile
>  create mode 100644 automation/build/debian/13-riscv64.dockerfile
>  create mode 100644 automation/build/debian/13-x86_32.dockerfile
>  create mode 100644 automation/build/debian/13-x86_64.dockerfile
>  create mode 100644 stubdom/newlib-fix-etext.patch
>=20
> --=20
> 2.39.5
>=20
>=20

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjAFCUACgkQ24/THMrX
1yzTzQf9EWJQA/eQRV7sHma79ZvBdWfndwcfJvPH2ulKf8aVxxKfN8JUesjPSj/n
jJDJzNuE+SweAa1aqKAoK8ON3pnWPTzoPGjRoaaMItG8uSyTGfyshRbmQPT7gTkc
NAniEFGU47f1h4Y0EpkkkYoJ7jTwcqiPfFAo0jpqe4g1mcfmJZxc/byZNaJPkbmj
zamPyXn7hunRWG9RBbGrEMgMkFgBmfOTyAdLcEPCTazmKEVLKOp7786hFfPSD518
N2fn40l8ux+gqI4FcqnssyrM62ha56s+6QKLpOL+hPFy1MVU/jEmGVT/4m7EJMsL
tCxw17UR1oeFP/9f4Zb3CFK6urGoIQ==
=QEex
-----END PGP SIGNATURE-----

--7ByBE5CgLQp0KhHp--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 11:55:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 11:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116423.1462741 (Exim 4.92)
	(envelope-from )
	id 1uvwwM-0002Yk-Ez; Tue, 09 Sep 2025 11:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116423.1462741; Tue, 09 Sep 2025 11:55: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 1uvwwM-0002Yd-Bh; Tue, 09 Sep 2025 11:55:14 +0000
Received: by outflank-mailman (input) for mailman id 1116423;
 Tue, 09 Sep 2025 11:55: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 1uvwwK-0002YW-SE
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 11:55:12 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d3c56314-8d73-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 13:55:07 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-133-UAH-kuizO96D6f-TV0fwig-1; Tue, 09 Sep 2025 07:55:04 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-45df609b181so303175e9.2
 for ; Tue, 09 Sep 2025 04:55:04 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e75223898csm2497249f8f.39.2025.09.09.04.55.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 04: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: d3c56314-8d73-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757418906;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=wOh5IdHecYmXNJFyfTY+5ofA8ReFnlDB1RFePKgZiG8=;
	b=LsYeTzlNsM41M2M8/Bqw2Kt/2mNt7o0ao12CZrHgHc+oSijEiI+f5I1kfXmy+pI7W17faJ
	hOdajbyoSZwUDAPpSpHUABKjqjNEkJjGxz9QEA8tqA+rI4wnnpS6rRzHtskbQcCSIU5VbL
	+tIr2Cb8deyfgxsbX+3Do77uLJi6wpo=
X-MC-Unique: UAH-kuizO96D6f-TV0fwig-1
X-Mimecast-MFC-AGG-ID: UAH-kuizO96D6f-TV0fwig_1757418903
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757418903; x=1758023703;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wOh5IdHecYmXNJFyfTY+5ofA8ReFnlDB1RFePKgZiG8=;
        b=szhGpWpm7D5CvfwvpOiEX5+IISMov3HlyDbZf4OS5lFWcj/tPCEfsBNhWwbj+kyiBJ
         wF5+OFaq9CBEK468ykGvYgreKKlEJ79Oj2GHkTJhA3B9ka2UcLKOcl007iCQaB4I29OX
         JXpGHiGEpfjPixU8pTfJ/nQ7YaEFDJ8SiTOkFk2utZocv63f5rIVDIsSyf7yH9CHAa4i
         l/0QVDpy3iDUVyo+kUMkjxVyHDc5PkuTNGLn4T16woK4ffV53C1qJXqunhqKZe9TrU4a
         jsY8zFewBZtVlPd16t2R6D11u0LpSS2EWbluSrapexE34ylRvijhzqHV6Hb9A8NrDDmx
         zImQ==
X-Forwarded-Encrypted: i=1; AJvYcCUTTSaWjsAQu2H6fDi7rDmC9Uhu41hB/wXb3xlrjzfJbANigwHcMxG52aO3xVx/7jmp0EegIY67nOI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyaH825pCWj1BvEfTFS0Y3hJW0MwOTN0NBu58yNLOOWnzYsMHVq
	XbRYe8PZeEMynb4GfMbzDNooSrVXfefkZDCW6yoHX05QHrU5t0WkrYr9pzajD/2c6vVhu/YykHs
	CiRqU9fva4x6iWw7HK8yCiwK+oiQFBNjJwEhWHdI9Ks+mNagXmSWCLYhhzBFFrsN9lWdJ
X-Gm-Gg: ASbGncs1LmjmEETJfGQvh6P17OmUOOulYA96Wjwzk8pSMVMJQeRceFjFqMeZ5XpRiPK
	aXWWrw7ObVNT5zLG3juvT12+o0jqClnmssxrI8YPmvZdzGu4lvRbD4IFDdREexx2hp6Wjq50KSC
	faz4kDTEMH+vvRHlX0dHFGGTMf8UlVlo+DaIQ6a/AX9u6MEdIHRmMRy5R8cpv8HtyGsxCXwNDEz
	xXJZLITzDG3yNXANy7imXeHlvNgEWj4l9qB2FNAI08fEkcNbnGrNM1bVg0mLO0zbqsbDZtlqEFw
	JB77zoxRXLaHY23wu5bf0h8EoewH61qU/0FadM8TEItdAff+Xn39Us4UDGi5giKeJMfqIjVsuqv
	Bqyj6G5eIXLYAXUj3HpyjFJBgGWxAqSaJ+wOnzLhvE/6pWAObZMLsEir1BIXs71BJImg=
X-Received: by 2002:a5d:5f82:0:b0:3e7:42ae:d3dd with SMTP id ffacd0b85a97d-3e742aed713mr7769542f8f.53.1757418903206;
        Tue, 09 Sep 2025 04:55:03 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IF+ZfFXrc3J/ZXb10wuImf1IN/WN2zT9Bnd5gvpLTDU+4GYxL8KyTu1AXUf0+6BD7rUQ8++xA==
X-Received: by 2002:a5d:5f82:0:b0:3e7:42ae:d3dd with SMTP id ffacd0b85a97d-3e742aed713mr7769489f8f.53.1757418902733;
        Tue, 09 Sep 2025 04:55:02 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 13:54:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: Kevin Brodsky , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: H3kB-LYTLAECgs2dmjrVQHZf5vrJOzkI0FHfJToDmBE_1757418903
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09.09.25 13:45, Alexander Gordeev wrote:
> On Tue, Sep 09, 2025 at 12:09:48PM +0200, David Hildenbrand wrote:
>> On 09.09.25 11:40, Alexander Gordeev wrote:
>>> On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
>>>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>>>> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
>>>>> (taking and returning no value). This is proving problematic in
>>>>> situations where leave() needs to restore some context back to its
>>>>> original state (before enter() was called). In particular, this
>>>>> makes it difficult to support the nesting of lazy_mmu sections -
>>>>> leave() does not know whether the matching enter() call occurred
>>>>> while lazy_mmu was already enabled, and whether to disable it or
>>>>> not.
>>>>>
>>>>> This patch gives all architectures the chance to store local state
>>>>> while inside a lazy_mmu section by making enter() return some value,
>>>>> storing it in a local variable, and having leave() take that value.
>>>>> That value is typed lazy_mmu_state_t - each architecture defining
>>>>> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
>>>>> For now we define it as int everywhere, which is sufficient to
>>>>> support nesting.
>>> ...
>>>>> {
>>>>> + lazy_mmu_state_t lazy_mmu_state;
>>>>> ...
>>>>> - arch_enter_lazy_mmu_mode();
>>>>> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
>>>>> ...
>>>>> - arch_leave_lazy_mmu_mode();
>>>>> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
>>>>> ...
>>>>> }
>>>>>
>>>>> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
>>>>>      lazy_mmu is already enabled, and it temporarily disables it by
>>>>>      calling leave() and then enter() again. Here we want to ensure
>>>>>      that any operation between the leave() and enter() calls is
>>>>>      completed immediately; for that reason we pass LAZY_MMU_DEFAULT to
>>>>>      leave() to fully disable lazy_mmu. enter() will then re-enable it
>>>>>      - this achieves the expected behaviour, whether nesting occurred
>>>>>      before that function was called or not.
>>>>>
>>>>> Note: it is difficult to provide a default definition of
>>>>> lazy_mmu_state_t for architectures implementing lazy_mmu, because
>>>>> that definition would need to be available in
>>>>> arch/x86/include/asm/paravirt_types.h and adding a new generic
>>>>>     #include there is very tricky due to the existing header soup.
>>>>
>>>> Yeah, I was wondering about exactly that.
>>>>
>>>> In particular because LAZY_MMU_DEFAULT etc resides somewehere compeltely
>>>> different.
>>>>
>>>> Which raises the question: is using a new type really of any benefit here?
>>>>
>>>> Can't we just use an "enum lazy_mmu_state" and call it a day?
>>>
>>> I could envision something completely different for this type on s390,
>>> e.g. a pointer to a per-cpu structure. So I would really ask to stick
>>> with the current approach.
>>
>> Would that integrate well with LAZY_MMU_DEFAULT etc?
> 
> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
> want to use it - at least that is how I read the description above.
> 
> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
> that do not follow this pattern, and it looks as a problem to me.

Yes, that's why I am asking.

What kind of information (pointer to a per-cpu structure) would you want 
to return, and would handling it similar to how 
pagefault_disable()/pagefault_enable() e.g., using a variable in 
"current" to track the nesting level avoid having s390x to do that?

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 12:00:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 12:00:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116439.1462759 (Exim 4.92)
	(envelope-from )
	id 1uvx1Y-0004Tx-Aj; Tue, 09 Sep 2025 12:00:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116439.1462759; Tue, 09 Sep 2025 12:00: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 1uvx1Y-0004Tq-6h; Tue, 09 Sep 2025 12:00:36 +0000
Received: by outflank-mailman (input) for mailman id 1116439;
 Tue, 09 Sep 2025 12:00: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 1uvx1X-0004Tc-BT
 for xen-devel@lists.xen.org; Tue, 09 Sep 2025 12:00:35 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 93c5610d-8d74-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 14:00:30 +0200 (CEST)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvx1K-001exF-14;
 Tue, 09 Sep 2025 12:00:22 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1uvx1K-001SUg-0t;
 Tue, 09 Sep 2025 12:00: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: 93c5610d-8d74-11f0-9809-7dc792cee155
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.510 (Entity 5.510)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 472 v2 (CVE-2025-27466,CVE-2025-58142,CVE-2025-58143)
 - Mutiple vulnerabilities in the Viridian interface
Message-Id: 
Date: Tue, 09 Sep 2025 12:00:22 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 Xen Security Advisory CVE-2025-27466,CVE-2025-58142,CVE-2025-58143 / XSA-472
                                   version 2

           Mutiple vulnerabilities in the Viridian interface

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:

 1. A NULL pointer dereference in the updating of the reference TSC area.
    This is CVE-2025-27466.

 2. A NULL pointer dereference by assuming the SIM page is mapped when
    a synthetic timer message has to be delivered.  This is
    CVE-2025-58142.

 3. A race in the mapping of the reference TSC page, where a guest can
    get Xen to free a page while still present in the guest physical to
    machine (p2m) page tables.  This is CVE-2025-58143.

IMPACT
======

Denial of Service (DoS) affecting the entire host, information leaks, or
elevation of privilege.

VULNERABLE SYSTEMS
==================

Xen versions 4.13 and newer are vulnerable.  Xen versions 4.12 and older
are not vulnerable.

Only x86 HVM guests which have the reference_tsc or stimer viridian
extensions enabled are vulnerable.

MITIGATION
==========

Not enabling the reference_tsc and stimer viridian extensions will avoid
the issues.

CREDITS
=======

This issue was discovered by Roger Pau Monné of XenServer.

RESOLUTION
==========

Applying the appropriate set of attached patches resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa472-?.patch         xen-unstable - Xen 4.17.x

$ sha256sum xsa472*
16e14b3cc87800c08d96adc18e66aa4a20a77834af12b9cdd01d739882f07b7d  xsa472-1.patch
4be6a1066fbec367e8c9883240cec2a78671d484928d51ac5fb82e2c539e38ca  xsa472-2.patch
9e1972a2b5a7a817b25cad0fa80c983198bb73a2788a4d0b5cdcaca4518a57cf  xsa472-3.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches (but not mitigations) described above (or others
which are substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

This is because the mitigations are guest visible changes, and hence could
give hints to users about the upcoming vulnerabilities.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmjAFT8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZGV8H+QEb73eX4Nf/BSKpeLxzO5vpieWv9vFX83Tq9/LH
KFQKbz4Y13XjtrxEpQhnZCYBEjgByBECrCnngaqjT8P3G17fhiEp2pMgMsU783mz
TPtmdDcC63WGNyqB/7j3jxDLuCscPKKGjS+DHmcIbiV9H820EYQi83mWOGNwXRQP
pYaMz5HSO15YypxKgK4i+piVceTS/fL0dclFU/vY13bq9sCqE/E4XRsClPgk1ryS
LqUBtXbQJfxSK9asMxd0BLozVsWNVgZ6e2XTWpPf/T5EBoOo+qhQ2XaRmGCyVi98
D5t8BJ0HV83Ptik37QlosjsRbtogPXpOiaPsFmB15WFlxk8=
=/zd8
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa472-1.patch"
Content-Disposition: attachment; filename="xsa472-1.patch"
Content-Transfer-Encoding: base64

RnJvbSAyNjIxMTRhNDQwYmY3YzMyZmQ2ZDIxNWUyNDNiM2VhZWJkZDZkN2Nk
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpEYXRlOiBUaHUsIDEwIEp1bCAy
MDI1IDE1OjUxOjQwICswMjAwClN1YmplY3Q6IFtQQVRDSCAxLzNdIHg4Ni92
aXJpZGlhbjogYXZvaWQgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGluCiB1
cGRhdGVfcmVmZXJlbmNlX3RzYygpCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRl
bnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOApDb250ZW50LVRy
YW5zZmVyLUVuY29kaW5nOiA4Yml0CgpUaGUgZnVuY3Rpb24gaXMgb25seSBj
YWxsZWQgd2hlbiB0aGUgTVNSIGhhcyB0aGUgZW5hYmxlZCBiaXQgc2V0LCBi
dXQgZXZlbgp0aGVuIHRoZSBwYWdlIG1pZ2h0IG5vdCBiZSBtYXBwZWQgYmVj
YXVzZSB0aGUgZ3Vlc3QgcHJvdmlkZWQgZ2ZuIGlzIG5vdApzdWl0YWJsZS4K
ClByZXZlbnQgYSBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2UgaW4gdXBkYXRl
X3JlZmVyZW5jZV90c2MoKSBieSBjaGVja2luZwp3aGV0aGVyIHRoZSBwYWdl
IGlzIG1hcHBlZC4KClRoaXMgaXMgQ1ZFLTIwMjUtMjc0NjYgLyBwYXJ0IG9m
IFhTQS00NzIuCgpGaXhlczogMzg2YjMzNjUyMjFkICgndmlyaWRpYW46IHVz
ZSB2aXJpZGlhbl9tYXAvdW5tYXBfZ3Vlc3RfcGFnZSgpIGZvciByZWZlcmVu
Y2UgdHNjIHBhZ2UnKQpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOp
IDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVs
aWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KLS0tCiB4ZW4vYXJjaC94ODYvaHZt
L3ZpcmlkaWFuL3RpbWUuYyB8IDQgKysrKwogMSBmaWxlIGNoYW5nZWQsIDQg
aW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0v
dmlyaWRpYW4vdGltZS5jIGIveGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi90
aW1lLmMKaW5kZXggMTM3NTc3Mzg0ZjFlLi5jYTZkNTI2ZjQ2YjcgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdmlyaWRpYW4vdGltZS5jCisrKyBi
L3hlbi9hcmNoL3g4Ni9odm0vdmlyaWRpYW4vdGltZS5jCkBAIC0yNiw2ICsy
NiwxMCBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcmVmZXJlbmNlX3RzYyhjb25z
dCBzdHJ1Y3QgZG9tYWluICpkLCBib29sIGluaXRpYWxpemUpCiAgICAgSFZf
UkVGRVJFTkNFX1RTQ19QQUdFICpwID0gcnQtPnB0cjsKICAgICB1aW50MzJf
dCBzZXE7CiAKKyAgICAvKiBSZWZlcmVuY2UgVFNDIHBhZ2UgbWlnaHQgbm90
IGJlIG1hcHBlZCBldmVuIGlmIHRoZSBNU1IgaXMgZW5hYmxlZC4gKi8KKyAg
ICBpZiAoICFwICkKKyAgICAgICAgcmV0dXJuOworCiAgICAgaWYgKCBpbml0
aWFsaXplICkKICAgICAgICAgY2xlYXJfcGFnZShwKTsKIAotLSAKMi40OS4w
Cgo=

--=separator
Content-Type: application/octet-stream; name="xsa472-2.patch"
Content-Disposition: attachment; filename="xsa472-2.patch"
Content-Transfer-Encoding: base64

RnJvbSA3MWM5NTY4ZTI5MGI1MWRmZDdhYjA5MWFjOThiMjcyZmQwYWEwYjkw
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpEYXRlOiBUaHUsIDEwIEp1bCAy
MDI1IDE1OjU4OjUxICswMjAwClN1YmplY3Q6IFtQQVRDSCAyLzNdIHg4Ni92
aXJpZGlhbjogYXZvaWQgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGluCiB2
aXJpZGlhbl9zeW5pY19kZWxpdmVyX3RpbWVyX21zZygpCk1JTUUtVmVyc2lv
bjogMS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYt
OApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpUaGUgZnVuY3Rp
b24gaXMgY2FsbGVkIHVuY29uZGl0aW9uYWxseSwgcmVnYXJkbGVzcyBvZiB3
aGV0aGVyIHRoZSBTSU0gcGFnZQppcyBtYXBwZWQuICBBdm9pZCBhIE5VTEwg
cG9pbnRlciBkZXJlZmVyZW5jZSBpbgp2aXJpZGlhbl9zeW5pY19kZWxpdmVy
X3RpbWVyX21zZygpIGJ5IGNoZWNraW5nIHdoZXRoZXIgdGhlIFNJTSBwYWdl
IGlzCm1hcHBlZC4KClRoaXMgaXMgQ1ZFLTIwMjUtNTgxNDIgLyBwYXJ0IG9m
IFhTQS00NzIuCgpGaXhlczogMjZmYmEzYzg1NTcxICgndmlyaWRpYW46IGFk
ZCBpbXBsZW1lbnRhdGlvbiBvZiBzeW50aGV0aWMgdGltZXJzJykKU2lnbmVk
LW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5j
b20+Ci0tLQogeGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi9zeW5pYy5jIHwg
NCArKysrCiAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspCgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi9zeW5pYy5jIGIv
eGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi9zeW5pYy5jCmluZGV4IGMzZGM1
NzNiMDAzZC4uZTZjYmE3NTQ4ZjFiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvaHZtL3ZpcmlkaWFuL3N5bmljLmMKKysrIGIveGVuL2FyY2gveDg2L2h2
bS92aXJpZGlhbi9zeW5pYy5jCkBAIC0zMzgsNiArMzM4LDEwIEBAIGJvb2wg
dmlyaWRpYW5fc3luaWNfZGVsaXZlcl90aW1lcl9tc2coc3RydWN0IHZjcHUg
KnYsIHVuc2lnbmVkIGludCBzaW50eCwKICAgICAgICAgLkRlbGl2ZXJ5VGlt
ZSA9IGRlbGl2ZXJ5LAogICAgIH07CiAKKyAgICAvKiBEb24ndCBhc3N1bWUg
U0lNIHBhZ2UgdG8gYmUgbWFwcGVkLiAqLworICAgIGlmICggIW1zZyApCisg
ICAgICAgIHJldHVybiBmYWxzZTsKKwogICAgIC8qCiAgICAgICogVG8gYXZv
aWQgdXNpbmcgYW4gYXRvbWljIHRlc3QtYW5kLXNldCwgYW5kIGJhcnJpZXIg
YmVmb3JlIGNhbGxpbmcKICAgICAgKiB2bGFwaWNfc2V0X2lycSgpLCB0aGlz
IGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGluIGNvbnRleHQgb2YgdGhlCi0t
IAoyLjQ5LjAKCg==

--=separator
Content-Type: application/octet-stream; name="xsa472-3.patch"
Content-Disposition: attachment; filename="xsa472-3.patch"
Content-Transfer-Encoding: base64

RnJvbSBhZWQ0Y2ZkNjRkMTc4YWVlNjc3YTg3OTA0NDBhZGRkYTAzNjc4Y2Q2
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpEYXRlOiBUaHUsIDMgSnVsIDIw
MjUgMTM6MDk6MDMgKzAyMDAKU3ViamVjdDogW1BBVENIIDMvM10geDg2L3Zp
cmlkaWFuOiBwcm90ZWN0IGNvbmN1cnJlbnQgbW9kaWZpY2F0aW9uIG9mIHRo
ZQogcmVmZXJlbmNlIFRTQyBwYWdlCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRl
bnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOApDb250ZW50LVRy
YW5zZmVyLUVuY29kaW5nOiA4Yml0CgpUaGUgcmVmZXJlbmNlIFRTQyBwYWdl
IGlzIHNoYXJlZCBiZXR3ZWVuIGFsbCB2Q1BVcywgYW5kIHRoZSBkYXRhIHN0
b3JlZCBpbgp0aGUgZG9tYWluIHN0cnVjdC4gIEhvd2V2ZXIgdGhlIGhhbmRs
ZXJzIHRvIHNldCBhbmQgY2xlYXIgaXQgYXJlIG5vdCBzYWZlCmFnYWluc3Qg
Y29uY3VycmVudCBhY2Nlc3Nlcy4gIEl0J3MgcG9zc2libGUgZm9yIHR3byAo
b3IgbW9yZSkgdkNQVXMgdG8gY2FsbApIVl9YNjRfTVNSX1JFRkVSRU5DRV9U
U0MgYXQgdGhlIHNhbWUgdGltZSBhbmQgY2F1c2UgdGhlIGluLXVzZSByZWZl
cmVuY2UKVFNDIHBhZ2UgdG8gYmUgZnJlZWQsIHdoaWxlIHN0aWxsIGJlaW5n
IG9uIHRoZSBwMm0uICBUaGlzIGNyZWF0ZXMgYW4KaW5mb3JtYXRpb24gbGVh
aywgd2hlcmUgdGhlIHBhZ2UgY2FuIGVuZCB1cCBtYXBwZWQgaW4gYW5vdGhl
ciBkb21haW4gd2hpbGUKc3RpbGwgYmVpbmcgcGFydCBvZiB0aGUgb3JpZ2lu
YWwgZG9tYWluIHAybS4KCkl0J3MgYWxzbyBwb3NzaWJsZSB0byB1bmRlcmZs
b3cgdGhlIHJlZmVyZW5jZSBjb3VudGVyLCBhcyBtdWx0aXBsZQpjb25jdXJy
ZW50IHdyaXRlcyB0byBIVl9YNjRfTVNSX1JFRkVSRU5DRV9UU0MgY2FuIGNy
ZWF0ZSBhbiBpbWJhbGFuY2Ugb24KdGhlIG51bWJlciBvZiBwdXRfcGFnZV9h
bmRfdHlwZSgpIGNhbGxzLgoKSW50cm9kdWNlIGEgbG9jayB0byBwcm90ZWN0
IHRoZSByZWZlcmVuY2UgVFNDIGRvbWFpbiBmaWVsZCwgdGh1cwpzZXJpYWxp
emluZyBjb25jdXJyZW50IHZDUFUgYWNjZXNzZXMuCgpUaGlzIGlzIENWRS0y
MDI1LTU4MTQzIC8gcGFydCBvZiBYU0EtNDcyLgoKRml4ZXM6IDM4NmIzMzY1
MjIxZCAoJ3ZpcmlkaWFuOiB1c2UgdmlyaWRpYW5fbWFwL3VubWFwX2d1ZXN0
X3BhZ2UoKSBmb3IgcmVmZXJlbmNlIHRzYyBwYWdlJykKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJl
dmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0t
LQogeGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi90aW1lLmMgICAgICAgIHwg
NCArKysrCiB4ZW4vYXJjaC94ODYvaHZtL3ZpcmlkaWFuL3ZpcmlkaWFuLmMg
ICAgfCAyICsrCiB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL3Zpcmlk
aWFuLmggfCAxICsKIDMgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCsp
CgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi90aW1l
LmMgYi94ZW4vYXJjaC94ODYvaHZtL3ZpcmlkaWFuL3RpbWUuYwppbmRleCBj
YTZkNTI2ZjQ2YjcuLjkzMTE4NThkNjNjMCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2h2bS92aXJpZGlhbi90aW1lLmMKKysrIGIveGVuL2FyY2gveDg2
L2h2bS92aXJpZGlhbi90aW1lLmMKQEAgLTEwOCw4ICsxMDgsMTAgQEAgc3Rh
dGljIHZvaWQgdGltZV9yZWZfY291bnRfdGhhdyhjb25zdCBzdHJ1Y3QgZG9t
YWluICpkKQogCiAgICAgdHJjLT5vZmYgPSAoaW50NjRfdCl0cmMtPnZhbCAt
IHRyY192YWwoZCwgMCk7CiAKKyAgICBzcGluX2xvY2soJnZkLT5sb2NrKTsK
ICAgICBpZiAoIHZkLT5yZWZlcmVuY2VfdHNjLm1zci5lbmFibGVkICkKICAg
ICAgICAgdXBkYXRlX3JlZmVyZW5jZV90c2MoZCwgZmFsc2UpOworICAgIHNw
aW5fdW5sb2NrKCZ2ZC0+bG9jayk7CiB9CiAKIHN0YXRpYyB1aW50NjRfdCB0
aW1lX3JlZl9jb3VudChjb25zdCBzdHJ1Y3QgZG9tYWluICpkKQpAQCAtMzMx
LDYgKzMzMyw3IEBAIGludCB2aXJpZGlhbl90aW1lX3dybXNyKHN0cnVjdCB2
Y3B1ICp2LCB1aW50MzJfdCBpZHgsIHVpbnQ2NF90IHZhbCkKICAgICAgICAg
aWYgKCAhKHZpcmlkaWFuX2ZlYXR1cmVfbWFzayhkKSAmIEhWTVBWX3JlZmVy
ZW5jZV90c2MpICkKICAgICAgICAgICAgIHJldHVybiBYODZFTVVMX0VYQ0VQ
VElPTjsKIAorICAgICAgICBzcGluX2xvY2soJnZkLT5sb2NrKTsKICAgICAg
ICAgdmlyaWRpYW5fdW5tYXBfZ3Vlc3RfcGFnZSgmdmQtPnJlZmVyZW5jZV90
c2MpOwogICAgICAgICB2ZC0+cmVmZXJlbmNlX3RzYy5tc3IucmF3ID0gdmFs
OwogICAgICAgICB2aXJpZGlhbl9kdW1wX2d1ZXN0X3BhZ2UodiwgIlJFRkVS
RU5DRV9UU0MiLCAmdmQtPnJlZmVyZW5jZV90c2MpOwpAQCAtMzM5LDYgKzM0
Miw3IEBAIGludCB2aXJpZGlhbl90aW1lX3dybXNyKHN0cnVjdCB2Y3B1ICp2
LCB1aW50MzJfdCBpZHgsIHVpbnQ2NF90IHZhbCkKICAgICAgICAgICAgIHZp
cmlkaWFuX21hcF9ndWVzdF9wYWdlKGQsICZ2ZC0+cmVmZXJlbmNlX3RzYyk7
CiAgICAgICAgICAgICB1cGRhdGVfcmVmZXJlbmNlX3RzYyhkLCB0cnVlKTsK
ICAgICAgICAgfQorICAgICAgICBzcGluX3VubG9jaygmdmQtPmxvY2spOwog
ICAgICAgICBicmVhazsKIAogICAgIGNhc2UgSFZfWDY0X01TUl9USU1FX1JF
Rl9DT1VOVDoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vdmlyaWRp
YW4vdmlyaWRpYW4uYyBiL3hlbi9hcmNoL3g4Ni9odm0vdmlyaWRpYW4vdmly
aWRpYW4uYwppbmRleCA3ZWE2YzkwMTY4OTQuLmMwYmUyNGJkMjIxMCAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L2h2bS92aXJpZGlhbi92aXJpZGlhbi5j
CisrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdmlyaWRpYW4vdmlyaWRpYW4uYwpA
QCAtNDk0LDYgKzQ5NCw4IEBAIGludCB2aXJpZGlhbl9kb21haW5faW5pdChz
dHJ1Y3QgZG9tYWluICpkKQogICAgIGlmICggIWQtPmFyY2guaHZtLnZpcmlk
aWFuICkKICAgICAgICAgcmV0dXJuIC1FTk9NRU07CiAKKyAgICBzcGluX2xv
Y2tfaW5pdCgmZC0+YXJjaC5odm0udmlyaWRpYW4tPmxvY2spOworCiAgICAg
cmMgPSB2aXJpZGlhbl9zeW5pY19kb21haW5faW5pdChkKTsKICAgICBpZiAo
IHJjICkKICAgICAgICAgZ290byBmYWlsOwpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2h2bS92aXJpZGlhbi5oIGIveGVuL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL2h2bS92aXJpZGlhbi5oCmluZGV4IDRjOGZmNmU4
MGI2Zi4uNDdjOWQxMzg0MWFjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
aW5jbHVkZS9hc20vaHZtL3ZpcmlkaWFuLmgKKysrIGIveGVuL2FyY2gveDg2
L2luY2x1ZGUvYXNtL2h2bS92aXJpZGlhbi5oCkBAIC03MSw2ICs3MSw3IEBA
IHN0cnVjdCB2aXJpZGlhbl9kb21haW4KICAgICBERUNMQVJFX0JJVE1BUCho
eXBlcmNhbGxfZmxhZ3MsIF9IQ0FMTF9ucik7CiAgICAgc3RydWN0IHZpcmlk
aWFuX3RpbWVfcmVmX2NvdW50IHRpbWVfcmVmX2NvdW50OwogICAgIHN0cnVj
dCB2aXJpZGlhbl9wYWdlIHJlZmVyZW5jZV90c2M7CisgICAgc3BpbmxvY2tf
dCBsb2NrOwogfTsKIAogdm9pZCBjcHVpZF92aXJpZGlhbl9sZWF2ZXMoY29u
c3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IGxlYWYsCi0tIAoyLjQ5LjAK
Cg==

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 12:00:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 12:00:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116444.1462799 (Exim 4.92)
	(envelope-from )
	id 1uvx1c-0005PS-9M; Tue, 09 Sep 2025 12:00:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116444.1462799; Tue, 09 Sep 2025 12:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvx1c-0005OZ-66; Tue, 09 Sep 2025 12:00:40 +0000
Received: by outflank-mailman (input) for mailman id 1116444;
 Tue, 09 Sep 2025 12: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 1uvx1a-0004Tc-0O
 for xen-devel@lists.xen.org; Tue, 09 Sep 2025 12:00:38 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95a14277-8d74-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 14:00:32 +0200 (CEST)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvx1O-001exT-1m;
 Tue, 09 Sep 2025 12:00:26 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1uvx1O-001SVn-1d;
 Tue, 09 Sep 2025 12:00: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: 95a14277-8d74-11f0-9809-7dc792cee155
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.510 (Entity 5.510)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 473 v2 (CVE-2025-58144,CVE-2025-58145) -
 Arm issues with page refcounting
Message-Id: 
Date: Tue, 09 Sep 2025 12:00:26 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

     Xen Security Advisory CVE-2025-58144,CVE-2025-58145 / XSA-473
                               version 2

                   Arm issues with page refcounting

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

There are two issues related to the mapping of pages belonging to other
domains: For one, an assertion is wrong there, where the case actually
needs handling.  A NULL pointer de-reference could result on a release
build.  This is CVE-2025-58144.

And then the P2M lock isn't held until a page reference was actually
obtained (or the attempt to do so has failed).  Otherwise the page can
not only change type, but even ownership in between, thus allowing
domain boundaries to be violated.  This is CVE-2025-58145.

IMPACT
======

An unprivileged guest can cause a hypervisor crash, causing a Denial of
Service (DoS) of the entire host.  Privilege escalation and information
leaks cannot be ruled out.

VULNERABLE SYSTEMS
==================

Xen versions 4.12 and onwards are vulnerable.  Xen versions 4.11 and
earlier are not vulnerable.

Only Arm systems are affected.  x86 systems are not affected.

MITIGATION
==========

There is no known mitigation.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the appropriate set of attached patches resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa473-?.patch           xen-unstable - Xen 4.19.x
xsa473-4.18-?.patch      Xen 4.18.x - Xen 4.17.x

$ sha256sum xsa473*
e70f71258f1998eddafcdb5f4cb46d98e9dedc529f102b85dfb4e5310faf48eb  xsa473-1.patch
a501bde6ffb7391387cffe74e3eb9bd5c06d70bd7695aa811d42c75d3903fa59  xsa473-2.patch
e8a27f02e57d1a8d956cca9c9ed2db90c328911ff3a9434883baf633a0f3be5c  xsa473-4.18-1.patch
b2f6f4560d6082e0fb040f7352dda8963ab2dce207efce289131c10b69ebf656  xsa473-4.18-2.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmjAFU8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ/k0IAMjOW7n+dt0rgaRfwA7twgv8OLLOkuw/+DcPYuR0
tm43Y/5OtqThqmtVqOYdZNA91EQ2rIdh2hkhrCcLI1wrm6qWHvWw4ZUp5VMLyLka
u616++Uk3vlc3BrfVEVXzWgGOGYW1o7KP5njiTGcEMR/3BYC3bYBbrf7PHoDgSUR
xCmHB/tMCZ/XNkYly1oZntlQTyDjW4lnMJJMTJGXqVOviXmpGs52PRsiClk5kUuB
HU8wPkjpw2VQR43iJQWkLQykHnTGWWW/V271br1cJVDHylKaAxETBDUu44JkXTHx
voqmAG9cwm6K5Rlh6junqnfW6+UOe6Ib+FGmRXcBZ8zRAV4=
=Mloq
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa473-1.patch"
Content-Disposition: attachment; filename="xsa473-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiBBcm06IGZvcmVpZ24gcGFnZSBoYW5kbGluZyBpbiBwMm1fZ2V0X3BhZ2Vf
ZnJvbV9nZm4oKQoKSSBjYW4ndCBzZWUgd2hhdCB3b3VsZCBtYWtlIHRoZSAx
c3Qgb2YgdGhlIGFzc2VydGlvbnMgc2FmZTogRm9yIGV4YW1wbGUsCnRoZSBQ
Mk0gbG9jayBub3QgYmVpbmcgaGVsZCwgdGhlIGZvcmVpZ24gcGFnZSBtYXkg
ZGlzYXBwZWFyIGJlZm9yZSB3ZQpnZXQgdG8gY2FsbCBwYWdlX2dldF9vd25l
cl9hbmRfcmVmZXJlbmNlKCksIHdoaWNoIGhlbmNlIG1heSByZXR1cm4gTlVM
TC4KCkV2ZW4gdGhlIDJuZCwgd2hpY2ggYXBwZWFycyB0byBiZSBzYWZlIHNh
ZmUsIGlzIGxhY2tpbmcgcHJvcGVyIHJlbGVhc2UKYnVpbGQgZmFsbGJhY2tz
LgoKRHJvcCB0aGUgZm9ybWVyIGluIGZhdm9yIG9mIGFuIGlmKCksIGFuZCBj
b252ZXJ0IHRoZSBsYXR0ZXIgdG8gdGhlCmVxdWl2YWxlbnQgb2Ygd2hhdCB4
ODYgdXNlczogQVNTRVJUX1VOUkVBQ0hBQkxFKCkgcGx1cyBwdXR0aW5nIG9m
IHRoZQpvYnRhaW5lZCBwYWdlLgoKVGhpcyBpcyBDVkUtMjAyNS01ODE0NCAv
IHBhcnQgb2YgWFNBLTQ3My4KCkZpeGVzOiA5NDg2YThkMDdiYTggKCJ4ZW4v
YXJtOiBIYW5kbGUgcmVtb3ZlIGZvcmVpZ24gbWFwcGluZyIpClNpZ25lZC1v
ZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3
ZWQtYnk6IEp1bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+CgotLS0g
YS94ZW4vYXJjaC9hcm0vcDJtLmMKKysrIGIveGVuL2FyY2gvYXJtL3AybS5j
CkBAIC03NCwxMCArNzQsMTYgQEAgc3RydWN0IHBhZ2VfaW5mbyAqcDJtX2dl
dF9wYWdlX2Zyb21fZ2ZuKAogICAgICAqLwogICAgIGlmICggcDJtX2lzX2Zv
cmVpZ24ocDJtdCkgKQogICAgIHsKLSAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZmRvbSA9IHBhZ2VfZ2V0X293bmVyX2FuZF9yZWZlcmVuY2UocGFnZSk7Ci0g
ICAgICAgIEFTU0VSVChmZG9tICE9IE5VTEwpOwotICAgICAgICBBU1NFUlQo
ZmRvbSAhPSBkKTsKLSAgICAgICAgcmV0dXJuIHBhZ2U7CisgICAgICAgIGNv
bnN0IHN0cnVjdCBkb21haW4gKmZkb20gPSBwYWdlX2dldF9vd25lcl9hbmRf
cmVmZXJlbmNlKHBhZ2UpOworCisgICAgICAgIGlmICggZmRvbSApCisgICAg
ICAgIHsKKyAgICAgICAgICAgIGlmICggZmRvbSAhPSBkICkKKyAgICAgICAg
ICAgICAgICByZXR1cm4gcGFnZTsKKyAgICAgICAgICAgIEFTU0VSVF9VTlJF
QUNIQUJMRSgpOworICAgICAgICAgICAgcHV0X3BhZ2UocGFnZSk7CisgICAg
ICAgIH0KKyAgICAgICAgcmV0dXJuIE5VTEw7CiAgICAgfQogCiAgICAgcmV0
dXJuIGdldF9wYWdlKHBhZ2UsIGQpID8gcGFnZSA6IE5VTEw7Cg==

--=separator
Content-Type: application/octet-stream; name="xsa473-2.patch"
Content-Disposition: attachment; filename="xsa473-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiBBcm06IGFkanVzdCBsb2NraW5nIGluIHAybV9nZXRfcGFnZV9mcm9tX2dm
bigpCgpJbiBvcmRlciB0byBzYWZlbHkgYWNxdWlyZSBhIHJlZmVyZW5jZSBm
b3IgYSBmb3JlaWduIHBhZ2UgbWFwcGluZywgdGhlClAyTSBsb2NrIG5lZWRz
IHRvIGJlIGhlbGQgdW50aWwgd2UgaGF2ZSB0aGUgcmVmZXJlbmNlIGluIGhh
bmQgKG9yCmdldHRpbmcgb25lIGZhaWxlZCkuIE90aGVyd2lzZSB0aGUgcGFn
ZSBjYW4gY2hhbmdlIFAyTSB0eXBlIGFuZApvd25lcnNoaXAgaW4gYmV0d2Vl
bi4KClRoaXMgaXMgQ1ZFLTIwMjUtNTgxNDUgLyBwYXJ0IG9mIFhTQS00NzMu
CgpGaXhlczogOTQ4NmE4ZDA3YmE4ICgieGVuL2FybTogSGFuZGxlIHJlbW92
ZSBmb3JlaWduIG1hcHBpbmciKQpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGlj
aCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBKdWxpZW4gR3Jh
bGwgPGpncmFsbEBhbWF6b24uY29tPgoKLS0tIGEveGVuL2FyY2gvYXJtL3Ay
bS5jCisrKyBiL3hlbi9hcmNoL2FybS9wMm0uYwpAQCAtNTMsMTggKzUzLDIy
IEBAIG1mbl90IHAybV9sb29rdXAoc3RydWN0IGRvbWFpbiAqZCwgZ2ZuX3QK
IHN0cnVjdCBwYWdlX2luZm8gKnAybV9nZXRfcGFnZV9mcm9tX2dmbihzdHJ1
Y3QgZG9tYWluICpkLCBnZm5fdCBnZm4sCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcDJtX3R5cGVfdCAqdCkKIHsKKyAgICBz
dHJ1Y3QgcDJtX2RvbWFpbiAqcDJtID0gcDJtX2dldF9ob3N0cDJtKGQpOwog
ICAgIHN0cnVjdCBwYWdlX2luZm8gKnBhZ2U7CiAgICAgcDJtX3R5cGVfdCBw
Mm10OwotICAgIG1mbl90IG1mbiA9IHAybV9sb29rdXAoZCwgZ2ZuLCAmcDJt
dCk7CisgICAgbWZuX3QgbWZuOworCisgICAgcDJtX3JlYWRfbG9jayhwMm0p
OworICAgIG1mbiA9IHAybV9nZXRfZW50cnkocDJtLCBnZm4sICZwMm10LCBO
VUxMLCBOVUxMLCBOVUxMKTsKIAogICAgIGlmICggdCApCiAgICAgICAgICp0
ID0gcDJtdDsKIAotICAgIGlmICggIXAybV9pc19hbnlfcmFtKHAybXQpICkK
LSAgICAgICAgcmV0dXJuIE5VTEw7Ci0KLSAgICBpZiAoICFtZm5fdmFsaWQo
bWZuKSApCisgICAgaWYgKCAhcDJtX2lzX2FueV9yYW0ocDJtdCkgfHwgIW1m
bl92YWxpZChtZm4pICkKKyAgICB7CisgICAgICAgIHAybV9yZWFkX3VubG9j
ayhwMm0pOwogICAgICAgICByZXR1cm4gTlVMTDsKKyAgICB9CiAKICAgICBw
YWdlID0gbWZuX3RvX3BhZ2UobWZuKTsKIApAQCAtNzYsNiArODAsOCBAQCBz
dHJ1Y3QgcGFnZV9pbmZvICpwMm1fZ2V0X3BhZ2VfZnJvbV9nZm4oCiAgICAg
ewogICAgICAgICBjb25zdCBzdHJ1Y3QgZG9tYWluICpmZG9tID0gcGFnZV9n
ZXRfb3duZXJfYW5kX3JlZmVyZW5jZShwYWdlKTsKIAorICAgICAgICBwMm1f
cmVhZF91bmxvY2socDJtKTsKKwogICAgICAgICBpZiAoIGZkb20gKQogICAg
ICAgICB7CiAgICAgICAgICAgICBpZiAoIGZkb20gIT0gZCApCkBAIC04Niw2
ICs5Miw4IEBAIHN0cnVjdCBwYWdlX2luZm8gKnAybV9nZXRfcGFnZV9mcm9t
X2dmbigKICAgICAgICAgcmV0dXJuIE5VTEw7CiAgICAgfQogCisgICAgcDJt
X3JlYWRfdW5sb2NrKHAybSk7CisKICAgICByZXR1cm4gZ2V0X3BhZ2UocGFn
ZSwgZCkgPyBwYWdlIDogTlVMTDsKIH0KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa473-4.18-1.patch"
Content-Disposition: attachment; filename="xsa473-4.18-1.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiBBcm06IGZvcmVpZ24gcGFnZSBoYW5kbGluZyBpbiBwMm1fZ2V0X3BhZ2Vf
ZnJvbV9nZm4oKQoKSSBjYW4ndCBzZWUgd2hhdCB3b3VsZCBtYWtlIHRoZSAx
c3Qgb2YgdGhlIGFzc2VydGlvbnMgc2FmZTogRm9yIGV4YW1wbGUsCnRoZSBQ
Mk0gbG9jayBub3QgYmVpbmcgaGVsZCwgdGhlIGZvcmVpZ24gcGFnZSBtYXkg
ZGlzYXBwZWFyIGJlZm9yZSB3ZQpnZXQgdG8gY2FsbCBwYWdlX2dldF9vd25l
cl9hbmRfcmVmZXJlbmNlKCksIHdoaWNoIGhlbmNlIG1heSByZXR1cm4gTlVM
TC4KCkV2ZW4gdGhlIDJuZCwgd2hpY2ggYXBwZWFycyB0byBiZSBzYWZlIHNh
ZmUsIGlzIGxhY2tpbmcgcHJvcGVyIHJlbGVhc2UKYnVpbGQgZmFsbGJhY2tz
LgoKRHJvcCB0aGUgZm9ybWVyIGluIGZhdm9yIG9mIGFuIGlmKCksIGFuZCBj
b252ZXJ0IHRoZSBsYXR0ZXIgdG8gdGhlCmVxdWl2YWxlbnQgb2Ygd2hhdCB4
ODYgdXNlczogQVNTRVJUX1VOUkVBQ0hBQkxFKCkgcGx1cyBwdXR0aW5nIG9m
IHRoZQpvYnRhaW5lZCBwYWdlLgoKVGhpcyBpcyBDVkUtMjAyNS01ODE0NCAv
IHBhcnQgb2YgWFNBLTQ3My4KCkZpeGVzOiA5NDg2YThkMDdiYTggKCJ4ZW4v
YXJtOiBIYW5kbGUgcmVtb3ZlIGZvcmVpZ24gbWFwcGluZyIpClNpZ25lZC1v
ZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3
ZWQtYnk6IEp1bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+CgotLS0g
YS94ZW4vYXJjaC9hcm0vcDJtLmMKKysrIGIveGVuL2FyY2gvYXJtL3AybS5j
CkBAIC02MTIsMTAgKzYxMiwxNiBAQCBzdHJ1Y3QgcGFnZV9pbmZvICpwMm1f
Z2V0X3BhZ2VfZnJvbV9nZm4oCiAgICAgICovCiAgICAgaWYgKCBwMm1faXNf
Zm9yZWlnbihwMm10KSApCiAgICAgewotICAgICAgICBzdHJ1Y3QgZG9tYWlu
ICpmZG9tID0gcGFnZV9nZXRfb3duZXJfYW5kX3JlZmVyZW5jZShwYWdlKTsK
LSAgICAgICAgQVNTRVJUKGZkb20gIT0gTlVMTCk7Ci0gICAgICAgIEFTU0VS
VChmZG9tICE9IGQpOwotICAgICAgICByZXR1cm4gcGFnZTsKKyAgICAgICAg
Y29uc3Qgc3RydWN0IGRvbWFpbiAqZmRvbSA9IHBhZ2VfZ2V0X293bmVyX2Fu
ZF9yZWZlcmVuY2UocGFnZSk7CisKKyAgICAgICAgaWYgKCBmZG9tICkKKyAg
ICAgICAgeworICAgICAgICAgICAgaWYgKCBmZG9tICE9IGQgKQorICAgICAg
ICAgICAgICAgIHJldHVybiBwYWdlOworICAgICAgICAgICAgQVNTRVJUX1VO
UkVBQ0hBQkxFKCk7CisgICAgICAgICAgICBwdXRfcGFnZShwYWdlKTsKKyAg
ICAgICAgfQorICAgICAgICByZXR1cm4gTlVMTDsKICAgICB9CiAKICAgICBy
ZXR1cm4gZ2V0X3BhZ2UocGFnZSwgZCkgPyBwYWdlIDogTlVMTDsK

--=separator
Content-Type: application/octet-stream; name="xsa473-4.18-2.patch"
Content-Disposition: attachment; filename="xsa473-4.18-2.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiBBcm06IGFkanVzdCBsb2NraW5nIGluIHAybV9nZXRfcGFnZV9mcm9tX2dm
bigpCgpJbiBvcmRlciB0byBzYWZlbHkgYWNxdWlyZSBhIHJlZmVyZW5jZSBm
b3IgYSBmb3JlaWduIHBhZ2UgbWFwcGluZywgdGhlClAyTSBsb2NrIG5lZWRz
IHRvIGJlIGhlbGQgdW50aWwgd2UgaGF2ZSB0aGUgcmVmZXJlbmNlIGluIGhh
bmQgKG9yCmdldHRpbmcgb25lIGZhaWxlZCkuIE90aGVyd2lzZSB0aGUgcGFn
ZSBjYW4gY2hhbmdlIFAyTSB0eXBlIGFuZApvd25lcnNoaXAgaW4gYmV0d2Vl
bi4KClRoaXMgaXMgQ1ZFLTIwMjUtNTgxNDUgLyBwYXJ0IG9mIFhTQS00NzMu
CgpGaXhlczogOTQ4NmE4ZDA3YmE4ICgieGVuL2FybTogSGFuZGxlIHJlbW92
ZSBmb3JlaWduIG1hcHBpbmciKQpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGlj
aCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBKdWxpZW4gR3Jh
bGwgPGpncmFsbEBhbWF6b24uY29tPgoKLS0tIGEveGVuL2FyY2gvYXJtL3Ay
bS5jCisrKyBiL3hlbi9hcmNoL2FybS9wMm0uYwpAQCAtNTkxLDE4ICs1OTEs
MjIgQEAgbWZuX3QgcDJtX2xvb2t1cChzdHJ1Y3QgZG9tYWluICpkLCBnZm5f
dAogc3RydWN0IHBhZ2VfaW5mbyAqcDJtX2dldF9wYWdlX2Zyb21fZ2ZuKHN0
cnVjdCBkb21haW4gKmQsIGdmbl90IGdmbiwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90ICp0KQogeworICAg
IHN0cnVjdCBwMm1fZG9tYWluICpwMm0gPSBwMm1fZ2V0X2hvc3RwMm0oZCk7
CiAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZTsKICAgICBwMm1fdHlwZV90
IHAybXQ7Ci0gICAgbWZuX3QgbWZuID0gcDJtX2xvb2t1cChkLCBnZm4sICZw
Mm10KTsKKyAgICBtZm5fdCBtZm47CisKKyAgICBwMm1fcmVhZF9sb2NrKHAy
bSk7CisgICAgbWZuID0gcDJtX2dldF9lbnRyeShwMm0sIGdmbiwgJnAybXQs
IE5VTEwsIE5VTEwsIE5VTEwpOwogCiAgICAgaWYgKCB0ICkKICAgICAgICAg
KnQgPSBwMm10OwogCi0gICAgaWYgKCAhcDJtX2lzX2FueV9yYW0ocDJtdCkg
KQotICAgICAgICByZXR1cm4gTlVMTDsKLQotICAgIGlmICggIW1mbl92YWxp
ZChtZm4pICkKKyAgICBpZiAoICFwMm1faXNfYW55X3JhbShwMm10KSB8fCAh
bWZuX3ZhbGlkKG1mbikgKQorICAgIHsKKyAgICAgICAgcDJtX3JlYWRfdW5s
b2NrKHAybSk7CiAgICAgICAgIHJldHVybiBOVUxMOworICAgIH0KIAogICAg
IHBhZ2UgPSBtZm5fdG9fcGFnZShtZm4pOwogCkBAIC02MTQsNiArNjE4LDgg
QEAgc3RydWN0IHBhZ2VfaW5mbyAqcDJtX2dldF9wYWdlX2Zyb21fZ2ZuKAog
ICAgIHsKICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZmRvbSA9IHBh
Z2VfZ2V0X293bmVyX2FuZF9yZWZlcmVuY2UocGFnZSk7CiAKKyAgICAgICAg
cDJtX3JlYWRfdW5sb2NrKHAybSk7CisKICAgICAgICAgaWYgKCBmZG9tICkK
ICAgICAgICAgewogICAgICAgICAgICAgaWYgKCBmZG9tICE9IGQgKQpAQCAt
NjI0LDYgKzYzMCw4IEBAIHN0cnVjdCBwYWdlX2luZm8gKnAybV9nZXRfcGFn
ZV9mcm9tX2dmbigKICAgICAgICAgcmV0dXJuIE5VTEw7CiAgICAgfQogCisg
ICAgcDJtX3JlYWRfdW5sb2NrKHAybSk7CisKICAgICByZXR1cm4gZ2V0X3Bh
Z2UocGFnZSwgZCkgPyBwYWdlIDogTlVMTDsKIH0KIAo=

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 12:00:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 12:00:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116448.1462845 (Exim 4.92)
	(envelope-from )
	id 1uvx1f-0006Ij-KH; Tue, 09 Sep 2025 12:00:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116448.1462845; Tue, 09 Sep 2025 12:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvx1f-0006Hl-9h; Tue, 09 Sep 2025 12:00:43 +0000
Received: by outflank-mailman (input) for mailman id 1116448;
 Tue, 09 Sep 2025 12:00:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvx1b-0004cM-Le
 for xen-devel@lists.xen.org; Tue, 09 Sep 2025 12:00:40 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 983f6b74-8d74-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 14:00:37 +0200 (CEST)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uvx1S-001exn-29;
 Tue, 09 Sep 2025 12:00:30 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1uvx1S-001SWl-1q;
 Tue, 09 Sep 2025 12:00: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: 983f6b74-8d74-11f0-9d13-b5c5bf9af7f9
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.510 (Entity 5.510)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 474 v2 (CVE-2025-58146) - XAPI UTF-8 string
 handling
Message-Id: 
Date: Tue, 09 Sep 2025 12:00:30 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2025-58146 / XSA-474
                               version 2

                      XAPI UTF-8 string handling

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

There are multiple issues.

 1. Updates to the XAPI database sanitise input strings, but try
    generating the notification using the unsanitised input.  This
    causes the database's event thread to terminate and cease further
    processing.

 2. XAPI's UTF-8 encoder implements v3.0 of the Unicode spec, but XAPI
    uses libraries which conform to the stricter v3.1 of the Unicode
    spec.  This causes some strings to be accepted as valid UTF-8 by
    XAPI, but rejected by other libraries in use.  Notably, such strings
    can be entered into the database, after which the database can no
    longer be loaded.

 3. There is no input sanitisation for Map/Set updates on objects in the
    XAPI database.

IMPACT
======

Buggy or malicious inputs to XAPI can cause a Denial of Service.

VULNERABLE SYSTEMS
==================

All versions of XAPI are believed to be vulnerable.

Issues 1 and 2 can be leveraged by guest administrator.

Issue 3 can only be leveraged by an authenticated API user.

MITIGATION
==========

There are no mitigations.

CREDITS
=======

This issue was discovered by Edwin Török from XenServer.

RESOLUTION
==========

An updated XAPI, built with the attached patch, needs to be deployed to
resolve the issue.  If XAPI restarts correctly, no further action is
necessary.

If bad strings have been entered into the database, XAPI will get into a
restart loop, citing:

  [error||0 ||backtrace] Xapi.watchdog failed with exception Xmlm.Error(999:42777, "malformed character stream")

in /var/log/xensource.log roughly every 4 seconds.

To resolve this, the bad characters need stripping manually from the
database.  In dom0, something along the lines of:

  cd /var/xapi
  service xapi stop
  cp state.db state.bak
  iconv -f UTF-8 -t UTF-8//IGNORE < state.db > state.$$
  mv state.$$ state.db
  service xapi start

xsa474.patch           XAPI master

$ sha256sum xsa474*
e3c7ce7522252b25710062f1c761b5f1e319dab2129fc7c1d9fd6440f9331a9f  xsa474.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmjAFVEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZCBUIAKiQgLyn/B876QeNwBbHk30wylE9ep1okFBuGhBa
zhpwNJrJeqnzEfw3ma3v+gDiy/qNp6AKhg8U1GGmF9WyJ4I3c3oA/ATfkN5Kms/W
NQnisqExSgo/d8SK0udyk7BCtI0Z+jYxdmnLcPyJgCHOJflZ2CCIpsz6VVvQqq0Y
bSgylgrhhQa8+yQ9xWOQHeEzle89JR4JLTRCUzg4AyTUuxaiHGP8zRj9uwgdwkJZ
nou+4dQxzE3YhzPjz15j+l9JY8zVUsyzMjsXC0W1EnXuzYGJxuiy8oqaMaqlx7+e
hO6fU1iy9ZkIgXPqhAMLlexLkR47Bgw1HLFh4f2XdyqSnBw=
=Zist
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa474.patch"
Content-Disposition: attachment; filename="xsa474.patch"
Content-Transfer-Encoding: base64

RnJvbTogQ2hyaXN0aWFuIExpbmRpZyA8Y2hyaXN0aWFuLmxpbmRpZ0BjbG91
ZC5jb20+ClN1YmplY3Q6IFNpbXBsaWZ5IFVURi04IGRlY29kaW5nCgoqIFVz
ZSB0aGUgZGVjb2RlciBmcm9tIHRoZSBPQ2FtbCBzdGFuZGFyZCBsaWJyYXJ5
IGluc3RlYWQgb2YKICBvdXIgb3duIGltcGxlbWVudGF0aW9uLCB3aGljaCB0
aGlzIHBhdGNoIHJlbW92ZXMuCiogVmFsaWRhdGUgVVRGLTgvWE1MIGNvbmZv
cm1hbmNlIGZvciBtYXBzIGFuZCBzZXRzLCBpbiBhZGRpdGlvbiB0bwogIHN0
cmluZ3MuCgpUaGlzIGlzIFhTQS00NzQgLyBDVkUtMjAyNS01ODE0Ni4KClNp
Z25lZC1vZmYtYnk6IENocmlzdGlhbiBMaW5kaWcgPGNocmlzdGlhbi5saW5k
aWdAY2xvdWQuY29tPgpSZXZpZXdlZC1ieTogRWR3aW4gVMO2csO2ayA8ZWR3
aW4udG9yb2tAY2xvdWQuY29tPgoKZGlmZiAtLWdpdCBhL29jYW1sL2RhdGFi
YXNlL2RiX2NhY2hlX2ltcGwubWwgYi9vY2FtbC9kYXRhYmFzZS9kYl9jYWNo
ZV9pbXBsLm1sCmluZGV4IGU5NzQ1NzQ5YS4uMDUwZDQzZjA1IDEwMDY0NAot
LS0gYS9vY2FtbC9kYXRhYmFzZS9kYl9jYWNoZV9pbXBsLm1sCisrKyBiL29j
YW1sL2RhdGFiYXNlL2RiX2NhY2hlX2ltcGwubWwKQEAgLTY3LDkgKzY3LDcg
QEAgbGV0IHJlYWRfZmllbGQgdCB0YmxuYW1lIGZsZG5hbWUgb2JqcmVmID0K
ICAgICBvY2N1cnMuICopCiBsZXQgZW5zdXJlX3V0ZjhfeG1sIHN0cmluZyA9
CiAgIGxldCBsZW5ndGggPSBTdHJpbmcubGVuZ3RoIHN0cmluZyBpbgotICBs
ZXQgcHJlZml4ID0KLSAgICBYYXBpX3N0ZGV4dF9lbmNvZGluZ3MuRW5jb2Rp
bmdzLlVURjhfWE1MLmxvbmdlc3RfdmFsaWRfcHJlZml4IHN0cmluZwotICBp
bgorICBsZXQgcHJlZml4ID0gWGFwaV9zdGRleHRfZW5jb2RpbmdzLlV0Zjgu
WE1MLmxvbmdlc3RfdmFsaWRfcHJlZml4IHN0cmluZyBpbgogICBpZiBsZW5n
dGggPiBTdHJpbmcubGVuZ3RoIHByZWZpeCB0aGVuCiAgICAgd2FybiAic3Ry
aW5nIHRydW5jYXRlZCB0bzogJyVzJy4iIHByZWZpeCA7CiAgIHByZWZpeApA
QCAtODYsMjAgKzg0LDMyIEBAIGxldCB3cml0ZV9maWVsZF9sb2NrZWQgdCB0
YmxuYW1lIG9ianJlZiBmbGRuYW1lIG5ld3ZhbCA9CiAgICAgICAoZ2V0X2Rh
dGFiYXNlIHQpCiAgICkKIAorKCoqIEVuc3VyZSBhIHZhbHVlIGlzIGNvbmZv
cm1pbmcgdG8gVVRGLTggd2l0aCBYTUwgcmVzdHJpY3Rpb25zICopCitsZXQg
aXNfdmFsaWQgdiA9CisgIGxldCB2YWxpZCA9IFhhcGlfc3RkZXh0X2VuY29k
aW5ncy5VdGY4LlhNTC5pc192YWxpZCBpbgorICBsZXQgdmFsaWRfcGFpciAo
eCwgeSkgPSB2YWxpZCB4ICYmIHZhbGlkIHkgaW4KKyAgbWF0Y2ggdiB3aXRo
CisgIHwgU2NoZW1hLlZhbHVlLlN0cmluZyBzIC0+CisgICAgICB2YWxpZCBz
CisgIHwgU2NoZW1hLlZhbHVlLlNldCBzcyAtPgorICAgICAgTGlzdC5mb3Jf
YWxsIHZhbGlkIHNzCisgIHwgU2NoZW1hLlZhbHVlLlBhaXJzIHBhaXJzIC0+
CisgICAgICBMaXN0LmZvcl9hbGwgdmFsaWRfcGFpciBwYWlycworCitsZXQg
c2hhcmVfc3RyaW5nID0gZnVuY3Rpb24KKyAgfCBTY2hlbWEuVmFsdWUuU3Ry
aW5nIHMgLT4KKyAgICAgIFNjaGVtYS5WYWx1ZS5TdHJpbmcgKFNoYXJlLm1l
cmdlIHMpCisgIHwgdiAtPgorICAgICAgKCogd2UgYXNzdW1lIHN0cmluZ3Mg
aW4gdGhlIHRyZWUgaGF2ZSBiZWVuIHNoYXJlZCBhbHJlYWR5ICopCisgICAg
ICB2CisKIGxldCB3cml0ZV9maWVsZCB0IHRibG5hbWUgb2JqcmVmIGZsZG5h
bWUgbmV3dmFsID0KLSAgbGV0IG5ld3ZhbCA9Ci0gICAgbWF0Y2ggbmV3dmFs
IHdpdGgKLSAgICB8IFNjaGVtYS5WYWx1ZS5TdHJpbmcgcyAtPgotICAgICAg
ICAoKiB0aGUgb3RoZXIgY2FsbGVyIG9mIHdyaXRlX2ZpZWxkX2xvY2tlZCBv
bmx5IHVzZXMgc2V0cyBhbmQgbWFwcywKLSAgICAgICAgICAgc28gd2Ugb25s
eSBuZWVkIHRvIGNoZWNrIGZvciBTdHJpbmcgaGVyZQotICAgICAgICAqKQot
ICAgICAgICBpZiBub3QgKFhhcGlfc3RkZXh0X2VuY29kaW5ncy5FbmNvZGlu
Z3MuVVRGOF9YTUwuaXNfdmFsaWQgcykgdGhlbgotICAgICAgICAgIHJhaXNl
IEludmFsaWRfdmFsdWUgOwotICAgICAgICBTY2hlbWEuVmFsdWUuU3RyaW5n
IChTaGFyZS5tZXJnZSBzKQotICAgIHwgXyAtPgotICAgICAgICBuZXd2YWwK
LSAgaW4KLSAgd2l0aF9sb2NrIChmdW4gKCkgLT4gd3JpdGVfZmllbGRfbG9j
a2VkIHQgdGJsbmFtZSBvYmpyZWYgZmxkbmFtZSBuZXd2YWwpCisgIGlmIG5v
dCBAQCBpc192YWxpZCBuZXd2YWwgdGhlbgorICAgIHJhaXNlIEludmFsaWRf
dmFsdWUKKyAgZWxzZQorICAgIHdpdGhfbG9jayAoZnVuICgpIC0+CisgICAg
ICAgIHdyaXRlX2ZpZWxkX2xvY2tlZCB0IHRibG5hbWUgb2JqcmVmIGZsZG5h
bWUgKHNoYXJlX3N0cmluZyBuZXd2YWwpCisgICAgKQogCiBsZXQgdG91Y2hf
cm93IHQgdGJsbmFtZSBvYmpyZWYgPQogICB1cGRhdGVfZGF0YWJhc2UgdCAo
dG91Y2ggdGJsbmFtZSBvYmpyZWYpIDsKZGlmZiAtLWdpdCBhL29jYW1sL2Rh
dGFiYXNlL3N0cmluZ19tYXJzaGFsbF9oZWxwZXIubWwgYi9vY2FtbC9kYXRh
YmFzZS9zdHJpbmdfbWFyc2hhbGxfaGVscGVyLm1sCmluZGV4IGJhMDAzYmVl
OS4uMWFkZDNhZWY3IDEwMDY0NAotLS0gYS9vY2FtbC9kYXRhYmFzZS9zdHJp
bmdfbWFyc2hhbGxfaGVscGVyLm1sCisrKyBiL29jYW1sL2RhdGFiYXNlL3N0
cmluZ19tYXJzaGFsbF9oZWxwZXIubWwKQEAgLTIyLDkgKzIyLDcgQEAgbW9k
dWxlIEQgPSBEZWJ1Zy5NYWtlIChzdHJ1Y3QgbGV0IG5hbWUgPSBfX01PRFVM
RV9fIGVuZCkKIAogbGV0IGVuc3VyZV91dGY4X3htbCBzdHJpbmcgPQogICBs
ZXQgbGVuZ3RoID0gU3RyaW5nLmxlbmd0aCBzdHJpbmcgaW4KLSAgbGV0IHBy
ZWZpeCA9Ci0gICAgWGFwaV9zdGRleHRfZW5jb2RpbmdzLkVuY29kaW5ncy5V
VEY4X1hNTC5sb25nZXN0X3ZhbGlkX3ByZWZpeCBzdHJpbmcKLSAgaW4KKyAg
bGV0IHByZWZpeCA9IFhhcGlfc3RkZXh0X2VuY29kaW5ncy5VdGY4LlhNTC5s
b25nZXN0X3ZhbGlkX3ByZWZpeCBzdHJpbmcgaW4KICAgaWYgbGVuZ3RoID4g
U3RyaW5nLmxlbmd0aCBwcmVmaXggdGhlbgogICAgIEQud2FybiAiV2hpbHN0
IGRvaW5nICdzZXQnIG9mIHN0cnVjdHVyZWQgZmllbGQsIHN0cmluZyB0cnVu
Y2F0ZWQgdG86ICclcycuIgogICAgICAgcHJlZml4IDsKZGlmZiAtLWdpdCBh
L29jYW1sL2lkbC9vY2FtbF9iYWNrZW5kL2dlbl9zZXJ2ZXIubWwgYi9vY2Ft
bC9pZGwvb2NhbWxfYmFja2VuZC9nZW5fc2VydmVyLm1sCmluZGV4IDE5MTQ1
MDIxMi4uZjk1ZjVmNmQ5IDEwMDY0NAotLS0gYS9vY2FtbC9pZGwvb2NhbWxf
YmFja2VuZC9nZW5fc2VydmVyLm1sCisrKyBiL29jYW1sL2lkbC9vY2FtbF9i
YWNrZW5kL2dlbl9zZXJ2ZXIubWwKQEAgLTQ1Nyw3ICs0NTcsNyBAQCBsZXQg
Z2VuX21vZHVsZSBhcGkgOiBPLk1vZHVsZS50ID0KICAgICAgICAgICAgICAg
IChbCiAgICAgICAgICAgICAgICAgICAibGV0IF9fY2FsbCwgX19wYXJhbXMg
PSBjYWxsLlJwYy5uYW1lLCBjYWxsLlJwYy5wYXJhbXMgaW4iCiAgICAgICAg
ICAgICAgICAgOyAiTGlzdC5pdGVyIChmdW4gcCAtPiBsZXQgcyA9IFJwYy50
b19zdHJpbmcgcCBpbiBpZiBub3QgXAotICAgICAgICAgICAgICAgICAgIChY
YXBpX3N0ZGV4dF9lbmNvZGluZ3MuRW5jb2RpbmdzLlVURjhfWE1MLmlzX3Zh
bGlkIHMpIHRoZW4iCisgICAgICAgICAgICAgICAgICAgKFhhcGlfc3RkZXh0
X2VuY29kaW5ncy5VdGY4LmlzX3ZhbGlkIHMpIHRoZW4iCiAgICAgICAgICAg
ICAgICAgOyAicmFpc2UgKEFwaV9lcnJvcnMuU2VydmVyX2Vycm9yKEFwaV9l
cnJvcnMuaW52YWxpZF92YWx1ZSwgXAogICAgICAgICAgICAgICAgICAgIFtc
IkludmFsaWQgVVRGLTggc3RyaW5nIGluIHBhcmFtZXRlclwiOyBzXSkpKSAg
X19wYXJhbXM7IgogICAgICAgICAgICAgICAgIDsgImxldCBfX2xhYmVsID0g
X19jYWxsIGluIgpkaWZmIC0tZ2l0IGEvb2NhbWwvbGlicy94YXBpLXN0ZGV4
dC9saWIveGFwaS1zdGRleHQtZW5jb2RpbmdzL2JlbmNoL2JlbmNoX2VuY29k
aW5ncy5tbCBiL29jYW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3Rk
ZXh0LWVuY29kaW5ncy9iZW5jaC9iZW5jaF9lbmNvZGluZ3MubWwKaW5kZXgg
NzMwOGM3NTZkLi5iYjIwZWVkNGYgMTAwNjQ0Ci0tLSBhL29jYW1sL2xpYnMv
eGFwaS1zdGRleHQvbGliL3hhcGktc3RkZXh0LWVuY29kaW5ncy9iZW5jaC9i
ZW5jaF9lbmNvZGluZ3MubWwKKysrIGIvb2NhbWwvbGlicy94YXBpLXN0ZGV4
dC9saWIveGFwaS1zdGRleHQtZW5jb2RpbmdzL2JlbmNoL2JlbmNoX2VuY29k
aW5ncy5tbApAQCAtMSw1ICsxLDUgQEAKIG9wZW4gQmVjaGFtZWwKLW9wZW4g
WGFwaV9zdGRleHRfZW5jb2RpbmdzLkVuY29kaW5ncworb3BlbiBYYXBpX3N0
ZGV4dF9lbmNvZGluZ3MKIAogbGV0IHRlc3QgbmFtZSBmID0KICAgVGVzdC5t
YWtlX2luZGV4ZWRfd2l0aF9yZXNvdXJjZSB+bmFtZSB+YXJnczpbMTA7IDEw
MDA7IDEwMDAwXQpAQCAtMTAsNiArMTAsNiBAQCBsZXQgdGVzdCBuYW1lIGYg
PQogCiBsZXQgYmVuY2htYXJrcyA9CiAgIFRlc3QubWFrZV9ncm91cGVkIH5u
YW1lOiJFbmNvZGluZ3MudmFsaWRhdGUiCi0gICAgW3Rlc3QgIlVURjhfWE1M
IiBVVEY4X1hNTC52YWxpZGF0ZV0KKyAgICBbdGVzdCAiVVRGOC5YTUwiIFV0
ZjguWE1MLmlzX3ZhbGlkXQogCiBsZXQgKCkgPSBCZWNoYW1lbF9zaW1wbGVf
Y2xpLmNsaSBiZW5jaG1hcmtzCmRpZmYgLS1naXQgYS9vY2FtbC9saWJzL3hh
cGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3MvZHVuZSBiL29j
YW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3RkZXh0LWVuY29kaW5n
cy9kdW5lCmluZGV4IDc0MmRkMjEyZi4uODM5MzQ2ZTM1IDEwMDY0NAotLS0g
YS9vY2FtbC9saWJzL3hhcGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1lbmNv
ZGluZ3MvZHVuZQorKysgYi9vY2FtbC9saWJzL3hhcGktc3RkZXh0L2xpYi94
YXBpLXN0ZGV4dC1lbmNvZGluZ3MvZHVuZQpAQCAtMSwxMiArMSw2IEBACiAo
bGlicmFyeQogICAobmFtZSB4YXBpX3N0ZGV4dF9lbmNvZGluZ3MpCiAgIChw
dWJsaWNfbmFtZSB4YXBpLXN0ZGV4dC1lbmNvZGluZ3MpCi0gIChtb2R1bGVz
IDpzdGFuZGFyZCBcIHRlc3QpCisgIChtb2R1bGVzIDpzdGFuZGFyZCkKICkK
IAotKHRlc3QKLSAgKG5hbWUgdGVzdCkKLSAgKHBhY2thZ2UgeGFwaS1zdGRl
eHQtZW5jb2RpbmdzKQotICAobW9kdWxlcyB0ZXN0KQotICAobGlicmFyaWVz
IGFsY290ZXN0IHhhcGktc3RkZXh0LWVuY29kaW5ncykKLSkKZGlmZiAtLWdp
dCBhL29jYW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3RkZXh0LWVu
Y29kaW5ncy9lbmNvZGluZ3MubWwgYi9vY2FtbC9saWJzL3hhcGktc3RkZXh0
L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3MvZW5jb2RpbmdzLm1sCmRlbGV0
ZWQgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAyZGZkNDVhN2QuLjAwMDAwMDAw
MAotLS0gYS9vY2FtbC9saWJzL3hhcGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4
dC1lbmNvZGluZ3MvZW5jb2RpbmdzLm1sCisrKyAvZGV2L251bGwKQEAgLTEs
MTY3ICswLDAgQEAKLSgqCi0gKiBDb3B5cmlnaHQgKEMpIDIwMDYtMjAwOSBD
aXRyaXggU3lzdGVtcyBJbmMuCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZy
ZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBt
b2RpZnkKLSAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3Nl
ciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAotICogYnkg
dGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25s
eS4gd2l0aCB0aGUgc3BlY2lhbAotICogZXhjZXB0aW9uIG9uIGxpbmtpbmcg
ZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KLSAqCi0gKiBUaGlzIHByb2dy
YW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJl
IHVzZWZ1bCwKLSAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91
dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCi0gKiBNRVJDSEFOVEFC
SUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlCi0gKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug
Zm9yIG1vcmUgZGV0YWlscy4KLSAqKQotZXhjZXB0aW9uIFVDU192YWx1ZV9v
dXRfb2ZfcmFuZ2UKLQotZXhjZXB0aW9uIFVDU192YWx1ZV9wcm9oaWJpdGVk
X2luX1VURjgKLQotZXhjZXB0aW9uIFVDU192YWx1ZV9wcm9oaWJpdGVkX2lu
X1hNTAotCi1leGNlcHRpb24gVVRGOF9jaGFyYWN0ZXJfaW5jb21wbGV0ZQot
Ci1leGNlcHRpb24gVVRGOF9oZWFkZXJfYnl0ZV9pbnZhbGlkCi0KLWV4Y2Vw
dGlvbiBVVEY4X2NvbnRpbnVhdGlvbl9ieXRlX2ludmFsaWQKLQotZXhjZXB0
aW9uIFVURjhfZW5jb2Rpbmdfbm90X2Nhbm9uaWNhbAotCi1leGNlcHRpb24g
U3RyaW5nX2luY29tcGxldGUKLQotKCogPT09IFVuaWNvZGUgRnVuY3Rpb25z
ID09PSAqKQotCi1tb2R1bGUgVUNTID0gc3RydWN0Ci0gIGxldCBpc19ub25f
Y2hhcmFjdGVyIHZhbHVlID0KLSAgICBmYWxzZQotICAgIHx8ICgweGZkZDAg
PD0gdmFsdWUgJiYgdmFsdWUgPD0gMHhmZGVmKSAoKiBjYXNlIDEgKikKLSAg
ICB8fCBJbnQubG9nYW5kIDB4ZmZmZSB2YWx1ZSA9IDB4ZmZmZQotICAoKiBj
YXNlIDIgKikKLSAgW0BAaW5saW5lXQotZW5kCi0KLW1vZHVsZSBYTUwgPSBz
dHJ1Y3QKLSAgbGV0IGlzX2lsbGVnYWxfY29udHJvbF9jaGFyYWN0ZXIgdmFs
dWUgPQotICAgIGxldCB2YWx1ZSA9IFVjaGFyLnRvX2ludCB2YWx1ZSBpbgot
ICAgIHZhbHVlIDwgMHgyMCAmJiB2YWx1ZSA8PiAweDA5ICYmIHZhbHVlIDw+
IDB4MGEgJiYgdmFsdWUgPD4gMHgwZAotICBbQEBpbmxpbmVdCi1lbmQKLQot
KCogPT09IFVDUyBWYWxpZGF0b3JzID09PSAqKQotCi1tb2R1bGUgdHlwZSBV
Q1NfVkFMSURBVE9SID0gc2lnCi0gIHZhbCB2YWxpZGF0ZSA6IFVjaGFyLnQg
LT4gdW5pdAotZW5kCi0KLW1vZHVsZSBVVEY4X1VDU192YWxpZGF0b3IgPSBz
dHJ1Y3QKLSAgbGV0IHZhbGlkYXRlIHZhbHVlID0KLSAgICBpZiAoVUNTLmlz
X25vbl9jaGFyYWN0ZXIgW0BpbmxpbmVkXSkgKFVjaGFyLnRvX2ludCB2YWx1
ZSkgdGhlbgotICAgICAgcmFpc2UgVUNTX3ZhbHVlX3Byb2hpYml0ZWRfaW5f
VVRGOAotICBbQEBpbmxpbmVdCi1lbmQKLQotbW9kdWxlIFhNTF9VVEY4X1VD
U192YWxpZGF0b3IgPSBzdHJ1Y3QKLSAgbGV0IHZhbGlkYXRlIHZhbHVlID0K
LSAgICAoVVRGOF9VQ1NfdmFsaWRhdG9yLnZhbGlkYXRlIFtAaW5saW5lZF0p
IHZhbHVlIDsKLSAgICBpZiAoWE1MLmlzX2lsbGVnYWxfY29udHJvbF9jaGFy
YWN0ZXIgW0BpbmxpbmVkXSkgdmFsdWUgdGhlbgotICAgICAgcmFpc2UgVUNT
X3ZhbHVlX3Byb2hpYml0ZWRfaW5fWE1MCi1lbmQKLQotKCogPT09IFN0cmlu
ZyBWYWxpZGF0b3JzID09PSAqKQotCi1tb2R1bGUgdHlwZSBTVFJJTkdfVkFM
SURBVE9SID0gc2lnCi0gIHZhbCBpc192YWxpZCA6IHN0cmluZyAtPiBib29s
Ci0KLSAgdmFsIHZhbGlkYXRlIDogc3RyaW5nIC0+IHVuaXQKLQotICB2YWwg
bG9uZ2VzdF92YWxpZF9wcmVmaXggOiBzdHJpbmcgLT4gc3RyaW5nCi1lbmQK
LQotZXhjZXB0aW9uIFZhbGlkYXRpb25fZXJyb3Igb2YgaW50ICogZXhuCi0K
LW1vZHVsZSBVVEY4X1hNTCA6IFNUUklOR19WQUxJREFUT1IgPSBzdHJ1Y3QK
LSAgbGV0IGRlY29kZV9jb250aW51YXRpb25fYnl0ZSBieXRlID0KLSAgICBp
ZiBieXRlIGxhbmQgMGIxMTAwMDAwMCA9IDBiMTAwMDAwMDAgdGhlbgotICAg
ICAgYnl0ZSBsYW5kIDBiMDAxMTExMTEKLSAgICBlbHNlCi0gICAgICByYWlz
ZSBVVEY4X2NvbnRpbnVhdGlvbl9ieXRlX2ludmFsaWQKLQotICBsZXQgcmVj
IGRlY29kZV9jb250aW51YXRpb25fYnl0ZXMgc3RyaW5nIGxhc3QgdmFsdWUg
aW5kZXggPQotICAgIGlmIGluZGV4IDw9IGxhc3QgdGhlbgotICAgICAgbGV0
IGNodW5rID0gZGVjb2RlX2NvbnRpbnVhdGlvbl9ieXRlIChDaGFyLmNvZGUg
c3RyaW5nLltpbmRleF0pIGluCi0gICAgICBsZXQgdmFsdWUgPSAodmFsdWUg
bHNsIDYpIGxvciBjaHVuayBpbgotICAgICAgZGVjb2RlX2NvbnRpbnVhdGlv
bl9ieXRlcyBzdHJpbmcgbGFzdCB2YWx1ZSAoaW5kZXggKyAxKQotICAgIGVs
c2UKLSAgICAgIHZhbHVlCi0KLSAgbGV0IHZhbGlkYXRlX2NoYXJhY3Rlcl91
dGY4IHN0cmluZyBieXRlIGluZGV4ID0KLSAgICBsZXQgdmFsdWUsIHdpZHRo
ID0KLSAgICAgIGlmIGJ5dGUgbGFuZCAwYjEwMDAwMDAwID0gMGIwMDAwMDAw
MCB0aGVuCi0gICAgICAgIChieXRlLCAxKQotICAgICAgZWxzZSBpZiBieXRl
IGxhbmQgMGIxMTEwMDAwMCA9IDBiMTEwMDAwMDAgdGhlbgotICAgICAgICAo
Ynl0ZSBsYW5kIDBiMDAxMTExMSwgMikKLSAgICAgIGVsc2UgaWYgYnl0ZSBs
YW5kIDBiMTExMTAwMDAgPSAwYjExMTAwMDAwIHRoZW4KLSAgICAgICAgKGJ5
dGUgbGFuZCAwYjAwMDExMTEsIDMpCi0gICAgICBlbHNlIGlmIGJ5dGUgbGFu
ZCAwYjExMTExMDAwID0gMGIxMTExMDAwMCB0aGVuCi0gICAgICAgIChieXRl
IGxhbmQgMGIwMDAwMTExLCA0KQotICAgICAgZWxzZQotICAgICAgICByYWlz
ZSBVVEY4X2hlYWRlcl9ieXRlX2ludmFsaWQKLSAgICBpbgotICAgIGxldCB2
YWx1ZSA9Ci0gICAgICBpZiB3aWR0aCA9IDEgdGhlbgotICAgICAgICB2YWx1
ZQotICAgICAgZWxzZQotICAgICAgICBkZWNvZGVfY29udGludWF0aW9uX2J5
dGVzIHN0cmluZyAoaW5kZXggKyB3aWR0aCAtIDEpIHZhbHVlIChpbmRleCAr
IDEpCi0gICAgaW4KLSAgICBYTUxfVVRGOF9VQ1NfdmFsaWRhdG9yLnZhbGlk
YXRlIChVY2hhci51bnNhZmVfb2ZfaW50IHZhbHVlKSA7Ci0gICAgd2lkdGgK
LQotICBsZXQgcmVjIHZhbGlkYXRlX2F1eCBzdHJpbmcgbGVuZ3RoIGluZGV4
ID0KLSAgICBpZiBpbmRleCA9IGxlbmd0aCB0aGVuCi0gICAgICAoKQotICAg
IGVsc2UKLSAgICAgIGxldCB3aWR0aCA9Ci0gICAgICAgIHRyeQotICAgICAg
ICAgIGxldCBieXRlID0gc3RyaW5nLltpbmRleF0gfD4gQ2hhci5jb2RlIGlu
Ci0gICAgICAgICAgdmFsaWRhdGVfY2hhcmFjdGVyX3V0Zjggc3RyaW5nIGJ5
dGUgaW5kZXgKLSAgICAgICAgd2l0aAotICAgICAgICB8IEludmFsaWRfYXJn
dW1lbnQgXyAtPgotICAgICAgICAgICAgcmFpc2UgU3RyaW5nX2luY29tcGxl
dGUKLSAgICAgICAgfCBlcnJvciAtPgotICAgICAgICAgICAgcmFpc2UgKFZh
bGlkYXRpb25fZXJyb3IgKGluZGV4LCBlcnJvcikpCi0gICAgICBpbgotICAg
ICAgdmFsaWRhdGVfYXV4IHN0cmluZyBsZW5ndGggKGluZGV4ICsgd2lkdGgp
Ci0KLSAgbGV0IHZhbGlkYXRlIHN0cmluZyA9IHZhbGlkYXRlX2F1eCBzdHJp
bmcgKFN0cmluZy5sZW5ndGggc3RyaW5nKSAwCi0KLSAgbGV0IHJlYyB2YWxp
ZGF0ZV93aXRoX2Zhc3RwYXRoIHN0cmluZyBzdG9wIHBvcyA9Ci0gICAgaWYg
cG9zIDwgc3RvcCB0aGVuCi0gICAgICAoKiB0aGUgY29tcGlsZXIgaXMgc21h
cnQgZW5vdWdoIHRvIG9wdGltaXplIHRoZSAnaW50MzInIGF3YXkgaGVyZSwK
LSAgICAgICAgIGFuZCBub3QgYWxsb2NhdGUgKikKLSAgICAgIGxldCBpMzIg
PSBTdHJpbmcuZ2V0X2ludDMyX25lIHN0cmluZyBwb3MgfD4gSW50MzIudG9f
aW50IGluCi0gICAgICAoKiB0ZXN0IHRoYXQgZm9yIGFsbCBieXRlcyAweDIw
IDw9IGJ5dGUgPCAweDgwLgotICAgICAgICAgSWYgYW55IGlzIDwweDIwIGl0
IHdvdWxkIGNhdXNlIGEgbmVnYXRpdmUgdmFsdWUgdG8gYXBwZWFyIGluIHRo
YXQgYnl0ZSwKLSAgICAgICAgIHdoaWNoIHdlIGNhbiBkZXRlY3QgaWYgd2Ug
dXNlIDB4ODAgYXMgYSBtYXNrLgotICAgICAgICAgQnl0ZSA+PSAweDgwIGNh
biBiZSBzaW1pbGFybHkgZGV0ZWN0ZWQgd2l0aCBhIG1hc2sgb2YgMHg4MCBv
biBlYWNoIGJ5dGUuCi0gICAgICAgICBXZSBkb24ndCB3YW50IHRvIHNlZSBh
IDB4ODAgZnJvbSBlaXRoZXIgb2YgdGhlc2UsIGhlbmNlIHdlIGJpdHdpc2Ug
b3IgdGhlIDIgdmFsdWVzIHRvZ2V0aGVyLgotICAgICAgKikKLSAgICAgIGlm
IGkzMiBsb3IgKGkzMiAtIDB4MjBfMjBfMjBfMjApIGxhbmQgMHg4MF84MF84
MF84MCA9IDAgdGhlbgotICAgICAgICB2YWxpZGF0ZV93aXRoX2Zhc3RwYXRo
IHN0cmluZyBzdG9wIChwb3MgKyA0KQotICAgICAgZWxzZSAoKiB3aGVuIHRo
ZSBjb25kaXRpb24gZG9lc24ndCBob2xkIGZhbGwgYmFjayB0byBmdWxsIFVU
RjggZGVjb2RlciAqKQotICAgICAgICB2YWxpZGF0ZV9hdXggc3RyaW5nIChT
dHJpbmcubGVuZ3RoIHN0cmluZykgcG9zCi0gICAgZWxzZQotICAgICAgdmFs
aWRhdGVfYXV4IHN0cmluZyAoU3RyaW5nLmxlbmd0aCBzdHJpbmcpIHBvcwot
Ci0gIGxldCB2YWxpZGF0ZV93aXRoX2Zhc3RwYXRoIHN0cmluZyA9Ci0gICAg
dmFsaWRhdGVfd2l0aF9mYXN0cGF0aCBzdHJpbmcgKFN0cmluZy5sZW5ndGgg
c3RyaW5nIC0gMykgMAotCi0gIGxldCB2YWxpZGF0ZSA9Ci0gICAgaWYgU3lz
LndvcmRfc2l6ZSA9IDY0IHRoZW4KLSAgICAgIHZhbGlkYXRlX3dpdGhfZmFz
dHBhdGgKLSAgICBlbHNlCi0gICAgICB2YWxpZGF0ZQotCi0gIGxldCBpc192
YWxpZCBzdHJpbmcgPSB0cnkgdmFsaWRhdGUgc3RyaW5nIDsgdHJ1ZSB3aXRo
IF8gLT4gZmFsc2UKLQotICBsZXQgbG9uZ2VzdF92YWxpZF9wcmVmaXggc3Ry
aW5nID0KLSAgICB0cnkgdmFsaWRhdGUgc3RyaW5nIDsgc3RyaW5nCi0gICAg
d2l0aCBWYWxpZGF0aW9uX2Vycm9yIChpbmRleCwgXykgLT4gU3RyaW5nLnN1
YiBzdHJpbmcgMCBpbmRleAotZW5kCmRpZmYgLS1naXQgYS9vY2FtbC9saWJz
L3hhcGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3MvZW5jb2Rp
bmdzLm1saSBiL29jYW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3Rk
ZXh0LWVuY29kaW5ncy9lbmNvZGluZ3MubWxpCmRlbGV0ZWQgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAyYTEzOWFlMzcuLjAwMDAwMDAwMAotLS0gYS9vY2Ft
bC9saWJzL3hhcGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3Mv
ZW5jb2RpbmdzLm1saQorKysgL2Rldi9udWxsCkBAIC0xLDg0ICswLDAgQEAK
LSgqCi0gKiBDb3B5cmlnaHQgKEMpIDIwMDYtMjAwOSBDaXRyaXggU3lzdGVt
cyBJbmMuCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7
IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKLSAqIGl0
IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAotICogYnkgdGhlIEZyZWUgU29m
dHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUg
c3BlY2lhbAotICogZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGlu
IGZpbGUgTElDRU5TRS4KLSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKLSAq
IGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBp
bXBsaWVkIHdhcnJhbnR5IG9mCi0gKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklU
TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCi0gKiBH
TlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0
YWlscy4KLSAqKQotCi0oKiogRW5jb2RpbmcgaGVscGVyIG1vZHVsZXMgKikK
LQotKCoqIHsyIEV4Y2VwdGlvbnN9ICopCi0KLWV4Y2VwdGlvbiBVQ1NfdmFs
dWVfb3V0X29mX3JhbmdlCi0KLWV4Y2VwdGlvbiBVQ1NfdmFsdWVfcHJvaGli
aXRlZF9pbl9VVEY4Ci0KLWV4Y2VwdGlvbiBVQ1NfdmFsdWVfcHJvaGliaXRl
ZF9pbl9YTUwKLQotZXhjZXB0aW9uIFVURjhfY2hhcmFjdGVyX2luY29tcGxl
dGUKLQotZXhjZXB0aW9uIFVURjhfaGVhZGVyX2J5dGVfaW52YWxpZAotCi1l
eGNlcHRpb24gVVRGOF9jb250aW51YXRpb25fYnl0ZV9pbnZhbGlkCi0KLWV4
Y2VwdGlvbiBVVEY4X2VuY29kaW5nX25vdF9jYW5vbmljYWwKLQotZXhjZXB0
aW9uIFN0cmluZ19pbmNvbXBsZXRlCi0KLSgqKiB7MiBVQ1MgVmFsaWRhdG9y
c30gKikKLQotKCoqIFZhbGlkYXRlcyBVQ1MgY2hhcmFjdGVyIHZhbHVlcy4g
KikKLW1vZHVsZSB0eXBlIFVDU19WQUxJREFUT1IgPSBzaWcKLSAgdmFsIHZh
bGlkYXRlIDogVWNoYXIudCAtPiB1bml0Ci1lbmQKLQotKCoqIEFjY2VwdHMg
YWxsIHZhbHVlcyB3aXRoaW4gdGhlIFVDUyBjaGFyYWN0ZXIgdmFsdWUgcmFu
Z2UgZXhjZXB0Ci0gKiAgdGhvc2Ugd2hpY2ggYXJlIGludmFsaWQgZm9yIGFs
bCBVVEYtOC1lbmNvZGVkIFhNTCBkb2N1bWVudHMuICopCi1tb2R1bGUgWE1M
X1VURjhfVUNTX3ZhbGlkYXRvciA6IFVDU19WQUxJREFUT1IKLQotbW9kdWxl
IFhNTCA6IHNpZwotICB2YWwgaXNfaWxsZWdhbF9jb250cm9sX2NoYXJhY3Rl
ciA6IFVjaGFyLnQgLT4gYm9vbAotICAoKiogUmV0dXJucyB0cnVlIGlmIGFu
ZCBvbmx5IGlmIHRoZSBnaXZlbiB2YWx1ZSBjb3JyZXNwb25kcyB0bwotICAg
ICAgCSAqICBhIGlsbGVnYWwgY29udHJvbCBjaGFyYWN0ZXIgYXMgZGVmaW5l
ZCBpbiBzZWN0aW9uIDIuMiBvZgotICAgICAgCSAqICB0aGUgWE1MIHNwZWNp
ZmljYXRpb24sIHZlcnNpb24gMS4wLiAqKQotZW5kCi0KLSgqKiB7MiBTdHJp
bmcgVmFsaWRhdG9yc30gKikKLQotKCoqIFByb3ZpZGVzIGZ1bmN0aW9uYWxp
dHkgZm9yIHZhbGlkYXRpbmcgYW5kIHByb2Nlc3NpbmcKLSAqICBzdHJpbmdz
IGFjY29yZGluZyB0byBhIHBhcnRpY3VsYXIgY2hhcmFjdGVyIGVuY29kaW5n
LiAqKQotbW9kdWxlIHR5cGUgU1RSSU5HX1ZBTElEQVRPUiA9IHNpZwotICB2
YWwgaXNfdmFsaWQgOiBzdHJpbmcgLT4gYm9vbAotICAoKiogUmV0dXJucyB0
cnVlIGlmIGFuZCBvbmx5IGlmIHRoZSBnaXZlbiBzdHJpbmcgaXMgdmFsaWRs
eS1lbmNvZGVkLiAqKQotCi0gIHZhbCB2YWxpZGF0ZSA6IHN0cmluZyAtPiB1
bml0Ci0gICgqKiBSYWlzZXMgYW4gZW5jb2RpbmcgZXJyb3IgaWYgdGhlIGdp
dmVuIHN0cmluZyBpcyBub3QgdmFsaWRseS1lbmNvZGVkLiAqKQotCi0gIHZh
bCBsb25nZXN0X3ZhbGlkX3ByZWZpeCA6IHN0cmluZyAtPiBzdHJpbmcKLSAg
KCoqIFJldHVybnMgdGhlIGxvbmdlc3QgdmFsaWRseS1lbmNvZGVkIHByZWZp
eCBvZiB0aGUgZ2l2ZW4gc3RyaW5nLiAqKQotZW5kCi0KLSgqKiBSZXByZXNl
bnRzIGEgdmFsaWRhdGlvbiBlcnJvciBhcyBhIHR1cGxlIFsoaSxlKV0sIHdo
ZXJlOgotICogICAgW2ldID0gdGhlIGluZGV4IG9mIHRoZSBmaXJzdCBub24t
Y29tcGxpYW50IGNoYXJhY3RlcjsKLSAqICAgIFtlXSA9IHRoZSByZWFzb24g
Zm9yIG5vbi1jb21wbGlhbmNlLiAqKQotZXhjZXB0aW9uIFZhbGlkYXRpb25f
ZXJyb3Igb2YgaW50ICogZXhuCi0KLSgqKiBQcm92aWRlcyBmdW5jdGlvbnMg
Zm9yIHZhbGlkYXRpbmcgYW5kIHByb2Nlc3NpbmcKLSAqICBzdHJpbmdzIGFj
Y29yZGluZyB0byB0aGUgVVRGLTggY2hhcmFjdGVyIGVuY29kaW5nLAotICog
IHdpdGggY2VydGFpbiBhZGRpdGlvbmFsIHJlc3RyaWN0aW9ucyBvbiBVQ1Mg
dmFsdWVzCi0gKiAgaW1wb3NlZCBieSB0aGUgWE1MIHNwZWNpZmljYXRpb24u
Ci0gKgotICogIFZhbGlkbHktZW5jb2RlZCBzdHJpbmdzIG11c3Qgc2F0aXNm
eSBib3RoIFJGQyAzNjI5Ci0gKiAgYW5kIHNlY3Rpb24gMi4yIG9mIHRoZSBY
TUwgc3BlY2lmaWNhdGlvbi4KLSAqCi0gKiAgRm9yIGZ1cnRoZXIgaW5mb3Jt
YXRpb24sIHNlZToKLSAqICBodHRwOi8vd3d3LnJmYy5uZXQvcmZjMzYyOS5o
dG1sCi0gKiAgaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLXhtbC8jY2hhcnNl
dHMgKikKLW1vZHVsZSBVVEY4X1hNTCA6IFNUUklOR19WQUxJREFUT1IKZGlm
ZiAtLWdpdCBhL29jYW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3Rk
ZXh0LWVuY29kaW5ncy90ZXN0Lm1sIGIvb2NhbWwvbGlicy94YXBpLXN0ZGV4
dC9saWIveGFwaS1zdGRleHQtZW5jb2RpbmdzL3Rlc3QubWwKZGVsZXRlZCBm
aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDljYzc1YjI5Ny4uMDAwMDAwMDAwCi0t
LSBhL29jYW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3RkZXh0LWVu
Y29kaW5ncy90ZXN0Lm1sCisrKyAvZGV2L251bGwKQEAgLTEsNTMzICswLDAg
QEAKLSgqCi0gKiBDb3B5cmlnaHQgKEMpIDIwMDYtMjAwOSBDaXRyaXggU3lz
dGVtcyBJbmMuCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKLSAq
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAotICogYnkgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4gd2l0aCB0
aGUgc3BlY2lhbAotICogZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVk
IGluIGZpbGUgTElDRU5TRS4KLSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZGlz
dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwK
LSAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo
ZSBpbXBsaWVkIHdhcnJhbnR5IG9mCi0gKiBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCi0g
KiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUg
ZGV0YWlscy4KLSAqKQotbW9kdWxlIEUgPSBYYXBpX3N0ZGV4dF9lbmNvZGlu
Z3MuRW5jb2RpbmdzCi0KLSgqIFB1bGwgaW4gdGhlIGluZml4IG9wZXJhdG9y
cyBmcm9tIEVuY29kaW5ncyB1c2VkIGluIHRoaXMgdGVzdCAqKQotbGV0ICgg
LS0tICksICggKysrICksICggPDw8ICkgPSAoSW50LnN1YiwgSW50LmFkZCwg
SW50LnNoaWZ0X2xlZnQpCi0KLSgqID09PSBNb2NrIGV4Y2VwdGlvbnMgID09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0gKikKLQotKCoqIFNpbXVsYXRlcyBhIGRlY29kaW5nIGVycm9yLiAq
KQotZXhjZXB0aW9uIERlY29kZV9lcnJvcgotCi0oKiA9PT0gTW9jayBVQ1Mg
dmFsaWRhdG9ycyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09ICopCi0KLSgqKiBBIHZhbGlkYXRvciB0aGF0IGFs
d2F5cyBzdWNjZWVkcy4gKikKLW1vZHVsZSBMZW5pZW50X1VDU192YWxpZGF0
b3IgOiBFLlVDU19WQUxJREFUT1IgPSBzdHJ1Y3QKLSAgbGV0IHZhbGlkYXRl
IF8gPSAoKQotZW5kCi0KLSgqID09PSBNb2NrIGNoYXJhY3RlciB2YWxpZGF0
b3JzID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PSAqKQotCi0oKiogQSB2YWxpZGF0b3IgdGhhdCBzdWNjZWVkcyBmb3Ig
YWxsIGNoYXJhY3RlcnMuICopCi1tb2R1bGUgVW5pdmVyc2FsX2NoYXJhY3Rl
cl92YWxpZGF0b3IgPSBzdHJ1Y3QKLSAgbGV0IHZhbGlkYXRlIF8gPSAoKQot
ZW5kCi0KLSgqKiBBIHZhbGlkYXRvciB0aGF0IGZhaWxzIGZvciBhbGwgY2hh
cmFjdGVycy4gKikKLW1vZHVsZSBGYWlsaW5nX2NoYXJhY3Rlcl92YWxpZGF0
b3IgPSBzdHJ1Y3QKLSAgbGV0IHZhbGlkYXRlIF8gPSByYWlzZSBEZWNvZGVf
ZXJyb3IKLWVuZAotCi0oKiogQSB2YWxpZGF0b3IgdGhhdCBzdWNjZWVkcyBm
b3IgYWxsIGNoYXJhY3RlcnMgZXhjZXB0IHRoZSBsZXR0ZXIgJ0YnLiAqKQot
bW9kdWxlIFNlbGVjdGl2ZV9jaGFyYWN0ZXJfdmFsaWRhdG9yID0gc3RydWN0
Ci0gIGxldCB2YWxpZGF0ZSB1Y2hhciA9Ci0gICAgaWYgVWNoYXIuZXF1YWwg
dWNoYXIgKFVjaGFyLm9mX2NoYXIgJ0YnKSB0aGVuIHJhaXNlIERlY29kZV9l
cnJvcgotZW5kCi0KLSgqID09PSBUZXN0IGhlbHBlcnMgPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0g
KikKLQotbGV0IGFzc2VydF90cnVlID0gQWxjb3Rlc3QuKGNoZWNrIGJvb2wp
ICJ0cnVlIiB0cnVlCi0KLWxldCBhc3NlcnRfZmFsc2UgPSBBbGNvdGVzdC4o
Y2hlY2sgYm9vbCkgImZhbHNlIiBmYWxzZQotCi1sZXQgYXNzZXJ0X3JhaXNl
c19tYXRjaCBleGNlcHRpb25fbWF0Y2ggZm4gPQotICB0cnkKLSAgICBmbiAo
KSA7Ci0gICAgQWxjb3Rlc3QuZmFpbCAiYXNzZXJ0X3JhaXNlc19tYXRjaDog
ZmFpbHVyZSBleHBlY3RlZCIKLSAgd2l0aCBmYWlsdXJlIC0+Ci0gICAgaWYg
bm90IChleGNlcHRpb25fbWF0Y2ggZmFpbHVyZSkgdGhlbgotICAgICAgcmFp
c2UgZmFpbHVyZQotICAgIGVsc2UKLSAgICAgICgpCi0KLSgqID09PSBNb2Nr
IGNvZGVjcyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0gKikKLQotbW9kdWxlIFVDUyA9IHN0cnVj
dAotICAoKiA9PT0gVW5pY29kZSBGdW5jdGlvbnMgPT09ICopCi0gIGxldCBt
aW5fdmFsdWUgPSAweDAwMDAwMAotCi0gIGxldCBtYXhfdmFsdWUgPSAweDEw
ZmZmZgotICAoKiB1c2VkIHRvIGJlIDB4MWZmZmZmLCBidXQgdGhpcyBjaGFu
Z2VkIGFuZCBVbmljb2RlIHdvbid0IGFsbG9jYXRlIGxhcmdlciB0aGFuIDB4
MTBmZmZmICopCi0KLSAgbGV0IGlzX25vbl9jaGFyYWN0ZXIgdmFsdWUgPQot
ICAgIGZhbHNlCi0gICAgfHwgKDB4ZmRkMCA8PSB2YWx1ZSAmJiB2YWx1ZSA8
PSAweGZkZWYpICgqIGNhc2UgMSAqKQotICAgIHx8IEludC5sb2dhbmQgMHhm
ZmZlIHZhbHVlID0gMHhmZmZlCi0gICgqIGNhc2UgMiAqKQotCi0gIGxldCBp
c19vdXRfb2ZfcmFuZ2UgdmFsdWUgPSB2YWx1ZSA8IG1pbl92YWx1ZSB8fCB2
YWx1ZSA+IG1heF92YWx1ZQotCi0gIGxldCBpc19zdXJyb2dhdGUgdmFsdWUg
PSAweGQ4MDAgPD0gdmFsdWUgJiYgdmFsdWUgPD0gMHhkZmZmCi0KLSAgKCoq
IEEgbGlzdCBvZiBVQ1Mgbm9uLWNoYXJhY3RlcnMgdmFsdWVzLCBpbmNsdWRp
bmc6Ci0gICAgICBhLiBub24tY2hhcmFjdGVycyB3aXRoaW4gdGhlIGJhc2lj
IG11bHRpbGluZ3VhbCBwbGFuZTsKLSAgICAgIGIuIG5vbi1jaGFyYWN0ZXJz
IGF0IHRoZSBlbmQgb2YgdGhlIGJhc2ljIG11bHRpbGluZ3VhbCBwbGFuZTsK
LSAgICAgIGMuIG5vbi1jaGFyYWN0ZXJzIGF0IHRoZSBlbmQgb2YgdGhlIHBy
aXZhdGUgdXNlIGFyZWEuICopCi0gIGxldCBub25fY2hhcmFjdGVycyA9Ci0g
ICAgWwotICAgICAgMHgwMGZkZDAKLSAgICA7IDB4MDBmZGVmCi0gICAgOyAo
KiBjYXNlIGEuICopCi0gICAgICAweDAwZmZmZQotICAgIDsgMHgwMGZmZmYK
LSAgICA7ICgqIGNhc2UgYi4gKikKLSAgICAgIDB4MWZmZmZlCi0gICAgOyAw
eDFmZmZmZiAoKiBjYXNlIGMuICopCi0gICAgXQotCi0gICgqKiBBIGxpc3Qg
b2YgVUNTIGNoYXJhY3RlciB2YWx1ZXMgbG9jYXRlZCBpbW1lZGlhdGVseSBi
ZWZvcmUgb3IKLSAgICAgIGFmdGVyIFVDUyBub24tY2hhcmFjdGVyIHZhbHVl
cywgaW5jbHVkaW5nOgotICAgICAgYS4gbm9uLWNoYXJhY3RlcnMgd2l0aGlu
IHRoZSBiYXNpYyBtdWx0aWxpbmd1YWwgcGxhbmU7Ci0gICAgICBiLiBub24t
Y2hhcmFjdGVycyBhdCB0aGUgZW5kIG9mIHRoZSBiYXNpYyBtdWx0aWxpbmd1
YWwgcGxhbmU7Ci0gICAgICBjLiBub24tY2hhcmFjdGVycyBhdCB0aGUgZW5k
IG9mIHRoZSBwcml2YXRlIHVzZSBhcmVhLiAqKQotICBsZXQgdmFsaWRfY2hh
cmFjdGVyc19uZXh0X3RvX25vbl9jaGFyYWN0ZXJzID0KLSAgICBbCi0gICAg
ICAweDAwZmRjZgotICAgIDsgMHgwMGZkZjAKLSAgICA7ICgqIGNhc2UgYS4g
KikKLSAgICAgIDB4MDBmZmZkCi0gICAgOyAweDAxMDAwMAotICAgIDsgKCog
Y2FzZSBiLiAqKQotICAgICAgMHgxZmZmZmQKLSAgICA7IDB4MjAwMDAwICgq
IGNhc2UgYy4gKikKLSAgICBdCi0KLSAgbGV0IHRlc3RfaXNfbm9uX2NoYXJh
Y3RlciAoKSA9Ci0gICAgTGlzdC5pdGVyIChmdW4gdmFsdWUgLT4gYXNzZXJ0
X3RydWUgKGlzX25vbl9jaGFyYWN0ZXIgdmFsdWUpKSBub25fY2hhcmFjdGVy
cyA7Ci0gICAgTGlzdC5pdGVyCi0gICAgICAoZnVuIHZhbHVlIC0+IGFzc2Vy
dF9mYWxzZSAoaXNfbm9uX2NoYXJhY3RlciB2YWx1ZSkpCi0gICAgICB2YWxp
ZF9jaGFyYWN0ZXJzX25leHRfdG9fbm9uX2NoYXJhY3RlcnMKLQotICBsZXQg
dGVzdF9pc19vdXRfb2ZfcmFuZ2UgKCkgPQotICAgIGFzc2VydF90cnVlIChp
c19vdXRfb2ZfcmFuZ2UgKG1pbl92YWx1ZSAtLS0gMSkpIDsKLSAgICBhc3Nl
cnRfZmFsc2UgKGlzX291dF9vZl9yYW5nZSBtaW5fdmFsdWUpIDsKLSAgICBh
c3NlcnRfZmFsc2UgKGlzX291dF9vZl9yYW5nZSBtYXhfdmFsdWUpIDsKLSAg
ICBhc3NlcnRfdHJ1ZSAoaXNfb3V0X29mX3JhbmdlIChtYXhfdmFsdWUgKysr
IDEpKQotCi0gIGxldCB0ZXN0X2lzX3N1cnJvZ2F0ZSAoKSA9Ci0gICAgYXNz
ZXJ0X2ZhbHNlIChpc19zdXJyb2dhdGUgMHhkN2ZmKSA7Ci0gICAgYXNzZXJ0
X3RydWUgKGlzX3N1cnJvZ2F0ZSAweGQ4MDApIDsKLSAgICBhc3NlcnRfdHJ1
ZSAoaXNfc3Vycm9nYXRlIDB4ZGZmZikgOwotICAgIGFzc2VydF9mYWxzZSAo
aXNfc3Vycm9nYXRlIDB4ZTAwMCkKLQotICBsZXQgdGVzdHMgPQotICAgIFsK
LSAgICAgICgidGVzdF9pc19ub25fY2hhcmFjdGVyIiwgYFF1aWNrLCB0ZXN0
X2lzX25vbl9jaGFyYWN0ZXIpCi0gICAgOyAoInRlc3RfaXNfb3V0X29mX3Jh
bmdlIiwgYFF1aWNrLCB0ZXN0X2lzX291dF9vZl9yYW5nZSkKLSAgICA7ICgi
dGVzdF9pc19zdXJyb2dhdGUiLCBgUXVpY2ssIHRlc3RfaXNfc3Vycm9nYXRl
KQotICAgIF0KLWVuZAotCi1tb2R1bGUgTGVuaWVudF9VVEY4X2NvZGVjID0g
c3RydWN0Ci0gIGxldCBkZWNvZGVfaGVhZGVyX2J5dGUgYnl0ZSA9Ci0gICAg
aWYgYnl0ZSBsYW5kIDBiMTAwMDAwMDAgPSAwYjAwMDAwMDAwIHRoZW4KLSAg
ICAgIChieXRlLCAxKQotICAgIGVsc2UgaWYgYnl0ZSBsYW5kIDBiMTExMDAw
MDAgPSAwYjExMDAwMDAwIHRoZW4KLSAgICAgIChieXRlIGxhbmQgMGIwMDEx
MTExLCAyKQotICAgIGVsc2UgaWYgYnl0ZSBsYW5kIDBiMTExMTAwMDAgPSAw
YjExMTAwMDAwIHRoZW4KLSAgICAgIChieXRlIGxhbmQgMGIwMDAxMTExLCAz
KQotICAgIGVsc2UgaWYgYnl0ZSBsYW5kIDBiMTExMTEwMDAgPSAwYjExMTEw
MDAwIHRoZW4KLSAgICAgIChieXRlIGxhbmQgMGIwMDAwMTExLCA0KQotICAg
IGVsc2UKLSAgICAgIHJhaXNlIEUuVVRGOF9oZWFkZXJfYnl0ZV9pbnZhbGlk
Ci0KLSAgbGV0IGRlY29kZV9jb250aW51YXRpb25fYnl0ZSBieXRlID0KLSAg
ICBpZiBieXRlIGxhbmQgMGIxMTAwMDAwMCA9IDBiMTAwMDAwMDAgdGhlbgot
ICAgICAgYnl0ZSBsYW5kIDBiMDAxMTExMTEKLSAgICBlbHNlCi0gICAgICBy
YWlzZSBFLlVURjhfY29udGludWF0aW9uX2J5dGVfaW52YWxpZAotCi0gIGxl
dCB3aWR0aF9yZXF1aXJlZF9mb3JfdWNzX3ZhbHVlIHZhbHVlID0KLSAgICBp
ZiB2YWx1ZSA8IDB4MDAwMDgwICgqIDEgbHNsICA3ICopIHRoZW4KLSAgICAg
IDEKLSAgICBlbHNlIGlmIHZhbHVlIDwgMHgwMDA4MDAgKCogMSBsc2wgMTEg
KikgdGhlbgotICAgICAgMgotICAgIGVsc2UgaWYgdmFsdWUgPCAweDAxMDAw
MCAoKiAxIGxzbCAxNiAqKSB0aGVuCi0gICAgICAzCi0gICAgZWxzZQotICAg
ICAgNAotCi0gIGxldCBkZWNvZGVfY2hhcmFjdGVyIHN0cmluZyBpbmRleCA9
Ci0gICAgbGV0IHZhbHVlLCB3aWR0aCA9IGRlY29kZV9oZWFkZXJfYnl0ZSAo
Q2hhci5jb2RlIHN0cmluZy5baW5kZXhdKSBpbgotICAgIGxldCB2YWx1ZSA9
Ci0gICAgICBpZiB3aWR0aCA9IDEgdGhlbgotICAgICAgICB2YWx1ZQotICAg
ICAgZWxzZQotICAgICAgICBsZXQgdmFsdWUgPSByZWYgdmFsdWUgaW4KLSAg
ICAgICAgZm9yIGluZGV4ID0gaW5kZXggKyAxIHRvIGluZGV4ICsgd2lkdGgg
LSAxIGRvCi0gICAgICAgICAgbGV0IGNodW5rID0gZGVjb2RlX2NvbnRpbnVh
dGlvbl9ieXRlIChDaGFyLmNvZGUgc3RyaW5nLltpbmRleF0pIGluCi0gICAg
ICAgICAgdmFsdWUgOj0gKCF2YWx1ZSBsc2wgNikgbG9yIGNodW5rCi0gICAg
ICAgIGRvbmUgOwotICAgICAgICBpZiB3aWR0aCA+IHdpZHRoX3JlcXVpcmVk
X2Zvcl91Y3NfdmFsdWUgIXZhbHVlIHRoZW4KLSAgICAgICAgICByYWlzZSBF
LlVURjhfZW5jb2Rpbmdfbm90X2Nhbm9uaWNhbCA7Ci0gICAgICAgICF2YWx1
ZQotICAgIGluCi0gICAgKHZhbHVlLCB3aWR0aCkKLWVuZAotCi0oKiA9PT0g
TW9jayBzdHJpbmcgdmFsaWRhdG9ycyA9PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09ICopCi1tb2R1bGUgTW9ja19TdHJp
bmdfdmFsaWRhdG9yIChWYWxpZGF0b3IgOiBFLlVDU19WQUxJREFUT1IpIDoK
LSAgRS5TVFJJTkdfVkFMSURBVE9SID0gc3RydWN0Ci0gICgqIG5vIGxvbmdl
ciBhIGZ1bmN0b3IgaW4gRW5jb2RpbmdzIGZvciBwZXJmb3JtYW5jZSByZWFz
b25zLAotICAgICBzbyBtb2RpZnkgdGhlIG9yaWdpbmFsIHN0cmluZyBwYXNz
ZWQgYXMgYXJndW1lbnQgaW5zdGVhZCByZXBsYWNpbmcKLSAgICAgY2hhcmFj
dGVycyB0aGF0IHdvdWxkIGJlIGludmFsaWQgd2l0aCBhIGtub3duIGludmFs
aWQgWE1MIGNoYXI6IDB4MEIuCi0gICopCi0KLSAgbGV0IHRyYW5zZm9ybSBz
dHIgPQotICAgIGxldCBiID0gQnVmZmVyLmNyZWF0ZSAoU3RyaW5nLmxlbmd0
aCBzdHIpIGluCi0gICAgbGV0IHJlYyBsb29wIHBvcyA9Ci0gICAgICBpZiBw
b3MgPCBTdHJpbmcubGVuZ3RoIHN0ciB0aGVuCi0gICAgICAgIGxldCB2YWx1
ZSwgd2lkdGggPSBMZW5pZW50X1VURjhfY29kZWMuZGVjb2RlX2NoYXJhY3Rl
ciBzdHIgcG9zIGluCi0gICAgICAgIGxldCAoKSA9Ci0gICAgICAgICAgdHJ5
Ci0gICAgICAgICAgICBsZXQgdSA9IFVjaGFyLm9mX2ludCB2YWx1ZSBpbgot
ICAgICAgICAgICAgVmFsaWRhdG9yLnZhbGlkYXRlIHUgOyBCdWZmZXIuYWRk
X3V0Zl84X3VjaGFyIGIgdQotICAgICAgICAgIHdpdGggXyAtPiBCdWZmZXIu
YWRkX2NoYXIgYiAnXHgwQicKLSAgICAgICAgaW4KLSAgICAgICAgbG9vcCAo
cG9zICsgd2lkdGgpCi0gICAgaW4KLSAgICBsb29wIDAgOyBCdWZmZXIuY29u
dGVudHMgYgotCi0gIGxldCBpc192YWxpZCBzdHIgPSBFLlVURjhfWE1MLmlz
X3ZhbGlkICh0cmFuc2Zvcm0gc3RyKQotCi0gIGxldCB2YWxpZGF0ZSBzdHIg
PQotICAgIHRyeSBFLlVURjhfWE1MLnZhbGlkYXRlICh0cmFuc2Zvcm0gc3Ry
KQotICAgIHdpdGggRS5WYWxpZGF0aW9uX2Vycm9yIChwb3MsIF8pIC0+Ci0g
ICAgICByYWlzZSAoRS5WYWxpZGF0aW9uX2Vycm9yIChwb3MsIERlY29kZV9l
cnJvcikpCi0KLSAgbGV0IGxvbmdlc3RfdmFsaWRfcHJlZml4IHN0ciA9IEUu
VVRGOF9YTUwubG9uZ2VzdF92YWxpZF9wcmVmaXggKHRyYW5zZm9ybSBzdHIp
Ci1lbmQKLQotKCoqIEEgdmFsaWRhdG9yIHRoYXQgYWNjZXB0cyBhbGwgc3Ry
aW5ncy4gKikKLW1vZHVsZSBVbml2ZXJzYWxfc3RyaW5nX3ZhbGlkYXRvciA9
Ci0gIE1vY2tfU3RyaW5nX3ZhbGlkYXRvciAoVW5pdmVyc2FsX2NoYXJhY3Rl
cl92YWxpZGF0b3IpCi0KLSgqKiBBIHZhbGlkYXRvciB0aGF0IHJlamVjdHMg
YWxsIHN0cmluZ3MuICopCi1tb2R1bGUgRmFpbGluZ19zdHJpbmdfdmFsaWRh
dG9yID0KLSAgTW9ja19TdHJpbmdfdmFsaWRhdG9yIChGYWlsaW5nX2NoYXJh
Y3Rlcl92YWxpZGF0b3IpCi0KLSgqKiBBIHZhbGlkYXRvciB0aGF0IHJlamVj
dHMgc3RyaW5ncyBjb250YWluaW5nIHRoZSBjaGFyYWN0ZXIgJ0YnLiAqKQot
bW9kdWxlIFNlbGVjdGl2ZV9zdHJpbmdfdmFsaWRhdG9yID0KLSAgTW9ja19T
dHJpbmdfdmFsaWRhdG9yIChTZWxlY3RpdmVfY2hhcmFjdGVyX3ZhbGlkYXRv
cikKLQotKCogPT09IFRlc3RzID09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAqKQotCi1t
b2R1bGUgU3RyaW5nX3ZhbGlkYXRvciA9IHN0cnVjdAotICBsZXQgdGVzdF9p
c192YWxpZCAoKSA9Ci0gICAgYXNzZXJ0X3RydWUgKFVuaXZlcnNhbF9zdHJp
bmdfdmFsaWRhdG9yLmlzX3ZhbGlkICIiKSA7Ci0gICAgYXNzZXJ0X3RydWUg
KFVuaXZlcnNhbF9zdHJpbmdfdmFsaWRhdG9yLmlzX3ZhbGlkICIxMjM0NTY3
ODkiKSA7Ci0gICAgYXNzZXJ0X3RydWUgKFNlbGVjdGl2ZV9zdHJpbmdfdmFs
aWRhdG9yLmlzX3ZhbGlkICIiKSA7Ci0gICAgYXNzZXJ0X3RydWUgKFNlbGVj
dGl2ZV9zdHJpbmdfdmFsaWRhdG9yLmlzX3ZhbGlkICIxMjM0NTY3ODkiKSA7
Ci0gICAgYXNzZXJ0X2ZhbHNlIChTZWxlY3RpdmVfc3RyaW5nX3ZhbGlkYXRv
ci5pc192YWxpZCAiRjIzNDU2Nzg5IikgOwotICAgIGFzc2VydF9mYWxzZSAo
U2VsZWN0aXZlX3N0cmluZ192YWxpZGF0b3IuaXNfdmFsaWQgIjEyMzRGNjc4
OSIpIDsKLSAgICBhc3NlcnRfZmFsc2UgKFNlbGVjdGl2ZV9zdHJpbmdfdmFs
aWRhdG9yLmlzX3ZhbGlkICIxMjM0NTY3OEYiKSA7Ci0gICAgYXNzZXJ0X2Zh
bHNlIChTZWxlY3RpdmVfc3RyaW5nX3ZhbGlkYXRvci5pc192YWxpZCAiRkZG
RkZGRkZGIikKLQotICBsZXQgdGVzdF9sb25nZXN0X3ZhbGlkX3ByZWZpeCAo
KSA9Ci0gICAgQWxjb3Rlc3QuKGNoZWNrIHN0cmluZykKLSAgICAgICJwcmVm
aXgiCi0gICAgICAoVW5pdmVyc2FsX3N0cmluZ192YWxpZGF0b3IubG9uZ2Vz
dF92YWxpZF9wcmVmaXggIiIpCi0gICAgICAiIiA7Ci0gICAgQWxjb3Rlc3Qu
KGNoZWNrIHN0cmluZykKLSAgICAgICJwcmVmaXgiCi0gICAgICAoVW5pdmVy
c2FsX3N0cmluZ192YWxpZGF0b3IubG9uZ2VzdF92YWxpZF9wcmVmaXggIjEy
MzQ1Njc4OSIpCi0gICAgICAiMTIzNDU2Nzg5IiA7Ci0gICAgQWxjb3Rlc3Qu
KGNoZWNrIHN0cmluZykKLSAgICAgICJwcmVmaXgiCi0gICAgICAoU2VsZWN0
aXZlX3N0cmluZ192YWxpZGF0b3IubG9uZ2VzdF92YWxpZF9wcmVmaXggIiIp
Ci0gICAgICAiIiA7Ci0gICAgQWxjb3Rlc3QuKGNoZWNrIHN0cmluZykKLSAg
ICAgICJwcmVmaXgiCi0gICAgICAoU2VsZWN0aXZlX3N0cmluZ192YWxpZGF0
b3IubG9uZ2VzdF92YWxpZF9wcmVmaXggIjEyMzQ1Njc4OSIpCi0gICAgICAi
MTIzNDU2Nzg5IiA7Ci0gICAgQWxjb3Rlc3QuKGNoZWNrIHN0cmluZykKLSAg
ICAgICJwcmVmaXgiCi0gICAgICAoU2VsZWN0aXZlX3N0cmluZ192YWxpZGF0
b3IubG9uZ2VzdF92YWxpZF9wcmVmaXggIkYyMzQ1Njc4OSIpCi0gICAgICAi
IiA7Ci0gICAgQWxjb3Rlc3QuKGNoZWNrIHN0cmluZykKLSAgICAgICJwcmVm
aXgiCi0gICAgICAoU2VsZWN0aXZlX3N0cmluZ192YWxpZGF0b3IubG9uZ2Vz
dF92YWxpZF9wcmVmaXggIjEyMzRGNjc4OSIpCi0gICAgICAiMTIzNCIgOwot
ICAgIEFsY290ZXN0LihjaGVjayBzdHJpbmcpCi0gICAgICAicHJlZml4Igot
ICAgICAgKFNlbGVjdGl2ZV9zdHJpbmdfdmFsaWRhdG9yLmxvbmdlc3RfdmFs
aWRfcHJlZml4ICIxMjM0NTY3OEYiKQotICAgICAgIjEyMzQ1Njc4IiA7Ci0g
ICAgQWxjb3Rlc3QuKGNoZWNrIHN0cmluZykKLSAgICAgICJwcmVmaXgiCi0g
ICAgICAoU2VsZWN0aXZlX3N0cmluZ192YWxpZGF0b3IubG9uZ2VzdF92YWxp
ZF9wcmVmaXggIkZGRkZGRkZGRiIpCi0gICAgICAiIgotCi0gICgqKiBUZXN0
cyB0aGF0IHZhbGlkYXRpb24gZG9lcyBub3QgZmFpbCBmb3IgYW4gZW1wdHkg
c3RyaW5nLiAqKQotICBsZXQgdGVzdF92YWxpZGF0ZV93aXRoX2VtcHR5X3N0
cmluZyAoKSA9IEUuVVRGOF9YTUwudmFsaWRhdGUgIiIKLQotICBsZXQgdGVz
dF92YWxpZGF0ZV93aXRoX2luY29tcGxldGVfc3RyaW5nICgpID0KLSAgICBB
bGNvdGVzdC5jaGVja19yYWlzZXMgIlZhbGlkYXRpb24gZmFpbHMgY29ycmVj
dGx5IGZvciBhbiBpbmNvbXBsZXRlIHN0cmluZyIKLSAgICAgIEUuU3RyaW5n
X2luY29tcGxldGUgKGZ1biAoKSAtPiBFLlVURjhfWE1MLnZhbGlkYXRlICJc
eGMyIgotICAgICkKLQotICBsZXQgdGVzdF92YWxpZGF0ZV93aXRoX2ZhaWxp
bmdfZGVjb2RlcnMgKCkgPQotICAgIEZhaWxpbmdfc3RyaW5nX3ZhbGlkYXRv
ci52YWxpZGF0ZSAiIiA7Ci0gICAgYXNzZXJ0X3JhaXNlc19tYXRjaAotICAg
ICAgKGZ1bmN0aW9uIEUuVmFsaWRhdGlvbl9lcnJvciAoMCwgRGVjb2RlX2Vy
cm9yKSAtPiB0cnVlIHwgXyAtPiBmYWxzZSkKLSAgICAgIChmdW4gKCkgLT4g
U2VsZWN0aXZlX3N0cmluZ192YWxpZGF0b3IudmFsaWRhdGUgIkYiKSA7Ci0g
ICAgYXNzZXJ0X3JhaXNlc19tYXRjaAotICAgICAgKGZ1bmN0aW9uIEUuVmFs
aWRhdGlvbl9lcnJvciAoMCwgRGVjb2RlX2Vycm9yKSAtPiB0cnVlIHwgXyAt
PiBmYWxzZSkKLSAgICAgIChmdW4gKCkgLT4gU2VsZWN0aXZlX3N0cmluZ192
YWxpZGF0b3IudmFsaWRhdGUgIkYxMjM0NTY3OCIpIDsKLSAgICBhc3NlcnRf
cmFpc2VzX21hdGNoCi0gICAgICAoZnVuY3Rpb24gRS5WYWxpZGF0aW9uX2Vy
cm9yICg0LCBEZWNvZGVfZXJyb3IpIC0+IHRydWUgfCBfIC0+IGZhbHNlKQot
ICAgICAgKGZ1biAoKSAtPiBTZWxlY3RpdmVfc3RyaW5nX3ZhbGlkYXRvci52
YWxpZGF0ZSAiMDEyM0Y1Njc4IikgOwotICAgIGFzc2VydF9yYWlzZXNfbWF0
Y2gKLSAgICAgIChmdW5jdGlvbiBFLlZhbGlkYXRpb25fZXJyb3IgKDgsIERl
Y29kZV9lcnJvcikgLT4gdHJ1ZSB8IF8gLT4gZmFsc2UpCi0gICAgICAoZnVu
ICgpIC0+IFNlbGVjdGl2ZV9zdHJpbmdfdmFsaWRhdG9yLnZhbGlkYXRlICIw
MTIzNDU2N0YiKSA7Ci0gICAgYXNzZXJ0X3JhaXNlc19tYXRjaAotICAgICAg
KGZ1bmN0aW9uIEUuVmFsaWRhdGlvbl9lcnJvciAoMCwgRGVjb2RlX2Vycm9y
KSAtPiB0cnVlIHwgXyAtPiBmYWxzZSkKLSAgICAgIChmdW4gKCkgLT4gU2Vs
ZWN0aXZlX3N0cmluZ192YWxpZGF0b3IudmFsaWRhdGUgIkZGRkZGRkZGRiIp
Ci0KLSAgbGV0IHRlc3RzID0KLSAgICBbCi0gICAgICAoInRlc3RfaXNfdmFs
aWQiLCBgUXVpY2ssIHRlc3RfaXNfdmFsaWQpCi0gICAgOyAoInRlc3RfbG9u
Z2VzdF92YWxpZF9wcmVmaXgiLCBgUXVpY2ssIHRlc3RfbG9uZ2VzdF92YWxp
ZF9wcmVmaXgpCi0gICAgOyAoICJ0ZXN0X3ZhbGlkYXRlX3dpdGhfZW1wdHlf
c3RyaW5nIgotICAgICAgLCBgUXVpY2sKLSAgICAgICwgdGVzdF92YWxpZGF0
ZV93aXRoX2VtcHR5X3N0cmluZwotICAgICAgKQotICAgIDsgKCAidGVzdF92
YWxpZGF0ZV93aXRoX2luY29tcGxldGVfc3RyaW5nIgotICAgICAgLCBgUXVp
Y2sKLSAgICAgICwgdGVzdF92YWxpZGF0ZV93aXRoX2luY29tcGxldGVfc3Ry
aW5nCi0gICAgICApCi0gICAgOyAoICJ0ZXN0X3ZhbGlkYXRlX3dpdGhfZmFp
bGluZ19kZWNvZGVycyIKLSAgICAgICwgYFF1aWNrCi0gICAgICAsIHRlc3Rf
dmFsaWRhdGVfd2l0aF9mYWlsaW5nX2RlY29kZXJzCi0gICAgICApCi0gICAg
XQotZW5kCi0KLW1vZHVsZSBYTUwgPSBzdHJ1Y3QKLSAgaW5jbHVkZSBFLlhN
TAotCi0gIGxldCB0ZXN0X2lzX2lsbGVnYWxfY29udHJvbF9jaGFyYWN0ZXIg
KCkgPQotICAgIGFzc2VydF90cnVlIChpc19pbGxlZ2FsX2NvbnRyb2xfY2hh
cmFjdGVyIChVY2hhci5vZl9pbnQgMHgwMCkpIDsKLSAgICBhc3NlcnRfdHJ1
ZSAoaXNfaWxsZWdhbF9jb250cm9sX2NoYXJhY3RlciAoVWNoYXIub2ZfaW50
IDB4MTkpKSA7Ci0gICAgYXNzZXJ0X2ZhbHNlIChpc19pbGxlZ2FsX2NvbnRy
b2xfY2hhcmFjdGVyIChVY2hhci5vZl9pbnQgMHgwOSkpIDsKLSAgICBhc3Nl
cnRfZmFsc2UgKGlzX2lsbGVnYWxfY29udHJvbF9jaGFyYWN0ZXIgKFVjaGFy
Lm9mX2ludCAweDBhKSkgOwotICAgIGFzc2VydF9mYWxzZSAoaXNfaWxsZWdh
bF9jb250cm9sX2NoYXJhY3RlciAoVWNoYXIub2ZfaW50IDB4MGQpKSA7Ci0g
ICAgYXNzZXJ0X2ZhbHNlIChpc19pbGxlZ2FsX2NvbnRyb2xfY2hhcmFjdGVy
IChVY2hhci5vZl9pbnQgMHgyMCkpCi0KLSAgbGV0IHRlc3RzID0KLSAgICBb
Ci0gICAgICAoICJ0ZXN0X2lzX2lsbGVnYWxfY29udHJvbF9jaGFyYWN0ZXIi
Ci0gICAgICAsIGBRdWljawotICAgICAgLCB0ZXN0X2lzX2lsbGVnYWxfY29u
dHJvbF9jaGFyYWN0ZXIKLSAgICAgICkKLSAgICBdCi1lbmQKLQotKCoqIFRl
c3RzIHRoZSBYTUwtc3BlY2lmaWMgVVRGLTggVUNTIHZhbGlkYXRpb24gZnVu
Y3Rpb24uICopCi1tb2R1bGUgWE1MX1VURjhfVUNTX3ZhbGlkYXRvciA9IHN0
cnVjdAotICBpbmNsdWRlIEUuWE1MX1VURjhfVUNTX3ZhbGlkYXRvcgotCi0g
IGxldCB2YWxpZGF0ZSB1Y2hhciA9Ci0gICAgaWYgVWNoYXIuaXNfdmFsaWQg
dWNoYXIgdGhlbgotICAgICAgdmFsaWRhdGUgQEAgVWNoYXIub2ZfaW50IHVj
aGFyCi0gICAgZWxzZSBpZiB1Y2hhciA8IFVjaGFyLnRvX2ludCBVY2hhci5t
aW4gfHwgdWNoYXIgPiBVY2hhci50b19pbnQgVWNoYXIubWF4Ci0gICAgdGhl
bgotICAgICAgcmFpc2UgRS5VQ1NfdmFsdWVfb3V0X29mX3JhbmdlCi0gICAg
ZWxzZQotICAgICAgcmFpc2UgRS5VQ1NfdmFsdWVfcHJvaGliaXRlZF9pbl9V
VEY4Ci0KLSAgbGV0IHRlc3RfdmFsaWRhdGUgKCkgPQotICAgIGxldCB2YWx1
ZSA9IHJlZiAoVUNTLm1pbl92YWx1ZSAtLS0gMSkgaW4KLSAgICB3aGlsZSAh
dmFsdWUgPD0gVUNTLm1heF92YWx1ZSArKysgMSBkbwotICAgICAgaWYgVUNT
LmlzX291dF9vZl9yYW5nZSAhdmFsdWUgdGhlbgotICAgICAgICBBbGNvdGVz
dC5jaGVja19yYWlzZXMgInNob3VsZCBmYWlsIiBFLlVDU192YWx1ZV9vdXRf
b2ZfcmFuZ2UgKGZ1biAoKSAtPgotICAgICAgICAgICAgdmFsaWRhdGUgIXZh
bHVlCi0gICAgICAgICkKLSAgICAgIGVsc2UgaWYgVUNTLmlzX25vbl9jaGFy
YWN0ZXIgIXZhbHVlIHx8IFVDUy5pc19zdXJyb2dhdGUgIXZhbHVlIHRoZW4K
LSAgICAgICAgQWxjb3Rlc3QuY2hlY2tfcmFpc2VzICJzaG91bGQgZmFpbCIg
RS5VQ1NfdmFsdWVfcHJvaGliaXRlZF9pbl9VVEY4Ci0gICAgICAgICAgKGZ1
biAoKSAtPiB2YWxpZGF0ZSAhdmFsdWUKLSAgICAgICAgKQotICAgICAgZWxz
ZSBpZgotICAgICAgICBVY2hhci5pc192YWxpZCAhdmFsdWUKLSAgICAgICAg
JiYgWE1MLmlzX2lsbGVnYWxfY29udHJvbF9jaGFyYWN0ZXIgKFVjaGFyLm9m
X2ludCAhdmFsdWUpCi0gICAgICB0aGVuCi0gICAgICAgIEFsY290ZXN0LmNo
ZWNrX3JhaXNlcyAic2hvdWxkIGZhaWwiIEUuVUNTX3ZhbHVlX3Byb2hpYml0
ZWRfaW5fWE1MCi0gICAgICAgICAgKGZ1biAoKSAtPiB2YWxpZGF0ZSAhdmFs
dWUKLSAgICAgICAgKQotICAgICAgZWxzZQotICAgICAgICB2YWxpZGF0ZSAh
dmFsdWUgOwotICAgICAgdmFsdWUgOj0gIXZhbHVlICsrKyAxCi0gICAgZG9u
ZQotCi0gIGxldCB0ZXN0cyA9IFsoInRlc3RfdmFsaWRhdGUiLCBgUXVpY2ss
IHRlc3RfdmFsaWRhdGUpXQotZW5kCi0KLW1vZHVsZSBVVEY4X2NvZGVjID0g
c3RydWN0Ci0gICgqKiBBIGxpc3Qgb2YgY2Fub25pY2FsIGVuY29kaW5nIHdp
ZHRocyBvZiBVQ1MgdmFsdWVzLAotICAgICAgcmVwcmVzZW50ZWQgYnkgdHVw
bGVzIG9mIHRoZSBmb3JtICh2LCB3KSwgd2hlcmU6Ci0gICAgICB2ID0gdGhl
IFVDUyBjaGFyYWN0ZXIgdmFsdWUgdG8gYmUgZW5jb2RlZDsgYW5kCi0gICAg
ICB3ID0gdGhlIHdpZHRoIG9mIHRoZSBlbmNvZGVkIGNoYXJhY3RlciwgaW4g
Ynl0ZXMuICopCi0gIGxldCB2YWxpZF91Y3NfdmFsdWVfd2lkdGhzID0KLSAg
ICBbCi0gICAgICAoMSwgMSkKLSAgICA7ICgoMSA8PDwgNykgLS0tIDEsIDEp
Ci0gICAgOyAoMSA8PDwgNywgMikKLSAgICA7ICgoMSA8PDwgMTEpIC0tLSAx
LCAyKQotICAgIDsgKDEgPDw8IDExLCAzKQotICAgIDsgKCgxIDw8PCAxNikg
LS0tIDEsIDMpCi0gICAgOyAoMSA8PDwgMTYsIDQpCi0gICAgOyAoKDEgPDw8
IDIxKSAtLS0gMSwgNCkKLSAgICBdCi0KLSAgbGV0IHdpZHRoX3JlcXVpcmVk
X2Zvcl91Y3NfdmFsdWUgdmFsdWUgPQotICAgIGlmIHZhbHVlIDwgMHgwMDAw
ODAgKCogMSBsc2wgIDcgKikgdGhlbgotICAgICAgMQotICAgIGVsc2UgaWYg
dmFsdWUgPCAweDAwMDgwMCAoKiAxIGxzbCAxMSAqKSB0aGVuCi0gICAgICAy
Ci0gICAgZWxzZSBpZiB2YWx1ZSA8IDB4MDEwMDAwICgqIDEgbHNsIDE2ICop
IHRoZW4KLSAgICAgIDMKLSAgICBlbHNlCi0gICAgICA0Ci0KLSAgbGV0IHRl
c3Rfd2lkdGhfcmVxdWlyZWRfZm9yX3Vjc192YWx1ZSAoKSA9Ci0gICAgTGlz
dC5pdGVyCi0gICAgICAoZnVuICh2YWx1ZSwgd2lkdGgpIC0+Ci0gICAgICAg
IEFsY290ZXN0LihjaGVjayBpbnQpCi0gICAgICAgICAgInNhbWUgaW50cyIK
LSAgICAgICAgICAod2lkdGhfcmVxdWlyZWRfZm9yX3Vjc192YWx1ZSB2YWx1
ZSkKLSAgICAgICAgICB3aWR0aAotICAgICAgKQotICAgICAgdmFsaWRfdWNz
X3ZhbHVlX3dpZHRocwotCi0gICgqKiBBIGxpc3Qgb2YgdmFsaWQgY2hhcmFj
dGVyIGRlY29kaW5ncyByZXByZXNlbnRlZCBieQotICAgICAgdHVwbGVzIG9m
IHRoZSBmb3JtIChzLCAodiwgdykpLCB3aGVyZToKLQotICAgICAgcyA9IGEg
dmFsaWRseS1lbmNvZGVkIFVURi04IHN0cmluZzsKLSAgICAgIHYgPSB0aGUg
VUNTIHZhbHVlIHJlcHJlc2VudGVkIGJ5IHRoZSBzdHJpbmc7Ci0gICAgICAg
ICAgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlIHZhbGlkIGluIGl0cyBvd24g
cmlnaHQpCi0gICAgICB3ID0gdGhlIHdpZHRoIG9mIHRoZSBlbmNvZGVkIHN0
cmluZywgaW4gYnl0ZXMuCi0KLSAgICAgIEZvciBlYWNoIGJ5dGUgbGVuZ3Ro
IGIgaW4gWzEuLi40XSwgdGhlIGxpc3QgY29udGFpbnMKLSAgICAgIGRlY29k
aW5ncyBmb3I6Ci0KLSAgICAgIHZfbWluID0gdGhlIHNtYWxsZXN0IFVDUyB2
YWx1ZSBlbmNvZGFibGUgaW4gYiBieXRlcy4KLSAgICAgIHZfbWF4ID0gdGhl
IGdyZWF0ZXN0IFVDUyB2YWx1ZSBlbmNvZGFibGUgaW4gYiBieXRlcy4gKikK
LSAgbGV0IHZhbGlkX2NoYXJhY3Rlcl9kZWNvZGluZ3MgPQotICAgIFsKLSAg
ICAgICgqICAgICAgICAgICAgICAgNzY1NDMyMSAgICopCi0gICAgICAoKiAw
YjB4eHh4eHh4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICop
Ci0gICAgICAoKiAwMDAwMDAwMDAwMDAwMHh4eHh4eHggICAqKQotICAgICAg
KCAiXHgwMCIgKCogMGIwMDAwMDAwMCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAqKQotICAgICAgLCAoMGIwMDAwMDAwMDAwMDAwMDAwMDAw
MDAsIDEpCi0gICAgICApCi0gICAgOyAoICJceDdmIiAoKiAwYjAxMTExMTEx
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICopCi0gICAgICAs
ICgwYjAwMDAwMDAwMDAwMDAwMTExMTExMSwgMSkKLSAgICAgICkKLSAgICA7
ICgqICAgICAgICAgICAxMDk4NzY1NDMyMSAgICopCi0gICAgICAoKiAwYjEx
MHh4eHN4IDBiMTB4eHh4eHggICAgICAgICAgICAgICAgICAgICAgICopCi0g
ICAgICAoKiAwMDAwMDAwMDAweHh4c3h4eHh4eHggICAqKQotICAgICAgKCAi
XHhjMlx4ODAiICgqIDBiMTEwMDAwMTAgMGIxMDAwMDAwMCAgICAgICAgICAg
ICAgICAgICAgICAgKikKLSAgICAgICwgKDBiMDAwMDAwMDAwMDAwMDEwMDAw
MDAwLCAyKQotICAgICAgKQotICAgIDsgKCAiXHhkZlx4YmYiICgqIDBiMTEw
MTExMTEgMGIxMDExMTExMSAgICAgICAgICAgICAgICAgICAgICAgKikKLSAg
ICAgICwgKDBiMDAwMDAwMDAwMDExMTExMTExMTExLCAyKQotICAgICAgKQot
ICAgIDsgKCogICAgICA2NTQzMjEwOTg3NjU0MzIxICAgKikKLSAgICAgICgq
IDBiMTExMHh4eHggMGIxMHN4eHh4eCAwYjEweHh4eHh4ICAgICAgICAgICAg
KikKLSAgICAgICgqICAgICAgeHh4eHN4eHh4eHh4eHh4eCAgICopCi0gICAg
ICAoICJceGUwXHhhMFx4ODAiICgqIDBiMTExMDAwMDAgMGIxMDEwMDAwMCAw
YjEwMDAwMDAwICAgICAgICAgICAgKikKLSAgICAgICwgKDBiMDAwMDAwMDAw
MTAwMDAwMDAwMDAwLCAzKQotICAgICAgKQotICAgIDsgKCAiXHhlZlx4YmZc
eGJmIiAoKiAwYjExMTAxMTExIDBiMTAxMTExMTEgMGIxMDExMTExMSAgICAg
ICAgICAgICopCi0gICAgICAsICgwYjAwMDAwMTExMTExMTExMTExMTExMSwg
MykKLSAgICAgICkKLSAgICA7ICgqIDEwOTg3NjU0MzIxMDk4NzY1NDMyMSAg
ICopCi0gICAgICAoKiAwYjExMTEweHh4IDBiMTB4c3h4eHggMGIxMHh4eHh4
eCAwYjEweHh4eHh4ICopCi0gICAgICAoKiB4eHh4c3h4eHh4eHh4eHh4eHh4
eHggICAqKQotICAgICAgKCAiXHhmMFx4OTBceDgwXHg4MCIgKCogMGIxMTEx
MDAwMCAwYjEwMDEwMDAwIDBiMTAwMDAwMDAgMGIxMDAwMDAwMCAqKQotICAg
ICAgLCAoMGIwMDAwMTAwMDAwMDAwMDAwMDAwMDAsIDQpCi0gICAgICApCi0g
ICAgOyAoICJceGY3XHhiZlx4YmZceGJmIiAoKiAwYjExMTEwMTExIDBiMTAx
MTExMTEgMGIxMDExMTExMSAwYjEwMTExMTExICopCi0gICAgICAsICgwYjEx
MTExMTExMTExMTExMTExMTExMSwgNCkKLSAgICAgICkKLSAgICBdCi0KLSAg
bGV0IHVjaGFyID0gQWxjb3Rlc3QuaW50Ci0KLSAgbGV0IHRlc3RfZGVjb2Rl
X2NoYXJhY3Rlcl93aGVuX3ZhbGlkICgpID0KLSAgICBMaXN0Lml0ZXIKLSAg
ICAgIChmdW4gKHN0cmluZywgKHZhbHVlLCB3aWR0aCkpIC0+Ci0gICAgICAg
IEFsY290ZXN0LihjaGVjayAocGFpciB1Y2hhciBpbnQpKQotICAgICAgICAg
ICJzYW1lIHBhaXIiCi0gICAgICAgICAgKExlbmllbnRfVVRGOF9jb2RlYy5k
ZWNvZGVfY2hhcmFjdGVyIHN0cmluZyAwKQotICAgICAgICAgICh2YWx1ZSwg
d2lkdGgpCi0gICAgICApCi0gICAgICB2YWxpZF9jaGFyYWN0ZXJfZGVjb2Rp
bmdzCi0KLSAgKCoqIEEgbGlzdCBvZiBzdHJpbmdzIGNvbnRhaW5pbmcgb3Zl
cmxvbmcgY2hhcmFjdGVyIGVuY29kaW5ncy4KLSAgICAgIEZvciBlYWNoIGJ5
dGUgbGVuZ3RoIGIgaW4gWzIuLi40XSwgdGhpcyBsaXN0IGNvbnRhaW5zIHRo
ZQotICAgICAgb3ZlcmxvbmcgZW5jb2RpbmcgZSAodiksIHdoZXJlIHYgaXMg
dGhlIFVDUyB2YWx1ZSBvbmUgbGVzcwotICAgICAgdGhhbiB0aGUgc21hbGxl
c3QgVUNTIHZhbHVlIHZhbGlkbHktZW5jb2RhYmxlIGluIGIgYnl0ZXMuICop
Ci0gIGxldCBvdmVybG9uZ19jaGFyYWN0ZXJfZW5jb2RpbmdzID0KLSAgICBb
Ci0gICAgICAiXHhjMVx4YmYiICgqIDBiMTEwMDAwMDEgMGIxMDExMTExMSAg
ICAgICAgICAgICAgICAgICAgICAgKikKLSAgICA7ICJceGUwXHg5Zlx4YmYi
ICgqIDBiMTExMDAwMDAgMGIxMDAxMTExMSAwYjEwMTExMTExICAgICAgICAg
ICAgKikKLSAgICA7ICJceGYwXHg4Zlx4YmZceGJmIiAoKiAwYjExMTEwMDAw
IDBiMTAwMDExMTEgMGIxMDExMTExMSAwYjEwMTExMTExICopCi0gICAgXQot
Ci0gIGxldCB0ZXN0X2RlY29kZV9jaGFyYWN0ZXJfd2hlbl9vdmVybG9uZyAo
KSA9Ci0gICAgTGlzdC5pdGVyCi0gICAgICAoZnVuIHN0cmluZyAtPgotICAg
ICAgICBBbGNvdGVzdC5jaGVja19yYWlzZXMgInNob3VsZCBmYWlsIiBFLlVU
RjhfZW5jb2Rpbmdfbm90X2Nhbm9uaWNhbAotICAgICAgICAgIChmdW4gKCkg
LT4gTGVuaWVudF9VVEY4X2NvZGVjLmRlY29kZV9jaGFyYWN0ZXIgc3RyaW5n
IDAgfD4gaWdub3JlCi0gICAgICAgICkKLSAgICAgICkKLSAgICAgIG92ZXJs
b25nX2NoYXJhY3Rlcl9lbmNvZGluZ3MKLQotICBsZXQgdGVzdHMgPQotICAg
IFsKLSAgICAgICggInRlc3Rfd2lkdGhfcmVxdWlyZWRfZm9yX3Vjc192YWx1
ZSIKLSAgICAgICwgYFF1aWNrCi0gICAgICAsIHRlc3Rfd2lkdGhfcmVxdWly
ZWRfZm9yX3Vjc192YWx1ZQotICAgICAgKQotICAgIDsgKCAidGVzdF9kZWNv
ZGVfY2hhcmFjdGVyX3doZW5fdmFsaWQiCi0gICAgICAsIGBRdWljawotICAg
ICAgLCB0ZXN0X2RlY29kZV9jaGFyYWN0ZXJfd2hlbl92YWxpZAotICAgICAg
KQotICAgIDsgKCAidGVzdF9kZWNvZGVfY2hhcmFjdGVyX3doZW5fb3Zlcmxv
bmciCi0gICAgICAsIGBRdWljawotICAgICAgLCB0ZXN0X2RlY29kZV9jaGFy
YWN0ZXJfd2hlbl9vdmVybG9uZwotICAgICAgKQotICAgIF0KLWVuZAotCi1s
ZXQgKCkgPQotICBBbGNvdGVzdC5ydW4gIkVuY29kaW5ncyIKLSAgICBbCi0g
ICAgICAoIlVDUyIsIFVDUy50ZXN0cykKLSAgICA7ICgiWE1MIiwgWE1MLnRl
c3RzKQotICAgIDsgKCJTdHJpbmdfdmFsaWRhdG9yIiwgU3RyaW5nX3ZhbGlk
YXRvci50ZXN0cykKLSAgICA7ICgiWE1MX1VURjhfVUNTX3ZhbGlkYXRvciIs
IFhNTF9VVEY4X1VDU192YWxpZGF0b3IudGVzdHMpCi0gICAgOyAoIlVURjhf
Y29kZWMiLCBVVEY4X2NvZGVjLnRlc3RzKQotICAgIF0KZGlmZiAtLWdpdCBh
L29jYW1sL2xpYnMveGFwaS1zdGRleHQvbGliL3hhcGktc3RkZXh0LWVuY29k
aW5ncy91dGY4Lm1sIGIvb2NhbWwvbGlicy94YXBpLXN0ZGV4dC9saWIveGFw
aS1zdGRleHQtZW5jb2RpbmdzL3V0ZjgubWwKbmV3IGZpbGUgbW9kZSAxMDA2
NDQKaW5kZXggMDAwMDAwMDAwLi5kMTdkODViM2IKLS0tIC9kZXYvbnVsbAor
KysgYi9vY2FtbC9saWJzL3hhcGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1l
bmNvZGluZ3MvdXRmOC5tbApAQCAtMCwwICsxLDc0IEBACisoKgorICogQ29w
eXJpZ2h0IChjKSBDbG91ZCBTb2Z0d2FyZSBHcm91cCwgSW5jLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlz
dHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBh
cyBwdWJsaXNoZWQKKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b247IHZlcnNpb24gMi4xIG9ubHkuIHdpdGggdGhlIHNwZWNpYWwKKyAqIGV4
Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBmaWxlIExJQ0VOU0Uu
CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBo
b3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50
eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFS
VElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIExlc3NlciBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKikKKwor
bGV0IGlzX3ZhbGlkID0gU3RyaW5nLmlzX3ZhbGlkX3V0Zl84CisKKygqIGRl
cHJlY2F0ZWQgLSByZWplY3QgaW52YWxpZCBVVEYtOCAqKQorbGV0IGxvbmdl
c3RfdmFsaWRfcHJlZml4IHN0ciA9CisgIGxldCBsZW4gPSBTdHJpbmcubGVu
Z3RoIHN0ciBpbgorICBsZXQgcmVjIGxvb3AgPSBmdW5jdGlvbgorICAgIHwg
aSB3aGVuIGkgPCBsZW4gLT4KKyAgICAgICAgbGV0IGRlYyA9IFN0cmluZy5n
ZXRfdXRmXzhfdWNoYXIgc3RyIGkgaW4KKyAgICAgICAgaWYgVWNoYXIudXRm
X2RlY29kZV9pc192YWxpZCBkZWMgdGhlbgorICAgICAgICAgIGxvb3AgKGkg
KyBVY2hhci51dGZfZGVjb2RlX2xlbmd0aCBkZWMpCisgICAgICAgIGVsc2UK
KyAgICAgICAgICBTdHJpbmcuc3ViIHN0ciAwIGkKKyAgICB8IGkgd2hlbiBp
ID0gbGVuIC0+CisgICAgICAgIHN0cgorICAgIHwgaSAtPgorICAgICAgICBT
dHJpbmcuc3ViIHN0ciAwIGkgKCogbmV2ZXIgcmVhY2hlZCAqKQorICBpbgor
ICBsb29wIDAKKworbW9kdWxlIFhNTCA9IHN0cnVjdAorICAoKiogc29tZSBV
VEYtOCBjaGFyYWN0ZXJzIGFyZSBub3QgbGVnYWwgaW4gWE1MLiBBc3N1bWlu
ZyB1Y2hhciBpcworICAgICAgbGVnYWwgVVRGLTgsIGZ1cnRoZXIgY2hlY2sg
dGhhdCBpdCBpcyBsZWdhbCBpbiBYTUwgKikKKyAgbGV0IGlzX2xlZ2FsIHVj
aGFyID0KKyAgICBsZXQgdWNoYXIgPSBVY2hhci50b19pbnQgdWNoYXIgaW4K
KyAgICB1Y2hhciA+PSAweDIwIHx8IHVjaGFyID0gMHgwOSB8fCB1Y2hhciA9
IDB4MGEgfHwgdWNoYXIgPSAweDBkCisgIFtAQGlubGluZV0KKworICBsZXQg
aXNfdmFsaWQgc3RyID0KKyAgICBsZXQgbGVuID0gU3RyaW5nLmxlbmd0aCBz
dHIgaW4KKyAgICBsZXQgcmVjIGxvb3AgPSBmdW5jdGlvbgorICAgICAgfCBp
IHdoZW4gaSA8IGxlbiAtPgorICAgICAgICAgIGxldCBkZWMgPSBTdHJpbmcu
Z2V0X3V0Zl84X3VjaGFyIHN0ciBpIGluCisgICAgICAgICAgVWNoYXIudXRm
X2RlY29kZV9pc192YWxpZCBkZWMKKyAgICAgICAgICAmJiBpc19sZWdhbCAo
VWNoYXIudXRmX2RlY29kZV91Y2hhciBkZWMpCisgICAgICAgICAgJiYgbG9v
cCAoaSArIFVjaGFyLnV0Zl9kZWNvZGVfbGVuZ3RoIGRlYykKKyAgICAgIHwg
XyAtPgorICAgICAgICAgIHRydWUKKyAgICBpbgorICAgIGxvb3AgMAorCisg
ICgqIGRlcHJlY2F0ZWQgLSByZWplY3QgaW52YWxpZCBVVEYtOCAqKQorICBs
ZXQgbG9uZ2VzdF92YWxpZF9wcmVmaXggc3RyID0KKyAgICBsZXQgbGVuID0g
U3RyaW5nLmxlbmd0aCBzdHIgaW4KKyAgICBsZXQgcmVjIGxvb3AgPSBmdW5j
dGlvbgorICAgICAgfCBpIHdoZW4gaSA8IGxlbiAtPgorICAgICAgICAgIGxl
dCBkZWMgPSBTdHJpbmcuZ2V0X3V0Zl84X3VjaGFyIHN0ciBpIGluCisgICAg
ICAgICAgaWYKKyAgICAgICAgICAgIFVjaGFyLnV0Zl9kZWNvZGVfaXNfdmFs
aWQgZGVjCisgICAgICAgICAgICAmJiBpc19sZWdhbCAoVWNoYXIudXRmX2Rl
Y29kZV91Y2hhciBkZWMpCisgICAgICAgICAgdGhlbgorICAgICAgICAgICAg
bG9vcCAoaSArIFVjaGFyLnV0Zl9kZWNvZGVfbGVuZ3RoIGRlYykKKyAgICAg
ICAgICBlbHNlCisgICAgICAgICAgICBTdHJpbmcuc3ViIHN0ciAwIGkKKyAg
ICAgIHwgaSB3aGVuIGkgPSBsZW4gLT4KKyAgICAgICAgICBzdHIgKCogYXZv
aWQgY29weSAqKQorICAgICAgfCBpIC0+CisgICAgICAgICAgU3RyaW5nLnN1
YiBzdHIgMCBpICgqIG5ldmVyIHJlYWNoZWQgKikKKyAgICBpbgorICAgIGxv
b3AgMAorZW5kCmRpZmYgLS1naXQgYS9vY2FtbC9saWJzL3hhcGktc3RkZXh0
L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3MvdXRmOC5tbGkgYi9vY2FtbC9s
aWJzL3hhcGktc3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3MvdXRm
OC5tbGkKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwLi42
ZDg5NDllMmYKLS0tIC9kZXYvbnVsbAorKysgYi9vY2FtbC9saWJzL3hhcGkt
c3RkZXh0L2xpYi94YXBpLXN0ZGV4dC1lbmNvZGluZ3MvdXRmOC5tbGkKQEAg
LTAsMCArMSwzMSBAQAorKCoKKyAqIENvcHlyaWdodCAoYykgQ2xvdWQgU29m
dHdhcmUgR3JvdXAsIEluYy4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJl
ZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1v
ZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgTGVzc2Vy
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkCisgKiBieSB0
aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyB2ZXJzaW9uIDIuMSBvbmx5
LiB3aXRoIHRoZSBzcGVjaWFsCisgKiBleGNlcHRpb24gb24gbGlua2luZyBk
ZXNjcmliZWQgaW4gZmlsZSBMSUNFTlNFLgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUg
dXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0
IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNl
ZSB0aGUKKyAqIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBm
b3IgbW9yZSBkZXRhaWxzLgorICopCisKK3ZhbCBpc192YWxpZCA6IHN0cmlu
ZyAtPiBib29sCisoKiogdHJ1ZSwgaWYgYSBzdHJpbmcgaXMgYSBwcm9wZXIg
VVRGLTggc3RyaW5nICopCisKK3ZhbCBsb25nZXN0X3ZhbGlkX3ByZWZpeCA6
IHN0cmluZyAtPiBzdHJpbmcKKygqKiBEZXByZWNhdGVkLiBMb25nZXN0IHBy
ZWZpeCBvZiBhIHN0cmluZyB0aGF0IGlzIHByb3BlciBVVEYtOCAqKQorCiso
KiBzdHJpbmdzIGluIFhNTCBhcmUgbW9yZSByZXN0cmljdGVkIHRoYW4gVVRG
LTggaW4gZ2VuZXJhbC4gVGhlIG11c3QgYmUKKyAgIHZhbGlkIFVURi04IGFu
ZCBtdXN0IG5vdCBjb250YWluIGNlcnRhaW4gY2hhcmFjdGVycyAqKQorCitt
b2R1bGUgWE1MIDogc2lnCisgIHZhbCBpc192YWxpZCA6IHN0cmluZyAtPiBi
b29sCisgICgqKiB0cnVlLCBpZiBhIHN0cmluZyBpcyBhIHByb3BlciBVVEYt
OCBzdHJpbmcgaW4gWE1MICopCisKKyAgdmFsIGxvbmdlc3RfdmFsaWRfcHJl
Zml4IDogc3RyaW5nIC0+IHN0cmluZworICAoKiogRGVwcmVjYXRlZC4gbG9u
Z2VzdCBwcmVmaXggb2YgYSBzdHJpbmcgdGhhdCBpcyBwcm9wZXIgVVRGLTgu
CisgICAgICBCZXR0ZXIgcmVqZWN0IGludmFsaWQgVVRGLTguICopCitlbmQK
ZGlmZiAtLWdpdCBhL29jYW1sL3hhcGkveGFwaV9tZXNzYWdlLm1sIGIvb2Nh
bWwveGFwaS94YXBpX21lc3NhZ2UubWwKaW5kZXggNDA4YmE3YWNmLi40YzA4
NjQ4ZGMgMTAwNjQ0Ci0tLSBhL29jYW1sL3hhcGkveGFwaV9tZXNzYWdlLm1s
CisrKyBiL29jYW1sL3hhcGkveGFwaV9tZXNzYWdlLm1sCkBAIC0yOCw3ICsy
OCw3IEBACiAgKikKIAogbW9kdWxlIERhdGUgPSBDbG9jay5EYXRlCi1tb2R1
bGUgRW5jb2RpbmdzID0gWGFwaV9zdGRleHRfZW5jb2RpbmdzLkVuY29kaW5n
cworbW9kdWxlIEVuY29kaW5ncyA9IFhhcGlfc3RkZXh0X2VuY29kaW5ncwog
bW9kdWxlIExpc3RleHQgPSBYYXBpX3N0ZGV4dF9zdGQuTGlzdGV4dAogbW9k
dWxlIFBlcnZhc2l2ZWV4dCA9IFhhcGlfc3RkZXh0X3BlcnZhc2l2ZXMuUGVy
dmFzaXZlZXh0CiBtb2R1bGUgVW5peGV4dCA9IFhhcGlfc3RkZXh0X3VuaXgu
VW5peGV4dApAQCAtNDE0LDcgKzQxNCw3IEBAIGxldCBjcmVhdGUgfl9fY29u
dGV4dCB+bmFtZSB+cHJpb3JpdHkgfmNscyB+b2JqX3V1aWQgfmJvZHkgPQog
ICBkZWJ1ZyAiTWVzc2FnZS5jcmVhdGUgJXMgJUxkICVzICVzIiBuYW1lIHBy
aW9yaXR5CiAgICAgKFJlY29yZF91dGlsLmNsc190b19zdHJpbmcgY2xzKQog
ICAgIG9ial91dWlkIDsKLSAgaWYgbm90IChFbmNvZGluZ3MuVVRGOF9YTUwu
aXNfdmFsaWQgYm9keSkgdGhlbgorICBpZiBub3QgKEVuY29kaW5ncy5VdGY4
LmlzX3ZhbGlkIGJvZHkpIHRoZW4KICAgICByYWlzZSAoQXBpX2Vycm9ycy5T
ZXJ2ZXJfZXJyb3IgKEFwaV9lcnJvcnMuaW52YWxpZF92YWx1ZSwgWyJVVEY4
IGV4cGVjdGVkIl0pKSA7CiAgIGlmIG5vdCAoY2hlY2tfdXVpZCB+X19jb250
ZXh0IH5jbHMgfnV1aWQ6b2JqX3V1aWQpIHRoZW4KICAgICByYWlzZQo=

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116767.1463010 (Exim 4.92)
	(envelope-from )
	id 1uvyOU-0005uZ-5Z; Tue, 09 Sep 2025 13:28:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116767.1463010; Tue, 09 Sep 2025 13: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 1uvyOU-0005uS-2j; Tue, 09 Sep 2025 13:28:22 +0000
Received: by outflank-mailman (input) for mailman id 1116767;
 Tue, 09 Sep 2025 13:28:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvyOS-0005uM-Ji
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:20 +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 d81341b1-8d80-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:28:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id CBC5340951;
 Tue,  9 Sep 2025 13:28:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06301C4CEF4;
 Tue,  9 Sep 2025 13:28: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: d81341b1-8d80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424495;
	bh=4Kp6x0JSqX0slJB3ko5gRb1MmNBDdg5wnGscFkyjE2Y=;
	h=From:To:Cc:Subject:Date:From;
	b=fdb2HzReI50PZxO4MtzTlQzMUmIPNsId/eyqchj5xq6lrQ+njXuothnH6ox2KFWeg
	 Pig6E0g5m+KtNmnqkOJsk5hVZD5EzndXl5JM5PtfJqxvRhWT2nxJ8qOPZHQ2Zk5vSm
	 hjiXORu2mJvDfOxyK0zhuwFVDHho9JsG9Y1F0WD/fRg3CSXDPAUlijyJFrxE3LLi2j
	 SOfVx4izw+hJqGavvnWRCV6fQbNYft+6mURTgKfF7e8OEjs7s7bEqYTlYKR3y6ZD5D
	 USU+zYf9+5pw17PdePh0uV6Xx55Pd1LZB6owTlIpMPrDjk4SjIlxeQea0fHRhF/4jF
	 qN1Cp9bFLJoqA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 00/16] dma-mapping: migrate to physical address-based API
Date: Tue,  9 Sep 2025 16:27:28 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Changelog:
v6:
 * Based on "dma-debug: don't enforce dma mapping check on noncoherent
   allocations" patch.
 * Removed some unused variables from kmsan conversion.
 * Fixed missed ! in dma check.
v5: https://lore.kernel.org/all/cover.1756822782.git.leon@kernel.org
 * Added Jason's and Keith's Reviewed-by tags
 * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys
 * Jason's cleanup suggestions
v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/
 * Fixed kbuild error with mismatch in kmsan function declaration due to
   rebase error.
v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org
 * Fixed typo in "cacheable" word
 * Simplified kmsan patch a lot to be simple argument refactoring
v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org
 * Used commit messages and cover letter from Jason
 * Moved setting IOMMU_MMIO flag to dma_info_to_prot function
 * Micro-optimized the code
 * Rebased code on v6.17-rc1
v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org
 * Added new DMA_ATTR_MMIO attribute to indicate
   PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
 * Rewrote dma_map_* functions to use thus new attribute
v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/
------------------------------------------------------------------------

This series refactors the DMA mapping to use physical addresses
as the primary interface instead of page+offset parameters. This
change aligns the DMA API with the underlying hardware reality where
DMA operations work with physical addresses, not page structures.

The series maintains export symbol backward compatibility by keeping
the old page-based API as wrapper functions around the new physical
address-based implementations.

This series refactors the DMA mapping API to provide a phys_addr_t
based, and struct-page free, external API that can handle all the
mapping cases we want in modern systems:

 - struct page based cacheable DRAM
 - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable
   MMIO
 - struct page-less PCI peer to peer non-cacheable MMIO
 - struct page-less "resource" MMIO

Overall this gets much closer to Matthew's long term wish for
struct-pageless IO to cacheable DRAM. The remaining primary work would
be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on
phys_addr_t without a struct page.

The general design is to remove struct page usage entirely from the
DMA API inner layers. For flows that need to have a KVA for the
physical address they can use kmap_local_pfn() or phys_to_virt(). This
isolates the struct page requirements to MM code only. Long term all
removals of struct page usage are supporting Matthew's memdesc
project which seeks to substantially transform how struct page works.

Instead make the DMA API internals work on phys_addr_t. Internally
there are still dedicated 'page' and 'resource' flows, except they are
now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both
flows use the same phys_addr_t.

When DMA_ATTR_MMIO is specified things work similar to the existing
'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(),
pfn_valid(), etc are never called on the phys_addr_t. This requires
rejecting any configuration that would need swiotlb. CPU cache
flushing is not required, and avoided, as ATTR_MMIO also indicates the
address have no cacheable mappings. This effectively removes any
DMA API side requirement to have struct page when DMA_ATTR_MMIO is
used.

In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow,
except on the common path of no cache flush, no swiotlb it never
touches a struct page. When cache flushing or swiotlb copying
kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU
usage. This was already the case on the unmap side, now the map side
is symmetric.

Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users
must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA
path must also set it. This corrects some existing bugs where iommu
mappings for P2P MMIO were improperly marked IOMMU_CACHE.

Since ATTR_MMIO is made to work with all the existing DMA map entry
points, particularly dma_iova_link(), this finally allows a way to use
the new DMA API to map PCI P2P MMIO without creating struct page. The
VFIO DMABUF series demonstrates how this works. This is intended to
replace the incorrect driver use of dma_map_resource() on PCI BAR
addresses.

This series does the core code and modern flows. A followup series
will give the same treatment to the legacy dma_ops implementation.

Thanks

Leon Romanovsky (16):
  dma-mapping: introduce new DMA attribute to indicate MMIO memory
  iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link().
  dma-debug: refactor to use physical addresses for page mapping
  dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys
  iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys
  iommu/dma: implement DMA_ATTR_MMIO for iommu_dma_(un)map_phys()
  dma-mapping: convert dma_direct_*map_page to be phys_addr_t based
  kmsan: convert kmsan_handle_dma to use physical addresses
  dma-mapping: implement DMA_ATTR_MMIO for dma_(un)map_page_attrs()
  xen: swiotlb: Open code map_resource callback
  dma-mapping: export new dma_*map_phys() interface
  mm/hmm: migrate to physical address-based DMA mapping API
  mm/hmm: properly take MMIO path
  block-dma: migrate to dma_map_phys instead of map_page
  block-dma: properly take MMIO path
  nvme-pci: unmap MMIO pages with appropriate interface

 Documentation/core-api/dma-api.rst        |   4 +-
 Documentation/core-api/dma-attributes.rst |  18 ++++
 arch/powerpc/kernel/dma-iommu.c           |   4 +-
 block/blk-mq-dma.c                        |  15 ++-
 drivers/iommu/dma-iommu.c                 |  61 ++++++------
 drivers/nvme/host/pci.c                   |  18 +++-
 drivers/virtio/virtio_ring.c              |   4 +-
 drivers/xen/swiotlb-xen.c                 |  21 +++-
 include/linux/blk-mq-dma.h                |   6 +-
 include/linux/blk_types.h                 |   2 +
 include/linux/dma-direct.h                |   2 -
 include/linux/dma-map-ops.h               |   8 +-
 include/linux/dma-mapping.h               |  33 +++++++
 include/linux/iommu-dma.h                 |  11 +--
 include/linux/kmsan.h                     |   9 +-
 include/linux/page-flags.h                |   1 +
 include/trace/events/dma.h                |   9 +-
 kernel/dma/debug.c                        |  82 ++++------------
 kernel/dma/debug.h                        |  37 ++-----
 kernel/dma/direct.c                       |  22 +----
 kernel/dma/direct.h                       |  57 +++++++----
 kernel/dma/mapping.c                      | 112 +++++++++++++---------
 kernel/dma/ops_helpers.c                  |   6 +-
 mm/hmm.c                                  |  19 ++--
 mm/kmsan/hooks.c                          |  10 +-
 rust/kernel/dma.rs                        |   3 +
 tools/virtio/linux/kmsan.h                |   2 +-
 27 files changed, 312 insertions(+), 264 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116770.1463041 (Exim 4.92)
	(envelope-from )
	id 1uvyOd-0006du-0y; Tue, 09 Sep 2025 13:28:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116770.1463041; Tue, 09 Sep 2025 13:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyOc-0006dj-UE; Tue, 09 Sep 2025 13:28:30 +0000
Received: by outflank-mailman (input) for mailman id 1116770;
 Tue, 09 Sep 2025 13:28: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 1uvyOc-0005uM-Gp
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:30 +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 de8c3233-8d80-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:28: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 7FBE744D02;
 Tue,  9 Sep 2025 13:28:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5E1DC4CEF5;
 Tue,  9 Sep 2025 13:28: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: de8c3233-8d80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424507;
	bh=m/3FWvMEP+/8V652buMynLIdEwgRPi43wgZz18MTj3M=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=J1woyVLhqM3siMNPivivEJv4VNv9s6uNc0piiXttUtdg0DDgKmV0YSZ8iAFwn4Alr
	 i3+qMLsfuJ9iNwKrXrEh3Gws4/K2iEAToxhQNQRXHpqnn6JdhSO4dpZT934lxzQik/
	 O7NdvZ5UQ9AQqZA3NGDNaMt/iPOjxHoruIxaXyeL+Muz472ygrFNWUvBi2XbazYeKs
	 f6ctLEh0WQXu5o3Q7G7BI3TeRYALJWhN1JAzf58uBQBm+HT/TLHbHonKigOdYlr4LE
	 wORVtoiGviO3dG7x+I9o7DQ7kX+JtTcYcgSvq5O39pFQ72XF5HX25y58wNQqXX7NAx
	 AVQmxHiCRj5Sw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 04/16] dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys
Date: Tue,  9 Sep 2025 16:27:32 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

As a preparation for following map_page -> map_phys API conversion,
let's rename trace_dma_*map_page() to be trace_dma_*map_phys().

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 include/trace/events/dma.h | 4 ++--
 kernel/dma/mapping.c       | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h
index ee90d6f1dcf35..84416c7d6bfaa 100644
--- a/include/trace/events/dma.h
+++ b/include/trace/events/dma.h
@@ -72,7 +72,7 @@ DEFINE_EVENT(dma_map, name, \
 		 size_t size, enum dma_data_direction dir, unsigned long attrs), \
 	TP_ARGS(dev, phys_addr, dma_addr, size, dir, attrs))
 
-DEFINE_MAP_EVENT(dma_map_page);
+DEFINE_MAP_EVENT(dma_map_phys);
 DEFINE_MAP_EVENT(dma_map_resource);
 
 DECLARE_EVENT_CLASS(dma_unmap,
@@ -110,7 +110,7 @@ DEFINE_EVENT(dma_unmap, name, \
 		 enum dma_data_direction dir, unsigned long attrs), \
 	TP_ARGS(dev, addr, size, dir, attrs))
 
-DEFINE_UNMAP_EVENT(dma_unmap_page);
+DEFINE_UNMAP_EVENT(dma_unmap_phys);
 DEFINE_UNMAP_EVENT(dma_unmap_resource);
 
 DECLARE_EVENT_CLASS(dma_alloc_class,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 0b7e16c69bf18..bd3bb6d59d722 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -173,7 +173,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 	else
 		addr = ops->map_page(dev, page, offset, size, dir, attrs);
 	kmsan_handle_dma(page, offset, size, dir);
-	trace_dma_map_page(dev, phys, addr, size, dir, attrs);
+	trace_dma_map_phys(dev, phys, addr, size, dir, attrs);
 	debug_dma_map_phys(dev, phys, size, dir, addr, attrs);
 
 	return addr;
@@ -193,7 +193,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 		iommu_dma_unmap_page(dev, addr, size, dir, attrs);
 	else
 		ops->unmap_page(dev, addr, size, dir, attrs);
-	trace_dma_unmap_page(dev, addr, size, dir, attrs);
+	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
 	debug_dma_unmap_phys(dev, addr, size, dir);
 }
 EXPORT_SYMBOL(dma_unmap_page_attrs);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116769.1463030 (Exim 4.92)
	(envelope-from )
	id 1uvyOb-0006On-IQ; Tue, 09 Sep 2025 13:28:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116769.1463030; Tue, 09 Sep 2025 13:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyOb-0006Og-Fl; Tue, 09 Sep 2025 13:28:29 +0000
Received: by outflank-mailman (input) for mailman id 1116769;
 Tue, 09 Sep 2025 13:28: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 1uvyOZ-0005uM-Uk
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:27 +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 dcf99a0c-8d80-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:28:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 2600A6021E;
 Tue,  9 Sep 2025 13:28:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DD48C4CEF4;
 Tue,  9 Sep 2025 13:28: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: dcf99a0c-8d80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424503;
	bh=LmA+5r2y6XpziEWAZNosju3G43mU5TfGKzS41p72Fok=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Ke4hsb0oLTPfHFWhWc4Tu1uf9YsEMIjSIvc5uG8GeGq7ZrmKRs3eEH4x3/XNxE63q
	 I8P3KLAOWemasIp0/JtzEJjq0Gq5BYdlQLtKtP7S8q66J0I6u6sMvYCPpEm6ssKVHY
	 90pjKxcoblQIxpLEvhej/ET5tEF4zRv9Dz0M2UyhkraPqoG9mxB04L+fZcESm7IsLy
	 2jgLMxUISDXt6aaaYuGkkb3kCJv07RaaXvA2RVy6VT5TlYk78Kn+irOXgEBcpDaxXd
	 hHkLj0RlB2AXvc+crVg3gfw2gatuw+pcwILlr/cKNJxEnGOaOvYDOa3vyXqxCn7N3p
	 bFUN02wQ98k0Q==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 03/16] dma-debug: refactor to use physical addresses for page mapping
Date: Tue,  9 Sep 2025 16:27:31 +0300
Message-ID: <56d1a6769b68dfcbf8b26a75a7329aeb8e3c3b6a.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Convert the DMA debug infrastructure from page-based to physical address-based
mapping as a preparation to rely on physical address for DMA mapping routines.

The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and
changes its signature to accept a phys_addr_t parameter instead of struct page
and offset. Similarly, debug_dma_unmap_page() becomes debug_dma_unmap_phys().
A new dma_debug_phy type is introduced to distinguish physical address mappings
from other debug entry types. All callers throughout the codebase are updated
to pass physical addresses directly, eliminating the need for page-to-physical
conversion in the debug layer.

This refactoring eliminates the need to convert between page pointers and
physical addresses in the debug layer, making the code more efficient and
consistent with the DMA mapping API's physical address focus.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 Documentation/core-api/dma-api.rst |  4 +--
 include/linux/page-flags.h         |  1 +
 kernel/dma/debug.c                 | 39 +++++++++++++++---------------
 kernel/dma/debug.h                 | 16 ++++++------
 kernel/dma/mapping.c               | 10 ++++----
 5 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst
index 3087bea715ed2..ca75b35416792 100644
--- a/Documentation/core-api/dma-api.rst
+++ b/Documentation/core-api/dma-api.rst
@@ -761,7 +761,7 @@ example warning message may look like this::
 	[] find_busiest_group+0x207/0x8a0
 	[] _spin_lock_irqsave+0x1f/0x50
 	[] check_unmap+0x203/0x490
-	[] debug_dma_unmap_page+0x49/0x50
+	[] debug_dma_unmap_phys+0x49/0x50
 	[] nv_tx_done_optimized+0xc6/0x2c0
 	[] nv_nic_irq_optimized+0x73/0x2b0
 	[] handle_IRQ_event+0x34/0x70
@@ -855,7 +855,7 @@ that a driver may be leaking mappings.
 dma-debug interface debug_dma_mapping_error() to debug drivers that fail
 to check DMA mapping errors on addresses returned by dma_map_single() and
 dma_map_page() interfaces. This interface clears a flag set by
-debug_dma_map_page() to indicate that dma_mapping_error() has been called by
+debug_dma_map_phys() to indicate that dma_mapping_error() has been called by
 the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
 this flag is still set, prints warning message that includes call trace that
 leads up to the unmap. This interface can be called from dma_mapping_error()
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 8d3fa3a91ce47..dfbc4ba86bba2 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -614,6 +614,7 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
  * available at this point.
  */
 #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
+#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
 #define folio_test_highmem(__f)	is_highmem_idx(folio_zonenum(__f))
 #else
 PAGEFLAG_FALSE(HighMem, highmem)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index b82399437db03..b275db9ca6a03 100644
--- a/kernel/dma/debug.c
+++ b/kernel/dma/debug.c
@@ -40,6 +40,7 @@ enum {
 	dma_debug_coherent,
 	dma_debug_resource,
 	dma_debug_noncoherent,
+	dma_debug_phy,
 };
 
 enum map_err_types {
@@ -143,6 +144,7 @@ static const char *type2name[] = {
 	[dma_debug_coherent] = "coherent",
 	[dma_debug_resource] = "resource",
 	[dma_debug_noncoherent] = "noncoherent",
+	[dma_debug_phy] = "phy",
 };
 
 static const char *dir2name[] = {
@@ -1054,17 +1056,16 @@ static void check_unmap(struct dma_debug_entry *ref)
 	dma_entry_free(entry);
 }
 
-static void check_for_stack(struct device *dev,
-			    struct page *page, size_t offset)
+static void check_for_stack(struct device *dev, phys_addr_t phys)
 {
 	void *addr;
 	struct vm_struct *stack_vm_area = task_stack_vm_area(current);
 
 	if (!stack_vm_area) {
 		/* Stack is direct-mapped. */
-		if (PageHighMem(page))
+		if (PhysHighMem(phys))
 			return;
-		addr = page_address(page) + offset;
+		addr = phys_to_virt(phys);
 		if (object_is_on_stack(addr))
 			err_printk(dev, NULL, "device driver maps memory from stack [addr=%p]\n", addr);
 	} else {
@@ -1072,10 +1073,12 @@ static void check_for_stack(struct device *dev,
 		int i;
 
 		for (i = 0; i < stack_vm_area->nr_pages; i++) {
-			if (page != stack_vm_area->pages[i])
+			if (__phys_to_pfn(phys) !=
+			    page_to_pfn(stack_vm_area->pages[i]))
 				continue;
 
-			addr = (u8 *)current->stack + i * PAGE_SIZE + offset;
+			addr = (u8 *)current->stack + i * PAGE_SIZE +
+			       (phys % PAGE_SIZE);
 			err_printk(dev, NULL, "device driver maps memory from stack [probable addr=%p]\n", addr);
 			break;
 		}
@@ -1204,9 +1207,8 @@ void debug_dma_map_single(struct device *dev, const void *addr,
 }
 EXPORT_SYMBOL(debug_dma_map_single);
 
-void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
-			size_t size, int direction, dma_addr_t dma_addr,
-			unsigned long attrs)
+void debug_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		int direction, dma_addr_t dma_addr, unsigned long attrs)
 {
 	struct dma_debug_entry *entry;
 
@@ -1221,19 +1223,18 @@ void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
 		return;
 
 	entry->dev       = dev;
-	entry->type      = dma_debug_single;
-	entry->paddr	 = page_to_phys(page) + offset;
+	entry->type      = dma_debug_phy;
+	entry->paddr	 = phys;
 	entry->dev_addr  = dma_addr;
 	entry->size      = size;
 	entry->direction = direction;
 	entry->map_err_type = MAP_ERR_NOT_CHECKED;
 
-	check_for_stack(dev, page, offset);
+	if (!(attrs & DMA_ATTR_MMIO)) {
+		check_for_stack(dev, phys);
 
-	if (!PageHighMem(page)) {
-		void *addr = page_address(page) + offset;
-
-		check_for_illegal_area(dev, addr, size);
+		if (!PhysHighMem(phys))
+			check_for_illegal_area(dev, phys_to_virt(phys), size);
 	}
 
 	add_dma_entry(entry, attrs);
@@ -1277,11 +1278,11 @@ void debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
 }
 EXPORT_SYMBOL(debug_dma_mapping_error);
 
-void debug_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
+void debug_dma_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 			  size_t size, int direction)
 {
 	struct dma_debug_entry ref = {
-		.type           = dma_debug_single,
+		.type           = dma_debug_phy,
 		.dev            = dev,
 		.dev_addr       = dma_addr,
 		.size           = size,
@@ -1305,7 +1306,7 @@ void debug_dma_map_sg(struct device *dev, struct scatterlist *sg,
 		return;
 
 	for_each_sg(sg, s, nents, i) {
-		check_for_stack(dev, sg_page(s), s->offset);
+		check_for_stack(dev, sg_phys(s));
 		if (!PageHighMem(sg_page(s)))
 			check_for_illegal_area(dev, sg_virt(s), s->length);
 	}
diff --git a/kernel/dma/debug.h b/kernel/dma/debug.h
index 48757ca13f314..bedae973e725d 100644
--- a/kernel/dma/debug.h
+++ b/kernel/dma/debug.h
@@ -9,12 +9,11 @@
 #define _KERNEL_DMA_DEBUG_H
 
 #ifdef CONFIG_DMA_API_DEBUG
-extern void debug_dma_map_page(struct device *dev, struct page *page,
-			       size_t offset, size_t size,
-			       int direction, dma_addr_t dma_addr,
+extern void debug_dma_map_phys(struct device *dev, phys_addr_t phys,
+			       size_t size, int direction, dma_addr_t dma_addr,
 			       unsigned long attrs);
 
-extern void debug_dma_unmap_page(struct device *dev, dma_addr_t addr,
+extern void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr,
 				 size_t size, int direction);
 
 extern void debug_dma_map_sg(struct device *dev, struct scatterlist *sg,
@@ -62,14 +61,13 @@ extern void debug_dma_free_pages(struct device *dev, struct page *page,
 				 size_t size, int direction,
 				 dma_addr_t dma_addr);
 #else /* CONFIG_DMA_API_DEBUG */
-static inline void debug_dma_map_page(struct device *dev, struct page *page,
-				      size_t offset, size_t size,
-				      int direction, dma_addr_t dma_addr,
-				      unsigned long attrs)
+static inline void debug_dma_map_phys(struct device *dev, phys_addr_t phys,
+				      size_t size, int direction,
+				      dma_addr_t dma_addr, unsigned long attrs)
 {
 }
 
-static inline void debug_dma_unmap_page(struct device *dev, dma_addr_t addr,
+static inline void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr,
 					size_t size, int direction)
 {
 }
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 56de28a3b1799..0b7e16c69bf18 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -157,6 +157,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		unsigned long attrs)
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
+	phys_addr_t phys = page_to_phys(page) + offset;
 	dma_addr_t addr;
 
 	BUG_ON(!valid_dma_direction(dir));
@@ -165,16 +166,15 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		return DMA_MAPPING_ERROR;
 
 	if (dma_map_direct(dev, ops) ||
-	    arch_dma_map_page_direct(dev, page_to_phys(page) + offset + size))
+	    arch_dma_map_page_direct(dev, phys + size))
 		addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		addr = iommu_dma_map_page(dev, page, offset, size, dir, attrs);
 	else
 		addr = ops->map_page(dev, page, offset, size, dir, attrs);
 	kmsan_handle_dma(page, offset, size, dir);
-	trace_dma_map_page(dev, page_to_phys(page) + offset, addr, size, dir,
-			   attrs);
-	debug_dma_map_page(dev, page, offset, size, dir, addr, attrs);
+	trace_dma_map_page(dev, phys, addr, size, dir, attrs);
+	debug_dma_map_phys(dev, phys, size, dir, addr, attrs);
 
 	return addr;
 }
@@ -194,7 +194,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 	else
 		ops->unmap_page(dev, addr, size, dir, attrs);
 	trace_dma_unmap_page(dev, addr, size, dir, attrs);
-	debug_dma_unmap_page(dev, addr, size, dir);
+	debug_dma_unmap_phys(dev, addr, size, dir);
 }
 EXPORT_SYMBOL(dma_unmap_page_attrs);
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116768.1463021 (Exim 4.92)
	(envelope-from )
	id 1uvyOX-00068M-BY; Tue, 09 Sep 2025 13:28:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116768.1463021; Tue, 09 Sep 2025 13: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 1uvyOX-00068F-8Z; Tue, 09 Sep 2025 13:28:25 +0000
Received: by outflank-mailman (input) for mailman id 1116768;
 Tue, 09 Sep 2025 13:28: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 1uvyOW-00067u-5o
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:24 +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 da3bb63f-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28: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 4F10844976;
 Tue,  9 Sep 2025 13:28:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F41DC4CEF4;
 Tue,  9 Sep 2025 13:28:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: da3bb63f-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424500;
	bh=SsTumAAe1s4B4pTZxHvsqOUAU/t1s79JgZHbKlTSbIo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=W2fAXIdM3SbF0lV91qntmnngT3VSZmIEruQIT17KY+xaUG8amR2RZZ2qhZz8YI6GT
	 FekzkYxHgtVMzFxHyjsHN98zvE/leulRAAGIaKJ8PC6QzVwcF2xi5m2F0HFJvKYy8l
	 Fp4AEq9NoSEAEb9k2dLzs9NnQ08nvQvz9j31xIcxLCfDD6m6CVzyYJZaJ+nKP0lE8k
	 +QKx4LFeqf+pCfO4WlArSVtqPiRTr8fruAPio9DWSrTz4HhW+v2IRIkuIHNvcRkHTc
	 9WMZiIwLJNpcK88/QaudkQf/qeP+li4/epJaKE3ugReQw2XSoGEZiJ2SJQ86a3TcPt
	 t6tYG1hVUoqgw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 01/16] dma-mapping: introduce new DMA attribute to indicate MMIO memory
Date: Tue,  9 Sep 2025 16:27:29 +0300
Message-ID: <6f058ec395c5348014860dbc2eed348c17975843.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers
that reside in memory-mapped I/O (MMIO) regions, such as device BARs
exposed through the host bridge, which are accessible for peer-to-peer
(P2P) DMA.

This attribute is especially useful for exporting device memory to other
devices for DMA without CPU involvement, and avoids unnecessary or
potentially detrimental CPU cache maintenance calls.

DMA_ATTR_MMIO is supposed to provide dma_map_resource() functionality
without need to call to special function and perform branching when
processing generic containers like bio_vec by the callers.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 Documentation/core-api/dma-attributes.rst | 18 ++++++++++++++++++
 include/linux/dma-mapping.h               | 20 ++++++++++++++++++++
 include/trace/events/dma.h                |  3 ++-
 rust/kernel/dma.rs                        |  3 +++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
index 1887d92e8e926..0bdc2be65e575 100644
--- a/Documentation/core-api/dma-attributes.rst
+++ b/Documentation/core-api/dma-attributes.rst
@@ -130,3 +130,21 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged
 subsystem that the buffer is fully accessible at the elevated privilege
 level (and ideally inaccessible or at least read-only at the
 lesser-privileged levels).
+
+DMA_ATTR_MMIO
+-------------
+
+This attribute indicates the physical address is not normal system
+memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page()
+functions, it may not be cacheable, and access using CPU load/store
+instructions may not be allowed.
+
+Usually this will be used to describe MMIO addresses, or other non-cacheable
+register addresses. When DMA mapping this sort of address we call
+the operation Peer to Peer as a one device is DMA'ing to another device.
+For PCI devices the p2pdma APIs must be used to determine if
+DMA_ATTR_MMIO is appropriate.
+
+For architectures that require cache flushing for DMA coherence
+DMA_ATTR_MMIO will not perform any cache flushing. The address
+provided must never be mapped cacheable into the CPU.
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 55c03e5fe8cb3..4254fd9bdf5dd 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -58,6 +58,26 @@
  */
 #define DMA_ATTR_PRIVILEGED		(1UL << 9)
 
+/*
+ * DMA_ATTR_MMIO - Indicates memory-mapped I/O (MMIO) region for DMA mapping
+ *
+ * This attribute indicates the physical address is not normal system
+ * memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page()
+ * functions, it may not be cacheable, and access using CPU load/store
+ * instructions may not be allowed.
+ *
+ * Usually this will be used to describe MMIO addresses, or other non-cacheable
+ * register addresses. When DMA mapping this sort of address we call
+ * the operation Peer to Peer as a one device is DMA'ing to another device.
+ * For PCI devices the p2pdma APIs must be used to determine if DMA_ATTR_MMIO
+ * is appropriate.
+ *
+ * For architectures that require cache flushing for DMA coherence
+ * DMA_ATTR_MMIO will not perform any cache flushing. The address
+ * provided must never be mapped cacheable into the CPU.
+ */
+#define DMA_ATTR_MMIO		(1UL << 10)
+
 /*
  * A dma_addr_t can hold any valid DMA or bus address for the platform.  It can
  * be given to a device to use as a DMA source or target.  It is specific to a
diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h
index d8ddc27b6a7c8..ee90d6f1dcf35 100644
--- a/include/trace/events/dma.h
+++ b/include/trace/events/dma.h
@@ -31,7 +31,8 @@ TRACE_DEFINE_ENUM(DMA_NONE);
 		{ DMA_ATTR_FORCE_CONTIGUOUS, "FORCE_CONTIGUOUS" }, \
 		{ DMA_ATTR_ALLOC_SINGLE_PAGES, "ALLOC_SINGLE_PAGES" }, \
 		{ DMA_ATTR_NO_WARN, "NO_WARN" }, \
-		{ DMA_ATTR_PRIVILEGED, "PRIVILEGED" })
+		{ DMA_ATTR_PRIVILEGED, "PRIVILEGED" }, \
+		{ DMA_ATTR_MMIO, "MMIO" })
 
 DECLARE_EVENT_CLASS(dma_map,
 	TP_PROTO(struct device *dev, phys_addr_t phys_addr, dma_addr_t dma_addr,
diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
index 2bc8ab51ec280..61d9eed7a786e 100644
--- a/rust/kernel/dma.rs
+++ b/rust/kernel/dma.rs
@@ -242,6 +242,9 @@ pub mod attrs {
     /// Indicates that the buffer is fully accessible at an elevated privilege level (and
     /// ideally inaccessible or at least read-only at lesser-privileged levels).
     pub const DMA_ATTR_PRIVILEGED: Attrs = Attrs(bindings::DMA_ATTR_PRIVILEGED);
+
+    /// Indicates that the buffer is MMIO memory.
+    pub const DMA_ATTR_MMIO: Attrs = Attrs(bindings::DMA_ATTR_MMIO);
 }
 
 /// An abstraction of the `dma_alloc_coherent` API.
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116771.1463050 (Exim 4.92)
	(envelope-from )
	id 1uvyOh-0006xd-77; Tue, 09 Sep 2025 13:28:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116771.1463050; Tue, 09 Sep 2025 13:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyOh-0006xS-4R; Tue, 09 Sep 2025 13:28:35 +0000
Received: by outflank-mailman (input) for mailman id 1116771;
 Tue, 09 Sep 2025 13:28: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 1uvyOf-00067u-QF
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:33 +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 e1225aa4-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28: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 D46A36022B;
 Tue,  9 Sep 2025 13:28:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE634C4CEF4;
 Tue,  9 Sep 2025 13:28: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: e1225aa4-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424511;
	bh=4mltAvyMabIGEImaWuSSJtalttkzAHCWh/Fw+6N32DY=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tCpUTcP9jO+9dsDDMtGfIjYcTNxitYgY+NyJLSaMvdcTJcdQ0eSFy/DQmzBDm2ZFR
	 GrUGVtXFkVPPjioBPZdc4zSec+IoGRCm/dW6ymp6AA5RlfNqRUUd7ZH9DBIlr6R4W7
	 IEsUYyFc07xgmZuhDfMQHV+BCte69Vi5MSizfFKTtm+tTWXqLb0Ui3bSWuWJ45Iw2Q
	 6f/ensYXk8TsYGeyrMrF0qcfNbx2ZHeDWJZMokK2P3cpAWKpMuXdcKrrY8UcJjMM7s
	 uks/fzjkj7BLsj+kh+MxLEhV2XiEu6To6Ul4To3CgbdtkzwXIwBZNHKVr8p0u6r5LE
	 ifao53nreLEHQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 02/16] iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link().
Date: Tue,  9 Sep 2025 16:27:30 +0300
Message-ID: <17ba63991aeaf8a80d5aca9ba5d028f1daa58f62.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

This will replace the hacky use of DMA_ATTR_SKIP_CPU_SYNC to avoid
touching the possibly non-KVA MMIO memory.

Also correct the incorrect caching attribute for the IOMMU, MMIO
memory should not be cachable inside the IOMMU mapping or it can
possibly create system problems. Set IOMMU_MMIO for DMA_ATTR_MMIO.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 drivers/iommu/dma-iommu.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ea2ef53bd4fef..e1185ba73e23a 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -724,7 +724,12 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev
 static int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
 		     unsigned long attrs)
 {
-	int prot = coherent ? IOMMU_CACHE : 0;
+	int prot;
+
+	if (attrs & DMA_ATTR_MMIO)
+		prot = IOMMU_MMIO;
+	else
+		prot = coherent ? IOMMU_CACHE : 0;
 
 	if (attrs & DMA_ATTR_PRIVILEGED)
 		prot |= IOMMU_PRIV;
@@ -1838,12 +1843,13 @@ static int __dma_iova_link(struct device *dev, dma_addr_t addr,
 		unsigned long attrs)
 {
 	bool coherent = dev_is_dma_coherent(dev);
+	int prot = dma_info_to_prot(dir, coherent, attrs);
 
-	if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+	if (!coherent && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
 		arch_sync_dma_for_device(phys, size, dir);
 
 	return iommu_map_nosync(iommu_get_dma_domain(dev), addr, phys, size,
-			dma_info_to_prot(dir, coherent, attrs), GFP_ATOMIC);
+			prot, GFP_ATOMIC);
 }
 
 static int iommu_dma_iova_bounce_and_link(struct device *dev, dma_addr_t addr,
@@ -1949,9 +1955,13 @@ int dma_iova_link(struct device *dev, struct dma_iova_state *state,
 		return -EIO;
 
 	if (dev_use_swiotlb(dev, size, dir) &&
-	    iova_unaligned(iovad, phys, size))
+	    iova_unaligned(iovad, phys, size)) {
+		if (attrs & DMA_ATTR_MMIO)
+			return -EPERM;
+
 		return iommu_dma_iova_link_swiotlb(dev, state, phys, offset,
 				size, dir, attrs);
+	}
 
 	return __dma_iova_link(dev, state->addr + offset - iova_start_pad,
 			phys - iova_start_pad,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116772.1463061 (Exim 4.92)
	(envelope-from )
	id 1uvyOk-0007HT-Fy; Tue, 09 Sep 2025 13:28:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116772.1463061; Tue, 09 Sep 2025 13:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyOk-0007HI-DB; Tue, 09 Sep 2025 13:28:38 +0000
Received: by outflank-mailman (input) for mailman id 1116772;
 Tue, 09 Sep 2025 13:28: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 1uvyOj-00067u-47
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:37 +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 e35b5cde-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28:36 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9A8146021E;
 Tue,  9 Sep 2025 13:28:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9385AC4CEF4;
 Tue,  9 Sep 2025 13:28: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: e35b5cde-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424515;
	bh=A63sCU1us486CfnvbybDoy2DvC4mWvbNv9XH5e8Grdg=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Wi8yN8n22gc8EHttTIy6nTDZdyyXoXQ/Pldkc75H1b6hLRfWF7W91QongjbmQvASx
	 sv6rDJHl2MJSbLxPwGa3dmCMbrX9j01Em95NpNXM4cIDH7UJTEwX83geF/iBTaLFuP
	 z9936grIMWYOudFZFyWQaaATwNqlVd7G9UV/xV6GFF/aAOUbPO06Q/ST7pKHRaUbg7
	 zvG59sLnQHkzA0x5NeN55UQGwo5PwCywmKPSo//7gII1NKJ57XsBVOqW3xGebHV5Ho
	 GeffiYBcLO2jLid5aJ6HsuI1v5dL0okkwlGaoFgMfg5DtNWLYRKj5r9JHHMSD8Ink5
	 CRsGJPvVMTubA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 06/16] iommu/dma: implement DMA_ATTR_MMIO for iommu_dma_(un)map_phys()
Date: Tue,  9 Sep 2025 16:27:34 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Make iommu_dma_map_phys() and iommu_dma_unmap_phys() respect
DMA_ATTR_MMIO.

DMA_ATTR_MMIO makes the functions behave the same as
iommu_dma_(un)map_resource():
 - No swiotlb is possible
 - No cache flushing is done (ATTR_MMIO should not be cached memory)
 - prot for iommu_map() has IOMMU_MMIO not IOMMU_CACHE

This is preparation for replacing iommu_dma_map_resource() callers
with iommu_dma_map_phys(DMA_ATTR_MMIO) and removing
iommu_dma_(un)map_resource().

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 drivers/iommu/dma-iommu.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index aea119f32f965..6804aaf034a16 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1211,16 +1211,19 @@ dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 	 */
 	if (dev_use_swiotlb(dev, size, dir) &&
 	    iova_unaligned(iovad, phys, size)) {
+		if (attrs & DMA_ATTR_MMIO)
+			return DMA_MAPPING_ERROR;
+
 		phys = iommu_dma_map_swiotlb(dev, phys, size, dir, attrs);
 		if (phys == (phys_addr_t)DMA_MAPPING_ERROR)
 			return DMA_MAPPING_ERROR;
 	}
 
-	if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+	if (!coherent && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
 		arch_sync_dma_for_device(phys, size, dir);
 
 	iova = __iommu_dma_map(dev, phys, size, prot, dma_mask);
-	if (iova == DMA_MAPPING_ERROR)
+	if (iova == DMA_MAPPING_ERROR && !(attrs & DMA_ATTR_MMIO))
 		swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
 	return iova;
 }
@@ -1228,10 +1231,14 @@ dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 void iommu_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	struct iommu_domain *domain = iommu_get_dma_domain(dev);
 	phys_addr_t phys;
 
-	phys = iommu_iova_to_phys(domain, dma_handle);
+	if (attrs & DMA_ATTR_MMIO) {
+		__iommu_dma_unmap(dev, dma_handle, size);
+		return;
+	}
+
+	phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle);
 	if (WARN_ON(!phys))
 		return;
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116776.1463072 (Exim 4.92)
	(envelope-from )
	id 1uvyOq-0007mY-RR; Tue, 09 Sep 2025 13:28:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116776.1463072; Tue, 09 Sep 2025 13: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 1uvyOq-0007mD-KG; Tue, 09 Sep 2025 13:28:44 +0000
Received: by outflank-mailman (input) for mailman id 1116776;
 Tue, 09 Sep 2025 13: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 1uvyOo-00067u-RM
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:42 +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 e5ed5a71-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28:41 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id DABBA443D0;
 Tue,  9 Sep 2025 13:28:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AFE4C4CEFA;
 Tue,  9 Sep 2025 13:28: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: e5ed5a71-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424519;
	bh=w8kS6Kv6jl4hijoz408buSvl4DjsRf9g5sD93Yq2Jnc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=H0K5skJh4/WF1ektaQtKz3ZvzjCQqgk/jPDZY831i1OmPzNKJt3zr0VMLZUn6Oalv
	 QZlGTWfPJFB7YeDbSMUjcTI8tj9oxelLdc6cTAEt8nQzs1r8TU1y2uFmuHgOFV+7c0
	 zEBCqYzjKQTExQMtJ79OmQvvY67JyWUakHS4U0Q2xmIwAQsk/PUF0NrIhd8JCJsskZ
	 VNR1XrQWFu6/SZ5+39SqVX3r9GV1SO+KxS4E9QiFH8hpgNXXzYyQoNPdKGBL9h1dD1
	 QxJaEGXOUKJTU4yZUiZoacSiZ+5WLQ3HXsD6ySMQJWATB9JTvrZUM1yN6Y9PbEE38Q
	 a/pRBshQSFabQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 07/16] dma-mapping: convert dma_direct_*map_page to be phys_addr_t based
Date: Tue,  9 Sep 2025 16:27:35 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Convert the DMA direct mapping functions to accept physical addresses
directly instead of page+offset parameters. The functions were already
operating on physical addresses internally, so this change eliminates
the redundant page-to-physical conversion at the API boundary.

The functions dma_direct_map_page() and dma_direct_unmap_page() are
renamed to dma_direct_map_phys() and dma_direct_unmap_phys() respectively,
with their calling convention changed from (struct page *page,
unsigned long offset) to (phys_addr_t phys).

Architecture-specific functions arch_dma_map_page_direct() and
arch_dma_unmap_page_direct() are similarly renamed to
arch_dma_map_phys_direct() and arch_dma_unmap_phys_direct().

The is_pci_p2pdma_page() checks are replaced with DMA_ATTR_MMIO checks
to allow integration with dma_direct_map_resource and dma_direct_map_phys()
is extended to support MMIO path either.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 arch/powerpc/kernel/dma-iommu.c |  4 +--
 include/linux/dma-map-ops.h     |  8 ++---
 kernel/dma/direct.c             |  6 ++--
 kernel/dma/direct.h             | 57 +++++++++++++++++++++------------
 kernel/dma/mapping.c            |  8 ++---
 5 files changed, 49 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 4d64a5db50f38..0359ab72cd3ba 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -14,7 +14,7 @@
 #define can_map_direct(dev, addr) \
 	((dev)->bus_dma_limit >= phys_to_dma((dev), (addr)))
 
-bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr)
+bool arch_dma_map_phys_direct(struct device *dev, phys_addr_t addr)
 {
 	if (likely(!dev->bus_dma_limit))
 		return false;
@@ -24,7 +24,7 @@ bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr)
 
 #define is_direct_handle(dev, h) ((h) >= (dev)->archdata.dma_offset)
 
-bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t dma_handle)
+bool arch_dma_unmap_phys_direct(struct device *dev, dma_addr_t dma_handle)
 {
 	if (likely(!dev->bus_dma_limit))
 		return false;
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index f48e5fb88bd5d..71f5b30254159 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -392,15 +392,15 @@ void *arch_dma_set_uncached(void *addr, size_t size);
 void arch_dma_clear_uncached(void *addr, size_t size);
 
 #ifdef CONFIG_ARCH_HAS_DMA_MAP_DIRECT
-bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr);
-bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t dma_handle);
+bool arch_dma_map_phys_direct(struct device *dev, phys_addr_t addr);
+bool arch_dma_unmap_phys_direct(struct device *dev, dma_addr_t dma_handle);
 bool arch_dma_map_sg_direct(struct device *dev, struct scatterlist *sg,
 		int nents);
 bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist *sg,
 		int nents);
 #else
-#define arch_dma_map_page_direct(d, a)		(false)
-#define arch_dma_unmap_page_direct(d, a)	(false)
+#define arch_dma_map_phys_direct(d, a)		(false)
+#define arch_dma_unmap_phys_direct(d, a)	(false)
 #define arch_dma_map_sg_direct(d, s, n)		(false)
 #define arch_dma_unmap_sg_direct(d, s, n)	(false)
 #endif
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 24c359d9c8799..fa75e30700730 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -453,7 +453,7 @@ void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl,
 		if (sg_dma_is_bus_address(sg))
 			sg_dma_unmark_bus_address(sg);
 		else
-			dma_direct_unmap_page(dev, sg->dma_address,
+			dma_direct_unmap_phys(dev, sg->dma_address,
 					      sg_dma_len(sg), dir, attrs);
 	}
 }
@@ -476,8 +476,8 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
 			 */
 			break;
 		case PCI_P2PDMA_MAP_NONE:
-			sg->dma_address = dma_direct_map_page(dev, sg_page(sg),
-					sg->offset, sg->length, dir, attrs);
+			sg->dma_address = dma_direct_map_phys(dev, sg_phys(sg),
+					sg->length, dir, attrs);
 			if (sg->dma_address == DMA_MAPPING_ERROR) {
 				ret = -EIO;
 				goto out_unmap;
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index d2c0b7e632fc0..da2fadf45bcd6 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -80,42 +80,57 @@ static inline void dma_direct_sync_single_for_cpu(struct device *dev,
 		arch_dma_mark_clean(paddr, size);
 }
 
-static inline dma_addr_t dma_direct_map_page(struct device *dev,
-		struct page *page, unsigned long offset, size_t size,
-		enum dma_data_direction dir, unsigned long attrs)
+static inline dma_addr_t dma_direct_map_phys(struct device *dev,
+		phys_addr_t phys, size_t size, enum dma_data_direction dir,
+		unsigned long attrs)
 {
-	phys_addr_t phys = page_to_phys(page) + offset;
-	dma_addr_t dma_addr = phys_to_dma(dev, phys);
+	dma_addr_t dma_addr;
 
 	if (is_swiotlb_force_bounce(dev)) {
-		if (is_pci_p2pdma_page(page))
-			return DMA_MAPPING_ERROR;
+		if (attrs & DMA_ATTR_MMIO)
+			goto err_overflow;
+
 		return swiotlb_map(dev, phys, size, dir, attrs);
 	}
 
-	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
-	    dma_kmalloc_needs_bounce(dev, size, dir)) {
-		if (is_pci_p2pdma_page(page))
-			return DMA_MAPPING_ERROR;
-		if (is_swiotlb_active(dev))
-			return swiotlb_map(dev, phys, size, dir, attrs);
-
-		dev_WARN_ONCE(dev, 1,
-			     "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
-			     &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
-		return DMA_MAPPING_ERROR;
+	if (attrs & DMA_ATTR_MMIO) {
+		dma_addr = phys;
+		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
+			goto err_overflow;
+	} else {
+		dma_addr = phys_to_dma(dev, phys);
+		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
+		    dma_kmalloc_needs_bounce(dev, size, dir)) {
+			if (is_swiotlb_active(dev))
+				return swiotlb_map(dev, phys, size, dir, attrs);
+
+			goto err_overflow;
+		}
 	}
 
-	if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+	if (!dev_is_dma_coherent(dev) &&
+	    !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
 		arch_sync_dma_for_device(phys, size, dir);
 	return dma_addr;
+
+err_overflow:
+	dev_WARN_ONCE(
+		dev, 1,
+		"DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
+		&dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
+	return DMA_MAPPING_ERROR;
 }
 
-static inline void dma_direct_unmap_page(struct device *dev, dma_addr_t addr,
+static inline void dma_direct_unmap_phys(struct device *dev, dma_addr_t addr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	phys_addr_t phys = dma_to_phys(dev, addr);
+	phys_addr_t phys;
+
+	if (attrs & DMA_ATTR_MMIO)
+		/* nothing to do: uncached and no swiotlb */
+		return;
 
+	phys = dma_to_phys(dev, addr);
 	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
 		dma_direct_sync_single_for_cpu(dev, addr, size, dir);
 
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 90ad728205b93..3ac7d15e095f9 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -166,8 +166,8 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		return DMA_MAPPING_ERROR;
 
 	if (dma_map_direct(dev, ops) ||
-	    arch_dma_map_page_direct(dev, phys + size))
-		addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
+	    arch_dma_map_phys_direct(dev, phys + size))
+		addr = dma_direct_map_phys(dev, phys, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
 	else
@@ -187,8 +187,8 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 
 	BUG_ON(!valid_dma_direction(dir));
 	if (dma_map_direct(dev, ops) ||
-	    arch_dma_unmap_page_direct(dev, addr + size))
-		dma_direct_unmap_page(dev, addr, size, dir, attrs);
+	    arch_dma_unmap_phys_direct(dev, addr + size))
+		dma_direct_unmap_phys(dev, addr, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
 	else
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:28:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:28:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116787.1463080 (Exim 4.92)
	(envelope-from )
	id 1uvyOv-0008GD-0j; Tue, 09 Sep 2025 13:28:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116787.1463080; Tue, 09 Sep 2025 13: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 1uvyOu-0008G1-TL; Tue, 09 Sep 2025 13:28:48 +0000
Received: by outflank-mailman (input) for mailman id 1116787;
 Tue, 09 Sep 2025 13: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 1uvyOt-00067u-S9
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28: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 e88a6c20-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28:45 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 5024C433EF;
 Tue,  9 Sep 2025 13:28:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66D52C4CEF4;
 Tue,  9 Sep 2025 13:28: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: e88a6c20-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424524;
	bh=az1vV9FS2ijQFCe2KnlGsCUm5py+7cz5M/t0oqZVEe0=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=jgpKjl3Wzr18vmUsgRZQtN4//p8yXvKe2bqbeBF+tjCU7DiPUojq+IdDByulqXWaT
	 RoAAZFNISIIUjdOgETkxJvzlEMu06VIXfR7n+SDYVJ7snL//aFTqN5/n+wjwc9CKce
	 hgPzq2wz22D/FrFpA1h8MaExay5bJUjRXKU9I9qYxPPzy5vQjh6WVr5wv9ZdJETnxa
	 +RSkDK4c0tSR4Jg25A6+k+Nj48PdiVEpZ97m9rNszJ8IkgL9HIE++EJgXm7HweKW2n
	 Z/eO4I7jE8ssv546fCTIjcxZvbt+sSyTCV9kntGrGqjk4RietJ966th5LAGixlLyUg
	 ACSDJ7U85NKEQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 08/16] kmsan: convert kmsan_handle_dma to use physical addresses
Date: Tue,  9 Sep 2025 16:27:36 +0300
Message-ID: <3557cbaf66e935bc794f37d2b891ef75cbf2c80c.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Convert the KMSAN DMA handling function from page-based to physical
address-based interface.

The refactoring renames kmsan_handle_dma() parameters from accepting
(struct page *page, size_t offset, size_t size) to (phys_addr_t phys,
size_t size). The existing semantics where callers are expected to
provide only kmap memory is continued here.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 drivers/virtio/virtio_ring.c |  4 ++--
 include/linux/kmsan.h        |  9 ++++-----
 kernel/dma/mapping.c         |  3 ++-
 mm/kmsan/hooks.c             | 10 ++++++----
 tools/virtio/linux/kmsan.h   |  2 +-
 5 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index f5062061c4084..c147145a65930 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -378,7 +378,7 @@ static int vring_map_one_sg(const struct vring_virtqueue *vq, struct scatterlist
 		 * is initialized by the hardware. Explicitly check/unpoison it
 		 * depending on the direction.
 		 */
-		kmsan_handle_dma(sg_page(sg), sg->offset, sg->length, direction);
+		kmsan_handle_dma(sg_phys(sg), sg->length, direction);
 		*addr = (dma_addr_t)sg_phys(sg);
 		return 0;
 	}
@@ -3157,7 +3157,7 @@ dma_addr_t virtqueue_dma_map_single_attrs(struct virtqueue *_vq, void *ptr,
 	struct vring_virtqueue *vq = to_vvq(_vq);
 
 	if (!vq->use_dma_api) {
-		kmsan_handle_dma(virt_to_page(ptr), offset_in_page(ptr), size, dir);
+		kmsan_handle_dma(virt_to_phys(ptr), size, dir);
 		return (dma_addr_t)virt_to_phys(ptr);
 	}
 
diff --git a/include/linux/kmsan.h b/include/linux/kmsan.h
index 2b1432cc16d59..f2fd221107bba 100644
--- a/include/linux/kmsan.h
+++ b/include/linux/kmsan.h
@@ -182,8 +182,7 @@ void kmsan_iounmap_page_range(unsigned long start, unsigned long end);
 
 /**
  * kmsan_handle_dma() - Handle a DMA data transfer.
- * @page:   first page of the buffer.
- * @offset: offset of the buffer within the first page.
+ * @phys:   physical address of the buffer.
  * @size:   buffer size.
  * @dir:    one of possible dma_data_direction values.
  *
@@ -192,7 +191,7 @@ void kmsan_iounmap_page_range(unsigned long start, unsigned long end);
  * * initializes the buffer, if it is copied from device;
  * * does both, if this is a DMA_BIDIRECTIONAL transfer.
  */
-void kmsan_handle_dma(struct page *page, size_t offset, size_t size,
+void kmsan_handle_dma(phys_addr_t phys, size_t size,
 		      enum dma_data_direction dir);
 
 /**
@@ -372,8 +371,8 @@ static inline void kmsan_iounmap_page_range(unsigned long start,
 {
 }
 
-static inline void kmsan_handle_dma(struct page *page, size_t offset,
-				    size_t size, enum dma_data_direction dir)
+static inline void kmsan_handle_dma(phys_addr_t phys, size_t size,
+				    enum dma_data_direction dir)
 {
 }
 
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 3ac7d15e095f9..e47bcf7cc43d7 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -172,7 +172,8 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
 	else
 		addr = ops->map_page(dev, page, offset, size, dir, attrs);
-	kmsan_handle_dma(page, offset, size, dir);
+
+	kmsan_handle_dma(phys, size, dir);
 	trace_dma_map_phys(dev, phys, addr, size, dir, attrs);
 	debug_dma_map_phys(dev, phys, size, dir, addr, attrs);
 
diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c
index 97de3d6194f07..fa9475e5ec4e9 100644
--- a/mm/kmsan/hooks.c
+++ b/mm/kmsan/hooks.c
@@ -336,14 +336,16 @@ static void kmsan_handle_dma_page(const void *addr, size_t size,
 }
 
 /* Helper function to handle DMA data transfers. */
-void kmsan_handle_dma(struct page *page, size_t offset, size_t size,
+void kmsan_handle_dma(phys_addr_t phys, size_t size,
 		      enum dma_data_direction dir)
 {
-	u64 page_offset, to_go, addr;
+	struct page *page = phys_to_page(phys);
+	u64 page_offset, to_go;
+	void *addr;
 
-	if (PageHighMem(page))
+	if (PhysHighMem(phys))
 		return;
-	addr = (u64)page_address(page) + offset;
+	addr = page_to_virt(page);
 	/*
 	 * The kernel may occasionally give us adjacent DMA pages not belonging
 	 * to the same allocation. Process them separately to avoid triggering
diff --git a/tools/virtio/linux/kmsan.h b/tools/virtio/linux/kmsan.h
index 272b5aa285d5a..6cd2e3efd03dc 100644
--- a/tools/virtio/linux/kmsan.h
+++ b/tools/virtio/linux/kmsan.h
@@ -4,7 +4,7 @@
 
 #include 
 
-inline void kmsan_handle_dma(struct page *page, size_t offset, size_t size,
+inline void kmsan_handle_dma(phys_addr_t phys, size_t size,
 			     enum dma_data_direction dir)
 {
 }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:33:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:33:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116832.1463092 (Exim 4.92)
	(envelope-from )
	id 1uvyTV-0002hy-SY; Tue, 09 Sep 2025 13:33:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116832.1463092; Tue, 09 Sep 2025 13: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 1uvyTV-0002hr-O3; Tue, 09 Sep 2025 13:33:33 +0000
Received: by outflank-mailman (input) for mailman id 1116832;
 Tue, 09 Sep 2025 13:33: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 1uvyTU-0002hE-Em
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:33:32 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061d.outbound.protection.outlook.com
 [2a01:111:f403:200a::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 929866f9-8d81-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:33:31 +0200 (CEST)
Received: from SN7P222CA0016.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:124::16)
 by IA1PR12MB8079.namprd12.prod.outlook.com (2603:10b6:208:3fb::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 13:33:25 +0000
Received: from SN1PEPF0002529E.namprd05.prod.outlook.com
 (2603:10b6:806:124:cafe::a8) by SN7P222CA0016.outlook.office365.com
 (2603:10b6:806:124::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.23 via Frontend Transport; Tue,
 9 Sep 2025 13:33:23 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF0002529E.mail.protection.outlook.com (10.167.242.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Tue, 9 Sep 2025 13:33:23 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Tue, 9 Sep
 2025 06:32:22 -0700
Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 9 Sep
 2025 08:31:12 -0500
Received: from [192.168.29.198] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Tue, 9 Sep 2025 06:31:11 -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: 929866f9-8d81-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=e0zjae1l2BA3qh+VcpRkQ92Q0WrIHsPNHwJcDn3R5siqkz/Y0JnFpMzyPrZxzpTdv6kVlL3vzs9vFy7QpxGlNKK5poL7JK4Z0hOUWJpXqHgODwtCxSOUaY6Gec8Zo521Q/veDQqTGgUnAHk7hg4y2CWkD7I+BvOFg6017zydHLV5cbiz0vraiz6qfVqItad8uzp+WcpAhS2YadxwfrjabcJ9v92tfKnipHmnyKgo0Pd56V5qMNb5d5yvh4fJSuTi67gccqgQtEM/VbCIHUH/9KOy3g5BgMU2p9bohd+lHuHwd30bKOhCsFJn1PNIk8waDS0vHwcgsF32COEjrWo+Ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DtLJLBmdDdGL28ifw2udY+Oia7vhLHnRXYJaPTwSAnI=;
 b=hmdguGs11btJb+66GVokjgmu0I/ig+SRGa9t36OGk8Rnvil+S/WkdvzvNRVOw2rhrFb2myxPguWYK3g+FVb6Rh5ixM9XiSnp57Zl8snr6WZfBS5i9u3wJ+oahBpEkQXIWV//uuE2n6d964FQvWvxUVurdGmRDUPejnRZfMEyO71x/woD4J5P/X/FDy6p+Bh3ntGRIlAyHm0RCnk+Dc/3crvLQ0TbMMXahcVUq05EzMFvX17jmtHAZKvWyvSs/EWyaPQNTvPZhBIIoNIWNEczrMLDDf38dBK/QDbM6bkfaJqACBC/8gwpex/I7EefYH0EV1v+sKcyGnm/5l4vFIkJ0w==
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=DtLJLBmdDdGL28ifw2udY+Oia7vhLHnRXYJaPTwSAnI=;
 b=Ddg7CL19oRyB3tEDGN04pW6NKYMVpznt0X2BFf0ZaR1XCOcBIQwsmy0srHZJREhALW8TDZUFQz/yOM7uUad/SlmjuYuiOY+kJM9fqAzY0c2FWkBM1FrMARod8T0zJNqt4Rta9PyUhQMeNsPQ2vyd9KtIeqpOw80h+PHt5GTIzOo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <593b0524-879c-4cca-afb9-516af613c5af@amd.com>
Date: Tue, 9 Sep 2025 09:31:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/IO-APIC: drop setup_ioapic_ids_from_mpc()
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	"consulting@bugseng.com" 
References: 
 <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@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: SN1PEPF0002529E:EE_|IA1PR12MB8079:EE_
X-MS-Office365-Filtering-Correlation-Id: 295d7fdc-9a19-4c5e-4023-08ddefa5733b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?V093U3daOGNWdDM4dVNzaWZaV3p4bUlRbFdaeFU2OWdvdWFXczVNMWlCQnQv?=
 =?utf-8?B?ZnlTRVJ0Y1pXT1ZFL1gxZUt5S0lIMm5tVnMwcVNOaE9iM2thVFl1QXV0WWlt?=
 =?utf-8?B?eHI5ZllzK0E0MlhUOHpJZmd6cGtVK0RtVUxmNlN0ZTgxK0x1aTNpbkQ3blcr?=
 =?utf-8?B?aGZTeHYyWHNxVmY5MmJRL3JMZ1dXcU5jSGh2QTBYeEVyam84VzZNVGFKOW0r?=
 =?utf-8?B?bTFZYzJMZThza01mNWFUS3JXVXNqbHhxVWRDY0RSd3ljMnZvSnJOTjB3Q3M5?=
 =?utf-8?B?NHd0L2Z0NDhKQ3B5bGdaTUswaDBNMkZlVnBRWnJiQUJQby9BS3RyTlZvaUZu?=
 =?utf-8?B?V3lxajFZekVqVExNU1kzMG9YelM4eEhaTEJ6WW9GaWljSmlTbm82Z1RwV2V6?=
 =?utf-8?B?ZDMwMUxmNXUrK3gxTGNUck1CbjRjQ2RuOW56bGJaTHpOakl5U1dMZnFEbVpT?=
 =?utf-8?B?Vjg2cmdmY3NGYVp5eFFLbnRIdzhLRmhDMENDWjVNVFFIS0FRTTQreHlscUFp?=
 =?utf-8?B?QjhuTHBjWGIwazNWTGMwK3U2NUM1eldzQ1VJL1NaOW9wQ2dWbzROZFN3cXh4?=
 =?utf-8?B?NGZWOERaQmJOS3B4bzd5bkFqVGdLYjduaHA5Nmttb08zbGhJWXNoV1hUVUtz?=
 =?utf-8?B?ZHp1Rk40dEsyOHFSZWZiWnlNZ3BPaGp6K3JuZ1hoMlg5OWI1bzdqZ0hFZTBM?=
 =?utf-8?B?cW5QT2hSblBkc1VacWJFbFN5ZjFzU09TRHpzM1FjWHk1U2lRVTNZbDVHaDZG?=
 =?utf-8?B?c1d2dGxJSThuQ0ZsOVF0SG44UlAyVTg5T2dlcTBOWVBaNks3bnlMbDVvRmtH?=
 =?utf-8?B?RmRLYXI2Z1hrU251SDhxdGFHc3RrWjEzUTRlbm5lT0l5NU84K3h0K0wwNks5?=
 =?utf-8?B?RnVkS3FSV2NINmM2THFjbW1KM2hrOWY2YVdXMC8vQ002NWNudzJIS2p2UXdG?=
 =?utf-8?B?ZjN2VXZmaThBeDRWNUpQaHg2aFNzZDZsN01lOCs1Unp4UEdpS3dXZzV2VGNI?=
 =?utf-8?B?dUw0K0NONGt4cUZ2Y2VkZ0p5TWVRL1RQdFdGekpSS2cxZGJRM3M2Ykl1NUlN?=
 =?utf-8?B?Z2hIWkdVRE82QW9CWmVRamkzRHpWVlAzZkErdUpCUklFRzNESURRWTQwSjZm?=
 =?utf-8?B?cWRJNlllbi83SUQ0dkcyUElvcUlISlJVWGxCYTYreUNhT1NiN3p1Znhqa2ZO?=
 =?utf-8?B?dVVzNjJqWXZNVld0SFZ4T3ZYZXhlWnlUblZ1SDZQM2I4VWQ2VUFyVlY0Z1ZN?=
 =?utf-8?B?VXZINFRiWkRwckhYa2s4L0wrUy9hVCtYWkZsZVRHOWtnUWZkRnVYdkVxRWFt?=
 =?utf-8?B?Qkk0UG9QaUdQRFNuVEVOSGNxRVdvOW5Dd3JTekM4Rm94UFBwdnNpdm13NHlk?=
 =?utf-8?B?eTlIL0hjWExPVDliaTJNTlpiamc5UHJjTXp3RXlvVWNDeXBldm92b0ZtTXhG?=
 =?utf-8?B?NlM4eXJFbFQwMHB5QXFwVERETlBoUlNnMzdha3hObHgxbHVNV2lOV1NmYW05?=
 =?utf-8?B?bGYzcGlxMkdTWTVSZENVOU5Fbmd0eEwrd2lOZ2RBdWdhRG40M3Z6aWNVOW0v?=
 =?utf-8?B?L09kaVBhU0FsUERMbDVBaDNiRm1ZSlBhVys1TFlBQXMzaXBJRE9XZTJRSDZp?=
 =?utf-8?B?akZhcThRenU2Nlp6bkpaMVJvT1dQYXlScXM2ZlkrdW9NMVBBTTlScWhvbG1x?=
 =?utf-8?B?TzFMM0tuS0F6SzdMejRkNG5Bd3p3RDlwOGh3Mi9vOURla0RBaDFxNkVNYUJu?=
 =?utf-8?B?QVNpVnBHNjJvdXdSdm95dUpkTlIvT01hblpkNzhuV1IrM1ZXcmMvRUx0SVc0?=
 =?utf-8?B?eThsRVZaK0M3dlU1djRMamtIL2JDVDR1QWRSUTRHOXdmMUVMcGVVQnhWMGkv?=
 =?utf-8?B?Y2JPK0JNYVRwV2VYRGl2N2RXQ3IxaGhPb1oxRXJOK0lBK0dTc1BKRFdtVnpV?=
 =?utf-8?B?c21hWnhiUzF5Y2ZkVUp0a3RyWjZHUTlSK1FUU3lTOEVwbERCbTdKdWIxMFhS?=
 =?utf-8?B?VmJlS2dkUy8zSkFOeEJUV0FTR09QS2xqLzV4QzRNSGhMamhPMW9BZE14UWdp?=
 =?utf-8?Q?KB/K8d?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2025 13:33:23.7778
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 295d7fdc-9a19-4c5e-4023-08ddefa5733b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002529E.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8079

On 2025-09-03 03:55, Jan Beulich wrote:
> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
> said, the function is dead logic as well: All 64-bit capable Intel systems
> have (at least) xAPIC (if not x2APIC).
> 
> Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
> code; we didn't accept that yet, but - where possible - we probably would
> better follow it). Depending on one's reading, this code may actually be a
> violation of rule 2.1 (unreachable), which we did accept:
> 
> "Code is unreachable if, ..., there is no combination of program inputs
>   that can cause it to be executed."
> 
> Otoh it's "only" __init code.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:36:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116847.1463101 (Exim 4.92)
	(envelope-from )
	id 1uvyVv-0003Gn-7s; Tue, 09 Sep 2025 13:36:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116847.1463101; Tue, 09 Sep 2025 13: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 1uvyVv-0003Gg-4e; Tue, 09 Sep 2025 13:36:03 +0000
Received: by outflank-mailman (input) for mailman id 1116847;
 Tue, 09 Sep 2025 13: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 1uvyPM-00067u-5j
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29:16 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa21209f-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15: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 C541260226;
 Tue,  9 Sep 2025 13:29:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 946BBC4CEF7;
 Tue,  9 Sep 2025 13:29: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: fa21209f-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424553;
	bh=XSpIlPt4jLS+CRWTwe4PmKBEGcwSmMFNT5/+aafmf9o=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tD4BnfmgL7nSjP8jarOPnF1Kn1BC45TmtpUEyk4UgzRF9j3xxWUtgCJasGtD1cEYW
	 wsKbMmoN0mLlTVmqVsUCjuHU9MFeENKol/15l9I7px1JVOo67vHUW2X/x6NNJaO3go
	 B89Nkj4jb11BZXb69fWJg+iH7a9i4JMVdRx6HuizamFiINp/Xht6wzw2NrsRjzGEFg
	 uU2y5hSynA8hokL2y95P+N9k99ZCfT1r+u27f/8u3ug+IG812ekDMVu/nbK3l8aJ7T
	 OFODjRzmkmI1kisdeS4BJ0OXrhmGCoh7t8HbiKHptbJxGSed9WkruGW5w4iBDhJELY
	 ntNW51a5dmJaQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 15/16] block-dma: properly take MMIO path
Date: Tue,  9 Sep 2025 16:27:43 +0300
Message-ID: <1d0b07d0f1a5ce7f2b80e3c0aa06c7df56680ed8.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Make sure that CPU is not synced and IOMMU is configured to take
MMIO path by providing newly introduced DMA_ATTR_MMIO attribute.

Reviewed-by: Keith Busch 
Signed-off-by: Leon Romanovsky 
---
 block/blk-mq-dma.c         | 13 +++++++++++--
 include/linux/blk-mq-dma.h |  6 +++++-
 include/linux/blk_types.h  |  2 ++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c
index 37e2142be4f7d..d415088ed9fd2 100644
--- a/block/blk-mq-dma.c
+++ b/block/blk-mq-dma.c
@@ -87,8 +87,13 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec)
 static bool blk_dma_map_direct(struct request *req, struct device *dma_dev,
 		struct blk_dma_iter *iter, struct phys_vec *vec)
 {
+	unsigned int attrs = 0;
+
+	if (req->cmd_flags & REQ_MMIO)
+		attrs = DMA_ATTR_MMIO;
+
 	iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len,
-			rq_dma_dir(req), 0);
+			rq_dma_dir(req), attrs);
 	if (dma_mapping_error(dma_dev, iter->addr)) {
 		iter->status = BLK_STS_RESOURCE;
 		return false;
@@ -103,14 +108,17 @@ static bool blk_rq_dma_map_iova(struct request *req, struct device *dma_dev,
 {
 	enum dma_data_direction dir = rq_dma_dir(req);
 	unsigned int mapped = 0;
+	unsigned int attrs = 0;
 	int error;
 
 	iter->addr = state->addr;
 	iter->len = dma_iova_size(state);
+	if (req->cmd_flags & REQ_MMIO)
+		attrs = DMA_ATTR_MMIO;
 
 	do {
 		error = dma_iova_link(dma_dev, state, vec->paddr, mapped,
-				vec->len, dir, 0);
+				vec->len, dir, attrs);
 		if (error)
 			break;
 		mapped += vec->len;
@@ -176,6 +184,7 @@ bool blk_rq_dma_map_iter_start(struct request *req, struct device *dma_dev,
 			 * same as non-P2P transfers below and during unmap.
 			 */
 			req->cmd_flags &= ~REQ_P2PDMA;
+			req->cmd_flags |= REQ_MMIO;
 			break;
 		default:
 			iter->status = BLK_STS_INVAL;
diff --git a/include/linux/blk-mq-dma.h b/include/linux/blk-mq-dma.h
index c26a01aeae006..6c55f5e585116 100644
--- a/include/linux/blk-mq-dma.h
+++ b/include/linux/blk-mq-dma.h
@@ -48,12 +48,16 @@ static inline bool blk_rq_dma_map_coalesce(struct dma_iova_state *state)
 static inline bool blk_rq_dma_unmap(struct request *req, struct device *dma_dev,
 		struct dma_iova_state *state, size_t mapped_len)
 {
+	unsigned int attrs = 0;
+
 	if (req->cmd_flags & REQ_P2PDMA)
 		return true;
 
 	if (dma_use_iova(state)) {
+		if (req->cmd_flags & REQ_MMIO)
+			attrs = DMA_ATTR_MMIO;
 		dma_iova_destroy(dma_dev, state, mapped_len, rq_dma_dir(req),
-				 0);
+				 attrs);
 		return true;
 	}
 
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 09b99d52fd365..283058bcb5b14 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -387,6 +387,7 @@ enum req_flag_bits {
 	__REQ_FS_PRIVATE,	/* for file system (submitter) use */
 	__REQ_ATOMIC,		/* for atomic write operations */
 	__REQ_P2PDMA,		/* contains P2P DMA pages */
+	__REQ_MMIO,		/* contains MMIO memory */
 	/*
 	 * Command specific flags, keep last:
 	 */
@@ -420,6 +421,7 @@ enum req_flag_bits {
 #define REQ_FS_PRIVATE	(__force blk_opf_t)(1ULL << __REQ_FS_PRIVATE)
 #define REQ_ATOMIC	(__force blk_opf_t)(1ULL << __REQ_ATOMIC)
 #define REQ_P2PDMA	(__force blk_opf_t)(1ULL << __REQ_P2PDMA)
+#define REQ_MMIO	(__force blk_opf_t)(1ULL << __REQ_MMIO)
 
 #define REQ_NOUNMAP	(__force blk_opf_t)(1ULL << __REQ_NOUNMAP)
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:40:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:40:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116868.1463131 (Exim 4.92)
	(envelope-from )
	id 1uvyaH-0005Kr-7J; Tue, 09 Sep 2025 13:40:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116868.1463131; Tue, 09 Sep 2025 13:40: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 1uvyaH-0005Kg-3T; Tue, 09 Sep 2025 13:40:33 +0000
Received: by outflank-mailman (input) for mailman id 1116868;
 Tue, 09 Sep 2025 13:40: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 1uvyOz-00067u-Tc
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:53 +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 eb0dcf1c-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28: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 7C4C74341A;
 Tue,  9 Sep 2025 13:28:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7058C4CEF4;
 Tue,  9 Sep 2025 13:28: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: eb0dcf1c-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424528;
	bh=4ePATvT4TR5ecFcfHcb8V41SufKtoqnQ4LoEjPMODUw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=HCZ7zSxCHQnq8uO02FHrTDo9Lqt2UvrUd/Tgm4oPlzwgbEeOTJx1Uy9r7p4JgvoxP
	 Ke745OYSHLnFUKGgFXhYbUeDG1Ihk0CUdGU2Mv0dG2bIzGkcdFea1d18yN1daQt2Cq
	 iE8mEQbhJv0nnhsjj7yBNFvA+tRmvDdUyCjHBsp2bhV8M2K26dI0FkoL3OriItB4Ey
	 j4HFlYSG1vzaC5yFi1GHGFn91SDzxPg6zuJo/1d/MJ0U7jdkP/E+fkInf5nUZVzXVB
	 NQAZUmfuLAG2fmHd3zdrILMZZNfdyg1Y7zH1yWXMPkYCce4fYkR3GLvIi+SX429ywB
	 1GtYpw9a64y9w==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 05/16] iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys
Date: Tue,  9 Sep 2025 16:27:33 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Rename the IOMMU DMA mapping functions to better reflect their actual
calling convention. The functions iommu_dma_map_page() and
iommu_dma_unmap_page() are renamed to iommu_dma_map_phys() and
iommu_dma_unmap_phys() respectively, as they already operate on physical
addresses rather than page structures.

The calling convention changes from accepting (struct page *page,
unsigned long offset) to (phys_addr_t phys), which eliminates the need
for page-to-physical address conversion within the functions. This
renaming prepares for the broader DMA API conversion from page-based
to physical address-based mapping throughout the kernel.

All callers are updated to pass physical addresses directly, including
dma_map_page_attrs(), scatterlist mapping functions, and DMA page
allocation helpers. The change simplifies the code by removing the
page_to_phys() + offset calculation that was previously done inside
the IOMMU functions.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 drivers/iommu/dma-iommu.c | 14 ++++++--------
 include/linux/iommu-dma.h |  7 +++----
 kernel/dma/mapping.c      |  4 ++--
 kernel/dma/ops_helpers.c  |  6 +++---
 4 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index e1185ba73e23a..aea119f32f965 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1195,11 +1195,9 @@ static inline size_t iova_unaligned(struct iova_domain *iovad, phys_addr_t phys,
 	return iova_offset(iovad, phys | size);
 }
 
-dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
-	      unsigned long offset, size_t size, enum dma_data_direction dir,
-	      unsigned long attrs)
+dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		enum dma_data_direction dir, unsigned long attrs)
 {
-	phys_addr_t phys = page_to_phys(page) + offset;
 	bool coherent = dev_is_dma_coherent(dev);
 	int prot = dma_info_to_prot(dir, coherent, attrs);
 	struct iommu_domain *domain = iommu_get_dma_domain(dev);
@@ -1227,7 +1225,7 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
 	return iova;
 }
 
-void iommu_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+void iommu_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	struct iommu_domain *domain = iommu_get_dma_domain(dev);
@@ -1346,7 +1344,7 @@ static void iommu_dma_unmap_sg_swiotlb(struct device *dev, struct scatterlist *s
 	int i;
 
 	for_each_sg(sg, s, nents, i)
-		iommu_dma_unmap_page(dev, sg_dma_address(s),
+		iommu_dma_unmap_phys(dev, sg_dma_address(s),
 				sg_dma_len(s), dir, attrs);
 }
 
@@ -1359,8 +1357,8 @@ static int iommu_dma_map_sg_swiotlb(struct device *dev, struct scatterlist *sg,
 	sg_dma_mark_swiotlb(sg);
 
 	for_each_sg(sg, s, nents, i) {
-		sg_dma_address(s) = iommu_dma_map_page(dev, sg_page(s),
-				s->offset, s->length, dir, attrs);
+		sg_dma_address(s) = iommu_dma_map_phys(dev, sg_phys(s),
+				s->length, dir, attrs);
 		if (sg_dma_address(s) == DMA_MAPPING_ERROR)
 			goto out_unmap;
 		sg_dma_len(s) = s->length;
diff --git a/include/linux/iommu-dma.h b/include/linux/iommu-dma.h
index 508beaa44c39e..485bdffed9888 100644
--- a/include/linux/iommu-dma.h
+++ b/include/linux/iommu-dma.h
@@ -21,10 +21,9 @@ static inline bool use_dma_iommu(struct device *dev)
 }
 #endif /* CONFIG_IOMMU_DMA */
 
-dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t size, enum dma_data_direction dir,
-		unsigned long attrs);
-void iommu_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 		size_t size, enum dma_data_direction dir, unsigned long attrs);
 int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
 		enum dma_data_direction dir, unsigned long attrs);
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index bd3bb6d59d722..90ad728205b93 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -169,7 +169,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 	    arch_dma_map_page_direct(dev, phys + size))
 		addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
 	else if (use_dma_iommu(dev))
-		addr = iommu_dma_map_page(dev, page, offset, size, dir, attrs);
+		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
 	else
 		addr = ops->map_page(dev, page, offset, size, dir, attrs);
 	kmsan_handle_dma(page, offset, size, dir);
@@ -190,7 +190,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 	    arch_dma_unmap_page_direct(dev, addr + size))
 		dma_direct_unmap_page(dev, addr, size, dir, attrs);
 	else if (use_dma_iommu(dev))
-		iommu_dma_unmap_page(dev, addr, size, dir, attrs);
+		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
 	else
 		ops->unmap_page(dev, addr, size, dir, attrs);
 	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
index 9afd569eadb96..6f9d604d9d406 100644
--- a/kernel/dma/ops_helpers.c
+++ b/kernel/dma/ops_helpers.c
@@ -72,8 +72,8 @@ struct page *dma_common_alloc_pages(struct device *dev, size_t size,
 		return NULL;
 
 	if (use_dma_iommu(dev))
-		*dma_handle = iommu_dma_map_page(dev, page, 0, size, dir,
-						 DMA_ATTR_SKIP_CPU_SYNC);
+		*dma_handle = iommu_dma_map_phys(dev, page_to_phys(page), size,
+						 dir, DMA_ATTR_SKIP_CPU_SYNC);
 	else
 		*dma_handle = ops->map_page(dev, page, 0, size, dir,
 					    DMA_ATTR_SKIP_CPU_SYNC);
@@ -92,7 +92,7 @@ void dma_common_free_pages(struct device *dev, size_t size, struct page *page,
 	const struct dma_map_ops *ops = get_dma_ops(dev);
 
 	if (use_dma_iommu(dev))
-		iommu_dma_unmap_page(dev, dma_handle, size, dir,
+		iommu_dma_unmap_phys(dev, dma_handle, size, dir,
 				     DMA_ATTR_SKIP_CPU_SYNC);
 	else if (ops->unmap_page)
 		ops->unmap_page(dev, dma_handle, size, dir,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:40:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:40:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116866.1463110 (Exim 4.92)
	(envelope-from )
	id 1uvyaD-0004rK-OZ; Tue, 09 Sep 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 1116866.1463110; Tue, 09 Sep 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 1uvyaD-0004rD-LH; Tue, 09 Sep 2025 13:40:29 +0000
Received: by outflank-mailman (input) for mailman id 1116866;
 Tue, 09 Sep 2025 13:40: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 1uvyPE-0005uM-Fb
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29:08 +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 f568605c-8d80-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:29:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id D79DA601AB;
 Tue,  9 Sep 2025 13:29:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE671C4CEF4;
 Tue,  9 Sep 2025 13:29: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: f568605c-8d80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424545;
	bh=ThC+GnSzG3vqrBq8iTzTPlcPa91tU2BQkMRg6ndRAuA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tnTViotBzgzX8VJMiUdP1iBUBwTcHGl4cXP5/xMCQJd3NuJ+v83PZRp+IV4I6m6Oo
	 rii0+a9xxI6kUod6ywO0FDmoTZ6nHn1Sm9TRhAhDLtUAwTh72wrfQLc04U7MeCpJP7
	 S+VB1HVBG2J4AB5r/4HEc/HDCNwV9/HfLsWB9aqhPOk5wvZ5OXodZEfSrk5TQI0YSe
	 2rgbYngdJVyQWuu3KtxqmyHFWhVGXg7iRlR+oGtwNzAeTNGHstyq5kW2vRrVG1sC4O
	 sQLrmM3sgvgI/IElfjSWQ/akyQs02UZyEB+0KaMdypAsViiUDxdz4nCkmXQU4JWJEG
	 mVUoTlUsHhrUw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 13/16] mm/hmm: properly take MMIO path
Date: Tue,  9 Sep 2025 16:27:41 +0300
Message-ID: <998251caf3f9d1a3f6f8205f1f494c707fb4d8fa.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

In case peer-to-peer transaction traverses through host bridge,
the IOMMU needs to have IOMMU_MMIO flag, together with skip of
CPU sync.

The latter was handled by provided DMA_ATTR_SKIP_CPU_SYNC flag,
but IOMMU flag was missed, due to assumption that such memory
can be treated as regular one.

Reuse newly introduced DMA attribute to properly take MMIO path.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 mm/hmm.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index 015ab243f0813..6556c0e074ba8 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -746,7 +746,7 @@ dma_addr_t hmm_dma_map_pfn(struct device *dev, struct hmm_dma_map *map,
 	case PCI_P2PDMA_MAP_NONE:
 		break;
 	case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
-		attrs |= DMA_ATTR_SKIP_CPU_SYNC;
+		attrs |= DMA_ATTR_MMIO;
 		pfns[idx] |= HMM_PFN_P2PDMA;
 		break;
 	case PCI_P2PDMA_MAP_BUS_ADDR:
@@ -776,7 +776,7 @@ dma_addr_t hmm_dma_map_pfn(struct device *dev, struct hmm_dma_map *map,
 			goto error;
 
 		dma_addr = dma_map_phys(dev, paddr, map->dma_entry_size,
-					DMA_BIDIRECTIONAL, 0);
+					DMA_BIDIRECTIONAL, attrs);
 		if (dma_mapping_error(dev, dma_addr))
 			goto error;
 
@@ -811,16 +811,17 @@ bool hmm_dma_unmap_pfn(struct device *dev, struct hmm_dma_map *map, size_t idx)
 	if ((pfns[idx] & valid_dma) != valid_dma)
 		return false;
 
+	if (pfns[idx] & HMM_PFN_P2PDMA)
+		attrs |= DMA_ATTR_MMIO;
+
 	if (pfns[idx] & HMM_PFN_P2PDMA_BUS)
 		; /* no need to unmap bus address P2P mappings */
-	else if (dma_use_iova(state)) {
-		if (pfns[idx] & HMM_PFN_P2PDMA)
-			attrs |= DMA_ATTR_SKIP_CPU_SYNC;
+	else if (dma_use_iova(state))
 		dma_iova_unlink(dev, state, idx * map->dma_entry_size,
 				map->dma_entry_size, DMA_BIDIRECTIONAL, attrs);
-	} else if (dma_need_unmap(dev))
+	else if (dma_need_unmap(dev))
 		dma_unmap_phys(dev, dma_addrs[idx], map->dma_entry_size,
-			       DMA_BIDIRECTIONAL, 0);
+			       DMA_BIDIRECTIONAL, attrs);
 
 	pfns[idx] &=
 		~(HMM_PFN_DMA_MAPPED | HMM_PFN_P2PDMA | HMM_PFN_P2PDMA_BUS);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:40:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:40:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116867.1463122 (Exim 4.92)
	(envelope-from )
	id 1uvyaF-000550-1E; Tue, 09 Sep 2025 13:40:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116867.1463122; Tue, 09 Sep 2025 13:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyaE-00054t-Sx; Tue, 09 Sep 2025 13:40:30 +0000
Received: by outflank-mailman (input) for mailman id 1116867;
 Tue, 09 Sep 2025 13:40: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 1uvyP4-00067u-Ui
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:28:58 +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 edf26f7e-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:28:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 616B6601AB;
 Tue,  9 Sep 2025 13:28:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 849B1C4CEFB;
 Tue,  9 Sep 2025 13:28: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: edf26f7e-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424533;
	bh=7uEF0lKa6/2PTd5roUeWZMSJr/PVEy6yTszu34DH254=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Mpt2hgsJQLyoPhqjQriUYwGxGpWOvhlRgZACUtJZjHzMze/5G5TKeJL+AIhpyHxHM
	 vtE7nDo43ohKMBF9jSzvLXexcmcqvZC/y3uNm14s8yMrtQUg4js6SK/BCrc9vovOvy
	 m+/ZwBtY3Q1G+3xu+k84+QsJ/t1V9cxoPLxU52E20FJDPGZnEBXHN59+tO8YeP9uQZ
	 6cc03DpD9wq/4u9y1z6U4q62L+IvJgAhPZxl9KlxwRXT+EJ6mm07Qgk8GBpvwvcFFE
	 HITZ7A5WwXv0OciZ4Op8uJ/UR8Zev+4BsP82OybASTk3DMWQh9knb+FPHYLwK64zVG
	 XT3P1zTpAz7tA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 10/16] xen: swiotlb: Open code map_resource callback
Date: Tue,  9 Sep 2025 16:27:38 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

General dma_direct_map_resource() is going to be removed
in next patch, so simply open-code it in xen driver.

Reviewed-by: Juergen Gross 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 drivers/xen/swiotlb-xen.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index da1a7d3d377cf..dd7747a2de879 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -392,6 +392,25 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
 	}
 }
 
+static dma_addr_t xen_swiotlb_direct_map_resource(struct device *dev,
+						  phys_addr_t paddr,
+						  size_t size,
+						  enum dma_data_direction dir,
+						  unsigned long attrs)
+{
+	dma_addr_t dma_addr = paddr;
+
+	if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
+		dev_err_once(dev,
+			     "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
+			     &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
+		WARN_ON_ONCE(1);
+		return DMA_MAPPING_ERROR;
+	}
+
+	return dma_addr;
+}
+
 /*
  * Return whether the given device DMA address mask can be supported
  * properly.  For example, if your device can only drive the low 24-bits
@@ -426,5 +445,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
 	.alloc_pages_op = dma_common_alloc_pages,
 	.free_pages = dma_common_free_pages,
 	.max_mapping_size = swiotlb_max_mapping_size,
-	.map_resource = dma_direct_map_resource,
+	.map_resource = xen_swiotlb_direct_map_resource,
 };
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:42:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:42:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116910.1463150 (Exim 4.92)
	(envelope-from )
	id 1uvycX-0006ry-UC; Tue, 09 Sep 2025 13:42:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116910.1463150; Tue, 09 Sep 2025 13:42: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 1uvycX-0006rr-RM; Tue, 09 Sep 2025 13:42:53 +0000
Received: by outflank-mailman (input) for mailman id 1116910;
 Tue, 09 Sep 2025 13:42: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 1uvyPI-0005uM-L9
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29:12 +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 f7ae814e-8d80-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:29: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 9FDB94411F;
 Tue,  9 Sep 2025 13:29:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A74DAC4CEF4;
 Tue,  9 Sep 2025 13:29: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: f7ae814e-8d80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424549;
	bh=jQ3T/brRUziOQrtl/kGVlBSfi2tE0bxT371ZOGgDim4=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=nHwsQe9pTWoBdpjmDo2+n+5/JjBFwg/dIJmlZq+/ndbthLybHRer7dXzwBpSuEQ7i
	 WpgZESFOSYk0vymXIf70Ka4LsYpVS5vQw8F7smlUhzgUae5YWqaRUFJM4IwK3XdPU8
	 nQd69kJNsmstJsXKlBgipLCGMWJfYYqJE2rU2FkxR/cKCJArJmyICbqTFiX7qT52P6
	 bFJt/DsWpz8Ho6ieuoZtZR1VMlsPp35ivfkfFmrDlxi+gYH4TXCDlS/zFwml2ISjyT
	 4kyTMDiyaDIt3S9mhvAvhapMGPAO3w0XKnS9A0uiBpYOSAAbYn+JofRb8t5SlIv8X4
	 Nu/sGhPGyBQ1g==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 14/16] block-dma: migrate to dma_map_phys instead of map_page
Date: Tue,  9 Sep 2025 16:27:42 +0300
Message-ID: <0efc4a06258eb1cbedcee642263d8ba24c5e97e6.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

After introduction of dma_map_phys(), there is no need to convert
from physical address to struct page in order to map page. So let's
use it directly.

Reviewed-by: Keith Busch 
Signed-off-by: Leon Romanovsky 
---
 block/blk-mq-dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c
index ad283017caef2..37e2142be4f7d 100644
--- a/block/blk-mq-dma.c
+++ b/block/blk-mq-dma.c
@@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec)
 static bool blk_dma_map_direct(struct request *req, struct device *dma_dev,
 		struct blk_dma_iter *iter, struct phys_vec *vec)
 {
-	iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr),
-			offset_in_page(vec->paddr), vec->len, rq_dma_dir(req));
+	iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len,
+			rq_dma_dir(req), 0);
 	if (dma_mapping_error(dma_dev, iter->addr)) {
 		iter->status = BLK_STS_RESOURCE;
 		return false;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:42:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:42:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116909.1463140 (Exim 4.92)
	(envelope-from )
	id 1uvycV-0006cW-Nk; Tue, 09 Sep 2025 13:42:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116909.1463140; Tue, 09 Sep 2025 13:42: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 1uvycV-0006cP-Kw; Tue, 09 Sep 2025 13:42:51 +0000
Received: by outflank-mailman (input) for mailman id 1116909;
 Tue, 09 Sep 2025 13:42: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 1uvyPP-00067u-NR
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29:19 +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 fc7c6fcb-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:29:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id C05D3419CF;
 Tue,  9 Sep 2025 13:29:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1F67C4CEF5;
 Tue,  9 Sep 2025 13:29: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: fc7c6fcb-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424557;
	bh=wtwQANAMZgZyvB6tiFp96jG3UeEes+qCqSz/NoS3UPQ=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=RO8SwnvnOfqCFFo/OQtuk43y08F/9NiC0qo46QlPcxTa4eGVUHYLlbxNnl6dZ85H0
	 x20F6dmOkEPcmpHsf5R+/6fXBIjXKuBiWRMkaWwUQubRdIinqe54Txa6tN8WlX2eCE
	 TjNCykXDXDAKP22rhADMYKKG4IeQ/xdqjUNB9nFAhHvWm8XVmqmTnjP+KsZMgXmxER
	 U9ohR1NuEHfgYDgyAZHMIK03b2sbV6Yt6fuGDW5ZtsOhCz1qoFNEVy4A6MCZp4MaVA
	 K+CH97tUymCL5/6yV3iWa8ebvxIWwf3QpaIqoywL+4IYTWGZmoJfNhPPhhg16fdKRx
	 XixjO6eOuMVKQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 12/16] mm/hmm: migrate to physical address-based DMA mapping API
Date: Tue,  9 Sep 2025 16:27:40 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Convert HMM DMA operations from the legacy page-based API to the new
physical address-based dma_map_phys() and dma_unmap_phys() functions.
This demonstrates the preferred approach for new code that should use
physical addresses directly rather than page+offset parameters.

The change replaces dma_map_page() and dma_unmap_page() calls with
dma_map_phys() and dma_unmap_phys() respectively, using the physical
address that was already available in the code. This eliminates the
redundant page-to-physical address conversion and aligns with the
DMA subsystem's move toward physical address-centric interfaces.

This serves as an example of how new code should be written to leverage
the more efficient physical address API, which provides cleaner interfaces
for drivers that already have access to physical addresses.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 mm/hmm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index d545e24949949..015ab243f0813 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -775,8 +775,8 @@ dma_addr_t hmm_dma_map_pfn(struct device *dev, struct hmm_dma_map *map,
 		if (WARN_ON_ONCE(dma_need_unmap(dev) && !dma_addrs))
 			goto error;
 
-		dma_addr = dma_map_page(dev, page, 0, map->dma_entry_size,
-					DMA_BIDIRECTIONAL);
+		dma_addr = dma_map_phys(dev, paddr, map->dma_entry_size,
+					DMA_BIDIRECTIONAL, 0);
 		if (dma_mapping_error(dev, dma_addr))
 			goto error;
 
@@ -819,8 +819,8 @@ bool hmm_dma_unmap_pfn(struct device *dev, struct hmm_dma_map *map, size_t idx)
 		dma_iova_unlink(dev, state, idx * map->dma_entry_size,
 				map->dma_entry_size, DMA_BIDIRECTIONAL, attrs);
 	} else if (dma_need_unmap(dev))
-		dma_unmap_page(dev, dma_addrs[idx], map->dma_entry_size,
-			       DMA_BIDIRECTIONAL);
+		dma_unmap_phys(dev, dma_addrs[idx], map->dma_entry_size,
+			       DMA_BIDIRECTIONAL, 0);
 
 	pfns[idx] &=
 		~(HMM_PFN_DMA_MAPPED | HMM_PFN_P2PDMA | HMM_PFN_P2PDMA_BUS);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:49:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:49:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116941.1463161 (Exim 4.92)
	(envelope-from )
	id 1uvyii-0007vx-Jj; Tue, 09 Sep 2025 13:49:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116941.1463161; Tue, 09 Sep 2025 13:49: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 1uvyii-0007vq-Gq; Tue, 09 Sep 2025 13:49:16 +0000
Received: by outflank-mailman (input) for mailman id 1116941;
 Tue, 09 Sep 2025 13:49: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 1uvyih-0007vk-AM
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:49:15 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2415::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c3f9c3f2-8d83-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:49:12 +0200 (CEST)
Received: from MW4PR04CA0172.namprd04.prod.outlook.com (2603:10b6:303:85::27)
 by DS7PR12MB9042.namprd12.prod.outlook.com (2603:10b6:8:ed::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 13:49:09 +0000
Received: from CO1PEPF000044F5.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::c4) by MW4PR04CA0172.outlook.office365.com
 (2603:10b6:303:85::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Tue,
 9 Sep 2025 13:49:09 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CO1PEPF000044F5.mail.protection.outlook.com (10.167.241.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Tue, 9 Sep 2025 13:49:09 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 9 Sep
 2025 06:49:05 -0700
Received: from [192.168.29.198] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Tue, 9 Sep 2025 06:49:05 -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: c3f9c3f2-8d83-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eAWfHIBTW/Z9di8PXNdUiB2nG3cEanApmDyW3tHo/nEzEjORlV99t1sUMR9C/MTW7R6JuyU2MDOv7E6g57U9dd3vzQqzRZeeKKu2jS9VI7jIqbO1n8FRtkAHxT1BCW2rZQ1FGDfW9FYoeClcTOQi9Qgn2MsSsUfd3YZWQBMWdR9DdFAIij+uC2MGnc30zFHNjw3MBl2U+1FP2uRnpP8EodyOGASy1Mc4vmJ4nbcPiJ1+AmbKmAoWSjUInzqtUMy8jbs4h+TeMsUkaQCbXDUwRLzVlr305Wj7TZXtnRLhbHIjR0apdfy0hv/5VbbsHwfUfJGt702YPa3PegARGFhwWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xeeoystyVUbnYS2u183/jG+eMUB6+ooMWgEdXGHSN1I=;
 b=efoev2ukoTPob2kyeuGQc+CdfOvq33PMZEF3ig8Y/6+HBzg6TUgXxaSjzNXIjjc1DmPT4+hExLN3sBnboYc6BtTHpwIWn+O9ag6NBliSrU9j7UM+vrpxCPjsppJrmTcVAMWZtAG05vYHYxTX61Wf7mC/+HUBxnCVfRS0bhjy1kcK1XtPFH+9BcETlOZkEQE+SZu93gFyw1ANwLoqukKPbi+gi+cxI8ekrPAUjeIsEbThZbG/vWok1TUn77IqlisITopc7cfLNpzpKGAVJDrspxd3AnKeflrg+uSxYbwJvSp6H+/s0G4OZs3z8l8QILSGaLwONR7/e/BbPPPRw00hLw==
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=xeeoystyVUbnYS2u183/jG+eMUB6+ooMWgEdXGHSN1I=;
 b=bllSu4CFpB2muezLAx8TzJu4hoknniD3Ot96uqqwkds+MD6oPGwtbfHE3CSFfHKistpVovvrPeaCm427/O14Ku2mg930RpDv0mwELb+Lhh04cnamaPYPiqjL3Fi04KnwZ1eYmXD9HzjP3qkvqrDCN4OjwulDFrFavwMJfoubRWA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <92222795-8509-42a3-9e4e-47958cfe47d3@amd.com>
Date: Tue, 9 Sep 2025 09:49:06 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/IO-APIC: drop io_apic_get_unique_id()
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	"consulting@bugseng.com" 
References: 
 <80c035e0-54f6-4632-a5c2-a10d2c1c8422@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <80c035e0-54f6-4632-a5c2-a10d2c1c8422@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: CO1PEPF000044F5:EE_|DS7PR12MB9042:EE_
X-MS-Office365-Filtering-Correlation-Id: 15a41b91-0129-4685-3e53-08ddefa7a6af
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?N2VDT2JrcHJFdHd5K2xSaXVVRHprWjlQYWh3azlOQmRiOE40bTczZ085aEdP?=
 =?utf-8?B?am1QWmYxREdQTVczSnpIQ0dHemZZV2FzVVRKellldDhrTk5GRGpLdUg4Zkpm?=
 =?utf-8?B?ejhvNUJjVUZ4bmxGZm95Tm5IaVVkUDlBdmVCWDNLcGcyVHBBY0R5d1NPVW15?=
 =?utf-8?B?VkNBNmpLYmxTMUJoY2JuUDNjS2VZeG5INjV2RFU0VDVQSkxkNlBMZWRCaVhS?=
 =?utf-8?B?LzhqUWdwVmlFUUY4cWNQZTZaUU1FMHlEeFR0bUtUNlZ0eDRudE0wRzl5Q2xx?=
 =?utf-8?B?K2N2dG9WalplQTEvcndIK3RudVlPQ2hkbFVOeFNtR0NqbHFHVlRuT3pkSFZM?=
 =?utf-8?B?RlQrK01iYjYxeU9DQUxLa1RhMGl4bk8wa3RlbmxvenlTOXNkNG0vL1d6aHNE?=
 =?utf-8?B?RWxJSWpQZ0pheWh1R2k2SzVYeGtiOC9tREUxUVdZakRCNDhmQUVkOUJpcm5r?=
 =?utf-8?B?eHRKK281UTVvSUp1VkV1Ni9JbXZsS01WcXFHeXJGbEtyMkF5ZDhJeWNXSHhh?=
 =?utf-8?B?VENzRkxrMERKSXowSHh5Z2crM2VnOXlJMGdVcGdaV1JzcmkyWDN5VzRCSHBo?=
 =?utf-8?B?UXZzUmhSV0hrdVBsRi94NEJwSks3d0Q5MlR4SVVhZmV3Tzg2bXB0bk1wTnJ1?=
 =?utf-8?B?QitjZFZESi9wbnhaMXVqejBnWFdxaC8xMVJnOWgvM1Z5aVlNcmJyT3k4cXNj?=
 =?utf-8?B?TjVqK3Zodnp1ZjlaNEQwTFprQlN5dndOamt2b3k5aWI5RVJhTjhsWEs1NEha?=
 =?utf-8?B?SFBaRk5iSHlma0FSSTNJVVBiM0J1MW45LzUyRUJBMkozOVRGMW9xbDJLSTEy?=
 =?utf-8?B?U1BiVTNhd2NMQkFsVmpZZTZaTXpQUkkxcVNBNjhRb1BiVUlyL25SdTV2SVpx?=
 =?utf-8?B?TVppMmRacm52blZFNkNhVGJULzlMVW1VcnNORTV5aXlkVWFkRlZHaFNiMW02?=
 =?utf-8?B?N3UrRUtvZm9McFJMTEQ2dE1lUFRpQ2VwaDNFdG50RUZXdHBBbzVSMk8yV3B5?=
 =?utf-8?B?YUJtMVQ1bS8rVzFlc1M3MWhZd0Z5eEJ0RE5oWFMwNEVVWnlmWlNKL1ZrQWVx?=
 =?utf-8?B?WUdiMUcxeFZBVlV3bm5WODNYUVlzaHdjV1R1TmQ1Y2h3V1hIOExKWW9ZZ3VM?=
 =?utf-8?B?V2dVL1IvSGNScFU1c3NOQ21qNEUvQ2VtMldXdnE5S2VMbXRyVWM2R0ZINVpZ?=
 =?utf-8?B?NnZUckgwdElBcENpOXBjT1licmoyTWE0a3ppNEtpSWk2T0JieG5RZUdPZkZ5?=
 =?utf-8?B?cUZIS2pyeG13RTFZcUtMTHg5dVRLQUg3dC82MTF0QVVuL3BoYTM3UHhNL09I?=
 =?utf-8?B?eGZhaThWZmhnak5BSjhlb3NhTXNEdzJWZHp3OVgwbjZvYkViNkN6TGNkUzEx?=
 =?utf-8?B?NTBsRG90dU5jWlNFTHJSeEFaQnpxSE5ncmM3YUlYWkplNkJRbi9KWFZ2Q0dy?=
 =?utf-8?B?bDNTaE4wZG9zODJqQzY2Ky9vUUJSQlNhY1VHcEFqZEFpNGFzaDZUM2Z6U2g0?=
 =?utf-8?B?Z0xvZXNNUHZqZDZReFVJaXloZDA2eFVMYmZ1eTdDekp3OEpaNnBsaUJxSnZt?=
 =?utf-8?B?TnZJbU15OEhtR2l0bzhMQkVIK3Q2NWZ3YzNVMHg3dGQ4dHFTdmdtQVppUWFP?=
 =?utf-8?B?WHhkZS9YQzRYK1UreHJnc1lWK05Ma1VReHQ5UGVxVUVBUUNndGpva0JyUkhl?=
 =?utf-8?B?Z1ppQmErekpyamhLZWxQenM5c3RyekVTTTZpRUZ3OGZTRVd4cWJYMmJKL25Z?=
 =?utf-8?B?czdHNnp4RHNrcStnTGxJTzNpcEx4RmwwR2JYOWVjZjZSNWI4cmo3RmtxejRE?=
 =?utf-8?B?TFZNL0xkbFlkRzZBS3FFLzZGRkZDRUpEWEFpb2libkdCelBMWnRpYXpURWhj?=
 =?utf-8?B?NURIc0lRc01ibmtub0NyTlJKQjZvQ0NPb1BmYTNVdnZYMXNZM2ZyR2MxMFkv?=
 =?utf-8?B?a0VZWmhBKytMREJ4bThOanR3dlNycGY1S21rc2s1bkZNY1c4UERBeE5VcXAv?=
 =?utf-8?B?WkdFTjU2MFpxeHBVV0xML3NxUFNEMVo1ZWNndENCODNpa09ta2Q5L3NxTC9k?=
 =?utf-8?Q?UjnBQ6?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 09 Sep 2025 13:49:09.0220
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 15a41b91-0129-4685-3e53-08ddefa7a6af
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000044F5.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9042

On 2025-09-03 03:56, Jan Beulich wrote:
> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
> said, the function is dead logic as well: All 64-bit capable Intel systems
> have (at least) xAPIC (if not x2APIC).
> 
> Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
> code; we didn't accept that yet, but - where possible - we probably would
> better follow it). Depending on one's reading, this code may actually be a
> violation of rule 2.1 (unreachable), which we did accept:
> 
> "Code is unreachable if, ..., there is no combination of program inputs
>   that can cause it to be executed."
> 
> Otoh it's "only" __init code.
> 
> As this removes the last user of APIC_XAPIC(), remove the macro as well.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:50:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:50:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116948.1463171 (Exim 4.92)
	(envelope-from )
	id 1uvyjQ-0008WT-SD; Tue, 09 Sep 2025 13:50:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116948.1463171; Tue, 09 Sep 2025 13: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 1uvyjQ-0008WM-PQ; Tue, 09 Sep 2025 13:50:00 +0000
Received: by outflank-mailman (input) for mailman id 1116948;
 Tue, 09 Sep 2025 13: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 1uvyjP-0007vk-Kk
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:49:59 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id deee2d64-8d83-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:49: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 0F1831424;
 Tue,  9 Sep 2025 06:49:48 -0700 (PDT)
Received: from [10.44.160.77] (e126510-lin.lund.arm.com [10.44.160.77])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E3393F694;
 Tue,  9 Sep 2025 06:49: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: deee2d64-8d83-11f0-9809-7dc792cee155
Message-ID: <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
Date: Tue, 9 Sep 2025 15:49:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 13:54, David Hildenbrand wrote:
> On 09.09.25 13:45, Alexander Gordeev wrote:
>> On Tue, Sep 09, 2025 at 12:09:48PM +0200, David Hildenbrand wrote:
>>> On 09.09.25 11:40, Alexander Gordeev wrote:
>>>> On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
>>>>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>>>>> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
>>>>>> (taking and returning no value). This is proving problematic in
>>>>>> situations where leave() needs to restore some context back to its
>>>>>> original state (before enter() was called). In particular, this
>>>>>> makes it difficult to support the nesting of lazy_mmu sections -
>>>>>> leave() does not know whether the matching enter() call occurred
>>>>>> while lazy_mmu was already enabled, and whether to disable it or
>>>>>> not.
>>>>>>
>>>>>> This patch gives all architectures the chance to store local state
>>>>>> while inside a lazy_mmu section by making enter() return some value,
>>>>>> storing it in a local variable, and having leave() take that value.
>>>>>> That value is typed lazy_mmu_state_t - each architecture defining
>>>>>> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
>>>>>> For now we define it as int everywhere, which is sufficient to
>>>>>> support nesting.
>>>> ...
>>>>>> {
>>>>>> + lazy_mmu_state_t lazy_mmu_state;
>>>>>> ...
>>>>>> - arch_enter_lazy_mmu_mode();
>>>>>> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
>>>>>> ...
>>>>>> - arch_leave_lazy_mmu_mode();
>>>>>> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
>>>>>>      lazy_mmu is already enabled, and it temporarily disables it by
>>>>>>      calling leave() and then enter() again. Here we want to ensure
>>>>>>      that any operation between the leave() and enter() calls is
>>>>>>      completed immediately; for that reason we pass
>>>>>> LAZY_MMU_DEFAULT to
>>>>>>      leave() to fully disable lazy_mmu. enter() will then
>>>>>> re-enable it
>>>>>>      - this achieves the expected behaviour, whether nesting
>>>>>> occurred
>>>>>>      before that function was called or not.
>>>>>>
>>>>>> Note: it is difficult to provide a default definition of
>>>>>> lazy_mmu_state_t for architectures implementing lazy_mmu, because
>>>>>> that definition would need to be available in
>>>>>> arch/x86/include/asm/paravirt_types.h and adding a new generic
>>>>>>     #include there is very tricky due to the existing header soup.
>>>>>
>>>>> Yeah, I was wondering about exactly that.
>>>>>
>>>>> In particular because LAZY_MMU_DEFAULT etc resides somewehere
>>>>> compeltely
>>>>> different.
>>>>>
>>>>> Which raises the question: is using a new type really of any
>>>>> benefit here?
>>>>>
>>>>> Can't we just use an "enum lazy_mmu_state" and call it a day?
>>>>
>>>> I could envision something completely different for this type on s390,
>>>> e.g. a pointer to a per-cpu structure. So I would really ask to stick
>>>> with the current approach.

This is indeed the motivation - let every arch do whatever it sees fit.
lazy_mmu_state_t is basically an opaque type as far as generic code is
concerned, which also means that this API change is the first and last
one we need (famous last words, I know). 

I mentioned in the cover letter that the pkeys-based page table
protection series [1] would have an immediate use for lazy_mmu_state_t.
In that proposal, any helper writing to pgtables needs to modify the
pkey register and then restore it. To reduce the overhead, lazy_mmu is
used to set the pkey register only once in enter(), and then restore it
in leave() [2]. This currently relies on storing the original pkey
register value in thread_struct, which is suboptimal and most
importantly doesn't work if lazy_mmu sections nest. With this series, we
could instead store the pkey register value in lazy_mmu_state_t
(enlarging it to 64 bits or more).

I also considered going further and making lazy_mmu_state_t a pointer as
Alexander suggested - more complex to manage, but also a lot more flexible.

>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>>
>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
>> want to use it - at least that is how I read the description above.
>>
>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
>> that do not follow this pattern, and it looks as a problem to me.

This discussion also made me realise that this is problematic, as the
LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
convenience, not for generic code (where lazy_mmu_state_t should ideally
be an opaque type as mentioned above). It almost feels like the kasan
case deserves a different API, because this is not how enter() and
leave() are meant to be used. This would mean quite a bit of churn
though, so maybe just introduce another arch-defined value to pass to
leave() for such a situation - for instance,
arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?

>
> Yes, that's why I am asking.
>
> What kind of information (pointer to a per-cpu structure) would you
> want to return, and would handling it similar to how
> pagefault_disable()/pagefault_enable() e.g., using a variable in
> "current" to track the nesting level avoid having s390x to do that?

The pagefault_disabled approach works fine for simple use-cases, but it
doesn't scale well. The space allocated in task_struct/thread_struct to
track that state is wasted (unused) most of the time. Worse, it does not
truly enable states to be nested: it allows the outermost section to
store some state, but nested sections cannot allocate extra space. This
is really what the stack is for.

- Kevin


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:50:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:50:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116950.1463182 (Exim 4.92)
	(envelope-from )
	id 1uvyjX-0001Dx-9t; Tue, 09 Sep 2025 13:50:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116950.1463182; Tue, 09 Sep 2025 13: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 1uvyjX-0001Dq-4R; Tue, 09 Sep 2025 13:50:07 +0000
Received: by outflank-mailman (input) for mailman id 1116950;
 Tue, 09 Sep 2025 13:50: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 1uvyPT-00067u-N2
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29:23 +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 ff202714-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:29: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 1B15F6022C;
 Tue,  9 Sep 2025 13:29:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7C94C4CEF5;
 Tue,  9 Sep 2025 13:29: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: ff202714-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424561;
	bh=iTHTFebdJnIM4qjuR28g9oSbyH9qTLhzazcpZ251F1w=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=jsG+qsUJK7ffZ/z3OPchqA7x0yHguyPrENB1hNDceKyevn8Y0UY23vIlJKogKoOAV
	 mdweaZvTaV73xdPNvzuLcSgBCkcKJinDpA+AFFif7FJFzPv/yP0eacNr7loyHWPJQl
	 oDjSg5lytMZ5QZs3srGmQGs2aZnhiieWxGdijxV8InWTHYLEbMLD5nMB8zsJzQ7Y5/
	 n6m5X6Og8JA73w+GsQKGuK+FDZc8VM+Pv/R0ANeQAPkMSUkS/Z7Crlwiferwk3j/aY
	 bciFy1DVrMp5bQJF6IrE2GwiFytJBqVGnuxPc5FU5fznd5ZzC/Ro1XzYA9SknCnnqK
	 nq4YmMAH6+QaA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 16/16] nvme-pci: unmap MMIO pages with appropriate interface
Date: Tue,  9 Sep 2025 16:27:44 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Block layer maps MMIO memory through dma_map_phys() interface
with help of DMA_ATTR_MMIO attribute. There is a need to unmap
that memory with the appropriate unmap function, something which
wasn't possible before adding new REQ attribute to block layer in
previous patch.

Reviewed-by: Keith Busch 
Signed-off-by: Leon Romanovsky 
---
 drivers/nvme/host/pci.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 2c6d9506b1725..f8ecc0e0f576d 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -682,11 +682,15 @@ static void nvme_free_prps(struct request *req)
 {
 	struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
 	struct nvme_queue *nvmeq = req->mq_hctx->driver_data;
+	unsigned int attrs = 0;
 	unsigned int i;
 
+	if (req->cmd_flags & REQ_MMIO)
+		attrs = DMA_ATTR_MMIO;
+
 	for (i = 0; i < iod->nr_dma_vecs; i++)
-		dma_unmap_page(nvmeq->dev->dev, iod->dma_vecs[i].addr,
-				iod->dma_vecs[i].len, rq_dma_dir(req));
+		dma_unmap_phys(nvmeq->dev->dev, iod->dma_vecs[i].addr,
+				iod->dma_vecs[i].len, rq_dma_dir(req), attrs);
 	mempool_free(iod->dma_vecs, nvmeq->dev->dmavec_mempool);
 }
 
@@ -699,15 +703,19 @@ static void nvme_free_sgls(struct request *req)
 	unsigned int sqe_dma_len = le32_to_cpu(iod->cmd.common.dptr.sgl.length);
 	struct nvme_sgl_desc *sg_list = iod->descriptors[0];
 	enum dma_data_direction dir = rq_dma_dir(req);
+	unsigned int attrs = 0;
+
+	if (req->cmd_flags & REQ_MMIO)
+		attrs = DMA_ATTR_MMIO;
 
 	if (iod->nr_descriptors) {
 		unsigned int nr_entries = sqe_dma_len / sizeof(*sg_list), i;
 
 		for (i = 0; i < nr_entries; i++)
-			dma_unmap_page(dma_dev, le64_to_cpu(sg_list[i].addr),
-				le32_to_cpu(sg_list[i].length), dir);
+			dma_unmap_phys(dma_dev, le64_to_cpu(sg_list[i].addr),
+				le32_to_cpu(sg_list[i].length), dir, attrs);
 	} else {
-		dma_unmap_page(dma_dev, sqe_dma_addr, sqe_dma_len, dir);
+		dma_unmap_phys(dma_dev, sqe_dma_addr, sqe_dma_len, dir, attrs);
 	}
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:50:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:50:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116968.1463191 (Exim 4.92)
	(envelope-from )
	id 1uvyjr-00022C-G9; Tue, 09 Sep 2025 13:50:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116968.1463191; Tue, 09 Sep 2025 13:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyjr-000225-DJ; Tue, 09 Sep 2025 13:50:27 +0000
Received: by outflank-mailman (input) for mailman id 1116968;
 Tue, 09 Sep 2025 13:50: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 1uvyP7-0005uM-7t
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29:01 +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 f0be845d-8d80-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:28:59 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id E5D6C6022D;
 Tue,  9 Sep 2025 13:28:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6695C4CEFA;
 Tue,  9 Sep 2025 13:28: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: f0be845d-8d80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424537;
	bh=QzjTHFMcV2W/5P/ldKCH95efR5qUSLI1FF7g8V1uFGw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=JTgdL60zD3UJXI4gCha6KqVDuo0b2V/MsKfYe5rqT1rpiO1zHAisrX6NHYNl1YTL9
	 1BZAulAj/xq7Mr71bCrEJpFMYgmkTJac1rQuN9118uzujvklLr0ikmUuWqwn/4qeJ0
	 CMsXqHZoQV7ZgXP6ZLGqVSjhiaanETQoE9spixOk3rr6yiRo380zkGztEuQma5U7Em
	 jYV1joGUv8d0KqoodraObSpTvuadiugTTGzq84cgQoNloYkD+NsnhnlAyMzZTqoKcS
	 0lk5XfObyjhKNxaRT6PVP9iyvivqh1ZaOc6trkMp5uHD2w0wF9LKYz7PbajootemPu
	 HSTZaxfv1hNUA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 11/16] dma-mapping: export new dma_*map_phys() interface
Date: Tue,  9 Sep 2025 16:27:39 +0300
Message-ID: <54cc52af91777906bbe4a386113437ba0bcfba9c.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys()
that operate directly on physical addresses instead of page+offset
parameters. This provides a more efficient interface for drivers that
already have physical addresses available.

The new functions are implemented as the primary mapping layer, with
the existing dma_map_page_attrs()/dma_map_resource() and
dma_unmap_page_attrs()/dma_unmap_resource() functions converted to simple
wrappers around the phys-based implementations.

In case dma_map_page_attrs(), the struct page is converted to physical
address with help of page_to_phys() function and dma_map_resource()
provides physical address as is together with addition of DMA_ATTR_MMIO
attribute.

The old page-based API is preserved in mapping.c to ensure that existing
code won't be affected by changing EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
variant for dma_*map_phys().

Reviewed-by: Jason Gunthorpe 
Reviewed-by: Keith Busch 
Signed-off-by: Leon Romanovsky 
---
 drivers/iommu/dma-iommu.c   | 14 --------
 include/linux/dma-direct.h  |  2 --
 include/linux/dma-mapping.h | 13 +++++++
 include/linux/iommu-dma.h   |  4 ---
 include/trace/events/dma.h  |  2 --
 kernel/dma/debug.c          | 43 -----------------------
 kernel/dma/debug.h          | 21 -----------
 kernel/dma/direct.c         | 16 ---------
 kernel/dma/mapping.c        | 69 ++++++++++++++++++++-----------------
 9 files changed, 50 insertions(+), 134 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 6804aaf034a16..7944a3af4545e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1556,20 +1556,6 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 		__iommu_dma_unmap(dev, start, end - start);
 }
 
-dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
-		size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-	return __iommu_dma_map(dev, phys, size,
-			dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO,
-			dma_get_mask(dev));
-}
-
-void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-	__iommu_dma_unmap(dev, handle, size);
-}
-
 static void __iommu_dma_free(struct device *dev, size_t size, void *cpu_addr)
 {
 	size_t alloc_size = PAGE_ALIGN(size);
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index f3bc0bcd70980..c249912456f96 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -149,7 +149,5 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 		struct page *page, dma_addr_t dma_addr,
 		enum dma_data_direction dir);
 int dma_direct_supported(struct device *dev, u64 mask);
-dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
-		size_t size, enum dma_data_direction dir, unsigned long attrs);
 
 #endif /* _LINUX_DMA_DIRECT_H */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4254fd9bdf5dd..8248ff9363eed 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -138,6 +138,10 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		unsigned long attrs);
 void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 		enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		enum dma_data_direction dir, unsigned long attrs);
+void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size,
+		enum dma_data_direction dir, unsigned long attrs);
 unsigned int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
 		int nents, enum dma_data_direction dir, unsigned long attrs);
 void dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg,
@@ -192,6 +196,15 @@ static inline void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 }
+static inline dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys,
+		size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+	return DMA_MAPPING_ERROR;
+}
+static inline void dma_unmap_phys(struct device *dev, dma_addr_t addr,
+		size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+}
 static inline unsigned int dma_map_sg_attrs(struct device *dev,
 		struct scatterlist *sg, int nents, enum dma_data_direction dir,
 		unsigned long attrs)
diff --git a/include/linux/iommu-dma.h b/include/linux/iommu-dma.h
index 485bdffed9888..a92b3ff9b9343 100644
--- a/include/linux/iommu-dma.h
+++ b/include/linux/iommu-dma.h
@@ -42,10 +42,6 @@ size_t iommu_dma_opt_mapping_size(void);
 size_t iommu_dma_max_mapping_size(struct device *dev);
 void iommu_dma_free(struct device *dev, size_t size, void *cpu_addr,
 		dma_addr_t handle, unsigned long attrs);
-dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
-		size_t size, enum dma_data_direction dir, unsigned long attrs);
-void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir, unsigned long attrs);
 struct sg_table *iommu_dma_alloc_noncontiguous(struct device *dev, size_t size,
 		enum dma_data_direction dir, gfp_t gfp, unsigned long attrs);
 void iommu_dma_free_noncontiguous(struct device *dev, size_t size,
diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h
index 84416c7d6bfaa..5da59fd8121db 100644
--- a/include/trace/events/dma.h
+++ b/include/trace/events/dma.h
@@ -73,7 +73,6 @@ DEFINE_EVENT(dma_map, name, \
 	TP_ARGS(dev, phys_addr, dma_addr, size, dir, attrs))
 
 DEFINE_MAP_EVENT(dma_map_phys);
-DEFINE_MAP_EVENT(dma_map_resource);
 
 DECLARE_EVENT_CLASS(dma_unmap,
 	TP_PROTO(struct device *dev, dma_addr_t addr, size_t size,
@@ -111,7 +110,6 @@ DEFINE_EVENT(dma_unmap, name, \
 	TP_ARGS(dev, addr, size, dir, attrs))
 
 DEFINE_UNMAP_EVENT(dma_unmap_phys);
-DEFINE_UNMAP_EVENT(dma_unmap_resource);
 
 DECLARE_EVENT_CLASS(dma_alloc_class,
 	TP_PROTO(struct device *dev, void *virt_addr, dma_addr_t dma_addr,
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index b275db9ca6a03..1e5c64cb6a421 100644
--- a/kernel/dma/debug.c
+++ b/kernel/dma/debug.c
@@ -38,7 +38,6 @@ enum {
 	dma_debug_single,
 	dma_debug_sg,
 	dma_debug_coherent,
-	dma_debug_resource,
 	dma_debug_noncoherent,
 	dma_debug_phy,
 };
@@ -142,7 +141,6 @@ static const char *type2name[] = {
 	[dma_debug_single] = "single",
 	[dma_debug_sg] = "scatter-gather",
 	[dma_debug_coherent] = "coherent",
-	[dma_debug_resource] = "resource",
 	[dma_debug_noncoherent] = "noncoherent",
 	[dma_debug_phy] = "phy",
 };
@@ -1446,47 +1444,6 @@ void debug_dma_free_coherent(struct device *dev, size_t size,
 	check_unmap(&ref);
 }
 
-void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
-			    int direction, dma_addr_t dma_addr,
-			    unsigned long attrs)
-{
-	struct dma_debug_entry *entry;
-
-	if (unlikely(dma_debug_disabled()))
-		return;
-
-	entry = dma_entry_alloc();
-	if (!entry)
-		return;
-
-	entry->type		= dma_debug_resource;
-	entry->dev		= dev;
-	entry->paddr		= addr;
-	entry->size		= size;
-	entry->dev_addr		= dma_addr;
-	entry->direction	= direction;
-	entry->map_err_type	= MAP_ERR_NOT_CHECKED;
-
-	add_dma_entry(entry, attrs);
-}
-
-void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
-			      size_t size, int direction)
-{
-	struct dma_debug_entry ref = {
-		.type           = dma_debug_resource,
-		.dev            = dev,
-		.dev_addr       = dma_addr,
-		.size           = size,
-		.direction      = direction,
-	};
-
-	if (unlikely(dma_debug_disabled()))
-		return;
-
-	check_unmap(&ref);
-}
-
 void debug_dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
 				   size_t size, int direction)
 {
diff --git a/kernel/dma/debug.h b/kernel/dma/debug.h
index bedae973e725d..da7be0bddcf67 100644
--- a/kernel/dma/debug.h
+++ b/kernel/dma/debug.h
@@ -30,14 +30,6 @@ extern void debug_dma_alloc_coherent(struct device *dev, size_t size,
 extern void debug_dma_free_coherent(struct device *dev, size_t size,
 				    void *virt, dma_addr_t addr);
 
-extern void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
-				   size_t size, int direction,
-				   dma_addr_t dma_addr,
-				   unsigned long attrs);
-
-extern void debug_dma_unmap_resource(struct device *dev, dma_addr_t dma_addr,
-				     size_t size, int direction);
-
 extern void debug_dma_sync_single_for_cpu(struct device *dev,
 					  dma_addr_t dma_handle, size_t size,
 					  int direction);
@@ -95,19 +87,6 @@ static inline void debug_dma_free_coherent(struct device *dev, size_t size,
 {
 }
 
-static inline void debug_dma_map_resource(struct device *dev, phys_addr_t addr,
-					  size_t size, int direction,
-					  dma_addr_t dma_addr,
-					  unsigned long attrs)
-{
-}
-
-static inline void debug_dma_unmap_resource(struct device *dev,
-					    dma_addr_t dma_addr, size_t size,
-					    int direction)
-{
-}
-
 static inline void debug_dma_sync_single_for_cpu(struct device *dev,
 						 dma_addr_t dma_handle,
 						 size_t size, int direction)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index fa75e30700730..1062caac47e7b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -502,22 +502,6 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
 	return ret;
 }
 
-dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
-		size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-	dma_addr_t dma_addr = paddr;
-
-	if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
-		dev_err_once(dev,
-			     "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
-			     &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
-		WARN_ON_ONCE(1);
-		return DMA_MAPPING_ERROR;
-	}
-
-	return dma_addr;
-}
-
 int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
 		void *cpu_addr, dma_addr_t dma_addr, size_t size,
 		unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 95eab531e2273..fe7472f13b106 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -152,12 +152,10 @@ static inline bool dma_map_direct(struct device *dev,
 	return dma_go_direct(dev, *dev->dma_mask, ops);
 }
 
-dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
-		size_t offset, size_t size, enum dma_data_direction dir,
-		unsigned long attrs)
+dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		enum dma_data_direction dir, unsigned long attrs)
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
-	phys_addr_t phys = page_to_phys(page) + offset;
 	bool is_mmio = attrs & DMA_ATTR_MMIO;
 	dma_addr_t addr;
 
@@ -177,6 +175,9 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 
 		addr = ops->map_resource(dev, phys, size, dir, attrs);
 	} else {
+		struct page *page = phys_to_page(phys);
+		size_t offset = offset_in_page(phys);
+
 		/*
 		 * The dma_ops API contract for ops->map_page() requires
 		 * kmappable memory, while ops->map_resource() does not.
@@ -191,9 +192,26 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 
 	return addr;
 }
+EXPORT_SYMBOL_GPL(dma_map_phys);
+
+dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
+		size_t offset, size_t size, enum dma_data_direction dir,
+		unsigned long attrs)
+{
+	phys_addr_t phys = page_to_phys(page) + offset;
+
+	if (unlikely(attrs & DMA_ATTR_MMIO))
+		return DMA_MAPPING_ERROR;
+
+	if (IS_ENABLED(CONFIG_DMA_API_DEBUG) &&
+	    WARN_ON_ONCE(is_zone_device_page(page)))
+		return DMA_MAPPING_ERROR;
+
+	return dma_map_phys(dev, phys, size, dir, attrs);
+}
 EXPORT_SYMBOL(dma_map_page_attrs);
 
-void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
+void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size,
 		enum dma_data_direction dir, unsigned long attrs)
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
@@ -213,6 +231,16 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
 	debug_dma_unmap_phys(dev, addr, size, dir);
 }
+EXPORT_SYMBOL_GPL(dma_unmap_phys);
+
+void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
+		 enum dma_data_direction dir, unsigned long attrs)
+{
+	if (unlikely(attrs & DMA_ATTR_MMIO))
+		return;
+
+	dma_unmap_phys(dev, addr, size, dir, attrs);
+}
 EXPORT_SYMBOL(dma_unmap_page_attrs);
 
 static int __dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
@@ -338,41 +366,18 @@ EXPORT_SYMBOL(dma_unmap_sg_attrs);
 dma_addr_t dma_map_resource(struct device *dev, phys_addr_t phys_addr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	const struct dma_map_ops *ops = get_dma_ops(dev);
-	dma_addr_t addr = DMA_MAPPING_ERROR;
-
-	BUG_ON(!valid_dma_direction(dir));
-
-	if (WARN_ON_ONCE(!dev->dma_mask))
+	if (IS_ENABLED(CONFIG_DMA_API_DEBUG) &&
+	    WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr))))
 		return DMA_MAPPING_ERROR;
 
-	if (dma_map_direct(dev, ops))
-		addr = dma_direct_map_resource(dev, phys_addr, size, dir, attrs);
-	else if (use_dma_iommu(dev))
-		addr = iommu_dma_map_resource(dev, phys_addr, size, dir, attrs);
-	else if (ops->map_resource)
-		addr = ops->map_resource(dev, phys_addr, size, dir, attrs);
-
-	trace_dma_map_resource(dev, phys_addr, addr, size, dir, attrs);
-	debug_dma_map_resource(dev, phys_addr, size, dir, addr, attrs);
-	return addr;
+	return dma_map_phys(dev, phys_addr, size, dir, attrs | DMA_ATTR_MMIO);
 }
 EXPORT_SYMBOL(dma_map_resource);
 
 void dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size,
 		enum dma_data_direction dir, unsigned long attrs)
 {
-	const struct dma_map_ops *ops = get_dma_ops(dev);
-
-	BUG_ON(!valid_dma_direction(dir));
-	if (dma_map_direct(dev, ops))
-		; /* nothing to do: uncached and no swiotlb */
-	else if (use_dma_iommu(dev))
-		iommu_dma_unmap_resource(dev, addr, size, dir, attrs);
-	else if (ops->unmap_resource)
-		ops->unmap_resource(dev, addr, size, dir, attrs);
-	trace_dma_unmap_resource(dev, addr, size, dir, attrs);
-	debug_dma_unmap_resource(dev, addr, size, dir);
+	dma_unmap_phys(dev, addr, size, dir, attrs | DMA_ATTR_MMIO);
 }
 EXPORT_SYMBOL(dma_unmap_resource);
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1116982.1463201 (Exim 4.92)
	(envelope-from )
	id 1uvykA-0002gh-Nh; Tue, 09 Sep 2025 13:50:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1116982.1463201; Tue, 09 Sep 2025 13: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 1uvykA-0002gY-Kj; Tue, 09 Sep 2025 13:50:46 +0000
Received: by outflank-mailman (input) for mailman id 1116982;
 Tue, 09 Sep 2025 13: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 1uvyPB-00067u-0A
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:29: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 f355c361-8d80-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 15:29: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 6C5B360230;
 Tue,  9 Sep 2025 13:29:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DA0AC4CEFB;
 Tue,  9 Sep 2025 13:29: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: f355c361-8d80-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757424542;
	bh=OcM9fkdXGiKETEVH8cBKggBd8afyqoLB0RolB6LyNkA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Yn9O7EXt2i8TlTaF6Sd1iT2ojuajj2KIE2jrl5UhotsRQnaPwquEa2I6cD/7jlt78
	 XzUOKFVinPt3koMpplOVHfrrycPx1YW4URaCTEj9GV17QqK1Icqmm24uElNn4aNE6g
	 dyEXXglk755dAMizt1Low/9xHQbk9wGW/sAxTH/ig1Nx27Rmc511QRKeXmuB4uajDS
	 ry3EbwT8QF9bfs0VlcNQJBaOrGGd32GVtmtPUIlyAl6AFO5fHanUGGe7YyTbMEnZUk
	 af3JTensL0djx/ZctZdYrUUhgTz59dgEpyExsvDCG5MthdUQLFpoXIVWvYnKwiOkhb
	 czV9UQ2BdYnEw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig ,
	Danilo Krummrich ,
	David Hildenbrand ,
	iommu@lists.linux.dev,
	Jason Wang ,
	Jens Axboe ,
	Joerg Roedel ,
	Jonathan Corbet ,
	Juergen Gross ,
	kasan-dev@googlegroups.com,
	Keith Busch ,
	linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy ,
	rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev,
	Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v6 09/16] dma-mapping: implement DMA_ATTR_MMIO for dma_(un)map_page_attrs()
Date: Tue,  9 Sep 2025 16:27:37 +0300
Message-ID: <3660e2c78ea409d6c483a215858fb3af52cd0ed3.1757423202.git.leonro@nvidia.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Make dma_map_page_attrs() and dma_map_page_attrs() respect
DMA_ATTR_MMIO.

DMA_ATR_MMIO makes the functions behave the same as
dma_(un)map_resource():
 - No swiotlb is possible
 - Legacy dma_ops arches use ops->map_resource()
 - No kmsan
 - No arch_dma_map_phys_direct()

The prior patches have made the internal functions called here
support DMA_ATTR_MMIO.

This is also preparation for turning dma_map_resource() into an inline
calling dma_map_phys(DMA_ATTR_MMIO) to consolidate the flows.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 kernel/dma/mapping.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index e47bcf7cc43d7..95eab531e2273 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -158,6 +158,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
 	phys_addr_t phys = page_to_phys(page) + offset;
+	bool is_mmio = attrs & DMA_ATTR_MMIO;
 	dma_addr_t addr;
 
 	BUG_ON(!valid_dma_direction(dir));
@@ -166,14 +167,25 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		return DMA_MAPPING_ERROR;
 
 	if (dma_map_direct(dev, ops) ||
-	    arch_dma_map_phys_direct(dev, phys + size))
+	    (!is_mmio && arch_dma_map_phys_direct(dev, phys + size)))
 		addr = dma_direct_map_phys(dev, phys, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
-	else
+	else if (is_mmio) {
+		if (!ops->map_resource)
+			return DMA_MAPPING_ERROR;
+
+		addr = ops->map_resource(dev, phys, size, dir, attrs);
+	} else {
+		/*
+		 * The dma_ops API contract for ops->map_page() requires
+		 * kmappable memory, while ops->map_resource() does not.
+		 */
 		addr = ops->map_page(dev, page, offset, size, dir, attrs);
+	}
 
-	kmsan_handle_dma(phys, size, dir);
+	if (!is_mmio)
+		kmsan_handle_dma(phys, size, dir);
 	trace_dma_map_phys(dev, phys, addr, size, dir, attrs);
 	debug_dma_map_phys(dev, phys, size, dir, addr, attrs);
 
@@ -185,14 +197,18 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
 		enum dma_data_direction dir, unsigned long attrs)
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
+	bool is_mmio = attrs & DMA_ATTR_MMIO;
 
 	BUG_ON(!valid_dma_direction(dir));
 	if (dma_map_direct(dev, ops) ||
-	    arch_dma_unmap_phys_direct(dev, addr + size))
+	    (!is_mmio && arch_dma_unmap_phys_direct(dev, addr + size)))
 		dma_direct_unmap_phys(dev, addr, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
-	else
+	else if (is_mmio) {
+		if (ops->unmap_resource)
+			ops->unmap_resource(dev, addr, size, dir, attrs);
+	} else
 		ops->unmap_page(dev, addr, size, dir, attrs);
 	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
 	debug_dma_unmap_phys(dev, addr, size, dir);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 13:59:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 13:59:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117024.1463251 (Exim 4.92)
	(envelope-from )
	id 1uvyt1-0005jz-3z; Tue, 09 Sep 2025 13:59:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117024.1463251; Tue, 09 Sep 2025 13:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvyt1-0005js-0K; Tue, 09 Sep 2025 13:59:55 +0000
Received: by outflank-mailman (input) for mailman id 1117024;
 Tue, 09 Sep 2025 13:59: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 1uvyt0-0005jm-Hf
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 13:59:54 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 41c9ea04-8d85-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 15:59:52 +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 5E9261424;
 Tue,  9 Sep 2025 06:59:43 -0700 (PDT)
Received: from [10.44.160.77] (e126510-lin.lund.arm.com [10.44.160.77])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4CF773F66E;
 Tue,  9 Sep 2025 06: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: 41c9ea04-8d85-11f0-9809-7dc792cee155
Message-ID: <203c84db-1a58-42f0-a79b-35104d79e964@arm.com>
Date: Tue, 9 Sep 2025 15:59:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
To: David Hildenbrand ,
 Andrew Morton 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 11:21, David Hildenbrand wrote:
> On 09.09.25 04:16, Andrew Morton wrote:
>> On Mon,  8 Sep 2025 08:39:24 +0100 Kevin Brodsky
>>  wrote:
>>
>>> The main change enabling nesting is patch 2, following the approach
>>> suggested by Catalin Marinas [4]: have enter() return some state and
>>> the matching leave() take that state.
>>
>> This is so totally the correct way.  Thanks.
>
> Staring at this, I wonder if we could alternatively handle it like
> pagefault_disable()/pagefault_enable(), having something like
> current->lazy_mmu_enabled.
>
> We wouldn't have to worry about preemption in that case I guess
> (unless the arch has special requirements).
>
> Not sure if that was already discussed, just a thought. 

That's an interesting point, I think I've addressed it in reply to patch
2 [1].

- Kevin

[1]
https://lore.kernel.org/all/47ee1df7-1602-4200-af94-475f84ca8d80@arm.com/


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:02:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:02:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117035.1463260 (Exim 4.92)
	(envelope-from )
	id 1uvyvL-0007K0-Fc; Tue, 09 Sep 2025 14:02:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117035.1463260; Tue, 09 Sep 2025 14: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 1uvyvL-0007Jt-D6; Tue, 09 Sep 2025 14:02:19 +0000
Received: by outflank-mailman (input) for mailman id 1117035;
 Tue, 09 Sep 2025 14:02:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvyvJ-0007Jl-RC
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:02:17 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 96bee1f1-8d85-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 16:02:15 +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 06A861424;
 Tue,  9 Sep 2025 07:02:06 -0700 (PDT)
Received: from [10.44.160.77] (e126510-lin.lund.arm.com [10.44.160.77])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EAB473F66E;
 Tue,  9 Sep 2025 07: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: 96bee1f1-8d85-11f0-9809-7dc792cee155
Message-ID: <5681b377-baa7-4cd4-8e23-7314d58a7b5b@arm.com>
Date: Tue, 9 Sep 2025 16:02:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
From: Kevin Brodsky 
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
Content-Language: en-GB
In-Reply-To: <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 15:49, Kevin Brodsky wrote:
> On 09/09/2025 13:54, David Hildenbrand wrote:
>> On 09.09.25 13:45, Alexander Gordeev wrote:
>>> On Tue, Sep 09, 2025 at 12:09:48PM +0200, David Hildenbrand wrote:
>>>> On 09.09.25 11:40, Alexander Gordeev wrote:
>>>>> On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
>>>>>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>>>>>> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
>>>>>>> (taking and returning no value). This is proving problematic in
>>>>>>> situations where leave() needs to restore some context back to its
>>>>>>> original state (before enter() was called). In particular, this
>>>>>>> makes it difficult to support the nesting of lazy_mmu sections -
>>>>>>> leave() does not know whether the matching enter() call occurred
>>>>>>> while lazy_mmu was already enabled, and whether to disable it or
>>>>>>> not.
>>>>>>>
>>>>>>> This patch gives all architectures the chance to store local state
>>>>>>> while inside a lazy_mmu section by making enter() return some value,
>>>>>>> storing it in a local variable, and having leave() take that value.
>>>>>>> That value is typed lazy_mmu_state_t - each architecture defining
>>>>>>> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
>>>>>>> For now we define it as int everywhere, which is sufficient to
>>>>>>> support nesting.
>>>>> ...
>>>>>>> {
>>>>>>> + lazy_mmu_state_t lazy_mmu_state;
>>>>>>> ...
>>>>>>> - arch_enter_lazy_mmu_mode();
>>>>>>> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
>>>>>>> ...
>>>>>>> - arch_leave_lazy_mmu_mode();
>>>>>>> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
>>>>>>> ...
>>>>>>> }
>>>>>>>
>>>>>>> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
>>>>>>>      lazy_mmu is already enabled, and it temporarily disables it by
>>>>>>>      calling leave() and then enter() again. Here we want to ensure
>>>>>>>      that any operation between the leave() and enter() calls is
>>>>>>>      completed immediately; for that reason we pass
>>>>>>> LAZY_MMU_DEFAULT to
>>>>>>>      leave() to fully disable lazy_mmu. enter() will then
>>>>>>> re-enable it
>>>>>>>      - this achieves the expected behaviour, whether nesting
>>>>>>> occurred
>>>>>>>      before that function was called or not.
>>>>>>>
>>>>>>> Note: it is difficult to provide a default definition of
>>>>>>> lazy_mmu_state_t for architectures implementing lazy_mmu, because
>>>>>>> that definition would need to be available in
>>>>>>> arch/x86/include/asm/paravirt_types.h and adding a new generic
>>>>>>>     #include there is very tricky due to the existing header soup.
>>>>>> Yeah, I was wondering about exactly that.
>>>>>>
>>>>>> In particular because LAZY_MMU_DEFAULT etc resides somewehere
>>>>>> compeltely
>>>>>> different.
>>>>>>
>>>>>> Which raises the question: is using a new type really of any
>>>>>> benefit here?
>>>>>>
>>>>>> Can't we just use an "enum lazy_mmu_state" and call it a day?
>>>>> I could envision something completely different for this type on s390,
>>>>> e.g. a pointer to a per-cpu structure. So I would really ask to stick
>>>>> with the current approach.
> This is indeed the motivation - let every arch do whatever it sees fit.
> lazy_mmu_state_t is basically an opaque type as far as generic code is
> concerned, which also means that this API change is the first and last
> one we need (famous last words, I know). 
>
> I mentioned in the cover letter that the pkeys-based page table
> protection series [1] would have an immediate use for lazy_mmu_state_t.
> In that proposal, any helper writing to pgtables needs to modify the
> pkey register and then restore it. To reduce the overhead, lazy_mmu is
> used to set the pkey register only once in enter(), and then restore it
> in leave() [2]. This currently relies on storing the original pkey
> register value in thread_struct, which is suboptimal and most
> importantly doesn't work if lazy_mmu sections nest. With this series, we
> could instead store the pkey register value in lazy_mmu_state_t
> (enlarging it to 64 bits or more).

Forgot the references, sorry...

[1]
https://lore.kernel.org/linux-hardening/20250815085512.2182322-1-kevin.brodsky@arm.com/
[2]
https://lore.kernel.org/linux-hardening/20250815085512.2182322-19-kevin.brodsky@arm.com/

> I also considered going further and making lazy_mmu_state_t a pointer as
> Alexander suggested - more complex to manage, but also a lot more flexible.
>
>>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
>>> want to use it - at least that is how I read the description above.
>>>
>>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
>>> that do not follow this pattern, and it looks as a problem to me.
> This discussion also made me realise that this is problematic, as the
> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
> convenience, not for generic code (where lazy_mmu_state_t should ideally
> be an opaque type as mentioned above). It almost feels like the kasan
> case deserves a different API, because this is not how enter() and
> leave() are meant to be used. This would mean quite a bit of churn
> though, so maybe just introduce another arch-defined value to pass to
> leave() for such a situation - for instance,
> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?
>
>> Yes, that's why I am asking.
>>
>> What kind of information (pointer to a per-cpu structure) would you
>> want to return, and would handling it similar to how
>> pagefault_disable()/pagefault_enable() e.g., using a variable in
>> "current" to track the nesting level avoid having s390x to do that?
> The pagefault_disabled approach works fine for simple use-cases, but it
> doesn't scale well. The space allocated in task_struct/thread_struct to
> track that state is wasted (unused) most of the time. Worse, it does not
> truly enable states to be nested: it allows the outermost section to
> store some state, but nested sections cannot allocate extra space. This
> is really what the stack is for.
>
> - Kevin


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:15:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:15:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117049.1463271 (Exim 4.92)
	(envelope-from )
	id 1uvz88-00017Q-JW; Tue, 09 Sep 2025 14:15:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117049.1463271; Tue, 09 Sep 2025 14:15: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 1uvz88-00017J-GC; Tue, 09 Sep 2025 14:15:32 +0000
Received: by outflank-mailman (input) for mailman id 1117049;
 Tue, 09 Sep 2025 14:15: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 1uvz87-00017D-6b
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:15:31 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 6f0eb94a-8d87-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 16:15:27 +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 2C94C1424;
 Tue,  9 Sep 2025 07:15:18 -0700 (PDT)
Received: from [10.44.160.77] (e126510-lin.lund.arm.com [10.44.160.77])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0C5F63F66E;
 Tue,  9 Sep 2025 07:15: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: 6f0eb94a-8d87-11f0-9809-7dc792cee155
Message-ID: 
Date: Tue, 9 Sep 2025 16:15:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Juergen Gross , David Hildenbrand ,
 linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Alexander Gordeev ,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 "Liam R. Howlett" ,
 Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 12:57, Juergen Gross wrote:
> On 09.09.25 11:07, David Hildenbrand wrote:
>> On 08.09.25 09:39, Kevin Brodsky wrote:
>>> [...]
>>>
>>> Note: it is difficult to provide a default definition of
>>> lazy_mmu_state_t for architectures implementing lazy_mmu, because
>>> that definition would need to be available in
>>> arch/x86/include/asm/paravirt_types.h and adding a new generic
>>>   #include there is very tricky due to the existing header soup.
>>
>> Yeah, I was wondering about exactly that.
>>
>> In particular because LAZY_MMU_DEFAULT etc resides somewehere
>> compeltely different.
>>
>> Which raises the question: is using a new type really of any benefit
>> here?
>>
>> Can't we just use an "enum lazy_mmu_state" and call it a day?
>>
>
> The comment about the "header soup" made me look into this problem:
>
> It seems some of the "#include " instances in the code
> base can just be dropped.
>
> For the remaining cases I'd like to suggest a reorg of the related
> headers:
> Instead of having the non-paravirt definition in one header and the
> paravirt
> ones in paravirt.h, maybe it would be better to have only the paravirt
> generic definitions in paravirt.h and the specific functions in the
> header
> defining the non-paravirt variant. This would probably resolve the
> problem
> with the "soup", as paravirt.h wouldn't rely on so many other headers.
>
> I'm just preparing a patch doing the removal of the not needed
> includes, but
> I'd be willing to address the disentangling as noted above.
>
> Thoughts?

I don't know enough about these headers to express an informed opinion,
but it does sound like a useful cleanup. Do you think it would allow
 to include ? This is what we
would need to have a generic definition of lazy_mmu_state_t (which could
be overridden by defining some __HAVE_ARCH macro in ).

- Kevin


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:29:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:29:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117063.1463280 (Exim 4.92)
	(envelope-from )
	id 1uvzL8-0004c9-M1; Tue, 09 Sep 2025 14:28:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117063.1463280; Tue, 09 Sep 2025 14:28: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 1uvzL8-0004c2-JD; Tue, 09 Sep 2025 14:28:58 +0000
Received: by outflank-mailman (input) for mailman id 1117063;
 Tue, 09 Sep 2025 14:28: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 1uvzL6-0004bw-NK
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:28:56 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4d6cbb9f-8d89-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 16:28:50 +0200 (CEST)
Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com
 [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-488-Xn530B1mMc2gu9az9H5sow-1; Tue, 09 Sep 2025 10:28:48 -0400
Received: by mail-wr1-f69.google.com with SMTP id
 ffacd0b85a97d-3df3e935ec8so2632762f8f.0
 for ; Tue, 09 Sep 2025 07:28:47 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34?
 (p200300d82f239c00d1f6f7fe8f147e34.dip0.t-ipconnect.de.
 [2003:d8:2f23:9c00:d1f6:f7fe:8f14:7e34])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7521be57esm2887963f8f.2.2025.09.09.07.28.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 07:28: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: 4d6cbb9f-8d89-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757428129;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=D4QRi7hDsi9OF+uq4PfR985/VTCgDFYnf6cObBRAB+8=;
	b=f2SWvfkMQUOZdt3NP39GIKxjgDtCvpFGjWyi/FhhuKmXC8ir85mkJXL3iC467iJZDVWUh/
	u0VJbxKjREulLhnXnB34nnjL6lngjlIoVXPvnhtC8bm8e0UwANcbQ4/bf8f/L/gRfHVSyT
	cNyisjVfSQWlQ43aiT082Lm3/UTSOqg=
X-MC-Unique: Xn530B1mMc2gu9az9H5sow-1
X-Mimecast-MFC-AGG-ID: Xn530B1mMc2gu9az9H5sow_1757428127
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757428127; x=1758032927;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=D4QRi7hDsi9OF+uq4PfR985/VTCgDFYnf6cObBRAB+8=;
        b=M7FhdXKj9Cq99wRHL/8WlSMGXZ1Ny/p3TaaUP2hMoyTSM/h9irqKi694Un5tDNu4Mu
         1R4xwap+rBp3kKRI4/jf52DQqmJlvf46GbQtLXXshKWUk085KPQCnEweKsA0IO84sb/V
         iH8y9Bb534MKrUzhjkfpKb+BSNuhQZ+bTSV9qpTv/OC78X4t5PaCqqmfqYHdD84nrVhD
         /9JGruNJkgy6KwwkvhcYAfiu02vH5hgJJqCJXFPYNALxKagtRzqSUjo7J9FL+r4xPEHH
         ZQIvSqvr6exnetlW80Ovum4XCGjrMMorVZY08Dn0+rTAxOLknjdk/CLUAsJUUul4BcPU
         T3Rg==
X-Forwarded-Encrypted: i=1; AJvYcCWEwrFEd7byuZbnBTXh/0lKtB0LMLDDGrOoHFaKIfpmos3IyO/tNx8KGE8oVDrnJiQdip+miPJpkB0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxSOvWC89VDi1wlZEa8lColdVxZvi1cUykLf2OcAX3GMW+GRM0+
	EdF8yLjXciginVZ0j6msqQmvsyn4HENlrKOhYhweNqgFaBZaYnQ+qv5XbaxgfL1jKK33os8k/3w
	gs22e5ISrw1m6YfuFGiRi239JJ5MULJlTASmKDWa8+9V8NgXH6YPIh9lNZjScySMmb2Jj
X-Gm-Gg: ASbGncvH7A0y8suOZyEYSpvFideQsEF5CvNIIV4xZcvPMF/n+JeeuKS+GEEPIDgcPH2
	cqp6O4ghuVg5/gwX7ZTIXM6TnKxD0RX4o8GetFg/aGZX2hOTF+4htyRc4gqDYTUyzYtMrB2yi9W
	jKRn7hY1pdk7MWOAiIzR/K98/QByhkp5QHthroqwf41hgaG80clW9NGyFkM2rBrpAGojWrY6+dS
	YiWmJzqFtu9sqT7OHGeKkMNOYgGxzK8EpSJxIRganeous7RRPvI3WphgYxdB90ZG1zHWJQ9hRPB
	nuXm9RGor3Rb3fNlRcmdvts3/9QtLIjC6RWEYPlrIYaSKS8KoW+cQ2+kC+1uJ/ux5hs/ekroi5v
	4qdZrbc6IldG6BDRI68J3HTk70jvKmTa+g85g95HoIWJd6upizbK3JQWYBNoUFE52QBM=
X-Received: by 2002:a05:6000:40dc:b0:3b7:9c79:32bb with SMTP id ffacd0b85a97d-3e643741232mr9630224f8f.44.1757428126473;
        Tue, 09 Sep 2025 07:28:46 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHD6jqBYDWaPdeHuZLYdYngedHnwSRwLh5c9r19frL6eN+mcEvQ/xbzM3ef+SL3HLWhKdEABQ==
X-Received: by 2002:a05:6000:40dc:b0:3b7:9c79:32bb with SMTP id ffacd0b85a97d-3e643741232mr9630184f8f.44.1757428125875;
        Tue, 09 Sep 2025 07:28:45 -0700 (PDT)
Message-ID: <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
Date: Tue, 9 Sep 2025 16:28:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: TzH_5KCuRSPYYZU4owDYdhlwDLKnvtGwRmjU52X20dE_1757428127
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

>>>>>> Can't we just use an "enum lazy_mmu_state" and call it a day?
>>>>>
>>>>> I could envision something completely different for this type on s390,
>>>>> e.g. a pointer to a per-cpu structure. So I would really ask to stick
>>>>> with the current approach.
> 
> This is indeed the motivation - let every arch do whatever it sees fit.
> lazy_mmu_state_t is basically an opaque type as far as generic code is
> concerned, which also means that this API change is the first and last
> one we need (famous last words, I know).

It makes the API more complicated, though. :)

> 
> I mentioned in the cover letter that the pkeys-based page table
> protection series [1] would have an immediate use for lazy_mmu_state_t.
> In that proposal, any helper writing to pgtables needs to modify the
> pkey register and then restore it. To reduce the overhead, lazy_mmu is
> used to set the pkey register only once in enter(), and then restore it
> in leave() [2]. This currently relies on storing the original pkey
> register value in thread_struct, which is suboptimal and most

Can you elaborate why this is suboptimal? See below regarding the size of task_struct.

> importantly doesn't work if lazy_mmu sections nest.

Can you elaborate why it would be problematic with nesting (if we would have a count
and can handle the transition from 0->1 and 1->0)?

> With this series, we
> could instead store the pkey register value in lazy_mmu_state_t
> (enlarging it to 64 bits or more).

Yes.

> 
> I also considered going further and making lazy_mmu_state_t a pointer as
> Alexander suggested - more complex to manage, but also a lot more flexible.
> 
>>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>>>
>>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
>>> want to use it - at least that is how I read the description above.
>>>
>>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
>>> that do not follow this pattern, and it looks as a problem to me.
> 
> This discussion also made me realise that this is problematic, as the
> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
> convenience, not for generic code (where lazy_mmu_state_t should ideally
> be an opaque type as mentioned above). It almost feels like the kasan
> case deserves a different API, because this is not how enter() and
> leave() are meant to be used. This would mean quite a bit of churn
> though, so maybe just introduce another arch-defined value to pass to
> leave() for such a situation - for instance,
> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?

The discussion made me realize that it's a bit hack right now :)

If LAZY_MMU_DEFAULT etc. are not for common code, then please
maintain them for the individual archs as well, just like you do with the
opaque type.

> 
>>
>> Yes, that's why I am asking.
>>
>> What kind of information (pointer to a per-cpu structure) would you
>> want to return, and would handling it similar to how
>> pagefault_disable()/pagefault_enable() e.g., using a variable in
>> "current" to track the nesting level avoid having s390x to do that?
> 
> The pagefault_disabled approach works fine for simple use-cases, but it
> doesn't scale well. The space allocated in task_struct/thread_struct to
> track that state is wasted (unused) most of the time.

I'm not sure that's a concern. Fitting an int into existing holes should work
and even another 64bit (8byte )...

I just checked with pahole using the Fedora config on current mm-unstable.


/* size: 9792, cachelines: 153, members: 276 */
/* sum members: 9619, holes: 20, sum holes: 125 */
/* sum bitfield members: 85 bits, bit holes: 2, sum bit holes: 43 bits */
/* padding: 32 */
/* member types with holes: 4, total: 6, bit holes: 2, total: 2 */
/* paddings: 6, sum paddings: 49 */
/* forced alignments: 12, forced holes: 2, sum forced holes: 60 */

Due to some "arch_task_struct_size" we might actually allocate more space.


Staring at my live system:

$ sudo slabinfo
Name                   Objects Objsize           Space Slabs/Part/Cpu  O/S O %Fr %Ef Flg
...
task_struct               1491   12376           24.8M      721/25/37    2 3   3  74


I am not sure if even an additional 8byte would move the needle here.


Worse, it does not
> truly enable states to be nested: it allows the outermost section to
> store some state, but nested sections cannot allocate extra space. This
> is really what the stack is for.

If it's really just 8 bytes I don't really see the problem. So likely there is
more to it?

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:39:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:39:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117079.1463291 (Exim 4.92)
	(envelope-from )
	id 1uvzVd-00076w-Nr; Tue, 09 Sep 2025 14:39:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117079.1463291; Tue, 09 Sep 2025 14: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 1uvzVd-00076p-Kw; Tue, 09 Sep 2025 14:39:49 +0000
Received: by outflank-mailman (input) for mailman id 1117079;
 Tue, 09 Sep 2025 14:39: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 1uvzVb-00075u-F1
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:39:47 +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 d324d9c2-8d8a-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 16:39:44 +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 589BBEbn028671;
 Tue, 9 Sep 2025 14:38:53 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490xycw9r8-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 14:38:52 +0000 (GMT)
Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 589EUjFv007959;
 Tue, 9 Sep 2025 14:38:52 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 490xycw9r3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 14:38:51 +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 589AvumM017218;
 Tue, 9 Sep 2025 14:38:50 GMT
Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224])
 by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4911gmbdxs-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 09 Sep 2025 14:38:50 +0000
Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com
 [10.20.54.104])
 by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 589EcnS049545616
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 9 Sep 2025 14:38:49 GMT
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 0279320043;
 Tue,  9 Sep 2025 14:38:49 +0000 (GMT)
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 2791F2004B;
 Tue,  9 Sep 2025 14:38:48 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue,  9 Sep 2025 14:38:48 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d324d9c2-8d8a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=pp1; bh=PZxnEl
	gXfWNXHVRkPVUlwCfE0YEzKBATAK/iNRyCHno=; b=eAw85XMTzWR9vGa1/hE9vj
	mydHz5ZGmT77GHt0U64/1YAtQ+lSFTmIp9CIEXj9AqCB1xpfIW94Ks0mq2SdgDpJ
	0FPArRwybEixPfZaOslsDAe44oIe3Tm1gRsGZY/RLa+8mT3lM30D87vp64U0OPcE
	AyEhpKjxohjXf8zMTSl45uNLe+xdcC+WMRvNiK8F4OVX4+mUboi1o5W9xWOJyuG4
	YBGbdgCpU8wPxsq98ebD9TZKO89s1xp8D5BcFUSvtxMjUPUOH9oIgZBJ+OTTT7hW
	3ZKsxlOOkqxL4/35WGGIhaGdo6h3UOz5oPnEPsFraOl5KI9HlFyrZTNClQjrf38A
	==
Date: Tue, 9 Sep 2025 16:38:46 +0200
From: Alexander Gordeev 
To: Kevin Brodsky 
Cc: David Hildenbrand , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: w3un9YJFAnj-nx4lP2drAL9l1yJOP1En
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDIzNSBTYWx0ZWRfX5AD3L9SkswSm
 yrVgoGtIISKP604rm8z2wlBI+9ePIXNFYQAYLSzjXIjHlXrJz/N5CyEoKiLBFH0S6cAaacNg8MI
 /uqSqt+AyIfCoA2W1PycTsyoA9dnPphhk2M6Dy7RNUKN5o43iFF9IXyIGVBQKdc5LYc5Tqn/OPM
 HPGZJ2R+BrI/nWN/OrWkeMYz3esjc3UK9kdBknkAwa1vw44DfXe2kcF7OMH8RK37Zmyzfk8ftAT
 Mah9tj2mXv8ZZFGcLXNuNYIctcCpzvNgMf9Y+RDBJM2AEQkCBcXflTuYScwL6Aa0Fdpz3OLg/9L
 oof/OuMSKGRkSalY70FlPW8UQK4wZ6ys9K9DbelwH72mhkNMfgbwQ1G8LikJGVg3ZsfCHBBKKvz
 o+6LVfHA
X-Proofpoint-GUID: kEu557zaNP3aZma9JIWXWvvSIckTRd-u
X-Authority-Analysis: v=2.4 cv=F59XdrhN c=1 sm=1 tr=0 ts=68c03bfc cx=c_pps
 a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17
 a=8nJEP1OIZ-IA:10 a=yJojWOMRYYMA:10 a=0nQrape7h3WL6H1kZSkA:9
 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-09_02,2025-09-08_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 clxscore=1015
 impostorscore=0 bulkscore=0 adultscore=0 spamscore=0 classifier=typeunknown
 authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1
 engine=8.19.0-2507300000 definitions=main-2509060235

On Tue, Sep 09, 2025 at 03:49:46PM +0200, Kevin Brodsky wrote:
> On 09/09/2025 13:54, David Hildenbrand wrote:
> > On 09.09.25 13:45, Alexander Gordeev wrote:
> >> On Tue, Sep 09, 2025 at 12:09:48PM +0200, David Hildenbrand wrote:
> >>> On 09.09.25 11:40, Alexander Gordeev wrote:
> >>>> On Tue, Sep 09, 2025 at 11:07:36AM +0200, David Hildenbrand wrote:
> >>>>> On 08.09.25 09:39, Kevin Brodsky wrote:
> >>>>>> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> >>>>>> (taking and returning no value). This is proving problematic in
> >>>>>> situations where leave() needs to restore some context back to its
> >>>>>> original state (before enter() was called). In particular, this
> >>>>>> makes it difficult to support the nesting of lazy_mmu sections -
> >>>>>> leave() does not know whether the matching enter() call occurred
> >>>>>> while lazy_mmu was already enabled, and whether to disable it or
> >>>>>> not.
> >>>>>>
> >>>>>> This patch gives all architectures the chance to store local state
> >>>>>> while inside a lazy_mmu section by making enter() return some value,
> >>>>>> storing it in a local variable, and having leave() take that value.
> >>>>>> That value is typed lazy_mmu_state_t - each architecture defining
> >>>>>> __HAVE_ARCH_ENTER_LAZY_MMU_MODE is free to define it as it sees fit.
> >>>>>> For now we define it as int everywhere, which is sufficient to
> >>>>>> support nesting.
> >>>> ...
> >>>>>> {
> >>>>>> + lazy_mmu_state_t lazy_mmu_state;
> >>>>>> ...
> >>>>>> - arch_enter_lazy_mmu_mode();
> >>>>>> + lazy_mmu_state = arch_enter_lazy_mmu_mode();
> >>>>>> ...
> >>>>>> - arch_leave_lazy_mmu_mode();
> >>>>>> + arch_leave_lazy_mmu_mode(lazy_mmu_state);
> >>>>>> ...
> >>>>>> }
> >>>>>>
> >>>>>> * In a few cases (e.g. xen_flush_lazy_mmu()), a function knows that
> >>>>>>  lazy_mmu is already enabled, and it temporarily disables it by
> >>>>>>  calling leave() and then enter() again. Here we want to ensure
> >>>>>>  that any operation between the leave() and enter() calls is
> >>>>>>  completed immediately; for that reason we pass
> >>>>>> LAZY_MMU_DEFAULT to
> >>>>>>  leave() to fully disable lazy_mmu. enter() will then
> >>>>>> re-enable it
> >>>>>>  - this achieves the expected behaviour, whether nesting
> >>>>>> occurred
> >>>>>>  before that function was called or not.
> >>>>>>
> >>>>>> Note: it is difficult to provide a default definition of
> >>>>>> lazy_mmu_state_t for architectures implementing lazy_mmu, because
> >>>>>> that definition would need to be available in
> >>>>>> arch/x86/include/asm/paravirt_types.h and adding a new generic
> >>>>>>  #include there is very tricky due to the existing header soup.
> >>>>>
> >>>>> Yeah, I was wondering about exactly that.
> >>>>>
> >>>>> In particular because LAZY_MMU_DEFAULT etc resides somewehere
> >>>>> compeltely
> >>>>> different.
> >>>>>
> >>>>> Which raises the question: is using a new type really of any
> >>>>> benefit here?
> >>>>>
> >>>>> Can't we just use an "enum lazy_mmu_state" and call it a day?
> >>>>
> >>>> I could envision something completely different for this type on s390,
> >>>> e.g. a pointer to a per-cpu structure. So I would really ask to stick
> >>>> with the current approach.
> 
> This is indeed the motivation - let every arch do whatever it sees fit.
> lazy_mmu_state_t is basically an opaque type as far as generic code is
> concerned, which also means that this API change is the first and last
> one we need (famous last words, I know).
> 
> I mentioned in the cover letter that the pkeys-based page table
> protection series [1] would have an immediate use for lazy_mmu_state_t.
> In that proposal, any helper writing to pgtables needs to modify the
> pkey register and then restore it. To reduce the overhead, lazy_mmu is
> used to set the pkey register only once in enter(), and then restore it
> in leave() [2]. This currently relies on storing the original pkey
> register value in thread_struct, which is suboptimal and most
> importantly doesn't work if lazy_mmu sections nest. With this series, we
> could instead store the pkey register value in lazy_mmu_state_t
> (enlarging it to 64 bits or more).
> 
> I also considered going further and making lazy_mmu_state_t a pointer as
> Alexander suggested - more complex to manage, but also a lot more flexible.
> 
> >>> Would that integrate well with LAZY_MMU_DEFAULT etc?
> >>
> >> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
> >> want to use it - at least that is how I read the description above.
> >>
> >> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
> >> that do not follow this pattern, and it looks as a problem to me.
> 
> This discussion also made me realise that this is problematic, as the
> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
> convenience, not for generic code (where lazy_mmu_state_t should ideally
> be an opaque type as mentioned above). It almost feels like the kasan
> case deserves a different API, because this is not how enter() and
> leave() are meant to be used. This would mean quite a bit of churn
> though, so maybe just introduce another arch-defined value to pass to
> leave() for such a situation - for instance,
> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?

What about to adjust the semantics of apply_to_page_range() instead?

It currently assumes any caller is fine with apply_to_pte_range() to
enter the lazy mode. By contrast, kasan_(de)populate_vmalloc_pte() are
not fine at all and must leave the lazy mode. That literally suggests
the original assumption is incorrect.

We could change int apply_to_pte_range(..., bool create, ...) to e.g.
apply_to_pte_range(..., unsigned int flags, ...) and introduce a flag
that simply skips entering the lazy mmu mode.

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:52:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:52:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117090.1463311 (Exim 4.92)
	(envelope-from )
	id 1uvziA-0002Aq-0a; Tue, 09 Sep 2025 14:52:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117090.1463311; Tue, 09 Sep 2025 14: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 1uvzi9-0002Aj-Tr; Tue, 09 Sep 2025 14:52:45 +0000
Received: by outflank-mailman (input) for mailman id 1117090;
 Tue, 09 Sep 2025 14:52:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvzi8-0001x1-Iq
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:52:44 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3f94728-8d8c-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 16:52:43 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-61d143aa4acso9172109a12.2
 for ; Tue, 09 Sep 2025 07:52:43 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62c018f663asm1414898a12.43.2025.09.09.07.52.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Sep 2025 07:52: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: a3f94728-8d8c-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757429563; x=1758034363; darn=lists.xenproject.org;
        h=content-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=N/zX6oZGR3iPEmqzxrgqeby+Y3izMNsOvFj5VzGCrp4=;
        b=C0cD0DRw+lSGrx/Q1ev/NPSh9PXRdyH5B365otD3VZMtqHRSrIq2TcRMX0Sxw6wDMa
         BTx54PkYToRFXxYf4DytWt6y4u1Z8k8M2H2D8xAAsFRMLbVGB6RKw9dAvztn0c0rT6WI
         Z4wrABGcTnn6RtRnYoZJv5DdrJVOq5vB8o/j0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757429563; x=1758034363;
        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=N/zX6oZGR3iPEmqzxrgqeby+Y3izMNsOvFj5VzGCrp4=;
        b=cCirkcZJP0F79prGXpUA0ORjP4JGj6ZfEQswr2otFanVie4cFGxmsCXqmGtFdmTtpN
         gEX7s4fjeHsIC9l/IAyUvEEjLYg5GXaEL+YK/utiDN7Jwg3zNc9Xrfoa7zzEyN51L9Qm
         pqep0w4vItzQoaYN6BeI7wv0yhBQWKGaknrFWPBGPMVIbeDpcANwkNeevcOHMx2wGLQS
         fnxCv5MQpxmYFBX6qk6qrblG+zuFFTn/Y66Je7VESYhlgNSb2G+jJOauudyNuT4kXycS
         ClmXbAtHE16EuOZ8wuUwIrqmU39o7V2znmsn3k5axePCKYDDj1mJXUfTxqqNXDQJQC6f
         NW/Q==
X-Gm-Message-State: AOJu0Ywk9ymeMftQ6WPnq/wbwJawlfHn3iS+At6L8xyxoPbyCW83c3K7
	OshcHFbHe6s0AfGA8GYBd+9eKZyAjUVC+R4rMQtOywL2x/rX7TumrloaLRsYqHAV+NbRGToX/Tn
	2uCZmYXE=
X-Gm-Gg: ASbGncse9uZasfLCZ/aiKisLFNiRFliK+MnlH5NrT5NPdbHjov7NbU12an8jcyibolI
	3RdqR7fMs8RqBAkszZGCgAKpTqZLVpMwTWTRxCq/+iO54BWdwbt3JBz4k1ZE5C+yQ20wvs/0ciI
	mM3tI3pT8ecemBELHttw9dCqctgSx8FPa1DEmpus0uYUajR+Z0BQQaeNeydKpkJzLshQQ9rq3XE
	CIJVVv7hz+2hXTvENpkD9XgPMTb0lJph9781LP99E02wlpXcn+T/yc5r0knhG4pxd7w3/tb5TEA
	DzkLgv+MhimH503wrmN21oCJWJtj7aFffgCAM6G5qemHPpSBsMomFKT+vfwztWprO0BFkBMBLl0
	DINkHoIGiGk/4y2Y5WfFAlcEnQC3K/yYrSVMUcZ769ddkwA==
X-Google-Smtp-Source: AGHT+IE0TeY5ImlbPGw6G6DSZO46aVvnvk3NMNB5XQANqprPUgE4HQU1QcU3a8pNUeO2PSFuIwlBXA==
X-Received: by 2002:a05:6402:3814:b0:620:1030:138d with SMTP id 4fb4d7f45d1cf-6237edb1ca2mr10899206a12.22.1757429562713;
        Tue, 09 Sep 2025 07:52:42 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	Kevin Lampis ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v5 2/2] efi: Support using Shim's LoadImage protocol
Date: Tue,  9 Sep 2025 14:52:33 +0000
Message-ID: 
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The existing Verify functionality of the Shim lock protocol is
deprecated and will be removed, the alternative it to use the LoadImage
interface to perform the verification.

When the loading is successful we won't be using the newly loaded image
(as of yet) so we must then immediately unload the image to clean up.

If the LoadImage protocol isn't available then fall back to the Shim
Lock (Verify) interface.

Log when the kernel is not verified and fail if this occurs
when secure boot mode is enabled.

Signed-off-by: Gerald Elder-Vass 
Signed-off-by: Kevin Lampis 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 

v5:
- Expand comment to add more clarity on need for unloading the image
- Check for EFI_SUCCESS from Verify to account for possible warnings,
  this matches the original behaviour
v4:
- Updated error message when failing due to lack of verification
v3:
- Use Shim Image by default, fall back to Shim Lock
---
 xen/common/efi/boot.c | 62 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 54 insertions(+), 8 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 5eb0394e2937..76cccb03aa42 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -38,6 +38,8 @@
   { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 0x94} }
 #define SHIM_LOCK_PROTOCOL_GUID \
   { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} }
+#define SHIM_IMAGE_LOADER_GUID \
+  { 0x1f492041U, 0xfadb, 0x4e59, {0x9e, 0x57, 0x7c, 0xaf, 0xe7, 0x3a, 0x55, 0xab} }
 #define APPLE_PROPERTIES_PROTOCOL_GUID \
   { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0} }
 #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
@@ -70,6 +72,13 @@ typedef struct {
     EFI_SHIM_LOCK_VERIFY Verify;
 } EFI_SHIM_LOCK_PROTOCOL;
 
+typedef struct _SHIM_IMAGE_LOADER {
+    EFI_IMAGE_LOAD LoadImage;
+    EFI_IMAGE_START StartImage;
+    EFI_EXIT Exit;
+    EFI_IMAGE_UNLOAD UnloadImage;
+} SHIM_IMAGE_LOADER;
+
 struct _EFI_APPLE_PROPERTIES;
 
 typedef EFI_STATUS
@@ -1048,6 +1057,49 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
     return gop_mode;
 }
 
+static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
+{
+    static EFI_GUID __initdata shim_image_guid = SHIM_IMAGE_LOADER_GUID;
+    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
+    SHIM_IMAGE_LOADER *shim_loader;
+    EFI_HANDLE loaded_kernel;
+    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
+    EFI_STATUS status;
+    bool verified = false;
+
+    /* Look for LoadImage first */
+    if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_image_guid, NULL,
+                                           (void **)&shim_loader)) )
+    {
+        status = shim_loader->LoadImage(false, ImageHandle, NULL,
+                                        (void *)kernel.ptr, kernel.size,
+                                        &loaded_kernel);
+        if ( !EFI_ERROR(status) )
+            verified = true;
+
+        /* Always unload the image. We only wanted LoadImage to perform
+         * verification, in the case of a failure there may still be cleanup
+         * needing to be performed.
+         */
+        shim_loader->UnloadImage(loaded_kernel);
+    }
+
+    /* else fall back to Shim Lock */
+    if ( !verified &&
+         !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
+                                           (void **)&shim_lock)) &&
+         shim_lock->Verify(kernel.ptr, kernel.size) == EFI_SUCCESS )
+        verified = true;
+
+    if ( !verified )
+    {
+        PrintStr(L"Kernel was not verified\n");
+
+        if ( efi_secure_boot )
+            blexit(L"Refusing to boot unverified kernel with UEFI SecureBoot enabled");
+    }
+}
+
 static void __init efi_tables(void)
 {
     unsigned int i;
@@ -1335,13 +1387,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
                                       EFI_SYSTEM_TABLE *SystemTable)
 {
     static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
-    static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
     EFI_LOADED_IMAGE *loaded_image;
     EFI_STATUS status;
     unsigned int i;
     CHAR16 *file_name, *cfg_file_name = NULL, *options = NULL;
     UINTN gop_mode = ~0;
-    EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
     union string section = { NULL }, name;
     bool base_video = false;
@@ -1592,12 +1642,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
      * device tree through the efi_check_dt_boot function, in this stage
      * 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 )
-        PrintErrMesg(L"Dom0 kernel image could not be verified", status);
+    if ( kernel.ptr && !kernel_verified )
+        efi_verify_kernel(ImageHandle);
 
     efi_arch_edd();
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117091.1463321 (Exim 4.92)
	(envelope-from )
	id 1uvziC-0002Pg-BB; Tue, 09 Sep 2025 14:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117091.1463321; Tue, 09 Sep 2025 14: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 1uvziC-0002PY-8D; Tue, 09 Sep 2025 14:52:48 +0000
Received: by outflank-mailman (input) for mailman id 1117091;
 Tue, 09 Sep 2025 14:52: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 1uvziA-0002LK-VS
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:52:46 +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 a2d87619-8d8c-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 16:52:41 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b02c719a117so1013093366b.1
 for ; Tue, 09 Sep 2025 07:52:41 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62c018f663asm1414898a12.43.2025.09.09.07.52.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Sep 2025 07:52: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: a2d87619-8d8c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757429561; x=1758034361; 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=L+5tyAGpSMVY5aLl8xVyfpkA4boc1Qj+gZ5ebj+kJ4I=;
        b=WziEMW1zlx2qRyaD1Itzhf5Gf/6NBY/5WX34d2LQAczlN1ytIVKJZUD1VDxOs2xe9v
         xtOwkZucEAU7Rxs/Kmem9ENu/R54JscxIq3LiOpK9VwKS3u/G6AwgcPeONI1pzqaR2xH
         8Di7YcNwCHe6s5OPyInd2XMlB5OxsxTFtydBE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757429561; x=1758034361;
        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=L+5tyAGpSMVY5aLl8xVyfpkA4boc1Qj+gZ5ebj+kJ4I=;
        b=MCll7TMkC8hP7QBogtGA+kIIKkjNhxjvBMbXfTiJdhbUpLp9yD5A1G+JJFaQ2DcFUD
         Z25dZXZ8Jnu9PIqmON5qU64NzJzZG8Y/FNccxGBD/Ob47QRkGHc/KtmZIsc4KSxZPvwM
         s7j1uYFs1EV9qP6Tx7cnzgW/zocv+nVtQBNMQD6kdWDzMfTRZNl6PR2aqCQ3jLrN9PQI
         BcGKYbXer0WLIklLh7DNVUlm3qvTUonrRiyUSwv3UeyUwbOEghato+Cf32703BBVd5hp
         eROLmRcH/5hZ4sezTNiRFRxj1LeTSx/zoAwljqcmmWrKIM1Vg1U2b3iPLrHyBdugM5Hg
         MxQw==
X-Gm-Message-State: AOJu0YxX1E5xA0J37BHxkClxq+2NxSU56sNQAuZ89rNnliiBEeYnMEeo
	2vS2dz08x52YMmLK/RbEWD3dfFksPSLR6NUCC2IPUYyjJDAH5AC6KBJGqPu2joTyHNWcTTQPHw5
	yo9Lo
X-Gm-Gg: ASbGncvl31jTy3GQeIqmzfmiHgHpEUW+/nAK1/ASpyQb3g7R+oNKe1A9RWn6nAXgVri
	uavrXT6WdmvQuF06ze7jbsjyVzJOhW39AuiBLptYhJX2tBAorlovOK+oBWMhguj1WS6qtEvrSgx
	8gQcvg4ix46NX20tStSdmJUwuA0SWSbgK9rxBc5gvMmbXyvvT+/nvV9nTtwVWYad5jeKGXUdZRL
	YvCKazojQNklDjr1hJZBwWgAAqRqFrIoKZN9JHk0W3YLOAd94DFkmmheoqhD6nBlykNveEA2WPl
	QrjeFxPqSu5TGF7gc7+n+Lx/pMwplPfaXNg3epuCU6LBoN3VoWOmtcE5qkj9D1Aww/Q2A1+VWcL
	E+8wD0JcMJR3ChMr6Hlf921OgSVoy9By7lBHIAvq8bGqApQ==
X-Google-Smtp-Source: AGHT+IE1i9nuOtbAESvSKCM903/YmGiFwF8LPL7GQNpZp8BSjnKtARKSlSUYmK0Uq8ads8tbVAnA8w==
X-Received: by 2002:a17:907:928e:b0:afe:d62a:f04b with SMTP id a640c23a62f3a-b04b13d017dmr1152983466b.3.1757429560880;
        Tue, 09 Sep 2025 07:52:40 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass 
Subject: [PATCH v5 0/2] efi: Support Shim LoadImage
Date: Tue,  9 Sep 2025 14:52:31 +0000
Message-ID: 
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Support Shim LoadImage protocol but keep Shim Lock for compatibility

https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2029800410
- Saw known unrelated debian-12-x86_64 issue

Gerald Elder-Vass (1):
  efi: Support using Shim's LoadImage protocol

Ross Lagerwall (1):
  efi: Add a function to check if Secure Boot mode is enabled

 xen/common/efi/boot.c    | 87 ++++++++++++++++++++++++++++++++++++----
 xen/common/efi/runtime.c |  1 +
 xen/include/xen/efi.h    |  2 +
 3 files changed, 82 insertions(+), 8 deletions(-)

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 14:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 14:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117089.1463301 (Exim 4.92)
	(envelope-from )
	id 1uvzi8-0001xJ-Ps; Tue, 09 Sep 2025 14:52:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117089.1463301; Tue, 09 Sep 2025 14:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uvzi8-0001xB-NO; Tue, 09 Sep 2025 14:52:44 +0000
Received: by outflank-mailman (input) for mailman id 1117089;
 Tue, 09 Sep 2025 14:52:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uvzi7-0001x1-Ua
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 14:52:43 +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 a368f53f-8d8c-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 16:52:42 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-627b85e4c0fso4009962a12.1
 for ; Tue, 09 Sep 2025 07:52:42 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62c018f663asm1414898a12.43.2025.09.09.07.52.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Sep 2025 07:52: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: a368f53f-8d8c-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757429562; x=1758034362; darn=lists.xenproject.org;
        h=content-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=1eEqARqC+B2G8bL7TcbwWKgsOMAevlPlBxP4QFC8iu8=;
        b=Ctvoi2jDK/w2HDN+dlQDS0T1eYZBiIdsEFqUAb33/r4u1g35I6HFT6FMPtEKvczCjG
         fDHvBIsAF6O7ooVkBxOuYAoT90yy2ue0Mlq7nEYMVZDxCDpIaHPFJdYEx5oYAgLPqz+z
         LB+zxbIOjA+Wt+0Se1LZwPfoFwKNpgBy651Vw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757429562; x=1758034362;
        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=1eEqARqC+B2G8bL7TcbwWKgsOMAevlPlBxP4QFC8iu8=;
        b=Y28s9KuWgL7k4KTWypGSg/OfgxxOO2Eh59WGSfi449mnspw3vODyv3oOqFA3lxwo7E
         61/NMoivG/SifJRRLk3bObn32XpD9VN57iY2adPl3braqnlXUgjPXBQrC1CAZw0054V5
         i3cV/HKJVXKZzZQT3No+zSTMITjSK2MSsvPuNGJq8BhMuj79TI6hRpHWmvysIyUDQ/Eg
         LqxmyTCpT1EYsKEIT7drq65z+QR0dS+SGBG4mqBuEavN4FNFy105Uqz3jVINhU3xfepO
         Pvr5Fs+PWryV/VeY0yQfTiBcf+sZD7mGYUmi+R9D7iloq448RlWwRM8Cxkc8BdWhv+lF
         Fl7w==
X-Gm-Message-State: AOJu0YwjM/Iba6RNN3eXArgh5veLsOGbJaVzuyv80kYHHBxAxEZ5KQYJ
	ydCX/KFh52V/WKJtKxlKG+HgjMu7TWAdvmJveb0owwu/Ye+hfV8s+8E5697Sf5VB82KGtQyK55T
	Bi9bmDmE=
X-Gm-Gg: ASbGncuIWqKkEWDNdsgDrPzej+T8vDVtevVYbEYD6dsMDeqRv4rSzhbABRK5Xw/4hzT
	StYa8tVAANbDULcuaxXhLEw0ol4UUEv7JshekBIJoKLarMthb504D0WksjM58nkMJQznIipX/im
	IZDJQi7bqpa8tSx1EH6bRQiWSpXjFJ3zCmyRkia2GsbWmLyl6DmoiJWr5uSc8A2iw7F1hf9U3k4
	iAzENJGnUKKBLn5SiWCQlU0iXr8460q5JOAWSitniMn0bZ4Vxx569OmPbz8pe7/whVKrsVpzN/b
	2eGGTiiVMuO/hJM/rEx5RWOb1kLKgexlcorLQ0CW7EqZI4F8PK2Vb58OcDQxHLoN86r60OyUFBn
	DR0+XbYW2j+ETYdKGPU+6AfyjZ+CdVNssQRmTEoDeG2ayN+4H8wYQRIwW
X-Google-Smtp-Source: AGHT+IGdmlzAwf9qfVQOHOdpr+P0JJ3hMje1i2OshWya4hxHI39qZjL+0rhVPA5EfM2sZT5+b4vQtQ==
X-Received: by 2002:a05:6402:4302:b0:626:73d7:36c5 with SMTP id 4fb4d7f45d1cf-62673d739f9mr9997431a12.11.1757429561644;
        Tue, 09 Sep 2025 07:52:41 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Ross Lagerwall ,
	Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v5 1/2] efi: Add a function to check if Secure Boot mode is enabled
Date: Tue,  9 Sep 2025 14:52:32 +0000
Message-ID: <69dad96a21e230b35d57b8e3253815f9cb1532d3.1757421999.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

Also cache it to avoid needing to repeatedly ask the firmware.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Gerald Elder-Vass 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 

v5:
- Fix line length
v4:
- Fix MISRA warning regarding SecureBoot string
v3:
- Fix build on ARM
---
 xen/common/efi/boot.c    | 25 +++++++++++++++++++++++++
 xen/common/efi/runtime.c |  1 +
 xen/include/xen/efi.h    |  2 ++
 3 files changed, 28 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e12fa1a7ec04..5eb0394e2937 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -901,6 +901,29 @@ static void __init pre_parse(const struct file *file)
                    " last line will be ignored.\r\n");
 }
 
+static void __init init_secure_boot_mode(void)
+{
+    static EFI_GUID __initdata gv_uuid = EFI_GLOBAL_VARIABLE;
+    static CHAR16 __initdata str_SecureBoot[] = L"SecureBoot";
+    EFI_STATUS status;
+    uint8_t data = 0;
+    UINTN size = sizeof(data);
+    UINT32 attr = 0;
+
+    status = efi_rs->GetVariable(str_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;
@@ -915,6 +938,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 42386c6bde42..30d649ca5c1b 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -41,6 +41,7 @@ void efi_rs_leave(struct efi_rs_state *state);
 unsigned int __read_mostly efi_num_ct;
 const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
 
+bool __ro_after_init efi_secure_boot;
 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 623ed2ccdf31..723cb8085270 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -36,6 +36,8 @@ static inline bool efi_enabled(unsigned int feature)
 }
 #endif
 
+extern bool efi_secure_boot;
+
 void efi_init_memory(void);
 bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
 bool efi_rs_using_pgtables(void);
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 15:09:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 15:09:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117147.1463339 (Exim 4.92)
	(envelope-from )
	id 1uvzyN-0005c1-Q2; Tue, 09 Sep 2025 15:09:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117147.1463339; Tue, 09 Sep 2025 15:09: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 1uvzyN-0005bu-N6; Tue, 09 Sep 2025 15:09:31 +0000
Received: by outflank-mailman (input) for mailman id 1117147;
 Tue, 09 Sep 2025 15:09:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uvzyM-0005bn-5g
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 15:09:30 +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 fb353283-8d8e-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 17:09:29 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aff0775410eso202213466b.0
 for ; Tue, 09 Sep 2025 08:09: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-b0783049ee4sm6044366b.18.2025.09.09.08.09.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 08: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: fb353283-8d8e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757430568; x=1758035368; 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=9UHydMwrSBctP1oJVoY6Mbc86Lfti206VpuVxs6VsZ8=;
        b=dFacP/XiEFCXIDLSW2Yc7/Y3MNpZXuPn8FNmMsas2R4JL1m8qetzd0unL1MykbJgkk
         V517tDYBRI9R2mdwv/5dFgnI/3FSTuw9oyXqffMYhLkpyfSbPM4Lh0c9IwG0N7PimK8t
         sTisa7f4ikYsNv9dgkN459qG5j8T1ulzvuohA3O0PEv5d6wxbibVyZkOzAaLQpnfBeLS
         jErJVBqCdTsIu0Pwt6i3NB2lfxRym4qs901RvCLM0qTnE7qn+bwkUCkBLtmd4FeCgh3T
         RM0bBu7EW3HkDQFziSO1XNFe3eJidTT3aHX12Izohg53qpLBhiKTmBozP/kQgZ28S0DY
         xrOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757430568; x=1758035368;
        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=9UHydMwrSBctP1oJVoY6Mbc86Lfti206VpuVxs6VsZ8=;
        b=UASuSHvA12O4J8tZ0WF+S1yFAwV0/ghSTQIwRu0BeIzPf45lulzzVmlT4aj+urKJva
         rqgoFNws8ubY1U2xcxEfIAnM5Pg8Smjqe41KHa7oJV39jAHD0mmXYpNT/SMi48McuVr8
         yQ1z9IURJhzqf8g4khmgkXXHtiTGVplY2Qc9P+Zpn88Qx9x4My1tCNO5KwjpY9sE2JAE
         hEt6Fs8C25mq9diDAkkZrdUNNRg9olJvU0lmmmoqWhn/FiskqWdPakkEFd68kvL1MUNu
         4hgoCKT13NugaO9MFM6p0Ly9+oSh6zuwuKfI/m4XmiHNqRQs1jCcD2qfhClcZHGg85MR
         uqGQ==
X-Gm-Message-State: AOJu0Yzi/2usPEXYb6gJ1GgnIvBFJNsRKEcw/diJxXj6GG5S103S3Q9F
	D1l9jP1Kr+3fMUy47iJSHv3BWC5OzJaznkMBgAW1RPqq+FnuV3j3X9pxF+JTRJ5bOw==
X-Gm-Gg: ASbGncsBTOvQcP0oRGlEcswGrUP3JcuLQ6pREJNiztd63CE0c5VjAA29CfoYP0vwTO3
	t3DPIZXCQdwkgwzxfKsc6mTQc1XrhiBsNELVaLHvc+PG2ZEyjlRBYKIMfcqrMR1yjcmKoBIQSaT
	uiR8Y2/mE4gbxhKBR/63roclxGtFkrQiL0CLW4F6q1Q/gnSBrdr5WrFyjXVmHOCZ+JrolDnJFiu
	5YVj+Wa/1+6rWRNYYyY6Qhpt6zcXJN5k0uWoueQyf5vjhqCFZNHilH4Jx0kJjSqHnnTTqyvBliZ
	2AV8grP+2GrCtmkuSlhhDEnGDwVKzRhmtVeSrSW2iT891fu1hwnRTQxnDH+CnfN6KqoSNTNTktv
	iAVsqzWVudTD5vq7aXqcFHLbffw/XPpFT3c2mJsDvsd2isrO2da3KkCpZh5fE9T+mhxzM/0y7Jz
	PygNtRFQtbJFRCkE8cieXiYd/J/Gjr
X-Google-Smtp-Source: AGHT+IEOw7rjG/+rECJURORF2MIBSQkwJaJF1/blN8ejW75ahbjZh+QMJDNdITr7z3wE/mN+rdy77g==
X-Received: by 2002:a17:907:7f87:b0:b04:38f2:9060 with SMTP id a640c23a62f3a-b04b1f0d32emr1199078966b.18.1757430568091;
        Tue, 09 Sep 2025 08:09:28 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 17:09:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 0/2] efi: Support Shim LoadImage
To: Gerald Elder-Vass 
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 09.09.2025 16:52, Gerald Elder-Vass wrote:
> Support Shim LoadImage protocol but keep Shim Lock for compatibility
> 
> https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2029800410
> - Saw known unrelated debian-12-x86_64 issue
> 
> Gerald Elder-Vass (1):
>   efi: Support using Shim's LoadImage protocol
> 
> Ross Lagerwall (1):
>   efi: Add a function to check if Secure Boot mode is enabled

You realize that both patches have gone in already, so adjustments need to
be incremental patches now?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 15:13:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 15:13:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117158.1463349 (Exim 4.92)
	(envelope-from )
	id 1uw01t-0007Iz-8p; Tue, 09 Sep 2025 15:13:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117158.1463349; Tue, 09 Sep 2025 15:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uw01t-0007Is-5f; Tue, 09 Sep 2025 15:13:09 +0000
Received: by outflank-mailman (input) for mailman id 1117158;
 Tue, 09 Sep 2025 15:13: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 1uw01r-0007Im-VN
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 15:13:08 +0000
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com
 [2607:f8b0:4864:20::1136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7d1045ef-8d8f-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 17:13:07 +0200 (CEST)
Received: by mail-yw1-x1136.google.com with SMTP id
 00721157ae682-71d603a269cso45772237b3.1
 for ; Tue, 09 Sep 2025 08: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: 7d1045ef-8d8f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757430786; x=1758035586; 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=pxhv7TS3R+BEZMycgEqq+/8pSMfxSRVr+AeF7u8T4Jk=;
        b=EdsSQ+quC+/33HwBXy5/7Gz2WzbHPss+lJmx0n/62NSqPFiddA0FZt+VGC9lnjlyrB
         RxrqqIb627WLNI4IFzwLSCx/oe1sojXRC/F1lXwIyCSCo9mbyhO/iOCEBerkOZ6c+Hr+
         MaB8i9sI5DnN4zNY7kz5HCmQBU57eQBDuEmrs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757430786; x=1758035586;
        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=pxhv7TS3R+BEZMycgEqq+/8pSMfxSRVr+AeF7u8T4Jk=;
        b=WfPk/O0uVLOL+AT4I2XeSU+yom4/3pyLwpft7rjjRUZ3MLz+VoMYTS2lmy4W8M5flp
         55ggg/I9vkNTqLsHaf3TEFEMk25mbQf9AWL0VMn2Op5eEZDjQsZD7ei0esMWfWDGbSRw
         H9hkhTyECaWsSHW0le9RAzHjmJ+9PfwbBsY/bF2cxNkEPRQA1NZI7j0DOHqeyrIZVwH9
         SxFA+BI7FFXCCb22xQJVOWt8uQCFV4YbRaFMOKDYeXdzlrSyBpKfuli+el+XobzuZfVT
         0efoQs5APFKAh00+pCfrbzrWFDDGGZEbuJanWxgUcezNkShzEj5PWA8ElhcROldWjbfp
         2hCQ==
X-Gm-Message-State: AOJu0Yyt7XApEhdu+y/CiQqpryf/TZKB/cOLviIFi2VySMh/ezMox4mj
	bFv4y8tH9Zc36EmrSQY9e7eD391FkywX5inY5GeJ4LzeXQboAxr9J6g/cFL8aD250M+PB3AtTdd
	nddk70tCt7K4CeIa9Wh/zPow/yWzgQt5Te5n2hMfXXnm2yAYYhUyt
X-Gm-Gg: ASbGnctUC8Ur1Al8NbGILqTo2ALG/6s770jHqJq4nhCYhgLPfhXSed0e9kx5FRkeUd8
	mWUYm+zPUp6OLaIczm3aHdN4OeO/IuNOx+TKOYBUtragCqs60Hb8neg8KvNLBGg5jvM6Zx0fHAS
	X27M9fAjUMmJ2LxMoV6+49M8MpRPRKIwEVM0+aiDydifXTI+TVA4tkz0PezrHj3syBXbdHK6ght
	Ge1fA==
X-Google-Smtp-Source: AGHT+IEb3ilDdI5KI07EmYGd570ZUWis5ue4km/apKAvqsyRUfkXGnmBMfT8ygjUyTv2utd/k5gX5qK15X5s2SGDv7I=
X-Received: by 2002:a05:690c:d85:b0:71b:f632:54a7 with SMTP id
 00721157ae682-727f2ad75admr101427317b3.4.1757430785588; Tue, 09 Sep 2025
 08:13:05 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Gerald Elder-Vass 
Date: Tue, 9 Sep 2025 16:12:55 +0100
X-Gm-Features: AS18NWBwO2WXeiKYgBCiji89XbxWmBh-jq6rK6PHS0Q5EqToIA70HXp0ndNnt_E
Message-ID: 
Subject: Re: [PATCH v5 0/2] efi: Support Shim LoadImage
To: Jan Beulich 
Cc: Xen-devel 
Content-Type: multipart/alternative; boundary="000000000000b157e0063e5fbddb"

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

Apologies I did not realise, as there were outstanding comments I assumed
more changes were required

*Gerald Elder-Vass*
Senior Software Engineer

XenServer
Cambridge, UK

On Tue, Sep 9, 2025 at 4:09=E2=80=AFPM Jan Beulich  wrot=
e:

> On 09.09.2025 16:52, Gerald Elder-Vass wrote:
> > Support Shim LoadImage protocol but keep Shim Lock for compatibility
> >
> >
> https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2029800410
> > - Saw known unrelated debian-12-x86_64 issue
> >
> > Gerald Elder-Vass (1):
> >   efi: Support using Shim's LoadImage protocol
> >
> > Ross Lagerwall (1):
> >   efi: Add a function to check if Secure Boot mode is enabled
>
> You realize that both patches have gone in already, so adjustments need t=
o
> be incremental patches now?
>
> Jan
>

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


Apologies I did not realise, as there were outstandin=
g=C2=A0comments I assumed more changes were required

Gerald Elder-Vass
Seni=
or Software Engineer

XenServer
Cambridge=
, UK

On Tue, Sep 9, 2025 at 4:=
09=E2=80=AFPM Jan Beulich <jbeulich=
@suse.com> wrote:
On 09.09.2025 16:52, Gerald Elder-Vass wrote:

> Support Shim LoadImage protocol but keep Shim Lock for compatibility
> 

> https://gitlab.com/xen=
-project/people/geraldev/xen/-/pipelines/2029800410

> - Saw known unrelated debian-12-x86_64 issue

> 

> Gerald Elder-Vass (1):

>=C2=A0 =C2=A0efi: Support using Shim's LoadImage protocol

> 

> Ross Lagerwall (1):

>=C2=A0 =C2=A0efi: Add a function to check if Secure Boot mode is enable=
d



You realize that both patches have gone in already, so adjustments need to<=
br>
be incremental patches now?



Jan




--000000000000b157e0063e5fbddb--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 15:26:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 15:26:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117179.1463399 (Exim 4.92)
	(envelope-from )
	id 1uw0Ee-0001gE-NI; Tue, 09 Sep 2025 15:26:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117179.1463399; Tue, 09 Sep 2025 15: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 1uw0Ee-0001g7-KF; Tue, 09 Sep 2025 15:26:20 +0000
Received: by outflank-mailman (input) for mailman id 1117179;
 Tue, 09 Sep 2025 15: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 1uw0Ed-0001fh-K2
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 15:26:19 +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 4ca30e45-8d91-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 17:26:04 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-6228de280a4so6549839a12.2
 for ; Tue, 09 Sep 2025 08:26: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-b0783464fd3sm5750866b.111.2025.09.09.08.26.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 08:26: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: 4ca30e45-8d91-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757431564; x=1758036364; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iCVwucZcWCykdqJ/EtT3Q8JD61xpHRvmORwf2z2lEG8=;
        b=NztAgoFHfuKjgGUe3SGdGI8EIFVf8odMEA6pYl9q1tIfq5JsAqo4ZS24f227l5TFUO
         gMcx2wvI279hyRoudU2j610oIVEEKuV49dUu+F1CEsE/5eP9fq+H4RSNycJRbN9zUVY5
         cteCardXK21OoPJnnl/a4LR0t7E5Lv1ECfcXRQVxoKC/z6/9S1EHqNXbprzO7cOy+EUV
         iQTyHC5R6+6GVHG4LjbvkH1Mjwkz9TehrOWWli6iljGNUisWGI2GeN1FM4X3jNRXkvpS
         JHwwOj28HYe5UUv840CQ1dW5ZIM9HfCo3zcTQXT+HpYcrsUPyEtSLaDYeZE5OTpcSgis
         ctlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757431564; x=1758036364;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iCVwucZcWCykdqJ/EtT3Q8JD61xpHRvmORwf2z2lEG8=;
        b=FVj9+PmQSuXx8joLZWf3WDLKXu+0A/kdOjtrB5BlwlX1kNfkTcLI0l1muLqq7h15HP
         lCdCe7bwT3tAaOx+ybk+8AngTrGG8D8gsKTzifyPriMeKH4MaLoU756DK2pkfJP6sXLF
         dP4uuX/c6j6QFDDMnP1rzuRs/mLKWxW48wZ7WvNOiq36MO0XPrvo0u1cIuRDwIM3eNrE
         0slm3YVyHhQdvLTilSlr5+xty2fPtxYhCWzeW0D7BT/Y/87LvpE8eghnD450grbh+3jR
         InFaklhCwBegMfmZYIEixOfeULErIYSlSuAHmhkn/nu3Ozgl89hariHZ1h/1fHK9yH6o
         zmQw==
X-Gm-Message-State: AOJu0YxShaLtkEQfgCEq0OPPHvTGfy90xGrNecF/eqmb7+2uQwyxeyb/
	Ex3QstQ96agqHju8UsusCOOThKImh5tKUB4vziqsj9vWnPpb9GieyTPqHV5KVntTXw==
X-Gm-Gg: ASbGnct1u18ma13jRzCIoL9gCjSVe/3NCh03zfkoM93J9+PIiBfmc3bN/hpPXyhlRh4
	NA3hpfBCfldcomb9TiTlErsp1eGUkNWc2n+p5JG8rMH1fFHupQheu7NQ6IzBJfhqhrikDcr31R5
	Z4dNYZZjkp3R/g18U3qr6ldbc4dVP64QB9LnUf7MaW+sGcX1kGyLWNV1F2d7yVG97ZPrLEs/dNo
	P7YxIoqrH0vLfXvBuRL1ySM5uYrvETs/wNzdhsRI8B6WN39FefwaOdt1vKsHiNoxgQkOn8nIGwu
	MzCtuHwfnyptR6nA4U1q5R+xBtueKgjYZVQdjbdLObC9oblLKaiWoZEXbojLIotrDPapajuDlA6
	2d2fRYqdoYK+D8tdRUv0CNouawbBK4RMywQAdXEHD31o4njN8eyP9ph5Mp/5Bgq6BudUw06ysK3
	61vVUvMqNr4QsokrcM5Q==
X-Google-Smtp-Source: AGHT+IEnvlF4xx5B447dB7eXXxMrOakzq9BrHnt2r+M1KXLu+jfT3ALU9XuAotFLcI7kWweyrV7few==
X-Received: by 2002:a17:907:c24:b0:afe:cded:bf96 with SMTP id a640c23a62f3a-b04b1459092mr1091092566b.6.1757431563987;
        Tue, 09 Sep 2025 08:26:03 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 17:26:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 0/2] efi: Support Shim LoadImage
To: Gerald Elder-Vass 
Cc: Xen-devel 
References: 
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.09.2025 17:12, Gerald Elder-Vass wrote:
> Apologies I did not realise, as there were outstanding comments I assumed
> more changes were required

More changes may be required, just that now they will need doing incrementally.
Imo the committing was done a little too quickly.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 16:10:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 16:10:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117200.1463408 (Exim 4.92)
	(envelope-from )
	id 1uw0vY-00012e-QV; Tue, 09 Sep 2025 16:10:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117200.1463408; Tue, 09 Sep 2025 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uw0vY-00012X-Nj; Tue, 09 Sep 2025 16:10:40 +0000
Received: by outflank-mailman (input) for mailman id 1117200;
 Tue, 09 Sep 2025 16:10: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 1uw0vX-00012R-CK
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 16:10:39 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 863c9505-8d97-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 18:10:38 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-6229f5ed47fso5073201a12.1
 for ; Tue, 09 Sep 2025 09:10: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
 4fb4d7f45d1cf-62bfe99ffcbsm1489694a12.3.2025.09.09.09.10.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 09 Sep 2025 09:10: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: 863c9505-8d97-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757434237; x=1758039037; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aI8vG4osWbp5OgmNqe2HTMG3tJfN+5O+Z++VTtjIlHI=;
        b=S46tD9g/YYA9yZsdGdRMfEAeAkupFvbxQDr+HMwGYlaXmYZ9R55mWfGIES0WUefvuo
         Tqde6o8ohZ5PC9Pr8tgWgQvwTJLnrtsvaNXbWv2r9jzYAJ7sBVGPS6HpM2cWgO3O5E1X
         Ix57zeW5GqvZmxzGOUy/So3tL0nCymyOb9VY1xjYt0ADcw0oqBRiFHdZCJ6cu8EXhCU0
         tpa9KWVDIydRVjZUY6ShbM2q+xfKx4uVTifbdgOMUtL2lswtBrsEHhxBEuv3NnVzmvfn
         tPy8hpksF9oDCxm2423z+8fFCJF5EC0oqQyQLI6r/t/8C42Dz9trxSKWshoG3LGtTpoN
         gzRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757434237; x=1758039037;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aI8vG4osWbp5OgmNqe2HTMG3tJfN+5O+Z++VTtjIlHI=;
        b=nvdUSPe23o36/Amo14VGSkQiBl+/a4WR75aIKXGp6LznL7n+xQiHkHrBxiwIQbqhex
         KfAgsuMOmJcH9+0oNMpL8AF7bEapkagBNwOrr7PEsHHIoHphCa4KA+SWgm0GjGamyzYj
         vhohgyZBI21kYkumgSOfTdi9EWlG0gG+VlCX/1LyzakumXfl2yPw1ZUPoW9poWQVk5ID
         oA2hzAyI1/cLbRTjOqtFYGRQmizWk8pjfLdbxCrQRh7w+5o5LFUaZJKGqfO3n/SYxg78
         98HYREVpCj8LPT2/OfCH4wCXEEv2z2tG+EqrIg+LSCYQeAAMFZF9aLfzwYX4YvnJfs1F
         nF/A==
X-Forwarded-Encrypted: i=1; AJvYcCVoxRFNbb4+DLB1BED56i5oOTE4ozcoATlpgBEQlO5bul2W4CHXHjP7+r5CiPVW2yReOQNg1YJuaWc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysOjRSAwqvrMJoUVEpZvLF7MUDUyJ3L414DIAZJRhQhWdqlmpm
	gq361WKS3laSpIq9jZI8qa9FLhvcKQbPtAOCTArOm8KWhZUs+t3vmHhjZhxrNjoyig==
X-Gm-Gg: ASbGncuSo60MS5S15TvTO74uwur7V+3bRuPX+A+0mK96/lnF3CxmCJxUqU6gddnta6d
	iq4eA2ayIdWVctUzuxZBKqCunq1T7WCITaRvcL+RpOSrU6kZmoa/3Jcb9SLCt0QF7/gCF1WxlLY
	rC3hS3U2fG1cefvzc2s+UAbCeqR0vc7zoPmz0JNANq4UUeYU4ITXWQlQL5RLYyqLyfyRK/6L7uB
	5lE6ib3oZLhyTM8BVFbt5EpEN+EwIoXcHH541n5+2wxI5EoV3TE/ryH+csHhwsObgtDQ6IemSUb
	2pci9acQB270nCyDS7+PnY+73V52/HcmRiEnD5atMER8E/1waim5sGR+PvPey2uT1fD4+DJqGFt
	EUxqktCWTTeTJaUB/5eYsIcKiVzQmcSm9L70aJ5/T6vZqJOhLaX5FbQeZLI7FwwEpUaAAeDJepM
	vTb5S1fXI=
X-Google-Smtp-Source: AGHT+IEmQZVnY03evAkGxNSAH3gUvungsQdQcgukf8Sb4hBm9qoOI8jQgMFMZ2bgyRx3i9gcEIcLqA==
X-Received: by 2002:a05:6402:5107:b0:62a:768c:2223 with SMTP id 4fb4d7f45d1cf-62a768c24famr5122328a12.11.1757434237379;
        Tue, 09 Sep 2025 09:10:37 -0700 (PDT)
Message-ID: 
Date: Tue, 9 Sep 2025 18:10:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 0/8] amd-cppc CPU Performance Scaling Driver
To: Penny Zheng 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , Oleksii Kurochko ,
 Community Manager ,
 xen-devel@lists.xenproject.org
References: <20250904063518.2097629-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: <20250904063518.2097629-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.09.2025 08:35, 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 (8):
>   xen/cpufreq: embed hwp into struct cpufreq_policy{}
>   xen/cpufreq: implement amd-cppc driver for CPPC in passive mode
>   xen/cpufreq: implement amd-cppc-epp driver for CPPC in active mode
>   xen/cpufreq: get performance policy from governor set via xenpm
>   tools/cpufreq: extract CPPC para from cpufreq para
>   xen/cpufreq: bypass governor-related para for amd-cppc-epp
>   xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc
>     driver
>   CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq driver support
> 
>  CHANGELOG.md                         |   1 +
>  docs/misc/xen-command-line.pandoc    |   9 +-
>  tools/include/xenctrl.h              |   3 +-
>  tools/libs/ctrl/xc_pm.c              |  25 +-
>  tools/misc/xenpm.c                   |  94 ++--
>  xen/arch/x86/acpi/cpufreq/amd-cppc.c | 703 ++++++++++++++++++++++++++-
>  xen/arch/x86/acpi/cpufreq/hwp.c      |  32 +-
>  xen/arch/x86/cpu/amd.c               |   8 +-
>  xen/arch/x86/include/asm/amd.h       |   2 +
>  xen/arch/x86/include/asm/msr-index.h |   6 +
>  xen/drivers/acpi/pm-op.c             |  58 ++-
>  xen/drivers/cpufreq/utility.c        |  15 +
>  xen/include/acpi/cpufreq/cpufreq.h   |  44 ++
>  xen/include/public/sysctl.h          |   5 +-
>  14 files changed, 936 insertions(+), 69 deletions(-)

As we're considering our options towards getting this work in, can you clarify
two things please:
(1) In v9, the sole changes were related to the use of per-CPU data and the
    adding of a ChangeLog entry?
(2) The driver is inactive by default, i.e. requires use of the command line
    option to come into play?

If the answer to both is yes, we're leaning towards committing v8 plus the
ChangeLog entry.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 17:01:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 17:01:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117226.1463419 (Exim 4.92)
	(envelope-from )
	id 1uw1iX-0007mG-J8; Tue, 09 Sep 2025 17:01:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117226.1463419; Tue, 09 Sep 2025 17: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 1uw1iX-0007m9-Ey; Tue, 09 Sep 2025 17:01:17 +0000
Received: by outflank-mailman (input) for mailman id 1117226;
 Tue, 09 Sep 2025 17: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 1uw1iW-0007m3-Ff
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 17:01:16 +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 98b84f1a-8d9e-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 19:01:15 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3df3be0e098so3213732f8f.1
 for ; Tue, 09 Sep 2025 10:01:15 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e75224d165sm3223632f8f.57.2025.09.09.10.01.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Sep 2025 10:01: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: 98b84f1a-8d9e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757437275; x=1758042075; 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=CWSSPZ9omMuSs31QFjcFEchxLskxKeC36KOFf68CGZg=;
        b=UFUn85rfJMvkAiRYWvIPg+4m/SfJvSWBia++E0ahHs3aCgWTmK9ZES/oLFgIccaJ2H
         87jEj/08drB/nM5d18oFlYqxV40878CpvZRWXJUej9RuXThs+A9mOU/MiPgcuof41Eh6
         aa7wX9p1eUX8FxkAeohF87SKnkHq3CrdQv6x4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757437275; x=1758042075;
        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=CWSSPZ9omMuSs31QFjcFEchxLskxKeC36KOFf68CGZg=;
        b=PWXyDSpZCgnyOhgVQXWz3y0/TtZ8HzD/kb2ZvDMfAuOSIricRKLyBUSlnrZ8M+6uyW
         qm4ZMi++eA9aZXbhCgfQ0iBzNx28HV+uAp43Q6wZvdfGC4+co2aTjGlMYKtip+c97tgb
         XKBMuyhlhqMJZrxlL6yUyqzpIhK+TV025pl4MupJ5CKft11RzV3z/yncqcT77l0MC64E
         bYfe7vYggl5/BWWy5TD8K9kXVletePwDrFqqS8OI1jwWbx3JvEBulhCyHoabs/dXJbLv
         tZgd7R4597B/RFMcg2EF7cR3WNxeRG3i8ZaduNq3b7y6uKM8EDILvfAZn4sMLH53eu4p
         M4rQ==
X-Gm-Message-State: AOJu0YxRqxFG+YbYbAKR2S/ncEdcN/95PTarJormIif/Ymuu9wdadjuJ
	lP5e109ksj3AWHBIeA4o3yR2RyMpbmrzinzto+TASrSlAptcK7oFafIdPQqSDVavwbP980KAwyQ
	8NDw2
X-Gm-Gg: ASbGncvIvslSoDkTkVS543Whqx85wXkbWf+FbSw7/iirCkYEWMVwKTCYzOt8YcDs2dC
	MHW3zUij1KXvrsrMWXuuTZ18IEr1gOT20efyZ7mkp9EuwWwg9G7Awo8Exm6Cpuw41gl/o0VWdBw
	TljnjFwsBYuPCC+BdawUDFQaXos9Zt/G7pbXTzmqA5mngIZ8tUPKYgcWVVfIBg/iR6zM0INRnCq
	NPSlK1lmRcCCaxfY1Pdwdo+Rmue9WiNvbZ+iBYAFQBlZHLRQL6MdxO0HySnI2QiMUbkGmkS2K1h
	HlM34oNUJsRkvzqhpxLoPWZN9w+DviAU+KcLEErdHrYXZQoL2T0jcO+Gn/t+6ap+2pxXAfdJqT2
	Yxf956HbXmjQU/jG1PplNlgBfsyh7YWPEzsbvfnZ+YFoVy34a+ZJHMZtuaJD2zx5iHkCkdAvvfl
	OS
X-Google-Smtp-Source: AGHT+IGhM6N/e8kRKfioGxXjrp2JsjU+wbWsA/pMSQywJa+HLIGpX2rpaMCBQwJxGtJgnHXT+pXeqQ==
X-Received: by 2002:a05:6000:61e:b0:3e7:451f:3a6e with SMTP id ffacd0b85a97d-3e7451f3df8mr7379180f8f.51.1757437274655;
        Tue, 09 Sep 2025 10:01:14 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH TEST-ARTEFACTS] Be explicit about root in scripts/alpine-rootfs.sh
Date: Tue,  9 Sep 2025 18:01:11 +0100
Message-Id: <20250909170111.1810147-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 container is running as root, but be explicit anyway.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Marek Marczykowski-Górecki 
---
 scripts/alpine-rootfs.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index c999b89dbcd8..6fa1d56775bc 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -84,7 +84,7 @@ cd /
     PATHS="bin etc home init lib mnt opt root sbin srv usr var"
     find $PATHS -print0
     echo -ne "dev\0proc\0run\0sys\0"
-} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
+} | cpio -0 -R 0:0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
 
 # Print the contents for the build log
 zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv

base-commit: d7434697deec41ddf31a2f3d189dee75d4d2486f
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 17:15:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 17:15:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117242.1463429 (Exim 4.92)
	(envelope-from )
	id 1uw1wM-0001AF-Nr; Tue, 09 Sep 2025 17:15:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117242.1463429; Tue, 09 Sep 2025 17:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uw1wM-0001A8-Kz; Tue, 09 Sep 2025 17:15:34 +0000
Received: by outflank-mailman (input) for mailman id 1117242;
 Tue, 09 Sep 2025 17:15: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 1uw1wL-0001A0-Ju
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 17:15: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 96231f7c-8da0-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 19:15:30 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-45dde353b47so16100625e9.3
 for ; Tue, 09 Sep 2025 10:15:30 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45df27dd30asm25105085e9.15.2025.09.09.10.15.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Sep 2025 10: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: 96231f7c-8da0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757438129; x=1758042929; 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=qMM8h6Ao3FP5NHBqqYwxtCT3JS8hxYwxHVVU8dEoPUs=;
        b=OC1U/FpLQM100WdfbNaZiT4nk0dSlYgIRqA8Xgy63wvME3FIJ2r9wbza+u0WQgUYWz
         N5uJUDV49N/mrKm597c0x56JLSn9iEggK6iQ0MW+i/OeZlyc3Rg8dGb2l/i+BuyZtcF4
         fO/Hdk4McePrxNnDiuIOLFbb2heqpL/o92gTc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757438129; x=1758042929;
        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=qMM8h6Ao3FP5NHBqqYwxtCT3JS8hxYwxHVVU8dEoPUs=;
        b=LvINBJxFkPZGYGilj1QVPwQvK0Clf/8HH52bSE8MiiCo8DRH4kQ4GqBrmwKvQL9Won
         5qIwRCYiTfUtiTcqdBZ+4ZDQRu9FzjoAeHvNxzqmN5UZci5ul/7U9sfR7PFcTL+M5MSd
         DOctVdpWQsjvqUH60deKAnFg1VyhFf38vnq7o3jW8vm1kDddU8LFwiKQ9++DcMlaXEMJ
         yUj7NEOMhM5VbRzfQ+luxTtl06naZ6Szi0RXPLNPxShBpUsMT+1sK1CbNZske+CKyBQU
         H6/K3MGdTahxKxhK6oVRhbFjF/OPPww65VoiGlYohNJYkllHARw/3NYRRDwI7W6ANmOB
         XN5Q==
X-Gm-Message-State: AOJu0Yw0tSt8a8i2BCWNt3jb5JtLpxuX7lV0P6XTx0Lt4z2IUhFVLmN2
	tvQWLJ4hVWrJApnViV6vpsOrBeUgaBohBWOBemGi8jiWbSOf0gGhSthc6VOnpqifLekGrYnpp+s
	/yt8X
X-Gm-Gg: ASbGnct3SrrUiiTV99Y1UomSYorh1/ovmLbR2RZAbfUgdRzdMgMm4Gc9pXpSs4XvTcW
	adcfyeXfbGscm6iNDWRr4BeGFkEFtwaD8+mQ540RyJGnAKr42GBhcF687RXtPuQBNTTY+rLyAjg
	UMhYFh8NDMa58reCjl1xRMKU+KPF6AaJ5vvK6N2jIxBJ7a8yj3abgEXmQvkAybSBS7v3cufJnzW
	rtj57oy7IhKRBwNJaNaEPyIqAAsTGydCHaFYusKGwZnw5FakThJNZoX2IC9+Pn2jbshyyjg1caP
	NohvRHozd0m79vigXgaHwNC641AIegM1AIPyTSYqMATeKYW7tvVBksrevreUjr+Zx+Psp/FnsC1
	CxSO3s6TOa3JE22yUArc00e4NdCw9bXe9xs/kzuexULPWLcZebsBXjmdnXqt0JDFzqg1G+rgtqx
	YXwVeDkcmGVpE=
X-Google-Smtp-Source: AGHT+IHCNTNsawXqVURtf2iXsb70FlqvMqR0LjXDmkoXhgJh1PjxelHLSDBsgP1f1M3BW94Dgr6r4w==
X-Received: by 2002:a05:600c:4688:b0:45d:d2d2:f095 with SMTP id 5b1f17b1804b1-45deb702e1dmr50687885e9.19.1757438129386;
        Tue, 09 Sep 2025 10:15:29 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH] CI: Create initrd fragments explicitly as root
Date: Tue,  9 Sep 2025 18:15:27 +0100
Message-Id: <20250909171527.1813097-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

We have a mix of root and non-root containers, and are trying to become
rootless.  This can cause the local CPIO fragements to end up being user:user
in the test environment.

Nothing seems to go wrong so far, but it's a trap waiting to happen.

Make everything consistently root for the initrds, irrespective of the
rootness of the container the test is running in.

No practical change.

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

Best reviewed with `git show --colour-words`

I'm intending to backport this all trees as part of the fixes for the root vs
rootless mismatch.
---
 automation/scripts/build                          | 2 +-
 automation/scripts/qemu-alpine-x86_64.sh          | 4 ++--
 automation/scripts/qemu-smoke-dom0-arm32.sh       | 4 ++--
 automation/scripts/qemu-smoke-dom0-arm64.sh       | 4 ++--
 automation/scripts/qemu-smoke-dom0less-arm32.sh   | 2 +-
 automation/scripts/qemu-smoke-dom0less-arm64.sh   | 4 ++--
 automation/scripts/qubes-x86-64.sh                | 6 +++---
 automation/scripts/xilinx-smoke-dom0-x86_64.sh    | 6 +++---
 automation/scripts/xilinx-smoke-dom0less-arm64.sh | 4 ++--
 9 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/automation/scripts/build b/automation/scripts/build
index 0e7494ff6d87..d0511843e7ea 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -108,6 +108,6 @@ else
     # Note: Some smoke tests depending on finding binaries/xen on a full build
     # even though dist/ contains everything, while some containers don't even
     # build Xen
-    (cd dist/install; find | cpio -o -H newc | gzip) > binaries/xen-tools.cpio.gz
+    (cd dist/install; find | cpio -R 0:0 -o -H newc | gzip) > binaries/xen-tools.cpio.gz
     collect_xen_artefacts
 fi
diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
index c4666b9507dc..242ffca693fe 100755
--- a/automation/scripts/qemu-alpine-x86_64.sh
+++ b/automation/scripts/qemu-alpine-x86_64.sh
@@ -25,7 +25,7 @@ mount -t devtmpfs devtmpfs /dev
 chmod +x initrd/init
 # DomU rootfs
 cd initrd
-find . | cpio -H newc -o | gzip > ../domU-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip > ../domU-rootfs.cpio.gz
 cd ..
 
 # Dom0 rootfs
@@ -57,7 +57,7 @@ xl -vvv create -c /root/domU.cfg
 
 " > etc/local.d/xen.start
 chmod +x etc/local.d/xen.start
-find . | cpio -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
 cd ../..
 
 cat >> binaries/pxelinux.0 << EOF
diff --git a/automation/scripts/qemu-smoke-dom0-arm32.sh b/automation/scripts/qemu-smoke-dom0-arm32.sh
index 36c47daa4212..58797f7d30d3 100755
--- a/automation/scripts/qemu-smoke-dom0-arm32.sh
+++ b/automation/scripts/qemu-smoke-dom0-arm32.sh
@@ -30,13 +30,13 @@ curl --fail --silent --show-error --location --output initrd.tar.gz https://dl-c
 mkdir rootfs
 cd rootfs
 tar xvzf ../initrd.tar.gz
-find . | cpio -H newc -o | gzip > ../root/initrd.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip > ../root/initrd.cpio.gz
 cd ..
 rm -rf rootfs
 rm initrd.tar.gz
 
 cp ../zImage ./root
-find . | cpio -H newc -o | gzip > ../initrd.gz
+find . | cpio -R 0:0 -H newc -o | gzip > ../initrd.gz
 cd ..
 
 # XXX QEMU looks for "efi-virtio.rom" even if it is unneeded
diff --git a/automation/scripts/qemu-smoke-dom0-arm64.sh b/automation/scripts/qemu-smoke-dom0-arm64.sh
index ee682015a061..05962bdc0203 100755
--- a/automation/scripts/qemu-smoke-dom0-arm64.sh
+++ b/automation/scripts/qemu-smoke-dom0-arm64.sh
@@ -24,7 +24,7 @@ mount -t devtmpfs devtmpfs /dev
 /bin/sh" > initrd/init
 chmod +x initrd/init
 cd initrd
-find . | cpio -H newc -o | gzip > ../domU-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip > ../domU-rootfs.cpio.gz
 cd ..
 
 # Dom0 rootfs
@@ -54,7 +54,7 @@ xl -vvv create -c /root/domU.cfg
 
 " > etc/local.d/xen.start
 chmod +x etc/local.d/xen.start
-find . | cpio -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
 cd ../..
 
 # XXX QEMU looks for "efi-virtio.rom" even if it is unneeded
diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-dom0less-arm32.sh
index e27636dc9e8f..627d890a3926 100755
--- a/automation/scripts/qemu-smoke-dom0less-arm32.sh
+++ b/automation/scripts/qemu-smoke-dom0less-arm32.sh
@@ -75,7 +75,7 @@ mount -t devtmpfs devtmpfs /dev
 ${domU_check}
 /bin/sh" > init
 chmod +x init
-find . | cpio -H newc -o | gzip > ../initrd.gz
+find . | cpio -R 0:0 -H newc -o | gzip > ../initrd.gz
 cd ..
 
 # XXX QEMU looks for "efi-virtio.rom" even if it is unneeded
diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-dom0less-arm64.sh
index e660485f3a41..05c4a6acbb59 100755
--- a/automation/scripts/qemu-smoke-dom0less-arm64.sh
+++ b/automation/scripts/qemu-smoke-dom0less-arm64.sh
@@ -111,7 +111,7 @@ ${domU_check}
 /bin/sh" > initrd/init
 chmod +x initrd/init
 cd initrd
-find . | cpio --create --format='newc' | gzip > ../binaries/initrd
+find . | cpio -R 0:0 -o -H newc | gzip > ../binaries/initrd
 cd ..
 
 # Dom0 rootfs
@@ -139,7 +139,7 @@ xl network-attach 1 type=vif
 ${dom0_check}
 " > etc/local.d/xen.start
 chmod +x etc/local.d/xen.start
-find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
 # ImageBuilder
diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index bd939dc94894..7a59fa5f1116 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -184,7 +184,7 @@ ${domU_check}
 Kernel \r on an \m (\l)
 
 " > etc/issue
-    find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
+    find . | cpio -R 0:0 -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
     cd ..
     rm -rf rootfs
 
@@ -193,7 +193,7 @@ Kernel \r on an \m (\l)
     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
+    find . | cpio -R 0:0 -H newc -o > ../binaries/domU-in-dom0.cpio
     cd ..
     rm -rf rootfs
 
@@ -252,7 +252,7 @@ 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
-find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
+find . | cpio -R 0:0 -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 96f534f3aaa7..5379738019a7 100755
--- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
+++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
@@ -102,7 +102,7 @@ echo "domU Welcome to Alpine Linux
 Kernel \r on an \m (\l)
 
 " > etc/issue
-find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
 cd ..
 rm -rf rootfs
 
@@ -111,7 +111,7 @@ 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
+find . | cpio -R 0:0 -H newc -o > ../binaries/domU-in-dom0.cpio
 cd ..
 rm -rf rootfs
 
@@ -141,7 +141,7 @@ 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
-find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
 # Load software into TFTP server directory.
diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
index a6da7a830c35..61d6c686f745 100755
--- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
+++ b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
@@ -50,7 +50,7 @@ echo "#!/bin/sh
 ${domU_check}
 /bin/sh" > etc/local.d/xen.start
 chmod +x etc/local.d/xen.start
-find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
 cd ..
 rm -rf rootfs
 
@@ -71,7 +71,7 @@ bash /etc/init.d/xencommons start
 ${dom0_check}
 " > etc/local.d/xen.start
 chmod +x etc/local.d/xen.start
-find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
+find . | cpio -R 0:0 -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
 

base-commit: 2275bf83a1db579661b27fc4b310a7d92594dbc0
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Sep 09 19:24:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 19:24:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117281.1463438 (Exim 4.92)
	(envelope-from )
	id 1uw3ww-0000St-9W; Tue, 09 Sep 2025 19:24:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117281.1463438; Tue, 09 Sep 2025 19:24: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 1uw3ww-0000Sm-6x; Tue, 09 Sep 2025 19:24:18 +0000
Received: by outflank-mailman (input) for mailman id 1117281;
 Tue, 09 Sep 2025 19:24:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uw3wu-0000Sg-T9
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 19:24:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uw3wu-001o0z-1N;
 Tue, 09 Sep 2025 19:24:16 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uw3wu-001ySm-1O;
 Tue, 09 Sep 2025 19:24: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=o8GkZMK2wln4XOREy7mW4l9UCuLVh1sS+K5XuYxbV3g=; b=
	YecagZUQH9PKGz3m4rHjW3VIo0wGcFIwK1qfwtcxFSGSZhJ/2ALUMqWjkIbB3U00tIyi3Cam5T8eC
	UT0aljAQKYARlxj5mPNb9BqZfxSNXV1eAYa8lIh2P1NqTVubGW3Ip9NBA4A/kfk3j0w2j1ZSfZQ3d
	aMLuIglpb5AxhWNU8=;
From: dmukhin@xen.org
Date: Tue, 9 Sep 2025 12:24:15 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH] CI: Create initrd fragments explicitly as root
Message-ID: 
References: <20250909171527.1813097-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250909171527.1813097-1-andrew.cooper3@citrix.com>

On Tue, Sep 09, 2025 at 06:15:27PM +0100, Andrew Cooper wrote:
> We have a mix of root and non-root containers, and are trying to become
> rootless.  This can cause the local CPIO fragements to end up being user:user
> in the test environment.
> 
> Nothing seems to go wrong so far, but it's a trap waiting to happen.
> 
> Make everything consistently root for the initrds, irrespective of the
> rootness of the container the test is running in.
> 
> No practical change.
> 
> Signed-off-by: Andrew Cooper 


Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 19:25:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 19:25:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117291.1463448 (Exim 4.92)
	(envelope-from )
	id 1uw3xt-0000wH-Hr; Tue, 09 Sep 2025 19:25:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117291.1463448; Tue, 09 Sep 2025 19:25: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 1uw3xt-0000wA-FF; Tue, 09 Sep 2025 19:25:17 +0000
Received: by outflank-mailman (input) for mailman id 1117291;
 Tue, 09 Sep 2025 19:25:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uw3xs-0000w2-1o
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 19:25:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uw3xr-001o1h-2Q;
 Tue, 09 Sep 2025 19:25:15 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uw3xr-001yU5-2c;
 Tue, 09 Sep 2025 19:25: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=OexK4p8Ifzjl3kdRxgkg5QWNesTe1yyMw4MnYMEBVHE=; b=RWf3T/9B/rF3aP/QpQ8d1U12B8
	CYoue24FJstUUwZtD0cpehIw9A104lsIUWohfaIxWq/xtn6kS1TSo0/6G8jFYlnISn/Co8/P+JA0g
	vOQpHwOyLiBbiphlIDeFc/0b898z2tDYdJFo9Wuu31xE3L/ajlYmBdjcRvgfnRjQ/mJw=;
From: dmukhin@xen.org
Date: Tue, 9 Sep 2025 12:25:14 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH TEST-ARTEFACTS] Be explicit about root in
 scripts/alpine-rootfs.sh
Message-ID: 
References: <20250909170111.1810147-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250909170111.1810147-1-andrew.cooper3@citrix.com>

On Tue, Sep 09, 2025 at 06:01:11PM +0100, Andrew Cooper wrote:
> The container is running as root, but be explicit anyway.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  

> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Marek Marczykowski-Grecki 
> ---
>  scripts/alpine-rootfs.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
> index c999b89dbcd8..6fa1d56775bc 100755
> --- a/scripts/alpine-rootfs.sh
> +++ b/scripts/alpine-rootfs.sh
> @@ -84,7 +84,7 @@ cd /
>      PATHS="bin etc home init lib mnt opt root sbin srv usr var"
>      find $PATHS -print0
>      echo -ne "dev\0proc\0run\0sys\0"
> -} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
> +} | cpio -0 -R 0:0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
>  
>  # Print the contents for the build log
>  zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv
> 
> base-commit: d7434697deec41ddf31a2f3d189dee75d4d2486f
> -- 
> 2.39.5
> 
> 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 19:38:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 19:38:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117303.1463459 (Exim 4.92)
	(envelope-from )
	id 1uw4AB-0002ky-J1; Tue, 09 Sep 2025 19:37:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117303.1463459; Tue, 09 Sep 2025 19: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 1uw4AB-0002kr-Fv; Tue, 09 Sep 2025 19:37:59 +0000
Received: by outflank-mailman (input) for mailman id 1117303;
 Tue, 09 Sep 2025 19:37: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 1uw4A9-0002kl-NQ
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 19:37:57 +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 7a9de4b7-8db4-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 21:37: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 0F194442F8;
 Tue,  9 Sep 2025 19:37:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30BB1C4CEF4;
 Tue,  9 Sep 2025 19:37: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: 7a9de4b7-8db4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757446672;
	bh=Vkfs1C2Q/m2ciXngYEnMywKI/5g7jYuOYmYnMi4Z+6A=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=BK33sGpV6gJZdNQka35B5igzFncF6O4QoVJduYx5uymEwm19+Pae/Y8Ji2ztm6vFh
	 Of79hrgQzN752E6kK9Pd6CitdpQ05JM71b0yY2nJK5WUadz3JmWI4AqHd+rhRkpPML
	 jPSesTwS7Zw48bKNgh3AxJtfj3r28MMf09jWFv3Lide1Ok8C5lkasp0zoJfr6zuOnF
	 N5cxlSvTSt07fnYvpbKZtFqt6TP2eL80kCSBPIQL9mOveIT/STSyNFrSlP91N6uUF+
	 FdL0uwcDH/ATxbhiykxuiJP1XMjnnp4vhtxpR+0sRrU4PCEIaA22KI5S4HXWZpjWlB
	 smMV1bUYsFvcA==
Date: Tue, 9 Sep 2025 22:37:48 +0300
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	Keith Busch , linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 03/16] dma-debug: refactor to use physical addresses
 for page mapping
Message-ID: <20250909193748.GG341237@unreal>
References: 
 <56d1a6769b68dfcbf8b26a75a7329aeb8e3c3b6a.1757423202.git.leonro@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56d1a6769b68dfcbf8b26a75a7329aeb8e3c3b6a.1757423202.git.leonro@nvidia.com>

On Tue, Sep 09, 2025 at 04:27:31PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky 

<...>

>  include/linux/page-flags.h         |  1 +

<...>

> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -614,6 +614,7 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
>   * available at this point.
>   */
>  #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
> +#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))

This was a not so great idea to add PhysHighMem() because of "else"
below which unfolds to maze of macros and automatically generated
functions with "static inline int Page##uname ..." signature.

>  #define folio_test_highmem(__f)	is_highmem_idx(folio_zonenum(__f))
>  #else
>  PAGEFLAG_FALSE(HighMem, highmem)

Thanks


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 19:42:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 19:42:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117318.1463469 (Exim 4.92)
	(envelope-from )
	id 1uw4Ey-0004Ik-4U; Tue, 09 Sep 2025 19:42:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117318.1463469; Tue, 09 Sep 2025 19:42: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 1uw4Ey-0004Id-13; Tue, 09 Sep 2025 19:42:56 +0000
Received: by outflank-mailman (input) for mailman id 1117318;
 Tue, 09 Sep 2025 19:42:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uw4Ex-0004IX-Ec
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 19:42:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uw4Es-001oNx-2u;
 Tue, 09 Sep 2025 19:42:50 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uw4Es-001zaB-30;
 Tue, 09 Sep 2025 19:42: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=BgCy2fco2YaL2eeY84hZc3zf/PPtvizY8/oxBLPjt0A=; b=
	AwuFQzm33VkZrqhg75xm3KgwDfDyiIYx7lFJf+TGHW+PZ1xuRZbQSWircCk+lVdZX+2jIdxfeAuto
	7savx+YCxiaEQWtrpYqVHrQvvSh2Ata0SP8cvhRU94X6c1AGN49ud8wl2+SzCfh/zXZVRDcSS4qT1
	Q9r+yh5ypTDQGh/Ds=;
From: dmukhin@xen.org
Date: Tue, 9 Sep 2025 12:42:49 -0700
To: Jan Beulich 
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 v7 02/16] xen/8250-uart: update definitions
Message-ID: 
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-3-dmukhin@ford.com>
 <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>

On Tue, Sep 09, 2025 at 12:05:41PM +0200, Jan Beulich wrote:
> On 08.09.2025 23:11, dmukhin@xen.org wrote:
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
> > @@ -32,6 +32,7 @@
> >  #define UART_MCR          0x04    /* Modem control        */
> >  #define UART_LSR          0x05    /* line status          */
> >  #define UART_MSR          0x06    /* Modem status         */
> > +#define UART_SCR          0x07    /* Scratch pad          */
> >  #define UART_USR          0x1f    /* Status register (DW) */
> >  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
> >  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
> > @@ -42,6 +43,8 @@
> >  #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
> >  #define UART_IER_ELSI     0x04    /* rx line status       */
> >  #define UART_IER_EMSI     0x08    /* MODEM status         */
> > +#define UART_IER_MASK \
> > +    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
> 
> Here, aiui, ..._MASK covers all known bits. No #define-s for reserved
> ones.
> 
> > @@ -51,12 +54,19 @@
> >  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
> >  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
> >  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> > +#define UART_IIR_FE       0xc0    /* FIFO enabled (2 bits) */
> >  
> >  /* FIFO Control Register */
> >  #define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> >  #define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> >  #define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> > -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> > +#define UART_FCR_DMA      0x08    /* enter DMA mode       */
> 
> Question is whether we can actually use the source you indicate as
> reference. TL16C550C may already be too different from what a "standard"
> 16550 is (where admittedly it also looks unclear what "standard" would be,
> as I'm unaware of a "canonical" spec).

Yeah, I am not sure there's a "standard" spec for NS16550.

> 
> The source I'm looking at says something entirely different. Maybe we're
> better off simply omitting this #define?

All TL16Cx50 I have mentioned, including Synopsys uart databook, say
FCR's "DMA mode select" is Bit 3.

And Linux'es driver defines it as 0x08 (include/uapi/linux/serial_reg.h)

> 
> > +#define UART_FCR_RSRVD0   0x10    /* reserved; always 0   */
> > +#define UART_FCR_RSRVD1   0x20    /* reserved; always 0   */
> > +#define UART_FCR_RTB0     0x40    /* receiver trigger bit #0 */
> > +#define UART_FCR_RTB1     0x80    /* receiver trigger bit #1 */
> > +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)
> 
> Continuing from the top comment - here, with the TRG infix, the scope is
> clear, too.
> 
> > @@ -98,9 +108,30 @@
> >  /* Modem Control Register */
> >  #define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
> >  #define UART_MCR_RTS      0x02    /* Request to Send      */
> > -#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
> > +#define UART_MCR_OUT1     0x04    /* Output #1 */
> > +#define UART_MCR_OUT2     0x08    /* Output #2 */
> >  #define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
> > +#define UART_MCR_RSRVD0   0x20    /* Reserved #0 */
> >  #define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
> > +#define UART_MCR_RSRVD1   0x80    /* Reserved #1 */
> > +#define UART_MCR_MASK \
> > +    (UART_MCR_DTR | UART_MCR_RTS | \
> > +     UART_MCR_OUT1 | UART_MCR_OUT2 | \
> > +     UART_MCR_LOOP | UART_MCR_TCRTLR)
> 
> Here it's again all non-reserved bits. Yet why do we need #define-s for
> the two reserved ones here? (Same question for FCR, even if there's no
> UART_FCR_MASK.)
> 
> > +/* Modem Status Register */
> > +#define UART_MSR_DCTS     0x01    /* Change in CTS */
> > +#define UART_MSR_DDSR     0x02    /* Change in DSR */
> > +#define UART_MSR_TERI     0x04    /* Change in RI */
> > +#define UART_MSR_DDCD     0x08    /* Change in DCD */
> > +#define UART_MSR_CTS      0x10
> > +#define UART_MSR_DSR      0x20
> > +#define UART_MSR_RI       0x40
> > +#define UART_MSR_DCD      0x80
> > +#define UART_MSR_CHANGE \
> > +    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
> > +#define UART_MSR_STATUS \
> > +    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
> 
> Here it's properly two subsets.
> 
> > @@ -111,6 +142,7 @@
> >  #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
> >  #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
> >  #define UART_LSR_ERR      0x80    /* Error                */
> > +#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)
> 
> But what's the deal here? Why would only two of the bits be covered?
> 
> Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 19:45:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 19:45:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117335.1463478 (Exim 4.92)
	(envelope-from )
	id 1uw4HD-0004tP-LD; Tue, 09 Sep 2025 19:45:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117335.1463478; Tue, 09 Sep 2025 19: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 1uw4HD-0004tI-Ia; Tue, 09 Sep 2025 19:45:15 +0000
Received: by outflank-mailman (input) for mailman id 1117335;
 Tue, 09 Sep 2025 19:45:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uw4HC-0004tC-Ue
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 19:45:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uw4HC-001oQa-2e;
 Tue, 09 Sep 2025 19:45:14 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uw4HC-001zps-2r;
 Tue, 09 Sep 2025 19:45: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=fMBaU2ULXckfSkpkBP60C0aXC+bM4T65O8EiPR2eGvA=; b=
	S2HtFku6z9uJFXup6uSoGT0plWUBdQOdjWhJVS3olfWJlr51ECXfiLB9KLZEPslecWt/p0bCmRthW
	3urdz69rQbYcGA5SBg7AahXLCOVlrsgsPg6i9/iUGjykoYKyxVGZ7Dyg9R8lNW7a4UIXstKv0ouSu
	iCnHbTbaAIgyFhexA=;
From: dmukhin@xen.org
Date: Tue, 9 Sep 2025 12:45:13 -0700
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org
Subject: Re: [ImageBuilder] Use LOAD_CMD by default if not specified in
 load_file()
Message-ID: 
References: <20250909074141.7356-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250909074141.7356-1-michal.orzel@amd.com>

On Tue, Sep 09, 2025 at 09:41:41AM +0200, Michal Orzel wrote:
> Commit 061d6782756f modified load_file() to take load command as
> argument but did not change all the invocations (e.g. loading standalone
> Linux, bitstream, etc.) which broke the output script (load command
> empty). Fix it by defaulting to LOAD_CMD if not specified.
> 
> Fixes: 061d6782756f ("Add config option to use separate load commands for Xen, DOM0 and DOMU binaries")
> Signed-off-by: Michal Orzel 

Reviewed-by: Denis Mukhin  

> ---
>  scripts/uboot-script-gen | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> index 849b8f939e81..4f9261035d73 100755
> --- a/scripts/uboot-script-gen
> +++ b/scripts/uboot-script-gen
> @@ -736,6 +736,12 @@ function load_file()
>      local base="$(realpath $PWD)"/
>      local relative_path=${absolute_path#"$base"}
>  
> +    # Default to LOAD_CMD if not specified
> +    if test -z "${load_cmd}"
> +    then
> +        load_cmd="${LOAD_CMD}"
> +    fi
> +
>      if test "$FIT"
>      then
>          echo "imxtract \$fit_addr $fit_scr_name $memaddr" >> $UBOOT_SOURCE
> -- 
> 2.43.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 21:41:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 21:41:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117366.1463490 (Exim 4.92)
	(envelope-from )
	id 1uw65G-000248-Ie; Tue, 09 Sep 2025 21:41:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117366.1463490; Tue, 09 Sep 2025 21:41: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 1uw65G-000241-EC; Tue, 09 Sep 2025 21:41:02 +0000
Received: by outflank-mailman (input) for mailman id 1117366;
 Tue, 09 Sep 2025 21:41: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 1uw65F-00023v-0d
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 21:41: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 aab51dec-8dc5-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 23:40:57 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 4999141567;
 Tue,  9 Sep 2025 21:40:55 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96C9AC4CEF4;
 Tue,  9 Sep 2025 21:40: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: aab51dec-8dc5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757454055;
	bh=nOhI9cDajzpPCbgqvJnEAb3690mEQOIT7F21OwyyW34=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=irFS9iqiorXLswyGmqcrqrmVl6oj5iY4pRKU0Jv8wSaSlC/GJK9ROZyikHNukMclO
	 KDYhVrJB6ncB1wpLINYcr4OhpwNniEduJr8plVYwaRMiRriT6A+PjwTysbm8rUHXpK
	 ruL0Uufk3vNkjpeN3etxE5mNfq4JAM2sGSF96BIbhj8hryTAv+kGj7USnflFfXBNx9
	 9yPRJecONWK1uSjK11D79yDWlgVrAV10KzSwSSV7bmguQPzFPdV3m7Cqz9kcWHkeQ/
	 9+09l4GsVAh84rKhC2cNyOwAUHi0FPGfI70vOExAKP2w+8VrAZIwigtje4lW0RAC5v
	 NeO3e9AisH5Qw==
Date: Tue, 9 Sep 2025 14:40:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Orzel, Michal" 
cc: Mykola Kvach , xen-devel@lists.xenproject.org, 
    sstabellini@kernel.org
Subject: Re: [ImageBuilder] Use LOAD_CMD by default if not specified in
 load_file()
In-Reply-To: <0330174b-bda4-44fc-825b-6a680070b9dd@amd.com>
Message-ID: 
References: <20250909074141.7356-1-michal.orzel@amd.com>  <0330174b-bda4-44fc-825b-6a680070b9dd@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-325911015-1757454055=:1405870"

  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-325911015-1757454055=:1405870
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 9 Sep 2025, Orzel, Michal wrote:
> On 09/09/2025 11:22, Mykola Kvach wrote:
> > Hi Michal,
> > 
> > Thank you for the patch and the detailed explanation.
> > 
> > On Tue, Sep 9, 2025 at 10:42 AM Michal Orzel  wrote:
> >>
> >> Commit 061d6782756f modified load_file() to take load command as
> >> argument but did not change all the invocations (e.g. loading standalone
> >> Linux, bitstream, etc.) which broke the output script (load command
> >> empty). Fix it by defaulting to LOAD_CMD if not specified.
> >>
> >> Fixes: 061d6782756f ("Add config option to use separate load commands for Xen, DOM0 and DOMU binaries")
> >> Signed-off-by: Michal Orzel 
> >> ---
> >>  scripts/uboot-script-gen | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> >> index 849b8f939e81..4f9261035d73 100755
> >> --- a/scripts/uboot-script-gen
> >> +++ b/scripts/uboot-script-gen
> >> @@ -736,6 +736,12 @@ function load_file()
> >>      local base="$(realpath $PWD)"/
> >>      local relative_path=${absolute_path#"$base"}
> >>
> >> +    # Default to LOAD_CMD if not specified
> >> +    if test -z "${load_cmd}"
> >> +    then
> >> +        load_cmd="${LOAD_CMD}"
> >> +    fi
> >> +
> > 
> > I was wondering if we could use a slightly more concise notation here, like:
> > : "${load_cmd:=$LOAD_CMD}"
> > 
> > It does the same thing but is a bit more idiomatic for Bash scripts.
> Some time ago, Stefano requested me to use a simpler notation in ImageBuilder,
> so that it's immediately clear what the script does. Therefore I followed this
> suggestion here as well. I will let him choose what suits the project best.

I prefer the way Michal wrote it.

This is one of those cases where there is no right or wrong answer.
Mykola's suggestion is a more modern and concise version. The code style
I used was an attempt to be more verbose but also clearer. As always,
when it comes to clarity, each individual finds different approaches
more understandable.
--8323329-325911015-1757454055=:1405870--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 21:42:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 21:42:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117378.1463499 (Exim 4.92)
	(envelope-from )
	id 1uw66s-0002al-SR; Tue, 09 Sep 2025 21:42:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117378.1463499; Tue, 09 Sep 2025 21: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 1uw66s-0002ae-PN; Tue, 09 Sep 2025 21:42:42 +0000
Received: by outflank-mailman (input) for mailman id 1117378;
 Tue, 09 Sep 2025 21:42: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 1uw66r-0002aU-8n
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 21:42:41 +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 e75fdda4-8dc5-11f0-9d13-b5c5bf9af7f9;
 Tue, 09 Sep 2025 23:42: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 7DB8F601F0;
 Tue,  9 Sep 2025 21:42:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93E62C4CEF4;
 Tue,  9 Sep 2025 21:42: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: e75fdda4-8dc5-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757454157;
	bh=TllK/t8gPlfegoxQ23pwX3B2yhT6M30jjEkK+d7gQRc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ozfQn6eueTpbrtOnDky/5n3Oq/+263+9crLRJPDcNSz8+rOc+T0XkgqhGsOiWK58u
	 LESKpC9c6X66RpNYSWyoA9E/OgNf2y3gpSvM/dnraGkJXL7ca6F3osYFeqARJbwSMr
	 Oonmpa5MKnpYwrUUwcfApkQULUxy7/SgRyvQXVxcLMO9CSOVAXGceJ5nKnLv6EYxyA
	 uc1PXSA4EpCjv2ur/AaMAjC2jD5TI6SQAuop+O6pG5yfJwh9LfeAK9fpUpJfP9ruOG
	 R0DiB+nWxBqrYjK1C4Q0Ev5Ad0EaZ9b/gipevbjGNtRObvKjOPO2ak1pNhVfc2NEHE
	 HK7i85oJxuOug==
Date: Tue, 9 Sep 2025 14:42:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
cc: Michal Orzel , xen-devel@lists.xenproject.org, 
    sstabellini@kernel.org
Subject: Re: [ImageBuilder] Use LOAD_CMD by default if not specified in
 load_file()
In-Reply-To: 
Message-ID: 
References: <20250909074141.7356-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, 9 Sep 2025, dmukhin@xen.org wrote:
> On Tue, Sep 09, 2025 at 09:41:41AM +0200, Michal Orzel wrote:
> > Commit 061d6782756f modified load_file() to take load command as
> > argument but did not change all the invocations (e.g. loading standalone
> > Linux, bitstream, etc.) which broke the output script (load command
> > empty). Fix it by defaulting to LOAD_CMD if not specified.
> > 
> > Fixes: 061d6782756f ("Add config option to use separate load commands for Xen, DOM0 and DOMU binaries")
> > Signed-off-by: Michal Orzel 
> 
> Reviewed-by: Denis Mukhin  

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 21:53:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 21:53:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117394.1463509 (Exim 4.92)
	(envelope-from )
	id 1uw6HM-0004O7-Ow; Tue, 09 Sep 2025 21:53:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117394.1463509; Tue, 09 Sep 2025 21:53: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 1uw6HM-0004O0-MK; Tue, 09 Sep 2025 21:53:32 +0000
Received: by outflank-mailman (input) for mailman id 1117394;
 Tue, 09 Sep 2025 21:53:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uw6HM-0004Nu-Dn
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 21:53:32 +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 6bc75502-8dc7-11f0-9809-7dc792cee155;
 Tue, 09 Sep 2025 23:53:30 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id DE5EE601F0;
 Tue,  9 Sep 2025 21:53:28 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5CDAC4CEF4;
 Tue,  9 Sep 2025 21:53: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: 6bc75502-8dc7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757454808;
	bh=Gp2h0aHZdyJJi7aWjXmP1HYFmqQ+auLloFtCPtROtFE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=CDmyhDkF//HdvC6rGzi2zPb/oh1ITMFvamETcelOXuLHgozGgEK71kQ02dnsAu1wD
	 DoYPcgppYesE6YEcDgTthuwTV1NouC0Tiw7aGRElj9wsuIAnZ28qW3uaX+lrbho0KN
	 9p0BzTEMw/QvV6tmy0cFAyEctKVA1mmpGgEl2j+LYQ+4ERdkmKjZvCcH1+q4arJRWQ
	 jLT1X67gytt8BVk8EBbU0UHzkpVnoJnZ64mTvwl3vtwqI8kzlzb/3IsLIpL2iMxzTC
	 9D3NjGN1rQSNl64XPps3CfpdWlQs6PR6pJ+7wpe22At1u7wEpUrfV8wH46lAHZGCW0
	 QquV29Z3mDcXg==
Date: Tue, 9 Sep 2025 14:53:26 -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 , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Shawn Anastasio , 
    Oleksii Kurochko , 
    Doug Goldstein , Victor Lira , 
    Samuel Thibault , 
    Juergen Gross 
Subject: Re: [PATCH for-4.21 0/5] CI: Add Debian Trixie
In-Reply-To: 
Message-ID: 
References: <20250809221206.1260861-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-1658336827-1757454809=:1405870"

  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-1658336827-1757454809=:1405870
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 9 Sep 2025, Marek Marczykowski-Górecki wrote:
> On Sat, Aug 09, 2025 at 11:12:01PM +0100, Andrew Cooper wrote:
> > I know it's past the last-post deadline, but Trixie was only released today.
> > 
> > In terms of backports, we should at least go back to the bugfix branches.
> 
> What is the state of this series? I'm preparing refresh of my various CI
> series and some add more jobs on debian-12 - I wonder if I should make
> them debian-13 already - but for this I need this series committed...

I have been too busy reviewing the non-gitlab patch series for the
feature freeze last Friday and we have a couple of series still to
process.

Maybe gitlab-related series could be committed also past the feature
freeze.
--8323329-1658336827-1757454809=:1405870--


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 23:36:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 23:36:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117425.1463518 (Exim 4.92)
	(envelope-from )
	id 1uw7sQ-0007u4-Px; Tue, 09 Sep 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 1117425.1463518; Tue, 09 Sep 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 1uw7sQ-0007tx-NB; Tue, 09 Sep 2025 23:35:54 +0000
Received: by outflank-mailman (input) for mailman id 1117425;
 Tue, 09 Sep 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 1uw7sP-0007tr-RF
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 23:35:53 +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 b84282f5-8dd5-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 01:35: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 1458760230;
 Tue,  9 Sep 2025 23:35:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC7B1C4CEF4;
 Tue,  9 Sep 2025 23:35: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: b84282f5-8dd5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757460949;
	bh=UdqYZhSD2LFvS1Of2ShP2efKh3iuuOWBIgkXRo70Z8o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=J0VHhwWKSMEUvakYfYxAhZk7TRE5TxNLXQ1dG/Gr88WTr17/3j3WqlPWJtwp7Gk/1
	 ro22dVEkBX0UOHyhParxyDS1arhBjHPlV/KjepTxof8UVMmDUyJvZrsvtAtqzEnv3i
	 X2t5135ijxDHidTLJqWVeWyHgEJF9nyOOQQAfl7obGQEVPGWA1WmCjDZ3E3rInhD7F
	 WFAn0RPHvqgdUY4x/z/vsSY+s1pYciGL/XjOuG0AgTvzwM3l7I4PXjT/9FLV92ps6s
	 doHflMbeX9RACQyrzU7xEXqwda/OenV+USLoo9Unmj4VL7mJcopV0WhPpRIih+iuJL
	 ZUpkeXRKQfXNg==
Date: Tue, 9 Sep 2025 16:35:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
cc: Andrew Cooper , 
    Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH TEST-ARTEFACTS] Be explicit about root in
 scripts/alpine-rootfs.sh
In-Reply-To: 
Message-ID: 
References: <20250909170111.1810147-1-andrew.cooper3@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, 9 Sep 2025, dmukhin@xen.org wrote:
> On Tue, Sep 09, 2025 at 06:01:11PM +0100, Andrew Cooper wrote:
> > The container is running as root, but be explicit anyway.
> > 
> > No functional change.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Denis Mukhin  

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Sep 09 23:37:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Sep 2025 23:37:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117437.1463530 (Exim 4.92)
	(envelope-from )
	id 1uw7tl-0008SH-5t; Tue, 09 Sep 2025 23:37:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117437.1463530; Tue, 09 Sep 2025 23:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uw7tl-0008SA-1X; Tue, 09 Sep 2025 23:37:17 +0000
Received: by outflank-mailman (input) for mailman id 1117437;
 Tue, 09 Sep 2025 23:37: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 1uw7tk-0008S2-5E
 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2025 23:37:16 +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 e9aad34a-8dd5-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 01:37: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 64E1660230;
 Tue,  9 Sep 2025 23:37:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BCA9C4CEF4;
 Tue,  9 Sep 2025 23:37: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: e9aad34a-8dd5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757461033;
	bh=E/bJOLuTUuvAlsRWZrQ9ioldXV4lYDFfEuTtWo/f1XI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=SbKH+VAdS2ptZAMIiWCfd0foRNhTAGz8KEx+2siyeBQ8GssjCVjsJQziXPjbvTNRw
	 Ow6jFnBpf9thpMQfnklGXmKPumqVmI1C9Yw5yi45vF4orO2OdChwGfqrh0KiynqjNo
	 HTmxr62T9JWUi5YBs7ihZQL6zPzrxT8bjzU98CCjb3PEvKb1QDYNUyWGmGcidfjwW+
	 orZIUPQXxMHYCOm5cl4+rOC+Su6EhbPf7yD5xNhkPKS0fxCRNOMMPpr1zkZ/yo0bCV
	 LGhQ+06CrgiFlYj4giEObCJcq3RKXpxroEwtYIm88r2386E07ua3FVCVOOeXmpvSsZ
	 0nzAobHJSVpqQ==
Date: Tue, 9 Sep 2025 16:37:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmukhin@xen.org
cc: Andrew Cooper , 
    Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH] CI: Create initrd fragments explicitly as root
In-Reply-To: 
Message-ID: 
References: <20250909171527.1813097-1-andrew.cooper3@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, 9 Sep 2025, dmukhin@xen.org wrote:
> On Tue, Sep 09, 2025 at 06:15:27PM +0100, Andrew Cooper wrote:
> > We have a mix of root and non-root containers, and are trying to become
> > rootless.  This can cause the local CPIO fragements to end up being user:user
> > in the test environment.
> > 
> > Nothing seems to go wrong so far, but it's a trap waiting to happen.
> > 
> > Make everything consistently root for the initrds, irrespective of the
> > rootness of the container the test is running in.
> > 
> > No practical change.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> 
> Reviewed-by: Denis Mukhin  

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 05:26:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 05:26:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117529.1463587 (Exim 4.92)
	(envelope-from )
	id 1uwDLf-000780-VR; Wed, 10 Sep 2025 05:26:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117529.1463587; Wed, 10 Sep 2025 05:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwDLf-00077m-QZ; Wed, 10 Sep 2025 05:26:27 +0000
Received: by outflank-mailman (input) for mailman id 1117529;
 Wed, 10 Sep 2025 05:26: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 1uwDLf-00077g-Dc
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 05:26: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 b173b8c9-8e06-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 07:26: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 AFB3041752;
 Wed, 10 Sep 2025 05:26:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF34CC4CEF0;
 Wed, 10 Sep 2025 05:26: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: b173b8c9-8e06-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757481983;
	bh=bqpgnX0YeaX4gP4gTelyGSzbrLPxwuSSl4ugIJkeFPI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=W3++ctIiiR7UFpzqM9AUidv9AQ1n3Dz1tKeZadPk/293ETffI9nRLBp7aQx9AFled
	 M5GCYM1B4a3jkkhLPVRESnUtwcqokI2ZK9ojJ1YPCMkJpjHT45Cl+QruyYKY3aGARs
	 FpovID2F5xbpoec1xDhgC6MFSHIrXsB7JTzFkx6nfm41N+Pm3w/y/LnuGSrU2VRkhJ
	 x7tt8kh1ACIrOtgalXRNyxNgQvord1Z8/t1JGvHRdIaRHxawPvJnDmdHHJxvC9RDqD
	 RQiYwqXBRXcawbcju2eKP99VtdepUl8ofw/258NbTAl3BVZxhNFXZSkWH5N4CtNQIn
	 DIZ8LyFL6amIQ==
Date: Wed, 10 Sep 2025 08:26:18 +0300
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	Keith Busch , linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 03/16] dma-debug: refactor to use physical addresses
 for page mapping
Message-ID: <20250910052618.GH341237@unreal>
References: 
 <56d1a6769b68dfcbf8b26a75a7329aeb8e3c3b6a.1757423202.git.leonro@nvidia.com>
 <20250909193748.GG341237@unreal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250909193748.GG341237@unreal>

On Tue, Sep 09, 2025 at 10:37:48PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 09, 2025 at 04:27:31PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky 
> 
> <...>
> 
> >  include/linux/page-flags.h         |  1 +
> 
> <...>
> 
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page-flags.h
> > @@ -614,6 +614,7 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
> >   * available at this point.
> >   */
> >  #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
> > +#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
> 
> This was a not so great idea to add PhysHighMem() because of "else"
> below which unfolds to maze of macros and automatically generated
> functions with "static inline int Page##uname ..." signature.
> 
> >  #define folio_test_highmem(__f)	is_highmem_idx(folio_zonenum(__f))
> >  #else
> >  PAGEFLAG_FALSE(HighMem, highmem)

After sleeping over it, the following hunk will help:

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index dfbc4ba86bba2..2a1f346178024 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -614,11 +614,11 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
  * available at this point.
  */
 #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
-#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
 #define folio_test_highmem(__f)        is_highmem_idx(folio_zonenum(__f))
 #else
 PAGEFLAG_FALSE(HighMem, highmem)
 #endif
+#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))

 /* Does kmap_local_folio() only allow access to one page of the folio? */
 #ifdef CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP


> 
> Thanks
> 


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117573.1463645 (Exim 4.92)
	(envelope-from )
	id 1uwFQ5-0005z7-7t; Wed, 10 Sep 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 1117573.1463645; Wed, 10 Sep 2025 07: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 1uwFQ5-0005z0-4N; Wed, 10 Sep 2025 07:39:09 +0000
Received: by outflank-mailman (input) for mailman id 1117573;
 Wed, 10 Sep 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 1uwFQ3-0005yo-TA
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:08 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2414::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3a183332-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:05 +0200 (CEST)
Received: from SJ0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::20)
 by DM4PR12MB7669.namprd12.prod.outlook.com (2603:10b6:8:106::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:00 +0000
Received: from SN1PEPF000252A4.namprd05.prod.outlook.com
 (2603:10b6:a03:41b:cafe::19) by SJ0P220CA0013.outlook.office365.com
 (2603:10b6:a03:41b::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:00 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:38:59 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:38:51 -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: 3a183332-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d7pjUR1xiJYV84RJKpDjO61360xjrzptu23HzBmPZ+nu9umuhZnOAs62VvUPxpEid+s4X1/O1eOld8vcIYggXduMd75wIH6UT+VqaoGtLSw87U0IoMs2OAAjAwfObVVYaXFeSdWTgKuCWOi/DpwqOuDrEH+Y6VMyQuJnUxRa9/fDQwP66yGasPM0YqmlnE/Qj3sDoevuHv8zVENkPYwBkmsFT14IIDQQsxy/qq0suzAigSJx3Mh7bh9JiIcMOGJjRqpgODG9zwNMZqpQZYxNnx13uv3wsodmyMnr96lhgTbcBv45zHvSIUyEwrPl6VYfu58JJaKWkZ9RmoQ/zyAzZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ylJOAkC+9Y2pugvuLeeDf16FjlbynvMsbrnjYJVPdNA=;
 b=qBZmgokhC5B+8PV+/ffvVKZkB04rpcX+GqGGVIHPcbbKGJIpWpE/6QYlsEgoXWKR9J8xNLCPv51pnwHBu8ce4gLBLD3n7kySx1WkpocTSlHeyJXk7eQp+HKQSmcd3Pgh88gwP3a1fA2ArD7UAw6y/e5En34RVhQo3CGaTOCtFRTG2B87qp35pXbRUiWYlbdFy5R7MWTm6rYkHMwDgwqa8AvBvS79NzIWLDaRr/sNqUi3nj/qfqTabJEz0tko9nVYujR86c2P86CjanUukVr/BwpRVOYKAmO7t6N4nfkOYQINLx57x8gGfsTK6iKBierreAZzz4uOPr4/u49gLZVtug==
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=ylJOAkC+9Y2pugvuLeeDf16FjlbynvMsbrnjYJVPdNA=;
 b=jiu6Z/i9YPlVcQsmNQXNTOKkDAlTlRYAv1pFiZjhi7ZXDpZcJn7nzVDCYbp0BDzO6j7rAgmf/zCoqeimymtMVLaauHparV2WZRImmbPq1sR7CvovxsjTwvRA7OamWfEvrDHg6CjyLXgaHJOWPZ5bjaJCeISrza5f3CoYsl1iVKY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Alistair Francis ,
	Bob Eshleman , Connor Davis ,
	Oleksii Kurochko , Nathan Studer
	, Stewart Hildebrand , "Dario
 Faggioli" , Juergen Gross , George
 Dunlap , "Daniel P. Smith"
	, "Tamas K Lengyel" ,
	Alexandru Isaila , Petre Pircalabu
	, Christopher Clark
	, Meng Xu , Rahul Singh
	
Subject: [PATCH v2 00/26] Disable domctl-op via CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:01 +0800
Message-ID: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A4:EE_|DM4PR12MB7669:EE_
X-MS-Office365-Filtering-Correlation-Id: 1f9549af-3cae-463b-1618-08ddf03d1b46
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?uE5QUSGhDGo+C4Ob24HGYuMKyjeO7EL1V/UWxWrpXwHndyPmbJT4L7M0Jwlu?=
 =?us-ascii?Q?tJ+twlDvoWcXF0RAqOwbmLM2BosWxZvTKVT1Aax+m9jHphLErfefd8d3SpwG?=
 =?us-ascii?Q?UqCT5ZzhSkr+urHN7Ys8eD3jVtyhbLm7KkVUoJMdLb/nC46a78BcHSfQ0npW?=
 =?us-ascii?Q?Bc9El2E6BqIRZa0N+WOxyEm+dZpFcI4VsseodtFB6wCKs1uXoyuN9fEWaOJr?=
 =?us-ascii?Q?GqtPAAPBJE7yJIIJlM5qTl5XfMLL7JQbgDYV6E7lDUwwsFttuatFuXcZhyXd?=
 =?us-ascii?Q?4By5FiuD1M+gtm/aZ09Odex1yZocvq4Jrbz/Wk770VowDmuE5VmOXn8iIiGF?=
 =?us-ascii?Q?4/AWO0OJuCe3xFD6b4WBB5CvAP/jFyzGOKhEpaYDnMcEZMHv8ADeonOlLezt?=
 =?us-ascii?Q?GfIjvsijKeyDYkBN4Ov1mLhQuhD112B2EeITZD+oXVULrgjAwZ64O2CcWdmp?=
 =?us-ascii?Q?kB8teXvzvn0T/qbkQD0DPq8yi8PUvCdyHei/3YxSd37mDCzCpeYov9tGykfk?=
 =?us-ascii?Q?tsk1PophSe+eykvutw+JodwmtcRbL8o8/+HdZyhQ/O1rTFDNmLkdfo70e3VF?=
 =?us-ascii?Q?hrZ4B6zKDe6mm/O6Lng4iuidjO4Hxh10MMU/FSlgv6pC3PyDSx9P+7mSYzWK?=
 =?us-ascii?Q?nebg5qC0BVKwuPctdUxHviagLiDugqJlIZwS6HJP6OgBw9Zf5xVgOiVV0arC?=
 =?us-ascii?Q?LLpmHoAUhel9K4inPNDm0qzSoIJ5ingn1SGvkXzwQu9NsmXp/Tq2DdJmzY28?=
 =?us-ascii?Q?ZRQYu5PdvZ2oNQma5P8uHg4mGJErkIqfBkIEBHRcTg24KAx52TMt4ExswAiQ?=
 =?us-ascii?Q?nZgpdlEWaReQmtE4GpDKAKGIkCCNMvIx7/QBEZGFARH564bGi99qUlx34I28?=
 =?us-ascii?Q?YjiM6U6iOKolN2GgdRnRh7UNEgZEcwRXP15spCKGRvhskCGCqAQfDwf4iffu?=
 =?us-ascii?Q?u0fGxCRFWDaFl3ixXepAOoby8rBnYB4NkBLmm3ceB5KK5qd662Y6vOmIJOJb?=
 =?us-ascii?Q?fiUcI/6uACdTqB4W6ovgagJg5zFfGEJ56aM8YJ8paJizkJJM6CzxviokM4WA?=
 =?us-ascii?Q?hWYyY7USyWVPZH1Mv2OGH9r7APpQhIlpUfBt1l1jLI90IWJ3p4Je9sRq6zy7?=
 =?us-ascii?Q?WdeDj4Fvxq/UT1gfC7al8suTgKWtJAz2FjYqQba2gzX3TzvAqQiyu1nokMi9?=
 =?us-ascii?Q?Qk5XeWsNGgGmXE6E/w1XFqkBwKZ2AcjqUZPlfO4Pl28rkGObCcxTwPqKhtnG?=
 =?us-ascii?Q?mgjBtxVEOHA34oaknUIuLRBYno2zFvzf5ERpmCyMx/NLc4gXVSIrNt0HQnoC?=
 =?us-ascii?Q?PdgASco6wohQ4flR8FpdSOWEKttVsXBJ5/D74Xjs7PKOcp/aoscZHQIGM4Fa?=
 =?us-ascii?Q?3sFQDAJNdOqPWqhYWKT0fmlI/dawPHpgVx64WQIDYD5HJ2YfUJRpjMnhQyou?=
 =?us-ascii?Q?b5tI69k+VZkf7Ph8CxZ2XbVD3rXGbQH97HCFSUX6yqm8xkvhILWxyQ=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:38:59.7345
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f9549af-3cae-463b-1618-08ddf03d1b46
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7669

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.
We are introducing a new single Kconfig CONFIG_MGMT_HYPERCALLS to manage
such hypercalls.

We are trying to disable hypercalls in the following aspects:
- sysctl
- domctl
- hvm
- physdev
- platform
This patch serie is only focusing on domctl-op. Different aspects will be
covered in different patch serie.

Features, like VM event, or paging log-dirty support, which fully rely on
domctl-op, will be wrapped with CONFIG_MGMT_HYPERCALLS, 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 (26):
  xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE
  xen/sysctl: replace CONFIG_SYSCTL with CONFIG_MGMT_DOMCTL
  xen/x86: consolidate vram tracking support
  xen: consolidate CONFIG_VM_EVENT
  xen/x86: make VM_EVENT depend on CONFIG_MGMT_HYPERCALLS
  xen/xsm: wrap xsm_vm_event_control() with CONFIG_VM_EVENT
  xen/domctl: wrap domain_pause_by_systemcontroller() with
    MGMT_HYPERCALLS
  xen/domctl: wrap domain_soft_reset() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap domain_resume() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap domain_kill() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap domain_set_node_affinity() with
    CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap vcpu_affinity_domctl() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap sched_adjust() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap arch-specific arch_get_info_guest() with
    CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap xsm_{irq_permission,iomem_permission} with
    CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap arch-specific domain_set_time_offset() with
    CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap xsm_set_target() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap xsm_getdomaininfo() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap set_global_virq_handler() with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap iommu-related domctl op with CONFIG_MGMT_HYPERCALLS
  xen/xsm: wrap xsm-iommu-related functions with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap arch_{get,set}_paging_mempool_size() with
    CONFIG_MGMT_HYPERCALLS
  xen/x86: make CONFIG_X86_PSR depend on CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap arch-specific domctl-op with CONFIG_MGMT_HYPERCALLS
  xen/xsm: wrap xsm functions with CONFIG_MGMT_HYPERCALLS
  xen/domctl: wrap common/domctl.c with CONFIG_MGMT_HYPERCALLS

 xen/Kconfig.debug                           |  4 +-
 xen/arch/arm/Makefile                       |  2 +-
 xen/arch/arm/arm32/Makefile                 |  2 +-
 xen/arch/arm/arm64/Makefile                 |  2 +-
 xen/arch/arm/domain.c                       |  5 ++
 xen/arch/arm/include/asm/tee/tee.h          |  2 +
 xen/arch/arm/mmu/p2m.c                      |  8 +++
 xen/arch/arm/mpu/p2m.c                      |  2 +
 xen/arch/arm/tee/ffa.c                      |  4 ++
 xen/arch/arm/tee/optee.c                    |  4 ++
 xen/arch/arm/tee/tee.c                      |  2 +
 xen/arch/arm/time.c                         |  2 +
 xen/arch/riscv/stubs.c                      |  4 +-
 xen/arch/x86/Kconfig                        |  1 +
 xen/arch/x86/Makefile                       |  6 +-
 xen/arch/x86/configs/pvshim_defconfig       |  2 +-
 xen/arch/x86/domain.c                       |  4 ++
 xen/arch/x86/emul-i8254.c                   |  2 +
 xen/arch/x86/hvm/Makefile                   |  4 +-
 xen/arch/x86/hvm/hvm.c                      |  4 ++
 xen/arch/x86/hvm/pmtimer.c                  |  2 +
 xen/arch/x86/hvm/save.c                     |  2 +
 xen/arch/x86/hvm/svm/svm.c                  |  8 +++
 xen/arch/x86/hvm/vmx/vmx.c                  | 16 +++++
 xen/arch/x86/include/asm/hvm/hvm.h          | 20 +++++++
 xen/arch/x86/include/asm/hvm/monitor.h      | 65 ++++++++++++++++++++-
 xen/arch/x86/include/asm/hvm/vm_event.h     |  4 ++
 xen/arch/x86/include/asm/mem_access.h       |  9 +++
 xen/arch/x86/include/asm/monitor.h          |  7 +++
 xen/arch/x86/include/asm/p2m.h              |  6 +-
 xen/arch/x86/include/asm/paging.h           | 34 +++++------
 xen/arch/x86/mm/hap/hap.c                   |  4 +-
 xen/arch/x86/mm/mem_sharing.c               |  4 ++
 xen/arch/x86/mm/p2m-pod.c                   |  2 +
 xen/arch/x86/mm/p2m.c                       | 30 ++++++++++
 xen/arch/x86/mm/paging.c                    | 36 ++----------
 xen/arch/x86/psr.c                          | 18 ------
 xen/arch/x86/time.c                         |  2 +
 xen/common/Kconfig                          | 22 +++----
 xen/common/Makefile                         |  7 +--
 xen/common/argo.c                           |  2 +
 xen/common/device-tree/device-tree.c        |  2 +
 xen/common/domain.c                         | 10 ++++
 xen/common/event_channel.c                  |  2 +
 xen/common/grant_table.c                    |  2 +
 xen/common/page_alloc.c                     |  8 +--
 xen/common/perfc.c                          |  4 +-
 xen/common/sched/arinc653.c                 | 10 ++--
 xen/common/sched/core.c                     | 10 ++--
 xen/common/sched/cpupool.c                  | 16 ++---
 xen/common/sched/credit.c                   | 10 +++-
 xen/common/sched/credit2.c                  | 10 +++-
 xen/common/sched/private.h                  |  6 +-
 xen/common/sched/rt.c                       |  4 ++
 xen/common/spinlock.c                       |  4 +-
 xen/drivers/char/console.c                  |  4 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  8 +++
 xen/drivers/passthrough/arm/ipmmu-vmsa.c    |  6 ++
 xen/drivers/passthrough/arm/smmu-v3.c       |  4 ++
 xen/drivers/passthrough/arm/smmu.c          |  4 ++
 xen/drivers/passthrough/device_tree.c       |  6 ++
 xen/drivers/passthrough/iommu.c             |  2 +
 xen/drivers/passthrough/pci.c               |  6 ++
 xen/drivers/passthrough/vtd/iommu.c         |  6 ++
 xen/include/hypercall-defs.c                | 14 ++---
 xen/include/xen/domain.h                    | 13 +++--
 xen/include/xen/mem_access.h                | 35 ++++++++++-
 xen/include/xen/monitor.h                   |  8 ++-
 xen/include/xen/vm_event.h                  | 24 +++++++-
 xen/include/xsm/xsm.h                       | 58 +++++++++++++-----
 xen/lib/x86/Makefile                        |  2 +-
 xen/xsm/dummy.c                             | 16 ++---
 xen/xsm/flask/hooks.c                       | 44 +++++++-------
 73 files changed, 522 insertions(+), 202 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117574.1463655 (Exim 4.92)
	(envelope-from )
	id 1uwFQ6-0006Cq-Il; Wed, 10 Sep 2025 07:39:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117574.1463655; Wed, 10 Sep 2025 07:39: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 1uwFQ6-0006Ch-Fk; Wed, 10 Sep 2025 07:39:10 +0000
Received: by outflank-mailman (input) for mailman id 1117574;
 Wed, 10 Sep 2025 07:39: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 1uwFQ4-0005yt-GW
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:08 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2414::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b29f9b7-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:07 +0200 (CEST)
Received: from SJ0P220CA0017.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::27)
 by CH2PR12MB9544.namprd12.prod.outlook.com (2603:10b6:610:280::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:03 +0000
Received: from SN1PEPF000252A4.namprd05.prod.outlook.com
 (2603:10b6:a03:41b:cafe::60) by SJ0P220CA0017.outlook.office365.com
 (2603:10b6:a03:41b::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:03 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:03 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:38:58 -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: 3b29f9b7-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yjYAtNysZXPnxXPZywMkxtpRWtfpd0NwvpyfkkblJm1e59WLAj2246pYtPCzq5JFp39U54cpe3mnAjL7t2Y2jj+Y9arDj8vYaEMVDMoJBk5PRkF68ujK7tecqR22xz6tUp+3gvA/xMbto4KdDXXX5swevDphnG1eQAMdudMj2xSmAb2QVcNeTOM2jgfdsEFW6FFzEqL9O18+mNBhBcOdnnbTJQ7+9yVEGgakNtT6MZeHDQx9Fn5JWfzqcL/0Tztxq79m+YrgWtbsHOzxsanZ3erQ7dEL6pgyyb3MziswfCi1A7N/9BtN5O5tsv52TWu/8EaTVRCDNY7Yq1Nc+LSnAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YxOcHOXvmIbr0QEYbINptXR3BM3f6TIv8bBEhB3MSPE=;
 b=K1hjXjn5Ga2XHPikBmzNn+vjOkL0V6r49xymlNlLHa/rExtLmz9rVlCr6VREfyBsEFLIp/dVZ8vWi+G1qxKsPo6j2OJzMqViKXW3ytP7Q5RH8iRUEigFse2as7dpfz5UGpuNrw8V/+FghSw0TQgHFb3AO9vzog83iZgeaRSTtrfvvjs7E1U/QGFnfFZTM/SKcXLwsbVmnT/7X0XQurQmOAWrBmlj5IbsvhdnxXkcpYkHCAtB9N7nIUn0yx4Q634MSgAwAhKlmwCRsjPmk/4kbCk6Bfj6n51pbjUZ0yHW8liKe6iVrLMFjPY6/CnXX9h/DN3YpiZUnp4WQBpZetVzdw==
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=YxOcHOXvmIbr0QEYbINptXR3BM3f6TIv8bBEhB3MSPE=;
 b=G6oMCg++PlJB6Rd0kHxqX4agvhUXF9o26MSDdbEXyKXA+l6Ykt9E+aXcouZaeyI0ZIW8wmTlWrKRyKqpjrj1z61/qMM95aXUtJmZOwSELYa0p/XHgqY/3F9/OaZBgYnV4InWKpX6V2wAAn9wvxwolNT1rIlnZoKFvBsKBnVNTzM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 01/26] xen/x86: move domctl.o out of PV_SHIM_EXCLUSIVE
Date: Wed, 10 Sep 2025 15:38:02 +0800
Message-ID: <20250910073827.3622177-2-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A4:EE_|CH2PR12MB9544:EE_
X-MS-Office365-Filtering-Correlation-Id: c6b828ef-62d5-4e73-9dec-08ddf03d1d54
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?lRcMgvABeNNSS2kzOiQqAFxZsOU80Lms3fMDKFzLs8n1XXULDq3vlLz1L10w?=
 =?us-ascii?Q?Pso4n9h6GceDPmRuPjCQXHGwa3TLHJ9dLrge0spr1jzeC+yMK2pvs7j43piy?=
 =?us-ascii?Q?9m6kSBdu9OorssHsKcu0gizxqywA/+2D+KmIgKaiVxTIvEjaGUXF1S2o+0g7?=
 =?us-ascii?Q?aFacyBLcHQ5PuJ8f1lC/pzcE6ZZCDrtPhGAiWrrdEBh8Pp8mKxS9VUMnNKNd?=
 =?us-ascii?Q?OWMK7QRdeAVh1WRr/rBFx41BGpDWJJP9K3mJjOmBAKinwr1z4ashoSGhc9WY?=
 =?us-ascii?Q?hE91x/mUGA7uR7hCrMMf7WbGqcu6eZ//OIC53RVmhxeHyPm7kyx9KqMqtkbI?=
 =?us-ascii?Q?1rRliw6p6OenpUYNtGSiOMbz75+4zlJICunGwSgtNBLrbCdYQJp+xEEmenAf?=
 =?us-ascii?Q?1er0JD9VDGV3RrRB7b8EpEFIMBar0ulGDdfSf8k/l/pR2RfhZyYYQ9VLXMOi?=
 =?us-ascii?Q?Md2Y+5fJzU1TuCfXZTM5avEuqHpUmoP/foIs2fNqbZvhEyC+aCC9krY/230F?=
 =?us-ascii?Q?9nlM6KZjm7uwLEwNwIpl4h0WgspXgFp44EfXvAqZRm8bH6oaV5sOI+ggrkfr?=
 =?us-ascii?Q?7nMedc8rRVNc44WtbnIENyp8n9s/Ndt1n/uvpeZlHDY58E3311r7NnT2eBwY?=
 =?us-ascii?Q?GEV5tX48neYqKU29W57nhf+r/9e57x6qS104Uos2hJMRH8AJyf6x4cUNKGLt?=
 =?us-ascii?Q?KfcWs0ToPny9AWtR4HcNx1eGRglbNB5dUOZnB7VKKQgA4njYFd+vfIT9pz7B?=
 =?us-ascii?Q?5wuKmqmH2+hRj4/131I3AKaNVtDNKMHBsoXWx0CMiOuwUnQI/wO6JL1jX4PN?=
 =?us-ascii?Q?Q5WeBO+5Lk74cVZRviTFpePVslr3bfHsG6YFCRdwYw0rJ/SEDAeLMQ7KlJSy?=
 =?us-ascii?Q?h+XwJApY2ahxkyddzcCdJ/wFFOUvOKEeS1SQJ75PvB9926i5P04WqQGVx0qc?=
 =?us-ascii?Q?DMhQWozoGi8WCIFV351E4+lEwiQPo291LOHeSKdpI6juX+zIHd24GK2vBR38?=
 =?us-ascii?Q?iivnPNGayNCY2NlnKQ5UT13R5mFt3CpJwvHURAIPi4e+VRaZh6xLliMTM0xL?=
 =?us-ascii?Q?FSpta82ZhbuHP6ERD3XRAeLfFb2I3al//aQkvFKPviGMoaikL/mg3mDJD8oC?=
 =?us-ascii?Q?d4FsguwB/F9BREYDxpGT15Do7EFSHxAV30OaG7jd5lKAfJtecDSaLTSQNT9d?=
 =?us-ascii?Q?YSiPEvzp7Lnqlmgptku3ZNaE5I1GscGCXzlJG877n9EthVVo8LZknd17TOH9?=
 =?us-ascii?Q?LDY4YF0GCc+EL9h1Hwjsb3gFpN07Vxy9pgdgxfG1ghUgn8ENbbsBGUfuFsjl?=
 =?us-ascii?Q?R3YKO1zziwiK7PuqAnDsI1ybF5xlfnGLAgeCkKP4Uh5KJKp+WRdfJPWub4ab?=
 =?us-ascii?Q?Ikl2amTrP7igYbeE/dX1pDDeBMr2e4iWSzSBXEr/piIwBxNPO9+VnJGXXffz?=
 =?us-ascii?Q?frP2zuGPDrq5wYFnnfiBPgMRTLSlOCHkvxoswxKIDGf2TAmdiuKK51IpOmmk?=
 =?us-ascii?Q?ONHu8sKYB07xv2GGXaDhHglyLaJZ3VkYAPnH?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:03.1589
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c6b828ef-62d5-4e73-9dec-08ddf03d1d54
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9544

In order to fix CI error of a randconfig picking both PV_SHIM_EXCLUSIVE=y and
HVM=y results in hvm.c being built, but domctl.c not being built, which leaves
a few functions, like domctl_lock_acquire/release() undefined, causing linking
to fail.
To fix that, we intend to move domctl.o out of the PV_SHIM_EXCLUSIVE Makefile
/hypercall-defs section, with this adjustment, we also need to release
redundant vnuma_destroy() stub definition from PV_SHIM_EXCLUSIVE guardian,
to not break compilation
Above change will leave dead code in the shim binary temporarily and will be
fixed with the introduction of "wrap domctl-op with CONFIG_MGMT_HYPERCALLS".

Fixes: 568f806cba4c ("xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"")
Reported-by: Jan Beulich 
Signed-off-by: Penny Zheng 
---
v1 -> v2:
- remove paging_domctl hypercall-defs
---
 xen/arch/x86/Makefile        | 2 +-
 xen/common/Makefile          | 5 +----
 xen/include/hypercall-defs.c | 4 +---
 xen/include/xen/domain.h     | 4 ----
 4 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d7aed7d92c..84a83839d6 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -28,6 +28,7 @@ obj-y += delay.o
 obj-y += desc.o
 obj-bin-y += dmi_scan.init.o
 obj-y += domain.o
+obj-y += domctl.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain_page.o
 obj-y += e820.o
@@ -79,7 +80,6 @@ obj-y += vm_event.o
 obj-y += xstate.o
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
-obj-y += domctl.o
 obj-y += platform_hypercall.o
 obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
 endif
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 0c7d0f5d46..be442a3e47 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
 obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
+obj-y += domctl.o
 obj-y += domid.o
 obj-y += event_2l.o
 obj-y += event_channel.o
@@ -70,10 +71,6 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo un
 
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o)
 
-ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
-obj-y += domctl.o
-endif
-
 extra-y := symbols-dummy.o
 
 obj-$(CONFIG_COVERAGE) += coverage/
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 8370b4b289..221dc25f6f 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -200,8 +200,8 @@ sysctl(xen_sysctl_t *u_sysctl)
 #if defined(CONFIG_X86) && defined(CONFIG_PAGING)
 paging_domctl_cont(xen_domctl_t *u_domctl)
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 domctl(xen_domctl_t *u_domctl)
+#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 platform_op(xen_platform_op_t *u_xenpf_op)
 #endif
 #ifdef CONFIG_HVM
@@ -280,9 +280,7 @@ hvm_op                             do       do       do       do       do
 #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
 kexec_op                           compat   do       -        -        -
 #endif
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 8aab05ae93..11d2505420 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -185,11 +185,7 @@ struct vnuma_info {
     struct xen_vmemrange *vmemrange;
 };
 
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 void vnuma_destroy(struct vnuma_info *vnuma);
-#else
-static inline void vnuma_destroy(struct vnuma_info *vnuma) { ASSERT(!vnuma); }
-#endif
 
 extern bool vmtrace_available;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117579.1463666 (Exim 4.92)
	(envelope-from )
	id 1uwFQN-0006ej-So; Wed, 10 Sep 2025 07:39:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117579.1463666; Wed, 10 Sep 2025 07:39: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 1uwFQN-0006ec-Nn; Wed, 10 Sep 2025 07:39:27 +0000
Received: by outflank-mailman (input) for mailman id 1117579;
 Wed, 10 Sep 2025 07:39: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 1uwFQL-0005yo-Gz
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:25 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:2418::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4471cef5-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:23 +0200 (CEST)
Received: from BYAPR11CA0044.namprd11.prod.outlook.com (2603:10b6:a03:80::21)
 by PH7PR12MB5853.namprd12.prod.outlook.com (2603:10b6:510:1d4::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:16 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::1b) by BYAPR11CA0044.outlook.office365.com
 (2603:10b6:a03:80::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:16 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:15 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:00 -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: 4471cef5-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TDn/iPtAeFk2eolpwvEXxyGtiRb0z1Up5i+4L5Iv461Mx1yVqktEfmsOcLs3/dcG7EUp3vDL9HDm71a3hT+FSAR2JheFQKUoMb4j2VXxNSkr+Gd8M8+mIL+GZbe+niug3yfLC/xs45dGZ9loL3d78CZNhVdejG77eNmRNH6eJweOIGTUncFu2s2PO6kQMclnmw9dGn0apW9IOSa/aq387YrDmR7lAVTUeit9IhuV4FtwCPFIgwzhjf+LGeaR8lCuikRNWZZX0mDknD5q3Ka5eEW4Soe+cEoTOKoq6n8oUE/uJWQKEj7kVfY5w+LCTin98slKA4eoPpCd8X2nGvJNoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mmjjRmwBMN19DHx48HzdXSUmgXoB7lWnLJIzlZkESg8=;
 b=owPkcO50ToyKBWkA+ee4VT74Hz03nbvo3Zdeksogb3b7OLq89y3fyabihHo1Quf4Zbgw1MAhFEmMAFiz+N/7Jfrb2PurOF9JQ+4YykEAHH0nXzhjH4bLZpBNYnUom92vAnCWVico9Zbbijia7XvhvPLsNrZox2mkDnux33nldVwugvFc22qcf9W0t0tFFCjdt82ycrUZy6sSO9Pi5vKxOdqYQZ7kMTaF2eAH4U9+lR8bL+SWIPep2LQDp3MCARjLEdAf9/pCzM5rit+iizLMFpTEOjVcejjg6fYNPKOfGu65mHjCkmwr7zz/Wc7ZQ1d9aj5oNO/5BIYphcoVL7zGyA==
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=mmjjRmwBMN19DHx48HzdXSUmgXoB7lWnLJIzlZkESg8=;
 b=SasBvWLOY5+BxXYlgiMYoP5TsMw3F89UZgdfFIEvVJuirpYSDcF5H1aWIamjjiFX3Y6O+EHeCltLiGhPYGj25fY2TF/S44+E/hjzFrL1PLpWrOa9h1aIcd7sRKf+HX/y24+5RbPvN/Qe/vQognVj9XAS72dZjKBd2Rq1S1rNEeM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Alistair Francis ,
	Bob Eshleman , Connor Davis ,
	Oleksii Kurochko , Nathan Studer
	, Stewart Hildebrand , "Dario
 Faggioli" , Juergen Gross , George
 Dunlap , "Daniel P. Smith" 
Subject: [PATCH v2 02/26] xen/sysctl: replace CONFIG_SYSCTL with CONFIG_MGMT_DOMCTL
Date: Wed, 10 Sep 2025 15:38:03 +0800
Message-ID: <20250910073827.3622177-3-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|PH7PR12MB5853:EE_
X-MS-Office365-Filtering-Correlation-Id: 6c366754-861e-47f8-4b00-08ddf03d2493
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?SDCwXseAW7duwi/8yuHhOmmJmXQY/CMRvCfTRXmjsJEJbPaHkq6wN+/50URe?=
 =?us-ascii?Q?RXbuNSmsZv2EkHrky+zxgsnALCFtaR8hvkIBO67W+fHcOxIp1lY9HjJ6QfTk?=
 =?us-ascii?Q?t4MReTCWl0jPbMnrrRaIYsWu6J2YyMchlBtGVOvHBdQJVCzZ04r4oFTImAuZ?=
 =?us-ascii?Q?OBhiOBoyyaCxbJ1X3Bup2WRTMrSO+PXGvR9xQauAnFG2GwiUxVs5ebhcTk15?=
 =?us-ascii?Q?q+DEL0Z0KFTRlQ28uIkrIJX0MZmVY4hW4e6pAHHn3P2flm2uRjFweEG3V+gb?=
 =?us-ascii?Q?ZxdyGtodZ8QH97lOL/gGeBc33+qZamSVpr5csxFrBBlwMiVlQtY8QLNT+G0f?=
 =?us-ascii?Q?fowg2B9vfMhDp81/dpYp9Yv1Yeaxh/TpYYvamenGsS71McLLPNb/ttFZClE0?=
 =?us-ascii?Q?I+LUgatxYBclP2Kv2v+DFWUCMtGfB5RboYa7X+LODoTtfFugVpiaWZR8UIKZ?=
 =?us-ascii?Q?jM6ksgXZP5eekd4hrifEjba5n/JHgW8np/MdMu6LjRVRY2FmUpTM+erCVnCv?=
 =?us-ascii?Q?Q7JfTsT8x48AQUGOVo+fz/bEOnqRMIqdkmyPQSwxxMTehyCn/n69zw2VYe5U?=
 =?us-ascii?Q?55jU4PJjTj6QdzOOv8pWXTQoQdP3oml0b7f2G5qj166TesSAHDgXsdeLS2Nw?=
 =?us-ascii?Q?S1CqYH4n8jamPHPH2ghtS57WdQienXODk7Aa9gwycObqX/UOuptL5cKaxbna?=
 =?us-ascii?Q?t8m+wGsJzRxbYVAQoEBQ79ujyYBcmkMk5UQQbU3rSyAEDIPiB16hQeV3iHvi?=
 =?us-ascii?Q?7iAR8ImMctE9j58DrVAIyKZRTGbepRYuBI1Q39vrUII3TYv94+bpV2kpXqyZ?=
 =?us-ascii?Q?Xq1WOsdgHaOT77/MunC8nCh69wxsfseloE8K9Lhex4fYYC77vzoRub7gye02?=
 =?us-ascii?Q?lhzLOEGS+5XJyYSqiqyjTg+7OJx1sniD6PWQYAPBzeb+qmwliV37x3gJVRUV?=
 =?us-ascii?Q?cAbj0O9QouXCyylZF0VdgGG3jkCLNq+eHZukt+JX0AqixvgU7o/G+4aD/xgo?=
 =?us-ascii?Q?lU5yXA8r4yUQTIlrzj8sInxgSn3WBjXzPnyXDR2Ei/4If2y04LFpxZba0Hro?=
 =?us-ascii?Q?+WepfyLX3XpICnGj7MogfC01DZhD5f5OgIM6uzTvNAbAtdz5P2NSg3qWCDuJ?=
 =?us-ascii?Q?tILGGIRYtiXder4Rrt8k6QXkVs0aoMl+/2JYlymeG+pZelR4R8+0BexYeOfc?=
 =?us-ascii?Q?OGIH2JDwGLDS38nHwFz6iG7FyZrRLQCRS8V/WE2pJI6DUB4zKroz2VsHb4FF?=
 =?us-ascii?Q?s7ly0VfioUP/4/oeT4ScIqSOAFgjPPX3TeuaJXoP+ODMOPIwyN8SKhVNia1R?=
 =?us-ascii?Q?uPjCP0xk/PCNi7k7VYbUy1KR4ti60lDEliHe/MPL94leRN5PsQ1rWc/0o1Z3?=
 =?us-ascii?Q?6XC8zaD1nEq6Qmrd6VnJYEFnw/5Wbe0S7CGkNY8Xy8PNL6Y5Ie0tfUVyHZmc?=
 =?us-ascii?Q?N8ZRZj8eahSeG/lHJibOIvaIn7gS5BnCrxIamf+wcgQsg3XBQiqhNke3Pi07?=
 =?us-ascii?Q?e31ZQsM0jCSoudM1506izVZCZ3KRmHJp4vaj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:39:15.3094
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c366754-861e-47f8-4b00-08ddf03d2493
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5853

Rename all the CONFIG_SYSCTL into a single CONFIG_MGMT_HYPERCALLS to help
provide a single option to manage all unnecessary hypercalls, including
sysctl, domctl, etc, in dom0less system and PV shim mode, which could also
make it easier to support randconfigs.

Suggested-by: Stefano Stabellini 
Signed-off-by: Penny Zheng 
---
v1 -> v2:
- new commit
---
 xen/Kconfig.debug                     |  2 +-
 xen/arch/arm/Makefile                 |  2 +-
 xen/arch/riscv/stubs.c                |  4 ++--
 xen/arch/x86/Makefile                 |  2 +-
 xen/arch/x86/configs/pvshim_defconfig |  2 +-
 xen/arch/x86/psr.c                    | 26 +++++++++++++-------------
 xen/common/Kconfig                    | 20 ++++++++------------
 xen/common/Makefile                   |  2 +-
 xen/common/page_alloc.c               |  8 ++++----
 xen/common/perfc.c                    |  4 ++--
 xen/common/sched/arinc653.c           | 10 +++++-----
 xen/common/sched/core.c               |  6 +++---
 xen/common/sched/cpupool.c            | 16 ++++++++--------
 xen/common/sched/credit.c             |  6 +++---
 xen/common/sched/credit2.c            |  6 +++---
 xen/common/sched/private.h            |  4 ++--
 xen/common/spinlock.c                 |  4 ++--
 xen/drivers/char/console.c            |  4 ++--
 xen/include/hypercall-defs.c          |  4 ++--
 xen/include/xsm/xsm.h                 | 12 ++++++------
 xen/xsm/dummy.c                       |  6 +++---
 xen/xsm/flask/hooks.c                 | 22 +++++++++++-----------
 22 files changed, 84 insertions(+), 88 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d900d926c5..a69615cd63 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -37,7 +37,7 @@ config SELF_TESTS
 
 config COVERAGE
 	bool "Code coverage support"
-	depends on SYSCTL && !LIVEPATCH
+	depends on MGMT_HYPERCALLS && !LIVEPATCH
 	select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS if !ENFORCE_UNIQUE_SYMBOLS
 	help
 	  Enable code coverage support.
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7e88ddd3d7..2aff1a1630 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-$(CONFIG_SYSCTL) += sysctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 1a8c86cd8d..a74e56843c 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -282,7 +282,7 @@ unsigned long raw_copy_from_guest(void *to, const void __user *from,
     BUG_ON("unimplemented");
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* sysctl.c */
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
@@ -295,7 +295,7 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     BUG_ON("unimplemented");
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* p2m.c */
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 84a83839d6..a9fdba0b4c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -67,7 +67,7 @@ obj-y += smpboot.o
 obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
-obj-$(CONFIG_SYSCTL) += sysctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += sysctl.o
 obj-y += time.o
 obj-y += traps-setup.o
 obj-y += traps.o
diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig
index 24f4e4857d..d1db94df78 100644
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -25,4 +25,4 @@ CONFIG_PDX_NONE=y
 # CONFIG_INTEL_IOMMU is not set
 # CONFIG_DEBUG is not set
 # CONFIG_GDBSX is not set
-# CONFIG_SYSCTL is not set
+# CONFIG_MGMT_HYPERCALLS is not set
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index cce7020868..80ce5804b4 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -135,7 +135,7 @@ static const struct feat_props {
      */
     enum psr_type alt_type;
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     /* 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);
@@ -422,7 +422,7 @@ static bool mba_init_feature(const struct cpuid_leaf *regs,
     return true;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static bool cf_check cat_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
 {
@@ -435,7 +435,7 @@ static bool cf_check cat_get_feat_info(
 
     return true;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* L3 CAT props */
 static void cf_check l3_cat_write_msr(
@@ -448,14 +448,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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = cat_get_feat_info,
 #endif
     .write_msr = l3_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* L3 CDP props */
 static bool cf_check l3_cdp_get_feat_info(
     const struct feat_node *feat, uint32_t data[], uint32_t array_len)
@@ -467,7 +467,7 @@ static bool cf_check l3_cdp_get_feat_info(
 
     return true;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check l3_cdp_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -483,7 +483,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = l3_cdp_get_feat_info,
 #endif
     .write_msr = l3_cdp_write_msr,
@@ -501,14 +501,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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = cat_get_feat_info,
 #endif
     .write_msr = l2_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* MBA props */
 static bool cf_check mba_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
@@ -523,7 +523,7 @@ static bool cf_check mba_get_feat_info(
 
     return true;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check mba_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -561,7 +561,7 @@ static const struct feat_props mba_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_MBA_THRTL,
     .alt_type = PSR_TYPE_UNKNOWN,
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = mba_get_feat_info,
 #endif
     .write_msr = mba_write_msr,
@@ -826,7 +826,7 @@ static struct psr_socket_info *get_socket_info(unsigned int socket)
     return socket_info + socket;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 int psr_get_info(unsigned int socket, enum psr_type type,
                  uint32_t data[], unsigned int array_len)
 {
@@ -858,7 +858,7 @@ int psr_get_info(unsigned int socket, enum psr_type type,
 
     return -EINVAL;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int psr_get_val(struct domain *d, unsigned int socket,
                 uint32_t *val, enum psr_type type)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 76f9ce705f..c1571377d3 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -508,7 +508,7 @@ config CRYPTO
 config LIVEPATCH
 	bool "Live patching support"
 	default X86
-	depends on "$(XEN_HAS_BUILD_ID)" = "y" && SYSCTL && HAS_VMAP
+	depends on "$(XEN_HAS_BUILD_ID)" = "y" && MGMT_HYPERCALLS && HAS_VMAP
 	select CC_SPLIT_SECTIONS
 	help
 	  Allows a running Xen hypervisor to be dynamically patched using
@@ -600,7 +600,7 @@ config DTB_FILE
 config TRACEBUFFER
 	bool "Enable tracing infrastructure" if EXPERT
 	default y
-	depends on SYSCTL
+	depends on MGMT_HYPERCALLS
 	help
 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
 	  This will allow live information about Xen's execution and performance
@@ -648,21 +648,17 @@ config SYSTEM_SUSPEND
 
 	  If unsure, say N.
 
-menu "Supported hypercall interfaces"
-	visible if EXPERT
-
-config SYSCTL
-	bool "Enable sysctl hypercall"
+config MGMT_HYPERCALLS
+	bool "Enable hypercalls under management"
 	default y
 	help
 	  This option shall only be disabled on some dom0less systems, or
-	  PV shim on x86, to reduce Xen footprint.
-
-endmenu
+	  PV shim on x86, to reduce Xen footprint via managing unnessary
+	  hypercalls, like sysctl, etc.
 
 config PM_OP
 	bool "Enable Performance Management Operation"
-	depends on ACPI && HAS_CPUFREQ && SYSCTL
+	depends on ACPI && HAS_CPUFREQ && MGMT_HYPERCALLS
 	default y
 	help
 	  This option shall enable userspace performance management control
@@ -670,7 +666,7 @@ config PM_OP
 
 config PM_STATS
 	bool "Enable Performance Management Statistics"
-	depends on ACPI && HAS_CPUFREQ && SYSCTL
+	depends on ACPI && HAS_CPUFREQ && MGMT_HYPERCALLS
 	default y
 	help
 	  Enable collection of performance management statistics to aid in
diff --git a/xen/common/Makefile b/xen/common/Makefile
index be442a3e47..fdf826f218 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -52,7 +52,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-$(CONFIG_MGMT_HYPERCALLS) += sysctl.o
 obj-y += tasklet.o
 obj-y += time.o
 obj-y += timer.o
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1f67b88a89..26615d1e97 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -602,7 +602,7 @@ out:
     return ret;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
 {
     spin_lock(&heap_lock);
@@ -610,7 +610,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 */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static bool __read_mostly first_node_initialised;
 #ifndef CONFIG_SEPARATE_XENHEAP
@@ -1788,7 +1788,7 @@ int offline_page(mfn_t mfn, int broken, uint32_t *status)
     return 0;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * Online the memory.
  *   The caller should make sure end_pfn <= max_page,
@@ -1873,7 +1873,7 @@ int query_page_offline(mfn_t mfn, uint32_t *status)
 
     return 0;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * This function should only be called with valid pages from the same NUMA
diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 0f3b89af2c..97a94ef1fc 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -149,7 +149,7 @@ void cf_check perfc_reset(unsigned char key)
     }
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static struct xen_sysctl_perfc_desc perfc_d[NR_PERFCTRS];
 static xen_sysctl_perfc_val_t *perfc_vals;
 static unsigned int      perfc_nbr_vals;
@@ -266,7 +266,7 @@ int perfc_control(struct xen_sysctl_perfc_op *pc)
 
     return rc;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 8a4f4259d8..7d6c40d800 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -220,7 +220,7 @@ static void update_schedule_units(const struct scheduler *ops)
                       SCHED_PRIV(ops)->schedule[i].unit_id);
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /**
  * This function is called by the adjust_global scheduler hook to put
  * in place a new ARINC653 schedule.
@@ -335,7 +335,7 @@ arinc653_sched_get(
 
     return 0;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /**************************************************************************
  * Scheduler callback functions                                           *
@@ -661,7 +661,7 @@ a653_switch_sched(struct scheduler *new_ops, unsigned int cpu,
     return &sr->_lock;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /**
  * 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
@@ -701,7 +701,7 @@ a653sched_adjust_global(const struct scheduler *ops,
 
     return rc;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /**
  * This structure defines our scheduler for Xen.
@@ -736,7 +736,7 @@ static const struct scheduler sched_arinc653_def = {
     .switch_sched   = a653_switch_sched,
 
     .adjust         = NULL,
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     .adjust_global  = a653sched_adjust_global,
 #endif
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 2ab4313517..a0faddcb92 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2068,7 +2068,7 @@ long do_set_timer_op(s_time_t timeout)
     return 0;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* scheduler_id - fetch ID of current scheduler */
 int scheduler_id(void)
 {
@@ -2111,7 +2111,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
     return ret;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 {
     struct cpupool *pool;
@@ -2140,7 +2140,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 
     return rc;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void vcpu_periodic_timer_work_locked(struct vcpu *v)
 {
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index f5459c2779..51ba3cb43d 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -241,12 +241,12 @@ struct cpupool *cpupool_get_by_id(unsigned int poolid)
     return __cpupool_get_by_id(poolid, true);
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static struct cpupool *cpupool_get_next_by_id(unsigned int poolid)
 {
     return __cpupool_get_by_id(poolid, false);
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void cpupool_put(struct cpupool *pool)
 {
@@ -354,7 +354,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
 
     return ERR_PTR(ret);
 }
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * destroys the given cpupool
  * returns 0 on success, 1 else
@@ -382,7 +382,7 @@ static int cpupool_destroy(struct cpupool *c)
     debugtrace_printk("cpupool_destroy(pool=%u)\n", c->cpupool_id);
     return 0;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Move domain to another cpupool
@@ -572,7 +572,7 @@ static int cpupool_unassign_cpu_start(struct cpupool *c, unsigned int cpu)
     return ret;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static long cf_check cpupool_unassign_cpu_helper(void *info)
 {
     struct cpupool *c = info;
@@ -638,7 +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 */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * add a new domain to a cpupool
@@ -816,7 +816,7 @@ static void cpupool_cpu_remove_forced(unsigned int cpu)
     rcu_read_unlock(&sched_res_rculock);
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * do cpupool related sysctl operations
  */
@@ -982,7 +982,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
 
     return ret;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 unsigned int cpupool_get_id(const struct domain *d)
 {
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 6dcf6b2c8b..0cbec2a9c0 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -1256,7 +1256,7 @@ __csched_set_tslice(struct csched_private *prv, unsigned int timeslice_ms)
     prv->credit = prv->credits_per_tslice * prv->ncpus;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check
 csched_sys_cntl(const struct scheduler *ops,
                         struct xen_sysctl_scheduler_op *sc)
@@ -1299,7 +1299,7 @@ csched_sys_cntl(const struct scheduler *ops,
     out:
     return rc;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void *cf_check
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
@@ -2290,7 +2290,7 @@ static const struct scheduler sched_credit_def = {
 
     .adjust         = csched_dom_cntl,
     .adjust_affinity= csched_aff_cntl,
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     .adjust_global  = csched_sys_cntl,
 #endif
 
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 75316d42b7..307e63ebd8 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3131,7 +3131,7 @@ csched2_aff_cntl(const struct scheduler *ops, struct sched_unit *unit,
         __clear_bit(__CSFLAG_pinned, &svc->flags);
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check csched2_sys_cntl(
     const struct scheduler *ops, struct xen_sysctl_scheduler_op *sc)
 {
@@ -3163,7 +3163,7 @@ static int cf_check csched2_sys_cntl(
 
     return 0;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void *cf_check
 csched2_alloc_domdata(const struct scheduler *ops, struct domain *dom)
@@ -4248,7 +4248,7 @@ static const struct scheduler sched_credit2_def = {
 
     .adjust         = csched2_dom_cntl,
     .adjust_affinity= csched2_aff_cntl,
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     .adjust_global  = csched2_sys_cntl,
 #endif
 
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index d6884550cd..b7ff67200b 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -356,7 +356,7 @@ struct scheduler {
                                     struct sched_unit *unit,
                                     const struct cpumask *hard,
                                     const struct cpumask *soft);
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     int          (*adjust_global)  (const struct scheduler *ops,
                                     struct xen_sysctl_scheduler_op *sc);
 #endif
@@ -512,7 +512,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 0389293b09..9d08159615 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -690,7 +690,7 @@ void cf_check spinlock_profile_reset(unsigned char key)
     spinlock_profile_iterate(spinlock_profile_reset_elem, NULL);
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 typedef struct {
     struct xen_sysctl_lockprof_op *pc;
     int                      rc;
@@ -750,7 +750,7 @@ int spinlock_profile_control(struct xen_sysctl_lockprof_op *pc)
 
     return rc;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9bd5b4825d..c38b58d5fc 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -371,7 +371,7 @@ static void conring_puts(const char *str, size_t len)
         conringc = conringp - conring_size;
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 long read_console_ring(struct xen_sysctl_readconsole *op)
 {
     XEN_GUEST_HANDLE_PARAM(char) str;
@@ -414,7 +414,7 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 
     return 0;
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 
 /*
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 221dc25f6f..cd2c801af6 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -194,7 +194,7 @@ 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
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 sysctl(xen_sysctl_t *u_sysctl)
 #endif
 #if defined(CONFIG_X86) && defined(CONFIG_PAGING)
@@ -277,7 +277,7 @@ physdev_op                         compat   do       hvm      hvm      do_arm
 #ifdef CONFIG_HVM
 hvm_op                             do       do       do       do       do
 #endif
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 sysctl                             do       do       do       do       do
 #endif
 domctl                             do       do       do       do       do
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 9a23d2827c..3c960ad909 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -57,7 +57,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*sysctl_scheduler_op)(int op);
 #endif
     int (*set_target)(struct domain *d, struct domain *e);
@@ -140,7 +140,7 @@ struct xsm_ops {
     int (*resource_setup_gsi)(int gsi);
     int (*resource_setup_misc)(void);
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*page_offline)(uint32_t cmd);
 #endif
     int (*hypfs_op)(void);
@@ -246,7 +246,7 @@ static inline int xsm_domctl_scheduler_op(
     return alternative_call(xsm_ops.domctl_scheduler_op, d, cmd);
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 {
     return alternative_call(xsm_ops.sysctl_scheduler_op, cmd);
@@ -267,7 +267,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.sysctl, cmd);
 #else
     return -EOPNOTSUPP;
@@ -276,7 +276,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.readconsole, clear);
 #else
     return -EOPNOTSUPP;
@@ -603,7 +603,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.page_offline, cmd);
 #else
     return -EOPNOTSUPP;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8b7e01b506..f5483e0709 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -19,12 +19,12 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
 #endif
     .set_target                    = xsm_set_target,
     .domctl                        = xsm_domctl,
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl                        = xsm_sysctl,
     .readconsole                   = xsm_readconsole,
 #endif
@@ -98,7 +98,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .page_offline                  = xsm_page_offline,
 #endif
     .hypfs_op                      = xsm_hypfs_op,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index b0308e1b26..21914d3507 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -626,7 +626,7 @@ static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
     }
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_sysctl_scheduler_op(int op)
 {
     switch ( op )
@@ -641,7 +641,7 @@ static int cf_check flask_sysctl_scheduler_op(int op)
         return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check flask_set_target(struct domain *d, struct domain *t)
 {
@@ -858,7 +858,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     }
 }
 
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_sysctl(int cmd)
 {
     switch ( cmd )
@@ -946,7 +946,7 @@ static int cf_check flask_readconsole(uint32_t clear)
 
     return domain_has_xen(current->domain, perms);
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static inline uint32_t resource_to_perm(uint8_t access)
 {
@@ -1208,12 +1208,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
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int flask_resource_use_core(void)
 {
     return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check flask_resource_plug_pci(uint32_t machine_bdf)
 {
@@ -1278,7 +1278,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
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int cf_check flask_page_offline(uint32_t cmd)
 {
     switch ( cmd )
@@ -1293,7 +1293,7 @@ static inline int cf_check flask_page_offline(uint32_t cmd)
         return avc_unknown_permission("page_offline", cmd);
     }
 }
-#endif /* CONFIG_SYSCTL */
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static inline int cf_check flask_hypfs_op(void)
 {
@@ -1889,12 +1889,12 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
 #endif
     .set_target = flask_set_target,
     .domctl = flask_domctl,
-#ifdef CONFIG_SYSCTL
+#ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl = flask_sysctl,
     .readconsole = flask_readconsole,
 #endif
@@ -1956,7 +1956,7 @@ 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
+#ifdef CONFIG_MGMT_HYPERCALLS
     .page_offline = flask_page_offline,
 #endif
     .hypfs_op = flask_hypfs_op,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117581.1463671 (Exim 4.92)
	(envelope-from )
	id 1uwFQO-0006lz-9E; Wed, 10 Sep 2025 07:39:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117581.1463671; Wed, 10 Sep 2025 07:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFQO-0006kU-4u; Wed, 10 Sep 2025 07:39:28 +0000
Received: by outflank-mailman (input) for mailman id 1117581;
 Wed, 10 Sep 2025 07:39: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 1uwFQM-0005yt-Pg
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:26 +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 4607fd1a-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:26 +0200 (CEST)
Received: from BYAPR11CA0071.namprd11.prod.outlook.com (2603:10b6:a03:80::48)
 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.9094.22; Wed, 10 Sep
 2025 07:39:20 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::74) by BYAPR11CA0071.outlook.office365.com
 (2603:10b6:a03:80::48) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:20 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:20 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:06 -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: 4607fd1a-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Mjakr2j0FrYplPnrulqwzwuXuvkjlkBExnLjCcW4ccRE4Ql/L3oFKgBjeokP21Zqib8mTHfbfbWmlSpK9IRjAv8Dq+XfiyB8kkztBg7wGxD1cKfJQIlo3+ZbbHd0XlILD/PIyWsEIxOdKdKbgC3I0kVBv2apBwO5C52c2RRioU18BD8Q7vxHzUczyaSECOgvvF1XjusldkpSJBs6qrmAo0qa+PNu9mQ3kd3ogmLSCKxmq/HPzaqIVT6Wo6oTYz22Y9AYzkKxXClqFkJwAHgmcYP5D7IvMMRtkJkxfYtOWzsMBugtjlF6ZgaHQ2Wlu7hC28MAgCW2UVfbBI06Q3mUrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=laR1vIy8iDHUWom8KybMGHOL/51jt2m++lMgJI0rWmk=;
 b=Flo1PdL1k0Zr8Re+0tukVLpCsWjdCUKek4UhJ+yVpX4JigoA0aNxBSNd0LZH33U0IOKFdEejix1QUxHPpp7h1pQuctgk17LzOO5wC7kUuHAbK8kbNjvkVu6PP2DF2zn/fNSnX8YuNYYUN+XJDg8+Z/fv6ncqzOL9eikOfBvC+Td6NYzKmAMaRTdiGqhIbCzbFj3Ki5HxpxXlSjljzaBrzvLE6ESwFpziF+0nOMtn4FoSwNpKBkTB2F4m8BcOVmKVnaRd1kMzA0KK+06TA3n5Czphf8zAyR0BZCdqs/jsQySxHLr8P8yoJjox/WWzJneIIUaqfr21VUL00ic9RLqFZQ==
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=laR1vIy8iDHUWom8KybMGHOL/51jt2m++lMgJI0rWmk=;
 b=bW+yGkmDU+O44/PVx9RF5wfQueUWOIOjO0NHU6oF1QCvLu3aZlvOhBiAOVz4fkKoi639KImjZ/Ss4ZhnWw81ssaCCxg9wYopmpR9NPiUAQj1FBvxCtwGCgB5HeZf/depPEc08SeR2IB9xmTptwt5yh35cKZB+kkSJkAUUAoG35E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
Date: Wed, 10 Sep 2025 15:38:04 +0800
Message-ID: <20250910073827.3622177-4-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|CH3PR12MB7572:EE_
X-MS-Office365-Filtering-Correlation-Id: ff49e5f5-b7b2-46d7-6364-08ddf03d277d
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?24L5FvqOUUmcNC8p/i5aoWorGvWEoI2twO/8NTJci6MDVqgfnzN33kW1eqIA?=
 =?us-ascii?Q?efby8b1mQ1Rhm5rD4mf/u4Nm7DXPKSMdTm4UbEzaukS67+a0VpebhjStsLPA?=
 =?us-ascii?Q?N7VqVI8qrPsyRApSylJyx2zcQOxKQa2w7cQ88VKT+7UajKrqiYNqY7+OvTy7?=
 =?us-ascii?Q?+kCAMAH6HdEEq8TWXXcdBLyyP581G79rgm9YvCCa73TfY+c2B+mkwUFAhmtG?=
 =?us-ascii?Q?L98ure7P/aJAVqzdPYDhjCyq4Fk4kGWGbZTapFymPb/2iEaYpERgx4mRpjyY?=
 =?us-ascii?Q?QxufXPQYbVhNePjx3ELpzY7CvHZ2u0qzw9XhQ6v/pZWKEV3luswreUkpoFaf?=
 =?us-ascii?Q?Ic5zX9bdElt08Oe5kmKT1bgfy+2UXxo1BayBa524FlQq0SsA4g6akPwLdTC2?=
 =?us-ascii?Q?KLlLvRbYbGyPL+qsWChFp1lGOW009Xn/73Gq1sw8u3LSkhG+41z/Q4k0WbUx?=
 =?us-ascii?Q?EC6ItBT5VVJPNdJ4DK8WtZzlXmLBM/iXwhz+0kpFNrzvkYfKCgjvhDXw/wh1?=
 =?us-ascii?Q?QBhtNNq3dpoJFaUtmyDrUlZhPWkG2oHZTVBOkeZPG9hmF+i6teLGuHKJc/sP?=
 =?us-ascii?Q?fKX5YefpMJPEiXkV0WsF9KAW4iUT0fYyMOBzrQNdcsq8bnb/xaGZY9QOUd0B?=
 =?us-ascii?Q?DV208k4+KEHQuJ3McKCfQqil4sh3It9ovZbhQPeHy0iGE0m8KvTekujBH3Qx?=
 =?us-ascii?Q?RRueYCAVRqdtacua4eaMVRPsuL9oo02AiC05YQX3SVnwTo1w6rWTlqArOveA?=
 =?us-ascii?Q?PtDX+s4fcs+48Kbn0MP/6LTb5LQBzPe3PVxNXUSn4WhzgrYlp+k6QJdK7Aow?=
 =?us-ascii?Q?imw6+vy8mba7Zle9RKrfNEaYND5v9U8CLlvTqAr76mkyhOe8f7NIgAIYBFwf?=
 =?us-ascii?Q?leg/m7QPzHomfb/Hh/v+agyjYL2DEwxqfjbzH+gpku0982ZKSMOWYZNzPe2I?=
 =?us-ascii?Q?NixQFiUBW7fYRy6qZ+bZcCrwkqgbD24pinlO0d3P2nurR0aeyCbo7QYxSWCZ?=
 =?us-ascii?Q?hXS8bMHKJF0IXCm3gHpMTe9iGGboQWfidZQlBKFHmAXCaqft7aS4hpyAo2oB?=
 =?us-ascii?Q?YZEaWH6rkUwbAc2EzMbzClgT7/eU3mVMXnUrU3mBjzx/dYkuAxaEopbOaDUj?=
 =?us-ascii?Q?S+n2wDgXOD7AvNa2DqSxVL+aN5W8LCxWlfLnps2R33TgCb07mY0aLlr4Kj//?=
 =?us-ascii?Q?+CPVGO5NBqyfUmmH6JTUIczlnO7yv1qeUqAl4lkDQbGeKglGfyBPTdEKhUVJ?=
 =?us-ascii?Q?JJsZhwnjwvJsyY6TMnG/bwbq5fc/jGQcBq1wGadPx5x9WtAElEL+bSNNiJFP?=
 =?us-ascii?Q?++riAV1bKIfRTZDusJbaNuAzlVILmEOoKEAO8qtt2qQfNmJ1TwoFICkMW55Z?=
 =?us-ascii?Q?hh7OOtON9wxVxQ8bBYaYbfajGRvlh40+NUFpZKIGMaRMjPjW/H9c8gV3R0mJ?=
 =?us-ascii?Q?VPJZ9XYEE0tKqrYzrVzMMAG/CdkWBDy7mqiwDvTqmBmGbDOGzAtM8w3jY+wV?=
 =?us-ascii?Q?MOu/KJXBYKQiHIXrIP8WxyLoDQXvqDiQGSS6?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:39:20.2003
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ff49e5f5-b7b2-46d7-6364-08ddf03d277d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7572

Flag PG_log_dirty is for paging log dirty support, not vram tracking support.
However data structure sh_dirty_vram{} and function paging_log_dirty_range()
designed for vram tracking support, are guarded with PG_log_dirty.
We release both from PG_log_dirty, and also move paging_log_dirty_range(),
remamed with p2m_log_dirty_range(), into p2m.c, where it logically belongs.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- rename paging_log_dirty_range() into p2m_log_dirty_range(), and move it
to p2m.c, where it logically belongs
- remove #ifdef / #endif
- change int to unsigned int
---
 xen/arch/x86/include/asm/p2m.h    |  4 ++++
 xen/arch/x86/include/asm/paging.h | 32 +++++++++++++------------------
 xen/arch/x86/mm/hap/hap.c         |  4 ++--
 xen/arch/x86/mm/p2m.c             | 28 +++++++++++++++++++++++++++
 xen/arch/x86/mm/paging.c          | 32 -------------------------------
 5 files changed, 47 insertions(+), 53 deletions(-)

diff --git a/xen/arch/x86/include/asm/p2m.h b/xen/arch/x86/include/asm/p2m.h
index 3b860e30c3..1856cc396c 100644
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -1110,6 +1110,10 @@ static inline int p2m_entry_modify(struct p2m_domain *p2m, p2m_type_t nt,
 
 #endif /* CONFIG_HVM */
 
+/* get the dirty bitmap for a specific range of pfns */
+void p2m_log_dirty_range(struct domain *d, unsigned long begin_pfn,
+                         unsigned long nr, uint8_t *dirty_bitmap);
+
 #endif /* _XEN_ASM_X86_P2M_H */
 
 /*
diff --git a/xen/arch/x86/include/asm/paging.h b/xen/arch/x86/include/asm/paging.h
index 768b077ebd..1b0694bb36 100644
--- a/xen/arch/x86/include/asm/paging.h
+++ b/xen/arch/x86/include/asm/paging.h
@@ -133,13 +133,20 @@ struct paging_mode {
     (DIV_ROUND_UP(PADDR_BITS - PAGE_SHIFT - (PAGE_SHIFT + 3), \
                   PAGE_SHIFT - ilog2(sizeof(mfn_t))) + 1)
 
-#if PG_log_dirty
+#ifdef CONFIG_HVM
+/* VRAM dirty tracking support */
+struct sh_dirty_vram {
+    unsigned long begin_pfn;
+    unsigned long end_pfn;
+#ifdef CONFIG_SHADOW_PAGING
+    paddr_t *sl1ma;
+    uint8_t *dirty_bitmap;
+    s_time_t last_dirty;
+#endif
+};
+#endif
 
-/* get the dirty bitmap for a specific range of pfns */
-void paging_log_dirty_range(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            uint8_t *dirty_bitmap);
+#if PG_log_dirty
 
 /* log dirty initialization */
 void paging_log_dirty_init(struct domain *d, const struct log_dirty_ops *ops);
@@ -171,19 +178,6 @@ bool paging_mfn_is_dirty(const struct domain *d, mfn_t gmfn);
 #define L4_LOGDIRTY_IDX(pfn) ((pfn_x(pfn) >> (PAGE_SHIFT + 3 + PAGETABLE_ORDER * 2)) & \
                               (LOGDIRTY_NODE_ENTRIES-1))
 
-#ifdef CONFIG_HVM
-/* VRAM dirty tracking support */
-struct sh_dirty_vram {
-    unsigned long begin_pfn;
-    unsigned long end_pfn;
-#ifdef CONFIG_SHADOW_PAGING
-    paddr_t *sl1ma;
-    uint8_t *dirty_bitmap;
-    s_time_t last_dirty;
-#endif
-};
-#endif
-
 #else /* !PG_log_dirty */
 
 static inline void paging_log_dirty_init(struct domain *d,
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 4aec98109d..2f69ff9c7b 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -42,7 +42,7 @@
  * Create a dirty vram range on demand when some [begin_pfn:begin_pfn+nr] is
  * first encountered.
  * Collect the guest_dirty bitmask, a bit mask of the dirty vram pages, by
- * calling paging_log_dirty_range(), which interrogates each vram
+ * calling p2m_log_dirty_range(), which interrogates each vram
  * page's p2m type looking for pages that have been made writable.
  */
 
@@ -119,7 +119,7 @@ int hap_track_dirty_vram(struct domain *d,
             p2m_flush_hardware_cached_dirty(d);
 
             /* get the bitmap */
-            paging_log_dirty_range(d, begin_pfn, nr_frames, dirty_bitmap);
+            p2m_log_dirty_range(d, begin_pfn, nr_frames, dirty_bitmap);
 
             domain_unpause(d);
         }
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e802f2e4e6..e2a00a0efd 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2161,6 +2161,34 @@ int relinquish_p2m_mapping(struct domain *d)
     return rc;
 }
 
+void p2m_log_dirty_range(struct domain *d, unsigned long begin_pfn,
+                         unsigned long nr, uint8_t *dirty_bitmap)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    unsigned int i;
+    unsigned long pfn;
+
+    /*
+     * Set l1e entries of P2M table to be read-only.
+     *
+     * On first write, it page faults, its entry is changed to read-write,
+     * and on retry the write succeeds.
+     *
+     * We populate dirty_bitmap by looking for entries that have been
+     * switched to read-write.
+     */
+
+    p2m_lock(p2m);
+
+    for ( i = 0, pfn = begin_pfn; pfn < begin_pfn + nr; i++, pfn++ )
+        if ( !p2m_change_type_one(d, pfn, p2m_ram_rw, p2m_ram_logdirty) )
+            dirty_bitmap[i >> 3] |= (1 << (i & 7));
+
+    p2m_unlock(p2m);
+
+    guest_flush_tlb_mask(d, d->dirty_cpumask);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 3aafb0990b..65455a6867 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -583,38 +583,6 @@ static int paging_log_dirty_op(struct domain *d,
     return rv;
 }
 
-#ifdef CONFIG_HVM
-void paging_log_dirty_range(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           uint8_t *dirty_bitmap)
-{
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int i;
-    unsigned long pfn;
-
-    /*
-     * Set l1e entries of P2M table to be read-only.
-     *
-     * On first write, it page faults, its entry is changed to read-write,
-     * and on retry the write succeeds.
-     *
-     * We populate dirty_bitmap by looking for entries that have been
-     * switched to read-write.
-     */
-
-    p2m_lock(p2m);
-
-    for ( i = 0, pfn = begin_pfn; pfn < begin_pfn + nr; i++, pfn++ )
-        if ( !p2m_change_type_one(d, pfn, p2m_ram_rw, p2m_ram_logdirty) )
-            dirty_bitmap[i >> 3] |= (1 << (i & 7));
-
-    p2m_unlock(p2m);
-
-    guest_flush_tlb_mask(d, d->dirty_cpumask);
-}
-#endif
-
 /*
  * Callers must supply log_dirty_ops for the log dirty code to call. This
  * function usually is invoked when paging is enabled. Check shadow_enable()
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117586.1463685 (Exim 4.92)
	(envelope-from )
	id 1uwFQV-0007JD-IG; Wed, 10 Sep 2025 07:39:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117586.1463685; Wed, 10 Sep 2025 07:39: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 1uwFQV-0007Iw-EH; Wed, 10 Sep 2025 07:39:35 +0000
Received: by outflank-mailman (input) for mailman id 1117586;
 Wed, 10 Sep 2025 07:39: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 1uwFQU-0005yo-1J
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:34 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2416::61a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 49a78e28-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:32 +0200 (CEST)
Received: from BYAPR11CA0048.namprd11.prod.outlook.com (2603:10b6:a03:80::25)
 by SN7PR12MB8818.namprd12.prod.outlook.com (2603:10b6:806:34b::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:28 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::18) by BYAPR11CA0048.outlook.office365.com
 (2603:10b6:a03:80::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.23 via Frontend Transport; Wed,
 10 Sep 2025 07:39:27 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:27 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:10 -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: 49a78e28-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JrorcKgFR778dOLrJ3ol+bAKBo0iSROGYB+mxKgpOSb9AayDrMH1WbJvcVDZFEpJfycRjHJnjMppYDRVypDCKr4Xr/tG4mYKseAfb2cuwxi4XTV4k9WbP5FloxGNhhFVc0ds4SK5kwYiFlYqcx6JIBsXEExBzdhRvNHhqMzMPE0sMTafWf8w8aGO+dEjJjIzBNb8ZjIgaGkuiVxT2aD+d0+nTPIOwtCEUymp2AyqnpzgZ/9Zh7BDd9H3hn7KKrzQcuTiO4iSeHNOG0+kMYXwdKFves0kgQaP7g6j1/b4J7z9jhAtTtQI8Tncun42nrvWH/Tpwu7PewZ76U8ybO2RdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iCvTZoNSvyoMqZzxIQR/q/ai6c9ycQYKWaEiuV+fVAQ=;
 b=grPz6vCAPR9yTtltcUtjAquTuRWQ00Ol2vhrpKgMYNSCbOkKeVYvSS75H1q/bzg9sOAsaT1hhR3NmlqN9tyqdxPp7nSxoXVapus1p+Sy+9ro8wm4v/cUX5Jt4qwLGJ/k+A4JNJnC3NVNINBRSKtiyFVq58LT56etTCkxm+pWgyVAqUlhOK/Js90loNJIkEkmjWs4A+mF/XHv3/YLN6BQZ1I6x2QyHP8SxPEKNR6xl3f1GpZb2m+xujqT+iCTvVwW+tDs0iFMl3iQivdB59nia0NggtPPyiJtz/77z/kgWb2SJH4j/izsdsq68fISK2zC3TQzZwXcLzRG4dURAuckjw==
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=iCvTZoNSvyoMqZzxIQR/q/ai6c9ycQYKWaEiuV+fVAQ=;
 b=icQM2M3KvL69lpINYC5BGdkniBKJfJ8hdIJBYTODmdNZsdMdUWqUbbVUwFDccox0HyrnUB9FhtlujnromDnuMcARkX5vVor5JwLTYg3Ut8rK0lEdtXEZOeHe3p+bldAL4Pxdao0WWrkUs0JFn798TlqCxy5UIYKL96iGTzBV7rI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 05/26] xen/x86: make VM_EVENT depend on CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:06 +0800
Message-ID: <20250910073827.3622177-6-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|SN7PR12MB8818:EE_
X-MS-Office365-Filtering-Correlation-Id: a6bdd730-d856-4003-5e23-08ddf03d2c02
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?tkKWckCL/rzUqz5rahUPinHjfkjStkZThLscodxhVZ6Y6Apf1X2LeV6ygtSO?=
 =?us-ascii?Q?by/83KWX65qJfycm28Z766ZUUP017kLu9/5QXFWl36/GhHoVN1qbLMMOm3IO?=
 =?us-ascii?Q?o9xLDzPbr8SDjBFc1d/fAySbvzrrEXvAxAFneGhTZDonmk/OXx51JiDmd0fF?=
 =?us-ascii?Q?yJao8yQsZUOG0BqNY8Vtm384jphq9HFqeOPPoAdTn+VSh33aiXL7yThk8Joz?=
 =?us-ascii?Q?Xv5N/tCVteMdd1Ja4PR3Fm3N6Ld7nSG2kfUTg1GWuyRGI9iChuuxEnT2KYoj?=
 =?us-ascii?Q?G+pVKrtcUkYjGyFD2SYfacHLr1/EuBVdso3t2f1X+CXd01KGdkU4UYpypYeV?=
 =?us-ascii?Q?sfy72332UtkC4GG1Eya8/BeljiJv9lZKdS7jg13i3kPk4FQAzTcQBab8SaxN?=
 =?us-ascii?Q?es1vHPalmxgNz1Ebmnkj6B2sSC9lyU6wmGtTAb8tXrB+d/faf6/4/v0pdIyQ?=
 =?us-ascii?Q?DudmZ+gaKQ8KQdz/Rhdps3topvYAk3lJbCZwLs5CzNDfa2mqtVUlU6qCA9As?=
 =?us-ascii?Q?8HlYw6HW0M8EDm0CYgX9a9lTFyS4TvAW8PUX9o2+pjlXV3ou0ooZWKobeXKO?=
 =?us-ascii?Q?+bq3cVBuzaPg6WsOSDexNxvqWiQoWDnw/3n7kHnDkI4WV/tcof3Zja2fSyDX?=
 =?us-ascii?Q?U4T954vfMci3NuAe6XdWi9BESbUvrZqmlrcXOB7w2eoI4ojOSdoDME+iKl3a?=
 =?us-ascii?Q?cUCneZQ3K6ZmBwxoJJyNlgS6cAqHaUatcwksnhbqYaUf7aqsSv0sxovIams+?=
 =?us-ascii?Q?kVqMCBnkqgCyILKbNS96cMhkM8PI+pAAdtuelK6bnDtigpFEwHUWTJKEWjaJ?=
 =?us-ascii?Q?2DPtGYMt3gW7BqpSbmmF/XvvXjCcNMP17siBxlXFJBwUlfFvEuVjQOKnkp/X?=
 =?us-ascii?Q?TgKBD8nl1yQQLDivRM4fWcPJlIZqyQ79Lhm3ozJaPShgeHsg2Hp8FPkf6C13?=
 =?us-ascii?Q?bqgmfag2WaEk/R7fuqkPTIIKl50WqKI9wbHvWGcjGMkhJc8pmTHg3ZkZNHRu?=
 =?us-ascii?Q?gIBOTB16KdMXBzv8V8/r5JY0472tTC0PDnv52v6qAAXBypofG2Tq9GGbCyHI?=
 =?us-ascii?Q?Bo4DeNuanchrZrJK3W3lZzeU6C56iTW7b3VB+cxnmcLjbXrVasw5Zv093+pY?=
 =?us-ascii?Q?PHEhrQoi+SDHs08TjRuX/kp4xulaVEdI9tgHC+r69srq4PGpV5z0nKrMcxNo?=
 =?us-ascii?Q?AHhCwrPWxabeITtUKqWDlkfbvrcfS/KieUJ/1E2CxWl25nPwHzhbMBytOo8J?=
 =?us-ascii?Q?2b+GzIBV+y90GavPIugIDE4ftulkDJmtHoiaiZbJ/yppA0FAQpmrcqEM7IoO?=
 =?us-ascii?Q?ZD7YgMxvhKbxfJlTkYzB3Vp77Qlsnx3JtQokUDX/ioTJBbIM1qBwh6HtXRBt?=
 =?us-ascii?Q?kWXD8yMuDxcke3H3vFuN29VUwFZiHcjQUuW8pjAVYI100kSC0awwihhO4Spz?=
 =?us-ascii?Q?RIwultnzrnQ+Xzia2AFj9Zo6HctuvFbPINdfWUtyU6cyZt2gjosTxekfWyD2?=
 =?us-ascii?Q?LMRHvkRJedhoPL26Ow0wIboGHpThkJuPygN6?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:27.7824
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a6bdd730-d856-4003-5e23-08ddf03d2c02
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8818

VM event could only be enabled/disabled via vm_event domctl-op, so
CONFIG_VM_EVENT shall depend on CONFIG_MGMT_HYPERCALLS

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
 xen/common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index c1571377d3..1aedd00b12 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -176,7 +176,7 @@ config MEM_ACCESS_ALWAYS_ON
 config VM_EVENT
 	def_bool MEM_ACCESS_ALWAYS_ON
 	prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
-	depends on HVM
+	depends on HVM && MGMT_HYPERCALLS
 	help
 
 	  Framework to configure memory access types for guests and receive
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117588.1463696 (Exim 4.92)
	(envelope-from )
	id 1uwFQX-0007b4-Tc; Wed, 10 Sep 2025 07:39:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117588.1463696; Wed, 10 Sep 2025 07: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 1uwFQX-0007av-Oh; Wed, 10 Sep 2025 07:39:37 +0000
Received: by outflank-mailman (input) for mailman id 1117588;
 Wed, 10 Sep 2025 07: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 1uwFQV-0005yo-Te
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:36 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20611.outbound.protection.outlook.com
 [2a01:111:f403:2413::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ab49d7e-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:33 +0200 (CEST)
Received: from BYAPR11CA0037.namprd11.prod.outlook.com (2603:10b6:a03:80::14)
 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.9094.22; Wed, 10 Sep
 2025 07:39:26 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::1b) by BYAPR11CA0037.outlook.office365.com
 (2603:10b6:a03:80::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Wed,
 10 Sep 2025 07:39:25 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:25 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:08 -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: 4ab49d7e-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mwst07hOzSoOjY8LqjmHZsMCrhlPKwOYHMjxyg6D3g9+HnnFPK2GLFpCOfFYY1AkzZqmkLmn/WIlOhcWihAHEtjdNtiqUzrRs7it+YGK1gq9Du10FPFiU4FXc5I61Qu0tvee9Bua+5b+0CwRaapcN+t8PY+LXYcwe+LlttSpKfh45e6L2Zc+lOyvel41bLxUPEoMdOGwTS2anvt9KWK6Gfkbdym6MLerw+eDBULmY8Vpg0+Ih7nZ+LVM+aiWhIAs/7IBv+8S45EapsRYwE2tHWXs5sUst9HlwjP6LRmYETsGrG8ASH/0jsltyIXOU4Z8krMkCdOsZB14pxthOq/Uyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1SvkVjnTmPEwi4ioI5p5ke75eXA6MP3pWxYaqdIpCbw=;
 b=SXda7LQZUJWxv2MVgyvrjDp0RPSOiNm/aDnyJqJcB9CFF49qCltL9MkLcUNr9wfq6L6cduqDJBEYfV7UAa0RMvUww/qlZRdwN6WsrvRTGqU5yHYExqjkFmNjZ/EwtJNKLbIDdDWCZ29T2PfoL6LIA4wTZCCR0onyd0RZAZ4oN8Kj4IM7mN2cv7/SorFq8tMXx3u8lhdqI5oqynfmzQ3Rn3CtUGS4RWGn8no1Y4E+nKbssZ+yhIIaXNnb9JaR1uVw2q1UNG6Hxt6iCpjT4yAohNn9+Ed6Fer8q0L0EKbhnDIJ6XAGRqK57FNqg7DmcGHurSoXTV0hhozOJrKH7l+8pQ==
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=1SvkVjnTmPEwi4ioI5p5ke75eXA6MP3pWxYaqdIpCbw=;
 b=Hv6vHBQt8ZxKXzqMYC58SlC8nwsqfWekVozkqlJVoI/xdy7KMeXFAFyVNUPtojluFtpJ4MuzWNTX67K8/xG8BmzqnKz5BUdSgenxlgfvIZTfUxQRFbPlyrxP6/Jw8Pes2cOY70YDyJvj2VKw2eNAlfWOEF7lyMGjKzhdYqkvG/U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Tamas K Lengyel
	, Alexandru Isaila , "Petre
 Pircalabu" , "Daniel P. Smith"
	
Subject: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
Date: Wed, 10 Sep 2025 15:38:05 +0800
Message-ID: <20250910073827.3622177-5-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|MN2PR12MB4334:EE_
X-MS-Office365-Filtering-Correlation-Id: d1601738-a023-4573-46d1-08ddf03d2acc
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?QQ2HpMtvMBYBUaLk/jQa7TPxm4KLaUJcFoe8X+B0Uz0Bo5JZYYC5JMbg9MyL?=
 =?us-ascii?Q?/0hqNQryUt3lYyoyE+YcPZVmWlyMdbd6AVqwFxAhxcU2Bar17MfDDvGnr1UO?=
 =?us-ascii?Q?/exBwL1OtAxgkAw9tzMpiyYNaiqFMx+ZxOIkaN1hnIl3V9lFjybJKTs6Cepl?=
 =?us-ascii?Q?T2cGhUIy0VxJOLvfGUPxuudnGOkr9NhqbMnH9OiakmQDWubxI0sS1p1qwQ3V?=
 =?us-ascii?Q?RU8QwL2g5EqdteXumchsBkWTC8zh1dc1stBKSGsgghSgZBrs5sHxuHXrOYVj?=
 =?us-ascii?Q?LLHDJw8P+uvFA8MvJXw+HcGYIGOa4LvURxciJRJHhAKnR+X+l2Uuqoz0KeFv?=
 =?us-ascii?Q?dkxE8WVEFkdePLOHOTz5lQazbKX7m5eLMDd4cQFr3FDqVFZL9b49HOtBakMv?=
 =?us-ascii?Q?EMEDp1dJb7GT3B6kAgXgTJW9KKV+dplnQPXlYcuG0SV34r2h8eaSjcKZF29+?=
 =?us-ascii?Q?nP+OJXoZOLMJmUw+iFB/DoN5Mae7csTB5FUHDlYNJ5OcPzzV/3HiFE8XJXKI?=
 =?us-ascii?Q?ju+gGGXR92o2LTUpoF9c5mvgD1VOYgpogDgBpRX84aQOzp7lxDP0nlHK/fwf?=
 =?us-ascii?Q?iJBf9HML6sxOfFFv434SX9Ymik+M+9/eQ2JJZLBkUXXnDRlHjrtKOhG+kH2P?=
 =?us-ascii?Q?uVSRKKGqJeEO29LKUAnIiqxWF1FC2yMJeYPFU8x/+rmW9/SODi0ELcwqubit?=
 =?us-ascii?Q?K239oAy4FjSSz65oWeeGuReEBYWQRYKdPHMWf1zxk551OsfuYYbPzlpNx3iW?=
 =?us-ascii?Q?fq7DAmw7mFhLcQ2YbGKM2s/3uw1N0Fm2/fNCC9oOdF5G25Rz4Sil5YUCjXr7?=
 =?us-ascii?Q?PTIml2xv9JWTUpAHQ0zOvpEOk2QOn2V+Lwb2cg3aXjN+z/mlRdZ7ue8G+CER?=
 =?us-ascii?Q?qpdOaj5CATWLin+RvnBuTJXePrlGc4JQLvJmkJVW0n1+JSQZNcQ7ODjWyRLm?=
 =?us-ascii?Q?05TGnGJIaNI2JOpGKrzWVZWmztSMd4H1Ul+HHV7Jlki8HFtOLNJpomtkvwS5?=
 =?us-ascii?Q?xvYrRg/13YTE/wRiAyZjP2vTXRppVsNOMZKpF43G6xx1v405uCZUQNv9QxjE?=
 =?us-ascii?Q?Jntr+l3mGJXD7LvT9wx7W/I/+7pg0hgutF0f3Cde8+9QG/r9ZcnuMuBYEfH6?=
 =?us-ascii?Q?9W9yQa7LwpzzQVAyzh4Ye25ENZkStyogf3ile9I7pmjkj1BXw55RhNJwstiG?=
 =?us-ascii?Q?3I/mpUsdwF2hd0s3Nlmy5ZU36fnrhjxHwgzydvF4lCag2ue2FKE581AAYV7p?=
 =?us-ascii?Q?k/t/ZVJx3WGkjrTJ3O8I8m6YVHEgZQp6qrFInSEt+sGA1ufhKRCvkYcIb6wO?=
 =?us-ascii?Q?ngscSstSOsZIkzs4uUEuWqMbgh+299mSSEoeilvKoe0iqBF6yNohvW7ZLIEz?=
 =?us-ascii?Q?PkrODbOrPyAhIobun1LaPxJf5d1o+tP62b2yJwiw28Vl8zT/EHGZDMMRA68g?=
 =?us-ascii?Q?hJy61gNTwiUJAFTFEtqJp5U26/5ohwmD5GlJEKfMDtIzyN7eubBJECVo6cfn?=
 =?us-ascii?Q?/btXSTYnANXrvSgY8/2zM9IoK6sZhM1s4ilj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 07:39:25.7498
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d1601738-a023-4573-46d1-08ddf03d2acc
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4334

File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handling
routines, and its compilation shall be guarded by CONFIG_VM_EVENT too.
Futhermore, features about monitor_op and memory access are both based on
vm event subsystem, so monitor.o/mem_access.o shall be wrapped under
CONFIG_VM_EVENT.

Although CONFIG_VM_EVENT is forcibly enabled on x86, we could disable it
through disabling CONFIG_MGMT_HYPERCALLS in the future.
In consequence, a few functions, like the ones defined in hvm/monitor.h,
needs stub to pass compilation when CONFIG_VM_EVENT=n.
Remove the CONFIG_VM_EVENT wrapper for "#include ", as
we need stub of "p2m_mem_access_check()" to pass compilation on
CONFIG_VM_EVENT=n

The following functions are developed on the basis of vm event framework, or
only invoked by vm_event.c/monitor.c/mem_access.c, so they all shall be
wrapped with CONFIG_VM_EVENT:
- hvm_toggle_singlestep
- hvm_fast_singlestep
- hvm_enable_msr_interception
  - hvm_function_table.enable_msr_interception
- hvm_has_set_descriptor_access_existing
  - hvm_function_table.set_descriptor_access_existing

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- split out XSM changes
- remove unnecessary stubs
- move "struct p2m_domain" declaration ahead of the #ifdef
---
 xen/arch/x86/Makefile                   |  2 +-
 xen/arch/x86/hvm/Makefile               |  4 +-
 xen/arch/x86/hvm/hvm.c                  |  2 +
 xen/arch/x86/hvm/svm/svm.c              |  8 +++
 xen/arch/x86/hvm/vmx/vmx.c              | 10 ++++
 xen/arch/x86/include/asm/hvm/hvm.h      | 10 ++++
 xen/arch/x86/include/asm/hvm/monitor.h  | 65 ++++++++++++++++++++++++-
 xen/arch/x86/include/asm/hvm/vm_event.h |  4 ++
 xen/arch/x86/include/asm/mem_access.h   |  9 ++++
 xen/arch/x86/include/asm/monitor.h      |  7 +++
 xen/include/xen/mem_access.h            | 35 +++++++++++--
 xen/include/xen/monitor.h               |  8 ++-
 xen/include/xen/vm_event.h              | 24 ++++++++-
 13 files changed, 176 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a9fdba0b4c..a7bfe4c0b1 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -76,7 +76,7 @@ obj-y += usercopy.o
 obj-y += x86_emulate.o
 obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += hpet.o
-obj-y += vm_event.o
+obj-$(CONFIG_VM_EVENT) += vm_event.o
 obj-y += xstate.o
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 6ec2c8f2db..952db00dd7 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -16,7 +16,7 @@ obj-y += io.o
 obj-y += ioreq.o
 obj-y += irq.o
 obj-y += mmio.o
-obj-y += monitor.o
+obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += mtrr.o
 obj-y += nestedhvm.o
 obj-y += pmtimer.o
@@ -26,7 +26,7 @@ obj-y += save.o
 obj-y += stdvga.o
 obj-y += vioapic.o
 obj-y += vlapic.o
-obj-y += vm_event.o
+obj-$(CONFIG_VM_EVENT) += vm_event.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a..b044dc2ecb 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5266,6 +5266,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
     return rc;
 }
 
+#ifdef CONFIG_VM_EVENT
 void hvm_toggle_singlestep(struct vcpu *v)
 {
     ASSERT(atomic_read(&v->pause_count));
@@ -5275,6 +5276,7 @@ void hvm_toggle_singlestep(struct vcpu *v)
 
     v->arch.hvm.single_step = !v->arch.hvm.single_step;
 }
+#endif /* CONFIG_VM_EVENT */
 
 #ifdef CONFIG_ALTP2M
 void hvm_fast_singlestep(struct vcpu *v, uint16_t p2midx)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b54f9d9af5..b726d760d4 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -298,6 +298,7 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, int flags)
         __clear_bit(msr * 2 + 1, msr_bit);
 }
 
+#ifdef CONFIG_VM_EVENT
 static void cf_check svm_enable_msr_interception(struct domain *d, uint32_t msr)
 {
     struct vcpu *v;
@@ -305,6 +306,7 @@ static void cf_check svm_enable_msr_interception(struct domain *d, uint32_t msr)
     for_each_vcpu ( d, v )
         svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
 }
+#endif /* CONFIG_VM_EVENT */
 
 static void svm_save_dr(struct vcpu *v)
 {
@@ -825,6 +827,7 @@ static void cf_check svm_set_rdtsc_exiting(struct vcpu *v, bool enable)
     vmcb_set_general2_intercepts(vmcb, general2_intercepts);
 }
 
+#ifdef CONFIG_VM_EVENT
 static void cf_check svm_set_descriptor_access_exiting(
     struct vcpu *v, bool enable)
 {
@@ -842,6 +845,7 @@ static void cf_check svm_set_descriptor_access_exiting(
 
     vmcb_set_general1_intercepts(vmcb, general1_intercepts);
 }
+#endif /* CONFIG_VM_EVENT */
 
 static unsigned int cf_check svm_get_insn_bytes(struct vcpu *v, uint8_t *buf)
 {
@@ -2456,9 +2460,13 @@ static struct hvm_function_table __initdata_cf_clobber svm_function_table = {
     .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
     .msr_read_intercept   = svm_msr_read_intercept,
     .msr_write_intercept  = svm_msr_write_intercept,
+#ifdef CONFIG_VM_EVENT
     .enable_msr_interception = svm_enable_msr_interception,
+#endif
     .set_rdtsc_exiting    = svm_set_rdtsc_exiting,
+#ifdef CONFIG_VM_EVENT
     .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
+#endif
     .get_insn_bytes       = svm_get_insn_bytes,
 
     .nhvm_vcpu_initialise = nsvm_vcpu_initialise,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e2b5077654..4cf5da70ad 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1519,6 +1519,7 @@ static void cf_check vmx_set_rdtsc_exiting(struct vcpu *v, bool enable)
     vmx_vmcs_exit(v);
 }
 
+#ifdef CONFIG_VM_EVENT
 static void cf_check vmx_set_descriptor_access_exiting(
     struct vcpu *v, bool enable)
 {
@@ -1533,6 +1534,7 @@ static void cf_check vmx_set_descriptor_access_exiting(
     vmx_update_secondary_exec_control(v);
     vmx_vmcs_exit(v);
 }
+#endif /* CONFIG_VM_EVENT */
 
 static void cf_check vmx_init_hypercall_page(void *p)
 {
@@ -2412,6 +2414,7 @@ static void cf_check vmx_handle_eoi(uint8_t vector, int isr)
         printk_once(XENLOG_WARNING "EOI for %02x but SVI=%02x\n", vector, old_svi);
 }
 
+#ifdef CONFIG_VM_EVENT
 static void cf_check vmx_enable_msr_interception(struct domain *d, uint32_t msr)
 {
     struct vcpu *v;
@@ -2419,6 +2422,7 @@ static void cf_check vmx_enable_msr_interception(struct domain *d, uint32_t msr)
     for_each_vcpu ( d, v )
         vmx_set_msr_intercept(v, msr, VMX_MSR_W);
 }
+#endif /* CONFIG_VM_EVENT */
 
 #ifdef CONFIG_ALTP2M
 
@@ -2870,7 +2874,9 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = {
     .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
     .update_vlapic_mode = vmx_vlapic_msr_changed,
     .nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
+#ifdef CONFIG_VM_EVENT
     .enable_msr_interception = vmx_enable_msr_interception,
+#endif
 #ifdef CONFIG_ALTP2M
     .altp2m_vcpu_update_p2m = vmx_vcpu_update_eptp,
     .altp2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve,
@@ -3078,9 +3084,11 @@ const struct hvm_function_table * __init start_vmx(void)
 
     vmx_function_table.caps.singlestep = cpu_has_monitor_trap_flag;
 
+#ifdef CONFIG_VM_EVENT
     if ( cpu_has_vmx_dt_exiting )
         vmx_function_table.set_descriptor_access_exiting =
             vmx_set_descriptor_access_exiting;
+#endif
 
     /*
      * Do not enable EPT when (!cpu_has_vmx_pat), to prevent security hole
@@ -3151,8 +3159,10 @@ void __init vmx_fill_funcs(void)
     if ( !cpu_has_xen_ibt )
         return;
 
+#ifdef CONFIG_VM_EVENT
     vmx_function_table.set_descriptor_access_exiting =
         vmx_set_descriptor_access_exiting;
+#endif
 
     vmx_function_table.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap;
     vmx_function_table.process_isr            = vmx_process_isr;
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index f02183691e..b2c75b733e 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -192,7 +192,9 @@ struct hvm_function_table {
     void (*handle_cd)(struct vcpu *v, unsigned long value);
     void (*set_info_guest)(struct vcpu *v);
     void (*set_rdtsc_exiting)(struct vcpu *v, bool enable);
+#ifdef CONFIG_VM_EVENT
     void (*set_descriptor_access_exiting)(struct vcpu *v, bool enable);
+#endif
 
     /* Nested HVM */
     int (*nhvm_vcpu_initialise)(struct vcpu *v);
@@ -224,7 +226,9 @@ struct hvm_function_table {
                                 paddr_t *L1_gpa, unsigned int *page_order,
                                 uint8_t *p2m_acc, struct npfec npfec);
 
+#ifdef CONFIG_VM_EVENT
     void (*enable_msr_interception)(struct domain *d, uint32_t msr);
+#endif
 
 #ifdef CONFIG_ALTP2M
     /* Alternate p2m */
@@ -435,7 +439,11 @@ static inline bool using_svm(void)
 
 static inline bool hvm_has_set_descriptor_access_exiting(void)
 {
+#ifdef CONFIG_VM_EVENT
     return hvm_funcs.set_descriptor_access_exiting;
+#else
+    return false;
+#endif
 }
 
 static inline void hvm_domain_creation_finished(struct domain *d)
@@ -681,7 +689,9 @@ static inline int nhvm_hap_walk_L1_p2m(
 
 static inline void hvm_enable_msr_interception(struct domain *d, uint32_t msr)
 {
+#ifdef CONFIG_VM_EVENT
     alternative_vcall(hvm_funcs.enable_msr_interception, d, msr);
+#endif
 }
 
 static inline bool hvm_is_singlestep_supported(void)
diff --git a/xen/arch/x86/include/asm/hvm/monitor.h b/xen/arch/x86/include/asm/hvm/monitor.h
index 02021be47b..561ca2e585 100644
--- a/xen/arch/x86/include/asm/hvm/monitor.h
+++ b/xen/arch/x86/include/asm/hvm/monitor.h
@@ -17,14 +17,16 @@ enum hvm_monitor_debug_type
     HVM_MONITOR_DEBUG_EXCEPTION,
 };
 
+#define hvm_monitor_crX(cr, new, old) \
+                        hvm_monitor_cr(VM_EVENT_X86_##cr, new, old)
+
+#ifdef CONFIG_VM_EVENT
 /*
  * Called for current VCPU on crX/MSR changes by guest. Bool return signals
  * whether emulation should be postponed.
  */
 bool hvm_monitor_cr(unsigned int index, unsigned long value,
                     unsigned long old);
-#define hvm_monitor_crX(cr, new, old) \
-                        hvm_monitor_cr(VM_EVENT_X86_##cr, new, old)
 bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value);
 void hvm_monitor_descriptor_access(uint64_t exit_info,
                                    uint64_t vmx_exit_qualification,
@@ -45,6 +47,65 @@ int hvm_monitor_vmexit(unsigned long exit_reason,
 
 int hvm_monitor_io(unsigned int port, unsigned int bytes,
                    bool in, bool str);
+#else
+static inline bool hvm_monitor_cr(unsigned int index, unsigned long value,
+                                  unsigned long old)
+{
+    return false;
+}
+
+static inline bool hvm_monitor_msr(unsigned int msr, uint64_t new_value,
+                                   uint64_t old_value)
+{
+    return false;
+}
+
+static inline void hvm_monitor_descriptor_access(uint64_t exit_info,
+                                        uint64_t vmx_exit_qualification,
+                                        uint8_t descriptor, bool is_write) {}
+
+static inline int hvm_monitor_debug(unsigned long rip,
+                                    enum hvm_monitor_debug_type type,
+                                    unsigned int trap_type,
+                                    unsigned int insn_length,
+                                    unsigned int pending_dbg)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline int hvm_monitor_cpuid(unsigned long insn_length,
+                                    unsigned int leaf, unsigned int subleaf)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline void hvm_monitor_interrupt(unsigned int vector,
+                                         unsigned int type,
+                                         unsigned int err, uint64_t cr2) {}
+
+static inline bool hvm_monitor_emul_unimplemented(void)
+{
+    return false;
+}
+
+static inline bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn,
+                                         uint32_t pfec, uint16_t kind)
+{
+    return false;
+}
+
+static inline int hvm_monitor_vmexit(unsigned long exit_reason,
+                                     unsigned long exit_qualification)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline int hvm_monitor_io(unsigned int port, unsigned int bytes,
+                                 bool in, bool str)
+{
+    return -EOPNOTSUPP;
+}
+#endif /* CONFIG_VM_EVENT */
 
 #endif /* __ASM_X86_HVM_MONITOR_H__ */
 
diff --git a/xen/arch/x86/include/asm/hvm/vm_event.h b/xen/arch/x86/include/asm/hvm/vm_event.h
index 506a85c774..1628230182 100644
--- a/xen/arch/x86/include/asm/hvm/vm_event.h
+++ b/xen/arch/x86/include/asm/hvm/vm_event.h
@@ -8,7 +8,11 @@
 #ifndef __ASM_X86_HVM_VM_EVENT_H__
 #define __ASM_X86_HVM_VM_EVENT_H__
 
+#ifdef CONFIG_VM_EVENT
 void hvm_vm_event_do_resume(struct vcpu *v);
+#else
+static inline void hvm_vm_event_do_resume(struct vcpu *v) {}
+#endif /* CONFIG_VM_EVENT */
 
 #endif /* __ASM_X86_HVM_VM_EVENT_H__ */
 
diff --git a/xen/arch/x86/include/asm/mem_access.h b/xen/arch/x86/include/asm/mem_access.h
index 1a52a10322..c786116310 100644
--- a/xen/arch/x86/include/asm/mem_access.h
+++ b/xen/arch/x86/include/asm/mem_access.h
@@ -14,6 +14,7 @@
 #ifndef __ASM_X86_MEM_ACCESS_H__
 #define __ASM_X86_MEM_ACCESS_H__
 
+#ifdef CONFIG_VM_EVENT
 /*
  * Setup vm_event request based on the access (gla is -1ull if not available).
  * Handles the rw2rx conversion. Boolean return value indicates if event type
@@ -25,6 +26,14 @@
 bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
                           struct npfec npfec,
                           struct vm_event_st **req_ptr);
+#else
+static inline bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
+                                        struct npfec npfec,
+                                        struct vm_event_st **req_ptr)
+{
+    return false;
+}
+#endif /* CONFIG_VM_EVENT */
 
 /* Check for emulation and mark vcpu for skipping one instruction
  * upon rescheduling if required. */
diff --git a/xen/arch/x86/include/asm/monitor.h b/xen/arch/x86/include/asm/monitor.h
index 3c64d8258f..850c0798d7 100644
--- a/xen/arch/x86/include/asm/monitor.h
+++ b/xen/arch/x86/include/asm/monitor.h
@@ -123,7 +123,14 @@ static inline void arch_monitor_cleanup_domain(struct domain *d) {}
 
 #endif
 
+#ifdef CONFIG_VM_EVENT
 bool monitored_msr(const struct domain *d, u32 msr);
+#else
+static inline bool monitored_msr(const struct domain *d, u32 msr)
+{
+    return false;
+}
+#endif
 bool monitored_msr_onchangeonly(const struct domain *d, u32 msr);
 
 #endif /* __ASM_X86_MONITOR_H__ */
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 4de651038d..efbb26b703 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -33,9 +33,7 @@
  */
 struct vm_event_st;
 
-#ifdef CONFIG_VM_EVENT
 #include 
-#endif
 
 /*
  * Additional access types, which are used to further restrict
@@ -74,6 +72,7 @@ typedef enum {
 } p2m_access_t;
 
 struct p2m_domain;
+#ifdef CONFIG_VM_EVENT
 bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
                                  xenmem_access_t xaccess,
                                  p2m_access_t *paccess);
@@ -99,10 +98,40 @@ long p2m_set_mem_access_multi(struct domain *d,
 int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access,
                        unsigned int altp2m_idx);
 
-#ifdef CONFIG_VM_EVENT
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
 #else
+static inline bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
+                                               xenmem_access_t xaccess,
+                                               p2m_access_t *paccess)
+{
+    return false;
+}
+
+static inline long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
+                                      uint32_t start, uint32_t mask,
+                                      xenmem_access_t access,
+                                      unsigned int altp2m_idx)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline long p2m_set_mem_access_multi(struct domain *d,
+                            const XEN_GUEST_HANDLE(const_uint64) pfn_list,
+                            const XEN_GUEST_HANDLE(const_uint8) access_list,
+                            uint32_t nr, uint32_t start, uint32_t mask,
+                            unsigned int altp2m_idx)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline int p2m_get_mem_access(struct domain *d, gfn_t gfn,
+                                     xenmem_access_t *access,
+                                     unsigned int altp2m_idx)
+{
+    return -EOPNOTSUPP;
+}
+
 static inline
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index c086c4390c..1b7984909e 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -30,6 +30,7 @@ struct xen_domctl_monitor_op;
 #ifdef CONFIG_VM_EVENT
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
 void monitor_guest_request(void);
+int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
 #else /* !CONFIG_VM_EVENT */
 static inline int monitor_domctl(struct domain *d,
                                  struct xen_domctl_monitor_op *mop)
@@ -37,8 +38,11 @@ static inline int monitor_domctl(struct domain *d,
     return -EOPNOTSUPP;
 }
 static inline void monitor_guest_request(void) {}
+static inline int monitor_traps(struct vcpu *v, bool sync,
+                                vm_event_request_t *req)
+{
+    return -EOPNOTSUPP;
+}
 #endif /* !CONFIG_VM_EVENT */
 
-int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
-
 #endif /* __XEN_MONITOR_H__ */
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 27d0c74216..4b3d0d15ec 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -50,6 +50,7 @@ struct vm_event_domain
     unsigned int last_vcpu_wake_up;
 };
 
+#ifdef CONFIG_VM_EVENT
 /* Returns whether a ring has been set up */
 bool vm_event_check_ring(struct vm_event_domain *ved);
 
@@ -68,6 +69,20 @@ bool vm_event_check_ring(struct vm_event_domain *ved);
  */
 int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
                           bool allow_sleep);
+#else
+static inline bool vm_event_check_ring(struct vm_event_domain *ved)
+{
+    return false;
+}
+
+static inline int __vm_event_claim_slot(struct domain *d,
+                                        struct vm_event_domain *ved,
+                                        bool allow_sleep)
+{
+    return -EOPNOTSUPP;
+}
+#endif /* CONFIG_VM_EVENT */
+
 static inline int vm_event_claim_slot(struct domain *d,
                                       struct vm_event_domain *ved)
 {
@@ -82,23 +97,28 @@ static inline int vm_event_claim_slot_nosleep(struct domain *d,
 
 void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
 
+#ifdef CONFIG_VM_EVENT
 void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
                           vm_event_request_t *req);
 
-#ifdef CONFIG_VM_EVENT
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d);
 int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
+
+void vm_event_vcpu_pause(struct vcpu *v);
 #else /* !CONFIG_VM_EVENT */
+static inline void vm_event_put_request(struct domain *d,
+                                        struct vm_event_domain *ved,
+                                        vm_event_request_t *req) {}
 static inline void vm_event_cleanup(struct domain *d) {}
 static inline int vm_event_domctl(struct domain *d,
                                   struct xen_domctl_vm_event_op *vec)
 {
     return -EOPNOTSUPP;
 }
+static inline void vm_event_vcpu_pause(struct vcpu *v) {};
 #endif /* !CONFIG_VM_EVENT */
 
-void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
 
 void vm_event_fill_regs(vm_event_request_t *req);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117590.1463701 (Exim 4.92)
	(envelope-from )
	id 1uwFQY-0007hc-Fa; Wed, 10 Sep 2025 07:39:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117590.1463701; Wed, 10 Sep 2025 07:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFQY-0007ga-7m; Wed, 10 Sep 2025 07:39:38 +0000
Received: by outflank-mailman (input) for mailman id 1117590;
 Wed, 10 Sep 2025 07:39:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwFQX-0005yt-6G
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:37 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20610.outbound.protection.outlook.com
 [2a01:111:f403:240a::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4c5dcd5e-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:36 +0200 (CEST)
Received: from BYAPR11CA0072.namprd11.prod.outlook.com (2603:10b6:a03:80::49)
 by BY5PR12MB4067.namprd12.prod.outlook.com (2603:10b6:a03:212::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:32 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::59) by BYAPR11CA0072.outlook.office365.com
 (2603:10b6:a03:80::49) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:31 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:31 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:15 -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: 4c5dcd5e-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lg/rQlYttFe336ob4CObvp/2vWQ8I+M79Lb6bkBPjX6OFIhM0S33O2gJrM2o9nPyLCF1Frws8kh8AONbHUT7ziphAUa7fi86L9Vc4BsNKZfiE9kXIZI/c/c4JEcaVy7ONLBipSisuMqgIQ06SObdZv8FMoRGhMtPtcpaTbyLc4LxtVuEXnwb/UpaYnyY9qKvOrUV254CMiboGlc7L0OKphbfb31tc1m8bbj+tdGxkgcp8tfgaJjFIC0ELj5o/s8UIYOIIaL1uTBFPjmVvVjvqhJn4uNouL3ESNZ8Nv6VW3A8d0OTY43WdFAqG1jY+PassmpCzBNLNgCnowr7dW+gwA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i/kOr6NWGAHtu7qRDO4SbbFA71cfMDDDWYMWSaKP9zk=;
 b=GjOedmGI3kMp3RF/JqKDhCW25x7gzCldl9A6hpTCUA9W9fqrp7sPJqyZnyhInMOwO10WOKBOlT1ekBba+eJnJuvfRrQNCP6tbUjgRgD3XjslU/KOVhZ/gVK+sYtTyIN3xc20RpTj8C5vZ6P5bTz61jC39u+SqzCAMZf0HvjrkPvHW83SKMBDbs4w5fwjMc3dwz0F/R/x/aChdUwUcETMRlvop5yFsPn5MMlHz6r91xxPeE3toi+ubmt5GmMOrDYs4bM4FU8pPrPzWzN6DyTrDDsYnHKsstUwClyfDWXX1Yyx5csSuJ2nG6+ukYOsGcjJ1cF5UBMUNc31OZQWICy1pw==
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=i/kOr6NWGAHtu7qRDO4SbbFA71cfMDDDWYMWSaKP9zk=;
 b=aIF739X5s2DHVz/S1ZXaPVJITPlcNBYlhJDZ+DJ529KjNyUb80x1W9JLN5D6fjN4NFXiOnkyie3skPvm26Pb+6TaENXa0b7zuZ7tQAnft3Z0f1NztZcd4pxWEOzS/eoNo0XVjsW5EQs1V9lHXkDlEp+BMuguh0iVkqlH7XoTIS0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 07/26] xen/domctl: wrap domain_pause_by_systemcontroller() with MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:08 +0800
Message-ID: <20250910073827.3622177-8-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|BY5PR12MB4067:EE_
X-MS-Office365-Filtering-Correlation-Id: 51f86d3f-0d78-4c7e-566b-08ddf03d2e3d
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?y04zgkfScc3igoFPAO8b28+KL1lwiiFcWZGcGg5qva1e4aFUHY/E32CyBm26?=
 =?us-ascii?Q?dE8Odugeg7+H6RhXss2WWtBcy/dBtI4NJX1qN4Od68RiLGKjLtXtXBzgwE9N?=
 =?us-ascii?Q?i6GQ3DhMttpqw+cFh/ZVTCCW4hrVcsFt/GTFFP3HKnd1Q+9rW9ZDeCYp0kJW?=
 =?us-ascii?Q?7ucIL2EtsCnNSPW9f7zzSV614lCJqJap4Jdbfb1sUM0CFUUlb6blaG9dCOgr?=
 =?us-ascii?Q?GLfTTjDQug5ARup4Cc3VKptQwkDu3znxODI+aNStkfgIMTIaJupJktKydc5I?=
 =?us-ascii?Q?4tlwoANDAbSdRJcXkV17mNtKqDk/29bhgoBhO34ERd60E0hhQePpBP02qCWi?=
 =?us-ascii?Q?ox2Re8S1wU05zNTDMyZYW7UuytmhazXSDxggVwQwFhsv9f2/QD5DSRdBVNoZ?=
 =?us-ascii?Q?wnJXJshwrI4ec6FMhjD3DzoEsjo+9vDOvmcQGGKh33rgzezz9xma1mbjkkwc?=
 =?us-ascii?Q?AzcDgMA2iuaKSnXh+ENKHYBraK7am0abuX2HxFYaCYtX06LY31JC7I9z3t0F?=
 =?us-ascii?Q?4SORwn07ZxFL4lbN4nnJ5ny4E1x2CAPEWM2CKRU/VZvoNXHIWuIMl+NKV8hJ?=
 =?us-ascii?Q?5CjJP3wX39tSKj3Y7PQtQyg7h3QY3FmanHh7VBtJgMMbTf5vlv2YZXJCfpWj?=
 =?us-ascii?Q?/mfNiPVORHjr5rY3u7N43UPFeCsujDz7oVUiA8AS/u0Yb/IvXk93ZJJSQ5wl?=
 =?us-ascii?Q?379+8R4kMS43wmzBEYKoXRLJVFP5lCF9hi1krT5HQcHnd+NRVy1s3JyNj/Mv?=
 =?us-ascii?Q?zUSZAvXpK5nkxkkI7brC7eELJPSb4MHKMxIpJWhoQ95CHeCasUNMwOcEQkKE?=
 =?us-ascii?Q?b0R2G1adsd2sRwFPQ5bwEUNDSN17S81i4kuxKYrOFzWhK5rBPFrR3rMOjMdE?=
 =?us-ascii?Q?KQggkqsucjz01iKsebQQo7gkiYIvFkyt+SXdg0JoiV+mpxWwVttBy/YswZQZ?=
 =?us-ascii?Q?zd4jnJUNeSKVQV0ZqXbqsJxKMA9h9a5n+VszvTFVVp0B2FrsTGn5jVCd5T0t?=
 =?us-ascii?Q?DjawL2oG8x6yf5YYqH3KbmkwAn6gomofz5Z2XhXBxljfDZFcEEa0qSG+DDv0?=
 =?us-ascii?Q?fu59fRCJAJYDRJ8OslRQoYSg1mSIWT7vxG4pBXanqsNEKHSV1kiOntGZyBuf?=
 =?us-ascii?Q?+BSmxX2E+2i+HX/07aMZzqvMO3xoBSityxERKfgjTEzbW92494o+SZ1MOLFr?=
 =?us-ascii?Q?tU74OdP80FpGSCdx7cJ9ltjkxU846TOX5p0ZuDG+dmWxnp9rzypNRTvTb1p9?=
 =?us-ascii?Q?nPZH6SKE7EXpLS97OIC+Q7V4BK72EGxYwtURzXDc7U7rlUIPMJhRK2D13gxN?=
 =?us-ascii?Q?b2k8Bfp2+3guvp/wLX8jJ4cDRjyOJSgxFKR5fAnn/0sbMyxR8LOtAhhFl8Kb?=
 =?us-ascii?Q?MMCO/zdpPuCRQm3GWn/3Bxfn5ZYWDftkCvf1waCM6pBeffpOqdEM7i5eOryW?=
 =?us-ascii?Q?RAOLdU3D+TF010iFSLI8nBxdX4mCyO4JEts09q4edv4gxyMtfeIisIEWkkat?=
 =?us-ascii?Q?hcuJqrVDNYn0CBinn7043ZKO2DiprM0WAabp?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:31.5245
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 51f86d3f-0d78-4c7e-566b-08ddf03d2e3d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4067

Function domain_pause_by_systemcontroller() is responsible for
XEN_DOMCTL_pausedomain domctl-op, and shall be wrapped around with
CONFIG_MGMT_HYPERCALLS.
Provide transient wrapping around XEN_DOMCTL_pausedomain-case, and it
will be removed on introducing CONFIG_MGMT_HYPERCALLS on the common/domctl.c
in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- provide transient wrapping around XEN_DOMCTL_pausedomain-case
---
 xen/common/domain.c | 2 ++
 xen/common/domctl.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 775c339285..976172c7d3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1606,10 +1606,12 @@ static int _domain_pause_by_systemcontroller(struct domain *d, bool sync)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int domain_pause_by_systemcontroller(struct domain *d)
 {
     return _domain_pause_by_systemcontroller(d, true /* sync */);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int domain_pause_by_systemcontroller_nosync(struct domain *d)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 71e712c1f3..0061d7972a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -390,11 +390,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
     }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_pausedomain:
         ret = -EINVAL;
         if ( d != current->domain )
             ret = domain_pause_by_systemcontroller(d);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_unpausedomain:
         ret = domain_unpause_by_systemcontroller(d);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117593.1463715 (Exim 4.92)
	(envelope-from )
	id 1uwFQa-0008B3-OF; Wed, 10 Sep 2025 07:39:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117593.1463715; Wed, 10 Sep 2025 07:39: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 1uwFQa-0008Ar-K8; Wed, 10 Sep 2025 07:39:40 +0000
Received: by outflank-mailman (input) for mailman id 1117593;
 Wed, 10 Sep 2025 07: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 1uwFQZ-0005yo-KT
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:39 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2416::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4da726d3-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:37 +0200 (CEST)
Received: from BYAPR11CA0049.namprd11.prod.outlook.com (2603:10b6:a03:80::26)
 by IA1PR12MB7709.namprd12.prod.outlook.com (2603:10b6:208:423::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Wed, 10 Sep
 2025 07:39:31 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::d0) by BYAPR11CA0049.outlook.office365.com
 (2603:10b6:a03:80::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:30 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:30 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:13 -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: 4da726d3-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zTZ6Qh4MTMFTbpNxxNnyEGALzfKW9QiV262qFDlKL1mXpywhu7ZQeWEA8rTWybntABpTkQdKx0VkCk4Zn/+wsbN2c/tPCcRJZ9pb+usX5qug7vlDyFtEodNvXKV0lx7t1lYXkh/b6oAOFPfA0gE27uWGSYyqwZK2ylMLpLm7VgU9nVmjF30Y/znZpUvPzJ0MRTBKH37a8PLuR3Zi6xoEKmeuCQXvTH3jC0MghgfSF5o7WvjLE1Kthm6jSL4iF0PcNEIw6OiWW5um0rHafUAU1rX4YR9spB4sOzSZYfxze74/qqkXq9pfDRlfOGzLW20t1enEth3uwEyVRkUAh8/46Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lTp42bSRhvcOVjyyk45wHe2EzSvJUdHkIazLuJGONW0=;
 b=rds/uSPeY8WiIi7nzMTW5acYHgbyTZeSaQioK/hJgFmwJuraL1qbVMAh2CCMXvJ7FkCAuuALhs5+dLU15M9XHFyyvSHW2XrDQw15JBRxIBnEzw2KZvgCxkShJyA5vwQp9YlG69osmqWUjQGpnboOKq1P5rBKxkNKfqUaeTKgkDGYLp/lHMn3r8KW6bSfmnqxwP6yylruC2yR2O/GkopAuKWF4d8kjWvIcqfjcx5w0WNTwFpxOhv8iv1tRB/VC1UX3Fn7wXGlH0BsCn0JTJ1AUhDcpofLDeeSCASW8fBwOzWoSZgebgT/qA7MAgOWCHPAL+r3oopMhM+z2f5kBv2gjw==
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=lTp42bSRhvcOVjyyk45wHe2EzSvJUdHkIazLuJGONW0=;
 b=NaNrqsR6V0adY+a/gwrIl7TuoBEsX3k8cvmef0oFBCFk3QN2qInkfH6cChjHOHMmIX+ytaMQK/8nWb88JsnSsJgZUNovXt9q6FPnzjJ8cO0b3XTQdozlbTy/Jq9TkQ16Gb+lKmxLoqOKPrcRQASvjXbntucbjeox5bg58YvalTc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	
Subject: [PATCH v2 06/26] xen/xsm: wrap xsm_vm_event_control() with CONFIG_VM_EVENT
Date: Wed, 10 Sep 2025 15:38:07 +0800
Message-ID: <20250910073827.3622177-7-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|IA1PR12MB7709:EE_
X-MS-Office365-Filtering-Correlation-Id: 4343a5d8-9658-4a14-11a3-08ddf03d2dba
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?h02Y4c5oLfnA7rjckCmcjoJuAv9ATOrf5OEH9R8o/VlA+dnjXJb76xsnXdMC?=
 =?us-ascii?Q?UHm4iWGTUuDhUz2WLH4UtF4zy/GAi+7Fi/2oKAAS23aOqylIlLr3nBqZu/bb?=
 =?us-ascii?Q?CHxic30sy/jhA9+jHSaKUNSZUwajlbdO9BisG/IBwDnv/artNPt+2z9mNdDl?=
 =?us-ascii?Q?AbRJRqE5OEM1vO3IvoDMEF27HYY1LBFrsGHG3KdXa/QfIPp/uYia3+7Kb7uf?=
 =?us-ascii?Q?YgMLdpPN57jFBQBvmWlBthPE+8OTXSLtqqlGcznp7s+m3MhKe/xbtcJPK5Vr?=
 =?us-ascii?Q?0xYUq1FmmzZqn0zTW4kgjO+wfmn6LzK/WipluFdA518dXQshRiwLABjsuadj?=
 =?us-ascii?Q?CNR7ylCzHoUGGyC89EYfkr+lA8WlGSTwMrv8Goj3aErb17DcpFIiWMHMZhcr?=
 =?us-ascii?Q?ArvFFJ/v5yoBxcBGnqw6idiIVWTfRQqy17Cd4eMFl5usdK0CG1ojVVgJrmt7?=
 =?us-ascii?Q?3Dv1QLMoA5AbFtGnmxbY1nPx2vPuot/3fnC6vrtsKdGbc00SZdFmckZy/TFO?=
 =?us-ascii?Q?Id+uWxYaLGPAiubaEs8BgEnorokbNylZR13tFQGvADvej4C8iYYwKTYf2Qb8?=
 =?us-ascii?Q?vKgkFONNaleoK+0tYylm4CsHKKeQPki66IUBjBxlqA+SyT6yVcB7TXvHs0Le?=
 =?us-ascii?Q?+Re7nwPvQitB3m+Za+HEXtQytFBeqYgqQQM9I8O9pl7p+0UGPcmdO17k50Dh?=
 =?us-ascii?Q?iRKIillq7fEIO6E1F6EhugaH15F7oih8DoxYqATYLWbzJiWQvVxHkHJZ9E+N?=
 =?us-ascii?Q?0o69pf111U8zOTGiNdhnKB4JPL3Qx65ID/+Thu+ikBfy3JapyG7Csh+8xwo6?=
 =?us-ascii?Q?cwGBb/v7hfVQLYSnEx2Yrifr3osWtw6iVYPP83U+/dgXw9khtMknUYr0awu+?=
 =?us-ascii?Q?EihSTKxxP9i0BG6wL1wme1GE9OlYGA8oT95gVmuxA625zPrazSVJ6H2TYYXu?=
 =?us-ascii?Q?nfSszLeBbOvRVn/Lyt2MMyixZex+Z4T2jrrbV8DG2Tbmd835Vt5z24aRfEAu?=
 =?us-ascii?Q?qXYi2Hsaftq7jViA0t7x1K70rVVTf3cHY2IuzXQtl6tlK9dz0FVi/xka0J9b?=
 =?us-ascii?Q?HNOXtXw2m9nfdArVWYCWxebP5TREsSxvjr5uznYgBILs9IvrXOXsJ9YK6CK5?=
 =?us-ascii?Q?Kl8QibM7yeUkzD6n9JooRivXf0F7WPbOhdCx3xrVyxR78SMsbP7g7gOXdkv1?=
 =?us-ascii?Q?FzWlw2Q/in7X5i1HKRKu3vUXbhf+9F1twJ6Pjpkn4csd3YU76PC75FXHOcN9?=
 =?us-ascii?Q?Xe5NL+M1+QYGS+pDJS2mVAwgfpUMasILAKQM1tCq2An/wr7XVlVmw2d/6+R8?=
 =?us-ascii?Q?a4eWEovTRmU2QSaBNhsbO1N8CcXP7Im1G3mBlNeBKL6NpvHs3RnmgdiAWvAG?=
 =?us-ascii?Q?ptaHWbxdWu50dBwOqcgSje7wlNz5sE4SAcfHiNcvQSSiEcR+yjtFUZ5hq9td?=
 =?us-ascii?Q?j3H5t+dw4vARIHobThzhOub/YZu6zN+m2I2i39J0ytsWw8olD7lm6amC1er9?=
 =?us-ascii?Q?pdd1nSt9+V+OIiS3IYWBhdyd6hrhFOJbUCn6?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:30.6639
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4343a5d8-9658-4a14-11a3-08ddf03d2dba
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7709

Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
it shall be wrapped with it

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- new commit
---
 xen/include/xsm/xsm.h | 4 ++--
 xen/xsm/dummy.c       | 2 +-
 xen/xsm/flask/hooks.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3c960ad909..1e4647f7db 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -155,9 +155,9 @@ struct xsm_ops {
     int (*hvm_altp2mhvm_op)(struct domain *d, uint64_t mode, uint32_t op);
     int (*get_vnumainfo)(struct domain *d);
 
+#ifdef CONFIG_VM_EVENT
     int (*vm_event_control)(struct domain *d, int mode, int op);
 
-#ifdef CONFIG_VM_EVENT
     int (*mem_access)(struct domain *d);
 #endif
 
@@ -649,13 +649,13 @@ static inline int xsm_get_vnumainfo(xsm_default_t def, struct domain *d)
     return alternative_call(xsm_ops.get_vnumainfo, d);
 }
 
+#ifdef CONFIG_VM_EVENT
 static inline int xsm_vm_event_control(
     xsm_default_t def, struct domain *d, int mode, int op)
 {
     return alternative_call(xsm_ops.vm_event_control, d, mode, op);
 }
 
-#ifdef CONFIG_VM_EVENT
 static inline int xsm_mem_access(xsm_default_t def, struct domain *d)
 {
     return alternative_call(xsm_ops.mem_access, d);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index f5483e0709..2c70b979d6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -115,9 +115,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .remove_from_physmap           = xsm_remove_from_physmap,
     .map_gmfn_foreign              = xsm_map_gmfn_foreign,
 
+#ifdef CONFIG_VM_EVENT
     .vm_event_control              = xsm_vm_event_control,
 
-#ifdef CONFIG_VM_EVENT
     .mem_access                    = xsm_mem_access,
 #endif
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 21914d3507..ec3880f631 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1365,12 +1365,12 @@ static int cf_check flask_hvm_altp2mhvm_op(struct domain *d, uint64_t mode, uint
     return current_has_perm(d, SECCLASS_HVM, HVM__ALTP2MHVM_OP);
 }
 
+#ifdef CONFIG_VM_EVENT
 static int cf_check flask_vm_event_control(struct domain *d, int mode, int op)
 {
     return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__VM_EVENT);
 }
 
-#ifdef CONFIG_VM_EVENT
 static int cf_check flask_mem_access(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MEM_ACCESS);
@@ -1967,9 +1967,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .do_xsm_op = do_flask_op,
     .get_vnumainfo = flask_get_vnumainfo,
 
+#ifdef CONFIG_VM_EVENT
     .vm_event_control = flask_vm_event_control,
 
-#ifdef CONFIG_VM_EVENT
     .mem_access = flask_mem_access,
 #endif
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117594.1463724 (Exim 4.92)
	(envelope-from )
	id 1uwFQc-0008SW-4W; Wed, 10 Sep 2025 07:39:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117594.1463724; Wed, 10 Sep 2025 07:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFQb-0008S5-V1; Wed, 10 Sep 2025 07:39:41 +0000
Received: by outflank-mailman (input) for mailman id 1117594;
 Wed, 10 Sep 2025 07:39:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwFQa-0005yt-Ly
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:40 +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 4e968969-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:40 +0200 (CEST)
Received: from BYAPR11CA0062.namprd11.prod.outlook.com (2603:10b6:a03:80::39)
 by DS7PR12MB6287.namprd12.prod.outlook.com (2603:10b6:8:94::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.21; Wed, 10 Sep
 2025 07:39:36 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::44) by BYAPR11CA0062.outlook.office365.com
 (2603:10b6:a03:80::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:36 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:35 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:21 -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: 4e968969-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rVUiKKCZz1pwJPp5699W7G7o3EDjcEn0Qww5nhoxmN1sBbsc1tu+L/bDRVqNNfH6FxQOz6vEsVDvOXz4uFovdSdE6waf8fFd0tA/mkyFu8DG0HSOBNz764l4TZCUYsNQBhVI4t37wk1OxBcJJqoYl5Nq/2sr/aWn8h9CWeHdOTewNeVlf6p2WKIgoCn+2/LIhABtmYpTxLAtPx58rquLRBjBXUJg20A+TBSBRpifIKZ7sV0Mek66gxt4QGjBBI2MmCcIqzU/43fk4TUNrE1sQD6wi/FrgUToStrlndx4bu0ZiZ2YQmuZU9YRriH67wihtA9qX53HqaBseJGtvdSncA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=z6hAYbhVRKjqwBmccO7F1sUrcRPgT0pjyjykY0wxnhw=;
 b=szzAevj0MhHlDtgbptDbO0iTa2YqOeiwtcUAfAoAzKUjyIOXIH6y5D1Sl8x3Ifw8HrnvCZj1qUz+xWIJ8ZTe8yKXdZ93NU4UFlaBZgTh9A3Qc6qbJFS2R3yxfwXmjU52gSfZHR9bX13hOexXQlDPZo88GvIo7b/6Iy3ATTgGlt2JEu1DKlWtN86DrzLA5OUs1YQ95ek1UGmR7MWFDn/q+fV56UhQeEaaTb8ADqfXV2D/vzUG34ABU8mZZjqj2ITw1mmXqwV4oC3ltlr3PaZzZX9dYIivxHz+Jh9KsO8va/RxkaoyQ4QYVfCWBjngWUfq3a3M3slUWpbNg6heBVo95g==
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=z6hAYbhVRKjqwBmccO7F1sUrcRPgT0pjyjykY0wxnhw=;
 b=mBSKxN87Tp76439btxPWVtaIW/nT5E5s1RaHnR/Q6ZLm5OQLJyMiEL1lkCEcUM4gnU1WpWNBP4hTvfN+fh/7BzoRHOKUlUDuyoNEFyTF28XpJvA1ts0b6pIvWKeFbcCkYi403KpTVaIWqtREGvPpzwkrbg5js7zXAPR/xKYab/M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 09/26] xen/domctl: wrap domain_resume() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:10 +0800
Message-ID: <20250910073827.3622177-10-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|DS7PR12MB6287:EE_
X-MS-Office365-Filtering-Correlation-Id: d0f8b0d4-1f3d-4f5c-ba3b-08ddf03d30dc
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?b2GM+DZx/Bf+CG8Tj43G06F7ac/a8WC6z8W6yER3g17mkfgRZie5ioROLC4s?=
 =?us-ascii?Q?SIfsvQEOty25H/+/GL1fSy3Gsneb9X3TDlpOqAqmvRTOEShygmY6w3d16qfG?=
 =?us-ascii?Q?8L7EuGv1WZR3FQ2YYGdiGMo6gslJr9uMkDLrqjRO9SS6Q33ubixvfS/Z1R/r?=
 =?us-ascii?Q?Q/9KJvolQOPj60v6zzfDkxCU31EGnBXR35ONH1y4AhInm5eL7uXT8CvEAJ14?=
 =?us-ascii?Q?CQNcsdrp2DLVJs7CA97KgQccU50qkrw7bt2/Zs5HPBNIf3Hnnjx8Hcntf7QC?=
 =?us-ascii?Q?BIMZlMg8ofFnOZeUOHjsSzDeq9jUpbd/aryA+WD2DiCLQh8LKL968b8lKkUS?=
 =?us-ascii?Q?UuoRSy+Bd8jV4YALZX7a/nR71zBObXDqPRPsNKvPfohuxGW8pMWo3oNB9sWy?=
 =?us-ascii?Q?Wt20j9DlIRhe7M2YCpnAU8a9faRSK03CAsn37cAA9IQjLkwkPJKab4r3Zhl9?=
 =?us-ascii?Q?Xm8mdbmdXZhAtLN5z3nE8uHs1oXKI1e74m4Z7/ryRN88lnS2kcT+YckLRTay?=
 =?us-ascii?Q?ajaOcI4XyMzqjlz0HMbsigFq/zwzzmtaiiP3qr+z0qtzs6t9RiuCaT4Iwbys?=
 =?us-ascii?Q?j/bGSIQ5zuuShJ00J4805EOrMhxgtiBlDG91e4IRhfJLjentucvt1lz2Lyxt?=
 =?us-ascii?Q?JviIvcZholuu/FDG771emVyi/tqBZU4HrMwlXOHUhqgwW+cyu5uN9C/D0tMS?=
 =?us-ascii?Q?Fh4E0yiJ9p+EzJQqsXq67I59wAQSaUSYdj/TTOPwg/z6CAuZqpJgrNR2/H2h?=
 =?us-ascii?Q?So/jmf0sP1ZPAR15vaKPvlbijjSp7uiE6+3LT0bTLYkGh9nMs1jvQ0rOHup3?=
 =?us-ascii?Q?ifPwID+f3eqQ92zVEuE4B92egf3kqYyuKWkrr/FvPydfz8QWL4vChvmJalml?=
 =?us-ascii?Q?aWHm8GoQRP/EiyCjLvfXT/42R7DGJIGNFRd+vukjt/N8xQz/8Kt3RFl8MYeF?=
 =?us-ascii?Q?GNxz2L4R6rFBMH3aR0/deqQ+YQnb4Lj+gDFyrzD2u5VZ3ITExnyrGAbH4Qn8?=
 =?us-ascii?Q?UnuW8VfDP+Gsz9Md00r6hY0akdd+6nEpfUjjT5yetDO2eXW6m1w4wkle0fY3?=
 =?us-ascii?Q?5HGzj8+g+tAH4NP+lHLm3zkpY3Yr4FePXcov7wHpe2a7HbORMy9TjwEtmOKz?=
 =?us-ascii?Q?hgzQg5PITXBuP+USZx8Ml6EINR7a0ZmNw/Itisl9xaWb4BBwkqhoYkWwkA3a?=
 =?us-ascii?Q?0T9/FVh8JXFyAb5W0TpFVIT1dO6xw1dhwEHNgx/JBfu5/clcIvooxCcB7am3?=
 =?us-ascii?Q?jx7pcWniLxxNfXx/10OfVjSEcXNQwc/L2K1tsJepvQuFLNOej8ky2/l+1cjS?=
 =?us-ascii?Q?OSpzwUvQPqitZKTThl+liAZZyEoqeaRNrTXVrivgEAMa6YNMkHN4cET9s9X6?=
 =?us-ascii?Q?oyT71onVLJOBsA7K4yPm44OgtoB03/R09F8nO2+flDA7k1NgTKPJeE/hAcrA?=
 =?us-ascii?Q?XGaIO13/YhEsnZu2yfijXVbfGHDifFi8TlNpNUhkG+TueDVN1hLi6Kgu1Xmp?=
 =?us-ascii?Q?TjVkbr2llN942L61y91w6Dcu3x2iqXGBFjZd?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:35.9241
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d0f8b0d4-1f3d-4f5c-ba3b-08ddf03d30dc
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6287

One usage of function domain_resume() is in domain resume domctl-op, and
the other is in domain_soft_reset(), which is already guarded with
CONFIG_MGMT_HYPERCALLS.
So we could wrap domain_soft_reset() with CONFIG_MGMT_HYPERCALLS.

Wrap XEN_DOMCTL_resumedomain-case transiently with CONFIG_MGMT_HYPERCALLS, and
it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- new commit
---
 xen/common/domain.c | 2 ++
 xen/common/domctl.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 678e81b400..34e2e501dc 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1351,6 +1351,7 @@ int domain_shutdown(struct domain *d, u8 reason)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void domain_resume(struct domain *d)
 {
     struct vcpu *v;
@@ -1377,6 +1378,7 @@ void domain_resume(struct domain *d)
 
     domain_unpause(d);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int vcpu_start_shutdown_deferral(struct vcpu *v)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 1c0bfd456e..278a00b141 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -402,12 +402,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         ret = domain_unpause_by_systemcontroller(d);
         break;
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_resumedomain:
         if ( d == current->domain ) /* no domain_pause() */
             ret = -EINVAL;
         else
             domain_resume(d);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_createdomain:
     {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117599.1463735 (Exim 4.92)
	(envelope-from )
	id 1uwFQe-0000WC-Lu; Wed, 10 Sep 2025 07:39:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117599.1463735; Wed, 10 Sep 2025 07:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFQe-0000VL-GU; Wed, 10 Sep 2025 07:39:44 +0000
Received: by outflank-mailman (input) for mailman id 1117599;
 Wed, 10 Sep 2025 07:39:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwFQd-0005yo-2D
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:43 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2414::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4fd30496-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:41 +0200 (CEST)
Received: from BYAPR11CA0071.namprd11.prod.outlook.com (2603:10b6:a03:80::48)
 by CH3PR12MB9021.namprd12.prod.outlook.com (2603:10b6:610:173::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:35 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::4c) by BYAPR11CA0071.outlook.office365.com
 (2603:10b6:a03:80::48) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:35 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:35 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:17 -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: 4fd30496-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Vt3eqbsjLnuHl9Tqeq9eFiB5JDZNUAiIz+rTob2PNRsi3EJcBPGPKmm5Vyhx85n3bo00ISF9JFpOIFZl/YSPznamt5046nZSyQBwySL8YqI5kzB4Ajvw/ARjb9MFs6lxSzZWWuDMXYOOcOUdK3xKzLTRnfVh69x+dZWnUg3AkQlR4M94wFP6kWqvOqaiytw78479Yl7M8tdvSFID9j2tR9cFQUDwnKa2XWt+7JbZWoWantOeWBusQ1y/T8cnD0DycEfM3SOz5JgvAjMRljAFFwSKe6qkIeERRORAZ30F9MZflmusUFWWvkgkkmgYLeTJnR2BbGsVbAJvCNioUo3uRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QCQXbHre+Tmm9vrjGVCZOjoEzc5zPINt6SGXpZK2zMM=;
 b=HdVzcwTf6Pa0MpDEAli2Rw1VQN8Y7u/2SDytgthjpZ0Tnq2Grwt4i9OvPMJ2sBnhUZSMNOn5wE4j4H/mGpFEC1zIOKKLd6/rxe7bEkFh1qhPlHBliJTrN78mhyH2ntXVBTrg8s9on73InhrRHwfLVO49ZJLrW/+eAV+hwzx4qnrbm6CyI7kDVx++tD/sJOh6bGq3GQVO9WjVvZalTTMo4QkjBPmGyxTGQEHGjMZuh7owKSp+4IZ68y5dISbHI5xKMX4MQLGd6X3MmoRd8pgmsSL/cQW5Ny186DGV8+vM2+4ipVeyJQHUkpvc23VLJL44JTycIiGe3HIshjJNBZPf1g==
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=QCQXbHre+Tmm9vrjGVCZOjoEzc5zPINt6SGXpZK2zMM=;
 b=flC3c07rnLJ4sXwUGQYY2ElrhnK8Js1c+YuxievSQw4wbf9hxIjKxEyxMYMMdTpK/M09qvSef4GLGvZmagAM7O/h9LkFDPDhcxgJ8Y0Jpqhd0qXDBAXxb/+z29v4aZtvroR9DpvKo8+1u1ijQVPDZS8F21QNSnIF8szsn3PiDBI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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?=
	, Christopher Clark ,
	"Daniel P. Smith" 
Subject: [PATCH v2 08/26] xen/domctl: wrap domain_soft_reset() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:09 +0800
Message-ID: <20250910073827.3622177-9-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|CH3PR12MB9021:EE_
X-MS-Office365-Filtering-Correlation-Id: 9b4fadab-e0de-4936-b6f0-08ddf03d3061
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:
	=?us-ascii?Q?FheVA+sA+CN/qpqz6PojzQPWmIjyFnVMy6OIKFPub6+4AA8cTaf3y6LZiQIX?=
 =?us-ascii?Q?Zj19aAfctGaYr5VrcXLkvjR1GsMGjPFTfjpZKpggO2ZwK+mAuSbpmXVD5FJA?=
 =?us-ascii?Q?pLbnOkDOAYlUPLdM07Uk2rkv0ZR+LWfB82vBAn/VsUF3ULHXIH/L3R6XJt/8?=
 =?us-ascii?Q?YQL2cwpZfkymQKP+/Vj0e26+dnqVxcoYhj24PCLzKdei6vZKv1Mi+KM9++JR?=
 =?us-ascii?Q?Iat4m5b4Yv+A83z3odkNz1JwQq6mvq35vL2NUamo3c8fPhmYUAb4Ic/BUkO/?=
 =?us-ascii?Q?OQvFmb6SQ4Di3BV89gMKjhEocHvzBWqNwzBVHh3s5roiz8lckT74Zvr/gJMU?=
 =?us-ascii?Q?D+pns4LFjC35mFy/FQQ1ZM664pwcSXqgnKJSquALOfDdFq7RapVc0oTrUOEQ?=
 =?us-ascii?Q?nP+VIJ5YB9BYkbsgskCyvi+7dAyb3VoY+hOS5ZQtVzYMx49Vi/xg++JHkL/2?=
 =?us-ascii?Q?9B4LdbsrxYzLufmqVjbTTS2eS7PKFY3Oykv/Pko+NRKr0pes+7l35rjuIqh5?=
 =?us-ascii?Q?nBA1q9d8H0IcZJkkyk1xP7FjUqrSbTf8KXvr4QxkA0adlGd4QXDjVULtK2Bs?=
 =?us-ascii?Q?q6zLy3+BpF1GHKJnb1SXvOYGavYh/U4KXEJESXXuPDBSkRgW1MwRu7pdxrig?=
 =?us-ascii?Q?HHOlCJuVpCEAhMcq9be8z1NfKMPM9m3FDXHBJW8z0Xtn8CfEzIk8a9OpUGOR?=
 =?us-ascii?Q?Ogf8UUfFDGKd1QfHgEMBBcIxmtNdKvfw0/udcnJUQM+neML0HO5NMbZXGSLB?=
 =?us-ascii?Q?6u8AQPypqAOoLpYmnYBuBmYub3BDoiF6Ucuqa8jRgPkdurOddm1zfmKl3na4?=
 =?us-ascii?Q?5S79AQtKrFCIh6VJybJi6nsnTo74vxekftlxoq86U9Vp6AndcPj7sTzNUH47?=
 =?us-ascii?Q?WRs2qxtUlmWa9y7yYl4ZqzHEbxcb4Cth26DlLOg86+OCsnvdQ3McaB/jyvQl?=
 =?us-ascii?Q?oGg3ZTxy9ZwSyMfF2cGxxLK4/dlB8qGnBg3nghhWshgazX6HrsGX19rGTu9g?=
 =?us-ascii?Q?Y51dPvDF2mp7pBwHe58C+Kuy93DrvX9eh5GYyjo8FemUREVVB4V4ZtY4vDEa?=
 =?us-ascii?Q?jqM2IPslQ1d2IOAXHuQS+PaDv4ZzuFTiWrbj0HSugSqahMMtHAjJD3sFt9rr?=
 =?us-ascii?Q?ppWVl2BUnM0bFTBE1ixWUwjYvqpuPfSdE/RLsxyi3LR0d12cs7xSjcEzQXPy?=
 =?us-ascii?Q?RbONNR9rAhqN94vmgHldyJ64oIgdJXJ7S7pznZ9FvCxGQrhOmQFE/ToXfU1X?=
 =?us-ascii?Q?cfnlsQdbG7SMEucytZ5dzMWM5boLtMHKaPlwXzcOXF3RH0artdc4BbMXGtSK?=
 =?us-ascii?Q?/cW1t0K7KwKcrhRXrql6hP9SqfOMCYlIUNIYPSBGTVGWsX/BntJl8D7HUeiU?=
 =?us-ascii?Q?yG0wQWP3W02sGMieak9DYnndzb5Tvxrc77M3ei/aadBfLr9vgGFICWpsLo/b?=
 =?us-ascii?Q?AmSleBh8ln0XobQNXw1kNu9h3er1P2k769CvHyyCKWzTCyMJsF1KOa0rDTzx?=
 =?us-ascii?Q?EwgrnFituMg7l810LYP1dD8+e072M649+Y9A?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:35.1189
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b4fadab-e0de-4936-b6f0-08ddf03d3061
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9021

Function domain_soft_reset() is responsible for domain soft reset domctl-op,
and shall be wrapped with CONFIG_MGMT_HYPERCALLS
Tracking its calling chain, and the following functions shall also be wrapped
with CONFIG_MGMT_HYPERCALLS:
- grant_table_warn_active_grants()
- argo_soft_reset()
- arch_domain_soft_reset()
Wrap XEN_DOMCTL_soft_reset-case transiently with CONFIG_MGMT_HYPERCALLS, and
it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- remove unnessary wrapping in stub.c
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_soft_reset-case transiently
---
 xen/arch/arm/domain.c    | 2 ++
 xen/arch/x86/domain.c    | 2 ++
 xen/common/argo.c        | 2 ++
 xen/common/domain.c      | 2 ++
 xen/common/domctl.c      | 2 ++
 xen/common/grant_table.c | 2 ++
 6 files changed, 12 insertions(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b..30ff9dac46 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -875,10 +875,12 @@ void arch_domain_unpause(struct domain *d)
 {
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int arch_domain_soft_reset(struct domain *d)
 {
     return -ENOSYS;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void arch_domain_creation_finished(struct domain *d)
 {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 19fd86ce88..5b3c5e8caf 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1030,6 +1030,7 @@ void arch_domain_unpause(struct domain *d)
         viridian_time_domain_thaw(d);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int arch_domain_soft_reset(struct domain *d)
 {
     struct page_info *page = virt_to_page(d->shared_info), *new_page;
@@ -1131,6 +1132,7 @@ int arch_domain_soft_reset(struct domain *d)
 
     return ret;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void arch_domain_creation_finished(struct domain *d)
 {
diff --git a/xen/common/argo.c b/xen/common/argo.c
index cbe8911a43..a451546d57 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -2351,6 +2351,7 @@ argo_destroy(struct domain *d)
     write_unlock(&L1_global_argo_rwlock);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void
 argo_soft_reset(struct domain *d)
 {
@@ -2374,3 +2375,4 @@ argo_soft_reset(struct domain *d)
 
     write_unlock(&L1_global_argo_rwlock);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 976172c7d3..678e81b400 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1689,6 +1689,7 @@ void domain_unpause_except_self(struct domain *d)
         domain_unpause(d);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int domain_soft_reset(struct domain *d, bool resuming)
 {
     struct vcpu *v;
@@ -1726,6 +1727,7 @@ int domain_soft_reset(struct domain *d, bool resuming)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int vcpu_reset(struct vcpu *v)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 0061d7972a..1c0bfd456e 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -467,6 +467,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
     }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_soft_reset:
     case XEN_DOMCTL_soft_reset_cont:
         if ( d == current->domain ) /* no domain_pause() */
@@ -485,6 +486,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 ret = -EFAULT;
         }
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_destroydomain:
         ret = domain_kill(d);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index cf131c43a1..24ef1205c9 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3962,6 +3962,7 @@ int gnttab_release_mappings(struct domain *d)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void grant_table_warn_active_grants(struct domain *d)
 {
     struct grant_table *gt = d->grant_table;
@@ -4006,6 +4007,7 @@ void grant_table_warn_active_grants(struct domain *d)
 
 #undef WARN_GRANT_MAX
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void
 grant_table_destroy(
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:39:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:39:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117607.1463745 (Exim 4.92)
	(envelope-from )
	id 1uwFQi-00015P-Ts; Wed, 10 Sep 2025 07:39:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117607.1463745; Wed, 10 Sep 2025 07: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 1uwFQi-00015B-PK; Wed, 10 Sep 2025 07:39:48 +0000
Received: by outflank-mailman (input) for mailman id 1117607;
 Wed, 10 Sep 2025 07: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 1uwFQh-0005yt-4V
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:47 +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 5131ef70-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:44 +0200 (CEST)
Received: from BYAPR11CA0058.namprd11.prod.outlook.com (2603:10b6:a03:80::35)
 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.9094.22; Wed, 10 Sep
 2025 07:39:37 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::7e) by BYAPR11CA0058.outlook.office365.com
 (2603:10b6:a03:80::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:37 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:36 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:24 -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: 5131ef70-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TC4uUqyltw5vGItxPZ/zqEYWGhRZHIW8EK7/YP+IrMIHIiT3ftUzhy5em5ZawxvEyp7Z4SIfAbDx30DGK2sl1dyD46hPg6LF9OpS1OrFSwRBHKppMjuqYzpk7YR98eX1JW2o/ZgGLVEpPhAzxT2o+tk/VmQ54AeFv1PGdOlzJOSDGo8r0qZTRq9rBTD2ps59f7EDuq6rDORjoiRZzze/dnCGBA2lnoXl7gceUH3q8MZ4zqaf/+bQzQ5KEfnglMcOa8L0qd6a0boTJudUeNDu1rN3SfGsVW3/Cxozd7r9yumvru83s9twKQcyCoyQhr3TaN6y+bC6AxuU0nvHQN3Tpw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Tq+CA+zLJhXvuE0ShxLvIZ5qcSI/7xz/3Fi/Dd8+moA=;
 b=qZec2R9DBjkcd4vezsazPqBZgbF2liD9S35kgCa6ycTNzlbwFh0GGazQvUPLB5QwlxvqlLXaBlYSL4MzTq+3RWdNN74O9LDtn9YCvxEer1KhzJv6sXXAZ/gx4Cw+q1GCG28vWoEJccRPEVc//9rIlTmmeYUjRG31RqCli6s/k6YcH5RnKocgEwQ0VKf1jY9CBq8F9nQs0KKauKgGUpNnWivhoVT3zli8mUYGwUN19liDTw3JH7n7EMIoo0Wwvh4WmIhbuFtHSu8XO5o4f/rD6aSTk6cRch8NvxPRnAYP5BrNamQO7jM4xz5+HyvexToUG+O5+uwQNoGOd4H6fZNODQ==
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=Tq+CA+zLJhXvuE0ShxLvIZ5qcSI/7xz/3Fi/Dd8+moA=;
 b=ty/x+WBkoeJ15Ip2ZTSDEHU3e5nChCBt7wbRXCDoBWb6HiXOvjmD2Cch0NT/PbMrjFy7iFg8/Ru3IO43J8se2kxMfwdTI7Xhyg8RMAFAiddxjt529gTsfm1bMHowylw1c1nW7xb46y6SZTONwpHUWHSDpCUzGWndAd4AMRvc9fU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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?=
	, Tamas K Lengyel 
Subject: [PATCH v2 10/26] xen/domctl: wrap domain_kill() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:11 +0800
Message-ID: <20250910073827.3622177-11-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|MN0PR12MB6269:EE_
X-MS-Office365-Filtering-Correlation-Id: 2316dd43-d060-4201-2487-08ddf03d3149
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?fObpvZwNLj+LjZmgBHhLmcdAi2r1N+RFqoUcqT9V5kyPt7V9b5gmM9hGlcNx?=
 =?us-ascii?Q?pN/QCF/qD+mPETgUOJhFBDxahRnyx/KXqowKNQIPnJ34U2Co7XPMxRbI7sCR?=
 =?us-ascii?Q?ctiLlcJagsrNNmFS4EUcL+7EU5LFRfxPdoPwlBROsolA8BkOvbWsGq6IdpQZ?=
 =?us-ascii?Q?Zq12/hPKoX/klFUZDH6v3bx2G6sWp1jMdR6hBXsKK21ktnIXJ3KD4dW9HXZ6?=
 =?us-ascii?Q?5ZO0Vdh0ss53BAfO5miythUV95Ll0FAV08iL4CLmGkYXNIvFA3hNEuNbpBlh?=
 =?us-ascii?Q?wQrGuYcGGQKEjphDGipN8h3h+x/rwSS0x4jnv6yexXlxVIvuSuawpd60+5RZ?=
 =?us-ascii?Q?TRx3YGbSsAT0hC+V1lsBPeEo54vUO7Ihtu3dVeM14tP5hnSlJJb61kpMh3Wt?=
 =?us-ascii?Q?nyMC6cbkEYLAmuw9o8dcpxBBVN8lGaa4TNXuGlDmdNtgOfgmfggJMra+eRiQ?=
 =?us-ascii?Q?dzKmVLVNVJ9N0hwdD/t7Bpsa+PMcx1w7sQG7FmP5tzqw3xZKSe1/ssJdhNvT?=
 =?us-ascii?Q?ifcgIAor04qMs6lEoDoRwoGIjsQ8uAbdu8BME5KXHET1cnLwSNN6j+1MEjUb?=
 =?us-ascii?Q?MVFvYJTUXrwePqCQZnwORU/RWxcTV/DK5e5gtHmiZYWLdwNDxtTgGqi8PAyJ?=
 =?us-ascii?Q?bYuk+dqHbFqycIrxvEmmQKbxVdP+hb56hnzdSHYj0VDHOXCc2BcQXl03DNcx?=
 =?us-ascii?Q?u+6UhxxZm1lEc1SBw68guk3PUVnbeKabNL1JtkOnxUV3jL88iwV3quFnQdtp?=
 =?us-ascii?Q?IyyYnN/D+MWpxP+V2c88hxE4OQOgRZ1l0+QbU+MNu5SZTd16WLqJ6ErP4+VO?=
 =?us-ascii?Q?3A6+rDfJnKm7mtJEwlVxpBBq+gFwPD678yOB//y1kM0HP0nvs3ktf7FeOnKU?=
 =?us-ascii?Q?l5WjpIfeXmnd6e3g643/6KIsxoCv8BoKdu5pYbST7tRUt3K7KYfeieDaubwf?=
 =?us-ascii?Q?JTgidCY3HW5vdohFcOpMVzIHAB9zhb4e4GkidtsZowkO2d+zI1PuPBUHEd7y?=
 =?us-ascii?Q?Y8Csa3Hga3uu7qShfVINXdzuEWdLmYacLRi85BEIyEInci+5Bcjuoqk6Nwit?=
 =?us-ascii?Q?hOI59Er06sZpzGge69LhJG7L6PL9jlRehrPhSbMHwbN9lGWnjHfnTOANv3/q?=
 =?us-ascii?Q?mDDUecP1ywQGUgGwiIVItF01FsOQatD97nt1EH5J7X6vd3SOnWUB2tgYAdwm?=
 =?us-ascii?Q?SF2pYwRxWDO1GcNIvzWbEbvu2O19D9jRGWNVQrG7ki9WysI38tjTJRPjZsTl?=
 =?us-ascii?Q?vpUyD/KZ/ADwH/etXmNOsgXeDHK45K8Iv9t57BH2j8lFKyR8NysMgExtNKpf?=
 =?us-ascii?Q?C95QFQpCMWr0IJ6bZ9Z/YIUbbJNkwEisd74QshNqj1MdYzfP/CiOJL+A4HQ4?=
 =?us-ascii?Q?TFXX4BkpZXxd8fH18IRdLW72md3WXPka86i+JrHtPtCDzYco7yPWaWw5ejxH?=
 =?us-ascii?Q?ACZUgn3l8X0tIIrk4Vi98m8ERiHPehvjSoJGFMJemBLW5DjHdaq7G6gyKMu4?=
 =?us-ascii?Q?dZkBLRjFI29OjqQgmyuaT5R5gTJPlcDczKLw?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:39:36.6289
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2316dd43-d060-4201-2487-08ddf03d3149
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6269

Function domain_kill() is responsible for killing domain and relinquish
domain-held resources. and it is only invoked under
XEN_DOMCTL_destroydomain-case. So it shall be wrapped with
CONFIG_MGMT_HYPERCALLS.
Tracking its calling chain, the following functions could also be wrapped with
CONFIG_MGMT_HYPERCALLS:
- domain_relinquish_resource
  - pci_release_device
  - relinquish_shared_pages
  - paging_teardown
    - p2m_pod_empty_cache
  - relinquish_memory
  - pit_deinit
  - iommu_release_dt_devices
  - tee_relinquish_resources
    - ffa_relinquish_resources/optee_relinquish_resources
  - relinquish_p2m_mapping
  - p2m_clear_root_pages
Wrap XEN_DOMCTL_destroydomain-case transiently with CONFIG_MGMT_HYPERCALLS,
and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_destroydomain-case transiently
---
 xen/arch/arm/domain.c                 | 3 +++
 xen/arch/arm/include/asm/tee/tee.h    | 2 ++
 xen/arch/arm/mmu/p2m.c                | 4 ++++
 xen/arch/arm/mpu/p2m.c                | 2 ++
 xen/arch/arm/tee/ffa.c                | 4 ++++
 xen/arch/arm/tee/optee.c              | 4 ++++
 xen/arch/arm/tee/tee.c                | 2 ++
 xen/arch/x86/domain.c                 | 2 ++
 xen/arch/x86/emul-i8254.c             | 2 ++
 xen/arch/x86/mm/mem_sharing.c         | 2 ++
 xen/arch/x86/mm/p2m-pod.c             | 2 ++
 xen/arch/x86/mm/p2m.c                 | 2 ++
 xen/arch/x86/mm/paging.c              | 2 ++
 xen/common/domain.c                   | 2 ++
 xen/common/domctl.c                   | 2 +-
 xen/drivers/passthrough/device_tree.c | 2 ++
 xen/drivers/passthrough/pci.c         | 2 ++
 17 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 30ff9dac46..3e7f40ab01 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -995,6 +995,7 @@ int arch_vcpu_reset(struct vcpu *v)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int relinquish_memory(struct domain *d, struct page_list_head *list)
 {
     struct page_info *page, *tmp;
@@ -1145,6 +1146,8 @@ int domain_relinquish_resources(struct domain *d)
 
 #undef PROGRESS
 
+#endif /* CONFIG_MGMT_HYPERCALLS */
+
 void arch_dump_domain_info(struct domain *d)
 {
     p2m_dump_info(d);
diff --git a/xen/arch/arm/include/asm/tee/tee.h b/xen/arch/arm/include/asm/tee/tee.h
index 15d664e28d..f4187c5dc3 100644
--- a/xen/arch/arm/include/asm/tee/tee.h
+++ b/xen/arch/arm/include/asm/tee/tee.h
@@ -40,12 +40,14 @@ struct tee_mediator_ops {
     int (*domain_teardown)(struct domain *d);
     void (*free_domain_ctx)(struct domain *d);
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     /*
      * Called during domain destruction to relinquish resources used
      * by mediator itself. This function can return -ERESTART to indicate
      * that it does not finished work and should be called again.
      */
     int (*relinquish_resources)(struct domain *d);
+#endif
 
     /* Handle SMCCC call for current domain. */
     bool (*handle_call)(struct cpu_user_regs *regs);
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 51abf3504f..30d6071e91 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -1243,6 +1243,7 @@ static void p2m_invalidate_table(struct p2m_domain *p2m, mfn_t mfn)
     p2m->need_flush = true;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * The domain will not be scheduled anymore, so in theory we should
  * not need to flush the TLBs. Do it for safety purpose.
@@ -1262,6 +1263,7 @@ void p2m_clear_root_pages(struct p2m_domain *p2m)
 
     p2m_write_unlock(p2m);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Invalidate all entries in the root page-tables. This is
@@ -1556,6 +1558,7 @@ int p2m_init(struct domain *d)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * The function will go through the p2m and remove page reference when it
  * is required. The mapping will be removed from the p2m.
@@ -1626,6 +1629,7 @@ int relinquish_p2m_mapping(struct domain *d)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Clean & invalidate RAM associated to the guest vCPU.
diff --git a/xen/arch/arm/mpu/p2m.c b/xen/arch/arm/mpu/p2m.c
index f7fb58ab6a..c44297a9e3 100644
--- a/xen/arch/arm/mpu/p2m.c
+++ b/xen/arch/arm/mpu/p2m.c
@@ -57,10 +57,12 @@ bool p2m_resolve_translation_fault(struct domain *d, gfn_t gfn)
 
 void p2m_flush_vm(struct vcpu *v) {}
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int relinquish_p2m_mapping(struct domain *d)
 {
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void p2m_domain_creation_finished(struct domain *d) {}
 
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 1d0239cf69..f9ba9b60bf 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -469,10 +469,12 @@ static void ffa_free_domain_ctx(struct domain *d)
     XFREE(d->arch.tee);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int ffa_relinquish_resources(struct domain *d)
 {
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void ffa_init_secondary(void)
 {
@@ -623,7 +625,9 @@ static const struct tee_mediator_ops ffa_ops =
     .domain_init = ffa_domain_init,
     .domain_teardown = ffa_domain_teardown,
     .free_domain_ctx = ffa_free_domain_ctx,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .relinquish_resources = ffa_relinquish_resources,
+#endif
     .handle_call = ffa_handle_call,
 };
 
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 5151bd90ed..1ed0fd231d 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -632,6 +632,7 @@ static void free_optee_shm_buf_pg_list(struct optee_domain *ctx,
                  cookie);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int optee_relinquish_resources(struct domain *d)
 {
     struct arm_smccc_res resp;
@@ -693,6 +694,7 @@ static int optee_relinquish_resources(struct domain *d)
 
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 #define PAGELIST_ENTRIES_PER_PAGE                       \
     ((OPTEE_MSG_NONCONTIG_PAGE_SIZE / sizeof(u64)) - 1)
@@ -1727,7 +1729,9 @@ static const struct tee_mediator_ops optee_ops =
     .probe = optee_probe,
     .domain_init = optee_domain_init,
     .domain_teardown = optee_domain_teardown,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .relinquish_resources = optee_relinquish_resources,
+#endif
     .handle_call = optee_handle_call,
 };
 
diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
index 8501443c8e..a8e160700f 100644
--- a/xen/arch/arm/tee/tee.c
+++ b/xen/arch/arm/tee/tee.c
@@ -65,6 +65,7 @@ int tee_domain_teardown(struct domain *d)
     return cur_mediator->ops->domain_teardown(d);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int tee_relinquish_resources(struct domain *d)
 {
     if ( !cur_mediator )
@@ -72,6 +73,7 @@ int tee_relinquish_resources(struct domain *d)
 
     return cur_mediator->ops->relinquish_resources(d);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 uint16_t tee_get_type(void)
 {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5b3c5e8caf..314de75d8e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2298,6 +2298,7 @@ void sync_vcpu_execstate(struct vcpu *v)
            read_atomic(&v->dirty_cpu) != dirty_cpu);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int relinquish_memory(
     struct domain *d, struct page_list_head *list, unsigned long type)
 {
@@ -2622,6 +2623,7 @@ int domain_relinquish_resources(struct domain *d)
 
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void arch_dump_domain_info(struct domain *d)
 {
diff --git a/xen/arch/x86/emul-i8254.c b/xen/arch/x86/emul-i8254.c
index 144aa168a3..f106ab794c 100644
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -651,6 +651,7 @@ void pit_init(struct domain *d)
     pit_reset(d);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void pit_deinit(struct domain *d)
 {
     PITState *pit = domain_vpit(d);
@@ -664,6 +665,7 @@ void pit_deinit(struct domain *d)
         destroy_periodic_time(&pit->pt0);
     }
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4787b27964..d7cbf2047b 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1393,6 +1393,7 @@ int __mem_sharing_unshare_page(struct domain *d,
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int relinquish_shared_pages(struct domain *d)
 {
     int rc = 0;
@@ -1449,6 +1450,7 @@ int relinquish_shared_pages(struct domain *d)
     p2m_unlock(p2m);
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int range_share(struct domain *d, struct domain *cd,
                        struct mem_sharing_op_range *range)
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 05633fe2ac..4e915808f4 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -366,6 +366,7 @@ void p2m_pod_get_mem_target(const struct domain *d, xen_pod_target_t *target)
     pod_unlock(p2m);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int p2m_pod_empty_cache(struct domain *d)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -409,6 +410,7 @@ int p2m_pod_empty_cache(struct domain *d)
     unlock_page_alloc(p2m);
     return p2m->pod.count ? -ERESTART : 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int
 p2m_pod_offline_or_broken_hit(struct page_info *p)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e2a00a0efd..c1a87cde27 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2097,6 +2097,7 @@ int xenmem_add_to_physmap_one(
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * Remove foreign mappings from the p2m, as that drops the page reference taken
  * when mapped.
@@ -2160,6 +2161,7 @@ int relinquish_p2m_mapping(struct domain *d)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void p2m_log_dirty_range(struct domain *d, unsigned long begin_pfn,
                          unsigned long nr, uint8_t *dirty_bitmap)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 65455a6867..116389d4e9 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -768,6 +768,7 @@ void paging_vcpu_teardown(struct vcpu *v)
         shadow_vcpu_teardown(v);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* Call when destroying a domain */
 int paging_teardown(struct domain *d)
 {
@@ -794,6 +795,7 @@ int paging_teardown(struct domain *d)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* Call once all of the references to the domain have gone away */
 void paging_final_teardown(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 34e2e501dc..5d81ab3045 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1230,6 +1230,7 @@ int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int domain_kill(struct domain *d)
 {
     int rc = 0;
@@ -1280,6 +1281,7 @@ int domain_kill(struct domain *d)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 
 void __domain_crash(struct domain *d)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 278a00b141..0f20e8941b 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -488,7 +488,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 ret = -EFAULT;
         }
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_destroydomain:
         ret = domain_kill(d);
@@ -496,6 +495,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = hypercall_create_continuation(
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_setnodeaffinity:
     {
diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
index f5850a2607..015ffa15d4 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -108,6 +108,7 @@ int iommu_dt_domain_init(struct domain *d)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int iommu_release_dt_devices(struct domain *d)
 {
     const struct domain_iommu *hd = dom_iommu(d);
@@ -136,6 +137,7 @@ int iommu_release_dt_devices(struct domain *d)
 
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int iommu_dt_xlate(struct device *dev,
                           const struct dt_phandle_args *iommu_spec,
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 3edcfa8a04..cd855108c2 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -945,6 +945,7 @@ static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
     return ret;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int pci_release_devices(struct domain *d)
 {
     int combined_ret;
@@ -1003,6 +1004,7 @@ int pci_release_devices(struct domain *d)
 
     return combined_ret;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 #define PCI_CLASS_BRIDGE_HOST    0x0600
 #define PCI_CLASS_BRIDGE_PCI     0x0604
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117664.1463755 (Exim 4.92)
	(envelope-from )
	id 1uwFWl-0004RL-P5; Wed, 10 Sep 2025 07:46:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117664.1463755; Wed, 10 Sep 2025 07: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 1uwFWl-0004RE-MA; Wed, 10 Sep 2025 07:46:03 +0000
Received: by outflank-mailman (input) for mailman id 1117664;
 Wed, 10 Sep 2025 07: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 1uwFRG-0005yo-Qx
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:22 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20608.outbound.protection.outlook.com
 [2a01:111:f403:2417::608])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 66ce359c-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:40:20 +0200 (CEST)
Received: from BYAPR11CA0082.namprd11.prod.outlook.com (2603:10b6:a03:f4::23)
 by IA0PR12MB8645.namprd12.prod.outlook.com (2603:10b6:208:48f::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:40:15 +0000
Received: from SN1PEPF0002529E.namprd05.prod.outlook.com
 (2603:10b6:a03:f4:cafe::91) by BYAPR11CA0082.outlook.office365.com
 (2603:10b6:a03:f4::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.22 via Frontend Transport; Wed,
 10 Sep 2025 07:40:14 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF0002529E.mail.protection.outlook.com (10.167.242.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:40:14 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:40:04 -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: 66ce359c-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ps8wEh1u+KGi+t09RPAtHWmZRRNbgiW4Z+dWSJbExQRZL8APK6owBNqnFi3XfBYPxeSeMyUcpLzeIuOog7js9yuR8ClvmBaFumu5vp8zLeMEju7vQIk4Wbh6ph6RLaeke8DbIFPz3tTND79cvgKOrUWF7BkM19FgnmbP+m9KXEvzGALNJAxDYcnF+TJuLRgiS/Tdf1QRcxY0n3OgB1LoEB6q9aGWLvrg8reY7eCx89F51gbctUcCmE1BOFxKp0F/GZXvPJ8XZ6vXUSHaDndRY5nx/OMrwaeflYUued1ogBsn5VTQfSAE0ZHrdalJ2swZb/Svuopvt+mbcj+W9OA8CQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hWuX102tq8N0iGW1Xc/rVxB+j69uluf4R+r4Cnb/XwU=;
 b=iKv5W3CgikRHbc9XWII0F+gSF9sZDdLpHgqYlepAsVROQQRaMHhGfjxpYj/tZvIxNs9YDEAusjY9v4AvgF/jZ3OVA6reZaGv6wSDF4YBk+CIOvFVbRoWB6N/uOC8FqT15U8JIKOiJdhkz0NDG7QhgoYPwAiWjpLz1VxPXmLm0ImcFUAXD8eBesDhDCBoZdt/rQCyJOOKpU+KrJpkYV1zZtr5LWioTnGUCT7y1716EzmW6DWwFkx8lq3Gkq1qz1ydRtYbOsz04GLJQvCZRkLPoK3DuronUBANdcEsP/Wn1Kz2Ed59KvRoew4nQcrBiSmoni8R/nn3QGmN2W5MJBQzzQ==
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=hWuX102tq8N0iGW1Xc/rVxB+j69uluf4R+r4Cnb/XwU=;
 b=fvGfr/0tX9Uz3aOqC9LAhPG8N5q8lc1dak5VQgBM8u81m+OlmV7Ltqh0eXbYWYt4zf80zj668sSN+B47eUWmEur4teh8FmhdxyV6LZnRtAFe0D7dn/37adQolkEUfXMFfTdZNQa5ZlSeBZC5SJGmtDb2tGwD1wRS2tIxBrJUDpk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	
Subject: [PATCH v2 25/26] xen/xsm: wrap xsm functions with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:26 +0800
Message-ID: <20250910073827.3622177-26-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002529E:EE_|IA0PR12MB8645:EE_
X-MS-Office365-Filtering-Correlation-Id: e8af2545-45c3-4072-4ecb-08ddf03d47d2
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?uYgqoPTuaLZ9fVwkGZSjOlr9byLe1Bzai8rMquUZPLD5J4ILNARx2aAMfCsI?=
 =?us-ascii?Q?7vIhOjaPGFdZUNgh8dj0TH8t9+9wCiqMP43ZjeOB7ztVfJOiYOcRZIUPbrCA?=
 =?us-ascii?Q?mY/+CRhzxw6CwQ3WWKd7e4dTglB4jq6qJl0yVNCTjKtwVOVWwnnVEvCfIDFy?=
 =?us-ascii?Q?NrLPipS+QpZHyEaykhfLV0DIlAO57KiFmJxjRRlATQhR/syWoDOaEBTkvkEm?=
 =?us-ascii?Q?yu2dyyWL3mH7SyZKc0tLO+Cc2NaqqWjONqkWsw+TAybXSSYOQchy6ZV3fFnB?=
 =?us-ascii?Q?NCwDk7syRnpx+HUJWgk9cvCOK2E0yt7WFIO4toaBdHZKQF9SMTGXBgPy+s8c?=
 =?us-ascii?Q?I+TZWQQ7//nGOcAeJZQUjL5V9ENqlp+rOugpPB00vzZnPFvVZM8a7S2AcOzu?=
 =?us-ascii?Q?KHMXw4E1xBS0TOFpKidyr9sQ/FhpeMNy3m9s2ttEcYJJOBagYp2JHTIAiLbm?=
 =?us-ascii?Q?oaJBDSqq6R53Ko9wLRImQA5O8FoInWTY+qVYf8PwnNJ7ZNEzyUOKY8BpR50j?=
 =?us-ascii?Q?mXxndP4IrpurepQ1DW082mhOSKHUBKUL7FBvYIjv/Ux7hJqPMm2Er8N+IYpj?=
 =?us-ascii?Q?xphy8GxwO2YoFElrN98+6/5KaEDCM119ON/EtT5f1GOTBFo+73NzEAMr/sG2?=
 =?us-ascii?Q?AIHzOVEm/YV2eaX1mz+3ReQGr/PiEjyPdWOb4Kd+IZYwZ0VLd9j3JJw5lmBe?=
 =?us-ascii?Q?N/vUMp5fO2BrOEReFymZyTRWg426xXnDEmBKkbWn5KRZu/rKx4qD/qRnGLp4?=
 =?us-ascii?Q?QMUVgjy+jERryBQIfvlDNb9CoKcZxU527WGoCpjWdi/VbxMNxPZ2znM3Dyub?=
 =?us-ascii?Q?nDdm/bhnYMN9s5TqDAHRM1vhubBKfpxyWgD6q+ivorxX2guU8Uzfxq+GTnJ7?=
 =?us-ascii?Q?zfr1QEl9Br5KvXn7IvWSV/e99sHBPOmEQw6Dn5XGanuuDJlDqiWEQWT7MZJd?=
 =?us-ascii?Q?qiLJU+P/tBBVxGUyDqRGqWMANhSe8ISSS6cDFIhqFPPj+McxMLsoKCH5Hm8P?=
 =?us-ascii?Q?zCu/jge+NjK5QCNWVGn+DThzwtQ5/SdGp9duuOqlm1A1sfvFevVBGQ7UTn58?=
 =?us-ascii?Q?XSTUrBZG+QpQpJoeRcOxYu6wrwlkcpnnlvErr8nBhqvnWbYh2KK/nE6HByvH?=
 =?us-ascii?Q?NpBrYmjSqqeWzyt3DyeATZmFEUw3eIW7InNxU/Mlo5mnFxQBQRTs8M5fuBXR?=
 =?us-ascii?Q?Isy79lE/kWwDt3c1OlaQR6VwF1dOaErBdunK46I1+df8NERKndf9xsSSoxzP?=
 =?us-ascii?Q?/16ZgSroMy8HHWrvso3xRqMqt/0sQCIE7URYY+XjDXAanh8Eprv240qKVe9Q?=
 =?us-ascii?Q?zABGHlusZggs1QeMEwU18iiAj6nxsSWj92Y2IJ7Eki/7O39Yed0lODc4h2fY?=
 =?us-ascii?Q?SjMgOZhsZncuGWUrurKl8xaySIeWyNo6Azm2M22Mq2Jt252C5RYSoe2BshC0?=
 =?us-ascii?Q?GBMOl5hjPyoQ8cUCRFrDlVS0Psaug6YHNlpemonARu8zgYrCOTZkZVCfhKry?=
 =?us-ascii?Q?brB9eocZf8nbXMgwz2x0fL8WGLISz4jSg+Db?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:40:14.4513
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e8af2545-45c3-4072-4ecb-08ddf03d47d2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002529E.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8645

The following functions are xsm-related and only invoked under arch-specific
domctl-op, so they shall all be wrapped with CONFIG_MGMT_HYPERCALLS:
- xsm_domctl
- xsm_{bind,unbind}_pt_irq
- xsm_ioport_permission
- xsm_ioport_mapping

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- new commit
---
 xen/include/xsm/xsm.h | 14 ++++++++++++--
 xen/xsm/dummy.c       |  6 +++---
 xen/xsm/flask/hooks.c | 12 ++++++------
 3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 542488bd44..0539e3bf10 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -60,8 +60,8 @@ struct xsm_ops {
     int (*domctl_scheduler_op)(struct domain *d, int op);
     int (*sysctl_scheduler_op)(int op);
     int (*set_target)(struct domain *d, struct domain *e);
-#endif
     int (*domctl)(struct domain *d, unsigned int cmd, uint32_t ssidref);
+#endif
     int (*sysctl)(int cmd);
     int (*readconsole)(uint32_t clear);
 
@@ -111,9 +111,9 @@ struct xsm_ops {
     int (*map_domain_irq)(struct domain *d, int irq, const void *data);
     int (*unmap_domain_pirq)(struct domain *d);
     int (*unmap_domain_irq)(struct domain *d, int irq, const void *data);
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*bind_pt_irq)(struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq)(struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-#ifdef CONFIG_MGMT_HYPERCALLS
     int (*irq_permission)(struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission)(struct domain *d, uint64_t s, uint64_t e,
                             uint8_t allow);
@@ -190,10 +190,12 @@ struct xsm_ops {
     int (*update_va_mapping)(struct domain *d, struct domain *f,
                              l1_pgentry_t pte);
     int (*priv_mapping)(struct domain *d, struct domain *t);
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*ioport_permission)(struct domain *d, uint32_t s, uint32_t e,
                              uint8_t allow);
     int (*ioport_mapping)(struct domain *d, uint32_t s, uint32_t e,
                           uint8_t allow);
+#endif
     int (*pmu_op)(struct domain *d, unsigned int op);
 #endif
     int (*dm_op)(struct domain *d);
@@ -272,7 +274,11 @@ static inline int xsm_set_target(
 static inline int xsm_domctl(xsm_default_t def, struct domain *d,
                              unsigned int cmd, uint32_t ssidref)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.domctl, d, cmd, ssidref);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_sysctl(xsm_default_t def, int cmd)
@@ -503,6 +509,7 @@ static inline int xsm_unmap_domain_irq(
     return alternative_call(xsm_ops.unmap_domain_irq, d, irq, data);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int xsm_bind_pt_irq(
     xsm_default_t def, struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
@@ -514,6 +521,7 @@ static inline int xsm_unbind_pt_irq(
 {
     return alternative_call(xsm_ops.unbind_pt_irq, d, bind);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static inline int xsm_irq_permission(
     xsm_default_t def, struct domain *d, int pirq, uint8_t allow)
@@ -757,6 +765,7 @@ static inline int xsm_priv_mapping(
     return alternative_call(xsm_ops.priv_mapping, d, t);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int xsm_ioport_permission(
     xsm_default_t def, struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
@@ -768,6 +777,7 @@ static inline int xsm_ioport_mapping(
 {
     return alternative_call(xsm_ops.ioport_mapping, d, s, e, allow);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static inline int xsm_pmu_op(
     xsm_default_t def, struct domain *d, unsigned int op)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 2c8e0725b6..48ed724f86 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -22,9 +22,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .domctl_scheduler_op           = xsm_domctl_scheduler_op,
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
     .set_target                    = xsm_set_target,
-#endif
     .domctl                        = xsm_domctl,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl                        = xsm_sysctl,
     .readconsole                   = xsm_readconsole,
 #endif
@@ -71,9 +69,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .map_domain_irq                = xsm_map_domain_irq,
     .unmap_domain_pirq             = xsm_unmap_domain_pirq,
     .unmap_domain_irq              = xsm_unmap_domain_irq,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .bind_pt_irq                   = xsm_bind_pt_irq,
     .unbind_pt_irq                 = xsm_unbind_pt_irq,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .irq_permission                = xsm_irq_permission,
     .iomem_permission              = xsm_iomem_permission,
 #endif
@@ -143,8 +141,10 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .mmuext_op                     = xsm_mmuext_op,
     .update_va_mapping             = xsm_update_va_mapping,
     .priv_mapping                  = xsm_priv_mapping,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .ioport_permission             = xsm_ioport_permission,
     .ioport_mapping                = xsm_ioport_mapping,
+#endif
     .pmu_op                        = xsm_pmu_op,
 #endif
     .dm_op                         = xsm_dm_op,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 66d8bfda3a..76bf1b5240 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -665,7 +665,6 @@ static int cf_check flask_set_target(struct domain *d, struct domain *t)
                                  &dsec->target_sid);
     return rc;
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
                                  uint32_t ssidref)
@@ -858,7 +857,6 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     }
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_sysctl(int cmd)
 {
     switch ( cmd )
@@ -1078,6 +1076,7 @@ static int cf_check flask_unmap_domain_irq(
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_bind_pt_irq(
     struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
@@ -1111,7 +1110,6 @@ static int cf_check flask_unbind_pt_irq(
     return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_irq_permission(
     struct domain *d, int pirq, uint8_t access)
 {
@@ -1634,6 +1632,7 @@ static int cf_check flask_shadow_control(struct domain *d, uint32_t op)
     return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 struct ioport_has_perm_data {
     uint32_t ssid;
     uint32_t dsid;
@@ -1689,6 +1688,7 @@ static int cf_check flask_ioport_mapping(
 {
     return flask_ioport_permission(d, start, end, access);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check flask_mem_sharing_op(
     struct domain *d, struct domain *cd, int op)
@@ -1894,9 +1894,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
-#endif
     .domctl = flask_domctl,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl = flask_sysctl,
     .readconsole = flask_readconsole,
 #endif
@@ -1943,9 +1941,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .map_domain_irq = flask_map_domain_irq,
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .unmap_domain_irq = flask_unmap_domain_irq,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .bind_pt_irq = flask_bind_pt_irq,
     .unbind_pt_irq = flask_unbind_pt_irq,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
 #endif
@@ -2016,8 +2014,10 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .priv_mapping = flask_priv_mapping,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .ioport_permission = flask_ioport_permission,
     .ioport_mapping = flask_ioport_mapping,
+#endif
     .pmu_op = flask_pmu_op,
 #endif
     .dm_op = flask_dm_op,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117671.1463765 (Exim 4.92)
	(envelope-from )
	id 1uwFWo-0004ih-W5; Wed, 10 Sep 2025 07:46:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117671.1463765; Wed, 10 Sep 2025 07: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 1uwFWo-0004iY-Sq; Wed, 10 Sep 2025 07:46:06 +0000
Received: by outflank-mailman (input) for mailman id 1117671;
 Wed, 10 Sep 2025 07:46: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 1uwFR1-0005yo-5D
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:07 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20630.outbound.protection.outlook.com
 [2a01:111:f403:2409::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5ac635c2-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:40:00 +0200 (CEST)
Received: from SA1P222CA0042.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2d0::16)
 by CH1PR12MB9720.namprd12.prod.outlook.com (2603:10b6:610:2b2::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:55 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:806:2d0:cafe::a4) by SA1P222CA0042.outlook.office365.com
 (2603:10b6:806:2d0::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Wed,
 10 Sep 2025 07:39:55 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:55 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:51 -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: 5ac635c2-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OU0H91HF6Ua+E/82kCav35yGWM/O9FArr2e01xAMpp6nrks1Zoui1rG84cdvj7Spb/Y6eCacSDjt6XHPhUyUhT4aZnhbRpqSyJr5ygrRjIKMOpoDaSNqlxwefXz9cg0LSs9qzroeAo52JHSULrrJGvLvk/EdVYo5Pws3SMd8yRCX+jnlNIdOPmaW6vwvq5DUx19hJs1iA3NUy/sLfRUtIvkvuFdVg+Y2gOMTVSYTYqW8vOOQ03trX9DphskyM+5fVip/Q2cUy+qsMQXjn2FkgoVUsKbbAqShA8MjGNbj/0s7uZp+CCWLOwZyp9daPeiaIOT3widijjGoBOBQ1qRX6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jW923e2M3GzF3ljplSHb2j/zzkbSspIlyd89Yjzbzwo=;
 b=rujnfxTKthQG75Ura5YjFW9LFY6mEZSleZhS3OFzLZImq6T0usY/xEF3mEzo73JMoXbbQXo6bFYZHe+qA58ZOWNAK9pyVCbO9VKLWDDQzcnDpqUAllI7yQzDqUlsL/6cLPAnYEkqle3Jwou0gmAv9y+CUqiwg0DwBAAAitu1bA+40/JsGdXOBS75jfgK1QC9a9cj8dKQ+JCw+5ZZnODwsqicJD9+vxufwQ8d99GS0AfxgnEphfCdcCqm6nVNKYUg7JNdGmV+UhNRNN/r0QCWIOBhfUfb7oK1MVM0B/NWcR17tXqosRHokoMd9zO/EpKa4B0IZddpjAhcaezxWVq6tA==
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=jW923e2M3GzF3ljplSHb2j/zzkbSspIlyd89Yjzbzwo=;
 b=QdwvlenUwEWgaQjxur6h5UoJLhQgI8TQ5yaI8hqhuLyIOpqdmcxPyOViWcaGJk4UlrGq24CCIFOFNBspDrJiukDpJcutuwngmsMU7JoHyLdrDRK3YGxf77q/rNHsYHbVpZ/5gnlz0/HDqp3Uwf0xo+d8OHI24ZXuHdN7K2Hp5PE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Andrew
 Cooper" , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Volodymyr
 Babchuk" , Rahul Singh 
Subject: [PATCH v2 20/26] xen/domctl: wrap iommu-related domctl op with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:21 +0800
Message-ID: <20250910073827.3622177-21-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|CH1PR12MB9720:EE_
X-MS-Office365-Filtering-Correlation-Id: d7651a22-fe8b-4a97-f6a6-08ddf03d3c3e
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?otpdfLhyKYa7lrIOKNubZg58mEhy15hYbv4gwS0yGffMjFVNZlivS1B/0qvu?=
 =?us-ascii?Q?hw6A3zMreK5aSUQzg/TwowuCmGHxHan9B/qzcx6NpSYRRN4ZB4GJZi9niLop?=
 =?us-ascii?Q?MYPubV3Tjuct+zwDqlSWmtJacfNprcwjXgLNv9bgngdtycYxnPwd1cMI4uPw?=
 =?us-ascii?Q?nKdTggiGPpx3zyRQ8QXi2rGznFS/QwI1pPOV6kyzyCGKeEhkP8yIG1Y6/y1F?=
 =?us-ascii?Q?0JgitxrymVuEykCXTGaIErw62BQPQpv3dTSyMazRh3msGhExk2BnT6VO9rfT?=
 =?us-ascii?Q?2iQfZPVcexH91lTqHU2yCTc0lLcPWLy7d8Hui6Nd+8ICyLZS5eE9hr9+bCBM?=
 =?us-ascii?Q?eAJJphYPo/kD1ZGuLVNo91Dg2l0143Jd3StPiQSBWeVbGJK1Qjj82hLIh6wS?=
 =?us-ascii?Q?23EPjhdbKcU1RnsfTnr875KKh3EaXHrVOK4OEZt0oqxd3A+dgc7JLkpFxK9y?=
 =?us-ascii?Q?LaNmo5VHcMYh6wFwP+MKRsgbufxlid28A4Yo1dcC3+3MjSnijHRhlFY9bQZ8?=
 =?us-ascii?Q?RgztQAln6I163FmDyDe35Q0lTGqfVUB7IuC3y7QIHyXoP7/FTO+Gl2F0kVvH?=
 =?us-ascii?Q?+euwAhrJqNjzzciNvRM14ncLQE1WC1V9AmWc3U5QcPJpE5U3o4u6cOt9thMv?=
 =?us-ascii?Q?TpwVqelc5ToBo4eJFuK+3/nXSKoPFLXJQTdWqCCPkuQ/u26/pzDk/FsswL4+?=
 =?us-ascii?Q?KlKRjYw1KJWAvcTk3ZtbqQbdCVzx1duvOqaVjrB8jowmBlk0fcBNFmlltSRX?=
 =?us-ascii?Q?gNUmTjJaOwOM+iIgI+6T0mq+KMcXLe5/QMxn3nf8XRqyibQ3KphqjKK5hTGf?=
 =?us-ascii?Q?qVOsStNrGzbwAk8oHemERIenE80HlN4S+YQDdgfUxn5BIe+i7HCLMLk/g0Dw?=
 =?us-ascii?Q?TcUPmUVHlYHTupTHjcOB4vh93CKyF/LviC+cuVPdLz08fo9q5kL8mPj+bS+I?=
 =?us-ascii?Q?m5nxxY1aO8vb6GGN4zDZx+N5c03aw9LnGVqN/A/hVkf3q1d5V1kglvwGZwOU?=
 =?us-ascii?Q?foi93AhGKd21f+uWODEN+oSbFMIIDRwNqC9NBIBAYqJZENQctXyYejKNIfUV?=
 =?us-ascii?Q?wti9FDChoV4WuClElBdbdmM7TGeHjf4YXS9o+0gMQqLxnWQASf+oG5qOfZoP?=
 =?us-ascii?Q?CA04mWQixIuxiwud7zKVssiNfYwP1qK7IY2lNp6ZV69Dkem7Wr2vWiDcGkVB?=
 =?us-ascii?Q?aTtQil0hmByi7VqyuA52DMKUI6xMYAki6pLuhvT2K6dFtGvC5kgfjxqZhR/2?=
 =?us-ascii?Q?W852tHcfXGHVGFlWZdnbWALDqGtQ0VX4NIdG0bT1YVLVkQgYu3WBHM9MuGl9?=
 =?us-ascii?Q?Ln91FrhobHVoJ59gO8BsGqXNIXYuhOMPJnVar8VtaWsAe42zMGdcmROlG3dv?=
 =?us-ascii?Q?3XZoEho2ICBFbE7bF0QZPrhB/x/qoLmbjsZU2qoDQt2MIokHyMtWyglwixhC?=
 =?us-ascii?Q?55e4ZRux9aZXvWO89NMUc3KQQpoE0wtVnMqD1qGlNgU02V0lOdRMKl0pRPkz?=
 =?us-ascii?Q?qDsSJQLLrNQgA/F0+oaeLGpcK0yWod1RiEtF?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:55.0176
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d7651a22-fe8b-4a97-f6a6-08ddf03d3c3e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9720

Function iommu_do_domctl() is the main entry for all iommu-related domctl-op,
and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
Tracking its calling chain, the following functions shall all be wrapped
with CONFIG_MGMT_HYPERCALLS:
- iommu_do_pci_domctl
  - iommu_get_device_group
    - amd_iommu_group_id/intel_iommu_group_id
  - device_assigned
  - assign_device
    - intel_iommu_assign_device/amd_iommu_assign_device
  - deassign_device
    - reassign_device_ownership/reassign_device
- iommu_do_dt_domctl
  - iommu_deassign_dt_device
    - arm_smmu_reassign_dev/arm_smmu_reassign_dev
    - ipmmu_reassign_dev
      - ipmmu_deassign_dev
        - ipmmu_detach_dev
  - dt_find_node_by_gpath
Wrap XEN_DOMCTL_assign_device{test_assign_device,deassign_device,
get_device_group}-case transiently with CONFIG_MGMT_HYPERCALLS,
and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the whole
domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_assign_device{test_assign_device,deassign_device,
 get_device_group}-case transiently
---
 xen/common/device-tree/device-tree.c        | 2 ++
 xen/common/domctl.c                         | 2 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c | 8 ++++++++
 xen/drivers/passthrough/arm/ipmmu-vmsa.c    | 6 ++++++
 xen/drivers/passthrough/arm/smmu-v3.c       | 4 ++++
 xen/drivers/passthrough/arm/smmu.c          | 4 ++++
 xen/drivers/passthrough/device_tree.c       | 4 ++++
 xen/drivers/passthrough/iommu.c             | 2 ++
 xen/drivers/passthrough/pci.c               | 6 +++++-
 xen/drivers/passthrough/vtd/iommu.c         | 6 ++++++
 10 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 0b5375f151..70bd8e7da5 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -371,6 +371,7 @@ struct dt_device_node *dt_find_node_by_path_from(struct dt_device_node *from,
     return np;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int dt_find_node_by_gpath(XEN_GUEST_HANDLE(char) u_path, uint32_t u_plen,
                           struct dt_device_node **node)
 {
@@ -386,6 +387,7 @@ int dt_find_node_by_gpath(XEN_GUEST_HANDLE(char) u_path, uint32_t u_plen,
 
     return (*node == NULL) ? -ESRCH : 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 struct dt_device_node *dt_find_node_by_alias(const char *alias)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 736ad52265..d36885aeea 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -840,12 +840,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             copyback = 1;
         break;
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_assign_device:
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_deassign_device:
     case XEN_DOMCTL_get_device_group:
         ret = iommu_do_domctl(op, d, u_domctl);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_get_paging_mempool_size:
         ret = arch_get_paging_mempool_size(d, &op->u.paging_mempool.size);
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 3a14770855..5786bf0c59 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -461,6 +461,7 @@ static void amd_iommu_disable_domain_device(const struct domain *domain,
         spin_unlock_irqrestore(&iommu->lock, flags);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check reassign_device(
     struct domain *source, struct domain *target, u8 devfn,
     struct pci_dev *pdev)
@@ -550,6 +551,7 @@ static int cf_check amd_iommu_assign_device(
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check amd_iommu_clear_root_pgtable(struct domain *d)
 {
@@ -698,12 +700,14 @@ static int cf_check amd_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)
 {
     unsigned int bdf = PCI_BDF(bus, devfn);
 
     return (bdf < ivrs_bdf_entries) ? get_dma_requestor_id(seg, bdf) : bdf;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 #include 
 
@@ -772,14 +776,18 @@ static const struct iommu_ops __initconst_cf_clobber _iommu_ops = {
     .quarantine_init = amd_iommu_quarantine_init,
     .add_device = amd_iommu_add_device,
     .remove_device = amd_iommu_remove_device,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .assign_device  = amd_iommu_assign_device,
+#endif
     .teardown = amd_iommu_domain_destroy,
     .clear_root_pgtable = amd_iommu_clear_root_pgtable,
     .map_page = amd_iommu_map_page,
     .unmap_page = amd_iommu_unmap_page,
     .iotlb_flush = amd_iommu_flush_iotlb_pages,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .reassign_device = reassign_device,
     .get_device_group_id = amd_iommu_group_id,
+#endif
     .enable_x2apic = iov_enable_xt,
     .update_ire_from_apic = amd_iommu_ioapic_update_ire,
     .update_ire_from_msi = amd_iommu_msi_msg_update_ire,
diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
index ea9fa9ddf3..ec85b2fbdd 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -739,6 +739,7 @@ static int ipmmu_attach_device(struct ipmmu_vmsa_domain *domain,
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static void ipmmu_detach_device(struct ipmmu_vmsa_domain *domain,
                                 struct device *dev)
 {
@@ -748,6 +749,7 @@ static void ipmmu_detach_device(struct ipmmu_vmsa_domain *domain,
     for ( i = 0; i < fwspec->num_ids; ++i )
         ipmmu_utlb_disable(domain, fwspec->ids[i]);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int ipmmu_init_platform_device(struct device *dev,
                                       const struct dt_phandle_args *args)
@@ -1254,6 +1256,7 @@ out:
     return ret;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int ipmmu_deassign_device(struct domain *d, struct device *dev)
 {
     struct ipmmu_vmsa_xen_domain *xen_domain = dom_iommu(d)->arch.priv;
@@ -1309,6 +1312,7 @@ static int ipmmu_reassign_device(struct domain *s, struct domain *t,
 
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int ipmmu_dt_xlate(struct device *dev,
                           const struct dt_phandle_args *spec)
@@ -1487,7 +1491,9 @@ static const struct iommu_ops ipmmu_iommu_ops =
     .teardown        = ipmmu_iommu_domain_teardown,
     .iotlb_flush     = ipmmu_iotlb_flush,
     .assign_device   = ipmmu_assign_device,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .reassign_device = ipmmu_reassign_device,
+#endif
     .map_page        = arm_iommu_map_page,
     .unmap_page      = arm_iommu_unmap_page,
     .dt_xlate        = ipmmu_dt_xlate,
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c
index bf153227db..49cd37ff57 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -2799,6 +2799,7 @@ static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn, struct device
 	return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
 				u8 devfn,  struct device *dev)
 {
@@ -2826,6 +2827,7 @@ static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
 
 	return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int arm_smmu_iommu_xen_domain_init(struct domain *d)
 {
@@ -2862,7 +2864,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = {
 	.teardown		= arm_smmu_iommu_xen_domain_teardown,
 	.iotlb_flush		= arm_smmu_iotlb_flush,
 	.assign_device		= arm_smmu_assign_dev,
+#ifdef CONFIG_MGMT_HYPERCALLS
 	.reassign_device	= arm_smmu_reassign_dev,
+#endif
 	.map_page		= arm_iommu_map_page,
 	.unmap_page		= arm_iommu_unmap_page,
 	.dt_xlate		= arm_smmu_dt_xlate,
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 22d306d0cb..b7f01fbf89 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2891,6 +2891,7 @@ static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
 	return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
 				 u8 devfn,  struct device *dev)
 {
@@ -2918,6 +2919,7 @@ static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
 
 	return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int arm_smmu_iommu_domain_init(struct domain *d)
 {
@@ -2956,7 +2958,9 @@ static const struct iommu_ops arm_smmu_iommu_ops = {
     .teardown = arm_smmu_iommu_domain_teardown,
     .iotlb_flush = arm_smmu_iotlb_flush,
     .assign_device = arm_smmu_assign_dev,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .reassign_device = arm_smmu_reassign_dev,
+#endif
     .map_page = arm_iommu_map_page,
     .unmap_page = arm_iommu_unmap_page,
     .dt_xlate = arm_smmu_dt_xlate_generic,
diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
index 015ffa15d4..5c2122ba9f 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -59,6 +59,7 @@ fail:
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int iommu_deassign_dt_device(struct domain *d, struct dt_device_node *dev)
 {
     const struct domain_iommu *hd = dom_iommu(d);
@@ -86,6 +87,7 @@ fail:
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static bool iommu_dt_device_is_assigned_locked(const struct dt_device_node *dev)
 {
@@ -320,6 +322,7 @@ int iommu_add_dt_device(struct dt_device_node *np)
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
                        XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
@@ -431,3 +434,4 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
 
     return ret;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index c9425d6971..8812e38174 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -625,6 +625,7 @@ void iommu_resume(void)
         iommu_vcall(iommu_get_ops(), resume);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int iommu_do_domctl(
     struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
@@ -645,6 +646,7 @@ int iommu_do_domctl(
 
     return ret;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void iommu_crash_shutdown(void)
 {
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index cd855108c2..aa07a7e748 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -877,6 +877,7 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
     return ret;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* Caller should hold the pcidevs_lock */
 static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
                            uint8_t devfn)
@@ -945,7 +946,6 @@ static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
     return ret;
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 int pci_release_devices(struct domain *d)
 {
     int combined_ret;
@@ -1483,6 +1483,7 @@ static int iommu_remove_device(struct pci_dev *pdev)
     return iommu_call(hd->platform_ops, remove_device, devfn, pci_to_dev(pdev));
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int device_assigned(u16 seg, u8 bus, u8 devfn)
 {
     struct pci_dev *pdev;
@@ -1646,6 +1647,7 @@ static int iommu_get_device_group(
 
     return i;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void iommu_dev_iotlb_flush_timeout(struct domain *d, struct pci_dev *pdev)
 {
@@ -1671,6 +1673,7 @@ void iommu_dev_iotlb_flush_timeout(struct domain *d, struct pci_dev *pdev)
     pcidevs_unlock();
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int iommu_do_pci_domctl(
     struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
@@ -1804,6 +1807,7 @@ int iommu_do_pci_domctl(
 
     return ret;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 struct segment_iter {
     int (*handler)(struct pci_dev *pdev, void *arg);
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index b4105163cc..8913dd4d5f 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2731,6 +2731,7 @@ static int __init cf_check vtd_setup(void)
     return ret;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check reassign_device_ownership(
     struct domain *source,
     struct domain *target,
@@ -2926,6 +2927,7 @@ static int cf_check intel_iommu_group_id(u16 seg, u8 bus, u8 devfn)
 
     return PCI_BDF(bus, devfn);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int __must_check cf_check vtd_suspend(void)
 {
@@ -3234,14 +3236,18 @@ static const struct iommu_ops __initconst_cf_clobber vtd_ops = {
     .add_device = intel_iommu_add_device,
     .enable_device = intel_iommu_enable_device,
     .remove_device = intel_iommu_remove_device,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .assign_device  = intel_iommu_assign_device,
+#endif
     .teardown = iommu_domain_teardown,
     .clear_root_pgtable = iommu_clear_root_pgtable,
     .map_page = intel_iommu_map_page,
     .unmap_page = intel_iommu_unmap_page,
     .lookup_page = intel_iommu_lookup_page,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .reassign_device = reassign_device_ownership,
     .get_device_group_id = intel_iommu_group_id,
+#endif
     .enable_x2apic = intel_iommu_enable_eim,
     .disable_x2apic = intel_iommu_disable_eim,
     .update_ire_from_apic = io_apic_write_remap_rte,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117673.1463774 (Exim 4.92)
	(envelope-from )
	id 1uwFWr-0004z9-A1; Wed, 10 Sep 2025 07:46:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117673.1463774; Wed, 10 Sep 2025 07:46: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 1uwFWr-0004z2-7C; Wed, 10 Sep 2025 07:46:09 +0000
Received: by outflank-mailman (input) for mailman id 1117673;
 Wed, 10 Sep 2025 07:46: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 1uwFR4-0005yt-N5
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:10 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2009::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60d28b3f-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:40:09 +0200 (CEST)
Received: from SA1P222CA0050.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2d0::25)
 by IA1PR12MB6115.namprd12.prod.outlook.com (2603:10b6:208:3e9::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:40:05 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:806:2d0:cafe::e6) by SA1P222CA0050.outlook.office365.com
 (2603:10b6:806:2d0::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:40:03 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:40:05 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:59 -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: 60d28b3f-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uRICTrNU67ZZpg+NMZAoAEAty63a7dMpNWSparigDqIak/bGRTuMFmtBZADeIYeP9xoknkWhGufme7DFQQrA7nbJJDniNDl80CqX6pgPCYFS0S03ERjsZWtvaWtZGdLVKK32Yu6D9K0fpXt09bNFDEu9Uv4PEw5XFFY6u4Eb4Kz7zO2At0lLvAR6q3qBUKFr46Fgmk+z62MgpLuzKdxO3wlX0RV2KQy0BiCszYeUO7CVF3Cfjp4srjgnLZaoILUDUcQO89OvAiZ6iQ4/0lw2QmGXB4yqQzaNAie2qlrjO3zgeoTe7XYtqOblFGcjncdMathPq60Nx5NmH1g5L6/BJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/tKDNAZvqvuPmF10rFrm9o444l6QmZ2SjcvG0/5ayxc=;
 b=WZV6A6I1IFfZC6biKICiGX8FS8RrZoUDNY59OgPAWAsGwgdjN8bgSUs1MOkb8vwJc7DZ5vkZprYwNur6/YEa5yJZvxTF6SSdlLCkVb144N9U3vyr3O5wth4kcTuPd7xfXIoCyCZkD6Rl7J3aS3aihKTEhWyOB+dtTYi4Kd7nFLaytFBg1l4v6bpPgzMzegi3miNmfEibWwaFGCtdQQ0/H4mgSjXqTLbcTTN4TfJaIXDS/qb5nWvnKODp7NCaVmzuI+ODVmApZLc92n4i3P6NQi7XUcogTOboDQC/MNMSsoOlW4xinxxg42JQmI2ZzRQUffrEqZ37yyjKTx8IyWEgMw==
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=/tKDNAZvqvuPmF10rFrm9o444l6QmZ2SjcvG0/5ayxc=;
 b=s0iZflX9s3YyVO20yYjbrYOgX8GXitBswvZzPDZvykYxD5s4W6pWnH0duK1DrFNK5BDqm3KWsIPeq9r7tW3yTg2XkiRV0BZA8H61ShHox2y8vIOUs9a9PrBqzxKJgNzBYpxsB1tJqZU6eoWlHCAiRRKeVJWI5Uo9K9xdymR/2lk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 23/26] xen/x86: make CONFIG_X86_PSR depend on CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:24 +0800
Message-ID: <20250910073827.3622177-24-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|IA1PR12MB6115:EE_
X-MS-Office365-Filtering-Correlation-Id: 4c214b1f-f8a1-4d6a-7ff2-08ddf03d4262
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?IfSMDZiEiwg+FaFrka9ZjgB2LTHGlltIkvQVALxlCJH4Tm7rtkdeyUlrktKB?=
 =?us-ascii?Q?v6Mi1zFiJIIU5hR9QYIPOzScUcN1obqRJFxzTJJIcCLO1fsrkxvnzucIWaAm?=
 =?us-ascii?Q?3aT4K7//oj+gMzMbR8UAwX4SR98UMHs/CcX3DUPJ9+9jwRWbCn4tu/XqShcB?=
 =?us-ascii?Q?+NtyirfjshJTMG9vCgNGnuvzBL1n41aLQArOo1rgFxZMuOgUxcxtNqpf1i2k?=
 =?us-ascii?Q?WPUk11QP53MHGKCMFJzj5SvNUN45sInqylVNDXNKtIGCfS27grLCM65fMhjo?=
 =?us-ascii?Q?MqeBu2HIpzx4wruUmsCpYzzrQj915xi+Ls9jCVReZ/+JxE0q3IQ9+gLbeayq?=
 =?us-ascii?Q?DBmjqrzICRtEEYWaCvEBeu9JY2oBCzEMpoqIHoq2KpCCxoF8Vy6bmr4Wz/zq?=
 =?us-ascii?Q?la6PvTu5h7nI4mK2wW786HxUSicXg2QuMzkCYj9J+9TzJ6Eqsy6QDBFsA5hV?=
 =?us-ascii?Q?OY0Pg3s5JAteK17uG0HwwmcQMcAXWVn3YmvhYsqpfQsbzjjUvu6j1j0Qyw53?=
 =?us-ascii?Q?NyVhbqWKZHvLX0rDnqZoBaUKu04/zWsah6k4L+l3V7DGjRU/Ve6WQjCHunhq?=
 =?us-ascii?Q?tYCC+qM0ZkW2gUAVcUGKsWZzkiwHeCIujRa2eKKqX5c3TwqZ2DD+guVQVUC4?=
 =?us-ascii?Q?B09EFfTFD51OpAXhGM9cNOH3CHrRT/iW1v+0Irsi5R3ttzshn5HL0sz0OZgw?=
 =?us-ascii?Q?LrY34IZKeGOFQ1hh+zhKRpNT5s/1q5rjo7DB4GzbdEKyLCF10hAcfUfuQ4eG?=
 =?us-ascii?Q?DFXNadw2pD4+3wwXSL7i/n47z666Uca9erj2IpuXNX1WsBuGNe/zp5IC6nUh?=
 =?us-ascii?Q?jzgnGR50BY+Ns3LcTlg7cHY5YKj8c6tkZZxvvEsA8DdeJX4+bR2rUSXXuo2p?=
 =?us-ascii?Q?9WqPMNcJht0rJ7aR17ak5sopVGjJxhkUKYuNDkUFH3z7p1pcYyqt9FzbLfi3?=
 =?us-ascii?Q?olIH+KRZJHSj+UtRTAGgbXAfeO3Gb3Ey4RIVYX+Af0JxyWm99TRgOAZDu04+?=
 =?us-ascii?Q?b1l6gyaqHth08oenAdM1bIrg7L3XSmumB8pGl4yOug5d4dBn9zokPo/ub1DE?=
 =?us-ascii?Q?A4mZu0CX3Su7SujlxTEpEj2or+3ygDlsOv7lMw03tm08Y/BJwHC9ynUOWmcR?=
 =?us-ascii?Q?vrg3UxgaVczfLsl3ba/EFVL99qAELTigICUIiu4t0OcvW76WG52BM8w9Xb/S?=
 =?us-ascii?Q?b1TfllTjnsg/jyvPc+KZhTxEQhgp7/htXOKdbo7lAujE3eCzTbXPk329lARU?=
 =?us-ascii?Q?38QrJ/8FmQMiPdHLLEH49DVYZTcydd9RVpikbF6n0ZE48T704U0DHLGK8iab?=
 =?us-ascii?Q?OtOhnDDIwxBCFhnrylBSx6o6klhCRQKXb/NH0bgeLP3+QpZ0WBdSB5csCAEw?=
 =?us-ascii?Q?M+9Cwbn9siAINKkYIwUv+fcTotlEp1g9ifWQME9uGH2EcSTBGj+QiFzzZAp+?=
 =?us-ascii?Q?zTZpEp8emWRU/vK8pNMQfw/UShmM59xPoU+9jSSiAdXvku7P6zFlLU4Ij2wn?=
 =?us-ascii?Q?cB0vqpDL9dE71ILyOOc4CbH7hxKZMpXv1SAW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:40:05.3309
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c214b1f-f8a1-4d6a-7ff2-08ddf03d4262
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6115

Users control/monitor Intel Platform Shared Resource (PSR) through
related domctl-op or sysctl-op, so CONFIG_X86_PSR can be put under
MGMT_HYPERCALLS. With this change, we could remove MGMT_HYPERCALLS-wrapping
in psr.c

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
 xen/arch/x86/Kconfig |  1 +
 xen/arch/x86/psr.c   | 18 ------------------
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3f0f3a0f3a..21da8c1a69 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -190,6 +190,7 @@ config TBOOT
 config X86_PSR
 	bool "Platform Shared Resource support" if EXPERT
 	default INTEL
+	depends on MGMT_HYPERCALLS
 	help
 	  Support of Platform Shared Resource technology, which is basis for
 	  monitoring and control of resources like cache and memory bandwidth.
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 80ce5804b4..4f2c2d0042 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -135,11 +135,9 @@ static const struct feat_props {
      */
     enum psr_type alt_type;
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     /* 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);
@@ -422,7 +420,6 @@ static bool mba_init_feature(const struct cpuid_leaf *regs,
     return true;
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static bool cf_check cat_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
 {
@@ -435,7 +432,6 @@ static bool cf_check cat_get_feat_info(
 
     return true;
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* L3 CAT props */
 static void cf_check l3_cat_write_msr(
@@ -448,14 +444,11 @@ static const struct feat_props l3_cat_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_L3_CBM,
     .alt_type = PSR_TYPE_UNKNOWN,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = cat_get_feat_info,
-#endif
     .write_msr = l3_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 /* L3 CDP props */
 static bool cf_check l3_cdp_get_feat_info(
     const struct feat_node *feat, uint32_t data[], uint32_t array_len)
@@ -467,7 +460,6 @@ static bool cf_check l3_cdp_get_feat_info(
 
     return true;
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check l3_cdp_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -483,9 +475,7 @@ 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_MGMT_HYPERCALLS
     .get_feat_info = l3_cdp_get_feat_info,
-#endif
     .write_msr = l3_cdp_write_msr,
     .sanitize = cat_check_cbm,
 };
@@ -501,14 +491,11 @@ static const struct feat_props l2_cat_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_L2_CBM,
     .alt_type = PSR_TYPE_UNKNOWN,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = cat_get_feat_info,
-#endif
     .write_msr = l2_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 /* MBA props */
 static bool cf_check mba_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
@@ -523,7 +510,6 @@ static bool cf_check mba_get_feat_info(
 
     return true;
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check mba_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -561,9 +547,7 @@ static const struct feat_props mba_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_MBA_THRTL,
     .alt_type = PSR_TYPE_UNKNOWN,
-#ifdef CONFIG_MGMT_HYPERCALLS
     .get_feat_info = mba_get_feat_info,
-#endif
     .write_msr = mba_write_msr,
     .sanitize = mba_sanitize_thrtl,
 };
@@ -826,7 +810,6 @@ static struct psr_socket_info *get_socket_info(unsigned int socket)
     return socket_info + socket;
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 int psr_get_info(unsigned int socket, enum psr_type type,
                  uint32_t data[], unsigned int array_len)
 {
@@ -858,7 +841,6 @@ int psr_get_info(unsigned int socket, enum psr_type type,
 
     return -EINVAL;
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int psr_get_val(struct domain *d, unsigned int socket,
                 uint32_t *val, enum psr_type type)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117675.1463780 (Exim 4.92)
	(envelope-from )
	id 1uwFWr-00052p-KT; Wed, 10 Sep 2025 07:46:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117675.1463780; Wed, 10 Sep 2025 07:46: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 1uwFWr-000528-Fg; Wed, 10 Sep 2025 07:46:09 +0000
Received: by outflank-mailman (input) for mailman id 1117675;
 Wed, 10 Sep 2025 07:46: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 1uwFQe-0005yo-DD
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:44 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20603.outbound.protection.outlook.com
 [2a01:111:f403:2413::603])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5000c6ac-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:42 +0200 (CEST)
Received: from BYAPR11CA0052.namprd11.prod.outlook.com (2603:10b6:a03:80::29)
 by IA4PR12MB9761.namprd12.prod.outlook.com (2603:10b6:208:550::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:38 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:a03:80:cafe::e6) by BYAPR11CA0052.outlook.office365.com
 (2603:10b6:a03:80::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:38 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:37 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:27 -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: 5000c6ac-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HcaZHxMRnZA8Y/4pmRABLQd8vd2H2gqTLuqoJvPbL+TJxyjpqhb6B1Y9km4KFuDskGEAbYCHR85dfwFFFQx367oSZGAhlWR0YLvOiWI4qg78V1jvcqemZ7FiByw+xiOKm1LiaLXyk0eNBxF8Jk4MiO+cEGw0WmU3DyLZMGcHUvVPGlH1UZUkIFUnxq2+LUEM2zZcn0cilyHUHYfTuD9e/DSkAFQcAJqa9gIQenRJKIokmp3v6Sj6fZ8/gQ6ITJUIpVLOC8yslrVUslIG+a+l4bWmmWVNQUca6TXwqD3WeOfn3CzOeWFAkDfddMgeLm3kw+PUUhVYwoM7tbewWzHK9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ObH7PSMMf5VmUwx5E3g8pzKJFZIPGuXzQ+wIgiA+LvA=;
 b=U6TYwA5r/FnHLTVPCed+D46kPFYZQOTUvfAnNAa6Bu9ssjadQAOu2RYySyGZtDXGCjqSA7ZVHwlyHGd1znRHchG/AW+gb2VevBRwatmPUsCjP8tR9///SaaAAvyOVG2pmBS7MD956a88IcVb+xkKVqNf0UuXe3VY1cyzeQezIjfaVTFtvmjt1yDOPnKXsA/SHKU0b/pAa/Iy1yfPcwJDTetW9tjz/pXMfJvMQ97/wNbO2bYE1eAaV2j7sqYcvxR4KfFTD6bPBs+bpclJLgqrVQLL3zOP0ux9gQqiftUq4Lojlgn7Ve1InqBQF00bTts8LwbjQv367nBlE5aQdc5MtQ==
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=ObH7PSMMf5VmUwx5E3g8pzKJFZIPGuXzQ+wIgiA+LvA=;
 b=xxIuk57nC4L/W+Sw1bmBZuiIy0fd7ipZpvY/eMdov+1JKglbv9H3k2mZ3Mdj5zJF2fpeQcXk8alc9OhD99gUYh68PJJHv/pHjr++k340zbTEZKQSoCEms+oezXFpXGpSCzkskKlJrtsOxS4LQOiO6fd6LTrTouAxRTqWjvlj9Jc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 11/26] xen/domctl: wrap domain_set_node_affinity() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:12 +0800
Message-ID: <20250910073827.3622177-12-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|IA4PR12MB9761:EE_
X-MS-Office365-Filtering-Correlation-Id: 1b679de5-b022-408a-6c6c-08ddf03d3204
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?h71nJG8hkgIj2M9OKNziahRWDkFZ8qURrrhXsaAYPzC8qnfSgKauYMFxHhod?=
 =?us-ascii?Q?iIZL1bzVDmrQtmah3oJPekReRxkb8YI0FW9Ccg6pE1Y8s7aj1Qe1hCgcRX11?=
 =?us-ascii?Q?4x1Z6q863272xD9oIjGD0RccqxGEqYXBKUWKhn5d2K+tEX8IVcUPQIAUafAB?=
 =?us-ascii?Q?JLu8rgJrPXZFwewHftb3KcTvtJGjmJ1UQtPiK/jsXXqdGf6LMJMiXgCPQeSe?=
 =?us-ascii?Q?5O7DXzYU3boqlIlSk5lnCSVLPb5ZxWFg9wevqdoH/CIUjiO5Tfv82Wt9/XfJ?=
 =?us-ascii?Q?GSeh+FKTEvdRs/+9w3XCLW/uAsTt8ExATq7zGVAQVBLuq8BSrFL2osMK+eGF?=
 =?us-ascii?Q?C+pDcgh9i1f4xChJc8oafUyYYe7UQc3VJDGWjEaW3wJHr2bgXm002Hei4VNJ?=
 =?us-ascii?Q?h9qDDw1dA7W4E+ZNhzBy0zF7xEwR3rBegLZSllq8d0txA8fXJztiLpdgWjJc?=
 =?us-ascii?Q?BRP73Qc0P4XQdBaHRFYbDO8H9LI8HX6JU+YpUTEbsifuBD75DPJ0aB4uh6KP?=
 =?us-ascii?Q?flUI9mFK5d6vVvm8a9MxlT5LmIiXopoZxuuARjzOz8yUrWdxthcDzIAbtuWp?=
 =?us-ascii?Q?OkN+tjJ8UqSxrIj1gQcwVvLLrouTdl6pj5Lk/4Xbd7n+kJXthO3Z1aMpJvUR?=
 =?us-ascii?Q?s3wd1ySuGPHkgyQ9eL0em4fD0EnIwj4i8aisku2pAzTwgeOsNMm/iV10eKx7?=
 =?us-ascii?Q?H8nYB/mRGXyx3gzvvgSSxAsXTpS4U5RcZoSlUSBm03jmeLdQx5bKB/jJh+wI?=
 =?us-ascii?Q?4tozkoS8UDUCGKo8PA8Sa06482K09pCM00gluMMq/riXJd3WkU5bGNqqJvUz?=
 =?us-ascii?Q?sRQeBwOIjdZJ2jUfI/85s+4nCbQAXLWJOOR3JKF2jw6S0NpptChUSltCVO20?=
 =?us-ascii?Q?tpI09zJIRgU7zokxc1+3BL/jDcma05IQRmBQq0Gnk0DdiwWO/iu+Zq7W3hsF?=
 =?us-ascii?Q?HB+2TzmL3drldYZUQ56uIj5nDlIk3X40n/jr737aoi5hiUarhYBoBnxikf+p?=
 =?us-ascii?Q?6/xkGHfsD0LmIuKEpZAgu7Ide/eHbJ+u1cxAcER5VYoDnPhyNxeTFv0Pt/7O?=
 =?us-ascii?Q?7RThJ6sURKbPmAJt+Q48s1tgykM/AQQdLD5VKC1GEBgR2yt0m/mv8sXNS/Aj?=
 =?us-ascii?Q?ooInXOqZpGyLccU8i1LktbVJQ3SspbJOL1RgTUQ1NmJdAiZxpdrGgu+FyBPp?=
 =?us-ascii?Q?0MSINtsyU4QjFzp0Clp6hBuxy8b803uwsGFXatwCTzRRUvqKTvzqd58IK/Vd?=
 =?us-ascii?Q?n4F7vcxPWXaKdbyIya0R9gb5YH4nBJ+4KAKOJ1JzbWEhiSd+AhTzlrljdNgV?=
 =?us-ascii?Q?LG4/08mQXAGkftKxRUn049Aht/8F01IttBO791hCeo7zj2B+1ZJGRwtMlvg1?=
 =?us-ascii?Q?7akO0NeRMEDYKIl4R4/QJW7qfw2kDJkIpH1lkzFiPDxpBPvV177Rm4W/m6Zh?=
 =?us-ascii?Q?kYh8ZwzIdKpaj0IlCN0MkkTaQiI/HDAgORu04vCxwaBzN4ZgV4qTh0AhhKfi?=
 =?us-ascii?Q?GarTOafHUVLjliLtyg9a/kgkzeSxE3pWYABW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:37.8617
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b679de5-b022-408a-6c6c-08ddf03d3204
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR12MB9761

Function domain_set_node_affinity() is responsible for
XEN_DOMCTL_setnodeaffinity domctl-op, and shall be wrapped with
CONFIG_MGMT_HYPERCALLS
Wrap XEN_DOMCTL_setnodeaffinity-case and xenctl_bitmap_to_nodemask()
transiently with CONFIG_MGMT_HYPERCALLS, and it will be removed when
introducing CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_setnodeaffinity-case and xenctl_bitmap_to_nodemask()
transiently
---
 xen/common/domain.c | 2 ++
 xen/common/domctl.c | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 5d81ab3045..6778dc388c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1105,6 +1105,7 @@ void __init setup_system_domains(void)
 #endif
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
 {
     /* Being disjoint with the system is just wrong. */
@@ -1133,6 +1134,7 @@ out:
 
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* rcu_read_lock(&domlist_read_lock) must be held. */
 static struct domain *domid_to_domain(domid_t dom)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 0f20e8941b..fb6fe90888 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -44,12 +44,14 @@ static int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap,
                                    MAX_NUMNODES);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int xenctl_bitmap_to_nodemask(nodemask_t *nodemask,
                                      const struct xenctl_bitmap *xenctl_nodemap)
 {
     return xenctl_bitmap_to_bitmap(nodemask_bits(nodemask), xenctl_nodemap,
                                    MAX_NUMNODES);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
@@ -495,7 +497,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = hypercall_create_continuation(
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_setnodeaffinity:
     {
@@ -507,6 +508,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = domain_set_node_affinity(d, &new_affinity);
         break;
     }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_getnodeaffinity:
         ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117678.1463795 (Exim 4.92)
	(envelope-from )
	id 1uwFWt-0005WE-Sb; Wed, 10 Sep 2025 07:46:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117678.1463795; Wed, 10 Sep 2025 07:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFWt-0005W1-OA; Wed, 10 Sep 2025 07:46:11 +0000
Received: by outflank-mailman (input) for mailman id 1117678;
 Wed, 10 Sep 2025 07:46: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 1uwFQm-0005yt-6J
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:52 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20604.outbound.protection.outlook.com
 [2a01:111:f403:2413::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 52992622-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:47 +0200 (CEST)
Received: from BYAPR02CA0057.namprd02.prod.outlook.com (2603:10b6:a03:54::34)
 by DS0PR12MB7778.namprd12.prod.outlook.com (2603:10b6:8:151::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:43 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::6f) by BYAPR02CA0057.outlook.office365.com
 (2603:10b6:a03:54::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:42 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:42 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:40 -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: 52992622-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ly7DLNkdRMxRw6S9/Y8rj/ZyB99eietlVtejRl0k6r8zacNApW8UekguDSPVI0uWl477AaFMQoJ7JVCdZkVNyesZL43ltXsngRGjE9d42f+2eP0J4T+4AwbSvMmFyRW2HQLxO1s4/zoDwRoCzG/7f7lwie/sqIJZgNlXCR2CL11BxWOUkr1/x6e+ro20RFtjhaHFiKDJrziMKCJJjpiDiDCpAzC4/QFwTN6Pypxx8eX53JQImB0ZH1qcR5R9KP8JWoStAzOpW6zmk1gEMxGUywnRArqZ6l0PxxdSFYlNq+6+1AuQXMFXLqCzj29f91SepG5iyhfRIkGXZdKWtfXAwA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sPLCxnD1ZJb6r1rXSz/MjuR5iKDACsR2gEr90FFhFxk=;
 b=papn7aqDBMcvjvGcGClg1nriNzzStuchjIVmkjgpYsusP41MEnZRXZbnXSIkoQx2ZyHefd613XvC8gXiQg8j9t2GwZ6kdKKtmV8/e+8uDzGClX4etbniSlo6xHeHE4SxavGVaIUgCYvy0Ut5/amfH71JsLwKy0jF8y3lUCAwkbHTCm02s9eebi4IFM7UJhFXZT7ys8oF6Ut0SbSwoPEHg4hSbeT6RtNn8aNt7SQfmNR20ZRntXKQTVQ3lENmUmEOasTv9AZZ8jQPbsY3x2dzboah4SBNwdDoGP1hEUZ0cEyuzYVCl5zvIa1f9QNx9JovY4lS00nRLDp2APOBtHYU+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=sPLCxnD1ZJb6r1rXSz/MjuR5iKDACsR2gEr90FFhFxk=;
 b=meC+3NRmLur1NAjJxMIHSKVTr3XTskVM8Ua5wy310jeLWZmeo0aj0FRl62b0iAycXYPEUob9JVfInzkQJzQ+Veej659828d2V1+B5s9YkVXZgCw7lo8ILasJ0lgvz2p+JVSWGJ1dYdFRDU+m8iOEzThMlvQstiVd9uh6Ci5UcYM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	
Subject: [PATCH v2 15/26] xen/domctl: wrap xsm_{irq_permission,iomem_permission} with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:16 +0800
Message-ID: <20250910073827.3622177-16-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|DS0PR12MB7778:EE_
X-MS-Office365-Filtering-Correlation-Id: 274d4229-6ff2-4e03-6e8f-08ddf03d34e3
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?Rm9v+Dp0w+e9+A7hbzulm57Gx5UmucCEiuyv8WBsVqHPa59ELVJMRnoQetyc?=
 =?us-ascii?Q?5G104Lua3BwoymLZ++QLWLIxhS+yLSvjbVfncJ5FxwSRi5s0kVut3dZwGokY?=
 =?us-ascii?Q?KcjiwknvKKnQ8lx9nGnjhQ78wNnm0oTUyTwzg9a+MaDjtMsq2Q2hGbiIvfch?=
 =?us-ascii?Q?uDPNvcOV7XieoO+kzeMv9guAZ0skzK9wg2fiYDiArZ2P4S9hxGngpadX+oKi?=
 =?us-ascii?Q?9oB/AgjJ2quqxR7qQ9aCfpA8XY72BRHljW+ue+mokVhPRgcmvj79qntFlr+X?=
 =?us-ascii?Q?iVAgLSZGTsTymPtxSn/1KXwjxwKiCCJ7XrvH3EnFZpSZguSUHbq+Z1PY8bXz?=
 =?us-ascii?Q?qJojJ6spwlO5PCusOQ2kTvZxSpMKGn2lGuEZCgkPi/sdQEtDkCreMUN4deG1?=
 =?us-ascii?Q?N4oabXDHYVD6SF9keaFRLan/x4QIOVQ9x3JFwN5h8dkrF7qPkgvxtUNmRPIc?=
 =?us-ascii?Q?32WeB38T9xE0ZiLnyD4aToKWJB0D6XYtg6+RTAaJyc++G/M7R4WZTvygOgFD?=
 =?us-ascii?Q?9rHb7pt06ZhcD7iLDLLBZQCsKjrcdeWTZbcOs/JSP5xm8/SgAq9N9M3ZZ6KQ?=
 =?us-ascii?Q?VNJ2n9wCCFODF3y6DSRnN+K9KgLNHwHRD3jbOUpMt1odPCDHAzCeT5vRuNgX?=
 =?us-ascii?Q?Wk6MwxnLCSoTcXJwONuQdJBBG7qWlmbXAz7GyOh9qox0HSL1i4f81REnA4QW?=
 =?us-ascii?Q?WCsKDpKa35tvxxyIspOnG91boTYuK4g6WTR7lf/1mWtXejjTt5wzM/9O8KQR?=
 =?us-ascii?Q?x2fo4nIVXetMLGXH/9Xe9xGRbew3tfIHo+CJ0K4yrG8sAUIXXZO8y3UHRrWL?=
 =?us-ascii?Q?uu7f2IcHArm+pDGsx7ClsyGCJm46/4XRawoRtqJ0vOT9BbZg18G/1zbf4dJg?=
 =?us-ascii?Q?w25SUvLhPOcFKwnMoGkJjFZrR6Y2nm+z3ZWc97rTssiWSGLxvndkv/b5VR4F?=
 =?us-ascii?Q?WtttbRyfTxYLS6iZd/vBhcn1R4rKFh/QPDiue4Fa9s0Sh3K+ouWOInR2CcJb?=
 =?us-ascii?Q?T3kvWeCrF/JECHX08xK9i/8C2bDjuZXO4UN/Yg6avSwe+PkC2epK8GdymGdE?=
 =?us-ascii?Q?ftgVvHN0O3BI1NxiPivV8Lu6jGV7pctfej0qwMDtYDgvXUpIT7CpSmcVFWTO?=
 =?us-ascii?Q?JDNoPsbtcrMpuNWTcdKAcZON7sXZjzhrhTX3fxuQ7ucKZtfQhhgaT7BTI0rI?=
 =?us-ascii?Q?KhD6CEzjUP9UjWeJatzCLoM6KScCRWmem97dVO1yobDjP9CGnzucHXHysKpB?=
 =?us-ascii?Q?mVZc+V6AdJ9Q7IVDzjvL6N4VVh14IFCrNz07w2S80yjPpT1LvGQl1b5BSdWG?=
 =?us-ascii?Q?WWemsnhqiVH62mtW5dBy1uqpeLrOxRLUp/Mi83ndq3tbw8Xd+8DmTTx52301?=
 =?us-ascii?Q?WEBWUr5Bs7mCJKI1dFEmkZuj4G9X8RD5YN81BtikhFD0pI4RVCKIsUYgk5k9?=
 =?us-ascii?Q?a+AUFJQWB+9JD+9HpTDEeiGu8w1uXBDqGwfT2FPaaX28pF0mVuSBojZDpa22?=
 =?us-ascii?Q?2n/4qYbYAqcsl3c6zSkrhiIc7zHgWEf1ud4u?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:39:42.6747
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 274d4229-6ff2-4e03-6e8f-08ddf03d34e3
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7778

The following functions are invoked only under
XEN_DOMCTL_{irq_permission,iomem_permission} domctl-op, and shall be wrapped
with CONFIG_MGMT_HYPERCALLS:
- xsm_irq_permission
- xsm_iomem_permission

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
 xen/include/xsm/xsm.h | 10 ++++++++++
 xen/xsm/dummy.c       |  2 ++
 xen/xsm/flask/hooks.c |  4 ++++
 3 files changed, 16 insertions(+)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4d332ceca2..1fcd945336 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -113,9 +113,11 @@ struct xsm_ops {
     int (*unmap_domain_irq)(struct domain *d, int irq, const void *data);
     int (*bind_pt_irq)(struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq)(struct domain *d, struct xen_domctl_bind_pt_irq *bind);
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*irq_permission)(struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission)(struct domain *d, uint64_t s, uint64_t e,
                             uint8_t allow);
+#endif
     int (*iomem_mapping)(struct domain *d, uint64_t s, uint64_t e,
                          uint8_t allow);
     int (*pci_config_permission)(struct domain *d, uint32_t machine_bdf,
@@ -508,13 +510,21 @@ static inline int xsm_unbind_pt_irq(
 static inline int xsm_irq_permission(
     xsm_default_t def, struct domain *d, int pirq, uint8_t allow)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.irq_permission, d, pirq, allow);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_iomem_permission(
     xsm_default_t def, struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.iomem_permission, d, s, e, allow);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_iomem_mapping(
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 2c878999a3..b216894579 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -73,8 +73,10 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .unmap_domain_irq              = xsm_unmap_domain_irq,
     .bind_pt_irq                   = xsm_bind_pt_irq,
     .unbind_pt_irq                 = xsm_unbind_pt_irq,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .irq_permission                = xsm_irq_permission,
     .iomem_permission              = xsm_iomem_permission,
+#endif
     .iomem_mapping                 = xsm_iomem_mapping,
     .pci_config_permission         = xsm_pci_config_permission,
     .get_vnumainfo                 = xsm_get_vnumainfo,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e8a4deb2ea..198053be77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1111,12 +1111,14 @@ static int cf_check flask_unbind_pt_irq(
     return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_irq_permission(
     struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
     return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 struct iomem_has_perm_data {
     uint32_t ssid;
@@ -1943,8 +1945,10 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .unmap_domain_irq = flask_unmap_domain_irq,
     .bind_pt_irq = flask_bind_pt_irq,
     .unbind_pt_irq = flask_unbind_pt_irq,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+#endif
     .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117685.1463805 (Exim 4.92)
	(envelope-from )
	id 1uwFWw-0005sT-Cm; Wed, 10 Sep 2025 07:46:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117685.1463805; Wed, 10 Sep 2025 07: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 1uwFWw-0005s7-86; Wed, 10 Sep 2025 07:46:14 +0000
Received: by outflank-mailman (input) for mailman id 1117685;
 Wed, 10 Sep 2025 07: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 1uwFQs-0005yt-7K
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:58 +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 56205dc0-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:52 +0200 (CEST)
Received: from BYAPR02CA0047.namprd02.prod.outlook.com (2603:10b6:a03:54::24)
 by SN7PR12MB6690.namprd12.prod.outlook.com (2603:10b6:806:272::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9031.34; Wed, 10 Sep
 2025 07:39:46 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::12) by BYAPR02CA0047.outlook.office365.com
 (2603:10b6:a03:54::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:46 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:46 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:42 -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: 56205dc0-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rFhzBuSoEqGo1qfmYewzY2UDPyyD1XOvaCgJ/Oe0sh/CWf15by+aBzZBf8H4bApY7q7bm3isd51+EbqDoVxAZprboRFpwg7smhH00J2UVo34C88MfnjNKvVL/oQXVYxh0qV+agk6v7g/BNeBjmC92AQQ9LFJskpakbPr3pmUHNrhZ+/0+dxINzgpxM2Y4x91f0aW+oj86X0V1hgM6twM2r3zU1T6Doi/CeZX823mcgYVzJCTUnt6hZI0dx8NfsFd73dje+Uvn+zMyw8Qz1bq5B/uiCC2ivHjnBl3SxCDaSeDPn5a4bdQtiPCOcVy5B+XU3HUzDrcG1YySIveURVQVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zkokiDvf/GT2g8eWcD+vSGI07NbkAbkWkG3C6DWEVjg=;
 b=erIj7X08HTx3JEqR+EiUBdvqPVsBNcp5hl4FvpNg8kYP4livdjI3ZcfsWRahkc6VA2XZsU5V1SJAEJzA3NIlYumVmLIWo0pAJ74ZlnatdIQgDX2ZTDqOCSC9aUljggHhSoYMP5jTlACYFDNMsMSfwbP7pk7bgkh5p8taiXs247MeWYlsCr41088E5KDk2cJfn1qW4VDpLePIJ9rBdseKaWCmFUryA/LeLYRcNIwZs0eO3kW68EKZq243Xr0kzuyFyqhN+WrLZ3NXAMgYbFUmuwIdO3gs1bBa7rCCo6K+Rg3CrocNvs0iNDTHA5+R6FMKnXq1z1NzO+xYTSlOOto73g==
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=zkokiDvf/GT2g8eWcD+vSGI07NbkAbkWkG3C6DWEVjg=;
 b=CqYunTH/CciNKIrKwijIzmwrADepuLsVJpR9h/k0scVLZ9rCCg3r0BciC0/qgHSRe2+sU1ZLZyNqayrCF4MyW6ZEu099XJCk5etH/XCIFE0VA4yB+a1gSRXU2Ini6X5xBLpoJTmH/+NylDkDKJ/cn/zmaV3VsFs3oXj6hiHu40E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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?=
	
Subject: [PATCH v2 16/26] xen/domctl: wrap arch-specific domain_set_time_offset() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:17 +0800
Message-ID: <20250910073827.3622177-17-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|SN7PR12MB6690:EE_
X-MS-Office365-Filtering-Correlation-Id: 5a24d557-f83a-4dd1-fc8f-08ddf03d3729
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?3vhuvEjMv/cpVb/VAqf3IpSIPlbny3JZsTOL8KONxHr7UEMtnZU5jw3PpXhg?=
 =?us-ascii?Q?W+U6i0YDgJf69lFf9Di4z1ZgDTB1R+bh9l5fui92ha6Y7PPUSYqgrg8A3SjC?=
 =?us-ascii?Q?AZqS/Cqgg5uw/e+5YIKYaT9+omdSEvVhFYr1aQsY1DlGprgbTOXkyMX7f4ft?=
 =?us-ascii?Q?76QkTx3EW7z2pznpsp06+2u07DXgj1nTUHtFWMGSKZcY1alPitOuTaEd8ivo?=
 =?us-ascii?Q?NW6WxX5Waqw+DXP89YHbF4zxScogxSwY5uloHPqtkyusDwzdsZfnyWeq5h2+?=
 =?us-ascii?Q?fQ1R9Sw689a9vQFFyGCBby/CwqAlIe1USLnEIEEqSMm9Lu68SuxaJdCksVUj?=
 =?us-ascii?Q?TG6kvfSmgt1A+buRZKsP7SMNwOYUi9mgRNbLTKMPRKMCCqWSOrDynN5fnC4t?=
 =?us-ascii?Q?O3ZRbwtRfCoImr2mudqTS+56jROFJG4xGrskYpjnVRP7p5YLjGVB4ilF9cUq?=
 =?us-ascii?Q?OfRwQreFDHCWpGI6Kcs3VR1jMvZ27L9k5yVC6DN1KBgd6YsGJapRUOmGfgjc?=
 =?us-ascii?Q?sNaWboh/Vh+pkdOrHSJ9UU6zP2mNFcRECL5xWAwXsOEZWG70uvNe6b2R+vL+?=
 =?us-ascii?Q?HEXbl179UVRkT8G1rwiszoAVYe6q5WBRMl2cbtCe3npyqSkHUYz5JsPM9FDP?=
 =?us-ascii?Q?soxUMAUQlHYx+xdRh9jhfbOCALi662DQmOKbww7TYTBhDUlcv2h0FW84KBs6?=
 =?us-ascii?Q?2RplZX78z0/rmxZK3wra7aVWNxyumlp87tE1krEWuPstWoLlXx+NVYJNVzlm?=
 =?us-ascii?Q?79YKpo0aP2nVTiq3LUehdIA6Q+Fj3Zfoa67cVeEAzVn8Urn1FMHS+OcFfyQv?=
 =?us-ascii?Q?UIIrbTgduK0QPAdUXQ5RLKJavRnkAWnrz7EZyRls8HLKGVmpGV/ZQAyEyr33?=
 =?us-ascii?Q?46eu0apmll0gDJj4gotwXVmVSYzdf3Zl4NmiZilwx7ZCKAh0iVFoV3MHSXuF?=
 =?us-ascii?Q?7k8aazlkJ7UW/Oldsxx/L1rFLEcT7QTJPXRGvIgA9MJ4+FF4Hi0NGAALFi1M?=
 =?us-ascii?Q?wRMIf813TxNg+lMBQUODJP6q3ScpADIgl6Qo/q7xm65MQfkteNa3NLfY4qkC?=
 =?us-ascii?Q?CDXJhIdonC892Mnn4LKTzFu0SD73E+7U57ripeX9KrgIBtyo5K49oyZs9RuC?=
 =?us-ascii?Q?R1bDRhF6xHziyyEA0qva8gqQ9swi424BAQ1W5b5NwaKhDUQT4kanhP4S8/lL?=
 =?us-ascii?Q?X9/Brszy/Ua1v2nswqRtDSIWKVcwOkcEjakIsJeUgD6f/UwEtWFEFjQeUZhf?=
 =?us-ascii?Q?DTqa8XAuqbZKxH8NfcT2/c+DOkPd9i6LwADd+R2WvoW02bdujZV540sM+ImV?=
 =?us-ascii?Q?WJktsgGYe0tImxdiRrxbv8bbsNgEbpOZf0CzQQ6vFMlqr6S7e8ZDQWCGoBH+?=
 =?us-ascii?Q?7DLghzNLR6dQFpgmk7FlfD3s4LXvYhQy983P+FPQ0Xb4f8gO/F0LP6kln5Ki?=
 =?us-ascii?Q?wNnEI+ccrT1GhZBDpVgvn7PrH775cvjcv0mdq0ATPn9DEXx60Cop2uEgAEdO?=
 =?us-ascii?Q?JrIRqrYISNOuN9JfXhNcJh7ApLAb1EnYzvgF?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:46.4922
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a24d557-f83a-4dd1-fc8f-08ddf03d3729
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6690

Arch-specific domain_set_time_offset() is responisble for
XEN_DOMCTL_settimeoffset domctl-op, and shall be wrapped with
CONFIG_MGMT_HYPERCALLS
Wrap XEN_DOMCTL_settimeoffset-case transiently with CONFIG_MGMT_HYPERCALLS,
and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_settimeoffset-case transiently
---
 xen/arch/arm/time.c | 2 ++
 xen/arch/x86/time.c | 2 ++
 xen/common/domctl.c | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index e74d30d258..dfed0b0ab8 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -365,12 +365,14 @@ void force_update_vcpu_system_time(struct vcpu *v)
     update_vcpu_system_time(v);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds)
 {
     d->time_offset.seconds = time_offset_seconds;
     d->time_offset.set = true;
     /* XXX update guest visible wallclock time */
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cpu_time_callback(struct notifier_block *nfb,
                              unsigned long action,
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 59129f419d..e7394ce8cf 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1841,6 +1841,7 @@ static void update_domain_rtc(void)
     rcu_read_unlock(&domlist_read_lock);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds)
 {
     d->time_offset.seconds = time_offset_seconds;
@@ -1849,6 +1850,7 @@ void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds)
         rtc_update_clock(d);
     update_domain_wallclock_time(d);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int cpu_frequency_change(u64 freq)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6048a87826..776bf7b8e2 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -748,9 +748,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
     }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_settimeoffset:
         domain_set_time_offset(d, op->u.settimeoffset.time_offset_seconds);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_set_target:
     {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117692.1463814 (Exim 4.92)
	(envelope-from )
	id 1uwFX0-0006MF-Me; Wed, 10 Sep 2025 07:46:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117692.1463814; Wed, 10 Sep 2025 07: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 1uwFX0-0006M2-I4; Wed, 10 Sep 2025 07:46:18 +0000
Received: by outflank-mailman (input) for mailman id 1117692;
 Wed, 10 Sep 2025 07:46: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 1uwFQn-0005yt-6H
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:53 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20614.outbound.protection.outlook.com
 [2a01:111:f403:2412::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 51c19d12-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:46 +0200 (CEST)
Received: from BYAPR02CA0061.namprd02.prod.outlook.com (2603:10b6:a03:54::38)
 by BN7PPF2E18BD747.namprd12.prod.outlook.com
 (2603:10b6:40f:fc02::6ca) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:42 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::52) by BYAPR02CA0061.outlook.office365.com
 (2603:10b6:a03:54::38) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:41 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:41 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:37 -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: 51c19d12-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sOufc3I+ge8YE0yMAEgUAtDJhVgbXJ7Wl+eeSoCptceKysyK6JZ9MOkPY6Z2O0qyOgFKRcQosp6XLXtIQiAFzBnjATAYrWCcZXOACuXEm+7wsNvwsykvpwWszvRhi0CXK/HN9mJv2NV9MQtE7IXXlNl4X2Veh4GumdeXTev5ZChjKlxSwucm517rZOpAB9XEiJXfZeTHvpBTwMWuwmJByG2pJWeSs6252MT1kOEY5OHt6FdDfy4XKQca+ul+y5lHoROR1GwycVx5y1jOLHGpUnNk3tJCwEZzkSh+Mhqi18xRQyXIXJbRKk0tAlXK5geLcqA1g+HkVX8jSGo749sx4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=52WwT+owHzY3V8/0eDU9osPAmiimtxakR45Na4sC7po=;
 b=LqX0uyRXuXzVkD+HYVgFqIUDEyUexJ4QV5SAmWydovMr5ROwjJP/58L0EJcKymM/KiuSY1AIx0aCfSujVzQl+NUfg8ljR8xU5LworeEJdhb8xkkNgePqsVYf8qV/qmnpdagEwim/z/27Y+Ax61f/494/IMPz/HNfWltP7+gfyRd0bNiegoiH/8jb/MbVD1lR/4MdVaRve9uUYmXRHK7NNk077q9RRFLrnFtX8/IDqquUxl2P5OTe/ZVkgxJZN8naq3Yg+4y6EWcP1RjdL3kKS9JHsM9ZvPYZga03xKGyQXu8GQbgCasogfdJwiWHXExH+H8fryojKGsalyQKrjBy6g==
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=52WwT+owHzY3V8/0eDU9osPAmiimtxakR45Na4sC7po=;
 b=5bcaKGHbxp48+EWA6cDLmuUlYuaCZqaypLRvHj9hsMSXlz+XHeIvPf3B1oEt4y7cVcQPZzstuhnDIQbKtlxjfGB6bvVGk4GOmnZTosCXLIHqidDEzvZXjKK/2YACAYubIpKHFMmLOnrtbq/7yvdzjtQgLqfFVagJ5b+5t0+p8nA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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?=
	
Subject: [PATCH v2 14/26] xen/domctl: wrap arch-specific arch_get_info_guest() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:15 +0800
Message-ID: <20250910073827.3622177-15-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|BN7PPF2E18BD747:EE_
X-MS-Office365-Filtering-Correlation-Id: 13c55dff-468f-4e98-4999-08ddf03d3423
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?u90JWf8H+Mnc+oxN3tEN5jmsWwVESsTuU6bo9qIiz4dgmpjaLLHNHnfvUdiD?=
 =?us-ascii?Q?TdyxbaCkeXVc0+a4oLHtmohc4bquXiaPHUXl4pr32i/xWKxsg8zAWDoZhi1j?=
 =?us-ascii?Q?5t+wcuWBXI8q/JMVkdDsN/2hVGMuOYImyZ/L4awOg4I3Q1BhiGYTvQfGqz9D?=
 =?us-ascii?Q?ZXZAlMDiZP3tkvi4EQKGcLman1/pxf3yKsvbiWdsGoqUCTf8OMt9YpLHFjRN?=
 =?us-ascii?Q?FHd4XKQFR2XzNyMl944bCzx3+Z5+5VrWvDsINdiciDWFyUB976iphmkGnNWE?=
 =?us-ascii?Q?DE7YTRVk8ozWXCp2sLnkBuF/YzHjqj6piVgLc+VSJ8WymQDdlRIgT1Wz+Ks/?=
 =?us-ascii?Q?kfgV3EiTmFFJr98tcaEKLTvn310ytSmgKvqvoA+NbCmZeYzNPvekLca6LfGr?=
 =?us-ascii?Q?Q5ZxZe+i61eyQKxrvrGLXJeN/eYyn9COpVBoNCtWu+aMJPiPLBCF0VMJ78FW?=
 =?us-ascii?Q?TXXBTtsSRS1a7GUlP3WuMwaT/+Dl6+J0EIBh3X0UjWhUTjZ2xI+Nf8V2Jmri?=
 =?us-ascii?Q?mzrcLHm1syJQ2Bfqu8sZ4Pq7DeBYzfh/x17w/ww7zFj4z4cfDODtNVF8k15E?=
 =?us-ascii?Q?h/IPF/iMJqmZ6VDDmdTNOUmv3NAMimH6H4LC6QUqyCCewt6DhvCsYyECCFVB?=
 =?us-ascii?Q?3StDyzZDsZEgkMVNhmFknmK69R+Fgd+r3/IH/VmDw61t+9kS1LPfGdXWcfxi?=
 =?us-ascii?Q?6DlTinEXLCb4lhGwvUjn1UdunwgIZiv/7/i3IjM/3aFN27WrwuixBmSs9/s2?=
 =?us-ascii?Q?5NKot9D572UXPAMbeRWsgfj3i4DYAkM+0DQYMIVq+WT3M7AinVVQpdJ+YldL?=
 =?us-ascii?Q?oprhDONZ7pSF9s3C0qEjxMXldXxD8aZOqpyjl+FYyzGKlaHSkWdCHo8A2OYv?=
 =?us-ascii?Q?kRtK4UrqO3tAWayzqABm+7ilm2Sy0XX9//tQZqloJjE03uPa47Vef7BSnYzn?=
 =?us-ascii?Q?t2nH0osz8iVHLWZQhU9l9iQs5uKJ0i1lrLG1ApMJEOxnXfV9PPMLtrYxaiSw?=
 =?us-ascii?Q?BKkj0Sz/So348orFfN1xZjyENIFK33N5Wy9iXRuy8AirM0UMaHFDF5yX2ECr?=
 =?us-ascii?Q?A2BJE135wFbABq2D9yzdmX5SeY82JviXafOMoQPEl6pFKtDXuXNAS8DrLVaf?=
 =?us-ascii?Q?u9T/JHbbGmR2mGPbGwnMuHfufw/E5ZJi2cpE77MT3QsEzS/4zuzakAODUWMX?=
 =?us-ascii?Q?QGsySMwiWZZlbRS29zZMljcYUkmmvtjMqmIL5E6qNxPhHPjuTLGgRGc+bYFU?=
 =?us-ascii?Q?N4h7KhVXT8y4wPuJe64b+ukwPz1JCTWCS9X4XVIkjgWqxeJ33ftri9BtjqPs?=
 =?us-ascii?Q?Diz9nhY6QEYSjQyf1BBGamttyYcq83abGbR4q80TjM5JoQZRD6wxo7FDvkAT?=
 =?us-ascii?Q?jIYrlatsvWweJ39dfU4msEwehIrx3lgXMrJYOVB7RkTwGl2Fy2czqT3cRExI?=
 =?us-ascii?Q?myUn+hHUw/0FWYrIOa6qVSfRRTRiVr874oTp9pvsHwxJuXRIRkCSBg//e1+q?=
 =?us-ascii?Q?ndwlJvP5KB9hkxowKSEfca0cWM1tf1kIJoG2?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:41.4143
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 13c55dff-468f-4e98-4999-08ddf03d3423
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF2E18BD747

Arch-specific function arch_get_info_guest() is responsible for
XEN_DOMCTL_getvcpucontext domctl-op, and shall be wrapped with
CONFIG_MGMT_HYPERCALLS
Wrap XEN_DOMCTL_getvcpucontext-case transiently with CONFIG_MGMT_HYPERCALLS,
and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_getvcpucontext-case transiently
---
 xen/arch/arm/domctl.c | 2 ++
 xen/arch/x86/domctl.c | 2 ++
 xen/common/domctl.c   | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index ad914c915f..d3263e4d03 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -184,6 +184,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
     }
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
@@ -199,6 +200,7 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
     if ( !test_bit(_VPF_down, &v->pause_flags) )
         ctxt->flags |= VGCF_online;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 6153e3c07e..ea5f5b20cf 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1370,6 +1370,7 @@ long arch_do_domctl(
     return ret;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 #ifdef CONFIG_COMPAT
 #define xen_vcpu_guest_context vcpu_guest_context
 #define fpu_ctxt fpu_ctxt.x
@@ -1562,6 +1563,7 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
     c(vm_assist = d->vm_assist);
 #undef c
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6660f13e9e..6048a87826 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -538,6 +538,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         copyback = 1;
         break;
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_getvcpucontext:
     {
         vcpu_guest_context_u c = { .nat = NULL };
@@ -586,6 +587,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         xfree(c.nat);
         break;
     }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_getvcpuinfo:
     {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117704.1463826 (Exim 4.92)
	(envelope-from )
	id 1uwFX5-0006yL-7H; Wed, 10 Sep 2025 07:46:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117704.1463826; Wed, 10 Sep 2025 07:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFX4-0006xl-To; Wed, 10 Sep 2025 07:46:22 +0000
Received: by outflank-mailman (input) for mailman id 1117704;
 Wed, 10 Sep 2025 07:46:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwFQo-0005yo-9d
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:54 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20622.outbound.protection.outlook.com
 [2a01:111:f403:240a::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 554308fb-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:52 +0200 (CEST)
Received: from BYAPR02CA0053.namprd02.prod.outlook.com (2603:10b6:a03:54::30)
 by MN0PR12MB6126.namprd12.prod.outlook.com (2603:10b6:208:3c6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:47 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::f1) by BYAPR02CA0053.outlook.office365.com
 (2603:10b6:a03:54::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:47 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:47 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:45 -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: 554308fb-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gundG3Imx6ihamTOiGDIoBSl4+M9m3E90m+DSvXZwP1k0rdrfg9q0ow1T9eeTQIFnshBo5IjebCS0SYQhYEqID18O8GyAajoKDffPyXpHSZWX2uQ2jxt9PeDHq2ry9ZSMaWC9U9xmgAxS75Nq3cFRcJJSuxhIsQ1ikahwQTYeaq01lmjiaSDKU3pmlFQwC5ximcp29c0r1oV0JVx9w0xqJjklBhkOw8Hc6DVPSEQc+E0InwN9hc7waVoJ9Zr7DXxLpoOzLIYM7HWCYA4L7569pnKrnh/sHV6aQO92HJ68sx8rLAVyltb3Nwgk7WgEPVTyaRSqpBo6ERgvEaWPokqEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dsmFgRDA4WFTLrqEIuLxOXiyrzOrGFpurXCsxhnftMA=;
 b=buRt3pol+wnP9OX6fcBs3HaKn05AEk6MUaP46Yjr+Kyz0lbY8i1n3iSYuDnvX2wf0eOAHNqkOoFT4u6ZJD+tkvGB8GtGOZD24AbpoE/ZOcSji9AbCm9fgVLHwSzLPUem53vS8nsOLgaUG9zokN4Px4MvhIIZ/3J7+deRXw/MgIyZPHgpFGJ+k/FWs4ls4NU2SxX/nAcxG+ca55wwN7NRu45c/0HiqO83IxfX00g+UfpaTM36P3pw+X1Xo8dxl2eBKeG0z6gSDBcYK1DAEo+ZVUccVW13P5svBvFWoIai4BsweUKClL/9if+TLH2i+efYzPWvBIstgftGrKkv374DsA==
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=dsmFgRDA4WFTLrqEIuLxOXiyrzOrGFpurXCsxhnftMA=;
 b=EoPjfOnxqcoJmG/3W7DgG8em7FNQL1xZJIgnbFwvUm6TPRXrSiGJxZsrb7/dJV82syhpQ52Fi90bfcoNgst/wfg75Z2AszOlPHdgXzFTt+Sw+2Kgjlm1hugKUOC85NUl7s09ZlvUAPS7fOtRHc2b5Ahi+NQP4SDTG8GBGNkOsgc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	
Subject: [PATCH v2 17/26] xen/domctl: wrap xsm_set_target() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:18 +0800
Message-ID: <20250910073827.3622177-18-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|MN0PR12MB6126:EE_
X-MS-Office365-Filtering-Correlation-Id: 6c74ed39-fce7-4469-b6c9-08ddf03d378c
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?Wz1ZR9o3RS35/bobW7WRwWgc7f1Ag/Iq68r3HhSmQ7ETfJFsJx57bio9JSed?=
 =?us-ascii?Q?rQxmx3Og9Ep7AyJi/lL8zN2Sr/aGl+CXsWJQyuJn0lJfWEKtRpmYNbuWDqMZ?=
 =?us-ascii?Q?31Lw/f9V7GoEZfptFzxbNAnkQnQZXKrieEaawqL5SwPaO4tgYvV/UePz4BcW?=
 =?us-ascii?Q?mcIfgb6IVbvmBzyjEhjdow9qx0nOHWp8C9vRRY9koHFO7gbxnrsqR5SjORQh?=
 =?us-ascii?Q?Q/LxKWiDY7F8hxp/lfqZq++ATtNoRtfMNEKUSE0nYzKLwP7VbnzZTRlSEVe/?=
 =?us-ascii?Q?TrWddusO4gNqROECbl6ZqS/uLhRvtvA1UaCp9jf8jwOVg23q9Ln7gJa4BFbo?=
 =?us-ascii?Q?l7pXYhxJ9VwXlozc/MU0kaY5zESqLyObZ3quWQTP9rsoEpnV29CpTE5OTo8D?=
 =?us-ascii?Q?U29juWRa2V8HupYArkEQ9qv3PY3tlnLKWBCLgXxtoI1d3RfBS1IIaO9X6nTR?=
 =?us-ascii?Q?CVaGm7LJmxgqQRzKrYgxHjHWEUTKaMP+eWzA8Rglu4ETITBEeLZKkxE6psq/?=
 =?us-ascii?Q?fxU+rFHbC/9cgcQtNA5dazZ659jCMCtgqcn0rJwnxDcfCvRCKjfZpHVs0XLw?=
 =?us-ascii?Q?FUEIjiMygQ6fnfwE9AfqPhqqsvxYVvuqn9a3OAWmrMpbo5ooxsIvm+D4nxy9?=
 =?us-ascii?Q?pAC0Lw623G+ay0GaK1jSZwKiBtNaVmroiEkIjWe6tFJ0QKezBsylhwHdHQGm?=
 =?us-ascii?Q?kxrmsstHEaYUFmXK8Bmron3OtVJRvSaaMShNyvbPfxbQxS2j7Hfd4JPbFuNv?=
 =?us-ascii?Q?0A3uhtXMaJYBPgEBF51z3elhrHx8st6VEJ08KX7YS94SuzlqxvDpA0S8GkeX?=
 =?us-ascii?Q?lrSW8iYBm8PD1XSPhD/BWDX8I0tkI3xys70VeB2Qy5I0tfbLPjEMhtGMUUe3?=
 =?us-ascii?Q?7UuB842C4n3QTQmPrHK43JLTWJKlmGMuPgOYFznHLyQehahZrB6ibBhmLcpg?=
 =?us-ascii?Q?z1QrQztbn3vczfYnvvXvpi2QgpFsyK1Tz5RTV6icp6DziWu0t3KI35HcWWiu?=
 =?us-ascii?Q?+QPdKosgjDMg/41xvV+z9sYpMourgFgQXUcbc6K00Q7FvHI0U1YDkrNy8rn2?=
 =?us-ascii?Q?amLLBkPsFpdY/ESXJzUTxateISJeXv3DIoS9KouJc9X2VQnbJ29Q5US9MMTJ?=
 =?us-ascii?Q?DihZ1fBYHL/70JJc9Vt+y72kOTq+2wcCj3wO6FtRytPBNROjYxYcjKZWo2eA?=
 =?us-ascii?Q?FBCdpNz3rYtmkE/Zq/NhXKQ4lV/K2NX3XpzS2HGIWCN6RWIPsia4l6O7fD1Y?=
 =?us-ascii?Q?PiHwYDYYyasPmnQ9p/ozkXGKtseo5lxXgoAkljPF1k4EnivA09MNNK/M4ohr?=
 =?us-ascii?Q?grwjqQavdF63G1kJIj/J95rIWQaYdpayACJhGcwL2DFDNFuukNu1GjsALejj?=
 =?us-ascii?Q?zMwJN0bmW8Iqj2ZCsgrA7JRXG6ExTCh+9jrzCPcLNPHDY9uFVUbvc9WxpdCP?=
 =?us-ascii?Q?y2fPft48n0ZTrqFfSDqBA2zFUT518jDKioFv6V86Fwfs1LT1oM5pgiZatvTA?=
 =?us-ascii?Q?bu5l7fTfmz6MbbVTBClwh73JQOUHZpvO4ktl?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:47.1394
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c74ed39-fce7-4469-b6c9-08ddf03d378c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6126

Function xsm_set_target() is only invoked under XEN_DOMCTL_set_target
domctl-op, and shall be wrapped with CONFIG_MGMT_HYPERCALLS.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
 xen/include/xsm/xsm.h | 6 +++++-
 xen/xsm/dummy.c       | 2 +-
 xen/xsm/flask/hooks.c | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1fcd945336..678cb0f346 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -59,8 +59,8 @@ struct xsm_ops {
 #ifdef CONFIG_MGMT_HYPERCALLS
     int (*domctl_scheduler_op)(struct domain *d, int op);
     int (*sysctl_scheduler_op)(int op);
-#endif
     int (*set_target)(struct domain *d, struct domain *e);
+#endif
     int (*domctl)(struct domain *d, unsigned int cmd, uint32_t ssidref);
     int (*sysctl)(int cmd);
     int (*readconsole)(uint32_t clear);
@@ -258,7 +258,11 @@ static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 static inline int xsm_set_target(
     xsm_default_t def, struct domain *d, struct domain *e)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.set_target, d, e);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_domctl(xsm_default_t def, struct domain *d,
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index b216894579..f6986dd2bb 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -21,8 +21,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
 #ifdef CONFIG_MGMT_HYPERCALLS
     .domctl_scheduler_op           = xsm_domctl_scheduler_op,
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
-#endif
     .set_target                    = xsm_set_target,
+#endif
     .domctl                        = xsm_domctl,
 #ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl                        = xsm_sysctl,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 198053be77..ed4e466302 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -641,7 +641,6 @@ static int cf_check flask_sysctl_scheduler_op(int op)
         return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check flask_set_target(struct domain *d, struct domain *t)
 {
@@ -666,6 +665,7 @@ static int cf_check flask_set_target(struct domain *d, struct domain *t)
                                  &dsec->target_sid);
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
                                  uint32_t ssidref)
@@ -1893,8 +1893,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
 #ifdef CONFIG_MGMT_HYPERCALLS
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
-#endif
     .set_target = flask_set_target,
+#endif
     .domctl = flask_domctl,
 #ifdef CONFIG_MGMT_HYPERCALLS
     .sysctl = flask_sysctl,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117707.1463830 (Exim 4.92)
	(envelope-from )
	id 1uwFX5-00070g-Mr; Wed, 10 Sep 2025 07:46:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117707.1463830; Wed, 10 Sep 2025 07:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFX5-0006zU-A6; Wed, 10 Sep 2025 07:46:23 +0000
Received: by outflank-mailman (input) for mailman id 1117707;
 Wed, 10 Sep 2025 07: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 1uwFRL-0005yt-Gn
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:27 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 682d0fc8-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:40:22 +0200 (CEST)
Received: from SJ0P220CA0009.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::25)
 by PH7PR12MB6739.namprd12.prod.outlook.com (2603:10b6:510:1aa::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:40:17 +0000
Received: from SN1PEPF000252A4.namprd05.prod.outlook.com
 (2603:10b6:a03:41b:cafe::50) by SJ0P220CA0009.outlook.office365.com
 (2603:10b6:a03:41b::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:40:17 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:40:16 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:40:06 -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: 682d0fc8-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CN5x0eLqcfcJtcgcSKCJM+A/mDez7z6VkJD62ExDpUYYfDQhNHWDvyQ4StqlFRnl+QaVU1idBr+PGMthl5uD3Txep6t22fOBThQcVptdBROuTsH796347V4qCxtWvRBPo6gw77m+43/Su36W3mdIBINSRCzjMw17hDZh3eCBMSCQ85E25+BUEKulP5of88TxWH1Ui4HQzqwMee4fA2jS5Ba2a49YVS0BWXuwcEsrdptW9RtC+30fX7NHB/HDDAEpwhumEjckEGqyQ9u4cUpxYP7f/C9wK/3uvO7DSMlARCwwS+d2taunvOYxoCq9wj6HjnqAC2UmzIW+tO7Xtkn7aA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SXHAK3uL+WqLVQS8Xa7MII98ao1zO0m4LzYxceHy8E4=;
 b=gI6FecQg6rj9IlimLMGIKe93kBRhdYydvitEUAgqPjSmlwNkJGOzlJrvF8uBFxGffQQfghM0clvjVHO3Q4henJwv6GfPX3UtR08IJ6awNFwO9avw1uUkKzXUi6ktgliRbBNJ7IuwlIalloD+HequprTdHWR4EOpuJHfxQmJ0PokW8uR7ZXtU5/sMV/WO0cHQ94/VyghCLlEHGRvlTrvglIQRF+YPPdMGEZSg/NLNCYWf6HSI5SmaN5xbENZN+7c5udt42Vn6cwetX/PI2bsakunYn2t7kczj7iDi0ztujUmQykwbwrIiaUvJ9EhyEHdjzwXRU4P8d0rYZCGVvt2niQ==
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=SXHAK3uL+WqLVQS8Xa7MII98ao1zO0m4LzYxceHy8E4=;
 b=ETAjYkMXebEVLMtDf1O3oWUASrosYTkwGifcp1GQqQNWGmNJvhCCjFB6+lFkgCBqhcIlK9c1+DYLqG8Natn65P0C7OovAXUq3neJ+x5V7o9Op6UO7ylMSXCvkKkrO/S6OWf/6eWL9u+zxrnOvKv2JS9jRJETt61StWisO7mZF8k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 26/26] xen/domctl: wrap common/domctl.c with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:27 +0800
Message-ID: <20250910073827.3622177-27-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A4:EE_|PH7PR12MB6739:EE_
X-MS-Office365-Filtering-Correlation-Id: c7f821b7-7250-4afc-60cb-08ddf03d4954
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?aDvpUA0jZDkY7g5o1Tp0+n6GRyTTZ9l6pY889AwuPDpvIa0PgWXabPltKnIh?=
 =?us-ascii?Q?j/b7JEGZw8BEUhFROzTA9ewBfURM0d7B5x8v9kCt9U7vnhzB3vASMbTx+AlV?=
 =?us-ascii?Q?FH6ZC7v7PM0LLZB/K7KKYg2IuqYPla3EEEXvHFaC7afxzkc5/syP0AoyvUcg?=
 =?us-ascii?Q?XTncD0AYxN5KVy0Xv+XVGw0BwUXuKHFrAVLO276q/wvkMvOmezaAu2fUunJO?=
 =?us-ascii?Q?DFYCIMQ10BmyHd35+ppGiXUhNLDVqbDDHneKn05igiB8nymda5S5NO4gOzMa?=
 =?us-ascii?Q?t3IZpg9PvJP3mq9DxcpJbwlVjoLNoyd8NTHYKLhAvRba+uQta6x3WL6Ha2RV?=
 =?us-ascii?Q?lkJiVnZ/vWePigQ3jTU8b+vBOr44TCgkHKw8ovEA3vP6+b3W4VlvvdIbzxXe?=
 =?us-ascii?Q?u/DXfVBCuLNirrermheyYQC9wlNpQzwx5L41LKPWLHFKAabZUbZ9LKONtb4r?=
 =?us-ascii?Q?7wWVAvj0Nph/zpexJ7/7cooLJCmQ5J+YdinutcfFe5xh30BLvRuM41mVYXUX?=
 =?us-ascii?Q?uZISNroU4klqfEGcjFqa8ScGeR3YO3EL/npjzv58s/1C7aFqqvlxSVajA/Lr?=
 =?us-ascii?Q?2e/CqMqfWZouWhNe3qhgKD03zzgaFoXJA9rS7PmA4Cj9x1JIPUb8PY/RP4bg?=
 =?us-ascii?Q?ETeNWtVvFKSZZYFB7tJT0P8L1UQXrGUnefeH7vLREEsh3vKDRlmhcXhQItpb?=
 =?us-ascii?Q?oE4PNy+r4surKBl1l7lq5SUEMVQjW+dObPiRNQFEVOH/jVb/uBZFnSwxYbVi?=
 =?us-ascii?Q?pQFoGOgSS3mwl8IdG+CvXu/A51nhnEgVEoLVuKYGMBqIWWMSzAyaEedrLdDt?=
 =?us-ascii?Q?vyPxJN8sot6wDUdXBIgwFe8P5sqQOVQHezJVQEoOnvAbyhrVRdXclwmK7lvk?=
 =?us-ascii?Q?+q+VnE7l48P8pdnyv47P1xGMfDvKenQoFitb4Zj+1+WCFOYQDDk/Q7L0wnFQ?=
 =?us-ascii?Q?wYZ/lMQMneXUBwBhXMFH9gF5YAI9DBAenZM9175dYdSkqz0TcWirRalJkWIu?=
 =?us-ascii?Q?CgQa5ytZJU2PNbWeq61/8peygLdQ2c3LB2NwRIdB8Qn5ZkkPsT0nUyNxm8L2?=
 =?us-ascii?Q?4tHGLgqjroBY9vniWLuo8HY16RG4O7+4oNgmsvaNKG68ELh06AIVbG2QfrH3?=
 =?us-ascii?Q?QnWIJqgENEf1aCRJhb/q/fLC9UXdVEeoIGJoruQZQ7voL9Dl3jv9w2xj4rY9?=
 =?us-ascii?Q?f58RGrZml1g5zPSIXsK5YBgnus/fN2d2EJt7y/1+t4GYgEuXouXdzOQGOYTa?=
 =?us-ascii?Q?vBzEjlMhw/WOTuMKTiW1z9vjPud9XTe4xmUHn7N7n7ywF6g1bZU7JD99s3nU?=
 =?us-ascii?Q?g7EzqE0niaBQ+smNVu3+5JpCmvCBUgRQuCvEMyxm2LWXFDpDTkYpMJuPuX90?=
 =?us-ascii?Q?Z5GgqXXrpp4ckauXnsVsQeLAYw6xIUdFJwyw0klDxQ8bPJuq2sC78pPPUmah?=
 =?us-ascii?Q?hn0eP9h5lPOoEx5XRX7V6zshN3jHSTbxUVpGMv/ToiuAK+iEjqs6uZL1ibCK?=
 =?us-ascii?Q?qAZOJkrJvIP/DQcnW7lAaulqHbklDD6M2Lvp?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:40:16.9751
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c7f821b7-7250-4afc-60cb-08ddf03d4954
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6739

Wrap domctl hypercall def and domctl.o with CONFIG_MGMT_HYPERCALLS,
and remove all #ifdef CONFIG_MGMT_HYPERCALLS wrappings in common/domctl.c
With MGMT_HYPERCALLS=n, we need to provide stub for
domctl_lock_{acquire,release}(), as it may be invoked by hvm_set_param().

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- remove stub in common/domctl.c
- combine the original commit of "xen/domctl: provide stub for
 domctl_lock_{acquire,release}"
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
 xen/common/Kconfig           |  2 +-
 xen/common/Makefile          |  2 +-
 xen/common/domctl.c          | 24 ------------------------
 xen/include/hypercall-defs.c |  4 +++-
 xen/include/xen/domain.h     |  9 +++++++++
 5 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 1aedd00b12..da207a7183 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -654,7 +654,7 @@ config MGMT_HYPERCALLS
 	help
 	  This option shall only be disabled on some dom0less systems, or
 	  PV shim on x86, to reduce Xen footprint via managing unnessary
-	  hypercalls, like sysctl, etc.
+	  hypercalls, like sysctl, domctl, etc.
 
 config PM_OP
 	bool "Enable Performance Management Operation"
diff --git a/xen/common/Makefile b/xen/common/Makefile
index fdf826f218..45c0bda000 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,7 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
 obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
-obj-y += domctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += domctl.o
 obj-y += domid.o
 obj-y += event_2l.o
 obj-y += event_channel.o
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5657b95089..71e712c1f3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -44,14 +44,12 @@ static int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap,
                                    MAX_NUMNODES);
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static int xenctl_bitmap_to_nodemask(nodemask_t *nodemask,
                                      const struct xenctl_bitmap *xenctl_nodemap)
 {
     return xenctl_bitmap_to_bitmap(nodemask_bits(nodemask), xenctl_nodemap,
                                    MAX_NUMNODES);
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
@@ -114,9 +112,7 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
 
     memcpy(info->handle, d->handle, sizeof(xen_domain_handle_t));
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     arch_get_domain_info(d, info);
-#endif
 }
 
 bool domctl_lock_acquire(void)
@@ -394,26 +390,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
     }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_pausedomain:
         ret = -EINVAL;
         if ( d != current->domain )
             ret = domain_pause_by_systemcontroller(d);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_unpausedomain:
         ret = domain_unpause_by_systemcontroller(d);
         break;
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_resumedomain:
         if ( d == current->domain ) /* no domain_pause() */
             ret = -EINVAL;
         else
             domain_resume(d);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_createdomain:
     {
@@ -473,7 +465,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
     }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_soft_reset:
     case XEN_DOMCTL_soft_reset_cont:
         if ( d == current->domain ) /* no domain_pause() */
@@ -510,14 +501,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = domain_set_node_affinity(d, &new_affinity);
         break;
     }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_getnodeaffinity:
         ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap,
                                         &d->node_affinity);
         break;
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
         ret = vcpu_affinity_domctl(d, op->cmd, &op->u.vcpuaffinity);
@@ -527,7 +516,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         ret = sched_adjust(d, &op->u.scheduler_op);
         copyback = 1;
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_getdomaininfo:
         ret = xsm_getdomaininfo(XSM_XS_PRIV, d);
@@ -540,7 +528,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         copyback = 1;
         break;
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_getvcpucontext:
     {
         vcpu_guest_context_u c = { .nat = NULL };
@@ -589,7 +576,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         xfree(c.nat);
         break;
     }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_getvcpuinfo:
     {
@@ -750,11 +736,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
     }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_settimeoffset:
         domain_set_time_offset(d, op->u.settimeoffset.time_offset_seconds);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_set_target:
     {
@@ -810,11 +794,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
 #endif
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_set_virq_handler:
         ret = set_global_virq_handler(d, op->u.set_virq_handler.virq);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_setvnumainfo:
     {
@@ -842,7 +824,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             copyback = 1;
         break;
 
-#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_assign_device:
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_deassign_device:
@@ -863,7 +844,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = hypercall_create_continuation(
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_set_llc_colors:
         if ( op->u.set_llc_colors.pad )
@@ -884,11 +864,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
 
     default:
-#ifdef CONFIG_MGMT_HYPERCALLS
         ret = arch_do_domctl(op, d, u_domctl);
-#else
-        ret = -EOPNOTSUPP;
-#endif /* CONFIG_MGMT_HYPERCALLS */
         break;
     }
 
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 02d7b93e80..cbd547f724 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -200,7 +200,9 @@ sysctl(xen_sysctl_t *u_sysctl)
 #if defined(CONFIG_X86) && defined(CONFIG_PAGING) && defined(CONFIG_MGMT_HYPERCALLS)
 paging_domctl_cont(xen_domctl_t *u_domctl)
 #endif
+#ifdef CONFIG_MGMT_HYPERCALLS
 domctl(xen_domctl_t *u_domctl)
+#endif
 #ifndef CONFIG_PV_SHIM_EXCLUSIVE
 platform_op(xen_platform_op_t *u_xenpf_op)
 #endif
@@ -279,8 +281,8 @@ hvm_op                             do       do       do       do       do
 #endif
 #ifdef CONFIG_MGMT_HYPERCALLS
 sysctl                             do       do       do       do       do
-#endif
 domctl                             do       do       do       do       do
+#endif
 #ifdef CONFIG_KEXEC
 kexec_op                           compat   do       -        -        -
 #endif
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 11d2505420..19dd85150a 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -151,8 +151,17 @@ void arch_dump_domain_info(struct domain *d);
 
 int arch_vcpu_reset(struct vcpu *v);
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 bool domctl_lock_acquire(void);
 void domctl_lock_release(void);
+#else
+static inline bool domctl_lock_acquire(void)
+{
+    return false;
+}
+
+static inline void domctl_lock_release(void) {}
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Continue the current hypercall via func(data) on specified cpu.
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117712.1463835 (Exim 4.92)
	(envelope-from )
	id 1uwFX6-00075o-5g; Wed, 10 Sep 2025 07:46:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117712.1463835; Wed, 10 Sep 2025 07:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFX5-00074G-NZ; Wed, 10 Sep 2025 07:46:23 +0000
Received: by outflank-mailman (input) for mailman id 1117712;
 Wed, 10 Sep 2025 07:46:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwFQh-0005yo-BN
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:47 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20605.outbound.protection.outlook.com
 [2a01:111:f403:2414::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52390e34-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:45 +0200 (CEST)
Received: from BYAPR02CA0060.namprd02.prod.outlook.com (2603:10b6:a03:54::37)
 by BN5PR12MB9512.namprd12.prod.outlook.com (2603:10b6:408:2ab::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:40 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::99) by BYAPR02CA0060.outlook.office365.com
 (2603:10b6:a03:54::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:39 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:39 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:30 -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: 52390e34-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j0IADLjTF2hQNtbP7VLUexv8SFMDBIEj57AGL6nctRjYqJ4xFe+voGhXP4br57CJdpfM26s8eKpVL+tdJUjGvHP5TLfUyrZpjoJGoL3y2xPfR/VBzuAZ1dfSXNrWG8xM9YishBQaieDMOl2lwq3pAH1pCHAfOk7PGApCDOKu2vHUPZE3qvPjZZno+++64l1YuvBNMwRhky3lnJsMlKg6UO3NJ62n2Gdz4bTwzA3RGdYUswUsZY7XtAI6kGQjBCEnqeg7OAx1m5qdIYf33hiN7yzC0mYfLkVBfsaZ6NwqC1/ExvAGa9Y0v6haBBVuAugapdrNHDKDEzEU9r7z3dP9aA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OsGNmKsA7MnLndfkk3jVWl+tKOtl00t7vTpYsq/iVrE=;
 b=igr2VSw/S59+HvmSF0YJ+TuYKPHn0aoAaWn+6QUbpTLgmkXjgfv/VjhK6UYhFbth72gKPO4NvxDrDSU+Js4ywMQEV7XD9CDLl011F9af9uJtcP3JMsC8Y32XNDB1SI03DSzq7rqDxFjuIOTSOMvtvvNG92YUoAaHQPxJnxsETPXGnz+zmH8L9dA8dFtHgPz9lWal2D4Cx3mneE+E8DbfwgvN9zk38lvJeQzy13cIkhfZu9oysuILJzxIngSEhhYg2ny9L23UE8eJFJs5KMFXZnsbxLi5Pc3sI+krVsbhVksOe2vL4LIAbJV9SrBL2ZHErknEDi7n9IOC1Lm8xGT8cg==
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=OsGNmKsA7MnLndfkk3jVWl+tKOtl00t7vTpYsq/iVrE=;
 b=5VBvpJ4KoHWlsFVZgm6lza9h6TzsACHvn4GnALNJvmRMXr8509gwTVusK97CR7ZwIQndTYalhczdQ8IBHgSjMZ10Tc28SGmAqVLfd+TrhrXfj/8Ma5B69ZjbZg86l/dNA0m7L8p9v2y4TT1uuLuQZo3Zo4OkLitwXrV1Rh+Ony4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 , "Dario
 Faggioli" , Juergen Gross , George
 Dunlap 
Subject: [PATCH v2 12/26] xen/domctl: wrap vcpu_affinity_domctl() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:13 +0800
Message-ID: <20250910073827.3622177-13-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|BN5PR12MB9512:EE_
X-MS-Office365-Filtering-Correlation-Id: 41560ebf-acfc-47c9-df87-08ddf03d32b5
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?qWWIPjdjrt1VFiauJmjTEZNX66fkHHxdG3VYx5ceRn2/FyyxAfPP6Z/c6bf7?=
 =?us-ascii?Q?9tbe7mcLOJFaebMfw8nmzeCb2vKJn5d1+TsjH5+dPnzD2HN2zZc+37jbj6RS?=
 =?us-ascii?Q?wq+R1uMhLSN6VZYwtXorm56Bj3EEP23hBW7EI7v5djWY0JyWkcqDowLe+Fuu?=
 =?us-ascii?Q?vRTHwZJ+2doVQXioanEdUL2r6BnnIORAHlk1UoWxH7SxRM3TJPFnVELkg/K9?=
 =?us-ascii?Q?6ol3IjV6Y6eVfLbJ2okwnoY8ZctWzibfb1TiPPloKdNq0zQhxtn7sZPwJ9Lf?=
 =?us-ascii?Q?pW8Wnf5wPUUKxe6e6Jd/kzuM7n06+RUN8KPdtLdwQgeSLzfER9+c3qwl44yZ?=
 =?us-ascii?Q?xzEr+78gXD75Xft7d9M5q9pAWwNMf3kYY2rrJodsbbFMvZQ4BSM/pYYjDSQM?=
 =?us-ascii?Q?nEUREymbBvho++xChpWA555+4491OcZW658NOZ+HFfZ8MeOy/QfXzUMxxqR7?=
 =?us-ascii?Q?qjhspg7F3ejsP9oIpTFP9nH7c21HqeMyCKhoxd5ExH8PymAJitTzxZtDF+Nz?=
 =?us-ascii?Q?ehOJWpktpQfk1KMiLqYED75n20DLRBLMdFW32NRR80QvtdYmTdyi5XUl6cs8?=
 =?us-ascii?Q?AIgr6UEISc5PjIdfo+l20oblyQh9Y/PNJB4j2G5UPuc4KELDy+SjPiC6bUY2?=
 =?us-ascii?Q?/3+acWyUYlXSIi3GD/G6M7lFt8k3JA4cCpsD5nduC8RNE3zSz20DIrB6Payv?=
 =?us-ascii?Q?ezcXugfZlprOl6PLIk+UVy5yCwt8PQmbpzl2jT6hTCy/A+nnTHSv9+v+ywbO?=
 =?us-ascii?Q?GacdVCeyEvOycXZMkYAReC0AKhCBwrCwT8h/XMDvUqv8c6A/PnXzJFSbYolY?=
 =?us-ascii?Q?WokNhb3m4k4iCY623I8mAX0RoVWMqDuBJtzuPCY/aY3JwMYHMiDsm0PyiEY4?=
 =?us-ascii?Q?PgDipwMAy4y/qZq+zIvYCJIMXoLTDcH9aa3lej/sI3LPGahRf0BPjBq65Zww?=
 =?us-ascii?Q?0/zZi0pQKWFR7qUbL8+1Gl5MhU392O3Rdy2I+5lGzjJ9j+3nDp3UKRg94p22?=
 =?us-ascii?Q?UnF996kzvNzuKVdEZwNl6vZzWOS2onae2JP00qcXwlSzD3r2CHOJiq/Pfoaw?=
 =?us-ascii?Q?+xxE7DVTw3SgsMdlr4IAu6RFjBRagFZB/Pw98zJdky8Pwk9vYpL3s4qhm2FE?=
 =?us-ascii?Q?0ksK52/czavVqz8bSUUtZnxENk0yXf6Xl4Dx1i1d61A//2DnWXDRwSA4JEgq?=
 =?us-ascii?Q?nP2ys/7DrNRKKsnR8vBW8TgPvYhOHdzv2+is40pR4rqzzLOa0eSM0Ta1dtOP?=
 =?us-ascii?Q?j8NOroyt/ygsLNgVrpECHaoncVWESx546VGcb39BCTrJKBKS3Apf5B0wtpO4?=
 =?us-ascii?Q?FnzAk3o3voC3QI1xfxQ+glnoMk9ttXOyyIwGS9FNICs+YaoHpD4R7Rt3razQ?=
 =?us-ascii?Q?GEDOsxwP14hSTNN6oDDUSu6k4kr2uHkktqLWNF8FD118TNBiRot7DiVznJcB?=
 =?us-ascii?Q?Mv33G92zbbuYLuHbU+3XlmWZu0DkPYkBwPNKpGkXaUA7hVztG/YtVA4akalm?=
 =?us-ascii?Q?WEWtXqOdUVwCcFiVCQ1fEw4n76jGZWAVTOW9?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:39.0195
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 41560ebf-acfc-47c9-df87-08ddf03d32b5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR12MB9512

Function vcpu_affinity_domctl() is responsible for
XEN_DOMCTL_{getvcpuaffinity,setvcpuaffinity} domctl-op, and shall be
wrapped with CONFIG_MGMT_HYPERCALLS.
Tracking its calling chain, the following function shall be wrapped with
CONFIG_MGMT_HYPERCALLS too:
- vcpu_set_soft_affinity
Wrap XEN_DOMCTL_{getvcpuaffinity,setvcpuaffinity}-case transiently with
CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_{getvcpuaffinity,setvcpuaffinity}-case transiently
---
 xen/common/domctl.c     | 2 ++
 xen/common/sched/core.c | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index fb6fe90888..4a35c17060 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -515,10 +515,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                                         &d->node_affinity);
         break;
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
         ret = vcpu_affinity_domctl(d, op->cmd, &op->u.vcpuaffinity);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_scheduler_op:
         ret = sched_adjust(d, &op->u.scheduler_op);
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index a0faddcb92..69972147db 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1402,10 +1402,12 @@ int vcpu_set_hard_affinity(struct vcpu *v, const cpumask_t *affinity)
     return vcpu_set_affinity(v, affinity, v->sched_unit->cpu_hard_affinity);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int vcpu_set_soft_affinity(struct vcpu *v, const cpumask_t *affinity)
 {
     return vcpu_set_affinity(v, affinity, v->sched_unit->cpu_soft_affinity);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* Block the currently-executing domain until a pertinent event occurs. */
 void vcpu_block(void)
@@ -1693,6 +1695,7 @@ int vcpuaffinity_params_invalid(const struct xen_domctl_vcpuaffinity *vcpuaff)
             guest_handle_is_null(vcpuaff->cpumap_soft.bitmap));
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
                          struct xen_domctl_vcpuaffinity *vcpuaff)
 {
@@ -1802,6 +1805,7 @@ int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
 
     return ret;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 bool alloc_affinity_masks(struct affinity_masks *affinity)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117741.1463855 (Exim 4.92)
	(envelope-from )
	id 1uwFXC-0008Oz-08; Wed, 10 Sep 2025 07:46:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117741.1463855; Wed, 10 Sep 2025 07:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwFXB-0008Oc-MI; Wed, 10 Sep 2025 07:46:29 +0000
Received: by outflank-mailman (input) for mailman id 1117741;
 Wed, 10 Sep 2025 07:46:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwFQw-0005yt-7q
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:02 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20629.outbound.protection.outlook.com
 [2a01:111:f403:2408::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58eb3ce0-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:39:57 +0200 (CEST)
Received: from SA1P222CA0037.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2d0::18)
 by SJ5PPF01781787B.namprd12.prod.outlook.com
 (2603:10b6:a0f:fc02::986) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:49 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:806:2d0:cafe::8d) by SA1P222CA0037.outlook.office365.com
 (2603:10b6:806:2d0::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:48 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:48 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:47 -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: 58eb3ce0-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jk+GyVe5CV2zvlAw75YQ9sj2jIF/qmqWkKSxL6tXt3I5wjcw4fILKXx92n5Y2NMLAOPfQ1BF4Zywd+oNYXV4IUOmu2a5y5W4rxZ999tSkOqSJD/YAUm5ztPft6j9QFiQwQuq/eObybmlEX1UqUHTUb0r78tJsO+/WOVXAbnJZ8IOgAunol5Oiu8HQ56DhtfcgCnuj4RfM2nW3zKjQxCf1z1Cw1H+7CaA2aw3k6VBxZNDB+BQmhM1Y2vdm7NOP4xqlUHgbkdsvbjjyqr8rhl7SY8tvvjP8cF9qzkxzU8Da3ij82Rjc+T53ZRiLVO/rPhnpSj8bvfYgXzVUQRs8EsSaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VtXIKsaoo6fvEkspM37p5TMDLQUd1SnKg2qpc54XTls=;
 b=RSALfKEfzfT4e0SZMThSybXWSBtQcLMdoUk6HQiuLxPii1cwPOvyNljmqquNVwf7abN/4lQjhcawWEOKoXNCnUwXaKdM4nAbfC73/lNs1BljdtN9I7sceFJ+9Vh3Iqvc4l+mHN0vTUJ6o69ESxiiUD8HtP1RxwReR0W8f1pepcbaKZ+hIgV0xygnyCdQKSzfqKLbkEicaVa9Q4+wkldPfp3y+zM3SCzHqrZuqNjPEPL/Ih7o9/UD/RxS7Entk24z8nUfO+/z840Ahu60WGK81RCQcjPbrLtWklShkXc3iUlfIMg+zVY9ATYwo4FQalCAfd/Iu8ivxMzf8pNoe6Y6xQ==
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=VtXIKsaoo6fvEkspM37p5TMDLQUd1SnKg2qpc54XTls=;
 b=QhLBv6JqYKJCMCoCEHkhS3GDU6YczdmQTcVAadYSbauCBGKdUkMp6p9NvPCZXZPs6AqXLi9nJPShJy+em2Pz6w/uZqsIyTOqNy6yzVPP8decrfQej6bYbrUBwOVGwSC6lLHafT36Sq9oOgUVsudAau/1q8sZLuk+h5zJ2R0emSQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	
Subject: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:19 +0800
Message-ID: <20250910073827.3622177-19-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|SJ5PPF01781787B:EE_
X-MS-Office365-Filtering-Correlation-Id: 1e943df5-406f-4760-a8aa-08ddf03d388d
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?9jZHMu8Ju168MCTHwrbORcohN5rYy2Iv+ZnZC6Rj1NWCc8UCM0Qua1GjjdCf?=
 =?us-ascii?Q?L9qQuLpfJHvYBXiX9SXFcWWk4498Lu1zEGzs9pOu0apuGF2WqOzOuKbhP61a?=
 =?us-ascii?Q?53sGo2vZFzQupgW56Qk7EYsXzI4wROZyjb2mZAPZq11+eqzGiqNt+kCXz7ep?=
 =?us-ascii?Q?Dv3dh1wTWcsV4g/l9UB4pup6BGjfKLf4v25w7FySupZgDC2Y8Cg2G4113ltk?=
 =?us-ascii?Q?t7PUgo0RW1psbkPu0Q2iBdPoe4uuFP/tdGKoZC/fMF2drFlZW0YSHvd1g0XA?=
 =?us-ascii?Q?oYbSWalIRYCQ2myF1dL6wvePysC5gyIoWOJBdYL9pU+Re/JllEYb5weHnOaq?=
 =?us-ascii?Q?3vgSopUrjCNZBEt1QyEbUdiVUE09tysAMKMXwGdM2hv2zdzmz83Oj0A6GG/L?=
 =?us-ascii?Q?zFhw1jb0Gc0wOvgG0PYCV1scuKF32XreGk2rVMRVQvIutn63oaC2mD96bQ2K?=
 =?us-ascii?Q?tmlRedzY9fiWl4EfRVorobPLRfAdF+BhJLnWBMLbS2TLUrWdO6QjEXeMtDma?=
 =?us-ascii?Q?NHpM1l9Quk0kio0Qdshdr1U3AHg8jcoZGuFaJ/nwQn7j91pm9n5R1kEiSAx6?=
 =?us-ascii?Q?B6jsUq+/ehJQ5iWGN3j/5z3MD3lB98tJabbkiZZ/E35r4kpgFQbL1CFK9LjN?=
 =?us-ascii?Q?bySHT7mN+cSpiVlIgkpNJYvh8FWAvRMKjCtrmHKuR7zyuSarxtogm367fRel?=
 =?us-ascii?Q?/8QBp9lzAC2vp/AUFSODqAa9MIm6w1nnAthQdrdTtBFTG/LWmgLiGHFw6kn+?=
 =?us-ascii?Q?i9NCdW1zP3lcy51cxKrHfDOAEUo0qdJR1sf+No/VJG3ogNWCSz+vCoIvSi2P?=
 =?us-ascii?Q?L8D53ryNJ+Ip+1zw44sJ0JL/bz3gI1/zbl3sdUd9br87eol2Dad7p3/q3S9z?=
 =?us-ascii?Q?SGNWrE2xM8d3ZvXQhWccw0NjoLqF5Fuu2G9/1P7N4tUa05nxXryvOnA9r6O4?=
 =?us-ascii?Q?jAcmnaDp4Z20EDeHvfNalHEdF1mDj54lnID8mH4bQoVofgV5UQJsaLhXZBw9?=
 =?us-ascii?Q?InwgXdnbvLVGBT5ksA65um9+8ODqFmDugDPuJnuJjkQYCHr+7wfBd7ZbFMre?=
 =?us-ascii?Q?6wAnMJavOqb1C1NliuiBx8E+9WDbca+T6pP+k1+0PmgeSIjgZ8sY/0kxHSEK?=
 =?us-ascii?Q?zg9f8hiR3kGxvnBLfAPzClN8D0KJmzs8HkZ8zIaY8TWOcEwg145fy6edqnYP?=
 =?us-ascii?Q?/8MCXQAzmovFpl0Zt/BODjel8+sij+e24g7rCv5SJnsheXTg3B4eoXBhSWvg?=
 =?us-ascii?Q?ZjWWSEn9wkC8kIW5L1USNMysNNHCOxX/IHrvXVM+P5A4Tx2OjNf1qmIlmK3W?=
 =?us-ascii?Q?iapgqY5IvHd2q4tuMCcfBc4E+H36hbGyThXdcai6JNKFvrVvGODk2DGZV8mf?=
 =?us-ascii?Q?77QwjhOYyXjJhCy9fDK/NXGbJBibjEngrwvTuEGE8yZCwWYhCCuxS5HUqJPe?=
 =?us-ascii?Q?/+85whZryOCeZnI1D8M64rasVORhufA0vShR1W692TpGy537kq7j37UvgiUq?=
 =?us-ascii?Q?JCrFiVNxvtvP28nTWG7+5fkCnL2lHQdz7eIR?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:39:48.8238
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e943df5-406f-4760-a8aa-08ddf03d388d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF01781787B

Function xsm_getdomaininfo() is only invoked in XEN_DOMCTL_getdomaininfo
domctl-op, and it shall be wrapped with CONFIG_MGMT_HYPERCALLS

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
---
 xen/include/xsm/xsm.h | 6 +++++-
 xen/xsm/dummy.c       | 2 +-
 xen/xsm/flask/hooks.c | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 678cb0f346..2a107b2cde 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -55,8 +55,8 @@ struct xsm_ops {
     void (*security_domaininfo)(struct domain *d,
                                 struct xen_domctl_getdomaininfo *info);
     int (*domain_create)(struct domain *d, uint32_t ssidref);
-    int (*getdomaininfo)(struct domain *d);
 #ifdef CONFIG_MGMT_HYPERCALLS
+    int (*getdomaininfo)(struct domain *d);
     int (*domctl_scheduler_op)(struct domain *d, int op);
     int (*sysctl_scheduler_op)(int op);
     int (*set_target)(struct domain *d, struct domain *e);
@@ -234,7 +234,11 @@ static inline int xsm_domain_create(
 
 static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.getdomaininfo, d);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_get_domain_state(xsm_default_t def, struct domain *d)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index f6986dd2bb..7c4e6176aa 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -17,8 +17,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .set_system_active             = xsm_set_system_active,
     .security_domaininfo           = xsm_security_domaininfo,
     .domain_create                 = xsm_domain_create,
-    .getdomaininfo                 = xsm_getdomaininfo,
 #ifdef CONFIG_MGMT_HYPERCALLS
+    .getdomaininfo                 = xsm_getdomaininfo,
     .domctl_scheduler_op           = xsm_domctl_scheduler_op,
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
     .set_target                    = xsm_set_target,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index ed4e466302..7392e95e55 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -604,12 +604,12 @@ static int cf_check flask_domain_create(struct domain *d, uint32_t ssidref)
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_getdomaininfo(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
 {
     switch ( op )
@@ -1889,8 +1889,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
     .security_domaininfo = flask_security_domaininfo,
     .domain_create = flask_domain_create,
-    .getdomaininfo = flask_getdomaininfo,
 #ifdef CONFIG_MGMT_HYPERCALLS
+    .getdomaininfo = flask_getdomaininfo,
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117752.1463866 (Exim 4.92)
	(envelope-from )
	id 1uwFXE-0000PY-Jv; Wed, 10 Sep 2025 07:46:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117752.1463866; Wed, 10 Sep 2025 07:46: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 1uwFXE-0000PA-Bs; Wed, 10 Sep 2025 07:46:32 +0000
Received: by outflank-mailman (input) for mailman id 1117752;
 Wed, 10 Sep 2025 07: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 1uwFR9-0005yo-5r
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:15 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20625.outbound.protection.outlook.com
 [2a01:111:f403:2418::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5db3a281-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:40:04 +0200 (CEST)
Received: from BYAPR11CA0084.namprd11.prod.outlook.com (2603:10b6:a03:f4::25)
 by CY3PR12MB9701.namprd12.prod.outlook.com (2603:10b6:930:103::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:40:00 +0000
Received: from SN1PEPF0002529E.namprd05.prod.outlook.com
 (2603:10b6:a03:f4:cafe::2f) by BYAPR11CA0084.outlook.office365.com
 (2603:10b6:a03:f4::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:40:00 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF0002529E.mail.protection.outlook.com (10.167.242.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:59 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:56 -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: 5db3a281-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Jgu+ly3WHhWEfO+7cVsxDUP9ug7MuTnD5JAOQwCLKpWRStQM9BTfG9IEzgFFsF95krzso2z2OF2/zRKnqxgLoMz1Fdxn3S/6flwObMwnsX2YLJckCpAyOPFd5NiNEQ7D7KhsVmZHwzd2ntLoA0TVlJF//2sR4o0nS+kYznoZLMLbEVawcEMuAT0WcBpm01iMZmvw4IkHKDR4G7C8oX1g8b0ZhYMoxHmf0uaiBpgZdX+OLv+uDGQSWbTlec0K+Mek0Ps6Q7jTkCj6Fvd0ncBHAciM1eBLiI7HrXozmK0WDr6rnfCBTPhsVQPCJjTskKfbzp9ryBrifES4eJwPoOrseQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n0emPBHP6D/uzkCR8knCpz7UD/iYNoUnbmeDyfDnSzM=;
 b=WkTZc73o5HiOSi/vtdpfiAEuzxgf+k2QKAVWHt1btHbYhrHm2zoyRlCprretj51umAI3jzSbOsSyryrbXaziK+03r7twyfW8V3YfRSH0TKfvfczmwyyoFm07Fl43nZ6QI0WQHs/Su9pvcQudfTLix7QdrhyHN7wjnMhBqC80sgqaYLfI9mnMRDn0+NvAJqyJPDGV8s8WJrPboHet7I5g3HDE3NzMH0bcIGRhgj8DPZWRbAt7cVN6HVGLOU9OSwHu5uDRu2oVvRviT5iCBc8RiL3gnsQoXLo3m3GJta6o8JepHzjKu1PaRu4aKy+e0qbwoxOO7+RwewZHIi2CQIEBmg==
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=n0emPBHP6D/uzkCR8knCpz7UD/iYNoUnbmeDyfDnSzM=;
 b=cwJPvFlkMxumyY+YgRNaUVD3kRI2D2jA1gWyIsRhI3SdWjiW6NsRY8frLwypXgABEeUNDmSvtBghUSsEonnT9pOQ6//Oe2tUtp7alJ078oaaAAITfgdUFYzu9KEbQiRiuAZCmXyMUrE4dCxYq75EWEevzqw4EJlN/rEHDIVJaC0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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?=
	
Subject: [PATCH v2 22/26] xen/domctl: wrap arch_{get,set}_paging_mempool_size() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:23 +0800
Message-ID: <20250910073827.3622177-23-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002529E:EE_|CY3PR12MB9701:EE_
X-MS-Office365-Filtering-Correlation-Id: 88974cb0-b7be-48c3-1a99-08ddf03d3f28
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?AoJEheD0KJ92csIToANpgaQcgwi1piMbvsblZZoQSH74qS4ObPRrDEkUTqZM?=
 =?us-ascii?Q?JHmu1y8WS3XbAgyYS4ONhnAVghMzs6X3Va9jJUskyLuvKyLIleSsDjxagxcH?=
 =?us-ascii?Q?ldgQd75begAZ/oBoOWnQHEvhk7Gsb6gEcoglnFu3qj5d+/0DOP7vTmhL+fn4?=
 =?us-ascii?Q?wWKYZd0kpaSShqPyN3BHTM+aQYrUEwTvPxTGXKjzePfYsBoLY0Pq/SsXhTxC?=
 =?us-ascii?Q?ITJZL+lpK7rLK07pwMgOVHNfS7lJZY3nJL8jOsze7W1yImw182fZ2w841f/P?=
 =?us-ascii?Q?GZLiCeDJt9x77+HRqZ17Z4af57c3aC5pegWHHoTmagBPhulwd8v7c266cyGy?=
 =?us-ascii?Q?69K3vSDtPgYwPFGM+zaIq5/RvywEcy1Qa+ajadGSUuDRb2Ky9f9cgO7meFws?=
 =?us-ascii?Q?XqvfuHArqOoh+YJ11jnMivQ7g1oLCymcyKyajwZqFsgQneX1y7VPpNyWikEu?=
 =?us-ascii?Q?kxtRKGbZnUtsqeuLu2NFaFVIX0iDs1vin0gUvmj7IpDyBS8LHu6kO7bKS1xf?=
 =?us-ascii?Q?LSbZqIWkpSXwfQ+bju9JSCAZPSFEaTFcsqsB8zl0Au+pMgiU8p8Hq88f8S9H?=
 =?us-ascii?Q?0Q0Ux6rMjJnGFEk+SBhpWjQl1Xilks1v5LhG4ufmwrp1plcOqogedtt4vvvK?=
 =?us-ascii?Q?krzPxhqzf5+L6QiFUsKtVwuEbPeYPzJA/DCO9FlCWk1YaatcnmDpM4Wg8VyU?=
 =?us-ascii?Q?KxQhu2ODJc/bR5LoGGOswIOaWhKMlq/XEaJxvvIb0qgLW3SQ0Ni4rakEIgVI?=
 =?us-ascii?Q?jlXeXQiMbt8y9piltWpJGliLlOeMR75/LPSTfUAN6zU++axPfURUKhZGueXO?=
 =?us-ascii?Q?4RQuSdNzAPHQJvP+DXx3aW229oWIzmuj/E6Ms95nk3UsGGCO092oFt25Hut6?=
 =?us-ascii?Q?3XLoZbFOvPhaPky34YveQ3jLmxjf/CxXj2wW191Ru8pHmUUp6DHKQlHDnsKh?=
 =?us-ascii?Q?CcPQlIobny7pNoklWjjcwEnB9z1w08KzE7F1Q8/DID6kVuqRi1rDpYpArp9h?=
 =?us-ascii?Q?PoD5wjmjC8rJ+kpuZllBx9kz+fdaohgggH1HWPgp2/20qOLlCg6zaDDyLHnw?=
 =?us-ascii?Q?dZ3/+Ox7tKku8nApTVs2uLCsqGdJyCS0A0C6bm/IxoD1XHaiavFWSz+q7S0O?=
 =?us-ascii?Q?UlkjlYfKTTrCC0cqD1C2rGhi+F2iyInFZ/tEnmj43d/6vWK7H70rWvnHnPJ7?=
 =?us-ascii?Q?NtBC1xmFsy+PHhY8atebWbfNy0MLMpt4HUkcLGJNAwLRScTCMNyEUQDlzwpQ?=
 =?us-ascii?Q?Ss+NtebgDKBHpLIM0uJdPAoDHIrDRfb5KCLTX7abAOGUakl+XBJbE9cyTDYF?=
 =?us-ascii?Q?IG6ZqzEyJIzftFJ1mAH1Qna01wUlI/tTHEqfpZU8rEbhRNmvxu3irPGrNk0O?=
 =?us-ascii?Q?Asmosg6n0brihE3hz7fxRlY+4OJ4RHmr4QuytZi3SXoGHyYSbj/gl14Y1UZV?=
 =?us-ascii?Q?snLRPolH8bJccLCfVRJAD9Cxpx5ePXND1dZw81F1RL+gt3Bz+nkuNHWlW7oW?=
 =?us-ascii?Q?M46CnjzHAwp4WJw3rbpDQfVSHyMKffFETyQq?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:59.9070
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 88974cb0-b7be-48c3-1a99-08ddf03d3f28
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002529E.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9701

Arch-specific arch_{get,set}_paging_mempool_size() is responsible for
XEN_DOMCTL_{get,set}_paging_mempool_size domctl-op, and shall be wrapped
with CONFIG_MGMT_HYPERCALLS
Wrap XEN_DOMCTL_{get,set}_paging_mempool_size-case transiently with
CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_{get,set}_paging_mempool_size-case transiently
---
 xen/arch/arm/mmu/p2m.c   | 4 ++++
 xen/arch/x86/mm/paging.c | 2 ++
 xen/common/domctl.c      | 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 30d6071e91..4caa5844e4 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -58,12 +58,14 @@ static void p2m_free_page(struct domain *d, struct page_info *pg)
     }
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /* Return the size of the pool, in bytes. */
 int arch_get_paging_mempool_size(struct domain *d, uint64_t *size)
 {
     *size = (uint64_t)ACCESS_ONCE(d->arch.paging.p2m_total_pages) << PAGE_SHIFT;
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Set the pool of pages to the required number of pages.
@@ -122,6 +124,7 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
     return 0;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int arch_set_paging_mempool_size(struct domain *d, uint64_t size)
 {
     unsigned long pages = size >> PAGE_SHIFT;
@@ -140,6 +143,7 @@ int arch_set_paging_mempool_size(struct domain *d, uint64_t size)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int p2m_teardown_allocation(struct domain *d)
 {
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 116389d4e9..c6e3996093 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -949,6 +949,7 @@ int __init paging_set_allocation(struct domain *d, unsigned int pages,
 }
 #endif
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int arch_get_paging_mempool_size(struct domain *d, uint64_t *size)
 {
     unsigned long pages;
@@ -991,6 +992,7 @@ int arch_set_paging_mempool_size(struct domain *d, uint64_t size)
 
     return preempted ? -ERESTART : rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d36885aeea..c87c28cea2 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -847,7 +847,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     case XEN_DOMCTL_get_device_group:
         ret = iommu_do_domctl(op, d, u_domctl);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_get_paging_mempool_size:
         ret = arch_get_paging_mempool_size(d, &op->u.paging_mempool.size);
@@ -862,6 +861,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             ret = hypercall_create_continuation(
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_set_llc_colors:
         if ( op->u.set_llc_colors.pad )
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117756.1463871 (Exim 4.92)
	(envelope-from )
	id 1uwFXF-0000VQ-6Z; Wed, 10 Sep 2025 07:46:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117756.1463871; Wed, 10 Sep 2025 07: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 1uwFXE-0000U5-Q3; Wed, 10 Sep 2025 07:46:32 +0000
Received: by outflank-mailman (input) for mailman id 1117756;
 Wed, 10 Sep 2025 07:46: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 1uwFQu-0005yo-3n
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:00 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2417::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57c69ddc-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:55 +0200 (CEST)
Received: from SA1P222CA0047.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2d0::20)
 by DM4PR12MB7549.namprd12.prod.outlook.com (2603:10b6:8:10f::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:52 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:806:2d0:cafe::86) by SA1P222CA0047.outlook.office365.com
 (2603:10b6:806:2d0::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Wed,
 10 Sep 2025 07:39:51 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:51 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:48 -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: 57c69ddc-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Oi1oEnzCXoywaEC4Krshfh+wk40FigGtYgLQpurH0kNhmVYbRvEN0klh0TddLzk/KFL3plUkfX4CoUZW1sX8YzOzudSyi9rAsHewpBUO5SP2OyDY3MJHYHByXJeuBx3GGZQzr0jRzMu0TUNaiFr+iqegVYY+Dw2k3Nymqm82ZeOOFB/vXRcsfiSfBWWuTCL0OsR3+J8FgIs2cZzqiJUUoK0kqFh2/exQ4OhiDle7wc2eKR1M1m24nJKy/KrvYBZOXw7BeHTbe7ubpfURBLH1d8uVmov1kJFBrbHYwirtXJegLnmwzdlQP/EUo6J/Mk7i7lGPuyDmNTQvC8Dzg2/bzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZGyZbWaZfEIBYiIhPUBicJ7ty970xz/buEsqX2eLXCg=;
 b=Tcmzjg3cOilBkuaLwYaE+lMGIbeijHA9lDgMbvdVRe5F/rmHa+884XoEyRQ21WQs/14zBEKVJVFPHCmxNknENuLLw2X51ehXr2iTNIOdwuzKo0+kYh3o8GmwDhj3IfR20VrP1naehgLetM773+xsEWS91LCpnCPZ0AuXJdCgqxzajm7CGbGKSBcAKlFS3VT9tb4wprR9VMZzBRFHatL0pQWk/cigBlwtc0FnSf6CBgwUwfrDVZZb8jYW2u6mYWPXBeec7iaXRUi+cp5lkidHw4vt9rLKrQCnu4NnB1vqrKvJOU9GSFgqwhhi56doLnpoH5B0MpKg2RJGggyke8rFAQ==
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=ZGyZbWaZfEIBYiIhPUBicJ7ty970xz/buEsqX2eLXCg=;
 b=0sq8xIeTBqqObh2NU121hzp/yNyZ9TWkdp4VQH/Tp7CmbvLotV5w6gJaT3grNf+PTq+r8OaRoQXJXg8U6NsCYOIWKYGZOmNbspAEQc7B1WQAtO+bLagq8WT+PYmseyktb21pKPHtfFXgJh7w0jxwIVAuRaAlztF3vVtfy9L9+9U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v2 19/26] xen/domctl: wrap set_global_virq_handler() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:20 +0800
Message-ID: <20250910073827.3622177-20-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|DM4PR12MB7549:EE_
X-MS-Office365-Filtering-Correlation-Id: fe2d45ae-03c3-4073-dfd1-08ddf03d3a60
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?qT2NZjLdFfcQ9P54WrIz1xqSJc90Sbh29bQ+4yvC9P7k1KsIIEkJ215hCBgr?=
 =?us-ascii?Q?UFRC3mnRf3t93y51aJR6vHoBPy004qNGUywwGfQ6HQ2sJ/5j+o4nfgDKVovS?=
 =?us-ascii?Q?q55Yy9vkygNIxRaUr4Nfdfrg+6zQMA5dg8zQJzvIs5jEJLr5wJf9FehZQIPi?=
 =?us-ascii?Q?DN7MC3clyCTuse5tBFdq22zF0X3U1L1xeTqkMlMVbvEdVqhvh7h2FDYBd45N?=
 =?us-ascii?Q?FDgPyTpfbz7/wIHzYLXcDgo9Yqqy9Hu31MUsPSGA0i2NcIi2d48pPZF2C23w?=
 =?us-ascii?Q?vX/paTARys4HGoNVndTfdKPHeUINqQsBUNKI6nsp+Ykl9530hubkriYScks5?=
 =?us-ascii?Q?xmseX0wHnOANgx2AJYYEedN4OQU6704+/xuhOTrlOYnSRnfAKtSv7HjL8rk3?=
 =?us-ascii?Q?xa97YKOlamz09sX4XeeyKT7GodIs2XKqxPE129Z25mtKqgw8l9Uyp9kzzXAu?=
 =?us-ascii?Q?NTPHoeGN1pkMht/c4UH6jOYcLCOYwLP8PaDbbqbEr3SgPDG7aNK9RBa2OUDS?=
 =?us-ascii?Q?4uCc6Lsq0zx+/B66/0wLW1vmEwFogMFXw/o2aV9h9t2bzE06OJHVtVPBGCaa?=
 =?us-ascii?Q?zQVjv3lC2tRKKU2WKqT87nFDaXKcIju2UQMNH2W4eQAP7ccvTlbhENhy7jbU?=
 =?us-ascii?Q?z2t1hCoG24mLtR5GExQEM1EsIlzHtguPaLC21Gzn6nMIFV5NnBWhfmx+S0Pp?=
 =?us-ascii?Q?8Bxt4Kv6FG4LTEmZPE+qnpQP2MJo7Av7UrzfcwRjnbdRZ4bYIWs6ZwhtE2i6?=
 =?us-ascii?Q?C5pMXw7Z+Iw/ffToHEOzo9NihgzO6PqXTRfMZBwi0xlbelORn09dMpWcGfZG?=
 =?us-ascii?Q?dz7/ZZ/hI5rzU0QYjcAdlM6DLWH2GECaF1KhRdx6LIif0oH98LDKk04tJWOm?=
 =?us-ascii?Q?3S0pOWJMnoT5+T3ttVMC2FhE7PLzFoIcmz7y/E2xgbGCHIuKn5hVUJdJ516h?=
 =?us-ascii?Q?cJ/Tytzud7EJwyWj4mUk1R8otP18WklVBxlHSpk7X63+EeZcUTq41YDlE4cm?=
 =?us-ascii?Q?/G7tbi05GcxQB+xpwiKAKOckN1RFmJ1881z5gOmFkIkb3TKr80W5M48EGicE?=
 =?us-ascii?Q?D5sMSjUBzDuzBGw+OhqI2uacaKTxJFD0b01jn/2C0AqiAP23SYWKNwnPjAef?=
 =?us-ascii?Q?nY4MDogSajAO/3NAU4cOVeX7JoHazH1e+iRuCB16UnI2fADvvG984R58XRnI?=
 =?us-ascii?Q?uQ3clXsVDlh+6FWoPP88zewGJB6cPLyjGHfDoG/CnXt543+lodpi0effQg3T?=
 =?us-ascii?Q?uplO/HCLYeT20TE2gvly6MJ34OYBTSSUJrDM9I3bcKgRAWQy6cX74JEEDaV+?=
 =?us-ascii?Q?7VCUEMx169Ziur4wGfmUtDCxv+2MSlFgFjw8TODd5i92WvREcilpCiP4AvJ8?=
 =?us-ascii?Q?5a3O0mS9/78/EWckiQFPpUBwvmdLKZYIYFnnmDDw0MKOxthLrVCmUEnLT8xT?=
 =?us-ascii?Q?uhbNwjUtjxqB9BjmBBtvIqLjkshRIXqFuUjnQD4ILDYnaYO1Th1IfHDK3Mp5?=
 =?us-ascii?Q?bYh75cDVpndq49Ytwvup8lAd1E1KrKeVyO7X?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:51.8857
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fe2d45ae-03c3-4073-dfd1-08ddf03d3a60
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7549

Function set_global_virq_handler() is reponsible for
XEN_DOMCTL_set_virq_handler domctl-op, and shall be wrapped with
CONFIG_MGMT_HYPERCALLS.
Wrap XEN_DOMCTL_set_virq_handler-case transiently with CONFIG_MGMT_HYPERCALLS,
and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_set_virq_handler-case transiently
---
 xen/common/domctl.c        | 2 ++
 xen/common/event_channel.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 776bf7b8e2..736ad52265 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -808,9 +808,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
 #endif
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     case XEN_DOMCTL_set_virq_handler:
         ret = set_global_virq_handler(d, op->u.set_virq_handler.virq);
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_setvnumainfo:
     {
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 67700b050a..bb53dc1fb0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1006,6 +1006,7 @@ void send_global_virq(uint32_t virq)
     send_guest_domain_virq(get_global_virq_handler(virq), virq);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
     struct domain *old, *hdl;
@@ -1068,6 +1069,7 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void clear_global_virq_handlers(struct domain *d)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117780.1463885 (Exim 4.92)
	(envelope-from )
	id 1uwFXK-0001TU-CP; Wed, 10 Sep 2025 07:46:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117780.1463885; Wed, 10 Sep 2025 07: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 1uwFXK-0001TA-5p; Wed, 10 Sep 2025 07:46:38 +0000
Received: by outflank-mailman (input) for mailman id 1117780;
 Wed, 10 Sep 2025 07:46: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 1uwFR0-0005yt-94
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:06 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20610.outbound.protection.outlook.com
 [2a01:111:f403:2408::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5c3444b8-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:40:02 +0200 (CEST)
Received: from SA1P222CA0041.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2d0::15)
 by MN2PR12MB4205.namprd12.prod.outlook.com (2603:10b6:208:198::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:57 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:806:2d0:cafe::b7) by SA1P222CA0041.outlook.office365.com
 (2603:10b6:806:2d0::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Wed,
 10 Sep 2025 07:39:57 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:57 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:54 -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: 5c3444b8-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KqBPYcF+RKgCzD8AbvT4f+rcbgu9knei3BvSOYtE1ybXUFghYm4mESW/rO8YYWEzYH8ltkO5l12OEgzdTzHNhWhFGJq1JgJbpZLEuNd3TdMb/++RAAVHmPu7FiWxs9bVZZQ9dNmNukRnLsFZnUysGyimbo3ipNFUDLgao6+tSuieEvDIc/5pjQ3vDMSpXB7JQozuV8hzuLo3y2ZpOjoMVxnrsGqahyxbqNnBdKAcC88DrEFW4tFC3yzg0dU8C1sFD3gjYL18nEj9imzagW332DpXApXhGi/kXKv1pSjk/Lo2bNn3eSkGQOhrNXovoc1sXozUkqlWGXsQZCWuqQK7SA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iJfzE4HwZb5sVihZocpi8ewX0y4oS0xM9b4IWEsHGt0=;
 b=lkZAarVVClCAEsVGn7VrAavyEl15skNJQjiOGUDj5JNpCozs8pxtFtkJJylcxZ6EYr+WsSIWXF8ctkpamCtvJzO6kjQSLvJQIASJtLpDNKZubmP4QGgChn3f+FUduZMlZxssfLYWbiYtvOSAQ4/5UvXlita50WZK93vGI8U047W7h+RcW11NgLIVombVrs3dBW5H7IatsgPrQiOCR6g8ODprvOPwi38+kghHQ1ppwko2o7LAEy0jrttB/hGC35sRGdSBaGOshqtXeFe7tgX5lug+vn1kXQJmlneexowjIS6wOiG/J8WHgPz0O5QRMzUCWLaw9x+8GKKR/ECfznbWIA==
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=iJfzE4HwZb5sVihZocpi8ewX0y4oS0xM9b4IWEsHGt0=;
 b=e6oyERvrzddm3Aw1s1m9T4ueHchzMjZfJ9rtbfpauYVdnU5IKcp3y1V/j3glFSHoN+0opzCp+7itksDb3SgxPcqpw8szuI81BwOkMER3w+jCOpd8canA5zGu6rH23rNdyfdnMv8pWlp1/cQ+rXfAj/mHy9F63MeEobQg85togDM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	
Subject: [PATCH v2 21/26] xen/xsm: wrap xsm-iommu-related functions with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:22 +0800
Message-ID: <20250910073827.3622177-22-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|MN2PR12MB4205:EE_
X-MS-Office365-Filtering-Correlation-Id: 550f3be7-1fc4-4f66-dc17-08ddf03d3d98
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?6ydOHPw1pzXH7GR+ozWSShGISrmGMUlAZfyYSoK2g1I/6ZzJ0oEz2qOtpOcK?=
 =?us-ascii?Q?Npm2hJwYDzwDw3nCz3FSCH138j7eu5OQO28CEuFtlPGtEFTa29oicXbBvL3V?=
 =?us-ascii?Q?dAQRIn2nz83+w+Vvv3V18m0IP4yCPnXg0PBWSd5mSXsazrv+JiOmJHxp8RlN?=
 =?us-ascii?Q?Az9mMN2EgzUAplaDJNfbcJpTAS9LUlwJnEWxbxH8FcRnWGXT0Zg2pOiO7PDN?=
 =?us-ascii?Q?KEOCv0lYE6D9XYxcxDGhwW+et3Aczb3Xo+9veG0ksCG9q7W2t5CqvSZY0Ixm?=
 =?us-ascii?Q?NKuRwqXh0mOZp1MWif9HM+gFKBoeROEYlTgKONASglg+RiVAOnRbj4uHckUX?=
 =?us-ascii?Q?yMvjeGKxBCK9A71sFBj317ulapd/s5Tr6eo0cnHoXGUkS+chYgYLlSqQ0spR?=
 =?us-ascii?Q?GuZGci5Yq8fhfko2nKs0EpSIBlBV1VYdTqlwYiVEgTHFsxe02ZyTs7uNGlGR?=
 =?us-ascii?Q?nRr2frhss9CiXroQ59Ii+PcM+r3C6t2B18fj6zbhc09EUUPUwtok/ce4dqlc?=
 =?us-ascii?Q?dErHpChW9EkYG0hn/OYpEYiPmL6plRRt3o7Um5mNda4o1WamosOFcH+hJjnP?=
 =?us-ascii?Q?O24sT9xTuxEW0o27Wgbv9hgYl+XrRcd15EUMZBaoF7oVi97x8hFDZ98t80Tr?=
 =?us-ascii?Q?6UZ0CehyiyqWZ5NhOjEJ7ydrzQxKcNyVq09xHV5ekJdvOCGTzvoy4vHFjtuR?=
 =?us-ascii?Q?L9GtqYVyHzMw+5yb5Q87tpZ+1nIQdqDACuQRy8juCXzlGd0fDlsEdRzVpBrZ?=
 =?us-ascii?Q?+gD/q6tqeMS93/39c99gzfpXb2Eu0zhghH1bCoAE2fFylHxlZPXRF8bf2BVY?=
 =?us-ascii?Q?UyAYcyt9aBA/dc4NqzC5GYr59LplZWlilZMqtuM8ktceahshIxgaxtCfXnx3?=
 =?us-ascii?Q?3yEqqFs1v5nsATzZdzV1T8uhcw5af2pK4GuSlEN1nLzy9x2sLcjMT2xXp8F8?=
 =?us-ascii?Q?shSKHj/ssZEDj6/jFc63IuEqe9CVr8mhmFNeRfF+gK9OJR2ld+bWb+aX2M0C?=
 =?us-ascii?Q?udgX6TX+lIOd9d8EoB/na6OGd79churSEXnY7+RwCD+BoU/rGpW4gOKaCfKV?=
 =?us-ascii?Q?0WLAgsCFiOwiOtfVhvtvw1JUji1+4K/mbpINB4E7FdZr+s8vZupvtASa1/85?=
 =?us-ascii?Q?rzwWEl5467sAoKEcf2TgXIhQbf6EfACobVmXydo+byZp0eV1r/FYIKU0jCYb?=
 =?us-ascii?Q?X/PCfkAFKuA636FFCRfw9yzt5jOryQ6PyD/72VZjq7jbPt/BQ8pdwUM+afb2?=
 =?us-ascii?Q?eEQa4oqNSAzCtQHsX0iWwBiLVr/tN/asMSHPWJCKQsGg6xjUGbfBaEPHUfr9?=
 =?us-ascii?Q?nQZBRdlP7uVdFpBAswUmXelrzrft0bUrtihXiLKpxVvDeP4XccLQGrommCKu?=
 =?us-ascii?Q?7TCMIHiclH737hVLuPiB90G/nA+sBiERlbf+eYQ5c48yDh+E79ZmH8fhfmZ7?=
 =?us-ascii?Q?QMF2VnJQJ8Uy51wwOucQHiVsTPVySmhAR8dSbgz6PaZovv2WSID6p6SNix3u?=
 =?us-ascii?Q?nszFOAwKxcD+fkoLqxTTZhjuC1X0SAt3qhJb?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 07:39:57.2843
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 550f3be7-1fc4-4f66-dc17-08ddf03d3d98
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4205

The following functions are xsm-related and only invoked under iommu-related
domctl-op and shall all be wrapped with CONFIG_MGMT_HYPERCALLS:
- xsm_get_device_group
- xsm_assign_device
- xsm_deassign_device
- xsm_assign_dtdevice
- xsm_deassign_dtdevice

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- new commit
---
 xen/include/xsm/xsm.h | 12 ++++++------
 xen/xsm/dummy.c       |  4 ++--
 xen/xsm/flask/hooks.c | 12 ++++++------
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 2a107b2cde..542488bd44 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -123,13 +123,13 @@ struct xsm_ops {
     int (*pci_config_permission)(struct domain *d, uint32_t machine_bdf,
                                  uint16_t start, uint16_t end, uint8_t access);
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI) && defined(CONFIG_MGMT_HYPERCALLS)
     int (*get_device_group)(uint32_t machine_bdf);
     int (*assign_device)(struct domain *d, uint32_t machine_bdf);
     int (*deassign_device)(struct domain *d, uint32_t machine_bdf);
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY) && defined(CONFIG_MGMT_HYPERCALLS)
     int (*assign_dtdevice)(struct domain *d, const char *dtpath);
     int (*deassign_dtdevice)(struct domain *d, const char *dtpath);
 #endif
@@ -548,7 +548,7 @@ static inline int xsm_pci_config_permission(
     return alternative_call(xsm_ops.pci_config_permission, d, machine_bdf, start, end, access);
 }
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI) && defined(CONFIG_MGMT_HYPERCALLS)
 static inline int xsm_get_device_group(xsm_default_t def, uint32_t machine_bdf)
 {
     return alternative_call(xsm_ops.get_device_group, machine_bdf);
@@ -565,9 +565,9 @@ static inline int xsm_deassign_device(
 {
     return alternative_call(xsm_ops.deassign_device, d, machine_bdf);
 }
-#endif /* HAS_PASSTHROUGH && HAS_PCI) */
+#endif /* HAS_PASSTHROUGH && HAS_PCI && CONFIG_MGMT_HYPERCALLS */
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY) && defined(CONFIG_MGMT_HYPERCALLS)
 static inline int xsm_assign_dtdevice(
     xsm_default_t def, struct domain *d, const char *dtpath)
 {
@@ -580,7 +580,7 @@ static inline int xsm_deassign_dtdevice(
     return alternative_call(xsm_ops.deassign_dtdevice, d, dtpath);
 }
 
-#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE_DISCOVERY */
+#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE_DISCOVERY && CONFIG_MGMT_HYPERCALLS */
 
 static inline int xsm_resource_plug_pci(xsm_default_t def, uint32_t machine_bdf)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 7c4e6176aa..2c8e0725b6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -81,13 +81,13 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .pci_config_permission         = xsm_pci_config_permission,
     .get_vnumainfo                 = xsm_get_vnumainfo,
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI) && defined(CONFIG_MGMT_HYPERCALLS)
     .get_device_group              = xsm_get_device_group,
     .assign_device                 = xsm_assign_device,
     .deassign_device               = xsm_deassign_device,
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY) && defined(CONFIG_MGMT_HYPERCALLS)
     .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 7392e95e55..66d8bfda3a 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1393,7 +1393,7 @@ static int cf_check flask_mem_sharing(struct domain *d)
 }
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI) && defined(CONFIG_MGMT_HYPERCALLS)
 static int cf_check flask_get_device_group(uint32_t machine_bdf)
 {
     uint32_t rsid;
@@ -1464,9 +1464,9 @@ static int cf_check flask_deassign_device(
 
     return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
-#endif /* HAS_PASSTHROUGH && HAS_PCI */
+#endif /* HAS_PASSTHROUGH && HAS_PCI && MGMT_HYPERCALLS */
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY) && defined(CONFIG_MGMT_HYPERCALLS)
 static int flask_test_assign_dtdevice(const char *dtpath)
 {
     uint32_t rsid;
@@ -1527,7 +1527,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_DISCOVERY */
+#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE_DISCOVERY && MGMT_HYPERCALLS */
 
 static int cf_check flask_platform_op(uint32_t op)
 {
@@ -1993,13 +1993,13 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .remove_from_physmap = flask_remove_from_physmap,
     .map_gmfn_foreign = flask_map_gmfn_foreign,
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI) && defined(CONFIG_MGMT_HYPERCALLS)
     .get_device_group = flask_get_device_group,
     .assign_device = flask_assign_device,
     .deassign_device = flask_deassign_device,
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY) && defined(CONFIG_MGMT_HYPERCALLS)
     .assign_dtdevice = flask_assign_dtdevice,
     .deassign_dtdevice = flask_deassign_dtdevice,
 #endif
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117782.1463890 (Exim 4.92)
	(envelope-from )
	id 1uwFXK-0001XY-RR; Wed, 10 Sep 2025 07:46:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117782.1463890; Wed, 10 Sep 2025 07: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 1uwFXK-0001WY-IK; Wed, 10 Sep 2025 07:46:38 +0000
Received: by outflank-mailman (input) for mailman id 1117782;
 Wed, 10 Sep 2025 07: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 1uwFQj-0005yo-3f
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:39:49 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2417::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 53252909-8e19-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:39:47 +0200 (CEST)
Received: from BYAPR02CA0040.namprd02.prod.outlook.com (2603:10b6:a03:54::17)
 by DS0PR12MB8785.namprd12.prod.outlook.com (2603:10b6:8:14c::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:39:41 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::31) by BYAPR02CA0040.outlook.office365.com
 (2603:10b6:a03:54::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:39:40 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:39:40 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:39:33 -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: 53252909-8e19-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rLQtwpKNOKsS/CzxcatW18qakE6cQqe0QaPyQ2ljIg/zoh9hDGUuMvT6YZVPXh5sYV47HAS2MDGSq9ShHQT45SYiOWM1rZp4t4Uj6dl7E46H7teoE4D4EN7+593Z0Bb7BRbq0UrF0H0cjYU5vPU6cb4zZvMUK7ZrU7/FXSxo2qNvwOnT6PGDvzEsxsNrDZ6BVT1+cN+qZS2efqq/H2leRwcIU2e1+YN5JfP6AxAq0Ivk+iTxv+ebhExq9HBYVli/7M1BnI8AT3NLdWhMHCrf0W4PhcsU67zok+CbxUFDPjuWyalx6ZwBUqkpyT9oaX6KxdzE+SsVS2rHJrtx7VzJSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jBscWAwzK16wFtb9z6LG5pktl/B8WuF9ILjHfhMxcXc=;
 b=TBJmYbpONSrYGberD9I7IYWcM3s9nsei2jzfkNgI1ZMjeD3f9rdUuMuaEgnt4CPnbxSzStZZhY4rSUluWlQS5h/r4IUl/vs83WXaZE91RNoFaKGeNK754pj7Oyahol87F29mcfmwUodmD8wIHRNlnzcxb7UtiLl/l2yOemobFF7VmvkPBf+Gt/tQSzV6MCpJhQoNBe7PYyhgT7UFsN7SjExPIj+4XbXgkrXpJe/YTM6bMPc0uRvsZ37/Do2rGCUig2no58++KhNdTLQBXqgx6Yo2tH3nG7l786ex0t78NxO1azNbtC+cTiK2DCK1kH5YJ7jjWHizvLBmfsSSH06maw==
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=jBscWAwzK16wFtb9z6LG5pktl/B8WuF9ILjHfhMxcXc=;
 b=qAt17ySYEfUooD+ufmDQpeJ+ycAzKJeMVPc0NEDMgzs8XZPImH+clFqKTzpCRm2+8Jo+2mhsyA1KrHlnhIYxHT01V84Jy/fDUilFd1Oud1Osj15Epm7eRb+OB7Q3VilcpbDmMO0zKAZcIoJTMxLHwCxctcV3j9vltW1Ik8vPoaY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 , "Nathan
 Studer" , Stewart Hildebrand
	, Dario Faggioli , Juergen Gross
	, "George Dunlap" , Meng Xu
	, "Daniel P. Smith" 
Subject: [PATCH v2 13/26] xen/domctl: wrap sched_adjust() with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:14 +0800
Message-ID: <20250910073827.3622177-14-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|DS0PR12MB8785:EE_
X-MS-Office365-Filtering-Correlation-Id: 9ee1863f-a267-448b-a3e3-08ddf03d338d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jVXTctrDvl3wlkNfBuVVpD9gZFY2gxBQLv+0jini/bDm7TcwtIDfri6bk5fM?=
 =?us-ascii?Q?fAkkolFgbvCvRov7JexpIBVOaw2CYmTpFF1YeV5AQ7UR8PNRUlhUXxFDW5aG?=
 =?us-ascii?Q?/eJiZJRdTe5NYQX//N7xUNcaOGhn2F8iMEVF5npKx8usbCkO7UUM1SDaSarJ?=
 =?us-ascii?Q?v+8PqXp8hqCausEGh+I15k/Jkzaa56oiNh1q2cyFISY+FTF8dML0SQNqZmdr?=
 =?us-ascii?Q?0fKARLBoSkF1H7+DFdlGxTbDS4kIs1LicrD1UfrvwMBek+08avr8LsUoXX4Z?=
 =?us-ascii?Q?W97n4C+PpWmbyw0DNgdoEZF1ozh5BJqu19VWMjT45t38k9ja+3xNGPYeefVo?=
 =?us-ascii?Q?lhX0ePOOUKW2VV2uPaLyd6KCLlAlc53BrPGf5frBf+6LMzGWtrtN3M7JVgCZ?=
 =?us-ascii?Q?FqrKzeADv+16au7DNGlseDe61RVPohLmqyC9UMZdcuWNsi3xMJRZjnRG8Tt9?=
 =?us-ascii?Q?HpUO3Ws3Zx8mctqY7wly+ffXkU4kWQkcfqm3lDPZS2aEVnx1qXCR9IwxFCIg?=
 =?us-ascii?Q?qRUHcInoia1CRhd5r0h8l3clhoMzmG5e+oVjFWwskP1j3C9jb/xIyJ2r5wZC?=
 =?us-ascii?Q?XKhBbFLrfMy02wdzEqmRLnbssGfQ5LnhXcnCSY1k9fLq87kXnrpPKt7HLF4F?=
 =?us-ascii?Q?OcPNZFkRSrfSLH/GuAim5B2LmGCQaJI/Uu6gSIj/2xn7tde4R48fWPe1+DfV?=
 =?us-ascii?Q?BMFTUTLV+P23iGilznN/JuLoqsi9Ge1h++yAAPXOad/L7GnfbSgeZ8Q0mMPk?=
 =?us-ascii?Q?eQF7s2mH9cKlMy3yT/m/s9ksTKDqnC5Gs+zwn7agQB3YUVD8vhn5vTvrAhq4?=
 =?us-ascii?Q?NiWhCUPbgW5rHIfIz1cXpO1WWi1nB62oDf2WM7NFUPci72zyleO1ocV7/6nx?=
 =?us-ascii?Q?DrWGQQXCZC3u+T4Pk0HvmC7yiiF+F8Ty6GQhKIm7m5xjNGiSE1SXWs0ucLHD?=
 =?us-ascii?Q?M7VTdtWBerJcTxvi+mc9/YHV8AQ7UxzdDMx6og/Zp8UOVTPCAipkgZHmOCu9?=
 =?us-ascii?Q?NKM4JsHJO4UqwY2EsIgEi7IK3v4opoJQQI1CyAOA0Yxsti6ZTzs9qiYeR3aO?=
 =?us-ascii?Q?NpNH5RBWRF72FDPaSOUlgymZ7zPuYRVeARJW1U8wMCx8DQiaUVXmZVQfsDXt?=
 =?us-ascii?Q?EZ0PPOkaVLT0LBkdDqKeBiwu9dUlr7FKfcAOAEKLQEdtz++BOBsl6meS2Z3L?=
 =?us-ascii?Q?H9NwvH6ARIvAW6WbcIlLjaewl+l3iFoRYoclKQzQyqnI0T7nv2WaBoqrGvmB?=
 =?us-ascii?Q?2pwnsIE/N8Jb9vXyq+tSbB4eKr8fbrm5zwA8hcNb9z5RV1Jd8ASTd+2PAf4h?=
 =?us-ascii?Q?gsXv/N5joaWDpOq1uHH3TVUJ4+WuexUGCKQ6Jetls6S2NhMTm++qV/9DFrLP?=
 =?us-ascii?Q?Devjf6INfGrnW+x8OX+awDLo6/Xuq2oUvf7WhEiEgwdYM0jaTk/dw3sryS9j?=
 =?us-ascii?Q?0OaWq/Ctr2DMfGQ0B2tW9uSOxCJ4v/z5fkypmIzfFuLrXyIk1KuY19JL9aFM?=
 =?us-ascii?Q?kr74nWQb7qjzBcgaV/B6d2KLNTFspp5kjqvf?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:39:40.4334
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ee1863f-a267-448b-a3e3-08ddf03d338d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8785

Function sched_adjust() is responsible for XEN_DOMCTL_scheduler_op domctl-op,
so it could be wrapped with CONFIG_MGMT_HYPERCALLS.
Tracing its calling chain, the following functions shall be wrapped with
CONFIG_MGMT_HYPERCALLS too:
- sched_adjust_dom()
- scheduler-specific .adjust() callback
- xsm_sysctl_scheduler_op()
Wrap XEN_DOMCTL_scheduler_op-case transiently with CONFIG_MGMT_HYPERCALLS,
and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap XEN_DOMCTL_scheduler_op-case transiently
---
 xen/common/domctl.c         | 2 +-
 xen/common/sched/arinc653.c | 2 +-
 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/common/sched/rt.c       | 4 ++++
 xen/include/xsm/xsm.h       | 4 ++--
 xen/xsm/dummy.c             | 2 +-
 xen/xsm/flask/hooks.c       | 4 ++--
 10 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 4a35c17060..6660f13e9e 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -520,12 +520,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     case XEN_DOMCTL_getvcpuaffinity:
         ret = vcpu_affinity_domctl(d, op->cmd, &op->u.vcpuaffinity);
         break;
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_scheduler_op:
         ret = sched_adjust(d, &op->u.scheduler_op);
         copyback = 1;
         break;
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
     case XEN_DOMCTL_getdomaininfo:
         ret = xsm_getdomaininfo(XSM_XS_PRIV, d);
diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 7d6c40d800..484591a977 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -735,8 +735,8 @@ static const struct scheduler sched_arinc653_def = {
 
     .switch_sched   = a653_switch_sched,
 
-    .adjust         = NULL,
 #ifdef CONFIG_MGMT_HYPERCALLS
+    .adjust         = NULL,
     .adjust_global  = a653sched_adjust_global,
 #endif
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 69972147db..8a3251ce5f 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2078,7 +2078,6 @@ 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)
@@ -2115,7 +2114,6 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
     return ret;
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 {
     struct cpupool *pool;
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 0cbec2a9c0..da57350cae 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -1183,6 +1183,7 @@ csched_unit_yield(const struct scheduler *ops, struct sched_unit *unit)
     set_bit(CSCHED_FLAG_UNIT_YIELD, &svc->flags);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check
 csched_dom_cntl(
     const struct scheduler *ops,
@@ -1227,6 +1228,7 @@ csched_dom_cntl(
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check
 csched_aff_cntl(const struct scheduler *ops, struct sched_unit *unit,
@@ -2288,7 +2290,9 @@ static const struct scheduler sched_credit_def = {
     .wake           = csched_unit_wake,
     .yield          = csched_unit_yield,
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     .adjust         = csched_dom_cntl,
+#endif
     .adjust_affinity= csched_aff_cntl,
 #ifdef CONFIG_MGMT_HYPERCALLS
     .adjust_global  = csched_sys_cntl,
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 307e63ebd8..73df429b42 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -2909,6 +2909,7 @@ static void cf_check csched2_unit_migrate(
         sched_set_res(unit, get_sched_res(new_cpu));
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check
 csched2_dom_cntl(
     const struct scheduler *ops,
@@ -3114,6 +3115,7 @@ csched2_dom_cntl(
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static void cf_check
 csched2_aff_cntl(const struct scheduler *ops, struct sched_unit *unit,
@@ -4246,7 +4248,9 @@ static const struct scheduler sched_credit2_def = {
     .wake           = csched2_unit_wake,
     .yield          = csched2_unit_yield,
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     .adjust         = csched2_dom_cntl,
+#endif
     .adjust_affinity= csched2_aff_cntl,
 #ifdef CONFIG_MGMT_HYPERCALLS
     .adjust_global  = csched2_sys_cntl,
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index b7ff67200b..15e69f5c2d 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -349,9 +349,11 @@ struct scheduler {
     void         (*migrate)        (const struct scheduler *ops,
                                     struct sched_unit *unit,
                                     unsigned int new_cpu);
+#ifdef CONFIG_MGMT_HYPERCALLS
     int          (*adjust)         (const struct scheduler *ops,
                                     struct domain *d,
                                     struct xen_domctl_scheduler_op *op);
+#endif
     void         (*adjust_affinity)(const struct scheduler *ops,
                                     struct sched_unit *unit,
                                     const struct cpumask *hard,
@@ -506,13 +508,13 @@ static inline void sched_adjust_affinity(const struct scheduler *s,
         s->adjust_affinity(s, unit, hard, soft);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int sched_adjust_dom(const struct scheduler *s, struct domain *d,
                                    struct xen_domctl_scheduler_op *op)
 {
     return s->adjust ? s->adjust(s, d, op) : 0;
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 7b1f64a779..a42040b259 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1362,6 +1362,7 @@ out:
     unit_schedule_unlock_irq(lock, unit);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * set/get each unit info of each domain
  */
@@ -1471,6 +1472,7 @@ rt_dom_cntl(
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * The replenishment timer handler picks units
@@ -1572,7 +1574,9 @@ static const struct scheduler sched_rtds_def = {
     .insert_unit    = rt_unit_insert,
     .remove_unit    = rt_unit_remove,
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     .adjust         = rt_dom_cntl,
+#endif
 
     .pick_resource  = rt_res_pick,
     .do_schedule    = rt_schedule,
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1e4647f7db..4d332ceca2 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -56,8 +56,8 @@ struct xsm_ops {
                                 struct xen_domctl_getdomaininfo *info);
     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_MGMT_HYPERCALLS
+    int (*domctl_scheduler_op)(struct domain *d, int op);
     int (*sysctl_scheduler_op)(int op);
 #endif
     int (*set_target)(struct domain *d, struct domain *e);
@@ -240,13 +240,13 @@ static inline int xsm_get_domain_state(xsm_default_t def, struct domain *d)
     return alternative_call(xsm_ops.get_domain_state, d);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int xsm_domctl_scheduler_op(
     xsm_default_t def, struct domain *d, int cmd)
 {
     return alternative_call(xsm_ops.domctl_scheduler_op, d, cmd);
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 {
     return alternative_call(xsm_ops.sysctl_scheduler_op, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 2c70b979d6..2c878999a3 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -18,8 +18,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .security_domaininfo           = xsm_security_domaininfo,
     .domain_create                 = xsm_domain_create,
     .getdomaininfo                 = xsm_getdomaininfo,
-    .domctl_scheduler_op           = xsm_domctl_scheduler_op,
 #ifdef CONFIG_MGMT_HYPERCALLS
+    .domctl_scheduler_op           = xsm_domctl_scheduler_op,
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
 #endif
     .set_target                    = xsm_set_target,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index ec3880f631..e8a4deb2ea 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -609,6 +609,7 @@ static int cf_check flask_getdomaininfo(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
 {
     switch ( op )
@@ -626,7 +627,6 @@ static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
     }
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check flask_sysctl_scheduler_op(int op)
 {
     switch ( op )
@@ -1888,8 +1888,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .security_domaininfo = flask_security_domaininfo,
     .domain_create = flask_domain_create,
     .getdomaininfo = flask_getdomaininfo,
-    .domctl_scheduler_op = flask_domctl_scheduler_op,
 #ifdef CONFIG_MGMT_HYPERCALLS
+    .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
 #endif
     .set_target = flask_set_target,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117785.1463896 (Exim 4.92)
	(envelope-from )
	id 1uwFXL-0001ez-FU; Wed, 10 Sep 2025 07:46:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117785.1463896; Wed, 10 Sep 2025 07:46: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 1uwFXL-0001by-2s; Wed, 10 Sep 2025 07:46:39 +0000
Received: by outflank-mailman (input) for mailman id 1117785;
 Wed, 10 Sep 2025 07:46: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 1uwFRH-0005yt-7R
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:40:23 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2418::60b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 67af338e-8e19-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 09:40:22 +0200 (CEST)
Received: from SN6PR01CA0009.prod.exchangelabs.com (2603:10b6:805:b6::22) by
 PH7PR12MB8124.namprd12.prod.outlook.com (2603:10b6:510:2ba::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 07:40:15 +0000
Received: from SN1PEPF000252A0.namprd05.prod.outlook.com
 (2603:10b6:805:b6:cafe::da) by SN6PR01CA0009.outlook.office365.com
 (2603:10b6:805:b6::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 07:40:33 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SN1PEPF000252A0.mail.protection.outlook.com (10.167.242.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 07:40:14 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Wed, 10 Sep 2025 00:40:01 -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: 67af338e-8e19-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mGYKk8no+4KzoG7QdOuvFHB3+G/uKkJIJ2ZWJvcNWvjyuCfgSEmP2MZMDu2gk4VGL2qJgYteunEkbOTUmdQOYC48yg+dsZoHM3BMUl5nV4EG45XvWVZzJ02xkSUb+ttG+1QZEJxStdWl5ZNpub83o9pbPKmepP2g+OTtpXAuqDPKUyYIH8FWNErRR9CtMrFq3MOG2WTxkkQ9oWa+8qsxNn95yToCcK2+qfBnWsg8mzh5SI6BaWsMLdZvStGgNykX7jxT+ZfOivMwPfQ3ZCWpUi3Wu6U32k1pU9wapfhjXGlH3mz20b3yvDuAC0SXLPny2KvM8+V+VF4stAqb3psvPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cPpP+b+/IukhAi2FKipdO0pKRRyw4rGNMr68r7YHWug=;
 b=xn8iP5Am4moSGR5Gf8YYehMyAwpguOiME3F72L/oHDSQNhDJI40b/S0mk+dqwTerZ2uydeeOjjMczf8R8AvNJ7+5tiMIE4zOmcoMO3TqrYBJOxl5AHOGSG/B0/6bmsGHOWctFmXRQ2nSO6QToXponc526wu88LkfwKpNCfzoihguG7zacDPqJJFx4xk7aHvKvMUnDMNaOMIIvfMKC2ub9ZtCzBgxfGcCQMVTfbX7AHPTknsqQ98QnisA1Ca9vTL6wkq6NP8My+KDu1Mo+nw3kr7LC3YgTlaIg6LfQ5nlakdmTLDXyml5EcDPd+/XNNiqOxyzosJpgEFWbb7pYS5e8g==
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=cPpP+b+/IukhAi2FKipdO0pKRRyw4rGNMr68r7YHWug=;
 b=fUqJYcMC7yNDw9AdbnqiiRG6BpSN1c6IisbZiQWwnFwZEXL7qatF8ZgTAQ8PqfycX+SUvzN762DrQavtVDMalxGNGv0FgvYERjwg3D0c4P8TVH0efmkETLaglL313/6egK826KZVYnaVxXcXmEphIoUrW2FaPcnvVo2ng+74S1s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Tamas K Lengyel , "Daniel
 P. Smith" 
Subject: [PATCH v2 24/26] xen/domctl: wrap arch-specific domctl-op with CONFIG_MGMT_HYPERCALLS
Date: Wed, 10 Sep 2025 15:38:25 +0800
Message-ID: <20250910073827.3622177-25-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250910073827.3622177-1-Penny.Zheng@amd.com>
References: <20250910073827.3622177-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A0:EE_|PH7PR12MB8124:EE_
X-MS-Office365-Filtering-Correlation-Id: e4723181-0433-465e-761e-08ddf03d478e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|7416014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?T+U/ja/36brzF1BhhqMUoODrhA+e9rvnfX3iYu6HLuD1Jlioo44m7Bm1vnul?=
 =?us-ascii?Q?nkO6w/yZjYRM7u77YhzvcH/v11j57153AiN/WxPoh+Cn/GbSlj+sIkVNF9Z+?=
 =?us-ascii?Q?HIpRmHb5OyQqTHBrmKgGhf6dBD1YkEEMEW1pKZyjEv1oY4tO5FODlRQvInFB?=
 =?us-ascii?Q?UjmxjDJ5iT3ssGPbw6se6UTefnuY3Sq/kK8qIsDyPBTOmxetUoe5pAZAT2aB?=
 =?us-ascii?Q?havpM2YzuJXcEIOCwxosyOGnYPfBCfEMggnUrM9i/EloHnbM0vJeYjMBtw/t?=
 =?us-ascii?Q?rdxSqeYCduuMrQpF2+NlqeoocNxnGVOE+DRgIPjZAS4UDRcEJMiC4p4zWOkl?=
 =?us-ascii?Q?Y6RuDkw/k9mEwXU6JDtVEq9RVXRyaCzMcmxJgujCxKPrsH/NzI2NNY9qSL3H?=
 =?us-ascii?Q?wrmDyZG50tUWCaWK3wdUiTUrwEe7knnIFndMDyttypdl3OK24lW5enpZExSo?=
 =?us-ascii?Q?gmR9gLc/5NvIRf8oxhdAyGRLq6g41Og4efkZnP313MnTD/FMOo8gbOjElYqo?=
 =?us-ascii?Q?phQy0B/RE3Dp/5c/kOniO4I/KY8JTWEqye2OZsP1CQqT63lnzdUCEBqTQT3g?=
 =?us-ascii?Q?NYqhKct734JHLAbBG1ad0WbmU7rODuj3ni8PvK8TbjEDXc91HNjaFxfjIbfe?=
 =?us-ascii?Q?zoJ1aXTRTkNob+OuNArJU23JiewoEilTbtiIC3bwpAJrPUUSTSiqESBBP+iT?=
 =?us-ascii?Q?sa43Aym0QuEXLYNugIyfOVFe7mLVgu1Yfems3WOc5EdNU8dAthOuMjaZacij?=
 =?us-ascii?Q?ac3fI0iK0QuJQeVvwWnboiMsDszvlcfGxB4NR54y6F83yJ3J5N14pUwUBpgw?=
 =?us-ascii?Q?mW8HUXbQRHZItsYl+z2neo33OFQx8XAdC7Ek3yNi6D1+Y6KxjGRwxKWRuDzg?=
 =?us-ascii?Q?QcguEJ02+Va1wHIDEL1xMf0+C3BGUGS+de5oY9zpr1tga1x6R57aMKh2o5At?=
 =?us-ascii?Q?buPxxcOtx9QO18iEDN1Gaf1qXUI8U9zj5HCX2MA54a6NJ9YzOcSY4H1c3AiG?=
 =?us-ascii?Q?rxM6L2zOuSkBFie6eV5ytzqnE9ZXPAaVyY5OayO2sLG5aPYU8lCOE+DAuUcm?=
 =?us-ascii?Q?rXCj4EnWzsLy3vozUdbtUxbaC9yk6+jWqfZ5mrVBBzjaU/jp8aFJ8XQuXZYz?=
 =?us-ascii?Q?AVougIevW9KlxN0H0HmHgh0qYxUAGocB2rRNmX6g+6zSigcs84VCbPzl/f6e?=
 =?us-ascii?Q?jrPTfpat9/xXctIKZTckJ+nR+r5Nofi4W81TzuWUfg4xIrCcsrXNmLMwPapw?=
 =?us-ascii?Q?u7rmMpLGuNFzSJlZt4Zl/lk3BiqAOylpvgrd8Kr8K+CziWqDqxCC8wdd3q0H?=
 =?us-ascii?Q?YywcbnVIQw6mo9NQ4wUUZ4YDQ7cMb0qven+BhDos6R31oaB3WCy+hTAQSI8/?=
 =?us-ascii?Q?zVsds4EANhzwc+wWHhuhFjW+CwBiDoxKGz43KpG3ZAagkJ5/LWCT7ZkA6f2T?=
 =?us-ascii?Q?a+B0ZYMBspwNWKe0fzZDsmLFf2ziZR5tyfzcHttiSr5qYFQjV9710qsiSTM9?=
 =?us-ascii?Q?eIpXSi9uBkRhEZtYvUtHoyFn6O1sefdxdl/y?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(7416014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 07:40:14.0060
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e4723181-0433-465e-761e-08ddf03d478e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8124

Function arch_do_domctl() is responsible for arch-specific domctl-op,
and shall be wrapped with CONFIG_MGMT_HYPERCALLS
Tracking its calling chain and the following functions shall be wrapped with
CONFIG_MGMT_HYPERCALLS:
For x86:
- hvm_save_one
- hvm_acpi_power_button
- hvm_acpi_sleep_button
- hvm_debug_op
- mem_sharing_domctl
- make P2M_AUDIT depend on CONFIG_MGMT_HYPERCALLS
- make PG_log_dirty depend on CONFIG_MGMT_HYPERCALLS
- make policy.o depend on CONFIG_MGMT_HYPERCALLS
- do_vmtrace_op
  - hvm_vmtrace_control
    - hvm_funcs.vmtrace_control
  - hvm_vmtrace_get_option
    - hvm_funcs.vmtrace_get_option
  - hvm_vmtrace_set_option
    - hvm_funcs.vmtrace_set_option
- paging_domctl_cont
For ARM:
- subarch_do_domctl

Also, remove all #ifdef CONFIG_MGMT_HYPERCALLS-s in arch-specific domctl.c, as
we put the guardian in Makefile for the whole file.
Wrap default-case and arch_get_domain_info() transiently with
CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- split out xsm parts
- adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
- wrap default-case and arch_get_domain_info() transiently
---
 xen/Kconfig.debug                  |  2 +-
 xen/arch/arm/arm32/Makefile        |  2 +-
 xen/arch/arm/arm64/Makefile        |  2 +-
 xen/arch/arm/domctl.c              |  2 --
 xen/arch/x86/Makefile              |  2 +-
 xen/arch/x86/domctl.c              |  2 --
 xen/arch/x86/hvm/hvm.c             |  2 ++
 xen/arch/x86/hvm/pmtimer.c         |  2 ++
 xen/arch/x86/hvm/save.c            |  2 ++
 xen/arch/x86/hvm/vmx/vmx.c         |  6 ++++++
 xen/arch/x86/include/asm/hvm/hvm.h | 10 ++++++++++
 xen/arch/x86/include/asm/p2m.h     |  2 +-
 xen/arch/x86/include/asm/paging.h  |  2 +-
 xen/arch/x86/mm/mem_sharing.c      |  2 ++
 xen/common/domctl.c                |  6 ++++++
 xen/include/hypercall-defs.c       |  4 ++--
 xen/lib/x86/Makefile               |  2 +-
 17 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index a69615cd63..0dd44d2b10 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -15,7 +15,7 @@ if DEBUG || EXPERT
 
 config GDBSX
 	bool "Guest debugging with gdbsx"
-	depends on X86
+	depends on X86 && MGMT_HYPERCALLS
 	default y
 	help
 	  If you want to enable support for debugging guests from dom0 via
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 531168f58a..f8cbf14211 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -4,7 +4,7 @@ obj-$(CONFIG_MPU) += mpu/
 
 obj-y += cache.o
 obj-$(CONFIG_EARLY_PRINTK) += debug.o
-obj-y += domctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += domctl.o
 obj-y += domain.o
 obj-y += entry.o
 obj-y += head.o
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 6491c5350b..6b77a15abe 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -6,7 +6,7 @@ obj-y += cache.o
 obj-y += cpufeature.o
 obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
 obj-$(CONFIG_EARLY_PRINTK) += debug.o
-obj-y += domctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += domctl.o
 obj-y += domain.o
 obj-y += entry.o
 obj-y += head.o
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index d3263e4d03..ad914c915f 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -184,7 +184,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
     }
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
@@ -200,7 +199,6 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
     if ( !test_bit(_VPF_down, &v->pause_flags) )
         ctxt->flags |= VGCF_online;
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a7bfe4c0b1..8427dc52fd 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -28,7 +28,7 @@ obj-y += delay.o
 obj-y += desc.o
 obj-bin-y += dmi_scan.init.o
 obj-y += domain.o
-obj-y += domctl.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += domctl.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain_page.o
 obj-y += e820.o
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index ea5f5b20cf..6153e3c07e 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1370,7 +1370,6 @@ long arch_do_domctl(
     return ret;
 }
 
-#ifdef CONFIG_MGMT_HYPERCALLS
 #ifdef CONFIG_COMPAT
 #define xen_vcpu_guest_context vcpu_guest_context
 #define fpu_ctxt fpu_ctxt.x
@@ -1563,7 +1562,6 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
     c(vm_assist = d->vm_assist);
 #undef c
 }
-#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /*
  * Local variables:
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b044dc2ecb..08bb1ba857 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5223,6 +5223,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int hvm_debug_op(struct vcpu *v, int32_t op)
 {
     int rc = 0;
@@ -5265,6 +5266,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 #ifdef CONFIG_VM_EVENT
 void hvm_toggle_singlestep(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c
index 87a7a01c9f..f080f7561d 100644
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -56,6 +56,7 @@ static void pmt_update_sci(PMTState *s)
         hvm_isa_irq_deassert(s->vcpu->domain, SCI_IRQ);
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 void hvm_acpi_power_button(struct domain *d)
 {
     PMTState *s = &d->arch.hvm.pl_time->vpmt;
@@ -81,6 +82,7 @@ void hvm_acpi_sleep_button(struct domain *d)
     pmt_update_sci(s);
     spin_unlock(&s->lock);
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 /* Set the correct value in the timer, accounting for time elapsed
  * since the last time we did that. */
diff --git a/xen/arch/x86/hvm/save.c b/xen/arch/x86/hvm/save.c
index 8ab6405706..0d966911a2 100644
--- a/xen/arch/x86/hvm/save.c
+++ b/xen/arch/x86/hvm/save.c
@@ -121,6 +121,7 @@ size_t hvm_save_size(struct domain *d)
     return sz;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 /*
  * Extract a single instance of a save record, by marshalling all records of
  * that type and copying out the one we need.
@@ -195,6 +196,7 @@ int hvm_save_one(struct domain *d, unsigned int typecode, unsigned int instance,
     xfree(ctxt.data);
     return rv;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 int hvm_save(struct domain *d, hvm_domain_context_t *h)
 {
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 4cf5da70ad..056f46673e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2585,6 +2585,7 @@ static bool cf_check vmx_get_pending_event(
     (RTIT_STATUS_FILTER_EN | RTIT_STATUS_CONTEXT_EN | RTIT_STATUS_TRIGGER_EN | \
      RTIT_STATUS_ERROR | RTIT_STATUS_STOPPED)
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 static int cf_check vmtrace_get_option(
     struct vcpu *v, uint64_t key, uint64_t *output)
 {
@@ -2693,6 +2694,7 @@ static int cf_check vmtrace_control(struct vcpu *v, bool enable, bool reset)
 
     return 0;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 static int cf_check vmtrace_output_position(struct vcpu *v, uint64_t *pos)
 {
@@ -2883,10 +2885,14 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = {
     .altp2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
     .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
 #endif
+#ifdef CONFIG_MGMT_HYPERCALLS
     .vmtrace_control = vmtrace_control,
+#endif
     .vmtrace_output_position = vmtrace_output_position,
+#ifdef CONFIG_MGMT_HYPERCALLS
     .vmtrace_set_option = vmtrace_set_option,
     .vmtrace_get_option = vmtrace_get_option,
+#endif
     .vmtrace_reset = vmtrace_reset,
 
     .get_reg = vmx_get_reg,
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index b2c75b733e..6e5ec65a8e 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -239,10 +239,14 @@ struct hvm_function_table {
 #endif
 
     /* vmtrace */
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*vmtrace_control)(struct vcpu *v, bool enable, bool reset);
+#endif
     int (*vmtrace_output_position)(struct vcpu *v, uint64_t *pos);
+#ifdef CONFIG_MGMT_HYPERCALLS
     int (*vmtrace_set_option)(struct vcpu *v, uint64_t key, uint64_t value);
     int (*vmtrace_get_option)(struct vcpu *v, uint64_t key, uint64_t *value);
+#endif
     int (*vmtrace_reset)(struct vcpu *v);
 
     uint64_t (*get_reg)(struct vcpu *v, unsigned int reg);
@@ -747,8 +751,10 @@ bool altp2m_vcpu_emulate_ve(struct vcpu *v);
 
 static inline int hvm_vmtrace_control(struct vcpu *v, bool enable, bool reset)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     if ( hvm_funcs.vmtrace_control )
         return alternative_call(hvm_funcs.vmtrace_control, v, enable, reset);
+#endif
 
     return -EOPNOTSUPP;
 }
@@ -765,8 +771,10 @@ static inline int hvm_vmtrace_output_position(struct vcpu *v, uint64_t *pos)
 static inline int hvm_vmtrace_set_option(
     struct vcpu *v, uint64_t key, uint64_t value)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     if ( hvm_funcs.vmtrace_set_option )
         return alternative_call(hvm_funcs.vmtrace_set_option, v, key, value);
+#endif
 
     return -EOPNOTSUPP;
 }
@@ -774,8 +782,10 @@ static inline int hvm_vmtrace_set_option(
 static inline int hvm_vmtrace_get_option(
     struct vcpu *v, uint64_t key, uint64_t *value)
 {
+#ifdef CONFIG_MGMT_HYPERCALLS
     if ( hvm_funcs.vmtrace_get_option )
         return alternative_call(hvm_funcs.vmtrace_get_option, v, key, value);
+#endif
 
     return -EOPNOTSUPP;
 }
diff --git a/xen/arch/x86/include/asm/p2m.h b/xen/arch/x86/include/asm/p2m.h
index 1856cc396c..f29605df54 100644
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -20,7 +20,7 @@
 #include     /* for pagetable_t */
 
 /* Debugging and auditing of the P2M code? */
-#if !defined(NDEBUG) && defined(CONFIG_HVM)
+#if !defined(NDEBUG) && defined(CONFIG_HVM) && defined(CONFIG_MGMT_HYPERCALLS)
 #define P2M_AUDIT     1
 #else
 #define P2M_AUDIT     0
diff --git a/xen/arch/x86/include/asm/paging.h b/xen/arch/x86/include/asm/paging.h
index 1b0694bb36..db3e5b8f31 100644
--- a/xen/arch/x86/include/asm/paging.h
+++ b/xen/arch/x86/include/asm/paging.h
@@ -55,7 +55,7 @@
 #define PG_translate   0
 #define PG_external    0
 #endif
-#ifdef CONFIG_PAGING
+#if defined(CONFIG_PAGING) && defined(CONFIG_MGMT_HYPERCALLS)
 /* Enable log dirty mode */
 #define PG_log_dirty   (XEN_DOMCTL_SHADOW_ENABLE_LOG_DIRTY << PG_mode_shift)
 #else
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index d7cbf2047b..3210cf5553 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -2319,6 +2319,7 @@ out:
     return rc;
 }
 
+#ifdef CONFIG_MGMT_HYPERCALLS
 int mem_sharing_domctl(struct domain *d, struct xen_domctl_mem_sharing_op *mec)
 {
     int rc;
@@ -2336,6 +2337,7 @@ int mem_sharing_domctl(struct domain *d, struct xen_domctl_mem_sharing_op *mec)
 
     return rc;
 }
+#endif /* CONFIG_MGMT_HYPERCALLS */
 
 void arch_dump_shared_mem_info(void)
 {
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index c87c28cea2..5657b95089 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -114,7 +114,9 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
 
     memcpy(info->handle, d->handle, sizeof(xen_domain_handle_t));
 
+#ifdef CONFIG_MGMT_HYPERCALLS
     arch_get_domain_info(d, info);
+#endif
 }
 
 bool domctl_lock_acquire(void)
@@ -882,7 +884,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
 
     default:
+#ifdef CONFIG_MGMT_HYPERCALLS
         ret = arch_do_domctl(op, d, u_domctl);
+#else
+        ret = -EOPNOTSUPP;
+#endif /* CONFIG_MGMT_HYPERCALLS */
         break;
     }
 
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index cd2c801af6..02d7b93e80 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -197,7 +197,7 @@ dm_op(domid_t domid, unsigned int nr_bufs, xen_dm_op_buf_t *bufs)
 #ifdef CONFIG_MGMT_HYPERCALLS
 sysctl(xen_sysctl_t *u_sysctl)
 #endif
-#if defined(CONFIG_X86) && defined(CONFIG_PAGING)
+#if defined(CONFIG_X86) && defined(CONFIG_PAGING) && defined(CONFIG_MGMT_HYPERCALLS)
 paging_domctl_cont(xen_domctl_t *u_domctl)
 #endif
 domctl(xen_domctl_t *u_domctl)
@@ -296,7 +296,7 @@ dm_op                              compat   do       compat   do       do
 hypfs_op                           do       do       do       do       do
 #endif
 mca                                do       do       -        -        -
-#if defined(CONFIG_X86) && defined(CONFIG_PAGING)
+#if defined(CONFIG_X86) && defined(CONFIG_PAGING) && defined(CONFIG_MGMT_HYPERCALLS)
 paging_domctl_cont                 do       do       do       do       -
 #endif
 
diff --git a/xen/lib/x86/Makefile b/xen/lib/x86/Makefile
index 780ea05db1..ee5bec225e 100644
--- a/xen/lib/x86/Makefile
+++ b/xen/lib/x86/Makefile
@@ -1,3 +1,3 @@
 obj-y += cpuid.o
 obj-y += msr.o
-obj-y += policy.o
+obj-$(CONFIG_MGMT_HYPERCALLS) += policy.o
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 07:57:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 07:57:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117905.1463915 (Exim 4.92)
	(envelope-from )
	id 1uwFhq-00074K-9C; Wed, 10 Sep 2025 07:57:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117905.1463915; Wed, 10 Sep 2025 07:57: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 1uwFhq-00074D-6C; Wed, 10 Sep 2025 07:57:30 +0000
Received: by outflank-mailman (input) for mailman id 1117905;
 Wed, 10 Sep 2025 07:57: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 1uwFho-00072X-Eq
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 07:57:28 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca8a2795-8e1b-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 09:57:26 +0200 (CEST)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-336b908cbaaso56045351fa.1
 for ; Wed, 10 Sep 2025 00:57: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: ca8a2795-8e1b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757491046; x=1758095846; 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=EsCK+FAC+gsM4EV682APBEiNe693UcSOoCjjtWvQEsc=;
        b=GDGnxYw2+MdtHPvvAp2mA3z0wSqJYtauDnbArPeXo2nnLqufUTUrNgb+ZC7CvS8b1Z
         MHc+u7XbNie9LzhBkZcl/Sqq4IQG8DmNywpByWXI3GLFP1c0dBiGLnXOxQq2B0C90zKm
         jMVJQ5E2GxJBhYiXJOKHvi4DUkhqdW3nlZpTqhpWepQ6Kq9FCckZT0ZEWr37g40xBQnE
         cg+ns0Sfny1kUriThNftJtIw+uHPP4Zm3R98e65LB8vtAjG1YixMK+lb+cadjra3+opb
         AvMs2wM+W4RjHDbHZPuAZ79KzGtGd56L0DIBEFtVaUNWRBjCPU1p/CsEB2RRLBoWXx9d
         WPUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757491046; x=1758095846;
        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=EsCK+FAC+gsM4EV682APBEiNe693UcSOoCjjtWvQEsc=;
        b=QQBY3W1c2Fzdgqyf7E6abdzsUoFFnBWXNSbNeNMGfE5XgsVBbk23bNiadADSo8i2NO
         PfcGnfvlSQSALAyxda8tJ+/I9JjJp3t+b9EqUGFHCchE4DozAHIdbmQFxoAbYMKvvsfw
         g/46hZdco8dTiCgnOqPCgdwzpKfVRUQUJoUV3ReezKjbqpHeeuURIGVuJqmwb29arZsd
         I6sZHbUMDDBB+jp7sm8r76Pvd/o9DD+16rmN1msIwAQAq3NLT2axpwZAvELRq3vQ0lCl
         YkeWhkN3WTSsUruH1PLYM7BuijWtXR6L40GYR0Bi3wBcqcncPYcVaLSFl9qLTmMaiBBv
         QTSQ==
X-Gm-Message-State: AOJu0YwTUeJCWD30Idl5bYSiauQlFi4DVq4+2GN/KMa2A3YJKNgS3H51
	a4C1MhlsISLzFJYlOMGopxx1tpgE2WA29aUt50bEES/84d7KzCiW/O/uSE8oq58rYiHUa4bSiF6
	eQDcfzWVq5HGv0q38YhS7A92QL7OtamU=
X-Gm-Gg: ASbGncvhQ6oR+zSD4pdu6ol2AGScxO8MC7AR3ZcddaiZCup8hBdamHbL/8bGOCx5W/m
	1VU/P1DgVb4nDRCmqzSskXN1y2QgxAuyv4DH4YQQjVRbWesL8ox93BeI3At1uglBVYbB0/GR4b+
	EnKFmft0HedP5/dwWKmAFeAHq6hMaQ77nZO3ydvncIJObqwaFsv7mMDcbpd5JvRcEahmfUeG7L1
	NwXVw==
X-Google-Smtp-Source: AGHT+IHVMT5MUiPp568NOZyB1nfjqarDkPhtpnVFdJWjr4xPNn/svyK5S+lQEGYmMZdMEoTsUDbscAMWi3+2ICe/jcY=
X-Received: by 2002:a05:651c:3247:20b0:336:94b4:2b5d with SMTP id
 38308e7fff4ca-33b566fa995mr33597841fa.5.1757491045125; Wed, 10 Sep 2025
 00:57:25 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-2-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-2-dmukhin@ford.com>
From: Mykola Kvach 
Date: Wed, 10 Sep 2025 10:57:14 +0300
X-Gm-Features: Ac12FXzi0TcPZahdQQpNOxgau8e7C2HJpAVryccvqf2zOYBF57ln3vuQF5QUje0
Message-ID: 
Subject: Re: [PATCH v7 01/16] emul/vuart: introduce framework for UART emulators
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for addressing the issues from the previous version of the
patch series,

Everything looks good to me, with just a few questions:

On Tue, Sep 9, 2025 at 12:56=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> 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_VUART_FRAMEWORK, which will be
> automatically enabled once the user enables any UART emulator.
>
> Current implementation supports maximum of one vUART of each kind per dom=
ain.
>
> Use new domain_has_vuart() in the console driver code to check whether to
> forward console input to the domain using vUART.
>
> Enable console forwarding over vUART for hardware domains with a vUART. T=
hat
> enables console forwarding to dom0 on x86, since console can be forwarded=
 only
> to Xen, dom0 and pvshim on x86 as of now.
>
> Note: existing vUARTs are deliberately *not* hooked to the new framework =
to
> minimize the scope of the patch: vpl011 (i.e. SBSA) emulator and "vuart" =
(i.e.
> minimalistic MMIO-mapped dtuart for hwdoms on Arm) are kept unmodified.
>
> No functional changes for non-x86 architectures.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - addresses Mykola's feedback
> - some renaming (vuart_find_by_flags())
> - added extra checks to put_rx and dump_state
> - fixed vuart_init() error path
> - simplified some checks during vUART state 'search'
> ---
>  xen/arch/arm/xen.lds.S         |   1 +
>  xen/arch/ppc/xen.lds.S         |   1 +
>  xen/arch/riscv/xen.lds.S       |   1 +
>  xen/arch/x86/xen.lds.S         |   1 +
>  xen/common/Kconfig             |   2 +
>  xen/common/Makefile            |   1 +
>  xen/common/emul/Kconfig        |   6 ++
>  xen/common/emul/Makefile       |   1 +
>  xen/common/emul/vuart/Kconfig  |   6 ++
>  xen/common/emul/vuart/Makefile |   1 +
>  xen/common/emul/vuart/vuart.c  | 165 +++++++++++++++++++++++++++++++++
>  xen/common/keyhandler.c        |   3 +
>  xen/drivers/char/console.c     |   6 +-
>  xen/include/xen/sched.h        |   4 +
>  xen/include/xen/serial.h       |   3 +
>  xen/include/xen/vuart.h        | 115 +++++++++++++++++++++++
>  xen/include/xen/xen.lds.h      |  10 ++
>  17 files changed, 326 insertions(+), 1 deletion(-)
>  create mode 100644 xen/common/emul/Kconfig
>  create mode 100644 xen/common/emul/Makefile
>  create mode 100644 xen/common/emul/vuart/Kconfig
>  create mode 100644 xen/common/emul/vuart/Makefile
>  create mode 100644 xen/common/emul/vuart/vuart.c
>  create mode 100644 xen/include/xen/vuart.h
>
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index db17ff1efa98..cd05b18770f4 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -58,6 +58,7 @@ SECTIONS
>         *(.rodata)
>         *(.rodata.*)
>         VPCI_ARRAY
> +       VUART_ARRAY
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
>
> diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
> index 1de0b77fc6b9..f9d4e5b0dcd8 100644
> --- a/xen/arch/ppc/xen.lds.S
> +++ b/xen/arch/ppc/xen.lds.S
> @@ -52,6 +52,7 @@ SECTIONS
>          *(.rodata)
>          *(.rodata.*)
>          VPCI_ARRAY
> +        VUART_ARRAY
>          *(.data.rel.ro)
>          *(.data.rel.ro.*)
>
> diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
> index edcadff90bfe..59dcaa5fef9a 100644
> --- a/xen/arch/riscv/xen.lds.S
> +++ b/xen/arch/riscv/xen.lds.S
> @@ -47,6 +47,7 @@ SECTIONS
>          *(.rodata)
>          *(.rodata.*)
>          VPCI_ARRAY
> +        VUART_ARRAY
>          *(.data.rel.ro)
>          *(.data.rel.ro.*)
>
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 966e514f2034..d877b93a6964 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -132,6 +132,7 @@ SECTIONS
>         *(.rodata)
>         *(.rodata.*)
>         VPCI_ARRAY
> +       VUART_ARRAY
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 76f9ce705f7a..78a32b69e2b2 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -676,4 +676,6 @@ config PM_STATS
>           Enable collection of performance management statistics to aid i=
n
>           analyzing and tuning power/performance characteristics of the s=
ystem
>
> +source "common/emul/Kconfig"
> +
>  endmenu
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 0c7d0f5d46e1..8c8462565050 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) +=3D device-tree/
>  obj-$(CONFIG_IOREQ_SERVER) +=3D dm.o
>  obj-y +=3D domain.o
>  obj-y +=3D domid.o
> +obj-y +=3D emul/
>  obj-y +=3D event_2l.o
>  obj-y +=3D event_channel.o
>  obj-$(CONFIG_EVTCHN_FIFO) +=3D event_fifo.o
> diff --git a/xen/common/emul/Kconfig b/xen/common/emul/Kconfig
> new file mode 100644
> index 000000000000..7c6764d1756b
> --- /dev/null
> +++ b/xen/common/emul/Kconfig
> @@ -0,0 +1,6 @@
> +menu "Domain Emulation Features"
> +       visible if EXPERT
> +
> +source "common/emul/vuart/Kconfig"
> +
> +endmenu
> diff --git a/xen/common/emul/Makefile b/xen/common/emul/Makefile
> new file mode 100644
> index 000000000000..ae0b575c3901
> --- /dev/null
> +++ b/xen/common/emul/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VUART_FRAMEWORK) +=3D vuart/
> diff --git a/xen/common/emul/vuart/Kconfig b/xen/common/emul/vuart/Kconfi=
g
> new file mode 100644
> index 000000000000..ce1b976b7da7
> --- /dev/null
> +++ b/xen/common/emul/vuart/Kconfig
> @@ -0,0 +1,6 @@
> +config VUART_FRAMEWORK
> +       bool
> +
> +menu "UART Emulation"
> +
> +endmenu
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> new file mode 100644
> index 000000000000..97f792dc6641
> --- /dev/null
> +++ b/xen/common/emul/vuart/Makefile
> @@ -0,0 +1 @@
> +obj-y +=3D vuart.o
> diff --git a/xen/common/emul/vuart/vuart.c b/xen/common/emul/vuart/vuart.=
c
> new file mode 100644
> index 000000000000..ba89d608aeb2
> --- /dev/null
> +++ b/xen/common/emul/vuart/vuart.c
> @@ -0,0 +1,165 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UART emulator framework.
> + *
> + * Copyright 2025 Ford Motor Company
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define for_each_emulator(e) \
> +    for ( e =3D vuart_array_start; e < vuart_array_end; e++ )
> +
> +extern const struct vuart_emulator vuart_array_start[];
> +extern const struct vuart_emulator vuart_array_end[];
> +
> +static const struct vuart_emulator *
> +vuart_match_by_compatible(const struct domain *d, const char *compat)
> +{
> +    const struct vuart_emulator *emulator;
> +
> +    for_each_emulator(emulator)
> +        if ( emulator->compatible &&
> +             !strncmp(compat, emulator->compatible,
> +                      strlen(emulator->compatible)) )
> +            return emulator;
> +
> +    return NULL;
> +}
> +
> +const static struct vuart *
> +vuart_find_by_flags(const struct domain *d, unsigned int flags)
> +{
> +    const struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart && (vuart->flags & flags) )
> +        return vuart;
> +
> +    return NULL;
> +}
> +
> +struct vuart *vuart_find_by_io_range(struct domain *d, unsigned long add=
r,
> +                                     unsigned long size)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart &&
> +         addr >=3D vuart->info->base_addr &&
> +         addr + size - 1 <=3D vuart->info->base_addr + vuart->info->size=
 - 1 )
> +        return vuart;
> +
> +    return NULL;
> +}
> +
> +int vuart_init(struct domain *d, const struct vuart_info *info)
> +{
> +    const struct vuart_emulator *emulator;
> +    struct vuart *vuart;
> +    int rc;
> +
> +    if ( d->console.vuart )
> +        return -EBUSY;
> +
> +    emulator =3D vuart_match_by_compatible(d, info->compatible);
> +    if ( !emulator )
> +        return -ENODEV;
> +
> +    vuart =3D xzalloc(typeof(*vuart));
> +    if ( !vuart )
> +        return -ENOMEM;
> +
> +    vuart->info =3D xvzalloc(typeof(*vuart->info));
> +    if ( !vuart->info )
> +    {
> +        rc =3D -ENOMEM;
> +        goto err_out1;
> +    }
> +    memcpy(vuart->info, info, sizeof(*info));
> +
> +    vuart->vdev =3D emulator->alloc(d, vuart->info);
> +    if ( IS_ERR(vuart->vdev) )
> +    {
> +        rc =3D PTR_ERR(vuart->vdev);
> +        goto err_out2;
> +    }
> +
> +    vuart->emulator =3D emulator;
> +    vuart->owner =3D d;
> +    vuart->flags |=3D VUART_CONSOLE_INPUT;
> +
> +    d->console.input_allowed =3D true;

I'm not a specialist in the area of consoles, but I'm wondering:
Does the input_allowed flag serve the same purpose as
VUART_CONSOLE_INPUT? If so, do we need both, or
could one be removed to simplify the code?

At least here they are set in sync.

> +    d->console.vuart =3D vuart;
> +
> +    return 0;
> +
> + err_out2:
> +    xvfree(vuart->info);
> + err_out1:
> +    xvfree(vuart);
> +
> +    return rc;
> +}
> +
> +/*
> + * Release any resources taken by UART emulators.
> + *
> + * NB: no flags are cleared, since currently exit() is called only durin=
g
> + * domain destroy.
> + */
> +void vuart_deinit(struct domain *d)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart )
> +    {
> +        vuart->emulator->free(vuart->vdev);
> +        xvfree(vuart->info);
> +    }
> +    XVFREE(d->console.vuart);
> +}
> +
> +/*
> + * Print emulated UART state on the console.
> + *
> + * Must be called under rcu_lock_domain().
> + */
> +void vuart_dump_state(const struct domain *d)
> +{
> +    struct vuart *vuart =3D d->console.vuart;
> +
> +    if ( vuart && vuart->emulator->dump_state )
> +        vuart->emulator->dump_state(vuart->vdev);
> +}
> +
> +/*
> + * Put character to the first emulated UART's FIFO with the physical con=
sole
> + * forwarding enabled.
> + *
> + * Must be called under rcu_lock_domain().
> + */
> +int vuart_put_rx(struct domain *d, char c)
> +{
> +    const struct vuart *vuart =3D vuart_find_by_flags(d, VUART_CONSOLE_I=
NPUT);

The call to vuart_find_by_flags() with VUART_CONSOLE_INPUT in
vuart_put_rx() appears unnecessary. Every vUART console is always
initialized with VUART_CONSOLE_INPUT, so even if multiple consoles
exist, the search will always return the first console. It would be
simpler and clearer to use d->console.vuart directly.

Consider updating the function to remove the flag-based search and add a
short comment explaining why checking the flag isn=E2=80=99t needed. This w=
ill
help avoid confusion for future maintainers. Alternatively, we could
pass flags to the init functions instead of hardcoding
VUART_CONSOLE_INPUT for every console.

> +
> +    if ( vuart && vuart->emulator->put_rx )
> +        return vuart->emulator->put_rx(vuart->vdev, c);
> +
> +    return  -ENODEV;
> +}
> +
> +bool domain_has_vuart(const struct domain *d)
> +{
> +    return vuart_find_by_flags(d, VUART_CONSOLE_INPUT);

The same issue applies here: domain_has_vuart() calls
vuart_find_by_flags() with VUART_CONSOLE_INPUT, but every
vUART console is always initialized with this flag

> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index cb6df2823b00..156e64d9eb58 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  static unsigned char keypress_key;
> @@ -352,6 +353,8 @@ static void cf_check dump_domains(unsigned char key)
>                             v->periodic_period / 1000000);
>              }
>          }
> +
> +        vuart_dump_state(d);
>      }
>
>      for_each_domain ( d )
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9bd5b4825da6..d5164897a776 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_X86
>  #include 
> @@ -596,11 +597,12 @@ static void __serial_rx(char c)
>      if ( !d )
>          return;
>
> -    if ( is_hardware_domain(d) )
> +    if ( is_hardware_domain(d) && !domain_has_vuart(d) )
>      {
>          /*
>           * Deliver input to the hardware domain buffer, unless it is
>           * already full.
> +         * NB: must be the first check: hardware domain may have emulate=
d UART.
>           */
>          if ( (serial_rx_prod - serial_rx_cons) !=3D SERIAL_RX_SIZE )
>              serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] =3D c;
> @@ -611,6 +613,8 @@ static void __serial_rx(char c)
>           */
>          send_global_virq(VIRQ_CONSOLE);
>      }
> +    else if ( domain_has_vuart(d) )
> +        rc =3D vuart_put_rx(d, c);
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
>      else
>          /* Deliver input to the emulated UART. */
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 02bdc256ce37..613f4596e33d 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -660,6 +661,9 @@ struct domain
>      struct {
>          /* Permission to take ownership of the physical console input. *=
/
>          bool input_allowed;
> +#ifdef CONFIG_VUART_FRAMEWORK
> +        struct vuart *vuart;
> +#endif
>      } console;
>  } __aligned(PAGE_SIZE);
>
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 8e1844555208..123eee67df35 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -36,6 +36,9 @@ struct vuart_info {
>      unsigned long data_off;     /* Data register offset */
>      unsigned long status_off;   /* Status register offset */
>      unsigned long status;       /* Ready status value */
> +    unsigned int irq;           /* Interrupt */
> +    char compatible[16];        /* Compatible string */
> +    char name[16];              /* User-friendly name */
>  };
>
>  struct serial_port {
> diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
> new file mode 100644
> index 000000000000..55828f8498ce
> --- /dev/null
> +++ b/xen/include/xen/vuart.h
> @@ -0,0 +1,115 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UART emulator framework.
> + *
> + * Copyright 2025 Ford Motor Company
> + */
> +
> +#ifndef XEN_VUART_H
> +#define XEN_VUART_H
> +
> +#include 
> +#include 
> +
> +struct vuart_emulator;
> +
> +enum {
> +    VUART_CONSOLE_INPUT =3D BIT(0, U), /* Physical console input forward=
ing. */
> +};
> +
> +/*
> + * FIXME: #ifdef is temporary to avoid clash with
> + *   arch/arm/include/asm/domain.h
> + */
> +#ifdef CONFIG_VUART_FRAMEWORK
> +struct vuart {
> +    const struct vuart_emulator *emulator;
> +    struct vuart_info *info;
> +    struct domain *owner;
> +    unsigned int flags;
> +    void *vdev;
> +};
> +#endif
> +
> +struct vuart_emulator {
> +    /* UART compatible string. Cannot be NULL or empty. */
> +    const char *compatible;
> +
> +    /*
> +     * Allocate emulated UART state (RX/TX FIFOs, locks, initialize regi=
sters,
> +     * hook I/O handlers, etc.)
> +     * Cannot be NULL.
> +     */
> +    void *(*alloc)(struct domain *d, const struct vuart_info *info);
> +
> +    /*
> +     * Release resources used to emulate UART state (flush RX/TX FIFOs, =
unhook
> +     * I/O handlers, etc.).
> +     * Cannot be NULL.
> +     */
> +    void (*free)(void *arg);
> +
> +    /*
> +     * Print emulated UART state, including registers, on the console.
> +     * Can be NULL.
> +     */
> +    void (*dump_state)(void *arg);
> +
> +    /*
> +     * Place character to the emulated RX FIFO.
> +     * Used to forward physical console input to the guest OS.
> +     * Can be NULL.
> +     */
> +    int (*put_rx)(void *arg, char c);
> +};
> +
> +#define VUART_REGISTER(name, x) \
> +    static const struct vuart_emulator name##_entry \
> +        __used_section(".data.rel.ro.vuart") =3D x
> +
> +struct vuart *vuart_find_by_io_range(struct domain *d,
> +                                     unsigned long base_addr,
> +                                     unsigned long size);
> +
> +int vuart_put_rx(struct domain *d, char c);
> +
> +#ifdef CONFIG_VUART_FRAMEWORK
> +
> +int vuart_init(struct domain *d, const struct vuart_info *info);
> +void vuart_deinit(struct domain *d);
> +void vuart_dump_state(const struct domain *d);
> +bool domain_has_vuart(const struct domain *d);
> +
> +#else
> +
> +static inline int vuart_init(struct domain *d, const struct vuart_info *=
info)
> +{
> +    return 0;
> +}
> +
> +static inline void vuart_deinit(struct domain *d)
> +{
> +}
> +
> +static inline void vuart_dump_state(const struct domain *d)
> +{
> +}
> +
> +static inline bool domain_has_vuart(const struct domain *d)
> +{
> +    return false;
> +}
> +
> +#endif /* CONFIG_VUART_FRAMEWORK */
> +
> +#endif /* XEN_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/xen.lds.h b/xen/include/xen/xen.lds.h
> index b126dfe88792..2d65f32ddad3 100644
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -194,4 +194,14 @@
>  #define VPCI_ARRAY
>  #endif
>
> +#ifdef CONFIG_VUART_FRAMEWORK
> +#define VUART_ARRAY              \
> +       . =3D ALIGN(POINTER_ALIGN); \
> +       vuart_array_start =3D .;    \
> +       *(.data.rel.ro.vuart)     \
> +       vuart_array_end =3D .;
> +#else
> +#define VUART_ARRAY
> +#endif
> +
>  #endif /* __XEN_LDS_H__ */
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 08:39:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 08:39:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117962.1463925 (Exim 4.92)
	(envelope-from )
	id 1uwGML-0002Ec-Ba; Wed, 10 Sep 2025 08:39:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117962.1463925; Wed, 10 Sep 2025 08:39: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 1uwGML-0002EV-88; Wed, 10 Sep 2025 08:39:21 +0000
Received: by outflank-mailman (input) for mailman id 1117962;
 Wed, 10 Sep 2025 08:39: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 1uwGMK-0002EP-6u
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 08:39:20 +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 a46be685-8e21-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 10:39:19 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-55f6f7edf45so6136394e87.2
 for ; Wed, 10 Sep 2025 01:39: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: a46be685-8e21-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757493559; x=1758098359; 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=QdrSKgt6Kn7bDeROkON13jokpSii2R5xx0UfbqquSXE=;
        b=MHXsxAd/42fQXk8sSdSDy6mE/Crk6Uj2IbMbixLUsqm2chyvXJ5y+Z+FPfaRyZfmoP
         2DmN5c+IOkyAzgTGAFaO1DvXM1gWq9jCx+HCb/uk7dZyW4HD+BJAlTW6dfBw1sFV42jp
         mJKniHJPb76lpeZT7isjuz8JTEoX0v0uvVtly1m+PokXUsnx69I/VohiFkyBfJ32gXCy
         IgyG+uLvjSUK54Eurl6AiVgsy5wX0Oj/2vfxKSuLqDhujGhCJSOG1Hj5+mzprMrOoGXA
         uvFv2dA3C8eKaS//nzd1iGaZdYNfqEZmHJH33bNuf5Nbnx1PPnD4Slt8RfXFV6uMuiHT
         Iq2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757493559; x=1758098359;
        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=QdrSKgt6Kn7bDeROkON13jokpSii2R5xx0UfbqquSXE=;
        b=abBU6QHDvJoso3p127AxA90ZI9ZvpDIxr8L+V1icfVkMuNSVwXIUn8E9/c+YkExpWF
         IHuPqoZyTHDacg2BM4kS9EwUCst5FZVZG7wqQtjXDq60CD3Pn8n5lQGXj3nVlFHFFdjD
         JDhG01XuMbC+H3RcSdSF8aDzvUD++MUszpmRBc/tLJjN4CZD+YSQ4ibEZxtzRupQaWov
         gCsXeqoOWNuZuw3+lcGJQ4PktnNhPmgHkPlbXNRR4Hubnk+nu+OoJ4xX5hKkzdJzTfI0
         O9MD6MmT+n1sTpBq2c61Mx+1CAVJlYUUhomIm7nKa+JC2qdpfr9wgjuIq+q42AvgegXx
         YNQQ==
X-Forwarded-Encrypted: i=1; AJvYcCWFJtCkp2lHWCkVHXCrblO47HQgoxjH+NMGIlk7UTyjNBEJx+rZ6thyPCh/2LxQyF6UJGS+gtubKVE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyF8gCoWo1w5S+O+rbmv9LjTp+wzlF86qoqjML3XSz398e1H6WW
	bRXtu80XuXig/ksTIBx5OZac9MM63CDMDAM2Em76s2kW+G4IfN4tKlIjFnfB4KAmXnxwcexWn86
	nKESLSP8n1CGiYaDXf7Ev++EFtDlX9Ao=
X-Gm-Gg: ASbGncv+HmJcvGfjcZ0VEpGKfu77AY4wGPT+DAicSK2koGdv7Oaq8GlvCEyFDh9Uq2A
	GPSmZzrZDnsPon9E6a1kQmr7KKUF3RqPZjfgGcTYpkw+aPFx/itvhMVd2zL5VNjXxQG52Zz50kG
	1IXrQECNW22avbFDpii4LImxEYMAPH5lIewyIsfazrpHfzYdROOJsuLpNKk41IodQOew1PPFb2v
	LZ6xw==
X-Google-Smtp-Source: AGHT+IFJBtHdlQwtD2Q1Kq83ja3jL3Nf93+ud9uDaAVFT0qsuxdG5qwofQdBP/fNzm+WebtK8VMZBPl9RB+AFXI7dAA=
X-Received: by 2002:a05:6512:3d25:b0:55f:601d:a819 with SMTP id
 2adb3069b0e04-56262667f4fmr4424177e87.33.1757493558218; Wed, 10 Sep 2025
 01:39:18 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-3-dmukhin@ford.com>
 <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>
In-Reply-To: <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>
From: Mykola Kvach 
Date: Wed, 10 Sep 2025 11:39:07 +0300
X-Gm-Features: Ac12FXzkYqO6TBsCaBgjstzF6T9hR1eJI7W5JNLp04Y2G7MtVri7zYnkWNnhiNs
Message-ID: 
Subject: Re: [PATCH v7 02/16] xen/8250-uart: update definitions
To: Jan Beulich 
Cc: dmukhin@xen.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, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for the updates from the previous version of patch series,

On Tue, Sep 9, 2025 at 1:47=E2=80=AFPM Jan Beulich  wrot=
e:
>
> On 08.09.2025 23:11, dmukhin@xen.org wrote:
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
> > @@ -32,6 +32,7 @@
> >  #define UART_MCR          0x04    /* Modem control        */
> >  #define UART_LSR          0x05    /* line status          */
> >  #define UART_MSR          0x06    /* Modem status         */
> > +#define UART_SCR          0x07    /* Scratch pad          */
> >  #define UART_USR          0x1f    /* Status register (DW) */
> >  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=3D1) */
> >  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=3D1) */
> > @@ -42,6 +43,8 @@
> >  #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
> >  #define UART_IER_ELSI     0x04    /* rx line status       */
> >  #define UART_IER_EMSI     0x08    /* MODEM status         */
> > +#define UART_IER_MASK \
> > +    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
>
> Here, aiui, ..._MASK covers all known bits. No #define-s for reserved
> ones.

I think we can follow the Linux kernel style here [1]. For example:

#define UART_IER_ALL_INTR (UART_IER_MSI | \
        UART_IER_RLSI | \
        UART_IER_THRI | \
        UART_IER_RDI)

This way we avoid using the *_MASK suffix, which could be confusing,
and clearly indicate that these are all valid interrupt bits.

>
> > @@ -51,12 +54,19 @@
> >  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
> >  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
> >  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> > +#define UART_IIR_FE       0xc0    /* FIFO enabled (2 bits) */
> >
> >  /* FIFO Control Register */
> >  #define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> >  #define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> >  #define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> > -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> > +#define UART_FCR_DMA      0x08    /* enter DMA mode       */
>
> Question is whether we can actually use the source you indicate as
> reference. TL16C550C may already be too different from what a "standard"
> 16550 is (where admittedly it also looks unclear what "standard" would be=
,
> as I'm unaware of a "canonical" spec).
>
> The source I'm looking at says something entirely different. Maybe we're
> better off simply omitting this #define?
>
> > +#define UART_FCR_RSRVD0   0x10    /* reserved; always 0   */
> > +#define UART_FCR_RSRVD1   0x20    /* reserved; always 0   */
> > +#define UART_FCR_RTB0     0x40    /* receiver trigger bit #0 */
> > +#define UART_FCR_RTB1     0x80    /* receiver trigger bit #1 */
> > +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)
>
> Continuing from the top comment - here, with the TRG infix, the scope is
> clear, too.
>
> > @@ -98,9 +108,30 @@
> >  /* Modem Control Register */
> >  #define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
> >  #define UART_MCR_RTS      0x02    /* Request to Send      */
> > -#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
> > +#define UART_MCR_OUT1     0x04    /* Output #1 */
> > +#define UART_MCR_OUT2     0x08    /* Output #2 */
> >  #define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
> > +#define UART_MCR_RSRVD0   0x20    /* Reserved #0 */
> >  #define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=
=3D1) */
> > +#define UART_MCR_RSRVD1   0x80    /* Reserved #1 */
> > +#define UART_MCR_MASK \
> > +    (UART_MCR_DTR | UART_MCR_RTS | \
> > +     UART_MCR_OUT1 | UART_MCR_OUT2 | \
> > +     UART_MCR_LOOP | UART_MCR_TCRTLR)
>
> Here it's again all non-reserved bits. Yet why do we need #define-s for
> the two reserved ones here? (Same question for FCR, even if there's no
> UART_FCR_MASK.)
>
> > +/* Modem Status Register */
> > +#define UART_MSR_DCTS     0x01    /* Change in CTS */
> > +#define UART_MSR_DDSR     0x02    /* Change in DSR */
> > +#define UART_MSR_TERI     0x04    /* Change in RI */
> > +#define UART_MSR_DDCD     0x08    /* Change in DCD */
> > +#define UART_MSR_CTS      0x10
> > +#define UART_MSR_DSR      0x20
> > +#define UART_MSR_RI       0x40
> > +#define UART_MSR_DCD      0x80
> > +#define UART_MSR_CHANGE \
> > +    (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
> > +#define UART_MSR_STATUS \
> > +    (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
>
> Here it's properly two subsets.
>
> > @@ -111,6 +142,7 @@
> >  #define UART_LSR_THRE     0x20    /* Xmit hold reg empty  */
> >  #define UART_LSR_TEMT     0x40    /* Xmitter empty        */
> >  #define UART_LSR_ERR      0x80    /* Error                */
> > +#define UART_LSR_MASK     (UART_LSR_OE | UART_LSR_BI)
>
> But what's the deal here? Why would only two of the bits be covered?
>
> Jan
>

[1] https://elixir.bootlin.com/linux/v6.16.5/source/include/linux/serial.h#=
L15

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 09:25:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 09:25:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1117991.1463935 (Exim 4.92)
	(envelope-from )
	id 1uwH4w-0001zS-Mp; Wed, 10 Sep 2025 09:25:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1117991.1463935; Wed, 10 Sep 2025 09:25: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 1uwH4w-0001zL-K5; Wed, 10 Sep 2025 09:25:26 +0000
Received: by outflank-mailman (input) for mailman id 1117991;
 Wed, 10 Sep 2025 09:25: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 1uwH4v-0001zF-27
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 09:25:25 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2009::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 13479e52-8e28-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 11:25:23 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MN2PR12MB4287.namprd12.prod.outlook.com (2603:10b6:208:1dd::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 09:25:20 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29%6]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 09:25: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: 13479e52-8e28-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AZ440w2BYxgIR3agI/W1iaJhvAwzRHo8YksXEWL0WfY2xdf1lE8kUFVYkh+F2MNiXpfkbw488aGAUx8G9MpVHK+cmEFvJJaMSNADFXuWo/cuP8X85BC4sgKKPTgbzSjf1rqJmQ7rH/hcK77HjtTDWlRpCXyqJrpT8qayRkdUPMDp3blCMMyEFLvEJLcw+v367qab/HcxYxZ+pzTs7QymC2Tgsvj8P2EzMt/otK155ipmwyXpDvPQO4BGqQLhsA3jkvTlsRKj6xBBwqLm7Z4KsIY0iQw5N/B9zXyPz2FOloBovMcqMLYp/S3Ot0uyv6PvQXbeUCVy2uxKsamvZQsnYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VXn1NxGUVUtecb88czaS+9Dinrt3d0ISxjrBELIvCWg=;
 b=DGiIrNtO9hffzj7hkSgcLb2GeNZPpPjxvpG97Lu2DDlb3T5fK/V0CUuVsIZeuZI18aTahsE5TGVrQMWGnqCr5n4Ebdc6tRNpeKsdvjHp1G9s4YX8F8ZcmF8L0A9sc09R4tzJ23AZf62CLtoPldeIk1oiShB3nahhsPou/FF0YCljxDiXbPZzRdDNPNzZPj11yWk2Hr/JwUVuHoZsJ3GolOPM4QMJ6p9TyOrPPgB8UAQKYdEFFJ6uk7nttHiOAvGtEUbjnsDwtb+FmwDs8qkt+7C4QRsKeFNd/BuZTsRdXPtoXAtnX0cuiUAJt7QnwHP8fonOc8jZ/dVOOJMWb2qG3g==
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=VXn1NxGUVUtecb88czaS+9Dinrt3d0ISxjrBELIvCWg=;
 b=SLylhIJ44uuZjel0U5HGVBD8wTJvAupx6wHJDuMQ5VIa25rX4osdtfj97JllWHjmpJUez7nsgVCzfK4VrcBH17Z2hHXlw8gbT9KNLA73f2BjXcpcPAG5SizDxE2IEAamFLqgsE9lJuhmns9JOD//qOz2tRVOWm2we0dzJKTFDqU=
From: "Chen, Jiqian" 
To: Roger Pau Monne 
CC: "xen-devel@lists.xenproject.org" ,
	"Hildebrand, Stewart" , "jbeulich@suse.com"
	, "Chen, Jiqian" 
Subject: Re: [PATCH 0/5] xen/vpci: miscellaneous fixes
Thread-Topic: [PATCH 0/5] xen/vpci: miscellaneous fixes
Thread-Index: AQHcDTURKj5JMcHd/UWxKXg/kyCmwrSM00uA
Date: Wed, 10 Sep 2025 09:25:19 +0000
Message-ID:
 
References: <20250814160358.95543-1-roger.pau@citrix.com>
In-Reply-To: <20250814160358.95543-1-roger.pau@citrix.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.9094.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_|MN2PR12MB4287:EE_
x-ms-office365-filtering-correlation-id: 2602ace3-091e-45a5-f68c-08ddf04bf628
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?eDlmbzdJWmhkZ0d6bk9lK0pRYVpRaXZvZjBVMjh5WGswUWdZRmlndHVHeFdL?=
 =?utf-8?B?Z3hmMmp1S0p6OVptTUtvZ1hidWJ5LzNWVVdLakRucyt5L2MyMStncEloVkRo?=
 =?utf-8?B?U1VqR1B3Q2MvQytJMk5wb0ExZXFOTDl5T3g1THBydzZpVXhMcEZrb0lwVVVm?=
 =?utf-8?B?VjdqQUtUdlBPZzJVSzY0cDQxZEZBaTBIam01cEdUU2pwQXYxTThKNEhHOEwr?=
 =?utf-8?B?NXFvZ3hCT0FoTGhtS2NWbEMzd09zK25Nc01wUVc5WXhuRWwrOGpkQ094TnJ4?=
 =?utf-8?B?dDhJWGk5TGs5MUtZT1N0bXdKVkVKZ1pKVHVGZVdmRDVQam5wRjQ3cXFzQkhW?=
 =?utf-8?B?dW9ScFJIWEkxT2syWWlFTFNvTDJvNzV6N1RsamdoTndhZXVCemczRHZFYmVD?=
 =?utf-8?B?cXZySy92M3NsbFhaMkVwUldFaG9ZZDRyMHBWeDRlemhvQkx3bUVJWnZUZ0xo?=
 =?utf-8?B?TFdFeVVPOW5naHRvb2VtdHc1eXJrdksyMkc3VjRjZk0zcVBvcTQ3V2NEc0tB?=
 =?utf-8?B?akN4ZnFNa3FSeWR5TEt2ajBxYTVYOTNXd2FvdDZ6cmkrWjZibmtYcGRrZWpo?=
 =?utf-8?B?VDlZOUlqcDd3N3lzajhOQjMyMWVlZnBWenBIWFNVWk55VmM5bk1DUGR2cUFK?=
 =?utf-8?B?bFBKbkxHUUU1TlV4V2ZWZHRSWTZOMTdicGdtUkFXeFpEbjZjSzFmTmtFYUdR?=
 =?utf-8?B?clFZMWhFenBpRVhITjc3MSsybjhjOUw3Yk5CeUlhbzBUb1VyVVNPaHlNZFVZ?=
 =?utf-8?B?cGFHajd4cUJ5VjFWUkowbDAvV21ueE9FMmF6QkNVRmN5WnRhQ3FmWnlRd0Jr?=
 =?utf-8?B?ZGNLOFNmVlY2M01jN2tocjNIZlBQa1hMSmh4OHpyVGZLNkVncW91VkVFeVRF?=
 =?utf-8?B?TTU3U05KaVBUUS9wc0szY0JBNWdhTTl2MFl4bkpWUUc3Q1ByQVVoMXJhU0Mw?=
 =?utf-8?B?TkRCemhyYVpKc1Qvamw4RlI2M1NuZUNTVlRQS3lVYUQrY0ZSRStmd09EQUlr?=
 =?utf-8?B?Ykh0ZFZ0dFhXVkVmb0VhWUk3eDlsUGRxN2piTC9tU1pyTzRiMjdtQVVKTHdO?=
 =?utf-8?B?dC8wL3NFQnh3T2tSOVRTOElNcVEzdVdoeHk1ZGNHRE1YZlBTRlV1N3VaU1F2?=
 =?utf-8?B?QUpVUWFmOWpybEtLY3dLaFZXQnBVNGhxdm5CTzVCRDZBQjZJU1lyYmt0eE5x?=
 =?utf-8?B?U01RNzlMNzhTSVI1NHZKb0ZHNU9hRzlVTXZQVkZ6bzl2MWtGWDc2ajdVRGtn?=
 =?utf-8?B?akFpUXdNQnErdGpGOVVUUEdBOGdleWkrRnpmU1V2Qkk3VDhrNXRmNzBTcGhw?=
 =?utf-8?B?blY3c1NQa2R1RHl2allmSHpvQXpjZGFoelZYQmRXMHluOUtBc0ZSUDBBRUto?=
 =?utf-8?B?Y0ZaVlk4WXVwL29xR0pTNWU0RWo2VmE0WFF4bEJMS2FZTVJXbE9Idm0xQlpX?=
 =?utf-8?B?cnk3UDBPNnYwRG44QXdMVHRsY0xxdW1lUkp1M3doc3doTzFPOTF6M0FTZytP?=
 =?utf-8?B?OEgrT1hqR1M5Z1REd1hmUXI1VGFJTmUwbXMvcnM1c3pQYk11TWhXckhqUWU5?=
 =?utf-8?B?NytuTE5jeVNUWG9GeFAxQU5HSEowdk5CUkVzaExCc2ptYWtKaDVtOXNqUmhx?=
 =?utf-8?B?c3BEVVhyb2Z0UHp5bTFBcU5yZDhJMUFGaW8xUlJGVjVKVnd3aXFDVjNYamRx?=
 =?utf-8?B?VStsMEdlOGd4TmRHWUQ5LzBGWkI2d1pKb2ZZT2wzZHZITXB1a2J0OWEzcnM5?=
 =?utf-8?B?OW5jcENiM1hXNFQvRTNDQlpBdzFvREZ6ZzlMMDdKc0pMZC9ZeDZXZFJOUUNi?=
 =?utf-8?B?SHBzYy9hNUhjdUpJaUlxeGtOZWlUNzhMY2RHdHpwVDlqMkw4U25nOUhkYTR0?=
 =?utf-8?B?b05kUSt6Sk51VWZwLzBuQnRadGxiWXdmc0ZyaThUNFJTWUFYQnhoN1ZOR3RB?=
 =?utf-8?B?cUZjaSs2SjEvdkVsRC83RHhqZ3RIRC9pbU5MSXdGMmYvdTRxUCs0YU00WjBn?=
 =?utf-8?Q?xbIOvXclBgWNj2gOJHhJur9XiMO4VE=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?THRkQ2toRWJNYkJEZkIwTHhENS9OUUtrWk9CQkhOUVFZbDlvRFMzdGk1ZERq?=
 =?utf-8?B?U2RWd2NyU0pVNEgyeVRIRDVQeDZMY0VpUTVvb1U2cEt6YWtuNnRzQ29PZXZC?=
 =?utf-8?B?U1VzYjdNU09ub3VtSFI4Zk1DNjJWRTVpM3kyem9BeC9xNXB0K3FLQ3NSZ2NB?=
 =?utf-8?B?N0JOVkpRZWJFbHFmRk8yL1h1UWlSaVBYdnFGYktPSHUycDQ3MjZuWnJNWDhq?=
 =?utf-8?B?M2JZdGl1SEFqOHdSRk12Q2FEMUFMU2JjWW9FcUpxRVUyclNZMlFaaXEvNW9m?=
 =?utf-8?B?OHFjWWJLTUV0REdXT3J3QWJYU3JqTUhDVUdlcU5HQ1RsY04waG1UMWZvQTZ3?=
 =?utf-8?B?NWtUN05BaDdqcWJMdXk1U2IwcFNudFJTTkJjazB1dm1UL0JHdTFudVN3R2R2?=
 =?utf-8?B?cmZLTlpqRmhLQ2RVdkdKTllWY1RWbnF0YmdrNFF5eTVqT3FnTytIRGM0NE0v?=
 =?utf-8?B?QWRjaFBDa1VBM2U5eGNNQkUyQzM0OHBSTDV6aHVnRnpxNWlkVXpwNkQ5OUlw?=
 =?utf-8?B?eFUxS3BuY1FaVndoOENlRDIyUlAyVlZrZVplY2JlQ0NOUUl5NEZwLzZBS0Jp?=
 =?utf-8?B?aFRkUzR1UU40MHBRd3FWWXl2R2JmL05CT3hjS292NXFLajJ3ZzFRcnpWREV5?=
 =?utf-8?B?UTNwK2xTa1YraW05WjM3akhFSHNVVHd5aDhQTDUwZk9LbjA2RGEyTWJLdlZ6?=
 =?utf-8?B?YTVoT3NRSVlMd0xEa3A0bThRc2YwUzVaeklMbHR1Y0JRVEVPRHZXZGFBaVNM?=
 =?utf-8?B?WjRsOTg5Z1huK2o3QTdhODNuM08yOUp1WEYzdERIODRJRjJjVXJYRHpkYWxY?=
 =?utf-8?B?djFmUm1OSHBabWYrYVNMNklUS24rN3liSEdFYkxKL1dJU21ibXRpVVpuQ3R0?=
 =?utf-8?B?L1Z5M0huaWYzS0QrWUhQQXlEMUl2MWdCbTRCVjd6MEdMemFjczJpTWpGd2dF?=
 =?utf-8?B?SDIxRjJZeWI5YU50TFdGd3RkNXZwbnlpekRIRUhsWlFXaFNTbXBKbEpxWW9X?=
 =?utf-8?B?NUpBS05pbktmRmlxbEgxM1RNbXB6UE9PYUVtdm16UXFkLzZicFY3RnlyTEI2?=
 =?utf-8?B?aDBCMGFpeTV6NEVCWDM0SGttSjlaZG9OczhpNGRPSWpHV0UySUdHYytpTkll?=
 =?utf-8?B?YWg2TFdoay9ZWTkvRm5YMUxmUy9oTlFFUGpEQlRXd3EwbFdaaTgzMDhqTDhz?=
 =?utf-8?B?b010aVdla0FxNkNtdVpFRnlCNDZyUHBGaHk1ZTRaKzVDTU5aV3o0TmFPZ3Zh?=
 =?utf-8?B?MWErVjBMTGVpdGg5eFlrTnFDd1hsUk9YRk11OTBlMG5QRVFYelErOHNFaGFj?=
 =?utf-8?B?UEVEdnFKc1dEUm9ETDdubHBSMFNEYTBXWnZEMDM2YnQ1UzhWL0IrSnBTVzRH?=
 =?utf-8?B?Rjl5ays0R3R2VkFpb2dZdXhoTGN4ZzRRZ2xHNzJMdUZualA2eUxKaVVPUGVK?=
 =?utf-8?B?RnBoektMdWloaFdlYzJJSkFrQy9tTWE4NVBBUUl1MTJZa0dWVkF2N3pvVFNu?=
 =?utf-8?B?QWVFNFpFVmIvMUdiZDFkM215bUlWQmk5eERNNXlWOGM3UFphMkU3T2JjVDFZ?=
 =?utf-8?B?NlhrNk43cVpGbkwwelIraHJTZ2Q0NmgzcUxKbWdrcWZJYTlxVEgzV21wRWVQ?=
 =?utf-8?B?TUZiKy9Bem9wUjRqaEIrWEU5YzA3azh0d3RyNSswK1RWUnVzRGdjWUtGOUd5?=
 =?utf-8?B?Z1lvMU8vMEQyUnpSdytsYklFZVlucFZkZnFHRmF3WkpCWHdJVlBITEs3K1By?=
 =?utf-8?B?ZFF6eVJLc3FkcEVlRTVYZG1OcWJXQkt3eDV4UTFjQkRMWUdEZndVVERGNmZP?=
 =?utf-8?B?Sm8xN1JrMHg3U1pQaXVzaFZmczlHSHJsZC9TV0IxWHh2VGMrS2dhOXlGWWpo?=
 =?utf-8?B?bmF5c2NpeU02YnA1YUs4WDU4OE9QNFhZZUtuNGtZOFBETDZiN1A4RXVZcHFF?=
 =?utf-8?B?Z25sK1dySFk5bk44YXpXL1p6UTBWcXJqcC9pYVRQb2ZSV01ZK3FOSlc1b2xQ?=
 =?utf-8?B?dC9aZDdpMGt2Nm9kMWdYdUM3V2ZQNjcwVDZDZ3VPS2VFMmUvNFYwdDZYUE51?=
 =?utf-8?B?QSszYU03UzcxVGVmYWxnUUgxaVNBWkt1ZzN1VjArSEl5V3FVSWpQcUh5a3hO?=
 =?utf-8?Q?0W14=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2A40C82DB61CDB4FA4125B8ED973A71B@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: 2602ace3-091e-45a5-f68c-08ddf04bf628
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2025 09:25:19.9003
 (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: 7eITj2/dYGVIlTSiwG6g1Cr2Mkjac0PEHhIIzfh3cjs+AB0tFmmFCze7bGdsRGp1yQVibiShlqCEk5nZMS5qcA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4287

T24gMjAyNS84LzE1IDAwOjAzLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6DQo+IEhlbGxvLA0KPiAN
Cj4gVGhlIGZvbGxvd2luZyBzZXJpZXMgc3RhcnRlZCB3aXRoIHRoZSByZXBvcnQgaW46DQo+IA0K
PiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvZGJjMDAzYTItOTIwMi00NmVjLWJm
ODctMjgyOWQ4YTYzZDUzQGNpdHJpeC5jb20vDQo+IA0KPiBBbmQgZW5kZWQgdXAgZG9pbmcgYSBi
aXQgb2YgY2xlYW51cCBvbiB0aGUgd2F5LiAgSSB0aGluayB0aGUgb3ZlcmFsbA0KPiByZXN1bHQg
aXMgbmljZXIsIEkgbmV2ZXIgcmVhbGx5IGxpa2VkIHRoZSBkZWZlcnJhbCBvZiB0aGUgc2V0dGlu
ZyBvZiB0aGUNCj4gY29tbWFuZCBhbmQgUk9NIEJBUiByZWdpc3RlcnMsIGFzIGl0IG1ha2VzIHRo
ZSBsb2dpYyBtdWNoIGhhcmRlciB0bw0KPiBmb2xsb3cuICBJJ3ZlIGRvbmUgc29tZSB0ZXN0aW5n
LCBidXQgSSB3aWxsIHByb2JhYmx5IGRvIHNvbWUNCj4gc3BlY2lmaWMgdGVzdGluZyB0byBlbnN1
cmUgdGhlIGVycm9yIHBhdGhzIHdvcmsgYXMgZXhwZWN0ZWQgLSBhcyBJIGRvbid0DQo+IGhhdmUg
YSBzeXN0ZW0gdGhhdCB0cmlnZ2VyIHRob3NlLiANCkkgaGF2ZSBhcHBsaWVkIHRoaXMgc2VyaWVz
IHRvIG15IGxvY2FsIGVudmlyb25tZW50IGFuZCBydW4gc29tZSBub3JtYWwgZ3JhcGhpY3MgYXBw
cyB3aXRob3V0IGZpbmRpbmcgZXJyb3JzIGN1cnJlbnRseS4NCklmIHlvdSBuZWVkIHRvIGRvIHNv
bWUgc3BlY2lmaWMgdGVzdHMsIEkgYW0gaGFwcHkgdG8gaGVscCB0ZXN0aW5nLg0KDQo+IFBvc3Rp
bmcgaXQgYWhlYWQgYmVjYXVzZSBzb21lIHBhdGNoZXMgYXJlIGZhaXJseSB0cml2aWFsLCBhbmQg
dG8gZ2V0IGZlZWRiYWNrIG9uIHRoZSBhcHByb2FjaC4NCj4gDQo+IFRoYW5rcywgUm9nZXIuDQo+
IA0KPiBSb2dlciBQYXUgTW9ubmUgKDUpOg0KPiAgIHhlbi92cGNpOiBwdXJnZSBCQVIgcmFuZ2Vz
ZXQgY29udGVudHMgYmVmb3JlIHVzZQ0KPiAgIHhlbi92cGNpOiBtYWtlIEJBUiBtYXBwaW5nIG1v
cmUgcmVzaWxpZW50IGZvciB0aGUgaGFyZHdhcmUgZG9tYWluDQo+ICAgeGVuL3ZwY2k6IHNpbXBs
aWZ5IGhhbmRsaW5nIG9mIG1lbW9yeSBkZWNvZGluZyBhbmQgUk9NIGVuYWJsZSB3cml0ZXMNCj4g
ICB2cGNpL21zaXg6IG1vdmUgTVNJLVggaG9sZSBwdW5jaGluZyBhcyBhIHJlc3VsdCBvZiBtZW1v
cnkgZGVjb2RpbmcNCj4gICAgIGVuYWJsZQ0KPiAgIHhlbi92cGNpOiBvbmx5IGNoZWNrIEJBUiB2
YWxpZGl0eSBvbmNlDQo+IA0KPiAgeGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYyB8IDE4NiArKysr
KysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgeGVuL2luY2x1ZGUveGVuL3Zw
Y2kuaCAgICB8ICAgNSArDQo+ICAyIGZpbGVzIGNoYW5nZWQsIDgyIGluc2VydGlvbnMoKyksIDEw
OSBkZWxldGlvbnMoLSkNCj4gDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQoN
Cg==


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 09:27:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 09:27:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118003.1463945 (Exim 4.92)
	(envelope-from )
	id 1uwH7A-0002vF-3v; Wed, 10 Sep 2025 09:27:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118003.1463945; Wed, 10 Sep 2025 09:27: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 1uwH7A-0002v8-0M; Wed, 10 Sep 2025 09:27:44 +0000
Received: by outflank-mailman (input) for mailman id 1118003;
 Wed, 10 Sep 2025 09:27: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 1uwH79-0002v2-Io
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 09:27:43 +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 654f1236-8e28-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 11:27:41 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CY5PR12MB6478.namprd12.prod.outlook.com (2603:10b6:930:35::19) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.22; Wed, 10 Sep 2025 09:27:37 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 09:27: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: 654f1236-8e28-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AQIRySiVnWN9Pf6I7zdHZ/XEz82Q3m4gH7T7IyTO1tBciSNrBOnoH8wJXJhzkAwOFt63kxYuVN9nb8fAAtXdlpZMmbYhDza05VUrUDo7kNiNHjnrGod8hVNnGe6Qs04B87bN7KkEbV4WAIuhu78dq9XXIS71zTVu+KS+uUI9uUVirVglSne3MvC2vYIEhkBnPd1ZTvOjYeNwhySKsvFQjoZTU1i8ulvxs24vPLQYd462QVz1AwenMU7/BF1ZlR0rBU+03Zb0//7vy+2ePJb77A/89SfaXToNty01feYCFrQxCGwyC8Jz6U7GfgrHflNcoViQjaWczIbNd1DIxlq2oQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DGXHiE8g5bVKV4cF/SsCihL+O9WUEvnQ2BN8kxq5k3o=;
 b=bvVMszrzC1V2gXgZp1dr1pS97ZABpPXb+RK+PpGYbWm+gRidgTztrOGM1JxpxW9vgFwiJthG/9e9/uzXSuVT5gvKURYF7649YZbyzHCaZO+QDZqXY34uXoYhKyfuizUv7dpjrz69MVbum12pFzm8ewEvBh3jnpJE/x53PHigyO3NcdhSiWt6gIroYDaLr+GKHFfC4RvnwJP0gyPPX8NJk5lsFtYEAFRI3T+E/eDiDW3MlyoWag4WS1Qf0Ah2t4xdoj2PwTzWh2lwgI4/6Gy07mfjTeuF1zr16AAbGgQ3YQCqaBoGqKALWqddn6WGHhnLJfmN94R4f+dMyiMxZn0x+g==
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=DGXHiE8g5bVKV4cF/SsCihL+O9WUEvnQ2BN8kxq5k3o=;
 b=xQaOxJW6Y6l5rsV8IEOlZTc2WKU/ZHDjO8VEk3ES9X7npGtsRXhSl+zCn6dSKY+eegntHVs0owfFyC7IHModjL+CU98vF23abR3D74nULxRdyMM8tyhKuZoUKpmn1OOm5QBii1JUJBc5S5+kpoQYQf4GCm4ErLwgoFtZ+fzFy+U=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: Andrew Cooper ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Anthony PERARD
	, "Orzel, Michal" , Julien
 Grall , Stefano Stabellini , Juergen
 Gross , Oleksii Kurochko ,
	Community Manager ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v9 0/8] amd-cppc CPU Performance Scaling Driver
Thread-Topic: [PATCH v9 0/8] amd-cppc CPU Performance Scaling Driver
Thread-Index: AQHcHWYmANxehc4TY0iF4B3xrysaNrSLDcCAgAEffUA=
Date: Wed, 10 Sep 2025 09:27:36 +0000
Message-ID:
 
References: <20250904063518.2097629-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-09-10T09:23:04.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_|CY5PR12MB6478:EE_
x-ms-office365-filtering-correlation-id: df0dd64b-3169-45a3-c8df-08ddf04c47d3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?N1pPSzBpWSs4Rk9zQTRKVzV2VlI1U2NnM2I1TlVzU0lpOEZ2YjlsaWljWkFO?=
 =?utf-8?B?TnNrdUxCY2NndTFydnBVTWJHbEUyTXpqTllaMDRESU1sVThmY0svU1lnWFYz?=
 =?utf-8?B?M2VWcitzYVRkMEhxdVZPSS9rdWJUay9hcFduSWFoaFdUV204VHZDRUkxTEFB?=
 =?utf-8?B?Y0tmNHk0R0hIWlBDVWswS1FLSENQQTlCcExaWEE4RlJ5eEN1QTRGTDczRUNV?=
 =?utf-8?B?MzJ6cGlXSk5uZWt4ZGpiVlBaM1I2UEpIS1pja2xscDE1bzBNUWpBQitSMkxn?=
 =?utf-8?B?Qzh0T3VjQVNjUW05c1IvNkpNREdzWXEvSWw3TjNlcFNXWHhjUnpmRGo1MHJx?=
 =?utf-8?B?Snh3cDF5bEdicUZaQ20rUmY0Z2ZSVmkrTEhrSlUyMC9JQzQxdzVKM1JqSlYr?=
 =?utf-8?B?UzdoWUxCT1J1bjU0bkRzdGhGcXZ6V1hkcit2S1NyYnlsMmh1dDVzSU9xL0xX?=
 =?utf-8?B?RzRTOTdvL0UxcHgxdGxGbHRkT21kK2NpVnhZeTQyV0FmbE9IeUlUVEVMWjVL?=
 =?utf-8?B?blp3ZmRvdkFWUVhtRUpsOWFLQUtEZHp5OWxQWnkzaFovTmNPaVNua0Y0Qk5T?=
 =?utf-8?B?UjFJdlRLOFgvNkgvRitmWExwTHd0K1BwSkNzdEhFakhlQ3ZUeVNQb3pGM0hK?=
 =?utf-8?B?a3cwMFZBYkc3NlRsVGZ3ekhCa3JGU2E5b1lqT1k3RURzdG54clR6VjNzRS84?=
 =?utf-8?B?RGRndHNNVFlzYzZ1YUl6NkJxa211QnhmbS9KLytXUEg4M2crckI2MjhMdG5J?=
 =?utf-8?B?cmpHRjJ2OU8rK1BnMG5oSWt5QlM3aHdaMnlWbmE1ckEwWnV0d0hHSGh6RDdz?=
 =?utf-8?B?eHBpbk1uUG5sS05haXR2RVREQ0h3WlA1TUlvQWdNVWZ5YkJNckZ3N3dIdVpj?=
 =?utf-8?B?aGx6N0pYUVZBQ04yVzd0WE9uazFXbkxHdnFXSUVOVExCUkpaRUw4dVBMV3F1?=
 =?utf-8?B?YzZyQTdsT1lHU3BXNVlpYU9FbFFZUzU1Si9lcVVnay9aenhLanZNTjVHUmlx?=
 =?utf-8?B?eXZsMldDUC9OdUxreXA4OFJPSUJFOURVajdXalFQeVhvSE41UXpJYzg5L29r?=
 =?utf-8?B?R0hkMnNwNFdkQ0dXc2VnWDE0Ny8wRVhBNkZOV1cwNUlnbTZGRmliK2ZwNGpx?=
 =?utf-8?B?V0pqOWhlcWJaVlFOSWVpWnAwRkhpQmZEc1lFWFhQVUo5di9DUjh3WEdQZVNz?=
 =?utf-8?B?Mzk2MmFNQjZ3bTZrbFpwejIwcmcrbWVlYlp3Tk9Uc2tKeUtOdkpMamlscmo4?=
 =?utf-8?B?b0UyekpSbHA3Nk5RWU1QUE9QemhQOHd6RVlhQXRZS2pDV05UeFMrN0tMUXBM?=
 =?utf-8?B?eVZuVGdzc2JuVHF5ekVmQkFIYWNXb1pyd3lVU2dtR2pGRjNHT3crMDZlbE9t?=
 =?utf-8?B?VGZmOUlsSUY5SVl6V2hrUkpQblpMZTdrZjh3MkxVOXNYalJTb2cvWGNTeWR0?=
 =?utf-8?B?bENQNDFTNmI2NGlHVkFSUSt5ODVhc0FzenRzRVo5SURMN2VDb2p5MnB6UG1M?=
 =?utf-8?B?dHhZQThMQmdrUEpkQTF4WE41eTNrZ0VJdWVidkdtcnc1WVhPSXE0cDZvU1ZR?=
 =?utf-8?B?dmx1azJkSHBuUCs2WUpCQUxrcGVlRHJERDUxQlFGTzkrTjE2bUpnY294UjU5?=
 =?utf-8?B?NkVyQjdja1BzNDNRQ3JJZVI0NXlGUGFDTmVaS1dzTTJBeVRGMFY5NEVLRVdT?=
 =?utf-8?B?TkhENDFVVnpTV0xUMjFHUWZvaHpYTVRHMTFVeG94R2FlWXhjRzMySjhmaDVP?=
 =?utf-8?B?NzhUK2dieXhLdm4rOFRwUCszSXRSdkR3RjU0QUk3eE5RRmtsdE13SVBzQVN4?=
 =?utf-8?B?czNSM3F0ZzBCRVJZU2J4aEhQRnJ6V1hDRDhjaUcwWDlNczViWkl5ZlFNbE1U?=
 =?utf-8?B?KzUyL2wvakR4WklGRUJabzdaWUNrTVhPb25pWHdIWmNxeDI2UHc0ZzVZNFZH?=
 =?utf-8?B?cjJ4cG1GT3RBZFk3QVphUHI1ZGV0bmVnV09VMFgxSHVEYzhkNXl3Mkd6aFE5?=
 =?utf-8?B?WStvc0RYc2hnPT0=?=
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)(7416014)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TmFSdXRmZTRNcWgvQmkrQjgweGpJZ3VURkJFM3JZUjliR2NaUXFqZHYvdDVj?=
 =?utf-8?B?eWt2ckFteTYrZ3VsZWZCcW5mOS8zS2JPQXN0K01NWmFzU01WZDlXZVBXamV0?=
 =?utf-8?B?aG1sMnN0NHJRY1RuMU9uVW9COWxwWUNXVG5Rem5EbFZQYmFlU3NrRkgzVExq?=
 =?utf-8?B?d1MyOG5hK0J2MFNaZDdQdDMzYkkzNkIzQWtwUFlEbk5MVk1EOWxaYVVKeDRa?=
 =?utf-8?B?TmJScFVoVHY5b25LVFMxSUIwTGU3VkcreDA1TkJMY3d6eFpNUkRoQjMva28v?=
 =?utf-8?B?ek1PK0xoWUgwczBpZG1MeFhoQ2w0bVRLSFRWc0Q2VVVEUUphcmxTN1hUcFVm?=
 =?utf-8?B?bmlWbnh6Q1lINHBTRmVqVkZ0WHJ0NW81SkFPZjhnVGYwQVI4WWZodzVWMThr?=
 =?utf-8?B?Y1hQYkh2MEpwWnRPNHdHRlkzRXRCT1FrVjg5bDFkTW1ZU2V1YnFpMEVSajcx?=
 =?utf-8?B?YURsNmZUblcwdnBxbHdPWmIwSEhhc0crdk03djQyT1lIOGxjVDJ2L0Q5T2NZ?=
 =?utf-8?B?eDJ5SlJyQ2VkMExzVk1Eak15OHV3ZFd4NDM3TTQ2S2EwR2g1N0RCSjEwZmFp?=
 =?utf-8?B?aU1lTmJnTGN0czlXcnZReEdsTThEMTlFTnZqdFh5NEZaZXlsajljTVoydmVz?=
 =?utf-8?B?M2VucGwyTWNDMFFkeEZsVld4VUtEdGx1Q1FtVTZKbVpHQWlGMHdxUHJFQk5W?=
 =?utf-8?B?dnVNSCtCZlJiMlBYSTdGb1BZRENmRi8zVHJiMlZJVGtyOXZjSWZCOGs1NWYr?=
 =?utf-8?B?aUxieUYvL2FZbnc3MjZBblhUeFF6YXhuRk9OM0VVU0dQTGt3b2I5SlNMcjFQ?=
 =?utf-8?B?eHFyNmw5d0lseEJuNVNmZmVVb25SV3I3OEhqNUU2Q0dLR2k4THFNck1na1Vn?=
 =?utf-8?B?cEVFNVpaVXdWQ3lSdFRVMWJQai9Pa3lQcjk2MEhtZ2psQlBhN2liekRsL2Jo?=
 =?utf-8?B?ZEpiRGRnV3U2d0J6SkVxRVJkeXF6MzBPS0RtdG95NGw5OGVycGt4SnEyYVRs?=
 =?utf-8?B?V3VqWEJsTzJiTmJBVENRYzJhUXVwemliMW51c2RXcnl4YUtFL0tGME1tVElL?=
 =?utf-8?B?QnAvcGlLRnNac0pjVEFaVExnL1RiNTJRRVVtK0xpdEJKMDVGN0p1OU9DaTc3?=
 =?utf-8?B?SXd1M2hXTTFORlB1R0p5Lyt1VGcwQUdYREo0ZEk3T0oxMTViUXNmYmx1Rk45?=
 =?utf-8?B?K3l2c0hCL0VLdzBVdXl2d0lHRXBqVWtzMm4vdU0yd0cyUktGK0ZnZmxvN0JR?=
 =?utf-8?B?RXc3Yk1mSlFBM2p0WVZVQ0dpNnBqSHdKSzFyZE8xWUJnelV6RUQveGNiRDNE?=
 =?utf-8?B?SkpkdWlCdFZlSFIxMHFKbVVQM1pwTnhIWnlzTXR1ZWE0NXFmZ2xOTHB3OTB0?=
 =?utf-8?B?ZkxtUGZBSURkc0ZOdlZLc05BSGRNcll5Y2JZYzhCM1owVHFkR1JrekRDT0NT?=
 =?utf-8?B?MDNudXZFTS9Zd1BheUhxZTNETDdYNmZMNXJrcHBQK1hXem13Rld0RnVOT2hT?=
 =?utf-8?B?bUozeGpnQ2xuRERWeUpYSGdQa2ZFVitzQmJEK0V5YTVSTVhyaUlTbFY3cVpa?=
 =?utf-8?B?cFlPNlZ5MEQ1dTN6NmZJT2pWTUxKcS9DcEZBeWRQQ050VTdicDgxNFVoRlp1?=
 =?utf-8?B?Yjc0aFJYdi9reWJsUFhTMzhXUmxsS0J4YlBTNGJ2TzROdmw3VXdZVnVURDRE?=
 =?utf-8?B?Z2hIUkZ0a2VvYXg1c0QyK0hWQmJWRyt1ZFhwMzdzc05CYk5jOG1WMnRjSmEy?=
 =?utf-8?B?ZEJQOVpmRmlNemdBUTJqTUE4a1psQS9rQUVPOFMrS2lBaGRFQ2dmTW1Za290?=
 =?utf-8?B?cThKbWM5blFMRkRjOVN1MUg5Z2p6VlVGbFFBdjBjRkptRGJaVFlwZHlnTTF4?=
 =?utf-8?B?Y0Y4WjM0aVgxbjB3MlRJb0YyWExYZTVkcnBHZlcyeWlxT0N4R09oZkF5bDR1?=
 =?utf-8?B?WVUwUUhkSi9VeVk5LzlXU0V3QWhyYXAvdmdCZExyenIyZHBXRDZmWXJEb3Y0?=
 =?utf-8?B?MUNTSjRDK0pqR3FyU281dmczY1dDSmNWRzdwN2lTNERKMy9RMEFGa3pCU1BU?=
 =?utf-8?B?cmpDRzYwZ2ZNODh4SGY1QUlMM1hESEdGYlBZMHFpNjlSVjRESlhwYlg5bFJz?=
 =?utf-8?Q?+klQ=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: df0dd64b-3169-45a3-c8df-08ddf04c47d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2025 09:27:36.9169
 (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: fqdnIBPZOzXTKgXRCpCFOKI+Yqoz2gCqmEjW1kPOfpWKCnMsSnbcZHxJ43SLkBknvo0qpuKlyJ4l6NeWEhDjeQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6478

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEw
LCAyMDI1IDEyOjExIEFNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIg
UGF1IE1vbm7DqQ0KPiA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50
aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9yemVsLA0KPiBNaWNoYWwgPE1pY2hhbC5PcnplbEBh
bWQuY29tPjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFN0ZWZhbm8NCj4gU3RhYmVs
bGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz47IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNl
LmNvbT47IE9sZWtzaWkNCj4gS3Vyb2Noa28gPG9sZWtzaWkua3Vyb2Noa29AZ21haWwuY29tPjsg
Q29tbXVuaXR5IE1hbmFnZXINCj4gPGNvbW11bml0eS5tYW5hZ2VyQHhlbnByb2plY3Qub3JnPjsg
eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjkg
MC84XSBhbWQtY3BwYyBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXINCj4NCj4gT24gMDQu
MDkuMjAyNSAwODozNSwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gYW1kLWNwcGMgaXMgdGhlIEFN
RCBDUFUgcGVyZm9ybWFuY2Ugc2NhbGluZyBkcml2ZXIgdGhhdCBpbnRyb2R1Y2VzIGENCj4gPiBu
ZXcgQ1BVIGZyZXF1ZW5jeSBjb250cm9sIG1lY2hhbmlzbSBvbiBtb2Rlcm4gQU1EIEFQVSBhbmQg
Q1BVIHNlcmllcw0KPiA+IGluIFhlbi4gVGhlIG5ldyBtZWNoYW5pc20gaXMgYmFzZWQgb24gQ29s
bGFib3JhdGl2ZSBQcm9jZXNzb3INCj4gPiBQZXJmb3JtYW5jZSBDb250cm9sIChDUFBDKSB3aGlj
aCBwcm92aWRlcyBmaW5lciBncmFpbiBmcmVxdWVuY3kNCj4gPiBtYW5hZ2VtZW50IHRoYW4gbGVn
YWN5IEFDUEkgaGFyZHdhcmUgUC1TdGF0ZXMuIEN1cnJlbnQgQU1EIENQVS9BUFUNCj4gPiBwbGF0
Zm9ybXMgYXJlIHVzaW5nIHRoZSBBQ1BJIFAtc3RhdGVzIGRyaXZlciB0byBtYW5hZ2UgQ1BVIGZy
ZXF1ZW5jeQ0KPiA+IGFuZCBjbG9ja3Mgd2l0aCBzd2l0Y2hpbmcgb25seSBpbiAzIFAtc3RhdGVz
LiBDUFBDIHJlcGxhY2VzIHRoZSBBQ1BJDQo+ID4gUC1zdGF0ZXMgY29udHJvbHMgYW5kIGFsbG93
cyBhIGZsZXhpYmxlLCBsb3ctbGF0ZW5jeSBpbnRlcmZhY2UgZm9yIFhlbg0KPiA+IHRvIGRpcmVj
dGx5IGNvbW11bmljYXRlIHRoZSBwZXJmb3JtYW5jZSBoaW50cyB0byBoYXJkd2FyZS4NCj4gPg0K
PiA+IGFtZF9jcHBjIGRyaXZlciBoYXMgMiBvcGVyYXRpb24gbW9kZXM6IGF1dG9ub21vdXMgKGFj
dGl2ZSkgbW9kZSwgYW5kDQo+ID4gbm9uLWF1dG9ub21vdXMgKHBhc3NpdmUpIG1vZGUuIFdlIHJl
Z2lzdGVyIGRpZmZlcmVudCBDUFVGcmVxIGRyaXZlcg0KPiA+IGZvciBkaWZmZXJlbnQgbW9kZXMs
ICJhbWQtY3BwYyIgZm9yIHBhc3NpdmUgbW9kZSBhbmQgImFtZC1jcHBjLWVwcCINCj4gPiBmb3Ig
YWN0aXZlIG1vZGUuDQo+ID4NCj4gPiBUaGUgcGFzc2l2ZSBtb2RlIGxldmVyYWdlcyBjb21tb24g
Z292ZXJub3JzIHN1Y2ggYXMgKm9uZGVtYW5kKiwNCj4gPiAqcGVyZm9ybWFuY2UqLCBldGMsIHRv
IG1hbmFnZSB0aGUgcGVyZm9ybWFuY2UgdHVuaW5nLiBXaGlsZSB0aGUgYWN0aXZlDQo+ID4gbW9k
ZSB1c2VzIGVwcCB0byBwcm92aWRlcyBhIGhpbnQgdG8gdGhlIGhhcmR3YXJlIGlmIHNvZnR3YXJl
IHdhbnRzIHRvDQo+ID4gYmlhcyB0b3dhcmQgcGVyZm9ybWFuY2UgKDB4MCkgb3IgZW5lcmd5IGVm
ZmljaWVuY3kgKDB4ZmYpLiBDUFBDIHBvd2VyDQo+ID4gYWxnb3JpdGhtIGluIGhhcmR3YXJlIHdp
bGwgYXV0b21hdGljYWxseSBjYWxjdWxhdGUgdGhlIHJ1bnRpbWUNCj4gPiB3b3JrbG9hZCBhbmQg
YWRqdXN0IHRoZSByZWFsdGltZSBjcHUgY29yZXMgZnJlcXVlbmN5IGFjY29yZGluZyB0byB0aGUN
Cj4gPiBwb3dlciBzdXBwbHkgYW5kIHRoZXJtYWwsIGNvcmUgdm9sdGFnZSBhbmQgc29tZSBvdGhl
ciBoYXJkd2FyZSBjb25kaXRpb25zLg0KPiA+DQo+ID4gYW1kLWNwcGMgaXMgZW5hYmxlZCBvbiBw
YXNzaXZlIG1vZGUgd2l0aCBhIHRvcC1sZXZlbA0KPiA+IGBjcHVmcmVxPWFtZC1jcHBjYCBvcHRp
b24sIHdoaWxlIHVzZXJzIGFkZCBleHRyYSBgYWN0aXZlYCBmbGFnIHRvIHNlbGVjdCBhY3RpdmUN
Cj4gbW9kZS4NCj4gPg0KPiA+IFdpdGggYGNwdWZyZXE9YW1kLWNwcGMsYWN0aXZlYCwgd2UgZGlk
IGEgNjBzIHNhbXBsaW5nIHRlc3QgdG8gc2VlIHRoZQ0KPiA+IENQVSBmcmVxdWVuY3kgY2hhbmdl
LCB0aHJvdWdoIHR3ZWFraW5nIHRoZSBlbmVyZ3lfcGVyZiBwcmVmZXJlbmNlIGZyb20NCj4gPiBg
eGVucG0gc2V0LWNwdWZyZXEtY3BwYyBwb3dlcnNhdmVgIHRvIGB4ZW5wbSBzZXQtY3B1ZnJlcS1j
cHBjIHBlcmZvcm1hbmNlYC4NCj4gPiBUaGUgb3V0cHV0cyBhcmUgYXMgZm9sbG93czoNCj4gPiBg
YGANCj4gPiBTZXR0aW5nIENQVSBpbiBwb3dlcnNhdmUgbW9kZQ0KPiA+IFNhbXBsaW5nIGFuZCBP
dXRwdXRzOg0KPiA+ICAgQXZnIGZyZXEgICAgICA1ODAwMDAgS0h6DQo+ID4gICBBdmcgZnJlcSAg
ICAgIDU4MDAwMCBLSHoNCj4gPiAgIEF2ZyBmcmVxICAgICAgNTgwMDAwIEtIeg0KPiA+IFNldHRp
bmcgQ1BVIGluIHBlcmZvcm1hbmNlIG1vZGUNCj4gPiBTYW1wbGluZyBhbmQgT3V0cHV0czoNCj4g
PiAgIEF2ZyBmcmVxICAgICAgNDY0MDAwMCBLSHoNCj4gPiAgIEF2ZyBmcmVxICAgICAgNDIyMDAw
MCBLSHoNCj4gPiAgIEF2ZyBmcmVxICAgICAgNDY0MDAwMCBLSHoNCj4gPiBgYGANCj4gPg0KPiA+
IFBlbm55IFpoZW5nICg4KToNCj4gPiAgIHhlbi9jcHVmcmVxOiBlbWJlZCBod3AgaW50byBzdHJ1
Y3QgY3B1ZnJlcV9wb2xpY3l7fQ0KPiA+ICAgeGVuL2NwdWZyZXE6IGltcGxlbWVudCBhbWQtY3Bw
YyBkcml2ZXIgZm9yIENQUEMgaW4gcGFzc2l2ZSBtb2RlDQo+ID4gICB4ZW4vY3B1ZnJlcTogaW1w
bGVtZW50IGFtZC1jcHBjLWVwcCBkcml2ZXIgZm9yIENQUEMgaW4gYWN0aXZlIG1vZGUNCj4gPiAg
IHhlbi9jcHVmcmVxOiBnZXQgcGVyZm9ybWFuY2UgcG9saWN5IGZyb20gZ292ZXJub3Igc2V0IHZp
YSB4ZW5wbQ0KPiA+ICAgdG9vbHMvY3B1ZnJlcTogZXh0cmFjdCBDUFBDIHBhcmEgZnJvbSBjcHVm
cmVxIHBhcmENCj4gPiAgIHhlbi9jcHVmcmVxOiBieXBhc3MgZ292ZXJub3ItcmVsYXRlZCBwYXJh
IGZvciBhbWQtY3BwYy1lcHANCj4gPiAgIHhlbi9jcHVmcmVxOiBBZGFwdCBTRVQvR0VUX0NQVUZS
RVFfQ1BQQyB4ZW5fc3lzY3RsX3BtX29wIGZvciBhbWQtDQo+IGNwcGMNCj4gPiAgICAgZHJpdmVy
DQo+ID4gICBDSEFOR0VMT0cubWQ6IGFkZCBhbWQtY3BwYy9hbWQtY3BwYy1lcHAgY3B1ZnJlcSBk
cml2ZXIgc3VwcG9ydA0KPiA+DQo+ID4gIENIQU5HRUxPRy5tZCAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgMSArDQo+ID4gIGRvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyAgICB8
ICAgOSArLQ0KPiA+ICB0b29scy9pbmNsdWRlL3hlbmN0cmwuaCAgICAgICAgICAgICAgfCAgIDMg
Ky0NCj4gPiAgdG9vbHMvbGlicy9jdHJsL3hjX3BtLmMgICAgICAgICAgICAgIHwgIDI1ICstDQo+
ID4gIHRvb2xzL21pc2MveGVucG0uYyAgICAgICAgICAgICAgICAgICB8ICA5NCArKy0tDQo+ID4g
IHhlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEvYW1kLWNwcGMuYyB8IDcwMyArKysrKysrKysrKysr
KysrKysrKysrKysrKy0NCj4gPiAgeGVuL2FyY2gveDg2L2FjcGkvY3B1ZnJlcS9od3AuYyAgICAg
IHwgIDMyICstDQo+ID4gIHhlbi9hcmNoL3g4Ni9jcHUvYW1kLmMgICAgICAgICAgICAgICB8ICAg
OCArLQ0KPiA+ICB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYW1kLmggICAgICAgfCAgIDIgKw0K
PiA+ICB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLWluZGV4LmggfCAgIDYgKw0KPiA+ICB4
ZW4vZHJpdmVycy9hY3BpL3BtLW9wLmMgICAgICAgICAgICAgfCAgNTggKystDQo+ID4gIHhlbi9k
cml2ZXJzL2NwdWZyZXEvdXRpbGl0eS5jICAgICAgICB8ICAxNSArDQo+ID4gIHhlbi9pbmNsdWRl
L2FjcGkvY3B1ZnJlcS9jcHVmcmVxLmggICB8ICA0NCArKw0KPiA+ICB4ZW4vaW5jbHVkZS9wdWJs
aWMvc3lzY3RsLmggICAgICAgICAgfCAgIDUgKy0NCj4gPiAgMTQgZmlsZXMgY2hhbmdlZCwgOTM2
IGluc2VydGlvbnMoKyksIDY5IGRlbGV0aW9ucygtKQ0KPg0KPiBBcyB3ZSdyZSBjb25zaWRlcmlu
ZyBvdXIgb3B0aW9ucyB0b3dhcmRzIGdldHRpbmcgdGhpcyB3b3JrIGluLCBjYW4geW91IGNsYXJp
ZnkgdHdvDQo+IHRoaW5ncyBwbGVhc2U6DQo+ICgxKSBJbiB2OSwgdGhlIHNvbGUgY2hhbmdlcyB3
ZXJlIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiBwZXItQ1BVIGRhdGEgYW5kIHRoZQ0KPiAgICAgYWRk
aW5nIG9mIGEgQ2hhbmdlTG9nIGVudHJ5Pw0KDQpZZXMsIGFsc28gaW4gY29tbWl0IG9mICJ4ZW4v
Y3B1ZnJlcTogQWRhcHQgU0VUL0dFVF9DUFVGUkVRX0NQUEMiLiBJIGFkZGVkIGRlc2NyaXB0aW9u
IG9mICJtb3ZpbmcgdGhlIGNvcHlpbmcgb2YgdGhlIGdvdmVybm9yIG5hbWUiDQoNCj4gKDIpIFRo
ZSBkcml2ZXIgaXMgaW5hY3RpdmUgYnkgZGVmYXVsdCwgaS5lLiByZXF1aXJlcyB1c2Ugb2YgdGhl
IGNvbW1hbmQgbGluZQ0KPiAgICAgb3B0aW9uIHRvIGNvbWUgaW50byBwbGF5Pw0KPg0KDQpZZXMs
IG9ubHkgd2l0aCBzcGVjaWZpYyBjb21tYW5kIGxpbmUgdG8gdHVybiBvbiB0aGUgZHJpdmVyDQoN
Cj4gSWYgdGhlIGFuc3dlciB0byBib3RoIGlzIHllcywgd2UncmUgbGVhbmluZyB0b3dhcmRzIGNv
bW1pdHRpbmcgdjggcGx1cyB0aGUNCj4gQ2hhbmdlTG9nIGVudHJ5Lg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 09:33:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 09:33:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118022.1463955 (Exim 4.92)
	(envelope-from )
	id 1uwHCC-0004VS-RW; Wed, 10 Sep 2025 09:32:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118022.1463955; Wed, 10 Sep 2025 09: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 1uwHCC-0004VL-Nr; Wed, 10 Sep 2025 09:32:56 +0000
Received: by outflank-mailman (input) for mailman id 1118022;
 Wed, 10 Sep 2025 09: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 1uwHCB-0004V1-PB
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 09:32:55 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20610.outbound.protection.outlook.com
 [2a01:111:f403:2408::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2084df31-8e29-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 11:32:54 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA3PR12MB7976.namprd12.prod.outlook.com (2603:10b6:806:312::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 09:32:51 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29%6]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 09:32:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2084df31-8e29-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zPHCFuf/asx4+a4YnMVqwtXtP4BHfyMSjll2ypvPyUEoVD2wQ+ftftDRpImXvxylU+QbN3TGM7NzcZnbRML+YCIJ67hCkojhpRgEIhAZm2WOUOruiv/ozlkloLotak7fRxNdWs58J9688Dcc7euegZv+yiQUX/uXUx6CQ9QyF+TNZBz/mjM4j0fnJlxLaMWtGHKRt8vk1CrEfUQT2Jc0ea6igxcnmu3o6uZ3FoDpgwuxzx3Lwixcr7129aQ+yZUTD6CZ7cCwdYz0tbLVz9wnbTlPVo+YCUPo5rruseYZ/7rfeUnX5OZmhUeobrDvoufXUIYo6er0shvb8GfCVMmFHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n1o4j0Ytf2SjFcRqQYzprcFxqQ7OlSGMvjpcoWcHEJM=;
 b=CzkLToqXT8cN/CqQwqQXLUAgxCtHPxaXMq49Tfs9TEjaxpe1iCUbjjSx/eQx1JDgwHRYHo6ZxObilxCrO5rb0qCs+/gK/0zDosL8EANqN/ewmEgDU1nkRTv+T5crV7h9weK+TSgyL7iHk9H8B3NqL/GFBNbjOnlaOqeYKsKA9z4nKKGZQxZVBaI/zZOeNg7gd+7EIvi40zVkUdM4OCKUOcwkHjSLbmg2F/qxOzM4XAt7U46P/Pvqpbno3G9ooK9Vo1NjM4nXOrzSGaqMKlzskP2KaIJtW6i7AvYq2F09mUBzhwu07O6j8Jwh/bJ0iDWTkV9JTnU1hfkYemOQMc7VIg==
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=n1o4j0Ytf2SjFcRqQYzprcFxqQ7OlSGMvjpcoWcHEJM=;
 b=EEnimU6odWiJhgRz2APYCvRjUqSdXut8hQlIOzUCjwmdowYT/8IpLE2S0ud4Zf9qSYV06SdUUBLF2LwwzRcqFipG2P//PM99SPsw2oYyOD/WmqoDvs63PIDp9L6q4lmKRkY4pOyw/+ORX1qM1O031zmTKM6PWzhJ3U5C0em3QFs=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v11 3/5] vpci/rebar: Implement cleanup function for Rebar
Thread-Topic: [PATCH v11 3/5] vpci/rebar: Implement cleanup function for Rebar
Thread-Index: AQHcCDsA6l8/pQuZ6kGf8SCBPZt3IbR5jRyAgBNS/AA=
Date: Wed, 10 Sep 2025 09:32:51 +0000
Message-ID:
 
References: <20250808080337.28609-1-Jiqian.Chen@amd.com>
 <20250808080337.28609-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.9094.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_|SA3PR12MB7976:EE_
x-ms-office365-filtering-correlation-id: 8330883b-a51e-46b7-5582-08ddf04d0337
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?SWYzSGY5akFsKzlNbGE1QmZocmExV2ZpS2k3WGtDVkZNbmYwY3MyRU0zc2FX?=
 =?utf-8?B?a01RNnNKNkh3a2JGaFFMVkNaQzlRanBlRnRXMExTSlFiWnZqUVkxZEJmcEsz?=
 =?utf-8?B?bXc0V21zaW4wb1FkbjRXUmJ5dENrSVVXUktESHNWRUtuTmRHRTgxTzFJclBh?=
 =?utf-8?B?NUpQRTR4WGZic1Njc1BHRTFZeEtYUkVHYUpwT040R0tVWDdFTDRPcGljY3Zh?=
 =?utf-8?B?dklMM1BVWEtOeHFjdUc1bUZIYkp3OGhKcy9vek56N2tPKzRzNXFXTUZtMmFW?=
 =?utf-8?B?MmE0T2F4M0QwQTdyUGh6Z1NGVi9Cb1k1Mmx5b0k4d3dXa2NjOWRnMXl5US8r?=
 =?utf-8?B?SnNDZHlHSUNRNVRybFdja2dCWktuNU1VRTBJS09PWTc3LzBIcGlIM3dDa3pz?=
 =?utf-8?B?SkY2bWd3RDdJRjU2RXNGdFNzQ2NVb095VkJxWitndW1Na1lSeEM0YmJEZzFr?=
 =?utf-8?B?MEJVaXorR0lpcWxFK1EvNU5GQ280Z05wS2s1alNPUDIra21VVEE1MXBUUGp4?=
 =?utf-8?B?eXVJS0hMSzAzeHFMRlVwcXZNUXJUbkFwNk5seGtNMWpOTlRFcHd5WE50aVZB?=
 =?utf-8?B?Q1RLM2N6NVhyUmp5NWlvNEF2MGlrWEg1MjFnT3hwcHBsY3l5eWl3SzA3cU9l?=
 =?utf-8?B?ZHJmak0zTTBpL2VPZ2ZRM1hOdWlwdzdKSXFTQ05oSGplaC9UZGlyblZPWktC?=
 =?utf-8?B?dFNCU0ppUGdYQmYwL05iTFMzUkxjQWsxancyaVNCMHJmejE0ZFlCVS9sQmdF?=
 =?utf-8?B?VEFuaC9aUGxKNjR2bjQ0WGRxZ0lNQWs1YWQrZnQrWWFmS0lIeFpscDZrRDRo?=
 =?utf-8?B?emxWa2xrOC9CZXo2MnVHakdISm1nNytkZThha0ppZ0FEYWNTMlI0Y2lYZ0FL?=
 =?utf-8?B?TndvRDNPMTJQOS9CbzhwUllPc1RJTG1Ici9xQVVQUlRsYWdBb3Rrci9QU3cz?=
 =?utf-8?B?N3M0Z3VmaDRqTW04MVI1T3JBb2RqU0NUa21ZemN2eVJsK2g4YW1ZRXJuV3c2?=
 =?utf-8?B?U0dheXd2alBUNHlCT0pueU9HamVwaGsrRHlBOVRLK0Zvd3daR21wY2JIWmFB?=
 =?utf-8?B?TjE3TUI3c1pJd3V3NGlVUHJjclVLTzRvRzd4aDk3bkNsY1hNM2t1enhCYitp?=
 =?utf-8?B?cUY5QmUxWU9PVDRycEVUSDVjTFNwT1dhS3hBeWJnWktsa0liVDFLeXI5b0lQ?=
 =?utf-8?B?bmZjRXdTWGVHUlhFTlkrZi9EZlBodEFhVGpwTlJzMzVnTHZvTVl4QzIvd1k0?=
 =?utf-8?B?ais5akdvK1JYRlRhTHpNRERsMERzcUJJVEttejdRa0YrTVA5cG5QRjBWMk1x?=
 =?utf-8?B?aDhFMG9yeXU1QlFwR3laNENmMlk0ak04WmU2c0J2RzI4UnNtbUIvMUhHdStV?=
 =?utf-8?B?Ymp5MFFPT1k0ZnlSQnBvQlVpSTZwL0I3OFAzekJRb2VDZGtGYk01WmtGUTNJ?=
 =?utf-8?B?OGUvNzhZUDA1U2t3enFXQUhYb29oSDgwWGZlSHpuODlQZ0NzNW1iUFBnTVkz?=
 =?utf-8?B?dVR5NVZrblBFbTM4cGRhbkUvS2hvOGNuS1N0amlSdWNCWmQyczRmaHFMUXVG?=
 =?utf-8?B?Zm9EN3lsK0Q5dkVkTzZMM01xOVdOMGczS21mcThlNEpqVjBQUE1RY3VuUjF0?=
 =?utf-8?B?VFVjR1cxVDhKMVBzSDRhNWlSRHFaK2NyNTFuaGxFTElrb0Z4cEJHQVRvWEVK?=
 =?utf-8?B?bkcrR0pERndhYTJ1TVI2SC9KMTk4ZVMvdGI3c1pXTmQ3NWJhZE81OWpqTEVs?=
 =?utf-8?B?eENvMGFsZDYzR1dVTGZXbDZ4TGhTQ3ZvRWhReHBGUFZtdmVQMnV0NVNyMldG?=
 =?utf-8?B?N2hDTVkvV2dMd3p3MVdxdlg0RUFEd1ZFVjFXT2lSQnF2VWhFNWkweDhoeXRP?=
 =?utf-8?B?bmxxTUlYV25FbUFZdGsvV0hQSDdXZ0VsZ2l3SFlXMC9NYzlqb1gvZkEvMmtv?=
 =?utf-8?B?Umc1MHJTRXNRbit1eVhDTkx4cFhodC9wTXlmTU8rd1dReFhwU1lwUnA5VnZy?=
 =?utf-8?B?elIzZjhWbGhnPT0=?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eWJWSmc2Qk1QL1A5UENGT2VCRko1KzVtREl3WnhkazZxWWZMQmZJaG1SWXZO?=
 =?utf-8?B?SWwyZjFQZGJ1NDMxSVJTMDBpU2FZcnRRRk45ZzN0SHYxelNUK3NpWEQyU28y?=
 =?utf-8?B?QjFOSnl5R0E3M0dSWnZtWUk3alVHbGM4L2VUc2hRYXM0VHY3WWs2eWd4elhJ?=
 =?utf-8?B?ZkNPMmtTejR1QTZPNXZUbnRCclF4SjNlcGJITjlLT3BrZitrOE15ZkJMRXpD?=
 =?utf-8?B?c29QVnVJd2JNdDY5MG1PT3hKSGFMVGdwZmRsdVRjYitrMHBOa1JQVFJST1Vz?=
 =?utf-8?B?WjRIRUVrTnpuSFhMbmRWdGpzSGVlczJ5ZWxoQXAxMnVnc3BYeEpQNDhIOWo0?=
 =?utf-8?B?WkhtUkRzZVRGLzcxZzZ5TkdlQnpzbTl1enZnOWszTFkycllwNEYwR0M4Y0JF?=
 =?utf-8?B?T293TloyL3FPOU1UVm5VLzNKdktaS3JyYU5uQy9UWGxtcGJTcnhBNXdGeXQz?=
 =?utf-8?B?T3U5Y0JOOWNGYXpVTW0rRVlqcE5UZzZ5RjlwYTczcmpaYllVbXU5Z25xTFJn?=
 =?utf-8?B?NFBvU0Y4Zld2ZzVPSHA5WTlDaFJMV0t0QmFvOTZXRHlQSzVHT0RnZ09PRFJs?=
 =?utf-8?B?bFQ4Zy8yaFhHR2lJL0pvRGRpTTRNYnlXTVhNcG9vNVJTNndDMWpWRzBsSHBx?=
 =?utf-8?B?c1J2azBGWE5XOSt6THUyRWxmcURwMTNGRWp2YnVTU2tyb0sydHlJMjRRRDlj?=
 =?utf-8?B?UkdwbmJyTWdsV1paUWRvMlp3KzlwczBFMEU2Z3Y4d2diUjg0UzNIZXprVVZN?=
 =?utf-8?B?Y1FtQ1pzT2xLU0hpME93NHJMNVpVUE9SU1FwWlFrNWRBaFZsb2lJbk43R1VH?=
 =?utf-8?B?b1RGc01MTlFaUXdBajlvdUZVTHJMT3pzTmkyQ2JPS2NydWJKSmhmdSttdlk2?=
 =?utf-8?B?NWlFMzlVemVpTzFUdWtZUTkzUTV3ZmU0RW1TOXFVRURqZmdaT0s2QWpqVjZW?=
 =?utf-8?B?MXVIcFBiVWFpUWJEU25BYkdIUlUxdk1JNVoya2dKcFhoVGh5eGg3TDc2L0lE?=
 =?utf-8?B?aTRCbDRZVUVXRzVQb0xRRDZITGpKR0ZvWm9JZENIOXZMZm9DOHNmYXErTTdl?=
 =?utf-8?B?R1QxdUkrRk1yQy9YV04xUUFnVXdPckxNMFl1ODBnSkNhaTRZbER3TXFTRUYy?=
 =?utf-8?B?QjFxL0V6eHlDK09xSzZaS0hiZ285WC9nQTFxRmxNTGx3ajdVSjBOREhoK1F6?=
 =?utf-8?B?R1V6bDB1R3hOK2JCL2ozcUt5RnFpS3k3eVZRUFd3d1BSMzNaOWw3SGt3ekJC?=
 =?utf-8?B?cy9nUGR0TUVWVi82ZXFnK29vLy9HSStjSVNEamF5RmlyWXJwTXpmcXBDRjRT?=
 =?utf-8?B?QmxBdXVRT05WNUZtV21rT3FsdytiZnlNazNKSlFVNEgvSnFENzNOSmw0ZU1L?=
 =?utf-8?B?Q1VYY1lkbWV3cExHelRKWVR6MDdkM213NkxTUlV6V2FqOGtyNmR3R2RTRWtn?=
 =?utf-8?B?SWFqSGRFSmJFeVVqMXEyc0RWQXBlT0hQaXJUbi9vSklGT1VXQXlBTmEveGx1?=
 =?utf-8?B?czFHU1p6WmNHVi9lVXlEVE1TNFR5cFZ6ZE1za2NTUm1pR25LQ0lUcEJqek9t?=
 =?utf-8?B?cSt0UmhtQ0pFUVZadHNZYVRqYjdHMG1lUGdjaHcvWGZzSmhVT295ZTRuWFY1?=
 =?utf-8?B?R1RkVjhmLzI4elJQcnk5MkxjWDEwRGY0czMySUlYK3JkazJhYlBWdWZERVVD?=
 =?utf-8?B?ajRXbytLcEZyaDlmbU0xOUV5QU9IVTZmMTVhWEFHRWF2RkR2QmNlOG1DeWp6?=
 =?utf-8?B?Y3BjOUV2dmw0OHkrTDUwc0JBUmRtaTlWUHhEcmEyTVFFQ21WYTIvWkR3NEZS?=
 =?utf-8?B?ZDlHd3QrY0E2RTluWngzN2ZPYmlVazhCVTJzMU0wb1pRaWFhcktBU3Q3dkM3?=
 =?utf-8?B?d0VKR0dwNzFLZVhUZUVTNC9ubkxvbEFIbUhsM3hjdnQyNEJYc1pGby9OQnJn?=
 =?utf-8?B?T0F5WXBVTHo4THRBU0pFb0tPRlJtRGNTMzRWU3ZTNjlETW00VjBTSyt1VUhD?=
 =?utf-8?B?ME12YkMybzFjQUpFSjNnbUJYeVpVTlBwYWozdTNkTjllWExXZUo2bk40U0lC?=
 =?utf-8?B?Mm5saWFZbFZVeEhkY0E1QVV1eXEvYzE5aVFRdnRrYlQ2ZGxVdnhLRnhUSXor?=
 =?utf-8?Q?HkrM=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: 8330883b-a51e-46b7-5582-08ddf04d0337
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2025 09:32:51.3378
 (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: CwvBg4wAdSwc0aFl/79J6TooWCBz8hoobQFdKVpA/21HHxN23RjSetutD9JUevaH496RuxgcpQEphjk9nZOo/w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7976

T24gMjAyNS84LzI5IDE4OjIyLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBGcmksIEF1
ZyAwOCwgMjAyNSBhdCAwNDowMzozNVBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IFdo
ZW4gUmViYXIgaW5pdGlhbGl6YXRpb24gZmFpbHMsIHZQQ0kgaGlkZXMgdGhlIGNhcGFiaWxpdHks
IGJ1dA0KPj4gcmVtb3ZpbmcgaGFuZGxlcnMgYW5kIGRhdGFzIHdvbid0IGJlIHBlcmZvcm1lZCB1
bnRpbCB0aGUgZGV2aWNlIGlzDQo+PiBkZWFzc2lnbmVkLiBTbywgaW1wbGVtZW50IFJlYmFyIGNs
ZWFudXAgaG9vayB0aGF0IHdpbGwgYmUgY2FsbGVkIHRvDQo+PiBjbGVhbnVwIFJlYmFyIHJlbGF0
ZWQgaGFuZGxlcnMgYW5kIGZyZWUgaXQncyBhc3NvY2lhdGVkIGRhdGEgd2hlbg0KPj4gaW5pdGlh
bGl6YXRpb24gZmFpbHMuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogSmlxaWFuIENoZW4gPEppcWlh
bi5DaGVuQGFtZC5jb20+DQo+PiAtLS0NCj4+IGNjOiAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPg0KPj4gLS0tDQo+PiB2MTAtPnYxMSBjaGFuZ2VzOg0KPj4gKiBBZGQg
QVNTRVJUX1VOUkVBQ0hBQkxFKCkgd2hlbiB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSBmYWlscw0K
Pj4gKiBXaGVuIGhpZGUgPT0gdHJ1ZSwgYWRkIGhhbmRsZXJzIHRvIGxldCBSZWJhciBjdHJsIGJl
IFJPLg0KPj4gKiBSZW1vdmUgUm9nZXIncyBSZXZpZXdlZC1ieSBzaW5jZSBwYXRjaCBjaGFuZ2Uu
DQo+Pg0KPj4gdjktPnYxMCBjaGFuZ2VzOg0KPj4gdjgtPnY5IGNoYW5nZXM6DQo+PiBOby4NCj4+
DQo+PiB2Ny0+djggY2hhbmdlczoNCj4+ICogQWRkIFJvZ2VyJ3MgUmV2aWV3ZWQtYnkuDQo+Pg0K
Pj4gdjYtPnY3IGNoYW5nZXM6DQo+PiAqIENoYW5nZSB0aGUgcG9pbnRlciBwYXJhbWV0ZXIgb2Yg
Y2xlYW51cF9yZWJhcigpIHRvIGJlIGNvbnN0Lg0KPj4gKiBQcmludCBlcnJvciB3aGVuIHZwY2lf
cmVtb3ZlX3JlZ2lzdGVycygpIGZhaWwgaW4gY2xlYW51cF9yZWJhcigpLg0KPj4NCj4+IHY1LT52
NiBjaGFuZ2VzOg0KPj4gTm8uDQo+Pg0KPj4gdjQtPnY1IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBk
ZWZpbml0aW9uICJzdGF0aWMgdm9pZCBjbGVhbnVwX3JlYmFyIiB0byAic3RhdGljIGludCBjZl9j
aGVjayBjbGVhbnVwX3JlYmFyIiBzaW5jZSBjbGVhbnVwIGhvb2sgaXMgY2hhbmdlZCB0byBiZSBp
bnQuDQo+Pg0KPj4gdjMtPnY0IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBmdW5jdGlvbiBuYW1lIGZy
b20gZmluaV9yZWJhcigpIHRvIGNsZWFudXBfcmViYXIoKS4NCj4+ICogQ2hhbmdlIHRoZSBlcnJv
ciBudW1iZXIgdG8gYmUgRTJCSUcgYW5kIEVOWElPIGluIGluaXRfcmViYXIoKS4NCj4+DQo+PiB2
Mi0+djMgY2hhbmdlczoNCj4+ICogVXNlIGZpbmlfcmViYXIoKSB0byByZW1vdmUgYWxsIHJlZ2lz
dGVyIGluc3RlYWQgb2YgaW4gdGhlIGZhaWx1cmUgcGF0aCBvZiBpbml0X3JlYmFyKCk7DQo+Pg0K
Pj4gdjEtPnYyIGNoYW5nZXM6DQo+PiAqIENhbGxlZCB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSB0
byByZW1vdmUgYWxsIHBvc3NpYmxlIHJlZ2lzdGVyZWQgcmVnaXN0ZXJzIGluc3RlYWQgb2YgdXNp
bmcgYSBhcnJheSB0byByZWNvcmQgYWxsIHJlZ2lzdGVyZWQgcmVnaXN0ZXIuDQo+Pg0KPj4gQmVz
dCByZWdhcmRzLA0KPj4gSmlxaWFuIENoZW4uDQo+PiAtLS0NCj4+ICB4ZW4vZHJpdmVycy92cGNp
L3JlYmFyLmMgfCA2NiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tDQo+
PiAgMSBmaWxlIGNoYW5nZWQsIDU1IGluc2VydGlvbnMoKyksIDExIGRlbGV0aW9ucygtKQ0KPj4N
Cj4+IGRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMgYi94ZW4vZHJpdmVycy92
cGNpL3JlYmFyLmMNCj4+IGluZGV4IDNjMTg3OTJkOWJjZC4uOTFkNTM2OWQ3NWUyIDEwMDY0NA0K
Pj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiArKysgYi94ZW4vZHJpdmVycy92
cGNpL3JlYmFyLmMNCj4+IEBAIC00OSw2ICs0OSw1NyBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayBy
ZWJhcl9jdHJsX3dyaXRlKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KPj4gICAgICBiYXIt
Pmd1ZXN0X2FkZHIgPSBiYXItPmFkZHI7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgY2Zf
Y2hlY2sgY2xlYW51cF9yZWJhcihjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgYm9vbCBoaWRl
KQ0KPj4gK3sNCj4+ICsgICAgaW50IHJjOw0KPj4gKyAgICB1aW50MzJfdCBjdHJsOw0KPj4gKyAg
ICB1bnNpZ25lZCBpbnQgbmJhcnM7DQo+PiArICAgIHVuc2lnbmVkIGludCByZWJhcl9vZmZzZXQg
PSBwY2lfZmluZF9leHRfY2FwYWJpbGl0eShwZGV2LT5zYmRmLA0KPj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUENJX0VYVF9DQVBfSURf
UkVCQVIpOw0KPj4gKw0KPj4gKyAgICBpZiAoICFyZWJhcl9vZmZzZXQgfHwgIWlzX2hhcmR3YXJl
X2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgQVNTRVJUX1VO
UkVBQ0hBQkxFKCk7DQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4g
KyAgICBjdHJsID0gcGNpX2NvbmZfcmVhZDMyKHBkZXYtPnNiZGYsIHJlYmFyX29mZnNldCArIFBD
SV9SRUJBUl9DVFJMKDApKTsNCj4+ICsgICAgbmJhcnMgPSBNQVNLX0VYVFIoY3RybCwgUENJX1JF
QkFSX0NUUkxfTkJBUl9NQVNLKTsNCj4+ICsNCj4+ICsgICAgcmMgPSB2cGNpX3JlbW92ZV9yZWdp
c3RlcnMocGRldi0+dnBjaSwgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NBUCgwKSwNCj4+ICsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUENJX1JFQkFSX0NUUkwobmJhcnMgLSAxKSk7
DQo+PiArICAgIGlmICggcmMgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9H
X0VSUiAiJXBkICVwcDogZmFpbCB0byByZW1vdmUgUmViYXIgaGFuZGxlcnMgcmM9JWRcbiIsDQo+
PiArICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2JkZiwgcmMpOw0KPj4gKyAg
ICAgICAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7DQo+PiArICAgICAgICByZXR1cm4gcmM7DQo+PiAr
ICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCAhaGlkZSApDQo+PiArICAgICAgICByZXR1cm4gMDsN
Cj4gDQo+IE5vdyB0aGF0IHRoZSBoYW5kbGVyIGNhbiBkaWZmZXJlbnRpYXRlIGJldHdlZW4gY2Fs
bHMgdG8gaGlkZSB0aGUNCj4gY2FwYWJpbGl0eSB2ZXJzdXMgY2FsbHMgZnJvbSBkZXZpY2UgZGVh
c3NpZ24sIGRvIHdlIG5lZWQgdG8gY2FsbA0KPiB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSBmb3Ig
dGhlIG5vbi1oaWRpbmcgY2FzZT8NCj4gDQo+IFRoZSBub24taGlkaW5nIGNhc2UgaXMgb25seSB1
c2VkIGZyb20gdnBjaV9kZWFzc2lnbl9kZXZpY2UoKSwgYW5kIGp1c3QNCj4gYWZ0ZXIgaGF2aW5n
IGNhbGxlZCBhbGwgdGhlIGNsZWFudXAgaG9va3MgdGhhdCBmdW5jdGlvbiBwdXJnZXMgYW55DQo+
IHJlbWFpbmluZyByZWdpc3RlcmVkIGhhbmRsZXJzLiAgSXQgd291bGQgYmUgT0sgdG8gZG8gc29t
ZXRoaW5nIGxpa2U6DQo+IA0KPiBzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfcmViYXIoY29u
c3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIGJvb2wgaGlkZSkNCj4gew0KPiAgICAgaW50IHJjOw0K
PiAgICAgdWludDMyX3QgY3RybDsNCj4gICAgIHVuc2lnbmVkIGludCBuYmFyczsNCj4gICAgIHVu
c2lnbmVkIGludCByZWJhcl9vZmZzZXQgPSBwY2lfZmluZF9leHRfY2FwYWJpbGl0eShwZGV2LT5z
YmRmLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFBDSV9FWFRfQ0FQX0lEX1JFQkFSKTsNCj4gDQo+ICAgICBpZiAoICFyZWJhcl9vZmZz
ZXQgfHwgIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4gICAgIHsNCj4gICAg
ICAgICBBU1NFUlRfVU5SRUFDSEFCTEUoKTsNCj4gICAgICAgICByZXR1cm4gMDsNCj4gICAgIH0N
Cj4gDQo+ICAgICBpZiAoICFoaWRlICkNCj4gICAgICAgICByZXR1cm4gMDsNCj4gDQo+ICAgICAu
Li4gcmVtb3ZlIGhhbmRsZXIgKyBtYXNrIHJlZ2lzdGVyIC4uLg0KPiANCj4gVGhvdWdodHM/DQpH
b3QgaXQuDQpCdXQgd2h5IG5vdCBtb3ZpbmcgaXQgYWJvdmUgdGhlIGZpcnN0IGNoZWNrICIgaWYg
KCAhcmViYXJfb2Zmc2V0IHx8ICFpc19oYXJkd2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSApIiA/
DQoNCj4gDQo+PiArDQo+PiArICAgIC8qDQo+PiArICAgICAqIFRoZSBkcml2ZXIgbWF5IG5vdCB0
cmF2ZXJzZSB0aGUgY2FwYWJpbGl0eSBsaXN0IGFuZCB0aGluayBkZXZpY2UNCj4+ICsgICAgICog
c3VwcG9ydHMgUmViYXIgYnkgZGVmYXVsdC4gU28gaGVyZSBsZXQgdGhlIGNvbnRyb2wgcmVnaXN0
ZXIgb2YgUmViYXINCj4+ICsgICAgICogYmUgUmVhZC1Pbmx5IGlzIHRvIGVuc3VyZSBSZWJhciBk
aXNhYmxlZC4NCj4+ICsgICAgICovDQo+PiArICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsg
aSA8IG5iYXJzOyBpKysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByYyA9IHZwY2lfYWRkX3Jl
Z2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDMyLCBOVUxMLA0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ1RSTChpKSwgNCwg
TlVMTCk7DQo+PiArICAgICAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICAgICAiJXBkICVwcDog
ZmFpbCB0byBhZGQgUmViYXIgY3RybCBoYW5kbGVyIHJjPSVkXG4iLA0KPj4gKyAgICAgICAgICAg
ICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLCByYyk7DQo+PiArICAgICAgICAgICAg
cmV0dXJuIHJjOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVy
biAwOw0KPj4gK30NCj4+ICsNCj4+ICBzdGF0aWMgaW50IGNmX2NoZWNrIGluaXRfcmViYXIoc3Ry
dWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgew0KPj4gICAgICB1aW50MzJfdCBjdHJsOw0KPj4gQEAg
LTgwLDcgKzEzMSw3IEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9yZWJhcihzdHJ1Y3QgcGNp
X2RldiAqcGRldikNCj4+ICAgICAgICAgIHsNCj4+ICAgICAgICAgICAgICBwcmludGsoWEVOTE9H
X0VSUiAiJXBkICVwcDogdG9vIGJpZyBCQVIgbnVtYmVyICV1IGluIFJFQkFSX0NUUkxcbiIsDQo+
PiAgICAgICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIGluZGV4KTsN
Cj4+IC0gICAgICAgICAgICBjb250aW51ZTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUUyQklH
Ow0KPj4gICAgICAgICAgfQ0KPj4gIA0KPj4gICAgICAgICAgYmFyID0gJnBkZXYtPnZwY2ktPmhl
YWRlci5iYXJzW2luZGV4XTsNCj4+IEBAIC04OCw3ICsxMzksNyBAQCBzdGF0aWMgaW50IGNmX2No
ZWNrIGluaXRfcmViYXIoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgICAgICAgICB7DQo+PiAg
ICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIiVwZCAlcHA6IEJBUiV1IGlzIG5vdCBpbiBt
ZW1vcnkgc3BhY2VcbiIsDQo+PiAgICAgICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBk
ZXYtPnNiZGYsIGluZGV4KTsNCj4+IC0gICAgICAgICAgICBjb250aW51ZTsNCj4+ICsgICAgICAg
ICAgICByZXR1cm4gLUVOWElPOw0KPiANCj4gSSdtIHVuc3VyZSB3ZSB3YW50IHRvIHJldHVybiBh
biBlcnJvciBoZXJlIGFuZCBpbiB0aGUgY2hlY2sgYWJvdmUsDQo+IGdpdmVuIHRoaXMgY2FwYWJp
bGl0eSBpcyBkb20wIG9ubHksIHdlIG1pZ2h0IHdhbnQgdG8ganVzdCBza2lwIHRoZSBCQVINCj4g
YW5kIGNvbnRpbnVlLCBhaW1pbmcgZm9yIHRoZSBvdGhlciByZXNpemFibGUgQkFScyB0byBiZSBm
dW5jdGlvbmFsPw0KV2h5IGhlcmUgbmVlZCB0byB1c2UgY29udGludWUsIGJ1dCBiZWxvdyB2cGNp
X2FkZF9yZWdpc3RlcigpIGZhaWwgcmV0dXJuIGVycm9yPw0KDQo+IA0KPiBUaGFua3MsIFJvZ2Vy
Lg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0KDQo=


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 09:47:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 09:47:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118043.1463964 (Exim 4.92)
	(envelope-from )
	id 1uwHPh-0006pm-VL; Wed, 10 Sep 2025 09:46:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118043.1463964; Wed, 10 Sep 2025 09: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 1uwHPh-0006pf-Sn; Wed, 10 Sep 2025 09:46:53 +0000
Received: by outflank-mailman (input) for mailman id 1118043;
 Wed, 10 Sep 2025 09: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 1uwHPg-0006pZ-K2
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 09:46:52 +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 1309778b-8e2b-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 11:46:50 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-627b85e4c0fso867733a12.1
 for ; Wed, 10 Sep 2025 02:46: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
 4fb4d7f45d1cf-62c01bdb952sm2968644a12.52.2025.09.10.02.46.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 02:46: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: 1309778b-8e2b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757497610; x=1758102410; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZgsRajd9sO0PsGqGTyI/+yzgRrq5KWbZfc5YAND8Kw4=;
        b=ds3R42XLVlEKpPUUTxrppXhc7pp8WF2ViJ2jX6QFeHVXygLaoSCNX2EpKcLy2RP/8a
         09gkNkbnf539cwiI50DcG1bMokBrJ0SmrDwDGcDNq24FJdPLl8DUxS2aToUQKWXMj/HA
         Don9KOvfMYfeEGLNJKw/ScOHuEFH1K4fI2joDH0y3ZdwksdJ28h9IqErAYQcWUcnyhEl
         xqb4INAcxCjyW/v8DnY96eATMSAFEYnHFhZP3M2mhVNIyrYuD5qmdFk8cwEJQ9bnyDbe
         P48N5cTW7/SkX0vhjU+R6pyG3v2I4xON02P1yDQOB5/ylwphqKP1Y74y0K8WLE83v5qX
         xb/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757497610; x=1758102410;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZgsRajd9sO0PsGqGTyI/+yzgRrq5KWbZfc5YAND8Kw4=;
        b=BbcWyVWjsba2DiU1wF/QhU+cAk8zbEwKzfClwcAObab0ajUcM03X4RNhg5jbCc/E7F
         A1Pm4M4CeBQ4HLvADGm49aVFeLafK9oHmD5mQrbQpM4NxGIr2ADUuaR5TGQluLlw251p
         iGZzHwppYBoRsjeSla8KY+BaRKaePLVwOsXQevwU1zkcTIK80InqcJeZ4dpWuPXVEjp5
         wQDoyABYrqvhrbxogunqMaTZm45aHYy1NkYWmzfk+Rt6HwOpLxN2gP/GS+cKuRae7gMa
         4X2XjqaRtm2ITOO0MAFKXbzeZu5tNNVr89ZqAHJGeeVWaO8s//jHWqESFAwJrJaSXbJN
         YGow==
X-Forwarded-Encrypted: i=1; AJvYcCWiTCPzxHNeS1FbYk9ji7JRf0u+28tggsIz7ONp8DmRqihcHxgYvByU2uTBGu1jtsbs36hVxYt2myo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2NKLEW4nIXc2woI/41f/zgfhSrSIU6nrUvsp7U50tNtOb49jr
	+ZfFIHP+ASJe/u5dp7L3f75YnU/I6XzmpfNY2LvbWa6jYIJhu1jHck0fJwirG2CQ4A==
X-Gm-Gg: ASbGncvpEUB7DAIBVUiaxr41/icG+Zri5pjA8UwQ3IV93uI8+ukQPv8F/+sJH3zXEJC
	GX6bECNQr4k5uonqEMdyvTPxh4OZ0dtNIKb6z3PDCgJ0kdbBJgxkz72cqwt0tJCXI71Qnh98KcB
	fwAuGyPGLkOHvhwNQN8UAGrRwk8wCmNZjEV1zfdrfH5LCZmJ+eAYuEcXw5rH0D1WA0u18qa4F9g
	dd0N72Q4i5ay/NDZFuLr5BfmztMAD4qw6bMTi9DMFvY8Wyh23/tiWCXsZkkzZHnZB2YtJPTn8UM
	UAkdQ22+9ASS/aka+RrOXbGEoYpn7wWGWnZZ0o/fHhzEtMJafR9Z28YXTh1y4nCQmt5MpBxmf0v
	yRiOl3OrUzJAs0+78qflngsW87uzsLxE2nY9Ht87VkQRwltGJBNYhPLKi7IOTzzp409n07FpdCW
	wfay11x1+B5skZEXLgIg==
X-Google-Smtp-Source: AGHT+IEyGb2I5+uWnwZVMyFKUx6TFqjo20D6YFPpJ1EfutV5Ji8OqhM7CXf9fjpFHMJy5Gs5z9k3Ew==
X-Received: by 2002:a05:6402:688:b0:626:15e3:fa with SMTP id 4fb4d7f45d1cf-62615e3029dmr9463454a12.13.1757497609751;
        Wed, 10 Sep 2025 02:46:49 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 11:46:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 0/8] amd-cppc CPU Performance Scaling Driver
To: "Penny, Zheng" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , Oleksii Kurochko ,
 Community Manager ,
 "xen-devel@lists.xenproject.org" 
References: <20250904063518.2097629-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 11:27, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, September 10, 2025 12:11 AM
>>
>> On 04.09.2025 08:35, Penny Zheng wrote:
>>> Penny Zheng (8):
>>>   xen/cpufreq: embed hwp into struct cpufreq_policy{}
>>>   xen/cpufreq: implement amd-cppc driver for CPPC in passive mode
>>>   xen/cpufreq: implement amd-cppc-epp driver for CPPC in active mode
>>>   xen/cpufreq: get performance policy from governor set via xenpm
>>>   tools/cpufreq: extract CPPC para from cpufreq para
>>>   xen/cpufreq: bypass governor-related para for amd-cppc-epp
>>>   xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-
>> cppc
>>>     driver
>>>   CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq driver support
>>>
>>>  CHANGELOG.md                         |   1 +
>>>  docs/misc/xen-command-line.pandoc    |   9 +-
>>>  tools/include/xenctrl.h              |   3 +-
>>>  tools/libs/ctrl/xc_pm.c              |  25 +-
>>>  tools/misc/xenpm.c                   |  94 ++--
>>>  xen/arch/x86/acpi/cpufreq/amd-cppc.c | 703 ++++++++++++++++++++++++++-
>>>  xen/arch/x86/acpi/cpufreq/hwp.c      |  32 +-
>>>  xen/arch/x86/cpu/amd.c               |   8 +-
>>>  xen/arch/x86/include/asm/amd.h       |   2 +
>>>  xen/arch/x86/include/asm/msr-index.h |   6 +
>>>  xen/drivers/acpi/pm-op.c             |  58 ++-
>>>  xen/drivers/cpufreq/utility.c        |  15 +
>>>  xen/include/acpi/cpufreq/cpufreq.h   |  44 ++
>>>  xen/include/public/sysctl.h          |   5 +-
>>>  14 files changed, 936 insertions(+), 69 deletions(-)
>>
>> As we're considering our options towards getting this work in, can you clarify two
>> things please:
>> (1) In v9, the sole changes were related to the use of per-CPU data and the
>>     adding of a ChangeLog entry?
> 
> Yes, also in commit of "xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC". I added description of "moving the copying of the governor name"

Oh, right, and that description is either too little or possibly unnecessary,
with a change made to "tools/cpufreq: extract CPPC para from cpufreq para"
(both as per my v9 comments). IOW v8 also isn't exactly what would want to go
in. All not a good basis for rushing this in at (later than) the last minute.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 09:57:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 09:57:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118062.1463975 (Exim 4.92)
	(envelope-from )
	id 1uwHaB-0008VB-TO; Wed, 10 Sep 2025 09:57:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118062.1463975; Wed, 10 Sep 2025 09:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwHaB-0008V4-QT; Wed, 10 Sep 2025 09:57:43 +0000
Received: by outflank-mailman (input) for mailman id 1118062;
 Wed, 10 Sep 2025 09:57:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwHa9-0008Us-Mo
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 09:57:41 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061d.outbound.protection.outlook.com
 [2a01:111:f403:200a::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9675f9f9-8e2c-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 11:57:40 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW4PR12MB7215.namprd12.prod.outlook.com (2603:10b6:303:228::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 09:57:36 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29%6]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 09:57:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9675f9f9-8e2c-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wSDwXXx8EFNulbQ5NtkOcbVFtAbY3bG1gn/5GEtcJcowoHQv9SCUNinjq5hAvtSr02PgnV7RzYbB9QAeq09uBp1+9U6hmkZ0puGUkULrDvVh5bWjVude3y54Xl6RhKjPRitM3paC3IqkSCZxGJPiS7bHmF4sk2nfJttDbIDvjdLJHPDUEFvEG00wwA0QCuU+HVZ8+D0qehCfmSjhN+Bp6kOQu16xE7uf+yP9IMen+uYglAU+0wnc+tUAowbdQAO/oE3gWVUZ05K6tzje1KrkTfTHk7kW9ibNB06qCW+S3CzI6sENAliRgw0+wqippMv3dawc/jf5AwyR8iMXPnJL3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ODQXCuXg461oInvTUHNS3WYAgmtmhKu6nv6eHeRPYLk=;
 b=Z9uWxxOxY3KKYAdCm300MRVq93qTiSPP3RlC0ypAnnOPhvjGv+MJK93Wj7AHeDnoQWNiY9G/dKRAMz1m3L/4RarsGNdsy9mo0oGhwGmMzlF0N59v6HutbSaDh1BmCiZ/OUc6vzxoU7kw00zj4HhrwPmucZoQZjMlXfqKVKQE2X774n+n7YkroIc+BD4MG6X2fvg+i/YU9uywU3zHgjd6yiLPetOYWdx16H/0jQiwFJMX3bf8IqCsRu7CSIxgDKRemb+ctafRd6s0xV//CoF9NGio+0N59zL/FRPHY3MjUFQdjIcdHr+ehYVB4SslndMaXRo4wQRr3NC9JFMDBOpEEQ==
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=ODQXCuXg461oInvTUHNS3WYAgmtmhKu6nv6eHeRPYLk=;
 b=S1yBEejKRORG2xJRSA9wGDyuvOgHype1h+XBJwcMfOJIIxfvxMSdIKpgjlnpwJRdVkRyAMXANKW2XwYDdGwrsNw82KlZeYUiHH6p/i9XljIMx517C6YPjmQEi6Rm2GqfX6bkm8iT0r4sGtM4GghBhow5Pxxrg0xv0T9Gw7awZck=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v11 4/5] vpci/msi: Implement cleanup function for MSI
Thread-Topic: [PATCH v11 4/5] vpci/msi: Implement cleanup function for MSI
Thread-Index: AQHcCDsBQje1Miq4QkCVUkMAlv2mX7R5kpQAgBNU3oA=
Date: Wed, 10 Sep 2025 09:57:36 +0000
Message-ID:
 
References: <20250808080337.28609-1-Jiqian.Chen@amd.com>
 <20250808080337.28609-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.9094.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_|MW4PR12MB7215:EE_
x-ms-office365-filtering-correlation-id: dbd0899e-0484-4d57-6999-08ddf050783a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?TDFFM0ZZcUFZM0Z4QWVSK05iVHI3aHNmc0J3V1JKaHRtSzJycjlibFArOXhl?=
 =?utf-8?B?ODVqUHNvSWNaZFJFQnNYNklzMEVFZDhGQmhhRUpwZjB4aUVkUDBSWks2YVZl?=
 =?utf-8?B?WVZyVGI3c3I4YnRZUHR1bklscWZMQ0F5Y3Bsa3pFc0ZzNkp5d2N2aWJKOEZ2?=
 =?utf-8?B?U21uS1RXQzQ4SmdBMWphT2ZQUStWQzl2NXl6U1BhVGZOSytSYkd4eVY2aUJ6?=
 =?utf-8?B?Wi9WbFR0bTI1eHlJajJtR0k5Yk1GdnZqREg4ZncxUG9OWlcxMEpyaG1uQVlT?=
 =?utf-8?B?VHltVS9XaWlHbkxBNUdub0ZjQmUxYnhUWnM0WVZSeG10YXdiZU1WM2RSaGor?=
 =?utf-8?B?QmRjellySFgybFlhWmk4UWlOZUtwbnFwbzVQMzVkakZaNXpmUGFFUVRjOGFs?=
 =?utf-8?B?eHZKNTZ2RmRGeEJYTGpLd0JrTWY0NzZ4eU45TjZuSFFvZXNPZmxRL2JwRGNa?=
 =?utf-8?B?ckZFQWgxTCtpczlyWjIycTNGK2NUSnRFUStXY3lzMWdGWDc1Q1JCUTJSb3E5?=
 =?utf-8?B?Y3VpY2ptRkg4VHRRcUhFVzQ4KzM2MzJyaGVJNWlXZEcrcXB6V0ZpOEFNd09K?=
 =?utf-8?B?K3lBMTFwK21qM2djNVd4bFZHUTEyZDhOMjgvYXNpT1BNcE81UU1JV0lZcksy?=
 =?utf-8?B?c3JObHg3Q1VINWVJcS9jZmMrUEYvY3M5eUowY1ZUb0NHWjN5dGxvc0tzbTF0?=
 =?utf-8?B?NDlMOXZMMFpMWjVxUytjYUhDZ1hBWDFvYWliZFB5eUxsN1dWMmQ1YWUwT3hB?=
 =?utf-8?B?S3hTZlRDUSs2cCtIbFR6SW4xTmJBeGJZUTFCbUJicGEzUUFDRDF0SGE1N0tB?=
 =?utf-8?B?VDk5OWc3UUN3M05DSWUzRjhHWHpTdHpUT2xwMlkyL3BuN0tOSGdnQjRyUlpG?=
 =?utf-8?B?dHU5bmR0aEpFYWlxWDBreEF4cEhjcXJjblJlYnFuUEs5bVlhdXhLb25TU2dy?=
 =?utf-8?B?eGRBVFVGOTF1aXdpSXRVU3RwcEFHaHFLVjdhR3N0aDVDV1JKa3RtVHZSSmJL?=
 =?utf-8?B?V3ZUQkhUUVNyV0RGWGJ1M0tZbFNaOWpYVTRmLzhYZW1rU1pleFczVk5FL0lm?=
 =?utf-8?B?Vy9aK0Qzc1NEYW1wVERrVDBpU1dmMCtYdjkrRFpVNlVUNlRlZzN6V3FFcXNj?=
 =?utf-8?B?bTR0V1B4SVNnV2Fac2RGaWJIWHR3VlF4R0UyTEhyaXpORmdUd2ZDMG9sZm1V?=
 =?utf-8?B?ODdST1A2MjI4M2dZZ1IydlhSWWl6Qk9tUDBiY1ROTU1SeVdHYm8yU1FJZTRI?=
 =?utf-8?B?cTNhcTY4RFFPNzBEcEw0ejI5Zk85MmZ2UVNSenNkRGdMYjAvUVJERzFqSm5U?=
 =?utf-8?B?ZU1SUEtqZzFySUlFUzRhSHQ2U2pqajhOOHhTL2oySG9xQXorTW4zaGc0VlpQ?=
 =?utf-8?B?SjZaelRONXFDMWk1cXpRb2dNelBFcmhGR0ZnOGpCaFROdk50bzR0UmpSU0wv?=
 =?utf-8?B?dHJ5dkk1MldINEFNV1RpaWhGRHkwR2hhWW9YYmJtVlE2NDltc3NPS1RFb1FV?=
 =?utf-8?B?ZXZJRlBtN0Jnd0V5eU1vcDRzUW1GbzNoSGF5cFc0S1cyZDduNklwTzJwd1R1?=
 =?utf-8?B?Zmo1cDV2RE1NOWhFbS85ZUJ5aEQ1WmdJK3ZnTWFwUjhlK29zTGVHRWxVanJm?=
 =?utf-8?B?elVWWG9Ib0QwcXZYazVrS015K011TkVWU2orTFBHOElrV2c5bGEvQnBjQ1Zi?=
 =?utf-8?B?RDhQZ2ZqOFJOYVpqZmN6YVdSS0RLNWo5MzdGRE5CZzVNZVRJZkI0OFVHbi9k?=
 =?utf-8?B?cWFRTEVlU2hkMkZQaFM0dnp0OU1OZlUzY08wQS9NNDg4czN1dzNNbUJYcEE1?=
 =?utf-8?B?SkdXaFdFaVlOeTJmMzAxZVlGWmtGNUtHL01jRjhXZEIvSW9yOXJTekVFeTJC?=
 =?utf-8?B?enZoRTloM1hpM3FQQXRNLzk1a00rcEs2RmxkeTh0eEFMUVd4U2djTjZmNkNl?=
 =?utf-8?B?UHZzd2oxcS9YNTFQRWV5bzdudTZ4d1A2T2IzdndwMi80N3R2dmg5RkJhbDN4?=
 =?utf-8?Q?2ZI48jX/Na+EW/wBVU89p68T+EdvdU=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WVhsblY4U0tDb1FtVnFCTVJLSWZLWHhSNzJxTSs0eW92YVJObkoxeUJ6eEYw?=
 =?utf-8?B?bW1jaGdlaTN2dU5DRlB2YzJVZkx3aVhJYjdwQ3pkOStDY20vQndTM2xxYlNB?=
 =?utf-8?B?UENoSUE3S1UzUzJDaFVyRGZLbklXci9iSFVmVm0ySTJiRUdUZWpHWGJRbzdQ?=
 =?utf-8?B?c3RyNVZCK0UzTUx6Y1gzRjRIblV6TDRkaTBiM2ZRMGlUTU5STlJrdWcyQk0y?=
 =?utf-8?B?a2VRZ2lVY1lTQ2tmUy9ZcS80c250eXg4YVIzV2tsOExNdjl1U3pLUGFKM010?=
 =?utf-8?B?WWhlNU4yMnlLTW5EVVhKcDJ1ME0wSFR4VkJzMktSaTN1WlcvVVpXMjVGcmtU?=
 =?utf-8?B?YkdyazZoUFVNT2h0V05XYmpzZkJTbVpQK2hPSGJpNUlzYURXMlNnZk4yMEUz?=
 =?utf-8?B?TnJFTy9ORWt0cEVDYk1zd0lGSU01RkRxU1prdjUvYlFxKzVjOE9YdkhncVQr?=
 =?utf-8?B?dGFSTEpDQ3RQZVF6Y0FUY2dKc0c2WmlmOFc1V1Z6bnUzc2pqZGtEKzA1TkFp?=
 =?utf-8?B?NVNBQmJMVVp5TjI4SVRNcnRlWklpbXhaWTliUGoyd1lzMTkweGpGVmxNVFFx?=
 =?utf-8?B?Sy9LSTMxaDY5OGdXSENNKzN6aVVTTS9tamRZUVRoRWNrVGRUQTRDdExBazhn?=
 =?utf-8?B?MVZNRnRrRmV5OFNtVytodE9acmZ0c3doVjJTcmRRajUxSjlrQ3U3dTVOV1dv?=
 =?utf-8?B?YW9kcEp4U05RVzkrTko5U0p2V1lWWEYwT1VDMWJtcjI5UTZ0VWhRb0k2RUZ2?=
 =?utf-8?B?dkpqUGhTbHFXN094Kzltam12YXlrWE5hOFJNemxPYVM1THg0NXk3OFNPaHMy?=
 =?utf-8?B?V2xKblhzUU1vUWVUckQwTFZwczc5MXpLU1VuWW5FVEtqSGl6TElOY0FhK1Uw?=
 =?utf-8?B?T1lMYVlQazAvUGFBbklibmkrVU5MUlFwU2pzckkxRXF4aXEwL3MzRE9SRGlm?=
 =?utf-8?B?VVR0Z3hsTmowbU1LSkdvZ2FCSkJ1R2M5V1Z1UmhMdFdXMXNQb3RQL2hJSnU0?=
 =?utf-8?B?UE1SZTZhRDBGekhhQkRzRXBjTUxTaHB1OHVoOGY5RXRTM3l6VzRLZEdaNi9u?=
 =?utf-8?B?ZC9ERmcySVI3cythNXpHYkZhRzAvM3FQUUtXejZsSmh1OHo0a0hDazMxejk3?=
 =?utf-8?B?Q0t4ZlRCN3IzaDhVeUpnUDhkbWFVcEdhM2w2eTFvL0RBUmFvU0xHWjZ5ekZr?=
 =?utf-8?B?R0xpUFQzODVNaHN5WHA3cjhFYmRuQXMxcDJiTVNuUW9HRGk0V1lXbGJtdVNL?=
 =?utf-8?B?bUZKVmNVbldXY2l1MHJFM05aUG51bXJXeTBCT21OS1Q0c1MrcjR0WFd0ZHQy?=
 =?utf-8?B?RGMzYTFaelZZMmVtT2twRVh4VndXby83Wlh5a2wwTnF2WEtNSkJzVFkwUlVp?=
 =?utf-8?B?NDFDb0xvaDhydDVoWHNWdGRnTlFZbWJCNktJWTlEUUF3TWpta2xSZkt5dm43?=
 =?utf-8?B?azdjcVhWNHVGY3l1V2dmeFljS2tWcXVodEZpeXp5MklSS1c2UzlBNlMrcTRr?=
 =?utf-8?B?Q2VLbzRJNmJzK3hmTE5OcVViWGdCZy93V3Fvd2xQRVA4bUdCWGRDMlV4emNQ?=
 =?utf-8?B?cjhzQUY3azgxN1lUeFFuNmNWYTBTS3FuS1FNai90aGFLRnBudmRHNkYvbXNT?=
 =?utf-8?B?ZXFCbHcvRkVkNjJZVU5RYmZMbmQyTUhHaHE2bVNBZlhLVlEzSHQvNHlrVVZy?=
 =?utf-8?B?S3J3ODBad2x4VmJjcDlTaGdmT2xDSnJ0VjE0RlhZWUZoM1QremlCSSsyQWc1?=
 =?utf-8?B?RWNMcUpWY05aMFh3WTZCcGVFMVdlRzRrODJIZk1JQ01CL0puS3BxZ29UWm5V?=
 =?utf-8?B?SzRBM1NZZm40ektOMjBXK21oelFXbkllZmRsTFpnU2NFMlBNMGhRa2ZKbjVT?=
 =?utf-8?B?R0tFcmNFNnMzdUErZmN1cm1UWHkzOTBoVG1aUVZPY3luQTZyMkhKMDZJL0Zv?=
 =?utf-8?B?elplS3gzVVkySVhNM2dRVU1LdXJiWDBVN1JyWG84SDI0SUovRUxlZmgxa2xS?=
 =?utf-8?B?MFN5Qzl2VzdPWXZKQXFFY2VLaUtSNWg0b2Roa2s1TFlzQU52WUMxYzdEOXpI?=
 =?utf-8?B?STRleUFEVWp0Z2NZQ3c2cWNjd1l3WTQyWU9HK1pON1VqdzBTL3J4SUxNNmcy?=
 =?utf-8?Q?4za0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <91C6D0246BF4924FB8608340EB64AB12@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: dbd0899e-0484-4d57-6999-08ddf050783a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2025 09:57:36.1578
 (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: bAKlfk4Df/Zhy+cVzqG/CZrebMeMtSxbHNjFXB1rgACYTCRsBa1EMdUXN0rmhm8coJUY9VKfTRZQEh3an2loxg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7215

T24gMjAyNS84LzI5IDE4OjQxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBGcmksIEF1
ZyAwOCwgMjAyNSBhdCAwNDowMzozNlBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IFdo
ZW4gTVNJIGluaXRpYWxpemF0aW9uIGZhaWxzLCB2UENJIGhpZGVzIHRoZSBjYXBhYmlsaXR5LCBi
dXQNCj4+IHJlbW92aW5nIGhhbmRsZXJzIGFuZCBkYXRhcyB3b24ndCBiZSBwZXJmb3JtZWQgdW50
aWwgdGhlIGRldmljZSBpcw0KPj4gZGVhc3NpZ25lZC4gU28sIGltcGxlbWVudCBNU0kgY2xlYW51
cCBob29rIHRoYXQgd2lsbCBiZSBjYWxsZWQgdG8NCj4+IGNsZWFudXAgTVNJIHJlbGF0ZWQgaGFu
ZGxlcnMgYW5kIGZyZWUgaXQncyBhc3NvY2lhdGVkIGRhdGEgd2hlbg0KPj4gaW5pdGlhbGl6YXRp
b24gZmFpbHMuDQo+Pg0KPj4gU2luY2UgY2xlYW51cCBmdW5jdGlvbiBvZiBNU0kgaXMgaW1wbGVt
ZW50ZWQsIGRlbGV0ZSB0aGUgb3Blbi1jb2RlDQo+PiBpbiB2cGNpX2RlYXNzaWduX2RldmljZSgp
Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29t
Pg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0cml4LmNv
bT4NCj4+IC0tLQ0KPj4gdjEwLT52MTEgY2hhbmdlczoNCj4+ICogQWRkIGhpZGUgcGFyYXRlbWVy
IHRvIGNsZWFudXBfbXNpKCkuDQo+PiAqIENoZWNrIGhpZGUsIGlmIGZhbHNlIHJldHVybiBkaXJl
Y3RseSBpbnN0ZWFkIG9mIGxldHRpbmcgY3RybCBSTy4NCj4+ICogRGVsZXRlIHhmcmVlKHBkZXYt
PnZwY2ktPm1zaSk7IGluIHZwY2lfZGVhc3NpZ25fZGV2aWNlKCkuDQo+PiAqIFJlbW92ZSBSb2dl
cidzIFJldmlld2VkLWJ5IHNpbmNlIHBhdGNoIGNoYW5nZS4NCj4+DQo+PiB2OS0+djEwIGNoYW5n
ZXM6DQo+PiBOby4NCj4+DQo+PiB2OC0+djkgY2hhbmdlczoNCj4+ICogQWRkIFJvZ2VyJ3MgUmV2
aWV3ZWQtYnkuDQo+Pg0KPj4gdjctPnY4IGNoYW5nZXM6DQo+PiAqIEFkZCBhIGNvbW1lbnQgdG8g
ZGVzY3JpYmUgd2h5ICItMiIgaW4gY2xlYW51cF9tc2koKS4NCj4+ICogR2l2ZW4gdGhlIGNvZGUg
aW4gdnBjaV9yZW1vdmVfcmVnaXN0ZXJzKCkgYW4gZXJyb3IgaW4gdGhlIHJlbW92YWwgb2YNCj4+
ICAgcmVnaXN0ZXJzIHdvdWxkIGxpa2VseSBpbXBseSBtZW1vcnkgY29ycnVwdGlvbiwgYXQgd2hp
Y2ggcG9pbnQgaXQncw0KPj4gICBiZXN0IHRvIGZ1bGx5IGRpc2FibGUgdGhlIGRldmljZS4gU28s
IFJvbGxiYWNrIHRoZSBsYXN0IHR3byBtb2RpZmljYXRpb25zIG9mIHY3Lg0KPj4NCj4+IHY2LT52
NyBjaGFuZ2VzOg0KPj4gKiBDaGFuZ2UgdGhlIHBvaW50ZXIgcGFyYW1ldGVyIG9mIGNsZWFudXBf
bXNpKCkgdG8gYmUgY29uc3QuDQo+PiAqIFdoZW4gdnBjaV9yZW1vdmVfcmVnaXN0ZXJzKCkgaW4g
Y2xlYW51cF9tc2koKSBmYWlscywgbm90IHRvIHJldHVybg0KPj4gICBkaXJlY3RseSwgaW5zdGVh
ZCB0cnkgdG8gZnJlZSBtc2kgYW5kIHJlLWFkZCBjdHJsIGhhbmRsZXIuDQo+PiAqIFBhc3MgcGRl
di0+dnBjaSBpbnRvIHZwY2lfYWRkX3JlZ2lzdGVyKCkgaW5zdGVhZCBvZiBwZGV2LT52cGNpLT5t
c2kgaW4NCj4+ICAgaW5pdF9tc2koKSBzaW5jZSB3ZSBuZWVkIHRoYXQgZXZlcnkgaGFuZGxlciBy
ZWFsaXplIHRoYXQgbXNpIGlzIE5VTEwNCj4+ICAgd2hlbiBtc2kgaXMgZnJlZSBidXQgaGFuZGxl
cnMgYXJlIHN0aWxsIGluIHRoZXJlLg0KPj4NCj4+IHY1LT52NiBjaGFuZ2VzOg0KPj4gTm8uDQo+
Pg0KPj4gdjQtPnY1IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBkZWZpbml0aW9uICJzdGF0aWMgdm9p
ZCBjbGVhbnVwX21zaSIgdG8gInN0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2kiDQo+PiAg
IHNpbmNlIGNsZWFudXAgaG9vayBpcyBjaGFuZ2VkIHRvIGJlIGludC4NCj4+ICogQWRkIGEgcmVh
ZC1vbmx5IHJlZ2lzdGVyIGZvciBNU0kgQ29udHJvbCBSZWdpc3RlciBpbiB0aGUgZW5kIG9mIGNs
ZWFudXBfbXNpLg0KPj4NCj4+IHYzLT52NCBjaGFuZ2VzOg0KPj4gKiBDaGFuZ2UgZnVuY3Rpb24g
bmFtZSBmcm9tIGZpbmlfbXNpKCkgdG8gY2xlYW51cF9tc2koKS4NCj4+ICogUmVtb3ZlIHVubmVj
ZXNzYXJ5IGNvbW1lbnQuDQo+PiAqIENoYW5nZSB0byB1c2UgWEZSRUUgdG8gZnJlZSB2cGNpLT5t
c2kuDQo+Pg0KPj4gdjItPnYzIGNoYW5nZXM6DQo+PiAqIFJlbW92ZSBhbGwgZmFpbCBwYXRoLCBh
bmQgdXNlIGZpbmlfbXNpKCkgaG9vayBpbnN0ZWFkLg0KPj4gKiBDaGFuZ2UgdGhlIG1ldGhvZCB0
byBjYWxjdWxhdGluZyB0aGUgc2l6ZSBvZiBtc2kgcmVnaXN0ZXJzLg0KPj4NCj4+IHYxLT52MiBj
aGFuZ2VzOg0KPj4gKiBBZGRlZCBhIG5ldyBmdW5jdGlvbiBmaW5pX21zaSB0byBmcmVlIGFsbCBN
U0kgcmVzb3VyY2VzIGluc3RlYWQgb2YgdXNpbmcgYW4gYXJyYXkNCj4+ICAgdG8gcmVjb3JkIHJl
Z2lzdGVyZWQgcmVnaXN0ZXJzLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IEppcWlhbiBDaGVu
Lg0KPj4gLS0tDQo+PiAgeGVuL2RyaXZlcnMvdnBjaS9tc2kuYyAgfCA0OSArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5j
IHwgIDEgLQ0KPj4gIDIgZmlsZXMgY2hhbmdlZCwgNDggaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlv
bnMoLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS9tc2kuYyBiL3hlbi9k
cml2ZXJzL3ZwY2kvbXNpLmMNCj4+IGluZGV4IGMzZWJhNGUxNDg3MC4uNmFiNDViOWJhNjU1IDEw
MDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9tc2kuYw0KPj4gKysrIGIveGVuL2RyaXZl
cnMvdnBjaS9tc2kuYw0KPj4gQEAgLTE5Myw2ICsxOTMsNTMgQEAgc3RhdGljIHZvaWQgY2ZfY2hl
Y2sgbWFza193cml0ZSgNCj4+ICAgICAgbXNpLT5tYXNrID0gdmFsOw0KPj4gIH0NCj4+ICANCj4+
ICtzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfbXNpKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpw
ZGV2LCBib29sIGhpZGUpDQo+PiArew0KPj4gKyAgICBpbnQgcmM7DQo+PiArICAgIHVuc2lnbmVk
IGludCBlbmQ7DQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBjaTsNCj4+ICsg
ICAgY29uc3QgdW5zaWduZWQgaW50IG1zaV9wb3MgPSBwZGV2LT5tc2lfcG9zOw0KPj4gKyAgICBj
b25zdCB1bnNpZ25lZCBpbnQgY3RybCA9IG1zaV9jb250cm9sX3JlZyhtc2lfcG9zKTsNCj4+ICsN
Cj4+ICsgICAgaWYgKCAhbXNpX3BvcyB8fCAhdnBjaS0+bXNpICkNCj4+ICsgICAgICAgIHJldHVy
biAwOw0KPiANCj4gSSdtIGFmcmFpZCB0aGUgYWJvdmUgaXMgbm90IGNvcnJlY3QsIGV2ZW4gaWYg
dnBjaS0+bXNpID09IE5VTEwgd2UNCj4gc3RpbGwgd2FudCB0byBoaWRlIHRoZSBjYXBhYmlsaXR5
IHdoZW4gcmVxdWVzdGVkIHRvIGRvIHNvLCB0aGF0IHdvdWxkDQo+IGJlIHRoZSBjYXNlIGlmIHRo
ZSBtZW1vcnkgYWxsb2Mgb2YgdnBjaS0+bXNpIGZhaWxzIGluIGluaXRfbXNpKCkuDQo+IA0KPiBU
aGlzIHNob3VsZCBiZToNCj4gDQo+IGlmICggIW1zaV9wb3MgKQ0KPiB7DQo+ICAgICBBU1NFUlRf
VU5SRUFDSEFCTEUoKTsNCj4gICAgIHJldHVybiAwOw0KPiB9DQo+IA0KPiBpZiAoICFoaWRlICkN
Cj4gew0KPiAgICAgWEZSRUUodnBjaS0+bXNpKTsNCj4gICAgIHJldHVybiAwOw0KPiB9DQpXaWxs
IGNoYW5nZS4NCg0KPiANCj4gDQo+IA0KPj4gKw0KPj4gKyAgICBpZiAoIHZwY2ktPm1zaS0+bWFz
a2luZyApDQo+IA0KPiBZb3UgY2Fubm90IGFzc3VtZSB0aGF0IG1hc2tpbmcgaGFzIGJlZW4gY29y
cmVjdGx5IHNldCwgZGVwZW5kaW5nIG9uDQo+IHdoZXJlIGluaXRfbXNpKCkgZmFpbHMgbWFza2lu
ZyB3aWxsIGJlIHVuaW5pdGlhbGl6ZWQsIHNhbWUgd2l0aA0KPiBhZGRyZXNzNjQuDQo+IA0KPiBJ
IHRoaW5rIHRoZSBsb2dpYyB3b3VsZCBzdGlsbCBiZSBjb3JyZWN0LCBiZWNhdXNlIGlmIC0+bWFz
a2luZyBhbmQNCj4gLT5hZGRyZXNzNjQgaXMgbm90IGluaXRpYWxpemVkIHRoZSByZWdpc3RlciBo
YW5kbGVycyB3b24ndCBiZSBzZXR1cA0KPiBlaXRoZXIsIGJ1dCBmZWVscyBmcmFnaWxlLiAgSWRl
YWxseSBjbGVhbnVwX21zaSgpIHNob3VsZG4ndCB1c2UgdGhlDQo+IGNvbnRlbnRzIG9mIHZwY2kt
Pm1zaSwgYmVjYXVzZSB0aGV5IGFyZSBsaWtlbHkgbm90IHByb3Blcmx5DQo+IGluaXRpYWxpemVk
Lg0KV291bGQgaXQgYmV0dGVyIHRvIGNoYW5nZSB0byBnZXQgbWFzayBhbmQgYWRkcmVzczY0IGlu
Zm8gZnJvbSBoYXJkd2FyZSBjdHJsIHJlZ2lzdGVyIG9mIG1zaSB3aGVuIHZwY2ktPm1zaSBpcyBu
b3QgTlVMTD8NCg0KPiANCj4gVGhhbmtzLCBSb2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpK
aXFpYW4gQ2hlbi4NCg0K


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 10:05:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 10:05:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118078.1463984 (Exim 4.92)
	(envelope-from )
	id 1uwHhj-00021P-PM; Wed, 10 Sep 2025 10:05:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118078.1463984; Wed, 10 Sep 2025 10:05: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 1uwHhj-00021I-MY; Wed, 10 Sep 2025 10:05:31 +0000
Received: by outflank-mailman (input) for mailman id 1118078;
 Wed, 10 Sep 2025 10:05: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 1uwHhi-00021C-Sy
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 10:05:31 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abe197ae-8e2d-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 12:05:25 +0200 (CEST)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-336b071e806so57123071fa.1
 for ; Wed, 10 Sep 2025 03:05: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: abe197ae-8e2d-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757498725; x=1758103525; 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=1Ae6yELyAiaiQcy/M4n7BOZ1Mq2mK/qjGs5PtjknVF0=;
        b=LrfDICzuAp8x77l75Z9yR4DJ14ZtrMSYV7nHUabreFbHY/rLmtyki4mRutld07agnc
         Oj2FrUS96Kx43zOcU/pLoAMzYvGnoGwoJG9QW7vtnXdd45Rtpko8n62A8w606G/c/C6U
         dinDiOxwHVjp60BRjOYnwdaQMvZoQTvyZwjfzL5eTWrI1cR8EyqAM5W1K5dGitkQhtLW
         js81/W5hgjQoxDi8CVwJLeXc/LsALhUnAzGTnQ3YCMIfk6BlW6wib25KAXTquRE7eJbn
         10V0oIZ9VZ2/0rCaPJ1R7ERSjHwzZdXLlIAn21ThJS1IE+Goo/t5wa0ekoXxu9SMQHCd
         TX9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757498725; x=1758103525;
        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=1Ae6yELyAiaiQcy/M4n7BOZ1Mq2mK/qjGs5PtjknVF0=;
        b=cH9gEhp6vnPPrUEnmfN985fnZfLTiSv5irsdI/UUAJWcOAZMknRZhfCM/tniUaQZgV
         0l9Dd6xd4SoVzQIpMzfSJ4ZzlpYlL9F153Fmcn6PqOuQ8+/Wzwr4+/r22VO5OzOWVGm3
         PY4DaJ6GAMwEnIkyUJ88fu36wbJdCyU/qg2ZlyvJ+6AbXnXWfV0EWWEYEaPaeDuhbq9s
         IHtH2VzHV2OiXSahC5dImIbZuPMfqvIEpjZyFtHfJxzUgJ76C+e5abQSVgucQn/3TCEk
         kAVO9jyrbuk7s5CH5zFCdagovZDibN0yuqIzm5QVDp5NWkhrT3JxLSEJS2VM9eS2AHuA
         fxlg==
X-Gm-Message-State: AOJu0Yx2IwEekJ4ft+lSZtFTl/WEaDwioEhbNIM1bkvQ1B0tJn8zzBQi
	SyJa5uVokmCUY5ydSIY8diAW2aT3QS1MxW5x1aygordzotPTAwWZUU7nnlOVEACIpRuvtmkdtgc
	+2r7H/hBWD8DJY+YcU4l0bFgKrNV4f1I=
X-Gm-Gg: ASbGnctHqFLzbyK8y0wgQ8TiYCdH32R4nCrZWagbJ7Bd8EmA9KhgcX6rDFgioReYVlF
	U1O+1SJZnxX/fUF6T9RvityWD8Ucfqgf5Wm5jL75yK0okHGSK4HOV+2KlDpmgfDJ22DxtG6/7Ew
	hdTgkm4WHCZ1bykdqnxGSf7BU3GvjeHdOu7yyl+mNLfm27nsXsvoLqDXZQJyLFoikl1lvfXeTD4
	4Pr9ZWxFTwXCrH38uaa7d4bu4I=
X-Google-Smtp-Source: AGHT+IF+PVptV4kBNDGaVLqK8cp5UnyvwUFFM7IS6KoakIz1n9tqNEFmpPoteUMhpasyyh01gwwCKPPl3PIv5wozMqI=
X-Received: by 2002:a2e:a607:0:b0:332:5fc0:24ae with SMTP id
 38308e7fff4ca-33b5108cecbmr27131931fa.15.1757498724677; Wed, 10 Sep 2025
 03:05:24 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-4-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-4-dmukhin@ford.com>
From: Mykola Kvach 
Date: Wed, 10 Sep 2025 13:05:13 +0300
X-Gm-Features: Ac12FXyjZQaI2TOE5OvdS1c8GkFIZIfdTOIu9-0_REswpiAgbe-uP1oGUkguObA
Message-ID: 
Subject: Re: [PATCH v7 03/16] emul/ns16x50: implement emulator stub
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

I appreciate you addressing the comments from the earlier version
of the patch series.

On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> The change is the first on the way on introducing minimally functional
> NS16550-compatible UART emulator.
>
> Only one domain, defined via 'vuart=3D' parameter, will have UART emulato=
r
> initially. The command line option is not documented yet because of the p=
lan
> to adjust this code for vUART configuration via xl.

Since the command line option is not yet documented, it would be
helpful to include the expected format of the 'vuart=3D' parameter in
the commit message. This will make it easier for reviewers and future
readers to understand how to use the option.

>
> Define UART state and a set of emulated registers.
>
> Implement alloc/free vUART hooks.
>
> Stub out I/O port handler.
>
> Add initialization of the NS16x50-compatible UART emulator state machine.
>
> Plumb debug logging.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - feedback from Mykola
> - added temporary 'vuart=3D' run-time option to enable emulator for certa=
in
>   domain for ease of testing
> ---
>  xen/arch/x86/hvm/hvm.c          |  75 +++++++
>  xen/common/emul/vuart/Makefile  |   1 +
>  xen/common/emul/vuart/ns16x50.c | 364 ++++++++++++++++++++++++++++++++
>  3 files changed, 440 insertions(+)
>  create mode 100644 xen/common/emul/vuart/ns16x50.c
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 23bd7f078a1d..363c010f8dcc 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -107,6 +108,67 @@ static const char __initconst warning_hvm_fep[] =3D
>  static bool __initdata opt_altp2m_enabled;
>  boolean_param("altp2m", opt_altp2m_enabled);
>
> +/* Enable NS16550 emulator for certain domain only. */
> +static int __read_mostly opt_vuart_domid =3D -1;

Should opt_vuart_domid be initialized to DOMID_INVALID instead of -1?
Using the standard DOMID_INVALID constant would make the intent clearer
and avoid potential confusion with valid domain IDs.
---
Should the variable type be domid_t or at least unsigned?

> +
> +#ifdef CONFIG_VUART_NS16X50
> +static int __read_mostly opt_vuart_id;
> +static int __init cf_check parse_vuart_param(const char *s)
> +{
> +    if ( !isdigit(*s) )
> +        return -EINVAL;
> +
> +    opt_vuart_domid =3D simple_strtoul(s, &s, 0);

Should we check the resulting value against DOMID_MASK to ensure it
is a valid domain ID?

> +
> +    if ( *s !=3D ':' )
> +        return 0;

It seems that if the COM ID is not provided on the command line, the
default value will come from the static variable, which is 0 (treated
as COM1). Is this intended behavior?

If this is by design, it would be helpful to add a comment explaining
why we allow a valid domain ID with a default COM ID. Otherwise, maybe
opt_vuart_id should be set to an invalid value or opt_vuart_domid
reset here to avoid ambiguity.

> +
> +    if ( strncmp(s, "com", 3) )
> +        return -EINVAL;
> +
> +    opt_vuart_id =3D *(s + 3) - '1';
> +    if ( opt_vuart_id < 0 || opt_vuart_id > 3 )

Would it be better to define the pc_uarts array outside the function
and then use ARRAY_SIZE(pc_uarts) here for the bounds check? This
would make the code more maintainable in case the number of UARTs
changes in the future.
---
Do we really need the search function below at all? Instead of
storing an opt_vuart_id, we could store a pointer to the chosen
vUART directly here and eliminate the search, simplifying the code.

> +        return -EINVAL;
> +
> +    return 0;
> +}
> +custom_param("vuart", parse_vuart_param);
> +
> +static const struct vuart_info *get_vuart_info(struct domain *d)
> +{
> +#define PC_UART(n,p,i) { \
> +    .name =3D n, \
> +    .compatible =3D "ns16550", \
> +    .base_addr =3D p, \
> +    .size =3D 8, \
> +    .irq =3D i, \
> +}
> +    static const struct vuart_info pc_uarts[4] =3D
> +    {
> +        PC_UART("com1", 0x3f8, 4),
> +        PC_UART("com2", 0x2f8, 3),
> +        PC_UART("com3", 0x3fe, 4),
> +        PC_UART("com4", 0x2fe, 3),
> +    };
> +    unsigned i;
> +
> +    for ( i =3D 0; i < ARRAY_SIZE(pc_uarts); i++ )
> +        if ( i =3D=3D opt_vuart_id )
> +            break;

Instead of breaking from the loop, why not return the pointer directly
when a match is found? For example:

for ( i =3D 0; i < ARRAY_SIZE(pc_uarts); i++ )
    if ( i =3D=3D opt_vuart_id )
        return &pc_uarts[i];

return NULL;

This eliminates the need for a separate break and makes the code
clearer.
---

Actually, we can simplify this further: since the array is indexed by
opt_vuart_id, we can directly check the bounds and return the entry:

if ( opt_vuart_id > -1 && opt_vuart_id < ARRAY_SIZE(pc_uarts) )
    return &pc_uarts[opt_vuart_id];

return NULL;

If opt_vuart_id were defined as unsigned, the lower-bound check could be
dropped entirely, leaving only the upper-bound check, which would make
the code even cleaner.

> +
> +    if ( i !=3D ARRAY_SIZE(pc_uarts) )
> +        return &pc_uarts[i];
> +
> +    return NULL;
> +#undef PC_UART
> +}
> +#else
> +static const struct vuart_info *get_vuart_info(struct domain *d)

inline ?

> +{
> +    return NULL;
> +}
> +#endif /* CONFIG_VUART_NS16X50 */

Should all of the code above be made common? If in the future other
architectures also use this vUART mechanism, it would be better to
make it generic from the start. In that case, vuart_info would
probably need a "compatible" property to support different hardware
types.

Then the search procedure through the vuart array would make
much more sense.

> +
>  static int cf_check cpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -689,6 +751,15 @@ int hvm_domain_initialise(struct domain *d,
>      if ( rc !=3D 0 )
>          goto fail1;
>
> +    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && d->domain_id =3D=3D opt_vua=
rt_domid )
> +    {
> +        const struct vuart_info *info =3D get_vuart_info(d);
> +
> +        rc =3D vuart_init(d, info);
> +        if ( rc )
> +            goto out_vioapic_deinit;
> +    }
> +
>      stdvga_init(d);
>
>      rtc_init(d);
> @@ -712,6 +783,8 @@ int hvm_domain_initialise(struct domain *d,
>      return 0;
>
>   fail2:
> +    vuart_deinit(d);
> + out_vioapic_deinit:
>      vioapic_deinit(d);
>   fail1:
>      if ( is_hardware_domain(d) )
> @@ -774,6 +847,8 @@ void hvm_domain_destroy(struct domain *d)
>      if ( hvm_funcs.domain_destroy )
>          alternative_vcall(hvm_funcs.domain_destroy, d);
>
> +    vuart_deinit(d);
> +
>      vioapic_deinit(d);
>
>      XFREE(d->arch.hvm.pl_time);
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> index 97f792dc6641..fe904f6cb65d 100644
> --- a/xen/common/emul/vuart/Makefile
> +++ b/xen/common/emul/vuart/Makefile
> @@ -1 +1,2 @@
>  obj-y +=3D vuart.o
> +obj-$(CONFIG_VUART_NS16X50) +=3D ns16x50.o
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> new file mode 100644
> index 000000000000..a3bdf9f415ca
> --- /dev/null
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -0,0 +1,364 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS16550-compatible UART Emulator.
> + *
> + * See:
> + * - Serial and UART Tutorial:
> + *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-u=
art_en.pdf
> + * - UART w/ 16 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> + * - UART w/ 64 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
> + *
> + * Limitations:
> + * - Only x86;
> + * - Only Xen console as a backend, no inter-domain communication (simil=
ar to
> + *   vpl011 on Arm);
> + * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
> + * - No baud rate emulation (reports 115200 baud to the guest OS);
> + * - No FIFO-less mode emulation;
> + * - No RX FIFO interrupt moderation (FCR) emulation;
> + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> + *   friends);
> + * - No ISA IRQ sharing allowed;
> + * - No MMIO-based UART emulation.
> + */
> +
> +#define pr_prefix               "ns16x50"
> +#define pr_fmt(fmt)             pr_prefix ": " fmt
> +
> +#ifdef CONFIG_VUART_NS16X50_DEBUG
> +#define guest_prefix            "FROM GUEST "
> +#define ns16x50_log_level       2
> +#else
> +#define guest_prefix            ""
> +#define ns16x50_log_level       0
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define ns16x50_log(n, lvl, vdev, fmt, args...) \
> +do { \
> +    if ( ns16x50_log_level >=3D n ) \
> +        gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \
> +} while (0)
> +
> +#define ns16x50_err(vdev, fmt, args...) \
> +    ns16x50_log(0, XENLOG_ERR, vdev, fmt, ## args)
> +#define ns16x50_warn(vdev, fmt, args...) \
> +    ns16x50_log(1, XENLOG_WARNING, vdev, fmt, ## args)
> +#define ns16x50_info(vdev, fmt, args...) \
> +    ns16x50_log(2, XENLOG_INFO, vdev, fmt, ## args)
> +#define ns16x50_debug(vdev, fmt, args...) \
> +    ns16x50_log(3, XENLOG_DEBUG, vdev, fmt, ## args)
> +
> +/*
> + * Number of supported registers in the UART.
> + */
> +#define NS16X50_REGS_NUM        (UART_SCR + 1)
> +
> +/*
> + * Number of emulated registers.
> + *
> + * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=
=3D0.
> + * - DLAB=3D1, R/W, DLL         =3D (NS16X50_REGS_NUM + 0)
> + * - DLAB=3D1, R/W, DLM         =3D (NS16X50_REGS_NUM + 1)
> + */
> +#define NS16X50_EMU_REGS_NUM    (NS16X50_REGS_NUM + 2)
> +
> +/*
> + * Virtual ns16x50 device state.
> + */
> +struct vuart_ns16x50 {
> +    uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */
> +    const struct vuart_info *info;      /* UART description */
> +    struct domain *owner;               /* Owner domain */
> +    const char *name;                   /* Device name */
> +    spinlock_t lock;                    /* Protection */
> +    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
> +};
> +
> +static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> +{
> +    return 0;
> +}
> +
> +/*
> + * Emulate 8-bit write access to ns16x50 register.
> + */
> +static int ns16x50_io_write8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    int rc =3D 0;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit write access to ns16x50 register.
> + * NB: some guest OSes use outw() to access UART_DLL.
> + */
> +static int ns16x50_io_write16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    int rc =3D -EINVAL;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate write access to ns16x50 register.
> + */
> +static int ns16x50_io_write(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_write8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_write16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 8-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    uint8_t val =3D UINT8_MAX;
> +    int rc =3D 0;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    uint16_t val =3D UINT16_MAX;
> +    int rc =3D -EINVAL;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate read access to ns16x50 register.
> + */
> +static int ns16x50_io_read(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_read8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_read16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        *data =3D UINT32_MAX;
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate I/O access to ns16x50 register.
> + * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is en=
abled.
> + */
> +static int cf_check ns16x50_io_handle(
> +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> +{
> +    const char op =3D (dir =3D=3D IOREQ_WRITE) ? 'W' : 'R';
> +    struct domain *d =3D rcu_lock_current_domain();
> +    struct vuart *vuart =3D vuart_find_by_io_range(d, addr, size);
> +    struct vuart_ns16x50 *vdev;
> +    const struct domain *owner;
> +    const struct vuart_info *info;
> +    uint32_t reg;
> +    unsigned dlab;
> +    int rc;
> +
> +    if ( !vuart )
> +    {
> +        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
> +               op, addr, size);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +
> +    vdev =3D vuart->vdev;
> +    ASSERT(vdev);
> +
> +    owner =3D vuart->owner;
> +    ASSERT(owner);
> +
> +    if ( d !=3D owner )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domai=
n %pv\n",
> +                    op, addr, size, d);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +
> +    info =3D vuart->info;
> +    ASSERT(info);
> +
> +    reg =3D addr - info->base_addr;
> +    if ( !IS_ALIGNED(reg, size) )
> +    {
> +        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
> +                    op, addr, size);
> +        goto out;
> +    }
> +
> +    dlab =3D ns16x50_dlab_get(vdev);
> +    if ( reg >=3D NS16X50_REGS_NUM )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"=
PRIx32": not implemented\n",
> +                    op, addr, size, dlab, reg, *data);
> +        goto out;
> +    }
> +
> +    spin_lock(&vdev->lock);
> +
> +    if ( dir =3D=3D IOREQ_WRITE )
> +        rc =3D ns16x50_io_write(vdev, reg, size, data);
> +    else
> +        rc =3D ns16x50_io_read(vdev, reg, size, data);
> +
> +    spin_unlock(&vdev->lock);
> +
> +    if ( rc =3D=3D 0 )
> +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"P=
RIx32"\n",
> +                      op, addr, size, dlab, reg, *data);
> +    else
> +        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"PRI=
x32": unsupported access\n",
> +                    op, addr, size, dlab, reg, *data);
> +
> +out:
> +    rcu_unlock_domain(d);
> +
> +    return X86EMUL_OKAY;
> +}
> +
> +static int ns16x50_init(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +    const struct vuart_info *info =3D vdev->info;
> +    struct domain *d =3D vdev->owner;
> +
> +    ASSERT(vdev);
> +
> +    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
> +
> +    return 0;
> +}
> +
> +static void cf_check ns16x50_deinit(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +
> +    ASSERT(vdev);
> +}
> +
> +static void * cf_check ns16x50_alloc(struct domain *d, const struct vuar=
t_info *info)
> +{
> +    struct vuart_ns16x50 *vdev;
> +    int rc;
> +
> +    if ( !is_hvm_domain(d) )
> +    {
> +        ns16x50_err(info, "not an HVM domain\n");
> +        return ERR_PTR(-ENOSYS);
> +    }
> +
> +    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
> +    {
> +        ns16x50_err(info, "already registered\n");
> +        return ERR_PTR(-EBUSY);
> +    }
> +
> +    vdev =3D xvzalloc(typeof(*vdev));
> +    if ( !vdev )
> +    {
> +        ns16x50_err(info, "failed to allocate memory\n");
> +        return ERR_PTR(-ENOMEM);
> +    }
> +
> +    spin_lock_init(&vdev->lock);
> +    vdev->name =3D info->name;
> +    vdev->owner =3D d;
> +    vdev->info =3D info;
> +
> +    rc =3D ns16x50_init(vdev);
> +    if ( rc )
> +    {
> +        xvfree(vdev);
> +        return ERR_PTR(rc);
> +    }
> +
> +    return vdev;
> +}
> +
> +static void cf_check ns16x50_free(void *arg)
> +{
> +    if ( arg )
> +        ns16x50_deinit(arg);
> +
> +    xvfree(arg);
> +}
> +
> +#define ns16x50_emulator                \
> +{                                       \
> +    .compatible =3D "ns16550",            \
> +    .alloc      =3D ns16x50_alloc,        \
> +    .free       =3D ns16x50_free,         \
> +    .dump_state =3D NULL,                 \
> +    .put_rx     =3D NULL,                 \
> +}
> +
> +VUART_REGISTER(ns16x50, ns16x50_emulator);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 10:11:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 10:11:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118092.1463995 (Exim 4.92)
	(envelope-from )
	id 1uwHnI-0003hc-ET; Wed, 10 Sep 2025 10:11:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118092.1463995; Wed, 10 Sep 2025 10: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 1uwHnI-0003hV-Ar; Wed, 10 Sep 2025 10:11:16 +0000
Received: by outflank-mailman (input) for mailman id 1118092;
 Wed, 10 Sep 2025 10:11: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 1uwHnH-0003hP-GO
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 10:11:15 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2418::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7a252763-8e2e-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 12:11:12 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA0PR12MB7075.namprd12.prod.outlook.com (2603:10b6:806:2d5::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 10:11:09 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::53da:e77e:261e:5a29%6]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 10:11: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: 7a252763-8e2e-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uqXJgupmxrL/JOX1LMNdYIc0KVIkjkCeEQfanSg5CGJWsqRhan7FlOyW7Bdp5As0r+0RY1Tm4rj37maDz62Pp0HMxs18dDq8zPzUHNh/oulpn3OtLI3nhziwPjf813BltwxQFaCzm56qjqduv2tkZLcFYuGledq2KYD9D5ALVZSjJX4d27bw5XK1GEtPDL8eDVPCZ0ozqp30RZfVzjxFb/jujEYNx59un4k7tn5qdvNwG0NjoWCrC+ZOpk2b+akzxhHakXSN3nsJ7ug2Qn8FV16dxgSyrsUqbmTx2uQv7aFZjU8+3c812wWmpYa4f8P2wNJWgrRzkLynGhx/p+cuVA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ph6vbwRzsg4J07rqbqonx8auHwK6/iO33Wn/HOQg+1E=;
 b=KAEOY4ED8wsiu9QLyibakyb9EVCpKdlMqds8UtKjGQCSrInlFvVrUc29WUjO5ghofy9ZvH/pMjnR8BDmMmb2fno7OAoxd3NlC8B1W99vXUtrrAxN/o7NJzDZfkYUztLIFzwvUARlgAcvBWWUeVW/dhtZ05oyIBnt8kUFBuVPEqmJzQ9+nX/YQ3n7Pxp7lEzYM6uPjI4sn/PGn4Ze/50vfk61Iav6OXBBiN6oKuqmivVvdTk149KaFRDAg+S4wbFzxEoUMxeqUI2P4AvMYt5lMVri+flPr4DXJpe4MpcBgNxlL6GdB21M0BiHXNPqIYBe/udR7SK3t5c5dAiwg0SYZg==
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=Ph6vbwRzsg4J07rqbqonx8auHwK6/iO33Wn/HOQg+1E=;
 b=sr6UbGLO1WpmFmqvrkxPZsEIAhNOhQAetyFwwTl8ir9SI1v8ujTyCiiy8pwn1aWbevn/ZCDmALmAam4iTHSRN1nWhEjEAYfLaQUIzTcl7yEX5CBZJHbzjrklg6miFG/EzcEh2FJ554KVV/8Q1UTRQ0H4pM+aHMKIv4rrY9NJHoc=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v11 5/5] vpci/msix: Implement cleanup function for MSI-X
Thread-Topic: [PATCH v11 5/5] vpci/msix: Implement cleanup function for MSI-X
Thread-Index: AQHcCDsDNbhhyPeREkWOwl6zipBaO7R5mWoAgBNQ/IA=
Date: Wed, 10 Sep 2025 10:11:09 +0000
Message-ID:
 
References: <20250808080337.28609-1-Jiqian.Chen@amd.com>
 <20250808080337.28609-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.9094.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_|SA0PR12MB7075:EE_
x-ms-office365-filtering-correlation-id: bd9295e8-3735-4b32-aad3-08ddf0525ce3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?d2w1Y1pMS1ZZS2p2cU5rTUVyc01ROXY0N2FVK2FxQk41YTRjQitOekp6QnVa?=
 =?utf-8?B?L2tiVWZ0Qmg2ZWxJMDVPR2QyUVVuaHY4dW1ISjhRbU9SVUdJa0FnaEhaaHBD?=
 =?utf-8?B?TzlRWGk4QXkzQUtiTnY5RDdMZ0hyOENsRVB6Skw1ckVPUkVGNXBuZndsdzll?=
 =?utf-8?B?a3lNcmVUTlRrWUIrVDR1S3dHVCtPRXIzcmNNZHplQWduUDFDSDRpcmNQUVEy?=
 =?utf-8?B?Q2tUTFBnb205d2xNNm5IdUw0Qys5T1RhcUpOMzhrWXFRZDNRbzVsZHZxTzVP?=
 =?utf-8?B?NkRuVVVtd0JxNHNZYUlra2JvclVvRmJrR09VT1o3ZlRTYWNTUENxRTVnQ3lv?=
 =?utf-8?B?SlBYbXBLNWM0ZDVMd1pXQmtaZ1kySnpNU0l3QmQ3L25sbnVkcXYwM09KWDg0?=
 =?utf-8?B?M0txeTczYkJ0V21LZWNFK0ZrVkZ3ZktYWWNaZ3hsZHdLZU5OcXdqdVZkNkIy?=
 =?utf-8?B?NWV3aUZ6aHlxeWhjUnlPcXN4M3BxaFNkM3NXZHMwcVVqQU9yWjVDRHlJcnFt?=
 =?utf-8?B?WHBJVG1KNW5kcy9pTFl5aTl1QmZHeGVCekJNYTFMbmhkMUw5elcwSndTd0xQ?=
 =?utf-8?B?OUpIdGtGa013WXpTSGJwUlJVeTRReVViQzBVY1lBVDdKdDBzZWx5T3VWVnhT?=
 =?utf-8?B?ZGh6ZEhrLzVpR2g4MVI4MVJpMDJxTEFjOHpoYTJidVBhTCtXbnUyQlpKRWJT?=
 =?utf-8?B?TlNJUDQvVGROZnhLTnZkZWppa2NuRHhyamlCSUl2UUIwWVhLZUZWSStPa29w?=
 =?utf-8?B?aFh2bUY0UE04UXZ3eG5jTkF5YllUNnQ3QjUvL0kwUG5od1k3OHp2TGtZYkdB?=
 =?utf-8?B?RGpVM2hFZkV5Q2RSNnF4bHhPUFZrN0N4b3AyNmdhMTJlTllEWk03RmVrNDJz?=
 =?utf-8?B?NUR3TC9kN3R6WjN3cTQzQUkvUkEvTkkwN01ubU1UMEJDME53TmNIUWIxbXBJ?=
 =?utf-8?B?QVkza2pBbXJ3cWVsSzhRUmUvZWNTZ1RLbkN4bnNUSWIxSVp2aGRDQ1Zrb1NF?=
 =?utf-8?B?Y0RkbFdqY0hEd01XcUhPWTdJNm13WktsTUMzNlA0dmdLeVFnVGxWdy82RlJH?=
 =?utf-8?B?VEdBNnptVkdtNjM5Ylk1OUdhSUVWM1BZRFd5cHMyTUtNdHNibmZDa2NhZU4x?=
 =?utf-8?B?emdzZGhvM0xROUlmdlZQbHl0bExHYTBaWkY3SzBUZHJlVXlFQU5mNGFLOFB2?=
 =?utf-8?B?dUhVVUhyWlFuSHUvQ3JlekF1Mmp0cXJzYzBrM094cUpzT1V5UUtDOXAxczhV?=
 =?utf-8?B?UnFEZEtKa25YTXRzUjk2V1EwMXBLK096elAydjFWbWlWNjBMMzZRMzI3NUVt?=
 =?utf-8?B?UmdvNmRFRjBGb3RkYXVNV214TWNWYldDV3VsOCtFMVhaZkN2THRzQW5GRjdX?=
 =?utf-8?B?NDE5ZCszTWZUc3B0OFJESTM2ZFZ3NmFYNGRUWnR1YktGbUVoazdGSjlSalhm?=
 =?utf-8?B?NThMK2FyMy9zUVJmSVRURU9jMkFlZUNrWU1BUVpRUzlrSzRtTTFUdWlidjFu?=
 =?utf-8?B?Ym5aa3hQU1RwaUw1eWNVQ2RBM2MyWUF0Z1pIaUJDL3RidlBiN3ZJTXJ1VDQ5?=
 =?utf-8?B?YWxaL3JZZk15ck9ZTE01QlNJODhVVmRvOGtRbExlT0VhMTh1bnRGQzJYNEdj?=
 =?utf-8?B?elZPR2YzOVJXTlFTRldLTUpuM2FuQlBvTDZHME1tK2s2aUxDRmF5ZTJocFNh?=
 =?utf-8?B?TTIwV21GNUI5RDl5N0V0SDkwd1Q4YkxxQ2FQYmdNdHVia1NFQlJER2RGS0w3?=
 =?utf-8?B?ejhSVkhaR0xOcTltSEt4T2pRVnNCc3R6cDZSVnZHLzEreit1bStObGJnRmk1?=
 =?utf-8?B?QlY1dmxjSzJiRTVHeGtCUVJxOUtQOVdHZ3ZseXdwdE9YVnlkMWlhaHJKV21h?=
 =?utf-8?B?U2Y3MmF2cmZkSFJLZ0Y1UUlPNE1kS3p0WUZ6VnppTmR5L3I0SFNhV0FqZVg5?=
 =?utf-8?B?WlRJNzRKS1pjMThtWHZhN0FxVVVXdnlOQkd5aDZmT0tPcCtFSEZEMUs3NjFz?=
 =?utf-8?Q?hIlr/WnEqssKrF/BTvtxjErdnjMK6c=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?cDlvOGJFSDl0VE91c041enRLdmhOdFlCWEJxME41dnNGY2gxWm9IN1Vld3JH?=
 =?utf-8?B?a295d0lYMkdRZ3NWOEhJNWpuWVU0aFExWHB3QkE5U1NwWjYvZk9kWmVnNEZ3?=
 =?utf-8?B?REhPM0V3Wi9WVGlSQ20vdVJJaGZlNVdQckdBTWh0QnlFdHdaUWlHNklSMlBR?=
 =?utf-8?B?T2JsWFpSNmlwOTVGbzgyanhVb0p5OEc0ZVcrcUJEVUtyMzEvQ1FHWnVPMG8z?=
 =?utf-8?B?NGhCd29wMUd5aS8zTWx1NVlrU1hSMmlpdUtpd0RqSDVEOFlLdHkxSGlaUFhY?=
 =?utf-8?B?MHRFRFpCKzNTL09zaHNRYzdDSUZWcmVXZFhpTnFOV09IaTVTeldQRWlWdFFa?=
 =?utf-8?B?SldGZUJJVHFNczZEV2ZaNDNDRVB4OTFZT0lvNkh2Rk9qVlViNDZ5ek5GKzBY?=
 =?utf-8?B?SVNKRHIyWWRwQkJZc3lJbHVxNmplMWtOV1JSdkR2Q1Y2TXJibWJJQVgxbUZX?=
 =?utf-8?B?NVFDanl1eGd5Y2lvOHlucDlvQVlhUk8xU1NzYllFbVoySnM1RnF1WlNUYXp2?=
 =?utf-8?B?Yk1iNTV1QjFtdE51R2ZxUS9KUERsYVpoTExTcjMrUVRYNm11eHdidVBVWXQ3?=
 =?utf-8?B?TDFNLzJzaVVKNG1QcnczSWNHcGFCcytibnoyU0dPTEJjSWlaMDNsMCt2bjV1?=
 =?utf-8?B?RUNXbWpES3piUzVXZ2VaTUlXODlnVkV3RWVjaG1WUitvQTJqbVI4VklERFBU?=
 =?utf-8?B?MlBPWGpkV3VQSlpMUXBHcmRhOHJJNWhBcUZtZHozcVFnVnFiUks3ZE1vWlZQ?=
 =?utf-8?B?Z0UvQVVUK1U1VGRJbitLZlU3djJRMndnSHd0UWg0cmFUbGlHa0NsV2NXYmRm?=
 =?utf-8?B?SVEraFpzSU1jTUNnR2duTm1rbFIvZ0JOYnVtT3lheE5vUU1jL3ZoSlZ1SzFN?=
 =?utf-8?B?TzloOWltVmxEZGoyVFhpWVJpMG9WenZMNUdqanZsVFMrR0wyQzdQcExFZzh1?=
 =?utf-8?B?dGVVeUNybWhxRkVPQ3F6VXlzR3JUZzkxQTA1Q05iZkxoencrTEFmZGhTUlR4?=
 =?utf-8?B?dmVMMkV1Tm5vcHg4Z3o0RWxKeGJaaFcvTEZjTkJ2ZkxISExFWm1jbXBDTEJa?=
 =?utf-8?B?N2lRVy9hUWhyOUxQSzVmYXU0OE9LVzJXMHowcVN5MUVoNGJqTS9jWnE4L3Fl?=
 =?utf-8?B?K1Y3emxFSGdMU3Y2NmhDWTREZ0FING1kYkxua2dJL1FOS1lZZjBOWC9uNHo0?=
 =?utf-8?B?VlFRN1hlNGI1QXVaL2NmZ0QxODNMdW9GWFBrSWRpV0tUWkJwVWRVQ2RLNmdm?=
 =?utf-8?B?dUpLL2lBTERpSXlaTkhVRnA2ZUdyUEVRUUZuNEtSVjJtNGdlZEFnTTJaemRk?=
 =?utf-8?B?K1c0dEt4K3JsS1FNRlVlMVZYb3hnUkFSa0ZVL3NZQUttNHYwdWVNVUltOWpG?=
 =?utf-8?B?Mi9JdzR3ZXdVUVlyZ0hsSUFLUldnUHJ1YjdHQjUvZkNDTXFmK1dnMUlSZWR2?=
 =?utf-8?B?amE3Y3pnNmt4d0xPUW9Uczl2U1BmNVN4Mm4vVG5Sb1pvMG82U2dqZE82RHN1?=
 =?utf-8?B?Z2Z1RGE5cmJxZkg2U2RLSkZ4OTFSTGhFNS9ndmdJeTNWaFh1WHBUR0g1Vkky?=
 =?utf-8?B?VXgwamlvQVJvY1N4YTB1bHhONzM5c3FpVU9KN3JoZVd6a1VLZmlja2JPTVJ2?=
 =?utf-8?B?cXE2QUYwZUJDa3ExNm85K3ZxaWN6SFlLNzNPbUVMR1VGYml6YzJUTVFNRlYr?=
 =?utf-8?B?N3lhSjVSNS9rejVFdDY0Y3A2MlZMSzFzSThQNGRDdDJDUTdRZ25lUWhyNTZv?=
 =?utf-8?B?NEJpck9qTkdSU3FNMlBHTGdHNEk0OWFhbW1DdXJzZVd4VXhDY3lUdWpSVEZS?=
 =?utf-8?B?NTJwbTl2QUpCVUw1WERyVGtMb09CZnl5MEY0NEh1VEV3Z2cxcVBDTkNjYTNl?=
 =?utf-8?B?V1pRQ0ZXK0NCZWFna0JzcVdpb1BJMmJidXZKdEhRSVY4L3M3ZGNpREJESFAx?=
 =?utf-8?B?R2FQNDZ1T00xc2hjTHp0aU4vZ0U3Sk95V1hRbWVnU1BRcWczdmwvVzZlY2U0?=
 =?utf-8?B?M2xNd21yVW42SldtbWMzdCt3L1pwLy8yRkxkT2paR2FsYmV6amxjRkl5MFZG?=
 =?utf-8?B?aFNjaFBRSlVsdjA5OFlGOStrMlVXdzVjN3dKRDd1NU1tMnZSeXR5WDlxbmxv?=
 =?utf-8?Q?26Bs=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <239E8B6410292E46B8C5286E5F560521@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: bd9295e8-3735-4b32-aad3-08ddf0525ce3
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2025 10:11:09.2529
 (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: Ac7TNJKxbCaDddNUdq3dtJdshGRBcl2zKOqR6buvb68OucZzJ4pMVNuMccic7BGZX51hWZPaq4kAexuT6nuX5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7075

T24gMjAyNS84LzI5IDE5OjA2LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBGcmksIEF1
ZyAwOCwgMjAyNSBhdCAwNDowMzozN1BNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IFdo
ZW4gTVNJLVggaW5pdGlhbGl6YXRpb24gZmFpbHMsIHZQQ0kgaGlkZXMgdGhlIGNhcGFiaWxpdHks
IGJ1dA0KPj4gcmVtb3ZpbmcgaGFuZGxlcnMgYW5kIGRhdGFzIHdvbid0IGJlIHBlcmZvcm1lZCB1
bnRpbCB0aGUgZGV2aWNlIGlzDQo+PiBkZWFzc2lnbmVkLiBTbywgaW1wbGVtZW50IE1TSS1YIGNs
ZWFudXAgaG9vayB0aGF0IHdpbGwgYmUgY2FsbGVkDQo+PiB0byBjbGVhbnVwIE1TSS1YIHJlbGF0
ZWQgaGFuZGxlcnMgYW5kIGZyZWUgaXQncyBhc3NvY2lhdGVkIGRhdGEgd2hlbg0KPj4gaW5pdGlh
bGl6YXRpb24gZmFpbHMuDQo+Pg0KPj4gU2luY2UgY2xlYW51cCBmdW5jdGlvbiBvZiBNU0ktWCBp
cyBpbXBsZW1lbnRlZCwgZGVsZXRlIHRoZSBvcGVuLWNvZGUNCj4+IGluIHZwY2lfZGVhc3NpZ25f
ZGV2aWNlKCkuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogSmlxaWFuIENoZW4gPEppcWlhbi5DaGVu
QGFtZC5jb20+DQo+PiAtLS0NCj4+IGNjOiAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPg0KPj4gLS0tDQo+PiB2MTAtPnYxMSBjaGFuZ2VzOg0KPj4gKiBNb3ZlIGNhbGxp
bmcgYWxsIGNsZWFudXAgaG9vayBpbiB2cGNpX2RlYXNzaWduX2RldmljZSgpIG91dCBvZiB0aGlz
IHBhdGNoLg0KPj4gKiBBZGQgaGlkZSBwYXJhbWV0ZXIgdG8gY2xlYW51cF9tc2l4KCkuDQo+PiAq
IENoZWNrIGhpZGUsIGlmIGl0IGlzIGZhbHNlLCByZXR1cm4gZGlyZWN0bHkgaW5zdGVhZCBvZiBs
ZXR0aW5nIGN0cmwgUk8uDQo+Pg0KPj4gdjktPnYxMCBjaGFuZ2VzOg0KPj4gKiBDYWxsIGFsbCBj
bGVhbnVwIGhvb2sgaW4gdnBjaV9kZWFzc2lnbl9kZXZpY2UoKSBpbnN0ZWFkIG9mIGNsZWFudXBf
bXNpeCgpLg0KPj4NCj4+IHY4LT52OSBjaGFuZ2VzOg0KPj4gKiBNb2RpZnkgY29tbWl0IG1lc3Nh
Z2UuDQo+PiAqIENhbGwgY2xlYW51cF9tc2l4KCkgaW4gdnBjaV9kZWFzc2lnbl9kZXZpY2UoKSB0
byByZW1vdmUgdGhlIG9wZW4tY29kZSB0byBjbGVhbnVwIG1zaXggZGF0YXMuDQo+PiAqIEluIGNs
ZWFudXBfbXNpeCgpLCBtb3ZlICJsaXN0X2RlbCgmdnBjaS0+bXNpeC0+bmV4dCk7IiBhYm92ZSBm
b3IgbG9vcCBvZiBpb3VubWFwIG1zaXggdGFibGVzLg0KPj4NCj4+IHY3LT52OCBjaGFuZ2VzOg0K
Pj4gKiBHaXZlbiB0aGUgY29kZSBpbiB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSBhbiBlcnJvciBp
biB0aGUgcmVtb3ZhbCBvZg0KPj4gICByZWdpc3RlcnMgd291bGQgbGlrZWx5IGltcGx5IG1lbW9y
eSBjb3JydXB0aW9uLCBhdCB3aGljaCBwb2ludCBpdCdzDQo+PiAgIGJlc3QgdG8gZnVsbHkgZGlz
YWJsZSB0aGUgZGV2aWNlLiBTbywgUm9sbGJhY2sgdGhlIGxhc3QgdHdvIG1vZGlmaWNhdGlvbnMg
b2YgdjcuDQo+Pg0KPj4gdjYtPnY3IGNoYW5nZXM6DQo+PiAqIENoYW5nZSB0aGUgcG9pbnRlciBw
YXJhbWV0ZXIgb2YgY2xlYW51cF9tc2l4KCkgdG8gYmUgY29uc3QuDQo+PiAqIFdoZW4gdnBjaV9y
ZW1vdmVfcmVnaXN0ZXJzKCkgaW4gY2xlYW51cF9tc2l4KCkgZmFpbHMsIG5vdCB0byByZXR1cm4N
Cj4+ICAgZGlyZWN0bHksIGluc3RlYWQgdHJ5IHRvIGZyZWUgbXNpeCBhbmQgcmUtYWRkIGN0cmwg
aGFuZGxlci4NCj4+ICogUGFzcyBwZGV2LT52cGNpIGludG8gdnBjaV9hZGRfcmVnaXN0ZXIoKSBp
bnN0ZWFkIG9mIHBkZXYtPnZwY2ktPm1zaXggaW4NCj4+ICAgaW5pdF9tc2l4KCkgc2luY2Ugd2Ug
bmVlZCB0aGF0IGV2ZXJ5IGhhbmRsZXIgcmVhbGl6ZSB0aGF0IG1zaXggaXMgTlVMTA0KPj4gICB3
aGVuIG1zaXggaXMgZnJlZWQgYnV0IGhhbmRsZXJzIGFyZSBzdGlsbCBpbiB0aGVyZS4NCj4+DQo+
PiB2NS0+djYgY2hhbmdlczoNCj4+ICogQ2hhbmdlIHRoZSBsb2dpYyB0byBhZGQgZHVtbXkgaGFu
ZGxlciB3aGVuICF2cGNpLT5tc2l4IGluIGNsZWFudXBfbXNpeCgpLg0KPj4NCj4+IHY0LT52NSBj
aGFuZ2VzOg0KPj4gKiBDaGFuZ2UgZGVmaW5pdGlvbiAic3RhdGljIHZvaWQgY2xlYW51cF9tc2l4
IiB0byAic3RhdGljIGludCBjZl9jaGVjayBjbGVhbnVwX21zaXgiDQo+PiAgIHNpbmNlIGNsZWFu
dXAgaG9vayBpcyBjaGFuZ2VkIHRvIGJlIGludC4NCj4+ICogQWRkIGEgcmVhZC1vbmx5IHJlZ2lz
dGVyIGZvciBNU0lYIENvbnRyb2wgUmVnaXN0ZXIgaW4gdGhlIGVuZCBvZiBjbGVhbnVwX21zaXgo
KS4NCj4+DQo+PiB2My0+djQgY2hhbmdlczoNCj4+ICogQ2hhbmdlIGZ1bmN0aW9uIG5hbWUgZnJv
bSBmaW5pX21zaXgoKSB0byBjbGVhbnVwX21zaXgoKS4NCj4+ICogQ2hhbmdlIHRvIHVzZSBYRlJF
RSB0byBmcmVlIHZwY2ktPm1zaXguDQo+PiAqIEluIGNsZWFudXAgZnVuY3Rpb24sIGNoYW5nZSB0
aGUgc2VxdWVuY2Ugb2YgY2hlY2sgYW5kIHJlbW92ZSBhY3Rpb24gYWNjb3JkaW5nIHRvDQo+PiAg
IGluaXRfbXNpeCgpLg0KPj4NCj4+IHYyLT52MyBjaGFuZ2VzOg0KPj4gKiBSZW1vdmUgdW5uZWNl
c3NhcnkgY2xlYW4gb3BlcmF0aW9ucyBpbiBmaW5pX21zaXgoKS4NCj4+DQo+PiB2MS0+djIgY2hh
bmdlczoNCj4+IG5ldyBwYXRjaC4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBKaXFpYW4gQ2hl
bi4NCj4+IC0tLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jIHwgNDcgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKy0NCj4+ICB4ZW4vZHJpdmVycy92cGNpL3ZwY2ku
YyB8ICA4IC0tLS0tLS0NCj4+ICAyIGZpbGVzIGNoYW5nZWQsIDQ2IGluc2VydGlvbnMoKyksIDkg
ZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5j
IGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+IGluZGV4IDU0YTUwNzA3MzNhYS4uMjg3YWFm
ZGE5MTU3IDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+ICsrKyBi
L3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jDQo+PiBAQCAtNjU1LDYgKzY1NSw1MSBAQCBpbnQgdnBj
aV9tYWtlX21zaXhfaG9sZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICAgICAgcmV0
dXJuIDA7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2l4
KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCBib29sIGhpZGUpDQo+PiArew0KPj4gKyAgICBp
bnQgcmM7DQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBjaTsNCj4+ICsgICAg
Y29uc3QgdW5zaWduZWQgaW50IG1zaXhfcG9zID0gcGRldi0+bXNpeF9wb3M7DQo+PiArDQo+PiAr
ICAgIGlmICggIW1zaXhfcG9zICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPiANCj4gTGlrZSB3
aXRoIHRoZSBNU0kgY2FwYWJpbGl0eSwgaXMgaXQgcG9zc2libGUgdG8gZ2V0IGNhbGxlZCBhbmQN
Cj4gcGRldi0+bXNpeF9wb3MgYmUgMD8NClNpbmNlIGN1cnJlbnRseSBvbmx5IHZwY2lfZGVhc3Np
Z25fZGV2aWNlIGFuZCB2cGNpX2luaXRfY2FwYWJpbGl0aWVzIGNhbGwgY2xlYW51cCBob29rLA0K
YW5kIHRoZXkgYm90aCBoYXZlIGNoZWNrIHRvIHByZXZlbnQgcG9zIGJlaW5nIDAsIHNvIGlmIHlv
dSB0aGluayBjaGVjayBoZXJlIGlzIHJlZHVuZGFuY3ksIEkgd2lsbCBkZWxldGUgaXQgaW4gbmV4
dCB2ZXJzaW9uLA0KTVNJIGFuZCBSZWJhciBjbGVhbnVwIGhvb2sgYXJlIHRoZSBzYW1lIGFzIGhl
cmUuDQoNCj4gDQo+IEkgd291bGQgYWxzbyBhdm9pZCB0aGUgY2FsbCB0byB2cGNpX3JlbW92ZV9y
ZWdpc3RlcnMoKSBpZiAhaGlkZSwgSQ0KPiB0aGluayB5b3UgY2FuIGNoYW5nZSB0aGUgb3JkZXIg
b2YgdGhlIGNsZWFudXAsIHNvIGl0J3M6DQo+IA0KPiBpZiAoIHZwY2ktPm1zaXggKQ0KPiB7DQo+
ICAgICBsaXN0X2RlbCgmdnBjaS0+bXNpeC0+bmV4dCk7DQo+ICAgICBmb3IgKCB1bnNpZ25lZCBp
bnQgaSA9IDA7IGkgPCBBUlJBWV9TSVpFKHZwY2ktPm1zaXgtPnRhYmxlKTsgaSsrICkNCj4gICAg
ICAgICBpZiAoIHZwY2ktPm1zaXgtPnRhYmxlW2ldICkNCj4gICAgICAgICAgICAgaW91bm1hcCh2
cGNpLT5tc2l4LT50YWJsZVtpXSk7DQo+IA0KPiAgICAgWEZSRUUodnBjaS0+bXNpeCk7DQo+IH0N
Cj4gDQo+IGlmICggIWhpZGUgKQ0KPiAgICAgcmV0dXJuIDA7DQo+IA0KPiByYyA9IHZwY2lfcmVt
b3ZlX3JlZ2lzdGVycyh2cGNpLCBtc2l4X2NvbnRyb2xfcmVnKG1zaXhfcG9zKSwgMik7DQo+IC4u
Lg0KPiANCj4gVGhhbmtzLCBSb2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hl
bi4NCg0K


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 10:16:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 10:16:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118109.1464004 (Exim 4.92)
	(envelope-from )
	id 1uwHs8-0004Lj-56; Wed, 10 Sep 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 1118109.1464004; Wed, 10 Sep 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 1uwHs8-0004Lc-25; Wed, 10 Sep 2025 10:16:16 +0000
Received: by outflank-mailman (input) for mailman id 1118109;
 Wed, 10 Sep 2025 10:16: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 1uwHs6-0004LW-Ky
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 10:16:14 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d59ae28-8e2f-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 12:16:12 +0200 (CEST)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-33c9f2bcdceso31964761fa.2
 for ; Wed, 10 Sep 2025 03:16: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: 2d59ae28-8e2f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757499372; x=1758104172; 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=T1kaL6Mnx2gH5E13iVZci7fObqBOOVo+qKkougytvlI=;
        b=ce0v63GbgXdkv7PIs++omtmNYAr6/EXdjl5KqGGEjjAwAxt9HEkswBx5oqmOce1JwR
         8TQMVa4Snp/BuFmJrxftzpuumyCWdIYtuKCs42MQfVR3ibSLQnWR+8gyRRcw5oLnWQ0G
         NU7uzHDm+0YYRtveg7mONipORIG2d7OC0AKgTGydloQ2jKC5r5/nqMQZk6v3o7gaozqO
         hAPMLYDhVJ8pRiX55j0Fg+sKEP2JXpBZu3ZN5mH7RSbGy/zV/yRf+D6LQ8pLIA9UXqGA
         iSxBo56m5afN5Q9+C2/r2As1i4lyfl0KsQ4wFrznJLzWsTStDX2EG7o+diz9qL3debEw
         MADw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757499372; x=1758104172;
        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=T1kaL6Mnx2gH5E13iVZci7fObqBOOVo+qKkougytvlI=;
        b=OPA6Ghx7UKx6UClpHj31v1Ly21UEFsGx595tHhZ0J2dqlhTl1x4RDMtxgmGZZHdbmD
         +dfBwhMF8CzoG2NmEvKhxY/KeEjy54VNGc+28IbMh3pUEzqUkehYz7FRHZlIjkePLy4L
         pxepdH4YLDhrdK+kW/UgtdjS7dVwWFXThYqxL5x/TdWwMcS8wuTB/HqjaMw3Xw+juUGe
         3nGMlx+ZGAegzABk/uow6Y3yiQegqQNKyCy9mtgQ7BST94Ne89sdPvc8rXJhl/2J/Gta
         /NwGICmE/8of4OqOyGUP67MywB/R7Hqx+cSn/wA86VJlKy5wZ/Z/ljOI6G6c+ALATw9Q
         fuCw==
X-Gm-Message-State: AOJu0YwprqdX9P0JkDxsUyIWP3bTXHx1mnlgdIuB16VwRZl19TWepQMN
	0Jct6YrTrl0Upu0XPJNmpSR1lhvvV6QJWmfHpryzvIGoUsAw+C2z9zZE6p0kqZ2/pfeN2ErnUJi
	XFZxsWg1QCUXZzwDSahDEkQanzzWorn0=
X-Gm-Gg: ASbGncua/BSYgPZKTDtzmCeKZfxt6fk1dJNRdMQxG1cyv6ZChrtambuUQkTqIc9IJNe
	VrVP9elGQAi61OMPL563CWQgK2kCbTe3zmiIOTGCMUZuljmVwevz3Uv/U+QpZY+wLwMP7ulLMty
	J2RWZ4vdGid+nbcNbz0PAO5AEQnSCyPuhvveh/F/TvX2zHHCuSTgLkzNo5d8HeHe4JmlfWsM1Me
	2LvuQ==
X-Google-Smtp-Source: AGHT+IEmZxc9EWjD9ymApbizg7ZlVlUym0SuEVLn1ccZwx8eUbbVinofMrduHVTD6EsxCoHM3Bv1X0WQkmfsmmGfsSk=
X-Received: by 2002:a05:651c:214e:b0:336:c080:4149 with SMTP id
 38308e7fff4ca-33b50f93fffmr33208981fa.18.1757499371675; Wed, 10 Sep 2025
 03:16:11 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-5-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-5-dmukhin@ford.com>
From: Mykola Kvach 
Date: Wed, 10 Sep 2025 13:16:00 +0300
X-Gm-Features: Ac12FXzjl9SPOwJf5S296-Gm78h0olHMBwG-lMADjTcEeQmMxl2QaWRtDjvmraM
Message-ID: 
Subject: Re: [PATCH v7 04/16] emul/ns16x50: implement DLL/DLM registers
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

I appreciate you addressing the comments from the earlier version
of the patch series.

On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add DLL/DLM registers emulation.
>
> DLL/DLM registers report hardcoded 115200 baud rate to the guest OS.
>
> Add stub for ns16x50_dlab_get() helper.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - added default registers handling for non-DLL/DLM accesses
> - used UINT8_MAX
> ---
>  xen/common/emul/vuart/ns16x50.c | 47 +++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index a3bdf9f415ca..da8583a1dc93 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -96,8 +96,22 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns1=
6x50 *vdev)
>  static int ns16x50_io_write8(
>      struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
>  {
> +    uint8_t *regs =3D vdev->regs;
> +    uint8_t val =3D *data;
>      int rc =3D 0;
>
> +    if ( ns16x50_dlab_get(vdev) && (reg =3D=3D UART_DLL || reg =3D=3D UA=
RT_DLM) )
> +        regs[NS16X50_REGS_NUM + reg] =3D val;
> +    else
> +    {
> +        switch ( reg )
> +        {
> +        default:
> +            rc =3D -EINVAL;
> +            break;
> +        }
> +    }
> +
>      return rc;
>  }
>
> @@ -108,8 +122,16 @@ static int ns16x50_io_write8(
>  static int ns16x50_io_write16(
>      struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
>  {
> +    uint16_t val =3D *data;
>      int rc =3D -EINVAL;
>
> +    if ( ns16x50_dlab_get(vdev) && reg =3D=3D UART_DLL )
> +    {
> +        vdev->regs[NS16X50_REGS_NUM + UART_DLL] =3D val & UINT8_MAX;
> +        vdev->regs[NS16X50_REGS_NUM + UART_DLM] =3D (val >> 8) & UINT8_M=
AX;
> +        rc =3D 0;
> +    }
> +
>      return rc;
>  }
>
> @@ -145,9 +167,22 @@ static int ns16x50_io_write(
>  static int ns16x50_io_read8(
>      struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
>  {
> +    uint8_t *regs =3D vdev->regs;
>      uint8_t val =3D UINT8_MAX;
>      int rc =3D 0;
>
> +    if ( ns16x50_dlab_get(vdev) && (reg =3D=3D UART_DLL || reg =3D=3D UA=
RT_DLM) )
> +        val =3D regs[NS16X50_REGS_NUM + reg];
> +    else
> +    {
> +        switch ( reg )
> +        {
> +        default:
> +            rc =3D -EINVAL;
> +            break;
> +        }
> +    }
> +
>      *data =3D val;
>
>      return rc;
> @@ -162,6 +197,13 @@ static int ns16x50_io_read16(
>      uint16_t val =3D UINT16_MAX;
>      int rc =3D -EINVAL;
>
> +    if ( ns16x50_dlab_get(vdev) && reg =3D=3D UART_DLL )
> +    {
> +        val =3D vdev->regs[NS16X50_REGS_NUM + UART_DLM] << 8 |
> +              vdev->regs[NS16X50_REGS_NUM + UART_DLL];
> +        rc =3D 0;
> +    }
> +
>      *data =3D val;
>
>      return rc;
> @@ -278,12 +320,17 @@ out:
>
>  static int ns16x50_init(void *arg)
>  {
> +    const uint16_t divisor =3D (UART_CLOCK_HZ / 115200) >> 4;
>      struct vuart_ns16x50 *vdev =3D arg;
>      const struct vuart_info *info =3D vdev->info;
>      struct domain *d =3D vdev->owner;
>
>      ASSERT(vdev);
>
> +    /* NB: report 115200 baud rate. */
> +    vdev->regs[NS16X50_REGS_NUM + UART_DLL] =3D divisor & UINT8_MAX;
> +    vdev->regs[NS16X50_REGS_NUM + UART_DLM] =3D (divisor >> 8) & UINT8_M=
AX;
> +
>      register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
>
>      return 0;
> --
> 2.51.0
>
>

Reviewed-by: Mykola Kvach 

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 11:34:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 11:34:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118155.1464066 (Exim 4.92)
	(envelope-from )
	id 1uwJ5i-0006Sv-5U; Wed, 10 Sep 2025 11:34:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118155.1464066; Wed, 10 Sep 2025 11:34: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 1uwJ5i-0006So-2u; Wed, 10 Sep 2025 11:34:22 +0000
Received: by outflank-mailman (input) for mailman id 1118155;
 Wed, 10 Sep 2025 11:34: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 1uwJ5g-0006Si-Kw
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 11:34:20 +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 170fd537-8e3a-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 13:34:19 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3df2f4aedc7so3808957f8f.2
 for ; Wed, 10 Sep 2025 04:34:19 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e752238832sm6343296f8f.31.2025.09.10.04.34.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 10 Sep 2025 04:34: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: 170fd537-8e3a-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757504059; x=1758108859; 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=j6+nn9UIr1kZR9BUz4wxS+TIl8oWXnDTOsT/TpLgGVU=;
        b=ApR4q8gW//nLJ2gW4KN2jPq13220Rom+2qrqcAN+V2LnSCZKpwLB4YYNezOf6klzCz
         OmHG2nX2gbUsKfCmK6x4uj9+rjB+EtImbYRaqtYy9WtvSR8qA1eshhkgrnxOndZJ6jjA
         SqzD7kFkfFyjh8AAyNyoRuyeqZB4nc6Xd8gYg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757504059; x=1758108859;
        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=j6+nn9UIr1kZR9BUz4wxS+TIl8oWXnDTOsT/TpLgGVU=;
        b=H7wEA+747TNlHvU9UorE6dTYMxupdaZelxqVQkhfkF88wM8zPXaAVQE0ND3h5z811R
         EMrJ4+TsJEhIfb9nZ+F6meqrNqU4k/KZlanTKAL03HPEm4ymX97OonBfoRCc+stWW/zT
         8zqRlvqKdZ/G2mwRf232GCx5Wo/rW1IDnw213vk99a+sEjKfPgWRxSYCymrs0hbJ7Zuf
         Suqg4v8nPysRwvSkpdSNYG+PQL+UKyriKQnHfsmgcIfa9CWY82xTcUezWSJdySVWypqM
         EZZLQ/IiOJjxPpQl2mELafpZVoTKfd42rL2fjgQ6e/0i1bN823JiGb2/OUDlYdTPe98V
         nhQw==
X-Gm-Message-State: AOJu0Ywz0EZ1y0K03bsubk4T+1clZCI4Yd24ZarnwB2Shtk666yviVjH
	8xpYyc8c9UUyp5HEG028vync895mQhtybdtP13Nt+Pg9Sok8nULA3ijukLS/wJ9NtdTjZMsoSh3
	8LtM/
X-Gm-Gg: ASbGncs1THVjkhxSTW3349h4+EDyPsvwVgSNkeG+dhxDGfcAkFrVhLjMJpRc+ja7NHs
	Wbbiyy5GB7xmT+JNgq7dwYrrx9JQKz5PGjpFR6kae4Ru13nMOSLWIF0V9QGOmtfFSQFOig2gHC4
	cJi/vZ3AFvj1gq8Kj5qXIPIufVsYlNx0TP1FyA986Ik+ZdrTgxrwb/HA74OtFhokcSPv4i86+r7
	6xFoucRS5cflodkgwC+bhJWeIhj73L5CDAoT1nD7EfBF6JLQfCIO0ueKedxMvwPQlbXXQ3QFrJI
	OyBcOUFzUpPU+H0pa7uzagIrGLM/6JYJpMJyeJgoOKkcbJO/NmAvPd3VSw+zQegGg6A1aDLnLW8
	u6WhzK4t8wQl/tamK8EK5zCSVvqsbLeblGtTEgFRycypntpuZRkQO5bxnm1Lq017HZ8S6Tg/KF1
	jrHHIhPaG17Vk=
X-Google-Smtp-Source: AGHT+IFIyERCIsO1mNcq6O6MZm9Fk5DxT0mcYLDk29QHvYrnzM7migljfZFkUPnIHU+XPBwztjETBQ==
X-Received: by 2002:a05:6000:420f:b0:3d9:70cc:6dd2 with SMTP id ffacd0b85a97d-3e64317eee0mr10039762f8f.40.1757504058633;
        Wed, 10 Sep 2025 04:34:18 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH] CI: Switch the alpine containers to be non-root
Date: Wed, 10 Sep 2025 12:34:16 +0100
Message-Id: <20250910113416.1835988-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

Testing on staging-4.19 is hitting a reliable failure, caused by alpine/3.18
being a root build container, but debian/12-x86_64 being a non-root test
container.  Specifically, the test container can't copy XEN_PAGING_DIR and
XEN_DUMP_DIR (both 700) from the build root in order to construct the initrd.

staging-4.20 and later do not repack the initrd in this way, so are not
affected.

Switch both alpine containers to being non-root.  This is still slightly
fragile, but better than depending on using root containers for both.

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

The only less fragile option I can think of would be to backport the initrd
CPIO optimisations.  I backported it from 4.21 to 4.20, and can't remember if
there was a blocking reason on 4.19, or simply that it would be a lot of work.

I've rebuilt these containers in registry.gitlab.com/xen-project/people/andyhhp/xen

Runs using this registry:
  staging:
    https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2031831044
  staging-4.19:
    https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2031832855

(There will be a delay until these can run fully.  The CPPCheck container
takes an unreasonable amount of time to rebuild, and it's holding up a couple
of others.)
---
 automation/build/alpine/3.18-arm64v8.dockerfile | 16 ++++++++--------
 automation/build/alpine/3.18.dockerfile         | 16 ++++++++--------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/automation/build/alpine/3.18-arm64v8.dockerfile b/automation/build/alpine/3.18-arm64v8.dockerfile
index b8482d5bf43f..360da8281054 100644
--- a/automation/build/alpine/3.18-arm64v8.dockerfile
+++ b/automation/build/alpine/3.18-arm64v8.dockerfile
@@ -3,13 +3,10 @@ FROM --platform=linux/arm64/v8 alpine:3.18
 LABEL maintainer.name="The Xen Project" \
       maintainer.email="xen-devel@lists.xenproject.org"
 
-ENV USER root
-
-RUN mkdir /build
-WORKDIR /build
-
-# build depends
-RUN apk --no-cache add \
+RUN adduser -S user && \
+  mkdir /build && \
+  # build depends
+  apk --no-cache add \
   \
   # xen build deps
   argp-standalone \
@@ -48,4 +45,7 @@ RUN apk --no-cache add \
   # qubes test deps
   openssh-client \
   fakeroot \
-  expect \
+  expect
+
+USER user
+WORKDIR /build
diff --git a/automation/build/alpine/3.18.dockerfile b/automation/build/alpine/3.18.dockerfile
index 263e9e90d888..4ccbe8e5c1b3 100644
--- a/automation/build/alpine/3.18.dockerfile
+++ b/automation/build/alpine/3.18.dockerfile
@@ -3,13 +3,10 @@ FROM --platform=linux/amd64 alpine:3.18
 LABEL maintainer.name="The Xen Project" \
       maintainer.email="xen-devel@lists.xenproject.org"
 
-ENV USER root
-
-RUN mkdir /build
-WORKDIR /build
-
-# build depends
-RUN apk --no-cache add \
+RUN adduser -S user && \
+  mkdir /build && \
+  # build depends
+  apk --no-cache add \
   \
   # xen build deps
   argp-standalone \
@@ -49,4 +46,7 @@ RUN apk --no-cache add \
   ninja \
   pixman-dev \
   # livepatch-tools deps
-  elfutils-dev \
+  elfutils-dev
+
+USER user
+WORKDIR /build
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 11:58:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 11:58:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118172.1464076 (Exim 4.92)
	(envelope-from )
	id 1uwJTM-0000xY-0H; Wed, 10 Sep 2025 11:58:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118172.1464076; Wed, 10 Sep 2025 11:58: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 1uwJTL-0000xR-TO; Wed, 10 Sep 2025 11:58:47 +0000
Received: by outflank-mailman (input) for mailman id 1118172;
 Wed, 10 Sep 2025 11:58: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 1uwJTK-0000xL-KY
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 11:58:46 +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 80094c5b-8e3d-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 13:58:45 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by CH3PR12MB8709.namprd12.prod.outlook.com (2603:10b6:610:17c::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 11:58:41 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 11:58: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: 80094c5b-8e3d-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Sn3V7oELjkrT+Ex+wYuTTfJd3WsUwYgnJmnkM+tItOpmbM+J8qovkAPHYt/A7PKdAxoWGlisZ5TesXjmIXvOHKWcNXtA1O3Hg9SA6mAhfrHEezRPKmMCSHIRBmSiBgsvZgxaw6V0hH4pbdO54/Yd5q5EIYBFKZuN7d/8WIw+zLxloBetM/UCcYtcIc6GW5rH0jBKwge7a0m4jPykaBH8Y8sKHehJQWlDdKdUNpkCp2evYTZ7lvgs+TsiTWScPuI24eLlp6TrdOL+hleedbJyK+OJ4SytpZZpW4FYO/j3zVP4FD60hiKyFc9ZB4/0Ery3tfckBgfq1QXuqElNvsjftw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=M2CRGJWbvgTRAKQCpQVq3CvW0DQ/ZyYML+xgjXHDleo=;
 b=tB2vXc4aLG7Xvj/iBdZSvwn5l5BDP6C+4bz1pIRIWCRgMWFDDbhmT5qJwttomGtb8BHCznSs1U/3u4v6DHTHmWC/I6z+Xr6vluxXtIpc3nRzQiDjGvtecnGkPUr8uW7zs/hJWBGP80S7Nc1dUlCLFh9qUOu5jO987pSlHgXoT/P1w6NsT3FQBwOILLwl3So1eAjWPEjg3x9jiy8sN7xCZqAPkDZVJitbvd8ChCDhycviaJq9+sQzjix1CUYwDf9us224wMfxwnVp/LXMt9t30uAoOeFS7X2kQZFGh8Eg3ciqLaMSqi0Ur/Kgqry1mm4HqC3j/XfupYGVGiT8b2TLaA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=M2CRGJWbvgTRAKQCpQVq3CvW0DQ/ZyYML+xgjXHDleo=;
 b=DCGX5i1wV1JzbNNAuAK46B1FTzUqbIWJJr1k/xRxSeDUhzU9om62gERPuNF9zaGeSw3Z47iVGhqjLYvnnpANarQksVzq5onyjKQEa/uqx4+QH9ptjWiYcpUBJuCKrMO21J8C5gZEzPW3uZshpwp8TsczXFauxzksXuc9pJwioRUTXudhdy6L2hUGfrzW6zFhm7ermfbnA+frN//qvdI/SL4Ye+KQ/MfEcYEEtrj13319OvercvtIa+jAK7pRYfUZPJwYgn+rUmDsHPM/wcOgja0mFu5Tjb6neURlaC8VFX+tVNuwHJvJyj+If2Ypv4p2rx/AJA7xTfLlNTPx9BllEA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Wed, 10 Sep 2025 08:58:39 -0300
From: Jason Gunthorpe 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	Keith Busch , linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 03/16] dma-debug: refactor to use physical addresses
 for page mapping
Message-ID: <20250910115839.GT789684@nvidia.com>
References: 
 <56d1a6769b68dfcbf8b26a75a7329aeb8e3c3b6a.1757423202.git.leonro@nvidia.com>
 <20250909193748.GG341237@unreal>
 <20250910052618.GH341237@unreal>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250910052618.GH341237@unreal>
X-ClientProxiedBy: YT4PR01CA0498.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:b01:10c::6) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|CH3PR12MB8709:EE_
X-MS-Office365-Filtering-Correlation-Id: d3d1beeb-870b-4064-522c-08ddf0616235
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|1800799024|376014|366016;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?FzIxhCTl/DFGFmaXIkSJW43QRlHeUwrObkzUBGOXZlpW5TknvixiA4gDQdO0?=
 =?us-ascii?Q?Y/Q2AqArhV3Ean+ESTnkZr/fvpBX2nkWxFKLLH4g5CA9C8G475Hr3gb3OOjv?=
 =?us-ascii?Q?6uJVbcwr9hyVssPYNNIHf4cHbHNfa1FcsJ0EkEfNXG98vrQPHF/sWCvG8QI/?=
 =?us-ascii?Q?COGsWCNfWUGpIWeBBcktY7eFttSjXnJa/fCDlR5M7SnWvVHjP09ct5kmeZoH?=
 =?us-ascii?Q?SAYNOPDNskcy46Em8ly9RRUNfqYG4XoPucVxFGwyPQt0cGYV/RAX2nuBRLnY?=
 =?us-ascii?Q?oDenFOddnolaVnUlfh0CImgVZFr/tUkfCle8aamRAftKGcs67gzyutBwvoDi?=
 =?us-ascii?Q?dNUaAWRksh0OpZeDtOzS+yUixVU6iF6zuAgdtdJ+/SJw1dzFDkGfm80wGCoH?=
 =?us-ascii?Q?pckzkDSveUd+iwi2lfDzjyPVQ9yj0CiH/xxWs9md9M1AQSc3NZiJU1hLjeKm?=
 =?us-ascii?Q?aAY8FuT7mkNTvmr+F8IaY1xbUkqwDE0/IWF1EmvaP2B2COuQ7wMj4RNUjEOc?=
 =?us-ascii?Q?O/AhbcPzLAMyP9dJTa4ojajfgOMtdCIXx/Rxry4yk0Rx2rZ2fjSA6M+C0jit?=
 =?us-ascii?Q?E4yYm3ZocgAEqqYDdafANBeHp39vXTx87t0jZIqiUkS+AeC6ISIHwD9hDxkj?=
 =?us-ascii?Q?3NKmejdUiaLbjH+sBCgqd206gGNFVcc0Zt98Oozys1GBZXwHRLMY812uQPYE?=
 =?us-ascii?Q?uyHrhpRnGAIYWFfAHefw01QVwryhLl4F/p2FxxZ5WJ2mJk8iLma6uzFa9nse?=
 =?us-ascii?Q?KDIQcCRrG9o4DskmRPMDf1PaNxx8TvwULUPJB0jwTMsE0RkZQnTZYU69eX3J?=
 =?us-ascii?Q?DTJiamg3E5I0LV9zQ7KUNLWj7+scC2fn2wUO2D+w6NK2kvcb0lvj02l6UkTc?=
 =?us-ascii?Q?X7jKgFI4/1/bAGQetuBuvx+ircaAenX1Iq6FMnRYQcgdor2MWhUDTqFKizIA?=
 =?us-ascii?Q?vJmD0Pht5I+lSm+VVTECa5eMOZE6H/UwUgnXBgFiR+SdXv8DEnEnO9a+9Ujl?=
 =?us-ascii?Q?fTzsLsC/NZI0DsiAFIBO+4w+7SMolqtyX9A00a9XgVJOp0yXxu2QqO44FHlF?=
 =?us-ascii?Q?F5kOApjBfLOwHK4UEafL48ADf1hzQpNZPMIk6R2fhwlKEIUMoSNqHn4cTPxl?=
 =?us-ascii?Q?znJlbuU5Ch+3Eejo3q7yZqrX3ozlPCo0nBxc8d/f9Cr9yddhddHSyXN4+eBq?=
 =?us-ascii?Q?1K8vM06RHw5aht/nrdIYWUbgLh/jYAL7eVKdCjw67lWNVVQn+anrn3l19WdD?=
 =?us-ascii?Q?BSnlzXwqrv/YfQoqXhsDx+EYQ9FcwydQzXtPK0D5bSt8yOGcjkm9NRk++zQ6?=
 =?us-ascii?Q?K5aUj8NJxT+OVBPsX2TS4htXjJaFpFkDZIIIo3/5K+GVBWGmqOwVOybPuki7?=
 =?us-ascii?Q?iI62pGuhOEA82Yro5WGvlkvleuez4YsUAy/C9hO+W3hCWvzy7fg3ZN0wgqkG?=
 =?us-ascii?Q?ptHYclhyF3Q=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?9YO2VNtN7/AVkNY5N+N6bpbx5DVFYyJdxIshjK2kTpMeuaOdcSF5l7noHEF1?=
 =?us-ascii?Q?s+lB5UEncua+s5Drg3oPC44ZKgxdHC7EQ1mmSbi+XEq4qFKNNVBpiRWSIfc/?=
 =?us-ascii?Q?8ywQrj440x8YBHiXj4uZB0QE+J1KktuhiJc4bflyorZLYXXCNTQlvOTv371c?=
 =?us-ascii?Q?ASDGOoCEv3wTgUSySdjTbUQQGWvJC0NQpKSsq2qJNstew84LYBuDpBk3uV4o?=
 =?us-ascii?Q?vBenXfKllbuWTEDAUQSxwockvdu2HZ5HxpgplNGCWZ7znKBO2Us7KIHdhBAe?=
 =?us-ascii?Q?TCX53Fa2wFwLETR5Ho0D0sOXqpILTIZlgHisolBKChaVQ1AKIqqsvk1hmIgd?=
 =?us-ascii?Q?YE6/iB4CEGVROiDFPAO5TfADkkrbbKpGKD5A/XCbSSUrHrrkqIUnPM/LzYXQ?=
 =?us-ascii?Q?WGT0sXGTpAAVusd7OCVZF7nEWNxNPvf9OafKMixxZg+5lm9hMrGaDiXZ7U/0?=
 =?us-ascii?Q?bWiQu0xeLBXSVpmNEob1HkW8KfUJ1e3A8+quycFN8fJOn5cfpnSW3FEqOAjC?=
 =?us-ascii?Q?JgfkhIRa6APiEb2G4je21c6BWKbOX5cOHZDHFENP3jL5g+YoyyU1LJz0NoX8?=
 =?us-ascii?Q?mASc/SCKxHdg3dyOiFa2V+Xpjd+N2LutqqAwhQg4IORPN9sNWSwzKWeX8TPJ?=
 =?us-ascii?Q?OYNp+31ak76mDNFtIe0GgR/CPpX7wrNktItOo5t05HaCglof/SdPTIbMFvnQ?=
 =?us-ascii?Q?dIlVEWzu0f1mZZgQUsT1aBY9Hx24N4Kx5QcmLxuijEYIEebO87J8trQkpOC6?=
 =?us-ascii?Q?5HvTn80xxmbnBR4Z8s48Qux7dO4liJ+EP9gA8N10i8HYKFz6FU5y6aWdKBDu?=
 =?us-ascii?Q?F2nCo6aUF13uff4b9pX53OdttabCsWvQhcMi73AjQz70ijVhIZRi5rD81caI?=
 =?us-ascii?Q?qzAmnxy0fXs8ZFjYivEVLHNmcYoWZVTCFLm9h9ZlCYQajTaL3WZ2b4bBYqGY?=
 =?us-ascii?Q?mE3YlmZLwZtHu8pjWIHa8Vu9ugDe14ebg5WRs5a83zohvO7s4Sb4LfCpMic1?=
 =?us-ascii?Q?IpBv8kPo4agNFbf1H2TyXz5QyQaAkHqbPjJgR2bgQJ8ELYUjejyvmEhrmoEJ?=
 =?us-ascii?Q?cle6p7D1vIfzHtVjImdzimXsTUYCsAKTGPmt140QMNxPK7rxy96x1wl3+GfE?=
 =?us-ascii?Q?2QmAUir2xSQdsVPQXgP+rTTiGOpzo02zLXIOySsQlKBQPfcSP0MVBNdZmxpU?=
 =?us-ascii?Q?KY1LAWASYTztVwsHLEbLnBvuORa0/G0/n1GbQA1BBOj9PkqnwENbff4O7HYX?=
 =?us-ascii?Q?n/06d/f2gFt8Gr7mnZ6gme2FoyHeKWUKi0gX2Yeoawx+x9szqxzDkBmWGxM8?=
 =?us-ascii?Q?R24cd960+95kkj5RLQyuLq+qQSfIut3CnDpnavZuMCT8M7VanWjlKpxbVBmH?=
 =?us-ascii?Q?9ZdLMvbeCVO22byX6zJ/TqPCtJxTr4zQCRF5JSAHjnClMwsB+zPNa8RuDdCD?=
 =?us-ascii?Q?ozo2sXZqvbCbHoDATIse33PWDM4HV99uQGVFvcLv2sGGvcSNU4Qq3K73wuEo?=
 =?us-ascii?Q?rAyxsA9mNo4oh0K+wFkx6BNR032gCcNqav90jaUAoi5RrDp9pRWy4nuuK/ZR?=
 =?us-ascii?Q?TKRZ0lKjkgxNLtP0ngU=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d3d1beeb-870b-4064-522c-08ddf0616235
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 11:58:40.8152
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NOBo5qiUePOEw1x7YNat0KXcE5eLDbKYD5g/dL+or0XOWmfL8YpjCGLIZSmZwreP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8709

On Wed, Sep 10, 2025 at 08:26:18AM +0300, Leon Romanovsky wrote:
>  #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
> -#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
>  #define folio_test_highmem(__f)        is_highmem_idx(folio_zonenum(__f))
>  #else
>  PAGEFLAG_FALSE(HighMem, highmem)
>  #endif
> +#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))

Yeah, that's what I imagined, and I'd make it a static inline

static inline bool PhysHighMem(phys_addr_t phys)

These existing macros are old fashioned imho.

Jason


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:11:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:11:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118228.1464088 (Exim 4.92)
	(envelope-from )
	id 1uwKbS-0002KL-Hu; Wed, 10 Sep 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 1118228.1464088; Wed, 10 Sep 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 1uwKbS-0002KE-Dl; Wed, 10 Sep 2025 13:11:14 +0000
Received: by outflank-mailman (input) for mailman id 1118228;
 Wed, 10 Sep 2025 13:11: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 1uwKbQ-0002K8-Ol
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:11:12 +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 9eabe3bb-8e47-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 15:11:10 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-45b4d89217aso45148055e9.2
 for ; Wed, 10 Sep 2025 06:11:10 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7522387acsm6812647f8f.40.2025.09.10.06.11.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 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: 9eabe3bb-8e47-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757509870; x=1758114670; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ow6FD6a4zTTUiQDCDP70Lj/7acZG5OGLgjzi9bSr5XY=;
        b=h2IS1YjT/ouHX7FU6qziHeMG9kqefrFKOdezvNKL4IBygof/rkItWek/JZn/wGBRSy
         arHKxdZQjdkR18/GaVt8xtoic1PDWj0SVmalSr7JZmj81K3YTFm4isUySqKvjkI6ZdpT
         XmJC7TAr1xzVnbW6mU8zUAQd5TR/a6Pj8sRbA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757509870; x=1758114670;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ow6FD6a4zTTUiQDCDP70Lj/7acZG5OGLgjzi9bSr5XY=;
        b=BuBjzXY0OaZUouLJvb6aH9eeLRqv3m1WBuuInOsAOoTQ1Hwvi8CMXxXiaxxoyXA9nJ
         6181ySXBw+WmmbsRMuxz/zoTFgMF1GDWLoqc7eKor/A72qreYt1vAnuTWJ4U3kOlHi71
         A5rLRK05QUmqtB5tZ0xUiUA+2b2Pt+6vu6zLF6685S3H/H5Ww7sJ6whlUX+6cqyjy5lf
         dWEWetWaMoaOkCLhV9LzqCU6zDmqNbZMMyRlQRfNjPWX+w0Ih6TbmBssn06/5DAtF6t2
         u4vlezA628dQS9/bQiT+L9A8YkekttUWr6cYLe15J6lyAPl4VDNaNZ7y7DPvS27h8FgK
         0WWA==
X-Gm-Message-State: AOJu0YyO3JO0279krNAGTh9NaEQ5t3EqgeBYhImPOE9+y10rUu+ikz+X
	z+hXPQUSo0ziPPlMt+snPgl3gWhUyTNtZvJxaoOoE8Xu6eUotn9rwXFsJiJsy3wb9dc=
X-Gm-Gg: ASbGncvFRuwkl/yUjoWIKN6PU0dooAP3HLToTFhdje/BjEv6UCziaRDnwgc7+fQev4N
	iF21sYK53WvJaAVFRdAdcB+e7nWTxc26hkIwm2adcVqJUg+E2gOfTtbAeD50oFEyPuZDBX1Qxjz
	a3xkN96ZvsCxNc+GVnygEehp2anMvi2jx5+0cVG5Gi+hyP1+cqyXFk/06uK3ougy2slpC7sWti1
	OLo/fUA5H2GiMGywvMqyyYmoRyj07ffVU4cnJ8+WZgm5AkUkfa3eqBzEdTF6FHa+P6aPcECa5UG
	263J4IH1xoTXE1OGMEdT+wjnhg95Fu/KRXJ3bh/J0BfV1HJMiUmQnk4sAI8Iv+yRaJ/mYvpIRUO
	P4Vz4SHB5MG6uyLl/VKjl8+NBjuHReog0a4gDnb9u/+9RVDC6vqA2N0g7IhW/rNqo2b5o
X-Google-Smtp-Source: AGHT+IHJUNflVznGtQBQ66yq6dLaLbNIShPzRyn6PiH6nnnqCwWViqokKPBtikjL0Atq7QvglQwCog==
X-Received: by 2002:a05:600c:314b:b0:45d:e111:de7e with SMTP id 5b1f17b1804b1-45de111df85mr121329225e9.19.1757509869878;
        Wed, 10 Sep 2025 06:11:09 -0700 (PDT)
Message-ID: <2c91d873-7f13-4f78-a0d8-8f67f06c88b2@citrix.com>
Date: Wed, 10 Sep 2025 14:11:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CI: Switch the alpine containers to be non-root
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Xen-devel ,
 Anthony PERARD ,
 Stefano Stabellini , Jan Beulich 
References: <20250910113416.1835988-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 10/09/2025 12:57 pm, Marek Marczykowski-Górecki wrote:
> On Wed, Sep 10, 2025 at 12:34:16PM +0100, Andrew Cooper wrote:
>> Testing on staging-4.19 is hitting a reliable failure, caused by alpine/3.18
>> being a root build container, but debian/12-x86_64 being a non-root test
>> container.  Specifically, the test container can't copy XEN_PAGING_DIR and
>> XEN_DUMP_DIR (both 700) from the build root in order to construct the initrd.
>>
>> staging-4.20 and later do not repack the initrd in this way, so are not
>> affected.
>>
>> Switch both alpine containers to being non-root.  This is still slightly
>> fragile, but better than depending on using root containers for both.
> This will likely explode done as is...
>
> First, grub.cfg is not writable anymore:
> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11305545275#L170
>
> I'm not sure what 'user' gets remapped to here, but the whole container
> is running under rootless podman, as gitlab-runner user. Files on the
> host are owned by gitlab-runner user.
>
> But second, repacking initrd as non-root, without any extra care will
> result in broken initrd. At the very least /sbin/mount is suid root -
> when repacked as normal user, it will end up as suid to non-root,
> breaking it quite effectively. I've run into this issue when needing to
> repack rootfs anyway and ended up using fakeroot (again):
> https://gitlab.com/xen-project/people/marmarek/xen/-/commit/bab939159127a9f8e56e119c1fa553c7bbb6d4f7
>
> At least your "CI: Create initrd fragments explicitly as root" patch may
> need backporting, but TBH I'm not sure if that's enough. /dev will
> likely be messed up too.

There's a lot of collateral damage here.  Summarising things a little.

* We cannot change the root-ness of alpine/3.18-arm64v8.  Like
xilinx-xenial, it does need root to drive real hardware

* We can change the root-ness of alpine/3.18.  It is only used as a
build container, not a test container.

* Contrary to my previous analysis, we have backported the test-artefact
CPIO work to 4.19, but not the build step CPIO archive.


And, what to do:

* We really do need to be rootless in the build containers.  Therefore I
think we need to split alpine/3.18-arm64v8 in two, and when bumping to
the next version is the obvious point to do this.  We should make a
dedicated qubes container similar to xilinx-xenial, and separate it from
the build step.

* I should see about backporting the build step CPIO archive.  I'm
beginning to think that was an oversight of mine, because I didn't
intend to end up with a split like this.  This should avoid the step
causing us problems here.

* I'm very inclined to change the root-ness of alpine/3.18.  Testing
suggests this is fine.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:26:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:26:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118245.1464097 (Exim 4.92)
	(envelope-from )
	id 1uwKqK-00046I-OL; Wed, 10 Sep 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 1118245.1464097; Wed, 10 Sep 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 1uwKqK-00046B-KZ; Wed, 10 Sep 2025 13:26:36 +0000
Received: by outflank-mailman (input) for mailman id 1118245;
 Wed, 10 Sep 2025 13:26: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 1uwKqI-000465-V6
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:26: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 c48b40d1-8e49-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 15:26:33 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-45dd505a1dfso43374305e9.2
 for ; Wed, 10 Sep 2025 06:26:33 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45df81c72edsm28526685e9.1.2025.09.10.06.26.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 06:26: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: c48b40d1-8e49-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757510792; x=1758115592; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UyO9lwvUP4MF7hak4fj1iSeZE9v5FUGZpfGxCuN8ZIk=;
        b=DEb5ls23JUdtffuGkzoN/YkD529J+hUyvmybD+ic2gpbu1pYhIpAzP5/HugPDrQCZw
         5pZ9iI9HssnK+8jR/XA/p9DS/+xsKaIvpYNihFPhwdlMhZs0pvOrw2nqgIpw9idpsJz5
         wehlOPqFSA2IpPcXhWOj98N565puuVr6lANuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757510792; x=1758115592;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UyO9lwvUP4MF7hak4fj1iSeZE9v5FUGZpfGxCuN8ZIk=;
        b=WcguUq3g2kLhvCjFFbG82x1eIXZc+0L9/DiSizVWtzkop4rOBuMKRvseOU2DsEfQIH
         2aIFdz412MXS6SQgrYw33UeZWjXMBibW6kI9+h1KaPOSEfJy8lkvr6sxpZMh79TQZtvA
         BRYRaCujboGevMdzMBy4A8o1h+EJg1MPTbwnXAFMJLlCP1ukF4VvOy7cL3WVtsklelRZ
         FPY4AxZSnn6k6LivBKqIqfNJZXhAbmj8LF6kTs768KBxORHzlogfq82u1jN4vXBKwp2s
         Lh4y6uC/vJlROFnerpkAomKhnwv9hP2O6kjJEBlqKi2FNf9XDCj8i5rKqyYGNTsUEJgx
         RxYQ==
X-Forwarded-Encrypted: i=1; AJvYcCXzQKmUkaxz0RrqPBzOCtzX5hDfgzYIdRfdoV/rEhN1Pyt5pQHk/ecmFBl+PtVGQAUvQ8GUGH8QJDY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyECbogz3RK3XlvNYSUJ1haCfhP/VD55/fClRN1J87qhURZvDgt
	Hp0hgFdNnUZwCdhOa5ZubpMiYg2QVFHpx/FMiRzJ8kN2s6ZuTw35krkCQWgHXgRBIxs=
X-Gm-Gg: ASbGncug2wimYbnAXst2avB7fH+6DPYJdSOU9jPsCWtdfZ09BEmrLHWBpEXabmqVJpl
	8Cew1F9EWaq5EWbhMnZzIPPX+iPxcnd2t58crR2xsxn/HNGxHRr0wFaeJ7Xe7tNbwlU/GND6R0E
	r4qxnihwUTNdPvJlcujlx8wQJJX+rGaH/wcco571PHvmL7p+AIo3QeSOCBadrnHHXgkxrZpKCOL
	FkrxaVAUXZ8PcE0Qg81mXwjIYQrip/Tw3JAWLdBsbqLdStfOvww1b6Iti1evrTbZ5ZUDu2Yu17b
	4rjJx9xBwzpd0rDAq2LT10T1dInam/YAnek4JPX7t0CEH25WBvbqZokNn3kqNz0SP+bzg045Ztm
	yPD6cSxMvpI+Uq9G1Ry/IIE3eUhgwzQ5i6tMDT6SQX2513iJ/WIbpg07rJYwrSSB19Kgv4X0HvH
	V3o7V/SlYts+T0SQ==
X-Google-Smtp-Source: AGHT+IGElgGFoDyljSjCkEbC4J1Xam49FWC4hAq0w5OnD+Olq5O6YGdFMZOMWyveohq5E1L1RRfy1A==
X-Received: by 2002:a05:600c:474e:b0:456:1b6f:c888 with SMTP id 5b1f17b1804b1-45dddecd894mr133709535e9.23.1757510792455;
        Wed, 10 Sep 2025 06:26:32 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 14:26:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/IO-APIC: drop setup_ioapic_ids_from_mpc()
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "consulting@bugseng.com" 
References: 
 <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@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: <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/09/2025 8:55 am, Jan Beulich wrote:
> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
> said, the function is dead logic as well: All 64-bit capable Intel systems
> have (at least) xAPIC (if not x2APIC).
>
> Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
> code; we didn't accept that yet, but - where possible - we probably would
> better follow it). Depending on one's reading, this code may actually be a
> violation of rule 2.1 (unreachable), which we did accept:
>
> "Code is unreachable if, ..., there is no combination of program inputs
>  that can cause it to be executed."
>
> Otoh it's "only" __init code.
>
> Signed-off-by: Jan Beulich 

The code change is fine, but the commit message should be first
paragraph only.

The first paragraph is plenty of justification to make the change,
irrespective of anything else.

The other 3 paragraphs are musings on an area of MISRA where which is
unclear, or even disputed.  The code here is statically reachable,
dynamically unreachable, and trying to argue this in terms of dead or
unreachability detracts from an otherwise clear patch.

With a very strong preference to have the commit message be only the
first paragraph, Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:31:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:31:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118257.1464106 (Exim 4.92)
	(envelope-from )
	id 1uwKut-0005i7-6n; Wed, 10 Sep 2025 13:31:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118257.1464106; Wed, 10 Sep 2025 13: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 1uwKut-0005i0-3r; Wed, 10 Sep 2025 13:31:19 +0000
Received: by outflank-mailman (input) for mailman id 1118257;
 Wed, 10 Sep 2025 13: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 1uwKur-0005hu-6o
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:31:17 +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 6d2f3ba0-8e4a-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 15:31:16 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3df726ecff3so3603385f8f.3
 for ; Wed, 10 Sep 2025 06:31:16 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7521ca22esm7509346f8f.18.2025.09.10.06.31.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 06:31: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: 6d2f3ba0-8e4a-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757511075; x=1758115875; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3MkGfz3VUq3hV2r7iXh77w3Mca/dAE9rQocE9HyDvFg=;
        b=exJBG9wVJvhOnxBrqS3gB84gCBd0Q4nVNWfodNsYbkw3oSoRBcXf0kdWYU45LU3UpJ
         eGQh4DJcGbIahYlzpfzjPiyHG4VOnbZ2+RSH+7mItw1ooY1SbNbjb/PseNd4rFhYsUjv
         bNhx4Uwi8a+SWwiNGbuhj9CNJdXAd0+UHmyEM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757511075; x=1758115875;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3MkGfz3VUq3hV2r7iXh77w3Mca/dAE9rQocE9HyDvFg=;
        b=U8vAFJrzPb+GG7eFqkg2MewouvUx87nIKKdjX8r0AYuvN8VcZ5YfHjOcO40CdwbS87
         7/xTkvlbXHAJO169NNgw17G6DobOmgDzu2xX57zTc+hCZRVkbovuGVbFDCFUf+QnHML9
         nWUL0yxyDwQHognC2AB5to7Q8gr2iSwOQTBhhS7+yphsqkB0D+oT4iCXQwgJF5D2TEwu
         uLOGOegSVCd/b+29kK5r2tvyLltkk9KWNbH9w7N+tBdYPc/Qn6WfVlKGhsAaKOfa0tcX
         m5vdyv6Oe2gKj2dn8yRQhrohxktgLGS/Jkut3kC/2xNwp/HBjqq6iTwfMFrjQYIlH1ek
         qfxA==
X-Forwarded-Encrypted: i=1; AJvYcCWQoL+s9hFj+RdkOYbuzLea8T/CRo5pNKiULFsi6jbwjnCmSTh2hg5/Ho+uoVBFH0LRPbV0dIp5At0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEEt6k3BfWqQPLaH5Lw5R3FN9wWNNe7bbSAhOsQzQ4mGwQQciZ
	GthHdevBNUi0f2oebMn1mQe2DVJMptfgZ4EFvzhXnUIk9f8Aknqd8dmmI2haabKrpe8=
X-Gm-Gg: ASbGncv6HZ/f9nQqHgu5eWeNO7Gia0I1VUHCg+w+TiIWplz49+l5Ih60kCg8tKwFhS7
	J1nMTsKPARfCwi76PUSBbaXpHWFWa+1K4TioOs3thKGt29qhDriX5M0xtgP8nwOQkzbhoZQC7Pt
	Wpowmeux5TYD7+cQzyI+DKaGek0PagRLpe964rTAGJ4AOalaGgtctAJ1TZKgMz34FRobaW5lSQO
	YAWym9P4kE/BmpurUkZTRTHhuqx8wpLI1zFIuUZDWETnMEl8+ehZYmrLPB7B47JwUcDP96tqepK
	7XmR6VyKH0HXSLf1rwdMwO64qCyjXLX0yAPKYgh6/DpOOBOOxkPjecSNY3aJsb4wN83cYaZErGb
	0BjJiBFCHODadN4S9FxjU4Mx3v3yfQr5B8n4SwpqbqpTE7jKTaZPKJDQ1ff1KEFeYSP35
X-Google-Smtp-Source: AGHT+IETzShO/bkLQIEEBmlENUpxbqlf3kZMYCjRdhPOSyGuCiy/UYsCGFCFoO0oZlp+cnHoaknRUw==
X-Received: by 2002:a05:6000:26d2:b0:3df:b9e7:35ba with SMTP id ffacd0b85a97d-3e6440f0674mr12375342f8f.57.1757511075270;
        Wed, 10 Sep 2025 06:31:15 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 14:31:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/IO-APIC: drop io_apic_get_unique_id()
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "consulting@bugseng.com" 
References: 
 <80c035e0-54f6-4632-a5c2-a10d2c1c8422@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: <80c035e0-54f6-4632-a5c2-a10d2c1c8422@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/09/2025 8:56 am, Jan Beulich wrote:
> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
> said, the function is dead logic as well: All 64-bit capable Intel systems
> have (at least) xAPIC (if not x2APIC).
>
> Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
> code; we didn't accept that yet, but - where possible - we probably would
> better follow it). Depending on one's reading, this code may actually be a
> violation of rule 2.1 (unreachable), which we did accept:
>
> "Code is unreachable if, ..., there is no combination of program inputs
>  that can cause it to be executed."
>
> Otoh it's "only" __init code.
>
> As this removes the last user of APIC_XAPIC(), remove the macro as well.
>
> Signed-off-by: Jan Beulich 

Same feedback as with the previous patch, albeit about the middle 3
paragraphs.  Again with a strong preference for those to be removed,
Reviewed-by: Andrew Cooper 

I'd not even spotted that APIC_XAPIC() existed.  This being explicit
conformation of where XAPIC starts would have been helpful when doing
archaeology.


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:36:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118269.1464116 (Exim 4.92)
	(envelope-from )
	id 1uwKzg-0006Mx-OQ; Wed, 10 Sep 2025 13:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118269.1464116; Wed, 10 Sep 2025 13: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 1uwKzg-0006Mq-Ln; Wed, 10 Sep 2025 13:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1118269;
 Wed, 10 Sep 2025 13:36:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwKzf-0006Is-GS
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:36:15 +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 1ea233bd-8e4b-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 15:36:13 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-621b8b0893bso8815340a12.2
 for ; Wed, 10 Sep 2025 06:36: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
 4fb4d7f45d1cf-62c0123f23dsm3378742a12.25.2025.09.10.06.36.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 06:36: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: 1ea233bd-8e4b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757511373; x=1758116173; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JmV45LpAXTHcg/3ZeB8mIxSHX3C+aS/dsTEggteiobI=;
        b=TzLwKkpcPFh385jKXiLn775vsKtE3v38eY5Y4HCp9AWeQi5eDw9MrZZGSM//vpnv+U
         78tTJr7K0ir0rG0ofiN8HoOmR4duJW9co1jMTE0J+NVwxQvPdOJqoiNGhJZH4zj1y8qb
         /q3bUXUcWQt0g0wtzjxNrZ7Y9aa8s44wFzk7Zr2PBXln8rjfO48dCEqzK5uICTP33OcU
         o2zKb5CcqXIFcwDK1rhaqMOWEmpJeksCBeQ50w/GxQtP9HNRxqBf8hHBA4hOTMegN5iB
         WC5c/j4iPsiMeU9ArzWj8POcRbGD4lrnuGJbznPa8EDWm59C13V2ibz1Dn+KZgb15MoI
         DN0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757511373; x=1758116173;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JmV45LpAXTHcg/3ZeB8mIxSHX3C+aS/dsTEggteiobI=;
        b=OD32+iGwqgDL3IxQAjMxa2BJ5IQ3qSdpagroMtdmTtn5Wi37+OvYdMeROzjR+J8r2C
         m4ctXIrmXL3kYocPaRkB3xjuYVgiin94q5TdWiq6v1udlAea4SH35SnXN2A3NnEPTSCk
         VxWopZ/5E0kTOsoxwZQBFhZyAQBodSTqZUXs4Dh3N8Pq2hrgqsp3SYM/QIJNa7UH8GmL
         dvfjZ0sG5udXpgIL0qL4Se3GT209KfwjpL7yinlBM3SwSp9A6p36dnL+w+LOk8DzgxKO
         iviD+GhdrALTpHfCN3S7uCyy7RXy7VEcxwrUT/qgJoS58yFW5awfUxItM2WmMmPgkros
         yqUg==
X-Forwarded-Encrypted: i=1; AJvYcCViXW+iDHag+1jVYbk4Kme3Nwl/zJrpzjFbj4bS6n1WUsTTQYlzyM4BW6HTdU3P24hGGezUzFRsuWU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywlu0lndCC4nUL/WiPk7DaSc2euujOnwVdu/pYaPkVidRkqyW4x
	AXr3yoKbc8Z08uOPXpGw1GBdIYbVRaPsJAFa0V/q+MCrtZfytpD62fNloD53B/oK7G/roEJW0KG
	CCrk=
X-Gm-Gg: ASbGncu/xbSriZbRBjVvW3pAwNA/CV3+BMIdOwoyRDtRWw1PQO+uyaM9dbKcpx78PbQ
	G0QoesLpnO+lbbwJadknm5GuBlOeQc4kVWJjq9hsNFL0v48ZrwZCvUeXAqT//3Hrfh8CwaE17bB
	tHsbvMrAaImW8KQ7lxCK3ZDTJcKGhcSYw8ssGhRtndl3pLDK6Ga1bYXu7wVYfBCxdxwec2PXk8j
	V+195UarVQNtaQcTa6AAobKm4mS7e6TDvm1rLAOlUkhU9/TpK/AhMP309JHs1UAYqVPd4xe0GM6
	XQVgL2gn0AzWSIggtvPuRiNVx0Dv9sL6Sxk+34ZKOhzylXFjleUnCuFrFFEPh0b0K3O+Jss6kdV
	6EWDmxSzPW5zrXRdKpOqrblCYrhLs0StUNQ1JTqUTB3M/PNP2nEtgGCbImXCNx0RSBqPuY1fXS2
	Ias9ZC6eMX1CVOIcNupw==
X-Google-Smtp-Source: AGHT+IHmJrFbeQw21awAqUVBng12qFt5BFFbAZ79vsHf38XFsWr01xkzHbLIXZ0Olfs6K8yMLdOJWQ==
X-Received: by 2002:a05:6402:505c:b0:621:ceb4:12fb with SMTP id 4fb4d7f45d1cf-6237ebc6feemr14048594a12.20.1757511373125;
        Wed, 10 Sep 2025 06:36:13 -0700 (PDT)
Message-ID: <3c678b60-4e1d-4c51-bfe4-efe3acee4e8f@suse.com>
Date: Wed, 10 Sep 2025 15:36:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/IO-APIC: drop setup_ioapic_ids_from_mpc()
To: Andrew Cooper ,
 Oleksii Kurochko 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "consulting@bugseng.com" ,
 "xen-devel@lists.xenproject.org" 
References: 
 <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@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.09.2025 15:26, Andrew Cooper wrote:
> On 03/09/2025 8:55 am, Jan Beulich wrote:
>> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
>> said, the function is dead logic as well: All 64-bit capable Intel systems
>> have (at least) xAPIC (if not x2APIC).
>>
>> Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
>> code; we didn't accept that yet, but - where possible - we probably would
>> better follow it). Depending on one's reading, this code may actually be a
>> violation of rule 2.1 (unreachable), which we did accept:
>>
>> "Code is unreachable if, ..., there is no combination of program inputs
>>  that can cause it to be executed."
>>
>> Otoh it's "only" __init code.
>>
>> Signed-off-by: Jan Beulich 
> 
> The code change is fine, but the commit message should be first
> paragraph only.
> 
> The first paragraph is plenty of justification to make the change,
> irrespective of anything else.

Well. I wouldn't have added the other parts if we weren't where we are in
the release cycle. Strictly speaking, with them dropped I can't put these
two patches in right now. Oleksii, may I ask for your view please (on
both of the patches, as they're both similar in this regard)?

> The other 3 paragraphs are musings on an area of MISRA where which is
> unclear, or even disputed.  The code here is statically reachable,
> dynamically unreachable, and trying to argue this in terms of dead or
> unreachability detracts from an otherwise clear patch.
> 
> With a very strong preference to have the commit message be only the
> first paragraph, Reviewed-by: Andrew Cooper 

Thanks (also for the one for patch 2).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:43:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:43:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118289.1464126 (Exim 4.92)
	(envelope-from )
	id 1uwL71-00087E-J2; Wed, 10 Sep 2025 13:43:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118289.1464126; Wed, 10 Sep 2025 13: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 1uwL71-000877-GP; Wed, 10 Sep 2025 13:43:51 +0000
Received: by outflank-mailman (input) for mailman id 1118289;
 Wed, 10 Sep 2025 13: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 1uwL70-00085n-R8
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:43:50 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2a7444f4-8e4c-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 15:43:43 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-625e1dfc43dso7409961a12.1
 for ; Wed, 10 Sep 2025 06:43: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-b078346526fsm162617066b.109.2025.09.10.06.43.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 06:43: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: 2a7444f4-8e4c-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757511822; x=1758116622; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vbwMiLvCK9iCoMikXzhNk8c+qVgPMbmENZwXNlWUKN8=;
        b=CrYXY6DoKUJBAXu0JlXOlTVE2sFTdhna2IdRSr2pOE8SWrE91C31ahloy19zJoziLS
         4oPFwXlM5gfZ5w8kGUDZhUWZMhG6caiZYlHU9oQ5OVd2y83b7BxAk7wDdNqdKR9h0cKi
         vV/pQ4P+HPlKh4BAxElivqzQ5DXMZF+tL8CKEJRdgZ9K/74VD2owNeT5Hh1q/SvBqXbL
         vWsqFYFYbG3Eoyl0JRi8hkqCCdPQO7wT5mSH0ck/EmEfcGQsKzH2i95X3dEE1wHW2leI
         BRK/dTxZ1vjGZz2yWiVbaOsW8p97544lRuKrLj172JWoU1gHwwEkZ/9E2R+dwhMmfefA
         8Pmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757511822; x=1758116622;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vbwMiLvCK9iCoMikXzhNk8c+qVgPMbmENZwXNlWUKN8=;
        b=IvLYfHaqQ9sq/FLRpHmrK91DMGgHluP3KcDy64rUtwYA3wFjOK0VmSI5t55GZK0kQy
         9wfRJR5+IjFR3Z3sBHvU4j1doRI8RVfYkbgcx3uIM0jiBicG9EP//9tALx3I51Ur/wy4
         qvGel5MXdIc8D8W+bCdktL7T1rMEmhGPkNYRsCAip0iUqxmcfjKNaH0yV5iKK4BrIniB
         XYNmYEq6wXHnh0rzbUqwi1i9sOkyI55oHzUrK9MYs60iltVG8b1ZO4rxubfdzPr6vkMa
         gTN3M38m2rBlzAsO9IPdD3eAglUwADbJwyagQnbawQ8+fOBqOZXginiy+9A/+qfH8//d
         sf5Q==
X-Forwarded-Encrypted: i=1; AJvYcCXT6Fnsle5UZL8+/Tk1vrjFuBzUoIho5bmBaNXAKahCjtRJ1lGak/E1xkW8ldzl7eRPC//pNOeAijI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxk5Ksu3Ts7TpN2pTIeAFiJ0pR/YHcnysA+DNHp4HTovUJNmRvn
	PJEa+flqHsY28qKIw3gW3Ege36iWfDymwJHggfi2HxFZ4r7jJrtLTb29OSIqoxmtDA==
X-Gm-Gg: ASbGncvYxiAtn77R1+7zkdNYZwlj0qmuJZZVMh+pnULKJHzP1cky9TIU1SfxP0P0Y2t
	hXLbWAv1NS1yA8eIiUjGE49CizbncDZk5GaUqiQL5dc4kih4mD+Wv8U7t5LSlup6qzmVxRIOfnB
	qAuGdNykmJrGP/V1R8sP21wof41R9d5ZAUI2JzNSYn4K2Ot/MdHrLt6nY3d54/rPmJRXyR5trNk
	9FUYbP0W5ExkSfMxNN+4Z9UsHYnTz8Rir2/XFByemCV7pbsqHlhd7cSRsAJ7pS9xGxoYy9Kd8lE
	OqCYNgVpR6JKOAx5GdePAt4Fy/67zaZmwES+uYGwGbmlw09YVf0gBJ3mponfyrVZC73KwCnpZ/0
	MWfd94W58CTbI3DP2owwaUG8LcjxCD7N8w/I1lNUz+w7+chfOTk9Ae+4bQJhE5Hr+nzKfw0Scn3
	iugvn9emQsliEVvRdo/w==
X-Google-Smtp-Source: AGHT+IENTcR0ugA8owAojjjzpCJeEJjokdSTdokjtEuHsOcKeyTXZYGl91Kf+hnA08d3UZkaRA2P6g==
X-Received: by 2002:a17:906:7304:b0:b04:5b3d:c31f with SMTP id a640c23a62f3a-b04b1698bbbmr1416843266b.49.1757511822458;
        Wed, 10 Sep 2025 06:43:42 -0700 (PDT)
Message-ID: <5d639a3a-6f15-4d78-8f41-47a4f66820a5@suse.com>
Date: Wed, 10 Sep 2025 15:43:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 26/26] xen/domctl: wrap common/domctl.c with
 CONFIG_MGMT_HYPERCALLS
To: Stefano Stabellini 
Cc: ray.huang@amd.com, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Penny Zheng 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-27-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: <20250910073827.3622177-27-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Wrap domctl hypercall def and domctl.o with CONFIG_MGMT_HYPERCALLS,
> and remove all #ifdef CONFIG_MGMT_HYPERCALLS wrappings in common/domctl.c
> With MGMT_HYPERCALLS=n, we need to provide stub for
> domctl_lock_{acquire,release}(), as it may be invoked by hvm_set_param().
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - remove stub in common/domctl.c
> - combine the original commit of "xen/domctl: provide stub for
>  domctl_lock_{acquire,release}"
> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
> ---
>  xen/common/Kconfig           |  2 +-
>  xen/common/Makefile          |  2 +-
>  xen/common/domctl.c          | 24 ------------------------
>  xen/include/hypercall-defs.c |  4 +++-
>  xen/include/xen/domain.h     |  9 +++++++++
>  5 files changed, 14 insertions(+), 27 deletions(-)

Please see all the removals of #ifdef-s below for why I was arguing towards
the Kconfig control wanting to (re)gain its prompt last. These #ifdef-s will
have been added by earlier patches in the series (which I didn't look at
yet), and that kind of churn could have been avoided.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:47:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:47:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118303.1464137 (Exim 4.92)
	(envelope-from )
	id 1uwLAw-0000Lw-3G; Wed, 10 Sep 2025 13:47:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118303.1464137; Wed, 10 Sep 2025 13:47: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 1uwLAv-0000Lp-Vn; Wed, 10 Sep 2025 13:47:53 +0000
Received: by outflank-mailman (input) for mailman id 1118303;
 Wed, 10 Sep 2025 13:47: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 1uwLAu-0000Lg-FL
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:47:52 +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 bdafa676-8e4c-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 15:47:50 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b0785be64f5so126641766b.1
 for ; Wed, 10 Sep 2025 06:47: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
 a640c23a62f3a-b0783047e17sm169786766b.20.2025.09.10.06.47.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 06:47: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: bdafa676-8e4c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757512069; x=1758116869; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KlzZsKgh7DGZHhEv5nXA4wvUDKRfHz4AixNx6MnueCc=;
        b=JGxN3Drgee6QxwkNLy5+1EiZiRI59FWa0AmqHB4g+6eSYLQz6bqkj5jbrrKDRABtuS
         OUCIeE7kIglfhMLB8nnYBNhC7hhOWCvi7ggFycgvVEZT6TSVn8kx/AUTuWHks+dE1HYm
         mM2AIWIKgWE28AeQdeQozgNvjW3ilw4lx2EwzmOM6gpsHsEv0po7wyTjU4RUylVfg3Bq
         wbABCaTluxCVCkGMlGSsn9p5eQVYojg5tUnNrO7gLHus5WE+8es8QqNjm7o9e6Zv5fBX
         nXCfnZ12bIzF2qFUvKyiKkMAv7H5l2Bs5DVwJGujrUzVO2tU7PNwv+3NcgMyM4vJxSPu
         rFcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757512069; x=1758116869;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KlzZsKgh7DGZHhEv5nXA4wvUDKRfHz4AixNx6MnueCc=;
        b=ldO9azGoGWbmGII+mxoT02UcJc0goJKNhDWNnZdMGGZM9PecK6lRhsrV+JiIHsfcHJ
         ON33SjZ8vDK0gD/WIys6h7Tco4a/8VuNZ3XS/tu6hSsj95xWz87N1E1NbQKoxgjB7+BS
         WRmEtillRGietuKzt8UNvNKtUh/Lm3xI6UUn5YrnoMLcVsADF/NNedoYkC9Lm/lS9nG9
         CvoW4fC6hscb++BK4jHViRGuqhXXSkGbf6op3fU8FC/Zvs7T0AAVp7Ct71Z4dMQJFb8Y
         pjdxg6438HAl/59UXmfQH/YesIPI/lBHaJalWVU4DKsOSPfLuSwBr72AYm83JHFWSb+2
         GnAw==
X-Forwarded-Encrypted: i=1; AJvYcCXe09NU6HTeIkUHxvlLwha+urGUFJNQT0M4G6lct9rJjnWERmrQWJ8wd6isZHll3EnTewxdO0u3EJc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8lQ5rcfNo76FAZ9yLgp0NGDV1OG+aNocCz/Glq3ROOVnWk5rX
	9Iq+aI8P353gartRUIjUWjxO2BPZ+Dp+VbEvlXSgBKIDBV452iI0jkWeUkSBMsK2TbbiyC+jwPm
	slDk=
X-Gm-Gg: ASbGncswWsy8PrkLml50XRTl1BvfYSiwZs0HJM62AOeY9OCbmjFpf07XNqlZu6+BbEr
	kv7NYSoVWkV3kWy7R5fob5wsmN4f92G85mn1kT6zP9cMjb6tl8jElvNsynrSb5jcdt0DqMiwh42
	GEdItuL8OyhW42T5ret+SpT74F1nhqhGVH3zWkCB81KD2gZ11vT+DKCUBSg7c7QleXHEcB8qIar
	T77WmYnvdCV5bihgHEmZ3n/SisWpfNpzoLSkRxYEsrkVA0tbXNDjkou78O73e0ws94/o4iqOsNg
	kJLgSMZKVA86wll8XG6CslVkXGjJhfuYJqyMqyjWemA4LV2xaGawsx5KBuXTNfwRp8Aq1VvRA5E
	bwnTII0OOKQuXLjVJWKKoO60yw3V5XmoU7UQeHvoRpMS7X2cJNSFBqOUAJ7c5TK3lVBxGyYw5U1
	rKFmfGzJlLrydHnrENNw==
X-Google-Smtp-Source: AGHT+IEyBEthlLoGAq34tX8u8D0luA+Gxjkwk2O4nub313vlmphDQGwz1/eRTqCkkDmaFOd9EBpRGA==
X-Received: by 2002:a17:907:d27:b0:b07:8930:b09e with SMTP id a640c23a62f3a-b078930b81emr258883966b.20.1757512069477;
        Wed, 10 Sep 2025 06:47:49 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 15:47:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/26] xen/x86: move domctl.o out of 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: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> In order to fix CI error of a randconfig picking both PV_SHIM_EXCLUSIVE=y and
> HVM=y results in hvm.c being built, but domctl.c not being built, which leaves
> a few functions, like domctl_lock_acquire/release() undefined, causing linking
> to fail.
> To fix that, we intend to move domctl.o out of the PV_SHIM_EXCLUSIVE Makefile
> /hypercall-defs section, with this adjustment, we also need to release
> redundant vnuma_destroy() stub definition from PV_SHIM_EXCLUSIVE guardian,
> to not break compilation
> Above change will leave dead code in the shim binary temporarily and will be
> fixed with the introduction of "wrap domctl-op with CONFIG_MGMT_HYPERCALLS".
> 
> Fixes: 568f806cba4c ("xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"")
> Reported-by: Jan Beulich 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - remove paging_domctl hypercall-defs
> ---
>  xen/arch/x86/Makefile        | 2 +-
>  xen/common/Makefile          | 5 +----
>  xen/include/hypercall-defs.c | 4 +---
>  xen/include/xen/domain.h     | 4 ----
>  4 files changed, 3 insertions(+), 12 deletions(-)

So this is still the same patch as before, still at the front of the series.
While I understand Stefano thinks differently, it was my expectation that
the domctl work would follow the sysctl one in (technical) style: First make
necessary arrangements, then expose the option for people to turn it off if
they feel like doing so.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 13:51:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 13:51:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118316.1464148 (Exim 4.92)
	(envelope-from )
	id 1uwLED-00021E-HJ; Wed, 10 Sep 2025 13:51:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118316.1464148; Wed, 10 Sep 2025 13:51: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 1uwLED-000217-Da; Wed, 10 Sep 2025 13:51:17 +0000
Received: by outflank-mailman (input) for mailman id 1118316;
 Wed, 10 Sep 2025 13:51:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwLEC-000211-5p
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 13:51:16 +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 37d07831-8e4d-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 15:51:15 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b04679375f6so1200542466b.2
 for ; Wed, 10 Sep 2025 06:51: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
 a640c23a62f3a-b078346526fsm163544466b.109.2025.09.10.06.51.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 06:51: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: 37d07831-8e4d-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757512274; x=1758117074; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TVHXhZ0yAX2N1bdYBedEiIPo5sSgmt1L2Z+FQJWZj7g=;
        b=ZPgJwL6w/xhNmqAbmD3xyUeKfSXJir23Zu1zdJHCy9gZiyNeiHYtAyw58dJpVpRV8s
         uNR8TQVb4KPpLFs0c6t1aFs13R1qmGmbSJz9Q2xw8/U6ABvx8PIBKiaAKVnZ6mMaaWPD
         fI1c8YBG6k+5ajL/u0enrtG88dOzCuEcpG6rUzhi1SMQWhrw8HaIVZFHR1L7VJ5hS0mw
         SpR8uWFcgbwY8uaKINJ2RS88QQRVqovA/EtECAOwsJm3UFZ7d5e3F3AeFBEql8Q9HtN2
         FhyJbLx82WX++2pVUQEVvOipFUxdcjuZgX6/VKgvbt93QqigwDkxN+WEMcBk1uPH8bap
         Fabg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757512274; x=1758117074;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TVHXhZ0yAX2N1bdYBedEiIPo5sSgmt1L2Z+FQJWZj7g=;
        b=aRpUlOme1hW+aPIF0yIaJ7Pqj/hCdfp1DZGvcurguW7BD5K5e3dqgFEzvC7nPf4uiJ
         AFRmnoYfMsyR91UBzY5rU5SLuB2CakXHCNKOiVSeqiI5ta1HLSMmhnAz6vHuHuldjDED
         gdTJvl3/Ez4cUVakd4igsL88jKtRRhnW7afVH8qQVOzwwgyG+3LupqAPzfOTCuV+C8+q
         SLEmH2TGw65iboSQ6PMqykuBW3qV3BfKzbwv/TgkEP33CcGxH/KHi8gB9mTW1mJ38Upj
         B6T8djI5gpiofDLrwWYlQ/VQ5hsU0HiFlh81bqVICqCb4IC6+PxIlVV946Wmlg5UN3J0
         9j9w==
X-Forwarded-Encrypted: i=1; AJvYcCVbRYAlOS9JCaOauwh3d8jI3kP+2iIvmWLKp8iAcAmuyo++AiK3KutrjDtYaRQNWOTm4vBHvr13u0Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGVbm6+D4xrhiG8kwIYa38zi0acOaPVzQXamqHyEDvR6OPBrCX
	sXI+Fkje4YyS11V6ybQY2v3FB/FBxzineinrGbdzDWVGiFicG0M5GnXtVpOdCfW0Sw==
X-Gm-Gg: ASbGncsTUIR0Yin0dtUOAH3zX4eLzqfc2vpPRHmNwmogQQukkYus+CwGkm629Wy3M/b
	kB29jmaMipLHjPn0ROwR4BqMi8GXWpslw4HKSS7ahcqg8BNx0/lVPflqbCtstyjmFATHbNvQIjz
	bpMicffL3QFz/AhGCrJbnAAPd94lihOBbsTCCayQRi9rH0XIZ1hISvI2UY+7II0LzGLlG29EXDI
	gVftOns0EwxrYrtslsals4tw27d1kZXo1c+u0vdcpI16TfwD4iwJH4rdpW4q4gpw5szUA9uMj/C
	j5s8L1HHcapak72ypcyWSCm03n84ijf2esdpYJUog92Im4ZsOEeBUpPAWw0hYo5i/5dsKou1rIL
	5DZl4hYj2sSpzwRKyKm/gBTIqMCqNo9jdIvWuLkd/3dfZ1KqTSPwAsuidPwmmY90p3rqB+h9Azu
	pSfuYOrn4=
X-Google-Smtp-Source: AGHT+IGWhMkWVShvo7xYCEvZwdzfhjFWU8q6T4f9FgH7chl4nJrGCzxqofwWOvGMi9cfS1i7NCePhA==
X-Received: by 2002:a17:907:970e:b0:afe:ea46:e80b with SMTP id a640c23a62f3a-b04b13c1c4cmr1687302366b.10.1757512274405;
        Wed, 10 Sep 2025 06:51:14 -0700 (PDT)
Message-ID: <7ddbde88-a0d8-4c9f-a3d3-c7331bbecd3a@suse.com>
Date: Wed, 10 Sep 2025 15:51:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/26] xen/xsm: wrap xsm_vm_event_control() with
 CONFIG_VM_EVENT
To: Penny Zheng 
Cc: ray.huang@amd.com, "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-7-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
> it shall be wrapped with it

Isn't this addressing a Misra violation then? Whether it's "unreachable code"
or "dead code" I can't really tell; I don't think I have properly understood
when it is which of the two. (Change looks okay to me, apart from this aspect
of describing it.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 14:08:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 14:08:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118341.1464157 (Exim 4.92)
	(envelope-from )
	id 1uwLUx-0004GD-SK; Wed, 10 Sep 2025 14:08:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118341.1464157; Wed, 10 Sep 2025 14:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwLUx-0004G6-PQ; Wed, 10 Sep 2025 14:08:35 +0000
Received: by outflank-mailman (input) for mailman id 1118341;
 Wed, 10 Sep 2025 14:08: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 1uwLUw-0004G0-13
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 14:08:34 +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 a2538b94-8e4f-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 16:08:32 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-b0787fdb137so128400866b.0
 for ; Wed, 10 Sep 2025 07:08: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
 4fb4d7f45d1cf-62bfef68629sm3471775a12.15.2025.09.10.07.08.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 07:08: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: a2538b94-8e4f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757513312; x=1758118112; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZZws/mfXdszWuaUA7T2svwUlHS5P35/6VJ79GmkU27Q=;
        b=MdCWmcj1L5+Yg9xllsAY5X6Ci+ADLyzUgBWWCTFcpSlCADfsVoylw+l4fIDUjt+kCu
         nATt5FhsZswwjFrJl/Kd/96TEzOaddWYW7sm3BKCJwyQvnw3QEAuRA61+MIHr21g67Xz
         WBdkDDVycYZq+lQ4xSVS23+BPfl3W3OSUemdmh4iFQ0SNjsbs7jSmWf5SJ+LGorlZ2li
         ii/hCxgXBWTkxZnKSlMRHgYhC4+qJOkEGoNsBe7Z8UUIPZpOV0p3JqevuoTssySOjnyN
         X5BBDz2jOpJfF9vj9riezX3AYIagWl24gULN1nL7Cqb4Gd37Z4YZd9pdxDA6UDkBXuQK
         FKDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757513312; x=1758118112;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZZws/mfXdszWuaUA7T2svwUlHS5P35/6VJ79GmkU27Q=;
        b=O/x5ER8pkymANt6I5Rnops0GV3tQquQkK5lYR/v7TNWRKfmnIPlt24yNkefjC8QvUG
         69WPwNeF3sWkfKR6mBTp6a0nUWSkl9H0rKviTi+hGpl7CKpEmNG6CVe9/AfECbFpuasd
         K2eaP+eKS3bDW8k5GJLxoU2Nm5sGJ01tTQuYLR7vNVeUkO6FePpIjtYai0iUmHUwZG1x
         Mah3uOWOb5Uoxz0sHdG5ruJY2syXlC3cOazwsASJXbl9ddKcj32XWNT/kmJWO6dZXxP0
         6bdD4RA6VcnquxqxsVOs6R9YPcMYoAyT0P3KWaA8Uk2qDP9cBhJ5P9CeSYhMnXZgBCt5
         80DA==
X-Forwarded-Encrypted: i=1; AJvYcCUZU5/j4EYLTavW/ZQrD10VKMkw4oXMO6pPo082Sg+85ugxvCKHNolSrNTnrQZ3fwxCsulB8P06+8I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytQBdK8LlctKfSVUE4Keefa0z0PdK9M3ZfRKOIJZceEi5cBgF8
	niQK4I5GLGa5qPO5YXyKXYUo6qKytsxP1Ku5X5J+WMNGokngDv0WzfQK/GfX21ZzvJg9eQ5bWij
	kb0c=
X-Gm-Gg: ASbGnctswmVq/NsY9MFfBekxuQ0wffVg3mLsoa6pnJdO0ZED1ucFyRu/LS6T21ehxdl
	GUd+qw2tizQp9wiWEXPqgsJ9MJZOHy8J+iemzeS4zWyuO66T3OUIwpRgqO5Uq75icaMcyPmZ5fx
	jWxEcRjjRV3GT8H0yQX9rbZWx8qcxgtKNeJN0uJj5O6kxpw+WZ90vTnNAB+F9bvL/71yTFP+r9f
	c3UhHIU1yzQC7Mf4k9pNjbH1vcPCKtmubqlyE9Bbg0bbKbAVK9as7QhaRBlZh6/1ziqWBNx8sIR
	Y6c2Iov0nWu+rffY2k5YkZvsSSOG3MawTu5+/pc/np5COR1JjVO0YYS+2+gtTd/8L7sMCS3A41U
	h12DwVhyYY1Bo9AL1AtG+K2blBaWznsNg39RZ1talYoqQmvsd4e50uBokc3IzRq1EX7ZhrUynMR
	jmymrW3Dok4KJZJtZVNvl0gIUMbz7W
X-Google-Smtp-Source: AGHT+IEYYKaEpHGxVULfQGgkz7zh9AHw+3nhfM1aHWoWlvtsrYeuD8q0X+mmrfV1PCsnclZIIwX52g==
X-Received: by 2002:a17:906:6a23:b0:b04:8d69:6717 with SMTP id a640c23a62f3a-b04b16db0cemr1571092266b.43.1757513311987;
        Wed, 10 Sep 2025 07:08:31 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 16:08:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-4-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Flag PG_log_dirty is for paging log dirty support, not vram tracking support.
> However data structure sh_dirty_vram{} and function paging_log_dirty_range()
> designed for vram tracking support, are guarded with PG_log_dirty.
> We release both from PG_log_dirty, and also move paging_log_dirty_range(),
> remamed with p2m_log_dirty_range(), into p2m.c, where it logically belongs.

Aren't these two independent changes? One to deal with struct sh_dirty_vram,
the other to move and rename paging_log_dirty_range()? Irrespective, in the
interest of making progress:
Acked-by: Jan Beulich 
with ...

> --- a/xen/arch/x86/include/asm/p2m.h
> +++ b/xen/arch/x86/include/asm/p2m.h
> @@ -1110,6 +1110,10 @@ static inline int p2m_entry_modify(struct p2m_domain *p2m, p2m_type_t nt,
>  
>  #endif /* CONFIG_HVM */
>  
> +/* get the dirty bitmap for a specific range of pfns */

... comment style corrected here (happy to do so while committing).

Aiui the patch is independent of the earlier two, and hence could go in ahead
of them. Sadly once again nothing like this is stated anywhere, so please
confirm.

> --- a/xen/arch/x86/include/asm/paging.h
> +++ b/xen/arch/x86/include/asm/paging.h
> @@ -133,13 +133,20 @@ struct paging_mode {
>      (DIV_ROUND_UP(PADDR_BITS - PAGE_SHIFT - (PAGE_SHIFT + 3), \
>                    PAGE_SHIFT - ilog2(sizeof(mfn_t))) + 1)
>  
> -#if PG_log_dirty
> +#ifdef CONFIG_HVM
> +/* VRAM dirty tracking support */
> +struct sh_dirty_vram {
> +    unsigned long begin_pfn;
> +    unsigned long end_pfn;
> +#ifdef CONFIG_SHADOW_PAGING
> +    paddr_t *sl1ma;
> +    uint8_t *dirty_bitmap;
> +    s_time_t last_dirty;
> +#endif
> +};
> +#endif

Subsequently I think we will want to do more cleanup here. Us using a shadow
mode struct also in HAP code is bogus and, afaics, wasteful. The three latter
members are used only by shadow code, so HAP could have its own, smaller
variant of the type. And each type could be private to the hap/ and shadow/
subtrees respectively.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 14:49:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 14:49:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118378.1464171 (Exim 4.92)
	(envelope-from )
	id 1uwM8j-0001id-Uj; Wed, 10 Sep 2025 14:49:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118378.1464171; Wed, 10 Sep 2025 14: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 1uwM8j-0001iW-S5; Wed, 10 Sep 2025 14:49:41 +0000
Received: by outflank-mailman (input) for mailman id 1118378;
 Wed, 10 Sep 2025 14:49: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 1uwM8j-0001iQ-30
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 14:49:41 +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 5f701c97-8e55-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 16:49:37 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by PAXPR03MB7611.eurprd03.prod.outlook.com (2603:10a6:102:205::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 14:49:35 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%6]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 14:49: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: 5f701c97-8e55-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HDw+dv+3KAVp9Q6EJlUnS8077pxd20r64ka/2Hni4D4IG+r0zGpAbixmijj9LyDnaGEV+3vgyOb5W7uxRrbwg4K97juhwNQDst6EtnmlDLV4iZ0fCMx7OtNHW8QcR0YECgK2mGDGdVLfOfcF1bzUdvHQiwurGKF/I/164YdWkLb0SkTeTTz0GMBE8k47RRJ5DcU+dXylFqHWdJX1U3WGFH+wJ5ZF4J0amf4qBQS8Fv9Gx1cdAomlqvJEbrGClHjGrA8vsc24ztyU71ejLd48ve/ptlvzymiWcFvDiZuPgdJSpDmEofOitOwXuW9mJrwBMEgQGXS1zmmRwYh6izSqiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KRaxHGvw2BTA0vfQ5YtYv6Ce4yTniHnIe4jQcbb1m2c=;
 b=TQRtY6Fivz6WYQEnQbeRYkHIhumpEP78l26U/JepveIV7JqT+CFpJfuX+oDsnbccIJyQ8Z6VEZRhwND76LxXJ6jvhu+WaIfp2N2qhbU4Ezzr6cL1NeFufS+UqmdpGea0ov122W+TpuFZHq/4qVLfovkq/bL6v5Zg4WnavBr44t6bHZsB2m7tF+MSOWON67pEW8N18vdMOeCih9QP7/yJ1HcAuSfehktUYsW4O4uLvqqQKVl3UoMJLVkjmNDUxiYigQiQu7GFz4uG2GA/CC+vOH4RTA4ogq1PyLL6HkTn2fhlTjLxarHuVTX/jAQKXv5w6MTnbraF4pHXJhXTtaIYLw==
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=KRaxHGvw2BTA0vfQ5YtYv6Ce4yTniHnIe4jQcbb1m2c=;
 b=l2zzl+kQNtuE72aljgtgUREAobM/+JBPWG18TtFVhtrnTozOZWNVQMjOdGpuesANA28Sq1NjMCukoHirz1CH+lQaqN0UWJFjGN9dECweS6BaujOPJTXfqzDlNSFQZPdmSIFmQGS9+I3690hydVUjjYi+pyEGF5u/dyIOCTTJfky9a9PjYRTpRQx1H9NrKwGmHEZLGrlPTUYF2tk+rfFQDPxgy1fFE1mEtqlXM4ExP6HSU7oS2BU3HIq018D52gqHn1RkkbYb5MZhU/du3YO2Et2f+i9/G/78MJD6bZ2J4LhL33kexef3ralf/CYgnuYVEUpdPFeKKiVtIi//LMctyA==
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: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
Thread-Topic: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
Thread-Index: AQHcHaczp/pn2jKXU0i48m8PFCAwNLSKpFGAgAHknYA=
Date: Wed, 10 Sep 2025 14:49:35 +0000
Message-ID: 
References: 
 <3e237c5256054a88b1c099d85d8bd1a602bba230.1756995595.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_|PAXPR03MB7611:EE_
x-ms-office365-filtering-correlation-id: f828c17c-0920-4743-c7f1-08ddf0794250
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|376014|7416014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?ZGJjYU1SdGVkMVFHUkxMQ1JpTVRWRmNtMEdISXVwbkRBNTNLN09sUStBcldn?=
 =?utf-8?B?T2pzQ3VCOW1sT081eWVVNVNjRFJRcVZXTU8xUXRxcEhrVDFlR0JERWdRUnVW?=
 =?utf-8?B?VjBOYUJOM3ptdFUrbUIxcWI3SVNHSVBkdUNJUVUvdWg5ZnZLUE5EZkw5bTFG?=
 =?utf-8?B?K1RvOTIrUWYvNU5ieU9Uais2cGdUUkd4dVlheG1aZy9zUGVsbStWazZPaEZh?=
 =?utf-8?B?UnRVTVg1MjNibEVhaWlhT09sTEF2OGgzS3VjUWVzbUhaZHRmZTk4UkhWUm4w?=
 =?utf-8?B?YmYxOXcxZ1VUdDMrSlpkQStobThkNGdNd0lFWHdRcUIwWWdJb2pmQlBoNVhi?=
 =?utf-8?B?VHRwS0Qva2VDRHJ1VXJhN1lZU0wzVzVTbVI5TlAyZDlqcE1HNHJpaVI2OStB?=
 =?utf-8?B?YWVQR21FZWlKYngxUzk4bnhmTGhFeUhMR0Jpb3krd0d3NlRUMnNPeVFJRlRX?=
 =?utf-8?B?T2RrWXdGL09sai9pN1ZwalpVR2RQaXFzMVk5dEJDMWxlcTFQZ2dTbDZGaTdP?=
 =?utf-8?B?S3Y0NlRpaStEc0JUYW5lT0lJdW8wVDlXWlNqRHNpMHl3NWludUQ0bjQ5Y3hH?=
 =?utf-8?B?N0Q4d2FJVlY1VjdXV1FoTDNJSFVTd1NCa1ZPZjhsV1BkM1grbUtuUEVieUQ0?=
 =?utf-8?B?TURlWTJJeGVpNmRvZjZrOTJMczNjclowRkdqS3NwZjVPbGJJRUlVSVkrSWtW?=
 =?utf-8?B?TFcvWVdkM0M0KzR0azdjSFFUQngyWDliQW5oTzdEMnYzOCs2QVFXV0pQeDVZ?=
 =?utf-8?B?SDBIQzluYlNVcWhIVXBkOU5USHZUcTBLOUJoa2FCbDZXNkhPaHdnWXBPMVEx?=
 =?utf-8?B?SWV4WVFFcUhBZUhOeDlIVERWRGJCUlQ1S2pMNFpsQkNpMVlmT2t0dDkyMjRR?=
 =?utf-8?B?dFpJRUJvRm4zcUk1bDBLS2YvNkgvalZMQ20rMVB3MHEydkwwS250NlRGN2xB?=
 =?utf-8?B?TTRxaW9mRG9XR3cxb3creTA4WkJiZTBKYTY5cXRkbXRIYXh6TGhSaGtMU0t3?=
 =?utf-8?B?cXUvN2ptcE4wNGZWelhkdEFRNWk3NWtNS0NJaFdRMTBkSG9QYTFqZCtUSW5n?=
 =?utf-8?B?L0J5OEluNkpXbXI5WEVIbkNQSkdZV0E2K09sTWxjblprMnByNTVxY0FnRmtO?=
 =?utf-8?B?VjhjNmhkTmtJUmtBdDlDQWhOMFJUR0ljRy82VyswR093MW0vUUhCWmFVUWRU?=
 =?utf-8?B?R3JkYU1IWHYwRlZrZzh0TEs4Z2NDeEZ0dUgxMTFlTW9PR1Z6bmN0bkdUUzhy?=
 =?utf-8?B?Vi9QUGMrN3BLRmpQZng0Lzk1ak8vT2JRV3BpMThEbTJoTDJnSllzRVU5S3Nw?=
 =?utf-8?B?M0NXem5SeE1hQndpSEFTMlF0aW5NSzRRV1VLa1VFVkxrYkIvOVVVaFcxYndC?=
 =?utf-8?B?TW1odXhWc3pWaVhRY3hTMm9hdlJiWXYwTTloV1MxMFlKSDVSS1hmcktRcmJC?=
 =?utf-8?B?R3ZIZk5kdE9Fd2Nsd1pvbzFOdkRBNzl1cm1ENW50eGZjbXcwN0dtWG1kclhq?=
 =?utf-8?B?aWJaUFNGUVZzWWhETkVzOFJqNFNuTkRodFNNNG9CcjBPVTY5elZ1bEkwTjNP?=
 =?utf-8?B?VDlaSVcxYTJiNm15R0VlQVZoU0FiY2FpVm5GODFmYXZFMi9Ic2xKYk5mVlVj?=
 =?utf-8?B?S0gwYzFHTTl4RDdqTnQ3Z2N1eFFsaUxPSzRWTXcrT094ZWNzMWgvTWUvZTho?=
 =?utf-8?B?NUwvazJ2a1MwZ25yUnBYOGxaN1FGdDBkLzlxQmpQUTc1Qzd5VW5xeUZuNCs0?=
 =?utf-8?B?KzdxYkhVZjRteGV6emovbHJTaWtmSUp3enc1SlBPRjQ5bXh4YmtMSDNsRDVz?=
 =?utf-8?B?L084bkZqZE5sWVAzMjdVZFRFTjNXd2FmeFZPc292djZ2RCtnTmF2bWF1WFEy?=
 =?utf-8?B?dkowZWY0RnR0SEM4QUU1SC84TkwxU2NvMmZ1YkZGblZLVElWbWJ3aTNPaDBE?=
 =?utf-8?B?aDhlaDc2T0pVKytSazNVWDJyZVRTZ3Y3K3NodVRYY1RlTCt0QUxCVTA5dXFE?=
 =?utf-8?Q?RGau3AMy7Kh4ybfhIwFjBPMLFKNRy4=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bnBTekVLRHBxd3pGYzRDWFEwVVpHTmNvYlpTblE2cXJmRG9vWGVoK0dtaVRz?=
 =?utf-8?B?eEZWbDN0dGlMS2FQd0Z3UUZNQ0w1MURUUHNyZG8rNFFTenJJdE95V1VoWGdu?=
 =?utf-8?B?QTFuRE1zTDJ4cjN3Q2J5ZGZIbmREQTMrRksrOFpZRE5nd0QwVFNHeldKYjlr?=
 =?utf-8?B?dDVNbVIxUkQvRFdKRStQNWFmZWdKR3F2UUl2R3ljdVd2eGNNQk5XYU5Id1cx?=
 =?utf-8?B?UG9RMWYybGQ0QmFBT2FSemdyYUxrT0xxOXl1Z0dlWUdQVGpOUnlxUnZHdjhX?=
 =?utf-8?B?cm8ycVd1bGhmWEpNQmdJUU1UcHBGLzN4T2RiaU80elRzNVhWbFc3ZzNCb1hm?=
 =?utf-8?B?RkFwT25xbTh3WHJEMXVRZjRpL25CTzE3K3BMV05Yc0dCeHM3b2Z2c2piWEVo?=
 =?utf-8?B?ZzJocFNEQUJlL1p4TXNnUytoTUJ6SElCNTdkMWRma0JMZGVTVUdNRkFNR3FF?=
 =?utf-8?B?RTdDTW84Yy8rSHQxRWgrN3lmWTFabENrMkNXV3hXRyt2RzE3ZjBYeUh1UmI4?=
 =?utf-8?B?V0IvUTlKZUNaSTlzNEUyR3V6RjdZU09VNDZ4UnNHd0J0L3JWRDJ3RkNsdmgv?=
 =?utf-8?B?aXhHNW1VQndMOFEvUnhFRktXZzduMEl2cXE0ODRrWUhZYzFUaGdzMFNxL3Zu?=
 =?utf-8?B?cnBvNlhGdGdHRmQvcVYrOUhwZG9uUDhBeXRacGt0a09DdmpqNGdwblRqV0lG?=
 =?utf-8?B?WTdwSEEwZUJ1SENlTmw5VWhzeWFuYVROTTlZUnRqbWhEU1BuNUwzNUZiR3dF?=
 =?utf-8?B?MGhXMm5UZU1LMEk0Yy8yd0RDTzZpMzVIMGtlTFNHcExETjhRejBEaWFqUFN5?=
 =?utf-8?B?OEVJMUZseHdXaG53RWZnc041QVhHajBQeld4T01DNlJtWVArYVVJYWN3blNv?=
 =?utf-8?B?Zk9ndlloWkNIbUFoK0k5UkNCMzlHa1ZoMWd3TCthSjI3Z3RVRGY2eEJyS2Rs?=
 =?utf-8?B?WE1kc3I4UGJMeEFQQTlhS3BTaFE4Y0tRbzZHWmRlRHBWNEJqL0FYak81RFNw?=
 =?utf-8?B?KzFtbFdxNjlpY21zQytIK2ZtVm1VL2ovVnVWOFdJNG1KaUxKQ3F0TU5uaDU4?=
 =?utf-8?B?OVRXOGhUSnc1RXZpeVlDYUZkSTRxcGZxRXdWZHJPUmx4WjhIZE9VdmZqclRC?=
 =?utf-8?B?QkRuTExPS2hDWWZQTGNQWTV6ZjBoMDM5T0xjeEpzdkVCNnJXamZZM2RpTXU5?=
 =?utf-8?B?cGxvazhEcEs2M0Y2S1dIcm4rRzlnS2wwQ1E2KytkSlphK2s0OHFFeEVXRmhy?=
 =?utf-8?B?UVMyNysrSHByQ2cxZUI2ZEFYbzZIaldsQW1yeG02UkVjRkx0cFMxTTd5VGF2?=
 =?utf-8?B?bzJiUENXSEpxTGVPUmsrZmJyLzZPRVYwdjJnY0pDNEVjNWNHb3pHR0lBNlhk?=
 =?utf-8?B?cE4xUU5VQk9oSWVNY2ViTXpLUGE1V0IrNlZYRXAzZjE4WVU2T3BDS21xU0lR?=
 =?utf-8?B?Z3RManNRaW44dWpXdTMzWC9wYlF5U1BOM0NoKzUxSElieFNmRmlmRTExMU5w?=
 =?utf-8?B?UStVRUpyaVJ4SXFKa2N3VEMrTUs3MFJDQnYwQS9QYnUxTE0rR2c5cW9QQmh3?=
 =?utf-8?B?V3k3eXh1ZUJxMzNaMHBwRVhKeXhHRUxHbXpCNks4QUdFMWF3VXRBMHpnRjRi?=
 =?utf-8?B?Mi9zVlJiNUlEN0t2OE5PalhjdmhDUmxBUGszUjJQZDBaT2JoWkZzMTQvUUVh?=
 =?utf-8?B?YUhjZ1JEZk9kK0VZeUZwV24yRlpUTXNTeFN3UVgrUFJ1MnZKUXRWb1NTMVM5?=
 =?utf-8?B?Q2JvSUxJejdhcGZZelhVbXhpMlNDSEI1YTY2NlFuZUUzSjlVYWIvT29rN3BM?=
 =?utf-8?B?RjduczFLcGxUTVBSRTYwSGFrZnBEVHhJYm5TQ2tWS3huS0hieEVvanZPdTZv?=
 =?utf-8?B?MEJUOTJUdXJDN3VXVEljYys2dzErM0VJdnRCUnNCY2dWL1MrSVhaZE1ET01I?=
 =?utf-8?B?eEI1elRLQnVvSmlKK0djSml1RnJKL0o5aXJpN24xbGxzOUc4QjhwTGRycnly?=
 =?utf-8?B?NmJkRGpNMlA4TGhaMm5OV2ovZ1ZGZWNtZDZDTkwyWjNXbm1ZMFhpcDEyMGs2?=
 =?utf-8?B?K0N6UFNhbGdRQmRwc01WTVJobEg0bVBUK3Y1S0VYWlR2eFNtK2dBNU9PNFNa?=
 =?utf-8?B?ZnNYZDhidWt6K2MzczZxSUZ1ZXRCSnF3QzFBWFR5a0taTjc3cVpmeXkvRG93?=
 =?utf-8?B?SUE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <23B2D5C239AEDC409CD5B4F1A358B0C9@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: f828c17c-0920-4743-c7f1-08ddf0794250
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2025 14:49:35.0376
 (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: 03c5O3sU0SbSX8Y+6xVR+tCq8Zbj/Cu2Xo0Nprzedk69fEbDuDNM+by52/XJMM+GRxgCmFwVMvldc6A8udhEs8ibzaK0qaOZ6Y0Ek2uJxug=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB7611

SGkgSnVsaWVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgb2JzZXJ2YXRpb25zLiBZb3UncmUgYWJz
b2x1dGVseSByaWdodCBhYm91dCB0aGlzLg0KDQpDdXJyZW50bHksIHRoZSBzY2lfcmVsaW5xdWlz
aF9yZXNvdXJjZXMgY2FsbCBkb2Vzbid0IHBlcmZvcm0gYW55IG9wZXJhdGlvbnMNCmJlY2F1c2Ug
dGhlIHNpbmdsZS1hZ2VudCBkb2Vzbid0IGltcGxlbWVudCBhIGNhbGxiYWNrLg0KDQpJJ2xsIG1v
dmUgdGhlIHNjaSBpbXBsZW1lbnRhdGlvbiB0byBiZSBwb3NpdGlvbmVkIGFib3ZlIHRoZSB0ZWUg
DQppbXBsZW1lbnRhdGlvbg0KYW5kIHByZXBhcmUgYSBwYXRjaCBmb3IgdGhpcyBjaGFuZ2UuDQoN
Ci0tDQpPbGVrc2lpDQoNCk9uIDA5LzA5LzIwMjUgMTI6NTUsIEp1bGllbiBHcmFsbCB3cm90ZToN
Cj4gSGkgT2xla3NpaSwNCj4NCj4gV2hpbGUgZ29pbmcgdGhyb3VnaCB0aGUgbGlzdCBvZiByZWNl
bnRseSBjb21taXR0ZWQgcGF0Y2hlcywgSSBub3RpY2VkIA0KPiBzb21lIGNoYW5nZXMgaW4gdGhl
IHJlbGlucXVpc2ggY29kZS4NCj4NCj4NCj4gT24gMDQvMDkvMjAyNSAxNToyMSwgT2xla3NpaSBN
b2lzaWVpZXYgd3JvdGU6DQo+PiBAQCAtMTEwMyw2ICsxMTA5LDEwIEBAIGludCBkb21haW5fcmVs
aW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+IMKgwqDCoMKgwqDCoMKgwqDC
oCByZXQgPSByZWxpbnF1aXNoX3AybV9tYXBwaW5nKGQpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKg
IGlmICggcmV0ICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByZXQ7DQo+
DQo+IFN0eWxlOiBUaGVyZSBpcyBhIG1pc3NpbmcgbmV3bGluZS4NCj4NCj4+ICvCoMKgwqAgUFJP
R1JFU1Moc2NpKToNCj4NCj4gSSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHdoeSB0aGUgc2NpIHJl
bGlucXVpc2ggd2FzIGFkZGVkIHJpZ2h0IGluIHRoZSANCj4gbWlkZGxlIG9mIHRoZSBQMk0gcmVs
aW5xdWlzaCBsb2dpYy4gQXQgbGVhc3QgdG8gbWUsIGl0IG1ha2VzIG1vcmUgDQo+IHNlbnNlIHRv
IGJlIGNsb3NlciB0byBURUUgKGJlY2F1c2UgdGhpcyBpcyBmaXJtd2FyZSBzdWJzeXN0ZW0pIGFu
ZCANCj4gcG9zc2libHkgZXZlbiBiZWZvcmUgcmVsZWFzaW5nIGFueSBkZXZpY2VzLg0KPg0KPiBD
YW4geW91IGNsYXJpZnkgd2h5IHlvdSBjaG9zZSB0aGlzIHBsYWNlbWVudD8NCj4NCj4gQ2hlZXJz
LA0KPg0K


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 14:49:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 14:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118380.1464181 (Exim 4.92)
	(envelope-from )
	id 1uwM91-00020Z-5r; Wed, 10 Sep 2025 14:49:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118380.1464181; Wed, 10 Sep 2025 14:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwM91-00020S-2x; Wed, 10 Sep 2025 14:49:59 +0000
Received: by outflank-mailman (input) for mailman id 1118380;
 Wed, 10 Sep 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 1uwM8z-0001xf-Kb
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 14:49:57 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20615.outbound.protection.outlook.com
 [2a01:111:f403:2405::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6a3facdb-8e55-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 16:49:56 +0200 (CEST)
Received: from SA1P222CA0104.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:3c5::14)
 by MW3PR12MB4443.namprd12.prod.outlook.com (2603:10b6:303:2d::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 14:49:52 +0000
Received: from SA2PEPF0000150A.namprd04.prod.outlook.com
 (2603:10b6:806:3c5:cafe::d2) by SA1P222CA0104.outlook.office365.com
 (2603:10b6:806:3c5::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Wed,
 10 Sep 2025 14:49:52 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SA2PEPF0000150A.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 14:49:51 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 10 Sep
 2025 07:49:49 -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: 6a3facdb-8e55-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=elqao55GizjVRhD6LwPwXOYeTnrIId4m11jM+lqnf64IRXB/19ot8mnZ7Mgm6A6Il8eKKEdInJqrCk1AqGI5z8MEVc6HRmk/iKqfP7TO4CZauL95JviXAQU5Su8ETM22KcBmt7m4igqYFSObiD076HyhTKKzpjV5mf6HbtFggQcRQps00zrxeByZ1OADtP1ZpPWHZni2d/SrluvscrQBwJwdI98wbKxhvzJ98R/4SwVcB7GolKn9JQmKbpK0mH5bdFiYqd+vgqKaZ6U34uaIAAF2RX7OjPkOfb0FRxnNJhT2LQYsgS0OI2iADL0bCzzYOAZ+of/wCtggwwiRLFygHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nRHcQao7ZcT1dOkugFqWSPo4ks4CXn7x1yCILxjr+R4=;
 b=HYTuGEhO51RUOxmfCHHlYBXEvbezKTBn7FvM3U6aZM1ihRve5/3/i4VC0IRJNM/sdJnaunEgPe+Lew/4POoqPd+Y26w7HA5VP0Wp3ZtBE9s/zDhBjpNTaHeI604Udp8dhy+feAtiiOvu/A52bGBgi3N8FBNVEU2kEBH5whDR7Ew1byZoc+mgHvHFi/A18wvo1QcSosqJngx5clC0hk0vdwGklCz+vYbIoV0SyWWzgGerbmg/7YUtkK36sT/1/dvkpLN+y0eG05wbyBJso9ckSvuKyfbjGqnKxBDK787olN/9EMHGobKFGcUpVTCYAgQwyOkMSq6XliiMztELHaqHNQ==
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=nRHcQao7ZcT1dOkugFqWSPo4ks4CXn7x1yCILxjr+R4=;
 b=dO+DnS+XnZR93WpXppeXP8vTfHjO7x9BOEnoVGCuqLDD4zC1z3wUqerXqqol6ERYEIhbZMUqBIUiIj3toCsm+OXwQUwuBWmTp6REpdaQQd1WRvMHlc5M8SAruHl5qDbQsHCgi11RCAjR5Di+XGb8cqkkwq6xg5Ncl7LmN6FqQuU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD , "Grygorii
 Strashko" , Roger Pau Monne
	
Subject: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH DSDTs
Date: Wed, 10 Sep 2025 16:49:19 +0200
Message-ID: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF0000150A:EE_|MW3PR12MB4443:EE_
X-MS-Office365-Filtering-Correlation-Id: 83ab215c-3840-4880-2aac-08ddf0794c20
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?PKEqfgAvE+vJPo4l+VFsorJBEbEFsO4Y2OiNGSrm+MMabL7xhmuNNaPfrkUN?=
 =?us-ascii?Q?uceX3h5uIFSi8z99DSGUQEH4hhj9B9+fV28/fhGkBuDPbNt9ejbTZuqftDrj?=
 =?us-ascii?Q?Z3oLHEYLCb6j8duuLRSmQHn9MSC3e8uyYHcKhlLVetPQRpzT00vl1bLSAyC2?=
 =?us-ascii?Q?KnPYIeEcHnjXQalJ3h2yWRYpW51Q31xcq+Q0hE9YyFNcVyI+ZNNbeuTGq7mS?=
 =?us-ascii?Q?jicZhJLGpBE2P8cE33OAlDdenDflDOi8nutJctZwx1po+7Fy5XpFnc0fvoWt?=
 =?us-ascii?Q?U1od/T4jOKCZQoJ/lIsn5vzcWMbAK/Gj92reORFg2QZEy9cR8WO1kbydjens?=
 =?us-ascii?Q?FqNWoccdhNO+s2I3rUscTatCqHDV322cXTttUhRT+aMmxl/dB9wesamy4b+H?=
 =?us-ascii?Q?lR2EUN0gs5Y5XrNkrWjRMODGIIy88JitXWvZT/kOLqi9OzerhFsQkPswCZy0?=
 =?us-ascii?Q?JhGAOLWR0rD0tMEzrF7Uc64sGv3I6aXmVq/+19Mg+rGD6JTZdyq4QlOgCrNE?=
 =?us-ascii?Q?s++lHzioYuG9scuSkDWAHaiPsWXZecYOQ1o21+MHxbJsfzArf9gVfarrgM96?=
 =?us-ascii?Q?6FiByOX2HzA55r89jDR67oybvtnxaRw9sPVYL5vorgTdQGA6yUFDRlO1bosg?=
 =?us-ascii?Q?lRm5dQ8X3TNXjSdXko17reYiumS+n7rpuCHYTtsyIbnsShLmg5874zzd4tnA?=
 =?us-ascii?Q?ypaW4HIk+ccVHih4eY6eNDRj4/EzlTIJGFqGwSSkXCzIqPaiHb2BNyyAtRCT?=
 =?us-ascii?Q?8K4vCToUYi924rV4FjeQqqzwT3CgepbPKCwSXLhjUkCbO44wXmlTo3394CO9?=
 =?us-ascii?Q?TWTBvEr1bpVaQMotuBa0eRIhsyhTt12fY9oYvt91YKP14J9MWWM0ryk0qz49?=
 =?us-ascii?Q?G8k822rVPNGvC8jrmahzJRLYA9Y09RAQQ66aIvgGa2BzKcpXo84X4JQd7u29?=
 =?us-ascii?Q?qUIQkuyeeeLSEkxTssamPqZiCvN4KGqy1mGQqmbnQWNkZPXUiKKcQuZDDttn?=
 =?us-ascii?Q?lZVyC8EW3ef/3fG6Unp/1PexX5iXYgN2s0iflesporg6jSS7FwDrsH0zizEI?=
 =?us-ascii?Q?8VUviPZtlrQdGkj8CZo5nZVuR7slFQKRgJ+hVsJ2ggvaKau00trr1rFNQjxV?=
 =?us-ascii?Q?0uSExdO+gNMUuVMvhu3q8HSzE/xnIsvNfzXFIVKcAS/t8gfy6U1w9fyxDL/O?=
 =?us-ascii?Q?r45+xO9eaYDbMSnnf28BFw3igDeE/SC3tEmKPfAAPhvNsfaRD1+EsolI5rJS?=
 =?us-ascii?Q?Orjy3sEFg1WZapBOmd99NTGH0eEJW72Bfa43VjQJJ44p/J8Uq0pIEC1xg3BR?=
 =?us-ascii?Q?7ZKo4FpbYXHlRthF2dleYa26F0SZhNrfPUrS5BH5rMN316Pb0UKDF1hfr0CL?=
 =?us-ascii?Q?SliazDn5nvrf+04oH376lniH3lqbSaGe7J1yQYvddj/cSRm1sxuz9lS8Y9lK?=
 =?us-ascii?Q?5pI352DgSuVXzkXcSWhtJ5KHXzjnF0fezvMwOJvxUdz5fsh/Dfvc6U16t7Nb?=
 =?us-ascii?Q?BLMvOBWQGOG6QBN/wVNzqxxvDrsXnYoUXHS/?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 14:49:51.4716
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 83ab215c-3840-4880-2aac-08ddf0794c20
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF0000150A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4443

CPU hotplug relies on the guest having access to the legacy online CPU
bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
this causes the MADT to get corrupted due to spurious modifications of
the "online" flag in MADT entries and the table checksum during the
initial acpica passes.

Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler too.

This shrinks PVH's DSDT substantially and fixes the MADT corruption
problem.

Fixes: e9a8dc050f9a("libacpi: Build DSDT for PVH guests")
Reported-by: Grygorii Strashko 
Signed-off-by: Alejandro Vallejo 
---
 tools/libacpi/mk_dsdt.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 8ac4f9d0b4..f71de6c8c6 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -218,6 +218,11 @@ int main(int argc, char **argv)
     pop_block();
     /**** Processor end ****/
 #else
+    if (dm_version == QEMU_NONE) {
+        pop_block();
+        pop_block();
+        return 0;
+    }
 
     /* Operation Region 'PRST': bitmask of online CPUs. */
     stmt("OperationRegion", "PRST, SystemIO, %#x, %d",
@@ -264,10 +269,6 @@ int main(int argc, char **argv)
     pop_block();
     pop_block();
 
-    if (dm_version == QEMU_NONE) {
-        pop_block();
-        return 0;
-    }
     /**** Processor end ****/
 
 

base-commit: 53c599cc33b61ae70d59572f3c1d843a3def84e2
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 14:57:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 14:57:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118401.1464190 (Exim 4.92)
	(envelope-from )
	id 1uwMFs-0003u6-TF; Wed, 10 Sep 2025 14:57:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118401.1464190; Wed, 10 Sep 2025 14: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 1uwMFs-0003tz-QQ; Wed, 10 Sep 2025 14:57:04 +0000
Received: by outflank-mailman (input) for mailman id 1118401;
 Wed, 10 Sep 2025 14:57:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwMFq-0003tr-Qi
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 14:57:02 +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 67c3b860-8e56-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 16:57:01 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-b0418f6fc27so1148310166b.3
 for ; Wed, 10 Sep 2025 07:57: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
 a640c23a62f3a-b0783047b9bsm179425366b.13.2025.09.10.07.56.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 07:56: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: 67c3b860-8e56-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757516220; x=1758121020; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=15cYQVjB6Bko11Is5/dYR/Umn5ijIKC3kxDHPdxDkiM=;
        b=DwQD8XijE3CnVlzG0MLzzgIMHzSaaxSWPYIisVYRjQlxQp4lwUFkIDCawRCba+1CzS
         xpCENmCHqtYOBk2N5IEI/Kp7YXKVbYFSE2qhjzCoRNeOqqdHtQ+6jhfE2vN4CV124IQB
         H1kWpLSi3NFvZ2YOWwAPzpNP2aokeuYBcRgHCN3UFTb6wBtZWd+QBarxe8sukD9f2ris
         07xZLemC5YkN0qBSI7SgHPwST/Tw6ce0Hjmd8rAdKf18tNkIIfKDU42N+2SHwfewvo3w
         VxA8kOrrzfjispa4FtgeHwxECSw9Py26ljX5s62zVDL6r7eiBLjkvQYugi9+lnRJsLLe
         xEHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757516220; x=1758121020;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=15cYQVjB6Bko11Is5/dYR/Umn5ijIKC3kxDHPdxDkiM=;
        b=WG7/fyuCT/0Dkd1X5pe4gdunZ/Lu3GKcXukOF8I4JvyzEMEaw6VGqDx5YCJ/jP5PpK
         Cc0ROcwfV1q4FmPDrJUi9JB+d/Agmdh8/vjxTxoWp5YHZNqCfnRHmz2rrryGCHFOo3sv
         6lWlR4DMhEcojYXXKurR5v7y7o/R1M0HhwMjYW1o//84M6ICZfUm2b4q2FQqUJf/+xWH
         Cs95dZ11QlAar+uci7n3pHXqNqCUa7wkt8kDfUf5UnXy/md/Y1g7i4RJMqAHmPII0h4+
         5yNpo29G+4+WNVcTPwYXpz9Nwk71PAra9sxNRcalPz06EwKPTGQL20dK0z3FeRmeoI6M
         eXjQ==
X-Forwarded-Encrypted: i=1; AJvYcCVY0G8RBFqtR69DnZN9VgEK3NwSm68gY1oy96t5eOIn1m2N/ERJ2GWjNLmES42xkgimImsNw4hX478=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOw27fRcoJFjjXuuP0tiQGdS19dNAEQdCTReebxDfdb+32PiUP
	Ge5IXK6cisB59ufDwQPvCBmubX5ijm0u5S19OEd55Iow8AQjLsk7/Y+sUtVQABnfbA==
X-Gm-Gg: ASbGncsiGE3OpmGDfPVcnZ/nFAFoRa9R0ziNmOLbgM5EYoWoePYFvuuq7HLFnZjRmtl
	MWktm0afCDBYgKZ/LhHRQGqYybSk8sBrQy5Ld0l55mqs2QxHkSCUMeXYFM/i7s6Vj+mrREaYI1J
	KHzmYf+dVZKvMo+AN41hEe0sUkjfJUT/VHbFUfJ3v+cs+LPb+ocMCG98hWOXToLgRhHtxQ8WDL4
	IyXEG1QamPWhJzPBQUhfjQWvuUr2ay0LvpVdLb3wAAfhpIYiJng7Y7bX4tkDsCzn6qXAwMlWJFG
	U2jfcC+Bzv0vZ5LqTYNxGkQblTrtuYOmcf1rS5NdmdaGSBlWb581R8GcTM69QI36/ZiVDR8oSA4
	KnLQHnz2bqoEOLDfAoyEq/Ao4QSoL8yFHx2sz2ao1/LOzgQQv7byAFzFguipF8IWatr6b/013kw
	571yAwBOHamrjaCIYnnw==
X-Google-Smtp-Source: AGHT+IFr09DYlgXsLIVaZOvNGub5Ek7Opv2Xbme58zhVraW4jrG3tuyMHtAqrksVw3G4Vlg1fTmang==
X-Received: by 2002:a17:906:456:b0:b07:6214:79f9 with SMTP id a640c23a62f3a-b0762148115mr734727866b.19.1757516220138;
        Wed, 10 Sep 2025 07:57:00 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 16:56:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
To: Penny Zheng , Tamas K Lengyel 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-5-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> @@ -2456,9 +2460,13 @@ static struct hvm_function_table __initdata_cf_clobber svm_function_table = {
>      .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
>      .msr_read_intercept   = svm_msr_read_intercept,
>      .msr_write_intercept  = svm_msr_write_intercept,
> +#ifdef CONFIG_VM_EVENT
>      .enable_msr_interception = svm_enable_msr_interception,
> +#endif
>      .set_rdtsc_exiting    = svm_set_rdtsc_exiting,
> +#ifdef CONFIG_VM_EVENT
>      .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
> +#endif

I think in such a case it would be preferable to move one of the existing
lines, so we can get away with just a single #ifdef.

> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -192,7 +192,9 @@ struct hvm_function_table {
>      void (*handle_cd)(struct vcpu *v, unsigned long value);
>      void (*set_info_guest)(struct vcpu *v);
>      void (*set_rdtsc_exiting)(struct vcpu *v, bool enable);
> +#ifdef CONFIG_VM_EVENT
>      void (*set_descriptor_access_exiting)(struct vcpu *v, bool enable);
> +#endif
>  
>      /* Nested HVM */
>      int (*nhvm_vcpu_initialise)(struct vcpu *v);
> @@ -224,7 +226,9 @@ struct hvm_function_table {
>                                  paddr_t *L1_gpa, unsigned int *page_order,
>                                  uint8_t *p2m_acc, struct npfec npfec);
>  
> +#ifdef CONFIG_VM_EVENT
>      void (*enable_msr_interception)(struct domain *d, uint32_t msr);
> +#endif

Possibly same here.

> @@ -435,7 +439,11 @@ static inline bool using_svm(void)
>  
>  static inline bool hvm_has_set_descriptor_access_exiting(void)
>  {
> +#ifdef CONFIG_VM_EVENT
>      return hvm_funcs.set_descriptor_access_exiting;
> +#else
> +    return false;
> +#endif
>  }

This is actively wrong. It being only monitor.[ch] which use the function,
I don't see why it can't just be wrapped in an #ifdef. With what you do,
some new caller might function fine until run in a VM_EVENT=n build.

> @@ -681,7 +689,9 @@ static inline int nhvm_hap_walk_L1_p2m(
>  
>  static inline void hvm_enable_msr_interception(struct domain *d, uint32_t msr)
>  {
> +#ifdef CONFIG_VM_EVENT
>      alternative_vcall(hvm_funcs.enable_msr_interception, d, msr);
> +#endif
>  }

Mostly the same here.

> --- a/xen/arch/x86/include/asm/hvm/monitor.h
> +++ b/xen/arch/x86/include/asm/hvm/monitor.h
> @@ -17,14 +17,16 @@ enum hvm_monitor_debug_type
>      HVM_MONITOR_DEBUG_EXCEPTION,
>  };
>  
> +#define hvm_monitor_crX(cr, new, old) \
> +                        hvm_monitor_cr(VM_EVENT_X86_##cr, new, old)
> +
> +#ifdef CONFIG_VM_EVENT
>  /*
>   * Called for current VCPU on crX/MSR changes by guest. Bool return signals
>   * whether emulation should be postponed.
>   */
>  bool hvm_monitor_cr(unsigned int index, unsigned long value,
>                      unsigned long old);
> -#define hvm_monitor_crX(cr, new, old) \
> -                        hvm_monitor_cr(VM_EVENT_X86_##cr, new, old)
>  bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value);
>  void hvm_monitor_descriptor_access(uint64_t exit_info,
>                                     uint64_t vmx_exit_qualification,
> @@ -45,6 +47,65 @@ int hvm_monitor_vmexit(unsigned long exit_reason,
>  
>  int hvm_monitor_io(unsigned int port, unsigned int bytes,
>                     bool in, bool str);
> +#else
> +static inline bool hvm_monitor_cr(unsigned int index, unsigned long value,
> +                                  unsigned long old)
> +{
> +    return false;
> +}
> +
> +static inline bool hvm_monitor_msr(unsigned int msr, uint64_t new_value,
> +                                   uint64_t old_value)
> +{
> +    return false;
> +}
> +
> +static inline void hvm_monitor_descriptor_access(uint64_t exit_info,
> +                                        uint64_t vmx_exit_qualification,
> +                                        uint8_t descriptor, bool is_write) {}
> +
> +static inline int hvm_monitor_debug(unsigned long rip,
> +                                    enum hvm_monitor_debug_type type,
> +                                    unsigned int trap_type,
> +                                    unsigned int insn_length,
> +                                    unsigned int pending_dbg)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static inline int hvm_monitor_cpuid(unsigned long insn_length,
> +                                    unsigned int leaf, unsigned int subleaf)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static inline void hvm_monitor_interrupt(unsigned int vector,
> +                                         unsigned int type,
> +                                         unsigned int err, uint64_t cr2) {}
> +
> +static inline bool hvm_monitor_emul_unimplemented(void)
> +{
> +    return false;
> +}
> +
> +static inline bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn,
> +                                         uint32_t pfec, uint16_t kind)
> +{
> +    return false;
> +}
> +
> +static inline int hvm_monitor_vmexit(unsigned long exit_reason,
> +                                     unsigned long exit_qualification)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static inline int hvm_monitor_io(unsigned int port, unsigned int bytes,
> +                                 bool in, bool str)
> +{
> +    return -EOPNOTSUPP;
> +}

For this one it's perhaps easiest to see that -EOPNOTSUPP (or in fact any
negative value) is wrong to return from the stub: Just go look at both
use sites. Guests wouldn't be able to use I/O insns anymore for intercepted
ports. Others look to have similar issues, while the ones returning "false"
look okay.

> --- a/xen/include/xen/mem_access.h
> +++ b/xen/include/xen/mem_access.h
> @@ -33,9 +33,7 @@
>   */
>  struct vm_event_st;
>  
> -#ifdef CONFIG_VM_EVENT
>  #include 
> -#endif

Aiui this breaks the build on PPC and RISC-V, which don't have such a
header. If this change is really needed (which I'm not convinced of, as
x86's hvm/hvm.c could as well include asm/mem_access.h directly), you'll
need to use has_include() here.

> @@ -74,6 +72,7 @@ typedef enum {
>  } p2m_access_t;
>  
>  struct p2m_domain;
> +#ifdef CONFIG_VM_EVENT
>  bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
>                                   xenmem_access_t xaccess,
>                                   p2m_access_t *paccess);
> @@ -99,10 +98,40 @@ long p2m_set_mem_access_multi(struct domain *d,
>  int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access,
>                         unsigned int altp2m_idx);
>  
> -#ifdef CONFIG_VM_EVENT
>  int mem_access_memop(unsigned long cmd,
>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
>  #else
> +static inline bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
> +                                               xenmem_access_t xaccess,
> +                                               p2m_access_t *paccess)
> +{
> +    return false;
> +}

So this is needed when VM_EVENT=n and ALTP2M=y. Tamas, is this a configuration
which makes sense?

> +static inline long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
> +                                      uint32_t start, uint32_t mask,
> +                                      xenmem_access_t access,
> +                                      unsigned int altp2m_idx)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static inline long p2m_set_mem_access_multi(struct domain *d,
> +                            const XEN_GUEST_HANDLE(const_uint64) pfn_list,
> +                            const XEN_GUEST_HANDLE(const_uint8) access_list,
> +                            uint32_t nr, uint32_t start, uint32_t mask,
> +                            unsigned int altp2m_idx)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static inline int p2m_get_mem_access(struct domain *d, gfn_t gfn,
> +                                     xenmem_access_t *access,
> +                                     unsigned int altp2m_idx)
> +{
> +    return -EOPNOTSUPP;
> +}

Instead of these, I wonder whether a single #ifdef in do_altp2m_op()
wouldn't be more appropriate (assuming the above config makes some sense
in the first place). Actually, it would need to be two #ifdef-s, one in
each of the two switch() blocks.

> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -30,6 +30,7 @@ struct xen_domctl_monitor_op;
>  #ifdef CONFIG_VM_EVENT
>  int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
>  void monitor_guest_request(void);
> +int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
>  #else /* !CONFIG_VM_EVENT */
>  static inline int monitor_domctl(struct domain *d,
>                                   struct xen_domctl_monitor_op *mop)
> @@ -37,8 +38,11 @@ static inline int monitor_domctl(struct domain *d,
>      return -EOPNOTSUPP;
>  }
>  static inline void monitor_guest_request(void) {}
> +static inline int monitor_traps(struct vcpu *v, bool sync,
> +                                vm_event_request_t *req)
> +{
> +    return -EOPNOTSUPP;
> +}

Is this needed? There's only one call that needs taking care of afaics,
in hvm_hap_nested_page_fault(). That's gated on "req_ptr" being non-NULL
though, which isn't possible when p2m_mem_access_check() also is a stub.
Hence the compiler ought to be able to DCE the call.

> --- a/xen/include/xen/vm_event.h
> +++ b/xen/include/xen/vm_event.h
> @@ -50,6 +50,7 @@ struct vm_event_domain
>      unsigned int last_vcpu_wake_up;
>  };
>  
> +#ifdef CONFIG_VM_EVENT
>  /* Returns whether a ring has been set up */
>  bool vm_event_check_ring(struct vm_event_domain *ved);
>  
> @@ -68,6 +69,20 @@ bool vm_event_check_ring(struct vm_event_domain *ved);
>   */
>  int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
>                            bool allow_sleep);
> +#else
> +static inline bool vm_event_check_ring(struct vm_event_domain *ved)
> +{
> +    return false;
> +}

Which call site is in need of this stub? I was first considering
mem_paging_enabled(), but MEM_PAGING already now depends on VM_EVENT.

> +static inline int __vm_event_claim_slot(struct domain *d,
> +                                        struct vm_event_domain *ved,
> +                                        bool allow_sleep)
> +{
> +    return -EOPNOTSUPP;
> +}

Sadly this looks to be needed when MEM_SHARING=y and VM_EVENT=n.

> @@ -82,23 +97,28 @@ static inline int vm_event_claim_slot_nosleep(struct domain *d,
>  
>  void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
>  
> +#ifdef CONFIG_VM_EVENT
>  void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
>                            vm_event_request_t *req);
>  
> -#ifdef CONFIG_VM_EVENT
>  /* Clean up on domain destruction */
>  void vm_event_cleanup(struct domain *d);
>  int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
> +
> +void vm_event_vcpu_pause(struct vcpu *v);
>  #else /* !CONFIG_VM_EVENT */
> +static inline void vm_event_put_request(struct domain *d,
> +                                        struct vm_event_domain *ved,
> +                                        vm_event_request_t *req) {}

Same here and ...

>  static inline void vm_event_cleanup(struct domain *d) {}
>  static inline int vm_event_domctl(struct domain *d,
>                                    struct xen_domctl_vm_event_op *vec)
>  {
>      return -EOPNOTSUPP;
>  }
> +static inline void vm_event_vcpu_pause(struct vcpu *v) {};

... here.

>  #endif /* !CONFIG_VM_EVENT */
>  
> -void vm_event_vcpu_pause(struct vcpu *v);
>  void vm_event_vcpu_unpause(struct vcpu *v);

Please move vm_event_vcpu_unpause() as well (without adding a stub). The
two would better stay together.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:02:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:02:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118426.1464200 (Exim 4.92)
	(envelope-from )
	id 1uwMKp-0005Yy-Ix; Wed, 10 Sep 2025 15:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118426.1464200; Wed, 10 Sep 2025 15: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 1uwMKp-0005Yr-Fn; Wed, 10 Sep 2025 15:02:11 +0000
Received: by outflank-mailman (input) for mailman id 1118426;
 Wed, 10 Sep 2025 15:02: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 1uwMKn-0005Xy-CA
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:02:09 +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 1e62cb98-8e57-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 17:02:07 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-61cb4374d2fso10570618a12.2
 for ; Wed, 10 Sep 2025 08: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
 4fb4d7f45d1cf-62c01bdb66esm3268561a12.47.2025.09.10.08.02.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08: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: 1e62cb98-8e57-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757516527; x=1758121327; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SvOd9m8kJxDcIg/axlV3ZS3HHk2oHeXldMDYZsTyLv0=;
        b=YoxK8CNI8YXtYAL7L1f6DAFGDkaaxvCJiemt0CEyGrRwJWl5HdHY1QRvo/D9OiJZKY
         07wEnP/HFv0o3dsJim54Xq/Yyxyy6Olr94JQBRu/k0yLCa0FKc84ierPhnQcl5Zjn4O5
         y8jvcpXvR5EJM2YIsN4gXObzOVDKv/DTmZaYrwy2/G3aWHUYWt/2NR4s9HKXsugr//QF
         /nM5xMgEow3fxEy2Sn+udLQjRvQOCf4/H51HfgVlmRpAeOOGFFDSqSqP+FTOwK9/kxM9
         XIfPBZguDcqLwUZrE7287gso5yNu4Qx707VGb6b/vNoO39XurDIXRQ/PEo52008wW130
         ciFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757516527; x=1758121327;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SvOd9m8kJxDcIg/axlV3ZS3HHk2oHeXldMDYZsTyLv0=;
        b=U0yablo4vnx8N1qgxUxr2eCPZcSnsWsnnQM4yWHNnuNw5OZo1SYsf9uTvsczEAoT7p
         sV8j9sbEgArVex3HLXmiHREQcpI4OrX1jUypqzLUi9eNFW5YJG7wPeNR/v18FCai0mAP
         7EkN0QxX2rONUXuE+DBBjEABynGGla54iQznRzXFj5GwgIFDnxq4OjA6wMtsFK+Zg7G5
         ly9ZCQMWp5CuvZFeSL76+5sLueKRZoKUTZbGMLWq0hwH/5nTtYi9xIzGWDSQ4x6amczY
         5IjY5Xgv+ToUu0M9IeKDQJleHlaZoE5HmtT+YieF9ltk7YTkJ78Y4wdJyTEN9Ni419Wf
         EJCg==
X-Forwarded-Encrypted: i=1; AJvYcCVlZAbu4yPIBkzOCdXty/YdOQQMV5qLfGHNbhW3EDY6PCpGlQqGeuQq0l5tRnwsDDf6aT/K24coaxc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnX1+D66efMxTVDns9mIW00qnW5vNNkgekTH+HXmtqVSFyR+J0
	aVrdLgEWutotsfr1EVbRCm6yWLV94LE13ak0eauQUB0hQzfU1Gxw190LI0HnNfu56A==
X-Gm-Gg: ASbGnct+OYW5YVXVnqH2ZeCvFrB9rNzU+N9W8/gYKXrdoiuUYLOkRcR8ymDfDhswT3D
	2PI5uuzzSMUBntXnWGjWI+ffo8eoizkH8nNolxovS7iaR4t2ZL5WyxjjfHLLvTvp2koZrfYkMN3
	CHRhb4r9e45UEEBGFO2NH3uDedP1mdI6na5OdguiEzJoWaPkCvlK6XRyQnXGOZw2TQGIFIlCmZT
	+7MQIrG5cP6V0nrosSOuOT5WT5aNdh+kpNH7eNAD1dyJtCG4akULY2C+0EArlQT6fF9E8oj8TLs
	EkqiSzSlG1ReQ7po+s2gGN3jMOU8SsP7RXTjtMr4cEDTFRsucoYOJsOdic+o8cbl7K5Rh4zFetm
	FAaDJyFR6atZUoxqGNFy/8NiwNVMjVSFiY6D4Ie7sDgbHnlhEbatw5ilNbD6FKATZ4nRWf8qIGw
	13H3P41bBFbqZwFicIcw==
X-Google-Smtp-Source: AGHT+IGDD6uEdgk1A8IYUrI7JBWrFpb7xC/+/HSY3g6IZDxOZ2sekopUWMiayGMRjq3ZGKhBn/z26A==
X-Received: by 2002:a05:6402:5210:b0:62a:85cb:44ca with SMTP id 4fb4d7f45d1cf-62a85e9ca8emr9248414a12.34.1757516526501;
        Wed, 10 Sep 2025 08:02:06 -0700 (PDT)
Message-ID: <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
Date: Wed, 10 Sep 2025 17:02:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 Roger Pau Monne , xen-devel@lists.xenproject.org
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 16:49, Alejandro Vallejo wrote:
> CPU hotplug relies on the guest having access to the legacy online CPU
> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
> this causes the MADT to get corrupted due to spurious modifications of
> the "online" flag in MADT entries and the table checksum during the
> initial acpica passes.

I don't understand this MADT corruption aspect, which - aiui - is why
there's a Fixes: tag here. The code change itself looks plausible.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:06:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:06:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118436.1464211 (Exim 4.92)
	(envelope-from )
	id 1uwMPN-0006DZ-35; Wed, 10 Sep 2025 15:06:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118436.1464211; Wed, 10 Sep 2025 15: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 1uwMPN-0006DS-0L; Wed, 10 Sep 2025 15:06:53 +0000
Received: by outflank-mailman (input) for mailman id 1118436;
 Wed, 10 Sep 2025 15:06:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwMPM-0006DM-JE
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:06:52 +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 c7f4a9d4-8e57-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:06:51 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-afcb7ae6ed0so1082028566b.3
 for ; Wed, 10 Sep 2025 08:06: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-b0783047123sm181469166b.14.2025.09.10.08.06.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08:06: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: c7f4a9d4-8e57-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757516811; x=1758121611; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dR/60dyN9WxiyGh9aLPatEMOll/KaCt99sCErUf0ooE=;
        b=KFknUBqpALO/ehvM71SCD7L7NPPG6RxNLbrOtiOPpFguEVZDhrNxY0xGY8k1uJOlc3
         EcyyZ3F/THbSb+sSO2FZJsuLXmInz/COifkuZQ5bfw0rG+hFSpI5TSB1YmOj5cUzA24s
         uqLpOPzXFNVjlBo1FpCSplDRG8SHcqJNQlz1MietDEn1SomHoMtTQRBtqd/KDV6dCYVw
         k7ru4/6jbPHh6lIFFoopFtPhsE9wplGiAjiV3w6i/3JjV6l0GB/IqqEv89S3c8Jos1cR
         wYCoD/Q1gEMq5FGeWJedEU49xxUcR1tZUevBURV/KMrOpAOApLZ3lgPdeeks4yOeHbwI
         aAAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757516811; x=1758121611;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dR/60dyN9WxiyGh9aLPatEMOll/KaCt99sCErUf0ooE=;
        b=f0WmRoQRIIRwrLBDz3+Iq3v7770xYLeUq87Ogfz8xpik3CcNafEErus7t3SKts8UxI
         QhtLBgXaaSwF67BaHXWX16qyn4S1FMVuG3Ekb5k7bYiyAQFM1uS4iRvJGwjIBFr/iMGp
         8N7itdW34ph8m8pYtKl+qcVS8NSqi4EVPR8wKDRH1EUkzmg0aglofK2yLjAIRtINLtpz
         iMKvML8cSy2eZCZtSYYyY0SuoqLith1I5QZDoZhpl2DwH4b7s7NU0et67gEixdAB8gq9
         fHtRAiD9yiRrKLB4g+42wXzLL5kOJXKOfybi27aWwbFDwqJnJ2QMBGEsy9Lcyb68qiat
         oCCA==
X-Forwarded-Encrypted: i=1; AJvYcCWZ5CiZVGv4sRuGQhfv1/aA+B3VrJk3IQy69rbx0gdoPUr7v5snifSq7VXVtD+o0SCxaHN5kURFiJo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwrCTHnQryRDW5R8RznBvokQ3TsFSbuvF1xOLBHRQE95padExki
	QxNZD+8+zUhsNXvZm6XgCFKbI3d7KfTDZ/Y/Ffu+OqLLL1xq3/HoaZbAOCrifl0jyg==
X-Gm-Gg: ASbGncuAImRz0dL9AHucAvrLNxHMHT4+mqC+ZIFS1vtySlS+VYz98sJFbZdoTCMrSiw
	pKEQX7DU+sAvl4YaVutrpWbtcx+06fqRx0+e8Ii/BMFdZAFA6HonVDKWQE6NXvjE8+UFAD2ZcqD
	YUouTvGuLqB9KbAjR0/4EglB1o1qj8AbwtMD4xkK9bLe5n2G70oJdzcZQdkREZKaytHzVhQB+vT
	KyEAp/+6C5b90Un1HG8gHu6BmZ3gMUrFo6J62ozMLaUGWTBf0YD08CB1CTSCrgGtHdX18GwlihD
	Xq9LQxQeuxpLOJ6Kou28beBnp0cU4mLWBRwiTLvS9vheAEfhIvpkz5sTesgzh+1v0/WP/34ST5m
	yCrBA8+BIFKq80VroYGaKqaE0yd/CAM/+1pwrQ6iAvTDxgpQusw/zHSxeXx8acE5y4yFZ6pDXpt
	dyljx4MEs=
X-Google-Smtp-Source: AGHT+IF7JNiTdkIYILG5qWoolBaY3CB5Tfw2xhI/pWNKc2iuFrieR1zbBhKG1qzc15mbsjxV9PDOqw==
X-Received: by 2002:a17:907:a07:b0:b04:67f3:890f with SMTP id a640c23a62f3a-b04b166c8afmr1520070466b.33.1757516811097;
        Wed, 10 Sep 2025 08:06:51 -0700 (PDT)
Message-ID: <4e61f21e-6e1e-4baf-a78e-2b17b876d20c@suse.com>
Date: Wed, 10 Sep 2025 17:06:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/26] xen/x86: make VM_EVENT depend on
 CONFIG_MGMT_HYPERCALLS
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,
 Tamas K Lengyel 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-6-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> VM event could only be enabled/disabled via vm_event domctl-op, so
> CONFIG_VM_EVENT shall depend on CONFIG_MGMT_HYPERCALLS
> 
> Signed-off-by: Penny Zheng 

Looks plausible to me, so:
Acked-by: Jan Beulich 
but really Tamas (now Cc-ed) should also get a chance to express possible
concerns.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:09:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:09:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118447.1464221 (Exim 4.92)
	(envelope-from )
	id 1uwMRQ-0006nR-EQ; Wed, 10 Sep 2025 15:09:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118447.1464221; Wed, 10 Sep 2025 15:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwMRQ-0006nK-Bk; Wed, 10 Sep 2025 15:09:00 +0000
Received: by outflank-mailman (input) for mailman id 1118447;
 Wed, 10 Sep 2025 15:08: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 1uwMRP-0006nE-M0
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:08:59 +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 1393bcd6-8e58-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:08:58 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b04271cfc3eso912965166b.3
 for ; Wed, 10 Sep 2025 08:08: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
 a640c23a62f3a-b078334a288sm184205866b.70.2025.09.10.08.08.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08: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: 1393bcd6-8e58-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757516938; x=1758121738; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=R7sngC8SDpSKHEBL1OTtoZ5DOvcrVsFzxEkaLIVt5YM=;
        b=DEGDCqgEGioFQ5BNxhpON8y1VvWKDSTeV4Keb9bt+9rulw7Z6qDUpe5frbBoQn8c5s
         8AuH/FJveC4Y9+PpkR/z8DGgbnJy9vY24Ic9W/tHF1+yi2FgHqPHhlCgJ+6h7nhgBHAu
         vmtnWY5cTKMeVI9poux6YAyhCR2r+wHvWsPl+dcLR6ecCTLiswP+oyxIMHr0D5FgsRx2
         l/Wk1oo1SVcV9BYZuKdfeXSCTzWY2ZtuoHzCPVztaAvfKwINOmnFVlI6D0mUzGktpGdO
         YD5JBF1d4aO2GQHhOlfIt+p00TZPRFT0/VFWkEMUTtp4CgaxkUbi6HtNJQI9CtA9LRms
         b+5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757516938; x=1758121738;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R7sngC8SDpSKHEBL1OTtoZ5DOvcrVsFzxEkaLIVt5YM=;
        b=eWHJYSalEa712m/U2GNdtUtjK3cpNSrrsSTE0thkeppxWlWSkcNk53nmX46DJOxPJJ
         vr8AUJw5SGBl13BobNb0ZB5OlU3X4OqKimHKGV9V2d6wUvAc3h2ocqSW77bJ/ZdlPWfq
         LJlwzw5+2rKOo3lwbbJeMCMdYNjdbOIvgs9p11GG1RiRK7dnZT+vKOZIVK6FfgujMN4J
         xQc9tKHMXlAAyxun8tzNrJHyrd06fjhS2wxV81EWiH7cw7/no+DfAITzt++R+GNUR3n/
         znhSvrssJ+UMHEW14Pv/Ks3Gp4luSoGntKgalQAdiZ6sIhlufhaBdBXfHm2qOZkBZ3dX
         YGGA==
X-Forwarded-Encrypted: i=1; AJvYcCVUVEmB3rQHttWa6jjoMC9//5hj1SedgUYLKMwmP8fzAX6LSKeSZ/VDlJLWIJWfkZO011aOSjTxYY8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6LSKN62JntRY0yJ2JRh1b3JyHSy9t0PGbJ3Tu0phGWIFjKd0w
	PynR5KvplFLdj2BZzpUKpMAEkRTRAtke6XJ1ZREUc7iIWwFIdE66++1zsOccKbqicg==
X-Gm-Gg: ASbGncubLRMbOW2VHxePqmp87yq0RDUKcCEChnQQk4tKvhqDvM7mqqSLx0fb9hZfgNN
	A6d9S6LcK8VScY4lwhmEYB8WMYuLjJf07x2Avoq8BOt4hSKHaRfiPmSYh67FM1RvMGonaQo99FP
	EaEnQLC7BHAp9Xq48qvOyl2by8I9PfnOsdZtbZpAMmch85yThE4Tsuvsr5CHr74yuMC5+Yj43+z
	s3nj9WXOs6CDF9vtIENKpV3JPcJpmbIdT4cIwT7D1MgcD9knWFO8ehbrNvfNOfZENvRu3uFQlOW
	bKedgRrsYz4hG3DtJVIqNKTUrEhjXhje9/1lW4sFNBR9wYUqOU2epkBIzrn8ewCFuVtHSk9iqmY
	qh+ij51jf+DWbQfxUsnm2/7T1PlD+1Xa3VeeD3BTRUeGfnXufI6EgLFrbB/klm6w6q+fpmqIUNN
	gPvapC8tMIX6T52lE2cw==
X-Google-Smtp-Source: AGHT+IGrzmtcdfxvaqcmiyZCdGOZlB4GHvQWEywWAVu9ZxsW+ncCHRP8FOTv2+68e7y7nIMo06tQ3A==
X-Received: by 2002:a17:907:d89:b0:afe:9552:9f44 with SMTP id a640c23a62f3a-b04b14916d6mr1500649766b.29.1757516938079;
        Wed, 10 Sep 2025 08:08:58 -0700 (PDT)
Message-ID: <99737b48-2f14-4d49-85f8-5acd4a434dde@suse.com>
Date: Wed, 10 Sep 2025 17:08:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/26] xen/domctl: wrap
 domain_pause_by_systemcontroller() with MGMT_HYPERCALLS
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: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-8-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1606,10 +1606,12 @@ static int _domain_pause_by_systemcontroller(struct domain *d, bool sync)
>      return 0;
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  int domain_pause_by_systemcontroller(struct domain *d)
>  {
>      return _domain_pause_by_systemcontroller(d, true /* sync */);
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  int domain_pause_by_systemcontroller_nosync(struct domain *d)
>  {

I would have ack-ed this if there was only this part, but ...

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -390,11 +390,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>          break;
>      }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      case XEN_DOMCTL_pausedomain:
>          ret = -EINVAL;
>          if ( d != current->domain )
>              ret = domain_pause_by_systemcontroller(d);
>          break;
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>      case XEN_DOMCTL_unpausedomain:
>          ret = domain_unpause_by_systemcontroller(d);

... as expressed elsewhere I'm not happy about this one, as it'll need
undoing in a later patch of this same series.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:13:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:13:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118459.1464230 (Exim 4.92)
	(envelope-from )
	id 1uwMVr-0008Mq-Uz; Wed, 10 Sep 2025 15:13:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118459.1464230; Wed, 10 Sep 2025 15:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwMVr-0008Mj-SM; Wed, 10 Sep 2025 15:13:35 +0000
Received: by outflank-mailman (input) for mailman id 1118459;
 Wed, 10 Sep 2025 15:13: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 1uwMVr-0008Md-0S
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:13:35 +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 b79f7a89-8e58-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:13:34 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-afcb7322da8so1300650766b.0
 for ; Wed, 10 Sep 2025 08:13: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
 a640c23a62f3a-b078304716dsm181620166b.12.2025.09.10.08.13.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08:13: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: b79f7a89-8e58-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757517213; x=1758122013; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=N/ASnHQArI5LvrunbEBR5tVoOsDlVKT+G13H/FwoRxc=;
        b=Qr+++NF9JfRjTNkxXlc28mMIhVzlvKFycn8R7gKO4XYoRcEJSluoHlorCzMFP8zagE
         35ukuKxEh9veWAJfA3sD7Zj3+5KvIzsgxpitgVWTWH9CLQmP/ZneP39WJmVmOIJIjPQI
         gouOrHVLzq0RqXuKpc9ZgFMzyR9py4dJxPMy700RKlbA1q7B/pFY+E/F6B3tBRWPfC+9
         OqaN4WtSlvfp5BZxbeOm2NhRqNoOxaz3kEb5Q+w/abYJ/K30VbwefGaXEeh09wCXjsBY
         7fQfDDmyDJD8W2scfoEPK+Fked1NP6RaUyOPkce3Gznh+coOW2Gtcz52/NKglHdbwTkR
         /r4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757517213; x=1758122013;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=N/ASnHQArI5LvrunbEBR5tVoOsDlVKT+G13H/FwoRxc=;
        b=EBtCcilgoAgeN34AZ6ADcJpvRWVNbeE2PcrQKKnrI7kyrshTDiXUFeDPbBnSyO9IXH
         1dnkV+I6ODaMrzF6bTtANwn6K//ZuVNGL9AjL4uPvKo4HMqsooCoJpVUFVVNYddj1zCI
         CADLMAZcnOk1rXwjdEw+wbDddG2cLuM6f6lkW+jtsYBE+6SOsLtKSAbIlZpk8dcOucY/
         DQM4GJukl9egzZMILq4vvRSK+9s/ySS2KlfoJkRYuWsl12UaYweLJ7EqjVvgKzmTAkAH
         Vb7T/C7Wh/EhEq5uehKu0wBCCFgHYRxL3yY5KyXxyq17i4MJH/HhDCGV+pYtkJcJO1kU
         MT/A==
X-Forwarded-Encrypted: i=1; AJvYcCXGMVQmeAJMbq+4h19GG+NFdaAX6N/EvKT+4/KzE9T4lJupGSura9uc27udXhqDLk0wse9cYPd+KEc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwqCH2kqMAME+1hyl4svN8RtMnpi7bBXpt8f1XkgPTxjUmul5Nc
	Ey0Vo8qI8Kaq3+6Kdl20PjhRGf0d6Le62o5B+emz2K/O+gMbHCorB5S4b5FyewIrHw==
X-Gm-Gg: ASbGncvij7CVSxN2gwiqtXnRX2jeFl7yefCANHo8V4Ni2I3WIw1H2duGI2hMjXe9qhE
	KevpyUX+7eWedREIWzZVCIDYx+t22WAxX/YSJ3Fg7YepZZKhKD7nnXjCWYBc/c5vB9DX0RJn8RJ
	UBT4WxTLzzVmpyrw3yiyRVhHejpzvLTHJucJZWElVL4fKIsUX2EB08l4TK0Mb8DFAayze1yLp8P
	0reUD3ArfQWAL3dym+buGn7nf8qEoMhZ5Ak1y5CTv5N7cXlyT/wgjc5V3DFq0TRfwn6BWMBM1kd
	FbexECVO2M5E/9XC4gMSP82gW6OPTz0sirH4d/lftfIyYjABEmWvD5q71VjQzV/jiTbkoV0RlAV
	DcXFdtduilLnn49COLz2u6a0Ua/YEeVkkq/0JP5OBE2YjiDK1bLy6kHJOmSIsOgh51kBzNGLXYE
	nWv01CMG9aBVLkHVFAvQ==
X-Google-Smtp-Source: AGHT+IEmqT/lUXyiN8ceod6sU/U7EFtrMnM+e5fk6fD3+1ukT9mha5Hv4iZoX4ARNXq2o/UHiFp5jQ==
X-Received: by 2002:a17:907:970e:b0:b04:6858:13fb with SMTP id a640c23a62f3a-b04b1663673mr1575365666b.36.1757517213033;
        Wed, 10 Sep 2025 08:13:33 -0700 (PDT)
Message-ID: <4be69331-8002-47a3-a2e1-e34b12a5c5bb@suse.com>
Date: Wed, 10 Sep 2025 17:13:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/26] xen/domctl: wrap domain_soft_reset() with
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Christopher Clark ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-9-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Function domain_soft_reset() is responsible for domain soft reset domctl-op,
> and shall be wrapped with CONFIG_MGMT_HYPERCALLS
> Tracking its calling chain, and the following functions shall also be wrapped
> with CONFIG_MGMT_HYPERCALLS:
> - grant_table_warn_active_grants()
> - argo_soft_reset()
> - arch_domain_soft_reset()
> Wrap XEN_DOMCTL_soft_reset-case transiently with CONFIG_MGMT_HYPERCALLS, and
> it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - remove unnessary wrapping in stub.c
> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
> - wrap XEN_DOMCTL_soft_reset-case transiently
> ---
>  xen/arch/arm/domain.c    | 2 ++
>  xen/arch/x86/domain.c    | 2 ++

What about PPC and RISC-V? They have the function in stubs.c, but not adding
the #ifdef there increases the chance that when the stubs are replaced by
real functions, the intended #ifdef might then be forgotten to add.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:16:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:16:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118469.1464241 (Exim 4.92)
	(envelope-from )
	id 1uwMYl-0000aw-By; Wed, 10 Sep 2025 15:16:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118469.1464241; Wed, 10 Sep 2025 15: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 1uwMYl-0000ap-92; Wed, 10 Sep 2025 15:16:35 +0000
Received: by outflank-mailman (input) for mailman id 1118469;
 Wed, 10 Sep 2025 15:16: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 1uwMYj-0000aj-JO
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:16:33 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 1f3989f3-8e59-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 17:16:28 +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 AD96716F2;
 Wed, 10 Sep 2025 08:16:18 -0700 (PDT)
Received: from [10.57.67.148] (unknown [10.57.67.148])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 99AFA3F694;
 Wed, 10 Sep 2025 08:16:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f3989f3-8e59-11f0-9809-7dc792cee155
Message-ID: <9de08024-adfc-421b-8799-62653468cf63@arm.com>
Date: Wed, 10 Sep 2025 17:16:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

+Mark Rutland

On 09/09/2025 16:28, David Hildenbrand wrote:
>>>>>>> Can't we just use an "enum lazy_mmu_state" and call it a day?
>>>>>>
>>>>>> I could envision something completely different for this type on
>>>>>> s390,
>>>>>> e.g. a pointer to a per-cpu structure. So I would really ask to
>>>>>> stick
>>>>>> with the current approach.
>>
>> This is indeed the motivation - let every arch do whatever it sees fit.
>> lazy_mmu_state_t is basically an opaque type as far as generic code is
>> concerned, which also means that this API change is the first and last
>> one we need (famous last words, I know).
>
> It makes the API more complicated, though. :)

Somewhat, but in the regular case where enter() is called followed by
leave() there is really no complexity for the caller, just an extra
local variable.

There are complications where we want to exit lazy_mmu temporarily, as
in mm/kasan/shadow.c [1k], but this is in fact unavoidable. Chatting
with Mark Rutland, I realised that to truly support nested sections,
this must be handled in a special way in any case. To be clear, I am
referring to this situation:

__kasan_populate_vmalloc:
    apply_to_page_range:
        arch_enter_lazy_mmu_mode() {1}

        kasan_populate_vmalloc_pte:
            arch_leave_lazy_mmu_mode() {2}
            arch_enter_lazy_mmu_mode() {3}

        arch_leave_lazy_mmu_mode() {4}

With the approach this series takes, call {2} is made safe by passing a
special parameter (say LAZY_MMU_FLUSH) that forces lazy_mmu to be fully
exited - and call {3} will then re-enter lazy_mmu. This works regardless
of whether __kasan_populate_vmalloc() has been called with lazy_mmu
already enabled (i.e. calls {1} and {4} can be nested).

On the other hand, with a pagefault_disabled-like approach, there is no
way to instruct call {3} to fully exit lazy_mmu regardless of the
nesting level.

It would be possible to make both approaches work by introducing a new
API, along the lines of:
- int arch_disable_save_lazy_mmu_mode() (the return value indicates the
nesting level)
- void arch_restore_lazy_mmu_mode(int state) (re-enter lazy_mmu at the
given nesting level)

This is arguably more self-documenting than passing LAZY_MMU_FLUSH in
call {2}. This API is however no simpler when using a
pagefault_disabled-like approach (and less consistent than when always
saving state on the stack).

[1k]
https://lore.kernel.org/all/0d2efb7ddddbff6b288fbffeeb10166e90771718.1755528662.git.agordeev@linux.ibm.com/

>
>>
>> I mentioned in the cover letter that the pkeys-based page table
>> protection series [1] would have an immediate use for lazy_mmu_state_t.
>> In that proposal, any helper writing to pgtables needs to modify the
>> pkey register and then restore it. To reduce the overhead, lazy_mmu is
>> used to set the pkey register only once in enter(), and then restore it
>> in leave() [2]. This currently relies on storing the original pkey
>> register value in thread_struct, which is suboptimal and most
>
> Can you elaborate why this is suboptimal? See below regarding the size
> of task_struct.

Suboptimal in the sense that we're allocating fixed space for each task
that we are almost never using.

>
>> importantly doesn't work if lazy_mmu sections nest.
>
> Can you elaborate why it would be problematic with nesting (if we
> would have a count
> and can handle the transition from 0->1 and 1->0)?

It doesn't work in that specific patch I linked - but yes it can be made
to work if we have both an extra task_struct member to store the level
of nesting *and* an extra thread_struct member to store the saved pkey
register value (both of which are only used while in lazy_mmu).


>
>> With this series, we
>> could instead store the pkey register value in lazy_mmu_state_t
>> (enlarging it to 64 bits or more).
>
> Yes.
>
>>
>> I also considered going further and making lazy_mmu_state_t a pointer as
>> Alexander suggested - more complex to manage, but also a lot more
>> flexible.
>>
>>>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>>>>
>>>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
>>>> want to use it - at least that is how I read the description above.
>>>>
>>>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
>>>> that do not follow this pattern, and it looks as a problem to me.
>>
>> This discussion also made me realise that this is problematic, as the
>> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
>> convenience, not for generic code (where lazy_mmu_state_t should ideally
>> be an opaque type as mentioned above). It almost feels like the kasan
>> case deserves a different API, because this is not how enter() and
>> leave() are meant to be used. This would mean quite a bit of churn
>> though, so maybe just introduce another arch-defined value to pass to
>> leave() for such a situation - for instance,
>> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?
>
> The discussion made me realize that it's a bit hack right now :)
>
> If LAZY_MMU_DEFAULT etc. are not for common code, then please
> maintain them for the individual archs as well, just like you do with the
> opaque type.

I see your point - having them defined in  could be
misleading. I just wanted to avoid all 4 architectures defining the same
macros. Maybe call them __LAZY_MMU_* to suggest they're not supposed to
be used in generic code?

>
>>
>>>
>>> Yes, that's why I am asking.
>>>
>>> What kind of information (pointer to a per-cpu structure) would you
>>> want to return, and would handling it similar to how
>>> pagefault_disable()/pagefault_enable() e.g., using a variable in
>>> "current" to track the nesting level avoid having s390x to do that?
>>
>> The pagefault_disabled approach works fine for simple use-cases, but it
>> doesn't scale well. The space allocated in task_struct/thread_struct to
>> track that state is wasted (unused) most of the time.
>
> I'm not sure that's a concern. Fitting an int into existing holes
> should work
> and even another 64bit (8byte )...
>
> I just checked with pahole using the Fedora config on current
> mm-unstable.
>
>
> /* size: 9792, cachelines: 153, members: 276 */
> /* sum members: 9619, holes: 20, sum holes: 125 */
> /* sum bitfield members: 85 bits, bit holes: 2, sum bit holes: 43 bits */
> /* padding: 32 */
> /* member types with holes: 4, total: 6, bit holes: 2, total: 2 */
> /* paddings: 6, sum paddings: 49 */
> /* forced alignments: 12, forced holes: 2, sum forced holes: 60 */
>
> Due to some "arch_task_struct_size" we might actually allocate more
> space.
>
>
> Staring at my live system:
>
> $ sudo slabinfo
> Name                   Objects Objsize           Space Slabs/Part/Cpu 
> O/S O %Fr %Ef Flg
> ...
> task_struct               1491   12376           24.8M     
> 721/25/37    2 3   3  74
>
>
> I am not sure if even an additional 8byte would move the needle here.
>
>
> Worse, it does not
>> truly enable states to be nested: it allows the outermost section to
>> store some state, but nested sections cannot allocate extra space. This
>> is really what the stack is for.
>
> If it's really just 8 bytes I don't really see the problem. So likely
> there is
> more to it? 

I suppose 8 extra bytes per task is acceptable, but some architectures
may want to add more state there.

The one case that is truly problematic (though not required at this
point) is where each (nested) section needs to store its own state. With
this series it works just fine as there is a lazy_mmu_state_t for each
section, however if we use task_struct/thread_struct there can be only
one member shared by all nested sections.

- Kevin


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:17:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:17:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118480.1464251 (Exim 4.92)
	(envelope-from )
	id 1uwMZG-0001CR-MY; Wed, 10 Sep 2025 15:17:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118480.1464251; Wed, 10 Sep 2025 15: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 1uwMZG-0001CK-Jt; Wed, 10 Sep 2025 15:17:06 +0000
Received: by outflank-mailman (input) for mailman id 1118480;
 Wed, 10 Sep 2025 15:17: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 1uwMZE-0000x5-Ni
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:17:04 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2413::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 343d2d5e-8e59-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:17:03 +0200 (CEST)
Received: from BYAPR05CA0013.namprd05.prod.outlook.com (2603:10b6:a03:c0::26)
 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.9094.22; Wed, 10 Sep
 2025 15:16:59 +0000
Received: from SJ1PEPF00002311.namprd03.prod.outlook.com
 (2603:10b6:a03:c0:cafe::72) by BYAPR05CA0013.outlook.office365.com
 (2603:10b6:a03:c0::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 15:16:59 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF00002311.mail.protection.outlook.com (10.167.242.165) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 15:16:59 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 10 Sep
 2025 08:16:56 -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: 343d2d5e-8e59-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=n93j8innBKuJuVUUwFqUcFCMNoCSuv+XN0q9R5+CjpNNF+wIa9GmDWmsayir2xcDaoLIKoiHrElq5JdRJ40KIvkP/26oTM9rBX4pHKI+1vDUESzCLEi9qFpliLY838tSLS71qMUUnNmN/FZlQu1cO9XJWZcSx9+NZZuAkPwGr3ks0kxYQz2RtHczN1L2UaMU/46MfpvxgeoQ3e6T50FFoWf0ec9d0gFOR4aPr8JNhA9XaScEEEyowWkzzWcrJCzRe3PABncEKz+ZsixdBrS7iDGjhJIUYqpz8UVXIgeHMLVbVwEWpqgwomDOBeKeG8E949WcofRequTo6+LrlKLhQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wlCm9wSUY/e2X1TE/PRNyvakaoCfl+WJ+Dh7fT51WK8=;
 b=St7OphjDZeww2kd2+nc4+kn4nk+PZ9yI5IILBSTrn+RLBtAsSQyzMxnRHC67vcRHLDkQpn+PvYofar/7wTy5Pcb4xeq/64cmfib2AQhN7TQL+yjCJOrjtQXu0nxRRoyaqzH6Huux0Ts5uxF0GyewPePnsnOfJ8dBtxqqZOwuyZsU3dfnRgjxeDiqkgSDW9wTy+kMs8WLodEiMFkwupx/c4BdUA4CxUaG9Hr3gCYiRvXndEpOvPSXUd7IBQMQv32sbe/0gIq6HTGz07jaghn+RF6G60KRTW4bjWTzmMQ4yGlU5G22xdz52RBt2LlXiibl2c/LAcKL3yVgsHSU1oAlHg==
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=wlCm9wSUY/e2X1TE/PRNyvakaoCfl+WJ+Dh7fT51WK8=;
 b=o3RBHhzYLq/SK1T5HhadtV7LmD9y31QmDW5uisRakIq4iBYVM8G96oBo9CZi4VoSI+DGI07PudRHycRc8VWKRok86oWbzlSJIMOOHGNrAS2Y5wzg3W1jxTQ9xP3fJygP5jdVI9rSL36jpFMlp40GSMuWRtkPi8tlK2fL7/gSr9k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 10 Sep 2025 17:16:54 +0200
Message-ID: 
CC: Anthony PERARD , Grygorii Strashko
	, Roger Pau Monne ,
	
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
In-Reply-To: <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002311:EE_|DS0PR12MB8813:EE_
X-MS-Office365-Filtering-Correlation-Id: 1209682b-12d4-4e5e-874a-08ddf07d164f
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?ZDRsdW0yMU1DeDk0UVNtZG5TaHMzZ1dlS0RSWEk1K2RPVVI0NFNBRkdZb0pB?=
 =?utf-8?B?S0pibEYxTmNzT0ZQaHVqeHZSOGdOaDF2dU5uQkdXWTJQUlFYZHBrYXc4Qnl3?=
 =?utf-8?B?OEo1SW9paUtaa2R4UnRMRDBLOC9oeFZMZEZqS0JXOTRkVHY1TkRsR0VYN2E5?=
 =?utf-8?B?d2JaUWwxelJYbDQ0SW8rdytFaTBzWjFNZCswOUZLS0tVdUlTL0ZzR2cwcjM4?=
 =?utf-8?B?YjIrQjV1VDNwRjErZXBwb2F4UWxuSlZNWHNMcGxRODBtZzlDWmZYOW5BMDR1?=
 =?utf-8?B?OG5RSnJCTExlZk5VZFpIc2M2cERlUzlCNi91ZWYzME0vQ2tHbWp0VnJoa0Js?=
 =?utf-8?B?YzJDVjJoZDFYdlo3NE42Ti9qSVh3RnFwUDNMcUR5bFZvRFlKcE9qZG5vd1JL?=
 =?utf-8?B?ZXBZNmZ0WGxzeGhrWVN0SkVkcmJrT1ppWWUxc2Vad0NJV2FXS2M2WlJsUDN5?=
 =?utf-8?B?UStpZXpTaXBnUXBSNkxEa2x1djl4RS9LcGpHeHp2bWVsNUk0NXN0UDdKbGNn?=
 =?utf-8?B?Wm13YnN6K2cwZ1FJQTlIdlhUa25WUXVaa0syVExGRFNLYU40R3JieEV2V2tR?=
 =?utf-8?B?NXJSTGFIOXNTN2taZG9mT29EOStxWXY2YXMzNFk2VzhTNGtUYWJnNXlVMFBt?=
 =?utf-8?B?aTdPQm4rUDhsd3ZHcm5CUWFJalBqMzBOMTRaSWZoWmc2ZENXcWF3d1EzOFF4?=
 =?utf-8?B?K2hsSVFaRC9QRHJiZWdYZ2JaMzlxeHJaWGUyd0pRR2VhUXFKZUk1VS9GWEUx?=
 =?utf-8?B?U3lwQ3h0U1NPTk10UG80YTFyOTFWVlczYWg4a3pweXZOM0JFUVdMYUNuQ3JN?=
 =?utf-8?B?dVcwN2tkcDlpWEo3MDZNdmlCYnNVRXZ0dUkyekF6TWEzNnlsMWIvUmJ4cGM3?=
 =?utf-8?B?OURRdUFtQ0JaaWM1WFNvdmE5a1ZWbzNPdVRURkVuSEV6VVJUbDRLVE5jc2xp?=
 =?utf-8?B?NGJweXhjYUtFRFRsdXowNXo5SXkvQW9yNS9JdXk3ZmxMY0pUaDNJYzdJT2xn?=
 =?utf-8?B?emwvdXRxR1haS2t6Wjh0b2lPWUlLKzlDdzhCOVozWGVEWWhqeEJ6ckJrRWtT?=
 =?utf-8?B?NysxcWF1UHFYdGlPNU5ER1hpRERkbGgyUDRVdVQvL0hnMUNvbE41enNLN05z?=
 =?utf-8?B?eEdCMGlzSWpxMFdtZ1lRZjlyVGUwOVNsRjZGa1cvN1ZxcGhjdnZKNUx2akt5?=
 =?utf-8?B?Z0s2ZjhTeDYwYnlQQkRqZHJSaHQ0ZzNKcWU2RkNqNUpjYUdCVFdsbjNEZFkw?=
 =?utf-8?B?cXkzTmdjTkJLOEN2dWNpZ1VIN040eFRONXdVZE9rV2RmbFZtS1JFSlFIQ0lK?=
 =?utf-8?B?ck4vNmVmRmcrWFN4dUNZd1oxV0t4d3dwSGMwV2JIaEN5VWJRbUpsYU1KYSt2?=
 =?utf-8?B?RlBGNDdScjV0ZklNemhDZEpLQ0N6eGxhZGNTYTF2Y09odjlNNkplY2wyKy9Z?=
 =?utf-8?B?ZjNtZys0TDlFc2V6Zis2c28xNmliQjJQOGVVbXJMKzBENmlMdkdNbG1mRGhq?=
 =?utf-8?B?dkpaQlN3NXd2MTBLd3RPSVBNdjNwS0xlMFYweERoajE3Q0tJODFLRG9LSHRq?=
 =?utf-8?B?bWw5cVpqejhROTVsbnhVVE9CR3ZrcUhBZ2c4T0srSnF6NXc1QVdsSmMySGpt?=
 =?utf-8?B?UFY4d2hHSFpLWnd0RXE2bTJTVVUyUFpWNVByYkY0UzNaSy9HQkN3c09saVBn?=
 =?utf-8?B?dk9Ndy9PUnBCSE85SS9IYWdTSCtyUmI1WnBpNnBMVXFXa1lUMjhHaXZ3b1dK?=
 =?utf-8?B?cFFJVGQrY0pZT1BUVFl5SGo4WXlUY2cramkzeFdJUEpiVndtTy9WUElZMk1R?=
 =?utf-8?B?em9jeEN1dGNjL0R2RjVUNmJRR1ZZcHlKUHM4blpGTHh6NVJZWHdyK0xTWlRE?=
 =?utf-8?B?RnN2SmpWQzh3c084bVhQMDJQVE4yK0NoZ2JXQ2U4SnVNTVlvVFJNQlVKOE1k?=
 =?utf-8?B?dDh2dklhK2haVEZhQjhiVnJJL0FzY1A1SUVLV2Q5c1hSN085ck02ODF5WDBU?=
 =?utf-8?B?bmtZSWRBWkRGcXRTNE5RQjA2Mm14WU1iSG82WUFIOG1JME5nWWFKOERtZ2Jv?=
 =?utf-8?Q?BS0w0v?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 15:16:59.1029
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1209682b-12d4-4e5e-874a-08ddf07d164f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002311.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8813

On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>> CPU hotplug relies on the guest having access to the legacy online CPU
>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
>> this causes the MADT to get corrupted due to spurious modifications of
>> the "online" flag in MADT entries and the table checksum during the
>> initial acpica passes.
>
> I don't understand this MADT corruption aspect, which - aiui - is why
> there's a Fixes: tag here. The code change itself looks plausible.
>
> Jan

When there's no DM to provide a real and honest online CPU bitmap on PIO 0x=
AF00
then we get all 1s (because there's no IOREQ server). Which confuses the GP=
E
handler.

Somehow, the GPE handler is being triggered. Whether this is due to a real =
SCI
or just it being spuriously executed as part of the initial acpica pass, I =
don't
know.

Both statements combined means the checksum and online flags in the MADT ge=
t
changed after initial parsing making it appear as-if all 128 CPUs were plug=
ged.

This patch makes the checksums be correct after acpica init.

Grygorii noticed the checksum mismatch while validating an ACPI dump on a P=
VH
Linux system.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:31:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:31:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118500.1464261 (Exim 4.92)
	(envelope-from )
	id 1uwMnG-0004D9-Uh; Wed, 10 Sep 2025 15:31:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118500.1464261; Wed, 10 Sep 2025 15:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwMnG-0004D2-Qs; Wed, 10 Sep 2025 15:31:34 +0000
Received: by outflank-mailman (input) for mailman id 1118500;
 Wed, 10 Sep 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 1uwMnG-0004Cw-B2
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:31:34 +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 3ac2b891-8e5b-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:31:32 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-b0787fa12e2so155111066b.2
 for ; Wed, 10 Sep 2025 08:31:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07830aa78bsm186915566b.29.2025.09.10.08.31.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08:31: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: 3ac2b891-8e5b-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757518292; x=1758123092; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kB/ZzoS93GS1qbaxrpjY6gLcgDq2wa5Z+qCvub59zO4=;
        b=gB9Z0yd9SZnYt2vXY8RHQAq8hI1eAqNTkuaGo9ddduOB1tDlcbQGqGr5LQI5pYEzm2
         z+IkUVlE+XlbBSBPdvjhudaWU/lJ/nZQgQgErXjUByKZ7hAR/J/4BdgrH3UQjno9iPEX
         0tKLXx2ZofAP71bCs/088zxk1FJ0osWE/ChDn4IUzBgmdYrFPXZTiX6Tq6AFH3LRZD5M
         4Fkj6Ib2oSLqVHZT4d+hJDfo2CAQc2haT8unGa7qIJCktmLpPXQJVh6YvFRkHsaAtCbk
         N4kwnq4jAzuoFpstp4yY6wYPvqwUM76UMndfbMddeqzudAo1FXei9GZCBKPeZV0WtGNk
         GmAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757518292; x=1758123092;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kB/ZzoS93GS1qbaxrpjY6gLcgDq2wa5Z+qCvub59zO4=;
        b=wR/0KQa628d/Rlp1vHVjZ+3hc20Q4nyNOBW/jZd4GSVKlavUrVL+rZv50Of6UiPTZq
         4winR1Sti9azdiehbzvEQ3YPO1KR5eTtHoYmqbk2Hyzd3ZXExgrAfiS02l3kN7MiqZ1e
         IuLFfZPcXvs473jd7MyRg700fifivl921HNgXDANAUY97GLz4JViETV8IOftw9iVqzc0
         7AZbIDnud5FBV0ShntMNU0QFZ4qumx+vi2YsCtggLoeIEPi9EzGupEoq4C1Dt1wwKQ5Z
         l0wVK/54y3uf+6dEPxRKqnQxn4IytSU+U77rO8v7EdbXf06xzZrzka+JHU8N4JcQsCVx
         gl3w==
X-Forwarded-Encrypted: i=1; AJvYcCXeegAn+v3OBeCChYyhN/87sTCivqMHZfwWnXPTTsef/TPQPVmjo4WRdJhegySQMd0HUGX5J5AQ02g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtuWzHGoPKU7Rxfft89yNO92FiRODHVWMB7tFwbcDJ9UghWzLb
	nZVeZg44QvHs1kQUqdZWlo/4CY0g5Cviu7ln32bZjRMuVYKMViHSj36gFRFAubN6WQ==
X-Gm-Gg: ASbGncs14/5VMD4W/nMuKCFmj7XR180w1itQAzkOE8tfewhlUUx48HTl5EDCiVNBrWN
	CdjVOB+V8n5nsW068OIY9OUrAa6x50nyAvj3MQjo5FtkP2ItWW2mb4SMHD9JXm8y4DLP1kDRu3u
	kpYSx/JFLjfRt1g2xn9msnGfPGRZYILyxkOdOohCEKQWQzOoIn1uv4+gFFLmjmxQpYrBvkkQsqI
	z6ZGwQUAuo2spCc41kMR2AqJOTJIvyXrnPJwc65jEr/ooq23FhEBY+rosTPAPYBrPXaJx8qS5Fn
	cJVVIN+XWVvu/czKc7Bd9ZDF05MOz9dkS/t2qevhiOQzqh+3a4oICGu33x+0Q1srezZLQrsF7rL
	h9oTXXLgCkMHCKnKtR9GjxDE4xYAMsDyv6iiiQOJFPyYk/vphJyJYZvu5gl2xOLfSlV55mGMDN6
	wWx7ymb2g=
X-Google-Smtp-Source: AGHT+IHleCDQL4+GPqsaYOFlop7ds0l8gQkKYiMNKwKZ2xROGiSLuQCl+hrKFkf/m1oR2UDciRTPhg==
X-Received: by 2002:a17:907:6090:b0:b04:1457:99 with SMTP id a640c23a62f3a-b04b1451f8amr1546138766b.14.1757518292204;
        Wed, 10 Sep 2025 08:31:32 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 17:31:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 Roger Pau Monne , xen-devel@lists.xenproject.org
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 17:16, Alejandro Vallejo wrote:
> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the guest having access to the legacy online CPU
>>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
>>> this causes the MADT to get corrupted due to spurious modifications of
>>> the "online" flag in MADT entries and the table checksum during the
>>> initial acpica passes.
>>
>> I don't understand this MADT corruption aspect, which - aiui - is why
>> there's a Fixes: tag here. The code change itself looks plausible.
> 
> When there's no DM to provide a real and honest online CPU bitmap on PIO 0xAF00
> then we get all 1s (because there's no IOREQ server). Which confuses the GPE
> handler.
> 
> Somehow, the GPE handler is being triggered. Whether this is due to a real SCI
> or just it being spuriously executed as part of the initial acpica pass, I don't
> know.
> 
> Both statements combined means the checksum and online flags in the MADT get
> changed after initial parsing making it appear as-if all 128 CPUs were plugged.

I can follow this part (the online flags one, that is).

> This patch makes the checksums be correct after acpica init.

I'm still in trouble with this one. If MADT is modified in the process, there's
only one of two possible options:
1) It's expected for the checksum to no longer be correct.
2) The checksum is being fixed up in the process.
That's independent of being HVM or PVH and independent of guest boot or later.
(Of course there's a sub-variant of 2, where the adjusting of the checksum
would be broken, but that wouldn't be covered by your change.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:35:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:35:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118514.1464271 (Exim 4.92)
	(envelope-from )
	id 1uwMqc-0004oF-Eg; Wed, 10 Sep 2025 15:35:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118514.1464271; Wed, 10 Sep 2025 15:35: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 1uwMqc-0004o8-B6; Wed, 10 Sep 2025 15:35:02 +0000
Received: by outflank-mailman (input) for mailman id 1118514;
 Wed, 10 Sep 2025 15:35: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 1uwMqb-0004nR-0E
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:35:01 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 (mail-northeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c200::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b586316d-8e5b-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:35:00 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DBBPR03MB6956.eurprd03.prod.outlook.com (2603:10a6:10:20e::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 15:34:56 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 15: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" 
X-Inumbo-ID: b586316d-8e5b-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mzOH9qnlbjuk3E6iSHtmX0bqZxviB8Zl2t/ln6IvyLhjW0plHpeEWvCkiQOvaQ8V3yCGijiM/uIThMKwnwzcFyjHDXJ6n6lRNBynkXF9CHk2N64zFyBkXV53wQrpA5mAYRkEfigLTjZzL5ogciBsNUykone1iNHKjsEYyZtbexuO0i9FZTUS8h0rzPO8+seLFDUamG/eY6Rvc67/FZVQK4ryBLfNsaePUwUTsiDblDy1SlvVZhim3nbvilQRfNFJjR73E2DDzS478/qXGD4a8f7EroEfz69igfiampFXKju6pNoIhbB18dMt0tpMRPFJIW2CoiDZ6Chpv445FzBWJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W1tJZWU2IlPQNrbhAJQ/MWSSAxIiK4ZF+maCctw/PNo=;
 b=JOPEsaKTc1SnnJnC5I/1v7hQhwNF7djmhm5AIF7Xn59p8Plm909A/MnU6MXHk5jgmOeYii2ZsvEAQC6P1Fv0AMYZ1nbl5vi6yp6UJ4lqdOvZ30TRazbNN9U48Gj7aqSEcP91Wo0mQavRi2p3fp/LqhJpp0MMbhQ2xVNfEUC7c+H0cZnA7r7++56vQ8tz8QSmrX2bAxfsg6YrEmsmLEUODFR1P0Z23AeVnknA6usmgg6uI9Jl91gJOqE/5KD2rq7L6iyVMVtYE2zDNbeZgNTTsqjLfpTHlvdi/3qmTz66DYlGwRfDKEdm2rCstJOmN5bUX/6j51auShiSFKjhN1Zi/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=W1tJZWU2IlPQNrbhAJQ/MWSSAxIiK4ZF+maCctw/PNo=;
 b=HdSuatDf/nRXso8riza2T6KcWPrpDMNV+9jySsMIPcnu7/5Wdoj13UvHvBA1sNAerML1KsOrvxkval8yQJgaLEWjzRsVlLtHhMS+x8cmhn7UCjHwtYcNqtfS5c+RkIIzOF+Cl2QBfokKN0WKANa3mN5p11UuscyOgvTKJlkAAUSda20HV/zRjG1exK6cx1v40OXu4Mlr0/admtDXrnCmIT1h7QGcicDmjUHBJzF1nTFHsZmX8C8hyewfjhxIGhc2+7quA5Cl/B/yYRUgPTePrQSmp8QV7F8P0BFizxOvzlbvq4SxYvfD8RTYXcBuvPzwGRotvJsd3AmxsnngNpnMuA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <0c879b3c-1b24-416e-a821-be116bf688f9@epam.com>
Date: Wed, 10 Sep 2025 18:34:55 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
To: Alejandro Vallejo ,
 Jan Beulich 
Cc: Anthony PERARD ,
 Roger Pau Monne , xen-devel@lists.xenproject.org
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0111.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9c::15) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DBBPR03MB6956:EE_
X-MS-Office365-Filtering-Correlation-Id: 4fce04d3-6d31-4047-cc2a-08ddf07f987c
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?TloybzBtWFRRNWtFbGhBZWNVbDZxR014eVJDQ3hGQ2VVUmZCZUFMVEFSUGVI?=
 =?utf-8?B?NTZ3S1UzM05tbCt2OUVRUVpDaktpdjRVd2NVNnNZZGpua0pQNDU3dEM3SURj?=
 =?utf-8?B?T2Z4MzAzb1puL0l4NUhHc0wrTVVCeVhqMjRyWFF4WW82U2EzNklPNkt0MXRv?=
 =?utf-8?B?bWVuS1V2WXRVU0gvckVNcWNSSlZjazdMOHE0WkV4TTZVWVpRQnZYOTE4Q1dt?=
 =?utf-8?B?VnhwNVU5ZW1WVHVpbzg0eTE2d3NiTWl5eGJYRXU1MnRHa29kb05OME5scXl1?=
 =?utf-8?B?N282MlVWams4ck5WOTNnd2lFSTZZUTZHMENTZ1FQcjJ5TXVhc29VU2pHTndI?=
 =?utf-8?B?VVBwUDRrTUl3L3VkRjM1ZnprZ0VORnI4RjUvc3lINW1lV2NpNnVLcjNzR21K?=
 =?utf-8?B?TmpOVnZtd3QrOVd2ajZrazF0QUVtWElCdTllMXJIS0pPUFJhNkdYK3BLYSt2?=
 =?utf-8?B?Qkp5R2xJVHkvSGs2cU4rTFByWFNUUGhOVDFLaHBGWUExa25ZN0lYYTgydVE4?=
 =?utf-8?B?M0N6TTNDdjhMN01GRFNXdzZyY2grakM0UXBtcXgrcGFhWVI0MEQ1N1AvaHlT?=
 =?utf-8?B?R2ovNW96SEhLOWtlOTMzUFZQRkFXTC82a0ZQUW9BV1Q0c1BBQXZzMEFJTVFK?=
 =?utf-8?B?YVo5b2RQMUxtNmRTZFNwSlFSUnI4ZSsrMkszNnY2Q3dTNTJnQjMwMDRwaDhq?=
 =?utf-8?B?alhCZk9BdExsejh6NFpOVVg3djR2N1pYL1VTMzduQ0FETDhVN1o0OWpuTTJD?=
 =?utf-8?B?VmgxVG1DOWJQUm9wcit3Rm5NU1p1U2ZNS0M3NFRnN0Y5cDJ4RDVjUlF3Y3Bq?=
 =?utf-8?B?NWdvOGI3NzJNV3pndmVqaGJaTGtFdXRuVmFwenVTVVBqVGZZQ3lXRHNoQ2Fx?=
 =?utf-8?B?aU1kcEZOMHdEOGZuODhmdE9Ob0RabmpBQ2xqTW9hcGlRRHQ2WkE5VzZDbmpX?=
 =?utf-8?B?TXk3OHpFSU1uNDhoTUpuLzlKbE5zZUFkdVpDQ2piMTlmMDYvTTExcU1GRFEz?=
 =?utf-8?B?blpWdVFCYmtSV2tqUGtCQWx6SmZEZzJYRlhOYmdsQUsyVGRIeGM5dmp6QVA4?=
 =?utf-8?B?REsvdFBRWS9OL1RTZUR0czFlR1FWNFZwS2ZiTzlIN2VRSjFZM2s1Si9VbFhl?=
 =?utf-8?B?YWF3a3ZHR3BYRDRqbVlrdDZVSEU0T2lCQkZyOEtONkNqa0MxSittdEUvM0Zn?=
 =?utf-8?B?WDdrUGxuTjVLcW0wTC9GQmxSZkNST3RuTjZ1UkZwSmtKYm5OZ1V4SWlIOVNh?=
 =?utf-8?B?VVkwZ0VtSGpkV3U5N0IycXhTYytSb0NVY0ZLRWFwQWYxMmRUVFRiQkxsR3hx?=
 =?utf-8?B?WG82V2Vxb0piOXhMRi8xN0I4M3lkU3ZacUZ3WHlEckpiSzNxN1Jsd1hPdEtQ?=
 =?utf-8?B?V0lyN053ZnhMMm5CL1ZIcEVTdTJBYy9MdmVFdk04TStsSEhHVTZwNCs1M0Yy?=
 =?utf-8?B?Rnp0SGJ3OVgyb1FBZit6clk5N0xCMHZ5eXJBa0JDMWR1YUpGZCtzZzcyMGpw?=
 =?utf-8?B?NjBBY3M3WFNqVEtMeThURDlvMDJKL0FSMDN6SEtkalNTZU9WdE5oY1ROU2xr?=
 =?utf-8?B?bEp1cDVxSUorRG15TnBib2xXVG1iZlNrUHpPd0xseEh5NVJYaUU0MkJFb3c0?=
 =?utf-8?B?c1JmblRnVTQ3bjJBTXhkeVVYTksxZWtqVVE3Q1lRcFRiYXVGNWpFdEVaTmx6?=
 =?utf-8?B?dityQnlhUUI2VThVUXJheTE4RXFxVjVkRktnVHFkM0E1MXlUMEl2cmI0dS9y?=
 =?utf-8?B?c05ESE9BcmpWUnlCeFRFUk41SWplVytZSmo3VkpDQzROUU92akhMdjBWLzNR?=
 =?utf-8?B?UnBhY3lWVlA2c1MxZVdTZVFnalpLUEc1Z1d2TVZiUjBvcEtoZUlGeFNzMjc3?=
 =?utf-8?B?c3RIUGQ5Vlh2NVB2S21XaWFkTmhLbWgvWGl4N1lPTXM4NFBjWjZMSC8rU1lx?=
 =?utf-8?Q?VSKgeuosjAw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?d2hKaTlOYTdhV0RtVWhQaXBhZnRvMXcwdXI4VzVCUGRBTzV2S0NaTFJyZ3d5?=
 =?utf-8?B?TVJwdklMNG5mWEFxZkxXQU5yYUxvbmFNNTM2V0hzb0Z5UUNwckdYUXpobnR1?=
 =?utf-8?B?eFJ0OTl6R3VsS212L0ZQVmRpQmczd3J3aWMyZjVaazVjR3c1OFNRYnJBVjVM?=
 =?utf-8?B?cGNzMDRiZUFEMGJRQzRjU1BBSVBzTTh1bktKUXFNdzVEY3JRYmN2b0FXM3V2?=
 =?utf-8?B?S0ZjQUMrTmorMmRISjFBM1ozMkxYS1pyRDJkbVMrMU4rVWtBUGUwQ0ZlbXBH?=
 =?utf-8?B?SlZnN3EyWGlSSVhoZTFMU29FTFdYb2dEbExiUHE1eXdXSCtuWEd4dUhCSW1v?=
 =?utf-8?B?cnlQdU9tZWhtVitkQUl1T0pMYzU5R3MrYUQwTlhYR2I0bmpjRUpPb21JMFo1?=
 =?utf-8?B?VVFRdGRZYmRlZWFKdit3YzFGeTIxMU03NEJyTWRVcmc1UWxLZG1xdC9ua1Ev?=
 =?utf-8?B?Z21JWjBuQnpYUWk4ZEl6YXVlYjN1cTErMXhVZ2p0MlNiSTA2VmIwQlViKzJD?=
 =?utf-8?B?cW5GeVhnOWpkTmMxY25wRmRXZFd0RnpiZGlKa201eFhPZ21DeHAvck5VN0tt?=
 =?utf-8?B?WFAwcDlUbXByWlE0anhpOHRIOGZJT2VZZk9hc2NHUFVRbmFmU011c0dmb0pq?=
 =?utf-8?B?OWRyanFUQkFxRHJIamsvY0F2Mjk1cGxTeC91cVR0VUlwakJpRlZDM3FETm1h?=
 =?utf-8?B?UTlkekMxYzNuNHpwOXV5NWY2QnJBbk5xNHBIWFV6RUtkVkYrR3ZIZDFUUzQ0?=
 =?utf-8?B?ZktDZ2dqeHZoSytieVVuWUgrRlJFNytLb3oxNUdmWUlYWk0xMG1sTkg2TDB3?=
 =?utf-8?B?L0Jrd2VYbDdaUDJIMDJvMjk0QXgyVjhwU0RBUHlxWStGWXRid2RoejBXbmZL?=
 =?utf-8?B?d2FvekJTV290MkN5SlI1WkgyOExQUCtleHFoRDZKd2ZsTVUwR2lJUE1FNUU0?=
 =?utf-8?B?WGYvVkhRRXBUTFd5Zkoza2pteWlibTFkM21YRDNMM2hvczRtTkFuWTl4eVND?=
 =?utf-8?B?c2hpVnNiOXN6NlMyN1BPVzRuMlp5TjFkSE1TVjFYRW9SNnh5UjFpR3c4dUdX?=
 =?utf-8?B?SDdjT2FkejdGWWN3YUF6VXlNRHhlUlZFRUY0MHlUT1dnT3gzUWRpS0kvQzFv?=
 =?utf-8?B?aEdORkd0T3pEbjNGMjl1eS83aDRmNXdqT3E5SlFYenVma2pnNHJtcHdWYUc0?=
 =?utf-8?B?L0NwaG1MbU9aemtDWnh6YmxSNUVCL24zR29IMnBxUGdRVGdpcmZsWkxLdVd1?=
 =?utf-8?B?UTlqVktCMWplR1BmU2U0b1d2eFVwbm1tU1hYZ1lzUit1cFY5bk9pTEdRazdZ?=
 =?utf-8?B?VnVLMTd4ZS8zc3JJQnF5b0pOaWdDcHNGbHpRWFN6d2ovb0dTM2ZHZWgyNGx2?=
 =?utf-8?B?Q3hEZDFabUc5QXF5RldQMTZuLzkwMDV0ZUZLNFA5WjRzUHp2UkYyY3hWTFBY?=
 =?utf-8?B?NjB1cWlaWUZrcWdCVlZkZjNKcDlvT3Q5ek83NENsSklXWHM3bUNKRFkzeVYx?=
 =?utf-8?B?bFpuQ2IvdlRKcU90SS9PUHh2UXV0Wjh5OFErTjZTa0NLQ3ZUTVg3M2hYSTJY?=
 =?utf-8?B?VGxjQTkzMi9OV21leU1nMWJUT1AxUlJ3dTl0Q0lnRzcwWmthNEFwVDRiWkRF?=
 =?utf-8?B?WE1yNTlVdmZIVk9xaDhqbUF4M0RlWDEwVUM0T0xENlFpU2pBbDVNZ2Y0S2lH?=
 =?utf-8?B?cUFwT3R2UVBqNTJYM2diMEdZQUpDRFpUUUdzT1Z0eVlhTnZXVjBqZG1iN2ZE?=
 =?utf-8?B?eUpTd0NMaGdrOCt5Vmh3SmJOQzJVdmF1d3ZTZzBhOXVTYWZGaE1uY3lnR1Vm?=
 =?utf-8?B?RnVsWUI3aWhTWGJuemdCbWZMQjlqREVsWnIydmYzc3lad0RsZ3BUS2hNOGxR?=
 =?utf-8?B?WmdKU3BNVjYrVmcyOW1oNSt5aVhCTDNWbmpWVjR4bmptbE1YZ25lbS9oZDQx?=
 =?utf-8?B?KzU2bWpUbUNud0dxSGxuUGJtTTRBUWREemxrdFFRUzZCcCsvTk9UT3Q2NVp0?=
 =?utf-8?B?bFhGM3pWZ0Jhei9kNW9uOHhwSzZWZXFzNldjMlFjM2RtMzlKaXRWbTVscGlP?=
 =?utf-8?B?MmR0QnlBOWhvbUZhZGFPRUF2RGIyb01LN0JVSU9SZEl6Y0s5bm9naE9QTVFI?=
 =?utf-8?B?bXhOS0NJUEtIZlJ1YVVuODZGRVljSXZXQkNSSFBteXVGRHFPb2NDYzIwNG5x?=
 =?utf-8?B?S3c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fce04d3-6d31-4047-cc2a-08ddf07f987c
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 15:34:56.7125
 (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: m4iAA4unpyML+mkHIu6wcC5xmegwaxKsiCECj1/yTQs12bHACCTPhA2taP5mxp9fNUAwbtE3sqLg5AsJqFp/KgIPkEvgWhPVExwltBT7f1M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6956



On 10.09.25 18:16, Alejandro Vallejo wrote:
> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the guest having access to the legacy online CPU
>>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
>>> this causes the MADT to get corrupted due to spurious modifications of
>>> the "online" flag in MADT entries and the table checksum during the
>>> initial acpica passes.
>>
>> I don't understand this MADT corruption aspect, which - aiui - is why
>> there's a Fixes: tag here. The code change itself looks plausible.
>>
>> Jan
> 
> When there's no DM to provide a real and honest online CPU bitmap on PIO 0xAF00
> then we get all 1s (because there's no IOREQ server). Which confuses the GPE
> handler.
> 
> Somehow, the GPE handler is being triggered. Whether this is due to a real SCI
> or just it being spuriously executed as part of the initial acpica pass, I don't
> know.
> 
> Both statements combined means the checksum and online flags in the MADT get
> changed after initial parsing making it appear as-if all 128 CPUs were plugged.
> 
> This patch makes the checksums be correct after acpica init.
> 
> Grygorii noticed the checksum mismatch while validating an ACPI dump on a PVH
> Linux system.

Below is "acpidump -r 0xfc000000" from PVH guest (not dom0) for MADT before/after this patch:

Before:

Firmware Warning (ACPI): Incorrect checksum in table [APIC] - 0x59, should be 0xFFFFFFE3 (20250404/utcksum-208)
APIC @ 0x0000000000000000
     0000: 41 50 49 43 52 00 00 00 02 59 58 65 6E 00 00 00  APICR....YXen...
                                      ^^ incorrect
     0010: 48 56 4D 00 00 00 00 00 00 00 00 00 48 56 4D 4C  HVM.........HVML
     0020: 00 00 00 00 00 00 E0 FE 00 00 00 00 02 0A 00 00  ................
     0030: 02 00 00 00 00 00 01 0C 00 00 00 00 C0 FE 00 00  ................
     0040: 00 00 00 08 00 00 01 00 00 00 00 08 01 02 01 00  ................
     0050: 00 00

After:
APIC @ 0x0000000000000000
     0000: 41 50 49 43 52 00 00 00 02 76 58 65 6E 00 00 00  APICR....vXen...
                                      ^^ correct
     0010: 48 56 4D 00 00 00 00 00 00 00 00 00 48 56 4D 4C  HVM.........HVML
     0020: 00 00 00 00 00 00 E0 FE 00 00 00 00 02 0A 00 00  ................
     0030: 02 00 00 00 00 00 01 0C 00 00 00 00 C0 FE 00 00  ................
     0040: 00 00 00 08 00 00 01 00 00 00 00 08 01 02 01 00  ................
     0050: 00 00

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:38:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:38:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118530.1464280 (Exim 4.92)
	(envelope-from )
	id 1uwMtV-0005ft-VY; Wed, 10 Sep 2025 15:38:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118530.1464280; Wed, 10 Sep 2025 15:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwMtV-0005fm-T2; Wed, 10 Sep 2025 15:38:01 +0000
Received: by outflank-mailman (input) for mailman id 1118530;
 Wed, 10 Sep 2025 15:38:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwMtU-0005fd-H4
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:38:00 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fdf0aa4-8e5c-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:37:58 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-519-Nn7d75JhNz-oEDBxkYvRXg-1; Wed, 10 Sep 2025 11:37:55 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-45a15f10f31so5031555e9.0
 for ; Wed, 10 Sep 2025 08:37:55 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f17:9c00:d650:ab5f:74c2:2175?
 (p200300d82f179c00d650ab5f74c22175.dip0.t-ipconnect.de.
 [2003:d8:2f17:9c00:d650:ab5f:74c2:2175])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7521c9cdbsm7733009f8f.16.2025.09.10.08.37.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08:37: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: 1fdf0aa4-8e5c-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757518676;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xC5R7eYl9Rwp0IenYxoNNT2Mrkq2ifbsmCTO4MCCq6w=;
	b=cBbrr4oOAAC2TDHzjFbIDAPy57+V5lhbL+bRUKVSiV+5qKONPaUk62FJVauTUOebSC1uM9
	SrFcx94MO4gbFZjEQr3EWBl/e7IE+QnpykS2dsyYqiERSEl49D4wi2dt7FhWnCK+X7wuz1
	s19Ost5HzCrBJpPddBEwxyGIGy8OadQ=
X-MC-Unique: Nn7d75JhNz-oEDBxkYvRXg-1
X-Mimecast-MFC-AGG-ID: Nn7d75JhNz-oEDBxkYvRXg_1757518674
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757518674; x=1758123474;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=xC5R7eYl9Rwp0IenYxoNNT2Mrkq2ifbsmCTO4MCCq6w=;
        b=Raa7XBlasuh+z6QO7l7M5s58gRiVrjR0ELP+/qSnjprYi/vO9ODZRkQKL/7arEnuak
         oytb14yrWtCZ3h8PO/k1klBg7PnudcWy0mHymxDeSzjolG5f8LuX23ZhFpyheU9r23eP
         xO6vC3aDENQLj/2/y77LEDZgR3POUSsugjKM+skXvHrq9iNgFDgjJKRvznLVNyRrw0gw
         tGdp29CoKfXJ05eZ+QTBhU4YdnvbtLaEoG8Id2bTAUC9QfEpd8zEPdRMJ88APH6f1xqC
         IylnSAawzVV8GuhqzU0hXd66fp7L46eSlr9fEEZYTlK7g5OuDi91R2LOucZkoriGmT+Z
         HGmQ==
X-Forwarded-Encrypted: i=1; AJvYcCV9tiZPVw4fiojnAwdQ5dwMUrE/4Fv+2pwH35vy2aeZE7fnU9yDqXlUKaoJAHdjlSOkog2WzxyrNv4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwX8tA9WrfPmYgKvS7M9QoCYuK3UINMYUdcErzuhOnxNgA6nssK
	skF/tEVx5oKOO5TaUL2NoYwTWv9ynAPx+GqEYTRaARziKY6asdKmAEqiCbepP+VEACXqv25dNgV
	DgA/qRRv7gAG2Xv0TZNpZJt6oDOk7lyND5W8RxLzdfTVHM/fjbkIZDJn82B9WGi+7ibs0
X-Gm-Gg: ASbGncvLUSSlle2N2xC2kXjIzBnlykzc0kdq6r8Qkzr2d5RnZXhrlTNWytRORwx/ETg
	BL2e3ehZfiJnruxpn1DuiaDRZnwZoJbv83e5VcJSZHFQSvtbrT/GX+2wCnw2ix4alCxgLtSWSdH
	L3oM11sIt+R5sO6f7C71ceXecTo9m8HASpkHSAWGoEDAoUu2fua+FurPdpCexcHqiogkokXpXCu
	D8alOle4EpuU1zkZkq/QI5gmDahA6rBzhyQ0UKyOcSIgHkCyT0oB2RwG385zK4uvlaylCwI9ycy
	oDDxAqFxInJXqtdaFgZm5uB2xBZ6Dnu3dLCWMDdrqpptx9M7xPF3/r22LDFbxrKB5DKZFYJ0txT
	FtV7HJNpGIn9v6+B0gE5yi+/dHkUiFTdCnq1aJY4u+2dKG7k2GVOd1vcZ6Vw5PdLHq5o=
X-Received: by 2002:a05:6000:400f:b0:3df:22a3:d240 with SMTP id ffacd0b85a97d-3e75e0f032cmr41423f8f.4.1757518674325;
        Wed, 10 Sep 2025 08:37:54 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFSanGWB8lh0ls+MFHggdlE9XrwwjBOuob47gN7Go2sD22cOkG0a4ZQLy4lN4pGQUVx9DuyJw==
X-Received: by 2002:a05:6000:400f:b0:3df:22a3:d240 with SMTP id ffacd0b85a97d-3e75e0f032cmr41388f8f.4.1757518673785;
        Wed, 10 Sep 2025 08:37:53 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 17:37:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <9de08024-adfc-421b-8799-62653468cf63@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: _XRLys9yJcWXH0FbZDRcJFj47H9e6NcypbpK2REODkk_1757518674
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

> 
> Somewhat, but in the regular case where enter() is called followed by
> leave() there is really no complexity for the caller, just an extra
> local variable.
> 
> There are complications where we want to exit lazy_mmu temporarily, as
> in mm/kasan/shadow.c [1k], but this is in fact unavoidable. Chatting
> with Mark Rutland, I realised that to truly support nested sections,
> this must be handled in a special way in any case. To be clear, I am
> referring to this situation:
> 
> __kasan_populate_vmalloc:
>      apply_to_page_range:
>          arch_enter_lazy_mmu_mode() {1}
> 
>          kasan_populate_vmalloc_pte:
>              arch_leave_lazy_mmu_mode() {2}
>              arch_enter_lazy_mmu_mode() {3}
> 
>          arch_leave_lazy_mmu_mode() {4}
> 
> With the approach this series takes, call {2} is made safe by passing a
> special parameter (say LAZY_MMU_FLUSH) that forces lazy_mmu to be fully
> exited - and call {3} will then re-enter lazy_mmu. This works regardless
> of whether __kasan_populate_vmalloc() has been called with lazy_mmu
> already enabled (i.e. calls {1} and {4} can be nested).
> 
> On the other hand, with a pagefault_disabled-like approach, there is no
> way to instruct call {3} to fully exit lazy_mmu regardless of the
> nesting level.

Sure there is, with a better API. See below. :)

> 
> It would be possible to make both approaches work by introducing a new
> API, along the lines of:
> - int arch_disable_save_lazy_mmu_mode() (the return value indicates the
> nesting level)
> - void arch_restore_lazy_mmu_mode(int state) (re-enter lazy_mmu at the
> given nesting level)

Yes, I think we really need a proper API.

> 
> This is arguably more self-documenting than passing LAZY_MMU_FLUSH in
> call {2}. This API is however no simpler when using a
> pagefault_disabled-like approach (and less consistent than when always
> saving state on the stack).

Yes, a proper API is warranted. In particular, thinking about the following:

arch_enter_lazy_mmu_mode() {1}
	arch_enter_lazy_mmu_mode() {2}

	kasan_populate_vmalloc_pte:
		arch_leave_lazy_mmu_mode() {3}
		arch_enter_lazy_mmu_mode() {4}

	arch_leave_lazy_mmu_mode() {5}
arch_leave_lazy_mmu_mode() {6}


Imagine if we have the following API instead:

lazy_mmu_enable() {1}
	lazy_mmu_enable() {2}

	kasan_populate_vmalloc_pte:
		lazy_mmu_pause() {3}
		lazy_mmu_continue() {4}

	lazy_mmu_disable() {5}
lazy_mmu_disable() {6}


I think it is crucial that after lazy_mmu_save/lazy_mmu_restore, no more 
nesting must happen.

Assume we store in the task_struct

uint8_t lazy_mmu_enabled_count;
bool lazy_mmu_paused;

We can do things like

a) Sanity check that while we are paused that we get no more 
enable/disable requests
b) Sanity check that while we are paused that we get no more pause requests.

[...]

>>
>> If LAZY_MMU_DEFAULT etc. are not for common code, then please
>> maintain them for the individual archs as well, just like you do with the
>> opaque type.
> 
> I see your point - having them defined in  could be
> misleading. I just wanted to avoid all 4 architectures defining the same
> macros. Maybe call them __LAZY_MMU_* to suggest they're not supposed to
> be used in generic code?

Maybe look into avoiding them completely :) Let's agree on the API first 
and then figure out how to pass the information we need to pass.

[...]

>> Worse, it does not
>>> truly enable states to be nested: it allows the outermost section to
>>> store some state, but nested sections cannot allocate extra space. This
>>> is really what the stack is for.
>>
>> If it's really just 8 bytes I don't really see the problem. So likely
>> there is
>> more to it?
> 
> I suppose 8 extra bytes per task is acceptable, but some architectures
> may want to add more state there.

Just for reference: we currently perform an order-2 allocation, 
effectively leaving ~4KiB "unused".

If there are any real such case on the horizon where we need to store 
significantly more (in which case storing it on the stack might probably 
also bad), please let me know.

> 
> The one case that is truly problematic (though not required at this
> point) is where each (nested) section needs to store its own state. With
> this series it works just fine as there is a lazy_mmu_state_t for each
> section, however if we use task_struct/thread_struct there can be only
> one member shared by all nested sections.

Do we have a use case for that on the horizon? If so, I fully agree, we 
have to store information per level. How/what information we have to 
store would be another question.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:52:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:52:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118551.1464290 (Exim 4.92)
	(envelope-from )
	id 1uwN7X-00009j-5R; Wed, 10 Sep 2025 15:52:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118551.1464290; Wed, 10 Sep 2025 15:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwN7X-00009c-2q; Wed, 10 Sep 2025 15:52:31 +0000
Received: by outflank-mailman (input) for mailman id 1118551;
 Wed, 10 Sep 2025 15:52: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 1uwN7W-00009W-0W
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:52:30 +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 25720856-8e5e-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 17:52:25 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b0787fa12e2so159161066b.2
 for ; Wed, 10 Sep 2025 08:52: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
 a640c23a62f3a-b078304793csm189909466b.3.2025.09.10.08.52.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08:52: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: 25720856-8e5e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757519545; x=1758124345; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KteYudVUBAYXnP0aIwiiCDvHDtysBL6DUl4cB16YF8g=;
        b=RQn7aTTcsLtqr1JFmiikZl8NB3etmuWneto79PkL5Zg35dG0/RRQh7qLulfnOBzbyc
         qIHRkJT3p+c4WiM3QvPurRtadXmLYeVVYZrDXC6+lrmzEyH3KwPBlwgY3/TD9R76cF4A
         FyWmHwFazrk5UOpzC6ejia80S4mRnFWzRGkoxTCfZKvvxenc7poi1G1XVCxAUJyx/w02
         IqJC/2ZlRffb0FD6Jqf7P9YlJNcePzEB36k/ndZgaTmrQBSAm+a9YigdEozFwT+k14Cu
         sIEnoaeoc22pU1KfIpU+CmmIMRsTrJrlwk8qRcoj7Ds5cfoSgirc39lu+2pwdsTi1CCk
         7J4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757519545; x=1758124345;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KteYudVUBAYXnP0aIwiiCDvHDtysBL6DUl4cB16YF8g=;
        b=OB5GwBWpQdfcWWLLmiaUH4tU16L+LGW7iAXpaYsR8fZojDVOl4g72SufVpI6Ei1kc5
         u5Jusxz0b6A9yRcJO5QJUaLlGJC/0jYpqQkWk1zpt2Rw9xy/0eBL/tPl+PdU5uCqilex
         zSKhOkFd2KlDO2PKiEkT1e8OGxS3Us8EKXWeaVz6gpkgMxnOLuWjjsH/UmiL/h2OsXTR
         6wREssbV4rvYXh7VuHdHgsFV82eBbwim9QPVbOB+jIr/EBkQ+WyKUOjNA6WFKKuj5QAb
         JNgcsaz9I2rocKx0tWrhysOlwUXLeK7G8ozhrCCeQm5fXNgcm3AU8HdFZIxEY4IN9Y/x
         k6qQ==
X-Forwarded-Encrypted: i=1; AJvYcCWANMonRKReK5bRgbprFFwNrWfusqUiMd7tJKP21+fGXc4r5h5N350Vr+SCFD3u37+PfJtqnrv4Muw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytnoVTskLRA9UfvlbGbUOGEex8xlodfDt/xqkfme3P277ExIFJ
	6DGgQVP+FVPV1mGV0zaMfXC9VrinZcv1w23hmMnkdII7HydQFNwpiD7EQRasUTlQgw==
X-Gm-Gg: ASbGnct6lay318s/jqdqJX7BiX4QkI11jF7GFN1K5iwH7KgFnrSBRG0ZJ9uRXuIqGEB
	fHKM3zX+kKcoYRGOaHDI5rYyVQyUAx9rJ7j6W7hdbmISWUEE0swdNS6IGQP7z0QVjPOHCJy09iZ
	DzTmzJs9LnVUl6EArZDq276df0vyQQqfb4uVDXJtkcss+/hPKbkxfWd02u4Ju6k9ZwjF5L0ltFZ
	ks0/x99sPFL5Fhji1rJv0ba3iaO7GQULifwa1iD5JxiKqaf7Ub1VQ7rUd3xXyTpvZF+ZU5S+U79
	QhdERezzQMvaPJO5LibWZsAu2wmt1C3v/Zb+8SpbdUDPuv1mPCAJn6ZBLYwXwiuHE1Ceiu+07hd
	4wd+basuQar8WNkROdnN5rG22V5VbSVqfS8QktN3/6o8GLS2E3cyeYpIOH1D8N51pttWaVWoRGX
	gTXQjEp+GgmtwpCtvzGA==
X-Google-Smtp-Source: AGHT+IHFcfHyz3XjGpe3MaRZBARPqkWNLnc/UGEkZH9UwsNBjlG1MQCITSwGb3fx7zU6GexcQ2LdhQ==
X-Received: by 2002:a17:907:8688:b0:b07:653d:56a8 with SMTP id a640c23a62f3a-b07653d5843mr743781066b.5.1757519544971;
        Wed, 10 Sep 2025 08:52:24 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 17:52:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/26] xen/domctl: wrap vcpu_affinity_domctl() with
 CONFIG_MGMT_HYPERCALLS
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 ,
 Dario Faggioli , Juergen Gross ,
 George Dunlap , xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-13-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1402,10 +1402,12 @@ int vcpu_set_hard_affinity(struct vcpu *v, const cpumask_t *affinity)
>      return vcpu_set_affinity(v, affinity, v->sched_unit->cpu_hard_affinity);
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  static int vcpu_set_soft_affinity(struct vcpu *v, const cpumask_t *affinity)
>  {
>      return vcpu_set_affinity(v, affinity, v->sched_unit->cpu_soft_affinity);
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */

Again preferable to get away with just a single #ifdef (i.e. ...

> @@ -1693,6 +1695,7 @@ int vcpuaffinity_params_invalid(const struct xen_domctl_vcpuaffinity *vcpuaff)
>              guest_handle_is_null(vcpuaff->cpumap_soft.bitmap));
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS

... this one) here. In fact I question the value of the helper: It has
a single caller, so what the helper does could easily be expanded at
the sole call site ...

>  int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
>                           struct xen_domctl_vcpuaffinity *vcpuaff)
>  {

... below from here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:54:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:54:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118562.1464300 (Exim 4.92)
	(envelope-from )
	id 1uwN9V-0000h5-Gu; Wed, 10 Sep 2025 15:54:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118562.1464300; Wed, 10 Sep 2025 15:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwN9V-0000gx-EQ; Wed, 10 Sep 2025 15:54:33 +0000
Received: by outflank-mailman (input) for mailman id 1118562;
 Wed, 10 Sep 2025 15:54: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 1uwN9T-0000gp-Mu
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:54:31 +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 6d7d615d-8e5e-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 17:54:26 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3c46686d1e6so4509291f8f.3
 for ; Wed, 10 Sep 2025 08:54:26 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7521ca0e9sm7917503f8f.25.2025.09.10.08.54.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 08:54: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: 6d7d615d-8e5e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757519666; x=1758124466; 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=RFteJgx6AqwB4D6h4mss4xo0en8UTw0VErhmFRJ+5LM=;
        b=SterV82ohzpABw1E2oCGRr8XeiJPCeMnarbYrr/6S4+a1Rpe9Ju7lrOZ2mm81oe96E
         EWWAMlULhhd6kkvGhI0xFOr4DgFnnyjGG3EuvIBJ076UsyOjdiGBhJgbGkW+Dh4oLzhh
         +R389U7sarKFXG8imCWtMeMEgt917ASP6+FkA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757519666; x=1758124466;
        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=RFteJgx6AqwB4D6h4mss4xo0en8UTw0VErhmFRJ+5LM=;
        b=AfOnp5U5CV2JVF406X9WUDfFJ5PWrQ2gPmsXsqVqeM+Fh9eAZO92lT9WuOWAA/ktfQ
         SKoyMddPmrjTLHX+1hTWIf6ya3dULY2V17SpudnTBBm2SFMPTnNapUQJpkogsytrQaeh
         h/2KyWcH/U4PdJ2xFRzDiWP4WbDBMierveOJNk1v+63ApEq+r1OPjIeZLwtDW2ngjv83
         h7OOemZPgADe6W0Bvnn5IpWkIuAjYhuxyyZwcTElkhRegLunME3qAAVqFHQQJvyFIF4L
         Tk7qtgIQdt3I+w/0aFOLOQnr2YRlfP81SrQODOyt9J8dyZl1x1xoxLysoS0wJovXgeeV
         +gkg==
X-Gm-Message-State: AOJu0YyVKz4E5yoxuqBqsU66X8w12T8EIm19GoOLINyHfjiBI2VwUTRt
	sZGCEQOWpGyDMhcHMHvRDIRHgRfeLH88os3faKmWr7pPGTY5OdVW45NYprVMbiqtZww=
X-Gm-Gg: ASbGncvZf5HubcQ9oVNA2PqLgGo9TB/50o5yumWozMG5r6ZxDMP2tOWPtxzq/esBiLq
	C1uUCh5RkN8xUOikQQspcq2ZINXI3kSH4YF6ldNA5W/+cNuwzUGuRzF0ecJob4hWkrUxJiyzc2k
	EZn+zNH1miFFjo1P09f27ZrhddOhyqEPgvXX/QdfIzDpyImpHTv+FZFSRG2chmYL9pIIVW5zWuh
	2fwfffl6LvqnzBi1jixhMZOmTQOCpLYMNMqd4/e98Yg9MZTDBmtluRnpelnq6sRuT9ZPY7M1iMM
	aLklAqdzUE6zOQHn5ld8ScWRuTW/lZuv++d6XQaqvA6Mg5XWAF7rsNkS/PEjqImD9RXRXndIGY4
	gjV7HxFx9OZH9/YDFHiu9478/B0hRXS7GnpOcUE2CCTnuIiJHFhlyntcuDI8te90W7v/N
X-Google-Smtp-Source: AGHT+IHqwcCcJ9+tMA8dz60LpMAZzAoi+ZHk6OLtgG13hHeSoWb5srKZzUW5EO2Kl2zvm6LHldq6eQ==
X-Received: by 2002:a05:6000:647:b0:3e7:1f63:6e81 with SMTP id ffacd0b85a97d-3e71f6373c5mr14230298f8f.16.1757519665687;
        Wed, 10 Sep 2025 08:54:25 -0700 (PDT)
Message-ID: <6f13d82f-743c-4bb7-ab95-c8a34fae957a@citrix.com>
Date: Wed, 10 Sep 2025 16:54:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CI: Switch the alpine containers to be non-root
From: Andrew Cooper 
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Xen-devel ,
 Anthony PERARD ,
 Stefano Stabellini , Jan Beulich 
References: <20250910113416.1835988-1-andrew.cooper3@citrix.com>
  <2c91d873-7f13-4f78-a0d8-8f67f06c88b2@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: <2c91d873-7f13-4f78-a0d8-8f67f06c88b2@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10/09/2025 2:11 pm, Andrew Cooper wrote:
> On 10/09/2025 12:57 pm, Marek Marczykowski-Górecki wrote:
>> On Wed, Sep 10, 2025 at 12:34:16PM +0100, Andrew Cooper wrote:
>>> Testing on staging-4.19 is hitting a reliable failure, caused by alpine/3.18
>>> being a root build container, but debian/12-x86_64 being a non-root test
>>> container.  Specifically, the test container can't copy XEN_PAGING_DIR and
>>> XEN_DUMP_DIR (both 700) from the build root in order to construct the initrd.
>>>
>>> staging-4.20 and later do not repack the initrd in this way, so are not
>>> affected.
>>>
>>> Switch both alpine containers to being non-root.  This is still slightly
>>> fragile, but better than depending on using root containers for both.
>> This will likely explode done as is...
>>
>> First, grub.cfg is not writable anymore:
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11305545275#L170
>>
>> I'm not sure what 'user' gets remapped to here, but the whole container
>> is running under rootless podman, as gitlab-runner user. Files on the
>> host are owned by gitlab-runner user.
>>
>> But second, repacking initrd as non-root, without any extra care will
>> result in broken initrd. At the very least /sbin/mount is suid root -
>> when repacked as normal user, it will end up as suid to non-root,
>> breaking it quite effectively. I've run into this issue when needing to
>> repack rootfs anyway and ended up using fakeroot (again):
>> https://gitlab.com/xen-project/people/marmarek/xen/-/commit/bab939159127a9f8e56e119c1fa553c7bbb6d4f7
>>
>> At least your "CI: Create initrd fragments explicitly as root" patch may
>> need backporting, but TBH I'm not sure if that's enough. /dev will
>> likely be messed up too.
> There's a lot of collateral damage here.  Summarising things a little.
>
> * We cannot change the root-ness of alpine/3.18-arm64v8.  Like
> xilinx-xenial, it does need root to drive real hardware
>
> * We can change the root-ness of alpine/3.18.  It is only used as a
> build container, not a test container.
>
> * Contrary to my previous analysis, we have backported the test-artefact
> CPIO work to 4.19, but not the build step CPIO archive.
>
>
> And, what to do:
>
> * We really do need to be rootless in the build containers.  Therefore I
> think we need to split alpine/3.18-arm64v8 in two, and when bumping to
> the next version is the obvious point to do this.  We should make a
> dedicated qubes container similar to xilinx-xenial, and separate it from
> the build step.
>
> * I should see about backporting the build step CPIO archive.  I'm
> beginning to think that was an oversight of mine, because I didn't
> intend to end up with a split like this.  This should avoid the step
> causing us problems here.
>
> * I'm very inclined to change the root-ness of alpine/3.18.  Testing
> suggests this is fine.

To follow up here, backporting the remaining CPIO patches has resolved
the issue. 
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2032200270

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 15:57:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 15:57:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118578.1464311 (Exim 4.92)
	(envelope-from )
	id 1uwNBt-0001aC-2Z; Wed, 10 Sep 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 1118578.1464311; Wed, 10 Sep 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 1uwNBs-0001a5-V5; Wed, 10 Sep 2025 15:57:00 +0000
Received: by outflank-mailman (input) for mailman id 1118578;
 Wed, 10 Sep 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 1uwNBs-0001Zy-EM
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 15:57: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 c88ede44-8e5e-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 17:56:59 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3e7428c4cbdso567877f8f.0
 for ; Wed, 10 Sep 2025 08:56:59 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45df804bce3sm32780635e9.0.2025.09.10.08.56.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 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: c88ede44-8e5e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757519819; x=1758124619; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uc0uRevkkxcuK9RJDoboXNlE4uHzDfJeym3CsurVY5I=;
        b=A106QOpWDeL34K27HUc46RTKh1OIfTNzuVs2SNJEAo8JiN93jOwYqUc3+RarLfmeYx
         ANUhRRSKGciba8Nlp4OdrojEXYTKuDrgex0wiOn8pf/JQTpTgFzbjjlUDsXA/uUR64Ha
         XNIROV0pLUciymdjNA6uD0TPLiEuMz+X8tnMc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757519819; x=1758124619;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uc0uRevkkxcuK9RJDoboXNlE4uHzDfJeym3CsurVY5I=;
        b=RZBlNU7rzKEwRg5J8LxG2jvBhdK4RUKsoiGEebFe1hPN981ier7Vza/xP3v6tQbiFe
         nRJRBkEumauwp8s2ctxgBbJ1DMom3yi8eVC8UY7jUoYz/cAUHLI6OwazGjJS+R/+feAs
         lGo5+hmSH7GrowXMEhxL6G2VWMdf64k/qkYLzDLUq6k8UBNhLgVQ1ZOH/+c0NTMqkVTI
         Ao5Ciol/fbfiR8SBW4z0jBkWb8W76YyMUW0tEqjXuYlbI5103zbI/hV78jcfpuCvcfhk
         fCtwD5QZaqnDU+UudBehnPO7Ay5b6AHhfdNE1Tr5PjoECkg5aRUby9qXpRRE+KI1AvZT
         MEUA==
X-Gm-Message-State: AOJu0Yz3EuCkYG4wXV7lZwC5FbCYseED0nSSklLAo/vKQfBdwEtiViIq
	fNYCsC4lJA5GX8sDLW6GXVrrHiChAZ2gRv+x4mwSwrEzSJFtXHKqTRt/4IyGcV47SNg=
X-Gm-Gg: ASbGncuB1yqVJt2aIPSIth+DldQYyrsh/rW3Gb/a7NN/SqOD8XO7pJyX+Bc14g++IGf
	x3NgR7VutbgrYERG2xY2Z5tbgyAshTKHLObtL9y0BMp8ba5pxP5P8CwxotuSeyBRckyfppjnqTR
	u/RSd1vkqpQrFLj4THbTL5yIYBrJOR0UCMMVKCdJqW+WGf5d7qh3WX0djOzTxtcuDWZ6gmaHBxu
	erTZvkIODrEn2KTtnE1YF2XgdLwhHvimEhMmtvtDzdQQNUqtpuLT0FaLZruybigqAWo3oSDUift
	d7qSPa/zkBqQ/lixKkPaFYyOKRd7Kl4yjznrWKAbWKGuhN1S+Z9Z+0jv0FnvZxpuPw86ewEg/Yv
	9exjh7DDgIconPSVsx20hFXM9PhRmIOD3YNo61nprkTG1cwXVv/QwHdH1OIL29LzfB5uA
X-Google-Smtp-Source: AGHT+IExUc1sIMUCc6ll9njETf3E9bFDcJD5GaHTfjaNUrXHheYIMTpyhs1BKLWugS/0R4ECCYvAag==
X-Received: by 2002:a05:6000:1a8b:b0:3c2:d7f0:9c4e with SMTP id ffacd0b85a97d-3e75e0fadc1mr83541f8f.8.1757519818574;
        Wed, 10 Sep 2025 08:56:58 -0700 (PDT)
Message-ID: <33285a11-a28e-490f-94e1-748b741a0405@citrix.com>
Date: Wed, 10 Sep 2025 16:56:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/5] CI: Update ppc64 to use Debian Trixie
To: Anthony PERARD 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Shawn Anastasio ,
 Oleksii Kurochko ,
 Doug Goldstein ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Victor Lira 
References: <20250809221206.1260861-1-andrew.cooper3@citrix.com>
 <20250809221206.1260861-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: 8bit

On 13/08/2025 4:16 pm, Anthony PERARD wrote:
> On Sat, Aug 09, 2025 at 11:12:03PM +0100, Andrew Cooper wrote:
>> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
>> index ab5211f77e5e..3fe539dc5683 100644
>> --- a/automation/gitlab-ci/build.yaml
>> +++ b/automation/gitlab-ci/build.yaml
>> @@ -319,10 +319,10 @@ debian-12-x86_64-clang-debug:
>>    variables:
>>      CONTAINER: debian:12-x86_64
>>  
>> -debian-12-ppc64le-gcc-debug:
>> +debian-13-ppc64le-gcc-debug:
>>    extends: .gcc-ppc64le-cross-build-debug
>>    variables:
>> -    CONTAINER: debian:12-ppc64le
>> +    CONTAINER: debian:13-ppc64le
>>      KBUILD_DEFCONFIG: ppc64_defconfig
>>      HYPERVISOR_ONLY: y
>>      EXTRA_XEN_CONFIG: |
>> @@ -705,6 +705,20 @@ debian-12-ppc64le-gcc:
>>      KBUILD_DEFCONFIG: ppc64_defconfig
>>      HYPERVISOR_ONLY: y
>>  
>> +debian-12-ppc64le-gcc-debug:
>> +  extends: .gcc-ppc64le-cross-build-debug
>> +  variables:
>> +    CONTAINER: debian:12-ppc64le
>> +    KBUILD_DEFCONFIG: ppc64_defconfig
>> +    HYPERVISOR_ONLY: y
>> +
> Why did you remove the EXTRA_XEN_CONFIG from this job? Currently, the
> job is setup as:
>
>     debian-12-ppc64le-gcc-debug:
>       extends: .gcc-ppc64le-cross-build-debug
>       variables:
>         CONTAINER: debian:12-ppc64le
>         KBUILD_DEFCONFIG: ppc64_defconfig
>         HYPERVISOR_ONLY: y
>         EXTRA_XEN_CONFIG: |
>           CONFIG_UBSAN=y
>           CONFIG_UBSAN_FATAL=y

Because the build run under QEMU changes too.  (See the hunk updating
test.yaml)

We use UBSAN/FATAL for builds where we boot the resulting hypervisor,
and not for the plain build tests.  (In farness, UBSAN/FATAL is newer
than the last time I shuffled test baselines).

If we're going to start having config like this on multiple builds,
we're going to need to find a better way to handle it, because we cannot
be duplicating it between different jobs.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 16:12:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 16:12:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118604.1464324 (Exim 4.92)
	(envelope-from )
	id 1uwNQW-00055M-9d; Wed, 10 Sep 2025 16:12:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118604.1464324; Wed, 10 Sep 2025 16:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwNQW-00055F-6g; Wed, 10 Sep 2025 16:12:08 +0000
Received: by outflank-mailman (input) for mailman id 1118604;
 Wed, 10 Sep 2025 16:12: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 1uwNQU-000559-Hh
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 16:12:06 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id e448d7d4-8e60-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 18:12: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 B91C716F2;
 Wed, 10 Sep 2025 09:11:55 -0700 (PDT)
Received: from [10.57.67.148] (unknown [10.57.67.148])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F3D43F63F;
 Wed, 10 Sep 2025 09:11: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: e448d7d4-8e60-11f0-9d13-b5c5bf9af7f9
Message-ID: <250835cd-f07a-4b8a-bc01-ace24b407efc@arm.com>
Date: Wed, 10 Sep 2025 18:11:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: David Hildenbrand , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09/09/2025 16:38, Alexander Gordeev wrote:
>>>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>>>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
>>>> want to use it - at least that is how I read the description above.
>>>>
>>>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
>>>> that do not follow this pattern, and it looks as a problem to me.
>> This discussion also made me realise that this is problematic, as the
>> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
>> convenience, not for generic code (where lazy_mmu_state_t should ideally
>> be an opaque type as mentioned above). It almost feels like the kasan
>> case deserves a different API, because this is not how enter() and
>> leave() are meant to be used. This would mean quite a bit of churn
>> though, so maybe just introduce another arch-defined value to pass to
>> leave() for such a situation - for instance,
>> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?
> What about to adjust the semantics of apply_to_page_range() instead?
>
> It currently assumes any caller is fine with apply_to_pte_range() to
> enter the lazy mode. By contrast, kasan_(de)populate_vmalloc_pte() are
> not fine at all and must leave the lazy mode. That literally suggests
> the original assumption is incorrect.
>
> We could change int apply_to_pte_range(..., bool create, ...) to e.g.
> apply_to_pte_range(..., unsigned int flags, ...) and introduce a flag
> that simply skips entering the lazy mmu mode.

This is pretty much what Ryan proposed [1r] some time ago, although for
a different purpose (avoiding nesting). There wasn't much appetite for
it then, but I agree that this would be a more logical way to go about it.

- Kevin

[1r]
https://lore.kernel.org/all/20250530140446.2387131-4-ryan.roberts@arm.com/


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 17:02:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 17:02:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118634.1464338 (Exim 4.92)
	(envelope-from )
	id 1uwOD5-0003gl-T9; Wed, 10 Sep 2025 17:02:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118634.1464338; Wed, 10 Sep 2025 17:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwOD5-0003ge-QC; Wed, 10 Sep 2025 17:02:19 +0000
Received: by outflank-mailman (input) for mailman id 1118634;
 Wed, 10 Sep 2025 17:02: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 1uwOD4-0003ed-1R
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 17:02:18 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2413::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e6df2fa1-8e67-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 19:02:16 +0200 (CEST)
Received: from SJ0PR05CA0193.namprd05.prod.outlook.com (2603:10b6:a03:330::18)
 by BL1PR12MB5972.namprd12.prod.outlook.com (2603:10b6:208:39b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 17:02:10 +0000
Received: from SJ1PEPF000023CB.namprd02.prod.outlook.com
 (2603:10b6:a03:330:cafe::3) by SJ0PR05CA0193.outlook.office365.com
 (2603:10b6:a03:330::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.14 via Frontend Transport; Wed,
 10 Sep 2025 17:02:10 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 17:02:09 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 10 Sep
 2025 10:01:29 -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: e6df2fa1-8e67-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=J6B48KycYOrf92SpeXKFzxnuxTXMalqYYYkeCUNPqOYtzGmiBk5ES4dWRKzAawfiP30p8oL7zbo8nu88/9J80eLCZhtvqRtEl+Iy71x1+qf2OMi7vTpmPkhxUQev9/wK0rHcEr1988ymHBIV34eNulxYJ5P/bShgNoyOOPUxWr7KLTkbIOrmRnkX5Nk/VE8WpjVFEqt9LKJ6pP8iLUg9W46tSNYkA5LnGL6wyYrYPVBadgmmD7ctG+jyQC+DK01JTdDgCLV6DyjNBO0X/Whak+/HNRcVqK+B94XUDD0262sYfLnzg3d7SnjR/m9Jj4VziASg9AHgQL+k7id3zo9CVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uHE1RrkGJDNNNV5lHGYmpuLxiJIwY665xOrzVH6SXlw=;
 b=CqeTuu2gXw7PfgFqOtotaR0UhfW+7/Rs4lFOZbJyEsw0Sy86US/tmlEESka4ru8QCQBPy6Y0HjrKJ9MentPiPRvi1skaORXiV8F4Js5hFaBsjOGh9FVFVZBsA8H1X0QmMvlKRvZ8VDVTeQRO8O7lZdpItGFBMWD2tb+C53pJ0byPXEMS+4DAPZwYwWCSmVK9/R/fBmBDCdTd7AKiZYdh6xalxKoLM5jcOFlXEJJjZX2st3YQEMYFt7b66W97bHfaVm8c81LFYIB1yZqKHN4R41V3OHH23fnvLIRHUoxTp5O4It5+zXEPznrAt0Pphrpz85Ch2pZ9uH4tziGWLBFLgw==
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=uHE1RrkGJDNNNV5lHGYmpuLxiJIwY665xOrzVH6SXlw=;
 b=bFZUI2dnrlTAgKqrWVYOkNLH6CzVVIcCiuIdunoOL4EQzGePgEzFdSgwx2eKOz2miVDwF5o1UlrYb++fLRBjQ5EvXXADYUvhjHOHNfDPqhqvojhLDE8C+tt9Ty58VKwuQ0l1fAmne77EMlQhudPSQBy4/j8Qj7MNt7sWLr1YZ9c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 10 Sep 2025 19:01:28 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Jan Beulich 
CC: Anthony PERARD , Grygorii Strashko
	, Roger Pau Monne ,
	
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
X-Mailer: aerc 0.20.1
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
 
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CB:EE_|BL1PR12MB5972:EE_
X-MS-Office365-Filtering-Correlation-Id: 257f6165-968b-4033-12da-08ddf08bc7ce
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?c0JZVlI1SnpFc1JzMFFQbS94cExwVkFZQXJjZlNzOC8yN0VoRkVuK0dVV0tn?=
 =?utf-8?B?NmU4dFQydVMwanlKZCtkNE9CLzZ6Um5oRTFuYXVTVjBLRDFOWjc0Y0V2UkZF?=
 =?utf-8?B?SGhjZGNkQkJqWExINTNNdTZiaklDT0dZR09RRENlU1BzWmFBVTdLTjVRd0tG?=
 =?utf-8?B?WVFoNzlMY3RZdmVkYjh0ajZZWjZ4RzlsVXJ2YkJsWjFEbks2Vjh5N3dybHdu?=
 =?utf-8?B?dFlSeCsyTE1DQWk3TVRQOHVCaytsSVIwb21ZYndrRTFPVnZ6ZWMyUjRWbjg2?=
 =?utf-8?B?eE9GZzBvSnMxY01KbUZsTGtsLzIzVWN6V1lwYnovVFNCT2ZHM20zMm0rKy9C?=
 =?utf-8?B?ZmhKM1VTb3U2dzNlcm96K3dVWTdBRlNCa09ITXZmVVRia1phYUsxc2orWGht?=
 =?utf-8?B?MVJWdm1yU0gzTU90RnRkREVzN1BhR1VEVGFIaFNSVjRoT2NoTFhUT21EM0wz?=
 =?utf-8?B?dEttd29kekltd1JlTFVXZUtCSGhOTmJjUW81eHZCRkZ0RVZNdmViRngrdVQ1?=
 =?utf-8?B?bHlVMGVzK2JVNGFMUUx1NnV2RnZOLzZ0MTVOakNOTGlVSTdBNExSR1NMcTJp?=
 =?utf-8?B?YXZJNU43bmpLcFl5d2c1SEVOeDhUczZEUnFJdHJpRzROOThreDlUb2ZGMitx?=
 =?utf-8?B?SGJmN2swMk5YUmY4UWtFSm1Dcm1Ba3ZFd0pmWDM2aEJSTkZRRGxwWmJJdTZY?=
 =?utf-8?B?S25yWEZUajdJL3FBeHFHUHRtN2NOMDJjdW9hRVNqQ2lxY1U0S0JjcXJSQlpl?=
 =?utf-8?B?Nm9peGRFYjl6blZWUm1ub0ptZ2U2QTQ2OXovVUZMTGxVZGlnQjNHcXJJSFZ4?=
 =?utf-8?B?TUxVUlJFTjVsYTlhRUxidWJNTFEyVFZoaXVDdU8zVWJSQXZYUVYrcmZwcy8x?=
 =?utf-8?B?M0YxWmlRVVVDOHdiMVd2cVlhOFRvNE9zWGxmOE5LOVUxWlBoMEprVU5Qdm1M?=
 =?utf-8?B?dVlCNjU3dFRwWHRxSkR3NVh6b2JGMnhaRzlFMUZ3SFlaUkdjc0hhODJ3TU5P?=
 =?utf-8?B?Sk1BZVVLS1dSR0IxRjdIMDI1cEl0ZFVPQUlLN2M2c01kc1p5OGszOXh6eEZx?=
 =?utf-8?B?R1N4cjgyeUdvUFlXclAwdy9CaEE5SFpuTE5OVkM5Ykhob0pyaUE5bGgyRERt?=
 =?utf-8?B?OFpOYlN5dW13ckpsK2UwSEM5QjhFYVBFMC9CWkJiYTZlYTdhU3RaKzVQOWNH?=
 =?utf-8?B?ZU5ucnAyUHl0ZHNaWmE0UGRrMVk3VUVsSmdxeGVBK0doS1hrVHNseFczOVFu?=
 =?utf-8?B?SkRibjdHVXVXOTN4OStIT2lPVHJsZHo1UUtBVXhDdWJxRDU5SUxjY0FxWUlG?=
 =?utf-8?B?QWpRSm82ZUZzNzlUQVJnU1M5NG5UV0IvN3pOdUdaVU1vRGIxNGtCb3hlSjB4?=
 =?utf-8?B?UUppWk1HUEdGREU4YmYydDkwRlZXSXcveXZydUZLQ3BvUjBlbFVBejAvYWNE?=
 =?utf-8?B?R3ZtL3d3Q2RFVjZNV1lwa2E0cGdLekNCNTBranhUNXNXbXhXRFpDNktYWWRs?=
 =?utf-8?B?ck4vcVNWVVJUd0lUb3R3RzgvakpYay8wOWgrdHBFTHRHbVluUXBuRFNCMGZm?=
 =?utf-8?B?b0NNdEV1eDB6SzJVbUptTFF1VVREVk1hU1ZyK0poVkY0QU55UnFZVXRNS0FP?=
 =?utf-8?B?VHR5WW5iaXBUUlBTcHhabmdwVVdhMVBhQk1iTitLSzRzSUorakRYR2Rrdmww?=
 =?utf-8?B?c2xJRjF4Mk1JVnB1NlBMS3UvRkNKL2hPUEFTdThBRDF4Yk1wNWljeGJ1YU5K?=
 =?utf-8?B?Sm9qZkNjRWlXMmxiellTZkZhMzQ4Q3dHdTI4TUlLSEV2NUxrMVQvUWtBZkhM?=
 =?utf-8?B?bnJQYW1ZeW5hSnV5VWt2VmZySHJscXNMMnROejZtWVoycDFiYWlHV2hsUlRK?=
 =?utf-8?B?QVQxa0o0RTEwVHVia3FkUjVKZDNwRUJYamkrZmNITFI2ZzJwNC9IK2tvWHk0?=
 =?utf-8?B?SDJQNSsxVVJuV0t3QkV2TmRlK0JVNzZCTWpsQUdYaEZubjU0TlZLOTBvMGJq?=
 =?utf-8?B?RmdPcXlJVUVWYlZLTExsNmIzaTVlY3RnalVDQll6OCtDMCttYlkydnNjNWpO?=
 =?utf-8?Q?y2P307?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 17:02:09.8431
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 257f6165-968b-4033-12da-08ddf08bc7ce
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023CB.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5972

On Wed Sep 10, 2025 at 5:31 PM CEST, Jan Beulich wrote:
> On 10.09.2025 17:16, Alejandro Vallejo wrote:
>> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>>>> CPU hotplug relies on the guest having access to the legacy online CPU
>>>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
>>>> this causes the MADT to get corrupted due to spurious modifications of
>>>> the "online" flag in MADT entries and the table checksum during the
>>>> initial acpica passes.
>>>
>>> I don't understand this MADT corruption aspect, which - aiui - is why
>>> there's a Fixes: tag here. The code change itself looks plausible.
>>=20
>> When there's no DM to provide a real and honest online CPU bitmap on PIO=
 0xAF00
>> then we get all 1s (because there's no IOREQ server). Which confuses the=
 GPE
>> handler.
>>=20
>> Somehow, the GPE handler is being triggered. Whether this is due to a re=
al SCI
>> or just it being spuriously executed as part of the initial acpica pass,=
 I don't
>> know.
>>=20
>> Both statements combined means the checksum and online flags in the MADT=
 get
>> changed after initial parsing making it appear as-if all 128 CPUs were p=
lugged.
>
> I can follow this part (the online flags one, that is).
>
>> This patch makes the checksums be correct after acpica init.
>
> I'm still in trouble with this one. If MADT is modified in the process, t=
here's
> only one of two possible options:
> 1) It's expected for the checksum to no longer be correct.
> 2) The checksum is being fixed up in the process.
> That's independent of being HVM or PVH and independent of guest boot or l=
ater.
> (Of course there's a sub-variant of 2, where the adjusting of the checksu=
m
> would be broken, but that wouldn't be covered by your change.)
>
> Jan

I see what you mean now. The checksum correction code LOOKS correct. But I
wonder about the table length... We report a table as big as it needs to be=
,
but the checksum update is done irrespective of FLG being inside the valid =
range
of the MADT. If a guest with 2 vCPUs (in max_vcpus) sees vCPU127 being sign=
alled
that'd trigger the (unseen) online flag to be enabled and the checksum adju=
sted,
except the checksum must not being adjusted.

I could add even more AML to cover that, but that'd be QEMU misbehaving (or
being absent). This patch covers the latter case, but it might be good to
change the commit message to reflect the real problem.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 17:30:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 17:30:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118662.1464350 (Exim 4.92)
	(envelope-from )
	id 1uwOdm-0006nx-Ts; Wed, 10 Sep 2025 17:29:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118662.1464350; Wed, 10 Sep 2025 17:29: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 1uwOdm-0006nq-Pt; Wed, 10 Sep 2025 17:29:54 +0000
Received: by outflank-mailman (input) for mailman id 1118662;
 Wed, 10 Sep 2025 17:29: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 1uwOdk-0006nc-Qi
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 17:29:52 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20613.outbound.protection.outlook.com
 [2a01:111:f403:200a::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c13ee6ca-8e6b-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 19:29:50 +0200 (CEST)
Received: from MN2PR17CA0021.namprd17.prod.outlook.com (2603:10b6:208:15e::34)
 by PH0PR12MB7813.namprd12.prod.outlook.com (2603:10b6:510:286::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 17:29:46 +0000
Received: from BL6PEPF00022572.namprd02.prod.outlook.com
 (2603:10b6:208:15e:cafe::a4) by MN2PR17CA0021.outlook.office365.com
 (2603:10b6:208:15e::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9094.16 via Frontend Transport; Wed,
 10 Sep 2025 17:29:45 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BL6PEPF00022572.mail.protection.outlook.com (10.167.249.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 17:29:45 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 10 Sep
 2025 10:29:44 -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: c13ee6ca-8e6b-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=v4jzC+STGa0F6fdRtKB0+wEZxkU5DY8RXHSjqGye1whQhG6ckM4xI/SDE6+Ej6rFrD33gduy4gMinngl+k8syBD4/DgGByBPhT9NbP9BQR01OQEVmFmxnL2hoLovXWIPT5WMqI5I4hgG+xtK9Cx/VfxWI+UGhQYWmWgX2h70A2rctRHcjurkfv5EyqsngtI1q8iCJWi4W6SaQd7tGb+ZdarBYSShBq0yhzECor7tfD1sUjBlRS4fvVQSgvIQz6htsT36PkngSqwCRSHczOLImVpoq107FOx2d80BI2J7dtMC2Zpvqwzriwim7a1XazjdjQBckYKgRKGlYJM/yJMeCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7Eg5T/iQcS2XH8Uv+ZB99onyrXxOKCdOx9AyoMMLx7Q=;
 b=bWUrLn3Zbp3lt1BNUx9OyYoAafHbTD4UrSlv9VQuRc3XpAMWqwwZhv1xHp6X+QPmE7pNmJpvlODPBtOspshzptgPpKBZQbr38D43vnGwdluBWmkr1Jk1sV0Dubp+NGkycehFtymYBw4r7Yb5xEFWS/GrLAfckBRzqs/sbvsqptitFEmUAxlzlbZCwe1nawRjmtHFDP+4oboYRDfRvNFNsQKaYUK39mGdRAU3cA9ryUu7h2rUmllJ4aXm7jDEkuzfBWmFraXV8NIKvxkN5gX1TZqJyN6XjM/WGHsmgU1Yzipc9h4UiHtWUQIuPY73OCb0U3Khv7sB14cc+kfk/bErUg==
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=7Eg5T/iQcS2XH8Uv+ZB99onyrXxOKCdOx9AyoMMLx7Q=;
 b=E/95nCaSVSl5AO2+fT+Ejm0jrf/0Me4NejIko1FjZBMWU4LcrEAHMv+NQ3ianZA7/Q0j8pdHaZoKiEHtsXuCf/hcnheWxAOImKgidwn8EvffD7lWom5GQXjy/EBM3PzwDysDArFJmpmhJ6ok1lRh0NN/UUhY9DBUTeQd1Wrgj20=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 10 Sep 2025 19:29:42 +0200
Message-ID: 
CC: Anthony PERARD , Grygorii Strashko
	, Roger Pau Monne ,
	, Xen-devel
	
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
From: Alejandro Vallejo 
To: Alejandro Vallejo , Jan Beulich
	
X-Mailer: aerc 0.20.1
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
 
 
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF00022572:EE_|PH0PR12MB7813:EE_
X-MS-Office365-Filtering-Correlation-Id: c470c5e9-0b59-4933-bfb4-08ddf08fa2b2
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?NXF5RXZlOHBTOXptdEVEaVZ4QnhxMVJ2eFQ3Z0E4V1lIZldsMFRMMlVYejhs?=
 =?utf-8?B?N01JalFOTy9XVUdMVm0yQW40eithUmJyT1hWaTllYXpic0FpWkJ1SzBFNWgy?=
 =?utf-8?B?M20rYUJSTWg2clRIWFB5bjFRb2RZWmtHV2d5SzYwYkcxcEpLL3VZejJCVVNi?=
 =?utf-8?B?TFBxK3VSZTc1VWRxL21adXZydmYrSE5aeC9uV1RZTXMwVVRrQjBveVlJWktl?=
 =?utf-8?B?MTByZmo5QmFlNlNiRGlxZmFxTSswYkowR1JjM0pVUHJKUGNDMW91eW1PaXlS?=
 =?utf-8?B?VVR4SFRKMGJuNlVuaFhYd1ZnU1FMQkVoUTNsYWxnaGN2T1JoZnhjOGh4d2lI?=
 =?utf-8?B?WWozNFR1MnlLeEVHMDdORHM0ZnBobGtkcVFMR1RRUjgwREFZZ211cHU3SXdT?=
 =?utf-8?B?MVk4OXJWaXlSUWVzVXdKTzhWUWNJSjFNYXozMnV0RTJFQjFuLzBodGNUWWRS?=
 =?utf-8?B?S2pZSW1HS1ZHWVVCZ0t3R2J3TVVYUlhUd3V0M2FoM2VWQVc1QWg4TWJqTWRY?=
 =?utf-8?B?ZERNZnlpRms0Y3JkVmF5STZzSitEMkpKKzRESDgxRndwcHcvd3piRDVqeW84?=
 =?utf-8?B?ZklKY1JnMGtZazZiTWJ4dlRVbGloekw2SlE5L2o0RnJXOG84NWNXU3dhNEVV?=
 =?utf-8?B?SnE4NllJUzlXdGMxSStGcUJ5L1F6YTc5aGFLMlBabzdTNDdmaG5tQklZRmJH?=
 =?utf-8?B?cVdadzJVYjRTUWRySllCUVE2QzU4TjBSZDdscEFrMTJiSGNhL3VSckFVMkNZ?=
 =?utf-8?B?NG5Vd3M0QmNkVEhDeUx4UFppSFU5UkVpWU4wcE55TUNmY0s3eDdRZXJqRlpj?=
 =?utf-8?B?Wml0Y0Y4OWRpcU51SGUxL0lwSDNaWjQvZWo2MzVoWHh6dEFOL1BuTW5mUG8x?=
 =?utf-8?B?NzM4WEx2bDdaQWRmU01JaWxTalpnTEEvQjJGNkl6UUN5NXp1QURXWGlac00x?=
 =?utf-8?B?djZRdis3YTdwNlJvWlZoTlZZb00zNU4wdzFtZjBiY2dvZ0hIMjUrczUrQllN?=
 =?utf-8?B?d2l3RXpFNHVyclYwQWpiRFpMZTNSeGZSZjVvTFBxT3VUclNVc0RQK3FUeTNB?=
 =?utf-8?B?TURDZzVkby80SzZ3dFpXQ3RHUWRrRU80SjdJbGVUV0RQUHFROXp0Ni9CR3pI?=
 =?utf-8?B?SCs0NW5iS0JvWHZDNlh5Y1plNUVkSEFuTTNWdGpHSVIwMEZUbFBQZjFDWEtZ?=
 =?utf-8?B?NjNaYjBkbzJmVVZJcWVqZ0xvR0l3UEtFeVNxejNNSFZIM0dHOFQzZm8xNnBV?=
 =?utf-8?B?ZGlueWtYd0pES0N6RWFaSFhjMVF1ZTFHa2lOSk92Rm5HaFNHK0M5dmVzWXdQ?=
 =?utf-8?B?Wm1RR3pFQ0N5V0U2OE9zUk5BZGxLdzF3TDdpaFd6UDc2OFJ0SEhTK21IRnFt?=
 =?utf-8?B?ZG43SUVoVFlaWnMyallBR2RWbVpRcFU4SEVSZnNsWFkxbDBXR1Y5QTFTMEVx?=
 =?utf-8?B?RDJGY2s4RkdoMnZPSG40SitTc1JhbGhrTGZ6b3M1d2RJLy93bDVvOWVxSjEv?=
 =?utf-8?B?U3lMdzduMnBoaGMrNTh1eXZETkdNZFpMK2JYK0RNcXFkaVNabVZvMHZ5WFR3?=
 =?utf-8?B?RGdmTDVub3YyMitETXhxKzFpQUpHNXZGdXNHemw4VCtZRXhBZVVNNzBLUlhl?=
 =?utf-8?B?Tm9yVHJiZllyY28wRmhXdFMzcWxrT0h5ZVhBcXEySHAycEVPUjEwQ0lDVG56?=
 =?utf-8?B?aFRnclQ2SkllVHBjQnBhbi9Fd1VHMU1scXBkWFhGVjNGMFJrVHkrYUtVLzF0?=
 =?utf-8?B?ZjM1ak5PU2lpdDhaM01VRGwvVzhmMlllNEl4OGxYdyt0SnVkTUNqOXg5c3JO?=
 =?utf-8?B?NEFHd01uYktkRVoyZTlVdXk5TUVmNFNPK3U0Nlh6Z1RtWVRIM0dBVkVZRUh4?=
 =?utf-8?B?RnpUTk1xRnNGYjAxaXRVK3ZJdzZGUWV5eFh5b0VTeGNML3Q0WU1hcDdhRlVT?=
 =?utf-8?B?Qjl6S2krRFF4dzdUdW1oWWpyeXVuUUo4aDEybmQxdzQyeloxVzdCNkdvajBq?=
 =?utf-8?B?OTdjcDBKd3ZNNVowN2c3dnVWam12dmNEWXNvMThCOGw2SXlhenFBZ24zNk9L?=
 =?utf-8?Q?cWsasD?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 17:29:45.6632
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c470c5e9-0b59-4933-bfb4-08ddf08fa2b2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF00022572.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7813

On Wed Sep 10, 2025 at 7:01 PM CEST, Alejandro Vallejo wrote:
> On Wed Sep 10, 2025 at 5:31 PM CEST, Jan Beulich wrote:
>> On 10.09.2025 17:16, Alejandro Vallejo wrote:
>>> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>>>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>>>>> CPU hotplug relies on the guest having access to the legacy online CP=
U
>>>>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, s=
o
>>>>> this causes the MADT to get corrupted due to spurious modifications o=
f
>>>>> the "online" flag in MADT entries and the table checksum during the
>>>>> initial acpica passes.
>>>>
>>>> I don't understand this MADT corruption aspect, which - aiui - is why
>>>> there's a Fixes: tag here. The code change itself looks plausible.
>>>=20
>>> When there's no DM to provide a real and honest online CPU bitmap on PI=
O 0xAF00
>>> then we get all 1s (because there's no IOREQ server). Which confuses th=
e GPE
>>> handler.
>>>=20
>>> Somehow, the GPE handler is being triggered. Whether this is due to a r=
eal SCI
>>> or just it being spuriously executed as part of the initial acpica pass=
, I don't
>>> know.
>>>=20
>>> Both statements combined means the checksum and online flags in the MAD=
T get
>>> changed after initial parsing making it appear as-if all 128 CPUs were =
plugged.
>>
>> I can follow this part (the online flags one, that is).
>>
>>> This patch makes the checksums be correct after acpica init.
>>
>> I'm still in trouble with this one. If MADT is modified in the process, =
there's
>> only one of two possible options:
>> 1) It's expected for the checksum to no longer be correct.
>> 2) The checksum is being fixed up in the process.
>> That's independent of being HVM or PVH and independent of guest boot or =
later.
>> (Of course there's a sub-variant of 2, where the adjusting of the checks=
um
>> would be broken, but that wouldn't be covered by your change.)
>>
>> Jan
>
> I see what you mean now. The checksum correction code LOOKS correct. But =
I
> wonder about the table length... We report a table as big as it needs to =
be,
> but the checksum update is done irrespective of FLG being inside the vali=
d range
> of the MADT. If a guest with 2 vCPUs (in max_vcpus) sees vCPU127 being si=
gnalled
> that'd trigger the (unseen) online flag to be enabled and the checksum ad=
justed,
> except the checksum must not being adjusted.
>
> I could add even more AML to cover that, but that'd be QEMU misbehaving (=
or
> being absent). This patch covers the latter case, but it might be good to
> change the commit message to reflect the real problem.
>
> Cheers,
> Alejandro

It doesn't quite add up in the mismatch though. There might be something el=
se
lurking in there.

Regardless, I don't want this junk in PVH. Would a commit reword suffice to=
 have
it acked?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 18:59:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 18:59:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118707.1464382 (Exim 4.92)
	(envelope-from )
	id 1uwQ28-000149-FR; Wed, 10 Sep 2025 18:59:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118707.1464382; Wed, 10 Sep 2025 18: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 1uwQ28-000142-Ck; Wed, 10 Sep 2025 18:59:08 +0000
Received: by outflank-mailman (input) for mailman id 1118707;
 Wed, 10 Sep 2025 18: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 1uwQ26-00013w-SE
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 18:59:06 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2416::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 373ff95b-8e78-11f0-9d13-b5c5bf9af7f9;
 Wed, 10 Sep 2025 20:59:04 +0200 (CEST)
Received: from DS7PR03CA0308.namprd03.prod.outlook.com (2603:10b6:8:2b::31) by
 BY5PR12MB4212.namprd12.prod.outlook.com (2603:10b6:a03:202::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.22; Wed, 10 Sep 2025 18:58:59 +0000
Received: from DS1PEPF0001709A.namprd05.prod.outlook.com
 (2603:10b6:8:2b:cafe::90) by DS7PR03CA0308.outlook.office365.com
 (2603:10b6:8:2b::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Wed,
 10 Sep 2025 18:58:59 +0000
Received: from satlexmb08.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 18:58:58 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Wed, 10 Sep
 2025 11:58:58 -0700
Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 10 Sep
 2025 13:58:57 -0500
Received: from [172.17.248.197] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Wed, 10 Sep 2025 11:58:57 -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: 373ff95b-8e78-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CMR9rjrEUCIV6jGLSI3N800XeFcdzOw4bWgwM78PBbbqncHK2GKPv9wuzovjwXuRfura3Piaxd4BKAlQ0Val2JJC/+3W6stN2wz7MllAsd+EnxvPRPbAvLsDVKZKC87g8osFj8VkCFZF09Qkwd8iCybH4vC1iSUDlTlCyMza9FOkNCds0fKPX2kxyP6nUuNK9sA4JM0tQmmFbri8k8aEZ0ZDt4bVFuHmXPuZYXT4pd8wxG7GCtkwbGH5UDDth4acUXV1fIPrAsSvnVg03+AmaWTvay4QUuMUUo/XUH5prsada+2QVfKDm9rGqdU/8LhWb19bpjEhBaJnm3oiQ3g6qA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2ARLEM3ngR7nSo8f7KyFfxgKHL610BYYDyw90q456cw=;
 b=QIeQA9PrLIgeVyuZUmQNOSTWrZBdcgusj95p05dwaYA1JUUjyjY3BYIFQ06+1QfXiyf+DOcko6t2KDU8lVOCDCEKd1luPBp/+m3Qwjepolv0njRAI4PTZasKihD00rwDCMO2Rh3J8byGqpnuTl5q7qTt98/roiH40cq4YEQ5i90MT7l1/l3YMtRNmIcs546yY1W6wuFhnLUbrC6h9FR58e/cFW2MOc3NbIL8aoBdY7rOaiAoVXf+NX1Jz0Xv+ANHCYa83DrNWX26flPtu6GI9paVMGqBsjcHm/C/npSvMKsrIxK5UCVkhE2vswPCAJcRfTpVo6ShwGZSFlgWDWtZhQ==
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=2ARLEM3ngR7nSo8f7KyFfxgKHL610BYYDyw90q456cw=;
 b=CrtKQegwKBMRgDBWBe/ZwAhHFURxwQgOY1m1eARr8i1HmFQyHnzjxrJEmdllPU7ZVsBAjsi6+8Z+8u3BgnZFMUrKjL+uDhznG7S0tzjvEe015WzU5aY9Eu/khrpZQkiJFL9AnSvFTimeHQ48ofQtpjt/0W5OQR8p5+CzHIH50Qc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: 
Date: Wed, 10 Sep 2025 14:58:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel 
From: Jason Andryuk 
Subject: domU reboot claim failed
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF0001709A:EE_|BY5PR12MB4212:EE_
X-MS-Office365-Filtering-Correlation-Id: d5bf05df-3d36-4895-c9ff-08ddf09c1957
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?eVZjZ244R21teEVGWWhnbHp0eVBvRkFHMXI2NzVpTGQvd3pLNEdKYzFUY1Rr?=
 =?utf-8?B?amJvN3JrNEJRTWRxVXZ6d0Q2Z2pJWUxsOU13VG5qMnFqZnJwdzFVLzNwNHZz?=
 =?utf-8?B?LzA3NHFuME9HSXpiMlFEbHg4MW1tWTloaTBoc01FMGxPMmg1REZQMTFIemZB?=
 =?utf-8?B?L29CRnE0RW1uNldhSGI2cytVSlFhRmhKVW54K0oyaW41NytKMzIydmw0NWpw?=
 =?utf-8?B?KzEwNUcrNjhuZmYrdW5PWnVlSWhuckJlY1lZaXdsOFRlSVlxNERQL2VEd1hz?=
 =?utf-8?B?Ump0Rm1mYkNCNW5sRjdlL2tUMEpXQW01WEFXNXI1MDFhUkVESjNqQm1zYWls?=
 =?utf-8?B?SWhiVjFacWc5SWQ3WU8wT0hUcWNaYVdFS3JyQlJESDhQNTdLNFZCa0UzNUhk?=
 =?utf-8?B?L2pqL21MbVUvV2k1QmNPbFBsM1FLZGQxN2lSSVZ2Qk5HRk1WNExOOWpaKysr?=
 =?utf-8?B?R0ZYYWFFNDVZQmpaNjhnVjdsVmNsMS91VUNtbTVSdnY1TU95bHVKblphMFBS?=
 =?utf-8?B?OUFHK1JaSUZZcG1yQ3dNTU43YjRZU2xGbkI3cmNiVE1mT3JyTjNFNG9ZeEhu?=
 =?utf-8?B?WVdhUlVvZ0d1OGkzY1hUc2h4YW5jRTlQcW9VUVpDNTJWOGQvVkZNZmoxRHBx?=
 =?utf-8?B?Y0FxUTdMQmlrVWRQQzFwQ2lsa0Zpd3plUWswVmRqSkExWkFhc0h6Q1lucGkv?=
 =?utf-8?B?QUM3aGpCMmptS0ZxWC8ySmtoYlFJMloyYUNMYWszN0xIdW5HeDdmV1VPZ3l2?=
 =?utf-8?B?bW03eDNFNFN1NlpEM2V5SVBwTVJHeWozcGE1RFRlN0NPQUgyNVRSSWVGdEti?=
 =?utf-8?B?cTJDRTZFay9pd29yL2dTeDE5UGVWRHlEVGd6MFJ6K000Z3BZWlh3TlBab1hQ?=
 =?utf-8?B?ZWg2OGcwYi9IR3NHVmptVVczNkg2YUFXRWhEcFR0UHhESzJERlYvUXRKYjZi?=
 =?utf-8?B?VWpGeUJUSWRSV2FucVo4TnFOZjlKb2d3MUJ2R2NwTnVYZ1NkYU9tMWdmNXRG?=
 =?utf-8?B?WEY5N1pybXhsUHRsYXp2eXhaVXJ5dk9lLzF0MDQ1OVBWRzFvdU1uYVFzQXJV?=
 =?utf-8?B?dldkTXVCOWM4ZGx6UC9TSXNMYWhZVjB6WDc1K2Uxa0trZURLSElWMlBJczdO?=
 =?utf-8?B?KzNKc0ZPZzlXQTlkaG9WRzhEdEgyUUUrYjRuclB1VS9JMnZVV2JyN3JGM2pM?=
 =?utf-8?B?UnJZTWNuTEFZNFArVmNtRGMvVExpY1RCZW5VK2VvSnMwayt6RnhBRGVFZ3Ir?=
 =?utf-8?B?cHNpQ2VXZ2ZlWndTVi82RVNYT0ZIb21XOFF2TFdBQ2cybW1wZnBLWkJHTnlE?=
 =?utf-8?B?dFc5R1l5T0VZOUQzelgrT2wwckJPV3E0RXBUMDRFbm10RFpYYjV0eUM3akhQ?=
 =?utf-8?B?dEhDMWdOSThmNHppZUdKRTJBc2xSRGY1MVZZV1NQWDRHS2c1NmZua3hQT2Ri?=
 =?utf-8?B?cUx2MnJxaHIyVjZuODQ2amYrNG9RaVcyV0hEVXB5OHhSVTlPWTFsZGY3Nm1T?=
 =?utf-8?B?dU14OEJieWNISTZPTlpkVUdGYWNwVXlkcndLV1pkaVB3eXJockg1S1VSQWpF?=
 =?utf-8?B?QVJtOTJFaXFzVWk2R0JqL1Y1VVhzUDdjZFB3QU1WaUNDaGlETHhCUlpBVDB2?=
 =?utf-8?B?Y1Z1bDVyc2FZZy96dGphaXVERTAwZTFQTHpVeFNlMkFVRWQ2MlZQSWNmVHZp?=
 =?utf-8?B?eFl1ZFRyMFN1cnNSZzBnaStXUFRZT2tzTkc1dHpxaElVZ3o0RUdkLzVhZW5u?=
 =?utf-8?B?a3pBVDVVY1RjakYxdW1kRXUxYlN0Z0IveWJrdkZyTWI0bnArYVI5WjBUemt0?=
 =?utf-8?B?RVRVdzY0MDZveTRUbDZvbmxxby8zQ1FKR21qNDlTaEZoZnZQSHJtUTNaNTBu?=
 =?utf-8?B?aTNOZEZlRUJ4VzFnQkQrb2UydXpzYTdLTUdUOUJsdXI0MUllME1VbnlpcGUr?=
 =?utf-8?B?ZlViZVIxc3VxUHR4Ui95OW5ZS29CcEtSUDBKL1VDMExPN09tbnErY1NyTmpM?=
 =?utf-8?B?UktWQzg0VWxsYi9IbFJtMjVVUms5TGZHajFZSXI2MDJaakZwZW1wTWNMNE5k?=
 =?utf-8?Q?toSP0O?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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: 10 Sep 2025 18:58:58.6430
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d5bf05df-3d36-4895-c9ff-08ddf09c1957
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF0001709A.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4212

Hi,

We're running Android as a guest and it's running the Compatibility Test 
Suite.  During the CTS, the Android domU is rebooted multiple times.

In the middle of the CTS, we've seen reboot fail.  xl -vvv shows:
domainbuilder: detail: Could not allocate memory for HVM guest as we 
cannot claim memory!
xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't 
allocate low memory for domain: Out of memory
libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init 
failed: Cannot allocate memory
domainbuilder: detail: xc_dom_release: called

So the claim failed.  The system has enough memory since we're just 
rebooting the same VM.  As a work around, I added sleep(1) + retry, 
which works.

The curious part is the memory allocation.  For d2 to d5, we have:
domainbuilder: detail: range: start=0x0 end=0xf0000000
domainbuilder: detail: range: start=0x100000000 end=0x1af000000
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0000000000000000
xc: detail:   2MB PAGES: 0x00000000000006f8
xc: detail:   1GB PAGES: 0x0000000000000003

But when we have to retry the claim for d6, there are no 1GB pages used:
domainbuilder: detail: range: start=0x0 end=0xf0000000
domainbuilder: detail: range: start=0x100000000 end=0x1af000000
domainbuilder: detail: HVM claim failed! attempt 0
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0000000000002800
xc: detail:   2MB PAGES: 0x0000000000000ce4
xc: detail:   1GB PAGES: 0x0000000000000000

But subsequent reboots for d7 and d8 go back to using 1GB pages.

Does the change in memory allocation stick out to anyone?

Unfortunately, I don't have insight into what the failing test is doing.

Xen doesn't seem set up to track the claim across reboot.  Retrying the 
claim works in our scenario since we have a controlled configuration.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 21:58:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 21:58:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118844.1464492 (Exim 4.92)
	(envelope-from )
	id 1uwSpI-00065g-4Y; Wed, 10 Sep 2025 21:58:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118844.1464492; Wed, 10 Sep 2025 21:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwSpI-00065Z-1c; Wed, 10 Sep 2025 21:58:04 +0000
Received: by outflank-mailman (input) for mailman id 1118844;
 Wed, 10 Sep 2025 21:58:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwSpH-00065S-7T
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 21:58:03 +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 37ea44c2-8e91-11f0-9809-7dc792cee155;
 Wed, 10 Sep 2025 23:58:01 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-45df0cde41bso448055e9.3
 for ; Wed, 10 Sep 2025 14:58:01 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7521c9a2esm9136460f8f.14.2025.09.10.14.57.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 14: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: 37ea44c2-8e91-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757541480; x=1758146280; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gMcZ5/Z8eru/CYsg9zyRNPxYeOwt+OeYK1yBmcLCv4s=;
        b=LwzIz4R6ZLuEOsS93163GcDx8nHaqR+BwyQ6SL833nvCrT8Yjr/jj1u87BtFa9przU
         +iRw2iQTeLP311qYIdvf5B0U+4vFBOPofE8Ef829lccoAYg5ud5uu4e+NuTfARUv600G
         R7Ufy5F+LhoPOTcKVfF7kA287WeQdJMV8CRKw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757541480; x=1758146280;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gMcZ5/Z8eru/CYsg9zyRNPxYeOwt+OeYK1yBmcLCv4s=;
        b=HbkJJnKvNKVq5Bd8ETHMzlE2dNfPCtV+g/Lf9b9v7yc3WUFGqTjU3GVgnE4KNY7d3D
         pEE0Jh6/oBM+GV/O7nJCDtMYQvxzduxWnF0vEc3a26HRS5yegzDdgVh1tw1CpZ7JzW+k
         y+b4dkwj1V1O0Wrg/qgWmKmnI3iuvD+IuFIva6o2WuevO6Up8LBpFxcAffTdPbJ5JPYZ
         qg6Lswo4T/4Fd8cP4Nuj3ArFRHtQwsrD8tV7y5WuTbi9hoHEfiZtoFLcS9FQE/L7qumj
         id4bmgRomA0G/PoaUfZb9+C6Z2DhUeseO8PQnQSBl2aDhut/PKUh4MbVPga15SkUi3D9
         z9ZQ==
X-Forwarded-Encrypted: i=1; AJvYcCXLa3NnHYlGHfeqEvYjq2pQZOtTq9v302LPEgYl1l+ec+vbq06Mk7+zgjo9ql2Z6QX3XukFy/eKQn4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzNa0fopqdErVvwnOpcKbsrOjLgLDehkiibcHHU+8ZGq88pay7I
	y2X9wVgqdAQ1HYkoOCOYvXfbEjh2iXD8vwP7DeA1xgJn+aaW3lv+cXuT5p9Et1r8fNc=
X-Gm-Gg: ASbGncvdFzPNUASN88pIlD0Or4zjuBg1nXiaMRSpPZbEvp2ZkSvxg0TtKfU9XsyEvzQ
	VivzxHKjfTl7jfGm3zwherL4mT/wrFZvuc+oq9CUBUMOO2UYPB6Ujgpvp9s04J0wyIbfm8sAySY
	co2/fUU35NRBe+NuHj4MdGSgDCS0qwz7S97WyHIRmIKzq+cxDiscRf8zRq26B1Slg4t7zXUpSNX
	RqH/5vtCGsjNt0oZydHZmAXmDwfvuR12ClCOJVByHo/zRIcDe1D/GkNudGOqc/Yu3Cj2pOnbPld
	MymBCiUfl3Opp7Tmxshwyc+IX7+83B/tdmruQaGUAsyObYCsJ2tWW9gcVk5ViLWUcWsGWKsmKUY
	uy+n8OPDD/vhjUL/uOkLl7uln2JhQUu/hsRJGqOjM2kbkDhIjm+qMeyAFXDnU+4F+IgPn
X-Google-Smtp-Source: AGHT+IFQCJGdRhWzE+OAbnCcJ0g0+6rJ7r01ntPR+RRqL/jUtSvV5WSRQYST35o+xHknpjs8D86iUA==
X-Received: by 2002:a05:600c:198a:b0:456:13b6:4b18 with SMTP id 5b1f17b1804b1-45dddedd746mr166251105e9.31.1757541480256;
        Wed, 10 Sep 2025 14:58:00 -0700 (PDT)
Message-ID: 
Date: Wed, 10 Sep 2025 22:57:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: domU reboot claim failed
To: Jason Andryuk ,
 Xen-devel 
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 10/09/2025 7:58 pm, Jason Andryuk wrote:
> Hi,
>
> We're running Android as a guest and it's running the Compatibility
> Test Suite.  During the CTS, the Android domU is rebooted multiple times.
>
> In the middle of the CTS, we've seen reboot fail.  xl -vvv shows:
> domainbuilder: detail: Could not allocate memory for HVM guest as we
> cannot claim memory!
> xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't
> allocate low memory for domain: Out of memory
> libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init
> failed: Cannot allocate memory
> domainbuilder: detail: xc_dom_release: called
>
> So the claim failed.  The system has enough memory since we're just
> rebooting the same VM.  As a work around, I added sleep(1) + retry,
> which works.
>
> The curious part is the memory allocation.  For d2 to d5, we have:
> domainbuilder: detail: range: start=0x0 end=0xf0000000
> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail:   4KB PAGES: 0x0000000000000000
> xc: detail:   2MB PAGES: 0x00000000000006f8
> xc: detail:   1GB PAGES: 0x0000000000000003
>
> But when we have to retry the claim for d6, there are no 1GB pages used:
> domainbuilder: detail: range: start=0x0 end=0xf0000000
> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
> domainbuilder: detail: HVM claim failed! attempt 0
> xc: detail: PHYSICAL MEMORY ALLOCATION:
> xc: detail:   4KB PAGES: 0x0000000000002800
> xc: detail:   2MB PAGES: 0x0000000000000ce4
> xc: detail:   1GB PAGES: 0x0000000000000000
>
> But subsequent reboots for d7 and d8 go back to using 1GB pages.
>
> Does the change in memory allocation stick out to anyone?
>
> Unfortunately, I don't have insight into what the failing test is doing.
>
> Xen doesn't seem set up to track the claim across reboot.  Retrying
> the claim works in our scenario since we have a controlled configuration.

This looks to me like a known phenomenon.  Ages back, a change was made
in how Xen scrubs memory, from being synchronous in domain_kill(), to
being asynchronous in the idle loop.

The consequence being that, on an idle system, you can shutdown and
reboot the domain faster, but on a busy system you end up trying to
allocate the new domain while memory from the old domain is still dirty.

It is a classic example of a false optimisation, which looks great on an
idle system only because the idle CPUs are swallowing the work.

This impacts the ability to find a 1G aligned block of free memory to
allocate a superpage with, and by the sounds of it, claims (which
predate this behaviour change) aren't aware of the "to be scrubbed"
queue and fail instead.

I thought OpenXT had a revert of this.  IIRC it was considered a
material regression in being able to know when a domain has gone away.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 22:23:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 22:23:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118861.1464508 (Exim 4.92)
	(envelope-from )
	id 1uwTDl-0001XG-Bc; Wed, 10 Sep 2025 22:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118861.1464508; Wed, 10 Sep 2025 22: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 1uwTDl-0001Wr-54; Wed, 10 Sep 2025 22:23:21 +0000
Received: by outflank-mailman (input) for mailman id 1118861;
 Wed, 10 Sep 2025 22: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 1uwTDk-0001Ut-9z
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 22:23:20 +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 c03a574f-8e94-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 00:23:18 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-45cb6428c46so1117565e9.1
 for ; Wed, 10 Sep 2025 15:23:18 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e01ba9601sm2452195e9.23.2025.09.10.15.23.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 10 Sep 2025 15: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: c03a574f-8e94-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757542997; x=1758147797; darn=lists.xenproject.org;
        h=content-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=tCzfIeejqWxnyYgYr5WylmGRYjOyeO6wPE1ifH2pzDk=;
        b=cG2WcpxU+mSZ8D1o7i8+XYZQKoYbobmrVjFmICHBrWKLwKuHe0zFU1l6RfBFW9jobR
         JE0MzZxCoxgCjzfrumO55yRJZERHzbD2khO9+yVF/jeVohOzWm/NxetzIDO4MdJIjU+9
         BGSMOw/9x/k49dJX5yZrf1CdmYRFyz8ov21yM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757542997; x=1758147797;
        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=tCzfIeejqWxnyYgYr5WylmGRYjOyeO6wPE1ifH2pzDk=;
        b=fULvJk+DlWMTF7GhOOput0wXr1y4ALGPYMDiMKxTlBLCsRSq5zbVaH2/+220mZqWxE
         t2CU1t1Zk7vJuwWbKP9HTcqtpDFG3CHtPTUZe54ENGU7IcpH5OGPy6w7NN6tS4rBd9PC
         QH2LCeGPbQgiB59jVIUdBQIEtVslcYiTObDtWmnKuWPl2M/mcSFlvzidxesHfxdX96qt
         jc5I6QNKC0U5Pa6WnSOxSsf4u/S1uBycBB/S6FeKf3hB8HOmFRT/WKs5zTvXu26Zpred
         EdWByurlYirECtflSddSXgYQ76Hwy4+8kxMAFT9R6YxodMKFt1z/NRm5NBAT/SjhLR0h
         YO7A==
X-Gm-Message-State: AOJu0YzhtSXKMhtAvnv2x05lLMt5tuo96oWaFgiyNymkZ4SJpLD68SDD
	6muY7seeC92aptCXarNxHLxvbJp/vNuqDZArSmjekuVD01n6/wfAhSrovUn6fx3WT584Xt8I7F5
	sleHJ
X-Gm-Gg: ASbGncsXy85rWcyFSbRL3wN10HIQfe3HjVilG7GnIAVYxMJQ2rF3vUWhCZulQMxmoOS
	7c/wzZaSkfmyuJ784WH5RwkoR72Ncs+R3cVlpr/WNVKuo5IKiiKE0BYJ6QSuZX2jtlSgWPIlLxG
	k1lXma9QxVIQf3APP5/JZm50FBHvt6J1BkgrZnZERvinr9JkfrGWpdLzMWtgPgxVxaP38yXDTgL
	9jyoLKeuHgYTxId7jhnxeXU1vygiV8SkxUGCthpglmf99F39KqRGZpz2Uacr2k8w3sTR/BxTTOf
	HXrx9SglsNZ6owb5OcYqgE19lVWXSvossYdp02iya9rv+cvs42azHUtflw42/0BDB2vWsvdKVGY
	PElW/uiiuXxQrwQKaRuVdlOX1VS+IwcmwHVzYqZ1/0bQk1sr1tYOnGGZPwHD+mYnHKaWHalIqdi
	mKlXhdT092D78=
X-Google-Smtp-Source: AGHT+IFgVhsIV3sjv5Jkm8zI+KkmH5A4l49zYAjHw9/YXYcTvAF0Aaw5P7ixTUXv+K+i4dJCqKq/1w==
X-Received: by 2002:a05:600c:6305:b0:45d:5c71:76a9 with SMTP id 5b1f17b1804b1-45ddded7652mr171254285e9.24.1757542997319;
        Wed, 10 Sep 2025 15:23:17 -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 ,
	Oleksii Kurochko ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v2 1/3] CI: Update ppc64 to use Debian Trixie
Date: Wed, 10 Sep 2025 23:23:11 +0100
Message-Id: <20250910222313.1858941-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
References: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Everything works fine with Debian 13.  Provide two new build jobs (for a total
of 6), and update the test job.

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: Oleksii Kurochko 
CC: Marek Marczykowski-Górecki 

v2:
 * Update containerize

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2032972883
---
 automation/build/debian/13-ppc64le.dockerfile | 37 +++++++++++++++++++
 automation/gitlab-ci/build.yaml               | 18 ++++++++-
 automation/gitlab-ci/test.yaml                |  2 +-
 automation/scripts/containerize               |  1 +
 4 files changed, 55 insertions(+), 3 deletions(-)
 create mode 100644 automation/build/debian/13-ppc64le.dockerfile

diff --git a/automation/build/debian/13-ppc64le.dockerfile b/automation/build/debian/13-ppc64le.dockerfile
new file mode 100644
index 000000000000..5b22a4545842
--- /dev/null
+++ b/automation/build/debian/13-ppc64le.dockerfile
@@ -0,0 +1,37 @@
+# syntax=docker/dockerfile:1
+FROM --platform=linux/amd64 debian:trixie-slim
+LABEL maintainer.name="The Xen Project"
+LABEL maintainer.email="xen-devel@lists.xenproject.org"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV CROSS_COMPILE=powerpc64le-linux-gnu-
+ENV XEN_TARGET_ARCH=ppc64
+
+RUN <&1 | tee ${LOGFILE}
   needs:
-    - debian-12-ppc64le-gcc-debug
+    - debian-13-ppc64le-gcc-debug
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 340b6caaab44..65c8804ce5f3 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -31,6 +31,7 @@ case "_${CONTAINER}" in
     _fedora) CONTAINER="${BASE}/fedora:41-x86_64";;
     _bullseye-ppc64le) CONTAINER="${BASE}/debian:11-ppc64le" ;;
     _bookworm-ppc64le) CONTAINER="${BASE}/debian:12-ppc64le" ;;
+    _trixie-ppc64le) CONTAINER="${BASE}/debian:13-ppc64le" ;;
     _bookworm-riscv64) CONTAINER="${BASE}/debian:12-riscv64" ;;
     _trixie-riscv64) CONTAINER="${BASE}/debian:13-riscv64" ;;
     _bookworm-x86_64-gcc-ibt) CONTAINER="${BASE}/debian:12-x86_64-gcc-ibt" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 22:23:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 22:23:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118860.1464503 (Exim 4.92)
	(envelope-from )
	id 1uwTDl-0001VI-1E; Wed, 10 Sep 2025 22:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118860.1464503; Wed, 10 Sep 2025 22: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 1uwTDk-0001VB-Uc; Wed, 10 Sep 2025 22:23:20 +0000
Received: by outflank-mailman (input) for mailman id 1118860;
 Wed, 10 Sep 2025 22:23:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwTDj-0001Ut-KV
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 22:23:19 +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 bfb2e8a0-8e94-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 00:23:17 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-45dfe95bbb7so966845e9.1
 for ; Wed, 10 Sep 2025 15:23:17 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e01ba9601sm2452195e9.23.2025.09.10.15.23.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 10 Sep 2025 15:23:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bfb2e8a0-8e94-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757542996; x=1758147796; 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=HlkCMCHL5vKi/TSpvzV5Z9BPGY7+wbhbMerflx8hDtc=;
        b=Iehxnw7e7EqyHHuV0DF5mk1UfToAh3qFwtEX69GexNixvNYh8EHXU9XHLgt3MzMnkf
         xQ9mLmQEtUyPrkBeFHFGQPYhrBZAaSWbhbdnaPQTJVU87KqbV7yy4ia1nXm0QX8jrmne
         24AeYwr3KTgmsPrnpm+GOVrthE8CUuIjRhz0s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757542996; x=1758147796;
        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=HlkCMCHL5vKi/TSpvzV5Z9BPGY7+wbhbMerflx8hDtc=;
        b=uAaSj6uNgMZwG6vn55lV4Z0Ff4QCo3VZPWc/uy4LeYwd/IhBLnRFNizHKrw0T5iBLr
         fB2vtyH9S9vo/fqpaCDpV+m3AnLiR3eyyaFouCE7X6fJp3GqfoySVQGhwQ7KCNAqCdKJ
         3g2F60+mIJQ3AwvnMEuqVIoQTukfWVSTKmS6Pk6A53qRJABvhurzrrEJ6vn8WfXmiVRh
         R6UUqzdq+O9OA2mtBSDw9xBcC2UmhdhgCkgKIXkT/aPowtWJQG0LMiElqMqAcxDYp8P9
         Swf7iuY1NhWnwSwT5E/huFdH+sBtygxOuUCr8yYTnp9gWQnJdaoWHAguHWzeFWvNfLPA
         jNyQ==
X-Gm-Message-State: AOJu0YzinmsG3XYxFbqTktl4ZEJjIYyPeNNdVkSezXLC5ZlBDmLb1JnU
	n8DrAwMixFvznwR1HJTvprcIH3Gk9YPrRcdnAIt4ah8PoBCgDxEWVvaaK7ngajjBKnKZRDhT6SZ
	wz/Uq
X-Gm-Gg: ASbGncsInQ3P6tncmNxv9A7L6X/6W+eknLjhVFILRZIwzNAB6s6/LSTrH6C/ngJ4j8V
	op/wngFxaL4gBYZoz7cKwlsgS4rGMzuivk/onLcgMrIB84h5lRxA6geA/kzXTmmY2z/3YWpcBbM
	/u7AL1UOjHmbw2CpjT04yhvLjsMAnZWg2pWodKo4roMbaJ6Eo3cn5/03mWkPg+25h+WaiB5LEdH
	1K1lajcF3sIkaBW8Jis6iGZQNBqTgHrHVdvMC8hD9L5xuTkLjTyTUoYWTFYyR7sQs3QIUKXosxE
	WzvJkEG8spsst9r5OrsohGG2TpDDhuflY42NYpmmy85z1BkGwXfTbIyEX7hSHnCQgMKmhDIKI4M
	4jALT3lu62HmtEbExg9ZqrBlCgn5dEmlonqMBOgxi2KwUOkv45pqme9vRSW7hPvghOk/fAABlv3
	gKNrnTDbCZZ+Y=
X-Google-Smtp-Source: AGHT+IHCHjynZ6xrP4i5Gypcv4UUV+H8pbYMVE/XZKEjMRTVYnwVtaWsbMH0B4H2yoHuAqagH2T5zg==
X-Received: by 2002:a05:600c:1d26:b0:45b:90fc:1ede with SMTP id 5b1f17b1804b1-45ddde6a436mr166145185e9.6.1757542996321;
        Wed, 10 Sep 2025 15:23:16 -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 ,
	Oleksii Kurochko ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v2 0/3] CI: Add Debian Trixie
Date: Wed, 10 Sep 2025 23:23:10 +0100
Message-Id: <20250910222313.1858941-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

Refreshed the Trixie series.  Update containerize, and change one x86
container to be rootless.  Add some changelog notes.

These containers are already built and deployed for people to test with.

Andrew Cooper (3):
  CI: Update ppc64 to use Debian Trixie
  CI: Update x86 to use Debian Trixie
  CHANGELOG: Notes about distro changes in CI

 CHANGELOG.md                                  |  3 +
 automation/build/debian/13-ppc64le.dockerfile | 37 +++++++++
 automation/build/debian/13-x86_32.dockerfile  | 51 +++++++++++++
 automation/build/debian/13-x86_64.dockerfile  | 76 +++++++++++++++++++
 automation/gitlab-ci/build.yaml               | 72 ++++++++++++++----
 automation/gitlab-ci/test.yaml                | 12 +--
 automation/scripts/containerize               |  4 +-
 7 files changed, 234 insertions(+), 21 deletions(-)
 create mode 100644 automation/build/debian/13-ppc64le.dockerfile
 create mode 100644 automation/build/debian/13-x86_32.dockerfile
 create mode 100644 automation/build/debian/13-x86_64.dockerfile

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 22:23:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 22:23:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118863.1464528 (Exim 4.92)
	(envelope-from )
	id 1uwTDm-000208-Rj; Wed, 10 Sep 2025 22:23:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118863.1464528; Wed, 10 Sep 2025 22: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 1uwTDm-0001yM-ME; Wed, 10 Sep 2025 22:23:22 +0000
Received: by outflank-mailman (input) for mailman id 1118863;
 Wed, 10 Sep 2025 22:23:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwTDl-0001Ut-9z
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 22:23:21 +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 c0c09841-8e94-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 00:23:19 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-45df0cde41bso537035e9.3
 for ; Wed, 10 Sep 2025 15:23:19 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e01ba9601sm2452195e9.23.2025.09.10.15.23.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 10 Sep 2025 15: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: c0c09841-8e94-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757542998; x=1758147798; darn=lists.xenproject.org;
        h=content-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=TsvDGYEPLweUsKTm32GOVy1k3irFVmqIwkK2ri34C6c=;
        b=wW0gWllulCT8YSPivyvySTV5bWqbxSVABLm30yf6ILep/y1u0X8EqGgZeWR2wyiF8O
         ATXsnpRnoQrjNSeJJtBO2If22IyIKPH1oqRl2icBo6F8A+xWAPNUysTmM6s4VwOlry/u
         5/crPMTWPacp9+0SeCiqSh8bVQTpC1aXwadRQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757542998; x=1758147798;
        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=TsvDGYEPLweUsKTm32GOVy1k3irFVmqIwkK2ri34C6c=;
        b=h2/CcHOkR+DlNERYar2Icpp747/ugEDIgO8emyaJ+kwsVlYCFfw2E6amEXkSBy1RMX
         mXM5GUN58FMRXhzQKI3o11QxqZ0grPDUr9kXQWGB9abx3+Ull8KZjmtN99BCUIbHOEX0
         Wicr6oa2Nt0VZ28qJ9VHmvvMncFrFmR4qStwXelgD9dacV+HHdg0BJPvw1Q5QDHzHVq/
         5JTsSz8eZ9z1GxcT7/efGk2H+/rwlJiJnqSmazib/9jWHqp4P2rDir6wJr23MAcJV250
         fUEsaz2GcYsC+Yut/NpZrUWb02OPGbbec1tZBGNoKf+hrUlR/IQGPmy+wkgnrBSSNZUK
         6BbA==
X-Gm-Message-State: AOJu0YycBfAHAZm1ni8DpyDR8k6M7NI+XKj7+Aht6illEx8QzL3QKorM
	WXEFVdDpki3NRbUATbEVkkpXOrzYXQYaNkSqmV7ufqpMgv1kMfbiG7L5V9Y9klAvmI9knWQSkEo
	sEq+/
X-Gm-Gg: ASbGncs7slq+5jJ8sfnFPrW2q2tsJzCPw1DRGdgx3Fil7W5XxupfK2RxBOPoji6wofB
	7W9iy1XBpBEEL9F6FEDoqb341AIZFaXUCVRIcumtBADyOB/mTQmuuIAkvK+qyV28OyUGRAC2NAy
	9OKtEI7UHXabjnIB0IcAq/jcHq9Av2vB6ng7+vQfjj7/J1IPqXu1glFOMp+/0Pqp5JLE51QyonK
	uuJj8J5cfMhwkwteEVA2VhRiR9JUhQDTdjOOfTaSF9uzFSgXihAfysHlFCN7HVPHGnud+jfA7x7
	c7kWojxUto123H28PR82EBPetIQFOhHWuioeMq1YF3nRfwP3kKe8+ORehQC6/lQyUobpkUO1eZT
	RTQ0SmcZBoLGyJuYnhTOZW720Ju7v2mJZsjJdVr3rQ2iBSPiFC4MLDAKlWAaJQC4sso0DYgLfHA
	le
X-Google-Smtp-Source: AGHT+IGTlp7M9spv7PmpNnsSzBzGa6seXyBhwBa1Q1awbDimc5tqzQ8CHbWBh7Wy9zPMbG0aLrgwBg==
X-Received: by 2002:a05:600c:8b22:b0:458:be62:dcd3 with SMTP id 5b1f17b1804b1-45dddec82fdmr190022735e9.17.1757542998184;
        Wed, 10 Sep 2025 15:23: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 ,
	Oleksii Kurochko ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v2 2/3] CI: Update x86 to use Debian Trixie
Date: Wed, 10 Sep 2025 23:23:12 +0100
Message-Id: <20250910222313.1858941-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
References: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the exception of the custom IBT job, copy all Debian 12 jobs making
Debian 13 versions, then trim the Debian 12 ranconfig jobs.

Update the test jobs using Debian 12 to use 13.

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: Oleksii Kurochko 
CC: Marek Marczykowski-Górecki 

v2:
 * Make 13-x86_64 be root-less
 * Update containerize

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2032972883
---
 automation/build/debian/13-x86_32.dockerfile | 51 +++++++++++++
 automation/build/debian/13-x86_64.dockerfile | 76 ++++++++++++++++++++
 automation/gitlab-ci/build.yaml              | 54 ++++++++++----
 automation/gitlab-ci/test.yaml               | 10 +--
 automation/scripts/containerize              |  3 +-
 5 files changed, 176 insertions(+), 18 deletions(-)
 create mode 100644 automation/build/debian/13-x86_32.dockerfile
 create mode 100644 automation/build/debian/13-x86_64.dockerfile

diff --git a/automation/build/debian/13-x86_32.dockerfile b/automation/build/debian/13-x86_32.dockerfile
new file mode 100644
index 000000000000..2bd11af5a0c3
--- /dev/null
+++ b/automation/build/debian/13-x86_32.dockerfile
@@ -0,0 +1,51 @@
+# syntax=docker/dockerfile:1
+FROM --platform=linux/i386 debian:trixie-slim
+LABEL maintainer.name="The Xen Project"
+LABEL maintainer.email="xen-devel@lists.xenproject.org"
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+RUN <&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-smoke-x86-64-clang:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-clang-debug
+    - debian-13-x86_64-clang-debug
 
 qemu-smoke-x86-64-gcc-pvh:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 hvm64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-smoke-x86-64-clang-pvh:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 hvm64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-clang-debug
+    - debian-13-x86_64-clang-debug
 
 qemu-smoke-x86-64-gcc-efi:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64-efi pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-xtf-argo-x86_64-gcc-debug:
   extends: .qemu-smoke-x86-64
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 65c8804ce5f3..743567cb772a 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -35,7 +35,8 @@ case "_${CONTAINER}" in
     _bookworm-riscv64) CONTAINER="${BASE}/debian:12-riscv64" ;;
     _trixie-riscv64) CONTAINER="${BASE}/debian:13-riscv64" ;;
     _bookworm-x86_64-gcc-ibt) CONTAINER="${BASE}/debian:12-x86_64-gcc-ibt" ;;
-    _bookworm|_bookworm-x86_64|_) CONTAINER="${BASE}/debian:12-x86_64" ;;
+    _bookworm|_bookworm-x86_64) CONTAINER="${BASE}/debian:12-x86_64" ;;
+    _trixie-x86_64|_) CONTAINER="${BASE}/debian:13-x86_64" ;;
     _bookworm-i386|_bookworm-x86_32) CONTAINER="${BASE}/debian:12-x86_32" ;;
     _bookworm-arm64v8-arm32-gcc) CONTAINER="${BASE}/debian:bookworm-arm64v8-arm32-gcc" ;;
     _bookworm-arm64v8) CONTAINER="${BASE}/debian:bookworm-arm64v8" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 22:23:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 22:23:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118862.1464523 (Exim 4.92)
	(envelope-from )
	id 1uwTDm-0001wo-Ic; Wed, 10 Sep 2025 22:23:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118862.1464523; Wed, 10 Sep 2025 22: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 1uwTDm-0001wg-Ew; Wed, 10 Sep 2025 22:23:22 +0000
Received: by outflank-mailman (input) for mailman id 1118862;
 Wed, 10 Sep 2025 22: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 1uwTDl-0001V7-2r
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 22:23:21 +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 c102a923-8e94-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 00:23:19 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-45df0cde41bso537105e9.3
 for ; Wed, 10 Sep 2025 15:23:19 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e01ba9601sm2452195e9.23.2025.09.10.15.23.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 10 Sep 2025 15:23: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: c102a923-8e94-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757542999; x=1758147799; darn=lists.xenproject.org;
        h=content-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=Be6iKna05Jm3M6YBcH7sSksx9f/N4umOF44zDD8ok3Q=;
        b=kb6PcxXuEs07xUpRD3TaEfa+2GU6L+WsovhpcWX+mZ9hvsvft2IcKLGmYOFUqKzAOa
         W3yMcvD3OIzYNv9Ha24PjHA2bq7wES5BC+whH7ArvHrHh7IQuyl4o060u653Xp7OmXyM
         TEMNBGwAprXYyBtNkwOgwuuJzJf/OBRBiO4NA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757542999; x=1758147799;
        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=Be6iKna05Jm3M6YBcH7sSksx9f/N4umOF44zDD8ok3Q=;
        b=Ek0tWgwCyclQpBkZswL4wvsfM8qIr9OWVOA9R+WNEpmdR4HfEDlAleBknuqKytHWWR
         DkkfMxWiNs+jcxxfpPKsdPc/sJEOVDtUVzuVbvunux69NkmlQ4YC0RxmGxnZOi7Q70ft
         4NYHt7mdOlKze40yENSn8JfdNN/VQdp+lF/HoclreevP5ywnjPbYbK34ylTpAHQgVREQ
         u4Z+IBx5NZ/rvB2HGdW5o9+HOwn/ouVBCednFhd9/HjDHR100p3Un93nIUmDkDr1Uusw
         tWHQvm/NrEcavZ4QIMa8zH5lCiKZraZX9wd15s3o8cnS5HwMHseqqm4/ziKnEKHJOtx2
         Wp+Q==
X-Gm-Message-State: AOJu0Yy9NhH5tG+57z95B3+flB+IR3XhZ38bVcIKJVF61qUzwUZLu3CU
	XhGUce6jCQhc0OSAe7GhfpQ3aiczSTlevkAv9hiG376qgFxM2m2lxOyWEbz9Ffil6DRiAPWss2i
	puTFe
X-Gm-Gg: ASbGncvfaogfA1NJm1pFO1LKw6brIdFurtkGQ0cxxx5InpUn6HU2xqWh2pPb2b+6ZvZ
	KRUdweCsfbqPNSx+AL+LGjOLVlNGsjEYaz9m4gfmH0JtVqqkFwCeMWU3YOaqXfPlIgqSnmrQZ7E
	M2qwDICqV3+FRcxLp4YTzUuS13kmsH1chiLhU/Y3KcxKX8ft8yNWpmutnoEXmCwtp8xzNelRgpM
	qXQubVi7fsItUzJPYX5oZNBCytzxtHIIjUGYWMW/cou4D9cuJrqWPZmj3wbz4S/Aq0LP1Bqi4vU
	0hNB+rpN1j837WSaTdJN1YwwDe/l6jqofkfLkY1yI8Lalf5Yayv4w0evlAfcKQVfzTkw9FipZWm
	oR2NaGniBa+BHY3ILyHJ50y4apE1z4YWx4ijX/t97IxOl5IiB1NiII0PuA2MqiGFLuDM+WfPJE3
	MKUHLLol/JLQE=
X-Google-Smtp-Source: AGHT+IGMDJKbOmww8BMqXwVLHBklHv2GzHyGwx53WGJ6C77VFn6KmUcRjq7Gpd0R2KmIH5+jdOZZxQ==
X-Received: by 2002:a05:600c:4ed2:b0:45d:f7e4:bf61 with SMTP id 5b1f17b1804b1-45dfe9e81d3mr8822055e9.4.1757542999038;
        Wed, 10 Sep 2025 15:23:19 -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 ,
	Oleksii Kurochko 
Subject: [PATCH v2 3/3] CHANGELOG: Notes about distro changes in CI
Date: Wed, 10 Sep 2025 23:23:13 +0100
Message-Id: <20250910222313.1858941-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
References: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Also state the RISC-V baseline now it's been set, as it's the reason why
RISC-V Bullseye got dropped.

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: Oleksii Kurochko 

v2:
 * New
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7bd96ac09d14..ca1b43b940d2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -10,6 +10,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - The minimum toolchain requirements have increased for some architectures:
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
+   - For RISC-V, GCC 12.2 and Binutils 2.39
+ - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
+   to the baseline change.
  - Linux based device model stubdomains are now fully supported.
 
  - On x86:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Sep 10 23:40:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 23:40:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118945.1464543 (Exim 4.92)
	(envelope-from )
	id 1uwUQL-0004mc-8p; Wed, 10 Sep 2025 23:40:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118945.1464543; Wed, 10 Sep 2025 23:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwUQL-0004mV-5X; Wed, 10 Sep 2025 23:40:25 +0000
Received: by outflank-mailman (input) for mailman id 1118945;
 Wed, 10 Sep 2025 23:40: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 1uwUQK-0003qA-4O
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 23:40:24 +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 83de0bbb-8e9f-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 01:40:22 +0200 (CEST)
Received: from SJ0PR13CA0212.namprd13.prod.outlook.com (2603:10b6:a03:2c1::7)
 by IA0PR12MB8696.namprd12.prod.outlook.com (2603:10b6:208:48f::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 23:40:17 +0000
Received: from SJ5PEPF000001C8.namprd05.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::68) by SJ0PR13CA0212.outlook.office365.com
 (2603:10b6:a03:2c1::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.6 via Frontend Transport; Wed,
 10 Sep 2025 23:40:16 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Wed, 10 Sep 2025 23:40:15 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 10 Sep
 2025 16:40:13 -0700
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 10 Sep
 2025 16:40:12 -0700
Received: from xsjvictlira50.xilinx.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17 via Frontend
 Transport; Wed, 10 Sep 2025 16:40:12 -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: 83de0bbb-8e9f-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vq87AHm+TLSXR6RTPQRcOuuNQydcXgID9TXIKtukqlrLr1SOEkITG0URqclAJ2zn48g1jezvx8G+4XzGo9uaaig0fUT2IgW7IAqCxsKsQR/zBvFTXWvcLf0lfopjUs4hbtEp7d0sAmmBeUTAXKxOrh6ufY2JAxkJraJd+OL33C2NTkfhN8n7uvSOOQswsR+pHoyP/zMedTa24BtSrAjFuHdeHJMC9+L06U/eN+STjWlU/skiAcXJ7tcuKvkCCTiL9T7my3kKGCtLwbPssDf15sPVVOzatE3td5igSoxQwrG2KMk8egJcKrFMt9SieNkjCmWRfSFdfv5CbVmTlDJ2WA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ywd4+98JNVWn5LlquwViQkCbOtL4x1Nk8xfenPNoMXs=;
 b=WzckdDXhbPy/horpvlCWctXE04sL50QB0kAlhCav4D+Urqz3qOV6KIARTi+nnxTzow/AaT+tglg6Yukt+vl67x+Vtdh+tfKdwd3RIBJXnVxlbZnwvAUfKW8FrRLJaray9zwaa7PEEwLU7NtBq1ObN6a3DTw3Sn/j3xlgW8HxV/crGvfgD3J+QWfBP+SXL0TAGvXRdP+AvB/rRPjxREjiTPmopK1QqZZlfNM7JHpl6riA8Ja5jxeu2JsVtWXVQtD39T/UGkuOGVhYFu7cfmBzzLpHtTfjyf5onKG3pTVAQOYxmvxe91VShfgGOt8JNsZIcEpns3mzXREwcVxM6bepzg==
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=ywd4+98JNVWn5LlquwViQkCbOtL4x1Nk8xfenPNoMXs=;
 b=ZFJcNzSBHtHKQ809GH/WJgToK5kkpAiObZEtET5+oqw0Kd7d/XOUkUwG0kPq6lDA9QXY78WGthy70GA+cV9ARMO1mBS9E0IMOpT+21epaXdUHFeEyl2AbR2TxB1sG84umlx/KNCuz63HRhsfHKk2Uv9zDSbFGWQSiSObi68SBT0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 
To: 
CC: Victor Lira , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v1] coverage: add missing include for macro
Date: Wed, 10 Sep 2025 16:40:02 -0700
Message-ID: 
X-Mailer: git-send-email 2.50.GIT
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C8:EE_|IA0PR12MB8696:EE_
X-MS-Office365-Filtering-Correlation-Id: f59560b8-0ad3-4857-f94f-08ddf0c364e7
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?sVtTsHYYZUsT6jpUFu88i8sNhGOBKBdBurwgCM9Cb3guzWftETAAF4apy5M8?=
 =?us-ascii?Q?zb9V+FehRT4iV+i41+GiJV8NPumMLQJhvjTM/cyaJxpAeoTiwed4jEbkDfuE?=
 =?us-ascii?Q?0i8C/IEgb6ZyEYIb00kCcdISbvs7BA3PPvOspZQIxsoSHEHsaH9oe+SWcukC?=
 =?us-ascii?Q?unRu3qNUcTCld9U/4j2XpaTpCYnpKIxG3c2hckEEc5iJcSwI3qLJhaCCrK5F?=
 =?us-ascii?Q?3V15SiVmElff/BWiC7N/3NaY8MA/l5jUVjpOdyyDWZixWymcQdpR/MNXNh6S?=
 =?us-ascii?Q?golr15E3McZg8shRn5jYHHFdFcmrR2VkpM2WXARYxk+spyq2XBhLR6Y6c/Oh?=
 =?us-ascii?Q?/mzhqw9/QXekMQ5t+6G2ZGDePNp8LOv4YduPTTFMf9AkQIXtvJXXBzotQK5b?=
 =?us-ascii?Q?EagQuufickrWo74cmJqNJh+Mkdi55pVBgbjepXVoRNyFdJvaLQ9Vpv8IQVs7?=
 =?us-ascii?Q?wkX5wG1XMfh8i9b05tseN4tKJ3CIp53caA6YGRgTolsgWGqrT8u5hT74NDRG?=
 =?us-ascii?Q?SsFSttccDbkEzuhWCptt6TzikMG2OBmU4H+Vbp6zHsV/mghH1OKtaTwWRpk5?=
 =?us-ascii?Q?9GLaviUkkJmpNpPNmhUmadjh12CiImve0gvrr2qUoa4i5yTm1nyZsCZ1g0CN?=
 =?us-ascii?Q?dgm7cDeWnIb43Kmajn17/er/7ilPAdq92fa9TPwrobGL+ZadKRim5X+9MN3a?=
 =?us-ascii?Q?2qSMkitFXIZWDMJhicL2738lKScspXCWoBjlUoldLUl6xiOyB+I8uU0kcmyW?=
 =?us-ascii?Q?GFRrPB8f0kKlQ90Y0KZj4rbgUGr2UO8b+/GH37IY9H1KLxFnx4XS394rylQE?=
 =?us-ascii?Q?wd9i1x/gSlWX8bRLLYM+SuzQyR9N+MHPlzONMDIWRTBsrdTd79jzXhFRNJ5R?=
 =?us-ascii?Q?xz27jrM/iF1vSDEYpbtT+PeCYPjQdDWb8e23XnYUNn1ywOcigIBnuGvkfnDO?=
 =?us-ascii?Q?C0q0dPiDTRjI7+f1HLnwKQAGHBf6/JX0WoEjIc7tYf/3MbutDdLkYuLZXGQs?=
 =?us-ascii?Q?qp51L/jS3ke8z+BL/AlD8xynMwCQwbNCvUyuvriPz0sZcRgLS+32AgwpHG08?=
 =?us-ascii?Q?GtKP4NqJFN0WcSiHaqpv9IzFVH+7h8cE4WN8B3vxozHyz9/9d4N2K9GFd7aL?=
 =?us-ascii?Q?kIpxPJdoh5iKv3Mevql6UZfhayxvhhDhU5q6Cohgp6/SXmNbrCe+01P6LERT?=
 =?us-ascii?Q?oe3/wF90mSX1Si6IL/2zBrDY4FKeuig1TXyT0INXYqXW78JXE6ETqZx2+tso?=
 =?us-ascii?Q?0JQHLIB3uhItLW6ZXpNiqHZRILx0q8LBb3vQwlJuM8saDeAxaCb9F0G9uMCQ?=
 =?us-ascii?Q?q/qKbl0fhFXBmxxTBZpNxLg55Xg1IFqqHw+KLyQAVQ/Odn+CgR4I0LI2Rey6?=
 =?us-ascii?Q?0+B7E98CsmMWPvNefFhyPhEMCBthOVpdP6fc4ooIhY0vfZ5uuW85Bay63bNP?=
 =?us-ascii?Q?IIcYie71K8BWJgVZjeDwDSwWisahiwPrCnoxAAB0DihVh07AINyyVAPqIWno?=
 =?us-ascii?Q?9NSIGymBDY24VgR80OqFJXb9m7iZjFmeje12?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 10 Sep 2025 23:40:15.7898
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f59560b8-0ad3-4857-f94f-08ddf0c364e7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001C8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8696

From: Victor Lira 

The missing include prevents it from compiling when CONFIG_COVERAGE is not set
and the header is included in a file that has not already included errno.h,
causing EOPNOTSUPP to be undeclared.

Add the missing include.

Signed-off-by: Victor Lira 
---
example of the problem:
    diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
    index 7ad870e382c..4d27f16e8ef 100644
    --- a/xen/arch/arm/setup.c
    +++ b/xen/arch/arm/setup.c
    @@ -10,6 +10,7 @@

    #include 
    #include 
    +#include 
    #include 
    #include 
    #include 
    ---

    In file included from arch/arm/setup.c:13:
    ./include/xen/coverage.h: In function 'sysctl_cov_op':
    ./include/xen/coverage.h:10:13: error: 'EOPNOTSUPP' undeclared (first use in this function)
       10 |     return -EOPNOTSUPP;
---
 xen/include/xen/coverage.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/xen/coverage.h b/xen/include/xen/coverage.h
index ba5fb67947..28506c239b 100644
--- a/xen/include/xen/coverage.h
+++ b/xen/include/xen/coverage.h
@@ -5,6 +5,7 @@
 #include 
 int sysctl_cov_op(struct xen_sysctl_coverage_op *op);
 #else
+#include 
 static inline int sysctl_cov_op(void *unused)
 {
     return -EOPNOTSUPP;
--
2.50.GIT


From xen-devel-bounces@lists.xenproject.org Wed Sep 10 23:47:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Sep 2025 23:47:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118961.1464552 (Exim 4.92)
	(envelope-from )
	id 1uwUXH-0005Pr-Tg; Wed, 10 Sep 2025 23:47:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118961.1464552; Wed, 10 Sep 2025 23: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 1uwUXH-0005Pk-R5; Wed, 10 Sep 2025 23:47:35 +0000
Received: by outflank-mailman (input) for mailman id 1118961;
 Wed, 10 Sep 2025 23:47: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 1uwUXG-0005Pe-KW
 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2025 23:47:34 +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 800813fc-8ea0-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 01:47:24 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-45cb6428c46so1626215e9.1
 for ; Wed, 10 Sep 2025 16:47:24 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm5139035e9.10.2025.09.10.16.47.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 10 Sep 2025 16:47: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: 800813fc-8ea0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757548044; x=1758152844; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=S+0jbgcvmEaxlDS/V2Fg6mrwR+BPyJ7ya3qULySWySI=;
        b=onXpSidz0Ff23Hm0BkYRS5FAfaR8arpiKsaY1m5aOziGO/LJdzy2kZQAdS9gUsOhx8
         VOWIjVofXH6h4f+BmwdisNHHcaaPWsWv86pLOkLlgKm2ZiOfCrdFdV+DEYkIh9cveDRI
         jwE/71toV+MhO9OEJnjyD/Ha0XMAjwmJ3BTxc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757548044; x=1758152844;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=S+0jbgcvmEaxlDS/V2Fg6mrwR+BPyJ7ya3qULySWySI=;
        b=mMT4xDVF2yP/VpE1LBEehkiQELVdMmGAWlsAi2lrSjqVzSwtRcbt87ZQpTZig29X6Q
         0bVnRSWBiTWJRL/h+lwyq6A5YacArnWjPDkDyWA/CA3O/heBeFE4YHtXUeQEPmbVP4yz
         1TB2zouBBaH8JMnzEDEvr3Arr96TlCjJU7eElIjaqwvMihLwiDugL7SWPMnQs6U00t8T
         TgFrp+v6eeF3q8GhyFM0L7CaBrVYUhPo49BSG7ocaHmnp5r8C7n5QDlujw6MXgL1I6hU
         eNXIRhqL17xsZPwF6HG1imAXTAhxxMMKig5gpwN97EvyNByn12KpHUffAFGsRAwh/Lka
         NbFQ==
X-Forwarded-Encrypted: i=1; AJvYcCUc2uRvGKvEgDa0cT35GwhjYF+Pi2VeAGWHWHnc7IYr/CnR5+clFAF6tEB7GLn5q5zdqQ9RTVkeG0I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzToZGhyHJgJTE1VEXUjhjZkFaiEUXtgt4zvusFdvePRV0FdfGx
	Iw+InYKpUAJQM9yzbrIF7R8ZAJXx1iD1/eiSJIjC0WvOFIIeYWM7SoUIV6y5wLulFgg=
X-Gm-Gg: ASbGncuc0dBdkTxHojMaHmXUVlJgbyEyPk51XiecKVt6hx0MGhCFcgNba/A2XxklRTF
	epFRPm9B3zif+R/sISQt87enaww4ypDsRspmqnBQ+HEeQsXMpr2j1aQ4yYyvqFmsKoRHOQu46RV
	43bTbKPTaV6TA0WgczsEhPa4txRA7Uf1umCtly0BV8JgAqPaj3gTwkWdIn84EWuDepstPXgH8E8
	XZsHHgO7gMe6+NMKvZWUMZc0CIkecOvAZSr3JVUgbr6zuSphYb74VOBisDYZPYLlvdEJHXUbXzq
	fJp7OxE5Y2B3fDdyurvWJZNEgyXofC67IwgakjFUfWqD+OQ+xwyCSnqIIc2LMZE2TH5gRi2QUxF
	p0Clk5tOURYlnEW38ydsDn1P6jFrgbtw+CLT6AoPjo/ZTAIGfQ0wnvS129pPanlBnQJmTq6bQ95
	56cCE=
X-Google-Smtp-Source: AGHT+IEWfgwNtnTl8WTz+lNaJ0U2zfFL9OHwwqCYMfAFSYZ8ZaQCrLHJWXff+Vnvgy66xEur8m9/+w==
X-Received: by 2002:a05:600c:1390:b0:45a:236a:23ba with SMTP id 5b1f17b1804b1-45ddded76a6mr143623435e9.22.1757548043858;
        Wed, 10 Sep 2025 16:47:23 -0700 (PDT)
Message-ID: <93b71cf5-5f58-4170-8e4e-0dee2ec21484@citrix.com>
Date: Thu, 11 Sep 2025 00:47:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] coverage: add missing include for macro
To: victorm.lira@amd.com, 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: 
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 11/09/2025 12:40 am, victorm.lira@amd.com wrote:
> From: Victor Lira 
>
> The missing include prevents it from compiling when CONFIG_COVERAGE is not set
> and the header is included in a file that has not already included errno.h,
> causing EOPNOTSUPP to be undeclared.
>
> Add the missing include.
>
> Signed-off-by: Victor Lira 

Acked-by: Andrew Cooper , although

> ---
> example of the problem:
>     diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>     index 7ad870e382c..4d27f16e8ef 100644
>     --- a/xen/arch/arm/setup.c
>     +++ b/xen/arch/arm/setup.c
>     @@ -10,6 +10,7 @@
>
>     #include 
>     #include 
>     +#include 
>     #include 
>     #include 
>     #include 
>     ---
>
>     In file included from arch/arm/setup.c:13:
>     ./include/xen/coverage.h: In function 'sysctl_cov_op':
>     ./include/xen/coverage.h:10:13: error: 'EOPNOTSUPP' undeclared (first use in this function)
>        10 |     return -EOPNOTSUPP;
> ---
>  xen/include/xen/coverage.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/include/xen/coverage.h b/xen/include/xen/coverage.h
> index ba5fb67947..28506c239b 100644
> --- a/xen/include/xen/coverage.h
> +++ b/xen/include/xen/coverage.h
> @@ -5,6 +5,7 @@
>  #include 
>  int sysctl_cov_op(struct xen_sysctl_coverage_op *op);
>  #else
> +#include 
>  static inline int sysctl_cov_op(void *unused)
>  {
>      return -EOPNOTSUPP;

... this is starting to get overly busy to read and could do with some
extra lines around the primary #ifdef CONFIG_COVERAGE / #else / #endif.

Happy to fix up on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 00:33:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 00:33:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1118988.1464562 (Exim 4.92)
	(envelope-from )
	id 1uwVFS-0003vQ-3C; Thu, 11 Sep 2025 00:33:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1118988.1464562; Thu, 11 Sep 2025 00:33: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 1uwVFS-0003vJ-0f; Thu, 11 Sep 2025 00:33:14 +0000
Received: by outflank-mailman (input) for mailman id 1118988;
 Thu, 11 Sep 2025 00:33: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 1uwVFQ-0003vB-HH
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 00:33:12 +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 e42f952a-8ea6-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 02:33:10 +0200 (CEST)
Received: from BYAPR21CA0029.namprd21.prod.outlook.com (2603:10b6:a03:114::39)
 by DS0PR12MB9348.namprd12.prod.outlook.com (2603:10b6:8:1a0::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 00:33:04 +0000
Received: from SJ1PEPF0000231A.namprd03.prod.outlook.com
 (2603:10b6:a03:114:cafe::85) by BYAPR21CA0029.outlook.office365.com
 (2603:10b6:a03:114::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.6 via Frontend Transport; Thu,
 11 Sep 2025 00:32:58 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ1PEPF0000231A.mail.protection.outlook.com (10.167.242.231) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 00:33:03 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Wed, 10 Sep
 2025 17:33:02 -0700
Received: from satlexmb07.amd.com (10.181.42.216) 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, 10 Sep
 2025 19:33:02 -0500
Received: from [10.17.28.33] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17 via Frontend
 Transport; Wed, 10 Sep 2025 17:33:02 -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: e42f952a-8ea6-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qaFwrGm744H4dNCqvZj5zokUiDPw65eUyPRTWxTRmWDfN1D2IfuSBdgj+fDImotU72fIT761JzroBa9zpK681ib7Cmimd06h/PeYckUWX96dhIXEID8RJyLiJs4NN4LMF9nvcIqdkcLUd9E0i9A8uhayft9wGrusn2ADRz7ZvXHtHOeowJJRCFksuW9W6oongkDJ68enGKfFYaZdkaIMLSDhmOPNRkcsgyDy3TOpkddBGw7EsSlTjq/x4LV6SeztD2lpdI4TN/jgX9FBrjcnU92tPSI1MntCeONrHvwTaYoyDDYkIz/TA+RDMLNt6t34gWXf/XxgqWtRcpsP8tjVIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GDWJSEcTVjc0wJZaqkRixzXwBrasAZEKCM01Inh6H/s=;
 b=fRpo6UcGNQxfZYxZQ0Zt/OwzW8amoDJikVqUIjVkw8fB6zZuTCISMTA6fYi8Ktbkst6TOUFTmQoP5EVW4u/eHs+We8F7VO47LQDYLYDEGRfvQ5nspLlwBvLlUJIYWk3PdpRrYCqIFerK7MtvlSywaI5LJH6yrGPCrJrtcJ1CbRjKGU2+BqhzVFEloUa7/jcYIfKYNw+7EjABMMNpigiyANcI4av8zUbQ69rHnuf4b2I++pEtxaI3YAdda9AsGyjTeGF26KleTIrzh5zZ1HdS7Fk/ou6x04ISJhI2azGuttEK6hwX4wkJBI6u+6VMswYkypfrm04H5fvjIHMY+fIVFg==
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=GDWJSEcTVjc0wJZaqkRixzXwBrasAZEKCM01Inh6H/s=;
 b=Dk/zU9C64HnNl1m8x6c9/nQgb7asVKbZyHmQF8oPjwc82gZJRhFMUlSBPXmvQfPVcl7YxBTBnc/x47A5KMMhFmmi50yfqOmYrsS9fxamxo9QWLmM5vT1D70EFN3WB5tG4OyxZH34tuFmg3dn9hT1KBwTx6EGWzmjBh+dFtqkHv0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <2df767a3-8a37-4cb2-82c7-2b1c9861cc69@amd.com>
Date: Wed, 10 Sep 2025 17:33:01 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] coverage: add missing include for macro
To: Andrew Cooper ,
	
CC: Anthony PERARD , Michal Orzel
	, Jan Beulich , Julien Grall
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini 
References: 
 <93b71cf5-5f58-4170-8e4e-0dee2ec21484@citrix.com>
Content-Language: en-US
From: "Lira, Victor M" 
In-Reply-To: <93b71cf5-5f58-4170-8e4e-0dee2ec21484@citrix.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
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: SJ1PEPF0000231A:EE_|DS0PR12MB9348:EE_
X-MS-Office365-Filtering-Correlation-Id: cd14128b-0d9f-4ce6-2d6c-08ddf0cac532
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?dllQOVp4NTVPUTMzL1A3VVN4ZGZHQ3RLVjV6aFB3NHgyaERPMHVmb0RVWlB4?=
 =?utf-8?B?dkdiZGhST3Y4M3lBYlB6TDFyMHNwY0ErMGFQZUVyWFlUbUZPOHVJWElPaVVZ?=
 =?utf-8?B?dWY0MTVNWnMyTStxSUQxaWFCWUZmQ2R2MmlESXNvUUhpZzkrNGJMUGlzSmNT?=
 =?utf-8?B?R01TaUtEWTk0eGRUOThYb2l1ME5KNmRWL2N6cXQ5NmFHQlM4cDNqcFNLRWpE?=
 =?utf-8?B?dktJOWx1RWF4dXZxMVZNZ1h6MTNSamU0cW10M1hibzdhd093NE9WeTZMS3k2?=
 =?utf-8?B?SGQ5RkR0cGc1V2Nxcm4vRmIrcEtYNHJPaytVVkw4UmZhMjloMHRLZS80OUFo?=
 =?utf-8?B?OTFuNy9kRVRvaG9odW0wSkNVZFBrV3NYL2JIV2RLdVhXWHhXVW9LaEpBcEVs?=
 =?utf-8?B?dDNOK3k1WWx6bzloQm0vcE5DZmFPekdydGEySXVRUWhTRS9zd3ljVkRZWUpa?=
 =?utf-8?B?YUNjOWxEcjF6aVdRREhxU29LNCtmWVhnVExQSEI3TTJUMWRQUFF2S1lYeEIx?=
 =?utf-8?B?eVJTMVFFd09QclYxY2pHbGtWNUtBTWFWa214Vyt0dGNZdC8yR3d4SlNFSlBv?=
 =?utf-8?B?a3JVRlVHWWp0YTZaV2o4S3lYQWdBNVNoVUd0clFBbm9LTlhHMDRlaUtyT3RB?=
 =?utf-8?B?ekIwbG40R0J0NWR6WUdEWm90UkczcWlHQWRBTGNSVFdpdWJzdFdRdDNFdWhn?=
 =?utf-8?B?aFpiVTRtZHN5ZHVzekZNSDluZDBmZVhaL04rTWI1ZkNJbmRSbGlGL25rUHpk?=
 =?utf-8?B?QU9mMWx6eXAyaEpaOVcwcDE3azc0UjdodUhHZDBaT2VsUDB1M0E4Wk9xcXlN?=
 =?utf-8?B?Y0w3VEhHb1UvMHZZY2dFaGlFRGlaYm1WTDFYYU1sQU9wY05heS9aOHZvTEJW?=
 =?utf-8?B?ajhQb3dCc0VLY3dNNDBTcHVYcnlEYnM4cTRQK3IwdGxHYmpONU15Y0dUbFBF?=
 =?utf-8?B?ZHd2SVRjSWtvTHBRYVN3MFoyNlNYd0F0NW1OQlhEYUZ5VHlucHVtQ0dRVVgy?=
 =?utf-8?B?VXhxa0pKTGRSNHZlTW5ZTkhqUDVlcW5NS3FWTG5ucG5uMnpGTkJFWEJ2aVNC?=
 =?utf-8?B?UENTVDZwdU1DTnBHYW8xZlp5WDRvT243aWpsZCtKYWVNRzVBbmJHb05HUzJE?=
 =?utf-8?B?OEFGVzVqdi93RTdnUjZFb05nNmZGRzdqYnhxNmJyN0JzbEdtVW8xb1Z3NnZJ?=
 =?utf-8?B?enNxUVh6cEhZdlRHTkM1UlFQVkVUbVBKa0Erc0p5N01ENzVOM084QzRiODlB?=
 =?utf-8?B?Sk1HZkRhd0FZUlFQZ1hxTWdQWkhGdGhGdjkrYThNN01zbllqNjRrWkpDa0g4?=
 =?utf-8?B?QWx4YVI1S3ZxTmhyL1hvUnY5cmpNT1JMWWVGN1I0QkFYaVZNSDFVQ2RSc21i?=
 =?utf-8?B?M2FKMW54eVhQM2RDVjhCSkRHczFKd1ZMVlVCYVhPWnFjd0tPZEhGNC96b1hL?=
 =?utf-8?B?L2RmQU13SWkzY0IzbmRIT2lleTJVcVo3TXhNYUJ4dWZ2WFVHc2FRbFVvcXhV?=
 =?utf-8?B?ZU1tZElhbThFMC92QTc2cEtuRGVjRVk4TVFxRDBiU3ZGbktKdXRxUlJoa1M5?=
 =?utf-8?B?WTBweit5eEp4MFh5SWloeTd5Ry9mbVBGMUNmZW0yRU1nZFlpK0lmOTJha0tN?=
 =?utf-8?B?UFRhZ1Ftb1p5Qmg2WU5jMWRuLzREOHc3KzBUS0FPOHZBbmNaM2E4M25CbEdu?=
 =?utf-8?B?NmtNSHcvMGlvN1ZrTmg2OStYNkcva3B4Yng3SGlpSnJBMTdtNkJlWDRGS3lT?=
 =?utf-8?B?R1JxV1FVS2RQQzVnWXVUUmRoSzJFY1B1d1RYYTg3R2JEbjN0eEFwVWNoa0po?=
 =?utf-8?B?N3NEVml0cnVPam9DdXY1SktzVlI3ZU1UTjVhU2dLRlppSmdHQTNXYnAzN2dm?=
 =?utf-8?B?SFluU1dlWW5jRHN4bkt3OTZwQnNmUTBrbmhtS2Z3UlJvVTdNY1VXNVdvR0Mv?=
 =?utf-8?B?ZEszS2F2bERDcFptL2pxdzV0WCtuSjZjQWEzM01LN1ZNdDZPYUViUHdtKzJS?=
 =?utf-8?B?dHVUeFg3ZjNuUHNHQnpYMTFnQjRCT29VUWJMQnV2OEpaVk1JTERpd1JibzJw?=
 =?utf-8?Q?dFNqjw?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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 Sep 2025 00:33:03.7600
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cd14128b-0d9f-4ce6-2d6c-08ddf0cac532
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF0000231A.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9348

On 9/10/2025 4:47 PM, Andrew Cooper wrote:
> @@ -5,6 +5,7 @@
>   #include 
>   int sysctl_cov_op(struct xen_sysctl_coverage_op *op);
>   #else
> +#include 
>   static inline int sysctl_cov_op(void *unused)
>   {
>       return -EOPNOTSUPP;
> ... this is starting to get overly busy to read and could do with some
> extra lines around the primary #ifdef CONFIG_COVERAGE / #else / #endif.
>
> Happy to fix up on commit.
OK, its fine by me.


Victor


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 01:35:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 01:35:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119024.1464572 (Exim 4.92)
	(envelope-from )
	id 1uwWDQ-0002DN-Ci; Thu, 11 Sep 2025 01:35:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119024.1464572; Thu, 11 Sep 2025 01: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 1uwWDQ-0002DD-9h; Thu, 11 Sep 2025 01:35:12 +0000
Received: by outflank-mailman (input) for mailman id 1119024;
 Thu, 11 Sep 2025 01:35: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 1uwWDO-0002D7-Vw
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 01:35:11 +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 8c4ff036-8eaf-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 03:35:08 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 8243944536;
 Thu, 11 Sep 2025 01:35:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A2B1C4CEEB;
 Thu, 11 Sep 2025 01:35: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: 8c4ff036-8eaf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757554506;
	bh=VI73ZDavTs0yzta9dYUCfAHn/Ey37VuffTIjoiibROs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NfqBkS36A0t1GKGmz+OXXpC8J7muPx8TDjiEas5hNYsvuwuvaEyoM5MtSIn2RDd/F
	 zL0L0q5SlYM1EKulOGrVOMwitn4e/b8nO+Rq/Np48YUPispAuAmujmuy2ABrqgvnYQ
	 5HxowHlHKcbHrWhD74TXsUi0ylruU+jGA7rGSpgTVSPDWacUraQdGdFYZPSkCqt5OT
	 i4xPdlphUL7AQONHW6kynG+ikPwvIQgnd5SG1GiEL4iPUp03oF+bT+JSPVzsjERAFe
	 h9Bi98GTctXQrJZBTpGODUIPA+gJ3teRI56/vTYVghIiIHyZ7xchbTKJ5ewlMlIEBm
	 foG1qdX2u4PPw==
Date: Wed, 10 Sep 2025 18:34:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, xen-devel@dornerworks.com, 
    ray.huang@amd.com, Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    Nathan Studer , 
    Stewart Hildebrand , Dario Faggioli , 
    Juergen Gross , George Dunlap , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 02/26] xen/sysctl: replace CONFIG_SYSCTL with
 CONFIG_MGMT_DOMCTL
In-Reply-To: <20250910073827.3622177-3-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-3-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Rename all the CONFIG_SYSCTL into a single CONFIG_MGMT_HYPERCALLS to help
> provide a single option to manage all unnecessary hypercalls, including
> sysctl, domctl, etc, in dom0less system and PV shim mode, which could also
> make it easier to support randconfigs.
> 
> Suggested-by: Stefano Stabellini 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 01:37:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 01:37:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119042.1464583 (Exim 4.92)
	(envelope-from )
	id 1uwWFl-0002qd-Pk; Thu, 11 Sep 2025 01:37:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119042.1464583; Thu, 11 Sep 2025 01:37: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 1uwWFl-0002qW-Lt; Thu, 11 Sep 2025 01:37:37 +0000
Received: by outflank-mailman (input) for mailman id 1119042;
 Thu, 11 Sep 2025 01:37: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 1uwWFk-0002qQ-3H
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 01:37:36 +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 e33971d0-8eaf-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 03:37: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 593A76013D;
 Thu, 11 Sep 2025 01:37:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F60CC4CEEB;
 Thu, 11 Sep 2025 01:37: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: e33971d0-8eaf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757554652;
	bh=NIg4dDartnnQtRfoVis2/qgqG45a5Bt301WJY1oyCO8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=rksC6szsQ1SBS9L5fAbQ7iTpb20AKZAZfHK0UWC7u4Pi6oS67ImI9I70FQUsNCpsV
	 QCVtc29Jnw5aGcpWPWN9tYut7KSdnhG4AIQoC1c0O1kxIqu/2NwjNNpqKuqgYW0Quj
	 FWh/1ZX5L/V3rHaWuH+2gCGfYRJ3QC91LWmzCgBy/nXbi3/MHUuy1dyksNw1FnmzMR
	 1aKXRpmgyFiI2VzFdHlrzVafd+jz4UtOJJA/oicKM5eme39QWHPO7zQ+5Hc46CCnck
	 zY/LNLJxtdpQBW/e4dilEKJaPArXDjXOBoWmfReXmxECi+xbZcx3fUhm829ETFAUtj
	 z59hECbj4hJjQ==
Date: Wed, 10 Sep 2025 18:37:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Penny Zheng , ray.huang@amd.com, 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 06/26] xen/xsm: wrap xsm_vm_event_control() with
 CONFIG_VM_EVENT
In-Reply-To: <7ddbde88-a0d8-4c9f-a3d3-c7331bbecd3a@suse.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-7-Penny.Zheng@amd.com> <7ddbde88-a0d8-4c9f-a3d3-c7331bbecd3a@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, 10 Sep 2025, Jan Beulich wrote:
> On 10.09.2025 09:38, Penny Zheng wrote:
> > Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
> > it shall be wrapped with it
> 
> Isn't this addressing a Misra violation then? Whether it's "unreachable code"
> or "dead code" I can't really tell; I don't think I have properly understood
> when it is which of the two. (Change looks okay to me, apart from this aspect
> of describing it.)

It would be "unreachable code". So yes, this patch helps address Rule
2.1.


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:08:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:08:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119077.1464592 (Exim 4.92)
	(envelope-from )
	id 1uwWjm-0007K6-TW; Thu, 11 Sep 2025 02:08:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119077.1464592; Thu, 11 Sep 2025 02:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwWjm-0007Jz-R0; Thu, 11 Sep 2025 02:08:38 +0000
Received: by outflank-mailman (input) for mailman id 1119077;
 Thu, 11 Sep 2025 02:08:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwWjl-0007Jt-U1
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:08:37 +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 387693c2-8eb4-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 04:08: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 29D7D6013D;
 Thu, 11 Sep 2025 02:08:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40E30C4CEEB;
 Thu, 11 Sep 2025 02:08: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: 387693c2-8eb4-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757556512;
	bh=FutJm2e+CDFR9L+V04eCu1tWkGjnTq25lBH6bQUg4xo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mhhL0hIrb7mC/+jRo+vboeQ7aS5fOInwBft0ndbJQXUH+SKB939NfBt2w9BfyN3u5
	 HYPLGxxD/0HwpT9ZP5vzI0SiFmFSsjGOl6UofWwjz2IRUDlDI26uplcIrTzd07ZQPl
	 /dc5PtlvbvBgIlg6lRziJfpWKYkDfpcSJQT1r/pSE9QttrpINMOBUxzin3d8n957Cy
	 W+Dipe8iYxJh3GoIEkQMPaTbqDhL6x7BCzhAYOrTOGepkF+/Sf8OZjzDjSWCJC0hBy
	 NU0JWJG3B40fSe3PkxLjZxifeNM9ewYq77ZVf3txE7hGkAFIfAQsO9bj9ZRhzKTX5i
	 dHSbYOstTVX3g==
Date: Wed, 10 Sep 2025 19:08:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 06/26] xen/xsm: wrap xsm_vm_event_control() with
 CONFIG_VM_EVENT
In-Reply-To: <20250910073827.3622177-7-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-7-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
> it shall be wrapped with it
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:18:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:18:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119088.1464603 (Exim 4.92)
	(envelope-from )
	id 1uwWtM-0000eo-QI; Thu, 11 Sep 2025 02:18:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119088.1464603; Thu, 11 Sep 2025 02: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 1uwWtM-0000eh-NQ; Thu, 11 Sep 2025 02:18:32 +0000
Received: by outflank-mailman (input) for mailman id 1119088;
 Thu, 11 Sep 2025 02:18: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 1uwWtL-0000eb-A6
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:18:31 +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 9a3a23da-8eb5-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 04:18: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 B64FF6013D;
 Thu, 11 Sep 2025 02:18:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BCACC4CEEB;
 Thu, 11 Sep 2025 02:18: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: 9a3a23da-8eb5-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757557106;
	bh=DhOeGsdl69RyahR+iYjVB2KU6W40Xqzqd3W+B4l5g6o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JpU+N5ObB+dsfRDN5oaVdQqcGpQQwYPtP48I2kWEUYNgiT9oetRALkadLOwi3AeBf
	 Ay8rilsuI8zUWdradaviwVedTGQCXxHPV4aXiJZaKZA4+494/5gCnCl5PWW63mNWTQ
	 FN33jlyes7mIys1omugcuF84gEDL56mlyXVB/2sAfr6Gbq103Ialrkzejuvy/D4fxE
	 QMo2Nyd96JKab2RVaZ2KSkH4pxHyWB4FF8lGBGtJ5O7VPfrqm7REPkk1baATwVuzSy
	 wsuJRhiYZZxysw7IkargbVXTW+qXTocqTyvgpoYN6Y6nn06NuzWucOGAwJWlGRC9Zh
	 LiwLcC2VgbqoA==
Date: Wed, 10 Sep 2025 19:18:22 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stefano Stabellini 
cc: Penny Zheng , xen-devel@lists.xenproject.org, 
    xen-devel@dornerworks.com, ray.huang@amd.com, 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    Nathan Studer , 
    Stewart Hildebrand , Dario Faggioli , 
    Juergen Gross , George Dunlap , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 02/26] xen/sysctl: replace CONFIG_SYSCTL with
 CONFIG_MGMT_DOMCTL
In-Reply-To: 
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-3-Penny.Zheng@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, 10 Sep 2025, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
> > Rename all the CONFIG_SYSCTL into a single CONFIG_MGMT_HYPERCALLS to help
> > provide a single option to manage all unnecessary hypercalls, including
> > sysctl, domctl, etc, in dom0less system and PV shim mode, which could also
> > make it easier to support randconfigs.
> > 
> > Suggested-by: Stefano Stabellini 
> > Signed-off-by: Penny Zheng 
> 
> Reviewed-by: Stefano Stabellini 

With one comment:

> -config SYSCTL
> -	bool "Enable sysctl hypercall"
> +config MGMT_HYPERCALLS
> +	bool "Enable hypercalls under management"

Please call it "Enable privileged hypercalls for system management"


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:28:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:28:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119099.1464612 (Exim 4.92)
	(envelope-from )
	id 1uwX2V-0002PB-Js; Thu, 11 Sep 2025 02:27:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119099.1464612; Thu, 11 Sep 2025 02:27: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 1uwX2V-0002P4-HG; Thu, 11 Sep 2025 02:27:59 +0000
Received: by outflank-mailman (input) for mailman id 1119099;
 Thu, 11 Sep 2025 02:27:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwX2T-0002Oy-NV
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:27: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 ec46650c-8eb6-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:27: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 53702601AB;
 Thu, 11 Sep 2025 02:27:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B48FEC4CEEB;
 Thu, 11 Sep 2025 02:27: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: ec46650c-8eb6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757557674;
	bh=AzRleKA5hFtB+5s/7DOclRULhkto/ekJs8r5r4I4s4g=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=QgyQ007qkVXfhp3x0HvoYWJNdEF5soVrzG6CrHNFv5TliAw9rX95/CJZMYyfBFi4B
	 N9kuIFIP1GmA20vFDuPtKf6nTOcf0OB+EFUF6BGwdcXMXv1pJiGhDal50UfFMFPXvr
	 Qsz+Rl/wqA5vsUvFsjrAgKV/fXlsOVpHhew6BlPdp0pzIq451UhYlKcqxhTW8sm1dX
	 DJNuMKoWpoucfLTq074AnSoIDms3/Pr7509CV1S3d9AH0hT9ddW4OKlR5fdHAvb2aE
	 YpGEgi/x1fNRC5jVw6/zFD2mOjaV0HJwZJWdb5Fh9FRAPxL8IMnF6PnL7q3wgPc2iL
	 ibg0G2YCC7lww==
Date: Wed, 10 Sep 2025 19:27:51 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH v2 09/26] xen/domctl: wrap domain_resume() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-10-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-10-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> One usage of function domain_resume() is in domain resume domctl-op, and
> the other is in domain_soft_reset(), which is already guarded with
> CONFIG_MGMT_HYPERCALLS.
> So we could wrap domain_soft_reset() with CONFIG_MGMT_HYPERCALLS.
> 
> Wrap XEN_DOMCTL_resumedomain-case transiently with CONFIG_MGMT_HYPERCALLS, and
> it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:29:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:29:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119110.1464624 (Exim 4.92)
	(envelope-from )
	id 1uwX45-0002ut-01; Thu, 11 Sep 2025 02:29:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119110.1464624; Thu, 11 Sep 2025 02:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwX44-0002um-SC; Thu, 11 Sep 2025 02:29:36 +0000
Received: by outflank-mailman (input) for mailman id 1119110;
 Thu, 11 Sep 2025 02:29: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 1uwX43-0002uc-AK
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:29:35 +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 268accc4-8eb7-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:29: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 6788C6013D;
 Thu, 11 Sep 2025 02:29:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D1E4C4CEEB;
 Thu, 11 Sep 2025 02:29: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: 268accc4-8eb7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757557772;
	bh=ps6VYtCKung9s6vYdHewRXmxP4ek7Iv6t9sxH4jBa7M=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Gzcd8j18ZzUDiHOK2ogFvH3ZrPCkGHqVhk4XCHpqCvLu5cqt9zcbAFMJGK3t5Yvcv
	 ATOP/85dYNuv3qIJdrZTWAFy458UQh5PpS02o8dBVcZn6VPjIneyxPBO1XsNp7D+dn
	 1M0AIHJvg70jqus7rZ88R5Le0RDoWe2GptK7ylPCuzWyRZwEXiutoVLesuCxLcpZDa
	 IO+OJSXMDLumCfSPyjkIyncH4Xz5TBZsbQX1deipRRpv/W5dT0AyJ/XVIBhwYPgnJg
	 HlHPMBaQmkeiVyxdVguSNrsSrHEo9wctLjldErYafgu0HZEhb0eMjzFiW+5dZ5LcXp
	 qYcnStLZzG51Q==
Date: Wed, 10 Sep 2025 19:29:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Tamas K Lengyel 
Subject: Re: [PATCH v2 10/26] xen/domctl: wrap domain_kill() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-11-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-11-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Function domain_kill() is responsible for killing domain and relinquish
> domain-held resources. and it is only invoked under
> XEN_DOMCTL_destroydomain-case. So it shall be wrapped with
> CONFIG_MGMT_HYPERCALLS.
> Tracking its calling chain, the following functions could also be wrapped with
> CONFIG_MGMT_HYPERCALLS:
> - domain_relinquish_resource
>   - pci_release_device
>   - relinquish_shared_pages
>   - paging_teardown
>     - p2m_pod_empty_cache
>   - relinquish_memory
>   - pit_deinit
>   - iommu_release_dt_devices
>   - tee_relinquish_resources
>     - ffa_relinquish_resources/optee_relinquish_resources
>   - relinquish_p2m_mapping
>   - p2m_clear_root_pages
> Wrap XEN_DOMCTL_destroydomain-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

There are RISC-V and PPC functions we could #ifdef out, although they are
only stubs. Given that:

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:29:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:29:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119112.1464633 (Exim 4.92)
	(envelope-from )
	id 1uwX4J-0003Ji-C0; Thu, 11 Sep 2025 02:29:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119112.1464633; Thu, 11 Sep 2025 02: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 1uwX4J-0003JQ-7q; Thu, 11 Sep 2025 02:29:51 +0000
Received: by outflank-mailman (input) for mailman id 1119112;
 Thu, 11 Sep 2025 02:29:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwX4I-0002uc-7r
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:29:50 +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 2f785973-8eb7-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:29:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id E584E44A83;
 Thu, 11 Sep 2025 02:29:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86021C4CEEB;
 Thu, 11 Sep 2025 02:29: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: 2f785973-8eb7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757557786;
	bh=bh5xWp9+jIQ/i/yL7/mFQRgmtOWyuT3Y3rSxCUgpVvY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mgDOKPeMYwilzXKC5jw+gMqPHihclgg2pB6Scy6ZW8zm5pC1Rm4ESfkHYBZfpfrXR
	 aOlNibj3hSCcshRLZjE1mcYyF8YL5O885w5nZp0P9N6mXkIIhSor9X7E6hWT24umOF
	 exszK0h3OBIK2IfK514uSFJHtDtGJuQ+mk5TS+2Bbc8S67S7rI40C9wwkwoZVsQs+p
	 xZw8onqCgZJqrNfPcETHtv3cMIYXHuSnVqTVzms/+yhaDJ4v94xlQHDWMGNHxV5WcG
	 oXrs3L4xfwElVG5AtipcMRIQEZKlx+8+0tajwUPQP/d2H8Ph3yE9OVvIyyX9ihw7Mu
	 XhTlPST5Qtcgw==
Date: Wed, 10 Sep 2025 19:29:44 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH v2 11/26] xen/domctl: wrap domain_set_node_affinity()
 with CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-12-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-12-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Function domain_set_node_affinity() is responsible for
> XEN_DOMCTL_setnodeaffinity domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_setnodeaffinity-case and xenctl_bitmap_to_nodemask()
> transiently with CONFIG_MGMT_HYPERCALLS, and it will be removed when
> introducing CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:30:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:30:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119134.1464643 (Exim 4.92)
	(envelope-from )
	id 1uwX4k-0004sg-Hn; Thu, 11 Sep 2025 02:30:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119134.1464643; Thu, 11 Sep 2025 02: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 1uwX4k-0004sZ-Ef; Thu, 11 Sep 2025 02:30:18 +0000
Received: by outflank-mailman (input) for mailman id 1119134;
 Thu, 11 Sep 2025 02:30: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 1uwX4j-0002uc-Bp
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:30:17 +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 3f8bc46b-8eb7-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:30:15 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 56BA5437BD;
 Thu, 11 Sep 2025 02:30:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED048C4CEEB;
 Thu, 11 Sep 2025 02:30: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: 3f8bc46b-8eb7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757557814;
	bh=Y04GJDVEX9t/myPrNQQRkZrf35AmYZ8p6chm2d9AThc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=paiEP6q6MjdtbCml9YpNMj4UmVNNVBSlzwf39mp+Bi9PRIGc6JM0ZuPl7zTnyRNzM
	 KtQFWnfo71O9sroM4E8tQjVoUDsqZviNbW013EaLAHVD9a+W48g+fLWN6gcGTbhzO4
	 bTtL8SBxpUfNGOjOwAAMK0EVrLIvvyiH+HBkTZaHJB6qZd4EGqvNo6Ek7h7LCkw1WE
	 4XyzvNpslVxl44HDmD3oPeXTbLR0AJ6jDuiRABxnstpyF7Z3tzJ9shodByOwCZZdYh
	 QECpKQ1gRMY/6vB/lWAWHTXfb/qSdM2PoCv4O2h1k92aCOb905EAv/ZmJ7dTZLmw24
	 FRg8zuUhSGzNw==
Date: Wed, 10 Sep 2025 19:30:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, xen-devel@dornerworks.com, 
    ray.huang@amd.com, Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Nathan Studer , 
    Stewart Hildebrand , Dario Faggioli , 
    Juergen Gross , George Dunlap , 
    Meng Xu , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 13/26] xen/domctl: wrap sched_adjust() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-14-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-14-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Function sched_adjust() is responsible for XEN_DOMCTL_scheduler_op domctl-op,
> so it could be wrapped with CONFIG_MGMT_HYPERCALLS.
> Tracing its calling chain, the following functions shall be wrapped with
> CONFIG_MGMT_HYPERCALLS too:
> - sched_adjust_dom()
> - scheduler-specific .adjust() callback
> - xsm_sysctl_scheduler_op()
> Wrap XEN_DOMCTL_scheduler_op-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:34:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:34:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119148.1464653 (Exim 4.92)
	(envelope-from )
	id 1uwX8W-0005Wo-VX; Thu, 11 Sep 2025 02:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119148.1464653; Thu, 11 Sep 2025 02:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwX8W-0005Wh-T3; Thu, 11 Sep 2025 02:34:12 +0000
Received: by outflank-mailman (input) for mailman id 1119148;
 Thu, 11 Sep 2025 02:34: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 1uwX8V-0005WY-6t
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:34:11 +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 caf0febb-8eb7-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:34:09 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id BBD3B6013D;
 Thu, 11 Sep 2025 02:34:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6A04C4CEEB;
 Thu, 11 Sep 2025 02: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: caf0febb-8eb7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757558047;
	bh=G8ibN61BRsROOmQoOnw6M9us1ny3T8uTx3GCsJ3GOXs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=gSDc/8EllrrT1VYdp/Yw9mWuEZxp7oqLWV38WLgGs0LAva3oYQMpIWympQfClSf0H
	 a33fi8VH4zLqgJIyYMcjNjVVjbOHfgMPqHefYh2KZx4FfCLo7IU46gOv2qDbrb3j2i
	 9yVkoQXNlt3GExAqphiqyQjKFESwemIzx/kIY5/gDkpAwPNhyaMOH/G3CFiKLrnXYr
	 k4WaQm6PGuNlCVDzEIFb3v7cJC3pWKTvSRXjZvw60dNxq68in7wRAkt6Om2NxOzGTD
	 QdDh34Hk2Wlh8u7qsZULx+WrTPM4hQBug/874nNfkNsOZkHbRoGUR7Vu3sNG1/t2NQ
	 awdyuROGw3bGQ==
Date: Wed, 10 Sep 2025 19:34:05 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 15/26] xen/domctl: wrap xsm_{irq_permission,iomem_permission}
 with CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-16-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-16-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> The following functions are invoked only under
> XEN_DOMCTL_{irq_permission,iomem_permission} domctl-op, and shall be wrapped
> with CONFIG_MGMT_HYPERCALLS:
> - xsm_irq_permission
> - xsm_iomem_permission
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
> ---
>  xen/include/xsm/xsm.h | 10 ++++++++++
>  xen/xsm/dummy.c       |  2 ++
>  xen/xsm/flask/hooks.c |  4 ++++
>  3 files changed, 16 insertions(+)

there is no change to domctl.c ?


> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 4d332ceca2..1fcd945336 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -113,9 +113,11 @@ struct xsm_ops {
>      int (*unmap_domain_irq)(struct domain *d, int irq, const void *data);
>      int (*bind_pt_irq)(struct domain *d, struct xen_domctl_bind_pt_irq *bind);
>      int (*unbind_pt_irq)(struct domain *d, struct xen_domctl_bind_pt_irq *bind);
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      int (*irq_permission)(struct domain *d, int pirq, uint8_t allow);
>      int (*iomem_permission)(struct domain *d, uint64_t s, uint64_t e,
>                              uint8_t allow);
> +#endif
>      int (*iomem_mapping)(struct domain *d, uint64_t s, uint64_t e,
>                           uint8_t allow);
>      int (*pci_config_permission)(struct domain *d, uint32_t machine_bdf,
> @@ -508,13 +510,21 @@ static inline int xsm_unbind_pt_irq(
>  static inline int xsm_irq_permission(
>      xsm_default_t def, struct domain *d, int pirq, uint8_t allow)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      return alternative_call(xsm_ops.irq_permission, d, pirq, allow);
> +#else
> +    return -EOPNOTSUPP;
> +#endif
>  }
>  
>  static inline int xsm_iomem_permission(
>      xsm_default_t def, struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      return alternative_call(xsm_ops.iomem_permission, d, s, e, allow);
> +#else
> +    return -EOPNOTSUPP;
> +#endif
>  }
>  
>  static inline int xsm_iomem_mapping(
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 2c878999a3..b216894579 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -73,8 +73,10 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
>      .unmap_domain_irq              = xsm_unmap_domain_irq,
>      .bind_pt_irq                   = xsm_bind_pt_irq,
>      .unbind_pt_irq                 = xsm_unbind_pt_irq,
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      .irq_permission                = xsm_irq_permission,
>      .iomem_permission              = xsm_iomem_permission,
> +#endif
>      .iomem_mapping                 = xsm_iomem_mapping,
>      .pci_config_permission         = xsm_pci_config_permission,
>      .get_vnumainfo                 = xsm_get_vnumainfo,
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index e8a4deb2ea..198053be77 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1111,12 +1111,14 @@ static int cf_check flask_unbind_pt_irq(
>      return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  static int cf_check flask_irq_permission(
>      struct domain *d, int pirq, uint8_t access)
>  {
>      /* the PIRQ number is not useful; real IRQ is checked during mapping */
>      return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  struct iomem_has_perm_data {
>      uint32_t ssid;
> @@ -1943,8 +1945,10 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>      .unmap_domain_irq = flask_unmap_domain_irq,
>      .bind_pt_irq = flask_bind_pt_irq,
>      .unbind_pt_irq = flask_unbind_pt_irq,
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      .irq_permission = flask_irq_permission,
>      .iomem_permission = flask_iomem_permission,
> +#endif
>      .iomem_mapping = flask_iomem_mapping,
>      .pci_config_permission = flask_pci_config_permission,
>  
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:36:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:36:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119160.1464664 (Exim 4.92)
	(envelope-from )
	id 1uwXAK-00064G-B7; Thu, 11 Sep 2025 02:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119160.1464664; Thu, 11 Sep 2025 02:36: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 1uwXAK-000649-7F; Thu, 11 Sep 2025 02:36:04 +0000
Received: by outflank-mailman (input) for mailman id 1119160;
 Thu, 11 Sep 2025 02: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 1uwX5Z-0003C3-TP
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:31:09 +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 5fbe020e-8eb7-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 04:31:09 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 342C66013D;
 Thu, 11 Sep 2025 02:31:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CE72C4CEEB;
 Thu, 11 Sep 2025 02:31: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: 5fbe020e-8eb7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757557867;
	bh=Nj/LW/DfXNbuVc7MsPOMUvZXGaRsDG4TO9H4+pNT9gU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=qv2OXv7Vt07Mwbp2UcXyzGaw8SxQ3kPK40kZAsrzt8N6kWvYHsv1dFAZHbWd/7tft
	 MiQYEFQWMegRKOarO3vFGB96YCbbLykyfjSgb/CobHQE7NBXh4kIbLs5c5A2dxK7tQ
	 UYi3fL0JKxRLyM30RX011GpJO047rUqyCNT4XD88IY7xYoDSW47ieN/NEBUMX4jp2z
	 gAEGGE5o168O7XDaHL+R9Z0f5+JazudwIqP4Jc+6IuAV5o+rqtKfH0RwJGV39Nu4jV
	 GeVimFYLiJg9WHNHFghYfgtcYiSTUJpowlKVp2GgAJevBzVsC6javIpuG0wfC/T2s+
	 D9Z/ta38zqgHQ==
Date: Wed, 10 Sep 2025 19:31:04 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    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 v2 14/26] xen/domctl: wrap arch-specific arch_get_info_guest()
 with CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-15-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-15-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Arch-specific function arch_get_info_guest() is responsible for
> XEN_DOMCTL_getvcpucontext domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_getvcpucontext-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

There is arch_get_info_guest under riscv but it is only a stub so:

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:36:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:36:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119167.1464673 (Exim 4.92)
	(envelope-from )
	id 1uwXAq-0006oI-Ho; Thu, 11 Sep 2025 02:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119167.1464673; Thu, 11 Sep 2025 02: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 1uwXAq-0006oB-F7; Thu, 11 Sep 2025 02:36:36 +0000
Received: by outflank-mailman (input) for mailman id 1119167;
 Thu, 11 Sep 2025 02: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 1uwXAo-0006np-LJ
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:36:34 +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 204f5337-8eb8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:36:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 0584D44667;
 Thu, 11 Sep 2025 02:36:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54BF1C4CEEB;
 Thu, 11 Sep 2025 02:36: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: 204f5337-8eb8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757558190;
	bh=3KH0HxVPhc7NG59TgII8DWZH0dSP9zBMOLrOVbY085o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=WkmwLD6EaOTPjK2fYoiKLs0nrI8kkjQGU2p/nrZtcKNyu1sjvYYfB986xmF9u7jwx
	 qP2syrAOUa6OJ75+ZG9mF8inBW5nUPLy8HO6v69Qz7rT8q1aEY1e8I/eM3sbnFQmIi
	 T6Fg6ZiuCoRHPGTEgC6OrMojmP/rn49YkOecSDlrsERDxtRPZuko/b6tCIANpW/Ywc
	 S97hpInqJ1l7nagQc6tFmMpngwTkQSmMXdTLRJGqeL6pZ9iT2nSrVRSBT/oJ6Lgzcs
	 KYUSRImUa0/JHkhU2vmwmStB6CFe5EH3xnSSAPKtCQJ/o/B1uIDyQvQPOknfKWXLKQ
	 UiPh+penE/wSA==
Date: Wed, 10 Sep 2025 19:36:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    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 v2 16/26] xen/domctl: wrap arch-specific domain_set_time_offset()
 with CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-17-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-17-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Arch-specific domain_set_time_offset() is responisble for
> XEN_DOMCTL_settimeoffset domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_settimeoffset-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

riscv has only a stub so:

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:37:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:37:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119181.1464683 (Exim 4.92)
	(envelope-from )
	id 1uwXBZ-0007NU-RQ; Thu, 11 Sep 2025 02:37:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119181.1464683; Thu, 11 Sep 2025 02: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 1uwXBZ-0007NN-Nu; Thu, 11 Sep 2025 02:37:21 +0000
Received: by outflank-mailman (input) for mailman id 1119181;
 Thu, 11 Sep 2025 02:37: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 1uwXBY-0007N0-Po
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:37:20 +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 3b85c426-8eb8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 04:37:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 1C36E43902;
 Thu, 11 Sep 2025 02:37:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CA92C4CEEB;
 Thu, 11 Sep 2025 02:37: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: 3b85c426-8eb8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757558237;
	bh=WThbnJgbo3znvlWkt4R9hHIR3Wl4SZolIIO9gH+Uayo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hnJYHJGdXA7MyfwLGnFP8sm6PJ6tIP6c63RsTEdT0QmMg6XVbAzfR4dPG9EYQbYVu
	 8uM9U+MZCLZ+Mm/jDiOjZ+a6cNLRxmgTvMIC19LE4oBIjvL5aZp0thUHYeF0sUFkWc
	 0IhewvEhKZlRfziBRxsBFikisZtU0V0CK643ky9pD1mxK5tTP7YQME1snd/utZo3NN
	 RgjfOjHOAkBc/2b9Wg0+0npUpiMMSwQbryQ2DCdnlTzjNU3Qh7k6Du9uqlUNzTZv3L
	 79Z/bTpsUxgjoEPjzliN9vXnSb6ottsCIWTbFZVDyDRRWGyQcc9QrKFvBEQAyoAbsp
	 6UycwqilxFQ1w==
Date: Wed, 10 Sep 2025 19:37:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 17/26] xen/domctl: wrap xsm_set_target() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-18-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-18-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Function xsm_set_target() is only invoked under XEN_DOMCTL_set_target
> domctl-op, and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
> ---
>  xen/include/xsm/xsm.h | 6 +++++-
>  xen/xsm/dummy.c       | 2 +-
>  xen/xsm/flask/hooks.c | 4 ++--
>  3 files changed, 8 insertions(+), 4 deletions(-)

No change to domctl.c ?


> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 1fcd945336..678cb0f346 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -59,8 +59,8 @@ struct xsm_ops {
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      int (*domctl_scheduler_op)(struct domain *d, int op);
>      int (*sysctl_scheduler_op)(int op);
> -#endif
>      int (*set_target)(struct domain *d, struct domain *e);
> +#endif
>      int (*domctl)(struct domain *d, unsigned int cmd, uint32_t ssidref);
>      int (*sysctl)(int cmd);
>      int (*readconsole)(uint32_t clear);
> @@ -258,7 +258,11 @@ static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
>  static inline int xsm_set_target(
>      xsm_default_t def, struct domain *d, struct domain *e)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      return alternative_call(xsm_ops.set_target, d, e);
> +#else
> +    return -EOPNOTSUPP;
> +#endif
>  }
>  
>  static inline int xsm_domctl(xsm_default_t def, struct domain *d,
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index b216894579..f6986dd2bb 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -21,8 +21,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      .domctl_scheduler_op           = xsm_domctl_scheduler_op,
>      .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
> -#endif
>      .set_target                    = xsm_set_target,
> +#endif
>      .domctl                        = xsm_domctl,
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      .sysctl                        = xsm_sysctl,
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 198053be77..ed4e466302 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -641,7 +641,6 @@ static int cf_check flask_sysctl_scheduler_op(int op)
>          return avc_unknown_permission("sysctl_scheduler_op", op);
>      }
>  }
> -#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  static int cf_check flask_set_target(struct domain *d, struct domain *t)
>  {
> @@ -666,6 +665,7 @@ static int cf_check flask_set_target(struct domain *d, struct domain *t)
>                                   &dsec->target_sid);
>      return rc;
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
>                                   uint32_t ssidref)
> @@ -1893,8 +1893,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      .domctl_scheduler_op = flask_domctl_scheduler_op,
>      .sysctl_scheduler_op = flask_sysctl_scheduler_op,
> -#endif
>      .set_target = flask_set_target,
> +#endif
>      .domctl = flask_domctl,
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      .sysctl = flask_sysctl,
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 02:41:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 02:41:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119194.1464694 (Exim 4.92)
	(envelope-from )
	id 1uwXF9-0000UK-BI; Thu, 11 Sep 2025 02:41:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119194.1464694; Thu, 11 Sep 2025 02: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 1uwXF9-0000UD-6h; Thu, 11 Sep 2025 02:41:03 +0000
Received: by outflank-mailman (input) for mailman id 1119194;
 Thu, 11 Sep 2025 02:41: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 1uwXF7-0000U7-UP
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 02:41: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 bf93404b-8eb8-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 04:41: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 75EF143D27;
 Thu, 11 Sep 2025 02:40:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 024D5C4CEEB;
 Thu, 11 Sep 2025 02:40: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: bf93404b-8eb8-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757558458;
	bh=gp7DVx+O61bT7TGkqRLjVfPd/Iv53dEhT1p5X1jLCow=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Zdq288wsj3U2FaK6b+HufkUW+XnHYJfQNuFIKe3CRbOLoaWK/+KDY2Jq5xfuQHf5s
	 ss/XFGf37dg/xnyfoOG0kaX6Cn3UCcBGeTzIKv808oSDJo2RhYVTN4L2A+OngdzKAp
	 jmiVNoE9A6BkI/a7KcwdZr0hMyrP3X11Kv8TpVOKCRmjh8b5Vitdh0fpJdDUfEUl06
	 R8WPSwRcH4wfmfV8tBiZxg8qWSuIpsStarTG6+uoJ2Lia2wCma7YLVVwK/Y9bfhIwI
	 T8k32dZpWmX8NWHkaMSLxGbUjd1e9kkm94dKe84uiG+NK7Pj+k68n4OcQSDvcvAmEE
	 UcE7QvJ61GVYQ==
Date: Wed, 10 Sep 2025 19:40:55 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH v2 19/26] xen/domctl: wrap set_global_virq_handler() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-20-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-20-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Function set_global_virq_handler() is reponsible for
> XEN_DOMCTL_set_virq_handler domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS.
> Wrap XEN_DOMCTL_set_virq_handler-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
> - wrap XEN_DOMCTL_set_virq_handler-case transiently
> ---
>  xen/common/domctl.c        | 2 ++
>  xen/common/event_channel.c | 2 ++
>  2 files changed, 4 insertions(+)

There is a call to set_global_virq_handler in
xen/common/device-tree/dom0less-build.c

ld: prelink.o: in function `set_xs_domain':
/local/repos/xen-upstream/xen/common/device-tree/dom0less-build.c:45: undefined reference to `set_global_virq_handler'
/local/repos/xen-upstream/xen/common/device-tree/dom0less-build.c:45:(.init.text+0x2eb0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `set_global_virq_handler'
ld: ./.xen-syms.0: hidden symbol `set_global_virq_handler' isn't defined
ld: final link failed: bad value


> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 776bf7b8e2..736ad52265 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -808,9 +808,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>          break;
>  #endif
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      case XEN_DOMCTL_set_virq_handler:
>          ret = set_global_virq_handler(d, op->u.set_virq_handler.virq);
>          break;
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>      case XEN_DOMCTL_setvnumainfo:
>      {
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 67700b050a..bb53dc1fb0 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1006,6 +1006,7 @@ void send_global_virq(uint32_t virq)
>      send_guest_domain_virq(get_global_virq_handler(virq), virq);
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  int set_global_virq_handler(struct domain *d, uint32_t virq)
>  {
>      struct domain *old, *hdl;
> @@ -1068,6 +1069,7 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
>  
>      return rc;
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  static void clear_global_virq_handlers(struct domain *d)
>  {
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 03:12:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 03:12:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119209.1464703 (Exim 4.92)
	(envelope-from )
	id 1uwXja-0005K2-HX; Thu, 11 Sep 2025 03:12:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119209.1464703; Thu, 11 Sep 2025 03:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwXja-0005Jv-E5; Thu, 11 Sep 2025 03:12:30 +0000
Received: by outflank-mailman (input) for mailman id 1119209;
 Thu, 11 Sep 2025 03:12:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwXjZ-0005Jp-NE
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 03:12:29 +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 21feb5d7-8ebd-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 05:12:23 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 23BB2442B7;
 Thu, 11 Sep 2025 03:12:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C66CC4CEEB;
 Thu, 11 Sep 2025 03:12:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 21feb5d7-8ebd-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757560341;
	bh=G4n2aqrx8Vhln81QzvIPRQ5ETDRj1hAQAVSyMqRNW1c=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=rvGNSELuYmxGOxMekZACfk9RT50OCAFLn/41bQTGy+IcNloHgwE18W74+3h8cLHws
	 exCrLi4Ovf7mrRjXOzriRO4WE5MAU6FbOc+r+SB2UeaYiYnxGml7/8nSrDg8D0yLP+
	 MdIH8zeYaxTj0y6Am7brQhJrBe5abJURVSpyA7kMLfLhNIB3UCCmA0QjCEQoJRz0z4
	 /FjzDKDA/PArhyHv0YzL+o87nRoFe1WJP3qwBh+/C9QibVjm4zTYuA8ECD5nfKVW+J
	 WWXEk3/ZtngvOtYfhPRSpagfl5DkDm8RDMk9WniwV2O8OvajLd0DzNonE/4mpAZhKy
	 AMDojZNdnTJjw==
Date: Wed, 10 Sep 2025 20:12:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Rahul Singh 
Subject: Re: [PATCH v2 20/26] xen/domctl: wrap iommu-related domctl op with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-21-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-21-Penny.Zheng@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1924521499-1757560340=:52703"

  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-1924521499-1757560340=:52703
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 10 Sep 2025, Penny Zheng wrote:
> Function iommu_do_domctl() is the main entry for all iommu-related domctl-op,
> and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
> Tracking its calling chain, the following functions shall all be wrapped
> with CONFIG_MGMT_HYPERCALLS:
> - iommu_do_pci_domctl
>   - iommu_get_device_group
>     - amd_iommu_group_id/intel_iommu_group_id
>   - device_assigned
>   - assign_device
>     - intel_iommu_assign_device/amd_iommu_assign_device
>   - deassign_device
>     - reassign_device_ownership/reassign_device
> - iommu_do_dt_domctl
>   - iommu_deassign_dt_device
>     - arm_smmu_reassign_dev/arm_smmu_reassign_dev
>     - ipmmu_reassign_dev
>       - ipmmu_deassign_dev
>         - ipmmu_detach_dev
>   - dt_find_node_by_gpath
> Wrap XEN_DOMCTL_assign_device{test_assign_device,deassign_device,
> get_device_group}-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the whole
> domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

drivers/passthrough/arm/smmu.c:2852:12: error: ‘arm_smmu_deassign_dev’ defined but not used [-Werror=unused-function]
 2852 | static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
      |            ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

--8323329-1924521499-1757560340=:52703--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 03:18:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 03:18:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119229.1464712 (Exim 4.92)
	(envelope-from )
	id 1uwXpT-00069G-4e; Thu, 11 Sep 2025 03:18:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119229.1464712; Thu, 11 Sep 2025 03:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwXpT-000699-26; Thu, 11 Sep 2025 03:18:35 +0000
Received: by outflank-mailman (input) for mailman id 1119229;
 Thu, 11 Sep 2025 03:18:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwXpS-000693-4r
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 03:18:34 +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 fea94400-8ebd-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 05:18: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 2B322601AB;
 Thu, 11 Sep 2025 03:18:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00E4EC4CEEB;
 Thu, 11 Sep 2025 03:18: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: fea94400-8ebd-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757560710;
	bh=g3/p4H40JqcqTgjiwVQSePcgScvUvtEsjUEL8LdYBbM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=nke7/mHGlkUBBgIH+vTqQaqCQhAC44OKc3IN7MNZ5tT6hG/7x0daw2CqsrwzT0+6a
	 FJ4N/hFyNahBH0PGCwsdV8lH9Q018CFX2Uw0hwxCRx9HT/m7wNTEPuASotlpAC3Cr1
	 vT2yiSK8RFbQ0MrIY+NsIV7btZLrD+afiKQSi2uZfuGaTfR5JrTii3g3LkKvGLKzGO
	 H6bdVm8id5a8HtZl41F3rPAzVg4VNyvGoVfZhc1Jz8JbQ8TqdtdQ9qCn/657N/NS+Q
	 Y7KdIH1HjTfRrH6/r1wCOaOh4eZyGL1CLyJwgNa5ijy975At4kjd/1kqFIrzns2rPQ
	 pqwOx7pOgml6w==
Date: Wed, 10 Sep 2025 20:18:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    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 v2 22/26] xen/domctl: wrap arch_{get,set}_paging_mempool_size()
 with CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-23-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-23-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Arch-specific arch_{get,set}_paging_mempool_size() is responsible for
> XEN_DOMCTL_{get,set}_paging_mempool_size domctl-op, and shall be wrapped
> with CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_{get,set}_paging_mempool_size-case transiently with
> CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
> CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 03:22:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 03:22:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119250.1464723 (Exim 4.92)
	(envelope-from )
	id 1uwXsv-0007dt-Ih; Thu, 11 Sep 2025 03:22:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119250.1464723; Thu, 11 Sep 2025 03:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwXsv-0007dm-Fq; Thu, 11 Sep 2025 03:22:09 +0000
Received: by outflank-mailman (input) for mailman id 1119250;
 Thu, 11 Sep 2025 03:22:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwXsu-0007dg-0I
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 03:22:08 +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 7e1ed5d5-8ebe-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 05:22: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 30AA9449B7;
 Thu, 11 Sep 2025 03:22:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4299AC4CEEB;
 Thu, 11 Sep 2025 03:22: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: 7e1ed5d5-8ebe-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757560925;
	bh=AS4+H2KdwzbWkkB2NyQf4brFuTMePJpc+8hNCB86lgw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=SXXuIkVgUArpV7/mG0jQVHk7sIVbAEXs3GdQD3rLN4F0D/Yf61u3m3wXxswhP9u6f
	 Lgax6XmOtPnaWo992Lni3HzWJM43+gx3QdwsJSjU8Fkb8n7Wdmwo/JeF+ewHoWliRF
	 nb/UrmKFv6q6F06PkasIGFEITkR4iAOUn3t4HOD6nL2f17858S9zexcpTp5NlurA8a
	 jlaHO+4AgpDtwaNMY1+GdniskcB9By8pp0EqZZ+bRGcK8vqBc7+qa8Ub+EFDF9Lv/l
	 BK46x1WVV8rkHUVal/9GlF/x2UdylH3eTSsXduOY8r444rm1aVrc+olhKK6+St01Gv
	 2oQjXeIxrjWtg==
Date: Wed, 10 Sep 2025 20:22:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Jan Beulich , Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v2 23/26] xen/x86: make CONFIG_X86_PSR depend on
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <20250910073827.3622177-24-Penny.Zheng@amd.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-24-Penny.Zheng@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, 10 Sep 2025, Penny Zheng wrote:
> Users control/monitor Intel Platform Shared Resource (PSR) through
> related domctl-op or sysctl-op, so CONFIG_X86_PSR can be put under
> MGMT_HYPERCALLS. With this change, we could remove MGMT_HYPERCALLS-wrapping
> in psr.c
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 06:34:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 06:34:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119343.1464733 (Exim 4.92)
	(envelope-from )
	id 1uwatK-0005Jh-Nf; Thu, 11 Sep 2025 06:34:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119343.1464733; Thu, 11 Sep 2025 06: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 1uwatK-0005JZ-KC; Thu, 11 Sep 2025 06:34:46 +0000
Received: by outflank-mailman (input) for mailman id 1119343;
 Thu, 11 Sep 2025 06:34:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwatJ-0005JR-NW
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 06:34:45 +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 6675e229-8ed9-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 08:34:42 +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 5E2A8683E8;
 Thu, 11 Sep 2025 06:34: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 773761372E;
 Thu, 11 Sep 2025 06:34: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 KsszG31twmjuTAAAD6G6ig
 (envelope-from ); Thu, 11 Sep 2025 06:34: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: 6675e229-8ed9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572479; 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=Lfr1qPpuiB3AOwPU0ZFjKKYSXrWZllg4AtF3tp+3Wzs=;
	b=Rb52kiLtTg3v2u9zgMn3NUgzc+I9t7goexfTSG/6vAd6CFqdCGPPMNDDYCobdCdyrq5sS4
	THsDzUD4UF4y2fXBlIeYIVCPmZLL7CdaqepqR8WgmiYxUf4btn7G6HEQab08I1KrGeDcGm
	nmUC3Xv4HYwAo2tomf/WXQlFMXA6O8w=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572479; 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=Lfr1qPpuiB3AOwPU0ZFjKKYSXrWZllg4AtF3tp+3Wzs=;
	b=Rb52kiLtTg3v2u9zgMn3NUgzc+I9t7goexfTSG/6vAd6CFqdCGPPMNDDYCobdCdyrq5sS4
	THsDzUD4UF4y2fXBlIeYIVCPmZLL7CdaqepqR8WgmiYxUf4btn7G6HEQab08I1KrGeDcGm
	nmUC3Xv4HYwAo2tomf/WXQlFMXA6O8w=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	loongarch@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kvm@vger.kernel.org
Cc: Juergen Gross ,
	Andy Lutomirski ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Peter Zijlstra ,
	Will Deacon ,
	Boqun Feng ,
	Waiman Long ,
	Jiri Kosina ,
	Josh Poimboeuf ,
	Pawan Gupta ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Russell King ,
	Catalin Marinas ,
	Huacai Chen ,
	WANG Xuerui ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Alexandre Ghiti ,
	Juri Lelli ,
	Vincent Guittot ,
	Dietmar Eggemann ,
	Steven Rostedt ,
	Ben Segall ,
	Mel Gorman ,
	Valentin Schneider ,
	linux-arm-kernel@lists.infradead.org,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Daniel Lezcano 
Subject: [PATCH 00/14] paravirt: cleanup and reorg
Date: Thu, 11 Sep 2025 08:34:19 +0200
Message-ID: <20250911063433.13783-1-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.30 / 50.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];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FREEMAIL_CC(0.00)[suse.com,kernel.org,linutronix.de,redhat.com,alien8.de,linux.intel.com,zytor.com,microsoft.com,infradead.org,gmail.com,oracle.com,lists.xenproject.org,broadcom.com,armlinux.org.uk,arm.com,xen0n.name,linux.ibm.com,ellerman.id.au,csgroup.eu,sifive.com,dabbelt.com,eecs.berkeley.edu,ghiti.fr,linaro.org,goodmis.org,google.com,suse.de,lists.infradead.org,epam.com];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	TAGGED_RCPT(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid];
	RCPT_COUNT_GT_50(0.00)[56];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -1.30

Some cleanups and reorg of paravirt code and headers:

- The first 2 patches should be not controversial at all, as they
  remove just some no longer needed #include and struct forward
  declarations.

- The 3rd patch is removing CONFIG_PARAVIRT_DEBUG, which IMO has
  no real value, as it just changes a crash to a BUG() (the stack
  trace will basically be the same). As the maintainer of the main
  paravirt user (Xen) I have never seen this crash/BUG() to happen.

- The 4th patch is just a movement of code.

- I don't know for what reason asm/paravirt_api_clock.h was added,
  as all archs supporting it do it exactly in the same way. Patch
  5 is removing it.

- Patches 6-12 are streamlining the paravirt clock interfaces by
  using a common implementation across architectures where possible
  and by moving the related code into common sched code, as this is
  where it should live.

- Patches 13+14 are more like RFC material: patch 13 is doing some
  preparation work to enable patch 14 to move all spinlock related
  paravirt functions into qspinlock.h. If this approach is accepted,
  I'd like to continue with this work by moving most (or all?)
  paravirt functions from paravirt.h into the headers where their
  native counterparts are defined. This is meant to keep the native
  and paravirt function definitions together in one place and
  hopefully to be able to reduce the include hell with paravirt.

Juergen Gross (14):
  x86/paravirt: remove not needed includes of paravirt.h
  x86/paravirt: remove some unneeded struct declarations
  x86/paravirt: remove PARAVIRT_DEBUG config option
  x86/paravirt: move thunk macros to paravirt_types.h
  paravirt: remove asm/paravirt_api_clock.h
  sched: move clock related paravirt code to kernel/sched
  arm/paravirt: use common code for paravirt_steal_clock()
  arm64/paravirt: use common code for paravirt_steal_clock()
  loongarch/paravirt: use common code for paravirt_steal_clock()
  riscv/paravirt: use common code for paravirt_steal_clock()
  x86/paravirt: use common code for paravirt_steal_clock()
  x86/paravirt: move paravirt_sched_clock() related code into tsc.c
  x86/paravirt: allow pv-calls outside paravirt.h
  x86/pvlocks: move paravirt spinlock functions into qspinlock.h

 arch/Kconfig                                  |   3 +
 arch/arm/Kconfig                              |   1 +
 arch/arm/include/asm/paravirt.h               |  22 ---
 arch/arm/include/asm/paravirt_api_clock.h     |   1 -
 arch/arm/kernel/Makefile                      |   1 -
 arch/arm/kernel/paravirt.c                    |  23 ---
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/paravirt.h             |  14 --
 arch/arm64/include/asm/paravirt_api_clock.h   |   1 -
 arch/arm64/kernel/paravirt.c                  |  11 +-
 arch/loongarch/Kconfig                        |   1 +
 arch/loongarch/include/asm/paravirt.h         |  13 --
 .../include/asm/paravirt_api_clock.h          |   1 -
 arch/loongarch/kernel/paravirt.c              |  10 +-
 arch/powerpc/include/asm/paravirt.h           |   3 -
 arch/powerpc/include/asm/paravirt_api_clock.h |   2 -
 arch/powerpc/platforms/pseries/setup.c        |   4 +-
 arch/riscv/Kconfig                            |   1 +
 arch/riscv/include/asm/paravirt.h             |  14 --
 arch/riscv/include/asm/paravirt_api_clock.h   |   1 -
 arch/riscv/kernel/paravirt.c                  |  11 +-
 arch/x86/Kconfig                              |   8 +-
 arch/x86/entry/entry_64.S                     |   1 -
 arch/x86/entry/vsyscall/vsyscall_64.c         |   1 -
 arch/x86/hyperv/hv_spinlock.c                 |   1 -
 arch/x86/include/asm/apic.h                   |   4 -
 arch/x86/include/asm/highmem.h                |   1 -
 arch/x86/include/asm/mmu_context.h            |   1 -
 arch/x86/include/asm/mshyperv.h               |   1 -
 arch/x86/include/asm/paravirt.h               | 166 ------------------
 arch/x86/include/asm/paravirt_api_clock.h     |   1 -
 arch/x86/include/asm/paravirt_types.h         |  82 +++++++--
 arch/x86/include/asm/pgtable_32.h             |   1 -
 arch/x86/include/asm/qspinlock.h              |  49 +++++-
 arch/x86/include/asm/spinlock.h               |   1 -
 arch/x86/include/asm/timer.h                  |   1 +
 arch/x86/include/asm/tlbflush.h               |   4 -
 arch/x86/kernel/apm_32.c                      |   1 -
 arch/x86/kernel/callthunks.c                  |   1 -
 arch/x86/kernel/cpu/bugs.c                    |   1 -
 arch/x86/kernel/cpu/vmware.c                  |   1 +
 arch/x86/kernel/kvm.c                         |   1 +
 arch/x86/kernel/kvmclock.c                    |   1 +
 arch/x86/kernel/paravirt.c                    |  16 --
 arch/x86/kernel/tsc.c                         |  10 +-
 arch/x86/kernel/vsmp_64.c                     |   1 -
 arch/x86/kernel/x86_init.c                    |   1 -
 arch/x86/lib/cache-smp.c                      |   1 -
 arch/x86/mm/init.c                            |   1 -
 arch/x86/xen/spinlock.c                       |   1 -
 arch/x86/xen/time.c                           |   2 +
 drivers/clocksource/hyperv_timer.c            |   2 +
 drivers/xen/time.c                            |   2 +-
 include/linux/sched/cputime.h                 |  18 ++
 kernel/sched/core.c                           |   5 +
 kernel/sched/cputime.c                        |  13 ++
 kernel/sched/sched.h                          |   3 +-
 57 files changed, 182 insertions(+), 362 deletions(-)
 delete mode 100644 arch/arm/include/asm/paravirt.h
 delete mode 100644 arch/arm/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/arm/kernel/paravirt.c
 delete mode 100644 arch/arm64/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/loongarch/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/powerpc/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/riscv/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/x86/include/asm/paravirt_api_clock.h

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 06:34:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 06:34:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119344.1464743 (Exim 4.92)
	(envelope-from )
	id 1uwatN-0005XM-Tc; Thu, 11 Sep 2025 06:34:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119344.1464743; Thu, 11 Sep 2025 06:34: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 1uwatN-0005XF-Qw; Thu, 11 Sep 2025 06:34:49 +0000
Received: by outflank-mailman (input) for mailman id 1119344;
 Thu, 11 Sep 2025 06:34:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwatM-0005JR-5g
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 06:34:48 +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 688fea76-8ed9-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 08:34:46 +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 930803FA7E;
 Thu, 11 Sep 2025 06:34: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 CC32A1372E;
 Thu, 11 Sep 2025 06:34: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 2pIrMIRtwmj3TAAAD6G6ig
 (envelope-from ); Thu, 11 Sep 2025 06:34: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: 688fea76-8ed9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572485; 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=ZcukGV7gQuiuA9hOLB6SltsCYfjx1J8SnmqFPL24sjI=;
	b=bjluMrfubjAkD8E7K6kYZWt+KlEp3VYRjX2q9RDPiEcTN60YcpbA/Z4krsVy2uiDXAm7rD
	UhZ3rk5S376wtZbvaqTW8NflOn+DQ7GqNxRVUVWHa1stcqCBoU0ycDm/UOUvUI2D/CAjb/
	XX36UuZRloBTewGVomuZJPDiZS1hGQU=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572485; 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=ZcukGV7gQuiuA9hOLB6SltsCYfjx1J8SnmqFPL24sjI=;
	b=bjluMrfubjAkD8E7K6kYZWt+KlEp3VYRjX2q9RDPiEcTN60YcpbA/Z4krsVy2uiDXAm7rD
	UhZ3rk5S376wtZbvaqTW8NflOn+DQ7GqNxRVUVWHa1stcqCBoU0ycDm/UOUvUI2D/CAjb/
	XX36UuZRloBTewGVomuZJPDiZS1hGQU=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org
Cc: Juergen Gross ,
	Andy Lutomirski ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Peter Zijlstra ,
	Will Deacon ,
	Boqun Feng ,
	Waiman Long ,
	Jiri Kosina ,
	Josh Poimboeuf ,
	Pawan Gupta ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 01/14] x86/paravirt: remove not needed includes of paravirt.h
Date: Thu, 11 Sep 2025 08:34:20 +0200
Message-ID: <20250911063433.13783-2-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250911063433.13783-1-jgross@suse.com>
References: <20250911063433.13783-1-jgross@suse.com>
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];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TAGGED_RCPT(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_CC(0.00)[suse.com,kernel.org,linutronix.de,redhat.com,alien8.de,linux.intel.com,zytor.com,microsoft.com,infradead.org,gmail.com,oracle.com,lists.xenproject.org];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -5.30

In some places asm/paravirt.h is included without really being needed.

Remove the related #include statements.

Signed-off-by: Juergen Gross 
---
 arch/x86/entry/entry_64.S             | 1 -
 arch/x86/entry/vsyscall/vsyscall_64.c | 1 -
 arch/x86/hyperv/hv_spinlock.c         | 1 -
 arch/x86/include/asm/apic.h           | 4 ----
 arch/x86/include/asm/highmem.h        | 1 -
 arch/x86/include/asm/mmu_context.h    | 1 -
 arch/x86/include/asm/mshyperv.h       | 1 -
 arch/x86/include/asm/pgtable_32.h     | 1 -
 arch/x86/include/asm/spinlock.h       | 1 -
 arch/x86/include/asm/tlbflush.h       | 4 ----
 arch/x86/kernel/apm_32.c              | 1 -
 arch/x86/kernel/callthunks.c          | 1 -
 arch/x86/kernel/cpu/bugs.c            | 1 -
 arch/x86/kernel/vsmp_64.c             | 1 -
 arch/x86/kernel/x86_init.c            | 1 -
 arch/x86/lib/cache-smp.c              | 1 -
 arch/x86/mm/init.c                    | 1 -
 arch/x86/xen/spinlock.c               | 1 -
 18 files changed, 24 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ed04a968cc7d..7a82305405af 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index c9103a6fa06e..53e50b506471 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define CREATE_TRACE_POINTS
 #include "vsyscall_trace.h"
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 81b006601370..2a3c2afb0154 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -13,7 +13,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 07ba4935e873..e1de090e51dd 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -90,10 +90,6 @@ static inline bool apic_from_smp_config(void)
 /*
  * Basic functions accessing APICs.
  */
-#ifdef CONFIG_PARAVIRT
-#include 
-#endif
-
 static inline void native_apic_mem_write(u32 reg, u32 v)
 {
 	volatile u32 *addr = (volatile u32 *)(APIC_BASE + reg);
diff --git a/arch/x86/include/asm/highmem.h b/arch/x86/include/asm/highmem.h
index 585bdadba47d..decfaaf52326 100644
--- a/arch/x86/include/asm/highmem.h
+++ b/arch/x86/include/asm/highmem.h
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 73bf3b1b44e8..ee15657d25b3 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -9,7 +9,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index abc4659f5809..a9ab46fcb6a1 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/include/asm/pgtable_32.h b/arch/x86/include/asm/pgtable_32.h
index b612cc57a4d3..acea0cfa2460 100644
--- a/arch/x86/include/asm/pgtable_32.h
+++ b/arch/x86/include/asm/pgtable_32.h
@@ -16,7 +16,6 @@
 #ifndef __ASSEMBLER__
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 5b6bc7016c22..934632b78d09 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 00daedfefc1b..238a6b807da5 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -300,10 +300,6 @@ static inline void mm_clear_asid_transition(struct mm_struct *mm) { }
 static inline bool mm_in_asid_transition(struct mm_struct *mm) { return false; }
 #endif /* CONFIG_BROADCAST_TLB_FLUSH */
 
-#ifdef CONFIG_PARAVIRT
-#include 
-#endif
-
 #define flush_tlb_mm(mm)						\
 		flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL, true)
 
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index b37ab1095707..3175d7c134e9 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -229,7 +229,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/callthunks.c b/arch/x86/kernel/callthunks.c
index a951333c5995..e37728f70322 100644
--- a/arch/x86/kernel/callthunks.c
+++ b/arch/x86/kernel/callthunks.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index af838b8d845c..00ac4a58542a 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 73511332bb67..25625e3fc183 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define TOPOLOGY_REGISTER_OFFSET 0x10
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 0a2bbd674a6d..02ca90378bf9 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -12,7 +12,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/cache-smp.c b/arch/x86/lib/cache-smp.c
index c5c60d07308c..ae5a5dfd33c7 100644
--- a/arch/x86/lib/cache-smp.c
+++ b/arch/x86/lib/cache-smp.c
@@ -1,5 +1,4 @@
 // SPDX-License-Identifier: GPL-2.0
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index bb57e93b4caf..f52ebcac50d9 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 8e4efe0fb6f9..fe56646d6919 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 06:35:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 06:35:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119360.1464753 (Exim 4.92)
	(envelope-from )
	id 1uwats-0006BL-8N; Thu, 11 Sep 2025 06:35:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119360.1464753; Thu, 11 Sep 2025 06:35: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 1uwats-0006BE-5R; Thu, 11 Sep 2025 06:35:20 +0000
Received: by outflank-mailman (input) for mailman id 1119360;
 Thu, 11 Sep 2025 06:35: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 1uwatq-0005JR-KH
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 06:35:18 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7aac68dc-8ed9-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 08:35:16 +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 DFD6922BF9;
 Thu, 11 Sep 2025 06:35:15 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C15CC1372E;
 Thu, 11 Sep 2025 06:35:14 +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 PJLTLaJtwmgeTQAAD6G6ig
 (envelope-from ); Thu, 11 Sep 2025 06:35: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: 7aac68dc-8ed9-11f0-9809-7dc792cee155
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	loongarch@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kvm@vger.kernel.org
Cc: Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Russell King ,
	Catalin Marinas ,
	Will Deacon ,
	Huacai Chen ,
	WANG Xuerui ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Alexandre Ghiti ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Peter Zijlstra ,
	Juri Lelli ,
	Vincent Guittot ,
	Dietmar Eggemann ,
	Steven Rostedt ,
	Ben Segall ,
	Mel Gorman ,
	Valentin Schneider ,
	linux-arm-kernel@lists.infradead.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 06/14] sched: move clock related paravirt code to kernel/sched
Date: Thu, 11 Sep 2025 08:34:25 +0200
Message-ID: <20250911063433.13783-7-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250911063433.13783-1-jgross@suse.com>
References: <20250911063433.13783-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-Action: no action
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: DFD6922BF9
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spam-Score: -4.00

Paravirt clock related functions are available in multiple archs.

In order to share the common parts, move the common static keys
to kernel/sched/ and remove them from the arch specific files.

Make a common paravirt_steal_clock() implementation available in
kernel/sched/cputime.c, guarding it with a new config option
CONFIG_HAVE_PV_STEAL_CLOCK_GEN, which can be selectd by an arch
in case it wants to use that common variant.

Signed-off-by: Juergen Gross 
---
 arch/Kconfig                           |  3 +++
 arch/arm/include/asm/paravirt.h        |  4 ----
 arch/arm/kernel/paravirt.c             |  3 ---
 arch/arm64/include/asm/paravirt.h      |  4 ----
 arch/arm64/kernel/paravirt.c           |  4 +---
 arch/loongarch/include/asm/paravirt.h  |  3 ---
 arch/loongarch/kernel/paravirt.c       |  3 +--
 arch/powerpc/include/asm/paravirt.h    |  3 ---
 arch/powerpc/platforms/pseries/setup.c |  4 +---
 arch/riscv/include/asm/paravirt.h      |  4 ----
 arch/riscv/kernel/paravirt.c           |  4 +---
 arch/x86/include/asm/paravirt.h        |  4 ----
 arch/x86/kernel/cpu/vmware.c           |  1 +
 arch/x86/kernel/kvm.c                  |  1 +
 arch/x86/kernel/paravirt.c             |  3 ---
 drivers/xen/time.c                     |  1 +
 include/linux/sched/cputime.h          | 18 ++++++++++++++++++
 kernel/sched/core.c                    |  5 +++++
 kernel/sched/cputime.c                 | 13 +++++++++++++
 kernel/sched/sched.h                   |  2 +-
 20 files changed, 47 insertions(+), 40 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index d1b4ffd6e085..7921be052472 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1003,6 +1003,9 @@ config HAVE_IRQ_TIME_ACCOUNTING
 	  Archs need to ensure they use a high enough resolution clock to
 	  support irq time accounting and then call enable_sched_clock_irqtime().
 
+config HAVE_PV_STEAL_CLOCK_GEN
+	bool
+
 config HAVE_MOVE_PUD
 	bool
 	help
diff --git a/arch/arm/include/asm/paravirt.h b/arch/arm/include/asm/paravirt.h
index 95d5b0d625cd..69da4bdcf856 100644
--- a/arch/arm/include/asm/paravirt.h
+++ b/arch/arm/include/asm/paravirt.h
@@ -5,10 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 #include 
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 dummy_steal_clock(int cpu);
 
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
index 7dd9806369fb..3895a5578852 100644
--- a/arch/arm/kernel/paravirt.c
+++ b/arch/arm/kernel/paravirt.c
@@ -12,9 +12,6 @@
 #include 
 #include 
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/arch/arm64/include/asm/paravirt.h b/arch/arm64/include/asm/paravirt.h
index 9aa193e0e8f2..c9f7590baacb 100644
--- a/arch/arm64/include/asm/paravirt.h
+++ b/arch/arm64/include/asm/paravirt.h
@@ -5,10 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 #include 
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 dummy_steal_clock(int cpu);
 
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
index aa718d6a9274..943b60ce12f4 100644
--- a/arch/arm64/kernel/paravirt.c
+++ b/arch/arm64/kernel/paravirt.c
@@ -19,14 +19,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/arch/loongarch/include/asm/paravirt.h b/arch/loongarch/include/asm/paravirt.h
index 3f4323603e6a..d219ea0d98ac 100644
--- a/arch/loongarch/include/asm/paravirt.h
+++ b/arch/loongarch/include/asm/paravirt.h
@@ -5,9 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 
 #include 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
 
 u64 dummy_steal_clock(int cpu);
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/loongarch/kernel/paravirt.c b/arch/loongarch/kernel/paravirt.c
index b1b51f920b23..8caaa94fed1a 100644
--- a/arch/loongarch/kernel/paravirt.c
+++ b/arch/loongarch/kernel/paravirt.c
@@ -6,11 +6,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int has_steal_clock;
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
 static DEFINE_PER_CPU(struct kvm_steal_time, steal_time) __aligned(64);
 DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
 
diff --git a/arch/powerpc/include/asm/paravirt.h b/arch/powerpc/include/asm/paravirt.h
index b78b82d66057..92343a23ad15 100644
--- a/arch/powerpc/include/asm/paravirt.h
+++ b/arch/powerpc/include/asm/paravirt.h
@@ -23,9 +23,6 @@ static inline bool is_shared_processor(void)
 }
 
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 pseries_paravirt_steal_clock(int cpu);
 
 static inline u64 paravirt_steal_clock(int cpu)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index b10a25325238..50b26ed8432d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -83,9 +84,6 @@ DEFINE_STATIC_KEY_FALSE(shared_processor);
 EXPORT_SYMBOL(shared_processor);
 
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static bool steal_acc = true;
 static int __init parse_no_stealacc(char *arg)
 {
diff --git a/arch/riscv/include/asm/paravirt.h b/arch/riscv/include/asm/paravirt.h
index c0abde70fc2c..17e5e39c72c0 100644
--- a/arch/riscv/include/asm/paravirt.h
+++ b/arch/riscv/include/asm/paravirt.h
@@ -5,10 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 #include 
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 dummy_steal_clock(int cpu);
 
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/riscv/kernel/paravirt.c b/arch/riscv/kernel/paravirt.c
index fa6b0339a65d..d3c334f16172 100644
--- a/arch/riscv/kernel/paravirt.c
+++ b/arch/riscv/kernel/paravirt.c
@@ -16,15 +16,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 0d1e611f619c..491cb7e037bf 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -34,10 +34,6 @@ static __always_inline u64 paravirt_sched_clock(void)
 	return static_call(pv_sched_clock)();
 }
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 __visible void __native_queued_spin_unlock(struct qspinlock *lock);
 bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index cb3f900c46fc..a3e6936839b1 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8ae750cde0c6..a23211eaaeed 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.c b/arch/x86/kernel/paravirt.c
index ab3e172dcc69..a3ba4747be1c 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -60,9 +60,6 @@ void __init native_pv_lock_init(void)
 		static_branch_enable(&virt_spin_lock_key);
 }
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 5683383d2305..d360ded2ef39 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/include/linux/sched/cputime.h b/include/linux/sched/cputime.h
index 5f8fd5b24a2e..e90efaf6d26e 100644
--- a/include/linux/sched/cputime.h
+++ b/include/linux/sched/cputime.h
@@ -2,6 +2,7 @@
 #ifndef _LINUX_SCHED_CPUTIME_H
 #define _LINUX_SCHED_CPUTIME_H
 
+#include 
 #include 
 
 /*
@@ -180,4 +181,21 @@ static inline void prev_cputime_init(struct prev_cputime *prev)
 extern unsigned long long
 task_sched_runtime(struct task_struct *task);
 
+#ifdef CONFIG_PARAVIRT
+struct static_key;
+extern struct static_key paravirt_steal_enabled;
+extern struct static_key paravirt_steal_rq_enabled;
+
+#ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
+u64 dummy_steal_clock(int cpu);
+
+DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
+
+static inline u64 paravirt_steal_clock(int cpu)
+{
+	return static_call(pv_steal_clock)(cpu);
+}
+#endif
+#endif
+
 #endif /* _LINUX_SCHED_CPUTIME_H */
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index be00629f0ba4..e723226e4e11 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -767,6 +767,11 @@ struct rq *task_rq_lock(struct task_struct *p, struct rq_flags *rf)
  * RQ-clock updating methods:
  */
 
+/* Use CONFIG_PARAVIRT as this will avoid more #ifdef in arch code. */
+#ifdef CONFIG_PARAVIRT
+struct static_key paravirt_steal_rq_enabled;
+#endif
+
 static void update_rq_clock_task(struct rq *rq, s64 delta)
 {
 /*
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 7097de2c8cda..ed8f71e08047 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -251,6 +251,19 @@ void __account_forceidle_time(struct task_struct *p, u64 delta)
  * ticks are not redelivered later. Due to that, this function may on
  * occasion account more time than the calling functions think elapsed.
  */
+#ifdef CONFIG_PARAVIRT
+struct static_key paravirt_steal_enabled;
+
+#ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
+static u64 native_steal_clock(int cpu)
+{
+	return 0;
+}
+
+DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+#endif
+#endif
+
 static __always_inline u64 steal_account_process_time(u64 maxtime)
 {
 #ifdef CONFIG_PARAVIRT
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 6442441b46d7..fdf3021bdf7d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -82,7 +82,7 @@ struct rt_rq;
 struct sched_group;
 struct cpuidle_state;
 
-#ifdef CONFIG_PARAVIRT
+#if defined(CONFIG_PARAVIRT) && !defined(CONFIG_HAVE_PV_STEAL_CLOCK_GEN)
 # include 
 #endif
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 06:35:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 06:35:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119363.1464763 (Exim 4.92)
	(envelope-from )
	id 1uwatw-0006Uh-Fc; Thu, 11 Sep 2025 06:35:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119363.1464763; Thu, 11 Sep 2025 06:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwatw-0006UY-Ci; Thu, 11 Sep 2025 06:35:24 +0000
Received: by outflank-mailman (input) for mailman id 1119363;
 Thu, 11 Sep 2025 06:35:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwatv-0005pZ-8S
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 06:35:23 +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 7e0309c3-8ed9-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 08:35: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-out1.suse.de (Postfix) with ESMTPS id A431A3FA80;
 Thu, 11 Sep 2025 06:35: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 49BF41372E;
 Thu, 11 Sep 2025 06:35: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 vvWQEKltwmghTQAAD6G6ig
 (envelope-from ); Thu, 11 Sep 2025 06:35: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: 7e0309c3-8ed9-11f0-9d13-b5c5bf9af7f9
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	virtualization@lists.linux.dev,
	x86@kernel.org
Cc: Juergen Gross ,
	Russell King ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	linux-arm-kernel@lists.infradead.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 07/14] arm/paravirt: use common code for paravirt_steal_clock()
Date: Thu, 11 Sep 2025 08:34:26 +0200
Message-ID: <20250911063433.13783-8-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250911063433.13783-1-jgross@suse.com>
References: <20250911063433.13783-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-Spam-Level: 
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: A431A3FA80
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Flag: NO
X-Spam-Score: -4.00

Remove the arch specific variant of paravirt_steal_clock() and use
the common one instead.

This allows to remove paravirt.c and paravirt.h from arch/arm.

Until all archs supporting Xen have been switched to the common code
of paravirt_steal_clock(), drivers/xen/time.c needs to include
asm/paravirt.h for those archs, while this is not necessary for arm
any longer.

Signed-off-by: Juergen Gross 
---
 arch/arm/Kconfig                |  1 +
 arch/arm/include/asm/paravirt.h | 18 ------------------
 arch/arm/kernel/Makefile        |  1 -
 arch/arm/kernel/paravirt.c      | 20 --------------------
 drivers/xen/time.c              |  2 ++
 5 files changed, 3 insertions(+), 39 deletions(-)
 delete mode 100644 arch/arm/include/asm/paravirt.h
 delete mode 100644 arch/arm/kernel/paravirt.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b1f3df39ed40..48c3a36a63f8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1338,6 +1338,7 @@ config UACCESS_WITH_MEMCPY
 
 config PARAVIRT
 	bool "Enable paravirtualization code"
+	select HAVE_PV_STEAL_CLOCK_GEN
 	help
 	  This changes the kernel so it can modify itself when it is run
 	  under a hypervisor, potentially improving performance significantly
diff --git a/arch/arm/include/asm/paravirt.h b/arch/arm/include/asm/paravirt.h
deleted file mode 100644
index 69da4bdcf856..000000000000
--- a/arch/arm/include/asm/paravirt.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM_PARAVIRT_H
-#define _ASM_ARM_PARAVIRT_H
-
-#ifdef CONFIG_PARAVIRT
-#include 
-
-u64 dummy_steal_clock(int cpu);
-
-DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
-
-static inline u64 paravirt_steal_clock(int cpu)
-{
-	return static_call(pv_steal_clock)(cpu);
-}
-#endif
-
-#endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index afc9de7ef9a1..b36cf0cfd4a7 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -83,7 +83,6 @@ AFLAGS_iwmmxt.o			:= -Wa,-mcpu=iwmmxt
 obj-$(CONFIG_ARM_CPU_TOPOLOGY)  += topology.o
 obj-$(CONFIG_VDSO)		+= vdso.o
 obj-$(CONFIG_EFI)		+= efi.o
-obj-$(CONFIG_PARAVIRT)	+= paravirt.o
 
 obj-y			+= head$(MMUEXT).o
 obj-$(CONFIG_DEBUG_LL)	+= debug.o
diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
deleted file mode 100644
index 3895a5578852..000000000000
--- a/arch/arm/kernel/paravirt.c
+++ /dev/null
@@ -1,20 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- *
- * Copyright (C) 2013 Citrix Systems
- *
- * Author: Stefano Stabellini 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static u64 native_steal_clock(int cpu)
-{
-	return 0;
-}
-
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index d360ded2ef39..53b12f5ac465 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -10,7 +10,9 @@
 #include 
 #include 
 
+#ifndef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
 #include 
+#endif
 #include 
 #include 
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 06:36:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 06:36:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119382.1464773 (Exim 4.92)
	(envelope-from )
	id 1uwaua-0007La-Pu; Thu, 11 Sep 2025 06:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119382.1464773; Thu, 11 Sep 2025 06:36: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 1uwaua-0007LH-MF; Thu, 11 Sep 2025 06:36:04 +0000
Received: by outflank-mailman (input) for mailman id 1119382;
 Thu, 11 Sep 2025 06:36: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 1uwauI-0005JR-QI
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 06:35:46 +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 8ba45cfb-8ed9-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 08:35:45 +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 CD4D03FA7F;
 Thu, 11 Sep 2025 06:35: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 416601372E;
 Thu, 11 Sep 2025 06:35: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 w5NADsBtwmhHTQAAD6G6ig
 (envelope-from ); Thu, 11 Sep 2025 06:35: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: 8ba45cfb-8ed9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572544; 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=mwbRHLALg5lwBc9OgVUB+3usz/LNGiagF/bxFj43cyE=;
	b=iIKZ32INl/ZYXAkpgDfbZ1kv7upRSYUWCbvcI02xFi4NYMTYL6p3WVeZpIILKEMMWX/ulI
	lW2wbz0/I2wRtO2xLTIH49uobGMLrdjNBpB/PZq60XmRSlaf4/Fy8/AbTHYfp19QOJD8xR
	/4leIyIhyow/2KKDzj1HsLpCJnTwI+A=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572544; 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=mwbRHLALg5lwBc9OgVUB+3usz/LNGiagF/bxFj43cyE=;
	b=iIKZ32INl/ZYXAkpgDfbZ1kv7upRSYUWCbvcI02xFi4NYMTYL6p3WVeZpIILKEMMWX/ulI
	lW2wbz0/I2wRtO2xLTIH49uobGMLrdjNBpB/PZq60XmRSlaf4/Fy8/AbTHYfp19QOJD8xR
	/4leIyIhyow/2KKDzj1HsLpCJnTwI+A=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev
Cc: Juergen Gross ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Boris Ostrovsky ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 11/14] x86/paravirt: use common code for paravirt_steal_clock()
Date: Thu, 11 Sep 2025 08:34:30 +0200
Message-ID: <20250911063433.13783-12-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250911063433.13783-1-jgross@suse.com>
References: <20250911063433.13783-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];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[16];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -6.80

Remove the arch specific variant of paravirt_steal_clock() and use
the common one instead.

With alol archs supporting Xen now having been switched to the common
variant, including paravirt.h can be dropped from drivers/xen/time.c.

Signed-off-by: Juergen Gross 
---
 arch/x86/Kconfig                | 1 +
 arch/x86/include/asm/paravirt.h | 7 -------
 arch/x86/kernel/paravirt.c      | 6 ------
 arch/x86/xen/time.c             | 1 +
 drivers/xen/time.c              | 3 ---
 5 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 07bf67b849b7..0f8abf96cc39 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -784,6 +784,7 @@ if HYPERVISOR_GUEST
 config PARAVIRT
 	bool "Enable paravirtualization code"
 	depends on HAVE_STATIC_CALL
+	select HAVE_PV_STEAL_CLOCK_GEN
 	help
 	  This changes the kernel so it can modify itself when it is run
 	  under a hypervisor, potentially improving performance significantly
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 491cb7e037bf..37d7494ce146 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -21,10 +21,8 @@ struct mm_struct;
 #include 
 #include 
 
-u64 dummy_steal_clock(int cpu);
 u64 dummy_sched_clock(void);
 
-DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
 DECLARE_STATIC_CALL(pv_sched_clock, dummy_sched_clock);
 
 void paravirt_set_sched_clock(u64 (*func)(void));
@@ -39,11 +37,6 @@ bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
 bool pv_is_native_vcpu_is_preempted(void);
 
-static inline u64 paravirt_steal_clock(int cpu)
-{
-	return static_call(pv_steal_clock)(cpu);
-}
-
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 void __init paravirt_set_cap(void);
 #endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index a3ba4747be1c..42991d471bf3 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -60,12 +60,6 @@ void __init native_pv_lock_init(void)
 		static_branch_enable(&virt_spin_lock_key);
 }
 
-static u64 native_steal_clock(int cpu)
-{
-	return 0;
-}
-
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
 DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
 
 void paravirt_set_sched_clock(u64 (*func)(void))
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 96521b1874ac..e4754b2fa900 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 53b12f5ac465..0b18d8a5a2dd 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -10,9 +10,6 @@
 #include 
 #include 
 
-#ifndef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
-#include 
-#endif
 #include 
 #include 
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 06:36:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 06:36:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119386.1464783 (Exim 4.92)
	(envelope-from )
	id 1uwauh-0007l5-4l; Thu, 11 Sep 2025 06:36:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119386.1464783; Thu, 11 Sep 2025 06:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwauh-0007kw-1Y; Thu, 11 Sep 2025 06:36:11 +0000
Received: by outflank-mailman (input) for mailman id 1119386;
 Thu, 11 Sep 2025 06: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 1uwauP-0005pZ-6X
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 06:35:53 +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 8fff489c-8ed9-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 08:35:52 +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 13D253FA82;
 Thu, 11 Sep 2025 06:35: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 4C9F21372E;
 Thu, 11 Sep 2025 06:35: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 5g/+EMZtwmhSTQAAD6G6ig
 (envelope-from ); Thu, 11 Sep 2025 06:35:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8fff489c-8ed9-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572551; 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=OLXeav6R3goFmnwqSyQXuQdUCPELjQMRny6JTPFJ3Z4=;
	b=IUpvF7kl5ZffJaksZuVY58/fynKPlGy1YDMgLOhKCWtjWc2rf1JgNgT+dENyA95kcJtlcA
	GgcRSwq8j2i33uJ30B7sVVyAxCZqi2lXAROPHSDR7pTQKbqUnxbpfbPmIS6WQMF9cREk2g
	FOe7ZaMXuRM4AUBuNbw/35c7TJ13g+M=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1757572551; 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=OLXeav6R3goFmnwqSyQXuQdUCPELjQMRny6JTPFJ3Z4=;
	b=IUpvF7kl5ZffJaksZuVY58/fynKPlGy1YDMgLOhKCWtjWc2rf1JgNgT+dENyA95kcJtlcA
	GgcRSwq8j2i33uJ30B7sVVyAxCZqi2lXAROPHSDR7pTQKbqUnxbpfbPmIS6WQMF9cREk2g
	FOe7ZaMXuRM4AUBuNbw/35c7TJ13g+M=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	linux-hyperv@vger.kernel.org
Cc: Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Daniel Lezcano ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 12/14] x86/paravirt: move paravirt_sched_clock() related code into tsc.c
Date: Thu, 11 Sep 2025 08:34:31 +0200
Message-ID: <20250911063433.13783-13-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250911063433.13783-1-jgross@suse.com>
References: <20250911063433.13783-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -6.80

The only user of paravirt_sched_clock() is in tsc.c, so move the code
from paravirt.c and paravirt.h to tsc.c.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/paravirt.h    | 12 ------------
 arch/x86/include/asm/timer.h       |  1 +
 arch/x86/kernel/kvmclock.c         |  1 +
 arch/x86/kernel/paravirt.c         |  7 -------
 arch/x86/kernel/tsc.c              | 10 +++++++++-
 arch/x86/xen/time.c                |  1 +
 drivers/clocksource/hyperv_timer.c |  2 ++
 7 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 37d7494ce146..bd050ceaae00 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -18,20 +18,8 @@ struct mm_struct;
 #ifndef __ASSEMBLER__
 #include 
 #include 
-#include 
 #include 
 
-u64 dummy_sched_clock(void);
-
-DECLARE_STATIC_CALL(pv_sched_clock, dummy_sched_clock);
-
-void paravirt_set_sched_clock(u64 (*func)(void));
-
-static __always_inline u64 paravirt_sched_clock(void)
-{
-	return static_call(pv_sched_clock)();
-}
-
 __visible void __native_queued_spin_unlock(struct qspinlock *lock);
 bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index 23baf8c9b34c..fda18bcb19b4 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -12,6 +12,7 @@ extern void recalibrate_cpu_khz(void);
 extern int no_timer_check;
 
 extern bool using_native_sched_clock(void);
+void paravirt_set_sched_clock(u64 (*func)(void));
 
 /*
  * We use the full linear equation: f(x) = a + b*x, in order to allow
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ca0a49eeac4a..b5991d53fc0e 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 42991d471bf3..4e37db8073f9 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -60,13 +60,6 @@ void __init native_pv_lock_init(void)
 		static_branch_enable(&virt_spin_lock_key);
 }
 
-DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
-
-void paravirt_set_sched_clock(u64 (*func)(void))
-{
-	static_call_update(pv_sched_clock, func);
-}
-
 static noinstr void pv_native_safe_halt(void)
 {
 	native_safe_halt();
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 87e749106dda..554b54783a04 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -266,19 +266,27 @@ u64 native_sched_clock_from_tsc(u64 tsc)
 /* We need to define a real function for sched_clock, to override the
    weak default version */
 #ifdef CONFIG_PARAVIRT
+DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
+
 noinstr u64 sched_clock_noinstr(void)
 {
-	return paravirt_sched_clock();
+	return static_call(pv_sched_clock)();
 }
 
 bool using_native_sched_clock(void)
 {
 	return static_call_query(pv_sched_clock) == native_sched_clock;
 }
+
+void paravirt_set_sched_clock(u64 (*func)(void))
+{
+	static_call_update(pv_sched_clock, func);
+}
 #else
 u64 sched_clock_noinstr(void) __attribute__((alias("native_sched_clock")));
 
 bool using_native_sched_clock(void) { return true; }
+void paravirt_set_sched_clock(u64 (*func)(void)) { }
 #endif
 
 notrace u64 sched_clock(void)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index e4754b2fa900..6f9f665bb7ae 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index 2edc13ca184e..6397a7ba4a98 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -535,6 +535,8 @@ static __always_inline void hv_setup_sched_clock(void *sched_clock)
 	sched_clock_register(sched_clock, 64, NSEC_PER_SEC);
 }
 #elif defined CONFIG_PARAVIRT
+#include 
+
 static __always_inline void hv_setup_sched_clock(void *sched_clock)
 {
 	/* We're on x86/x64 *and* using PV ops */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:16:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:16:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119430.1464793 (Exim 4.92)
	(envelope-from )
	id 1uwbXG-0005IC-1x; Thu, 11 Sep 2025 07:16:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119430.1464793; Thu, 11 Sep 2025 07:16: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 1uwbXF-0005I5-V4; Thu, 11 Sep 2025 07:16:01 +0000
Received: by outflank-mailman (input) for mailman id 1119430;
 Thu, 11 Sep 2025 07:16: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 1uwbXE-0005Hz-LO
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:16:00 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2413::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 29f127cc-8edf-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 09:15:59 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 IA0PR12MB8929.namprd12.prod.outlook.com (2603:10b6:208:484::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9052.30; Thu, 11 Sep 2025 07:15:55 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 07:15:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 29f127cc-8edf-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Br7WOojWgTIQCeBpM9rtbYGVrA32wohHluU+479m3yO+LEywrXynLAKOnYLqFTPihWNjLbaQ8rpguq1Kp6Q1sCqVHOLU6hiUhabQVu1NuwSjJ+0HLylRv1pY+5Gh9EQCB412xiBbAn+RlnxzNwkr4FWZXWlm3YjiQK9kMLx2aAFpuGjMwmg+3yiDQY0qdYd8bRP/FMs5sFXSxpezrkmRhtEAsj0CwNHYkSbQ0pZRhE1sa4//pcJorzUUQzBbOzrzMV4TloYQI5XSlCm3RJggyI/6jobGexX4UD+jmv7RJ/popPnGn9z5FVdMQWEzpKEjAyoY08DB5HFD/M1WzrDNWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=akXXZmOus3534TwnnQZvkOuf3V88X7Jud7UbWM7gcPs=;
 b=wkFCYyjAqFqsvcpIaLJ6gUTFRRAezcGD05le9CIufYOPzTd6xLZ4UioKJ38rghPhNC4idv01+9HjRZdvG9qWIWw4dNl+DGttDWPGW+IzvzZlSoD41f0q8AKSTEO21uqGQWzz3sbeUJWXHezsH47o74pRUqTKWO///iAu8AvE5ZGt6Kdep2WnsI+PfqIxdgbYc8/LjDoAFFff0lLGkCKAvJJSz3Ow1Hdb9uKRUeRrLu0xl+Vsdd17spglBMqmrV403eZkqqPkHM5YnBJsINyrCEffL0akqeHntBOIUsEi3sMOqvUNDn8u68nLgU93QMDCxE2EQ8GjwF17TbD6XpFqZA==
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=akXXZmOus3534TwnnQZvkOuf3V88X7Jud7UbWM7gcPs=;
 b=Aj3s/GwooIz+EuQ+/7uhIyD6MuNwditB6t40DdkL18BZyFX8M4Qf0j/YNNMQTDQ5XgmbdAx3EQBBCVaapFhcEEOg6P3RN7HCnhSbCeHBbwrnY2byOIffmqlIMLi+2Hu1B5yb+H9IJ6/JGQ3DTeK9//bG5G5Hy+U8BkSk2HO8+WQ=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
Thread-Topic: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
Thread-Index: AQHcIiYBT2pZeRIoyka2sfY1lhJyobSMdHkAgAEcX0A=
Date: Thu, 11 Sep 2025 07:15:55 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-4-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-09-11T07:06:27.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_|IA0PR12MB8929:EE_
x-ms-office365-filtering-correlation-id: 9e30b41f-1227-4b1c-de4f-08ddf1030c63
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?dFZRdXU1Q2lpZk1Da1RjQXd4b1hmVGswK1JmMDcwL3ZXSmQ3WWZNSlc0YzM2?=
 =?utf-8?B?R2lWNEFkb09rSTVERVVPeVhzWE45dGY5bm9sdGxMemVvanVoT1JqZmpxRFdH?=
 =?utf-8?B?c2l3cXhzVmJOZnFwVzE1bmFUQWZLOVFJMnJaWEpTc0s3bExhMVNFODN6aCtX?=
 =?utf-8?B?ckNMTG43bWdKZ2lsR3ZNMWI2bWdhL01MYjBOdXJuNWh5VWRZVGpaMC9qWkpy?=
 =?utf-8?B?dVEvSUYvOE9LWi85cWVhYjlHbU0ycGN4YUl1TTg3VkFKQmVNeXZvQk9jOHJQ?=
 =?utf-8?B?cjBwZ29PZXJGc1h2SlJBL3NKVmlrNktZRFFhQnZPQStaN1lnWG1pR2EvbjNi?=
 =?utf-8?B?eGlNeDZRK0l0dGlqMktpMDhsMjkyb2NUeFd3TkZpaXB6VGYrVWtjNkZxU0h1?=
 =?utf-8?B?dXpFajAwUUhQRlNqTG1sa2JMZFc5WWVJK21rV1VJTWYwYnRjRzJaeXFXVlI1?=
 =?utf-8?B?T0ltbVllVUxkeUU0NVU5cHF5M3RFZngvd01YQXh4RWtzdm8vSDRGQUIvQk4x?=
 =?utf-8?B?aGE1VnhSRXdydEMzNEJ1OHVSS3ozNndUYjFnZWRjajlUbFJHMDhwVUdwMzI1?=
 =?utf-8?B?T1d4T3haL2tldXE3VnlJaTRQa1U3MXRZYUQ1T0lTMlltZHNRakh3UnMrSDJk?=
 =?utf-8?B?L29jUGJzb0gybThrU0pBZHorak5IUGhCdjFQNHVyUC9lVHZRdFVjcUhScUg1?=
 =?utf-8?B?d3hqV2JhRlFMWGFOMVkrdXBISERxTjBISEt4Rm9POWdaZEtmSS90Q05EQ2R2?=
 =?utf-8?B?SkV4QkVhL3QyanE4d0NSUEhlUUdKbzM5OUZFeDFmRzh4VVBMZGlmcmZEUG0r?=
 =?utf-8?B?YlJrRU1lOW9Id3BFU2hOK1FUMzcyUCs5RDJVaU1mcmVQRkpHZDFoRG90Tldo?=
 =?utf-8?B?Q3NuVGlWNzB5aUJxWnFGVjdXWXB6anFacDI2Z2VUbENBS0pvUmt0bFZmbkVa?=
 =?utf-8?B?V011akxsaitOUGtSc0Z3d0lUcS9aVm1HRUZPVUpUZTVCQ0ZMei9zajc4dTRT?=
 =?utf-8?B?cmZKb3NnczEzdk9CcW5tYXIzMU1tS08xelJQc0lYdDVyb1cySXU3cXc3MlVV?=
 =?utf-8?B?V1JSNHlRVTRLVWFGR1pSMVk2UW90UTBtRG5uOC94bzdNSkJUcUZwRmFyZ3ZV?=
 =?utf-8?B?dE83ZFJJdHVGREt5YnFTQlZGTUN3b0hxZVg3cmJJTlNpSWdoSWFUb3h0MVEy?=
 =?utf-8?B?RnkvN3N0S3o0cS9JUm5WU2tsaGsyc1RBVUZnMVhFcE1TREZ5R3N4V0NhdDh4?=
 =?utf-8?B?eVkvbWdxbDQrYSs4TUlMZS9tenVjTmREMEF5WCsySmgrWFFuNmFUak1ZSG1J?=
 =?utf-8?B?RHFOYkMvQkQxSTNONUhXdnJwa2pvdGxaeFZ3WU14N1E0WGFURVNFaXJLMys2?=
 =?utf-8?B?NWZTZVVENUVwQWVTVitjN0J4MHhVVmZ6VzFuZElsT2tZYWd3bzd3a0VlWGhZ?=
 =?utf-8?B?TkpzK3Rpa0l5bTZnUWZrNml3S0ZDcnhtNHAvSmgyMU1SOUpXUTRzTkZEaUgz?=
 =?utf-8?B?eFpjWWh6YnA1UTU5L0k2SjF6NkY1ak1ZeGhrYnRqT3JoczMzSjZPd2tJRWQ0?=
 =?utf-8?B?dVRVOUlFYjI5QjRJNEtUYTV4Q0t6NmtDbjdnaEpvRGtxdU9VdFVZT0ZxUURF?=
 =?utf-8?B?UWlYamFuMWtkM0lGYzlvWkxVdTFHVCt5STNXbk82OXBFaGkxZ3dnMjdDNHc0?=
 =?utf-8?B?U1NyWHU4V2FGaHhzSE5uRGNQR0dyT2RObTFFc2M2eVFyWUNqa0hEdUJieFNt?=
 =?utf-8?B?ckIzWHdjQWFyMDZUdlBmZkZyRVJ4R1cxRmdCd3JpREdGZjR5OHdqSXN4RnZp?=
 =?utf-8?B?Rkd3ODU5bmcxWU1GeW4xMTB2S2ZNNER0VFVYNUluNk80Tk5jRkRzaU9LbmFj?=
 =?utf-8?B?VnNzYzVkbEVNYkRmdEpvSVlwWDZlYUZxc1NodTdQM0syRzViUUpEcXdXNStp?=
 =?utf-8?B?eGh1WDdlS1ZTTGNONEExTnFzTGpZQWZVaFo3L1dOYm1xQmR5Smp1NFcvREFl?=
 =?utf-8?Q?TXxtEabq/rNN2zqR/h1XMBFJWN0f6Q=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NkM0dnNzNkFWeGJjQ01obk0xS3F0QktWTkJpM3gvK1JMTlNLZ3JZeUtBSHlo?=
 =?utf-8?B?MEhFclk5S24vSXJuRHkycjEzNDY4c3JiR2MwQzFpZ2JqdWQvYklKYys2dGI5?=
 =?utf-8?B?ckRjNFZWbk5NdEZrU3J0cDg2eWhJNkkvaFdQc3FsU0ZqVm9RQ0llT0pJb1VW?=
 =?utf-8?B?Q3dvcEpiSEc4cnZ5QlBrc0praG1hbHBEL0I1QlBIVTdxSmZ0dm9YNFM5dytu?=
 =?utf-8?B?c2l4Q3pLcUJvaWorYTVmVk9pYVBMWk1nbVRtQnh4eEl0WUY4ZW1RMjNHRVJF?=
 =?utf-8?B?RUhBRmJjSVhSZmdxanRWM0ZZN04vN0thbWU4Rmg5RkFQM0Vza2lLTWJ2ZUdv?=
 =?utf-8?B?ZVRsZklxYUFJN1YxUHBRaU1IYkt4dEpWR0IxRGp4S3UrVVN3OVNzNit3Zk84?=
 =?utf-8?B?aHRscTJGb2VOK2xFdXpuQ2NMMUFPNkMwc1dPZUxFc1M4SmhmYTFBZTV3eERi?=
 =?utf-8?B?SlNWVnN1RWl0WHZuZW1Sdmk2YUE5aXVITG1hamVxUnZoNUo4cFdmSnNXamhG?=
 =?utf-8?B?aGI1ZWp3R1lFMkliMStuVXU3UUlsaTF5dFNxMnI0VkZJSkl3aG9KVEpVWUxP?=
 =?utf-8?B?azhTbFd1eTRKUm85ZU0yS015QnRxWUM2ZEsxQXNwTDF3WEFJWG1RaHN4azdY?=
 =?utf-8?B?U0YxemorbmIzY0FWT005QlhOTVQ2SDFXTGlWWVRnYVB0UTRGWmdYWVZwL3Zh?=
 =?utf-8?B?WkVOdEd1MnM0QkxTc2xrYXE2U3dVVHhlcTc0TlFlckxRa253bXZCV2xJWWVX?=
 =?utf-8?B?QXY3VzZXM1VybEdTUmRQTlZTZjI4M3RIRWR0VWZhMURQV0lGUmRvZ090bHJm?=
 =?utf-8?B?NUJYVVN4eTVYbkhUV2UrTzgrajF0UDltOFJqTmJMOVUvUGJSN3NzOERzYUlt?=
 =?utf-8?B?cTBPN0JSTjlVYnV5VEFKb2xiTlNuNmh3K2NQZFNIK25qZms0enM1TTBka05B?=
 =?utf-8?B?VXJpYlI2blZBOHIzZHpEcUdBVE9jVm5VTk5kV0JBVytPeldwWllOREw3SXd6?=
 =?utf-8?B?WTBWNXo2Q2FudzI3bUxGVkVQb0lFNTJ2TWI5Nnc5RXZNVEJpVFJhK2laSC9t?=
 =?utf-8?B?SGtMSExoSHUyei9kakRLZ2g1eHVBc2FWNGlacEdsODRLSm82V0hXc04wTFRz?=
 =?utf-8?B?Q0JYYlNkRnMrbzM0L0JmTnZaVllWcmxHUGlyKy9Nek5LejJ5SVBrNlIvL092?=
 =?utf-8?B?RENyQWIzRUdTbCtjWTVadDAvSEdVREt5aUFzUTdDSW1SMmliMFR1YlVLUFRU?=
 =?utf-8?B?YWFnbnF6OUlaSHN6ZmRRTTJEdVJWT3NVRHkrY2JuRll2TEdRU2pVU1VBM1Js?=
 =?utf-8?B?TFNnWGpUbVFBRnJCUGRsUFo4Rm91VjROcloxbHZHSlB4WGs5SDBpVWVVN0FO?=
 =?utf-8?B?aGxSWm9TUTgvcGExUjRJbVhMSzNmN0k2K3V1SmVpUXhtcm9UYTVSbnZhSllo?=
 =?utf-8?B?ZjN2S1BEWFBBKytJSEhOQTdPZTY0Y0tzdmRtcUlvRGVlZ0VvQ3REbStIYlZx?=
 =?utf-8?B?bVJmL2hkWmZ5RTkrbnhSTU9FMGI3eUVnTTNXcDR3L0tRajZYYXpxT3V5d2dE?=
 =?utf-8?B?TVEzeGNRZkZJVGo2dGYxTmJsQWZTekMyazhlZW1tS2IzK2NBaWIwT3oxdWo1?=
 =?utf-8?B?cERCY0swaHhESUJpK2VzVW9Pa0RiNkFKS002a2JRLzFZMklnN0ZzMlYwSWZh?=
 =?utf-8?B?MG5veTdkblhqNU9OUmFtOUFXd21DaitLQXJPaU9kVDhmZW5JMVZRWDQ2Q0I0?=
 =?utf-8?B?cmYzdERHbVF2Y0QyZUd0RDZjUnBDelo3ZUkzNHdQR2R2S1FjZWZJbFZXbTFG?=
 =?utf-8?B?S3FGS0lFZkRQMm9LQVpKd1Vnc2Z0eUY4MlJDblFDMkhlNFFtRGViTW5ZQXNj?=
 =?utf-8?B?WWs3emNJdFIwbTJnRllGRTRNU0gwdVc3eEo0YzhseE5jTGc1bjIydkNTTHBW?=
 =?utf-8?B?T1Y2ZzQ0WmFDYUVvL01oN2IrSTNFQVpUMkdJWXNmd1FTZzR0bklseW5QYXhm?=
 =?utf-8?B?Q2JZNjhwYUJQWmZtS044L0FTSjZhMVhzTFI1U1Exc0JPbjMzeTNrYXBlSTZo?=
 =?utf-8?B?MEdHWENHYlJwWVZtUEd3MC9HTkpHbXg4d1BIN3dwaTlacWxMaHJ6UDlOd1lm?=
 =?utf-8?Q?w52Y=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: 9e30b41f-1227-4b1c-de4f-08ddf1030c63
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 07:15:55.1285
 (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: 6NLEnqI14iyiap+xnD2gHSmz3XoFhsIEzy4Ewrm6G3wKMe9GD0shYbjui+dpPlOd0TxcNMpDBcs4DhlnXAZR0A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8929

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEw
LCAyMDI1IDEwOjA5IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4g
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVA
Y2l0cml4LmNvbT47IHhlbi0NCj4gZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVj
dDogUmU6IFtQQVRDSCB2MiAwMy8yNl0geGVuL3g4NjogY29uc29saWRhdGUgdnJhbSB0cmFja2lu
ZyBzdXBwb3J0DQo+DQo+IE9uIDEwLjA5LjIwMjUgMDk6MzgsIFBlbm55IFpoZW5nIHdyb3RlOg0K
PiA+IEZsYWcgUEdfbG9nX2RpcnR5IGlzIGZvciBwYWdpbmcgbG9nIGRpcnR5IHN1cHBvcnQsIG5v
dCB2cmFtIHRyYWNraW5nIHN1cHBvcnQuDQo+ID4gSG93ZXZlciBkYXRhIHN0cnVjdHVyZSBzaF9k
aXJ0eV92cmFte30gYW5kIGZ1bmN0aW9uDQo+ID4gcGFnaW5nX2xvZ19kaXJ0eV9yYW5nZSgpIGRl
c2lnbmVkIGZvciB2cmFtIHRyYWNraW5nIHN1cHBvcnQsIGFyZSBndWFyZGVkIHdpdGgNCj4gUEdf
bG9nX2RpcnR5Lg0KPiA+IFdlIHJlbGVhc2UgYm90aCBmcm9tIFBHX2xvZ19kaXJ0eSwgYW5kIGFs
c28gbW92ZQ0KPiA+IHBhZ2luZ19sb2dfZGlydHlfcmFuZ2UoKSwgcmVtYW1lZCB3aXRoIHAybV9s
b2dfZGlydHlfcmFuZ2UoKSwgaW50byBwMm0uYywgd2hlcmUNCj4gaXQgbG9naWNhbGx5IGJlbG9u
Z3MuDQo+DQo+IEFyZW4ndCB0aGVzZSB0d28gaW5kZXBlbmRlbnQgY2hhbmdlcz8gT25lIHRvIGRl
YWwgd2l0aCBzdHJ1Y3Qgc2hfZGlydHlfdnJhbSwgdGhlDQo+IG90aGVyIHRvIG1vdmUgYW5kIHJl
bmFtZSBwYWdpbmdfbG9nX2RpcnR5X3JhbmdlKCk/IElycmVzcGVjdGl2ZSwgaW4gdGhlIGludGVy
ZXN0IG9mDQo+IG1ha2luZyBwcm9ncmVzczoNCj4gQWNrZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4gd2l0aCAuLi4NCj4NCj4gPiAtLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vcDJtLmgNCj4gPiArKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vcDJtLmgNCj4g
PiBAQCAtMTExMCw2ICsxMTEwLDEwIEBAIHN0YXRpYyBpbmxpbmUgaW50IHAybV9lbnRyeV9tb2Rp
Znkoc3RydWN0DQo+ID4gcDJtX2RvbWFpbiAqcDJtLCBwMm1fdHlwZV90IG50LA0KPiA+DQo+ID4g
ICNlbmRpZiAvKiBDT05GSUdfSFZNICovDQo+ID4NCj4gPiArLyogZ2V0IHRoZSBkaXJ0eSBiaXRt
YXAgZm9yIGEgc3BlY2lmaWMgcmFuZ2Ugb2YgcGZucyAqLw0KPg0KPiAuLi4gY29tbWVudCBzdHls
ZSBjb3JyZWN0ZWQgaGVyZSAoaGFwcHkgdG8gZG8gc28gd2hpbGUgY29tbWl0dGluZykuDQo+DQo+
IEFpdWkgdGhlIHBhdGNoIGlzIGluZGVwZW5kZW50IG9mIHRoZSBlYXJsaWVyIHR3bywgYW5kIGhl
bmNlIGNvdWxkIGdvIGluIGFoZWFkIG9mDQo+IHRoZW0uIFNhZGx5IG9uY2UgYWdhaW4gbm90aGlu
ZyBsaWtlIHRoaXMgaXMgc3RhdGVkIGFueXdoZXJlLCBzbyBwbGVhc2UgY29uZmlybS4NCj4NCg0K
WWVzLCBpdCBjb3VsZCBnbyBpbiBhaGVhZCBvZiB0aGVtLiBJJ2xsIHNwbGl0IGl0IGludG8gdHdv
IGNvbW1pdHMsIGFuZCBJIHdpbGwgZG8gdGhpcyBpbW1lZGlhdGVseSB0byBzZW5kIHJlZ2FyZGxl
c3Mgb2YgdGhpcyBwYXRjaCBzZXJpZS4NCg0KPiA+IC0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9wYWdpbmcuaA0KPiA+ICsrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYWdpbmcu
aA0KPiA+IEBAIC0xMzMsMTMgKzEzMywyMCBAQCBzdHJ1Y3QgcGFnaW5nX21vZGUgew0KPiA+ICAg
ICAgKERJVl9ST1VORF9VUChQQUREUl9CSVRTIC0gUEFHRV9TSElGVCAtIChQQUdFX1NISUZUICsg
MyksIFwNCj4gPiAgICAgICAgICAgICAgICAgICAgUEFHRV9TSElGVCAtIGlsb2cyKHNpemVvZiht
Zm5fdCkpKSArIDEpDQo+ID4NCj4gPiAtI2lmIFBHX2xvZ19kaXJ0eQ0KPiA+ICsjaWZkZWYgQ09O
RklHX0hWTQ0KPiA+ICsvKiBWUkFNIGRpcnR5IHRyYWNraW5nIHN1cHBvcnQgKi8NCj4gPiArc3Ry
dWN0IHNoX2RpcnR5X3ZyYW0gew0KPiA+ICsgICAgdW5zaWduZWQgbG9uZyBiZWdpbl9wZm47DQo+
ID4gKyAgICB1bnNpZ25lZCBsb25nIGVuZF9wZm47DQo+ID4gKyNpZmRlZiBDT05GSUdfU0hBRE9X
X1BBR0lORw0KPiA+ICsgICAgcGFkZHJfdCAqc2wxbWE7DQo+ID4gKyAgICB1aW50OF90ICpkaXJ0
eV9iaXRtYXA7DQo+ID4gKyAgICBzX3RpbWVfdCBsYXN0X2RpcnR5Ow0KPiA+ICsjZW5kaWYNCj4g
PiArfTsNCj4gPiArI2VuZGlmDQo+DQo+IFN1YnNlcXVlbnRseSBJIHRoaW5rIHdlIHdpbGwgd2Fu
dCB0byBkbyBtb3JlIGNsZWFudXAgaGVyZS4gVXMgdXNpbmcgYSBzaGFkb3cNCj4gbW9kZSBzdHJ1
Y3QgYWxzbyBpbiBIQVAgY29kZSBpcyBib2d1cyBhbmQsIGFmYWljcywgd2FzdGVmdWwuIFRoZSB0
aHJlZSBsYXR0ZXINCj4gbWVtYmVycyBhcmUgdXNlZCBvbmx5IGJ5IHNoYWRvdyBjb2RlLCBzbyBI
QVAgY291bGQgaGF2ZSBpdHMgb3duLCBzbWFsbGVyDQo+IHZhcmlhbnQgb2YgdGhlIHR5cGUuIEFu
ZCBlYWNoIHR5cGUgY291bGQgYmUgcHJpdmF0ZSB0byB0aGUgaGFwLyBhbmQgc2hhZG93Lw0KPiBz
dWJ0cmVlcyByZXNwZWN0aXZlbHkuDQo+DQoNClVuZGVyc3Rvb2QuDQoNCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:44:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:44:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119453.1464803 (Exim 4.92)
	(envelope-from )
	id 1uwbyZ-00018J-5T; Thu, 11 Sep 2025 07:44:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119453.1464803; Thu, 11 Sep 2025 07:44: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 1uwbyZ-00018C-1z; Thu, 11 Sep 2025 07:44:15 +0000
Received: by outflank-mailman (input) for mailman id 1119453;
 Thu, 11 Sep 2025 07:44: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 1uwbyX-00017D-HA
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:44:13 +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 17d24eaf-8ee3-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 09:44:05 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b079c13240eso62081266b.1
 for ; Thu, 11 Sep 2025 00:44:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b317124esm74481266b.46.2025.09.11.00.44.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 00:44: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: 17d24eaf-8ee3-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757576645; x=1758181445; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=13EITH6UPoKNJoOZIRh0oEczIS9NjP3IQCphogYLm4Q=;
        b=GisFM34M7GNR11sd9DTY2qELAbsCew1pdsuLOqy82S/CzwNgW91PNfPvWkro0jgd5k
         BKMo4cI0f6yu9XMbbgFgFnK0O1f2Iw+1QxHbK7LN4Eep1OhFJtLguR9PNbmdeJSiBR93
         QX+eg4zAXtHLfbPjZXROUoPp6QhQiMGGQZxYNcwp7QxSBRGCUWogW8ya95ZKp3oHyXH/
         xid0WqWVnnnUTFtKw5z0D/nBoQb6OfvIGN7w66cIcS6/bneLIP2hbonB48QDbCr697La
         1awFAOprNN1RscGDv1fCl27md8HT/CFwzy6Nr4AvN4It7XeTe8iYphxMZdJk1YhHUFRm
         MEnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757576645; x=1758181445;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=13EITH6UPoKNJoOZIRh0oEczIS9NjP3IQCphogYLm4Q=;
        b=cbkwROkWUWE6rOxVtkPWdZx3sLAkYIxvv6n1oGp1Aa9l/QT/Qa0Wje0Pj4H9lOXoLq
         sonAPrrVvtmso6EQR4ym8N7DYHErg1CwDRLs6JruiDmaNiXtNSt4tOj9fPd+UO6opgNG
         juU4RnqSv/F9+U78qJKwki39KHwkoMDBT7+l0bO/7s+Fa+g0hLAUq/UD/UFlhQfYe9bK
         M69mRP7gQQdqHukjH3zIhIo8XevfAPAqBKxH0Nkc/1/vds90vP5XuFwst3sl5qfi9XSo
         A77Nmwg6oIylBfftNdHq0EnxWqfK6Txz50ML9AGUPj1UY+bT/6UEktjnrz84/POd+UzH
         UQ7Q==
X-Forwarded-Encrypted: i=1; AJvYcCVO7LpgS29js41cHTIcZ+NJ9IefIMXYZKYb+wHFKZa6kSDl6cwW4KqjOWO4JmvjnRCLH6IwQ2bkZQk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBEbtr7Oj1UQjX/+0Uht1bXDRDfRNTzOUOvn8a08JIY/nI8nTk
	pOeZXJDlQ1NznSQim6UpsL26lLZchdjHEXIOOiFYqwYCytl/jVj75SvuGJurfct3Vw==
X-Gm-Gg: ASbGncsG6e0Qsn30Wu4jfqBzaQKFXr5FdzKSutY2QMnpjH3pcRMp/NBmygNhbNw1RZ8
	EKiLd3NN/DIup8MHZL7vXwb9hMQQLkpbSm6j3X/U/JS1aPK2P5Jz+rGiR8oATA+Dy2RZlgCafDy
	eq0+4Z+MJnDVwlNBA++NTGVA3D1jrMpXmpRR/uUUwPQYSgrpjmWeOMc6CD6KTTJG20Pc6OKJTVz
	1XSn+tgwR7z6ixjS33PU8Mt6+1oH0Rw/uam/cZRs0+BJZDpJsKZ+Wjm68FUNWnp+v3rm9FbdgH4
	1NRRQ1gok2odVNOUhwXfdZrGkHsWKacxDjfKosvygqaaF7+oYlSyQ0h7I+/6YnhOFShKXpAuQoE
	HyLuvefm0fAiBCVL5DajnE0ubxGj9AobxomhXTnhut9gc7Wb7+XnYRiUl8w9nZPxjS5JLQkKGdX
	HLqPylHW8U2ex/ZdOvlg==
X-Google-Smtp-Source: AGHT+IEew67QPKjteNM6PENQoGic2kJr0i4aniLjkPqGfDaT8Hrd8JPvgaxSEVMZ608Geg8oP2HWJA==
X-Received: by 2002:a17:907:2d91:b0:b04:3302:d7a8 with SMTP id a640c23a62f3a-b04b16d300dmr1757116666b.58.1757576645156;
        Thu, 11 Sep 2025 00:44:05 -0700 (PDT)
Message-ID: <96b58fe4-668f-44be-9469-0ec7f4f28c6f@suse.com>
Date: Thu, 11 Sep 2025 09:44:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 Roger Pau Monne , xen-devel@lists.xenproject.org,
 Xen-devel 
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
 
 
  
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 19:29, Alejandro Vallejo wrote:
> On Wed Sep 10, 2025 at 7:01 PM CEST, Alejandro Vallejo wrote:
>> On Wed Sep 10, 2025 at 5:31 PM CEST, Jan Beulich wrote:
>>> On 10.09.2025 17:16, Alejandro Vallejo wrote:
>>>> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>>>>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>>>>>> CPU hotplug relies on the guest having access to the legacy online CPU
>>>>>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM, so
>>>>>> this causes the MADT to get corrupted due to spurious modifications of
>>>>>> the "online" flag in MADT entries and the table checksum during the
>>>>>> initial acpica passes.
>>>>>
>>>>> I don't understand this MADT corruption aspect, which - aiui - is why
>>>>> there's a Fixes: tag here. The code change itself looks plausible.
>>>>
>>>> When there's no DM to provide a real and honest online CPU bitmap on PIO 0xAF00
>>>> then we get all 1s (because there's no IOREQ server). Which confuses the GPE
>>>> handler.
>>>>
>>>> Somehow, the GPE handler is being triggered. Whether this is due to a real SCI
>>>> or just it being spuriously executed as part of the initial acpica pass, I don't
>>>> know.
>>>>
>>>> Both statements combined means the checksum and online flags in the MADT get
>>>> changed after initial parsing making it appear as-if all 128 CPUs were plugged.
>>>
>>> I can follow this part (the online flags one, that is).
>>>
>>>> This patch makes the checksums be correct after acpica init.
>>>
>>> I'm still in trouble with this one. If MADT is modified in the process, there's
>>> only one of two possible options:
>>> 1) It's expected for the checksum to no longer be correct.
>>> 2) The checksum is being fixed up in the process.
>>> That's independent of being HVM or PVH and independent of guest boot or later.
>>> (Of course there's a sub-variant of 2, where the adjusting of the checksum
>>> would be broken, but that wouldn't be covered by your change.)
>>
>> I see what you mean now. The checksum correction code LOOKS correct. But I
>> wonder about the table length... We report a table as big as it needs to be,
>> but the checksum update is done irrespective of FLG being inside the valid range
>> of the MADT. If a guest with 2 vCPUs (in max_vcpus) sees vCPU127 being signalled
>> that'd trigger the (unseen) online flag to be enabled and the checksum adjusted,
>> except the checksum must not being adjusted.
>>
>> I could add even more AML to cover that, but that'd be QEMU misbehaving (or
>> being absent). This patch covers the latter case, but it might be good to
>> change the commit message to reflect the real problem.
> 
> It doesn't quite add up in the mismatch though. There might be something else
> lurking in there.
> 
> Regardless, I don't want this junk in PVH. Would a commit reword suffice to have
> it acked?

I think so, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:45:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:45:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119467.1464812 (Exim 4.92)
	(envelope-from )
	id 1uwbzg-0001jf-Hw; Thu, 11 Sep 2025 07:45:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119467.1464812; Thu, 11 Sep 2025 07:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwbzg-0001jY-FN; Thu, 11 Sep 2025 07:45:24 +0000
Received: by outflank-mailman (input) for mailman id 1119467;
 Thu, 11 Sep 2025 07:45: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 1uwbzf-0001WI-F3
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:45:23 +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 447366c8-8ee3-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 09:45:21 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-b0787fc3008so52522766b.3
 for ; Thu, 11 Sep 2025 00:45:20 -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-b07b30da43esm73482166b.14.2025.09.11.00.45.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 00:45: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: 447366c8-8ee3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757576720; x=1758181520; 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=xmGPRKp7wyDkMZLVbkuaXn9JmpRopky+vuOQLMD+HII=;
        b=aOQDNYz5jMSa7ccq6OwfK7GOeLH7PHMHcml8VjuCTQHSg4hPGxUYq6lDeh5mhb/UmZ
         yCwaC09/2EnG9XMW1chdy5A7JC6Wan6ApTfuZNoxsKqoWDlnqrdYn0cXQlzGm45Mnn+F
         aeIjJ8yqbMxPtcQZ4C7ByUF/wlCFYbFCSTUfSGtF/C4hy4yOdqLvGOOImK71QcRu8J1R
         huDPgVTva7sV0yFyPqixJC/4GJFt2mEcbPawE2DlHysC8K2oKzVkNvfyK7AirItSf+7h
         c8EbC+A6Fq36hzPxDAncUThKyrdXiK7wCiSP8dIjO0GKy1iWYs48o74QSuWOQd8mkpDI
         aMeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757576720; x=1758181520;
        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=xmGPRKp7wyDkMZLVbkuaXn9JmpRopky+vuOQLMD+HII=;
        b=VMV92RqjVIWTj3YxAF8Zo+lKzEewLdOG/OodFXLy1duYtugJyGZ1KC42uvwd7xKi6y
         31XooZJvbEupeH0RbXSFZACsDfPJ2Z3QVlUX5mqB+ANkXe9v1TkC/otdCiUaiZYMti+S
         3fnY2kfZ7t/lMAIsqlyf5+Sw1wqAan0oSiq01cbWnS1ggeFt03K6Cfr/rdjse5MLDkoc
         tTXW7pFmxhnfiKfCItWP4LkCQoGaq1yORupdFh6SKo0Uv5FKKx4nttfTno4hSnOmr6hx
         FO0U1P+E9KMhfcBxFCErDfZj3K07HD8KsVQPdeXAhibRe0zIJ2xuy0dvYppuhxCeOwCj
         p0FA==
X-Forwarded-Encrypted: i=1; AJvYcCUiaslQhGREfETf8qI5/YOGevaZcxU1inU9+7H2+5ljnrG1kGO02MErOvk0+j+E7n582vH/Ur1Dszw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyxi5U1Koz+Lew6Ly2XAXLicTTEduI5+1e343DDJdot1e11rQXG
	inmU1gtYbGIAcgeG0//htmd3weVD2jwYTfMwUKBvf/CmoiRGNf6dL6Vw
X-Gm-Gg: ASbGnctb0wQ9jgjKhGLcAHDY4vszJXV9lOfwzIWOYm53cX6k6B/52yItiv30dnh5YGF
	Q/s3LLuKsnm8ZuO4eBqTVn9oTby4qWtG1ZWxJh9zCUHOPAJP4aHOziCq017+gV/jOSmrV2Sqoum
	85Os1FsdwxK64yEKoi/mY5ixWqh6EHd3oVFLtMIzQCfmMHlp+Zk1NYATnZWnqtvdydpsjahVAmU
	Y8hScJcKWWLqA43Thx8SO11kIME+9zClQLo+MLj4HoLfGt/a3HbwjjAsoJElKXHHVn7yAyk6cYh
	MYz7S1a+Qt4ZfJJFOh/nfEIUcIql/7FN1o1xtOb51/lqi9w1PuhOAA8N+07HxHNF78reQ72poF9
	dH5KvrVkS+vCrxGN+1pKX47TP9bEGEOUSk9mAjuMl0A9EHLcvsAxe8s3/wm1BodoR9TB94oig
X-Google-Smtp-Source: AGHT+IGesPJpsrn25kj+9GrTGFTO0cu3anl96ByXKb+08bSpeNLljpU8H38EYhDEXdXAWLMhfRZ73g==
X-Received: by 2002:a17:907:728c:b0:b07:88ef:fe1a with SMTP id a640c23a62f3a-b0788f004c2mr545448066b.40.1757576719847;
        Thu, 11 Sep 2025 00:45:19 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------nh800EQ0QKFzbDBJVeyaxtB7"
Message-ID: <95737e6b-0834-45e0-b8a4-f3f9cd2717ae@gmail.com>
Date: Thu, 11 Sep 2025 09:45:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/IO-APIC: drop setup_ioapic_ids_from_mpc()
To: Jan Beulich , Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "consulting@bugseng.com" ,
 "xen-devel@lists.xenproject.org" 
References: 
 <034dd6dd-4e3f-4353-9a11-7a0ebda9a664@suse.com>
 
 <3c678b60-4e1d-4c51-bfe4-efe3acee4e8f@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <3c678b60-4e1d-4c51-bfe4-efe3acee4e8f@suse.com>

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


On 9/10/25 3:36 PM, Jan Beulich wrote:
> On 10.09.2025 15:26, Andrew Cooper wrote:
>> On 03/09/2025 8:55 am, Jan Beulich wrote:
>>> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
>>> said, the function is dead logic as well: All 64-bit capable Intel systems
>>> have (at least) xAPIC (if not x2APIC).
>>>
>>> Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
>>> code; we didn't accept that yet, but - where possible - we probably would
>>> better follow it). Depending on one's reading, this code may actually be a
>>> violation of rule 2.1 (unreachable), which we did accept:
>>>
>>> "Code is unreachable if, ..., there is no combination of program inputs
>>>   that can cause it to be executed."
>>>
>>> Otoh it's "only" __init code.
>>>
>>> Signed-off-by: Jan Beulich
>> The code change is fine, but the commit message should be first
>> paragraph only.
>>
>> The first paragraph is plenty of justification to make the change,
>> irrespective of anything else.
> Well. I wouldn't have added the other parts if we weren't where we are in
> the release cycle. Strictly speaking, with them dropped I can't put these
> two patches in right now. Oleksii, may I ask for your view please (on
> both of the patches, as they're both similar in this regard)?

For both patches, I think it would still be useful to retain the explanation
about the MISRA Rule 2.2 violation in the commit message. While I agree that
the first paragraph provides sufficient justification on its own, the additional
context helps clarify why we're committing this change now, rather than waiting
until after the release. It also highlights the additional benefit of improving
MISRA compliance by removing this dead code.

Anyway, I am okay with having these patches merged now:
  Release-Acked-by: Oleksii Kurochko

~ Oleksii

>
>> The other 3 paragraphs are musings on an area of MISRA where which is
>> unclear, or even disputed.  The code here is statically reachable,
>> dynamically unreachable, and trying to argue this in terms of dead or
>> unreachability detracts from an otherwise clear patch.
>>
>> With a very strong preference to have the commit message be only the
>> first paragraph, Reviewed-by: Andrew Cooper
> Thanks (also for the one for patch 2).
>
> Jan
--------------nh800EQ0QKFzbDBJVeyaxtB7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 9/10/25 3:36 PM, Jan Beulich wrote:

    

    

      
On 10.09.2025 15:26, Andrew Cooper wrote:


      

        
On 03/09/2025 8:55 am, Jan Beulich wrote:


        

          
Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
said, the function is dead logic as well: All 64-bit capable Intel systems
have (at least) xAPIC (if not x2APIC).

Even if Eclair can't know it, such code is violating Misra rule 2.2 (dead
code; we didn't accept that yet, but - where possible - we probably would
better follow it). Depending on one's reading, this code may actually be a
violation of rule 2.1 (unreachable), which we did accept:

"Code is unreachable if, ..., there is no combination of program inputs
 that can cause it to be executed."

Otoh it's "only" __init code.

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


        

        
The code change is fine, but the commit message should be first
paragraph only.

The first paragraph is plenty of justification to make the change,
irrespective of anything else.


      

      
Well. I wouldn't have added the other parts if we weren't where we are in
the release cycle. Strictly speaking, with them dropped I can't put these
two patches in right now. Oleksii, may I ask for your view please (on
both of the patches, as they're both similar in this regard)?

    

    
For both patches, I think it would still be useful to retain the explanation
about the MISRA Rule 2.2 violation in the commit message. While I agree that
the first paragraph provides sufficient justification on its own, the additional
context helps clarify why we're committing this change now, rather than waiting
until after the release. It also highlights the additional benefit of improving
MISRA compliance by removing this dead code.

Anyway, I am okay with having these patches merged now:
 Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii


    

      



      

        
The other 3 paragraphs are musings on an area of MISRA where which is
unclear, or even disputed.  The code here is statically reachable,
dynamically unreachable, and trying to argue this in terms of dead or
unreachability detracts from an otherwise clear patch.

With a very strong preference to have the commit message be only the
first paragraph, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


      

      
Thanks (also for the one for patch 2).

Jan


    

  


--------------nh800EQ0QKFzbDBJVeyaxtB7--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:48:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:48:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119493.1464823 (Exim 4.92)
	(envelope-from )
	id 1uwc2j-0002YJ-0Y; Thu, 11 Sep 2025 07:48:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119493.1464823; Thu, 11 Sep 2025 07:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwc2i-0002YC-T1; Thu, 11 Sep 2025 07:48:32 +0000
Received: by outflank-mailman (input) for mailman id 1119493;
 Thu, 11 Sep 2025 07:48:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwc2h-0002Y3-TT
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:48:31 +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 b4ee4953-8ee3-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 09:48:29 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b04271cfc3eso49158666b.3
 for ; Thu, 11 Sep 2025 00:48:29 -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-b07b32dd47bsm74004666b.58.2025.09.11.00.48.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 00:48: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: b4ee4953-8ee3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757576909; x=1758181709; 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=3OiiKyOJFvu6X5z3RLlId/CdIpqvtrIsJnYhRupUhuc=;
        b=jt9nMAYZep88oDS9pFHT0qwLDvmEJ9riyLavdvb7Fc6BhHOUnqyXBjfxHEuHmGK5HB
         X4g8Bf3QN27Ya6D9Ldu7527MxkcOelOmxu1XR6ckJAR/q0kCzc1BFge3q4CpTgkknVSt
         wMeEhm3Ib2kKOh+Gw8F3pi5SaUqw/4vdDI//x5QI1YoS9llepvL1EeQlxTpRU4BIRJuM
         WzP2e1P6iKsSB0dpzoGyWjj9B1Sjwdd/AjZM2Sib1mSxlMA98j/XVjMfQ3cFNgb69+dY
         mLOxkDY82EdWWssPeuGoy2TDyOi/hYAXDALRbzlHTJK+VydtGUvzoOtPXvO5ri9KPPms
         eTzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757576909; x=1758181709;
        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=3OiiKyOJFvu6X5z3RLlId/CdIpqvtrIsJnYhRupUhuc=;
        b=Qh64NiNGiqeveIDdm/OcVOGQNQIgoels+nM/me4Z8afMIB7TQIJ2dRumCgrzhlFQfI
         c5aMb4iVWVA51GS8MT246HMoNVnjXbCbEtb6N98/Fi/UBboVixu5ZIm/h71ZmWXHOvru
         OPgS8kTYJ1r7WnTT+oiY9CwSeuH/fgVx+CqqHMtkDb/Ty3hP8P6u6+3BXgmH63KzZLX6
         UccIG7WfuEQf4G5OXjXbp7xSX3CUJs7uCa4jl5LKshFsJI8YwYCcuElXX53p83yXndKc
         ak9DSCbjlEsgq/mbz4sRadU6EDe8b3o8K2Qh7oL65NEbqjemLTM4HJ4X+Um8JPeHGIAs
         GNfw==
X-Forwarded-Encrypted: i=1; AJvYcCWKIccyCGnmZ+DtLg7OwFgxsHjvPPVCaJ+VKjzbmUro6+mEfea93b8YyGGZWYP0n73g9tzAGnGcTDs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxhh8eJ4KP+uuO0zDFWhrk/R7Y0mI8jBi/Enjq2YumjTJUHWK3E
	a/gBen/A/oW0qgrsgBhZZF/uAF2iu6NwKtsk4/bYHJ6FLMOgeHbeh9kE
X-Gm-Gg: ASbGncs9DmMTdhADw5KZxIenANxuD5PrC4T1JSnrPh5LAyVQnEmqkcQqJy6ENt5POnV
	IT4aqmoJLlZKoQ+wj8iLCyMFiojzAbtkVnF3fLvQUXlI4lEUNXtLXtMAhesh12ncnO/++rMhCo1
	292TZ16+ReQF8cEHp5QY2rKX/pXTPY24f3SmrzqYZMmyTrAJXqX89Rxp3fEYPV5lQZdrqN3qqW5
	HTxCir27YlMI58s9NaY3kNUUZJmHmG++ePqo79vnjvQte41yCmblOBzCEnovpVtM6pUcwzeQLU2
	Sk4IWFetgn2OHM5FdUoSxVjFHMcOG/CygerFAE14LQ65zcs7LeOqi4aAGFiE8lgl5kPPZJdjRCX
	8WuuZGgv9XG4GH1g/YHmcbdvdlbIYNKGTfytaPG0jjoZ+0hWnR56m7l70gQy7DXASd0FumCc+Ev
	xFcUVarZI=
X-Google-Smtp-Source: AGHT+IGk8SQOHJgNbkyjJVrzJcbajCl74dCdOvXFBC/bfymBLqk8YIRaQjtESD1XgTI3lS3LgdLEqw==
X-Received: by 2002:a17:907:9810:b0:b04:a1ec:d073 with SMTP id a640c23a62f3a-b04b1437db2mr1808993766b.18.1757576908567;
        Thu, 11 Sep 2025 00:48:28 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------tBtFFG0xJgK5YRGK3Yb0Ut2a"
Message-ID: 
Date: Thu, 11 Sep 2025 09:48:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21 0/5] CI: Add Debian Trixie
To: Stefano Stabellini ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Cc: Andrew Cooper ,
 Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Shawn Anastasio ,
 Doug Goldstein , Victor Lira ,
 Samuel Thibault ,
 Juergen Gross 
References: <20250809221206.1260861-1-andrew.cooper3@citrix.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/9/25 11:53 PM, Stefano Stabellini wrote:
> On Tue, 9 Sep 2025, Marek Marczykowski-Górecki wrote:
>> On Sat, Aug 09, 2025 at 11:12:01PM +0100, Andrew Cooper wrote:
>>> I know it's past the last-post deadline, but Trixie was only released today.
>>>
>>> In terms of backports, we should at least go back to the bugfix branches.
>> What is the state of this series? I'm preparing refresh of my various CI
>> series and some add more jobs on debian-12 - I wonder if I should make
>> them debian-13 already - but for this I need this series committed...
> I have been too busy reviewing the non-gitlab patch series for the
> feature freeze last Friday and we have a couple of series still to
> process.
>
> Maybe gitlab-related series could be committed also past the feature
> freeze.

It makes sense to me. And I think we had such conversation somewhere else.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/9/25 11:53 PM, Stefano Stabellini
      wrote:

    

    

      
On Tue, 9 Sep 2025, Marek Marczykowski-Górecki wrote:


      

        
On Sat, Aug 09, 2025 at 11:12:01PM +0100, Andrew Cooper wrote:


        

          
I know it's past the last-post deadline, but Trixie was only released today.

In terms of backports, we should at least go back to the bugfix branches.


        

        
What is the state of this series? I'm preparing refresh of my various CI
series and some add more jobs on debian-12 - I wonder if I should make
them debian-13 already - but for this I need this series committed...


      

      
I have been too busy reviewing the non-gitlab patch series for the
feature freeze last Friday and we have a couple of series still to
process.

Maybe gitlab-related series could be committed also past the feature
freeze.

    

    
It makes sense to me. And I think we had such conversation somewhere else.

~ Oleksii


  


--------------tBtFFG0xJgK5YRGK3Yb0Ut2a--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:48:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:48:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119497.1464833 (Exim 4.92)
	(envelope-from )
	id 1uwc32-0002ye-75; Thu, 11 Sep 2025 07:48:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119497.1464833; Thu, 11 Sep 2025 07:48: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 1uwc32-0002yX-4Y; Thu, 11 Sep 2025 07:48:52 +0000
Received: by outflank-mailman (input) for mailman id 1119497;
 Thu, 11 Sep 2025 07:48: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 1uwc2w-0002Y3-L8
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:48:50 +0000
Received: from casper.infradead.org (unknown [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bcd08802-8ee3-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 09:48:44 +0200 (CEST)
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]
 helo=noisy.programming.kicks-ass.net)
 by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
 id 1uwc2T-00000006tc7-2uQY; Thu, 11 Sep 2025 07:48:17 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
 id 455AE3002EB; Thu, 11 Sep 2025 09:48: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: bcd08802-8ee3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=U+zkD5dacXBFakf/sW3Py81BzX7lYGPL/ab+J9kqcdg=; b=rVrDSFK0bpnhi1r1s83os8o7QQ
	XayC14Rrw5fJaPANeMNniOrj8N2qlmXZE8oUJBQvG5kSAFrlNf0KMvYQRq0gk7u/1f3wItoWc/zSx
	gMRY+yKQ4sBjLvyySadOCkXFheZQ+DVX5dcy+Kawt4/VDIAADK8mtsP0tEVBlVeM6n5nliW9J5by5
	qcxvNNuHTHH3MFrkCcD3e1F5nHscsfjsTcYJksi3IX2HuJ8nFMSKL67BI8jxt/ELGL2WX0z4ME16L
	/SA7AkX24vu99JNGByq6XvVm5ZTsSUxhQ+ASMeIgwxmdEKvg7dsn3+Ahm1ViJVrCJYH4ibFHmaxtg
	rAsWgZlg==;
Date: Thu, 11 Sep 2025 09:48:17 +0200
From: Peter Zijlstra 
To: Juergen Gross 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
	loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
	Andy Lutomirski ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu , Dexuan Cui ,
	Will Deacon , Boqun Feng ,
	Waiman Long , Jiri Kosina ,
	Josh Poimboeuf ,
	Pawan Gupta ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Russell King ,
	Catalin Marinas ,
	Huacai Chen ,
	WANG Xuerui ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou , Alexandre Ghiti ,
	Juri Lelli ,
	Vincent Guittot ,
	Dietmar Eggemann ,
	Steven Rostedt ,
	Ben Segall , Mel Gorman ,
	Valentin Schneider ,
	linux-arm-kernel@lists.infradead.org,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Daniel Lezcano 
Subject: Re: [PATCH 00/14] paravirt: cleanup and reorg
Message-ID: <20250911074817.GX3245006@noisy.programming.kicks-ass.net>
References: <20250911063433.13783-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250911063433.13783-1-jgross@suse.com>

On Thu, Sep 11, 2025 at 08:34:19AM +0200, Juergen Gross wrote:
> Some cleanups and reorg of paravirt code and headers:
> 
> - The first 2 patches should be not controversial at all, as they
>   remove just some no longer needed #include and struct forward
>   declarations.
> 
> - The 3rd patch is removing CONFIG_PARAVIRT_DEBUG, which IMO has
>   no real value, as it just changes a crash to a BUG() (the stack
>   trace will basically be the same). As the maintainer of the main
>   paravirt user (Xen) I have never seen this crash/BUG() to happen.
> 
> - The 4th patch is just a movement of code.
> 
> - I don't know for what reason asm/paravirt_api_clock.h was added,
>   as all archs supporting it do it exactly in the same way. Patch
>   5 is removing it.
> 
> - Patches 6-12 are streamlining the paravirt clock interfaces by
>   using a common implementation across architectures where possible
>   and by moving the related code into common sched code, as this is
>   where it should live.
> 
> - Patches 13+14 are more like RFC material: patch 13 is doing some
>   preparation work to enable patch 14 to move all spinlock related
>   paravirt functions into qspinlock.h. If this approach is accepted,
>   I'd like to continue with this work by moving most (or all?)
>   paravirt functions from paravirt.h into the headers where their
>   native counterparts are defined. This is meant to keep the native
>   and paravirt function definitions together in one place and
>   hopefully to be able to reduce the include hell with paravirt.
> 
> Juergen Gross (14):
>   x86/paravirt: remove not needed includes of paravirt.h
>   x86/paravirt: remove some unneeded struct declarations
>   x86/paravirt: remove PARAVIRT_DEBUG config option
>   x86/paravirt: move thunk macros to paravirt_types.h
>   paravirt: remove asm/paravirt_api_clock.h
>   sched: move clock related paravirt code to kernel/sched
>   arm/paravirt: use common code for paravirt_steal_clock()
>   arm64/paravirt: use common code for paravirt_steal_clock()
>   loongarch/paravirt: use common code for paravirt_steal_clock()
>   riscv/paravirt: use common code for paravirt_steal_clock()
>   x86/paravirt: use common code for paravirt_steal_clock()
>   x86/paravirt: move paravirt_sched_clock() related code into tsc.c
>   x86/paravirt: allow pv-calls outside paravirt.h
>   x86/pvlocks: move paravirt spinlock functions into qspinlock.h

With the note that tip typically likes a capital after the prefix, like:

  x86/paravirt: Remove unneeded includes of paravirt.h

For 1-12:

  Acked-by: Peter Zijlstra (Intel) 


Now, as to the last two, I'm not sure. Leaking those macros out of PV
isn't particularly nice, then again, not the end of the world either.
Just not sure.


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:51:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:51:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119517.1464843 (Exim 4.92)
	(envelope-from )
	id 1uwc5G-0004YG-Jb; Thu, 11 Sep 2025 07:51:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119517.1464843; Thu, 11 Sep 2025 07:51: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 1uwc5G-0004Y9-GX; Thu, 11 Sep 2025 07:51:10 +0000
Received: by outflank-mailman (input) for mailman id 1119517;
 Thu, 11 Sep 2025 07:51: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 1uwc5E-0004Y3-Hm
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:51:08 +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 128e78f6-8ee4-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 09:51:06 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-62221568039so528741a12.0
 for ; Thu, 11 Sep 2025 00:51:06 -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-62ec33ad2d6sm658964a12.18.2025.09.11.00.51.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 00: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: 128e78f6-8ee4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757577066; x=1758181866; 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=3MofUxMIU3nSs2OBHcSvaghiWRwiNziBj+Blr4k+xrA=;
        b=GiyhDVeJ82pBweA1axtprl/6hm9K2NYprZYBQZcDMHXZM/LsZXsnYAR8eBBgkPXM/f
         ywdCP5IuzbDIBvqQ8aa6s27rXuYCa5U5kOArohtQUl/vV9EJMPND7CbJ+fjNXmsSYC4v
         6/MRUdNdsAFhKOxqOXknWXN4j7fMkqvmh2JGZKMSXocMoPIn7slRGkFHW4/YfNLa61XI
         zLnSAMuGQuG0khJmkKMQ17VKjr4OD/i4sjHWfPN6RmE6srU2iAo2rogT6v8nftRPSHVh
         1PwK60wvfpSCtHgLkv/PTGjG9XaZpioq73//Kxxb4o7i76FaNjedCcRJZ0uLuCmZBrhP
         bTng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757577066; x=1758181866;
        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=3MofUxMIU3nSs2OBHcSvaghiWRwiNziBj+Blr4k+xrA=;
        b=OjkZrPjLyh1rmdvHJAEkywcxtpCcL7CPV4ANl1u8GhKdnnGB4Rr0DT2nwIuGNwkFNP
         A3iWsUguWrODQIc4nLqb/vhJHQhMjNFrmkuUN1B1CCR4heU6VixoVyGkmGd/lUH7wnto
         AnF0gBJzLGcOzwE45/+dQWvYoT1fE80ydSehKkplRyg39rvb7+aHAjQVYUvRV36oWlx9
         sY/XClCeMZfjVeJZvcCndsUtOr+rQEZW7Ju4dpmgCwgzcClUebUg4X7ehp3Vo+WxXhpE
         ltIbCNCkcfWcUoy//ouY4bdJII0Hf5kwPJz5UMguLh5MOeBFn75zQkJGxxw5MI6C36Vx
         bJCg==
X-Forwarded-Encrypted: i=1; AJvYcCWdVIm3JWr21AJFrEDKQtAR100VWWNvpE6wwRU/3V0cqsFLRRVccFtadselTCLUFx/Du6DhrrN7miA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyqjeTu1ldByCm7aN2sW5izQAhdpRYCneJejTRFIYciWdf8lPRB
	rNXw7qHRn0m7V7o+9ZZDycQV+DW1wvhmxhbUi5/Oco5eFDFXlVkfVUgTxNEKEQ==
X-Gm-Gg: ASbGncu/+Bh6Pk8KdIaODo9atP4lsqlWx/FJTeSkcKJ0ijp9zMyYMqFPg4RxH+OEKfb
	ucwfUjtpsK50hSdBjvr5k2hVIbAvm95e7sXTleYkVEaludPJvTjflIJFdk8YLhV+2Rn8l79IXrc
	sH2wF5NHck2GFEY6DX+Gtq04zOQA4MWbWH2i+Hmho8lGe5Wf9FtfZdoY88cRO37qs76sakKDaZV
	Dx9me/GCzFdSp0i4T0oM6FzpYeP6yJovuEvvx6N40H4dlRAo/c5OWUqSuosKJsak/9vpIIdNdAS
	/8JDdz1X4PAavadp6w2AIpAAs7n5BvyGdhKKbPxklbruhbW0AMMj5T7Cr6oqmyV3b7+81dQ8lwi
	WC+fE2wqmkQgUMuQPY1f3z6dZg2mmuTKmlzi2DkJHtsWNGBzU65CPIfEZr211p7nrkXZrkAf2
X-Google-Smtp-Source: AGHT+IGxDQcg2tUf8709VzIaMOZF5znxCRYuOQOgbOKN+HvF/61Sjz01pp9iy48Xvh5Cp/zwyNtWPQ==
X-Received: by 2002:a05:6402:2806:b0:627:1120:f824 with SMTP id 4fb4d7f45d1cf-6271120fc43mr14310224a12.17.1757577065682;
        Thu, 11 Sep 2025 00:51:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------DXL1HUsGUfi9OKC3KFyjjzdG"
Message-ID: 
Date: Thu, 11 Sep 2025 09:51:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] CHANGELOG: Notes about distro changes in CI
To: Andrew Cooper ,
 Xen-devel 
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
 <20250910222313.1858941-4-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250910222313.1858941-4-andrew.cooper3@citrix.com>

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


On 9/11/25 12:23 AM, Andrew Cooper wrote:
> Also state the RISC-V baseline now it's been set, as it's the reason why
> RISC-V Bullseye got dropped.
>
> Signed-off-by: Andrew Cooper

LGTM: Acked-by: Oleksii Kurochko

Thanks.

~ Oleksii

> ---
> CC: Anthony PERARD
> CC: Michal Orzel
> CC: Jan Beulich
> CC: Julien Grall
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Oleksii Kurochko
>
> v2:
>   * New
> ---
>   CHANGELOG.md | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 7bd96ac09d14..ca1b43b940d2 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -10,6 +10,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>    - The minimum toolchain requirements have increased for some architectures:
>      - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
>      - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
> +   - For RISC-V, GCC 12.2 and Binutils 2.39
> + - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
> +   to the baseline change.
>    - Linux based device model stubdomains are now fully supported.
>   
>    - On x86:
--------------DXL1HUsGUfi9OKC3KFyjjzdG
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 9/11/25 12:23 AM, Andrew Cooper
      wrote:

    

    

      
Also state the RISC-V baseline now it's been set, as it's the reason why
RISC-V Bullseye got dropped.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

    

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

Thanks.

~ Oleksii


    

      
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

v2:
 * New
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7bd96ac09d14..ca1b43b940d2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -10,6 +10,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - The minimum toolchain requirements have increased for some architectures:
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
+   - For RISC-V, GCC 12.2 and Binutils 2.39
+ - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
+   to the baseline change.
  - Linux based device model stubdomains are now fully supported.
 
  - On x86:


    

  


--------------DXL1HUsGUfi9OKC3KFyjjzdG--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:55:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:55:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119544.1464853 (Exim 4.92)
	(envelope-from )
	id 1uwc90-0005D8-5a; Thu, 11 Sep 2025 07:55:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119544.1464853; Thu, 11 Sep 2025 07:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwc90-0005D1-2v; Thu, 11 Sep 2025 07:55:02 +0000
Received: by outflank-mailman (input) for mailman id 1119544;
 Thu, 11 Sep 2025 07:55: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 1uwc8y-0005Cv-UG
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:55:01 +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 9c461cc9-8ee4-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 09:54:58 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DM4PR12MB5817.namprd12.prod.outlook.com (2603:10b6:8:60::21) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.22; Thu, 11 Sep 2025 07:54:55 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 07:54: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: 9c461cc9-8ee4-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vmvaiaOP3E8XfOtCefa0mZXnULGUzo5mjG/4H2Cl7PECofTQdKLJejzvvx/T4bKHJv8OhLpOrdzJlkkIkDgQ7HyPVPNqXkch96PmMVJphcFAUHmBdqdw8IljD2ASz1J4WvQZj9MnbJfm/RBAdHzYanPKtNHH6xyuvKOVHVh2r6mmZEEOJHfkBdpD2gJ3nI4ecQT8qhkVOWpS+RNzdo3OuhexIIsr8a3KVmgHckf7b7zNGmTKciSZr2g0rGUy+1jFipOZspEbs1u+GoUX4xvMdFBs+MkamZ+j08rixAjj4T+Tiy0A9s5Vg+UCA2cRrQsSDoorDwVuFLquOYbdO9X+/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=JDzPS/Z2uaPUG4een3NzAEtR6RDB+qL4qcB85Dcl/So=;
 b=FuwqKiQbRocREBy2NSWFhV7iWC8s/q1jqpTP/QJ4/v94uyI1Nu+hm69zOl+c0KDI1NHrBkY8s93TB94/AQlkmE1l8czwWuI+KnYEdzYqFJ4HmKAHdgyYd+fMb3kyc5lrjjD8BqWG1mNvgRc81dofqtJHQn9CRTT3PqgkjwRDQRny4RDI1Vy/o8DglTmnuei3agdYAhC0EyB+IPvnTO0BUWjjIJKywOnuuYQgKClJXgyz3k32Un8CJjpZdgUvxBLDv50jubncNiBxcEZ2HuxkwxkaANqSZzFD7drWnIfKPh+rZeraNEf1vJyAUjAQvH5xIGLJv4s9ALWgVtaWMnvx7w==
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=JDzPS/Z2uaPUG4een3NzAEtR6RDB+qL4qcB85Dcl/So=;
 b=eBiusMkuCXmMr9YF/CyAB3J5+j9MwLYYwcr6uy01+rhXtlmnI4fjKVXg/xguKetIKNl8xLPUI6fjAWvYFZ9mGetFUJPenq4oQ1T24AN05u8Lg5S96rpztc6/gRpN4zkgW2GFprvXXM7NdqD8xgALv9u4dtRG13b/eXgBPdS4fUU=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
Thread-Topic: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
Thread-Index: AQHcIiYBT2pZeRIoyka2sfY1lhJyobSMdHkAgAEcX0CAAAljMA==
Date: Thu, 11 Sep 2025 07:54:54 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-4-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-09-11T07:06:27.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_|DM4PR12MB5817:EE_
x-ms-office365-filtering-correlation-id: 18cbeb89-61c1-4fe3-e330-08ddf1087efd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?b0RNRjdseTNwTWIxYlBDdmxxYTJxV0cwYVpvaUxURlJpKzhPWjN4eVFUeWlp?=
 =?utf-8?B?NWNuQ3QzM2JMY25RQXRUdHNOQnBuL2J1aG92czYvdS9McHR0Qk83eWVCMWc3?=
 =?utf-8?B?ZVUzZlZpRTVuQmd3T2pka3BlUzh1ZVZvOW9aK2syeUFvaC9lMGRzRXdDVG5D?=
 =?utf-8?B?STRZUVcrTko0cEpYTEpORGJJcUt3a1EwQlV1QURsL3ByUFNLUDVhTzd1aThr?=
 =?utf-8?B?dHluZmdqdStleUU5KzNRRUFQRVJyYm1nU2NSU0dVSklIbDlHT2pXQ090K3FM?=
 =?utf-8?B?c0Rybmo2TFVlcU1YaXZBRUVHSitYZDRJTFBacXlCV0F4NFlDUkJqYmI3OHN2?=
 =?utf-8?B?eTVVNXphaXF1aVlGVTZEKysvaE5QcHltQVQwYi9HSHFlWGR2K2tnbks3cFpH?=
 =?utf-8?B?cytpNTBYV2RmYjlBZHMwajNzQ05DNTk1V0wvcWNuTG9BMmpYNHRTczkwRTZl?=
 =?utf-8?B?TEoyaXBLaUJBZDRWN29sbXZZTENQRm8zY2xiVWw5ZDdOUGJYeHBrOUVNUjY4?=
 =?utf-8?B?SzVZUUo2WmZlc3hycy9YVVp2aTZSei9XWG1SL2NoaGdNQVhSU3ZaVzJKUFdV?=
 =?utf-8?B?VnlKNVRGL0pwRFJPeGE4OHM4NlBxOXoyV25GUGFXckVOU2dGaEp1MTh0R1pa?=
 =?utf-8?B?ai9BcXNndkpRcDV1NmhSUU1EQUUrdXd6bUx1N3RqdDVBUDl6cWo0SUJ4amtC?=
 =?utf-8?B?WnpNeG9YdW1UMFFudUx1cWFXU2ZSNVkxYlVrT2tHTnJvZ0g5bzkzSEk2SmZQ?=
 =?utf-8?B?Y1FyZXVuRlhMdVEwZ3Q1dzNMMjlUWDV5TUVYU3NBQ042T2tJeFlRRGRGeTRJ?=
 =?utf-8?B?c2FNWk9uUUhlS3ZoTWp3dlZyRlRjY2ttaXZEZkdZZHNCT0M3MlVlQTZmMjlN?=
 =?utf-8?B?TlVxL3QxcGI4bjY2VUdiZmNHMmEzemhOMVg1TVRRay9paEN2SERMZDJwZ0Vz?=
 =?utf-8?B?MGZ5VlplbDZPdzVoQzZIaWZ2Z0VLQmprNGYzV3BpSHNqSS9kUFVJZ1M3c3ds?=
 =?utf-8?B?VHFySkU2ZHN1WWswdng1OUZRS1pVOUs4TWhxRjZRRGx0RG9TRkRpemNBQ3FF?=
 =?utf-8?B?TXozMmsxNVQreERTYnZFOXJWdzV6TzNpUHVvQWp2WE84Y2YwVHdCcGJVYkVW?=
 =?utf-8?B?U2k3ekxCT3dkbFU3QTdhTEhQZkZrWDA4M1puZyt1bElDSzgySWE2eFdZRDV3?=
 =?utf-8?B?ZFE0ZHYxU2JkUks5M1hGalVIbjc3WHNYM2loMDV2TXVsYU8wVi9kQnpiaFRU?=
 =?utf-8?B?STVXZFg4RklweWlGa3U3cDNXZXV4eVpRWDVraFk5T0F1aFhRVFpyelVJRW16?=
 =?utf-8?B?WjVjR29HaUxDSTRJUzdvTitaWGE0dWRiM3ZiT0xSbDBPTW9ITTQ2ckluOHQz?=
 =?utf-8?B?TDRNb0g1WHlpUzUyclFZaEZKZ2p4eTlHV0xKeXBpWjVleXJZNU45WlM0aVVS?=
 =?utf-8?B?WVExU3Y5M3lkZm0zbWFNelZ1ZzR3cjBEcUhiNW1jdnFQQlNQMU9XeFQ4c0tk?=
 =?utf-8?B?b0E3eDU3bTlSZE5tT3ZoNStUZjg3c3NvSTRRTW5CVm00SWtIbWlPTk1BMmRR?=
 =?utf-8?B?VzRicWJTcE1wT1ZiZTQ0LzkzTTAwYUN3YjIza2w5eXV3NEFnSlQrN25mbE82?=
 =?utf-8?B?QjBRYlo5Mm13Vy9VeWFGRDdwMzFHVDJUTmo5WlRIaHRXNjRIUWViUFozWktO?=
 =?utf-8?B?VjlZREpDbFVEb3NkY1g0bFZDL0VMQjdvaWtoWWF3VWFIR29QaUcyRDBLaFlz?=
 =?utf-8?B?YjA1bGdrZkZxa3NRSHVEMXhoN0xseEQ0dkRVc0sxK1VnYTd5QytjbkxHUWJO?=
 =?utf-8?B?ZlBobUN6bWloQ3ZoM3ozZUVNbUpNOGdueWczYkRYSitiQ1VtRFBCbW9nZGRr?=
 =?utf-8?B?NlQ2SGNsaDJORUY1V3Y0RjloSDEvZmt3RUFTSDdlOFBsc3RkZjVUb1Z6LzE5?=
 =?utf-8?B?UzRWVEhzLzZWK2dhWW9jUStUeGFQSFVOSUFIU2lYMDZodFZYNnA4OTYwYnhq?=
 =?utf-8?Q?J3Bo4fttah0rD6mZhbDC6sGbByrkFM=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TzQzQ1l6NGJjekhVZEc2THlKVmV3NnlRMnU4ckhhOVNJYTBTeEE3VUJBUllw?=
 =?utf-8?B?aHZYRytkaEc4SXdNYTZVejhJbzlZL3prTkUrOXVzbXhjUTNwRXA5YVU2NEsy?=
 =?utf-8?B?YXRsVjJWdmJSem4wSGpLQldjSGdsRU13UTIzTVhvZDNEYnNvcE5XQzlyRlAz?=
 =?utf-8?B?ZGlLR2JkN0djNlhVUjcyazZQaTc5WjA3L2pFZkpYMzNtbzNtVHFHMk5wd1FD?=
 =?utf-8?B?YWJPNDg1V25qRUFwREZEWnRHVm9mNWp1R1VDaVZUYUtKVU9JRUs3V0hNaW9I?=
 =?utf-8?B?eVY4bHZ6a3BxVXVsTkFNM29DMWw1cWVUUU5DcHQ2UmdPaDRCV0FBVmJZdTlN?=
 =?utf-8?B?ekkzMm43cWw5MmhWSi9ydVZITE1pODRUTDZCRytiNTdLbGFpUVZINE41QnIr?=
 =?utf-8?B?UjFtU1lGT3ZDTTVvclg0enhqZkpERjZGbEo3MENjV3RLOElBcWVjNXN5MmlQ?=
 =?utf-8?B?Qm1oTVlYUmlXVFdNRTlHRFdRZTVqVGtBbUNTMFd6NzlQOVR2aGFzd1dqUWRw?=
 =?utf-8?B?S1A5Rm44ODNpQ20ra09Gbm5UdUxpUURNbnJRaC9aay91S2c5RmpySlNMWGNH?=
 =?utf-8?B?N0YzYlQzNWRNcWtuZmNJQUlhdzBUelFOSm1EYlJhQmZSZXhURUtRRFdmdVV6?=
 =?utf-8?B?VmpDZU5iWFZoSzA2RW9aRGNVaGw3Uk5yY2NkbnhwZ1dwY2VpWHhEeGZRUnVM?=
 =?utf-8?B?c21MYndXNnNhYk8xSlNGUndDYUZPcnZWdXE4RjhwNkRNTHVOUUtycmw4d2Nw?=
 =?utf-8?B?c3FNZThNRkM1aHByMjlQelpLQTFXazhDL201V0FjTjFIL1hZdHd4UzVnS1d2?=
 =?utf-8?B?dzQ3VUhmei9rWDhHaXEzV3lRYW9EOWt1aWJPalJZd2ltaUdXcllMNjRmekVs?=
 =?utf-8?B?RGh0KzlKYTY3dGhSTlArcEFPaTVHVU00UWQ2Z0tPVlRmK1pnWXJxUklJWWZY?=
 =?utf-8?B?UGduZ0V1VHZNMGNCT0RIY1hhYmlLSVQ3K1lqY01acmwzWGJEOS8yVUlpQU50?=
 =?utf-8?B?dnU0TDlnem4vcDBPd3dvMFcxN1F5ZHVGT0NTUFVOTW9yNGEzNjRmWjJWd00r?=
 =?utf-8?B?d1dOVk0rMytBcTltYktYdTNTT0lraXdKUXJSRmJ1cEt1Y3Ywb3hMWGNMcEV0?=
 =?utf-8?B?YTNwUFg2eVNaMm1EKzhXdFhTb0dTdEhWenR5bEhvR2lGTitraitlcm04RUtt?=
 =?utf-8?B?UXdIOUptcHlFNkJtV2xFUkE3RUtyQlRpaHB1QjNBaXhTblRNQUVyZjNYRUlB?=
 =?utf-8?B?WU82M2llRlRoY2RaMTZEcHJ2R0xZRW41SGJIcVFnOWp1cWFUUXIzQzJ6MmRH?=
 =?utf-8?B?VVpFZ2xHRXRQVVpBZW13bm1jWjZkY3BleTFrMjVONnJYQ2pQeFl5ZGZwOWRC?=
 =?utf-8?B?cU1PUy81cDM2RGlxaGI4dmxFMTduTHoxR3ZFOWRrYlZNdnMrRjVDRWhyVG9Q?=
 =?utf-8?B?OTNhZjA3OHlFUWhFcUlXVE9mWUJ4ZyszRitwS0dPS3NKWHBuRVhOdFp5Q2JW?=
 =?utf-8?B?TWNTME5XVElSbjJ6RXpwWVBsRUEzOXJEekxiNk11ZFFWMFdud2h4Zmw5aDN1?=
 =?utf-8?B?YVFLWUd0RCt1S2ZGajNJZ1FUbm5tSjIxNWMxOWtxbXliS0xOYUQ1REdEbnox?=
 =?utf-8?B?ajNtdWFKSlk1aWN6VS9sT2laWEtMUUM2ajd6SU5vaWlOMWZIOElJMUhXNTN2?=
 =?utf-8?B?dm5DMmdHd0VMeUN1SmZKZXp6RTFmeVZ1SFN4cDZYNjZ4bmwzKzJQc2QwRUpr?=
 =?utf-8?B?ZWlQaE95TlNVb1FYVHU5WktDZXB3aFM4aGdvMUZjS3lmYVNvQVpFMDdWOFpT?=
 =?utf-8?B?MEZrSFdabVZFQWgySzVtdDdWWUxwRkhDbDRsd0k2aU02V01nOWxYcFh1c2JH?=
 =?utf-8?B?U2VYZDB0OXZOMTh6ZC94MEJxUzJGZmpkV3NWTW9nNGFHV1kvWHBWNG1UeFNK?=
 =?utf-8?B?R2tPRDZvUGIxc0wxbm1HeE5jUTIwQ3o0OUR4MFVxeUNOa0NNSG9FQTB6L0la?=
 =?utf-8?B?NnVWcFM2clZ5NHEwYmNZUkRBVHJZdlhJS3g4dkxVelhJckJLRzQzSm1oNktM?=
 =?utf-8?B?TW5qL0p3c2VSbWJvN0VMdnJUWHRhSmFjbDBURzJpd0ZTMEJQQnoxZGJIaU1z?=
 =?utf-8?Q?9/WY=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: 18cbeb89-61c1-4fe3-e330-08ddf1087efd
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 07:54:54.9055
 (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: y7fnukdU/1uctRW8gEklgIjxQiQU7ZAlWqAY2M9AswitQ9+DkYLLHZJziui+N0KP6COqjROWV8mhixMB4wo3ag==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5817

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZW5ueSwg
WmhlbmcNCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAyNSAzOjE2IFBNDQo+IFRv
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IENjOiBIdWFuZywgUmF5IDxSYXku
SHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5j
b20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IHhlbi0NCj4gZGV2
ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSCB2MiAwMy8yNl0g
eGVuL3g4NjogY29uc29saWRhdGUgdnJhbSB0cmFja2luZyBzdXBwb3J0DQo+DQo+DQo+DQo+ID4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxp
Y2hAc3VzZS5jb20+DQo+ID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMjUgMTA6
MDkgUE0NCj4gPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiA+IENj
OiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPiA8YW5k
cmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPjsNCj4gPiB4ZW4tIGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+ID4gU3ViamVj
dDogUmU6IFtQQVRDSCB2MiAwMy8yNl0geGVuL3g4NjogY29uc29saWRhdGUgdnJhbSB0cmFja2lu
Zw0KPiA+IHN1cHBvcnQNCj4gPg0KPiA+IE9uIDEwLjA5LjIwMjUgMDk6MzgsIFBlbm55IFpoZW5n
IHdyb3RlOg0KPiA+ID4gRmxhZyBQR19sb2dfZGlydHkgaXMgZm9yIHBhZ2luZyBsb2cgZGlydHkg
c3VwcG9ydCwgbm90IHZyYW0gdHJhY2tpbmcgc3VwcG9ydC4NCj4gPiA+IEhvd2V2ZXIgZGF0YSBz
dHJ1Y3R1cmUgc2hfZGlydHlfdnJhbXt9IGFuZCBmdW5jdGlvbg0KPiA+ID4gcGFnaW5nX2xvZ19k
aXJ0eV9yYW5nZSgpIGRlc2lnbmVkIGZvciB2cmFtIHRyYWNraW5nIHN1cHBvcnQsIGFyZQ0KPiA+
ID4gZ3VhcmRlZCB3aXRoDQo+ID4gUEdfbG9nX2RpcnR5Lg0KPiA+ID4gV2UgcmVsZWFzZSBib3Ro
IGZyb20gUEdfbG9nX2RpcnR5LCBhbmQgYWxzbyBtb3ZlDQo+ID4gPiBwYWdpbmdfbG9nX2RpcnR5
X3JhbmdlKCksIHJlbWFtZWQgd2l0aCBwMm1fbG9nX2RpcnR5X3JhbmdlKCksIGludG8NCj4gPiA+
IHAybS5jLCB3aGVyZQ0KPiA+IGl0IGxvZ2ljYWxseSBiZWxvbmdzLg0KPiA+DQo+ID4gQXJlbid0
IHRoZXNlIHR3byBpbmRlcGVuZGVudCBjaGFuZ2VzPyBPbmUgdG8gZGVhbCB3aXRoIHN0cnVjdA0K
PiA+IHNoX2RpcnR5X3ZyYW0sIHRoZSBvdGhlciB0byBtb3ZlIGFuZCByZW5hbWUgcGFnaW5nX2xv
Z19kaXJ0eV9yYW5nZSgpPw0KPiA+IElycmVzcGVjdGl2ZSwgaW4gdGhlIGludGVyZXN0IG9mIG1h
a2luZyBwcm9ncmVzczoNCj4gPiBBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2Uu
Y29tPiB3aXRoIC4uLg0KPiA+DQo+ID4gPiAtLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
cDJtLmgNCj4gPiA+ICsrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wMm0uaA0KPiA+ID4g
QEAgLTExMTAsNiArMTExMCwxMCBAQCBzdGF0aWMgaW5saW5lIGludCBwMm1fZW50cnlfbW9kaWZ5
KHN0cnVjdA0KPiA+ID4gcDJtX2RvbWFpbiAqcDJtLCBwMm1fdHlwZV90IG50LA0KPiA+ID4NCj4g
PiA+ICAjZW5kaWYgLyogQ09ORklHX0hWTSAqLw0KPiA+ID4NCj4gPiA+ICsvKiBnZXQgdGhlIGRp
cnR5IGJpdG1hcCBmb3IgYSBzcGVjaWZpYyByYW5nZSBvZiBwZm5zICovDQo+ID4NCj4gPiAuLi4g
Y29tbWVudCBzdHlsZSBjb3JyZWN0ZWQgaGVyZSAoaGFwcHkgdG8gZG8gc28gd2hpbGUgY29tbWl0
dGluZykuDQo+ID4NCj4gPiBBaXVpIHRoZSBwYXRjaCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgZWFy
bGllciB0d28sIGFuZCBoZW5jZSBjb3VsZCBnbw0KPiA+IGluIGFoZWFkIG9mIHRoZW0uIFNhZGx5
IG9uY2UgYWdhaW4gbm90aGluZyBsaWtlIHRoaXMgaXMgc3RhdGVkIGFueXdoZXJlLCBzbw0KPiBw
bGVhc2UgY29uZmlybS4NCj4gPg0KPg0KPiBZZXMsIGl0IGNvdWxkIGdvIGluIGFoZWFkIG9mIHRo
ZW0uIEknbGwgc3BsaXQgaXQgaW50byB0d28gY29tbWl0cywgYW5kIEkgd2lsbCBkbyB0aGlzDQo+
IGltbWVkaWF0ZWx5IHRvIHNlbmQgcmVnYXJkbGVzcyBvZiB0aGlzIHBhdGNoIHNlcmllLg0KPg0K
PiA+ID4gLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhZ2luZy5oDQo+ID4gPiArKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vcGFnaW5nLmgNCj4gPiA+IEBAIC0xMzMsMTMgKzEz
MywyMCBAQCBzdHJ1Y3QgcGFnaW5nX21vZGUgew0KPiA+ID4gICAgICAoRElWX1JPVU5EX1VQKFBB
RERSX0JJVFMgLSBQQUdFX1NISUZUIC0gKFBBR0VfU0hJRlQgKyAzKSwgXA0KPiA+ID4gICAgICAg
ICAgICAgICAgICAgIFBBR0VfU0hJRlQgLSBpbG9nMihzaXplb2YobWZuX3QpKSkgKyAxKQ0KPiA+
ID4NCj4gPiA+IC0jaWYgUEdfbG9nX2RpcnR5DQo+ID4gPiArI2lmZGVmIENPTkZJR19IVk0NCj4g
PiA+ICsvKiBWUkFNIGRpcnR5IHRyYWNraW5nIHN1cHBvcnQgKi8NCj4gPiA+ICtzdHJ1Y3Qgc2hf
ZGlydHlfdnJhbSB7DQo+ID4gPiArICAgIHVuc2lnbmVkIGxvbmcgYmVnaW5fcGZuOw0KPiA+ID4g
KyAgICB1bnNpZ25lZCBsb25nIGVuZF9wZm47DQo+ID4gPiArI2lmZGVmIENPTkZJR19TSEFET1df
UEFHSU5HDQo+ID4gPiArICAgIHBhZGRyX3QgKnNsMW1hOw0KPiA+ID4gKyAgICB1aW50OF90ICpk
aXJ0eV9iaXRtYXA7DQo+ID4gPiArICAgIHNfdGltZV90IGxhc3RfZGlydHk7DQo+ID4gPiArI2Vu
ZGlmDQo+ID4gPiArfTsNCj4gPiA+ICsjZW5kaWYNCj4gPg0KPiA+IFN1YnNlcXVlbnRseSBJIHRo
aW5rIHdlIHdpbGwgd2FudCB0byBkbyBtb3JlIGNsZWFudXAgaGVyZS4gVXMgdXNpbmcgYQ0KPiA+
IHNoYWRvdyBtb2RlIHN0cnVjdCBhbHNvIGluIEhBUCBjb2RlIGlzIGJvZ3VzIGFuZCwgYWZhaWNz
LCB3YXN0ZWZ1bC4NCj4gPiBUaGUgdGhyZWUgbGF0dGVyIG1lbWJlcnMgYXJlIHVzZWQgb25seSBi
eSBzaGFkb3cgY29kZSwgc28gSEFQIGNvdWxkDQo+ID4gaGF2ZSBpdHMgb3duLCBzbWFsbGVyIHZh
cmlhbnQgb2YgdGhlIHR5cGUuIEFuZCBlYWNoIHR5cGUgY291bGQgYmUNCj4gPiBwcml2YXRlIHRv
IHRoZSBoYXAvIGFuZCBzaGFkb3cvIHN1YnRyZWVzIHJlc3BlY3RpdmVseS4NCj4gPg0KPg0KPiBV
bmRlcnN0b29kLg0KDQpSZWFkaW5nIHJlbGF0aXZlIGNvZGVzLCBmb3VuZCB0aGF0IHdlIGhhdmUg
YSAic3RydWN0IHNoX2RpcnR5X3ZyYW0gKmRpcnR5X3ZyYW0iIGluICJzdHJ1Y3QgaHZtX2RvbWFp
biIsDQpJZiB3ZSBkZWZpbmVkIGRpZmZlcmVudCB0eXBlICJzdHJ1Y3QgaGFwX2RpcnR5X3ZyYW0i
IGFuZCAic3RydWN0IHNoX2RpcnR5X3ZyYW0iIHByaXZhdGUgdG8gdGhlIGhhcC8gYW5kIHNoYWRv
dy8gc3VidHJlZXMgcmVzcGVjdGl2ZWx5LCBlaXRoZXIgd2UgYWRkIGRpZmZlcmVudCB0eXBlIGlu
ICJzdHJ1Y3QgaHZtX2RvbWFpbiIsIG9yIHdlIGNoYW5nZSBpdCB0byB0aGUgInZvaWQgKiIgdGhl
cmUgYW5kIGRvIHRoZSB0eXBlIGNhc3Rpbmcgb24gcmVmZXJyaW5nLi4uIG1heWJlIHRoZSBmb3Jt
ZXIgaXMgc2FmZXIgb3IgYW55IGJldHRlciBzdWdnZXN0aW9uPw0KDQo+DQo+ID4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 07:55:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 07:55:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119555.1464862 (Exim 4.92)
	(envelope-from )
	id 1uwc9d-0005gN-EG; Thu, 11 Sep 2025 07:55:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119555.1464862; Thu, 11 Sep 2025 07:55: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 1uwc9d-0005gG-B1; Thu, 11 Sep 2025 07:55:41 +0000
Received: by outflank-mailman (input) for mailman id 1119555;
 Thu, 11 Sep 2025 07:55: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 1uwc9c-0005Z3-Pj
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 07:55:40 +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 b57cb964-8ee4-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 09:55:39 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b079c13240eso63546366b.1
 for ; Thu, 11 Sep 2025 00: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
 a640c23a62f3a-b07b32dd5b4sm76856266b.70.2025.09.11.00.55.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 00: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: b57cb964-8ee4-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757577339; x=1758182139; 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=0tzrxVYV0ODh8wyuQpD65I+UKWhA/gnpjSYlbjKB6KY=;
        b=f6piUFKBBj//BkFdCpOKGt+93XDw/vocAppB75nwbGnlLb+eErmPd53iOs3CX3naRG
         bjyh+GNB4E7qBtDHDftIiFWE6EwPPTmRbjI/jknN3C65lkUs25t5hlJxjDixONC7xj6h
         0iNNEXxRsgKOLG8cLhHTP8nB61bQ78XhQncT9uDKt5fZoMffRLH9bxy5P+mm7tgDEyBn
         funmNOZ4IFFewt2C6FDAaSsvqZQ2JmVzUKJeD4My6MIu8S8g2KaHmtSWSLlH8pgltahu
         NYQzn47HxvcLc6/lDEtVWF001Dli5+u4BCnSfMrZEyFqaf4ZeiOd3DXANi58Tdt5JPhX
         6NcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757577339; x=1758182139;
        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=0tzrxVYV0ODh8wyuQpD65I+UKWhA/gnpjSYlbjKB6KY=;
        b=FOCTtTrXO5wqB8IIZ7Zlgt5A9Wf+7GlKtrl++YEetDUMsTFixj5ba3kfeQVoqbWbtw
         CugqAtOoJ/DyShtQPnvMJZAle1O8b1TAdzuBPE0+cU8OidDG3/tiQgG5nnxI7asyFej0
         xiiwy9HI36vDKAcYlSEmwWQeP4/iiMNcElzg/N9RVG0NligoYCH6UVSkIH8/GguQKFca
         zEuMgA0EOPaGygJ5yFJyACtOu6nwhLX95xnSd2XGgjVYSYbszdus1VzxJ/XNsthmP9kt
         GHV6ulustlI5nfwoJ+FmhHa6XUSqW3jUr7XrU9q56Q+WKV8dX/SaRkmJYQyyJyO+R6gM
         svHQ==
X-Gm-Message-State: AOJu0YyQqCP/YEoqrYTiW/YPVAZGerIMVp9HRYb/VZNYchk2VcZSHAei
	pV0inGb9htbH55Jufptc+FM61n8stFtsf4x4kNQONK/PFbbFW6NymXFMP/CXVKdz61afuaAFOP0
	bORg=
X-Gm-Gg: ASbGncvILos9MbZn6CdWXSE7EIEHa0qz4rbCzrlunLmhwqMY5F5EekDA77Z+Ku9SohV
	vOsfLHCtN6GDKNGtFIl5oyM4AMMP96QdymTcXwvOBYticUL0yTQDRybf1xyiIej258PZxQHZgjH
	WA148ERuagsQkmp6ccPimTzIrpCARdDw+XKIJCdUecDfVg7hPaLV4xHhopzaV3Y9X0mq+hZriFS
	mH7KZCervj4EkIwe9ZC0NuBSp64h530srQEF8AzfVI7TSd/DjDh16bJpHeeaVYdYhA7wnH/riZN
	VrarsIonheH3OTjGNJjETOkxXjsf1iYgEiMlBHubdqdsgpdHyB3HehonTI9kJT/Gze4wTlxZV82
	pqUMVZceWl7zBo3m5EZ1/kDVGdkRKAl/ELlZ8IBQK/3zcJbHcLwwh0CC5on/tS1GOZQ3St1q7zV
	7bUFtc+aSEOi0Ms3fgcg==
X-Google-Smtp-Source: AGHT+IFnxSQgb/UHw78F6/80SWH/W663BFO1CdMU3hlrU50xG10aKuzjKzCxNfFNrpH1f+SF4naKxg==
X-Received: by 2002:a17:907:3faa:b0:b04:4b0d:8e82 with SMTP id a640c23a62f3a-b04b167d174mr1557318766b.50.1757577339049;
        Thu, 11 Sep 2025 00:55:39 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 09:55:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: domU reboot claim failed
To: Andrew Cooper ,
 Jason Andryuk 
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: 8bit

On 10.09.2025 23:57, Andrew Cooper wrote:
> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>> Hi,
>>
>> We're running Android as a guest and it's running the Compatibility
>> Test Suite.  During the CTS, the Android domU is rebooted multiple times.
>>
>> In the middle of the CTS, we've seen reboot fail.  xl -vvv shows:
>> domainbuilder: detail: Could not allocate memory for HVM guest as we
>> cannot claim memory!
>> xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't
>> allocate low memory for domain: Out of memory
>> libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init
>> failed: Cannot allocate memory
>> domainbuilder: detail: xc_dom_release: called
>>
>> So the claim failed.  The system has enough memory since we're just
>> rebooting the same VM.  As a work around, I added sleep(1) + retry,
>> which works.
>>
>> The curious part is the memory allocation.  For d2 to d5, we have:
>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>> xc: detail:   4KB PAGES: 0x0000000000000000
>> xc: detail:   2MB PAGES: 0x00000000000006f8
>> xc: detail:   1GB PAGES: 0x0000000000000003
>>
>> But when we have to retry the claim for d6, there are no 1GB pages used:
>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>> domainbuilder: detail: HVM claim failed! attempt 0
>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>> xc: detail:   4KB PAGES: 0x0000000000002800
>> xc: detail:   2MB PAGES: 0x0000000000000ce4
>> xc: detail:   1GB PAGES: 0x0000000000000000
>>
>> But subsequent reboots for d7 and d8 go back to using 1GB pages.
>>
>> Does the change in memory allocation stick out to anyone?
>>
>> Unfortunately, I don't have insight into what the failing test is doing.
>>
>> Xen doesn't seem set up to track the claim across reboot.  Retrying
>> the claim works in our scenario since we have a controlled configuration.
> 
> This looks to me like a known phenomenon.  Ages back, a change was made
> in how Xen scrubs memory, from being synchronous in domain_kill(), to
> being asynchronous in the idle loop.
> 
> The consequence being that, on an idle system, you can shutdown and
> reboot the domain faster, but on a busy system you end up trying to
> allocate the new domain while memory from the old domain is still dirty.
> 
> It is a classic example of a false optimisation, which looks great on an
> idle system only because the idle CPUs are swallowing the work.

I wouldn't call this a "false optimization", but rather one ...

> This impacts the ability to find a 1G aligned block of free memory to
> allocate a superpage with, and by the sounds of it, claims (which
> predate this behaviour change) aren't aware of the "to be scrubbed"
> queue and fail instead.

... which isn't sufficiently integrated with the rest of the allocator.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:00:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:00:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119571.1464873 (Exim 4.92)
	(envelope-from )
	id 1uwcDz-0007ws-2i; Thu, 11 Sep 2025 08:00:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119571.1464873; Thu, 11 Sep 2025 08:00:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwcDy-0007wl-Ve; Thu, 11 Sep 2025 08:00:10 +0000
Received: by outflank-mailman (input) for mailman id 1119571;
 Thu, 11 Sep 2025 08:00: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 1uwcDx-0007we-H9
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:00:09 +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 54dc7d88-8ee5-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:00:07 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-6228de280ccso847748a12.3
 for ; Thu, 11 Sep 2025 01:00:07 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62ec3410ee7sm644477a12.50.2025.09.11.01.00.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 01:00: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: 54dc7d88-8ee5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757577606; x=1758182406; 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=QrlNksX0kBZBWgevQvqTCUnuhFgrLUFmsGDLIooJuIw=;
        b=Lan7LKIrKigdEkm65VsBo9Bgkx7S22h6VJ8cuJLq1VDfu+SidtXbwB7vZHLrjf8oUh
         2IVw8MwBo6mTmq63aBTxemIq2Nz3ppicMP1E8dVumEXC09Z0bpv5go6ZtYp9DAi62KfF
         y7w23c44YjIah5kBp6SoqQy1BOdzHO/LwYmkbTbhQnq0vuBYjjTc0Dx2Tx8Z3K3OEMsC
         RSipDT+5X//VdYb+3Zn8fch93Aq+joZyOzEQmKZWLctAbf26ZWG9Rrdy1Y2m4O9iu/A1
         zy01OShZPpViFbM/WKPWYZvzj7VjQbfWPEioTl0urt5AjRxvTT1daHHH3+a/kD6ncxiM
         YCdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757577606; x=1758182406;
        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=QrlNksX0kBZBWgevQvqTCUnuhFgrLUFmsGDLIooJuIw=;
        b=GpbRXmszI0/1sStZzP3E0aGePc9cpQiSpkNcC572MOAvRUS61m2zxssQqA8Fc70iTn
         j3siTwQ8W50xu5xl3hTvP96puCFnjSZp9bcD33+1WIDVUkkA9nP7ni/HITZJbldeVZwh
         9eg3ANLKZZXSmwDf0arJep+JUVkNYDr9q7cAg0KTVcQ0isi8G1lgERMdH/m7Uc+YoJTI
         Ydw3NtMx/ZvEVYCgEPpQXAlfWRc7jvRQEf21yVgDZJCr7cQjmnR6RGUuPDf336pJJZf1
         hDuAh40Y8pmJU3fPlkjBkSb64WnNm5fr8/Cm6msuiixjk6IJ9z2hXwvLXhhRYBkpltwg
         4KPg==
X-Forwarded-Encrypted: i=1; AJvYcCXAOwg7T9mlqfhhC/ykp0nM7IAgtWlN9dXgmmZAOz3AzIf0p6r9w6AZ7MwoNa2muXKpOKbAkP8pm0U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyv2f7Fc/PAee5y+mZXdqm04K7MD2u4Vt+K7j/wl1ykNyJmRfPx
	y/UNQkDva2v7oK4bQ5HiwFXhlODcOb/eJpFJdH61ZLVhsldLq2NghAaRZBd7M+oDxU0=
X-Gm-Gg: ASbGnctLzEI+GI5AgnT5n2BaG0zy11/KQUa8QhyJaB7Bz3e5kwcfHQpYMaMn3/ac63+
	9bDMAgtVSFKfxkiILWzclos/rr0J/BY/7Gutiw5cy3BASwCAOYNONJWPcBJ5Z/zrnLiKTMB5iu6
	XvagxlXDqRcWRXod4PnPRrnO5zNNhiqFmNx2jZ4XEQN7L2B6QrgEEuKLj7+QMFnmqnFDKhootht
	G7qZMOvG2z0Woj8hOI1A0RDTQgDCw0FXIgDMJL92w2fCNbG5mcLgqV0m9pemQqmIn/EmV0sJiHe
	ytR0IAsOpDI8GrTLkvTuUafr4rwK4WIz/92rnN7rHMbyMdN0NpzkpHOXKNd7L0ae+ymrb6p5ttU
	AP+uMpu+DEnyK+sLckvahRMQViA0/L7gw74Q5kCOXV7OTEcgN33icL7UBvPDpGwCo3fPyau5PML
	LSWq1QFJq1pFBQMm0OmM9888mXIvl/kFebWoDCVm1m4Y+m1q0XP3Njxr8=
X-Google-Smtp-Source: AGHT+IHtwJP+NpH1ymNM/0dCe30VtYrs+73DFAhA7FZXocgko07f9smiOVMlJT1b7qw2DXXLesjZRA==
X-Received: by 2002:a05:6402:50c8:b0:62e:c525:4f94 with SMTP id 4fb4d7f45d1cf-62ec5255575mr672136a12.32.1757577606313;
        Thu, 11 Sep 2025 01:00:06 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 10:00:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/14] paravirt: cleanup and reorg
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
 linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
 Andy Lutomirski , Thomas Gleixner ,
 Ingo Molnar , Borislav Petkov ,
 Dave Hansen , "H. Peter Anvin" ,
 "K. Y. Srinivasan" ,
 Haiyang Zhang , Wei Liu ,
 Dexuan Cui , Will Deacon ,
 Boqun Feng , Waiman Long ,
 Jiri Kosina , Josh Poimboeuf ,
 Pawan Gupta ,
 Boris Ostrovsky ,
 xen-devel@lists.xenproject.org, Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Russell King
 , Catalin Marinas ,
 Huacai Chen , WANG Xuerui ,
 Madhavan Srinivasan ,
 Michael Ellerman , Nicholas Piggin ,
 Christophe Leroy ,
 Paul Walmsley , Palmer Dabbelt
 , Albert Ou ,
 Alexandre Ghiti , Juri Lelli ,
 Vincent Guittot ,
 Dietmar Eggemann ,
 Steven Rostedt , Ben Segall ,
 Mel Gorman , Valentin Schneider ,
 linux-arm-kernel@lists.infradead.org, Paolo Bonzini ,
 Vitaly Kuznetsov ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Daniel Lezcano 
References: <20250911063433.13783-1-jgross@suse.com>
 <20250911074817.GX3245006@noisy.programming.kicks-ass.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: <20250911074817.GX3245006@noisy.programming.kicks-ass.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------qqcArw2UNkNKESBZAhTAYfh4"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------qqcArw2UNkNKESBZAhTAYfh4
Content-Type: multipart/mixed; boundary="------------SW0CtEgoDQ04mHi3OOJ80Cxj";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
 linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
 Andy Lutomirski , Thomas Gleixner ,
 Ingo Molnar , Borislav Petkov ,
 Dave Hansen , "H. Peter Anvin" ,
 "K. Y. Srinivasan" ,
 Haiyang Zhang , Wei Liu ,
 Dexuan Cui , Will Deacon ,
 Boqun Feng , Waiman Long ,
 Jiri Kosina , Josh Poimboeuf ,
 Pawan Gupta ,
 Boris Ostrovsky ,
 xen-devel@lists.xenproject.org, Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Russell King
 , Catalin Marinas ,
 Huacai Chen , WANG Xuerui ,
 Madhavan Srinivasan ,
 Michael Ellerman , Nicholas Piggin ,
 Christophe Leroy ,
 Paul Walmsley , Palmer Dabbelt
 , Albert Ou ,
 Alexandre Ghiti , Juri Lelli ,
 Vincent Guittot ,
 Dietmar Eggemann ,
 Steven Rostedt , Ben Segall ,
 Mel Gorman , Valentin Schneider ,
 linux-arm-kernel@lists.infradead.org, Paolo Bonzini ,
 Vitaly Kuznetsov ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Daniel Lezcano 
Message-ID: 
Subject: Re: [PATCH 00/14] paravirt: cleanup and reorg
References: <20250911063433.13783-1-jgross@suse.com>
 <20250911074817.GX3245006@noisy.programming.kicks-ass.net>
In-Reply-To: <20250911074817.GX3245006@noisy.programming.kicks-ass.net>

--------------SW0CtEgoDQ04mHi3OOJ80Cxj
Content-Type: multipart/mixed; boundary="------------uLSRgxz23yDirGsh3b5wzau0"

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

T24gMTEuMDkuMjUgMDk6NDgsIFBldGVyIFppamxzdHJhIHdyb3RlOg0KPiBPbiBUaHUsIFNl
cCAxMSwgMjAyNSBhdCAwODozNDoxOUFNICswMjAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K
Pj4gU29tZSBjbGVhbnVwcyBhbmQgcmVvcmcgb2YgcGFyYXZpcnQgY29kZSBhbmQgaGVhZGVy
czoNCj4+DQo+PiAtIFRoZSBmaXJzdCAyIHBhdGNoZXMgc2hvdWxkIGJlIG5vdCBjb250cm92
ZXJzaWFsIGF0IGFsbCwgYXMgdGhleQ0KPj4gICAgcmVtb3ZlIGp1c3Qgc29tZSBubyBsb25n
ZXIgbmVlZGVkICNpbmNsdWRlIGFuZCBzdHJ1Y3QgZm9yd2FyZA0KPj4gICAgZGVjbGFyYXRp
b25zLg0KPj4NCj4+IC0gVGhlIDNyZCBwYXRjaCBpcyByZW1vdmluZyBDT05GSUdfUEFSQVZJ
UlRfREVCVUcsIHdoaWNoIElNTyBoYXMNCj4+ICAgIG5vIHJlYWwgdmFsdWUsIGFzIGl0IGp1
c3QgY2hhbmdlcyBhIGNyYXNoIHRvIGEgQlVHKCkgKHRoZSBzdGFjaw0KPj4gICAgdHJhY2Ug
d2lsbCBiYXNpY2FsbHkgYmUgdGhlIHNhbWUpLiBBcyB0aGUgbWFpbnRhaW5lciBvZiB0aGUg
bWFpbg0KPj4gICAgcGFyYXZpcnQgdXNlciAoWGVuKSBJIGhhdmUgbmV2ZXIgc2VlbiB0aGlz
IGNyYXNoL0JVRygpIHRvIGhhcHBlbi4NCj4+DQo+PiAtIFRoZSA0dGggcGF0Y2ggaXMganVz
dCBhIG1vdmVtZW50IG9mIGNvZGUuDQo+Pg0KPj4gLSBJIGRvbid0IGtub3cgZm9yIHdoYXQg
cmVhc29uIGFzbS9wYXJhdmlydF9hcGlfY2xvY2suaCB3YXMgYWRkZWQsDQo+PiAgICBhcyBh
bGwgYXJjaHMgc3VwcG9ydGluZyBpdCBkbyBpdCBleGFjdGx5IGluIHRoZSBzYW1lIHdheS4g
UGF0Y2gNCj4+ICAgIDUgaXMgcmVtb3ZpbmcgaXQuDQo+Pg0KPj4gLSBQYXRjaGVzIDYtMTIg
YXJlIHN0cmVhbWxpbmluZyB0aGUgcGFyYXZpcnQgY2xvY2sgaW50ZXJmYWNlcyBieQ0KPj4g
ICAgdXNpbmcgYSBjb21tb24gaW1wbGVtZW50YXRpb24gYWNyb3NzIGFyY2hpdGVjdHVyZXMg
d2hlcmUgcG9zc2libGUNCj4+ICAgIGFuZCBieSBtb3ZpbmcgdGhlIHJlbGF0ZWQgY29kZSBp
bnRvIGNvbW1vbiBzY2hlZCBjb2RlLCBhcyB0aGlzIGlzDQo+PiAgICB3aGVyZSBpdCBzaG91
bGQgbGl2ZS4NCj4+DQo+PiAtIFBhdGNoZXMgMTMrMTQgYXJlIG1vcmUgbGlrZSBSRkMgbWF0
ZXJpYWw6IHBhdGNoIDEzIGlzIGRvaW5nIHNvbWUNCj4+ICAgIHByZXBhcmF0aW9uIHdvcmsg
dG8gZW5hYmxlIHBhdGNoIDE0IHRvIG1vdmUgYWxsIHNwaW5sb2NrIHJlbGF0ZWQNCj4+ICAg
IHBhcmF2aXJ0IGZ1bmN0aW9ucyBpbnRvIHFzcGlubG9jay5oLiBJZiB0aGlzIGFwcHJvYWNo
IGlzIGFjY2VwdGVkLA0KPj4gICAgSSdkIGxpa2UgdG8gY29udGludWUgd2l0aCB0aGlzIHdv
cmsgYnkgbW92aW5nIG1vc3QgKG9yIGFsbD8pDQo+PiAgICBwYXJhdmlydCBmdW5jdGlvbnMg
ZnJvbSBwYXJhdmlydC5oIGludG8gdGhlIGhlYWRlcnMgd2hlcmUgdGhlaXINCj4+ICAgIG5h
dGl2ZSBjb3VudGVycGFydHMgYXJlIGRlZmluZWQuIFRoaXMgaXMgbWVhbnQgdG8ga2VlcCB0
aGUgbmF0aXZlDQo+PiAgICBhbmQgcGFyYXZpcnQgZnVuY3Rpb24gZGVmaW5pdGlvbnMgdG9n
ZXRoZXIgaW4gb25lIHBsYWNlIGFuZA0KPj4gICAgaG9wZWZ1bGx5IHRvIGJlIGFibGUgdG8g
cmVkdWNlIHRoZSBpbmNsdWRlIGhlbGwgd2l0aCBwYXJhdmlydC4NCj4+DQo+PiBKdWVyZ2Vu
IEdyb3NzICgxNCk6DQo+PiAgICB4ODYvcGFyYXZpcnQ6IHJlbW92ZSBub3QgbmVlZGVkIGlu
Y2x1ZGVzIG9mIHBhcmF2aXJ0LmgNCj4+ICAgIHg4Ni9wYXJhdmlydDogcmVtb3ZlIHNvbWUg
dW5uZWVkZWQgc3RydWN0IGRlY2xhcmF0aW9ucw0KPj4gICAgeDg2L3BhcmF2aXJ0OiByZW1v
dmUgUEFSQVZJUlRfREVCVUcgY29uZmlnIG9wdGlvbg0KPj4gICAgeDg2L3BhcmF2aXJ0OiBt
b3ZlIHRodW5rIG1hY3JvcyB0byBwYXJhdmlydF90eXBlcy5oDQo+PiAgICBwYXJhdmlydDog
cmVtb3ZlIGFzbS9wYXJhdmlydF9hcGlfY2xvY2suaA0KPj4gICAgc2NoZWQ6IG1vdmUgY2xv
Y2sgcmVsYXRlZCBwYXJhdmlydCBjb2RlIHRvIGtlcm5lbC9zY2hlZA0KPj4gICAgYXJtL3Bh
cmF2aXJ0OiB1c2UgY29tbW9uIGNvZGUgZm9yIHBhcmF2aXJ0X3N0ZWFsX2Nsb2NrKCkNCj4+
ICAgIGFybTY0L3BhcmF2aXJ0OiB1c2UgY29tbW9uIGNvZGUgZm9yIHBhcmF2aXJ0X3N0ZWFs
X2Nsb2NrKCkNCj4+ICAgIGxvb25nYXJjaC9wYXJhdmlydDogdXNlIGNvbW1vbiBjb2RlIGZv
ciBwYXJhdmlydF9zdGVhbF9jbG9jaygpDQo+PiAgICByaXNjdi9wYXJhdmlydDogdXNlIGNv
bW1vbiBjb2RlIGZvciBwYXJhdmlydF9zdGVhbF9jbG9jaygpDQo+PiAgICB4ODYvcGFyYXZp
cnQ6IHVzZSBjb21tb24gY29kZSBmb3IgcGFyYXZpcnRfc3RlYWxfY2xvY2soKQ0KPj4gICAg
eDg2L3BhcmF2aXJ0OiBtb3ZlIHBhcmF2aXJ0X3NjaGVkX2Nsb2NrKCkgcmVsYXRlZCBjb2Rl
IGludG8gdHNjLmMNCj4+ICAgIHg4Ni9wYXJhdmlydDogYWxsb3cgcHYtY2FsbHMgb3V0c2lk
ZSBwYXJhdmlydC5oDQo+PiAgICB4ODYvcHZsb2NrczogbW92ZSBwYXJhdmlydCBzcGlubG9j
ayBmdW5jdGlvbnMgaW50byBxc3BpbmxvY2suaA0KPiANCj4gV2l0aCB0aGUgbm90ZSB0aGF0
IHRpcCB0eXBpY2FsbHkgbGlrZXMgYSBjYXBpdGFsIGFmdGVyIHRoZSBwcmVmaXgsIGxpa2U6
DQo+IA0KPiAgICB4ODYvcGFyYXZpcnQ6IFJlbW92ZSB1bm5lZWRlZCBpbmNsdWRlcyBvZiBw
YXJhdmlydC5oDQoNCk5vdGVkLCB0aGFua3MuDQoNCj4gDQo+IEZvciAxLTEyOg0KPiANCj4g
ICAgQWNrZWQtYnk6IFBldGVyIFppamxzdHJhIChJbnRlbCkgPHBldGVyekBpbmZyYWRlYWQu
b3JnPg0KPiANCj4gDQo+IE5vdywgYXMgdG8gdGhlIGxhc3QgdHdvLCBJJ20gbm90IHN1cmUu
IExlYWtpbmcgdGhvc2UgbWFjcm9zIG91dCBvZiBQVg0KPiBpc24ndCBwYXJ0aWN1bGFybHkg
bmljZSwgdGhlbiBhZ2Fpbiwgbm90IHRoZSBlbmQgb2YgdGhlIHdvcmxkIGVpdGhlci4NCj4g
SnVzdCBub3Qgc3VyZS4NCg0KWWVzLCB0aGF0J3Mgd2h5IEkgZGlkbid0IGNvbnRpbnVlIHdp
dGggYWxsIG9mIHRoZSBvdGhlciBwb3RlbnRpYWwgbW92ZW1lbnQgb2YNCnBhcmF2aXJ0IGZ1
bmN0aW9ucy4gSSB3YW50IHNvbWUgZmVlZGJhY2sgZmlyc3QuIDotKQ0KDQpJdHMgYSB0cmFk
ZW9mZiBiZXR3ZWVuIGhhdmluZyBmdW5jdGlvbnMgd2l0aCAvIHdpdGhvdXQgcGFyYXZpcnQg
aW4gb25lIGZpbGUNCmFnYWluc3QgaGlkaW5nIHRoZSBwYXJhdmlydCBzdHVmZiBmcm9tICJu
b3JtYWwiIHJlYWRlcnMgKG5vdCB3cml0ZXJzLCBhcyB0aG9zZQ0KcHJvYmFibHkgbmVlZCB0
byB0b3VjaCB0aGUgcGFyYXZpcnQgdmFyaWFudCwgdG9vKS4NCg0KQlRXLCBJIHRoaW5rIHRo
ZSBtYWNybyBsZWFraW5nIGlzbid0IHRoZSBtYWluIHByb2JsZW0uIFRoZXJlIGFyZSBvdGhl
ciBtYWNyb3MNCmxlYWtpbmcgYWxyZWFkeS4NCg0KDQpKdWVyZ2VuDQo=
--------------uLSRgxz23yDirGsh3b5wzau0
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-----

--------------uLSRgxz23yDirGsh3b5wzau0--

--------------SW0CtEgoDQ04mHi3OOJ80Cxj--

--------------qqcArw2UNkNKESBZAhTAYfh4
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/Ey8FAmjCgYQFAwAAAAAACgkQsN6d1ii/Ey8r
OAf/Qr2x8nYLyGRENJrie6zcaTwNZyeK2FPaGrjzVaiWjT9VH4G2q5x5mhR5oFWV4toAblU5ow2h
SX840JnBB/J+SkC/W9J4UKM5yKPxGuiAZIyUVnryVO46qdBhemIpMn03Sq3Bij/oQn62902kMQk8
+Fav26WncSGYllLET53pleP3CiC3wO/NrpLc1gGkGJR7e6Mh9/tA4FldPiYKafGEWVvvZvRHGsrb
BK/o5327iIlO40Rj51EE+RKO8uspX4JanSFzCXXis6bGSLcJtqwYK9y4eLMEqqvTNB8h30YWROBp
6YVlChchkh9g1mcOIfBDkyiK0cKJQ9lHSBC7mBkEiw==
=k6d0
-----END PGP SIGNATURE-----

--------------qqcArw2UNkNKESBZAhTAYfh4--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:10:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:10:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119604.1464883 (Exim 4.92)
	(envelope-from )
	id 1uwcO6-0001bS-5W; Thu, 11 Sep 2025 08:10:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119604.1464883; Thu, 11 Sep 2025 08:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwcO6-0001bL-1v; Thu, 11 Sep 2025 08:10:38 +0000
Received: by outflank-mailman (input) for mailman id 1119604;
 Thu, 11 Sep 2025 08:10:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwcO4-0001bF-1e
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:10:36 +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 ca2ff67c-8ee6-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:10:33 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-b04ba3de760so58014066b.0
 for ; Thu, 11 Sep 2025 01:10:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b30da37dsm76772266b.18.2025.09.11.01.10.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 01:10: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: ca2ff67c-8ee6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757578233; x=1758183033; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=knyf0yL3ndeWDsGH4Eq8tgKU2oeckIccW+wZEkcHsLU=;
        b=YUHXnAIW06h7iYDzEAIi6w8B4OuGccW7bx9gvDoJpZ9Py17A3Endx58b1CmnH5x8/F
         l3p6WTk4Cj7gAilFeds4rnynmA7inOQug6pTuJ80WkrZSyHO4pBFJ9d9yzXPrr5fnc+V
         lCQPcI8TNJmhcT8xpYBjkvzh6d0eC6bR0wRVj9rIxtNLXFNudf5hjzBiW7B6s7Lx090j
         R8siFyl/UdYS+faxfLJYMomPxS22z4i1BkNXwlapD4XBhhuIQ0RPMNKGr67NOz9VgOyJ
         Lo+Mb4VWCy4arIvbgIw6dR8txSKo3zvFRt5PeD9oXZbU3XTBJAsMhj3va2k8zQV5uBp4
         6HbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757578233; x=1758183033;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=knyf0yL3ndeWDsGH4Eq8tgKU2oeckIccW+wZEkcHsLU=;
        b=ZeyAMJW6yYfITakRTpG4I9e7K96OwlB3Ypb9lb2BQ2/5c6CBRO66bFcMToBIZnk8hQ
         0vBg82HGJvMKwcCWrSxdfQ78i69Krwuq3jfr8n9vkiItQvqqkHLbD5I2NJ48q/5KxsM9
         moMaNh5usRcA/WEXXKTUhGOeot03EkDYs9YWAa7pwZZ13VB4DWPOcaPE16txGxJNu4BB
         BZMWIiThuLh2lYkpeQMiUmBhmP57Hb1Jh4c/uk5u3bD7ihkyThKA6VEeUds2yUpmSh+u
         krK5C86Au+8R1Atim/Ltwxru3l1rmi772L+B6Pt8/xgjmLcXOsst9lewWpR+k+l6jEo8
         n1jA==
X-Forwarded-Encrypted: i=1; AJvYcCVtaebPqQP0L9sMR9giMq0/eFleDOM9qxJLXBPwAfUfUSZsT6bI8oGnd46SgvtYATTcWvvwxntK3Js=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzteFqJjtMwJBX5HB0cCYYcDIcz/DIyDWcGrgrOfcI1G67eyQmu
	jnGwuVWIt9233z2tt5+4z15wDA4xKuP2kxWPWcaUJV412bRJV00oCXs071FbLZcKtA+cBOyXWZx
	IFY8=
X-Gm-Gg: ASbGncsBAfh8mM+KqUlpNgamuj9DASbLELFMxeVVq5E5OgnfgJGWiUsOpwKVSSWRYcG
	2aNtpld3O6wuE5PmbY8UZoVROJ8iUrcIEEJVjlw4p7OPSXj49uxvy9vR2F2swSDS1H1qIiA0QUg
	TK88A/7zZ6yKgqutcEOVJdhiqQTgFyV6aDFxMXJru3vyV8oZcalTFS4+go0GWuxCOeAVYTvhg1r
	QQf83M++1zfVEBGO/GnkT7rM7Uz3kPPIdWZRWEx/LJyPxamNd8xZDJnpKnO+TIiYQYrfINe1m5o
	PikhjE0QPdwzcYz/Lj+LL5zouVqlrXyrOUQKRKFm5mwCXpG58gjOO8T45Na5Jao1xZ8NUM06dFr
	WvzFFId0LiZZvZlEZEiadamYY6YZWPYm6aV/Q+hLlaDRl6wFIzvAcj68xvuH/RPlTSlDEhrOaYO
	Q2FEFmVRA=
X-Google-Smtp-Source: AGHT+IFHdOleZ4VTgSObIOXSTwv1jvDLlQ2sHqF2+DXxk7djHAQ/TgU2b690W9FeRNiRXH3mtVQ7Ww==
X-Received: by 2002:a17:907:7ba3:b0:b04:9c08:e04b with SMTP id a640c23a62f3a-b04b14b1c8dmr1743764066b.29.1757578232777;
        Thu, 11 Sep 2025 01:10:32 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 10:10:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 09:54, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Penny, Zheng
>> Sent: Thursday, September 11, 2025 3:16 PM
>>
>>> -----Original Message-----
>>> From: Jan Beulich 
>>> Sent: Wednesday, September 10, 2025 10:09 PM
>>>
>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>> --- a/xen/arch/x86/include/asm/paging.h
>>>> +++ b/xen/arch/x86/include/asm/paging.h
>>>> @@ -133,13 +133,20 @@ struct paging_mode {
>>>>      (DIV_ROUND_UP(PADDR_BITS - PAGE_SHIFT - (PAGE_SHIFT + 3), \
>>>>                    PAGE_SHIFT - ilog2(sizeof(mfn_t))) + 1)
>>>>
>>>> -#if PG_log_dirty
>>>> +#ifdef CONFIG_HVM
>>>> +/* VRAM dirty tracking support */
>>>> +struct sh_dirty_vram {
>>>> +    unsigned long begin_pfn;
>>>> +    unsigned long end_pfn;
>>>> +#ifdef CONFIG_SHADOW_PAGING
>>>> +    paddr_t *sl1ma;
>>>> +    uint8_t *dirty_bitmap;
>>>> +    s_time_t last_dirty;
>>>> +#endif
>>>> +};
>>>> +#endif
>>>
>>> Subsequently I think we will want to do more cleanup here. Us using a
>>> shadow mode struct also in HAP code is bogus and, afaics, wasteful.
>>> The three latter members are used only by shadow code, so HAP could
>>> have its own, smaller variant of the type. And each type could be
>>> private to the hap/ and shadow/ subtrees respectively.
>>
>> Understood.
> 
> Reading relative codes, found that we have a "struct sh_dirty_vram *dirty_vram" in "struct hvm_domain",
> If we defined different type "struct hap_dirty_vram" and "struct sh_dirty_vram" private to the hap/ and shadow/ subtrees respectively, either we add different type in "struct hvm_domain", or we change it to the "void *" there and do the type casting on referring... maybe the former is safer or any better suggestion?

Yes, but I wasn't really meaning for you to do that further cleanup. I'm
intending to do that once your change has gone in.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:12:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:12:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119615.1464894 (Exim 4.92)
	(envelope-from )
	id 1uwcPj-00028o-Hf; Thu, 11 Sep 2025 08:12:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119615.1464894; Thu, 11 Sep 2025 08: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 1uwcPj-00028h-Ch; Thu, 11 Sep 2025 08:12:19 +0000
Received: by outflank-mailman (input) for mailman id 1119615;
 Thu, 11 Sep 2025 08: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 1uwcPi-00028b-4N
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:12:18 +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 07586ec9-8ee7-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 10:12:17 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DBBPR03MB6937.eurprd03.prod.outlook.com (2603:10a6:10:20a::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 08:12:13 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 08: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: 07586ec9-8ee7-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xlgT2S7DKXfvgsYHxvmdH86OrSpmiqr28ADLVC6fWuwTK0+rZ4kmnLdpdLXvTBxp+cOGsqJuWLTXF9wLEXmp0jF8b9OOii2T+qj258UYgQHhql5U46y5Ul8qGim7I3OHjb27IpyUn8yU9Q4+/daVNxHJnIoaXTJteJww88kBQ4GwSPYbv47rR1jT9F82jpmavRJ/nWNY8juBdANnno6OWZiAmv1mjMoI3G8kc42c+FSZNPAprambIBJKInQmgRZ1mC5+iMKFKc17gQL8gg914JRiV+wSJlJjEnfKoen+0bj22tkPL8YdSEgDmDrBGVs/Dz78jgyXvqUmhUwxCcA7tg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OMls4gkKxWS+SJIDk0QbaAmAryuXbYrLGkm4mbE1DTI=;
 b=wtiKJMnqGzyHCVVO8X53wpF6ztScirqFjbqaG1RupYJKA7i/iSUAwX8L221VfbL1Xmhb3RKVRvgO9IJtgX1qnsSQsKDtW82S8IZZyBMkQV14/QnEDBcrYRKV4wa8uHXiu7ncK9Rx3d0RqSYq9niLiYHGcalQPN4ynmil4r0Ti3hG7HLV13PmQK9j7TihfzHkGC9XLL5By3qOKEX4wRdk5WxO0pfNP4QetYfnFcbQfmZ2mBPdh1o21NRiOahDqrkZcSSh4AtOR/CgJcF0HbpW6VmPRsyW68y9lbSlDSG4JLtcT1OSgvJqNsN2LdH5ta+MWOyn84xrqbcasTyO8TXtnw==
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=OMls4gkKxWS+SJIDk0QbaAmAryuXbYrLGkm4mbE1DTI=;
 b=lI3Sloaz3Sv8MhKvfa6R3zvORjsPtEW+f0E6FJry0Rb07lJRWeGvaq2gsGLQr08pTziiIm7AKy6mYNOZhR3sGqhXqAstnWeQRjYmDYVUvh/FbriyHrkwlHtI6sWv/U8E5pwXl5JEBuPmPZV8tNXH71R47qF+Bpn8Y6wYQIrSLWhTsPJ5roz0ByV2JjDKM7SRmf2g61dyNBA6IzSirN7ugrY5cJ8XDxndRUEdeMGKC16wpetyIzXlrXRYdTg71CREghX1QPlVvkWbrVtGl1z5fYA4mkVbP4gQW4iPSnzwg8c2ardVW+giv8VTXArnSHsARDZvdvErHaXzNTC07lritQ==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [XEN][PATCH] xen/arm: restrict cpu_up_send_sgi() to arm32
Thread-Topic: [XEN][PATCH] xen/arm: restrict cpu_up_send_sgi() to arm32
Thread-Index: AQHcIvPHEqUOcNKJLk6tvD5PLd0SYw==
Date: Thu, 11 Sep 2025 08:12:13 +0000
Message-ID: <20250911081213.1323594-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|DBBPR03MB6937:EE_
x-ms-office365-filtering-correlation-id: 43037d70-988f-47fc-55a3-08ddf10aea32
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?07VLl/44TfYCphM4x0r9QYPNtAcv4CwIK42qk7EyN/tK1vZ9sKtL28z6/h?=
 =?iso-8859-1?Q?R8RdcInj9LlkGzDquH3cjZucog72It30JwfYSRoK9WzV9+M///VflMylk/?=
 =?iso-8859-1?Q?gY0YVlm8BJJQs9f8fmK9+C+Idc1kT9IPYPjoaMnaQRWx9emedssm9wOUJ6?=
 =?iso-8859-1?Q?OdXqEu6OT3f+w4x/kESY7sVGRsfKx6VTZuUPgFFl0lXnJMwT7a2aKbgsFp?=
 =?iso-8859-1?Q?qrIichnwDTaQKBnXk6GVZXcJNBb3iAmDOc0/1QBZBM084d5g3cVsbs2sje?=
 =?iso-8859-1?Q?lF5cvFLbcb0hAYGNk94bIqwsIYdpimYx8z+5xH8EcACmoqgYRoqpDNRlqc?=
 =?iso-8859-1?Q?YHmkteKhbGTg/b/8IdrcSQ6hJc0Ry68j92E+77C+5mLD79WTpJqO+R+/G3?=
 =?iso-8859-1?Q?ByezC0/X8To3Cj7EQSTOT1Mr1pbImCTTGSttx964p0za6GNCk0FT/YCJ9g?=
 =?iso-8859-1?Q?8k+6TeY98YQFRD19FDiDMs4MKkm/svIgYcdmjKk3fABMgKXGGVbS564OoG?=
 =?iso-8859-1?Q?9uMGytF8a0SGlm3mF9aNv0IrmmVy0YYa3aIDxHEKJg3OVXtfSw4zjTzV6L?=
 =?iso-8859-1?Q?VLot33/cAU8BCnDOc/zjbn6B6/0rsBjHR18zigP7rqT/G9XIm0Ie102tM2?=
 =?iso-8859-1?Q?HTT0Oef4qTfO1lU6avS2Yv7isj8yViabWsurhG4XW9DZhlulL9gExtz3xi?=
 =?iso-8859-1?Q?hwuzkWhbA2G5Z7Yqz1SxcI7WmmaeSH2tGyVS9SZ1Zgta4GoywWuJa/Wy1G?=
 =?iso-8859-1?Q?2XPZjRHZXd2XYC/E9gKHSgwZi4uC6mYDTI0xmJvsW91KN1HO+k7z+lnWgu?=
 =?iso-8859-1?Q?KOBhYb5lIGFXC2GNCieeIthlgD1c2ujIcE+m983TeOho6uszPyANrs9sL7?=
 =?iso-8859-1?Q?NbhmFSOsDjM+bk93cFaM0QnUKlhdA7lk5FVbWOdHWchyaQfoLZib/rsS5w?=
 =?iso-8859-1?Q?g5t0nQdYTjcsyknXPKmUba5lLE7mxf+feVKvQ+278F0PWzikhTqOy+/iKF?=
 =?iso-8859-1?Q?iXBfAsucQVpjk+1uiTP5YJ7g/hqr1k91xN6+LZ/Qfl6r0aXYvhx2apZ5cC?=
 =?iso-8859-1?Q?sc73M5OlQvsnhZ7HdpOIRE7iyRbj0qXSpMHEIH7KlKtnkjIgFfJnFUNSYv?=
 =?iso-8859-1?Q?alO/jNWYEQkXLJclDAE/k3rr/rv8CAm5PFzMgkzhqu3cv4RZyxWWT9N/fv?=
 =?iso-8859-1?Q?WJUM+Kt8/qirBGtN9TQ1b9MfUnSlC+/0PFm3lNLjPv52NiKKctQ51eq7km?=
 =?iso-8859-1?Q?ub+Dv7LUE8RAuBBQN0UtghhUe4seoDpOGTB8EtTKTuIhl5EVyucH7zJ8Vj?=
 =?iso-8859-1?Q?f6IcqsFXOXzxTv7BmJMx3H2nV3tKJ+yatNpTqeA7MoCsu7ODtJq13jUi8s?=
 =?iso-8859-1?Q?5BAE3pmhFBAp1mKxFFRl7HF/342RJt4nCsN8v4un4+k6ygg9Ci0Q616oAb?=
 =?iso-8859-1?Q?+vs0DyAZ29OiczPHZDNbK4I8BudR/Jcf9e9Fidrp1lDRHVMPgN7p9Fs2qA?=
 =?iso-8859-1?Q?7IHLSqI3PSU5jB3c/JZ7RZ9YjKhyDaHAgmMj1a2mwpllOs4Xw8fitbB8sZ?=
 =?iso-8859-1?Q?uhhpTBQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?ENOmY0X87n1oMa6m/oG/2g8RwmRtP/cVOB+nsCQvJiNHvEnche9xTtuR8N?=
 =?iso-8859-1?Q?osOSIS5+Y8Ukkj+ZSWmlKti3Vexe7VYOYmnby3P8ds5Efn5hI1WAJjayjW?=
 =?iso-8859-1?Q?SIYye4+iau6qeF7Q4a6aBhsSBsytHeJF/igRLLNnugqU3Ijw85+uBldknd?=
 =?iso-8859-1?Q?cMwQun9KpPQcchKKPjFe2EoCo9Q/nCtK4YDe4EXkLlPOFcfZkcduRDxGyx?=
 =?iso-8859-1?Q?2zy2ClEfkmta7Nl/hAmzGKfvgyIjBArku1cjVPHi4l/TIltjscYaqlQvSg?=
 =?iso-8859-1?Q?XVztH6SClE50QxsV8ruOCvUMsbY5ubZ7Lm8Wd5W7M4G9AHaketlCjfljxn?=
 =?iso-8859-1?Q?REYuBDM9Up0EdPxSzBUZagKwK+TX8f4VX30BZ636IiqRzUvd8aAZoorx86?=
 =?iso-8859-1?Q?DFQYZMqYWA48P1/UBuk2ZWSd6kr0axgOWKtli7oVvES1BFRdT+MNG23o8K?=
 =?iso-8859-1?Q?9zWLIZFFkCLwpfmpzYK2D3E52jrrXuFHluvjhBnsyem9BravsItc7KSrmR?=
 =?iso-8859-1?Q?8tBnprn4/WN8hskIk03QmZRzp5H/5uq2PpzgE23tMcnQ3as5RLuiBJ/ohA?=
 =?iso-8859-1?Q?5G0FFyebMwUOaC5NmD/obO9RZXcfuRVMjasrnuAfx4sdJi57oTp8EMFWNs?=
 =?iso-8859-1?Q?6hzJmk6QKxjpgqGBkEC0+54mppHgG6iJN/jQ+PgkTd15rqWHL4aalZ4QlP?=
 =?iso-8859-1?Q?6BOULNvMqTCkRO3XQeHGv9Oqw/RUdf4iBfMI2WV3POg4wYkDsCJu1QzRPj?=
 =?iso-8859-1?Q?o7OSnluhnI27hFvk5XrljqOQo3WhnkC32/eKsei95bNr3Iq9Qes7TdKT87?=
 =?iso-8859-1?Q?cndpUlJ/OGsfu9MSD+vkXMFYyUbLBWsfHzBSt0Oag5pB3AWFqWJi6ikNez?=
 =?iso-8859-1?Q?Wsm8TStk00Qp900Ga9PDl2qv9pqNfBL3ie0cV6KnCcqcbl8Yhu2W6uBcDt?=
 =?iso-8859-1?Q?0n9u6eaWyt3AZ+0Mgkmvpu5QnYY+hvH/EHSDsPL8ciRCrRdB6G/Z1P/OKj?=
 =?iso-8859-1?Q?tz1E3T4lNcz8eOa4Dh+El/24bcZ8T92ivZKK2zbenl3nZ1r+/6+yZmX+Wp?=
 =?iso-8859-1?Q?jfvmWZZoV+cpVC9jMpnBs3vVwQkxSyUs3V9hyvswS9vX4mnyoptsHksqwk?=
 =?iso-8859-1?Q?ezG5MVjbQ1Y1/2Bq3dA1+rBwVyQucXARrgAkSACrfEfTrmzaNcOOnR2m4G?=
 =?iso-8859-1?Q?XA1RhShWAauJ45iScsQYQP6tFtoLbKmQlGI9/z5eWiPyrBxDBqUzTsPSmZ?=
 =?iso-8859-1?Q?pr3M/ZkK0XNOH2ZgR2EHhTojo5fKlZSm6ogByyHh0qM7xqXjqcW1/ZLOBS?=
 =?iso-8859-1?Q?d2hxlCzTOyFJfjYjqYnwQhsShcEbq5ZJdD0cc7/oRsJoTSOUXwrKiizQqV?=
 =?iso-8859-1?Q?DHqd6SBue7JWF1/W7BUwAVhgW3VqDxNSlhjVmnd3r8Aonc9S8G4srWEUPG?=
 =?iso-8859-1?Q?NL7dyn86oSW6P4g+RwUCcUzCj4IzjpeXjUmRtH63nLa7mclQeBKeswMEIK?=
 =?iso-8859-1?Q?A3iJctITu0zvj6p0vp0hpTV+Ad/7CVbkCwMCSPAzK6bLTuciLCwdhTz2DJ?=
 =?iso-8859-1?Q?u8nHxUNtI9ta1sugO8c6nAT287XhZYjeXcbmTPWD3FmrEjNzHF11IxtwUC?=
 =?iso-8859-1?Q?GEzWuarIfIpMiudxmYLarlmvIV5bjX7zYxPqPszvca2BbvLmAMmsTryA?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43037d70-988f-47fc-55a3-08ddf10aea32
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 08:12:13.7064
 (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: V6XSNSTl/DOF9ieBuGHy/MN0wnid/bapFmggPZhCGfD6+Cs4u0iXvLP6g8JZ5fOGZEsnhXEPaPJAI9zK+i/BJwDfVoUL5cYMaGkFsISoZ9c=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6937

From: Grygorii Strashko 

Restrict cpu_up_send_sgi() function to arm32 code as it's used by arm32
platforms only and unreachable on arm64 (Misra rule 2.1).

Signed-off-by: Grygorii Strashko 
---
Logically cpu_up_send_sgi() should be moved in arm32, but source is
"GPL-2.0-or-later" while possible destination is "GPL-2.0-only", so put it
under ifdef for now.

 xen/arch/arm/smpboot.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 7f3cfa812edb..45f3be323687 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -464,6 +464,7 @@ static void set_smp_up_cpu(unsigned long mpidr)
=20
 }
=20
+#ifdef CONFIG_ARM_32
 int __init cpu_up_send_sgi(int cpu)
 {
     /* We don't know the GIC ID of the CPU until it has woken up, so just
@@ -473,6 +474,7 @@ int __init cpu_up_send_sgi(int cpu)
=20
     return 0;
 }
+#endif
=20
 /* Bring up a remote CPU */
 int __cpu_up(unsigned int cpu)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:14:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:14:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119627.1464902 (Exim 4.92)
	(envelope-from )
	id 1uwcS5-0002hA-T6; Thu, 11 Sep 2025 08:14:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119627.1464902; Thu, 11 Sep 2025 08:14: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 1uwcS5-0002h3-Pe; Thu, 11 Sep 2025 08:14:45 +0000
Received: by outflank-mailman (input) for mailman id 1119627;
 Thu, 11 Sep 2025 08:14: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 1uwcS4-0002ge-Ci
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:14: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 5ec46337-8ee7-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 10:14:43 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b042eb09948so82860266b.3
 for ; Thu, 11 Sep 2025 01:14: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
 a640c23a62f3a-b07b312940dsm79904866b.40.2025.09.11.01.14.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 01:14: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: 5ec46337-8ee7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757578482; x=1758183282; 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=NQw/pHbMKgZN/DXXg055zLw+8Gh5oTQyodMBAbDaFjI=;
        b=UHI5AJzo0fVDaIC7QMRZWF/V2LHiSGcCmkOl2K/n3YusEFiLAhNK9GufsK23Qld8gX
         yNl22Ov5XuHB4eg+dIeXGgOrxeVgdVfxQjnvlng7LDS7qufETrMMLHbH3uQRjqorziA4
         rD4PNkEt3bo60gZj+nNbchm+SRtk30qgRw1U0N+V1iUlE8kLOI9FUY9dTolgd86gkdZJ
         uvbNWV0oBbZs5+adLHvVjYq5Ax6ecBn21gI3xeWCHo46au7zdyIgfrCmAGEXgrij6KAN
         RLDGkJD9Ws0Oy5YHkD3yP7UWmCrYKg/Net5J9VMA5aJk560tLkAUPVwHbunfC0yryxlB
         Tg8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757578482; x=1758183282;
        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=NQw/pHbMKgZN/DXXg055zLw+8Gh5oTQyodMBAbDaFjI=;
        b=E1FmZ2qnOMMuf+L7oPYAi4dE42rhnspfRVgDLvOIxmjY6DyYENtPMuAMQf9Ioa9yNS
         AQXcrdCLaH4Xl9PVjRD/zjdMkCiCehmq00I5sPB87mU72VdaDo0QmDicmmFOv00ODVKn
         pyJmDS/vIWCiYfo62cJPzrrfAqQb7UdfT/9OL6cEcYAgbnGGzWkyR2Ow5BouFIyui3nf
         nmb9ba2WIoQch/crkPSHbrcVLv75TPDbDY02oR7Bdrxe9yfPtxoQ7EhtOwAwLRm7wX1v
         cgTS9am9MYP54WH6/3uCjkBheloh1iu7GwxJh0K8s0fAY55GG0EPeXj5va6zrITO7fPG
         oLcg==
X-Gm-Message-State: AOJu0YwLPzinCdRrglXLM4yV+RYMHnZuk48VRJ8FKvx7FhlINcIYsNPm
	P9t6gh3ZJDOT2Ui1bK3dVXbmZVasH3UdkIrxC0csr9kDJOQMfw/5IJ+exm0MGoPD8cq4hboWRTm
	V8es=
X-Gm-Gg: ASbGncs/efNId+UgiY7IkgdfDOHVQeyfV0SC+cyr7NMXnkz6yZF0en44IXPrL+8DDmE
	Anx5BjE9/pNSy4IDWS7mQk55LJnxFxzLBOPvySV65TFy/u3JY3qrkoEHRXK4/bj6m2VtyTqUIfF
	1NTnnyTBUDGC5egUPE3kx72mIq9FZ+vv44vmk8HuzBhaEflc4jQ6DtiKTdrud+SrO49heRuhbiP
	m4H52lpmcddI3b05jX6g03gAmzxcKXcUT0hEj8SaQX5uQZRB01no0uePXlyftdANzS+i8Ej/BnN
	5g1wH2P1DfNBckQ4iNiQB2S+J/zTz1uOLec6Hn85CFYMesTXNVg52NfqXbN3Fu5xxlq+M+NIqao
	gmaHggUdZUka+pi1Tb9Vhz9r+4BJMkoRlxlMP3R9ZbNpZdki5pZlur6g15gREwk7sop/Z9CUlBq
	hLDpgFpaI=
X-Google-Smtp-Source: AGHT+IHcHr7bZSbiyPPn4rsWRyGXyT1oS0YeJ0x4Iq2jsmYaMLXLldlIk9Gu0QB678SNj1fMG9YtOQ==
X-Received: by 2002:a17:906:d555:b0:b03:bc9c:ee9b with SMTP id a640c23a62f3a-b04b14aec03mr1720018666b.26.1757578482231;
        Thu, 11 Sep 2025 01:14:42 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 10:14:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v3] releases: use newer compression methods for tarballs
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Other projects have long switched to xz and/or lzip.

Tidy things some as well: With the removal of qemu from the tarball,
intermediately extracting the tarball again has become wasteful. Drop
that. Invoke compressors using asynchronous lists, to reduce overall
latency. Drop the -v option from the (previously implicit) gzip
invocation.

Signed-off-by: Jan Beulich 
---
v3: List tarballs using ls at end of script. (Don't alter the rm-s, due
    to lack of feedback there.)
v2: Don't expand intermediate uncompressed tarball. Don't check for
    commands' availablity. Don't request statistics. Use async lists.

--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -119,7 +119,7 @@ RELEASE TARBALL
        make src-tarball           # uses git-describe (best for RCs)
         # ^find some way to add git-cache-proxy to this (done in ~iwj/.gitconfig)
        mkdir /volatile/iwj/website-thing/xen.org/oss-xen/release/$v
-       mv dist/xen-$v.tar.gz /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/.
+       mv dist/xen-$v.tar.[glx]z /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/.
 
        # website-thing/xen.org is cvs -d mail.xenproject.org:/home/downloads-cvs/cvs-repos co xen.org
 	cd /volatile/iwj/website-thing/xen.org
@@ -139,9 +139,12 @@ RELEASE TARBALL
 	cvs add -kb oss-xen/release/$v/
 
         cd oss-xen/release/$v
-        gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' xen-$v.tar.gz
-	cvs add -kb xen-$v.tar.gz
-        cvs add -kb xen-$v.tar.gz.sig
+        for t in xen-$v.tar.[glx]z
+        do
+            gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' $t
+            cvs add -kb $t
+            cvs add -kb $t.sig
+        done
         cd ../../..
 
 	cvs ci -m $v
@@ -152,6 +155,10 @@ RELEASE TARBALL
 	# should show something like
 	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz
 	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz.sig
+	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.lz
+	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.lz.sig
+	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.xz
+	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.xz.sig
 
 After a .0 release, update XEN_EXTRAVERSION again (to .1-pre, see above).
 
--- a/docs/process/xen-release-management.pandoc
+++ b/docs/process/xen-release-management.pandoc
@@ -274,10 +274,10 @@ Xen X.Y rcZ is tagged. You can check tha
 https://xenbits.xen.org/git-http/xen.git X.Y.0-rcZ
 
 For your convenience there is also a tarball at:
-https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz
+https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.[glx]z
 
 And the signature is at:
-https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz.sig
+https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.[glx]z.sig
 
 Please send bug reports and test reports to xen-devel@lists.xenproject.org.
 When sending bug reports, please CC relevant maintainers and me
--- a/tools/misc/mktarball
+++ b/tools/misc/mktarball
@@ -5,14 +5,6 @@
 # Takes 2 arguments, the path to the dist directory and the version
 set -ex
 
-function git_archive_into {
-    mkdir -p "$2"
-
-    git --git-dir="$1"/.git \
-	archive --format=tar HEAD | \
-	tar Cxf "$2" -
-}
-
 if [[ -z "$1" || -z "$2" ]] ; then
   echo "usage: $0 path-to-XEN_ROOT xen-version"
   exit 1
@@ -21,14 +13,21 @@ fi
 xen_root="$1"
 desc="$2"
 
-tdir="$xen_root/dist/tmp.src-tarball"
+tdir="$xen_root/dist"
 
-rm -rf $tdir
+rm -f $tdir/xen-$desc.tar.[glx]z
 
 mkdir -p $tdir
 
-git_archive_into $xen_root $tdir/xen-$desc
+git --git-dir="$xen_root/.git" archive --format=tar HEAD --prefix=xen-$desc/ \
+    >"$tdir/xen-$desc.tar"
+
+gzip -9k "$tdir/xen-$desc.tar" &
+xz -9k "$tdir/xen-$desc.tar" &
+lzip -9k "$tdir/xen-$desc.tar" &
+wait
 
-GZIP=-9v tar cz -f $xen_root/dist/xen-$desc.tar.gz -C $tdir xen-$desc
+rm -f $tdir/xen-$desc.tar
 
-echo "Source tarball in $xen_root/dist/xen-$desc.tar.gz"
+echo "Source tarball(s):"
+ls -lh $tdir/xen-$desc.tar*


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119648.1464933 (Exim 4.92)
	(envelope-from )
	id 1uwcXz-0004zt-49; Thu, 11 Sep 2025 08:20:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119648.1464933; Thu, 11 Sep 2025 08:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwcXy-0004zk-VS; Thu, 11 Sep 2025 08:20:50 +0000
Received: by outflank-mailman (input) for mailman id 1119648;
 Thu, 11 Sep 2025 08: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 1uwcXw-0004XB-UF
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:20:48 +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 38196c94-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:20:47 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9468.eurprd03.prod.outlook.com (2603:10a6:20b:59b::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 08:20:35 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 08:20: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: 38196c94-8ee8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YcnxHkCloahbG6p5FNFww5ojMRW/gJ0OQElIIKrPArg0CHA/4kuTjiJkk8sdWeAPiJcY64UsTUejAsfskGXnvTKx9t0cLbkYgn4BW/OYQ8wbh180gpj7rA37F2TwnaLOj/72bWMRB7tsygC8k9IqEcyLRblC6DYk7HvxBVcFbtx6uDW5ikFh2OyFoSbSOEhLLm5sqi6a78zi+m/fpCz5QoSIGkcx7ZuYawG9MR/YG906NTf5i3JqdhgaVCTFqpUKHoXZAjOyI31eNn+/JewDk0hIFTwksEnsvUaZH4z6wFfQkQYY4LsovIaZEVMDZ8px0vvCKxY7t437dvcpDvkS0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rX2rdTxDeSwKJ1lHrAmzqYdj5Iky3KiEQg90cX64EBY=;
 b=mue+0pAYqbIO536mTFxh/dwYTnbFCocqFOD7elj1+0fMLU3P2EF9Sz/y7+nm3TBPFuwZDgYT/C6tWfJkTtzwuG1VVEBXWsvPFS20uHmSFgeQNGKd3pkcYmRW3JmTbGZpIu6IgUb8XjfjGP6fCFTsfn+57BTu/lymRSanY/PJ7TNTDGEWtT7kIQra9Dz0WmU9+qJk1mrhHyUFBqkCS85Yhizrh0AhWqBFkgF0rFbD37AGjO/m4ngEf/QlVpUpvTsHIBrMUmk0dfoH1LaIn/FaDV2lX/Gf6zCeN5GP02HlaSP7em926VwMq1SqkdSfAHnYOHQNVJaWYkYVF4DPlPAQHg==
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=rX2rdTxDeSwKJ1lHrAmzqYdj5Iky3KiEQg90cX64EBY=;
 b=PFYqDIX+b6k7ub9j16KvSJWUl+skFKqI7RXbcMXm2qK0MsIS83Jm5TIdpf1WW3iRPGwdrTZyg+mVE9nmvLZxxyDHDOPssIhnBtSPAroS/aoCeVME7wCfRGqpJYK6wHRl6mAzGI9/B8KtWJlL4u7xVdChH7Ewf23LsbxTQggJ+X2rE86oyktmfCHeIjQhnU91+51cYRhJYXymmyYMiiDY0o51SiydRynNF6NG5krG653a4GXSQu7dYCec52XXqNZAjVOfCW/gBx4Sx1Ku8qg0whE7lOayFH5nvWHkKX8PIOJUXWfRHeX6SNhwyXRQ+dxJMsg03IsCbHwxDTG8CFt7JQ==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Volodymyr Babchuk
	
Subject: [PATCH v3 2/4] xen/arm: split is_32bit/64bit_domain() between
 arm64/arm32
Thread-Topic: [PATCH v3 2/4] xen/arm: split is_32bit/64bit_domain() between
 arm64/arm32
Thread-Index: AQHcIvTyqGjM1f4hhUaFOl5Oytg18g==
Date: Thu, 11 Sep 2025 08:20:35 +0000
Message-ID: <20250911082034.1326377-3-grygorii_strashko@epam.com>
References: <20250911082034.1326377-1-grygorii_strashko@epam.com>
In-Reply-To: <20250911082034.1326377-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB9468:EE_
x-ms-office365-filtering-correlation-id: 8607d37e-6679-41b5-cda5-08ddf10c157d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?x00dVmFen7y2hKXeLKcIWQ41nV8u9C2s8U4glClP7SOhKtMMViwyEXu7X6?=
 =?iso-8859-1?Q?PqvMBzE5gvNKqg+nHpzlpzqCt15UNGBPRkKysdtBl0OyO8gb6iXQ61U+CM?=
 =?iso-8859-1?Q?Ng/1vNqpSMwdYKZUNdQ6L6REdD6wWn2PaMBI09YpQ1yAYsO//H/zsotD59?=
 =?iso-8859-1?Q?jXFNIXyrhjR455spbz+g+AYgkm4YS+mavOIBVYLyGX1KN06UMTSO4cTSKg?=
 =?iso-8859-1?Q?cp22Ups+e/voQNABEetuqIrOQgG0iLjMxDwiP8RUVdidI80LBt6whOUkQg?=
 =?iso-8859-1?Q?TUDjp9D+paBBla4iv3ikoD+lgAr6dzSU9lnKtMrSrFgR8yzki2jHMNG9j1?=
 =?iso-8859-1?Q?UC/IVXuE8NVM58JfJM4QMYF9tfPGz6nIMkn6vKOUzefWU6FnbaAMvbMs1l?=
 =?iso-8859-1?Q?KU4O5Jz+uHf6LuA8P62d79ZfiZz1zArDXrHqGukG7xQrTR++FmXa3VGnA4?=
 =?iso-8859-1?Q?vHTSuZYziNSngrJye7P2Sc5binC/9jzg9ze7HKtfqujh7N3lRsWB6FX88p?=
 =?iso-8859-1?Q?iN8VdGarKqZ11qJYFZVUGVNzSJbN+daJTATO/y3bOjlm2ge2nM/z1ueM1t?=
 =?iso-8859-1?Q?N4zAV2b7ovWMTE6wL5wdwWU7f4kbfuNu50OElpLLYONOtibnuOpiEVYAk/?=
 =?iso-8859-1?Q?rlKvZQTbv/0OdAF/IslI7+npRt4jPFKWMIIT9fmTNwEAQxd/Bf1VZYwiJv?=
 =?iso-8859-1?Q?2jvrLloX5YrN0nLlVfZ7Tb+BBF1tYYHBwpEExGirQOmqn5hWyBX5m8jVVH?=
 =?iso-8859-1?Q?VTb5PG9M42TSNBrRTLgiqS1frbNpe5sH5rnr6LnWIUezSPBq60ejCzNJS5?=
 =?iso-8859-1?Q?af7YLIbcTdboym3G/vSzNaBPv/Isa0wMtYzF6YpvU2KzZAWqinFq4jAQNi?=
 =?iso-8859-1?Q?0+88n93KIxJPnxnNuyoDPw04qOnTt04kwMAa3iApoAos7seSUEgo6fqa/E?=
 =?iso-8859-1?Q?UEphOAqcV9rvpFpTmC4MzqMvoW2XhOe4dGydl8UGJw5K2cLvv84QtYOu8m?=
 =?iso-8859-1?Q?El8O5+zExYZFLyfPpGzbFeI38z5u1hEazWJJtvvH445ZEa4VKk0Jm45hec?=
 =?iso-8859-1?Q?x5fKxKna8BAatfTww95ZmlsrNZrOgBUt2qdky5d6xyY3nsQ9OMSCBMFB58?=
 =?iso-8859-1?Q?qFKgBRb+QuxNOwN2hYov4/OuaH8ZRT/yas/Ty7mcZj3IaMhgAg5e1g1iAG?=
 =?iso-8859-1?Q?KLGpmNv2AwMvdPE5Nq93Lip4faXNEggov4RU1El4PxwLnXU4n3tYWR20p9?=
 =?iso-8859-1?Q?UeRa1pbGjWJp/6cSioVyFz6eW+X3A67YkBFyEVtVKEFWL6u7ostQGLwKJG?=
 =?iso-8859-1?Q?8LOsFlEDWnCw6yUSkuBa/aJ0wL9O+wYC00rSrYYqZMxO9EdnSxBLLu9GjD?=
 =?iso-8859-1?Q?DYt6gCX7WQsaF3o38UyiMJlWcQHq+YLIPJqwUj4Bi2Z6tME/Ut5eJr048A?=
 =?iso-8859-1?Q?aobt3UA3kEtl8zfxYzJ/h9w3sk3Jh1jakjWqFo7RJnVVP9ZgJcry4ig2fq?=
 =?iso-8859-1?Q?IzEcMAC0hgUfTNkU8GK8htMRNFWLLhCUOtdkzyV3zOY9Yc6W3AFaBUB8h1?=
 =?iso-8859-1?Q?IlPAQzQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Sf/Gjt1rfMd9Pl8Jw1o9omlnWxnHOy+uGbSPlGykLNM4t1dAUR8H42jmd0?=
 =?iso-8859-1?Q?Gmfyt+4qliwijjsSQZgaeleGDRaXVvzYJf8QYYJWpn4b6EI31G6Q58OMQb?=
 =?iso-8859-1?Q?wTXj2EKvNWPubxn4rWvc0/UxUjNCGCsxcR3eSdKro/MTRHkAtIN4ReKZOb?=
 =?iso-8859-1?Q?pmzQ0ia5BJB3tXIutystQKkz5baT+LfCLEfZN8hGkZQ4JGeGmZb5DLh8ab?=
 =?iso-8859-1?Q?OojvbfV9Zy0l5tcDjUtpsgEJs+QVEut0TXoFsbEj+SZ2Nk4LUVQSfiNiCC?=
 =?iso-8859-1?Q?EdIJFhhXfrp576MrwJQRwLGLfymHRmsKJoBIsQ1AWfd7DXpyUp5tQi1CuY?=
 =?iso-8859-1?Q?V7daNmJEiUkF2BGv1qD9qcznh7HcNpy1zuiJ6NWpOukbQKwEG/3UX7/7N/?=
 =?iso-8859-1?Q?LitLE08q95DtZ3UN67SZ0x+mgYSwzwrxHW7ozUHXJVo3qkRU1JbyK1Hph+?=
 =?iso-8859-1?Q?nOw5ZfCTlif1cXOuSOSB5sICXGff3y59AlbqFFtc7/1nWseMjiP599nn+j?=
 =?iso-8859-1?Q?VpyUnWcqs9PCkwTfJxrv9zcI96zktjoRW0hcs3PnPtlPCpNI4kOD5fpGHS?=
 =?iso-8859-1?Q?U33CFvcH7Vt2eFnWL0Au+4JOrZ8PEShk+ft0CPp8Awto8g/gnwhTBq0/Eb?=
 =?iso-8859-1?Q?0MkUx0tpXtruI2+omhGTtBb4DXBHbOgKeAJDrRuOpk4zxN5ZSKrJciFUlD?=
 =?iso-8859-1?Q?EFORTzDKVOIk3hOS9zx4IOZMPTur3YAPo1OLvB4JRiuaieGP1afKsBoaZ3?=
 =?iso-8859-1?Q?DGmoj5lilyd15bGNcV2XzCHmrFQ6nP+d53nR+p2QvkIplwBr/mWeLKuN67?=
 =?iso-8859-1?Q?hmPYdyqI7+eICOZJbr6Kgpno71plE9/aOW7oL4OA6ngb22R43woYSYtEnG?=
 =?iso-8859-1?Q?S1tfhVAA7bfBJHlQBuJQUimv1/dn0dbQFI61+za5VaE0NINReFe4FPNRqm?=
 =?iso-8859-1?Q?dkDRjY3L8nl1W71+HtM0lGyc2RD1jb63ueO6y9WUiJ9RJNuw+lpR5Mupoy?=
 =?iso-8859-1?Q?UI4j4CfRUSLb9bGZmRMcJYnI1rgFlXvAYTKAWG25VL5xyl0q26KofOPMY/?=
 =?iso-8859-1?Q?lGsm0fF2gVkC0st172NaxKwsvEjC1AMzX3Cu0n1q3Pxp4A9WjI1uakiJgE?=
 =?iso-8859-1?Q?DaEYbgRym/3Cg3JeYeCrmcPyYkTfjPBfUAzBfsBpHGS1xDarytj3zXkGyM?=
 =?iso-8859-1?Q?g2JzcJ+MbLC1xLqTUs0IQHqSrkfv5wTz/MCIZ7aKudNPydD1RA3WoOHUEb?=
 =?iso-8859-1?Q?ZVmowhe7aJSwti6CaXWGRJWQQ7lb+Bzn6WnLIQI6zR42cF8s0pAPPTxQAr?=
 =?iso-8859-1?Q?ECM+fYrjsdm9JWGhjeUJa/gEGN/ySxaq9u5KLtVF2Dil48DU+QR5ziESmP?=
 =?iso-8859-1?Q?0OFWANUXU7GFIUZDmQxtwZhSRjdUdODJ865WQmzgAeGJ8ijMnQ7wFX/7Xy?=
 =?iso-8859-1?Q?JUSrMDFQdcBCeX3MGapxuGzNC85hjr6R3np0ILVFFKQrkuYJb7lYAWTNrZ?=
 =?iso-8859-1?Q?aOOMzaQUhrBeTFZikF9ffW4ZaVRS+vUmXCC0zdTGAjqFx1ETK283eOq6PY?=
 =?iso-8859-1?Q?9V41FTpGxFdUR6xjUyAbWn3rs/f8Y3K5DlDIbPXUB6wMDKhAEbL8l8v7Qw?=
 =?iso-8859-1?Q?ULfebSIP28qt2BtF3DzKipAC7dhIvOC9jhEX4ijZpsYefFNmsbONRCgA?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8607d37e-6679-41b5-cda5-08ddf10c157d
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 08:20:35.8346
 (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: bDiDLms0kG0CGOd2ovImZXyOM2Cc5Y4/kVQUSRetGgjiw6SDprAtudRZ9BSITj4GlExzxJg9oDrcsiPnLT8F9JMe4KDN5YKJaFPd7mpEPXk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9468

From: Grygorii Strashko 

Split is_32bit/64bit_domain() macro implementations between arm64/arm32.

Signed-off-by: Grygorii Strashko 
Reviewed-by: Volodymyr Babchuk 
---
v3:
- no changes, add tag

v2:
- fix comments related to macro parameters evaluation issues

 xen/arch/arm/include/asm/arm32/domain.h | 20 +++++++++++++++++
 xen/arch/arm/include/asm/arm64/domain.h | 29 +++++++++++++++++++++++++
 xen/arch/arm/include/asm/domain.h       |  7 +++---
 3 files changed, 52 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/arm32/domain.h
 create mode 100644 xen/arch/arm/include/asm/arm64/domain.h

diff --git a/xen/arch/arm/include/asm/arm32/domain.h b/xen/arch/arm/include=
/asm/arm32/domain.h
new file mode 100644
index 000000000000..1bd0735c9194
--- /dev/null
+++ b/xen/arch/arm/include/asm/arm32/domain.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ARM_ARM32_DOMAIN_H
+#define ARM_ARM32_DOMAIN_H
+
+/* Arm32 always runs guests in AArch32 mode */
+
+#define is_32bit_domain(d) ((void)(d), 1)
+#define is_64bit_domain(d) ((void)(d), 0)
+
+#endif /* ARM_ARM32_DOMAIN_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/arm64/domain.h b/xen/arch/arm/include=
/asm/arm64/domain.h
new file mode 100644
index 000000000000..1a2d73950bf0
--- /dev/null
+++ b/xen/arch/arm/include/asm/arm64/domain.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ARM_ARM64_DOMAIN_H
+#define ARM_ARM64_DOMAIN_H
+
+/*
+ * Returns true if guest execution state is AArch32
+ *
+ * @d: pointer to the domain structure
+ */
+#define is_32bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_32BIT)
+
+/*
+ * Returns true if guest execution state is AArch64
+ *
+ * @d: pointer to the domain structure
+ */
+#define is_64bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_64BIT)
+
+#endif /* ARM_ARM64_DOMAIN_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index af3e168374b4..1a83f3924fb7 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -22,11 +22,10 @@ enum domain_type {
     DOMAIN_32BIT,
     DOMAIN_64BIT,
 };
-#define is_32bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_32BIT)
-#define is_64bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_64BIT)
+
+# include 
 #else
-#define is_32bit_domain(d) (1)
-#define is_64bit_domain(d) (0)
+# include 
 #endif
=20
 /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119647.1464923 (Exim 4.92)
	(envelope-from )
	id 1uwcXw-0004lB-Rh; Thu, 11 Sep 2025 08:20:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119647.1464923; Thu, 11 Sep 2025 08: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 1uwcXw-0004l4-Ny; Thu, 11 Sep 2025 08:20:48 +0000
Received: by outflank-mailman (input) for mailman id 1119647;
 Thu, 11 Sep 2025 08: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 1uwcXv-0004XB-CT
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:20:47 +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 37216ba4-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:20:45 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9468.eurprd03.prod.outlook.com (2603:10a6:20b:59b::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 08:20:35 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 08:20: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: 37216ba4-8ee8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y5Dlbf9QjxWKGaBJfC1jScFbhD+lfvC3JGvihAD/xjmwJLqxpYhdmJAVzmY5COsHYvQSMBm9RPwD85K6lOF7vwaA1ZUJDw1dQWetNR9pgZ1By3iAKftaBnsQdd+SBF2oZRTwUf6ZsInsKbMqp/BQudpT6fk6xZ0kg/z8z/TDrLSas4xhGcGTpL/j1BHQmn010pUg7m2etdDD45zA6ceCQKrqvr7kbGm3eVPzoGY/OONplC+f0JN7spTXeWl3JmzlMucn3B0mwoiV4kQm0HtQeExU3rEy/TvJLfyjjXfrYzFJljYUyX16Ov2fC1K8/60jjHondLXQtGCAsF+dAPRa+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=r0z7Dk/e65IYeZmN6jBkz/XbdB5t9TmOI0aQg9z0ciI=;
 b=IAQOIrAZnkrFRM111J42aIo7Oc9nCs0AYGTabynfyuQOCqBT2NEoxJzl6Gzg2QWjNHu1J9NiHfx/xOpoEBQEGShd2Z5c9EZCR75roZNx/kzBent++SlkZxZHCGe9aBRC7YN0slQdp23CymKA/DVn8NXCAM5YxqoD0WbDrs8gigBQTx/wvHd7ny5Z0mhkJk9uCVKuvQIDOxIgPbg6Tq/X4CEiu3IDJH0KMy8+O751Mp/cLhr5dd96hMOY8jYGkg4nug+CqkB6gZpC9532s79RATJbmLs1wc2WCB+xwvBY+S9Kd5gF4Zd8FsCLqTUTk2GKwlhY/HIYGx6OfZIMWVMzgQ==
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=r0z7Dk/e65IYeZmN6jBkz/XbdB5t9TmOI0aQg9z0ciI=;
 b=HzwaJncewigMb37RwfhJZgWjZuH8O4b9aYVTbiGuFPChp2vXI54XT4oMHecTQU+bmtw7aOQN+cZiDqQJ1Ww0wi0vKn/8lOINsgmmHgVqMJDmZuvo32C8DsmmT4mvV2ReWxPrE7NDFREVQqv8SmtlTCpt6fCzlhRgwZmDRwnqqjYtVweluOZVX0OPSr89EMW1YjZP9Hf2lAXwz3yxl+BobJ3GDrd0XL1rvB8ZI3qq+u4tbgvxG5obOHVUG00KmBmd8mF4SgVxzLZeGTT/q5h9690ybyLNmCx6EiFXisTYupFXQ182FtMAhqLgb0FiWCAbpcc7IaNZcCnE0V1yjMUM6A==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , 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 v3 1/4] xen/arm: split set_domain_type() between arm64/arm32
Thread-Topic: [PATCH v3 1/4] xen/arm: split set_domain_type() between
 arm64/arm32
Thread-Index: AQHcIvTy08CUia/8TkW/gNSEXuqqIg==
Date: Thu, 11 Sep 2025 08:20:35 +0000
Message-ID: <20250911082034.1326377-2-grygorii_strashko@epam.com>
References: <20250911082034.1326377-1-grygorii_strashko@epam.com>
In-Reply-To: <20250911082034.1326377-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB9468:EE_
x-ms-office365-filtering-correlation-id: ecbf077b-3b4d-402b-fe10-08ddf10c153a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?VJYnL/Jq7bj8bwY9q1062AV+ck/iAm3/6wND+u7YxVEHDW8nZyr4EKq3o0?=
 =?iso-8859-1?Q?MHTbY9F5ix4/+rEBYHD4k+KS7p2FdjqJGY1cdCOADmsx2kirrJCjXKuzvR?=
 =?iso-8859-1?Q?Kc/80nE/uWRs9wCJteS5C92LuQg3kKSASQOQpS1Ju9tWoweqgc/ewhbEAF?=
 =?iso-8859-1?Q?x37t/muSIgR5SMgUHJfVTWT2MtrAfX4mdLp/LYQQudO9PwyvmVmdFk4ySr?=
 =?iso-8859-1?Q?YGjbLImbf2b7rBYjdpGUyJ4oOG3P9dbhWQF3WU63V34XvxvddEXoeuxbRg?=
 =?iso-8859-1?Q?Wi09Whr1E2uUcdC3XkCu64qm8oiiUUobpzejQdplwIKbVKN7gnHZdcLekj?=
 =?iso-8859-1?Q?0DL5tgFnXsQbRE6OCQvWLkUCx3Kuj/SaYCMi5wc9PwEi0OvL/VljOK3wLV?=
 =?iso-8859-1?Q?cGziXQjCnlW19RVR6EqAHYijGmhKXnDtcN7aNyaK8qiv6njGtKvDH4TI5k?=
 =?iso-8859-1?Q?BRKneCfexQ0XfAf0XFnY28Kkw8Cu+66c0ujo0G8hNzOWa2V3CpqGizZQ6N?=
 =?iso-8859-1?Q?JImdr2gWaejKzF6I+fAqPk8xcSeEUB1VaT0AiOED+WKy/TvUWegPQX2VIY?=
 =?iso-8859-1?Q?AKYNN4UfVitid41y+8LlZ5BOKQzxYv4GaetPcjFNXOjYKqXJDbVWINPUok?=
 =?iso-8859-1?Q?f98I2IruvLx9tXX1SDHFu7pIkNgZLUoS780G3m6p6ID5K34wJFMjaOSn2g?=
 =?iso-8859-1?Q?QBq/lvUKUoiph0Pi6UGwlnG2NBZL9+1ASmX1l5iG0++BCAZi8um5kTdLGi?=
 =?iso-8859-1?Q?8i8IUKAv78n+sBt/cAD6mOo38iL3uuuOVQ8V1FksYtB9Rn+deeNen2gPlv?=
 =?iso-8859-1?Q?GWI3rNfAz7tHVkNTuSKD7FRHjNZUsQMHAaKK8bw+bhEMuv+gbEU7YfSGOr?=
 =?iso-8859-1?Q?3wtbv47TxKjgtlSvJp0H6Q2S60J76GEiLDe4iTCE+ybGJRe2CdujPZTIZD?=
 =?iso-8859-1?Q?VUdchqxXtRwoTHl51evfYp4j4jeSYZQEpLFSRAzzJSZrR7Y/wtMhbYt4Qd?=
 =?iso-8859-1?Q?jPx/NYfTfetUnjyW57jvburdhcw49u3fUJ64rLbD1r2EX2oBhem4HVvzzY?=
 =?iso-8859-1?Q?Mh0bd6EDoUuDDjjUoI1Zn8Ci/BAlVE23+xH02vi+vJ8dmZ7iBPAwCh+2z9?=
 =?iso-8859-1?Q?rQKfDmj8QNJUDIvQSWDSLE0Z9GsePueY4ZMWDLYlgFRID9R6KJ4vNlFOcl?=
 =?iso-8859-1?Q?3Mxzq2TtTCne/Vt7e+AbnqVLD69bQNE1h67PhIfZEislWelgC9NAWWuDkC?=
 =?iso-8859-1?Q?P9En6LhgpsxyfsQ+vftz2aHgiNtYvy2EWr6RqMrm60EOPBsP7i6Tfd8PDv?=
 =?iso-8859-1?Q?PSHAQJA4zPEJujYh6OyBvTQrm9A/DaWa8sIBBWh5QJM2DPmADxbgP1maKs?=
 =?iso-8859-1?Q?Au7JZ+ACDISNbfbo5+LTl7TeJ73XGrK2yNapINmPciNJ4PGtFD8SdlohtX?=
 =?iso-8859-1?Q?5ltg2u2fvMwEN1GZ28ACwQPcDHnfN5Nq4c6lBYIs+XmWXqoUHUJgEPYkE3?=
 =?iso-8859-1?Q?jePTs70BkZR0HgYAOaeJnKPteNbPCMKH7Ed0e5V4tmbw4ZHhgoh/p04PtA?=
 =?iso-8859-1?Q?dpo6m2A=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Cx0h+rWVDro91ubKCEtocCa+TVCPUdbD0IxJc5NcParkWL6BirYJqxMwRo?=
 =?iso-8859-1?Q?7ICsxowwOlKnwOBVj6BohOoqzyrX/6zTUBF9d2RxXYrYoPJPU1lCRRys/i?=
 =?iso-8859-1?Q?87JnWAOm4cuOUO2h4KlBU3KojEtkaf1gygeQR13wBfKAnYZtrNxUpthIea?=
 =?iso-8859-1?Q?xtQTzFNFssx/IoPtiGdJ+XXVHfCf81h57tYbw6aeb6lnznWZHnUmCVWd3M?=
 =?iso-8859-1?Q?kQHh5TwF3JOd592Ni+QfhSCO/jMcmHX083u6+AuYN70Oad+s/9xpw/psQj?=
 =?iso-8859-1?Q?z4UVdNFxuLBVl/ngngGXCu2UOGZzLBMbZC7m/E1rn/kw/H8+Gxcnt/Ddbr?=
 =?iso-8859-1?Q?cUZbUXkdmMDJPTHVApWlKCUzqLVl2TP959d7OjEU2ETiVODJKZyGSLxxoP?=
 =?iso-8859-1?Q?9DHp9FDJ+VURD7C7t8BSHlkDP3w+zeCfciUP5V3T23Jp6nM16WzexCxHR4?=
 =?iso-8859-1?Q?mwRxmUcozO0PM8drgwpabrYLAn7yqdi3gRysx4IihC0EJiuNpLvY1rpgJT?=
 =?iso-8859-1?Q?OWyICesSMcICe+pLYEyXYSPCYApMvBSPNlBBiEr6wXp92y/ZdTK3x5LMJy?=
 =?iso-8859-1?Q?9WYAVLp9d2wWOrKl7VFvVL8nCNKpDFfnj0qnzVEa4R7maMGxS84GKLQReg?=
 =?iso-8859-1?Q?g5ZlAYtzG6CODf1ZfIMUroLmo0300y1kZBvXhpgxQk7NcymKo/zSk81fvf?=
 =?iso-8859-1?Q?Eucxo1EVAALQ0tQfE+cCtEg5/5HDWMXj9C0ocIhvrj2TOGnvsinU9L5bwx?=
 =?iso-8859-1?Q?0nmJCbsYFKcpCv6OATHc5hNnMGf5SRskDNACgykH3IKI2glnYUn1eCCT/F?=
 =?iso-8859-1?Q?gVyKHt+1aGLoiuhWE1XS1YPzHFtFzzdbySwoSYgddjEv+MwERaZEQfZqNB?=
 =?iso-8859-1?Q?8vLRgzEtzW6KUdS2OS69zosYUYLrlZSqUChHpaplSQa+C4yKF8YVU3mDkb?=
 =?iso-8859-1?Q?VWZxE/nB1nDVdQTq3JP9m+OsNyzmBw8AcaZplCWBMUSitlqXhpLSXmVQik?=
 =?iso-8859-1?Q?Ok3sCqJNDmwqG57CpHU1FYAb9sA3kouy2iblMO1dy4a3Z98WIPbDG051hK?=
 =?iso-8859-1?Q?+vlxDf3bsw6EH/fNNVKLWYiv80qmpw1hbHvs3OQm2XaEug6WtKz9aZWeB1?=
 =?iso-8859-1?Q?XeQkDB/NqZUrAZ7tk51YrWu1aTv597yEXFcfyvvvTq8SnEQt8rn/JZDT2X?=
 =?iso-8859-1?Q?W+Kh79WofZ1aYfULFpAP0u6+3E3nGI8qfmd6AqIGRvf1S6ub/hsOmNiJ/D?=
 =?iso-8859-1?Q?oVLnJlLtwMxjelMh5Vd2wytvshVulQGjEpUuSVreIae+5cAQep+CesV0bp?=
 =?iso-8859-1?Q?PI/4l/pIfDdad25uExBO9TqVAYYIXKjwO4L3GTbbShAxS/fIie6Xd/mQuV?=
 =?iso-8859-1?Q?6l1ynsgFxB4wWZDOsCZ+HFKoQdsVjmZQCGfH1zLJP0Xzut222OfTSg+Lci?=
 =?iso-8859-1?Q?oQc5XxW8GGQrPqye4PRIPD17k2srHhk6FixRBCaqwBWfAxFHVK5Mg8G8TS?=
 =?iso-8859-1?Q?v8NA5c4wLXChhbcwTtSIIjWoHrrS8aBOwYSLgkA0TjjB4/hch5elU12shP?=
 =?iso-8859-1?Q?PuScpq+3cQLZr8l+M1+pRg0vQZt96hZXuM/Wb1iQ1grw0LYP6yR1DdL9Fa?=
 =?iso-8859-1?Q?AJP2A4sTnH71VsONaZ7hpyVwE9wd+8KvttvBCg9x+MnEfsoqERS70Ltg?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ecbf077b-3b4d-402b-fe10-08ddf10c153a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 08:20:35.4245
 (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: 4NiV5xOTvIRNtmwNevR+jHo4C+nylSUV1aDRzK0a8cmP7/w03BmyXgzNCso0XImfD2vRRtDTd5v/2QmphZp/ygYYrOWDwtkbENVbl4KODHg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9468

From: Grygorii Strashko 

Split set_domain_type() between Arm64/Arm32 sub-arches as
set_domain_type() implementation is going to be extended for Arm64.

Signed-off-by: Grygorii Strashko 
---
v3:
- mark domain-build.c as "init.o" for make

v2:
- no changes, rebase

 xen/arch/arm/arm32/Makefile       |  1 +
 xen/arch/arm/arm32/domain-build.c | 22 ++++++++++++++++++++++
 xen/arch/arm/arm64/Makefile       |  1 +
 xen/arch/arm/arm64/domain-build.c | 24 ++++++++++++++++++++++++
 xen/arch/arm/dom0less-build.c     | 14 --------------
 xen/include/xen/dom0less-build.h  |  8 ++++++++
 6 files changed, 56 insertions(+), 14 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain-build.c
 create mode 100644 xen/arch/arm/arm64/domain-build.c

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 531168f58a0a..969f24858cb5 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -6,6 +6,7 @@ obj-y +=3D cache.o
 obj-$(CONFIG_EARLY_PRINTK) +=3D debug.o
 obj-y +=3D domctl.o
 obj-y +=3D domain.o
+obj-y +=3D domain-build.init.o
 obj-y +=3D entry.o
 obj-y +=3D head.o
 obj-y +=3D insn.o
diff --git a/xen/arch/arm/arm32/domain-build.c b/xen/arch/arm/arm32/domain-=
build.c
new file mode 100644
index 000000000000..e34261e4a2ad
--- /dev/null
+++ b/xen/arch/arm/arm32/domain-build.c
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+
+#include 
+
+#ifdef CONFIG_DOM0LESS_BOOT
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
+{
+    /* Nothing to do */
+}
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 6491c5350b2e..c5d3479f6b96 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) +=3D bpi.o
 obj-$(CONFIG_EARLY_PRINTK) +=3D debug.o
 obj-y +=3D domctl.o
 obj-y +=3D domain.o
+obj-y +=3D domain-build.init.o
 obj-y +=3D entry.o
 obj-y +=3D head.o
 obj-y +=3D insn.o
diff --git a/xen/arch/arm/arm64/domain-build.c b/xen/arch/arm/arm64/domain-=
build.c
new file mode 100644
index 000000000000..3a89ee46b8c6
--- /dev/null
+++ b/xen/arch/arm/arm64/domain-build.c
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+
+#include 
+
+#ifdef CONFIG_DOM0LESS_BOOT
+/* TODO: make arch.type generic ? */
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
+{
+    /* type must be set before allocate memory */
+    d->arch.type =3D kinfo->arch.type;
+}
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index f00912a1ca85..713a90c3ad79 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -237,20 +237,6 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
     return 0;
 }
=20
-/* TODO: make arch.type generic ? */
-#ifdef CONFIG_ARM_64
-void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
-{
-    /* type must be set before allocate memory */
-    d->arch.type =3D kinfo->arch.type;
-}
-#else
-void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
-{
-    /* Nothing to do */
-}
-#endif
-
 int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
                       const struct dt_device_node *node)
 {
diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-bu=
ild.h
index faaf660424b2..4de8d9edba52 100644
--- a/xen/include/xen/dom0less-build.h
+++ b/xen/include/xen/dom0less-build.h
@@ -57,6 +57,14 @@ int init_vuart(struct domain *d, struct kernel_info *kin=
fo,
 int make_intc_domU_node(struct kernel_info *kinfo);
 int make_arch_nodes(struct kernel_info *kinfo);
=20
+/*
+ * Set domain type from struct kernel_info which defines guest Execution
+ * State 32-bit/64-bit (for Arm AArch32/AArch64).
+ * The domain type must be set before allocate_memory.
+ *
+ * @d: pointer to the domain structure.
+ * @kinfo: pointer to the kinfo structure.
+ */
 void set_domain_type(struct domain *d, struct kernel_info *kinfo);
=20
 int init_intc_phandle(struct kernel_info *kinfo, const char *name,
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119646.1464913 (Exim 4.92)
	(envelope-from )
	id 1uwcXu-0004XO-KS; Thu, 11 Sep 2025 08:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119646.1464913; Thu, 11 Sep 2025 08: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 1uwcXu-0004XH-Gu; Thu, 11 Sep 2025 08:20:46 +0000
Received: by outflank-mailman (input) for mailman id 1119646;
 Thu, 11 Sep 2025 08: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 1uwcXs-0004XB-VW
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:20:44 +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 323dccd9-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:20:37 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9468.eurprd03.prod.outlook.com (2603:10a6:20b:59b::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 08:20:35 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 08:20: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: 323dccd9-8ee8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DhgfujdFGKbgZNmB7wZtwA2+nBKxqdGVVtMR1ZPbhmhj6goPIjXfK+mXn/vLkjSU5xdhn/IPtFNXlsBk7EjLWhNDtFl62uI941b/hfCopmGpHXpgJ5w86JVNO/zb1pqZ7AjAgOzWxnU6jEpiWGrATAeYnZEXLTBaG0o6s0+aGJTrDDp6Yp9f/nAqu+lJM9EFhRvxb3I/XjF9m9HxmL4nzTow+1PUMCpp/lzVqlc2dIcTaAUYsgEsdjWnZWasl/Qq+Nnrbm9cQC95BxX+ohjtSfliY8ivw7eXHbA58Jz+9RweFgLzvmBD6i0CmNdFQIvnC86r1kgj0YAeMZipL5Wy0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9ZP1/GNLyYNR7SY89GsUWKdIx7nrZHZbAe/tWpM58Vk=;
 b=Kbm40uKqQm9sIhOFFXyzFyVL3eRkmzkDe9gen1XHC3mTzItLro+RyS5efPtC9ldCILR/RvxMLDDRTIpFiYVai2kDtTmApIslRSUBTvR2DpEi9mVJujfUGzy4C+l35dBc2680uNqiK64feChsrlFvYdZpReIM7JS6mByDxerT7K31dWwzgmoR4mptFViPb0wJMJxF0tLRVfWMV2NDTT1F6V6FU5UespUatLdUcTKQ47JZVWeDI5Ozace8VFOFTc+9cGFJ3zgF3+LMaNE/aQHQEZ/DZ1qPiOSu1rN5HTPkTkAoGAbtZojKe4ou6AHIB4WDiSe/nSDKk03SrqzpdIOqdg==
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=9ZP1/GNLyYNR7SY89GsUWKdIx7nrZHZbAe/tWpM58Vk=;
 b=DX7JOA8NnzBu/K4H/KneioV6F5FrYmQO+CpBNEBXHPqhOAE9HkrXxDrpviZ9Y1h6zS3s7gD9SOH/f9ds0Og4xX+mokqo1oKNcmHXXJdHA4lsWfzlzhBsM8vuf5jESISRekSOCQJlU2pJt+tr0YpKsaaekRt4oD4SDHaDz1zTEJ771MCILuvKpUIQmjLE379+r7/O1xcK/EU1Q6uSEZoCgAlj4fbuxP+ObPELcMAPzoVXPX6jx8WiSjKZuyQJimPtrm+wrpb9SMWkH9DjGiehV2ic9eO0US8+jAhDOOZMMLZgqDeWeVMJ2K1lF8A3oTLw1WGTB7kh5Qje2LjYK3ybpw==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , 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 v3 0/4] xen/arm64: allow to make aarch32 el1 support optional
Thread-Topic: [PATCH v3 0/4] xen/arm64: allow to make aarch32 el1 support
 optional
Thread-Index: AQHcIvTyx9z2i0DJTUamNSgeNa0v/g==
Date: Thu, 11 Sep 2025 08:20:35 +0000
Message-ID: <20250911082034.1326377-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB9468:EE_
x-ms-office365-filtering-correlation-id: 830e03e5-1440-4770-6d50-08ddf10c14ff
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?vmTNMeoUB/BH8soVYGey1/OUhMt3JARGEjUudixBZYfrAQA8taRA2holf+?=
 =?iso-8859-1?Q?uLBWlAJLos29qVQRdfRjyrWQ4hC+zvURduMzPEu9s0SqpAdSJHjmb+O3O5?=
 =?iso-8859-1?Q?AO4cDX7NPQfjyiQcxmqqeGFLwUdqZ4nV+XUnS0ch40mczpj4A22Aheldu1?=
 =?iso-8859-1?Q?5um8o7dMjxPNpm2ZVLIQ1RGOhNDS5/lHhEldX883skWWIH8+6Fo3StDfa5?=
 =?iso-8859-1?Q?jAn6XhFbH6g9XIwLXhtwE/bWAt+AZPZvSh4LbwqLSu9KS8JFC292BQ4nq9?=
 =?iso-8859-1?Q?7tumzj5dK0Szi2EWkS2HlV/XDhAtCWs8ce+xs8D3iKMIqTDGqr0faLbjSv?=
 =?iso-8859-1?Q?uLX2oZIQ6C7ga0vhD+XAaCNPriJViD6Uz4/iH7/n/exq21bQmQmcQaq1KI?=
 =?iso-8859-1?Q?scJkwOFWCsKfQf66ExVQnpsLOvizxwIG+KAI8RFcfc8+jRXOqbMUgqInmc?=
 =?iso-8859-1?Q?ZP3j66MG5QJ59G6LU5rleDLe+NBCRQGQCV5/zTiprovA06PQYbW2ndTjpx?=
 =?iso-8859-1?Q?UQy1m4yL9gbGuWsY6A6Erxj91bGcFsun5ZHK1d29ocVrP+KdcKaQjxFzEi?=
 =?iso-8859-1?Q?8Crr6WrEBWmhzaX3vgmhDOXy2Yc8/IHfUD2bvjBGAi5cpEQMzqUlm2tbxx?=
 =?iso-8859-1?Q?fdIN7jO4fnvxs8OygDuyBvZcZDOg/mBkX59ig4xYMTYtGRhZFulWjWA8+x?=
 =?iso-8859-1?Q?JlEZAy7dslP6TmS0ZyHjlYudEDFCteRk/I4VoI9XVrZ79fGpfH+lrsS6Su?=
 =?iso-8859-1?Q?seBKlkc0MECqZ+P3b35PulCefqnyA8c8ZmBa57Lb258MHkmx+Z9BBfJ6Ah?=
 =?iso-8859-1?Q?k0bsUcJNjDcZrzLhyxC4neE1QmP6ZnxeVtaTSxw4OmifV5WHn6J5AizUSp?=
 =?iso-8859-1?Q?PESAxbIWXtfUmzdlACiQCKTbWxMNpAJUlwnNNXQhJwIqWkR+dsash2IcW2?=
 =?iso-8859-1?Q?LASQ9DIv8rwypHgES3VWAmn6N/aE88PwkKMihFIuS3m07n6k3dw7VbZ3fg?=
 =?iso-8859-1?Q?8SS0FEJXa7P0+fBSc3X61OiM/G+GAj1jJdFkuSy0zymrinFQHB3jeHkKpv?=
 =?iso-8859-1?Q?nEsNcYBrbjyq62cy0YHpLMaKiQJj6nawokKD+w1rXsJFozr/+8l80/c+0Q?=
 =?iso-8859-1?Q?ApKtYAYFVPZGigEes1Ns4vgi/MXiszPjj3EE/H/uHbyl/MgUFj+O+ByoId?=
 =?iso-8859-1?Q?pkv+ZDn7KbA1X0bKsT3w+AU8YQPGKc/QqkiSZVOz+I/0q6uaP1FM78A7vH?=
 =?iso-8859-1?Q?A3Ilflep28A/6kAKTT7il4WHoxkY9nQ+iDNMTTpp6meJgu/DRV1sGlOWuX?=
 =?iso-8859-1?Q?aN29z1nOdmxubbJjQTTSkb8Jl6a9IjwLrnS465jX1Vuc4FABaiKin1vP1q?=
 =?iso-8859-1?Q?WTpALptJycfomi6JAvRDBtMI8UCuBuDdR4FWY3PYou81tmEYxGBzhHtfxD?=
 =?iso-8859-1?Q?Ff3Hxo6d6aXLdpuziIhdRNSFrHk8jlBVmSmzigaZooG8qejqSkpEDfsc/x?=
 =?iso-8859-1?Q?8=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Ejk/Anr+YAziaZ6Rx92j4PRrdQ77qfLpd2epfq11FLLGjVpRn5/CbcbGAB?=
 =?iso-8859-1?Q?zv5fzrGCpmtwu1bb1s2l4gErH4KGw+gtu1a865rg8jKg9yhoSiE4Uo4vGN?=
 =?iso-8859-1?Q?tjHGQBIkoDJypWvUSxgDNoLsqoDl0zmDrgybK+BKb5mWXLF8vWHAnycyPX?=
 =?iso-8859-1?Q?9ZJvRf9glAxgmq1xxOnshfGIahXwFVpT3W6xkAfBDWMZr+0Nkyjj4u9KKh?=
 =?iso-8859-1?Q?bfS7YHhHR3tDd9LMrl8Q0DFacUcCiE/59/Wmg76k7JCFwEADSJs/0ds7Lm?=
 =?iso-8859-1?Q?mudTjVehB7b9+aztKjdgGm72CmrbOuKaNLE0ewhRO2N6Pxh1nGo6dB/MaZ?=
 =?iso-8859-1?Q?oRV1B9XjOdYXbRTaX22UB0Pg9D6wAP8Ij8PO18Y26cWz9mLN3qn4Flc0xw?=
 =?iso-8859-1?Q?PBRnnUOwN+8d67S2hDq0dU4DEatBny49HL1m7PvFPbWbOQEsGcjPNR6EeE?=
 =?iso-8859-1?Q?hAhTlFQt3iVhCZOUWnj8VRo4JMPQT4Zka+Svrx9AGjM7AUrh9JHtJCMR7R?=
 =?iso-8859-1?Q?ueerRD9YOwvtioPv+RZmkixh24JUq3OmGMDSZQrMo+4GSk96C7uC0CD4i/?=
 =?iso-8859-1?Q?AfRE3joL9cMM5Gw/1FmV6l8UW9UfDx7CGWrx7EUazdEiCCVW6p68YAxZVz?=
 =?iso-8859-1?Q?ICSdszI4IC6ubkBPf78Muw0cRqtSASO5D+p9c7YXjO/F8XQggntobdQ2dX?=
 =?iso-8859-1?Q?dnMgyRzEycDgOUybf3XYBDy+a38VIQRrAawaks3UidpGEg6ixeTglMJPwh?=
 =?iso-8859-1?Q?85BYJhOee5VPLCC2VgxQSQ8wihl85nhw3ZZ3fcWGkv6oRul3Ew99vp5p7b?=
 =?iso-8859-1?Q?P1tHAWbNmlDKD8x5xxL6cfeD9kN+VxN5RoGzfy7NO2eosizoVy1DlINhXs?=
 =?iso-8859-1?Q?03vaPiVeBtVo+ZyaX4q7Au27/vlQ3YIeqLGHfxgpBYZkIODrGWkfclvQtD?=
 =?iso-8859-1?Q?pIpg6Isf1sQJ8b35oT1Cg3+evN8xkQb7emIZuCQljG7fyAkfmxWXaOr982?=
 =?iso-8859-1?Q?2GbI43LCcpajbeFZ9C9LbJ8EBq7pDKO9KomIgHJ7bZxKyQPKmiNK0Uk1dp?=
 =?iso-8859-1?Q?wFFyATy2/RoxFh8mU2tnP32biJxDHohSsDM5WCE0zg84rw42t4M9Sbo4EZ?=
 =?iso-8859-1?Q?s/ADY5gKyM+JB+mdfTuUxKw+UOfuVHuIi2GFt75ULddQiu+02btpqz069z?=
 =?iso-8859-1?Q?9AXNRhU+pdtzqZW0kje7aAKEvBe2z2S/wY6Fwxh+P6ZhLXaWx5Rnu8Diuz?=
 =?iso-8859-1?Q?tEhnAjicSAXU97LsSLPxssIZyWCfaOeVXc7cqnA2W/0FGfD+214zgFH3nN?=
 =?iso-8859-1?Q?30Qa5UrnqCeZfAlWMagIGYup8WhXJ3WBXu/1ZONwTAIioL5hvMd4yB3GS2?=
 =?iso-8859-1?Q?R8jskqkSXu7Mo/CKicdiYwW9QhBObdHG54H91LkT4aN2l0m9doy2BgtSwq?=
 =?iso-8859-1?Q?Ow5glYtTqwOhXNcUIyVvj4Ch/2ugDaKc2EyV/tLP6DCh4OQwTHwwY1x2da?=
 =?iso-8859-1?Q?nJoMhKZt7grisHrwDk0JCENuVWZeSABT/eKGVNvJqJm9xLUyt+H1lgsDBl?=
 =?iso-8859-1?Q?uukIhOQzhpqngwHVrRHpjIT+ECPLk7C4WOJOw8Iex8A57cQOw1zAiLYEE6?=
 =?iso-8859-1?Q?2+yhDXl4pHWWTUSmjaCpHB8hoCK16xgxI+yJLAB0ZoQ+biMSoqyxcroQ?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 830e03e5-1440-4770-6d50-08ddf10c14ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 08:20:35.0394
 (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: JmixxRq9Qb4oVl7lxw7D5yNe8Zgf9yoSS1DnoBnNkZsRzSrImt9ftT7ROKFaLfG5tL0bHxpBNhnkIqzkZlMq16teKOD6hOXaoRSsZvsN8PU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9468

From: Grygorii Strashko 

Hi,

During review of v1 [1] of this series Julien Grall raised concern that=20
"If the desire is to make 32-bit domain optional on Arm64.=20
Then I think it would be better to pass the domain type when the domain is
created (IOW add an extra flags to XEN_DOMCTL_createdomain)." for which
I've sent patches attempting to start solving the problem [2] and try to
probe guest kernels before creating domains. While proposed changes [2] is
under review and hence there are definitely more work is required I'd
appreciated if current series can be considered as it's Arm specific only
and working (and tested) with current Xen in its current state.

Now Arm64 AArch32 EL1 guest support is always enabled and built-in while no=
t
all Arm64 platforms supports AArch32 (for examaple on Armv9A) or this
support might not be needed (Arm64 AArch32 El1 is used quite rarely in embe=
dded
systems). More over, when focusing on safety certification, AArch32 related
code in Xen leaves a gap in terms of coverage that cannot really be
justified in words. This leaves two options: either support it (lots of
additional testing, requirements and documents would be needed) or compile
it out.

The series doesn't affect on Arm64 Guest's EL0 32-bit ARM execution state
support.

Patches 1-2 Prerequisite patches
Patch 3 - allows to make aarch32 support optional by introducing Kconfig op=
tion
          CONFIG_ARM64_AARCH32
Patch 4 - enables build-time optimization of AArch32 specific code by redef=
ining some
          is_32/64bit_domain() macro as constants

Tested (CONFIG_ARM64_AARCH32=3Dy/n):
- dom0 with AArch32/64 kernel
- toolstack create domain with AArch32/64 kernel
- dom0less domains with AArch32/64 kernel
- creating domain with AArch64 kernel and AArch32 EL0 rootfs

Changes in v3:
- Kconfig ARM64_AARCH32 use dependency from EXPERT instead of UNSUPPORTED
- drop code for "do not expose EL1 AArch32 support to guest in ID_AA64PFR0_=
EL1 reg"
- apply comments from Volodymyr Babchuk

Changes in v2:
- dropped patches
  - (licensing issue) "xen/arm: move vcpu_switch_to_aarch64_mode() in arch_=
vcpu_create()"
  - (problematic change) "xen/arm: move vcpu_switch_to_aarch64_mode() in ar=
m64"
  - constifying is_32/64bit_domain() macro gives most of results in terms o=
f coverage,
    drop regs changes for now (can be added latter):
    "xen/arm: regs.h split subarch definitions between arm64/arm32"
    "xen/arm64: constify regs_mode_is_32bit macro for CONFIG_ARM64_AARCH32=
=3Dn"
- use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 suppo=
rt
- rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with =
any initial domain type
  set (32bit or 64 bit)
- fix comments related to macro parameters evaluation issues
- do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
  AArch32 is disabled

Link on v1:
[1] https://lore.kernel.org/xen-devel/20250723075835.3993182-1-grygorii_str=
ashko@epam.com/

[2] https://patchwork.kernel.org/project/xen-devel/cover/20250731094234.996=
684-1-grygorii_strashko@epam.com/

Grygorii Strashko (4):
  xen/arm: split set_domain_type() between arm64/arm32
  xen/arm: split is_32bit/64bit_domain() between arm64/arm32
  xen/arm64: allow to make aarch32 support optional
  xen/arm64: constify is_32/64bit_domain() macro for
    CONFIG_ARM64_AARCH32=3Dn

 xen/arch/arm/Kconfig                    |  9 ++++
 xen/arch/arm/arm32/Makefile             |  1 +
 xen/arch/arm/arm32/domain-build.c       | 22 ++++++++
 xen/arch/arm/arm64/Makefile             |  1 +
 xen/arch/arm/arm64/domain-build.c       | 67 +++++++++++++++++++++++++
 xen/arch/arm/arm64/domctl.c             | 12 +++--
 xen/arch/arm/dom0less-build.c           | 14 ------
 xen/arch/arm/domain.c                   |  9 ++++
 xen/arch/arm/domain_build.c             | 21 ++------
 xen/arch/arm/include/asm/arm32/domain.h | 32 ++++++++++++
 xen/arch/arm/include/asm/arm64/domain.h | 54 ++++++++++++++++++++
 xen/arch/arm/include/asm/domain.h       |  7 ++-
 xen/arch/arm/setup.c                    |  2 +-
 xen/include/xen/dom0less-build.h        |  8 +++
 14 files changed, 220 insertions(+), 39 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain-build.c
 create mode 100644 xen/arch/arm/arm64/domain-build.c
 create mode 100644 xen/arch/arm/include/asm/arm32/domain.h
 create mode 100644 xen/arch/arm/include/asm/arm64/domain.h

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:20:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119649.1464942 (Exim 4.92)
	(envelope-from )
	id 1uwcY0-0005Fq-EY; Thu, 11 Sep 2025 08:20:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119649.1464942; Thu, 11 Sep 2025 08: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 1uwcY0-0005Fc-BI; Thu, 11 Sep 2025 08:20:52 +0000
Received: by outflank-mailman (input) for mailman id 1119649;
 Thu, 11 Sep 2025 08:20: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 1uwcXy-0004XB-QL
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:20:50 +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 390e50a0-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:20:49 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9468.eurprd03.prod.outlook.com (2603:10a6:20b:59b::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 08:20:36 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 08:20: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: 390e50a0-8ee8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f31kazE/sanvu0MA5dvAsIS8MwlQtE9F4Lh755PvvUP3FoiAL2rU4ZaNNtzJXiRCvoMHH69kM3vy5dJqelmfpeFAwG57APzJA3S5UGfJgX1bmY6/BmOO5jzf6+S8LyTpg/j+m+TQscKQLxLRyoHTKj0koeujVBdIa+qz9h8Z6WTEs3OMD1Un8T9FzZBM/h56vpxPZgKjzG6Fa3RG32JB/1+EDpm8dt/Px5Gipgcv0eV7MQVL0FuCH85myY9HNtk0VRIEfq7bX8P2Q1HKtX4TfkEkBZ9PjlpFFXjh5rh7q3U7+pWniXlni2VSbX1EAIs/4jtPRuBYzHYTx/wT92vNtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=z65KxaMTQr4KAm8lPnNDYzfoTXixatyIXL79M+shcKg=;
 b=vDFOXOBJgGDKzHNYKeCnCB11hUEwgKYKIjVrOygjB/YcM9dfAXd+uLjPqOyayoDXk/V3aGRGvCaiM+x6dKoxSdcIT7fOc0V3JIIUhmIDUp7Fl2KdgP0vLdxvXMglwajGVMGLvXIEV1n27zdiFLn2Equu8F3/dgFrB1mfKMMLW9zROIgTYGm2/KcLJqHzN82z1ifwy9B7YFcJixOXHbtHFUsnvhZb2IkLqYqVu3pDwB/QobFBCr8N0t1GniddTRhZXSsvcmCV1Tq447Fc/E1hcfycsLXM0FWTfDmbMKTG9vGmAYszUyzOKy7d0LkXrJic8773yxWBwRUEtYRcBVw62g==
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=z65KxaMTQr4KAm8lPnNDYzfoTXixatyIXL79M+shcKg=;
 b=RYo+O7p5zcVUkShuPfkdLw6A5rvM4EpMlh9v/CfhL5Xr3N3Ep5ezPWD4LefzrnfPfBb9U2YfRZnWXGymBt/e5Mvm+boDy+DD10PkRx7sixU75v+Xm9wx/PkPnXgtYBD2wlRV5N3+CX7VKKSzJ0+T9rCt6mGP3ZJ4j+d23dA+ir9cjHV7XLyv1hj0bER8sqtWh2uFK/wDwdgLmW4G++E9ssgWV4Ln7ta1ICNOAkPHtuDdFxbf+1rZ9/dNKyH1coYcjq9KuXCIUGpI4ihR6z80SS78WFYz0sn/Kxmrzz9n3w0iX19I7HzjJ/dRnbuw5penFdXWVneYk4Qw/WWnd42K7Q==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v3 3/4] xen/arm64: allow to make aarch32 el1 support optional
Thread-Topic: [PATCH v3 3/4] xen/arm64: allow to make aarch32 el1 support
 optional
Thread-Index: AQHcIvTzIqcmf0LCqECkmnRAIM+hSA==
Date: Thu, 11 Sep 2025 08:20:36 +0000
Message-ID: <20250911082034.1326377-4-grygorii_strashko@epam.com>
References: <20250911082034.1326377-1-grygorii_strashko@epam.com>
In-Reply-To: <20250911082034.1326377-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB9468:EE_
x-ms-office365-filtering-correlation-id: f2fbb5db-4568-4c2e-0791-08ddf10c15b7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?FZt/mBHoz3QVv2q9xZCw0KU+lIacH8r8SVUADSDXzpcVQnZmhEAi8Ry2d3?=
 =?iso-8859-1?Q?Sb0bYXupP41RB6B0YmU6cTlVPpcWLiHJiy0+WoZzrhJFHgMOU+O43VXjuw?=
 =?iso-8859-1?Q?3ZIGsli1s2OPH09XKTMGUGRnrg5xjutsqrr7/xz8sog/MAptU2rbrdBsUV?=
 =?iso-8859-1?Q?gm6AMcBGQhDq/x16tSDcwaGPbQibLC0JaI+97lM1t5iuFW5q252VTWFBsE?=
 =?iso-8859-1?Q?a390MNouUY8YXlyZ243tiFMDRHa3efTMoI23FPhbWCboUkRYo7laLr6As+?=
 =?iso-8859-1?Q?4B9MXWOQs6gBN9a8irGYmVagmztIO902GQXeUlkTCQEFuI70XGw8Mucrfj?=
 =?iso-8859-1?Q?7+KQJG1z7sP7f50b583h8BEHBaFSPRsJLa4bPRpZQ2y0uxb1D8SJphLvs7?=
 =?iso-8859-1?Q?nrYLsYgDb7+V3o2fKvUIAVkiBQ552N3uAjK+ZvtRqlxxLqLazkWZHdoi4J?=
 =?iso-8859-1?Q?e5r2bZznf9fdIRJp67kI/bvCh3BB/M1XeT2mWfHnQeMAjQDdVLllDZl2sr?=
 =?iso-8859-1?Q?++NBWE6HbMz596l2wdiQTfhrL8lrMwbgHNKSd6G4/aorwjf6lmNsHkhnSP?=
 =?iso-8859-1?Q?cL/CUo9bMRlZup+sobRd2ypnVi/K0wgiYXqhQygoQAT6cwxBPV2MDQPR1i?=
 =?iso-8859-1?Q?SYOAwyjgif5Wgbr094e2I4w12R0ffz6b8MjZQ+NrpvLSh3s3LEuiZup8fE?=
 =?iso-8859-1?Q?BVnctAAg98t0zS5mogcsUP/jv6CvHukuvoruSEavWO7dHSehVgBL+4cjR4?=
 =?iso-8859-1?Q?VQ7AhkIVT8rOXsEEAQ3vuzK2vk1v6ZE8WCbvUwlDnpJB71rp5DHtD3WY84?=
 =?iso-8859-1?Q?1ATDOZXxnKzzfwu5jsGqaD94WqcvmKbu0C3mBQlvuB0jjvOu05oLG+Kcjc?=
 =?iso-8859-1?Q?jc+EtZxqdPmRpGgWNLT0yX/jPhaJHfDY0dX4SDs8TqA6UEtnLqaaDVi1Yp?=
 =?iso-8859-1?Q?eLZ3tgpZZ4MPPLsx0VZMpwZUbcdHUJO1/3EKM41LZO6pceob/cMjuUmm8x?=
 =?iso-8859-1?Q?vUv2P1hLWxxIJhsFR124f7zmC6AJIehb9P+TwvVjT2siOc10lZ841EY3yU?=
 =?iso-8859-1?Q?MQsjnRUqJLjI2WG4LMJxKS0E/MSki93HiHDoFDt2+qe6OlzateKujVdtAi?=
 =?iso-8859-1?Q?7CnsFVdJr57P8j94fh63+rhxI9rHTwHY+cOoFxm1mz3A9FmgqQ30yi5Tey?=
 =?iso-8859-1?Q?v58eQvAQHtQr7D8kfdohfEECci/QwBlfzbvjSpaVFhEc+CphRy8MyjaCkw?=
 =?iso-8859-1?Q?UHVAqVyHc5VKDecA99LDjfru/Ck64n6r1cImO2iZN88FjOIY1B4ujv5Ov2?=
 =?iso-8859-1?Q?rHog/ykQcUKcMaHgheAnCYeaHdOWIOvwq+ZyxL9YlPKlBuZIINuJg1zhkY?=
 =?iso-8859-1?Q?UX2osmd/16aOPxOlQZBVM0a19y8+T9zHANmxJFmjnIOAsx4+n62a+69DxL?=
 =?iso-8859-1?Q?HwyB9VKDfCHtuEen97YtuhsZxW1HurobgDuTvULAim4aWmPTHah0IetMmV?=
 =?iso-8859-1?Q?e+4unSxzTJYHfnJptNVJD9suxsMd6NIKbcUZ88dMLiCQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?/XjDFVAA5bI2LpvNPhSr42yvAWBuQ52zoCj7BcC/T/ORshhLH7wDVVZh2J?=
 =?iso-8859-1?Q?mrUvQaXOnxyMX+fbelVWIE4b7agdnuCZC43BW5g70zyR3JNFIzoBubLx9q?=
 =?iso-8859-1?Q?BBIDsMc332wFypXrj2iztrgjzlZl9x94tmXNqG1JTaH1ACt4HXp5ZBAVF4?=
 =?iso-8859-1?Q?oRxF2QXSPhTo/+t2eegKJ8LHJGr/aPxzROx9wGqH+SNV4MIiCDPZUhxndn?=
 =?iso-8859-1?Q?IYTP0oEjAtRiAZYS464lVFWv3mq1Ci0lAdj+MfwL5nhJeAeP/QJOTO6SQe?=
 =?iso-8859-1?Q?Hnji4LOC/keSnKAx7vpp/cFEklT6yzVqkpP20pHLtvgh7mWuPgSeiXMvWq?=
 =?iso-8859-1?Q?iPdBvRDiGHvgjK/gN9+TeJO1L8uPgZYQM5d41ci+smIgTiaTo0R3BCbQmT?=
 =?iso-8859-1?Q?6qy21CxFoplw+We1DAexlk3Tw9frzg/dn5v5CC8/wccmB6nAVm5zOvEPF3?=
 =?iso-8859-1?Q?Q8CK04el/zUpqw5W1unOILxnIbMCOb6rIz6neBY0p9nZ5395A/BZLVhGZh?=
 =?iso-8859-1?Q?M8ytTGza3owYcWMkq9d5RMuoqC9UEZFe42+LzN3mFGMSadObUmgVjB5/X5?=
 =?iso-8859-1?Q?ZHz9fOVtC5FcYx/0VO/rf407JyjjXpSyECVjTzbQ78kNKqMgm/DZbJP2vp?=
 =?iso-8859-1?Q?vaAlmX2o3G24qMpSbO0NM11LQwpbFZpS+qbQ30WRpAPG43KQiIA5yfC1vc?=
 =?iso-8859-1?Q?RebQ4ei2V2E6HIELDYMaVSPgLYLFXBITWZ5cKD8ARVrvzjoDxsGUWeSg6t?=
 =?iso-8859-1?Q?iqbwL/D4JHXvRoou33j22oy/kpPI9NavZTEbw7mWZsqu0awyLcEXrTIplC?=
 =?iso-8859-1?Q?C2ZGX7zHX6HRgCoQ2Q6xu6HHVBqN/Tfrw0gUz1j8J9cZHsuDrBH8vjU5LQ?=
 =?iso-8859-1?Q?UHiPBgf8ZOf3kCwQ7V/WNEcpndUCwBFLs8ZXiZUGqBLadvWVCIYYjb33FU?=
 =?iso-8859-1?Q?JbUzZyrtpE2wCTQ8wLF2Rqd2bJbFYp9lKNQqLG3wV7VUaplRnCDYj6fOoj?=
 =?iso-8859-1?Q?PjBxZMzz957krnjvywkUIMxX5tqLmRkdq3o9DJYxpDm+/WM67MuV/Gdh5d?=
 =?iso-8859-1?Q?KzNC7e/4trD5DhIlJR8Mq9dnc2ge4lEEBjhZFbflFlXQ+InNpFXkjYj+S7?=
 =?iso-8859-1?Q?LDrSR8358EYt3IhF8gWVmNxzBq9eitMB7otVYer24kHhOHZxrk9LGNADgG?=
 =?iso-8859-1?Q?RGrs+WXXSho4Gz4onqiBqloRcQFlzzoFhaAKGwHjoAg2HRCBCbXfUaWArz?=
 =?iso-8859-1?Q?djReQINhSRdYN6ABVQQiCmLhsdKg8WSS3R2JJc1uhZSctCRgKvluNSFI7J?=
 =?iso-8859-1?Q?ndyrDvRRw6d2q7i+iKFJCq8I0gsHyQU+e/ON+xkbuIZ/xa3tePl5r/7hzU?=
 =?iso-8859-1?Q?I3G5XZnLfVHOEwyCwQek9Y3T/HIgXaw50jvicHXSTdkQdyKHg8NF1CxdhW?=
 =?iso-8859-1?Q?rQ/Ec4pd5K045/EuVEktqrl9tqaihOGxA7kmWWZcDa/M/kdYXcFUh9VO5b?=
 =?iso-8859-1?Q?5Vgtpeq3JwLJ9g2bi8SqDxjmKSeu9RDTxuLAx9dks54M/vqnoLO6BYS9+m?=
 =?iso-8859-1?Q?6PpdVHD/R1doCH2pyxjOfd0Zn2sE1DNYnf54gjW+cjd50Qjolu7u1S8VUy?=
 =?iso-8859-1?Q?22L+/uOq+DxzbmXomdPyNWSEr5xmPnT/sk+Yx9ayrdNBHi/K+1LHuHeQ?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2fbb5db-4568-4c2e-0791-08ddf10c15b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 08:20:36.2416
 (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: w2RVB5thyNyxW+o/JvNw9FKA/P35BOCaLbLV9GioYx/zB2ByPEUqLFhKMRWdVa/noRzm0epgxP+eS6Mv5TJbfMIYPzmsoUU1P05xuQE4kJo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9468

From: Grygorii Strashko 

Now Arm64 AArch32 EL1 guest support is always enabled and built-in while
not all Arm64 platforms supports AArch32 (for example on Armv9A) or this
support might not be needed (Arm64 AArch32 is used quite rarely in embedded
systems). More over, when focusing on safety certification, AArch32 related
code in Xen leaves a gap in terms of coverage that cannot really be
justified in words. This leaves two options: either support it (lots of
additional testing, requirements and documents would be needed) or compile
it out.

Hence, this patch introduces basic support to allow make Arm64
AArch32 EL1 guest support optional. The following changes are introduced:

- Introduce Kconfig option CONFIG_ARM64_AARCH32 to allow enable/disable
  Arm64 AArch32 guest support (default y)

- Introduce is_aarch32_enabled() helper which accounts Arm64 HW capability
  and CONFIG_ARM64_AARCH32 setting

- Introduce arm64_set_domain_type() to configure Arm64 domain type in
  unified way instead of open coding (d)->arch.type, and account
  CONFIG_ARM64_AARCH32 configuration.

- toolstack: do not advertise "xen-3.0-armv7l " capability if AArch32 is
  disabled.

- Set Arm64 domain type to DOMAIN_64BIT by default.
  - the Arm Xen boot code is handling this case properly already;
  - for toolstack case the XEN_DOMCTL_set_address_size hypercall handling
    updated to forcibly configure domain type regardless of current domain
    type configuration, so toolstack behavior is unchanged.

With CONFIG_ARM64_AARCH32=3Dn the Xen will reject AArch32 guests (kernels) =
if
configured by user in the following way:
- Xen boot will fail with panic during dom0 or dom0less domains creation
- toolstack domain creation will be rejected due to xc_dom_compat_check()
  failure.

Making Arm64 EL1 AArch32 guest support open further possibilities for build
optimizations of Arm64 AArch32 guest support code.

The change doesn't affect on Guest's EL0 32-bit ARM execution state
support.

Signed-off-by: Grygorii Strashko 
---
changes in v3:
- Kconfig ARM64_AARCH32 use dependency from EXPERT instead of UNSUPPORTED
- drop code for "do not expose EL1 AArch32 support to guest in ID_AA64PFR0_=
EL1 reg"
- apply comments from Volodymyr Babchuk
- reword commit message to mention that patch affects EL1 only

changes in v2:
- use Arm64 "cpu_has_el1_32" in all places to check if HW has AArch32 suppo=
rt
- rework Arm64 XEN_DOMCTL_set_address_size hypercall handling to work with =
any
  initial domain type set (32bit or 64 bit)
- fix comments related to macro parameters evaluation issues
- do not expose EL1 AArch32 support to guest in ID_AA64PFR0_EL1 reg if
  AArch32 is disabled

 xen/arch/arm/Kconfig                    |  9 +++++
 xen/arch/arm/arm64/domain-build.c       | 47 +++++++++++++++++++++++--
 xen/arch/arm/arm64/domctl.c             | 12 +++++--
 xen/arch/arm/domain.c                   |  9 +++++
 xen/arch/arm/domain_build.c             | 21 +++--------
 xen/arch/arm/include/asm/arm32/domain.h | 12 +++++++
 xen/arch/arm/include/asm/arm64/domain.h | 23 ++++++++++++
 xen/arch/arm/setup.c                    |  2 +-
 8 files changed, 112 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 5355534f3d5e..0289ebfe04f6 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -266,6 +266,15 @@ config PCI_PASSTHROUGH
 	help
 	  This option enables PCI device passthrough
=20
+config ARM64_AARCH32
+	bool "AArch32 (EL1) Guests support on ARM64" if EXPERT
+	depends on ARM_64
+	default y
+	help
+	  This option enables AArch32 (EL1) Guests on ARM64.
+	  This option doesn't affect on Guest's EL0 ARM 32-bit execution
+	  state support.
+
 endmenu
=20
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/arm64/domain-build.c b/xen/arch/arm/arm64/domain-=
build.c
index 3a89ee46b8c6..cb0afc9df19e 100644
--- a/xen/arch/arm/arm64/domain-build.c
+++ b/xen/arch/arm/arm64/domain-build.c
@@ -4,13 +4,56 @@
 #include 
=20
 #include 
+#include 
+
+int __init arm64_set_domain_type(struct kernel_info *kinfo)
+{
+    enum domain_type type;
+    struct domain *d;
+
+    ASSERT(kinfo);
+    ASSERT(kinfo->bd.d);
+
+    type =3D kinfo->arch.type;
+    d =3D kinfo->bd.d;
+
+    if ( !is_aarch32_enabled() )
+    {
+        ASSERT(d->arch.type =3D=3D DOMAIN_64BIT);
+
+        if ( type =3D=3D DOMAIN_32BIT )
+        {
+            const char *str =3D "not available";
+
+            if ( !IS_ENABLED(CONFIG_ARM64_AARCH32) )
+                str =3D "disabled";
+            printk(XENLOG_ERR "aarch32 guests support is %s\n", str);
+            return -EINVAL;
+        }
+
+        return 0;
+    }
+
+    if ( is_sve_domain(d) && type =3D=3D DOMAIN_32BIT )
+    {
+        printk(XENLOG_ERR "SVE is not available for 32-bit domain\n");
+        return -EINVAL;
+    }
+
+    d->arch.type =3D type;
+
+    return 0;
+}
=20
 #ifdef CONFIG_DOM0LESS_BOOT
 /* TODO: make arch.type generic ? */
 void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    /* type must be set before allocate memory */
-    d->arch.type =3D kinfo->arch.type;
+    int rc;
+
+    rc =3D arm64_set_domain_type(kinfo);
+    if ( rc < 0 )
+        panic("Unsupported guest type\n");
 }
 #endif
=20
diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
index 8720d126c97d..46eb3083cfad 100644
--- a/xen/arch/arm/arm64/domctl.c
+++ b/xen/arch/arm/arm64/domctl.c
@@ -13,6 +13,11 @@
 #include 
 #include 
=20
+static void vcpu_switch_to_aarch32_mode(struct vcpu *v)
+{
+    v->arch.hcr_el2 &=3D ~HCR_RW;
+}
+
 static long switch_mode(struct domain *d, enum domain_type type)
 {
     struct vcpu *v;
@@ -21,14 +26,15 @@ static long switch_mode(struct domain *d, enum domain_t=
ype type)
         return -EINVAL;
     if ( domain_tot_pages(d) !=3D 0 )
         return -EBUSY;
-    if ( d->arch.type =3D=3D type )
-        return 0;
=20
     d->arch.type =3D type;
=20
     if ( is_64bit_domain(d) )
         for_each_vcpu(d, v)
             vcpu_switch_to_aarch64_mode(v);
+    else
+        for_each_vcpu(d, v)
+            vcpu_switch_to_aarch32_mode(v);
=20
     return 0;
 }
@@ -38,7 +44,7 @@ static long set_address_size(struct domain *d, uint32_t a=
ddress_size)
     switch ( address_size )
     {
     case 32:
-        if ( !cpu_has_el1_32 )
+        if ( !is_aarch32_enabled() )
             return -EINVAL;
         /* SVE is not supported for 32 bit domain */
         if ( is_sve_domain(d) )
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b45..2e084dac0a7f 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -792,6 +792,15 @@ int arch_domain_create(struct domain *d,
     d->arch.sve_vl =3D config->arch.sve_vl;
 #endif
=20
+#ifdef CONFIG_ARM_64
+    /*
+     * Set default Execution State to AArch64 (64bit)
+     * - Xen will reconfigure it properly at boot time
+     * - toolstack will reconfigure it properly by XEN_DOMCTL_set_address_=
size
+     */
+    d->arch.type =3D DOMAIN_64BIT;
+#endif
+
     if ( (rc =3D sci_domain_init(d, config)) !=3D 0 )
         goto fail;
=20
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 89448fb4756e..ce7053ba6d59 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1881,19 +1881,6 @@ int __init construct_domain(struct domain *d, struct=
 kernel_info *kinfo)
     BUG_ON(v->is_initialised);
=20
 #ifdef CONFIG_ARM_64
-    /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain =
*/
-    if ( !(cpu_has_el1_32) && kinfo->arch.type =3D=3D DOMAIN_32BIT )
-    {
-        printk("Platform does not support 32-bit domain\n");
-        return -EINVAL;
-    }
-
-    if ( is_sve_domain(d) && (kinfo->arch.type =3D=3D DOMAIN_32BIT) )
-    {
-        printk("SVE is not available for 32-bit domain\n");
-        return -EINVAL;
-    }
-
     if ( is_64bit_domain(d) )
         vcpu_switch_to_aarch64_mode(v);
=20
@@ -1991,6 +1978,10 @@ static int __init construct_dom0(struct domain *d)
     if ( rc < 0 )
         return rc;
=20
+    rc =3D arm64_set_domain_type(&kinfo);
+    if ( rc < 0 )
+        return rc;
+
     return construct_hwdom(&kinfo, NULL);
 }
=20
@@ -2002,10 +1993,6 @@ int __init construct_hwdom(struct kernel_info *kinfo=
,
=20
     iommu_hwdom_init(d);
=20
-#ifdef CONFIG_ARM_64
-    /* type must be set before allocate_memory */
-    d->arch.type =3D kinfo->arch.type;
-#endif
     find_gnttab_region(d, kinfo);
     if ( is_domain_direct_mapped(d) )
         allocate_memory_11(d, kinfo);
diff --git a/xen/arch/arm/include/asm/arm32/domain.h b/xen/arch/arm/include=
/asm/arm32/domain.h
index 1bd0735c9194..30e8818ff2ae 100644
--- a/xen/arch/arm/include/asm/arm32/domain.h
+++ b/xen/arch/arm/include/asm/arm32/domain.h
@@ -3,11 +3,23 @@
 #ifndef ARM_ARM32_DOMAIN_H
 #define ARM_ARM32_DOMAIN_H
=20
+struct kernel_info;
+
 /* Arm32 always runs guests in AArch32 mode */
=20
 #define is_32bit_domain(d) ((void)(d), 1)
 #define is_64bit_domain(d) ((void)(d), 0)
=20
+static inline bool is_aarch32_enabled(void)
+{
+    return true;
+}
+
+static inline int arm64_set_domain_type(struct kernel_info *kinfo)
+{
+    return 0;
+}
+
 #endif /* ARM_ARM32_DOMAIN_H */
=20
 /*
diff --git a/xen/arch/arm/include/asm/arm64/domain.h b/xen/arch/arm/include=
/asm/arm64/domain.h
index 1a2d73950bf0..99c6c97a8057 100644
--- a/xen/arch/arm/include/asm/arm64/domain.h
+++ b/xen/arch/arm/include/asm/arm64/domain.h
@@ -3,6 +3,10 @@
 #ifndef ARM_ARM64_DOMAIN_H
 #define ARM_ARM64_DOMAIN_H
=20
+#include 
+
+struct kernel_info;
+
 /*
  * Returns true if guest execution state is AArch32
  *
@@ -17,6 +21,25 @@
  */
 #define is_64bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_64BIT)
=20
+/*
+ * Arm64 declares AArch32 (32bit) Execution State support in the
+ * Processor Feature Registers (PFR0), but also can be disabled manually.
+ */
+static inline bool is_aarch32_enabled(void)
+{
+    return IS_ENABLED(CONFIG_ARM64_AARCH32) && cpu_has_el1_32;
+}
+
+/*
+ * Set domain type from struct kernel_info which defines guest Execution
+ * State AArch32/AArch64 during regular dom0 or predefined (dom0less)
+ * domains creation.
+ * Type must be set before allocate_memory or create vcpus.
+ *
+ * @kinfo: pointer to the kinfo structure.
+ */
+int arm64_set_domain_type(struct kernel_info *kinfo);
+
 #endif /* ARM_ARM64_DOMAIN_H */
=20
 /*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7ad870e382c2..7e6e0541e024 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -530,7 +530,7 @@ static int __init init_xen_cap_info(void)
 #ifdef CONFIG_ARM_64
     safe_strcat(xen_cap_info, "xen-3.0-aarch64 ");
 #endif
-    if ( cpu_has_aarch32 )
+    if ( is_aarch32_enabled() )
         safe_strcat(xen_cap_info, "xen-3.0-armv7l ");
=20
     return 0;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:20:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:20:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119650.1464953 (Exim 4.92)
	(envelope-from )
	id 1uwcY1-0005VH-Ns; Thu, 11 Sep 2025 08:20:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119650.1464953; Thu, 11 Sep 2025 08:20:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwcY1-0005V3-Jt; Thu, 11 Sep 2025 08:20:53 +0000
Received: by outflank-mailman (input) for mailman id 1119650;
 Thu, 11 Sep 2025 08:20: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 1uwcY0-0004XB-Ba
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:20:52 +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 3a252c1c-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:20:50 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9468.eurprd03.prod.outlook.com (2603:10a6:20b:59b::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 08:20:36 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 08:20: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: 3a252c1c-8ee8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JWyz+fX86tCBqHxGgUoKHYP1Yo9wtegixdHuH/8vaO/CNSSNuVaV7ZW56vN2vZiI69CnDhcwr8bn+oHjVhMY8psqyVnAgIe9hpWbK6jGtMAQ2W+YI1QgU3JWG4IBNDumFcN3ZKHtAxKun6RItWlkMRuvfAgv5V20dhR4lFdFaRgDLlh2OgcUffZS3LvWuftJtOc2iP6eUeulV+c/VYDskv6CTELDrZ+8HLLdUd7/2uqxHJNgKw05UAZQ8ENA/CPa9aPvb9SssJTai34DUDfahsC8AnB17uALlnIwnsw3M1boeFNSDH195l10S7irlOyR+22SpJhFavEHfV4GADDjTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Bu7j+LGzSzBRWnn1uFmUlqpqkrqCdH2fH2rGjkvXHqo=;
 b=iJ0wHIiGw1Y+GYdJy325kEZdDUqKVY02B8TUbIZPYTfTQ4/pb3HQv7p5JEzzRpO+7BK4IuuGsfkJ4G+AXlRGx4h4wqILkTXLMhuoLzjPWUpCLYx9pV06knvMr4rvnzXjghfVrh87ThKnCH4VqrtJgc/C51EZKQ/4k11mYYebAur5N519TwyUoLUX7Jfu/OHmn/thvbmqC+T+byVDks4rMpo0hjfVpyQc3XtOee+sPEbEIkSBcaxlsB+lNyZDJYPnSqGubBpVYvOQ0Ub240gVBzBXWBodpj1uzVoqYNmgKzbdHM5CRufsuDHNNriipyaOhOaVU7Tk74xmZYdO09earg==
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=Bu7j+LGzSzBRWnn1uFmUlqpqkrqCdH2fH2rGjkvXHqo=;
 b=R4NvuVdjoW0FvVEJAY9RNl1C7RY9Ue/k1Uv7F6+kiwcPk8rRgRKD90zFxxuQLIIrw3Oy4vmozzgGvuV31P51n3x6TaMDhX24+Y+oDlEFTreoeLWs0WaL1OqnCu6XXDw0rS0fr/lEGIg4/1hIoDpkVXI1hJwiBE2ol9/2zrtUnzvtcleHnusRh+T7O9ZyYnHKa28lMYV/sKFIahwTQUQj0qGf4sR0+R5Gev4fE1rJJyDRURxZcEkOLSrsCEjlSULx6UEKLsnosjOgU/7lO81ekZb79asfsXpMY2To8gzWuMZsz0RzttJrz0jNEYxaGxiBdgn1gw1cr7t1VwjNUTN6Yg==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Volodymyr Babchuk
	
Subject: [PATCH v3 4/4] xen/arm64: constify is_32/64bit_domain() macro for
 CONFIG_ARM64_AARCH32=n
Thread-Topic: [PATCH v3 4/4] xen/arm64: constify is_32/64bit_domain() macro
 for CONFIG_ARM64_AARCH32=n
Thread-Index: AQHcIvTz7sirpn6LKUO7dGx//UyGtQ==
Date: Thu, 11 Sep 2025 08:20:36 +0000
Message-ID: <20250911082034.1326377-5-grygorii_strashko@epam.com>
References: <20250911082034.1326377-1-grygorii_strashko@epam.com>
In-Reply-To: <20250911082034.1326377-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB9468:EE_
x-ms-office365-filtering-correlation-id: 0d5a3600-0925-4a87-b9f9-08ddf10c15e6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?8Qt+0KOR2nCzREJ26z7kLM0ZEEc0jmX3OJfkFiCEKJit1A8iMbvWP+Xv7f?=
 =?iso-8859-1?Q?HuoDjOiHqzlmAY86/hKAaeniZGBGhfHAzjdg8PlXrPkgWNE0RigdaNeh19?=
 =?iso-8859-1?Q?wzJU4nDG4K8HsVQcYlzXiuLUbG5ZdbPMmrWIaBnrxLylbKcpccv1R1bhwx?=
 =?iso-8859-1?Q?ZvclqSXxvQWSpO/cB+ZFl2jFb79k/OtB7bZPYELT/vKTp1Oxi6xKXYd0rT?=
 =?iso-8859-1?Q?2ffg79PVPOrXEjvSCsX02Eqk2pAdp2XxWHZc71LtyuFTSe7XiNseC7wPZW?=
 =?iso-8859-1?Q?U5okIXHSOx/xFVkhQ4o1CBv2u3gHECoSDfnykzWnFLfxEg8M0dSAW5H61Z?=
 =?iso-8859-1?Q?5RZq6diCTChMSYtIx/euhBqj7g6JpuBJ322j927L5F41Q/nMahTOz9lrlp?=
 =?iso-8859-1?Q?LHs60ZzQbbAonphmdVHv6Fd+gcZuKmqa5JI1hMGn/bEhnfgDm1GWtldbYQ?=
 =?iso-8859-1?Q?Q4rRwFkfrMakcOG36JQcjpWfpdGU6aToLxkMAjp/dOUiXl6WI1LnxjuY52?=
 =?iso-8859-1?Q?MYj1HxW7EZVrDYzu5qhSMhPXHWAPT0kYC/2M42vkNcEUZOQhwZLNk3c1WN?=
 =?iso-8859-1?Q?pdVxTmqFstH+jUz2OC8rDdQxDPq9jMJgen1VJhfFtIPrx2o/Ir6RLM8vxH?=
 =?iso-8859-1?Q?+GmCyQR44mV2PHUPcP3AJQXcajiXeH+1oHuOzAV+W3oBeNzaDnWvMmFNiM?=
 =?iso-8859-1?Q?AqOKCNUz9bNZuNfjbOmSMkeNuA3TAgWM/b3SGhANj2BfMcfxlB1X6YMA6V?=
 =?iso-8859-1?Q?AwXNH5FPJM2wLcEUfA3YB8TYx5XcTS0hykl9Wd0qBH3tDFaumsKTOVMwD5?=
 =?iso-8859-1?Q?a8Hv1dxasV1p8b+N8MfWQagNnJ3+7okJfRE8CSmDyV29VtAYPRbeZH6mnv?=
 =?iso-8859-1?Q?7eeOrKomlFH8yGlxqQthGl0yaHhy1nGS4aPaool9We+/3M1uGXOKNsP2zT?=
 =?iso-8859-1?Q?Kxf6yYLVMQUzp6BM1wuUAggx3ngvEGPSfUs4NOLAndM5Gs7PY0m4LFI83Y?=
 =?iso-8859-1?Q?Ss/WxFCPX/xQY7z/YLZ766X32SIo1rg/2ysW7NgXqqmJpGpKNeKRWnuczL?=
 =?iso-8859-1?Q?+zxGjHDVbdxZylp0wSLFVAyecbybSyuTMvzMMIfmuhrnGhzUO5hsBrLvQO?=
 =?iso-8859-1?Q?Y4RIVjyc7+z/WlO50pMhzcbUM3H97a2A5JeDUJI2hKStc6Byt06WKlNZb/?=
 =?iso-8859-1?Q?xzV/y1RoCmR0rwNhaGFj2v28ZyDIcyXaxG+5tBRtMZ4ZCr56I60S2tGRGW?=
 =?iso-8859-1?Q?BrMqFvQY044rrg5DCJOniBZik5QW24L+TXICj9V34w/qMEIkTvM+G2ph8K?=
 =?iso-8859-1?Q?GboTrvq0BtV2YAp88DIboXS1eHP/t7drru19wmc9Udnv5zO5VgZv98VtRZ?=
 =?iso-8859-1?Q?caphGO8K1Wo+YnuW39PQt03UfUVLxvO/nhULjJb2ph5dEneJA4w6QrW5QM?=
 =?iso-8859-1?Q?vtQoDkIHJdRE+7jz4eNAI+gEScficP2yxF6j17EC6FyX4a2Y70cMjufWaB?=
 =?iso-8859-1?Q?n6lQq1xOVI4DZjnCqD6wHcWKqh9LB6vlL+rHNB0KBL7A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?nBOzBqko4mmhhRNKr0g3hmP+jzTnY4S2rqQUsgoDmGOL6hoqacr2L/sa4C?=
 =?iso-8859-1?Q?l1CGTTtG3xkFQlwXB3gwDNGcaDEUL+kYT7/6T3CDH8p74R83pnDNxf1O4d?=
 =?iso-8859-1?Q?wLNqHtApdAfZ3k6ouneNnliDUT/O58/OmOozIK2pioPDSZUm1swsCHw6ZQ?=
 =?iso-8859-1?Q?mGTzx+HFp8y6V2n49vPfv4ATbIPRgW/kP8wc5vN4NWMDUUJM0gRPsVo6eP?=
 =?iso-8859-1?Q?rb5szy5jmZT6iWywOZUiXi6TuK8QtT/LzFH6JW4jYIPJuQmDarCowHH0kG?=
 =?iso-8859-1?Q?dl5mEt4YIZsCdsA4ufxDU9LqfkBAsHbXXBV8y+elaN046kdhAAy2wSvncf?=
 =?iso-8859-1?Q?ehQ9G1wLO4ftUviqsmcnCoABSDirR4sC3HvG2GFI/Bsx9FvMIxf6ub2Pmj?=
 =?iso-8859-1?Q?39F3LTLExOQk/Yl85n8K8U6UDFuMrp0T/+x74OrF9kXqcAc90dCEbiAPqt?=
 =?iso-8859-1?Q?PjdMbZg7rbosaPTj8Qlkb9fyE+JIdiBdXlZ2ouXcR3/MjZfKwl1zf0m0jG?=
 =?iso-8859-1?Q?0NKIp3a9r6YDP2itxWi4MloWvLo7s68TwIcRsPuMrp3cRzuDPTiO+c0ulg?=
 =?iso-8859-1?Q?Uq4VdCmcSRAk0A7JDIrVjvMWGaEHrYxdlr5nI2NgUbsflIm5UONQOpzN2a?=
 =?iso-8859-1?Q?K70JBe+PapqDq2oUg0Jk5wgP57WJMRXe/4MzKE2ZJOqUV6nAAPrHe/lY/S?=
 =?iso-8859-1?Q?WRSVjbKrTVX+AOqQoshDyU03J8eACYwV1uZaW/lMxBukv5LwrLF2IdSvd6?=
 =?iso-8859-1?Q?r7Dwmgz4ByC3KQf/2w6uaG4hqosroivSfLKLwGlvcbFjSnMgkLodjSNKuF?=
 =?iso-8859-1?Q?iv31rVE/zB5YXoFeQvYISAU1dOG0D/wZ/9xw2xpXAL/TtRGT3lZ5vPmCNh?=
 =?iso-8859-1?Q?mGD/hq845gIIq6kXBjOtdO1bHIGox3gKGeonZx2/4LKq1OrQUS4DOUHHDc?=
 =?iso-8859-1?Q?nQVaCmYcrQJn17ZtUWq4TqCddj2nZpCxT6Y00oHbrRZiZXhhumJMFinKMW?=
 =?iso-8859-1?Q?PX51pK8aU+Uat/fWTAsElSWnMRW7TflWnhTDsV0GoDtAqMDPBkQXf6DJb0?=
 =?iso-8859-1?Q?TJK0JZQlVxL3my6WLWNdNvIYWQqHRlahb8Xs5mBXZfh6kz5Qv6VqJQpVv/?=
 =?iso-8859-1?Q?UC0tx5VlXzKswK8V8DERasB0kc7TbqdoWJH6PXzYuU4+tDK1vktq//corr?=
 =?iso-8859-1?Q?D4HIhGr3aOJRWNcTe933NUhRfvEpFktlqim/215YheDEScX1ipTSEt/5o4?=
 =?iso-8859-1?Q?MedN3QRhVVEpdC9TegRQAOIE5b09ZKrXJRr0Eb2RSuD0unLj3eZiYDjBPZ?=
 =?iso-8859-1?Q?RGtEpnOwUop+DlY7IBmo2gpxouIIjwklg9ctruZgWZIeOQC5l1L6leIxLj?=
 =?iso-8859-1?Q?7Y0kWcy9x6cZz5K3slN6vVk8F3WTqugIgXpsuagCiZNmJAsIUb8baY95rl?=
 =?iso-8859-1?Q?gjVw28SN0UrDQKJgQTAW5otFMnN+1+Pqwh1SEh/XpQmVkSXtqwzCsPqx6w?=
 =?iso-8859-1?Q?suR4ncsHqGSUEX8OEj3FJvS2LG7jEgZjtfyIxeVgWf3hQ7KzyZwlXARWlG?=
 =?iso-8859-1?Q?2abZ4s2Zv9sz3sNaOkPS3EYOJl0hevohPTbu4JtYQcgCII4EilSmA94id3?=
 =?iso-8859-1?Q?Fu66qiGd6YN6jRbUH4e86SXqdwWLlfu9sLpx86lJ4R7woRqyZlosH+1A?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d5a3600-0925-4a87-b9f9-08ddf10c15e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 08:20:36.5388
 (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: J9ZdM6UPRzsJmHwdaYMg94XJW8BmWhcmmXTgejfOKLoPbJCQWnBhRK7s8eqXBNVGaEn7Yy8bEa0zJpEG0ElYunbONgi1jmnAZMs1WnFgew0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9468

From: Grygorii Strashko 

Constify is_32/64bit_domain() macro for the case CONFIG_ARM64_AARCH32=3Dn a=
nd
so allow compiler to opt out Aarch32 specific code.

Before (CONFIG_ARM64_AARCH32=3Dy):
   text	   data	    bss	    dec	    hex	filename
 861672	 322412	 274976	1459060	 164374	xen-syms-before

After (CONFIG_ARM64_AARCH32=3Dn):
   text	   data	    bss	    dec	    hex	filename
 857856	 322412	 274976	1455244	 16348c	xen-syms-after

Signed-off-by: Grygorii Strashko 
Reviewed-by: Volodymyr Babchuk 
---
v3:
- no changes, add tag

v2:
- use IS_ENABLED(CONFIG_ARM64_AARCH32) instead of ifdefs

 xen/arch/arm/include/asm/arm64/domain.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm64/domain.h b/xen/arch/arm/include=
/asm/arm64/domain.h
index 99c6c97a8057..139d3ce0dd53 100644
--- a/xen/arch/arm/include/asm/arm64/domain.h
+++ b/xen/arch/arm/include/asm/arm64/domain.h
@@ -12,14 +12,16 @@ struct kernel_info;
  *
  * @d: pointer to the domain structure
  */
-#define is_32bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_32BIT)
+#define is_32bit_domain(d)                                                =
     \
+        (IS_ENABLED(CONFIG_ARM64_AARCH32) && (d)->arch.type =3D=3D DOMAIN_=
32BIT)
=20
 /*
  * Returns true if guest execution state is AArch64
  *
  * @d: pointer to the domain structure
  */
-#define is_64bit_domain(d) ((d)->arch.type =3D=3D DOMAIN_64BIT)
+#define is_64bit_domain(d)                                                =
     \
+        (!IS_ENABLED(CONFIG_ARM64_AARCH32) || (d)->arch.type =3D=3D DOMAIN=
_64BIT)
=20
 /*
  * Arm64 declares AArch32 (32bit) Execution State support in the
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:24:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119696.1464963 (Exim 4.92)
	(envelope-from )
	id 1uwcbh-0007Fg-Ed; Thu, 11 Sep 2025 08:24:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119696.1464963; Thu, 11 Sep 2025 08: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 1uwcbh-0007FZ-BI; Thu, 11 Sep 2025 08:24:41 +0000
Received: by outflank-mailman (input) for mailman id 1119696;
 Thu, 11 Sep 2025 08: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 1uwcbg-0007FO-1o
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:24:40 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c220815c-8ee8-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 10:24:39 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-b04abcc1356so63101666b.0
 for ; Thu, 11 Sep 2025 01:24:39 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62ec33b4d63sm699314a12.23.2025.09.11.01.24.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 01:24: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: c220815c-8ee8-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757579078; x=1758183878; 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=AX5M6JsUVBgtUWQloxbKOjbBxNM6+aanb5rbTnJcZhI=;
        b=FFCitnv2WwnmfwF1k1jHxReL+jQMSpK3NKhLkpKNfa4talQQJIIApJENW4fXM32ERe
         AHKqGRDsNBbC6TXbUfr7f4H/fh+r8MNJ+RGDloYdkdOY/G5uwI2n+2EX5KlWa5WhVyDn
         LCJvyYnWWUxkKzI1cbnSjkfZ/aIRSStx5qb7g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757579078; x=1758183878;
        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=AX5M6JsUVBgtUWQloxbKOjbBxNM6+aanb5rbTnJcZhI=;
        b=JQvyNrBWGF6k+SdMk4CMSGBcYj66fa4x0CsBuZhARJMGmmVTOCBXf5C1p0sZxBw7s6
         72TFpHwaOh6AhDIh/sL6iZWxyJ0i6OuL3zSM9ZBk5DKXGVB4bbHenmWH+YQXSxlNiH+o
         Hnu2L4Mk/XVWC+STdF5b8KsfiSyxygLq/1tCHs6f7owBhlf1o3c7KXDQ8d9C9C0SU7ck
         en66eYPxKy3o5k+b2SwzFrBJBo3fI8xS/q5l1Du7GVcZw2QgPo751oVeeOQ4h2Do1vNn
         V/38arjtDbwYf689Us0KblYDNQQF/aJzxbk7CaDSiENopxRLVIO1Hs5a/1+tlgEepHlU
         pdfQ==
X-Gm-Message-State: AOJu0YzU22VQkVZeHvsUpyhWXRFdLhrxV2jH2NbKr77o6+OtW4s4CteE
	pkvONU1ul07KRLRm4PdoBNMsiTAR6hDGRJlfIQvKMOv4RQjFVgTzOxjz8XW2JhgX7/ZoXIn9hmf
	HcKuj
X-Gm-Gg: ASbGnctcJFF3DrNk95dX4Vnw8fcdzaj3/MKEeUHHR1TTIKZh7mExGTpuFMxf6CA6yL0
	kBpQb4U8+2YkvY9TEc44z650YLBc7ZN7hf1gisaW3sW3FmiqFaTE8Wv7aimjGVhUeTMtxpUKR1V
	9nxMKjsGipCP8Yn75Xd4Hp075elJZ6Mfp/t7fuApu5nDJzhZEA1vsWRfK/o+kT3ZuEpmN49Y9o7
	/PHUNsX3qr7lj74GYetz2FK0b7MSk5EFBfkQJSvjPvR9foAY7BlHiAdAardtXFMkmwNJaDj/eFe
	WCuMTFEigIW03VSJDKA2T/BwlJtS1bAgpsv1Nkf6xZWmPGlPpcLD7eH82cjv1F2G2qNCUktvXYa
	15V7rVpT/U8b2HYWN6FNvCGh63xGkM1BLJ2jXn2Y3GrIksVndXpAK7U7g
X-Google-Smtp-Source: AGHT+IFR3s3EFcYpDPLzuG37Obd3r47IE8yh46jl0MZDTp4gSHuSNA3dFTphIpJwiNTYzYg8Krou2Q==
X-Received: by 2002:a17:907:1c26:b0:b07:892d:6769 with SMTP id a640c23a62f3a-b07892d67d9mr523996466b.2.1757579078222;
        Thu, 11 Sep 2025 01:24:38 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 0/3] efi: Shim LoadImage improvements
Date: Thu, 11 Sep 2025 08:24:26 +0000
Message-ID: 
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A previous series for supporting Shim's LoadImage protocol had some
outstanding comments after it had been accepted, and internal review
revealed an improvement to be safe when unloading the image.

This patch series includes those changes.

https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2032454096

Gerald Elder-Vass (3):
  efi: Fix line length in init_secure_boot_mode
  efi: Protect against unnecessary image unloading
  efi: Limit Shim's Verify success to EFI_SUCCESS

 xen/common/efi/boot.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:24:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119697.1464970 (Exim 4.92)
	(envelope-from )
	id 1uwcbh-0007Iv-PO; Thu, 11 Sep 2025 08:24:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119697.1464970; Thu, 11 Sep 2025 08: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 1uwcbh-0007Ij-Iu; Thu, 11 Sep 2025 08:24:41 +0000
Received: by outflank-mailman (input) for mailman id 1119697;
 Thu, 11 Sep 2025 08: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 1uwcbg-0007FO-UX
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:24:40 +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 c30c039a-8ee8-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 10:24:40 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-61cd6089262so623681a12.3
 for ; Thu, 11 Sep 2025 01:24:40 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62ec33b4d63sm699314a12.23.2025.09.11.01.24.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 01:24: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: c30c039a-8ee8-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757579080; x=1758183880; darn=lists.xenproject.org;
        h=content-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=v9lB+5/QMJwJ7zbazXB6aIwcP7l9eUd98XmJoHTDbJs=;
        b=UIHSARv08ikvpv4T8rE6zAmMpAarg+fSKDSpIWbN5YfWIrh+BI2vIrp8lfrTRWKXYW
         xTPaeCP5EIbFNdiPQ2ecwaEPzzcyvcqry4MJW/jgfnpFiVrKfm7LyAZfNTsqLycIz0Iv
         95iRU6kAAbxkvZJtwTF+0hmD7Sp+DzsWS/mbw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757579080; x=1758183880;
        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=v9lB+5/QMJwJ7zbazXB6aIwcP7l9eUd98XmJoHTDbJs=;
        b=NEvleZNVx+cg6N0/rwhdkxCOJGIsO8Mh4xDJZ1G1YAjRWFcEsFYXJTy7NllhOaAand
         v3KARnCz7LkjRa0FZhnwFx1cotCNqqWG8tCOHA+YibWi3tRO8zw0wSRITgpKJ7w3j3ly
         r8J00KTakbd46QsEDsQ9GTwBq94a89hw1g4FhBlS8/9iOi8DUJ7LUcROEmkEAtcokEeD
         7N5OszenKAkAz7gMIUDjd0LJwHJ7HAB0t8XQ2w/wGcYNUkCjs3yGvflV0ooJamfbQBj7
         FZn9mzumtIGfgwQqtCc200FM5S+8at7V48+6rb+x+t2uW8poZp6dfiS6lD/yajsrk2uA
         nTwA==
X-Gm-Message-State: AOJu0Yyuh1CZJbS/EtRKl0iyviO2FpOaT8Tafwgm6UueilpV8BRCke+Z
	FXhoYa8h98/+3Zvy6BC5AB1gHePV4Xkteg70Q0W+NP2dLtizzl6kYXwsJMzKh9Rv2kbOGlUGiP/
	PGGmx
X-Gm-Gg: ASbGncsKLTtCuM0jS/dQbJXon6sI/YMgJ1eFN+M8JaDZSyWkisINW2+3heJPqupoODb
	tnu9Q55idQz5Yb31Mg612zOQehIWyO/gve2Y13uA9ru9BCU8fLOxqbd/JRpq5xuPT3dgU+MCD1S
	agEiJoyTM8GJHIT4o0qmQNCM3DhVpG/yTkEcinixVHcHWl3xrCxVCVVbu1UVz2UpwV+4gAD6GoA
	5hbNnhjnUL/Ifi8uN/P1pFb1nOSqLXiv6CueLniH2UWRr/uX9wLWZziUyf9SdyZ4AS9apOb29Bu
	dT0iXgKN03EKG/EutkdnFnVQy5CYmI9xSYD0rXQxIgw7lITh3KP06ssvS5IU9+5/rLFeKF2Es2B
	BQ0lHGwx+xUFoxvXFAPaexaGA7YrJRBy9NgfU7ZnUTZ3OV8s2Y5rBylXV
X-Google-Smtp-Source: AGHT+IH9SIXzCcsHIgtZJiF8z9cGC3nRFa8aW436bg/A+OEbsBn9eW6N1Eq2im/QA1rrEXK1AOEBAQ==
X-Received: by 2002:a05:6402:2685:b0:61d:dd9:20db with SMTP id 4fb4d7f45d1cf-6237c048793mr15809936a12.31.1757579079733;
        Thu, 11 Sep 2025 01:24:39 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 2/3] efi: Protect against unnecessary image unloading
Date: Thu, 11 Sep 2025 08:24:28 +0000
Message-ID: <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 59a1d6d3ea1e introduced Shim's LoadImage protocol and unloads the
image after loading it (for verification purposes) regardless of the
returned status. The protocol API implies this is the correct behaviour
but we should add a check to protect against the unlikely case this
frees any memory in use.

Signed-off-by: Gerald Elder-Vass 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 
---
 xen/common/efi/boot.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 69fc022c18ab..ca162db0d8d3 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1062,7 +1062,7 @@ static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
     static EFI_GUID __initdata shim_image_guid = SHIM_IMAGE_LOADER_GUID;
     static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
     SHIM_IMAGE_LOADER *shim_loader;
-    EFI_HANDLE loaded_kernel;
+    EFI_HANDLE loaded_kernel = NULL;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_STATUS status;
     bool verified = false;
@@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
             verified = true;
 
         /*
-         * Always unload the image.  We only needed LoadImage() to perform
-         * verification anyway, and in the case of a failure there may still
-         * be cleanup needing to be performed.
+         * If the kernel was loaded, unload it. We only needed LoadImage() to
+         * perform verification anyway, and in the case of a failure there may
+         * still be cleanup needing to be performed.
          */
-        shim_loader->UnloadImage(loaded_kernel);
+        if ( loaded_kernel )
+            shim_loader->UnloadImage(loaded_kernel);
     }
 
     /* Otherwise, fall back to SHIM_LOCK. */
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:24:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119698.1464983 (Exim 4.92)
	(envelope-from )
	id 1uwcbi-0007hb-U5; Thu, 11 Sep 2025 08:24:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119698.1464983; Thu, 11 Sep 2025 08: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 1uwcbi-0007gj-PP; Thu, 11 Sep 2025 08:24:42 +0000
Received: by outflank-mailman (input) for mailman id 1119698;
 Thu, 11 Sep 2025 08:24: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 1uwcbh-0007Fi-MO
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:24:41 +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 c299c8a4-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:24:39 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b047f28a83dso83142766b.2
 for ; Thu, 11 Sep 2025 01:24:39 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62ec33b4d63sm699314a12.23.2025.09.11.01.24.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 01:24: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: c299c8a4-8ee8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757579079; x=1758183879; darn=lists.xenproject.org;
        h=content-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=pB+WsDeqv2sCpekU87otjg/rOz733WUlwzupkyN3uYo=;
        b=GxyytkzAZYLHgOU/J0QrE4MKIoX9Y/4nZzIB3/AJt3dDwHcg2s0mabWL2LGwA7Ze3l
         /lsbVkDxBBXMrZUAtXtZOgBtdfuU6ILzdXNWwGpbiEe/Ctp6Wz/gpshkwowGJaZs9fiX
         V1aop4FXklFtqkqhlZgl7qmyFQ+jXfMxsOmjk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757579079; x=1758183879;
        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=pB+WsDeqv2sCpekU87otjg/rOz733WUlwzupkyN3uYo=;
        b=qZxEBn2GdZFu5SUJ3iF6XuFbNec3nCagqhFzmI/SkvHG6ZmwDTw02niT3ywGyQmAZM
         kv9OsBj9p+LfWmzw3aTPLGiCbuRCXMBBacEC6nb9cZey0E0VO9sXu/hBpPAwk5PDP2Wk
         JKsMOEvCEFrx5ME2eLXC3C48d33UB+EQqCrYqrqFb6TxDlM3owPkJwwyqDdM764swE3C
         lQZlEv8IWOJ+gZMd8G9jQ19LtokC5ymUCKWEr5i7ppDNZg1BFCtXTdvFiS7hcuIkOti7
         DHmrbwvVZumB/8Vqk/2t9aClATLZEXH0jraqodNlFMDUQJI6KgbhZvn2scPh4JCwPOMR
         224A==
X-Gm-Message-State: AOJu0YxNRZoe0q5KMi6acqaGxbVCr5Z5BKVhh9IPe4q7On1guGjLM0uk
	c42C8xvZVN/rNhraRTDkjWNCENmGUSnD8AEZoGtMeuY0bycAvCFS15SFI6qHVlDDBMD6QgAPcq/
	MQeQ1
X-Gm-Gg: ASbGncusW6NutUwDg9n0YqIj8mJ+Q/ugG4SHpyk3n4nW7TTGLL4yYPjnPSIZaG+O7hv
	c7R+Ce7ZjnBjUXn+uvjjoL9jTs2VgT/DhB02efkcwCSCzez9EJCVI194hWklgO/97aTuOwNyRYE
	0ps/fWFND2vUxCWGxao16tHysrncvgJlxOTw+Kyvg/nZrcwaPEGKRKlKyRNOkC73SiZDsswmtAt
	G4mjqBs5q7QC9AffmDZeY/Y0JnZIQqQuBc/esbL+oCEQ5hnUR1jce0otDg5X13By00zSd2Yn660
	n8xcFbGCXexDFjUgr1mGr0g7ICiK2GY/RLkhf575f6/2xgh3KIzPDPpzrHeiEAF8oO8bg8UCKNY
	mUOoZBTiqyBq2jY480KLb5r1fhQRRgc2Z+8Gz38pT7YAMfg==
X-Google-Smtp-Source: AGHT+IGaN9ZR/JxKJ7mWuLxKQ/UrcA1+M6nyqmmQC7YK/MYv/l+HoZAtQ+OWShztok74LycAI8QyaA==
X-Received: by 2002:a17:907:6e90:b0:af9:29c1:1103 with SMTP id a640c23a62f3a-b04b16e4b03mr1631561566b.55.1757579078947;
        Thu, 11 Sep 2025 01:24:38 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 1/3] efi: Fix line length in init_secure_boot_mode
Date: Thu, 11 Sep 2025 08:24:27 +0000
Message-ID: 
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit cb41b4ce14a9 introduced init_secure_boot_mode but one line was
not wrapped appropriately.

Signed-off-by: Gerald Elder-Vass 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 
---
 xen/common/efi/boot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index b86c83d3348c..69fc022c18ab 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -923,7 +923,8 @@ static void __init init_secure_boot_mode(void)
 
     if ( status == EFI_NOT_FOUND ||
          (status == EFI_SUCCESS &&
-          attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&
+          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;
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:24:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:24:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119699.1464994 (Exim 4.92)
	(envelope-from )
	id 1uwcbk-0007wk-6j; Thu, 11 Sep 2025 08:24:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119699.1464994; Thu, 11 Sep 2025 08: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 1uwcbk-0007wZ-1n; Thu, 11 Sep 2025 08:24:44 +0000
Received: by outflank-mailman (input) for mailman id 1119699;
 Thu, 11 Sep 2025 08: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 1uwcbi-0007Fi-VF
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:24:42 +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 c38985a8-8ee8-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:24:41 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6188b72b7caso453389a12.2
 for ; Thu, 11 Sep 2025 01:24:41 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62ec33b4d63sm699314a12.23.2025.09.11.01.24.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 01:24: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: c38985a8-8ee8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757579081; x=1758183881; darn=lists.xenproject.org;
        h=content-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=Hl9F9GdCq3XbjB4Z6CoXc+8IbHjldBrhiMbyobpL14w=;
        b=fr0h3FTIxmM+G4o1dmsolkSZje1J3/tPXvZSITkGeUfjrysK9MAyPT3w73nLqejlbx
         XM2fylkZk++4QwjkJvHMxfUFcUursUBbQZnzWOhKvASB0O4HVQsK2pVx1w4wudg2oKMO
         mMOF4VY9NW42zlWRo0Ink9O6nl2wPtNZBMUlc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757579081; x=1758183881;
        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=Hl9F9GdCq3XbjB4Z6CoXc+8IbHjldBrhiMbyobpL14w=;
        b=dabbcyCveCATqLHkCr9t+Hi49Pa/NoSWXnciMFjHMK4gYeBo4E5t/n1wWKPWdscWxo
         XAbqoE3/0S5ArCw9VdwuakMifElu+aBmftDo8La6SsAu3nstfVXWwCHFHhMrdpJBYQMT
         QdTb9z1XOiFQCOwFFeuTXV2vYjaRJkcKkgwqufhhNj3x2ihbYk6ahZYyxE9eOLSsQIa/
         hLF83vuhUVX8WnaZ1h1uglJE/CiZmfvBv44IEM8duDreOWYsOoZardwdR9oyUvYYXkhv
         CFa7UZZfthNrxzgLXvwhjdF1IafW+EvZurHvprfW4cmC7Dv1+EsQhcSBTXkhjY8JBxlJ
         01QQ==
X-Gm-Message-State: AOJu0YxY28lulxA3ZuIqd4W9vo/LrZkvc9/yTuNQ2YrqGDMERmqDELIm
	TX+29L4rLBfS4MICVz5T6iHi3/2+ehfudjeE+QwHjnzgJhAPLqeL3ZJQdRo85HG13V4PAJ6Q7kR
	ewPQm
X-Gm-Gg: ASbGncsFVJMNShJnssiaMfJLnC1S9CV9h1BbRL4kdhj2ZKqYM6avuqr5+FKSt5kO3vB
	skSqKfiazWtEiJU97rDYQuoHhKIPJrW803CA/o8Hdo3r242D7wrQ5WUmzRyifK5ovb2XQGE7i3q
	w+cCdc1QwFmP/QOfT/UF8Z2IQPl5Y6EeyzyFBbQ9r2PVmYm5S6MKCrpqF1y/Ea7LK0IPX8014Rv
	+WSeqsICs1QvRalQ6z6M4vSuDfLRh4rC8MyfuBUU462Az4ZjUGK9vvKetSHxtV/YeUW7pahfequ
	pJ215mUwO1FjpmGn+hHwq1+VSrmbAoPECCf9VhECOzC8Hn1Z19yBKeRvbtLa+Dv+8Vl5zd238JY
	UxtrmO43xyXGdqFuAsnmEcR090GL47B1cPeXxPKWxsgTszw==
X-Google-Smtp-Source: AGHT+IEKYdGW49F1QRWZFaaOhXYtDEMXUm2DU7DUuF8lWq0D1h9ghowYA5zkYThRoQSb4KytgD1/BQ==
X-Received: by 2002:a05:6402:5049:b0:61c:e99d:fdef with SMTP id 4fb4d7f45d1cf-62372bbf6cdmr15573109a12.2.1757579080505;
        Thu, 11 Sep 2025 01:24:40 -0700 (PDT)
From: Gerald Elder-Vass 
To: Xen-devel 
Cc: Gerald Elder-Vass ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 3/3] efi: Limit Shim's Verify success to EFI_SUCCESS
Date: Thu, 11 Sep 2025 08:24:29 +0000
Message-ID: <20fa42c198ab257085a49e157a2d0e58a0010393.1757519202.git.gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 59a1d6d3ea1e replaced the Verify status check with
!EFI_ERROR(...), this changed the behaviour to consider any warnings
(EFI_WARN_) to be considered a successful verification.

This commit reverts that behaviour change.

Signed-off-by: Gerald Elder-Vass 
---
CC: Marek Marczykowski-Górecki 
CC: "Daniel P. Smith" 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: "Roger Pau Monné" 
CC: Stefano Stabellini 
---
 xen/common/efi/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index ca162db0d8d3..36e1e2cf9d4a 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1090,7 +1090,7 @@ static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
     if ( !verified &&
          !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
                                            (void **)&shim_lock)) &&
-         !EFI_ERROR(shim_lock->Verify(kernel.ptr, kernel.size)) )
+         shim_lock->Verify(kernel.ptr, kernel.size) == EFI_SUCCESS )
         verified = true;
 
     if ( !verified )
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:35:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:35:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119757.1465003 (Exim 4.92)
	(envelope-from )
	id 1uwclj-0002VR-0t; Thu, 11 Sep 2025 08:35:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119757.1465003; Thu, 11 Sep 2025 08:35: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 1uwcli-0002VK-UF; Thu, 11 Sep 2025 08:35:02 +0000
Received: by outflank-mailman (input) for mailman id 1119757;
 Thu, 11 Sep 2025 08:35: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 1uwclh-0002VE-Ik
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:35:01 +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 2cf4ee72-8eea-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 10:34:47 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b0411b83aafso63645866b.1
 for ; Thu, 11 Sep 2025 01:34: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
 a640c23a62f3a-b07b33478e4sm79430366b.96.2025.09.11.01.34.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 01:34: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: 2cf4ee72-8eea-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757579687; x=1758184487; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6om+MgAOmuQxmj0lBwEIDPkVNrCBj3qz4cJqW+B19+A=;
        b=XeWWvtB/FN27f/WyfJ1oynaQnQ9aJ26vKp2mabkd3eDOxK4WObHLFukCehGJazRQGb
         VJrNFbO2KGrP5P4YFtWTTbyaJway7cXQIlBIYDQ/0PGKUrXgSORbym/P2QEc2tmPGs7o
         bgv8LMtcPusHWvsQYGQEugNDR5HuTYf8jx9D5YQotRFWXEokh3EOtoxEliFp8C9GOKRc
         NqMPlm7FGkNSFInOpZO6imeGJk8aCkRJwBHovZwJVL3seHqITRrHjXn/pWkAHKFOEkG4
         sqyMlSrWxezDvV4SgZ/lDPemvLaEX/QtTwjbo32mzdSzvjCbFSqGpJsO4bnW2b0295vQ
         ygjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757579687; x=1758184487;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6om+MgAOmuQxmj0lBwEIDPkVNrCBj3qz4cJqW+B19+A=;
        b=plNJUgKXuodN2GXAHxlP/DfROc83jjdxc11H7zKUgrBVCDcDUUhgnNR8gbl4DPLFxE
         JQk6QMw1Je9+ieBVzkklCRbNrVGOythQtRoCySdUuO7GdRmjnQWbVAQ2NSOpWvbAydPJ
         /OS2QwQiyCeR4JTikDrYyeQpa9buv7abhNcZqDCv94O2oEYpktNxASeZc3OZzROGtCyu
         H20oCAVqYvZQU6HIABhzy3T69dqw6xFXmHKFRukfr/XaZkH8JRzJEEPn9WqFQVD9UBHM
         XIM9qNeiyrpkCFRi+ilbM3teNZwR8xql284b1trGQrucMcvQeOAcvnPswaCvsNUisea6
         7M/Q==
X-Forwarded-Encrypted: i=1; AJvYcCUfOpdDPwfNse+YH6E5kCfnZzG2wUyRSaBwv+oNIIrYqLl8XLn6A7g9gVHHCH0ZCA2KR5Nv7VgYsXI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQHojXB2YkjASroILfnoAGumphMaX6i22gFfLhUdm6pGfxs6BC
	uMIGgKlq98tGhunwXv5hrZSdrKQHB9ZJOpH4F7r8CHr7nWm2nEDbRPpaA87R+WHpN6anKcBDFIP
	fe+8=
X-Gm-Gg: ASbGncvT9vYLeY/CjAb1+kWbFEpS/TQd1tpf9EQ3Gl3u936Jr0tbwS8+CIRL+/lGxm9
	ePCIzHiJayU3ZVI7Ow+t56CWqwgZ/bVO5vqPabnmnxrFuYEYtVofwC/Jc0vflAaWXykJQv/sfSN
	ChxaKzCopqtKKLnaq09QRrzwjJqtwtQ7cQfNGSYnPTqPAZG0oUNB8UfcNg+9qIr29yrCMe5WCar
	cp+ixf5F6jZJeymlurIArBAE7o9v2SBLkk11ch6cgeKJmRX76oOnTT3cfpyE2lRru6+/3uAV3RT
	wkXvARK13ylnu1u2igha4bos4NHqvM7JKMezR5YBE89UgK/3I+03kn8iwIIdb4DwzBFzJUxjZMd
	tjtged5ncJDKl1EoLUnz83pFkFR7jbWU9EJGcgSYOgEHexJzB4wwGL9Sbb8jxZIShT+jiVZrx1J
	BFxucfYmNiEDbekVSsRQ==
X-Google-Smtp-Source: AGHT+IGKeO0u3ps5n1Fad3J0ER9y7vjudn1pSBY6n1ak9068BaHbvyWqXC8bI00X7CYymSUfYrU7wg==
X-Received: by 2002:a17:906:1b14:b0:b07:87ef:9d9e with SMTP id a640c23a62f3a-b0787efaa43mr453561166b.61.1757579687140;
        Thu, 11 Sep 2025 01:34:47 -0700 (PDT)
Message-ID: <48e537f5-2379-4b8d-a9b5-4761225a855a@suse.com>
Date: Thu, 11 Sep 2025 10:34:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] efi: Protect against unnecessary image unloading
To: Gerald Elder-Vass 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: 
 <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@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: <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 10:24, Gerald Elder-Vass wrote:
> @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
>              verified = true;
>  
>          /*
> -         * Always unload the image.  We only needed LoadImage() to perform
> -         * verification anyway, and in the case of a failure there may still
> -         * be cleanup needing to be performed.
> +         * If the kernel was loaded, unload it. We only needed LoadImage() to
> +         * perform verification anyway, and in the case of a failure there may
> +         * still be cleanup needing to be performed.
>           */
> -        shim_loader->UnloadImage(loaded_kernel);
> +        if ( loaded_kernel )
> +            shim_loader->UnloadImage(loaded_kernel);
>      }

To me this looks as odd as the earlier unconditional unloading. How would a
halfway sane implementation of LoadImage() return an error, but require
subsequent cleanup (and set what the last function argument points at to
non-NULL)? Unless explicitly specified otherwise, my expectation would be
that upon failure loaded_kernel could have any arbitrary value, possibly
entirely unsuitable to pass to UnloadImage().

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 08:35:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 08:35:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119772.1465013 (Exim 4.92)
	(envelope-from )
	id 1uwcma-00033A-DM; Thu, 11 Sep 2025 08:35:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119772.1465013; Thu, 11 Sep 2025 08:35: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 1uwcma-000333-AD; Thu, 11 Sep 2025 08:35:56 +0000
Received: by outflank-mailman (input) for mailman id 1119772;
 Thu, 11 Sep 2025 08:35: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 1uwcmY-0002qI-JB
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 08:35:54 +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 543f2fa3-8eea-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 10:35:53 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-b04679375f6so75378666b.2
 for ; Thu, 11 Sep 2025 01:35: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
 a640c23a62f3a-b07b31283e3sm84056866b.24.2025.09.11.01.35.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 01:35:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 543f2fa3-8eea-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757579753; x=1758184553; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=grTetyzW0o2pITRC2Tai7FBoj6w8DqouuQvdNUY70cs=;
        b=OBqZnUQxvy0o0teMnyjffSB3+KX1vy+8PIcwNRamaM4W08/q9xx4DxZERclAN0GqCc
         j11owq/biSrCaWZlR4/rlRnZKIHlGNXF/P/s7O0Wgsfxsy+LBeb2MvbxC67nv384ZmAK
         d/tHENMfwnWd53AFBDy45Oj/96yDlC14oMHjrUEdgTmBglASfc8SnTmrWelBshoHp8H5
         TGvyOqZwqBjeY8BJGX4jrqvI+/TbtoQDbmwVWCq+wYUoDkXOxuiOgT02REiwYVx5d9qY
         yIHviufdofl/Rk9/IVH0L6IHsTiizTG+LKkpdnxzkinoH+yA0kXogECB+jOEvbGesntA
         JaIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757579753; x=1758184553;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=grTetyzW0o2pITRC2Tai7FBoj6w8DqouuQvdNUY70cs=;
        b=e0wrLHcSHMVzZMMRmkRJHI436M9MmCL0SrG4VDggB2+NgsSiOZoWOtqe2O3mRxOA5d
         cOs+8jOcPU1pZ84pTqe1kogAwPL+b1ZiW44cWFZ3rwadXtVwMMV9LlnMRP8f81Z9yjCw
         xwaF6DYJ0kMU6y4BPhFgyAHK2a3Glv5hsi63xdTD7BvEbVcvbCFOwxWjn6sSyHA/7LWS
         rsAdpW5PT9bwqKZG9Y6a+b3MBYUvqcRYcb+nmyK7HKSszwHfdKgIilLbDFfMKHV2RNBQ
         aSXjnq+l1w7EGvO+jy4j/ZVVktAFjA2rLnLQ2ptqlKmRRhuqrB2Kvz1eizcT3RMcmQb8
         jkRw==
X-Forwarded-Encrypted: i=1; AJvYcCWx7iZ8xuKQSaL5zIhW/M1WktojVe3PZRga7KKHovkStzwYdds5iFitN/dAouREzWDeSsC3XRRayLs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyTgtpPxw0NurKXqaLbUOw9et3AYo7UlnDWWxBsV7Pc9LQVhYUF
	561rz93O+ylxpmelhkTdqFfOtR3NOM2U2mJ5MCj8ZDZVm9durwIFsAw223OfWt31kA==
X-Gm-Gg: ASbGncubpLUIQPI4PyMN2d++/0S9/3Y0EIiHQCCxAI0BaytdMK5cRbDoUJCRAKW29qM
	R1w1VQ1PrbHIrYNWQiOSx7YzUFQOAjG/f/IGxZLzTkbiphb6E+9k+T/GxHelzKLMs0ESEbOwUmi
	QRLljyILwMFSHBXTcz0dfNRM7jJF0ZnMp0Cya5QjaoGa5FwKOUry2CMFXuPvvBLEfEY4B7FAsQg
	slIMmpgm4izvU/8rsW4FCKNkZTou20fSHdZ2Z91a2ah1DrTKnJrwYFN7j/mK0P4BupcrtDaXeTX
	kP2hX9j97iEljGTzIIBlVqoKdMH1XHA5cVhYlUPsGOz5ZJvHwjDf1O28jIpg2T/3LEFWVHDi2ZF
	kQ4qkpOjiKbLfM9puJe8eb6J52kXsSN8+2UF6p938b5y2l9og6XNJtOI8Viw4/fspNOiNQD8LQD
	/iBpwrP4A=
X-Google-Smtp-Source: AGHT+IE7lhgpbqp2YlZulaeqA1+XHpXOd4eA0f7IGybh0TpnDUwIAmIW7XrpRtc0JMZuWxfz77ZcBg==
X-Received: by 2002:a17:906:16c9:b0:b07:6087:6803 with SMTP id a640c23a62f3a-b0760876abdmr915216966b.21.1757579753096;
        Thu, 11 Sep 2025 01:35:53 -0700 (PDT)
Message-ID: <2a1df546-c0b5-4937-9d9f-4d1c58c3e925@suse.com>
Date: Thu, 11 Sep 2025 10:35:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] efi: Limit Shim's Verify success to EFI_SUCCESS
To: Gerald Elder-Vass 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: 
 <20fa42c198ab257085a49e157a2d0e58a0010393.1757519202.git.gerald.elder-vass@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: <20fa42c198ab257085a49e157a2d0e58a0010393.1757519202.git.gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 10:24, Gerald Elder-Vass wrote:
> Commit 59a1d6d3ea1e replaced the Verify status check with
> !EFI_ERROR(...), this changed the behaviour to consider any warnings
> (EFI_WARN_) to be considered a successful verification.
> 
> This commit reverts that behaviour change.

Reported-by: Jan Beulich 
Fixes: ...

> Signed-off-by: Gerald Elder-Vass 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 09:08:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 09:08:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119808.1465027 (Exim 4.92)
	(envelope-from )
	id 1uwdI9-00006w-R2; Thu, 11 Sep 2025 09:08:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119808.1465027; Thu, 11 Sep 2025 09:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwdI9-00006p-NS; Thu, 11 Sep 2025 09:08:33 +0000
Received: by outflank-mailman (input) for mailman id 1119808;
 Thu, 11 Sep 2025 09: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 1uwdI9-00006j-7L
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 09:08:33 +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 e279a2ec-8eee-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 11:08:30 +0200 (CEST)
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-e970599004aso236755276.0
 for ; Thu, 11 Sep 2025 02:08: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: e279a2ec-8eee-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757581709; x=1758186509; 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=MDFSPpfMQx0xouLbfqxGVzwgr6YW2sVDKyq9doRjQQ8=;
        b=LqfdYiZv/EOJQ1ZlLvv7iJesrTi7PO59QTrha7ytNc9fJZJjTh6gqNePrlb1Iu5IEl
         Xv54wtoOJXzMt0xqyH6PjQ9mGVZrulzQTOuJn03eZWKps0SoC1gPpCk8RrMak5Es11E8
         UaQaCr+yqevxrjky7nsroV+SpK70WCV0kYeig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757581709; x=1758186509;
        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=MDFSPpfMQx0xouLbfqxGVzwgr6YW2sVDKyq9doRjQQ8=;
        b=eIWeaIio4ccMy+t+DBSkfmjzqydLXYdjtlYqSJWd93ciqzyEDciG/+qITUxaHHZkLL
         YJNjC0+fGVCZXOOfX2HGV9/4XeLh6+lqSJeO1bvEO/YkTp0bv/FLtKpwRyIIo6T/g8m4
         EQrGAhBHjst93Dmvi1BZeLL32OvTLBg7cmnVVbD4tQPk7uEPBE86wl8pQ4G/iQxT5Y3I
         9r7tQaSJ+zFF+HVqJM9ED+rIpRHhuSCIuFTOCIeL/D5ozjGBv9z24XjaQkeJhtIp8ZGU
         P9bS2Rs4T1Ypp3wDE9wGJiEdiQfPdi2yCGSOLSxwqqFfAe7wYbhlnEF0CwW6gmcdmo/H
         8mSQ==
X-Forwarded-Encrypted: i=1; AJvYcCXphvn47ZjFmtJN0i2EJzRXGlkOTjEmy14SXw3Q9dWBBFj2fWReDzqFml/ypHTYl7Jgvi7EUfDkSlY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTM0AHVeA9xfWk9WDjgDV6aO66lhKjNY76EWWTjuG5fxDZjrzy
	qtJB8Huoo+ue7kP1VlVYzD7dJF2OBUial/kG/xOATIEuJ+zmGaYSxzcd8aslUA6u+o9ATAUoK2B
	KC4sIc3N9yTjbpVcUxyozdaiCv9DQggoRfraFAdOHPw==
X-Gm-Gg: ASbGncvJbtu1VPJaSrdGiIBl2hFRzdl1+K0v/10hk0/ESb3Wpq6jOpwL9SP9VHm6PNh
	iZk8qdCMW3BZImlfpXeiwqIThJmaYvCV9rmJ/+PYMyf4JMJzOFgfMCQQKtYZ8uP5D8ESpEsqcRf
	qIqggotJVH411u4fadJ0Ax7wGDCNtmm17SlHp6WuoqyIKd6e3l5BlyOgP9WWQj4dtI02ypxYvd7
	Z2C0Llskx2wYjNu/gzqe7eODamDNDlZwf9/EYbGss5FqRfSqC8=
X-Google-Smtp-Source: AGHT+IGPd+dsNL21jtbwQOdC3WmVh3Qdk+YgrjLNtLVTAAYLhD6qRu5Yn0HiiHDHRgrCQYBZin3ZtpdjMSpeWVNw8hY=
X-Received: by 2002:a05:690c:30a:b0:723:8ccd:6898 with SMTP id
 00721157ae682-727f28e47c9mr200833927b3.10.1757581709260; Thu, 11 Sep 2025
 02:08:29 -0700 (PDT)
MIME-Version: 1.0
References: 
 <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@cloud.com>
 <48e537f5-2379-4b8d-a9b5-4761225a855a@suse.com>
In-Reply-To: <48e537f5-2379-4b8d-a9b5-4761225a855a@suse.com>
From: Gerald Elder-Vass 
Date: Thu, 11 Sep 2025 10:08:18 +0100
X-Gm-Features: AS18NWAsH1FBtBbkGK8qbiA5ITlL7LNC_VbNP0JbfHV6I1hu23rQFoA4qyqzDIE
Message-ID: 
Subject: Re: [PATCH 2/3] efi: Protect against unnecessary image unloading
To: Jan Beulich 
Cc: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	"Daniel P. Smith" , Andrew Cooper , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Xen-devel 
Content-Type: multipart/alternative; boundary="00000000000071e38c063e82e1d4"

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

>> @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE
ImageHandle)
>>              verified =3D true;
>>
>>          /*
>> -         * Always unload the image.  We only needed LoadImage() to
perform
>> -         * verification anyway, and in the case of a failure there may
still
>> -         * be cleanup needing to be performed.
>> +         * If the kernel was loaded, unload it. We only needed
LoadImage() to
>> +         * perform verification anyway, and in the case of a failure
there may
>> +         * still be cleanup needing to be performed.
>>           */
>> -        shim_loader->UnloadImage(loaded_kernel);
>> +        if ( loaded_kernel )
>> +            shim_loader->UnloadImage(loaded_kernel);
>>      }
>
>To me this looks as odd as the earlier unconditional unloading. How would =
a
>halfway sane implementation of LoadImage() return an error, but require
>subsequent cleanup (and set what the last function argument points at to
>non-NULL)? Unless explicitly specified otherwise, my expectation would be
>that upon failure loaded_kernel could have any arbitrary value, possibly
>entirely unsuitable to pass to UnloadImage().

This is because LoadImage performs the verification step after the loading.
They are independent operations but the output conflates the two, so we can
receive a successfully loaded image and an EFI_SECURITY_VIOLATION
status code, in this particular case the image will need to be unloaded. Th=
e
generalised check for the EFI_IMAGE_HANDLE before unloading (as
opposed to checking this specific status code) protects against any future
changes in the protocol.

I've linked the specification which states that the ImageHandle is created
in this particular case.
https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-se=
rvices-loadimage

*Gerald Elder-Vass*
Senior Software Engineer

XenServer
Cambridge, UK

On Thu, Sep 11, 2025 at 9:34=E2=80=AFAM Jan Beulich  wro=
te:

> On 11.09.2025 10:24, Gerald Elder-Vass wrote:
> > @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE
> ImageHandle)
> >              verified =3D true;
> >
> >          /*
> > -         * Always unload the image.  We only needed LoadImage() to
> perform
> > -         * verification anyway, and in the case of a failure there may
> still
> > -         * be cleanup needing to be performed.
> > +         * If the kernel was loaded, unload it. We only needed
> LoadImage() to
> > +         * perform verification anyway, and in the case of a failure
> there may
> > +         * still be cleanup needing to be performed.
> >           */
> > -        shim_loader->UnloadImage(loaded_kernel);
> > +        if ( loaded_kernel )
> > +            shim_loader->UnloadImage(loaded_kernel);
> >      }
>
> To me this looks as odd as the earlier unconditional unloading. How would=
 a
> halfway sane implementation of LoadImage() return an error, but require
> subsequent cleanup (and set what the last function argument points at to
> non-NULL)? Unless explicitly specified otherwise, my expectation would be
> that upon failure loaded_kernel could have any arbitrary value, possibly
> entirely unsuitable to pass to UnloadImage().
>
> Jan
>

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


>> @@ -1078=
,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE ImageHandle=
)

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 verified =3D true;

>>=C2=A0 
>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 /*
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Always un=
load the image.=C2=A0 We only needed LoadImage() to perform
>> -=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* verification anyway, and in the case of=
 a failure there may still
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=
 be cleanup needing to be performed.
>> +=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0* If the kernel was loaded, unload it. We only needed LoadImage()=
 to
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* perform verification a=
nyway, and in the case of a failure there may
>> +=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0* still be cleanup needing to be performed.
>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
>> -=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 shim_loader->UnloadImage(loaded_kernel);
>> +=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if ( loaded_kernel )
>> +=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 shim_loader->UnloadImage(loaded_kernel);
>&g=
t;=C2=A0 =C2=A0 =C2=A0 }
>
>To me this looks as odd as t=
he earlier unconditional unloading. How would a
>halfway sane impleme=
ntation of LoadImage() return an error, but require
>subsequent clean=
up (and set what the last function argument points at to
>non-NULL)? =
Unless explicitly specified otherwise, my expectation would be
>that =
upon failure loaded_kernel could have any arbitrary value, possibly
>=
entirely unsuitable to pass to UnloadImage().

This is =
because LoadImage performs the verification step after the loading.
They are independent operations but the output conflates the two, so we =
can
receive a successfully loaded image and an EFI_SECURITY_VIOLA=
TION
status code, in this particular case the image will need to =
be unloaded. The
generalised check for the EFI_IMAGE_HANDLE befor=
e unloading (as
opposed to checking this specific status code) pr=
otects against any future
changes in the protocol.

=

I've linked the specification which states that the ImageHan=
dle is created
in this particular case.

Gerald Elder-Vass
Senior Softw=
are Engineer

XenServer
Cambridge, UK

On Thu, Sep 11, 2025 at 9:34=E2=
=80=AFAM Jan Beulich <jbeulich@suse=
.com> wrote:
On 11.09.2025 10:24, Gerald Elder-Vass wrote:

> @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDL=
E ImageHandle)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 verified =3D true;

>=C2=A0 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Always unload the image.=C2=A0 We=
 only needed LoadImage() to perform

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* verification anyway, and in the c=
ase of a failure there may still

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* be cleanup needing to be performe=
d.

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If the kernel was loaded, unload =
it. We only needed LoadImage() to

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* perform verification anyway, and =
in the case of a failure there may

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* still be cleanup needing to be pe=
rformed.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 shim_loader->UnloadImage(loaded_kernel=
);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( loaded_kernel )

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 shim_loader->UnloadImage=
(loaded_kernel);

>=C2=A0 =C2=A0 =C2=A0 }



To me this looks as odd as the earlier unconditional unloading. How would a=


halfway sane implementation of LoadImage() return an error, but require

subsequent cleanup (and set what the last function argument points at to
non-NULL)? Unless explicitly specified otherwise, my expectation would be
that upon failure loaded_kernel could have any arbitrary value, possibly
entirely unsuitable to pass to UnloadImage().



Jan




--00000000000071e38c063e82e1d4--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 09:21:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 09:21:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119830.1465037 (Exim 4.92)
	(envelope-from )
	id 1uwdU9-0002mH-SJ; Thu, 11 Sep 2025 09:20:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119830.1465037; Thu, 11 Sep 2025 09: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 1uwdU9-0002mA-O2; Thu, 11 Sep 2025 09:20:57 +0000
Received: by outflank-mailman (input) for mailman id 1119830;
 Thu, 11 Sep 2025 09:20:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwdU8-0002m4-Q5
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 09:20:57 +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 9d6402ad-8ef0-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 11:20:54 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DS0PR12MB7728.namprd12.prod.outlook.com (2603:10b6:8:13a::10) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.22; Thu, 11 Sep 2025 09:20:49 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9094.021; Thu, 11 Sep 2025
 09:20: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: 9d6402ad-8ef0-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TXBmDHkyhpG2/D11sf4H0IFpUsyomglLFxp4pUrP76QCjgn7bhShIKd+mdjmNsURpiWbCYwy8uL5kd2epubte6EuFYy6ZZkWg0Ebl6/jLoAg2700z4png5LtjpAKFDAx5Hyi/fFV2fkmWHhPSasJxX71173+xeVyAzOVIihm7mSLR1CIMYaWZb6p6E38Uu8jQ6YnCkTbtLRZhZOASG9QmUYYUDCFOKRF3bo7vTpp+IRWGCdmFwsXEizR1Td8+E3OGRggIWlqnt5XDbuoP1KUvSi2s4lvHaAO/7gCBq+1ZCESSvxydSdjQjUtli+Y4N9hcCEGhRbm0CSrWg+bbH4SsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sa6DXcd7FYmvoF0+8vlTtfuH1T4DMtYcPTZioNW9epk=;
 b=PMRS34/msLyk3nfw4/XE2qWA81Qu6fxjG1UlFP12YegZl8Mm6xVUPnPKy+6qj25dxmkVCEPOb0AS49kAF8rYaWCmH9ETcZ6fh9RmWu8sbCzDyItinqkRAhIw4a3UXtWRfq0hR0HgkI1OLDKcW4Mivr/AqnoYMLiYM/qiEtz89UBHBNIp2ALsRIh7EZdSFm2RiBaMZ+ddsPoHBTw9HKjfpvE6hoBvwMrcoDVHQfHLCi9g81S8EheTSQbRatVJURhpYfXCf6MNMmXXybWDxJyR1+2aT/Czc4q8SE5D0b91KG7nFWFfHmeZz+R47c7QFd2NOe/52lG4Thc1qXLUO2pvlw==
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=sa6DXcd7FYmvoF0+8vlTtfuH1T4DMtYcPTZioNW9epk=;
 b=a4fRa93AVP8f4HI17G4Lk0dVssleUGmCxWkAn2czM6niEH8lBVw2aEK1nqP57o75Al68mIuNOhPI1kcWrKkDZO6FtsW57vqJG8y1WWC3vtMuLCWEUmU9vDOoHD1lyTpssRpLftSSYkdpHZ/2JyheAiqXXpRgUtW/fRSDJiaFHWQ=
From: "Penny, Zheng" 
To: Jan Beulich , Tamas K Lengyel 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Alexandru Isaila , Petre
 Pircalabu , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
Thread-Topic: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
Thread-Index: AQHcIiYDHxl9uXccpkex+vWb0p4h67SMggMAgAEx1KA=
Date: Thu, 11 Sep 2025 09:20:49 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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-09-11T09:20: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_|DS0PR12MB7728:EE_
x-ms-office365-filtering-correlation-id: 22af94b7-f467-4b11-8a5d-08ddf1147f28
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?cmtkY29CWVREMXlIQzB3WWVBRmVVY1lTKzBJcVQwQ3Q2bUhWVDdMcCtqSGVn?=
 =?utf-8?B?dVRLc293YWlUdTN1WXRnS0NZWnZDeFdMRnNmd0ZhbVpVVmdZdzZWKzdlZkhu?=
 =?utf-8?B?QXBuWW1UNU5QaXlaYWRTVnV3UjE3MDc3dlBuempTNVhtblV6ZHRrZTZYVElD?=
 =?utf-8?B?UGxnMDZaZTBxMXltVGt6aTZQV29WSVJzMHJ3NjFJTmsrYWlxYldLeDJMakJm?=
 =?utf-8?B?OUJjRkp0dlNLeDZXMHdGcE1pR05uQ2MydTNodkErRXhSS0hTa1gyVGFKNzZU?=
 =?utf-8?B?cHQ1TVlqYi9CT0hTOWRiK2FVS3hYQU50eUx6bFZIRlY1WUtEMk5jOFJENGJo?=
 =?utf-8?B?ZC9QVm1ZVnBua0R6OXJoNTNva1FJVGQ2YW9FQXBSNDlpc2VSeWhqZ1JqY2hZ?=
 =?utf-8?B?Ui8rbVBOaWhIWmZGdWdGVHBvZ3I1ZGxMRlpORXVWZzU5eExNSG1XRXV0TEVR?=
 =?utf-8?B?N3lVek9Zc2dPdnhsMXZPY2JwaElCQ1pIeTl0Wm5ueURRWHRJeG42MzJYaksz?=
 =?utf-8?B?QkpOeTRhbW5iVG9ZTWlPQ1FIZWcyazg5cEJScVpqcnZ0WFZENWpVb0dNWXdm?=
 =?utf-8?B?d0FoeWNuM3huRVRQYll2U2JhZzVjNVhsV2VNeXFtcUY1dFpwMFlIT3BUYmFt?=
 =?utf-8?B?TXJUaUJQdk1wYkRsUk1kTzVqdGdISlNpTndVKzVzZUdFVFBGaGoyUUtSeVdi?=
 =?utf-8?B?cDh4QS9zVndpem5ybmJEekFGNVEzWElhWk15TDdEeGJ4bWdvQW1QQjkrcGxC?=
 =?utf-8?B?U1IwUHV2dW83NnplU0w3SlhXWkFESmk5eE4vb0ZWcmtCTFF3R0VuZ003Zkcx?=
 =?utf-8?B?V1B1aVNVN1lGZjl1UWZIQ0hoa21ScFRzSnArRmo3SjU2SU5jVWNuWDBUOUEy?=
 =?utf-8?B?ZUpuVmNXWXg4R1B1RmR2ZGxOYVA2WWF5bVFtOE5CT2UzS2hLWFlVK0d6dGRR?=
 =?utf-8?B?dUIxU2M5MnBJa1ZYOG45Z1lUWkQ1U1Y1Z3ViVis3UlN0QnI1VlpKSnc3RlJ6?=
 =?utf-8?B?TVE5eSt5dk1CcjBkTE93U2Y2OC9rbHBSQm9XTXJBRzV5dnp5bnZtN0Q1dzVM?=
 =?utf-8?B?NVlBdEVra0tLbmtscGR1N3VQaVJjdjVQM2pWUXlySUlyK2J3ejQ1QktpN0Vp?=
 =?utf-8?B?Qk8yekJKRFFvWnJFK1NJWmJ6Sk9odkJGbFBMaUFYYWxkQTkwSWVYcEFOMkNI?=
 =?utf-8?B?ci9qNWxLVmc0cE1oaWYyK2FUMTZCMWJPVlpmT2FHSzI1dTJnZnErSERIQk8z?=
 =?utf-8?B?NkJhRnRoZ0d3eFBTd2VHMDBnVmlIWTdhNDRod0Y4TURFNWFWc2VyZDVKUHdq?=
 =?utf-8?B?dHFlYlMrVnBIV3B1VWFOOHNYbXVBOERCZ0pRN2tlMDlnVzBDWDVjL3JBMEZY?=
 =?utf-8?B?M0MxdzJuZ3BlUWlYemkrdzcwZHE0VVJ2eXJSZW5BNlJWV3VEKzZkbEtFd3My?=
 =?utf-8?B?Q0FNc1A2VWhkOUR5Z2lyVnhWV3VDbmplUkg5d2VIK1o0VXZSSFoybndtZ0da?=
 =?utf-8?B?eGhXWUIzTy82NW90dHNFdmIraG5iS1l6eGJJRUxMM2NqNUVxRFdOdnpVd290?=
 =?utf-8?B?dVJUWHhzL2dUSDA5SzdGYkpJRDFHYW9NOGJuZTk2bEw5MHBHWEpsRFZiUDFn?=
 =?utf-8?B?MFBBQ0ljNm9jL2xnZ3B0QjRDN3RGbll1NEgwM2cycUhxVStlOVlYNG9ld2lI?=
 =?utf-8?B?Smg1aFdWQ1hqV3NwYlVaZ1pPSkRkWm9lQUU0Q0lKTGp1c0p1VTBTSER5WFNl?=
 =?utf-8?B?ajBZZjdrdytHUVVYZTBtU2dLbzh0dDIzMGdmOE05TGpiamE2TWRqQ1Q1Q1Fo?=
 =?utf-8?B?TjEzZ0Z6dGZsS3lpbDB1Y0lCRjd6aVp1SEpNMzJmVk9sMTZlMERPem9NL3Er?=
 =?utf-8?B?VWhRSlh2aU9NOEh0T1A0NlE2WmdYN24ycXJlVnVMNlZTT1RuQnhacmtlNHVz?=
 =?utf-8?B?ZHlaNmhONjlwdmJqVXdKWXVGbnZNT2Y5cERUamNCdU9uTTdid3E2a1JTYjlH?=
 =?utf-8?B?bmVhaXcyOFp3PT0=?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?d281SVJIV2FIcFM0NStRTHFGMUdZVG55OHdtQnQyTEhXcnJCWUk3NmVrb1g5?=
 =?utf-8?B?WmpNdTVUWHlHcnpmZ3lja213MU4wMDZhbkx3a0haYWlEQ2dnQmRXb0hxUmgx?=
 =?utf-8?B?ckZnVllObzFCOGhxTUpaMW0zTGdiZVpKemVCZmxVV3I4NW5reGYra0Q4ZnUx?=
 =?utf-8?B?Mmx6TjNaVUgrdWRVK2wwaEM1OVhCR0x0TWNEeWltenBoTjV5elYrbCt1cmYr?=
 =?utf-8?B?S1dackFZM0dsbndNU3RsNlF1R2NOdTh2ZEcvVTNpeW9KQUxLSG1NeWJyYjE1?=
 =?utf-8?B?dHFzcDNuYUtUUnZibktJbmlrVzkyQjAvYk93Y3M1MndjR0J4Qmd3NnVLL1NL?=
 =?utf-8?B?WldoTXYzWjUvVlRYWFQ4UHdiajNEOEE5dnl2VDdmUTMrMUtxNnVFdjZmWjhQ?=
 =?utf-8?B?aFZURGNKd1VLMk1lNjVMdEZmYmZXK29QLzVpYXJZUWdLWk9yRUgraWVkYzNm?=
 =?utf-8?B?M0J0Mm8zc2FHRlIrUXJ2ZEFOY3h2d3ZzeU12aWkyV2k4RTAzNmRGcjZHWVNn?=
 =?utf-8?B?MERtN2VySEtndXV4UkZvbmgxendGL1dlMEJpYk5vS0V0Y2NwNzZVem5ObitW?=
 =?utf-8?B?dXRaTzZVTWFacXVKOEJiM3BVaEZILzZRd1F4NEwzYUNyZU9BWEVqS3kxOFhU?=
 =?utf-8?B?cWFFUk9ndUFiRjhZQTJyQ25CcGdibEdTdFBxeDNpVDRKbzN3aW9BelZVMWNl?=
 =?utf-8?B?RkZBS2lrb3hZZkpTWnBjTHpidWtFWDdERmxaTHo3WFRBWVBiRGdkaFZ3TW1l?=
 =?utf-8?B?NVhwWnZrVWh6VU1qQW5JM290Zjl6M0svSjAxNDdpY29CWGovaGdpcWlTK2Ex?=
 =?utf-8?B?N2grbnJXRk5xeCtOUlI2T1Nld2Q1cnJGZmVLNmRzbEVIaU40TDlreDVIUWhT?=
 =?utf-8?B?MTliOWVjWmJnOWpycUVrM2ZaK0xkdmh3WWY3aWxZaUlNZUEvd0ZicVprdDZB?=
 =?utf-8?B?WEhLMDRzUUhPZms1TGdOMEJIempvV1VHUHhhdlloSzVFVEpNMk5lMU1iejlr?=
 =?utf-8?B?ZmNqbmFUbHZWaHVrWTNXazc0bitVZnNOUksvTnRSZDV5TGFsTUsyRU5Xa0tF?=
 =?utf-8?B?SzRRNmdnQXAwbUlOUzJoQVRZOGp0Y0dpUFhkckhDNW1SR3JWTFg3KzBEUjRH?=
 =?utf-8?B?d01YckNGSnRNVjUzRnQzT2h2MmZpZ0k2bWRuOHFFS0gwVGJoWFhTdnY5dzBH?=
 =?utf-8?B?ZlFvTTFpOVRQRDdTTWhrdWhjV3VGQjVhc1RGeDc0OFhVdmhlK09JRWpFRHZm?=
 =?utf-8?B?aXM2UXh1RkxjU3Y0UGkrMHB3WW5NVDk1UURzTE03MHIrTVlkNGkzSytSZ2Mw?=
 =?utf-8?B?VHNSc2p1SEM4ZFVUemJOY1o2QmRlZ0VKQ1pYYXlIazFZbm9HVFJVV0J0Qngz?=
 =?utf-8?B?UjVValNwTkxaY1pTb3JOcGIySDRFVFVaLzV1Y3ZTSUN6VTVCaFkrR0xYcWRR?=
 =?utf-8?B?VFgrbEVNb2VJMXZzZ2VXV2NHR1gxWGRRTWVrbDB3SGVVWGlyem9jdkw5dVhB?=
 =?utf-8?B?RDJ1Tlh5dkhaMlRIUDhWbCswWVp1VTlyZTB1c0dBbnYzd2xacWZ4ZFE4cFhj?=
 =?utf-8?B?b0dyU2NPVkpFc1A2ZENRMXJqTTVYZ0FFSWh1MmsrUmNjdVBWRUk2WnNYbGh1?=
 =?utf-8?B?M01pQ0tIVWxpNks2U0dDNi9uMUNYZWRyY05GcWhBNlhwdy81NTBuNDB6eGRT?=
 =?utf-8?B?cU9pNUN0azdPTDIvbTBlQ05EVzVvVGx0a0pmRmxEMGY2SUdZdGU4ZkJxUHZ5?=
 =?utf-8?B?M2V4V3NuVTRYRlVGRHRiWVJ5SjkxMVBOT0JFRllmQXRnenVSakp3bHB6QmRl?=
 =?utf-8?B?eHRSQ1Zrd091c2pQMlUwcUpHYUNCR3FMNFdEdUVlOGRIT21YUTh2dTFmQS9U?=
 =?utf-8?B?Yi8vSUIwSDVhY014d0IxaE5IT05CU3R5ZFlYbGJjM09sR201SHNUOUFkY044?=
 =?utf-8?B?SGcvVlQxK0lIODJPWDd5Nm1SaDhPbi9BOTJFMVY0ejBnTVovT2U2RHhkKzBv?=
 =?utf-8?B?bGhkQTh5eDlqSnNqWkd3bzVWSlNXVVBIMDNBZ1hJVFlVOHNoQ0FVa002eVpt?=
 =?utf-8?B?elNpbG83Q1NVNkRVK1UxTC9BZEJqM0dJWm14L0c2anRmelpIK3J2cnN1SGlE?=
 =?utf-8?Q?uVtg=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: 22af94b7-f467-4b11-8a5d-08ddf1147f28
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2025 09:20:49.0726
 (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: ntTXM7jTGMFcC5L5vem1xT6vC/jz0H1vmEeQ7a4P5nW8zoxXRnVepPIGE/bq5izGbyMgmnJQaOyXzdq+MP6NIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7728

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEw
LCAyMDI1IDEwOjU3IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
OyBUYW1hcyBLIExlbmd5ZWwNCj4gPHRhbWFzQHRrbGVuZ3llbC5jb20+DQo+IENjOiBIdWFuZywg
UmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47DQo+
IEFsZXhhbmRydSBJc2FpbGEgPGFpc2FpbGFAYml0ZGVmZW5kZXIuY29tPjsgUGV0cmUgUGlyY2Fs
YWJ1DQo+IDxwcGlyY2FsYWJ1QGJpdGRlZmVuZGVyLmNvbT47IERhbmllbCBQLiBTbWl0aCA8ZHBz
bWl0aEBhcGVydHVzc29sdXRpb25zLmNvbT47DQo+IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHYyIDA0LzI2XSB4ZW46IGNvbnNvbGlkYXRlIENP
TkZJR19WTV9FVkVOVA0KPg0KPiBPbiAxMC4wOS4yMDI1IDA5OjM4LCBQZW5ueSBaaGVuZyB3cm90
ZToNCj4NCj4gPiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4vdm1fZXZlbnQuaA0KPiA+ICsrKyBiL3hl
bi9pbmNsdWRlL3hlbi92bV9ldmVudC5oDQo+ID4gQEAgLTUwLDYgKzUwLDcgQEAgc3RydWN0IHZt
X2V2ZW50X2RvbWFpbg0KPiA+ICAgICAgdW5zaWduZWQgaW50IGxhc3RfdmNwdV93YWtlX3VwOw0K
PiA+ICB9Ow0KPiA+DQo+ID4gKyNpZmRlZiBDT05GSUdfVk1fRVZFTlQNCj4gPiAgLyogUmV0dXJu
cyB3aGV0aGVyIGEgcmluZyBoYXMgYmVlbiBzZXQgdXAgKi8gIGJvb2wNCj4gPiB2bV9ldmVudF9j
aGVja19yaW5nKHN0cnVjdCB2bV9ldmVudF9kb21haW4gKnZlZCk7DQo+ID4NCj4gPiBAQCAtNjgs
NiArNjksMjAgQEAgYm9vbCB2bV9ldmVudF9jaGVja19yaW5nKHN0cnVjdCB2bV9ldmVudF9kb21h
aW4NCj4gKnZlZCk7DQo+ID4gICAqLw0KPiA+ICBpbnQgX192bV9ldmVudF9jbGFpbV9zbG90KHN0
cnVjdCBkb21haW4gKmQsIHN0cnVjdCB2bV9ldmVudF9kb21haW4gKnZlZCwNCj4gPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBib29sIGFsbG93X3NsZWVwKTsNCj4gPiArI2Vsc2UNCj4gPiAr
c3RhdGljIGlubGluZSBib29sIHZtX2V2ZW50X2NoZWNrX3Jpbmcoc3RydWN0IHZtX2V2ZW50X2Rv
bWFpbiAqdmVkKSB7DQo+ID4gKyAgICByZXR1cm4gZmFsc2U7DQo+ID4gK30NCj4NCj4gV2hpY2gg
Y2FsbCBzaXRlIGlzIGluIG5lZWQgb2YgdGhpcyBzdHViPyBJIHdhcyBmaXJzdCBjb25zaWRlcmlu
Zw0KPiBtZW1fcGFnaW5nX2VuYWJsZWQoKSwgYnV0IE1FTV9QQUdJTkcgYWxyZWFkeSBub3cgZGVw
ZW5kcyBvbiBWTV9FVkVOVC4NCj4NCg0KSXQgaXMgdXNlZCBpbiBodm0uYyB0byBjaGVjayB3aGV0
aGVyIHZtX2V2ZW50X3NoYXJlIHJpbmcgaXMgZW1wdHkuIEFuZCBpdCBoYXMgdGhlIHNhbWUgcHJv
YmxlbSBhcyB0aGUgYmVsb3c6IHdoZXRoZXIgd2Ugc3VwcG9ydCB0aGUgY29uZmlndXJhdGlvbjog
Vk1fRVZFTlQ9biBhbmQgTUVNX1NIQVJJTkc9eS4gSSdtIG5vdCB2ZXJ5IGZhbWlsaWFyIHdpdGgg
aXQgYW5kIG1heSBuZWVkIGhlbHAgb24gaXQuDQpJZiB0aGUgY29tYmluYXRpb24gaXMgbm90IHN1
cHBvcnRlZCwgSSBzdWdnZXN0IHRvIG1ha2UgTUVNX1NIQVJJTkcgZGVwZW5kIG9uIFZNX0VWRU5U
LCBtb3N0IG9mIHRoZSBiZWxvdyBzdHVicyBjb3VsZCBiZSByZW1vdmVkLg0KDQo+ID4gK3N0YXRp
YyBpbmxpbmUgaW50IF9fdm1fZXZlbnRfY2xhaW1fc2xvdChzdHJ1Y3QgZG9tYWluICpkLA0KPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHZtX2V2ZW50
X2RvbWFpbiAqdmVkLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYm9vbCBhbGxvd19zbGVlcCkgew0KPiA+ICsgICAgcmV0dXJuIC1FT1BOT1RTVVBQOw0KPiA+
ICt9DQo+DQo+IFNhZGx5IHRoaXMgbG9va3MgdG8gYmUgbmVlZGVkIHdoZW4gTUVNX1NIQVJJTkc9
eSBhbmQgVk1fRVZFTlQ9bi4NCj4NCj4gPiBAQCAtODIsMjMgKzk3LDI4IEBAIHN0YXRpYyBpbmxp
bmUgaW50DQo+ID4gdm1fZXZlbnRfY2xhaW1fc2xvdF9ub3NsZWVwKHN0cnVjdCBkb21haW4gKmQs
DQo+ID4NCj4gPiAgdm9pZCB2bV9ldmVudF9jYW5jZWxfc2xvdChzdHJ1Y3QgZG9tYWluICpkLCBz
dHJ1Y3Qgdm1fZXZlbnRfZG9tYWluDQo+ID4gKnZlZCk7DQo+ID4NCj4gPiArI2lmZGVmIENPTkZJ
R19WTV9FVkVOVA0KPiA+ICB2b2lkIHZtX2V2ZW50X3B1dF9yZXF1ZXN0KHN0cnVjdCBkb21haW4g
KmQsIHN0cnVjdCB2bV9ldmVudF9kb21haW4gKnZlZCwNCj4gPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB2bV9ldmVudF9yZXF1ZXN0X3QgKnJlcSk7DQo+ID4NCj4gPiAtI2lmZGVmIENPTkZJ
R19WTV9FVkVOVA0KPiA+ICAvKiBDbGVhbiB1cCBvbiBkb21haW4gZGVzdHJ1Y3Rpb24gKi8NCj4g
PiAgdm9pZCB2bV9ldmVudF9jbGVhbnVwKHN0cnVjdCBkb21haW4gKmQpOyAgaW50IHZtX2V2ZW50
X2RvbWN0bChzdHJ1Y3QNCj4gPiBkb21haW4gKmQsIHN0cnVjdCB4ZW5fZG9tY3RsX3ZtX2V2ZW50
X29wICp2ZWMpOw0KPiA+ICsNCj4gPiArdm9pZCB2bV9ldmVudF92Y3B1X3BhdXNlKHN0cnVjdCB2
Y3B1ICp2KTsNCj4gPiAgI2Vsc2UgLyogIUNPTkZJR19WTV9FVkVOVCAqLw0KPiA+ICtzdGF0aWMg
aW5saW5lIHZvaWQgdm1fZXZlbnRfcHV0X3JlcXVlc3Qoc3RydWN0IGRvbWFpbiAqZCwNCj4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB2bV9ldmVudF9k
b21haW4gKnZlZCwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHZtX2V2ZW50X3JlcXVlc3RfdCAqcmVxKSB7fQ0KPg0KPiBTYW1lIGhlcmUgYW5kIC4uLg0KPg0K
PiA+ICBzdGF0aWMgaW5saW5lIHZvaWQgdm1fZXZlbnRfY2xlYW51cChzdHJ1Y3QgZG9tYWluICpk
KSB7fSAgc3RhdGljDQo+ID4gaW5saW5lIGludCB2bV9ldmVudF9kb21jdGwoc3RydWN0IGRvbWFp
biAqZCwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5f
ZG9tY3RsX3ZtX2V2ZW50X29wICp2ZWMpDQo+ID4gew0KPiA+ICAgICAgcmV0dXJuIC1FT1BOT1RT
VVBQOw0KPiA+ICB9DQo+ID4gK3N0YXRpYyBpbmxpbmUgdm9pZCB2bV9ldmVudF92Y3B1X3BhdXNl
KHN0cnVjdCB2Y3B1ICp2KSB7fTsNCj4NCj4gLi4uIGhlcmUuDQo+DQo+ID4gICNlbmRpZiAvKiAh
Q09ORklHX1ZNX0VWRU5UICovDQo+ID4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 09:52:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 09:52:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119867.1465046 (Exim 4.92)
	(envelope-from )
	id 1uwdyL-0006v6-AT; Thu, 11 Sep 2025 09:52:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119867.1465046; Thu, 11 Sep 2025 09:52: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 1uwdyL-0006uz-7Y; Thu, 11 Sep 2025 09:52:09 +0000
Received: by outflank-mailman (input) for mailman id 1119867;
 Thu, 11 Sep 2025 09:52: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 1uwdyJ-0006ut-QV
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 09:52:07 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f98053b1-8ef4-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 11:52:05 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-b0787fdb137so72047666b.0
 for ; Thu, 11 Sep 2025 02:52: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-b07b30da4c5sm92931366b.21.2025.09.11.02.52.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 02:52: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: f98053b1-8ef4-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757584325; x=1758189125; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uywRppr1+m9BATvN76D6Q1/AqxH6pkAJLlw5PWEDakw=;
        b=YA9ZR8wI5RI9AsCIU9SQCbqcTqOfqZ0i52pi825/KFJTX5B7o/K0ohj0ebVbtQnqUN
         Cu1G+KbOX167KCp1speZhxLlD0WhWUjZuD7ErIYftKK6OPa/InQQJGfhHXXhjFOKUsmq
         tVTMCa5NCxBZeuxp8tTQb9fYU/LSvGCnGv3FNOSSwuH4ACerjZTx/pWlspcSyjRW2GUt
         QjeVi2JJmySy8v5yt1h1WHzpGTX+ZL6DgwTWDD9WnZGKY12tgZ2PTrh6lrgO4upoOCXa
         F/dVSVygcI2LcTO5Dg28oEyCeopeIu6OKVK2PWgDfBdtTIRhUzpWWDjjS+dlnlhZDb1R
         YO1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757584325; x=1758189125;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uywRppr1+m9BATvN76D6Q1/AqxH6pkAJLlw5PWEDakw=;
        b=s1MEavyW4mMOJXZ73LdZyjUVtTXkY05YARCON5LE2vW+VUZeJI5i+B12bmc0BR5HmL
         EUALvyqWJ5LUOa2EkwMkcrOfZrOtYY1iSegTHXmLxepNLIj8ZvnfWj8ncNxYoB1XkAsc
         R+YQjTaHBWRtC2ExmqX5wUVdsgraMLhfXIMoCtD7k3Nqbvm16wONLF249JBR5OCunh1u
         CPlTutDhumEYuaPL1YQBw4behElONtbVEmNHqT/gZusMUoJ9TIi90xXVuaPhMmxTCaEQ
         FGhJRdRe/WOGnUa8hlFUYCvHuFdsIBotKst9+cFdtFKHGktnqjOLyUV+GADP5FvfmppQ
         eEyw==
X-Forwarded-Encrypted: i=1; AJvYcCWacK1gICqAW8X5l/pQYS9F4ryhe+rMiSvWcR6Qh1gn3jiu47OtaBjI/GU5bYjwJ6pIhgbYKG2YOUw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBAHCrlH6uzRWlfBXQjyBzXILHkeipgtoDSFE75lO32ngsdvLD
	UK3MWbUtldAPQxxgwZhCINAPvEydpR/il59+aAAOOKnycLu+aegC8kF8zaXP7h80jA==
X-Gm-Gg: ASbGncuETXaLJqHyG3NSCiqM21RT1FzoScL8q7sGAAmVY2zqQowB90Gtb+PtKxzrPzS
	ElVhK7cOqsmjLrA/H++D7bJpXKd1nwRDKlVjAD279FMN6TpdL0gFGofMabgAruulk2ngUoVVZ2l
	0OBNniLQ6jEKrsZ4fsAkh7XlZD/IR9rTaV9rYcJkIzo0sSaPQ1kcjfzCuwSId/qkMWdUffFL45j
	43m3JfrTiVBS7QwSwwUeBrMPrq/rKt1mkgw9U+8WhRFZCOz/vj1we0a/Pxgym84GXBV9xXnKZWB
	6eZvAekwtkRbTf9wXyjiyZORxuxNbsKjPlZCFjkylA9h8pQUxSLexmJlOBUvWT4jCLtjCHeROjl
	s37iNwhXJrazWg5gaKh+UANO8GXr/Pg0NFT0CGFjX6BguSsVcrnvyhtEbLZpNc8tpVpTwcD3T9J
	JnIbS68n5VIQxkpfHHhg==
X-Google-Smtp-Source: AGHT+IELfaxamOpX9yHEKCdCkmm8rIUdT7oqykT5WIC7t7znsYYimJV7Gc3Tg4Tae67bdhO5SskCSA==
X-Received: by 2002:a17:907:7e8b:b0:b07:b19c:1381 with SMTP id a640c23a62f3a-b07b19c15bcmr189748466b.50.1757584325243;
        Thu, 11 Sep 2025 02:52:05 -0700 (PDT)
Message-ID: <5d5b4f0e-4c5e-42ac-a9e2-61fbb60718f5@suse.com>
Date: Thu, 11 Sep 2025 11:52:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
To: "Penny, Zheng" ,
 Tamas K Lengyel 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 11:20, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, September 10, 2025 10:57 PM
>>
>> On 10.09.2025 09:38, Penny Zheng wrote:
>>> --- a/xen/include/xen/vm_event.h
>>> +++ b/xen/include/xen/vm_event.h
>>> @@ -50,6 +50,7 @@ struct vm_event_domain
>>>      unsigned int last_vcpu_wake_up;
>>>  };
>>>
>>> +#ifdef CONFIG_VM_EVENT
>>>  /* Returns whether a ring has been set up */  bool
>>> vm_event_check_ring(struct vm_event_domain *ved);
>>>
>>> @@ -68,6 +69,20 @@ bool vm_event_check_ring(struct vm_event_domain
>> *ved);
>>>   */
>>>  int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
>>>                            bool allow_sleep);
>>> +#else
>>> +static inline bool vm_event_check_ring(struct vm_event_domain *ved) {
>>> +    return false;
>>> +}
>>
>> Which call site is in need of this stub? I was first considering
>> mem_paging_enabled(), but MEM_PAGING already now depends on VM_EVENT.
>>
> 
> It is used in hvm.c to check whether vm_event_share ring is empty. And it has the same problem as the below: whether we support the configuration: VM_EVENT=n and MEM_SHARING=y.

Hmm, yes, I must have overlooked that. This needs to stay, I expect.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 10:43:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 10:43:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119914.1465056 (Exim 4.92)
	(envelope-from )
	id 1uwelD-00054j-Pg; Thu, 11 Sep 2025 10:42:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119914.1465056; Thu, 11 Sep 2025 10: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 1uwelD-00054c-Mw; Thu, 11 Sep 2025 10:42:39 +0000
Received: by outflank-mailman (input) for mailman id 1119914;
 Thu, 11 Sep 2025 10: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 1uwelC-00054W-8E
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 10:42:38 +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 076d0391-8efc-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 12:42:35 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-6188b5ad681so781724a12.0
 for ; Thu, 11 Sep 2025 03:42: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
 a640c23a62f3a-b07b30da289sm103895266b.17.2025.09.11.03.42.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 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: 076d0391-8efc-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757587355; x=1758192155; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KKV7CufMZ9DOV2XuiV7SNMDgZvcY2sS7LvVboG84b4U=;
        b=I4iauHolos4FDE8Ny/P8QrWiMR59X6g1gUSgQFk0Ks7gxOmWGXCPU3V/0gtRM0iyEp
         VhVDHBrxYtxZp9Z2sLNrYBjB31Bkq06MPNRggDvFlAHaHntSNLMXjYWsUAjj/2vJsl0D
         NKObN8wf6dO6bqTHk7ZQrAnWLgJSiARFHhsXrLFXpbFSXZvVgdLpi3BIr21d9x9NQzQa
         E5rQCFeOF0fwVkf+JZAbvbWD5E4C1+17wrs/ajwD39L+/ocuVrER/LY7AyfGPS4i5DBp
         eT27tIR2rxOEZIwlMjR8LDXX+eWFHKM36Kv4xXgraD6WvEfppwlnnYGH8qw6rFheAYtH
         ULnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757587355; x=1758192155;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KKV7CufMZ9DOV2XuiV7SNMDgZvcY2sS7LvVboG84b4U=;
        b=SQBFzL+ngnHuIEdYi6APZqJ/6bEg+XiBOPpTzrHJBDYu1s6JYU4c8A23Emz54XAGwS
         5sIfOTWNwNwDT+xsOQmGIZoSz1dm5fEW+N+FYw0lxbjvT4WCyozUrIUVgCkNkaM9rEGn
         toR7WDhmmq4JfAcpiL0OOMbrAO256shg0G4ketMXLHbLiQ+eQKqXWdVSdIendTPUEstn
         /AKFd11iH0W05Nd6G4yqmOgO1Vnj7JHe+MB9WIbPvLVWxfvmB1fQhg+k3AXYkEgaet/B
         cM0tyaxAdK4OEJusW7jW8qQ36pcgFR028Ua2AmlVfl56gUubAV18O3cywBos3QhBrqWm
         OL9Q==
X-Forwarded-Encrypted: i=1; AJvYcCXuRrt1HGGW2hMYq+WYuaOClA+Nkphmg7FLYMMFLMO/QAMgcb/EIxwBOVfNBon11nTYVAGcJBZQ1J8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYhNwzu1LDuncmXNYOjkLquHWM7g/wYKSCuNK0RLWzmObr20J+
	JLFisEWqhQm1bk+Xpj+c2hdhOKfB0AEmo4PHcyLttgTHKk1riOUahHJ6lddooxMH7Q==
X-Gm-Gg: ASbGnctc5nmjXH7g4Sou01uOWaXZPMLUcyqjgjQaUj915zjjqlBkUvOiXU6F9yKGH9g
	F+b9HFWyJAxug40/kFhvhW+Mz+SsNqsxlDGbDKkU+zx1tKRuho4t5NY+DmDHYcJ8832aGa5c6m0
	+9r8HlQ1KufDdGlleBtPPG9raSho/tJwHeReHcWuhtZMbupjyj7i7myBVwfT2YEbTTb5HAGMtSc
	K4Mh2rjbbkgN/srb+X75vqloR68t58biszxlAZz6Ie2VqzcfgmJ2UJrf8doWNdV5qRpd9FLS+PA
	ChTDcdprSeQK2QwolhuwGYYqaO/QTkXYI/E1E6r+h2vLUEKdiillPyrUOCddJSrJaMt0kQ+MWsh
	Doxs8TiNUKrkmvSdkpbR83QQ176WClWIRarSbqatYT+ErUw94/S1hqNv3tzFM7o+c7KLPays+s2
	u/St3Bc2DA9b9dq9HLAg==
X-Google-Smtp-Source: AGHT+IHBzE1uckw4rF1TBD4T+H0Qopzs26WImiSNm0xzEVbIUfiP4txYvWirEm25U4TQvWmN5L/gjA==
X-Received: by 2002:a17:907:2d91:b0:b04:3302:d7a8 with SMTP id a640c23a62f3a-b04b16d300dmr1811696566b.58.1757587353024;
        Thu, 11 Sep 2025 03:42:33 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 12:42:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 13/26] xen/domctl: wrap sched_adjust() with
 CONFIG_MGMT_HYPERCALLS
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 ,
 Nathan Studer ,
 Stewart Hildebrand , Dario Faggioli ,
 Juergen Gross , George Dunlap ,
 Meng Xu ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org, xen-devel@dornerworks.com
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-14-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -735,8 +735,8 @@ static const struct scheduler sched_arinc653_def = {
>  
>      .switch_sched   = a653_switch_sched,
>  
> -    .adjust         = NULL,

This line can just be dropped, can't it? It doesn't need ...

>  #ifdef CONFIG_MGMT_HYPERCALLS
> +    .adjust         = NULL,

... re-adding here.

> @@ -2288,7 +2290,9 @@ static const struct scheduler sched_credit_def = {
>      .wake           = csched_unit_wake,
>      .yield          = csched_unit_yield,
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      .adjust         = csched_dom_cntl,
> +#endif
>      .adjust_affinity= csched_aff_cntl,
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      .adjust_global  = csched_sys_cntl,

Again better to get away with just a single #ifdef, I suppose.

> @@ -4246,7 +4248,9 @@ static const struct scheduler sched_credit2_def = {
>      .wake           = csched2_unit_wake,
>      .yield          = csched2_unit_yield,
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      .adjust         = csched2_dom_cntl,
> +#endif
>      .adjust_affinity= csched2_aff_cntl,
>  #ifdef CONFIG_MGMT_HYPERCALLS
>      .adjust_global  = csched2_sys_cntl,

Same here.

> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/private.h
> @@ -349,9 +349,11 @@ struct scheduler {
>      void         (*migrate)        (const struct scheduler *ops,
>                                      struct sched_unit *unit,
>                                      unsigned int new_cpu);
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      int          (*adjust)         (const struct scheduler *ops,
>                                      struct domain *d,
>                                      struct xen_domctl_scheduler_op *op);
> +#endif
>      void         (*adjust_affinity)(const struct scheduler *ops,
>                                      struct sched_unit *unit,
>                                      const struct cpumask *hard,

And here, even if the other #ifdef is (just) out of context.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 10:46:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 10:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119926.1465067 (Exim 4.92)
	(envelope-from )
	id 1uweoU-0005cc-8q; Thu, 11 Sep 2025 10:46:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119926.1465067; Thu, 11 Sep 2025 10:46: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 1uweoU-0005cV-64; Thu, 11 Sep 2025 10:46:02 +0000
Received: by outflank-mailman (input) for mailman id 1119926;
 Thu, 11 Sep 2025 10: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 1uweoT-0005cK-Md
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 10:46:01 +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 81383d96-8efc-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 12:46:00 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-afcb7ae6ed0so81562566b.3
 for ; Thu, 11 Sep 2025 03:46:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b32f20dcsm102819566b.90.2025.09.11.03.45.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 03: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: 81383d96-8efc-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757587559; x=1758192359; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rHSUWoYMdgzf4IiT3dMD5pcRmUqjWPY7dpo49gnYGMM=;
        b=TcfH3ZCbQWlTdVolvmCJVCCd6jMTh698ZpVs0BAiMQHyXFZLliKGeuYukc/hZJjdH5
         OYmJgECdacAARk+FIRe1D/O7rcbrwbBJqj8hIS/VGv2FepUhqRvTRIg7reZ26NpIhEhU
         VLJXuQcvm3ZPAazD8Xhei5edFWsDfrvDwghcm73HcWpZ3WMfYW0MCg7wRYP0TXp4D+PP
         l6H2kv2dIYTZ7OwTbT4ACa77z8PoFXCQwl5kbTRMoZ4CEtflhofuM9BfYA8vA74g/m+H
         u/fKQbGKqBR9OGi3aXdAL0PHKjlsP9iKZrColJQ8+/ehZC9BASVVXk3t1ILiN1QCcuXu
         DjLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757587559; x=1758192359;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rHSUWoYMdgzf4IiT3dMD5pcRmUqjWPY7dpo49gnYGMM=;
        b=mZfegkFViQmijErTmXrOVnxoTdiwBDywjKdA9SKR2upq4hm6LauzGEwxXUi+y07caK
         h3AeXTgRxudvmgUju7V7gZcuTZxxwFrMHY8jwX5YnlbBXy1z4qoCb2/RmisG2KuBR8wb
         6POH3sR4aSai2VbCStMajkUfZkOZlLJKHBR6TvwyB8fWrHWwbPO7KRt8jcJW8ObgLRRI
         QCid8B21NRwrar6ELTaMW9y8PkLNXOhVvVcxrh+ppYXPBwSYn+M9rra5nOarH3hW/3dI
         yQP7TmbuV9HWST9zLFtS4+iiRhPhdzc7Llp0Z5o9Jutehkj/tveVpE5l/mLzdmt/qjFR
         1Xnw==
X-Gm-Message-State: AOJu0YxssRX8B0w8VOtDe7zIss3kx483wy8/5U/BSsJfNZP5uK+MPDn4
	AVZcM/Wsurd3MBEddbr1EoNhUbSZS03HwnkfnExfO9RnYH5CypuS/Czu/YPNmTktJA==
X-Gm-Gg: ASbGncvMQy9uaeCoPxHKAlCf3v/HiNgVRGAUPdW4PIXNpCGpcwLm/uk5OdNGU6Iqyka
	ETo2I0psF18KswiFwsIn9V6hhGkmAmSHmD2/dr/M4j20P0T0sCfWuXMrese6XHB6p5GkAiw/0gL
	ZFXbFPokN9EuhG1N6M+VxtJq6mVgt2EyshTNIlnyS6FpijGM4GKLYVsYO3geN0nZ0VOISVqUzW5
	OurinzykTaD/HBFsQuuaQ4tIGDyoPF1vNDt3ilRQwAgdvWOkfgKfQZLbM24mBcKfqGBSm+7S+60
	0qqpeQ1KXZjcm4RXitn+ISRBdg5Bj3W3ZKsVVcGVKtAdSshGtsxd9YkrGtAisiAT+XME8+LcHvS
	VQcePLkyArIhKp8W4NiNSoK+siUmg2S40Sszkfi4xUeLtbm7rnmypcJpk4yaMcQ/3Y6YjSgtfE4
	z3F21vizM=
X-Google-Smtp-Source: AGHT+IHDk0BCWy9NHTP0eiCLaecgTZsDe5m+fK2o/oqPqrl/NBLCQhql3xIzO3/sK7pT9MKLV5vTVQ==
X-Received: by 2002:a17:906:fd8a:b0:afe:85d5:a318 with SMTP id a640c23a62f3a-b04b1666d66mr1826857866b.36.1757587559423;
        Thu, 11 Sep 2025 03:45:59 -0700 (PDT)
Message-ID: <1a81010e-98f5-40f3-a64e-ca01b64ae8fc@suse.com>
Date: Thu, 11 Sep 2025 12:45:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/26] xen/domctl: wrap arch-specific
 arch_get_info_guest() with CONFIG_MGMT_HYPERCALLS
To: Stefano Stabellini ,
 Penny Zheng 
Cc: xen-devel@lists.xenproject.org, ray.huang@amd.com,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 04:31, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
>> Arch-specific function arch_get_info_guest() is responsible for
>> XEN_DOMCTL_getvcpucontext domctl-op, and shall be wrapped with
>> CONFIG_MGMT_HYPERCALLS
>> Wrap XEN_DOMCTL_getvcpucontext-case transiently with CONFIG_MGMT_HYPERCALLS,
>> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
>> common/domctl.c in the last.
>>
>> Signed-off-by: Penny Zheng 
> 
> There is arch_get_info_guest under riscv but it is only a stub so:

As said in reply to other patches, I think those stubs want covering nevertheless.

And btw, this is an example of a patch which would have been entirely unnecessary
(afaict) if the Kconfig setting didn't have a prompt (yet / anymore).

Jan

> Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:02:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:02:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119949.1465077 (Exim 4.92)
	(envelope-from )
	id 1uwf4K-00005u-Iv; Thu, 11 Sep 2025 11:02:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119949.1465077; Thu, 11 Sep 2025 11:02: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 1uwf4K-00005n-FO; Thu, 11 Sep 2025 11:02:24 +0000
Received: by outflank-mailman (input) for mailman id 1119949;
 Thu, 11 Sep 2025 11:02:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwf4J-00005g-VX
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:02:23 +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 c9f7d1c9-8efe-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 13:02:21 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b0418f6fc27so94965066b.3
 for ; Thu, 11 Sep 2025 04:02: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
 a640c23a62f3a-b07b32ddf93sm110457266b.69.2025.09.11.04.02.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 04:02: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: c9f7d1c9-8efe-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757588540; x=1758193340; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HOZseogxC7Jw13BzxMtqs9U3YWfc5TF5Ry9p9rPXVxk=;
        b=LHdunsBuwXTtf0qwQjuEaXEy2iTFiYswQ94ocf/IjQRo7ZZx7d0NRLlPUC9Wgk21xd
         VzTavyESz+94tCimkSRupXvysqReknBVKMyCdZqJlTclyBadMEswZDxBoZijBWOT7QGb
         M7PvMR1Qqd+PaoN1Y2meykl+iTvRazyszn6HER5tzRvV9Lqo7DbD2PTpCk+CCIg1gfPJ
         FfOPme5AcwlygDz3AC08ccBvVuVFkP7oDZRzRLG6rCiltlCigqbnekC7jYd3Dn0nE8oj
         2kWOjNgDKREAFsZVSfppp7rqVK8fp1Kzr7bBpakmBmK0ZQgLiR0Oig6gnyO9oCvEQzk7
         cuug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757588540; x=1758193340;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HOZseogxC7Jw13BzxMtqs9U3YWfc5TF5Ry9p9rPXVxk=;
        b=GZPLyV+HD9tLkuvMWSvD0IRA84tRJjtPy21QSYn6Hz1ANA9pyr8V81UzwteMwuQ9T3
         Bys4TcURRT7F5al33n6pX2Wj2tHFyz/ETdgzmNmusnTdQd5HaRfWLWAj5fzZ/O6lUF93
         HOPL5nlN7r1pbzIr9KIfTFHJCjkpqjQBvcJ4Tr2I68p6CbCzPt9gItlpRnE3SFxqi2gp
         KfaDtQC8iJcK98WaIDuNWaMkj7PWGnAHh+WaZqMUSPQTf4LxdQl4FMxzjd0bm4LP+ODg
         RVk4GgLDQWdrHKPdF3Sk6bA8wuDexLGgSbgyIIAzDAbmT5c8hDftPKgIehN6J7IU6M/V
         fNRg==
X-Forwarded-Encrypted: i=1; AJvYcCXY2mbSvdZmpUC5SPwwWw82dWmpUNW+4wc96fyJwyD0QQR98Ln1a9RePvBT36aXWOzxUq+V3zpQBaA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwE491axtRsXXYCkueiZv0FiF6Ovb/oE59lQXYfzoSM3U0C0XvQ
	9LnTg29CLJ10ayEUtVR4w9XY8tn01oxwB5AZBBeQMk0LueuWBwCF6D+WvpLutdI1dg==
X-Gm-Gg: ASbGncuA9Zygn5OBI6vP+MQEqE8pal7+hnQPD59GJtwMGj81l0W2r6Fo8TtMzOry6TA
	+AiofRGWjH3js0yJcoiCT5oltV4Qh7AmJgl+n30sstJ33v/XITUIN5Stf3umUPVzOrhENfFSUSY
	/pRaFin4xhvP2Dy09KNJcWI9cOm/j2VxZTlF2o1YED9WZUH0skVa1mT/NYYeoTwmCtrLYhUzgYZ
	acKm1/GbNRu4qwgMqP0H8cEvm2EO7TSxC/1BD866pPUzbkU9suIuSYBm6VSutOESBLwZl4eFJOQ
	LbOMd1azJWYdOU6JhcpJmISlpxYi9W8/JfJb1We5KqNJvZcf2r1hdokPq+5M+vb6jHe2D+V3fO1
	T8703zVKf8nu9iA9zNT9LZ/dxSKSP53zFNng2oCWkHgima+drDArj4AWfVI/U3U62UiYBY6LFxz
	Wc63HPhCE=
X-Google-Smtp-Source: AGHT+IHnzaLBah+FOTdjftyOl5jR2taPQVoByueBEXEWqPK1VdjzzJkPE0aV9yosXbt73dDXZKlxYA==
X-Received: by 2002:a17:906:b59:b0:b07:8809:9c22 with SMTP id a640c23a62f3a-b0788099dbcmr490214066b.15.1757588540003;
        Thu, 11 Sep 2025 04:02:20 -0700 (PDT)
Message-ID: <1bb90323-6071-4aec-9f6f-33163e6f769d@suse.com>
Date: Thu, 11 Sep 2025 13:02:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 15/26] xen/domctl: wrap
 xsm_{irq_permission,iomem_permission} with CONFIG_MGMT_HYPERCALLS
To: Penny Zheng ,
 "Daniel P. Smith" 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-16-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> @@ -508,13 +510,21 @@ static inline int xsm_unbind_pt_irq(
>  static inline int xsm_irq_permission(
>      xsm_default_t def, struct domain *d, int pirq, uint8_t allow)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      return alternative_call(xsm_ops.irq_permission, d, pirq, allow);
> +#else
> +    return -EOPNOTSUPP;
> +#endif
>  }
>  
>  static inline int xsm_iomem_permission(
>      xsm_default_t def, struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      return alternative_call(xsm_ops.iomem_permission, d, s, e, allow);
> +#else
> +    return -EOPNOTSUPP;
> +#endif
>  }

Along the lines of Stefano's comment - why would these inline functions stay
around? Them returning an error in the MGMT_HYPERCALLS=n case is actually a
problem: For xsm_iomem_permission() it's only a conceptual one, but for
xsm_irq_permission() you break x86's handling of XEN_DOMCTL_gsi_permission.
I would have added "transiently", but from the titles of later patches I
can't spot where to expect that one to be taken care of.

> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1111,12 +1111,14 @@ static int cf_check flask_unbind_pt_irq(
>      return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  static int cf_check flask_irq_permission(
>      struct domain *d, int pirq, uint8_t access)
>  {
>      /* the PIRQ number is not useful; real IRQ is checked during mapping */
>      return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  struct iomem_has_perm_data {
>      uint32_t ssid;
> @@ -1943,8 +1945,10 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>      .unmap_domain_irq = flask_unmap_domain_irq,
>      .bind_pt_irq = flask_bind_pt_irq,
>      .unbind_pt_irq = flask_unbind_pt_irq,
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      .irq_permission = flask_irq_permission,
>      .iomem_permission = flask_iomem_permission,
> +#endif
>      .iomem_mapping = flask_iomem_mapping,
>      .pci_config_permission = flask_pci_config_permission,
>  

It's odd that flask_iomem_permission() remains as a function, but for the
moment that looks to be necessary, as it's (oddly enough) called from
flask_iomem_mapping(). However, for that one I again can't drive from
titles of subsequent patches where it would be taken care of.

Daniel - is this layering actually helpful? Can't we either drop
flask_iomem_mapping() (with the benefit of a cf_check disappearing), or
have it do directly what it wants done, rather than calling the other
hook function?

Having reached the bottom of the patch - what about xsm/dummy.h?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:03:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:03:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119965.1465086 (Exim 4.92)
	(envelope-from )
	id 1uwf5S-0000fv-2I; Thu, 11 Sep 2025 11:03:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119965.1465086; Thu, 11 Sep 2025 11:03: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 1uwf5R-0000fo-Uz; Thu, 11 Sep 2025 11:03:33 +0000
Received: by outflank-mailman (input) for mailman id 1119965;
 Thu, 11 Sep 2025 11: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 1uwf5Q-00005g-MW
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:03: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 f3c35c0c-8efe-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 13:03:31 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-b078aabeb9fso93476866b.1
 for ; Thu, 11 Sep 2025 04:03: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
 a640c23a62f3a-b07b32f2098sm111624966b.74.2025.09.11.04.03.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 04:03: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: f3c35c0c-8efe-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757588611; x=1758193411; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZFlQ66xf9E1AIHJgBQrFRpqSzElE9aMBia7jW0BfmUk=;
        b=eHbHBrwJGeq+lTAbcQe5TCsu/yjhzlK/sKtXLUKBUDPv0l92xz27yKE5WK41M8kdEM
         UR0hoM4LN7WaN3d5VPO4L023R6XEL0dGASDPR5N3uRj0+rquQweMyKh1Us9nnI5Ie9Hp
         Fqd2BEND/5vkFd8YNwqMaSdqJdyhHCmAyr+Q9Pobf13HLTgF81iNAiFxhmVNK9MyD6TQ
         b39A9Tya68w+UkTKf6lrcA+0C5QPqe+Vkf72PpvCi43RXrDoexqA+qHPls6O5nJHnAOE
         8X0sB1MP0Us5Pf3Tz+hGE7TMAx9ZLFhKcBLQ+s5S1N5huKoiEN0gBKsF6SoKgIsR6fle
         PXgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757588611; x=1758193411;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZFlQ66xf9E1AIHJgBQrFRpqSzElE9aMBia7jW0BfmUk=;
        b=sfcx3aXLnB+OSJ2KZUkvtdXSBVIwkd1Kc6h1zvXnVRFGqog1Ntn70eRtCupTZh1B/x
         TuEeIYz0lvWklFYWAuFCxYhnMBUHY3GAOga1MB7yK+4OjdD2zM4/UC6L2rvKJFiP/mLY
         Y26jdyr5sGvo79tq8CgNo1ywWTkvTmYntc4tlBZSCREwrC7w3gOzDLO5/IK/dpixlLa5
         1gxk0jcUyZ07yaN1m2pt3L5Omj3684ITs+z6p1DolGKDGNfZ9fbj52AFVCH5qxq62Vj+
         6yTxqKF4++dn34rXEiIL+tVSALLIzcea+adPxInqPk8nLxexKUi7TKo8WD5kMBJhKbpF
         N59w==
X-Forwarded-Encrypted: i=1; AJvYcCXC4KQZmbbl2M4lJG5/zSvM4nmaKcs4pAbqq90lcs0Hcx+LrBB2gS/Z+wIhukUv12QzysxCwqcTdK8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwDGQLuejgt+EnZI45BHlOK/TWdQ7CoBNvrApi17+vIGinhGXJu
	WSHtB1/hG2cZ48zDc/AQXXNXU/bfNpFtCSQry2BuxUzzxWT3fWByyS2Yb7OCyyMcSQ==
X-Gm-Gg: ASbGncsxqy1vYpD9cJ33e2fLmdQjg5VLmxYTFbBAsXGlie5FwA0mIuHAgvxIK15KfCd
	VyGxjLEyBLpWSFkd+wyIPy//SFnaJvs4ziXniTgJtNjYDJfLaRN4apbsQptBdwcAP8nYo/GEZ+E
	s3PMumpD4qelNJkbuuPsfjRpZqD1oo68r2Dy8hDwpV1ytOWl/4jxdTFXq6Q+S31kiiss40k3zU3
	N9FWprJ0dsbjOufFPdNwmxcuMU8NqOqUZ28QbIrwSDqjKXchD7vrR8hKc0pzGRPxzvQliIqIcM7
	qmmll487u+RNW6tTB8gdil/8yaETBIjIxmZd6/yL/TkFV9S2JuGWHd9+SdBjOJye1cbnj1p6H4z
	DAnVRQNWzhmIMfA9DLV4s/9CgGzJCQIMooeQd2cNMLUZuxlpj11hqomUUxQQGLzWogWEU/Y1I3G
	4eEzCMbSja2WsqHQqVXPAG2vTopHKh
X-Google-Smtp-Source: AGHT+IH5rhe7FE1lnrEB7PmVeSRPzqejrDlN2ih1k0s9OItCIgzLY5QgIibll4UgzFSmVKac0vlFRA==
X-Received: by 2002:a17:907:7243:b0:b04:9460:c4fd with SMTP id a640c23a62f3a-b04b1663c48mr2061566466b.33.1757588610622;
        Thu, 11 Sep 2025 04:03:30 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 13:03:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/26] xen/xsm: wrap xsm_vm_event_control() with
 CONFIG_VM_EVENT
To: Penny Zheng 
Cc: ray.huang@amd.com, "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-7-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
> it shall be wrapped with it
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - new commit
> ---
>  xen/include/xsm/xsm.h | 4 ++--
>  xen/xsm/dummy.c       | 2 +-
>  xen/xsm/flask/hooks.c | 4 ++--
>  3 files changed, 5 insertions(+), 5 deletions(-)

What about xen/include/xsm/dummy.h?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:09:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:09:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119977.1465098 (Exim 4.92)
	(envelope-from )
	id 1uwfBN-0001Wt-Mg; Thu, 11 Sep 2025 11:09:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119977.1465098; Thu, 11 Sep 2025 11: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 1uwfBN-0001Wm-IJ; Thu, 11 Sep 2025 11:09:41 +0000
Received: by outflank-mailman (input) for mailman id 1119977;
 Thu, 11 Sep 2025 11:09: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 1uwfBM-0001Wb-FH
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:09:40 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2009::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cd237ba5-8eff-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 13:09:36 +0200 (CEST)
Received: from DM6PR02CA0068.namprd02.prod.outlook.com (2603:10b6:5:177::45)
 by IA1PR12MB8408.namprd12.prod.outlook.com (2603:10b6:208:3db::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 11:09:31 +0000
Received: from DS2PEPF00003442.namprd04.prod.outlook.com
 (2603:10b6:5:177:cafe::75) by DM6PR02CA0068.outlook.office365.com
 (2603:10b6:5:177::45) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Thu,
 11 Sep 2025 11:09:31 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF00003442.mail.protection.outlook.com (10.167.17.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 11:09:31 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 04:09:29 -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: cd237ba5-8eff-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=skbS0wOlC5IYLFmra5PlObBTRryHA/XmaNmK99+xqdMIL7lO22am6AURPERYWGOXZe2ZgmuWwpcEJ+YqXK4JWxpufgeMNfI66Y1QUG6J/EPTaqT9JPH5/MDwY/AbdDAZWUxxxp4JjskAakPNYEH0JqSLiH+j2ZYzQH/Junkm2kSQ1bhpAVvCWrOZKoMw+xguYQQwVp06zuAf3TXGvwF8yeD0YRoykFQduaC8W8S2eeZml9tO8OyZUVzbNEFNw0OXLQTEIYoDpO+mx/XZiJnfRHpgxKzrKQPjiQ+emZuxwoAllIuKgdyIu1PEe8Jb3qoNUoXre8gIip5e/xpSINJt4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kSiKUZrAcTKU40jPaohK4uN8CCQUbKaVe/0osqfKl1o=;
 b=lhXHSEDzBOdsiH3jjex+Q4sGwXj1qbZvIWfrYL5/D+bu1yzEF9g712oZZN+uQbp9aDwOcGUeufi8dHYxKhdzJZBoR5zZK4nX/nsalLptF27dwpNZEsTkQ5kcl7n9deCveilZ+7T/QLGrXbNcFyuECFzs2nIP9JOJlUQ9p+Iup615R+vmMw+hW3vYACyoi0ny8evLg9A3k8aObPelHLaWEi8+a1IvGGSe1DJXbiDaMqewlYpxh9qnR1G/SBIYrRp6h8i927SFfKq17lRF0XcFWXgaOO8eP33AmHRXqYu8YDxt9IDSzcq/hYP868VnNhTOwgOq8DYPuxpS5GngiPXy5g==
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=kSiKUZrAcTKU40jPaohK4uN8CCQUbKaVe/0osqfKl1o=;
 b=k0irrSeMiP/rrf6UyeUUV3sO8L6bSfXPeDrkpy4uFYb6ZzWfe9RjYPHnNfJ2UgtBmPOXATwhvVngv8I1nNBPSgX0qRzAc4y8YRqt34Nr3lynkhlUj7fTyyCrQ+mxpf1i1415UHDM4CRs5zrSQBLpq+AxGhkdNhJISIjMExL7Xr4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 13:09:28 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Jan Beulich 
CC: Anthony PERARD , Grygorii Strashko
	, Roger Pau Monne ,
	, Xen-devel
	
Subject: Re: [PATCH] libacpi: Remove CPU hotplug and GPE handling from PVH
 DSDTs
X-Mailer: aerc 0.20.1
References: <20250910144921.29048-1-alejandro.garciavallejo@amd.com>
 <2c559b3a-9991-4aab-ad65-645ac0cca5ab@suse.com>
 
 
  
 <96b58fe4-668f-44be-9469-0ec7f4f28c6f@suse.com>
In-Reply-To: <96b58fe4-668f-44be-9469-0ec7f4f28c6f@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF00003442:EE_|IA1PR12MB8408:EE_
X-MS-Office365-Filtering-Correlation-Id: 355cf80f-2534-46e7-1fdc-08ddf123aeb1
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?cXg5SVRHbFBVdy9BRlYraXJKZjZCeDIrdHduUSt5SlloSEMrRXVuZEVhWWkv?=
 =?utf-8?B?T0RpOEZWMTR1TzFhN21GWWFqa0NJVHpVY1l2emt5TElhSjlKNkZmdjBDd3Jj?=
 =?utf-8?B?aHVoVDdWRmlKUHU1c0FoclUycTlPZlBzS2xsdDMrKzljN3NEWWNMbGsxTW82?=
 =?utf-8?B?N05tNzdRNzNqOVZjSm1pcmNWblIxSDNKSWI1clptZHVxaDhrcFB0T1A4T0lj?=
 =?utf-8?B?VUhxY09mckZ3QURZZmFzVUUzN1VMZ1FLbXViVm5vYTFSSnJ0WkhzVm1DYkJm?=
 =?utf-8?B?UXZvNWZkZEtyd1NkQnFjT05SK2owZnZKQU1QWWVOaURXdW1vWCtvYkVndDVP?=
 =?utf-8?B?T3MvSXhmM3dZQ3hRS1IvUXZmNnlibktlOUFYRFNGMEo1SU9QeTlxRVZod1Fz?=
 =?utf-8?B?N1hOOHFkcVdScXRUR3JqU1B2dU52UC9vancxK29rNFl5MUR6SUhCRFE4WWl2?=
 =?utf-8?B?TmFQRzFieW5MZVlDc08xL2RnM0paSGJvWEliOE1Mc2d6YXBoMGVMRVZ3Q1Bm?=
 =?utf-8?B?K1B6WE5EUnRaK3ZLcGlLOFRQYUdVZHBseGlDR3V0UkNOMEZWT1dyS2w3VjM3?=
 =?utf-8?B?ME1VU3hoYXRDVUc1bXBHZk5nNDhWajFHRWlQbGowTVRNNkd5UlpkQUpUTTRL?=
 =?utf-8?B?cDlZaVQ0cldDWnVLZklnV01FaU9CdStuaHFQKzZRaVR1b2pkMUZQalVkdWwv?=
 =?utf-8?B?bGd4ejBvUCt6eXp6dS84L0R4bWpxOWRzZ2twaFJzS0N0U1crU0FuWUVRcWNQ?=
 =?utf-8?B?Rk1SMlE1WERCY3JtNW0zYjRvOTFBTUxOSktjV1RXMzBJbzNCNjdkV3doc1Uv?=
 =?utf-8?B?WXExaDdiZzU0d2Y0MUNHUG9zd0ZiWFgrVmdPd1Z2L05uYlUyRWpkSVBPK1hv?=
 =?utf-8?B?NmJJclQzM2NOVitibjY1U2hYTm5WVEkyYU9VVGU0RW9SWEJPRkl6alhZRDhq?=
 =?utf-8?B?eHUvamd6ekdnaW55cnhGYnZiZWRPZXlrSTd4bGlJVkxReFE5bzVLTU5ZZmlr?=
 =?utf-8?B?cjhiYmlQR2pLZEh4QXBEUVl1NkE3Uzl5d1NPdEp5MHFTb0hsTWgxL2o3ZFNN?=
 =?utf-8?B?RXNGZWRKbGlGcmhrSCtmWGZkN2I0Tjl3T2o0VnFvSHh2VkNIaWV1MnB4Skht?=
 =?utf-8?B?S1htdzRHYnlDN3dRLzdGNEhObWtRb0ZvemtBNlFBNkpxZFNyZFlZeTNOTEcr?=
 =?utf-8?B?ak9Za2ZWVUFERjZ6L29pcHI2MFRzdzFMNUUwQlFsR0dyTWlCOEFuMnV2OExw?=
 =?utf-8?B?RnJuSDlHdE9PNE5DRk5FS053Q0p6U1RZNzNOV0tHcXZYaWg0VUpkV3pqbnR4?=
 =?utf-8?B?S3lucUZXVGdjQTNZcCtmdkFWSUsza056akZDYXpHNmxOdFA4R0ROVElVSi9s?=
 =?utf-8?B?UzE5Qlg1ZkE2T2g0U2hYQ01BZTQrWm95WWtjeFMrRG51TG44SDA2eGY1cGNa?=
 =?utf-8?B?THBmT2JtS0JnbFc2UlR1YjQ3eGVFV25pOVZHdE9PTjRydXE2dTNERCs4RG5O?=
 =?utf-8?B?UUxEZmFIdmV6Y3lRRjhaOGtFbS9naXhqRFR1NmtPRDMwY29HeU12WTJncytK?=
 =?utf-8?B?aS9JT3VHb2F1M2JwRHVwZ2VETXdodVgyanMxMmZySTlFWFFIa2NmZm05TVFX?=
 =?utf-8?B?WVNrR3lMZkdvVkF4bFBpdU9ySUhpbFI2VEVscEx5UlJ5R2pKSyt4ZFVYRDNJ?=
 =?utf-8?B?THNQUkNhb05qSCtROUNENXd3MlpHRC9Lc1BxWmZXRVJPMlR2TjZDK1JsTUMr?=
 =?utf-8?B?cG1JTXR6RFYySGp0WUNlbU0yQnRJUTdpSXdRd0pDMGVaMG4ydmxaNE9ubUlC?=
 =?utf-8?B?M2hyMmpsWUNXUnJSVlRSRTc0ekVubkE1UWR6Vm4yZzhxOHhoNTR1S0lyYWtk?=
 =?utf-8?B?QlhYa21tSmdKUExqT1Q5VGNVN3hJUnRQR095V1hWcm5GSjdRTjZzaXpJZklW?=
 =?utf-8?B?c3J6UUdTeUI1ZWRLbEFhcjNBQWo4bkt2T2U5eUJuOEY1WUZhbW1XT0xzbHZX?=
 =?utf-8?B?TzdPUjBHbFBqT0FUek1yalAwU2EyN3V5R0JISFdqL2FYZ1o5MjR2OVN2OXdk?=
 =?utf-8?Q?Fdb7tL?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 11:09:31.2664
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 355cf80f-2534-46e7-1fdc-08ddf123aeb1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF00003442.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8408

On Thu Sep 11, 2025 at 9:44 AM CEST, Jan Beulich wrote:
> On 10.09.2025 19:29, Alejandro Vallejo wrote:
>> On Wed Sep 10, 2025 at 7:01 PM CEST, Alejandro Vallejo wrote:
>>> On Wed Sep 10, 2025 at 5:31 PM CEST, Jan Beulich wrote:
>>>> On 10.09.2025 17:16, Alejandro Vallejo wrote:
>>>>> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>>>>>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
>>>>>>> CPU hotplug relies on the guest having access to the legacy online =
CPU
>>>>>>> bitmap that QEMU provides at PIO 0xAF00. But PVH guests have no DM,=
 so
>>>>>>> this causes the MADT to get corrupted due to spurious modifications=
 of
>>>>>>> the "online" flag in MADT entries and the table checksum during the
>>>>>>> initial acpica passes.
>>>>>>
>>>>>> I don't understand this MADT corruption aspect, which - aiui - is wh=
y
>>>>>> there's a Fixes: tag here. The code change itself looks plausible.
>>>>>
>>>>> When there's no DM to provide a real and honest online CPU bitmap on =
PIO 0xAF00
>>>>> then we get all 1s (because there's no IOREQ server). Which confuses =
the GPE
>>>>> handler.
>>>>>
>>>>> Somehow, the GPE handler is being triggered. Whether this is due to a=
 real SCI
>>>>> or just it being spuriously executed as part of the initial acpica pa=
ss, I don't
>>>>> know.
>>>>>
>>>>> Both statements combined means the checksum and online flags in the M=
ADT get
>>>>> changed after initial parsing making it appear as-if all 128 CPUs wer=
e plugged.
>>>>
>>>> I can follow this part (the online flags one, that is).
>>>>
>>>>> This patch makes the checksums be correct after acpica init.
>>>>
>>>> I'm still in trouble with this one. If MADT is modified in the process=
, there's
>>>> only one of two possible options:
>>>> 1) It's expected for the checksum to no longer be correct.
>>>> 2) The checksum is being fixed up in the process.
>>>> That's independent of being HVM or PVH and independent of guest boot o=
r later.
>>>> (Of course there's a sub-variant of 2, where the adjusting of the chec=
ksum
>>>> would be broken, but that wouldn't be covered by your change.)
>>>
>>> I see what you mean now. The checksum correction code LOOKS correct. Bu=
t I
>>> wonder about the table length... We report a table as big as it needs t=
o be,
>>> but the checksum update is done irrespective of FLG being inside the va=
lid range
>>> of the MADT. If a guest with 2 vCPUs (in max_vcpus) sees vCPU127 being =
signalled
>>> that'd trigger the (unseen) online flag to be enabled and the checksum =
adjusted,
>>> except the checksum must not being adjusted.
>>>
>>> I could add even more AML to cover that, but that'd be QEMU misbehaving=
 (or
>>> being absent). This patch covers the latter case, but it might be good =
to
>>> change the commit message to reflect the real problem.
>>=20
>> It doesn't quite add up in the mismatch though. There might be something=
 else
>> lurking in there.
>>=20
>> Regardless, I don't want this junk in PVH. Would a commit reword suffice=
 to have
>> it acked?
>
> I think so, yes.
>
> Jan

The problem is present in HVM too, I think. It just clicked to me that if A=
ML
overflows the MADT it WILL corrupt whatever is after it, and how many times=
 (and
in what direction) the checksum changes is undefined because the memory aft=
er the
MADT is undefined. I somehow thought we allocated a full 128-CPU MADT, but =
that
doesn't seem to be the case (rightfully so).

So this is a general ACPI memory corruption bug. The saving grace is that t=
ables
are already parsed by the time execute AML, and the corruption doesn't seem=
 to
reach the DSDT.

Modifying the DSDT to avoid the overflow seems unavoidable. That should fix=
 the
root cause.

I still want to remove it all on PVH, but HVM should be fixed too.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:26:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:26:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1119999.1465107 (Exim 4.92)
	(envelope-from )
	id 1uwfRX-0004RH-0J; Thu, 11 Sep 2025 11:26:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1119999.1465107; Thu, 11 Sep 2025 11: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 1uwfRW-0004RA-TO; Thu, 11 Sep 2025 11:26:22 +0000
Received: by outflank-mailman (input) for mailman id 1119999;
 Thu, 11 Sep 2025 11:26: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 1uwfRV-0004R4-Ba
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:26: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 23e4289d-8f02-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 13:26:20 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3e07ffffb87so334650f8f.2
 for ; Thu, 11 Sep 2025 04:26:20 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e760786c95sm2182450f8f.17.2025.09.11.04.26.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 04:26: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: 23e4289d-8f02-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757589980; x=1758194780; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LgUD10XgMjlx4sSop+a3xfy6O4s1Zq45/17JnlrCfy0=;
        b=A13rC248+b8wPzS4O+UHGqejsQoA/JpSz1IiPcCgtPLnnlQ0ojRqJY6n+FHNK0IOJS
         VaYohDNHF7rT5nMx4mtgnIPqKcZatLUvwIaBCoh/DFYJYu7xXIiztA/jr8rIh37Foxxr
         +Gw7VQdKpLQ1OTe1tV+X3VEIpVKtiwFo113/k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757589980; x=1758194780;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LgUD10XgMjlx4sSop+a3xfy6O4s1Zq45/17JnlrCfy0=;
        b=QDZSU0kkiipVDvVOivzg6Acs6Uy+HOQyxMYPW+Q1SrTgMkXE08e9g9GFs+Oo+oU7EM
         +d355RmEsunox7VaQyU6eqxFTteqFFpHzKilP+2bbVKl30bSVa2bGVo8brVS4sR8PLLj
         7OqrZA+8ehY1sA2U15/pxM8UBgEONHV5Mdf6+JpedfqUT/LMLvnJEsKM8vGGZIE4oMT6
         9bTLA/LYtrDclsWSFybU5rlSAaLbu3ccUzwsuFZxPAcdLEyjFfqJ5zg1wgvPl+ZWiZzi
         k11miznBD5yYvRr6DAM40dBhwGwlK7LJG0HfbZlfNMmhyyHCTMN8bfpqeBOl8ci8BUAS
         cd9g==
X-Gm-Message-State: AOJu0YwjRxSUlAHU97jhQbIrufJYJIQaxJbKN9Orb/aEXm9TYfD+xq1/
	xDnOhKmEg5HWuwQ7iKrTQ4P4EAm4pJ+7zhVvTbSqyOVkgB1sEZ3xBXXkjun6ALGDVXM=
X-Gm-Gg: ASbGnctoLmHbkKPWbtBv5lRvlJSE8KGLTVW/2onXBeMpKvDXpIMM1xVuN0pvCEo8QGz
	g/GyC7uWvyRaMcsWUpC5R7UVSTIUZNlPSgUyWQ4YPgIcHwq3ns8TRukbN0KDKLpgCQ6t44i8HH4
	6jeS8ACk4gfTMvBIIvLBokHK3g64ew8SkBeSQVhZIEuK0yCH3q01nUnqEyyV+CYy0ztYsSUplUl
	DqmLztPf5PkrWt0a+cYHj3WSS+YX7T2Vqkc1GPeLDX3ARPiLEwKw5qRbf9hNQsFLsrA53Y7/Oli
	t1B7Se5zkm99pi0xXwRTJLQLbftxhgZ7UE/XjxXvMq30B15+eK4fpHc3Zf5mTQglRUZh2X8y6Jz
	jlnzrua9MNABP9LyHUQTYXpietUc19oMZs/z9tO9XpkKTr8SYv1D1Osv/IE2s+Ebf/J2EAiR1Xg
	CKyIY=
X-Google-Smtp-Source: AGHT+IH5Dq6jeeKZcCYmxSP0YqtEsAsY63UOCILA04X0me8LgHaovKBBqKPMvpOC94haMCjQKnGySQ==
X-Received: by 2002:a05:6000:26d3:b0:3e7:6367:2bc6 with SMTP id ffacd0b85a97d-3e763673233mr802745f8f.56.1757589979799;
        Thu, 11 Sep 2025 04:26:19 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 12:26:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] CI: Update x86 to use Debian Trixie
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Oleksii Kurochko 
References: <20250910222313.1858941-1-andrew.cooper3@citrix.com>
 <20250910222313.1858941-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: 8bit

On 11/09/2025 4:06 am, Marek Marczykowski-Górecki wrote:
> On Wed, Sep 10, 2025 at 11:23:12PM +0100, Andrew Cooper wrote:
>> diff --git a/automation/build/debian/13-x86_64.dockerfile b/automation/build/debian/13-x86_64.dockerfile
>> new file mode 100644
>> index 000000000000..20e9d2f3f52d
>> --- /dev/null
>> +++ b/automation/build/debian/13-x86_64.dockerfile
>> @@ -0,0 +1,76 @@
>> +# syntax=docker/dockerfile:1
>> +FROM --platform=linux/amd64 debian:trixie-slim
>> +LABEL maintainer.name="The Xen Project"
>> +LABEL maintainer.email="xen-devel@lists.xenproject.org"
>> +
>> +ENV DEBIAN_FRONTEND=noninteractive
>> +
>> +RUN <> +#!/bin/bash
>> +    set -eu
>> +
>> +    useradd --create-home user
>> +
>> +    apt-get update
>> +
>> +    DEPS=(
>> +        # Xen
>> +        bison
>> +        build-essential
>> +        checkpolicy
>> +        clang
>> +        flex
>> +
>> +        # Tools (general)
>> +        ca-certificates
>> +        git-core
>> +        pkg-config
>> +        wget
>> +        # libxenguest dombuilder
>> +        libbz2-dev
>> +        liblzma-dev
>> +        liblzo2-dev
>> +        libzstd-dev
>> +        zlib1g-dev
>> +        # libacpi
>> +        acpica-tools
>> +        # libxl
>> +        uuid-dev
>> +        libnl-3-dev
>> +        libyajl-dev
>> +        # RomBIOS
>> +        bcc
>> +        bin86
>> +        # xentop
>> +        libncurses5-dev
>> +        # Python bindings
>> +        python3-dev
>> +        python3-setuptools
>> +        # Golang bindings
>> +        golang-go
>> +        # Ocaml bindings/oxenstored
>> +        ocaml-nox
>> +        ocaml-findlib
>> +
>> +        # for test phase, qemu-smoke-* jobs
>> +        expect
>> +        qemu-system-x86
> qemu-smoke-* remain at debian:12 here.

Oh, that was an oversight.  And I missed in in RISC-V.


>  And IIUC the plan is to split
> build and test containers, so those dependencies are not needed here.

I maybe didn't phrase the comment very well, but the split I intended
was the hardware-running containers vs everything else.

What the hardware containers need is almost disjoint with everything else.

>
>> +        # for build-each-commit-gcc
>> +        ccache
>> +
>> +        # for qemu-alpine-x86_64-gcc
>> +        busybox-static
> Same comment as above, but ...
>
>> +        cpio
> ... this should remain, and likely moved to "Tools (general)" section.

Hmm, probably yes, although I'll do that as a prep patch and fix all the
impacted containers.

>
>> +
>> +        # For *-efi jobs
>> +        ovmf
> And this one too.

Tools general?  I don't think so, no.

But we probably should have a combined section for qemu based testing
and call it done.  This is overly fine-grained IMO.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:27:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:27:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120011.1465117 (Exim 4.92)
	(envelope-from )
	id 1uwfSs-000526-FG; Thu, 11 Sep 2025 11:27:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120011.1465117; Thu, 11 Sep 2025 11:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwfSs-00051z-Bk; Thu, 11 Sep 2025 11:27:46 +0000
Received: by outflank-mailman (input) for mailman id 1120011;
 Thu, 11 Sep 2025 11:27: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 1uwfSr-00051d-Qg
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:27:45 +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 50c43d2e-8f02-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 13:27:35 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b045d56e181so91147266b.2
 for ; Thu, 11 Sep 2025 04:27: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
 a640c23a62f3a-b07b32f2f00sm110953366b.93.2025.09.11.04.27.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 04:27: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: 50c43d2e-8f02-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757590055; x=1758194855; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=D3k9V7BvoneZ+R9aMKc7bJA7A/iHy7smlcJ7KB07gDM=;
        b=Hft1aNhFuLcFxWIeVDAb0PFsCOOlYP6i19t8e8GQthKnjzi92V1KpV7PxXkZCAeSoe
         WZjFQHw1tu/BcUVJLt0/0SqGlquldZg5xLSQoer9hZ/pnWk2oYOGjt/RZ4996WFlcZpn
         PfsRdlbR4Y2hqph1mTwnNsF2y2poOn9iucPaezN2Dmnyeb7LQ80tTks2cZMHV3Urvfzs
         HZKbhKt8o9mlXHZUybHREllTCU9tCu2iAUNJkr8gvqlQLV1g32CpjhuGPpehPu5RRh9F
         BauDFfRG41yLxile4RVL8wgLCAmMPO4QiCSkfJFEs6O76wRB0zlEZhWW8iBcbCijp1CM
         p10Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757590055; x=1758194855;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=D3k9V7BvoneZ+R9aMKc7bJA7A/iHy7smlcJ7KB07gDM=;
        b=FviQuqgp13BY48/6SEH/SUKWRNXkie+NTt3MKz1LfvBFElktyToYW66RB7KCEwkctH
         cryG7EDrdT/WpWdf8E/q/xYwNc0UlSGl4OuUO19qSvsruthst7jd3dtFgiZrSX3HCZMA
         Jn8b3f2/hSEakm90haXnFCIqv2DHtD/tmIrB8MIf0iAOMqopUcsUfLF8Ttn7xMady9xs
         fXkVTjMDikfe+m7fe+aNreq8o2WqgvF6B3WUo6YmUlubDUnVsfK6l0ixLYXNPrcvh1/M
         TzWj6aQhp/puYk+Mur4bhnsbDV98bPSJwuaBKDr/VJKLJ3PvlyElIZYNc/9rFv5BNdkz
         XoFg==
X-Forwarded-Encrypted: i=1; AJvYcCXnne2XmYovvVQYI3aITi3UCtfQd2ORAtfGAyv6umOVAg+FFRs89fwOM2PLaZzcmGVPAA1kXu8jbNA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzISfD9tW9O1SoteMTghfbeKJVTaw36fhWJ0PVthE54HUkcfA8K
	xQSAIwU5vFefwD8PHzwTziwErz9EaREgrbmfBCKHJaKXy3gzQ8iJZmgd9m2zggoLcyFUDqSoU/r
	Afbg=
X-Gm-Gg: ASbGnctEPh9M+K/u5VgOJ6dhKMlj59Gy1oVkP7evQaKFgCzGN9V9jgEjnzKGGFZ1V/S
	X7n8Szhu1Qvum5E6999jSHrajH/5KRtsCzOg81isWzvKCUltxmTbh2vHX70UEgSHEczZhIz+IW1
	AQKJBkJO278XeTkXJH7eo1Zb2FGpDtsrTCMILg7VPH0v4TRDES6TiMDK/qyFL1zqhR/LScnFadj
	bP0dGdO/yNzL5BOaXnWJL9moF2CzI/lUNn7oSSF/SQBLOP/WRV9Ub1oZPrD3WYo6Z33IQ1SWAlq
	sLfF/mpKzcJyUXUbAyzV7dkHdjY2h0SCRXKW0/tOzZPluQjI5YsgV4rrV0RBEiESZf5sJ6jrlYx
	Ng84SVaYMFADl+lzIxY17tjcFNcpHkdL74qhYEqzBdo4aQFC3SjPaikxV4SKpNlvZlLk3KW1hI4
	EsdTgZdrOBiO13kwPDkw==
X-Google-Smtp-Source: AGHT+IEB4R4H+f3wOlx1oU548+arFi4icehlzbGM5eEGWPK1h06bTMcdo1qjw2lkWlkkDRiRRvuXUw==
X-Received: by 2002:a17:907:96a7:b0:b04:a39:9b98 with SMTP id a640c23a62f3a-b04b13bbd11mr1792929766b.5.1757590055006;
        Thu, 11 Sep 2025 04:27:35 -0700 (PDT)
Message-ID: <2d4bed7a-352b-4090-a07a-fd617e2f932b@suse.com>
Date: Thu, 11 Sep 2025 13:27:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/26] xen/domctl: wrap arch-specific
 domain_set_time_offset() with CONFIG_MGMT_HYPERCALLS
To: Penny Zheng ,
 Stefano Stabellini 
Cc: ray.huang@amd.com, 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: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-17-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Arch-specific domain_set_time_offset() is responisble for
> XEN_DOMCTL_settimeoffset domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_settimeoffset-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the
> common/domctl.c in the last.

As I keep seeing this same wording, I finally have to say something there as
well: For one, the last patch doesn't introduce CONFIG_MGMT_HYPERCALLS on
common/domctl.c. In instead makes the building of common/domctl.o conditional
upon that control being set. And then, "in the last" (btw - last what?) is as
unhelpful as "in the next patch" or "in the previous patch". When writing
commit messages, you want to make sure they make sense all on their own, no
matter in what order patches are committed (in particular possibly piecemeal
and interspersed with other patches). Possible replacement wording:

"Wrap XEN_DOMCTL_settimeoffset-case transiently with CONFIG_MGMT_HYPERCALLS,
 which will be removed again once common/domctl.o's building as a whole
 becomes dependent upon that setting."

> Signed-off-by: Penny Zheng 

Acked-by: Jan Beulich  # x86

(i.e. specifically _not_ the common code change)

I also wonder what our (Misra related) position is towards leaving declarations
around in cases like this one, where they're not in support of DCE-ing of code.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:33:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:33:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120024.1465126 (Exim 4.92)
	(envelope-from )
	id 1uwfYn-0006ap-1u; Thu, 11 Sep 2025 11:33:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120024.1465126; Thu, 11 Sep 2025 11:33:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwfYm-0006ai-VG; Thu, 11 Sep 2025 11:33:52 +0000
Received: by outflank-mailman (input) for mailman id 1120024;
 Thu, 11 Sep 2025 11:33:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwfYm-0006ac-8v
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:33:52 +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 3070dbb5-8f03-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 13:33:51 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-b07883a5feeso105415666b.1
 for ; Thu, 11 Sep 2025 04: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
 a640c23a62f3a-b07b30da289sm114200166b.17.2025.09.11.04.33.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 04: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: 3070dbb5-8f03-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757590430; x=1758195230; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TeRftCh6CmvexS9+5z6TL7fW/ZDSwEmG+WJ1MAF1Li8=;
        b=CsD7WK3s9dTPNE1BMRHrsHWRVo7Gom8hLDkjeQ/Sj720iuF+1IrEk/8Kq9WVnou9zR
         VHk5xhVgkI+lCMrwnzyU8pUNWCaHrCmm2pXW25GqvT8Ulb3XY3b/LgprmdX+EuRHV3Te
         EXNUsNqdgw2NT83V6XmDy/awfWtD8sUd38u9EgmdPjCcrCWS+nhz6m0dhnxisoVsozVo
         vNZsg5kQhwITxbGNxQ1MMPkciANbWX1CqIG1OVLN/6pKu2u293BsRiBDvPuahXp47UOx
         UpgYBA5QKpUBM+ow11TYMIcK4c9hniSFSgcKeVvuYESP3NNqtRAuTJALaeAWiTyxigjg
         Tvaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757590430; x=1758195230;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TeRftCh6CmvexS9+5z6TL7fW/ZDSwEmG+WJ1MAF1Li8=;
        b=YnaN43o/9RGOMoNjYEIYkIIkJRXpo4sWMa6ogQW9QIH5eV6FVaiKa0+6r564X5ChS6
         fTMjNb71yOhIoQX+rCUXXNNn0Pq3jaLrDeqrDlgJBM1mi3S8zpTLC9Z2gE7tzQO/g6Zl
         NCWxbd63YwD5bJUKmZ4W+H1MD4+m30iWtd+Phj0t41Fd0Q515nI0+Vc5IjxVdHhkqjq5
         phMTytutyN/qELdKc1SmMGvgVL9ZTUtPF7w4FcN2cW1BFxNK7SDV6AD+UKkzi4X2pzj1
         upG6SVuHLN9pdL7WckZxXlv8YlDT/5EohsPEV9n3hprFyd+n0q3w7a0d0XmWmiioU7u/
         nnOw==
X-Gm-Message-State: AOJu0YzBMUFWVrASzu6reZ7y8VInM158MJ1aQbTj3oXTVjwrY/CTlAo3
	k/S2sE5ySEPattum4R2sWB6M4wM4kcXWPsgfJbeUI+uQM5sz/ddlYrQFbp3ijATjjw==
X-Gm-Gg: ASbGncv9fvkwvwXLLGNsbvjw7X5AL2jEshSwURmmfNkoqTFHwM4H3R6yUYYaGLQsqfm
	NpK5rq1MzmVFhIc9aaCEMH+EJbgQGdrMWYEzYGFnsGlD4WK9wRhGcSPR6FJ8vy9PtbVMa1TA8+5
	1kAWsBMAcVuXOpJYNwNQAJwrO19r2wNB95exuD4Xz/+qY65Sqt2xvRQ5r5F/GKjnD8MnlORhjxf
	Co5MzPtjVijtuIR4HcpdCinKUE+0ue+25sMjC5A7i33Wv17K04JFe2QYU51FHWGXCR1gK0EBKz+
	3yYO2bCJbyYzlRPquaPhVtV9ZUc8Bstluo8QXx2uTLYiJgM2aHftKYI4oFvBErIM9s5KNqZeGnx
	UL4Z9FpS+KiO9Z+z39GC3T57jI0lnNYcXLs63huybiJC2oBizGqH2CFKXztkpIyGs+yY7Kkty6C
	MvX1JUqo0=
X-Google-Smtp-Source: AGHT+IEcd8/XntfiHd7x0vWf9fdavgBOdbJ3MF5Fl95o9WchJO93pj3zk+bLiwsOyTeIn0DyneqY6w==
X-Received: by 2002:a17:907:9612:b0:b04:70f8:d454 with SMTP id a640c23a62f3a-b04b167e38fmr1815371666b.51.1757590430318;
        Thu, 11 Sep 2025 04:33:50 -0700 (PDT)
Message-ID: <62c80f82-d85d-4d11-a7f2-4193bc882911@suse.com>
Date: Thu, 11 Sep 2025 13:33:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 17/26] xen/domctl: wrap xsm_set_target() with
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: xen-devel@lists.xenproject.org, ray.huang@amd.com,
 "Daniel P. Smith" ,
 Stefano Stabellini 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 04:37, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
>> Function xsm_set_target() is only invoked under XEN_DOMCTL_set_target
>> domctl-op, and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
>>
>> Signed-off-by: Penny Zheng 
>> ---
>> v1 -> v2:
>> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
>> ---
>>  xen/include/xsm/xsm.h | 6 +++++-
>>  xen/xsm/dummy.c       | 2 +-
>>  xen/xsm/flask/hooks.c | 4 ++--
>>  3 files changed, 8 insertions(+), 4 deletions(-)
> 
> No change to domctl.c ?

And xsm/dummy.h ?

>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -59,8 +59,8 @@ struct xsm_ops {
>>  #ifdef CONFIG_MGMT_HYPERCALLS
>>      int (*domctl_scheduler_op)(struct domain *d, int op);
>>      int (*sysctl_scheduler_op)(int op);
>> -#endif
>>      int (*set_target)(struct domain *d, struct domain *e);
>> +#endif
>>      int (*domctl)(struct domain *d, unsigned int cmd, uint32_t ssidref);
>>      int (*sysctl)(int cmd);
>>      int (*readconsole)(uint32_t clear);
>> @@ -258,7 +258,11 @@ static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
>>  static inline int xsm_set_target(
>>      xsm_default_t def, struct domain *d, struct domain *e)
>>  {
>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>      return alternative_call(xsm_ops.set_target, d, e);
>> +#else
>> +    return -EOPNOTSUPP;
>> +#endif
>>  }

Again I would have expected for this inline function to be wrapped as a whole;
the title says exactly that, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:53:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:53:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120055.1465160 (Exim 4.92)
	(envelope-from )
	id 1uwfrq-0001c7-3k; Thu, 11 Sep 2025 11:53:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120055.1465160; Thu, 11 Sep 2025 11:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwfrp-0001aY-VU; Thu, 11 Sep 2025 11:53:33 +0000
Received: by outflank-mailman (input) for mailman id 1120055;
 Thu, 11 Sep 2025 11:53:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwfro-0001L2-OK
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:53:32 +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 ef42a230-8f05-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 13:53:31 +0200 (CEST)
Received: from DS7PR03CA0184.namprd03.prod.outlook.com (2603:10b6:5:3b6::9) by
 SN7PR12MB7834.namprd12.prod.outlook.com (2603:10b6:806:34d::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 11:53:25 +0000
Received: from DS2PEPF0000343F.namprd02.prod.outlook.com
 (2603:10b6:5:3b6:cafe::ea) by DS7PR03CA0184.outlook.office365.com
 (2603:10b6:5:3b6::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.17 via Frontend Transport; Thu,
 11 Sep 2025 11:53:25 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF0000343F.mail.protection.outlook.com (10.167.18.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 11:53:25 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 04:53:23 -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: ef42a230-8f05-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y8jXL90Mj1dKfsAu1tQhYtMmhJhK0bnMWtZW0/pldbw/+j9jvsHWzH4lOO9MiskOD0pGZt97JLhY6xOrhMt1ohEdB3X4mck8ofsn+TsqxOwECs8bRfrtNj1nUjgaFBCTi9GRbs2pTz1NS++J5unk2vA1VPhqCRTys0U74tkepjk2DIEIKwxblfQ8Uf/EADLEwd37VzZzlOmKXFErfi7Iz4iJZKDPqLv5+pqVRGOoDFWJD63V3ESM1N17/+W9RuyUL6G+tdY7TfBrqrJwCQZ2Wjcw2PColzBGUsfJRYfMfdTaovtaPFtOQAwAkkqyRHm0HZqkTbEZFrAwu3B/0k0Jrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cwmMyqpJdahiFQT+aq+YWQtIG3NlD4esX8arqlLAnZU=;
 b=xZZ5rti0GlYmofwyZAGsR1tRRdBK6P7UykS6KUDRAnsFvCJDOe7hSIehVgikypD+rzWP7ZxgsL+Qk6WYpHql2fpxTJU4jSW3Ng7oxT/4UhLUMD4b6CxqOJwgwXJnDY+CpS3wcokZtThEl9rIFjUJGquxiYDy0DpujfyvGE+XjU4QxBr3j4SoHHpbuAeJ5a+FLyb2NYYuU9vVnxeyQu0dQ1nCEEm83hcV1RBioA/B0f24yDMFMX1jGqFUX3VsQgN6YeM98CHB2XH5bA3Ay0v/l243C4hUZD0Nc6nYBJCfex1Lng7pxg+P/4QUgb0lR4PTXqpKWegfQGilR1S5j5lFhA==
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=cwmMyqpJdahiFQT+aq+YWQtIG3NlD4esX8arqlLAnZU=;
 b=qkzwdikVYvUa6KzHwNHkQcMI7vVz5EY2vTik81VYFzJmzwEX/FVTi8TtgTYYggNk5VHRuYcbWBVwoyhNISDQl29sDPQiDOD67lj44wl6EyYa201PYyrjlYPk74xQ0Lvc15QYob9HiStLUCDRaCCRUhULWDkrJr51di/ay0T49+g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD 
Subject: [PATCH v2 2/2] libacpi: Remove CPU hotplug and GPE handling from PVH DSDTs
Date: Thu, 11 Sep 2025 13:53:03 +0200
Message-ID: <20250911115308.16580-3-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343F:EE_|SN7PR12MB7834:EE_
X-MS-Office365-Filtering-Correlation-Id: aa27fa81-f89c-45bd-296b-08ddf129d0ac
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?K7i+cOfacqlXJDM8MmdSaxOUQcXqCAIjB4SJXVOshgWwcx7IBme7C/p2yIcF?=
 =?us-ascii?Q?sA0/arwjTxa25GiGhuQO8xXgBS9QjaW862ty+AHtWuSS+6WOdLoAidmRhpKk?=
 =?us-ascii?Q?bVyC+x/nWvfztcZRnMPUHhXYO9GqNUoe1JwOAaoj9JWI1nf3sj0cd0CQ7gYo?=
 =?us-ascii?Q?HcyUGDutlX+ZM+UtbgOJ5LbSWXYyJW45Fd2QUK7RI3nllfM9NKF6LA7KAc9V?=
 =?us-ascii?Q?aL6KV3YJRYvwea6K3eFEMgqD+YpRoBLoJNvup/8giz5JP3ZVeEq4rxswq5TH?=
 =?us-ascii?Q?Z+uJLaadstWKgqbxQFfg0Y7tGClDTvgdIJ3HdVeQEbJyzL2AxfgiRyyymSej?=
 =?us-ascii?Q?hxfVvpsZj9rJ10nktfcx4m0zwEsB6iS7f0upFrVjbgkacW2ecxFTG1z8j/Xk?=
 =?us-ascii?Q?5SZEwvka5Ggbm9nSZQvyDn8rP7zyiT2203yCDwKx8NG/xifpWEilHxt53fi2?=
 =?us-ascii?Q?KaEPCU01GY+Rsb/w29lh4+sTJOfQxKM6TIYhhVahKmMlw4Zw/HRnr9vw6FK3?=
 =?us-ascii?Q?Ggm02RTIU8xhEcNTL2ia5eCYh8k/Uqxeq00ibwrgJfhG1ahpHoHh8CKe9RIY?=
 =?us-ascii?Q?dem4qqoKH7bE+ZnrmdolsgiaBfoZ2oCELGB212H8m3nsAUmqWTxKz9tZJ9Ik?=
 =?us-ascii?Q?JZawWQ4GyLcPsOfXBycHDmcydrSSusGhPT8fMAl+uRqPgGpu4J6oFvU4s7U6?=
 =?us-ascii?Q?wLEuStcTMlH8hUS3A2Anxb+0DX3gTBL07zvI6JFR0WQALys66eSjBTSk5rD6?=
 =?us-ascii?Q?3WNwhIB+x1cSrHEDofh7qIYkB3yT1xaDch9BKcQ18BfYpwkigh2XfmJHAQnk?=
 =?us-ascii?Q?EXoZvKYXoXSDIKX8lUrMjo61W+uDYTQb+1IBZdS/m8ujva82Tm6Xs5EtUYtg?=
 =?us-ascii?Q?uIfy6kSZvWxxFOnB26wv3EU/0hke/tjT1uMs0PUY8M/tq4h26dZFvKpJ9AFo?=
 =?us-ascii?Q?xtteOXHat5WIyrhvzmePSHIrO75b+jtmb2q6oTCXLORPQ7Z8g4ZtK7g+dsVn?=
 =?us-ascii?Q?6EthjpJplDl9fC66MTUcp9TIA6lc4ehRW2Uyv5pZTav+0kPW/OKTWeCkK03c?=
 =?us-ascii?Q?/ckJas9Ig/WpNFj52mShCy8EIsQ87SQnGqdudQsvMn+JKotx2+3mRQADecra?=
 =?us-ascii?Q?WudMZz/xDFDRSBBFZuWzv+yUU2o2pqlfzUN4knJ5K0RTJmeVp4zjDiXljOop?=
 =?us-ascii?Q?TArH6OPpF/Z9O8hbQYBLbqepudV94UUV97QJTLdNfN7dTYf/gpOKNJQrPeiw?=
 =?us-ascii?Q?hYNNzEeSm7Epy3GwTClc+GBIvazue5FHctdXoQJFvqECT1n1VWeE9SZyDYzc?=
 =?us-ascii?Q?YaFvrUlcytFSVHKEO5c6h4D6i587JzJdgV8uoVW7AlknzI0EPFeFLlz71+Wo?=
 =?us-ascii?Q?p0hMjAhJu5Z5wxIY3j5CkMdA7CZ1f1nWeWU6J/KwgV0moEvFlTfffDWQbhpy?=
 =?us-ascii?Q?Fl8K0mPv5MdNVGtc+7mK7peqWpDi5yjgCdf2+3O/kfhD4RuMF5tDlr+CdGJo?=
 =?us-ascii?Q?AkEP+tXvZpcG5gIHoIxSPi9xgFug2LO9HPoN?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 11:53:25.2576
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: aa27fa81-f89c-45bd-296b-08ddf129d0ac
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7834

PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.

Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.

This shrinks PVH's DSDT substantially and prevents spuriously executing
a large amount of AML with no purpose at all.

Signed-off-by: Alejandro Vallejo 
---
v2:
  * Adjusted commit message
  * All other tags except S-by moved to patch 1.
---
 tools/libacpi/mk_dsdt.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 06a229e2e9..cc4ed3961c 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -218,6 +218,11 @@ int main(int argc, char **argv)
     pop_block();
     /**** Processor end ****/
 #else
+    if (dm_version == QEMU_NONE) {
+        pop_block();
+        pop_block();
+        return 0;
+    }
 
     /* Operation Region 'PRST': bitmask of online CPUs. */
     stmt("OperationRegion", "PRST, SystemIO, %#x, %d",
@@ -265,10 +270,6 @@ int main(int argc, char **argv)
     pop_block();
     pop_block();
 
-    if (dm_version == QEMU_NONE) {
-        pop_block();
-        return 0;
-    }
     /**** Processor end ****/
 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:53:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:53:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120053.1465144 (Exim 4.92)
	(envelope-from )
	id 1uwfrn-0001LG-Kj; Thu, 11 Sep 2025 11:53:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120053.1465144; Thu, 11 Sep 2025 11: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 1uwfrn-0001L9-I8; Thu, 11 Sep 2025 11:53:31 +0000
Received: by outflank-mailman (input) for mailman id 1120053;
 Thu, 11 Sep 2025 11:53: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 1uwfrm-0001L2-BV
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:53:30 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20602.outbound.protection.outlook.com
 [2a01:111:f403:2405::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed765fbe-8f05-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 13:53:27 +0200 (CEST)
Received: from DS7PR03CA0187.namprd03.prod.outlook.com (2603:10b6:5:3b6::12)
 by SA0PR12MB4493.namprd12.prod.outlook.com (2603:10b6:806:72::24) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 11:53:23 +0000
Received: from DS2PEPF0000343F.namprd02.prod.outlook.com
 (2603:10b6:5:3b6:cafe::c2) by DS7PR03CA0187.outlook.office365.com
 (2603:10b6:5:3b6::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Thu,
 11 Sep 2025 11:53:23 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF0000343F.mail.protection.outlook.com (10.167.18.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 11:53:22 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 04:53:21 -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: ed765fbe-8f05-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=V0W5TygsqKkcMfnJ7wgAu+c66q1oCUpujlPKqdlQ2wD0RU7PYgwwpeH3P3T2cQJGzknjY+0vIMkhIdxzrGKRdJ3vhNxer9EutVnCS2jm67Y5mL0HR5bUKRYAtxazaJDRuUHQPvqKi0KIz99CnIwubcyA2XNmAm/gUnzEbsPShIEKGbEqcmSNU8MBXtjIBJzg8wgNLKO5CyaousT7rFQ5RT5fU8lg/wVlWrYrXqQ6qn/teFylOLYf5knnN87fZQfkc1SJEPlDfK8JDVJ8Rnv8Jr7D/iS5SBMnp9+ekFDZfy1pUGVz8FATAit9OdF/3DF2733kcGJZQnn9d9g2SEp0+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1GhQ34t6zDY5lsPGRwXvJvYhlFV8itdLff0nmyIBRPU=;
 b=lqxMosQl1tcV0OkL/XRZXLaEwnJEnowM/tWhS6bccH8bJbJx2cBqvIs4W25Meqh4F2vG9rwAJ4wjNcIZHZDJUfHH/lwgbfv13HisCN520MVtsm3kjjU9rQrSJgtn7tbtYHU9oQiGloSWj/OijcQevzqru2f1T16VxMbi7eGT5MrQn5Dwqcjt9lmG7eYLO6/qlqMFRbGuMW8mWllKBRc/48UFLaqkXmJazVWiAnNkXAVTmFADc6J4i32HiYZn/Yl09tMPfs8aqnfdFnB4xh2EEUCmdLKynUpeuDz6T68LhZYNjhyGWCbP90NDSIpg99MS9cNQ3iqj9KUY/JfIWVUbTw==
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=1GhQ34t6zDY5lsPGRwXvJvYhlFV8itdLff0nmyIBRPU=;
 b=RuRe2kKUJc6NsL+0DVtRdTpxUtgj5TjDfQEziqnr5Of0ywXPFc58hPaCTgKyFXB9Ya39u7eZne9IpBltdiBOLpNA2UJnkLAk2LdiAFdHjD766X0mspP4ow/Pwae+X0bPQyAPAcLvOI5yX+AmSyF4mzmDrYz3NE4W/+lYF5sQmHI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD 
Subject: [PATCH 0/2] libacpi: Fix memory corruption on ACPI CPU hotplug
Date: Thu, 11 Sep 2025 13:53:01 +0200
Message-ID: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343F:EE_|SA0PR12MB4493:EE_
X-MS-Office365-Filtering-Correlation-Id: 7b50d947-7b9e-4a30-1b34-08ddf129cf1b
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?SrDzBziOhu5+9gQdP/v0p6tj0GJ3pJkYKAbZZIeS/9d6fZj6fyEpJdsjN4lC?=
 =?us-ascii?Q?brMJ5U2DofXXPgLcV8XAJu3IIPAKEetmez2IKW7hCIHz9aWR2KlOjg1XZUcT?=
 =?us-ascii?Q?jAOwBMWYgRWJHXHcEOtAK+t8TfARZyNgYDXemaxdLc1WSzkSljs+GBr1zXBg?=
 =?us-ascii?Q?uhWGFXb6tE3FdfH1Grh8w0LuyC7mpfbzVZdRdvfdP+J7CwA3xjAPE6VkGqTR?=
 =?us-ascii?Q?vA9wvbEth8Udny6A/uNWHLO1sjlwejMZHhW+k1q/6jjpPkzvTMdCEq3SkhJj?=
 =?us-ascii?Q?UD8UCUDPApOU2lOkYWGyzokTM5rPn3LgEKg3Fzx3f3e5P9eeZmhmF0oa6tzh?=
 =?us-ascii?Q?gkhNsY8QE5ItNhiN2V590w2PeFP+dNmhACWuqo9Dr6sZvWVWNI1HNLwqYe+v?=
 =?us-ascii?Q?xg/zp2ERvsvxOxxH8FdB8AGx2aPBCQJqvxSagcFd5cjAwBOWQ2g8uczajqOM?=
 =?us-ascii?Q?nunmTXTY86fzA2dLHzgVwAmv8ABgQlobHMA1ieM1nzB8t1RIlRUlao1cL4R+?=
 =?us-ascii?Q?hQ9vxvCqx6EGbmdrwTWYZKkBRqR0w4jWk2kUuGJNGF63Ie5fRkVpcywrauhY?=
 =?us-ascii?Q?tcyep0wytNjRrDulQoBAZ8AXUoEhl9aexTtNnGnIup0coNYvdR3DktRJLeo9?=
 =?us-ascii?Q?iT+nImYLBoM8yke0umppyjcIyBqEwblrLdKlKTL0DR9kBD2jMc3h+muCBqzy?=
 =?us-ascii?Q?l4bPK65RocWPLx9E3zMYKd7FyeCvBc+Agm72Mss/+PgwuVv4UHoFUE/TIkDO?=
 =?us-ascii?Q?92KIPifVQtOR1aPqkSB6/NXlEJahZM8mPKMaN8hurKcexLSDN2cne9WtwMTI?=
 =?us-ascii?Q?pzn08iUyEkTcyG3pC5BJWY4GFk90HRRohrhD99poKgyUJ5s1sgg/xItM59Q0?=
 =?us-ascii?Q?r9LkXhfbAMiGN4rWoXeWSqBSmJIZtdtr0mY2CxPr+TMh3BsFfk+kYPE3dOuA?=
 =?us-ascii?Q?8X+uNr7SZWDTMh4As6Fpr05yo25Hu3nDRVj4t3ucir6mBt67fjVCmAAtzz04?=
 =?us-ascii?Q?0vS/vhdeZlKf2otkiiVssgkHIlIE8I117wlgId2TGVD2+hXWLu/iN1i4Xy6Z?=
 =?us-ascii?Q?mCh0/aEocSVtLoU7+kPUAku2K81P8b39DwWLqFCC6tX6FU17fiRrHa8Ago2G?=
 =?us-ascii?Q?N4c8kC/oOubTt3MqWxuEp1Hyo/gn1SC/2Pdu3OsJlb6xFewAxxhcE2o40Nr3?=
 =?us-ascii?Q?iX/aNY/BW4S6wJEpx7c7Vv89kxp464XhR60m8dghGA8GyfnVa4VpN+hkkKbE?=
 =?us-ascii?Q?xN7+OfdZS9svj9iRK4az8IxsAf1aRWqyQwwuxqE1jdE/XiKO+tCslgyLJJxo?=
 =?us-ascii?Q?zknK7KqIKZLlDxtJC7Xc6SYnhFW0PiMl7aomxzgPrjt/f3mAeFJYyS1OWaeW?=
 =?us-ascii?Q?aFYbDNqoBVufiHfEFl63zNHvSOWUbhC7rkIud2kbWpiUqzAqI7kapb29yb6W?=
 =?us-ascii?Q?Akfs/nAZnffSSxrKvTy67VOLvQg8NNYvVQpAL5Ue/tQ4ZpRu5qgOYzXeXS7V?=
 =?us-ascii?Q?sHqhJj/qWa0Kx1X+x078vNCdjmSJ6TdIis4lrDSpx0EV7h78WkD5WNcr9w?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 11:53:22.6300
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b50d947-7b9e-4a30-1b34-08ddf129cf1b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4493

Hi,

This series is a follow-up to a prior patch to remove ACPI CPU hotplug AML from
PVH guests. Between now and then the working assumption for the corruption has
been identified to be more general than PVH. This series rewords the commit
message for that patch (which became patch 2 in this series), and includes a
patch 1 that prevents AML overflowing the MADT during execution of _GPE.

More details of the bug in patch1's commit message.

pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2034006083
original patch: https://lore.kernel.org/xen-devel/20250910144921.29048-1-alejandro.garciavallejo@amd.com/

Alejandro Vallejo (2):
  libacpi: Prevent CPU hotplug AML from corrupting memory
  libacpi: Remove CPU hotplug and GPE handling from PVH DSDTs

 tools/libacpi/mk_dsdt.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)


base-commit: aad6ebf0596f7eda6ea709f1c293ef5911ae8938
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:53:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:53:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120054.1465155 (Exim 4.92)
	(envelope-from )
	id 1uwfrp-0001Yz-SJ; Thu, 11 Sep 2025 11:53:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120054.1465155; Thu, 11 Sep 2025 11:53:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwfrp-0001Ys-P4; Thu, 11 Sep 2025 11:53:33 +0000
Received: by outflank-mailman (input) for mailman id 1120054;
 Thu, 11 Sep 2025 11:53: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 1uwfrn-0001L8-RG
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:53:31 +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 eecf0432-8f05-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 13:53:30 +0200 (CEST)
Received: from DS7PR03CA0192.namprd03.prod.outlook.com (2603:10b6:5:3b6::17)
 by BL1PR12MB5828.namprd12.prod.outlook.com (2603:10b6:208:397::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 11:53:24 +0000
Received: from DS2PEPF0000343F.namprd02.prod.outlook.com
 (2603:10b6:5:3b6:cafe::3d) by DS7PR03CA0192.outlook.office365.com
 (2603:10b6:5:3b6::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Thu,
 11 Sep 2025 11:53:24 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF0000343F.mail.protection.outlook.com (10.167.18.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 11:53:24 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 04:53:22 -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: eecf0432-8f05-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Xp7qzRQlLvcftuLGSkY3eT37iOoRkWkWm7K08Ocuu6QZYcY1CaaI0Ic4xKPNlu5GI0B9I1VtvSpj39SnAtz2Dk/NGHDR1zyheES2WeHPA2SguVYeMIGJ9h9Z2jIIKWKHtgzfy3zP9dHIQqu01v5nAmkUEasGmmrq6DBqOSsW+n0LZ8Xsa07z6ak1yfxXlwhgYkuITuRUOPN8yKzfUvdx32cumdOJRBBAfsHedaXMEFiUDDFQsGGPJAragjCI0ESYLiWK+WWsMT/hE4qJu2uSkTaq9TBICDM9TRyGRQ9/amOBQ+UYZnnMsr6M0t/IgJGI6/G4b7VYNm+OKkqUpElZGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zkDMZW5IAo1eBCGEcen5eEzeBVV+iCXu9QaTMqlJeYQ=;
 b=GbVoN3eWlH5RMTmVxxyk8zCFxVSDvEC0iuBVJ0pNJiJGXUDcYlVjS0kInnhkDiz+rhnCgGD6FJDQ8Jli3lFJjmV8pEz5yroRAeVQmKahIhfAK67nHd3SaBIQIVS/3T6fJ5eUBTO6ZCxap29baaU8ULx/qgR6ftaMNxVTOpQ5Phv6Fx+qP/HJm865+nruZA+DEzj2PIag2oFgebUBdUdGBtGWj2c2BEKvCHy0ZblciUQv98iA2EVVOoD7Pkr8VJYjbLjRrsnk3Zu9QYMtHdccAgx2maWQhvkeHup8I9OTHfGIEK7HLKG70tkI28VRsB8bbnNz1mXHwL5lIar8zjjTQA==
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=zkDMZW5IAo1eBCGEcen5eEzeBVV+iCXu9QaTMqlJeYQ=;
 b=h88Vlp/b9AqrdvljtiNUifMRsKYUNu/9aEU8MTc4ZpbyCZ0QRASaYoDKUyYEwZCzmo9l3BkpC2tf9wxrQ57FNf7XFvQUVMxV5xsG03x3uqZuEnYMMfcFwnSHpE2D2dygmLdDlRm2j1oLPedpq39Lli0X7Q7WsTiare+k43lwamE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD , "Grygorii
 Strashko" 
Subject: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting memory
Date: Thu, 11 Sep 2025 13:53:02 +0200
Message-ID: <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343F:EE_|BL1PR12MB5828:EE_
X-MS-Office365-Filtering-Correlation-Id: 8a345029-02ba-45fe-be20-08ddf129d049
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?7i+FXEWLKV/oQn9sb+cV4wh4zsbuVkrYSabzXjjuDQXYF6f+1yFJqNnShgrP?=
 =?us-ascii?Q?lXw5RzPF7iw/W3PghY49cIHVICGKoCk/LWF2ERspt1mtcnClUZvYoLnu+K1Y?=
 =?us-ascii?Q?Gg2Xar3MyJX9+QQURGWO3n+MrGEjTJrT3fSe1WEREfLqVroHJ8fHYntdQu/q?=
 =?us-ascii?Q?uPJPXXi1VgCH2eUW4uXwnKW4K4+N5rEybowOxI//t80cecU6gD0zwE7Y7ruH?=
 =?us-ascii?Q?ffsMD7uVHXjoSPqyPtHIVV3gNqi+U4qaZ0jE3iU5Js9crynUOS5VQrDzGN0D?=
 =?us-ascii?Q?aiSb3C90gxQ0k//3ioieywT67aKv5sXG8mJogbY8nwhbcp5luHOAEaeV2BnN?=
 =?us-ascii?Q?uWVTX+eH/evn+03JouQ+fhJMThcD0bS/Tmb9vxy7g+6sK07o7WmwuoPlmcpX?=
 =?us-ascii?Q?pPDYKPOhlQz8VCyFiwqeSC/SgSkmzIE66pHNSXOkasK1v4R75F3RwiS9EApU?=
 =?us-ascii?Q?0VFf+ls6wWhcc7Nnq+jsQshHFaoq/sag7p8q5SmO6d/HYggAaoQ9MCKielNZ?=
 =?us-ascii?Q?DK3h9YmlS6d7RHkhSGn+u3NhhT0O8aiK+uLVqG8yflN3oXhA7rjB2GTbcNab?=
 =?us-ascii?Q?FHRNxnXobel+SDXgnqxfQ0WKhq5MB+0pklNs1W10hl/o20oOjn2LZ7yb2z9H?=
 =?us-ascii?Q?aMChC2M3Ai2qnevg1a+nzNgRMKbXOnpa2B/Dz67BlEKJ4AY7a0YYs+Vuwtjg?=
 =?us-ascii?Q?pYGQ5HfcDnAlIt4hZSFvYMPmW8ig40hIKEBqHWL894//DrqWNQlOS+EMa9dC?=
 =?us-ascii?Q?jj8NSMbEQ2eRMt1IHMtkq2FUjdqynD0foI0mJ03UUv8koBgiTCHT/msZ8quP?=
 =?us-ascii?Q?BXwFdwEIKrFeDOwEAiXR1hawRy5U+OjfnaYEijjMuIX+51bb4pSkyGSQB3Oz?=
 =?us-ascii?Q?IemKXASoRZpUtWc9jit1RCUrf6o9m17VA95XCKfII6pHb6P8UkLrQ514H4fu?=
 =?us-ascii?Q?lt5YNeuaKKPV6kGiwU8Km5BevtI01yIZrYiNPYGrurtmQTx0nyfJrnvYp/QK?=
 =?us-ascii?Q?zSU3v15Re1rrihXLBXspE1CZRnPc5bUysXcpx+VHdkYHrlP4s2Rz/9eCwRhX?=
 =?us-ascii?Q?nDGZc1IliFRnQCLqYBh3IBO0GQby7fJ/kngksEa3Smf7XFojCrG15xKVZ2Iy?=
 =?us-ascii?Q?vh+teu7VWgYtXQmF3dQOXKf7RS/AHqPNct21dljfqftVadm3Op6qm3oKv/zI?=
 =?us-ascii?Q?RMtKYbltt80mKHwxvuu0QMmYzSu1G1y0shpRLZ37QEvrtUEyo3NaZWh5wMZi?=
 =?us-ascii?Q?DA0gS7SdytzPisiSR+Lyv94yUNFqr6WNHm4f9KBQ350ecc9nUeSsVLtRnueb?=
 =?us-ascii?Q?OXDyufH0blRh8pQfr5olFpatz9vq9l2ymEoL2nJeBsvSTGPsHUWrZp28+DQK?=
 =?us-ascii?Q?lOiTU241Oj3XInoPql+slqcch1ECye0zlZHpSsATMxf1OghVgsxHr2FmiKnA?=
 =?us-ascii?Q?+Bjivn7VGRNDEANYfHugVQm86oDBCemTZYYh74ecrZfsxVL5O1h4kIAUmjpT?=
 =?us-ascii?Q?Gub95bC9/pdRt5mMTYV5tsP9RTKBPAaGp5mr?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 11:53:24.6123
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a345029-02ba-45fe-be20-08ddf129d049
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5828

CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
by the device model. The GPE handler checks this and compares it against
the "online" flag on each MADT LAPIC entry, setting the flag to its
related bit in the bitmap and adjusting the table's checksum.

The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
reaches 128, even if that overflows the MADT into some other (hopefully
mapped) memory. The reading isn't as problematic as the writing though.

If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
then the bit where the "online" flag would be is flipped, thus
corrupting that memory. And the MADT checksum gets adjusted for a flip
that happened outside its range. It's all terrible.

Note that this corruption happens regardless of the device-model being
present or not, because even if the bitmap holds 0s, the overflowed
memory might not at the bits corresponding to the "online" flag.

This patch adjusts the DSDT so entries >=NCPUS are skipped.

Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
Reported-by: Grygorii Strashko 
Signed-off-by: Alejandro Vallejo 
---
Half RFC. Not thoroughly untested. Pipeline is green, but none of this is tested
there.

v2:
  * New patch with the general fix for HVM too. Turns out the correction
    logic was buggy after all.
---
 tools/libacpi/mk_dsdt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 8ac4f9d0b4..06a229e2e9 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -239,7 +239,8 @@ int main(int argc, char **argv)
         /* Extract current CPU's status: 0=offline; 1=online. */
         stmt("And", "Local1, 1, Local2");
         /* Check if status is up-to-date in the relevant MADT LAPIC entry... */
-        push_block("If", "LNotEqual(Local2, \\_SB.PR%02X.FLG)", cpu);
+        push_block("If", "And(LLess(%d, NCPU), LNotEqual(Local2, \\_SB.PR%02X.FLG))",
+                   cpu, cpu);
         /* ...If not, update it and the MADT checksum, and notify OSPM. */
         stmt("Store", "Local2, \\_SB.PR%02X.FLG", cpu);
         push_block("If", "LEqual(Local2, 1)");
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 11:58:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 11:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120092.1465174 (Exim 4.92)
	(envelope-from )
	id 1uwfwv-0003Cw-Nm; Thu, 11 Sep 2025 11:58:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120092.1465174; Thu, 11 Sep 2025 11:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwfwv-0003Cp-Kv; Thu, 11 Sep 2025 11:58:49 +0000
Received: by outflank-mailman (input) for mailman id 1120092;
 Thu, 11 Sep 2025 11:58: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 1uwfwv-0003Cj-30
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 11:58:49 +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 aca06238-8f06-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 13:58:47 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b042eb09948so128806166b.3
 for ; Thu, 11 Sep 2025 04: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
 a640c23a62f3a-b07b33478e4sm114444966b.96.2025.09.11.04.58.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 04: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: aca06238-8f06-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757591927; x=1758196727; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ypJXWGy4zGKZEm6L6+M44/YFGkPLMs03nR2P4e+tGzU=;
        b=CmClvW6HNeUoMvTt1nTA/Hl+ZbXrJTd3mySiFm6OQCPkwMwiB3XboieLUMsv1T6Si5
         quGnWcwzJdqYurfcVYbObzg5+AAN+xCd6zSQ3f0pwaXFFYCXtARt5U+IpaILTat1l2Aa
         HFWEsP5MsXPzg/pBkRYDkkPXfYeRCs4c1Tv0fClMrEe/vTsQAnOjoKEtkImaxYhxV1YE
         jwvqOVTcLQ6yi/XLX6ju3ChImbyxNZ3BqnslFKQPpEGn1VfiFa10MCWmjfnJAnUK+PfA
         wF35WW3jgRCW5OOdEk9qUn2BQnAMzFLKsdWxLTb08eGu3hgL2y4fol/NTPhtxqBFdvPF
         mcCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757591927; x=1758196727;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ypJXWGy4zGKZEm6L6+M44/YFGkPLMs03nR2P4e+tGzU=;
        b=BWwlDV3Nn9zeKhxDlJSKy/JjKT+oqj/7l3spi+AnClng+lfBdV9O5IjNw4ALOh4xYF
         N3ZO6KFwfLyVuNzh8Crg+RC26sgCGOCfrcD/r4oqCBqscDGp2Iug5dtVwLKq1v5MrZf2
         WIA+j7vhQR2FCj3oANRw8tZmM5k9d/VwISi0CD/of3gYmVvuwgFOTsxH3Pt0tHVsusCV
         DFpM2/eqYXkXV/ttQHocTXHhfxlpQsEwqyHUPVVre5r5xQETweuimfmB/nHkIlSq9Qbu
         8H4S6uasQafQPtUjuOzmfMt0h2nL6G+aN9+pjYtNZ+AfziR4KfahjQaIk4i3XaS2vXAl
         sflg==
X-Forwarded-Encrypted: i=1; AJvYcCWkBbAlaqFAIg+rE/P3KQgqDN6mbMpqRx7O5bjY1KPWaKnSnbHUd2O92Wt4bMs2ywh7+JVgRlv7fD8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdykQxCzNOnL+OC2PiIjqhTyvcNZxBLrUCZp8m4b/eDyJDYfQb
	WEtPiQzobG+3jCx8thVS5mGypLMdexdSkscjuBVMwNGAaIRIe7c66L8oCaNvIzFjeQ==
X-Gm-Gg: ASbGncsMwb37yubMX7PQalH0+QRgSUHrgq0Fpwmb4rPZcGhrxYnhF4Pj3sWb+5ZKuk/
	e8TGshgbTMwDyubarB5JBGLQV3cZGU9NTKtYUVifUML8Rl+jo30TrOJX9PXvzNxxhw4GSy6kSxI
	deDiE/de66uGze5G9WFXGqCppKwL78NA8X1hZTI7D/5cX5bUWQWHdMU65L9dl5zvUhsu/k0g00h
	kCmU+dp71cZRMMPamrvYsTow1N4J4Tv6+yzn8zOaKVzBh3gVroJSYADGQc9Oibn8mtQaN76I4Qb
	+GthLtO0HtmCC447KIWYObsIWmp/s5k4U++W7NIlNosmnEeTsyredVpGXkmHHyG+DOl8urhOrxo
	ai8s9Et65K24XvR+lti3Pi49rOPZvbBZmqQnscRDBhIeD1D7BATXXwMYYHw+PvNcyIuodaxKlMp
	JWWqwYoKPYgJgM/Ozquw==
X-Google-Smtp-Source: AGHT+IFCDzCthNPJUSi2K9wmpOK9kYw8IA/ZAdccooK858tHScEc6r6kKI4Z2o9VyagOar30EN2oBQ==
X-Received: by 2002:a17:907:e98b:b0:afe:d62a:f038 with SMTP id a640c23a62f3a-b04b13fe73bmr1673487666b.8.1757591927225;
        Thu, 11 Sep 2025 04:58:47 -0700 (PDT)
Message-ID: <0af66ec5-a53e-4f09-96bd-3cedb7419006@suse.com>
Date: Thu, 11 Sep 2025 13:58:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/26] xen/domctl: wrap iommu-related domctl op with
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Volodymyr Babchuk ,
 Rahul Singh , xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-21-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Function iommu_do_domctl() is the main entry for all iommu-related domctl-op,
> and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
> Tracking its calling chain, the following functions shall all be wrapped
> with CONFIG_MGMT_HYPERCALLS:
> - iommu_do_pci_domctl
>   - iommu_get_device_group
>     - amd_iommu_group_id/intel_iommu_group_id
>   - device_assigned
>   - assign_device
>     - intel_iommu_assign_device/amd_iommu_assign_device
>   - deassign_device
>     - reassign_device_ownership/reassign_device
> - iommu_do_dt_domctl
>   - iommu_deassign_dt_device
>     - arm_smmu_reassign_dev/arm_smmu_reassign_dev
>     - ipmmu_reassign_dev
>       - ipmmu_deassign_dev
>         - ipmmu_detach_dev
>   - dt_find_node_by_gpath
> Wrap XEN_DOMCTL_assign_device{test_assign_device,deassign_device,
> get_device_group}-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when introducing CONFIG_MGMT_HYPERCALLS on the whole
> domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

Apart from all of the above another aspect becomes apparent here: Some code is
called at boot time only once management hypercalls are compiled out. Such
code should then move to .init.text, so we may need to gain something like
__init_or_mgmt. Imo that would want dealing with right here, but I can imagine
opinions to differ on this.

Furthermore, while looking around, I noticed that there's dt_overlay_sysctl(),
entirely unguarded despite the earlier sysctl series. Yet if that work (and
Misra checking) assumed OVERLAY_DTB=n, then there's iommu_remove_dt_device()
which is only used when OVERLAY_DTB=y.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 12:03:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 12:03:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120118.1465184 (Exim 4.92)
	(envelope-from )
	id 1uwg1R-0004q9-Bb; Thu, 11 Sep 2025 12:03:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120118.1465184; Thu, 11 Sep 2025 12: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 1uwg1R-0004q2-92; Thu, 11 Sep 2025 12:03:29 +0000
Received: by outflank-mailman (input) for mailman id 1120118;
 Thu, 11 Sep 2025 12:03: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 1uwg1P-0004ps-UX
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 12:03:27 +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 530b73de-8f07-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 14:03:27 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-45cb6428c46so8086835e9.1
 for ; Thu, 11 Sep 2025 05:03:27 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e016b5a16sm24440585e9.12.2025.09.11.05.03.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 05:03: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: 530b73de-8f07-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757592206; x=1758197006; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TNq70eBJGjUku1kl6S4ZWlnYQIdhEGvIwf2HGXsVXBA=;
        b=lwzZatexubpZxhfPhi9NhC3IWQs9fYSOhxaVgJNHsyE4Zo9yCARvXWkSp8lY67Kok6
         mJDsKD4mGrAvFDNgiDMfmJJNFcozpjaFBEwFRdqb1dR7nKFbyIBLkfeeO75MGAAUPwHk
         Y5rLd9zZuXTByizw8X/lFxGe/JFzYdE6wNsXU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757592206; x=1758197006;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TNq70eBJGjUku1kl6S4ZWlnYQIdhEGvIwf2HGXsVXBA=;
        b=Jxic/rmoZzaV0QgUuy1Bwzx92qdOWNiCqMZB6lFU9kCvu4BnNlG8iQEpHO/ep7GJQO
         Ant/nK97gto2faUmQXAN+/qLRkd6brmsumw8e7lh+kg/ArvdgEFCfZHBC/qkgSOBMhPV
         b+aSHRkfQ1JrPnRbhU+wJM7/6i73TxLBgxLLl32TroEdXm8my1YQweTZ7bbtZHigjK9l
         0ObgeMM+f99PevnqRzypUTh9KGg7KVlHkRlkc0UFNnmAv9AD9hgqc0NIki81XZjiN4yy
         R8egPUecfYe0qAvIbZR+nUDw3SVmspfAFUWDfhUqjKrPdQ5ID2VKBBElDbtqXgtyzC+M
         XVrw==
X-Forwarded-Encrypted: i=1; AJvYcCWOMP84A+u/T3gNmqwfYOz67FVTO6yj0RE3DeGpu/C5Eiyf2ce24U/1w69UtJ2GPndUgF6pLXXBeC4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytKmP6Pru9w1fzEi9i+Y5rBRHjAtfJ021VsS06BPqCALil1xHb
	Bwy1jZm7H/ijflCVHnQgFsSxn4ZFLrbM19IdhjXRn751DU3aLgn1/DcYpzI0vwiQ7gw=
X-Gm-Gg: ASbGnctUeWH1If2qJTMI8CliME38pzGP6mgN68tNZL7ii4WbIequTVt9lsqJflAoCZ5
	1dfvVNYnanUIpO9J0UK6hZEAgUIti3LsblqDTXkhveo3L7N/ViTNusEm2jbfoXZnf93lLUJrHUq
	1iuE2JwnM0IzFh/f3rHHvKxFbRq9UUUm/Z5jQC6BN6JDJDsKAtJHLp9EjceL/jtiYTx7ShGmwIf
	Rqa48+x8KMGbawEerEqIXESDQOg1P2wXKYaXKiyVvPGWeYfqgrqw6ZtgT++wVeZoxKxGFLhrctH
	++bJb4kwzxOfpAcfROhc57qRJAIsQjyi9EA2unH1h2LXZUveqhpm9n4PSnULg14dLu7ryCfk6R9
	Kf1lmC/8F3V0rWWTzJBEC719350gzuc3u2FSgHy5HrrEsUVuBH92RGXxd9b31dW5yOTs/
X-Google-Smtp-Source: AGHT+IEWu4l3ou+sTPuGxSUbLYD3F14++0HjkAt2KSBW6zTA8F8AfQcygaIzwYmANYx07z0KYf4knA==
X-Received: by 2002:a05:600c:6305:b0:45d:5c71:76a9 with SMTP id 5b1f17b1804b1-45ddded7652mr193370495e9.24.1757592206400;
        Thu, 11 Sep 2025 05:03:26 -0700 (PDT)
Message-ID: <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@citrix.com>
Date: Thu, 11 Sep 2025 13:03:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Alejandro Vallejo ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
 Anthony PERARD ,
 Grygorii Strashko 
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@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: <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
> by the device model. The GPE handler checks this and compares it against
> the "online" flag on each MADT LAPIC entry, setting the flag to its
> related bit in the bitmap and adjusting the table's checksum.
>
> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
> reaches 128, even if that overflows the MADT into some other (hopefully
> mapped) memory. The reading isn't as problematic as the writing though.
>
> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
> then the bit where the "online" flag would be is flipped, thus
> corrupting that memory. And the MADT checksum gets adjusted for a flip
> that happened outside its range. It's all terrible.
>
> Note that this corruption happens regardless of the device-model being
> present or not, because even if the bitmap holds 0s, the overflowed
> memory might not at the bits corresponding to the "online" flag.
>
> This patch adjusts the DSDT so entries >=NCPUS are skipped.
>
> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
> Reported-by: Grygorii Strashko 
> Signed-off-by: Alejandro Vallejo 
> ---
> Half RFC. Not thoroughly untested. Pipeline is green, but none of this is tested
> there.
>
> v2:
>   * New patch with the general fix for HVM too. Turns out the correction
>     logic was buggy after all.

Hmm, this does sound rather more serious.  I have a nagging feeling that
until recently we always wrote 128 MADT entries.

So, while this looks like a good fix, I think we might want a second
Fixes tag.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 12:05:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 12:05:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120129.1465194 (Exim 4.92)
	(envelope-from )
	id 1uwg3l-0005N3-NC; Thu, 11 Sep 2025 12:05:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120129.1465194; Thu, 11 Sep 2025 12: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 1uwg3l-0005Mw-KJ; Thu, 11 Sep 2025 12:05:53 +0000
Received: by outflank-mailman (input) for mailman id 1120129;
 Thu, 11 Sep 2025 12: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 1uwg3k-0005Mq-Jr
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 12:05:52 +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 a880d0bd-8f07-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 14:05:50 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-6228de281baso1058906a12.1
 for ; Thu, 11 Sep 2025 05:05: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
 4fb4d7f45d1cf-62ec33f57dbsm1081546a12.25.2025.09.11.05.05.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 05:05: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: a880d0bd-8f07-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757592350; x=1758197150; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zjTj9jIzhm4doUGKBlncqulQ5QU6mxkYS8CWuf3Huk0=;
        b=H8+uMrsP7s/nJhi99vd0eFTHryQfkEqF8RITj2dFhP9eBvAhK7Q5vNwLf1bKnofgJD
         gdrizSO2rbmuCf2VNwMSkLLkfFSVlhIzTetWK+bWjx2xZCIAik0WE+s6PpQyz30x83iQ
         pRx4jYGUxaS4QkyOhNjJgQlileO07uV7X18YznbuSt/OmbEiOm5A/FESvZte4n0L6j22
         9/LUcWrU0fOknx9s9AtWhvmCROExeYcmlOn0JOyOnV5a44rF4vg+5hwJTBK2LTabbvVW
         VREHQw/7aWUmiU9/r+nUzSeV2UhrZBEDnrnnco4V/aHPoZ3Qz0MLRz/tNBXTMr4H1QjO
         SOYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757592350; x=1758197150;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zjTj9jIzhm4doUGKBlncqulQ5QU6mxkYS8CWuf3Huk0=;
        b=LM2ipocQjS4FOD5JjhOuqXFmGh1hA6Ns3DVItH0e6pJFlBUxJF+DjC4IvpQY9ky8HK
         Pe0hN8+KiiTWb56k7AM+KfaVgn6MyPQDQWlss+eQ50hNWH1Br5Lqve4O7kK4ArhOHih1
         /4O+Uh1Pxd78tPdm26lcjBV93FHw5hN+/bbyCWxLkgNFklZMIWLvIY3OuJcpFH/wksQ6
         bCXeqbHj2OvQnlSJ7XcCSSZ8KPFhMIWaNXPaOcgdrXSSO/oS/vNTM1FO6/y3HzMOuu45
         CkA9pGnZ5mwUWPJrl1sXpgwouO1+RQ9Sv6AQQfLJNu2A/oLz76RqUnvLs7zW2W/7xyGG
         bzDg==
X-Forwarded-Encrypted: i=1; AJvYcCXCB4i7TdPuQ2jggU+6QRGmQU+XbYGmo12IBe3l9z9pJhtSbjWytRg+rETxQaHcaylVfacP4K9sRBw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMPNtW+XLOHoXu6lHvIpj6rIrZOZrHf+kNLGp+D+XUFmGPA3XN
	DOd1oX15GPH1bW0YB8CQcl6DUkr6rukGLfKZfSY+eW0TsrYCq4hNBBsXGlG4TOwB/g==
X-Gm-Gg: ASbGncsQJ2ft5tl5+/SiKyUqjjolZ7kYIZOBqPhz4PL1KvxxzfaKFddBsgAPGHvS9Eh
	X0oDM8FqIDiP+Q5SFV9Mnv+esFwgJJlkV2fzTJk6GXMvAGq81uwCRiTtcb14cPdb0e7A9yU/XF+
	iLUSPRDnWSZnVPe/BCP7Gi6swiNwnlGfh8yXNOFG17Dby4jy8RUIWAR0Z3pLrfxNOhuxICJDk3V
	HVP885Y8f4lTxlzMo14JKKtYXjAlxwR16wGdDuU/KBb5nzOb2qKhx1x2JBolgcY+gkuv55utOCM
	WIZRrSNMXFrx1PwypahRoc1YvMDeNZBw/0lzvnP+PtoHgDatNyXkB/40zh1Gyxv2DXT1wEzV1rF
	03ARLufMRIBl6Wg6myVJfXdNmUAviOkm/D7FlbUJZmpeWBCbq7Yvt5NwrbM64Gz5tmoV99WdmKP
	CUxkpIZ0nhdomwyKtyqg==
X-Google-Smtp-Source: AGHT+IGbaXBYENG3+R2LUsNPmoKGplewkWHGPaIaLjJAFNJg1wvChk0NIsFDsudME+vsJ2Ax9/Dy9A==
X-Received: by 2002:a05:6402:90b:b0:620:27e5:10fb with SMTP id 4fb4d7f45d1cf-62377109d22mr17851714a12.19.1757592349808;
        Thu, 11 Sep 2025 05:05:49 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 14:05:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 21/26] xen/xsm: wrap xsm-iommu-related functions with
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: ray.huang@amd.com, "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-22-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: <20250910073827.3622177-22-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> The following functions are xsm-related and only invoked under iommu-related
> domctl-op and shall all be wrapped with CONFIG_MGMT_HYPERCALLS:
> - xsm_get_device_group
> - xsm_assign_device
> - xsm_deassign_device
> - xsm_assign_dtdevice
> - xsm_deassign_dtdevice
> 
> Signed-off-by: Penny Zheng 

First - aren't you dealing with unreachable code issues here that the earlier
patch introduced? I.e. would both patches need folding.

Then same question again as to xsm/dummy.h.

> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -123,13 +123,13 @@ struct xsm_ops {
>      int (*pci_config_permission)(struct domain *d, uint32_t machine_bdf,
>                                   uint16_t start, uint16_t end, uint8_t access);
>  
> -#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
> +#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI) && defined(CONFIG_MGMT_HYPERCALLS)

Here and elsewhere below you're introducing overly long lines. This may be
helped some by having

#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_MGMT_HYPERCALLS)
#ifdef CONFIG_HAS_PCI
...

>      int (*get_device_group)(uint32_t machine_bdf);
>      int (*assign_device)(struct domain *d, uint32_t machine_bdf);
>      int (*deassign_device)(struct domain *d, uint32_t machine_bdf);
>  #endif
>  
> -#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
> +#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY) && defined(CONFIG_MGMT_HYPERCALLS)

#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY

>      int (*assign_dtdevice)(struct domain *d, const char *dtpath);
>      int (*deassign_dtdevice)(struct domain *d, const char *dtpath);
>  #endif

And a double #endif here (and then similarly elsewhere).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 12:07:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 12:07:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120141.1465205 (Exim 4.92)
	(envelope-from )
	id 1uwg5V-0005vh-2B; Thu, 11 Sep 2025 12:07:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120141.1465205; Thu, 11 Sep 2025 12: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 1uwg5U-0005va-Ud; Thu, 11 Sep 2025 12:07:40 +0000
Received: by outflank-mailman (input) for mailman id 1120141;
 Thu, 11 Sep 2025 12: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 1uwg5T-0005vU-88
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 12:07:39 +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 e7f8a992-8f07-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 14:07:38 +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 58B84fHU032047;
 Thu, 11 Sep 2025 12:06:56 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490cffmge8-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 11 Sep 2025 12:06:56 +0000 (GMT)
Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 58BButst022969;
 Thu, 11 Sep 2025 12:06:55 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 490cffmge1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 11 Sep 2025 12:06:55 +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 58B99ZNi011435;
 Thu, 11 Sep 2025 12:06:54 GMT
Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228])
 by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 490y9unx8m-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 11 Sep 2025 12:06:54 +0000
Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com
 [10.20.54.100])
 by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 58BC6qp621103260
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 11 Sep 2025 12:06:52 GMT
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 592C42004B;
 Thu, 11 Sep 2025 12:06:52 +0000 (GMT)
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 95E1D20040;
 Thu, 11 Sep 2025 12:06:51 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 11 Sep 2025 12:06:51 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7f8a992-8f07-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=c30ZQnsvAEyuVkRVamQoGQaRen0nYI
	Ra+BA7jFqu78U=; b=k8qq71z07GrReGd9S9mOiL2kfz2BW5pit9iGHWyQ501+3o
	18SrSVgXyKIh3fgbTocFTOqLMtqSFK4cxX7BIxE3tS22XZO0MuuzR1offUBCNMnq
	oKDIaYOBM6OqV/8/2nb5TYMMtbfty7TIxuJR1UwI7ijudG7hBz2n8mEO1/1JtIWQ
	dCG50x7Is5mNMQX/2OgEzJRaOS4B3WAK5BbVoavZQgJ0vMUStU+M4xrwJU761IBV
	72RsuHX8BmU9AXx/ZC8PQ4TAp5bfKtZi3PWfc0gEnh3wsk+FWngrjfyj6wXqFlUw
	ta9dp/wt1kSFBm9tnzdcdwRJffzZgn8TZgXdZhNg==
Date: Thu, 11 Sep 2025 14:06:50 +0200
From: Alexander Gordeev 
To: Kevin Brodsky 
Cc: David Hildenbrand , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        Mark Rutland 
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: <80be36e5-d6e1-4b37-a1ca-47e92ac21b02-agordeev@linux.ibm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 
 <250835cd-f07a-4b8a-bc01-ace24b407efc@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <250835cd-f07a-4b8a-bc01-ace24b407efc@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: EOlye06iv3wrpFZ8EV5hsz2FcaKHpkNR
X-Proofpoint-GUID: 51K6fRL5QpJCzFIQhT_Qazz7bChQjXpl
X-Authority-Analysis: v=2.4 cv=EYDIQOmC c=1 sm=1 tr=0 ts=68c2bb60 cx=c_pps
 a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8
 a=jRhVRVM2bwpbWWX_RR8A:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDAyMCBTYWx0ZWRfX8pGJfFgtntNW
 /kOIUEwDJMICGimD1/ufjSKSVIfmo3TNK7+Fxsinl9Egq+oGXoolAwIU93iuesvkQ3s13VVlzhh
 JIgGdj6U9PokjpkHg4ykDpABkraxfLb3HERwg3941FM1HXB2esU2ebixaknpbywBxWh5hGHimsp
 ci9R67AshxoJpy340lLj5ssEfi6eKhyjCh5p8fZq/k83GFNAv5ZYjhl/Hqc7I+sNgjVlWR40LHM
 kZLurS1M60tPSFVJMaBaPvAXWRbQAESVilgI8Vf2JWna8t2s571X/x3Ahb2bFBInNwL1PkLtgz0
 aizOmw9YsKcqSGhvZ6E05+Xu1Xlt46nNfGetQx37HOL9xVINKsAa7u5yRb/jAsXOIQWyZmkfM1v
 9y5BFajA
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-10_04,2025-09-11_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 impostorscore=0
 priorityscore=1501 phishscore=0 clxscore=1015 bulkscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509060020

On Wed, Sep 10, 2025 at 06:11:54PM +0200, Kevin Brodsky wrote:

Hi Kevin,

> On 09/09/2025 16:38, Alexander Gordeev wrote:
> >>>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
> >>>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
> >>>> want to use it - at least that is how I read the description above.
> >>>>
> >>>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
> >>>> that do not follow this pattern, and it looks as a problem to me.
> >> This discussion also made me realise that this is problematic, as the
> >> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
> >> convenience, not for generic code (where lazy_mmu_state_t should ideally
> >> be an opaque type as mentioned above). It almost feels like the kasan
> >> case deserves a different API, because this is not how enter() and
> >> leave() are meant to be used. This would mean quite a bit of churn
> >> though, so maybe just introduce another arch-defined value to pass to
> >> leave() for such a situation - for instance,
> >> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?
> > What about to adjust the semantics of apply_to_page_range() instead?
> >
> > It currently assumes any caller is fine with apply_to_pte_range() to
> > enter the lazy mode. By contrast, kasan_(de)populate_vmalloc_pte() are
> > not fine at all and must leave the lazy mode. That literally suggests
> > the original assumption is incorrect.
> >
> > We could change int apply_to_pte_range(..., bool create, ...) to e.g.
> > apply_to_pte_range(..., unsigned int flags, ...) and introduce a flag
> > that simply skips entering the lazy mmu mode.
> 
> This is pretty much what Ryan proposed [1r] some time ago, although for
> a different purpose (avoiding nesting). There wasn't much appetite for
> it then, but I agree that this would be a more logical way to go about it.
> 
> - Kevin
> 
> [1r]
> https://lore.kernel.org/all/20250530140446.2387131-4-ryan.roberts@arm.com/

May be I missing the point, but I read it as an opposition to the whole
series in general and to the way apply_to_pte_range() would be altered
in particular:

 static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 				     unsigned long addr, unsigned long end,
 				     pte_fn_t fn, void *data, bool create,
-				     pgtbl_mod_mask *mask)
+				     pgtbl_mod_mask *mask, bool lazy_mmu)

The idea of instructing apply_to_page_range() to skip the lazy mmu mode
was not countered. Quite opposite, Liam suggested exactly the same:


Could we do something like the pgtbl_mod_mask or zap_details and pass
through a struct or one unsigned int for create and lazy_mmu?

These wrappers are terrible for readability and annoying for argument
lists too.

Could we do something like the pgtbl_mod_mask or zap_details and pass
through a struct or one unsigned int for create and lazy_mmu?

At least we'd have better self-documenting code in the wrappers.. and if
we ever need a third boolean, we could avoid multiplying the wrappers
again.


Thanks!


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 12:13:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 12:13:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120175.1465215 (Exim 4.92)
	(envelope-from )
	id 1uwgAd-0007X4-Id; Thu, 11 Sep 2025 12:12:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120175.1465215; Thu, 11 Sep 2025 12:12: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 1uwgAd-0007Wx-Ex; Thu, 11 Sep 2025 12:12:59 +0000
Received: by outflank-mailman (input) for mailman id 1120175;
 Thu, 11 Sep 2025 12:12:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwgAb-0007Wr-Ex
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 12:12:57 +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 a5df3fb0-8f08-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 14:12:55 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-623720201fdso1319012a12.1
 for ; Thu, 11 Sep 2025 05:12:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b3333e81sm122410966b.94.2025.09.11.05.12.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 05:12: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: a5df3fb0-8f08-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757592775; x=1758197575; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CJ4QEto79CF5RB4ihut1AYj5dYYkPa+6FCfTnZrB3sQ=;
        b=fn0YLycd7wVyWgZ79gJ3bzVlu0zUkschKa4U/oE0hRI/q/ayAOGFLxfAqWC+yz/H91
         wXkFWD/5n3AzCv+g9d3kOjRtHlrqVgdGnw4zMa8lDhV/aHmu+3PR9YsrfvxS03ooxpEP
         qTGvW76zpP/AL5qky/BTi5mLDMaIf8UEBiOWcm3KS3iUZO5bCVINV3+kQqfuUXNsrn2c
         3R0AJlCrBNWRvWj4jbOa/RrbO4e527S60rby462HJp9KrqSIvxLa4ayms4ex5CDTIHIA
         4vmn0j9iQdJcFdICCBacOO312JEd4Mc80lVZleWpOkaauNAZeQ+wTrz4DN1ZTM3DaOjx
         ERgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757592775; x=1758197575;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CJ4QEto79CF5RB4ihut1AYj5dYYkPa+6FCfTnZrB3sQ=;
        b=M2CLnYW/KpakUKwx8tHsN/5yMhQD1RJE/740d5Pi7Ws2uru1SouAmMNeag29BbC7H0
         bOggw6fKpE/pgWKy8/uMc7eWjYIA7x2ruSwrTuH6T9F8+UUm/4UXWPTc9LiQx1WXsowo
         JHf52DIV8n8tPnrcKdPMHsDp/JB/CkOHyBunVDE1GzYyjMFZKAXxI06cVhu3/aG+nV0e
         4gEBiXK/qBlRh6NGzKOr5VuiKIYWLBW1Y+LmvhpKGtOavl3xjyGhpvUujAM0C34bnrq6
         imnTwJEnuMwRVXQOIKypsA6JVy4ywZJk3raKO8WCthAt/9lPypKyzGyRmmzfJ83EGigL
         G81Q==
X-Forwarded-Encrypted: i=1; AJvYcCWN0zdcemsp671q8+Ev6acPfxb5vKESlEwMPCBMShz3tywc+5+bJ3u0e+gV5FIxlREjzL9QY5u6OkI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYseypYm56/Er1R8mn0+kYKkri4tU3jAOQnZYgxKGWLv1BO/fe
	oSvZ8DtjU+rF+tvro4iEBbnENLFn41KOs4h8SuDCuYOBTOqBsjcbAz8AGeJbHq/QIQ==
X-Gm-Gg: ASbGncsSZvo7cEDTyImHmZmu+Hjqe4B4T9QrSKeEWvPdGQYiPkylt4LoB5AP5TbmLWR
	8YNscImQKY7NCW52zM9Jc1doTNtNcpDC6RnYrUoYu8kvEmRvsdGZwcpc2UpcHsOXu9B+rTYl1IW
	Biakq0UJTgyo09FMzJJA7P16MAbTznFgjFsn2/fob3MHimLj9WAwCKpI/+rJBZG7ezlWmgkuBlb
	z2xrx0emI5vthAuMm2w9hej4jr7ejHPIc8YQ8AWxT7QeGyHPP8XgqlaJj9Ne248pXHBHBmfEXxp
	6Y7nr4Ae+go/VkdkOFzGBdvPIHaW0PDqqaGv5PHsfFEoekZ0gfdDiP04leBxSrBX6YlNh/qMxJa
	vucb6joYSoczuwEhdwLQgQLbLiiFHb2CCpqAqJt/00erL9H9uSK0WRv8BIORCC3nNBQu0AYS3S9
	TFRQKPx2XzwPMybfUoTA==
X-Google-Smtp-Source: AGHT+IHR/BZHwwwmp9AKZklb5fedwLJhv7KbT4p14ukSCP6uv9LTJ10hW0kwZ1IljaBIfyDb8//mxQ==
X-Received: by 2002:a17:907:7290:b0:b04:32ff:5d3a with SMTP id a640c23a62f3a-b04b10081d8mr1861189066b.0.1757592774926;
        Thu, 11 Sep 2025 05:12:54 -0700 (PDT)
Message-ID: <1c67c451-9c52-46e4-89ee-419c6bc96e0e@suse.com>
Date: Thu, 11 Sep 2025 14:12:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 22/26] xen/domctl: wrap
 arch_{get,set}_paging_mempool_size() with CONFIG_MGMT_HYPERCALLS
To: Penny Zheng , xen-devel@lists.xenproject.org
Cc: ray.huang@amd.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-23-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: <20250910073827.3622177-23-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Arch-specific arch_{get,set}_paging_mempool_size() is responsible for
> XEN_DOMCTL_{get,set}_paging_mempool_size domctl-op, and shall be wrapped
> with CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_{get,set}_paging_mempool_size-case transiently with
> CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
> CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 

Acked-by: Jan Beulich  # x86



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 12:19:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 12:19:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120193.1465225 (Exim 4.92)
	(envelope-from )
	id 1uwgHK-0000Nd-9w; Thu, 11 Sep 2025 12:19:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120193.1465225; Thu, 11 Sep 2025 12:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwgHK-0000NW-7B; Thu, 11 Sep 2025 12:19:54 +0000
Received: by outflank-mailman (input) for mailman id 1120193;
 Thu, 11 Sep 2025 12:19: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 1uwgHJ-0000NP-Ev
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 12:19:53 +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 9d7ccba1-8f09-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 14:19:51 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-b079c13240eso105124666b.1
 for ; Thu, 11 Sep 2025 05:19: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-b07b32dd3efsm120831966b.55.2025.09.11.05.19.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 05:19: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: 9d7ccba1-8f09-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757593190; x=1758197990; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=07cCRKFEKR73KcOdWtmwOLBVT2/9Zq2igD34GYfPbwI=;
        b=WVss+EDtO2nSlnwKB3ifA/VGAuw8tCeiFC7mzhx+Shc3+gqW7Tk+2I/r1pB4zbEWEX
         APg13QTwPbSduZknJZ9ulFVeoWP22hXTxOsYklE6hGh2etf0fxTWr/yqmMNOf+oT8w7U
         rvGoKesomleXQph5S+USQ5rR5vdAtyzRMA0T9Uu++G0lReMLmS0vVZN2WEMk8oj0fwSW
         uI34KJShJ0IN5U2C/7AphaCW6QjqQMB4MV649ZzicwmFUV3+6H5D/QSPAICpdptSijcJ
         KOuAM9u3uw8xg6B2C49dZykR0zUPP75uCbtXZqFUTnQnsCBrM9+QQku6OFMyxez3M4D4
         qwBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757593190; x=1758197990;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=07cCRKFEKR73KcOdWtmwOLBVT2/9Zq2igD34GYfPbwI=;
        b=agF3HEL0+B0XwMGSJWp+LHxUGfdg8IoWo1OZgd0IlBoycvY1EZ/4wtjrAJeWajaD0P
         IVLWFDf8MxC2Ct0FrPX4+njqPnXpYXO9ytnkHtLBXZrh7lKReEmrMTbOOV1KauH6uwmS
         O3tGVC3ayp9V/6bZe3TtEAwcIOAeTN35y3Ru05XwIBkSa3dXNm3c/XHB7rRa6zcm69/A
         Yg2rJ75xLEHq+QUUfRWu70AB3PsyknjE6/7PE2qHAQaTt5ZxzFKZ8DbAKln6tE+OTDa/
         zAnJ1rL5l+v8JqP5EYa0y+I7RAFFfM2OwQUHSKy9NKtXMPB7OCZVCqYcg6JXeGkkhnQD
         HSbg==
X-Gm-Message-State: AOJu0Yw8L+Bb5uKeh8XTdcZzLdmsrVbS5wEFAgg7mbn7fxcEkFUsGiVo
	oQ1Ep1/YqvyFzU3kgygOdvsgtlJ+HL286wJnMREoL8QK/P9uuiO/qPclLRu1ls2GNw==
X-Gm-Gg: ASbGncs6Do6uXr5USrGZNOMWqMaCxCEgAliLLbRIwsIjbBARcTi/HI01KBqV3pMDdio
	B5aTNZcqPN2w2MObIMfmwHr0Cbfzfk6znlZn8RNw2D3pnECMouyR993V4xsTb/BmDXpCiQNH8fn
	qpCLB0/NKSYXMUQHiGkKJXjMJOaVxpgU+8LNVwZ2P+D6yX1S2A7MAcXzQ1FvzMTCgnbd39Vl67e
	e7hjwjCjX5ZPyqTWZr1Qvsghdhu3tjTiF6QqrUM7Ez7uOr91s0sX/mD2BCuEjrwbVgYF632xOat
	ej7YUJ46Sq4jyclZFL7E0qylbuE1RYVRDEaakSoWEWW6pn78bnt87kJCL7lySnMj+ow96b02X6h
	zbiQ64CBLyJlW7H2jnckc9Gs8a/g4yafyA7wwymGgkplw6kaUKLb+MZYIYfzgRJxAG4+e6YOesI
	RqoXpZYHc=
X-Google-Smtp-Source: AGHT+IGS+R8sUY7Cmx8cqEPn9NCyABx3ZIvVKD+39LfDEEmyjXzcbDBHdgosaFLE6xltRODWVO0obA==
X-Received: by 2002:a17:907:6d16:b0:b04:48b5:6e8a with SMTP id a640c23a62f3a-b04b13c1734mr1957582266b.7.1757593190176;
        Thu, 11 Sep 2025 05:19:50 -0700 (PDT)
Message-ID: <6c53c773-019e-4650-93a7-4a3127e33410@suse.com>
Date: Thu, 11 Sep 2025 14:19:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 23/26] xen/x86: make CONFIG_X86_PSR depend on
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: xen-devel@lists.xenproject.org, ray.huang@amd.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-24-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 05:22, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
>> Users control/monitor Intel Platform Shared Resource (PSR) through
>> related domctl-op or sysctl-op, so CONFIG_X86_PSR can be put under
>> MGMT_HYPERCALLS. With this change, we could remove MGMT_HYPERCALLS-wrapping
>> in psr.c
>>
>> Signed-off-by: Penny Zheng 
> 
> Reviewed-by: Stefano Stabellini 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 12:36:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 12:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120213.1465251 (Exim 4.92)
	(envelope-from )
	id 1uwgX8-0003cS-LE; Thu, 11 Sep 2025 12:36:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120213.1465251; Thu, 11 Sep 2025 12: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 1uwgX8-0003cL-Ie; Thu, 11 Sep 2025 12:36:14 +0000
Received: by outflank-mailman (input) for mailman id 1120213;
 Thu, 11 Sep 2025 12:36:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwgX7-0003b0-LL
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 12:36:13 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20620.outbound.protection.outlook.com
 [2a01:111:f403:2417::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e10265be-8f0b-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 14:36:03 +0200 (CEST)
Received: from MN0PR02CA0019.namprd02.prod.outlook.com (2603:10b6:208:530::34)
 by BL3PR12MB6570.namprd12.prod.outlook.com (2603:10b6:208:38d::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 12:35:58 +0000
Received: from BL6PEPF0001AB74.namprd02.prod.outlook.com
 (2603:10b6:208:530:cafe::72) by MN0PR02CA0019.outlook.office365.com
 (2603:10b6:208:530::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Thu,
 11 Sep 2025 12:35:58 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 12:35:58 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 05:35:57 -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: e10265be-8f0b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ng+LSWqDkkqSb30MbdOJEKGuu9m0SkWT+aRXABKpG6CJlURyEVEIpBzISJ//asqLvAc35Vu0Qs5PACZUzmi1T9o9KOMxIOZUfps2R3KH/VwAdTAa3i+RBijP+QLClMvWxFLX8mtILB5gP8JFadx5O7EqyYjw0PLsDpV3SC0UNY3wqki7DcGGNF6XqOXEwREgdTiAV7/C8ex+kMr/62X2rkiWHT2iZZ5awrWhZh1v5/TDrvRSHSvAiTKd6YPUGfpxIAtWeE0HCDnW+AHlo2490rzydOuhlLGc6TTcCnsgTK8wtLwN0XkWiIud0vqPDgOGM5s2Mi6MAPgJe3Ed1erZnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DYBsyTbeLIqtnkUldpoqCbwHqVEi3abOMhzuF8zI7Ak=;
 b=xpqbu0+ysLPNMlskt3qin3PmeXxAOKq4HmHoGbB6JCfLZircYUe2ksIIDq/wVcaTLdluLMi/jy1eW+okAxTfo+H/nuH2an9ar98//x6dia3FfEIq5PFLvs3uqsuMNTW1sfFyColw/yzCxNGEBcBZCIT0pWuVG+B62JmU037zFDlQAdGfvNZ4fs3BacQzq1YFpuRrOOImubCQ5jWMyNWwM5YQ8Y5JYLU8kk7WgPeadeH5jaGgv7PyNoyHVI3DZdfKsHllmvLlVgh+Ispj6c8N7pcwetNV3VNlZqZicCfzV7cID2ZVEgKYZFBBsa2Pa0jH8mXnM8ULS4oqj36x7+zyrw==
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=DYBsyTbeLIqtnkUldpoqCbwHqVEi3abOMhzuF8zI7Ak=;
 b=1hmhAdPZD6PzfYnR5eb8ZOPflQSs/tlWDbnKlLCAIT8nFoUM8pYJASPAhONznfwNtpkrPn6YTy/m3/CG7nIKq2/aqgPbSGBdQtT6FHhy3UxGeeOa83m6suuZ03PEs5HL5aDsHCUF4y+Qo33+NekrtIoqjAq6ZXQKvnJUoa8Stpo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 14:35:55 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Andrew Cooper ,
	
CC: Jan Beulich , Anthony PERARD
	, Grygorii Strashko 
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
X-Mailer: aerc 0.20.1
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
 <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@citrix.com>
In-Reply-To: <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@citrix.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB74:EE_|BL3PR12MB6570:EE_
X-MS-Office365-Filtering-Correlation-Id: d3abc0ab-8073-4918-2c56-08ddf12fc287
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?bytYalVtWitDa2tpd1g0bVA2REQ5dUpuK3FMNkhCamlsNFlJNk5zTmZYMWty?=
 =?utf-8?B?ZlVIUTA3QUlJZU4wVS9WNnhXbGNJU1VEWStEcllpbnUycTdqRGc3L21uU0V3?=
 =?utf-8?B?T3FCODgrUjd3Y0xPSm1QZmZWUndwUjlZWEhDMG53UkpZcFovWkRJZWlNMjhx?=
 =?utf-8?B?RXNmeUl1R1psSzY2MzJGUEpDK0FVT1I0RXdISTFWZUdoTExqY0tUR3oyNURl?=
 =?utf-8?B?RGIrUk5oZFNacVcyc0lwMm84TVQxTTFIRSs5Qno4VCtJTEF0V0RNRFN0WWNM?=
 =?utf-8?B?dFJaRW80QVJxM1AxelBHSlo1d2w1VHVBVWZXZ0RIQXlYSWlQVkY1a2VmWkxs?=
 =?utf-8?B?UHUwVlBQOTBhWU5ET3gyaDNCR084ZGxxdldzWVczYmt0RzhoSmNTOHVjVnE0?=
 =?utf-8?B?TGl1WlBwZ0xVMG5iZ0UzZG8vQ2NrZnZMb0xBc1J0S0VNTk0yUytmcXVqMlBU?=
 =?utf-8?B?VXo0SDhnM2VGTzRyYzR2WU11ZVl6c2lpbDVmQXFUWFMwZnZ1UEdZUTd5enVs?=
 =?utf-8?B?ZzBWRkR1c2F4RGZiWTNWdUpoTy9nNzJsTVY2MTI3dG10a2hoTWh4VFZXSXlq?=
 =?utf-8?B?c2lOSG1xUEFNb05IMWxEeEw4aTVrTDkrcHY5ZHhMWjJ2eENTTkJyWnVyRVBm?=
 =?utf-8?B?aHdoYkZtei8xWmhXR0FsdW1OOEh5eUcyUENRenVZTTNUYkN3MXpaZDFtNkNF?=
 =?utf-8?B?L3BNY256SkNOODZQTmdhQ3dKak5hSEg5Q3NIUy9QcUgvNzhJRDRUbnhEazl4?=
 =?utf-8?B?V21pTFJzNDJzREFDaUJCTlpZRGQwRFJ6YW8xK0x1bk1lUGs5MzVockJDMW4y?=
 =?utf-8?B?Z0JvVEVpdVdMb3R1NEpXamxHSElkeXBPQnpOOTFlckNsdTFaajJjMWV2NjVK?=
 =?utf-8?B?NHk1QTVpWUlaN2J4azhnNjJiVnllU3B5ZWxJTmNJVWgrM1ovQ29ndTZMSkJN?=
 =?utf-8?B?aHF1UXlWMVY5OG9JZ3BGdnBLc3oyblVkdjVXL1YrZjB4ZWF1dlpBaTMvL0kw?=
 =?utf-8?B?eWZIY2VRaWFjZklub2hMOWxVYlVlQ0RLcUxlUDRiSU8xb0hKUjdSVmdrNVBZ?=
 =?utf-8?B?K0NpeDhpMmdFT1lEMkRHeGZWY2N4dE9CRXJrT1JHS2hkeXBNanJPUk5Nb3p6?=
 =?utf-8?B?SWdUcFFzSnJNMVpPUnZITFVBaTRsRnFiNHlDdzB4a3g0NGRXdkxYOTQ0ZGZJ?=
 =?utf-8?B?aW5kNThnWEEvTy9aNmVGdlphMEplYXJOTW9PclFDenhZUVhralZRVmNiZjFI?=
 =?utf-8?B?Yyt3bXpTVW0zQWh3Mnh3UVFwTUsxZzlsWHZHSXJQdVdidDdkZTRNZFczd3Y0?=
 =?utf-8?B?eUR1Tkk2czlRU0VWMDJMMmorWmJ0cStpL2ROTDk1eTFCTitjdkFDN01QSUk2?=
 =?utf-8?B?aW9tdHRRRFpxNmZRQkRvQW0wSjhLY1pGRXNGM2Q1eDlqYjdHcy92OGpGS0x4?=
 =?utf-8?B?QW5UOVMwampEdWI1ZG16WmcrRFRrUTh1TWdDdGpJbXloU3dmQ0xFZlVMZEd3?=
 =?utf-8?B?ZzJ0OGlkTFFTMUlJd2tXd21pYmI5NUJXNlFhTmNLMFd5TlBMR2xISTF2Z1Fa?=
 =?utf-8?B?R3RNVHVrK1pnY0hOMFY0R3NQaGUvSlpWYVRwcDVsaTllbGhMOEJnL3B3MVZS?=
 =?utf-8?B?dFNGcDU2NVlkb0RuWjdaY2M1ZjhyaXRkYnBVSElSTzIxb0xXaFF6cWpSWkRP?=
 =?utf-8?B?a0FxZXNGTUwwZytaVDFEbzdWbFlnNWx4QjFYQ2lvVUlBcEwwYXNJZitSVk5o?=
 =?utf-8?B?UG5JRjh2bXY2N0p6T0o4RWpzNmU1Yk8yOVd2ZHIyTy83eEs5eGFIVVR5S3Nu?=
 =?utf-8?B?Tk9zalU2Y2IwNFpnVHVsdkY4YVdEN01ORVlCY1pqZVdSVnhXTjY5ZkRzRjht?=
 =?utf-8?B?Y2RDMmlIdkF0WnJmTktuLy91SXpvd09iYlFQUkRxTlYxVmVTTGllRUMxRGpn?=
 =?utf-8?B?ZGs0V2tFdXVBaDNMNDdWdHFVWnhCZUtyM1NVRWtJLzFZRngrOG9hZmEvaG11?=
 =?utf-8?B?U2s4cU5KY3RNNDRhbHh3dndHYXhsSDUxUTduWHZOWkk3UGZDbjRIUFVwVkdn?=
 =?utf-8?Q?a2+k4M?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 12:35:58.5451
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d3abc0ab-8073-4918-2c56-08ddf12fc287
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB74.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6570

On Thu Sep 11, 2025 at 2:03 PM CEST, Andrew Cooper wrote:
> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>> by the device model. The GPE handler checks this and compares it against
>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>> related bit in the bitmap and adjusting the table's checksum.
>>
>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until i=
t
>> reaches 128, even if that overflows the MADT into some other (hopefully
>> mapped) memory. The reading isn't as problematic as the writing though.
>>
>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>> then the bit where the "online" flag would be is flipped, thus
>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>> that happened outside its range. It's all terrible.
>>
>> Note that this corruption happens regardless of the device-model being
>> present or not, because even if the bitmap holds 0s, the overflowed
>> memory might not at the bits corresponding to the "online" flag.
>>
>> This patch adjusts the DSDT so entries >=3DNCPUS are skipped.
>>
>> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
>> Reported-by: Grygorii Strashko 
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> Half RFC. Not thoroughly untested. Pipeline is green, but none of this i=
s tested
>> there.
>>
>> v2:
>>   * New patch with the general fix for HVM too. Turns out the correction
>>     logic was buggy after all.
>
> Hmm, this does sound rather more serious.=C2=A0 I have a nagging feeling =
that
> until recently we always wrote 128 MADT entries.

If so, I don't see where. It used to be 16, waaaaaaaaaaaaaaaaaaaaay back wh=
en.
Then it got extended to whatever it needed to be.

I have the nagging feeling that rather opaque "some OSs (cough Windows coug=
h)
don't like more than 16 CPUs was actually this bug in action. Making the DS=
DTs
with exactly 16 CPUs a particular kind of silly.

>
> So, while this looks like a good fix, I think we might want a second
> Fixes tag.

Happy to add it, but I really don't see anything like that in the git log.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 13:02:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 13:02:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120236.1465260 (Exim 4.92)
	(envelope-from )
	id 1uwgwm-00083R-Jc; Thu, 11 Sep 2025 13:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120236.1465260; Thu, 11 Sep 2025 13:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwgwm-00083K-Gd; Thu, 11 Sep 2025 13:02:44 +0000
Received: by outflank-mailman (input) for mailman id 1120236;
 Thu, 11 Sep 2025 13:02:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwgwk-00083E-QD
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 13:02: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 958b99c5-8f0f-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 15:02:34 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-62598fcf41aso910694a12.3
 for ; Thu, 11 Sep 2025 06:02: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
 4fb4d7f45d1cf-62ec33b4d63sm1133500a12.23.2025.09.11.06.02.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 06:02: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: 958b99c5-8f0f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757595754; x=1758200554; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=23RZBBF9aJ5+NKN0Qo5G3UUaRiLapvjbrInirG7jKoo=;
        b=KEejP3LC6hdVShTMemVX27m7P2Cdqcar/AR2R65jHbyZQChlpDVG9Bl0gNYUJrToNF
         ewShmGZpTz3MU95PAMBW9V7470I5bb6GFiraRB1RkCqNxxh33dPti7anDHJuUpPeLpof
         Eu7iysC9kw3Ipi6Yqh1kBZlWaQ/Cw8eCX+WnrFOL9uKRQq0jpSO23+sfIw55gZwQaaIb
         +fOfv73bP4gMt3XG2AhOtjMUefoFXOOKgXwT6nkQW9CEdmnkVWDp8MHpnTs12FFpqzIF
         V0l2Hws1k2VMm4JytLaLBQ5fjrVl9EjcTp2t1PHyuP2R+M4poHpM6d9Jq6feT0RLdW7m
         8Low==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757595754; x=1758200554;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=23RZBBF9aJ5+NKN0Qo5G3UUaRiLapvjbrInirG7jKoo=;
        b=LKCAS+gerIQ5asPGiwxQLF1gL9kGM+Z62haQRPcau+iud5vxeckjrxJxE+zK6bg1Xf
         KgB392hkUJCEnL7uZTu2e3m90JDcf7dWExPywyZU6S7te3EbPPDpithVhLJ578khPsEf
         ai/eXFqK3CdD+RKuKxRO88707U0L1eQ0SGuGy4VtlGuM+vYevRSsI+vhvD7VIsICcG6t
         j0jscaQ3T0AofVjDMvXyFRayw/rGXqOdMMXClEeU21X5Vi8qPIJ84bXJ29yiKMfCOppD
         PAKKluxL443xsV9zAbKZsS5FXOAbzcJAltwREsaMynvbLfPMxLOZQrbIaTeKlBdDmrJs
         /PEw==
X-Forwarded-Encrypted: i=1; AJvYcCUu1ArQ+ZshW1r39RT99/JGtpallCPyWdyJztizbAq1W3AnpZLdEOEW296OjXs/6g5HI1jARLB/Awk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGqoF2IW+q1FJlRyTMv5EOZcfTnp02oQHx2JB5IrQNkT8RdfKH
	h/dAtHqTpTfDd8LIfgGeib8Frwi/pyfCX3dGd5h+XGBpvw05VZDW543q9Exomn2CBA==
X-Gm-Gg: ASbGncsNgjz98L2V0UlETDRsyCrhrrIfrH9lNIM6YUeJp3jmdPjoKuaByf4w9VAAeB7
	DGisYc5ynN2y4JPcnF1b3obMzDEHD3RSUSx5rFrmuUtctQQXNxez1ElvaeIwcMeXbppmh+/KSn4
	cN9N28fDjX2pKSLTmmhcws6JUkQ4JjDJ0gab9JOWa7mxC2BA8+iYS1MdkvvBTzZHieVzM71DuZT
	CVOLWxhAybrd+thX8QkAXbJq73kwGGYDjTCoT0X2Odf3Ip4vR4eaoJd2x3XRJcmfy5/1C2Ndk+b
	hcerEvrB9CpsMDDx5v9NduCslTBfjat4oEzJHkh/RifFCzbPWYH8Ym1ty4Szf62RQv1BriWmmho
	vwyYq7KIFxRnTBG5y/Wkkbzyn1v1xYl5jkc32sMxDfgt6UkkJJg3MogYkgR6mfhRoSrWvTPZlrR
	TcnOEXRcEw0/rn3fMcOQ==
X-Google-Smtp-Source: AGHT+IGzfD85p+zWbyyfT7Lx3PvSLRipfyMd5Osh+QDPyKHb3FQ5eb2JVwoewn0Xxy25QAn9AJFhZA==
X-Received: by 2002:a05:6402:3596:b0:629:949c:a653 with SMTP id 4fb4d7f45d1cf-629949cb00dmr12863519a12.24.1757595753685;
        Thu, 11 Sep 2025 06:02:33 -0700 (PDT)
Message-ID: <56024eb0-b30f-43fd-84b7-6070a1d79cf0@suse.com>
Date: Thu, 11 Sep 2025 15:02:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 24/26] xen/domctl: wrap arch-specific domctl-op with
 CONFIG_MGMT_HYPERCALLS
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 ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Tamas K Lengyel ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-25-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: <20250910073827.3622177-25-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> Function arch_do_domctl() is responsible for arch-specific domctl-op,
> and shall be wrapped with CONFIG_MGMT_HYPERCALLS
> Tracking its calling chain and the following functions shall be wrapped with
> CONFIG_MGMT_HYPERCALLS:
> For x86:
> - hvm_save_one
> - hvm_acpi_power_button
> - hvm_acpi_sleep_button
> - hvm_debug_op
> - mem_sharing_domctl
> - make P2M_AUDIT depend on CONFIG_MGMT_HYPERCALLS
> - make PG_log_dirty depend on CONFIG_MGMT_HYPERCALLS
> - make policy.o depend on CONFIG_MGMT_HYPERCALLS
> - do_vmtrace_op
>   - hvm_vmtrace_control
>     - hvm_funcs.vmtrace_control
>   - hvm_vmtrace_get_option
>     - hvm_funcs.vmtrace_get_option
>   - hvm_vmtrace_set_option
>     - hvm_funcs.vmtrace_set_option
> - paging_domctl_cont
> For ARM:
> - subarch_do_domctl
> 
> Also, remove all #ifdef CONFIG_MGMT_HYPERCALLS-s in arch-specific domctl.c, as
> we put the guardian in Makefile for the whole file.
> Wrap default-case and arch_get_domain_info() transiently with
> CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
> CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - split out xsm parts
> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
> - wrap default-case and arch_get_domain_info() transiently
> ---
>  xen/Kconfig.debug                  |  2 +-
>  xen/arch/arm/arm32/Makefile        |  2 +-
>  xen/arch/arm/arm64/Makefile        |  2 +-
>  xen/arch/arm/domctl.c              |  2 --

Isn't there a change missing to arm/Makefile? Or else, how can ...

> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -184,7 +184,6 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>      }
>  }
>  
> -#ifdef CONFIG_MGMT_HYPERCALLS
>  void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
>  {
>      struct vcpu_guest_context *ctxt = c.nat;
> @@ -200,7 +199,6 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
>      if ( !test_bit(_VPF_down, &v->pause_flags) )
>          ctxt->flags |= VGCF_online;
>  }
> -#endif /* CONFIG_MGMT_HYPERCALLS */

... this be correct?

> --- a/xen/arch/x86/hvm/save.c
> +++ b/xen/arch/x86/hvm/save.c
> @@ -121,6 +121,7 @@ size_t hvm_save_size(struct domain *d)
>      return sz;
>  }

Both this and ...

> +#ifdef CONFIG_MGMT_HYPERCALLS
>  /*
>   * Extract a single instance of a save record, by marshalling all records of
>   * that type and copying out the one we need.
> @@ -195,6 +196,7 @@ int hvm_save_one(struct domain *d, unsigned int typecode, unsigned int instance,
>      xfree(ctxt.data);
>      return rv;
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  int hvm_save(struct domain *d, hvm_domain_context_t *h)
>  {

... this and hvm_load() (and some others) will end up unreachable when
MGMT_HYPERCALLS=n and MEM_SHARING=n.

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2585,6 +2585,7 @@ static bool cf_check vmx_get_pending_event(
>      (RTIT_STATUS_FILTER_EN | RTIT_STATUS_CONTEXT_EN | RTIT_STATUS_TRIGGER_EN | \
>       RTIT_STATUS_ERROR | RTIT_STATUS_STOPPED)
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  static int cf_check vmtrace_get_option(
>      struct vcpu *v, uint64_t key, uint64_t *output)
>  {

This #ifdef wants to move up a few lines, to also cover the two #define-s.

> @@ -2693,6 +2694,7 @@ static int cf_check vmtrace_control(struct vcpu *v, bool enable, bool reset)
>  
>      return 0;
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  static int cf_check vmtrace_output_position(struct vcpu *v, uint64_t *pos)
>  {
> @@ -2883,10 +2885,14 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = {
>      .altp2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
>      .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
>  #endif
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      .vmtrace_control = vmtrace_control,
> +#endif
>      .vmtrace_output_position = vmtrace_output_position,

Why would this remain? Patch 05 makes VM_EVENT dependent upon MGMT_HYPERCALLS,
and outside of domctl.c the only other caller is in vm_event.c.

> @@ -747,8 +751,10 @@ bool altp2m_vcpu_emulate_ve(struct vcpu *v);
>  
>  static inline int hvm_vmtrace_control(struct vcpu *v, bool enable, bool reset)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      if ( hvm_funcs.vmtrace_control )
>          return alternative_call(hvm_funcs.vmtrace_control, v, enable, reset);
> +#endif
>  
>      return -EOPNOTSUPP;
>  }
> @@ -765,8 +771,10 @@ static inline int hvm_vmtrace_output_position(struct vcpu *v, uint64_t *pos)
>  static inline int hvm_vmtrace_set_option(
>      struct vcpu *v, uint64_t key, uint64_t value)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      if ( hvm_funcs.vmtrace_set_option )
>          return alternative_call(hvm_funcs.vmtrace_set_option, v, key, value);
> +#endif
>  
>      return -EOPNOTSUPP;
>  }
> @@ -774,8 +782,10 @@ static inline int hvm_vmtrace_set_option(
>  static inline int hvm_vmtrace_get_option(
>      struct vcpu *v, uint64_t key, uint64_t *value)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      if ( hvm_funcs.vmtrace_get_option )
>          return alternative_call(hvm_funcs.vmtrace_get_option, v, key, value);
> +#endif
>  
>      return -EOPNOTSUPP;
>  }

Why #ifdef inside the functions? The sole users each are in domctl.c.

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -114,7 +114,9 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
>  
>      memcpy(info->handle, d->handle, sizeof(xen_domain_handle_t));
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      arch_get_domain_info(d, info);
> +#endif
>  }

This shouldn't be necessary; instead imo patch 18 should be extended to cover
getdomainfo() altogether.

> --- a/xen/lib/x86/Makefile
> +++ b/xen/lib/x86/Makefile
> @@ -1,3 +1,3 @@
>  obj-y += cpuid.o
>  obj-y += msr.o
> -obj-y += policy.o
> +obj-$(CONFIG_MGMT_HYPERCALLS) += policy.o

Fair parts of cpuid.c also become unreachable. And all of msr.c afaics.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 13:14:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 13:14:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120252.1465270 (Exim 4.92)
	(envelope-from )
	id 1uwh7n-0001Uu-Ld; Thu, 11 Sep 2025 13:14:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120252.1465270; Thu, 11 Sep 2025 13: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 1uwh7n-0001Un-IQ; Thu, 11 Sep 2025 13:14:07 +0000
Received: by outflank-mailman (input) for mailman id 1120252;
 Thu, 11 Sep 2025 13:14:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwh7l-0001Uf-Ki
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 13:14:05 +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 2f563e7b-8f11-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 15:14:02 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b0428b537e5so102092966b.3
 for ; Thu, 11 Sep 2025 06:14:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b30da37dsm128642666b.18.2025.09.11.06.14.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 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: 2f563e7b-8f11-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757596441; x=1758201241; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aL6a1NHLWC8VwdXipdoBqMORqHdqxc8SyRVYKG45v+U=;
        b=YdT3mGas34r28JMCvkN9763Vl1iCNjRrhhULde2jlSDaAu3Z8nJ/+IB+ORwvkXb4Jp
         Q3A2B6/na1ANeNkGQY1Dgn8z8w1FpO7TlrDyUlMHuKex/d+sym3NpNtgsnKlYxsodeQB
         fpjf1qbeHgutzck7uDG3Nn6s79AN9kOkLOoOQ2UJrBWb8wDpvSnEiB+nYV7S4LOyG50p
         5EoFdWS57yBLZqHPEfQHbYCDXiczK3G93m2hUNnuNkzTXn6kibSGW/43z+ueFkEusjZC
         7dDemmVf+BZkLkrV3CfnB7N4lJoPsc3z8PBtVqhCvOvuvWeQuXr9ssbfc0zTCQybokuv
         L8Tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757596441; x=1758201241;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aL6a1NHLWC8VwdXipdoBqMORqHdqxc8SyRVYKG45v+U=;
        b=OCQVc/H8B2I46QOJDf8gfeecSe+0gOEYLU8sljtGvsYGVn2zWhdix0pAZ3ipn3sR4R
         IHohvwK9gcAltNAaXVRherjLg8Pdxx7l1xGhCqA7mMvQW/zrhKe5Ziy9Vy29hBNun+wf
         GI/98Ly2s6uBOjClQ7Y4ILM7tfpInSfnSrp9+RAYM0pomIA4QDWZfLg+EdQYRnxdtxWh
         EpvhaYYp3OvDgSsdME3FSsrSCyLKhs55Wc5b/GuuDZBxqNKhN2UTtIJvnSnQKJHjGoP8
         ZxSL8R83K9lUYYLFj+BsnYZ3egHTZdQfdm1N2wbS/7c+8Dm/Wiffx96f8u2pMgl2zB8C
         QZFQ==
X-Forwarded-Encrypted: i=1; AJvYcCUhQVHFvxKAmy6hdWCQnQqhhNI6kJ4Bk5cr+VwfsRl1yuAtZpvnHFH6KGfupGSS/LFqwMBmG8n2qU8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBP2xVs7Inf6cVl49Pjjq8l6ss9EltqN8AHvwO5NCUBpUL9eji
	6SrY0HUj37EP6SDbj4zm6UHycHe6abhaHzgUHqQESwz7ylvEKbG80gW4ejmj2qetZA==
X-Gm-Gg: ASbGncvmBXacyEmUm1AGPNSunht0nY4JJ5il3OVdIMMJduZ9u8YS/qvSp2/AhOcdUWf
	zY/o8kosaPxmegl71cVDaYOhx1NQ1GgI5urw8zMZmT+EKKtFGs7aUKkR8pDCFuvMbvAFjcdvgMy
	rMTgDAznBelClmjFI8VVbsVnB8sAfiSzeq4fzp6lRhsikO/jppX93qSWJpmsvS+KKrKNkw+QuhO
	7krxkcLPwM0cpiD/OYECWI+Jt7aB1OwlSugjNV7G8xaCaR2tIpGlsYnH9NtZ1ZkOxB60pLoUNoE
	iEogE6+KNfsX2055xPEMtEkWj4E5pL/LE+94os6gTMm7wmz45xzLefKUJtT3psqYKiTjahCjoQk
	8nbn2hSvteW9iOV7dl1fiIgI9bWpMnJVzuKxsfbyuK5V1HqDbwkFQ5cCVDFHbFgpVLUKDZYpgCa
	5mpLAnwC0=
X-Google-Smtp-Source: AGHT+IFw7IHnswo+zmiA0nq6BiFCvO7q9MXfRcEEU9C43WA8CJueeMKfjmr7a4bjWwGS2UMqGNTpIQ==
X-Received: by 2002:a17:907:3cd5:b0:b04:4d7a:8509 with SMTP id a640c23a62f3a-b04b1559b84mr1825324466b.36.1757596441501;
        Thu, 11 Sep 2025 06:14:01 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 15:13:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 25/26] xen/xsm: wrap xsm functions with
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: ray.huang@amd.com, "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-26-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: <20250910073827.3622177-26-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> The following functions are xsm-related and only invoked under arch-specific
> domctl-op, so they shall all be wrapped with CONFIG_MGMT_HYPERCALLS:
> - xsm_domctl

Doesn't this come too early (reflected by you putting #ifdef inside the
function), while ...

> - xsm_{bind,unbind}_pt_irq
> - xsm_ioport_permission
> - xsm_ioport_mapping

... these fix unreachable code issues introduced by the previous patch?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 13:26:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 13:26:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120271.1465281 (Exim 4.92)
	(envelope-from )
	id 1uwhJU-0003Ln-Mr; Thu, 11 Sep 2025 13:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120271.1465281; Thu, 11 Sep 2025 13:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwhJU-0003Lg-J3; Thu, 11 Sep 2025 13:26:12 +0000
Received: by outflank-mailman (input) for mailman id 1120271;
 Thu, 11 Sep 2025 13:26: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 1uwhJT-0003La-9t
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 13:26:11 +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 e0c268c7-8f12-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 15:26:09 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-afcb78ead12so101799166b.1
 for ; Thu, 11 Sep 2025 06:26:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b334ed29sm131214066b.107.2025.09.11.06.26.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 06:26: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: e0c268c7-8f12-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757597169; x=1758201969; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sg4kGQHdbEsMsy1Uynhefotwcxa2aAEMZ9/hvyKJum0=;
        b=Cil5aiwNpPR+CQNTLaOF5S77G6AmA/Jl/f8KuCJkYufbmy+DTlC26xz4c/XI8IMM71
         1F+cLJxym5XGQXJiriw3cZOM6HHGL0rDaZU089KZfU4PCYCLkkBtJi+xMz5V7WsvZkYb
         d+RlHSPSg8piTnV+NU0IESUtdiUn1khvgtDPLYm9v0BCTpwEtHW9VfxUuLTEyi/h2LKC
         FF7FWCcYIgzwmwivT7DiP1lw8aY3UV3JWrj+cj1RtiNirX/zzyHSsdkSo1MWCd1Zafnk
         JM00jA+dHiWZNsKTzqCKek05eiiOwin67dA4fY/ic/xww4NUa5BFPgRVuzjn2GRMYizV
         tpSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757597169; x=1758201969;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sg4kGQHdbEsMsy1Uynhefotwcxa2aAEMZ9/hvyKJum0=;
        b=ZAN8I7gFd0MabKy9zkZhQBrwl1LbtsMg7SLTaUhgzRb63hxaxeSjejBWL01uxxWu+J
         OSfZT497eC7FoYhFKLp2nVDiflvQhgLPNXKyhtTiYk4CbOiv+EXzlUDGslJemP7WCPaK
         pwCeWsWhRKp5hvtBaXI3QFkNWBN3KAPp82Kd22XGVgPccIiE0FFYbk1y/jrZLI6Gp4vC
         E+ZmsPtCprsMvyYMx511h9HP1L93JeqlbBgdPZd9dDtApdReRtEHwAvVZ287c5ss/4B3
         HQpjl4tN8JIJF5rGNBu0gOR1uSZCln6nFJXisbHzRIhQcBJoemlvcnljNPgDAoI1pYOK
         LTfg==
X-Forwarded-Encrypted: i=1; AJvYcCXUEVY2FFIfV+VDk6q81vKRb9SLWMzBlOb1iEzsk+NTiRGEkeFFqOlmKnpHVRqAY1bfM9Zf/bsG1Do=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/YTwWE62Pn8JjtzUeuem3Yvk7QUoYHXsrNtheX7UGSLgBSprK
	IFZXC14nTcQdawlHd4LVSYej2I0xTmxJAHEVj89630zI6iZ8FfW3R86bMi54XdkGHA==
X-Gm-Gg: ASbGncvc3a7zkuvSJ5pUSbC7wtoFI9mF6Cy7epN48aNxXSs8lCjdqEH3D1o20UGsi2X
	e6G8gE1D9NLk49ihxrbdv6Vb93rReeBTn1FicrgTPCni5ykPA5P49p4Kl/ksQKvlEdhM4+mXSnL
	EdngJ7vDRmYtUR9uuDAQAntdnH1LziYVHQBA39DLklDBlXMYbp5mUExTpta7B8iYvXUvn4VYTsf
	yEkfQOPA0HElnPsK/VAW0FhdCwels0Sb+1vpEIPm4s6vzCLFFWfR3PxfeLFzMCU/9sAo6IZP2dp
	0eC41daBJ4EeOnPWA/hBLM18azlGDw4t4B65M8ufev1LZmAOnNoMWTd6b3kfOiZIaZBvIz1D9Gs
	h0cRRI3lBx1J47bfpBanjG1bBgXNCrkT71IvOEWdcp7mjUXIpp2i24kgdPs7ZU1ip8E9XXoU5JH
	9DjmA+mOrpnMM5YMdPaw==
X-Google-Smtp-Source: AGHT+IFVDiWambJBLm/XHcqeaV9jSmbF4S6s0EZAFYrlJINiXpZcl6nM/A6G0QMaEd8JDgO6TPY0dg==
X-Received: by 2002:a17:907:7e9f:b0:b04:5a74:b675 with SMTP id a640c23a62f3a-b04b1401165mr1702946466b.9.1757597168674;
        Thu, 11 Sep 2025 06:26:08 -0700 (PDT)
Message-ID: <7bed306d-ddd6-432e-802f-ee0e4e8c5cfb@suse.com>
Date: Thu, 11 Sep 2025 15:26:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 26/26] xen/domctl: wrap common/domctl.c with
 CONFIG_MGMT_HYPERCALLS
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: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-27-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: <20250910073827.3622177-27-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -151,8 +151,17 @@ void arch_dump_domain_info(struct domain *d);
>  
>  int arch_vcpu_reset(struct vcpu *v);
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  bool domctl_lock_acquire(void);
>  void domctl_lock_release(void);
> +#else
> +static inline bool domctl_lock_acquire(void)
> +{
> +    return false;

I.e. a someone invoking hvm_set_param() with HVM_PARAM_IDENT_PT will loop
indefinitely on getting back -ERESTART? Imo you simply cannot get things
right here with a stub: Either you have the above issue, or you put some
future new user of the function at risk.

Setting HVM_PARAM_IDENT_PT being a toolstack-only operation, I think that
needs making conditional upon CONFIG_MGMT_HYPERCALLS right in this series,
such that the last caller of these lock/unlock functions disappears.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 13:30:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 13:30:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120284.1465290 (Exim 4.92)
	(envelope-from )
	id 1uwhNH-0004vX-4C; Thu, 11 Sep 2025 13:30:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120284.1465290; Thu, 11 Sep 2025 13: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 1uwhNH-0004vQ-1f; Thu, 11 Sep 2025 13:30:07 +0000
Received: by outflank-mailman (input) for mailman id 1120284;
 Thu, 11 Sep 2025 13: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 1uwhNG-0004pq-77
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 13:30:06 +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 6ac9723e-8f13-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 15:30:00 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-45dd505a1dfso5939985e9.2
 for ; Thu, 11 Sep 2025 06:30:00 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607cd27dsm2425221f8f.41.2025.09.11.06.29.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 06:29: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: 6ac9723e-8f13-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757597400; x=1758202200; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KbatsuDTaiKpismUZyqTbUrE//HluN2A1JCg86bt5SA=;
        b=ikRq0YZIZ+mhI0OgTi5ynsGm3isnaxisS2m/gZLoV4A+FgGWa1A5O8eCbd7CCnmBWy
         K9iq19Vz1u7J/qvjW4A7hGE2GPxT0+Z2e2kBvhPymVzSC7chOzASiJGkiiWlL5nlsZPq
         z05C33wka8dpVceHwKdeabvepK1XE+nEWn91I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757597400; x=1758202200;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KbatsuDTaiKpismUZyqTbUrE//HluN2A1JCg86bt5SA=;
        b=pocrS2ySJD9UmiP7QNpYdM273UN1Mnl8BVHUwBLuKN1bzldojf0brf37GoCp3ot/dY
         XAdwza94hPtc/y346QakLb6/11vYr/Md57rOQOVUXHY07dn5DySvTg2PxNjNZT/N9UED
         hIUEhbN5xOxBBOYE07xHrcbPCvK14l6Rf4s1D1pTqq6nG+ldQaR3aQ+IK7UKzDV95GkF
         AWkQ05/Ppr4vo441NLY9ORUzFff3GkLcVHIt/F6orGCPNJKhqZh735cCnTfW77J3i7ar
         +oENY/ScD5qslUVpXxcOztpLFAEKvpwp1ITxUGim7WxFDqUYclUaqjmVoOFq8s4GJ5R5
         rC6g==
X-Forwarded-Encrypted: i=1; AJvYcCXoK/QEoggOHKAOJo8RT2AlIktBEjvvOim/aZV1UIOSmloorju80dSySzTLU+zHQeLVu5CmpSxapUs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/MiudHVmzUMaPj7WDo0tfcis5yINckAp7RmGGCa7zC0ka3XlL
	iuBR21EHTsq8w5kychisHOQ+QfDB5F03AKCtMvbd4HUU1V1PMOsByo6/pveYNXux7h7orvm8vYR
	+Us8w
X-Gm-Gg: ASbGnctxHy3Sec03xaCvSgRmLwGog5lx3eI+svZd+kUIUU5lhlOxZ2zERj0C++EGJIH
	5IHYwfMYyZGLuiP1Qf4FYdEImxi+94aF7cXzkqYyXqpdJimBllVuTGz5g1ijuTvtDTPCax6q5+l
	wX6uRcFQKVi4dT1+df4MpUwNs7aea5rf+8QXix4cVu1INFxLeeDra2RuscFcFHNwXDidKFFbzdu
	T1N6VYpc9Lr05zzdCRupoco3uaifD5fQC44O/XhTUFluwCVb7r7eICZhl6l5RjeY91yMadsQz2Y
	YCULn/jGFXN3wa/FOUDsX8DSXRZ5sbtZpBIX9ftjXbSvzUthj39sxA2gavjyVc3OZ8GsT/lABV1
	gjaFe37i/WbmTpwvDpLTQ/1D5cXljpJfEBNFUxw7ZU7ugBIWI2OA8Tjcs3jtO7UkPI6fV
X-Google-Smtp-Source: AGHT+IGwy5XUDzgxy3KbfsXguza0y8H6/sGrUNMWv9IHhrWAzNm9puCo1opbLCqXWbCXNqw/CX4vdg==
X-Received: by 2002:a05:6000:26d2:b0:3df:b9e7:35ba with SMTP id ffacd0b85a97d-3e6440f0674mr15798675f8f.57.1757597400130;
        Thu, 11 Sep 2025 06:30:00 -0700 (PDT)
Message-ID: <48503adc-4ad5-4506-8e04-6e7882022b7d@citrix.com>
Date: Thu, 11 Sep 2025 14:29:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Alejandro Vallejo ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
 Anthony PERARD ,
 Grygorii Strashko 
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
 <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@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 11/09/2025 1:35 pm, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 2:03 PM CEST, Andrew Cooper wrote:
>> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>>> by the device model. The GPE handler checks this and compares it against
>>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>>> related bit in the bitmap and adjusting the table's checksum.
>>>
>>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
>>> reaches 128, even if that overflows the MADT into some other (hopefully
>>> mapped) memory. The reading isn't as problematic as the writing though.
>>>
>>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>>> then the bit where the "online" flag would be is flipped, thus
>>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>>> that happened outside its range. It's all terrible.
>>>
>>> Note that this corruption happens regardless of the device-model being
>>> present or not, because even if the bitmap holds 0s, the overflowed
>>> memory might not at the bits corresponding to the "online" flag.
>>>
>>> This patch adjusts the DSDT so entries >=NCPUS are skipped.
>>>
>>> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
>>> Reported-by: Grygorii Strashko 
>>> Signed-off-by: Alejandro Vallejo 
>>> ---
>>> Half RFC. Not thoroughly untested. Pipeline is green, but none of this is tested
>>> there.
>>>
>>> v2:
>>>   * New patch with the general fix for HVM too. Turns out the correction
>>>     logic was buggy after all.
>> Hmm, this does sound rather more serious.  I have a nagging feeling that
>> until recently we always wrote 128 MADT entries.
> If so, I don't see where. It used to be 16, waaaaaaaaaaaaaaaaaaaaay back when.
> Then it got extended to whatever it needed to be.
>
> I have the nagging feeling that rather opaque "some OSs (cough Windows cough)
> don't like more than 16 CPUs was actually this bug in action. Making the DSDTs
> with exactly 16 CPUs a particular kind of silly.
>
>> So, while this looks like a good fix, I think we might want a second
>> Fixes tag.
> Happy to add it, but I really don't see anything like that in the git log.

I can't find it either.  Maybe my memory is getting faulty.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 13:30:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 13:30:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120286.1465301 (Exim 4.92)
	(envelope-from )
	id 1uwhNO-0005HY-C8; Thu, 11 Sep 2025 13:30:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120286.1465301; Thu, 11 Sep 2025 13: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 1uwhNO-0005HR-8k; Thu, 11 Sep 2025 13:30:14 +0000
Received: by outflank-mailman (input) for mailman id 1120286;
 Thu, 11 Sep 2025 13:30: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 1uwhNN-0004pq-Ed
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 13:30:13 +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 71556973-8f13-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 15:30:11 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-b0415e03e25so94847966b.0
 for ; Thu, 11 Sep 2025 06:30:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b31295c9sm137298666b.43.2025.09.11.06.30.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 06:30: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: 71556973-8f13-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757597411; x=1758202211; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5VDz3WA7cDa9FIjcLpWB/5k5debjAvF8zkERceJxvUY=;
        b=Uornn5XRRzqEgs4+UCOewta0VFu++v3zPfi6BBdfp25ts7+mh0BldCdhl88oFcBitc
         AE2EFcExoQVEeQ9h8y1Y8pKQHCIlyN5MkrU3i9bnTmsSVZFodKhtNG14oON+5hwPFq59
         0FU0glmqFrytaDaeZtIn4AfpzszqCIF4T3z6M0ZHsuVOIVmYatIl4CNhw0pNppJ96DSN
         PXn7yFW3ZQ8UqH01jZT23fE0KqzapJvrKX/MYCoy4SbtcytkYFkMZ8h+onkWoTReBfVw
         Q349v1GXrIgWDaOF4tm+Qq3cdDnJIAsHAzUSflkBi1qO2y5Sfr1GziAet2XHWSK3ODLx
         V8FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757597411; x=1758202211;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5VDz3WA7cDa9FIjcLpWB/5k5debjAvF8zkERceJxvUY=;
        b=XvyA4Lk3Ml8GLmDuR98h/GCqqd/O5X0lOTFM6G4Bgu1HhfetElw8CVzZErUgoODBf3
         Z9hE+ggywGGfw/LhJi96M5rjneg4cH4wi6MyqgQ5Fm0MCOOCPd86NKSb0v/0To2Nykgg
         +wbDJoNmd0KE32uZV+xi9Dd1OFWfcSAYtMqMipjoSdJz8fy+skA5G1+tiM0j7nrox+1s
         /beEplpobAN4yXzHh2hEh/2dFIYOqm9ug5DLZGGn7eToUoJcaowWxJ66hjTl+taAwuE6
         IrAX2uTaIbUdaZTCw8TObbUfcS7f2QfFt6FyNwoU7xWZQzPEDOii1KaKDJd8PqBWNxai
         dzSw==
X-Forwarded-Encrypted: i=1; AJvYcCULM5Dqgae6xkJ8Dqrr2oT8LKvAcSgtDViBJGi6/qA5RYNCvfknHUe3IqGVdAgJLVx7fEomGKl/IhY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAWSgAIyOjYk+jxqMDYQrtSWHHfoBDvQ9W26L6CqFSvddUE4gX
	9RVGfsxCXeX9tLEyendvNPOCYc4KV3LiUTyTPxxPhs367+BnK3iI83c2aQIRsF19yg==
X-Gm-Gg: ASbGncvwPRgKzCmtxgTjaDi+ztv2RqxXlNG6ek5IGlUcL4yirxY2llj5863/CxlB5D+
	qb56J5ynbntl0rZT9O/VkDY6hvw36tGw/28Mhn5pV6ef6qUnpUcLcA/pPglvz/WqJwH7bcg5OY3
	EiEhMxGa0uY+UBhjfoiKJ8bQE87/nAyCiCCpDqSy0Qgic2lfhO1nHW0QgB7d5DezzMWh0de2a4I
	XxgS4ggKLrP6a9Nq4JKTYcPkEQCUdoWxEEyyf+2olepVIrBpcyAvJgulozInlAT3HBboTlLFmwM
	9K6fPDNfp5AwHYZ8Mlj2mnKarIk+W9tXvqLqhP5fPCBPH5gpotUOg/6CC7coqoWud/hYo2Iytrk
	iVyNqUBkjAeWsbZVofsCWHjr35SBSRKxiqEPI+PdwdynKlwN06BHasr4StU1y2HvVoL0kWmoPeK
	3zVJ6sf5M=
X-Google-Smtp-Source: AGHT+IF/Rxn5onPTjug4vXjTkrTTpagvnrSI9fReADu97oJMeMktdOGGd9G9PrXQrqRYMvcgk1vE4Q==
X-Received: by 2002:a17:907:890d:b0:b04:9ad9:5b2c with SMTP id a640c23a62f3a-b04b140d270mr1888579666b.25.1757597411245;
        Thu, 11 Sep 2025 06:30:11 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 15:30:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: Penny Zheng 
Cc: ray.huang@amd.com, "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: <20250910073827.3622177-19-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -55,8 +55,8 @@ struct xsm_ops {
>      void (*security_domaininfo)(struct domain *d,
>                                  struct xen_domctl_getdomaininfo *info);
>      int (*domain_create)(struct domain *d, uint32_t ssidref);
> -    int (*getdomaininfo)(struct domain *d);
>  #ifdef CONFIG_MGMT_HYPERCALLS
> +    int (*getdomaininfo)(struct domain *d);
>      int (*domctl_scheduler_op)(struct domain *d, int op);
>      int (*sysctl_scheduler_op)(int op);
>      int (*set_target)(struct domain *d, struct domain *e);
> @@ -234,7 +234,11 @@ static inline int xsm_domain_create(
>  
>  static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
>  {
> +#ifdef CONFIG_MGMT_HYPERCALLS
>      return alternative_call(xsm_ops.getdomaininfo, d);
> +#else
> +    return -EOPNOTSUPP;
> +#endif
>  }

This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl is
hence already broken with the earlier series. Now the domctl is also being
screwed up. I don't think MGMT_HYPERCALLS really ought to extend to any
operations available to other than the core toolstack. That's the Xenstore
ones here, but also the ones used by qemu (whether run in Dom0 or a stubdom).
IOW I think there's a conceptual issue with this work which needs resolving
first.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 14:52:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 14:52:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120365.1465330 (Exim 4.92)
	(envelope-from )
	id 1uwiey-0007Wl-Aa; Thu, 11 Sep 2025 14:52:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120365.1465330; Thu, 11 Sep 2025 14:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwiey-0007We-7c; Thu, 11 Sep 2025 14:52:28 +0000
Received: by outflank-mailman (input) for mailman id 1120365;
 Thu, 11 Sep 2025 14:52: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 1uwiew-0007WY-Sw
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 14:52:26 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ee16f37c-8f1e-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 16:52:25 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-6188b5ae1e8so1076226a12.0
 for ; Thu, 11 Sep 2025 07:52: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
 4fb4d7f45d1cf-62ec3400c92sm1336966a12.38.2025.09.11.07.52.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 07:52: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: ee16f37c-8f1e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757602345; x=1758207145; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2lhZ27yQ4va1xoMlXoRfL42mfmMrtYi47J2r+hzd8r0=;
        b=X172xgHxBIg3VX3rGrrKV7Nw9pjZkDE3m0tlExk6V+yRJJGarZLn9Wius4rQtKxwnS
         Wa4rWcWebAqwPiYbVCPF5Ft2YNPajKn+7Y4rZJvGgEjVjbvSNTVoHsKdPaAxhGhxRSpu
         v3XH0dpQ/DrmMk88lWLx7WjzlR+8cyNHJK4LWiMYOg+SBnSTeUKXPKWU0GkTDPKn2y+r
         sm5YJ6Ix/kqYyBfEmwTp/sd3U0Sj6TEOnv4Z/dojjvXmQn+h/UBiQ6qKZYuPil1Jlgw/
         LTJcmMhGW5TEPhOoImAGvyZrF3xMN+b6UhXs2hhtLke7590i37AgL2cViCsMhNw+tQxE
         Y3WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757602345; x=1758207145;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2lhZ27yQ4va1xoMlXoRfL42mfmMrtYi47J2r+hzd8r0=;
        b=Ej6VU+xIo1WOwSw3vDHOjp1FLZUR39EOI1VetpEMeSkPTno6Q365AikaCF1Igoztzu
         TwFhaYnXg5oYHDvMDhdQJRTvXiHnwA0iS9UDw/F3dMezXxkzr0kpSA2mpn8ohS4xxb7R
         PQJjT6xNJvzUT7NDMjaGvOs9j6grEjC1Ctiv0a22YUfDFqq+6xjmbJ9M+pncFd/o7rkP
         BDvxIqYNpmwXQRcomkMTkaJ12xRMol6+6CtahcXdNwL54mdNtweIH2YTD12Jo7fUeOBs
         U/v3sWPiZYrqOGIOvolUXRTCWjyinJMpwxpwZjaPy8IHLpi6TvIeRFKmOVX7OEWIGHKu
         ERIw==
X-Forwarded-Encrypted: i=1; AJvYcCVKlSfPoyfrTwqmNidVJDPiZh3h1uYW7kNvCRs5QpmhDI6CkVPHuaOKTqsBTj/CeGQ6xmLpamIf5BY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx1gsuOd9YeC3pEIYbbPsVIYKNCJ/hb/A0qcpo3PZbVekkm1RLQ
	8EtXB23WLpjV9lUAu8yxjIiL5iq9yT+kfb3gwTI7kElgTsE3FxamaRB2pR2P0bGjVg==
X-Gm-Gg: ASbGncviwuODmaK3os/znj6W0VX0coqjWGKJQsgfW9EYezZO8OUqls1E5i2ctYF1EwL
	LDwjBXz9ze3S0i6D5u60tmMNQH6dUC1ixxQFsaXk638weVO4LtvZf3QlHY6Yku51sCOJfFsV05t
	Z7VZkXxCSBB5u8hHv/hN4yyIKL1eZOmVRC/MUlSHhU5CeMd9OYHc1NpIzXa+NMTn7KdyjKWXA/b
	O5lQWnZVh3Ad0Oz4xa/POVSvSJVgr9zBFnhIPQeki3iEnjv1h4iXy3eKdAuctpsuZ7735l6qB95
	NmsRgoHsScK5jgUUFjY8EwdbPFsUOLEXe6wMXa+BYzh7zUwajGV/A2LeQGUHGw719Oo8kKSf6P0
	axKoDEXjHIkP9vtF4PJF2VOd6x3REnYVhjzQd9J0uxcszt2ZFjzouamAOgkLQDkzxlv0TDrJY8R
	zA+g1FL9M9FeBf4efNaw==
X-Google-Smtp-Source: AGHT+IHNCAse2nLu2lgUtDgDErKBK9yqKMEXuusRKDNyJ/cAuMSzxpT0xHeUrM5wLhnShSc680Juuw==
X-Received: by 2002:a05:6402:2102:b0:620:e309:6c67 with SMTP id 4fb4d7f45d1cf-62376d2c9b6mr17463096a12.2.1757602344915;
        Thu, 11 Sep 2025 07:52:24 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 16:52:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 xen-devel@lists.xenproject.org
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 13:53, Alejandro Vallejo wrote:
> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
> by the device model. The GPE handler checks this and compares it against
> the "online" flag on each MADT LAPIC entry, setting the flag to its
> related bit in the bitmap and adjusting the table's checksum.
> 
> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
> reaches 128, even if that overflows the MADT into some other (hopefully
> mapped) memory. The reading isn't as problematic as the writing though.
> 
> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
> then the bit where the "online" flag would be is flipped, thus
> corrupting that memory. And the MADT checksum gets adjusted for a flip
> that happened outside its range. It's all terrible.
> 
> Note that this corruption happens regardless of the device-model being
> present or not, because even if the bitmap holds 0s, the overflowed
> memory might not at the bits corresponding to the "online" flag.
> 
> This patch adjusts the DSDT so entries >=NCPUS are skipped.
> 
> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")

The code in question originates from e5dc62c4d4f1 ("hvmloader: Fix CPU
hotplug notify handler in ACPI DSDT"), though. Before that there was a
different issue (as mentioned in the description).

> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -239,7 +239,8 @@ int main(int argc, char **argv)
>          /* Extract current CPU's status: 0=offline; 1=online. */
>          stmt("And", "Local1, 1, Local2");
>          /* Check if status is up-to-date in the relevant MADT LAPIC entry... */
> -        push_block("If", "LNotEqual(Local2, \\_SB.PR%02X.FLG)", cpu);
> +        push_block("If", "And(LLess(%d, NCPU), LNotEqual(Local2, \\_SB.PR%02X.FLG))",
> +                   cpu, cpu);

Don't we need to use \\_SB.NCPU here? From the other two uses it's not
quite clear; it might also be that the one using this form is actually
needlessly doing so. Yet here it may be better if only for consistency's
sake, as the LNotEqual() also operates on an absolute reference.

The other thing is that I'm not fluent in AML operand evaluation rules.
We want to avoid even the read access to FLG, and I'm unconvinced And()
will avoid evaluating its 2nd argument when the first one is 0. IOW this
may need to become a 2nd "If".

I further think that strictly speaking you mean LAnd() here, not And()
(but the above concern remains; all the ASL spec says is "Source1 and
Source2 are evaluated as integers" for both And() and LAnd()).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:04:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:04:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120388.1465340 (Exim 4.92)
	(envelope-from )
	id 1uwiqF-0000pj-9m; Thu, 11 Sep 2025 15:04:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120388.1465340; Thu, 11 Sep 2025 15:04: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 1uwiqF-0000pc-6O; Thu, 11 Sep 2025 15:04:07 +0000
Received: by outflank-mailman (input) for mailman id 1120388;
 Thu, 11 Sep 2025 15:04: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 1uwiqE-0000pV-9j
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:04:06 +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 8efe49ef-8f20-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 17:04:05 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-b04271cfc3eso107013666b.3
 for ; Thu, 11 Sep 2025 08:04: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-b07b32dd0fdsm147535466b.50.2025.09.11.08.04.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 08:04: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: 8efe49ef-8f20-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757603044; x=1758207844; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8iCpDT/tx/mro9DOysbu9Xqq5zQA2MGoutiWSGpk8mY=;
        b=CZtS2Q7wce/dL3ZOp2YA1hLY96loQjbauPap8iq7UxuB6x2Yaqh2D/FYe06cDWTNc2
         KeYdSk6uvPpEiQj/kzpTpiyrrvqS5IZ739L9YZfJaOQQArh+af5vht9pUdpaDILNVGYJ
         GmBeXgywinqbk4P2qvp0EKcWhuhOftdLXw5slvwOZGsnnzdZlz6HeN2iX81cboO0Lvh6
         45lvCnH7Bh/iM2HCHpc5m1pj07N8+/5qZ5tvjHUzea1oAduSLgl0z+2amplUVemjCJe+
         RAGP7DgJJeP72s4iIEaD6z0gdsDOEfdNHihL3DtzeoHgzhNyfQdXRZvmoAMsd1tHoIdn
         wUYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757603044; x=1758207844;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8iCpDT/tx/mro9DOysbu9Xqq5zQA2MGoutiWSGpk8mY=;
        b=FEs6RNS2X6A5sViDH5z5UgvHuwZdzHh7b9IxSAx2V8xspD0b5fXMmCTWWB7+Rc5Caf
         16HuKGgMl9CJNVK8YPQRTzX62xsP2RWHSlvQKaI8HsLMgHeGr/HI2KOWYSykvPTqx5TF
         6RD/DX3I20wiAfiwn8Dx8tmx3cQeVATV5gnHBv/UATN681rLe5FLpfS+Yk13Fr5V9bNy
         rx+WkfEZx3sanI9N57tNrsrNGDZ2dXebCcHWX1fQWeykPhUTHlsQh2PTm2OJQeomiGLp
         qDkuFG9nrheX4meHPh7bKFi9Ba29jWox5aMvOZxN8s8r1Wy83cBdepvYcXDFOPUD+JMs
         tPzQ==
X-Forwarded-Encrypted: i=1; AJvYcCXWtPDJFvxDAtCdTyDqvzKwKwpvXss/VUiy/0Y1QVvn22AWPkcX6sxceKDCCgQkaRiZ6iAAQi09/FI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzhXjXM8c3KWHSmHP9EUzS6Hqpc+k2o1dbfGL4G56LFyNhfVjcL
	RK5xseLMJ8ts88v2qIKYbs+/l01lbTMPNIG/J86nT+4eo6F7zgDKmqAIBG5pFxSC+Q==
X-Gm-Gg: ASbGncsV7ZvPXzuqkVDYzsd7wgfhePHBfnK1X7/PESjos3FCLCrSA3PScbpRvyNBbxd
	mehcfTb9TbtgnAWpWdoZCXesKtTIFfLcY1mX/5abZqqelSfsQW4EpWnC/2u+EWSGIdZGn0dtkBw
	9eJ6N0hOtLM5CaCEqpqxnXOuAtmuMcwGEo9bnt/nso39/5bT1OzTLn14wtKdb9kXnhQgQcSWKAO
	P4372R3mojGrGmE/lB4whoSwNo1Z99DRH15FREB5Jq0XtB9Bxv+kctYWdzfy1ldGStaaqZQqoXD
	xVWgVR3VXY9Djp0UHRIdGKlrk2jUHSGIsVG282i/q8sy8WkG8K16p9ygjJ7RDQuYKHnmXO11Y/R
	8aPEuRvREWCpyedkvPZzFAth54em0n/SNl28MAkqD2WPyGXAkMLewYAMsRClCeNfu2MOHhiTyqj
	D0LuWukhnj+tnobEbDrOZPfjKB3F6H
X-Google-Smtp-Source: AGHT+IEwIj+hPkJpYoCFpJxg+pnZeko3tkv0RfVYId9ciB4q1ML5W+3jNfQKqj0C1ezJeRwIDfWt/w==
X-Received: by 2002:a17:907:807:b0:b04:7a92:c7cb with SMTP id a640c23a62f3a-b04b1687dc3mr1807994366b.37.1757603044310;
        Thu, 11 Sep 2025 08:04:04 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 17:04:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Andrew Cooper ,
 Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 xen-devel@lists.xenproject.org
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
 <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@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: <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.09.2025 14:03, Andrew Cooper wrote:
> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>> by the device model. The GPE handler checks this and compares it against
>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>> related bit in the bitmap and adjusting the table's checksum.
>>
>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
>> reaches 128, even if that overflows the MADT into some other (hopefully
>> mapped) memory. The reading isn't as problematic as the writing though.
>>
>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>> then the bit where the "online" flag would be is flipped, thus
>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>> that happened outside its range. It's all terrible.
>>
>> Note that this corruption happens regardless of the device-model being
>> present or not, because even if the bitmap holds 0s, the overflowed
>> memory might not at the bits corresponding to the "online" flag.
>>
>> This patch adjusts the DSDT so entries >=NCPUS are skipped.
>>
>> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
>> Reported-by: Grygorii Strashko 
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> Half RFC. Not thoroughly untested. Pipeline is green, but none of this is tested
>> there.
>>
>> v2:
>>   * New patch with the general fix for HVM too. Turns out the correction
>>     logic was buggy after all.
> 
> Hmm, this does sound rather more serious.  I have a nagging feeling that
> until recently we always wrote 128 MADT entries.

Not exactly recently, but looks like that's my fault then: 0875433389240
("hvmloader: limit CPUs exposed to guests").

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:08:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:08:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120402.1465350 (Exim 4.92)
	(envelope-from )
	id 1uwity-0001VK-O7; Thu, 11 Sep 2025 15:07:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120402.1465350; Thu, 11 Sep 2025 15:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwity-0001VD-LX; Thu, 11 Sep 2025 15:07:58 +0000
Received: by outflank-mailman (input) for mailman id 1120402;
 Thu, 11 Sep 2025 15: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 1uwitx-0001V7-OY
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:07: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 18736faa-8f21-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 17:07:55 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b0472bd218bso144477366b.1
 for ; Thu, 11 Sep 2025 08: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
 a640c23a62f3a-b07b3128a5csm150603666b.37.2025.09.11.08.07.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 08: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: 18736faa-8f21-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757603275; x=1758208075; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=D15V0iG2MZ0Z/AwcKFpgky46QGXFGdQ+EP2jUIV+Wb0=;
        b=eOD9XlnTHr94tjuJG8LIIqBubxiBkGTTYBPfGMZD1S4Obehp2DGd8UeSxjaurlD0sS
         wB7WYVhoeQkyPRMTsJXWcLe/HUZYkw8+PR0Bw/Qwfo5MAsrqxAkMMabIRSGLphvlgFqE
         0cR7lF6K7wbu7wLnB69Yqqr1GEx+2Si+a/fxqIpY6V3CD0oJuJRH5TqbgyfXAR7X8xli
         cmrlvEykmgJ/UOlhDyOAHXOuV0pf+Xyx3uz6HOIbKOSN2Eab2yWRLea9pT6oRpwIPkQg
         R1srLtTu6lUGNCllKesr0qJQO9y8XUJsZ6hbLea3oX173y6k6eCwp8ZB4WmFsOPTo91Y
         eh/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757603275; x=1758208075;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=D15V0iG2MZ0Z/AwcKFpgky46QGXFGdQ+EP2jUIV+Wb0=;
        b=sbiobsEYqDSRp7KrD9vH3n/pnvwp1+XcEDzwt3OAffXeTWcR9MoGIJwzlEgD4p0hjR
         vShmGi33PUgsBSsqO5JIbqgFBeeMB+LP3SzYFYyLPGBKNusmqSkg6jpAs2qh6LorMvo5
         PftpxvsLzow789rsCuiSvnPoKIWanrYMYlUEq/apYvmZ5HLb4SB74UI+pZqSx4ieT7uC
         HdXQkD1eWijuh4xYUDl6V7tKpNQednNx7pR26Knhsw607IoifoSaDrp9NazGvpqNqz7J
         w79iHFJcgBZskgt4ZTMMMhNhm7IdECoW5LNHW6BGCYoOIB7DzeW870zMWqED4pACo1HE
         Y5Ew==
X-Forwarded-Encrypted: i=1; AJvYcCWs5GCmitZ7thhIz1bkJxUPkmEGbZfbXWmqL3Z4edFJzR6boBvOmnPJaLwkgX0eWRayafEkbs50F5o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxuyW4B2hAybsPFPM+VsVgRVyl52i83p9078RTYbbNAYYhQPZ4C
	MEoXZ1GtYDIatgDxeF43NZmooD3EQwhz7ZyiiDdzdnlEcWKqdxQ0XEaqNhBdWUCeRw==
X-Gm-Gg: ASbGncudtQFGYog5S2kGqa3g7+90qXDjZM0LYXZOc7lfeJ/9zYOvfz5zKcbkiFLV4rS
	TzBB8U0YMuqIfrkVSObzaiYLYSlrzIXUphuLoi/6xR0knEJtsHa6lRyhp8WNgpNjTJjwxgdNqrn
	ENqd0xJC0V/SvijTWBFQPRuk2NPtuZszg7ViY2G0Q0BpRtPe4gnbw3YJrAghPBTv4IrC9+5Q/tY
	RlpdzJAj2rv+iWlOBp/iDXa4tfCb5WgmuMdOdxUvdiy15h74YRJq7QbS4R3HhB+c+osdqp7M7Gz
	LhJhLo/JariWVLK1LIlTevDZock4Pav0Uv+lq5cuFb4fbaYd6sEqyjtKk7mvMk3aUMCf6VxYMY5
	IcmRJ0ciWgo2Zcf0TGst9TQk/WwfBAeAjmELxALHOapCqCShyDCJA3oAwtkj2BD0k4Kl/AtE/+9
	kREg6qVwsvngU3DcOYXw==
X-Google-Smtp-Source: AGHT+IFjZqJVmgqgHemcJZQq4tHzj5mw/hBJGKQ/o2zPwesmJRplaY6EhAf31Dsych+uasVHMj4Heg==
X-Received: by 2002:a17:906:dc92:b0:afe:9e58:754d with SMTP id a640c23a62f3a-b04b1714a6amr1818246266b.64.1757603275014;
        Thu, 11 Sep 2025 08:07:55 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 17:07:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] libacpi: Remove CPU hotplug and GPE handling from
 PVH DSDTs
To: Alejandro Vallejo 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-3-alejandro.garciavallejo@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250911115308.16580-3-alejandro.garciavallejo@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 13:53, Alejandro Vallejo wrote:
> PVH guests have no DM, so this causes the guest to fetch the online CPU
> bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
> 
> Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
> the GPE handler in addition to anything ACPI CPU hotplug related.
> 
> This shrinks PVH's DSDT substantially and prevents spuriously executing
> a large amount of AML with no purpose at all.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Jan Beulich 

> ---
> v2:
>   * Adjusted commit message
>   * All other tags except S-by moved to patch 1.

This will want backporting; I expect finding a suitable commit for a Fixes:
tag is somewhat difficult.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:11:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:11:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120413.1465360 (Exim 4.92)
	(envelope-from )
	id 1uwixG-0002yS-6V; Thu, 11 Sep 2025 15:11:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120413.1465360; Thu, 11 Sep 2025 15:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwixG-0002yL-3j; Thu, 11 Sep 2025 15:11:22 +0000
Received: by outflank-mailman (input) for mailman id 1120413;
 Thu, 11 Sep 2025 15:11: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 1uwixF-0002yF-4P
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:11:21 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90fedb2e-8f21-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 17:11:18 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 40E717A0316;
 Thu, 11 Sep 2025 11:11:17 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Thu, 11 Sep 2025 11:11:17 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 11 Sep 2025 11:11: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: 90fedb2e-8f21-11f0-9809-7dc792cee155
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=1757603477; x=1757689877; bh=Op
	BV2oIANtjlUKd2RvH8eUWtuy1HmwEUDQuIs61cuGk=; b=G453LlSFIk2lR+OVsi
	A0BvzRcYK9kO15aqEBKIYjK0CKA5Hh9OG/nV6Hllr8pE+a4wiLeVsIfB8DbXCPMS
	ajAXpOlYoal2J7GomN9Q2ozhu/kgWWL7e8rfKbD6YKarpEZ3wDfGOkc0Znri6Bj7
	hFgemAZw355EN2LQX50oKaSFvErB8/JRJ2/k844iMBvMXFso3bGXA2PtgWmAEddr
	2hqcYsbHbvXrLmgoIrFfQGTUaw/VofPzxjH9K/BUmljWGOv72ou6AcqWyziSY34Q
	wNEWtIAA95AKN9qmPv6RPMoNmeEtN0e1ZNB8kHoQPBq/yslcLIcKpHsalE0Nl6/E
	lxDQ==
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=1757603477; x=
	1757689877; bh=OpBV2oIANtjlUKd2RvH8eUWtuy1HmwEUDQuIs61cuGk=; b=P
	SteqXSoNJOR5oo3TjOUB8hS/qduXgkPT3cDSMMwfpqRuo4BLL1wWauvUcm32wN8X
	b5DW8bCgF+4OIlQjZsEG0nQAQCieqrFSlNGWv7TG8zoc/FNc9csay2P6dzDbPucO
	82D3wZ9BfDOTbl+gI/u1iFR10cEB5Dq8FIMDX9QYnb4MtXioY8xosIRCjzx47QNp
	qnVBKnUSF6U0msnk6V4tIkqpVnL9nPVWK3y614saLfuqvnrGeqTIkXWIz9fR4hpv
	/Cpj1t174tOMKTrE6RxwBIuf39dQ2Ew/J0A8fuoub9OIvffhk1kgkgLPjrET1Pee
	s0zGT2orMkHOAVCyuoh5g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvieeglecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkgggtugesghdtreertddtje
    enucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceo
    mhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecugg
    ftrfgrthhtvghrnhephfetuefhiefgtddtlefggffggeevhedtvdefffeugfeiieeiheef
    teefgefggeejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghruf
    hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhi
    shhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohguvg
    epshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghn
    phhrohhjvggtthdrohhrghdprhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 11 Sep 2025 17:11:14 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Subject: WARN in xennet_disconnect_backend when frontend is paused during
 backend shutdown
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="x55zhp3nHLq16CA6"
Content-Disposition: inline


--x55zhp3nHLq16CA6
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Sep 2025 17:11:14 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Subject: WARN in xennet_disconnect_backend when frontend is paused during
 backend shutdown

Hi,

The steps:
1. Have domU netfront ("untrusted" here) and domU netback
("sys-firewall-alt" here).
2. Pause frontend
3. Shutdown backend
4. Unpause frontend
5. Detach network (in my case attaching another one follows just after,
but I believe it's not relevant).

This gives the following on the frontend side:

    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 141 at include/linux/mm.h:1328 xennet_disconnect_b=
ackend+0x1be/0x590 [xen_netfront]
    Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd=
_timer snd soundcore nft_reject_ipv6 nf_reject_ipv6 nft_reject_ipv4 nf_reje=
ct_ipv4 nft_reject nft_ct nft_masq nft_chain_nat nf_nat nf_conntrack nf_def=
rag_ipv6 nf_defrag_ipv4 nf_tables intel_rapl_msr intel_rapl_common intel_un=
core_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class =
intel_pmc_ssram_telemetry intel_vsec polyval_clmulnighash_clmulni_intel xen=
_netfront pcspkr xen_scsiback target_core_mod xen_netback xen_privcmd xen_g=
ntdev xen_gntalloc xen_blkback xen_evtchn i2c_dev loop fuse nfnetlink overl=
ay xen_blkfront
    CPU: 1 UID: 0 PID: 141 Comm: xenwatch Not tainted 6.17.0-0.rc5.1.qubes.=
1.fc41.x86_64 #1 PREEMPT(full)
    RIP: 0010:xennet_disconnect_backend+0x1be/0x590 [xen_netfront]
    Code: 00 0f 83 93 03 00 00 48 8b 94 dd 90 10 00 00 48 8b 4a 08 f6 c1 01=
 75 79 66 90 0f b6 4a 33 81 f9 f5 00 00 00 0f 85 f3 fe ff ff <0f> 0b 49 81 =
ff 00 01 00 00 0f 82 01 ff ff ff 4c 89 fe 48 c7 c7 e0
    RSP: 0018:ffffc90001123cf8 EFLAGS: 00010246
    RAX: 0000000000000010 RBX: 0000000000000001 RCX: 00000000000000f5
    RDX: ffffea0000a05200 RSI: 0000000000000001 RDI: ffffffff82528d60
    RBP: ffff888041400000 R08: ffff888005054c80 R09: ffff888005054c80
    R10: 0000000000150013 R11: ffff88801851cd80 R12: 0000000000000000
    R13: ffff888053619000 R14: ffff888005d61a80 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880952c6000(0000) knlGS:00000000000=
00000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00006182a11f3328 CR3: 000000001084c006 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     
     xennet_remove+0x1e/0x80 [xen_netfront]
     xenbus_dev_remove+0x6e/0xf0
     device_release_driver_internal+0x19c/0x200
     bus_remove_device+0xc6/0x130
     device_del+0x160/0x3e0
     ? _raw_spin_unlock+0xe/0x30
     ? klist_iter_exit+0x18/0x30
     ? __pfx_xenwatch_thread+0x10/0x10
     device_unregister+0x17/0x60
     xenbus_dev_changed+0x1d7/0x240
     xenwatch_thread+0x8f/0x1c0
     ? __pfx_autoremove_wake_function+0x10/0x10
     kthread+0xf9/0x240
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x152/0x180
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     
    ---[ end trace 0000000000000000 ]---
    xen_netfront: backend supports XDP headroom
    vif vif-0: bouncing transmitted data to zeroed pages

The last two are likely related to following attach, not detach.

The same happens on 6.15 too, so it isn't new thing.

Shutting down backend without detaching first is not really a normal
operation, and doing that while frontend is paused is even less so. But
is the above expected outcome? If I read it right, it's
WARN_ON_ONCE(folio_test_slab(folio)) in get_page(), which I find
confusing.

Originally reported at https://github.com/QubesOS/qubes-core-agent-linux/pu=
ll/603#issuecomment-3280953080

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjC5pIACgkQ24/THMrX
1yzJJQgAmAjqLnEPVaJSeYfoos6u0fhu2ziAdmtCzMkQEEAsbcozZionCqKy2Tzy
uF0Db7aLOiG9P/WXLwIaaZQLQ3kOHQbvcJsL5z7onFgbsisQFAB27QKC4sk4R2sB
/de4lxFGxutRmpl15q5RvyvBybcjBmw9qKGWTjBbwBOYOvVMPkSQivFOgPuCaQMd
+UkdMtEBsUDBvw7dWSxMoKIWGDOvJY9pIs2GvMm0ErtYFfAT84WqZELozQvJ2htI
P7eupj04AZZbiFaMn7Mu7htOBEC3QVxfzA13k86DLRetat4fCfrz5EE7FMGmqylG
Ms9csQwCERXFiI5oa0Ql8/d6WpK8Hw==
=Eqh1
-----END PGP SIGNATURE-----

--x55zhp3nHLq16CA6--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:16:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:16:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120429.1465370 (Exim 4.92)
	(envelope-from )
	id 1uwj2R-0003fQ-T9; Thu, 11 Sep 2025 15:16:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120429.1465370; Thu, 11 Sep 2025 15: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 1uwj2R-0003fJ-PR; Thu, 11 Sep 2025 15:16:43 +0000
Received: by outflank-mailman (input) for mailman id 1120429;
 Thu, 11 Sep 2025 15: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 1uwj2Q-0003fD-8u
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:16:42 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20602.outbound.protection.outlook.com
 [2a01:111:f403:2413::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4fe38335-8f22-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 17:16:40 +0200 (CEST)
Received: from SJ0PR03CA0202.namprd03.prod.outlook.com (2603:10b6:a03:2ef::27)
 by MN6PR12MB8541.namprd12.prod.outlook.com (2603:10b6:208:47a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 15:16:35 +0000
Received: from CO1PEPF000044F9.namprd21.prod.outlook.com
 (2603:10b6:a03:2ef:cafe::7f) by SJ0PR03CA0202.outlook.office365.com
 (2603:10b6:a03:2ef::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Thu,
 11 Sep 2025 15:16:34 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CO1PEPF000044F9.mail.protection.outlook.com (10.167.241.199) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.0 via Frontend Transport; Thu, 11 Sep 2025 15:16:34 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 08:16:25 -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: 4fe38335-8f22-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tDy52fDZFwBcin+hvN1bWOq31Tj8L3Y/q4odbDhub/Rz+9cansWh6QkwvJQ8S033CHBI9Y7Br3jqJZ8pXR/2gRfL5AxYJqLnJHBNWcGbTJk3QpQaLnaXUeqE2uvWOI5EoOlsHsP0BAlsAwvfnAdHT99VSkAucy3dnBBLP0a/meKswO9O49RedrNWYJsMjh8ROFJqQBkPCzc8tsyhhzR8RsK+9UGAfxe2gCsJN5EPTlRM0EOZXM4wFJu/3NL2yJ5xl2/WJTzh0werl4Bjv9iWPT+ia4IGnIPIPl0gJozROA8jMYEFUYH7ae7HWUdZnSsj32iKolTHzN/QsXH5yF5ySg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XtZeKBnVGG3y7WD0wOdYIDiDdz8Dd88mQrLv83KFryQ=;
 b=XeLjQdSyC/S77kKIvcZANjD9QjOR3Uy9gztNICm7LbxTWPsKZqUJP8E5pz9Qw7D96gBnMuiYjkd73mOCJbh9+Zq63J6dy7XUA75cxAor756dFFITOyOocoA1M7JcgtSGi9/PjGLk+17Cv7emjoCz3A+0c+/lHemsFVtioTkIXcixVYow22AY/Ms5zT/4L4TB7NQ6aaZvdJPZ4d+ZU3iQtEP3illz8BJIjXFxMoC6MOEmrYvhHiVD96R2+o4sjVHDTiVev22rwP8XWCG1P/4PP7xLVQILq2sKnLl3LeE/YgjR0RSeeMK8PGf5kjG4ZKkI8s1ekv94VbLZMP2Tut5Otg==
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=XtZeKBnVGG3y7WD0wOdYIDiDdz8Dd88mQrLv83KFryQ=;
 b=kDAQWR2Sk1PeJnUrCaGPG8JmW7Q3a4K57FbPcNtUGctIZxZ0ZrtNNL4hvvwjtTJcIy9AS7Kc6h88P/bu8ktYa5M/qQvgq6R0d7Elc4t1JWdTOJWtxiXF5/gVyDF7hZKdCndeXXywj8QygRdZ7x7h0QVm/KRc4mGrA2AOJ8kTK+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=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 17:16:23 +0200
Message-ID: 
CC: Anthony PERARD , Grygorii Strashko
	, 
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
From: Alejandro Vallejo 
To: Jan Beulich , Andrew Cooper 
X-Mailer: aerc 0.20.1
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
 <42bf6ed7-3a6b-4021-9a53-1891117ff2ba@citrix.com>
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000044F9:EE_|MN6PR12MB8541:EE_
X-MS-Office365-Filtering-Correlation-Id: e379a1c0-8abc-4bdf-1e17-08ddf14631e4
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?dkY0RWQzYzN3Zm9ZbWtpU0pTQ3RDdGYwaEQ2SFZycWw5Y3l1b1NXbWxLMEJv?=
 =?utf-8?B?TnBXQXo5Tmw2ZVBrVytNTHJNMktHbjVOM0hSVGRUbTJKVHBFS2Q2QVloVmNX?=
 =?utf-8?B?NlRISEdlY1lpT0c4S0ZhSENxQzVpNlJtU1REcm85NVVtd1dhOTY0Y2phN0dN?=
 =?utf-8?B?RExZMGJJSi83OU5idDlrbjMvZXFIaUtITnFaNkp0VkZTYnowV1IzV2piZHNP?=
 =?utf-8?B?eTMyc3hadm1MMlNKUnNkOGQxMVRqZjkwSzJ2Zm5ERGxpY3hnQ3hWNnFkMkIr?=
 =?utf-8?B?cWI0ZGlTeVJ4ZEdhd2p6aWoza253NXRtWkkzU04vZVBVR2hpNXF5bmlnQWI0?=
 =?utf-8?B?UjdhQ2dnQVdsbHVjRzE2a0UyUWhKa01XSEZYM0ZWK0RYb2QrZjBJakZXUWF4?=
 =?utf-8?B?dXZDaUQybGpQUi9FKzUxOFM0dzlrSHpuOHA1aDJUYnBQdG5pNmx4cWVyeE1x?=
 =?utf-8?B?dmZLL1ExQmRtT21xbVY4NEFQaWljYWtMNVNCSlNRQlVhbk5ZbnFMdzVyZ0tn?=
 =?utf-8?B?ZWVraUgzZGttWmhGV2xMMENhRjhIOEZuc2lodk5SUzBJQ1BCbGVrcXR3UHFs?=
 =?utf-8?B?MGtHMkljQTZsQ3EzZ29INkdWaE9oWUdOaUJORFZ3V2VyZUpyMzRxcEtnbnA0?=
 =?utf-8?B?c1hSYzZaV2hmZnZrL21iTzBpeTdQNjRGbHRONFhRbGt3U2VwcVk2T09ZK05H?=
 =?utf-8?B?UU9pRjd4R3FhbmxEenhoRnFmVU9Yd1M1V3A3c0IrcGNkSEhHWVJpWGRZZGwr?=
 =?utf-8?B?TWNwUEZrWG5oUmMzVXRvdGsvaENWemhkQW4zWkNCNnhieC9tMVdRaW1kY1lV?=
 =?utf-8?B?c0hqbkdSZFFRWXh4VDhtR1dqVktrWm1SbkEvNzBGdk11U0pFeW11NnN0Rk1K?=
 =?utf-8?B?cmV0aFBZTExKelpoYVdqQ1lDZFdHeW5pbHNDQ0htYUxzZmdTRTNjZlZ5cUZE?=
 =?utf-8?B?bEFLS0VRUlRrZEk2L2p2RWR2N1VabDd1citjUnpJQ3g2RkVJU1BkNzVRVXMy?=
 =?utf-8?B?aVZEWlU0aW4wYytSMGxoOHZuSllxSjVtRkNnaVMyZVlxaEZHd0tKeDJvMVJm?=
 =?utf-8?B?ZlFKTnI3ZUJoaDhqWTQ0QU4waUxMNkQ0bDR3d001NHVWTG1JdFU2akptRDdr?=
 =?utf-8?B?L3lURTR0UWZLaEFubzVzL0s2WGRWOXBiWUh6YVpocnVCTDhINklvdzVHQjBC?=
 =?utf-8?B?Nm5ta0lRdGVDVU1KQW9keU8vTnhpSEg1N1phUGduaml6Q3hVSGhxYXRFWTJN?=
 =?utf-8?B?SUR6MEsyOERYYTFUSTUyUlF2aFB6N3h0cU13bDdOQ2lJaTRZUStMbXhSZlFy?=
 =?utf-8?B?clAvSEFzVGhrKzNFVWZSK2NUS0ZDT1R6NjFBWHliWHdPa0N6bEVBU0E3a29n?=
 =?utf-8?B?ayt5a0VyMmFSanRUVVk1NnFmcmQ3TTE1WTBGZFhseVlNaHlSVUliVDQwTFNB?=
 =?utf-8?B?V0s5cWpkSFhySWFnWDNBazhTSzFsZEdLVHcvSVd0T2lCYTBnZmVZWjMvYlZj?=
 =?utf-8?B?bGtYWm80cVJ4VUdKYU9FVTgrOFBQTzZNN0lQK1Y5MjZZUVFMVGJRei9ybito?=
 =?utf-8?B?aTUrdFU0MW1LZWlMc1NaY3N0aDc5cHlRRWxsS1grSC9PNjhHS2pHT3dZYkR6?=
 =?utf-8?B?cXV2V1d3OFV2OHR6TDM2TVFsL3M4VDlMNWpRek5YSTFwaUE5NktSRzFWem03?=
 =?utf-8?B?WnZYR0J6MnZPVm0yb0FGWlQ2RWpZOERxNEpmSEFBaHBMbHdTRnpkVGZRenlD?=
 =?utf-8?B?SkdlT0JaZmpJcENRQU14OWFkRGp6OSt4MnRVNGliQm1aaE16elVHM1U2M3hk?=
 =?utf-8?B?YUhjVDRaQzE0TjY0Zko5Q3Vldkd0dGhOTkx4ck5PUDJES1B0TWM1ZytXbHV2?=
 =?utf-8?B?ZkNndlU0YTIvUUdpRzdETW5QM0g5NTNHdFBrbUEzOWlJNVlPMjZKN2NoUlpD?=
 =?utf-8?B?YXpUWi9DcUtLN0FPb1hvaVI1OURORE4zdEVKVG9sTFpuUWx4QWhWWVBoblph?=
 =?utf-8?B?QnVGYzFLNmJOdDE4cjhrZjE4M1ZkQkxLRWVqUWxPSlNQVDN0WFhsVFhtanZW?=
 =?utf-8?Q?s2Y4n+?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 15:16:34.2180
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e379a1c0-8abc-4bdf-1e17-08ddf14631e4
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000044F9.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8541

On Thu Sep 11, 2025 at 5:04 PM CEST, Jan Beulich wrote:
> On 11.09.2025 14:03, Andrew Cooper wrote:
>> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf0=
0
>>> by the device model. The GPE handler checks this and compares it agains=
t
>>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>>> related bit in the bitmap and adjusting the table's checksum.
>>>
>>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until =
it
>>> reaches 128, even if that overflows the MADT into some other (hopefully
>>> mapped) memory. The reading isn't as problematic as the writing though.
>>>
>>> If an "entry" outside the MADT is deemed to disagree with the CPU bitma=
p
>>> then the bit where the "online" flag would be is flipped, thus
>>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>>> that happened outside its range. It's all terrible.
>>>
>>> Note that this corruption happens regardless of the device-model being
>>> present or not, because even if the bitmap holds 0s, the overflowed
>>> memory might not at the bits corresponding to the "online" flag.
>>>
>>> This patch adjusts the DSDT so entries >=3DNCPUS are skipped.
>>>
>>> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure..."=
)
>>> Reported-by: Grygorii Strashko 
>>> Signed-off-by: Alejandro Vallejo 
>>> ---
>>> Half RFC. Not thoroughly untested. Pipeline is green, but none of this =
is tested
>>> there.
>>>
>>> v2:
>>>   * New patch with the general fix for HVM too. Turns out the correctio=
n
>>>     logic was buggy after all.
>>=20
>> Hmm, this does sound rather more serious.=C2=A0 I have a nagging feeling=
 that
>> until recently we always wrote 128 MADT entries.
>
> Not exactly recently, but looks like that's my fault then: 0875433389240
> ("hvmloader: limit CPUs exposed to guests").
>
> Jan

Very right. I got to that commit, but thought nr_processor_objects would ma=
tch=20
NCPUS. Wrong assumption.

That sorts out wich fixes tag to attribute this to.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:32:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:32:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120450.1465379 (Exim 4.92)
	(envelope-from )
	id 1uwjHR-0006c3-3N; Thu, 11 Sep 2025 15:32:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120450.1465379; Thu, 11 Sep 2025 15:32: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 1uwjHR-0006bw-0s; Thu, 11 Sep 2025 15:32:13 +0000
Received: by outflank-mailman (input) for mailman id 1120450;
 Thu, 11 Sep 2025 15:32: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 1uwjHO-0006aJ-T7
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:32:10 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20622.outbound.protection.outlook.com
 [2a01:111:f403:2417::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a6dd684-8f24-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 17:32:09 +0200 (CEST)
Received: from DS7P220CA0010.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:1ca::8) by
 SJ0PR12MB5673.namprd12.prod.outlook.com (2603:10b6:a03:42b::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 15:32:05 +0000
Received: from CH3PEPF00000012.namprd21.prod.outlook.com
 (2603:10b6:8:1ca:cafe::b4) by DS7P220CA0010.outlook.office365.com
 (2603:10b6:8:1ca::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.17 via Frontend Transport; Thu,
 11 Sep 2025 15:32:05 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9115.0 via Frontend Transport; Thu, 11 Sep 2025 15:32:03 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 08:32:01 -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: 7a6dd684-8f24-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Cfio6a7V2FBazFxUOkTs0mLztMOftOc8jYcdwmPPR3+O1cffTgArYTADqCRej2wIhXyXbIGGbW26G44e9BWD52RVJngpqi56jydfi59LykHIWChkPFXWT8abaDuCs4n4eu5RE6Pbp9kMYXwqgv3PZimr2EGZycFcHu8KtSAcRl5Ict7kM4HxEtskwyrTNG5UW/+UxJ1j1Bn5Q6WXL+QVf9M0qcEncTSmw2SnV/o6XYk4EBH/pHDgjzMsMp3EkzrAeWxPXX/BGfRBShepWJQzInGbymq1oao8FQhSR+E+ILwBTpk33Mv0maOwXIkEY9luMkY2UaKijmhWDhH8v8A3sA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zzoORT5Alnot4yZ8c1Uh06435a7QtoSb4OjfRU3o+QY=;
 b=vAIxN/NDzHuLLhZNKg0q26lSZQnOAhhmcew5WfjpaYD2h1KaP2ecxl0yKSBcJbx0WXy5Lp/KdufCZfKgPkKuEOCWMny8DFJc5B2dAdWS1ylcqXbkry6XYg6x1KwssuatfbCRmbnRlvmODx1CxiLxaSJWc5jxlzfSH5VGwHsmej7EKraqWW6QLuBWAiKhwufcBFjQsYjzQX4XH1rLHLqJhyDQqwWWNoC6jk9w8PeXh1KWklMfPu5N6ZqDH9kn2FFWFbLlwY3QquqcKAO1RM1UvTQBuHmaxavYgFdTAu98EztqS/rSUX3Xr8QPOaAWv64M/3vUeJG+w79ZYwzG7AgSKA==
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=zzoORT5Alnot4yZ8c1Uh06435a7QtoSb4OjfRU3o+QY=;
 b=jYZ0jYZr60rKlxwmthia7rKNB8reUVbS46lsiIhVff5+4rcUOGPH6hq6xPXG47tQttz61ZJvyyriv5yK3YhMbtBH/lRGn42Z8cjKJwlrt/0lZiNRFI92ApWKCRfD40CAKOeqUZaLshZ6omWr7VifPkNGJdszFNIizXyEYlhu0No=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 17:32:00 +0200
Message-ID: 
CC: Anthony PERARD , Grygorii Strashko
	, 
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000012:EE_|SJ0PR12MB5673:EE_
X-MS-Office365-Filtering-Correlation-Id: dd043868-72df-4e58-ac27-08ddf1485ba9
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?QlNzM3pjYUxoVm5RYlQ0cVlIZHhCNjZvV2hGeUV6SUI5NUJINUlldlNDbG9x?=
 =?utf-8?B?cXVEbURQL1ByVHBGdU5RNDIxSGRzemIzNTFEby9DK0JESUVPL2ozY0FBU1dC?=
 =?utf-8?B?N1BUREpqS0xyKzdsRjdOOHpPUzV2dnEzZFBRYndHZU9DYStSWjVGVjdJM2E0?=
 =?utf-8?B?MTkvSHMvdlg1cVAwM2RKRWl4SWJVSysxb3dBczU5Nm9XcVBnSHB4Z1A1R2xI?=
 =?utf-8?B?VFo0RjZLQVl5djBYNHdBM1V5cVhUMld4L09QRENvV05Kc2J6b0FqNzJkaHVS?=
 =?utf-8?B?US9MZWJ3Y01jZ0FrNjU2dktBT1ZJTndiWjdra3pVQ0hRV1VISWpETkZySGxU?=
 =?utf-8?B?aUpyY3dUclphcXE4UUNtbnF0VnRHMW8yV0VReTJsMmhueVhPZzBsVVprYmRC?=
 =?utf-8?B?VDByZkZVWUVZV2haUXhrb2hUSUd5OW1uVjgzd2NjaSt6Nis0T2o2dnVJem16?=
 =?utf-8?B?dWErSXhoaG5LSHVVZFdyWGdWSkxGOG11WnI5aWJRVTV1dmorbEpCWHZNeUtN?=
 =?utf-8?B?aHZZYW9JaE9YRUIvTkhWTGc3dldFUnVuZm4vTmZ5WFgzb01QYzQzODN2N2Fn?=
 =?utf-8?B?bE1KVStwSUFNMEZWbXIrOVYyTkJHWmVlRG83RmZwYjJUUlFUWFh3MWFOalA0?=
 =?utf-8?B?dmNENFpncXZXdFR5bmc4Y09XZW9ZWXlMQ0VYbXJsWm04NyttVjRtQ21MZ2R2?=
 =?utf-8?B?QWtxcVl5cWlGRi9iWXNMVW5mV3BNYmpaRVlxMERLOWJxUVhJNCt4eTFOOUFy?=
 =?utf-8?B?RC9qcmluQ2c2SVhrQlBnSWtsbWZac1ZINW1YZHhZV2taQmQxUExqd3djdzY4?=
 =?utf-8?B?WnZNalVaMnoxcGJ5ZGZ6TWE5Y2owUlY2R3AycnRNR2RtWU1rM1J1S2xuVVhU?=
 =?utf-8?B?bW93OVBiUmhTa2VKWHFXTFA4NHBsUnZSeG5tMlFFVU9BamhFcTBkVlVpSWhF?=
 =?utf-8?B?Zy9tSjhUTVkxUHJ6K05ucTF0UHRkQUZBZE53WkNWc2phejRjUGZrdDRsSmx3?=
 =?utf-8?B?dzFvb1loaGUyR0d6ZXdGaHdZc1JoSUgvUFF2YzlGQnVwVlhpbytIU2JBVTNi?=
 =?utf-8?B?WU5QNUxnK2RCM2d5SnpNM2lUTDlBVDQ2bDNCN005UmlBeG94K0hGUzBTYzY2?=
 =?utf-8?B?dGpacVN1eGdpeThLZnhzejZLOHlWYmhIMTVHMm1xMHV3QkJOSVEwbW41RG9B?=
 =?utf-8?B?bUp4ODB0NnBQWS9yaTAraDhncmNRYmVieXBzK2Q1SVZzL05va05CMkNRRFd5?=
 =?utf-8?B?VTR2Qnh4NWlwWjNnTW9xUkpuU0llZElFZmZ0U3pxV1pOS3FVRCt3YTNXVEhR?=
 =?utf-8?B?cG1NYlNEZXRPL2ZIdEtTekIwcVhOQ3J3dHUwcGMyd2VPaE16aUhSQU9jRXR0?=
 =?utf-8?B?cjg2b0tuanlNYUJqUEY4SEhMK3ZyVklSSlltSmd6d29aYjBMdkFSWmszRmV1?=
 =?utf-8?B?TDJWaFlTRXYrOFg3cHpBSjdPN0hyc0VLeDFlbTl5R2x4aHpyd2ZQYmNHc3dp?=
 =?utf-8?B?cDNPMDFhWEFRWjBEZ3NqQXFoYkpXZWR6dzlVbDc1bUxIZ25xTHg1dm1oTVM4?=
 =?utf-8?B?UVZWeW5OTWdiM2NORVRCOFpEU3JxUDczczlQR0VyV093a0NqZGNWeG9KS2Fn?=
 =?utf-8?B?U3ZPRzlwVmVGWmQrcklpaDNGZS9nVEdZaHJjOHl0aW4xUHdFMEVlbnlPWEtL?=
 =?utf-8?B?LzB3d1cxYlZqdnU5OUJWSFVyaTg5bXhZTE5tYmxDY3pGMzZOa2F4TVlsTDRz?=
 =?utf-8?B?a0xRY0E3dkNDNmg0V3dWdW1PdWd2eGV1d2dZcjdycks0ZHlBMVRmUzlGV1VE?=
 =?utf-8?B?U1c2b2VOTkNWY0F5MGhzanFsS3JuQ0xzNGVpb0FSUU1laExwVm1aZWl0eWdZ?=
 =?utf-8?B?UGJraUFzaytHM2FVWXlTc2pCK0lheGdVQWJWMkgxWm9TUEt1QWp5Qm9Uam1C?=
 =?utf-8?B?SWlVZCtzc3RGd3FkZXExMHBRUWRjVkZaTkFpbFNEOWdySmY1Y3hZQXMzRUd5?=
 =?utf-8?B?Smdrei8zNGdsU213MFZ1ZE5SSHdCV1ArcUc1d0VpWXQ4QjBZV044dHlDSUVE?=
 =?utf-8?Q?gl16l9?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 15:32:03.3718
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dd043868-72df-4e58-ac27-08ddf1485ba9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000012.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB5673

On Thu Sep 11, 2025 at 4:52 PM CEST, Jan Beulich wrote:
> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>> by the device model. The GPE handler checks this and compares it against
>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>> related bit in the bitmap and adjusting the table's checksum.
>>=20
>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until i=
t
>> reaches 128, even if that overflows the MADT into some other (hopefully
>> mapped) memory. The reading isn't as problematic as the writing though.
>>=20
>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>> then the bit where the "online" flag would be is flipped, thus
>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>> that happened outside its range. It's all terrible.
>>=20
>> Note that this corruption happens regardless of the device-model being
>> present or not, because even if the bitmap holds 0s, the overflowed
>> memory might not at the bits corresponding to the "online" flag.
>>=20
>> This patch adjusts the DSDT so entries >=3DNCPUS are skipped.
>>=20
>> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
>
> The code in question originates from e5dc62c4d4f1 ("hvmloader: Fix CPU
> hotplug notify handler in ACPI DSDT"), though. Before that there was a
> different issue (as mentioned in the description).

As you mentioned elsewhere, it probably is 087543338924("hvmloader: limit C=
PUs
exposed to guests") that matters. Until then the DSDT was correct.

>
>> --- a/tools/libacpi/mk_dsdt.c
>> +++ b/tools/libacpi/mk_dsdt.c
>> @@ -239,7 +239,8 @@ int main(int argc, char **argv)
>>          /* Extract current CPU's status: 0=3Doffline; 1=3Donline. */
>>          stmt("And", "Local1, 1, Local2");
>>          /* Check if status is up-to-date in the relevant MADT LAPIC ent=
ry... */
>> -        push_block("If", "LNotEqual(Local2, \\_SB.PR%02X.FLG)", cpu);
>> +        push_block("If", "And(LLess(%d, NCPU), LNotEqual(Local2, \\_SB.=
PR%02X.FLG))",
>> +                   cpu, cpu);
>
> Don't we need to use \\_SB.NCPU here? From the other two uses it's not
> quite clear; it might also be that the one using this form is actually
> needlessly doing so. Yet here it may be better if only for consistency's
> sake, as the LNotEqual() also operates on an absolute reference.

\SB.PMAT method does the same thing. I'll just change that too while at it.

> The other thing is that I'm not fluent in AML operand evaluation rules.
> We want to avoid even the read access to FLG, and I'm unconvinced And()
> will avoid evaluating its 2nd argument when the first one is 0. IOW this
> may need to become a 2nd "If".

I don't think there are any rules, it's unspecified. While in practice it
wouldn't matter a lot, it's indeed better not to rely on it not blowing up.

After sending this, I wondered about having a separate if with an early ret=
urn.

>
> I further think that strictly speaking you mean LAnd() here, not And()
> (but the above concern remains; all the ASL spec says is "Source1 and
> Source2 are evaluated as integers" for both And() and LAnd()).

I very definitely did mean LAnd! Nice catch. As for=20

>
> Jan

TL;DR: Will s/And/LAnd/ and move it to a separate If

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:36:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120464.1465389 (Exim 4.92)
	(envelope-from )
	id 1uwjLP-0007IB-J4; Thu, 11 Sep 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 1120464.1465389; Thu, 11 Sep 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 1uwjLP-0007I4-GS; Thu, 11 Sep 2025 15:36:19 +0000
Received: by outflank-mailman (input) for mailman id 1120464;
 Thu, 11 Sep 2025 15:36: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 1uwjLP-0007Ce-4b
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:36:19 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2418::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0c2f7502-8f25-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 17:36:13 +0200 (CEST)
Received: from MN2PR11CA0017.namprd11.prod.outlook.com (2603:10b6:208:23b::22)
 by IA0PPF52B16157D.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bce) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 15:36:10 +0000
Received: from BL02EPF0001A103.namprd05.prod.outlook.com
 (2603:10b6:208:23b:cafe::7a) by MN2PR11CA0017.outlook.office365.com
 (2603:10b6:208:23b::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Thu,
 11 Sep 2025 15:36:03 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BL02EPF0001A103.mail.protection.outlook.com (10.167.241.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 15:36:10 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 08:36:09 -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: 0c2f7502-8f25-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IehtMrj6cehdKeo197EpFyMalbFvgv3iKoLSwdW7+Opqv5bj9HSpF1/HSu5kx41LYg7Yyl2aXsfonDgVBmOOj1eTE6NuNyEqXArkKCP3Ji2G12+ECWrdHglpOVshkqV1/JhCw9FUCRVVZX3nUrp/K0GTVGgDH+FAvjO4TEo52wIAeiQjtU1Z3A9GixIPTvcfAy7PrJ8ZkgAD6HKZ7cSzOFhvZvRsALKlYYux/0XC+GnYCsxysacVxBa4XyVtbCNCY/K2XtoEWu4BmRMxeso5pskXlNqyZiD4oIb4sGyKe74vKPv3o0fZPJg1D7QxMz6rLsgtKC6l3qOVolNIDBnDCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ILnfP8RABLb+q0Xa/Rg4y+cxoUVc0GUqnq9+CRWXsBA=;
 b=MjNgoS/RiQq1rcRXaSPycZPKm9Zs8EnG0DmdnBQEU0DxXSsVgFqO8sFfY1z2UauUAzjlBjs4b3BiJfxZVrW5hbxwfvhkXBQqDoknJmHUiLlrbvOLwTxUVGHTQLSZl+U2h+0czaziae8Cw9Pj01A4Fa0bzfVNg/BiB3QxbdRVY1NPXfI/swujYH9LIH9Nl/zR/o7wMmh7aCCLXsnmkTUw+rBrc3unOU/IvU5bMrGHVKL9vcxAUoUbl49bBIgSbpOlaltS0/PxKHRgnhcl1i7prXnCfEHSzPEkqIzx2+z04WiL6pAlFA6qWoZ0BzdQ5bVsaBaqCZhP/RgHGBOl/fiLTA==
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=ILnfP8RABLb+q0Xa/Rg4y+cxoUVc0GUqnq9+CRWXsBA=;
 b=JsRwxDI5C4MJI7f3+hvgtsdfxg6QBhpQgLXmmB4btuoRnRowUpoqnOrrabjlb2QLdQOyuHzjiIOVQlxdO9ppvtBWmEk+8rk/7iw7wNNo2aGhJ1qbGFyHypmnE8eynhpmjrUJFIwyplun8heUS3OTiMqo9yHAmJh+hsCmeRlijBM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 17:36:08 +0200
Message-ID: 
CC: Anthony PERARD ,
	
Subject: Re: [PATCH v2 2/2] libacpi: Remove CPU hotplug and GPE handling
 from PVH DSDTs
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-3-alejandro.garciavallejo@amd.com>
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A103:EE_|IA0PPF52B16157D:EE_
X-MS-Office365-Filtering-Correlation-Id: 1e5acaa8-ab95-48e9-e22f-08ddf148ef17
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?aThxbGcxZks4aG9xcThhSnVEejlGanppNkw3U0c0QmhWcHVWcThmcFNDNmZZ?=
 =?utf-8?B?OXA2KzRnd3JuRmE3SHBnSnNMZGUrQjV1WnBZcS9BYjVsbXYwTjF1VkFwN2p3?=
 =?utf-8?B?VnhRQVRDTFF2OFZWaURnRFFmY2txMnBHbzZrOW1wQmRja3NqUC9jWm9xeWN4?=
 =?utf-8?B?NmFKVE14V2hIc0ROaERTWW15L2RDdnE5K2tES3hwTEhzV0Z6ZHd0cHBQdnlw?=
 =?utf-8?B?eHFJb0owSDlwazdTTU5RNzdVS2k5bVNOY3BUMFNVaXlDNHViMDEwSzdmb0Vm?=
 =?utf-8?B?a1V0WWUzU1Z2eDd5MlY5T1B4NTJHQU1zT0VWWUNlV0MyOVN2ZVlTeWx2MUFa?=
 =?utf-8?B?a2w5STY0ZktIM2tIZGlUaFowVlhGdHNMMnZSVmh4dStOeVZwaVNjSFRLVFlr?=
 =?utf-8?B?UjU2WW5UWm5rQU1Ta3U5Nyt2VjlCTnFmTzZZbWRkcU1OKy94OW9YekdnNEVQ?=
 =?utf-8?B?b21NbmR3cUU0UGZBVm5KdnZxbnBEV2FZcm1RbFF1RjBJRFRLR0JWRnU4bTZk?=
 =?utf-8?B?T1Fob1VPU0QyUXhVcUt5RkhSUktHTEhxREhCVWQ3MjBCbkwxRVVzaVhXcTNH?=
 =?utf-8?B?d2FoV1BEbTdDOGlORTU3Vlpib0FkRTc1UVdKb1cyRDRMZXVoL3RJV2didzVZ?=
 =?utf-8?B?Sm00ZnlzNzVZZmtTTmRrbGRveW1Mb1hadE5wditUR2JZajFEMnJTRmRzOUF5?=
 =?utf-8?B?S1NXdm9HaDlTeHh4UnFkWEYzQTRGSEx5ZXd1eGRQM0JqbW4zVkExckl6a1FF?=
 =?utf-8?B?RC9DY2VzZnRTZzRvb1h0THZ5SitadUpLREs0WEhXTnRzR0MwSFcwaDA0cEVk?=
 =?utf-8?B?aGFsV3NQNGZXdi8rQVNPUm1NWlg0REtPaGpYdFgveGc1MjhUcFBvU2cxTXJl?=
 =?utf-8?B?YkVaNlFyOW52RU4yODVGUWp1VkxHTURGR1VJWFVSdHNIUVBWQ0IwaFFMdkhT?=
 =?utf-8?B?ZnlMbnVJV2cyU0xSNE9aWER6RFBTMm9RK0o2UUpxYzlNNmhPb21wcFJCRnNG?=
 =?utf-8?B?dzdZVWN0aWV4MUx5RitJeUJCS3NieFJhVW5RdVBFckF5OVJIZUxIOUhneS9h?=
 =?utf-8?B?R3V0REZoK3hnUWZlcGFQOUF2NkhlNi9LdlJOclhjMFE3ckpEblVYY0svUkFk?=
 =?utf-8?B?R2ExbEdiWlREOE5iUzJCNExOZldudURFM09vVjFhWFhpRDZGV29YbS9FdGFI?=
 =?utf-8?B?N3RWclRNYnhYd1JTVnQxWlpBa0hnWVV0SkRXbTV0c3dCSTNtcjJLVis1STRz?=
 =?utf-8?B?RVQvNjBIbGxqbmV5YjJwNkJIdWN6amszMVhEQTY3NTRGL3pDSnRqUURnU3JD?=
 =?utf-8?B?bVpGdlR4UEFOTHdIYUVVL2I1bVhWMmlHckdCSjFTaXBWK0N6dkVwbDJMekY4?=
 =?utf-8?B?QkF4RE5DSUJWSnQ3VGJ3QVF2OEN0SXdLWk1hRXdMQmVSWFpaRTVYaWVxQzQy?=
 =?utf-8?B?SEdxUm1xakdMT1M1KzNIdlY1RU83L3dNV0o1a0Z0UThDcDh5NStsc2Z5ZU9B?=
 =?utf-8?B?SldoVCtJbUNUNTFxbUNZUU9ZendzdmJHUC9QUWJSTWx5RlRBUzdsbmxGeXJx?=
 =?utf-8?B?b0JSVlh3UFgza2tEUkJZY3FUZ29RTlJDcThiTGd3a0pZZFlRd0ZhWWEwSXd4?=
 =?utf-8?B?b01JZmxORzBhblliY0ttelRqNmY3QnplbFBmTEplZFVqd2JEMEpDdTBLZnVv?=
 =?utf-8?B?TDJLQXpzSEVqSkVxTk9teGUwU0hmNEs3NS9DbjZ1dHI0c1RmRUllWFhDcW9G?=
 =?utf-8?B?UllnRDgva2loNEdiN1JRVDMrN1ZlK2dENmsrb1V4cVZzbTczVmJnNVFyc3pn?=
 =?utf-8?B?aXRBSUJMeXBDcHFaQitsUUNHaHVVUGJMcFd1cVBBcjd5cDBlamtHSVBEazRF?=
 =?utf-8?B?d1QxRDBGaUd5R2NpLzg5c0VURGdidU1od2U5TStlLzFPK0wweDl1SERYMG9C?=
 =?utf-8?B?dlU3RkRocjI2aFYzR3FwMTVxUytsc3BJWVdCMFRLbXlvcCtPcGZOM1dHMXlB?=
 =?utf-8?B?dEo4WUhqdEhpQ1c0SmxVZ0tZdUxyL3hZODZXRnZwbFFXRnFGVTE0SlF4L2ZT?=
 =?utf-8?Q?rsfply?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 11 Sep 2025 15:36:10.7312
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e5acaa8-ab95-48e9-e22f-08ddf148ef17
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A103.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF52B16157D

On Thu Sep 11, 2025 at 5:07 PM CEST, Jan Beulich wrote:
> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>> PVH guests have no DM, so this causes the guest to fetch the online CPU
>> bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
>>=20
>> Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
>> the GPE handler in addition to anything ACPI CPU hotplug related.
>>=20
>> This shrinks PVH's DSDT substantially and prevents spuriously executing
>> a large amount of AML with no purpose at all.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>
> Reviewed-by: Jan Beulich 

Thanks

>
>> ---
>> v2:
>>   * Adjusted commit message
>>   * All other tags except S-by moved to patch 1.
>
> This will want backporting; I expect finding a suitable commit for a Fixe=
s:
> tag is somewhat difficult.
>
> Jan

I'd say it's the patch that needlessly enabled GPE handling on PVH.

Fixes: 062975dc9441("acpi: PVH guests need _E02 method")

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:42:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:42:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120479.1465400 (Exim 4.92)
	(envelope-from )
	id 1uwjR6-0000Z6-Bo; Thu, 11 Sep 2025 15:42:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120479.1465400; Thu, 11 Sep 2025 15: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 1uwjR6-0000Yx-8F; Thu, 11 Sep 2025 15:42:12 +0000
Received: by outflank-mailman (input) for mailman id 1120479;
 Thu, 11 Sep 2025 15:42:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwjR5-0000XT-36
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:42:11 +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 e01a9e9a-8f25-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 17:42:08 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-62ed3e929d1so450017a12.3
 for ; Thu, 11 Sep 2025 08:42: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-62ec33ac2c7sm1344908a12.13.2025.09.11.08.42.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 08:42: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: e01a9e9a-8f25-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757605328; x=1758210128; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1LfVpQMa8EqWRGQECfp1CNnRonRO/NJ7wxd71Gbpnak=;
        b=XgJ0wsoEvn9VV4incs+6CPu4na0P+IKeA/+wKQHpF9JA/DgAUiTH4fS18MMSaXCi+f
         Xvlks76Yywa2zKOSseVPOznBJjxEfnq+ma1C7IsmgMko8wavC1NvZdyuViVD+wKUzzOE
         5jyYMKPCJPjoyHXgzzFBG1iE3ze1qtogDF+54Am1us3clJ4pJdGcP0szkgAar3cqa2kk
         sr+1B2tNsSl8GWYQPTHKDWtd4pfjrZ0ByEu9WEZlPuo9jOW9WIfCeRjA2ZQWyRX4iRDO
         D5yRDa949418PCFj4VRiLblCNbu4IPTpbEZ5yHQMqd2g7ySbU/8f8POIcQs9KmjcHetb
         DvKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757605328; x=1758210128;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1LfVpQMa8EqWRGQECfp1CNnRonRO/NJ7wxd71Gbpnak=;
        b=b27fVAPo3M6y3I2CZ5fe8PtfvNCrz0mgo8ceuSczaD5eYWCJihLj62GieEjTzp6CeN
         FxY8pbXpnwiKOXopFIyGnld3OQ66z1R1TsafNr+GUPNA+j97+EfMeoXCi7ckPQi9lTb3
         boW5FujWplteGPevAE2Am3pb9U6HhlBXvQ9MI5F2O8BemfZYKoPOTL6/Ula6HiD03ss5
         HzArNcjyT5xD3nXt4wQrfOeNn0ivaemFxZ8ryYaI4cA+FFjl90VnmvMbyU9za4fwzCAt
         yV+IdGf4mjp4mAFL0X2I9Uqukw7m5GABB1mVKtSHIfDImxRZcZ35W781sMYf+las6qHn
         pSbA==
X-Forwarded-Encrypted: i=1; AJvYcCWGcX5w8z+XAWx13mSK6HxUICAqwATbFbTjURnny17p6L99q/WiPD3IeAwMCAm2/xe35/CGJxF5hGQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywuu85gN6TkQE5u90nEBfR2SnxZJYrMLU5fWl4t1fCLFVMVxV82
	Nu6VEnb/uEartvoNVsM5zmj+VaKuB8VV5hLiVj0mJRky+HFxpB5fdlGpuYD4tWLi18Gjx0HsSRt
	phps=
X-Gm-Gg: ASbGnctj1k48277Fj6LIfcDPz0YxbHw2np+oeBGr6W0ypMyp5+8GSM6MDE8w4bmHrVg
	CugU+/KCx4R/AjcUZ4NzBhxIULmx8EGI+kgrnykzp36dnQMenNSBAGqTwa2Zdtsc54kvWRD8THz
	YiSVPeJvrV5GaRs0TAMhH9cNtxbSMaoU16S6M1uUaTFO9SxOyWYAH7lGQ+xdJ4DqBZbjQSFFfxH
	+3FMbByoqA4WtNOld85nV5fmaDf0lLr59rYOZk+Ka9bqso6rpTM/TUh08bcM16leTyG72Psz+tn
	4+pDOAPHWHdWxHzW3gCE+XEZsoyQ+fVm7IKtpxgwJsmTWjkWZzQinAnBXj3526KvFxfFf5e+ZH9
	RLz+1wICIMUUmoccSMBW6E46QuZSg4zh5CUg+NAnpbnjSGcAfH8NDKrb9QbkY1nTYQgkTFNUuPD
	EYihCyXWZ1s/ouuFiILw==
X-Google-Smtp-Source: AGHT+IFQhaENGZCXxoeYFng5B5MFF8qjfOY/nRI9OzP/MMktsTVOeXQSduRjOVooeVq9HKd1e/NEjQ==
X-Received: by 2002:a05:6402:23d5:b0:62b:e4d1:1192 with SMTP id 4fb4d7f45d1cf-62ed823facamr39569a12.4.1757605327938;
        Thu, 11 Sep 2025 08:42:07 -0700 (PDT)
Message-ID: 
Date: Thu, 11 Sep 2025 17:42:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 xen-devel@lists.xenproject.org
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-2-alejandro.garciavallejo@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 17:32, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 4:52 PM CEST, Jan Beulich wrote:
>> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>>> by the device model. The GPE handler checks this and compares it against
>>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>>> related bit in the bitmap and adjusting the table's checksum.
>>>
>>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
>>> reaches 128, even if that overflows the MADT into some other (hopefully
>>> mapped) memory. The reading isn't as problematic as the writing though.
>>>
>>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>>> then the bit where the "online" flag would be is flipped, thus
>>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>>> that happened outside its range. It's all terrible.
>>>
>>> Note that this corruption happens regardless of the device-model being
>>> present or not, because even if the bitmap holds 0s, the overflowed
>>> memory might not at the bits corresponding to the "online" flag.
>>>
>>> This patch adjusts the DSDT so entries >=NCPUS are skipped.
>>>
>>> Fixes: c70ad37a1f7c("HVM vcpu add/remove: setup dsdt infrastructure...")
>>
>> The code in question originates from e5dc62c4d4f1 ("hvmloader: Fix CPU
>> hotplug notify handler in ACPI DSDT"), though. Before that there was a
>> different issue (as mentioned in the description).
> 
> As you mentioned elsewhere, it probably is 087543338924("hvmloader: limit CPUs
> exposed to guests") that matters. Until then the DSDT was correct.
> 
>>
>>> --- a/tools/libacpi/mk_dsdt.c
>>> +++ b/tools/libacpi/mk_dsdt.c
>>> @@ -239,7 +239,8 @@ int main(int argc, char **argv)
>>>          /* Extract current CPU's status: 0=offline; 1=online. */
>>>          stmt("And", "Local1, 1, Local2");
>>>          /* Check if status is up-to-date in the relevant MADT LAPIC entry... */
>>> -        push_block("If", "LNotEqual(Local2, \\_SB.PR%02X.FLG)", cpu);
>>> +        push_block("If", "And(LLess(%d, NCPU), LNotEqual(Local2, \\_SB.PR%02X.FLG))",
>>> +                   cpu, cpu);
>>
>> Don't we need to use \\_SB.NCPU here? From the other two uses it's not
>> quite clear; it might also be that the one using this form is actually
>> needlessly doing so. Yet here it may be better if only for consistency's
>> sake, as the LNotEqual() also operates on an absolute reference.
> 
> \SB.PMAT method does the same thing. I'll just change that too while at it.
> 
>> The other thing is that I'm not fluent in AML operand evaluation rules.
>> We want to avoid even the read access to FLG, and I'm unconvinced And()
>> will avoid evaluating its 2nd argument when the first one is 0. IOW this
>> may need to become a 2nd "If".
> 
> I don't think there are any rules, it's unspecified. While in practice it
> wouldn't matter a lot, it's indeed better not to rely on it not blowing up.
> 
> After sending this, I wondered about having a separate if with an early return.
> 
>>
>> I further think that strictly speaking you mean LAnd() here, not And()
>> (but the above concern remains; all the ASL spec says is "Source1 and
>> Source2 are evaluated as integers" for both And() and LAnd()).
> 
> I very definitely did mean LAnd! Nice catch. As for 
> 
>>
>> Jan
> 
> TL;DR: Will s/And/LAnd/ and move it to a separate If

Except that once you use a separate If, no And() or LAnd() will be needed
anymore.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:43:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:43:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120492.1465410 (Exim 4.92)
	(envelope-from )
	id 1uwjSM-00014d-LM; Thu, 11 Sep 2025 15:43:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120492.1465410; Thu, 11 Sep 2025 15:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwjSM-00014W-Ic; Thu, 11 Sep 2025 15:43:30 +0000
Received: by outflank-mailman (input) for mailman id 1120492;
 Thu, 11 Sep 2025 15:43:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwjSL-00014O-NP
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:43:29 +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 0fb17bc5-8f26-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 17:43:28 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b0411b83aafso130796466b.1
 for ; Thu, 11 Sep 2025 08:43: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-b07b31283e3sm159623666b.24.2025.09.11.08.43.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 08:43: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: 0fb17bc5-8f26-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757605408; x=1758210208; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZalBOOkrRJa5IA8T/hiJ81YAsRHcOaaxM0Uyj8g4wlI=;
        b=BkstLBpKIGJ+pNRz565iMhQI0aNW2ZwRTIyCtXRnN2QE3Im3rvBWRxFOrg3hyDVVHq
         Mv9+XIOzpNC3f6atCwapqMUmML2mbxs79RnfJv9P8ni8pqm705lp2/yA/s3JZKZx1rcg
         nRsc0qtB64VPGrGwLtf7lAbAHFzCqWKw14iKOfCAYhpfN4Qqvh13YJXx9AXTf7mGM4RS
         ijNUZUEXWSg7KmIS7eouBF8dZCzZll3ceUgl0p4W3eNaylpAillNAqbwPBmNwp2/TE0h
         jMuX3+8aeFZrogxnhMyTj4LkowxPvZAp8G0mt9BPw9p+pURyNQg+/ugvSpk2pUc5WBrs
         ElkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757605408; x=1758210208;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZalBOOkrRJa5IA8T/hiJ81YAsRHcOaaxM0Uyj8g4wlI=;
        b=thlTXP6KLbK0Joh7UD1FLUkls55zJExrPZp6k+V/Jr3DWcPvedNRxroiqEtdKCFTPW
         Pl31zXIq/SF2wTwHNrosTGQ4KQNTliPdh4l9k8SAzGTHY9rdfBgDrbDRg9oMSYEMelIy
         p2B0POGAjeyIR7l3e2YdiMhbtfJQGjwK55dxO2jJC3VbFv644WUAImVo+CNc1siofPKp
         cNNCEridltQ6qRSUNrZv1uSLnAHp6QStfD3wTp+vt7uchmM95pWah4GhbXrLjnHbymkO
         PoMU+ZevYC1TUs5V71BhLWMNiNoiwlAmkbr50gfkdJE0WHDGkQEwm7EsCHmmA2g2+2C1
         pF4g==
X-Forwarded-Encrypted: i=1; AJvYcCWsPDVNEwb1p/H5udziI8s2aNAGmnWFxA0XbHj2g7C6cxo5Avy01i8BqDhO6MTvh35NdmOxcpJG19Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyo+w2NUVf+wUl/YyYJ1p4EreRq0o/4A3NhG9RQ+YHeX+dAs0vP
	K+ptP5zTwPMuD7aGndqLx6Ag5tUizkezE6mir6yRszYNXzImmBEoLcr+VdCCqpZnhg==
X-Gm-Gg: ASbGnctyDHMvWSzkz5iBv7rbmmHvn9qc9MmdaXoaukzLTkJEp7UFLQmzI/45Ksv83ih
	iJTQdGM6bGIdkFG90LydsRtxBwBVRbbEmwEX58d7ESkhN16XwloJB3VBbBPIlph38gaH9B+r0zK
	IrySyepo3f+MsdejRQXs2jrptoyDJ1R5c+Gm4/AEaxk423ck9Fnh/K+MSAAeMUm/CRJ9SCOzTcD
	3JPYtuI0x9ao9kpvHTywUpoJR5KjnkAeC4QwSEZr9g7rlQvtOpUZrQAEmWISRTaX00CDAgHf4KG
	orHar+n2hCwxlHgPq3C8x3xPPIL7HLX7o/DuyW2NlkZmMSbe9MG8U7pebdtP4jXSNrfJwnAqNUQ
	mN4/KwBcVoi9jbaOxjwKfxw7ZVjlqey8GVJpDp6YNWv4dn6oHsPc4FniArPC29rnp7bSNEaxWnJ
	2sO6/y90xCg+Jnkj4fiw==
X-Google-Smtp-Source: AGHT+IHCpHmEpSIB1MGnmSybZH/FMjJf0nTIZkntNo/f9fUR5EkVbkVoubCmRO356LveC2TrdXnOTw==
X-Received: by 2002:a17:907:3f2a:b0:b04:9d90:a7e6 with SMTP id a640c23a62f3a-b04b1741ac2mr1987530466b.55.1757605407865;
        Thu, 11 Sep 2025 08:43:27 -0700 (PDT)
Message-ID: <6b616feb-8984-40c9-b7c0-8c75dca65596@suse.com>
Date: Thu, 11 Sep 2025 17:43:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] libacpi: Remove CPU hotplug and GPE handling from
 PVH DSDTs
To: Alejandro Vallejo 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250911115308.16580-1-alejandro.garciavallejo@amd.com>
 <20250911115308.16580-3-alejandro.garciavallejo@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 17:36, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 5:07 PM CEST, Jan Beulich wrote:
>> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>>> ---
>>> v2:
>>>   * Adjusted commit message
>>>   * All other tags except S-by moved to patch 1.
>>
>> This will want backporting; I expect finding a suitable commit for a Fixes:
>> tag is somewhat difficult.
> 
> I'd say it's the patch that needlessly enabled GPE handling on PVH.
> 
> Fixes: 062975dc9441("acpi: PVH guests need _E02 method")

Oh, right.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 15:46:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 15:46:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120503.1465419 (Exim 4.92)
	(envelope-from )
	id 1uwjV8-0001st-1k; Thu, 11 Sep 2025 15:46:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120503.1465419; Thu, 11 Sep 2025 15: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 1uwjV7-0001sm-V4; Thu, 11 Sep 2025 15:46:21 +0000
Received: by outflank-mailman (input) for mailman id 1120503;
 Thu, 11 Sep 2025 15:46:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwjV5-0001sb-W7
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 15:46:19 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2009::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 74896bad-8f26-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 17:46:18 +0200 (CEST)
Received: from BL1PR13CA0113.namprd13.prod.outlook.com (2603:10b6:208:2b9::28)
 by SA3PR12MB7781.namprd12.prod.outlook.com (2603:10b6:806:31a::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 15:46:13 +0000
Received: from BN2PEPF000055DC.namprd21.prod.outlook.com
 (2603:10b6:208:2b9:cafe::96) by BL1PR13CA0113.outlook.office365.com
 (2603:10b6:208:2b9::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.8 via Frontend Transport; Thu,
 11 Sep 2025 15:46:13 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BN2PEPF000055DC.mail.protection.outlook.com (10.167.245.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.0 via Frontend Transport; Thu, 11 Sep 2025 15:46:13 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 08:46:09 -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: 74896bad-8f26-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=e1u3LApDYszOTEma88lL46zxbHQhLkO0HRq583UzgeIfnMyRcPUFDYuS+UWUmfXvRsP15/WsAKJC+APpeoElUtM78X2j+YMAfQ/lJyYqi3hYpEUQCjEuy3/Cew2O3mIRgzTcnuLuMGXxIaXexVQQ2Qi8MaNZajFtH713XwUo+O/QUR4jmdT7EhuAKL81zzfa9I7HFIjBggmIPlhVTWt4FtF1/6NjDMdz8EuKGEfaU4oxnx08CRxQEi8rATyYGovX590zJOk1Shm+6KXI1ZY5dacx7e7pVAjwFPptplZqlXrNmgpC3+O7fyaS6pEJOQNAsB6K/uGxL41lpX+nLkllJw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1GKoceEeRTsg1YvJtSF0BHGnKeYr1esTx0wBbEOPykQ=;
 b=iCDBYxuQVOzEtH5rosJwVYxGPWPLurWk9z8E2usiuYo+mmB9qZAGQmlSilSI42bhbTPiE4mpmfjEAy/fDXqDVPyKIScxouvImVxRYB0eDBeJ8rU1WneC6DcwBpHxtxgAr+XZ21IhdnnRKDHEaN8adcrC6yM/33lOnMJdI12tYuFfGGe3TCYr07DBuIvxuDrYHo4IWjfgvtgV+MRieAi8CkkdR5C4GiPly4iwkq0Rl0Cb+cStRTsxCHgTY9OB1uVvO8cjW6SdfbqcKnJQPCKLcr7PU8vl6J7qv1PPvShTQMWytaO5d83lua2x0Mhs8mkqDNmqNh4C/qyHjPJodkKa9A==
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=1GKoceEeRTsg1YvJtSF0BHGnKeYr1esTx0wBbEOPykQ=;
 b=ns+9JQ6EhZONsehp0bH8BWZGlT79oOazrzG8+WZ0ddmlSdKbwhC8YvmIh0YwORChkiBbQ+lbm7rfv50cEjZTqHJKTLEHtQdALKFi0JWNSA7Rv2bLNxJcHARg6jl0FY01523E88XPtzaq7tzblb+dZDBEYZWGuEhIUZXJb+Uh++g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 17:46:08 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Jan Beulich , Andrew Cooper
	, Jason Andryuk 
CC: Xen-devel , Xen-devel
	
Subject: Re: domU reboot claim failed
X-Mailer: aerc 0.20.1
References: 
 
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000055DC:EE_|SA3PR12MB7781:EE_
X-MS-Office365-Filtering-Correlation-Id: 301d1f7b-331d-4500-e19a-08ddf14a566b
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?SXV2OStzVlE5VW9uelFoV1pockRLcktqVm1xamFLRUp6WEdBUjdaMGd3VGxh?=
 =?utf-8?B?Q0Q1SVk4NkRJbkZRY29zMU0reU9WSkZSd2pkVW9xYm44SEYxK3hLUDIyc2dr?=
 =?utf-8?B?d2VqTENHendxRk0zS2VFWnA5RmlRVlNTZEp2R091WHQ5NHR4S1R2YkRlanRK?=
 =?utf-8?B?SitUQndlMjF5a0JZanNjbnlEelhQWWdRK0thSkhIRENKbWhsSEUvSXJPaWZ5?=
 =?utf-8?B?NEVYZU9CVlRIUFVTYzlGQjkyZ2NVL1NMN3UvVVhnU3lxb2JHNGw4OGpOT0NQ?=
 =?utf-8?B?Qk5VOEVNczAyZXQ2QlNXdHkwQUIySUgxRG1BbFBGTHp1R3o4Y0p4ZEZaTDZW?=
 =?utf-8?B?Z3ZCd2hiTnoxdXh4M1ZtcTNSeGpGUXgxTlpTNDM2cnkwOXdHeXZSWXZwdU9R?=
 =?utf-8?B?VkVLdjVvOVhwSStZMjFxN1NDdjVTK1JtcUh1bWpQNzUzMEJsazRSbUdmdzg5?=
 =?utf-8?B?Nmt5V3lZQ1hSbGs4QVJvRkdPZHdTOHhSWDF0S2pBOXF2LzhFNlIxU3hjaEtv?=
 =?utf-8?B?aUhVWFo4VkZJaEU0R2ZJSm81ZTdpTHpZVnp4aTJtWkEzeUVBcVNvVWpwOWp6?=
 =?utf-8?B?VkIvdnZubmNDR3NseUFKc0RheDFpYzIzVkZtUy9SOWNYYU5td2JZcUcwVWJT?=
 =?utf-8?B?ZndHUW5YKzMvczRGbzB3MGRiNHk5bXdzYkZqd3cwc28yK1Z6RVBSREpZNXMv?=
 =?utf-8?B?dlh0UnMwZWczREZPVDVETHBndFUwNk5OMWd1MFFablBVQXVyM0RPNDBlU3Rt?=
 =?utf-8?B?aEYrVmhmTzdhRG1iSklncXNkNEFZQnRYWThDSGIzY2piaDZuL3JPZWRSdXhk?=
 =?utf-8?B?ZWVnOVA4NVgvblZla29jQUU0b3RzZVREU2E0Z2k1OWhlZStWd2ZyWEE2cWg2?=
 =?utf-8?B?bGtndnUrSjVEYk1MRUo3aHZIeXk5OWZjNDc1MEN2d21ITTZQN0c3a0FqRHNX?=
 =?utf-8?B?SzErNFZJOXlKN1FETVh1MW85b0xPS2tUOEN3Nll6VkltYU11aEFlZWU4dk93?=
 =?utf-8?B?Ym8rU2xiYTBpU2IrTDZMSWxmbXdIUUV2ZVg0eGVOYW1oL0NjRjdCVGVPc2hs?=
 =?utf-8?B?dlNwYW9HUk1BSkd2amtFaTJseTRWcDVsSWdjOFNMcmpxTVBWNktBcjJGU1dX?=
 =?utf-8?B?WHdSTWpVblJ6bE9SRlQ5a1h4SUtCTmZLTkRYMHp6ck1wYWpUUFNvNTE4eEcz?=
 =?utf-8?B?MjZTRGdmQkZSbVRkTmdyazBTTDNLcXN4cEg0dUZVclZaQ210RHV2czE1TDFN?=
 =?utf-8?B?WmVrMlJXbVVwV1ZocUNFU3RQbHY1OFpSYVlJc2wwN3IybDlhdnNJM1ZnNDlH?=
 =?utf-8?B?dnFBc0pETVd1Y0VMUWIweUdoL0ZnNHhpUEl1eGNCaUtScDRrR2tkOEhoMlZM?=
 =?utf-8?B?ckQvWVRGbDdPcldlTkt0Nmo3NUFtTXNiUzVMVlNOcy9QVUVyNU1aTTB3OFJ2?=
 =?utf-8?B?Vm1oek1SNTIxWitQclIva3ZaZ3JvZWZBcnZsWGlDbVMzV01yajRtMGxQVHBV?=
 =?utf-8?B?WFJFb3VXSk1mdW1YeFJvZ0RoQjJRRWVha1BOajlKZ0hFcVVXZXpUeW5penlq?=
 =?utf-8?B?ZzVuaFFrdDJ0SkU3Vm1CQlFXcUJoTTI0RmI5MmV3M21pTXZXMmlWYUEydWI3?=
 =?utf-8?B?N0NyZzEyazdrT3pIRHR4ek9yMXJBeElqb2tUYU9iYUx5bCt2elhFL3dXUjdF?=
 =?utf-8?B?Q0hsMWFxb3NaSGRaNVZZbml3eEprUlQ2OEVzMEh0Rk1hZzV1RExCNFJTRExp?=
 =?utf-8?B?aGp4NXV4Y0tmcVpHMW5GU1ZXWVZSbkNLcmFsOWRKRUxuWGZQUlgvNGdvdTJY?=
 =?utf-8?B?eXlKSTY0MkxmMzFIQ1FkdW1PVlp6NW1najcxS2huNiszWm02RE5wN3FwbGFy?=
 =?utf-8?B?Rm53clhncDFBaXVMYkdVMUpoQTI0aTJHcDFjZGJ6d1JkQTV4TWFSRlJwRE1q?=
 =?utf-8?B?NWRWWjQ3Q2Y0dVlRQkVyN3MrVndoU1dWQlY5c0ljYmxEc3RYUElLMDczMEJK?=
 =?utf-8?B?MXRlY3pZSnRGTEcwd3VYRkVGVEVoNWRFYXIrTWtHZzN0MjJUaXpvUTMxaVNV?=
 =?utf-8?Q?IEzF01?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 11 Sep 2025 15:46:13.5843
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 301d1f7b-331d-4500-e19a-08ddf14a566b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000055DC.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7781

On Thu Sep 11, 2025 at 9:55 AM CEST, Jan Beulich wrote:
> On 10.09.2025 23:57, Andrew Cooper wrote:
>> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>>> Hi,
>>>
>>> We're running Android as a guest and it's running the Compatibility
>>> Test Suite.=C2=A0 During the CTS, the Android domU is rebooted multiple=
 times.
>>>
>>> In the middle of the CTS, we've seen reboot fail.=C2=A0 xl -vvv shows:
>>> domainbuilder: detail: Could not allocate memory for HVM guest as we
>>> cannot claim memory!
>>> xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't
>>> allocate low memory for domain: Out of memory
>>> libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init
>>> failed: Cannot allocate memory
>>> domainbuilder: detail: xc_dom_release: called
>>>
>>> So the claim failed.=C2=A0 The system has enough memory since we're jus=
t
>>> rebooting the same VM.=C2=A0 As a work around, I added sleep(1) + retry=
,
>>> which works.
>>>
>>> The curious part is the memory allocation.=C2=A0 For d2 to d5, we have:
>>> domainbuilder: detail: range: start=3D0x0 end=3D0xf0000000
>>> domainbuilder: detail: range: start=3D0x100000000 end=3D0x1af000000
>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>> xc: detail:=C2=A0=C2=A0 4KB PAGES: 0x0000000000000000
>>> xc: detail:=C2=A0=C2=A0 2MB PAGES: 0x00000000000006f8
>>> xc: detail:=C2=A0=C2=A0 1GB PAGES: 0x0000000000000003
>>>
>>> But when we have to retry the claim for d6, there are no 1GB pages used=
:
>>> domainbuilder: detail: range: start=3D0x0 end=3D0xf0000000
>>> domainbuilder: detail: range: start=3D0x100000000 end=3D0x1af000000
>>> domainbuilder: detail: HVM claim failed! attempt 0
>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>> xc: detail:=C2=A0=C2=A0 4KB PAGES: 0x0000000000002800
>>> xc: detail:=C2=A0=C2=A0 2MB PAGES: 0x0000000000000ce4
>>> xc: detail:=C2=A0=C2=A0 1GB PAGES: 0x0000000000000000
>>>
>>> But subsequent reboots for d7 and d8 go back to using 1GB pages.
>>>
>>> Does the change in memory allocation stick out to anyone?
>>>
>>> Unfortunately, I don't have insight into what the failing test is doing=
.
>>>
>>> Xen doesn't seem set up to track the claim across reboot.=C2=A0 Retryin=
g
>>> the claim works in our scenario since we have a controlled configuratio=
n.
>>=20
>> This looks to me like a known phenomenon.=C2=A0 Ages back, a change was =
made
>> in how Xen scrubs memory, from being synchronous in domain_kill(), to
>> being asynchronous in the idle loop.
>>=20
>> The consequence being that, on an idle system, you can shutdown and
>> reboot the domain faster, but on a busy system you end up trying to
>> allocate the new domain while memory from the old domain is still dirty.
>>=20
>> It is a classic example of a false optimisation, which looks great on an
>> idle system only because the idle CPUs are swallowing the work.
>
> I wouldn't call this a "false optimization", but rather one ...
>
>> This impacts the ability to find a 1G aligned block of free memory to
>> allocate a superpage with, and by the sounds of it, claims (which
>> predate this behaviour change) aren't aware of the "to be scrubbed"
>> queue and fail instead.
>
> ... which isn't sufficiently integrated with the rest of the allocator.
>
> Jan

That'd depend on the threat model. At the very least there ought to be a
Kconfig knob to control it. You can't really tell a customer "your data is
gone from our systems" unless it really is gone. I'm guessing part of the
rationale was speeding up the obnoxiously slow destroydomain, since it hogs
a dom0 vCPU until it's done and it can take many minutes in large domains.

IOW: It's a nice optimisation, but there's multiple use cases for specifica=
lly
not wanting something like that.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:11:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:11:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120540.1465429 (Exim 4.92)
	(envelope-from )
	id 1uwjtP-0006ao-Tp; Thu, 11 Sep 2025 16:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120540.1465429; Thu, 11 Sep 2025 16: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 1uwjtP-0006ah-RF; Thu, 11 Sep 2025 16:11:27 +0000
Received: by outflank-mailman (input) for mailman id 1120540;
 Thu, 11 Sep 2025 16: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 1uwjtN-0006ab-Mp
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:11:25 +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 f6293a08-8f29-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 18:11: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 7AEC5601D7;
 Thu, 11 Sep 2025 16:11:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E70DC4CEF0;
 Thu, 11 Sep 2025 16:11: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: f6293a08-8f29-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757607082;
	bh=5vEajUiE8vOl+c0s0dvzPQu+3RLAa5VvYGmH9nj+aKw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=YuBfToxkwuIfFk9nR7Y5ZKaZTpqeEbvLsL+qmycMw0U/DWbqdVZBI+xfRcTJIXSjv
	 +ideQ2F+dkvBGRcPw0TI7raAqdbPKd3p1xPevy0lLKkhe3cp/CDA5JYm3dlXveJgt5
	 c9HxB+j2wC/hdSdy+H2WS8xkBdq+0tfdl5VRfb2xPplBMrhcsWtsayftcmFSKBpAxv
	 3UcG5VZwZsZAC0o5XyqoBblq8tADG28vOkNDOCtXcSVNULNKRqppuJntr6AzgZZEa8
	 yBbpzDWD5bwn4ULjxesg/J8dOfFSpOyE2jdRpl3CnPuWPP1HdLCvrmMEnWke1BfDdP
	 hPOi2tnQfXZ7Q==
From: Will Deacon 
To: catalin.marinas@arm.com,
	oleg@redhat.com,
	sstabellini@kernel.org,
	mark.rutland@arm.com,
	ada.coupriediaz@arm.com,
	mbenes@suse.cz,
	broonie@kernel.org,
	anshuman.khandual@arm.com,
	ryan.roberts@arm.com,
	chenl311@chinatelecom.cn,
	liaochang1@huawei.com,
	kristina.martsenko@arm.com,
	leitao@debian.org,
	ardb@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Jinjie Ruan 
Cc: kernel-team@android.com,
	Will Deacon 
Subject: Re: [PATCH v8 0/8] arm64: entry: Convert to generic irq entry
Date: Thu, 11 Sep 2025 17:11:12 +0100
Message-Id: <175760255687.903003.14486495786906094929.b4-ty@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250815030633.448613-1-ruanjinjie@huawei.com>
References: <20250815030633.448613-1-ruanjinjie@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 15 Aug 2025 11:06:25 +0800, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the generic entry which makes
> maintainers' work easier and codes more elegant. So also convert arm64
> to use the generic entry infrastructure from kernel/entry/* by
> switching it to generic IRQ entry first, which will make PREEMPT_DYNAMIC
> and PREEMPT_LAZY use the generic entry common code and remove a lot of
> duplicate code.
> 
> [...]

Applied to arm64 (for-next/entry), thanks!

[1/8] arm64: ptrace: Replace interrupts_enabled() with regs_irqs_disabled()
      https://git.kernel.org/arm64/c/788b8f6af60b
[2/8] arm64: entry: Refactor the entry and exit for exceptions from EL1
      https://git.kernel.org/arm64/c/ee776d68ba47
[3/8] arm64: entry: Rework arm64_preempt_schedule_irq()
      https://git.kernel.org/arm64/c/77c195394639
[4/8] arm64: entry: Use preempt_count() and need_resched() helper
      https://git.kernel.org/arm64/c/c74c44c6ae20
[5/8] entry: Add arch_irqentry_exit_need_resched() for arm64
      https://git.kernel.org/arm64/c/3c973c51bfba
[6/8] arm64: entry: Refactor preempt_schedule_irq() check code
      https://git.kernel.org/arm64/c/64f4b8b15f1c
[7/8] arm64: entry: Move arm64_preempt_schedule_irq() into __exit_to_kernel_mode()
      https://git.kernel.org/arm64/c/99eb057ccd67
[8/8] arm64: entry: Switch to generic IRQ entry
      https://git.kernel.org/arm64/c/b3cf07851b6c

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:20:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:20:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120574.1465440 (Exim 4.92)
	(envelope-from )
	id 1uwk1l-0008MT-RS; Thu, 11 Sep 2025 16:20:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120574.1465440; Thu, 11 Sep 2025 16:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwk1l-0008MM-OB; Thu, 11 Sep 2025 16:20:05 +0000
Received: by outflank-mailman (input) for mailman id 1120574;
 Thu, 11 Sep 2025 16:20:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwk1k-00085B-Gz
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:20:04 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 2ac85f9a-8f2b-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 18:20:01 +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 6DC0B153B;
 Thu, 11 Sep 2025 09:19:52 -0700 (PDT)
Received: from [10.57.70.14] (unknown [10.57.70.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9403F3F694;
 Thu, 11 Sep 2025 09:19: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: 2ac85f9a-8f2b-11f0-9809-7dc792cee155
Message-ID: <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
Date: Thu, 11 Sep 2025 18:19:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10/09/2025 17:37, David Hildenbrand wrote:
>>
>> Somewhat, but in the regular case where enter() is called followed by
>> leave() there is really no complexity for the caller, just an extra
>> local variable.
>>
>> There are complications where we want to exit lazy_mmu temporarily, as
>> in mm/kasan/shadow.c [1k], but this is in fact unavoidable. Chatting
>> with Mark Rutland, I realised that to truly support nested sections,
>> this must be handled in a special way in any case. To be clear, I am
>> referring to this situation:
>>
>> __kasan_populate_vmalloc:
>>      apply_to_page_range:
>>          arch_enter_lazy_mmu_mode() {1}
>>
>>          kasan_populate_vmalloc_pte:
>>              arch_leave_lazy_mmu_mode() {2}
>>              arch_enter_lazy_mmu_mode() {3}
>>
>>          arch_leave_lazy_mmu_mode() {4}
>>
>> With the approach this series takes, call {2} is made safe by passing a
>> special parameter (say LAZY_MMU_FLUSH) that forces lazy_mmu to be fully
>> exited - and call {3} will then re-enter lazy_mmu. This works regardless
>> of whether __kasan_populate_vmalloc() has been called with lazy_mmu
>> already enabled (i.e. calls {1} and {4} can be nested).
>>
>> On the other hand, with a pagefault_disabled-like approach, there is no
>> way to instruct call {3} to fully exit lazy_mmu regardless of the
>> nesting level.
>
> Sure there is, with a better API. See below. :) 

I meant while keeping the existing shape of the API but yes fair enough!

>
>>
>> It would be possible to make both approaches work by introducing a new
>> API, along the lines of:
>> - int arch_disable_save_lazy_mmu_mode() (the return value indicates the
>> nesting level)
>> - void arch_restore_lazy_mmu_mode(int state) (re-enter lazy_mmu at the
>> given nesting level)
>
> Yes, I think we really need a proper API.
>
>>
>> This is arguably more self-documenting than passing LAZY_MMU_FLUSH in
>> call {2}. This API is however no simpler when using a
>> pagefault_disabled-like approach (and less consistent than when always
>> saving state on the stack).
>
> Yes, a proper API is warranted. In particular, thinking about the
> following:
>
> arch_enter_lazy_mmu_mode() {1}
>     arch_enter_lazy_mmu_mode() {2}
>
>     kasan_populate_vmalloc_pte:
>         arch_leave_lazy_mmu_mode() {3}
>         arch_enter_lazy_mmu_mode() {4}
>
>     arch_leave_lazy_mmu_mode() {5}
> arch_leave_lazy_mmu_mode() {6}
>
>
> Imagine if we have the following API instead:
>
> lazy_mmu_enable() {1}
>     lazy_mmu_enable() {2}
>
>     kasan_populate_vmalloc_pte:
>         lazy_mmu_pause() {3}
>         lazy_mmu_continue() {4}
>
>     lazy_mmu_disable() {5}
> lazy_mmu_disable() {6}
>
>
> I think it is crucial that after lazy_mmu_save/lazy_mmu_restore, no
> more nesting must happen.

That makes sense to me - lazy_mmu should only be paused in very specific
situations and I don't see a justification for supporting nesting while
paused.

>
> Assume we store in the task_struct
>
> uint8_t lazy_mmu_enabled_count;
> bool lazy_mmu_paused;

I didn't think of that approach! I can't immediately see any problem
with it, assuming we're fine with storing arch-specific context in
thread_struct (which seems to be the case as things stand).

>
> We can do things like
>
> a) Sanity check that while we are paused that we get no more
> enable/disable requests
> b) Sanity check that while we are paused that we get no more pause
> requests.

These are good points - and this is only possible with such global
state. (Similarly we can check that the counter never underflows.)

>
> [...]
>
>>>
>>> If LAZY_MMU_DEFAULT etc. are not for common code, then please
>>> maintain them for the individual archs as well, just like you do
>>> with the
>>> opaque type.
>>
>> I see your point - having them defined in  could be
>> misleading. I just wanted to avoid all 4 architectures defining the same
>> macros. Maybe call them __LAZY_MMU_* to suggest they're not supposed to
>> be used in generic code?
>
> Maybe look into avoiding them completely :) Let's agree on the API
> first and then figure out how to pass the information we need to pass.
>
> [...]
>
>>> Worse, it does not
>>>> truly enable states to be nested: it allows the outermost section to
>>>> store some state, but nested sections cannot allocate extra space.
>>>> This
>>>> is really what the stack is for.
>>>
>>> If it's really just 8 bytes I don't really see the problem. So likely
>>> there is
>>> more to it?
>>
>> I suppose 8 extra bytes per task is acceptable, but some architectures
>> may want to add more state there.
>
> Just for reference: we currently perform an order-2 allocation,
> effectively leaving ~4KiB "unused".
>
> If there are any real such case on the horizon where we need to store
> significantly more (in which case storing it on the stack might
> probably also bad), please let me know.
>
>>
>> The one case that is truly problematic (though not required at this
>> point) is where each (nested) section needs to store its own state. With
>> this series it works just fine as there is a lazy_mmu_state_t for each
>> section, however if we use task_struct/thread_struct there can be only
>> one member shared by all nested sections.
>
> Do we have a use case for that on the horizon? If so, I fully agree,
> we have to store information per level. How/what information we have
> to store would be another question.

Not that I'm aware of, and all things considered it may not be so
likely: once lazy_mmu is enabled, entering nested sections isn't really
supposed to change any state.


Overall what you're proposing seems sensible to me, the additional
fields in task_struct don't take much space and we can keep the API
unchanged in most cases. It is also good to have the option to check
that the API is used correctly. I'll reply to the cover letter to let
anyone who didn't follow this thread chip in, before I go ahead and try
out that new approach.

- Kevin


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:20:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120578.1465450 (Exim 4.92)
	(envelope-from )
	id 1uwk25-0000PP-2Q; Thu, 11 Sep 2025 16:20:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120578.1465450; Thu, 11 Sep 2025 16: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 1uwk24-0000PI-VU; Thu, 11 Sep 2025 16:20:24 +0000
Received: by outflank-mailman (input) for mailman id 1120578;
 Thu, 11 Sep 2025 16:20: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 1uwk23-00085B-QX
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:20:23 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 36ea5af1-8f2b-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 18:20:21 +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 D43CB1756;
 Thu, 11 Sep 2025 09:20:12 -0700 (PDT)
Received: from [10.57.70.14] (unknown [10.57.70.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 462913F694;
 Thu, 11 Sep 2025 09:20: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: 36ea5af1-8f2b-11f0-9809-7dc792cee155
Message-ID: <076c7f16-fe56-49a8-910e-7d71d3f8f0b4@arm.com>
Date: Thu, 11 Sep 2025 18:20:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: David Hildenbrand , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 
 <250835cd-f07a-4b8a-bc01-ace24b407efc@arm.com>
 <80be36e5-d6e1-4b37-a1ca-47e92ac21b02-agordeev@linux.ibm.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <80be36e5-d6e1-4b37-a1ca-47e92ac21b02-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/09/2025 14:06, Alexander Gordeev wrote:
> On Wed, Sep 10, 2025 at 06:11:54PM +0200, Kevin Brodsky wrote:
>
> Hi Kevin,
>
>> On 09/09/2025 16:38, Alexander Gordeev wrote:
>>>>>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>>>>>> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
>>>>>> want to use it - at least that is how I read the description above.
>>>>>>
>>>>>> It is only kasan_populate|depopulate_vmalloc_pte() in generic code
>>>>>> that do not follow this pattern, and it looks as a problem to me.
>>>> This discussion also made me realise that this is problematic, as the
>>>> LAZY_MMU_{DEFAULT,NESTED} macros were meant only for architectures'
>>>> convenience, not for generic code (where lazy_mmu_state_t should ideally
>>>> be an opaque type as mentioned above). It almost feels like the kasan
>>>> case deserves a different API, because this is not how enter() and
>>>> leave() are meant to be used. This would mean quite a bit of churn
>>>> though, so maybe just introduce another arch-defined value to pass to
>>>> leave() for such a situation - for instance,
>>>> arch_leave_lazy_mmu_mode(LAZY_MMU_FLUSH)?
>>> What about to adjust the semantics of apply_to_page_range() instead?
>>>
>>> It currently assumes any caller is fine with apply_to_pte_range() to
>>> enter the lazy mode. By contrast, kasan_(de)populate_vmalloc_pte() are
>>> not fine at all and must leave the lazy mode. That literally suggests
>>> the original assumption is incorrect.
>>>
>>> We could change int apply_to_pte_range(..., bool create, ...) to e.g.
>>> apply_to_pte_range(..., unsigned int flags, ...) and introduce a flag
>>> that simply skips entering the lazy mmu mode.
>> This is pretty much what Ryan proposed [1r] some time ago, although for
>> a different purpose (avoiding nesting). There wasn't much appetite for
>> it then, but I agree that this would be a more logical way to go about it.
>>
>> - Kevin
>>
>> [1r]
>> https://lore.kernel.org/all/20250530140446.2387131-4-ryan.roberts@arm.com/
> May be I missing the point, but I read it as an opposition to the whole
> series in general and to the way apply_to_pte_range() would be altered
> in particular:
>
>  static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  				     unsigned long addr, unsigned long end,
>  				     pte_fn_t fn, void *data, bool create,
> -				     pgtbl_mod_mask *mask)
> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>
> The idea of instructing apply_to_page_range() to skip the lazy mmu mode
> was not countered. Quite opposite, Liam suggested exactly the same:

Yes that's a fair point. It would be sensible to post a new series
trying to eliminate the leave()/enter() calls in mm/kasan as you
suggested. Still I think that it makes sense to define an API to handle
that situation ("pausing" lazy_mmu), as discussed with David H.

- Kevin

>
> 
> Could we do something like the pgtbl_mod_mask or zap_details and pass
> through a struct or one unsigned int for create and lazy_mmu?
>
> These wrappers are terrible for readability and annoying for argument
> lists too.
>
> Could we do something like the pgtbl_mod_mask or zap_details and pass
> through a struct or one unsigned int for create and lazy_mmu?
>
> At least we'd have better self-documenting code in the wrappers.. and if
> we ever need a third boolean, we could avoid multiplying the wrappers
> again.
> 
>
> Thanks!


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:24:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:24:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120606.1465460 (Exim 4.92)
	(envelope-from )
	id 1uwk5p-0001Jc-IK; Thu, 11 Sep 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 1120606.1465460; Thu, 11 Sep 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 1uwk5p-0001JU-Ev; Thu, 11 Sep 2025 16:24:17 +0000
Received: by outflank-mailman (input) for mailman id 1120606;
 Thu, 11 Sep 2025 16:24:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwk5n-0001Iy-Sk
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:24:16 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2412::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0d96387-8f2b-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 18:24:14 +0200 (CEST)
Received: from DS7PR06CA0041.namprd06.prod.outlook.com (2603:10b6:8:54::10) by
 BN5PR12MB9461.namprd12.prod.outlook.com (2603:10b6:408:2a8::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9094.22; Thu, 11 Sep 2025 16:24:08 +0000
Received: from CY4PEPF0000E9D9.namprd05.prod.outlook.com
 (2603:10b6:8:54:cafe::1e) by DS7PR06CA0041.outlook.office365.com
 (2603:10b6:8:54::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Thu,
 11 Sep 2025 16:24:08 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000E9D9.mail.protection.outlook.com (10.167.241.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 16:24:08 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 09:24:05 -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: c0d96387-8f2b-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Hi3lsTTGtnRl3WZU5i/qVCnP7FSiKmRgkgRbZSCOBNk+yofcI9h1seiq+SNlq6YDrqlUaHP5c+GAk5RiTbkiwqD8rVD0s7lWQeO19jSAXO+wtA8TDTIfheY0lL7GAHXdBdQTBGt2LIVHIRuSeHUWJ1dxWy+ycsP4UZ7ccs7AIr/BRDPWInywu3ZeLX4kOXSfgyX85WEntAG+QWksXp3bz+IJXD1AyyADVUuC1xW6Muo7WB0HT5JaFp1w5iva27GxHUvO3vKKYgu+L6yEUl44ZnUZFyCA0QFoQV4kWTCjsp/RiLlNOzwDVJBqbGck66zvOP59fARDhAI07R84x/ZyCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oC0zV2Rn5tEKRCNSHpot5uWzS9t8S0EwSLusR4mEgMI=;
 b=I7D1LZrIW/BvXhJ9Gv8LApfnVpNbwbTS9TmNWCj5SmzWHKBZUTQdZi4NytMtK5YUEc52ozJWI6M2SnPlar5IHl7NDtjc89vXo0ddagu5srDDI1hUfzwCyMZ1BCvwq3ECd77StKXvfD3e7sopCi4ej7vz55qQkRL7IIYe7x/aEEtOA1PCTnKJcjjGCIihnyrU2DxHkeFKaP8KsC57UVL58eHhQ3Lx6B7GMl5c34q1q7lHD1j4+Z8Oha1LfpgLiWayScZ91/sBkwLeF/Aq9+cUnRS4aCjsa/ch6G6zLYLvIV8pSgl7bpjJRnUF6lgbOgbtK9iJHkfjRmHFcZO8aXFgyQ==
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=oC0zV2Rn5tEKRCNSHpot5uWzS9t8S0EwSLusR4mEgMI=;
 b=E+oU4Ix4Cx+u6gYRc2f9Iza0HKfDCpfpWeZ7/Ph32Tor03MVRbSyDBe9oJIU6m+KUzKugdFIV2f+YZxbYo6aN0X1YZKY69r5mjaCzdpFqx+27JVYQnmcMfkuxuVqHNs3wai1NnXjzxx3W8VnCM+kL8nKC+k384WXMrpxCCjUT50=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD , "Grygorii
 Strashko" 
Subject: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting memory
Date: Thu, 11 Sep 2025 18:23:32 +0200
Message-ID: <20250911162336.23887-2-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
References: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D9:EE_|BN5PR12MB9461:EE_
X-MS-Office365-Filtering-Correlation-Id: 86ed1138-6a2c-44fe-cc9e-08ddf14fa235
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?wzc3tZPFzuIV7/5G2cOi6jxg+ndRHsUx+ij3LA+6IkYxlww/Aay/b9h0MzM6?=
 =?us-ascii?Q?EtbdeBi9jQzRmo+QNh6lQFK/SC8jaLWpU8FBLmaF19IonFaCGqTA3BeIGpaj?=
 =?us-ascii?Q?hQ6sCO1iL5ADKljPWVar7x32LTxEDLJJMH9LzD+sUWGn3IKREUZ/RfR6H2W/?=
 =?us-ascii?Q?eS2J9txnhXM4QHEE7dTVjSfMDWde/DmlY6nwjOyMEwSP6qZwU+k4oLdummkn?=
 =?us-ascii?Q?ODHCKPKWoC6NzW4koWc6F2YCoqwtlBNlRSYif/YCqZwGep1th+3tXTjIH6Ed?=
 =?us-ascii?Q?AQbmKS/sc2fpbTpIk1sowZcjPQbKpKizndBnSpfEJIpXEZRcWQTbcaNh3mzv?=
 =?us-ascii?Q?6QzmDRbFqxYI0n3CD4XS8iSTDl9oIEGrZ6ubXeucdwaf42pS5QaZspuHMABP?=
 =?us-ascii?Q?rqdqiEMBtDEZfOP30b6ZMqPRrAugSsu06157mEJJc41SnJeV5mPq0oz9LBB1?=
 =?us-ascii?Q?Yhw78U+8uzmH8FKBID0DB6v+cTF1LwXc0d6DU5fJYfD2ZqGdrz276K/pR91W?=
 =?us-ascii?Q?jtYqun+4g7QQgoDa5gHNsqWU04JUDHNUpotlmKORkHhcX9N8zm4GsfJ1tau1?=
 =?us-ascii?Q?ErQO2Wf029/EtwfI8/1nUFKIBoPDrRCbJmx3GYOn32UfPRvlY+5663KjzVlI?=
 =?us-ascii?Q?4khQ3C7t4WqiAWPWSXH6NOHTLEXnc12tw1wic41TpW1NlV2Z67h1odC5XH1V?=
 =?us-ascii?Q?+bA7c4aw7nZNxTDhm5rrJ9cAnr64ICuUYCyLk38FwVWwvwxE8P1S1eX+S7+r?=
 =?us-ascii?Q?2m7jTWlMG6Zw2v/Sc5RgDotCqL0/nKqxxVMPJ8or4qbSnkFYxEj1iQKG/R81?=
 =?us-ascii?Q?xyG0Hj+zUcTvzNSRlnNNDL4sB6zifsdiX9VzJbcDADvJJeZE/jcj/UyPkexa?=
 =?us-ascii?Q?Y92CMdVD7anMgaZCsn8qrv9A5Q1ys4oBKevpruFEntmZ2YbQCfcLHKU6OIey?=
 =?us-ascii?Q?VvZPhIcHq6DGhqgrHTYXBe2ucMcOgG8cMjElyGVv+WnodDIc3Hx5SEBZqMY6?=
 =?us-ascii?Q?6ejhEYtOlJ9ZLNx4ezf+ktVMPQm6Wa0DD5GQ+KAhZLQpWxR886Dc81tQ0tJu?=
 =?us-ascii?Q?nG/pWcoXR88uKJ/hCgnabkZUMiy/CXO+enJtH805GW547VgrHQ2+QPLF8mvP?=
 =?us-ascii?Q?UodU/DmGzaE+VeM4G/e+B1E6cnTpVV2xLZ++Ru6vMVl933CbvE9bzzXkapVF?=
 =?us-ascii?Q?lhQ7vzuFeWvi1Hr22HSfTQLSHSAdgW9SfjQA9Mk4F7kDO8qT+gy/0M9qdZ5f?=
 =?us-ascii?Q?Q+TWZ+LC47esJaqb74kcLcyrsW/M9v5z7R1HkRoA5ygbmFAqD/EpQZRRUhVU?=
 =?us-ascii?Q?5QHRGlTT3a1xXhANcf9MZAsbxhBV/eejffF/StTq++yKpi1mgUcnZmgnJ0o7?=
 =?us-ascii?Q?Uot3pxDg1Kzqv1ZByqEYoAFluULAPNoDIODUEBszMOkvpSgwGMvQT+imBFik?=
 =?us-ascii?Q?ZqFe7/4NYuFDZIhs/purWWUT1MNb4hIIOJZWD0Rfv1KQwEhkTq+L1Zf/URDw?=
 =?us-ascii?Q?VbTuiaGq4ZCPQ01yC3fhxo0RfPJVAJg0upWj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 16:24:08.1746
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 86ed1138-6a2c-44fe-cc9e-08ddf14fa235
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR12MB9461

CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
by the device model. The GPE handler checks this and compares it against
the "online" flag on each MADT LAPIC entry, setting the flag to its
related bit in the bitmap and adjusting the table's checksum.

The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
reaches 128, even if that overflows the MADT into some other (hopefully
mapped) memory. The reading isn't as problematic as the writing though.

If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
then the bit where the "online" flag would be is flipped, thus
corrupting that memory. And the MADT checksum gets adjusted for a flip
that happened outside its range. It's all terrible.

Note that this corruption happens regardless of the device-model being
present or not, because even if the bitmap holds 0s, the overflowed
memory might not at the bits corresponding to the "online" flag.

This patch adjusts the DSDT so entries >=NCPUS are skipped.

Fixes: 087543338924("hvmloader: limit CPUs exposed to guests")
Reported-by: Grygorii Strashko 
Signed-off-by: Alejandro Vallejo 
---
v2:
  * Added early returns in AML rather than dubious And() statements
---
 tools/libacpi/mk_dsdt.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 8ac4f9d0b4..aeeb71dfe6 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -231,6 +231,20 @@ int main(int argc, char **argv)
     stmt("Store", "ToBuffer(PRS), Local0");
     for ( cpu = 0; cpu < max_cpus; cpu++ )
     {
+        if ( cpu )
+        {
+            /*
+             * Check if we're still within the MADT bounds
+             *
+             * LLess() takes one byte, but LLessEqual() takes two. Increase
+             * `cpu` by 1, so we can avoid it. It does add up once you do it
+             * 127 times!
+             */
+            push_block("If", "LLess(\\_SB.NCPU, %d)", 1 + cpu);
+            stmt("Return", "One");
+            pop_block();
+        }
+
         /* Read a byte at a time from the PRST online-CPU bitmask. */
         if ( (cpu & 7) == 0 )
             stmt("Store", "DerefOf(Index(Local0, %u)), Local1", cpu/8);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:24:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:24:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120608.1465474 (Exim 4.92)
	(envelope-from )
	id 1uwk5q-0001Y6-AW; Thu, 11 Sep 2025 16:24:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120608.1465474; Thu, 11 Sep 2025 16:24: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 1uwk5q-0001Vw-4c; Thu, 11 Sep 2025 16:24:18 +0000
Received: by outflank-mailman (input) for mailman id 1120608;
 Thu, 11 Sep 2025 16:24: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 1uwk5p-0001Cf-8y
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:24:17 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2416::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c19072a0-8f2b-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 18:24:15 +0200 (CEST)
Received: from DS7PR06CA0039.namprd06.prod.outlook.com (2603:10b6:8:54::7) by
 MW4PR12MB6897.namprd12.prod.outlook.com (2603:10b6:303:20a::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 16:24:07 +0000
Received: from CY4PEPF0000E9D9.namprd05.prod.outlook.com
 (2603:10b6:8:54:cafe::e2) by DS7PR06CA0039.outlook.office365.com
 (2603:10b6:8:54::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.17 via Frontend Transport; Thu,
 11 Sep 2025 16:24:07 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000E9D9.mail.protection.outlook.com (10.167.241.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 16:24:06 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 09:24:04 -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: c19072a0-8f2b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=khpTxSjS5qTCijoQK2D3WJJ5sRYAWSH3PHWGbTaf2Z3W9m0dVCAi33D1DX6XLZav3GbzeXgrLgycqoQT47R71EErWFMTgQw9YoWlBsZd+r0FnW9MZtGF0Kxnb1QJcCfizBtgFZ2qp5bv0ywCTkz2o3sLj8nAx9mWhFg2/ZFBMK1CrTQt2fFyzH5QnbrzmNXra50AjQk5QcBeHDo3EtQkj3BuI3AQVvJpTLLBx6MiElYqv1JEUzqbcJhW9KwACk6xSWBBD+BsMHslybMvOTfHqufVHsLBCKzvWBZMWraR054gl+hBw/JsDF/Ur91CbCiTpj0VP+ySuqPH80k9veBMrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Fn+dK7+SCQSLAhJxI3AXAoO++irC+zRNHzsL5Pd8Fv8=;
 b=CDC6vhVVbToYct/gaay2+pBiQ/ypxzd6dJnPkYfiWMHMdUTgaTzuj8s6nZ6SCkryzOlufwzTikRfkn86ah2BImQqodSnlmazMO0MaQ8tQTmW/PQlGRcDfFO+FrytLBXIBY0kU+Fa0AbCgrC0KnFGJ1WmjK5PkwuUR4JLoHMJPeOEneHjHYFxeAzFz6WfuHBjEovrs4MUA8BkhGB/GB3WQwdmGfjHBMAT8OCWjF+SHrtp8BbqtWPio9NX/0p/wUrgvqQNutgv2Ssr1I85CQAo8RP0abLS+MsIJGLBYdm9Sh1Uzui73wRS/UftcX2eu0hFcLISHVKrN6HF4LJxpoCAUA==
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=Fn+dK7+SCQSLAhJxI3AXAoO++irC+zRNHzsL5Pd8Fv8=;
 b=YsJGwqUKHYsJXbI6xk6BqdETVrIDlLnINjwRb+XQ2sjJvK4edCY0MMbzc8MtrNWyZPsqGFto2MkLCpKth8sox4S99weYf/PE09stT0cxf69VbtsZ7Pkkci2qV3JJKKXEipH9XtoWegS9NiSc1GP3rktYMtAXUMNWrtIVEwW969c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD , "Grygorii
 Strashko" 
Subject: [PATCH v2 0/2] libacpi: Fix memory corruption on ACPI CPU hotplug
Date: Thu, 11 Sep 2025 18:23:31 +0200
Message-ID: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D9:EE_|MW4PR12MB6897:EE_
X-MS-Office365-Filtering-Correlation-Id: 4c0f4a41-b11b-4805-1df6-08ddf14fa151
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?2my4Kcx7Fld+iIGETGdqLpToyuu+3MRnIP2X3t1BmOA8RyUR2yBosVj0phxp?=
 =?us-ascii?Q?tfjdoJunZ3AvdCLt4p37bFyBSJBBnDexAT+pD0vrVd2AcDwV+CjtP6Nkf/8y?=
 =?us-ascii?Q?TcE/1E++pDW164ZtkTPk6LSvIBcN2BEQVruLzekomTt3sibOS560qLz0zy6w?=
 =?us-ascii?Q?oAOC7MkLU0Zgp6hDyuWZqtaewQtHy0e+bXPnnVA3WO1rGT7n6GNIHkY5C6F5?=
 =?us-ascii?Q?YmJ6i6sQCJJxMlMqn0AuF9GF342SLJVSNXJvVVE/mcUbTf0Ec6FX/LrzqQ3n?=
 =?us-ascii?Q?Gqw6av7RWSBmUfhjbQKUgkuSvysx12S/D+7IguzmBp5Xx+GkzH+myxwJVZKg?=
 =?us-ascii?Q?GnOMPu6uTwGYrF7JItNbMGjDKoXUZHAkgGXHSuiEUckTbURwyUIL/6iAGyDA?=
 =?us-ascii?Q?EsMOX9+3trs20D3YGn9hmnt2f1QDqFzsV6GmBhYh1j8ZxMQqw7D6Dt2Sv0pi?=
 =?us-ascii?Q?I5naSnzIVlzpNxLbkCtEbrYymg854Xh4IkbCR+RSz0dAlaloyi85fRcngGIU?=
 =?us-ascii?Q?BuRm9ZqFwAKq8rcL+U5ZOAcifOpzdS1tPVZuS3uJikyFd8IzYzOzKVWeaYeD?=
 =?us-ascii?Q?P57bz4yvqlyAgaZ51vZMrfKPXa3lGkVSAqcGhpMvEvJOU8xjFnoiWKL6Sybw?=
 =?us-ascii?Q?xCGX3ZboLolrvz4Gixbr3EZ7sc3DY9lyN/zJ1Y/9BhD3jFbum6wX/9smrhqj?=
 =?us-ascii?Q?VifqXD9IhgEk9YxDfOZuq3CI4A0mVZpxayNOLcvPuNx6/EGzTNEzx9R7OAJ+?=
 =?us-ascii?Q?sKI7CTO6ZezPXk7aH/nOZ3xhhjsXCa6dNKj2fWc1FSiwRjMaVc96FxWPJxqD?=
 =?us-ascii?Q?cF8ixVfWkXG3BCWaYVNMmwdC7tf4QupeeLM/U0qXR+E2AfIsq5hsFASnWSf1?=
 =?us-ascii?Q?0bT6XbgONgjFX7Fl+pdipvyB4up5gROoU6pRp657tAy5P5E08SjWB5dcc1OC?=
 =?us-ascii?Q?9gVigYaATFRV41sX/yymOjA2O6ewg8smfxKhnbY39ESZD3L+It3ZjRDwC3go?=
 =?us-ascii?Q?B3vVvE1gFXlMckwGJ4LUzEWEDZe2ffAM3VURmOYh3MrO5o9OLl3X6zwKKaty?=
 =?us-ascii?Q?Ch3QWUOW96xFbESoZyl6QPPvHDESIiQvOur0tJqFkbDllt/tEA9E21Xh/zgY?=
 =?us-ascii?Q?bKHayjdTd2KzM+4/t6Xd+tfuO21vPaG6wEbYKhVF6OT7+dcegNlZkUvmHJwg?=
 =?us-ascii?Q?S5EHIdkNoEiqs7uaQTZM6CpX5NrhI8cgg1eR+bgNptp2qLRzoP3wAJ+IEBEY?=
 =?us-ascii?Q?RR9KJgA93Qnx4S1H61Utoef7x7Gew0r3vcLgJwCIgF3Zts6M6Vte87aXvYL6?=
 =?us-ascii?Q?Exc2xaMyrxDMzlEQ+StE1wsQPp0HhCVYGVFT8iukrqmheAi/I4wo8sDECQ0b?=
 =?us-ascii?Q?6AyyqTFdRl/cQ8E91l4otP85mX9IjMjoCF7AqDOiPpuTGwXPNuyHyuL+WMG9?=
 =?us-ascii?Q?dzmargS0l2QFVaJs6w5qSmMYddCpN2NK2cvzE7aGRAF1nd5q6NVl1p5UyCrS?=
 =?us-ascii?Q?mC70nJCfuKJelNaOK1i0MlfwtqnYDgMIl8/AlMpZjeObxyHWfA9YU3tduA?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 16:24:06.6751
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c0f4a41-b11b-4805-1df6-08ddf14fa151
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6897

Hi,

Both patches are independent Patch 2 can very well go in before patch 1.

pipeline:  https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2034774204
(still running as of now)

      v1: https://lore.kernel.org/xen-devel/20250911115308.16580-1-alejandro.garciavallejo@amd.com/
original: https://lore.kernel.org/xen-devel/20250910144921.29048-1-alejandro.garciavallejo@amd.com/

Cheers,
Alejandro

Alejandro Vallejo (2):
  libacpi: Prevent CPU hotplug AML from corrupting memory
  libacpi: Remove CPU hotplug and GPE handling from PVH DSDTs

 tools/libacpi/mk_dsdt.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)


base-commit: 16fae1561354f35dd524eb8953385d31eac3ce37
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:24:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:24:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120607.1465466 (Exim 4.92)
	(envelope-from )
	id 1uwk5p-0001Mp-R2; Thu, 11 Sep 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 1120607.1465466; Thu, 11 Sep 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 1uwk5p-0001MT-Mc; Thu, 11 Sep 2025 16:24:17 +0000
Received: by outflank-mailman (input) for mailman id 1120607;
 Thu, 11 Sep 2025 16:24:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwk5o-0001Cf-8m
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:24:16 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2415::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c0c4921f-8f2b-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 18:24:14 +0200 (CEST)
Received: from DS7PR06CA0050.namprd06.prod.outlook.com (2603:10b6:8:54::32) by
 BY5PR12MB4275.namprd12.prod.outlook.com (2603:10b6:a03:20a::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 16:24:10 +0000
Received: from CY4PEPF0000E9D9.namprd05.prod.outlook.com
 (2603:10b6:8:54:cafe::1c) by DS7PR06CA0050.outlook.office365.com
 (2603:10b6:8:54::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.17 via Frontend Transport; Thu,
 11 Sep 2025 16:24:09 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000E9D9.mail.protection.outlook.com (10.167.241.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 16:24:09 +0000
Received: from xcbagarciav01.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 09:24:06 -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: c0c4921f-8f2b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=owQsLgEBMOB4Jze6ao1TndqGxgM1Vq0Mh9ALelut3w1XenspII8NeNpdfTBE2V4ebSIF4ErkifS2l4yZhDk2PzM5BamexAebqmeTz6oixuQl5ILnGx0xaCDN9bf+vPMb7XuUvasTzCiIBycu57nvcrvTP8lyACFhjc/YJDjdPwHySHXsajFd2XSuvpOBXP6MDp43Awek0ikWmfaULWk4jeKhIjwBka8ViGagZe60hZVEZg0HpalaiZla6/v0Gxkg0C77jStuR3w0WrcZ0DpAEM/uy0EeGw/vrtiBGHxAF34zyLV3tDx5mFpAMZL/I9o+eNQcDA2boJIhKeHD2wPhFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fZp8fHLc0jXPIevCWfpyhP3DSXtF3QrqNtbiS4xuVfw=;
 b=vBiyf6+Mhi37JqpTXaze3qOY0g5INhB1k4nWjLa10cZgi2JaqZ6n6fARc1HD9rLsXKszNedi4xylLGVbgFY8M4k0OY0opnM2dcd5bQRwBjQDPSnVAzAs+zTSRSFM4xxPfoPf+E4YRXrg3do2N9AqM5G08VV54dhGe0VOZvgFvUbe83gaXwEL/EJN2GguoH9yANK1Nas+EhxonE8XsmFUQCBponqrmLk+kvmUbqmwPRyofxhoH1bqf0i4vSPBWq1J10lEhTZH5mAHJGLyria4KipfOVrstpAwyGCtOuoJIQepZjdzq6btY5EBwCEUioWO0R9uhLihXeMgQ35DOHuTBQ==
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=fZp8fHLc0jXPIevCWfpyhP3DSXtF3QrqNtbiS4xuVfw=;
 b=dwDKIqCgLjxWsaM5muGIFkegyWffMtsDFXi3r6nqU9I5VpOHOpiRVxVNNeuPQGpJ7TevNW/SbOEU2iXo86byQ07I/JTFc9f4zFRmTK0ffJTYtHyJXm+Ga9XVQgTmNXX7a/ip8OQemQHBlkAleq76FI0eelrqBRWIwgcQ5xw6fsI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich
	, Anthony PERARD , "Grygorii
 Strashko" 
Subject: [PATCH v2 2/2] libacpi: Remove CPU hotplug and GPE handling from PVH DSDTs
Date: Thu, 11 Sep 2025 18:23:33 +0200
Message-ID: <20250911162336.23887-3-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
References: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D9:EE_|BY5PR12MB4275:EE_
X-MS-Office365-Filtering-Correlation-Id: 1e7da137-3aa5-4415-22d4-08ddf14fa32a
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?VBaRImzOJB/Awv2DQSyzwa6s6EXqs8UQ4euJVX8uKiEh3dGL72F9QE0cNoGg?=
 =?us-ascii?Q?Ekd2KJF49OvuZbawdK802b/uTA+s9DUgut+I5X6jgOG8eY8OMXPhiTK9IEwm?=
 =?us-ascii?Q?mIVohJLFyMk8LfE9pqrk9Fub0U+fHa+hfnGRaCywlzRqX3yBBqo4l9NKsifi?=
 =?us-ascii?Q?HN/q5Rnk6yQf2Kd11JkLazTfTOgXU+78/lfyn0iiKUjbs1nmymmHnm1PmeZH?=
 =?us-ascii?Q?OCtrnN27oze/dHe3J5n3acQm27B2w44ZHHmR1fZuxky3GJEpbHDiyka1SruN?=
 =?us-ascii?Q?C/MEmotfR+IlhIxpDQjj9FNrS/G1mzouiXpmiyZKA8s13TVig4eu+DVpApNO?=
 =?us-ascii?Q?uXMAAfYGufo9VvhVwPmC8IvPn44zwdlH2RxSYlL96Bj2UVMShKPBt8nD1z5J?=
 =?us-ascii?Q?Rjss78VIGU+XiLOSq/OqYHXN02y2JbSKuJP6g2MBk9JMmsnVmkqEQNJBcK+b?=
 =?us-ascii?Q?ZfH66NbuWHALcSGAzRFWaryV/Ivd3R2fQ1DsqzsnvHqXNCrS7YlryHvFubTb?=
 =?us-ascii?Q?LS2rV9hXQ5jOyznLA6ku7VvFowcD6O7G4srWsy2bcTwV4l2BGO2rOyJKPu7j?=
 =?us-ascii?Q?uydS8pp4A8RJ1oZ6dXZx3z3uKBBRG+8NBM4h2fH21O9uQTu05pr4vIwUV1YF?=
 =?us-ascii?Q?V3FnSSBzPyCSaCAJ/YCmW7ueqp8HXJ5KJ8ZvgeSpqN6+H0j1CyLki/r4Gb82?=
 =?us-ascii?Q?XK+BFyF+U/5MvDTiifWStOB3LihIV1ojQ/RzsAP6Dr5X4YxTmapyvBopVvAp?=
 =?us-ascii?Q?J5blB2UxMBb9/eZtQ2r8ig8UVSNqbUBykyL+cN2WEX7+m5lmDoWjPDsHF9HE?=
 =?us-ascii?Q?yjLQTqPiWf66mrPAgayUQzsKUlxvIqVs4JBq+CXcSnC5DjJzZQsC4/4k7Lim?=
 =?us-ascii?Q?dalVYEl9Rnkaxp5oeYym/PoC0qhKxUs1bymKLJ1iqNqEAGXycTeIRjh3LHtT?=
 =?us-ascii?Q?pFixfAC7b0dZdVJe6DIH3VCK/jNoL+xNZo3c0uUkRCjoAHasTtJNXmDkPWBa?=
 =?us-ascii?Q?UqTioAtT5ShmOApwc38QoVT7jHZsnlpXcva4rwKZZvIOTWZ6vKZvnbwo8bSW?=
 =?us-ascii?Q?pCdIpmZuy4GJxWGbRhzKyxTP1aLKhsLUMJildDrhICkVNcQrsvXr3pqY0jAZ?=
 =?us-ascii?Q?LIoZV+3NEvI2ZGvCXWp+r+ztBwG0yII+lCU+y2NJczdTEYgRlxNxatq4xgrN?=
 =?us-ascii?Q?+BVwxBjbX0z2VjqSmuJGyLhjopjujt9yCK+5Qw676qgSY2IfA+r0lYydnwlg?=
 =?us-ascii?Q?QbU/bKcuH8VXZN5TXG/FQzZcRiFSZrgt39b6u5QckuE2oa1M/+ijlVdEfzUN?=
 =?us-ascii?Q?O5iyFjgT+rzpoa4YTeCCRapkRWf2Sk7fyOk7jRGqQLrpJ/p8+WMz8u544KE+?=
 =?us-ascii?Q?KwFoScXYw8M8SchHvEKL/QFMN9S6UnupO3On952l1tUaAcH+tjt5lBrPuP42?=
 =?us-ascii?Q?c801THdeSNvQh6S7w2+buflXbsZnXpNdxI06lpw1tzodhpUrMahmcx38bSS3?=
 =?us-ascii?Q?RFQOq7btJ8oGI/KEoE62PPLjjR3W3ULBI/YQ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 16:24:09.7769
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e7da137-3aa5-4415-22d4-08ddf14fa32a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4275

PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.

Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.

This shrinks PVH's DSDT substantially and prevents spuriously executing
a large amount of AML with no purpose at all.

Fixes: 062975dc9441("acpi: PVH guests need _E02 method")
Signed-off-by: Alejandro Vallejo 
Reviewed-by: Jan Beulich 
---
v2:
  * Added Fixes and R-by tags
---
 tools/libacpi/mk_dsdt.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index aeeb71dfe6..433eb4f8d9 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -218,6 +218,11 @@ int main(int argc, char **argv)
     pop_block();
     /**** Processor end ****/
 #else
+    if (dm_version == QEMU_NONE) {
+        pop_block();
+        pop_block();
+        return 0;
+    }
 
     /* Operation Region 'PRST': bitmask of online CPUs. */
     stmt("OperationRegion", "PRST, SystemIO, %#x, %d",
@@ -278,10 +283,6 @@ int main(int argc, char **argv)
     pop_block();
     pop_block();
 
-    if (dm_version == QEMU_NONE) {
-        pop_block();
-        return 0;
-    }
     /**** Processor end ****/
 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 16:47:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 16:47:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120661.1465489 (Exim 4.92)
	(envelope-from )
	id 1uwkSC-0007F3-2t; Thu, 11 Sep 2025 16:47:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120661.1465489; Thu, 11 Sep 2025 16:47: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 1uwkSC-0007Ew-0F; Thu, 11 Sep 2025 16:47:24 +0000
Received: by outflank-mailman (input) for mailman id 1120661;
 Thu, 11 Sep 2025 16:47: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 1uwkSB-0007El-2W
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 16:47:23 +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 fa8ad360-8f2e-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 18:47:19 +0200 (CEST)
Received: from BN9P222CA0029.NAMP222.PROD.OUTLOOK.COM (2603:10b6:408:10c::34)
 by DM6PR12MB4203.namprd12.prod.outlook.com (2603:10b6:5:21f::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 16:47:15 +0000
Received: from BL02EPF00021F6F.namprd02.prod.outlook.com
 (2603:10b6:408:10c:cafe::ef) by BN9P222CA0029.outlook.office365.com
 (2603:10b6:408:10c::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.16 via Frontend Transport; Thu,
 11 Sep 2025 16:47:15 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BL02EPF00021F6F.mail.protection.outlook.com (10.167.249.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 16:47:15 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 09:47:13 -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: fa8ad360-8f2e-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bMwudRTYnfywoBL63X50/xGeCCpnZv//tzghqtzZ9zlSQXU0ZySKwTd0O5lG8PKIETuAqyYgdG+Fk8UVB2+PV2jJqe5L0fCM9QQSbLC+qwKdLYP2+EXmomnmXecM2A9zGXp63KlpxB38AKictGF0W+v/84REieCcXXD+LZOkHCQ32q9mstOpz9qEdJSkPm3F4tACGqBE51Nc0kvYoB94wyR0z/LfIVG0glEQwyNJf9QrkYfGpc2dcx1ws0E46/irqZlMAfd29R0H6YFd2F/b2v/sTHvDMy5Ddagjz/3GgFNFFTflzzQwr1XLEFvhQbXYWlmaapj9h4xPTRzKx7S3rw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qyl0XrpajtGk8BJ+o2kIi42BC4riVLLVKAl8oupkkRM=;
 b=cKXy0T8Wbj1R3DSJqCVaEndJqCooGsdVfJ8QagdC25w2fm35R+MTE6x0yiYzlz6dNIhfTUspuxc9l9LTwMaruOLWcFsh8GEhEQ8tNNupVHQ+7frhvZflmgLDcv1ydDH11Lcw/5xrd3jlG/EErkxyf+cCAsc1lH+nUuH8LM+kKWMijukhYeBNZn0sLQKka4b+6CgpPNcfXN2mgdAm7B3KsvRPzpFZI6zobXKUgxD/xe6ITnmN4m4yPlAMlx4z/iTjgEUN3dBShjsphzmotcWbRVw6PWo3mHaQ5tff3kdmJmTnibECtqCe8hEvRiVZ8ikElxCsginZp/SNHnt/NNdosQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=cloud.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=qyl0XrpajtGk8BJ+o2kIi42BC4riVLLVKAl8oupkkRM=;
 b=TRTdOwrN3j9loHgsEzMMXFrciQotJAeHJbxoySFlb+EnaEiqp4UqWnGXVlnWRuvmIZfRMXCcAUXhOZF/trk8/6gkuMarKPseFL7Th/czf2gmYQQFQbchD8NHpF5eH+LnqIYCHjr51aI6z4pBbgvrqa4ia2cmjPEmu1vSZU2bq08=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 18:47:12 +0200
Message-ID: 
CC: =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=
	, "Daniel P. Smith"
	, Jan Beulich , "Andrew
 Cooper" , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH 1/3] efi: Fix line length in init_secure_boot_mode
From: Alejandro Vallejo 
To: Gerald Elder-Vass , Xen-devel
	
X-Mailer: aerc 0.20.1
References: 
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF00021F6F:EE_|DM6PR12MB4203:EE_
X-MS-Office365-Filtering-Correlation-Id: 533fc907-07ba-4cd1-e831-08ddf152dd2f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|7416014|376014|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?V1JlN1MvWWoyNVBaa2hZc3MxZ2kyRGplQkRpekp0SFVzbkF2T2tCaDZMNFpj?=
 =?utf-8?B?TzB5eDRqNk5qaDUrR3JUMStIZXkySEN4bDVHdFdMVE03dXRGaUI0S3Z6SXRm?=
 =?utf-8?B?ZU1vTmJ5VXdzTzJjazMxMGZhWjNlNWx5dmZicExUWG5STjk1V1AyOVplQVlG?=
 =?utf-8?B?OVd0SFVFVkN1cW1oUkV4S1NiZ05PYkpHbDV1UDYwYkRITmk4cW40bDR0cTBt?=
 =?utf-8?B?TXoyRTVNeHllcTBibU5EU3VNSUdKUWtyMzVtMHN2dnc1Y3pZdlE5aEU5QzVK?=
 =?utf-8?B?Y2dnaGp4WTJDNXdwUy9JQkQrMTFNUU9RRER5MjF0VkNIOG92Qzl2aUsrYy9h?=
 =?utf-8?B?UkhzWEljUm53dTJrQmpETXk5cnI3UG1tMy84cVQ2QUlodHhLU1BVVFNpTVBo?=
 =?utf-8?B?T1ZFVWZQUkg1NWlIRDlhd0dSbit5bFNuRzV3NFloY2puTTdpanZ6M1JySTFl?=
 =?utf-8?B?N2sxZWJnVEwvWkFOVm9hQU9qSXAyVGJCbGR3NnlBMC9jemNZLyt6NFlaOFNp?=
 =?utf-8?B?Nk5vMFZrT3BzZWc1cjJXVUMyTXlyZHhsMk9lTHlpZFIzM1orL1R2akF2UW5x?=
 =?utf-8?B?cFQxTjg2UmpwWVh2OEsySit0clBwNm1hZDVUVlMxZ3c1Tzc2S29IRGVtbHZN?=
 =?utf-8?B?OFdNSWIxRE1WZnZvUmgwQUVZdDYwRTRaTUk5eFFPZWxEdFpmTEh1OWZhbktt?=
 =?utf-8?B?cGxJd2V1Qytsbm9XeVpWanQwWWprclhsMzdoL0JDWlNwWDMwR01kRjJOZytP?=
 =?utf-8?B?VGVBR1dpZXBlaytpelhNYjB1c3poL2pSOThCTHp4Rzdla3ZiaU8rdk9HUDVI?=
 =?utf-8?B?cW5Da2NFTm5DWXpPYStZbTRUdWV2enVWQ2FLTzJhNVkxYUVxdENYUE55NDZM?=
 =?utf-8?B?b2RYeU9KaXFqK0xQUnZENHpTSjlLRXluTFRxWjN2R1NwTU5odzFCRDRJR01l?=
 =?utf-8?B?UWcvZlIrTlYxUkI5MExDdFhFcU15bW9meU13YUJMVkhWWWlqakJTWHpkQ0oy?=
 =?utf-8?B?Z3VzTDhjRnJ1ejM4dys0NVpFZE9GK3lOVHRoOFBEeUpNa0NBWGFjdHR2Tzgv?=
 =?utf-8?B?dmdjcXhVVFpKZHFxRThrcHJkcWl1M3RYMlc5TklOcko1QlUyVWdMa3lyV1NT?=
 =?utf-8?B?OVl0TUdPbnplbTBqTW9WTzg3L1FiYjFHVFZqY3hBNkxKWWxwTHFIWlNVdWp1?=
 =?utf-8?B?Z2lnN0NhTXkxcHdDUlhtWlBPS0F6dnhGak84enBFTXlNZXZYNXRka3l2NXZN?=
 =?utf-8?B?aVFkd2VrUXVnSldKbzNCZE94amNyOGdKME1UUFMwTTZySHMyM3l0S2Q4WHMr?=
 =?utf-8?B?dFpaN3VFUlRvUGZQTlU1cm53cnVkeVIya2dHS0k4MVJGb3B0TjBmdkIxRkJD?=
 =?utf-8?B?bWRxekR6blZDUUpyVHB3a2RxaVM5ak8wWkhJLzFaY0VOVEV0bWVvR2pWYWR6?=
 =?utf-8?B?akZMSTdtOG5Hd2lTU05Najg1L0VzRWlxdjNkUklsK29md21IYy9iRGpaZy9E?=
 =?utf-8?B?THNVZXBtVXl3WnYxSG9oenFyWDRoTThNSnJkeVZiSnFxdm5pY2ZFMGs1N2M4?=
 =?utf-8?B?ekFKTys2ZDBCbmhSbkx1Ym93S1BhaHNuVG1HV0ZYUWZhWkEyTE5MMWorNlJJ?=
 =?utf-8?B?c2VkcVlWdnpEcDZXckVrK1dNeVM0VmdXdHpyc3ZIdk90MWduTDZUWTdCREFp?=
 =?utf-8?B?NHVEcVZsNkt3NXQwSEhTSytMcEhWRVorNFpETUJRMGh2Qmtqd2FzTjdtSEkz?=
 =?utf-8?B?REJjVWFjanFGT0hsb0VVRWlRRThCWUl6dVVIZGFPSXlmYjhxYWRRNUZHZDBT?=
 =?utf-8?B?SjZOT1d6dURJUkFJNUhPVHNPWlN1dEsxREZ1UVZxeGJ4WVFvSExTZ1VjMGVa?=
 =?utf-8?B?ancwM1J4SmpING5WbHZ4SnAxOWNrYklmanR0eXNDU0dXUzBRRzVyOVNwVmZw?=
 =?utf-8?B?c2lzaTBHTFNwUGRlSlg3eWU5cGdOVnhLRWRFTjdNcW9zNFNvSlNXRWNTaVVY?=
 =?utf-8?B?cjU4T3ZYWE41UDdDZ2RRNnlTS2hMaEc5aFNTaURKb0pacjhDbFdadkJaKzNp?=
 =?utf-8?Q?/pWpvM?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(7416014)(376014)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2025 16:47:15.6546
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 533fc907-07ba-4cd1-e831-08ddf152dd2f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF00021F6F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4203

On Thu Sep 11, 2025 at 10:24 AM CEST, Gerald Elder-Vass wrote:
> Commit cb41b4ce14a9 introduced init_secure_boot_mode but one line was
> not wrapped appropriately.
>
> Signed-off-by: Gerald Elder-Vass 
> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monn=C3=A9" 
> CC: Stefano Stabellini 
> ---
>  xen/common/efi/boot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index b86c83d3348c..69fc022c18ab 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -923,7 +923,8 @@ static void __init init_secure_boot_mode(void)
> =20
>      if ( status =3D=3D EFI_NOT_FOUND ||
>           (status =3D=3D EFI_SUCCESS &&
> -          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RU=
NTIME_ACCESS) &&
> +          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +                   EFI_VARIABLE_RUNTIME_ACCESS) &&
>            size =3D=3D 1 && data =3D=3D 0) )
>          /* Platform does not support Secure Boot or it's disabled. */
>          efi_secure_boot =3D false;

You're not wrong, but it feels a bit excessive having a patch just for this=
.

Oh, well.

  Reviewed-by: Alejandro Vallejo 

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 17:20:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 17:20:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120693.1465500 (Exim 4.92)
	(envelope-from )
	id 1uwkyV-00040e-Jf; Thu, 11 Sep 2025 17:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120693.1465500; Thu, 11 Sep 2025 17: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 1uwkyV-00040T-FD; Thu, 11 Sep 2025 17:20:47 +0000
Received: by outflank-mailman (input) for mailman id 1120693;
 Thu, 11 Sep 2025 17:20: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 1uwkyU-00040I-Ao
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 17:20:46 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20623.outbound.protection.outlook.com
 [2a01:111:f403:2415::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a584a0a7-8f33-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 19:20:44 +0200 (CEST)
Received: from MW4PR04CA0135.namprd04.prod.outlook.com (2603:10b6:303:84::20)
 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.9094.22; Thu, 11 Sep
 2025 17:20:39 +0000
Received: from CO1PEPF000042AD.namprd03.prod.outlook.com
 (2603:10b6:303:84:cafe::4) by MW4PR04CA0135.outlook.office365.com
 (2603:10b6:303:84::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Thu,
 11 Sep 2025 17:20:39 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CO1PEPF000042AD.mail.protection.outlook.com (10.167.243.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 17:20:38 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 11 Sep
 2025 10:20:35 -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: a584a0a7-8f33-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pgjlpbR0y9F406TNN3Xslshdwpeso0jAIfY08Pj8F+1NYs6179iLFdUoI6FhfE4CHszaW5WRxWH79WhY/ZuOe33utbVdXBguiY2KX+AhivOi1VZvbQsNsG2Dk6CBesiH+m71j6H3YwIuucqMQbrRniNFFl3025TDjv81x87uxjn/95453vXFBUymCdcVG3Ew62XHdMEIbYoaurwSTaTjnq23WCQxWJQZxO5LmtqgRmn8z1DHL42s1+sXms1QwDeeg7bt4LNrY3g5WxeBxEGqbRisNL6oBGZl/0ZhPySHO3Q3tyR0dI/4FCXYRryAPkjeuaMxvBxFi6N5+9foYNviCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KtD0HXiA6kfML2R5w42sJk/0LJZtoVkpc5kiCLJuFaI=;
 b=lHManHIRfza+6Dda0wOx62y6liPuxYLFDEvZcDsnq4ffZX0u8eurPQZmEQ9RRNriSGfbm5LZ9bkVydTVKXsZSdHDnkS0jZtEik+l4FTCRU4EPqseITHtVzYydgpT0K63DX7J0OkRVjv9ecQi0UZGFp3e5w0TYO7/akFdPfDH+H/iZ1r5LqHHZoWe8v+oKZXiVRY9VIT6OZiE/tQVDNVyfk87mqmzdymaH9RF297LtEAGcn4ZnfluOduUE/gGN+NPOC3HUO/9f7+hKdb2KyAc0a1jWJh3V5SyNTHNp9dJvb/X/nwHgHRkROdUK9qqBC61i0C19YukuDz51y80ojF0ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=cloud.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=KtD0HXiA6kfML2R5w42sJk/0LJZtoVkpc5kiCLJuFaI=;
 b=ihnlEoCvaMdaTLVSOWH/HEvwZSAZAr3wyhTI5ay6g0/cjYI6wTjb2Giq6YH5kOpeUogq2bwRhFIPs9HLtIiywqFHgYb0o0YlNqKfHdkYhe5yQUIkVLE7KmBf0vhBEIfewXT7zYp2S1WrFNyKXM/Te3lDL5j1vHY8aymM0y85p9o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 11 Sep 2025 19:20:33 +0200
Message-ID: 
To: Gerald Elder-Vass , Xen-devel
	
CC: =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=
	, "Daniel P. Smith"
	, Jan Beulich , "Andrew
 Cooper" , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH 2/3] efi: Protect against unnecessary image unloading
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: 
 <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@cloud.com>
In-Reply-To: <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@cloud.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AD:EE_|PH8PR12MB7277:EE_
X-MS-Office365-Filtering-Correlation-Id: 26778f01-fc76-4b88-6b37-08ddf15786f8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|7416014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?L2QzckJ6OU04N3J3M1FyTFJpblRoQzJJWmU3RjcyWlIvdFBoVDFvTExoZncr?=
 =?utf-8?B?RUpMY3dVODVzR0FwLzZWVXkrK2RldHI0SnVHejJqRnA4SGVqWWVnY2FsN3E5?=
 =?utf-8?B?Yi9uNTFRS3NITTZweXNsTVpyNFhpdDRwNkFOdnArZkNlVVZKZW12aFBYY2NK?=
 =?utf-8?B?VWk3OFEzdVZ6Z0kwVjdJaWsvclRPRUxjdkJYTWhlbEdOM2lIK2RxUE1zYVp1?=
 =?utf-8?B?WXcvQUdnL0MvTE4vQ1VGVWdKZUx2OGdPblpBMGZMVmF1QkRJZjRtQ09VeDBM?=
 =?utf-8?B?eThQMDJvMjdhbGI5QW9hTkF5USt2c0xDWVVEYVg5UmtiTkZHL3hwWFdnZmVD?=
 =?utf-8?B?MFYrNm1nSmdPcVNGMlpYV1dkYSszL2pHYjBVQ0N3cU9SMU9MN2hMcW1kSGVu?=
 =?utf-8?B?elhicHl2VXZoc1Rkb0Z2MWloNURlb09STTRHQ1Uwb2x3K0o0MG5pR3NhWEo4?=
 =?utf-8?B?LzhjVlUzRDJuQTlhbXZ1Ymc1R2E0ak12dTJRQTdSdGNvUU52OWpnYkFuTWVT?=
 =?utf-8?B?dVU5b0kycHhJa1M5VlpOcysxbm5qdkkrckp3Y05hRWs1bkZzN05nSkxMWko0?=
 =?utf-8?B?U1AySERZQVA0bUp6MGFFTk1mVzVhV0RBeXFaOGpENmZ5SHloU0VTLzlPYlZ3?=
 =?utf-8?B?Q0J1amYwZ1JKSlZjRlNFK0twL3VjSSszaWZKSVJxbkpib0xPNS9QVCsrbVVp?=
 =?utf-8?B?TmFUNXA0VWwxdUQzNTNZdnpMMlNrMlFxdHBPdnhNcDF2aDJvdEJuZ296aDJv?=
 =?utf-8?B?Um1HMHhzT3cyZEtCNjJBSXI3MDJUVHN4cWErbzA4UGgvN0xtZXRRQ3NpcGdr?=
 =?utf-8?B?ZS9PUDR3bnE5YmNIazJXQmxUVU5YS3NsdTdhZDJicW4xL0ZJenVTVmpVckxz?=
 =?utf-8?B?V3h4Q1dPbHBlajdUYjFhY29jQVJlaDAweTZwUEQwOWxKc3F2dnpieHBGM01x?=
 =?utf-8?B?OG9CVEhaRmlNUlF2M3ZPV1kwWGQwQm9BTjUzRjluZnFtaGpGQ2V0eWphYm9N?=
 =?utf-8?B?dXpMM3hULytmeEFDLzQrR2d6ZzRxWWEyTFBVZHRVVWpkYXNLQVVtS2tvRTRo?=
 =?utf-8?B?RWNJeVBRdzhyd3BPUWJSbnhZaks2TW5BUmJxdC9vNEtXNmhxT2lCTmdLT3Fq?=
 =?utf-8?B?Q3lhTHVFaDZ6UlEwWFpPaEdaTGs4L0c2WWdSTG1seW9vZW9wamJMdUtqV3Iy?=
 =?utf-8?B?aUdUeEhGS2FDTktaS09zOHJoUzVCNFRBeFpCZDRjYzl1MGt4RzdiMlBGMEZz?=
 =?utf-8?B?cFlDbUVXUVV2ekREQ1c2SkpjK3lrc2NKMHU1U0doc2gydkI5bTA2MkRhOEZL?=
 =?utf-8?B?d24wL21XSEFpRlYyM1JwajFSUjJxaFdFaXZxNyttTmpROTM5RnVYZDJ0d0Rh?=
 =?utf-8?B?MG1BcXhrcnhnV0pucEd1OWUvTGFjaTdwSjFsYXBhV1pOZlhIQ1JQQ3ZEaVBo?=
 =?utf-8?B?T0h5RTUra3ZXTitWbW9rUUtodlltLzdjSUNDL2lOTTBUQndGUGFSemd0cFl0?=
 =?utf-8?B?N1ZDT2FITStwV050N2o3RHhsNFh2dVF6QWVBeVZmMjJVVWYvaEkreTRJVi95?=
 =?utf-8?B?OHV0TU00Znh6R3BxZFR5ZlV4d216bUVWbGEyVXRuT0Z5WHIxZnpCTnpZM1Ay?=
 =?utf-8?B?ck12Nlk0MmIwYXJybXdMMjRrcGc1OTM5c21hNFBnK0VZUVJlZVc4cStEelU1?=
 =?utf-8?B?cHlnSkJsNG9CaGlOaTBLYlJPNElpbUorUUZxb0pTL3h6Tk11VUJLUllPdTBE?=
 =?utf-8?B?d3NFbk9zMnNXMFhlT3F5dWRwUG5OeTBwbWtiUkR2RWJTWFQxdnptanJxVERi?=
 =?utf-8?B?VHFqMFBQSDNPSk1zZHo5NkRoM2QwUjEvRlVNblBQK0wvcGRsdDY1dlowc2lM?=
 =?utf-8?B?bmlRUGtXMWozbzVsdDBMV1FrV2FJT3dHWmYvbzVhM0NUZGVXa0kvNEZ2WmFo?=
 =?utf-8?B?Q1NLV3lUbkJTNG9JTmpadWN0UzE3MzIrUEdWQXQ3T1hjak1DeEtjZ1pMTW0v?=
 =?utf-8?B?YkNXZ0pGT2dBPT0=?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2025 17:20:38.4026
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 26778f01-fc76-4b88-6b37-08ddf15786f8
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AD.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7277

On Thu Sep 11, 2025 at 10:24 AM CEST, Gerald Elder-Vass wrote:
> Commit 59a1d6d3ea1e introduced Shim's LoadImage protocol and unloads the
> image after loading it (for verification purposes) regardless of the
> returned status. The protocol API implies this is the correct behaviour
> but we should add a check to protect against the unlikely case this
> frees any memory in use.

Any what memory in use? The function loads an image, it's not a consumer.

It can't free anything because it doesn't know where it came from. It might=
've
been embedded in your own binary, and it can't compromise its integrity lik=
e
that.

>
> Signed-off-by: Gerald Elder-Vass 
> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monn=C3=A9" 
> CC: Stefano Stabellini 
> ---
>  xen/common/efi/boot.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index 69fc022c18ab..ca162db0d8d3 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1062,7 +1062,7 @@ static void __init efi_verify_kernel(EFI_HANDLE Ima=
geHandle)
>      static EFI_GUID __initdata shim_image_guid =3D SHIM_IMAGE_LOADER_GUI=
D;
>      static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_GUI=
D;
>      SHIM_IMAGE_LOADER *shim_loader;
> -    EFI_HANDLE loaded_kernel;
> +    EFI_HANDLE loaded_kernel =3D NULL;

This isn't required if unloading checks for the success case or the only er=
ror case
that has a successful load. See below.

Furthermore, you don't really know if the callee clobbered it.

>      EFI_SHIM_LOCK_PROTOCOL *shim_lock;
>      EFI_STATUS status;
>      bool verified =3D false;
> @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE I=
mageHandle)
>              verified =3D true;
> =20
>          /*
> -         * Always unload the image.  We only needed LoadImage() to perfo=
rm
> -         * verification anyway, and in the case of a failure there may s=
till
> -         * be cleanup needing to be performed.
> +         * If the kernel was loaded, unload it. We only needed LoadImage=
() to
> +         * perform verification anyway, and in the case of a failure the=
re may
> +         * still be cleanup needing to be performed.
>           */
> -        shim_loader->UnloadImage(loaded_kernel);
> +        if ( loaded_kernel )

Not sure this is what you want. The image needs unloading only when there's=
 no
error OR the error is EFI_SECURITY_VIOLATION. See section 7.4.1:

https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html#efi-boot-se=
rvices-loadimage

... and shim being a drop-in replacement, it's meant to be spec-compliant.

Trying to unload based on the assumption that loaded_image will remain undi=
sturbed is
an assumption waiting to be broken.

IMO, this wants to be instead:

  if ( !EFI_ERROR(status) || (status =3D=3D EFI_SECURITY_VIOLATION) )
      // unload

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 17:38:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 17:38:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120713.1465510 (Exim 4.92)
	(envelope-from )
	id 1uwlFm-00060M-2k; Thu, 11 Sep 2025 17:38:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120713.1465510; Thu, 11 Sep 2025 17: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 1uwlFm-00060F-06; Thu, 11 Sep 2025 17:38:38 +0000
Received: by outflank-mailman (input) for mailman id 1120713;
 Thu, 11 Sep 2025 17:38: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 1uwlFk-000609-GW
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 17:38:36 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 248c03a2-8f36-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 19:38:35 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b043a33b060so150832266b.1
 for ; Thu, 11 Sep 2025 10:38:35 -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-b07b31291bbsm176732466b.42.2025.09.11.10.38.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 10: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: 248c03a2-8f36-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757612314; x=1758217114; darn=lists.xenproject.org;
        h=cc:subject:from:to:content-language:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Fg6U/zUUNT5guRlToLkcmCkMbxQgwYvKIezKtcB8DA0=;
        b=GdE/RpjKmMyYj5Exy3SIcEXh4jy6D+f+hOaQIeEuuicVC5rts8CI12RwszzJpXxdc9
         xx9MqrDNPwg65FI1V4aNUp++M/9ZUgpuDBEuxImnCZbE/sYXOClrPP0vUKP6sSbaIzMC
         3Mud1M0GdF8pRp+577WNnPzt7AHv3U+MFUHsV1H74NrAovhM7XSx3SzgFBTwK8Jnxbc7
         L8mpzvShiGtXYNjr3R8miVpO+2RVEm4FzAuomIuSu8typGBuS/oHDwmbZRhT1ijXa/W/
         3JBsOtBb3nrISrzpD59DOooF4rOQzTkMkzu81JxOBByM84YBToi4+TlxvchAv2oiDXcu
         sDjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757612314; x=1758217114;
        h=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=Fg6U/zUUNT5guRlToLkcmCkMbxQgwYvKIezKtcB8DA0=;
        b=U542oytS67CN6+gzS6gJ8rFrBpwzFO55WSSt2VURvVOKFkJHByLpxISb2pkHKgOkOB
         ujx7RIfKINfR0OL2GGruwxMC4+yqP/kY/QKSWh0kf6Nni2zSvGY8aqmRV2nIBdevkRW9
         aU1dlqneccmIpe+RbGe6HZhLec6WqWwG8a7yhQhiiNugSJCC0ptWBuEi3DLqIgngh/7S
         oNEsYbB9GTjOWzUdbAp6KsBLXz5mzYIc8xvHefuUydWa02J1jzkolmMNkZ1Fw/+UTv9P
         LsI1wizIQILZyv0NWoo8wz+EKtSIuQeahSn8Kyv+w7kgvzmUFDTKwpK/XHt2fcDgGSyt
         S47Q==
X-Gm-Message-State: AOJu0YxYXo8SZjBtP8TfHUY/AyzwyioxSKGmg0ekyjrx+KizZssfJzMi
	XgK7Wp5bvyzaBte1Qdhx44Y70k+rA1TgiKDcrf90zuwJ8MmM8jJ5sWcZHMZ5zw==
X-Gm-Gg: ASbGncvHKSJefM4UVkv8n4QpohNNVhHF9uRXJm1OKMC56EQ1nCveQ2MB2ToK5whAlXD
	3xrzyWcq7PqEIUauyT6w+oWL/9TtzxgQDJA6jDNOML+pU2wR+GtjQp+4ZOjXUsSI8aqCFGVAeB5
	qumqEpCuQX1fP0Ae8JGxKVgdFZr8fT5ov3cSEd6klCx8l45D5rvJSRY+AkshGlDdwrkHFsvpGPQ
	WXX/Vb6hyX8z0Lph+xeQ22Eu7dv+2r3dq0BzqQ904fcElGrMw2kxJtljHUzZdFDGq+rOXIWXskw
	QmZbJDqMLzIstKsqLknsE14PqVzYXr1f5Q6W6P9j800Qul/eTV6eoy5LsxhR/L2dlOnrE0hz6/W
	K69in5UnIBNFTB+M2BOqW7qK1m2y5Svns0fcn91eQIUjUa4seGYKZCbL6tULeiziXhxZLBY4AEE
	CDmbkq2PA=
X-Google-Smtp-Source: AGHT+IFyCnlj1AKoIK+JOCfX7ooQVOLLkUhOpB1E69W0nkfe2fk9WJSnW0WLpZTkfice2u9e2Bas8Q==
X-Received: by 2002:a17:906:9c84:b0:ae9:c494:1ade with SMTP id a640c23a62f3a-b04b173b495mr1765918766b.53.1757612314245;
        Thu, 11 Sep 2025 10:38:34 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------ziRazTzCRRdtO7kmyc9E8GfB"
Message-ID: <1248fd0c-08c7-42b1-ba10-755ae8696528@gmail.com>
Date: Thu, 11 Sep 2025 19:38:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel 
From: Oleksii Kurochko 
Subject: Code freeze is Fri Oct 03, 2025
Cc: Community Manager ,
 "committers@xenproject.org" 

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

Hello everyone,

I would like to inform you that the release schedule has been updated due to
an extension of the Feature Freeze.

The Code Freeze is now scheduled for*Friday, October 3, 2025*.

You can find the updated schedule here:
  https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes

Have a good evening.

Best regards,
  Oleksii

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



  

    
  
  
    
Hello everyone,

I would like to inform you that the release schedule has been updated due to
an extension of the Feature Freeze.

The Code Freeze is now scheduled for Friday, October 3, 2025.

You can find the updated schedule here:
 https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes

Have a good evening.

Best regards,
 Oleksii


  


--------------ziRazTzCRRdtO7kmyc9E8GfB--


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 18:14:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 18:14:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120756.1465519 (Exim 4.92)
	(envelope-from )
	id 1uwloH-0002rC-Iu; Thu, 11 Sep 2025 18:14:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120756.1465519; Thu, 11 Sep 2025 18:14: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 1uwloH-0002r5-Fq; Thu, 11 Sep 2025 18:14:17 +0000
Received: by outflank-mailman (input) for mailman id 1120756;
 Thu, 11 Sep 2025 18:14: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 1uwloG-0002qz-Gm
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 18:14:16 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e524b48-8f3b-11f0-9d13-b5c5bf9af7f9;
 Thu, 11 Sep 2025 20:14:13 +0200 (CEST)
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
 [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-28-iWP038R7PQW8pLTkgu4n0w-1; Thu, 11 Sep 2025 14:14:10 -0400
Received: by mail-wm1-f72.google.com with SMTP id
 5b1f17b1804b1-45b920e0c25so6846275e9.3
 for ; Thu, 11 Sep 2025 11:14:10 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f42:b000:db8b:7655:f60f:812b?
 (p200300d82f42b000db8b7655f60f812b.dip0.t-ipconnect.de.
 [2003:d8:2f42:b000:db8b:7655:f60f:812b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e016b5cbcsm35354055e9.11.2025.09.11.11.14.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 11:14: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: 1e524b48-8f3b-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757614452;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=fO/wiS6u6wjvvJi4t2wKktGS6aYq1CiRm5gJANXSAXc=;
	b=ROmY7FUr4RFL/ZaJdrsNgxHvb34/pAbXIlb5WxbBwVKDvroNMtrDVkA7rzCQcYhEqSXRQA
	0VFaqRk3jkv/sWR13uf/Zx5Uy6ZZXnT/pLJX/OgNKiWbPBcIoPslsk8bRSG1mp0j3ZqF+8
	6b5EBJooQIW0NgT5Tk70lsJr6Axak8M=
X-MC-Unique: iWP038R7PQW8pLTkgu4n0w-1
X-Mimecast-MFC-AGG-ID: iWP038R7PQW8pLTkgu4n0w_1757614449
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757614449; x=1758219249;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fO/wiS6u6wjvvJi4t2wKktGS6aYq1CiRm5gJANXSAXc=;
        b=wmeCgXvgBzUQZoAXyQHdoZKkRWGJ1Eyeu9stK5iMDLszsCdqY4fMOWHORmrySEPuj/
         XHjG8RqSytniuVTOoDFd5KjOi27Strwwy8Xv0G2arhLiRmr0svIa2X9dtM/JfWHANZB8
         QqIS/CtgGwGjS79bANBFSsDSsCCvDJWMtLOkCJWEVSn66bmQgQvMz6iKpOcqq3+05P+R
         5AkKr9vNyUe3F1u6zpSWV4IqkNSaCiI63OcDnae4WS31krEhAmKvnZRezlTRPnXm3Ko0
         XV/zcSgGnUVZj47bVetj+It5bZ0NWNNKoZk6UAdz/gpFuy2WhIvMpKJVLl9C8K3d22d6
         pZNg==
X-Forwarded-Encrypted: i=1; AJvYcCUtngg4rzCYGwZyWmpwdu4WtHXFN9U95OHLaiXyyVNx2N8/v5f5EjIBP1J1gz0w2JWBX6xFe4Aecf0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzI26KUC/v516lmO2OS+8VpSRnwZxW8QVNeUELhBb95MElOBpo7
	jD3/cBD5TGaIfij5ViGwbZEDW6b2MCiy4jbQrWI3zFBAMw/60CLYZRqsiY7tIV5i2NTv3AUxGvX
	5kIAdoGwzbFBvJj+GXfiWXa77iQSNXIUwt+Jd2OcR78J1ezrjm/wVUQ/rnWCHLoExrTAi
X-Gm-Gg: ASbGncvSPmIz94wFUCdX3ILAaEfevF3eqe7EQZ/IGDOhgxOvN2zd+QPc0POoB46U07i
	DlNNzBgkfsr8rYhRceqEpUYRQwZwtAUdBR/cUhpsxnaHXhlVg2NwBnT92jJsvxJSzLMS53ZOnDL
	WCymkvrEbRa3I/mY9tpWA2Fygrcuo7toLZaiAdTxIVBvDcJujfHV1kEdP0GBLVD/B0gi1KmZRw4
	8Dg8nzglvhL1Ns+hkStJoXPd12oPFSgLCMUatYmQoh4GmrJ4en9xTTjiyZUdjPrBcxHBbWulCKo
	q9gSl7ePdsm3AWBU5E4fp9Ao8Ln1VD2d/fjVGLjPsR8ghIObHYt5RX9e9qsseQgEKHzrxzk9pNK
	/5ZLarQgyIoOrnvZDB3wNExkbFo9NMO6ps4uOyGongvyUznzl23e3Aw68XTicmuJt5Hg=
X-Received: by 2002:a05:600c:1387:b0:45b:88d6:8ddb with SMTP id 5b1f17b1804b1-45f211fc2dbmr3761195e9.37.1757614449372;
        Thu, 11 Sep 2025 11:14:09 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHYPRnitXgQzHDt7U0vwEWEhdUB9NK1hJir7NlpKTdRzaPw5ybQNZDXnkL32l5S2EQ4JRmc7Q==
X-Received: by 2002:a05:600c:1387:b0:45b:88d6:8ddb with SMTP id 5b1f17b1804b1-45f211fc2dbmr3760825e9.37.1757614448886;
        Thu, 11 Sep 2025 11:14:08 -0700 (PDT)
Message-ID: <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
Date: Thu, 11 Sep 2025 20:14:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 1KZCWXOQ0X7A5P57rNc__r7qj-5ZJrO6gJPkE7WvXqs_1757614449
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

>>> On the other hand, with a pagefault_disabled-like approach, there is no
>>> way to instruct call {3} to fully exit lazy_mmu regardless of the
>>> nesting level.
>>
>> Sure there is, with a better API. See below. :)
> 
> I meant while keeping the existing shape of the API but yes fair enough!

Time to do it properly I guess :)

[...]

>> Assume we store in the task_struct
>>
>> uint8_t lazy_mmu_enabled_count;
>> bool lazy_mmu_paused;
> 
> I didn't think of that approach! I can't immediately see any problem
> with it, assuming we're fine with storing arch-specific context in
> thread_struct (which seems to be the case as things stand).

Right, just to complete the picture:

a) We will have some CONFIG_ARCH_LAZY_MMU

b) Without that config, all lazy_mmu_*() functions are a nop and no 
lazy_mmu_state is stored in task_struct

struct lazy_mmu_state {
	uint8_t enabled_count;
	bool paused;
}

c) With that config, common-code lazy_mmu_*() functions implement the 
updating of the lazy_mmu_state in task_struct and call into arch code
on the transition from 0->1, 1->0 etc.

Maybe that can be done through exiting 
arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode() callbacks, maybe 
we need more. I feel like
we might be able to implement that through the existing helpers.

> 
>>
>> We can do things like
>>
>> a) Sanity check that while we are paused that we get no more
>> enable/disable requests
>> b) Sanity check that while we are paused that we get no more pause
>> requests.
> 
> These are good points - and this is only possible with such global
> state. (Similarly we can check that the counter never underflows.)

Exactly.

[..]

> 
> Overall what you're proposing seems sensible to me, the additional
> fields in task_struct don't take much space and we can keep the API
> unchanged in most cases. It is also good to have the option to check
> that the API is used correctly. I'll reply to the cover letter to let
> anyone who didn't follow this thread chip in, before I go ahead and try
> out that new approach.

And on top of the proposal above we will have some

struct arch_lazy_mmu_state;

define by the architecture (could be an empty struct on most).

We can store that inside "struct lazy_mmu_state;" or if we ever have to, 
start returning only that from the enable/disable etc. functions.

For now, I'd say just store it in the task struct in the lazy_mmu_state. 
But we can always adjust later if required.

In the first (this) series we probably don't even have to introduce 
arch_lazy_mmu_state.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 20:19:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 20:19:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120842.1465529 (Exim 4.92)
	(envelope-from )
	id 1uwnld-0000kB-2b; Thu, 11 Sep 2025 20:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120842.1465529; Thu, 11 Sep 2025 20:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwnlc-0000k4-Vo; Thu, 11 Sep 2025 20:19:40 +0000
Received: by outflank-mailman (input) for mailman id 1120842;
 Thu, 11 Sep 2025 20:18:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uwnkl-0000j2-TP; Thu, 11 Sep 2025 20:18:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwnkk-0051p6-2S;
 Thu, 11 Sep 2025 20:18:46 +0000
Received: from host-195-149-20-212.as13285.net ([195.149.20.212]
 helo=[192.168.1.183])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uwnkk-004kUE-2p;
 Thu, 11 Sep 2025 20: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=BybyxlsIV5NU/aaN9hg4Y0yoTFvcU+i2l/qm/JtmDIo=; b=Gax9dLpuU0+dWAwU7RwgqsfmfX
	TQz8AQjZT7ub4pFBjgpvrCzN3vXtxTlG9dJZsNnf2dB0JH+3ITHX9Lc3UA9yigUz2mUUQb+ljFPoe
	cYpMOtsEYU4KB4dhcYl+w1wd9JqWEbIMKQLqJVchQpuhJ3lEExm12nKemXKpDB8Uisa0=;
Message-ID: <2daad10e-e1ae-4e95-9b29-13c27425d8c3@xen.org>
Date: Thu, 11 Sep 2025 21:18:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: domU reboot claim failed
To: Alejandro Vallejo ,
 Jan Beulich , Jason Andryuk 
Cc: Xen-devel ,
 Xen-devel 
References: 
 
 
 
Content-Language: en-GB
From: Andrew Cooper 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[Resend from an account which will let me...]

On 11/09/2025 4:46 pm, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 9:55 AM CEST, Jan Beulich wrote:
>> On 10.09.2025 23:57, Andrew Cooper wrote:
>>> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>>>> Hi,
>>>>
>>>> We're running Android as a guest and it's running the Compatibility
>>>> Test Suite.  During the CTS, the Android domU is rebooted multiple times.
>>>>
>>>> In the middle of the CTS, we've seen reboot fail.  xl -vvv shows:
>>>> domainbuilder: detail: Could not allocate memory for HVM guest as we
>>>> cannot claim memory!
>>>> xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't
>>>> allocate low memory for domain: Out of memory
>>>> libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init
>>>> failed: Cannot allocate memory
>>>> domainbuilder: detail: xc_dom_release: called
>>>>
>>>> So the claim failed.  The system has enough memory since we're just
>>>> rebooting the same VM.  As a work around, I added sleep(1) + retry,
>>>> which works.
>>>>
>>>> The curious part is the memory allocation.  For d2 to d5, we have:
>>>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>>>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>> xc: detail:   4KB PAGES: 0x0000000000000000
>>>> xc: detail:   2MB PAGES: 0x00000000000006f8
>>>> xc: detail:   1GB PAGES: 0x0000000000000003
>>>>
>>>> But when we have to retry the claim for d6, there are no 1GB pages used:
>>>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>>>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>>>> domainbuilder: detail: HVM claim failed! attempt 0
>>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>>> xc: detail:   4KB PAGES: 0x0000000000002800
>>>> xc: detail:   2MB PAGES: 0x0000000000000ce4
>>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>>
>>>> But subsequent reboots for d7 and d8 go back to using 1GB pages.
>>>>
>>>> Does the change in memory allocation stick out to anyone?
>>>>
>>>> Unfortunately, I don't have insight into what the failing test is doing.
>>>>
>>>> Xen doesn't seem set up to track the claim across reboot.  Retrying
>>>> the claim works in our scenario since we have a controlled configuration.
>>> This looks to me like a known phenomenon.  Ages back, a change was made
>>> in how Xen scrubs memory, from being synchronous in domain_kill(), to
>>> being asynchronous in the idle loop.
>>>
>>> The consequence being that, on an idle system, you can shutdown and
>>> reboot the domain faster, but on a busy system you end up trying to
>>> allocate the new domain while memory from the old domain is still dirty.
>>>
>>> It is a classic example of a false optimisation, which looks great on an
>>> idle system only because the idle CPUs are swallowing the work.
>> I wouldn't call this a "false optimization",

Sorry - I was referring to things more generally.  There's a huge number
of things that look like great ideas when you develop and demo them on
an idle system, and then they fall off a cliff on a busy system.

This is one.  Releasing the domctl lock in domain_kill() was another
(this one did get reverted IIRC).  XenServer's attempt to compress the
migrate stream, etc.

Performance is hard, and definitely harder than functional fixes.  All
of these were reasonable hypotheses and a valid line of experimentation,
but were not tested outside of idle conditions.

All of these examples have behaviour on a busy system which is far worse
than not having the improvement in the first place.  Hence the "false"
part of the optimisation.

>>  but rather one ...
>>
>>> This impacts the ability to find a 1G aligned block of free memory to
>>> allocate a superpage with, and by the sounds of it, claims (which
>>> predate this behaviour change) aren't aware of the "to be scrubbed"
>>> queue and fail instead.
>> ... which isn't sufficiently integrated with the rest of the allocator.
>>
>> Jan
> That'd depend on the threat model.

I'm pretty sure Kconfig post-dates the change in question here.

> At the very least there ought to be a
> Kconfig knob to control it. You can't really tell a customer "your data is
> gone from our systems" unless it really is gone. I'm guessing part of the
> rationale was speeding up the obnoxiously slow destroydomain, since it hogs
> a dom0 vCPU until it's done and it can take many minutes in large domains.

It was Oracle being unhappy at domain shutdown on a 2T VM taking 20 minutes.

> IOW: It's a nice optimisation, but there's multiple use cases for specifically
> not wanting something like that.

My recommendation at some point under the fact was a parameter to
domain_kill().  In a mixed system, you might care about it for some
domains and not others.

Although it occurs to me now that really it needs to be an input to
domain_create(), because if you care about it on a VM, you care about
anything that gets freed, not just the things freed right at the end of
the domain's lifetime.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 21:20:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 21:20:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120882.1465540 (Exim 4.92)
	(envelope-from )
	id 1uwoiK-0000YJ-BQ; Thu, 11 Sep 2025 21:20:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120882.1465540; Thu, 11 Sep 2025 21:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwoiK-0000YC-7k; Thu, 11 Sep 2025 21:20:20 +0000
Received: by outflank-mailman (input) for mailman id 1120882;
 Thu, 11 Sep 2025 21:20: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 1uwoiJ-0000Y6-A4
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 21:20:19 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2418::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c2d7432-8f55-11f0-9809-7dc792cee155;
 Thu, 11 Sep 2025 23:20:15 +0200 (CEST)
Received: from SJ0PR03CA0288.namprd03.prod.outlook.com (2603:10b6:a03:39e::23)
 by CH1PR12MB9646.namprd12.prod.outlook.com (2603:10b6:610:2af::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Thu, 11 Sep
 2025 21:20:12 +0000
Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com
 (2603:10b6:a03:39e:cafe::94) by SJ0PR03CA0288.outlook.office365.com
 (2603:10b6:a03:39e::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.15 via Frontend Transport; Thu,
 11 Sep 2025 21:20:12 +0000
Received: from satlexmb08.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_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Thu, 11 Sep 2025 21:20:12 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Thu, 11 Sep
 2025 14:20:03 -0700
Received: from satlexmb08.amd.com (10.181.42.217) 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, 11 Sep
 2025 16:20:02 -0500
Received: from [172.17.248.197] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Thu, 11 Sep 2025 14:20:02 -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: 1c2d7432-8f55-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kjkl4ui0p2OD1cLImV0zwLq4GnTiMpHluAX0eBG88OeEb+72lNer1dRSML/8eC9peb4T7QXjVchXvMUPJ6vWkZVeS8L+YUfu+oz5Fflui7o+DwHWm1yoHN4DamMdh+5cGbb/zrQblIKCZqOYBIaQfFXG7TLnO2bDXs7qEfQFcDQm1XSlXJbUXPATzHTsN1zaQmvc5m/B4/DGvnDep8YRAFxsv5bhC4Q+hrH2TMnBEE+WhWo8iB3e1+S/sxJbZpzkyJWOBbcF6v+oMiYZuoG5TjYHwavuxfMNGqZycA8wXcS8AjXE3RFruwnNRjPK9s44aK2YcZ7wCCh/Hf6LA74gJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lYxhfaTKwgGAktgCxBHpAENAvJBMyx4rARatCt1E9C8=;
 b=LJEwSjpPqo3NaBvkkMry30D7nLpC/yJoV94oaZAQOAZ4RzXs5q+sQ1Kh0+CMI3pIAHz0fUklvDlhD/F5bw5EvBkC1duYrQGP7s2CxUlsp5picD+wooqS6QJjH+vqCPo1PuI13m7+lU5YK4Z7xwo3zPKUZOrWQaX1yvRRKJPD9fNjmTAJbhUJD31JihXfIVYr0XQ8vxYKBBMpb5HDtYv/e3w96rdeNwY5JjNDUgZQA7a47StSbtzXmEZ686XBAtAZRpWP1VXzku2fNoApevg58AkDn+3VjxNtJtUvqKzQrjYeobmiz0cnMN/6gFruLvhysbHh2QGRt36Trx2dzjvbeA==
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=lYxhfaTKwgGAktgCxBHpAENAvJBMyx4rARatCt1E9C8=;
 b=CwYFocD8NObFF7B9aT5DXpZPAfFGwSJye2dDjPY+7yAo1RSZyiP8h8/bQZD+aPL/i2o5MB0oCGs8kdZojtgNaf9Z+7yEXdZzxD1VCl1V+wv5C/mfYn0Ci7osj3BqGBM1G5EaeHl6k71XRCzDuVHBpYNQK0tM5SDhjt69ZsFExEA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <44207905-ece0-48f1-a7d7-8c30720cb48d@amd.com>
Date: Thu, 11 Sep 2025 17:20:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: domU reboot claim failed
To: Andrew Cooper , Xen-devel
	
References: 
 
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 (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CE:EE_|CH1PR12MB9646:EE_
X-MS-Office365-Filtering-Correlation-Id: 17c72dfb-a215-4283-598c-08ddf178fe8a
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?UENaaTlSLzMvc29HNmwxS09pdlRMNGNENFRmL2Y5VUY4R1o3N1g3aVhoQ2g5?=
 =?utf-8?B?UWdxMVQyRmJKVTFYOEptRHBlOVpucmN0NGsxcmxsZ1dDMFRWOXBRWjNNUGRL?=
 =?utf-8?B?QlBoQVZzOVBpWm1wbERpLzIwRWxNRS9MOEo0eUxSWTFsODZnK25qQTNDRUVC?=
 =?utf-8?B?U3ltWTU5TzRsV3BOaWxzNmVJdytzcE1DYjNUYWgzVVBseVUzOHpQdWFjME1s?=
 =?utf-8?B?YmFXSGRuZjZ4K0xXcG5zN25TeGszVitneHZxWTZXRW5aTmhHQ05RSk4yZ3dV?=
 =?utf-8?B?Rk5mWDl2YnA2MDhqM2VrSTU5YlhvazFoK25wWDRpeElqMldvYmdnSWtrR0VU?=
 =?utf-8?B?Q0dUM0RQVkZJV1NHS3pVaXAwRmV0aUthdG9FcUdWT28waFU1RldDb2VudUZw?=
 =?utf-8?B?bys0bEoxWE9zZFJqSEtLcy9LQ0xMLzRGOFd3TENsWngrOThmNnAzM1gwMUZn?=
 =?utf-8?B?TnZnelRLNnpOTTNseTVlL0VhZkZmUDB1SWNxN3NQUlBhT3lqR1p6eUVUY1Fu?=
 =?utf-8?B?TUFCWHVGQXM3czRVY0xtcWxkQ2FSY3ZjK3NBdjk0OGJaMFpGQUNsdFJrUVZU?=
 =?utf-8?B?MGE0bVkraS9FeVg4WnROeGJZWW9VYmU3ckZFU1ZFK3Bsd3RCbTk5b25DSDZR?=
 =?utf-8?B?dHJlcWtFNDViUlNaVzhZR1Y0a1NNcWhqQ1Z6NlRwUEJUVDNsY1JlcS8rQVJx?=
 =?utf-8?B?YkhMaGVhNlY3OVRMc2pFV2tPS29WRDdZN1JpSmJ5VmNqbHRHYWxhVDQ1cUtx?=
 =?utf-8?B?Ry9CcUJwbGxWMnZqSTExUWFHbUppL3dBdkNPWVRMdmZiY2hSMXZWSDJaMDM1?=
 =?utf-8?B?MzVvaTROUWlxZzE5a1dnNVlkQWdWOC96a2RYc1dZRml6MUZMZ01QbCtaSVIz?=
 =?utf-8?B?OE52Tm00WThpN1Vmb20yVmpEVUNidGIwTFlsWFNyd1VhT25DL2tjYy8rVmM0?=
 =?utf-8?B?TnFvZEExYUt0K0pkRDNTaWdkaDArSXQ4c0NwaWQxSWZFWmhxZDRwaGs1Rmsy?=
 =?utf-8?B?dHJjRVI4NEp2NFJGdnFMdVUzVkgrb3B3bXlJU2Fad0tBNThUV0ZQQ2VMM3lV?=
 =?utf-8?B?a0pudDY5R3BnbHJ1VjYrcldTRE5CWTA0Q3NlQWdZVkY2UytETUdVTXRnODZi?=
 =?utf-8?B?ciswT3BNNlIvZ0RBK3FoRUNTUVhZOWo1bXp2R2tyRG53R0Y0MHU1L2cwWGNZ?=
 =?utf-8?B?c3lXMnkxMDNxQ3dKcDlvckxiVjZtOURtRTZRT2F0RG1iTnNMaUpuY0ZUQ0hV?=
 =?utf-8?B?ZHppRXJZMHFSWjhpYjhUbC83M1FCb2lwcWVGRm41cjBRUG12bWdldVRsT3ly?=
 =?utf-8?B?b1p0Um9YclNzT2FnUGpxdHhOSVlXRExoVXUxazFpc0NKZzlKR3lCL1hrV2VC?=
 =?utf-8?B?emY5eStqdVFFeGJ5WndlVWdkb28wemJ6MEt3a0RzSzFQelAvSk1vOHZab3FN?=
 =?utf-8?B?WDFyV2ZQam8rRWcyTHpOWDJGbDNycmZ3a3gxWlFPTDlNeEZPUmdBeklDV2po?=
 =?utf-8?B?TlpidFJEeHFad0IxSm5Ta0ZrODJBREZRUmhFQUhqa0U1bFVkTnNsb2JIelJT?=
 =?utf-8?B?dGx0NHZ3UklWOGxoRHBnUGRRR3FjRVZIblUvb1FNZENPT3hvUE5rWXR6MDZh?=
 =?utf-8?B?YU1ITDZSSkYvWTR4YzVycHBzRndTOW5RUnVpbGJJRE1zMEUreGV5RHVZTkdl?=
 =?utf-8?B?KzlLeUgzd0JFeXJ0Ymp5MnlrRDRCRXJJUDZlWXpSVk1CTG9NUUpKQVdURVoy?=
 =?utf-8?B?THVGNFBsNWYxb09zRXF4SlJtUjhuanVXd1VJSGZQY3drblBvK1JTWXlaMXY1?=
 =?utf-8?B?SXI0b2ZDVzRTZjJoelIzc1hsK3QwQXExMjNjTHkzNWpsMUViWkNSa1R3dW5W?=
 =?utf-8?B?ZHRJSUNSUmFwdmlEYy9aN1k1KzIvdHdCTTRBeTR0bHc1QjRkRlZMU1VLbFlG?=
 =?utf-8?B?alVhejdpay9JaFRuamtpZzJzRFp3cTdkTTBmYkVpb25OK0ttSXgwc3hpejhR?=
 =?utf-8?B?TUplZ1dXcGc2QnFuanRSMmJZdHE0VHR6ZGwwc1BhZTc2cVU5SURkZ2FJSVJP?=
 =?utf-8?Q?81Qizl?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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 Sep 2025 21:20:12.3946
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 17c72dfb-a215-4283-598c-08ddf178fe8a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023CE.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9646

Thanks, everyone.

On 2025-09-10 17:57, Andrew Cooper wrote:
> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>> Hi,
>>
>> We're running Android as a guest and it's running the Compatibility
>> Test Suite.  During the CTS, the Android domU is rebooted multiple times.
>>
>> In the middle of the CTS, we've seen reboot fail.  xl -vvv shows:
>> domainbuilder: detail: Could not allocate memory for HVM guest as we
>> cannot claim memory!
>> xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't
>> allocate low memory for domain: Out of memory
>> libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init
>> failed: Cannot allocate memory
>> domainbuilder: detail: xc_dom_release: called
>>
>> So the claim failed.  The system has enough memory since we're just
>> rebooting the same VM.  As a work around, I added sleep(1) + retry,
>> which works.
>>
>> The curious part is the memory allocation.  For d2 to d5, we have:
>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>> xc: detail:   4KB PAGES: 0x0000000000000000
>> xc: detail:   2MB PAGES: 0x00000000000006f8
>> xc: detail:   1GB PAGES: 0x0000000000000003
>>
>> But when we have to retry the claim for d6, there are no 1GB pages used:
>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>> domainbuilder: detail: HVM claim failed! attempt 0
>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>> xc: detail:   4KB PAGES: 0x0000000000002800
>> xc: detail:   2MB PAGES: 0x0000000000000ce4
>> xc: detail:   1GB PAGES: 0x0000000000000000
>>
>> But subsequent reboots for d7 and d8 go back to using 1GB pages.
>>
>> Does the change in memory allocation stick out to anyone?
>>
>> Unfortunately, I don't have insight into what the failing test is doing.
>>
>> Xen doesn't seem set up to track the claim across reboot.  Retrying
>> the claim works in our scenario since we have a controlled configuration.
> 
> This looks to me like a known phenomenon.  Ages back, a change was made
> in how Xen scrubs memory, from being synchronous in domain_kill(), to
> being asynchronous in the idle loop.
> 
> The consequence being that, on an idle system, you can shutdown and
> reboot the domain faster, but on a busy system you end up trying to
> allocate the new domain while memory from the old domain is still dirty.
> 
> It is a classic example of a false optimisation, which looks great on an
> idle system only because the idle CPUs are swallowing the work.
> 
> This impacts the ability to find a 1G aligned block of free memory to
> allocate a superpage with, and by the sounds of it, claims (which
> predate this behaviour change) aren't aware of the "to be scrubbed"
> queue and fail instead.

Claims check total_avail_pages and outstanding_claims.  It looks like 
free_heap_pages() sets PGC_need_scrub and then increments 
total_avail_pages.  But then it's not getting through the accounting far 
enough to stake a claim?

Also free_heap_page() looks like it's trying to merge chunks - I thought 
that would handle larger allocations.  Are they not truly usable until 
they've been scrubbed, which leads to the lack of 1GB pages?

Clearly I need to learn more here.

> I thought OpenXT had a revert of this.  IIRC it was considered a
> material regression in being able to know when a domain has gone away.

OpenXT wants to scrub the memory ASAP so there is no remnant data.  They 
is a patch for that.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Sep 11 22:23:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 22:23:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120946.1465550 (Exim 4.92)
	(envelope-from )
	id 1uwphP-00086L-Uj; Thu, 11 Sep 2025 22:23:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120946.1465550; Thu, 11 Sep 2025 22:23: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 1uwphP-00086E-R9; Thu, 11 Sep 2025 22:23:27 +0000
Received: by outflank-mailman (input) for mailman id 1120946;
 Thu, 11 Sep 2025 22:23: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 1uwphN-00085p-FP
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 22:23:25 +0000
Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com
 [210.118.77.11]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed93ee2e-8f5d-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 00:23:24 +0200 (CEST)
Received: from eucas1p2.samsung.com (unknown [182.198.249.207])
 by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id
 20250911222322euoutp011634560d57af0d6769ea82508ee6c7b3~kWqER7Qs81513015130euoutp01K;
 Thu, 11 Sep 2025 22:23:22 +0000 (GMT)
Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by
 eucas1p1.samsung.com (KnoxPortal) with ESMTPA id
 20250911222321eucas1p114043a72e011e2fff92df33a2133b21e~kWqDhtt8p0600006000eucas1p18;
 Thu, 11 Sep 2025 22:23:21 +0000 (GMT)
Received: from [106.210.134.192] (unknown [106.210.134.192]) by
 eusmtip2.samsung.com (KnoxPortal) with ESMTPA id
 20250911222317eusmtip2aabd06b78078a7146730dff557f2cb71~kWqAG3AB-1019110191eusmtip2F;
 Thu, 11 Sep 2025 22:23:17 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed93ee2e-8f5d-11f0-9d13-b5c5bf9af7f9
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20250911222322euoutp011634560d57af0d6769ea82508ee6c7b3~kWqER7Qs81513015130euoutp01K
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;
	s=mail20170921; t=1757629402;
	bh=9atdt/om7OmffbDgov9WTxIsiO59X0BmEMtINP1uP9A=;
	h=Date:Subject:To:Cc:From:In-Reply-To:References:From;
	b=oYf4Wl/vK4mtCwLnlaPuk0Vbqm1kIIG4/GofumuhdavmIiBHyUZQRceOU6BgMduk5
	 UPpbMvZbaMJvAX41rCofkjz8fUum8Xd7cFaLczcWfrjE46zM7Gw77+bY+gxYbnaXwW
	 jL8zkycMTQXVpPJyDpmR0+MuvHwC/4FUakNYU3YU=
Message-ID: <5ffc63e9-19bd-4e12-92fc-57fe12d10f4f@samsung.com>
Date: Fri, 12 Sep 2025 00:23:17 +0200
MIME-Version: 1.0
User-Agent: Betterbird (Windows)
Subject: Re: [PATCH v6 03/16] dma-debug: refactor to use physical addresses
 for page mapping
To: Leon Romanovsky 
Cc: Jason Gunthorpe , Abdiel Janulgue
	, Alexander Potapenko , Alex
	Gaynor , Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich , David
	Hildenbrand , iommu@lists.linux.dev, Jason Wang
	, Jens Axboe , Joerg Roedel
	, Jonathan Corbet , Juergen Gross
	, kasan-dev@googlegroups.com, Keith Busch
	, linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan
	, Masami Hiramatsu , Michael
	Ellerman , "Michael S. Tsirkin" , Miguel
	Ojeda , Robin Murphy ,
	rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano
	Stabellini , Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Content-Language: en-US
From: Marek Szyprowski 
In-Reply-To: <20250910052618.GH341237@unreal>
Content-Transfer-Encoding: 7bit
X-CMS-MailID: 20250911222321eucas1p114043a72e011e2fff92df33a2133b21e
X-Msg-Generator: CA
Content-Type: text/plain; charset="utf-8"
X-RootMTR: 20250910052628eucas1p160daa0dadb6f81d7831d8047628aa9d4
X-EPHeader: CA
X-CMS-RootMailID: 20250910052628eucas1p160daa0dadb6f81d7831d8047628aa9d4
References: 
	<56d1a6769b68dfcbf8b26a75a7329aeb8e3c3b6a.1757423202.git.leonro@nvidia.com>
	<20250909193748.GG341237@unreal>
	
	<20250910052618.GH341237@unreal>

On 10.09.2025 07:26, Leon Romanovsky wrote:
> On Tue, Sep 09, 2025 at 10:37:48PM +0300, Leon Romanovsky wrote:
>> On Tue, Sep 09, 2025 at 04:27:31PM +0300, Leon Romanovsky wrote:
>>> From: Leon Romanovsky 
>> <...>
>>
>>>   include/linux/page-flags.h         |  1 +
>> <...>
>>
>>> --- a/include/linux/page-flags.h
>>> +++ b/include/linux/page-flags.h
>>> @@ -614,6 +614,7 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
>>>    * available at this point.
>>>    */
>>>   #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
>>> +#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
>> This was a not so great idea to add PhysHighMem() because of "else"
>> below which unfolds to maze of macros and automatically generated
>> functions with "static inline int Page##uname ..." signature.
>>
>>>   #define folio_test_highmem(__f)	is_highmem_idx(folio_zonenum(__f))
>>>   #else
>>>   PAGEFLAG_FALSE(HighMem, highmem)
> After sleeping over it, the following hunk will help:
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index dfbc4ba86bba2..2a1f346178024 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -614,11 +614,11 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
>    * available at this point.
>    */
>   #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))
> -#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
>   #define folio_test_highmem(__f)        is_highmem_idx(folio_zonenum(__f))
>   #else
>   PAGEFLAG_FALSE(HighMem, highmem)
>   #endif
> +#define PhysHighMem(__p) (PageHighMem(phys_to_page(__p)))
>
>   /* Does kmap_local_folio() only allow access to one page of the folio? */
>   #ifdef CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP

Okay, I will add this fixup while applying the patches.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 22:25:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 22:25:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120974.1465560 (Exim 4.92)
	(envelope-from )
	id 1uwpje-0000C6-9W; Thu, 11 Sep 2025 22:25:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120974.1465560; Thu, 11 Sep 2025 22:25: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 1uwpje-0000Bz-6q; Thu, 11 Sep 2025 22:25:46 +0000
Received: by outflank-mailman (input) for mailman id 1120974;
 Thu, 11 Sep 2025 22:25: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 1uwpjc-0000Bt-Vl
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 22:25:44 +0000
Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com
 [210.118.77.11]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 418b0afe-8f5e-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 00:25:43 +0200 (CEST)
Received: from eucas1p2.samsung.com (unknown [182.198.249.207])
 by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id
 20250911222543euoutp0181a9340dd64dc67c6339e0a47181ebf4~kWsHnYW5E2610126101euoutp01U;
 Thu, 11 Sep 2025 22:25:43 +0000 (GMT)
Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by
 eucas1p1.samsung.com (KnoxPortal) with ESMTPA id
 20250911222542eucas1p1fd99b15e46362a0af4417b04fa0c831b~kWsHKwmS41727217272eucas1p1e;
 Thu, 11 Sep 2025 22:25:42 +0000 (GMT)
Received: from [106.210.134.192] (unknown [106.210.134.192]) by
 eusmtip1.samsung.com (KnoxPortal) with ESMTPA id
 20250911222538eusmtip17e16b44d9939848958cad6696cc3414c~kWsDGpMzk2282122821eusmtip1T;
 Thu, 11 Sep 2025 22:25:38 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 418b0afe-8f5e-11f0-9d13-b5c5bf9af7f9
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20250911222543euoutp0181a9340dd64dc67c6339e0a47181ebf4~kWsHnYW5E2610126101euoutp01U
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;
	s=mail20170921; t=1757629543;
	bh=pKZpcAmq/bht8ZKkJqtZPTgOAGANcQvA5kKLVuXifcI=;
	h=Date:Subject:To:Cc:From:In-Reply-To:References:From;
	b=TYzap3cszLDOEgEsqU6EupJ7Zu8ir86kgd0ybK+4ACWZaOiATyvZFbUDShQ8MbR85
	 SejzQ/ANTvod+crbxkB+bIskmGYNCRGJfAnTK7Wx3EUgGfsfp9YrG/QNqAamMubhrs
	 7HS78hSROwDaJIS7uPVpylvDm+iDdZwL3r/+voe4=
Message-ID: <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
Date: Fri, 12 Sep 2025 00:25:38 +0200
MIME-Version: 1.0
User-Agent: Betterbird (Windows)
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
To: Leon Romanovsky 
Cc: Leon Romanovsky , Jason Gunthorpe ,
	Abdiel Janulgue , Alexander Potapenko
	, Alex Gaynor , Andrew Morton
	, Christoph Hellwig , Danilo
	Krummrich , David Hildenbrand ,
	iommu@lists.linux.dev, Jason Wang , Jens Axboe
	, Joerg Roedel , Jonathan Corbet
	, Juergen Gross ,
	kasan-dev@googlegroups.com, Keith Busch ,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org, Madhavan Srinivasan
	, Masami Hiramatsu , Michael
	Ellerman , "Michael S. Tsirkin" , Miguel
	Ojeda , Robin Murphy ,
	rust-for-linux@vger.kernel.org, Sagi Grimberg , Stefano
	Stabellini , Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Content-Language: en-US
From: Marek Szyprowski 
In-Reply-To: 
Content-Transfer-Encoding: 7bit
X-CMS-MailID: 20250911222542eucas1p1fd99b15e46362a0af4417b04fa0c831b
X-Msg-Generator: CA
Content-Type: text/plain; charset="utf-8"
X-RootMTR: 20250909132821eucas1p1051ce9e0270ddbf520e105c913fa8db6
X-EPHeader: CA
X-CMS-RootMailID: 20250909132821eucas1p1051ce9e0270ddbf520e105c913fa8db6
References: 
	

On 09.09.2025 15:27, Leon Romanovsky wrote:
> From: Leon Romanovsky 
>
> Changelog:
> v6:
>   * Based on "dma-debug: don't enforce dma mapping check on noncoherent
>     allocations" patch.
>   * Removed some unused variables from kmsan conversion.
>   * Fixed missed ! in dma check.
> v5: https://lore.kernel.org/all/cover.1756822782.git.leon@kernel.org
>   * Added Jason's and Keith's Reviewed-by tags
>   * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys
>   * Jason's cleanup suggestions
> v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/
>   * Fixed kbuild error with mismatch in kmsan function declaration due to
>     rebase error.
> v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org
>   * Fixed typo in "cacheable" word
>   * Simplified kmsan patch a lot to be simple argument refactoring
> v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org
>   * Used commit messages and cover letter from Jason
>   * Moved setting IOMMU_MMIO flag to dma_info_to_prot function
>   * Micro-optimized the code
>   * Rebased code on v6.17-rc1
> v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org
>   * Added new DMA_ATTR_MMIO attribute to indicate
>     PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
>   * Rewrote dma_map_* functions to use thus new attribute
> v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/
> ------------------------------------------------------------------------
>
> This series refactors the DMA mapping to use physical addresses
> as the primary interface instead of page+offset parameters. This
> change aligns the DMA API with the underlying hardware reality where
> DMA operations work with physical addresses, not page structures.
>
> The series maintains export symbol backward compatibility by keeping
> the old page-based API as wrapper functions around the new physical
> address-based implementations.
>
> This series refactors the DMA mapping API to provide a phys_addr_t
> based, and struct-page free, external API that can handle all the
> mapping cases we want in modern systems:
>
>   - struct page based cacheable DRAM
>   - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable
>     MMIO
>   - struct page-less PCI peer to peer non-cacheable MMIO
>   - struct page-less "resource" MMIO
>
> Overall this gets much closer to Matthew's long term wish for
> struct-pageless IO to cacheable DRAM. The remaining primary work would
> be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on
> phys_addr_t without a struct page.
>
> The general design is to remove struct page usage entirely from the
> DMA API inner layers. For flows that need to have a KVA for the
> physical address they can use kmap_local_pfn() or phys_to_virt(). This
> isolates the struct page requirements to MM code only. Long term all
> removals of struct page usage are supporting Matthew's memdesc
> project which seeks to substantially transform how struct page works.
>
> Instead make the DMA API internals work on phys_addr_t. Internally
> there are still dedicated 'page' and 'resource' flows, except they are
> now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both
> flows use the same phys_addr_t.
>
> When DMA_ATTR_MMIO is specified things work similar to the existing
> 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(),
> pfn_valid(), etc are never called on the phys_addr_t. This requires
> rejecting any configuration that would need swiotlb. CPU cache
> flushing is not required, and avoided, as ATTR_MMIO also indicates the
> address have no cacheable mappings. This effectively removes any
> DMA API side requirement to have struct page when DMA_ATTR_MMIO is
> used.
>
> In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow,
> except on the common path of no cache flush, no swiotlb it never
> touches a struct page. When cache flushing or swiotlb copying
> kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU
> usage. This was already the case on the unmap side, now the map side
> is symmetric.
>
> Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users
> must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA
> path must also set it. This corrects some existing bugs where iommu
> mappings for P2P MMIO were improperly marked IOMMU_CACHE.
>
> Since ATTR_MMIO is made to work with all the existing DMA map entry
> points, particularly dma_iova_link(), this finally allows a way to use
> the new DMA API to map PCI P2P MMIO without creating struct page. The
> VFIO DMABUF series demonstrates how this works. This is intended to
> replace the incorrect driver use of dma_map_resource() on PCI BAR
> addresses.
>
> This series does the core code and modern flows. A followup series
> will give the same treatment to the legacy dma_ops implementation.

Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it 
works fine in linux-next.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 23:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120998.1465592 (Exim 4.92)
	(envelope-from )
	id 1uwqSo-0007Mg-Gm; Thu, 11 Sep 2025 23:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120998.1465592; Thu, 11 Sep 2025 23: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 1uwqSo-0007M9-9r; Thu, 11 Sep 2025 23:12:26 +0000
Received: by outflank-mailman (input) for mailman id 1120998;
 Thu, 11 Sep 2025 23:12: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 1uwqSm-0007EP-T1
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 23:12:24 +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 c5b3377f-8f64-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 01:12:22 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-45dd5e24d16so11892585e9.3
 for ; Thu, 11 Sep 2025 16:12:22 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e03729c76sm40014715e9.6.2025.09.11.16.12.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 16:12: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: c5b3377f-8f64-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757632342; x=1758237142; darn=lists.xenproject.org;
        h=content-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=qA97h+zsPKEYB032/l0iO18TFQorVKP6/aYR2Xp/q4U=;
        b=aIJ1sX+JYgvVaKVjGtoLsd87yJ/57/FKYDqxrLmmXrl+v8BpRSuTxqVK6WLBofh+7V
         oY5O1XkutL1hkbi8+N4uTNc8vSdrIZ1EUXc1FIG+L7oHiIIV/M9ZmE1mAPY+/KZq4W24
         vE9gLOt9M3BLPLprhP0McZ68vOx1H75gFzIdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757632342; x=1758237142;
        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=qA97h+zsPKEYB032/l0iO18TFQorVKP6/aYR2Xp/q4U=;
        b=ppq1rDv19A2qGgGpndKxjCZqBaddzAGnCl17dniRxQs4RXq15NtUJc5PeSxFfB+C8k
         1Ho351r+uCgGCvb/BBVg/ys8r8+uuv2sGXjcb2tIdkC/7ZtYSlMrz+tPvhModCwx6JXm
         +t2/DJFe6a7TEdCW3VTW2p3MWY7UizrXZj2aN1HbsK7jrXBMc9UMWrPNsWqYEJW1R2am
         PuLBjrTL5bZ2pxy2z4+GfDX5iR8vLa9Z519D+nTpDpKqIf7MY/eBpoziN+KLlt8i6oKe
         dStPmGwcaytMqQ3CHgAMCNtnR/ExNM3fCzeOmRR4bNiGGe5uVIvG0DSiPflrLX/fZT+m
         DYrg==
X-Gm-Message-State: AOJu0Yz9vAoZaFqCAXn2Nul9pYLQpfrm4C0QxJNKzey+/CIR6I4/0UYi
	+6HVd4ZPLZWL1YwbxJrMxHOgG/IegK7qHgHE5hwt79ujrUGPt168LAZQqk0VO7JjybtuLUw+9ky
	4eVS+
X-Gm-Gg: ASbGncuV9s7qzw/5pzMymQV84z5jbNnIg++vFrOXBhH8My00OWQONkE7T16KdXCnRU6
	8yuNwPNRUbZv7oMwBGNvCepuKU9+sTbl0ILfkJeoMKNDXxDAY/H7DaXkjp7jeWYBamE1rpPiWKi
	M8Ed0wAn+b1rMRs7AEx9FfcS5KMYlmtZZNAuJsBc9xs9PM5YnbwagxYlvLT8WcMwvC8lLJ1BEfd
	nxRXyxfZpFXlLc1zVLCWbYJAVJGvk62un7li+AI2GR14+bXuvMrRJvJeVtX7WqipBk98fRubjlR
	8uTA8O2a3uYU2jmrPTNF8LvjJT0gQLmZAOUSQo+Dpc6KXSNKBuHaxNx3y+8QqCKbWPnElOhjn3M
	94MsAXHCKtJYq3WDQLpp8iAUXBESr5Z2T/KJg3wl4SpsoFjq2+fD//M+T4zO1X/P2iuzRRUolBB
	Bs
X-Google-Smtp-Source: AGHT+IGkeZP9ism/K61CjFrZhMUU/Ygfd+tEVAVA1LYM92gkINWhEnDPDJ7BylRoYSjWwM63IWQNZw==
X-Received: by 2002:a05:600c:3b26:b0:45b:7a93:f108 with SMTP id 5b1f17b1804b1-45f211c4c47mr8257535e9.3.1757632341839;
        Thu, 11 Sep 2025 16:12:21 -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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v3 2/5] CI: Update ppc64 to use Debian Trixie
Date: Fri, 12 Sep 2025 00:12:13 +0100
Message-Id: <20250911231216.1886818-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Everything works fine with Debian 13.  Provide two new build jobs (for a total
of 6), and update the test jobs.

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: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v3:
 * Update .qemu-ppc64le template too
v2:
 * Update containerize
---
 ...pc64le.dockerfile => 13-ppc64le.dockerfile} |  2 +-
 automation/gitlab-ci/build.yaml                | 18 ++++++++++++++++--
 automation/gitlab-ci/test.yaml                 |  4 ++--
 automation/scripts/containerize                |  1 +
 4 files changed, 20 insertions(+), 5 deletions(-)
 copy automation/build/debian/{12-ppc64le.dockerfile => 13-ppc64le.dockerfile} (93%)

diff --git a/automation/build/debian/12-ppc64le.dockerfile b/automation/build/debian/13-ppc64le.dockerfile
similarity index 93%
copy from automation/build/debian/12-ppc64le.dockerfile
copy to automation/build/debian/13-ppc64le.dockerfile
index da518aab4e10..5b22a4545842 100644
--- a/automation/build/debian/12-ppc64le.dockerfile
+++ b/automation/build/debian/13-ppc64le.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/amd64 debian:bookworm-slim
+FROM --platform=linux/amd64 debian:trixie-slim
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index c0728e58c48b..f8e45f3467c8 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -319,10 +319,10 @@ debian-12-x86_64-clang-debug:
   variables:
     CONTAINER: debian:12-x86_64
 
-debian-12-ppc64le-gcc-debug:
+debian-13-ppc64le-gcc-debug:
   extends: .gcc-ppc64le-cross-build-debug
   variables:
-    CONTAINER: debian:12-ppc64le
+    CONTAINER: debian:13-ppc64le
     KBUILD_DEFCONFIG: ppc64_defconfig
     HYPERVISOR_ONLY: y
     EXTRA_XEN_CONFIG: |
@@ -705,6 +705,20 @@ debian-12-ppc64le-gcc:
     KBUILD_DEFCONFIG: ppc64_defconfig
     HYPERVISOR_ONLY: y
 
+debian-12-ppc64le-gcc-debug:
+  extends: .gcc-ppc64le-cross-build-debug
+  variables:
+    CONTAINER: debian:12-ppc64le
+    KBUILD_DEFCONFIG: ppc64_defconfig
+    HYPERVISOR_ONLY: y
+
+debian-13-ppc64le-gcc:
+  extends: .gcc-ppc64le-cross-build
+  variables:
+    CONTAINER: debian:13-ppc64le
+    KBUILD_DEFCONFIG: ppc64_defconfig
+    HYPERVISOR_ONLY: y
+
 # RISC-V 64 cross-build
 debian-12-riscv64-gcc:
   extends: .gcc-riscv64-cross-build
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 1de68a0fe450..e8946e15dc3a 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -90,7 +90,7 @@
 .qemu-ppc64le:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-ppc64le
+    CONTAINER: debian:13-ppc64le
     LOGFILE: qemu-smoke-ppc64le.log
   artifacts:
     paths:
@@ -712,4 +712,4 @@ qemu-smoke-ppc64le-powernv9-gcc:
   script:
     - ./automation/scripts/qemu-smoke-ppc64le.sh powernv9 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-ppc64le-gcc-debug
+    - debian-13-ppc64le-gcc-debug
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 340b6caaab44..65c8804ce5f3 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -31,6 +31,7 @@ case "_${CONTAINER}" in
     _fedora) CONTAINER="${BASE}/fedora:41-x86_64";;
     _bullseye-ppc64le) CONTAINER="${BASE}/debian:11-ppc64le" ;;
     _bookworm-ppc64le) CONTAINER="${BASE}/debian:12-ppc64le" ;;
+    _trixie-ppc64le) CONTAINER="${BASE}/debian:13-ppc64le" ;;
     _bookworm-riscv64) CONTAINER="${BASE}/debian:12-riscv64" ;;
     _trixie-riscv64) CONTAINER="${BASE}/debian:13-riscv64" ;;
     _bookworm-x86_64-gcc-ibt) CONTAINER="${BASE}/debian:12-x86_64-gcc-ibt" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 23:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120999.1465599 (Exim 4.92)
	(envelope-from )
	id 1uwqSp-0007YU-1p; Thu, 11 Sep 2025 23:12:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120999.1465599; Thu, 11 Sep 2025 23: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 1uwqSo-0007VV-PD; Thu, 11 Sep 2025 23:12:26 +0000
Received: by outflank-mailman (input) for mailman id 1120999;
 Thu, 11 Sep 2025 23: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 1uwqSo-00070m-1y
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 23:12:26 +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 c7897e24-8f64-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 01:12:25 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-45cb6428c46so14741945e9.1
 for ; Thu, 11 Sep 2025 16:12:25 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e03729c76sm40014715e9.6.2025.09.11.16.12.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 16:12: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: c7897e24-8f64-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757632345; x=1758237145; darn=lists.xenproject.org;
        h=content-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=FRzzkStlIW6Boe0j8jd7BGR45fCprZcNJeI4i+HTj+s=;
        b=LWRIeHl4NrvrGslBWwqgX7AmAMiKU1Yhhk4Ld3RpZe2ecCRFKqYez9v7OnbQGdrhQe
         0bZCUvR3umzMboiG7ZJOzkHl14aEKZduqYtGfcQ5RiiyyHoyj85eW/TrhqsZmTMIFzFZ
         erPOS+QWzkTlkegqWYpdZfR9LQC6l3kU3RmMY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757632345; x=1758237145;
        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=FRzzkStlIW6Boe0j8jd7BGR45fCprZcNJeI4i+HTj+s=;
        b=UuqjKBrdWplyhPR/keaACWwbHZh7uE9iVaMLOcTGmj7QgFSOGaSRKO07wszKRRja+Y
         eQHaSCU+LfXZYUWWOamnNFdiFyJ+f39N2Ry7FButaL+REwbVpL9X57IKsItQ1IEWknoj
         HV9WYg7BQrYTtMNUd2d6XQgjeQo67OLSMz0034ocloF9s59ukKvAf/iwJkejGaS85eXd
         HriWup7YmYLwSbr3tPxq3bYbh5tWnU18pG5fGVNlRkdNuKG0JA01/dCi7h2Ybzg22C0n
         XXA8LOcYz7ohnjLbw7eFchtH5uRDInn9JNkTNaAJ/m8q34S5kk5C+YRUL2RbufoRIhG6
         gJtA==
X-Gm-Message-State: AOJu0YwqePZCkoG7qoi17iNjr+j3fRp8o47IMCskJHjMJI9Y4QyIw9EY
	gtAwIaeS6FOGhLfowkU4Llu96fTjLqoz7JSHBc8OkAs/hoHtq2v8SkVOPl6WSIACbzszlADc4X1
	voxFD
X-Gm-Gg: ASbGnct/q2oPL0XxEcxoNp+ENyjU7m3uQzolyEhkN2e/5s1Jyp6ZtM9jIiOvhBhfEdq
	PwzhdJTv9/0EHjQwcyC4KH68H0u5kmN3WYugbcgei3Z7pQ6lPVldzs6Uo3+u6GMaRI6ERz1DlsG
	SjHi6/AcjEQ6HpYvidig/NC+LW1CN1j51Sb5pNhUnPOduDJQL1/DqE5lupD/XvSXt6o8ZJS7tOX
	Iwv9QSKgje6aqzxqz4fqc5ZusngdoL3ejJ6zrEL7T7fJFpLx2IAdkcesOzmBMYRNBWIzxlQKaVu
	nvAd0V6DYOm9IjeIcNVOMu8/u77l3dDT7JAfBrTRXvgOGeJxldxPKEg7VjuPpmhG6jn1c/E+y5o
	lJ6H4vtMLwb4w1t+EKgGz5x0c5zcZB4XGSSo1lZbY0G/hW4SgyRGr1LJcrEmPdAD2GTyXw54cB9
	ks
X-Google-Smtp-Source: AGHT+IFcVNFTgWUWmuJhtP5yb3dIMz7oWoZD78httYc6541oZoWGaa8cRwkdy9rw24mK4VTfMHgBXA==
X-Received: by 2002:a05:6000:290c:b0:3e3:1736:a7d9 with SMTP id ffacd0b85a97d-3e7657928b8mr655623f8f.18.1757632344851;
        Thu, 11 Sep 2025 16:12:24 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Oleksii Kurochko ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 5/5] CHANGELOG: Notes about distro changes in CI
Date: Fri, 12 Sep 2025 00:12:16 +0100
Message-Id: <20250911231216.1886818-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Also state the RISC-V baseline now it's been set, as it's the reason why
RISC-V Bullseye got dropped.

Signed-off-by: Andrew Cooper 
Acked-by: Oleksii Kurochko 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Oleksii Kurochko 

v2:
 * New
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7bd96ac09d14..ca1b43b940d2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -10,6 +10,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - The minimum toolchain requirements have increased for some architectures:
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
+   - For RISC-V, GCC 12.2 and Binutils 2.39
+ - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
+   to the baseline change.
  - Linux based device model stubdomains are now fully supported.
 
  - On x86:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 23:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120995.1465569 (Exim 4.92)
	(envelope-from )
	id 1uwqSk-00070z-L7; Thu, 11 Sep 2025 23:12:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120995.1465569; Thu, 11 Sep 2025 23: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 1uwqSk-00070s-I9; Thu, 11 Sep 2025 23:12:22 +0000
Received: by outflank-mailman (input) for mailman id 1120995;
 Thu, 11 Sep 2025 23: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 1uwqSj-00070m-SI
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 23:12:21 +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 c499fed6-8f64-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 01:12:20 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-45ed646b656so6195575e9.3
 for ; Thu, 11 Sep 2025 16:12:20 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e03729c76sm40014715e9.6.2025.09.11.16.12.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 16:12: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: c499fed6-8f64-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757632340; x=1758237140; 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=+Msz/P4Iipik3z5leLuYvmWF+Vhjs/lcwil6do7QRps=;
        b=QYdzt56W18R/lmpkTGyJoR++jwpeesDE41EAlQ816Ryj+RijDCOf0JqJa/1TM4CwQe
         4BD5uF46wT+1Gi34F5Z5y5RexAUXTvhce2HSVyJmpxPlEfENY1OSlgMCtk+kmZ+yd4WQ
         3wMFKFrVkRNiYeUodyB7aRGgTKu8UPikP+DR0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757632340; x=1758237140;
        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=+Msz/P4Iipik3z5leLuYvmWF+Vhjs/lcwil6do7QRps=;
        b=Vo5a3CBLQLKv4+3P4fYSyIA2nzLrg1S7Q7pHMVii6Z8WhbaIqc3auD16c1fEtBr7zx
         85gl3A7d0cD4CMZ0env0hKe3O8NSaz6jkEzsRC8OFoWeOcdHbKRjm75WWVCr+0hG5hyK
         GqAxo+9gBarS0GmJFjlIe/S6NKVEa3uprj3Ak4HAA13LTJl7109LdpMq9XLhN6fWDRDY
         ijNs7spXg/gp3Ii2k5JLomDeye/kTN+e/w9AmmQNjYeWsFfZ+nr3B061Gj1rBvL/+ZbD
         4O4R8xtjLy2CwnWi+ZT93bGLZ7lvgODDVaekubGVRbGSp6vstsqvYSFD62ywb5dOqNlH
         Be8A==
X-Gm-Message-State: AOJu0YzcWD/wX/1y2sx9RfiEIMa0zlp3kYC5P5RR+i+F+Mh0BGI2tUuL
	mNFSbE067lmpeU1wJ8NwpN1pondV5uzfKWrHUxvieBQKWx29Gr+AjP06f+78Vi9FRPLH2su5tpa
	BKZYj
X-Gm-Gg: ASbGncu7wotykUjYSdpQco0oK4nrFUquPRm3CEFAB8c0beUK0Xb1QIWkJl66uUACPsI
	0VhRDXZOvUUwQnJ9IXvJY6ycyr0kX9pnpMAp1fMHL+zZrZbE6waohaw0Y4Pfd1u1fCwj6QSZwH8
	ud1bHrOBjg5D5UBUSd/UbKf3aKwdQQ8X4CZaD0GCgVO2hFC3BqxeWgeIA1xwAUmI0Q6UrKt/s61
	AdqBc078cdxSLPZ/ssE9QuoNvcEpGIAQFhAp3DhtX1WrqoNtoCRGiGy1WWzorD6P0uV+KhsRAXm
	RbN/XdRECTfXNpdoItSQxQhMS8vMh6est3104v5Oq7MP87YcgiTrrIBHoB0svavAk8sgriG+gdA
	huS7pgL/7K7Bmt69mIHLgPxzFskjOhQwxRmoV4w1rfMZeSdl2PsLYdDtuTqyrCUhiwmmcffII5z
	Jm
X-Google-Smtp-Source: AGHT+IGC+bIc1T74WN63SoD7WCNF2JD3BT8W3tc2jyJjdyvVCyZH7heUYQXCve0lh1eDfrBNbtkUFA==
X-Received: by 2002:a05:600c:630e:b0:45d:da25:595d with SMTP id 5b1f17b1804b1-45f211f8835mr8748935e9.22.1757632339941;
        Thu, 11 Sep 2025 16:12:19 -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 ,
	Oleksii Kurochko ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v3 0/5] CI: Add Debian Trixie
Date: Fri, 12 Sep 2025 00:12:11 +0100
Message-Id: <20250911231216.1886818-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

Refreshed the Trixie series.  See patches for details.

These containers are already built and deployed for people to test with.

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

Andrew Cooper (5):
  CI: Use the Debian Trixie container for RISC-V test jobs
  CI: Update ppc64 to use Debian Trixie
  CI: Merge categories in debian/12-x86_64.dockerfile
  CI: Update x86 to use Debian Trixie
  CHANGELOG: Notes about distro changes in CI

 CHANGELOG.md                                  |  3 +
 automation/build/debian/12-x86_64.dockerfile  | 12 ++--
 ...c64le.dockerfile => 13-ppc64le.dockerfile} |  2 +-
 ...x86_32.dockerfile => 13-x86_32.dockerfile} |  2 +-
 ...x86_64.dockerfile => 13-x86_64.dockerfile} | 14 ++--
 automation/gitlab-ci/build.yaml               | 72 +++++++++++++++----
 automation/gitlab-ci/test.yaml                | 18 ++---
 automation/scripts/containerize               |  4 +-
 8 files changed, 84 insertions(+), 43 deletions(-)
 copy automation/build/debian/{12-ppc64le.dockerfile => 13-ppc64le.dockerfile} (93%)
 copy automation/build/debian/{12-x86_32.dockerfile => 13-x86_32.dockerfile} (95%)
 copy automation/build/debian/{12-x86_64.dockerfile => 13-x86_64.dockerfile} (89%)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 23:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120996.1465580 (Exim 4.92)
	(envelope-from )
	id 1uwqSn-0007F8-Sc; Thu, 11 Sep 2025 23:12:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120996.1465580; Thu, 11 Sep 2025 23:12:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwqSn-0007F1-Q5; Thu, 11 Sep 2025 23:12:25 +0000
Received: by outflank-mailman (input) for mailman id 1120996;
 Thu, 11 Sep 2025 23:12:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwqSm-00070m-2u
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 23:12:24 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c65b8f9e-8f64-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 01:12:23 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45df656889cso8263005e9.1
 for ; Thu, 11 Sep 2025 16:12:23 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e03729c76sm40014715e9.6.2025.09.11.16.12.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 16:12: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: c65b8f9e-8f64-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757632343; x=1758237143; darn=lists.xenproject.org;
        h=content-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=iOUALOCpdFsqmHA3SRQn/svniHSJ57I695EoNza7NlM=;
        b=MUI6PdIuZSQwZZMRWrZwrstYq0fVYL1+zd8vsYGrglwvQY2jUHzusSIY7htb3gPmJW
         4OcFAC5RGYtQwdu/MemjiprY3pBbHgBCdFFrrGniE1hLX6eOrFS9fCHIH/x5mUf9DFIg
         RrSW5OVdUE9PJTd2T/lc30UUsuFeAdCvcfdRk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757632343; x=1758237143;
        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=iOUALOCpdFsqmHA3SRQn/svniHSJ57I695EoNza7NlM=;
        b=iNMS+BqYluYAWY0dNeXNn6YliuhHZ5eRxA7JOe3DZDhk5jiVdgPz7dHAD9QgJD8rOX
         DHAH+0H45raOJyn0hxNEhWLCEougxBrfUcm+8SHLphMXhBLjRVOruadDa0MkZZGxuuZn
         YT017Oei1o3ycrORaFDYhyeg8VgPiqUr04NzV81RG/JXeh61b/wGb7avtZExnF189KoM
         GkhFB0cjCddR5ItEQyXPSy6EMVHlSwLun1NTJyM7zQdyeUrfyjIhLKqS3d9+1igV2hzc
         HL9xULRqPFxNIuFBuKPUv/4eVe+Qi3cMkhX76ay6ons0dRd9jROOxrZmSI+3vgmNzcuY
         baYA==
X-Gm-Message-State: AOJu0Yxf9gw6pCEaIYRucH/zkAtv+q1J2TEvfjpcxEW6WS+Ti3ZKckGw
	mDpU3CuoM2SUYFFtMH38aLMru+qNO1E0HsHukoUwlQT2X4z7wG35xl1AUFC1V7ML/USH9RJV74i
	C9nld
X-Gm-Gg: ASbGncs2+2LwIHVNNCyAsKxayCjK3k+um/kdyrwXgTEOex7lTLiYLSWkcnz9NgpMbWn
	iby6oYR2OeMz8xhDHU3S0yBPMx2Q9J8Ve+bk/PTwx8kELxuQUFluRGz9+x8wjr1YkqqBRf7o0sN
	4ZBJUvWCDUAEs6P4wuutFwTIv8wh438ZWMI25joC8OXRVv0tj+SisYDActerfgTTb3fbzo+m5eW
	SpSuhqPUobf7CQGXCq6ecRSJwqhWq0o+1Ft0mM6yfTQ4Nc+xZpwzEa3p/YA0vT2Gz/A/akqoOA/
	ry2qf/Y/o4efzCdnccgUwvnyPSB7SQs7+Fp+2AbIMxf25LRtv/n6Nx9S5Q1IbIfwSW3vTe9ESlg
	Ww3cCkcpEfUa+7GVcS4kTO3F0qdv4pVaXhi0D2e4GoG7yKVXsRGU1C/9IgL4NpjR0cKHNmWfaKz
	LiTCTV0P2BOrQ=
X-Google-Smtp-Source: AGHT+IFii9WBqjjp8HnC++x+cmQBqZl+SrBHhgF01zlr0HQzxmRj6ziAFyPoy1JLsfQ0HAaZLrJHgw==
X-Received: by 2002:a05:6000:2008:b0:3e1:2d70:674e with SMTP id ffacd0b85a97d-3e7659f3c6cmr624555f8f.47.1757632342864;
        Thu, 11 Sep 2025 16:12:22 -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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v3 3/5] CI: Merge categories in debian/12-x86_64.dockerfile
Date: Fri, 12 Sep 2025 00:12:14 +0100
Message-Id: <20250911231216.1886818-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpio needs to be in Tools (general) now that it's used by the general build
script.  Merge the rest of the test phase jobs into one group, to avoid being
overly fine-grain.

No functional change.

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: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

Prep for making a Debian Trixie derivative.

v3:
 * New
---
 automation/build/debian/12-x86_64.dockerfile | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/automation/build/debian/12-x86_64.dockerfile b/automation/build/debian/12-x86_64.dockerfile
index 3cf99c730b61..4e533ee879fd 100644
--- a/automation/build/debian/12-x86_64.dockerfile
+++ b/automation/build/debian/12-x86_64.dockerfile
@@ -23,6 +23,7 @@ RUN <
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121000.1465618 (Exim 4.92)
	(envelope-from )
	id 1uwqSq-000827-76; Thu, 11 Sep 2025 23:12:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121000.1465618; Thu, 11 Sep 2025 23:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwqSq-00080K-1a; Thu, 11 Sep 2025 23:12:28 +0000
Received: by outflank-mailman (input) for mailman id 1121000;
 Thu, 11 Sep 2025 23: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 1uwqSo-0007EP-Ly
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 23:12:26 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c705ed73-8f64-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 01:12:24 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3dce6eed889so1194382f8f.0
 for ; Thu, 11 Sep 2025 16:12:24 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e03729c76sm40014715e9.6.2025.09.11.16.12.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 16:12: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: c705ed73-8f64-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757632344; x=1758237144; darn=lists.xenproject.org;
        h=content-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=GeLwzviMpfWDaMr+4cJyL8clwYsQTKK8d3VCevZ5LjE=;
        b=ML4MkSgyHGC/sgYT6FLxg9VUW+zyXmpsJCd7UGbVyMDJOx6HSsIb/Sq18eSiD1xXGW
         mpR6Le4shfJ+W7ItvYBc+88myI4j7Z8vz0I5sOKuoCcQoR5u0ewxhMkyrv9anVfYf/WA
         q8ArHNNDmrnYFqGhjC/L2txr9PFmQOMSd0yrw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757632344; x=1758237144;
        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=GeLwzviMpfWDaMr+4cJyL8clwYsQTKK8d3VCevZ5LjE=;
        b=Z3evbaNUvzOhSx/uUFJYVpPHsNYN2e4lkJshhDyjJsl0lVESmCl+Bs8s6ASAoU0/tV
         syF6rKG/mTFcQ2kPy6n+BS+NyMs+Bpz5kuyt/NDCXTQgPuwjlNb8Vt04OLmDxDP02USa
         VW5Jc89HNc87XOrAGsR/jCA4b4W4w1/vJVpsQOVTZzrNRg6HB5e4wZ4yJHDnr5j5WHfG
         l/klE3MoRFNI7/9C4OcBFG8GgmC8F3/sErm5P1eY9bllVsB8whbzx+4UwSsqEYsY6Bgz
         A3I+vfnHFJWExOkH2J39noegb2OAgtqYUU70Ur6TQ4EgGQvQZHuEGpuYxp03KyTl1l6C
         xqzA==
X-Gm-Message-State: AOJu0YzZCx6g5RNEOoxu/QP72sYH0PxOrSMKoFlx6WGXSqziKwwbtd5v
	WtMMMAeYaJpX4k/B/tTMIoVLO6BPNYtmxDzHf2x1ixRoCaRDMuAZ/VCccWPCh6u4rw48JSoNM0l
	EoVBc
X-Gm-Gg: ASbGncvvfI0tlNF1GB7C7P3y53q0A0BYOU1WeZIHEfZMyer2Xb0a4w5qu6HHWpxDTKx
	4wQREVkDD4sMaTu5SNGujGweHE9SrY0xq/GESOlWu/3Idh12+WlzLc990EnC4akDi70LrzUdk/C
	0bqH1+5z0rhzx1z2y6OrG6Wbs/6GbVePsmDac801Hpkv8/sxLgYi/UADZa+a8p9DapDfPY3pPzo
	OWrUSGgRUpUArpI3nCJf0lwLqVu0NfT4Pu/9MZuB/COI3K0s2DujFiqOs6SsNWox1nnWPxVOrRx
	EGRpF+nWNzgDBFAjD7m1PKbHn1Z/FwVWtrQQgU2mrDgaXyWb1HClbdmQxQqau5V6iiKCBLzK9tf
	LEoIOtbmOSBycfhdLpVtUaqxrv1kTL/VeE/hN0Wdio+M8ZDf0TYxPdGn0QAHbhLpGpAJNdQc3ok
	qwLjxhFMjGuOg=
X-Google-Smtp-Source: AGHT+IFX23G7QN0g3dE2sYV/MnY6dXS7qgjlt2Aw6ZFq9rRDcdGw2dFEWCLCyJHH/WZaILosgsFjww==
X-Received: by 2002:a05:6000:40c9:b0:3e7:42c5:ea46 with SMTP id ffacd0b85a97d-3e765a03801mr718781f8f.55.1757632343917;
        Thu, 11 Sep 2025 16:12:23 -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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v3 4/5] CI: Update x86 to use Debian Trixie
Date: Fri, 12 Sep 2025 00:12:15 +0100
Message-Id: <20250911231216.1886818-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the exception of the custom IBT job, copy all Debian 12 jobs making
Debian 13 versions, then trim the Debian 12 ranconfig jobs.

Update the test jobs using Debian 12 to use 13.

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: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v3:
 * Update .qemu-x86-64 too.
 * Rebase over cleanup to 12-x86_64
v2:
 * Make 13-x86_64 be root-less
 * Update containerize
---
 ...x86_32.dockerfile => 13-x86_32.dockerfile} |  2 +-
 ...x86_64.dockerfile => 13-x86_64.dockerfile} |  2 +-
 automation/gitlab-ci/build.yaml               | 54 ++++++++++++++-----
 automation/gitlab-ci/test.yaml                | 12 ++---
 automation/scripts/containerize               |  3 +-
 5 files changed, 52 insertions(+), 21 deletions(-)
 copy automation/build/debian/{12-x86_32.dockerfile => 13-x86_32.dockerfile} (95%)
 copy automation/build/debian/{12-x86_64.dockerfile => 13-x86_64.dockerfile} (96%)

diff --git a/automation/build/debian/12-x86_32.dockerfile b/automation/build/debian/13-x86_32.dockerfile
similarity index 95%
copy from automation/build/debian/12-x86_32.dockerfile
copy to automation/build/debian/13-x86_32.dockerfile
index ef7a2571556b..2bd11af5a0c3 100644
--- a/automation/build/debian/12-x86_32.dockerfile
+++ b/automation/build/debian/13-x86_32.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/i386 debian:bookworm
+FROM --platform=linux/i386 debian:trixie-slim
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/build/debian/12-x86_64.dockerfile b/automation/build/debian/13-x86_64.dockerfile
similarity index 96%
copy from automation/build/debian/12-x86_64.dockerfile
copy to automation/build/debian/13-x86_64.dockerfile
index 4e533ee879fd..2c6c9d4a5098 100644
--- a/automation/build/debian/12-x86_64.dockerfile
+++ b/automation/build/debian/13-x86_64.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/amd64 debian:bookworm
+FROM --platform=linux/amd64 debian:trixie-slim
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index f8e45f3467c8..4cb52fe59715 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -309,15 +309,15 @@ alpine-3.18-gcc-debug:
       CONFIG_UCODE_SCAN_DEFAULT=y
       CONFIG_XHCI=y
 
-debian-12-x86_64-gcc-debug:
+debian-13-x86_64-gcc-debug:
   extends: .gcc-x86-64-build-debug
   variables:
-    CONTAINER: debian:12-x86_64
+    CONTAINER: debian:13-x86_64
 
-debian-12-x86_64-clang-debug:
+debian-13-x86_64-clang-debug:
   extends: .clang-x86-64-build-debug
   variables:
-    CONTAINER: debian:12-x86_64
+    CONTAINER: debian:13-x86_64
 
 debian-13-ppc64le-gcc-debug:
   extends: .gcc-ppc64le-cross-build-debug
@@ -545,24 +545,20 @@ debian-12-x86_64-clang:
   variables:
     CONTAINER: debian:12-x86_64
 
-debian-12-x86_64-clang-randconfig:
-  extends: .clang-x86-64-build
+debian-12-x86_64-clang-debug:
+  extends: .clang-x86-64-build-debug
   variables:
     CONTAINER: debian:12-x86_64
-    RANDCONFIG: y
-    EXTRA_FIXED_RANDCONFIG: |
-      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
 
 debian-12-x86_64-gcc:
   extends: .gcc-x86-64-build
   variables:
     CONTAINER: debian:12-x86_64
 
-debian-12-x86_64-gcc-randconfig:
-  extends: .gcc-x86-64-build
+debian-12-x86_64-gcc-debug:
+  extends: .gcc-x86-64-build-debug
   variables:
     CONTAINER: debian:12-x86_64
-    RANDCONFIG: y
 
 debian-12-x86_32-clang-debug:
   extends: .clang-x86-32-build-debug
@@ -574,6 +570,40 @@ debian-12-x86_32-gcc-debug:
   variables:
     CONTAINER: debian:12-x86_32
 
+debian-13-x86_64-clang:
+  extends: .clang-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+
+debian-13-x86_64-clang-randconfig:
+  extends: .clang-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+    RANDCONFIG: y
+    EXTRA_FIXED_RANDCONFIG: |
+      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
+
+debian-13-x86_64-gcc:
+  extends: .gcc-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+
+debian-13-x86_64-gcc-randconfig:
+  extends: .gcc-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+    RANDCONFIG: y
+
+debian-13-x86_32-clang-debug:
+  extends: .clang-x86-32-build-debug
+  variables:
+    CONTAINER: debian:13-x86_32
+
+debian-13-x86_32-gcc-debug:
+  extends: .gcc-x86-32-build-debug
+  variables:
+    CONTAINER: debian:13-x86_32
+
 fedora-41-x86_64-gcc:
   extends: .gcc-x86-64-build
   variables:
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index e8946e15dc3a..8d8f62c8d04d 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -59,7 +59,7 @@
 .qemu-x86-64:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-x86_64
+    CONTAINER: debian:13-x86_64
     LOGFILE: qemu-smoke-x86-64.log
   artifacts:
     paths:
@@ -661,35 +661,35 @@ qemu-smoke-x86-64-gcc:
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-smoke-x86-64-clang:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-clang-debug
+    - debian-13-x86_64-clang-debug
 
 qemu-smoke-x86-64-gcc-pvh:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 hvm64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-smoke-x86-64-clang-pvh:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 hvm64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-clang-debug
+    - debian-13-x86_64-clang-debug
 
 qemu-smoke-x86-64-gcc-efi:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64-efi pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-xtf-argo-x86_64-gcc-debug:
   extends: .qemu-smoke-x86-64
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 65c8804ce5f3..743567cb772a 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -35,7 +35,8 @@ case "_${CONTAINER}" in
     _bookworm-riscv64) CONTAINER="${BASE}/debian:12-riscv64" ;;
     _trixie-riscv64) CONTAINER="${BASE}/debian:13-riscv64" ;;
     _bookworm-x86_64-gcc-ibt) CONTAINER="${BASE}/debian:12-x86_64-gcc-ibt" ;;
-    _bookworm|_bookworm-x86_64|_) CONTAINER="${BASE}/debian:12-x86_64" ;;
+    _bookworm|_bookworm-x86_64) CONTAINER="${BASE}/debian:12-x86_64" ;;
+    _trixie-x86_64|_) CONTAINER="${BASE}/debian:13-x86_64" ;;
     _bookworm-i386|_bookworm-x86_32) CONTAINER="${BASE}/debian:12-x86_32" ;;
     _bookworm-arm64v8-arm32-gcc) CONTAINER="${BASE}/debian:bookworm-arm64v8-arm32-gcc" ;;
     _bookworm-arm64v8) CONTAINER="${BASE}/debian:bookworm-arm64v8" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Sep 11 23:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Sep 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1120997.1465585 (Exim 4.92)
	(envelope-from )
	id 1uwqSo-0007HN-5e; Thu, 11 Sep 2025 23:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1120997.1465585; Thu, 11 Sep 2025 23: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 1uwqSo-0007Gb-1z; Thu, 11 Sep 2025 23:12:26 +0000
Received: by outflank-mailman (input) for mailman id 1120997;
 Thu, 11 Sep 2025 23:12: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 1uwqSm-0007EP-7i
 for xen-devel@lists.xenproject.org; Thu, 11 Sep 2025 23:12:24 +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 c53839d3-8f64-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 01:12:21 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-45df656889cso8262925e9.1
 for ; Thu, 11 Sep 2025 16:12:21 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e03729c76sm40014715e9.6.2025.09.11.16.12.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 16:12: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: c53839d3-8f64-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757632341; x=1758237141; darn=lists.xenproject.org;
        h=content-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=moBCqRr5Tce3kLFSshOWPZblWbvo8j34kwNtthkvDIw=;
        b=JBBXRkkWcjYVfxnQ/6qGtRB2Z3WsaQ+C+IkoOzZOsWuiT0N3pczI6iZ5qW2XoYlqwY
         g/A1E1V94FxSn4FYlTsN/FDHUit6FJQzAhEqLFTF9MFhjvrBiarfxChGnxT+t7q+IISc
         9rVu/YlRr20yuaN6Ahqdmyt8FubBtTK5leLqs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757632341; x=1758237141;
        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=moBCqRr5Tce3kLFSshOWPZblWbvo8j34kwNtthkvDIw=;
        b=uems2m06RbvvdRiKK0BUdD48Te4kfozrVXV9bnv45S87Msze2SIEqEh24VegK+DbVd
         beoGQw0LSrG9osAkLynZVJDFKkXjJxqwAj28V2S+zMNz4hFybLgQ6nJuuk60bycSLtKS
         YDnfRZ06JSJseEULgSgJ9evnwquicw1+Sqm5BX3jGpqrb0JqcLqtWKZt1t7P98wtJMNj
         qWn64FT32doWvmfuF7woAP5+42HEOyvHiZDKCh+Kz/9uSP6t/4Gstnho+bu43b8G5yi+
         K1dm7+B4/TH6UQOclmON57dlTugcAkJ9RBRcxjJcvykeWChb5rAekH7Zr7Lh5mhbVX3I
         uY+Q==
X-Gm-Message-State: AOJu0YxSfyrrUJJ9re6FuFwKXJqU/8TMo6CXSgDshz6ndGvptFxj5fBD
	menmF4YGcQibdxMiGFUr/ixQ5WERHyXpbJm8IkJwiEx+OQ7PJUiG4GhzcLSrVVQ/Cc3gI+dMtIX
	BCQxB
X-Gm-Gg: ASbGncu32OAKAjgyXsbcBzrD24ZlYNxD3OFUiY+ONA6qjUHvIRzKG5JkbTfBAQqzMsQ
	OtuGT1MC5oz5jzJx4hz9OcxEw6RkPW9NB+7f/6YCxZSwtlqtdTg0ldphdP7e0G4DDR5L7gigxJI
	GZti0CCAJfENXWzk8x2LiZ7VdWy5Bi/C7GU3+uPNzuLm2prEgn/XDg8teSTezoJz5eFxhJa3huf
	vrG2GMF8fKkzN5Uw0OpbxefFeVNhFyM9eSE/iodJKEp5mmkJzIJMHO6lOCIfYWmIpygOuv7AmG0
	cOyPBuaajKK3tCBZypxyUh4gT0IvEaENldTWbid2t3fOxeA3GuSgs5LmsXhbkYTHxmb+p/5qWC9
	r1yVLK/Osm20zum4fQqyIIQeRY8vyA6fsUtLPwaf5IqhM0bDfOWJOFiMJ/MuIP6H9WQWFlYYZS4
	4URh4q0ZWGV9I=
X-Google-Smtp-Source: AGHT+IFn4eSEVOqBx+EUwg3DPBWka8jtAlLC92oVZkkzviYQMrlbmjdmYHW6UYYgM8Armi+t93ZHxw==
X-Received: by 2002:a05:600c:5798:b0:45d:ddc6:74a9 with SMTP id 5b1f17b1804b1-45f211d5507mr6613845e9.12.1757632340905;
        Thu, 11 Sep 2025 16:12: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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v3 1/5] CI: Use the Debian Trixie container for RISC-V test jobs
Date: Fri, 12 Sep 2025 00:12:12 +0100
Message-Id: <20250911231216.1886818-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This was missed when introducing Trixie.

Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
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: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v3:
 * New
---
 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 95b883b32bb6..1de68a0fe450 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -77,7 +77,7 @@
 .qemu-riscv64:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-riscv64
+    CONTAINER: debian:13-riscv64
     LOGFILE: qemu-smoke-riscv64.log
   artifacts:
     paths:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 01:15:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 01:15:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121157.1465630 (Exim 4.92)
	(envelope-from )
	id 1uwsO4-0007p3-9y; Fri, 12 Sep 2025 01:15:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121157.1465630; Fri, 12 Sep 2025 01:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwsO4-0007op-4u; Fri, 12 Sep 2025 01:15:40 +0000
Received: by outflank-mailman (input) for mailman id 1121157;
 Fri, 12 Sep 2025 01:15:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwsO2-0007oj-TB
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 01:15:38 +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 fd3dc6b3-8f75-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 03:15:37 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-45de1084868so6185355e9.2
 for ; Thu, 11 Sep 2025 18:15:37 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e016b5a16sm45827245e9.12.2025.09.11.18.15.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Sep 2025 18:15: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: fd3dc6b3-8f75-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757639736; x=1758244536; darn=lists.xenproject.org;
        h=content-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=9yPQP1AiZ6MAimirV8m1kgaZtgS1jLjq17yJsft7IsE=;
        b=tR3V/War5/2hhpv4VdSlOld/qzfUQl0imMazq9vqJe/GnayYt0awBGsvlHSejry2yk
         NxZrEFj8ng+CL4jRWGCFqfPFqzcRdNZOGMlppHH3CMIc8Uka3mzR2QkxmG0IRnccb5o2
         xTf717XJybf/e3VTvV036uz84S5+P0KXyBsu4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757639736; x=1758244536;
        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=9yPQP1AiZ6MAimirV8m1kgaZtgS1jLjq17yJsft7IsE=;
        b=KrsQU1Udp/hr7fW3mSvZdEK5xn/HpUGKxkd6Yc9s8QvpPtclMvbd5BoGsV2dreOeNP
         v6cxzYhUEiUY6nOTwu9jmN0Yyb3rJsNot/JYufQbvQ3DSkFhVOgjrD9NWpXo7Nr0RZNA
         1zhug99nmMUWd9Ojufydc8qke9kRDAXCl093B2A59mLwXlAG4aoIYeyd43J3TjSEotoN
         dF48R6oHXCEsnDlJKbevLMEQWc4+tlsG7jj42/7r5pbTllz/xcWobm5TQa77yIPgnwmk
         yueg9q7xIbvamd6YujJX4DCCf+g7k9+/4jUNDjAM4wj8mrsug5l2YLua5wxJcBny/Vv+
         maiQ==
X-Gm-Message-State: AOJu0Yx2Q1tnUvC0h0IGDsnf7A9JFGGHozH4fMFuByTszBiB2Ip26a5v
	MOswuNqRzFQy3ezqmxtmGwneCneOVMyhHnHqKbAfBSi3gH3+CcQleNWPKwmMyeraQVZxPEmVgX7
	HsZf0
X-Gm-Gg: ASbGncvxlvTMRH/geofjNZjOxmKvJakbSqUAyXMUU9VbmLSnA+ctO+ACOSnrlEmUud0
	Nh8U2ZOY+m+8ZrM1DvDkwN3torH7NHp18hWfZQOi6ixH7s3trU62WdwKltw+bP/pDKZQwVztmss
	ZQqIcYlEXyrAZU36KZltver5kVOMeP0DibbHazn1B4WS2i2/blia3E7JFpOO/GrF6gNZp/m2kOF
	9j3VcR2rBOHTwRTbbGS9df2AphRxQmpSUgYgXiMB1MQHuQdAOvB9MnJKIzB2emwpixSfu1bnT/2
	BhN8TNCZx6PUr6U7Q0x4LzqAECBiNAIScHFnSoNlNOPcSuJk4t7Nq0I2kNJtJ/9Pd2dkwF2dncr
	LrieFQveqni2AsxP0t2LEYFengYuLSfs7U0Z0dkyLdGM6YepaOnVQoOghMTUVTB773nCrjWaa7N
	Ij9EfdKkonDDY=
X-Google-Smtp-Source: AGHT+IG9HHGIndgHY/tm/TceKBExZ0scjb6hvqpU+eCOivtwqyDdIXlG2ig0tHpVFlkCLJtISFnw2A==
X-Received: by 2002:a05:600c:1911:b0:459:d5d1:d602 with SMTP id 5b1f17b1804b1-45f211c8371mr9833845e9.3.1757639736369;
        Thu, 11 Sep 2025 18:15:36 -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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira ,
	Denis Mukhin 
Subject: [PATCH v3 3.5/5] CI: Make qemu-smoke-x86-64-gcc-efi compatible with Debian Trixie
Date: Fri, 12 Sep 2025 02:15:34 +0100
Message-Id: <20250912011534.1889763-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The OVMF package in Debian Trixie has _4M suffixes on the files.  Have
scripts/include/xtf-x86-64-efi check for this before falling back to no
suffix.

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: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 
CC: Denis Mukhin 

v3.5
 * New

Speculative testing in progress:
  https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2035561867
---
 automation/scripts/include/xtf-x86-64-efi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/automation/scripts/include/xtf-x86-64-efi b/automation/scripts/include/xtf-x86-64-efi
index e0d821b3f6fd..ea5f208e8cb3 100644
--- a/automation/scripts/include/xtf-x86-64-efi
+++ b/automation/scripts/include/xtf-x86-64-efi
@@ -20,6 +20,7 @@ function xtf_arch_setup()
 {
     local esp_dir="${WORKDIR}/boot-esp"
     local efi_dir="${esp_dir}/EFI/BOOT"
+    local suff=
 
     # Generate EFI boot environment
     mkdir -p ${efi_dir}
@@ -35,8 +36,13 @@ options=${XEN_CMDLINE}
 kernel=kernel
 EOF
 
+    # Vs older versions, Debian Trixie names the OVMF files with a _4M suffix.
+    if [[ -e ${FW_PREFIX}/OVMF_VARS_4M.fd ]]; then
+        suff=_4M
+    fi
+
     # NB: OVMF_CODE.fd is read-only, no need to copy
-    cp ${FW_PREFIX}OVMF_VARS.fd ${WORKDIR}
+    cp ${FW_PREFIX}OVMF_VARS${suff}.fd ${WORKDIR}
 
     export TEST_CMD="${QEMU_PREFIX}qemu-system-x86_64 \
         -no-reboot \
@@ -45,7 +51,7 @@ EOF
         -serial stdio \
         -m 512 \
         -M q35,kernel-irqchip=split \
-        -drive if=pflash,format=raw,readonly=on,file=${FW_PREFIX}OVMF_CODE.fd \
+        -drive if=pflash,format=raw,readonly=on,file=${FW_PREFIX}OVMF_CODE${suff}.fd \
         -drive if=pflash,format=raw,file=${WORKDIR}/OVMF_VARS.fd \
         -drive file=fat:rw:${esp_dir},media=disk,index=0,format=raw \
     "
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 02:36:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 02:36:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121211.1465640 (Exim 4.92)
	(envelope-from )
	id 1uwte5-00010B-0D; Fri, 12 Sep 2025 02:36:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121211.1465640; Fri, 12 Sep 2025 02: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 1uwte4-000104-Tz; Fri, 12 Sep 2025 02:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1121211;
 Fri, 12 Sep 2025 02:36:15 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwte3-0000zy-Jg
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 02:36:15 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwte2-006Gs0-2z;
 Fri, 12 Sep 2025 02:36:14 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwte2-0054fq-2H;
 Fri, 12 Sep 2025 02:36: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=24T8MpKarVXiuYct/e/CYDD298o/Xba9qUJZu1cUHxo=; b=mpOwiVrtqOSy7n3K/2y0R22x6p
	UXUYLuU8nBNUcxOHETzEcop1k4EZQ5DC26JlVeP5wtneT/1+EaE1YkgoHFBsNSTwA3KZy4NWY2Grg
	GdZ+JxSNZk0WGOEJTy2oDHY1k61CN+9Vmab2bCFn5THWKhQHBKaqzK6bH6ho1zq5z24A=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 19:36:13 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Victor Lira 
Subject: Re: [PATCH v3 1/5] CI: Use the Debian Trixie container for RISC-V
 test jobs
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250911231216.1886818-2-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250911231216.1886818-2-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 12:12:12AM +0100, Andrew Cooper wrote:
> This was missed when introducing Trixie.
> 
> Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  

> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn 
> CC: Stefano Stabellini 
> CC: Shawn Anastasio 
> CC: Oleksii Kurochko 
> CC: Doug Goldstein 
> CC: Marek Marczykowski-Grecki 
> CC: Victor Lira 
> 
> v3:
>  * New
> ---
>  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 95b883b32bb6..1de68a0fe450 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -77,7 +77,7 @@
>  .qemu-riscv64:
>    extends: .test-jobs-common
>    variables:
> -    CONTAINER: debian:12-riscv64
> +    CONTAINER: debian:13-riscv64
>      LOGFILE: qemu-smoke-riscv64.log
>    artifacts:
>      paths:
> -- 
> 2.39.5
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 02:37:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 02:37:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121221.1465650 (Exim 4.92)
	(envelope-from )
	id 1uwtew-0001T9-8B; Fri, 12 Sep 2025 02:37:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121221.1465650; Fri, 12 Sep 2025 02: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 1uwtew-0001T2-5d; Fri, 12 Sep 2025 02:37:10 +0000
Received: by outflank-mailman (input) for mailman id 1121221;
 Fri, 12 Sep 2025 02:37:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwteu-0001Ri-QI
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 02:37:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwteu-006Gsu-0U;
 Fri, 12 Sep 2025 02:37:08 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwteu-0054iV-0K;
 Fri, 12 Sep 2025 02:37: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=9W46cm0OnctGte1ilrRzPSK+LoIyzufbhxk4SxDx6G8=; b=1y0YUny45J/V4y+6ADbRHkssZ0
	tw9RUI+V9OPE992NRI1/SwbKTUBTKThTFRExjBqKAy7fEhNnALCYrUuekVRbKD6G55szGLjnz5ZGJ
	ghi79VEfZ/LLI5DcP6ffF633OeZGOpjIVOG92HfkpRIBAwT/Y5CPPWYMh0tTUh1RJ6ps=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 19:37:07 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Victor Lira 
Subject: Re: [PATCH v3 3/5] CI: Merge categories in
 debian/12-x86_64.dockerfile
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250911231216.1886818-4-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250911231216.1886818-4-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 12:12:14AM +0100, Andrew Cooper wrote:
> cpio needs to be in Tools (general) now that it's used by the general build
> script.  Merge the rest of the test phase jobs into one group, to avoid being
> overly fine-grain.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  

> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn 
> CC: Stefano Stabellini 
> CC: Shawn Anastasio 
> CC: Oleksii Kurochko 
> CC: Doug Goldstein 
> CC: Marek Marczykowski-Grecki 
> CC: Victor Lira 
> 
> Prep for making a Debian Trixie derivative.
> 
> v3:
>  * New
> ---
>  automation/build/debian/12-x86_64.dockerfile | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/automation/build/debian/12-x86_64.dockerfile b/automation/build/debian/12-x86_64.dockerfile
> index 3cf99c730b61..4e533ee879fd 100644
> --- a/automation/build/debian/12-x86_64.dockerfile
> +++ b/automation/build/debian/12-x86_64.dockerfile
> @@ -23,6 +23,7 @@ RUN <  
>          # Tools (general)
>          ca-certificates
> +        cpio
>          git-core
>          pkg-config
>          wget
> @@ -52,19 +53,14 @@ RUN <          ocaml-nox
>          ocaml-findlib
>  
> -        # for test phase, qemu-smoke-* jobs
> +        # for test phase, qemu-* jobs
> +        busybox-static
>          expect
> +        ovmf
>          qemu-system-x86
>  
>          # for build-each-commit-gcc
>          ccache
> -
> -        # for qemu-alpine-x86_64-gcc
> -        busybox-static
> -        cpio
> -
> -        # For *-efi jobs
> -        ovmf
>      )
>  
>      apt-get -y --no-install-recommends install "${DEPS[@]}"
> -- 
> 2.39.5
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 02:39:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 02:39:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121245.1465659 (Exim 4.92)
	(envelope-from )
	id 1uwtgm-00024u-IV; Fri, 12 Sep 2025 02:39:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121245.1465659; Fri, 12 Sep 2025 02:39: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 1uwtgm-00024n-FW; Fri, 12 Sep 2025 02:39:04 +0000
Received: by outflank-mailman (input) for mailman id 1121245;
 Fri, 12 Sep 2025 02:39:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwtgl-00024h-61
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 02:39:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwtgk-006Gwm-0w;
 Fri, 12 Sep 2025 02:39:02 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwtgj-0054nR-2m;
 Fri, 12 Sep 2025 02:39: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=3OWwJLVIUalsdUjtKNKCYLLkIz6YThMLa6KQ83aeI2c=; b=
	uK8InW5N9tFpyWHhrbir0yrkZVaRk8Vh9Cs7MT0kfcyeQG0iFSh/qCgpe7ZWQMoIppzkxkI4aeIuZ
	rbrl14wppeg/EGtwhd41K3ZDcuSrrSbQCVd6b0/uK3rEobga0Eds9IDMJFt5AnAIC+luU1r7YXPOk
	zdjYryfZvlwBBR1JU=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 19:39:00 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Victor Lira , Denis Mukhin 
Subject: Re: [PATCH v3 3.5/5] CI: Make qemu-smoke-x86-64-gcc-efi compatible
 with Debian Trixie
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250912011534.1889763-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250912011534.1889763-1-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 02:15:34AM +0100, Andrew Cooper wrote:
> The OVMF package in Debian Trixie has _4M suffixes on the files.  Have
> scripts/include/xtf-x86-64-efi check for this before falling back to no
> suffix.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 02:40:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 02:40:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121258.1465669 (Exim 4.92)
	(envelope-from )
	id 1uwtht-0003We-Re; Fri, 12 Sep 2025 02:40:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121258.1465669; Fri, 12 Sep 2025 02: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 1uwtht-0003WX-P3; Fri, 12 Sep 2025 02:40:13 +0000
Received: by outflank-mailman (input) for mailman id 1121258;
 Fri, 12 Sep 2025 02:40:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwths-0003WG-07
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 02:40:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwthr-006Gxi-1J;
 Fri, 12 Sep 2025 02:40:11 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwthr-0054vT-1D;
 Fri, 12 Sep 2025 02:40:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=B3Ua5zvzVHSBNvwnmIN1U4E9wHiXXsPFNfjwrPHrMFo=; b=
	DAwE/sh0D8TjB0M0tOnLonhr0rex3ncY5hshKvyMUe0/6Xb9WP9128IxQY2Kqio37OLN+OS0EeLPz
	pPXQqUncIaSb/6C2SZk7MXN3Vc9xi1Qf+eum9ZVyqSdJOiNQVc5ICEJbO9RDOkztseKxoaagcACHP
	JOleR9HIcpBJPA2cU=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 19:40:10 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Victor Lira 
Subject: Re: [PATCH v3 3/5] CI: Merge categories in
 debian/12-x86_64.dockerfile
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250911231216.1886818-4-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250911231216.1886818-4-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 12:12:14AM +0100, Andrew Cooper wrote:
> cpio needs to be in Tools (general) now that it's used by the general build
> script.  Merge the rest of the test phase jobs into one group, to avoid being
> overly fine-grain.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 02:41:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 02:41:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121269.1465680 (Exim 4.92)
	(envelope-from )
	id 1uwtj3-00042z-4h; Fri, 12 Sep 2025 02:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121269.1465680; Fri, 12 Sep 2025 02: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 1uwtj3-00042s-21; Fri, 12 Sep 2025 02:41:25 +0000
Received: by outflank-mailman (input) for mailman id 1121269;
 Fri, 12 Sep 2025 02:41:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwtj2-00042J-5u
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 02:41:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwtj1-006Gyr-2o;
 Fri, 12 Sep 2025 02:41:23 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwtj1-00556J-2k;
 Fri, 12 Sep 2025 02:41: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=XkovJnvqB+4UBBkHkUhrOHgvkoti+hw9OZjVaGMk/JE=; b=yUUO/s2VzG4Lt3RnTnJbfDIk8U
	nzecdCcfv40mA29iN/mILZSp4kzffN4dLctK0uUiTzh1V4s6hTGjbOG9UTUjJsgd2oMa/LQewqB+z
	j1flwHIsWfp7qlOECDN2MxlW+1VuK025GtZyPbMx0F8zvwnBqQOfDNL/s1GiRGGOOylo=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 19:41:22 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Oleksii Kurochko ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 5/5] CHANGELOG: Notes about distro changes in CI
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250911231216.1886818-6-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250911231216.1886818-6-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 12:12:16AM +0100, Andrew Cooper wrote:
> Also state the RISC-V baseline now it's been set, as it's the reason why
> RISC-V Bullseye got dropped.
> 
> Signed-off-by: Andrew Cooper 
> Acked-by: Oleksii Kurochko 

Reviewed-by: Denis Mukhin  

> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn 
> CC: Stefano Stabellini 
> CC: Oleksii Kurochko 
> 
> v2:
>  * New
> ---
>  CHANGELOG.md | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 7bd96ac09d14..ca1b43b940d2 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -10,6 +10,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   - The minimum toolchain requirements have increased for some architectures:
>     - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
>     - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
> +   - For RISC-V, GCC 12.2 and Binutils 2.39
> + - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
> +   to the baseline change.
>   - Linux based device model stubdomains are now fully supported.
>  
>   - On x86:
> -- 
> 2.39.5
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 02:50:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 02:50:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121287.1465690 (Exim 4.92)
	(envelope-from )
	id 1uwtra-0005nw-UU; Fri, 12 Sep 2025 02:50:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121287.1465690; Fri, 12 Sep 2025 02: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 1uwtra-0005np-Qr; Fri, 12 Sep 2025 02:50:14 +0000
Received: by outflank-mailman (input) for mailman id 1121287;
 Fri, 12 Sep 2025 02:50:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwtrZ-0005nj-Nk
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 02:50:13 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwtrZ-006H9o-0o;
 Fri, 12 Sep 2025 02:50:13 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwtrZ-0055j0-0N;
 Fri, 12 Sep 2025 02:50: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=r3CAyZzIsfX0fntwAuWviWcep0O0mq7yxuSuY1bv1RY=; b=
	0jc0eVcvHHSIRp820vhiOVsrYNaj0TCSIGikL5G58Tjnhsf+AcbeZOm4oL84sQVCYAA1BDhbluyzv
	qYFqR3e1mk/ohK6TgnioSUKaXX8FMaLNWb0W0cnkVMkFbTqMqMJavYu5veYmsavOSVSIjAgKy/Nq+
	tniIDpdOgSXYLhwZA=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 19:50:11 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Victor Lira 
Subject: Re: [PATCH v3 4/5] CI: Update x86 to use Debian Trixie
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250911231216.1886818-5-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250911231216.1886818-5-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 12:12:15AM +0100, Andrew Cooper wrote:
> With the exception of the custom IBT job, copy all Debian 12 jobs making
> Debian 13 versions, then trim the Debian 12 ranconfig jobs.
> 
> Update the test jobs using Debian 12 to use 13.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 03:39:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 03:39:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121311.1465699 (Exim 4.92)
	(envelope-from )
	id 1uwucv-0002jO-9X; Fri, 12 Sep 2025 03:39:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121311.1465699; Fri, 12 Sep 2025 03: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 1uwucv-0002jH-6t; Fri, 12 Sep 2025 03:39:09 +0000
Received: by outflank-mailman (input) for mailman id 1121311;
 Fri, 12 Sep 2025 03:39:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uwucu-0002jB-KH
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 03:39:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uwuct-006IAz-2i;
 Fri, 12 Sep 2025 03:39:07 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uwuct-0057xy-1N;
 Fri, 12 Sep 2025 03:39: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=sH5Gn8ooqsoB7E2IVqamcCixZIn8HYym1LTUM0WeTCs=; b=
	fj6RJ+3TaXoEXcqkLORtYO8ZHBriCNRlhDoiyFpTz+WcSrDKa6PKcHtmoTw9/5yALrWAyOZD+Vd1R
	WbFOefrTgyP2rjxEppESm5FcKL9LwcwEuf7eNaiZV0pD0nWdItYLGj6JQ4k7W2IUTB+8e5t/7K8GJ
	iNNfM+CtV7vAXpwb4=;
From: dmukhin@xen.org
Date: Thu, 11 Sep 2025 20:39:06 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Victor Lira 
Subject: Re: [PATCH v3 2/5] CI: Update ppc64 to use Debian Trixie
Message-ID: 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250911231216.1886818-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250911231216.1886818-3-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 12:12:13AM +0100, Andrew Cooper wrote:
> Everything works fine with Debian 13.  Provide two new build jobs (for a total
> of 6), and update the test jobs.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 04:53:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 04:53:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121387.1465710 (Exim 4.92)
	(envelope-from )
	id 1uwvmi-0003m5-G4; Fri, 12 Sep 2025 04:53:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121387.1465710; Fri, 12 Sep 2025 04:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwvmi-0003ly-D8; Fri, 12 Sep 2025 04:53:20 +0000
Received: by outflank-mailman (input) for mailman id 1121387;
 Fri, 12 Sep 2025 04:53: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 1uwvmh-0003lq-A6
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 04:53:19 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2405::61f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 648bdeaf-8f94-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 06:53:17 +0200 (CEST)
Received: from CH2PR05CA0049.namprd05.prod.outlook.com (2603:10b6:610:38::26)
 by SA3PR12MB7904.namprd12.prod.outlook.com (2603:10b6:806:320::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Fri, 12 Sep
 2025 04:53:11 +0000
Received: from DS3PEPF000099D5.namprd04.prod.outlook.com
 (2603:10b6:610:38:cafe::a7) by CH2PR05CA0049.outlook.office365.com
 (2603:10b6:610:38::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.7 via Frontend Transport; Fri,
 12 Sep 2025 04:53:10 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS3PEPF000099D5.mail.protection.outlook.com (10.167.17.6) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Fri, 12 Sep 2025 04:53:10 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Thu, 11 Sep 2025 21:53:07 -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: 648bdeaf-8f94-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QWoLnkR+FZstMDl918V9MsD0ZOwh8btE3NJ554DF4afp+Yz0AGhnZBr+AvsPvdYpPYv9R8ZIshzF9SHkhAb8k5u6VGpXPncVnfdN59WN2YWr4tX455OfBa5jGbfP39VyG3q/uxkgSm8fGxFKT8X0lWmEnrnc8k5ZhEqP5GcJQH8MgDwq74wj14ZwuxBJVi21j5nVXQUL9gIRozaxWvkP1dD+DOSJOqeSTitjFAa6wYaVxXWXRh9j6Z6wEvOqoZ9kOcjTLf9yehWwD89g/EEAp6mh7z5fCUy3t/6n+BcyFinGZ+tJKPUMXEcrwQQaqHo5RX3wpBVpcId7ocQMVxphvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qS4zBvwuCK+Oq5V6/9fIKJDP99q1GGCdKKoXl0OBYLg=;
 b=QovQPx9MK7WLo6xJ7PALUspiElxO9U1mmQo4Ne1eEdDQr/EJ+ihULhKzCEqaOiMrUSBXPWBU3JXP/KfS2S/T20WKkLKjx00TqLqDu5cMgqxp4Pwr/EJn5S88gykOVyHxMxC9tJXwFTIX43PxxQ0mxGQSshIqqwvcmD+0TBtUEKIgTBOAjlqdZkAhH0YWM3s5nTSmaspqgKuavarW6Wi4lqf7pU7cZqHLWwLgnEwKKf4+7wNrj7vogSFrqP3s7phNKmoGFUoz0b0FpIJmOSRghnMnSoFmXd/gfrfiJ9/jUffK5I3J5aV3klIAo/K51w6NBIssequMLCSLH6TlCLTF+g==
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=qS4zBvwuCK+Oq5V6/9fIKJDP99q1GGCdKKoXl0OBYLg=;
 b=gfN436iSI4ePrQLG8MpQXxWwdf+ZRnRXK+bIEnLmpbkYEuF8Nu5Sh1yFt2Y3quD+1XOzjBOZekxofQgAjHzGup2poojU3ZDzW0Hx8UIef6yOQFqhPUQWJwREToj+0FuzrrjZR1smZQTmu+FbCiDpJPCPIMfbkX4spzwEazy1JA0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Tamas K Lengyel
	, Alexandru Isaila , "Petre
 Pircalabu" 
Subject: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
Date: Fri, 12 Sep 2025 12:52:54 +0800
Message-ID: <20250912045254.3731398-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099D5:EE_|SA3PR12MB7904:EE_
X-MS-Office365-Filtering-Correlation-Id: 99349b40-5060-4293-8b9d-08ddf1b845e0
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?4PI4yEFzxupo2PCM6TIwSTc2hBLk35v3gkdlKkqamzkoX/wc8g1kYWsVWWnd?=
 =?us-ascii?Q?oJ/IJSd+H0VQB2as0ckHCFGU2F/kcXv2xaXiXhPPG47J62GFQZo1kK6qWadC?=
 =?us-ascii?Q?gIDv7wxjtM5lDKcc1fhLJ/y0KsgnRw8qw36zEk9AjSBDOCtCv23iD9Bs8uRl?=
 =?us-ascii?Q?14J3lrs48kvr7oOIHaCL695h+eYhi0ESkef8YSAIDlT/kjdRkjMcq6YAPdpJ?=
 =?us-ascii?Q?UrqRTNZoXppxM12TXYpWrEOP75sguzLY7CGy6g6+h1KuLj6dNJAnjZaw1MxW?=
 =?us-ascii?Q?FekOeMw5UY4wFEeWbS16i6TlKtzyB/9EmwGfVN4U4vYw9h2n/fXKKqNcJj3E?=
 =?us-ascii?Q?ur3lpqT3VeU0VtRpVB8Qvd/vV5vkaMvvaia2791uQAOFUFsFcwi/pi1alhhN?=
 =?us-ascii?Q?SASQIoWXb4vuYIBwOsACOM3RAkN7L7PVYezXo2TEu42hnsUVkphosHd4ZQQ/?=
 =?us-ascii?Q?Q9EBUTVCbO1oAPtsdJLm92hnCqjntSeI2J1r/zN8pcm7A19ALCQsSmcc0xa9?=
 =?us-ascii?Q?7k29+62+ZdfvXByeNbwgmtZIT/jqnG/mQdETX62aDxmEgd+f5togpQcaaSQp?=
 =?us-ascii?Q?oJd2hwtWZjRbp2Y/WDtwZcuescpIggzOjiPRMO/OxG1WkW71TnL0U6lqcjuL?=
 =?us-ascii?Q?Cgoh26xbOFsKQoAOvW+HL3QNMxKduRyeNGCbJzO6sNLCaFIBEL6YBFqj2llO?=
 =?us-ascii?Q?fTT5drC1Mo1uIqSXXLY3QGYqV5HJNzpjm/sVLJYaBHFgrAymeXIoIETCpjH/?=
 =?us-ascii?Q?VXhnNPAoB6juH0U3OB5lN+xf+J6UwE+DUt6gWzPTiMqRIhBM8NNSR/Arpj3p?=
 =?us-ascii?Q?RLuUVPvesm3RUKGP2zIqCqeRc1xGSYJoUnBx4r0Hl5AaswZjAK9eM8G79b08?=
 =?us-ascii?Q?HG8nQ3woBWUTFGGFgGrSl2mKKPSSRINyxiUqzwuvQ1NRvq4rLad986PHj/nE?=
 =?us-ascii?Q?DadInz5PvRzV6r8Z5gGxpxDs53BkrIjpdnSloZVUi9FT5qYQBt8TF8mI09wP?=
 =?us-ascii?Q?vo2PhGd/r7Q+0J/wGbC0xzHWzNeHZyyHeqzIdc6JQXFXZtDn6Q8XFmaF50+x?=
 =?us-ascii?Q?yJcurbzNu+/dFqkrhlPMDLsdSYOvpMCnj0rqIDLaH45KcEKhYmTJrbJKV3q/?=
 =?us-ascii?Q?XQEqwr52Wq1AG30lCXf9PEgfUZ/KMwe9DYZvxs0BUiL/d1gJVTBuJvdzLg7L?=
 =?us-ascii?Q?kws/s1ef02HcCnCCvfUWIBAbyaduOAKJhyFCsgCCyq/Acs0A3hPQOAmuicFU?=
 =?us-ascii?Q?GhH3rvg0BV14TWCncyR2mp9rVgywqL2vuxRsHXfTCAxfaRR00eZ3NJQcVFQm?=
 =?us-ascii?Q?qLZ+yqs0ckMIBigyb6y7TztdEDbX/u9JXvjevp+XI22Opfn1x+Z/FgcfIW59?=
 =?us-ascii?Q?2sWC6C3ugQB8C2Yhd2Lkqp34p83dU7iVTibFa25ANP42fjwOgaQVVx866jwU?=
 =?us-ascii?Q?kUKnJtTkhzJLzCa5iVmbLh4ARisVyP5kl3P0pRi6qa6ElCsukCqOYn6y3PYk?=
 =?us-ascii?Q?J+ywZKhwsqhceRoY3WfxzEfPB3SsSn0IM1T8?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 12 Sep 2025 04:53:10.4359
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 99349b40-5060-4293-8b9d-08ddf1b845e0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099D5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7904

Function vm_event_is_enabled() is introduced to check if vm event is enabled,
and also make the checking conditional upon CONFIG_VM_EVENT, which could help
DCE a lot calls/codes, such as hvm_monitor_io(), etc when VM_EVENT=n.
In-place assertion of arch.vm_event is kinds of redundant and could be
removed.

Signed-off-by: Penny Zheng 
---
 xen/arch/x86/hvm/emulate.c          |  6 ++---
 xen/arch/x86/hvm/hvm.c              | 41 +++++++++++++----------------
 xen/arch/x86/hvm/svm/intr.c         |  2 +-
 xen/arch/x86/hvm/vmx/intr.c         |  2 +-
 xen/arch/x86/include/asm/vm_event.h |  9 +++++++
 5 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 2af4f30359..75567db403 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -105,7 +105,7 @@ static int set_context_data(void *buffer, unsigned int size)
 {
     struct vcpu *curr = current;
 
-    if ( curr->arch.vm_event )
+    if ( vm_event_is_enabled(curr) )
     {
         unsigned int safe_size =
             min(size, curr->arch.vm_event->emul.read.size);
@@ -771,7 +771,7 @@ static void *hvmemul_map_linear_addr(
             ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
         }
 
-        if ( unlikely(curr->arch.vm_event) &&
+        if ( unlikely(vm_event_is_enabled(curr)) &&
              curr->arch.vm_event->send_event &&
              hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
         {
@@ -1870,7 +1870,7 @@ static int hvmemul_rep_outs_set_context(
     int rc = X86EMUL_OKAY;
 
     ASSERT(bytes_per_rep <= 4);
-    if ( !ev )
+    if ( !vm_event_is_enabled(current) )
         return X86EMUL_UNHANDLEABLE;
 
     ptr = ev->emul.read.data;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a..e3abd2849a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -532,7 +532,7 @@ void hvm_do_resume(struct vcpu *v)
     if ( !vcpu_ioreq_handle_completion(v) )
         return;
 
-    if ( unlikely(v->arch.vm_event) )
+    if ( unlikely(vm_event_is_enabled(v)) )
         hvm_vm_event_do_resume(v);
 
     /* Inject pending hw/sw event */
@@ -546,11 +546,12 @@ void hvm_do_resume(struct vcpu *v)
         v->arch.hvm.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
     }
 
-    if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled )
+    if ( unlikely(vm_event_is_enabled(v)) &&
+         v->arch.monitor.next_interrupt_enabled )
     {
         struct x86_event info;
 
-        if ( hvm_get_pending_event(v, &info) )
+        if ( hvm_get_pending_event(v, &info) && vm_event_is_enabled(v) )
         {
             hvm_monitor_interrupt(info.vector, info.type, info.error_code,
                                   info.cr2);
@@ -2088,7 +2089,7 @@ int hvm_handle_xsetbv(u32 index, u64 new_bv)
 {
     int rc;
 
-    if ( index == 0 )
+    if ( index == 0 && vm_event_is_enabled(current) )
         hvm_monitor_crX(XCR0, new_bv, current->arch.xcr0);
 
     rc = x86emul_write_xcr(index, new_bv, NULL);
@@ -2337,9 +2338,7 @@ int hvm_set_cr0(unsigned long value, bool may_defer)
     if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
                                monitor_ctrlreg_bitmask(VM_EVENT_X86_CR0)) )
     {
-        ASSERT(v->arch.vm_event);
-
-        if ( hvm_monitor_crX(CR0, value, old_value) )
+        if ( vm_event_is_enabled(v) && hvm_monitor_crX(CR0, value, old_value) )
         {
             /* The actual write will occur in hvm_do_resume(), if permitted. */
             v->arch.vm_event->write_data.do_write.cr0 = 1;
@@ -2462,9 +2461,8 @@ int hvm_set_cr3(unsigned long value, bool noflush, bool may_defer)
     if ( may_defer && unlikely(currd->arch.monitor.write_ctrlreg_enabled &
                                monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
     {
-        ASSERT(curr->arch.vm_event);
-
-        if ( hvm_monitor_crX(CR3, value, curr->arch.hvm.guest_cr[3]) )
+        if ( vm_event_is_enabled(curr) &&
+             hvm_monitor_crX(CR3, value, curr->arch.hvm.guest_cr[3]) )
         {
             /* The actual write will occur in hvm_do_resume(), if permitted. */
             curr->arch.vm_event->write_data.do_write.cr3 = 1;
@@ -2544,9 +2542,7 @@ int hvm_set_cr4(unsigned long value, bool may_defer)
     if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
                                monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4)) )
     {
-        ASSERT(v->arch.vm_event);
-
-        if ( hvm_monitor_crX(CR4, value, old_cr) )
+        if ( vm_event_is_enabled(v) && hvm_monitor_crX(CR4, value, old_cr) )
         {
             /* The actual write will occur in hvm_do_resume(), if permitted. */
             v->arch.vm_event->write_data.do_write.cr4 = 1;
@@ -3407,7 +3403,7 @@ static enum hvm_translation_result __hvm_copy(
             return HVMTRANS_bad_gfn_to_mfn;
         }
 
-        if ( unlikely(v->arch.vm_event) &&
+        if ( unlikely(vm_event_is_enabled(v)) &&
              (flags & HVMCOPY_linear) &&
              v->arch.vm_event->send_event &&
              hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
@@ -3538,6 +3534,7 @@ int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len)
     struct vcpu *curr = current;
     unsigned int leaf = regs->eax, subleaf = regs->ecx;
     struct cpuid_leaf res;
+    int ret = 0;
 
     if ( curr->arch.msrs->misc_features_enables.cpuid_faulting &&
          hvm_get_cpl(curr) > 0 )
@@ -3554,7 +3551,10 @@ int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len)
     regs->rcx = res.c;
     regs->rdx = res.d;
 
-    return hvm_monitor_cpuid(inst_len, leaf, subleaf);
+    if ( vm_event_is_enabled(curr) )
+        ret = hvm_monitor_cpuid(inst_len, leaf, subleaf);
+
+    return ret;
 }
 
 void hvm_rdtsc_intercept(struct cpu_user_regs *regs)
@@ -3694,9 +3694,8 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content,
         if ( ret != X86EMUL_OKAY )
             return ret;
 
-        ASSERT(v->arch.vm_event);
-
-        if ( hvm_monitor_msr(msr, msr_content, msr_old_content) )
+        if ( vm_event_is_enabled(v) &&
+             hvm_monitor_msr(msr, msr_content, msr_old_content) )
         {
             /* The actual write will occur in hvm_do_resume(), if permitted. */
             v->arch.vm_event->write_data.do_write.msr = 1;
@@ -3854,12 +3853,10 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
     struct vcpu *curr = current;
     struct domain *currd = curr->domain;
 
-    if ( currd->arch.monitor.descriptor_access_enabled )
-    {
-        ASSERT(curr->arch.vm_event);
+    if ( currd->arch.monitor.descriptor_access_enabled &&
+         vm_event_is_enabled(curr) )
         hvm_monitor_descriptor_access(exit_info, vmx_exit_qualification,
                                       descriptor, is_write);
-    }
     else if ( !hvm_emulate_one_insn(is_sysdesc_access, "sysdesc access") )
         domain_crash(currd);
 
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index 46186a1102..557ebc98d8 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -130,7 +130,7 @@ void asmlinkage svm_intr_assist(void)
     enum hvm_intblk intblk;
 
     /* Block event injection while handling a sync vm_event. */
-    if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
+    if ( unlikely(vm_event_is_enabled(v)) && v->arch.vm_event->sync_event )
         return;
 
     /* Crank the handle on interrupt state. */
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index b35dc8c586..a8ced95871 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -239,7 +239,7 @@ void asmlinkage vmx_intr_assist(void)
     }
 
     /* Block event injection while handling a sync vm_event. */
-    if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
+    if ( unlikely(vm_event_is_enabled(v)) && v->arch.vm_event->sync_event )
         return;
 
 #ifdef CONFIG_MEM_SHARING
diff --git a/xen/arch/x86/include/asm/vm_event.h b/xen/arch/x86/include/asm/vm_event.h
index 46e77ed6d9..446d02c7d5 100644
--- a/xen/arch/x86/include/asm/vm_event.h
+++ b/xen/arch/x86/include/asm/vm_event.h
@@ -45,4 +45,13 @@ void vm_event_sync_event(struct vcpu *v, bool value);
 
 void vm_event_reset_vmtrace(struct vcpu *v);
 
+static inline bool vm_event_is_enabled(struct vcpu *v)
+{
+#ifdef CONFIG_VM_EVENT
+    return v->arch.vm_event != NULL;
+#else
+    return false;
+#endif
+}
+
 #endif /* __ASM_X86_VM_EVENT_H__ */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 06:15:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 06:15:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121413.1465719 (Exim 4.92)
	(envelope-from )
	id 1uwx3x-0005Fz-6D; Fri, 12 Sep 2025 06:15:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121413.1465719; Fri, 12 Sep 2025 06:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwx3x-0005Fs-3J; Fri, 12 Sep 2025 06:15:13 +0000
Received: by outflank-mailman (input) for mailman id 1121413;
 Fri, 12 Sep 2025 06:15: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 1uwx3v-0005Fg-Tb
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 06:15:11 +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 d3bb4c14-8f9f-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 08:15:06 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-61cc281171cso2814489a12.0
 for ; Thu, 11 Sep 2025 23:15: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
 4fb4d7f45d1cf-62ee40dcaddsm593605a12.6.2025.09.11.23.15.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 23:15: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: d3bb4c14-8f9f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757657706; x=1758262506; 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=DAnJwl5NhEXX/VJqCboUAA4HpYs7h0yS0lxkLE0K0k0=;
        b=HcV/3W//e62+zijb9qtoAwmECXEic9DoRVPN9njoo9IrKx36vf48ZN6p0+A5dlS540
         znv3ZZ5UF0Xkv/rSbY0SdeBTWk4tvOiaFvtXo4krMBiZP4GTDgLSYZ9WYsVUMJJMCjVc
         58cOnFNvcOrpFJhkTDXZgDPnNOUd64nsQciSCT9FTcjexeS4sE6y/9824Yh3B/0P/Nyd
         7d/e/5gPZKTdISGLbHNoWf2YHxRDSl4DpfiWRrGFFsySAoWj4hXIZ6L4tMowc+sH/tPN
         FoNXn2IjHsTJQxC6E0HsQ6JsbL85A6D7XwtUYm7PbW97LWh28XiKNuie80dKmaN6jDNI
         kshA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757657706; x=1758262506;
        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=DAnJwl5NhEXX/VJqCboUAA4HpYs7h0yS0lxkLE0K0k0=;
        b=czCssqyWs8MCM8JSU54Z/z3MnA5rgU09mKFkTk2vUWp/yAfl0RUUkHE3oJ27dNbxof
         2tSJguNoAR02hdn0siyBnR+t2409ttJZiSHE+CI7lBO4kw1+XYR0J8pHK/dYkuAyXZ+k
         8sweR7L8gpBxHoIt5/iQUQgU6L5yWjBWNk7qHbJoFnSsx/qbNAJFeswz+NgFHUsOrZWT
         Cms/EIPYohUHPYvm9vLoxCcnfWPMrz3xvLAJQ5k+bkFoEhN3tazDFFsaqMeCZotK6Xr0
         sFkuhZrW8kDejCAu4eTQ3BjrZB+dKu3jGwADRhcAawHpHVNknB66cWbH4y/nZDkqrt2R
         NxmQ==
X-Forwarded-Encrypted: i=1; AJvYcCXkMrJbpaJgN4TRMY4C0JpvfGTwrlyuRW1W9/Ym5CIBd9WIwYqWIZE9rn5XWul1M+J0dSEvzatrBPw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzooiKBSxgeVG0x9DNSaZO5GPNNLhoKG4AOZiTnLK2yOVA65Zg4
	o9zNccVRssjKgg2Dli/edOPz2nMlZtn9y7EtdM8ZkDfCrVSH+G3cLVY+500sCkQAbg==
X-Gm-Gg: ASbGncvvoduMEkRfcitKrb08zT/ia2OmMRQTgP+PYEkHLwyTqcwBJDsAAQHaLZVDogQ
	75W4E8ciYC+LB+5ViMs+zcHrxHB64Prn523giM0HdQUz8WAanatwZBMyrBN6foSsowAwbPUGYHc
	lYKdUCTJAy8hazv+aLA4hW/gGI+K99wiaw9nwsQZ6dRq+dEGVOeIrwHRHjOtkyoM58Gg0Y435OC
	5EDjhSNI9WZ0JhbwedeApyIjcHm8aZfG42iT5nJbNyMz/QdHGfoDEwFUkJvxYZ6SQIDIelgpFWJ
	qKu2hBzh/j/EmgH3jUBI/c6uEu7fNCae0aekgbQ76MAjjIIj+/lZtVklVl+9JkOKeVa9mqgmZI/
	U+1+g0nUu3t2HTWqAnhmqzrV/5o4iEFA9FBWaJcmVQ4Wj0i7qtHS1QDdn9v1CIijLGs+bPY/++q
	IsUZvoQxBTE/ZVz+KC2g==
X-Google-Smtp-Source: AGHT+IH3OsodKDruToDkB+VWGVa8UaMjifPGuxzGncTvd82uuwSt70k+GMaRrFIB1RTQ3jlTdNq1Uw==
X-Received: by 2002:a05:6402:35c7:b0:628:b619:49ca with SMTP id 4fb4d7f45d1cf-62ed82fe63amr2079736a12.25.1757657705713;
        Thu, 11 Sep 2025 23:15:05 -0700 (PDT)
Message-ID: <3d0d9653-e96f-4ed7-a6c2-2a082f03b712@suse.com>
Date: Fri, 12 Sep 2025 08:15:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: domU reboot claim failed
To: Jason Andryuk 
References: 
 
 <44207905-ece0-48f1-a7d7-8c30720cb48d@amd.com>
Content-Language: en-US
Cc: Andrew Cooper ,
 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: <44207905-ece0-48f1-a7d7-8c30720cb48d@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.09.2025 23:20, Jason Andryuk wrote:
> Thanks, everyone.
> 
> On 2025-09-10 17:57, Andrew Cooper wrote:
>> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>>> Hi,
>>>
>>> We're running Android as a guest and it's running the Compatibility
>>> Test Suite.  During the CTS, the Android domU is rebooted multiple times.
>>>
>>> In the middle of the CTS, we've seen reboot fail.  xl -vvv shows:
>>> domainbuilder: detail: Could not allocate memory for HVM guest as we
>>> cannot claim memory!
>>> xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't
>>> allocate low memory for domain: Out of memory
>>> libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init
>>> failed: Cannot allocate memory
>>> domainbuilder: detail: xc_dom_release: called
>>>
>>> So the claim failed.  The system has enough memory since we're just
>>> rebooting the same VM.  As a work around, I added sleep(1) + retry,
>>> which works.
>>>
>>> The curious part is the memory allocation.  For d2 to d5, we have:
>>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>> xc: detail:   4KB PAGES: 0x0000000000000000
>>> xc: detail:   2MB PAGES: 0x00000000000006f8
>>> xc: detail:   1GB PAGES: 0x0000000000000003
>>>
>>> But when we have to retry the claim for d6, there are no 1GB pages used:
>>> domainbuilder: detail: range: start=0x0 end=0xf0000000
>>> domainbuilder: detail: range: start=0x100000000 end=0x1af000000
>>> domainbuilder: detail: HVM claim failed! attempt 0
>>> xc: detail: PHYSICAL MEMORY ALLOCATION:
>>> xc: detail:   4KB PAGES: 0x0000000000002800
>>> xc: detail:   2MB PAGES: 0x0000000000000ce4
>>> xc: detail:   1GB PAGES: 0x0000000000000000
>>>
>>> But subsequent reboots for d7 and d8 go back to using 1GB pages.
>>>
>>> Does the change in memory allocation stick out to anyone?
>>>
>>> Unfortunately, I don't have insight into what the failing test is doing.
>>>
>>> Xen doesn't seem set up to track the claim across reboot.  Retrying
>>> the claim works in our scenario since we have a controlled configuration.
>>
>> This looks to me like a known phenomenon.  Ages back, a change was made
>> in how Xen scrubs memory, from being synchronous in domain_kill(), to
>> being asynchronous in the idle loop.
>>
>> The consequence being that, on an idle system, you can shutdown and
>> reboot the domain faster, but on a busy system you end up trying to
>> allocate the new domain while memory from the old domain is still dirty.
>>
>> It is a classic example of a false optimisation, which looks great on an
>> idle system only because the idle CPUs are swallowing the work.
>>
>> This impacts the ability to find a 1G aligned block of free memory to
>> allocate a superpage with, and by the sounds of it, claims (which
>> predate this behaviour change) aren't aware of the "to be scrubbed"
>> queue and fail instead.
> 
> Claims check total_avail_pages and outstanding_claims.  It looks like 
> free_heap_pages() sets PGC_need_scrub and then increments 
> total_avail_pages.  But then it's not getting through the accounting far 
> enough to stake a claim?
> 
> Also free_heap_page() looks like it's trying to merge chunks - I thought 
> that would handle larger allocations.  Are they not truly usable until 
> they've been scrubbed, which leads to the lack of 1GB pages?
> 
> Clearly I need to learn more here.

I rather expect this then may not be scrubbing related, but domain cleanup
hasn't progressed quickly enough for the earlier instance.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 06:40:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 06:40:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121441.1465729 (Exim 4.92)
	(envelope-from )
	id 1uwxSk-0000bA-1x; Fri, 12 Sep 2025 06:40:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121441.1465729; Fri, 12 Sep 2025 06:40: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 1uwxSj-0000b3-VK; Fri, 12 Sep 2025 06:40:49 +0000
Received: by outflank-mailman (input) for mailman id 1121441;
 Fri, 12 Sep 2025 06:40: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 1uwxSi-0000ax-0i
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 06:40:48 +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 69328174-8fa3-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 08:40:45 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b07883a5feeso273527466b.1
 for ; Thu, 11 Sep 2025 23:40: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
 a640c23a62f3a-b07b32dd57csm296846066b.52.2025.09.11.23.40.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 11 Sep 2025 23:40: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: 69328174-8fa3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757659245; x=1758264045; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AxReRsaxHQo5lXVw1qwqvb+OtsLDzjQVC3KLDyod23I=;
        b=JtOxG0Ng6WDKdONV0Q3imeIrlZHdjdcK5cYQcbIFuP73uWMCBd2O1yXbqp19Ykzu6b
         yhkU+qd8T5nPs/XSUXxzqoHEN0R/igWFKb12Qo776ZqfbwdjIs9f7ax75k9CNLXRF31a
         CZuN3p897Avl3ou51Ce//XMV6SI0FSM2mgmWfKS334ntkc+Q8rZnDrwKo7++npHQgB2E
         q3RrMJb78D346rBrcB1L0Kt26NlYRUv4rEF7cP8Jj6/MGVuk7IeISzA+8qRw/7CXuiXF
         f2/xTauhmxhO5keIMkPkkOG15MlgVV8/NR4LeWQQ88aOkpoqSrCvaPz9a/FUqndb+Gqs
         pLRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757659245; x=1758264045;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AxReRsaxHQo5lXVw1qwqvb+OtsLDzjQVC3KLDyod23I=;
        b=SLCJcLV/d35zdQzTXVudEJzWFIIvCtjU3JfCAiXJchppsSpLVzRWjcrH1O0EVs6NB4
         sMoFCziLNoY9lNJcO3HbO+0pF7DT6GL7Mgf0JCrRc5U4/WXHZN3b2M8zhZiNo8lzAfWd
         oBW89GpQTvh1CUJ4kvEjpsHyufvjNKrfIsZyC/pR3LgENQ3nLPaHO7yHmir2Zp+Cxlb+
         60tK47Uv0NdUULIWmepqRg7fV8lmG/YgpKrvlP9DtFgZljXrPa8ZIx9BBx8KUgS1wVVC
         rTWSWRQIlWm1lisE5hBrmG6KynxdLnvhs6+KMH/foJBYIHIT8V7Zto7UxLEbduM6R2EX
         CRSQ==
X-Forwarded-Encrypted: i=1; AJvYcCXIcN6JPz0SZS+ajBF0uwtjprInE350zn9UTs7c+5yvk9+CIIYDgIkEYcqyQS3lnwazR7UdbuOq3rk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx743aNd0IUVHVEBYpfZfTNoUy1N49OV6XuYRuU8x80kylI+Mj2
	zpaCYRrM1vPxHNtyaZm0g3sJRwc0od/Oq91eIcUQLw/sL2qwqqdEn6xn/R6VEVb5WQ==
X-Gm-Gg: ASbGnctI7S4SHUCskuXFDZbO6IHm12PbubBZ4+Wj2+Om2yNs3IvhaHclpWD3Z5Jrikq
	RD5q8PUu9S94Bn0H5atJ4KYBxcilskh1EeJAsIcWjlwM3rUN7kIQLR4j152PFuFhlleTD8oeeYT
	zsRjgktdIjq1MYx9PI4dSqqfU8l3k/eBopTcsPV6bQ6fRehVexA6l2MRCpijiqLMivF4F1wNy+5
	tOzmYIgqzwjBmBwHUEyx9HtDITcIOSogwdZaOxcjmzrKudMptPwL5a1nFQuPxeFhUMGNTkbFqtC
	k/u2hRMZFqDOfWe0w6HAnmhBInU/OuDOX+638DHXpVMjdMiJ5QiIo1COa2RNm1Y2mGilIeQfk1/
	HiU2FmyyJV4nNOE5OOFQtXcl874Jyz80wVU1RQq2MnO8suOCgS64kgWuivyONUy/lylPjL8LpSb
	EZE1iFesNWhEHsIbex0w==
X-Google-Smtp-Source: AGHT+IFslBo+bQ9HJClrVwPYvIRArnACAj0uz4plujZwJ3Joi/FyYVT3mA6Dc5p+HjIyCYN8/dnGhQ==
X-Received: by 2002:a17:907:d2a:b0:b04:79e1:a08e with SMTP id a640c23a62f3a-b07c3583f6dmr166249866b.24.1757659245016;
        Thu, 11 Sep 2025 23:40:45 -0700 (PDT)
Message-ID: <4b958afe-dfcd-4ac0-bc09-468e2b9b2710@suse.com>
Date: Fri, 12 Sep 2025 08:40:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 xen-devel@lists.xenproject.org
References: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
 <20250911162336.23887-2-alejandro.garciavallejo@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250911162336.23887-2-alejandro.garciavallejo@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 18:23, Alejandro Vallejo wrote:
> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
> by the device model. The GPE handler checks this and compares it against
> the "online" flag on each MADT LAPIC entry, setting the flag to its
> related bit in the bitmap and adjusting the table's checksum.
> 
> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
> reaches 128, even if that overflows the MADT into some other (hopefully
> mapped) memory. The reading isn't as problematic as the writing though.
> 
> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
> then the bit where the "online" flag would be is flipped, thus
> corrupting that memory. And the MADT checksum gets adjusted for a flip
> that happened outside its range. It's all terrible.
> 
> Note that this corruption happens regardless of the device-model being
> present or not, because even if the bitmap holds 0s, the overflowed
> memory might not at the bits corresponding to the "online" flag.
> 
> This patch adjusts the DSDT so entries >=NCPUS are skipped.
> 
> Fixes: 087543338924("hvmloader: limit CPUs exposed to guests")
> Reported-by: Grygorii Strashko 
> Signed-off-by: Alejandro Vallejo 

In principle:
Reviewed-by: Jan Beulich 

However, ...

> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -231,6 +231,20 @@ int main(int argc, char **argv)
>      stmt("Store", "ToBuffer(PRS), Local0");
>      for ( cpu = 0; cpu < max_cpus; cpu++ )
>      {
> +        if ( cpu )
> +        {
> +            /*
> +             * Check if we're still within the MADT bounds
> +             *
> +             * LLess() takes one byte, but LLessEqual() takes two. Increase
> +             * `cpu` by 1, so we can avoid it. It does add up once you do it
> +             * 127 times!
> +             */
> +            push_block("If", "LLess(\\_SB.NCPU, %d)", 1 + cpu);
> +            stmt("Return", "One");

... if you already care about size bloat in the conditional, why are the two
bytes per instance that this extra return requires not relevant? They too
add up, and they can be avoided by wrapping the If around the rest of the
code. I didn't count it, but I expect the If encoding to grow by at most one
byte, perhaps none at all.

Jan

> +            pop_block();
> +        }
> +
>          /* Read a byte at a time from the PRST online-CPU bitmask. */
>          if ( (cpu & 7) == 0 )
>              stmt("Store", "DerefOf(Index(Local0, %u)), Local1", cpu/8);



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 07:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 07:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121491.1465744 (Exim 4.92)
	(envelope-from )
	id 1uwy3D-0004nJ-Ry; Fri, 12 Sep 2025 07:18:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121491.1465744; Fri, 12 Sep 2025 07:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwy3D-0004nC-O1; Fri, 12 Sep 2025 07:18:31 +0000
Received: by outflank-mailman (input) for mailman id 1121491;
 Fri, 12 Sep 2025 07: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 1uwy3C-0004n6-Lu
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 07:18:30 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20620.outbound.protection.outlook.com
 [2a01:111:f403:240a::620])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a9b1cdbf-8fa8-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 09:18:22 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 MN0PR12MB6174.namprd12.prod.outlook.com (2603:10b6:208:3c5::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Fri, 12 Sep
 2025 07:18:17 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9094.021; Fri, 12 Sep 2025
 07:18:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a9b1cdbf-8fa8-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a1QmiaRORkcYXR0QrXxZWjJrspdYdxLSk2+lZuHOfOaQ8MgO8VCNsy+kk+KW7Ja2RqG5sSxtsXmm/MvB0i4+JzrTBrqy0Loclf/v9eeBh6WHfBs0hKPikjUsSBbKZDHLDgTLuss7IFqH+fm19YKKze+SKb/U0oG6/hL6hQALbD0pabCtjvF86iRMWvt+LDNgKToj6H45IeqmYJNTYe4NgExQNuaeQSE1Mw+yeWH5SKDa4HSfrNFE+LRjV3jjja26JXxzD2C+N+O8KHBxlHBN2n/akWcNzUSe8srLdFVS9MyBM21R3q0BN5WV6SZ/YpEzQs4uXfmBPgcMCVzl5tfqXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=va/hHtoVUddBHPPJfrZeDTTi86YAml7MWdPG+2P6Py4=;
 b=AvKbKKoG53vD33Fb1OT/iX2zLcqS7TEPbPY6Nkfggi4bKKKB/DDGXspfrHAXvn0uvqUmZXhwNAVREz9vbWGfYvKr7bAXXNJw40MfNODJL4iq+Sxgux3fFFyhKx962l3uMpp8DN/R/s6bIUl7eaHMWJQQmm/wVVZiQYRdfvqbVNK55gb6Fa8Xe0o3z3XBVDLwvQlZ3+jhE3GLahmdS+eNdlJYZWEZNa0VkZBjgtD1oahuCUWowzCnwGYROARj30F+zgwMj/58LFH5UVHYu+g7g8gHCtlOhrHs40XbQ9P5sZO0IS2DvSoQkmLnXg+p34xug8qKiIloqPBzjQIuncD0zw==
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=va/hHtoVUddBHPPJfrZeDTTi86YAml7MWdPG+2P6Py4=;
 b=5FGZtnWRDzDe0/K7NMNJZBjG/zkebTySFaQ7cQ1ovGgUxLLAETAIZdxmap7EOHmISDmDLxmDzOidPzQmnsIYmLEtajRPbDfWzBUQ1jv71kLzxkYfC/RzyxOauL//fn3extHW6VyfrVh1tiioY/KmPmQFFLUj6UZafJqJGAa78vs=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, "Orzel, Michal" , Volodymyr
 Babchuk , Andrew Cooper
	, Anthony PERARD ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Christopher
 Clark , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 08/26] xen/domctl: wrap domain_soft_reset() with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 08/26] xen/domctl: wrap domain_soft_reset() with
 CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYHZJOGLvR3zUGWUPGFPkbfXLSMhqOAgAKeg+A=
Date: Fri, 12 Sep 2025 07:18:17 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-9-Penny.Zheng@amd.com>
 <4be69331-8002-47a3-a2e1-e34b12a5c5bb@suse.com>
In-Reply-To: <4be69331-8002-47a3-a2e1-e34b12a5c5bb@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-09-12T07:18:10.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_|MN0PR12MB6174:EE_
x-ms-office365-filtering-correlation-id: 36e0a22f-f153-4916-d8a2-08ddf1cc8bcc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?ODVmVW9EZGttWW9aR3AwaGNGYkZFTXZRblU3QVFBMk1yZnhNd0duNUZBTlV1?=
 =?utf-8?B?U1dQK2ZlSXlYM1Z6QnIxRzFCY0o0UUl4VUQ2aGVHalZqYllQdmNYNnk2RS9K?=
 =?utf-8?B?WTJ5MEZyY0VHaHVvVGRJaWJxUlczQWlVdk5zdEMrL2VVRlQ2YTVBTlZIaVRs?=
 =?utf-8?B?bk15QVYyWWxuc0NSNFVRQlBzeGxtYks2OGVHNi9rMm93ZGhOWEVXT21VNlFP?=
 =?utf-8?B?VVZvOUkyMDNDUVNkS24rY1oyVWF2dUVxN2JBczM1Yk1VV3RleUtJMVAwSGtK?=
 =?utf-8?B?VTlBWDFzUTZtMmd5K3hiMW1NWW4vZTk1TWdaUUhROWpma3I2L3duYmlvSUVT?=
 =?utf-8?B?cjk0eGwxSEQzbENXNXRCSGUzcTIrUEJkd0ExTHZTNVJtZi9jS3FVbXRVd2lS?=
 =?utf-8?B?KytHNXo1T1d6R0dHWkF5a1BEZFE4MEFMWm9yQkwrNlJ6b1UxamVwbXBMZWpF?=
 =?utf-8?B?aVdvU1NJV09Sb1k5a2Y1M0hZN3J3cmYzeFZHTUtOMXhhUEkvenViK2gvVVlt?=
 =?utf-8?B?RlB5YXFBK2VmekczTGlMaFZSNVV5c0ZScE1URGN4eXRQMDhsdVcyeDZkT3dv?=
 =?utf-8?B?clVVWUpZelI5WHlFdFJlNFpDcEp5TFdaNEs5UnNSSzRFY3RRYi9CL1QzRkc5?=
 =?utf-8?B?NnJhaWZNMEFrNllCZkZvamtFeUxmRmFBNlg0ODNSU3drZ1FtMG9rVGpNdmhr?=
 =?utf-8?B?TUJjbzJwZmlRMlYyVGRhZWVVa0lNcTZzWGU5WTRncEsxWUd1bTZTU0RzUmo2?=
 =?utf-8?B?emZPQ1ZVRzlIU014YktRbXhBL3d1bmFscUVXL2JnREVjNlkwWkhFY2pIVTBr?=
 =?utf-8?B?N01pZVkxRHBxNjRRby9ObjdaQldIbFpnVjB4K3MvSVlGditUaXZuQzhSZ21N?=
 =?utf-8?B?SmJuOENHWUdJZHNCL3FITTg5bFlmUHcrbkV1dTdPYUUvNzczOEZJTUQ5QXov?=
 =?utf-8?B?ZitrWlZuWS9mVm5ZUUtyR3haRHBPWFhLNWhlWk5LRExzTXFMWjAwZXJ0N1lv?=
 =?utf-8?B?NzVjc05KOXhmOEpMOUd6TXZLYlNNMnRrYWVpVEMzcE9nQTNHcnp1cDRaam92?=
 =?utf-8?B?dC9mT3hoSTJZTm5PNHVyMEpqSmp5Mlk1YnJpSjlLcUtMQVg5d2hSbzRGc3Ew?=
 =?utf-8?B?b0Zld2ZibSszamQrclNFZGUyNys5VTdtVEhLM095aWNUczVPQU1adXdlY29J?=
 =?utf-8?B?UGUvSG03ZUw3cHUrakRHMWFpVjdObTZRT3ZJNFVBTXRrWjZUWUk4V3ZWWXJO?=
 =?utf-8?B?anhGZmN5aTZuV0tZT1oyK0FmejJVOGwxU0Q4RTlsTFZ1MTRHY1BKdnMyekd5?=
 =?utf-8?B?cGQ2K1dka3lwNGpuaW1OWE55U0RMTEhMcVpDc01LL2cvU2JXWTVnWkZWc1RZ?=
 =?utf-8?B?VExZTW9UbFZTRDFvZ2ZrbGcycEhjVTZPdkZ2elgvcVE1YzZaYjV1T0lBdWFJ?=
 =?utf-8?B?MVhzVnY5d1pSbVZ2V2hLK1hoSFR6Yll6S1VJcmVpK1BFOUkyYU5NSHpldUxO?=
 =?utf-8?B?cEsvL2lNL3RIVnlRUWVaejlBWVBoWjE4UWlUdzJtM213MEJnVXoyN0lEMmpl?=
 =?utf-8?B?ampDdXo0WHdTdXc0RUVCRVZNSU1jR1N5TkpZZzV1QmZmRzBkRWlSaUMyR25T?=
 =?utf-8?B?bE9ZY1I2K3E3UThKMnZWMGVPUGJrc1kwbFJyc3J1TUZOZWRQdTFaSG1WNkJS?=
 =?utf-8?B?VzBBUDRWSEt2NUs2K3AxQkVFMWJzMkpBTlFQZzdveHRDTURrR0FJRFJJcXIx?=
 =?utf-8?B?QWNSaytKVlh0RU5ZZkdvT2dlMFB4ckRyM2Jnbm9MTzR0a0VYQjB5Q1pWNWFt?=
 =?utf-8?B?YjVVajZGVitZREgwMzBWa2o3VkRXRHYzU3V0TEFBSkRiWkxTRzd0MEczd2NP?=
 =?utf-8?B?MXlWMlVsMlM5OHNiUFprOE5lQ0xrcUFjZ0FVYU1Wd1J4TUtSeTk1OVRhMEp0?=
 =?utf-8?Q?jXgBDLnVP2Q=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)(7416014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UDBEN0gvTDNHMzQwT3d6RDNvR0lTZWJ1VnhKaXFsY045aWU3ajh1eFJHNHds?=
 =?utf-8?B?RHI0QXg4K3JvaEh0ZjBOYXdaR3dWbkVWZVRjMjlGTXlEN0lhdUlPYTNFZWlO?=
 =?utf-8?B?M0R4U2hxcStBSHJpS1dCaXY0UGVXL3U5b09EY2VlTmpXbHl3QytQSTFmRXFT?=
 =?utf-8?B?UXJXU0w3U3lUQVdHeVM2OWhGVWNjMEpWaGdITGVEaU9DYnRjbkh6UFdYSytI?=
 =?utf-8?B?bk5pcTM5VnVZSDJBYlFUMWp2TjE0K082TjFTR1orR2wwZERYeG9ybE14LzJa?=
 =?utf-8?B?anVxYkNhQkdianZqVVd3anNncW5XdHNJTW91dVlDUnBEdnEvZWVmSjNIaDcv?=
 =?utf-8?B?L2ozeGM3dlFoOHFLaVpBWDJSTDAzb1NQbjYxbFkxNjRkM2x4bjZwM3pCZ3gx?=
 =?utf-8?B?cEpwMHdLQXE5Y0dZYXBvbUpESHVKZGhwWUlHTmFOS0tVYzN0VXNUWmJRWkRx?=
 =?utf-8?B?QWdrd2o3bmlMZFdaVEtXSXlLNGR2UXFhVTE4WGo5ekh4SlREaXhBL2M3UUZx?=
 =?utf-8?B?S294dk54V0tsemxMdUNMTVIzNXQ2OXhncjNOeE1kZmQ4ZFIxN3dTQm5XcW01?=
 =?utf-8?B?TjlYd242ckREYTB1V1MxYU4yRDE1WjN4djR0L3VCemhYY2p6WXlMR2lHMHNu?=
 =?utf-8?B?b2NWYzd2R3BGRmFwZTZRZVBOMndqeFpzNW5ISHNCNEFGcFdpTkRpN0ZWc0R3?=
 =?utf-8?B?ZngxUE1RZS9yQUl4QUFLQVA2VDBvejF3STNFcWtiQzgzL2pzUEdyTFloQWVv?=
 =?utf-8?B?dkdFYmk1aTN2USt1SWdUS3huNkE0NzczNXZDTFFKbGppd09rbjBFQVdLVmor?=
 =?utf-8?B?akI1MzdyVGw2dkxxZndaK0Q0dkdZQjUxYkFiYlk0TzRNT2tPLzduNmhTNzk2?=
 =?utf-8?B?R0dHZ2phMGVyTCt1MXU2Z2NMUjlhS3JzSWRlcnAzUGlvNnVXWExOYnJXbkI1?=
 =?utf-8?B?alEyaG5oQ3FvdVRWeVFCUFpMSVo4VU4wcDBiVFlYZDR3K1htWHhBNGFSMG1t?=
 =?utf-8?B?Y3JBTWF2WGRGSFNFZjltL0U5OVZsS0dpekNDMVQ5TmVMRXhuK2pscWhqVytL?=
 =?utf-8?B?ZHJYZHF3SGh0OVlzMTgrQjl2SFNJT1ZBTmNldFdRTyttN3dBTDcwOUZvWkFr?=
 =?utf-8?B?c2lpSFRpOHdrckpoMGJDbHN3WE5FNEdiejV4OEYxa2djN1VaQk1HeURMUlJC?=
 =?utf-8?B?a0Fzc283SFpUcDM0VU1najNvbnFUbG5ncEVZOGtLcXV5QVJEOS9WUDB5N05S?=
 =?utf-8?B?cHpLRWJ5OUJ4dEg3QUZZS2lwS0dSVVNyeFVEOUtXMDRudFY3MmowWm85eEIx?=
 =?utf-8?B?YmUvWVM0eUVMYklhZGdQZmt6Y2FIazE4WW9nQ3ZWMEk3eWRiRy9HQmFNcWEw?=
 =?utf-8?B?OHM1YVgvbSszY3ZIM3E0OHRYVCtaSERYRzdKdXhhanNKcEc5Uk9KTjFUUFpF?=
 =?utf-8?B?Ym8yWkxHK1B3MXI3L0ZLWXVOZWpjbThWYmpEMmZTZkE5SzNEWHJFMktlUE81?=
 =?utf-8?B?K2Vsamp4aDdpSUNEcmY3aUJpL2JwQ2xIazZXSmtuUzZYeEw3TCs3TVZDT25w?=
 =?utf-8?B?TUd3WTduRERnYXRTNDZPMmMwYU5XU3gxL1N0VjZXWHVnb1FrNkNmV2tlQVJH?=
 =?utf-8?B?TlRiUThrNDhtNmttQUZqa0VwOHowaUcxajZabUtXMHVUVTBRSjlDOWdXVnhN?=
 =?utf-8?B?MW51SU51bEYzUWU2VXk1QTFZTnE4TXJ2OHlscEwxS242Uk01c3Nxak5nNmZy?=
 =?utf-8?B?S3NDdjlYOTFyQU50enhJMmlsS3NHajRSVlNJRkVIT2lQaHlLZEw1WHVHTkln?=
 =?utf-8?B?dS9YMWVDZWM3eUdUMVVYbWFzYS9MZGFwMUJvSGVUZWFMbyt4QVluQkZ2VElM?=
 =?utf-8?B?dVNZaHVCcWsvMXd1aUlNVWhwbkpMb2U4OXVkZWViZFBFWmV6R2poSmlMMlFS?=
 =?utf-8?B?YlYrZnZ6bG5UMlZYODR0Y2oxT3h5ZUZ0U1RSN3V5UWxTUi90ZUlLMzRjNkM3?=
 =?utf-8?B?aCtydEVvaTNydVRSWEF3R3h5bU83K09uZUtyc09hcWJ4TGRBelJLcXZHUGM5?=
 =?utf-8?B?TFZzcGpDTE9Xd1J2YWwyRXBKOTVpby9WSzkrblVGQmdUcitidmJrWnBXSklz?=
 =?utf-8?Q?llMI=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: 36e0a22f-f153-4916-d8a2-08ddf1cc8bcc
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2025 07:18:17.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: +IGKMd98T1xJkcoonrGWXxm1KLQCDPOXUjFHa3hQZ5IQFGDk8KqMFefqWZU7l0QnkueGYlECQvCHtmncfITgBQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6174

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEw
LCAyMDI1IDExOjE0IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IFN0ZWZhbm8gU3RhYmVsbGlu
aQ0KPiA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz47IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5v
cmc+OyBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+OyBPcnpl
bCwgTWljaGFsIDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47DQo+IFZvbG9keW15ciBCYWJjaHVrIDxW
b2xvZHlteXJfQmFiY2h1a0BlcGFtLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29w
ZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVj
aD47DQo+IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgQ2hyaXN0b3Bo
ZXIgQ2xhcmsNCj4gPGNocmlzdG9waGVyLncuY2xhcmtAZ21haWwuY29tPjsgRGFuaWVsIFAuIFNt
aXRoDQo+IDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tPjsgeGVuLWRldmVsQGxpc3RzLnhl
bnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMDgvMjZdIHhlbi9kb21jdGw6
IHdyYXAgZG9tYWluX3NvZnRfcmVzZXQoKSB3aXRoDQo+IENPTkZJR19NR01UX0hZUEVSQ0FMTFMN
Cj4NCj4gT24gMTAuMDkuMjAyNSAwOTozOCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gRnVuY3Rp
b24gZG9tYWluX3NvZnRfcmVzZXQoKSBpcyByZXNwb25zaWJsZSBmb3IgZG9tYWluIHNvZnQgcmVz
ZXQNCj4gPiBkb21jdGwtb3AsIGFuZCBzaGFsbCBiZSB3cmFwcGVkIHdpdGggQ09ORklHX01HTVRf
SFlQRVJDQUxMUyBUcmFja2luZw0KPiA+IGl0cyBjYWxsaW5nIGNoYWluLCBhbmQgdGhlIGZvbGxv
d2luZyBmdW5jdGlvbnMgc2hhbGwgYWxzbyBiZSB3cmFwcGVkDQo+ID4gd2l0aCBDT05GSUdfTUdN
VF9IWVBFUkNBTExTOg0KPiA+IC0gZ3JhbnRfdGFibGVfd2Fybl9hY3RpdmVfZ3JhbnRzKCkNCj4g
PiAtIGFyZ29fc29mdF9yZXNldCgpDQo+ID4gLSBhcmNoX2RvbWFpbl9zb2Z0X3Jlc2V0KCkNCj4g
PiBXcmFwIFhFTl9ET01DVExfc29mdF9yZXNldC1jYXNlIHRyYW5zaWVudGx5IHdpdGgNCj4gPiBD
T05GSUdfTUdNVF9IWVBFUkNBTExTLCBhbmQgaXQgd2lsbCBiZSByZW1vdmVkIHdoZW4gaW50cm9k
dWNpbmcNCj4gPiBDT05GSUdfTUdNVF9IWVBFUkNBTExTIG9uIHRoZSBjb21tb24vZG9tY3RsLmMg
aW4gdGhlIGxhc3QuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQZW5ueSBaaGVuZyA8UGVubnku
WmhlbmdAYW1kLmNvbT4NCj4gPiAtLS0NCj4gPiB2MSAtPiB2MjoNCj4gPiAtIHJlbW92ZSB1bm5l
c3Nhcnkgd3JhcHBpbmcgaW4gc3R1Yi5jDQo+ID4gLSBhZGFwdCB0byBjaGFuZ2VzIG9mICJ1bmlm
eSBET01DVEwgdG8gTUdNVF9IWVBFUkNBTExTIg0KPiA+IC0gd3JhcCBYRU5fRE9NQ1RMX3NvZnRf
cmVzZXQtY2FzZSB0cmFuc2llbnRseQ0KPiA+IC0tLQ0KPiA+ICB4ZW4vYXJjaC9hcm0vZG9tYWlu
LmMgICAgfCAyICsrDQo+ID4gIHhlbi9hcmNoL3g4Ni9kb21haW4uYyAgICB8IDIgKysNCj4NCj4g
V2hhdCBhYm91dCBQUEMgYW5kIFJJU0MtVj8gVGhleSBoYXZlIHRoZSBmdW5jdGlvbiBpbiBzdHVi
cy5jLCBidXQgbm90IGFkZGluZyB0aGUNCj4gI2lmZGVmIHRoZXJlIGluY3JlYXNlcyB0aGUgY2hh
bmNlIHRoYXQgd2hlbiB0aGUgc3R1YnMgYXJlIHJlcGxhY2VkIGJ5IHJlYWwNCj4gZnVuY3Rpb25z
LCB0aGUgaW50ZW5kZWQgI2lmZGVmIG1pZ2h0IHRoZW4gYmUgZm9yZ290dGVuIHRvIGFkZC4NCj4N
Cg0KQXMgd2UgYXJlIGFkZHJlc3NpbmcgY29uY2VybnMgb24gdGhlIHYxIGFib3V0IGVkaXRpbmcg
c3R1YnMuYyBmaWxlcyBbMV0sIEkgcmVtb3ZlZCB0aGVtIGFsbCBpbiB0aGlzIHBhdGNoIHNlcmll
LiBJZiB0aGV5IGFyZSBjb25zaWRlcmVkIG5lY2Vzc2FyeSBub3csIEknbGwgYWRkIHRoZW0gYmFj
ayBpbiBuZXh0IHZlcnNpb24NClsxXSBodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDgvbXNnMDAxMzUuaHRtbA0KDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 07:24:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 07:24:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121508.1465754 (Exim 4.92)
	(envelope-from )
	id 1uwy8U-0006OB-Gt; Fri, 12 Sep 2025 07:23:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121508.1465754; Fri, 12 Sep 2025 07:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwy8U-0006O4-Du; Fri, 12 Sep 2025 07:23:58 +0000
Received: by outflank-mailman (input) for mailman id 1121508;
 Fri, 12 Sep 2025 07:23: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 1uwy8T-0006Ny-Gg
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 07:23:57 +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 70db4044-8fa9-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 09:23:55 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-5688ac2f39dso1798994e87.3
 for ; Fri, 12 Sep 2025 00:23: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: 70db4044-8fa9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757661835; x=1758266635; 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=/XBtKd030PtX4VgNSyh7U2rBK96P7C4gA9am3ktsEBw=;
        b=EVquBs0mBjcczyXbjrjtzfzjQMXRU/S2sro96YXeYCpzH9VOjHDKxi48Dt2xpfVHNA
         y6dBhSuVumNuh3ANHi25UF0RRPrEMLuAtccdsCiW/P7mVfBP7Ltk3mfl7ZdwUFPxj0gD
         xe4Po7GjG4K7eKrRGvOv2cjsswDEjW8N7fHPDXu9uFhqgNBA+upJh/9Ud5P4Gw+AYjli
         ULaLQFQxyisNgrj724ouM8NUunLAkyVtfZ2fNo70IxiiRwzBTjwfPFSGd4jxPrTsjoDD
         IgL8m5Wrb1Om5ygOoa0TcwskmZOEHPzgGl0fTLrx69akciTH/kjyY/aux383wkTu7t9z
         kTNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757661835; x=1758266635;
        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=/XBtKd030PtX4VgNSyh7U2rBK96P7C4gA9am3ktsEBw=;
        b=TDnqo4jKRe9Hw5xian2xqz1ntM45oVCwwH3CFwhveFjXkH6yMtZPWdV7Q2Ke6c7XpN
         GJcnr4kQjziF1a79jlBFf4t9QdAz1lGuzYh84EoBCbEvBwYqPb+jdFtg260bG0D68OYu
         EJ+9XAFGB0iXwCFljCypDyJ2FKHdVc+gS9Zjk5KNeuuienPaB0RfPsKzh1ZczJ4YaiOJ
         9j6g0ZN6+E5/QbvhWTtu8xlyHQ98pyfPY/3EQtQrNdBkGse9e+c5b4sb940TwC8GaHPL
         86m+s5SGdzhY+5DSEYZ9L8An1/yATQxpogyMlpLiM0pYDqudkg6U852X+JZWPKnK2W9q
         sYWA==
X-Gm-Message-State: AOJu0YyD3y1IBeDtFBakcNU5x41nLg9hEIq9N/93Hm2WnKghDHdjXpEh
	zXk9JiKzq5W27+/GnztU4uOQ943olTMVxBBTM2O4pXEAW5oT8eC4VkcX9XSqScoWOctCRv0nNP+
	Hm+jV5t14eWW+TJHzIRT9SNXwAwviRcY=
X-Gm-Gg: ASbGncvED+2PkH38LbH4z+0YO07PH7KYt6VleHl7SR8DoIitYo6kOzSVj6WfxkiQ1Am
	9EyhL2yHzsGVY1Sc1Hte4M9PXUykRaFcTuJO1mn/SIDM/qn1Nbq+LPX7e3sqU2ltWLK63c/5leg
	TxX8VpfaqYSwop0F7kfGKOBFF3TKh42TwdDQ/PWoP1gLIeTVmicNCKQQCnI1v5uB13wGayrEJxT
	81mH0Q3rktpBnn4
X-Google-Smtp-Source: AGHT+IHgwEP2w9zcActW5zsVd93iodZHaojQBpFqqXGFF7lbwNT9cefyZgGD08KypNHAIUAWfw5FoTXm9eEVdzNVhCo=
X-Received: by 2002:a05:6512:3599:b0:562:d04d:fa05 with SMTP id
 2adb3069b0e04-5704fb8634dmr517183e87.54.1757661834640; Fri, 12 Sep 2025
 00:23:54 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-6-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-6-dmukhin@ford.com>
From: Mykola Kvach 
Date: Fri, 12 Sep 2025 10:23:42 +0300
X-Gm-Features: Ac12FXwZPcQsXKAtGl9ieahyjpUhQXfZJ9pjXTrDT5SvYeWfKCjFAlREpZIQays
Message-ID: 
Subject: Re: [PATCH v7 05/16] emul/ns16x50: implement SCR register
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for the patch.

On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add SCR register emulation to the I/O port handler.
> Firmware (e.g. OVMF) may use SCR during the guest OS boot.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - default handling of non-DLL/DLM registers moved to the previous patch
> ---
>  xen/common/emul/vuart/ns16x50.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index da8583a1dc93..5643ef4cc01e 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -106,6 +106,11 @@ static int ns16x50_io_write8(
>      {
>          switch ( reg )
>          {
> +        /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
> +        case UART_SCR:
> +            regs[UART_SCR] =3D val;
> +            break;
> +
>          default:
>              rc =3D -EINVAL;
>              break;
> @@ -177,6 +182,10 @@ static int ns16x50_io_read8(
>      {
>          switch ( reg )
>          {
> +        case UART_SCR:
> +            val =3D regs[UART_SCR];
> +            break;
> +
>          default:
>              rc =3D -EINVAL;
>              break;
> --
> 2.51.0
>
>

Reviewed-by: Mykola Kvach 

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 07:26:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 07:26:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121522.1465763 (Exim 4.92)
	(envelope-from )
	id 1uwyAy-00073p-U6; Fri, 12 Sep 2025 07:26:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121522.1465763; Fri, 12 Sep 2025 07: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 1uwyAy-00073i-Rd; Fri, 12 Sep 2025 07:26:32 +0000
Received: by outflank-mailman (input) for mailman id 1121522;
 Fri, 12 Sep 2025 07:26:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uwyAx-00073c-7L
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 07:26:31 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id cc310a30-8fa9-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 09:26:29 +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 CD76F16A3;
 Fri, 12 Sep 2025 00:26:19 -0700 (PDT)
Received: from [10.57.66.147] (unknown [10.57.66.147])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DD1E03F63F;
 Fri, 12 Sep 2025 00:26: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: cc310a30-8fa9-11f0-9d13-b5c5bf9af7f9
Message-ID: <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
Date: Fri, 12 Sep 2025 09:26:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/09/2025 20:14, David Hildenbrand wrote:
>>>> On the other hand, with a pagefault_disabled-like approach, there
>>>> is no
>>>> way to instruct call {3} to fully exit lazy_mmu regardless of the
>>>> nesting level.
>>>
>>> Sure there is, with a better API. See below. :)
>>
>> I meant while keeping the existing shape of the API but yes fair enough!
>
> Time to do it properly I guess :)

Yes, I think the discussions on that series have shown that we might as
well refactor it completely. Once and for all™!

>
> [...]
>
>>> Assume we store in the task_struct
>>>
>>> uint8_t lazy_mmu_enabled_count;
>>> bool lazy_mmu_paused;
>>
>> I didn't think of that approach! I can't immediately see any problem
>> with it, assuming we're fine with storing arch-specific context in
>> thread_struct (which seems to be the case as things stand).
>
> Right, just to complete the picture:
>
> a) We will have some CONFIG_ARCH_LAZY_MMU
>
> b) Without that config, all lazy_mmu_*() functions are a nop and no
> lazy_mmu_state is stored in task_struct 

Agreed on both counts (replacing __HAVE_ARCH_ENTER_LAZY_MMU_MODE).

>
> struct lazy_mmu_state {
>     uint8_t enabled_count;
>     bool paused;

Looking at the arm64 implementation, I'm thinking: instead of the paused
member, how about a PF_LAZY_MMU task flag? It would be set when lazy_mmu
is actually enabled (i.e. inside an enter()/leave() section, and not
inside a pause()/resume() section). This way, architectures could use
that flag directly to tell if lazy_mmu is enabled instead of reinventing
the wheel, all in slightly different ways. Namely:

* arm64 uses a thread flag (TIF_LAZY_MMU) - this is trivially replaced
with PF_LAZY_MMU
* powerpc and sparc use batch->active where batch is a per-CPU variable;
I expect this can also be replaced with PF_LAZY_MMU
* x86/xen is more complex as it has xen_lazy_mode which tracks both
LAZY_MMU and LAZY_CPU modes. I'd probably leave that one alone, unless a
Xen expert is motivated to refactor it.

With that approach, the implementation of arch_enter() and arch_leave()
becomes very simple (no tracking of lazy_mmu status) on arm64, powerpc
and sparc.

(Of course we could also have an "enabled" member in lazy_mmu_state
instead of PF_LAZY_MMU, there is no functional difference.)

> }
>
> c) With that config, common-code lazy_mmu_*() functions implement the
> updating of the lazy_mmu_state in task_struct and call into arch code
> on the transition from 0->1, 1->0 etc.

Indeed, this is how I thought about it. There is actually quite a lot
that can be moved to the generic functions:
* Updating lazy_mmu_state
* Sanity checks on lazy_mmu_state (e.g. underflow/overflow)
* Bailing out if in_interrupt() (not done consistently across arch's at
the moment)

>
> Maybe that can be done through exiting
> arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode() callbacks, maybe
> we need more. I feel like
> we might be able to implement that through the existing helpers.

We might want to rename them to align with the new generic helpers, but
yes otherwise the principle should remain unchanged.

In fact, we will also need to revive arch_flush_lazy_mmu_mode(). Indeed,
in the nested situation, we need the following arch calls:

enter() -> arch_enter()
    enter() -> [nothing]
    leave() -> arch_flush()
leave() -> arch_leave()

leave() must always flush whatever arch state was batched, as may be
expected by the caller.

How does all that sound?

>
> [...]
>
>>
>> Overall what you're proposing seems sensible to me, the additional
>> fields in task_struct don't take much space and we can keep the API
>> unchanged in most cases. It is also good to have the option to check
>> that the API is used correctly. I'll reply to the cover letter to let
>> anyone who didn't follow this thread chip in, before I go ahead and try
>> out that new approach.
>
> And on top of the proposal above we will have some
>
> struct arch_lazy_mmu_state;
>
> define by the architecture (could be an empty struct on most).
>
> We can store that inside "struct lazy_mmu_state;" or if we ever have
> to, start returning only that from the enable/disable etc. functions.

I'm not sure we'd want to mix those styles (task_struct member + local
variable), that's adding complexity without much upside... Also having a
local variable at every nesting level only makes sense if we have an
arch callback regardless of nesting level, which is unnecessary in this
proposed API.

>
> For now, I'd say just store it in the task struct in the
> lazy_mmu_state. But we can always adjust later if required.
>
> In the first (this) series we probably don't even have to introduce
> arch_lazy_mmu_state. 

I suppose this could improve the overall struct layout - but otherwise I
don't really see the need compared to adding members to thread_struct
(which is fully arch-specific).

- Kevin


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 07:30:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 07:30:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121536.1465774 (Exim 4.92)
	(envelope-from )
	id 1uwyEG-0007dp-EI; Fri, 12 Sep 2025 07:29:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121536.1465774; Fri, 12 Sep 2025 07:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwyEG-0007di-Ad; Fri, 12 Sep 2025 07:29:56 +0000
Received: by outflank-mailman (input) for mailman id 1121536;
 Fri, 12 Sep 2025 07:29: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 1uwyEF-0007dc-Kx
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 07:29:55 +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 45f94926-8faa-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 09:29:53 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b07c28f390eso99169766b.2
 for ; Fri, 12 Sep 2025 00:29: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
 a640c23a62f3a-b07b30da289sm307046866b.17.2025.09.12.00.29.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 00:29: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: 45f94926-8faa-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757662192; x=1758266992; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1OaZ4ACBHXcPAaQSwE2GYXsBNKUBXGC1v8dtnTOZtjQ=;
        b=N1yRLAUS2/5ZXKPbs0A5j/d9wA2/7t5CTFHAeb2kUihbszR8zGTvXFziue1DmBhtVL
         meijvjk8vKsoYNxA6pN+pNeJxJlg/Aq8Mhn/U4bqaPO3vf/Mk3mbLiUsFqWLPDuStj0v
         5EnEI3YC07WgkiclMwLrT351IRm+g+hQTlOMcsM0/OGzi5RuumZkt9OQNZrDXc8M6Wwx
         iHtcwkHvyok6Uuue+qxYoZF+pSMLVgQclFfwecBwEV8KIm1hqgspL/PGF6fcP1k+YUhi
         Qy6DYKaWhj/g700UjMJhDjM5PARJGNMmD1hwoUL1ZSxJYJSlk4ieAOFsafdJNfgMb4rw
         3I8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757662192; x=1758266992;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1OaZ4ACBHXcPAaQSwE2GYXsBNKUBXGC1v8dtnTOZtjQ=;
        b=AlLJmyarIir8hOs0iQxZoDiYjw/lifLzrP9r8fslFU/daTTEJfZXPMFj1lpomjn4g7
         gGhiuG4hTc2pB0Z7wK3BE+udSTRe2Uqxr501hfsDpFV39G5fuBByONvWswjuUkFHQO6h
         yq/NbK0a7q1pUZz9c4v2hQ+YjOMEwBZ/0Yi/NIyCNyhwNFM5SGHAAyjvUzdVOZ8Qt4mJ
         ez9C3jhvPKSh0StBGzrtQiodbSVpt82XVmZEAE/XVuT/8Gq+gWfCY0eOH0a6+BQubK5T
         BpIMkeV0qByiHxkjaZidroNSjsqg+tGXFMDVFszU+2uQEorgCQ4h+6x1Qn4L6RgM4BAH
         L8AA==
X-Forwarded-Encrypted: i=1; AJvYcCV0cimtTa4B1Ao7IUWYRLDljyAZjSlxcUp87DJ0rZyGVC9WmuQ5ZjApoeIW8KZokDxzwIOZhLi8VkU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw80AX4x3WbtQjLd6fKAaQ3gXzzR3PcZtT/OgJX6AgU4vVA1eqm
	7MmrUpjLdchW1KH3lKjPrNDQPzToSH5uMtweTvrwlny8tR+Nf0ukMRJv97JJBBfX6g==
X-Gm-Gg: ASbGncurUN7JD2MMsHYKc9AOSzH2zrRWl3Srx2kLWFFfJ4C65Pn7xSK3K0yrcbGlboq
	dy4D7ymj+rQZOwkMEScjx3j5KPUnqRJHWxBeH5RFZPjG24Aguv6I+gNZTWT/zJ8+A5zXIeVVjpf
	Wk34fZZEvVSXWER84y0vqHuMesZLP5X0wD++W3fG7s1QuqBMxE+08d1/xxOGBTzpGZQxwf9/OMo
	zIQQyHEpHW98r1s0dU1VnDOLzb3mRg+BjHmIBZJxoSA19q8osvz9kx2fUkyqO4B/QQuvMV6S2FL
	GFBiUFTfYDX/zspm9GvCsC1fV5M0x1NkcRVr5C1/h9fEJ2m6NBDbaOGqpyVCjAo6l9iNtimZJjl
	9D5wgg+XzEAPeO0tut/M99RjU9LMaaALDljp/c1kz0D2wiVv7K/p5hD/KI3yj/5OcDQHey4Cay1
	YSraOfsqBltnjQBvK8NQ==
X-Google-Smtp-Source: AGHT+IEBqGfy0KWQ0edxWi2/LvF8zYRmD0eI8sUiDHIpd85tM4bid6kQzCDaOu5unS8XwDcNLXdEXA==
X-Received: by 2002:a17:907:7e8c:b0:b04:3513:5138 with SMTP id a640c23a62f3a-b07c37fca87mr188017766b.41.1757662192371;
        Fri, 12 Sep 2025 00:29:52 -0700 (PDT)
Message-ID: 
Date: Fri, 12 Sep 2025 09:29:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
To: Penny Zheng , Tamas K Lengyel 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 xen-devel@lists.xenproject.org, Oleksii Kurochko 
References: <20250912045254.3731398-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: <20250912045254.3731398-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.09.2025 06:52, Penny Zheng wrote:
> Function vm_event_is_enabled() is introduced to check if vm event is enabled,
> and also make the checking conditional upon CONFIG_VM_EVENT, which could help
> DCE a lot calls/codes, such as hvm_monitor_io(), etc when VM_EVENT=n.
> In-place assertion of arch.vm_event is kinds of redundant and could be
> removed.
> 
> Signed-off-by: Penny Zheng 

Why is this sent standalone, without even a reference to the domctl series?
Without the connection, this clearly wouldn't be valid to consider for 4.21.
Also you will want to Cc Oleksii on such past-the-deadline submissions.

> ---
>  xen/arch/x86/hvm/emulate.c          |  6 ++---
>  xen/arch/x86/hvm/hvm.c              | 41 +++++++++++++----------------
>  xen/arch/x86/hvm/svm/intr.c         |  2 +-
>  xen/arch/x86/hvm/vmx/intr.c         |  2 +-
>  xen/arch/x86/include/asm/vm_event.h |  9 +++++++
>  5 files changed, 33 insertions(+), 27 deletions(-)

With this diffstat, I think the subject prefix is misleading (should perhaps
be x86/vm_event: or x86/hvm:).

> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -105,7 +105,7 @@ static int set_context_data(void *buffer, unsigned int size)
>  {
>      struct vcpu *curr = current;
>  
> -    if ( curr->arch.vm_event )
> +    if ( vm_event_is_enabled(curr) )
>      {
>          unsigned int safe_size =
>              min(size, curr->arch.vm_event->emul.read.size);
> @@ -771,7 +771,7 @@ static void *hvmemul_map_linear_addr(
>              ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
>          }
>  
> -        if ( unlikely(curr->arch.vm_event) &&
> +        if ( unlikely(vm_event_is_enabled(curr)) &&
>               curr->arch.vm_event->send_event &&
>               hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
>          {
> @@ -1870,7 +1870,7 @@ static int hvmemul_rep_outs_set_context(
>      int rc = X86EMUL_OKAY;
>  
>      ASSERT(bytes_per_rep <= 4);
> -    if ( !ev )
> +    if ( !vm_event_is_enabled(current) )
>          return X86EMUL_UNHANDLEABLE;

I wonder if in a case like this one the assignment (to ev) would better move
past the predicate check.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -532,7 +532,7 @@ void hvm_do_resume(struct vcpu *v)
>      if ( !vcpu_ioreq_handle_completion(v) )
>          return;
>  
> -    if ( unlikely(v->arch.vm_event) )
> +    if ( unlikely(vm_event_is_enabled(v)) )
>          hvm_vm_event_do_resume(v);
>  
>      /* Inject pending hw/sw event */
> @@ -546,11 +546,12 @@ void hvm_do_resume(struct vcpu *v)
>          v->arch.hvm.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
>      }
>  
> -    if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled )
> +    if ( unlikely(vm_event_is_enabled(v)) &&

With this, ...

> +         v->arch.monitor.next_interrupt_enabled )
>      {
>          struct x86_event info;
>  
> -        if ( hvm_get_pending_event(v, &info) )
> +        if ( hvm_get_pending_event(v, &info) && vm_event_is_enabled(v) )

... why this?

> @@ -2088,7 +2089,7 @@ int hvm_handle_xsetbv(u32 index, u64 new_bv)
>  {
>      int rc;
>  
> -    if ( index == 0 )
> +    if ( index == 0 && vm_event_is_enabled(current) )
>          hvm_monitor_crX(XCR0, new_bv, current->arch.xcr0);
>  
>      rc = x86emul_write_xcr(index, new_bv, NULL);
> @@ -2337,9 +2338,7 @@ int hvm_set_cr0(unsigned long value, bool may_defer)
>      if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
>                                 monitor_ctrlreg_bitmask(VM_EVENT_X86_CR0)) )
>      {
> -        ASSERT(v->arch.vm_event);
> -
> -        if ( hvm_monitor_crX(CR0, value, old_value) )
> +        if ( vm_event_is_enabled(v) && hvm_monitor_crX(CR0, value, old_value) )
>          {

I don't think assertions (here and below) should be replaced like this.
Can't you e.g. force "may_defer" to false at the top of the function when
vm_event_is_enabled() returns false?

> @@ -2462,9 +2461,8 @@ int hvm_set_cr3(unsigned long value, bool noflush, bool may_defer)
>      if ( may_defer && unlikely(currd->arch.monitor.write_ctrlreg_enabled &
>                                 monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
>      {
> -        ASSERT(curr->arch.vm_event);
> -
> -        if ( hvm_monitor_crX(CR3, value, curr->arch.hvm.guest_cr[3]) )
> +        if ( vm_event_is_enabled(curr) &&
> +             hvm_monitor_crX(CR3, value, curr->arch.hvm.guest_cr[3]) )
>          {
>              /* The actual write will occur in hvm_do_resume(), if permitted. */
>              curr->arch.vm_event->write_data.do_write.cr3 = 1;
> @@ -2544,9 +2542,7 @@ int hvm_set_cr4(unsigned long value, bool may_defer)
>      if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
>                                 monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4)) )
>      {
> -        ASSERT(v->arch.vm_event);
> -
> -        if ( hvm_monitor_crX(CR4, value, old_cr) )
> +        if ( vm_event_is_enabled(v) && hvm_monitor_crX(CR4, value, old_cr) )
>          {
>              /* The actual write will occur in hvm_do_resume(), if permitted. */
>              v->arch.vm_event->write_data.do_write.cr4 = 1;
> @@ -3407,7 +3403,7 @@ static enum hvm_translation_result __hvm_copy(
>              return HVMTRANS_bad_gfn_to_mfn;
>          }
>  
> -        if ( unlikely(v->arch.vm_event) &&
> +        if ( unlikely(vm_event_is_enabled(v)) &&
>               (flags & HVMCOPY_linear) &&
>               v->arch.vm_event->send_event &&
>               hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
> @@ -3538,6 +3534,7 @@ int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len)
>      struct vcpu *curr = current;
>      unsigned int leaf = regs->eax, subleaf = regs->ecx;
>      struct cpuid_leaf res;
> +    int ret = 0;
>  
>      if ( curr->arch.msrs->misc_features_enables.cpuid_faulting &&
>           hvm_get_cpl(curr) > 0 )
> @@ -3554,7 +3551,10 @@ int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len)
>      regs->rcx = res.c;
>      regs->rdx = res.d;
>  
> -    return hvm_monitor_cpuid(inst_len, leaf, subleaf);
> +    if ( vm_event_is_enabled(curr) )
> +        ret = hvm_monitor_cpuid(inst_len, leaf, subleaf);
> +
> +    return ret;
>  }
>  
>  void hvm_rdtsc_intercept(struct cpu_user_regs *regs)
> @@ -3694,9 +3694,8 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content,
>          if ( ret != X86EMUL_OKAY )
>              return ret;
>  
> -        ASSERT(v->arch.vm_event);
> -
> -        if ( hvm_monitor_msr(msr, msr_content, msr_old_content) )
> +        if ( vm_event_is_enabled(v) &&
> +             hvm_monitor_msr(msr, msr_content, msr_old_content) )
>          {
>              /* The actual write will occur in hvm_do_resume(), if permitted. */
>              v->arch.vm_event->write_data.do_write.msr = 1;
> @@ -3854,12 +3853,10 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
>      struct vcpu *curr = current;
>      struct domain *currd = curr->domain;
>  
> -    if ( currd->arch.monitor.descriptor_access_enabled )
> -    {
> -        ASSERT(curr->arch.vm_event);
> +    if ( currd->arch.monitor.descriptor_access_enabled &&
> +         vm_event_is_enabled(curr) )
>          hvm_monitor_descriptor_access(exit_info, vmx_exit_qualification,
>                                        descriptor, is_write);
> -    }
>      else if ( !hvm_emulate_one_insn(is_sysdesc_access, "sysdesc access") )
>          domain_crash(currd);

Following "xen: consolidate CONFIG_VM_EVENT" this function is actually unreachable
when VM_EVENT=n, so no change should be needed here. It's instead the unreachability
which needs properly taking care of (to satisfy Misra requirements) there.

> --- a/xen/arch/x86/hvm/svm/intr.c
> +++ b/xen/arch/x86/hvm/svm/intr.c
> @@ -130,7 +130,7 @@ void asmlinkage svm_intr_assist(void)
>      enum hvm_intblk intblk;
>  
>      /* Block event injection while handling a sync vm_event. */
> -    if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
> +    if ( unlikely(vm_event_is_enabled(v)) && v->arch.vm_event->sync_event )
>          return;
>  
>      /* Crank the handle on interrupt state. */
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index b35dc8c586..a8ced95871 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -239,7 +239,7 @@ void asmlinkage vmx_intr_assist(void)
>      }
>  
>      /* Block event injection while handling a sync vm_event. */
> -    if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event )
> +    if ( unlikely(vm_event_is_enabled(v)) && v->arch.vm_event->sync_event )
>          return;
>  
>  #ifdef CONFIG_MEM_SHARING
> diff --git a/xen/arch/x86/include/asm/vm_event.h b/xen/arch/x86/include/asm/vm_event.h
> index 46e77ed6d9..446d02c7d5 100644
> --- a/xen/arch/x86/include/asm/vm_event.h
> +++ b/xen/arch/x86/include/asm/vm_event.h
> @@ -45,4 +45,13 @@ void vm_event_sync_event(struct vcpu *v, bool value);
>  
>  void vm_event_reset_vmtrace(struct vcpu *v);
>  
> +static inline bool vm_event_is_enabled(struct vcpu *v)
> +{
> +#ifdef CONFIG_VM_EVENT
> +    return v->arch.vm_event != NULL;

Is "enabled" (in the function name) a good description of this condition, Tamas?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 07:34:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 07:34:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121553.1465783 (Exim 4.92)
	(envelope-from )
	id 1uwyIb-0000nw-1p; Fri, 12 Sep 2025 07:34:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121553.1465783; Fri, 12 Sep 2025 07:34: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 1uwyIa-0000np-VZ; Fri, 12 Sep 2025 07:34:24 +0000
Received: by outflank-mailman (input) for mailman id 1121553;
 Fri, 12 Sep 2025 07:34: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 1uwyIZ-0000nj-KP
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 07:34:23 +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 e5f5b9d9-8faa-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 09:34:21 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-b0418f6fc27so271179066b.3
 for ; Fri, 12 Sep 2025 00:34: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
 a640c23a62f3a-b07b33478e4sm303481166b.96.2025.09.12.00.34.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 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: e5f5b9d9-8faa-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757662461; x=1758267261; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Zx+F00AEOde4cYO30/QXLuJvTThR4MJ7BuHCJG0MFUI=;
        b=M9///Qxh/Xvg9nwGUQ9P0j1snaLXMtixeC78QdzS4ZbqK6Wfte/kh/Uzee5a89C7it
         xYSRJwTvaoQNWQJ8BsHTCrxnMd6SaDJmdIdG3COzLUParxP6+B1oLTq75JlAEpJ0Cszi
         bLtQr3nV5GV7YonCIEONHeAcoUsZ/kvOHHGg0gPrki68Qq8WhXSVyYKOMvQ2ZfF1mhMJ
         Otj+QN8B6uapFL3pCRmjPtQJqYNNKXNDQciuZiBGOKUkRAAPb40ZwPShAiRFSBIycY/e
         sX99gJI6XY/yPcEVOWciv1aczfciNx/ZpdYeZpx8YQVOiVCfA3s9HD1L8ve/K+GCqRaG
         I/HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757662461; x=1758267261;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Zx+F00AEOde4cYO30/QXLuJvTThR4MJ7BuHCJG0MFUI=;
        b=LQpFg59KMeUfUekaFhm8nby7C6pWuK02PjZu7PNN+3KRboX+Ew9ugRkKo3ElV7ITXE
         f8BgZd+yD4BWZevLOElFftlfY10MTbkyq9gLFLXc9DjrO2oTgmyWdUi5M+eljJnNdAvr
         Uel95d+ERHYwuigiv+TfLJA31yLRAY1VmQ5qvo7rnOSTDXNdPhP0Ewia0nxvog5f+2dN
         51hu23atha3uzGUJ7QEdU1cXcETuSgfSGZ6wJhpw9KeRyKliAptoTzSCs8ycTy6N2z2R
         o9RVzHZqciIzgl1Q0FbkpDtTU08w0Yp5b+21+cnx2xWbItbDgDpQGrfx0GjsF/Il6vqm
         +aQQ==
X-Forwarded-Encrypted: i=1; AJvYcCVqIXTzqEJ8be8+VREyZpeDhcIFHTDkuUQ1OhKNVVBw9UQD3bMkWSChBKEIAfKPtatK6pOEjAP2CXE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9dULscJZMSexeM5FMbA712u7jnAuHHzggzrgqUUyI1QZLXxuB
	m8pkZwp2GHySuypXokauEgaqOWHzBAc/V4m/js/XPZzaacfsscPmMKLy/6Wr/jkMag==
X-Gm-Gg: ASbGncv7mGOodvN8GqqE6X5lWWHHTM/EtoZlTPsmjvagdL6bkN/Oys2J/ncqLYHOReL
	HXbDajDsWsPzRmxtfhxAvk9Zwnv7JewfOFz3DyYpOq4jDIsO9ok2DydBMKT5mqOuUo1krKKVMCd
	CWzdNLxIaWUgfDwE+coa8x+m4vW+2JqGkgsrGc0Sfki3DlEkOSnIhLndHVMAK6eJc0jihUr2Vu/
	wlTGdrWRXNl3fxQ+2sIodn9TNFYAflFaeHWm7KLagOCS+13js8wkpt5U+fLuAx22wfQtq8trGk1
	0N/QD4y4n0iuO/OwBTvYip7MqUaTjhJhnexIezgXPlvWRX95+RAbyGvOh5F44f/4xb+iPth2uAy
	TIF1uUxQqJg4WuKAC8/vj5pEos+3zZJiFJdjIrzAo3VFWkO3GQ7vR5tB8SzjcuL69dnEIRH2J72
	1JLLNyhp0=
X-Google-Smtp-Source: AGHT+IGC3n9FQ8CRAkQaABFzd2YTSR/FuqVCzRGdMdwEPElV45vHOx47uhzQlXJSwzMlZeVyoDy1RA==
X-Received: by 2002:a17:907:2d20:b0:b04:74d1:a561 with SMTP id a640c23a62f3a-b07c34d63f1mr215449266b.25.1757662460813;
        Fri, 12 Sep 2025 00:34:20 -0700 (PDT)
Message-ID: <17003bf5-4005-4ff1-8e8f-26bfe39e7e6b@suse.com>
Date: Fri, 12 Sep 2025 09:34:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/26] xen/domctl: wrap domain_soft_reset() with
 CONFIG_MGMT_HYPERCALLS
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 "Orzel, Michal" ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Christopher Clark ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-9-Penny.Zheng@amd.com>
 <4be69331-8002-47a3-a2e1-e34b12a5c5bb@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.09.2025 09:18, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, September 10, 2025 11:14 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Stefano Stabellini
>> ; Julien Grall ; Bertrand Marquis
>> ; Orzel, Michal ;
>> Volodymyr Babchuk ; Andrew Cooper
>> ; Anthony PERARD ;
>> Roger Pau Monné ; Christopher Clark
>> ; Daniel P. Smith
>> ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v2 08/26] xen/domctl: wrap domain_soft_reset() with
>> CONFIG_MGMT_HYPERCALLS
>>
>> On 10.09.2025 09:38, Penny Zheng wrote:
>>> Function domain_soft_reset() is responsible for domain soft reset
>>> domctl-op, and shall be wrapped with CONFIG_MGMT_HYPERCALLS Tracking
>>> its calling chain, and the following functions shall also be wrapped
>>> with CONFIG_MGMT_HYPERCALLS:
>>> - grant_table_warn_active_grants()
>>> - argo_soft_reset()
>>> - arch_domain_soft_reset()
>>> Wrap XEN_DOMCTL_soft_reset-case transiently with
>>> CONFIG_MGMT_HYPERCALLS, and it will be removed when introducing
>>> CONFIG_MGMT_HYPERCALLS on the common/domctl.c in the last.
>>>
>>> Signed-off-by: Penny Zheng 
>>> ---
>>> v1 -> v2:
>>> - remove unnessary wrapping in stub.c
>>> - adapt to changes of "unify DOMCTL to MGMT_HYPERCALLS"
>>> - wrap XEN_DOMCTL_soft_reset-case transiently
>>> ---
>>>  xen/arch/arm/domain.c    | 2 ++
>>>  xen/arch/x86/domain.c    | 2 ++
>>
>> What about PPC and RISC-V? They have the function in stubs.c, but not adding the
>> #ifdef there increases the chance that when the stubs are replaced by real
>> functions, the intended #ifdef might then be forgotten to add.
> 
> As we are addressing concerns on the v1 about editing stubs.c files [1], I removed them all in this patch serie. If they are considered necessary now, I'll add them back in next version
> [1] https://lists.xenproject.org/archives/html/xen-devel/2025-08/msg00135.html

Hmm, looks like I changed my perspective, previously not having taken into account
the aspect mentioned above. I'm sorry for the back and forth. And yes, it is on
the edge, seeing also what Stefano said. I guess I should say "okay either way,
with (now) a slight preference to also adding the #ifdef-s there".

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 08:04:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 08:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121584.1465795 (Exim 4.92)
	(envelope-from )
	id 1uwylg-0005cP-BL; Fri, 12 Sep 2025 08:04:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121584.1465795; Fri, 12 Sep 2025 08:04: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 1uwylg-0005cI-79; Fri, 12 Sep 2025 08:04:28 +0000
Received: by outflank-mailman (input) for mailman id 1121584;
 Fri, 12 Sep 2025 08:04: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 1uwylf-0005cC-6n
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 08:04:27 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 158536a9-8faf-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 10:04:20 +0200 (CEST)
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
 [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-278-JBaaB5lePNWwfXOX_Kjfpw-1; Fri, 12 Sep 2025 04:04:17 -0400
Received: by mail-wm1-f70.google.com with SMTP id
 5b1f17b1804b1-45de27bf706so7653985e9.0
 for ; Fri, 12 Sep 2025 01:04:17 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f20:da00:b70a:d502:3b51:1f2d?
 (p200300d82f20da00b70ad5023b511f2d.dip0.t-ipconnect.de.
 [2003:d8:2f20:da00:b70a:d502:3b51:1f2d])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e0157619fsm55845035e9.7.2025.09.12.01.04.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 01:04: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: 158536a9-8faf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757664259;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=H5X75pHcHAnEM8zcD7ykTJjL5glq6wg6eQ+1uRSxWa4=;
	b=eaVxy06RIZK7fFnh8SLhx7CZtgyZI1I+YLuNK22L3tuXu/6kvI4gU7wrol7FHQjXz8O8bz
	jDgw19n6OIyoZR/emx+ieW/H4g9wDNVFAgs3Z0QuwozRE6b8bhagY4uKTU2jZr6To4NZg7
	7COUaSR8wnMhc10mMpTfpa5DLV+8Yn0=
X-MC-Unique: JBaaB5lePNWwfXOX_Kjfpw-1
X-Mimecast-MFC-AGG-ID: JBaaB5lePNWwfXOX_Kjfpw_1757664256
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757664256; x=1758269056;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=H5X75pHcHAnEM8zcD7ykTJjL5glq6wg6eQ+1uRSxWa4=;
        b=mVe5xoWrLsLbrnogPr9e2no975K5dveROG07Sqrh88BfriX8kl4kfudZcTxtCFMlIt
         otHRHOX29bq+693hT7z39915jrMeQnyhTtpsl88zJfhc2IAf0VPJjfqhY2p/FBW7gE+y
         FzoG4J3bkTiUBjFvzcAS0Dk8yev58MfZYyBHx3I2U1JS6e1vZKKwFph3G8VMu8WzOGZr
         Jmv4Z2yfvFrmiFQEIgG5LQxUVyjL+M0O0GV8XvB+n4UMPgKkN36Dl9xQ0Vd/tJyQkHOv
         NxM/htTwEdi1guTz31XGlHESIzL158npVJ0Sgsv9xRxDYt68Y4WdsylEhGzfNX/SZlXG
         L61A==
X-Forwarded-Encrypted: i=1; AJvYcCUuu2fT5cxWE2tKgpeXvqeNZN5/NQeED0w2aPYBJZOsmEORr9kTWgH0eUkOOy2SlLFBtFDnVmdohwY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxPLlGAaSPyThzA1zyFNXo0XSQnQYpOZs2kgBuWIdPRP9IW2x/F
	Qhi3BUCLMVB/l944FWw5830wPVQQ0OHLZER21JmmuPzfr3RqCmQdzJLnK1d/5F1gUIOCRaBj2E2
	mhKEC7peLLRdnwD13SBf8Rap+384E6mT/I6p1rkZKJVVcRnTtI+i50O97+mVcf4C7xcBO
X-Gm-Gg: ASbGncu31B/OqpS1nEg9XII+ztl7y1pM34FQZJQcDrhz7+EUxVNSoWSNmi2LU9O2e2K
	afY9PhhZI/FqpvbF+CiZbcQVCSqObpmLdaEN+yCxrE5wPMh6PrNxcociyH4kTiN2vQmjweFxBiR
	QQbYHcOnLiqIReyNXoW/o5uuLn2CZ8PeSL+s71y88XhuURLJW6VJM6h09Zjd4g6RSaBU+LjIGB/
	W+jD0S5nsc3sspVr9PvO543B2XnGhqCspjwOzClfYM1hOPGrHQor0MuDh0FNLF3ATEEUoBcdiG8
	xwE6f7hS5rhgrLX1/MZ6C+OiEMLqWfptE+Shhgklv6P+p0v2rTSPis61Zy0KdzYKb9wLom3KIku
	Pb4jN+UlOfoH6NFhlPzwOHyAieXjjp+PW3P/7AqmKm+q+XbELpya/9a4SSdSGa9tjdbY=
X-Received: by 2002:a05:600c:3b85:b0:45f:2207:ab2a with SMTP id 5b1f17b1804b1-45f25476d29mr270035e9.27.1757664255921;
        Fri, 12 Sep 2025 01:04:15 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IH6B4WHtwQniBOXl9TNxrOEZZoyaGGED6LI1RYVbwr7AHnntDCVEJCDe9m05fXcYWcUrUbEPw==
X-Received: by 2002:a05:600c:3b85:b0:45f:2207:ab2a with SMTP id 5b1f17b1804b1-45f25476d29mr269475e9.27.1757664255404;
        Fri, 12 Sep 2025 01:04:15 -0700 (PDT)
Message-ID: <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
Date: Fri, 12 Sep 2025 10:04:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: ZOac_nCd_ijjiY09n0M2GOr9Ybg-ldBAWtl1k-9bG2o_1757664256
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

>>
>> struct lazy_mmu_state {
>>      uint8_t enabled_count;
>>      bool paused;
> 
> Looking at the arm64 implementation, I'm thinking: instead of the paused
> member, how about a PF_LAZY_MMU task flag? It would be set when lazy_mmu
> is actually enabled (i.e. inside an enter()/leave() section, and not
> inside a pause()/resume() section). This way, architectures could use
> that flag directly to tell if lazy_mmu is enabled instead of reinventing
> the wheel, all in slightly different ways. Namely:
> 
> * arm64 uses a thread flag (TIF_LAZY_MMU) - this is trivially replaced
> with PF_LAZY_MMU
> * powerpc and sparc use batch->active where batch is a per-CPU variable;
> I expect this can also be replaced with PF_LAZY_MMU
> * x86/xen is more complex as it has xen_lazy_mode which tracks both
> LAZY_MMU and LAZY_CPU modes. I'd probably leave that one alone, unless a
> Xen expert is motivated to refactor it.
> 
> With that approach, the implementation of arch_enter() and arch_leave()
> becomes very simple (no tracking of lazy_mmu status) on arm64, powerpc
> and sparc.
> 
> (Of course we could also have an "enabled" member in lazy_mmu_state
> instead of PF_LAZY_MMU, there is no functional difference.)
> 

No strong opinion, but to me it feels like PF_LAZY_MMU is rather "the 
effective state when combining nested+paused", and might complicate the 
code + sanity checks?

So we could maintain that in addition fairly easily of course from the 
core instead of letting archs do that manually.

I would probably have to see the end result to judge whether removing 
the "paused" bool makes things look more complicated or not.

>> }
>>
>> c) With that config, common-code lazy_mmu_*() functions implement the
>> updating of the lazy_mmu_state in task_struct and call into arch code
>> on the transition from 0->1, 1->0 etc.
> 
> Indeed, this is how I thought about it. There is actually quite a lot
> that can be moved to the generic functions:
> * Updating lazy_mmu_state
> * Sanity checks on lazy_mmu_state (e.g. underflow/overflow)
> * Bailing out if in_interrupt() (not done consistently across arch's at
> the moment)
> 
>>
>> Maybe that can be done through exiting
>> arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode() callbacks, maybe
>> we need more. I feel like
>> we might be able to implement that through the existing helpers.
> 
> We might want to rename them to align with the new generic helpers, but
> yes otherwise the principle should remain unchanged.
> 
> In fact, we will also need to revive arch_flush_lazy_mmu_mode().

That's okay if it's all hidden behaind a sane core API.

> Indeed,
> in the nested situation, we need the following arch calls:
> 
> enter() -> arch_enter()
>      enter() -> [nothing]
>      leave() -> arch_flush()
> leave() -> arch_leave()
> 
> leave() must always flush whatever arch state was batched, as may be
> expected by the caller.
> 
> How does all that sound?

I am no expert on the "always flush when leaving", but it sounds 
reasonable to me.

Which arch operations would you call from

pause()
continue()

?

>> And on top of the proposal above we will have some
>>
>> struct arch_lazy_mmu_state;
>>
>> define by the architecture (could be an empty struct on most).
>>
>> We can store that inside "struct lazy_mmu_state;" or if we ever have
>> to, start returning only that from the enable/disable etc. functions.
> 
> I'm not sure we'd want to mix those styles (task_struct member + local
> variable), that's adding complexity without much upside... Also having a
> local variable at every nesting level only makes sense if we have an
> arch callback regardless of nesting level, which is unnecessary in this
> proposed API.

Yes, that was rather a "if we ever really run out of space we could look 
into that", I am not a fan of it obviously.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 08:48:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 08:48:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121632.1465807 (Exim 4.92)
	(envelope-from )
	id 1uwzSW-0002sF-Gy; Fri, 12 Sep 2025 08:48:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121632.1465807; Fri, 12 Sep 2025 08:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uwzSW-0002s8-EK; Fri, 12 Sep 2025 08:48:44 +0000
Received: by outflank-mailman (input) for mailman id 1121632;
 Fri, 12 Sep 2025 08:48: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 1uwzSV-0002s2-09
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 08:48:43 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 45ac883a-8fb5-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 10:48:37 +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 4134416A3;
 Fri, 12 Sep 2025 01:48:28 -0700 (PDT)
Received: from [10.57.66.147] (unknown [10.57.66.147])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 63FC83F66E;
 Fri, 12 Sep 2025 01: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: 45ac883a-8fb5-11f0-9809-7dc792cee155
Message-ID: <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
Date: Fri, 12 Sep 2025 10:48:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/09/2025 10:04, David Hildenbrand wrote:
>>>
>>> struct lazy_mmu_state {
>>>      uint8_t enabled_count;
>>>      bool paused;
>>
>> Looking at the arm64 implementation, I'm thinking: instead of the paused
>> member, how about a PF_LAZY_MMU task flag? It would be set when lazy_mmu
>> is actually enabled (i.e. inside an enter()/leave() section, and not
>> inside a pause()/resume() section). This way, architectures could use
>> that flag directly to tell if lazy_mmu is enabled instead of reinventing
>> the wheel, all in slightly different ways. Namely:
>>
>> * arm64 uses a thread flag (TIF_LAZY_MMU) - this is trivially replaced
>> with PF_LAZY_MMU
>> * powerpc and sparc use batch->active where batch is a per-CPU variable;
>> I expect this can also be replaced with PF_LAZY_MMU
>> * x86/xen is more complex as it has xen_lazy_mode which tracks both
>> LAZY_MMU and LAZY_CPU modes. I'd probably leave that one alone, unless a
>> Xen expert is motivated to refactor it.
>>
>> With that approach, the implementation of arch_enter() and arch_leave()
>> becomes very simple (no tracking of lazy_mmu status) on arm64, powerpc
>> and sparc.
>>
>> (Of course we could also have an "enabled" member in lazy_mmu_state
>> instead of PF_LAZY_MMU, there is no functional difference.)
>>
>
> No strong opinion, but to me it feels like PF_LAZY_MMU is rather "the
> effective state when combining nested+paused", and might complicate
> the code + sanity checks?
>
> So we could maintain that in addition fairly easily of course from the
> core instead of letting archs do that manually.
>
> I would probably have to see the end result to judge whether removing
> the "paused" bool makes things look more complicated or not.

Agreed, it is a little difficult to consider all the cases ahead of
time. What is clear to me though is that [paused] can be inferred from
[count + enabled], and conversely [enabled] from [count + paused]. As a
result I really wouldn't store both paused and enabled in task_struct -
duplicating information is how you create inconsistent states.

We can very easily introduce helpers to get the enabled/paused status
regardless of how they're stored. Since "enabled" is what we need to
know in most cases (arch checking the status), I would rather store
"enabled" than "paused". But indeed, let's see how it turns out in practice.

>
>>> }
>>>
>>> c) With that config, common-code lazy_mmu_*() functions implement the
>>> updating of the lazy_mmu_state in task_struct and call into arch code
>>> on the transition from 0->1, 1->0 etc.
>>
>> Indeed, this is how I thought about it. There is actually quite a lot
>> that can be moved to the generic functions:
>> * Updating lazy_mmu_state
>> * Sanity checks on lazy_mmu_state (e.g. underflow/overflow)
>> * Bailing out if in_interrupt() (not done consistently across arch's at
>> the moment)
>>
>>>
>>> Maybe that can be done through exiting
>>> arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode() callbacks, maybe
>>> we need more. I feel like
>>> we might be able to implement that through the existing helpers.
>>
>> We might want to rename them to align with the new generic helpers, but
>> yes otherwise the principle should remain unchanged.
>>
>> In fact, we will also need to revive arch_flush_lazy_mmu_mode().
>
> That's okay if it's all hidden behaind a sane core API.
>
>> Indeed,
>> in the nested situation, we need the following arch calls:
>>
>> enter() -> arch_enter()
>>      enter() -> [nothing]
>>      leave() -> arch_flush()
>> leave() -> arch_leave()
>>
>> leave() must always flush whatever arch state was batched, as may be
>> expected by the caller.
>>
>> How does all that sound?
>
> I am no expert on the "always flush when leaving", but it sounds
> reasonable to me.

This is a core expectation for lazy_mmu: when leave() is called, any
batched state is flushed. The fact it currently happens unconditionally
when calling leave() is in fact what stops nesting from exploding on
arm64 with DEBUG_PAGEALLOC [1].

[1] https://lore.kernel.org/all/aEhKSq0zVaUJkomX@arm.com/

>
> Which arch operations would you call from
>
> pause()
> continue()

I also wondered about that. I think the safest is to make them
respectively arch_leave() and arch_enter() - the flushing entailed by
arch_leave() might not be required, but it is safer. Additionally,
powerpc/sparc disable preemption while in lazy_mmu, so it seems like a
good idea to re-enable it while paused (by calling arch_leave()).

- Kevin


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 08:56:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 08:56:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121649.1465818 (Exim 4.92)
	(envelope-from )
	id 1uwzZY-0004Tr-BR; Fri, 12 Sep 2025 08:56:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121649.1465818; Fri, 12 Sep 2025 08:56: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 1uwzZY-0004Tk-8U; Fri, 12 Sep 2025 08:56:00 +0000
Received: by outflank-mailman (input) for mailman id 1121649;
 Fri, 12 Sep 2025 08:55: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 1uwzZX-0004TO-9F
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 08:55:59 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b8e255c-8fb6-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 10:55:57 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-513-WZd0XfxAPsCGU7gPlgZL-A-1; Fri, 12 Sep 2025 04:55:54 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-45de27bf706so7924275e9.0
 for ; Fri, 12 Sep 2025 01:55:54 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f20:da00:b70a:d502:3b51:1f2d?
 (p200300d82f20da00b70ad5023b511f2d.dip0.t-ipconnect.de.
 [2003:d8:2f20:da00:b70a:d502:3b51:1f2d])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e037c3ce5sm54255495e9.16.2025.09.12.01.55.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 01:55: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: 4b8e255c-8fb6-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757667356;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=yhSXL+2pa9oDbDGRuQ4gQlpl18vQ+30/sPKc3K6z7Uo=;
	b=IveBiTgu6K6wb46I3mtmTdpkQZdEaqeL7kwT/a8yxdSlKW8E78iZo7pxHlYZUQtPHxFiux
	ab9FzjtoPCb2eSDilf1UonpvzWM9HIJYBUUXLpll/e4fZlMu3/EBp+6NQjhHgc7kmlbz7v
	K1OjrPcQbN3bxuuhO2kLH+8V/cZFQEk=
X-MC-Unique: WZd0XfxAPsCGU7gPlgZL-A-1
X-Mimecast-MFC-AGG-ID: WZd0XfxAPsCGU7gPlgZL-A_1757667353
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757667353; x=1758272153;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=yhSXL+2pa9oDbDGRuQ4gQlpl18vQ+30/sPKc3K6z7Uo=;
        b=BWdEALMPGS2lPFKun9hMdy43tT1FhHpZs5UFWrV+U6ldI0AVUiQp/x34LWrkqw00UJ
         Huv04Zzy5TtlWGuFHBqTCCqGThJQf37HKgCagxpOPVuSQhzy3byU9pH0vxYmVVZIMiIC
         BKGf1PCuVv/4CPK5M3XCCo0QJBF2T0WXIh/+i+KpG7D+FSiyMqrP2ntO9R6MjefmLAl8
         qcG1mg2XGKXsULv3EuwWnew11+IM/gzauclw6DksMwA/Mdr/EECIhfQk4OCuAizLc8kA
         CsySt9zRfbVURqEfdbkN8G2Mc22PTRhstN5U3RF7fBXnevNwrvrpQ0xYyX/k50cmH/MJ
         C1GA==
X-Forwarded-Encrypted: i=1; AJvYcCXhZ1xy/vCdSZ+qUwrnAbzEBABXub/dTeNE/EhtIJzpwZwBuBRtfEHQ6dlBPgQIV0ELtzijsL7dKmQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmmPaWawYityUDX77VkfldYAGnKM8bvze0eyFhbZmOee95G0bW
	AyF8qQX3iCTLRmqrhCUh82LqIWjteMQFLeWsnrgl/gkem6QTYKSweOeC5v2SB2xKULdPlvU8HUx
	SmtBkmoDh8aKW4+B1uAaieEcA6UnW7khGZZbt8nEgGtGAbEnGNqCz5mJkTbq8V+wgAOk2
X-Gm-Gg: ASbGncum2hdRW7q0E/wDqtIIxQMDVsNvPkyOKDhVc02TuMdSHiGX1iOk5xqk5bzpGgw
	v4BRL64p55QBus2xyrDkMB/YOa/vb0Z9MDvrQ7s7cEGhFx2iS2gaI8De+QwKmJm2Tviv39Fkp84
	TE2MC1ieylXYs+BxuWijbDG92A9YnUhlpQRZPw1ymgP7wxhjkx+QmXnQweSoVgYpkhTxXbiA1c5
	fQqIAmVOF9HPEu5qIjCe/A9+mg1YpLQukFF+2ewyCU3q9Ln8/JQHGf3btY7xGl5cVQC3PQnofir
	ZjoOp/gavOVmduUrOZetuVNfQ7eQjMhpy9UDS8GkGwrhSFHjVV0rUXmkUaSfESxgBH5KATFZz8S
	FQm1B3soLFBaRVTAj+hg36UlEA7CJD3fmvDfAFz2ndkiuUbV1RT/GKVA6DxFoaKEMw08=
X-Received: by 2002:a05:600c:228f:b0:45b:6743:2242 with SMTP id 5b1f17b1804b1-45f211f86c5mr15325655e9.22.1757667353212;
        Fri, 12 Sep 2025 01:55:53 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGWDKbJzbJR4/u84XZSgPwx14/k9hN3sfQaLT2TQm5sKZh16Dp+Cgzni1IYyZJBI43U7rR/8A==
X-Received: by 2002:a05:600c:228f:b0:45b:6743:2242 with SMTP id 5b1f17b1804b1-45f211f86c5mr15325425e9.22.1757667352826;
        Fri, 12 Sep 2025 01:55:52 -0700 (PDT)
Message-ID: 
Date: Fri, 12 Sep 2025 10:55:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Kevin Brodsky ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908073931.4159362-3-kevin.brodsky@arm.com>
 
 
 
 <2fecfae7-1140-4a23-a352-9fd339fcbae5-agordeev@linux.ibm.com>
 
 <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: S2oBC5TC8OPOVXYJvwtK0_523Yf68u42krkOQnsYllY_1757667353
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


> I also wondered about that. I think the safest is to make them
> respectively arch_leave() and arch_enter() - the flushing entailed by
> arch_leave() might not be required, but it is safer. Additionally,
> powerpc/sparc disable preemption while in lazy_mmu, so it seems like a
> good idea to re-enable it while paused (by calling arch_leave()).

Great, looking forward to seeing this all getting cleaned up and done 
properly for good.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 09:33:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 09:33:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121692.1465827 (Exim 4.92)
	(envelope-from )
	id 1ux09G-0001FV-Vh; Fri, 12 Sep 2025 09:32:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121692.1465827; Fri, 12 Sep 2025 09:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux09G-0001FO-Sj; Fri, 12 Sep 2025 09:32:54 +0000
Received: by outflank-mailman (input) for mailman id 1121692;
 Fri, 12 Sep 2025 09:32: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 1ux09G-0001FI-5Q
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 09:32:54 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2009::61f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73ee666f-8fbb-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 11:32:52 +0200 (CEST)
Received: from DS7PR03CA0020.namprd03.prod.outlook.com (2603:10b6:5:3b8::25)
 by DM6PR12MB4204.namprd12.prod.outlook.com (2603:10b6:5:212::23) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Fri, 12 Sep
 2025 09:32:49 +0000
Received: from CY4PEPF0000E9D7.namprd05.prod.outlook.com
 (2603:10b6:5:3b8:cafe::b8) by DS7PR03CA0020.outlook.office365.com
 (2603:10b6:5:3b8::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.18 via Frontend Transport; Fri,
 12 Sep 2025 09:32:48 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000E9D7.mail.protection.outlook.com (10.167.241.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Fri, 12 Sep 2025 09:32:48 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 12 Sep
 2025 02:32:47 -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: 73ee666f-8fbb-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ERzt3ygZZ+3B+prWgvsEEeI1SCNuR+J8AlBxMbw7pPXKd5EYZZsYXcrLHxOhtf6KGkbcTy6lNqIPTvJrx5BImkZRWA4tHsuvtmuNXYtG5XRg8ne49UsVY009JZH9R0SFVNBuFifW0sjISdAb5TyoXnf9nvoksNW+gRvGv2GpC0/8giZSKXCF/n0u9YVMAVplNECGYrk/Igt5lQbNojXFq1cBCuRGKXhWwbVEP8wu1KfcNmCPNmYCyz7AE7Ayq5pFJkhjciJMjPr/9gbFLXzprLPa+bO6RJLhMslzgcikqfTwhze60U0sc+lbMmDeXXe98/qVcbfWUTMdwxab3fIP+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=dCyprfv3sjr3a6DlPE2wBcwa510YmRrToiggLr1oa5E=;
 b=cjZWiQ3xKEL8Y+8V83DD75UY/1UYw+e0CVo9otlJdgVrR121vdgF8fyxuHqaUAICRWk6y09oJ6k8EcNbRf10OLerI0BgEtU5BDdJKG6gb1Gf1oXFtuYbcGvqA70NnGtaAmMB+yXp7Q1k5p7QXebKi9QvmUzSxxzVzkqZsFE1Kj8gDbg1AJhTYT0VN3DLVJeFLvQTiY6RmR0e1sPmnQNXiaEFEHD/vVSskze5tmRgDi79olvXJ6fWt04X9VFtemx39xGcj3kn89/6phRw8FD5n3rLfLNiULJip9/pSn/EBII+gZ6l7+yArwq59hUQ+ir+ibHbRk29Fkpro0EJEjmYzw==
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=dCyprfv3sjr3a6DlPE2wBcwa510YmRrToiggLr1oa5E=;
 b=4RYQWMm/Wzr1yv+AXhVFezJVjyd+woOaAW8WxdaeCbjR+rlx9qwoTqT92tIr2unROg8vIRq7z8jiDHebqJCtsmLdWaseo4yhAA9ME7WUIDQFaunml7k7yMRSE+vQWzG1wHOREiPxAcrlIHfM7+l2FyabghSxcXh7DC3rPW2+yns=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 12 Sep 2025 11:32:45 +0200
Message-ID: 
CC: Anthony PERARD , Grygorii Strashko
	, 
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
 <20250911162336.23887-2-alejandro.garciavallejo@amd.com>
 <4b958afe-dfcd-4ac0-bc09-468e2b9b2710@suse.com>
In-Reply-To: <4b958afe-dfcd-4ac0-bc09-468e2b9b2710@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D7:EE_|DM6PR12MB4204:EE_
X-MS-Office365-Filtering-Correlation-Id: 3958e738-bd22-42d5-fc23-08ddf1df5631
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WDdFa0pza1pRbmNwbFd6ekZiOTNSVFBwN21Fa2o5bHc5cThpNWdjMjVSTzhy?=
 =?utf-8?B?aFhkQnNBVmpqVUkvQi9KWmNXOUJjbUxSZW5tcmJjc0YxSHVHbHpINkRwc21h?=
 =?utf-8?B?dXZmaVdsUFlsanROSnA1cXhXd1ZWdVdheGRyVHVaeUw1SC90TzM5MjM3aFpG?=
 =?utf-8?B?OHFKU28xa0g1TWxIazFoMjJhaWxHRlZZVzhId2hpMlN0cHR2SkJlSjk5NEJE?=
 =?utf-8?B?ejhqNnhmWnpyUjRCMzBkcktndDFRWDRUbVlHVkI2akd0dzV6ekEzSENva3lm?=
 =?utf-8?B?SEZqK1JtRWc0cWNHUklnL0plTjhPSGhleERCcUl1c3JJalNUR0xQb3A2Y0My?=
 =?utf-8?B?N1hla3k1NjhZbC93d08xT0s0cXdrYWJkYmM3UjJUMERsOW8rekpSM09VdTNP?=
 =?utf-8?B?dEQ2WmlkTkwxcmZJeC9EYkV0Qm9LQmtmUXpybnhNTk1jVk1CZUVQWFpGWm02?=
 =?utf-8?B?ZnhDcGVzdUJzK1NBZXpVK05TcmYvTlJXZ3JnTk1KNlRKUW94eVBOSzFnKzUr?=
 =?utf-8?B?K2FScm5tQzNPTWp6SDBlZlVITG1jQnRwVG1pWGZvaWFnMEJ5N2dMTEw2aXla?=
 =?utf-8?B?NHIxWE5QeE5IQlNzTWxTS1FmdlhJUFVWRUI4RjdoQmpOZGF0Q2p0Skt1dmVr?=
 =?utf-8?B?RXhTVk4reUlpSWR5QjZ3NG9nazQ0cEtaQ2g5cWRCcnFSMDcycUQyY1FyaFcx?=
 =?utf-8?B?ZC9LQzVVTVBwcEMvYTE3ZGVjWmE3Q2VncWFEcGRYclJhcTA2SzcvNWFha3FW?=
 =?utf-8?B?Q3NmeUZtcmcwdWRxdjhkUTlYTXZOUDlUNVZsb0VtanpiN0Y1U1NDQWlKcWVl?=
 =?utf-8?B?a2ExK2JMSkxpUk9zZXBLV0taQVlrenRSY3ZXYk40UStTL3ZHNDZaSG1kTldW?=
 =?utf-8?B?QkhBL0J6L2FBeWw1UHJweG45Q3RxamJTTGNSNXNvb2N1bWVlQmhCK3hWRXNt?=
 =?utf-8?B?UGd0UlFsTTNEaGRFbkVFaHoxNkkwNndLb2NEcWx4RVFpVC9nbnByck1aenNl?=
 =?utf-8?B?U1kzZUxYQjlxb0kxZEp3Q1VaOG9OcVc2YVhZU1FkS1NDbUFTUjZQdnp0ZVdH?=
 =?utf-8?B?djl2RzQzZXNqczNqQStXWUR5RkZoTGEyVkQzWXVqV3JoL2NnZXZzWHkwRE1D?=
 =?utf-8?B?MkxZZE4zMy8ybW9WZy9UZ2pHdHgrejZCVkl4MnZINnlqL2JrY1pIcW1VTzZp?=
 =?utf-8?B?WXBFOFBIaVdaSXZGWC9jZXVsaFdYbGNxLzVibXE1NzZ3d3AyYnFLM0lzeFVB?=
 =?utf-8?B?WFVSaExmOURpRWNtTlFNU3dlNUgvMlU1c3Axc1ZVOFY4Nk1Od0ZHU2xkY3dH?=
 =?utf-8?B?b2JHNHNBa2VhUUx3SlJ6TGE5OUJoRG94YWRROTJrc0tsZnZ3SXJ6Qm9sZkFq?=
 =?utf-8?B?dkkxb2krMnBzQnpXQXFZM3UrRytESERNN0s4VHlpL1pGOXdZaER4azl2RWdE?=
 =?utf-8?B?R1N6THdRS04rNHZFSzUvWHo1SmJvRVo4cHpyS2F3WC85WWJQNm9ibStmc3hL?=
 =?utf-8?B?R0R2ZlgwSElpdFBVRHZ5dmtlQTRNZ2I1c0RSejR6Tjh0aWt3ZDVhZjRGWGtq?=
 =?utf-8?B?aUtpYWFTR3B1cmxQWFQ1VW1Ud2FjUjRmNU9iUlZFSHlEczl6cVFZZDEwRW42?=
 =?utf-8?B?eUZaajZ0d1hoaU80eS9TdW9FN1Z5TFZGRDlhc1BiVzBBK0xFWjhzZnRFMGtM?=
 =?utf-8?B?VTFuMnFsUExrV2NkcWc5SmpJWUFqVC92WUpVNHpHaXQyaENKK2EyampadzBT?=
 =?utf-8?B?QlphVjI2SUpYTzQ5TUZsazR0U0l6d09wVnpuU1RjeGNDSVluRVNrNUZhbEtw?=
 =?utf-8?B?VkF6VlZhcGlrdndTV0ZWK2pRb0NCdDhGcE9JaUdPN2x2VG1wWXpvQ3hleksr?=
 =?utf-8?B?dmVldGF6V1dMTTJXVUJTNTBxZC9VT0xVL0VEWG1UaUFVOTRtYXJvdFgrYnlq?=
 =?utf-8?B?SEY4QjI3NkZhVjZYWGF2VnJoLzN1SFNKcytwUHdZTVBEcHRpMFozRjhZanJj?=
 =?utf-8?B?SWp2VVpQaGs0RGpzd1RzQlJRbmlzOFEyS29iamo1ejRMeWhRbHB3c3lvdnlk?=
 =?utf-8?Q?w/tGRG?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2025 09:32:48.1731
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3958e738-bd22-42d5-fc23-08ddf1df5631
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D7.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4204

On Fri Sep 12, 2025 at 8:40 AM CEST, Jan Beulich wrote:
> On 11.09.2025 18:23, Alejandro Vallejo wrote:
>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>> by the device model. The GPE handler checks this and compares it against
>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>> related bit in the bitmap and adjusting the table's checksum.
>>=20
>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until i=
t
>> reaches 128, even if that overflows the MADT into some other (hopefully
>> mapped) memory. The reading isn't as problematic as the writing though.
>>=20
>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>> then the bit where the "online" flag would be is flipped, thus
>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>> that happened outside its range. It's all terrible.
>>=20
>> Note that this corruption happens regardless of the device-model being
>> present or not, because even if the bitmap holds 0s, the overflowed
>> memory might not at the bits corresponding to the "online" flag.
>>=20
>> This patch adjusts the DSDT so entries >=3DNCPUS are skipped.
>>=20
>> Fixes: 087543338924("hvmloader: limit CPUs exposed to guests")
>> Reported-by: Grygorii Strashko 
>> Signed-off-by: Alejandro Vallejo 
>
> In principle:
> Reviewed-by: Jan Beulich 

Cheers,

>
> However, ...
>
>> --- a/tools/libacpi/mk_dsdt.c
>> +++ b/tools/libacpi/mk_dsdt.c
>> @@ -231,6 +231,20 @@ int main(int argc, char **argv)
>>      stmt("Store", "ToBuffer(PRS), Local0");
>>      for ( cpu =3D 0; cpu < max_cpus; cpu++ )
>>      {
>> +        if ( cpu )
>> +        {
>> +            /*
>> +             * Check if we're still within the MADT bounds
>> +             *
>> +             * LLess() takes one byte, but LLessEqual() takes two. Incr=
ease
>> +             * `cpu` by 1, so we can avoid it. It does add up once you =
do it
>> +             * 127 times!
>> +             */
>> +            push_block("If", "LLess(\\_SB.NCPU, %d)", 1 + cpu);
>> +            stmt("Return", "One");
>
> ... if you already care about size bloat in the conditional, why are the =
two
> bytes per instance that this extra return requires not relevant? They too
> add up, and they can be avoided by wrapping the If around the rest of the
> code. I didn't count it, but I expect the If encoding to grow by at most =
one
> byte, perhaps none at all.

I don't mind either way. Removing the "return" statement and the pop_block(=
)
would save 254 bytes in tota at most. I don't think the conditional would g=
row
because the there wouldn't be that much contained within, but regardless th=
e
early return is in the spirit of not going through 127 conditionals on ever=
y
GPE handle when you typically only have a handful of CPUs. The sooner we dr=
op
out of AML, the better.

In due time I want to shrink this to be an AML loop in dsdt.asl so it can
be taken out of mk_dsdt.c. That will both shrink the DSDT (a ton) and accel=
erate
GPE handling, but I don't have time to do it at the moment.

Do you have a preference in table size vs execution-time?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 09:47:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 09:47:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121713.1465837 (Exim 4.92)
	(envelope-from )
	id 1ux0N7-0002yR-3u; Fri, 12 Sep 2025 09:47:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121713.1465837; Fri, 12 Sep 2025 09:47: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 1ux0N7-0002yK-1K; Fri, 12 Sep 2025 09:47:13 +0000
Received: by outflank-mailman (input) for mailman id 1121713;
 Fri, 12 Sep 2025 09:47: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 1ux0N5-0002wh-B2
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 09:47:11 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71395213-8fbd-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 11:47:06 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU0PR03MB9615.eurprd03.prod.outlook.com (2603:10a6:10:422::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.19; Fri, 12 Sep
 2025 09:47:03 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9094.021; Fri, 12 Sep 2025
 09: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: 71395213-8fbd-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LNiJRa2VinkPYWdAVUwWUq3XaS+MaBJL641atsfsDxQxwQdf8JM8PYn1HQdYzegFdeX/eAIno/TWOSAYwcwxO8i8ARzQoTIS1XURG/9YLpvp8gY8qYHGxYrk/cpJ0FR7m8uFNwW881ZJLD0dKEAfjURA/ECvdexUOCYDvPpUOhFhHnZBDNMGTrS2hP21ms3WRh9Dk776Dy/nAb1REPxdnKRf+Stlh1Cn/ZkMX0iXO6Z8mwMJ8PKNarFc8JnLJ00oWJpRodXpoS9HMKpLdGspZxrwWDzx+nhziTCQFp/NwocFR0IlQO1pHnURI9KaPFOR5ggVYxXNaku4rFbJ286H/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=c3cXhSVaQPKt/puKFM1lKoxFGYP+UyaXGv6+MogjbpM=;
 b=V5nf1BgftrDk/j2eEa8pgHvz6B9ZSIoZZrs6uHg2BOg8x6VnHCcyXvYEWcfJTTd4MveMSnxzjixuKuBX9vvNiHIzE3zr8+sGFYcDN6AMX1t2dxTKH2eXT0gw+AXJDZh/Pu+jzt0SyvnXqNayKaRgw94fxI4DmoSKp4jgYIZqgSQhNkL4hPUmzHdFkaP6FFBuIlBXaxrpGiLE7TzEoKJQlE85nS7XCq0AZadRHVQv3YbCcUDnJtBH6LWo4ElajlIwFwfq0/YOdiu0YijR6ftTUX1tFInA+3fUTYA8xrnRgOcde83d3P9bTyxqmAxM9jVXUukgGfhZXcmC9fBBhsSz7g==
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=c3cXhSVaQPKt/puKFM1lKoxFGYP+UyaXGv6+MogjbpM=;
 b=X2MHmuPkXCw7R09KfilDFrGjpAYpM2jwKZ9rt0GpJnXxKGxIfxo10NNRjjxe697h2EhBmkdO8+uAIHzDQew5xUxw6FvExSWXAK7u4RXoZlkcIN+8HA17oWp4wP/Ru9Xth9xkuVxEdmBVEslhFb4IcxmXICRXeznsM6Zyhloyf0fkaPA5ERcWOQOyUjC48KrhLElhEkP+gb/BhvPVW3cW3RoLUV/0k6TYWBQx2B9Zov1wehAThwrZjn+fYulBwru5Kq8o71+uRHtN1xWFedwkEPH00bupIWlZywXTdLid2gCcLrw21lxrRI1ccvTMsG66srA4PbmrqjsIu0Y0KHNI0g==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Subject: [XEN][PATCH] x86: hvm: hypercall: use define instead of const in
 hvm_hypercall()
Thread-Topic: [XEN][PATCH] x86: hvm: hypercall: use define instead of const in
 hvm_hypercall()
Thread-Index: AQHcI8oxX/I/itfE00GCxamYjAZC5A==
Date: Fri, 12 Sep 2025 09:47:03 +0000
Message-ID: <20250912094702.1654772-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|DU0PR03MB9615:EE_
x-ms-office365-filtering-correlation-id: f6d2372b-dfff-4d23-bcc8-08ddf1e153e1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Sxr2Ntcz8B0O2xpH5HNIuuv07c6oBP48PnejSU/5uKd6SU6PR6rWLrMfaj?=
 =?iso-8859-1?Q?Iv2rbyTLdrpPlIdzEle+YD7QcQO01SxDgLlHAApxfNt2rJ4PypumFJvur6?=
 =?iso-8859-1?Q?+EMFxApGaCPgpqVriZku0QZNPvBrCqnsfJNx9Ukhba4d34OmrOtAxUovSW?=
 =?iso-8859-1?Q?53l9Uq0aFIuFIYEPNE00OU9bJWie4teys8y6wR327uWoza8A5GhOhFIUM6?=
 =?iso-8859-1?Q?40eaQnL3iY60kQGyQTM9LmOS3jjwyRb5FLn4//cqDgyQ/K7xertn6Z3x7e?=
 =?iso-8859-1?Q?DWQi5WOLNKt44ZVx4IquppEItE0OcnI1oEJj/Uw7FmOK9v7veAnspSOhud?=
 =?iso-8859-1?Q?ep9cxrvULCcA3YY0+oTnV1HqmtGKBTxiSACwO00oXKQrOLKtZ3qrUHS2GT?=
 =?iso-8859-1?Q?WvhL6V90/ftyxHgM7hj7E2mkC4aRKLapZAsUV67OpfsDEWHrs8zZ8UH/8R?=
 =?iso-8859-1?Q?Wa5mwIX3THYb41uD4OM6VTNPkSNbQ635JTYzFWtA8s3+jxM60ynadr6Px1?=
 =?iso-8859-1?Q?CzoT7F4bmEPJ1IDQZXOnMlQv6HjmTOrL+LgvT4TnP3/tqzyUYNG0xAgZOy?=
 =?iso-8859-1?Q?1AC5YvNcwfpRB/HFI0G1qF08sA35kXRLDGQJu1/Hrs+dkWw9Y7edrcyqoF?=
 =?iso-8859-1?Q?g3rRF7kN4L5UVUb6ccNQWSYPlJEQRrtxnPl9nX3XTAM8sAGNJDY4kqS7lI?=
 =?iso-8859-1?Q?oBic9fFPrOO11PamO7kL6gMnPKsdbuw83I+sUXOOzfKK+V3sp40XqfHEcH?=
 =?iso-8859-1?Q?/av3waCWVIgjmHS7xAj8ssnIdN1ZFkMxHLRp5dXqBP1G/jpTJHP3IiWmPM?=
 =?iso-8859-1?Q?GkcUuKIpAptSCq1SiBg1umPekdZu6TZ6AwJ50ZN+Y0XvgoRAAKpqfESvr7?=
 =?iso-8859-1?Q?+jLzOAHLm531xtEikQ6sRLv4i5TjmXztPx6x+dsXExq7mgtf7nJz5i/+PA?=
 =?iso-8859-1?Q?9aOMqAQpcIK+tzzom7WhSLJyMeai5ndUgmXwsKFHBMgDvcayhHh+Z7EbDj?=
 =?iso-8859-1?Q?X/9AY0jN0FBV5O2FgkVxruEtZg9FTVCTAb7ksj3DQC8rsS+Nly/dymR8kF?=
 =?iso-8859-1?Q?x/ebYbPWQihaTsFJ1x5nCJQnIPb9zjF/RuSvTWw7RxHquMqkON0KSkmfUt?=
 =?iso-8859-1?Q?S98dO4X6jNv6Cs16EgRxNm/wvnZm/5+W9eVkM5+PLmGZSojr8ZXyQ+Yp9D?=
 =?iso-8859-1?Q?rIF6zSMPe5ZyLsH6e23+TUfCLKv8bpJQSZ8zmeBtAoHMDGE5w9dRgZFsW+?=
 =?iso-8859-1?Q?I2+JhMZPBiwIYuzAqZvU1cjVh57y3L8FZvPuCwNS0wUd4hfUd04LVTIdbW?=
 =?iso-8859-1?Q?wqqUuoajJurc3p6NFjNNG/n6FVdy+iAwTdVn+Gvy8NK5hml514628DnwqY?=
 =?iso-8859-1?Q?gDs/4XddxvBIfs/PUJdwXWldQHahbQgmHM9Q3WUdt52RIlz3BHHqpnH6cD?=
 =?iso-8859-1?Q?jt54nHHKh+4x2p3TevdllQkmVKdPLyEl2jSPX1Av/r84QYs5KJWR1sg54L?=
 =?iso-8859-1?Q?Ph4BGV6Fsw/q+xbclsd9bD/J5rd64OzYPbH6hnpsQ1BCVUi9bVdIlSB0IZ?=
 =?iso-8859-1?Q?Psdjo7o=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?AL9bCaAn4NXKRxsVFCPYtju+sJAgqiBYjBqZqEgf7XQsIcf8GBuy9be88B?=
 =?iso-8859-1?Q?MsIHAaZKDuU+M/lE22JdE/luWUsCXSAf2pwX3seqoRK9HChFd8W5KsYDJM?=
 =?iso-8859-1?Q?2CFNwdBtLoVGpwJ59BZKGf141tjZcjdPqwlvPZy517TqUEtNa3JObm0Rjt?=
 =?iso-8859-1?Q?ChlAb1dLB2675ZIBwhUDxypnleB6a8SevQimc0oQ/XjG2FScPhqvRhhv6g?=
 =?iso-8859-1?Q?IN2rYgl/z2MbzhI/fIyWSzXynqqcyefaGjTF2rxELUIgnl6mJWg6tS4hCp?=
 =?iso-8859-1?Q?7c9iliaycN6V1/ImXltS7RU3Mym2qCfrTtTUjJ2b7zB+unpbhMf5DfyTJp?=
 =?iso-8859-1?Q?4FTh4Nyapofkbj1sOFqPbvtf2bF99R6rTzDfSHtS6Rca8K2nBw+1+IpI8a?=
 =?iso-8859-1?Q?T+Vwl5i5I0qnPZ7fXC/H7Dtl+hRM02wGJJtMR2Rw5+tOEFgUFmjZBHNMAd?=
 =?iso-8859-1?Q?ZLhvNwK1+qFrUZ+yoigBu7CV/UgZ3WQcMJRuEXn0CBobiHOR1VyIJxumE1?=
 =?iso-8859-1?Q?2DORQvp9wQuorcBfPYp7vti5eEuEkMGpgyQsP0Vx8jWsIeiUz+BnuzlCBr?=
 =?iso-8859-1?Q?tCmD3Iac0oQe9FVh/eYprGqdiLqhwy/N6DHUtUz7jBsx6+ngpHmJI0DHH0?=
 =?iso-8859-1?Q?HB6QPOhdeg46mYCNLZI7TElDNqCaaediso75SlQcgxwUagrXUEH+YY68Vg?=
 =?iso-8859-1?Q?EBZg/pIGZplh3euqsRsf1CmQYGup2VdpnBujA62a7CSmZCkm9jnHRJTCJG?=
 =?iso-8859-1?Q?E05MF2FU+ACL2QU3xbg/Rw4rwp41BsiY+Mqc6mb6dS28u3I3kFH+kaQZ4x?=
 =?iso-8859-1?Q?+m2+YSiT0+wUh3gJqXlzPT102Dr6GIY0kIJ3mR+LE+z6wMOHdWtYIZXGlb?=
 =?iso-8859-1?Q?cdCBDPsTiAv1slr2ufcUhnvRXuAJ6X2dSErg5/WkU9VFuSzD07je+vvUw0?=
 =?iso-8859-1?Q?Rf2JfN+HXtqIOuAEFTr7LdhOe3c6SNIGdETuHW9nZFO+SjnPBR7dVl7a3+?=
 =?iso-8859-1?Q?hldvJokWpJy6mJA8fumGEoMRt+KeVrVNA2ODLhPomnYUzem+mng/2W/BCD?=
 =?iso-8859-1?Q?zTt222Q7XmpxykbYd3Z1FktWBBDuUVVKPFFN7VX8JRvyL9X0+zzxJ/48gs?=
 =?iso-8859-1?Q?2YmyonEtqBRAksDPAnLJkYHCbPuTUqAxRrzCcssRg47RCJmxXcfPKYjGHw?=
 =?iso-8859-1?Q?qWRLJiioZ1e8qsltVCJzXmIehv7PvYr/3g9vNocxLqOy0xS3bRSgy0Zd5o?=
 =?iso-8859-1?Q?BRFZ0DHLFVSN7xN/xrvmzqtprNMeCs9EeD6+iwJ0gXGKWQR9I9hw2n8/f3?=
 =?iso-8859-1?Q?/cCWCmgigGmFUZrBFA1n1zpeCfwbzx8X6Ip70mrL8N52S0afsIhM9FHx9D?=
 =?iso-8859-1?Q?oRVD9GqUb+zypjeB8tZ2GYLoxhBNjkVuYIFpHbk76ErX4dmvdP9dlPu1KJ?=
 =?iso-8859-1?Q?dhyZ3+Mw1MkQif7UFDInnVoHcm84HiQ2ITAhvnlzXhP6kSKjgC9qyj/yX0?=
 =?iso-8859-1?Q?izpW57hYWRfbxNfIbJLbpWnJ4P9heZ5d0nEk9SuYGEM3UVAkV3SPuyez1L?=
 =?iso-8859-1?Q?JicANKFr8Chyug4RdMfBZFBS8cqpV5asFdT6Zgzm/fijL7gDbkdnWJ4UYw?=
 =?iso-8859-1?Q?mDj3rqCBik1ck5b1BWak+OqsqbWMNpsM63yyyFWB5Ud36aY6oIbwdclg?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f6d2372b-dfff-4d23-bcc8-08ddf1e153e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2025 09:47:03.3344
 (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: 6Z9eAu3LSkc/SsrlOerHvmrjSJO5QfCN03k74S5+C1U0dsWb5tuQNti8Cez1w5P9z5b6F20Mj8LSMSokzoSeUCo4JRozeBuRuhuL9U3Dbkw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9615

From: Grygorii Strashko 

Use define X86_MODE_64BIT instead of constant in hvm_hypercall() for "mode"
conditional check to improve code readability.

Signed-off-by: Grygorii Strashko 
---
 xen/arch/x86/hvm/hypercall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 6f8dfdff4ac6..b254b3e2f7d6 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -155,7 +155,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
=20
     curr->hcall_preempted =3D false;
=20
-    if ( mode =3D=3D 8 )
+    if ( mode =3D=3D X86_MODE_64BIT )
     {
         HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%lx, %lx, %lx, %lx, %lx)",
                     eax, regs->rdi, regs->rsi, regs->rdx, regs->r10, regs-=
>r8);
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 09:49:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 09:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121731.1465848 (Exim 4.92)
	(envelope-from )
	id 1ux0P8-0003YO-Hz; Fri, 12 Sep 2025 09:49:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121731.1465848; Fri, 12 Sep 2025 09: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 1ux0P8-0003YH-FJ; Fri, 12 Sep 2025 09:49:18 +0000
Received: by outflank-mailman (input) for mailman id 1121731;
 Fri, 12 Sep 2025 09:49: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 1ux0P6-0003YB-W2
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 09:49:17 +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 bdf339ce-8fbd-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 11:49:14 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b0787fc3008so234326666b.3
 for ; Fri, 12 Sep 2025 02:49:14 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b07b31291b0sm337259166b.34.2025.09.12.02.49.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 02:49: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: bdf339ce-8fbd-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757670554; x=1758275354; 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=RCfKepTI44+aiMfz+fCazCpPOr/YPjAvTn6JXYE1Ds8=;
        b=PbmALipCMT11RszH0Y2dIuIfLxMlG4ymV1+XqNMqKZdVORKTfeaGCTE6XOl9SXm+yb
         0QBRIURs+lm6tzh8Vfh6SZj26dkJfvxQBm6OCxwDrMcFT6+O2Tx1Daq9LRuJcqJB5bZL
         hJYp7WZENVxiChuNyOY7D7VvpuQVT4p8Irs/ifUY9TPG3Oidf+2Bjp+b04tY2c+KqsHD
         LMqYxryZ6+uSKl1HwNBCnb3L4AdcWN5dK/mCCC3BwnuTNdTSYle+nIKGJE0qxpPplxQk
         xQJiwlIUHYa2PTYHYkz3oIqJYq3QwPfGtsYOpiudMObxiF204v1QHhPmZoL7Jode/Ddv
         d7Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757670554; x=1758275354;
        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=RCfKepTI44+aiMfz+fCazCpPOr/YPjAvTn6JXYE1Ds8=;
        b=nfdTQ5t5crp2SKltlhuatr6M7yyAlOFfCFwBO1KgBv/J6Pqi7tTmne4xlU6AURCKPm
         dl3J+bPSG6/9JNOhnMsrHve9LufPUjclbdHyKTGeP49sJkX7RDYYsXaKthoUVpFMLzIn
         TFJYkdvPZ7TdJuxkjeEv4X7nXvYAFBypuM7aR2iaK6Ir71lEggwLb5BXRSnDNAr5cBo/
         tSy+Njrl1UyWuHwAS3uUxDsinzJJXoSb3s1I9L4rSukHaprk4zl+Ddq0SldveFLMNo5S
         zOVSt8DPoH/wxkuVgmqplaHfj0NPSDmVEZrN4+TOIdZkhaVhpVKDpeQhAoC5CWFraU3i
         8QAA==
X-Forwarded-Encrypted: i=1; AJvYcCVJOF0AWVPQGKeeNlcecwJ/WFiQUCYUpL1kBeWkAgUG09Km+J9ntnbjMqj4VILb2NYHyBnAsTxeuTw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIZ1ol5ZsI8Gy3dyHxc9G8o2V0b8IOxsdbHP7VF81p3ytH96yU
	ZKb5sjytLwpxfdDqR1BtV9briH+tas0uhZ/YCRWiFgVT7lPOtbLD4o1P5lJFkjJvcxA=
X-Gm-Gg: ASbGncsMwOIwPF7+TJNC8N0ysVkSg7Zna+omMmNwusCuKNaE6iAHFrtBjBmRKCKO0aq
	w8w+9Yev1IuOl4t1uLL96gJKXm4WGjxS0kW5C8Qz8bUmPVGuEf3F2AiVrTEEvfRT+Me0y+kTU23
	xNgAySkeYapz7bcJ6YWc94lsfQzEjymX5k3DucZgVRQejYsjtnP7yjx23VzwikBqk843yThMmS5
	+gflT/SIxc7P/TrfJD45B0Jf0hDMmFX7sXCXJreXJjHNo6Y5spbUJk822gVsACFPUpwPUZNzTCD
	L7shSpVUOBNzAXy2hKgXtmruJxzlDFSotcw+vXFlMsV092A1GYRSNIGDfJ+FS5wBsPdu6z1+6/l
	xfo3XCs+ylvO8R38wYYxiNs4qR3oqLEIfx/DAjWG04yYfJA4I/xjNFm8HSCo4mlBd7un2fEY8k4
	vj94f2AlSyEySjQKUIabVGpyYPrRdL0y428+6SstHbF+S+
X-Google-Smtp-Source: AGHT+IFQDNbG+mSizXCHYgdgZc5bpBYCEGvOvt3RqGb0cJg1KCyWZjhvzljHh8moTtF892HF/Z+G1w==
X-Received: by 2002:a17:906:fd82:b0:b04:760d:1162 with SMTP id a640c23a62f3a-b07c384ae2dmr187984966b.47.1757670554073;
        Fri, 12 Sep 2025 02:49:14 -0700 (PDT)
Message-ID: <776ba15a-f922-407d-b1f2-2a2186c4729e@suse.com>
Date: Fri, 12 Sep 2025 11:49:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: WARN in xennet_disconnect_backend when frontend is paused during
 backend shutdown
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel 
References: 
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------zfMhlxn0vqbr5l0if1ACoHpA"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------zfMhlxn0vqbr5l0if1ACoHpA
Content-Type: multipart/mixed; boundary="------------VqrcMoDPvxkZ0lgIbmGPIpJg";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel 
Message-ID: <776ba15a-f922-407d-b1f2-2a2186c4729e@suse.com>
Subject: Re: WARN in xennet_disconnect_backend when frontend is paused during
 backend shutdown
References: 
In-Reply-To: 

--------------VqrcMoDPvxkZ0lgIbmGPIpJg
Content-Type: multipart/mixed; boundary="------------chSMkUMN6gxtqd0bb7uhXVHL"

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

T24gMTEuMDkuMjUgMTc6MTEsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN
Cj4gSGksDQo+IA0KPiBUaGUgc3RlcHM6DQo+IDEuIEhhdmUgZG9tVSBuZXRmcm9udCAoInVu
dHJ1c3RlZCIgaGVyZSkgYW5kIGRvbVUgbmV0YmFjaw0KPiAoInN5cy1maXJld2FsbC1hbHQi
IGhlcmUpLg0KPiAyLiBQYXVzZSBmcm9udGVuZA0KPiAzLiBTaHV0ZG93biBiYWNrZW5kDQo+
IDQuIFVucGF1c2UgZnJvbnRlbmQNCj4gNS4gRGV0YWNoIG5ldHdvcmsgKGluIG15IGNhc2Ug
YXR0YWNoaW5nIGFub3RoZXIgb25lIGZvbGxvd3MganVzdCBhZnRlciwNCj4gYnV0IEkgYmVs
aWV2ZSBpdCdzIG5vdCByZWxldmFudCkuDQo+IA0KPiBUaGlzIGdpdmVzIHRoZSBmb2xsb3dp
bmcgb24gdGhlIGZyb250ZW5kIHNpZGU6DQo+IA0KPiAgICAgIC0tLS0tLS0tLS0tLVsgY3V0
IGhlcmUgXS0tLS0tLS0tLS0tLQ0KPiAgICAgIFdBUk5JTkc6IENQVTogMSBQSUQ6IDE0MSBh
dCBpbmNsdWRlL2xpbnV4L21tLmg6MTMyOCB4ZW5uZXRfZGlzY29ubmVjdF9iYWNrZW5kKzB4
MWJlLzB4NTkwIFt4ZW5fbmV0ZnJvbnRdDQo+ICAgICAgTW9kdWxlcyBsaW5rZWQgaW46IHNu
ZF9zZXFfZHVtbXkgc25kX2hydGltZXIgc25kX3NlcSBzbmRfc2VxX2RldmljZSBzbmRfdGlt
ZXIgc25kIHNvdW5kY29yZSBuZnRfcmVqZWN0X2lwdjYgbmZfcmVqZWN0X2lwdjYgbmZ0X3Jl
amVjdF9pcHY0IG5mX3JlamVjdF9pcHY0IG5mdF9yZWplY3QgbmZ0X2N0IG5mdF9tYXNxIG5m
dF9jaGFpbl9uYXQgbmZfbmF0IG5mX2Nvbm50cmFjayBuZl9kZWZyYWdfaXB2NiBuZl9kZWZy
YWdfaXB2NCBuZl90YWJsZXMgaW50ZWxfcmFwbF9tc3IgaW50ZWxfcmFwbF9jb21tb24gaW50
ZWxfdW5jb3JlX2ZyZXF1ZW5jeV9jb21tb24gaW50ZWxfcG1jX2NvcmUgcG10X3RlbGVtZXRy
eSBwbXRfZGlzY292ZXJ5IHBtdF9jbGFzcyBpbnRlbF9wbWNfc3NyYW1fdGVsZW1ldHJ5IGlu
dGVsX3ZzZWMgcG9seXZhbF9jbG11bG5pZ2hhc2hfY2xtdWxuaV9pbnRlbCB4ZW5fbmV0ZnJv
bnQgcGNzcGtyIHhlbl9zY3NpYmFjayB0YXJnZXRfY29yZV9tb2QgeGVuX25ldGJhY2sgeGVu
X3ByaXZjbWQgeGVuX2dudGRldiB4ZW5fZ250YWxsb2MgeGVuX2Jsa2JhY2sgeGVuX2V2dGNo
biBpMmNfZGV2IGxvb3AgZnVzZSBuZm5ldGxpbmsgb3ZlcmxheSB4ZW5fYmxrZnJvbnQNCj4g
ICAgICBDUFU6IDEgVUlEOiAwIFBJRDogMTQxIENvbW06IHhlbndhdGNoIE5vdCB0YWludGVk
IDYuMTcuMC0wLnJjNS4xLnF1YmVzLjEuZmM0MS54ODZfNjQgIzEgUFJFRU1QVChmdWxsKQ0K
PiAgICAgIFJJUDogMDAxMDp4ZW5uZXRfZGlzY29ubmVjdF9iYWNrZW5kKzB4MWJlLzB4NTkw
IFt4ZW5fbmV0ZnJvbnRdDQo+ICAgICAgQ29kZTogMDAgMGYgODMgOTMgMDMgMDAgMDAgNDgg
OGIgOTQgZGQgOTAgMTAgMDAgMDAgNDggOGIgNGEgMDggZjYgYzEgMDEgNzUgNzkgNjYgOTAg
MGYgYjYgNGEgMzMgODEgZjkgZjUgMDAgMDAgMDAgMGYgODUgZjMgZmUgZmYgZmYgPDBmPiAw
YiA0OSA4MSBmZiAwMCAwMSAwMCAwMCAwZiA4MiAwMSBmZiBmZiBmZiA0YyA4OSBmZSA0OCBj
NyBjNyBlMA0KPiAgICAgIFJTUDogMDAxODpmZmZmYzkwMDAxMTIzY2Y4IEVGTEFHUzogMDAw
MTAyNDYNCj4gICAgICBSQVg6IDAwMDAwMDAwMDAwMDAwMTAgUkJYOiAwMDAwMDAwMDAwMDAw
MDAxIFJDWDogMDAwMDAwMDAwMDAwMDBmNQ0KPiAgICAgIFJEWDogZmZmZmVhMDAwMGEwNTIw
MCBSU0k6IDAwMDAwMDAwMDAwMDAwMDEgUkRJOiBmZmZmZmZmZjgyNTI4ZDYwDQo+ICAgICAg
UkJQOiBmZmZmODg4MDQxNDAwMDAwIFIwODogZmZmZjg4ODAwNTA1NGM4MCBSMDk6IGZmZmY4
ODgwMDUwNTRjODANCj4gICAgICBSMTA6IDAwMDAwMDAwMDAxNTAwMTMgUjExOiBmZmZmODg4
MDE4NTFjZDgwIFIxMjogMDAwMDAwMDAwMDAwMDAwMA0KPiAgICAgIFIxMzogZmZmZjg4ODA1
MzYxOTAwMCBSMTQ6IGZmZmY4ODgwMDVkNjFhODAgUjE1OiAwMDAwMDAwMDAwMDAwMDAxDQo+
ICAgICAgRlM6ICAwMDAwMDAwMDAwMDAwMDAwKDAwMDApIEdTOmZmZmY4ODgwOTUyYzYwMDAo
MDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMA0KPiAgICAgIENTOiAgMDAxMCBEUzogMDAw
MCBFUzogMDAwMCBDUjA6IDAwMDAwMDAwODAwNTAwMzMNCj4gICAgICBDUjI6IDAwMDA2MTgy
YTExZjMzMjggQ1IzOiAwMDAwMDAwMDEwODRjMDA2IENSNDogMDAwMDAwMDAwMDc3MGVmMA0K
PiAgICAgIFBLUlU6IDU1NTU1NTU0DQo+ICAgICAgQ2FsbCBUcmFjZToNCj4gICAgICAgPFRB
U0s+DQo+ICAgICAgIHhlbm5ldF9yZW1vdmUrMHgxZS8weDgwIFt4ZW5fbmV0ZnJvbnRdDQo+
ICAgICAgIHhlbmJ1c19kZXZfcmVtb3ZlKzB4NmUvMHhmMA0KPiAgICAgICBkZXZpY2VfcmVs
ZWFzZV9kcml2ZXJfaW50ZXJuYWwrMHgxOWMvMHgyMDANCj4gICAgICAgYnVzX3JlbW92ZV9k
ZXZpY2UrMHhjNi8weDEzMA0KPiAgICAgICBkZXZpY2VfZGVsKzB4MTYwLzB4M2UwDQo+ICAg
ICAgID8gX3Jhd19zcGluX3VubG9jaysweGUvMHgzMA0KPiAgICAgICA/IGtsaXN0X2l0ZXJf
ZXhpdCsweDE4LzB4MzANCj4gICAgICAgPyBfX3BmeF94ZW53YXRjaF90aHJlYWQrMHgxMC8w
eDEwDQo+ICAgICAgIGRldmljZV91bnJlZ2lzdGVyKzB4MTcvMHg2MA0KPiAgICAgICB4ZW5i
dXNfZGV2X2NoYW5nZWQrMHgxZDcvMHgyNDANCj4gICAgICAgeGVud2F0Y2hfdGhyZWFkKzB4
OGYvMHgxYzANCj4gICAgICAgPyBfX3BmeF9hdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgx
MC8weDEwDQo+ICAgICAgIGt0aHJlYWQrMHhmOS8weDI0MA0KPiAgICAgICA/IF9fcGZ4X2t0
aHJlYWQrMHgxMC8weDEwDQo+ICAgICAgIHJldF9mcm9tX2ZvcmsrMHgxNTIvMHgxODANCj4g
ICAgICAgPyBfX3BmeF9rdGhyZWFkKzB4MTAvMHgxMA0KPiAgICAgICByZXRfZnJvbV9mb3Jr
X2FzbSsweDFhLzB4MzANCj4gICAgICAgPC9UQVNLPg0KPiAgICAgIC0tLVsgZW5kIHRyYWNl
IDAwMDAwMDAwMDAwMDAwMDAgXS0tLQ0KPiAgICAgIHhlbl9uZXRmcm9udDogYmFja2VuZCBz
dXBwb3J0cyBYRFAgaGVhZHJvb20NCj4gICAgICB2aWYgdmlmLTA6IGJvdW5jaW5nIHRyYW5z
bWl0dGVkIGRhdGEgdG8gemVyb2VkIHBhZ2VzDQo+IA0KPiBUaGUgbGFzdCB0d28gYXJlIGxp
a2VseSByZWxhdGVkIHRvIGZvbGxvd2luZyBhdHRhY2gsIG5vdCBkZXRhY2guDQo+IA0KPiBU
aGUgc2FtZSBoYXBwZW5zIG9uIDYuMTUgdG9vLCBzbyBpdCBpc24ndCBuZXcgdGhpbmcuDQo+
IA0KPiBTaHV0dGluZyBkb3duIGJhY2tlbmQgd2l0aG91dCBkZXRhY2hpbmcgZmlyc3QgaXMg
bm90IHJlYWxseSBhIG5vcm1hbA0KPiBvcGVyYXRpb24sIGFuZCBkb2luZyB0aGF0IHdoaWxl
IGZyb250ZW5kIGlzIHBhdXNlZCBpcyBldmVuIGxlc3Mgc28uIEJ1dA0KPiBpcyB0aGUgYWJv
dmUgZXhwZWN0ZWQgb3V0Y29tZT8gSWYgSSByZWFkIGl0IHJpZ2h0LCBpdCdzDQo+IFdBUk5f
T05fT05DRShmb2xpb190ZXN0X3NsYWIoZm9saW8pKSBpbiBnZXRfcGFnZSgpLCB3aGljaCBJ
IGZpbmQNCj4gY29uZnVzaW5nLg0KPiANCj4gT3JpZ2luYWxseSByZXBvcnRlZCBhdCBodHRw
czovL2dpdGh1Yi5jb20vUXViZXNPUy9xdWJlcy1jb3JlLWFnZW50LWxpbnV4L3B1bGwvNjAz
I2lzc3VlY29tbWVudC0zMjgwOTUzMDgwDQo+IA0KDQpIbW0sIHdpdGggdGhpcyBzY2VuYXJp
byBJIGltYWdpbmUgeW91IGNvdWxkIG1hbmFnZSB0byBoYXZlDQp4ZW5uZXRfZGlzY29ubmVj
dF9iYWNrZW5kKCkgcnVubmluZyBtdWx0aXBsZSB0aW1lcyBmb3IgdGhlIHNhbWUgZGV2aWNl
DQpjb25jdXJyZW50bHkuDQoNCkhvdyByZWxpYWJsZSBjYW4gdGhpcyBiZSByZXByb2R1Y2Vk
PyBIb3cgbWFueSB2Y3B1cyBkb2VzIHRoZSBndWVzdCBoYXZlPw0KDQpNYXliZSB0aGUgZml4
IGlzIGFzIHNpbXBsZSBhcyBhZGRpbmcgYSBsb2NrIGluIHhlbm5ldF9kaXNjb25uZWN0X2Jh
Y2tlbmQoKS4NCg0KDQpKdWVyZ2VuDQo=
--------------chSMkUMN6gxtqd0bb7uhXVHL
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-----

--------------chSMkUMN6gxtqd0bb7uhXVHL--

--------------VqrcMoDPvxkZ0lgIbmGPIpJg--

--------------zfMhlxn0vqbr5l0if1ACoHpA
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/Ey8FAmjD7JgFAwAAAAAACgkQsN6d1ii/Ey/B
CAf/XWjfbsht4eg1gM2OkzUmZu5wgXQ9Gv5X4MN+A7IiyREyrQT1RAk8aiM0wWRdhfNqG8y93OM9
aXX7J+fDrc5vWnYzS8kUHVRv5Iz4GLIFgEkKIkzjXrtvPIvEEqFA9JFNYlBqX/db4wpTae06rKJr
MqE23+7ua39Dtk4rBX8TBUIIjid7RVKlqKYXv3rqBJge7zHHTdyU02FsUXLfkoSyWZdYY6yl6l9b
qoejJAOWYKzDlObD+QYt9ioMXULqlwZkLgbdFl3pP03e7kquIxkpprmQZXNc4LmERSE9km+yDUz5
NAS0VJd+AAJFgpIzem2OyntzHhjHXatnb6T+OCODEg==
=y54H
-----END PGP SIGNATURE-----

--------------zfMhlxn0vqbr5l0if1ACoHpA--


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 09:58:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 09:58:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121747.1465858 (Exim 4.92)
	(envelope-from )
	id 1ux0XX-0005CT-9W; Fri, 12 Sep 2025 09:57:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121747.1465858; Fri, 12 Sep 2025 09:57: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 1ux0XX-0005CM-6W; Fri, 12 Sep 2025 09:57:59 +0000
Received: by outflank-mailman (input) for mailman id 1121747;
 Fri, 12 Sep 2025 09:57: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 1ux0XV-0005CG-SY
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 09:57:57 +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 f4e0cc32-8fbe-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 11:57:56 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45cb5492350so12733345e9.1
 for ; Fri, 12 Sep 2025 02:57:56 -0700 (PDT)
Received: from localhost.localdomain ([87.114.69.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607cd9fasm5850043f8f.35.2025.09.12.02.57.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 02:57: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: f4e0cc32-8fbe-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757671076; x=1758275876; 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=40hmlr5BYX9rZsXVh4CU9sX4LFOJM9bVuQanQklyxpE=;
        b=CwYOARX8LACft4Qw6D8QzzVOK1kK4w/G2SSAMwySKvd8NSUMRS2aHpeDxd9PJDky+g
         guM1vSVSWgKenHsh+sA0GqJoqx1j0dD0kG0uAZm2BFIc/tlncYehW9qvQ5hI3wnY9ZwL
         7H7ukna5OEqi7l0nZ+blzbC4ZeUPmJ4ks63PE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757671076; x=1758275876;
        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=40hmlr5BYX9rZsXVh4CU9sX4LFOJM9bVuQanQklyxpE=;
        b=obY9VoKrIMSLikge/32/hm984ID6NCoRJ+hgwE4JMbIhbxEWFYM6lpHeMO5d4dCEO8
         L8DGCthG+2GRx99DPAwlR4uL0Ifw+RvFDF3eNgj2Dd5AxmrE+6hZFgPEk/DvCjwHUCGP
         WKctI2+QYJWn1eg7qelJ6n+6Nbjc8pHwctaqV9BVXqQ/2CNvptanE3LLh5g1uYO96TY6
         FdEQpd+8MQoBz2X0xzMsgIn85alO1aadJNsjP3Gc/mL6L7gHHCKGbnSMzMqYhiy+EKIa
         IL9XmK+eoBxduf9CXZ1GCgIuhn77cEW8Oo+aUdVbX5sIYWka/uSG19CQh7ag+l1m7IQo
         Bnag==
X-Gm-Message-State: AOJu0YwViN1lbRjbsK3vTEqHRsK8hmeTum8slvhufOr0oDx6MtOrDFj/
	4EIdoLcSR18bsUfW/Q2jPYGfqnt/Td+6AAc6jllQ2sXxtAzb5/K6NeuItOHua5CLPIwFCgw3y0k
	wKM16LKY=
X-Gm-Gg: ASbGncsCJuMbsVqiLqKRJhHsZ12VCCNk5iQKPTrWhm7b/SHiNiQSc8bhy7aTKzDQA44
	+xJzC2firrDPd+T7JL60i6SopK9kJEy6qZdMy+c3yfm08RY72nXltol4OXUcVY6CzC763zkj/vq
	ZtTbIa+uW8YyV9vOEaxIfQbnGWIBuo6taqT+v7gSie0JtF6jtG9HIayXaC+N+kS7nb9C7qXQUv/
	MrO+fBriYIbhw7UmW52GfbmkXjAHBW5nS3341nLCzUaIRcCYWK4nJFeTJxrDHqX32DhST2pwd8N
	jCHOL8HLAA38fLLQkPKXJ0j6z5Ny+iEYhaEICGSVO1IHVScrTeZOJg2mXHchAOEh7tLdkmUHM3V
	nYpkMSQNs/CoQUivNUbx1zhrp9V7rhx0YGtXcv/kTSfzQ2gErfqG6
X-Google-Smtp-Source: AGHT+IGs+stwR7Er4cFYsKF0o4kRKljj4gxRt6JfpX/6GkjzcAiePSBMlTp/aPec5ahAwYotQImiiQ==
X-Received: by 2002:a05:600c:6812:b0:45d:98be:ee91 with SMTP id 5b1f17b1804b1-45f211d4f1emr24183805e9.9.1757671075611;
        Fri, 12 Sep 2025 02:57:55 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	Anthony PERARD ,
	Juergen Gross ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Andrew Cooper ,
	Oleksii Kurochko 
Subject: [PATCH v3] tools/libs: Use superpages where possible on migrate/resume
Date: Fri, 12 Sep 2025 10:57:44 +0100
Message-ID: <20250912095744.99181-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Try to allocate larger order pages.
With some test memory program stressing TLB (many small random
memory accesses) you can get 15% performance improves.
On the first memory iteration the sender is currently sending
memory in 4mb aligned chunks which allows the receiver to
allocate most pages as 2mb superpages instead of single 4kb pages.
This works even for HVM where the first 2mb contains some holes.
This change does not handle 1gb superpages as this will require
change in the protocol to preallocate space.

Signed-off-by: Frediano Ziglio 
Release-Acked-by: Oleksii Kurochko 
---
Changes since v1:
- updated commit message and subject;
- change the implementation detecting possible 2mb pages inside
  the packet sent allowing more 2mb superpages.

Changes since v2:
- change implementation simplifying detecting and allocations
  of 2mb pages.
---
 tools/libs/guest/xg_sr_restore.c | 45 +++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c
index 06231ca826..ea5a137612 100644
--- a/tools/libs/guest/xg_sr_restore.c
+++ b/tools/libs/guest/xg_sr_restore.c
@@ -129,6 +129,30 @@ static int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
+/* Order of the smallest superpage */
+#define SMALL_SUPERPAGE_ORDER 9
+#else
+#error Define SMALL_SUPERPAGE_ORDER for this platform
+#endif
+
+static bool populate_small_superpage(struct xc_sr_context *ctx, xen_pfn_t pfn)
+{
+    xen_pfn_t mfn = pfn;
+
+    if ( xc_domain_populate_physmap_exact(
+         ctx->xch, ctx->domid, 1, SMALL_SUPERPAGE_ORDER, 0, &mfn) )
+        return false;
+
+    if ( mfn == INVALID_MFN )
+        return false;
+
+    for ( size_t i = 0; i < (1 << SMALL_SUPERPAGE_ORDER); ++i )
+        ctx->restore.ops.set_gfn(ctx, pfn + i, mfn + i);
+
+    return true;
+}
+
 /*
  * Given a set of pfns, obtain memory from Xen to fill the physmap for the
  * unpopulated subset.  If types is NULL, no page type checking is performed
@@ -142,6 +166,9 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned int count,
         *pfns = malloc(count * sizeof(*pfns));
     unsigned int i, nr_pfns = 0;
     int rc = -1;
+    xen_pfn_t prev = 0;
+    unsigned num_contiguous = 0;
+    xen_pfn_t mask = ~((~(xen_pfn_t)0) << SMALL_SUPERPAGE_ORDER);
 
     if ( !mfns || !pfns )
     {
@@ -152,14 +179,26 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned int count,
 
     for ( i = 0; i < count; ++i )
     {
+        xen_pfn_t pfn = original_pfns[i];
+
         if ( (!types || page_type_to_populate(types[i])) &&
-             !pfn_is_populated(ctx, original_pfns[i]) )
+             !pfn_is_populated(ctx, pfn) )
         {
-            rc = pfn_set_populated(ctx, original_pfns[i]);
+            rc = pfn_set_populated(ctx, pfn);
             if ( rc )
                 goto err;
-            pfns[nr_pfns] = mfns[nr_pfns] = original_pfns[i];
+            pfns[nr_pfns] = mfns[nr_pfns] = pfn;
             ++nr_pfns;
+            if ( pfn != prev + 1 )
+                num_contiguous = 0;
+            num_contiguous++;
+            prev = pfn;
+            if ( num_contiguous > mask && (pfn & mask) == mask &&
+                 populate_small_superpage(ctx, pfn - mask) )
+            {
+                nr_pfns -= mask + 1;
+                num_contiguous = 0;
+            }
         }
     }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 10:05:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 10:05:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121762.1465869 (Exim 4.92)
	(envelope-from )
	id 1ux0eO-0006vT-VV; Fri, 12 Sep 2025 10:05:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121762.1465869; Fri, 12 Sep 2025 10:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux0eO-0006vM-Rb; Fri, 12 Sep 2025 10:05:04 +0000
Received: by outflank-mailman (input) for mailman id 1121762;
 Fri, 12 Sep 2025 10: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 1ux0eN-0006vG-Ap
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 10:05: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 f03b5156-8fbf-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 12:04:58 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3dae49b1293so908543f8f.1
 for ; Fri, 12 Sep 2025 03:04:58 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607cd0a7sm5868898f8f.39.2025.09.12.03.04.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 03: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: f03b5156-8fbf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757671497; x=1758276297; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AQYhS7fp5sjFCCrG0LUR3X9Ch1Pl189clAO+Hcfc2ao=;
        b=boyJhpGctuoWIg2/a39R59O1jCniiD75FApdRJA1wk9QlUN2VzJhoqswV7ZHIFQiOU
         0U8X3SqSmQxrE4N9rBA9zKoMwmD7QEKRnKFDwwxnrGSlRLC5rDW1QY1RT9dTKio/UEaK
         eSCO93Mk05Sp6EXvKZ6uQyltaFDlRkDh+2An8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757671497; x=1758276297;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AQYhS7fp5sjFCCrG0LUR3X9Ch1Pl189clAO+Hcfc2ao=;
        b=fPFGEfEvW7ydr1/BzXuWULAP7nYQ+RQqL7mlsCJK/r6t+uFZHWcpdlnDVM0OA7neFJ
         xGL/92KrqQhsoaI4YCZU18Jzi8dfpfjRXRyMaPcrg4ynj0AAYPxLzlHxXJ8JHu1f7O3A
         kEgWk74oGDn17kbRWZc5PJXdyQrLatRxl3IZBWklpiCp6L2/TStitMNx4VpBsvjQ6oEM
         gJrsTckCdBj3v9jADuOIkylq15tRcXl2WfTZJI6537LVszc2GV0BVUpppQ41t2Jc8oFI
         3V6DA2eq0ezPGdFWRmvAWfOhsQOOPD3q2E+WQnQGT7kp6JtipkrM54PrkslpbInOCnee
         Sl4g==
X-Forwarded-Encrypted: i=1; AJvYcCWkaXqT6xrqn+T75n2YwVDuo0IrPPfBhoBS3MqU5hVvGd1Z9HDV12yfiwjKz+w7ALkPvov0lM7Fa8s=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzn2MCU/PZrMGnl7w2J/GhkC4KHJf3aL+pMGhVkkYRRtqSPPybZ
	Olsy1M2x/b/b9yCL7fzVdvGz4Rq0EPWoeAptj05xaeBlQscvuUCzAycDtLUhbIukuunXU++prjR
	0JtMd
X-Gm-Gg: ASbGncsls+j/o6Ind8ENh6I6G/B728VNyn82NdvR1AMX744pzubo3Icmc0l57Zit1wE
	4fH9Qzui6ZbZW58xOSWVsVx6XJYsWvliL84I5C5X48jN6Xbk3/rTZw/HmxefuF4oyEAu8TONtu1
	KJqVd1+5lzuAWdwr8MLOLdH8hDsC16RjJKct9UlM+fkaQZaDcQsu7E4Gu19xWf3iTLqs2yRj9CC
	y7/ytUkBnMGL1GDe9zu2+uSuxpvaCmwBmfi8VqeT0S586lAXWyR5v60X/dU25OulzXpPknYPtaH
	SC6+KWdstrPQu9aQH817zZJBQqcr+h18qKfELxft+PdroafXK+XzEsp2GsLYxAuI2uWrlflz/Gi
	yRNRkPYblyOIsOnTphRnmy7+BYAzbmja/zLl/GfIY1zHt5ZgbGgwQnm3sEMjacTuiySxdrdal3j
	2v9V3zwZ/l9e1B8A==
X-Google-Smtp-Source: AGHT+IFvJYoRAgHsJ1qw2gDR6BJxWMXYvjkt0hr0WSyBV/MkZubx3SQQXrk5vJaXNTrCFWBTkk+gFg==
X-Received: by 2002:a5d:5f94:0:b0:3e7:610b:85f6 with SMTP id ffacd0b85a97d-3e765a142cemr2097407f8f.39.1757671497543;
        Fri, 12 Sep 2025 03:04:57 -0700 (PDT)
Message-ID: <66d13154-688f-4a7c-b273-d214c6fcd43b@citrix.com>
Date: Fri, 12 Sep 2025 11:04:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86: hvm: hypercall: use define instead of const in
 hvm_hypercall()
To: Grygorii Strashko ,
 "xen-devel@lists.xenproject.org" 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250912094702.1654772-1-grygorii_strashko@epam.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20250912094702.1654772-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/09/2025 10:47 am, Grygorii Strashko wrote:
> From: Grygorii Strashko 
>
> Use define X86_MODE_64BIT instead of constant in hvm_hypercall() for "mode"
> conditional check to improve code readability.
>
> Signed-off-by: Grygorii Strashko 

Acked-by: Andrew Cooper 

but this really needs to wait for 4.22 at this juncture.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 10:45:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 10:45:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121796.1465877 (Exim 4.92)
	(envelope-from )
	id 1ux1HH-0003v4-Ty; Fri, 12 Sep 2025 10:45:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121796.1465877; Fri, 12 Sep 2025 10: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 1ux1HH-0003ux-RN; Fri, 12 Sep 2025 10:45:15 +0000
Received: by outflank-mailman (input) for mailman id 1121796;
 Fri, 12 Sep 2025 10: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 1ux1HG-0003ur-EB
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 10:45:14 +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 8fdf6f9b-8fc5-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 12:45:13 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-45b9853e630so15579835e9.0
 for ; Fri, 12 Sep 2025 03:45:13 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607cd0a7sm5996429f8f.39.2025.09.12.03.45.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 03:45: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: 8fdf6f9b-8fc5-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757673913; x=1758278713; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+SerKqr29Yusp9y32AqQh/jGFD6z1ygWrvyt8tzKHQA=;
        b=Os12OWjCAFzRgREs6fjfvQdEaj2z9QPS6mLlwprUYv09XW0R6EAb0lcfIAwMjfCBz/
         RSQ1HyS1tb1UPxVDGTHnSLlZd6W8r6aGuJYOlCDp42WE50qqkXPvSrLdbaG8TAcHeC4x
         3vHPX5eSJHXVw8EgnT3P8Ln8RiyyAIZY2wZMA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757673913; x=1758278713;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+SerKqr29Yusp9y32AqQh/jGFD6z1ygWrvyt8tzKHQA=;
        b=SxCpKcJTBP9SAu9SmLZxan8GfFDVme+qqPREV4H31D9VSTCjiBvhCaXLM4NbG+doXM
         saU4czFhH2MJcWQwv0awqUyW4ctfuYNShcVoUfwdWSsWlfvRuHqMFAYf3ohU4CpkHXSI
         zJent0eeR2tsNl0//jBz9C/D1CRVjh1TiDfVCgDkFzKKxHYnC+qv523aCrw4QkSpexyh
         h+F47NLidhsA6nxshSjSeUqTB+aA4N0t55P92vl075SxqIUzLRWgjcPg6Jx582CWDVyX
         J8gG2eNT339/QRyKLKZJFdB2iomsSFFS6JWep2o9LdLCk1Lk48bcCq6NDrhKQD++girl
         FzwA==
X-Gm-Message-State: AOJu0YyfANc0DwiuI1mGW7eKKPoT8RHOVDnuAKx6icoMmgp/G/bPSxOt
	8PqepeHOGHVNOORue1jcqOXyiFYFnA6rnb+Y6rZL3g3NuLfZ45PwzqNk5SVIgqD1kcQ=
X-Gm-Gg: ASbGnctGURQQ/mEs6DQ67Wm+XnH98HkUvtPsU3MwGa4cUSf6PL0G58AatCfHutoP4Hu
	kiJn8A9bdelk6asJjmW7G273VjKuk/hEy5JlIrPIfRVHIpLHpSqu7v7bznkOAN32JY1bKRxsEME
	OBDSwbr23qimlci0NcQJhhWdpwPWEEzjMH7bwjBXk7OpF2tRyRsi+20/2by71F687ygXoC+MZKV
	KfbqV4ndusKiuf9gW+UL01Za6E1MMgaKJihDRBFRbw7RMog0DdKIqFZlfIlXIUsqrLCjBeB/fNt
	DadIWgrxQw4wZ5saKi4LTXeyzFHVaRAcEcfovncRs2keDScQQuAYgjDTKw+PJ0mIbGiJY6l0Pqi
	V1JUxMWiZWPaqvE+iIleMq5WA4K8cyecZH7kNe2uXPvMybPhUwedZWBvonCAP7Ol1drOe
X-Google-Smtp-Source: AGHT+IE5rf4mYeX5A/w4dbxr3y/pBz57ItSkxCCGExoopy9i+GO+g9OS5noavYIsUUwaAHBMWa9VJg==
X-Received: by 2002:a05:6000:471c:b0:3e7:b3de:6895 with SMTP id ffacd0b85a97d-3e7b3de6908mr683473f8f.16.1757673912860;
        Fri, 12 Sep 2025 03:45:12 -0700 (PDT)
Message-ID: <69f88053-9aa3-43ec-bae1-fd762f6a4522@citrix.com>
Date: Fri, 12 Sep 2025 11:45:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3.5/5] CI: Make qemu-smoke-x86-64-gcc-efi compatible
 with Debian Trixie
To: dmukhin@xen.org
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Shawn Anastasio ,
 Oleksii Kurochko ,
 Doug Goldstein ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Victor Lira ,
 Denis Mukhin 
References: <20250911231216.1886818-1-andrew.cooper3@citrix.com>
 <20250912011534.1889763-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 12/09/2025 3:39 am, dmukhin@xen.org wrote:
> On Fri, Sep 12, 2025 at 02:15:34AM +0100, Andrew Cooper wrote:
>> The OVMF package in Debian Trixie has _4M suffixes on the files.  Have
>> scripts/include/xtf-x86-64-efi check for this before falling back to no
>> suffix.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Denis Mukhin  

Thanks.

Testing revealed that I also need:

  -drive if=pflash,format=raw,file=${WORKDIR}/OVMF_VARS${suff}.fd

because the cp has ${WORKDIR} as the destination, so the file retains
it's source name.

I've folded this fix, and
https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11334759836
is happy now.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 10:56:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 10:56:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121832.1465887 (Exim 4.92)
	(envelope-from )
	id 1ux1Rm-0005fz-TS; Fri, 12 Sep 2025 10:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121832.1465887; Fri, 12 Sep 2025 10:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux1Rm-0005fs-Q6; Fri, 12 Sep 2025 10:56:06 +0000
Received: by outflank-mailman (input) for mailman id 1121832;
 Fri, 12 Sep 2025 10:56: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 1ux1KS-0004Xd-D1
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 10:48:32 +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 02a68c82-8fc6-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 12:48:26 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49])
 by mailfout.phl.internal (Postfix) with ESMTP id 75D50EC050D;
 Fri, 12 Sep 2025 06:48:25 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Fri, 12 Sep 2025 06:48:25 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 12 Sep 2025 06:48:24 -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: 02a68c82-8fc6-11f0-9809-7dc792cee155
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=1757674105;
	 x=1757760505; bh=963dbPAOfs1Spm78yUqe9iLdVpRYccnJ2wC05EW06cM=; b=
	SUuq3aS4iqe281VP+BIdwelOv2uHMX5CCNZRW0ohyMunNzvlBqAnkxWZWpTduVOf
	bmh/O0OeTUPkEZHo/jMYrME3U47ghIlCzacsx3/EVKLHT1gF/5jOjSxLrVcAVA+E
	WOfcymR3YZhAnMVWAwRvJi0UKe4emYBlrBY0sobftuqOdLba6x3aP6bhJVdJVWlY
	3uEEp9s025bYES8oto0s3735lKxjMC+OMcRYY1/mkR0hyXy5m1tXxoXNFe1bIfH+
	Wf4sz29UpwWYSm+0VGb+YXVgBqOKWmenQHtakQcuoWvAOt3gIVFhupqcomhYPubt
	XTodhP7IB/2Mis63H7C40Q==
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=
	1757674105; x=1757760505; bh=963dbPAOfs1Spm78yUqe9iLdVpRYccnJ2wC
	05EW06cM=; b=fre0adLlGUCb+Hqa290EeD311pTb9Nb3Whyq9B7/y4dmzkjHO66
	3EAkGJFwT3oHcxtHXW5wFOin/VmFCtbUvXKuIxbyspfa7coBO7+EhgEsvuTFyyW5
	9SXXRCcWPWtb93/g92WJ+M7yvgPDd530DpMSCDkEsyicr6Ffdd0lDpriRAyE7yYS
	1GllVCUWal4uNpmOmrqVcNnGlpDDNSKxQM/lZOpj11MIR9VW7kRPXrbnWPUp6vXh
	pWYx+9q6DkZYHwlSETr8M7OXd6OPR6TpkMeqM+7ai43KJMoYWGuXK7fwan8/4KL4
	5OetOkFAd4bJG2YoKq782n9EvpH6odvLr/A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvkeekhecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesghdtreertd
    dtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhi
    uceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqne
    cuggftrfgrthhtvghrnhepueekteetgefggfekudehteegieeljeejieeihfejgeevhfet
    gffgteeuteetueetnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedvpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhr
    tghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorh
    hg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 12 Sep 2025 12:48:22 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel 
Subject: Re: WARN in xennet_disconnect_backend when frontend is paused during
 backend shutdown
Message-ID: 
References: 
 <776ba15a-f922-407d-b1f2-2a2186c4729e@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="xdPowR8pAYgmS1+l"
Content-Disposition: inline
In-Reply-To: <776ba15a-f922-407d-b1f2-2a2186c4729e@suse.com>


--xdPowR8pAYgmS1+l
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Sep 2025 12:48:22 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel 
Subject: Re: WARN in xennet_disconnect_backend when frontend is paused during
 backend shutdown

On Fri, Sep 12, 2025 at 11:49:12AM +0200, J=C3=BCrgen Gro=C3=9F wrote:
> On 11.09.25 17:11, Marek Marczykowski-G=C3=B3recki wrote:
> > Hi,
> >=20
> > The steps:
> > 1. Have domU netfront ("untrusted" here) and domU netback
> > ("sys-firewall-alt" here).
> > 2. Pause frontend
> > 3. Shutdown backend
> > 4. Unpause frontend
> > 5. Detach network (in my case attaching another one follows just after,
> > but I believe it's not relevant).
> >=20
> > This gives the following on the frontend side:
> >=20
> >      ------------[ cut here ]------------
> >      WARNING: CPU: 1 PID: 141 at include/linux/mm.h:1328 xennet_disconn=
ect_backend+0x1be/0x590 [xen_netfront]
> >      Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_devic=
e snd_timer snd soundcore nft_reject_ipv6 nf_reject_ipv6 nft_reject_ipv4 nf=
_reject_ipv4 nft_reject nft_ct nft_masq nft_chain_nat nf_nat nf_conntrack n=
f_defrag_ipv6 nf_defrag_ipv4 nf_tables intel_rapl_msr intel_rapl_common int=
el_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_c=
lass intel_pmc_ssram_telemetry intel_vsec polyval_clmulnighash_clmulni_inte=
l xen_netfront pcspkr xen_scsiback target_core_mod xen_netback xen_privcmd =
xen_gntdev xen_gntalloc xen_blkback xen_evtchn i2c_dev loop fuse nfnetlink =
overlay xen_blkfront
> >      CPU: 1 UID: 0 PID: 141 Comm: xenwatch Not tainted 6.17.0-0.rc5.1.q=
ubes.1.fc41.x86_64 #1 PREEMPT(full)
> >      RIP: 0010:xennet_disconnect_backend+0x1be/0x590 [xen_netfront]
> >      Code: 00 0f 83 93 03 00 00 48 8b 94 dd 90 10 00 00 48 8b 4a 08 f6 =
c1 01 75 79 66 90 0f b6 4a 33 81 f9 f5 00 00 00 0f 85 f3 fe ff ff <0f> 0b 4=
9 81 ff 00 01 00 00 0f 82 01 ff ff ff 4c 89 fe 48 c7 c7 e0
> >      RSP: 0018:ffffc90001123cf8 EFLAGS: 00010246
> >      RAX: 0000000000000010 RBX: 0000000000000001 RCX: 00000000000000f5
> >      RDX: ffffea0000a05200 RSI: 0000000000000001 RDI: ffffffff82528d60
> >      RBP: ffff888041400000 R08: ffff888005054c80 R09: ffff888005054c80
> >      R10: 0000000000150013 R11: ffff88801851cd80 R12: 0000000000000000
> >      R13: ffff888053619000 R14: ffff888005d61a80 R15: 0000000000000001
> >      FS:  0000000000000000(0000) GS:ffff8880952c6000(0000) knlGS:000000=
0000000000
> >      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >      CR2: 00006182a11f3328 CR3: 000000001084c006 CR4: 0000000000770ef0
> >      PKRU: 55555554
> >      Call Trace:
> >       
> >       xennet_remove+0x1e/0x80 [xen_netfront]
> >       xenbus_dev_remove+0x6e/0xf0
> >       device_release_driver_internal+0x19c/0x200
> >       bus_remove_device+0xc6/0x130
> >       device_del+0x160/0x3e0
> >       ? _raw_spin_unlock+0xe/0x30
> >       ? klist_iter_exit+0x18/0x30
> >       ? __pfx_xenwatch_thread+0x10/0x10
> >       device_unregister+0x17/0x60
> >       xenbus_dev_changed+0x1d7/0x240
> >       xenwatch_thread+0x8f/0x1c0
> >       ? __pfx_autoremove_wake_function+0x10/0x10
> >       kthread+0xf9/0x240
> >       ? __pfx_kthread+0x10/0x10
> >       ret_from_fork+0x152/0x180
> >       ? __pfx_kthread+0x10/0x10
> >       ret_from_fork_asm+0x1a/0x30
> >       
> >      ---[ end trace 0000000000000000 ]---
> >      xen_netfront: backend supports XDP headroom
> >      vif vif-0: bouncing transmitted data to zeroed pages
> >=20
> > The last two are likely related to following attach, not detach.
> >=20
> > The same happens on 6.15 too, so it isn't new thing.
> >=20
> > Shutting down backend without detaching first is not really a normal
> > operation, and doing that while frontend is paused is even less so. But
> > is the above expected outcome? If I read it right, it's
> > WARN_ON_ONCE(folio_test_slab(folio)) in get_page(), which I find
> > confusing.
> >=20
> > Originally reported at https://github.com/QubesOS/qubes-core-agent-linu=
x/pull/603#issuecomment-3280953080
> >=20
>=20
> Hmm, with this scenario I imagine you could manage to have
> xennet_disconnect_backend() running multiple times for the same device
> concurrently.
>=20
> How reliable can this be reproduced? How many vcpus does the guest have?

Quite reliably (always?). And there are 2 vcpus.
Interestingly, it doesn't happen on 6.12.42, but does on 6.15.10 and
later.

> Maybe the fix is as simple as adding a lock in xennet_disconnect_backend(=
).

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

--xdPowR8pAYgmS1+l
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjD+nYACgkQ24/THMrX
1yzH3gf9H0GtaM1G+79g7rdizX7K6Hx+Wkj/G9zH9oyho9bpFvQ895KfCmknv71J
SICv63F5k4FDJMf/9D9DI3lecoeB4f8UnsPxEd/sNGCEAA9Rq9eer2IYgAdKaC1Y
5X74NigWJDo4jHwjPysEtFwCQJ0Ssmbz3jf8ulXsbisopX4CtlypIQbOcMgp2oi+
ebSrfOlkO9iaYsOSrRHT6GiI0qTdBRY0yC1BGzjMh/hzbQWLvWPGrFpfWIbnTzER
A7vbdxi4e1lxo+ao1djN94nmeTifTqI3Hg4OP8r3G+y+2jhj/AyPk6YeY9gK9SDX
huMCPYYK9Sz5/Dg8gB3MvsE0w4G4vw==
=thhx
-----END PGP SIGNATURE-----

--xdPowR8pAYgmS1+l--


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 12:19:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 12:19:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121902.1465899 (Exim 4.92)
	(envelope-from )
	id 1ux2kT-0007j3-St; Fri, 12 Sep 2025 12:19:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121902.1465899; Fri, 12 Sep 2025 12:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux2kT-0007iw-Ng; Fri, 12 Sep 2025 12:19:29 +0000
Received: by outflank-mailman (input) for mailman id 1121902;
 Fri, 12 Sep 2025 12:19: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 1ux2kR-0007iq-OT
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 12:19:27 +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 b89a7495-8fd2-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 14:19:25 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b07c38680b3so123672066b.1
 for ; Fri, 12 Sep 2025 05:19: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
 4fb4d7f45d1cf-62ee1fd6c0fsm1400841a12.5.2025.09.12.05.19.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 05:19: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: b89a7495-8fd2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757679565; x=1758284365; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ah9BmBT3PRBdzAisUp3GUqiyxcVdWnMdjbSEzd+vKNI=;
        b=fTbBrC/2y7kplqO7F4szVFrLVhbC3p9LEn4sVOV/g+T0BQJIrUcR+KyuWVKuNA6hKT
         eLBKE4SSrIEBJNP274y8M/1FRs3mzwFvJ48EKnmZJA9f47vPlaeOek+0wwcdU6Kq96K3
         /uV0mW0MSg38a4IEkOn2bRzmkade4/BAqXaife4q5E0ZT1bS6s0OuwfKvTdCFxp8Q4Nv
         sG6en8LKc5rSjPBEYbUPfqKS2Xa6iN0Wl3bM3Lk5BECZhyib7P+J3eWcnp1m1c4Mpmvw
         MqPYZc2bQgo8MFgDIaLsfptc5g/jj1QOwY12TqbdZG2D7cF9yjo7UP/99IYOS/TEDuJl
         u7Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757679565; x=1758284365;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ah9BmBT3PRBdzAisUp3GUqiyxcVdWnMdjbSEzd+vKNI=;
        b=acxT7riFlnRsF0pV7OwM52pDq07eXc5Gxj8juDGfT762Bq6R+kH+PzIxX1Wkyo3ebm
         Xb6tjTkNE1L/cIi4q/dYXwYPVYSVJqHQOmh8pmr0+DSR7hu1FziKyqePzB9fwaCOlZbg
         IyI4jbppdRVZbVz/aEq4MEgvQfK56hhUR8zYGEedg9CBrrmrY0mQhuUgBc1QY2NnAXFI
         sFHlDIluQQg1fzY4tX4A4sw2sIyfxYQYwxUEl2n25awrt3SxWNrRuvNCEQ4fKk8Ldzei
         ZeYl3glH1SMJMuiES/fbK0cf+TIIEjxOPZi54UIuoHXM1TSs03QTCk7LBhWjIUU1yypV
         MoMQ==
X-Forwarded-Encrypted: i=1; AJvYcCUIcQerSlaMX3aSRbASH5umeQwiQ/Cvl7on5eLrpcCPHsWMxZmFtFVIRkI/84q5KfGpmIJYSRX4TtU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz5VJJUnIwZDx4iEAHiZZwaZuA02hSFbPRyI4NBmFokgg/Eh3oH
	ZyGQbD4xXQ393TUgwbIjvy/2rJ4rbXpeuDe5+ytd6I6D6NLy4fmGFZYFqZBl3wzfKg==
X-Gm-Gg: ASbGncsAclIx25lC9sVoI0yshfrHvj/ZMG48ErmzzoUcs4iSEDcZ1NJ8GnpjZr39q20
	WS5X/L2NNw+CEyG105wJvtnT2ehmCj5lvxR9phH3i9bzyVNAoDh31IVeSAsNq2tlusB5PMSrg6t
	K6eJMhx9DFvg9gyW/7rZH8Bybyy9ft0t6rxLGN4KLPdfz5Bl5biCLCFWyskSv43IuDd4bMbnrLY
	P9XqM3Fz/8C27a70VxnLlhsFW0P/FGaxKbV18hzz6hWJ9d6OQk6NfSvn8GlHKcN32mXblVU4Fdb
	mlM0+nSS5WTY91JW+PTT+/8LFWgIyNjXMl5FrE1xVNrueABSsecucLMMN47kX9Q+qf6E7jCsjQS
	e0+/TyDEjPGlU16uH6J5Pu33ijwGKwUvtqNGa6GfGjfWm4kF80ot5aFvrUtFsmntyR7xSN2/ORi
	cnFO3cBDHVbQArWT2feA==
X-Google-Smtp-Source: AGHT+IEnk/AE7ZVaHib0lpAwHSkRelpaGXymI6aDcMDf/pSD9Gj2sIqHZUgdoE5ivbyYaGiacg+zAw==
X-Received: by 2002:a17:907:96a9:b0:afa:1d2c:2dc7 with SMTP id a640c23a62f3a-b07c3a7a7d2mr286829666b.57.1757679564614;
        Fri, 12 Sep 2025 05:19:24 -0700 (PDT)
Message-ID: 
Date: Fri, 12 Sep 2025 14:19:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] libacpi: Prevent CPU hotplug AML from corrupting
 memory
To: Alejandro Vallejo 
Cc: Anthony PERARD ,
 Grygorii Strashko ,
 xen-devel@lists.xenproject.org
References: <20250911162336.23887-1-alejandro.garciavallejo@amd.com>
 <20250911162336.23887-2-alejandro.garciavallejo@amd.com>
 <4b958afe-dfcd-4ac0-bc09-468e2b9b2710@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.09.2025 11:32, Alejandro Vallejo wrote:
> On Fri Sep 12, 2025 at 8:40 AM CEST, Jan Beulich wrote:
>> On 11.09.2025 18:23, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>>> by the device model. The GPE handler checks this and compares it against
>>> the "online" flag on each MADT LAPIC entry, setting the flag to its
>>> related bit in the bitmap and adjusting the table's checksum.
>>>
>>> The bytecode doesn't, however, stop at NCPUS. It keeps comparing until it
>>> reaches 128, even if that overflows the MADT into some other (hopefully
>>> mapped) memory. The reading isn't as problematic as the writing though.
>>>
>>> If an "entry" outside the MADT is deemed to disagree with the CPU bitmap
>>> then the bit where the "online" flag would be is flipped, thus
>>> corrupting that memory. And the MADT checksum gets adjusted for a flip
>>> that happened outside its range. It's all terrible.
>>>
>>> Note that this corruption happens regardless of the device-model being
>>> present or not, because even if the bitmap holds 0s, the overflowed
>>> memory might not at the bits corresponding to the "online" flag.
>>>
>>> This patch adjusts the DSDT so entries >=NCPUS are skipped.
>>>
>>> Fixes: 087543338924("hvmloader: limit CPUs exposed to guests")
>>> Reported-by: Grygorii Strashko 
>>> Signed-off-by: Alejandro Vallejo 
>>
>> In principle:
>> Reviewed-by: Jan Beulich 
> 
> Cheers,
> 
>>
>> However, ...
>>
>>> --- a/tools/libacpi/mk_dsdt.c
>>> +++ b/tools/libacpi/mk_dsdt.c
>>> @@ -231,6 +231,20 @@ int main(int argc, char **argv)
>>>      stmt("Store", "ToBuffer(PRS), Local0");
>>>      for ( cpu = 0; cpu < max_cpus; cpu++ )
>>>      {
>>> +        if ( cpu )
>>> +        {
>>> +            /*
>>> +             * Check if we're still within the MADT bounds
>>> +             *
>>> +             * LLess() takes one byte, but LLessEqual() takes two. Increase
>>> +             * `cpu` by 1, so we can avoid it. It does add up once you do it
>>> +             * 127 times!
>>> +             */
>>> +            push_block("If", "LLess(\\_SB.NCPU, %d)", 1 + cpu);
>>> +            stmt("Return", "One");
>>
>> ... if you already care about size bloat in the conditional, why are the two
>> bytes per instance that this extra return requires not relevant? They too
>> add up, and they can be avoided by wrapping the If around the rest of the
>> code. I didn't count it, but I expect the If encoding to grow by at most one
>> byte, perhaps none at all.
> 
> I don't mind either way. Removing the "return" statement and the pop_block()
> would save 254 bytes in tota at most. I don't think the conditional would grow
> because the there wouldn't be that much contained within, but regardless the
> early return is in the spirit of not going through 127 conditionals on every
> GPE handle when you typically only have a handful of CPUs. The sooner we drop
> out of AML, the better.
> 
> In due time I want to shrink this to be an AML loop in dsdt.asl so it can
> be taken out of mk_dsdt.c. That will both shrink the DSDT (a ton) and accelerate
> GPE handling, but I don't have time to do it at the moment.
> 
> Do you have a preference in table size vs execution-time?

Personally I'd favor table size. The AML interpreter is slow anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 12:38:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 12:38:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121922.1465907 (Exim 4.92)
	(envelope-from )
	id 1ux32s-00027e-As; Fri, 12 Sep 2025 12:38:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121922.1465907; Fri, 12 Sep 2025 12: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 1ux32s-00027X-7z; Fri, 12 Sep 2025 12:38:30 +0000
Received: by outflank-mailman (input) for mailman id 1121922;
 Fri, 12 Sep 2025 12: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 1ux32r-00027R-Q9
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 12:38:29 +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 612e2c9c-8fd5-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 14:38:28 +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 58C4NGak023577;
 Fri, 12 Sep 2025 12:37:48 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490cmxbgbt-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 12:37:48 +0000 (GMT)
Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 58CCZk7V019437;
 Fri, 12 Sep 2025 12:37:47 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 490cmxbgbr-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 12:37:47 +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 58CAHmfd007982;
 Fri, 12 Sep 2025 12:37:46 GMT
Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 49109q2yat-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 12:37:46 +0000
Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com
 [10.20.54.100])
 by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 58CCbiaW43581748
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 12 Sep 2025 12:37:44 GMT
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id F244B20043;
 Fri, 12 Sep 2025 12:37:43 +0000 (GMT)
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 2D0D220040;
 Fri, 12 Sep 2025 12:37:43 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri, 12 Sep 2025 12:37:43 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 612e2c9c-8fd5-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=F/QMkXR0QmFDH2hSNcKmtWCaKqZWJp
	/K34Yf9Q/vV4o=; b=cj9ccOMz3g4C+PjNeaWiuuTaP4HNhRLpXSoNy8fDYBJ3tk
	7VmA5YJda8fjEnU3nV9LYEJ0vevAyi5kPStuOoThm2LttsPn7OqSUIv9hpgYHrDl
	VM/aZj0XTYswaLwEhX4chi7Xmx3veV2pPSKQE7Xpwhzl/TPEp2EAuPOeuv511Ow4
	GdjQgA67d2m8iwQ5Lwg5nwGJfFU1oEES3U34uXlfpBV2PZpk1btufFqXlMgXkSrh
	hrBnft6mO7kvHVsAtqgMa22uMd+6dFXCBNXIQ9bxYg5JQfOYQABNv/34YA++priZ
	YK5q9EfpN5W8w2jVpUGi5mI4pVFy6aKSSO89ulWA==
Date: Fri, 12 Sep 2025 14:37:41 +0200
From: Alexander Gordeev 
To: David Hildenbrand 
Cc: Kevin Brodsky , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        Mark Rutland 
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
References: <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: DzRH41cgO_SjjRs72WZBVybY8ExotUyL
X-Proofpoint-ORIG-GUID: 5szjY0KVwgiaHLPdjEz_BJ9YvOIOK4Xh
X-Authority-Analysis: v=2.4 cv=J52q7BnS c=1 sm=1 tr=0 ts=68c4141c cx=c_pps
 a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=VnNF1IyMAAAA:8 a=nv4XAxrWCHwsSIOw55kA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDAyNSBTYWx0ZWRfX86gaOQ1LrR1y
 +AynjQ4AgALVhtZYKnZDDT8c+j9DRk8HERAKDNNp36tCtsrKRRJnQfrOFLxyYdnAr8hyqmeGA1f
 1prxUpnPJ5rXvIAgmJzbfZjhxXBnmxRp2iqjJgJ3i90OwHrL2TrKP54cHw5M3qK3XhAF0n2TpPW
 RsnjxBxBdvNnEesXLpwgkw7dWSF2rosg2AqDmw/wB76gRXWMNRK5mr5x7N99pH4pGAXXTiU4uVS
 i159bhlfOwCXD+7CDYya0yNVx3NBZFrGp9nJP7w5HEd4jjYX/OX0RgcnOvpZcS7CewzKLkB5WKW
 CUaIccrW4ap26mcSEi1Rt8r0K+KbR+7MT6HbSo+gGNNB0kqns8XawW6Wq5nSDOWHRsM/E9JdJ0e
 dqDgxgLq
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-12_04,2025-09-11_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 impostorscore=0 clxscore=1015 suspectscore=0 spamscore=0 phishscore=0
 bulkscore=0 adultscore=0 malwarescore=0 priorityscore=1501
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509060025

On Fri, Sep 12, 2025 at 10:55:50AM +0200, David Hildenbrand wrote:

Hi David, Kevin,

> Great, looking forward to seeing this all getting cleaned up and done
> properly for good.

I am currently working on lazy mmu for s390 and this nesting
initiative kind of interferres. Well, in fact it looks like
it does not, but I am bit lost in last couple of iterations ;)

The prerequisite for s390 would be something like the change
below. With that change I can store the context in a per-cpu
structure and use it later in arch-specific ptep_* primitives.

Moreover, with a further (experimental) rework we could use
a custom kasan sanitizer to spot false directly compiled
PTE accesses, as opposed to set_pte()/ptep_get() accessors.

I am not quite sure see whether this could be derailed by
the new lazy mmu API. At least I do not immediately see any
obvious problem. But may be you do?


[PATCH] mm: Make lazy MMU mode context-aware

The lazy MMU mode is assumed to be context-independent in a
sense the MMU does not need any additional data in lazy mode.
Yet, s390 architecture may benefit strongly if it knows the
exact page table entries being changed while in lazy mode.

Introduce arch_enter_lazy_mmu_mode_pte() that is provided
with the process memory space and the page table being
operated on as the prerequisite for s390 optimization.
It is expected to be called only against PTE page tables
and never cross the page table boundary.

There is no change for architectures that do not need any
context.

Signed-off-by: Alexander Gordeev 
---
 fs/proc/task_mmu.c      | 2 +-
 include/linux/pgtable.h | 8 ++++++++
 mm/madvise.c            | 8 ++++----
 mm/memory.c             | 8 ++++----
 mm/mprotect.c           | 2 +-
 mm/mremap.c             | 2 +-
 mm/vmalloc.c            | 6 +++---
 7 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 751479eb128f..02fcd2771b2a 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -2493,7 +2493,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 		return 0;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(vma->vm_mm, start, end, start_pte);
 
 	if ((p->arg.flags & PM_SCAN_WP_MATCHING) && !p->vec_out) {
 		/* Fast path for performing exclusive WP */
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 0b6e1f781d86..16235c198bcb 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -235,6 +235,14 @@ static inline int pmd_dirty(pmd_t pmd)
 #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_pte(struct mm_struct *mm,
+						unsigned long addr,
+						unsigned long end,
+						pte_t *ptep)
+{
+	arch_enter_lazy_mmu_mode(); 
+}
 #endif
 
 #ifndef pte_batch_hint
diff --git a/mm/madvise.c b/mm/madvise.c
index 1d44a35ae85c..d36d4dc42378 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -448,7 +448,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	if (!start_pte)
 		return 0;
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(mm, addr, end, start_pte);
 	for (; addr < end; pte += nr, addr += nr * PAGE_SIZE) {
 		nr = 1;
 		ptent = ptep_get(pte);
@@ -509,7 +509,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 				if (!start_pte)
 					break;
 				flush_tlb_batched_pending(mm);
-				arch_enter_lazy_mmu_mode();
+				arch_enter_lazy_mmu_mode_pte(mm, addr, end, start_pte);
 				if (!err)
 					nr = 0;
 				continue;
@@ -678,7 +678,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!start_pte)
 		return 0;
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(mm, addr, end, start_pte);
 	for (; addr != end; pte += nr, addr += PAGE_SIZE * nr) {
 		nr = 1;
 		ptent = ptep_get(pte);
@@ -743,7 +743,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 				if (!start_pte)
 					break;
 				flush_tlb_batched_pending(mm);
-				arch_enter_lazy_mmu_mode();
+				arch_enter_lazy_mmu_mode_pte(mm, addr, end, pte);
 				if (!err)
 					nr = 0;
 				continue;
diff --git a/mm/memory.c b/mm/memory.c
index b0cda5aab398..93c0b8457eb0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1131,7 +1131,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
 	orig_src_pte = src_pte;
 	orig_dst_pte = dst_pte;
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(src_mm, addr, end, src_pte);
 
 	do {
 		nr = 1;
@@ -1723,7 +1723,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		return addr;
 
 	flush_tlb_batched_pending(mm);
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(mm, addr, end, start_pte);
 	do {
 		bool any_skipped = false;
 
@@ -2707,7 +2707,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 	mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
 	if (!pte)
 		return -ENOMEM;
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(mm, addr, end, mapped_pte);
 	do {
 		BUG_ON(!pte_none(ptep_get(pte)));
 		if (!pfn_modify_allowed(pfn, prot)) {
@@ -3024,7 +3024,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			return -EINVAL;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(mm, addr, end, mapped_pte);
 
 	if (fn) {
 		do {
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 88608d0dc2c2..919c1dedff87 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -106,7 +106,7 @@ static long change_pte_range(struct mmu_gather *tlb,
 		target_node = numa_node_id();
 
 	flush_tlb_batched_pending(vma->vm_mm);
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(vma->vm_mm, addr, end, pte);
 	do {
 		oldpte = ptep_get(pte);
 		if (pte_present(oldpte)) {
diff --git a/mm/mremap.c b/mm/mremap.c
index 60f6b8d0d5f0..08b9cb3bb9ef 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -233,7 +233,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
 	if (new_ptl != old_ptl)
 		spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
 	flush_tlb_batched_pending(vma->vm_mm);
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(mm, old_addr, old_end, old_pte);
 
 	for (; old_addr < old_end; old_pte++, old_addr += PAGE_SIZE,
 				   new_pte++, new_addr += PAGE_SIZE) {
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 6dbcdceecae1..29cfc64970a5 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -105,7 +105,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	if (!pte)
 		return -ENOMEM;
 
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(&init_mm, addr, end, pte);
 
 	do {
 		if (unlikely(!pte_none(ptep_get(pte)))) {
@@ -359,7 +359,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);
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(&init_mm, addr, end, pte);
 
 	do {
 #ifdef CONFIG_HUGETLB_PAGE
@@ -526,7 +526,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!pte)
 		return -ENOMEM;
 
-	arch_enter_lazy_mmu_mode();
+	arch_enter_lazy_mmu_mode_pte(&init_mm, addr, end, pte);
 
 	do {
 		struct page *page = pages[*nr];

> David / dhildenb

Thanks!


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 12:41:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 12:41:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121935.1465918 (Exim 4.92)
	(envelope-from )
	id 1ux35S-0003am-Ow; Fri, 12 Sep 2025 12:41:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121935.1465918; Fri, 12 Sep 2025 12: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 1ux35S-0003af-LF; Fri, 12 Sep 2025 12:41:10 +0000
Received: by outflank-mailman (input) for mailman id 1121935;
 Fri, 12 Sep 2025 12:41: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 1ux35R-0003aZ-KM
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 12:41:09 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bd988f92-8fd5-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 14:41:03 +0200 (CEST)
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
 [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-508-uFpQm-wcNXCjFI4pB2hSVQ-1; Fri, 12 Sep 2025 08:41:00 -0400
Received: by mail-wm1-f70.google.com with SMTP id
 5b1f17b1804b1-45deddf34b9so17325705e9.1
 for ; Fri, 12 Sep 2025 05:41:00 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f20:da00:b70a:d502:3b51:1f2d?
 (p200300d82f20da00b70ad5023b511f2d.dip0.t-ipconnect.de.
 [2003:d8:2f20:da00:b70a:d502:3b51:1f2d])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e0372ae57sm60050545e9.8.2025.09.12.05.40.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 05: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: bd988f92-8fd5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757680861;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=iMoIwx8Fq7mQjvBVlaYyQNpQMDf4JO+RcpWFZz45CMg=;
	b=L3x7sOxXeoX4Ez1i9TUHu1NQVTocckaO6l3LdUWbess1psN78SxuRICFrMLvk1MX4LvsCj
	5VDT6L1/v9sALGwup8sMcrcyvzGqckgtKN4cHQXHnojVgogbuRySCGdNhRKIb+hVdE60G2
	N2uFfrfl4cS0q1j1FEomBc1Hc/LSs9Q=
X-MC-Unique: uFpQm-wcNXCjFI4pB2hSVQ-1
X-Mimecast-MFC-AGG-ID: uFpQm-wcNXCjFI4pB2hSVQ_1757680859
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757680859; x=1758285659;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=iMoIwx8Fq7mQjvBVlaYyQNpQMDf4JO+RcpWFZz45CMg=;
        b=TGpqA09PyZXI5KeiNLhgwPFHVPScxjulgKLgrTNc6pNcBXhR5UL9QLWOzLS7LAkm00
         3hIIm7a/2aClEoKZRYZ+hCAA8QCFpKTsDYmHzZjIwy7k6F9OI3RQJ6cby4aHsQkPq66H
         R0uNr+g1v2mGkdHtXAkPrIbTYRRg/v98AAngACDtQ8JozHSj+GL/1vYl0R647UNfurYj
         5ZmbqMeu+SY6xrYKpt+zqO+aomon8fdoWH0Xm7+knFibNFYPJi2OkEBEQWupd/j6f2W9
         kRAf+4ENk8/W5JYYAc6Ozkq2VEUYJoxQ5Mp9J8ODQvLHE3Y6QqOKm5cAdPL5CAqMBsSF
         eqzQ==
X-Forwarded-Encrypted: i=1; AJvYcCVdAiZmo7J4zB51TuMYEQsQpbCEOGaWsp0umyg423AEPTn40/9Vy6JfamACzMOJkiOmfaSrApBh/Os=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLfK+uObzY1+ckEC9xAFC/F8tS+iUMUH8qjKdB/DoHSGGi2Hq3
	vuBZtHzrWKoXLELLCCzo6e7jH8uJ3u4XPvg/O+NJO7GJ98rXIwsKMm0C2//up/3VBvR/WTPoHx6
	mEpSK/Uv6TPfFhIIuywYWRWc5DjGyW0lgFFA4AeYPnoBkTDpSuJcCT3DGLORIYEe/PtY+
X-Gm-Gg: ASbGncsf9YZCetKGuQnl71KsAgRXTwlQedBMTh+wSV2kZGEqC2pLvB3VINuF4RdjN7J
	CzMR/Wv0TQlSo4/0zu5Lo/IKoycWuvLWx/fpocG69/Q7Q2PinAae2vqr+zyldHXLFiaq/pQp0/0
	b1d0gl4I89CMtaZ6jVB+28i/+xgav4msF+D/hBefH1c0qDGKXy66CsvfH+azepfV9XkNgXt9rGG
	BJO0DLP7EOq1icASqecNj7zlVzGuJi+SLB8QgtkM0HV43PNezMIA5SnlDkzvMQdsk0+upNgJeKY
	f0zHU2ytx8bYP29WKEYR0CevAIB3nY+yGp3Pr4ZjaAMmCD4nKW5G5mVVqYpc4x3kAFP+SXvyxas
	pNxiIt1YmEtxAphv6MmO/J98tvTLNeKeSt2oCnn3rzo/VuQXuj8p7xOPKg0TRKk+cmDM=
X-Received: by 2002:a05:600c:1daa:b0:459:d577:bd24 with SMTP id 5b1f17b1804b1-45ed647a10cmr35610305e9.7.1757680859012;
        Fri, 12 Sep 2025 05:40:59 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEVEThTm8r9XP8uPlz9qkFfWXl+PlwCvx30XVhJYO0zMEAs87UYsFy+ktNpyiVcKL2vVNFxRw==
X-Received: by 2002:a05:600c:1daa:b0:459:d577:bd24 with SMTP id 5b1f17b1804b1-45ed647a10cmr35609685e9.7.1757680858542;
        Fri, 12 Sep 2025 05:40:58 -0700 (PDT)
Message-ID: <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
Date: Fri, 12 Sep 2025 14:40:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: Kevin Brodsky , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <47ee1df7-1602-4200-af94-475f84ca8d80@arm.com>
 <29383ee2-d6d6-4435-9052-d75a263a5c45@redhat.com>
 <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
 <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: VegPScGpTMKrhjQJNSWspqR9H0BvaWIkUr2PfHhngNw_1757680859
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12.09.25 14:37, Alexander Gordeev wrote:
> On Fri, Sep 12, 2025 at 10:55:50AM +0200, David Hildenbrand wrote:
> 
> Hi David, Kevin,
> 
>> Great, looking forward to seeing this all getting cleaned up and done
>> properly for good.
> 
> I am currently working on lazy mmu for s390 and this nesting
> initiative kind of interferres. Well, in fact it looks like
> it does not, but I am bit lost in last couple of iterations ;)
> 
> The prerequisite for s390 would be something like the change
> below. With that change I can store the context in a per-cpu
> structure and use it later in arch-specific ptep_* primitives.
> 
> Moreover, with a further (experimental) rework we could use
> a custom kasan sanitizer to spot false directly compiled
> PTE accesses, as opposed to set_pte()/ptep_get() accessors.
> 
> I am not quite sure see whether this could be derailed by
> the new lazy mmu API. At least I do not immediately see any
> obvious problem. But may be you do?

It would just be passing more context down to the architecture, right?

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 12:57:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 12:57:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121965.1465929 (Exim 4.92)
	(envelope-from )
	id 1ux3LL-0005lI-6K; Fri, 12 Sep 2025 12:57:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1121965.1465929; Fri, 12 Sep 2025 12: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 1ux3LL-0005lB-2F; Fri, 12 Sep 2025 12:57:35 +0000
Received: by outflank-mailman (input) for mailman id 1121965;
 Fri, 12 Sep 2025 12: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 1ux3LJ-0005l5-Qc
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 12:57:33 +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 08d50648-8fd8-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 14:57:28 +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 58CAlUZY015991;
 Fri, 12 Sep 2025 12:56:54 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490cffuknu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 12:56:53 +0000 (GMT)
Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 58CCpNN7003042;
 Fri, 12 Sep 2025 12:56:53 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 490cffuknk-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 12:56:53 +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 58CALT4M007950;
 Fri, 12 Sep 2025 12:56:51 GMT
Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 49109q31gu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 12:56:51 +0000
Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com
 [10.20.54.100])
 by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 58CCunWS30671476
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 12 Sep 2025 12:56:49 GMT
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 8EA2220043;
 Fri, 12 Sep 2025 12:56:49 +0000 (GMT)
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id C6AEE20040;
 Fri, 12 Sep 2025 12:56:48 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri, 12 Sep 2025 12:56:48 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08d50648-8fd8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=58XwPAOdgj8C/KnRAhD4XHr5Jy4g4v
	ejUcQ6Kbk//CM=; b=PINgmJaTmGHdAT2AF+hgUasxjL9BP3ekGD0+BKKS7KwoK8
	sGABYUGDODVMXQiHgWK+c+K5Qk7qSwsgdR60qqAZLzYDpggZETp3z0psgslZEABv
	bBcX5ESEIDmK3Ssh4H9tOANdUsDC4ve3Ss2+F7gv0b2x4eL+/WuLL75MKzVSTweJ
	BnHNEduw3NBEZJnatPGxz4bNXovlyj8qkSo5dnKOW7TDpBEP+nN+NRBZl40CS5Tr
	qNJ/GWrhyJzczvz2SBRv1DGgGFj+1abS9It+4g1b4P1w7KVsvZsRQWs+fZ5Ni2Pe
	K7Sikg3vWmUIf/JocL9wcnOqBq8GCKYq4CYPpeqQ==
Date: Fri, 12 Sep 2025 14:56:47 +0200
From: Alexander Gordeev 
To: David Hildenbrand 
Cc: Kevin Brodsky , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        Mark Rutland 
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com>
References: <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
 <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
 <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: VjJg1bjgqAhkPIFaDf1mLUh7KWJjYCG6
X-Proofpoint-GUID: sT9Q6O7KpHDMezFzmg7Jr_oCplhrH_ZC
X-Authority-Analysis: v=2.4 cv=EYDIQOmC c=1 sm=1 tr=0 ts=68c41895 cx=c_pps
 a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=uYqTi1GheQgrfgZHFtwA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDAyMCBTYWx0ZWRfX5jpC8GUVmzcb
 WNTQnHEt7CYJzjyNcPBhadLwyx9qWJPieT278SgOv0+fgDWmcDKSO9n/bVKVzE2Km2J/kquNqse
 Jo2h4tBAH3Rq2bzLQZKuYkpibwvUYGVvMaMFCBcqCEiBXpyJ/14KPD+uGmPeQ+53nO3UReJyF9T
 vV9SHmTpFlxTvywhGFj1lAohZo5EPieMQrww4F/cF8jq4d9H2qtG/up3a2vR/gmEjopqXn2qMS8
 3cpWLt2lTNHCVrgNs3lbLBPz8/ZfWPrNMNeF/iwV1NkiQwT301stt/rMbx65ewChkpW8jMQrt+D
 mygDppYgjygKsvAP9O23nIW8cFyauWRb1MftHnofDLV/qfCy2wrFGsX2zoH6Hz3rIIVyUeTZ9rw
 xobmB0cV
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-12_04,2025-09-11_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 impostorscore=0
 priorityscore=1501 phishscore=0 clxscore=1015 bulkscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509060020

On Fri, Sep 12, 2025 at 02:40:55PM +0200, David Hildenbrand wrote:
> It would just be passing more context down to the architecture, right?

Yes. Namely this one would be arch-defined and arch_enter_lazy_mmu_mode()
by default.

static inline void arch_enter_lazy_mmu_mode_pte(struct mm_struct *mm,
						unsigned long addr,
						unsigned long end,
						pte_t *ptep)
{
	...
}

> David / dhildenb


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 13:02:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 13:02:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1121989.1465938 (Exim 4.92)
	(envelope-from )
	id 1ux3Q2-0007Ly-NG; Fri, 12 Sep 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 1121989.1465938; Fri, 12 Sep 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 1ux3Q2-0007Lr-JH; Fri, 12 Sep 2025 13:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1121989;
 Fri, 12 Sep 2025 13: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 1ux3Q1-0007Lg-6c
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 13:02:25 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b8886cc6-8fd8-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 15:02:22 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-494-DWVQDCELPrWgFuYN0iSUsQ-1; Fri, 12 Sep 2025 09:02:20 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-45dde353979so10851915e9.3
 for ; Fri, 12 Sep 2025 06:02:20 -0700 (PDT)
Received: from [192.168.3.141] (p4ff1f73f.dip0.t-ipconnect.de. [79.241.247.63])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607d7c0dsm6591328f8f.47.2025.09.12.06.02.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 06:02: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: b8886cc6-8fd8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757682141;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=T6pmjetwrY6Pjkps/LwmTPHSQvgSA/RNS+9TNChzIHs=;
	b=QQP0WTo/VeIyxCPCbVUe5AJXBgefOo1dAYKoVQKlcex/v0MHo3cyWnkqSllUu2HYa56l8K
	iDoQnuACefG/me47bk9o1JBWya3UaWUlf3MXdB5JW6oV5hpkVtzbLQAnuW55k4XStx3wbl
	aYbTS0n827opu30kCIeopIeavm0DR1E=
X-MC-Unique: DWVQDCELPrWgFuYN0iSUsQ-1
X-Mimecast-MFC-AGG-ID: DWVQDCELPrWgFuYN0iSUsQ_1757682139
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757682139; x=1758286939;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=T6pmjetwrY6Pjkps/LwmTPHSQvgSA/RNS+9TNChzIHs=;
        b=smje0QXIUi9kDs8VkjLcGqyNNOaDedhM0jpun/NC/neoqU6wAevJJd0TKsyb/I77Eb
         EAl1ACqo0OWrck1JQw8nTGwRFPa3l997V1o67jx+u92ckYgu/bPBiqpJDaQVeLo1xnyS
         y2AXW+OIMhJSYqLKicLbAivl0BQuQCUYEhKYwGOp+2OqP7OaZ5NgTrU/cS31LPWaiWL7
         jV/987JwGqmwW5aFxTaK46zoPlepg2Re5/91IASIAvWnlJFdoqFE1igrKfT4h3kR22cV
         yDRP/afsRDKXrK80gYNOe4mCQG4owtHwQGJkfDwUfFZZbruiFEkvyqxBYF3iaanxnqHT
         Wgzg==
X-Forwarded-Encrypted: i=1; AJvYcCV8+3ksLNWz59RRCK9ZRn4GbpcbzHZaD3kjC3CzKHsqjK2nlDA6u4WGomw0ifmH8U8zuQGAFpzMbp8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysQ7oD2LIqhleFwphGGO/w3oMjZevTheLVEbYaTOi7LR9dKvzp
	bnIgtDzmeChYC78wS/4beRpqfkKENbKOTZKMTUmmT4yWO9e85KKc4VqwTFoddl3T4f6TT3IBEEC
	+DhMPyXOYMUAzUdFUvD/o9R2KkYcRt/msnjtbxioly4ebZ5Q/B5Xn3qZy8kxrieskmmNO
X-Gm-Gg: ASbGncvRXm8zVqE1aSr4PLb4NGNObCHn3ECKdipilsghc0NLOcwJn7gaOj/ehsOOnTO
	45w5jk7nCbBhvJqhx5mL3leCtHPqTu6ABTqY2ZroqDIhyrXEnCDCrMkNu5GSlZjH1lj37xIcgmd
	msfltRpANw9ThzPgEW9ia+b7sREZ+1HfQHRpZDSJgkkX3Gyb81HOcxBnRkFlx9I8Q+HUwXzxpxK
	Gq9o0dhOpWt0yEzJHj7tOcwCLcZuFTtMZp21c41l1jCbIsTw7uXWw/thC5bYdz4Ge6YPrscmUJG
	sUgPnJ3baBKw9sfhNwD96XcGXHy1NSPB2P6iDVgw1tyovbH3fQQA3ks86dBwwszqEBDW3w==
X-Received: by 2002:a7b:c8cd:0:b0:459:e466:1bec with SMTP id 5b1f17b1804b1-45f211cb997mr19987525e9.2.1757682139297;
        Fri, 12 Sep 2025 06:02:19 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IE8835/Sw5cx2XNXD41yV+ksXCYwqrt5aGn88DM3+Lr7h6frt33fSGmBjo6KK3fA6Iu30zVDA==
X-Received: by 2002:a7b:c8cd:0:b0:459:e466:1bec with SMTP id 5b1f17b1804b1-45f211cb997mr19986575e9.2.1757682137932;
        Fri, 12 Sep 2025 06:02:17 -0700 (PDT)
Message-ID: 
Date: Fri, 12 Sep 2025 15:02:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: Kevin Brodsky , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <9de08024-adfc-421b-8799-62653468cf63@arm.com>
 
 <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
 <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
 <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
 <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com>
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: _r4a0HBnP6e6xMd4NRldpsxByO9KhGjUd3UEcQNlNLw_1757682139
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12.09.25 14:56, Alexander Gordeev wrote:
> On Fri, Sep 12, 2025 at 02:40:55PM +0200, David Hildenbrand wrote:
>> It would just be passing more context down to the architecture, right?
> 
> Yes. Namely this one would be arch-defined and arch_enter_lazy_mmu_mode()
> by default.
> 

How would that work with nesting? I feel like there is a fundamental 
problem with nesting with what you describe but I might be wrong.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:06:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:06:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122042.1465947 (Exim 4.92)
	(envelope-from )
	id 1ux4PU-000737-40; Fri, 12 Sep 2025 14:05:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122042.1465947; Fri, 12 Sep 2025 14: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 1ux4PU-000730-1B; Fri, 12 Sep 2025 14:05:56 +0000
Received: by outflank-mailman (input) for mailman id 1122042;
 Fri, 12 Sep 2025 14:05: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 1ux4PT-00072u-B0
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:05:55 +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 97d756a0-8fe1-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:05:54 +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 58C386ET024821;
 Fri, 12 Sep 2025 14:05:14 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 490cmxby8m-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 14:05:13 +0000 (GMT)
Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 58CE2ClP009324;
 Fri, 12 Sep 2025 14:05:13 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 490cmxby8e-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 14:05:13 +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 58CAOXI1010588;
 Fri, 12 Sep 2025 14:05:11 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4910snb7ur-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 12 Sep 2025 14:05:11 +0000
Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com
 [10.20.54.100])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 58CE59N522544674
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 12 Sep 2025 14:05:09 GMT
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 536162004B;
 Fri, 12 Sep 2025 14:05:09 +0000 (GMT)
Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 8D07120043;
 Fri, 12 Sep 2025 14:05:08 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri, 12 Sep 2025 14:05:08 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 97d756a0-8fe1-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=1Fi+81t5zqEybF/Ll9ApuHFjhXkkb1
	vHdHvbxL0Vc8U=; b=JdymV3ITkTcSWYrGAqYC9vUBwbPERmwdJ7SwSpzPahVcmB
	br9gT4phgvwygUUAi3bNoWfXtnHy6dCZTXY+1IcGYGCd6MSDvQFtwZ59FVh14Zkm
	vfzwu2r9YJDSn9D4O25/8kKQeaXBrfxGz7ow9SGeZK6IqKoWvjNrVhipWaODarli
	GtDPVfrbEzN5BeTqC/p995pcDrx5upjpVdi3aGcDIMnh5WmfSVmAgJWAuMpIitpB
	dx+gg/KyXJBqYUJvppfytE11Gs6VCBfid+zHk9Mld+hpjF8BzLN0R4DoaJen6tmh
	Qsj/3X1kE2+aoD7/v/vGVE9/PNoEAxLm1WFuoGLQ==
Date: Fri, 12 Sep 2025 16:05:07 +0200
From: Alexander Gordeev 
To: David Hildenbrand 
Cc: Kevin Brodsky , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Andrew Morton ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        Mark Rutland 
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
Message-ID: 
References: <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
 <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
 <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
 <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: ZMmKMxWqtsslbAtdOPAzBRJYU4GL7wAu
X-Proofpoint-ORIG-GUID: j5mM8DCXgm3DPCWWxntSIgsJIjsuTDHV
X-Authority-Analysis: v=2.4 cv=J52q7BnS c=1 sm=1 tr=0 ts=68c42899 cx=c_pps
 a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17
 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=xegNWJJ1Rn4Hofgs2fcA:9
 a=CjuIK1q_8ugA:10
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTA2MDAyNSBTYWx0ZWRfXyQgs4MJipRKm
 Vh4mPp8mP6XTDOkYJ7/naEofqsCMunScyHXUNGqkDffcXe8gbUTaR6visxv0m0kRskga/a5g93o
 Y0rVCYsKPe9P0+nMVlo+OxrV7SEnalYxsvJH/2d4bx8m5Zotd/48CmrUGFK82F0g4ZHLlVG2QyQ
 v9UaEdTcRwYdLo8RFKENqA+3oT6sxrdZPoE2SA+aupZ9ucY0p/3lfsPwTVCbkACKw9viHKZUPh5
 sUwnl0/J1iAjs+cvRsvj5o5BYd545b8qOoQTDQow9AxgiianjYJVfAmcO4Lvo/OxYU1Zraata1S
 PL9YSDjhZWpLjBNA8UeDChKZIto5ViRARZ1acta2OR59pSCA4kyBpUWrv47WX0z1P1aU2UCNZhg
 VoRSX1Jb
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-12_05,2025-09-11_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 impostorscore=0 clxscore=1015 suspectscore=0 spamscore=0 phishscore=0
 bulkscore=0 adultscore=0 malwarescore=0 priorityscore=1501
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509060025

On Fri, Sep 12, 2025 at 03:02:15PM +0200, David Hildenbrand wrote:
> How would that work with nesting? I feel like there is a fundamental problem
> with nesting with what you describe but I might be wrong.

My picture is - flush on each lazy_mmu_disable(), pause on lazy_mmu_pause()
and honour only top-level arch_enter_lazy_mmu_mode_pte(mm, start, end, ptep) 
context on all nested levels.

In theory (and if I got it right, you leave the door open for this possibility)
every (mm, start, end, ptep) context could be stored for each nesting level
(as an opaque arch-specific data?).

But I do not really expect it ever, since arch_enter_lazy_mmu_mode_pte()
is only to be called in PTE walkers that never span more than one page
table and follow the pattern:

	ptep = pte_offset_map_lock(...);
	arch_enter_lazy_mmu_mode_pte(mm, start, end, ptep);

	for (...; ptep++) {
		/*
		 * set_pte(ptep, ...) or something
		 */
	}

	arch_leave_lazy_mmu_mode();                                             
	pte_unmap_unlock(...);                                         

As result, the lazy mmu mode is only "bound" to a single PTE table on s390,
while arch_enter_lazy_mmu_mode() is going to stay NOP.

So when you say you feel a fundamental problem - what that could be?

> David / dhildenb

Thanks!


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:25:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:25:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122065.1465958 (Exim 4.92)
	(envelope-from )
	id 1ux4iJ-0001TZ-Kb; Fri, 12 Sep 2025 14:25:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122065.1465958; Fri, 12 Sep 2025 14: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 1ux4iJ-0001TS-Hj; Fri, 12 Sep 2025 14:25:23 +0000
Received: by outflank-mailman (input) for mailman id 1122065;
 Fri, 12 Sep 2025 14:25: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 1ux4iI-0001TM-EN
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:25:22 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4d2a26a8-8fe4-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 16:25:16 +0200 (CEST)
Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com
 [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-586-fwe0dDgeMNKffj2XJKFyYQ-1; Fri, 12 Sep 2025 10:25:14 -0400
Received: by mail-wr1-f71.google.com with SMTP id
 ffacd0b85a97d-3e3f8616125so1906386f8f.1
 for ; Fri, 12 Sep 2025 07:25:14 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f20:da00:b70a:d502:3b51:1f2d?
 (p200300d82f20da00b70ad5023b511f2d.dip0.t-ipconnect.de.
 [2003:d8:2f20:da00:b70a:d502:3b51:1f2d])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607e9e6asm6786163f8f.62.2025.09.12.07.25.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 07:25: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: 4d2a26a8-8fe4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1757687115;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=gn3WhgefbhqadhZ+e2VS3g6y1n7EinfOM5ykIxfpPls=;
	b=ITTGI8IEYS693XakVLg4WSSwvqZfefn4zoC6E5WjV3iT0cFkdZWBeSeclogqG4jEhly3kB
	pdC5wm3yG0MelWA1BRdbKZXpd/ncPvRNwykYF8uUlWAQy9fp7cMYMosnn7iMOTvgOODv7s
	h7dTnNYn4D7i8o7ceO1t/ILVDXBlozg=
X-MC-Unique: fwe0dDgeMNKffj2XJKFyYQ-1
X-Mimecast-MFC-AGG-ID: fwe0dDgeMNKffj2XJKFyYQ_1757687113
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757687113; x=1758291913;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gn3WhgefbhqadhZ+e2VS3g6y1n7EinfOM5ykIxfpPls=;
        b=t6ZgQ04WgtI1hNk23I50zfnap3jE5Ifal+Ub3oQyy9gQEieOgHRfy9tZHalpW/Bp1h
         /bNVVkeVx/Lpw+sSE88+tGcdtUJ45bAmjYKrk9OpY4/ayuyuj/HP4chKdfMVulg3cU3Q
         0eFZKfSfHLK19HDGzpdAxVu/1FxQhn4E6SUZndG8ev3A94CMSiBZmI5ixRb091yn19/c
         Y9SlA6grfqKxxNX/QEQCaS2TBluoF/XskWUneUjE5CkM69ge4LR9ffHmsUB/E3ps4ixs
         CQcbW7wQ+Dr8nCyUjBd8Yp1mW1XLfiios7R4tUd1iCjz64wXmkRHJgH1ReklEY37TMl+
         5woA==
X-Forwarded-Encrypted: i=1; AJvYcCU3x2QkWK1XwD9Aj7BcF3Ros1LUpIJS5FMMs6m5IWQLOlpPmAQwYJASDAwNa/bQJDfDv8tX6xSU6xs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyEG59pVry8ss9kVL5PKFyhkJGarDMtL4E3pExNnlG/KCARZ7wx
	wbYAQckR8axVZttLICrsjtPVP4rJ93sjYWNsRO4WnKs930euwRIQhS/9p+Us7OkrCCP6dUqnLrA
	58ozlL5BxjTkTooxaFEcSL2eZ6r5og5fHVI5xPqvwFY/kavk+Q7qCvMRE1s3wn6FE0610
X-Gm-Gg: ASbGncvL15Os/rPH9G1SUaNzGb5QtjQcSlOiK1Vls9V0Z+BSgTfhYjtihQHPrU2uAEU
	f+G+tCo9dOciB7WLubsSg1B7cA2uNpD3wZfFREWUru7k6I21TUVTKUc/dBUNl78AMhQTOUJb70x
	Mc0ybhfS3J6sBAA973+vlfRBNt2157gcuYTV/1KUYb4VbXKDjzYLVVroc8Q7I8lsSmVaaXibMjh
	RRHk9PQF7DDSahggyXarGplD2vb80d9s2NFrCqj4QGIStrRDHvhys7zlhiVtXTz8NbJVoyzpT/3
	Qn08qV6WLA2lA6+dvRG1NG7q2CQhM9X026Dz3yKgeyXIP+PXKRE2DifiTRWC/MvxFMda3xct90/
	N+usS5o7clFj/Ekodqd8kwmrTn6wxUFrIArd6aL0mzA/M1hOdpdfs9/LJxWI+zpcv3tE=
X-Received: by 2002:a05:6000:186a:b0:3c6:c737:d39f with SMTP id ffacd0b85a97d-3e765792e71mr3311142f8f.3.1757687112714;
        Fri, 12 Sep 2025 07:25:12 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IG5Dw0WMhxC0tkHYzo2PeBegNsNsLTmAmmO9jpDPgYtz3v1hBhfjXrJHgGEloPWOm+UgdFZUw==
X-Received: by 2002:a05:6000:186a:b0:3c6:c737:d39f with SMTP id ffacd0b85a97d-3e765792e71mr3311069f8f.3.1757687111967;
        Fri, 12 Sep 2025 07:25:11 -0700 (PDT)
Message-ID: <852d6f8c-e167-4527-9dc9-98549124f6b1@redhat.com>
Date: Fri, 12 Sep 2025 16:25:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: Alexander Gordeev 
Cc: Kevin Brodsky , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
 <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
 <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
 <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com>
 
 
From: David Hildenbrand 
Autocrypt: addr=david@redhat.com; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
 ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG
 FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN
 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11
 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR
 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW
 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv
 Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ
 lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv
 cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr
 Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O
 otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A
 LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: fSqCieC8Vlfl63pVK7-RgEQPRO5-cGQgv1kHSTrpqQw_1757687113
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12.09.25 16:05, Alexander Gordeev wrote:
> On Fri, Sep 12, 2025 at 03:02:15PM +0200, David Hildenbrand wrote:
>> How would that work with nesting? I feel like there is a fundamental problem
>> with nesting with what you describe but I might be wrong.
> 
> My picture is - flush on each lazy_mmu_disable(), pause on lazy_mmu_pause()
> and honour only top-level arch_enter_lazy_mmu_mode_pte(mm, start, end, ptep)
> context on all nested levels.
> 
> In theory (and if I got it right, you leave the door open for this possibility)
> every (mm, start, end, ptep) context could be stored for each nesting level
> (as an opaque arch-specific data?).

Yes, I explained that we could do that, for example, by returning a 
"struct arch_lazy_mmu_state" from enable() and feeding it into disable().

I would just wish that we could avoid that ...

As an alternative, you could store it somewhere else as an array (percpu 
variable? task_struct) and support only a limited number of nesting 
levels. The current nesting level could always be retrieved from the 
task_struct, for example.

Maybe s390x really wouldn't need support for more than one nesting level 
right now.

> 
> But I do not really expect it ever, since arch_enter_lazy_mmu_mode_pte()
> is only to be called in PTE walkers that never span more than one page
> table and follow the pattern:

Well, the cover letter here states:

"Unfortunately, a corner case (DEBUG_PAGEALLOC) may still cause nesting 
to occur on arm64. Ryan proposed [2] to address that corner case at the 
generic level but this approach received pushback; [3] then attempted to 
solve the issue on arm64 only, but it was deemed too fragile."

So I guess we should support nesting cleanly, at least on the core-mm side.

I guess we could start with saying "well, s390x doesn't fully support 
nesting yet but doing so just requires changing the way we manage this 
per-nesting-level state internally".

s390 is trying to do something different than the other archs here, so 
that naturally concerns me :)

But if it's really just about forwarding that data and having s390 store 
it somewhere (task_struct, percpu variable, etc), fine with me.

-- 
Cheers

David / dhildenb



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122091.1466013 (Exim 4.92)
	(envelope-from )
	id 1ux50w-0005E0-Pw; Fri, 12 Sep 2025 14:44:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122091.1466013; Fri, 12 Sep 2025 14: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 1ux50w-0005CT-HU; Fri, 12 Sep 2025 14:44:38 +0000
Received: by outflank-mailman (input) for mailman id 1122091;
 Fri, 12 Sep 2025 14:44:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1ux50v-0004JT-3Z
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:37 +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 00eb5423-8fe7-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:44:36 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3e8123c07d7so47009f8f.0
 for ; Fri, 12 Sep 2025 07:44:36 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44: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: 00eb5423-8fe7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688276; x=1758293076; darn=lists.xenproject.org;
        h=content-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=Y8OCJ00B7SiN+TcNJnXk15Q6BMK+dvW43SxAcU8PxzY=;
        b=qOApSUJ2J2lP50EF0B0Qn0GB2bcMi0LNEcHrK8LJ1FGZdjtu0wRI3y23Zq4iNC85Kv
         GN62hvouCLSb/yHXIESafON9UhylSMaFvqf+8O5TIj/2k6ti5ns+BsFuEJC671X/4nKA
         JogoNkThGmBy0FnoyYDdlj71qiHODsDTatQ9o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688276; x=1758293076;
        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=Y8OCJ00B7SiN+TcNJnXk15Q6BMK+dvW43SxAcU8PxzY=;
        b=LnKkQNGn8R4tNXDdXp2MAoJeuLXsJerJBSGVLgu9nOOcmByAPEiksQbCGULCSB7bOZ
         ZtZ8HYZObFPWf86IjdivW6IedpU+imwtP98sU9ByQ6Yvro3dFOv+1aWsp3RgQJDKptT6
         w0g/haKmHH3juO6jDxKgDjmw71b9ccOFgZPS73bWJ2+LOsDWF++au5jGmu5X5o6n4VMH
         ZaWNDNODC+0Wo0gOIoAMIEU6dHtisREFD0b+CjSFJ6480eMWT9ellvSPJEJA/js3DQdf
         VuU7FiLOXYkqxRWYV6rQo7RDt1O+byOwtdxpeDzE0N1zwWs3ydDvA1WJUOu+clkfH53q
         M/fQ==
X-Gm-Message-State: AOJu0YyR6OzIm1O40opV7GLgEcSywZVmnEcaNSiysbJIzAIE2kRLaNGF
	urlW2V1Ci54oGO/uhqVE7CClGJiz6L7eIfBUM2gSn1XPOqzPzT0s4wVJwAYInh/MjVXo+/f8q99
	WjSXm
X-Gm-Gg: ASbGncuMLrq6bRna5eujs3jxe+Q0U0fhZkXD3nru0W9iagCHK8v+K206ARAN2yehUt5
	v4OnekE2Ir63UjcyvdVBgPwebxkLdzs6KdcIYuOwkCoTjPt67Zz59v3Eb6WFIT6M7GAiogmwSAV
	sH6a2DmW4ZlqzWl4PBQsyDkfSQpIdNMUniBWCY0/9CrwglVLt3oTrbul2z6oeDopINsnV8a3TVo
	jbMEzGyN/TCU/BmuQfrw3KK25Noc0csm++8FanjBEkahI80AZ1b2DZiLZoVUKVRM+6AvNknljz6
	lb5pz2feqhD2apKxEPzmFU6xVNk/1NLADOzcwYKrFY3GjIKe670U0wp8sLSWoL5dcxnOMc2ZKO/
	C1PWbTI+WUGAX3TGQVlyZYYvHNiuiu5lOQTFKswBXI+lrFImgC3MvSLRFq0avirYssktdXNDKak
	Dd
X-Google-Smtp-Source: AGHT+IFI+H0LGobGeE9zijNwuP0LN6Roi39UE0X8oThdZYHVRwFL4CZw2IWIM5DfdjrGcyGIMiEbCw==
X-Received: by 2002:a05:6000:26cb:b0:3e2:e851:7f93 with SMTP id ffacd0b85a97d-3e75e0fc32bmr6897230f8f.7.1757688275709;
        Fri, 12 Sep 2025 07:44:35 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Volodymyr Babchuk 
Subject: [PATCH v4 5/8] x86/emul: Make condition coverage warning non-fatal
Date: Fri, 12 Sep 2025 15:44:24 +0100
Message-Id: <20250912144427.1905141-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Randconfig with GCC-14 (Debian Trixie) found:

  In file included from arch/x86/x86_emulate/x86_emulate.c:11,
                   from arch/x86/x86_emulate.c:27:
  arch/x86/x86_emulate/x86_emulate.c: In function 'x86_emulate':
  arch/x86/x86_emulate/private.h:482:8: error: Too many conditions (found 826); giving up coverage [-Werror=coverage-too-many-conditions]
    482 | ({  if ( (p) ) {                                                          \
        |        ^
  arch/x86/x86_emulate/x86_emulate.c:1283:5: note: in expansion of macro 'generate_exception_if'
   1283 |     generate_exception_if((mode_vif() &&
        |     ^~~~~~~~~~~~~~~~~~~~~

which is a consequence of having a new enough compiler to allow
CONFIG_CONDITIONAL_COVERAGE in to the mix.

In the short term make warning non-fatal.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Julien Grall 
CC: Stefano Stabellini 
CC: Volodymyr Babchuk 

v4:
 * New

Full failure logs:
  https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11331286819
---
 xen/arch/x86/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d7aed7d92c15..a0bba5d9085e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -98,6 +98,9 @@ $(obj)/usercopy.o: CFLAGS-y += -iquote .
 ifneq ($(CONFIG_HVM),y)
 $(obj)/x86_emulate.o: CFLAGS-y += -Wno-unused-label
 endif
+ifneq ($(CONFIG_CONDITION_COVERAGE),y)
+$(obj)/x86_emulate.o: CFLAGS-y += $(call cc-option,$(CC),-Wno-error=coverage-too-many-conditions)
+endif
 
 efi-y := $(shell if [ ! -r $(objtree)/include/xen/compile.h -o \
                       -O $(objtree)/include/xen/compile.h ]; then \
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122089.1465987 (Exim 4.92)
	(envelope-from )
	id 1ux50v-0004Y4-61; Fri, 12 Sep 2025 14:44:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122089.1465987; Fri, 12 Sep 2025 14:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004XK-TX; Fri, 12 Sep 2025 14:44:36 +0000
Received: by outflank-mailman (input) for mailman id 1122089;
 Fri, 12 Sep 2025 14:44: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 1ux50u-0004JT-3J
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:36 +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 005952d6-8fe7-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:44:35 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-45dfb6cadf3so18049445e9.2
 for ; Fri, 12 Sep 2025 07:44:35 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44: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: 005952d6-8fe7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688275; x=1758293075; darn=lists.xenproject.org;
        h=content-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=fz6A5Gve9VSC84pT6xrA0HURFM9BjgbSCbypdn93KKc=;
        b=cfp6jlUjJWXSaNVCOdvJcFTmcXZwyCnAifNeM0Ul7zdyxgYpgLoxyDdg3mzmnjOTQe
         ASW9ZMIq2UDhGFPh+8Pq8Q4aFxz3q+KCNJYq6NnnPjVKHQrjU7oeFRt7EczS//JjkwEQ
         Qtbe7UkaIL0d5ALbQIQFdi6RPOJuRh8cgWf7o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688275; x=1758293075;
        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=fz6A5Gve9VSC84pT6xrA0HURFM9BjgbSCbypdn93KKc=;
        b=I/sxy3wJPM15MFBQPyfRFUZgE1wsNU3dNgffkPqgr6W4q7dfXUztzik9m9uPSE/G7B
         5nPSiuFtGZCCLx0KRg4/nraZR2bzpiGSh9wpAkFJtGwRqQfVaHS33R95zzIznDPU//hs
         cECKsimmfGJZV33oVC0lzGAIdr3oM1GPg/0ZJ/MRNDcxkKQmRfpoCvmWi9Fc/FDF0WWw
         2eLU6hG7ODaSIttUoj1vxcdobcfOjGMN1n8uaPMEGlUa4XWVuY7F5oCpZHV9nnhvSCh7
         TU0VleqIC3pSyT6kE0oH+2GBgjy3rjj9wURPKVHDqT8HDKe02X9cSltSu7L0UX1Q07x2
         ke8g==
X-Gm-Message-State: AOJu0YzuZEqJEoDH6mNNWhc/Dno/MkFE55e/eq3bx2hoO/U/3JtdIMH+
	1rh4EMsBc6wePGqV358oBekHCte9QDIZpbJbeULq3QkbJKJ//AtgJF6SwO25yonuxGwIH14z4Fg
	KPOir
X-Gm-Gg: ASbGncvZMo/H/Jy10Nolj8BY5de90FuZfLTnGcMVEgOzvM2oMYesN2Ys6KMZ+cHsI/3
	zVy+jRfJ+DrCKM36/YrgVNl+43w8CNaY6OgbM7dIZPZ9qwYj+p3+QQ4UJFgpmNr+8d3IiFILGB4
	gM0S6t42b6zMGoA32rRfyISjYnfk40bfY+JLEFx/tU82kVzI9i2c8LB6j/fY3zkaqygfST1Fq05
	IsdtFOdvpKS2f94CJSBlodCCQ2Lnb9/LcQNMk08sy+Q0EpF6owKqx3MiYlgkkUPGLqcOCOsir81
	B/H0I45ScJcGhfs1K2bxheBcppH03LdAkTxHnJC5CFBeNUcNZEV8VPxlvvUgulZZ9R5t8k/mIw2
	XzIsGAqgXsZqd/vbrkvGhPn6xDIlYDi5WvGrSrRZyH88NUTmTeXQjDajZLPLUaF481xHWZDmhcV
	j6
X-Google-Smtp-Source: AGHT+IFnlcxvKSZ/oFXXCOvd+e4AN+6ez3oru+DjhUoktXsiu1T1iIjZmKpAXTDS+cm5jeMmUwDl7g==
X-Received: by 2002:a05:600c:5254:b0:45d:f55d:3478 with SMTP id 5b1f17b1804b1-45f211e610fmr37983115e9.17.1757688274714;
        Fri, 12 Sep 2025 07:44:34 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v4 4/8] CI: Make qemu-smoke-x86-64-gcc-efi compatible with Debian Trixie
Date: Fri, 12 Sep 2025 15:44:23 +0100
Message-Id: <20250912144427.1905141-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The OVMF package in Debian Trixie has _4M suffixes on the files.  Have
scripts/include/xtf-x86-64-efi check for this before falling back to no
suffix.

Signed-off-by: Andrew Cooper 
Reviewed-by: Denis Mukhin 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 
CC: Denis Mukhin 

v4:
 * New

https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11334759836
---
 automation/scripts/include/xtf-x86-64-efi | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/automation/scripts/include/xtf-x86-64-efi b/automation/scripts/include/xtf-x86-64-efi
index e0d821b3f6fd..8340c745dbf4 100644
--- a/automation/scripts/include/xtf-x86-64-efi
+++ b/automation/scripts/include/xtf-x86-64-efi
@@ -20,6 +20,7 @@ function xtf_arch_setup()
 {
     local esp_dir="${WORKDIR}/boot-esp"
     local efi_dir="${esp_dir}/EFI/BOOT"
+    local suff=
 
     # Generate EFI boot environment
     mkdir -p ${efi_dir}
@@ -35,8 +36,13 @@ options=${XEN_CMDLINE}
 kernel=kernel
 EOF
 
+    # Vs older versions, Debian Trixie names the OVMF files with a _4M suffix.
+    if [[ -e ${FW_PREFIX}/OVMF_VARS_4M.fd ]]; then
+        suff=_4M
+    fi
+
     # NB: OVMF_CODE.fd is read-only, no need to copy
-    cp ${FW_PREFIX}OVMF_VARS.fd ${WORKDIR}
+    cp ${FW_PREFIX}OVMF_VARS${suff}.fd ${WORKDIR}
 
     export TEST_CMD="${QEMU_PREFIX}qemu-system-x86_64 \
         -no-reboot \
@@ -45,8 +51,8 @@ EOF
         -serial stdio \
         -m 512 \
         -M q35,kernel-irqchip=split \
-        -drive if=pflash,format=raw,readonly=on,file=${FW_PREFIX}OVMF_CODE.fd \
-        -drive if=pflash,format=raw,file=${WORKDIR}/OVMF_VARS.fd \
+        -drive if=pflash,format=raw,readonly=on,file=${FW_PREFIX}OVMF_CODE${suff}.fd \
+        -drive if=pflash,format=raw,file=${WORKDIR}/OVMF_VARS${suff}.fd \
         -drive file=fat:rw:${esp_dir},media=disk,index=0,format=raw \
     "
 }
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122086.1465969 (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004Jv-AO; Fri, 12 Sep 2025 14:44:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122086.1465969; Fri, 12 Sep 2025 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004Jo-5r; Fri, 12 Sep 2025 14:44:36 +0000
Received: by outflank-mailman (input) for mailman id 1122086;
 Fri, 12 Sep 2025 14:44: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 1ux50s-0004JT-DP
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:34 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff35efda-8fe6-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:44:33 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-45dde353b47so13054995e9.3
 for ; Fri, 12 Sep 2025 07:44:33 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44: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: ff35efda-8fe6-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688273; x=1758293073; darn=lists.xenproject.org;
        h=content-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=APcVKYSQhSwM06it+vKiPyIO4PXTJ2pXYHSmoq6z1Z4=;
        b=WcOzBGYpCBbyh9zvvP2fPoyM2kU8/RkCvv1zPmsH+pw//NYsKOyEHO/ncL7dyWtozm
         ldW4Kv3SqnZvhAwWCfNmyaD6gxVnqxruiJHJETSaWREMLM0DS7VjES4HidD5E71I7Orm
         cc15+dpqhLI2DqbcNbd+cTq1PkSVqFhv65Ibg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688273; x=1758293073;
        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=APcVKYSQhSwM06it+vKiPyIO4PXTJ2pXYHSmoq6z1Z4=;
        b=Nqf1YaP2LWM5+I0DNVZC+TVM+QKimFK7nqOh9/KNw4nuqpTTNUJaXw7Hs/GJsdY9LA
         NX7V+O8dA77adiMR8S5VAXEUu99/TWoEcOrHRQFHRx78wdCC5WYoCTRngADH5+/fG5A1
         /UMmqc03IiYZ7uPWbdTqONMA31YYKklRGfwm+vzI3anQZFTeex9uCvQqmOKPCkqAvwfk
         vlAQpDCvmVgPdH4fGycp7NT6OqAAreImgt3KIl4o0BVKDxp42HJe6cxylhVjqtSnIte2
         kstbdUofXl6BhIw3vqF+U+HRgPOBrkgw2IKN9H5fEFqJWfF8D2IWBgLe24ebvVOxkDo9
         o5Rg==
X-Gm-Message-State: AOJu0Yw3DVtiWcjWNP0JhN1iGn1n9kCBWb7+n/p0LXVXgioVZHrRK/2i
	7qPWeEaIBCnEGlA/9gUGcgZz1pL1F9RnwL72Ht8We52+b9FB8HPQD0n2iztsExQdMzd0QaUtoE4
	IdizQ
X-Gm-Gg: ASbGncuVBYu54+85rES834fJAPQ/+7D7KFnN35vWMS31jJ3YdEVafFqu+hnoiVe/rys
	hk1euhIZcIwXaonubgzfj+ydsswk//V8USkNoPnLagIA2KINIcMZwV/0PM1kEEL72sQx6bECeI2
	FfyJCRjG9dhhmXicibM304wWnT4XoNvWbWiPMsnM59GTP87ikgn+crGU9Ba1a0tG1Xt98asewl/
	SUBGst1ctClu9kDciqYJwqNqWg65Wpk7UpvkkJ1J+kaDDTJ3gFKfx5utaqODrlhCY8GcM43aHPU
	6dSciE7JXhGC2EoIgjCoxyLKCI/x3rQgKxFrtVi2cp3qy2qBXqqHMTrkIJgZlF6ZaWD+sn3IjYP
	wDr8syCC1ns7MFDZfpWf/BgTnxcuEPlJIs4IvI7DnAzGQi+jqZU/SNg4E4+c29LHoVgXVi4Fv9t
	94XBkn12UAgJA=
X-Google-Smtp-Source: AGHT+IGZBt1h6TFy7LIIVJ7FT8oS8K4tdPDztlvTu0Fs4WVRlCLgiLY2+eZMa4Hrqd0u+tB27AadfQ==
X-Received: by 2002:a05:600c:d5:b0:45d:d609:117f with SMTP id 5b1f17b1804b1-45f211cab8bmr30593865e9.8.1757688272858;
        Fri, 12 Sep 2025 07:44:32 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v4 2/8] CI: Update ppc64 to use Debian Trixie
Date: Fri, 12 Sep 2025 15:44:21 +0100
Message-Id: <20250912144427.1905141-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Everything works fine with Debian 13.  Provide two new build jobs (for a total
of 6), and update the test jobs.

Signed-off-by: Andrew Cooper 
Reviewed-by: Denis Mukhin 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v3:
 * Update .qemu-ppc64le template too
v2:
 * Update containerize
---
 ...pc64le.dockerfile => 13-ppc64le.dockerfile} |  2 +-
 automation/gitlab-ci/build.yaml                | 18 ++++++++++++++++--
 automation/gitlab-ci/test.yaml                 |  4 ++--
 automation/scripts/containerize                |  1 +
 4 files changed, 20 insertions(+), 5 deletions(-)
 copy automation/build/debian/{12-ppc64le.dockerfile => 13-ppc64le.dockerfile} (93%)

diff --git a/automation/build/debian/12-ppc64le.dockerfile b/automation/build/debian/13-ppc64le.dockerfile
similarity index 93%
copy from automation/build/debian/12-ppc64le.dockerfile
copy to automation/build/debian/13-ppc64le.dockerfile
index da518aab4e10..5b22a4545842 100644
--- a/automation/build/debian/12-ppc64le.dockerfile
+++ b/automation/build/debian/13-ppc64le.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/amd64 debian:bookworm-slim
+FROM --platform=linux/amd64 debian:trixie-slim
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index c0728e58c48b..f8e45f3467c8 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -319,10 +319,10 @@ debian-12-x86_64-clang-debug:
   variables:
     CONTAINER: debian:12-x86_64
 
-debian-12-ppc64le-gcc-debug:
+debian-13-ppc64le-gcc-debug:
   extends: .gcc-ppc64le-cross-build-debug
   variables:
-    CONTAINER: debian:12-ppc64le
+    CONTAINER: debian:13-ppc64le
     KBUILD_DEFCONFIG: ppc64_defconfig
     HYPERVISOR_ONLY: y
     EXTRA_XEN_CONFIG: |
@@ -705,6 +705,20 @@ debian-12-ppc64le-gcc:
     KBUILD_DEFCONFIG: ppc64_defconfig
     HYPERVISOR_ONLY: y
 
+debian-12-ppc64le-gcc-debug:
+  extends: .gcc-ppc64le-cross-build-debug
+  variables:
+    CONTAINER: debian:12-ppc64le
+    KBUILD_DEFCONFIG: ppc64_defconfig
+    HYPERVISOR_ONLY: y
+
+debian-13-ppc64le-gcc:
+  extends: .gcc-ppc64le-cross-build
+  variables:
+    CONTAINER: debian:13-ppc64le
+    KBUILD_DEFCONFIG: ppc64_defconfig
+    HYPERVISOR_ONLY: y
+
 # RISC-V 64 cross-build
 debian-12-riscv64-gcc:
   extends: .gcc-riscv64-cross-build
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 1de68a0fe450..e8946e15dc3a 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -90,7 +90,7 @@
 .qemu-ppc64le:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-ppc64le
+    CONTAINER: debian:13-ppc64le
     LOGFILE: qemu-smoke-ppc64le.log
   artifacts:
     paths:
@@ -712,4 +712,4 @@ qemu-smoke-ppc64le-powernv9-gcc:
   script:
     - ./automation/scripts/qemu-smoke-ppc64le.sh powernv9 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-ppc64le-gcc-debug
+    - debian-13-ppc64le-gcc-debug
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 340b6caaab44..65c8804ce5f3 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -31,6 +31,7 @@ case "_${CONTAINER}" in
     _fedora) CONTAINER="${BASE}/fedora:41-x86_64";;
     _bullseye-ppc64le) CONTAINER="${BASE}/debian:11-ppc64le" ;;
     _bookworm-ppc64le) CONTAINER="${BASE}/debian:12-ppc64le" ;;
+    _trixie-ppc64le) CONTAINER="${BASE}/debian:13-ppc64le" ;;
     _bookworm-riscv64) CONTAINER="${BASE}/debian:12-riscv64" ;;
     _trixie-riscv64) CONTAINER="${BASE}/debian:13-riscv64" ;;
     _bookworm-x86_64-gcc-ibt) CONTAINER="${BASE}/debian:12-x86_64-gcc-ibt" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122088.1465980 (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004QH-TT; Fri, 12 Sep 2025 14:44:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122088.1465980; Fri, 12 Sep 2025 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004Nu-JG; Fri, 12 Sep 2025 14:44:36 +0000
Received: by outflank-mailman (input) for mailman id 1122088;
 Fri, 12 Sep 2025 14:44: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 1ux50t-0004JT-32
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:35 +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 ffc6a8dc-8fe6-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:44:34 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-45de287cc11so17162865e9.1
 for ; Fri, 12 Sep 2025 07:44:34 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44: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: ffc6a8dc-8fe6-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688274; x=1758293074; darn=lists.xenproject.org;
        h=content-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=1+5OeQGcDbnAwz67GRXnivaacN6ERwJk9ywsk5rSdw4=;
        b=dCqui4viqM1c84yjGZkveW210vB3q+QTBKUKaXdqmjT17zX8uQ5o4/Rol5b9uN+DrJ
         orFU7j1aTofiP6bNSB1tJFflB+OP8Q9AsCj3GSv0Eh3J7ljedcccPhjNAaKUddrXTL7h
         PcCHYe/UiotiHZ9EHRxvqp4p9A4THKdUgjAoM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688274; x=1758293074;
        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=1+5OeQGcDbnAwz67GRXnivaacN6ERwJk9ywsk5rSdw4=;
        b=htfviTbXifgmijw6ALsSipobSeQB3XGYprI+0BbxgDrn9p9SE2HHwL+1fz2LI1gm1I
         MHLF90VhEIvXQNQXeaJtEv+ikuhLhai/NgLon7pwu3tjjuLmVvbzGtSF7LP5EE2R0N44
         6E6Z7WBjIOyq8peGCteI1E01D3wuSx9DTT/+RnYnSY53Wv3TF1SU0jIQqB8+rEsJ7CJG
         6whUJQSvNmwZQOJGHoqDtJ73+MIhqQzCqaqfaJBW73bbg5UJzpVYNNeqVQK2x4giaEW3
         QgxJBnOoDdhP17kpri25Fyrv9O3rjCh48UysdqZLTGgDinqy46wYW3pXXSDjw1qn9CNo
         Z/VQ==
X-Gm-Message-State: AOJu0YwCzh5KSVPKoZxRzA0tWIbH7WckRe7KuyjP96F6/bxxuCi3tHFC
	wcT+svkWNo7mO8Cf9hAWmnTZgfbeQidUbOlbY8nWOMU9fvoSMjZ7DfJIAw5sT1j+51MxegSTIAf
	QojBj
X-Gm-Gg: ASbGncvzudsSf2dEfYxMRTWYBxoaJCH4c87mNC7KtpBgNKl79BEdhWDP7AoUwpH06ZQ
	aPZ5aj+gWR83avCM98FqX/K64BEyHM0yCccVLZB+kBEecSNF5u6M/ricDrsyi4jE8Ft642oxl28
	g79laSBFZtgGwjQjsOVDzOO3g6ll2KTcz/iqWBut10R2sm4VU/+Ky2m8211E4/ahNvbjHYnwbWl
	EiT2CKbEVo591fYBgXnXQK8AMAaEh3WFA/TXIoGIGJoawtIA/lGug1MXKbCn4PkdebNj2PR8kPO
	/kFk0pnmCRo7d1+b4lKgcBF9Qe+6wI8pjxkY/GAreKT3yY7k0Uh4SUHgAVC37ghAF09rHm95vpH
	Hpjj2PriQ9jFS1ay9zvSI0gzWstMyRO8z2Yqql08F+vgm3qK4UJI1p2LXJZcZJGZ6DHZiF34ftK
	Pt
X-Google-Smtp-Source: AGHT+IEDBDTcLKQZMymHxnkL0ZmqZP2tyEPSSEWgGE5dHxDEL754J1+bNZLH27HK2yeITyRAGaGXWw==
X-Received: by 2002:a05:600c:40c4:b0:45d:e775:d8b8 with SMTP id 5b1f17b1804b1-45dfd5aaff0mr55189765e9.1.1757688273755;
        Fri, 12 Sep 2025 07:44:33 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v4 3/8] CI: Merge categories in debian/12-x86_64.dockerfile
Date: Fri, 12 Sep 2025 15:44:22 +0100
Message-Id: <20250912144427.1905141-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpio needs to be in Tools (general) now that it's used by the general build
script.  Merge the rest of the test phase jobs into one group, to avoid being
overly fine-grain.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Denis Mukhin 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

Prep for making a Debian Trixie derivative.

v3:
 * New
---
 automation/build/debian/12-x86_64.dockerfile | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/automation/build/debian/12-x86_64.dockerfile b/automation/build/debian/12-x86_64.dockerfile
index 3cf99c730b61..4e533ee879fd 100644
--- a/automation/build/debian/12-x86_64.dockerfile
+++ b/automation/build/debian/12-x86_64.dockerfile
@@ -23,6 +23,7 @@ RUN <
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122090.1466008 (Exim 4.92)
	(envelope-from )
	id 1ux50w-00058v-GB; Fri, 12 Sep 2025 14:44:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122090.1466008; Fri, 12 Sep 2025 14: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 1ux50w-00057T-68; Fri, 12 Sep 2025 14:44:38 +0000
Received: by outflank-mailman (input) for mailman id 1122090;
 Fri, 12 Sep 2025 14: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 1ux50u-0004JZ-Hg
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:36 +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 fe17845e-8fe6-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 16:44:31 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-45dcff2f313so14441275e9.0
 for ; Fri, 12 Sep 2025 07:44:31 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44: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: fe17845e-8fe6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688271; x=1758293071; 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=4RGHXqBNJI6tQy2M8/bIoPq23nxzoU9POG3ZkPJ6xPE=;
        b=FfspcdjfLBaKcWWVsI1Q3ClaNBwxqBK/tzRdy8ECYHKIwS5pgvryd3uoxPr6j5nIn7
         EjlB9Y5+USoWSbcJKf18zLV1zOx69D8k+lHLixeml5Q4jurNalQillP3CmESLJXQA5TQ
         JCC5dp6NgVZMDHu/YH0ttDvZ2aXhDDGyQi+1k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688271; x=1758293071;
        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=4RGHXqBNJI6tQy2M8/bIoPq23nxzoU9POG3ZkPJ6xPE=;
        b=wu362P/AbJ0x2VQDyNe+ebHKAd9cBav4wyBNCy8C0yAi+dUzr0AfXpdTnufK9IsSFd
         iDScbMQJrIQkWroHvsE5C1BrgjoWXWPS5/p9kjPUw7yPpMRSekqXmzlhvEOLtUhpcW8F
         cDsONQZxOXZhOxp/zfg0+/iBuc6MbyUjy3yupbr6aSQTo/MUsb8p2bUF/RrLOv2crU9R
         SR4ECgUnxvHOksrJHYxsFIwOGDRpzeg4mYMx3/IG1N4ut81kETt6DoSVAcIGaPtKKE/H
         bAxga6vgJaILDtBxGmbgOiBQc0aisCrwKB16xGit1wRiMBqXxkvfEG0KU5oIS49yCyuF
         M4bQ==
X-Gm-Message-State: AOJu0YxvLjxteXzOnwtDm3HwT65aO9lRkIHrSEykd8tSsoI57JApnJiM
	68YklgUw4kgfPjERsmpkmY98f5XyDSnrbCq5+COQU0rgf3fRAkDY2+lkcfWleMcs/NPYCIeb6ai
	tSl7D
X-Gm-Gg: ASbGncu1mTPOf45HT1syW8k83sphqY0U7FlDuWLwsVwyDjSA0ojbwSLe2M9KY8f1aXV
	1vREbK7slL69P0Ud2GoavdvuuX6CYAIJNVBsK8Sn3f7bC0ND+baoVfiQS2c79O29fbvqyWqyDc5
	xGCInreip28EFUMIMLNGlQDznKxm38OALyrLqwGHw5iTffDBz4Ox/vyq26V42EvqQVCHXvzWBWI
	/RIxDRW+0u3gmuwr7tWJDWbGKFGw1Xv+OIbRooP0OYhOzA3i/7y+CEGjWJi74rmdy+sn5dcFpmR
	tFhKCb8DVrRNPt3PPD/BHlM1a1O4Gr2OqSIZGLvLdL6haUDgE5HVvyAX6o+N0pTfYDvA6VNyYuB
	7qpZNKH7WRzO9QR1PR/X6hoZL26I5JgQxo6qbGCiiCZnH0SFcGWy520GXgq+RfmPuMAIv4TBaCL
	DTCqow3m9RlOM=
X-Google-Smtp-Source: AGHT+IFJ7tXD7Isvqk1AB812PnDe847/r4b57QBBoUDIiIyAvhZ5Nt7pq5LCYCt72xrfxmZwaeJUVw==
X-Received: by 2002:a05:600c:6288:b0:45d:e326:96fb with SMTP id 5b1f17b1804b1-45f211ff89emr39879115e9.30.1757688270944;
        Fri, 12 Sep 2025 07:44:30 -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 ,
	Oleksii Kurochko ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v4 0/8] CI: Add Debian Trixie
Date: Fri, 12 Sep 2025 15:44:19 +0100
Message-Id: <20250912144427.1905141-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

Refresh the Trixie series.  A few more bugfixes found by randconfig and log
inspection.

These containers are already built and deployed for people to test with.

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

Andrew Cooper (8):
  CI: Use the Debian Trixie container for RISC-V test jobs
  CI: Update ppc64 to use Debian Trixie
  CI: Merge categories in debian/12-x86_64.dockerfile
  CI: Make qemu-smoke-x86-64-gcc-efi compatible with Debian Trixie
  x86/emul: Make condition coverage warning non-fatal
  CI: Use pipefail in scripts/build
  CI: Update x86 to use Debian Trixie
  CHANGELOG: Notes about distro changes in CI

 CHANGELOG.md                                  |  3 +
 automation/build/archlinux/current.dockerfile |  1 +
 automation/build/debian/12-x86_32.dockerfile  |  1 +
 automation/build/debian/12-x86_64.dockerfile  | 12 ++--
 ...c64le.dockerfile => 13-ppc64le.dockerfile} |  2 +-
 ...x86_32.dockerfile => 13-x86_32.dockerfile} |  3 +-
 ...x86_64.dockerfile => 13-x86_64.dockerfile} | 14 ++--
 automation/build/fedora/41-x86_64.dockerfile  |  1 +
 .../opensuse/leap-15.6-x86_64.dockerfile      |  1 +
 .../opensuse/tumbleweed-x86_64.dockerfile     |  1 +
 .../build/ubuntu/16.04-x86_64.dockerfile      |  1 +
 .../build/ubuntu/18.04-x86_64.dockerfile      |  1 +
 .../build/ubuntu/20.04-x86_64.dockerfile      |  1 +
 .../build/ubuntu/22.04-x86_64.dockerfile      |  1 +
 .../build/ubuntu/24.04-x86_64.dockerfile      |  1 +
 automation/gitlab-ci/build.yaml               | 72 +++++++++++++++----
 automation/gitlab-ci/test.yaml                | 18 ++---
 automation/scripts/build                      |  2 +
 automation/scripts/containerize               |  4 +-
 automation/scripts/include/xtf-x86-64-efi     | 12 +++-
 xen/arch/x86/Makefile                         |  3 +
 21 files changed, 109 insertions(+), 46 deletions(-)
 copy automation/build/debian/{12-ppc64le.dockerfile => 13-ppc64le.dockerfile} (93%)
 copy automation/build/debian/{12-x86_32.dockerfile => 13-x86_32.dockerfile} (93%)
 copy automation/build/debian/{12-x86_64.dockerfile => 13-x86_64.dockerfile} (89%)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122092.1466020 (Exim 4.92)
	(envelope-from )
	id 1ux50x-0005Qr-Dx; Fri, 12 Sep 2025 14:44:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122092.1466020; Fri, 12 Sep 2025 14:44: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 1ux50x-0005PA-7G; Fri, 12 Sep 2025 14:44:39 +0000
Received: by outflank-mailman (input) for mailman id 1122092;
 Fri, 12 Sep 2025 14:44: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 1ux50w-0004JT-3p
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:38 +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 018a5300-8fe7-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:44:37 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3e7643b0ab4so1116023f8f.2
 for ; Fri, 12 Sep 2025 07:44:37 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07: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: 018a5300-8fe7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688277; x=1758293077; darn=lists.xenproject.org;
        h=content-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=WoTkLLzczgfJCAgT/pEdPHpSfLp9QlUgMwmAH0OgjKI=;
        b=KGPHkxMN0yexB2GGHtqTvvyTLWv5/C+76aFJ2s/78mrdthWgObhsmJ4JFuTiDEAqLW
         K+R/XjdRLdX81y+sleVf5sgkILIJ8PnDcQTV55BvkiJFzBmqyfioKFd9Z2koUBSx2v1W
         7r9cVzBFcAlIPioJo7Ks7fi56QEMoXhGYS/h8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688277; x=1758293077;
        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=WoTkLLzczgfJCAgT/pEdPHpSfLp9QlUgMwmAH0OgjKI=;
        b=gPtbM2CiozQinqRMg/w1VlpXxQ+Z1YckuHO6rUeYTGPwQqYGUshRIY4ddrvhnQzHcs
         k7f805ZhUDrxWdT5B+TLebXv/tPO0nWQCNudVDyJn5dxNkXTiPcSgPM09bGah2XgZz59
         Cfpey/6KYHzJPQIqtY+pPTF22PlHc15/VAphVcbR3ezIYedyBisun4RqaT9zVf4wOj9D
         Wguqkm8o79pdcn5hFobVc202kr880vABvEQUmTu6F42DcEC0QckLugfvB/lA3U2MJ/Pj
         c3l9BSQsTC2ffiWFUzuqP9GgSjY1t4hiS9WmHOl4Z/lsd+1ZkSGGWXLRfkKQFeGFczuV
         KQIA==
X-Gm-Message-State: AOJu0YyJ11T3eAyYTmF8PgTPJiIk85+jkVSfC64U/IdkmutiCmoFblSX
	isIIB6jZ4SRVL+DjH4W9vwy/lRSxgFwT4NfMTHPcIXu/nqwsDSi238D2KsNUnyGsxWm74qtdV+X
	HQ351
X-Gm-Gg: ASbGncsjJNUE9ErN0legYeyeUrGEh50JZwEBiBZ/6+pdV19dnAJLGD931xvawN+82mh
	/QoNE+hMpt6p0e6XYnbTI38AThScXRcJ++AD6nyaciYy9r2RC6AcpoFF8fCuFKun4AunoIVpsDi
	ZFJKYWPicdYmCUavdHnncqCNMtBpbtjxQ1hy8LBzjs/Xxc5pO8ppjcSJ+244iy8Y9cibe/ai2e1
	nj98kt6Jft2joHJMCZ9AM+is8olLkDLgroieboKwVBa5M8EvZlUeXgia4TvrvXUV8kP4FsqyFBu
	DxKO4H8HsPt7q7TbP/510bKxqUwAA8tP2jW4ewKVbLnQlnThvGlZH6TGhEs7jHT2DZgNXiqoOd/
	tYU86MJXrKivOVMxAqGnU4E6KLJE+SNWUM1WgNdQ4xP4h9Q5uWUuskercbBSle+yP/Dp+tA44jT
	HYMHchBPsJoquPZMn5fDfc/A==
X-Google-Smtp-Source: AGHT+IHujJvcSHrLmVnyhhPcSJgTM1tAhBqsElDCkNGpTY6jV0fsEGre6zSrxLSpmMlrywVyLYecqw==
X-Received: by 2002:a05:6000:2885:b0:3e3:c5a8:a1be with SMTP id ffacd0b85a97d-3e76552eb61mr3131530f8f.0.1757688276676;
        Fri, 12 Sep 2025 07:44:36 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: [PATCH v4 6/8] CI: Use pipefail in scripts/build
Date: Fri, 12 Sep 2025 15:44:25 +0100
Message-Id: <20250912144427.1905141-7-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Marek noticed that some builds were failing with:

  + cd dist/install
  + find
  + cpio -R 0:0 -o -H newc
  ./automation/scripts/build: line 111: cpio: command not found
  + gzip

but succeeding overall, and producing a zero length xen-tools.cpio.gz as an
artefact.

In fact, it's all of:

  archlinux:current
  debian:12-x86_32
  fedora:41
  opensuse:tumbleweed
  ubuntu (all versions)

Add cpio into all of these containers, including opensuse leap for good
measure, and use pipefail in the build script.

Fixes: 4611ae6fb8f9 ("CI: save toolstack artifact as cpio.gz")
Reported-by: Marek Marczykowski-Górecki 
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: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v4:
 * New

I have already deployed the updated containers.

All failures:
  https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2036157692
---
 automation/build/archlinux/current.dockerfile          | 1 +
 automation/build/debian/12-x86_32.dockerfile           | 1 +
 automation/build/fedora/41-x86_64.dockerfile           | 1 +
 automation/build/opensuse/leap-15.6-x86_64.dockerfile  | 1 +
 automation/build/opensuse/tumbleweed-x86_64.dockerfile | 1 +
 automation/build/ubuntu/16.04-x86_64.dockerfile        | 1 +
 automation/build/ubuntu/18.04-x86_64.dockerfile        | 1 +
 automation/build/ubuntu/20.04-x86_64.dockerfile        | 1 +
 automation/build/ubuntu/22.04-x86_64.dockerfile        | 1 +
 automation/build/ubuntu/24.04-x86_64.dockerfile        | 1 +
 automation/scripts/build                               | 2 ++
 11 files changed, 12 insertions(+)

diff --git a/automation/build/archlinux/current.dockerfile b/automation/build/archlinux/current.dockerfile
index 657ddd77a85c..4e53c835fa50 100644
--- a/automation/build/archlinux/current.dockerfile
+++ b/automation/build/archlinux/current.dockerfile
@@ -8,6 +8,7 @@ RUN pacman-key --init
 RUN pacman -S --refresh --sysupgrade --noconfirm --noprogressbar --needed \
         bridge-utils \
         bzip2 \
+        cpio \
         discount \
         dtc \
         e2fsprogs \
diff --git a/automation/build/debian/12-x86_32.dockerfile b/automation/build/debian/12-x86_32.dockerfile
index ef7a2571556b..447152d7e5e4 100644
--- a/automation/build/debian/12-x86_32.dockerfile
+++ b/automation/build/debian/12-x86_32.dockerfile
@@ -23,6 +23,7 @@ RUN <
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122087.1465975 (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004N8-Iq; Fri, 12 Sep 2025 14:44:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122087.1465975; Fri, 12 Sep 2025 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux50u-0004MP-Ch; Fri, 12 Sep 2025 14:44:36 +0000
Received: by outflank-mailman (input) for mailman id 1122087;
 Fri, 12 Sep 2025 14:44:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1ux50s-0004JZ-VI
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:34 +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 feb920db-8fe6-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 16:44:32 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3e46fac8421so1630889f8f.2
 for ; Fri, 12 Sep 2025 07:44:32 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44: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: feb920db-8fe6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688272; x=1758293072; darn=lists.xenproject.org;
        h=content-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=vHN27rLxCbFWo2ic6OFVcKs35MAX0SyPbGCQ+GtE01g=;
        b=C5jmUg/VxY0mSa94wMGoDigi2Z6slgMaJcCCf0zmLZ4EIwV5OwtMZ+15dQFiOxGWI4
         o7PtKQXuK4DTpUebALLv03mZqb7FZdeSHlVtylyWDR/DhsAAlTGjRd3u8mbw9m2SvbvY
         lkoMVumAzhPtHCd1oJ1mFpcDzhvbHe9EaGXlk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688272; x=1758293072;
        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=vHN27rLxCbFWo2ic6OFVcKs35MAX0SyPbGCQ+GtE01g=;
        b=Na/Mx+U5/p145EW6yaAx4fejccEG38ovcvhDwg8fUJivXhGOfROzXoqyfdEctqJu1w
         iGR8C3GmQ6KT9bXwDY3bYUEAHIY/rbb367TpwW+XLcVKluH+0XPG3st5X2VK7MyeRa82
         Ps63mAeHb9xY4sjVRC7dm4ECXGvJ961/y7SAUanza1W/Choqp2iWjyu+RjyrYpg26YDe
         qMVBJd6HaV9/BqXb5N1RHAEn3qk2bh/I09tzsYQFaDJ72ufupbwCGAOpAQ+YYTJvXnPB
         3DjbkWJ3HNF+uxGYfoKW7ieYRc6ESfdh7+0HcA4lHKHzEDmLN1L7aRA/YZ514Ibp9RMP
         2Yjg==
X-Gm-Message-State: AOJu0YwwidUTACfwg7CPmpbMYMmhb9zR6wv7pJZsoIHzVrMdg3X4hXpC
	D4l/vBmgHN5W2Ywc2cRDzc3p9vxr3kXpvXjXrHWKwd4aUD4afQuE+hIBZd/zyEjtqbIjmab+cEX
	XGEnh
X-Gm-Gg: ASbGnct1LHuqIbIuf4tAo9w1NUTQHzCjk3WSBGfEpiW73W1Jbn6632WZDxTW/53noli
	cZn3ywoo1YNJpNpzv1GMZ25noViUa3PB8lTEQDt3vQdoeIIyk3MCoHvSquUwJnprx4Lo5X4lH/k
	e1ks+YvSkl8qWkkh9OoRZC1NZJOaROo3DtGFlFNiBevugEEG6iCl7Hm7uo9xZ0Kkn4cF4/Xfgwo
	bFufq5E9eWH3UTA29THgGeIqkoK6FUBRSB0wgNtGPV6nns4qQ6THuEPDiDSxQ/Fc3C3DA7VumfI
	VQk43J7kxNMQnZ7PLUQNW1rwNMTiy/CgFZcKXI1P7f0kfoi5L/lboZ5aHaBkX+0uK2O70x4+uKc
	fTvToK2UN5c03nbGkNGaXK1lvgVjP97rwPcFDXbNBOrJqWQ1Wvsd25ntEx+4NhaR9rNAEqInCuL
	4H
X-Google-Smtp-Source: AGHT+IHLR9W1AAW8bZY3UEfIgtgmYJsL/LNz6U91e2MZKjQUa//DJo2Ra1QyEyPrRXAvjYqP0w1dWg==
X-Received: by 2002:a05:6000:1849:b0:3e6:a8ba:7422 with SMTP id ffacd0b85a97d-3e765780a9amr3586244f8f.10.1757688271921;
        Fri, 12 Sep 2025 07:44:31 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v4 1/8] CI: Use the Debian Trixie container for RISC-V test jobs
Date: Fri, 12 Sep 2025 15:44:20 +0100
Message-Id: <20250912144427.1905141-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This was missed when introducing Trixie.

Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
Signed-off-by: Andrew Cooper 
Reviewed-by: Denis Mukhin 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v3:
 * New
---
 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 95b883b32bb6..1de68a0fe450 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -77,7 +77,7 @@
 .qemu-riscv64:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-riscv64
+    CONTAINER: debian:13-riscv64
     LOGFILE: qemu-smoke-riscv64.log
   artifacts:
     paths:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122093.1466037 (Exim 4.92)
	(envelope-from )
	id 1ux50y-0005rY-W5; Fri, 12 Sep 2025 14:44:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122093.1466037; Fri, 12 Sep 2025 14: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 1ux50y-0005qr-OZ; Fri, 12 Sep 2025 14:44:40 +0000
Received: by outflank-mailman (input) for mailman id 1122093;
 Fri, 12 Sep 2025 14: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 1ux50x-0004JT-43
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:39 +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 0217de34-8fe7-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 16:44:38 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3e76766a172so679631f8f.0
 for ; Fri, 12 Sep 2025 07:44:38 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07: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: 0217de34-8fe7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688278; x=1758293078; darn=lists.xenproject.org;
        h=content-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=4Fa1/s/Dy+cCaT7ztlJbT+Ce4uvv+WkjLn5aHmuIYYY=;
        b=hRdj06IgGlpYshAXMEJm4k+gqOjvypN1yQqao7oJxeTemST445uAZRJguP2Ue/VdNw
         vhHwl8LH4nbk8n5W4Br93ODle4JOh1mlsgg+w9Vbjn9mFnQ1uB3X/T7kblH8FjnQvS0G
         E1C/ccq1RRlGsj8suQMoF0SmuGB8zXEUlVY8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688278; x=1758293078;
        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=4Fa1/s/Dy+cCaT7ztlJbT+Ce4uvv+WkjLn5aHmuIYYY=;
        b=rzb5QwxGD507d7YT+X39SE8dVxOWSP50EQ5w7x+5x8NWY3yHy5vdFE/Cm7JXuGNn+A
         ZXER+Ew7HVqiNG7I92L8DVZ7EG2IF97x8Tu4Xfrrn7Wl1cfSqleb2CFprRp7xBr4IPoG
         WAMnDqzYox1KuPnPzyolLkKKCz1W2sAFMK+2Ce9adfKHmtKr+37NRbLX3+Z46j+FUx0S
         txQdtHhkV25Y9WULmLLVSOErrWTIQx8BXtrxFr9g16OzROylo8P5aWZqX+Bsx1TlIAtE
         H7jfrkDR71Xmn9gNT4iy0UYBykHF9C9NCIbczjOysCKIHPge6TxsidDzswqSYivcfmRG
         xeaw==
X-Gm-Message-State: AOJu0YzB7ubfZaohMi0JGS0aWdSgNkz/vTB3hG6zRQ1uliqrL6W1AAC/
	tjTDYyi3R9QMo2zOn8klVeBRkM/prjbCNGFrzuQeeXa0z4FZrrRqX4poVZqULlPZlF0TnzHbjAg
	qUIKG
X-Gm-Gg: ASbGncsGyz/hD5chJoFSeCatm4iq9brUkU+mP0FeFiuHKch+1fCyOm3DClxGgRa1t1X
	Q4Tn9fO2A64AtA2FaJMoJy7DoYu8Xljjl+4FGS4yt940lLMYShV0+IpPITJGi+7A9M8988TtH9f
	OrEsoGsc4f+FyVAZ1d52gwJTAapI28/0BI9VSmlFAnMLA8+E6ESBUFNAoHa/a3XwzvpgAdZjr8Z
	JoJk+r1YvLoHSzVR3zBZ17fCQ9XG/Ml22CNhe3hOjzwMhT7e783MUOpxCO6Yi1OuqVo2XvtUPO+
	rpORySiFxxE2G1RQA1N6Jh4ugPxSLVOfWn7xQEluAuLXVgtWNo+qQeNoGXtdb8l7NPRJuejoZt9
	PH5WtgJkeYab1Z1nYQk1xZgTFKyc29JMJdeKoz48/DLgxK0y6B3wDOcAAx9+t07izmd+rXyZqm6
	P1
X-Google-Smtp-Source: AGHT+IFtxjvc/nwlNgff2Wk70EZffbLeEHdBX9p4nUZmKLib84yJUpcgSHaEkkPdbPVwfWrdywmapw==
X-Received: by 2002:a05:6000:4023:b0:3e2:4a3e:d3ee with SMTP id ffacd0b85a97d-3e765a14133mr2670234f8f.58.1757688277654;
        Fri, 12 Sep 2025 07:44:37 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Victor Lira 
Subject: [PATCH v4 7/8] CI: Update x86 to use Debian Trixie
Date: Fri, 12 Sep 2025 15:44:26 +0100
Message-Id: <20250912144427.1905141-8-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the exception of the custom IBT job, copy all Debian 12 jobs making
Debian 13 versions, then trim the Debian 12 ranconfig jobs.

Update the test jobs using Debian 12 to use 13.

Signed-off-by: Andrew Cooper 
Reviewed-by: Denis Mukhin 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: Doug Goldstein 
CC: Marek Marczykowski-Górecki 
CC: Victor Lira 

v3:
 * Update .qemu-x86-64 too.
 * Rebase over cleanup to 12-x86_64
v2:
 * Make 13-x86_64 be root-less
 * Update containerize
---
 ...x86_32.dockerfile => 13-x86_32.dockerfile} |  2 +-
 ...x86_64.dockerfile => 13-x86_64.dockerfile} |  2 +-
 automation/gitlab-ci/build.yaml               | 54 ++++++++++++++-----
 automation/gitlab-ci/test.yaml                | 12 ++---
 automation/scripts/containerize               |  3 +-
 5 files changed, 52 insertions(+), 21 deletions(-)
 copy automation/build/debian/{12-x86_32.dockerfile => 13-x86_32.dockerfile} (95%)
 copy automation/build/debian/{12-x86_64.dockerfile => 13-x86_64.dockerfile} (96%)

diff --git a/automation/build/debian/12-x86_32.dockerfile b/automation/build/debian/13-x86_32.dockerfile
similarity index 95%
copy from automation/build/debian/12-x86_32.dockerfile
copy to automation/build/debian/13-x86_32.dockerfile
index 447152d7e5e4..464b4fc55e38 100644
--- a/automation/build/debian/12-x86_32.dockerfile
+++ b/automation/build/debian/13-x86_32.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/i386 debian:bookworm
+FROM --platform=linux/i386 debian:trixie-slim
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/build/debian/12-x86_64.dockerfile b/automation/build/debian/13-x86_64.dockerfile
similarity index 96%
copy from automation/build/debian/12-x86_64.dockerfile
copy to automation/build/debian/13-x86_64.dockerfile
index 4e533ee879fd..2c6c9d4a5098 100644
--- a/automation/build/debian/12-x86_64.dockerfile
+++ b/automation/build/debian/13-x86_64.dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM --platform=linux/amd64 debian:bookworm
+FROM --platform=linux/amd64 debian:trixie-slim
 LABEL maintainer.name="The Xen Project"
 LABEL maintainer.email="xen-devel@lists.xenproject.org"
 
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index f8e45f3467c8..4cb52fe59715 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -309,15 +309,15 @@ alpine-3.18-gcc-debug:
       CONFIG_UCODE_SCAN_DEFAULT=y
       CONFIG_XHCI=y
 
-debian-12-x86_64-gcc-debug:
+debian-13-x86_64-gcc-debug:
   extends: .gcc-x86-64-build-debug
   variables:
-    CONTAINER: debian:12-x86_64
+    CONTAINER: debian:13-x86_64
 
-debian-12-x86_64-clang-debug:
+debian-13-x86_64-clang-debug:
   extends: .clang-x86-64-build-debug
   variables:
-    CONTAINER: debian:12-x86_64
+    CONTAINER: debian:13-x86_64
 
 debian-13-ppc64le-gcc-debug:
   extends: .gcc-ppc64le-cross-build-debug
@@ -545,24 +545,20 @@ debian-12-x86_64-clang:
   variables:
     CONTAINER: debian:12-x86_64
 
-debian-12-x86_64-clang-randconfig:
-  extends: .clang-x86-64-build
+debian-12-x86_64-clang-debug:
+  extends: .clang-x86-64-build-debug
   variables:
     CONTAINER: debian:12-x86_64
-    RANDCONFIG: y
-    EXTRA_FIXED_RANDCONFIG: |
-      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
 
 debian-12-x86_64-gcc:
   extends: .gcc-x86-64-build
   variables:
     CONTAINER: debian:12-x86_64
 
-debian-12-x86_64-gcc-randconfig:
-  extends: .gcc-x86-64-build
+debian-12-x86_64-gcc-debug:
+  extends: .gcc-x86-64-build-debug
   variables:
     CONTAINER: debian:12-x86_64
-    RANDCONFIG: y
 
 debian-12-x86_32-clang-debug:
   extends: .clang-x86-32-build-debug
@@ -574,6 +570,40 @@ debian-12-x86_32-gcc-debug:
   variables:
     CONTAINER: debian:12-x86_32
 
+debian-13-x86_64-clang:
+  extends: .clang-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+
+debian-13-x86_64-clang-randconfig:
+  extends: .clang-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+    RANDCONFIG: y
+    EXTRA_FIXED_RANDCONFIG: |
+      CONFIG_COVERAGE=n # Disable coverage otherwise build times out.
+
+debian-13-x86_64-gcc:
+  extends: .gcc-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+
+debian-13-x86_64-gcc-randconfig:
+  extends: .gcc-x86-64-build
+  variables:
+    CONTAINER: debian:13-x86_64
+    RANDCONFIG: y
+
+debian-13-x86_32-clang-debug:
+  extends: .clang-x86-32-build-debug
+  variables:
+    CONTAINER: debian:13-x86_32
+
+debian-13-x86_32-gcc-debug:
+  extends: .gcc-x86-32-build-debug
+  variables:
+    CONTAINER: debian:13-x86_32
+
 fedora-41-x86_64-gcc:
   extends: .gcc-x86-64-build
   variables:
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index e8946e15dc3a..8d8f62c8d04d 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -59,7 +59,7 @@
 .qemu-x86-64:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-x86_64
+    CONTAINER: debian:13-x86_64
     LOGFILE: qemu-smoke-x86-64.log
   artifacts:
     paths:
@@ -661,35 +661,35 @@ qemu-smoke-x86-64-gcc:
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-smoke-x86-64-clang:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-clang-debug
+    - debian-13-x86_64-clang-debug
 
 qemu-smoke-x86-64-gcc-pvh:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 hvm64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-smoke-x86-64-clang-pvh:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64 hvm64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-clang-debug
+    - debian-13-x86_64-clang-debug
 
 qemu-smoke-x86-64-gcc-efi:
   extends: .qemu-smoke-x86-64
   script:
     - ./automation/scripts/qemu-xtf.sh x86-64-efi pv64 example 2>&1 | tee ${LOGFILE}
   needs:
-    - debian-12-x86_64-gcc-debug
+    - debian-13-x86_64-gcc-debug
 
 qemu-xtf-argo-x86_64-gcc-debug:
   extends: .qemu-smoke-x86-64
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 65c8804ce5f3..743567cb772a 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -35,7 +35,8 @@ case "_${CONTAINER}" in
     _bookworm-riscv64) CONTAINER="${BASE}/debian:12-riscv64" ;;
     _trixie-riscv64) CONTAINER="${BASE}/debian:13-riscv64" ;;
     _bookworm-x86_64-gcc-ibt) CONTAINER="${BASE}/debian:12-x86_64-gcc-ibt" ;;
-    _bookworm|_bookworm-x86_64|_) CONTAINER="${BASE}/debian:12-x86_64" ;;
+    _bookworm|_bookworm-x86_64) CONTAINER="${BASE}/debian:12-x86_64" ;;
+    _trixie-x86_64|_) CONTAINER="${BASE}/debian:13-x86_64" ;;
     _bookworm-i386|_bookworm-x86_32) CONTAINER="${BASE}/debian:12-x86_32" ;;
     _bookworm-arm64v8-arm32-gcc) CONTAINER="${BASE}/debian:bookworm-arm64v8-arm32-gcc" ;;
     _bookworm-arm64v8) CONTAINER="${BASE}/debian:bookworm-arm64v8" ;;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 14:44:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 14:44:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122095.1466047 (Exim 4.92)
	(envelope-from )
	id 1ux510-0006Du-HG; Fri, 12 Sep 2025 14:44:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122095.1466047; Fri, 12 Sep 2025 14:44: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 1ux510-0006DR-BZ; Fri, 12 Sep 2025 14:44:42 +0000
Received: by outflank-mailman (input) for mailman id 1122095;
 Fri, 12 Sep 2025 14:44: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 1ux50z-0004JZ-6X
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 14:44:41 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 02be5f71-8fe7-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 16:44:39 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-45b9814efbcso19519135e9.0
 for ; Fri, 12 Sep 2025 07:44:39 -0700 (PDT)
Received: from localhost.localdomain (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e015784c3sm72070045e9.10.2025.09.12.07.44.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 12 Sep 2025 07:44:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 02be5f71-8fe7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757688279; x=1758293079; darn=lists.xenproject.org;
        h=content-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=qEVGh+hBiy0tcYl95EH1DJJNtCx14TTBNUGE0bJJUpQ=;
        b=WyP6a/ulZBhazQu9MuUso7Kb8WSJBlyVuz1sTMw7z9TR5RXfJpLSxc9XnrNEW+DBiT
         Qunr7ejzEiyO9Fnj2UPOm9Kvhy8UDdfsM+c/KMmnS2i0Mt29yjNui1ztHR1d/xV2Glo0
         uDWvz9KtiM2RM/ImnDFFbH6tNfLmXwFLI0irw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757688279; x=1758293079;
        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=qEVGh+hBiy0tcYl95EH1DJJNtCx14TTBNUGE0bJJUpQ=;
        b=HDGtrmbDXA33LgrQd4dLf86WcP3ke4rziRQ2kOk72Gno/GYfNxgUYJaKge3zVvBDAH
         460s+1DBWjclRs2p85iS0BNjVyA+3q7ulxlidAfZvQ8zcSVUzDZDZAHQRu7pFZvBI8vi
         eleu1NnZmnP8uiR9J/IE60HOTT52K1sS8h4T80SyyFed5YIxGcYauo6wYPS5KejWCx8i
         PD3ShztYiP5txHzrL1iwjLY9Uu/14ryS7v73fcMx9POqm2+cV/NSPsu1XmR2gS9zXUVg
         DZKscdk4LRJTdqd9C6ftqGo0i2VknJ0/LeSI1o13iN0cVJKrX7qpq5ulggS0MTo/4vKx
         G2lQ==
X-Gm-Message-State: AOJu0YxGW5hQO/9RVNkBDiO0hY1mja8qMvVE8Re9PRH6qBvrQ+PiOJja
	WAyf/kWFTsZcQ0a+PEUjzs/Wd7XgtqFQIFbCsj7tLcpQwMy5dG6rUHISQYQU0g4pskWvsMzTm4P
	RsbGv
X-Gm-Gg: ASbGncvoBJNxpgE175qZbvGD2eWbhMZKeZG9GTE1JWpnZ6fOp6Y3+3zvAl4KoIrbcQt
	y5sqSBO+uto4QV7dsu14YS4w7lrqfQ1RUEPG6PSC9H6FZg4wZblzVIVcl3pj48xIy30b2+pfHml
	OBbiSUaFQ6cVqGap1E7FzcAAaWFlJ1x/2ZS1izuWjRWLFlz5N7Aw2Js+P5zzoJNqn/9T9SkE9u3
	V+HHXwlytNBCm06foOmSQieRvFBYVQOBULWBiSpvFs1RFNTbjE0f8ITKHk/UYXrJPM8vOguv6Hh
	erDIn3r8oYQBgbE33z+obgKH6zZT047wRbcNa0qLybuFxS1DlvxVzHCBYGq8ISuFGR99+/NP6kN
	UyNU1FVBBpILeC4c7UmA5vTBx/B2gLp7jBmsMY6+f7wC6S3byRRNFatjReqtcfZp9WBewftr1Uv
	wBPbV0VZtLWdw=
X-Google-Smtp-Source: AGHT+IHbTNMNvOgl9nb7GA+1YNnbAV3yQpRDlAuoAvo8j6kYhG8i+CyDFWOLgim1UcuhTXGEWTEPOQ==
X-Received: by 2002:a05:600c:8886:b0:45c:b642:87a6 with SMTP id 5b1f17b1804b1-45dfd54ac60mr57713025e9.0.1757688278699;
        Fri, 12 Sep 2025 07:44:38 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Oleksii Kurochko ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 8/8] CHANGELOG: Notes about distro changes in CI
Date: Fri, 12 Sep 2025 15:44:27 +0100
Message-Id: <20250912144427.1905141-9-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Also state the RISC-V baseline now it's been set, as it's the reason why
RISC-V Bullseye got dropped.

Signed-off-by: Andrew Cooper 
Acked-by: Oleksii Kurochko 
Reviewed-by: Denis Mukhin 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Oleksii Kurochko 

v2:
 * New
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7bd96ac09d14..ca1b43b940d2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -10,6 +10,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - The minimum toolchain requirements have increased for some architectures:
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
+   - For RISC-V, GCC 12.2 and Binutils 2.39
+ - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
+   to the baseline change.
  - Linux based device model stubdomains are now fully supported.
 
  - On x86:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 15:03:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 15:03:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122212.1466058 (Exim 4.92)
	(envelope-from )
	id 1ux5IZ-0003Rl-3D; Fri, 12 Sep 2025 15:02:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122212.1466058; Fri, 12 Sep 2025 15:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux5IY-0003Re-VV; Fri, 12 Sep 2025 15:02:50 +0000
Received: by outflank-mailman (input) for mailman id 1122212;
 Fri, 12 Sep 2025 15: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 1ux5IX-0003RW-U7
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 15:02:49 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 89047bd8-8fe9-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 17:02:44 +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 DCD5812FC;
 Fri, 12 Sep 2025 08:02:34 -0700 (PDT)
Received: from [10.57.66.147] (unknown [10.57.66.147])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 558333F694;
 Fri, 12 Sep 2025 08:02: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: 89047bd8-8fe9-11f0-9809-7dc792cee155
Message-ID: 
Date: Fri, 12 Sep 2025 17:02:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections
To: David Hildenbrand ,
 Alexander Gordeev 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Andreas Larsson ,
 Andrew Morton ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com>
 <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com>
 <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com>
 <7953a735-6129-4d22-be65-ce736630d539@redhat.com>
 <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com>
 
 <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com>
 <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com>
 <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com>
 
 
 <852d6f8c-e167-4527-9dc9-98549124f6b1@redhat.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <852d6f8c-e167-4527-9dc9-98549124f6b1@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/09/2025 16:25, David Hildenbrand wrote:
>
>>
>> But I do not really expect it ever, since arch_enter_lazy_mmu_mode_pte()
>> is only to be called in PTE walkers that never span more than one page
>> table and follow the pattern:
>
> Well, the cover letter here states:
>
> "Unfortunately, a corner case (DEBUG_PAGEALLOC) may still cause
> nesting to occur on arm64. Ryan proposed [2] to address that corner
> case at the generic level but this approach received pushback; [3]
> then attempted to solve the issue on arm64 only, but it was deemed too
> fragile."
>
> So I guess we should support nesting cleanly, at least on the core-mm
> side.

Nesting remains a rare occurrence though. I think it would be plausible
to require this new interface to be used in a region where no nesting
can occur, just like pause()/resume().

In fact, I think this is a requirement if we go for the approach we have
been discussing, because nested enter()/leave() calls are not meant to
call arch_enter()/arch_leave(), and I really wouldn't want to use a
different logic for this variant.

>
> I guess we could start with saying "well, s390x doesn't fully support
> nesting yet but doing so just requires changing the way we manage this
> per-nesting-level state internally".
>
> s390 is trying to do something different than the other archs here, so
> that naturally concerns me :)
>
> But if it's really just about forwarding that data and having s390
> store it somewhere (task_struct, percpu variable, etc), fine with me. 

Yes I think this is fine, with the restriction above. The extra
arguments are directly forwarded to arch code and otherwise ignored by
core code, and unless the arch defines some __HAVE_ARCH... or CONFIG,
the extended interface falls back to regular enter()/leave().

- Kevin


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 15:25:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 15:25:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122232.1466069 (Exim 4.92)
	(envelope-from )
	id 1ux5ee-0006hR-QC; Fri, 12 Sep 2025 15:25:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122232.1466069; Fri, 12 Sep 2025 15: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 1ux5ee-0006hK-MO; Fri, 12 Sep 2025 15:25:40 +0000
Received: by outflank-mailman (input) for mailman id 1122232;
 Fri, 12 Sep 2025 15:25: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 1ux5ed-0006hE-KO
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 15:25:39 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id bbaf3a8c-8fec-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 17:25:37 +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 6E94328AC;
 Fri, 12 Sep 2025 08:25:28 -0700 (PDT)
Received: from [10.57.66.147] (unknown [10.57.66.147])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 301DA3F694;
 Fri, 12 Sep 2025 08:25: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: bbaf3a8c-8fec-11f0-9d13-b5c5bf9af7f9
Message-ID: <338ef811-1dab-4c4e-bc5f-8ebd8cb68435@arm.com>
Date: Fri, 12 Sep 2025 17:25:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Kevin Brodsky 
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
To: David Hildenbrand ,
 Andrew Morton 
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Alexander Gordeev ,
 Andreas Larsson ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
 
Content-Language: en-GB
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/09/2025 11:21, David Hildenbrand wrote:
> On 09.09.25 04:16, Andrew Morton wrote:
>> On Mon,  8 Sep 2025 08:39:24 +0100 Kevin Brodsky
>>  wrote:
>>
>>> The main change enabling nesting is patch 2, following the approach
>>> suggested by Catalin Marinas [4]: have enter() return some state and
>>> the matching leave() take that state.
>>
>> This is so totally the correct way.  Thanks.
>
> Staring at this, I wonder if we could alternatively handle it like
> pagefault_disable()/pagefault_enable(), having something like
> current->lazy_mmu_enabled.
>
> We wouldn't have to worry about preemption in that case I guess
> (unless the arch has special requirements).
>
> Not sure if that was already discussed, just a thought. 

Based on the outcome of the discussion with David on patch 2 [1p], there
is indeed an alternative approach that we should seriously consider. In
summary:

* Keep the API stateless, handle nesting with a counter in task_struct
* Introduce new functions to temporarily disable lazy_mmu without
impacting nesting, track that with a bool in task_struct (addresses the
situation in mm/kasan/shadow.c and possibly some x86 cases too)
* Move as much handling from arch_* to generic functions

What the new generic infrastructure would look like:

struct task_struct {
    ...
#ifdef CONFIG_ARCH_LAZY_MMU
    struct {
        uint8_t count;
        bool enabled; /* or paused, see below */
    } lazy_mmu_state;
#endif
}

* lazy_mmu_mode_enable():
    if (!lazy_mmu_state.count) {
        arch_enter_lazy_mmu_mode();
        lazy_mmu_state.enabled = true;
    }
    lazy_mmu_state.count++;

* lazy_mmu_mode_disable():
    lazy_mmu_count--;
    if (!lazy_mmu_state.count) {
        lazy_mmu_state.enabled = false;
        arch_leave_lazy_mmu_mode();
    } else {
        arch_flush_lazy_mmu_mode();
    }

* lazy_mmu_mode_pause():
    lazy_mmu_state.enabled = false;
    arch_leave_lazy_mmu_mode();

* lazy_mmu_mode_resume();
    arch_enter_lazy_mmu_mode();
    lazy_mmu_state.enabled = true;

The generic enable()/disable() helpers are able to handle most of the
logic, leaving only truly arch-specific code to the arch callbacks:
* Updating lazy_mmu_state
* Sanity checks on lazy_mmu_state (e.g. count underflow/overflow,
pause()/resume() only called when count > 0, etc.)
* Bailing out if in_interrupt() (not done consistently across arch's at
the moment)

A further improvement is to make arch code check lazy_mmu_state.enabled
to determine whether lazy_mmu is enabled at any given point. At the
moment every arch uses a different mechanism, and this is an occasion to
make them converge.

The arch callback interface remains unchanged, and we are resurrecting
arch_flush_lazy_mmu_mode() to handle the nested disable() case (flushing
must happen when exiting a section regardless of nesting):

enable() -> arch_enter()
    enable() -> [nothing]
    disable() -> arch_flush()
disable() -> arch_leave()

Note: lazy_mmu_state.enabled (set whenever lazy_mmu is actually enabled)
could be replaced with lazy_mmu_state.paused (set inside a
pause()/resume() section). I believe this is equivalent but the former
is slightly more convenient for arch code - to be confirmed in practice.

Any thoughts on this? Unless there are concerns, I will move towards
that approach in v3.

- Kevin

[1p]
https://lore.kernel.org/all/4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com/t/#u



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 15:35:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 15:35:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122264.1466078 (Exim 4.92)
	(envelope-from )
	id 1ux5oD-0008Uz-KB; Fri, 12 Sep 2025 15:35:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122264.1466078; Fri, 12 Sep 2025 15: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 1ux5oD-0008Us-H9; Fri, 12 Sep 2025 15:35:33 +0000
Received: by outflank-mailman (input) for mailman id 1122264;
 Fri, 12 Sep 2025 15: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 1ux5oC-0008Su-BP
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 15:35:32 +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 1ce3f907-8fee-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 17:35:30 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 4F04B1400459;
 Fri, 12 Sep 2025 11:35:29 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Fri, 12 Sep 2025 11:35:29 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 12 Sep 2025 11:35: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: 1ce3f907-8fee-11f0-9d13-b5c5bf9af7f9
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=1757691329;
	 x=1757777729; bh=N878IgmG87czFFaXvhNllDFTWf5isiDCSYiZ1CojGH8=; b=
	UgwaAVgjfldmkQVJc9M5MLmxXgoajhU9j9bdi+p+QygNfRqnTlRwUDbPJomZMZ5u
	lGxPExOpU72Poqx1P4IlSCI78d38gPnMVltUMRkAZoaVs2LI/4ltZgwI4KsXHMP2
	AJmY2a9rxdVef4q6dp9DaeOyfSaGtT735FA58FpLm7jgkHBKseXzbZK6TelHZHKd
	YZfZBISyrQvgHuUWtA0yxSFV9rR9iY4AaIpYPgl8BENu3tjbhiym+MYGGpEy4xtu
	AqXr93mDFkGzH+kPU/HiYjfeLWmKzNM86Sr+ePwvPIfnGDS6UDPjEttq9sjFby1a
	zNApuMknRC+fkejNynoTqA==
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=
	1757691329; x=1757777729; bh=N878IgmG87czFFaXvhNllDFTWf5isiDCSYi
	Z1CojGH8=; b=b5W/wOIshuYHkwx8n2Z8VmVN1j1s2suZH2QBxp1NPZ81/Hlb+9X
	mN8Xw4J4ZPknuHM3YT3/W0sHuIzkyBN5pK+3s664rnqZJX8P1BsTinUCWqKHKgyy
	jKPwm8335hKdydxW3db8s/vFpZvZmsA/ZdmPgCJsxat94J48Gv9/YxbO824qzrG9
	Fv1YJfnIC7Yj8QDlJPtgRR8dJb4fJ4tvfutH1i2apRKCGNV4zWnzCnw8w1iUqITL
	nFZfi2Fc9iQcbHwzk3AqGZS2g4+RHdybbRjYbmBlU0aF4xFTx2Xta54EDEjZ+QTy
	sL6eVZdxOqFw+/9aWeMDxJjM/j0hE9yV3uQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvleegfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeduvddpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegt
    ihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvg
    hnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghruges
    vhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurd
    gtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthho
    pehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtih
    htrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdr
    ohhrghdprhgtphhtthhopehsrghnrghsthgrshhiohesrhgrphhtohhrvghnghhinhgvvg
    hrihhnghdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 12 Sep 2025 17:35:25 +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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 6/8] CI: Use pipefail in scripts/build
Message-ID: 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-7-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="q81WF+hWZXgVrHl1"
Content-Disposition: inline
In-Reply-To: <20250912144427.1905141-7-andrew.cooper3@citrix.com>


--q81WF+hWZXgVrHl1
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Sep 2025 17:35:25 +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 ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 6/8] CI: Use pipefail in scripts/build

On Fri, Sep 12, 2025 at 03:44:25PM +0100, Andrew Cooper wrote:
> Marek noticed that some builds were failing with:
>=20
>   + cd dist/install
>   + find
>   + cpio -R 0:0 -o -H newc
>   ./automation/scripts/build: line 111: cpio: command not found
>   + gzip
>=20
> but succeeding overall, and producing a zero length xen-tools.cpio.gz as =
an
> artefact.
>=20
> In fact, it's all of:
>=20
>   archlinux:current
>   debian:12-x86_32
>   fedora:41
>   opensuse:tumbleweed
>   ubuntu (all versions)
>=20
> Add cpio into all of these containers, including opensuse leap for good
> measure, and use pipefail in the build script.
>=20
> Fixes: 4611ae6fb8f9 ("CI: save toolstack artifact as cpio.gz")
> Reported-by: Marek Marczykowski-G=C3=B3recki 
> Signed-off-by: Andrew Cooper 

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


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

--q81WF+hWZXgVrHl1
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjEPb0ACgkQ24/THMrX
1ywHqgf/cd7wMyXHKnPl3O9dGa6YrPxBuG5mLXrbhzxrtTCl1MumRuPdIgHSy9b3
HsXdnjgkxijEXtjjdsqd/t+SXh0bU0AuAS6qsRRMp8fMG045cCjLSaVQCx3Vrai5
cucpsHUlh3TK2VsAmMmiOCGC0kAPX7LgEEJPYSBzqlyfG0JTl8XbxegS5/NmDnRq
QSpZxUrnFKBoIY4G9XtXflHJEvNql2KaosTd7te+CLBPPec6G0WRTDRsxZvfTsXk
lq9gEgOXDQDs5NT54CiZZrAUpkb+DvY6blRRECS+UeufQCERClecNn/pVoBxC1Nn
m26vLddf9hBGvoyDAYt+LhSQNVxrrA==
=9W0q
-----END PGP SIGNATURE-----

--q81WF+hWZXgVrHl1--


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 15:40:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 15:40:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122281.1466087 (Exim 4.92)
	(envelope-from )
	id 1ux5t5-0001kg-52; Fri, 12 Sep 2025 15:40:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122281.1466087; Fri, 12 Sep 2025 15:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1ux5t5-0001kZ-2Q; Fri, 12 Sep 2025 15:40:35 +0000
Received: by outflank-mailman (input) for mailman id 1122281;
 Fri, 12 Sep 2025 15:40: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 1ux5t4-0001kT-Do
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 15:40:34 +0000
Received: from fout-a6-smtp.messagingengine.com
 (fout-a6-smtp.messagingengine.com [103.168.172.149])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0c9b1b4-8fee-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 17:40:32 +0200 (CEST)
Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50])
 by mailfout.phl.internal (Postfix) with ESMTP id 3232DEC04C3;
 Fri, 12 Sep 2025 11:40:31 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-10.internal (MEProxy); Fri, 12 Sep 2025 11:40:31 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 12 Sep 2025 11:40: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: d0c9b1b4-8fee-11f0-9809-7dc792cee155
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=1757691631;
	 x=1757778031; bh=d/7uUIl3/7ovbLOxZ3GgywGud51wODORRvQXRsz3s6A=; b=
	bUgULeMYcYJLjvuQcdghS/TmnJNHaqPV3Hg2HUTtOdh1QFtbhStOVVMfQNg23qZa
	jSgdwfTHVOT6W4tgwqYG7qdLND2MoUnyP30VQ497Is8F8Yut5h1JmrjzWpE2VRiU
	NQFqBx4cOvXJKGDccMxJxpkNwcLsLYLCJ3UNuEB5j5l0ReIGJfylzd/2NZZABZCh
	khGRJD4a74nppCa9+WNP8D1ZvJ0gs/upKyinyOKC7DI89xgmfFOM26t92AoRozyR
	Qz+fr6eIE13MnePnHwAlOMbNNgfvt6ofTh4lfa7xks16vDLAZQNLCsP3gBckFrv3
	1vItMVDFrgfk1RoE1ID+0w==
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=
	1757691631; x=1757778031; bh=d/7uUIl3/7ovbLOxZ3GgywGud51wODORRvQ
	XRsz3s6A=; b=mEMSuGDtB9TzZ/YzH0R7CPEiSDtn18w3+JSNRTqkM4vWgkBfWjL
	hc+59U/Fme6IA2GRR03esNeIaUWMxKdS0LJByv6VtR5CDLqqQMU0gdNDEEi6cQMx
	bpnCfbhy/HwPjkcdVZQo2nzpODxJmgx/UQqDvBcm/ujx2iQ3FRlzCQE/OaF4bQKh
	y7WiEtQI3pnp0QgV0LbPoL+4PC1Og7XLxpIGTl2kZMcKjd3//qUC4nyx9PPLYs6L
	ZiuPaGUlrsPo6TvvqRKELksonrjtzADxtmVNDdzbbR0FjyRB8cmAcXUeZycmkgK3
	/DCSDvsIU2lYWhQHIGaKy8z6EXilREQjVwg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvleeggecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedufedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegt
    ihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvg
    hnphhrohhjvggtthdrohhrghdprhgtphhtthhopegumhhukhhhihhnsehfohhrugdrtgho
    mhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpd
    hrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohep
    jhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnh
    drohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgt
    phhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 12 Sep 2025 17:40:27 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 7/8] CI: Update x86 to use Debian Trixie
Message-ID: 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-8-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="fiUeKHBbhTAFVbIy"
Content-Disposition: inline
In-Reply-To: <20250912144427.1905141-8-andrew.cooper3@citrix.com>


--fiUeKHBbhTAFVbIy
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Sep 2025 17:40:27 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 7/8] CI: Update x86 to use Debian Trixie

On Fri, Sep 12, 2025 at 03:44:26PM +0100, Andrew Cooper wrote:
> With the exception of the custom IBT job, copy all Debian 12 jobs making
> Debian 13 versions, then trim the Debian 12 ranconfig jobs.
>=20
> Update the test jobs using Debian 12 to use 13.
>=20
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Denis Mukhin 

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

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjEPusACgkQ24/THMrX
1yz8KAf/dbUffz4fEa4yRtUeDlEI4yuaMEUK84j4z7Nc5pgjka+6JOUMl8VmqZx4
qzK7YszO8DxZ6Fz/tjsEIeKGoj8Whaa+lCtAvZXMavlDOBtBvB8nxr194HB8jjnD
vtaOiCUbnncnAcjkgbMRLVmJ1zfi5oA4FQhsruNEg49NhANsT+s8/CPL4xFSUJLZ
cpRQ+TI+FRIy2+OEWYFUbvHwPyrSHgz9CBvowPzSKsvTDi6ra56RMTUF1dDCZ5+k
3xH3xdTfnfQg+0lG6/t1hfM6x4mPVtR7Go66SJFmu2Ai6T8JQa1pYi/ip9PRABCb
6D/SyqnGaBYXaISxufQAoSxHnOPFWA==
=RHJd
-----END PGP SIGNATURE-----

--fiUeKHBbhTAFVbIy--


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 15:41:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 15:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122294.1466098 (Exim 4.92)
	(envelope-from )
	id 1ux5ty-0002Hg-Iu; Fri, 12 Sep 2025 15:41:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122294.1466098; Fri, 12 Sep 2025 15: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 1ux5ty-0002HZ-FE; Fri, 12 Sep 2025 15:41:30 +0000
Received: by outflank-mailman (input) for mailman id 1122294;
 Fri, 12 Sep 2025 15:41: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 1ux5tx-000225-7a
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 15:41:29 +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 f1cbb760-8fee-11f0-9d13-b5c5bf9af7f9;
 Fri, 12 Sep 2025 17:41:27 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id CF8FF14003F4;
 Fri, 12 Sep 2025 11:41:26 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Fri, 12 Sep 2025 11:41:26 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 12 Sep 2025 11:41:24 -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: f1cbb760-8fee-11f0-9d13-b5c5bf9af7f9
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=1757691686;
	 x=1757778086; bh=rwksSHDdUzKpjOvN/NyoUqYRPNHs+BbfkGgXLjLMB40=; b=
	L+F42A1XBqJuKvJf6d9SIO9J3rNb9QtgKWRzVi+esIQirsb0Z7zAN9xhMiHOpZKZ
	620IRWX60mZtiKwhdDH3W6I4ld6saAYzUhxxvANy5EZ8zI075ewCP7pRNfRMBsqx
	mZIyH91hdUq0ptC25EB3WqVwubZKloaVuS9P1JPr1Nc4NZfarrlPlXZB/FD7Rjxn
	mWJPo5KQJjf3lpR2mto16eH/6krAUk14GTlzVB9Aj2Dsgj/7ylYz4LOzIpdCJE7O
	BVQ3+DKVxWhW2CPjCyfvgjhS2Nwm3y6qd0x6C1OGmaPJrQnHZk/Z7F6PLo6xuOV9
	lOTYc/ht1qD4Jz8lxYPB+A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
	1757691686; x=1757778086; bh=rwksSHDdUzKpjOvN/NyoUqYRPNHs+BbfkGg
	XLjLMB40=; b=ILuvaCu3vd+cVKXhbfBkEFiQ2XvdLxGoO95Vd88j3yYnvclQgmX
	MJjL5oRtzAFwdol8wHf6OtiPmstm0/FTz/BYGF09AKMb4XaC596GO079I372ge7T
	7MirTTT5d94Fw4PeAsYWwQVvhWE5w+07IiS+3TGSjzMMDxST7nN5AOyDUycJYT1U
	2JmjwSmNsMBdISVAVVNUe0X/KTHSuvNFDRHMQ3SWgtvdKp0i+U0NL2/IB+V8JT8H
	ehI80fKAjUOAmotzXx31Pr5wYkB0Lz5/6jMHX2R02gs/gU7DQUM2kDopzNO+h3KQ
	eiPEj5K7JVti4FhIUpb2yD0PdfDTU2HV9qA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvleeggecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedufedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegt
    ihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvg
    hnphhrohhjvggtthdrohhrghdprhgtphhtthhopegumhhukhhhihhnsehfohhrugdrtgho
    mhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpd
    hrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohep
    jhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnh
    drohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgt
    phhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 12 Sep 2025 17:41:23 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 3/8] CI: Merge categories in
 debian/12-x86_64.dockerfile
Message-ID: 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-4-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="+vMEMMthi/UCmWIG"
Content-Disposition: inline
In-Reply-To: <20250912144427.1905141-4-andrew.cooper3@citrix.com>


--+vMEMMthi/UCmWIG
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Sep 2025 17:41:23 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Denis Mukhin ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 3/8] CI: Merge categories in
 debian/12-x86_64.dockerfile

On Fri, Sep 12, 2025 at 03:44:22PM +0100, Andrew Cooper wrote:
> cpio needs to be in Tools (general) now that it's used by the general bui=
ld
> script.  Merge the rest of the test phase jobs into one group, to avoid b=
eing
> overly fine-grain.
>=20
> No functional change.
>=20
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Denis Mukhin 

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

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

--+vMEMMthi/UCmWIG
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjEPyMACgkQ24/THMrX
1yzJZgf9HJCHFHktXoFcdByD/lYyBDjJLSTLejMIOYp357ZonBJ6kpWFuHdA7wVx
nvfR6AEzqo07Da/sOuIMwn+JJuGYQPWpS3JrHQC+mlOoYieu/E4xlaNI8F6vqYlU
fPxQ3v2ypy6KCm8jDmh97F3H9bBz9nC2ZfAVYeNxZn4xT4rQKYF3HBYzFdDfMuQG
VASVI3sRKBNwph5CBBVU/m0frm77Mpac749OIKFLgdsIBy6lWhDSGRpAdn6J6+ys
WeKdJQkAmU/5/T56N+PnPdm3LRJBAG0CFGxzgzo+2PZibTfIQq04CG50fdX7VvtR
Xx5bZSGTfTriQ6od6afyNc+kF4fkZw==
=u1jk
-----END PGP SIGNATURE-----

--+vMEMMthi/UCmWIG--


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 17:01:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 17:01:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122363.1466108 (Exim 4.92)
	(envelope-from )
	id 1ux79I-0004kM-13; Fri, 12 Sep 2025 17:01:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122363.1466108; Fri, 12 Sep 2025 17:01: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 1ux79H-0004kF-Ua; Fri, 12 Sep 2025 17:01:23 +0000
Received: by outflank-mailman (input) for mailman id 1122363;
 Fri, 12 Sep 2025 17:01: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 1ux79G-0004k9-V9
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 17:01:23 +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 18682c2d-8ffa-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 19:01:17 +0200 (CEST)
Received: from BYAPR07CA0072.namprd07.prod.outlook.com (2603:10b6:a03:60::49)
 by SJ5PPFABE38415D.namprd12.prod.outlook.com
 (2603:10b6:a0f:fc02::99e) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Fri, 12 Sep
 2025 17:01:13 +0000
Received: from SJ1PEPF00001CE0.namprd05.prod.outlook.com
 (2603:10b6:a03:60:cafe::fc) by BYAPR07CA0072.outlook.office365.com
 (2603:10b6:a03:60::49) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9115.17 via Frontend Transport; Fri,
 12 Sep 2025 17:01:13 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF00001CE0.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.13 via Frontend Transport; Fri, 12 Sep 2025 17:01:12 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Fri, 12 Sep
 2025 10:01:12 -0700
Received: from satlexmb07.amd.com (10.181.42.216) 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, 12 Sep
 2025 12:01:08 -0500
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via
 Frontend Transport; Fri, 12 Sep 2025 10:01:08 -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: 18682c2d-8ffa-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=czQP1mDVyw//DwTw0gsdKPcX/M8VueT06XAsl58hWm/ccwnNczArLR9fIhE+AI/HoZ4hls/q5Rzz2TfGfXR+8NZ6G/mRAhu8HElatXMQORPw7emA5USN7pmeJNsYU1KtkNjI/4ye4nBwFkso/fljeRYo3t/8usuSEsZiWbbEKh8FqZ94N9d2LUwqRtClU6RvL4HXTra4Mnh9KO+I4G+VDysIhDYLSlsVgHVIp2jKOEmfdA6c4poomALbfjqCqvS1sJHlwhglchXvnKeeC0h06VvvyDFCtuwjwTa/YoFmK03ePoctIO9q2KVyrcdVS2o9Skwtb5vo/TKrEhQocxiBow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=27DHt0J20Pg2g97L+tvBsc3Z3ZrT3sGO/+bEzgDSuu0=;
 b=BXCMxPegprTnkbJbnijbQuUQLElrFdI+7vyzjCqgbq4AjDu5cv0H6duG0tGDs9x+F3sg8sJwwpAVHTPw7Kz/cjJ8p7R3QTQuD95LhHF2wT59quT7PJk8QZirc2zPjuTL4DbmVY+9bL6TJ9wcfHhEr7AyKYYxWCnpfR2x5emHrKwqNjrJxzSM4trL2uhUs41Vfz2VPREHGjMDpyAY7AyZTjYoFkcbw0ishHpqkqDtQOhaE6YoNMObxjl2l6gDKuiYM9LydDJv0rW5WspoDAJ+4rQ61utP++6xcohXT3gmzbs0Mp6QuhOPAxp7+J4FySU03/m4xMlflx8Md31zBZQHJg==
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=27DHt0J20Pg2g97L+tvBsc3Z3ZrT3sGO/+bEzgDSuu0=;
 b=OgpIuw9CThUbwvkOmQg3Qjki6FErwFqL1FhOP1V1TTV9yfdjnRJHPZOmNQcRK1jOhyHxZ7ckii8gH13b5a31qMBkpI19BO1S5NnaXCqsAQLsAzOjhfYJ0GLLLD4RIkwVHetXSlSikMMd6Ds2vWNe68jegM83tLOfSYrWDK1bzrY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Ayan Kumar Halder 
To: 
CC: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Michal Orzel
	, Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
Date: Fri, 12 Sep 2025 18:00:55 +0100
Message-ID: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE0:EE_|SJ5PPFABE38415D:EE_
X-MS-Office365-Filtering-Correlation-Id: f37914e5-8547-4824-6da1-08ddf21dfab3
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?jXbOJodezbuQVtmM8LOgO3tveVoqKNwpK5pZJqc5V/rCH8vqCh6++7Feym70?=
 =?us-ascii?Q?lcxMaNW9X1xUaiXGmC5P/5GRCbhH834Cj+HdSeN3vkxuKgs+Xs6lDcm7kGpM?=
 =?us-ascii?Q?8m4wggzGUgX9i355rncAZDiO2aCEiT1ZmYjPZMXKvsr3Cr8auoT9sfg8tDX1?=
 =?us-ascii?Q?gAiJVH9Nbiel68xuw85trIjgB2IgShFT947653p/fniNWRXp7TKIU+sbKieK?=
 =?us-ascii?Q?GGZM6VkQcu2Yc98RRX7AqJYXTw9HewE7iBjj2jfUIoci91iR7efFqQxySQq6?=
 =?us-ascii?Q?64RdPSX/c9ezFg7z3WW3Mc5cbDXTV1hr/Qu/T6IoPJOmDibXY45/osqazeCU?=
 =?us-ascii?Q?xdzkYnkUvEVy+sosoJII5w48ru9ANU/yWCMy8+uv0EtVCvwX2P21V9c/TZbk?=
 =?us-ascii?Q?+ZtrssrJ7L2ADtk/4YZPHJe0RqXPzc1daoUVBCBxCbLgARov1MVhStZ67Opn?=
 =?us-ascii?Q?1ZlYk6aDLgjbgIgqkyBCT0WUcHUWYyFqV/iFOEGWbZZOdlSpS267/8RvnX8b?=
 =?us-ascii?Q?RQBv49r+yiSh+l6rOhAc/9BQdDhabOvz+UI9TgzvR/m7ebmYNogEuLb9jjAH?=
 =?us-ascii?Q?PTJxhrjcZHjhSm+GE/IWmWK5u9Kd+0CFph37mohC/DHaxqSvJ3nQIW2f4S8r?=
 =?us-ascii?Q?kGMIvjXPsTM/l9ZNaJJlsez8+ik3Te6pHFFaXarezJ1D129XPsR0gvzWNSHh?=
 =?us-ascii?Q?Xc6oCKwAa8V3G8AWAwGrUzIn2LVBonL2oIc+K7cK9M1jlwrOoAi0VadJjFT2?=
 =?us-ascii?Q?SHgoSLJJ4xR9ygv8mWC+Yvbfk5u3j5lRNN9OGS8SvQhpyBZR8snFjYvx0fxZ?=
 =?us-ascii?Q?SnkANXXMncs+TTHCj4NtraFNqDvPL53Rk0SwRtvlEG/OpGM78BqQAtQYkTHV?=
 =?us-ascii?Q?ZBKOVzVGqPnUIFWmKy/6ENGCpSP8X77L80njkjjHavDKCfcnEDrbmp8mAbtA?=
 =?us-ascii?Q?yqn6yXODN2oHc+BO6FYw5Jv0BF67Qd9rI2pEAcHMqcMIu60RbswjQK7PVXwb?=
 =?us-ascii?Q?8nN56oYxIFeZHfZ/WsrWEMw1D5yZHD/RUh6G9rm4lJzbM+TEsWRzxHZQtF5a?=
 =?us-ascii?Q?IRrh82teenvYZpd39uFPtCUY6k5Qy7pjXJEufeYmdYpicrb/1oQkhu+jiQZz?=
 =?us-ascii?Q?KgcKiQTRyo6mah5O91t9+ElHKkC3aRcOYByalknCYsouJMsewo+daSOrITND?=
 =?us-ascii?Q?/nqlwx3V/75uDsqbdKLkT6fvyZa+AH2XIiZqATV++2EnTAnW9Vz+z0AUnAHk?=
 =?us-ascii?Q?oZ7e36bXYbNxvXCoXmbCE2up/SN9XRJQ5/6l/4DMf91AoV5HjqVYdeCDKScA?=
 =?us-ascii?Q?oqR6Q6OMNWRxMBdefJvpXDMkxnnIu5K1grxFXDmr5RjTJpAbcjsL0K2U0XRb?=
 =?us-ascii?Q?e0AFg+bnR6Tu/ggd9jTOv4BldVWFs+DarOD/Y+xDG5Q0r7EI8zA8si+OcbiO?=
 =?us-ascii?Q?VqPBYVGCSyxma0KK8My2V1NIFvjCmhpYFi0o8CfGFOr3YbNlg+YT7u98KKLN?=
 =?us-ascii?Q?5tFsY10Y8bmMSi3fIP45WZ7nWyXiz1r/jqRi?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 12 Sep 2025 17:01:12.9171
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f37914e5-8547-4824-6da1-08ddf21dfab3
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CE0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPFABE38415D

Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
Test that Xen is able to generate SGIs.

Signed-off-by: Ayan Kumar Halder 
---
One of the aim of functional safety is to test hw/sw interface. This means that
Xen is able to configure the hardware correctly for the desired functionalities.

Normally this is tested from the VMs. For eg if a VM is able to receive irq, this
implies that Xen has configured the GICv3 interface 'correctly'. However this is
a high level (or integration) test which uses not only the GICv3 interface
between Xen and VM, but the interrupt injection code for Xen to VMs.

We want to have some kind of unit tests to check that Xen is able to receive
various interrupts, set priorities, etc. Here, we have written unit tests for
software generated interrupts (SGIs) as example.

These tests are expected to be triggered as Xen boots (right after Xen has
initialised the GICv3 interface ie gicv3_init(). The aim of this test is to
check whether Xen can trigger SGIs after gicv3_init() is invoked. If so, we can
claim that gicv3_init() was done properly to be able to trigger SGIs. Likewise
we will have tests to check for priorities, SPIs, etc.

A script will parse the logs and claim that Xen is able to trigger SGIs.

 xen/arch/arm/Kconfig  |  8 ++++++++
 xen/arch/arm/gic-v3.c |  7 +++++++
 xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
 3 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 950e4452c1..739f99eaa9 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,14 @@ config GICV3
 	  Driver for the ARM Generic Interrupt Controller v3.
 	  If unsure, use the default setting.
 
+config GICV3_SELFTEST
+    bool "GICv3 driver self test"
+    default n
+    depends on GICV3
+    ---help---
+
+      Self tests to validate GICV3 driver.
+
 config HAS_ITS
         bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
         depends on GICV3 && !NEW_VGIC && !ARM_32
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4e6c98bada..eb0c05231c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
 
     gicv3_hyp_init();
 
+#ifdef CONFIG_GICV3_SELFTEST
+    send_SGI_self(GIC_SGI_EVENT_CHECK);
+    send_SGI_self(GIC_SGI_DUMP_STATE);
+    send_SGI_self(GIC_SGI_CALL_FUNCTION);
+    send_SGI_self(GIC_SGI_MAX);
+#endif
+
 out:
     spin_unlock(&gicv3.lock);
 
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index d922ea67aa..5cb58cdb92 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
      */
     smp_rmb();
 
+#ifdef CONFIG_GICV3_SELFTEST
+    switch (sgi)
+    {
+    case GIC_SGI_EVENT_CHECK:
+        printk("GIC_SGI_EVENT_CHECK received\n");
+        break;
+    case GIC_SGI_DUMP_STATE:
+        printk("GIC_SGI_DUMP_STATE received\n");
+        break;
+    case GIC_SGI_CALL_FUNCTION:
+        printk("GIC_SGI_CALL_FUNCTION received\n");
+        break;
+    case GIC_SGI_MAX:
+        printk("GIC_SGI_MAX received\n");
+        break;
+    default:
+        panic("Unknown SGI triggered\n");
+        break;
+    }
+#else
     switch (sgi)
     {
     case GIC_SGI_EVENT_CHECK:
@@ -361,6 +381,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
         panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
         break;
     }
+#endif
 
     /* Deactivate */
     gic_hw_ops->deactivate_irq(desc);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 18:01:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 18:01:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122422.1466117 (Exim 4.92)
	(envelope-from )
	id 1ux85L-0003wi-6c; Fri, 12 Sep 2025 18:01:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122422.1466117; Fri, 12 Sep 2025 18:01: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 1ux85L-0003wb-3v; Fri, 12 Sep 2025 18:01:23 +0000
Received: by outflank-mailman (input) for mailman id 1122422;
 Fri, 12 Sep 2025 18: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 1ux85J-0003wV-RX
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 18:01:21 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7a5250d1-9002-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 20:01:16 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-45cb659e858so16415775e9.2
 for ; Fri, 12 Sep 2025 11:01:16 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e037d62besm68377385e9.21.2025.09.12.11.01.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 11:01: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: 7a5250d1-9002-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757700076; x=1758304876; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=O30KPNJ2mr6ATeP8HncSxVK987KLpW1yFdoXCnqU3kk=;
        b=uowRl17r+/RkeRJMqMxpa87PmD2pYGN+ioD1zLXA0/B/bU6ukwGdSfZvdPS2TAvWVe
         LIZj0Vm3nDUtyuQjT5DEfDuxlLWi5LAvDRQbvxtcqT4dHTgS66DyaDI1Z2RMzamrUlEl
         g141am3WfHXynrMLUyq4yY8K2YGqf0J0WwT3w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757700076; x=1758304876;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=O30KPNJ2mr6ATeP8HncSxVK987KLpW1yFdoXCnqU3kk=;
        b=o33lgUS8jhPVvHGPFIarMsBo/uRB+cQTKGhoMA5ypY6ZIZ3oQZwTS4kE0gWG2N2+N5
         g0QZcBCsSFR63t25gFbNsVHizGKJcuNb92Nbtehz9h829FhDv7Vj/cZDYTFI1FKlNOft
         TfNxbYeLLconvb2N/xti7l96+uWBvzNGb2HLW8yoRGaxAyL4W13nXMm2uLY0OumePJ1l
         Ti17cN9anPw2AyrocfMPeFIUwX0ji8ChkO7nMIBTG5an1JAhX1e5Q5k6juHnApRefWJX
         8PDzLYm4C2Qhm7uRlWv7b1jYOB0Y282q2g6cWwXT/uxltv9h2zyX93RffGzRrpUqE90K
         uJ8g==
X-Forwarded-Encrypted: i=1; AJvYcCUDRs0VxkBcwXAAWN/8wKTTKx0Cf2L+cFzd8zds75Q40cFifB+MACHMQyupCnDmU78moDYpwh76zFY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxIpZWOSqAoxevEFdGrypNi2HxWCYdMs93KVkn4F5IypBCjOsdU
	gTY6bnJECVjCwMn6JTbYpFAG14WPb4Gi2vOXrehJowO8EwcVVcXnpQGoFfg5/h3hBxU=
X-Gm-Gg: ASbGncsN1ZAh1LUvYiI5Y92TEQH7ZStS2Cz6l1BZFwRWPFgHX7eD2Ghgo0YzMTzTkOa
	YUioeAlCzNPC1OHlIfIHoNliyQ3RKfjNaFzzjIZgl9x40PoqRu3GE6m+ZmcNrR7+cqTRTizMKdp
	oEjOYubyGVsto44B3OQ6XtwWmpjWdGsOtd+DgzCD0Vnxr4ic+QqR+ndt7AmcqmLs4CKAl4nf5iY
	/seLVrJMQHHSzaa01mduuVMoKmNxMzcSVvJbCyBaMyWwprLBLjW7eO1O7CPd8fSbL3YX6G9q62h
	DzzTkC2r9k2RYzb7VFJEWeZfMsw5egXVsgCrcyUAV4nJiQO4uJbU5NbiKyvhTEEMC5KY4VdEx2S
	KaKlj4dceWJwK9dBTATivqqsvr6gqA8M9gRdaUYLMHBMWeg4zzaT0A/oR7l10AJ5mNHJ6QQl0P8
	Qxssg=
X-Google-Smtp-Source: AGHT+IEnSbFCJ2v5ZT+SYjgUfVstjDvCBOF+c+TyeaZ8fJma7kYZhLXqQ9sd2uJMVfqsAohcHgi5/w==
X-Received: by 2002:a05:600c:8a17:20b0:45b:8504:3002 with SMTP id 5b1f17b1804b1-45f211d50a9mr38530835e9.10.1757700075995;
        Fri, 12 Sep 2025 11:01:15 -0700 (PDT)
Message-ID: <152377b3-075f-46f1-a17d-eb2aa82c1e82@citrix.com>
Date: Fri, 12 Sep 2025 19:01:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] tools/libs: Use superpages where possible on
 migrate/resume
To: Frediano Ziglio ,
 xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Juergen Gross , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Oleksii Kurochko 
References: <20250912095744.99181-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: <20250912095744.99181-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/09/2025 10:57 am, Frediano Ziglio wrote:
> Try to allocate larger order pages.
> With some test memory program stressing TLB (many small random
> memory accesses) you can get 15% performance improves.
> On the first memory iteration the sender is currently sending
> memory in 4mb aligned chunks which allows the receiver to
> allocate most pages as 2mb superpages instead of single 4kb pages.
> This works even for HVM where the first 2mb contains some holes.
> This change does not handle 1gb superpages as this will require
> change in the protocol to preallocate space.
>
> Signed-off-by: Frediano Ziglio 
> Release-Acked-by: Oleksii Kurochko 

Reviewed-by: Andrew Cooper 

Thanks, this is far easier to follow.  A couple of minor things.

> ---
> Changes since v1:
> - updated commit message and subject;
> - change the implementation detecting possible 2mb pages inside
>   the packet sent allowing more 2mb superpages.
>
> Changes since v2:
> - change implementation simplifying detecting and allocations
>   of 2mb pages.
> ---
>  tools/libs/guest/xg_sr_restore.c | 45 +++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c
> index 06231ca826..ea5a137612 100644
> --- a/tools/libs/guest/xg_sr_restore.c
> +++ b/tools/libs/guest/xg_sr_restore.c
> @@ -129,6 +129,30 @@ static int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
>      return 0;
>  }
>  
> +#if defined(__i386__) || defined(__x86_64__)
> +/* Order of the smallest superpage */
> +#define SMALL_SUPERPAGE_ORDER 9
> +#else
> +#error Define SMALL_SUPERPAGE_ORDER for this platform
> +#endif
> +
> +static bool populate_small_superpage(struct xc_sr_context *ctx, xen_pfn_t pfn)

I know the terminology is terrible (this work was what prompted some of
my clean-up attempts in Xen).

I think we want to s/pfn/gfn/ all across this function.

> +{
> +    xen_pfn_t mfn = pfn;
> +
> +    if ( xc_domain_populate_physmap_exact(
> +         ctx->xch, ctx->domid, 1, SMALL_SUPERPAGE_ORDER, 0, &mfn) )

This needs a comment.

/* XENMEM_populate_physmap has no coherent error semantics.  Assume a
failure here is ENOMEM, and fall back to allocating small pages. */

(Yes, the physmap hypercalls are insane.  The only error feedback is "I
completed this many before something went wrong", and libxenctrl chooses
EBUSY for want of anything better.)

> +        return false;
> +
> +    if ( mfn == INVALID_MFN )
> +        return false;
> +
> +    for ( size_t i = 0; i < (1 << SMALL_SUPERPAGE_ORDER); ++i )
> +        ctx->restore.ops.set_gfn(ctx, pfn + i, mfn + i);
> +
> +    return true;
> +}
> +
>  /*
>   * Given a set of pfns, obtain memory from Xen to fill the physmap for the
>   * unpopulated subset.  If types is NULL, no page type checking is performed
> @@ -142,6 +166,9 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned int count,
>          *pfns = malloc(count * sizeof(*pfns));
>      unsigned int i, nr_pfns = 0;
>      int rc = -1;
> +    xen_pfn_t prev = 0;
> +    unsigned num_contiguous = 0;
> +    xen_pfn_t mask = ~((~(xen_pfn_t)0) << SMALL_SUPERPAGE_ORDER);

(1ULL << SMALL_SUPERPAGE_ORDER) - 1; is the more normal way of writing this.

>  
>      if ( !mfns || !pfns )
>      {
> @@ -152,14 +179,26 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned int count,
>  
>      for ( i = 0; i < count; ++i )
>      {
> +        xen_pfn_t pfn = original_pfns[i];
> +
>          if ( (!types || page_type_to_populate(types[i])) &&
> -             !pfn_is_populated(ctx, original_pfns[i]) )
> +             !pfn_is_populated(ctx, pfn) )
>          {
> -            rc = pfn_set_populated(ctx, original_pfns[i]);
> +            rc = pfn_set_populated(ctx, pfn);
>              if ( rc )
>                  goto err;
> -            pfns[nr_pfns] = mfns[nr_pfns] = original_pfns[i];
> +            pfns[nr_pfns] = mfns[nr_pfns] = pfn;
>              ++nr_pfns;

/* For x86 HVM guests in the first pass, PAGE_DATA records contain
metadata about 4M aligned chunks of GFN space.  Reconstruct 2M
superpages where possible. */

I'm happy to fix these all on commit, if you're happy?

~Andrew

> +            if ( pfn != prev + 1 )
> +                num_contiguous = 0;
> +            num_contiguous++;
> +            prev = pfn;
> +            if ( num_contiguous > mask && (pfn & mask) == mask &&
> +                 populate_small_superpage(ctx, pfn - mask) )
> +            {
> +                nr_pfns -= mask + 1;
> +                num_contiguous = 0;
> +            }
>          }
>      }
>  



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 20:30:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 20:30:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122498.1466127 (Exim 4.92)
	(envelope-from )
	id 1uxAPg-0004bx-45; Fri, 12 Sep 2025 20:30:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122498.1466127; Fri, 12 Sep 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 1uxAPg-0004bq-1E; Fri, 12 Sep 2025 20:30:32 +0000
Received: by outflank-mailman (input) for mailman id 1122498;
 Fri, 12 Sep 2025 20:30:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxAPe-0004bk-PV
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 20:30:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxAPe-006cjo-09;
 Fri, 12 Sep 2025 20:30:30 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uxAPd-00684b-39;
 Fri, 12 Sep 2025 20:30:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=ODR2NxxYnmygMLkLe8MISIe0BR4RrYikvOaMfaMVFOE=; b=3w2yZmlQhSe8cnykk3CTqsWfpI
	C7h5eTxkFGoUI2bNSg/soJG/dGemwf9xPHaAmMb710mIpNniwbrtMrIH7iMkmpu9Ldgt8kdWrnbiP
	JJFWs3Hw+TZ/01U9Mqyc/2zJFWFjV24f5O/AYzeY0jFgVF9J7Ag69aemeIL1SMlV2X0A=;
From: dmukhin@xen.org
Date: Fri, 12 Sep 2025 13:30:28 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Shawn Anastasio ,
	Oleksii Kurochko ,
	Doug Goldstein ,
	Victor Lira 
Subject: Re: [PATCH v4 6/8] CI: Use pipefail in scripts/build
Message-ID: 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-7-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250912144427.1905141-7-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 03:44:25PM +0100, Andrew Cooper wrote:
> Marek noticed that some builds were failing with:
> 
>   + cd dist/install
>   + find
>   + cpio -R 0:0 -o -H newc
>   ./automation/scripts/build: line 111: cpio: command not found
>   + gzip
> 
> but succeeding overall, and producing a zero length xen-tools.cpio.gz as an
> artefact.
> 
> In fact, it's all of:
> 
>   archlinux:current
>   debian:12-x86_32
>   fedora:41
>   opensuse:tumbleweed
>   ubuntu (all versions)
> 
> Add cpio into all of these containers, including opensuse leap for good
> measure, and use pipefail in the build script.
> 
> Fixes: 4611ae6fb8f9 ("CI: save toolstack artifact as cpio.gz")
> Reported-by: Marek Marczykowski-Grecki 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 20:31:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 20:31:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122509.1466138 (Exim 4.92)
	(envelope-from )
	id 1uxAQb-000555-By; Fri, 12 Sep 2025 20:31:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122509.1466138; Fri, 12 Sep 2025 20: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 1uxAQb-00054y-9D; Fri, 12 Sep 2025 20:31:29 +0000
Received: by outflank-mailman (input) for mailman id 1122509;
 Fri, 12 Sep 2025 20:31:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxAQZ-00054k-Km
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 20:31:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxAQZ-006ckr-0n;
 Fri, 12 Sep 2025 20:31:27 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uxAQZ-006866-0x;
 Fri, 12 Sep 2025 20: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=Z0TPAK7wGgWTPXFEC4jB7daTrq/ACCmRYZv+/448238=; b=
	TWptsiSVv+MyuL9/u24O0BgSRBfhNGYBtrlLQ4Z/AWGd0zdMATNNaUq8IVzXRiy/uqFahG+N7ZJDY
	2ngwnp9gZX/sWK3+HU430/PL1aYLHN57MYdt12U2ekuHOq98E2uOXV0riVZS1FLENRHyY8GdM76j6
	CxjKyn90xRb91zsTw=;
From: dmukhin@xen.org
Date: Fri, 12 Sep 2025 13:31:26 -0700
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v4 5/8] x86/emul: Make condition coverage warning
 non-fatal
Message-ID: 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-6-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250912144427.1905141-6-andrew.cooper3@citrix.com>

On Fri, Sep 12, 2025 at 03:44:24PM +0100, Andrew Cooper wrote:
> Randconfig with GCC-14 (Debian Trixie) found:
> 
>   In file included from arch/x86/x86_emulate/x86_emulate.c:11,
>                    from arch/x86/x86_emulate.c:27:
>   arch/x86/x86_emulate/x86_emulate.c: In function 'x86_emulate':
>   arch/x86/x86_emulate/private.h:482:8: error: Too many conditions (found 826); giving up coverage [-Werror=coverage-too-many-conditions]
>     482 | ({  if ( (p) ) {                                                          \
>         |        ^
>   arch/x86/x86_emulate/x86_emulate.c:1283:5: note: in expansion of macro 'generate_exception_if'
>    1283 |     generate_exception_if((mode_vif() &&
>         |     ^~~~~~~~~~~~~~~~~~~~~
> 
> which is a consequence of having a new enough compiler to allow
> CONFIG_CONDITIONAL_COVERAGE in to the mix.
> 
> In the short term make warning non-fatal.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin  


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 20:49:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 20:49:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122532.1466148 (Exim 4.92)
	(envelope-from )
	id 1uxAhh-0006xj-O3; Fri, 12 Sep 2025 20:49:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122532.1466148; Fri, 12 Sep 2025 20:49: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 1uxAhh-0006xc-KR; Fri, 12 Sep 2025 20:49:09 +0000
Received: by outflank-mailman (input) for mailman id 1122532;
 Fri, 12 Sep 2025 20: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 1uxAhg-0006xW-Ox
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 20:49:08 +0000
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com
 [2001:4860:4864:20::2e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea2e8856-9019-11f0-9809-7dc792cee155;
 Fri, 12 Sep 2025 22:49:03 +0200 (CEST)
Received: by mail-oa1-x2e.google.com with SMTP id
 586e51a60fabf-31d6dcb5894so1511679fac.0
 for ; Fri, 12 Sep 2025 13: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: ea2e8856-9019-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1757710142; x=1758314942; 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=80vY5q580AGu5oGDR0XEBwrWoQUsrpekyF9nEI2MzhU=;
        b=IWBaym0EGLi6so5+rQCgyYhzaG0qCYePam66Z1eGZzCwUZVpQlrBZeNtwC+EU7c+Ph
         443y0+Je7/isrByYDnFZa4BBU4ouP5B/3RsncNXh7vatIwEudNMoLQ/z6oi2w/sWVTJp
         +NgbBquySDRMaNiPs5GIDc4cd2JsGxLO6A3ng=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757710142; x=1758314942;
        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=80vY5q580AGu5oGDR0XEBwrWoQUsrpekyF9nEI2MzhU=;
        b=hzewf00e/jq/Bt+f99lLeLyM9/c9YaWxMcYCyhmliWVevp/KwzUzZUY0zBfSmOGQEI
         Gns+sGrPjmlEtTU6efYoZc/mm90+SNwgzAlD4QDNAhGbST8k/Vlb0xC9qd2bYoB0+REh
         WAt89XELDkhlxyoEOj3qkPax35q+2Ez5oTTFebPLnfLTOqH7CwOPzOkrYZ1EJx8FLzET
         1Vz4fR7/QPWEDLoMt8UU3Q3a5pHUaclpXPoqZzZNIEpiMy2N3TL/sR48Xf4SzKKQ0ZlU
         foZlxSFiPYeWcV6JxziQr/89o0cH8XE4mZXJXS0Rvv2fjckU3LNBL7qprmcbzyc6X7XX
         TjAg==
X-Gm-Message-State: AOJu0YzEROpL0+CEKPB0Wxg+ngAE4w3IiiISbIfsLXcEe6MMiIK79kzz
	rf99w7XReBTGgEVoRSB86VH18ZDMlvC4KzSgoN9f0PnGSfhxKEEkRD+Xqe0Zgy8SmssMZYxFGyv
	8ZO+8xEy5rrYxdrgulN2yCu9N4zqWJx9ETrWdcIx9MQ==
X-Gm-Gg: ASbGncv16hufu0rxunQyRJfVL4STfpgRSwO40TfiQwlO15BwCH2+Fnr+6tmbdrsvX2Q
	F+l4X71k5B4SqYzXjYORU9/l9AaLcYde2FWwZCWgzlTU2rN9a+4vmWNLY7OXmN0IZurn7sHwnGM
	xaHxj6u44NFBGMS9Ncg17WYukl2b4jcu5e9pPx2wNguU4pLEFzoOPO9iJAivBq83TQbU2rF/ML6
	zQVYRU=
X-Google-Smtp-Source: AGHT+IFfWaAq2iJp3XBFzZ5NfCTXZtmbtVwB56IqCJcdt98i3fqoUavP1vQPh+noLTKJU2+QsFzgavZ5t+wVSsw+kVA=
X-Received: by 2002:a05:6870:b28f:b0:2ea:87d7:5a35 with SMTP id
 586e51a60fabf-32e58970d28mr2200477fac.36.1757710141815; Fri, 12 Sep 2025
 13:49:01 -0700 (PDT)
MIME-Version: 1.0
References: <20250912095744.99181-1-frediano.ziglio@cloud.com> <152377b3-075f-46f1-a17d-eb2aa82c1e82@citrix.com>
In-Reply-To: <152377b3-075f-46f1-a17d-eb2aa82c1e82@citrix.com>
From: Frediano Ziglio 
Date: Fri, 12 Sep 2025 21:48:49 +0100
X-Gm-Features: Ac12FXxUx923MAvSwEJZULl3skfIRtIxM35aEQC8TOfz_yemD_mJ1v05d3O3OAI
Message-ID: 
Subject: Re: [PATCH v3] tools/libs: Use superpages where possible on migrate/resume
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD , 
	Juergen Gross , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Oleksii Kurochko 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 12, 2025 at 7:01=E2=80=AFPM Andrew Cooper  wrote:
>
> On 12/09/2025 10:57 am, Frediano Ziglio wrote:
> > Try to allocate larger order pages.
> > With some test memory program stressing TLB (many small random
> > memory accesses) you can get 15% performance improves.

Checker is suggesting "improvements" instead of "improves" here. Can
you also update this ?

> > On the first memory iteration the sender is currently sending
> > memory in 4mb aligned chunks which allows the receiver to
> > allocate most pages as 2mb superpages instead of single 4kb pages.
> > This works even for HVM where the first 2mb contains some holes.
> > This change does not handle 1gb superpages as this will require
> > change in the protocol to preallocate space.
> >
> > Signed-off-by: Frediano Ziglio 
> > Release-Acked-by: Oleksii Kurochko 
>
> Reviewed-by: Andrew Cooper 
>
> Thanks, this is far easier to follow.  A couple of minor things.
>
> > ---
> > Changes since v1:
> > - updated commit message and subject;
> > - change the implementation detecting possible 2mb pages inside
> >   the packet sent allowing more 2mb superpages.
> >
> > Changes since v2:
> > - change implementation simplifying detecting and allocations
> >   of 2mb pages.
> > ---
> >  tools/libs/guest/xg_sr_restore.c | 45 +++++++++++++++++++++++++++++---
> >  1 file changed, 42 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_=
restore.c
> > index 06231ca826..ea5a137612 100644
> > --- a/tools/libs/guest/xg_sr_restore.c
> > +++ b/tools/libs/guest/xg_sr_restore.c
> > @@ -129,6 +129,30 @@ static int pfn_set_populated(struct xc_sr_context =
*ctx, xen_pfn_t pfn)
> >      return 0;
> >  }
> >
> > +#if defined(__i386__) || defined(__x86_64__)
> > +/* Order of the smallest superpage */
> > +#define SMALL_SUPERPAGE_ORDER 9
> > +#else
> > +#error Define SMALL_SUPERPAGE_ORDER for this platform
> > +#endif
> > +
> > +static bool populate_small_superpage(struct xc_sr_context *ctx, xen_pf=
n_t pfn)
>
> I know the terminology is terrible (this work was what prompted some of
> my clean-up attempts in Xen).
>
> I think we want to s/pfn/gfn/ all across this function.
>
> > +{
> > +    xen_pfn_t mfn =3D pfn;
> > +
> > +    if ( xc_domain_populate_physmap_exact(
> > +         ctx->xch, ctx->domid, 1, SMALL_SUPERPAGE_ORDER, 0, &mfn) )
>
> This needs a comment.
>
> /* XENMEM_populate_physmap has no coherent error semantics.  Assume a
> failure here is ENOMEM, and fall back to allocating small pages. */
>
> (Yes, the physmap hypercalls are insane.  The only error feedback is "I
> completed this many before something went wrong", and libxenctrl chooses
> EBUSY for want of anything better.)
>
> > +        return false;
> > +
> > +    if ( mfn =3D=3D INVALID_MFN )
> > +        return false;
> > +
> > +    for ( size_t i =3D 0; i < (1 << SMALL_SUPERPAGE_ORDER); ++i )
> > +        ctx->restore.ops.set_gfn(ctx, pfn + i, mfn + i);
> > +
> > +    return true;
> > +}
> > +
> >  /*
> >   * Given a set of pfns, obtain memory from Xen to fill the physmap for=
 the
> >   * unpopulated subset.  If types is NULL, no page type checking is per=
formed
> > @@ -142,6 +166,9 @@ int populate_pfns(struct xc_sr_context *ctx, unsign=
ed int count,
> >          *pfns =3D malloc(count * sizeof(*pfns));
> >      unsigned int i, nr_pfns =3D 0;
> >      int rc =3D -1;
> > +    xen_pfn_t prev =3D 0;
> > +    unsigned num_contiguous =3D 0;
> > +    xen_pfn_t mask =3D ~((~(xen_pfn_t)0) << SMALL_SUPERPAGE_ORDER);
>
> (1ULL << SMALL_SUPERPAGE_ORDER) - 1; is the more normal way of writing th=
is.
>
> >
> >      if ( !mfns || !pfns )
> >      {
> > @@ -152,14 +179,26 @@ int populate_pfns(struct xc_sr_context *ctx, unsi=
gned int count,
> >
> >      for ( i =3D 0; i < count; ++i )
> >      {
> > +        xen_pfn_t pfn =3D original_pfns[i];
> > +
> >          if ( (!types || page_type_to_populate(types[i])) &&
> > -             !pfn_is_populated(ctx, original_pfns[i]) )
> > +             !pfn_is_populated(ctx, pfn) )
> >          {
> > -            rc =3D pfn_set_populated(ctx, original_pfns[i]);
> > +            rc =3D pfn_set_populated(ctx, pfn);
> >              if ( rc )
> >                  goto err;
> > -            pfns[nr_pfns] =3D mfns[nr_pfns] =3D original_pfns[i];
> > +            pfns[nr_pfns] =3D mfns[nr_pfns] =3D pfn;
> >              ++nr_pfns;
>
> /* For x86 HVM guests in the first pass, PAGE_DATA records contain
> metadata about 4M aligned chunks of GFN space.  Reconstruct 2M
> superpages where possible. */
>
> I'm happy to fix these all on commit, if you're happy?
>

Yes, fine with all changes.
> ~Andrew
>

Frediano


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 21:09:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 21:09:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122546.1466157 (Exim 4.92)
	(envelope-from )
	id 1uxB1l-0001MQ-9t; Fri, 12 Sep 2025 21:09:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122546.1466157; Fri, 12 Sep 2025 21:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxB1l-0001MJ-7P; Fri, 12 Sep 2025 21:09:53 +0000
Received: by outflank-mailman (input) for mailman id 1122546;
 Fri, 12 Sep 2025 21:09:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxB1j-0001MD-Ta
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 21:09:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxB1j-006dXW-16;
 Fri, 12 Sep 2025 21:09:51 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxB1j-006A1c-16;
 Fri, 12 Sep 2025 21:09:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=zlcujAk6Lo59RFqYuGaHKJuqf6p6m8I7RCpvCucJ+fE=; b=L5Xe+wirpdHwBPI2XkTOQkeirZ
	pbbSgzsJqHSE3h4nNNn//+WhCEOUKMnRAnlE6yYxCgrjj8K26PYrECoeTRyU/bv/1mdF7doV7ZT7v
	lfRegKGX/j0dkaPMpMto309M+JnXDSbmpU3lTUp6zSblACcxKp2YA9xNKdu0yS2jdjY4=;
Message-ID: <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
Date: Fri, 12 Sep 2025 22:09:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
Content-Language: en-GB
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: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-jgross@suse.com>
From: Julien Grall 
In-Reply-To: <20250730122305.4050-9-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,

Sorry for the late answer.

On 30/07/2025 13:23, Juergen Gross wrote:
> Live update is now working with the PVH variant of xenstore-stubdom.
 > > Signed-off-by: Juergen Gross 
> ---
> V2:
> - new patch
> ---
>   SUPPORT.md | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 6a82a92189..eb44ee85fd 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -280,7 +280,7 @@ or itself will not be regarded a security issue.
>   ### C xenstore stubdom PVH
>   
>       Status: Supported
> -    Status, Liveupdate: Not implemented
> +    Status, Liveupdate: Supported

I went through the changes in Xenstored for the stubdom and I have one 
question regarding [1]. Does this mean the event channel will be closed 
during Live-Update? Asking because I vaguely remember we need to keep 
them open to avoid losing events. I am wondering how this would work in 
stubdom?

Cheers,

[1] https://lore.kernel.org/all/20250730122305.4050-7-jgross@suse.com/

>   
>   ### OCaml xenstored daemon
>   

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 21:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 21:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122559.1466167 (Exim 4.92)
	(envelope-from )
	id 1uxB2m-0002nB-JI; Fri, 12 Sep 2025 21:10:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122559.1466167; Fri, 12 Sep 2025 21:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxB2m-0002n4-GZ; Fri, 12 Sep 2025 21:10:56 +0000
Received: by outflank-mailman (input) for mailman id 1122559;
 Fri, 12 Sep 2025 21:10:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxB2l-0002mu-5H
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 21:10:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxB2k-006dYX-2i;
 Fri, 12 Sep 2025 21:10:54 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxB2k-006A3A-36;
 Fri, 12 Sep 2025 21:10: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:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=XnGJt0RrQO01mz7muJZ9enC8u3lAYSRU/sBaI6jZliQ=; b=X7vMfsY+XO52HqC2vBliUFXvZY
	V7weutGAiDYnN6rPW4asRMfEY16YnMNCaOHQxNmxH5A5De9IQDlYydTngHHbv1fM5cx3xKltmE5FE
	9M6lkG7AkVBbUNK5W/KkJ+t11GW/5GVU5cO5NOae/1Cf44zJ1s14YqO4LwZjRcGIkGws=;
Message-ID: <1bd3e5a0-1b97-414c-b78d-1d77c70376b6@xen.org>
Date: Fri, 12 Sep 2025 22:10:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
Content-Language: en-GB
From: Julien Grall 
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: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-jgross@suse.com>
 <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
In-Reply-To: <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 12/09/2025 22:09, Julien Grall wrote:
> Hi Juergen,
> 
> Sorry for the late answer.
> 
> On 30/07/2025 13:23, Juergen Gross wrote:
>> Live update is now working with the PVH variant of xenstore-stubdom.
>  > > Signed-off-by: Juergen Gross 
>> ---
>> V2:
>> - new patch
>> ---
>>   SUPPORT.md | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index 6a82a92189..eb44ee85fd 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -280,7 +280,7 @@ or itself will not be regarded a security issue.
>>   ### C xenstore stubdom PVH
>>       Status: Supported
>> -    Status, Liveupdate: Not implemented
>> +    Status, Liveupdate: Supported
> 
> I went through the changes in Xenstored for the stubdom and I have one 
> question regarding [1]. Does this mean the event channel will be closed 
> during Live-Update? Asking because I vaguely remember we need to keep 
> them open to avoid losing events. I am wondering how this would work in 
> stubdom?

I forgot to mention, this is the only thing blocking my ack for this patch.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 21:23:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 21:23:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122582.1466177 (Exim 4.92)
	(envelope-from )
	id 1uxBF0-0004d6-Kt; Fri, 12 Sep 2025 21:23:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122582.1466177; Fri, 12 Sep 2025 21:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxBF0-0004cz-IS; Fri, 12 Sep 2025 21:23:34 +0000
Received: by outflank-mailman (input) for mailman id 1122582;
 Fri, 12 Sep 2025 21:23:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxBEy-0004cs-SL
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 21:23:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxBEy-006dmu-1w;
 Fri, 12 Sep 2025 21:23:32 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxBEy-006Ajk-24;
 Fri, 12 Sep 2025 21:23:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=QSNFsOFIXDEOU/eQ5zPH08Xp1QN49RW9J/tguUW+J6c=; b=bhs68KVM8i8ZHWnY1ptVk2o7KX
	qz8sDZjMRBmL1TojxUpRoc2es7mDrXlk4gEgPDgk2smY6fFXqBRWsKSo9AqV2iNfl4MfHOrAzvVag
	bnPeebF7Wy6PJCGJMICExmaFTpfyJ+KUwiiIK1XFg3b2vBW1oz0WaadrK42KXQPi522Q=;
Message-ID: <53d760ad-c58d-4d3f-bd66-598b4a95a8ff@xen.org>
Date: Fri, 12 Sep 2025 22:23:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] releases: use newer compression methods for tarballs
Content-Language: en-GB
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 11/09/2025 09:14, Jan Beulich wrote:
> Other projects have long switched to xz and/or lzip.
> 
> Tidy things some as well: With the removal of qemu from the tarball,
> intermediately extracting the tarball again has become wasteful. Drop
> that. Invoke compressors using asynchronous lists, to reduce overall
> latency. Drop the -v option from the (previously implicit) gzip
> invocation.
> 
> Signed-off-by: Jan Beulich 

I have tested manually the steps and the correct tarballs have been 
produced. I will update my scripts to copy & sign all the tarballs once 
this is merged.

Acked-by: Julien Grall 
Tested-by: Julien Grall 

Is this intended for Xen 4.21?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 21:37:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 21:37:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122599.1466188 (Exim 4.92)
	(envelope-from )
	id 1uxBRz-0006UQ-Pq; Fri, 12 Sep 2025 21:36:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122599.1466188; Fri, 12 Sep 2025 21: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 1uxBRz-0006UJ-MJ; Fri, 12 Sep 2025 21:36:59 +0000
Received: by outflank-mailman (input) for mailman id 1122599;
 Fri, 12 Sep 2025 21:36:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxBRx-0006UC-Ol
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 21:36:57 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxBRx-006dzk-1B;
 Fri, 12 Sep 2025 21:36:57 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxBRx-006BGT-1Q;
 Fri, 12 Sep 2025 21:36: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" 
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=BIdtF20OI98y+cEOdWKs7eJUp00nycsNeL9Fr5TvTIM=; b=XvFSi3WyEKE9uiUFB2yzrNzFMs
	1nT+C9tduYwPhMtQdg1Up2UxNbmdTBQoq1Ft9Rd7C6pGlgPc/WmiWv14gcYZsvc0vehB+CtyuU/CO
	qYuVxGrT0VpsWVbD8uMk8p+NDASOcY4Zb6m/WjcW7U5uLv64tuyyh0qMVh7X9uCQmeT4=;
Message-ID: <705d4436-2263-462b-a582-5f0092821959@xen.org>
Date: Fri, 12 Sep 2025 22:36:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] xen/arm: restrict cpu_up_send_sgi() to arm32
Content-Language: en-GB
To: Grygorii Strashko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250911081213.1323594-1-grygorii_strashko@epam.com>
From: Julien Grall 
In-Reply-To: <20250911081213.1323594-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Grygorii,

On 11/09/2025 09:12, Grygorii Strashko wrote:
> From: Grygorii Strashko 
> 
> Restrict cpu_up_send_sgi() function to arm32 code as it's used by arm32
> platforms only and unreachable on arm64 (Misra rule 2.1).
> 
> Signed-off-by: Grygorii Strashko 
 > ---> Logically cpu_up_send_sgi() should be moved in arm32, but source is
> "GPL-2.0-or-later" while possible destination is "GPL-2.0-only", so put it
> under ifdef for now.

:(. I don't know if we will ever solve this license mess... Looking at 
the list of platform using cpu_up_send_sgi(), all the platforms are 10+ 
years old and to be honest except maybe the rcar2 development platforms. 
I doubt there are anyone using them.

So I would be tempted to get rid of them and mandate PSCI when booting 
on Xen.

Bertrand, Michal, Stefano any thoughts?

Meanwhile for this patch:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 21:38:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 21:38:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122615.1466198 (Exim 4.92)
	(envelope-from )
	id 1uxBTs-00075j-7n; Fri, 12 Sep 2025 21:38:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122615.1466198; Fri, 12 Sep 2025 21:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxBTs-00075c-4t; Fri, 12 Sep 2025 21:38:56 +0000
Received: by outflank-mailman (input) for mailman id 1122615;
 Fri, 12 Sep 2025 21:38:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxBTr-00075W-AM
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 21:38:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxBTq-006e3O-2N;
 Fri, 12 Sep 2025 21:38:54 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxBTq-006BM1-2g;
 Fri, 12 Sep 2025 21:38: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=SFLYSUSsN6iOWQYYhy8K6YJtlIBFaDouIua2Q9yP8gk=; b=VAR4R9Mq9Wv5y7Yrbt5umYNItn
	ljwz4yC9AL15eomhPW3bLOErL2G+p9jUkG7+aHyKaC4z7qRjbbsiXkn8kSBFWdU7b54mxLq4keVV8
	wAwZbZE8/n8v95OMougqwGIUNVzSqRoEglk9bkDLoRBPh+uHo/LRhUeWvFVjrjyK7jTU=;
Message-ID: <1715e68b-fef3-4846-8db0-5cbd49878f27@xen.org>
Date: Fri, 12 Sep 2025 22:38:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
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 ,
 Oleksii 
References: 
 <3e237c5256054a88b1c099d85d8bd1a602bba230.1756995595.git.oleksii_moisieiev@epam.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

(+ Release manager)

On 10/09/2025 15:49, Oleksii Moisieiev wrote:
> Hi Julien,
> 
> Thank you for your observations. You're absolutely right about this.
> 
> Currently, the sci_relinquish_resources call doesn't perform any operations
> because the single-agent doesn't implement a callback.
> 
> I'll move the sci implementation to be positioned above the tee
> implementation
> and prepare a patch for this change.

Thanks! I think this change should go in Xen 4.21. Please tag it with 
[for-4.21] or similar.

CCing Oleksii Kurochko to keep track.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:01:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:01:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122664.1466207 (Exim 4.92)
	(envelope-from )
	id 1uxBpw-0002gh-W1; Fri, 12 Sep 2025 22:01:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122664.1466207; Fri, 12 Sep 2025 22: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 1uxBpw-0002ga-TH; Fri, 12 Sep 2025 22:01:44 +0000
Received: by outflank-mailman (input) for mailman id 1122664;
 Fri, 12 Sep 2025 22:01:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxBpw-0002gU-2x
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:01:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxBpv-006ejR-2T;
 Fri, 12 Sep 2025 22:01:43 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxBpv-006Cfh-2h;
 Fri, 12 Sep 2025 22:01:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=wpd03YPoBlgAjURP54w1VIsouT66uZ/1Dd48RQIn0l0=; b=k3m0P1cGtT4kXo/DzlXaUq4cMc
	AiUqj0l3dBS+SgfMD0S02ZOGzaLIb0trFmoOLlclLaE61Edpay+tGPO5kr+937tFbzfzvRrHWhAvx
	JUejEz70gamVWSex2D9ysoz7WRZlgV+PVN4u386cOA3A+uMrMovZekHxQaOONauJzj0Y=;
Message-ID: <0d0f4689-97e2-408f-91e4-dd59f47bdb95@xen.org>
Date: Fri, 12 Sep 2025 23:01:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in
 setup_irq()
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 03/09/2025 03:55, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> Use GIC_PRI_IPI priority for SGI interrupts instead of the generic
> GIC_PRI_IRQ priority in setup_irq().
> 
> This change ensures that SGIs get the correct priority level when
> being set up for Xen's use, maintaining proper interrupt precedence
> in the system.
> 
> The priority assignment now follows ARM GIC best practices:
> - SGIs (0-15): GIC_PRI_IPI (higher priority)
> - PPIs/SPIs (16+): GIC_PRI_IRQ (standard priority)

Please provide a reference to the spec. But I don't follow why we should 
follow exactly what the spec suggest. This is up to us to decide what we 
want. Otherwise what's the point of having more than two priorities?

> 
> Signed-off-by: Mykola Kvach 
> ---
>   xen/arch/arm/irq.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 02ca82c089..17c7ac92b5 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -397,7 +397,13 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
AFAIK, we are not using setup_irq() to handle SGIs because they are all 
static and always enabled. Are you planning to handle dynamic SGIs? If 
yes, then can you provide more details?

>       /* First time the IRQ is setup */
>       if ( disabled )
>       {
> -        gic_route_irq_to_xen(desc, GIC_PRI_IRQ);
> +        unsigned int prio = GIC_PRI_IRQ;
> +
> +        /* Use appropriate priority based on interrupt type */
> +        if (desc->irq < NR_GIC_SGI)
> +            prio = GIC_PRI_IPI;

I am a bit split with this change. I feel static SGI (e.g. EVENT_CHECK, 
CALL_FUNCTION) should have higher priority to the dynamic SGIs because 
they are critical for Xen.

Before making my mind, I would like to understand a bit more the use case.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:13:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:13:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122680.1466217 (Exim 4.92)
	(envelope-from )
	id 1uxC0y-0004Jh-V7; Fri, 12 Sep 2025 22:13:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122680.1466217; Fri, 12 Sep 2025 22: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 1uxC0y-0004Ja-Sc; Fri, 12 Sep 2025 22:13:08 +0000
Received: by outflank-mailman (input) for mailman id 1122680;
 Fri, 12 Sep 2025 22:13: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 1uxC0x-0004JU-QJ
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:13: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 a54c9722-9025-11f0-9809-7dc792cee155;
 Sat, 13 Sep 2025 00:13:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 5C34443492;
 Fri, 12 Sep 2025 22:13:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CC43C4CEF1;
 Fri, 12 Sep 2025 22:12: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: a54c9722-9025-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757715180;
	bh=Ccd/zGgaIQAigfpa2OWbRTTmobz6C5JGvboSwNSPcuk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=inXVFrwXrbDGrynPktjBgPQSVzTFJ4N/QSTNSb2jAcMMi1G0U2QSGtt1GM2f4Szoa
	 f1j+U/bSQNdFNUqwwVa8QWsNsTnvw33c8k4e5Qo2hUmd0Ca/SuTvAtIEBHIkPBC6HK
	 78PNOmGFxzQfsnWS0styy7Qb2XJsli1njVYQflJc4YY00aTtw9mSdHg0ITFgGM2mqq
	 Ci7XeTMXr2TspF8JO4+PaDZ/jZFzlqIo0qorIUKMtBWWjpx1FLCqOGQJ3VvrsSuM8h
	 XYzFMQri2oEUJatrLGUiTVf4hfjKuVEThWUi0JFp62baZZbq/Z9A8GTztNqLw5lHA8
	 8jvmNHLRTYXCw==
Date: Fri, 12 Sep 2025 15:12:53 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: Grygorii Strashko , 
    "xen-devel@lists.xenproject.org" , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [XEN][PATCH] xen/arm: restrict cpu_up_send_sgi() to arm32
In-Reply-To: <705d4436-2263-462b-a582-5f0092821959@xen.org>
Message-ID: 
References: <20250911081213.1323594-1-grygorii_strashko@epam.com> <705d4436-2263-462b-a582-5f0092821959@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 12 Sep 2025, Julien Grall wrote:
> Hi Grygorii,
> 
> On 11/09/2025 09:12, Grygorii Strashko wrote:
> > From: Grygorii Strashko 
> > 
> > Restrict cpu_up_send_sgi() function to arm32 code as it's used by arm32
> > platforms only and unreachable on arm64 (Misra rule 2.1).
> > 
> > Signed-off-by: Grygorii Strashko 
> > ---> Logically cpu_up_send_sgi() should be moved in arm32, but source is
> > "GPL-2.0-or-later" while possible destination is "GPL-2.0-only", so put it
> > under ifdef for now.
> 
> :(. I don't know if we will ever solve this license mess... Looking at the
> list of platform using cpu_up_send_sgi(), all the platforms are 10+ years old
> and to be honest except maybe the rcar2 development platforms. I doubt there
> are anyone using them.
> 
> So I would be tempted to get rid of them and mandate PSCI when booting on Xen.
> 
> Bertrand, Michal, Stefano any thoughts?

I am OK with that.


> Meanwhile for this patch:
> 
> Acked-by: Julien Grall 



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:15:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:15:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122693.1466228 (Exim 4.92)
	(envelope-from )
	id 1uxC3Z-0004sQ-Am; Fri, 12 Sep 2025 22:15:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122693.1466228; Fri, 12 Sep 2025 22: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 1uxC3Z-0004sJ-89; Fri, 12 Sep 2025 22:15:49 +0000
Received: by outflank-mailman (input) for mailman id 1122693;
 Fri, 12 Sep 2025 22:15: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 1uxC3Y-0004sD-4D
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:15:48 +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 081f2ee5-9026-11f0-9d13-b5c5bf9af7f9;
 Sat, 13 Sep 2025 00:15:47 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-45b9c35bc0aso20647165e9.2
 for ; Fri, 12 Sep 2025 15:15:47 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e01984a62sm42414805e9.4.2025.09.12.15.15.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 12 Sep 2025 15:15: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: 081f2ee5-9026-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757715346; x=1758320146; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fI12ki/2YG8fLNA7sjUeC6RtlTYEgW9nrZQllWkJzRg=;
        b=s9e3ARRACT+dPW+d3jE7kfpmD3CLKFiowArDJgXVRj0ysFK5rk5agVsc4OWXX3/ajj
         hvJ6uXS6oQNBEGejYFe6qE+z+m4b/NSHIFJiZVz0AOMsaQW1OT6Zpp2Ic9UAc7Jok+k1
         AR0STS8C5vzKOMb2bl+yZFAXcF0RIstp/vgAA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757715346; x=1758320146;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fI12ki/2YG8fLNA7sjUeC6RtlTYEgW9nrZQllWkJzRg=;
        b=eY3rYEwKoH31Kj7giWwY9in6ytTdbI22cdhVdajNBrl6gBWaxdy97BP8l3QXcqu1dc
         EMojrPlORHGo81DDWw0hmCx8SGCQNBm5cKYQ6iYkMlQNbQO0ZGfhMO7kTVcc37Yq0UlH
         9awTh1mu535DTmc9iK4oiuoSByAUmEWc0NC64JD+vsi6JuNrByR0RxLT9QxbuqoyiOwh
         xCnXBqP0lRNWWBk55dWvoqaWD3ZXoZjc8uHMm7AhexEnDBdVz1nQZQXzlQlDO1F5mO/R
         YOcchzfanYjQiKJWbU3ab1lSR1jC7oj+uD88POlMwcemzj7C/MBGC/MyOGqjM3X7xPen
         kMZw==
X-Gm-Message-State: AOJu0YwHGNf6L5tA6E1BJmUYONK4R8uv6qAioAJzgIuSjaVbnl+UGk1V
	P2U5Lr2UWfwh27dh8CISMqEeDmrsYMyb9UKMe5igt87ulJCtzS0JLnonmNq/bGPExyR52O4bUpg
	dSiRq
X-Gm-Gg: ASbGncsGG7Z12YqTkq3KETSmPh+6mW4eEtbKJrOHoPATyPAaQg00rHVoW5S2k8Q5I2P
	IRn5X0xYJSUuoCIzOt0u7Aw+KuqP3gSOmAPqfCRgmE9f19NTJ8uekuuHygYpfo4ZQh9ChLrRTOa
	EkF2Q6AmjP/O1CbG6JYzM4aQLQEaGSnDLECXBCJXA/IzEa1ZqNelQ8PFtjGK+OqiKSE5nnnXxNY
	myom+rDcQ46Rp7eNTb7P96j05VQ+0tMouwr+IISWajy0LICc9E7GolSZ7rZ770vXgnZ/2SrnhMk
	sIvqxtUFtK62EZfZzb5x+NF5Nmry5MZRPnq7vWMtbs9dRfSqeobv1jrhMhX5z3BFLfhFG1MJ+WW
	AaUl3XmVecFvwDKmpK5pJ8vEco4CPpSKyXL49ueAaWUHGMMyBvBRLX95WFJ5ssjaoWaQ3IS+B/r
	lvuTk=
X-Google-Smtp-Source: AGHT+IHL57xbQNLyXwWa6TfY10Loe97ih3Czug1bfxrG8oZCVxEB+Nxrd6BfG/1rTMSppH5ryP9GKg==
X-Received: by 2002:a05:600c:22d4:b0:45c:b56c:4194 with SMTP id 5b1f17b1804b1-45f211ccb4emr32414765e9.2.1757715346024;
        Fri, 12 Sep 2025 15:15:46 -0700 (PDT)
Message-ID: <9d128ef7-fd18-4eed-90e9-1a0236be361b@citrix.com>
Date: Fri, 12 Sep 2025 23:15:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/8] x86/emul: Make condition coverage warning
 non-fatal
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Volodymyr Babchuk 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-6-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: <20250912144427.1905141-6-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/09/2025 3:44 pm, Andrew Cooper wrote:
> Randconfig with GCC-14 (Debian Trixie) found:
>
>   In file included from arch/x86/x86_emulate/x86_emulate.c:11,
>                    from arch/x86/x86_emulate.c:27:
>   arch/x86/x86_emulate/x86_emulate.c: In function 'x86_emulate':
>   arch/x86/x86_emulate/private.h:482:8: error: Too many conditions (found 826); giving up coverage [-Werror=coverage-too-many-conditions]
>     482 | ({  if ( (p) ) {                                                          \
>         |        ^
>   arch/x86/x86_emulate/x86_emulate.c:1283:5: note: in expansion of macro 'generate_exception_if'
>    1283 |     generate_exception_if((mode_vif() &&
>         |     ^~~~~~~~~~~~~~~~~~~~~
>
> which is a consequence of having a new enough compiler to allow
> CONFIG_CONDITIONAL_COVERAGE in to the mix.
>
> In the short term make warning non-fatal.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: Stefano Stabellini 
> CC: Volodymyr Babchuk 
>
> v4:
>  * New
>
> Full failure logs:
>   https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11331286819
> ---
>  xen/arch/x86/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index d7aed7d92c15..a0bba5d9085e 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -98,6 +98,9 @@ $(obj)/usercopy.o: CFLAGS-y += -iquote .
>  ifneq ($(CONFIG_HVM),y)
>  $(obj)/x86_emulate.o: CFLAGS-y += -Wno-unused-label
>  endif
> +ifneq ($(CONFIG_CONDITION_COVERAGE),y)
> +$(obj)/x86_emulate.o: CFLAGS-y += $(call cc-option,$(CC),-Wno-error=coverage-too-many-conditions)
> +endif

This should be ifeq, not ifneq.  It's probably safe to drop the
cc-option too, as that limits it to compilers which know
-fcondition-coverage

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:18:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:18:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122706.1466239 (Exim 4.92)
	(envelope-from )
	id 1uxC6Y-0005d1-Qu; Fri, 12 Sep 2025 22:18:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122706.1466239; Fri, 12 Sep 2025 22:18: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 1uxC6Y-0005cu-Mf; Fri, 12 Sep 2025 22:18:54 +0000
Received: by outflank-mailman (input) for mailman id 1122706;
 Fri, 12 Sep 2025 22:18: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 1uxC6W-0005co-MJ
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:18:52 +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 7534cd62-9026-11f0-9809-7dc792cee155;
 Sat, 13 Sep 2025 00:18:50 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1D5F46000A;
 Fri, 12 Sep 2025 22:18:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D551C4CEF1;
 Fri, 12 Sep 2025 22:18: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: 7534cd62-9026-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757715528;
	bh=mWEATl0bC6mjbFq66ZmUqPd6XcUCIomMSjFvLZTJo4k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LJ1pepOsE1EYULrE7b2PU2SCcMvpV4YtOOAMWS+eljGPTF4lBwMMOmtY/ts6v+CKe
	 wQqb3bU5+uKIZw5X9DEANgBwgdM8XSFF/R20F+EHOiZSZXgdbZ2KmDYYG4x0ZqnlQZ
	 SYjL7y4lh2AWrkT5nLwS6LRhCUgPm5kXTvwYwbFx3SysOwHDst/l23ZjsYMXy8wwsA
	 2KtbVfC3AEDdqgJE+pXvyWEdYh6/If2bvzZ66nWanW38R7D7jPns718zWcgr+IKOyr
	 58fE81HzwBEH27e/8OnEKmjdW5TX2XLS8FJfrUlU4qbXulcSzGPgjanIIaoqUPGBTr
	 s/mIo0rVsh3mg==
Date: Fri, 12 Sep 2025 15:18:46 -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 , 
    Oleksii Kurochko , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH v4 0/8] CI: Add Debian Trixie
In-Reply-To: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 12 Sep 2025, Andrew Cooper wrote:
> Refresh the Trixie series.  A few more bugfixes found by randconfig and log
> inspection.
> 
> These containers are already built and deployed for people to test with.
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2036687955

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:39:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:39:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122722.1466247 (Exim 4.92)
	(envelope-from )
	id 1uxCPy-00005E-8D; Fri, 12 Sep 2025 22:38:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122722.1466247; Fri, 12 Sep 2025 22: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 1uxCPy-000053-5X; Fri, 12 Sep 2025 22:38:58 +0000
Received: by outflank-mailman (input) for mailman id 1122722;
 Fri, 12 Sep 2025 22:38:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxCPw-00004w-Rp
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:38:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxCPw-006fOu-0k;
 Fri, 12 Sep 2025 22:38:56 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxCPw-006Ebm-0Z;
 Fri, 12 Sep 2025 22:38: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" 
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=/UZytuTqwTQZKP0akQ05+kyvh35/kIXdYoAHrinw1Hg=; b=6pxpQZcKLTGGmNSYdccGMuIEHO
	qJ14wpzJRUbTN3CL0dXfuUI9mOXyqiDMmYU8nWP6P95nEAEJbM8sQA/rGKqPmKptQD0ZeJvy9NRsW
	SPeOkjmlqUWWzdaUaDeIne5yKgCJGFRa7tLbqg4wJXlxU+Xie9oN6ymizZcmRjqi8+ic=;
Message-ID: <86aec3a8-a4aa-40e4-9542-9d291c2c119e@xen.org>
Date: Fri, 12 Sep 2025 23:38:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 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 ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 02/09/2025 10:03, Mykola Kvach wrote:
> @@ -880,6 +883,40 @@ void arch_domain_creation_finished(struct domain *d)
>       p2m_domain_creation_finished(d);
>   }
>   
> +int arch_domain_resume(struct domain *d)
> +{
> +    int rc;
> +    typeof(d->arch.resume_ctx) *ctx = &d->arch.resume_ctx;

I know this is v13, but I don't think we should use typeof() is in this 
context. "struct resume_info" is much shorter and help the review (I 
don't have to grep resume_ctx to figure out the type).

> +
> +    if ( !d->is_shutting_down || d->shutdown_code != SHUTDOWN_suspend )
> +    {
> +        dprintk(XENLOG_WARNING,
> +                "%pd: Invalid domain state for resume: is_shutting_down=%d, shutdown_code=%d\n",
> +                d, d->is_shutting_down, d->shutdown_code);
> +        return -EINVAL;
> +    }
> +
> +    /*
> +     * It is still possible to call domain_shutdown() with a suspend reason
> +     * via some hypercalls, such as SCHEDOP_shutdown or SCHEDOP_remote_shutdown.
> +     * In these cases, the resume context will be empty.
> +     * This is not expected to cause any issues, so we just warn about the
> +     * situation and return without error, allowing the existing logic to
> +     * proceed as expected.

I think this odd to warn if something is expected. It would be best to 
use "XENLOG_INFO".

> +     */
> +    if ( !ctx->wake_cpu )
> +    {
> +        dprintk(XENLOG_WARNING, "%pd: Invalid wake CPU pointer for resume\n",

As you wrote above, there is nothing wrong. So "Invalid" is not correct. 
I think a better wording is "Wake CPU pointer context was not provided").

Also note that dprintk() will be a NOP in release build. I am guessing 
this is intended?

I will answer you Jan's comment separately. The rest looks good to me.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:43:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:43:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122740.1466257 (Exim 4.92)
	(envelope-from )
	id 1uxCUC-0001gr-SX; Fri, 12 Sep 2025 22:43:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122740.1466257; Fri, 12 Sep 2025 22:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxCUC-0001gk-Po; Fri, 12 Sep 2025 22:43:20 +0000
Received: by outflank-mailman (input) for mailman id 1122740;
 Fri, 12 Sep 2025 22:43:19 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxCUB-0001ge-OU
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:43:19 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxCU7-006fTv-0h;
 Fri, 12 Sep 2025 22:43:15 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxCU7-006F49-0h;
 Fri, 12 Sep 2025 22:43: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=lsSS3bXDr65K5UWTyDadFhlbxDaP5BEzvQcAZse4Rsw=; b=nV/9eR8Qngj4UToEdoOP9NigF+
	uzANHeUw7jr+apEgnZaJFooaIkg/deM0RvpGNFDb1QGZsz+svIPeVWmn409K+Jj9HN+lh7+JYo6cY
	4Eh/gRkBcXQpvP0qdydS2i7R6LRUf9lS6+MRsF4fOU/JVXICNIF31wHd1UWSEaGzX1Cs=;
Message-ID: <212f3043-bfd1-4c84-bce4-ed98648aa880@xen.org>
Date: Fri, 12 Sep 2025 23:43:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for
 guests
Content-Language: en-GB
To: Mykola Kvach , Jan Beulich 
Cc: Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com>
 <28e78684-ff7b-4902-89cd-c341ba236d57@suse.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 02/09/2025 18:55, Mykola Kvach wrote:
>>> --- a/xen/include/xen/domain.h
>>> +++ b/xen/include/xen/domain.h
>>> @@ -8,6 +8,10 @@
>>>
>>>   #include 
>>>
>>> +#if __has_include()
>>> +#include 
>>> +#endif
>>> +
>>>   struct guest_area {
>>>       struct page_info *pg;
>>>       void *map;
>>> @@ -109,6 +113,13 @@ int arch_domain_soft_reset(struct domain *d);
>>>
>>>   void arch_domain_creation_finished(struct domain *d);
>>>
>>> +#if !__has_include()
>>> +static inline int arch_domain_resume(struct domain *d)
>>> +{
>>> +    return 0;
>>> +}
>>> +#endif /* !__has_include() */
>>> +
>>>   void arch_p2m_set_access_required(struct domain *d, bool access_required);
>>>
>>>   int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c);
>>
>> Imo it would be preferable to have such in a single #if/#else. There's nothing
>> wrong with an #include not sitting at the very top.
> 
> I understand that includes can be placed near where something from the
> header is used. However, I find it more natural to keep them together
> in a single location.

It is not always possible to keep all includes together. I also have a 
slight preference to Jan suggestion because we don't have multiple "#if 
__has_include()" which I find rather ugly but necessary.

> 
>>
>> (Another question is whether to put this in xen/domain.h at all. There could
>> be a xen/suspend.h having - for now at least - just this and nothing else.)
> 
> With this approach, I don’t need to move the include to the middle of
> the file.

A new suspend.h file would also work for me.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 22:47:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 22:47:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122765.1466267 (Exim 4.92)
	(envelope-from )
	id 1uxCXq-0002QQ-Ap; Fri, 12 Sep 2025 22:47:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122765.1466267; Fri, 12 Sep 2025 22:47: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 1uxCXq-0002QJ-8O; Fri, 12 Sep 2025 22:47:06 +0000
Received: by outflank-mailman (input) for mailman id 1122765;
 Fri, 12 Sep 2025 22:47:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxCXo-0002QD-Me
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 22:47:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxCXo-006fWu-0l;
 Fri, 12 Sep 2025 22:47:04 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxCXo-006FJM-17;
 Fri, 12 Sep 2025 22:47: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=sYPqw6SWkUINZCLQgp8uRx2waBan1moNfGZFtXkfZVU=; b=bvrikgAlYh7NN2Ww8yuctNwXdK
	220EtEMRxXJFZXR0fN67JBotM59/doMCh6wR8B4Ujym232+wP/2RKrYUHNwIWEU1ItxzH7SRv3lTC
	h+/DwOAzM9vlsgAk0TUzvuLwR+3cOsE2b2kB5dbP4S0oKhTrgHIY7uITMir9+WkZfzNo=;
Message-ID: <95ac4fa9-3169-4285-874e-32ec58c247b2@xen.org>
Date: Fri, 12 Sep 2025 23:47:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 3/4] SUPPORT.md: Document PSCI SYSTEM_SUSPEND support
 for guests
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: 
 <9dffe19e3ba29020a8f35c0fcf12f088de6b9eea.1756803419.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <9dffe19e3ba29020a8f35c0fcf12f088de6b9eea.1756803419.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 02/09/2025 10:03, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> Add a new entry under the "Virtual Hardware, QEMU" section documenting
> support for the optional PSCI SYSTEM_SUSPEND function exposed to guests.

AFAICT, this is added under "Virtual Hardware, Hypervisor".

> 
> This function is available via the virtual PSCI (vPSCI) interface and
> allows guest domains (domUs) to initiate system suspend operations.
> 
> The feature is currently marked as "Tech Preview".
> 
> Signed-off-by: Mykola Kvach 

With the above fixed:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 23:04:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 23:04:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122779.1466278 (Exim 4.92)
	(envelope-from )
	id 1uxCoc-0005IU-Nm; Fri, 12 Sep 2025 23:04:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122779.1466278; Fri, 12 Sep 2025 23:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxCoc-0005IN-Ju; Fri, 12 Sep 2025 23:04:26 +0000
Received: by outflank-mailman (input) for mailman id 1122779;
 Fri, 12 Sep 2025 23:04:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxCoa-0005IH-S1
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 23:04:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxCoa-006frV-0s;
 Fri, 12 Sep 2025 23:04:24 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxCoa-006G1C-17;
 Fri, 12 Sep 2025 23:04: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=YEROTMEFMnIIQSzRr4/J7fp4WWdzOAOQxEfLm/Xv528=; b=GO50QwU1AVDoodDkYWVMX/WL42
	cCpwqYo1ukXT1xKJkJd9iAMDJ4K/k3uUiFW6t1ArCvvrm3rIrc3btAYtvF/9E6GEB+hnxawQOTGOA
	aH6sgCcbbS8Xa8cjSRme9CAi8dpJZhe4f+gfO8bTiW1HnMSvJjA0CQmRVPD6+j4a4l1Y=;
Message-ID: <0ac3217d-f3d6-4bac-ac27-0afa6775f03c@xen.org>
Date: Sat, 13 Sep 2025 00:04:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 01/13] xen/arm: Add suspend and resume timer helpers
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mirela Simonovic ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Saeed Nowshadi ,
 Mykola Kvach 
References: 
 <781c8e1b3a4d9b269bfde125072a84baae3f9bb3.1756763487.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <781c8e1b3a4d9b269bfde125072a84baae3f9bb3.1756763487.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 01/09/2025 23:10, Mykola Kvach wrote:
> From: Mirela Simonovic 
> 
> Timer interrupts must be disabled while the system is suspended to prevent
> spurious wake-ups.

Yet, you don't seem to disable the virtual interrupt. Can you explain why?

> Suspending the timers involves disabling both the EL1
> physical timer and the EL2 hypervisor timer.
I know this is what Arm is naming the timers. But I would rather s/EL1// 
and s/EL2// because the physical timer is also accessible from EL0.

Note that Xen doesn't use or expose the physical timer. So it should 
always be disabled at the point "time_suspend()" is called. I am still 
ok to disable it just in case though.

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

The name of the times are "physical timer" and "hypervisor timer".

> +static inline void disable_physical_timers(void)

"Physical is a bit misleading" in this context. All the 3 timers 
(virtual, physical, hypervisor) are physical timers. My preference would 
be to name this function disable_timers() (assuming you also need to 
disable the virtual timer).

> +{
> +    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);

I think we should add a comment about the physical timer.

> +}
> +
> +#endif /* CONFIG_SYSTEM_SUSPEND */
> +
>   static int cpu_time_callback(struct notifier_block *nfb,
>                                unsigned long action,
>                                void *hcpu)Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 23:30:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 23:30:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122797.1466288 (Exim 4.92)
	(envelope-from )
	id 1uxDDq-00011I-O4; Fri, 12 Sep 2025 23:30:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122797.1466288; Fri, 12 Sep 2025 23:30:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxDDq-00011B-KP; Fri, 12 Sep 2025 23:30:30 +0000
Received: by outflank-mailman (input) for mailman id 1122797;
 Fri, 12 Sep 2025 23:30:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxDDp-000115-B5
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 23:30:29 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxDDo-006gHx-1t;
 Fri, 12 Sep 2025 23:30:28 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxDDo-006HDj-2C;
 Fri, 12 Sep 2025 23:30:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=mx/IgOPXrMzMO910AY8EMCxcgVjkUkGwXy0BjCfWsN8=; b=O8GhyecqpC1He5HfRJrMXmGINi
	zi+kVxlpU41Xt5E7kKs6Uc4q47etdXOFu8XyqslBX2stmRcdH1oRcng27rj4btH+WzNjY5XOxqjGX
	dXGtlWOh7gxv2nOJELERSU93B+xgDlRLD2Vwo3jqlaWX+9iDZdhcBhPl30PttewY0V8Q=;
Message-ID: 
Date: Sat, 13 Sep 2025 00:30:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/13] xen/arm: gic-v2: Implement GIC suspend/resume
 functions
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mirela Simonovic ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Saeed Nowshadi ,
 Mykyta Poturai ,
 Mykola Kvach 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 01/09/2025 23:10, Mykola Kvach wrote:
> 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.
> 
> Signed-off-by: Mirela Simonovic 
> Signed-off-by: Saeed Nowshadi 
> Signed-off-by: Mykyta Poturai 
> Signed-off-by: Mykola Kvach 
> ---
> Changes in v6:
> - drop extra func/line printing from dprintk
> - drop checking context allocation from resume handler
> - merge some loops where it is possible
> 
> 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          | 143 +++++++++++++++++++++++++++++++++
>   xen/arch/arm/gic.c             |  29 +++++++
>   xen/arch/arm/include/asm/gic.h |  12 +++
>   3 files changed, 184 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index b23e72a3d0..6373599e69 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1098,6 +1098,140 @@ 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;

I don't quite follow why all the registers above needs to be 
saved/restored. Is it just convenience because it is too complicated to 
recreate the value?

> +    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, "GICv2 suspend context not allocated!\n");
> +        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);
> +        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);
> +        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;
> +
 > +    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);
> +
> +        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);
> +        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);

Why are we forcing CTL_ENABLE? Surely it should have been set and if 
not, then why is it fine to override it?

> +
> +    /* 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);

Same question here for both ENABLE and EOI.

> +}
> +
> +static void gicv2_alloc_context(struct gicv2_context *gc)

I am a bit surprised this is not returning an error? Why is it ok to 
ignore the error and continue? At least for now, if someone enable 
CONFIG_SYSTEM_SUSPEND, they would likely want the feature. So it would 
be better to crash early.

> +{
> +    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;

I am wondering if we are really saving that much by allocating each 
array separately? It would simply the code if we fix the array to 
support up to 1024 interrupts so we allocate a single structure.

 > +> +    return;
> +
> + err_free:
> +    printk(XENLOG_ERR "Failed to allocate memory for GICv2 suspend context\n");
> +> +    xfree(gc->gicd_icfgr);
> +    xfree(gc->gicd_ipriorityr);
> +    xfree(gc->gicd_itargetsr);
> +    xfree(gc->gicd_isactiver);
> +    xfree(gc->gicd_isenabler);

NIT: If you use XFREE(), then you don't need the memset below.

> +
> +    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 +1436,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 +1484,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 */

What would prevent us to suspend from another CPU?

> +    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;

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Sep 12 23:45:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Sep 2025 23:45:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1122827.1466297 (Exim 4.92)
	(envelope-from )
	id 1uxDSO-0002oZ-Ti; Fri, 12 Sep 2025 23:45:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1122827.1466297; Fri, 12 Sep 2025 23:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxDSO-0002oS-RH; Fri, 12 Sep 2025 23:45:32 +0000
Received: by outflank-mailman (input) for mailman id 1122827;
 Fri, 12 Sep 2025 23:45:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxDSO-0002oM-5m
 for xen-devel@lists.xenproject.org; Fri, 12 Sep 2025 23:45:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxDSN-006gXl-2R;
 Fri, 12 Sep 2025 23:45:31 +0000
Received: from [2a02:8012:3a1:0:95d0:d8bb:cf45:58c2]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uxDSN-006IF0-2L;
 Fri, 12 Sep 2025 23:45: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=ORhsJawLryrRsLHdoo+dTD19aW3s/bereOldDhCGGbI=; b=hWIzrzVx+b1zr8uF70TUqhBaiY
	nK2yX4FDPAoHS3eD2lM6zKW/YaKG+DFyLmUFd5L+ol1sTWc4kBUa9IfnotU1vev82R5t69Glm4lH1
	o8KoxxIgHSVrJ7MWrmA/ZetiUUkvpwmAfxzZ6uudXqYSgrs3pjX7g17G/R/zSFI3dlWo=;
Message-ID: <40480c61-0619-41b8-866a-85a219f5e157@xen.org>
Date: Sat, 13 Sep 2025 00:45:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 04/13] xen/arm: Don't release IRQs on suspend
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <293acbb653b5f4d5bf71dc459f9de3e729bff3e1.1756763487.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <293acbb653b5f4d5bf71dc459f9de3e729bff3e1.1756763487.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 01/09/2025 23:10, Mykola Kvach wrote:
> 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:

Looking at the stack trace, I don't understand why this error would not 
happen when offlining a CPU. Can you clarify?

Anyway, I am not very happy to special case suspend/resume in the IRQ 
code. So I would strongly prefer if we follow a different approach.

The one that come to my mind is to switch from request_irq() to 
setup_irq() and allocate the action in a per-cpu variable. With that, 
there should be no free happening with the stop_machine helper.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Sep 13 07:16:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 07:16:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123040.1466371 (Exim 4.92)
	(envelope-from )
	id 1uxKUx-0004vh-Qm; Sat, 13 Sep 2025 07:16:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123040.1466371; Sat, 13 Sep 2025 07: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 1uxKUx-0004va-Nt; Sat, 13 Sep 2025 07:16:39 +0000
Received: by outflank-mailman (input) for mailman id 1123040;
 Sat, 13 Sep 2025 07: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 1uxKUw-0004vU-Nb
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 07:16:38 +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 95f4e0ba-9071-11f0-9d13-b5c5bf9af7f9;
 Sat, 13 Sep 2025 09:16:37 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-45dec1ae562so23386435e9.1
 for ; Sat, 13 Sep 2025 00:16:37 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3e7607cd4cdsm9238829f8f.37.2025.09.13.00.16.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 00:16: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: 95f4e0ba-9071-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757747796; x=1758352596; 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=xje1crB6/RpCXZepP9n4C83bdrQMxqzt4pcOcmmsRGg=;
        b=G0uXH/0HBMWaX7bhdoxhUAHuwlFLetclLfyI9IJCDs96XJ6/ArF+GSw53XyeDEI1PH
         cDFfvRyZ1GQqMThhV+uef7mL3l9XBLAzSDFH6PTqaiVjjSCVL1SZvGaqsu5YhBP1cFW7
         acIC8ylkg7CIAVhoRgYlQphdgM3g/tpcyNtNCu9VOk0jtBm6nvWhj+EMHzGntEZrL0uf
         kBXLF2zE1SLNdYVAE0JkjR3BWkDkdR+DuheEjDAn8HV0QfKH+SErSuRjY+D7WXgBrhqf
         Gcw0uyD3kNxB5h7CtatRL7WGaAtbn75YAkyPP+FU97/DGwfjZ6VgoVjv4wwdvHdkMXk0
         GGNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757747796; x=1758352596;
        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=xje1crB6/RpCXZepP9n4C83bdrQMxqzt4pcOcmmsRGg=;
        b=rzI3QUWzV7mCbKShBRZLv9IJYJjuonk2Pcw4g/seaCXE1KeWq1fF0wpgqbAIZnDqti
         mwkHS9iyZD2uWy9/sfBZ0lHPMo9RlmBkRo8mHSxDEUmJ2F7n9dZxZGqmzw9cE99AgqfE
         yu0/5FdWZ5RpqOIT7p11ER1jgu1B/LqI76kxuPSMJa3OIEHaqQIbpP13K0uQ2BTiFpAP
         FsXm+LsaRa00C5zPj7fuPOZowoTCoZW7aiqm9VKnRaC+tmuyRw1C7oB6uq1WuR4TlkQ9
         d7xrJ2U2FuBje6PBxS77TeU8xkrz/QO34KjKKfs8Us/mwmmxlEuyCWdqWajvqla7EhXm
         lT3w==
X-Forwarded-Encrypted: i=1; AJvYcCXLNouANdLZpE+4VbXqYHWZ2oFBNyTSRQil6837hTnLl0hatCacPbNMyquxSgx5TvRTAgSgHoPT4GE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQV9FsC8OMUDo60ldG7jp/SwHZMxebC9D0SyU0FLIkRl2Mpd7n
	Hml0E6U3W2BPIhBIz98VunSILSbzzklX1yKmWGKUgsyn9KQXr26BpV1UipgTx2Ln80U=
X-Gm-Gg: ASbGncvyUCOxpAugm+WdL4UJaVRA81x/8vm5h6yrdpuLrDYOZFiIfg92R2AjRwc/1+y
	aRLROfZaMfnbJ0rQvecwdJUeKINEMqh6R2XdNJRmNycUqDaorOiUc3d6LZoEOMk64o7+RUwR32+
	YEuZU1GbhVANIOdPWMezXvqbLNGLcJZdinhTNoGJlJ0EF47lEta/chSRAjLAEQfzW2yH8NRnDgC
	nV3dZrWTwO9CYOvcZc+y9jnGM8JXl43AE64CndRJr1gJjlfbqqnoLbRFc3G86dtB/17d6xJI33P
	jjF90GMVdv5jiRvaBHM4aqJ5jpjwlZ6wQAeH6vDlXuVqCIBYfmHhhrWIGJL6WbgMJ1aNjVpRuhC
	fOD1adqwAtGtqIzt/f6FmRAeXKyl4rnNNY+Sh+V939yfEOTenRD1sjqgTl6/URhcC75PBf4sqT/
	bAQCwTaJzFaQvFQQZDMT1wBsN2N25U71PLm3HHVaRsXVW2AzIJebYW7hI=
X-Google-Smtp-Source: AGHT+IH1c4+pxrHtLZCPRNkyCEtPXUpmokLJCxIB+vWOmL5Ne7ATfKa+ZCpiH20dtRe6rBtXDB+VPA==
X-Received: by 2002:a05:6000:230b:b0:3d0:b3cc:c1ff with SMTP id ffacd0b85a97d-3e765a2df90mr5048129f8f.39.1757747796470;
        Sat, 13 Sep 2025 00:16:36 -0700 (PDT)
Message-ID: <1f1a5a8f-0b1f-4e50-9467-3d27d8a3089d@suse.com>
Date: Sat, 13 Sep 2025 09:16:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-jgross@suse.com>
 <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0sOc0ImYWr9fRcilD63Tv4k6"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0sOc0ImYWr9fRcilD63Tv4k6
Content-Type: multipart/mixed; boundary="------------cwjEYSPA3N88hrGJnWJPxla7";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
Message-ID: <1f1a5a8f-0b1f-4e50-9467-3d27d8a3089d@suse.com>
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
References: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-jgross@suse.com>
 <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
In-Reply-To: <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
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=

--------------cwjEYSPA3N88hrGJnWJPxla7
Content-Type: multipart/mixed; boundary="------------pPrLaUNLqexxwDpL6LYOMVsq"

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

T24gMTIuMDkuMjUgMjM6MDksIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgSnVlcmdlbiwN
Cj4gDQo+IFNvcnJ5IGZvciB0aGUgbGF0ZSBhbnN3ZXIuDQo+IA0KPiBPbiAzMC8wNy8yMDI1
IDEzOjIzLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gTGl2ZSB1cGRhdGUgaXMgbm93IHdv
cmtpbmcgd2l0aCB0aGUgUFZIIHZhcmlhbnQgb2YgeGVuc3RvcmUtc3R1YmRvbS4NCj4gID4g
PiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQo+PiAt
LS0NCj4+IFYyOg0KPj4gLSBuZXcgcGF0Y2gNCj4+IC0tLQ0KPj4gwqAgU1VQUE9SVC5tZCB8
IDIgKy0NCj4+IMKgIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxldGlv
bigtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS9TVVBQT1JULm1kIGIvU1VQUE9SVC5tZA0KPj4g
aW5kZXggNmE4MmE5MjE4OS4uZWI0NGVlODVmZCAxMDA2NDQNCj4+IC0tLSBhL1NVUFBPUlQu
bWQNCj4+ICsrKyBiL1NVUFBPUlQubWQNCj4+IEBAIC0yODAsNyArMjgwLDcgQEAgb3IgaXRz
ZWxmIHdpbGwgbm90IGJlIHJlZ2FyZGVkIGEgc2VjdXJpdHkgaXNzdWUuDQo+PiDCoCAjIyMg
QyB4ZW5zdG9yZSBzdHViZG9tIFBWSA0KPj4gwqDCoMKgwqDCoCBTdGF0dXM6IFN1cHBvcnRl
ZA0KPj4gLcKgwqDCoCBTdGF0dXMsIExpdmV1cGRhdGU6IE5vdCBpbXBsZW1lbnRlZA0KPj4g
K8KgwqDCoCBTdGF0dXMsIExpdmV1cGRhdGU6IFN1cHBvcnRlZA0KPiANCj4gSSB3ZW50IHRo
cm91Z2ggdGhlIGNoYW5nZXMgaW4gWGVuc3RvcmVkIGZvciB0aGUgc3R1YmRvbSBhbmQgSSBo
YXZlIG9uZSBxdWVzdGlvbiANCj4gcmVnYXJkaW5nIFsxXS4gRG9lcyB0aGlzIG1lYW4gdGhl
IGV2ZW50IGNoYW5uZWwgd2lsbCBiZSBjbG9zZWQgZHVyaW5nIExpdmUtIA0KPiBVcGRhdGU/
IEFza2luZyBiZWNhdXNlIEkgdmFndWVseSByZW1lbWJlciB3ZSBuZWVkIHRvIGtlZXAgdGhl
bSBvcGVuIHRvIGF2b2lkIA0KPiBsb3NpbmcgZXZlbnRzLiBJIGFtIHdvbmRlcmluZyBob3cg
dGhpcyB3b3VsZCB3b3JrIGluIHN0dWJkb20/DQoNClRoZSBldmVudCBjaGFubmVsIGlzIHN0
aWxsIG9wZW4sIGl0cyBqdXN0IHRoZSBNaW5pLU9TIGludGVybmFscyB0aGF0IGRvbid0DQpr
bm93IGFib3V0IHRoaXMuIFRoaXMgaXMgdGhlIHJlYXNvbiBmb3IgY2FsbGluZyB4ZW5ldnRj
aG5fYmluZCgpIHRvIGJyaW5nDQpoeXBlcnZpc29yIGFuZCBNaW5pLU9TIHZpZXcgaW4gc3lu
YyBhZ2Fpbiwgd2l0aG91dCBjaGFuZ2luZyB0aGUgaHlwZXJ2aXNvcg0Kc2lkZS4NCg0KDQpK
dWVyZ2VuDQo=
--------------pPrLaUNLqexxwDpL6LYOMVsq
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-----

--------------pPrLaUNLqexxwDpL6LYOMVsq--

--------------cwjEYSPA3N88hrGJnWJPxla7--

--------------0sOc0ImYWr9fRcilD63Tv4k6
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/Ey8FAmjFGlMFAwAAAAAACgkQsN6d1ii/Ey81
qgf+IE1vgHUEb0/riaqYLz0J3pSR6RGPBa5gJpScMwuHXbJSBOKMdlPxqu1Be6l7LvypnYGTEo0C
AMnpcs0LPMNaFEpnrVW+KdCEj6Fv1oKT24kLN79yQ5iepWFemzIucI2laTlV5GMamVh2991ZtwCE
ZciasY/e3Ejbt3B10OctPoxjNtduD60q4vCiWpyyAJFmrW5Bry+kgmfpqyDEVFk45+YOp/HpRSqq
yBViDqUfFsfcv3uBuc4P7TqXkeoBeAnSHZhZBXJDOXI9/eX49tZYp2c4Lkht5dzWg8eW6HwUez3A
cFfP7stfroqZ1pS/89RUylWgf0gapReWh2x+UI24lg==
=oxZg
-----END PGP SIGNATURE-----

--------------0sOc0ImYWr9fRcilD63Tv4k6--


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 10:31:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 10:31:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123115.1466382 (Exim 4.92)
	(envelope-from )
	id 1uxNX3-0003Fm-Dh; Sat, 13 Sep 2025 10:31:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123115.1466382; Sat, 13 Sep 2025 10:31: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 1uxNX3-0003Fc-7w; Sat, 13 Sep 2025 10:31:01 +0000
Received: by outflank-mailman (input) for mailman id 1123115;
 Sat, 13 Sep 2025 10:31: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 1uxNX2-0003FW-Bv
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 10:31:00 +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 bb9b6d7d-908c-11f0-9809-7dc792cee155;
 Sat, 13 Sep 2025 12:30:58 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by PR3PR03MB6412.eurprd03.prod.outlook.com (2603:10a6:102:7d::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Sat, 13 Sep
 2025 10:30: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%5]) with mapi id 15.20.9115.018; Sat, 13 Sep 2025
 10:30: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: bb9b6d7d-908c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dpyK50VMM+LbzAbHgDw/Y4ML3popKtn57TEg7aYhy755dgK22Ng1bfJBxUdVIhZn96zzejoUibZJqlrVRGtRhK9Zf+VY9PLJT0C+KTsZHl2BxrQO1LwT0+Za+eI4vioTcVwiCTUURaWwXIiEL4UhmchiNOo8RyZVrAfC988pa6UF5ihh4DGLzSh2d2z6HGNdllPo7btOl9yVVZ8NICntxtEzQmMEaBtOV1DnGuVZLjAiFnNV/d+rSmv0GeUf+zTGP5ZmyIi5njpoNs5ffwICxmsVC37wM+dLb/YcYNJWX694HnmX8Bg0eYoPtrdkMdVsIbisPVnRpPEq070FtyOuCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yUBRdFfjv4vjz/L1/mnMHHZQZNhjzGWw6xIiUs8MDUc=;
 b=QBqSvBsMPMXpIyvOzqQrKvTSGrlHqFWxe7n06/34ybWvTwcqkbg2wxs7kR3OtGbkDJN87CF5/nufYiSaXFQlmURpZFIIlKnNHnXyVSOTIWsU+RqdcmYp6BTLRh03quJ1e+WPtWytc5fYxt1mOQBkkAf8Gz6HAn4q9jYHyLDHHmRwkbiWH9b8pZZRwVw1fb61zAaB67f59rcwrebf+eMeGNIuvUomSr3K1/dH99Og4hnccsr8jdYbHEJvJ5SzfavfOCloIiQcpTXiJalX+VhB76b8AayVzb8xQdpJ3g+sXvLw2M6DktmfcF0Rbp0enfwbqwK2Q0IKZuPZPDBKiVrgHQ==
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=yUBRdFfjv4vjz/L1/mnMHHZQZNhjzGWw6xIiUs8MDUc=;
 b=bOt5xka4xxYKbudhdFhKyh0S6M5bGxl79aBt8nUgvo0I+bFD0ko5m48OY5MOhEh/2bxUXywWMLkorMw8BVuSNOczt3TbgT1tsqsAsX4IVEfVLwBZpXPwxazcj56eFG6MXGqA3RKNs8N07zVAbIoiPMyoBphJ5HUJGs0hyWtQ33qYxcfB7t6733nTwNsyUp8xJJc4IUJRVhqt6g9HopXqUtQA43sMU50vmY3hmc138oGB+L5G/QLBh4xQ0dGglBKS6z4U0CVT+fgXwRXQJaAyPr7NcscmwArC/neiPlUV9n4jGGbTpM2fNr01xOd3VIOsUBqXbYPxwQMszzyXtFEydQ==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Oleksii Moisieiev 
Subject: [PATCH][for-4.21] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Topic: [PATCH][for-4.21] xen/arm: Reorder SCI resource cleanup in
 domain destruction
Thread-Index: AQHcJJl8FFyN4sTuc02XpBtKM5m65Q==
Date: Sat, 13 Sep 2025 10:30:54 +0000
Message-ID:
 <164651d0662e674002ed17399300c3a25e6dcbfc.1757757602.git.oleksii_moisieiev@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|PR3PR03MB6412:EE_
x-ms-office365-filtering-correlation-id: 87ab38af-1eb5-4f90-2e93-08ddf2b09ea2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?b/dYcs6OiQ8UPMhbtpU7EHfmB2dtQ8m7hNq/kCr/G9gwOFoS/C9qJdLx8/?=
 =?iso-8859-1?Q?oNMVpMS+nuv/rKb4WIlJ+yvTXiLH/e3ov09LdHIvb/SeQQOHOaUgn8FgBh?=
 =?iso-8859-1?Q?oaXE97mVYC5Sn/PNmzrLdE4Qo6EDW+TVEQeE+xIIE3vvQsoTknjMTbj3ce?=
 =?iso-8859-1?Q?vko6v2Q9e0Sym+jD/074HfB0rHgGuwG9J9TvZMrnLYTUat4eaveVeCn2ts?=
 =?iso-8859-1?Q?3GZtdlCQIrUN6bPffXKrBPEvxE8CvTNuShfRyrfEtUiqVLqxofic+yYyUS?=
 =?iso-8859-1?Q?4ss+utMRmUSTvv420ZsPo3uY5QSk6oEQAKqn6QyGcbiG0Wn4R7C6QqONI4?=
 =?iso-8859-1?Q?fzDaG+aCrWg42xfNs9QXVZP2rhievQ7TvQqhuqGXyVnzJz8v8ZPvnVJuKy?=
 =?iso-8859-1?Q?Uvv88ttwhWyYvxl6frrrC2saR1lXW3ptuDjbSOD14ZHlWRWMQOyzibB95s?=
 =?iso-8859-1?Q?iGXUlimM0AyUpqorQvCV6qJnJWwat9BfDxo21TLFpt3ljHcC5XvTJa3rSH?=
 =?iso-8859-1?Q?oH9+ySVcT5OtSx+NNEwhvOFm9hsxDsXNTDiDDnWZIKrwNh+y0VHX9YRVPH?=
 =?iso-8859-1?Q?R14iGHHv/qBFGgfHmnIChhzanaHHMSCi0hvKrBIBpoLmc9lm9IEnbPLLgL?=
 =?iso-8859-1?Q?xWwj6dkmInM4BlhbfCUVSHIMqLhAP6b9AzNcszj61U30BrdK/7X41YTLQw?=
 =?iso-8859-1?Q?n0EAUFvzSJ2xwQQH75wxHoYl6QLJpAgvPkxQfoGcHJftJDjHTvDGKO44jX?=
 =?iso-8859-1?Q?GAoql2sC7ZgcrktDePJKRZc7zjujMQijoluRTBDAErYjcJHFxtmkGrhBud?=
 =?iso-8859-1?Q?PXwvq9zDVx1Ex/fMhM9fViFr86+c+F8tOLNXq9LjwRzlkPlobBPlwFMBJM?=
 =?iso-8859-1?Q?xTQWsAmd8E1USCu1QlGs9K/TAQTB/XoNFLRjibj07yynmqwR0wl+SR0lx5?=
 =?iso-8859-1?Q?7s9Jgb47Jl7fe9XTL24fqzQcB45INKlzcvaBk4ZfzHvWrqACQTrWUJEf/G?=
 =?iso-8859-1?Q?4Swf57On2wnrgeo3t+dnbwlhhDse1M8xj1Rs3YzToA7zwy6gDyv0SukfK+?=
 =?iso-8859-1?Q?8Ah9Cft5ZszOVp5MNIcQVRMeXAQshQgf4pd/riysgcwW8mVza1I6Z6Gv9p?=
 =?iso-8859-1?Q?xcka/rbpQb+WeHkDlqdx9rf4/VhAFGjXnsd3OiPk8n9K7hbi5/ooobS89L?=
 =?iso-8859-1?Q?Jy7Ld3n7DPO5jecD1066sK8LScAQjShPRfYPuX8Rz+j+mxXy9LCr8BDKXm?=
 =?iso-8859-1?Q?bVrYVL9bPUCiPzYbqFZZ5q08aMUvdazcljuUu0z+p+/ttoFSM+c52/ppBv?=
 =?iso-8859-1?Q?f3fQptOq95+aELG1BNUIXGw9SDFIBLC+l8Ac8eAXhVjI0b6R3SAygU/zg7?=
 =?iso-8859-1?Q?hVmuqUPltncUcNBb2vDfYXbs6KSMCgz3nlI9CBheRfZ5FGXqgz71kfqhUI?=
 =?iso-8859-1?Q?RFXK1sNnj85riXxB1H+fBZKKr/0hcc2x6x12vtxvfBuskuzxjGIburFloO?=
 =?iso-8859-1?Q?CXPFdKPFpk6SY96CnV2NYQhST/SRZe0ks5V9qwLXYe9QbGINI3PJNvs+xw?=
 =?iso-8859-1?Q?e7KdBdQ=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?NY6t1Jw9aE0/bOs6bvGwPNlXeSaqK2fNJoJaWWyKWOf7d55nVdZ0L+ORZE?=
 =?iso-8859-1?Q?yUI+P24LsS197AhLivXgwhvTOLZv/AX0doUoXaMvcMoqTlHQCq1N5T+t+E?=
 =?iso-8859-1?Q?5peEL0WW4mTE/gOqUgu872mWzILdqbUCJk2HkGEcJ+JhMflnu8JGJr5s7P?=
 =?iso-8859-1?Q?n8848PBk9aDaxFwk98oVTrA/3/5L+tkSVAyLniH1qv7kMxL8uB5l8wqc5N?=
 =?iso-8859-1?Q?H3/1Mgc5YoPWZ7nOqWhCsUKTOWIbgbobD7HLWdeevfmnf0/xJi7EXos8qm?=
 =?iso-8859-1?Q?a0weYnns3/kTqe3hnW+8baI0dAMgu1C11K4hzrRnH+GpJDwjCxc+jY1WKr?=
 =?iso-8859-1?Q?zeFf3m07rct0Uj4NK9rmecw81vsxLQlIos5/DBr81OJE9TqqoYJXeFEpfi?=
 =?iso-8859-1?Q?Un10wZNBjasH1T+XMXTU2XTRUfI56gTPx3Y32EyrXDAw/Mw/EOq7YKOXuY?=
 =?iso-8859-1?Q?iaAyjt0PlIEN+0mXF29xI70d73MVB1pr/RO59Uym93zPeDQGMkgRWroTxq?=
 =?iso-8859-1?Q?oVgCgb+ubeTCoRk/AmucdgERFsttrz7R6ssoEWy/RFpZhRmdcCnzWaw/nk?=
 =?iso-8859-1?Q?4855elwN+yJF4093ypy5h7q0ZaumVxTdfYg+HQ8eGZ1td0m4sYV4MBRYkQ?=
 =?iso-8859-1?Q?Xgf5ns/LZm322YSQpRk53VnSI0aRzEucUCB+em+fmEwI3xFR7BNldUk/NH?=
 =?iso-8859-1?Q?Fa1brTtrg+KmYHd4ovDOAMJukBIVhMhxCXvfb+XcsHZLLuFTq4gmootH/K?=
 =?iso-8859-1?Q?hK4vKgzwX0FumQKwiVROaG7wb+S6r+015KWebIx6xM0u0DAP4/1lNPdnB2?=
 =?iso-8859-1?Q?0kXxmvsMdTmdUnDVtDgFoySVooz2mVQBn+ZQXhrUPWvy0NX3985gkfmPTl?=
 =?iso-8859-1?Q?UzcoDwcolv4mHynvgpBY3Iw9PCXKTAGObE5nFlpqWMkoAnxiVG4ZWNO6zf?=
 =?iso-8859-1?Q?zgfmKK5PtIHrOMyPLS9U2e4BO/m2XhfV4Em0P75c3JFzJg1+NokuSCG/i5?=
 =?iso-8859-1?Q?JPuNvDSkK0ZldVx6lBMvcoR//ZHccDduakvegH37Zwey5SSXFnkZuZvrkN?=
 =?iso-8859-1?Q?mgk3zQVzgK4X5MhcOvX/JU87wrx56HyieHhEP/Slkqj8zQjN3B4p/zVYoX?=
 =?iso-8859-1?Q?4OHarTKoSZxSJNu1Q8L6jLTv74yEGfsc7NTpqoN/0yKicg9YgJbKE8gSI4?=
 =?iso-8859-1?Q?j/wOEEjdcocJJJy3uRYLNXFvLIsXjvngHRFzol4GIQFacIs64gshA0wPBx?=
 =?iso-8859-1?Q?z2y54ikexmMIafw5zWJNUFreVAFpgtLYjKhjQKme5SfNSNmWpS0S0xUBlq?=
 =?iso-8859-1?Q?4+96vCl0nXrfQ5TEiHkDcIc6dlLqJPhd0RYavWeTyRWXphcXDvNDz04wS+?=
 =?iso-8859-1?Q?Sph0IQTr4HkRBrv+7jf3S/f15tItoi/bO3GrKkyyiJ+lXGI+ve4qruZurn?=
 =?iso-8859-1?Q?oQkS0Qigbi3ZlOFPr9NFBb99LNEZI1tkEm32TfAHIjAWVVDjUNn+V1CrAu?=
 =?iso-8859-1?Q?s3ny/DcTjg5qZuVm5xEohBBoxNCJh3nPS0Oh4QCgr6hs6z5P2U7g4diwtW?=
 =?iso-8859-1?Q?hgGqLBFKd91bUOSknXPQzh2jCvxUMnLc+1++PLdlS6PVYleB62TuYc7WPA?=
 =?iso-8859-1?Q?1d3Xw2fIyM7c+Uq0FBZsqkGbXg+WUModuRWtASgtbComhCRvlYN9jfpA?=
 =?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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 87ab38af-1eb5-4f90-2e93-08ddf2b09ea2
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2025 10:30:54.5998
 (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: cz4garfWzjOnHbRDGQhzd2MCa3jbKgsCdTE3yKIF3f8YFdkuNw8TzChIanSwfp7ZeedPoujsJ663fXAqgORLlEZPjUGVuOZf9rzO61M/Sco=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6412

Move the SCI (System Control and Management Interface) resource cleanup
earlier in the domain_relinquish_resources() sequence to ensure proper
cleanup ordering during domain destruction.

The SCI cleanup is now performed before TEE (Trusted Execution Environment)
cleanup rather than after P2M mapping cleanup. This reordering ensures that
SCI resources are properly released before other subsystems that might
depend on them are torn down.

This change addresses potential resource cleanup dependencies where SCI
resources need to be released before P2M mappings are cleaned up, preventin=
g
potential issues during domain destruction on ARM platforms with SCI suppor=
t.

Signed-off-by: Oleksii Moisieiev 
---

 xen/arch/arm/domain.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b..0ac381a5a5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct domain *d)
             return ret;
 #endif
=20
+    PROGRESS(sci):
+        ret =3D sci_relinquish_resources(d);
+        if ( ret )
+            return ret;
+
     PROGRESS(tee):
         ret =3D tee_relinquish_resources(d);
         if (ret )
@@ -1109,10 +1114,6 @@ int domain_relinquish_resources(struct domain *d)
         ret =3D relinquish_p2m_mapping(d);
         if ( ret )
             return ret;
-    PROGRESS(sci):
-        ret =3D sci_relinquish_resources(d);
-        if ( ret )
-            return ret;
=20
     PROGRESS(p2m_root):
         /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 10:44:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 10:44:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123132.1466392 (Exim 4.92)
	(envelope-from )
	id 1uxNkM-00050L-G7; Sat, 13 Sep 2025 10:44:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123132.1466392; Sat, 13 Sep 2025 10: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 1uxNkM-00050D-CQ; Sat, 13 Sep 2025 10:44:46 +0000
Received: by outflank-mailman (input) for mailman id 1123132;
 Sat, 13 Sep 2025 10:44: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 1uxNkK-000505-Og
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 10:44:44 +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 a83b80f4-908e-11f0-9d13-b5c5bf9af7f9;
 Sat, 13 Sep 2025 12:44:43 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by VI0PR03MB10855.eurprd03.prod.outlook.com (2603:10a6:800:265::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Sat, 13 Sep
 2025 10:44:39 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9115.018; Sat, 13 Sep 2025
 10:44: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: a83b80f4-908e-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JfEubHy5ELREPkhTtIxg5gN6rqVgeCcOOZveRD2jLAMhIpRcXNEOp0v1qstEjMewVQ6EySUpkvQluiEhPRDMZE2xUGNJ+Ow/RK8CB5zonhvoKjPqwBkhzTVcJk8/mGnJK3tY8vD0t1V//+a6M/EkpET1tEBALw8A0uuiOCjLDjNLgO2dLcciiCQsloxdoCDWavH9nG2bXFOzJLWPq1/PAHLGGIrCkztSgKyiVI+xO60ZKD06R30bRvmzH+odT7d8tRZzeruXX6f4asP/pMIA8ZIMK9n6HrrInu3SfGENUHuh5WApZEZXtPs86LB9BaPW9mPFNxfvmpw+k2tKIA4MRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=61uh5N/uThDNa1TWy+cKskqdhGcAZG1zA83c/tYm0iY=;
 b=OWCJdBHXwKxRAi537jC4ShmllQT58IbKeu7H0hEUIt4c+mEmhqVVsZc7QtB9lWEAee8bLoFkuHu6WlGeFzLxiDjKXybA/noYnagQ33ADcQquAq26D8ZT9cTVVgPmkHb1KKRraXrsEokaYsicpT9IdqzYyCPSX5xqd809Eid/Ml3bndyoYHNUYtJPvbr9GQ1nFvw9cbJHohKXt53yXy0kujkPc3Hqf27REyh4mCyJ7/EW6cBO+w3EEJ3UvOtmrKKpHOa9y7I0PU4d8bLncSAN3FPLjPT3WoQA5xIs4YKqu0qGTr8NTpVrh2UUtdlQJfrrmTwtzW9dCGor4AHF7t5oVw==
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=61uh5N/uThDNa1TWy+cKskqdhGcAZG1zA83c/tYm0iY=;
 b=SxXHOUiP0KYgVYwFDyV+T0jowv7qFyz9gG6fjUvSMP5wf2tLrXvx6y8UEYq2ej8q6O8QyDA+U080CEBRCefAEIgfEcVu4cILxmdHV6+3NwBcui3KqSbLa853G6WC3E43GDrRMyORia33bM8BE8FqS9Zd9azvQHdXs+JFjsk3b9UfLlYZphzrorSgfIyryS/jbE5XGSZgvNygbhjTYADSyBvQRv2OPNmTcUlcSjVWUvCyOWbsDHXUAVOGBW0HyCwyvBKqbBGU2Yvnr+TlaguERHeOZMFkYPSsPjY5GGGOiSNtS1JY16cTT3NboWfS1zRQtqWZJEYx+k7iX9twYkIrvA==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini
	, Oleksii Moisieiev 
Subject: [PATCH] xen/domctl: Fix double domid_free in XEN_DOMCTL_createdomain
 error path
Thread-Topic: [PATCH] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
Thread-Index: AQHcJJtnc9kfi+189ki0+czMQTtF+A==
Date: Sat, 13 Sep 2025 10:44:39 +0000
Message-ID:
 <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|VI0PR03MB10855:EE_
x-ms-office365-filtering-correlation-id: 7dbfced2-b058-484c-50a0-08ddf2b28a68
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?QMwoHkwSTffHXLO+sboQzbywGJNxwLrqMoAN7w/CbY8UG6OU7rq166df0G?=
 =?iso-8859-1?Q?cfvmMWS7WBj9q3tqCmY/IXKJPcrp9hCCHSFHEz7UbBxBbJdm2u0IqT/sC4?=
 =?iso-8859-1?Q?E1cG2ah0ntpqi2aLOY/hJy6z03hIIfX+P97AD9dtE6mqKvymqjhvuUlLv0?=
 =?iso-8859-1?Q?c6xSlv+KlhaSuH8CZh+GIgGqlhs/jlIH2u/jxTyfDz6rWmFKT8Y00Jgl6g?=
 =?iso-8859-1?Q?jSCJD0HHaMhcVFDmDXIWu7Q+WJw8pDSQOuPDqtwKNXXwEKXZPbHMcvKtqK?=
 =?iso-8859-1?Q?FoPS3/oj6fMXc2AkZTA0RgsepzVN07rGt4oQCwftATsAbrIeOaGLAih32G?=
 =?iso-8859-1?Q?rAcHuVLNW3JTZokIiNK3cyE8Y15QAVX+KGfTQUSGoR2+PigQLxMbvlS9AI?=
 =?iso-8859-1?Q?cqFJM/CSoDV2b5FrChEN3UmKBjcrfgQ82sam2dpcTOJh1fjX7CidnRZPFT?=
 =?iso-8859-1?Q?sUE0xQcz/LK7vAV+CIP7xpZdjLKXnrLQ5SEfsWqVSjqVlN6Rn9WygTSZOf?=
 =?iso-8859-1?Q?FLYLSnkmPvY8RA95xgp9IHYIZwCyZCp1m6hL5R7joEX8ILWJzwmMUTOBr6?=
 =?iso-8859-1?Q?yz0x9Lb0PiNni5tvKnplemRLc8H3zFbEjM/r3Uy5fixDK2vDJxBP9k/PS+?=
 =?iso-8859-1?Q?0wzudYlaoy6HpnaKynFPTteLnXSKLCxnn4R5UzEhIoJ/NlR0/jyh/fFcpd?=
 =?iso-8859-1?Q?hajhqDvyYTjpYQ+p3rJ+xJVZmWKWHhTsIn3BqjoYz1sewJkiwFapKA2+RI?=
 =?iso-8859-1?Q?VNDcJDlEbd/xMD4Q4bjTKx2UXpL60T4EHTsV7x1i2jZlvP16Xb4fAOvrjF?=
 =?iso-8859-1?Q?huURrsghHTed0RH0+d/kMi6HO4DVmmelEQ64N/21M6H2yncUDmfwJx41il?=
 =?iso-8859-1?Q?o2256adgGHSgWUXrKUmw2x44P2zTsouxpDpgFGw/SZx5cB2gSyyXxEPs7A?=
 =?iso-8859-1?Q?HtlFaHIrERCHJA22yrshfVoRp8AkRzPX2RjYKT5voZSkkaJhw0QDm4JVM2?=
 =?iso-8859-1?Q?a3SUD3BoYD2kDd2EiJQCzg+uPV+/BJkpjoSmFojHoBjc+ku6w7RwStm1I0?=
 =?iso-8859-1?Q?mQQaQ7baDozsfNvi7d1woLi8bcZbzkEz6aqmjFsEE6GSGF4PNCkCl09ouV?=
 =?iso-8859-1?Q?H+FFeWLRabTmPYi7GGdhxkjXzQd4hx96yoQlRQi0NRvvPpN4IVDOCs98Wo?=
 =?iso-8859-1?Q?8O9bUJlvsAVGRUvny24wOvznbFelCkrdkj6/RPOfR0QpRtTLJftsJLz875?=
 =?iso-8859-1?Q?Ny6oPsQIB4Ae2ZDFzvLqcvwgIqGXVo4qGHa7DOF/Xc33ztaEFU0HV3RYwL?=
 =?iso-8859-1?Q?SlVUiMz7+PaIZeMCZAMJlmR4xVFNuyLgTuadKN/fbLLdss3rXDGJA54t2L?=
 =?iso-8859-1?Q?cKFid3SZD93fC8oxMtfo6Kuv4PqQ6iUYNYDHozf0jalcv6oXmLThI/VQmj?=
 =?iso-8859-1?Q?4TzVz4wuZjTL6kwHFequKsnZ4BKTKVAiwXuC26tcZx7EBqd5GyyofQAmtx?=
 =?iso-8859-1?Q?hjKG0DkHVfo0JAmt14kfdioZrREXzoIg0iH2JENHKuXStcOzfxVnx9f01A?=
 =?iso-8859-1?Q?JGqq38E=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?znMq04nmhh51JaGDq9Ipt6UGab0UJaBt45SGAFW+J/mSLZczdGSnbYbSrv?=
 =?iso-8859-1?Q?JY3oD4TuMPX+yNho2CmozPgmxeNmSnF/Um5Z68g8aG3Y1WR8yGgZmB0VJy?=
 =?iso-8859-1?Q?DSnxsS4m2FRnJ3hkhzfcQNPAc3blfFCai8snD96fw5iEbCpjGzXToJfG+P?=
 =?iso-8859-1?Q?mmCERuPrAG7rgaBP+NRlZsnkHoM4Y+Er8Fx9HBEEcUUCg7xu3vDagI1Grk?=
 =?iso-8859-1?Q?U1iOwO6mFIG4nTC3pQuRz76srHwSkYkr9f28dtQzBTox7/VOHjZ7UKkiRR?=
 =?iso-8859-1?Q?xgHLwCJZIpIrIWBESFr4E+PWp6150gV9mvyDboBA9R/NXo0gB0HEjY/ybb?=
 =?iso-8859-1?Q?jrfQGUchHwq2k76eY5SNi0/hC58KQjI11I2BPpiK8By7fEJ7doPBB1DsRi?=
 =?iso-8859-1?Q?ItYf7VydzFrHc7ol8EEIOY662ifiIhooaoDmsAEC1Q3c/UghvcJaWl5cgp?=
 =?iso-8859-1?Q?7frKcOsDe+hc0Qu/cCaCmsnjGMDXA1RyxBpcEnOx7rnDX7oCLS/JvDecox?=
 =?iso-8859-1?Q?19n1dgsi8pIGN0yPNxxchhvtxjs2uuAIpOOU7lrtQnJwgOZBsWa35H/zWQ?=
 =?iso-8859-1?Q?G/rjizr25U+nMGUs5uQYP1zERgwEVwnzSRXhlIhovjiMmA88PgdTmQaw70?=
 =?iso-8859-1?Q?WENat3QZqL8qFAdHecp0py0wfftyOjKZjnwfUtqdMrVOxlWtlZa0uv9gyE?=
 =?iso-8859-1?Q?t+SJzLtMy6HSlcAx4mIHZOLNf4gnPikj2hYD7a9B39KI8SdN6bSoGzKTvx?=
 =?iso-8859-1?Q?2jKiG8AquJMFazGGQo+s0k7rlPunJk+/bhTWFvEuhjqo63LJTe9ccuTMl6?=
 =?iso-8859-1?Q?EqCYO75bwaBEG2qvvvgDmQuF8JdaEkPPYReDdXJSwX6acphSjcLZPH0pPP?=
 =?iso-8859-1?Q?5JWFjbUfna/A87Ld3sFTsKxwaCNDU4TVDpFSNZoECXETwAHEAEbFNpfNy6?=
 =?iso-8859-1?Q?0z3dvcZnPA+5GYDreShkVKJGurwUEXrwfOVM/RsRtjcmSunrXVLBmwVIcF?=
 =?iso-8859-1?Q?4jGCWtmqazB06XtVeW7DuH78Ilo+FOJ48+p2nBT9ZXf/MFI+gpGRLv839p?=
 =?iso-8859-1?Q?DLc23KeFNczp05jSe5nq2n34J2y1bIumlegpMgot5kWA5lpl/bP/UH17+r?=
 =?iso-8859-1?Q?S0QT6r7y9DvxFHOSHpthF6+uZwzxZ6iYrrsPUy+3Qf+pB67nYNBtGz44Ct?=
 =?iso-8859-1?Q?vWWuRJRLsinmUvc9NR7fYUMCgbGfBPdDAlq2k/gTMPojOeDjetwDxhy2O6?=
 =?iso-8859-1?Q?1MPHgy02TmOVweEKi4wwq+xag7n8oSrh3j3hxM46JX9dTJlJYiwaQdNhoR?=
 =?iso-8859-1?Q?DQbsc9ox3GjhGJRBuoNiN1HekFFxgFvjzNDDF22ijDyvujHLhky/Zefrl4?=
 =?iso-8859-1?Q?9/05RfBd8mg8EKDjhhXcDnJeU+3Kjs2+eDyUApoO/qL2k4SsHN92XJ6pev?=
 =?iso-8859-1?Q?dz+xP0ErPt6ln7dMIfd0pr2hBPOi2pVmLcs6O5bwyTr5FyyY6eaXl8jK5Z?=
 =?iso-8859-1?Q?QbBCwOQhtozMtgqq6F5zphQtSESDznTrYcxNw7hvEnyQr5+5bk7HJAnmIw?=
 =?iso-8859-1?Q?sxM+8XYocjtrjVYdXBHPopBPL/OBaQwkgsIt4csnR0ny+EgTwMpZ+F+fJs?=
 =?iso-8859-1?Q?mQK2Q0LdoSJUCQLPRy73ahkS4AOl+gp6B/gIFeGPDq8iy5lMWG6eYEdg?=
 =?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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7dbfced2-b058-484c-50a0-08ddf2b28a68
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2025 10:44:39.6395
 (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: jqk3ylImYLd2HcKBZ+EmRh70t349FaojTkpo0A5h+6lHVQXApb+WfsavKuYOy/P/+YLR9IKKTvNbPrD7FBgaDKszHpIzjtIGQD7YsZhfnaI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10855

Remove redundant domid_free() call in the XEN_DOMCTL_createdomain error
handling path to prevent a double-free condition.

When domain_create() fails, it internally calls _domain_destroy() during
its cleanup routine, which already invokes domid_free() to release the
allocated domain ID. The additional domid_free() call in the domctl error
path creates a double-free scenario, triggering an assertion failure in
domid.c:

    Assertion 'rc' failed at common/domid.c:84

The domain creation flow is:
1. domid_alloc() allocates a domain ID
2. domain_create() is called with the allocated ID
3. If domain_create() fails:
   a) domain_create() calls _domain_destroy() internally
   b) _domain_destroy() calls domid_free() to release the ID
   c) domctl incorrectly calls domid_free() again

This double-free violates the domain ID management invariants and causes
system instability. The fix ensures domid_free() is called exactly once
per allocated domain ID, maintaining proper resource cleanup
semantics.

Signed-off-by: Oleksii Moisieiev 
---

 xen/common/domctl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 71e712c1f3..954d790226 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -421,7 +421,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_d=
omctl)
         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;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 11:56:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 11:56:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123184.1466402 (Exim 4.92)
	(envelope-from )
	id 1uxOrQ-0005Fw-JJ; Sat, 13 Sep 2025 11:56:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123184.1466402; Sat, 13 Sep 2025 11:56: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 1uxOrQ-0005Fp-Fv; Sat, 13 Sep 2025 11:56:08 +0000
Received: by outflank-mailman (input) for mailman id 1123184;
 Sat, 13 Sep 2025 11:56: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 1uxOrO-0005FN-JM
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 11:56:06 +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 a09abb86-9098-11f0-9d13-b5c5bf9af7f9;
 Sat, 13 Sep 2025 13:56:05 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-45de56a042dso17216085e9.3
 for ; Sat, 13 Sep 2025 04:56:05 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45f29174de1sm10869425e9.2.2025.09.13.04.56.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 04:56: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: a09abb86-9098-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757764565; x=1758369365; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YVwhMoFe1PU4VrHRnseDMYfClY1TX/o63ebu+sBig8s=;
        b=bU4n1px1Wf1HqR0kHYHYxmXTfZQ37/JBfxZiifxBZfVCM0yWR2M+evidYdt3M2E5aD
         fRm294NQhZPOpM5JZVaopBXufJBU6INSz/RTKx5KgxlkT/vSTYPvDDt9C9hEfNRMnDa8
         TFsXZbTmHhc6XqKY/elUYUwEqd5J4441pjzWE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757764565; x=1758369365;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YVwhMoFe1PU4VrHRnseDMYfClY1TX/o63ebu+sBig8s=;
        b=waTNVquDMbXkgg7s5KM/+z7X05LCXf9ZcqsYuC9RoxIoMKfARrI/1NHYYc4QLGEpTq
         jvYDoU3nDCZcrgiY1SnSa7l1WKS47nM/rbFDZhLP6NINjX9KA2uO9u2xBEoO0kg3eANO
         eeCkmBYAvXtTAu9knw7EPEQtpsLEPVvOfsTs+9bWifrQhPSurYaD6bX92IDIJkY3yP/J
         l+zm1e90Dcs8biUn1/9mijX4N7XYkNAU7IXfiKpKGNCPYCnsd/AnufSG+q7mc1Ac+Zs8
         DchrTukBeLOb0zcdIYYanDB01eEH1jcbK43Cu3Q5nMhU6nF/xnL1oGIN/Ozirsz8YXVk
         /pMQ==
X-Forwarded-Encrypted: i=1; AJvYcCWfI1hRJ2QIdkBgL9+hYjD7G1wQjwujypGZsdNLXwPrX0wti0QgaOQE4elPny5OpI0eAsnj9e+dmP0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWkyTbJrwm+ESz7KO0SE9OsoRvmFuOgfKOCmWxd1wKQVEJnyTg
	vOIZdAeZl5PjcxGtrI0JomKSCs24jeH02pyIlRd0RuaE90SEhyRZCjc7qydqCqyJCPM=
X-Gm-Gg: ASbGncv217rYm18Jf+pzoQzNMW583TUmd1zTz0R0Tych2N8Eu09NbPuUVNt8nQ8yCC4
	leOACJHLcjag6XDl11QipD8IFC5Xd4SHjYFfH0xKL3NT+Y6CYEPYaRfGBKQofrJ5OvjDTE/S6by
	2qxX4huY5Ffa0bdQ1GbGhwTycXEHz7uYc+Uf5SJgichADiro2i4+2c3Wjx7aqr1I/pawreCK2PM
	2jg1z34iAeo8jV2EnB1pxUBrW7tFZmUbwcd5zpUZu6DZ5cjKLLSqlMYqKqEiVbyEJEpXj2ohsfo
	uc2jbO5TUBY3CZuxHRYzPjNVbU2QduxeRoGVyBCybB+tmQkecNySw0Q2Zc+jOsmO9SswFvuocnR
	bD+nnx7M+eaJAnU7Ofudjwps40mMvLD3OqbGhusdNilKmZt4azEvgZdV5fSTadsKmOF2I
X-Google-Smtp-Source: AGHT+IFMpVubaQB1SxParmZlHPl++SyKaXtezFsGGOZXZj/NAFjcZbavjHGLfPGVnddGQZXaBWVC6g==
X-Received: by 2002:a05:600c:4691:b0:45f:28d5:fae with SMTP id 5b1f17b1804b1-45f28d511f7mr10557045e9.4.1757764564593;
        Sat, 13 Sep 2025 04:56:04 -0700 (PDT)
Message-ID: <3ba29020-3a9b-4e10-8523-82bfb63482f6@citrix.com>
Date: Sat, 13 Sep 2025 12:56:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
To: Oleksii Moisieiev ,
 "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: <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/09/2025 11:44 am, Oleksii Moisieiev wrote:
> Remove redundant domid_free() call in the XEN_DOMCTL_createdomain error
> handling path to prevent a double-free condition.
>
> When domain_create() fails, it internally calls _domain_destroy() during
> its cleanup routine, which already invokes domid_free() to release the
> allocated domain ID. The additional domid_free() call in the domctl error
> path creates a double-free scenario, triggering an assertion failure in
> domid.c:
>
>     Assertion 'rc' failed at common/domid.c:84
>
> The domain creation flow is:
> 1. domid_alloc() allocates a domain ID
> 2. domain_create() is called with the allocated ID
> 3. If domain_create() fails:
>    a) domain_create() calls _domain_destroy() internally
>    b) _domain_destroy() calls domid_free() to release the ID
>    c) domctl incorrectly calls domid_free() again
>
> This double-free violates the domain ID management invariants and causes
> system instability. The fix ensures domid_free() is called exactly once
> per allocated domain ID, maintaining proper resource cleanup
> semantics.

Fixes: 2d5065060710 ("xen/domain: unify domain ID allocation")

> Signed-off-by: Oleksii Moisieiev 

Reviewed-by: Andrew Cooper 

the tl;dr is that domain_create() either inserts the domain into the
domlist, or cleans up after itself.

The domid alloc infrastructure is problematic in multiple ways, not
least because it now means there are two sources of truth for which
domain's exist, and they are not interlocked.

I would have blocked this from being committed if I'd had any time to
look at it.  It will need remediating one way or another before 4.21
goes out.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 14:08:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 14:08:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123297.1466415 (Exim 4.92)
	(envelope-from )
	id 1uxQuv-0003h4-JE; Sat, 13 Sep 2025 14:07:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123297.1466415; Sat, 13 Sep 2025 14:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxQuv-0003gx-G3; Sat, 13 Sep 2025 14:07:53 +0000
Received: by outflank-mailman (input) for mailman id 1123297;
 Sat, 13 Sep 2025 14:07: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 1uxQuu-0003gr-Ip
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 14:07:52 +0000
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com
 [2607:f8b0:4864:20::d36])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 07f99544-90ab-11f0-9809-7dc792cee155;
 Sat, 13 Sep 2025 16:07:50 +0200 (CEST)
Received: by mail-io1-xd36.google.com with SMTP id
 ca18e2360f4ac-887764c2834so169282439f.1
 for ; Sat, 13 Sep 2025 07:07: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: 07f99544-90ab-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757772469; x=1758377269; 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=M3PsKtcxHDBTZqejD/5uhh+ObuTl+eI1gWgG9+w7CQo=;
        b=MjawJm2xmy+mWzHqV4UjVd6MYclZMBwryvW13n8xFXzbL8xNuuzfNC2VhMgokWcwO0
         JB9mNeI/rbvxFk2twBx9C/vCebl3T1D3W4wQTC2zx5IRQKqN6nmCm0Fi9dhvlN/WYOiD
         EADq5KCZ1pfl21tP5cn/fNovCz4pqiOHoT3JYOyWrtXsUhYc11hoPHMuMyI4B+GKYUUJ
         c7+3sfFl9DAtaRKZVqkizMfp1E07NBE5eNNp0Txq9Xigwol1hq+u0IWWRGzKPs+7nUlm
         s99PGjkIf+ltnlWHj2WMoGL9QZvRUvVO943U8VE8Vwn3Je1mMQ1PH3X5zuUr0FI5sLxM
         77Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757772469; x=1758377269;
        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=M3PsKtcxHDBTZqejD/5uhh+ObuTl+eI1gWgG9+w7CQo=;
        b=Rtnd+58iKFDwFe/1AaAjzab9jgItsgzASVB1q/80J/wkV6GeVE7nQsP7JS/3c85Mr6
         UbrHQQ7WwcIBE7Jc2p0I9yaeSjXUoBpIOXOziY9P4Z5pPLkGjVPJJ+ADbDaN/lGaiydx
         EiSFXS/dJwwzP5mFaWja7dw1LkrY/oq0rjlmBUfNKFZGeJa75ZHT8r5+YVRqFuvOeBdT
         RmJUm8QYLby8iXow8wGbtIHprzARHrnr3UxSYQ+e+siPSY2vVAMCRroYA6R1090eIWkd
         i6QZcoWkjzPFCwDvlK+PfbhonkpcL78g3gir5FSZ0S1cieMCPz1lnMhzUdEJyC5Ownf5
         ziww==
X-Gm-Message-State: AOJu0YxRjiuaJAl3V4J8DyjNUghoNGE/O5LicuC2xx+wl8uC/5FXqdQ1
	t6u+VnUi0Av+kU+rLYgQm3jnxPQxwLjWt5ia5L4lGrIPeSPV6ZTnhR3tq7giteEruvl51OJ43Fm
	qbRdscwVE/GZ9o7XAtAuF9RBNtXI1kBg=
X-Gm-Gg: ASbGncuF+Nhdw5zmaMamQCL4loonoVE2yYLFvmIeOjqjaAn3NGYoIf5+u0SpPD9A7Xd
	+p45vFqLojmMD2NN+JBvL4QeptgtdmYTbtwlrrry2N0qk66IXFnhFE5wDwWPmOEdOG+9lObaZBJ
	GCi73DGQHTPLu4UnfLvICKoDWeHfmYsURCfGKM5Lft9j3ES4vENOemdI9CTgllciD/7YHMxVEJV
	PnpSfc=
X-Google-Smtp-Source: AGHT+IF89tmQegCh6KAMDjdGA+TabGB+hc+yDdmhYIA9SYQsEnlna6Q8sqIe5NtrTdKlPEYGjaC7lPhF/dRnKmNMLB0=
X-Received: by 2002:a05:6602:2ccf:b0:88d:69d4:39b4 with SMTP id
 ca18e2360f4ac-890351aeffdmr794069639f.18.1757772465398; Sat, 13 Sep 2025
 07:07:45 -0700 (PDT)
MIME-Version: 1.0
References: <164651d0662e674002ed17399300c3a25e6dcbfc.1757757602.git.oleksii_moisieiev@epam.com>
In-Reply-To: <164651d0662e674002ed17399300c3a25e6dcbfc.1757757602.git.oleksii_moisieiev@epam.com>
From: Oleksandr Tyshchenko 
Date: Sat, 13 Sep 2025 17:07:34 +0300
X-Gm-Features: Ac12FXwCyXiBCi50rT6fK1r8TQptK4hLc4L4nnyZXEDCLJO6_Ko1cLbg4Q5Tztg
Message-ID: 
Subject: Re: [PATCH][for-4.21] xen/arm: Reorder SCI resource cleanup in domain destruction
To: Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" , 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk 
Content-Type: multipart/alternative; boundary="000000000000657449063eaf4bcc"

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

On Sat, Sep 13, 2025 at 1:31=E2=80=AFPM Oleksii Moisieiev <
Oleksii_Moisieiev@epam.com> wrote:

Hello Oleksii

Move the SCI (System Control and Management Interface) resource cleanup
> earlier in the domain_relinquish_resources() sequence to ensure proper
> cleanup ordering during domain destruction.
>
> The SCI cleanup is now performed before TEE (Trusted Execution Environmen=
t)
> cleanup rather than after P2M mapping cleanup. This reordering ensures th=
at
> SCI resources are properly released before other subsystems that might
> depend on them are torn down.
>
> This change addresses potential resource cleanup dependencies where SCI
> resources need to be released before P2M mappings are cleaned up,
> preventing
> potential issues during domain destruction on ARM platforms with SCI
> support.
>
> Signed-off-by: Oleksii Moisieiev 
> ---
>
>  xen/arch/arm/domain.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 1a8585d02b..0ac381a5a5 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct domain *d)
>              return ret;
>  #endif
>

There is an enum above (not visible in context)

enum {
     PROG_pci =3D 1,
     PROG_tee,
     PROG_xen,
     PROG_page,
     PROG_mapping,
     PROG_p2m_root,
     PROG_p2m,
     PROG_p2m_pool,
     PROG_sci,
     PROG_done,
};

I am sorry, but shouldn't PROG_sci location there reflect to where you now
put PROGRESS(sci)
(I mean above PROG_tee)?



> +    PROGRESS(sci):
> +        ret =3D sci_relinquish_resources(d);
> +        if ( ret )
> +            return ret;
> +
>      PROGRESS(tee):
>          ret =3D tee_relinquish_resources(d);
>          if (ret )
> @@ -1109,10 +1114,6 @@ int domain_relinquish_resources(struct domain *d)
>          ret =3D relinquish_p2m_mapping(d);
>          if ( ret )
>              return ret;
> -    PROGRESS(sci):
> -        ret =3D sci_relinquish_resources(d);
> -        if ( ret )
> -            return ret;
>
>      PROGRESS(p2m_root):
>          /*
> --
> 2.34.1
>
>

--=20
Regards,

Oleksandr Tyshchenko

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




On Sat, Sep 13,=
 2025 at 1:31=E2=80=AFPM Oleksii Moisieiev <Oleksii_Moisieiev@epam.com> wrote:

Hello O=
leksii

Move the SCI (System Control and Managem=
ent Interface) resource cleanup

earlier in the domain_relinquish_resources() sequence to ensure proper

cleanup ordering during domain destruction.



The SCI cleanup is now performed before TEE (Trusted Execution Environment)=


cleanup rather than after P2M mapping cleanup. This reordering ensures that=


SCI resources are properly released before other subsystems that might

depend on them are torn down.



This change addresses potential resource cleanup dependencies where SCI

resources need to be released before P2M mappings are cleaned up, preventin=
g

potential issues during domain destruction on ARM platforms with SCI suppor=
t.



Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>

---



=C2=A0xen/arch/arm/domain.c | 9 +++++----

=C2=A01 file changed, 5 insertions(+), 4 deletions(-)



diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c

index 1a8585d02b..0ac381a5a5 100644

--- a/xen/arch/arm/domain.c

+++ b/xen/arch/arm/domain.c

@@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct domain *d)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ret;

=C2=A0#endif

There is an enum above (no=
t visible in context)

enum {
=C2=A0 =C2=A0 =C2=
=A0PROG_pci =3D 1,
=C2=A0 =C2=A0 =C2=A0PROG_tee,
=C2=A0 =C2=A0 =C2=A0=
PROG_xen,
=C2=A0 =C2=A0 =C2=A0PROG_page,
=C2=A0 =C2=A0 =C2=A0PROG_map=
ping,
=C2=A0 =C2=A0 =C2=A0PROG_p2m_root,
=C2=A0 =C2=A0 =C2=A0PROG_p2m=
,
=C2=A0 =C2=A0 =C2=A0PROG_p2m_pool,
=C2=A0 =C2=A0 =C2=A0PROG_sci,=C2=A0 =C2=A0 =C2=A0PROG_done,
};

I am sorry, =
but shouldn't PROG_sci location there reflect to where you now put PROG=
RESS(sci)
(I mean above PROG_tee)?
=C2=A0



+=C2=A0 =C2=A0 PROGRESS(sci):

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D sci_relinquish_resources(d);

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( ret )

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ret;

+

=C2=A0 =C2=A0 =C2=A0PROGRESS(tee):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D tee_relinquish_resources(d);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (ret )

@@ -1109,10 +1114,6 @@ int domain_relinquish_resources(struct domain *d)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D relinquish_p2m_mapping(d);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ( ret )

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ret;

-=C2=A0 =C2=A0 PROGRESS(sci):

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D sci_relinquish_resources(d);

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( ret )

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ret;



=C2=A0 =C2=A0 =C2=A0PROGRESS(p2m_root):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*

-- 

2.34.1






-- 
Regards,

Oleksandr Tyshchenk=
o


--000000000000657449063eaf4bcc--


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 14:44:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 14:44:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123325.1466430 (Exim 4.92)
	(envelope-from )
	id 1uxRUU-0000E4-8W; Sat, 13 Sep 2025 14:44:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123325.1466430; Sat, 13 Sep 2025 14: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 1uxRUU-0000Dv-5u; Sat, 13 Sep 2025 14:44:38 +0000
Received: by outflank-mailman (input) for mailman id 1123325;
 Sat, 13 Sep 2025 14: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 1uxRUS-0000Dm-IR
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 14:44:36 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 254b1c47-90b0-11f0-9809-7dc792cee155;
 Sat, 13 Sep 2025 16:44:26 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3e7636aa65fso2194148f8f.1
 for ; Sat, 13 Sep 2025 07:44:26 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e01578272sm109003395e9.9.2025.09.13.07.44.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 07:44: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: 254b1c47-90b0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1757774666; x=1758379466; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=w0fR/zVOW7BvlafCNVW2z+aApS6CRvAACmRmwWLbDX0=;
        b=GvzmJRHn9WgQriuIeYLb+eQeMDiGkKnvBFym7/rHakDdCI5qiFRTbDmXP2DkaLnFQ3
         W6m0IjYh9CPKomp2qguEHIMwJSNc0Bl8hv9NxsNk21ghjlk78/vw9cvDbeyrIHTSdq0y
         ocs0AnQJ9MBAm3+kK531BYsYdATq6JrjNNlPg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757774666; x=1758379466;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w0fR/zVOW7BvlafCNVW2z+aApS6CRvAACmRmwWLbDX0=;
        b=UQ5t0atMJnrGJ1p3SZuvQbeqWGd1Jrz8x2twTUa4wWV9Bgpuy4DHKk/5k35bK7favr
         qzQca5qWxPyFQ6SMSwViU9mhj0EpH7tH8as2OtNSs17aj7yvlHuQcjdgcVfz2h4R/h5W
         a5I6k97CgFXYd0ibjP/sbwL7xL7bc4cF1sLqBEdVq79HK7t+U37SYDnT7TpoEbClhuxI
         g64IhMlCGLBMOvEuN1b3CtQw4C8OWW+D7S7R1uZ0pLxT10Uda0u0bKRSx458dF6eli1h
         ML5gG3mg02XpQdDUJ4VmHKlvKqxVl7XOpEGbbjigXduEr0R5zD4exnQMsW20NM4/1hRY
         XNZg==
X-Gm-Message-State: AOJu0Yyf6cHPdkngl6G2rXPc2buDYu0o7O1arUyLHVQgiF9JJCcAaLdc
	/eMf2hfPa4Nfuw7gFuzX6j4H5gcNoUN9Q5Z75LpYM/ykX5XaevHAePMGSa7E42y1NPs=
X-Gm-Gg: ASbGncsebRSWaq4WzSXzAsNnUQy+KgL/+7rwrVZG+bW5iqT9Wbe1wLOyhQ4248Dnv/g
	jWX9UtwP0ZMFdCiQb3gXKNfbqEfZ6aw+P3on9fncW34AgB5gzNGzwrT051VudoIPrlnA5oSxM2C
	wr7LpLdf9H74QU+quM2b0m5/yQ4xOImkUdLlimsTOPfZ4Z2VXty0CynEROS3A5mDNrGSb43P78Z
	iu6zNYph/IPRonAubMdkkCP+LH6svsio0cr9zZF5xTVbtmBgSdGhuP17993A56NO1nrfJTN6mkK
	70dWaDti4sR8HZqzP2GHRGsZWzd1gnO9U+wFmQeE3oj3CMenVvQyaU8Ed9mlAuiyX0lKehy9ePr
	eRowBupo+DIt2sYRYhzwNuh3liMnK8mrO/LNHjAf4gJ9/6XtjMQFTJMx4kAiL6Hk1wXBZlnbHZU
	fH4Qw=
X-Google-Smtp-Source: AGHT+IFKXTqhzWrdcaKtUFPfyePQTP4SRBVmpQ+6MevEtR/qPjd0hgaAXMwFjj9SH1y557/w5jnHrg==
X-Received: by 2002:a05:6000:22c3:b0:3e2:fcba:915b with SMTP id ffacd0b85a97d-3e765a2e03fmr5376909f8f.32.1757774665627;
        Sat, 13 Sep 2025 07:44:25 -0700 (PDT)
Message-ID: 
Date: Sat, 13 Sep 2025 15:44:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH][for-4.21] xen/arm: Reorder SCI resource cleanup in domain
 destruction
To: Oleksandr Tyshchenko ,
 Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <164651d0662e674002ed17399300c3a25e6dcbfc.1757757602.git.oleksii_moisieiev@epam.com>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/09/2025 3:07 pm, Oleksandr Tyshchenko wrote:
>
>
> On Sat, Sep 13, 2025 at 1:31 PM Oleksii Moisieiev
>  wrote:
>
> Hello Oleksii
>
>     Move the SCI (System Control and Management Interface) resource
>     cleanup
>     earlier in the domain_relinquish_resources() sequence to ensure proper
>     cleanup ordering during domain destruction.
>
>     The SCI cleanup is now performed before TEE (Trusted Execution
>     Environment)
>     cleanup rather than after P2M mapping cleanup. This reordering
>     ensures that
>     SCI resources are properly released before other subsystems that might
>     depend on them are torn down.
>
>     This change addresses potential resource cleanup dependencies
>     where SCI
>     resources need to be released before P2M mappings are cleaned up,
>     preventing
>     potential issues during domain destruction on ARM platforms with
>     SCI support.
>
>     Signed-off-by: Oleksii Moisieiev 
>     ---
>
>      xen/arch/arm/domain.c | 9 +++++----
>      1 file changed, 5 insertions(+), 4 deletions(-)
>
>     diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>     index 1a8585d02b..0ac381a5a5 100644
>     --- a/xen/arch/arm/domain.c
>     +++ b/xen/arch/arm/domain.c
>     @@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct
>     domain *d)
>                  return ret;
>      #endif
>
>
> There is an enum above (not visible in context)
>
> enum {
>      PROG_pci = 1,
>      PROG_tee,
>      PROG_xen,
>      PROG_page,
>      PROG_mapping,
>      PROG_p2m_root,
>      PROG_p2m,
>      PROG_p2m_pool,
>      PROG_sci,
>      PROG_done,
> };
>
> I am sorry, but shouldn't PROG_sci location there reflect to where you
> now put PROGRESS(sci)
> (I mean above PROG_tee)?

The enumeration can be in any order.  All they're actually doing is
encoding which case label to use next time.

But, for people's sanity following the logic, they ought to be kept in
order.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 16:47:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 16:47:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123395.1466440 (Exim 4.92)
	(envelope-from )
	id 1uxTPP-0006ht-H5; Sat, 13 Sep 2025 16:47:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123395.1466440; Sat, 13 Sep 2025 16:47: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 1uxTPP-0006hl-BX; Sat, 13 Sep 2025 16:47:31 +0000
Received: by outflank-mailman (input) for mailman id 1123395;
 Sat, 13 Sep 2025 16:47:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxTPO-0006hf-Ce
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 16:47:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxTPN-0087u3-0o;
 Sat, 13 Sep 2025 16:47:29 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uxTPN-007JXH-0G;
 Sat, 13 Sep 2025 16: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=nk+a4Zm09MRHh8ilMQeOdDzCAbcGfTh80Z4xo3A5uLk=; b=
	eaxup+O+P6saiitEUPvYJ9b3eDU1yuYNV9rsiDfLlZGeKqlYkVFUvuvGOjifrZKIVDkObnHsko1fJ
	NpnROrJQmADGyjp9tyCC5BJEjpPrKdMbGUuxCC0ZVYGrIbxO1zrBhRM/rayE7w2KtBJwnhM7/pw5B
	41l3671s2c8uV6jig=;
From: dmukhin@xen.org
Date: Sat, 13 Sep 2025 09:47:27 -0700
To: Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini 
Subject: Re: [PATCH] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
Message-ID: 
References: <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>

On Sat, Sep 13, 2025 at 10:44:39AM +0000, Oleksii Moisieiev wrote:
> Remove redundant domid_free() call in the XEN_DOMCTL_createdomain error
> handling path to prevent a double-free condition.
> 
> When domain_create() fails, it internally calls _domain_destroy() during
> its cleanup routine, which already invokes domid_free() to release the
> allocated domain ID. The additional domid_free() call in the domctl error
> path creates a double-free scenario, triggering an assertion failure in
> domid.c:
> 
>     Assertion 'rc' failed at common/domid.c:84
> 
> The domain creation flow is:
> 1. domid_alloc() allocates a domain ID
> 2. domain_create() is called with the allocated ID
> 3. If domain_create() fails:
>    a) domain_create() calls _domain_destroy() internally
>    b) _domain_destroy() calls domid_free() to release the ID
>    c) domctl incorrectly calls domid_free() again
> 
> This double-free violates the domain ID management invariants and causes
> system instability. The fix ensures domid_free() is called exactly once
> per allocated domain ID, maintaining proper resource cleanup
> semantics.
> 
> Signed-off-by: Oleksii Moisieiev 

Thanks a quick fix and sorry for the breakage.

--
Denis


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 17:29:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 17:29:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123420.1466449 (Exim 4.92)
	(envelope-from )
	id 1uxU4L-0003Fb-Do; Sat, 13 Sep 2025 17:29:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123420.1466449; Sat, 13 Sep 2025 17: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 1uxU4L-0003FU-BE; Sat, 13 Sep 2025 17:29:49 +0000
Received: by outflank-mailman (input) for mailman id 1123420;
 Sat, 13 Sep 2025 17:29:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxU4J-0003FO-I5
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 17:29:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxU4I-0088gY-18;
 Sat, 13 Sep 2025 17:29:46 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uxU4I-007Rop-00;
 Sat, 13 Sep 2025 17: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=OzsW1yzoLTy+K+CunPLCOmn64If/Y4aeaubQAog79Xw=; b=
	xsU50lrDkk/cYqkCNJISuiubMMUg62bQs0oUmnvouiwUvNaPMZc7Hw6OlsHJAMnwoYaDlOir+dI4K
	s/ZbR5FcuQgVM7sQ+gK9HMl6hTeLiFWEZxFKHk6lwLfZAJPVV8+w+9fRDOf145o1KxOov4k5LYYdH
	uzmiQ2TxfO+pkmNyc=;
From: dmukhin@xen.org
Date: Sat, 13 Sep 2025 10:29:44 -0700
To: Mykola Kvach 
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 v7 03/16] emul/ns16x50: implement emulator stub
Message-ID: 
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-4-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Wed, Sep 10, 2025 at 01:05:13PM +0300, Mykola Kvach wrote:
[..]
> >
> > +/* Enable NS16550 emulator for certain domain only. */
> > +static int __read_mostly opt_vuart_domid = -1;
> 
> Should opt_vuart_domid be initialized to DOMID_INVALID instead of -1?
> Using the standard DOMID_INVALID constant would make the intent clearer
> and avoid potential confusion with valid domain IDs.
> ---
> Should the variable type be domid_t or at least unsigned?

Yes, absolutely; thanks.

> 
> > +
> > +#ifdef CONFIG_VUART_NS16X50
> > +static int __read_mostly opt_vuart_id;
> > +static int __init cf_check parse_vuart_param(const char *s)
> > +{
> > +    if ( !isdigit(*s) )
> > +        return -EINVAL;
> > +
> > +    opt_vuart_domid = simple_strtoul(s, &s, 0);
> 
> Should we check the resulting value against DOMID_MASK to ensure it
> is a valid domain ID?

Good point, will hook the check.

> 
> > +
> > +    if ( *s != ':' )
> > +        return 0;
> 
> It seems that if the COM ID is not provided on the command line, the
> default value will come from the static variable, which is 0 (treated
> as COM1). Is this intended behavior?

Correct, the idea was using COM1 by default.

> 
> If this is by design, it would be helpful to add a comment explaining
> why we allow a valid domain ID with a default COM ID. Otherwise, maybe
> opt_vuart_id should be set to an invalid value or opt_vuart_domid
> reset here to avoid ambiguity.

I will add a comment.

> 
> > +
> > +    if ( strncmp(s, "com", 3) )
> > +        return -EINVAL;
> > +
> > +    opt_vuart_id = *(s + 3) - '1';
> > +    if ( opt_vuart_id < 0 || opt_vuart_id > 3 )
> 
> Would it be better to define the pc_uarts array outside the function
> and then use ARRAY_SIZE(pc_uarts) here for the bounds check? This
> would make the code more maintainable in case the number of UARTs
> changes in the future.

Makes sense.
Let me see how that can be improved.

> ---
> Do we really need the search function below at all? Instead of
> storing an opt_vuart_id, we could store a pointer to the chosen
> vUART directly here and eliminate the search, simplifying the code.
> 
> > +        return -EINVAL;
> > +
> > +    return 0;
> > +}
> > +custom_param("vuart", parse_vuart_param);
> > +
> > +static const struct vuart_info *get_vuart_info(struct domain *d)
> > +{
> > +#define PC_UART(n,p,i) { \
> > +    .name = n, \
> > +    .compatible = "ns16550", \
> > +    .base_addr = p, \
> > +    .size = 8, \
> > +    .irq = i, \
> > +}
> > +    static const struct vuart_info pc_uarts[4] =
> > +    {
> > +        PC_UART("com1", 0x3f8, 4),
> > +        PC_UART("com2", 0x2f8, 3),
> > +        PC_UART("com3", 0x3fe, 4),
> > +        PC_UART("com4", 0x2fe, 3),
> > +    };
> > +    unsigned i;
> > +
> > +    for ( i = 0; i < ARRAY_SIZE(pc_uarts); i++ )
> > +        if ( i == opt_vuart_id )
> > +            break;
> 
> Instead of breaking from the loop, why not return the pointer directly
> when a match is found? For example:
> 
> for ( i = 0; i < ARRAY_SIZE(pc_uarts); i++ )
>     if ( i == opt_vuart_id )
>         return &pc_uarts[i];
> 
> return NULL;
> 
> This eliminates the need for a separate break and makes the code
> clearer.

Yep, will do.

> ---
> 
> Actually, we can simplify this further: since the array is indexed by
> opt_vuart_id, we can directly check the bounds and return the entry:
> 
> if ( opt_vuart_id > -1 && opt_vuart_id < ARRAY_SIZE(pc_uarts) )
>     return &pc_uarts[opt_vuart_id];
> 
> return NULL;
> 
> If opt_vuart_id were defined as unsigned, the lower-bound check could be
> dropped entirely, leaving only the upper-bound check, which would make
> the code even cleaner.

Ack.

> 
> > +
> > +    if ( i != ARRAY_SIZE(pc_uarts) )
> > +        return &pc_uarts[i];
> > +
> > +    return NULL;
> > +#undef PC_UART
> > +}
> > +#else
> > +static const struct vuart_info *get_vuart_info(struct domain *d)
> 
> inline ?

Yes, thanks.

> 
> > +{
> > +    return NULL;
> > +}
> > +#endif /* CONFIG_VUART_NS16X50 */
> 
> Should all of the code above be made common? If in the future other
> architectures also use this vUART mechanism, it would be better to
> make it generic from the start. In that case, vuart_info would
> probably need a "compatible" property to support different hardware
> types.
> 
> Then the search procedure through the vuart array would make
> much more sense.

My plan is have DT-binding for dom0less and xl config for legacy
configuration. Let me see, looks like dom0 vUART configuration
should be supplied via command line anyway in non-dom0less case.


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 17:50:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 17:50:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123448.1466459 (Exim 4.92)
	(envelope-from )
	id 1uxUO6-0006zu-3n; Sat, 13 Sep 2025 17:50:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123448.1466459; Sat, 13 Sep 2025 17: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 1uxUO6-0006zn-1D; Sat, 13 Sep 2025 17:50:14 +0000
Received: by outflank-mailman (input) for mailman id 1123448;
 Sat, 13 Sep 2025 17:50:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxUO3-0006za-WF
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 17:50:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxUNy-00891Z-2x;
 Sat, 13 Sep 2025 17:50:06 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uxUNy-007UEv-1f;
 Sat, 13 Sep 2025 17:50: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=n/NIyzWScPTA4RnRtGlg/JdWBCz0ifZVz6h8bY1/sQU=; b=
	EqcQ7w61kvpf0wzorOrtKOPDVbCEDJFwwwe6unDE7aX4AYI+n0i1y5kA4HrTVHp0yQ7PP8Yah2nhC
	9zg5YpP57lUNTaqV9ZPEh/nIJtU8uO6Kn7EIDJNRgriuXz9lDQL4Wlhi3JaNn8vAVBIG5y5uCOvJ1
	OZysukGWN1WIoBt4Q=;
From: dmukhin@xen.org
Date: Sat, 13 Sep 2025 10:50:05 -0700
To: Mykola Kvach 
Cc: Jan Beulich , 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 v7 02/16] xen/8250-uart: update definitions
Message-ID: 
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-3-dmukhin@ford.com>
 <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Wed, Sep 10, 2025 at 11:39:07AM +0300, Mykola Kvach wrote:
> > > +#define UART_IER_MASK \
> > > +    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
> >
> > Here, aiui, ..._MASK covers all known bits. No #define-s for reserved
> > ones.
> 
> I think we can follow the Linux kernel style here [1]. For example:
> 
> #define UART_IER_ALL_INTR (UART_IER_MSI | \
>         UART_IER_RLSI | \
>         UART_IER_THRI | \
>         UART_IER_RDI)
> 
> This way we avoid using the *_MASK suffix, which could be confusing,
> and clearly indicate that these are all valid interrupt bits.

Agreed, will update.


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 18:09:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 18:09:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123464.1466470 (Exim 4.92)
	(envelope-from )
	id 1uxUgs-0000Od-Jq; Sat, 13 Sep 2025 18:09:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123464.1466470; Sat, 13 Sep 2025 18:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxUgs-0000OW-HJ; Sat, 13 Sep 2025 18:09:38 +0000
Received: by outflank-mailman (input) for mailman id 1123464;
 Sat, 13 Sep 2025 18:09:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uxUgr-0000OQ-Gs
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 18:09:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uxUgq-0089RO-11;
 Sat, 13 Sep 2025 18:09:36 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uxUgq-007VHd-0k;
 Sat, 13 Sep 2025 18:09: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=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:Date:From;
	bh=F3WkMxo0QuWWcnZ3fFw0tI3XNr0b24EUPuuABcpHFuM=; b=prjZjvsI2g7U2ZvdrrdDWMMIUX
	BFgKJ5HtF+R4RK0qx05cOrCGbT7HSqnmGITHH4DoawQcynmZ9fT1rRNVLv5pdFou31IvSFMecepYm
	f66sThnBCZCX6JAHCv5C501AlznbLLJZe8zVitUYVBu3S272Nw5vm6OwPCCx1c19oQck=;
From: dmukhin@xen.org
Date: Sat, 13 Sep 2025 11:09:35 -0700
To: Mykola Kvach 
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 v7 01/16] emul/vuart: introduce framework for UART
 emulators
Message-ID: 
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-2-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 Wed, Sep 10, 2025 at 10:57:14AM +0300, Mykola Kvach wrote:
> > +int vuart_init(struct domain *d, const struct vuart_info *info)
> > +{
> > +    const struct vuart_emulator *emulator;
> > +    struct vuart *vuart;
> > +    int rc;
> > +
> > +    if ( d->console.vuart )
> > +        return -EBUSY;
> > +
> > +    emulator = vuart_match_by_compatible(d, info->compatible);
> > +    if ( !emulator )
> > +        return -ENODEV;
> > +
> > +    vuart = xzalloc(typeof(*vuart));
> > +    if ( !vuart )
> > +        return -ENOMEM;
> > +
> > +    vuart->info = xvzalloc(typeof(*vuart->info));
> > +    if ( !vuart->info )
> > +    {
> > +        rc = -ENOMEM;
> > +        goto err_out1;
> > +    }
> > +    memcpy(vuart->info, info, sizeof(*info));
> > +
> > +    vuart->vdev = emulator->alloc(d, vuart->info);
> > +    if ( IS_ERR(vuart->vdev) )
> > +    {
> > +        rc = PTR_ERR(vuart->vdev);
> > +        goto err_out2;
> > +    }
> > +
> > +    vuart->emulator = emulator;
> > +    vuart->owner = d;
> > +    vuart->flags |= VUART_CONSOLE_INPUT;
> > +
> > +    d->console.input_allowed = true;
> 
> I'm not a specialist in the area of consoles, but I'm wondering:
> Does the input_allowed flag serve the same purpose as
> VUART_CONSOLE_INPUT? If so, do we need both, or
> could one be removed to simplify the code?

At this point these two flags must be in sync.

`console.input_allowed` is a permission for a domain to take the physical
console input.

`VUART_CONSOLE_INPUT` in `vuart->flags` is a permission for vUART to take
the physical console input.

pvshim does not have vUART, but can have console focus.

And not every vUART can be configured to have a console input (e.g. Arm's
"hwdom vuart").

> > +/*
> > + * Put character to the first emulated UART's FIFO with the physical console
> > + * forwarding enabled.
> > + *
> > + * Must be called under rcu_lock_domain().
> > + */
> > +int vuart_put_rx(struct domain *d, char c)
> > +{
> > +    const struct vuart *vuart = vuart_find_by_flags(d, VUART_CONSOLE_INPUT);
> 
> The call to vuart_find_by_flags() with VUART_CONSOLE_INPUT in
> vuart_put_rx() appears unnecessary. Every vUART console is always
> initialized with VUART_CONSOLE_INPUT, so even if multiple consoles
> exist, the search will always return the first console. It would be
> simpler and clearer to use d->console.vuart directly.

There's no certain order in which multiple vUARTs are initialized, so there
should be something which scans the vUART list and selects the vUART with
console input permission. Follow on Arm's change will add multiple vUARTs
and I decided to generalize logic in this patch, so that there will be 
minimal update in vuart_find_by_flags() only.

> 
> Consider updating the function to remove the flag-based search and add a
> short comment explaining why checking the flag isn’t needed. This will
> help avoid confusion for future maintainers. Alternatively, we could
> pass flags to the init functions instead of hardcoding
> VUART_CONSOLE_INPUT for every console.

That will work, thanks for suggestion.


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 23:22:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 23:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123570.1466480 (Exim 4.92)
	(envelope-from )
	id 1uxZZC-0002x0-Dq; Sat, 13 Sep 2025 23:22:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123570.1466480; Sat, 13 Sep 2025 23: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 1uxZZC-0002ws-8b; Sat, 13 Sep 2025 23:22:02 +0000
Received: by outflank-mailman (input) for mailman id 1123570;
 Sat, 13 Sep 2025 23:22: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 1uxZZA-0002wm-SX
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 23:22:00 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e6a047c-90f8-11f0-9d13-b5c5bf9af7f9;
 Sun, 14 Sep 2025 01:21:54 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1757805708409168.5613458921232;
 Sat, 13 Sep 2025 16:21:48 -0700 (PDT)
Received: by mail-oa1-f44.google.com with SMTP id
 586e51a60fabf-322f0a39794so911666fac.2
 for ; Sat, 13 Sep 2025 16:21: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: 6e6a047c-90f8-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; t=1757805710; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Svcm3mobCYbmtaKgvDfiCw1S4czfRKrJHI7Nxwh20aCslb3hRrIkLmmtS2hnV5ddndgiz8urjqKjGSwEiWih8UM7qzknWYXaC/C+SBYtBqzENc9mZq+shimHU8EAZdgTrvXJCIULqGbP/j05yjzWSL6bYQtcgEaXpdw9Qx242Rw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757805710; 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=Lb4oPEpeznTSNONNNkvIwZWMW8wPE/TZ8ZqgB31kdBU=; 
	b=NSoPXnzXA639TFkNgfIiRYqfiVgi7+MuoGlPp1QvxTT788pSSVOWM9HL45geL7dAj2VFITu5Je8FJvYF0D+oE5ggzpEIeQ/eXVQ29yEx+orttH6SpcUEVoPNKo8uiV+Py3pGEDuth+T2PHYyI7uOSHLblWo6OoxMzy7Gw97R114=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757805710;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Lb4oPEpeznTSNONNNkvIwZWMW8wPE/TZ8ZqgB31kdBU=;
	b=BJYCEwM+J6jYBeb7HP+RwlN+8fBFs5gVClzhI3hE5bsopg45UdPjWJVuku1WJi6P
	gO0ebe7Kh72EWNgPWettBCvlbYAz2NevJLyjuFhmpYbp69KQlKvgZAVkjwbdQLOpcvz
	fcWBf7rojmkH004+9gbvrNP44NdsE5SOP4zT2+1s=
X-Forwarded-Encrypted: i=1; AJvYcCVhcyMAUTmuTdJ7VI1yP1MCoPiL8Zh0xoX+uC7NiYA1lBBMqz5/SThXWosONi/xUyiN5JAj8I80y/s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUGt+qYU4UQ6AiPReTfeuc1eRSFebD11r+E6BtWUST2MrEBvvu
	JFaoIfZB4GMutnbdVTA3havYOXjL14CqPyoBvSkU1oQlKJ4HOvbqOGClFBkdLWQ6C65qM4BfSbU
	UA9wVTsK2xizZPmnW1rwM0Sp/MmcOkLQ=
X-Google-Smtp-Source: AGHT+IH6rlFWsBb58CAzact8c+s/gwD+oH00dVydclqv9iB+pIhEiCJYR+hgRKqOyTCVo2GGvYjynTkFHE6w7e1a0S8=
X-Received: by 2002:a05:6871:611:b0:31d:8c33:59b4 with SMTP id
 586e51a60fabf-32e55ec69f7mr3157277fac.28.1757805707555; Sat, 13 Sep 2025
 16:21:47 -0700 (PDT)
MIME-Version: 1.0
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-6-Penny.Zheng@amd.com>
 <4e61f21e-6e1e-4baf-a78e-2b17b876d20c@suse.com>
In-Reply-To: <4e61f21e-6e1e-4baf-a78e-2b17b876d20c@suse.com>
From: Tamas K Lengyel 
Date: Sat, 13 Sep 2025 19:21:11 -0400
X-Gmail-Original-Message-ID: 
X-Gm-Features: AS18NWBoTwWby4gfbh2Hlm-4u3KeUcE6OcRxRuvhCYTlG9I8nsZw1HHCi0AJzgM
Message-ID: 
Subject: Re: [PATCH v2 05/26] xen/x86: make VM_EVENT depend on CONFIG_MGMT_HYPERCALLS
To: Jan Beulich 
Cc: Penny Zheng , 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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 10, 2025 at 11:06=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 10.09.2025 09:38, Penny Zheng wrote:
> > VM event could only be enabled/disabled via vm_event domctl-op, so
> > CONFIG_VM_EVENT shall depend on CONFIG_MGMT_HYPERCALLS
> >
> > Signed-off-by: Penny Zheng 
>
> Looks plausible to me, so:
> Acked-by: Jan Beulich 
> but really Tamas (now Cc-ed) should also get a chance to express possible
> concerns.

No concerns, thanks.

Tamas


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 23:25:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 23:25:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123584.1466490 (Exim 4.92)
	(envelope-from )
	id 1uxZcP-0003VJ-PS; Sat, 13 Sep 2025 23:25:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123584.1466490; Sat, 13 Sep 2025 23: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 1uxZcP-0003VC-MV; Sat, 13 Sep 2025 23:25:21 +0000
Received: by outflank-mailman (input) for mailman id 1123584;
 Sat, 13 Sep 2025 23:25: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 1uxZcO-0003V6-Jx
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 23:25:20 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5df4d67-90f8-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 01:25:14 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1757805908972887.190284944816;
 Sat, 13 Sep 2025 16:25:08 -0700 (PDT)
Received: by mail-oa1-f54.google.com with SMTP id
 586e51a60fabf-30ccec59b4bso2285899fac.3
 for ; Sat, 13 Sep 2025 16:25: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: e5df4d67-90f8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; t=1757805910; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hD7aZLewRtGUr7hw6BjMEbX7QvOv6lryfzh6H1VScXizVmeaeEo2jdyqRKhMWAFB4PbXhozbJGZTRPPY5inAYntopEPRmSu7vRF/xYyGlMJlbTkcvboSGt5WMvxZ0V7rJkZlMIlqJ4DMVVdt/lMk7NxyD7l0sdhEPi6O09VuzN8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757805910; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=a/5O9EeoJbUrG3OVl131zn0jgiKjRVk3yZV5Cm7hIHE=; 
	b=FJEaJLafkoX4/tBw7fHP2iiWa8V8T0Zl8XGI8C0IBKz7lSSy7aJrd14GujetA+MLI5RkgYGe4yYtUuG5Hlbp5uSJ4/JZ2G3D7QBDVrSSzCoxk3Xn73k/ngpkjkDQUqGbM1z8omPRtXOP+1gGTqYyw02F+dLSTjKweTzOobnlkY8=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757805910;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Message-Id:Reply-To;
	bh=a/5O9EeoJbUrG3OVl131zn0jgiKjRVk3yZV5Cm7hIHE=;
	b=kW5KX0x4aqE//kSw6tVZb3M/Tjr+SyG43kwc5ljcPiL6yolusIgzvRvJBeTBiVgh
	oEgcCuaU3cIJFMg1R+YFhl6x5AIu1j1KhPi4HMlTt5lxulVT2W8iisFr5eNU6z8K6NT
	m9xXFqMnFS8LMP92Qc3Xit6AoO28NP+xpo1TauPk=
X-Forwarded-Encrypted: i=1; AJvYcCXwk9U4woRW0/VhXVhAhpsVHJcFC26Q5vKs9nHhF3F181hrnPFy9wxfnKOdq2pHbJ+FuDHC5hLOHkU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZX97oz8czJNFcSpgzWn7uw+DgtNkWAI0tzz3B6uR0zA1TNJfF
	8Ux5LFeptXUdLSkkP3Wxc51muNiszXTt0ZmImsximloFPLr+O2bAO0Ve/W2V0i+mN3CMW8/sDau
	+/vl5IERUorir4/XF7wovbyT5ePHfick=
X-Google-Smtp-Source: AGHT+IHRn2u/fq9/Nn9tOEKtqarER85JsqKdfxExxlljbG7ZWgd2ih0ogxjJ/j0D1pBmpMlLC8krebfp4iTxRfKte/0=
X-Received: by 2002:a05:6870:f621:b0:30c:92a1:64e6 with SMTP id
 586e51a60fabf-32e566ca4f3mr3325385fac.42.1757805908248; Sat, 13 Sep 2025
 16:25:08 -0700 (PDT)
MIME-Version: 1.0
References: <20250912045254.3731398-1-Penny.Zheng@amd.com> 
In-Reply-To: 
From: Tamas K Lengyel 
Date: Sat, 13 Sep 2025 19:24:32 -0400
X-Gmail-Original-Message-ID: 
X-Gm-Features: AS18NWAyf3GqyMFt6N-mqYMuzg6ud-cCCKqZMLzGdnrh3rNSL2n8O3cUx5Ea97Y
Message-ID: 
Subject: Re: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
To: Jan Beulich 
Cc: Penny Zheng , ray.huang@amd.com, 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Alexandru Isaila , Petre Pircalabu , 
	xen-devel@lists.xenproject.org, Oleksii Kurochko 
Content-Type: text/plain; charset="UTF-8"

> > +static inline bool vm_event_is_enabled(struct vcpu *v)
> > +{
> > +#ifdef CONFIG_VM_EVENT
> > +    return v->arch.vm_event != NULL;
>
> Is "enabled" (in the function name) a good description of this condition, Tamas?

Sure, sounds fine to me.

Tamas


From xen-devel-bounces@lists.xenproject.org Sat Sep 13 23:32:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Sep 2025 23:32:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123595.1466500 (Exim 4.92)
	(envelope-from )
	id 1uxZjT-0005DI-FK; Sat, 13 Sep 2025 23:32:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123595.1466500; Sat, 13 Sep 2025 23: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 1uxZjT-0005DB-Bk; Sat, 13 Sep 2025 23:32:39 +0000
Received: by outflank-mailman (input) for mailman id 1123595;
 Sat, 13 Sep 2025 23: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 1uxZjS-0005D3-B1
 for xen-devel@lists.xenproject.org; Sat, 13 Sep 2025 23:32:38 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed068204-90f9-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 01:32:36 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1757806350589923.8464784861359;
 Sat, 13 Sep 2025 16:32:30 -0700 (PDT)
Received: by mail-ot1-f50.google.com with SMTP id
 46e09a7af769-75763558ae1so40992a34.3
 for ; Sat, 13 Sep 2025 16: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: ed068204-90f9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; t=1757806353; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Qz2icy26nm6llYXSsafgH0grImK2yFuKCNY9uvnmXJL3Zj10H30wYXwEnbpRJHV/2zDgC3lVzb2FK1KCzE+N75/aXqaH0aJ8ZON9eNczBlI0z3SFPH1iorQpq4edVzTWaTfCP/o7bAjvz2Wf1eCP3WNepz1ntDKzsaB86D02fMg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757806353; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=H7Z7rEemNPwWDOk4xlNKyvzqspj59iltoaOmQWtea20=; 
	b=dMfoxIlPxxrIVVNA3bof+lUhv7XSjl54picbkzyByJwpKb/POQ0k6D77Upse0w8vrPrnHx92MF2mEzBVbwdvp8utwsGNIdC3uERYkNi0Yh265mVUIsTJae2VJ9wc2l416iRwtylRcGX2aLYY9W2Rbixxdr8a0Kmv4ZaBynbpvBI=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757806353;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Message-Id:Reply-To;
	bh=H7Z7rEemNPwWDOk4xlNKyvzqspj59iltoaOmQWtea20=;
	b=KKvL4aqxlpBXRgP9NFJUWWvmtIA/zrhIalzqMY87HtOOxxl0tyoLc3K3nToexuTn
	BKlom/hfWHgJrLFrJpU5/jZUV6abS9KXMI5xREjuhZgL31s4GlkPKMvqE/1Qxf7BlYJ
	ovM4+wmqApGianqWyUXZofc7RtpkT03BvkPXYOWU=
X-Forwarded-Encrypted: i=1; AJvYcCUZo1228+UCT/KQVX70KnfMczQDFoCv8/icr78AOrHfCvH7TumSPyF0ds+u+NaH42UWcqCb5wfhvrc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzhKfEwyNneFxTy31RIEndquEzCH+8uED4LhbL38E3M75fXxSne
	3Toajrw64GhSLs8Eu8yeo2b9aIEOoIKgH1G+tBhOgn6L2G6s0+2os43hINXNqi1L41zdBC75n3K
	+LpZB/qzkHnyLfAUiNMMf8haAd3MLwXQ=
X-Google-Smtp-Source: AGHT+IFHPAqfDMV/ymtAwKnQp7aSUpnqca2vS3dSVIkd1YZZgoqqdnoUZCK1qHQeF1RG5jgAN0GgGhggcd3FkHKFJ0w=
X-Received: by 2002:a05:6870:a911:b0:321:2ad1:941a with SMTP id
 586e51a60fabf-32e56db5a93mr4345013fac.45.1757806349786; Sat, 13 Sep 2025
 16:32:29 -0700 (PDT)
MIME-Version: 1.0
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-5-Penny.Zheng@amd.com>
 
In-Reply-To: 
From: Tamas K Lengyel 
Date: Sat, 13 Sep 2025 19:31:53 -0400
X-Gmail-Original-Message-ID: 
X-Gm-Features: Ac12FXxraQlC8wGhFxor6fgXwEN5wSiV9aH4hp0P885Ol2IrkFyqHun1vcZDFS4
Message-ID: 
Subject: Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
To: Jan Beulich 
Cc: Penny Zheng , ray.huang@amd.com, 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Alexandru Isaila , Petre Pircalabu , 
	"Daniel P. Smith" , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

> > @@ -99,10 +98,40 @@ long p2m_set_mem_access_multi(struct domain *d,
> >  int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access,
> >                         unsigned int altp2m_idx);
> >
> > -#ifdef CONFIG_VM_EVENT
> >  int mem_access_memop(unsigned long cmd,
> >                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
> >  #else
> > +static inline bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
> > +                                               xenmem_access_t xaccess,
> > +                                               p2m_access_t *paccess)
> > +{
> > +    return false;
> > +}
>
> So this is needed when VM_EVENT=n and ALTP2M=y. Tamas, is this a configuration
> which makes sense?

Yes, altp2m should be functional without vm_event being enabled. There
could very well be in-guest only use of altp2m via #VE. This function
is used in p2m_init_next_altp2m which means it being stubbed out like
this when vm_event is disabled breaks altp2m.

Tamas


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 00:42:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 00:42:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123627.1466509 (Exim 4.92)
	(envelope-from )
	id 1uxaoR-0006Er-12; Sun, 14 Sep 2025 00:41:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123627.1466509; Sun, 14 Sep 2025 00:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxaoQ-0006Ek-To; Sun, 14 Sep 2025 00:41:50 +0000
Received: by outflank-mailman (input) for mailman id 1123627;
 Sun, 14 Sep 2025 00: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 1uxaoP-0006Ee-5Z
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 00:41:49 +0000
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com
 [2607:f8b0:4864:20::b32])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92be1922-9103-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 02:41:38 +0200 (CEST)
Received: by mail-yb1-xb32.google.com with SMTP id
 3f1490d57ef6-ea409597fe1so3694276.0
 for ; Sat, 13 Sep 2025 17:41:38 -0700 (PDT)
Received: from [10.138.34.110]
 (h96-60-249-169.cncrtn.broadband.dynamic.tds.net. [96.60.249.169])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-72f79a8ca9bsm22070287b3.67.2025.09.13.17.41.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 17:41: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: 92be1922-9103-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757810497; x=1758415297; 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=I1RUaDz6ZK8/RaQ/NO/WAet1aWzYR2kKiVazCvxpNhk=;
        b=RU7X2HPx+cFVk1cTYoPBckLJ8q/IqWJ8/jrQb9xELlcyLsLcwm34r9+ps/fuM0GgaF
         BtYq+bNIovZ1tEyEbseNDZTvZgRi4WP4KLRKdpcwpIx2o9QGcYDfiObzeJl4Dwp5iLbn
         MZjuoLm957ATQ6HLuuvvPfDysf2Cqrm3gFvAD7J2QaRPvKJda7hccpGd0FoCQU7h5BxY
         ANoir68gv4EYOOsn4uX4ImvG7lsnMt+VfVQUMMzD2guBRqZTCFwBwp39kK0CpXp6tJM1
         m1sh+rcCgx0JPOh4I6WJ55+WKZeyDPYzNTNd0xJOHolqhjF/RVIEGz0ToQrIHhnpRKZE
         92LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757810497; x=1758415297;
        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=I1RUaDz6ZK8/RaQ/NO/WAet1aWzYR2kKiVazCvxpNhk=;
        b=LpncIBxxRj07XQiy+ubODq9H1LCrv2RWwUpEZOBt/B4zaB4GdCTkzs7pG55OcXgWcR
         KdOB73ntpjQN/TU2nB8Z5O0byng3J5U2IA6bDb0NFG84pO4XRM8VwsmAaFqO/gzpsI7h
         j1rDw07IL5Eia89xLXSha6AAGrfMlWCdXz3S9vt96WfR7A58UJ0Kj1iU9+1yWbSeG6Gn
         cx+mjBZrZTlZSDjrHzofgtQ9yR9E3VpxGMb/YK07/dPF7xqCiMe6x+TNpd1+vefOs7Wa
         wOBnAQ4vs19oZE919jsD8S5Fk7G4NMKUgv5nLdeJAYX5DS1oors+Uwl2oMEU87hrEo2m
         lJAA==
X-Forwarded-Encrypted: i=1; AJvYcCVZsOTIXYilVl5Ff+yrhE3dS5UEc0wsh7GUxlMQAAAsBRsJDihLM+qPmi1o+HFbj8QT6UoPxAff8uo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy9HsfVPWPGj85fLfSCnDaaO+UuKjBBWBXfUh8Srma1wh2jK6ID
	k1/YGctmmKBW4LH8bJY8YP+W80pwu2oK8HxdY7hdxqXHlHJiim1qwcr1
X-Gm-Gg: ASbGncuX+HCmtO0UP2Y40hRE69jDOYsboPcQOaYDPcaa80rDhvmLt361Eyytw6dzGYK
	BmgUeTutmlAp9D3gTlyaaFb7Pc9RZoQrvdGXH2lDbBihdkArztcRG7G+QRGb0luZBgXXjRRO2gI
	RHsNXeeJbHudVtU0FUlj/2OKMVl8TLNTceLJrIFObutC5CX+0zsiMutRVnukrUbenro12QeSYLF
	NVuEXiDet9mKwTQzDmGdRdEc3psfQ+mt2i7xrFaNZUujK3R7BcZNwKZySgn8MauqlDPeUJPWMOh
	qqaKFZvEyxU5hRJ99u7HvzcmR3xjypEqdMPvLEG4JLywOxpaC8ek0DiV/SxoCg7FR7HZ39r6+Nl
	/h9GvWNWxkJkkhiekPE7q9XX5DSVFK4Y4d1XbNF33dVcbfabsCYPLehhH3AFmAKt8lmi/1pvlts
	XFOdPK4lJErXhurQfpHcAk/YeA7q87z94woZmKqR5V7HEYJw==
X-Google-Smtp-Source: AGHT+IELIGMkMYfiCRwMCuQ9Yf83LT8G3+dUa2h5kVXgWFIYFwLv5Vu0Bj29gbDNbPNTOn8xhu2Vhg==
X-Received: by 2002:a05:690e:4282:10b0:62f:542b:300a with SMTP id 956f58d0204a3-62f542b35fcmr383801d50.9.1757810497511;
        Sat, 13 Sep 2025 17:41:37 -0700 (PDT)
Message-ID: <1fbcbcf2-4b29-4b14-9fa1-9b904bb2657f@gmail.com>
Date: Sat, 13 Sep 2025 20:41:31 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
To: Andrew Cooper ,
 Oleksii Moisieiev ,
 "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: <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>
 <3ba29020-3a9b-4e10-8523-82bfb63482f6@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: <3ba29020-3a9b-4e10-8523-82bfb63482f6@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------K7V8gDeCigD4QIMr93qDC6gh"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------K7V8gDeCigD4QIMr93qDC6gh
Content-Type: multipart/mixed; boundary="------------ThyWfZa5APLclshshEerTAlr";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Andrew Cooper ,
 Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
Message-ID: <1fbcbcf2-4b29-4b14-9fa1-9b904bb2657f@gmail.com>
Subject: Re: [PATCH] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
References: <37561a9a3b6000502bb1a43651f6ddc49cd9149c.1757759941.git.oleksii_moisieiev@epam.com>
 <3ba29020-3a9b-4e10-8523-82bfb63482f6@citrix.com>
In-Reply-To: <3ba29020-3a9b-4e10-8523-82bfb63482f6@citrix.com>

--------------ThyWfZa5APLclshshEerTAlr
Content-Type: multipart/mixed; boundary="------------0a8SRZx8zVOL0VUT0e40eY0p"

--------------0a8SRZx8zVOL0VUT0e40eY0p
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 9/13/25 07:56, Andrew Cooper wrote:
> On 13/09/2025 11:44 am, Oleksii Moisieiev wrote:
>> Remove redundant domid_free() call in the XEN_DOMCTL_createdomain erro=
r
>> handling path to prevent a double-free condition.
>>
>> When domain_create() fails, it internally calls _domain_destroy() duri=
ng
>> its cleanup routine, which already invokes domid_free() to release the=

>> allocated domain ID. The additional domid_free() call in the domctl er=
ror
>> path creates a double-free scenario, triggering an assertion failure i=
n
>> domid.c:
>>
>>     Assertion 'rc' failed at common/domid.c:84
>>
>> The domain creation flow is:
>> 1. domid_alloc() allocates a domain ID
>> 2. domain_create() is called with the allocated ID
>> 3. If domain_create() fails:
>>    a) domain_create() calls _domain_destroy() internally
>>    b) _domain_destroy() calls domid_free() to release the ID
>>    c) domctl incorrectly calls domid_free() again
>>
>> This double-free violates the domain ID management invariants and caus=
es
>> system instability. The fix ensures domid_free() is called exactly onc=
e
>> per allocated domain ID, maintaining proper resource cleanup
>> semantics.
>=20
> Fixes: 2d5065060710 ("xen/domain: unify domain ID allocation")
>=20
>> Signed-off-by: Oleksii Moisieiev 
>=20
> Reviewed-by: Andrew Cooper 
>=20
> the tl;dr is that domain_create() either inserts the domain into the
> domlist, or cleans up after itself.
>=20
> The domid alloc infrastructure is problematic in multiple ways, not
> least because it now means there are two sources of truth for which
> domain's exist, and they are not interlocked.
>=20
> I would have blocked this from being committed if I'd had any time to
> look at it.=C2=A0 It will need remediating one way or another before 4.=
21
> goes out.
Revert time?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------0a8SRZx8zVOL0VUT0e40eY0p
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-----

--------------0a8SRZx8zVOL0VUT0e40eY0p--

--------------ThyWfZa5APLclshshEerTAlr--

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

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

iQIzBAEBCgAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmjGDzwACgkQszaHOrMp
8lMLFA//aUz6AaGdFnCzGEjVDBrdniJA7K6xQPbGDTP9RF6aMEVvXJhBV0uXdU3G
TW+V2DxzcxlZ8eZbCo+0czsQL+8sOmL0oV/cJO1GqZ9NsSUXuqkdyh0dJeRb9g5T
pWbuzVbIhEUJGnrqlpZ7LuR5e0HG+Oh64lJwi4iszxaWQ8mfngust8ornkH+w7G9
N6TbTG5l2dwJMOB0V+MvCIHqUBTxqmUMeNB0QZIh89TZdNMQ9B+/GUS+7wRpiwRY
ZXEnAc4nIyYWhX6gYCHBFKOubFDO7EuUdUMy6dlyjmGqwakFK2Wa0jSPT1WAFdlz
sCGtJhWtV+BBIUM/eoV8skxQiILcovRKfIdtSRsICeA2HUzwVwIDz7MmNwHpY3qV
GlwC8P8vxDtu3ARYwiWvCXtNCtUL/fEM6fomJ2elOxlJF6iInv7oubkeWOHFP0U1
/nuHQioROPaEd+jC5A3nNVDaIYBCWimOXx9nXZTOEHXR8f3ayuMIQDbJoFILVTmq
p1OYY/tICYlMX4rA9AOc5P3kk1gqFGAyHavhf+jusJysW/ZinZ+h4RSVVCPK234Q
kkmpK3MV4j7vUeXE1IH2E7qqzbOZtkc9pvDkgZef1YCQcErOe0bHuHIIaDrOQZzE
2+h5qvJBiXLwFSHrNyA95mifwK+D6z6Je1xxUl/fH5SId6YLuFc=
=JCjx
-----END PGP SIGNATURE-----

--------------K7V8gDeCigD4QIMr93qDC6gh--


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 04:05:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 04:05:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123689.1466520 (Exim 4.92)
	(envelope-from )
	id 1uxdyx-0003M7-L9; Sun, 14 Sep 2025 04:04:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123689.1466520; Sun, 14 Sep 2025 04: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 1uxdyx-0003Lz-Ft; Sun, 14 Sep 2025 04:04:55 +0000
Received: by outflank-mailman (input) for mailman id 1123689;
 Sun, 14 Sep 2025 04: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 1uxdyw-0003Lr-PO
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 04:04:54 +0000
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com
 [2607:f8b0:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4e8f4a7-911f-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 06:04:49 +0200 (CEST)
Received: by mail-pl1-x631.google.com with SMTP id
 d9443c01a7336-2445806df50so25272815ad.1
 for ; Sat, 13 Sep 2025 21:04:49 -0700 (PDT)
Received: from ?IPV6:2601:646:9e00:b920::2bf4? ([2601:646:9e00:b920::2bf4])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77614f3c244sm6423966b3a.79.2025.09.13.21.04.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 21:04: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: f4e8f4a7-911f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757822688; x=1758427488; 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=VzemIDikZYgL9exPt5M8v/LJGHU6LS2hmoTEaMFHg2s=;
        b=CZANum+RphowjZ96k2OziFvSl2r+0wKY8P6zt9Qn8YeXk5yJQuAzaP8j5F0cu068Ho
         51oDaDe08PKjzsK0NDMQaGVQY/Yk5tm6e2P/xUQWiC0MfPFfjbPDrpB/F6mU8vOFgRtr
         WqzvrshehHuhhf56dAFVYBFPqNSD2e6MOMdJv7WhTv6bhiPf2bVA4PymnZbGQVdjwYDp
         ck00V1dINPgMC5La0KZSd3cxNLNLW4bfrHIKBWjvmRNHUnNOgp9NFKVTZRsXOiW3DbW6
         NE5NQkkHpp4js5r7R3wN1MnSGy09aC6jj2MrMzkfZD9b58q2ocgl9fAadzYT8BCpvck6
         6/5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757822688; x=1758427488;
        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=VzemIDikZYgL9exPt5M8v/LJGHU6LS2hmoTEaMFHg2s=;
        b=WgCIjqM31AeEw+sf7aEcJuCsqXqIVj909S24Vw71wkPPS28/4GB01NNgfhN6I9Nnli
         NnlJdPNT5HJSGx/L2dyak6YydL/dOgLzo8pdu6kwegq3Vo5pNdjBoVlm1kwrTTUMCjpN
         UXJB/h1YddecruRtAMbkB8bQqt9uzFIjvOcdFtNm+/Px/f/T5kB3XFZwwadDwlpq4Jp3
         94QGqeL5/9puM/kJt8XAI6ZXdfYUdC4tX+FZl7eItdSvyyt0pXhsBrQVqPKQ1iGMPUgw
         UmcETXFo9B/LchoDwXqB1PSLG1d2qs9VxRGluNS3j6wjQT769PynSKY33T6C2N+Dv3/a
         uQYw==
X-Forwarded-Encrypted: i=1; AJvYcCU3Dcs4aSt5cacl6NQ+GP94/nFdnAEEB9ZxRvAkhhl89T1+SpN98ha7bWrL9c1nIShirvczf84qMJE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwypOM1NPZjm5IDbNfeRY0b6dk2U3tJ7m9ywLGBWtSy/QivLkeL
	VXKU68vmRflCe4Qek3fn53asQm4t+pYqjKSHOQg4NCchPBO9NwmueXrJ
X-Gm-Gg: ASbGnctwYqczg8Drji64MQS9wEpDaYQsNtsGTt5M9MrPlVq4cObJPVJLuxKwv4d+EDv
	MHbKlYVnQSTAIvjiwwAMm2G0avrmMsM8UpjufdrMUuWOEhTFTHI2Ow6EAWuHYX/WluIIXSm0DUa
	yEeSRLATucFOBYs+PvtVgi8Tpy45QCmexnTwl9GFTsDZmBoSyUb4sfC84PKiM+YZb1uwW4efqDI
	uCSuOE+OQxkgFIMzaV6ICCs8b8sZnHI81r7UXzP/xy+/6O+++16dEOOp8xGs4kwV1OB/4Yc6WB+
	DwKORGFQ4L+xFF65hYf9KgykFw71kIwm9rMtQ48851sFikUw5eUTjCDLgn/JJGSbcS7m0abm0mK
	wEXknwsuDHR/0WlvS97t212G5uokHHMi1cGtAEi2aBYMtobwfeNiRfA==
X-Google-Smtp-Source: AGHT+IG9yDpBiOAueeneMaAmMcVqH6SnwO/wwKcnXWqCb4uFKvqjSl0kZtiC7sYfrdSLaML93CCcTg==
X-Received: by 2002:a17:903:3c65:b0:24c:ed9f:ba53 with SMTP id d9443c01a7336-25d26079e22mr101611915ad.29.1757822688041;
        Sat, 13 Sep 2025 21:04:48 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------Hu0m4xuLBOLyybHzTbFLjDZb"
Message-ID: 
Date: Sun, 14 Sep 2025 06:04:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH][for-4.21] xen/arm: Reorder SCI resource cleanup in domain
 destruction
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <164651d0662e674002ed17399300c3a25e6dcbfc.1757757602.git.oleksii_moisieiev@epam.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <164651d0662e674002ed17399300c3a25e6dcbfc.1757757602.git.oleksii_moisieiev@epam.com>

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


On 9/13/25 12:30 PM, Oleksii Moisieiev wrote:
> Move the SCI (System Control and Management Interface) resource cleanup
> earlier in the domain_relinquish_resources() sequence to ensure proper
> cleanup ordering during domain destruction.
>
> The SCI cleanup is now performed before TEE (Trusted Execution Environment)
> cleanup rather than after P2M mapping cleanup. This reordering ensures that
> SCI resources are properly released before other subsystems that might
> depend on them are torn down.
>
> This change addresses potential resource cleanup dependencies where SCI
> resources need to be released before P2M mappings are cleaned up, preventing
> potential issues during domain destruction on ARM platforms with SCI support.

Shouldn't be then Fix tag present?

~ Oleksii

> Signed-off-by: Oleksii Moisieiev
> ---
>
>   xen/arch/arm/domain.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 1a8585d02b..0ac381a5a5 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct domain *d)
>               return ret;
>   #endif
>   
> +    PROGRESS(sci):
> +        ret = sci_relinquish_resources(d);
> +        if ( ret )
> +            return ret;
> +
>       PROGRESS(tee):
>           ret = tee_relinquish_resources(d);
>           if (ret )
> @@ -1109,10 +1114,6 @@ int domain_relinquish_resources(struct domain *d)
>           ret = relinquish_p2m_mapping(d);
>           if ( ret )
>               return ret;
> -    PROGRESS(sci):
> -        ret = sci_relinquish_resources(d);
> -        if ( ret )
> -            return ret;
>   
>       PROGRESS(p2m_root):
>           /*
--------------Hu0m4xuLBOLyybHzTbFLjDZb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/13/25 12:30 PM, Oleksii Moisieiev
      wrote:

    

    

      
Move the SCI (System Control and Management Interface) resource cleanup
earlier in the domain_relinquish_resources() sequence to ensure proper
cleanup ordering during domain destruction.

The SCI cleanup is now performed before TEE (Trusted Execution Environment)
cleanup rather than after P2M mapping cleanup. This reordering ensures that
SCI resources are properly released before other subsystems that might
depend on them are torn down.

This change addresses potential resource cleanup dependencies where SCI
resources need to be released before P2M mappings are cleaned up, preventing
potential issues during domain destruction on ARM platforms with SCI support.


    

    
Shouldn't be then Fix tag present?

~ Oleksii


    

      
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
---

 xen/arch/arm/domain.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b..0ac381a5a5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct domain *d)
             return ret;
 #endif
 
+    PROGRESS(sci):
+        ret = sci_relinquish_resources(d);
+        if ( ret )
+            return ret;
+
     PROGRESS(tee):
         ret = tee_relinquish_resources(d);
         if (ret )
@@ -1109,10 +1114,6 @@ int domain_relinquish_resources(struct domain *d)
         ret = relinquish_p2m_mapping(d);
         if ( ret )
             return ret;
-    PROGRESS(sci):
-        ret = sci_relinquish_resources(d);
-        if ( ret )
-            return ret;
 
     PROGRESS(p2m_root):
         /*


    

  


--------------Hu0m4xuLBOLyybHzTbFLjDZb--


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 04:06:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 04:06:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123700.1466529 (Exim 4.92)
	(envelope-from )
	id 1uxe0R-0003wa-SO; Sun, 14 Sep 2025 04:06:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123700.1466529; Sun, 14 Sep 2025 04:06: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 1uxe0R-0003wT-Pr; Sun, 14 Sep 2025 04:06:27 +0000
Received: by outflank-mailman (input) for mailman id 1123700;
 Sun, 14 Sep 2025 04:06: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 1uxe0Q-0003wJ-8m
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 04:06:26 +0000
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com
 [2607:f8b0:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d3d5c04-9120-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 06:06:24 +0200 (CEST)
Received: by mail-pl1-x634.google.com with SMTP id
 d9443c01a7336-24b28de798cso22077255ad.0
 for ; Sat, 13 Sep 2025 21:06:24 -0700 (PDT)
Received: from ?IPV6:2601:646:9e00:b920::2bf4? ([2601:646:9e00:b920::2bf4])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77607a4734esm9924071b3a.34.2025.09.13.21.06.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 21:06: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: 2d3d5c04-9120-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757822783; x=1758427583; 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=j0bwFi0gWVX0C7UbIGK4b1ALT6ZyeTA2AoW/1bSIA9k=;
        b=MKIhruA7dDAPLEsd+pwgu2poKHLyw55Ih5e9OaeJ5X/syGd6UYGSlJB5A87zJwA7o3
         n+RJlFgYQCpxC/Vdi4QCKYB6NfIDRp+iWUJFLdMXmV1mq+CNQ1SOJcM1mxSmuTKaNonn
         yLh+ODBiBNEZoExF3Vh6rbxseeflosLvkNAq7xu3U1wCWJqHI9rmLd6aGNekDknxmEI7
         fmUqH/L7y6wZN8ZdGreMuOMJyzZ+4pY/mdT3XlDoO9wqEup47BrPfGPltsDW3XkC6pbv
         /sGw8HTsJ7PRmREmxUHblZwsX5TWI8fsSg6cN/LqIH4YDZwkcJAlyez6IOhSZm/3D4CC
         87/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757822783; x=1758427583;
        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=j0bwFi0gWVX0C7UbIGK4b1ALT6ZyeTA2AoW/1bSIA9k=;
        b=HrUaF2cBiKwlPudZuxhgNcyJ+25+GM6I7ov07Jq52xk7dBxCjsR8KzmaC3O1iTiHr5
         xiinndDDAPbYGkIRhvsmiFU8DUHeEv8IC8kJUTw3V0HRBeGxz9nIIABcD2NhZOExD12Y
         yt7+dd0nyf9Yg0MqLjtGQ5fgBdDOeiwMTbspRgexmwjq4y/2uEW0A7E/XZ8xJKzLBBZp
         nQ2i35OpY+5CC39pU6yQdClF07WGbt4bt0CobIOQnENKObr4R0gz7biV1ihEtlJZFQxG
         Bh+sxd+10ikvQIsObruVF3JX4Qt3BsvS+xvnJpsbrV+XTcBynCwoGou+fVcb6MM7p62p
         n5sg==
X-Forwarded-Encrypted: i=1; AJvYcCVupXgLfE2ufSQL5teKQXcamrsCB+P2BHf8Msc6bkK5FO/jTQW9wy3TZoLxonHWe2kRzQAV3ZTMbn8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwI8AL8jXRv9nTW9BqxGbnWubpJP64RqBfHEREDkzgVy0BYCa6F
	pjLRr9+DC53qjEu6v82nqZmcA4Pu03no2ZhRVJ58WDR8Nqs87XjoJ1OZ
X-Gm-Gg: ASbGncvMY/FcGtLhtqvntGOWYXbikBsGKz6qDh2cq3kVaec0Fz9Nk1T3zvCnSSUY5Ne
	JmhcE1l1ty9pwvzsTuJEPW8hbtXZf/ZOKYHoYvnO38W1NZ2/PdjZc2ZyMMYcca9kR5E6wPOJ6hL
	ojCh5U2O7sAX2qEuMeels8oBMqIMNc7rorA7+fcSM5Q4kdcOjewiASoAKhwzDmw2O5gourQfeWG
	ayoA9462VHKrHw8Q0VeLuMLkEIOAW9GBtECRNXprn40Hf2Yrkfs+3HNzAOYNpSqIcLbpa1IFrwJ
	Y6Kf9kaMrQdwKioKtkPskyVARNvAOJsh3VhzBLJtW6N6E6kHOMLr4x8uobdVmorA1rPoH4pl85s
	bMaSWKtG/im32SgL5ldCAc3AQbWemPvzFN55762SpDMg=
X-Google-Smtp-Source: AGHT+IEXpKZi6drgIBTtnKy7edy0xXQ0DWz0G0yacZQdQE50SEUWaxYQMVmZs3oYdx9PgQtqjzGpQg==
X-Received: by 2002:a17:903:3c2c:b0:256:2b13:5f11 with SMTP id d9443c01a7336-25d26d4c335mr91569125ad.40.1757822782712;
        Sat, 13 Sep 2025 21:06:22 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------PI7vKfyN0dsXWqX0ITXmDRXi"
Message-ID: 
Date: Sun, 14 Sep 2025 06:06:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/8] CI: Use the Debian Trixie container for RISC-V
 test jobs
To: Andrew Cooper ,
 Xen-devel 
Cc: Denis Mukhin ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Shawn Anastasio ,
 Doug Goldstein ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Victor Lira 
References: <20250912144427.1905141-1-andrew.cooper3@citrix.com>
 <20250912144427.1905141-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250912144427.1905141-2-andrew.cooper3@citrix.com>

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


On 9/12/25 4:44 PM, Andrew Cooper wrote:
> This was missed when introducing Trixie.
>
> Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
> Signed-off-by: Andrew Cooper
> Reviewed-by: Denis Mukhin

Reviewed-by: Oleksii Kurochko

~ Oleksii


> ---
> CC: Anthony PERARD
> CC: Michal Orzel
> CC: Jan Beulich
> CC: Julien Grall
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Shawn Anastasio
> CC: Oleksii Kurochko
> CC: Doug Goldstein
> CC: Marek Marczykowski-Górecki
> CC: Victor Lira
>
> v3:
>   * New
> ---
>   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 95b883b32bb6..1de68a0fe450 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -77,7 +77,7 @@
>   .qemu-riscv64:
>     extends: .test-jobs-common
>     variables:
> -    CONTAINER: debian:12-riscv64
> +    CONTAINER: debian:13-riscv64
>       LOGFILE: qemu-smoke-riscv64.log
>     artifacts:
>       paths:
--------------PI7vKfyN0dsXWqX0ITXmDRXi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 9/12/25 4:44 PM, Andrew Cooper
      wrote:

    

    

      
This was missed when introducing Trixie.

Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>

    

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

~ Oleksii


    


    

    

      
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Doug Goldstein <cardoe@cardoe.com>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
CC: Victor Lira <victorm.lira@amd.com>

v3:
 * New
---
 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 95b883b32bb6..1de68a0fe450 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -77,7 +77,7 @@
 .qemu-riscv64:
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:12-riscv64
+    CONTAINER: debian:13-riscv64
     LOGFILE: qemu-smoke-riscv64.log
   artifacts:
     paths:


    

  


--------------PI7vKfyN0dsXWqX0ITXmDRXi--


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 04:11:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 04:11:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123711.1466540 (Exim 4.92)
	(envelope-from )
	id 1uxe5V-0005UI-Ed; Sun, 14 Sep 2025 04:11:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123711.1466540; Sun, 14 Sep 2025 04: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 1uxe5V-0005UB-Bg; Sun, 14 Sep 2025 04:11:41 +0000
Received: by outflank-mailman (input) for mailman id 1123711;
 Sun, 14 Sep 2025 04:11:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uxe5T-0005U5-UH
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 04:11:39 +0000
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com
 [2607:f8b0:4864:20::1036])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e885823d-9120-11f0-9d13-b5c5bf9af7f9;
 Sun, 14 Sep 2025 06:11:38 +0200 (CEST)
Received: by mail-pj1-x1036.google.com with SMTP id
 98e67ed59e1d1-32e1288eb0cso476216a91.3
 for ; Sat, 13 Sep 2025 21:11:38 -0700 (PDT)
Received: from ?IPV6:2601:646:9e00:b920::2bf4? ([2601:646:9e00:b920::2bf4])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7760793b65dsm9376593b3a.9.2025.09.13.21.11.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 13 Sep 2025 21:11: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: e885823d-9120-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757823097; x=1758427897; 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=sksv9cuJpSxQMGAkjPHpmVpw8OJEWIXA+fog+o/4DNE=;
        b=C3do8tBeLdIqkSocaLeYCtyMvRMEF++yvbckh3A6Xsw7CItBaGLgiqlpVKlFWP0KyS
         ZLBDV48IdgX0AFCSPMYVpTOtJI2ySgKiY+VaSmSlETa+w4em+/Tffqxr+/9CdUn3NWRH
         +2IqIVPoUej/uOQcUVRnUkC1WkwtmuO9jbbbE0qizBl7/32MiIoIbGR0yrlogEtpoVjM
         vWif4R3rfyosFvrW2bIYzy+Lcwg2YyNY+ImB+hIhW3pJVAaLM/IAizvJs4r4a+2MHPiR
         QwGLvJxtRQrttZDzxPoFc9OhR6NxrsKCy2Z+Ac+A8zaxMKppPb0QZ4KoSp1RLxTLIy4Q
         epgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757823097; x=1758427897;
        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=sksv9cuJpSxQMGAkjPHpmVpw8OJEWIXA+fog+o/4DNE=;
        b=F4vROxWVxWrBkBUx+NvRwvkOYnP8aA4yA5XBo7Gg7ffKVLTjlzKFzp74HuH9KHjbzB
         9KaVVIaDc6yzkDZQRqI03BGLydxUzvHyITThLto7kdbf25eV28H7DQzWyxI1EO+769s0
         wgX8i1nGZ+4epnlPISPaRUoiQaR1/swQ+Eoah4LFbNmcrOAJC3GtuK3PJdWT6OxKLg5S
         HnkMtM20rpDKNCMF62sQHUjSIySEoat3SdgwA7gqh8bOwoMYqS6I/5JYTw8+ohmyiwDN
         GBCYrPCqH4XOksRIDRgwLBhVjSoG++8p+79B9AnqHd09I6I6FiOCCfj39bFRNSP2K41K
         8mFw==
X-Forwarded-Encrypted: i=1; AJvYcCVXHWcUTCnIZdP05IuldxxA0h9MiLL6eiVUgdTbV9EW1YjUgJZTl+lRTH6qiMZLDBBtzQbkpeBN17Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz8ss4ZajKbnQ56Db8gbXyn+GnW9SDWr3fceFjZWQxZjM1M8bmL
	EN4XFurjva3cbFTp6Y4GezQpHydKurQgAqxwzhZzOOER9zOBGwVnG2ARFcMrXfZW
X-Gm-Gg: ASbGncsyDrLYI9AbZxLPcUkwMP+13pEFFT26gwNl7q5rDKkS+gRtX4dWYzljYccpJuX
	NyX3N6uG8CQj8uWxZyiHwoMAbRQsjt1hPm8R/aq9SDWp7dH1lKRI3DqLcSUN58M6jEeFd9ZowAB
	26tXtX8BoS6XvZf1e08cnNQCPhOhDGE8elqeRApA+bqX3iDvh+KPC5TYFLTOnVrgn7X86f2PLjz
	IQ+dNDnJN6uD0HbfW25j5R7Prr4MFZIRRIZeX8iRzZcJDC7yL2wLUGy9x11qzcB9mYKZn4dzk7r
	LzbowAVqr7oTjSSE4eEhtupgKaAY0CVA77MU9sThDaxPNsVb70GlBsmXQ/Psk0ntrdY+DqxfMJ8
	k7qH26F0+6GTZ1OSFh/3tG/tO8avCxbyNA39fhPnIAWjT60EYtWwaGzbjq9p/AvVN
X-Google-Smtp-Source: AGHT+IHjgh1wqqQn8YLgOVA3pN603Ez/HqF6uPzCVy8ssLqsgqRpavRpB0oc6IK4aE3X/+4XytPrCg==
X-Received: by 2002:a17:90b:1d47:b0:32e:2798:9064 with SMTP id 98e67ed59e1d1-32e27989209mr2668119a91.35.1757823096818;
        Sat, 13 Sep 2025 21:11:36 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------rz1mpetzxbwWGK7PgvjqWYzI"
Message-ID: <6b2c6641-38ac-4ed5-855b-e79a1deb4b9b@gmail.com>
Date: Sun, 14 Sep 2025 06:11:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/4] xen/arm: add generic SCI subsystem
To: Julien Grall ,
 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: 
 <3e237c5256054a88b1c099d85d8bd1a602bba230.1756995595.git.oleksii_moisieiev@epam.com>
 
 
 <1715e68b-fef3-4846-8db0-5cbd49878f27@xen.org>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <1715e68b-fef3-4846-8db0-5cbd49878f27@xen.org>

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


On 9/12/25 11:38 PM, Julien Grall wrote:
> (+ Release manager)
>
> On 10/09/2025 15:49, Oleksii Moisieiev wrote:
>> Hi Julien,
>>
>> Thank you for your observations. You're absolutely right about this.
>>
>> Currently, the sci_relinquish_resources call doesn't perform any 
>> operations
>> because the single-agent doesn't implement a callback.
>>
>> I'll move the sci implementation to be positioned above the tee
>> implementation
>> and prepare a patch for this change.
>
> Thanks! I think this change should go in Xen 4.21. Please tag it with 
> [for-4.21] or similar.
>
In one of previous replies we already agreed that it is fine to have this patch series in
4-21. Just to be sure:
  Release-Acked-by: Oleksii Kurochko

Thanks.

~ Oleksii

> CCing Oleksii Kurochko to keep track.
>
> Cheers,
>
--------------rz1mpetzxbwWGK7PgvjqWYzI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/12/25 11:38 PM, Julien Grall
      wrote:

    

    
(+ Release
      manager)
      

      

      On 10/09/2025 15:49, Oleksii Moisieiev wrote:
      

      
Hi Julien,
        

        

        Thank you for your observations. You're absolutely right about
        this.
        

        

        Currently, the sci_relinquish_resources call doesn't perform any
        operations
        

        because the single-agent doesn't implement a callback.
        

        

        I'll move the sci implementation to be positioned above the tee
        

        implementation
        

        and prepare a patch for this change.
        

      

      

      Thanks! I think this change should go in Xen 4.21. Please tag it
      with [for-4.21] or similar.
      

      

    

    
In one of previous replies we already agreed that it is fine to have this patch series in
4-21. Just to be sure:
 Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii


    
CCing
      Oleksii Kurochko to keep track.
      

      

      Cheers,
      

      

    

  


--------------rz1mpetzxbwWGK7PgvjqWYzI--


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 13:16:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 13:16:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123848.1466550 (Exim 4.92)
	(envelope-from )
	id 1uxmaR-00086f-Sc; Sun, 14 Sep 2025 13:16:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123848.1466550; Sun, 14 Sep 2025 13:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxmaR-00086M-MP; Sun, 14 Sep 2025 13:16:11 +0000
Received: by outflank-mailman (input) for mailman id 1123848;
 Sun, 14 Sep 2025 13:16:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uxmaQ-00086G-Mn
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 13:16:10 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa0fc1b2-916c-11f0-9d13-b5c5bf9af7f9;
 Sun, 14 Sep 2025 15:16:08 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AM0PR03MB6243.eurprd03.prod.outlook.com (2603:10a6:20b:144::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Sun, 14 Sep
 2025 13:16:05 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9115.018; Sun, 14 Sep 2025
 13:16: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: fa0fc1b2-916c-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BUCoz7cJkjo/8x6YP47E82iDC+/7fySvX5rmXnlyHgW36tPicn5jBEKtqFifuy13YPvx/rsXkbYsb5pZkG7HacyxmO5wwtkuDqh0Ba38kke/8foQZoLOjQ03Y73fzPViSPLdPkUU4jNk9vbWzZPSniGMj51wuLVNnqWsuZ1V8xugnCUjTD19WKVjNkKmBWTBu+ouHAV63aePm9OrZS5/NuqDNRUwm3aijaJePe5z7TRur2oW74DP3fer5cZMN6sHsuhrLkMMUUIRVn1rJEJFIIwIbJ84oK/mHKvWnEx7k7sxyUgQSq25/FUZ+E8Xss+6ARnoHVgXjSVfYOY+G7yBBQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1CJzf1o3FIkwIZND5pCfpJAVKyuUylbQ8n2PwOOqp5A=;
 b=PR3wuc3AsEEwmDkInsBqe2DulFJAh18AY6/mtZqRCVL1PV0AYrp2GLzyDzIXiLmKFnou9NE+ta9F6yQx1x6CAEUTBIjIfdw//Pkvb2+DeE7TI0aJX1HE6pCYuJLFtbcITlqdOSyclsHWRPk1ok4v9gsoiqSw8xHthElvHt5+dL2y2Wad24mZcd5VSn5BpJBcEnCehtBW8X+TuQC7PfbHLhsSUGp0wqeGu3UpbK/J+65Hvfxkfnfla1tYnc/mS0F94f9lAEzf92F/GfAoffgxc1otUCk582JPnwSgxg9Gx/jZfUoojDNbjsTpJgcOhRf+4YS7JrPWg1WAOkkWrhrA4g==
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=1CJzf1o3FIkwIZND5pCfpJAVKyuUylbQ8n2PwOOqp5A=;
 b=iKk/B60imaRGmnTjTNGYia83235eVq5+9CWJlpFl4HP5j1cRzbvqiSXsMnrRMRnScfv4mDyTeaJKvVZGInjsdW+7fRe/azWUbL3d0FGNcRZN45TFi0LFIx1hPkxWDpypF3KaGDoBQNH/OWEeuOn7nSzaVLVFvfj+mqOBgS0xn+wjVwCaK3r+qcRz6GOwc4Pb3EEeoviiiBjPmG+9FsrHJz2tvV7T0tbihn2KNKbcUj7OB1rTFk9lko77THic8Vep5+UaXgFfG32QCsIygAGEooBOS8sSCm0lnqeP+5LM9lcrHtvLetb+GhjmEnWxIp+/23oOTr9sZV1Rfoqbpzco6w==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini
	, Oleksii Moisieiev 
Subject: [PATCH v2] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
Thread-Topic: [PATCH v2] xen/domctl: Fix double domid_free in
 XEN_DOMCTL_createdomain error path
Thread-Index: AQHcJXm5/L1/35fsPkySCbuTTizhog==
Date: Sun, 14 Sep 2025 13:16:05 +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: PAVPR03MB8946:EE_|AM0PR03MB6243:EE_
x-ms-office365-filtering-correlation-id: b7bf8982-bf92-49fd-ecc7-08ddf390dc39
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ztuj4NfOV6SBLDQ56Ts9IKMw/lLnehs779qnA7FN55UyTrWA3bbXE1DGui?=
 =?iso-8859-1?Q?aK5JcFx0nX9qhPNfn4UiCltf06iJzt8c5F8yvuxNPIfaJ5zHxFi1XvtefH?=
 =?iso-8859-1?Q?4QGqxG7eM7XHkOVN5SBNuXLeWWfTaj7HW6MogOinoKsgG0/ViyzjeReikR?=
 =?iso-8859-1?Q?RXtOGvKJFBygeP9vxkLfRChdc9Fxj3M7O5P7/9uuNyDXaWZpk7ZhUG1+6+?=
 =?iso-8859-1?Q?iVKRQ7nHqrg+W4Z/9mp6m+7tmdNWbm7MCEcg5vf/BMWfGM0bccWi/1dB/g?=
 =?iso-8859-1?Q?tI96wXA0VN+PAavdmwxHp5qNHF1MD7SqV5F3DxKgSMXFVcSDjMi/L8gre1?=
 =?iso-8859-1?Q?TUvRn0XO0+OZANMtr383VQ7YPqkrT07L55V33s6GQ014sPBIFae7o7rZdv?=
 =?iso-8859-1?Q?belVOoWvamgV8VNAynVaZz+M/0r8fNXVUM7S52sqxEOtfTSUZ4F+FkYO+W?=
 =?iso-8859-1?Q?17kcXTSdtZVcDf074ZV4woVJNruYW0yecGjnECAtsyb+JWapQ8ANbh3SKX?=
 =?iso-8859-1?Q?nV6YArQmyklnIYqrN98EZYBKgA9ATc4mp/L1P+7KxUJs0wowzXuNCtwU/B?=
 =?iso-8859-1?Q?crf/uJhmk+ySQrIu8DWATS05iOv54GKtDS0aS45+PpcjnKuB2558zyv6P1?=
 =?iso-8859-1?Q?lzBzTV7a0d4EBwa2kNFWozAqgoQ05nYVMftB5lZCxyUtaIS+CAMyT5kuej?=
 =?iso-8859-1?Q?okLYPa1d33CEPEbMlakfzL1laHLp6uCiWwDpk3wg3ac4fw1yaWnrO4RBgl?=
 =?iso-8859-1?Q?MB1r95bsmHXDczYiKrY346gqVwxJ5rXvx30G6NrsKeSaGe88AtjQTcd/8/?=
 =?iso-8859-1?Q?4ahOZoyE6zZLtPXP45gyKmvQ3/b/LrelNt8tOyEikpHfnFQij8ZOg66zDM?=
 =?iso-8859-1?Q?6LP6nceyzMdeZhEMpZ+TFryqGvn/gVT5c1hJTj3TgiPfB/7ORJFLgOrnnH?=
 =?iso-8859-1?Q?HRn29KCxS1wS9C0lRX69ZUzULk7/qN3wMlh5NAG63s5DI3LO+wgM3e0BEb?=
 =?iso-8859-1?Q?ZpAIdD8bLT4cmXq+JwbByBxwi6lvPCqKpVySZrFjxrlifS8o4jQJDtD/k/?=
 =?iso-8859-1?Q?R+9qi/ryGHMCGsjwIfPMyFRrGfJRefV0ttFc93mh89GtZwPrBLmta7r7VL?=
 =?iso-8859-1?Q?2bOm3YSxliLJ0pSKSZB0bzbN9n03KMIp/8/A2ldGy8M4/HJ3sxzQb0dLrM?=
 =?iso-8859-1?Q?SQYMT9bt9+bJIDylCePz7YIyeGXl/k+TiiIhD+fFRpmddOkIxr9Cw53mI1?=
 =?iso-8859-1?Q?hADUtZJCyIjxfs82lPbg5tJ8jgaEIqasG5JSq9GjqjieYdgkOj7lGdj6eb?=
 =?iso-8859-1?Q?0v3rdpEyr19D7kSibqUsRAP5wMVG3LO5Z5xjHasaBmLMaHP5DPrze4YH0U?=
 =?iso-8859-1?Q?AAc/C5nNAz9QRXLIrOIJtlkI4aptKjFZ3TVvZ/zosoYvuxlXOihC1Yqp9r?=
 =?iso-8859-1?Q?G/8pvk6tW5GAl44QWoF3M0FQeyzDYGi5MlXyc2IgvWBJpjdFcUz8YK5x6P?=
 =?iso-8859-1?Q?5MOow0czn3Wmsab/ovCC8DFXSr/HfmL7eDfjGcZcdTecSU6E4o6cMuGk/I?=
 =?iso-8859-1?Q?rC8bkAE=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)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?yAvw8mShWs5J+/wrzniJ36BYF0P8zGRQ+4N6sjaJCFwG/wKpzmB8rJBtkk?=
 =?iso-8859-1?Q?T64zvrfZ7ZEdfbjxlTOQL+h04VNZupTAovzxfOfaLvN4r2MgTWEC/xxpRQ?=
 =?iso-8859-1?Q?i27ilFeu0doBq1qXP//tfXK54DgzNjxDjAXzAWoR92EqZj2QlMF9hlPa3p?=
 =?iso-8859-1?Q?NpPsY4PJ6YnIVQMZKiBQFwKN7do9Wld/o0h/VkL0W6nBeferVisdApudMd?=
 =?iso-8859-1?Q?vCccG4XjbvjaOsoZ1z1Mc7WkGP5fbOlRuEocSTskKhrj/CFEU+eIt745Y0?=
 =?iso-8859-1?Q?MdSxEU05lMijxef78uxE45no4CCPnkuoQjfW08yhkX0Nu58cJAC4p1UadH?=
 =?iso-8859-1?Q?8FB8qegEA728xemIe9H5jrOy+wvE+2mlFGtvD/uLfeMwIG7dhOvatiKrM2?=
 =?iso-8859-1?Q?W08en1PI6JOuO6tc7aydYJb/tpjrRFiQPrw8r6W4XdypkPPzz+cmbV2yl+?=
 =?iso-8859-1?Q?S4TLC1QRipyEtmT5eGhomQyvfXOepwzbd6KjqECRYEY9WRKgFEmesydnfh?=
 =?iso-8859-1?Q?vuCugswVl9hYhslIxsxUoNEbCIK3EMNxq+DD4ZwCJkJ/zCtgKsGl3sOK20?=
 =?iso-8859-1?Q?ZbTIC2MdjsHfY3XWXtYZfPqYtmuwCmIJiMZlSu6qlN4ASdHUVR0dAqvFqO?=
 =?iso-8859-1?Q?K2/KHwjwXnDuOwEV1vADkmsk9uX8aIbrBaYnfl4ggn8z0sv8+57+knDBvN?=
 =?iso-8859-1?Q?+U0Rpo8pbsC5H6FISbkjOWzRwYHkvz9+TndOT0snop259SJlBfZn9dALwb?=
 =?iso-8859-1?Q?a1Ty3s9apA9if/itK+SBeGcg0ZZA2i1d9t7B1OQ+dYSR/T6X9BYrMxddWG?=
 =?iso-8859-1?Q?k4xBVnUkt1QMvaPj2xnbrK3DJOEP2YFPzQ+q9EhWTGsRZy5SPYB0+w3nCN?=
 =?iso-8859-1?Q?a7mX7CXMH0LGbKZwdv0J6G4k0VdnRt9yh7Dhxh6knm3YsCImvXovagr0q9?=
 =?iso-8859-1?Q?HZkUufTOtzzJj+Oh28VGZEt9O2PYzPO57cVxC+vSkJ1U3FKaYJOzDNmQQO?=
 =?iso-8859-1?Q?K5SwICgqXOTHlFDUP3UTleG8m+2v6/+VMfgPHcjc+eILnIk9gWd2ihSZcf?=
 =?iso-8859-1?Q?3ZrhBaT7bBZT3g8E4wKsWwQ6rE6739rcONy6X+XkzFB/FxVAdj3nNwR+hp?=
 =?iso-8859-1?Q?ltBznz9qOhRaJypx3tFZFddyecV8uqdyWBLwOVzJuAbAZFPWNNROoS2Ao4?=
 =?iso-8859-1?Q?9YbM2/pjtQ7Kfo4SpAzhj/5IEOx7TubyafLdJfwFFfroTOd6wxnAvngkDs?=
 =?iso-8859-1?Q?/UGLoWpZjMRPY/YbIRco1RcNpKHFhsahlTnqvyTBcQx+VaavaM/ah8jL4B?=
 =?iso-8859-1?Q?iMwNTL+ovp1mFhkgs9nh00S7rNyE/oIVTJTMSWrsbrs++weEluYBUnEg3K?=
 =?iso-8859-1?Q?lfQ5CoHXITUYQTMVyIxUC1uwhmtZj/fM7Yw6gVh7xsSXM6pzsXJeb18IRo?=
 =?iso-8859-1?Q?JMgTlrk7m99EOUFb+LBGlhzNYzoilkEYnhsMunjAld/GxMaRPSpC5ZNlvY?=
 =?iso-8859-1?Q?03KSYKWH1MZfR3sqIPXFuh1gTAd6Jd1oOzuW5eiNAR4ZMcC9WxBWRBH2Kh?=
 =?iso-8859-1?Q?Qn0+wdEVN9SB/YWCp0GE/PuGFqVFSflzBuKVkGIVQOGrAm+NJTvrgk+mM/?=
 =?iso-8859-1?Q?YWsdPotg7MmmSMw83DYNU3p7e8yB/toABMI0ktx98LciRLNdfAN3Cpig?=
 =?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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b7bf8982-bf92-49fd-ecc7-08ddf390dc39
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2025 13:16:05.1678
 (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: lz97l1hIJJW1V9U2UokDmODMJDTWRyhNtJg+czjbQcGVvV7LzcyLdJjaloqDyeRlmOO6ehC5zYFPI+GIoqybrrsVpGg9wQjPP1t0CNgqKOs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB6243

Remove redundant domid_free() call in the XEN_DOMCTL_createdomain error
handling path to prevent a double-free condition.

When domain_create() fails, it internally calls _domain_destroy() during
its cleanup routine, which already invokes domid_free() to release the
allocated domain ID. The additional domid_free() call in the domctl error
path creates a double-free scenario, triggering an assertion failure in
domid.c:

    Assertion 'rc' failed at common/domid.c:84

The domain creation flow is:
1. domid_alloc() allocates a domain ID
2. domain_create() is called with the allocated ID
3. If domain_create() fails:
   a) domain_create() calls _domain_destroy() internally
   b) _domain_destroy() calls domid_free() to release the ID
   c) domctl incorrectly calls domid_free() again

This double-free violates the domain ID management invariants and causes
system instability. The fix ensures domid_free() is called exactly once
per allocated domain ID, maintaining proper resource cleanup
semantics.

Fixes: 2d5065060710 ("xen/domain: unify domain ID allocation")

Signed-off-by: Oleksii Moisieiev 
---

Changes in v2:
- add "Fixes:" section to the commit description

 xen/common/domctl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 71e712c1f3..954d790226 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -421,7 +421,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_d=
omctl)
         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;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 13:27:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 13:27:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123860.1466559 (Exim 4.92)
	(envelope-from )
	id 1uxmkq-0001OL-Md; Sun, 14 Sep 2025 13:26:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123860.1466559; Sun, 14 Sep 2025 13:26: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 1uxmkq-0001OE-K2; Sun, 14 Sep 2025 13:26:56 +0000
Received: by outflank-mailman (input) for mailman id 1123860;
 Sun, 14 Sep 2025 13:26: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 1uxmkp-0001O3-7O
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 13:26:55 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7524aa67-916e-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 15:26:45 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by VI1PR0301MB6637.eurprd03.prod.outlook.com (2603:10a6:800:17d::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.21; Sun, 14 Sep
 2025 13:26:42 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9115.018; Sun, 14 Sep 2025
 13:26: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: 7524aa67-916e-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VJAEzOYk0soF8EMXqX5Epttjh1j9lFe4uCwvaBmp8UQWhr8wSo6865j4pzRn10xVzBAgLb8dgRbuwCmxJrf2K5wZC3ezz+py5ubW38azk2OduddEctnzoee2QesQcDwngF4sWr5mcoPcZ4p4agJHkpNuCHpo2SdfWwPlwkT2DHPgaiGRPMtLQkkD2vQUz/3TgiItfR+gMyQl/U8H0CrWBcQ2AN3ZsmpFv+DfDS2DC4ta89ZDV6MV0FJ+eIgngSJak1DZaXhcI5bRY9E7SFXHTFNOSObapw3rMICVrrrOcLf9BBX7rQb+yGanIwj7qIrw7Xks8XHTIztaZ2d5FIZVOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gNAc1qEb/6M5T2GGRl2Ps8WmmqUXUMtwvy5Hlsi5R+o=;
 b=DlNbxRLOIz/pXe4zA/4lkwdsHiZVOYB2dwU8N4Lqx7d5qVUANdtjKcvncM8Y3qhg2WBPYj6cdSALrMd3aG6Zb89SiX2ulhwwsQ1UnCHwhDoogstji9JN88lmO8PixUR+nNkspZQYfqTw/2kn0RD77nuHqjquzU0e329+vLW7fvn1gaUdXlAwuMyhvqucnwDLiLAyqOEM2ql+bAUXvOG+JcuBxfaPQxgDYGIy9S5PxFUBITXU6sQrW0gBWdZtHLUZvapAGaC3W+GjxKPApyKM3s4fSeM9VNhyLJ/asPXzwsjcnaUjy/uWfhEfQ+4rm9Mnl4LvXo6YUHJDPpXjVXWRxQ==
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=gNAc1qEb/6M5T2GGRl2Ps8WmmqUXUMtwvy5Hlsi5R+o=;
 b=OKfg7c1PLClcpVSGc1J4RLIaAwSH3gULhETJkXlKJMGYsjYnsD++jhGZZqMiSyMI2SoMte5OuPzBKmmoLxETlD4xtINNaqG+PPWNhNvfF/6NadQblFxi0eX9+V2pMfk2pw6TGLWD5iGBEvddt2nnHsu8U4eiw3EEgB0dRvmjpz/nSYAPlNoLVDJKbLr6/lEXLOiuwNUb63b6QGFFmrEzOqvd5bMvT5ptQ/1nbDrXzW3kBRDqnnxQvMOekUxOXZRkvaaQzBldiMwV2wEO47nBczMc7Ilf8YqESNgE8DAlZaTolrVI82W2igFH2R6RntIXkSiya+uFXamDYZgT8YF1/g==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Oleksii Moisieiev 
Subject: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Topic: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Index: AQHcJXs1K3LqZ5+aqE65C1kspBdxMw==
Date: Sun, 14 Sep 2025 13:26:42 +0000
Message-ID:
 <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|VI1PR0301MB6637:EE_
x-ms-office365-filtering-correlation-id: 5e0a5920-75af-4101-6a54-08ddf39257f0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?zVob1uerdlOv3cgZqJk2cDMGdso8KAdkSebZNxXOwtxjJzFl0OgRXwWFqQ?=
 =?iso-8859-1?Q?PXRpbkF239S2liFoE40BlU1lj2wlfTNNeSOnsBpKpHJaHCTGRdVz5ny4fN?=
 =?iso-8859-1?Q?Xru+5VjFe8orNHd713B50S4s6n/SItS4Q9v3GkRF73OUeji2+bq9Ikmowp?=
 =?iso-8859-1?Q?UoBoahsrYgB39gbKNx8UZ2OKe8M4polGzXEvlToJXTQNHU8GyPt6tNHnG8?=
 =?iso-8859-1?Q?GcEZmqDyRLbYpuOM3WR04NS61ZghX8PNHyF8e2XPWKnjsS/zIuibaUZsgD?=
 =?iso-8859-1?Q?9AuMxIgYXtERbIjL/aiX8Ef5L3s5XJII3cccAfyjZEi0PUVvOXncBznHB1?=
 =?iso-8859-1?Q?ExSIfivoLWyH4+SkqsTk9cM69ZG+z9u3vtsj8o0NB9tpJ61jXjAf7kImaF?=
 =?iso-8859-1?Q?uuDCWcIwXv/urLa6wEdn6xuZ8Mh+i9qYUMp3b8A82cKq4rtChnmM8eIER0?=
 =?iso-8859-1?Q?v4gnWqAMlORuxA0a0yNEAtNT4qCP0FXTIVD7ACjn3UIRxkUThwz3/k3ohT?=
 =?iso-8859-1?Q?oeREr0bhm+Vkd8kO7t9FXCXZuVgJjwGL6buQV5/vex5u3mqMoD9qgwlNCA?=
 =?iso-8859-1?Q?D3Mfd5Kus5CbQbfhFtMxjMUYDqDcSG0db61elZPucibQKfgMG2ZA+Gcf8V?=
 =?iso-8859-1?Q?NpztiuaqaUFB6sWnedby3CWG2rgM2Ekjnh2O/iWUjUzNsLdZ/tmsox0s9z?=
 =?iso-8859-1?Q?vigBPfuGSG8wFaIOCpwlEVbXKRUA34gvhz8Tm+c9/lI92Bn9fUnsaBf87U?=
 =?iso-8859-1?Q?tR7ws22T24b9fPV4e/J2vYKo6xGZPlG8aLiLBN7W0/GBayuynRnB0Vl4ZL?=
 =?iso-8859-1?Q?+DlHehcym2ZzBVJ0k99RSbbDC70AWc7RMEq6u6Cdh6bHxkJLbbt+TOgs2i?=
 =?iso-8859-1?Q?WPHWFH4NIwaK+zGqZfOhaYTUSPH9LmMTy8yF8epusan9xXl7U6EE5Up3Ex?=
 =?iso-8859-1?Q?a4pEQWKCrDGkhLtIwjh48X64JeBC9nkov1qr78nZLtO2x9N3UFmzsrIfiH?=
 =?iso-8859-1?Q?JfAYzDe+QAp94kAkUDkhz5mJnxRrZ0EiTxsT4ruXnbK5nrhJDPGQqqQoXJ?=
 =?iso-8859-1?Q?8aX1fH3bwgRl8suo6cenvd/9lK1ex6M0XCEywDYtfR9VekOa8l6Qs9AXYd?=
 =?iso-8859-1?Q?3EXECb0bHYzcgNbkycjlZ6DqwY3y3cmUikClfmJVuc3fqutUchSvpWmq66?=
 =?iso-8859-1?Q?yNuEjrzORf98ug+4d/anoIoYIXxIsV6p1Tx37osoPaiqCaL9hI403IbKo7?=
 =?iso-8859-1?Q?4ig6yAkDzTh1PBN8tdoPfHkEWdQMaVoIlRvgjkVHmaLrl7RMQ/9Fceo93U?=
 =?iso-8859-1?Q?XFUpgJKKflC5lhwCJMoqnXUORd62OV13cjmD/dWRBFjL13wyI0jWbb0fvs?=
 =?iso-8859-1?Q?F5rP6Y7vLdBUbWwqENM2JvD6X9eG+IPAsrXP4G/83XKWDOJmIHnE/C+vld?=
 =?iso-8859-1?Q?Yn0UtkGHVX1Ptfb1gmr96UaRv54jo8jUY/DkZDhk+pGZkL532hfhYjNNPh?=
 =?iso-8859-1?Q?R+xYTD0YgWJjplX0z8+f7sMMrI40EC1vlf/x3D3nVhag=3D=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)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?VeIOlZa9Egn2TA/a7+nKSptpWaxKRY027k1ueSaJH2A6Bd0k7hbtNzqKdS?=
 =?iso-8859-1?Q?mfjnGldKSfVilkvuqEIZ/TXobrMBnonTao+OGmFnukVHOZ7dnvhn6ApK9z?=
 =?iso-8859-1?Q?YG9NgCTOvg5INl1sgjXiYc/WwJ15WkRIBwNCq1GqTxwLs5/JwpnAu0dl/5?=
 =?iso-8859-1?Q?Yk7qbx6m5Oh/XnBfhEe0mUeTMX9BBdfmwloQlMZ+GK7ZLjOyQBGdrWWrvv?=
 =?iso-8859-1?Q?F8fMxSFLKbi3IG+maaiPlq7ZSRO9+ovvKszS0iBzWoCxIAba1ZqCIvgwww?=
 =?iso-8859-1?Q?4UAivA3ropCFxd8mVm6ncjeAY7FLddek7x4TofDS8zUf5ex9XuJRsc2c3q?=
 =?iso-8859-1?Q?5yyREEBYvqbqcee2WXa6DRFKMeVWvrWPQSTzGiQU+MTwpVhpzkjX9/ozOZ?=
 =?iso-8859-1?Q?E++hZDKxRfOPjUh4TGz0syr/frLyzccUc4p3Tto39CMzMmrQtJv4hey3ve?=
 =?iso-8859-1?Q?6TIHPm7bVprWXkPfbv28QrnvTUiLUd3RGB+0yiloov04K7kxNC9dB63CME?=
 =?iso-8859-1?Q?pKoA1efordWdsilpfLqafDXuZNWGZTqA3ExWQ+bIzSfkJdCVUxtxWgBM4l?=
 =?iso-8859-1?Q?GHlJCIt9HgK9QErrlsp2SuY5CsRBe/N0J7/cB80aIbw83TQ+iYDfWaSQw3?=
 =?iso-8859-1?Q?YZgGfEP1P+tdmE8iEpPJlYQ7YT+EQxcb6dmEr9pE19WLh6H4ykocbf//K0?=
 =?iso-8859-1?Q?sOmE34Z7MNTfIYHDwGYRd/iAUyPniATpnEkxAC6ZoqosoND30Kta8LHzal?=
 =?iso-8859-1?Q?UzTcapa4KMjKZ6a9Pjim/0tmXSfGszgFxC9EAOmDmF/m3aXQ3ywo6PHcdw?=
 =?iso-8859-1?Q?snarZg2HYRgUZjp5uAW/sGqBNgWQzoqX+I8NhPCdvPe91m94uZeMMU7Jkt?=
 =?iso-8859-1?Q?lAlYMaRiT9qpvvHvOnQgrn2owlSAEqbBVKL996Ag+S3v2SXbkZg0QOkyP4?=
 =?iso-8859-1?Q?dIshDKvqisnhgL0ULsJVylG4Ro63Rr82XBSXdnCEyEflf+3mQLYVmXeect?=
 =?iso-8859-1?Q?X6Jv2EpVntzy0QGo9tGmEaDwAnoUSCW0CwQaIYLFK15wANucEQXjDSZDNJ?=
 =?iso-8859-1?Q?7NeyB3DOqkTmsKGDtOfOBxjYjJjDy6bDSoxOs8yOByuU7/JNnTEGIhw3QT?=
 =?iso-8859-1?Q?lpNNi/WvxCnbNLkpJBLajFFDzhBlDm3mPhxVgCylSpxzpYZnqV/zbtHBii?=
 =?iso-8859-1?Q?MKgfAwfP3/FmbZx1b5WQfeU2llqKHhN8vJlmIEd+S4LO1r7QtdpuD3xJF9?=
 =?iso-8859-1?Q?DsR3j9sZgiBgBbbnFWSjtUQqeIbKrXG9KVHBW7XcHssibbKjnbfYIvkPFt?=
 =?iso-8859-1?Q?Jam3oMBdATBwY9TwRhuDBDk7+qayE7idypoMj/z2CVG5O1gC385jRsLL6T?=
 =?iso-8859-1?Q?9kkFCO37uNjvkj0BlObLkic/9xZKbOEr8vMeyNc8fSdBvBuHnGraTHrwvp?=
 =?iso-8859-1?Q?rbpAUtNZ76AODCuzVs1JXcQlBVG3EZ5NMhrRIgzA5RV3jdbgW9KJe77Pio?=
 =?iso-8859-1?Q?kqyFlBBlzXfRMbHpkiafzN+daimpuM6VnZ+0e56VYS/oLi4/ItOd6IXQbz?=
 =?iso-8859-1?Q?3/3pL1/81wQoNb6PNCEiFwDdPtfXl1dPwL7oNrE2jj105myFjE7wKlgMtP?=
 =?iso-8859-1?Q?aTKfFhuvEpXI4ml8OhSIjBBotQavTCurYiVhsCQwOmymnmrQ55CkJ1JQ?=
 =?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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e0a5920-75af-4101-6a54-08ddf39257f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2025 13:26:42.2419
 (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: SpKVWF9OwafpK3UyprddCvzj981sgoKECc+PZGvkXU0it9I+/gbu/fFBkm0DHg+xANKkrGTuGqbvHZZM1xoP+uWJjBp8HpAAX4A5iTfVhCM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0301MB6637

Move the SCI (System Control and Management Interface) resource cleanup
earlier in the domain_relinquish_resources() sequence to ensure proper
cleanup ordering during domain destruction.

The SCI cleanup is now performed before TEE (Trusted Execution Environment)
cleanup rather than after P2M mapping cleanup. This reordering ensures that
SCI resources are properly released before other subsystems that might
depend on them are torn down.

This change addresses potential resource cleanup dependencies where SCI
resources need to be released before P2M mappings are cleaned up, preventin=
g
potential issues during domain destruction on ARM platforms with SCI suppor=
t.

Fixes: e2cc10867b (xen/arm: add generic SCI subsystem, 2025-09-04)

Signed-off-by: Oleksii Moisieiev 
---

Changes in v2:
- rearrange enum by placing PROG_sci before PROG_tee
- add "Fixes:" tag

 xen/arch/arm/domain.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b..e36719bce4 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1042,6 +1042,7 @@ static int relinquish_memory(struct domain *d, struct=
 page_list_head *list)
  */
 enum {
     PROG_pci =3D 1,
+    PROG_sci,
     PROG_tee,
     PROG_xen,
     PROG_page,
@@ -1049,7 +1050,6 @@ enum {
     PROG_p2m_root,
     PROG_p2m,
     PROG_p2m_pool,
-    PROG_sci,
     PROG_done,
 };
=20
@@ -1090,6 +1090,11 @@ int domain_relinquish_resources(struct domain *d)
             return ret;
 #endif
=20
+    PROGRESS(sci):
+        ret =3D sci_relinquish_resources(d);
+        if ( ret )
+            return ret;
+
     PROGRESS(tee):
         ret =3D tee_relinquish_resources(d);
         if (ret )
@@ -1109,10 +1114,6 @@ int domain_relinquish_resources(struct domain *d)
         ret =3D relinquish_p2m_mapping(d);
         if ( ret )
             return ret;
-    PROGRESS(sci):
-        ret =3D sci_relinquish_resources(d);
-        if ( ret )
-            return ret;
=20
     PROGRESS(p2m_root):
         /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 13:44:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 13:44:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123873.1466570 (Exim 4.92)
	(envelope-from )
	id 1uxn1K-000485-5F; Sun, 14 Sep 2025 13:43:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123873.1466570; Sun, 14 Sep 2025 13: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 1uxn1K-00047y-2V; Sun, 14 Sep 2025 13:43:58 +0000
Received: by outflank-mailman (input) for mailman id 1123873;
 Sun, 14 Sep 2025 13:43: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 1uxn1I-00047s-3w
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 13:43:56 +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 da7ce60a-9170-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 15:43:53 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3dae49b117bso2605853f8f.1
 for ; Sun, 14 Sep 2025 06:43:53 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-32df2bf49b1sm3496242a91.1.2025.09.14.06.43.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 14 Sep 2025 06:43: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: da7ce60a-9170-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757857433; x=1758462233; 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=dKoCnE6l414VKWhPoxHQvdoC8TQFdArRiHZZAzXuJPk=;
        b=bELoh1HYrEJysdvtTamp7M3keFdZzG3mzzIy0WD5Mep3V4n95EtObpFbOmlFpOsxvx
         xPvNixZxxyYgFqDuyGCR3HTue7t1Rlbkd20GEEAx/ukXA4OGqj+sf5M7PxmrmUrnuqXn
         uBNzH6uVZl2HcCpyWI5nFS1O0LPCRQKZogTlbN4QqdwnrDNvuiVU0alRgtuf3+fyetzA
         bKeU6kjj2Q5Snlc9TrXEsEZqQJTc43aCrjrVaQ5FNVDWS2/kyJJumIQkWGrXG5+qgyiN
         bEYdGX95UFWUr2jkMvxPV1dglAzh08qCLtr2z9/RlPZSHLBKqFAsKKrzlmtLsSCjOT5S
         XorA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757857433; x=1758462233;
        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=dKoCnE6l414VKWhPoxHQvdoC8TQFdArRiHZZAzXuJPk=;
        b=USzWEfdSnlObuvsdx7K2ROcUnM66ZX2O80MKhxKvzEeWoff/Ecls34yV4ZViGl0xuF
         kuqFsESrDntu3H0a1fYnDnxJkZOFBYQOtXub+7lJfO9g04mRze25F7UQdq3KIWg+Fcvg
         fZ0yu7mnNBzXLjxxUWnWxqPn2glK3We5TROfZv2RRHtxi/qGJPEVLFg6MAF6d8ABJflt
         2gkcHU5ZY8HxkNuRaCJpz6J2cj9Q4xZNp5QmBbv5P7cwOZ+kwLEsWLqL+LtLVNqBgWg4
         gbNDfjcAht4PPPEBcs5DUENeqS+N8D2kkrNOJWtQG1cH9N+uX9xancFDz8KL07cI0ocQ
         85Gg==
X-Forwarded-Encrypted: i=1; AJvYcCVDqH2onW8bkbeFzM0m6xydfpvYy5uBt/dct0rstqQnCVEdBrxnxMrVj5TETyjEcVtoJ6m9KvEOluE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOoyYWs5Hwgy33q92pRQXnxpPDm4orNudiXp4XYfML+Iom3BJ0
	qdkylXAQLBGzRBStnllna+uaQk4TMJWrxnTImm9XfZ5gF8jwRiRdmk5bIDSGMuCGlA==
X-Gm-Gg: ASbGncvZvPtpeHMo3WiW3vfCzyJVwp6L7Qrcfrp+Le7md8hR1CZNsOLEMux6vqYc3tN
	rhNIlZ1J6rGZenpw8YpQAS1Acx/IJ/Lf6AxsVy/35EIWR+RxX8CH8OhuGIANUL7kGgpfQqsjlxD
	gouSCQa5r8rODKEHZm5e19hx7qjY6hxHeG1KhlFvPIZLRdcqLvKvnPbUm7ZVQK9c6O5fnaiwZmZ
	+FMgyOVfvGrc1sDgJuzPYZIOJw35ORAQVsuxLWD1aTAhZo4UScIInozuG7Jg9OMIV8mPFN0KH1d
	YzrGcGToJ3PMYvtQOkOMzb3DEknVCjKPLNRHtX898QBCMo3zDCVmOW3RBCEoiE18WUFPEbXbY/o
	Z4QcbgI25oqtE5mFjSvUpOzM/nU3uVArh4WqVeEe8kA==
X-Google-Smtp-Source: AGHT+IHddcuDiwmhwy8tIym6TxHFInfVIoVq9M2Ao0l5IdkMBZYzrYZf2oHFbrZS+nN14BhNvtlIEQ==
X-Received: by 2002:a05:6000:208a:b0:3d7:eb95:b1e1 with SMTP id ffacd0b85a97d-3e7659eb4admr5824405f8f.32.1757857433167;
        Sun, 14 Sep 2025 06:43:53 -0700 (PDT)
Message-ID: 
Date: Sun, 14 Sep 2025 15:43:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] releases: use newer compression methods for tarballs
To: Julien Grall , Andrew Cooper 
Cc: Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" ,
 Oleksii Kurochko 
References: 
 <53d760ad-c58d-4d3f-bd66-598b4a95a8ff@xen.org>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <53d760ad-c58d-4d3f-bd66-598b4a95a8ff@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.09.2025 23:23, Julien Grall wrote:
> On 11/09/2025 09:14, Jan Beulich wrote:
>> Other projects have long switched to xz and/or lzip.
>>
>> Tidy things some as well: With the removal of qemu from the tarball,
>> intermediately extracting the tarball again has become wasteful. Drop
>> that. Invoke compressors using asynchronous lists, to reduce overall
>> latency. Drop the -v option from the (previously implicit) gzip
>> invocation.
>>
>> Signed-off-by: Jan Beulich 
> 
> I have tested manually the steps and the correct tarballs have been 
> produced. I will update my scripts to copy & sign all the tarballs once 
> this is merged.
> 
> Acked-by: Julien Grall 
> Tested-by: Julien Grall 

Thanks.

> Is this intended for Xen 4.21?

So far it was, but I'm increasingly unsure, seeing that it still hasn't
gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
rm use, but hasn't come back as to his argument towards the uncompressed
tarball previously not having been removed (when I can't see that one
would have been created in the first place), hence why I couldn't make
use of his (conditional) R-b.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 13:49:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 13:49:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123889.1466579 (Exim 4.92)
	(envelope-from )
	id 1uxn6j-0004sV-RU; Sun, 14 Sep 2025 13:49:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123889.1466579; Sun, 14 Sep 2025 13:49: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 1uxn6j-0004sO-Oz; Sun, 14 Sep 2025 13:49:33 +0000
Received: by outflank-mailman (input) for mailman id 1123889;
 Sun, 14 Sep 2025 13:49: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 1uxn6j-0004sI-Bi
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 13:49:33 +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 a3b28e5e-9171-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 15:49:31 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ea3d3ae48fso189476f8f.1
 for ; Sun, 14 Sep 2025 06:49:31 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-32dd620a64dsm12239775a91.8.2025.09.14.06.49.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 14 Sep 2025 06:49: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: a3b28e5e-9171-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757857771; x=1758462571; 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=pW/+k4+KI0qELuCUefA1eTNn6dv6V3ftKzgsVCCt42A=;
        b=WRe9B5+3mMkMcDka12dO2a9MAnpYJNwwVUyuYGhlstfiqKlbHKG/FN1FBaJLoqj00o
         1KvZn2vJLoXF98Lb9pKeNgcO6+WyfW/d2+roLtu/Kxed2UVp3a0BtESQp5EwgznGoyBd
         hqtRDfz1/RJpgEHeKAjJ6PcRtX7K71X4FumI7QIFnmQHBBYCDrZ1A40lnBzivLYl8erZ
         QIVFRU8hC0hCjZZIrqAKRDuKYl/mue9QfTznO0yzk8oveKSkSEgEnUqRKf6AgQVgBH0d
         fWYOMtxwuZhSFOoH0jzafM6d4FY9VmNwmXe7wqmOBTFB9HHIJWIcNlA/b5aPsHEjInev
         A4kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757857771; x=1758462571;
        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=pW/+k4+KI0qELuCUefA1eTNn6dv6V3ftKzgsVCCt42A=;
        b=qO/nitg96KEZkXh9WdWFCww168uKQhdIWvsLjI0Hh69cX7v1RMCtbIOFjKu2BL80+z
         UmYgoIN1bKeh2T72wjhJ6OAT0fek29Hu6OgPrC5YILQidaLo/Xz4wBC2704Yf575cmDJ
         BnfFmHh1NdzgzaaWPd28JRayYAemiIwNfjJtY0UBkjro87hwJqN0qCVINvsH85S27bS+
         HQRSsi+E+YkyNdpOnYof0iu7ppINWablHiaANXyFKdbiU5i3ce4SKGDGJ2SqP4DwR2Vx
         kMAuMTMRa2U6rz20Hug2tniOVjnZ7DWQ3e+5b0P2ydWK8vsk8PzHHQLnzuZ4fODHFt/5
         K8iQ==
X-Forwarded-Encrypted: i=1; AJvYcCUUGFFvr2ZvyezcvJZL64fsqMATxY32KGm68vJlkT4hraOzKe9v8egB5wo6359nHry8BaeWyppGDu4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOdb3UMVgnl5Xhr3NtdWzadaDRVd6CbXqL9/cPEpiURDqkqUmJ
	tpfyytAm/6e8fbuXjQT8juNCMW+bIaUZPUJPrK/MxtbRFmWlfwc2r1ahSTGzcOtGUw==
X-Gm-Gg: ASbGncvLHeKYYaGVLo/NQshLtcviqsr2TkEzqom1OPfNMMTSWlvg9tO0/Fx8XLN7MNw
	4qR0dTpPoMH78MRgk2xX5Fm/vLCWLs5O0jdsjrozlyS2Sk/1BtgZM400KE1ETg23YaqQvzZSdR7
	gOOWTE52yOb+rjZBRlQ3QchFmVjRTbVYLLQzT1U+oEp6Tpk+e8293j5gyG6tn6ZbrjRRYCRNIG3
	MBapk57gYFv5M14rOuLKjlRnIF3Jo8lrvDoTckm4C3/GQJU69P2lIMeMO41aWSSWELCeOAy5QTP
	+UOxGMka7DKiqRBLsyraofb321Q8c1axZ8qAlf7Sexd5lUzEQ+TnpkZ/s1U2aHPAgxjGAP97lcm
	NSUrNQQTdafF4o+jk7ewKKvqD3WT1F3iw0DgUfQYk/Q==
X-Google-Smtp-Source: AGHT+IGtn/M0UGs7OVW81zJaWqH1M8LU5Y33+XeEc0V8f3hfQAi1pRjgrEQTVtAo+bQmX77TWJPeBQ==
X-Received: by 2002:a5d:64e9:0:b0:3e2:3717:cce5 with SMTP id ffacd0b85a97d-3e75e16b341mr11002810f8f.30.1757857770818;
        Sun, 14 Sep 2025 06:49:30 -0700 (PDT)
Message-ID: <2a818f1b-4326-4335-8ca5-4301632b1f33@suse.com>
Date: Sun, 14 Sep 2025 15:49:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
To: Tamas K Lengyel 
Cc: Penny Zheng , ray.huang@amd.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 xen-devel@lists.xenproject.org, Oleksii Kurochko 
References: <20250912045254.3731398-1-Penny.Zheng@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.09.2025 01:24, Tamas K Lengyel wrote:
>>> +static inline bool vm_event_is_enabled(struct vcpu *v)
>>> +{
>>> +#ifdef CONFIG_VM_EVENT
>>> +    return v->arch.vm_event != NULL;
>>
>> Is "enabled" (in the function name) a good description of this condition, Tamas?
> 
> Sure, sounds fine to me.

That is the pointer alone being non-NULL identifies "enabled"? And not
just e.g. "active" or "available" (can be enabled with further things
set up)?

Jan


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 14:04:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 14:04:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123907.1466590 (Exim 4.92)
	(envelope-from )
	id 1uxnKr-0007gM-2c; Sun, 14 Sep 2025 14:04:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123907.1466590; Sun, 14 Sep 2025 14:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxnKq-0007gF-V7; Sun, 14 Sep 2025 14:04:08 +0000
Received: by outflank-mailman (input) for mailman id 1123907;
 Sun, 14 Sep 2025 14:04: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 1uxnKp-0007g9-Sa
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 14:04:07 +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 accfb45d-9173-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 16:04:05 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3df2f4aedc7so2186448f8f.2
 for ; Sun, 14 Sep 2025 07:04:05 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54b169f2edsm6274277a12.19.2025.09.14.07.04.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 14 Sep 2025 07:04: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: accfb45d-9173-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757858645; x=1758463445; 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=dsmjXoPv7LF/hLNfx6ZHyF/RI9YKI26DbYA/q8yIU8c=;
        b=Vz5LzdamoG4C7fRQCf9pzii+j9NThH1g+ipmV5j5d2NJSI+7QjY1Ud7v+fKBMLb1wj
         cs7uHeyP7sLkcH/iSH6oNKwKinUbuML+upXm+/zOypZJlYpD7Kjfp6Zlfcy9JlYOoErE
         R61oF7FeBmLGc25TrHki7Dtn6XZcHbxQwLFEWxYVHAFh0tzi1NS9VxgmO9C2nR+KEbCv
         v+cNJipZB029mwnxWxNLkN56A/FsJuBS2qxuJhytaGxwrm9TPeqC14in0DkXwsNMFMg7
         iVV2FjojCsJ8TAtra7hVHSFzrgHTDVQUL+/7uS+tVtYri0P73nzxoccmjP7EoV/JGPd6
         Jx8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757858645; x=1758463445;
        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=dsmjXoPv7LF/hLNfx6ZHyF/RI9YKI26DbYA/q8yIU8c=;
        b=HbIkiLJUXFBlvYa2S6UVsWZL+8RMvDN+hEpReH3w9Ek8BgbKJrW51d+eEVvuQTNf8L
         GRzx8FBFc3C+e+m6cyDzmikOfzc4S4MkIJXvRuGFq+NEZzlisdhfYHPfJzLiNtKUJx34
         LMZXqN4DKI2LrZZvrUVk8j1axXXHOyn0lSHg1VaFJY5w664Y8M9Moxrp9pQbYQ50yjA6
         /4nKfbRUXbFWluezopDIGKDHziFdeVIvKrTxkN/L+YOkdGaZt31Wpr4H2QZyOVATlpNp
         keN1xA0YU0EWLQY/fyLaHhMML1PZnCy+o2QB7VunMQzSgUkWcf10cqDkY5Bn3pPDOnqG
         +7IQ==
X-Forwarded-Encrypted: i=1; AJvYcCXPwybBCtk96HWnKBKX3kxG13pd3igJYw2KICw0wgEtgTG3ZH415hsdsE2i4o8+j/vCGEZmns7xuks=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+ULE34jb+RkBFRHqm0dMjjcGImiICImb8OojqNngGxxESes5I
	nt7CZ4oShMQZL+hvkOV3dv2sVbA5c64geraQi9cEHeLYJEXHr6U9JdS57V0n+N3u0w==
X-Gm-Gg: ASbGncve+z/TqKy7UVqoIxmcQatxUA2l9KYoAaBa6HxPe2u6myeYa0OovSQGqPO4o/t
	POkj4EHvIpYYBW5aK7M8iGmPsG97kyJMy+OdcxDvmu0E2PzvF2dgdx8VV3FROvjVcdjFLGA0Akk
	MMA7CNmXSVUY+EChVnMa6vSO12/j2f9oo235QfX36Sp9uzX29axVqYDOpckk0bastpLuLtOpsvQ
	t+cY9ceXfZxWTmss8aM9yJl6Ca06SNrzwR797imwc3/6CpodUMnuQf1f+ZHLT+j3CFPr1on6Uem
	VD0WtNtI524m9z2s1a3wGb+TT0S4p8Go4rdl/m3ZVCL0TH9VwkZAMya2cS+JvWA9PCE/djxpn8l
	nXYlPeObvTpyQcNvnUP6EyNrM2gpAv8w=
X-Google-Smtp-Source: AGHT+IG3EALCbIVw6udqHMHC4INP5RXjlKqtBvT93BHbdY4YVjI46JF3j0Dtesc4nV+Vm5ZQRgHxjQ==
X-Received: by 2002:a05:6000:2384:b0:3e7:484a:7428 with SMTP id ffacd0b85a97d-3e765a3dee2mr7947494f8f.60.1757858645101;
        Sun, 14 Sep 2025 07:04:05 -0700 (PDT)
Message-ID: 
Date: Sun, 14 Sep 2025 16:04:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
To: Tamas K Lengyel , Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-5-Penny.Zheng@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.09.2025 01:31, Tamas K Lengyel wrote:
>>> @@ -99,10 +98,40 @@ long p2m_set_mem_access_multi(struct domain *d,
>>>  int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access,
>>>                         unsigned int altp2m_idx);
>>>
>>> -#ifdef CONFIG_VM_EVENT
>>>  int mem_access_memop(unsigned long cmd,
>>>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
>>>  #else
>>> +static inline bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
>>> +                                               xenmem_access_t xaccess,
>>> +                                               p2m_access_t *paccess)
>>> +{
>>> +    return false;
>>> +}
>>
>> So this is needed when VM_EVENT=n and ALTP2M=y. Tamas, is this a configuration
>> which makes sense?
> 
> Yes, altp2m should be functional without vm_event being enabled. There
> could very well be in-guest only use of altp2m via #VE. This function
> is used in p2m_init_next_altp2m which means it being stubbed out like
> this when vm_event is disabled breaks altp2m.

Oh, indeed - the stub still needs to handle XENMEM_access_default. Of course
with MEM_ACCESS=n it's not quite clear to me what p2m->default_access ought
to be; imo in principle that field ought to also go away in that case
(becoming hard-coded p2m_access_rwx). While doing that will be a larger
patch, perhaps using the hard-coded value here should be done right away.

Once the code correctly handles MEM_ACCESS=n as an implication from
VM_EVENT=n, it's also questionable whether MEM_ACCESS_ALWAYS_ON should be
retained.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 16:59:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 16:59:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123957.1466600 (Exim 4.92)
	(envelope-from )
	id 1uxq4X-0002NF-1i; Sun, 14 Sep 2025 16:59:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123957.1466600; Sun, 14 Sep 2025 16:59:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxq4W-0002N7-TA; Sun, 14 Sep 2025 16:59:28 +0000
Received: by outflank-mailman (input) for mailman id 1123957;
 Sun, 14 Sep 2025 16: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 1uxq4V-0002N1-FL
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 16:59:27 +0000
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com
 [2607:f8b0:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2b2009d7-918c-11f0-9d13-b5c5bf9af7f9;
 Sun, 14 Sep 2025 18:59:26 +0200 (CEST)
Received: by mail-pf1-x42d.google.com with SMTP id
 d2e1a72fcca58-777ea9fa8fdso196224b3a.0
 for ; Sun, 14 Sep 2025 09:59:26 -0700 (PDT)
Received: from ?IPV6:2601:646:9e00:b920::2bf4? ([2601:646:9e00:b920::2bf4])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-776ad32de79sm3968603b3a.63.2025.09.14.09.59.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 14 Sep 2025 09: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: 2b2009d7-918c-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757869165; x=1758473965; 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=MAqmMOu1BH7n12vnVRqeSfPqzwKV3ZVtFtGYBvTCHQ4=;
        b=IIcbR3jmUUjjsZB4pSLnFusIshReAd4o5jJIWIS0uRnKE4Ivo2/OHeEq7AWF3Og2B9
         Hc6vKQoKUtobs7QF1p0rgFWOfO3dD7nrC/BXd/oAmMzETy2VoJVvGTacHDOZtZqVt3aD
         s1VQgoNH7hFCw/48/9feMSvGq+MWE4H70rAiMyEE5svgxsRUfzYp2trEJDbFofWg2cbr
         XakOLL8K4CXQleGtOkViHBO5VAw7AIfUFRFS8jMjr9Vd61aefbvMm2EmQCJV/Kgwi2Nr
         UxpRXvYT2npiFXYDzsowUVNM7EwPAd8iQrO7cbtcX2kKFrOaw5xeYRjElrG9s0AwG/GK
         +Log==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757869165; x=1758473965;
        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=MAqmMOu1BH7n12vnVRqeSfPqzwKV3ZVtFtGYBvTCHQ4=;
        b=AR0/Fbm5f1DZO9Ngw7odTb+nvn6heU92OuVZSwGjQTU/z40f0LkUtw/P7kjcgH7+eS
         oshfAQilqKdMRTjlgvoFkuD4pXxz/S6a5ladMMkPYCO3Ml92+qsnINAvZZ4dR8GmZdeB
         yLQrr0pLc2D3NUGiSli00qK0z489BVuqObVwMFShEXJwKTzBbU8Gk8q7LVLVY6JBOFJO
         HqIBZRXzRBSFr2Z/lHsy8OKiI4jEMPq1xkM3PLsLQqwFxZ8yAEkkwPXe3DdkdKi9rsR6
         iNQGJ+GdCNvSwQMJK4sAw9ADJqCuYaANKy18m+R015NcoRDdVSFT38okeWoMWeeed8ef
         AIjA==
X-Forwarded-Encrypted: i=1; AJvYcCUzcMa7eqVB8sV/YI7Hrc3QnrG1WiuSpHUDamb4g+f8zZG4JFG/jDhoCVTLfNNeg/xSJwk1VIQXSxk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywq7IQOvbGQl1N7CYTh47fCND33LJeL2Ou55SL3v0OEkXe1eezT
	YBexnV/EL1Qs8+oxQ+D4vO4Vla6YnybYHlucLYrbLSXbLTL+2nggYUf7
X-Gm-Gg: ASbGnctYmnGsp7keVElh1G9e9jUuB0TcSM/h195OH8JBlawz8YBejbDabCtP0VIw70F
	mh0gArXIa7bX4+wifYXZC3z3grd7twEII12LnyzU1DaXQ/eiGROw8GvOaiz6ZIqMpTfqvnQbrYk
	qh/dXwwBp3RYYUUTJ9AxK4AipCCXiDI4CBxDHpzucrFhHEvy+x/3Tm/0uzUgQuM4xRu5QQHEMQz
	GSNRd4QH46slzjdd3CTrwqVw7H2XN43fbpcdyYwEw9QdVy53zeRkJC0SL8Pmqj/bYUknrKf5PS4
	PzTznUlYDeWRjQ2tOholuRvc3LW3emGVLTJ3UFI4RlhYG9qKtrqA0sVqkUTFOf7WAmyCG1iQxRm
	fWam91+/ML+niNg9XDizHWdLswjrRszoPp4TLcWWKID6MZ80fHoxNCg==
X-Google-Smtp-Source: AGHT+IHxEbB31XLUPk/YbhKXYG4jGeWF3F80cfkz+/PVRvEfldxizqTDfSEE66o5/XsxftmralkRqQ==
X-Received: by 2002:a05:6a00:7583:b0:772:348b:8883 with SMTP id d2e1a72fcca58-7760332ba31mr11782190b3a.13.1757869164634;
        Sun, 14 Sep 2025 09:59:24 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------ytewXNeJqlkI5UHe9sSa9p4A"
Message-ID: <7c017dec-91e6-4637-842e-8210ae8022d7@gmail.com>
Date: Sun, 14 Sep 2025 18:59:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] releases: use newer compression methods for tarballs
To: Jan Beulich , Julien Grall ,
 Andrew Cooper 
Cc: Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" 
References: 
 <53d760ad-c58d-4d3f-bd66-598b4a95a8ff@xen.org>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/14/25 3:43 PM, Jan Beulich wrote:
> On 12.09.2025 23:23, Julien Grall wrote:
>> On 11/09/2025 09:14, Jan Beulich wrote:
>>> Other projects have long switched to xz and/or lzip.
>>>
>>> Tidy things some as well: With the removal of qemu from the tarball,
>>> intermediately extracting the tarball again has become wasteful. Drop
>>> that. Invoke compressors using asynchronous lists, to reduce overall
>>> latency. Drop the -v option from the (previously implicit) gzip
>>> invocation.
>>>
>>> Signed-off-by: Jan Beulich
>> I have tested manually the steps and the correct tarballs have been
>> produced. I will update my scripts to copy & sign all the tarballs once
>> this is merged.
>>
>> Acked-by: Julien Grall
>> Tested-by: Julien Grall
> Thanks.
>
>> Is this intended for Xen 4.21?

IMO, it would be nice to have that in Xen 4.21.

> So far it was, but I'm increasingly unsure, seeing that it still hasn't
> gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
> rm use, but hasn't come back as to his argument towards the uncompressed
> tarball previously not having been removed (when I can't see that one
> would have been created in the first place), hence why I couldn't make
> use of his (conditional) R-b.

There is not too much sense in the uncompressed tarball. I prefer to not
generate it at all.

Also I have regarding .gz. If other projects switched to xz and/or
lzip (as it is mentioned in the commit message) what is the purpose of
having .gz tarball then?

~ Oleksii

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



  
    
  
  
    


    

    
On 9/14/25 3:43 PM, Jan Beulich wrote:

    

    

      
On 12.09.2025 23:23, Julien Grall wrote:


      

        
On 11/09/2025 09:14, Jan Beulich wrote:


        

          
Other projects have long switched to xz and/or lzip.

Tidy things some as well: With the removal of qemu from the tarball,
intermediately extracting the tarball again has become wasteful. Drop
that. Invoke compressors using asynchronous lists, to reduce overall
latency. Drop the -v option from the (previously implicit) gzip
invocation.

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


        

        
I have tested manually the steps and the correct tarballs have been 
produced. I will update my scripts to copy & sign all the tarballs once 
this is merged.

Acked-by: Julien Grall <jgrall@amazon.com>
Tested-by: Julien Grall <jgrall@amazon.com>


      

      
Thanks.



      

        
Is this intended for Xen 4.21?


      

    

    
IMO, it would be nice to have that in Xen 4.21.



    

      
So far it was, but I'm increasingly unsure, seeing that it still hasn't
gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
rm use, but hasn't come back as to his argument towards the uncompressed
tarball previously not having been removed (when I can't see that one
would have been created in the first place), hence why I couldn't make
use of his (conditional) R-b.

    

    
There is not too much sense in the uncompressed tarball. I prefer to not
generate it at all.

Also I have regarding .gz. If other projects switched to xz and/or
lzip (as it is mentioned in the commit message) what is the purpose of
having .gz tarball then?

~ Oleksii

  


--------------ytewXNeJqlkI5UHe9sSa9p4A--


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 17:57:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 17:57:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1123974.1466609 (Exim 4.92)
	(envelope-from )
	id 1uxqyJ-000148-1U; Sun, 14 Sep 2025 17:57:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1123974.1466609; Sun, 14 Sep 2025 17:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uxqyI-000141-Uw; Sun, 14 Sep 2025 17:57:06 +0000
Received: by outflank-mailman (input) for mailman id 1123974;
 Sun, 14 Sep 2025 17:57: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 1uxqyH-00013v-Dq
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 17:57:05 +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 374eb079-9194-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 19:57:02 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3e7622483beso1700790f8f.3
 for ; Sun, 14 Sep 2025 10:57:02 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-25c36cc6adcsm107083635ad.7.2025.09.14.10.57.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 14 Sep 2025 10:57: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: 374eb079-9194-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757872621; x=1758477421; 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=MMVbcPts/TfyGtp/9rEYYPMaMs38KHK+eMYy+Om5bqM=;
        b=Sx9FMb5UevUDFT1zspGr8uUFbDEkiM4C1TwztYyUmSd0fxpZ1/D+k8kkLkXivd23Kd
         70UPhj1vWNMA+QmWYY68wLnv4h+v245cF+AvtvK5mhteHnZ1VpX+6sGHxi+om+cQWU0i
         3z6kDx1hkFX7aNhvfNXnaNTs1U1aAYRPk3H8cmGezuxsRPZpEOAV44QU1V89Tq74trzc
         zri9IUrfLOCnB4Ip8KW2cSuDL8/HvqsT1xFGcDV3A44OWH+C+15eBVXY/Zq+aT3Z80vx
         s3A4nRxSxf5Yz9N5amv6IyAVIYJ2AeZjTiqOfoxtCLECNYdwJaBhDSih6dfcJuEyt/BP
         uRLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757872621; x=1758477421;
        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=MMVbcPts/TfyGtp/9rEYYPMaMs38KHK+eMYy+Om5bqM=;
        b=fk39mM6noQg3eCz3n4Ft7BKjHkFZNXem9tKR3nabYUfUP8VgX7lPnbKlcUdULBbV2h
         WisS4WQSfONuxKDIuXD+cwG/SSa9Viwqr4iWz/YEo+UdtdTiW6OlZtjdpRqAaxZDHZTt
         aRorQWtv6TIyl6gM5neA2aBbR9gjQSNwEb6WqX5Lsaz9Y5eJnuCawFnHBRP4EOXhG1Yd
         J32IigHugcJTi/bjqF1HG8nJwpeSr8/S2T6dMzor+e7pDCT5d4pLcoHAJDgk7N1c9eAX
         hDi/TkTBEYwDprzcuoi94O1VVetQKI3NmT4Uv+AzLXgdyEhfM3/qZby/VeKF0hhjSNkA
         yP4Q==
X-Forwarded-Encrypted: i=1; AJvYcCUiVbAIWpzAoSZALtNevtcPqk9dMjbqxL6EQRhiZzATQ+0Go1IIlUkfAOz8NwIm0F6kZGRPdk4mMrI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRO9tyYk3ABxgUlmwHSUNYpenXdhDoPGfdvoSeNcGyqDj/c/mf
	xGSKrk3/caDIFLUQlXF6b1jNT9/sH0XTDE+6TjgvP/WuPWIxAR02ieQNq6AarWlB5g==
X-Gm-Gg: ASbGncuHkcwWTC7gX050k8lR2Ok1xov+N3tHNdKVPUYMa3O2OR3YaBdNtet0ayr2eXC
	W2D2p08Ykz6FfgcvroT7Qi9B1OWF8Lf/Rj0/OFHQH+nVmJpBuE3h8cPS1JrUhV/n8mE7lJSJgkx
	Hi7qRHeo8Oebv6XF4d7JlCmJAKT1ZDA7pgEHdfP4wn5CAa7q7J2KeCxanw0dsImqCItiIXFpLwQ
	JoAwTi0wqFuBmkKx3Ql0LOJ+6NLLkKsndKz2YqW83MCZ1b4NB32yKqOPQueGzAyiTJr00sa3ufG
	oBW/0ht+7X/+/SDaeUuCDQTTeQ2Emo0D+W9PeL0t1OtezBdbNs34XQIv4EHIMJroZlZg31KDfeM
	0Q2F9kHFxAiuX0IjNkyJmlMbZZ71BLUEWYjXWDLAIDTgiLku6lYGd
X-Google-Smtp-Source: AGHT+IFpt0/ASKXY6P2+J9kA4e7qsuFEorNDxY7nmROUYbSQYAxe/i3Q9WxeuSw3jKVoEtwmr747Qw==
X-Received: by 2002:a05:6000:2486:b0:3e7:404f:685 with SMTP id ffacd0b85a97d-3e765a197ebmr8875378f8f.44.1757872621190;
        Sun, 14 Sep 2025 10:57:01 -0700 (PDT)
Message-ID: 
Date: Sun, 14 Sep 2025 19:56:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] releases: use newer compression methods for tarballs
To: Oleksii Kurochko 
Cc: Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Julien Grall 
References: 
 <53d760ad-c58d-4d3f-bd66-598b4a95a8ff@xen.org>
 
 <7c017dec-91e6-4637-842e-8210ae8022d7@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <7c017dec-91e6-4637-842e-8210ae8022d7@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.09.2025 18:59, Oleksii Kurochko wrote:
> 
> On 9/14/25 3:43 PM, Jan Beulich wrote:
>> On 12.09.2025 23:23, Julien Grall wrote:
>>> On 11/09/2025 09:14, Jan Beulich wrote:
>>>> Other projects have long switched to xz and/or lzip.
>>>>
>>>> Tidy things some as well: With the removal of qemu from the tarball,
>>>> intermediately extracting the tarball again has become wasteful. Drop
>>>> that. Invoke compressors using asynchronous lists, to reduce overall
>>>> latency. Drop the -v option from the (previously implicit) gzip
>>>> invocation.
>>>>
>>>> Signed-off-by: Jan Beulich
>>> I have tested manually the steps and the correct tarballs have been
>>> produced. I will update my scripts to copy & sign all the tarballs once
>>> this is merged.
>>>
>>> Acked-by: Julien Grall
>>> Tested-by: Julien Grall
>> Thanks.
>>
>>> Is this intended for Xen 4.21?
> 
> IMO, it would be nice to have that in Xen 4.21.

May I translate this to a release-ack then?

>> So far it was, but I'm increasingly unsure, seeing that it still hasn't
>> gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
>> rm use, but hasn't come back as to his argument towards the uncompressed
>> tarball previously not having been removed (when I can't see that one
>> would have been created in the first place), hence why I couldn't make
>> use of his (conditional) R-b.
> 
> There is not too much sense in the uncompressed tarball. I prefer to not
> generate it at all.

Generating is helpful, to do it only once (instead of once per compressed
tarball).

> Also I have regarding .gz. If other projects switched to xz and/or
> lzip (as it is mentioned in the commit message) what is the purpose of
> having .gz tarball then?

At the very least to help people presently assuming they'll find a .gz.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Sep 14 21:17:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Sep 2025 21:17:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124026.1466620 (Exim 4.92)
	(envelope-from )
	id 1uxu5g-0006nE-FL; Sun, 14 Sep 2025 21:16:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124026.1466620; Sun, 14 Sep 2025 21: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 1uxu5g-0006mv-9l; Sun, 14 Sep 2025 21:16:56 +0000
Received: by outflank-mailman (input) for mailman id 1124026;
 Sun, 14 Sep 2025 21:16: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 1uxu5f-0006mk-1I
 for xen-devel@lists.xenproject.org; Sun, 14 Sep 2025 21:16:55 +0000
Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ffada21-91b0-11f0-9809-7dc792cee155;
 Sun, 14 Sep 2025 23:16:49 +0200 (CEST)
Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233])
 by smtpout-04.galae.net (Postfix) with ESMTPS id EBAB9C8EC7C;
 Sun, 14 Sep 2025 21:16:31 +0000 (UTC)
Received: from mail.galae.net (mail.galae.net [212.83.136.155])
 by smtpout-01.galae.net (Postfix) with ESMTPS id 092936063F;
 Sun, 14 Sep 2025 21:16:48 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)
 with ESMTPSA id 76865102F2A78; 
 Sun, 14 Sep 2025 23:16: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: 1ffada21-91b0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim;
	t=1757884606; h=from:subject:date:message-id:to:cc:mime-version:content-type:
	 in-reply-to:references; bh=PrFkxRI/rM5SQxoVJY6C6jishZsikS57oIN/hwunQlI=;
	b=j+82wh8EW/26ftt8B3pTo1EF6a84LZS/ds3nQRpCwbhT3EnmTALAHRvlO8AaJPUcIhLHT/
	gl6jy60jXJho+DItqUqAiO30JedIhLNi6Q8iHiliohdlf/U1fzqVAfru1ocswYYozJrZ6b
	G8T1SuFDUk3FEl5M8tYxF5FckzXCm3SvxGXKysA2w/fNni0aqN7/YjLZ7Qrcx+e+82gmuN
	TrF/Uq8mV4ZHEstaLbfM1ST8YeXhs0i1w7ilUCrIHelmL+RBtOtGJN4y4l7FAtcPFuJc7e
	9AmDmRUv8YBvnRbWBiulqtUTQeRPGkyMscOZZNXSS0NMEANY+15EN7K4nD8YnA==
Date: Sun, 14 Sep 2025 23:16:29 +0200
From: Alexandre Belloni 
To: linux-kernel@vger.kernel.org, Ard Biesheuvel 
Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel ,
	Heinrich Schuchardt ,
	Feng Tang ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Sunil V L ,
	Bibo Mao , linux-rtc@vger.kernel.org,
	linux-efi@vger.kernel.org, xen-devel@lists.xenproject.org,
	x86@kernel.org, linux-riscv@lists.infradead.org,
	loongarch@lists.linux.dev
Subject: Re: (subset) [RFC PATCH 1/3] efi-rtc: Remove wakeup functionality
Message-ID: <175788449957.388732.6353062596898107602.b4-ty@bootlin.com>
References: <20250714060843.4029171-5-ardb+git@google.com>
 <20250714060843.4029171-6-ardb+git@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250714060843.4029171-6-ardb+git@google.com>
X-Last-TLS-Session-Version: TLSv1.3

On Mon, 14 Jul 2025 08:08:45 +0200, Ard Biesheuvel wrote:
> The EFI rtc driver is used by non-x86 architectures only, and exposes
> the get/set wakeup time functionality provided by the underlying
> platform. This is usually broken on most platforms, and not widely used
> to begin with [if at all], so let's just remove it.
> 
> 

Applied, thanks!

[1/3] efi-rtc: Remove wakeup functionality
      https://git.kernel.org/abelloni/c/50562f9cd366

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 03:49:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 03:49:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124104.1466630 (Exim 4.92)
	(envelope-from )
	id 1uy0De-0001Ap-NE; Mon, 15 Sep 2025 03:49:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124104.1466630; Mon, 15 Sep 2025 03:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uy0De-0001Ae-ID; Mon, 15 Sep 2025 03:49:34 +0000
Received: by outflank-mailman (input) for mailman id 1124104;
 Mon, 15 Sep 2025 03: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 1uy0Dd-0001AX-R2
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 03:49:34 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20614.outbound.protection.outlook.com
 [2a01:111:f403:2406::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb94ad67-91e6-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 05:49:31 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::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.9115.19; Mon, 15 Sep 2025 03:49:26 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9115.020; Mon, 15 Sep 2025
 03:49: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: fb94ad67-91e6-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U+IeRCbPZZ7ngm4APNBQIleokgnNXTSOgBnWBQX7Y0qz0grUD+09T6nCPraFMfvColTWzkVPMKMavU6O2P+uEkLv7J+bSt3VfDgOSegXCqD/aSCwsvEfTq2Xep1Jgk3lmn/CiPPk0TL8FWJjzwcHhZuezeVPGJfGXbKykJQ/WexbG4DObkxTtjKHZbDVobYg7RSFN5YKCM+yeNN7tbaTjoLoTEXoP/yYYtR2ocVbqcvzY3VwEP7E6qUGMCRxIHbn0vzC2zOYkT3ffqQKRhaaSNgPq5qW5oU4SZwP4ZY5uBlq3R5U+ASiar9mo+dm9OVQ1t/QeBjTCrjiDBGfZJDquA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SkSSqu4YI08dqY4Va5eTOo1UDxeCudbje/fjLRUGmNw=;
 b=ZLMyQkIQ4MB0XrG9gJdAXwghQgkW44sB5xb+Vwn8jOCf534Q8yz0jqwjXoko0+3mVd++Ge39VshPH+l6lVsjusnbFqmTfa5fTjOixctS2t2W3zjgh34pJYu7scv3H2EcjOUmfoh9qTB2FM57DN804F2VxdhM5+4aymIe3thQG6EV9NjnMBfJ2O4i+sz41v+gdkQN9YfCNe2UeBDcR/LxRm+vJ23wPNKkFjvi5vzoAVqp0QRXkQmjkyWkpg9UMBbwlN5c7XbU/eiYqbA4bUYzdm+W0ZpEaxtTWqLwE3gz1O1DfCHxinXx6hX+dc7L8m6HZK6q/YNasRgOBXd437XgsA==
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=SkSSqu4YI08dqY4Va5eTOo1UDxeCudbje/fjLRUGmNw=;
 b=GO+nx4jqgTkc7D6UvNvOjxaebbxqNpvbHIn+t54aG7sZblxpe0Vj3b3pRjgxRQjPhuVy0sNWO+32yPBYo3WJYcdc0UgmiSi/P7R0l3wPk47E/jvmKgJQC+tAbiZISPqL9pcJgcq8kHn0f+Q9dMaPX4M+9gdkuwdcAIKFigH9aZg=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Andryuk, Jason" , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , Stefano
 Stabellini 
Subject: RE: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
Thread-Topic: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
Thread-Index: AQHcHWYoX5yLBs91qkCeYarmDUxFSLSC6XqAgAD6+DCABTACAIAKkulw
Date: Mon, 15 Sep 2025 03:49:26 +0000
Message-ID:
 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@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-09-15T03:30:49.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_|IA0PR12MB8746:EE_
x-ms-office365-filtering-correlation-id: 5f8fa64f-e7b1-42d5-6b9d-08ddf40adde3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?TDBGR1NTL0VkSWIvNGsyRVN4SVloOFRWeFkxOG93U2VXME5CVFhlZ0dtOGxr?=
 =?utf-8?B?R01uU1V5M09tVXJ5Q2JtNmcvUGlXV3dwSXdxeFR4d1p6Q0NOKzlEWmpBNGFJ?=
 =?utf-8?B?cnpoWVBTK0VESExKWjM1eC9pTTlUQjVncDJQUlRTZGkrdFlLRUdYYi9NNUVB?=
 =?utf-8?B?bFZQVXc3MlBJRnlwck1QaWhjK0FGNGxVdllwdW5hUklXTlF0T3NNU3MvRWts?=
 =?utf-8?B?TXpiL1owVEd0a0ZQS0lRVFFUZEhHWmpGNUd5Q0V1dWV1WTgwYVdCOWFlVCtF?=
 =?utf-8?B?QnJwOW1HQnQ1NEdMbkJDL3R4Nnp4S0tGVFkvaTRDVWVkNU1nRU5YandvWnQ1?=
 =?utf-8?B?STlMVEJqblJxSFlWVlB0Z1JRVjlnRStjQjJQbVd3TjJIMHZXYnpMOFFnc01D?=
 =?utf-8?B?dG8raDdkK0lnYjNTbEF6Z2FTS3RTUGpHamVUMjloTTR1ZGxjUkJIdjZ6Wlh3?=
 =?utf-8?B?Z0RIVjd5WG82VWlPOVV5MVZ5dXNjVUZlYTdjVm5oRFJ3dW8yWTFwdHQ5NGpl?=
 =?utf-8?B?LzlKT3V6anEzTEYzSk1STitYVTVrbzBoTCtad3hDRVlJQWlSSUhTU3JxcXpU?=
 =?utf-8?B?TGJjWWJoelkvN2piaUl2RGxkNzFiL1pjaXpVbngrMGpJRGU2K2QwL3NxS0ti?=
 =?utf-8?B?aG5SV0VFN3Z5MXZMbVhVdllUMFlWSW84QTZUWmVYRzRqbURCK0FWNFJna0pY?=
 =?utf-8?B?NTFWd0czQmRvdHZ0elZRSGQyRzh6Ry9xdjk5QnJrL0tMZHJ4ZE9FU0Vtbmgz?=
 =?utf-8?B?bjM3ZmQ4ckhlZkZnK2wyZ1ZKeTROVnpQUE9qY2dyekhNSkVCakVZRnVDVXJI?=
 =?utf-8?B?Y2tyVENTbDBrNC9qR1BxeGRBbUh3R3J0dnh5NFJFb2IwWmNlMzZET2JVY3dU?=
 =?utf-8?B?dTBxVmFiRmZQRW5lSnhlS1oyQ0VMekVEbXZ5dzgrSFJFSkxWQ0hxYlB1Rk5V?=
 =?utf-8?B?TzBTRG9YNWorTFRZNStKV1pFZzY5RnV0VDlmT0tBbzUvR3gyY1VCaWVveW5s?=
 =?utf-8?B?dXlaOTRSYlpjMnZVTFJyd1NMUzFqKzBqVkRWS2lDL3pjQzhaTDg3L0d1SlV6?=
 =?utf-8?B?a21WUXd6eDQ4MzE5cDhVallSd1VRVmlRbE9kcWw0eE1YVjlER0xhL1RJaW4y?=
 =?utf-8?B?RHB6eEs4aFpuZ05VdWk5M0dNS2xlQjlpU3NOWlRVQkY1L0krYW5KYTFEWDNS?=
 =?utf-8?B?emdCWncvcHpDLzMrNnZHN0VNbVRjNGppWVpTSTI3UU50R1Q3WVpSVkoxanNH?=
 =?utf-8?B?bVErbHZkaTViQnlpaVF5dU5zNzNYUmNua3RleVNIQXl2amFGSC9PZGZYL1Fl?=
 =?utf-8?B?WnR1UUZud3lGb3Jub21Ha0c1WnZVcjNFdWR2b2dhaHdtVVFBNWFRQXNZaTBh?=
 =?utf-8?B?T2EzRkgyRmNqV01LYXlCNmFoSkZ1eHUxZ1NjaGVNMzlQcU03QXlZVGdRVG1X?=
 =?utf-8?B?MjdnL01WanMxTmJmM2V1aVJhUGVocFlGaUhsbS9GWnVpUlh5dnlsZytIRytC?=
 =?utf-8?B?QmxGcGF0aUZTWFVhbU9veS9wL0hCZHhNR2tOaWtRak1tMk5IcExGc01BUHlw?=
 =?utf-8?B?Vzl1ZFNBdStEMEJDc0t0aGNOOVd3elVXM1B6dldydzlCQ3ZWdHZva2lGdlli?=
 =?utf-8?B?VTgrN2RDU1pESys3QzVhY1MxdHRyL2o4dUhoWE1kSGFDWkZ5WmkrMXp6Z25Z?=
 =?utf-8?B?RW5ib2VKR1F5NFBPRnNHVXJhekxlN1gwYjlHc2l1VmR4ZEc2ZzRRdStQVVk3?=
 =?utf-8?B?MWRTeWRTVmhLa3Q5VnBkUENVZ1E2dEdaankyc1gwamxheSt5S1RWU3cxOGxk?=
 =?utf-8?B?bkkwZXhjd3VQRWp1d1hUMFRha05SLzlXazgwbkNkOWVEQUhxMEpkdnBFMFZn?=
 =?utf-8?B?OTNxZERDNXNYdDl1MlJQR2gvUmpGV0ZkUmV5VUFBMEVqbWlZbjkzeEFvd3Vm?=
 =?utf-8?Q?VBmDldkY+0I=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eWtFYTl6b2ZCVThmVDltT0xJK3NzL1hLVmM4RVM4WVRyU1dWZzJXUWJLQito?=
 =?utf-8?B?bDBRelk3c29sRjJ4clA4dUNFR3l1SUVNZ1IxMXBkTXlWU2N3RTBzMUxxakxY?=
 =?utf-8?B?NnBMbG1zRDZnQXdnVllzL1A0eHBiT2M2QzRDNVl6MG1lcVVZN1B0dmw1RjUy?=
 =?utf-8?B?VzY0cUJGUnk3TGpJTDFWM3VGeEd3bUR5Z1ZIZXdJMWZHcDlJcFYxTlhta3Fp?=
 =?utf-8?B?Z0tObWJPc3pOeXg3VEJCZDYxakN2UGc0WGZ6VnloczJiMVVOVGdHTDRXZWJD?=
 =?utf-8?B?RVd5RXcwd3ZicG1SVE0ra1JJeUFCV0hIK2M3bmVrNSt5YzRsenE5V3BVTHFH?=
 =?utf-8?B?YnJ4SjlVSFhVaFhqVmtsTnpUckdDUGN4V0sxQlFBcXFCM0tnOFlDbEtrTlJC?=
 =?utf-8?B?Zm5BM1ZxU0hBMkhFQlpmV3B6OHlJckxBd21KaGNYVTk2d3NqdW5jTWlUK2w1?=
 =?utf-8?B?VGNKZzJ0bzBieCsvV3BoekZZVjhtUDBrSmFhc3VRYkxWNU5yWW5KaUh6Qlk1?=
 =?utf-8?B?UXpPSGpwbFJSTzFHUjVzTTExUG1EWXBzYzZOTWdJcm8yVkNUVWZYNTdEL29m?=
 =?utf-8?B?OXUwSDViVnUxTVY4NkJ5UFR3d0FaWlk5K3R2QkkxNGNMNGRIMm9RR2JoWFpC?=
 =?utf-8?B?ckFZSEFPSXBNWFpjSUtQOGJReEdIVm5YMndJR1gwUnlsME9SOTZIQWc3UGE3?=
 =?utf-8?B?UFd6eXA4cmRRRTdxY1dNT2ZzbWJpUWRDd2tlQTE3NkgyVGJqNUp5VmQxUVA4?=
 =?utf-8?B?ZjhsQmxXZVpsMVhiNUdrN0NDZ2JRZ0pRTDJzN2xuYzBqUTRkMm9RS0RqdHE5?=
 =?utf-8?B?bVVFaHFUU2NHbVNoNzl3QzJxY1lxeklCanVYTk9HVnU2ZURkVGdYMUQybjly?=
 =?utf-8?B?ZCtRM2NoOWJ1NWFkL2ltbEVmSm9SenBXQVE0VkZLRUltVDBLTCtnRkN6T0kv?=
 =?utf-8?B?ODNDdU1iZ09TMEE1dWFpRHhKL1FNWkd4cDBEdjJOWm9ZRFVYYnFJK3M2c2JD?=
 =?utf-8?B?Z3VQQ1RDZ1h0ZCt5RGlwOThFSU1VUEtWOHFKaU5LMkxNY204bHc5VG4zR1JX?=
 =?utf-8?B?TmlCbks1cUIwSEdMZjFkUEd6UjlwMW8xUDNCQzJDSlM1RlJHaG9oUEVCdzBz?=
 =?utf-8?B?MUpKR0w1bmZYQzdsQzluZnZTTllJRzJMeWxBMVdlY3NLaU9NMTB5d1g0eDE5?=
 =?utf-8?B?NXY1OXlPbVJvL3F2Slc0dFd6dmRlU20wWmlndEo2eUd1SU1KVC9keXJMc2hT?=
 =?utf-8?B?V0o1Q0VuWXRJWjJjcmpIekhUeFVQTmthMVdvdUUxbllTYnBIWEtNdjBoZjdv?=
 =?utf-8?B?SWZhaEFnM3A5eHhKeUFFQkVNVjVKVDQwVUl1L05sZHRmWFY2Z0RZMTZMU2RI?=
 =?utf-8?B?cFJwTTlPcDFYVmpoRkRRb0VQVDlxeDZSUDdFRHgxUUMwMHp0UVM5Zzh2QzFC?=
 =?utf-8?B?ZzczcDd5bjh4V0dYZEhiTitrUmhuR25qak9GbUdqeHF1R0tyMEdud1hmMXZr?=
 =?utf-8?B?VGNabkkwV2FEckk4SExRS2FQNGZ2cjJLemlCeXY2Q2JTWVFJUys3YVdLYkRL?=
 =?utf-8?B?UzF1TnBKK1VoS1JpMmxTcEFKSzYzSXY1bnF5bFlyYyt4WjNsNkFmZ0RRM0lW?=
 =?utf-8?B?R2lsa3BkTjR0M252Nms1ZlBNYTB6azVmT2EzbWlacTZudUZCK0VNLytyMDNO?=
 =?utf-8?B?b25wNnl6UmlQY01oOUt2WjdsOUVKNG52YjFtUEFmTDVJOXczODNzaEw5dkhR?=
 =?utf-8?B?RkIySWpYRlhORGlpSDVTNllrYjIrVUZIdEFXSDRFQ3E2a0I0eUpkZngxcFY5?=
 =?utf-8?B?UUFXRjgydEdWR2xwZU9RcmJUODUxQ0szMEdmZnc5QWMzajZEUVFnZGhBUm5Q?=
 =?utf-8?B?aHMxa2pETjRtaWVrYlRWWHV0bGxBRzR5Y3FuZTBuc3hZSm9UV2RMKzhIYVR0?=
 =?utf-8?B?SVJ2K00rNldCMnV3RkpmUzdKYmpWVHlVV0d4cG9EQW81WVNDejlnQkxEODhm?=
 =?utf-8?B?WUxvcWxjdzZ1NGdYMHltOU96SHZFZXFQdkVFNGtvSUVTZjBlVDBHSkJyLzhk?=
 =?utf-8?B?cHBsTnA0T2JhMnF0WHZOaXoxREZBM1BTaHJ5VENsWjZiSThZUFZwTHBvdFlM?=
 =?utf-8?Q?DzOA=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: 5f8fa64f-e7b1-42d5-6b9d-08ddf40adde3
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2025 03:49:26.5413
 (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: JLMQU4kU/Kqbni3G2ejM+sFqh/Er7nWZWkJJK+RciiYbwp+OzxzPDvg4hV/h2emQau7Q/qSZlB+kxsdlmCs06Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8746

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDgsIDIw
MjUgNjowMiBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD
YzogQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNvbT47IHhlbi0NCj4gZGV2ZWxA
bGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OSAxLzhdIHhlbi9j
cHVmcmVxOiBlbWJlZCBod3AgaW50byBzdHJ1Y3QgY3B1ZnJlcV9wb2xpY3l7fQ0KPg0KPiAocmUt
YWRkaW5nIHRoZSBsaXN0KQ0KPg0KPiBPbiAwNS4wOS4yMDI1IDA2OjU4LCBQZW5ueSwgWmhlbmcg
d3JvdGU6DQo+ID4gW1B1YmxpY10NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiA+PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+ID4+IFNlbnQ6
IFRodXJzZGF5LCBTZXB0ZW1iZXIgNCwgMjAyNSA3OjUxIFBNDQo+ID4+IFRvOiBQZW5ueSwgWmhl
bmcgPHBlbm55LnpoZW5nQGFtZC5jb20+OyBBbmRyeXVrLCBKYXNvbg0KPiA+PiA8SmFzb24uQW5k
cnl1a0BhbWQuY29tPg0KPiA+PiBDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kNCj4gPj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsg
eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djkgMS84XSB4ZW4vY3B1ZnJlcTogZW1iZWQgaHdwIGludG8gc3RydWN0DQo+ID4+IGNwdWZyZXFf
cG9saWN5e30NCj4gPj4NCj4gPj4gT24gMDQuMDkuMjAyNSAwODozNSwgUGVubnkgWmhlbmcgd3Jv
dGU6DQo+ID4+PiBGb3IgY3B1cyBzaGFyaW5nIG9uZSBjcHVmcmVxIGRvbWFpbiwgY3B1ZnJlcV9k
cml2ZXIuaW5pdCgpIGlzIG9ubHkNCj4gPj4+IGludm9rZWQgb24gdGhlIGZpcnN0Y3B1LCBzbyBj
dXJyZW50IHBlci1DUFUgaHdwIGRyaXZlciBkYXRhIHN0cnVjdA0KPiA+Pj4gaHdwX2Rydl9kYXRh
e30gYWN0dWFsbHkgZmFpbHMgdG8gYmUgYWxsb2NhdGVkIGZvciBjcHVzIG90aGVyIHRoYW4NCj4g
Pj4+IHRoZSBmaXJzdCBvbmUuIFRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSBpdCBwZXItQ1BVLg0K
PiA+Pj4gV2UgZW1iZWQgc3RydWN0IGh3cF9kcnZfZGF0YXt9IGludG8gc3RydWN0IGNwdWZyZXFf
cG9saWN5e30sIHRoZW4NCj4gPj4+IGNwdXMgY291bGQgc2hhcmUgdGhlIGh3cCBkcml2ZXIgZGF0
YSBhbGxvY2F0ZWQgZm9yIHRoZSBmaXJzdGNwdSwNCj4gPj4+IGxpa2UgdGhlIHdheSB0aGV5IHNo
YXJlIHN0cnVjdCBjcHVmcmVxX3BvbGljeXt9LiBXZSBhbHNvIG1ha2UgaXQgYQ0KPiA+Pj4gdW5p
b24sIHdpdGggImh3cCIsIGFuZCBsYXRlciAiYW1kLWNwcGMiIGFzIGEgc3ViLXN0cnVjdC4NCj4g
Pj4NCj4gPj4gQW5kIEFDUEksIGFzIHBlciBteSBwYXRjaCAod2hpY2ggdGhlbiB3aWxsIG5lZWQg
cmUtYmFzaW5nKS4NCj4gPj4NCj4gPj4+IFN1Z2dlc3RlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVs
aWNoQHN1c2UuY29tPg0KPiA+Pg0KPiA+PiBOb3QgcXVpdGUsIHRoaXMgcmVhbGx5IGlzIFJlcG9y
dGVkLWJ5OiBhcyBpdCdzIGEgYnVnIHlvdSBmaXgsIGFuZCBpbg0KPiA+PiB0dXJuIGl0IGFsc28g
d2FudHMgdG8gZ2FpbiBhIEZpeGVzOiB0YWcuIFRoaXMgYWxzbyB3aWxsIG5lZWQgYmFja3BvcnRp
bmcuDQo+ID4+DQo+ID4+IEl0IHdvdWxkIGFsc28gaGF2ZSBiZWVuIG5pY2UgaWYgeW91IGhhZCBD
Yy1lZCBKYXNvbiByaWdodCBhd2F5LA0KPiA+PiBzZWVpbmcgdGhhdCB0aGlzIGNvZGUgd2FzIGFs
bCB3cml0dGVuIGJ5IGhpbS4NCj4gPj4NCj4gPj4+IEBAIC0yNTksNyArMjU4LDcgQEAgc3RhdGlj
IGludCBjZl9jaGVjayBod3BfY3B1ZnJlcV90YXJnZXQoc3RydWN0DQo+ID4+IGNwdWZyZXFfcG9s
aWN5ICpwb2xpY3ksDQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgdW5zaWduZWQgaW50IHJlbGF0aW9uKSAgew0KPiA+Pj4gICAgICB1bnNpZ25lZCBpbnQgY3B1
ID0gcG9saWN5LT5jcHU7DQo+ID4+PiAtICAgIHN0cnVjdCBod3BfZHJ2X2RhdGEgKmRhdGEgPSBw
ZXJfY3B1KGh3cF9kcnZfZGF0YSwgY3B1KTsNCj4gPj4+ICsgICAgc3RydWN0IGh3cF9kcnZfZGF0
YSAqZGF0YSA9IHBvbGljeS0+dS5od3A7DQo+ID4+PiAgICAgIC8qIFplcm8gZXZlcnl0aGluZyB0
byBlbnN1cmUgcmVzZXJ2ZWQgYml0cyBhcmUgemVyby4uLiAqLw0KPiA+Pj4gICAgICB1bmlvbiBo
d3BfcmVxdWVzdCBod3BfcmVxID0geyAucmF3ID0gMCB9Ow0KPiA+Pg0KPiA+PiBGdXJ0aGVyIGRv
d24gaW4gdGhpcyBzYW1lIGZ1bmN0aW9uIHdlIGhhdmUNCj4gPj4NCj4gPj4gICAgIG9uX3NlbGVj
dGVkX2NwdXMoY3B1bWFza19vZihjcHUpLCBod3Bfd3JpdGVfcmVxdWVzdCwgcG9saWN5LCAxKTsN
Cj4gPj4NCj4gPj4gVGhhdCdzIHNpbWlsYXJseSBwcm9ibGVtYXRpYyB3aGVuIHRoZSBDUFUgZGVu
b3RlZCBieSBwb2xpY3ktPmNwdQ0KPiA+PiBpc24ndCBvbmxpbmUgYW55bW9yZS4gKEl0J3Mgbm90
IHF1aXRlIGNsZWFyIHdoZXRoZXIgYWxsIHJlbGF0ZWQNCj4gPj4gaXNzdWVzIHdvdWxkIHdhbnQg
Zml4aW5nIHRvZ2V0aGVyLCBvciBpbiBtdWx0aXBsZSBwYXRjaGVzLikNCj4gPg0KPiA+IENoZWNr
aW5nIHRoZSBsb2dpYyBpbiBjcHVmcmVxX2RlbF9jcHUoKSwgb25jZSBhbnkgcHJvY2Vzc29yIGlu
IHRoZQ0KPiA+IGRvbWFpbiBnZXRzIG9mZmxpbmUsIHRoZSBnb3Zlcm5vciB3aWxsIHN0b3AuDQo+
DQo+IFlldCB3aXRoIEhXUCBhbmQgQ1BQQyBkcml2ZXJzIGJlaW5nIGdvdmVybm9yLWxlc3MsIGhv
dyB3b3VsZCB0aGF0IG1hdHRlcj8NCj4NCj4gPiBUaGF0IGlzIHRvIHNheSwgb25seSBhbGwgcHJv
Y2Vzc29ycyBpbiB0aGUgZG9tYWluIGFyZSBvbmxpbmUsIGNwdWZyZXEgZHJpdmVyIGNvdWxkDQo+
IHN0aWxsIGJlIGVmZmVjdGl2ZS4gV2hpY2ggaXMgYWxzbyBjb21wbGllcyB0byB0aGUgZGVzY3Jp
cHRpb24gaW4gX1BTRCBBQ1BJIFNQRUMNCj4gZm9yICJOdW0gUHJvY2Vzc29ycyIgWzFdOg0KPiA+
IGBgYA0KPiA+IFRoZSBudW1iZXIgb2YgcHJvY2Vzc29ycyBiZWxvbmdpbmcgdG8gdGhlIGRvbWFp
biBmb3IgdGhpcyBsb2dpY2FsIHByb2Nlc3NvcuKAmXMNCj4gUC1zdGF0ZXMuIE9TUE0gd2lsbCBu
b3Qgc3RhcnQgcGVyZm9ybWluZyBwb3dlciBzdGF0ZSB0cmFuc2l0aW9ucyB0byBhIHBhcnRpY3Vs
YXIgUC0NCj4gc3RhdGUgdW50aWwgdGhpcyBudW1iZXIgb2YgcHJvY2Vzc29ycyBiZWxvbmdpbmcg
dG8gdGhlIHNhbWUgZG9tYWluIGhhdmUgYmVlbg0KPiBkZXRlY3RlZCBhbmQgc3RhcnRlZC4NCj4g
PiBgYGANCj4gPiBbMV0NCj4gPiBodHRwczovL3VlZmkub3JnL3NwZWNzL0FDUEkvNi41LzA4X1By
b2Nlc3Nvcl9Db25maWd1cmF0aW9uX2FuZF9Db250cm9sDQo+ID4gLmh0bWw/aGlnaGxpZ2h0PWNw
cGMjcHN0YXRlZGVwZW5kZW5jeS1wYWNrYWdlLXZhbHVlcw0KPiA+DQo+ID4gSSBrbm93IHRoYXQg
QU1EIENQUEMgaXMgb2JleWluZyB0aGUgX1BTRCBkZXBlbmRlbmN5IHJlbGF0aW9uIHRvbywgZXZl
biBpZg0KPiBib3RoIENQUEMgUmVxdWVzdCByZWdpc3RlciAoY2NkWzE1OjBdX2x0aHJlZTBfY29y
ZVs3OjBdX3RocmVhZFsxOjBdOw0KPiBNU1JDMDAxXzAyQjMpIGFuZCBDUFBDIENhcGFiaWxpdHkg
UmVnaXN0ZXINCj4gKF9jY2RbMTU6MF1fbHRocmVlMF9jb3JlWzc6MF1fdGhyZWFkWzE6MF07IE1T
UkMwMDFfMDJCMCkgaXMgUGVyLXRocmVhZCBNU1IuDQo+ID4gSSBkb24ndCBoYXZlIHRoZSBoYXJk
d2FyZSB0byB0ZXN0ICJzaGFyaW5nIiBsb2dpYy4gQWxsIG15IHBsYXRmb3JtIHNheXMNCj4gIkhX
X0FMTCIgaW4gX1BTRC4NCj4NCj4gQWl1aSB0aGF0J3Mgbm90IG1hbmRhdGVkIGJ5IHRoZSBDUFUg
c3BlYywgdGhvdWdoLiBQbHVzIEhXX0FMTCBzdGlsbCBkb2Vzbid0IHNheQ0KPiBhbnl0aGluZyBh
Ym91dCB0aGUgc2NvcGUvc2l6ZSBvZiBlYWNoIGRvbWFpbi4NCj4NCg0KU29ycnkgZm9yIHRoZSBs
YXRlIHJlcGx5Lg0KSSBoYXZlIGRpc2N1c3NlZCB0aGlzIHdpdGggaGFyZHdhcmUgdGVhbSBub3cs
IHRoZXkgc2FpZCB0aGF0IHdlIHNoYWxsIG5vdCBleHBlY3QgYW55IHZhbHVlIG90aGVyIHRoYW4g
IkhXX0FMTCIgZnJvbSBfUFNELCBpZiB3ZSBoYXZlIF9DUEMgdGFibGUsIGFrYSwgQ1BQQyBlbmFi
bGVkLiBNYXliZSBleGNlcHQgZm9yIHNvbWUgaW5pdGlhbCBpbXBsZW1lbnRhdGlvbnMsIHdoaWNo
IG1heSBvciBtYXkgaGF2ZSBub3QgcmVhY2hlZCBwcm9kdWN0IHJlbGVhc2UsIHRoaXMgbWF5IHN0
aWxsIG5lZWQgYSBmZXcgdGltZSB0byBsb29rIGZvciBjb25jbHVzaW9uDQpBbmQgaWYgaXQgaXMg
SFdfQUxMLCBpdCBtZWFucywgaW4gY29kZXMsIHdlIGFyZSBpbnZva2luZyBwZXItY3B1IGNwdWZy
ZXFfZHJpdmVyLmluaXQsIGFsbG9jYXRpbmcgcGVyLWNwdSBjb3B1ZnJlcV9wb2xpY3ksIGFuZCBl
dGMuIEluIEhXX0FMTCwgT1NQTSBjYW4gbWFrZSBkaWZmZXJlbnQgc3RhdGUgcmVxdWVzdHMgZm9y
IHByb2Nlc3NvcnMgaW4gdGhlIGRvbWFpbiwgd2hpbGUgaGFyZHdhcmUgZGV0ZXJtaW5lcyB0aGUg
cmVzdWx0aW5nIHN0YXRlIGZvciBhbGwgcHJvY2Vzc29ycyBpbiB0aGUgZG9tYWluLg0KDQo+DQoN
Cj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 05:48:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 05:48:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124138.1466639 (Exim 4.92)
	(envelope-from )
	id 1uy24h-0006lF-Sr; Mon, 15 Sep 2025 05:48:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124138.1466639; Mon, 15 Sep 2025 05:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uy24h-0006l8-Pi; Mon, 15 Sep 2025 05:48:27 +0000
Received: by outflank-mailman (input) for mailman id 1124138;
 Mon, 15 Sep 2025 05:48:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uy24g-0006l2-WE
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 05:48: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 97e446ef-91f7-11f0-9d13-b5c5bf9af7f9;
 Mon, 15 Sep 2025 07:48: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 05E2143F68;
 Mon, 15 Sep 2025 05:48:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1FCDC4CEF1;
 Mon, 15 Sep 2025 05:48: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: 97e446ef-91f7-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757915302;
	bh=QmA1uWtopyZKqYFa3aB5R38vcRhwp6UNA5QEhCCpxlY=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=LY4R44OPNzL3Qer2vVNQup9uUTcNx43gZqh5FwLU0Oh1PdFVX0Y/KMu9Uvifa32bq
	 LKQg8b7U2pc5ik4+PxHv4Vxaw4OOg+vsmxh8TnpYqhx/pMCEM27S4kfw09R8Z3+SrS
	 WOCH3NphTYB7cis3wXHahmF9XEuFQFnTdwnEgrsxicfvxKQHyvsgH5+RBeSZZNlt+1
	 jN5OeNDI/I13LeozFgh3Z/w6y7Zqmf8gbZ1coqUma25WZo+AQ3j6hF69NbTonbiUow
	 a8r0c3Mzdr4L7umKhPtyml+GICc0Iz7CXrXjBFFY5PAmWMihDcJf2V0TWoeJPC1g6V
	 RKkFNq598mfYQ==
Date: Fri, 12 Sep 2025 12:03:27 +0300
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	Keith Busch , linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvme@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250912090327.GU341237@unreal>
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>

On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote:
> On 09.09.2025 15:27, Leon Romanovsky wrote:
> > From: Leon Romanovsky 
> >
> > Changelog:
> > v6:
> >   * Based on "dma-debug: don't enforce dma mapping check on noncoherent
> >     allocations" patch.
> >   * Removed some unused variables from kmsan conversion.
> >   * Fixed missed ! in dma check.
> > v5: https://lore.kernel.org/all/cover.1756822782.git.leon@kernel.org
> >   * Added Jason's and Keith's Reviewed-by tags
> >   * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys
> >   * Jason's cleanup suggestions
> > v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/
> >   * Fixed kbuild error with mismatch in kmsan function declaration due to
> >     rebase error.
> > v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org
> >   * Fixed typo in "cacheable" word
> >   * Simplified kmsan patch a lot to be simple argument refactoring
> > v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org
> >   * Used commit messages and cover letter from Jason
> >   * Moved setting IOMMU_MMIO flag to dma_info_to_prot function
> >   * Micro-optimized the code
> >   * Rebased code on v6.17-rc1
> > v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org
> >   * Added new DMA_ATTR_MMIO attribute to indicate
> >     PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
> >   * Rewrote dma_map_* functions to use thus new attribute
> > v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/
> > ------------------------------------------------------------------------
> >
> > This series refactors the DMA mapping to use physical addresses
> > as the primary interface instead of page+offset parameters. This
> > change aligns the DMA API with the underlying hardware reality where
> > DMA operations work with physical addresses, not page structures.
> >
> > The series maintains export symbol backward compatibility by keeping
> > the old page-based API as wrapper functions around the new physical
> > address-based implementations.
> >
> > This series refactors the DMA mapping API to provide a phys_addr_t
> > based, and struct-page free, external API that can handle all the
> > mapping cases we want in modern systems:
> >
> >   - struct page based cacheable DRAM
> >   - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable
> >     MMIO
> >   - struct page-less PCI peer to peer non-cacheable MMIO
> >   - struct page-less "resource" MMIO
> >
> > Overall this gets much closer to Matthew's long term wish for
> > struct-pageless IO to cacheable DRAM. The remaining primary work would
> > be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on
> > phys_addr_t without a struct page.
> >
> > The general design is to remove struct page usage entirely from the
> > DMA API inner layers. For flows that need to have a KVA for the
> > physical address they can use kmap_local_pfn() or phys_to_virt(). This
> > isolates the struct page requirements to MM code only. Long term all
> > removals of struct page usage are supporting Matthew's memdesc
> > project which seeks to substantially transform how struct page works.
> >
> > Instead make the DMA API internals work on phys_addr_t. Internally
> > there are still dedicated 'page' and 'resource' flows, except they are
> > now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both
> > flows use the same phys_addr_t.
> >
> > When DMA_ATTR_MMIO is specified things work similar to the existing
> > 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(),
> > pfn_valid(), etc are never called on the phys_addr_t. This requires
> > rejecting any configuration that would need swiotlb. CPU cache
> > flushing is not required, and avoided, as ATTR_MMIO also indicates the
> > address have no cacheable mappings. This effectively removes any
> > DMA API side requirement to have struct page when DMA_ATTR_MMIO is
> > used.
> >
> > In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow,
> > except on the common path of no cache flush, no swiotlb it never
> > touches a struct page. When cache flushing or swiotlb copying
> > kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU
> > usage. This was already the case on the unmap side, now the map side
> > is symmetric.
> >
> > Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users
> > must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA
> > path must also set it. This corrects some existing bugs where iommu
> > mappings for P2P MMIO were improperly marked IOMMU_CACHE.
> >
> > Since ATTR_MMIO is made to work with all the existing DMA map entry
> > points, particularly dma_iova_link(), this finally allows a way to use
> > the new DMA API to map PCI P2P MMIO without creating struct page. The
> > VFIO DMABUF series demonstrates how this works. This is intended to
> > replace the incorrect driver use of dma_map_resource() on PCI BAR
> > addresses.
> >
> > This series does the core code and modern flows. A followup series
> > will give the same treatment to the legacy dma_ops implementation.
> 
> Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it 
> works fine in linux-next.

Thanks a lot.

> 
> Best regards
> -- 
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
> 
> 


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 06:00:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 06:00:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124149.1466651 (Exim 4.92)
	(envelope-from )
	id 1uy2GC-00011l-UI; Mon, 15 Sep 2025 06:00:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124149.1466651; Mon, 15 Sep 2025 06: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 1uy2GC-00011e-Pg; Mon, 15 Sep 2025 06:00:20 +0000
Received: by outflank-mailman (input) for mailman id 1124149;
 Mon, 15 Sep 2025 06:00: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 1uy2G9-00011Y-7f
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 06:00:17 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f898d39-91f9-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 08:00:14 +0200 (CEST)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-353dece5805so12085271fa.1
 for ; Sun, 14 Sep 2025 23:00: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: 3f898d39-91f9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757916014; x=1758520814; 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=fG37zlIx/BLttU26MS4fnoiz9Oe/mvO+lojMmBf3toE=;
        b=E/BZ8ZyZZ/YvaTMV7RLjwKHaYkv2Bra8EwZ8LAcIhrszgjIrIhzN4oStAkZUI0itWe
         rFBa2A8iBKjXZOaqetNfAPfgt5+hoFQOUL7xr6jIzqNiyqJ/htzKh3xt4ZIlJ3OvYTpz
         RO0SvYGaurjIKuWwtixaOHeWvDBaBzVuCGrXNmbChaODYoSi3rvRMWnfiTnaBxAYMNLI
         HN4nW6ilCc8kTOQdaCo7u8mca1W9lcnzQN7cbq946RRLAsWcrlFh87IB7hsu7+CwiSv0
         gtZtBcP9+bWVT44pO2Dbx2ae4p2rrG1FBRW7iF5xKYu3dsl7nyvh1iZo0btxWhwq1V/d
         73Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757916014; x=1758520814;
        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=fG37zlIx/BLttU26MS4fnoiz9Oe/mvO+lojMmBf3toE=;
        b=kVvEFhT0SHVChljozlVv2tlFqRCGGg6YmdkxcLLD/i+AQTuj+MDivs5tEt1ntRDrVc
         7KLO48CFRObRJm1o3t5VoCoJTMaK8kkNWXnT+ZJk4907tTXbWkQSRzdtn7xMFboI1Axc
         CT1Q3MGUgK6BKfUM5MNSNvX+ten12A8W2TajCXW9aCBLSF/TNZUdkQwqwS+xaDcORmxI
         YHhiO2VAXPbVmVd4xd0V2bK85yJeKwaO55dco6gGt6YZbGnioSOf9Btk9dEK6f9oj869
         uE/jCOGAd95p6tq95TpH21nr58WgKogEbDs4v7uhO3a4DPQd2+Ac1BUok8OCbgqcMjsr
         d32Q==
X-Gm-Message-State: AOJu0YwJZGco8SzK3l+ZiFFGew70CJJDfnlBLZQANufo0UVIhRP7/IU7
	B30GH9wD6DQ17onicvncxdWu2gGrCDwZEovDq58IO5kFoJWxCdiOk48t4IvxyOgnbSTNSW8YRS6
	oMXRytu6VPfE9+wxJcoQRkj3uMpyviv8=
X-Gm-Gg: ASbGncsFUagokelUIh+afQ7IbX2hbBxg3E5M9xQXKyS/VI8twZarh1GtcepjpSK8Lvz
	v6KlId9e8hBjtYO1dKlW7SYo2IemLe7Le3EinKJHNphzvDQ5+OsG/nC0fI4251vIP/ic3RFsJsP
	WkE/i0myEM2R3ds72E2HtXXpdfeB1UqjZheeWBN+8oFlMlIUcu4VKjy3aO4UAnw5wkfkDktQVy9
	lwMZg==
X-Google-Smtp-Source: AGHT+IFZte8KAPDPT0BJ1lP0XzI8I4zyUquj7Ss5QmG+1e4Lhf8qe2SP7bKcWMXixTidK5soGrS7Hq45RpBBVljxpQ0=
X-Received: by 2002:a05:651c:4413:10b0:336:e1d6:8903 with SMTP id
 38308e7fff4ca-351405de0b5mr23849821fa.30.1757916013740; Sun, 14 Sep 2025
 23:00:13 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-7-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-7-dmukhin@ford.com>
From: Mykola Kvach 
Date: Mon, 15 Sep 2025 09:00:00 +0300
X-Gm-Features: Ac12FXxpmNGi55GJZkqoi-asB_g1oeBQgmf4p2JfXGVuerx-7iftT8HgEVwUQ7k
Message-ID: 
Subject: Re: [PATCH v7 06/16] emul/ns16x50: implement IER/IIR registers
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for the patch.

On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add interrupt enable register emulation (IER) and interrupt identity reas=
on
> (IIR) register emulation to the I/O port handler.
>
> Also add routines for asserting/deasserting the virtual ns16x50 interrupt
> line as a dependent on IIR code. vPIC case is implemented (HVM), vIOAPIC
> case is stubbed out (for follow on PVH).
>
> Poke ns16x50_irq_check() on every I/O register access because the emulato=
r
> does not have clock emulation anyway (e.g. for baud rate emulation)>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - removed asserts for !has_vpic() paths
> ---
>  xen/common/emul/vuart/ns16x50.c | 138 ++++++++++++++++++++++++++++++++
>  1 file changed, 138 insertions(+)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index 5643ef4cc01e..664d799ddaee 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -90,6 +90,124 @@ static uint8_t ns16x50_dlab_get(const struct vuart_ns=
16x50 *vdev)
>      return 0;
>  }
>
> +static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *v=
dev)
> +{
> +    return false;
> +}
> +
> +static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *v=
dev)
> +{
> +    return false;
> +}
> +
> +static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *v=
dev)
> +{
> +    return false;
> +}
> +
> +static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *v=
dev)
> +{
> +    return false;
> +}
> +
> +/*
> + * Get the interrupt identity reason.
> + *
> + * IIR is re-calculated once called, because ns16x50 always reports high
> + * priority events first.
> + */
> +static uint8_t ns16x50_iir_get(const struct vuart_ns16x50 *vdev)
> +{
> +    /*
> +     * Interrupt identity reasons by priority.
> +     * NB: high priority are at lower indexes below.
> +     */
> +    static const struct {
> +        bool (*check)(const struct vuart_ns16x50 *vdev);
> +        uint8_t ier;
> +        uint8_t iir;
> +    } iir_by_prio[] =3D {
> +        [0] =3D { ns16x50_iir_check_lsi, UART_IER_ELSI,   UART_IIR_LSI }=
,
> +        [1] =3D { ns16x50_iir_check_rda, UART_IER_ERDAI,  UART_IIR_RDA }=
,
> +        [2] =3D { ns16x50_iir_check_thr, UART_IER_ETHREI, UART_IIR_THR }=
,

According to the spec (PC16550D and others also state this), if the
source of the IRQ is Transmitter Holding Register Empty, then reading
from IIR clears this interrupt.

So, I think it is not safe to call ns16x50_irq_check for every I/O.
According to the documentation, reset conditions for interrupts are:

    Reads:
        UART_RBR
        UART_IIR (only for the above case)
        UART_LSR
        UART_MSR

    Writes:
        UART_THR
        UART_IER

Of course, it is also necessary to think about how to handle the setting
of bits in IIR properly.

> +        [3] =3D { ns16x50_iir_check_msi, UART_IER_EMSI,   UART_IIR_MSI }=
,

Are you going to implement support for the Timeout Interrupt bit in
FIFO mode (PC16550D)?

    Bit 3: In the 16450 Mode this bit is 0. In the FIFO mode this
    bit is set along with bit 2 when a timeout interrupt is pending.
?

> +    };
> +    const uint8_t *regs =3D vdev->regs;
> +    uint8_t iir =3D 0;
> +    unsigned int i;
> +
> +    /*
> +     * NB: every interaction w/ ns16x50 registers (except DLAB=3D1) goes
> +     * through that call.
> +     */
> +    ASSERT(spin_is_locked(&vdev->lock));
> +
> +    for ( i =3D 0; i < ARRAY_SIZE(iir_by_prio); i++ )
> +    {
> +        if ( (regs[UART_IER] & iir_by_prio[i].ier) &&
> +             iir_by_prio[i].check(vdev) )
> +            break;
> +

Do we need this extra line?

> +    }
> +    if ( i =3D=3D ARRAY_SIZE(iir_by_prio) )
> +        iir |=3D UART_IIR_NOINT;
> +    else
> +        iir |=3D iir_by_prio[i].iir;
> +
> +    if ( regs[UART_FCR] & UART_FCR_ENABLE )
> +        iir |=3D UART_IIR_FE;
> +
> +    return iir;
> +}
> +
> +static void ns16x50_irq_assert(const struct vuart_ns16x50 *vdev)
> +{
> +    struct domain *d =3D vdev->owner;
> +    const struct vuart_info *info =3D vdev->info;
> +    int vector;
> +
> +    if ( has_vpic(d) )
> +        vector =3D hvm_isa_irq_assert(d, info->irq, vioapic_get_vector);
> +    else if ( has_vioapic(d) )
> +        /* TODO */
> +    else
> +        ASSERT_UNREACHABLE();
> +
> +    ns16x50_debug(vdev, "IRQ#%d vector %d assert\n", info->irq, vector);
> +}
> +
> +static void ns16x50_irq_deassert(const struct vuart_ns16x50 *vdev)
> +{
> +    struct domain *d =3D vdev->owner;
> +    const struct vuart_info *info =3D vdev->info;
> +
> +    if ( has_vpic(d) )
> +        hvm_isa_irq_deassert(d, info->irq);
> +    else if ( has_vioapic(d) )
> +        /* TODO */
> +    else
> +        ASSERT_UNREACHABLE();
> +
> +    ns16x50_debug(vdev, "IRQ#%d deassert\n", info->irq);
> +}
> +
> +/*
> + * Assert/deassert virtual ns16x50 interrupt line.
> + */
> +static void ns16x50_irq_check(const struct vuart_ns16x50 *vdev)
> +{
> +    uint8_t iir =3D ns16x50_iir_get(vdev);
> +    const struct vuart_info *info =3D vdev->info;
> +
> +    if ( iir & UART_IIR_NOINT )
> +        ns16x50_irq_deassert(vdev);
> +    else
> +        ns16x50_irq_assert(vdev);
> +
> +    ns16x50_debug(vdev, "IRQ#%d IIR 0x%02x %s\n", info->irq, iir,
> +                  (iir & UART_IIR_NOINT) ? "deassert" : "assert");
> +}
> +
>  /*
>   * Emulate 8-bit write access to ns16x50 register.
>   */
> @@ -106,6 +224,10 @@ static int ns16x50_io_write8(
>      {
>          switch ( reg )
>          {
> +        case UART_IER:
> +            regs[UART_IER] =3D val & UART_IER_MASK;
> +            break;
> +
>          /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
>          case UART_SCR:
>              regs[UART_SCR] =3D val;
> @@ -115,6 +237,8 @@ static int ns16x50_io_write8(
>              rc =3D -EINVAL;
>              break;
>          }
> +
> +        ns16x50_irq_check(vdev);
>      }
>
>      return rc;
> @@ -182,6 +306,14 @@ static int ns16x50_io_read8(
>      {
>          switch ( reg )
>          {
> +        case UART_IER:
> +            val =3D regs[UART_IER];
> +            break;
> +
> +        case UART_IIR: /* RO */
> +            val =3D ns16x50_iir_get(vdev);
> +            break;
> +
>          case UART_SCR:
>              val =3D regs[UART_SCR];
>              break;
> @@ -190,6 +322,8 @@ static int ns16x50_io_read8(
>              rc =3D -EINVAL;
>              break;
>          }
> +
> +        ns16x50_irq_check(vdev);
>      }
>
>      *data =3D val;
> @@ -342,6 +476,10 @@ static int ns16x50_init(void *arg)
>
>      register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
>
> +    spin_lock(&vdev->lock);
> +    ns16x50_irq_check(vdev);
> +    spin_unlock(&vdev->lock);
> +
>      return 0;
>  }
>
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 06:00:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 06:00:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124157.1466660 (Exim 4.92)
	(envelope-from )
	id 1uy2Gp-0001Tf-8b; Mon, 15 Sep 2025 06:00:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124157.1466660; Mon, 15 Sep 2025 06: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 1uy2Gp-0001TY-5L; Mon, 15 Sep 2025 06:00:59 +0000
Received: by outflank-mailman (input) for mailman id 1124157;
 Mon, 15 Sep 2025 06:00: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 1uy2Gn-00011Y-9V
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 06:00:57 +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 57ef27e3-91f9-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 08:00:55 +0200 (CEST)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-355739c7fc8so7951381fa.1
 for ; Sun, 14 Sep 2025 23: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: 57ef27e3-91f9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757916055; x=1758520855; 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=Nf5BgwxyPouvItWKO9mTHtFoYvHKxPMjCLUlJIi3GSM=;
        b=fUmT79vzUYaKU3dEhpltSVDv5DYe06IepttC7mqhiHISSV0DYfsF11vEzwc7N6oJfi
         3aohdycqP5sTcDWbz1Lje3YBzNCCe37rUtwapZMdAiGj9SfuLGKEjetOQV/qpxgYyJCH
         j//M0Eun6+3sow1Yf8zZQrC5PpnOrs761fZS0Aj/2sDTzOqYAyZa0R1dluzHbHKSuLbS
         aq1eooZLfYOu4UMa+MLdAaHNrNvP45hovJsjN2Jxzl7vfGsJnzJqjNS8OXmcMqYq4tAn
         lwPUE2DnsrTLN5db0Rbj9+OLx//85nsQyjWzKen7vCucibK/aCCjgl4YFBb/X2NL90Ck
         Hn2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757916055; x=1758520855;
        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=Nf5BgwxyPouvItWKO9mTHtFoYvHKxPMjCLUlJIi3GSM=;
        b=Nb6sjsqVe4ShgIEov7faEYL8aPkz6JlI1I35svqyAjglQKKwrA5uGAAx079jhRHf2d
         MrvilyYUiEHe1IXcPlIwQmQxV8wopERElSnMkG8ZIjJ7/APD7T8j6iogOzxMH4Uvsepo
         YbICumH5oGVA418d5PZ4cIoo4rhtOuojmAekYa8q7OIS3liEQzjMiTS34xxxjSwtt2v/
         5XA//3gi/mgme+lSZEdxBfBZvToDhMbbPsZVz2B5Mcc++XBmxeDReGxvKvNFxCx0+7iR
         opZVGjROLtyaebRgewBeig0aDsal+WX5e9eg4l+b52UrZEbwfQ1rKKuGElO383JPbuct
         hhfA==
X-Gm-Message-State: AOJu0YwXNf6OwHYnyUTOhmaTND5OITOXcAxg4vnV1pf62ur1bN2QmJL5
	BDjTH3qeoiCb5+U0JpLDt93V4PAauQv99s3E77Ki6L4qg813wKUppsVEUpTxOl0Aq9cokvsHt3E
	yhKACv7uzvSrtzTrj7uu0WlOMO2IBhng=
X-Gm-Gg: ASbGncu7E4GhmXmM6lWhhmP4XFpovSMh5MP6yymijfGKRRpTdoARYM9v6cpyVg+wdia
	ilSX9pTBfoJ4AhKieHbdGS4uL8rRX3in4iYIQyWFJoC4TRr6WWWJuAGi91db7Z/11+U9njLG8o2
	DNSfmRohQWzi5kbbRznvCw6b26xz1mjThHyHHPZsWu8s6FwekVEXhuPlMXb4s0mYKI4HrncM5uO
	uQ0Uw==
X-Google-Smtp-Source: AGHT+IH6oEq6KcuOeriJ1q5kNa8zylqQAHLc3b8zGq6vnqNEgyqfCEcTK2Hmkb/I80968+Il0BB+x3NrGa8dVLgBe0c=
X-Received: by 2002:a05:651c:23c2:20b0:338:beb:88c8 with SMTP id
 38308e7fff4ca-3513b484841mr24908501fa.19.1757916054931; Sun, 14 Sep 2025
 23:00:54 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-8-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-8-dmukhin@ford.com>
From: Mykola Kvach 
Date: Mon, 15 Sep 2025 09:00:00 +0300
X-Gm-Features: Ac12FXzqB87rPykqNLyXEIl1CERp8BxXK2CNufCeBhdrk1iaQg7cVuce44qz0H8
Message-ID: 
Subject: Re: [PATCH v7 07/16] emul/ns16x50: implement LCR/LSR registers
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for the patch.

On Tue, Sep 9, 2025 at 1:16=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add LCR/LSR registers implementation to the I/O port handler.
>
> Add implementation of ns16x50_dlab_get() and ns16x50_iir_check_lsi().
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - n/a
> ---
>  xen/common/emul/vuart/ns16x50.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index 664d799ddaee..0831a576cd9e 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -87,12 +87,12 @@ struct vuart_ns16x50 {
>
>  static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
>  {
> -    return 0;
> +    return vdev->regs[UART_LCR] & UART_LCR_DLAB ? 1 : 0;
>  }
>
>  static bool cf_check ns16x50_iir_check_lsi(const struct vuart_ns16x50 *v=
dev)
>  {
> -    return false;
> +    return vdev->regs[UART_LSR] & UART_LSR_MASK;
>  }
>
>  static bool cf_check ns16x50_iir_check_rda(const struct vuart_ns16x50 *v=
dev)
> @@ -228,11 +228,16 @@ static int ns16x50_io_write8(
>              regs[UART_IER] =3D val & UART_IER_MASK;
>              break;
>
> +        case UART_LCR:
> +            regs[UART_LCR] =3D val;

I understand that this register is mostly used to control the hardware
behavior, but I think we should pay attention to Bit 7 in this register:

    Bit 7: Divisor Latch Access Bit (DLAB). It must be set high (logic 1)
    to access the Divisor Latches of the Baud Generator during a read or
    write operation. It must be set low (logic 0) to access the Receiver
    Buffer, the Transmitter Holding Register, or the Interrupt Enable
    Register.

I know that you are checking it before accessing DLAB registers, but what
about accesses to RBR, THR, and IER?

> +            break;
> +
>          /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
>          case UART_SCR:
>              regs[UART_SCR] =3D val;
>              break;
>
> +        case UART_LSR: /* RO */

Is there a reason we cannot simply leave this unchanged?

>          default:
>              rc =3D -EINVAL;
>              break;
> @@ -314,6 +319,15 @@ static int ns16x50_io_read8(
>              val =3D ns16x50_iir_get(vdev);
>              break;
>
> +        case UART_LCR:
> +            val =3D regs[UART_LCR];
> +            break;
> +
> +        case UART_LSR:
> +            val =3D regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;

Why are UART_LSR_THRE and UART_LSR_TEMT set unconditionally?
What about UART_LSR_DR?

> +            regs[UART_LSR] =3D val & ~UART_LSR_MASK;

Maybe it would be good to mention why we are not resetting
UART_LSR_PE and UART_LSR_FE on read.

> +            break;
> +
>          case UART_SCR:
>              val =3D regs[UART_SCR];
>              break;
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 06:01:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 06:01:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124161.1466670 (Exim 4.92)
	(envelope-from )
	id 1uy2H0-0001qQ-HW; Mon, 15 Sep 2025 06:01:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124161.1466670; Mon, 15 Sep 2025 06:01: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 1uy2H0-0001qJ-EO; Mon, 15 Sep 2025 06:01:10 +0000
Received: by outflank-mailman (input) for mailman id 1124161;
 Mon, 15 Sep 2025 06:01: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 1uy2Gz-00011Y-73
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 06:01:09 +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 5f06444e-91f9-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 08:01:07 +0200 (CEST)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-55f78e3cdf9so4333296e87.1
 for ; Sun, 14 Sep 2025 23: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: 5f06444e-91f9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757916067; x=1758520867; 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=iImlh/71Mnv5AjhQqadSQLy2vbzq1b5PoMNI95mShAw=;
        b=YH207ptCl7setXUMSLpoHLBLMvFKkGSSA0TkfK84akYxr/8GBb+B5lxk3eUlAO7+1Q
         h9A0KjeUhO7ZFTTboatG2rSIEr9sZCAfxDjmMvR6NF6QlMJUqoktxORlJ7voXrY2cenr
         lIf0dOBYaUuoVw2aQrHVCGatxqoI5fyAZ2Q7fyVDhCpvw/RnGkUA/HL4hm1I1727SgOY
         Sja5pCukvoszFh0LYS9YZhdS7NASjweYFj3aZGiVxlrT7+Zd63Lz9nHfcOnfVhQe94Cf
         BeMqJc5VPjevKCvPgWXpLv59Rhm9l6GO/i+bZl278lXdIqZo17DZHSPB+WFI/fbCJjym
         oUag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757916067; x=1758520867;
        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=iImlh/71Mnv5AjhQqadSQLy2vbzq1b5PoMNI95mShAw=;
        b=CVMLrwDH8hJNhgSKQzsaOQPbrNGnigcbJu6DuNBa3WJF3K2IgyowBWQf/jX4sHzySy
         3w0Vp4HkInU9UJND9cDLoampK5QuseY4QqRen1aJpV1N2SPwOjAhmLNdtBRdp6Bl0sCf
         EdxQ5JGv8EzbKoi3yVMnGGEtjJBSqYMpRgtxCUgpCVmsVINe+fcfVKjOPwKZ3gPYzK1q
         IukUd87LldwESeKuiRQsmh9YpOlZu4XQe2R7eXPx3A5EZsqwXTi232jEqv06YS7uVROI
         9aeMNYS98vp6wBxnLFC+iUBhaOAGFnA36RdKrCfCe15ZQcuXG4I3wid3PSRGyRamHbM+
         At3A==
X-Gm-Message-State: AOJu0YziqoiffGOlAHa+d9ympuM2t6KvtvZrRFKFQrZ9CwOn+i+NW28z
	FWY/x1bFIzZ2coPMMFJcGs7beRn6yUCn2BwmOdSoDh6PUwWrANPc8OeibVHllh9ivacu093btGJ
	fRKJY8h7HYMZlDuNfqpnAJyEefiNpWzE=
X-Gm-Gg: ASbGncvDwS10tjKNnTYM7CpZ4tdqKs1HZ76bfu+1cxomWWXKviNx1Pfba3DcC0mUeER
	LimjlhnEg7DykJMuGJwWCW9zvcFmYHXwi/Qhiqzgq8ZCHYtPSuohK8FLsaTZmhB6hB3MaVvaE5b
	0vHNA2nHd4k3miF+gFVnssbxLEwHi7sQNSYPpWvIqCGr+wp4fouBgzkdOjYzgcSTh1TwK4DtkTx
	QypFeLxgR2hr5K01/J1KjnuP7I=
X-Google-Smtp-Source: AGHT+IFxrEzlLs++lPK5cYh0EJpAsaWR8l3JW7V/LWvCS5UuTUZ6YfzvxbY8woACJM1rt+gBeDWDuGLLE1lH3Aea1eo=
X-Received: by 2002:a05:651c:4397:20b0:337:e4cd:b2df with SMTP id
 38308e7fff4ca-3513db5a478mr30085001fa.20.1757916066689; Sun, 14 Sep 2025
 23:01:06 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-9-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-9-dmukhin@ford.com>
From: Mykola Kvach 
Date: Mon, 15 Sep 2025 09:00:00 +0300
X-Gm-Features: Ac12FXxQEVkBwcBctz-HGni0BeJU20yZFWmJwjNkTkRavWrkyzm1CjbwgBfuX1s
Message-ID: 
Subject: Re: [PATCH v7 08/16] emul/ns16x50: implement MCR/MSR registers
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for the patch.

On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> Add MCR/MSR registers emulation to the I/O port handler.
>
> Add implementation of ns16x50_iir_check_msi().
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - fixed UART_MSR_TERI handling
> ---
>  xen/common/emul/vuart/ns16x50.c | 62 ++++++++++++++++++++++++++++++++-
>  1 file changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> index 0831a576cd9e..fdc20124d4c9 100644
> --- a/xen/common/emul/vuart/ns16x50.c
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -107,7 +107,7 @@ static bool cf_check ns16x50_iir_check_thr(const stru=
ct vuart_ns16x50 *vdev)
>
>  static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *v=
dev)
>  {
> -    return false;
> +    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
>  }
>
>  /*
> @@ -232,12 +232,63 @@ static int ns16x50_io_write8(
>              regs[UART_LCR] =3D val;
>              break;
>
> +        case UART_MCR: {

Probably the opening brace should be moved to the next line.
See CODING_STYLE:

Braces ('{' and '}') are usually placed on a line of their own, except
for:

- the do/while loop
- the opening brace in definitions of enum, struct, and union
- the opening brace in initializers
- compound literals

> +            uint8_t msr_curr, msr_next, msr_delta;
> +
> +            msr_curr =3D regs[UART_MSR];
> +            msr_next =3D 0;
> +            msr_delta =3D 0;
> +
> +            if ( val & UART_MCR_RSRVD0 )
> +                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x=
\n",
> +                             UART_MCR_RSRVD0);
> +
> +            if ( val & UART_MCR_TCRTLR )
> +                ns16x50_warn(vdev, "MCR: not supported: %x\n",
> +                             UART_MCR_TCRTLR);
> +
> +            if ( val & UART_MCR_RSRVD1 )
> +                ns16x50_warn(vdev, "MCR: attempt to set reserved bit: %x=
\n",
> +                             UART_MCR_RSRVD1);
> +
> +            /* Set modem status */
> +            if ( val & UART_MCR_LOOP )
> +            {
> +                if ( val & UART_MCR_DTR )
> +                    msr_next |=3D UART_MSR_DSR;
> +                if ( val & UART_MCR_RTS )
> +                    msr_next |=3D UART_MSR_CTS;
> +                if ( val & UART_MCR_OUT1 )
> +                    msr_next |=3D UART_MSR_RI;
> +                if ( val & UART_MCR_OUT2 )
> +                    msr_next |=3D UART_MSR_DCD;
> +            }
> +            else
> +                msr_next |=3D UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS=
;
> +
> +            /* Calculate changes in modem status */
> +            if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> +                msr_delta |=3D UART_MSR_DCTS;
> +            if ( (msr_curr & UART_MSR_DSR) ^ (msr_next & UART_MSR_DSR) )
> +                msr_delta |=3D UART_MSR_DDSR;
> +            if ( !(msr_curr & UART_MSR_RI) && (msr_next & UART_MSR_RI) )
> +                msr_delta |=3D UART_MSR_TERI;
> +            if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
> +                msr_delta |=3D UART_MSR_DDCD;

It looks like this could be simplified to something like:
    msr_delta =3D ((regs[UART_MSR] ^ msr_next) >> 4);

> +
> +            regs[UART_MCR] =3D val & UART_MCR_MASK;
> +            regs[UART_MSR] =3D msr_next | msr_delta;

Does this description for the first four bits of MSR:
    "... input to the chip has changed state since the last time it was
    read by the CPU"

mean that we shouldn't modify bits that are already set but have not yet
been read by the CPU?

> +
> +            break;
> +        }
> +
>          /* NB: Firmware (e.g. OVMF) may rely on SCR presence. */
>          case UART_SCR:
>              regs[UART_SCR] =3D val;
>              break;
>
>          case UART_LSR: /* RO */
> +        case UART_MSR: /* RO */
>          default:
>              rc =3D -EINVAL;
>              break;
> @@ -323,11 +374,20 @@ static int ns16x50_io_read8(
>              val =3D regs[UART_LCR];
>              break;
>
> +        case UART_MCR:
> +            val =3D regs[UART_MCR];
> +            break;
> +
>          case UART_LSR:
>              val =3D regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
>              regs[UART_LSR] =3D val & ~UART_LSR_MASK;
>              break;
>
> +        case UART_MSR:
> +            val =3D regs[UART_MSR];
> +            regs[UART_MSR] &=3D ~UART_MSR_CHANGE;
> +            break;
> +
>          case UART_SCR:
>              val =3D regs[UART_SCR];
>              break;
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 06:30:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 06:30:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124190.1466680 (Exim 4.92)
	(envelope-from )
	id 1uy2iq-0005RH-LY; Mon, 15 Sep 2025 06:29:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124190.1466680; Mon, 15 Sep 2025 06:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uy2iq-0005RA-If; Mon, 15 Sep 2025 06:29:56 +0000
Received: by outflank-mailman (input) for mailman id 1124190;
 Mon, 15 Sep 2025 06:29:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uy2ip-0005R4-MS
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 06:29:55 +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 634e9ed2-91fd-11f0-9d13-b5c5bf9af7f9;
 Mon, 15 Sep 2025 08:29:53 +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 58EH2k6T008844;
 Mon, 15 Sep 2025 06:29:01 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 49509y0tk9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 15 Sep 2025 06:29:00 +0000 (GMT)
Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 58F6NRje019684;
 Mon, 15 Sep 2025 06:29:00 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 49509y0tk4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 15 Sep 2025 06:29:00 +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 58F2ZLlc029484;
 Mon, 15 Sep 2025 06:28:58 GMT
Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227])
 by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 495kb0n5uq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 15 Sep 2025 06:28:58 +0000
Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com
 [10.20.54.102])
 by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 58F6SuNA58458606
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 15 Sep 2025 06:28:56 GMT
Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 8B80F20043;
 Mon, 15 Sep 2025 06:28:56 +0000 (GMT)
Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 5171820040;
 Mon, 15 Sep 2025 06:28:54 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.87.136.34]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Mon, 15 Sep 2025 06:28:54 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 634e9ed2-91fd-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=pp1; bh=M/xuln
	62q5zfY1XqnOkzluoH/jhmqhYNwkmp3WpUxjM=; b=jaZLS26lBDtzg2fecSZHqg
	vv5wXs+Q/QWPzoKutrrQc6JlTQgh9S++0kG1xYTEEhhACxrSaEwrVcmFNUrm5aqi
	OtK0MYRXJHIvOwUxdJDVmGllntU+dWQ/n1X9T0qND7U13HpIsA/bx3E95xS6zSiA
	G61SjiM2ehKgCwcxj/d9UyDG2/tPRNmRQ1Hbt9E+RCa/4Ymom5k7ti/+qmaBBf+f
	VEyzVGOhzGaTidXPVx4X8SSv3dIj5Oxjs0qsGj5K8mF92mOvsSCfHnnElObmQvvm
	y7XvEJjXSIurhHceuMaFZFx9Txg7BTX7q6CqqSlAH22dER7OpbB+bhODUu/v3N6w
	==
Date: Mon, 15 Sep 2025 08:28:52 +0200
From: Alexander Gordeev 
To: Kevin Brodsky 
Cc: David Hildenbrand ,
        Andrew Morton , linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Andreas Larsson ,
        Boris Ostrovsky ,
        Borislav Petkov ,
        Catalin Marinas ,
        Christophe Leroy ,
        Dave Hansen ,
        "David S. Miller" ,
        "H. Peter Anvin" , Ingo Molnar ,
        Jann Horn , Juergen Gross ,
        "Liam R. Howlett" ,
        Lorenzo Stoakes ,
        Madhavan Srinivasan ,
        Michael Ellerman , Michal Hocko ,
        Mike Rapoport , Nicholas Piggin ,
        Peter Zijlstra ,
        Ryan Roberts ,
        Suren Baghdasaryan ,
        Thomas Gleixner , Vlastimil Babka ,
        Will Deacon , Yeoreum Yun ,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        Mark Rutland 
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
Message-ID: <5a0818bb-75d4-47df-925c-0102f7d598f4-agordeev@linux.ibm.com>
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
 
 <338ef811-1dab-4c4e-bc5f-8ebd8cb68435@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <338ef811-1dab-4c4e-bc5f-8ebd8cb68435@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwOTEzMDAyMCBTYWx0ZWRfX4Cx2ngBEYL5c
 roZzmS41YuVlUSpSRef2KxL4WggODwY/soRMJpx2gg7kNLdYMyZvXNoqxYULYholGjNDiAVT4t6
 ukIUbG+OX0a4imqOK2lAsyx5041sIs8EVQMQ06NsJGnBzkaxygCee6tTvsutuzI9wnG+eg3PA/v
 F5e7gPnCVAvuDEchpnbMPDdE4TzdeZAArCZTLOmkY9Xd7mYwn00cbVETqAT3ckHgDdrWLphTxSN
 y5ALHiTawyw3ojSiUQHSaHqzU+geaiqg5gb2LGGBqmnxp5igHqNKf3fjoaJ0BgJ2I38Ya10WbMS
 bYUlmQ5btypMVlGwBcuKVUODKwIOxTQn2bBDW8olvvXBnB4V+w9kPSd+TVwMJmnqFMZo71QBQkH
 T1vGkEV/
X-Authority-Analysis: v=2.4 cv=OPYn3TaB c=1 sm=1 tr=0 ts=68c7b22c cx=c_pps
 a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17
 a=8nJEP1OIZ-IA:10 a=yJojWOMRYYMA:10 a=nkFB8puKy1KDrdvMtSoA:9
 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
X-Proofpoint-GUID: dbH_inTMwHRH6BHBdGMtY8_aObQAr3rR
X-Proofpoint-ORIG-GUID: XMRhk7th-c6XacqgLmk45pWkcqEsR17O
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40
 definitions=2025-09-15_02,2025-09-12_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 adultscore=0 clxscore=1015 phishscore=0 suspectscore=0 spamscore=0
 bulkscore=0 malwarescore=0 impostorscore=0 priorityscore=1501
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2509130020

On Fri, Sep 12, 2025 at 05:25:27PM +0200, Kevin Brodsky wrote:

Hi Kevin,

> Based on the outcome of the discussion with David on patch 2 [1p], there
> is indeed an alternative approach that we should seriously consider. In
> summary:
> 
> * Keep the API stateless, handle nesting with a counter in task_struct
> * Introduce new functions to temporarily disable lazy_mmu without
> impacting nesting, track that with a bool in task_struct (addresses the
> situation in mm/kasan/shadow.c and possibly some x86 cases too)
> * Move as much handling from arch_* to generic functions
> 
> What the new generic infrastructure would look like:
> 
> struct task_struct {
>   ...
> #ifdef CONFIG_ARCH_LAZY_MMU
>   struct {
>     uint8_t count;
>     bool enabled; /* or paused, see below */
>   } lazy_mmu_state;
> #endif
> }
> 
> * lazy_mmu_mode_enable():

This helper is parameter-free, assuming the MMU unit does not need any
configuration other than turning it on/off. That is currently true, but
(as I noted in my other mail) I am going to introduce a friend enable
function that accepts parameters, creates an arch-specific state and
uses it while the lazy mmu mode is active.

That does not impact your design (AFAICT), except one change below.

>   if (!lazy_mmu_state.count) {
>    arch_enter_lazy_mmu_mode();
>     lazy_mmu_state.enabled = true;
>   }
>  lazy_mmu_state.count++;
> 
> * lazy_mmu_mode_disable():
>   lazy_mmu_count--;
>  if (!lazy_mmu_state.count) {
>    lazy_mmu_state.enabled = false;
>     arch_leave_lazy_mmu_mode();
>   } else {
>    arch_flush_lazy_mmu_mode();
>   }
> 
> * lazy_mmu_mode_pause():
>  lazy_mmu_state.enabled = false;
>   arch_leave_lazy_mmu_mode();

This needs to be arch_pause_lazy_mmu_mode(), otherwise the arch-specific
state will be lost.

> * lazy_mmu_mode_resume();
>  arch_enter_lazy_mmu_mode();

Conversely, this needs to be arch_resume_lazy_mmu_mode(). And it can not
be arch_enter_lazy_mmu_mode(), since a lazy_mmu_mode_resume() caller does
not know the parameters passed to the lazy_mmu_mode_enable(...)-friend.

>   lazy_mmu_state.enabled = true;
...

Thanks!


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 10:16:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 10:16:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124241.1466690 (Exim 4.92)
	(envelope-from )
	id 1uy6GJ-0007TN-33; Mon, 15 Sep 2025 10:16:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124241.1466690; Mon, 15 Sep 2025 10: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 1uy6GI-0007T4-UK; Mon, 15 Sep 2025 10:16:42 +0000
Received: by outflank-mailman (input) for mailman id 1124241;
 Mon, 15 Sep 2025 10: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 1uy6GH-0007Sy-C4
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 10:16:41 +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 11280a00-921d-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 12:16:38 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-55f6f7edf45so3377022e87.2
 for ; Mon, 15 Sep 2025 03:16: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: 11280a00-921d-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757931398; x=1758536198; 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=TfSQ08K3XOa0Gk0W4iMaukyj7ws9EKPpQm4NjG3hS9E=;
        b=cN0zpvYu+B/B3BAvyA9Vnx9DGMsiSYiIY0d399r7anJ7DzZID0URPG4+L7SPg7CW9x
         iuq7N4/bR81QkTh2n36qTVSXnlU/3p1/igXB3fPWABQfw48Mb3rBDMlTEKajcRS4ClVM
         BtLlhOX2AcFaVP20JJ9S8bZ+LVWbzzb88O3iyR2wtKqqN7y97xryj7Fim5wFqXCKTZRX
         s/LllGkQ3RtE20hP7/q9n1cZkvsWRjlqSeFs39t6iFyChgEl106vbtBkqe2u+WVi0T/y
         CVwBwKusLkgbfqOWzCbJvB6eUhv3gvwnDHzLYSC3G35NGoxl0zd9j7EnGYrTaqmHiaGt
         9mlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757931398; x=1758536198;
        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=TfSQ08K3XOa0Gk0W4iMaukyj7ws9EKPpQm4NjG3hS9E=;
        b=xKcYAEItRlkVn0F0RnvwI216sxRIlbdtNlm1/jhz3Qv24wWyk7UrDwSlUrepjOY+1c
         KQysq1CDpMeWjEvXJu9SaecvsLNzXUCeO0n5aWMd4oeJkeBvzuxDGTKpcR5yEcoocXjJ
         +IZnEZrFB/aAa30WGeF9tMgkdlqFr8OpXIGXmZRMGl9EKMQkh7u/jDI5Z+iCrYrsjDOh
         /ZDSarmv6lABQDKroq9Py1eFvYoAUu+9tnt8HLPWQnRWRzil3uVLG0OT0zJ/p8ipGtVf
         pSJfiVqjJehHU03/eMSIiTMh9cVcm1d3yv8vvpMrNsd641WnbjpgYut4AkAE5SicmSzW
         tQIw==
X-Gm-Message-State: AOJu0YyK3lHi96prSAXRfX6py+AhDr+972d1iqBwvWiVyWKLvCxDHy0u
	IcWR1yQf+MF1H7UEByZmUQJstf9IYyXx3Ld2YE+LOdxE03GqP3smmmxDB06rFH+mWD3ecl4sEJX
	CiTcGJeAhd4SQqEAIHFkiCI09eTNpWds=
X-Gm-Gg: ASbGnct/FkMRs1DJYyaHuPzfrC4yAIQoZA2akOzFAuLXRcsUCZ+dSav/cjkm5NkEbCp
	aAr0OAhyizfro8qZbspFk8BVNIiOZLkI5QsaSKlPregUH2i78YVQE+SrwDanjoZ2fVgRROjcSiC
	sfpDh5TYbpqhx+PeDtKAxRPcPrR3CZGhL2msWQI883lJmv06vfq0Uy7yuoB+1XGLwHZTKb9pwjB
	+4jM/0dl7dCKogw
X-Google-Smtp-Source: AGHT+IEFi031BIyFOxOVWr+ebes9hjd2LcLzMRuUUWBi5aUK/feoUjP6aThJcu+jsuRrfoLnnq2OtNKMcD6m77PodJA=
X-Received: by 2002:a05:6512:6715:b0:55f:503c:d322 with SMTP id
 2adb3069b0e04-570508278e0mr2454672e87.40.1757931397988; Mon, 15 Sep 2025
 03:16:37 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-4-dmukhin@ford.com>
In-Reply-To: <20250908211149.279143-4-dmukhin@ford.com>
From: Mykola Kvach 
Date: Mon, 15 Sep 2025 13:16:26 +0300
X-Gm-Features: Ac12FXxwZR-KqMMKFrE7VEzx1JMmHgDw0QtOhDWhoX96q46uW1kcHVMxoIltsWk
Message-ID: 
Subject: Re: [PATCH v7 03/16] emul/ns16x50: implement emulator stub
To: dmukhin@xen.org
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
>
> From: Denis Mukhin 
>
> The change is the first on the way on introducing minimally functional
> NS16550-compatible UART emulator.
>
> Only one domain, defined via 'vuart=3D' parameter, will have UART emulato=
r
> initially. The command line option is not documented yet because of the p=
lan
> to adjust this code for vUART configuration via xl.
>
> Define UART state and a set of emulated registers.
>
> Implement alloc/free vUART hooks.
>
> Stub out I/O port handler.
>
> Add initialization of the NS16x50-compatible UART emulator state machine.
>
> Plumb debug logging.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - feedback from Mykola
> - added temporary 'vuart=3D' run-time option to enable emulator for certa=
in
>   domain for ease of testing
> ---
>  xen/arch/x86/hvm/hvm.c          |  75 +++++++
>  xen/common/emul/vuart/Makefile  |   1 +
>  xen/common/emul/vuart/ns16x50.c | 364 ++++++++++++++++++++++++++++++++
>  3 files changed, 440 insertions(+)
>  create mode 100644 xen/common/emul/vuart/ns16x50.c
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 23bd7f078a1d..363c010f8dcc 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -107,6 +108,67 @@ static const char __initconst warning_hvm_fep[] =3D
>  static bool __initdata opt_altp2m_enabled;
>  boolean_param("altp2m", opt_altp2m_enabled);
>
> +/* Enable NS16550 emulator for certain domain only. */
> +static int __read_mostly opt_vuart_domid =3D -1;
> +
> +#ifdef CONFIG_VUART_NS16X50
> +static int __read_mostly opt_vuart_id;
> +static int __init cf_check parse_vuart_param(const char *s)
> +{
> +    if ( !isdigit(*s) )
> +        return -EINVAL;
> +
> +    opt_vuart_domid =3D simple_strtoul(s, &s, 0);
> +
> +    if ( *s !=3D ':' )
> +        return 0;
> +
> +    if ( strncmp(s, "com", 3) )
> +        return -EINVAL;
> +
> +    opt_vuart_id =3D *(s + 3) - '1';
> +    if ( opt_vuart_id < 0 || opt_vuart_id > 3 )
> +        return -EINVAL;
> +
> +    return 0;
> +}
> +custom_param("vuart", parse_vuart_param);
> +
> +static const struct vuart_info *get_vuart_info(struct domain *d)
> +{
> +#define PC_UART(n,p,i) { \
> +    .name =3D n, \
> +    .compatible =3D "ns16550", \
> +    .base_addr =3D p, \
> +    .size =3D 8, \
> +    .irq =3D i, \
> +}
> +    static const struct vuart_info pc_uarts[4] =3D
> +    {
> +        PC_UART("com1", 0x3f8, 4),
> +        PC_UART("com2", 0x2f8, 3),
> +        PC_UART("com3", 0x3fe, 4),
> +        PC_UART("com4", 0x2fe, 3),
> +    };
> +    unsigned i;
> +
> +    for ( i =3D 0; i < ARRAY_SIZE(pc_uarts); i++ )
> +        if ( i =3D=3D opt_vuart_id )
> +            break;
> +
> +    if ( i !=3D ARRAY_SIZE(pc_uarts) )
> +        return &pc_uarts[i];
> +
> +    return NULL;
> +#undef PC_UART
> +}
> +#else
> +static const struct vuart_info *get_vuart_info(struct domain *d)
> +{
> +    return NULL;
> +}
> +#endif /* CONFIG_VUART_NS16X50 */
> +
>  static int cf_check cpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -689,6 +751,15 @@ int hvm_domain_initialise(struct domain *d,
>      if ( rc !=3D 0 )
>          goto fail1;
>
> +    if ( IS_ENABLED(CONFIG_VUART_NS16X50) && d->domain_id =3D=3D opt_vua=
rt_domid )
> +    {
> +        const struct vuart_info *info =3D get_vuart_info(d);
> +
> +        rc =3D vuart_init(d, info);
> +        if ( rc )
> +            goto out_vioapic_deinit;
> +    }
> +
>      stdvga_init(d);
>
>      rtc_init(d);
> @@ -712,6 +783,8 @@ int hvm_domain_initialise(struct domain *d,
>      return 0;
>
>   fail2:
> +    vuart_deinit(d);
> + out_vioapic_deinit:
>      vioapic_deinit(d);
>   fail1:
>      if ( is_hardware_domain(d) )
> @@ -774,6 +847,8 @@ void hvm_domain_destroy(struct domain *d)
>      if ( hvm_funcs.domain_destroy )
>          alternative_vcall(hvm_funcs.domain_destroy, d);
>
> +    vuart_deinit(d);
> +
>      vioapic_deinit(d);
>
>      XFREE(d->arch.hvm.pl_time);
> diff --git a/xen/common/emul/vuart/Makefile b/xen/common/emul/vuart/Makef=
ile
> index 97f792dc6641..fe904f6cb65d 100644
> --- a/xen/common/emul/vuart/Makefile
> +++ b/xen/common/emul/vuart/Makefile
> @@ -1 +1,2 @@
>  obj-y +=3D vuart.o
> +obj-$(CONFIG_VUART_NS16X50) +=3D ns16x50.o
> diff --git a/xen/common/emul/vuart/ns16x50.c b/xen/common/emul/vuart/ns16=
x50.c
> new file mode 100644
> index 000000000000..a3bdf9f415ca
> --- /dev/null
> +++ b/xen/common/emul/vuart/ns16x50.c
> @@ -0,0 +1,364 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS16550-compatible UART Emulator.
> + *
> + * See:
> + * - Serial and UART Tutorial:
> + *     https://download.freebsd.org/doc/en/articles/serial-uart/serial-u=
art_en.pdf
> + * - UART w/ 16 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c550c.pdf
> + * - UART w/ 64 byte FIFO:
> + *     https://www.ti.com/lit/ds/symlink/tl16c750.pdf
> + *
> + * Limitations:
> + * - Only x86;
> + * - Only Xen console as a backend, no inter-domain communication (simil=
ar to
> + *   vpl011 on Arm);
> + * - Only 8n1 emulation (8-bit data, no parity, 1 stop bit);
> + * - No baud rate emulation (reports 115200 baud to the guest OS);
> + * - No FIFO-less mode emulation;
> + * - No RX FIFO interrupt moderation (FCR) emulation;
> + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> + *   friends);
> + * - No ISA IRQ sharing allowed;
> + * - No MMIO-based UART emulation.
> + */
> +
> +#define pr_prefix               "ns16x50"
> +#define pr_fmt(fmt)             pr_prefix ": " fmt
> +
> +#ifdef CONFIG_VUART_NS16X50_DEBUG
> +#define guest_prefix            "FROM GUEST "
> +#define ns16x50_log_level       2
> +#else
> +#define guest_prefix            ""
> +#define ns16x50_log_level       0
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define ns16x50_log(n, lvl, vdev, fmt, args...) \
> +do { \
> +    if ( ns16x50_log_level >=3D n ) \
> +        gprintk(lvl, pr_fmt("%s: " fmt), (vdev)->name, ## args); \
> +} while (0)
> +
> +#define ns16x50_err(vdev, fmt, args...) \
> +    ns16x50_log(0, XENLOG_ERR, vdev, fmt, ## args)
> +#define ns16x50_warn(vdev, fmt, args...) \
> +    ns16x50_log(1, XENLOG_WARNING, vdev, fmt, ## args)
> +#define ns16x50_info(vdev, fmt, args...) \
> +    ns16x50_log(2, XENLOG_INFO, vdev, fmt, ## args)
> +#define ns16x50_debug(vdev, fmt, args...) \
> +    ns16x50_log(3, XENLOG_DEBUG, vdev, fmt, ## args)
> +
> +/*
> + * Number of supported registers in the UART.
> + */
> +#define NS16X50_REGS_NUM        (UART_SCR + 1)
> +
> +/*
> + * Number of emulated registers.
> + *
> + * - Emulated registers [0..NS16X50_REGS_NUM] are R/W registers for DLAB=
=3D0.
> + * - DLAB=3D1, R/W, DLL         =3D (NS16X50_REGS_NUM + 0)
> + * - DLAB=3D1, R/W, DLM         =3D (NS16X50_REGS_NUM + 1)
> + */
> +#define NS16X50_EMU_REGS_NUM    (NS16X50_REGS_NUM + 2)
> +
> +/*
> + * Virtual ns16x50 device state.
> + */
> +struct vuart_ns16x50 {
> +    uint8_t regs[NS16X50_EMU_REGS_NUM]; /* Emulated registers */

I think it would be better to add an init procedure for the registers.
At least not all bits in all registers should be initialized to zero.
Or will this be handled in some way during I/O reads?

> +    const struct vuart_info *info;      /* UART description */
> +    struct domain *owner;               /* Owner domain */
> +    const char *name;                   /* Device name */
> +    spinlock_t lock;                    /* Protection */
> +    struct xencons_interface cons;      /* Emulated RX/TX FIFOs */
> +};
> +
> +static uint8_t ns16x50_dlab_get(const struct vuart_ns16x50 *vdev)
> +{
> +    return 0;
> +}
> +
> +/*
> + * Emulate 8-bit write access to ns16x50 register.
> + */
> +static int ns16x50_io_write8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    int rc =3D 0;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit write access to ns16x50 register.
> + * NB: some guest OSes use outw() to access UART_DLL.
> + */
> +static int ns16x50_io_write16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    int rc =3D -EINVAL;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate write access to ns16x50 register.
> + */
> +static int ns16x50_io_write(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_write8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_write16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 8-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read8(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    uint8_t val =3D UINT8_MAX;
> +    int rc =3D 0;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit read access to ns16x50 register.
> + */
> +static int ns16x50_io_read16(
> +    struct vuart_ns16x50 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    uint16_t val =3D UINT16_MAX;
> +    int rc =3D -EINVAL;
> +
> +    *data =3D val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate read access to ns16x50 register.
> + */
> +static int ns16x50_io_read(
> +    struct vuart_ns16x50 *vdev, uint8_t reg, uint32_t size, uint32_t *da=
ta)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc =3D ns16x50_io_read8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc =3D ns16x50_io_read16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        *data =3D UINT32_MAX;
> +        rc =3D -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate I/O access to ns16x50 register.
> + * Note, emulation always returns X86EMUL_OKAY, once I/O port trap is en=
abled.
> + */
> +static int cf_check ns16x50_io_handle(
> +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> +{
> +    const char op =3D (dir =3D=3D IOREQ_WRITE) ? 'W' : 'R';
> +    struct domain *d =3D rcu_lock_current_domain();
> +    struct vuart *vuart =3D vuart_find_by_io_range(d, addr, size);
> +    struct vuart_ns16x50 *vdev;
> +    const struct domain *owner;
> +    const struct vuart_info *info;
> +    uint32_t reg;
> +    unsigned dlab;
> +    int rc;
> +
> +    if ( !vuart )
> +    {
> +        printk(XENLOG_ERR "%c io 0x%04x %d: not initialized\n",
> +               op, addr, size);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +
> +    vdev =3D vuart->vdev;
> +    ASSERT(vdev);
> +
> +    owner =3D vuart->owner;
> +    ASSERT(owner);
> +
> +    if ( d !=3D owner )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: does not match current domai=
n %pv\n",
> +                    op, addr, size, d);
> +
> +        ASSERT_UNREACHABLE();
> +        goto out;
> +    }
> +
> +    info =3D vuart->info;
> +    ASSERT(info);
> +
> +    reg =3D addr - info->base_addr;
> +    if ( !IS_ALIGNED(reg, size) )
> +    {
> +        ns16x50_err(vdev, "%c 0x%04x %d: unaligned access\n",
> +                    op, addr, size);
> +        goto out;
> +    }
> +
> +    dlab =3D ns16x50_dlab_get(vdev);
> +    if ( reg >=3D NS16X50_REGS_NUM )
> +    {
> +        ns16x50_err(vdev, "%c io 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"=
PRIx32": not implemented\n",
> +                    op, addr, size, dlab, reg, *data);
> +        goto out;
> +    }
> +
> +    spin_lock(&vdev->lock);
> +
> +    if ( dir =3D=3D IOREQ_WRITE )
> +        rc =3D ns16x50_io_write(vdev, reg, size, data);
> +    else
> +        rc =3D ns16x50_io_read(vdev, reg, size, data);
> +
> +    spin_unlock(&vdev->lock);
> +
> +    if ( rc =3D=3D 0 )
> +        ns16x50_debug(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"P=
RIx32"\n",
> +                      op, addr, size, dlab, reg, *data);
> +    else
> +        ns16x50_err(vdev, "%c 0x%04x %d: DLAB=3D%d %02"PRIx32" 0x%08"PRI=
x32": unsupported access\n",
> +                    op, addr, size, dlab, reg, *data);
> +
> +out:
> +    rcu_unlock_domain(d);
> +
> +    return X86EMUL_OKAY;
> +}
> +
> +static int ns16x50_init(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +    const struct vuart_info *info =3D vdev->info;
> +    struct domain *d =3D vdev->owner;
> +
> +    ASSERT(vdev);
> +
> +    register_portio_handler(d, info->base_addr, info->size, ns16x50_io_h=
andle);
> +
> +    return 0;
> +}
> +
> +static void cf_check ns16x50_deinit(void *arg)
> +{
> +    struct vuart_ns16x50 *vdev =3D arg;
> +
> +    ASSERT(vdev);
> +}
> +
> +static void * cf_check ns16x50_alloc(struct domain *d, const struct vuar=
t_info *info)
> +{
> +    struct vuart_ns16x50 *vdev;
> +    int rc;
> +
> +    if ( !is_hvm_domain(d) )
> +    {
> +        ns16x50_err(info, "not an HVM domain\n");
> +        return ERR_PTR(-ENOSYS);
> +    }
> +
> +    if ( vuart_find_by_io_range(d, info->base_addr, info->size) )
> +    {
> +        ns16x50_err(info, "already registered\n");
> +        return ERR_PTR(-EBUSY);
> +    }
> +
> +    vdev =3D xvzalloc(typeof(*vdev));
> +    if ( !vdev )
> +    {
> +        ns16x50_err(info, "failed to allocate memory\n");
> +        return ERR_PTR(-ENOMEM);
> +    }
> +
> +    spin_lock_init(&vdev->lock);
> +    vdev->name =3D info->name;
> +    vdev->owner =3D d;
> +    vdev->info =3D info;
> +
> +    rc =3D ns16x50_init(vdev);
> +    if ( rc )
> +    {
> +        xvfree(vdev);
> +        return ERR_PTR(rc);
> +    }
> +
> +    return vdev;
> +}
> +
> +static void cf_check ns16x50_free(void *arg)
> +{
> +    if ( arg )
> +        ns16x50_deinit(arg);
> +
> +    xvfree(arg);
> +}
> +
> +#define ns16x50_emulator                \
> +{                                       \
> +    .compatible =3D "ns16550",            \
> +    .alloc      =3D ns16x50_alloc,        \
> +    .free       =3D ns16x50_free,         \
> +    .dump_state =3D NULL,                 \
> +    .put_rx     =3D NULL,                 \
> +}
> +
> +VUART_REGISTER(ns16x50, ns16x50_emulator);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 2.51.0
>
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 10:35:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 10:35:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124256.1466700 (Exim 4.92)
	(envelope-from )
	id 1uy6YK-0001qu-Ht; Mon, 15 Sep 2025 10:35:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124256.1466700; Mon, 15 Sep 2025 10:35: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 1uy6YK-0001qn-F4; Mon, 15 Sep 2025 10:35:20 +0000
Received: by outflank-mailman (input) for mailman id 1124256;
 Mon, 15 Sep 2025 10:35: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 1uy6YI-0001qf-RH
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 10:35:19 +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 a8ca4dff-921f-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 12:35:12 +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 70A1633722;
 Mon, 15 Sep 2025 10:35: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 D535D1368D;
 Mon, 15 Sep 2025 10:35:10 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id WO5lMt7rx2hmEwAAD6G6ig
 (envelope-from ); Mon, 15 Sep 2025 10:35: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: a8ca4dff-921f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1757932511; 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=wyZ7R1j8ekVpPVWOeGovOVmplGZx5PoOUHolz+8mQ9A=;
	b=FPGp+DWnjZ8cpc2VUqQoiyB/9LNHZYKvuORtYnVfZ/XHaMFtXUVkqBJcO7rAv1RFBFx8Wt
	WO9vXmdo3ndVCRkwybC/JRSx7vg7aRbraBqaSL3pYejnsPSAS3V9zbavON3zPYoiuoyHq6
	t30gZa8OHDAhmOgPfFIgs/KdUCYtpH0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1757932511;
	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=wyZ7R1j8ekVpPVWOeGovOVmplGZx5PoOUHolz+8mQ9A=;
	b=jve2A0736Y5pKNdzRyUDlpuD78LkpAU4DSyrxIJjrTFvm/CDnns1c+0qAhYAGzGZhQpsjD
	q17urp8vFAEgnsDA==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1757932511; 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=wyZ7R1j8ekVpPVWOeGovOVmplGZx5PoOUHolz+8mQ9A=;
	b=FPGp+DWnjZ8cpc2VUqQoiyB/9LNHZYKvuORtYnVfZ/XHaMFtXUVkqBJcO7rAv1RFBFx8Wt
	WO9vXmdo3ndVCRkwybC/JRSx7vg7aRbraBqaSL3pYejnsPSAS3V9zbavON3zPYoiuoyHq6
	t30gZa8OHDAhmOgPfFIgs/KdUCYtpH0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1757932511;
	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=wyZ7R1j8ekVpPVWOeGovOVmplGZx5PoOUHolz+8mQ9A=;
	b=jve2A0736Y5pKNdzRyUDlpuD78LkpAU4DSyrxIJjrTFvm/CDnns1c+0qAhYAGzGZhQpsjD
	q17urp8vFAEgnsDA==
Message-ID: <331c5105-481f-4776-943f-376b21ccc430@suse.de>
Date: Mon, 15 Sep 2025 12:35:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 00/25] drm/dumb-buffers: Fix and improve buffer-size
 calculation
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
References: <20250821081918.79786-1-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: <20250821081918.79786-1-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Level: 
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];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	ARC_NA(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[20];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:mid]
X-Spam-Flag: NO
X-Spam-Score: -2.80

FYI, I significant number of these patches got a review already. I 
intent to merge these and then send out the others for each driver 
individually.

Am 21.08.25 um 10:17 schrieb Thomas Zimmermann:
> 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.
>
> v6:
> - extend TODO item (Tomi)
> - fix typos in documentation (Tomi)
> 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                    |  37 ++++
>   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, 457 insertions(+), 228 deletions(-)
>   create mode 100644 include/drm/drm_dumb_buffers.h
>

-- 
--
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 Mon Sep 15 11:20:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 11:20:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124267.1466709 (Exim 4.92)
	(envelope-from )
	id 1uy7FM-0007F8-KZ; Mon, 15 Sep 2025 11:19:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124267.1466709; Mon, 15 Sep 2025 11:19:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uy7FM-0007F1-HH; Mon, 15 Sep 2025 11:19:48 +0000
Received: by outflank-mailman (input) for mailman id 1124267;
 Mon, 15 Sep 2025 11: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 1uy7FL-0007Ev-LJ
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 11:19:47 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id def3ae48-9225-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 13:19:41 +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 4D6971424;
 Mon, 15 Sep 2025 04:19:31 -0700 (PDT)
Received: from [10.57.70.220] (unknown [10.57.70.220])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6C7D73F694;
 Mon, 15 Sep 2025 04: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: def3ae48-9225-11f0-9809-7dc792cee155
Message-ID: 
Date: Mon, 15 Sep 2025 13:19:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/7] Nesting support for lazy MMU mode
To: Alexander Gordeev 
Cc: David Hildenbrand ,
 Andrew Morton , linux-mm@kvack.org,
 linux-kernel@vger.kernel.org, Andreas Larsson ,
 Boris Ostrovsky , Borislav Petkov
 , Catalin Marinas ,
 Christophe Leroy ,
 Dave Hansen ,
 "David S. Miller" , "H. Peter Anvin" ,
 Ingo Molnar , Jann Horn ,
 Juergen Gross , "Liam R. Howlett"
 , Lorenzo Stoakes ,
 Madhavan Srinivasan ,
 Michael Ellerman , Michal Hocko ,
 Mike Rapoport , Nicholas Piggin ,
 Peter Zijlstra , Ryan Roberts ,
 Suren Baghdasaryan , Thomas Gleixner
 , Vlastimil Babka ,
 Will Deacon , Yeoreum Yun ,
 linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 Mark Rutland 
References: <20250908073931.4159362-1-kevin.brodsky@arm.com>
 <20250908191602.61160a7990b9ea418de758c7@linux-foundation.org>
 
 <338ef811-1dab-4c4e-bc5f-8ebd8cb68435@arm.com>
 <5a0818bb-75d4-47df-925c-0102f7d598f4-agordeev@linux.ibm.com>
Content-Language: en-GB
From: Kevin Brodsky 
In-Reply-To: <5a0818bb-75d4-47df-925c-0102f7d598f4-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15/09/2025 08:28, Alexander Gordeev wrote:
> On Fri, Sep 12, 2025 at 05:25:27PM +0200, Kevin Brodsky wrote:
>
> Hi Kevin,
>
>> Based on the outcome of the discussion with David on patch 2 [1p], there
>> is indeed an alternative approach that we should seriously consider. In
>> summary:
>>
>> * Keep the API stateless, handle nesting with a counter in task_struct
>> * Introduce new functions to temporarily disable lazy_mmu without
>> impacting nesting, track that with a bool in task_struct (addresses the
>> situation in mm/kasan/shadow.c and possibly some x86 cases too)
>> * Move as much handling from arch_* to generic functions
>>
>> What the new generic infrastructure would look like:
>>
>> struct task_struct {
>>     ...
>> #ifdef CONFIG_ARCH_LAZY_MMU
>>     struct {
>>         uint8_t count;
>>         bool enabled; /* or paused, see below */
>>     } lazy_mmu_state;
>> #endif
>> }
>>
>> * lazy_mmu_mode_enable():
> This helper is parameter-free, assuming the MMU unit does not need any
> configuration other than turning it on/off. That is currently true, but
> (as I noted in my other mail) I am going to introduce a friend enable
> function that accepts parameters, creates an arch-specific state and
> uses it while the lazy mmu mode is active.

Yes I think that's fine.

> That does not impact your design (AFAICT), except one change below.
>
>>     if (!lazy_mmu_state.count) {
>>         arch_enter_lazy_mmu_mode();
>>         lazy_mmu_state.enabled = true;
>>     }
>>     lazy_mmu_state.count++;
>>
>> * lazy_mmu_mode_disable():
>>     lazy_mmu_count--;
>>     if (!lazy_mmu_state.count) {
>>         lazy_mmu_state.enabled = false;
>>         arch_leave_lazy_mmu_mode();
>>     } else {
>>         arch_flush_lazy_mmu_mode();
>>     }
>>
>> * lazy_mmu_mode_pause():
>>     lazy_mmu_state.enabled = false;
>>     arch_leave_lazy_mmu_mode();
> This needs to be arch_pause_lazy_mmu_mode(), otherwise the arch-specific
> state will be lost.
>
>> * lazy_mmu_mode_resume();
>>     arch_enter_lazy_mmu_mode();
> Conversely, this needs to be arch_resume_lazy_mmu_mode(). And it can not
> be arch_enter_lazy_mmu_mode(), since a lazy_mmu_mode_resume() caller does
> not know the parameters passed to the lazy_mmu_mode_enable(...)-friend.

Got it, that makes sense. Even without your proposal, it is probably a
good idea to allow arch's to behave differently on pause/resume.

I hope we can avoid forcing all arch's to define arch_pause/arch_resume
though, since only s390 will use it for the foreseeable future. Using
optional macros should do the trick.

- Kevin


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 12:19:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 12:19:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124300.1466720 (Exim 4.92)
	(envelope-from )
	id 1uy8Ay-0006Da-U9; Mon, 15 Sep 2025 12:19:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124300.1466720; Mon, 15 Sep 2025 12:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uy8Ay-0006DT-Qv; Mon, 15 Sep 2025 12:19:20 +0000
Received: by outflank-mailman (input) for mailman id 1124300;
 Mon, 15 Sep 2025 12:19: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 1uy8Ax-0006DN-GQ
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 12:19:19 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 324116b4-922e-11f0-9d13-b5c5bf9af7f9;
 Mon, 15 Sep 2025 14:19:17 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1757938750772316.82499019828015;
 Mon, 15 Sep 2025 05:19:10 -0700 (PDT)
Received: by mail-oa1-f47.google.com with SMTP id
 586e51a60fabf-330d1565844so1624363fac.1
 for ; Mon, 15 Sep 2025 05: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: 324116b4-922e-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; t=1757938752; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=XKRIt9W7fHnavqJGbr3EbeEdKp7O6YOYfol7LqUcEFcN9eSANeujfkeBdrX6N74U8FAFNHcG6Eqg+Parj6cfU6pb5bNz1U/8+sVB7kf+0lr3QMUL356lhWvXWdVbK3Z2vFC1R6Dqw8IIr39bldKphS1Jdj6Q/YL1fv/mVwHfVv4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757938752; 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=nMENMgkEm0iRso4+GD3zG/CwrpYfs5RQRWgp6rLB49c=; 
	b=mIG1+I11dHUxpzavcR/2pG6BApf4VeTq1wGjaD1bxNJC4hrkSx9DCtV1oxCiOOZRWRq1S3ddF5VfN9queBjJxLXAcybybRtjhCB8ilJLxcITnmoTsSy+r18MdmjVlwDZvPkaoRZV+tr4Bmcg/z+lM4sUtbNtDCn6tXWWkzzTTRA=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757938752;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=nMENMgkEm0iRso4+GD3zG/CwrpYfs5RQRWgp6rLB49c=;
	b=IEoAaam3Zn7itG7dNrY+DGQy6+lO9oE1KsDhXMqXaKzVs3We29X5v9u2IzVHkGHA
	mC48TSmfm9nE+erbTnMIZTP2oYgI7dyhUqiqvJ1MD02Ei0GueMOMu+kYxLkUlyHtYHU
	Mc492F15OU23cwoiD9uIhSxn1REDswXVjQCIatpg=
X-Forwarded-Encrypted: i=1; AJvYcCXAnwHJ8Rei6mc2VJHKzs5o8eN5MJh1I3GVislwk+EQmvJZvtGDeiHm5iZXYhrtwT9jwod/hzUTojY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywd4u0eOd72/MHhcbgRo0LeK+wdG/f23Xw8Y8v9pncXOBhx0LuN
	6YMUMDZpP2wE+NMbBNRK29jUuwblsQ1cw+3e7pQk9FakryLRjSogGS1FdD7Kft0Gat0zFprQq4h
	A9jcshgsVuWhs0VB5As44INS5r59lxts=
X-Google-Smtp-Source: AGHT+IEDc5j9CT82P/bxsO2/ozi7hX/BTTrSvYLxtKTerJ43hrZ3Ms712PfIjmpf5OxPr2lWW/wqJ833BwQOk/K+9z0=
X-Received: by 2002:a05:6870:2c8e:b0:31d:7467:e394 with SMTP id
 586e51a60fabf-32e560ccda0mr6814067fac.4.1757938749926; Mon, 15 Sep 2025
 05:19:09 -0700 (PDT)
MIME-Version: 1.0
References: <20250912045254.3731398-1-Penny.Zheng@amd.com> 
  <2a818f1b-4326-4335-8ca5-4301632b1f33@suse.com>
In-Reply-To: <2a818f1b-4326-4335-8ca5-4301632b1f33@suse.com>
From: Tamas K Lengyel 
Date: Mon, 15 Sep 2025 08:18:35 -0400
X-Gmail-Original-Message-ID: 
X-Gm-Features: Ac12FXwGwFRKD5W32YGq_UAcjF4B6nNxjHy9XB3ZEoBMpyUf-ERQgphAGzqb_Bw
Message-ID: 
Subject: Re: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
To: Jan Beulich 
Cc: Penny Zheng , ray.huang@amd.com, 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Alexandru Isaila , Petre Pircalabu , 
	xen-devel@lists.xenproject.org, Oleksii Kurochko 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 14, 2025 at 9:49=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 14.09.2025 01:24, Tamas K Lengyel wrote:
> >>> +static inline bool vm_event_is_enabled(struct vcpu *v)
> >>> +{
> >>> +#ifdef CONFIG_VM_EVENT
> >>> +    return v->arch.vm_event !=3D NULL;
> >>
> >> Is "enabled" (in the function name) a good description of this conditi=
on, Tamas?
> >
> > Sure, sounds fine to me.
>
> That is the pointer alone being non-NULL identifies "enabled"? And not
> just e.g. "active" or "available" (can be enabled with further things
> set up)?

Nope, just that the struct is non-NULL means vm_event is enabled.
There is no meaningful distinction of enabled vs active vs available
in the contexts this is being checked.

Tamas


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 14:18:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 14:18:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124327.1466729 (Exim 4.92)
	(envelope-from )
	id 1uyA1i-00034l-UR; Mon, 15 Sep 2025 14:17:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124327.1466729; Mon, 15 Sep 2025 14: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 1uyA1i-00034e-Rg; Mon, 15 Sep 2025 14:17:54 +0000
Received: by outflank-mailman (input) for mailman id 1124327;
 Mon, 15 Sep 2025 14:17: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 1uyA1h-00034W-Hd
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 14:17:53 +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 c3e90db1-923e-11f0-9d13-b5c5bf9af7f9;
 Mon, 15 Sep 2025 16:17:52 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3c6abcfd142so2078556f8f.2
 for ; Mon, 15 Sep 2025 07:17:52 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54b03cf65csm8902679a12.16.2025.09.15.07.17.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 15 Sep 2025 07:17: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: c3e90db1-923e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757945871; x=1758550671; 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=zgUeb6mKZu68/qZ3rmFRYrVD6wnpBm5BM45eW203xEk=;
        b=APxk2yHaS57snpjonrVOvMfSZBzxLSY81xTwzbZKJEZZ7X3801QA8xL+VrnBbDq7Pq
         be3AFheVCDtOVzGJwbfh/ThqJQXPPZT2pNBPL/0bceQhioIwkhz4eo0N0t4aqAlMKUdA
         PnpiufSC8Y0l/9W7pMbFEqsS7a0GkWrt+eojS2LKcC/S0HjvvN/De1O9F4cxGFR7VQfY
         Fp8RVcgg2UB64T7P9DepjqU+Yr1N62X3P2g2IJ6K7fwEeQcA/N+jjnj5KHensVq/NJBO
         vQf2Xms9N8WYUIQFy4FUJGx1nqzIVaoYF7vmsvimGfNsYCFJi7h9IYKS0Ab3p1ppIlI1
         EFEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757945871; x=1758550671;
        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=zgUeb6mKZu68/qZ3rmFRYrVD6wnpBm5BM45eW203xEk=;
        b=N3BLSgJFmofj8DSMniRGCXg6b34uEvwM/v2NdimLIa6GAkxp9z18Hj4sjdSq8KBbGy
         zMsjcUBzho8RQYB5LE5P0O470+/ol/s7FgGpNKiWNEABhi2HjTcalyym8GVWE5yWlRpL
         wh+SGRa0LkXnOOZsD7bDG0/p+OxzElNj1ywZOPadriQ02ysFleAsIRKSuzFzinmXSxn1
         x/KKI2ocTR8Iob9J9Bu4VYonkCz8YXfEXCpZYGW8speGqPOLovEJSw3ywFkP1ywgXtyQ
         9beTrNY1fkQbw6+5SZ8Xl7kTGe5DJPYAR5Kvgt7iCiV/yqsbS4nvBvwtlAUxXr1Rj5W1
         2K5w==
X-Forwarded-Encrypted: i=1; AJvYcCXXJdWBUtaphgmIvZDMzNvaoS/L8fEy6x8AQg4p+ivFoTjYwHm5fEFGUV4qye83CVBhdIZBo2+LQiM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZHY/IFIZUVBu+g9M/PQqhcile+tVk7/RDZ9z6DwU/g3yXTmmg
	s26Eef8cvWsVmJgIeHOCmEOpewFa7+ei6L711pwBDsLGwX/dqt4DtAMinQ/Cgd74Vw==
X-Gm-Gg: ASbGncs1ZfbHQSjl2RXLDUawZVxyEJT7LyVyvzVCY8pDgoyNH4jz6smPbDE6xw4J14i
	q4gQVyPO9NiHV1Dmv+yNU+j9h1B5LunhoBxLTswx5jEzSJrE6l4hb09szyCWu/SudXojobZJ0uY
	S/qE27M82T31Un/RqQCotzp/BWiIySmkzTsgJxOQuuHOnUlIujLZEvs22pMqY9gM1hBzoYuCTUX
	dnh+LAv4FXaW9zW9jjtD+BkRksny8t0EzHi1hHK10f9i2dEusUN4GrVlS0wXXAI5N0CW1z8goVp
	HeZdYrkhge1AAiyPiotuotMB54b7STFXVi+t2s5qPEKCRJ69YC5fI7f1a12fG+VUTK5E+ZsBnsn
	gwPN6XB3dFNsQ+CrlSttOUI52xw/47TWKy5bffok7RA==
X-Google-Smtp-Source: AGHT+IEsKgnM5nqqUr0Nu/3YNyQyfCPieD57ZIq4FjErX4TjjlZTUUbkxYzPMiyPeultZ5LkkMfMIw==
X-Received: by 2002:a05:6000:2011:b0:3e8:ee5d:f31e with SMTP id ffacd0b85a97d-3e8ee5df6cemr6464675f8f.25.1757945871461;
        Mon, 15 Sep 2025 07:17:51 -0700 (PDT)
Message-ID: <492013c4-340a-4fee-81f1-348f9c646546@suse.com>
Date: Mon, 15 Sep 2025 16:17:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
 cpufreq_policy{}
To: "Penny, Zheng" 
Cc: "Andryuk, Jason" ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" , Stefano Stabellini 
References: <20250904063518.2097629-1-Penny.Zheng@amd.com>
 <20250904063518.2097629-2-Penny.Zheng@amd.com>
 <849f73f1-4004-4d17-a7a9-d755fb0f889b@suse.com>
 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.09.2025 05:49, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, September 8, 2025 6:02 PM
>> To: Penny, Zheng 
>> Cc: Andryuk, Jason ; xen-
>> devel@lists.xenproject.org
>> Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct cpufreq_policy{}
>>
>> (re-adding the list)
>>
>> On 05.09.2025 06:58, Penny, Zheng wrote:
>>> [Public]
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Thursday, September 4, 2025 7:51 PM
>>>> To: Penny, Zheng ; Andryuk, Jason
>>>> 
>>>> Cc: Andrew Cooper ; Roger Pau Monné
>>>> ; xen-devel@lists.xenproject.org
>>>> Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
>>>> cpufreq_policy{}
>>>>
>>>> On 04.09.2025 08:35, Penny Zheng wrote:
>>>>> For cpus sharing one cpufreq domain, cpufreq_driver.init() is only
>>>>> invoked on the firstcpu, so current per-CPU hwp driver data struct
>>>>> hwp_drv_data{} actually fails to be allocated for cpus other than
>>>>> the first one. There is no need to make it per-CPU.
>>>>> We embed struct hwp_drv_data{} into struct cpufreq_policy{}, then
>>>>> cpus could share the hwp driver data allocated for the firstcpu,
>>>>> like the way they share struct cpufreq_policy{}. We also make it a
>>>>> union, with "hwp", and later "amd-cppc" as a sub-struct.
>>>>
>>>> And ACPI, as per my patch (which then will need re-basing).
>>>>
>>>>> Suggested-by: Jan Beulich 
>>>>
>>>> Not quite, this really is Reported-by: as it's a bug you fix, and in
>>>> turn it also wants to gain a Fixes: tag. This also will need backporting.
>>>>
>>>> It would also have been nice if you had Cc-ed Jason right away,
>>>> seeing that this code was all written by him.
>>>>
>>>>> @@ -259,7 +258,7 @@ static int cf_check hwp_cpufreq_target(struct
>>>> cpufreq_policy *policy,
>>>>>                                         unsigned int relation)  {
>>>>>      unsigned int cpu = policy->cpu;
>>>>> -    struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
>>>>> +    struct hwp_drv_data *data = policy->u.hwp;
>>>>>      /* Zero everything to ensure reserved bits are zero... */
>>>>>      union hwp_request hwp_req = { .raw = 0 };
>>>>
>>>> Further down in this same function we have
>>>>
>>>>     on_selected_cpus(cpumask_of(cpu), hwp_write_request, policy, 1);
>>>>
>>>> That's similarly problematic when the CPU denoted by policy->cpu
>>>> isn't online anymore. (It's not quite clear whether all related
>>>> issues would want fixing together, or in multiple patches.)
>>>
>>> Checking the logic in cpufreq_del_cpu(), once any processor in the
>>> domain gets offline, the governor will stop.
>>
>> Yet with HWP and CPPC drivers being governor-less, how would that matter?
>>
>>> That is to say, only all processors in the domain are online, cpufreq driver could
>> still be effective. Which is also complies to the description in _PSD ACPI SPEC
>> for "Num Processors" [1]:
>>> ```
>>> The number of processors belonging to the domain for this logical processor’s
>> P-states. OSPM will not start performing power state transitions to a particular P-
>> state until this number of processors belonging to the same domain have been
>> detected and started.
>>> ```
>>> [1]
>>> https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control
>>> .html?highlight=cppc#pstatedependency-package-values
>>>
>>> I know that AMD CPPC is obeying the _PSD dependency relation too, even if
>> both CPPC Request register (ccd[15:0]_lthree0_core[7:0]_thread[1:0];
>> MSRC001_02B3) and CPPC Capability Register
>> (_ccd[15:0]_lthree0_core[7:0]_thread[1:0]; MSRC001_02B0) is Per-thread MSR.
>>> I don't have the hardware to test "sharing" logic. All my platform says
>> "HW_ALL" in _PSD.
>>
>> Aiui that's not mandated by the CPU spec, though. Plus HW_ALL still doesn't say
>> anything about the scope/size of each domain.
> 
> Sorry for the late reply.

No worries. From feedback from Stefano I was fearing much of a delay.

> I have discussed this with hardware team now, they said that we shall not expect any value other than "HW_ALL" from _PSD, if we have _CPC table, aka, CPPC enabled. Maybe except for some initial implementations, which may or may have not reached product release, this may still need a few time to look for conclusion
> And if it is HW_ALL, it means, in codes, we are invoking per-cpu cpufreq_driver.init, allocating per-cpu copufreq_policy, and etc. In HW_ALL, OSPM can make different state requests for processors in the domain, while hardware determines the resulting state for all processors in the domain.

Okay, so going back to v8 (and doing some unrelated adjustments there)
looks (to me) to be the best option. Eventually (I wouldn't insist on
this happening right away) we may want to actually reject non-HW_ALL
configurations when using this new driver.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 14:49:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 14:49:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124341.1466739 (Exim 4.92)
	(envelope-from )
	id 1uyAWL-0006sn-7O; Mon, 15 Sep 2025 14:49:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124341.1466739; Mon, 15 Sep 2025 14:49: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 1uyAWL-0006sg-4a; Mon, 15 Sep 2025 14:49:33 +0000
Received: by outflank-mailman (input) for mailman id 1124341;
 Mon, 15 Sep 2025 14:49: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 1uyAWJ-0006sa-Oj
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 14:49:31 +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 2f9302d7-9243-11f0-9d13-b5c5bf9af7f9;
 Mon, 15 Sep 2025 16:49:30 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3d44d734cabso2723211f8f.3
 for ; Mon, 15 Sep 2025 07:49:30 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-267b0bbab01sm9878695ad.116.2025.09.15.07.49.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 15 Sep 2025 07:49: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: 2f9302d7-9243-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757947770; x=1758552570; 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=6tXQeSc9UFIcIaC80pLCYs62/iLGI6+GAveXdj6Nq6Q=;
        b=fn9phLoKbuLuQ/M2tWsApumP0xRjyE6TjyxYYnlAdKLz/xSjTMvLWIpiNT82Ru3RXs
         z4rRztZFFm2C3Uu3whtCSl2rgf4DYfYku9+1M5EketgCeOrxQw6D0F405jlus87f9M25
         IAI1oXN9R5vhBWz7cHyNKi0Bvpg0I3TSF9YktCa1k0gh0toVr/xsYVe9dDF3y+TJ07YN
         R/ZIm+GmUeX1T85hcA+NJndmqdPw6owLGWdcNk5hl6XtO0Q5rmnXC3dIG0Cit8aN/pWK
         6zhxUxLK/smAz77I2qyGbR5lklc6aD9tvbqSVhD6izpdoI4jQBeG63mgXsWxtx9qr9Bx
         GAjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757947770; x=1758552570;
        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=6tXQeSc9UFIcIaC80pLCYs62/iLGI6+GAveXdj6Nq6Q=;
        b=sJsYors0J8Bc3SvasZ/1zKGgLTiA4gZ4lzko4OKlS4Y4udtcsLMb061vg4mH6iK7vX
         nGbW/QsyH/Bcanx9T6qTLviPn6cDoxwCHnCVy9JP5QQDlBc7OzHlDsPJk5ZohAVSy012
         Y8eD5mKHlcvggqVYIMp0l+OvUJdHu3SFjuffKWyYI/XYoxY6J/AnPO5vLzE8K4YCFm0i
         PgMs18MXggzqxNnZ3oz81QbklzxepDuyLcgRW7BMewEkUtW2RSV5pf2uZwAcHxuGWjrr
         USxdEPR/b0HxolD9XbZaLhLX6+gLKyGioAiznuF78MjarAT+UT27o93SZb8oWttxdQas
         gwJg==
X-Gm-Message-State: AOJu0YxzhL2sr1U9rgTSQMrGUrbAkZed3MXZztqtNC3sGWDcpwvskiNa
	jmT5ChKkCuGLpmso9lI9+yEq/oT0sOqrT6CT292eXczLuyDnkv3CZ/1qzWWAkrPqZg==
X-Gm-Gg: ASbGncto4LV2puBjIgdei23R2Ls/eArpDwrftTfnm4DlfGqiFMrYJzMTnFM7cgtX5E6
	FjF2RRgBkqj4cuuzIgi3CRTrxf/vkUI7jjXzekrEMjBecXwozU3/njD/v2r6M489eMzpZLY4qDx
	WdBJvD3498pgV3PTjtjwTEvFPE4yvoZPPVeRg7/OCcTKZyLAPhacIsENQkprVlKjpbKF12IBarI
	DyTC7TvFI/le/Pa399TA6eOAaNZxGNgrDMUBghLcJj3HccLD6BUomrII9xkjumMueHrxo9LsdUu
	IW1CEfJsMStWIQWLrXue6FTRx/lQ2MLjIzkwBu3r7KZ51CEE6sl/1jdpDBYlBhhjKf+v1mxcYIX
	DYZ96142BzYDaiyrp1uaH+lASON/swqX1X2seLfJs+Q==
X-Google-Smtp-Source: AGHT+IGmGCF/wt8DUigXpLtGunnYCs6QSBpcMIItOcImwJHxvysK5u/w6VKOnR4iM05xK2OM/KxWlQ==
X-Received: by 2002:a5d:5887:0:b0:3eb:2d8a:4fca with SMTP id ffacd0b85a97d-3eb2d8a9c6cmr2596053f8f.63.1757947770118;
        Mon, 15 Sep 2025 07:49:30 -0700 (PDT)
Message-ID: <9d55721e-bd95-4354-b839-f8896eedab24@suse.com>
Date: Mon, 15 Sep 2025 16:49:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/16] emul/ns16x50: implement MCR/MSR registers
To: Mykola Kvach 
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,
 dmukhin@xen.org
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-9-dmukhin@ford.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.09.2025 08:00, Mykola Kvach wrote:
> On Tue, Sep 9, 2025 at 12:12 AM  wrote:
>> --- a/xen/common/emul/vuart/ns16x50.c
>> +++ b/xen/common/emul/vuart/ns16x50.c
>> @@ -107,7 +107,7 @@ static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
>>
>>  static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
>>  {
>> -    return false;
>> +    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
>>  }
>>
>>  /*
>> @@ -232,12 +232,63 @@ static int ns16x50_io_write8(
>>              regs[UART_LCR] = val;
>>              break;
>>
>> +        case UART_MCR: {
> 
> Probably the opening brace should be moved to the next line.
> See CODING_STYLE:
> 
> Braces ('{' and '}') are usually placed on a line of their own, except
> for:
> 
> - the do/while loop
> - the opening brace in definitions of enum, struct, and union
> - the opening brace in initializers
> - compound literals

strictly by the wording of the doc you're right, yet if you go look then
you'll see that we really permit both forms (and apparently prefer the
one used here).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 16:53:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 16:53:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124366.1466749 (Exim 4.92)
	(envelope-from )
	id 1uyCRd-0005fx-IZ; Mon, 15 Sep 2025 16:52:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124366.1466749; Mon, 15 Sep 2025 16:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyCRd-0005fp-FO; Mon, 15 Sep 2025 16:52:49 +0000
Received: by outflank-mailman (input) for mailman id 1124366;
 Mon, 15 Sep 2025 16: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 1uyCRc-0005ff-4p
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 16:52:48 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20729.outbound.protection.outlook.com
 [2a01:111:f403:2613::729])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 67d2b913-9254-11f0-9d13-b5c5bf9af7f9;
 Mon, 15 Sep 2025 18:52:46 +0200 (CEST)
Received: from DB9P250MB0523.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:338::7) by
 PA1P250MB1086.EURP250.PROD.OUTLOOK.COM (2603:10a6:102:454::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9115.19; Mon, 15 Sep 2025 16:52:44 +0000
Received: from DB9P250MB0523.EURP250.PROD.OUTLOOK.COM
 ([fe80::bfa1:a1c3:42a9:744e]) by DB9P250MB0523.EURP250.PROD.OUTLOOK.COM
 ([fe80::bfa1:a1c3:42a9:744e%5]) with mapi id 15.20.9115.017; Mon, 15 Sep 2025
 16:52: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: 67d2b913-9254-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=utSICj1gu91iMhrwhNMgff7g+tUwbmENO/94n59pgxFq4gtLvZ0n/TTh/VxZTAiS1sI/Jw9/BXvt8ozdcQ7qni0z2TC091HhXsXs3c0wDAGctuWd2p9LdAUMIYduHDkGL6B6uT8keTA0CfE0VWKd73DZPSaPVBYl4ok/lMps2/CgXscceGitGbe1o7Rt7WFli2avTHEy34TOReAw0S2+OVLmEIgn0cKR20TZTeeVO4RG8ZB/i65xeL9DaBQvvJ6tgVwC0Zzsv4i9/HT6+UExx/ihmDS8beNlR0nBPbwXmQ7tWTi/HNpJCFuJ8uPru8q0KD0TqFyZFQoVeVhiLNAcFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qdkLOj+4y/jK1MmehA41W2jn/zC/qER/r8Sveptw/I8=;
 b=y850Ax2mSnfz89xBJ1YS2weJDF/YYpc2itGluRzg5yX8pYkrKnakwrsEov0OSzNSFLZhyt5/dT44cPUW7Vk3Gf8wdd8oPtCyF78/N7Vn0ZIqx+P32V67fo7WPliT7gVnPaAFmMUqcO5ksyTBVjisjdc6ldHUfcPQJRsJsSmhOj4WsCBxYlGXzd1lAqOR/bnUs8zs7uUc5eh4nQj2h35+hWB8uIsTn6cDkCvcWEgQum4HQ79IW4EpvdI61ApX9q/CLjVWZWUB6UpO5JEhf85QyhuOJIqZCBWjsj+VOhkHQyPTjbKMvcjxqC7QB3yP4kACsbodeyjuE9FbBc8p+xY04w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=student.uliege.be; dmarc=pass action=none
 header.from=student.uliege.be; dkim=pass header.d=student.uliege.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.uliege.be;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=qdkLOj+4y/jK1MmehA41W2jn/zC/qER/r8Sveptw/I8=;
 b=nDS7O2ooEYFbJfzKBXXFxbsbqg9AWhG9R7Bq8ltFRZwxZpl9Uyy7b6SQfYqdTlelgcLaOcHEwionu3kqSPNkJfcrK8jEs5MaKMVklb5bsTzL8laXv1dUFDmqO6TuZcIXQ4+HK7YBaWruO6zt42yKIwlDjr0sn0VmTqcfZXi12+KJbqOPziRwaX396aGhuqZtH8+diGh6IcBYzwwdYrsci790P6aFMb6/UZHtvDilrXvUBxiZGXGzGUxr7nMZR3G5A3akBRfsK50xLsvdXlz7ftzVPJsBLmIhaWJEqQqQUwxApd5WESpwrDnqrYUhC0rmIdEDfaorz4I+7EeBSC/ajQ==
From: Ngamia Djabiri Julie 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" 
Subject: RE: Request for patch to fix boot loop issue in Xen 4.17.6
Thread-Topic: Request for patch to fix boot loop issue in Xen 4.17.6
Thread-Index: AQHbu22NmgKiRiHk2kKM1KfVYdOb37POwC4AgMaJ3Tw=
Date: Mon, 15 Sep 2025 16:52:44 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=student.uliege.be;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB9P250MB0523:EE_|PA1P250MB1086:EE_
x-ms-office365-filtering-correlation-id: bc9a8513-5e45-4571-4169-08ddf4784a9d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|10070799003|366016|1800799024|376014|8096899003|13003099007|38070700021|7053199007;
x-microsoft-antispam-message-info:
 =?Windows-1252?Q?/SUrHFpXVCeTcSlIwNet4WIbYNMyKNfpEyYde6OO3daFEYdpyEdXpOqd?=
 =?Windows-1252?Q?9En2V8h8sYpaLVgEEsfA4ZVKCEHYMSBGG1nK2hIHh64LE6KVi2haCQ4V?=
 =?Windows-1252?Q?shcc7hOK7Ab9MMBYF7JBY7KIVpK235U2rVVHF5J/pNjyXJaBNRNnas5R?=
 =?Windows-1252?Q?QbWhcbqCYfUvs6otdmUNA3STkiidCQCTfjg0Lr+pBq9ywkNj+KOVOcr4?=
 =?Windows-1252?Q?cjPe2rqXHykcxQgx1nI36QzgOValCLibLjMVzNsHJaDGQHVLOXVHwEzX?=
 =?Windows-1252?Q?sr8FdX8NEs70JOd5U7nY7JGRI8x02WyGJWyRaVYwUPPEEbaRYMb/az89?=
 =?Windows-1252?Q?59EC1mgifD17rFctgvqClg9lstek4xXO2aMUZ84MC51JNCdINsso9I/y?=
 =?Windows-1252?Q?J6kzKvRkWA/vvOSy0P4kJtX89I0d9hBdo10MQ1NZtBgVOOvfEaNp70Nm?=
 =?Windows-1252?Q?x0g3H6Nl77oHH09Wc10LKAsSMAR5/5RWTvN34vBKPoGnDMt88WgL3Dnf?=
 =?Windows-1252?Q?68O69q/WHDkx21eGkQcWeYZEjAmB9ZLFef1rNAPFxWtcy209N5OGh7By?=
 =?Windows-1252?Q?8VwIBp4SRue1VxtOo0df/cFM5WM9e2HGSK6cFl2pz0BQpm3LfMSh5N6g?=
 =?Windows-1252?Q?vsCQ8r9cRC9dxwpoQXdsbulkKJSHjWcs2hugyrnzlbeRU/y8oGwSYm+d?=
 =?Windows-1252?Q?7kTRaQMp10vji6+CSEJvkosfVpvGRb63QRu+fEm7QV2bOylZCR1JihyJ?=
 =?Windows-1252?Q?Xn6/2uJyU5CNl7ogGSeoaORxt80Dk2L7UdSyaMPjLhc1noc4bTr3v5IL?=
 =?Windows-1252?Q?Vl8nNExO8zXhAg79zp/87sVrJsOr6lIUYY4YXV998YR7hS9CwF9Lm06A?=
 =?Windows-1252?Q?8Qyx4/n7FCPR/pNK0090W3MA2nzx0SPex/yrUz1/b9vg2kI9JT6Xw64B?=
 =?Windows-1252?Q?BMmcN8SpeFnm4krpOOj2vlGXeoUXnWLlQb3tWHRZrzbMqtMf62BhnbkF?=
 =?Windows-1252?Q?r1dUj+o/1COeRvTtRH88tYxwn9vkAXw0glFKCuPhS7cZ6K3fs3tRBiOf?=
 =?Windows-1252?Q?crZTE56+WQqPv59D18oYV7vvAKID4bRdNbpX5rjWgZqIsqe3TYVUwV48?=
 =?Windows-1252?Q?uuncwNwaAS07W+bcST+qPhl4E5fjyl8hqw9jZpeJq7e9ya99xqLszs0L?=
 =?Windows-1252?Q?0tNr58v5x3lLSKD3bINPEAjI7Kzq7TcG6hx7pUgMnx2RIryJZZjcUeW5?=
 =?Windows-1252?Q?KKd06eWNhNRV8o/nmlG25vlOngJsYdQYNKeBkltAGH2pRHE6/l85/cfB?=
 =?Windows-1252?Q?OM5Q4Y7mbsc84Bli8lirXPKrFHLY1f4hO1irTVV+ORbrer1PgkqS3DsB?=
 =?Windows-1252?Q?aQ3a2/CadQIZr5jWoUYC7CNnso59SOLIaYS1weLDABHxZgeK+wrSoOKN?=
 =?Windows-1252?Q?mTeh4YAMwQW8/6Q98lEbAwviqyIFZpF+msqjLsS2TfgjBpcAN7EKNOJd?=
 =?Windows-1252?Q?wIp3jZcPmjA4PcU0RlsEm1DiF8AC1LXurSUN1vsZ4j4YviM/Acg=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9P250MB0523.EURP250.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(1800799024)(376014)(8096899003)(13003099007)(38070700021)(7053199007);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?Windows-1252?Q?LsYyMOmA6rIJQhA24tdwOHRpwLVCSmVocEtNQjqodTjt84wKuu9iPXnY?=
 =?Windows-1252?Q?ejgzpE1Lfhlww5BPLpbGNaTj0NqCuBceAKWWnvOsvteoGtEELZ9fE4yo?=
 =?Windows-1252?Q?T6KStu0PbEEnB/4JWxu8R9VFGAH9DLT3qkNCvVfJNIjT65PN26kAP8I4?=
 =?Windows-1252?Q?1f71/cUBqLybeqEbEcz9i9v1TJPRqLwgUoJH0f3nHHpXJZoyHLAyN+w2?=
 =?Windows-1252?Q?V/HJuULlWuwGQ6C+Rb/DScDDjU+3sT0InavcgO7R1poafzKW8zSCupgf?=
 =?Windows-1252?Q?jhw97YMjZeiP2F6hSTg9+e4HWv0Ib7pXJGP1rFzGZULcVnlXvMbERNrG?=
 =?Windows-1252?Q?6AAQETnEEwSMeBlut19/T3YKZKhbFrnk9MF/tvB6qCqIlZ0UJQ58fZVO?=
 =?Windows-1252?Q?IMUdLqmUWKgP4qwjFT863y0hyQ28DCKzv6ynB966ugTdQWiNaEvbUSVY?=
 =?Windows-1252?Q?VOKpvTyiBqzWneKYrkz8OE2AZRn1AcHeq2204fr7eQzvBk7PUZzM8qoU?=
 =?Windows-1252?Q?73Bb5LkBmpdDcH/VGmTds5bMY1p2uBw9Ddl3h5kAj2+reZG2M7bN2W0t?=
 =?Windows-1252?Q?zQqPfxAX2DgPlj6ZuSzWvpQQePYpgxy/91pCa1YAEmEKzqLp0qJcKrnN?=
 =?Windows-1252?Q?j/vU4Yh0jc3O4uM5Fx9nD6BpFDAzi5fayNFgreibzHn2jSn5/2FCZqh4?=
 =?Windows-1252?Q?P7bLcUZJPVxtL1CNX1qiPnGkQobnfHALlG2Is8xjo2WkT5UI6Ttl02EY?=
 =?Windows-1252?Q?W71YtimKQb+iE2Y2W0Z1WThiIKD/pPbrxzvujWxJx8oN6uOjA0kjbfC4?=
 =?Windows-1252?Q?pRwqTLnlHMxcH0K1rK5+YSZqjl+wAYUmAcdonrAKRxiKYhH9PkcxhWpG?=
 =?Windows-1252?Q?IxJGeIdigc2UMMCVtkFxxtXzBNQB8yjQjCGkx39tFwVyiaHdsiWUJqh4?=
 =?Windows-1252?Q?m0APZunwqNvdv+iCoy4pdcR1enFnF1e10kud9OjoPhNM1xs5MlYry7fb?=
 =?Windows-1252?Q?52ink2qabVsAdrXj+tjb+O9xWkjxTwTSQ6KLHpEEJWJcyuaKOBUdzBQu?=
 =?Windows-1252?Q?jKySz+4mUX5Cw4Mpn9+abzY8RAueIQy7HTTu0OYCyKzaI8GCUNDM4lw7?=
 =?Windows-1252?Q?Gc/cM/lT8LstAaD1qP61QGXaNlEzTz+nkELZLoMwD476Q3QUVQAb7k5B?=
 =?Windows-1252?Q?DFCd6nIjr2O5/OSN6u12kjtwNq6pN/ZxQHVW7kavp/b3P7U7Xfy9iqDw?=
 =?Windows-1252?Q?/foe/T/xqkVIQODCtStVrP+LH9Rb2Xj9cQN82rznYOfx/xf2/YiNeH9F?=
 =?Windows-1252?Q?yT2eWlO46xcurv83gdiVFrLCtG3uTaXJitlpPiIZWVFQLA8OF4WB3sGA?=
 =?Windows-1252?Q?A4nLsDP4DUc1m/PlLD5Jiy/aymVSA7+EvwCbWZnWLa/s9O8lrkLpNX4J?=
 =?Windows-1252?Q?Y3hwcuB7DIYxKAkRnjb8MFzJpBEIp5wsvhyjWL8TfpUvPdJ7gLJ9RW7P?=
 =?Windows-1252?Q?HFdCHkJ/KpRB+RdTt21iIeA0sosQkfzi7u5BHuEqHBXjYc8R07GWq3S7?=
 =?Windows-1252?Q?4xzwWCscJRcLm57jXdmUNaktFGqbmQkjTqeF8IzyCjB1U3DCG8hohhr5?=
 =?Windows-1252?Q?f537HgUVtSs6YTL11fpA/WIAn1ohzKpVS3G/PJanpLmOje+vD+AvSRSE?=
 =?Windows-1252?Q?CMZFrW/uokJJyQig3McERSUOQLSWzsCnZN2E60Z4042txsdg8s/zg7nI?=
 =?Windows-1252?Q?CEAJytTyDWxV8eS9on2ADhrEhu+wcjVc1qC4pjOoAtUSvjslZml/4hgo?=
 =?Windows-1252?Q?Cceu3+qHE+KWmfhAhgZ0h3/KWzw=3D?=
Content-Type: multipart/alternative;
	boundary="_000_DB9P250MB0523A25B90E1223BD1037EE7A015ADB9P250MB0523EURP_"
MIME-Version: 1.0
X-OriginatorOrg: student.uliege.be
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9P250MB0523.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: bc9a8513-5e45-4571-4169-08ddf4784a9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2025 16:52:44.1065
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 62e13b84-1960-4562-8c7f-72472951da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2EZ2wK/uu0bhYpecjpKKJ0MntlIUIEr2U3EDo6Js+Qg3MAdU9pfHcrc/qWFSqOMjphYC81+Add4n2JuFYu7ObgcgOETFU5KMmxsi/AARjxNzaQ3/XC/HhYQANF7tsI/j
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1P250MB1086

--_000_DB9P250MB0523A25B90E1223BD1037EE7A015ADB9P250MB0523EURP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dear Jan,
I want to underline that this issue is a critical security problem affectin=
g system availability and that it has direct consequences for XEN users:

  *
Systems running Xen 4.17.0 =96 4.17.3 will fail to boot when upgraded to 4.=
17.4 or 4.17.5 under Intel Nested Virtualization.

  *
Diagnosing and fixing this requires advanced skills and time, and in some c=
ases may be impossible for standard users, leaving their systems unusable o=
r unmaintained.

  *
The problem has been known to Xen maintainers since 2024-01-20, but no offi=
cial communication has been made.

  *
Root cause: commit 6bdb9651 (2024-01-17)

  *
Fix: commit dd05d265 (2025-01-21), applied in Xen=
 4.18.5, 4.19.2, 4.20.0-rc3

  *
Xen 4.17 remains security-supported until 2025-12-12, but this fix was not =
included in 4.17.5


Suggestion: I would suggest creating an XSA to notify the community and/or =
include this fix in Xen 4.17.6. This would help prevent affected users from=
 encountering unbootable systems and protect the availability of their envi=
ronments.
Thank you for your attention.
Best regards,
Julie
________________________________
De : Jan Beulich 
Envoy=E9 : lundi 12 mai 2025 10:54
=C0 : Ngamia Djabiri Julie 
Cc : xen-devel@lists.xenproject.org 
Objet : Re: Request for patch to fix boot loop issue in Xen 4.17.6

On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
> Dear Xen developers,
>
> I would like to ask if the following fix can also be included in Xen 4.17=
.6 (and eventually in the Xen versions after 4.17.6 that don't have the fix=
) :
>
> https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3Ddd05d265b8=
abda4cc7206b29cd71b77fb46658bf
>
> This bug causes a boot loop in nested virtualization environments (for in=
stance nested environments that use VMware Workstation), making Xen unable =
to start. It was introduced in version 4.17.3 and the fix has already be in=
cluded in 4.19(.2) and 4.20(.0) and woud be planned to be included in Xen 4=
.18.6 in the coming weeks.
>
> Even though Xen 4.17 is in security-only support, this is an issue that b=
locks testing and usage for users and projects such as Alpine Linux.

I fear I don't view this severe enough an issue to break the security-only
status of that branch. People concerned ought to simply update to a branch
where the bug was fixed. Or the distro could include a backport.

The underlying consideration being that once we start making exceptions,
more exceptions will be asked for, along the lines of ...

> I am a student using Xen in a nested setup for Virtal Machine Introspecti=
on (VMI), and including this fix in 4.17.6 would really help avoid these pr=
oblems for others in a similar case.

... what you say here.

Jan

--_000_DB9P250MB0523A25B90E1223BD1037EE7A015ADB9P250MB0523EURP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Dear Jan,



I want to underline that this issue is a critical security problem<=
/b> affecting
system availability and that it has direct consequences fo=
r XEN users:


    

  • 

    
Systems running Xen 4.17.0 =96 4.17.3 will fail to boot&=
nbsp;when upgraded to 4.17.4 or 4.17.5 under Intel Nested Virtualization.

    

    

    

  • 

    
Diagnosing and fixing this requires advanced skills and time, and in s=
ome cases may be impossible for standard users, leaving their systems =
unusable or unmaintained.
    

    

    

    

  • 

    
The problem has been known to Xen maintainers since 202=
4-01-20, but no official communication has been made.
    

    

    

    

  • 

    
Root cause: commit 6bdb9651&nb=
sp;(2024-01-17)
    

    

    

    

  • 

    
Fix: commit dd05d265 (202=
5-01-21),
 applied in Xen 4.18.5, 4.19.2, 4.20.0-rc3
    

    

    

    

  • 

    
Xen 4.17 remains security-supported until 2025-12-12, but this fix w=
as 
not included in 4.17.5
    

    

    

    




Suggestion: I would suggest creating an XSA =
to notify the community and/or include this fix in
Xen 4.17.6. This would help prevent affected users from encountering=
 unbootable systems and protect the availability of their environments.


Thank you for your attention.



Best regards,



Julie








De : Jan Beulich <jbeuli=
ch@suse.com>

Envoy=E9 : lundi 12 mai 2025 10:54

=C0 : Ngamia Djabiri Julie <Julie.NgamiaDjabiri@student.uliege.be=
>

Cc : xen-devel@lists.xenproject.org <xen-devel@lists.xenproj=
ect.org>

Objet : Re: Request for patch to fix boot loop issue in Xen 4.17.6

 






On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
> Dear Xen developers,

> 

> I would like to ask if the following fix can also be included in Xen 4=
.17.6 (and eventually in the Xen versions after 4.17.6 that don't have the =
fix) :

> 

> 
https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3Ddd05d265b8ab=
da4cc7206b29cd71b77fb46658bf

> 

> This bug causes a boot loop in nested virtualization environments (for=
 instance nested environments that use VMware Workstation), making Xen unab=
le to start. It was introduced in version 4.17.3 and the fix has already be=
 included in 4.19(.2) and 4.20(.0)
 and woud be planned to be included in Xen 4.18.6 in the coming weeks.

> 

> Even though Xen 4.17 is in security-only support, this is an issue tha=
t blocks testing and usage for users and projects such as Alpine Linux.



I fear I don't view this severe enough an issue to break the security-only<=
br>
status of that branch. People concerned ought to simply update to a branch<=
br>
where the bug was fixed. Or the distro could include a backport.



The underlying consideration being that once we start making exceptions,
more exceptions will be asked for, along the lines of ...



> I am a student using Xen in a nested setup for Virtal Machine Introspe=
ction (VMI), and including this fix in 4.17.6 would really help avoid these=
 problems for others in a similar case.



... what you say here.



Jan








--_000_DB9P250MB0523A25B90E1223BD1037EE7A015ADB9P250MB0523EURP_--


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 16:56:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 16:56:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124381.1466760 (Exim 4.92)
	(envelope-from )
	id 1uyCUv-0006Pq-6H; Mon, 15 Sep 2025 16:56:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124381.1466760; Mon, 15 Sep 2025 16:56: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 1uyCUv-0006Pj-2Z; Mon, 15 Sep 2025 16:56:13 +0000
Received: by outflank-mailman (input) for mailman id 1124381;
 Mon, 15 Sep 2025 16:56: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 1uyCUu-0006Pd-7E
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 16:56:12 +0000
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com
 [2607:f8b0:4864:20::732])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e0cd7200-9254-11f0-9809-7dc792cee155;
 Mon, 15 Sep 2025 18:56:10 +0200 (CEST)
Received: by mail-qk1-x732.google.com with SMTP id
 af79cd13be357-8127215a4c6so518367385a.0
 for ; Mon, 15 Sep 2025 09:56:10 -0700 (PDT)
Received: from localhost.localdomain
 (host-154-4.mdu.ilcmifre.champaign.il.us.clients.pavlovmedia.net.
 [66.253.154.4]) by smtp.gmail.com with ESMTPSA id
 af79cd13be357-820c974d5edsm837402085a.26.2025.09.15.09.56.07
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 15 Sep 2025 09:56: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: e0cd7200-9254-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757955369; x=1758560169; 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=1rAZQe97A8nOk7FS8pbW2Xc+T7ma3O2xAHfOfQiOuws=;
        b=Pjda92+4R+3jaesJYmKusDi2vD9cnO/1+R7Jj9aJTuIhyEENx/GvWbE00sKWLkqfIS
         abstBLS2yyor4o75+nPK5xajukTeluqMF7F8EXBlkMmQX7kFUq7yky1wRjmtVMExoxDB
         c0i8DIIxauoqxjZSzM2aFTHNUjLwjbHp+N1YeNGQkJE8tb6rf1MyCjctzPrG1/JHzfji
         psxbh9s7xmzj8i5nXrMXYABoMtTU9nqA2O036sbD3xpLw7kUcQUMwosv8wvyI1yklQCn
         PlGbAxxP4j2Mw3Yb/HNrW+BRtovZ9WqkMNxNtMah+mBr+dNTgmoVIZ+OhcG8beGa4T7F
         cNbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757955369; x=1758560169;
        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=1rAZQe97A8nOk7FS8pbW2Xc+T7ma3O2xAHfOfQiOuws=;
        b=U97kNj1z2171CHk8bqNPkFlqIUcs45XTSgaJQjJTpD3PlTmh9GeIjrG7C7lB34Jyd1
         JerV7ZivpTH/c/s9WJPwmAZbk63/sGlyfVMBkNIzsPHMHnoV8NGAwlQKWrjSpZLxS58K
         qyCxgVPylH7rQzyQco9Zcab9VPK59FU0nsRV6tyb3JRwc9wFpBFCtjK4Z487l03RZc/z
         xPepDxsVNE6+bS+RiTJxgNymoxGrslvhk8JgBr6lIvTX3aK6o7R1YZU74VjAGplHOgZ1
         kynCGufjn55HR427crWXffmWJyTC966sUBAFG5TNBUBb/wwlwQLs2ubC8hILaG+adsRJ
         yvvw==
X-Gm-Message-State: AOJu0YzaKCdyOLDHQbhHxVlliicxri557oq65OYeZF87JgG0zsZUZyhb
	3Eei0gK6gnDLhecehANqTg02taFT2H8ayo5Z8fFFpbQfndyfyHFVgyhzU9PEAH8=
X-Gm-Gg: ASbGncs4JtwPyK+3orR22dQE9Yec9gOt4KFoVjS4YdxSKmtm9RM3lzByPbefZVtkRIy
	FmQJfpMjLvCa5oP45gZly+61NlZyZCpz/tBIORLQo7A/zosgcvPfnN/DmzMwkETcJ0tDagR688/
	OEhojBUsUV30nbcOPfwHxpzEJcjBC7Ll8NUOHcrWTvS68gt4MZu6KlePjsNgcLmuGkujabfEc75
	BANSQkqI266NZ5MxD9c0UjG4E9ZxWqlbDcoK2z9bX33epcMUw7PqSY+dQdv0LBL0gSsk+K6Sz7k
	1fcZYluNkzm+R1Ft8VoclPXQqCkUk+38aA1nxKDwylo9pPaFG2JWu4aI1yve+OJarCgpEGrLlkk
	7AjHjnUiL7vm353PLMTVp4jtKlv9qptfvr0g5GP+BgoSxJXJLyEgfFUqUP9IdK8njkIomgVpNBp
	5RmnvCMmCsoGJ+ZpW565Dc4iROzmH5vGty1XKc4/mCQlXCMPEQPkJcRapRR66o
X-Google-Smtp-Source: AGHT+IEUZt+Slbf2P4wxa7IUZCWchf5tchX1yumP4roroVSNZApDnQHzN0X3nxgCiIUQln9gdyYEmw==
X-Received: by 2002:a05:620a:7185:b0:823:f5e9:db04 with SMTP id af79cd13be357-823f5e9dba8mr1283601785a.33.1757955368482;
        Mon, 15 Sep 2025 09:56:08 -0700 (PDT)
From: Saman Dehghan 
To: xen-devel@lists.xenproject.org
Cc: Saman Dehghan ,
	Jan Beulich 
Subject: [llvm coverage] Update LLVM profile raw format from v4 to v10
Date: Mon, 15 Sep 2025 11:56:05 -0500
Message-ID: <12f2f3bd9010422004c38c23f6758c87df8682a5.1757951300.git.samaan.dehghan@gmail.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch updates the LLVM profile raw format in
`xen/common/coverage/llvm.c` from version 4 to version 10,
enabling compatibility with LLVM versions 19 and 20.
While the patch supports only one version:
1. It seems better to support one version than no version --
   the current profile version 4 is not compatible with
   LLVM version 11 or later
2. The patch could be extended to support multiple
   LLVM profile versions, e.g., from 5 to 10

The llvm-cov toolchain, with its Source-based Code Coverage,
offers two substantial advantages over gcov:
  - More accurate coverage reporting when compiler optimizations
    are enabled, ensuring better analysis of optimized code.
  - Better tracking of coverage across inlined function boundaries,
    critical for complex control flows in Xen.

Overall, this change would enhance Xen's code coverage analysis
capabilities by leveraging the latest LLVM toolchain improvements,
particularly for safety-critical hypervisor code.

The patch modifies only `xen/common/coverage/llvm.c`,
maintaining API compatibility while enabling modern toolchain support.
Testing was performed with LLVM 19 and 20 to confirm functionality.

---
 xen/common/coverage/llvm.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/xen/common/coverage/llvm.c b/xen/common/coverage/llvm.c
index 517b2aa8c2..3da82c6cda 100644
--- a/xen/common/coverage/llvm.c
+++ b/xen/common/coverage/llvm.c
@@ -44,27 +44,37 @@
     ((uint64_t)'f' << 16) | ((uint64_t)'R' << 8)  | ((uint64_t)129)
 #endif
 
-#define LLVM_PROFILE_VERSION    4
-#define LLVM_PROFILE_NUM_KINDS  2
+#define LLVM_PROFILE_VERSION    10
+#define LLVM_PROFILE_NUM_KINDS  3
 
 struct llvm_profile_data {
     uint64_t name_ref;
     uint64_t function_hash;
-    void *counter;
+    void *relative_counter;
+    void *relative_bitmap;
     void *function;
     void *values;
     uint32_t nr_counters;
     uint16_t nr_value_sites[LLVM_PROFILE_NUM_KINDS];
+    uint32_t numbitmap_bytes;
 };
 
 struct llvm_profile_header {
     uint64_t magic;
     uint64_t version;
-    uint64_t data_size;
-    uint64_t counters_size;
+    uint64_t binary_ids_size;
+    uint64_t num_data;
+    uint64_t padding_bytes_before_counters;
+    uint64_t num_counters;
+    uint64_t padding_bytes_after_counters;
+    uint64_t num_bitmap_bytes;    
+    uint64_t padding_bytes_after_bitmap_bytes;
     uint64_t names_size;
     uint64_t counters_delta;
+    uint64_t bitmap_delta;
     uint64_t names_delta;
+    uint64_t num_vtables;
+    uint64_t vnames_size;
     uint64_t value_kind_last;
 };
 
@@ -110,7 +120,7 @@ static int cf_check dump(
         .data_size = (END_DATA - START_DATA) / sizeof(struct llvm_profile_data),
         .counters_size = (END_COUNTERS - START_COUNTERS) / sizeof(uint64_t),
         .names_size = END_NAMES - START_NAMES,
-        .counters_delta = (uintptr_t)START_COUNTERS,
+        .counters_delta = (uintptr_t)(START_COUNTERS - START_DATA),
         .names_delta = (uintptr_t)START_NAMES,
         .value_kind_last = LLVM_PROFILE_NUM_KINDS - 1,
     };
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 15 19:02:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 19:02:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124405.1466770 (Exim 4.92)
	(envelope-from )
	id 1uyETH-00058X-N1; Mon, 15 Sep 2025 19:02:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124405.1466770; Mon, 15 Sep 2025 19:02: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 1uyETH-00058P-Hk; Mon, 15 Sep 2025 19:02:39 +0000
Received: by outflank-mailman (input) for mailman id 1124405;
 Mon, 15 Sep 2025 19:02:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uyETF-00058J-Rn
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 19:02:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uyETF-00BKi4-1S;
 Mon, 15 Sep 2025 19:02:37 +0000
Received: from [2a02:8012:3a1:0:94fa:2916:1471:b94a]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uyETF-00B54Q-1n;
 Mon, 15 Sep 2025 19:02: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=c6ZWZdslp/khrddMiuDlVzvNHOb1VnysWLgLZoQhNeM=; b=WU0M7REmFqWaRYz9aq2WxSRMd1
	xlYT2qvsoyPZ2CXN2LoTs3NAi+1B5hAGtcCXP86Hx9dXne8OC//bWpvsXZfrfpbdyasGHNby3gqw/
	LjYgkvC3w7gmFCz2UgVDGxPuMQrQhNOJPhvsvG3bK4emGaWWIphmUO7dHT+CTZ6tZen0=;
Message-ID: <14f698f1-b1cf-4244-9157-7214710e92d2@xen.org>
Date: Mon, 15 Sep 2025 20:02:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 8/9] SUPPORT.md: add xenstorepvh-stubdom live update
Content-Language: en-GB
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 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: <20250730122305.4050-1-jgross@suse.com>
 <20250730122305.4050-9-jgross@suse.com>
 <25c867ca-3b73-4b65-be98-c2d7b3ea4f7b@xen.org>
 <1f1a5a8f-0b1f-4e50-9467-3d27d8a3089d@suse.com>
From: Julien Grall 
In-Reply-To: <1f1a5a8f-0b1f-4e50-9467-3d27d8a3089d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Juergen,

On 13/09/2025 08:16, Jürgen Groß wrote:
> On 12.09.25 23:09, Julien Grall wrote:
>> Hi Juergen,
>>
>> Sorry for the late answer.
>>
>> On 30/07/2025 13:23, Juergen Gross wrote:
>>> Live update is now working with the PVH variant of xenstore-stubdom.
>>  > > Signed-off-by: Juergen Gross 
>>> ---
>>> V2:
>>> - new patch
>>> ---
>>>   SUPPORT.md | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>> index 6a82a92189..eb44ee85fd 100644
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -280,7 +280,7 @@ or itself will not be regarded a security issue.
>>>   ### C xenstore stubdom PVH
>>>       Status: Supported
>>> -    Status, Liveupdate: Not implemented
>>> +    Status, Liveupdate: Supported
>>
>> I went through the changes in Xenstored for the stubdom and I have one 
>> question regarding [1]. Does this mean the event channel will be 
>> closed during Live- Update? Asking because I vaguely remember we need 
>> to keep them open to avoid losing events. I am wondering how this 
>> would work in stubdom?
> 
> The event channel is still open, its just the Mini-OS internals that don't
> know about this. This is the reason for calling xenevtchn_bind() to bring
> hypervisor and Mini-OS view in sync again, without changing the hypervisor
> side.

Thanks for the clarification.

Acked-by: Julien Grall 

Cheers,
-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Sep 15 19:14:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 19:14:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124418.1466780 (Exim 4.92)
	(envelope-from )
	id 1uyEeN-0006nu-Jv; Mon, 15 Sep 2025 19:14:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124418.1466780; Mon, 15 Sep 2025 19: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 1uyEeN-0006nn-Gh; Mon, 15 Sep 2025 19:14:07 +0000
Received: by outflank-mailman (input) for mailman id 1124418;
 Mon, 15 Sep 2025 19:14:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uyEeM-0006nh-B5
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 19:14:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uyEeL-00BKto-2r;
 Mon, 15 Sep 2025 19:14:05 +0000
Received: from [2a02:8012:3a1:0:94fa:2916:1471:b94a]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uyEeL-00B5wL-3B;
 Mon, 15 Sep 2025 19:14: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" 
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=qOgrIpvX9kR6ubwlRpnwkvinyWtx5gOYfvrPokiGukQ=; b=Shmq1GKIII1Ae26s3G9COWSjhd
	9Glw76tfCPYpky7o+gCCL934WYXDgSLoTeN8vkwXJgDfyVkOSTZ4XKJcHuvsh0U6naSFNznNexJ0B
	XsS6kkMlr30Z+1G0RbgsqVMQIeyLu5qPOugf4WGXig2fimGaGVu3MyhUY/YuRmsgFvLU=;
Message-ID: <7bbd581f-bfa4-444e-9c76-bcb833a2ec74@xen.org>
Date: Mon, 15 Sep 2025 20:14:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Michal Orzel ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 12/09/2025 18:00, Ayan Kumar Halder wrote:
> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
> Test that Xen is able to generate SGIs.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---
> One of the aim of functional safety is to test hw/sw interface. This means that
> Xen is able to configure the hardware correctly for the desired functionalities.
> 
> Normally this is tested from the VMs. For eg if a VM is able to receive irq, this
> implies that Xen has configured the GICv3 interface 'correctly'. However this is
> a high level (or integration) test which uses not only the GICv3 interface
> between Xen and VM, but the interrupt injection code for Xen to VMs.
> 
> We want to have some kind of unit tests to check that Xen is able to receive
> various interrupts, set priorities, etc. Here, we have written unit tests for
> software generated interrupts (SGIs) as example.
> 
> These tests are expected to be triggered as Xen boots (right after Xen has
> initialised the GICv3 interface ie gicv3_init(). The aim of this test is to
> check whether Xen can trigger SGIs after gicv3_init() is invoked. If so, we can
> claim that gicv3_init() was done properly to be able to trigger SGIs. 

To clarify, this only guarantees that the boot CPU can send SGIs to 
self. Secondary CPUs are brought up later and will need their own setup 
to enable SGIs.

> Likewise
> we will have tests to check for priorities, SPIs, etc.
> 
> A script will parse the logs and claim that Xen is able to trigger SGIs.
> 
>   xen/arch/arm/Kconfig  |  8 ++++++++
>   xen/arch/arm/gic-v3.c |  7 +++++++
>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>   3 files changed, 36 insertions(+)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 950e4452c1..739f99eaa9 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -73,6 +73,14 @@ config GICV3
>   	  Driver for the ARM Generic Interrupt Controller v3.
>   	  If unsure, use the default setting.
>   
> +config GICV3_SELFTEST
> +    bool "GICv3 driver self test"
> +    default n
> +    depends on GICV3
> +    ---help---
> +
> +      Self tests to validate GICV3 driver.
> +
>   config HAS_ITS
>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>           depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 4e6c98bada..eb0c05231c 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>   
>       gicv3_hyp_init();
>   
> +#ifdef CONFIG_GICV3_SELFTEST
> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
> +    send_SGI_self(GIC_SGI_DUMP_STATE);
> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
> +    send_SGI_self(GIC_SGI_MAX);
> +#endif

Looking a the code below, it seems like Xen will not be functional after 
running the selftests? Is this intended? If so, we need to stop Xen as 
soon as possible.

Also, looking at start_xen(), we call local_irq_enable() a little after 
gicv3_init() is called. So I am a little bit surprised this is working?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Sep 15 22:42:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 22:42:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124452.1466790 (Exim 4.92)
	(envelope-from )
	id 1uyHuC-0005rB-LN; Mon, 15 Sep 2025 22:42:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124452.1466790; Mon, 15 Sep 2025 22:42: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 1uyHuC-0005r4-Hz; Mon, 15 Sep 2025 22:42:40 +0000
Received: by outflank-mailman (input) for mailman id 1124452;
 Mon, 15 Sep 2025 22:42: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 1uyHuB-0005qy-9r
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 22:42:39 +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 451bb509-9285-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 00:42:36 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id
 58FMgVw6018413; Mon, 15 Sep 2025 15:42:31 -0700
Received: from XCH16-05-04.nos.boeing.com (xch16-05-04.nos.boeing.com
 [137.137.111.25])
 by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with
 ESMTPS id 58FMgSR6018389
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Mon, 15 Sep 2025 15:42:28 -0700
Received: from XCH16-05-01.nos.boeing.com (137.137.111.22) by
 XCH16-05-04.nos.boeing.com (137.137.111.25) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2507.58; Mon, 15 Sep 2025 15:42:27 -0700
Received: from XCH19-EDGE-Q01.nos.boeing.com (130.76.23.13) by
 XCH16-05-01.nos.boeing.com (137.137.111.22) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2507.58 via Frontend Transport; Mon, 15 Sep 2025 15:42:27 -0700
Received: from USG02-CY1-obe.outbound.protection.office365.us (23.103.199.179)
 by boeing.com (130.76.23.13) with Microsoft SMTP Server
 (version=TLS1_2, 
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.36; Mon, 15 Sep
 2025 15:42:14 -0700
Received: from BN0P110MB2067.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:19c::7)
 by PH1P110MB1131.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:177::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.21; Mon, 15 Sep
 2025 22:42:13 +0000
Received: from BN0P110MB2067.NAMP110.PROD.OUTLOOK.COM
 ([fe80::34e0:4442:7be9:6519]) by BN0P110MB2067.NAMP110.PROD.OUTLOOK.COM
 ([fe80::34e0:4442:7be9:6519%7]) with mapi id 15.20.9115.020; Mon, 15 Sep 2025
 22:42: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: 451bb509-9285-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com;
	s=boeing-s1912; t=1757976152;
	bh=tIRoOIbJ52kYhtN19KU7Tov6Yt6nzIwL/SSo+i8lIeI=;
	h=From:To:CC:Subject:Date:References:In-Reply-To:From;
	b=Tv49FfgQtK+25fXjys4lDoXowvqG7Cy7jHa4GGJoK2GjBvJH7hUITR/h8i8BWcwdl
	 HHvCkCUkN3FEH4ZMmgjg/hoOsxQy3qRLN2PYJugmE3+FGK2cUIUUXfzHcZSExtguaI
	 kSiEUDJDyCNtP5XLM06rIdwbyT5eaGFH/ECAcFZhfvoR18+aDkEDm039sGL/dD9u+j
	 dzR1efkHup1lZDo3YJgTvCvwHo2dBLBF9GbcnscGBQcgu8TRAI77XE/+PiL+R70M/0
	 9fgzTTM+tjZknaJR5KTuIYvVX5d0oO0wJX5eeA2pGpq3F+/ykadZdNM0//hg4A8x2+
	 Qvg31u+UXGEYg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none;
 b=swDYddfAj0zC/YJ111gz1Cc+g2CvDmPDp5CIkjUpmZFn1351vadztF8fe2eNGn2kV4p6R4J0KSjmDOLIVK3c34p7hkXXpOwIbsj1K+FRgesIj5m2dJwntNvc9PifGmKR+fNoZD4+W8kLPnjHIdTd6vCB7fxyfLmFYYh87YZm7hC60xb6b+GLWKbr9RvYBakfCo4fT7uVzpxVuNv2qMKEeW9Np4yE+5oOqOvN7qm8RFtDOYhajCWX3cXwseSkhYu2GfqT7KWrOvWlX+4raFfmnKIDJJPB3WfDlN0YYpN76gVWKNBORWDa1rGlXLKAaAtniSXzVTo8t6yideNwvf6vUw==
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=tIRoOIbJ52kYhtN19KU7Tov6Yt6nzIwL/SSo+i8lIeI=;
 b=dI/XREeDnlnKXqRcRkswxtVYGfGA7tgnzzTaRylQ8XHS0c86VKxhYbA4s8xhnG+niPF1Z7rnBP2OiJbKFWiKmnjy402HpLuj51TpHLkeP8ssYlCiUVdfj4B4axwRZLOtPtakNh6GG7B0iWojh2KrqEv+RwLHeDFrCagiFS8EzGq2BrbHqvxxwNJP0spAb99y3PM6d4aTScD/a6NDv7F4MJPwgZfhImqXQjAxEZ8k1DdCCHrPQDv0mnmZZmu1kj4johGPDoc1xCate6svYwbbyRELuLoPmLrIOQsgbGWJYexDwMWnKbZHWPgR8C1pA30hRTBrPshM9iit/4v/5Vm+jA==
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=tIRoOIbJ52kYhtN19KU7Tov6Yt6nzIwL/SSo+i8lIeI=;
 b=Tgn2DaQuwVaw+RbdzUVqeIXuI177xgLAz+ItO9Z7ie/dWFx+BymdfkLqfRQg9dHKzeZTKGLl31ELf6C78+fXLHhn/5byW8Q0JToqYptpikLvCk36BgmRtvrFJpkK1lkzolW6+uJL4RduWcOlue9LOtU+he+98bA9sKilHeUwWco=
From: "Weber (US), Matthew L" 
To: Saman Dehghan ,
        "xen-devel@lists.xenproject.org"
	
CC: Jan Beulich 
Subject: RE: [EXTERNAL] [llvm coverage] Update LLVM profile raw format from v4
 to v10
Thread-Topic: [EXTERNAL] [llvm coverage] Update LLVM profile raw format from
 v4 to v10
Thread-Index: AQHcJmG2oeeyHeOUtEKLs5eugkA/BLSUy2Pg
Date: Mon, 15 Sep 2025 22:42:13 +0000
Message-ID: 
References: <12f2f3bd9010422004c38c23f6758c87df8682a5.1757951300.git.samaan.dehghan@gmail.com>
In-Reply-To: <12f2f3bd9010422004c38c23f6758c87df8682a5.1757951300.git.samaan.dehghan@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=boeing.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB2067:EE_|PH1P110MB1131:EE_
x-ms-office365-filtering-correlation-id: 467b71f5-5d8e-445c-14fd-08ddf4a91d8d
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|38070700021;
x-microsoft-antispam-message-info: =?us-ascii?Q?NIs0yLZU9jMCIuZaH17b6TR1S9sLGVttFYLaAvNdfB2Jda/XeUfolFxjUq4n?=
 =?us-ascii?Q?P5WzGNPexxrWsvCjFlV/nqIpLDxPVhIi73E8vprw9gwR9nwq5DPpKcCoOcHK?=
 =?us-ascii?Q?HWej75uV7kSuzLUjctt8VeaEPZ3BXCPkfVmztTKc7lvlfLnrrsluZqbBtiUE?=
 =?us-ascii?Q?lavIx2xLCU+8cp4NB9+nImzEMtn9OCIrxC1N+vVzVWKoNJgSq8sY908Lylpu?=
 =?us-ascii?Q?DK252OsspN9DFsNAWknPVNVh/u4RPxoaa9Lm0Zq41uPt2idhQ9xPXdnekCCA?=
 =?us-ascii?Q?Oilm8iRNYHRRO/OC+Ra3/tehzKJhST+FLSFVT5ysXe7qT7C5r1G2T0YssdvF?=
 =?us-ascii?Q?DFSu2utugCLyqVLRYlfJCa3kepqX4BQJx/PzjQjtgNeTzuPogsY7ESY42eH4?=
 =?us-ascii?Q?BjNDlYbPRIihlPXQNxgGWO7tNwfQpkVxwD/2Hk1savglc4ZwkKqLUOKwLn1j?=
 =?us-ascii?Q?+gHwxI+eQuiAc4K/1wnC1JbaudVCzjkWnE2z75v5F5yvI+1VH6S1WEWSu88v?=
 =?us-ascii?Q?ht3Lt+8OK+NVik0yE+n5F+ow7VQw+bwuibcz8Tza24OXR56HGazvJeMEWpN+?=
 =?us-ascii?Q?aQPE+TYTzWAPuIrp6VLjZGtr63Gj6Up5qSD0gsTcJzk4hvYZnHbq3NFtnp3a?=
 =?us-ascii?Q?AGzNy9Ifg59WC86BHiTavo3q/W4VbxNbnUqsJXsYwxePYyQwOr27D0/sJ8lZ?=
 =?us-ascii?Q?jeUjKIub4Jrz40oJnd9WUMpms6Ana2VvQ68+OkLpE7KvkkdzMrMtg7Ey2RpU?=
 =?us-ascii?Q?gRtGmc8tzB0iyc9J+ArYYs+bU8i02UqGFy2wSF7taH0FgmanKG7Kk/SDuZR0?=
 =?us-ascii?Q?SfLwzFADED8QkcA+fqoDE8YgCXx8NvB/Pbf4UEdpxG1TM6s2gq/klHU8JKk+?=
 =?us-ascii?Q?UDA/LdX58zRfKZ7DDkYllmoaP3NpQIIg8IzCLYIDdMhnoP0fvPygyeDMz7hb?=
 =?us-ascii?Q?628lGUWEoDfQx5/4WQ9dmo4QhhADH0bEYPeVHTrlrKlaZmKq0E2MVLcbsNq8?=
 =?us-ascii?Q?UoUw7KzQDYGKxkQAvKYasucANwVi/s2hJFS6XWQl/bW/UtxDcHrFaLUaCl8C?=
 =?us-ascii?Q?/EBejmTovUfaCNoxeTiJlKK9FyrxS/U22LFy1Ow0fbhMgM3yZdY+SGGCYeEo?=
 =?us-ascii?Q?VfBV9cHjjLk353fxwCIsp8y64WSGsl0cOdONE83zNNY8IbKwW5vQh2tDu36j?=
 =?us-ascii?Q?2waja0+cR4mL/9JX5X7q+oONBKV2WSVIu/mfC2/OcNuyORyMMHBTH9KMiLHJ?=
 =?us-ascii?Q?y8jwmTJGCeLJOhrhvO4Qm8rXnoMrPN6P7tTwjG6llxJes1Zv6QKiBIHQZHHO?=
 =?us-ascii?Q?9VgaPjyq6w1ONVwfr3Cw9w/ThzjzWHD/+2Wm/FHQt2wcxGM5wILj2Q6Eu6v/?=
 =?us-ascii?Q?i49RQo0uwlRZtJcvZ4HlhixLZmFCghh0fRAGap43xc0JQUYWNYG+k5LBoB8A?=
 =?us-ascii?Q?EfPo/cR9so1wUfvjQNx4znyPIp82CezzGQbfbuYIyZ2UsfJ78oXecbiY5gEJ?=
 =?us-ascii?Q?hHcxjezYl0lqFsw=3D?=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN0P110MB2067.NAMP110.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?X0eYIvB+j/HMIA8szWK9TRDFOlebmyr87DHCxibk1UjkvErdwwS8OFDlMDrK?=
 =?us-ascii?Q?w7eaOnIGhkHLu0mMA/sz8EL7YdxdHWYkHQ/XQrbml3GdX/pV7pk+aG/IP7Hv?=
 =?us-ascii?Q?w0Y3UhQjJUtfMdSN67vZ4v8GIgzE48pbfwMZKuJJhAN/4XVUp9UCUkEU46Ry?=
 =?us-ascii?Q?rN8CL8npkuRsh1dP0Ts1q7rHfzmjhjZxDDyzS3hb4zDFT8o225445nX/DPxb?=
 =?us-ascii?Q?kJY25AuBq0ku/Kq8yiGnVenYiC2U5IDW5JUxBFrvVhkrzkumrOOZ3MAoWqY4?=
 =?us-ascii?Q?DAWl8GthgeDl9A2didktHp4kccR7zKRG1lLIIgNtqrTf5cMHszI9ftTwR8CM?=
 =?us-ascii?Q?ViBxJ1Z7W1juhtHgqz+7XivzQ9oOKf2PN/kpAcmABEKVvtf8U2AB8mXLmzlm?=
 =?us-ascii?Q?SxSHvumzedOJBvlWHwV14q59Pam1feXrgFOlX+n0orN7A9rDZ50pshSyYScU?=
 =?us-ascii?Q?kMOTPrEdgg/HkMUOAVBrASpvFPo3y9CuTvr2lteQ/k1GpA8zpXtC6mRwydmX?=
 =?us-ascii?Q?Bl4Dipk2GF8jQD9RoSnNq0E2d35wj4ia2xiHRfD07/EVjo89hnesk0S2SMGm?=
 =?us-ascii?Q?UKO42t8Q9pQJ5OOtOCtVQ4d73qbqD13S3R1MaTI9tIH6PoDW0oD3aNGZYHBr?=
 =?us-ascii?Q?PKRjeGwuBFywAQoeVNV+L/ufsfC6TSA53pn/BNAcvP5NKQDMY+BGeG5mQQ2P?=
 =?us-ascii?Q?skO3gxQQQYJiWekTZn7WQJ0VzpfrBQClAiJYWldc8KqL6Jvb+lPIgy0qixZ5?=
 =?us-ascii?Q?LZ2VrvGhJdmDBB3cd9SUDSrIBjmr7c99WVR5dDzlAMFgK3j8brqdNXjn2F5Y?=
 =?us-ascii?Q?gdQrdKPFewavvbQ0r+glHRnZYNDM4cO8zBYQgAA9vHZI9mqmtcOJLXSNFLTi?=
 =?us-ascii?Q?pfx6RCK/ckDRA6o/g76fMgZC0VrwAEtVuaTjefDV+nOMsQqnB9QwOuej6btd?=
 =?us-ascii?Q?FOvu9jq1MoA8HC4uDGiQhR/3Fou8uP2X99OA/OSIlx4AaUm3NWHwiPbFxPAE?=
 =?us-ascii?Q?DVlvuOW6Ll6MKYc6flZNf6kU+kgEBmVno1GpMmyBRNyfbC2iVNgyfVzjdRP7?=
 =?us-ascii?Q?UA31TK1D+YpG8TvNquO6JgjDgqztmtUs2OGmFcVvzknr+IIdzl1ACcfXiQ2X?=
 =?us-ascii?Q?Q6wDs3MEM4PC54BKhqVG1H644/IkLVKRCTr13FRd1uIEi6nijlzFXRp4TUU4?=
 =?us-ascii?Q?pQSLYaVcCEvn2dLJ/rcjCqEr+9xSAFTnBRZt/hMvx7v+b9nHrv0IPR/9a6rO?=
 =?us-ascii?Q?TmM6n2JpQYegKvQgCEUJ0/V1eT9eDBghCVxXXWVQf6xsP7/a3m7WaFQ2SLNq?=
 =?us-ascii?Q?ygPu35LLPCequdRkfaaN9ZaeR/D2rtqmqcqzaVOz6fiq8pwRndBm3O4oyiGV?=
 =?us-ascii?Q?KFJq3roqOTH28pFZmfUt2ryt8jtEOGgzpnqI6bNycOipzgMtHTqEhiD6Rfcd?=
 =?us-ascii?Q?lJo1TPZYjB9rH4xbQRQvKoUGk/E87Sj+Jdv82L9RjYSh+3TMSt3hYByQNKg+?=
 =?us-ascii?Q?t6YdFkAj53mYOcB2sAGuiAHbWYEq7Z4GK7Kv?=
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: BN0P110MB2067.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 467b71f5-5d8e-445c-14fd-08ddf4a91d8d
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2025 22:42:13.8546
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bcf48bba-4d6f-4dee-a0d2-7df59cc36629
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH1P110MB1131
X-OriginatorOrg: boeing.com
X-TM-AS-GCONF: 00

Saman,

> -----Original Message-----
> From: Xen-devel  On Behalf Of Sam=
an Dehghan
> Sent: Monday, September 15, 2025 9:56 AM
> To: xen-devel@lists.xenproject.org
> Cc: Saman Dehghan ; Jan Beulich 
> Subject: [EXTERNAL] [llvm coverage] Update LLVM profile raw format from v=
4 to v10
>=20
> EXT email: be mindful of links/attachments.
>=20
>=20
>=20
> This patch updates the LLVM profile raw format in `xen/common/coverage/ll=
vm.c` from version 4 to version 10, enabling compatibility with LLVM versio=
ns 19 and 20.
> While the patch supports only one version:
> 1. It seems better to support one version than no version --
>    the current profile version 4 is not compatible with
>    LLVM version 11 or later

I'd suggest adding logic to check the LLVM version and conditionally add th=
e struct field(s).  e.g., "__clang__", "__clang_major__" and "__clang_minor=
__".

[snip]

>=20
> Overall, this change would enhance Xen's code coverage analysis capabilit=
ies by leveraging the latest LLVM toolchain improvements, particularly for =
safety-critical hypervisor code.
>=20
> The patch modifies only `xen/common/coverage/llvm.c`, maintaining API com=
patibility while enabling modern toolchain support.
> Testing was performed with LLVM 19 and 20 to confirm functionality.

Please elaborate on your testing.  You could put it under the --- so it's s=
how what you did but not included in the git description when merged.
E.g. what dom0 was used, command sequence, etc.


[snip]

>  struct llvm_profile_header {
>      uint64_t magic;
>      uint64_t version;
> -    uint64_t data_size;
> -    uint64_t counters_size;
> +    uint64_t binary_ids_size;
> +    uint64_t num_data;
> +    uint64_t padding_bytes_before_counters;
> +    uint64_t num_counters;
> +    uint64_t padding_bytes_after_counters;
> +    uint64_t num_bitmap_bytes;   =20

The above line has extra spaces at the end.

> +    uint64_t padding_bytes_after_bitmap_bytes;
>      uint64_t names_size;
>      uint64_t counters_delta;
> +    uint64_t bitmap_delta;
>      uint64_t names_delta;
> +    uint64_t num_vtables;
> +    uint64_t vnames_size;
>      uint64_t value_kind_last;
> };
>

Steps I used to build
- I checked out latest master (656b9ca03b)=20
- Applied this patch
- menuconfig'd to disable livepatch and enable coverage
- make dist-xen clang=3Dy

I got the following.

  CC      common/coverage/llvm.o
common/coverage/llvm.c:120:10: error: field designator 'data_size' does not=
 refer to any field in type 'struct llvm_profile_header'
        .data_size =3D (END_DATA - START_DATA) / sizeof(struct llvm_profile=
_data),
         ^
common/coverage/llvm.c:121:10: error: field designator 'counters_size' does=
 not refer to any field in type 'struct llvm_profile_header'
        .counters_size =3D (END_COUNTERS - START_COUNTERS) / sizeof(uint64_=
t),
         ^

Best Regards,
Matt


From xen-devel-bounces@lists.xenproject.org Mon Sep 15 22:57:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Sep 2025 22:57:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124467.1466800 (Exim 4.92)
	(envelope-from )
	id 1uyI8f-0007lr-0t; Mon, 15 Sep 2025 22:57:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124467.1466800; Mon, 15 Sep 2025 22:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyI8e-0007lk-Tj; Mon, 15 Sep 2025 22:57:36 +0000
Received: by outflank-mailman (input) for mailman id 1124467;
 Mon, 15 Sep 2025 22:57:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uyI8d-0007ld-HP
 for xen-devel@lists.xenproject.org; Mon, 15 Sep 2025 22:57:35 +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 5da38ac8-9287-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 00:57:34 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-45f2b062b86so12974735e9.1
 for ; Mon, 15 Sep 2025 15:57:34 -0700 (PDT)
Received: from smtpclient.apple (public-gprs232241.centertel.pl.
 [31.60.54.114]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45e037186e5sm196923275e9.5.2025.09.15.15.57.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 15 Sep 2025 15:57: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: 5da38ac8-9287-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757977053; x=1758581853; 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=mnYhUQzKzPFnbfPJig1Dv6FPRHTgQ6d8LY4Eo419aR8=;
        b=g1BxkWklR4I4FXn4KUecmVzocgkZssdRQmOiCgMptEP0227t+izRFJCXu5KVYaAUVq
         6gO9ilLoyKT3pkI+PNJdsGxhkYn6qnB4Oq8u+0JAgKnO0SG8QRzVCWoViN3Z0nyka1a1
         V9G67uZcMfPHpvfIbAdgwKCUHGb1srK/MW3aySU1TOimf5FthWL0QcOkFb3REWmtISsu
         HPXZkNB2PzGlNE3DGi78sjoIX043LFBf6yeth3iJlbXljsXiFgkM9P+3BAgMoWQHuhL8
         P8Ud9W4YYkPIFQWQH4YV2S5xuTQgNizO2CJxICwRIxti4VhSbtzzvqPvZuFglIKKLLcy
         Ekaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757977053; x=1758581853;
        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=mnYhUQzKzPFnbfPJig1Dv6FPRHTgQ6d8LY4Eo419aR8=;
        b=k5sdjn5+LK9bxVG1laWrdrY5ir/p+Jc2q2xheHkSnustDOVZNX6iP1fkWK0h/TXuCA
         lSuGzMdOwRyTNZHbjed2RUuquk8Vyxzj70Upahj1KT559pNoDDGxowRPpngf+1SKhRuT
         4mJ33JrPNyMNgqBHAXCEitHsz1ia4G8dgEUfiqqnQnwhpdVZNZ+/Ygjk68l77+7+xgd9
         2SqvR49bCeucxb9PDk0iZXh0dMMTL0bUj7IR3Exy96Dnnq8lToz3TtC/YZteiIzy8r8Z
         XyAopatPJtZTcZfEaWWfqaeb/9ktJrTIgV8QC9VvGqwfZw+Ms2A6iPAAHDmCDH/0Ynu/
         54WA==
X-Forwarded-Encrypted: i=1; AJvYcCXoJgtH1BPqDBQoOToWJKGoZk0gWvwf1wGtkO2TKvTl/vDcrpQHtdXVHOuiwiH2dMcphY04UFYOMn8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywo3v2d3wXLgDIY2P/fpvwmFuzDvJWnjdmUei/MLKlw6XycGSES
	KX+nXYmsw0S8D0dCX+iY8Q219PjaWynU/uKcP08HPi9XpLLpk1XIqkXO
X-Gm-Gg: ASbGncsmDpsm51Esibqx06ZYsihMi5GGqG1gLIBi6vn6bqgFblXIaVLiUxn1uLWeb5n
	4Kb7+/vVV9Y8BIIIoo+0ywTc8N+EU07fNqb/lKKpunCvfP7fVAkSFbE9WAz+IHHrihp3u0gjV5g
	Lk7sXHxrdTO2+/IF0G9ZLD4ULb2Shd5DbfNgaQdXn9tqxEd818RV5IikB47X+RqffnEMy9UxAbx
	fWClH3wJO4C6WEfiskr1OolpZMMSnSqv/vigoh6OeO52zXCgP8IcFllpxP/Tju5FMAitNM44Dr6
	gf1Ih9kIuqOuEUVL1b/M6vd69Rn18SbiCILqfn69654yA4JnjQZNGHEFUg6ooRVTJu0Q84X99+p
	mk4yzetui29WL3qojfJL0LmUbW6HroZ89nkZ3kpBAwVP/cVj5ePmAP+Pi8+YT8xrgxRFpFhZD+D
	lJIA==
X-Google-Smtp-Source: AGHT+IHe21Bb6U/hH+aoudD0UnxR50zXP8AXLSlZ2b+vP9vkVNg8jFmKP+8aOgNvxs+gXBVp3sMe1A==
X-Received: by 2002:a05:600c:1c98:b0:45f:2cf9:c229 with SMTP id 5b1f17b1804b1-45f2cf9c54bmr49262505e9.0.1757977053078;
        Mon, 15 Sep 2025 15:57:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Oleksii Kurochko 
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v3] releases: use newer compression methods for tarballs
Date: Mon, 15 Sep 2025 15:57:19 -0700
Message-Id: <63F3548C-5DD5-4A0E-B7BA-C480ABF60CB4@gmail.com>
References: 
Cc: Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel ,
 =?utf-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org, Andrew Cooper ,
 Julien Grall 
In-Reply-To: 
To: Jan Beulich 
X-Mailer: iPhone Mail (22G100)



> On 14 Sep 2025, at 10:57, Jan Beulich  wrote:
>=20
> =EF=BB=BFOn 14.09.2025 18:59, Oleksii Kurochko wrote:
>>=20
>>> On 9/14/25 3:43 PM, Jan Beulich wrote:
>>> On 12.09.2025 23:23, Julien Grall wrote:
>>>> On 11/09/2025 09:14, Jan Beulich wrote:
>>>>> Other projects have long switched to xz and/or lzip.
>>>>>=20
>>>>> Tidy things some as well: With the removal of qemu from the tarball,
>>>>> intermediately extracting the tarball again has become wasteful. Drop
>>>>> that. Invoke compressors using asynchronous lists, to reduce overall
>>>>> latency. Drop the -v option from the (previously implicit) gzip
>>>>> invocation.
>>>>>=20
>>>>> Signed-off-by: Jan Beulich
>>>> I have tested manually the steps and the correct tarballs have been
>>>> produced. I will update my scripts to copy & sign all the tarballs once=

>>>> this is merged.
>>>>=20
>>>> Acked-by: Julien Grall
>>>> Tested-by: Julien Grall
>>> Thanks.
>>>=20
>>>> Is this intended for Xen 4.21?
>>=20
>> IMO, it would be nice to have that in Xen 4.21.
>=20
> May I translate this to a release-ack then?
Yes.

Release-Acked-by: Oleksii Kurochko 

~ Oleksii

>=20
>>> So far it was, but I'm increasingly unsure, seeing that it still hasn't
>>> gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
>>> rm use, but hasn't come back as to his argument towards the uncompressed=

>>> tarball previously not having been removed (when I can't see that one
>>> would have been created in the first place), hence why I couldn't make
>>> use of his (conditional) R-b.
>>=20
>> There is not too much sense in the uncompressed tarball. I prefer to not
>> generate it at all.
>=20
> Generating is helpful, to do it only once (instead of once per compressed
> tarball).
>=20
>> Also I have regarding .gz. If other projects switched to xz and/or
>> lzip (as it is mentioned in the commit message) what is the purpose of
>> having .gz tarball then?
>=20
> At the very least to help people presently assuming they'll find a .gz.
>=20
> Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 01:53:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 01:53:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124487.1466810 (Exim 4.92)
	(envelope-from )
	id 1uyKsI-00068x-H3; Tue, 16 Sep 2025 01:52:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124487.1466810; Tue, 16 Sep 2025 01: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 1uyKsI-00068e-BN; Tue, 16 Sep 2025 01:52:54 +0000
Received: by outflank-mailman (input) for mailman id 1124487;
 Tue, 16 Sep 2025 01:52:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uyKsH-00068W-Mh
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 01:52: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 da6be9c3-929f-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 03:52:51 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ebe8dc13a3so697729f8f.3
 for ; Mon, 15 Sep 2025 18:52:51 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-32ea41d3e19sm236103a91.11.2025.09.15.18.52.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 15 Sep 2025 18: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: da6be9c3-929f-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757987571; x=1758592371; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:cc:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=bTA5cgKGgBiuphRp7mP3u6Gnvre7ZlNtP4IpL5fN19o=;
        b=G9+kdw5sCs1zW3PurEyggg21GPWXsYBODak1zipNH0TlJmjlTXmyJ7RpPb7GK0ZjPw
         aIAgB8pCkqJ1Ft9/JM8nmpNM9H/vGOdT3yg1eSiKVCBN29rf0NETBw5BuC4250ZUXAAZ
         c8VPB1R6SbjA/ZHT5BndrjopDWPb+WerdMOJ3M9FuMVT1nfu4wq10oBHk7AzMHh2rC8E
         RTQLIYoJcTFj9+CN+awprQ6VphzQjrjEda0+8OZyM8enIQobScJkCH/jkdsZN8JHJ6Yl
         ubHBnB2OTcnIcP707++KAK4If83/9z36an79Mb05kuymPXm5rZWX2GNTLQIAHN3lxC20
         izaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757987571; x=1758592371;
        h=content-transfer-encoding:in-reply-to: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=bTA5cgKGgBiuphRp7mP3u6Gnvre7ZlNtP4IpL5fN19o=;
        b=lI5f2wU7bi4Q2UgcxiDACOhmGVA3LdtzpwrWq3yuh+xEr77Xc+FZf9totnWpEApckS
         PmoYhFB1NRaQSpX+fok3wCTsJTAhJfQQKlk1Fxf0yqEIW4N2UsCNVGP8BeKycgZ2UJHo
         1c5bE3BhxVusBlieFA8B4Ny2rhAOg0Pi8qe9JQqv2vZflgZhxVPFWwbIGPA3bh8ys3gP
         c1cz4UsrZAako3kv4ba5RBpBtPKfg8PczASZwkX5h3SrCOHwW57QjnU0I7jYvHprpmNt
         nAtKL3TBpaloU5qYLblluwWFUQeNKvNH58C5g2xhps+PqpGHdAHOLHHN+g5/YkMaLyKV
         Kexw==
X-Gm-Message-State: AOJu0Yxs/vSqT/XwJHt5+a5FH8ZmazQurosD2iiYwFHnul/l5RPjKwfH
	e6BqiUnSexORlc6obhx3VwwJDmwGJ+IFslaskgCTkrB2u8bgl2ZHjeOzhNlrhNUn8g==
X-Gm-Gg: ASbGnctZZbJgZHwZQkGYLh89XafYOfchNYyI6M8t8d/3D0t5JOihJJuxlxdMi3eBvjT
	oAPzz3gJYGVfNAS+QeTU6PPkQp+XXDyThC9rDy95V3LLAQBQNMzNZPluKnFD7JP+6l1dBEI3GC8
	FsYbkOfqOWW+oc/2Hs2sHbCvBjC+714odqK1LrqDPevhgvc5DBgU+2PE2f1rGV0Ka/e0jJdJFVr
	CfGVnyK9qhBAG7xghpe0RhSmKD6TceNyt+NapX0d94G9ceO+GQH0//7x9I5HFVBiSpK+sYK4N09
	yLsugkvs2n7l/zNSs0aXI7nMlqpd6p/Me6jC0r+1YMCXMCJifm9poofEwLZxKYYt+r7fEI6xtO9
	mahytkyDLmkoK/7sXAQaNOBagSJuc4Uk=
X-Google-Smtp-Source: AGHT+IEpJkzEeA/kd4GuzYObfhnHnswToz97S95soyEjoJnKdBc5H2XFfzGincPgU8veGYERV79B/Q==
X-Received: by 2002:a5d:4d81:0:b0:3e7:bbaf:6a07 with SMTP id ffacd0b85a97d-3e7bbbeb55cmr8086260f8f.6.1757987570634;
        Mon, 15 Sep 2025 18:52:50 -0700 (PDT)
Message-ID: <7228afa5-6ebc-4fdd-8181-b30c78417767@suse.com>
Date: Tue, 16 Sep 2025 03:52:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [llvm coverage] Update LLVM profile raw format from v4 to v10
To: Saman Dehghan 
References: <12f2f3bd9010422004c38c23f6758c87df8682a5.1757951300.git.samaan.dehghan@gmail.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
In-Reply-To: <12f2f3bd9010422004c38c23f6758c87df8682a5.1757951300.git.samaan.dehghan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.09.2025 18:56, Saman Dehghan wrote:
> This patch updates the LLVM profile raw format in
> `xen/common/coverage/llvm.c` from version 4 to version 10,
> enabling compatibility with LLVM versions 19 and 20.
> While the patch supports only one version:
> 1. It seems better to support one version than no version --
>    the current profile version 4 is not compatible with
>    LLVM version 11 or later

Indeed.

> 2. The patch could be extended to support multiple
>    LLVM profile versions, e.g., from 5 to 10

Would certainly be nice, perhaps as a follow-on.

> The llvm-cov toolchain, with its Source-based Code Coverage,
> offers two substantial advantages over gcov:
>   - More accurate coverage reporting when compiler optimizations
>     are enabled, ensuring better analysis of optimized code.
>   - Better tracking of coverage across inlined function boundaries,
>     critical for complex control flows in Xen.
> 
> Overall, this change would enhance Xen's code coverage analysis
> capabilities by leveraging the latest LLVM toolchain improvements,
> particularly for safety-critical hypervisor code.
> 
> The patch modifies only `xen/common/coverage/llvm.c`,
> maintaining API compatibility while enabling modern toolchain support.
> Testing was performed with LLVM 19 and 20 to confirm functionality.
> 
> ---

What's missing in any event is your Signed-off-by:.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 02:08:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 02:08:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124497.1466819 (Exim 4.92)
	(envelope-from )
	id 1uyL72-0008Gd-Jb; Tue, 16 Sep 2025 02:08:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124497.1466819; Tue, 16 Sep 2025 02: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 1uyL72-0008GW-H0; Tue, 16 Sep 2025 02:08:08 +0000
Received: by outflank-mailman (input) for mailman id 1124497;
 Tue, 16 Sep 2025 02:08: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 1uyL71-0008GQ-Dd
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 02:08:07 +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 fb87a422-92a1-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 04:08:05 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3e9c5faa858so2191172f8f.3
 for ; Mon, 15 Sep 2025 19:08:05 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77607a48c19sm14652415b3a.36.2025.09.15.19.08.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 15 Sep 2025 19: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: fb87a422-92a1-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1757988485; x=1758593285; 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=JPsCIOYK1ovn9kCkK+EjWsBMX09q+U37GNtiL4+vhHI=;
        b=GQ9Ij5IIcrL66gglJ49ymwzkV3yDBg8XKVcNY4M5II6MPlo6rGwMM6VcqSowWBkOlL
         rf6D0ZQP6/9hoAr7Cp+8zmgCNhLZWzZb0P/lJTMCDeBbyX//LnTNc5fNb0Ic6mTwZZm/
         +wX97GpLz+YBdWUv58S5z+xngC4msn2gBUz1TFHo2yjDJg+x+uS+lQkniEX8qklorEOe
         g5KmCEHRXaywqijnPlLAHfEMMiU7zSl+QLZwbi+tVC/7nFA12iDNVjqZM8WPY4sRAL0V
         6/UrXzVIcsd4sD8o6MFT6ZoVuedK0AOVGiQHb7Jq3GZPkvBFWz6CCtTGhhA20Tm3yz2N
         W6SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757988485; x=1758593285;
        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=JPsCIOYK1ovn9kCkK+EjWsBMX09q+U37GNtiL4+vhHI=;
        b=ibCNwxMouksUJ1mqrfudnqiNgW130DsyJ0FEOyV521APcfWqszKXNHafwwM72FyJQS
         SCZZcO28q+iaZVB4g08fGQdLQ7IKOuGKjKIc/LxgnRtkkYCaS/wOBFGcrpNjPJo14oyG
         oum18GNyTCl2lj/TEiQCBnVesQ9V3qkZeC9UjDgNCwFPGTPcxq8vuqzXrFcH7Rk9EFIp
         J7WpT/tpDAEjVfV2yj3g48SI5BCQvzb5w/o2+w3+GnnGWhRzH2NVLk2bMWqy2NCknZMr
         ewjh3Ww6TPqD5tHPT6QgSIGIR+XuGUsY1hfTX2BJh7b0wFR85ouNFux1c37O2kILSxOs
         HySg==
X-Gm-Message-State: AOJu0YyQdCMxyKIGND5ygtOvDF2WO7SMko4x15976Ex3ARsCMPsTyIT9
	prIRhlHsLkpTQvp3SObrkDzY4qPprWPLfYrJHBZh/dXgszyOvWxo5PoEtBPug1GPCnvLQGjwSd4
	ho2o=
X-Gm-Gg: ASbGncujdneb0KcwIWximYhEL+Ei+4w4LjW1eoSfdHfXImMXcPU0a+5lZuBPnf3Rg5H
	H1XoH+JMpCIluc7vMJGNktruNJdvdRYiZeoPygJEv2vOYktxuTsdX/8VHlE7Nszsc/p8SXnDHV1
	b1qHGMQr5Z0g9m5NCutaRHQP+7zVGC2ptfOieHQtmmzjxahQLT5Rb+UUBdGvKt25+zZD/UUyvPv
	MWJepc3TtDWpk3eOQX/mt/aykbx3nrU0K3giZYYt3jATi+fHEqAToyiaCDE4SKc9kBFnQ40LyFM
	yt4gDZVPFquSf27Nv3awEb3SAxphjqkYfseuHqvoCE1w9Umb3sv0iEuhhr7NrpOh9zUdzPjYJVc
	p8WcWcjwVxfJycPLTQcJavIGRaOyg/msrL70auzE9iQ==
X-Google-Smtp-Source: AGHT+IHfIN4wemmccqIycCmIMWgsu/kfqM5TmDn/KFABeca2z5LgaL6gmyVh1i7MkMGxTf2zVCahBQ==
X-Received: by 2002:a05:6000:2410:b0:3e7:5f26:f1d6 with SMTP id ffacd0b85a97d-3e765790821mr14622490f8f.13.1757988485122;
        Mon, 15 Sep 2025 19:08:05 -0700 (PDT)
Message-ID: 
Date: Tue, 16 Sep 2025 04:08:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Request for patch to fix boot loop issue in Xen 4.17.6
To: Ngamia Djabiri Julie 
Cc: "xen-devel@lists.xenproject.org" 
References: 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.09.2025 18:52, Ngamia Djabiri Julie wrote:
> Dear Jan,
> I want to underline that this issue is a critical security problem affecting system availability and that it has direct consequences for XEN users:
> 
>   *
> Systems running Xen 4.17.0 – 4.17.3 will fail to boot when upgraded to 4.17.4 or 4.17.5 under Intel Nested Virtualization.
> 
>   *
> Diagnosing and fixing this requires advanced skills and time, and in some cases may be impossible for standard users, leaving their systems unusable or unmaintained.
> 
>   *
> The problem has been known to Xen maintainers since 2024-01-20, but no official communication has been made.
> 
>   *
> Root cause: commit 6bdb9651 (2024-01-17)
> 
>   *
> Fix: commit dd05d265 (2025-01-21), applied in Xen 4.18.5, 4.19.2, 4.20.0-rc3
> 
>   *
> Xen 4.17 remains security-supported until 2025-12-12, but this fix was not included in 4.17.5

Yes; the fix isn't fixing a security issue, so won't go onto that branch.
You (now) calling it a security issue doesn't make it one. Note how ...

> On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
>> Dear Xen developers,
>>
>> I would like to ask if the following fix can also be included in Xen 4.17.6 (and eventually in the Xen versions after 4.17.6 that don't have the fix) :
>>
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=dd05d265b8abda4cc7206b29cd71b77fb46658bf
>>
>> This bug causes a boot loop in nested virtualization environments (for instance nested environments that use VMware Workstation), making Xen unable to start. It was introduced in version 4.17.3 and the fix has already be included in 4.19(.2) and 4.20(.0) and woud be planned to be included in Xen 4.18.6 in the coming weeks.
>>
>> Even though Xen 4.17 is in security-only support, this is an issue that blocks testing and usage for users and projects such as Alpine Linux.

... there also was no talk of this being a security in your original report.
Quite the opposite, you asked for the fix to be included despite the branch
being in security-only mode.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 08:00:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 08:00:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124528.1466830 (Exim 4.92)
	(envelope-from )
	id 1uyQbz-00075v-9p; Tue, 16 Sep 2025 08:00:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124528.1466830; Tue, 16 Sep 2025 08:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyQbz-00075n-6u; Tue, 16 Sep 2025 08:00:27 +0000
Received: by outflank-mailman (input) for mailman id 1124528;
 Tue, 16 Sep 2025 08:00:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uyQbx-00075f-Kd
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 08:00:25 +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 31677c26-92d3-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 10:00:21 +0200 (CEST)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-570d0c280e4so4936815e87.0
 for ; Tue, 16 Sep 2025 01:00: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: 31677c26-92d3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758009621; x=1758614421; 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=KouwesFlgNsfi6ZAeLHccS36bPkCPn/8z9o1uRe7qGM=;
        b=JchCTBO1VhCxeqiqaO+AaLqATiHwmAq3SY6c3NtD/mk4czXhYp3TtA4BfKk7F2NUzf
         +MEiZmuHPt8L4N3JRW6TVCL5ZExqpksOWSbNEFz/RUjy6ojTyLXIKpxmYFBZvrBpSdhU
         mq67xfLvWXe2HlfzzFOQ8e2ZRTtNbDsGXPdyW5z4GSdEqMWtvdSxS7l4dD5rc7lqWmTy
         ezfVlkVML/VDRHe+Bh6eGLxU08jAJ0tGKKka8IBgXTRGtlY9zH9feHrKUPNN2x0a/yzB
         o5S0L/e1dCXLEfbI/A/ZR3ISvoPa9yACGBGu99odFLoupYwc/ay6ULbWsWMuYyoab9Pw
         ciIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758009621; x=1758614421;
        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=KouwesFlgNsfi6ZAeLHccS36bPkCPn/8z9o1uRe7qGM=;
        b=MFpyXX3VQnsfUGOeejJXx+YBbsaNwn514nqYadQNoHXvGzUzCCe8reiU0vkmMjqCZ1
         pB5956yC4r9bLB2qVqBTRCbB50IExXjrcjhu+/6mUpdUFumZfQ4q4yNA/E3KYV85aN9Z
         4DG5+GkYXUkI8MBbz2fMkXGYEq4diwqYtNzSz3/LOpysr7mx73AhvDfl5IAbMBx6Fk4S
         ZN2JbyuvjvIWZI3HpHU41f3cY6yrT9BtL0S85uMfTmVuU8J3SUoPALACURKlrxGJTSAp
         NwJiNA/5NprOvSqdRvxl77GCFULcw5jsRvqdPj0XJvuA7D8BgsDUv0FokiuqVdNcfCVY
         nY1A==
X-Gm-Message-State: AOJu0Yzih26Me6HTUuYkfRe6qffWgQ/YyEHdS2Kb6urXjHfCRdMJgIYT
	oRXtuGsOZPpsHEaJFZfESj+3SsyeZnoMQ3SaUb34t51H6rWp2b5DIFcT6qEkCPxdifZ0HFX+7yr
	WKUdgrFSoneUyudkWqkv3EOCbPTBAHpw=
X-Gm-Gg: ASbGncuS2Ngsx9/gcI5VlQXvXg5PxDHVoY3AginL7de2Wj+7V+WYuNzhTrDBpGgZr+L
	jLg0H8cCGNpOE7Tt/sGe1Y0s53UshcaugjYanZnMYrNwkvHTRIuq9Qr6F2VEiROofRJ2OkoqT3I
	LDwwG8jVKb/IQSaMzbdaHZ/tUu67t+8pgqSPwSgODBnTn2ZQQCpByzUUzql9idV41LWTFVrhUZt
	E12bQ==
X-Google-Smtp-Source: AGHT+IEJrFZoMW7PmfVoWSINU4I3HTGnlRnflqU8TM/JJ21hH/uIwpZeNizqRloY1Ku3PrMZkcKn2al9cAtez+w3dGA=
X-Received: by 2002:a05:651c:211b:b0:32a:6eea:5c35 with SMTP id
 38308e7fff4ca-3513c8db849mr40085881fa.15.1758009620350; Tue, 16 Sep 2025
 01:00:20 -0700 (PDT)
MIME-Version: 1.0
References: <20250908211149.279143-1-dmukhin@ford.com> <20250908211149.279143-9-dmukhin@ford.com>
  <9d55721e-bd95-4354-b839-f8896eedab24@suse.com>
In-Reply-To: <9d55721e-bd95-4354-b839-f8896eedab24@suse.com>
From: Mykola Kvach 
Date: Tue, 16 Sep 2025 11:00:09 +0300
X-Gm-Features: AS18NWCfWk7FtPLvfHN8_wjN3-wtq_vXU4WVFhLiUY-DdOAnW_zEPy5DbArYNG0
Message-ID: 
Subject: Re: [PATCH v7 08/16] emul/ns16x50: implement MCR/MSR registers
To: Jan Beulich 
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, 
	dmukhin@xen.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Mon, Sep 15, 2025 at 5:49=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 15.09.2025 08:00, Mykola Kvach wrote:
> > On Tue, Sep 9, 2025 at 12:12=E2=80=AFAM  wrote:
> >> --- a/xen/common/emul/vuart/ns16x50.c
> >> +++ b/xen/common/emul/vuart/ns16x50.c
> >> @@ -107,7 +107,7 @@ static bool cf_check ns16x50_iir_check_thr(const s=
truct vuart_ns16x50 *vdev)
> >>
> >>  static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50=
 *vdev)
> >>  {
> >> -    return false;
> >> +    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
> >>  }
> >>
> >>  /*
> >> @@ -232,12 +232,63 @@ static int ns16x50_io_write8(
> >>              regs[UART_LCR] =3D val;
> >>              break;
> >>
> >> +        case UART_MCR: {
> >
> > Probably the opening brace should be moved to the next line.
> > See CODING_STYLE:
> >
> > Braces ('{' and '}') are usually placed on a line of their own, except
> > for:
> >
> > - the do/while loop
> > - the opening brace in definitions of enum, struct, and union
> > - the opening brace in initializers
> > - compound literals
>

Thanks for clarifying.

> strictly by the wording of the doc you're right, yet if you go look then
> you'll see that we really permit both forms (and apparently prefer the
> one used here).

I just want to make sure I understand the expectation correctly.
The CODING_STYLE document has wording about brace placement, but as
you noted, the actual code in this subsystem uses both styles, and the
one used here seems to be preferred in practice.

To get a better sense, I did a quick search in the repository. The
pattern with the brace on the next line after case appears roughly
340 times, while the variant with the brace on the same line as case
appears about 75 times. So overall the first form seems to be much
more common.

That makes me think the choice here is more a matter of maintainer
preference than a global convention. My main concern is consistency:
if in one place both forms are accepted, but in another case reviewers
point back to the document and ask for strict compliance, it could
create confusion for contributors.

I'm fine if Denis leaves it as is. I just wanted to note the
misalignment with the CODING_STYLE doc.

>
> Jan

Best regard,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 08:22:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 08:22:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124542.1466839 (Exim 4.92)
	(envelope-from )
	id 1uyQxa-0001aa-0o; Tue, 16 Sep 2025 08:22:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124542.1466839; Tue, 16 Sep 2025 08: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 1uyQxZ-0001aT-UV; Tue, 16 Sep 2025 08:22:45 +0000
Received: by outflank-mailman (input) for mailman id 1124542;
 Tue, 16 Sep 2025 08: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 1uyQxX-0001Zv-TM
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 08:22:43 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4d218b12-92d6-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 10:22:36 +0200 (CEST)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-56088927dcbso6530495e87.3
 for ; Tue, 16 Sep 2025 01:22: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: 4d218b12-92d6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758010956; x=1758615756; 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=imugdng3S5FK+Hm/ZoItPyp1ChMcqMTz5qfgj1SIRFw=;
        b=ZLWqxM5o1yBuI6KvSXnbp1gAT8rf4KZV6Wfhntw8Zd2nkhWJbC7mTAkEfD6aWxEMnJ
         pi8XCC6IjVJ3zndgZVdfKDF/+1ehKT5CkQ2fBPfh8WXEJjF4ZDkAGDXikbv4qFRFagce
         FVD1uS7Nu9eQbKh5jvYjIg8/kDEj8qsOnVhdAMwfnbAV+6R8ugLjTlUvU2VsPD4QDc1t
         0GUSyYoj+hkO+h3eSoftYsylSOx29yvceXIYJF4ksKvyc9QBJRq8iLX4Blx5tZM+GKZn
         bQZ6NWgNEBrRLTFhCW/LNDLaz1k2E7jMFj7hf3eq0uzl4bbm5OvRnbIJTqDx7o7HPx3D
         x9tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758010956; x=1758615756;
        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=imugdng3S5FK+Hm/ZoItPyp1ChMcqMTz5qfgj1SIRFw=;
        b=VUvXCltn0RCVS1dyrpMq4YtNTqZ5pvf2lLQuYb3eTWz3GnEvRU5LLjiz71XRBBBRnd
         IaooE/ZxFX7WwI+WKO0gMvysHikntoWU26Zryqvi7p1ygUATPe6vAsx9sdZCm6WJ46ED
         r+CLfyA0GOIMTCwA80xvYG17K7izabe88H4+i2rvbLuv2t1aHf07gQB1V/PnGb4RJclX
         WbkVyFYHz8uxKTVCGolOpiGK1kLS/whp0vuXIPqYx/1v1XrfcTrVwNbbpRiZiz4cS4/1
         fJyKFiq/8AlR9Utes6IDhV6+5nk2eIfj35L43sOZpMwjW1fnkLTZLPuuQzzaZRiUhmwX
         a36Q==
X-Gm-Message-State: AOJu0YwxPFThdr1LnoERRpTbG9FZTH6Yct4PWMQjcJQ2W9mnfjPoIMXM
	zjCyHIJn9h6mJfo1Wzxz3Dmbwo58s7KrvL1BIShdzlLFcJDcULaDbbWkvTstghdvU+RrM+xW6Wi
	OdCTJXYKn4BvfwuPDIIaoI2RchRliSpk=
X-Gm-Gg: ASbGncsLNjgL8lYodtwioyNWdd3tvP9gdNgDQfMcpllXgLR1NjTCvnM39uwXzgaRJGK
	LEX7tdY8R1hG78VpB/4E8cTfQ8EjA2EvPazXleKfx58Dl5xqOOa46y74UgWYhaHQon/wDo+qx5t
	GHCRlkMPfk18XIlzpjFzHcaHNNgEZYeIfnlqqnktkmfD3BWO4++WUqvgCT6X4P1RfkGbStEA9py
	AJCfa4H2LEickc1
X-Google-Smtp-Source: AGHT+IFLTHm5o0mv4CGWgrUqeErZr9HrQbQ/VmFgZ0l3RsPrOLo7zFMVPFu7+ypT31Wj9MZz2Qe/ZkQz+FZSSbkyE0s=
X-Received: by 2002:ac2:4ca9:0:b0:55f:3f00:a832 with SMTP id
 2adb3069b0e04-5704aaa0544mr3746790e87.10.1758010955682; Tue, 16 Sep 2025
 01:22:35 -0700 (PDT)
MIME-Version: 1.0
References:  <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com>
 <86aec3a8-a4aa-40e4-9542-9d291c2c119e@xen.org>
In-Reply-To: <86aec3a8-a4aa-40e4-9542-9d291c2c119e@xen.org>
From: Mykola Kvach 
Date: Tue, 16 Sep 2025 11:22:24 +0300
X-Gm-Features: AS18NWAVe7RC4KzRpPhU8KOkhwSyTlHJT8npqcpWzNQkODJfUSEcgs0V2YDr5HM
Message-ID: 
Subject: Re: [PATCH v13 1/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 , 
	Andrew Cooper , Anthony PERARD , 
	Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Julien,

Thank you for reviewing this patch series and for your valuable feedback.

On Sat, Sep 13, 2025 at 1:38=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 02/09/2025 10:03, Mykola Kvach wrote:
> > @@ -880,6 +883,40 @@ void arch_domain_creation_finished(struct domain *=
d)
> >       p2m_domain_creation_finished(d);
> >   }
> >
> > +int arch_domain_resume(struct domain *d)
> > +{
> > +    int rc;
> > +    typeof(d->arch.resume_ctx) *ctx =3D &d->arch.resume_ctx;
>
> I know this is v13, but I don't think we should use typeof() is in this
> context. "struct resume_info" is much shorter and help the review (I
> don't have to grep resume_ctx to figure out the type).

Ack

>
> > +
> > +    if ( !d->is_shutting_down || d->shutdown_code !=3D SHUTDOWN_suspen=
d )
> > +    {
> > +        dprintk(XENLOG_WARNING,
> > +                "%pd: Invalid domain state for resume: is_shutting_dow=
n=3D%d, shutdown_code=3D%d\n",
> > +                d, d->is_shutting_down, d->shutdown_code);
> > +        return -EINVAL;
> > +    }
> > +
> > +    /*
> > +     * It is still possible to call domain_shutdown() with a suspend r=
eason
> > +     * via some hypercalls, such as SCHEDOP_shutdown or SCHEDOP_remote=
_shutdown.
> > +     * In these cases, the resume context will be empty.
> > +     * This is not expected to cause any issues, so we just warn about=
 the
> > +     * situation and return without error, allowing the existing logic=
 to
> > +     * proceed as expected.
>
> I think this odd to warn if something is expected. It would be best to
> use "XENLOG_INFO".

Ack.

>
> > +     */
> > +    if ( !ctx->wake_cpu )
> > +    {
> > +        dprintk(XENLOG_WARNING, "%pd: Invalid wake CPU pointer for res=
ume\n",
>
> As you wrote above, there is nothing wrong. So "Invalid" is not correct.
> I think a better wording is "Wake CPU pointer context was not provided").

Thanks for the suggestion. I'll change the message.

>
> Also note that dprintk() will be a NOP in release build. I am guessing
> this is intended?

Yep. In any case, the status is checked after the call to arch_domain_resum=
e
(see domain_resume), so we notify the user about the situation. Detailed
prints are only available in debug builds.

>
> I will answer you Jan's comment separately. The rest looks good to me.
>
> Cheers,
>
> --
> Julien Grall
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 08:23:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 08:23:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124554.1466849 (Exim 4.92)
	(envelope-from )
	id 1uyQyJ-00027E-Ca; Tue, 16 Sep 2025 08:23:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124554.1466849; Tue, 16 Sep 2025 08:23: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 1uyQyJ-000277-9z; Tue, 16 Sep 2025 08:23:31 +0000
Received: by outflank-mailman (input) for mailman id 1124554;
 Tue, 16 Sep 2025 08:23: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 1uyQyI-0001Zv-RN
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 08:23:30 +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 6c8990ad-92d6-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 10:23:29 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-571a58b385aso4385838e87.2
 for ; Tue, 16 Sep 2025 01:23: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: 6c8990ad-92d6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758011009; x=1758615809; 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=auVS9T+dgb0lg6NH2LN1afejzf9QPdC2hyz88jpF4oM=;
        b=gOFgVCE2UdUiIAVwG7FHKBsC8rOqy+UOoew5Drjp1+iKtkUGM1J/LEyhXuEPO65XU3
         9l99mBfKOZ3KH3SrryT2F6LR+AJHm+VEHOiun0bBIWVfqCiNB6zgEu/Z6uCRjnrVNkbi
         q62TkSo888M+Lmlurf5H8zIqS0t4Cpp5iyY1pkI7iksH7FFBAw4i+5d91dV9ih58Dsyr
         QXPD3hTa1eTSQneufEHYdUWbRcmElZ1zCD1C5/4SwDFJbTF6ea3Ql3y+Ud4YMMo8rvBm
         6gWjuJFhPXPOSqAHgmdrfKsv2PFSDqMK2nmvJyAMIN2fR7aBCL1YYnKHXJ/IUpcvhqWH
         0H/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758011009; x=1758615809;
        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=auVS9T+dgb0lg6NH2LN1afejzf9QPdC2hyz88jpF4oM=;
        b=T272u/j9eqaa5cYXpnwH+PYXAtsBOzlXQ9O2quHr0P2k3EytGMwUv+dwO1SedIetEl
         1567QldNoxijmZc+hyVLxz+VSHZBvi4F5DrASYLlE86Ss+j150WV3AZM0GMm7zSuJtpv
         VtkuREpiQsZfkmjX3yyDB4XKSRp14AJ7n18CX09jSx4N5CXeMPmIBptdCza/VfvMaVzH
         bDM5Vrv9icyWMmCUL03NLwW0tl5i54Dqh0cGgofzjglMUph2AZohDBsv9rseaCTBBBK6
         3otMzHLLrLC+Wj7z7+wvEL9jbUhV/ewj9avppcwRQbCo/cjV5VwFxBB1yG+GbXH5Dbwm
         JMIw==
X-Forwarded-Encrypted: i=1; AJvYcCWP2Q5d0jHuWAvedFDdgOu8Xe+yDqkjOvrFRmvE33fditq5AmCWpk83dafLmWLCr3X+WklfUJPvSXI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaazEVIsqDQvMd6FE2gitvymIPjb8wJtpbHUa9HmwFPHMg+dX0
	l0K96Fibl7Sb5h4QcGigTGsjFyxj/XhYY6InOglt+klUt3aLyNj5NDidR9gV6KkGkMred/uNFSO
	05di3KpNhwBMayJtyvolCoT/ZVdrQMgQ=
X-Gm-Gg: ASbGncs8TTLuSitLm8AFJnvcehNN4aPUKLe/Go1Ip9wFVkAmN6E6luZV387AIs1Q8uQ
	iGr9CDJDT91SYqdYYT2S+H8VveYEpgA/rDHuW2lEMIL5WwQhsPVR3sv98kN+qYjsbzU1ruabrgv
	yaDwW4Y9dgvUnVJEZpTxeEl+TLUnrFUbnCZIrU+q97ToFPqVpm9OgHS5qgBb364/AnuhhhCLBaJ
	gbw1g==
X-Google-Smtp-Source: AGHT+IHWxBsSoQN9PIWPasmPxaATOMBJU4zAZHQLuU4ZrpZiZRMedObwLqZfQGyO/x8z4qnjiOw5ravJ9lo3+a1+UpY=
X-Received: by 2002:a05:651c:509:b0:354:8a7:2f7a with SMTP id
 38308e7fff4ca-35408a73bc8mr39241341fa.20.1758011008543; Tue, 16 Sep 2025
 01:23:28 -0700 (PDT)
MIME-Version: 1.0
References:  <53cc6a9cf7a73d12c632bf8b8eee2f7069e6b0f1.1756803419.git.mykola_kvach@epam.com>
 <28e78684-ff7b-4902-89cd-c341ba236d57@suse.com> 
 <212f3043-bfd1-4c84-bce4-ed98648aa880@xen.org>
In-Reply-To: <212f3043-bfd1-4c84-bce4-ed98648aa880@xen.org>
From: Mykola Kvach 
Date: Tue, 16 Sep 2025 11:23:17 +0300
X-Gm-Features: AS18NWBhtmIpqHcw2C26VfKBkitw_05lwPVsJylFKd6NPU7YsVYHzkbc22rLbGQ
Message-ID: 
Subject: Re: [PATCH v13 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests
To: Julien Grall 
Cc: Jan Beulich , Mykola Kvach , 
	Stefano Stabellini , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Andrew Cooper , Anthony PERARD , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 13, 2025 at 1:43=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi,
>
> On 02/09/2025 18:55, Mykola Kvach wrote:
> >>> --- a/xen/include/xen/domain.h
> >>> +++ b/xen/include/xen/domain.h
> >>> @@ -8,6 +8,10 @@
> >>>
> >>>   #include 
> >>>
> >>> +#if __has_include()
> >>> +#include 
> >>> +#endif
> >>> +
> >>>   struct guest_area {
> >>>       struct page_info *pg;
> >>>       void *map;
> >>> @@ -109,6 +113,13 @@ int arch_domain_soft_reset(struct domain *d);
> >>>
> >>>   void arch_domain_creation_finished(struct domain *d);
> >>>
> >>> +#if !__has_include()
> >>> +static inline int arch_domain_resume(struct domain *d)
> >>> +{
> >>> +    return 0;
> >>> +}
> >>> +#endif /* !__has_include() */
> >>> +
> >>>   void arch_p2m_set_access_required(struct domain *d, bool access_req=
uired);
> >>>
> >>>   int arch_set_info_guest(struct vcpu *v, vcpu_guest_context_u c);
> >>
> >> Imo it would be preferable to have such in a single #if/#else. There's=
 nothing
> >> wrong with an #include not sitting at the very top.
> >
> > I understand that includes can be placed near where something from the
> > header is used. However, I find it more natural to keep them together
> > in a single location.
>
> It is not always possible to keep all includes together. I also have a
> slight preference to Jan suggestion because we don't have multiple "#if
> __has_include()" which I find rather ugly but necessary.
>
> >
> >>
> >> (Another question is whether to put this in xen/domain.h at all. There=
 could
> >> be a xen/suspend.h having - for now at least - just this and nothing e=
lse.)
> >
> > With this approach, I don=E2=80=99t need to move the include to the mid=
dle of
> > the file.
>
> A new suspend.h file would also work for me.

Ack.

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

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 08:41:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 08:41:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124568.1466860 (Exim 4.92)
	(envelope-from )
	id 1uyRFg-00057x-Qy; Tue, 16 Sep 2025 08:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124568.1466860; Tue, 16 Sep 2025 08:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyRFg-00057q-N1; Tue, 16 Sep 2025 08:41:28 +0000
Received: by outflank-mailman (input) for mailman id 1124568;
 Tue, 16 Sep 2025 08: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 1uyRFg-00057k-29
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 08:41:28 +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 ea08e8f2-92d8-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 10:41:18 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-55f7cd8ec2cso6113860e87.2
 for ; Tue, 16 Sep 2025 01:41: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: ea08e8f2-92d8-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758012078; x=1758616878; 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=El3Ib6F1KjdsO1/Gdr5bPdBdPa3T/yY6demzLruzJfw=;
        b=lNStVW9MyLf8kgx02ZwdOmJJBSY+/xii0dRiZ/cwXK1Yye98VdR88G3zwKD77REe1+
         hnkXHy3m2s05Y9C/IbWjJZKJI4n5D/4UewfF0OR7cYyUBLWZylylQDm/2g/cJje/ZA2p
         5u2N1nSshkIE1MFW34Ivv4JBFqdpme8B4nZzOWu2AmqDUWMz31vLzSrf+gV4QnfhqQAC
         Y+mAT1odTBozrdRhYuNDoU4ahOfjiLiA4tg/4tpwW4cWHT7Qi2SMK5hevVk4BusLM+Kq
         UAbufB3YIsUXTlRvQ42fwLCMLKJcJebzjvl2zPHFFp+Y9y+L95LIEtPUWogreAwWCJ7H
         03Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758012078; x=1758616878;
        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=El3Ib6F1KjdsO1/Gdr5bPdBdPa3T/yY6demzLruzJfw=;
        b=srZBJHhc4ivPKUnX+ED58V6nP0vfe4XA9f1XZbCmdFjuf6SoglxkXutox1n/qP5CUf
         od6AEt/09caCc9A16KYFDR7rp0elGZV2A7ypI+zyeWoGJ5XQloQDMLuuLzW77pqGuQ1Y
         s+4eeiZRx4xFx7Pgay/Lqh5PCUh/FB/QzXlYP37YQqWmEn3WSWr9GiTKzKxi86T93A/R
         2Ebzac3JpKFYanHlIXJ4PN/HZew9A5/rluX7dvgIoRPoHOfYQp3s7thHaoL+pzdb+Bp0
         3gev0zlV8V+kf+dOL3qSoNnmJi96BjC5vbvueo0s5QKp5xx+7+DSogLC/XwwtdD1xIIF
         ddpw==
X-Gm-Message-State: AOJu0Yzd9ByNGGt2ZSfvq5yHqBxO0sKNwjZH8zkj2rFXpMAiHnK4qbYN
	ESkohM0cU6C8C63mHaVp7XuaXC+0YLT/1Hhh3cJLNiuOFQdpMXAIzOrra7d9FKonLbDIj9lnG2D
	B53Q5qBOxulroVA9LLaVOa9UORu2JHJQ=
X-Gm-Gg: ASbGncuXccqXoQtxHIrG5UdmTtXFVIlmdQxLhHMCr3NLv8e42w7235x2YytYyrsppyU
	lcdKkoxYjNx9dchiiwHVU5BJ1Ir2PTTb3fq2qhM/o8FUOikw7pC1XuMOt4sT0YuI5wAdLPtno7N
	A9inaxBcbOX4vMkLJx0QAvuTtzLJlAUaeBRRwcCN0FAEoffsCayDmzmG9F3vk3RbjneUIN52H8v
	zq7DA==
X-Google-Smtp-Source: AGHT+IFSaoW0fYKvZs6OedwlNuCbz1iQIBfY3TuXQvtZsV1hP+Dxvwpur6g0eNfVOFEehd8QNJq+phDWME16ztcoAYo=
X-Received: by 2002:a05:6512:1352:b0:573:8044:a98f with SMTP id
 2adb3069b0e04-5738053edf1mr2306217e87.15.1758012077828; Tue, 16 Sep 2025
 01:41:17 -0700 (PDT)
MIME-Version: 1.0
References:  <9dffe19e3ba29020a8f35c0fcf12f088de6b9eea.1756803419.git.mykola_kvach@epam.com>
 <95ac4fa9-3169-4285-874e-32ec58c247b2@xen.org>
In-Reply-To: <95ac4fa9-3169-4285-874e-32ec58c247b2@xen.org>
From: Mykola Kvach 
Date: Tue, 16 Sep 2025 11:41:06 +0300
X-Gm-Features: AS18NWBa8KS0uSO_0XMWmo8TIoQIp5xF1NRtRkSdVJherFpMzMuWNIOeEHlxmJI
Message-ID: 
Subject: Re: [PATCH v13 3/4] SUPPORT.md: Document PSCI SYSTEM_SUSPEND support
 for guests
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, Sep 13, 2025 at 1:47=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 02/09/2025 10:03, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > Add a new entry under the "Virtual Hardware, QEMU" section documenting
> > support for the optional PSCI SYSTEM_SUSPEND function exposed to guests=
.
>
> AFAICT, this is added under "Virtual Hardware, Hypervisor".

My bad, thanks for catching that.

>
> >
> > This function is available via the virtual PSCI (vPSCI) interface and
> > allows guest domains (domUs) to initiate system suspend operations.
> >
> > The feature is currently marked as "Tech Preview".
> >
> > Signed-off-by: Mykola Kvach 
>
> With the above fixed:
>
> Acked-by: Julien Grall 
>
> Cheers,
>
> --
> Julien Grall
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 10:20:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 10:20:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124587.1466869 (Exim 4.92)
	(envelope-from )
	id 1uySmu-0007hG-Ex; Tue, 16 Sep 2025 10:19:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124587.1466869; Tue, 16 Sep 2025 10: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 1uySmu-0007h9-C1; Tue, 16 Sep 2025 10:19:52 +0000
Received: by outflank-mailman (input) for mailman id 1124587;
 Tue, 16 Sep 2025 10:19: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 1uySms-0007gy-GE
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 10:19:50 +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 ac6b6d9c-92e6-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 12:19:48 +0200 (CEST)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-55f98e7782bso6491643e87.0
 for ; Tue, 16 Sep 2025 03:19: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: ac6b6d9c-92e6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758017988; x=1758622788; 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=CJGhaFxrI3QvqCALSLc2lTh4znvwNyDw2PIa0ef8UTc=;
        b=iZzbxR+QXtsi0Vs6XxX0EeiK06tOfxwXEVUsfGPJmiwI7wGocpV6A1NeCNsxTEH1LC
         vJPUz82LgAKlZl7iBoo4NFwJFHOBzMihnfR0VlX7/LFUHEXrRz7Jg1+/svrX57H3itZG
         lUPu3o/l0UYwZtCHPQxS15Tmc5Tusl6PSBeE1sVN+NC+mXzDflPbF3dHe2Db3u0zPpCq
         q284XNaZcCrclnxQpkYUvIjGjeX/lIq1DdAhEVyk70hs+Uewnp/UpwkegbGAaxOf/WEx
         p0xc3x3BSJQV+CLIFn1t1jnuhZXrYZT/JqrP6UmWh+COTt5gUHs929mEEwyUZf0yc1xE
         Mrxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758017988; x=1758622788;
        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=CJGhaFxrI3QvqCALSLc2lTh4znvwNyDw2PIa0ef8UTc=;
        b=g/0p8vbnDJS+uTIQYFgDFzKHaxXYUbl7MLtIPVssh8gpJ2ZZmJdMYMH2iYmfIYze50
         WLY2hwAfNJnMXkMVs648p2omunHH6kmZK27jcXi1RnemOrNXgtgdzJK/ZRBlujg9dSt+
         RAQwbZuniA+tmZDt61XTbGS3p8IOTiZCanmLt1XA6h3jBRRv+DC5CpsIntB+7DTf6pdm
         YX/GBVBKnD/11mL6CpUB6vLhVwwwwUYOLWUD7qEurWkrf6Oof5DxABdZ5VeBqfyKYXZc
         1k2+vRGaSvh+MLEP0hEpKSOxTdtTBVm4IHpMruVRGGsW94FSqjL8LEngNDresAgVl2pi
         xrKQ==
X-Gm-Message-State: AOJu0YwJVDS8exPDArGOIZeghg6ITtBTSbCYDscKsrs+V+J6La8By/LW
	gTfZO35OgEj5UWsEGY2ZOJc7PUW3pdHXQuK4J6wA/DlY7MOOziIEFn1pYqdv34FUIN4jgy2HZsH
	e13lypBZBjo23Xstfm42r7LVgPQkjyrE=
X-Gm-Gg: ASbGnctcUVIZded4ml32248xNqSVy/bythjCnHe743+AtxnBr6JxQHV995NKerx39zx
	zcrtZpMWEiBs1KC3NYzX9k+u44/jmnSsjCl/+F9FD2b0mzs7dgs+75PYUx/eKmRqwfdhu05G6rB
	prSaM2SxweOEwD2VLwim1n7Rv1vmF+zm8UViTd3CJ7HeCL7HGqvlvOX3RfJ3lLWPA8Xko0w+fsV
	qT++Q==
X-Google-Smtp-Source: AGHT+IG+zB1OqA8r0jCDQBM50rd7D3RT/EYwfe2xsMCAgjPj8rSeQHe3Tz1FLxAtGq/CX2pgLTr9JuwDwG06NTPIDMU=
X-Received: by 2002:a05:6512:3b97:b0:55f:3ae4:fe55 with SMTP id
 2adb3069b0e04-5763d4f8981mr685316e87.4.1758017987410; Tue, 16 Sep 2025
 03:19:47 -0700 (PDT)
MIME-Version: 1.0
References: 
 <0d0f4689-97e2-408f-91e4-dd59f47bdb95@xen.org>
In-Reply-To: <0d0f4689-97e2-408f-91e4-dd59f47bdb95@xen.org>
From: Mykola Kvach 
Date: Tue, 16 Sep 2025 13:19:36 +0300
X-Gm-Features: AS18NWD2GgZVJe0SKHZdEe-7g_RDtM1f2rth_di0bO15KJRo3yNTMQTSUMAfPwQ
Message-ID: 
Subject: Re: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in setup_irq()
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,

Thank you for your review and the helpful comments.
I appreciate your time and feedback.

On Sat, Sep 13, 2025 at 1:01=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 03/09/2025 03:55, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > Use GIC_PRI_IPI priority for SGI interrupts instead of the generic
> > GIC_PRI_IRQ priority in setup_irq().
> >
> > This change ensures that SGIs get the correct priority level when
> > being set up for Xen's use, maintaining proper interrupt precedence
> > in the system.
> >
> > The priority assignment now follows ARM GIC best practices:
> > - SGIs (0-15): GIC_PRI_IPI (higher priority)
> > - PPIs/SPIs (16+): GIC_PRI_IRQ (standard priority)
>
> Please provide a reference to the spec. But I don't follow why we should
> follow exactly what the spec suggest. This is up to us to decide what we
> want. Otherwise what's the point of having more than two priorities?

To clarify, the GIC specification does not require SGIs to have higher
priority than PPIs or SPIs. My reference to =E2=80=9Cbest practices=E2=80=
=9D is based on
how Xen typically configures SGIs with higher priority during initializatio=
n.
This is not a strict requirement, but it helps maintain interrupt precedenc=
e
in a way that aligns with established implementations.

If needed, PPIs or SPIs could be assigned higher priority depending on
system requirements.

>
> >
> > Signed-off-by: Mykola Kvach 
> > ---
> >   xen/arch/arm/irq.c | 8 +++++++-
> >   1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> > index 02ca82c089..17c7ac92b5 100644
> > --- a/xen/arch/arm/irq.c
> > +++ b/xen/arch/arm/irq.c
> > @@ -397,7 +397,13 @@ int setup_irq(unsigned int irq, unsigned int irqfl=
ags, struct irqaction *new)
> AFAIK, we are not using setup_irq() to handle SGIs because they are all
> static and always enabled. Are you planning to handle dynamic SGIs? If
> yes, then can you provide more details?As far as I know, there can be at =
least one =E2=80=9Cdynamic=E2=80=9D SGI in Xen.

As far as I know, there is at least one =E2=80=9Cdynamic=E2=80=9D SGI in Xe=
n. For
example, see ffa_notif.c in the functions ffa_notif_init_interrupt
and ffa_notif_init, which handle initialization of such SGIs.

>
> >       /* First time the IRQ is setup */
> >       if ( disabled )
> >       {
> > -        gic_route_irq_to_xen(desc, GIC_PRI_IRQ);
> > +        unsigned int prio =3D GIC_PRI_IRQ;
> > +
> > +        /* Use appropriate priority based on interrupt type */
> > +        if (desc->irq < NR_GIC_SGI)
> > +            prio =3D GIC_PRI_IPI;
>
> I am a bit split with this change. I feel static SGI (e.g. EVENT_CHECK,
> CALL_FUNCTION) should have higher priority to the dynamic SGIs because
> they are critical for Xen.

That=E2=80=99s a good point. My intention was to follow the general approac=
h of
assigning higher priority to SGIs, as done during GIC initialization.

>
> Before making my mind, I would like to understand a bit more the use case=
.
>
> Cheers,
>
> --
> Julien Grall
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 10:33:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 10:33:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124599.1466881 (Exim 4.92)
	(envelope-from )
	id 1uySzf-0001tf-IS; Tue, 16 Sep 2025 10:33:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124599.1466881; Tue, 16 Sep 2025 10:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uySzf-0001tY-ED; Tue, 16 Sep 2025 10:33:03 +0000
Received: by outflank-mailman (input) for mailman id 1124599;
 Tue, 16 Sep 2025 10:33: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 1uySzd-0001tN-Eo
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 10:33:01 +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 8458780e-92e8-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 12:33:00 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU0PR03MB9591.eurprd03.prod.outlook.com (2603:10a6:10:422::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Tue, 16 Sep
 2025 10:32:55 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 10:32: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: 8458780e-92e8-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tlJCyIVh+FoaFWUCJGxYoTBfgx63HJR0SFy53VQ5kjFvrGYoY+m1KoirDpmFLySLYwDF0ukKnHyPvkWfCHUBFvswytmyN3tSd6NS2ANhYuPJaEecbikDIGu2sj8Wf7LajyMBOHH7xw22KmxQSqT3er3dxjZuN8dlSI7Vux422CejP4HYaVJzogm4SWPaBE75TExCOyH62uSrEH5e3If1gG6MUl8mBYhY12wVFglWXjmydM9wZ0A+lLmF+4o01ryFo33Mej2SZJUtlwx7e9hmhUEaEuDorgPte8A554xVT8AcAUr3HO/Y/ENIbCqKBZc8PNnXbCijNhcDqnVC73P09A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7ETb3dpCMMoT7n0RU1nZ6MxKaPbIvoDnb5WEDgR6cbo=;
 b=PtqnO8z61U47sjy3eumE5FU726KroxX2+1Ezh2YVtAOmRinT4TVLeD1Kc/xZEnje4IwcLJ6AN2wdiXMjasVUbS2+q2Bo5P4qvxGsmmIUmLObguMvLZxIlhOwinr+KuT8Br7FxcI2DLFstLpLLRauO+cFFzMPajzEzVM6uhbbwQpolJPex/SunaVq6eaQmznPRaqb3+bjIWxDfOsW6MLl6yLe7sNdxmafnRUJme9jJ+xMmfntv5+iK6d1dki+or6Uc0+psRNhioDzqWXrYDZAmYs+W1SKQk+PEDDNlNMgkccOWSlPhV75ZID8OlPv166MxLN0fgH6r5pPaZhkwU0Olw==
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=7ETb3dpCMMoT7n0RU1nZ6MxKaPbIvoDnb5WEDgR6cbo=;
 b=WnBwJDU4jXct2Om0lk7q2TCx/jqLbkdb3w84rUAaepeaTN3m0p/3n/1fDzr49A/UZZvgj6qXSCFJJM0OlIOdslUNBtfadzZlDJWqN1Ra56XVtvPsJChEFDIyAsY6GSwAVxEK5/okDuHjyahmbXMjsPTosWtPojvtUKslrfqRQKM2HBlQMi0LowCR9gOJGihwpL411iFJ66sulDip4kOaPcm4ta3A27qpvX3or3iBeTCTD4e8YGm2s6XP+ZJ9dernoYcu3bQ/SZ2GZPEQR0wBW1jZZXs/CtXD+RzAOKt9lHGkDLvsBL0iLqpXt4Pm2GE+aRxyGX9mzm6BDKVYMobEqw==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alejandro Vallejo
	, Oleksii Kurochko
	
Subject: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check for
 !CONFIG_INTEL_VMX case
Thread-Topic: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
Thread-Index: AQHcJvVD2WER0/U75UWsICVLjMYHFA==
Date: Tue, 16 Sep 2025 10:32:55 +0000
Message-ID: <20250916103251.2144449-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|DU0PR03MB9591:EE_
x-ms-office365-filtering-correlation-id: cf1c6037-b7a4-452d-7515-08ddf50c65d9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?pF/oTw65e+YALbZrDV2SBGkWT0FP5fgIj0Sc+G/JmjkuFR2uQuVnq/WL9+?=
 =?iso-8859-1?Q?URk0HheG0ISnX/y8k1TNoPuc4yu/7Jz4bTSSfPBdN1j4gJf2Yw4wpBLcRY?=
 =?iso-8859-1?Q?KXg2Z8FJEeeZyvE41GDKufHELJ3o/Ft20pAAU6LIEYc3OmQN8IYaJ9AIPI?=
 =?iso-8859-1?Q?Fsn3d9X0kV+BlTJingoLf43reUlHffayx37UCKKvfT2LUZg+hxjriK3gi+?=
 =?iso-8859-1?Q?ikLGMotMsgS6+U2DDNvam88NlECNOl8S0phy38vQrEJt2Wv6MMgWGfSeqz?=
 =?iso-8859-1?Q?U/OCnLW9r0J/p2ESXsNnR72lI/4rNTG2zhKKW83RWuBPJnubSoz+o4eYJ7?=
 =?iso-8859-1?Q?kg/Toc0JkuGQT9Bn+6tI0NJT2UvQN0YYDFycKojjhjqaX4mJjAdMr2gIKi?=
 =?iso-8859-1?Q?A79WzJ5/cQzA4haFHhWPokLc1CBDMKc3k5whDFNGcWJZXDpQOB2evF3HiX?=
 =?iso-8859-1?Q?oCB++UeMBKS9WwL7B/et+1hpri7tJYTX9Bs+xMj57c8VVQh6IyAtIY911m?=
 =?iso-8859-1?Q?D3XjZakHDrPu1WMALtYO6xIVl6zXq6BlHewEADFgd9R8rjH6l8Husfu7ua?=
 =?iso-8859-1?Q?30UfryumOguj8htPPGkrBYKUsSR8vhk87i0o+Nmf1MsnhG3zeJP66nMRDT?=
 =?iso-8859-1?Q?eEPPM4y06VC6Amff9v8aQOnA4xx6wtBSJRBtmyQecFFBaFb/So789SX5hx?=
 =?iso-8859-1?Q?Ejc4/V7ebtddaa8eHMue4eUeRJw7c0rIWMYjN58zYy6DqFKU6bAYZ2MJWo?=
 =?iso-8859-1?Q?YWgQ5TX3EWOpjzwbFsZMjuW842MKgEvL8O/7YoIyAU6wQLktJYhnEpUC4q?=
 =?iso-8859-1?Q?yrJj1617fXHCRfTTUfUYCS2SKM5ESbu5bLCti06S2xJ8yaXVhRaHHqHvUI?=
 =?iso-8859-1?Q?ap3eLz0quI7+zS+7PJumcL6Z1/NKkUTxh6OZvU3T2PdflRkJoNtfljBmqL?=
 =?iso-8859-1?Q?gtnhNbTmW+n5qoBcu4yUTv0BQzabIf+iDUqCIx94rFJIr6hW8KUVXprsv2?=
 =?iso-8859-1?Q?e3Muee5bfyIUMJ+1qF2WShKhKcPo+/rnvd5w8IWYK3rBGc1a5XwfeS5Cws?=
 =?iso-8859-1?Q?5oU5W5GRHcKSgx1CYkbiv/MUvyG0I3pHLarso8ty/bUa2PwKBN6uzHYn5k?=
 =?iso-8859-1?Q?MxLcuwr3+0riXzVJgtd3lljZRj54a+e84h2USQlCZpURDNhR53Zs95C0is?=
 =?iso-8859-1?Q?kPoluThQMznypAqkga/+DYnMhoW/PXsn6u4/deq3kdBJAA9gVIB3ERo1lF?=
 =?iso-8859-1?Q?7xb4ljshayGAZA/a0HyRPo7TYEhrGBvvAp2UNXg6DNEl7cGB2o532LT5Ve?=
 =?iso-8859-1?Q?lHozkh6c+xOkma0FAWY9npAD1klEjqTyhUxryrUKxAIBKiy/WVc6IApuUM?=
 =?iso-8859-1?Q?CI1H78fhFINhLjboQZ/vwyKpO5H154m1fhCovf1nyDXyvLD5Hu+pPUIbpE?=
 =?iso-8859-1?Q?6k6p+s5Qh5rYp8YmC9VVg2SNoXL4MjYkGInEjDll8cG5JRLVf3bGHPQC62?=
 =?iso-8859-1?Q?06FgWdK+wRJB5O4ns2Eqqg5SCQajoCsGMBDmpIC4JF/A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?2tsR6AypYV/xAZiv8BvWHGp9bwFGe+wal5OT4YtoqEvzdWgI6jQimTFSNf?=
 =?iso-8859-1?Q?m6VjZcPR3Gw6YeYvQdF7C7e2YZ4u1GKFz/fBKwwXta+3lglGUbF5Wd4Y42?=
 =?iso-8859-1?Q?xX7OqhUIhJwvBX/qkN83hayYej+4RYV3AruAj+5TqCqWa6CZHNfX9mapkR?=
 =?iso-8859-1?Q?A702GRvclyX3cRCBd7LY3zm/5ng/RlNvNsQt38l1kBnGMwYAM7HSbnkOqa?=
 =?iso-8859-1?Q?htWDVfhxR1yU4UNNQoNIfvWnJNmuVldzqw3/cnQCxORPuz3YFTQmki3AZR?=
 =?iso-8859-1?Q?iGC35c3x0TLGAuBkN8dUmE9qh08cUm4HRXT0u1nLhUFqImz29iFgmkyBVl?=
 =?iso-8859-1?Q?ILuu/GcF/8UPzZIVchyk2mE18GArDaYFz17Pux2L4jbAsioEVLfPgDSVmt?=
 =?iso-8859-1?Q?UAFRplV7jOg/BC/QRM8kWtGgaahTXDYlfGD+VhrqHVBHPzy/oW79m5cs8w?=
 =?iso-8859-1?Q?/xu4hXott2QCAnEznHVckcDPqVhbKvOElY/QTSd0Qzig8T4SDKqnZorwWe?=
 =?iso-8859-1?Q?EKqo9NK988kmWkn1Zz7Hh/BIPmTe22n/8H6NsuHibrzAwbGa7aV1iirdPt?=
 =?iso-8859-1?Q?0BIpiyFuFi+CzajOCTPKlda3BchKbJoPL1UmdZQjp30kdenPBFqEoq4AsL?=
 =?iso-8859-1?Q?zBbdPF+pPejX87EdQMed7CCv9APCon6iGBXPpRPO19KpuTzL1bq1E3znjl?=
 =?iso-8859-1?Q?QdoP0FMMa5gk3pXElyANYTtLOe5dCPfwV2z7JxrxV77A4QDwWHASpXLWJS?=
 =?iso-8859-1?Q?SujVQk01xgWI00f1OTegMyg/IvN37oo5g95403u7zG3YqZo2cMZ6j+Uox/?=
 =?iso-8859-1?Q?mwaKs6zLZ0XFnHDLb4jj4XisF4PWFo5exJE4Y6Zxjd9Say9vElNF8gIssT?=
 =?iso-8859-1?Q?4Qe5Wj0FHe6I8zctjpgFeACafzy7YZZknWydLUNzuygDNIV8gixiQjB6gE?=
 =?iso-8859-1?Q?kNpT+X18v9clPliPE3G31pvHTzcSCM/ag8Ku2tf8Cnt/u60X1RnZ4HaOVe?=
 =?iso-8859-1?Q?YSqIB47XQtVqgKh/8u28c3k6agj9TX47RlJy5sS2oT2UJgywHS8j3Nose2?=
 =?iso-8859-1?Q?1K0SKiir0jtjjkNWy8rinDJK2ktC5jHAK8aTbJFsZmSfBJPgTvGhH/FWZR?=
 =?iso-8859-1?Q?grcWd3xsoPDEk62oQaTk6Eb6oQ1YV+WgdfA3Hr8G9t+MI98m9yD1gPVEts?=
 =?iso-8859-1?Q?6TGyxpKxV8bmglbljsrhREB2WcD4+P6LvbESKFo5RqVgmEcbp9p1z2xuWh?=
 =?iso-8859-1?Q?g3eJr716GjG9UXGQg1UGGCSmfFyX38wHcveBsyIPGiWRqoecmgPBbU7F2j?=
 =?iso-8859-1?Q?c6NkVAre3IKLQ8V2LHN//E4ftX82ZFWx3ahzxM56fq4X111tp/Mteh/BpU?=
 =?iso-8859-1?Q?VIoofyLzbUFMQMd9koCjvTNxWiGybaDgQ1A6eXubB0iUD/yiLf8Cf6Azuu?=
 =?iso-8859-1?Q?KYit1oc7z6YPvEk/lOrx0qtbkDBLGXOy8tOiFJlfGqN4CW9QvMavpsuMnF?=
 =?iso-8859-1?Q?VizggvOzjYO2YHnMvcWWfoGGRXMJZhW85Os9xcwkp8DvtdN8m8SUrNdCuY?=
 =?iso-8859-1?Q?2oz8sOkvpPzWm64XLjkDyyAYEuc6k4nMrPOVZ3Jfs9JDmEtIl123S3F43T?=
 =?iso-8859-1?Q?E3XUPaBeKklVZSiskXtA9bVuwQ04SQsN91XS1pnNSHmQnthikB5winwg?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cf1c6037-b7a4-452d-7515-08ddf50c65d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2025 10:32:55.3321
 (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: COdah+z+b+Ad+h1Gt1eRHVTvNn0sqNlQV3mS30Gno6njyZyhKtnIogFi9CEGRlEe013HigHx69aUkREvj7RGVFmIWotCTcadHhKi1lfnMes=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9591

From: Grygorii Strashko 

Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
HVM Intel VT-x support can be gracefully disabled, but it still keeps VMX
code partially built-in, because HVM code uses mix of:

 - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_VMX cfg
 - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX cfg

for runtime VMX availability checking. As result compiler DCE can't remove
all, unreachable VMX code.

Fix it by sticking to "cpu_has_vmx" macro usage only which is updated to
account CONFIG_INTEL_VMX cfg.

Signed-off-by: Grygorii Strashko 
---
Hi

It could be good to have it in 4.21, so vmx/svm disabling
option will be in complete state within 4.21 version.

bloat-o-meter:
add/remove: 0/0 grow/shrink: 0/7 up/down: 0/-779 (-779)
Function                                     old     new   delta
guest_wrmsr_viridian                        1062    1043     -19
hvm_monitor_descriptor_access                168     133     -35
init_guest_cpu_policies                     1200    1164     -36
nestedhvm_setup                              274     233     -41
p2m_mem_access_sanity_check                   71      27     -44
hvm_set_param                               1602    1473    -129
dom0_construct_pvh                          4438    3963    -475
Total: Before=3D3422547, After=3D3421768, chg -0.02%

 xen/arch/x86/hvm/hvm.c                | 2 +-
 xen/arch/x86/hvm/nestedhvm.c          | 2 +-
 xen/arch/x86/include/asm/cpufeature.h | 3 ++-
 xen/arch/x86/include/asm/hvm/hvm.h    | 5 -----
 xen/arch/x86/mm/p2m-basic.c           | 4 ++--
 xen/arch/x86/traps.c                  | 4 ++--
 6 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a1d..57d09e02ed0f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -158,7 +158,7 @@ static int __init cf_check hvm_enable(void)
 {
     const struct hvm_function_table *fns =3D NULL;
=20
-    if ( using_vmx() )
+    if ( cpu_has_vmx )
         fns =3D start_vmx();
     else if ( using_svm() )
         fns =3D start_svm();
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index bddd77d8109b..c6329ba2e51a 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -155,7 +155,7 @@ static int __init cf_check nestedhvm_setup(void)
      * done, so that if (for example) HAP is disabled, nested virt is
      * disabled as well.
      */
-    if ( using_vmx() )
+    if ( cpu_has_vmx )
         start_nested_vmx(&hvm_funcs);
     else if ( using_svm() )
         start_nested_svm(&hvm_funcs);
diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/a=
sm/cpufeature.h
index b6cf0c8dfc7c..f42e95586966 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
 #define cpu_has_sse3            boot_cpu_has(X86_FEATURE_SSE3)
 #define cpu_has_pclmulqdq       boot_cpu_has(X86_FEATURE_PCLMULQDQ)
 #define cpu_has_monitor         boot_cpu_has(X86_FEATURE_MONITOR)
-#define cpu_has_vmx             boot_cpu_has(X86_FEATURE_VMX)
+#define cpu_has_vmx             (IS_ENABLED(CONFIG_INTEL_VMX) && \
+                                 boot_cpu_has(X86_FEATURE_VMX))
 #define cpu_has_eist            boot_cpu_has(X86_FEATURE_EIST)
 #define cpu_has_ssse3           boot_cpu_has(X86_FEATURE_SSSE3)
 #define cpu_has_fma             boot_cpu_has(X86_FEATURE_FMA)
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/=
hvm/hvm.h
index f02183691ea6..0fa9e3c21598 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -383,11 +383,6 @@ int hvm_copy_context_and_params(struct domain *dst, st=
ruct domain *src);
=20
 int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value);
=20
-static inline bool using_vmx(void)
-{
-    return IS_ENABLED(CONFIG_INTEL_VMX) && cpu_has_vmx;
-}
-
 static inline bool using_svm(void)
 {
     return IS_ENABLED(CONFIG_AMD_SVM) && cpu_has_svm;
diff --git a/xen/arch/x86/mm/p2m-basic.c b/xen/arch/x86/mm/p2m-basic.c
index e126fda26760..08007a687c32 100644
--- a/xen/arch/x86/mm/p2m-basic.c
+++ b/xen/arch/x86/mm/p2m-basic.c
@@ -40,7 +40,7 @@ static int p2m_initialise(struct domain *d, struct p2m_do=
main *p2m)
     p2m_pod_init(p2m);
     p2m_nestedp2m_init(p2m);
=20
-    if ( hap_enabled(d) && using_vmx() )
+    if ( hap_enabled(d) && cpu_has_vmx )
         ret =3D ept_p2m_init(p2m);
     else
         p2m_pt_init(p2m);
@@ -72,7 +72,7 @@ struct p2m_domain *p2m_init_one(struct domain *d)
 void p2m_free_one(struct p2m_domain *p2m)
 {
     p2m_free_logdirty(p2m);
-    if ( hap_enabled(p2m->domain) && using_vmx() )
+    if ( hap_enabled(p2m->domain) && cpu_has_vmx )
         ept_p2m_uninit(p2m);
     free_cpumask_var(p2m->dirty_cpumask);
     xfree(p2m);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0c5393cb2166..e5141f819330 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -918,7 +918,7 @@ void vcpu_show_execution_state(struct vcpu *v)
      * region. Despite this being a layering violation, engage the VMCS ri=
ght
      * here. This then also avoids doing so several times in close success=
ion.
      */
-    if ( using_vmx() && is_hvm_vcpu(v) )
+    if ( cpu_has_vmx && is_hvm_vcpu(v) )
     {
         ASSERT(!in_irq());
         vmx_vmcs_enter(v);
@@ -947,7 +947,7 @@ void vcpu_show_execution_state(struct vcpu *v)
         console_unlock_recursive_irqrestore(flags);
     }
=20
-    if ( using_vmx() && is_hvm_vcpu(v) )
+    if ( cpu_has_vmx && is_hvm_vcpu(v) )
         vmx_vmcs_exit(v);
=20
     vcpu_unpause(v);
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 10:33:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 10:33:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124600.1466886 (Exim 4.92)
	(envelope-from )
	id 1uySzf-0001wx-Qw; Tue, 16 Sep 2025 10:33:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124600.1466886; Tue, 16 Sep 2025 10:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uySzf-0001wl-Lu; Tue, 16 Sep 2025 10:33:03 +0000
Received: by outflank-mailman (input) for mailman id 1124600;
 Tue, 16 Sep 2025 10:33:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uySze-0001tN-2x
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 10:33:02 +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 84eb78ab-92e8-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 12:33:00 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU0PR03MB9591.eurprd03.prod.outlook.com (2603:10a6:10:422::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Tue, 16 Sep
 2025 10:32:56 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 10:32: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: 84eb78ab-92e8-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mImsfdtGNq4t8gltSOs5PVcUnn5PZfLYhTXUx9ItNQYNjmhGq67OQ8AXSigfXpBUIgybqBTO62H0YWmKlRIFV1spupfGf70SzWYg1111ZwVR5M0JVqSUyG8nPuqGTtYyLJzG5+YoACVSH/Lo8vLyYpW5+k2gCzjj+yFmZzlcvaDO3BwTlzsZ6nwaqqhwlgzdUJJ7SQt44cCOkSKvLwQx0w+BDXGfQ9cztlq4bbNUpRzB5JQgSisK0zxM0t2mSblhsRtTg2XW5q0vpnL8VLQ4/dZ2u8hSAAvWQap60wHLvYi5GxRkVqat0g0NKGp2Kq9nG4A5YSDzjwQYdg2B32lxWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wv13zN5BcibyLFTJq/H0LRp7NtOi2qCJ2E+tKH0O7oM=;
 b=g5gAPTFhLQxc7YTBigHCXK6H94IoY9/+71IEVPJPsANngz0v0G9cwCsdn0UUwkNpmSQJ5rh/qmtRa0AqxfSlf+Otmkzs+MjF0dxD1Vj3Rc7vAPfruQtKyYdxYw2FnA6/yts8dP/B/IavQv1gaXdYoOuS4K5owq8GQ6MKQrf2Tny7TJ3XSdDWKGkMKe8vwI82vtfSK0ziRNE13mxZVK6h29fbzatCI+VRncreutM+zH+YmO6zjTOfrl4DFXhOH740Nd02KFA7cD3TcJa258BO+zVBE8tJHphaYF0GSbdNrrGcvH5/rZa+wr7IJ+sFWIwnWIhVG6Bb1Zq7/+LuwhcegQ==
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=Wv13zN5BcibyLFTJq/H0LRp7NtOi2qCJ2E+tKH0O7oM=;
 b=umPNSuib6YKTbkgM1kFCLWUf/09FTzDY0OqWnapdkfsVvwZv9RFJt9GGZw+v9qdP9swsJd4+v9yGo0cwlzBfxjydIQTM4ykx5+3ArGZ2J5O149KbBQNbbbZv/q6kv6TPYfLsOxZdYJwOYJerSEOKaJyKOfsXMSQ9gUTaomF+GXk6uoJGszXWnCr+h8PItSXTB6Dy70jqrTW3tQljdm9J9KzV1bhHsTZyMfBJ7kJM7w94R1zeoJ/wql0udOCQNKvq3tEFMZY24rebjK+lST1HvkJsgj1L5YEUW6BoQJBVPDt//tlxYfUfQ7A6Pmrvkn98lfp846igNECEkeb/CfvC2w==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alejandro Vallejo
	, Oleksii Kurochko
	
Subject: [XEN][PATCH 2/2] x86: hvm: svm: fix runtime svm presence check for
 !CONFIG_AMD_SVM case
Thread-Topic: [XEN][PATCH 2/2] x86: hvm: svm: fix runtime svm presence check
 for !CONFIG_AMD_SVM case
Thread-Index: AQHcJvVD14T55ZkVAEOSLzvP6+fiIg==
Date: Tue, 16 Sep 2025 10:32:55 +0000
Message-ID: <20250916103251.2144449-2-grygorii_strashko@epam.com>
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
In-Reply-To: <20250916103251.2144449-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|DU0PR03MB9591:EE_
x-ms-office365-filtering-correlation-id: b88a02e8-624b-474e-257e-08ddf50c662d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?W1HaOsH8Qiit4UyHtoR4oSTAvV+obToComCIWzccGVet4DnMq+d3XZYhs5?=
 =?iso-8859-1?Q?kzI6Zg+RmGiDdp84ukY5muq1eB4Pi8kH8S7MpVKxTIfkq5sxUqeVHd1XJ9?=
 =?iso-8859-1?Q?7lPsVPducCSSgW9tY4lS+pmP4OiAjHNPviodtBLgT0xOhrNFNi3JRL5pBp?=
 =?iso-8859-1?Q?7PIWAM82NZKJ/VLQupSSYqhd+I2RJsBZpyD/h9TZjHo1Ttg4R+tE95R2Rj?=
 =?iso-8859-1?Q?JJQfaJRkI8t2BqP3V6+tFFsUukanQ2u87L5ZWUh3OBhx+CDKqpd34GKs+y?=
 =?iso-8859-1?Q?T4VCRa6y7WOOR32uBgQvih9nwdJ7rCCxXZa28WnstEnd3C9oEIcRAMRpoE?=
 =?iso-8859-1?Q?up//jbKfy9ocuhcI9BHoMA11w57Xb5jcf9J+jkWeeDZtQfPNYPAQBdWD3G?=
 =?iso-8859-1?Q?yrIPD+hvkGYybbMo3nsihmaf9jQj4LtsG6Gbf3XNRvLihNO2fm42gD1Xqq?=
 =?iso-8859-1?Q?SbjHZdyKm4sZw++lL84346avy8sdy4FEIyuXgldvP0J2bDbR12Hce1TvUT?=
 =?iso-8859-1?Q?RuVrsS3YnuKcoVOfMdNOrZ0OB9FTnlgCm3GWx/INilrLW3w13sAye744ZW?=
 =?iso-8859-1?Q?YQVqEvZ2tbjvSR90OAQiREn+c38ZJTgGAuw9qoJfcfJNjBdcjNlYqLl7rC?=
 =?iso-8859-1?Q?CoCj5+McFmOCXADwCjpx7kbfIyPtLYS4JDbOjlElpjk1mFcjzs00IqSN+m?=
 =?iso-8859-1?Q?ScDFDTLWBJrx8Oo7zoQ6OUtVad73vtZP/GLEy+FmVFW2pUMOi6fPILn5ET?=
 =?iso-8859-1?Q?3EhgU4jULYC0yrQ5o39rbzs4EInylYTifvmRyRUGX7FsMAMI3LfPwh6yMy?=
 =?iso-8859-1?Q?vIEwo3b6PiBThphDMV40ZBpiKeZxA73LUeEGdGAjaIZ3iVo2zDM4OpHrIR?=
 =?iso-8859-1?Q?o7j71o4w1PdPuhwshvh9/ZUs+KZi23LNl1qdI37q68KonpKrRnOy+ETmkE?=
 =?iso-8859-1?Q?NE+7msiWcPWu3RLEA/p8B2PruVnKQF1d7mIMRIxV+DEK9dYyWQNUi7PWfn?=
 =?iso-8859-1?Q?7NLp2CiGPHp0i7N3Up2VC/8AlzSLedGJInswbNTNmWYllmhu5HOeWhfvQ0?=
 =?iso-8859-1?Q?m0l8EU2hFbo4d1Gmo42zu0lIp6lSGCxwIe3JWX+DFJ+auBBiQnezFDvAQH?=
 =?iso-8859-1?Q?Fa0LCyWoYRXaGLf5jXcPYpY+ZUwvfP8B8yTNYKml5lFu60lgeOQZE4tmWj?=
 =?iso-8859-1?Q?E2zdNsk3eqryhkA7Fp4JmB0xxdQXZKn/DVZYe3hpb90OHEIVr8TZRBdn0M?=
 =?iso-8859-1?Q?6bCFnmWUZUlVsI50VczY5bMyeeEm7tHDo0e2NhDUAFlPvMZohKfjLGv7RG?=
 =?iso-8859-1?Q?qNdWw6Q0QWkrJM1Na8Zii5bH02a2q4KzuKtEV/xiP2C+itWFBWZGPerQ0+?=
 =?iso-8859-1?Q?LHedZUNBkqDJlp3a6Xwb7mKTr9985VoMnd0o5SXFkAAuu/xiihJnEnjpmK?=
 =?iso-8859-1?Q?uEP50TBdyOAYyg1sf1nW/BHLTlR3aokFS4RvXZY3eRJDXj4EaI4MEwy0Gu?=
 =?iso-8859-1?Q?rdWDpK751dDF60s0/7Lh2kjCwnDpcJy8izDNz8eseLFw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Le7xk1M7BVFU8s7P5oN9RdBwgAGAlcB4u8ot8jx27uQJJvroshzQwc2Fy5?=
 =?iso-8859-1?Q?lYdQ2zpOrSFrZjgOYrRZ8JnkozAOh5U8ZJZ17BQT+a2QBK1YeP3eaUlo2H?=
 =?iso-8859-1?Q?3uhyQzi0SpvzaQ2J4Lw3S1GWmuakUsh7Z+dbE740/cLHJdMEJ2Nq9eC81J?=
 =?iso-8859-1?Q?u2PshVWbuc+0PwQfgjYAlR4Znxm6lp3aqsnqlgMVRwGbSj4mN4f7hIZP3D?=
 =?iso-8859-1?Q?CRII3vOYiK4eke7DJLzgGMtvCoR82q+EZFuEq635JGXkVKxpIfeoOjAm7D?=
 =?iso-8859-1?Q?2jTlW5KOaFXzu5iW11CFJWoJajKnUZx6pvogTDMBI/zXiAf4SwLdPQW9rM?=
 =?iso-8859-1?Q?1vJaOK+0Cg3QOOrNiyWIYbKa3GhoS18sud9YmlD37z1PFn1ah9VP5Q4xJG?=
 =?iso-8859-1?Q?MiUgJvXM0XCjrlCYj38hioobFIkOJcj4f2s2WIzO5FmMfqRvUc65if9lqi?=
 =?iso-8859-1?Q?7oi7DSN2Q/s8nI7pIAYRfeNkXQJhvifOZqDKwJYRppEleBh6vFhLXrSSzO?=
 =?iso-8859-1?Q?3/EFd+VVW/AjGJLxePmF68AtPcq9kX6fNKBH5+t4DiGwQDFFrJi37S7yIS?=
 =?iso-8859-1?Q?8G40N9KHJcIPB1qFjKxOM1kJYNLkaT0CxRBqZdJNI2Pv5OB2jJg/qFxhn1?=
 =?iso-8859-1?Q?wbNuEC0+C0S5XTkAuyxDc2jtApdWD81Ny48ZW1q8Z22oMniLVDPRjWZYv4?=
 =?iso-8859-1?Q?FA4WgKVxEpZzbrE3ajEMBcBonaaZBZauyb/+xCI/Wf0D37wXUSUfEh58tI?=
 =?iso-8859-1?Q?Oi7+Rq2AjGCMDvyhcWgdAgao+q5vVetCDgrgE2bhp/1RcDtsR4N/hWan+3?=
 =?iso-8859-1?Q?rr83HveI1/2SvvLUfZjUV06A8J2FEEKooL+UH7Sp6+fe/Jl9jmaZ+E9XOZ?=
 =?iso-8859-1?Q?1oVEMzohCzKvnV9stLs+SRWNE5Q7jzFAZHgW6p6oGTMu7BAwj/7uiQQbV+?=
 =?iso-8859-1?Q?G6eJ4eaDl+XpQ4SNkxTLXKqOeLHFFGKwJNTQ+cxRVrPKLJZuGQIJ2MLD3I?=
 =?iso-8859-1?Q?85MtoSLpI6UgtCicVqYepZSxc7d9mwsqNMMH9Suii/Ep2j+R+gjdM9HH79?=
 =?iso-8859-1?Q?WIMogZmEJBSPqHwBNhME6udnhHpQy7yOUabk/KnV/jWa7hMtzYhcN7K9Gl?=
 =?iso-8859-1?Q?xFkP5/3XiABzylMGMiP10c3y8M3pJJz68Uo/KOaiC+O0dT5pqSOjgi23it?=
 =?iso-8859-1?Q?ckc/fQQWP4rtFbbuxb4KI1qkIiHNbErGH5r2EH+dOG5njXRe+ar12nR7Qp?=
 =?iso-8859-1?Q?BVmbTgop0wc1E/kcqcbEgYW/UlOnQGLjcmBRCHmk2wWJo2Wh1/WAj+BwcJ?=
 =?iso-8859-1?Q?PxSNpswOnOeEcayI/8s5cxgaWNj5QaxbPQQYaELQ2Tdz0gs5EnGZRnoWpK?=
 =?iso-8859-1?Q?C9XkeImVME1FOA9kgOd8f0ci9gbl0s/hw+xug3KlCWPz3ni2S/885pQp1Y?=
 =?iso-8859-1?Q?jX/zSx7Yixkep6Kkf38yFfy7YlrkIScmXrm/mbVn0nN8uiY4jfZDREtapD?=
 =?iso-8859-1?Q?1GBKjRonj7A2Qmd2T8OYSewJZItQ3F6utk+sO83DihAEHw51btryRzmJn6?=
 =?iso-8859-1?Q?LerXmGD+J1rZfkknsAru7lWgCBE95WrEJlg1UJdoBJG6+e8YM6IwqCGbsM?=
 =?iso-8859-1?Q?kL65yraqoH5t8AZEPcvpwGPP9D9tJFAUvrfT+7+OHvy/EMiTcxPrETvw?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b88a02e8-624b-474e-257e-08ddf50c662d
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2025 10:32:55.8111
 (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: WylyvfNMDUDTHLc5wTPLF4QG429br0mVVHotJKWnMCTGyv/532nbCrjbD++EirebCRPd+Gat7SmAy/o9VbgSWh3IwEI58MStgiPC+hJHaHM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9591

From: Grygorii Strashko 

Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
AMD-V support can be gracefully disabled, but it still keeps SVM
code partially built-in, because HVM code uses mix of:

- "cpu_has_svm" macro, which doesn't account for CONFIG_AMD_SVM cfg
- "using_svm()" function, which accounts for CONFIG_AMD_SVM cfg

for runtime SVM availability checking. As result compiler DCE can't remove
all, unreachable SVM code.

Fix it by sticking to "cpu_has_svm" macro usage only which is updated to
account CONFIG_AMD_SVM cfg.

Signed-off-by: Grygorii Strashko 
---
Hi

It could be good to have it in 4.21.

bloat-o-meter:
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-98 (-98)
Function                                     old     new   delta
guest_flush_tlb_flags                         71      62      -9
init_speculation_mitigations               10024   10011     -13
hvm_set_efer                                 364     288     -76
Total: Before=3D3656835, After=3D3656737, chg -0.00%

 xen/arch/x86/domain.c                 | 4 ++--
 xen/arch/x86/hvm/hvm.c                | 2 +-
 xen/arch/x86/hvm/nestedhvm.c          | 2 +-
 xen/arch/x86/include/asm/cpufeature.h | 3 ++-
 xen/arch/x86/include/asm/hvm/hvm.h    | 5 -----
 5 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 19fd86ce88d2..92661527eb75 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1824,7 +1824,7 @@ static void load_segments(struct vcpu *n)
         if ( !(n->arch.flags & TF_kernel_mode) )
             SWAP(gsb, gss);
=20
-        if ( using_svm() && (n->arch.pv.fs | n->arch.pv.gs) <=3D 3 )
+        if ( cpu_has_svm && (n->arch.pv.fs | n->arch.pv.gs) <=3D 3 )
             fs_gs_done =3D svm_load_segs(n->arch.pv.ldt_ents, LDT_VIRT_STA=
RT(n),
                                        n->arch.pv.fs_base, gsb, gss);
     }
@@ -2142,7 +2142,7 @@ static void __context_switch(void)
=20
 #ifdef CONFIG_PV
     /* Prefetch the VMCB if we expect to use it later in the context switc=
h */
-    if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
+    if ( cpu_has_svm && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
         svm_load_segs_prefetch();
 #endif
=20
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 57d09e02ed0f..330103ddf386 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -160,7 +160,7 @@ static int __init cf_check hvm_enable(void)
=20
     if ( cpu_has_vmx )
         fns =3D start_vmx();
-    else if ( using_svm() )
+    else if ( cpu_has_svm )
         fns =3D start_svm();
=20
     if ( fns )
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index c6329ba2e51a..d895a738448c 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -157,7 +157,7 @@ static int __init cf_check nestedhvm_setup(void)
      */
     if ( cpu_has_vmx )
         start_nested_vmx(&hvm_funcs);
-    else if ( using_svm() )
+    else if ( cpu_has_svm )
         start_nested_svm(&hvm_funcs);
=20
     return 0;
diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/a=
sm/cpufeature.h
index f42e95586966..ce7dc1ddad0a 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -165,7 +165,8 @@ static inline bool boot_cpu_has(unsigned int feat)
=20
 /* CPUID level 0x80000001.ecx */
 #define cpu_has_cmp_legacy      boot_cpu_has(X86_FEATURE_CMP_LEGACY)
-#define cpu_has_svm             boot_cpu_has(X86_FEATURE_SVM)
+#define cpu_has_svm             (IS_ENABLED(CONFIG_AMD_SVM) && \
+                                 boot_cpu_has(X86_FEATURE_SVM))
 #define cpu_has_sse4a           boot_cpu_has(X86_FEATURE_SSE4A)
 #define cpu_has_xop             boot_cpu_has(X86_FEATURE_XOP)
 #define cpu_has_skinit          boot_cpu_has(X86_FEATURE_SKINIT)
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/=
hvm/hvm.h
index 0fa9e3c21598..24a7ed88567b 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -383,11 +383,6 @@ int hvm_copy_context_and_params(struct domain *dst, st=
ruct domain *src);
=20
 int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value);
=20
-static inline bool using_svm(void)
-{
-    return IS_ENABLED(CONFIG_AMD_SVM) && cpu_has_svm;
-}
-
 #ifdef CONFIG_HVM
=20
 #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 10:56:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 10:56:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124624.1466899 (Exim 4.92)
	(envelope-from )
	id 1uyTLo-0005Qw-NS; Tue, 16 Sep 2025 10:55:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124624.1466899; Tue, 16 Sep 2025 10:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyTLo-0005Qp-JS; Tue, 16 Sep 2025 10:55:56 +0000
Received: by outflank-mailman (input) for mailman id 1124624;
 Tue, 16 Sep 2025 10:55: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 1uyTLn-0005Qj-1J
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 10:55:55 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b7004f1e-92eb-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 12:55:53 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AM7PR03MB6418.eurprd03.prod.outlook.com (2603:10a6:20b:1be::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 16 Sep
 2025 10:55:51 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 10:55: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: b7004f1e-92eb-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zUGMLzTyGjwok8m7O9nuKgs/Svthsm3ISTvQbYhl+OkUCKHFuBUdo1gk843rSy/o3Emq1/hAbunNunRlC7glfEUzH6Oc9SZGGvfMRk0JCg1IETTC+t/bIxaE8p15nyDX0cHaQffbW2vAo7C6IvS6Bv7Pfcxb+E4ionFNDgVHBURheM6GHgiKUJxURdBsQLzBB1EiW0h2wWKE1Tt7zvyzMnioWUrcI8e+Z7PrOspHgrbzoQOeE9dEM373vWuO84BFWCPQUg9x+vVh/W4YYaFS0zjbfhf5oPEL81vRJ9wg1cUMTT3IrAX3IthmbN3yx9g3DsPCFja1AHSTjsWvgykNRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QawKr7LjBAp+OlI6uqGWIkXkO+C1u8qxqlumOft6VDg=;
 b=VKy6f8qCOvbg6PDNOeUh9c+ebXDLDu1unQ4tY28QNptswsg6sNUkQCPNAm44jrZHw7Dk7ypAI8OwPoGmEv9V+XZO5fyWpoTj/QiZRazSL91cj4DFsMlEDDzx++xT2QSOAMJ4PwO9oFtBMj8QougcvI/yPuU5bi9EGMEeXjaZHsjz+5GB8MU7NcS/HhfPEVlT5NRJrddgsHIr8RN6sPl8sWyg/osb0Rcz5KWz5MBijkN7zHIgrtQeRrsEpdSrKj3RZZ9Tm7qx9ymZsmr2B+r3X+3UPawC6VUtF8Mv+ydPkLjAuFQqrtfL3dM91iPO/IZaz6keBwyeYZmbeA5to2LQjA==
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=QawKr7LjBAp+OlI6uqGWIkXkO+C1u8qxqlumOft6VDg=;
 b=FxNx5LQMxO6E1UCp/NGy/n1+46YHPP5ywG2CCoedV2/wrCeEOGjSeFRuh2IR/iYoG9WXhAZTi/LHKGEKW1yD47h2hwEbrio2UAq9AN3BS9c+PooCDicAboqkCrAYOEVXeLtjAMvN4kiuBffnPpfiH2XDiP3sIdREKX2xsF/7JI7QKsPFS3GUjQebos7iL5IVeUjS1Roj4221kMCEzPM5RJUw3oo+NrgA0/0nHgm50XT0RuGMvR5290E7ih408e9Ek0vRu/KwQJgFGLCME/4cW4l/o7B0kx1cidkN+Rl1KPeJ80GkqDEM/ee6nXqYFV/+ZWj0cLYas0d6wOd8VDgIIQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Tue, 16 Sep 2025 13:55:39 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Michal Orzel ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0286.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e7::13) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AM7PR03MB6418:EE_
X-MS-Office365-Filtering-Correlation-Id: 42f0a16d-f71c-435d-8222-08ddf50f99b1
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?bDR0aURpbzlWTkpCUXNVcGVGUGttWTZuM04wV2tDVGF5YS83MEl4UTdidW1p?=
 =?utf-8?B?WVNxODFQY2dmdGdaZjl1S3M4NXJEMHZOTVQvYm9UbVJ5SGxjNXlYTit1VlZ5?=
 =?utf-8?B?MzRBZDRhb1RUZVNnTi9TMjdFdTlqZk5OV1laTnNEcmpFdWM4NnV4cnpodXJp?=
 =?utf-8?B?TWwrdnV5RmFCWllJYzcyR0svSWlGQVJCRElnUjczbWVrNFQwdjhLck1ZQjdI?=
 =?utf-8?B?TkhnQzdiNkd5YThxZnBLa0F2ajJodS8vTGozczRtZzcwdjE1Wm83VFF5WXht?=
 =?utf-8?B?YjZTUWFBQWhEM3IrcWpvS29zNFpTOGJyTFQ4dnFSUjNWNjRGd0R2RkpXWjJr?=
 =?utf-8?B?di9QL0M1cUhpU0h5TE51UmNMa1Z2aFZ0d1JPRWJ1YU1XMmNzZG1HWndxR3kr?=
 =?utf-8?B?bDZUcVhjaWJlMVZDTXZWVDFEVWx6SHU5OEhkK01iQXRBcjd5WFl2R0w5ZytL?=
 =?utf-8?B?Qm02Q1ZZb2JFYWI0S1RzaU1mdWtWY3dxOWRueVh0MlltZldiMVFvL0FvZ2Rs?=
 =?utf-8?B?M0RiTUxDMUZTR1BUYzNFSVR6WEZRZEVVRXFVK2pvRGNQY0hzWXVnanJLeENw?=
 =?utf-8?B?Q2lOeG9ZZlBZcWhUbnplcm9xNFJOTWhFK2JnWTFiNDA1cUNiRThZU1hxODBF?=
 =?utf-8?B?dlZYZWFKWEtTQUxIM2trNTduREhoVnA1R0x2eGlLMFU1YStDZWNwTTB5MFFn?=
 =?utf-8?B?Y041RjVLNDhhWlc1UzZPUFl5dmRQbU4wOENtSXJVWFJwOFpWSm5PN1FZWTNW?=
 =?utf-8?B?OERCcG1QUXZQS1VmMUJGdkpScm1RTnJhdS9kMXhWMm5qT3hnRFovNkRUdjFx?=
 =?utf-8?B?VHBWYmJoSVZjN1hjaVVzNTE2bVJzeVVRNld3dVc1NEhPZy9RMnNBaHg4RXJz?=
 =?utf-8?B?cTUxTTgzRFhQdkZ1dldzdk4vNnhBRTNxTG9BNEJPb3RBVFM5cHc5T1dZLyts?=
 =?utf-8?B?TUd1cDNNL1BvdmlBY2ZPOG5Bbi9oMVo2UFpsZ3dwYWFhWTE3K0tzVkpCZlgv?=
 =?utf-8?B?NEpnNG84Y1h4QzZoRmxIcTFMQ0tqRFpjMk5nRXZ1Ry91aGpTNVF3WWdReXUy?=
 =?utf-8?B?V3FDdXdwVmVFc3lFOTdNcktkSVpJd3NScGowWk9FV2xGeGs3dzBqUklHVnVm?=
 =?utf-8?B?cHNGemFVNDkwUVBUbHpGWEZmK2s3SXBySmVYN1Y4UU1WWXo4T0I5L2ZTR0Fl?=
 =?utf-8?B?cno0bFp0Qmo3UjgwUS9tbnB0LzVrc3JvYTlweGRtcWpOY3Nhd3BwZE8yOWRM?=
 =?utf-8?B?NkU5ZWc1Wmd0c1RaWnB1NjlaaTVId0tJY3RONTVqdUdCdzR1ZlU2NjhCdlNi?=
 =?utf-8?B?Rk43eEdWa0RIT3FhQlhxOEs0T1Z3eEdBWDBnQUhBUmJUdnc2UHI3Tm5LTWxu?=
 =?utf-8?B?b0c4bnoyZzYvNVRMQm5kMTJoQ2pQaXNQT2JoQzY4bzJnMjk0dEt5b2s5QkJT?=
 =?utf-8?B?Kzg2andzSWQvWW1zeVRXVHIyYzMrMmdyS2VMRW55Ti9hL0ppMk1ST3VJS0JY?=
 =?utf-8?B?S014cEtNeFRZZ3VCYWpCOVZJVUg2dlNHTENwR0ZxaU52WDdvbTMyejNVVlox?=
 =?utf-8?B?dW9OV05CVHUrZzBHNU1BMFI1MkhLZ053cVBZVm9yUi9iUFpibjBQQXAyK2c1?=
 =?utf-8?B?K2YrWG53QUNrM0NtR1dUd2J0QjVWYXhvVEEzVWJING1RVUppNVBRWHBRZlA4?=
 =?utf-8?B?OEQwVDlOK1BqTGM3WUV3VFIvaE9Hc2c0Rm1JM3JoNnloQVFmb21mKzdydS9Q?=
 =?utf-8?B?SlhGdldUd1ZEVmxabHpmZkc2cGp3blVqYjhFUjBEVHFSNGVaY2ljcy9QYmo4?=
 =?utf-8?B?ZnJKVnVzVUR1ZkxEZFJJYktsZmNteFc4RDBsQm9DdlFnSFc1S254NGd4M25Y?=
 =?utf-8?B?U1Q3cUNONVBtenVCbSszdzlpQU9vaEx6WmFNWkpKT084WER5Y052OFRlOFFP?=
 =?utf-8?Q?9t0VSgu3bF8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ckZsSnVrNjJQTlpkcUtmWm5Qazg1ZXBjUHhMT1ZoQTFUTzhyMDJmb1pIM1JS?=
 =?utf-8?B?aDFGanRiWlZpZ3llbnI0b1paZWtGYjFscm9NWTVxeEZpci96Y2RWWUJseXhN?=
 =?utf-8?B?VDY4UHlCT0dway8yaXJGRmd1b0Y1ZzhwTU8rRS9obGEyUXl0RUpUUy9ndGRJ?=
 =?utf-8?B?c3Q5YXFSZUg4YzBVcURGNjFrWW9va091QmJKczlQcXVMUGVFNko1Q3ArM1Nj?=
 =?utf-8?B?cU1ubFdoQXlDUWZZaW9lOVZpcXV2MmEwQmVYNS9JTFVoZmlxVFFqaytkcWEx?=
 =?utf-8?B?Skp3SXI4SEZIMHNYM0VpS3JocTVIWFFaWWR1Mm5kWVdxT3kydlpjRThwOURM?=
 =?utf-8?B?TWwyZllaVHlsTXhsbFA2TzI0bVcvMkdkd0VKaEYxUGZIZWR2c005MjNIQkQz?=
 =?utf-8?B?Z3BiRUlYd3VJc1pmc3gyK0txN3RaSXFwbXVyaHh0T05iT2tLbkltL24xejJ1?=
 =?utf-8?B?TkJ3MWlZYWpjTUJTRG1qQUFMNGpvM0tOU2Z3MDEzUXlRNTZLa0p0alNyZGhm?=
 =?utf-8?B?YTRHTURlTjdJVEI0cUtjRTcwRnVzYkZ6aTY2SUhkL3JZSlgybldCdmQzOWNM?=
 =?utf-8?B?d2wyWnZKRmFYQ1d3bC9ITFhycWMrUkc5cU1KNzlHV0czZWszNGxFSTFjWDYx?=
 =?utf-8?B?eG4wMnlBVmhBV0orRWl5NE0wSUVxS3NBeGliajRSM0Z0amg1TFpPYTBBM0o2?=
 =?utf-8?B?b09mZDFPcUNDc0ZOQUEyZ0xqeUtsRjJML01MdnVYZ3psL2x6YW1aK1NMK0tI?=
 =?utf-8?B?TmpXaEVsN1ZOdVR1b0VqY1o3ZmduQ3c5dnQ2bXhDN2tBcVoxd0wvMnFYK3hJ?=
 =?utf-8?B?QUk4TldXR3hvNlBWYlB0bDN4UXJmWWFYWDRxdTVoaDZxaEMrVXBUcnEvVlRr?=
 =?utf-8?B?REdTMmZpb2JhYXNJMEdnZVZ6MG5uYjB3dloxUHliVjBGd1Y5TkE4cXUvd1ln?=
 =?utf-8?B?N09nanJRWXVGcFpLRXhkZUVOdU4wS1pLNDdrc0p6OXpzR0tINHJQRXFpSzhF?=
 =?utf-8?B?V0hmZjJSNXFlMlpIVWNUd3J1NkxxblVkeXJsbjh4S0NIdmpOdU5QYTRlZmRE?=
 =?utf-8?B?QXJLNWNiVS9NM1pqdC9BcEJ3cmplVTk2RExFd0R3eFF4TXlUMjNTeEUra1px?=
 =?utf-8?B?YzkyYUtoYlk4Y3dqcEhKeUgrUWl2Ui90bGo2SzdCNGJ5TUNSSlVWMCtyS3lB?=
 =?utf-8?B?OE5YUVVGZWF2OU9JNzYxTk80cHpBWS9UUlJ5NSt0YnJGZ2s2Z2UyM05CRU04?=
 =?utf-8?B?TDR1cTRlSVpVdjlWRFhSSlZEYzFGOVBDMHpwV3RXTVE2dFZCVVh2R3RMeUY0?=
 =?utf-8?B?K25OdkVEQUZZamJpYTNwWC95RE9DTTFpZURJdko3WmVVS0xoV3U0bmUzbFNZ?=
 =?utf-8?B?WW5nVDRoT0hzaGxQNFVQU0pCTVd6RmNRQlhtUEN0LzFRZys3OFhUU1ExNGVk?=
 =?utf-8?B?TDQ4cW51UTlZSHZEb1FNVmFrek1Jc2Y5UzhZSUx0NzEzME1WRm5ZVlh1cE5z?=
 =?utf-8?B?WlJDN0MzbUhPaHUwbmNkTkR6STZTclF1c2twQjFldlRWQWdWRnF5eXlpM1Ar?=
 =?utf-8?B?emFBN1J2S1NxcERmbytqbS9XMHcwdUxNajkzVkFocFBWKzNaVDdWa0N0YVBJ?=
 =?utf-8?B?UVlQY3VkVzdiM25jUDlNdTFyazJjbDNISGZlZEhMTlNoK0xQM1FsS2ZSbldq?=
 =?utf-8?B?bGVPa1h2aDFZdGlvWnRMMHRxbDlNdmJFcWV4K2t0RC94a2pxTWdDMnpVZE5T?=
 =?utf-8?B?T01OMzF6UHJhMlZOSWltVG1YRTdOMUMyU2lySDlibURud2lqU0JBdWNPbHZh?=
 =?utf-8?B?N0RLQ21zSFU4MkFvVVdqMk90NkRFbGNDQXNFcHdGSThuUW1lMUlGSE1uN0pF?=
 =?utf-8?B?Y052ZVNKZTNrTGZ6STZTYTR3WVFGVjAwR2VMMTV2VnBFZFd2T0gyb0pTVTYz?=
 =?utf-8?B?ekx5dlZMTkpvN092cHpSajFBQnpyUTJaL1hwNDdjZytDUnhYRldXN09neHlR?=
 =?utf-8?B?VjM5TEx3SGJtYzhQeTM3Z3hLejdGOFdxWlpaV2owZjZRRmlsb0dMRXQ0eE5H?=
 =?utf-8?B?VDlTMWRXTmZ1Y0tKZWFCZzFjaE5zOTJ5SGJQTC9aQVhhaXZwWk51WGVYMHEy?=
 =?utf-8?B?bm1qckY2Y2t6T215QkdEbnhhblI0Ulp1SXJXL0tUN0xBc2xuS3ZlZWRyOWJa?=
 =?utf-8?B?Q2c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42f0a16d-f71c-435d-8222-08ddf50f99b1
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2025 10:55:51.0655
 (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: k/tU2yF65mbpRPZbNoiPaeqVRVZoeV95XxhLzcjLWg6XbDv7mTO9DREVMAMxDcGwgHhbGQJXJp3Jgw0WsiwAdVCvT67qQa7LrM+N+wfVH4Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6418

Hi Ayan,

On 12.09.25 20:00, Ayan Kumar Halder wrote:
> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
> Test that Xen is able to generate SGIs.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---
> One of the aim of functional safety is to test hw/sw interface. This means that
> Xen is able to configure the hardware correctly for the desired functionalities.
> 
> Normally this is tested from the VMs. For eg if a VM is able to receive irq, this
> implies that Xen has configured the GICv3 interface 'correctly'. However this is
> a high level (or integration) test which uses not only the GICv3 interface
> between Xen and VM, but the interrupt injection code for Xen to VMs.
> 
> We want to have some kind of unit tests to check that Xen is able to receive
> various interrupts, set priorities, etc. Here, we have written unit tests for
> software generated interrupts (SGIs) as example.
> 
> These tests are expected to be triggered as Xen boots (right after Xen has
> initialised the GICv3 interface ie gicv3_init(). The aim of this test is to
> check whether Xen can trigger SGIs after gicv3_init() is invoked. If so, we can
> claim that gicv3_init() was done properly to be able to trigger SGIs. Likewise
> we will have tests to check for priorities, SPIs, etc.
> 
> A script will parse the logs and claim that Xen is able to trigger SGIs.
> 
>   xen/arch/arm/Kconfig  |  8 ++++++++
>   xen/arch/arm/gic-v3.c |  7 +++++++
>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>   3 files changed, 36 insertions(+)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 950e4452c1..739f99eaa9 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -73,6 +73,14 @@ config GICV3
>   	  Driver for the ARM Generic Interrupt Controller v3.
>   	  If unsure, use the default setting.
>   
> +config GICV3_SELFTEST
> +    bool "GICv3 driver self test"
> +    default n
> +    depends on GICV3
> +    ---help---
> +
> +      Self tests to validate GICV3 driver.
> +
>   config HAS_ITS
>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>           depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 4e6c98bada..eb0c05231c 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>   
>       gicv3_hyp_init();
>   
> +#ifdef CONFIG_GICV3_SELFTEST
> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
> +    send_SGI_self(GIC_SGI_DUMP_STATE);
> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
> +    send_SGI_self(GIC_SGI_MAX);
> +#endif
> +

I'd like to ask, if possible, to minimize mixing selftest and functional code.
Like add gic-v3-selftest.c.

>   out:
>       spin_unlock(&gicv3.lock);
>   
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index d922ea67aa..5cb58cdb92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>        */
>       smp_rmb();
>   
> +#ifdef CONFIG_GICV3_SELFTEST

if (gic_selftest_run)

> +    switch (sgi)
> +    {
> +    case GIC_SGI_EVENT_CHECK:
> +        printk("GIC_SGI_EVENT_CHECK received\n");
> +        break;
> +    case GIC_SGI_DUMP_STATE:
> +        printk("GIC_SGI_DUMP_STATE received\n");
> +        break;
> +    case GIC_SGI_CALL_FUNCTION:
> +        printk("GIC_SGI_CALL_FUNCTION received\n");
> +        break;
> +    case GIC_SGI_MAX:
> +        printk("GIC_SGI_MAX received\n");

	   gic_selftest_done = true;

> +        break;
> +    default:
> +        panic("Unknown SGI triggered\n");
> +        break;
> +    }

Potentially GIC selftest code can be guarded by some "gic_selftest_run/done" vars
if xen boot is expected to proceed further after testing.

> +#else
>       switch (sgi)
>       {
>       case GIC_SGI_EVENT_CHECK:
> @@ -361,6 +381,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>           panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
>           break;
>       }
> +#endif
>   
>       /* Deactivate */
>       gic_hw_ops->deactivate_irq(desc);

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Tue Sep 16 12:45:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 12:45:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124649.1466910 (Exim 4.92)
	(envelope-from )
	id 1uyV3p-0001nG-5C; Tue, 16 Sep 2025 12:45:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124649.1466910; Tue, 16 Sep 2025 12: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 1uyV3p-0001n9-2D; Tue, 16 Sep 2025 12:45:29 +0000
Received: by outflank-mailman (input) for mailman id 1124649;
 Tue, 16 Sep 2025 12: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 1uyV3n-0001n2-T8
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 12:45:28 +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 04354fd1-92fb-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 14:45:25 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by AM0PR03MB6163.eurprd03.prod.outlook.com (2603:10a6:20b:151::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Tue, 16 Sep
 2025 12:45:23 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 12:45: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: 04354fd1-92fb-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oJ+LhB7yoHFCBWDrO2GttJbrg7hLB45xz2as+yjLTnk6OpjHb3cDg9W73KGe6rWJ2kfNVBW2Bw7xyEXWlrsula/OBSRlb3cP13FL09QWZStAmeJJIjgtiwxJSMvZ5lcyjQdlO6HiFaJrkFueE7ggxwEVVUmJo0AO+w1BK0bE12JuY9GMkeBhtP7C4OCKGSccU3UJjO6VXMYNEREFxQ2gvpTWpY7P9orS3yikVJxxe8NXwfUv+7nXhN+lBemCiT1WhWbziSI2nYELaGEhuYynNUNRiKVPDQmBommTqCJFvdN+56l0UEeMXs1CGreQeKVAmxjjQit6h5werlKcmPdT+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W6XoUttgMRb6pOjMwWhbuAvhXm2rApd18bfiIb1FoJA=;
 b=OaVc0jI0LmwDZNVrVRWJFN2q5hH09jeIxE05AgraRGXGTdwCScU+xJ6eSSExBFN/oPUI2Gi18oJ9op0a/01bL9vCA9/XHmQsjga9410Aiq1/XjnlNXe3r7YGGHyIdYgTD+2ltjFK5WBJjNO+lFAXYVVTCyGvcnngQwAJ5e60Q6HO1fQ0qtUx2G7lXrVGyIVYRlUKWJMzTy3G2ZcBrHLsyOt7m7EV1Tkc8DqsY5hkeEF2CCIVeQQLf1862B9nQKObdJ6htaaAr5cBQ8DUEQsCV7TNsTfDN3SpOhqYGkcLwYyCIAJbtqaT0/IrU4rnSXp+l5+E2W7rPGzbfGHQsIzt/A==
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=W6XoUttgMRb6pOjMwWhbuAvhXm2rApd18bfiIb1FoJA=;
 b=jZQXhvY///RvPJatItir2TkMbYi+9wz4FUfxOMW2D+/+iussgvyf0t1f03fjhpXGri/2EuKdJOHx3C1MfT660evTl8P8sk2wL/D45imelP0z8CcxVYK3qJ0N7W+h8AN5uRsBAHfNIepIuax5awq10+9GvnPIFzkO3c3ztfbgbAO/P2wFub41eAvd8twtl7Df2IH4L2VrY7tytIYVRBFY7c/EhraRPP3wE9g0kUkHtjo1SaDh8gEwCBurrRKGTiMwQwRV3jzZrcQq1skYVog39mKG7ZDdHfySuzywgYfZWSkVOSUBflubp6TCGVOJ5PTJ+lKUKfkfkcGlMo42Y54iSQ==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Nicola Vetrini
	, Doug Goldstein , Stefano
 Stabellini , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	
Subject: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Topic: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Index: AQHcJwfEWjVU7vF+102YDgRq9OEY7w==
Date: Tue, 16 Sep 2025 12:45:22 +0000
Message-ID:
 <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.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: GV2PR03MB9572:EE_|AM0PR03MB6163:EE_
x-ms-office365-filtering-correlation-id: 742b2fd4-650f-49a0-ddb9-08ddf51ee6dc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|366016|376014|42112799006|1800799024|38070700021|13003099007;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?YAGb7eCK3dfVW3eClyiSEJkdHYhYRI8gdgO3pUo06ELCxb8At42UjcKny1?=
 =?iso-8859-1?Q?vDFWvD4THtEd495lJNtAcMSWh3C+sRAmgiJQlCMAxmLQRZNavXEKyH6CX1?=
 =?iso-8859-1?Q?XjYoozwYh6u6AsCWYKzT4lRRJTx7ibj7PTK45ajcLSWw+X5nLj9DkOiELz?=
 =?iso-8859-1?Q?OheLsV3GBJwX3F1aLAsasL3Gp7vjHyHdQcex3ZjipU5TB7+0Ne2KtfGzPC?=
 =?iso-8859-1?Q?gYjw626UhJ0qPxiF/vsbXF1CanG5laSW8AOpbgt/u+2iXmjH4V/n6R8ZEq?=
 =?iso-8859-1?Q?tRLwkknhjbjBo20EkZPaEuYqDTo/5Bc5Z+HtwTgKAESaTrvasgZ2BO03ef?=
 =?iso-8859-1?Q?1EWhTzmuhgh3X2Zn2VC6Jz3EwKdhC73XJUjM8fuID/aeU3CqKuwi7cVPBN?=
 =?iso-8859-1?Q?IrNtfGRX6pCxddsn/E6J61W3fcbVERCf/d7R+WweU8fMiyxx+NELu4ZGEW?=
 =?iso-8859-1?Q?JSqbyn0s0CGxnXiA0on8llpbWAPfISe7eJjbuBbXCAJlqb1hQmxktPPJLu?=
 =?iso-8859-1?Q?NKgm3vy7UDkROmEDuxfwDC2nRFYFWgmFk/HWgim33lfVVDgl2Wex0tVMMb?=
 =?iso-8859-1?Q?8LnrxmiRJnqpSg2whyvHOAnUGTTGL0VLt983DZnJ+T0VC7WwUS0It3kahp?=
 =?iso-8859-1?Q?FiukwsLI3PeUeeLecup41s9jsZotIH/9px3PUAD34PPBwSyuAVZykB3Xgq?=
 =?iso-8859-1?Q?bVv4kHDssbqjemRY9sZJvdVn4IML8UY6aM0ykZ6JLwXBUuhF9PR0rGrHeN?=
 =?iso-8859-1?Q?IF/QMmXwmPsoLoH0GgmDE8UG3g0cDLvam3W/LOjngq5AxRfPDKI3krk+wj?=
 =?iso-8859-1?Q?R+pqyWmT5ljEqIKfJ5HlQ5xyQaIHD2I9EO0OoRArr45ZwDkBzlfZiqolU/?=
 =?iso-8859-1?Q?kIuV0sH1DjeG/QPiE8t5ycdqyMbPgCu1zU6QaUiMAS3VElymHlc+WtDw6Y?=
 =?iso-8859-1?Q?VI8zqFC7LB82igMRyPZkMzINOltXUQn7BEX9C4knD4BoHUDCrZncgUaDUq?=
 =?iso-8859-1?Q?/zURFpO/ptntl5hL2mGMyHn6W1VI48cf2C6VcH6E3voKM27e7Ho9XoPaG9?=
 =?iso-8859-1?Q?uS7lqKpLZq3TsLd32/0VooxpZQLYy0i3ALDUHosilwnAaBCUOOJeA5fUmR?=
 =?iso-8859-1?Q?ci2RzcQPYt25F2hQ/83UtOoo4eRHTBszl812RAn8vD+bl3L/SNVGfzLfck?=
 =?iso-8859-1?Q?ECNvjiG+128LXltnPd1Q0ssMLUZc4L9kj9/qKmGdyNNp7MnymLqgxFwhrd?=
 =?iso-8859-1?Q?YT6cqvreU31f3k9kyyltwnKWGyUjWrKJMGmNfpv5Bt9/TkvDfqyd23vpYW?=
 =?iso-8859-1?Q?23tgL0SLVCjk2TyREJnpjcKz8UOWlFerRZivZAFdXm/pf7ORc5BfUhCQEr?=
 =?iso-8859-1?Q?ToMeJN6gT/RD5W4sApAeW2dwjgJXgWZpQjOtMyswIqXEi3iidncXL0kCzg?=
 =?iso-8859-1?Q?FAc0dXFZLNeZ36ARpheT6kt413zyBXTgUpQ4m65Bq9bgoCJhv9OfKtF7mK?=
 =?iso-8859-1?Q?0=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(366016)(376014)(42112799006)(1800799024)(38070700021)(13003099007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?ixd3aZ4pRHUcJRaKkAnpTaVdnw4LHqeTXhIDTDefx8w0LF4xQzn8hgMBSX?=
 =?iso-8859-1?Q?4FcPLbyv309pxPiuI5d1pm76A95mvWMSlnjBGV1yN0nYgyGY7vPn9MOp5p?=
 =?iso-8859-1?Q?mWxP9Og0zllrU7rMGSw8Ykkp+RA4DaA+nF1SyVJIkNkLTGdxzUSp5xAjc8?=
 =?iso-8859-1?Q?ZSsPZxwDgF+WiT49ZGxGJ66gJ56Lpb2Azxg3WeF0HxDahBNjfvphmmV2oh?=
 =?iso-8859-1?Q?pnG55jHVrddf+IuI5qGT1ljzRbs2ECGJeyzya1qtvAQOUbGqwdvmFB6Op3?=
 =?iso-8859-1?Q?gabDgqiZ43nLHqYZjRuOtrvZrxqT+HgfxOsVwtovWX7hAJv6QNRGzQT48t?=
 =?iso-8859-1?Q?hDgUfFeHDeXE/Vjz+wOEZeCTYjMhzpACBoJGcHYbYE9fafOLvoBtbi2V6j?=
 =?iso-8859-1?Q?ykrW9RWbz6sg1RRYtClRTmEHs7DEdMzbObhIHzbEJT3UUFDI4YyDS2k7w5?=
 =?iso-8859-1?Q?tK+9TnNFjub4AsGULhUt/lURobG4bRupHfWNyq0BOruY3X0D65vFVwAKa8?=
 =?iso-8859-1?Q?MyYKNeDFk057U41151KevMGb3GSWGB/QM8u8kdvp6yJSISkdU9cVjXwqOK?=
 =?iso-8859-1?Q?TyQCPqtRxOltaqo3KiTOCmE1QqHzbPz33i01dd/ImhWf0oo0xzZEa0U1ES?=
 =?iso-8859-1?Q?eu6+xwiXsmPSPbgjzC4v/9p5tROXM6wsn647pc/szJ8h0NW8XiZCdHvig4?=
 =?iso-8859-1?Q?IVm2c6rafHKBNob3D1XN1KoYNSvF/lpb02P85osh+Vhi9USr4fdCxMfdYo?=
 =?iso-8859-1?Q?xPl/RrYFDDuT2CYOEShms4nlSk1veyXZf37QviD4B+vpBeP6bWPFyYnEEj?=
 =?iso-8859-1?Q?kXx6qMfLGwG19jchs1PIb1Cms5BgGolY1MoYkB2LOvCaHdmDkgwTmCFwyJ?=
 =?iso-8859-1?Q?LDs3HAXD9wc1z7mZyv3VvhRZtfaX4oY+gwcSRArpQBkg0bibsBZ9hxIYFr?=
 =?iso-8859-1?Q?elfR9zQdTyNLnC4PRuG9vCauYAMEbLFcEP8AVLLYpVDR/VY7cAIxf+aOij?=
 =?iso-8859-1?Q?sbD1zppzko/tMykRu5arcKcCixMM53I+aHd69OTROb8ezF0HW9mRahj+m+?=
 =?iso-8859-1?Q?LNW2jV7m1sdu+EgXM+Rn1tSirdF27iYIYOdvMVSzHib3HIap5VA8MfOh+6?=
 =?iso-8859-1?Q?F8kyTP9EnBX8BsaY8llD5ESRugScIX7GvJI5E/j6JI54oI9rB3QykOgzTc?=
 =?iso-8859-1?Q?nXpFeOdXBQuc1qygGfpS9IosPh61lQO7O2JZQlpKv3pnH2hu9tJEzEdzxA?=
 =?iso-8859-1?Q?nYWlcxSa8AEk6xQO5KewD1W013kG1HoDz+d9kAfkDjOV5xZ57mTOR7C8Gp?=
 =?iso-8859-1?Q?Kzt/jBABD76nL0DLvCP2w8YssqGdfyvNj1losFZh4aoTCBCL58IVf8fAYZ?=
 =?iso-8859-1?Q?r3rnSDA1gHT02Bq6f4ZLFNfobGFeSq0zrt71aftMWA4/8v1QJi1tG8xRkU?=
 =?iso-8859-1?Q?zwcL/MTGGnLnXnd0NmRaKZXz9Abf3c1ggUcHLDB8daBywwrJw6DQymkzQw?=
 =?iso-8859-1?Q?Ge8horKy6chm/0PGQa216MNuq0W1/2nTv3NMfK3rRFAxUQFv1cZC5LrsLE?=
 =?iso-8859-1?Q?EtnkztlBYIStSdFO507Ohn2kwxgfdCFlV8EfpNDxBe7S7cJGLKUJa3DO78?=
 =?iso-8859-1?Q?9yIMqMGXlulpcY4bNx3NR8N0nN4slrcz4zgrIfNQJuMs0H1pVeWFjyUQ?=
 =?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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 742b2fd4-650f-49a0-ddb9-08ddf51ee6dc
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2025 12:45:22.7472
 (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: A7csYRwZ7Rtgx9PBnCc5AE8qEUr0O3NhjFQ+zjSi7X0LzDWQANMjJoIvYCBFeMtrRpW74EFFd+QxGCTbvb4eSWHw618upwMKOzfOlBY0Nck=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB6163

MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the 'noreturn' attribute are considered a violation of this rule.

In certain cases, some functions might be non-returning in specific build
configurations due to call to '__builtin_unreachable()' in the expansion
of the macro 'BUG()':
 - functions 'gicv3_do_LPI()' and 'gicv3_its_setup_collection()' when the
config CONFIG_HAS_ITS is not defined, it is intentionally used to catch
and prevent any unintended execution of code that should only run when
ITS is available;
 - function 'prepare_acpi()' when the config CONFIG_ACPI is not defined,
to trigger an error if ACPI-related features are used incorrectly.

Although these functions are defined as 'static inline' and the compiler
may remove them from the object if they are not called (e.g., during Dead
Code Elimination (DCE)), they are still present after preprocessing and
are analyzed by the Eclair tool (regardless of whether this code is later
removed by the compiler). This is what causes Eclair to detect these rule
violations.

To account for that in specific builds, update the ECLAIR configuration
to deviate these violations. Update deviations.rst file accordingly.
No functional changes.

Signed-off-by: Dmytro Prokopchuk 
---
Changes in v2:
- updated commit message (added explanation why the Eclair detects these
  violations)
- aligned Eclair configs with deviations wordings (explicit specify header
  file and function 'static inline' attributes)

Link to v1:
https://patchew.org/Xen/f7b4112aad84162c25f96a9d6db43a0c2ba85daa.1756046023=
.git.dmytro._5Fprokopchuk1@epam.com/

Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2042397534
---
 .../eclair_analysis/ECLAIR/deviations.ecl       | 12 ++++++++++++
 docs/misra/deviations.rst                       | 17 +++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/=
eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..c10dbf4f26 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -41,6 +41,18 @@ not executable, and therefore it is safe for them to be =
unreachable."
 -call_properties+=3D{"name(__builtin_unreachable)&&stmt(begin(any_exp(macr=
o(name(ASSERT_UNREACHABLE)))))", {"noreturn(false)"}}
 -doc_end
=20
+-doc_begin=3D"In the specific build configuration (when the config CONFIG_=
ACPI is not defined) the 'BUG()' macro is intentionally
+used in the 'prepare_acpi()' function defined as 'static inline' in the he=
ader file 'xen/arch/arm/include/asm/domain_build.h'
+to trigger a runtime error if ACPI-related features are used incorrectly."
+-config=3DMC3A2.R2.1,reports+=3D{deliberate, "any_area(any_loc(file(^xen/a=
rch/arm/include/asm/domain_build\\.h$))&&context(name(prepare_acpi)&&writte=
n_inline()&&written_storage(static)))"}
+-doc_end
+
+-doc_begin=3D"In the specific build configuration (when the config CONFIG_=
HAS_ITS is not defined) the 'BUG()' macro is intentionally
+used in the 'gicv3_do_LPI()' and 'gicv3_its_setup_collection()' functions =
defined as 'static inline' in the header file 'xen/arch/arm/include/asm/gic=
_v3_its.h'
+to catch and prevent any unintended execution of code that should only run=
 when ITS is available."
+-config=3DMC3A2.R2.1,reports+=3D{deliberate, "any_area(any_loc(file(^xen/a=
rch/arm/include/asm/gic_v3_its\\.h$))&&context(name(gicv3_do_LPI||gicv3_its=
_setup_collection)&&written_inline()&&written_storage(static)))"}
+-doc_end
+
 -doc_begin=3D"Proving compliance with respect to Rule 2.2 is generally imp=
ossible:
 see https://arxiv.org/abs/2212.13933 for details. Moreover, peer review gi=
ves us
 confidence that no evidence of errors in the program's logic has been miss=
ed due
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 3271317206..45f665d5e3 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
        even when debug-only assertions like `ASSERT_UNREACHABLE()` are rem=
oved.
      - ECLAIR has been configured to ignore those statements.
=20
+   * - R2.1
+     - In the specific build configuration (when the config CONFIG_ACPI is=
 not
+       defined) the 'BUG()' macro is intentionally used in the 'prepare_ac=
pi()'
+       function in the header file 'xen/arch/arm/include/asm/domain_build.=
h'
+       defined as 'static inline' to trigger a runtime error if ACPI-relat=
ed
+       features are used incorrectly.
+     - Tagged as `deliberate` for ECLAIR.
+
+   * - R2.1
+     - In the specific build configuration (when the config CONFIG_HAS_ITS=
 is not
+       defined) the 'BUG()' macro is intentionally used in the 'gicv3_do_L=
PI()'
+       and 'gicv3_its_setup_collection()' functions defined as 'static inl=
ine'
+       in the header file 'xen/arch/arm/include/asm/gic_v3_its.h' to catch=
 and
+       prevent any unintended execution of code that should only run when =
ITS is
+       available.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R2.2
      - Proving compliance with respect to Rule 2.2 is generally impossible=
:
        see ``_ for details. Moreover, pe=
er
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 13:41:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 13:41:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124660.1466920 (Exim 4.92)
	(envelope-from )
	id 1uyVvv-0000TB-4D; Tue, 16 Sep 2025 13:41:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124660.1466920; Tue, 16 Sep 2025 13:41: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 1uyVvv-0000T4-17; Tue, 16 Sep 2025 13:41:23 +0000
Received: by outflank-mailman (input) for mailman id 1124660;
 Tue, 16 Sep 2025 13:41:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uyVvt-0000Sy-CY
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 13:41:21 +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 d3937680-9302-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 15:41:20 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AM9PR03MB8056.eurprd03.prod.outlook.com (2603:10a6:20b:412::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Tue, 16 Sep
 2025 13:41:16 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 13:41: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: d3937680-9302-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=st8JHsIbVdYGuyoOdrFhdQenTt0sp1LPGKB8Yag+uJovIaFHesY0eFz60FSKFcRSjcgZVzAMguAb8teyKnkJLMaNAfafH4KcIINlhLVHthaQc+JSUr0k3+z1qrnNMRJvaS1jqtHRo+5Y6rGzLR5RhAwbhB+WBw4soS6oOtZR9dcExpXjjA+fKrbn+5M3N3mZugVpmVZtX1DckiIOiA8tygo0F16UtpxsixjOPd4tgqO+SlqZOQMmBP7pcCIpD5IALmvNU0o5wT/SuZy7bOHr4RRra1csry6L+yyDBQ71drQqo5g9dj3+d373RGzOwigyxVxMRUaJzJOEtnbquY5WFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RLpF1mnMF2e6pzGWDziI1N7zYaog8WbysndvDk8Wg50=;
 b=GEPdhNHuC8cDYeeRgWgO0Xyj4k0TIQn7rI3EzUU53Wn4GAUn4LmSNbL4V6aDw3+r+r+gB5e0w2hwpqV8Yj8nCDdMTtOQRyoGyHKjImOCmGM6Tvy2XXBWaLXiMdyEb930ZjbKYD9fgjL0EuEacvfliPUPzVNB0efmF4C3pPRQFtRPDvPlLGdnjHydaiPnLmhJMxhJ40FmtpSQTBCxgqfjkXgu7VFG+7xsN7AyeWqMy4sA5Av7K7BYuy2M2tgzd2uXO+kKbfAlxi5a0OCD9XrapQSDfexIWvADZWzIB3u3EZj6YnhifLW9NyM2Tb+o7Z5Dvoe7n8vtOTaKFrb2kCv4Vg==
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=RLpF1mnMF2e6pzGWDziI1N7zYaog8WbysndvDk8Wg50=;
 b=BG9ph+wvDRntMgJPfy61EtN0ZEvEPQqi63FV+qpHUSPeYT8LHuHWxgL5ghRqZ+j/eKW0OJ8Phz934fWZfRtkSI6rFtRIw2kjwGUvB8H1cN/VvTV7yUOt+cbVOy7AD1kWqAHbfwYJsbUFCxTATqbEfYSwweDRUVlFYzAgmQ5QsuBPuxN0pj5af/70EP2AnhJYDvtY2IQ7B0vU3DNl8N0yRLHG60I67Hdx12ymTffQJLsOPOdvNN3o7VpTpcH2EY9YcznK1TtyUsB+jqQFxAlIloXe4zYPLyUBpCttIwFLJP2NqPrHAVlm4nLuRByIr0NPeZh7YKHKMYGyCYhoHBOhjg==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Sergiy Kibrik , Jan Beulich ,
	Andrew Cooper , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Paul Durrant , Alejandro Vallejo
	, Grygorii Strashko
	
Subject: [XEN][PATCH v3] x86: make Viridian support optional
Thread-Topic: [XEN][PATCH v3] x86: make Viridian support optional
Thread-Index: AQHcJw+TXHcbPb3jhkSvBimN3GcHkg==
Date: Tue, 16 Sep 2025 13:41:15 +0000
Message-ID: <20250916134114.2214104-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AM9PR03MB8056:EE_
x-ms-office365-filtering-correlation-id: bd601bbd-85ed-4540-84bd-08ddf526b5c3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?7fQCUZ9KLLcoDZh5SkGrEZOIzde2l0jykqnwpQyfVP/nwephyHNYrlfbUL?=
 =?iso-8859-1?Q?X4F63EL7ctRx+0sEEtNFm48NnK7O3nPNS0JM3lkcQ2SvxA+rlDsp2n1F86?=
 =?iso-8859-1?Q?MtmLr3zDbcgga7iNU+7/+I6RTCxBLKVVQSDuM5bqMzcjqsa50dHhayBd0/?=
 =?iso-8859-1?Q?WdjGwL3g5amDOhymKVD6AVBNAO04CHQFWt81Ug/iDZ898vPxFXK65L6JPh?=
 =?iso-8859-1?Q?tYe+5rfCJfK7iWGSWzU3mpMgXB0gEVNSFKtzGeC3As8wF8+CoYgs62D2C1?=
 =?iso-8859-1?Q?JiLwYHCZ3OBXH8dTxjvitg/ChpA5XnLg2JHhmOdNymZFmKGCzFs2B0tGuP?=
 =?iso-8859-1?Q?A7tzYLMJaoyycTYx+e3sANj/WMJXmq17RKXZoahOIXbc4Yi2TCFh1/eTHY?=
 =?iso-8859-1?Q?Nwqet76BmpFJsPF3nXVDX7Bc8DRAX+chYl/cB4XUeAmCeIO7/L4cgfzMXg?=
 =?iso-8859-1?Q?S93cb14MTt/k/RVrRhmnd64fvO3/7b4O1CBzoNmFYDrDy5Dxv+bYBLAwmI?=
 =?iso-8859-1?Q?23PBowa2KwskcTQOApTycqXmfBYJb/A/7FkafM811zPyCLOAAGb7ZxoYew?=
 =?iso-8859-1?Q?ovVe4RGitP/YbNLLTZ1TS9hsflbYo8LmHl9ul7xmwlaE/3AMVoBdvfGuZC?=
 =?iso-8859-1?Q?ZfV4EnvpPYI8jvguIW+whkMqlDXxAOBQLzdAwExG21Q4B0qWHeyiRjzKbJ?=
 =?iso-8859-1?Q?aucoQMDVL4CG6yVhRl7IV/XsHanB2GcaecBeJ4koRWNZaKx1nG9rb7K4sI?=
 =?iso-8859-1?Q?6ubsaJhr7ehAoXqrhr4eilL6BOfOyr2SRz7Rn0Ab3+hDwLltDMyQhG4BRZ?=
 =?iso-8859-1?Q?VBxo6h4jeKGAWxj/laxxSvjH6OAJTouZikpmYdqiRQZ54wQa1VmhH38XHN?=
 =?iso-8859-1?Q?J/L4CB/Qk1gVic+Im7juaKRXlh6mM2Q0dE/fS3ntr4GwR1u4Hjnu0f+woe?=
 =?iso-8859-1?Q?Kz8mAo9ChnwqaOUnVAK3u0HE7NoGrVwv5jwIYsFfb0qEqy+ZaKnxJhP76k?=
 =?iso-8859-1?Q?rkopcHP/Gq2cAGLoXetrPP0E2Of3DABV+sszInJ0FYfp9dEfjp3M0Dhbso?=
 =?iso-8859-1?Q?jglPgdi1tjh3OEzlyk2jWMPU4kW18BtqaENkCLVywvF75Tr+ZaFl8FrFNQ?=
 =?iso-8859-1?Q?TSls+PfM8zGYbT2+Zyiu22PpB3mibP3tcLzguwP8ysx75w1KMoLGbQVEmL?=
 =?iso-8859-1?Q?qbdIZNwZjCtzODDorv65xeq0mpGgHGBVhxbcyTpv3NC+C/K6xsPVJcvwjz?=
 =?iso-8859-1?Q?NWmkhT5m02Qqb7bpWJdSxRvNTiK+Aajleewpdf4v9tMzvq5mgj1+juv8Vs?=
 =?iso-8859-1?Q?IFj4GKtcbSy91HNQ0vmPZRD33F+KlcNx0fLvO6kJTsNgT7mD/D4ILSJpTl?=
 =?iso-8859-1?Q?DnnZbpjD26cNmndzLC/YuV5aujwAF2poMBHDdxd3a/uyWV4oRgU4shSLy4?=
 =?iso-8859-1?Q?26CFFgzekb6lC+wbmfwQCX3ifN+ADviDeQPWaZ9XS0FYy1JS8qqsTNDYTG?=
 =?iso-8859-1?Q?xFVM1Slto9DGvLGGm4xcJ0PKZW6mm7Zht/6BRCjcezFA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?P1qOY2TxD5w1HzxiscFLGnP50K0d3d5vrMpAEVPmcI04RI8M593DhxNzuI?=
 =?iso-8859-1?Q?YaKIDgtXBQgdlymzqJq8tiPaqYigDaDSaMa5I/abewhSjza7LsA2gbeN7r?=
 =?iso-8859-1?Q?8wMXs4MhxYC5Ezl8ggSmKKsODUPdA9wKT7D1KpU+bLY+KlJN2lGQq1BFH3?=
 =?iso-8859-1?Q?oChGGkUTJzkbix/REdlPCiZDNNKzbxKoJTHakQySLK08LtPSe1b/mG2mjr?=
 =?iso-8859-1?Q?6xkbTs7epIPwIkLz+AfpbB/F2HtfijxEwItiEt8bgxN39UHzI1Uk0iPI3b?=
 =?iso-8859-1?Q?1Tyme4Q0WZvG0eZ8i/bRzBQ7iucCP5WpNRiY7+5LIBDYeGAZMaMO3B3mL7?=
 =?iso-8859-1?Q?1shSezDURUhvwYaILREU+6yDDqoFmvUv3NTHGRTpeoNrQhwonC02DtZ6z+?=
 =?iso-8859-1?Q?wn8NtLeQ6nQh9Bf2W4ik/yduqB0KrFXQb3bJvTBBY/F2EQDcLvuC9v/DPq?=
 =?iso-8859-1?Q?I+ltVy1o72CWVzazNGEkFuU/hJhcZgogFTO8gFNiQyNfu9le0rH5phO43S?=
 =?iso-8859-1?Q?873Sd+sdoJ1KpmY/I55nCy8u0KopCH03i7GAv76hwU4w+HLJiv659X0zDT?=
 =?iso-8859-1?Q?K5YOLYRNDiPUxzhUiiUjiXcIzry1QCtCNpCoZbjKcQ97MOHVg5eLp1p9jq?=
 =?iso-8859-1?Q?W28EPMdrKbQtkifWl1LoBOkT991Mlm/Jx9dKn2l4Fv82KvBrjeza8ojjfO?=
 =?iso-8859-1?Q?1ham0GWSSIMnI1Z6cnz+bwU7+YZQLtNI48IXE4UsiSgwJPyvK8OohQ2zFb?=
 =?iso-8859-1?Q?O0UW3iCSD05GDU0PIMlOdzLH097gUM7JTFweW5ZjdQqZz606p1qnBm2tOB?=
 =?iso-8859-1?Q?JrSmTyWAtYZ+/kF2H9+JZxIJvJINCN9J3Ft32eCa/dH8exlbEdlVq+rFbj?=
 =?iso-8859-1?Q?AkwpIjDg+esF8BPEw4bAOssZrpSFYioAuf70wg/oZXg7CfgBsEriFz3Qwi?=
 =?iso-8859-1?Q?BAlPaYVbEVkqdiQYAgMFWSl4gbHDtAtV++vPqQT6DHhgfcMbee3l0LQJTs?=
 =?iso-8859-1?Q?2yOp4ywCp8qKyoMDSsKcqfSH6tVytT0QYOw6XPjFIrL6WknXDi/bW6803X?=
 =?iso-8859-1?Q?V2wWp01+/abQwYY/2KudPg25SVL2uzSDKlcyHq6Y9/3t1sV5Fi7nXe5yzg?=
 =?iso-8859-1?Q?n6EKQJzfkzlCqgwjQvAx2Zk3oXwbBczoo6SZ9tNO6dPltVm0fwYbVvoWjR?=
 =?iso-8859-1?Q?vuNWtYfhQJRW6zA1lWP7Ot6S0VbLkSOGQndWejjKVbGzL7n3E9zrY1og8r?=
 =?iso-8859-1?Q?H0o4uvOJd5w++3qH1+1BuUcd/nMeKOjqGZ4Li/NQFhOUC7SSaqmI3soozy?=
 =?iso-8859-1?Q?MFR7imy/wQmVL9fDloDqgpOK1CGAFnH4ZeAqmf42m+TS4EerQBx/g/qT8X?=
 =?iso-8859-1?Q?eSwHg2JM6iAgBwnScmWhDZL5JH2cQssUFuK7C/wmcVDbPj6lJCCnI4GtnA?=
 =?iso-8859-1?Q?4YEDVrR/pqL1suEtAAMhtDPJTLPikakV0O9LUdgufLI8BLX2lB5jyuEniN?=
 =?iso-8859-1?Q?J3kGouvjC+X08c8BSJdcuTs6kU5HW18pNtG/GVIaDuWXnomsXJDE+DmHLE?=
 =?iso-8859-1?Q?kSCESeB4brQwO1w1q87ykRpYiyS/Q8K7h2BeRdlaNiiyQtuKQdccDaCskF?=
 =?iso-8859-1?Q?l5s54bn/7GdQ4ShAGe3hWMl/az7qCM4xS88AWc4bSP9Q9jfoA1NKdXOw?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd601bbd-85ed-4540-84bd-08ddf526b5c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2025 13:41:16.3028
 (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: a3/fGwVDpIg7RCZtwjvId/8niKG6xxa9iFMIUpLMAk51n+FnYBfNVICsWtrrE5qB2x3aMSk5zLexxXcwMNIgG1/boo0PZbsALMaAFd4NFXE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8056

From: Sergiy Kibrik 

Add config option HVM_VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related mac=
ros.
Having this option may be beneficial by reducing code footprint for systems
that are not using Hyper-V.

[grygorii_strashko@epam.com: fixed NULL pointer deref in
viridian_save_domain_ctxt()]
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Grygorii Strashko 
---
changes in v3:
- fixed NULL pointer deref in viridian_save_domain_ctxt() reported for v2,
  which caused v2 revert by commit 1fffcf10cd71 ("Revert "x86: make Viridia=
n
  support optional"")

v2: https://patchwork.kernel.org/project/xen-devel/patch/20250321092633.398=
2645-1-Sergiy_Kibrik@epam.com/

 xen/arch/x86/hvm/Kconfig              | 10 ++++++++++
 xen/arch/x86/hvm/Makefile             |  2 +-
 xen/arch/x86/hvm/hvm.c                | 27 ++++++++++++++++++---------
 xen/arch/x86/hvm/viridian/viridian.c  |  8 ++++----
 xen/arch/x86/hvm/vlapic.c             | 11 +++++++----
 xen/arch/x86/include/asm/hvm/domain.h |  2 ++
 xen/arch/x86/include/asm/hvm/hvm.h    |  3 ++-
 xen/arch/x86/include/asm/hvm/vcpu.h   |  2 ++
 8 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index 5cb9f2904255..cf2726ef6bc3 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -62,6 +62,16 @@ config ALTP2M
=20
 	  If unsure, stay with defaults.
=20
+config HVM_VIRIDIAN
+	bool "Hyper-V enlightenments for guests" if EXPERT
+	default y
+	help
+	  Support optimizations for Hyper-V guests such as faster hypercalls,
+	  efficient timer and interrupt handling, and enhanced paravirtualized
+	  I/O. This is to improve performance and compatibility of Windows VMs.
+
+	  If unsure, say Y.
+
 config MEM_PAGING
 	bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED
 	depends on VM_EVENT
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 6ec2c8f2db56..0aee4cd114b8 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_AMD_SVM) +=3D svm/
 obj-$(CONFIG_INTEL_VMX) +=3D vmx/
-obj-y +=3D viridian/
+obj-$(CONFIG_HVM_VIRIDIAN) +=3D viridian/
=20
 obj-y +=3D asid.o
 obj-y +=3D dm.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 330103ddf386..0d063ae95f6b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -701,9 +701,12 @@ int hvm_domain_initialise(struct domain *d,
     if ( hvm_tsc_scaling_supported )
         d->arch.hvm.tsc_scaling_ratio =3D hvm_default_tsc_scaling_ratio;
=20
-    rc =3D viridian_domain_init(d);
-    if ( rc )
-        goto fail2;
+    if ( is_viridian_domain(d) )
+    {
+        rc =3D viridian_domain_init(d);
+        if ( rc )
+            goto fail2;
+    }
=20
     rc =3D alternative_call(hvm_funcs.domain_initialise, d);
     if ( rc !=3D 0 )
@@ -739,7 +742,8 @@ void hvm_domain_relinquish_resources(struct domain *d)
     if ( hvm_funcs.nhvm_domain_relinquish_resources )
         alternative_vcall(hvm_funcs.nhvm_domain_relinquish_resources, d);
=20
-    viridian_domain_deinit(d);
+    if ( is_viridian_domain(d) )
+        viridian_domain_deinit(d);
=20
     ioreq_server_destroy_all(d);
=20
@@ -1643,9 +1647,12 @@ int hvm_vcpu_initialise(struct vcpu *v)
          && (rc =3D nestedhvm_vcpu_initialise(v)) < 0 ) /* teardown: neste=
dhvm_vcpu_destroy */
         goto fail5;
=20
-    rc =3D viridian_vcpu_init(v);
-    if ( rc )
-        goto fail6;
+    if ( is_viridian_domain(d) )
+    {
+        rc =3D viridian_vcpu_init(v);
+        if ( rc )
+            goto fail6;
+    }
=20
     rc =3D ioreq_server_add_vcpu_all(d, v);
     if ( rc !=3D 0 )
@@ -1675,13 +1682,15 @@ int hvm_vcpu_initialise(struct vcpu *v)
  fail2:
     hvm_vcpu_cacheattr_destroy(v);
  fail1:
-    viridian_vcpu_deinit(v);
+    if ( is_viridian_domain(d) )
+        viridian_vcpu_deinit(v);
     return rc;
 }
=20
 void hvm_vcpu_destroy(struct vcpu *v)
 {
-    viridian_vcpu_deinit(v);
+    if ( is_viridian_domain(v->domain) )
+        viridian_vcpu_deinit(v);
=20
     ioreq_server_remove_vcpu_all(v->domain, v);
=20
diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridi=
an/viridian.c
index c0be24bd2210..7a2f718e6be7 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
 {
     const struct domain *d =3D v->domain;
     const struct viridian_domain *vd =3D d->arch.hvm.viridian;
-    struct hvm_viridian_domain_context ctxt =3D {
-        .hypercall_gpa =3D vd->hypercall_gpa.raw,
-        .guest_os_id =3D vd->guest_os_id.raw,
-    };
+    struct hvm_viridian_domain_context ctxt =3D {};
=20
     if ( !is_viridian_domain(d) )
         return 0;
=20
+    ctxt.hypercall_gpa =3D vd->hypercall_gpa.raw;
+    ctxt.guest_os_id =3D vd->guest_os_id.raw,
+
     viridian_time_save_domain_ctxt(d, &ctxt);
     viridian_synic_save_domain_ctxt(d, &ctxt);
=20
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 993e972cd71e..79697487ba90 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -426,7 +426,8 @@ void vlapic_EOI_set(struct vlapic *vlapic)
      * priority vector and then recurse to handle the lower priority
      * vector.
      */
-    bool missed_eoi =3D viridian_apic_assist_completed(v);
+    bool missed_eoi =3D has_viridian_apic_assist(v->domain) &&
+                      viridian_apic_assist_completed(v);
     int vector;
=20
  again:
@@ -442,7 +443,7 @@ void vlapic_EOI_set(struct vlapic *vlapic)
      * NOTE: It is harmless to call viridian_apic_assist_clear() on a
      *       recursion, even though it is not necessary.
      */
-    if ( !missed_eoi )
+    if ( has_viridian_apic_assist(v->domain) && !missed_eoi )
         viridian_apic_assist_clear(v);
=20
     vlapic_clear_vector(vector, &vlapic->regs->data[APIC_ISR]);
@@ -1360,7 +1361,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
      * If so, we need to emulate the EOI here before comparing ISR
      * with IRR.
      */
-    if ( viridian_apic_assist_completed(v) )
+    if ( has_viridian_apic_assist(v->domain) &&
+         viridian_apic_assist_completed(v) )
         vlapic_EOI_set(vlapic);
=20
     isr =3D vlapic_find_highest_isr(vlapic);
@@ -1373,7 +1375,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
     if ( isr >=3D 0 &&
          (irr & 0xf0) <=3D (isr & 0xf0) )
     {
-        viridian_apic_assist_clear(v);
+        if ( has_viridian_apic_assist(v->domain) )
+            viridian_apic_assist_clear(v);
         return -1;
     }
=20
diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/a=
sm/hvm/domain.h
index 333501d5f2ac..07eec231f023 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -111,7 +111,9 @@ struct hvm_domain {
     /* hypervisor intercepted msix table */
     struct list_head       msixtbl_list;
=20
+#ifdef CONFIG_HVM_VIRIDIAN
     struct viridian_domain *viridian;
+#endif
=20
     /*
      * TSC value that VCPUs use to calculate their tsc_offset value.
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/=
hvm/hvm.h
index 24a7ed88567b..ad05101f19ca 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -500,7 +500,8 @@ hvm_get_cpl(struct vcpu *v)
     (has_hvm_params(d) ? (d)->arch.hvm.params[HVM_PARAM_VIRIDIAN] : 0)
=20
 #define is_viridian_domain(d) \
-    (is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
+    (IS_ENABLED(CONFIG_HVM_VIRIDIAN) && \
+     is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
=20
 #define is_viridian_vcpu(v) \
     is_viridian_domain((v)->domain)
diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm=
/hvm/vcpu.h
index 924af890c5b2..b38702045818 100644
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -176,7 +176,9 @@ struct hvm_vcpu {
     /* Pending hw/sw interrupt (.vector =3D -1 means nothing pending). */
     struct x86_event     inject_event;
=20
+#ifdef CONFIG_HVM_VIRIDIAN
     struct viridian_vcpu *viridian;
+#endif
 };
=20
 #endif /* __ASM_X86_HVM_VCPU_H__ */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 14:13:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 14:13:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124678.1466930 (Exim 4.92)
	(envelope-from )
	id 1uyWR3-0004dZ-Jv; Tue, 16 Sep 2025 14:13:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124678.1466930; Tue, 16 Sep 2025 14:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyWR3-0004dS-H5; Tue, 16 Sep 2025 14:13:33 +0000
Received: by outflank-mailman (input) for mailman id 1124678;
 Tue, 16 Sep 2025 14:13: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 1uyWR2-0004dM-Th
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 14:13:32 +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 4eed9576-9307-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 16:13:24 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3ea115556b2so1659704f8f.2
 for ; Tue, 16 Sep 2025 07:13:24 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77607a6986esm16299286b3a.43.2025.09.16.07.13.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 07:13: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: 4eed9576-9307-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758032004; x=1758636804; 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=5icLOJ4TvSuMnp6Gzb0gOFoCfk+0MLOxBayTmD4t3ts=;
        b=SlxqLdYbCQK3o/KgJdNEYtcERBWJqQFOSrQnlxjN15dEPk8ag7bU/enD69oxTRnBss
         8Eqc5qCaviKBWLoNEhN4Iqxlz5nNKsnezeA4ID963BxjHkeFGhTBA9rdFwHhkfhiz5y8
         wxdlipjQyKyDi4yc9hiJp1y/C1tXX0Q7HO1fBpkau9FELFAXl4g/Uqz5RDr7PelAfX1x
         8V6xRhRk9zoxaF13vIQiBnXacrE+ySxi0OB58TVdylZiL1ly7Trwi7oH4G/wF9FVgS3c
         nFyPoVmemVNbBYilXWHUD5NuVybmIYhhbO3umK/Lj+fsqtj2qIZStUBrA0ooLNEdoInH
         7iug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758032004; x=1758636804;
        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=5icLOJ4TvSuMnp6Gzb0gOFoCfk+0MLOxBayTmD4t3ts=;
        b=coo0aUXcXf0dyGVzESp65EezgpAAcV/ODqytZ5lyBS6DVmpJqUAUgJsTpXOPHWvUJI
         08KyoJgSz7Ra9W649/sLXaN4JBoHxSGuXL2Dra6Jsf52+B0squ6euSB2NSrlYX4RKIfZ
         Rqm//n2lm0o3ovtkUQxdtGuuVTOBMIOFJnHWp4p54VCzWnRVHlVqJfxRXxnUANmyiPVk
         jKvqV8CNw4DSXxJvjxmobKw51yg780LT2l92VZ4srILq/P/H5szrRCNciXn5Z548Mm7A
         UK1jVpSo2S8RjSyorpDIYcIo8a5dbrA6uqXT5oNpRK9W4XIdv/BRFK+gWrr3KhiCIXhB
         QEfg==
X-Gm-Message-State: AOJu0Yy5whtAWtXviJ9bR2VUOzRoOSPN+ow0u4zrGXuZXvFheG0qkLzT
	MRmhGbc1kCHKiI0/4aIXMDZVppEITdlqsfaMUrYOJiN8dIOB1m1tSPb+HuwiQW0qMg==
X-Gm-Gg: ASbGncsgWcolh31L0VKWiwAyosuXuih+SvRRQ0NnOf4KyP8a34mpBgrUMGxB7SxFg2e
	zE0TwsZhMNtp/M9zGQmnIQAsF5B0D4SE4obKb3r7lsQuYCwbXK/4tJZYnjlY1wYakGQV/9J0DpJ
	anSuQoJsOZwUA9Jd0GUhUCbxzlgHex0lbIGAccGdASo1RIqu8CRjKP7+EcfO2KEqphPDdM3wOms
	J4Yv4mH/ia5nnJ5EJhS/bCQZ6hkCzg4LBMQRDt6Gi/JFQGYzKNmqkx+Snph+6Vlm9QpN+Ulnbtg
	ZhBUPsiQM/oYVYmH5vefftu4pggdW7L6dys606PXq5VlaYLaVCluGCbXmNj/J1h7+eECZsgBW6E
	RafhPxXzeZGP6CcmcV2Z4cSvH8dOO8VQ=
X-Google-Smtp-Source: AGHT+IGA57tdXQt1exHQ/NZDUUV3HE04ebZas3OlqG2i30tO8dvUGIsz4ya/YjnsDZeLJDpGYQJyAw==
X-Received: by 2002:a05:6000:40cb:b0:3ec:c50c:7164 with SMTP id ffacd0b85a97d-3ecc50c7871mr2287413f8f.15.1758032004073;
        Tue, 16 Sep 2025 07:13:24 -0700 (PDT)
Message-ID: <8e2ee71c-62fa-4398-802f-1774242f4df2@suse.com>
Date: Tue, 16 Sep 2025 16:13:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 08/16] emul/ns16x50: implement MCR/MSR registers
To: Mykola Kvach 
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,
 dmukhin@xen.org
References: <20250908211149.279143-1-dmukhin@ford.com>
 <20250908211149.279143-9-dmukhin@ford.com>
 
 <9d55721e-bd95-4354-b839-f8896eedab24@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.09.2025 10:00, Mykola Kvach wrote:
> Hi Jan,
> 
> On Mon, Sep 15, 2025 at 5:49 PM Jan Beulich  wrote:
>>
>> On 15.09.2025 08:00, Mykola Kvach wrote:
>>> On Tue, Sep 9, 2025 at 12:12 AM  wrote:
>>>> --- a/xen/common/emul/vuart/ns16x50.c
>>>> +++ b/xen/common/emul/vuart/ns16x50.c
>>>> @@ -107,7 +107,7 @@ static bool cf_check ns16x50_iir_check_thr(const struct vuart_ns16x50 *vdev)
>>>>
>>>>  static bool cf_check ns16x50_iir_check_msi(const struct vuart_ns16x50 *vdev)
>>>>  {
>>>> -    return false;
>>>> +    return vdev->regs[UART_MSR] & UART_MSR_CHANGE;
>>>>  }
>>>>
>>>>  /*
>>>> @@ -232,12 +232,63 @@ static int ns16x50_io_write8(
>>>>              regs[UART_LCR] = val;
>>>>              break;
>>>>
>>>> +        case UART_MCR: {
>>>
>>> Probably the opening brace should be moved to the next line.
>>> See CODING_STYLE:
>>>
>>> Braces ('{' and '}') are usually placed on a line of their own, except
>>> for:
>>>
>>> - the do/while loop
>>> - the opening brace in definitions of enum, struct, and union
>>> - the opening brace in initializers
>>> - compound literals
>>
> 
> Thanks for clarifying.
> 
>> strictly by the wording of the doc you're right, yet if you go look then
>> you'll see that we really permit both forms (and apparently prefer the
>> one used here).
> 
> I just want to make sure I understand the expectation correctly.
> The CODING_STYLE document has wording about brace placement, but as
> you noted, the actual code in this subsystem uses both styles, and the
> one used here seems to be preferred in practice.
> 
> To get a better sense, I did a quick search in the repository. The
> pattern with the brace on the next line after case appears roughly
> 340 times, while the variant with the brace on the same line as case
> appears about 75 times. So overall the first form seems to be much
> more common.
> 
> That makes me think the choice here is more a matter of maintainer
> preference than a global convention. My main concern is consistency:
> if in one place both forms are accepted, but in another case reviewers
> point back to the document and ask for strict compliance, it could
> create confusion for contributors.
> 
> I'm fine if Denis leaves it as is. I just wanted to note the
> misalignment with the CODING_STYLE doc.

Yes, the situation with ./CODING_STYLE is suboptimal. Yet trying to get
in changes to that file also has proven difficult.

As to the brace placement in case block: Please realize that this is
also special because of the case labels indented as much as switch()
statement's opening figure brace. While nothing can be done for the
closing braces (i.e. there being successive ones with the same
indentation), the opening ones have this alternative placement as an
option.

What we could consider is to allow omitting the braces altogether in
case blocks. That comes with its own downsides, but we may want to
weigh things as to what's deemed worse.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 14:27:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 14:27:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124693.1466940 (Exim 4.92)
	(envelope-from )
	id 1uyWeX-0006T5-PT; Tue, 16 Sep 2025 14:27:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124693.1466940; Tue, 16 Sep 2025 14: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 1uyWeX-0006Sy-MG; Tue, 16 Sep 2025 14:27:29 +0000
Received: by outflank-mailman (input) for mailman id 1124693;
 Tue, 16 Sep 2025 14:27: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 1uyWeW-0006Ss-Sr
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 14:27:28 +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 42d867ba-9309-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 16:27:23 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3ec44b601b8so806013f8f.1
 for ; Tue, 16 Sep 2025 07:27:23 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7761af2e09dsm12303109b3a.76.2025.09.16.07.27.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 07: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: 42d867ba-9309-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758032843; x=1758637643; 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=n3aHQVorPOxvsoXCkZqV0/Enf6ycaWx6Ys4jGKOncfg=;
        b=Z6FMObJLUxsA7z3fEDfU3NO4QK0LvcOjZN3alRhw9OTfcf0dN5OCusvynn+Mr0OFdi
         lSVoiPT+9BmhPA0lSkPV+GaMrBd9mAFNoWBG6VDpBIB+zgUPSHzi29CjVOyd70MiR0BM
         goC0aHA89qHUanW4q6sO4tnFtlpmWdwLM13xQkgHsUZBIu4/5dSHc6BxcgKI/pF29N0x
         iDmwvU8ROsRxwql29gzNxlcIMd515m5PeTF1vu1nIhsTlW8O7Ff0ixg5aIAafQO135Xf
         lvct+sqOxDkZ/mZ/QglKooPfI+0M7TKzeJLcsa1GjEvYXMsgwr3VjMBT3in7Jqvi+0Lc
         3Y9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758032843; x=1758637643;
        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=n3aHQVorPOxvsoXCkZqV0/Enf6ycaWx6Ys4jGKOncfg=;
        b=EKmrN71oAjICjtqyBTiH61IYm0gSJPtk1qVAe+0zapaJF1llnUZfHbMx6exTYAOhKK
         z86LDqO6ls0WpA0iMTt4+8FbQtBexHfabuFtte3cSa1xs5yW5uJGGeY5DrpOHXbc/PYE
         40H47K0vFP+Fqhz4/vIb4p6U14aEUyFHJmOrVJepTvbZBVfiDCw9jnbpnnlEEG23Wyao
         JBOX2ejZwa3u7ZLGyi/MuddFAz6kmM0AHe/AFsHqFmsg9Yv0gyTcYvEd8lrij6x1iXwc
         9NBlZm5whS+hMX4JZxhOYvJM1o1/vcAOuyDx6g4wA6FXCF4o3bbzPCQVm+p0uP6iACL/
         P2Pw==
X-Forwarded-Encrypted: i=1; AJvYcCVr4Fy0hTMTKYAuiiQ9ThhR+DkNjY8dAerUgCPJh9xaS41iXEZwyrECZTRfpYUMjXOucYyhFdR2w58=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyeo6yONVVLgizRojMGqCQuC55qeYWaiMqD7ixIigZZXP0g0xWa
	/6SVClWlempljUQ9W+gFbWOlwyYJZ96UVVU+ujK+dAzgk/chDbjHRVnAuvK0b6Sv1w==
X-Gm-Gg: ASbGncvBCOnf7YAE73+WxFU7OVSJckPiB/nKQCN1VtNXSqzlpb08rwTlS7B5WyqVGoG
	eGXNoPYwZkLAnkkRa70uP7Aq4tR/A5iA9aww8rWCSaS7r60clLHiwJZ6JwdT2Pd4VwKVfdxyJPz
	rI7EPpFh4kzxI5GSnWiAJSvFhtwOm/1HZhCqsrUp7SWnHhl7oESSYm1idQBes8//jv4CKz9TvQk
	nQs7ytJjSe79E/KprthFuf9qpaE5S8CqRs7w393tRvmKrlGCOC6eU28ZbHbo4q8y/YXS2501+c9
	5F+1NEFBjMl7tG07L5dPKfeQedpVb6UfcM0gweokYy0UTS3EFjACSS2quR5J+sFCIwXQzY7EqDZ
	uPQku0pg136mBZNihxYzlHUScCDImDXE=
X-Google-Smtp-Source: AGHT+IEqh7XdLTvBtcjdD3jkGU4Agh/KA8GAx2ZYB1F7zD+JpEXb2viNHJyn6I5HZ+lAvbVa424t9w==
X-Received: by 2002:a05:6000:178e:b0:3e3:f332:7414 with SMTP id ffacd0b85a97d-3e765a08455mr12944810f8f.58.1758032842865;
        Tue, 16 Sep 2025 07:27:22 -0700 (PDT)
Message-ID: 
Date: Tue, 16 Sep 2025 16:27:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
To: Dmytro Prokopchuk1 
Cc: Nicola Vetrini ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
>         even when debug-only assertions like `ASSERT_UNREACHABLE()` are removed.
>       - ECLAIR has been configured to ignore those statements.
>  
> +   * - R2.1
> +     - In the specific build configuration (when the config CONFIG_ACPI is not
> +       defined) the 'BUG()' macro is intentionally used in the 'prepare_acpi()'
> +       function in the header file 'xen/arch/arm/include/asm/domain_build.h'
> +       defined as 'static inline' to trigger a runtime error if ACPI-related
> +       features are used incorrectly.
> +     - Tagged as `deliberate` for ECLAIR.

I response to me outlining a deviation-less alternative you tried it out
and said it works. Then why is the deviation still being put in place?

> +   * - R2.1
> +     - In the specific build configuration (when the config CONFIG_HAS_ITS is not
> +       defined) the 'BUG()' macro is intentionally used in the 'gicv3_do_LPI()'
> +       and 'gicv3_its_setup_collection()' functions defined as 'static inline'
> +       in the header file 'xen/arch/arm/include/asm/gic_v3_its.h' to catch and
> +       prevent any unintended execution of code that should only run when ITS is
> +       available.
> +     - Tagged as `deliberate` for ECLAIR.

Taking both together and considering that really, when we no longer limit
Misra checking to specific configurations, we are going to have many more
of such "problems", I fear this way of deviating them simply doesn't scale.
Imo this needs a SAF-style deviation that can be applied without needing to
add a new section of text every time.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 14:34:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 14:34:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124706.1466950 (Exim 4.92)
	(envelope-from )
	id 1uyWlO-00084B-Eq; Tue, 16 Sep 2025 14:34:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124706.1466950; Tue, 16 Sep 2025 14:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyWlO-000844-C7; Tue, 16 Sep 2025 14:34:34 +0000
Received: by outflank-mailman (input) for mailman id 1124706;
 Tue, 16 Sep 2025 14:34: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 1uyWlN-00083y-8H
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 14:34:33 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 41f4891f-930a-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 16:34:31 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-45f29dd8490so26383925e9.1
 for ; Tue, 16 Sep 2025 07:34:31 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-267b0bbabe6sm39874955ad.107.2025.09.16.07.34.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 07:34: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: 41f4891f-930a-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758033271; x=1758638071; 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=LpH/rE8zcXN2ig4ftQNEaMDs8lFxshbqYSLJz+hrQQc=;
        b=XAWjouNcS8RLmrJnPNAQLHIsZER5NGZJOpmK3WfBpxmuLZ2Vavvr2N+97wW+4M2k/e
         1668Dg5hsacSvpEgFQtV2GLWeiT0VnwqVLoPdu2xgGUliYx0mFFtfqFMTJOAyKk1hvvX
         JyVmtRyAKIHxlgYOLLcNi/VVT+2cCXFNmGSP9OmvmPbtt/47FVQV8VtNbG37pXzFn50+
         8b+EjV7EW7wfJKLZVAeoms6aAS78zUR4nho9E7d6LR46IOuCzSH7zLBDHlWt17qslXBV
         /CzH2X0XT5WA0nwLsIcC04P1wCq96fI7hJ/QOw6d9aJZ71CBzDTuKMGVZJ7VswD6DrLg
         sTbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758033271; x=1758638071;
        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=LpH/rE8zcXN2ig4ftQNEaMDs8lFxshbqYSLJz+hrQQc=;
        b=u5Q69KDJHrbTz4Od1V1586aBgEkfoxnkB5C32QiuEOuetVei2tBhLcc0mo09No1iY2
         msR33TJj7m2BlIPaFDy8Z1zMzsZKIiGI4YSq4+MI+j+P3BxX9WNh/dbjwORbovHtfWZn
         dTvpGDGzcupAefXy+Wb52Dz5hk5H9zMMF7gHX7awWV6u95IDqfauJZCQB+tzGQaqdph1
         r33we9A7iqFx/EDadiWakt6hGnH+418KC8NcHZN7xT3SJNY6yzTWqTalC5jKAj+6vZWO
         zdNj+gJdqPhQ8g15Voj7uA64DZOF6fgslir9sEgOTe+GelHYvlpl9oc0M+yVSvL8vd86
         UfOA==
X-Forwarded-Encrypted: i=1; AJvYcCWKJeS3B0uplJoXjsV3KomrNK/C03EXUQqgXb+SQok54N2I2ubpkV896qbQ2tm+luAulViyw4cOx6I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9ahfaF7QVDd1iTSKtc8LQxA3t6Ai6fTYZVwY0fEqBfOlNLJ3i
	M+xGRw+SCh1vasG8SL/+yNLoUVyBRVM0PreWrGJMlaqw/52fLw0Y87CFe/OYimrt+w==
X-Gm-Gg: ASbGncsUaryE1S8PGYbiZQN9iBI6teQP4SF8LQHIJ4Zx1/Qc/LR2G3yr46kwUmEoVVo
	obQrCmX7ywHzVNdYIsGMA+kctLxDSjQWFcEcHEHpt14F0jQBY6BsSTHdG2H5FAAJXTtBs3pD1Dc
	Aj/QFU5857cNGIywW60OuHlO+6OBX6GBDj0O2t+QCtY/7/BVSb1IMzdOxCLchZGEzs2KN+yP759
	uCW0YXRtnfFXYH4dm8pR3084OL45MixDg9wI+JRbUrZFojLkpK68K1HjnlXw6YN2llPL1IocNqP
	UAQ1Gf15Dmpty58nDxg7NYqNPZv1Z/D/+kT1sMWhK1K85hQSGSvyGfh8WA1/WqVpWFvnzEBtG0M
	WRaG/EgEQHNBbyAD1MUv+hVtEKuiCZr8=
X-Google-Smtp-Source: AGHT+IGX0J2hSiBNJPvcdSdZRPpeHnaf9gwVgsDqWqEp3Coz6yA5oObsjz48XAQieSOyYJtAX6FFsw==
X-Received: by 2002:a05:6000:2283:b0:3e7:6196:fdf2 with SMTP id ffacd0b85a97d-3e765a0981amr12523016f8f.47.1758033270809;
        Tue, 16 Sep 2025 07:34:30 -0700 (PDT)
Message-ID: <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
Date: Tue, 16 Sep 2025 16:34:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
To: Grygorii Strashko 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Oleksii Kurochko ,
 "xen-devel@lists.xenproject.org" 
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250916103251.2144449-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.09.2025 12:32, Grygorii Strashko wrote:
> From: Grygorii Strashko 
> 
> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
> HVM Intel VT-x support can be gracefully disabled, but it still keeps VMX
> code partially built-in, because HVM code uses mix of:
> 
>  - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_VMX cfg
>  - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX cfg
> 
> for runtime VMX availability checking. As result compiler DCE can't remove
> all, unreachable VMX code.
> 
> Fix it by sticking to "cpu_has_vmx" macro usage only which is updated to
> account CONFIG_INTEL_VMX cfg.
> 
> Signed-off-by: Grygorii Strashko 
> ---
> Hi
> 
> It could be good to have it in 4.21, so vmx/svm disabling
> option will be in complete state within 4.21 version.

Imo this isn't release critical and has come too late. It's of course
Oleksii's call in the end.

> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
> @@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>  #define cpu_has_sse3            boot_cpu_has(X86_FEATURE_SSE3)
>  #define cpu_has_pclmulqdq       boot_cpu_has(X86_FEATURE_PCLMULQDQ)
>  #define cpu_has_monitor         boot_cpu_has(X86_FEATURE_MONITOR)
> -#define cpu_has_vmx             boot_cpu_has(X86_FEATURE_VMX)
> +#define cpu_has_vmx             (IS_ENABLED(CONFIG_INTEL_VMX) && \
> +                                 boot_cpu_has(X86_FEATURE_VMX))

I'm pretty sure using_vmx() was introduced precisely to avoid the use of
IS_ENABLED() here. What is completely missing from the description is a
discussion of the effect of this change on pre-existing uses of the
macro. ISTR there being at least one instance which would break with
that change. And no, I'm not looking forward to digging that out again,
when I already did at the time the using_vmx() was suggested and then
implemented. (I can't exclude it was the SVM counterpart; we want to
keep both in sync in any event, imo.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 16:58:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 16:58:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124732.1466960 (Exim 4.92)
	(envelope-from )
	id 1uyYzr-00085b-4m; Tue, 16 Sep 2025 16:57:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124732.1466960; Tue, 16 Sep 2025 16:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyYzr-00085T-03; Tue, 16 Sep 2025 16:57:39 +0000
Received: by outflank-mailman (input) for mailman id 1124732;
 Tue, 16 Sep 2025 16:57: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 1uyYzp-00085K-Li
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 16:57:37 +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 3e56b9e0-931e-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 18:57:35 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by VI0PR03MB10902.eurprd03.prod.outlook.com (2603:10a6:800:265::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.23; Tue, 16 Sep
 2025 16:57:33 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 16:57: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: 3e56b9e0-931e-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LBxKqCnktg2oZLXt6La/NcAzRsU/IvVbhozorCnRd3VwHkC0yodu0BiRizQFm7EDQMDQySGcCyxRuTfklOezTpoJQYff903GnWNV+fsXFa5L75sxYisM9D+8+qvQ57hA9C0axSf+QyfO1tf25ZCPDWCfjJQfTgR1VxeoqYR2Jo6HtBKVB7Lcwhl7BbXKI80WTa+vbSenf6E27Jy+RSLzn6iLgAV1cFyrL9TjCpBeQCO66Z/iWomhwjTIVD8oM5XAGv5nj4TqQapDQDQJzhD65eaGMhhXZZrKnTbBOTkusZuxIaoY5HLlEE+068B0sdvWf1gq/GjwIgb0Ig+CjUfEbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=g5uYeXa3i9VaZACp93bIk8qhtw6G0YlYhQ16KKrxULw=;
 b=WqihaDziY7AsR0FteMVw7WXxVOrwDZnqc1Sf2Zs5cturMAwQ5F2+ZWPbgOMw2iTmZp9EU7rpois5GvOBM1RKNS8NVkuInMjT46PELwLaJ3eQNGcrGM05JgHbs53KwA49ZSbi5B+IeHs5fKOSkkLOEOtfm8S9vltzT05SzIxP4xK4BvnY5QxId+LzBGZu37Q4dAB2vS0F9pTQnp5RShv7HRjQ1mZBmYFKMYLGp55zRO7sXlembBtZH+SeX5A+cIPOPHQcISPDYbzE5U2oai6dd6E94HdZImc/gz3HyOCLBfs0ABujhw8jvHeK+ks4jIgdlq4pi50n5lbUVoJFj2JRAQ==
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=g5uYeXa3i9VaZACp93bIk8qhtw6G0YlYhQ16KKrxULw=;
 b=PgJYKhVT7YBUsjKJljY7FO3S8qzxa0ocz/mhJCrpn+UaHQPcK5MAzYngmmVWxA/r5AEZnWTMRTZTjuUpawhERNhvJbWbor3HRhHubpBeNYovvqw9Gou5hKoSclrUkH1ZjvYcC6HWwf+YvY9yA2lzfNdZmrOLQOrZNPC/cu1dIDSOaXE6huuRdHJcRsrU7Z+/vWtjT3Y9TeIRkzpht+JOMVbMyb7QjDxyRTArN4fTUGCfDzQoj7LT/zjeAOdQMvg5VNUy48eBMqVOt6EM1kDIxSiHiPvaYrzv3sQXzO9GgP07ZxTsuuHRTy1GsgboJEyFIXPg3wh5jsYPOXe8Fudhsg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Tue, 16 Sep 2025 19:57:31 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Oleksii Kurochko ,
 "xen-devel@lists.xenproject.org" 
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
 <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0019.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:14::6) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|VI0PR03MB10902:EE_
X-MS-Office365-Filtering-Correlation-Id: e0999994-7538-426a-45a2-08ddf54220a6
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?YVh6aU1WZ0Ewb3N5TXJuZmRwVTIxWmpJTm5oVy90ZEoyaGd3bGZRNFA5aVJ6?=
 =?utf-8?B?MEZ6bUV6Q1kxVFU3NEgrNndQZ0VUcnA4TGpFRVZIV0tyMU9sdkJVZUhaamJm?=
 =?utf-8?B?TWx2dzJZY29qWE1oU0dtSUZEZ25TbHE5R1dGeWFXeDUrN0RNL04rRTByejF2?=
 =?utf-8?B?TnZqZER6K1lOcEVRT3JHT3dCN2IvVGRUb0Q0KytHZXk2MHZTQjZBaWp6M1Nq?=
 =?utf-8?B?c3pGYXpBSk9QYXRXMnczUTFTWVlFSDA5VVYyeG44Nm5oSjYvYUJ0OW50UllL?=
 =?utf-8?B?SXB5UDRES084OXdSUjBzd0RNS0RhenBxR2ZIODE5VUtQenBaRW5qaWNNdDNT?=
 =?utf-8?B?cWFKWGRsSmJMcEp4Y0lYekI2K0YwT2JGcit0MG1ZSnc2bUo1aWo4dldHTzdH?=
 =?utf-8?B?Z2xXUUZTR2k1TXF2bVBKYkxvMkgreFlxNWpWOW5BdmNoNURUbktkYUUwdlBh?=
 =?utf-8?B?bTMvVlBDZzQ5RkJzRXBJV2kwdlo5UmpnN3F6U2tjakFJdjhRUUF4aGQ3Mi80?=
 =?utf-8?B?eEYrZHFzdjRZNUxQeGtJVnZ4ZUV5b0lMMmNjc3I1eVRWcG9HM0NmSWFBMHFx?=
 =?utf-8?B?N0NhdWZtdHlHTk1yN09WOGEyV29XT0kvbzZ0N3F3cmE1Mnk1TWhZWEo3eWdY?=
 =?utf-8?B?SCs4TDhzdTBVNVppRy81aFFkRkQvZmwvWHJ4Q2FiRVdudC9UcURGZ1J4Nkow?=
 =?utf-8?B?ZUtrekRTWWJRY0QvUlh4cG85RFU3L3NnZHNaUHZGazhQQi84cnhBcTNFZjl1?=
 =?utf-8?B?MWdubnE3clVhMjBaTXVsUGJtdUFyaFpDUmQySXV3SnBNa3M2d0ZoRTd1UzRr?=
 =?utf-8?B?b0hVVVAvb2hBbytBamxoR3hJaWJKUm9HaW9LalB3eDBVOUR6amJ1ckQzNStJ?=
 =?utf-8?B?ZEhzallIWTMyOUtqTGtVZ05FNWIvOW1XTDQrM2lLUlRIaGY2bldHbGg4UnR0?=
 =?utf-8?B?SFk1ZTR2NVViVlA2UGVaYkk0OXEzSWxjVlMyWHJUWEhTL2REaERod0FYRXpk?=
 =?utf-8?B?U2dlRVNDR3VsMnAwY3A3WUl2aVJodWRibjNvR2kvRURNYkhjVXVia3pBOU9s?=
 =?utf-8?B?dG5lR1NzenhaRVlSZytmeFNZMkRaazFMRkFmdUhKd2NRR0g0a21WYm5NYmxl?=
 =?utf-8?B?MFRNc1hBbXhNZms0RmpESG5YOUlTOFVtUG9oMHlsVC9vNXdaRHBxU2NoOEZz?=
 =?utf-8?B?WXdrcGZUWXFUaU1iSlRTM2g0ZW1peldycVFaOHFUTUhZMTFvRHBsQUhmcGVl?=
 =?utf-8?B?c0I4UEVkMWpOcGliR05KZHRwa3hrYUlJM01ub1NyRksyNTBpNjJsSU5iOGMz?=
 =?utf-8?B?bmw0WjBiNE1pSmlua20rdUlFVzViSWI0cXFUWEMzcjRpbTM5Y3ZpdVBOQVB3?=
 =?utf-8?B?MGRlN0s4eVNwMFUya1pyUVRjOFFZU1ZEYmVwckpSZ3lzRmpMZDNJTndOWE5z?=
 =?utf-8?B?c0VjT05SWE9lbmtnK3ZLQkhMWUFsR0dEM0JTdktBbGw4TFZMNUswdEhDM2sx?=
 =?utf-8?B?Q2d4S29vaDNXK2dLZmdKdFpoSVNXckkrd0FHdG9QREFJbW5FSTVrZ1liMTJG?=
 =?utf-8?B?RGNFWGp4Z2N6Rm1qWXFHSGFGSXFtSWtIZE5NL0lJODBHMVhVaWppMkw0K0Np?=
 =?utf-8?B?bEdQSnNPUkc1TlNYNEgzTjBJUXZlT3hNOVdEeWk0VVpOOGZwY1Y5LzlMNzVv?=
 =?utf-8?B?VVhRMlpDM3RnV09ZamQ4ck43ZHBDOWdtdkxSdXBTZXBFL3R5NnZiR0hKdkpH?=
 =?utf-8?B?VEdCdGpvVlY3TXNZa3krM1BCWFgwR2Fub2luR0QrZ3VNeURyS3UyK0NuYmJu?=
 =?utf-8?B?TGtPTnBtMkh3czM2SHV6b1Q5SVhMSkkyb1ZrbmRKUGFtc2g0Z2pwMUQvOFBw?=
 =?utf-8?B?cWc3NXZsVEZzbmlzVzF0NGorZnRyQW9QZGJGTGFrU0ZQZjc4ZTdPVFBYdlNn?=
 =?utf-8?Q?kSebAGpvRNY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TTlNNTBkdUZPYjBzM3FBR2R1d2lvWU9kK1gzTFJFRFVRelpPa2pGZm5Tc3hD?=
 =?utf-8?B?dzJndmRQRVBIOWY0QllrbHJFODJKbTB1VFlCdkFGMlNBZkZMU1dGZkp4UVVM?=
 =?utf-8?B?eDNjYVdzRXpTSk5IMDBYNW85clJUSTZWeFNNaXhZbVB1aGRSaS9pbmR5a20v?=
 =?utf-8?B?Z0ZzRjdkQUFQRncwblVoaG5sYXdhbVRzMUhMdVo2eTBMbWlnNEttMWhGTGhh?=
 =?utf-8?B?TDVxYmwzRXhZWVgyTlQ0L055QnYyRDA0TmU4NVdmenRQaVpsaHVkZ0hYbEt2?=
 =?utf-8?B?emJ4enVCZTdmeW50cHRGSGJDQ0lCWVFUS3RkU1RGTUQyZmp3YzhIOGIwaWpw?=
 =?utf-8?B?andsZWQvYUxPeUpCWG05VVNWUmVJVzFxczBIY291STZzVW9XY3MzcjRLb0JL?=
 =?utf-8?B?Q3l2eFFMZGRpc1RKRkhWY0Y5ZVI4dGNFOEdFT29pVjNGQ0g4K1VTQk1mbkpW?=
 =?utf-8?B?Y09pN2RYUDRHTWo3VDJOR0ZUL0VSMmN5V0NtdTJoVXFGVDNCMEkzMFkvaEpr?=
 =?utf-8?B?YXRxeENLZWtLK0RRWUZnTnAvWlpRdlo2S3FCWVJPV29DUXFlSXcrY0xMeU50?=
 =?utf-8?B?UjdTNUNDZEFYS0wvbmhWdnVMZS9YcEcwWmZhOXJmZ3hvSW5NUVhKUjBzdjBm?=
 =?utf-8?B?TFlxNEs0dHNnWFdCU0pDa0hLU0ZXNGIwVkhyVW9wWXMzUEZWd1I3OThmaVk3?=
 =?utf-8?B?anZJZ1hsWjBYa0Q4MW9nOUg4Q042OVZ4SDR1Vis5ZUdxcDU4SnRacUhRRnVU?=
 =?utf-8?B?SlBHNFhDVmp4MWZZNVdMSmFmWVdJbSt2L2tnQjA5OElyRWN2cytadmtIZ0Ev?=
 =?utf-8?B?MFBxZVNjL1dlZkdFcjZCM3JkVVdheEpFbldETHVmeE1sVzVsVVZ2VW8rUldt?=
 =?utf-8?B?RWE1TXY1VUhHMFk4dXFwSW5XQkNZVmVlWk9acSt4Qm53L0FZaXNLRzRURkhk?=
 =?utf-8?B?NVZIVUUzeDZXYU14SFg3ODlOT0krTU43NjQ4MlI4QktnVG80L3k1bExDeUZY?=
 =?utf-8?B?bXVsZEd1SUc4T3pjK0l4WlJPbStoOGxVcEU4aHRmVFBsR3BpMW9CN1pmbXA3?=
 =?utf-8?B?MUNmVEtabzdsUzBQOFZQZTRWMjgxeFlXcmZQK09sUjgwRzhsWWhPaXFEbm5R?=
 =?utf-8?B?a2J3ODBUUU1HWTVURjl6ckJMbVNrcmVvK3h4V2dxdU9oRzBHcWpia0Fkb1hL?=
 =?utf-8?B?cUZ6UFRWUm5NKy9NN2dJaUo5RWdRci9aenlaek1GLzRxUC8ydmlMcm9NZi96?=
 =?utf-8?B?NVYvNmFSb1ZDeStPd0ZuaXN5bmM0ZFFlV1kzZHFrYzR1T045RjVGSmFNbkJp?=
 =?utf-8?B?Wit1bERWbHVQMzRUTVR3SjJEanp2c1ZRZTBaODJWZXZaS1hjVG5lZ25Icyta?=
 =?utf-8?B?ejdCZTF0LzV3TW50emVBY0ltVm1TMy9JZEFsV2NkSkw1NlR2SmIyUlczK2FH?=
 =?utf-8?B?Q1M4NkJEajFwelhhTGFJcmdKUG91ZFp2QkdidnRmVnBEdnBSazlXbjMxOVNF?=
 =?utf-8?B?cng1MldKOFdjeWpyNmVTMWFqSUkwU1lObXBYV3piOGVrWW9NT1hIQ3Q2OGdl?=
 =?utf-8?B?WTBQSlZYc1hZeWdMeVlKMkNsNjdRSmZzR2FON1JvTzdTc20vdE9OQ3dhVjRI?=
 =?utf-8?B?N3pXT0MvMkdyd2hHbWlPMWp0MU5wTlpod1JzcUtHcGMwZ2Q1d3hTVVVKRWl5?=
 =?utf-8?B?aVpLRlBYeDIvYzBKZkdlZUxERlJhRDdsckFzd3RTMk80Vlh1M1RIdXdRZHA3?=
 =?utf-8?B?bXhBeUI5L0JnSlVYTWpnY0RPZlBCUmx4SHJXYzhMSVNXL01KTm15TzFGWEVP?=
 =?utf-8?B?YUVicmc4R0pSdGR6T0NUUXQ0Z0J4dUFhR3FteWVkRWx3ZGI3cE8zQ09DbHRM?=
 =?utf-8?B?aSt6b0VYVDNSbzRRTlhSTENWV2VoUkF3RW1GSjcxUjg3ZkNlTGJ6UDNkMGVH?=
 =?utf-8?B?UmxFeWVYUFRoUUtzcUlGTVZPZ3hvbHFURWtPVkFTOWU3WmFFN2orOEdMNWZT?=
 =?utf-8?B?U3huQlRmUnlRanFBL2FPelBQN3N6QkptQWkvUlFlQmhMQmNyQ3MwYks5ZG8z?=
 =?utf-8?B?OW1BMCtNV0NPOHpoc0duUzROVVowYTViMTZLSWU3OUhaNUVjd2JNMU5WWk5w?=
 =?utf-8?B?MHR1V0t6V0tVdXdHZkNRbGF0NnJMS28vWmdqTXJRVWlaSnZXYlVjNGZoQU13?=
 =?utf-8?B?d0E9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e0999994-7538-426a-45a2-08ddf54220a6
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2025 16:57:33.1128
 (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: QhNoCpiRwXxMkefuVFU/cQPBmdBMflxus8zjWAVNpoUxsAIaUgfYHeB7c8r4P+JeXop36vyezoHFyLoxSnk7O1YLplIgmBRrnHp40dwJDwA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10902

Hi Jan,

On 16.09.25 17:34, Jan Beulich wrote:
> On 16.09.2025 12:32, Grygorii Strashko wrote:
>> From: Grygorii Strashko 
>>
>> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
>> HVM Intel VT-x support can be gracefully disabled, but it still keeps VMX
>> code partially built-in, because HVM code uses mix of:
>>
>>   - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_VMX cfg
>>   - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX cfg
>>
>> for runtime VMX availability checking. As result compiler DCE can't remove
>> all, unreachable VMX code.
>>
>> Fix it by sticking to "cpu_has_vmx" macro usage only which is updated to
>> account CONFIG_INTEL_VMX cfg.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>> Hi
>>
>> It could be good to have it in 4.21, so vmx/svm disabling
>> option will be in complete state within 4.21 version.
> 
> Imo this isn't release critical and has come too late. It's of course
> Oleksii's call in the end.
> 
>> --- a/xen/arch/x86/include/asm/cpufeature.h
>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>> @@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>>   #define cpu_has_sse3            boot_cpu_has(X86_FEATURE_SSE3)
>>   #define cpu_has_pclmulqdq       boot_cpu_has(X86_FEATURE_PCLMULQDQ)
>>   #define cpu_has_monitor         boot_cpu_has(X86_FEATURE_MONITOR)
>> -#define cpu_has_vmx             boot_cpu_has(X86_FEATURE_VMX)
>> +#define cpu_has_vmx             (IS_ENABLED(CONFIG_INTEL_VMX) && \
>> +                                 boot_cpu_has(X86_FEATURE_VMX))
> 
> I'm pretty sure using_vmx() was introduced precisely to avoid the use of
> IS_ENABLED() here. What is completely missing from the description is a
> discussion of the effect of this change on pre-existing uses of the
> macro. ISTR there being at least one instance which would break with
> that change. And no, I'm not looking forward to digging that out again,
> when I already did at the time the using_vmx() was suggested and then
> implemented. (I can't exclude it was the SVM counterpart; we want to
> keep both in sync in any event, imo.)

Thank you for your comments and sorry for not digging into the history of
the related patches.

All, please ignore these patches as existing places. where cpu_has_vmx/smv
are still used, need to be revised one by one.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Tue Sep 16 17:14:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 17:14:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124750.1466970 (Exim 4.92)
	(envelope-from )
	id 1uyZGE-0002Vg-I6; Tue, 16 Sep 2025 17:14:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124750.1466970; Tue, 16 Sep 2025 17:14: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 1uyZGE-0002VZ-Et; Tue, 16 Sep 2025 17:14:34 +0000
Received: by outflank-mailman (input) for mailman id 1124750;
 Tue, 16 Sep 2025 17:14:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uyZGD-0002VT-Om
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 17:14:33 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uyZGA-00Ct9c-0X;
 Tue, 16 Sep 2025 17:14:30 +0000
Received: from [149.199.65.200] (helo=[10.10.151.52])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uyZGA-00CzYu-0u;
 Tue, 16 Sep 2025 17: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:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=EOMrII1z1zQLRHCl1sFMtAmD+D/WioEXgF5lO/GymEY=; b=wcsUuFAEycHnTVEzJBexSJV0HW
	GW4wjy/rEzIXnXs+mJRZ/aw3j7Ht/yxW9dV76O7ZlvyPmPYmjuBNkVsrX4QQh1SQbt4gTH8L+Qtit
	XxK1l/6Kglqw8F7ZDYgi13qB8o30tZnWZjJ8q3Zc3SOevd4VPhNRpK3PzaUR7pEWBv1g=;
Message-ID: <88cc4cf1-3bc9-47f5-b8f7-e04f01b027ee@xen.org>
Date: Tue, 16 Sep 2025 10:14:29 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
To: Grygorii Strashko ,
 Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Oleksii Kurochko ,
 "xen-devel@lists.xenproject.org" 
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
 <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
 
Content-Language: en-GB
From: Andrew Cooper 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/09/2025 9:57 am, Grygorii Strashko wrote:
> Hi Jan,
>
> On 16.09.25 17:34, Jan Beulich wrote:
>> On 16.09.2025 12:32, Grygorii Strashko wrote:
>>> From: Grygorii Strashko 
>>>
>>> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX
>>> dependency") the
>>> HVM Intel VT-x support can be gracefully disabled, but it still
>>> keeps VMX
>>> code partially built-in, because HVM code uses mix of:
>>>
>>>   - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_VMX cfg
>>>   - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX cfg
>>>
>>> for runtime VMX availability checking. As result compiler DCE can't
>>> remove
>>> all, unreachable VMX code.
>>>
>>> Fix it by sticking to "cpu_has_vmx" macro usage only which is
>>> updated to
>>> account CONFIG_INTEL_VMX cfg.
>>>
>>> Signed-off-by: Grygorii Strashko 
>>> ---
>>> Hi
>>>
>>> It could be good to have it in 4.21, so vmx/svm disabling
>>> option will be in complete state within 4.21 version.
>>
>> Imo this isn't release critical and has come too late. It's of course
>> Oleksii's call in the end.
>>
>>> --- a/xen/arch/x86/include/asm/cpufeature.h
>>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>>> @@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>>>   #define cpu_has_sse3            boot_cpu_has(X86_FEATURE_SSE3)
>>>   #define cpu_has_pclmulqdq       boot_cpu_has(X86_FEATURE_PCLMULQDQ)
>>>   #define cpu_has_monitor         boot_cpu_has(X86_FEATURE_MONITOR)
>>> -#define cpu_has_vmx             boot_cpu_has(X86_FEATURE_VMX)
>>> +#define cpu_has_vmx             (IS_ENABLED(CONFIG_INTEL_VMX) && \
>>> +                                 boot_cpu_has(X86_FEATURE_VMX))
>>
>> I'm pretty sure using_vmx() was introduced precisely to avoid the use of
>> IS_ENABLED() here. What is completely missing from the description is a
>> discussion of the effect of this change on pre-existing uses of the
>> macro. ISTR there being at least one instance which would break with
>> that change. And no, I'm not looking forward to digging that out again,
>> when I already did at the time the using_vmx() was suggested and then
>> implemented. (I can't exclude it was the SVM counterpart; we want to
>> keep both in sync in any event, imo.)
>
> Thank you for your comments and sorry for not digging into the history of
> the related patches.
>
> All, please ignore these patches as existing places. where
> cpu_has_vmx/smv
> are still used, need to be revised one by one.
>

Off the top of my head, fixups to MSR_FEATURE_CONTROL, and AMD SKINIT
need cpu_has_vmx/svm not guarded by Kconfig like this.

~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Sep 16 17:37:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 17:37:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124764.1466980 (Exim 4.92)
	(envelope-from )
	id 1uyZcm-0005Sn-DO; Tue, 16 Sep 2025 17:37:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124764.1466980; Tue, 16 Sep 2025 17:37:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyZcm-0005Sg-9o; Tue, 16 Sep 2025 17:37:52 +0000
Received: by outflank-mailman (input) for mailman id 1124764;
 Tue, 16 Sep 2025 17:37:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uyZcl-0005Sa-GH
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 17:37:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uyZck-00CtYe-2w;
 Tue, 16 Sep 2025 17:37:50 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uyZck-00D11r-2r;
 Tue, 16 Sep 2025 17: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date:
	Subject:Cc:To:From; bh=4FipEdpCDftLa+r/OaA6uiqwWggjDvOFISDzRgT27hU=; b=F1VaWX
	M/FYPachbS/sNDMURLijZfIf38Oa+SaDZg+x7WUgX4S3GfJ+MzmHSq/xNdj36Gkam75xq0nMbDhi0
	OzvD1fcfqRQ9QndmoMBHjYIYReQHmlaGQCGPSeQK87hvfVIVJajDQq0PblDINJivyDU8yRc8zIxHr
	oLwl62jGNuk=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH] xen/domain: introduce DOMID_ANY
Date: Tue, 16 Sep 2025 10:37:03 -0700
Message-ID: <20250916173702.871508-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
of the code.

Update all relevant domid_alloc() call sites.

Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
Signed-off-by: Denis Mukhin 
---
CI link: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2043125323
---
 tools/tests/domid/harness.h             |  1 +
 tools/tests/domid/test-domid.c          | 12 ++++++------
 xen/common/device-tree/dom0less-build.c |  2 +-
 xen/common/domctl.c                     |  2 +-
 xen/common/domid.c                      |  2 +-
 xen/include/public/xen.h                |  3 +++
 6 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/tools/tests/domid/harness.h b/tools/tests/domid/harness.h
index 17eb22a9a854..610b564d4061 100644
--- a/tools/tests/domid/harness.h
+++ b/tools/tests/domid/harness.h
@@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
 
 #define DOMID_FIRST_RESERVED            (100)
 #define DOMID_INVALID                   (101)
+#define DOMID_ANY                       DOMID_INVALID
 
 #endif /* _TEST_HARNESS_ */
 
diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
index 5915c4699a5c..71cc4e7fd86d 100644
--- a/tools/tests/domid/test-domid.c
+++ b/tools/tests/domid/test-domid.c
@@ -41,20 +41,20 @@ int main(int argc, char **argv)
         domid_free(expected);
 
     /*
-     * Test that that two consecutive calls of domid_alloc(DOMID_INVALID)
+     * Test that that two consecutive calls of domid_alloc(DOMID_ANY)
      * will never return the same ID.
      * NB: ID#0 is reserved and shall not be allocated by
-     * domid_alloc(DOMID_INVALID).
+     * domid_alloc(DOMID_ANY).
      */
     for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == expected,
                "TEST 3: expected %u allocated %u\n", expected, allocated);
     }
     for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == DOMID_INVALID,
                "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated);
     }
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
         domid_free(expected);
     for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == expected,
                "TEST 5: expected %u allocated %u\n", expected, allocated);
     }
@@ -72,7 +72,7 @@ int main(int argc, char **argv)
     /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */
     expected = DOMID_FIRST_RESERVED - 1;
     domid_free(DOMID_FIRST_RESERVED - 1);
-    allocated = domid_alloc(DOMID_INVALID);
+    allocated = domid_alloc(DOMID_ANY);
     verify(allocated == expected,
            "TEST 6: expected %u allocated %u\n", expected, allocated);
 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 9fd004c42af7..e2764768c983 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -848,7 +848,7 @@ void __init create_domUs(void)
         if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
             panic("No more domain IDs available\n");
 
-        domid = domid_alloc(DOMID_INVALID);
+        domid = domid_alloc(DOMID_ANY);
         if ( domid == DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node));
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 954d79022645..ca91686a03d8 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -410,7 +410,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     case XEN_DOMCTL_createdomain:
     {
         /* NB: ID#0 is reserved, find the first suitable ID instead. */
-        domid_t domid = domid_alloc(op->domain ?: DOMID_INVALID);
+        domid_t domid = domid_alloc(op->domain ?: DOMID_ANY);
 
         if ( domid == DOMID_INVALID )
         {
diff --git a/xen/common/domid.c b/xen/common/domid.c
index 2387ddb08300..76b7f3e7ae6e 100644
--- a/xen/common/domid.c
+++ b/xen/common/domid.c
@@ -19,7 +19,7 @@ static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
  * @param domid Domain ID hint:
  * - If an explicit domain ID is provided, verify its availability and use it
  *   if ID is not used;
- * - If DOMID_INVALID is provided, search [1..DOMID_FIRST_RESERVED-1] range,
+ * - If DOMID_ANY is provided, search [1..DOMID_FIRST_RESERVED-1] range,
  *   starting from the last used ID. Implementation guarantees that two
  *   consecutive calls will never return the same ID. ID#0 is reserved for
  *   the first boot domain (currently, dom0) and excluded from the allocation
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 82b9c05a76b7..b0b2651eb4f0 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
 /* DOMID_INVALID is used to identify pages with unknown owner. */
 #define DOMID_INVALID        xen_mk_uint(0x7FF4)
 
+/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */
+#define DOMID_ANY            DOMID_INVALID
+
 /* Idle domain. */
 #define DOMID_IDLE           xen_mk_uint(0x7FFF)
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 16 17:47:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 17:47:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124776.1466989 (Exim 4.92)
	(envelope-from )
	id 1uyZmM-00076k-7o; Tue, 16 Sep 2025 17:47:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124776.1466989; Tue, 16 Sep 2025 17: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 1uyZmM-00076d-5D; Tue, 16 Sep 2025 17:47:46 +0000
Received: by outflank-mailman (input) for mailman id 1124776;
 Tue, 16 Sep 2025 17:47:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uyZmK-00076X-PR
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 17:47:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uyZmK-00CtjC-0S;
 Tue, 16 Sep 2025 17:47:44 +0000
Received: from [149.199.65.200] (helo=[10.10.151.52])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uyZmK-00D2BS-0p;
 Tue, 16 Sep 2025 17:47:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=aUAXBlScNakr70JycnQHDgroWAwqf/4C9+lIRfapDqw=; b=JZbb6Gu0S1S7++3RVXCfbhvep6
	UU3e9qjPvEad+GdLMMQ3qYe0UeWGMvV3MkfkVBy6efkSepWxkQSOyssnW3jxDWO6pFoik8D9OBgbi
	eMON3QEzQM0fhX8KAJknJqwlcCkQ4c3J0DdDjHUsWsHyCgWVD8pAcmcZBPHADvhiLCTo=;
Message-ID: <3cee106c-6398-4c42-939d-7d77db5a34c8@xen.org>
Date: Tue, 16 Sep 2025 10:47:42 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domain: introduce DOMID_ANY
To: dmukhin@xen.org, 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: <20250916173702.871508-2-dmukhin@ford.com>
Content-Language: en-GB
From: Andrew Cooper 
In-Reply-To: <20250916173702.871508-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/09/2025 10:37 am, dmukhin@xen.org wrote:
> From: Denis Mukhin  
>
> Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
> of the code.
>
> Update all relevant domid_alloc() call sites.
>
> Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
> Signed-off-by: Denis Mukhin 

Thankyou.  This is indeed far more coherent to read at the callsites.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 18:31:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 18:31:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124799.1466999 (Exim 4.92)
	(envelope-from )
	id 1uyaSP-0005Ak-Ce; Tue, 16 Sep 2025 18:31:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124799.1466999; Tue, 16 Sep 2025 18:31: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 1uyaSP-0005Ad-A7; Tue, 16 Sep 2025 18:31:13 +0000
Received: by outflank-mailman (input) for mailman id 1124799;
 Tue, 16 Sep 2025 18:31: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 1uyaSN-0005AX-Q0
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 18:31:11 +0000
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com
 [2607:f8b0:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 509eff98-932b-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 20:31:10 +0200 (CEST)
Received: by mail-pl1-x62f.google.com with SMTP id
 d9443c01a7336-25669596955so59838725ad.0
 for ; Tue, 16 Sep 2025 11:31:10 -0700 (PDT)
Received: from [10.10.151.246] ([149.199.65.200])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-25eda9b0124sm119997295ad.72.2025.09.16.11.31.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 11: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: 509eff98-932b-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758047469; x=1758652269; 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=1TBGeBwXSx1uoROCbnURu50DazYBBHG6c4DxP1O6kH0=;
        b=UXBrVg1yxZ8pG6VvNxo71nYFRjjHi5dGV2UopYtcArpVr6yt69Su/POPYHF6YiTQvH
         EYl2C5P9FiJGgYYPV8uCYXUMhd4FjT84aqbFFiAQo1v9fbEMJPYZNjcKa1Pw7E/cNkY0
         R0/3YqruYr0wU6xK1EYOPaF23fNR+ILXmnzdedRKkvIzxrffRGjyu3UXei4roUjzXti7
         mnhai575APUXiQDzwoZKZmjJzrsaTMfgCGKaoZk/QJlrs7GaY4LZ9qr53mrQDpBJZKUE
         hVdAcmIFGTj67g1I6YcAO404ImLz/v8UDWAc8hDwzpoMnKKSbgiUKdJcK1YnRqsx4Ls/
         Mwcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758047469; x=1758652269;
        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=1TBGeBwXSx1uoROCbnURu50DazYBBHG6c4DxP1O6kH0=;
        b=N7+pWmofjyJHKDNUDKmxR29MCOhtJ8E49yZYuIJ32UJWOOXMB5mZCmavVvntE+vCZt
         UlmR6p+PzCnx+uKnOB0I+PhsARslOtkLLUzT1ovk5XLszTBMBivtnTtJPXie3z9bpm6n
         nc0JhZVD7v23ZJgAMH5loshUOT/mN4gkvaJfQf7os8gt76Cy2dw93mzprQ7aBKwzlp+D
         W7ykvoPqcHQubNPLbcygzsXnatuAweeXJAwPhw0pFtaSc2dLY9RKRigRWFnhGXcwYwOZ
         w7XQUmkz+r9d08yBJwt/Bbd3AfAz32rlUBCwLOEZRPgh16B+qKWumMJZVpf7LTUBvhFw
         RysA==
X-Forwarded-Encrypted: i=1; AJvYcCXhr7WOmxCiFUxBJy0C+47piItCg6JgaLWuQ48VC8YX+tvYrUs4fGvv9dX+ZJBPe2AV6oYSQTrGlx8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygPzWtGdCahopr1MWG5coDD1zk8MWEg43SVJxEUyxdRyxhLei2
	kmrFbv+qxtUz2JgVzc7LIJ5P2dd4KY3VI5SmlHh0qRwqNkdS8oRRgPK6
X-Gm-Gg: ASbGncthemCBZBXmCofAZPKZygt+Mihypo2xTinlCz9+9gKXtZa2AyoCXoNsP77z8Ae
	fjlmhus33JLrXVF+jlkCBf/ltwOPpqMt6P7mZcD2L2dRFk28DMeQBJ8K4WWpS57GXC/HaQJSIih
	w5EGTbR6Whillw1CcmdT6wYlQPHD/QxmHt1mzORl0pXP+77vAl+By7YokAxKUJKYOrcxUKSojz1
	4LvyXbi4vdQkXH7dMnVE0/am/A844wJxtpnnSrTrk4HlqilLpxC48wj6J8PL2Gr9Z8Rb5BQpYB7
	kAYwSIXcGUk51SUc0Jd2e/x3IKhowfgvMuUGjJUb7miKYoG08r7MJZwvR4AGYNxFvwR/It0/5M6
	X6FgHp/54jl4MJQysk0TFoXPpEg18HdPYkT4pBQ==
X-Google-Smtp-Source: AGHT+IH24HN0gRp38x/CwoPNtQwk77aV2jl8+TCzQmBTyUm+LGfWDkwSSUsKRYleiWpZuQg+1ojprg==
X-Received: by 2002:a17:902:dace:b0:264:f3ed:ee2c with SMTP id d9443c01a7336-264f3edf689mr128336455ad.12.1758047468522;
        Tue, 16 Sep 2025 11:31:08 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------xjFVMHajgA0MTdDKb0qO8m7v"
Message-ID: <364993ef-cff8-4967-8f0c-d7d3adf132d8@gmail.com>
Date: Tue, 16 Sep 2025 20:31:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH 2/2] x86: hvm: svm: fix runtime svm presence check
 for !CONFIG_AMD_SVM case
To: Grygorii Strashko ,
 "xen-devel@lists.xenproject.org" 
Cc: Jan Beulich , Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Alejandro Vallejo 
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
 <20250916103251.2144449-2-grygorii_strashko@epam.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250916103251.2144449-2-grygorii_strashko@epam.com>

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


On 9/16/25 12:32 PM, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
> AMD-V support can be gracefully disabled, but it still keeps SVM
> code partially built-in, because HVM code uses mix of:
>
> - "cpu_has_svm" macro, which doesn't account for CONFIG_AMD_SVM cfg
> - "using_svm()" function, which accounts for CONFIG_AMD_SVM cfg
>
> for runtime SVM availability checking. As result compiler DCE can't remove
> all, unreachable SVM code.
>
> Fix it by sticking to "cpu_has_svm" macro usage only which is updated to
> account CONFIG_AMD_SVM cfg.
>
> Signed-off-by: Grygorii Strashko
> ---
> Hi
>
> It could be good to have it in 4.21.
>
> bloat-o-meter:
> add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-98 (-98)
> Function                                     old     new   delta
> guest_flush_tlb_flags                         71      62      -9
> init_speculation_mitigations               10024   10011     -13
> hvm_set_efer                                 364     288     -76
> Total: Before=3656835, After=3656737, chg -0.00%

It doesn't seem critical for the current release stage, so let's consider these
changes for 4.22.

Thanks.

~ Oleksii

>
>   xen/arch/x86/domain.c                 | 4 ++--
>   xen/arch/x86/hvm/hvm.c                | 2 +-
>   xen/arch/x86/hvm/nestedhvm.c          | 2 +-
>   xen/arch/x86/include/asm/cpufeature.h | 3 ++-
>   xen/arch/x86/include/asm/hvm/hvm.h    | 5 -----
>   5 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 19fd86ce88d2..92661527eb75 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1824,7 +1824,7 @@ static void load_segments(struct vcpu *n)
>           if ( !(n->arch.flags & TF_kernel_mode) )
>               SWAP(gsb, gss);
>   
> -        if ( using_svm() && (n->arch.pv.fs | n->arch.pv.gs) <= 3 )
> +        if ( cpu_has_svm && (n->arch.pv.fs | n->arch.pv.gs) <= 3 )
>               fs_gs_done = svm_load_segs(n->arch.pv.ldt_ents, LDT_VIRT_START(n),
>                                          n->arch.pv.fs_base, gsb, gss);
>       }
> @@ -2142,7 +2142,7 @@ static void __context_switch(void)
>   
>   #ifdef CONFIG_PV
>       /* Prefetch the VMCB if we expect to use it later in the context switch */
> -    if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
> +    if ( cpu_has_svm && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
>           svm_load_segs_prefetch();
>   #endif
>   
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 57d09e02ed0f..330103ddf386 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -160,7 +160,7 @@ static int __init cf_check hvm_enable(void)
>   
>       if ( cpu_has_vmx )
>           fns = start_vmx();
> -    else if ( using_svm() )
> +    else if ( cpu_has_svm )
>           fns = start_svm();
>   
>       if ( fns )
> diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
> index c6329ba2e51a..d895a738448c 100644
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -157,7 +157,7 @@ static int __init cf_check nestedhvm_setup(void)
>        */
>       if ( cpu_has_vmx )
>           start_nested_vmx(&hvm_funcs);
> -    else if ( using_svm() )
> +    else if ( cpu_has_svm )
>           start_nested_svm(&hvm_funcs);
>   
>       return 0;
> diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h
> index f42e95586966..ce7dc1ddad0a 100644
> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
> @@ -165,7 +165,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>   
>   /* CPUID level 0x80000001.ecx */
>   #define cpu_has_cmp_legacy      boot_cpu_has(X86_FEATURE_CMP_LEGACY)
> -#define cpu_has_svm             boot_cpu_has(X86_FEATURE_SVM)
> +#define cpu_has_svm             (IS_ENABLED(CONFIG_AMD_SVM) && \
> +                                 boot_cpu_has(X86_FEATURE_SVM))
>   #define cpu_has_sse4a           boot_cpu_has(X86_FEATURE_SSE4A)
>   #define cpu_has_xop             boot_cpu_has(X86_FEATURE_XOP)
>   #define cpu_has_skinit          boot_cpu_has(X86_FEATURE_SKINIT)
> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
> index 0fa9e3c21598..24a7ed88567b 100644
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -383,11 +383,6 @@ int hvm_copy_context_and_params(struct domain *dst, struct domain *src);
>   
>   int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value);
>   
> -static inline bool using_svm(void)
> -{
> -    return IS_ENABLED(CONFIG_AMD_SVM) && cpu_has_svm;
> -}
> -
>   #ifdef CONFIG_HVM
>   
>   #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
--------------xjFVMHajgA0MTdDKb0qO8m7v
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/16/25 12:32 PM, Grygorii Strashko
      wrote:

    

    

      
From: Grygorii Strashko <grygorii_strashko@epam.com>

Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
AMD-V support can be gracefully disabled, but it still keeps SVM
code partially built-in, because HVM code uses mix of:

- "cpu_has_svm" macro, which doesn't account for CONFIG_AMD_SVM cfg
- "using_svm()" function, which accounts for CONFIG_AMD_SVM cfg

for runtime SVM availability checking. As result compiler DCE can't remove
all, unreachable SVM code.

Fix it by sticking to "cpu_has_svm" macro usage only which is updated to
account CONFIG_AMD_SVM cfg.

Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
---
Hi

It could be good to have it in 4.21.

bloat-o-meter:
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-98 (-98)
Function                                     old     new   delta
guest_flush_tlb_flags                         71      62      -9
init_speculation_mitigations               10024   10011     -13
hvm_set_efer                                 364     288     -76
Total: Before=3656835, After=3656737, chg -0.00%

    

    
It doesn't seem critical for the current release stage, so let's consider these
changes for 4.22.

Thanks.

~ Oleksii


    

      

 xen/arch/x86/domain.c                 | 4 ++--
 xen/arch/x86/hvm/hvm.c                | 2 +-
 xen/arch/x86/hvm/nestedhvm.c          | 2 +-
 xen/arch/x86/include/asm/cpufeature.h | 3 ++-
 xen/arch/x86/include/asm/hvm/hvm.h    | 5 -----
 5 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 19fd86ce88d2..92661527eb75 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1824,7 +1824,7 @@ static void load_segments(struct vcpu *n)
         if ( !(n->arch.flags & TF_kernel_mode) )
             SWAP(gsb, gss);
 
-        if ( using_svm() && (n->arch.pv.fs | n->arch.pv.gs) <= 3 )
+        if ( cpu_has_svm && (n->arch.pv.fs | n->arch.pv.gs) <= 3 )
             fs_gs_done = svm_load_segs(n->arch.pv.ldt_ents, LDT_VIRT_START(n),
                                        n->arch.pv.fs_base, gsb, gss);
     }
@@ -2142,7 +2142,7 @@ static void __context_switch(void)
 
 #ifdef CONFIG_PV
     /* Prefetch the VMCB if we expect to use it later in the context switch */
-    if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
+    if ( cpu_has_svm && is_pv_64bit_domain(nd) && !is_idle_domain(nd) )
         svm_load_segs_prefetch();
 #endif
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 57d09e02ed0f..330103ddf386 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -160,7 +160,7 @@ static int __init cf_check hvm_enable(void)
 
     if ( cpu_has_vmx )
         fns = start_vmx();
-    else if ( using_svm() )
+    else if ( cpu_has_svm )
         fns = start_svm();
 
     if ( fns )
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index c6329ba2e51a..d895a738448c 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -157,7 +157,7 @@ static int __init cf_check nestedhvm_setup(void)
      */
     if ( cpu_has_vmx )
         start_nested_vmx(&hvm_funcs);
-    else if ( using_svm() )
+    else if ( cpu_has_svm )
         start_nested_svm(&hvm_funcs);
 
     return 0;
diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h
index f42e95586966..ce7dc1ddad0a 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -165,7 +165,8 @@ static inline bool boot_cpu_has(unsigned int feat)
 
 /* CPUID level 0x80000001.ecx */
 #define cpu_has_cmp_legacy      boot_cpu_has(X86_FEATURE_CMP_LEGACY)
-#define cpu_has_svm             boot_cpu_has(X86_FEATURE_SVM)
+#define cpu_has_svm             (IS_ENABLED(CONFIG_AMD_SVM) && \
+                                 boot_cpu_has(X86_FEATURE_SVM))
 #define cpu_has_sse4a           boot_cpu_has(X86_FEATURE_SSE4A)
 #define cpu_has_xop             boot_cpu_has(X86_FEATURE_XOP)
 #define cpu_has_skinit          boot_cpu_has(X86_FEATURE_SKINIT)
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index 0fa9e3c21598..24a7ed88567b 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -383,11 +383,6 @@ int hvm_copy_context_and_params(struct domain *dst, struct domain *src);
 
 int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value);
 
-static inline bool using_svm(void)
-{
-    return IS_ENABLED(CONFIG_AMD_SVM) && cpu_has_svm;
-}
-
 #ifdef CONFIG_HVM
 
 #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)


    

  


--------------xjFVMHajgA0MTdDKb0qO8m7v--


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 19:36:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 19:36:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124817.1467009 (Exim 4.92)
	(envelope-from )
	id 1uybSx-0004Ff-Tk; Tue, 16 Sep 2025 19:35:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124817.1467009; Tue, 16 Sep 2025 19:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uybSx-0004FY-Qn; Tue, 16 Sep 2025 19:35:51 +0000
Received: by outflank-mailman (input) for mailman id 1124817;
 Tue, 16 Sep 2025 19: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 1uybSw-0004FS-B0
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 19:35:50 +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 58b6e26f-9334-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 21:35:48 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by AS8PR03MB8103.eurprd03.prod.outlook.com (2603:10a6:20b:446::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.13; Tue, 16 Sep
 2025 19:35:45 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9115.020; Tue, 16 Sep 2025
 19:35: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: 58b6e26f-9334-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ouGrjqbScgE8Xjgw1XYz+XNpkj/CJehELmsBxI1P7mvlwxP18Mz1+yd4/E7gL//OmmXKh+LYbDr+AlgEX/NBvyhj8aYNHWy9fumCUO4wvzAXR3GYbAPyW4yV7xO+Dsrn3QBtuvUPL73c2RHPdjl+FRccWduFc/FXaJQUBWdSTTt5Pnr1cju5+/Hip61hrYhb5RroiGdcuFRz3zFdoAu/cLCzEKe/XQDjr4PWR8nwdmvrzisYwdZrBE/F+U/7Eh5nMJFJ1KO08fD1my504Hd00dBFDj688gTazpHfyLw63esKBEVVkJcWpcK1sjQv2GgLtMdmOzfZT11QegcVoXiCFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XO9Ci9v8RoygCBNXTpGGWjmCTKLPTHUrEUbQDhQ1Dtc=;
 b=Wzf8IkEKjB8NB6QvQe/ih74P5ZidSGEk+tNCcG41nBam+hzxe3Ow7ByINwI7iDaWsW3OtBnQ/tINhg7hdoufIccRIPa240RFJLwA44Fo2wGCIJzjPibi3CfwpyN6SYeKr/9dcIWgNVFeencjdLbHWdLeafmy0ykRkW1VZJdjvf3EiyBnVxFLhpHTgBVzNXTOX5AqXbXiTSIZpCtPzGJAs7Tx7U4XaTyea5sExQSO3dyhPPdttOaR0b9ASNjyqTRXLyVJbTA7tnJ9dM6cMEldmYpX2dijRFuwVYm/9hZLgmXT2ZvoHdeTSttlvv5v5fcH+B73bdZjAuEVCK7Rel3b3A==
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=XO9Ci9v8RoygCBNXTpGGWjmCTKLPTHUrEUbQDhQ1Dtc=;
 b=hSAILHY+6Nth7466yDTcmwqQXwR0FQCz/4q6h3LlJK4BU6ar9vuV8p+azzhBkZQay8n79TLXclL87+AhW/0bz/B0oTrkSMIsajWzAicXbBGUzScqQpo0YUB8DsxR1uhRPquP2YkQEdfBVa2/VDVegbEODuHml42wnz7FifIfoUzrBGzOUaFu7LvzD3RGk+UcJldp8x7hk+JbO+BcHTVkugJwBGah/FutZGolUpVgOKpJPT+EFQD09GcV429s+Eneaz0oUdnKQBOzTgOpB5PgrL5zkBXy41lZYztsXc4MDINEVZc7qzPbDQYN533jdbFsC86aFGA5VfnDHDukmj/Z4Q==
From: Dmytro Prokopchuk1 
To: Jan Beulich 
CC: Nicola Vetrini , Doug Goldstein
	, Stefano Stabellini , Andrew
 Cooper , Anthony PERARD
	, Michal Orzel , Julien
 Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Topic: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Index: AQHcJwfEWjVU7vF+102YDgRq9OEY77SV3fSAgABWKoA=
Date: Tue, 16 Sep 2025 19:35:44 +0000
Message-ID: 
References:
 <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
 
In-Reply-To: 
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: GV2PR03MB9572:EE_|AS8PR03MB8103:EE_
x-ms-office365-filtering-correlation-id: 1219ee55-f0d8-452a-eb2c-08ddf5583abb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|366016|1800799024|7416014|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?YTI4blYwaitxWjhkRHhZUlR0ME1mYjNzdkNJSXpzSmwrR0crcmpxN1kvNGxI?=
 =?utf-8?B?dzV1eVZ6aVpKa2d5SWovUWVFNkw5SWcwY2xwYVBZNUhkb2FScHE4WjVpK0lP?=
 =?utf-8?B?TnY5ZW1FYkZna1NvQ2hpV3IzMTM0Q1YweVdzMFVKVU5kbWNXbVljNTNUTk1O?=
 =?utf-8?B?QytwMDBUOEhzZGtYbUJldEQ3bjd1a3kxSGdOZ0JDK2lQWkpmVlNSSkx4N1pK?=
 =?utf-8?B?NW51cnNtU3Q1azArMzIvZFo1bHBtbDk4Z3BTM0s1S0I1RXpKQWo2NTQyRnNP?=
 =?utf-8?B?MmhaVkN2dzVoMXlkVWRGaUFWdE1EMHJNMDRNK0ZPUUZXZVNGVHp6K1RIMmdQ?=
 =?utf-8?B?b1RRMld1Q2NiZmhLdjlDNkZmVmJSc3Jwcm5MR1hTK0dyTkhZSzNGNHllZ0c2?=
 =?utf-8?B?MDBqSW9UWlRmUDljRml0MnVWaGN2U3JqZ1BjQUlPUjJFSmhyL1NrRG9ZTWli?=
 =?utf-8?B?STdJYlRSb2VubWZCZURlMDVOK3RGTGxCdEExQVJZakVRMStObDNtTXBKaWg2?=
 =?utf-8?B?MmkvaDJ2ZjJqR3p3aTlrUmJMa05NUXE1S214MDJtNmxwU3hZTnZpM0RZSWI5?=
 =?utf-8?B?SHI0d0VNK0R0VDFDaHM1NmJzQVZHcVBLRFRuOTlWaFNOK21JK1FXV2RBYlBD?=
 =?utf-8?B?NlExcXhxL0tRR1hwa05jY1FtSWVBNzFOR2M2emJ4bUFROHFkaUFkNm1jTms2?=
 =?utf-8?B?N2NKZkpuemQ4R1M3VWpDTWU4U2tJMHZEeUd1Q1RRY2RIbWZwNUk3MTJ4QzN6?=
 =?utf-8?B?SVZIZHRraWY1dExadkM2ejBNZ29YM3dBNkRIKzlmNWJuTGkrQTFjZ2JFZWMx?=
 =?utf-8?B?ak0yTDFibnVjR25XVHdqSUQxSGlUQnNDdC9QVGFuTDdwdHd1YXl3K0NoKzR6?=
 =?utf-8?B?SCt6ZHIwcmpXdmJMaHRhVFBKWFZ3ZUNxcGdNK3Y1MnR2TXh5S1ZMRjVQVFFl?=
 =?utf-8?B?aTVhYVBVcG1GRkI1MGNNTzJpL0VjaVp6Zzd2ek96U1g0bFFNa0ZnMDEzdEc2?=
 =?utf-8?B?VFk1ZjFaYURzb1NCbXVCZmlCTk90OFNhWlNydWc2dW5vdjZBVXNaUWFjNWFE?=
 =?utf-8?B?aVBNa2ZhZFRYZnVpNUtiSHdYMFU5aWdWb2FiNWNzSEtsTGNIQ0ZMY3hrU1BB?=
 =?utf-8?B?cFdQS2FyQWZjaEtuL3RXbjJiL0RXUHJ3QVNqL1oyZEowdTkxbUpBc3pGNHNy?=
 =?utf-8?B?T3ptSzlTOXRnSXBtQ1ZUaG0vZGZOR2prelRvK2ZVL2x1cG4xQktKbkNaYjNz?=
 =?utf-8?B?WWxmVHU1aXdPK2tPYVdtd3BLbFFISnRxcmh6Sml5eHlKZnhKc1Q4Z3pZMFdt?=
 =?utf-8?B?d2dockQxeFRjWlphdmhYaXRiWEg0L0dBQmx1QzVFaXpIM2plclFkcWxWMWIx?=
 =?utf-8?B?M1laNm40TW1IL1VSYlBQZ1pyczdGUEJVZ1BSYlB2VlprcWxrd3JRQXRqT0d2?=
 =?utf-8?B?UEM4R0RwbURwaytTbWNLSnJSZ0hIOElsWk9YeFRWMG55UldOV0g4cElUUW9K?=
 =?utf-8?B?WmRDaEhTSkM0T29Ob1pESGNVc1R5c3diZkkwWk9YanZ2azhiRno4cy8wZVBn?=
 =?utf-8?B?K2FNdjhkRks5Q0FEZlRPVkx1d2tZSDFNNDJQUCtqV1c0RjZNWktJeGhpRGYz?=
 =?utf-8?B?RG56QzdwZHdLZlJDSU01REx2Wkd4MW9JcFNGWVVOaDVtbVFicHpwYmdrVUVt?=
 =?utf-8?B?Z3lCMURXMU1RdGRnZ2JIQkdqb1k4ejY5dExHVlYzTXlWRkJtZ1V0dWV1TFdX?=
 =?utf-8?B?eGZFL3dqMGlZRTNNMjFkTkNROFVVSU1TNzRCQVNkZHlRZHZGc2JYaVNYQ0po?=
 =?utf-8?B?Y3NHUmpNTEdoZWhRQ2FGbzZXNFhiMzdCbGF5YkRraHduejJnY1YrTW9tbVZI?=
 =?utf-8?B?aDE2SDNxT0pYTTQ5Y2tXY01JVnhyaUhUR2tnRE1CaHRBZjFPYkhLeVYyU2ZM?=
 =?utf-8?B?RDJPbnlnaHMzUTRMYmI4YjFndXplVVlaa1FiekpJOHJPM0J1YU5rSnMza1FC?=
 =?utf-8?Q?dNLEiyGTk8I8/Vb2g4O1c6OV5qNBDQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(366016)(1800799024)(7416014)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Sjgrb3E3aTlOU2dXNm9TUDlnMy9sNXU0UktZQW1qR1cwWDFkU3FFM3pMTk1p?=
 =?utf-8?B?YzhwKzI4VER0cVVIRjFkQ3dpOWw1SnVWdVN4SG5FZDQrUWZ3bWpEZHpBaSsv?=
 =?utf-8?B?YkdVeWdjWjUxYURiT0pHQmpVN0pxc3lIaXE3M1g5eUdFaFFIYy82eTUxU1oz?=
 =?utf-8?B?QjFNdTBnU21iSS9NOE00eHNoVnhycGF2S3dKWDhybjB4OU4xNm9nTmRxOXAv?=
 =?utf-8?B?VmVIbTllcmdWQUZFQngyLzhhMmFMOGQzMSthVWhmODl2YlVzdjFWbitUeUc5?=
 =?utf-8?B?UklHT2RUTDFnK2dtV3Y2Zy9XTm9HRW5jNGhpY3g0NWoyM1RMdS8ybnNNTXFB?=
 =?utf-8?B?UjZNOGdUQm43UzZHc2MycVNFUXQzVGllWU5FTTVtZGUyeXIyOVRNUk9hZzV0?=
 =?utf-8?B?VWJXWUlBZk0xbjd2b0YxdHZYZGlVWWJydkxPdlFlRTV0dmxoM3ZCOUdPTlhP?=
 =?utf-8?B?MWhYUGNycmhUd1VBQ2x6OEluU3VZOElSZThtSW1FZXV3endNZ1B0N2Nsc05F?=
 =?utf-8?B?ZmM2QTRSMWxuQU5iYW9ZYWxnUmJvc21vbWZCTkUrMSs3L3dZQ2hoYUl4MTg4?=
 =?utf-8?B?YmJTVWZWY242a2x2bHI2OG4vaGtPRU1DdGRNRytxRjhoWVUxbWFyV0pOVGM1?=
 =?utf-8?B?UUoyVCsyby90ZWtTUHAvVGh1L01GR3Z4cC92VW5qRlNQckUxdmIxNis3NTl5?=
 =?utf-8?B?eGplcXJDVGZMKzJ4RnhyQVNrT3FTVFlGcW9BQjJlbjM2Uk9IOVk5SXVkaVBE?=
 =?utf-8?B?Q0lhNlNrS3ZHWnpCRkJsV3U0OHNKQmJMYWh5cUtuK0RWSGh1YVpaS3BUN2Vr?=
 =?utf-8?B?b2t0K2UrL3AxTjRvbjJLNjRWWUtlWWpZQWV2allZbWY4SWdpT245YTRxSFUv?=
 =?utf-8?B?NWRZWWhNdk9iVFcyNDFYMUVwV0NsUmhCZGovazBEUWVTTDc2dXQwV2t3Z3hj?=
 =?utf-8?B?dEZoL1QyL0tUNDhSbXAwaExRLzJJQUg1dTNRWjBRQXN1dUJXelkxM2t4T1VE?=
 =?utf-8?B?clVGVnRPYWtVU2tuSTBIUXpDOSszWGFYZ3dpbkxONGM2TWxKZlRyN3ZnZWN1?=
 =?utf-8?B?MGQremVoQlVCRkFvbWlwcE5OUms4bXJDWmdpeFdYejV5dUdKOTZtQVcwYlRC?=
 =?utf-8?B?TmY1aHhXNGNGRTJ1azMzdkh6NTBVdjVMTU5ZcGg3Z2dLaEpBaFpBWGRibk10?=
 =?utf-8?B?clQwTDRGR1k1U0RjRDFQMk96Tlp6YkRiQkdPMGJYS2FPaGdLa0t0NHBtSnZ3?=
 =?utf-8?B?dkdjM3RWUCs1QTFYckhVVVd3cGdPZDZ2SXRRdG5OaERoRVphamoyM0xBOTl3?=
 =?utf-8?B?TGNRQXBKcm9zaW5RZUx3NnVQZURSMDdYQk44cE5yeVVocnRncW5NREN0L3VN?=
 =?utf-8?B?d1BGTnNPWjF1SllGRmhKRXd4d3lVL1BZNTBtdCtSd1Q4N2NrcGMyZEpzcytr?=
 =?utf-8?B?T2tCU210VXpaTWFHODloT2VwQ1BFVnJCdWlNd1ZhTnp1Q3FubGUrZERUM244?=
 =?utf-8?B?bzhiTDUrVjVWT2RQRlFGNzMrNkhZalRBNWtBRUVkRWREenJWUE16VFY3UVJW?=
 =?utf-8?B?MWxIWWlrQldGZTJkMXFQT2hYQzZqbzh5TXFHRTVBYkY2bnRLandZbkFNb0Jy?=
 =?utf-8?B?ejV0NnZGYUVaUWI1U2dTRlV3ZFhqdk5BMGhTejdwSU5VK2dVeUxZVE1NczJL?=
 =?utf-8?B?NjM4WFo3c0gzZitWcTdzZmsvNnk2OGtsMVdvT3RKVnlYSVJ0Tzl0WkIwbzI0?=
 =?utf-8?B?aE90bmVsYzVORVI4dHB6ZUs1c25oV0l5ay9samphbmJSVTBkL0lZWExNbFlX?=
 =?utf-8?B?RTF6THNBRzBJanQzZExOVkp4MjRFalJNWXJtUSswbXJpNFJjTDBQNFEvUlFl?=
 =?utf-8?B?NXFkYXV6TXBsY1RSbGt3Z1JWeUNydVFMK29Xd3FuWHk5V1hSamhob1IxN2gz?=
 =?utf-8?B?QUJMMkZOa2JncDJ2TXdVREVwL05wNTZYZFVRMHd5emlnMExKMlhPRUhTTTY0?=
 =?utf-8?B?LzBUUmduVHEyWmMvSjh4VUJLa1BUY1BId3dDbmNrSmN5Z3JVYWZwNWZZTnNh?=
 =?utf-8?B?NVQ0Z1lVMHA1RTQ4SU4yN3oyVXZmVjdCcXZpSkZHK09GLyt3TXhVZVVWSkg0?=
 =?utf-8?B?VnRaeHJpT2lqQVU3WmJmQmd4R3ppeUIvaDRqK0xBZ3IxUThtMUx3T1hZdjc1?=
 =?utf-8?B?RWc9PQ==?=
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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1219ee55-f0d8-452a-eb2c-08ddf5583abb
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2025 19:35:44.7547
 (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: hjwRUzPo6GiwJfO8f8e3E3yt8+LGSpX02J+VgK4AxHtSqJF0rJESSIP+pTEJhxR5ET/EoYCfZJgn16n7w2g+zwfmKR5uzsKBWdO36xsJVws=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8103

DQoNCk9uIDkvMTYvMjUgMTc6MjcsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNi4wOS4yMDI1
IDE0OjQ1LCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+PiAtLS0gYS9kb2NzL21pc3JhL2Rl
dmlhdGlvbnMucnN0DQo+PiArKysgYi9kb2NzL21pc3JhL2RldmlhdGlvbnMucnN0DQo+PiBAQCAt
OTgsNiArOTgsMjMgQEAgRGV2aWF0aW9ucyByZWxhdGVkIHRvIE1JU1JBIEM6MjAxMiBSdWxlczoN
Cj4+ICAgICAgICAgIGV2ZW4gd2hlbiBkZWJ1Zy1vbmx5IGFzc2VydGlvbnMgbGlrZSBgQVNTRVJU
X1VOUkVBQ0hBQkxFKClgIGFyZSByZW1vdmVkLg0KPj4gICAgICAgIC0gRUNMQUlSIGhhcyBiZWVu
IGNvbmZpZ3VyZWQgdG8gaWdub3JlIHRob3NlIHN0YXRlbWVudHMuDQo+PiAgIA0KPj4gKyAgICog
LSBSMi4xDQo+PiArICAgICAtIEluIHRoZSBzcGVjaWZpYyBidWlsZCBjb25maWd1cmF0aW9uICh3
aGVuIHRoZSBjb25maWcgQ09ORklHX0FDUEkgaXMgbm90DQo+PiArICAgICAgIGRlZmluZWQpIHRo
ZSAnQlVHKCknIG1hY3JvIGlzIGludGVudGlvbmFsbHkgdXNlZCBpbiB0aGUgJ3ByZXBhcmVfYWNw
aSgpJw0KPj4gKyAgICAgICBmdW5jdGlvbiBpbiB0aGUgaGVhZGVyIGZpbGUgJ3hlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9kb21haW5fYnVpbGQuaCcNCj4+ICsgICAgICAgZGVmaW5lZCBhcyAnc3Rh
dGljIGlubGluZScgdG8gdHJpZ2dlciBhIHJ1bnRpbWUgZXJyb3IgaWYgQUNQSS1yZWxhdGVkDQo+
PiArICAgICAgIGZlYXR1cmVzIGFyZSB1c2VkIGluY29ycmVjdGx5Lg0KPj4gKyAgICAgLSBUYWdn
ZWQgYXMgYGRlbGliZXJhdGVgIGZvciBFQ0xBSVIuDQo+IA0KPiBJIHJlc3BvbnNlIHRvIG1lIG91
dGxpbmluZyBhIGRldmlhdGlvbi1sZXNzIGFsdGVybmF0aXZlIHlvdSB0cmllZCBpdCBvdXQNCj4g
YW5kIHNhaWQgaXQgd29ya3MuIFRoZW4gd2h5IGlzIHRoZSBkZXZpYXRpb24gc3RpbGwgYmVpbmcg
cHV0IGluIHBsYWNlPw0KDQpZZXMsIHRoYXQncyB0cnVlLg0KSSBzdGFydGVkIHdpdGggdGhhdCBw
cmVwYXJlX2FjcGkoKSBmdW5jdGlvbiBhbmQgSSB0cmllZCB0byBtb3ZlIGl0IGludG8gDQp4ZW4v
aW5jbHVkZS94ZW4vYWNwaS5oIGhlYWRlciBmaWxlIHVuZGVyIGFwcHJvcHJpYXRlICNpZmRlZjoN
Cmh0dHBzOi8vZ2l0bGFiLmNvbS94ZW4tcHJvamVjdC9wZW9wbGUvZGltYXBya3A0ay94ZW4vLS9j
b21taXQvZDE1Y2Y5MWRlOTJmMWY4ZWM2NzkxMWM1MWExM2U3ZjA5NWMxYmNkZA0KDQpUaGUgRWNs
YWlyIGRpZG4ndCByZXBvcnQgdmlvbGF0aW9ucyByZWxhdGVkIHRvIHRoZSBwcmVwYXJlX2FjcGko
KS4NCkkgd2FzIGNvbmZ1c2VkIHdoeSBFY2xhaXIgY29udGludWVkIHRvIHJlcG9ydCBvdGhlciB2
aW9sYXRpb25zLCBhbmQgDQpkaWRuJ3QgcmVwb3J0IGZvciB0aGUgcHJlcGFyZV9hY3BpKCkuDQpB
ZnRlciBhIHdoaWxlIEkgcmVhbGl6ZWQgdGhhdCB0aGlzIGhlYWRlciBmaWxlICd4ZW4vaW5jbHVk
ZS94ZW4vYWNwaS5oJyANCndhcyBwbGFjZWQgaW50byBleGNsdWRlIGxpc3QgJ2RvY3MvbWlzcmEv
ZXhjbHVkZS1saXN0Lmpzb24nLA0Kd2hlcmU6DQogICAgICAgICB7DQogICAgICAgICAgICAgInJl
bF9wYXRoIjogImluY2x1ZGUveGVuL2FjcGkuaCIsDQogICAgICAgICAgICAgImNvbW1lbnQiOiAi
SW1wb3J0ZWQgZnJvbSBMaW51eCwgaWdub3JlIGZvciBub3ciDQogICAgICAgICB9LA0KDQpTbywg
YWxsIHZpb2xhdGlvbnMgZnJvbSAgdGhlICdpbmNsdWRlL3hlbi9hY3BpLmgnIGZpbGUgd2VyZSBp
Z25vcmVkLg0KSXQgd2FzIGp1c3QgYSBjb2luY2lkZW5jZS4NCg0KPiANCj4+ICsgICAqIC0gUjIu
MQ0KPj4gKyAgICAgLSBJbiB0aGUgc3BlY2lmaWMgYnVpbGQgY29uZmlndXJhdGlvbiAod2hlbiB0
aGUgY29uZmlnIENPTkZJR19IQVNfSVRTIGlzIG5vdA0KPj4gKyAgICAgICBkZWZpbmVkKSB0aGUg
J0JVRygpJyBtYWNybyBpcyBpbnRlbnRpb25hbGx5IHVzZWQgaW4gdGhlICdnaWN2M19kb19MUEko
KScNCj4+ICsgICAgICAgYW5kICdnaWN2M19pdHNfc2V0dXBfY29sbGVjdGlvbigpJyBmdW5jdGlv
bnMgZGVmaW5lZCBhcyAnc3RhdGljIGlubGluZScNCj4+ICsgICAgICAgaW4gdGhlIGhlYWRlciBm
aWxlICd4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3YzX2l0cy5oJyB0byBjYXRjaCBhbmQN
Cj4+ICsgICAgICAgcHJldmVudCBhbnkgdW5pbnRlbmRlZCBleGVjdXRpb24gb2YgY29kZSB0aGF0
IHNob3VsZCBvbmx5IHJ1biB3aGVuIElUUyBpcw0KPj4gKyAgICAgICBhdmFpbGFibGUuDQo+PiAr
ICAgICAtIFRhZ2dlZCBhcyBgZGVsaWJlcmF0ZWAgZm9yIEVDTEFJUi4NCj4gDQo+IFRha2luZyBi
b3RoIHRvZ2V0aGVyIGFuZCBjb25zaWRlcmluZyB0aGF0IHJlYWxseSwgd2hlbiB3ZSBubyBsb25n
ZXIgbGltaXQNCj4gTWlzcmEgY2hlY2tpbmcgdG8gc3BlY2lmaWMgY29uZmlndXJhdGlvbnMsIHdl
IGFyZSBnb2luZyB0byBoYXZlIG1hbnkgbW9yZQ0KPiBvZiBzdWNoICJwcm9ibGVtcyIsIEkgZmVh
ciB0aGlzIHdheSBvZiBkZXZpYXRpbmcgdGhlbSBzaW1wbHkgZG9lc24ndCBzY2FsZS4NCj4gSW1v
IHRoaXMgbmVlZHMgYSBTQUYtc3R5bGUgZGV2aWF0aW9uIHRoYXQgY2FuIGJlIGFwcGxpZWQgd2l0
aG91dCBuZWVkaW5nIHRvDQo+IGFkZCBhIG5ldyBzZWN0aW9uIG9mIHRleHQgZXZlcnkgdGltZS4N
Cj4gDQo+IEphbg0KDQpJIGFncmVlLiBBY3R1YWxseSwgSSBzYXcgc2ltaWxhciBmdW5jdGlvbnMu
IEl0IGNvdWxkIGJlIHRyaWNreSB0byANCm1haW50YWluIEVjbGFpciBjb25maWdzLg0KDQpJIHdp
bGwgY3JlYXRlIFNBRi1iYXNlZCBwYXRjaC4NCg0KVGhhbmtzLA0KRG15dHJvLg0K


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 20:03:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 20:03:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124829.1467019 (Exim 4.92)
	(envelope-from )
	id 1uybti-0008DB-VW; Tue, 16 Sep 2025 20:03:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124829.1467019; Tue, 16 Sep 2025 20: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 1uybti-0008D4-SP; Tue, 16 Sep 2025 20:03:30 +0000
Received: by outflank-mailman (input) for mailman id 1124829;
 Tue, 16 Sep 2025 20: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 1uybth-0008CW-Is
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 20:03:29 +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 33a3040d-9338-11f0-9809-7dc792cee155;
 Tue, 16 Sep 2025 22:03:24 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-45b9c35bc0aso52588505e9.2
 for ; Tue, 16 Sep 2025 13:03:24 -0700 (PDT)
Received: from [10.10.152.155] ([149.199.65.200])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77607b1840esm16601532b3a.48.2025.09.16.13.03.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 13:03: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: 33a3040d-9338-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758053003; x=1758657803; 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=PQStpmZrDOJE/kXT6itgcJh0LkbKDe3gIMs56zKvQY8=;
        b=LDCpzn2b1HzLtgte1e0K9YNYfMJfkeQtQ+NHVT5+fHIwiI8FwPG7xFTtd6GV9Yf0ia
         /yAdtoyQrxdu3UbWt9UfRXIg2OsbjDKLL1KsH5RTQaK8YpFNzNaSPCz9NwicfsrKwmuL
         LUL66kCcX96kAvahIID/NJQjEhFe84bj1z3y6IB7nDtRdAjoUbJCGIyp/52Cg4lZeHCs
         xUpPWAjxRS8SEZdEJ/RF5kKkLNic4LDba0J7uLm2rM5D5HEPiNF/2fmCCvyDmDtNQcv8
         YA16fa1WmJSSiFqDRAJENH9UnmqNpYJUG7kLe98A57ghe0Q42IkWc7ggl3hBQuGxQYJy
         b5Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758053004; x=1758657804;
        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=PQStpmZrDOJE/kXT6itgcJh0LkbKDe3gIMs56zKvQY8=;
        b=XfwqRdDVQsTTZXoaIOrX0f7t0QqfQ0F/yISciFbpIYcyjmCqctl7RJsTh1aaNg6AKN
         gz5dR9jwKKmsYa389phm97R5S1GqadVJ2NZkUzWTxSzNClNmY2xkwEZkIxJTEPgwAMRt
         FAQHqYer7qQjhRRzZ/5lFUE9F99dwm8AwxDSiHAWu/sX29VcXubzrokRqMT9CR2dABw2
         9Vl7bX0wR22uRkn2E7HIdFuaYSvNIpR8iPZHOE3BrrOS+vieguQCdVFm4pH6mp+zv7jX
         POW21igRlzTvl/cH2H04izRpDwnjx5/clw7cFN9+CntcB9LMa0ZymBxMZmdn3MxIiPOn
         YmGw==
X-Forwarded-Encrypted: i=1; AJvYcCUrBqwVhsVBnTLOd2o/b0KL4u1giX6mUwzUQ/uGB9ZJR+zgL8O95T0qCZ4Us93iQMDVzz19GJA8UCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxCBcrd7W+APxHboUNAhG2+jB7kk1ww69CRyn8SAt4TtVwUeGEf
	1xAkyhub4zsBIrCJrtR2sp55D40HZGvxyW8oDuqx5JjTAeiWcXu4HAK3cZjxR3FLoA==
X-Gm-Gg: ASbGncusSAR/5ssYpr7oRktgaz+QEQowNvMXl8xMEA4uEMW7gdcLKFur8Y95cmLC2/d
	riiJStnvMbjtnVwf0EBhgk29DxctuN+5HSj6j2nKNmxjlttlC25kfXyj7zCjXgmqbzz2m1yS29y
	8wV4uI09j5VrsfBjFLKCG6MCG30IrBKx6VIRBcBFwyWijT0mWBrDbNwD0eytVhwyg/plmooqIS5
	cMhqAQrRQzLceo5By4WMIbSmV7hdFMvEGExa7RCNqYXhiu9Lnh/OZFORJGOAEQLwVr/zfUBWUUi
	OI/JVE5/XGPuJ4BPJEpSK1XMlugZJDKdMk+R6ZXIwb1VKwSRwrFsxLOglUWnCA5Vk/bMNPgAmDV
	a21fjmrMJZ+naerxFsCtABthSCga7KGif3XNedMROqp6a
X-Google-Smtp-Source: AGHT+IEcZkUHKeiEOiTn0gsJ47va8ogau+sAU6ka7K2UBEv21Ho5RYPI61YnRnUjPfVoy7Z3nM/j3g==
X-Received: by 2002:a05:6000:1789:b0:3ec:db0a:464c with SMTP id ffacd0b85a97d-3ecdb0a46cdmr3248046f8f.44.1758053003568;
        Tue, 16 Sep 2025 13:03:23 -0700 (PDT)
Message-ID: 
Date: Tue, 16 Sep 2025 22:03:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
To: Dmytro Prokopchuk1 
Cc: Nicola Vetrini ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
> 
> 
> On 9/16/25 17:27, Jan Beulich wrote:
>> On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
>>>          even when debug-only assertions like `ASSERT_UNREACHABLE()` are removed.
>>>        - ECLAIR has been configured to ignore those statements.
>>>   
>>> +   * - R2.1
>>> +     - In the specific build configuration (when the config CONFIG_ACPI is not
>>> +       defined) the 'BUG()' macro is intentionally used in the 'prepare_acpi()'
>>> +       function in the header file 'xen/arch/arm/include/asm/domain_build.h'
>>> +       defined as 'static inline' to trigger a runtime error if ACPI-related
>>> +       features are used incorrectly.
>>> +     - Tagged as `deliberate` for ECLAIR.
>>
>> I response to me outlining a deviation-less alternative you tried it out
>> and said it works. Then why is the deviation still being put in place?
> 
> Yes, that's true.
> I started with that prepare_acpi() function and I tried to move it into 
> xen/include/xen/acpi.h header file under appropriate #ifdef:
> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/commit/d15cf91de92f1f8ec67911c51a13e7f095c1bcdd

But an important part of my proposal was to have no #ifdef around
the declaration, iirc. With that, no violation should result.
Whether (or why) moving would be required I don't know.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 20:06:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 20:06:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124842.1467029 (Exim 4.92)
	(envelope-from )
	id 1uybwK-0000O8-BM; Tue, 16 Sep 2025 20:06:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124842.1467029; Tue, 16 Sep 2025 20:06: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 1uybwK-0000O1-8H; Tue, 16 Sep 2025 20:06:12 +0000
Received: by outflank-mailman (input) for mailman id 1124842;
 Tue, 16 Sep 2025 20:06: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 1uybwJ-0000Nt-CL
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 20:06:11 +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 924db5cb-9338-11f0-9d13-b5c5bf9af7f9;
 Tue, 16 Sep 2025 22:06:03 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3e9c5faa858so3118484f8f.3
 for ; Tue, 16 Sep 2025 13:06:03 -0700 (PDT)
Received: from [10.10.152.155] ([149.199.65.200])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54a387b618sm15136094a12.32.2025.09.16.13.06.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 13:06: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: 924db5cb-9338-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758053163; x=1758657963; 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=pJLhApEulSIjvFulpUZib0KekJ0AgXZ/v42YdH3eDog=;
        b=AincNZICzlQIJc56tZpEn9NlmjacmhYzm5TM03tuWPly2DZh3SiU+x7T4/uANBSQD+
         Y93dluzXg3jH4QGS9+++SfV2oUkf3s6JbWqWsixxfOGHS5X3gcogCqIKBmo+y9vOWQ1M
         /vCIL/anU6csSzosiwKBfaXgz5sMV8xIArMK532poBkE4ZxoF/ylwq/Tm2mbBdSuzirb
         XjjA/CNAHY8e2IFhqSFj2b0pVaV9ZmCq/1uXMrly6GLCzFQsioBB+Rtw85E6C/lyDAEf
         RlDvMjXyKdQ/aWom0teIn3So+vs0kRe9gb0LTMTmcLtn4ZYYCT5mpz6vWqhlRbZJ/G/Q
         a7Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758053163; x=1758657963;
        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=pJLhApEulSIjvFulpUZib0KekJ0AgXZ/v42YdH3eDog=;
        b=tZ1z7jI66dFyHpFtUzKa7Uj63XOHQlh1GMXWmnRwjmb0E31Q0aEJQ8eSsgDiXtNXFZ
         SOR1qQooA01aytcuhSqgpMbNIu8xvy55Uu3Lzr/tbM8qE3/6dv4xC+UpYlT/WAcgskgm
         XrgqNZgUNHUAWVPfSd4BQdNhrOs/GP3ZhWlq5l1/YU/M9HuZ/vJjiKTUBmMiUKMiHWbf
         Ru3+yIimNFVSLRhaiMRzxD71s8z+IEOa5xPOnVG6bexBlzNhDmAmBPpndMBiKOIHc9Ar
         KxzcoId30YbNuebaPLFoNeX+ayZr7DQYI9GA1t7dEYzspfbPb90G8gv3xskKXIKMaOL6
         FWng==
X-Forwarded-Encrypted: i=1; AJvYcCXUWLdib/I/wJtfDkcJ63obaxUFw5yA8HpqD47rnFFfVXKp9JykHRLuk2NF/sgkt1TQxEHh/udE2aE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yza2RUu/ehx9rNSqzXjwSvRiRxTLdzNh0DDdQkEn3h1zHymzwmm
	ebZHZTZroGJsGcD/3RfKD0J5A3Y5To9EMhIcPpcffvkA8bxpYzHTZQHaBfNRcM6Bzw==
X-Gm-Gg: ASbGncsgZpkRbMIX1L9AY+iG5/7A0vXeK3JNY74yELOB7ODD72RKXHNfbGsssfBp7m6
	DDdDKVGAKcd2PwoiIL1jxoqqMS6SatPg0OEsWkYN2OB5EgttQyaUKp2OMZd2p5XecynFvy9OIDa
	AI18wlsZc9FUpL7dF0XqJjW9HKBx2mPl8s4r6fsvDFPAvUMbQHLzaDSQHFUkKAWb1dffG7R6yar
	Y11WThqjrPbFNYOOhnuS7hBpWOxMdxJQkQXV5ar/EyGluA6XBJoYKTq1siJdUZxwlhhHrtM0GZ3
	sVDev1K8MxUyUeXdJ+Q2YCrs52/OXba0+s7sC4R/zq2T+vzKPEVbwm0CUfFglfb8nv8Yth7lE3H
	TuDJ483DOuzgNEypJ/xhHK84aSAcjQtr2dg==
X-Google-Smtp-Source: AGHT+IGSVqGxFKXiMIv4cWiJNw2Be4nkDRxMPPpGJzj1X91EiaPf4qakK4NFv1E50dxY5/SGK2rhWw==
X-Received: by 2002:a5d:61cb:0:b0:3ec:1154:7dec with SMTP id ffacd0b85a97d-3ec11547dfcmr4112106f8f.25.1758053162609;
        Tue, 16 Sep 2025 13:06:02 -0700 (PDT)
Message-ID: <9e5c0735-1024-4d44-b1bd-1a8909ce2c37@suse.com>
Date: Tue, 16 Sep 2025 22:05:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domain: introduce DOMID_ANY
To: dmukhin@xen.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, xen-devel@lists.xenproject.org
References: <20250916173702.871508-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250916173702.871508-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.09.2025 19:37, dmukhin@xen.org wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>  /* DOMID_INVALID is used to identify pages with unknown owner. */
>  #define DOMID_INVALID        xen_mk_uint(0x7FF4)
>  
> +/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */

Considering this is an implementation detail of the hypervisor, ...

> +#define DOMID_ANY            DOMID_INVALID

... I don't think this should go in a public header.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 16 20:52:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Sep 2025 20:52:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124860.1467039 (Exim 4.92)
	(envelope-from )
	id 1uycee-0006UE-Iy; Tue, 16 Sep 2025 20:52:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124860.1467039; Tue, 16 Sep 2025 20: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 1uycee-0006U7-Fp; Tue, 16 Sep 2025 20:52:00 +0000
Received: by outflank-mailman (input) for mailman id 1124860;
 Tue, 16 Sep 2025 20:51:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uyced-0006U1-AS
 for xen-devel@lists.xenproject.org; Tue, 16 Sep 2025 20:51:59 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uyceY-00CxDf-00;
 Tue, 16 Sep 2025 20:51:54 +0000
Received: from [149.199.65.200] (helo=[10.10.151.52])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uyceY-00DG2N-0B;
 Tue, 16 Sep 2025 20:51: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" 
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=Uf6XeadhFawDcIV8dpBEaYKUBStuK0owIWX7FO5bFQ4=; b=yU/uzTSc2ZD78p5lNkW6mKdwRz
	oGu8ecZ3K4mDsKEjJFs5QI0TtXNfXAzBt4ihSVOoOxl6lEKIiNrgvex5jPtNdlXbiivcVG+VYQ7eX
	PoOCn+lRFdS2DzLkzmfMbqLBJfjvGLzfnK3DuT0wBRyBlVdNZhY9fsj2fncmaahacDB0=;
Message-ID: <71e80d9a-0210-490c-a3b0-6b370a18145f@xen.org>
Date: Tue, 16 Sep 2025 13:51:52 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domain: introduce DOMID_ANY
To: Jan Beulich , dmukhin@xen.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, xen-devel@lists.xenproject.org
References: <20250916173702.871508-2-dmukhin@ford.com>
 <9e5c0735-1024-4d44-b1bd-1a8909ce2c37@suse.com>
Content-Language: en-GB
From: Andrew Cooper 
In-Reply-To: <9e5c0735-1024-4d44-b1bd-1a8909ce2c37@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16/09/2025 1:05 pm, Jan Beulich wrote:
> On 16.09.2025 19:37, dmukhin@xen.org wrote:
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>  /* DOMID_INVALID is used to identify pages with unknown owner. */
>>  #define DOMID_INVALID        xen_mk_uint(0x7FF4)
>>  
>> +/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */
> Considering this is an implementation detail of the hypervisor, ...
>
>> +#define DOMID_ANY            DOMID_INVALID
> ... I don't think this should go in a public header.

Except we want it for the toolstack to use, as part of preventing 0
being a magic number to XEN_DOMCTL_createdomain.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 02:23:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 02:23:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124905.1467053 (Exim 4.92)
	(envelope-from )
	id 1uyhpB-00020N-O8; Wed, 17 Sep 2025 02:23:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124905.1467053; Wed, 17 Sep 2025 02:23: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 1uyhpB-000204-J8; Wed, 17 Sep 2025 02:23:13 +0000
Received: by outflank-mailman (input) for mailman id 1124905;
 Wed, 17 Sep 2025 02:23: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 1uyhpA-0001zy-EF
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 02:23:12 +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 41c08876-936d-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 04:23:11 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-55f720ffe34so566151e87.1
 for ; Tue, 16 Sep 2025 19:23: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: 41c08876-936d-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758075791; x=1758680591; 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=Jw7CytErdaqG5NSkbJajOGN1sz+03T+CVp3e3RSNSUk=;
        b=RaeFmyQHAcaeY3fn412MnAaNec/ntVa0LeXcVd9BFeYA2acCtz+aXAsfK1hLdYwSDp
         +fbLQlQoFrDvULagvrhIqoGEsQJO8y5EDg+7vKjHHG5QZoxIC1+EhWv7wGP+v6FPnI0G
         mfUt4V8wc0zUSArKRNvvdDzeAfIoVz/aCEqjACYaQDot5LcynL/kae0AtXwjlmsY89KF
         25KOf9RKx5XcsqmFElv9v/+G+GhSTG6MflA0RoXkwHzvjSyAMI7psTn9M1bxLlerFaUg
         fMGVGRYdegIzEyqymVgxZxznwmwAPj8ZjbD5KUDYcyMcan5k5aaer/KPdf5wxFBuai1C
         bnTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758075791; x=1758680591;
        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=Jw7CytErdaqG5NSkbJajOGN1sz+03T+CVp3e3RSNSUk=;
        b=wG11aw/CSCi856WzJjx21MsuDN0CzNGnNKH0a2YmRMi08DOsMy8Odo+3GKlekzteYE
         bgW2TS6kY6ky8lg8wIirQUjy4VhH+WUySnIeAlJRlC043Hu/GdqTWjtJg3pqEqoNYxcw
         s3zM0Mh+wP4UoQxEZu/fuPE33Wcvt+6Ku5l9UBD1FsxwO/nmh8aCGRH5q7Z4EMt8NDu9
         fSIsVZOpObKWvkA4H7t02YSEeW9fuf6cudXKlwo6teiAvzB4B/tYEuucUfhIaAVPA0YS
         kaDBysn4DsCvIiADOXS9PwFwN5f8eKjSxWHK5zHO9LrRLhibSd7Cp3Jxq+2nrkJdqvhg
         lb6g==
X-Gm-Message-State: AOJu0Yy2VSAr7zK1FKrMem6Rxbi6IBV4b83TebeQwhv3PyOm7sMfkyKy
	D9i+3rWPHEbUT/G95vVWnXhWHwzwxsr+1hKLC1iuyCfKdKa6VBCxI5toyHkYaawCWOGtKFX2bdy
	2d93uENrycUtUfO+1CFRrd6fMAVX8Mdk=
X-Gm-Gg: ASbGnctwsiaDzU7qpBzh3MGtXeD6FgKPZALLBR0hyk7Zcy5n4Q2HYJ/4rD4AHpQyCTS
	/nP0rkaCFJIn3TGwvc76juLyaEI0HzJZPf46icjnQRixr0XoRcwHzOzudP5ZtoQ1Ym+Fn/EcRkF
	otdJOFfqYSlMwZ0BNcvdZ7u87SSuTaAVwwPaNbC6nI9cwNzXCkp1tuxLXLp94SeQdNQ9MIbsj2F
	kWMBw==
X-Google-Smtp-Source: AGHT+IEhxvccF/vkGpgGFJxHc+AU1HmBvcWAUY2LiRM5h21I/Ba6dpbehNAnKkEkGpPflfCs5j6EXA/vfhCTZ2DVAFY=
X-Received: by 2002:a05:6512:124d:b0:55f:3ae4:fe57 with SMTP id
 2adb3069b0e04-577a3edbaecmr129650e87.20.1758075790471; Tue, 16 Sep 2025
 19:23:10 -0700 (PDT)
MIME-Version: 1.0
References:  <293acbb653b5f4d5bf71dc459f9de3e729bff3e1.1756763487.git.mykola_kvach@epam.com>
 <40480c61-0619-41b8-866a-85a219f5e157@xen.org>
In-Reply-To: <40480c61-0619-41b8-866a-85a219f5e157@xen.org>
From: Mykola Kvach 
Date: Wed, 17 Sep 2025 05:22:59 +0300
X-Gm-Features: AS18NWCDEeAZIq3jwNJ6nj7I0qu-3pRtzUxEPEevGj9LxkrTTPMMn_vU9WYh4bI
Message-ID: 
Subject: Re: [PATCH v6 04/13] xen/arm: Don't release IRQs on suspend
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,

Thank you for the review.

On Sat, Sep 13, 2025 at 2:45=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 01/09/2025 23:10, Mykola Kvach wrote:
> > 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:
>
> Looking at the stack trace, I don't understand why this error would not
> happen when offlining a CPU. Can you clarify?
>
> Anyway, I am not very happy to special case suspend/resume in the IRQ
> code. So I would strongly prefer if we follow a different approach.
>
> The one that come to my mind is to switch from request_irq() to
> setup_irq() and allocate the action in a per-cpu variable. With that,
> there should be no free happening with the stop_machine helper.

Yes, this should help in my case and it also looks like a cleaner
solution, thank you.

Interestingly, my teammate Mykyta Poturai came up with the same idea a
few days ago when he faced a similar problem during CPU hotplug
implementation.

So I will just reuse his commits this is the one of the commits:

https://github.com/Deedone/xen/commit/3817601c2f437453035839f29e94c069a7708=
17d

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

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 03:29:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 03:29:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124919.1467063 (Exim 4.92)
	(envelope-from )
	id 1uyirS-00010P-Al; Wed, 17 Sep 2025 03:29:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124919.1467063; Wed, 17 Sep 2025 03: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 1uyirS-00010I-6z; Wed, 17 Sep 2025 03:29:38 +0000
Received: by outflank-mailman (input) for mailman id 1124919;
 Wed, 17 Sep 2025 03:29: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 1uyirQ-00010B-L9
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 03:29:36 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87d9eed6-9376-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 05:29:34 +0200 (CEST)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-35eecfce023so3869441fa.1
 for ; Tue, 16 Sep 2025 20:29: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: 87d9eed6-9376-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758079774; x=1758684574; 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=0QFWpLR2EIZkKKQy2sEaLjYFIeEBGT0kYHmIFZ2W/UI=;
        b=nX2A+y0VS/Eev7nFyLvBSj/DpXJF0SugaIU43kF78o/MZgIowKV2qq+VDZ0jcbN+pc
         J/T2BxBxXguovSbDozedNj1LK4lzt3KV7DNEbZ42+LJY+szaFcXQT5XxF5ZaN0eIc3Sc
         H0O5vWT47yd2259W46W8z/trXf9fZwSZLjC9LsGSh+LCCsuLndaJgR64bIfw/EclDjs1
         63t/GfBrbQTXmDQlgE3hAlKWHD5qNsRsQ/Y8RhQiRvPKnmJbU2QN8L9vOmdS8GeaxAPv
         NLfQpAeY90O2RgxhXuL94c9iVKCe3qZvnbgeNavX5j9qyOMbQucHXz8/Gv4YUr3UkV1g
         GZPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758079774; x=1758684574;
        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=0QFWpLR2EIZkKKQy2sEaLjYFIeEBGT0kYHmIFZ2W/UI=;
        b=ZSWlM959YDdw6H+Z5QJNMPrB8NCvF5ip6fL70sRAqfQocp8t7ZOJNsAiIVtPnBqf8G
         4P8PKGBNey+en2fnC/V8U3Fb/Bugi1GbAEXHEIfSRPMdFqyCwv3nucLocGkbqUQ8Ro7v
         XD3L7QXxzoke3Esd0Rah7hESPcGVvXTq+FpOoH1doDX2WBNuMNCixi96X6l7tEEzP3+f
         ZhVeLHYZrhm528cJBCCp7F4CzIfLgOlu35WeLXzjKc6tPE/TB2z91vi10n7jYvVeHhUH
         rtH2y61BMOckGegmyfsekQNb/9tlrL8PXt9MC7lq1QjNWbGLCbqoqGcQn7U45JqzF5E/
         lPpA==
X-Gm-Message-State: AOJu0YzcsyUb4HkDdO33aUs8wji4kY/pOjknl67EFXxsp54fYZjSBlyi
	/9AsZT0ro9icjmVfxaEiOk3+pn2YpUNJIrKk8o0a9yzQT3iq47TER/8i1+Cwxg5uWTwl1oxFbF0
	R8gHwZovTNUU/2AKcavd3YPzOZdSRGjA=
X-Gm-Gg: ASbGncvKoLj5kdblI3BdtoND5d6hb968jo8FAMldO4DVH3ojQyEVbBQyxbfVv0pnsuJ
	gmGXoh+8CojY6SxRqahdGdApew8HpftvzjnP0WI1SIFf5ARrbvh1GYyV08PMI3vogkpXJFPF0ak
	hcz99/NXZ4mCQBAc/AA01tdyfcNKtfgvFk0/7zD6wULEj7F8chiprPix754sAjRwkLiaGa+AEEb
	rWlZQ==
X-Google-Smtp-Source: AGHT+IEWMxTLq0nRfC5yHHPPIDeIrX1w4CJXBz6+h+O2zMj4MIdXTJvDydiyUZ3UurwhD/tloz/JnekYpuZB1qzxPOA=
X-Received: by 2002:a05:651c:25d7:20b0:333:b90c:f48a with SMTP id
 38308e7fff4ca-35f6093dd1bmr1721841fa.10.1758079773443; Tue, 16 Sep 2025
 20:29:33 -0700 (PDT)
MIME-Version: 1.0
References:  
 
In-Reply-To: 
From: Mykola Kvach 
Date: Wed, 17 Sep 2025 06:29:21 +0300
X-Gm-Features: AS18NWAoSKbAZ2zIcfqCTbUkF_yTXor_xLZhqzD8x2YbD_XBUJLpPciP61Vbs48
Message-ID: 
Subject: Re: [PATCH v6 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, 
	Mirela Simonovic , Stefano Stabellini , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Saeed Nowshadi , 
	Mykyta Poturai , Mykola Kvach 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Julien,

Thank you for the review.

On Sat, Sep 13, 2025 at 2:30=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 01/09/2025 23:10, Mykola Kvach wrote:
> > 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.
> >
> > Signed-off-by: Mirela Simonovic 
> > Signed-off-by: Saeed Nowshadi 
> > Signed-off-by: Mykyta Poturai 
> > Signed-off-by: Mykola Kvach 
> > ---
> > Changes in v6:
> > - drop extra func/line printing from dprintk
> > - drop checking context allocation from resume handler
> > - merge some loops where it is possible
> >
> > 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          | 143 ++++++++++++++++++++++++++++++++=
+
> >   xen/arch/arm/gic.c             |  29 +++++++
> >   xen/arch/arm/include/asm/gic.h |  12 +++
> >   3 files changed, 184 insertions(+)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > index b23e72a3d0..6373599e69 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -1098,6 +1098,140 @@ static int gicv2_iomem_deny_access(struct domai=
n *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;
>
> I don't quite follow why all the registers above needs to be
> saved/restored. Is it just convenience because it is too complicated to
> recreate the value?

Do you mean reinitializing them with the same values as in the init path?
My reasoning for saving/restoring is to avoid duplicating assumptions from
initialization in the resume code. If the init sequence changes in the
future, or if some registers are modified outside of init, the resume path
would also need to be updated. Saving/restoring directly feels like a more
universal and robust approach.

>
> > +    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, "GICv2 suspend context not allocated!\=
n");
> > +        return -ENOMEM;
> > +    }
> > +
> > +    /* Save GICC configuration */
> > +    gicv2_context.gicc_ctlr =3D readl_gicc(GICC_CTLR);
> > +    gicv2_context.gicc_pmr =3D readl_gicc(GICC_PMR);
> > +    gicv2_context.gicc_bpr =3D readl_gicc(GICC_BPR);
> > +
> > +    /* Save GICD configuration */
> > +    gicv2_context.gicd_ctlr =3D readl_gicd(GICD_CTLR);
> > +
> > +    for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
> > +    {
> > +        gicv2_context.gicd_isenabler[i] =3D readl_gicd(GICD_ISENABLER =
+ i * 4);
> > +        gicv2_context.gicd_isactiver[i] =3D readl_gicd(GICD_ISACTIVER =
+ i * 4);
> > +    }
> > +
> > +    for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> > +    {
> > +        gicv2_context.gicd_ipriorityr[i] =3D readl_gicd(GICD_IPRIORITY=
R + i * 4);
> > +        gicv2_context.gicd_itargetsr[i] =3D readl_gicd(GICD_ITARGETSR =
+ i * 4);
> > +    }
> > +
> > +    for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ )
> > +        gicv2_context.gicd_icfgr[i] =3D readl_gicd(GICD_ICFGR + i * 4)=
;
> > +
> > +    return 0;
> > +}
> > +
> > +static void gicv2_resume(void)
> > +{
> > +    unsigned int i;
> > +
>  > +    gicv2_cpu_disable();> +    /* Disable distributor */
> > +    writel_gicd(0, GICD_CTLR);
> > +
> > +    /* Restore GICD configuration */
> > +    for ( i =3D 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);
> > +
> > +        writel_gicd(0xffffffff, GICD_ICACTIVER + i * 4);
> > +        writel_gicd(gicv2_context.gicd_isactiver[i], GICD_ISACTIVER + =
i * 4);
> > +    }
> > +
> > +    for ( i =3D 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> > +    {
> > +        writel_gicd(gicv2_context.gicd_ipriorityr[i], GICD_IPRIORITYR =
+ i * 4);
> > +        writel_gicd(gicv2_context.gicd_itargetsr[i], GICD_ITARGETSR + =
i * 4);
> > +    }
> > +
> > +    for ( i =3D 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);
>
> Why are we forcing CTL_ENABLE? Surely it should have been set and if
> not, then why is it fine to override it?

You are right =E2=80=94 forcing GICD_CTL_ENABLE is unnecessary here.
The value of GICD_CTLR was already saved before suspend, so restoring
it as-is should be sufficient.

I will drop the | GICD_CTL_ENABLE and just restore the saved value.

>
> > +
> > +    /* 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_E=
OI,
> > +                GICC_CTLR);
>
> Same question here for both ENABLE and EOI.

You are right here as well =E2=80=94 we don=E2=80=99t need to force GICC_CT=
L_ENABLE
or GICC_CTL_EOI. The saved GICC_CTLR value should already reflect
the correct state at the time of suspend.

So it would be cleaner to just restore the saved register value
directly, without OR=E2=80=99ing additional bits.

>
> > +}
> > +
> > +static void gicv2_alloc_context(struct gicv2_context *gc)
>
> I am a bit surprised this is not returning an error? Why is it ok to
> ignore the error and continue? At least for now, if someone enable
> CONFIG_SYSTEM_SUSPEND, they would likely want the feature. So it would
> be better to crash early.

This behavior was introduced based on feedback on one of the earlier
versions of the patch series.

I agree with your point =E2=80=94 if CONFIG_SYSTEM_SUSPEND is enabled, then
failing to allocate the context should be treated as fatal. I will
update the code to crash early in this case.

>
> > +{
> > +    uint32_t n =3D gicv2_info.nr_lines;
> > +
> > +    gc->gicd_isenabler =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32)=
);
> > +    if ( !gc->gicd_isenabler )
> > +        goto err_free;
> > +
> > +    gc->gicd_isactiver =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32)=
);
> > +    if ( !gc->gicd_isactiver )
> > +        goto err_free;
> > +
> > +    gc->gicd_itargetsr =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4))=
;
> > +    if ( !gc->gicd_itargetsr )
> > +        goto err_free;
> > +
> > +    gc->gicd_ipriorityr =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4)=
);
> > +    if ( !gc->gicd_ipriorityr )
> > +        goto err_free;
> > +
> > +    gc->gicd_icfgr =3D xzalloc_array(uint32_t, DIV_ROUND_UP(n, 16));
> > +    if ( !gc->gicd_icfgr )
> > +        goto err_free;
>
> I am wondering if we are really saving that much by allocating each
> array separately? It would simply the code if we fix the array to
> support up to 1024 interrupts so we allocate a single structure.

I suppose some systems may have only local interrupts, or a very small
number of SPIs, which is allowed by the spec.

We could rewrite the code to use a single allocation for all arrays, or
possibly avoid dynamic allocation entirely and declare the arrays of
structs in global scope. The latter approach would simplify the code
and reduce the number of allocations, but it would use memory less
efficiently.

>
>  > +> +    return;
> > +
> > + err_free:
> > +    printk(XENLOG_ERR "Failed to allocate memory for GICv2 suspend con=
text\n");
> > +> +    xfree(gc->gicd_icfgr);
> > +    xfree(gc->gicd_ipriorityr);
> > +    xfree(gc->gicd_itargetsr);
> > +    xfree(gc->gicd_isactiver);
> > +    xfree(gc->gicd_isenabler);
>
> NIT: If you use XFREE(), then you don't need the memset below.

Ack.

>
> > +
> > +    memset(gc, 0, sizeof(*gc));
> > +}
> > +
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >   #ifdef CONFIG_ACPI
> >   static unsigned long gicv2_get_hwdom_extra_madt_size(const struct dom=
ain *d)
> >   {
> > @@ -1302,6 +1436,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 su=
spend */
> > +    gicv2_alloc_context(&gicv2_context);
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >       return 0;
> >   }
> >
> > @@ -1345,6 +1484,10 @@ static const struct gic_hw_operations gicv2_ops =
=3D {
> >       .map_hwdom_extra_mappings =3D gicv2_map_hwdom_extra_mappings,
> >       .iomem_deny_access   =3D gicv2_iomem_deny_access,
> >       .do_LPI              =3D gicv2_do_LPI,
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +    .suspend             =3D gicv2_suspend,
> > +    .resume              =3D 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 */
>
> What would prevent us to suspend from another CPU?

Nothing prevents suspend from being called on another CPU.
According to the PSCI specification, it just needs to be the last
running CPU in the system.

>
> > +    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;
>
> Cheers,
>
> --
> Julien Grall
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 04:49:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 04:49:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124936.1467073 (Exim 4.92)
	(envelope-from )
	id 1uyk6g-0002DG-S9; Wed, 17 Sep 2025 04:49:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124936.1467073; Wed, 17 Sep 2025 04: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 1uyk6g-0002D9-OL; Wed, 17 Sep 2025 04:49:26 +0000
Received: by outflank-mailman (input) for mailman id 1124936;
 Wed, 17 Sep 2025 04: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 1uyk6e-0002Bk-TM
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 04:49:24 +0000
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com
 [2607:f8b0:4864:20::d2d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id adcb2818-9381-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 06:49:23 +0200 (CEST)
Received: by mail-io1-xd2d.google.com with SMTP id
 ca18e2360f4ac-8876de33c86so450432939f.3
 for ; Tue, 16 Sep 2025 21:49:23 -0700 (PDT)
Received: from localhost ([2605:9480:312:2031:4ed7:17ff:feaa:a013])
 by smtp.gmail.com with ESMTPSA id
 8926c6da1cb9f-511f2f32facsm6630066173.19.2025.09.16.21.49.20
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 16 Sep 2025 21:49: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: adcb2818-9381-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=edera.dev; s=google; t=1758084562; x=1758689362; darn=lists.xenproject.org;
        h=to:from:subject:message-id:date:content-transfer-encoding
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=jZ7hBKPepBdLWV/w2l/ZIF3GaLF0WRrNhLtwU/RtH5o=;
        b=NI7vofzrrHwMTjsvbf1RBUxy015t3Tag7wot9C2hS9tygExFhyN3Yq+4eFKA++OkqW
         SQzxchZRA6t3qtNdF1t0zAIVTYU6DnqQNzIEigl0fkACq2VwpWcvdQmlaCOdoxuKq810
         z4/RWsMEJQOAro8OeOk/5Iv+aT9uEioQnH2xLZzxpddFf4uGDHRb+EnMl6g51CHByHzx
         dbbVp6NWgPr1bK8TNI7+E23onotqn2UNwWeZ0OLfwYEi43jiEj77S0yBNAr0GxpKd87R
         dQPbhHvQo7pLay6JdGnGPtiM5n1Ms6j5uGJb4BwcTY9GUCJmEiFatYmmUfSiayS80vdJ
         JqTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758084562; x=1758689362;
        h=to:from:subject:message-id:date:content-transfer-encoding
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jZ7hBKPepBdLWV/w2l/ZIF3GaLF0WRrNhLtwU/RtH5o=;
        b=j6q6z18diVFxJISi0bYvbHyRB0+Zj9/helwL8J+cBVgJeADXkIXo5+B7YCdbd1EKgq
         lX5yDHu7BCYAJyPEckZbmnADWZBY3S59/EnCubXLCkdPkKqpQkfmGsbjdnYpAuvHtGK3
         xWRoc7ZIavtxdNZVo6fjZXudVZvusBT9BvZe6IlXUe3RW8A7+ROHHQ1JW7e/USOUhQkm
         PUcZAmPM1jdv3BMZIgwnXDWQxGri6a2dE1danu0taRmrO/ZQLLPzXZTGvEunfpfxiEVu
         6anmkdr9pt6iUPGt4ELAOmf25gLNmJpWwwyOK3RO+480HSYDLMX7sONu7xrCMovty824
         kFJA==
X-Gm-Message-State: AOJu0YyKg9AApxrnUcTyZJkH12+DR7+bOwelgnXRO0A9MbBZH9X9Lt3a
	Uy5ZiUqzGr9+ZO/iRU+NjqUYI557A9y3utIhIn8mET2nyR7TeG6Abw5qyWHbFyQcaJQ08GoVbQb
	gBifMrSY=
X-Gm-Gg: ASbGnctW/C2+oY+itRRs78spFevAxKBtrHRFwEFQ3bnPgYVckdxqp2YtHcJ9G/VIxok
	jjl5DY01fDX0Rcj3+qb/no+mQ0Y+hTZb572PPJhgT7a1b8EKDF0U59q2IbgtegilDkO6EuFwC2D
	UHs9mpDhPZFf/wtKPUrVT8DH5MSxl3T8bL+JdQGCMfcydp6jRj1qPZjC+FGMIsCosEoYYq4r0vh
	X+a+MDJ+CXUjw8aGTEnWwA1hmvZHdWAwo76UDGnLm94mFTVFYgH9M1G9JymgI2wMZJPiMNglwQb
	9SVXB2uTPjigXfEmGu0OjWurxyjAxBxHka/HlBQPc6jB3Ne10d3enZUaRKDFuV98sU684p0G+WL
	XNKd6Mq2MW6B8+cyHsY9Lug==
X-Google-Smtp-Source: AGHT+IHFrx3ohwYyBFJhKdBb2A5tBp0OwGtFKYm3ziHVzlPekfmHeNiENSxmKXS9+ItdnEFy7AC3cA==
X-Received: by 2002:a05:6602:3412:b0:890:1f62:492c with SMTP id ca18e2360f4ac-89d1bfab247mr130671639f.8.1758084561635;
        Tue, 16 Sep 2025 21:49:21 -0700 (PDT)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 16 Sep 2025 23:49:19 -0500
Message-Id: 
Subject: Xen Summit 2025 - Design Discussion Notes - Xen ABI
From: "Alexander M. Merritt" 
To: 
X-Mailer: aerc 0.18.2

Hi all, it was requested I send the notes I took during the design discussi=
on on the ABI / APIs to the list.

Normally I keep this as personal notes, so there may be errors (esp if I di=
d not hear correctly), so please feel free to correct or expand. Details ma=
y be missing where I am unaware of the history behind something.

-Alex Merritt




Design Discussion: Xen ABIs and APIs

- Chris on remote: Andrew has been and wants to work on a new ABI
- Andrew: put together a collection of documents to understand what we have
to work with, what we want to improve, before starting the work on any
design or iterations on interfaces we currently have
- link to document in the design session
        =E2=80=90 https://design-sessions.xenproject.org/uid/discussion/dis=
c_3IEQbyaCTkqLf2fFzoze/view
- number of things we have been aware of for a while
- some attempts to address them on the list
- one problem: if you only try to fix one of them, it brings in discussion =
of
fixing many other items
- everyone has opinion on what the end result will look like
- existing designs only fix subsets, not the whole thing
- we want to address all the problems from the start, before deciding on a =
plan
to fix them
- enumerate the ABIs and APIs that currently exist
        =E2=80=90 problems not apparent if you just think about this
        =E2=80=90 many folks think this is just the hypercalls
        =E2=80=90 there is the enumeration information
        =E2=80=90 xen has many bugs - originally monorepo with xen, linux, =
qemu, BSDs,
        bochs, ... with =E2=80=9Cmake world=E2=80=9D you got a system. All =
guests were
        required to have event channel - no discovery exists because they a=
ll
        had it
        =E2=80=90 grant table v2, migrate old version of xen to new, exerci=
se new code
        paths, then kernel crashed
        =E2=80=90 initial state of vcpus - many folks don=E2=80=99t think a=
bout them, but what
        xen presents, we have bugs describing those via the hypercalls we u=
se
        =E2=80=90 the hypercalls themselves -- 46? -- half of them specific=
 for PV guests
                - x86 HVM / ARM HVM are only a small fraction of the total
                hypercalls that exist
- the reason the hypercalls look like this now, Xen started with pv guests =
on
x86, a VAS system made sense
        =E2=80=90 when HVM guests came along, we have hacks fitting PV gues=
ts into HVM
        =E2=80=90 Xen has to walk the page tables of the guest just to get =
the
        information it needs, you cannot do that in encrypted VMs by design
        =E2=80=90 need to change the way we deal with pointers in the API
- evtchn send, pass pointer information on the stack
        =E2=80=90 get interrupt for someone else!
- look over all APIs and ABIs that exist because they have different proble=
ms in
different areas
- XenServer cares most about right now host UEFI secure boot
        =E2=80=90 new priv boundary that does not exist previously
        =E2=80=90 admin with root cannot (should not) violate security boun=
dary, cannot
        read/write arbitrary memroy
        =E2=80=90 hypercalls: open /dev/xen/privcmd and pointers into user =
space
        memory, nothing stops passing kernel pointer memory
                - giant privilege escalation hole in UEFI secure boot
                - root user space is not priv enough to execute arbitrary c=
ode
        =E2=80=90 all problems compound, thus we want to look at all of the=
m before we
        start figuring out what to do
- another example: being based on x86 originally, large hypercalls have a s=
hift
by 12, assume 4k pages, problem with ARM wanting 64k page tables
        =E2=80=90 event the data layout wants to change
- if you change the version of Xen, you break the user space (library versi=
ons)
        =E2=80=90 was intentional choice early on, doesn=E2=80=99t scale
        =E2=80=90 get rid of unstable APIs -- killing xen
- security hotfix - recompile QEMU
        =E2=80=90 ABI rules say any change in hypervisor, thus rebuilding u=
ser space,
        and QEMU -- anything that links against the xen packages!
- Bertrand: look at problem yesterday: how we create and configure a guest,
coherency to reach dom0less
        =E2=80=90 twice code to create a guest, duplicated code
        =E2=80=90 duplicate configuration format
        =E2=80=90 if we modify ABI between dom0 and Xen, need to look at ha=
ve
        coherent format so we can reuse the same code
- Alex M: can we hide hypercalls via libraries?
        =E2=80=90 yes but currently the versions for a break
        =E2=80=90 definitely an option forward
        =E2=80=90 still doesn=E2=80=99t solve the issue, because other libr=
aries in other languages
        won=E2=80=99t be shielded from unstable ABIs
- Jan: both knowing what to do and where we go is useful
        =E2=80=90 Andrew: have to have broad idea where to go....
- Jan: carrying out hypercall is independent of the mechansim we define
        =E2=80=90 Andrew: still needs backwards compatibility
        =E2=80=90 Andrew: use higher op numbers
- Alex M: is our problem unique to us?
        =E2=80=90 Andrew: we have enough corner cases that yes
        =E2=80=90 Bertrand: PV guests require a large number of hypercalls
        =E2=80=90 Jan: keep VA for PV hypercalls
- Rich on call: work together with Chris to write down something difficult =
in
scope
        =E2=80=90 any work written down, useful for folks on other side whe=
re we may
        encounter failures
        =E2=80=90 newcomers: xen forked by HP (?)
        =E2=80=90 everyone tried to narrow to verticle markets, focus on sp=
ecific markets
        =E2=80=90 Xen: is last entity standing, still trying to pull all st=
akeholders together,
        but not sure how long it will last
        =E2=80=90 if collapses: accidental or intentional interoperability,=
 carve out the
        pieces so that the ppl at table today have a chance to know what
        results from it
        =E2=80=90 what will last longest: certified entities that have long=
 lifecycles,
        decades or more
        =E2=80=90 certified snapshots will become longest lived design choi=
ces
- Andrew: shared info page
        =E2=80=90 layout was done with unsigned longs which changed sizes
        =E2=80=90 layout of the shared info page changes
        =E2=80=90 different vcpus can be in different modes at a time
        =E2=80=90 we cache the mode of the cpu at the point which it makes =
one of two
        types of hypercalls
- another design session tomorrow


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124982.1467101 (Exim 4.92)
	(envelope-from )
	id 1uypdf-0001Aa-N4; Wed, 17 Sep 2025 10:43:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124982.1467101; Wed, 17 Sep 2025 10: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 1uypdf-00018O-Ge; Wed, 17 Sep 2025 10:43:51 +0000
Received: by outflank-mailman (input) for mailman id 1124982;
 Wed, 17 Sep 2025 10:15: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 1uypCh-00062y-Jb
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:15:59 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ccd3f76-93af-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 12:15:58 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8sE093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:25 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4ccd3f76-93af-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=Uu80FK/yXlnI37NFgIYNtl95VwZCqRjIMZXhhdmhF1M=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104065; v=1;
        b=QyJv3vZ248Y7SoZ7rWNS++L+0DfaUm9g8fSVALB9v7pLAf6X4hVbSWM39ZMC9y+o
         nOzP1T/LsuuGh8RtkTQzS3ljsikW0nElI4Yo2D9rD3eVoBHS1Fdf58ScQ53giRdt
         GyV3UUD/8nwtM0mYcYMSexmWNGunMYLNOPx8WmKqf0NGjoFzA+gGCyXcWSSDZOKi
         foJw4RAQDbQSw0zLGGJFN1cJ3mryRFuAJWcbDEPv8cvKl2bSK/wxto7+8UgfK8ik
         KyA0vPyq94V9GlrknshqaUrPH5yuJ2W01fFM//XxlJtr8gNFDrwEIYGq0O3B4HlB
         iryWMp26qm5r6DWLySwslA==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:31 +0900
Subject: [PATCH v3 6/7] vfio: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-6-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
 hw/vfio/pci-quirks.c | 9 +--------
 hw/vfio/region.c     | 3 ---
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index 3f002252acfb..83419b1ab58d 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -1150,15 +1150,12 @@ void vfio_vga_quirk_exit(VFIOPCIDevice *vdev)
 
 void vfio_vga_quirk_finalize(VFIOPCIDevice *vdev)
 {
-    int i, j;
+    int i;
 
     for (i = 0; i < ARRAY_SIZE(vdev->vga->region); i++) {
         while (!QLIST_EMPTY(&vdev->vga->region[i].quirks)) {
             VFIOQuirk *quirk = QLIST_FIRST(&vdev->vga->region[i].quirks);
             QLIST_REMOVE(quirk, next);
-            for (j = 0; j < quirk->nr_mem; j++) {
-                object_unparent(OBJECT(&quirk->mem[j]));
-            }
             g_free(quirk->mem);
             g_free(quirk->data);
             g_free(quirk);
@@ -1198,14 +1195,10 @@ void vfio_bar_quirk_exit(VFIOPCIDevice *vdev, int nr)
 void vfio_bar_quirk_finalize(VFIOPCIDevice *vdev, int nr)
 {
     VFIOBAR *bar = &vdev->bars[nr];
-    int i;
 
     while (!QLIST_EMPTY(&bar->quirks)) {
         VFIOQuirk *quirk = QLIST_FIRST(&bar->quirks);
         QLIST_REMOVE(quirk, next);
-        for (i = 0; i < quirk->nr_mem; i++) {
-            object_unparent(OBJECT(&quirk->mem[i]));
-        }
         g_free(quirk->mem);
         g_free(quirk->data);
         g_free(quirk);
diff --git a/hw/vfio/region.c b/hw/vfio/region.c
index d04c57db630f..b165ab0b9378 100644
--- a/hw/vfio/region.c
+++ b/hw/vfio/region.c
@@ -365,12 +365,9 @@ void vfio_region_finalize(VFIORegion *region)
     for (i = 0; i < region->nr_mmaps; i++) {
         if (region->mmaps[i].mmap) {
             munmap(region->mmaps[i].mmap, region->mmaps[i].size);
-            object_unparent(OBJECT(®ion->mmaps[i].mem));
         }
     }
 
-    object_unparent(OBJECT(region->mem));
-
     g_free(region->mem);
     g_free(region->mmaps);
 

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124990.1467125 (Exim 4.92)
	(envelope-from )
	id 1uypdg-0001bM-UF; Wed, 17 Sep 2025 10:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124990.1467125; Wed, 17 Sep 2025 10:43: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 1uypdg-0001XQ-GH; Wed, 17 Sep 2025 10:43:52 +0000
Received: by outflank-mailman (input) for mailman id 1124990;
 Wed, 17 Sep 2025 10:16:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uypCy-00062y-AH
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:16:16 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 53db5649-93af-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 12:16:10 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8s8093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:21 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 53db5649-93af-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=lJRKJLkUtQVuwFEISLl+dhYLnOkVsl4daLaMLN8WUus=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Subject:Date:Message-Id:To;
        s=rs20250326; t=1758104062; v=1;
        b=oSwItlPy6eUaF3lh0yljm0+YCQBLTh6nG41CDwERnyNvvOnjQMl7mGXP+YZv2tHG
         cQ85oqb0YLQ+StopBgfveBRpVYJohzqiHNNR2JdhLymCdpqUr6t6VXy8GRFHTT9R
         cIb8YmgQYR6vHa7S+mPZP9ORB5wu0etavueW/B/ziXBrRzZpESHRoKJwd8fWH5HF
         PtOMtXTi0fLWCW7X5lvU9RjXpf6e6h0rF+AGzgDO4rbZEcArb5JDrw9/xuhAQlbz
         ITpfxxz0BxXfnbauuAqKB2w9aQQgYlR/uCg4Xs6+Tl+oAD9GziK/hKFkTcd2l0eL
         SCbnL+KlTAWECgXyrOaWzQ==
From: Akihiko Odaki 
Subject: [PATCH v3 0/7] Do not unparent in instance_finalize()
Date: Wed, 17 Sep 2025 19:13:25 +0900
Message-Id: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-B4-Tracking: v=1; b=H4sIAMWJymgC/3XMTQ6CMBCG4auQrm3TH5HUlfcwLsowhdFESAuNh
 HB3C2504fKdzPcsLGIgjOxcLCxgokj9M4c5FAw692yRU5ObaalLaeWJTxG5qRDASuMsSpY/h4C
 eXrtyveXuKI59mHc0qe36u0+KSw6lAud8o7CuLiG2AkiQmPjYP+ZeOBD3gW1Y0l+AKj+AzoA/Q
 uW9MrVH+xdY1/UN5gLO0eQAAAA=
X-Change-ID: 20250906-use-37ecc903a9e0
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Based-on: 
("[PATCH v2 00/14] hw/pci-host/raven clean ups")

Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
Changes in v3:
- Added patches to remove other object_unparent() calls in
  instance_finalize().
- Dropped patch "qdev: Automatically delete memory subregions" and the
  succeeding patches to avoid Ccing many.
- Link to v2: https://lore.kernel.org/qemu-devel/20250915-use-v2-0-f4c7ff13bfe9@rsg.ci.i.u-tokyo.ac.jp

Changes in v2:
- Added a reference to "[PATCH] docs/devel: Prohibit calling
  object_unparent() for memory region", which does something similar to
  patch "docs/devel: Do not unparent in instance_finalize()" but I
  forgot I sent it in the past.
- Fixed a typo in patch
  "docs/devel: Do not unparent in instance_finalize()" and
  "[PATCH 02/22] vfio/pci: Do not unparent in instance_finalize()".
- Dropped patches to move address_space_init() calls; I intend to
  QOM-ify to fix memory leaks automatically as discussed in the
  following thread:
  https://lore.kernel.org/qemu-devel/cd21698f-db77-eb75-6966-d559fdcab835@eik.bme.hu/
  But the QOM-ification will be big so I'll send it as a separate
  series.
- Rebased on top of "[PATCH v2 00/14] hw/pci-host/raven clean ups".
  https://lore.kernel.org/qemu-devel/cover.1751493467.git.balaton@eik.bme.hu/
- Link to v1: https://lore.kernel.org/qemu-devel/20250906-use-v1-0-c51caafd1eb7@rsg.ci.i.u-tokyo.ac.jp

---
Akihiko Odaki (7):
      docs/devel: Do not unparent in instance_finalize()
      vfio/pci: Do not unparent in instance_finalize()
      hw/core/register: Do not unparent in instance_finalize()
      hv-balloon: hw/core/register: Do not unparent in instance_finalize()
      hw/sd/sdhci: Do not unparent in instance_finalize()
      vfio: Do not unparent in instance_finalize()
      hw/xen: Do not unparent in instance_finalize()

 docs/devel/memory.rst  | 19 ++++++-------------
 hw/core/register.c     |  1 -
 hw/hyperv/hv-balloon.c | 12 +-----------
 hw/sd/sdhci.c          |  4 ----
 hw/vfio/pci-quirks.c   |  9 +--------
 hw/vfio/pci.c          |  4 ----
 hw/vfio/region.c       |  3 ---
 hw/xen/xen_pt_msi.c    | 11 +----------
 8 files changed, 9 insertions(+), 54 deletions(-)
---
base-commit: e101d33792530093fa0b0a6e5f43e4d8cfe4581e
change-id: 20250906-use-37ecc903a9e0

Best regards,
--  
Akihiko Odaki 



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124979.1467082 (Exim 4.92)
	(envelope-from )
	id 1uypde-0000x4-TX; Wed, 17 Sep 2025 10:43:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124979.1467082; Wed, 17 Sep 2025 10: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 1uypde-0000wx-QN; Wed, 17 Sep 2025 10:43:50 +0000
Received: by outflank-mailman (input) for mailman id 1124979;
 Wed, 17 Sep 2025 10:15: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 1uypCg-00062y-IM
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:15:59 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b878f45-93af-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 12:15:56 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8sD093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:24 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4b878f45-93af-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=hrFeIYsdveoSw39gLf38PDAGKQ7lahlpxgxSM3Eq+7Y=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104065; v=1;
        b=DdLzysLdoItNX02agwRNTGyUnTrzx20tFWGfsRm6Kj1Bcgto7jzT6NanLKz/sw54
         c+SFhhHxg7ZxwyzOUB5Y41jcQzG0ftXjCYbd7tD7stmwz9Yec0hIiAHCjVEYefqo
         Me1eK3UKWbYxbezILi9fy2VOf4+KEZ0NQ+rdsHcRn5ADw2w01gtn/7p1u4GAwcZp
         WUKHC47iY8/4AYK3RupRXpz8oDrep/DTUEkGUxzHWz4bCKSw+EvzspWajKbxAsT6
         HwzYNR5qw2df5gfWZ1Rbu4esPyUm1QZ7oE2EIWvch8aXE6l+SM2RfSA9WQWmc+1c
         RTagV4R6EmSTMQMcY55uCQ==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:30 +0900
Subject: [PATCH v3 5/7] hw/sd/sdhci: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-5-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
 hw/sd/sdhci.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 3c897e54b721..89b595ce4a5a 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1578,10 +1578,6 @@ static void sdhci_sysbus_finalize(Object *obj)
 {
     SDHCIState *s = SYSBUS_SDHCI(obj);
 
-    if (s->dma_mr) {
-        object_unparent(OBJECT(s->dma_mr));
-    }
-
     sdhci_uninitfn(s);
 }
 

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124983.1467107 (Exim 4.92)
	(envelope-from )
	id 1uypdg-0001Lk-1a; Wed, 17 Sep 2025 10:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124983.1467107; Wed, 17 Sep 2025 10:43: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 1uypdf-0001Jb-T7; Wed, 17 Sep 2025 10:43:51 +0000
Received: by outflank-mailman (input) for mailman id 1124983;
 Wed, 17 Sep 2025 10:15: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 1uypCh-00062x-Q9
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:15:59 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4bd59f75-93af-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 12:15:56 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8s9093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:22 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4bd59f75-93af-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=tbKbnY2EjTKUHaLtZsZLQXCBZoyFNJpVfMbynsbGNqo=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104062; v=1;
        b=L8qA32CUCpnM5wR9hyBKh3E3/yVIENsagGU1hOnAgvAMMqlfFWNsMEt2aZTPndT1
         789WFVfvIMnTmjILQ2a/n6nU42rVSG1NwIR23FhPpG2CBeMmrKgzeI5p6qgROC5L
         NBrIr4Xb9ur7ofaNTCvw3IZHWSwJ8n3ReSrCn6YIv/vGP86RhHKGK7ito8oLS6xv
         mhfGB0exEQKh1wFHt2ToijtgXVJRDHSE6hyg1tz+Q4MEV404KUYgN5PZa5xhUt7y
         CDWjSftHQBO/8M3Teael6SsSbVBhBDSPHvF0ko20sHKelxLfwsz7aXE/sqDR1kt9
         3UY9vvUiMSInhL8GYh3TQA==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:26 +0900
Subject: [PATCH v3 1/7] docs/devel: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Remove the instruction to call object_unparent(), and the exception
of the "do not call object_unparent()" rule for instance_finalize().

Signed-off-by: Akihiko Odaki 
---
 docs/devel/memory.rst | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
index 57fb2aec76e0..749f11d8a4dd 100644
--- a/docs/devel/memory.rst
+++ b/docs/devel/memory.rst
@@ -161,18 +161,11 @@ or never.
 Destruction of a memory region happens automatically when the owner
 object dies.
 
-If however the memory region is part of a dynamically allocated data
-structure, you should call object_unparent() to destroy the memory region
-before the data structure is freed.  For an example see VFIOMSIXInfo
-and VFIOQuirk in hw/vfio/pci.c.
-
 You must not destroy a memory region as long as it may be in use by a
 device or CPU.  In order to do this, as a general rule do not create or
-destroy memory regions dynamically during a device's lifetime, and only
-call object_unparent() in the memory region owner's instance_finalize
-callback.  The dynamically allocated data structure that contains the
-memory region then should obviously be freed in the instance_finalize
-callback as well.
+destroy memory regions dynamically during a device's lifetime.
+The dynamically allocated data structure that contains the
+memory region should be freed in the instance_finalize callback.
 
 If you break this rule, the following situation can happen:
 
@@ -198,9 +191,9 @@ this exception is rarely necessary, and therefore it is discouraged,
 but nevertheless it is used in a few places.
 
 For regions that "have no owner" (NULL is passed at creation time), the
-machine object is actually used as the owner.  Since instance_finalize is
-never called for the machine object, you must never call object_unparent
-on regions that have no owner, unless they are aliases or containers.
+machine object is actually used as the owner.  You must never call
+object_unparent on regions that have no owner, unless they are aliases
+or containers.
 
 
 Overlapping regions and priority

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124981.1467092 (Exim 4.92)
	(envelope-from )
	id 1uypdf-00012e-DE; Wed, 17 Sep 2025 10:43:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124981.1467092; Wed, 17 Sep 2025 10: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 1uypdf-00011D-7d; Wed, 17 Sep 2025 10:43:51 +0000
Received: by outflank-mailman (input) for mailman id 1124981;
 Wed, 17 Sep 2025 10:15: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 1uypCh-00062x-JJ
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:15:59 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a7b1545-93af-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 12:15:54 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8sF093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:25 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a7b1545-93af-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=v+Xb+1QVJw0wOnTS9Jio3e/jbQ2BZQtVgu226l6UV38=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104066; v=1;
        b=qEQfSTKEA4U78rKYzbed5g3KZSs3bTwJOaCeJ0jPTsX31Ok70JSdTMTDcNjaYAEK
         Nfsgl2Dk7WOqvjUUENqOPvbH6iVwIn4nzFaJ0CGqkwCyumf4XFQ3dQppxlr20jUb
         hcL+CvT2eXiYoMXuG+wpRdCW2AdceSZ0KuYI7j7Nk/QFY5kiql35cWMEt/PTX/t6
         HSPUn0+O4YgMOCUfQc9KhgV/fKpdSK2ijVaiB21ZrNjIZ9RGrzApRNV+guTZWjUw
         S0IT30OulcQ/p2axRplunesPLlsNUN8r96/kgDZQOuZ1AfqYRaBUQLDCAAIZ84hH
         DMwHkZqV4rdHT966UikOww==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:32 +0900
Subject: [PATCH v3 7/7] hw/xen: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-7-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
 hw/xen/xen_pt_msi.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 09cca4eecb1c..e9ba17317aba 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -637,14 +637,5 @@ void xen_pt_msix_unmap(XenPCIPassthroughState *s)
 
 void xen_pt_msix_delete(XenPCIPassthroughState *s)
 {
-    XenPTMSIX *msix = s->msix;
-
-    if (!msix) {
-        return;
-    }
-
-    object_unparent(OBJECT(&msix->mmio));
-
-    g_free(s->msix);
-    s->msix = NULL;
+    g_clear_pointer(&s->msix, g_free);
 }

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124980.1467087 (Exim 4.92)
	(envelope-from )
	id 1uypdf-0000zg-4o; Wed, 17 Sep 2025 10:43:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124980.1467087; Wed, 17 Sep 2025 10: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 1uypdf-0000yt-1M; Wed, 17 Sep 2025 10:43:51 +0000
Received: by outflank-mailman (input) for mailman id 1124980;
 Wed, 17 Sep 2025 10:15: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 1uypCf-00062x-UP
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:15:59 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a5d253a-93af-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 12:15:54 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8sA093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:22 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a5d253a-93af-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=feDbk9J/yWdV06ehpX8rW3/wvLj8rzMauO12ghjmdGI=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104063; v=1;
        b=lK4jroglAeXdT8FGOvw97ekqlK6fKLYxyxeyuadhi9q7col6rF4pdBsdhaFzZNTY
         3h0H0sctUoxgojDBKvuiDt1AR4/GsNyAnceAlgUPo8uNXm+ZEoRqTv3bHyHBTYWC
         gVGoNGn5VyyBTGuN1/FoivEOtIWURfHGw6f615Qp48pzMMcdwhCDFcYSPw1sPL6h
         rcNxvucJRYybjOE104+B4033Zpl2MsP7qvBHUXgqad2nkJu2yRwQ54lqbWb3+O9W
         3zoe7dP/ozhNgpc93IefFxgFYjQ6K0S9K024DbgYpu1NhTd1E2iyI2SpUUduT9NW
         4IZWPcKBp3sYVux+zGxD0w==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:27 +0900
Subject: [PATCH v3 2/7] vfio/pci: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-2-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the insntance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
 hw/vfio/pci.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 07257d0fa049..2e909c190f86 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2000,7 +2000,6 @@ static void vfio_bars_finalize(VFIOPCIDevice *vdev)
         vfio_region_finalize(&bar->region);
         if (bar->mr) {
             assert(bar->size);
-            object_unparent(OBJECT(bar->mr));
             g_free(bar->mr);
             bar->mr = NULL;
         }
@@ -2008,9 +2007,6 @@ static void vfio_bars_finalize(VFIOPCIDevice *vdev)
 
     if (vdev->vga) {
         vfio_vga_quirk_finalize(vdev);
-        for (i = 0; i < ARRAY_SIZE(vdev->vga->region); i++) {
-            object_unparent(OBJECT(&vdev->vga->region[i].mem));
-        }
         g_free(vdev->vga);
     }
 }

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124989.1467115 (Exim 4.92)
	(envelope-from )
	id 1uypdg-0001R9-CF; Wed, 17 Sep 2025 10:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124989.1467115; Wed, 17 Sep 2025 10:43: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 1uypdg-0001Q2-6x; Wed, 17 Sep 2025 10:43:52 +0000
Received: by outflank-mailman (input) for mailman id 1124989;
 Wed, 17 Sep 2025 10:16: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 1uypCx-00062y-9z
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:16:15 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4feb3452-93af-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 12:16:03 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8sC093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:23 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4feb3452-93af-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=iR0pDnfR/s67erqtJ5ANa4aW2wGgB9XJZzw7HSfqAKs=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104064; v=1;
        b=MxBH9GHNOqphNoMQVv2olt8dlKdOl9TJMNu7YMMgr89UjH08Y9n0qPtjUWRc7iYq
         lo7wdEMxdC51APmdrm9UPh8CfZxb3bk+jspaOXoFRl5jsFlh6Iz5JA9w2KafJbjm
         7G2zQ9gkzbjamjM1dqhH0/0nsPahh7J4IDgAed9rbI3oyhk7UzkHTWGxuXpedIms
         eqX+B0rhLWWiY57QUZbZwVnPuXe+RMKAPemNLSI17uEjFA6zuOduO6K8J8pmjS1W
         venp0dEs+bSLGpYzaBiPhnMbLZv4JIJq1cQxmf71sy3DiC4pu5Z+JvHlF0C65El5
         KJfzqTlQGN/u7Qqj1H6bhQ==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:29 +0900
Subject: [PATCH v3 4/7] hv-balloon: hw/core/register: Do not unparent in
 instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-4-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
 hw/hyperv/hv-balloon.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/hw/hyperv/hv-balloon.c b/hw/hyperv/hv-balloon.c
index 6dbcb2d9a29d..2d6d7db4ee0e 100644
--- a/hw/hyperv/hv-balloon.c
+++ b/hw/hyperv/hv-balloon.c
@@ -1475,16 +1475,6 @@ static void hv_balloon_ensure_mr(HvBalloon *balloon)
     balloon->mr->align = memory_region_get_alignment(hostmem_mr);
 }
 
-static void hv_balloon_free_mr(HvBalloon *balloon)
-{
-    if (!balloon->mr) {
-        return;
-    }
-
-    object_unparent(OBJECT(balloon->mr));
-    g_clear_pointer(&balloon->mr, g_free);
-}
-
 static void hv_balloon_vmdev_realize(VMBusDevice *vdev, Error **errp)
 {
     ERRP_GUARD();
@@ -1580,7 +1570,7 @@ static void hv_balloon_vmdev_reset(VMBusDevice *vdev)
  */
 static void hv_balloon_unrealize_finalize_common(HvBalloon *balloon)
 {
-    hv_balloon_free_mr(balloon);
+    g_clear_pointer(&balloon->mr, g_free);
     balloon->addr = 0;
 
     balloon->memslot_count = 0;

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 10:43:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 10:43:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1124993.1467133 (Exim 4.92)
	(envelope-from )
	id 1uypdh-0001i2-AA; Wed, 17 Sep 2025 10:43:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1124993.1467133; Wed, 17 Sep 2025 10:43: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 1uypdg-0001f7-S8; Wed, 17 Sep 2025 10:43:52 +0000
Received: by outflank-mailman (input) for mailman id 1124993;
 Wed, 17 Sep 2025 10: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 1uypHL-00076j-TS
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 10:20:47 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f80102fe-93af-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 12:20:45 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HAE8sB093528
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 19:14:23 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f80102fe-93af-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=Nb2IXk8Wd06JvJLljjYiPCsN3a3uINbunrK794JTiso=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758104063; v=1;
        b=Oo5GWWtwzsWYxzsGXA+JY0CJMcCICiVhaS9y1lRGW6PO5yUYUtN7uDfQqIA+lXRU
         Mo+ydn8Pe1RE5VeibUxfmj5y5G6MG0wUf+OtIDjTsYV9r5RXrrMAjWDMp8dKz3yj
         ht41kegl/A3FFKssuK+aJknlqAd3KHu7LRAYDxciSex2hne/1KdIqOXAeuVX1Caj
         Edp+fiXbGzHVqbrHbuqVUH+WZlV97MmCbLcuPv1auKXr0wlmF9c0GsAy+ueVvcIO
         rO3wR19/WdYoURQwly6sr4aZMC4Oj5OmcBHc+GKDta9yK+7chuS/LRxIONFhkHEz
         mhj736rzwMlM6d3TKkXjzw==
From: Akihiko Odaki 
Date: Wed, 17 Sep 2025 19:13:28 +0900
Subject: [PATCH v3 3/7] hw/core/register: Do not unparent in
 instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250917-use-v3-3-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
 hw/core/register.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/core/register.c b/hw/core/register.c
index 8f63d9f227c4..3340df70b06e 100644
--- a/hw/core/register.c
+++ b/hw/core/register.c
@@ -314,7 +314,6 @@ RegisterInfoArray *register_init_block64(DeviceState *owner,
 
 void register_finalize_block(RegisterInfoArray *r_array)
 {
-    object_unparent(OBJECT(&r_array->mem));
     g_free(r_array->r);
     g_free(r_array);
 }

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 11:58:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 11:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125124.1467164 (Exim 4.92)
	(envelope-from )
	id 1uyqnb-0005BB-Lm; Wed, 17 Sep 2025 11:58:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125124.1467164; Wed, 17 Sep 2025 11: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 1uyqnb-0005B4-I2; Wed, 17 Sep 2025 11:58:11 +0000
Received: by outflank-mailman (input) for mailman id 1125124;
 Wed, 17 Sep 2025 11:58: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 1uyqna-0005Ay-46
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 11:58:10 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9253347b-93bd-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 13:58:08 +0200 (CEST)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-614-vfRmwMIKMIKOyYB0nkQjsQ-1; Wed,
 17 Sep 2025 07:58:02 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id D6588195608B; Wed, 17 Sep 2025 11:57:54 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 8976C19560B8; Wed, 17 Sep 2025 11:57: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: 9253347b-93bd-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758110285;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:in-reply-to:in-reply-to:  references:references;
	bh=GLbcYhOmZLOkQI2riqXN1sQU5QUildnLa02awuxxLvA=;
	b=Wc+VemoZm8DujJyN0e1pjtIgYpNY4gBcZDYETIrsyT+PvVrKbLU+JoanWiud4oieNnKBZL
	pu+EGrOK22tCtlGd/8e6pAqImkBHRqYjlucHJrl2pt7ACEoe2ZbsdBAgdLjnWXo+71+FKE
	FxgPdsIMcgEj794AJzvnfYydL+WDJMg=
X-MC-Unique: vfRmwMIKMIKOyYB0nkQjsQ-1
X-Mimecast-MFC-AGG-ID: vfRmwMIKMIKOyYB0nkQjsQ_1758110277
Date: Wed, 17 Sep 2025 12:57:31 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12

On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> Based-on: 
> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> 
> Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
> ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
> 
> Children are automatically unparented so manually unparenting is
> unnecessary.

Where is automatic unparenting you're referring to being done ?

> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.

IIUC, object_property_add_child will acquire a reference on
the child, and object_property_del_child (and thus
object_unparent) will release that reference.

The 'object_finalize' method, and thus 'instance_finalize'
callback, won't be invoked until the last reference is
dropped on the object in question.

IOW, it should be impossible for 'object_finalize' to ever
run, as long as the child has a parent set.

So if we're in the 'finalize' then 'object_unparent' must
be a no-op as the child must already have no references
held and thus no parent.

IOW, the reason to remove 'object_unparent' calls from
finalize is surely because they do nothing at all,
rather than this talk about callbacks being run at the
wrong time ?

> 
> Signed-off-by: Akihiko Odaki 
> ---
> Changes in v3:
> - Added patches to remove other object_unparent() calls in
>   instance_finalize().
> - Dropped patch "qdev: Automatically delete memory subregions" and the
>   succeeding patches to avoid Ccing many.
> - Link to v2: https://lore.kernel.org/qemu-devel/20250915-use-v2-0-f4c7ff13bfe9@rsg.ci.i.u-tokyo.ac.jp
> 
> Changes in v2:
> - Added a reference to "[PATCH] docs/devel: Prohibit calling
>   object_unparent() for memory region", which does something similar to
>   patch "docs/devel: Do not unparent in instance_finalize()" but I
>   forgot I sent it in the past.
> - Fixed a typo in patch
>   "docs/devel: Do not unparent in instance_finalize()" and
>   "[PATCH 02/22] vfio/pci: Do not unparent in instance_finalize()".
> - Dropped patches to move address_space_init() calls; I intend to
>   QOM-ify to fix memory leaks automatically as discussed in the
>   following thread:
>   https://lore.kernel.org/qemu-devel/cd21698f-db77-eb75-6966-d559fdcab835@eik.bme.hu/
>   But the QOM-ification will be big so I'll send it as a separate
>   series.
> - Rebased on top of "[PATCH v2 00/14] hw/pci-host/raven clean ups".
>   https://lore.kernel.org/qemu-devel/cover.1751493467.git.balaton@eik.bme.hu/
> - Link to v1: https://lore.kernel.org/qemu-devel/20250906-use-v1-0-c51caafd1eb7@rsg.ci.i.u-tokyo.ac.jp
> 
> ---
> Akihiko Odaki (7):
>       docs/devel: Do not unparent in instance_finalize()
>       vfio/pci: Do not unparent in instance_finalize()
>       hw/core/register: Do not unparent in instance_finalize()
>       hv-balloon: hw/core/register: Do not unparent in instance_finalize()
>       hw/sd/sdhci: Do not unparent in instance_finalize()
>       vfio: Do not unparent in instance_finalize()
>       hw/xen: Do not unparent in instance_finalize()
> 
>  docs/devel/memory.rst  | 19 ++++++-------------
>  hw/core/register.c     |  1 -
>  hw/hyperv/hv-balloon.c | 12 +-----------
>  hw/sd/sdhci.c          |  4 ----
>  hw/vfio/pci-quirks.c   |  9 +--------
>  hw/vfio/pci.c          |  4 ----
>  hw/vfio/region.c       |  3 ---
>  hw/xen/xen_pt_msi.c    | 11 +----------
>  8 files changed, 9 insertions(+), 54 deletions(-)
> ---
> base-commit: e101d33792530093fa0b0a6e5f43e4d8cfe4581e
> change-id: 20250906-use-37ecc903a9e0
> 
> Best regards,
> --  
> Akihiko Odaki 
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 12:26:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 12:26:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125140.1467172 (Exim 4.92)
	(envelope-from )
	id 1uyrEm-0000cv-PW; Wed, 17 Sep 2025 12:26:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125140.1467172; Wed, 17 Sep 2025 12:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyrEm-0000co-Mo; Wed, 17 Sep 2025 12:26:16 +0000
Received: by outflank-mailman (input) for mailman id 1125140;
 Wed, 17 Sep 2025 12: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 1uyrEk-0000ci-JH
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 12:26:15 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7eb24e9f-93c1-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 14:26:13 +0200 (CEST)
Received: from [133.11.54.205] (h205.csg.ci.i.u-tokyo.ac.jp [133.11.54.205])
 (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58HCO5JM035551
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 17 Sep 2025 21:24:05 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7eb24e9f-93c1-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=7Wlnz80tbhY7qRbZWs6EVByRB96OxlH4d0GlP1+LXn4=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=Message-ID:Date:Subject:To:From;
        s=rs20250326; t=1758111846; v=1;
        b=pcA8k4lRgBS+t8ieEiJwckoiL6SVDotMvZ+SV6ab51ZpRmSZyNHvPc1tsm2O60Z3
         Vabanu3VGyMcDlvcTQMXwUgSGM/R4Jnh/R3IDNzM5e1R3HgJDb2e5mIzVFRbiwUM
         KsXbDp5IK3b97+7+r5cI8qagpx1WBNngXicMKex9/qHpeXUVy0rpDmZsO0PEx0Rb
         EF9uZa7bjHuJF/0Q6D7LZBneKBPEqtgTamSWtX+vQPcVa14v1PSzh6qbcvRLSAet
         AyZ4qOdB0eryLyrNWxaSLxlFUUWtkZN8b1o+cuCe9TTBTJ/abyzONpk9IcMp0uUH
         /kM7345Karx0jA73rC5T1Q==
Message-ID: 
Date: Wed, 17 Sep 2025 21:24:04 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
        =?UTF-8?Q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?=
 ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?UTF-8?Q?Alex_Benn=C3=A9e?=
 ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo
 ,
        Max Filippov ,
        =?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
Content-Language: en-US
From: Akihiko Odaki 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
>> Based-on: 
>> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
>>
>> Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
>> ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
>>
>> Children are automatically unparented so manually unparenting is
>> unnecessary.
> 
> Where is automatic unparenting you're referring to being done ?
> 
>> Worse, automatic unparenting happens before the instance_finalize()
>> callback of the parent gets called, so object_unparent() calls in
>> the callback will refer to objects that are already unparented, which
>> is semantically incorrect.
> 
> IIUC, object_property_add_child will acquire a reference on
> the child, and object_property_del_child (and thus
> object_unparent) will release that reference.
> 
> The 'object_finalize' method, and thus 'instance_finalize'
> callback, won't be invoked until the last reference is
> dropped on the object in question.
> 
> IOW, it should be impossible for 'object_finalize' to ever
> run, as long as the child has a parent set.
> 
> So if we're in the 'finalize' then 'object_unparent' must
> be a no-op as the child must already have no references
> held and thus no parent.
> 
> IOW, the reason to remove 'object_unparent' calls from
> finalize is surely because they do nothing at all,
> rather than this talk about callbacks being run at the
> wrong time ?

This patch series deals with the situation where the parent calls 
object_unparent() in its instance_finalize() callback. The process of 
finalization looks like as follows:

1. The parent's reference count reaches to zero. Please note that there 
can be remaining children that are referenced by the parent at this point.

2. object_finalize() is called.

2a. object_property_del_all() is called and the parent releases 
references to its children. This is what I referred as "automatic 
unparenting". The children without any other references will be 
finalized here.

2b. instance_finalize() is called. Past children may be already 
finalized, and calling object_unparent() here will cause dereferencing 
finalized objects in that case, which should be avoided.

Regards,
Akihiko Odaki


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 13:18:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 13:18:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125159.1467183 (Exim 4.92)
	(envelope-from )
	id 1uys3B-0006hV-HG; Wed, 17 Sep 2025 13:18:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125159.1467183; Wed, 17 Sep 2025 13:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uys3B-0006hO-E9; Wed, 17 Sep 2025 13:18:21 +0000
Received: by outflank-mailman (input) for mailman id 1125159;
 Wed, 17 Sep 2025 13:18: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 1uys3A-0006gz-3C
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 13:18:20 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5398d18-93c8-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 15:18:17 +0200 (CEST)
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-ZAwOnfOcOMO9PEQblHgkzQ-1; Wed,
 17 Sep 2025 09:18:14 -0400
Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A350A18002D6; Wed, 17 Sep 2025 13:17:58 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 8FCDC180044F; Wed, 17 Sep 2025 13:17: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: c5398d18-93c8-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758115095;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Qdcwf8s9HmUuLp1IBeZbjsBqwFaRhrktluqh5mPF+QI=;
	b=LDpZlZ8om0QLKIkTFGNZyEahbvWgs7cDFzgtGZ5cFNeKpp0FutUvtCBRYsvoPrPCabYX+N
	Qedh22UjmsAa384HT/YaNNwLWdimSV/fzNiGRbo5u850BAKZL35Jz2BysmWAB4X0uCCgDw
	EsdIOTlMbclrkHzJMXyg/Vme3rawCZo=
X-MC-Unique: ZAwOnfOcOMO9PEQblHgkzQ-1
X-Mimecast-MFC-AGG-ID: ZAwOnfOcOMO9PEQblHgkzQ_1758115081
Date: Wed, 17 Sep 2025 14:17:35 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93

On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > Based-on: 
> > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> > > 
> > > Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
> > > ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
> > > 
> > > Children are automatically unparented so manually unparenting is
> > > unnecessary.
> > 
> > Where is automatic unparenting you're referring to being done ?
> > 
> > > Worse, automatic unparenting happens before the instance_finalize()
> > > callback of the parent gets called, so object_unparent() calls in
> > > the callback will refer to objects that are already unparented, which
> > > is semantically incorrect.
> > 
> > IIUC, object_property_add_child will acquire a reference on
> > the child, and object_property_del_child (and thus
> > object_unparent) will release that reference.
> > 
> > The 'object_finalize' method, and thus 'instance_finalize'
> > callback, won't be invoked until the last reference is
> > dropped on the object in question.
> > 
> > IOW, it should be impossible for 'object_finalize' to ever
> > run, as long as the child has a parent set.
> > 
> > So if we're in the 'finalize' then 'object_unparent' must
> > be a no-op as the child must already have no references
> > held and thus no parent.
> > 
> > IOW, the reason to remove 'object_unparent' calls from
> > finalize is surely because they do nothing at all,
> > rather than this talk about callbacks being run at the
> > wrong time ?
> 
> This patch series deals with the situation where the parent calls
> object_unparent() in its instance_finalize() callback. The process of
> finalization looks like as follows:
> 
> 1. The parent's reference count reaches to zero. Please note that there can
> be remaining children that are referenced by the parent at this point.
> 
> 2. object_finalize() is called.
> 
> 2a. object_property_del_all() is called and the parent releases references
> to its children. This is what I referred as "automatic unparenting". The
> children without any other references will be finalized here.
> 
> 2b. instance_finalize() is called. Past children may be already finalized,
> and calling object_unparent() here will cause dereferencing finalized
> objects in that case, which should be avoided.

Oh, so these object_unparent calls run by the parent, against the child
in fact use-after-free flaws.

This is driven by the parent keeping hold of explicit pointers to the
child (MemoryRegion), without also holding its own reference, and these
pointers are invalidated when the parent<->child property is deleted.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 13:24:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 13:24:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125171.1467193 (Exim 4.92)
	(envelope-from )
	id 1uys8y-0008Dd-5O; Wed, 17 Sep 2025 13:24:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125171.1467193; Wed, 17 Sep 2025 13:24: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 1uys8y-0008DW-2f; Wed, 17 Sep 2025 13:24:20 +0000
Received: by outflank-mailman (input) for mailman id 1125171;
 Wed, 17 Sep 2025 13:24: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 1uys8x-0008DQ-9H
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 13:24:19 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 979e214b-93c9-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 15:24:09 +0200 (CEST)
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-658-PodyvTI3NAK437XH95VlJw-1; Wed,
 17 Sep 2025 09:24:07 -0400
Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 774A11800562; Wed, 17 Sep 2025 13:23:58 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 716B33002D26; Wed, 17 Sep 2025 13:23: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: 979e214b-93c9-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758115448;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=hLRV015Povt+VNSvSRUbgvoZOhQwts5tuReFT3LIL+Q=;
	b=imINsUi1zaoak+U84XPEaMPtZMuQ08EdlbY0HlnOPKyR9BRjquPi6pSkK+YtjfaHGLJcFU
	6awexKLxEfZlSyXdH7lRyXT4cB3Fgu/LTjg5nlugq0wlM5s/t2N8kYx4a3v+yMHA0CWCZU
	6gNyx5g1lNES/maSblLlCUE8wBgtZvk=
X-MC-Unique: PodyvTI3NAK437XH95VlJw-1
X-Mimecast-MFC-AGG-ID: PodyvTI3NAK437XH95VlJw_1758115441
Date: Wed, 17 Sep 2025 14:23:35 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki , qemu-devel@nongnu.org,
	Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4

On Wed, Sep 17, 2025 at 02:17:35PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> > On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > > Based-on: 
> > > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> > > > 
> > > > Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
> > > > ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
> > > > 
> > > > Children are automatically unparented so manually unparenting is
> > > > unnecessary.
> > > 
> > > Where is automatic unparenting you're referring to being done ?
> > > 
> > > > Worse, automatic unparenting happens before the instance_finalize()
> > > > callback of the parent gets called, so object_unparent() calls in
> > > > the callback will refer to objects that are already unparented, which
> > > > is semantically incorrect.
> > > 
> > > IIUC, object_property_add_child will acquire a reference on
> > > the child, and object_property_del_child (and thus
> > > object_unparent) will release that reference.
> > > 
> > > The 'object_finalize' method, and thus 'instance_finalize'
> > > callback, won't be invoked until the last reference is
> > > dropped on the object in question.
> > > 
> > > IOW, it should be impossible for 'object_finalize' to ever
> > > run, as long as the child has a parent set.
> > > 
> > > So if we're in the 'finalize' then 'object_unparent' must
> > > be a no-op as the child must already have no references
> > > held and thus no parent.
> > > 
> > > IOW, the reason to remove 'object_unparent' calls from
> > > finalize is surely because they do nothing at all,
> > > rather than this talk about callbacks being run at the
> > > wrong time ?
> > 
> > This patch series deals with the situation where the parent calls
> > object_unparent() in its instance_finalize() callback. The process of
> > finalization looks like as follows:
> > 
> > 1. The parent's reference count reaches to zero. Please note that there can
> > be remaining children that are referenced by the parent at this point.
> > 
> > 2. object_finalize() is called.
> > 
> > 2a. object_property_del_all() is called and the parent releases references
> > to its children. This is what I referred as "automatic unparenting". The
> > children without any other references will be finalized here.
> > 
> > 2b. instance_finalize() is called. Past children may be already finalized,
> > and calling object_unparent() here will cause dereferencing finalized
> > objects in that case, which should be avoided.
> 
> Oh, so these object_unparent calls run by the parent, against the child
> in fact use-after-free flaws.

Oh actually not a use-after-free since memory regions aren't directly
freed by object_finalize.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 13:59:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 13:59:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125189.1467202 (Exim 4.92)
	(envelope-from )
	id 1uysgy-0003rS-OH; Wed, 17 Sep 2025 13:59:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125189.1467202; Wed, 17 Sep 2025 13: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 1uysgy-0003rL-LU; Wed, 17 Sep 2025 13:59:28 +0000
Received: by outflank-mailman (input) for mailman id 1125189;
 Wed, 17 Sep 2025 13: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 1uysgw-0003rF-T9
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 13:59:26 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83828a8f-93ce-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 15:59:24 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by DU0PR03MB9708.eurprd03.prod.outlook.com (2603:10a6:10:44c::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.19; Wed, 17 Sep
 2025 13:59:19 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9115.020; Wed, 17 Sep 2025
 13:59: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: 83828a8f-93ce-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RU9eCQUgmUXO+AkBJwRzbaU4TkKWmoQNsLoR+v1HvBmiz4hZLqEmEuL9sYAzxisbCbWEujJdq8pJJjcv+TMABA5RzhpQ3MfKWRBytm0oAB4OJdrQE16q/QhRNkaxhtPZMlJulgy7BYC+877zHI6D+Jb8Svlj99AccTixU6LbT4xx0uVPjS7VPKfz+AbHXeOw88QU6zJXNPzXEt8S/OjdaBNxGaTJ+Iz5RZQOa4B824lzdPZLM1CQcFNgj0uowVCLrf939Xq7vqYTb4W3pKOf+UfxtqBqO54TAWNMdsnUBv6Y1pAgfUlyS2ReGwqt1fG+FQFh1f2WvETPX9kyOH3Xsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zXPHv0eiWB6fWamkDKEiVENzRxdZ90Y2Irf6aq8NUXQ=;
 b=uTqHZAGPiSprcJcBKNltA1lRmakOwJPfwy06YEu8EDjlyH7pzstZpitTxLCrsN0MwsA4cVm9PliQWDofpt5TPVmUnXwHLC5vPwi8e423jo2U9ckalHztqktHdji5sLyCgESA2p0uv9ZgcrwCLqfjpBfdiXGwvHKy2QDUQ4+PWhrB2oz21Gzf9EXJN4JX+3nN3rgWpvlvl5teiFMe9e9NJVHKej7FHNkfb6ewaQD2sawZBdFrnzrgqJnH8t3KPMBRcfSWapYDFC0HyTUjc+C1qPCJnyIw0HgmAw777rb+T3Q2nVmMD782pCCQoMkthVHl3L8C9qiXuPofx0vIhKFxyQ==
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=zXPHv0eiWB6fWamkDKEiVENzRxdZ90Y2Irf6aq8NUXQ=;
 b=azVpY4x89briIXhAu+0HmHmpqjLi+ewu+bmSP1BOptWGkGzZGywFhL7yNZSJ1kAf0vFay7JFwKAQSs1FlJrk71pr+mfC1koFkB7ASGkd4qd16vtOJuumd6yGhRuv5DEKRurDRXVt4iQWPUe7aPwQD9Nh54aj6J87LLUwgFvuSC/SuyVMHgWzcuRL9IPNEs8idemrYXy8wuVGORlBGph5mxZTjCXQa2kQYGHbWj0kdXJJE74Jkoovq/p5Ts+1XNlavy0giWStYwSSqCDWDaRdmr19jknY6uJJPp+crr8Qzy3EWsQYuMmOGbPY0Mc0EFmBWjYTou9g2kNQfebp08ZDrA==
From: Dmytro Prokopchuk1 
To: Jan Beulich 
CC: Nicola Vetrini , Doug Goldstein
	, Stefano Stabellini , Andrew
 Cooper , Anthony PERARD
	, Michal Orzel , Julien
 Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Topic: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Index: AQHcJwfEWjVU7vF+102YDgRq9OEY77SV3fSAgABWKoCAAAe4AIABLJwA
Date: Wed, 17 Sep 2025 13:59:18 +0000
Message-ID: 
References:
 <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
 
 
 
In-Reply-To: 
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: GV2PR03MB9572:EE_|DU0PR03MB9708:EE_
x-ms-office365-filtering-correlation-id: fb6c898b-a3fb-470e-69af-08ddf5f26572
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|42112799006|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bjV2MFRwclc4UGdrYjN6bEVLaDZRMWNUaFRXQUVFZERiYjB3SjFzZGRPeVFE?=
 =?utf-8?B?b0JSVjRCc1N2TnZyNHhnVmJlUlpsNXNjQmJOVTlGbVpvZmhSSDBLT2w4b0di?=
 =?utf-8?B?clk3Q0JaM2U4cXVkcW5rV3VMRmlWaXlJODh1dHJMbS9UNVR1TGVBMlpGRmhB?=
 =?utf-8?B?U3ZLSXUzMVZWWUgyTHVvam85cWJWT2sxSUcrd2QxVXNOb0hJMFFTdFBMOCt6?=
 =?utf-8?B?Qm5mVXlIZTlSRXlIS1ZrcUZadVpJUlhDTHRGNnJHOVFTNDR2Y1BOd1hFMzE4?=
 =?utf-8?B?T3RLZk0vTXB4OFRwdVA2TVhlb0U5K3g4Myt1VWp1VXVnUHdPR0hINVJJREJV?=
 =?utf-8?B?TFE2V2E4aElBek14a01mS0dQQ2FDWEJnN2x1Zk5Fd3NMdEpUdG1yYkp4K3pX?=
 =?utf-8?B?cUhCVUYzV0Uvb21YVEZudzlzQUc1bE8wbTNkNDFkNUNHNEVaZDNTUUNKcHht?=
 =?utf-8?B?SDdCamphall6WlhBOW5KUnk0YmpOYW9VaDVacE5kMG9kNmI2bDFCSTNYSkdU?=
 =?utf-8?B?TDJYaEVtS1NlYW1GaHBRRXVNRmM2dUdDZE0rVkQzOWI5N1BDSWl0cVJQdG9U?=
 =?utf-8?B?YktLOURZczFJWGY0SmErYjJpQzZWdGJKQTVFTEt0dGRUSWhEc09ENDAzZFR0?=
 =?utf-8?B?Yk8rcWE2UkFOMFR6aE5tVGw0QzlNVkNQWVgvWCtxeWVVMEkvUWdscWpsZEdt?=
 =?utf-8?B?MEoyMmdrekEzUTI5cms0OVQzNW1LY2lYSUlGQmZWSHViZkN5SDZxU3Y1RTJT?=
 =?utf-8?B?OFZMVWFvUk1LZHRwYjV0b0lNK2JLOUw1cEh3TGs3QzlKVGJQZTlsQ3phWCto?=
 =?utf-8?B?R1gwTVlCTm1VQWpRRmJFRnpuckFDL1g1c3pQcEhrL2MrczZMSFR2NWp4aU5z?=
 =?utf-8?B?azNUN1VFVDZvYk8vdEdmVGtIa2pjSkZXRFBYRWdlN0xzRUJSeXU1b2xVQlZy?=
 =?utf-8?B?cGJKdVp5MkRqRk9wZDdMUkhaMFFqbmo3WWxnS3FMSHA1bFovaVlsemYraS95?=
 =?utf-8?B?YmhybWtJaE1XMnlNV1AzTDZXdXJIVGtYVDBwcEpncnNJb0x0WitrM0p1QS9x?=
 =?utf-8?B?bnFtN3hoTysvdTRCZ1NvMEsrUENnTHJnR1NHbGZoUXhSckhPY3lJNDNQMUZB?=
 =?utf-8?B?ckg4T21HNUwrNjVtVnBYcDZrVmpBVWcxSUJOTFgzYjB4cmlxUTVDZnBLMFZJ?=
 =?utf-8?B?bHZWeC84U1F2N0o4dmtWaUVzOFFkQVcrcW1EUHNTdUI4WXRpSkpDQ1FkZG94?=
 =?utf-8?B?cnhNQlczbkhMZEwvTEUwK0RYYXlkcXhCaXR0anBDZWNuK0hYVGhvNzJZMEFF?=
 =?utf-8?B?TG93ZVBQeXMxQ2wvTktYc0xkNDRoakhOdEsvYXh0UUxhb1AwT2kvS21BcUcy?=
 =?utf-8?B?YnRCYnJGWjYvcXFsRmFZQklCOFVCUkFQenpoM0VNRjYzb1dxcVA4cXZVL0lK?=
 =?utf-8?B?Qm1lTUxkbmxDbzJhaEl4WHArSVJvdFVMb0RML09KQlY0YTlXSi9VL0l5NlFH?=
 =?utf-8?B?L2VlNWc3eEh1R3ZraFBiOGgyTGNWWVZNVkI4dU1xTE1WNjYwYzhrQUJraWx0?=
 =?utf-8?B?VE9McEJDS2FGQVVKQXpMQ2RyWUVqajVGdEllb0lMbGFVR2VsMmhpR1Vmbmtu?=
 =?utf-8?B?Y1RSeHVYa3EzVm9YanQzeFpNZDlqeVd2YWt1ejZuVzFvZW9yUHlXZE10UzZ5?=
 =?utf-8?B?K2ROZXFtb2ZES3RkY3dDRStsUFhiM2hqa05YSEcvV1RaS2I1YjBhMjlDaDhW?=
 =?utf-8?B?L3J2VHh6dldSZVpDL1R5NXhSM3g1RjVmV1AyWjcxSzFBUFUzWHQyTVZxdlll?=
 =?utf-8?B?RjNTZ2I1NzN3bHFXYjZUajBnQVI5MnVJdWpuMThaUFNlRVJYVTR2SURRNkgz?=
 =?utf-8?B?ck01MTJjTnc1YVV0eGxxYlZmZmdvVTdkMHZSM2FFdHhDVzdJblZtdVYxRmV6?=
 =?utf-8?B?Q2JKMnJXVk14c0x0aFIzTGhkQS83eFlDMlFCaGF4YWlQc1VoZkRqVlV5UTNl?=
 =?utf-8?B?L2pZZEZFS3dnPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(42112799006)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SFJJRGJUeDQ0VlhiWm5LYWxBa2J5NHBhSEYxM1RWUVUxRVpkUDF3bVZPTit2?=
 =?utf-8?B?ekdnZmcrUGFJRXgwRkMrNE5xQUxVbk5JeHhBTzQ2VHpiT2pNNXRBa2xlTzN5?=
 =?utf-8?B?NUVLdUFqRDdwZnBUZlJnOElkdlpWRmpRRFNHYU5wTkZuc3c1MjZIeXIwN3Bz?=
 =?utf-8?B?WjJGSG8vYWhndnp4RnVycDl1NjRDQ3FjRjRqc2o0bjRra3ZzWHFBdVloRVZn?=
 =?utf-8?B?ZEdLNUtoK1k5VU5XczhSSnlPbTNVNXYybVozaWlVdCtSM2RBUXlNcDhZYnZT?=
 =?utf-8?B?OWNyZGw1M0xhUEdmWVpXM3hUY1VqeHp5WWRxbmlMOVgwd1ZWNmNudUN0NkVl?=
 =?utf-8?B?aUkyYWdzUEJLSXpoVkJxdXRobWcrSlhvZlR1eTFKUk0yb093THliVHl0b3BP?=
 =?utf-8?B?Z1BLMm05TjIzb1NOczNxNlYwbTlwUU5wN05uZDNVSjFxbnZXK0RLdW0zUkdV?=
 =?utf-8?B?dDBqbzJLZUhHUEV5TUNNLzNrS3YwSlU0YmFwRFgvNVFtSGt2dEJLU2J3aDl6?=
 =?utf-8?B?VFR1ZDlGbjZoSS9FZ2NNdG1ReHQzUmtWTzRNclFXT1ZjQjNFZHk4MG4zditv?=
 =?utf-8?B?VWxhRzZhRm0wZENwcHllY3NGWWNETTNVeHlVZkdWeWdwK0djdjZvbVNzcE1L?=
 =?utf-8?B?bnNUVGc0Y3JwZ2xweHVCSEFzRVVVMzdrTG9UTXVDVHVWUFVRbGsxTUQyU3Br?=
 =?utf-8?B?VzZnWHBlMmc0OEtKTXd1Q3RwMEJFWmVDN1RBV0NSU0Mydm1FZ1liV0VnMVdl?=
 =?utf-8?B?OU93NEdPVFAzRjkxVmMzQ0RWRFNVSTBWekhlbzNQeFEwY2dNaDZvdTE3akdr?=
 =?utf-8?B?N1NjaTNDYjRrRmo1dWQ2aExPM3VRa2J3dlRrUE14T3Q3M1I2SmNMRDl4SGdv?=
 =?utf-8?B?QnA2UUtndFZyWlBrNVZUNEdaWGg3bm5CMWFDY3JYK3g3SmlrK1pwRTkrVlJv?=
 =?utf-8?B?WGNoU01DMnJaR3NFN0c5STM3aVloRStVWG5FQU43bXNXNnhVaUxFMGRFT3Zt?=
 =?utf-8?B?Mk94ZitGenlTQVBMZnJqYkNPdE82bWlTd0F0VEsyNm0yVUFxc0Z0QStsbGts?=
 =?utf-8?B?TUlZcTRNb0lzUWNDVHZlaDBmc0hGZytmUXdrRlk0emZoK2dLRXUrY3BPdFBm?=
 =?utf-8?B?RGgxZ0g3ZVhkZ3VwbVRsZENubzgwRlVPN2traGJ0MVJQNjArREdjdVlNaDN5?=
 =?utf-8?B?b2N5T3p5VTFxNXVha0hPaDJBU1kwN0srUG5rY1hHRDlqQXV4Q0x5VDNQbzFW?=
 =?utf-8?B?akxLOTlsT2FadTFJeXhPK2RQRHMzaHltczRnMCtNNXZrajU3UFhnQ2ZHdmVr?=
 =?utf-8?B?b0lyaXg5dmRDai9uTXVQWmZDcjBPS21KSTB4bVFzdTAvaVM0N05WeGlYSmJ6?=
 =?utf-8?B?a0k3WUU5RXVtYTJZZTVuaEFCZjE3Z0tXYjVFcS9PUVhwdmp3eVJ4YysvOWQz?=
 =?utf-8?B?VDJmVkx6bGZzbUE5RUVMVEwzUW1oMXVyZmdWUzRNcVBqZGJFbGlKMnhTakFs?=
 =?utf-8?B?VzZqS2haQzRyc2ZobE9VNEVVSGtFQ3F5MGxCNjgvYVQwMmJWVEhlQnovcEdP?=
 =?utf-8?B?R08vcHUyVmdrMjRmUEFkaFRoaCtmbVJ0VmpEMGJNcUFHb3VaYytwVU5vM1hF?=
 =?utf-8?B?TkNUWm9najcrVFY0WTdqUHFxRmNjb2xFbU9XMGk5dWFvanYvdEErdFVxdzF5?=
 =?utf-8?B?bG9tUGN5SlF0YmFVcC9LcmZIYm5QOFhYcjc0OW41R2h1OStDalEvZUkwMEw5?=
 =?utf-8?B?aGw3UzN5R3VPa1dnMDJPOFJyKzd6aGJoMkZKeDlWSEQ5Z01raDlzcXoxdGRG?=
 =?utf-8?B?VERHU2x0NDNJeFRPblZFd3c0VmtxVVhpdE1EakI3Yk5xdkRWemdoSkNzczF2?=
 =?utf-8?B?Zi92S1REZGFuaFJ1T3NUaU9NeXhTMDh1V2JUdC9GTjFjc2ZCZWRYNlRCaktY?=
 =?utf-8?B?WnBhcmdxeGxFamdQdXRQeXBoTlo0Wm9SZWZxS3ZxSFFWeWluZnNJOWt4RzA1?=
 =?utf-8?B?U0N0dFNsRWI4dWFaWHBvQmc1a1BRUGZzaUFON0d2N3ZoRXpXVDdBdDZDcEdH?=
 =?utf-8?B?Q00rQUZHSzlEUkVici8rWHE5RDRsd3FuU3V0bG92c2wySlRqbVJITzNPaFRR?=
 =?utf-8?B?V3ZOcFZLVmdZTDdzc0lPb2ZhdUM0S3QranB0aTYrRUsxQko1cm9wc2ltdWVw?=
 =?utf-8?B?cVE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1EAFDF7CFA156742AAF752ED94AB9AD0@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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb6c898b-a3fb-470e-69af-08ddf5f26572
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2025 13:59:18.9218
 (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: UuqJKGuz2pY1fo8PcwLdag2fRUtL8YlUmyYcSDVgGvcIDKwE9WFWYfHBczdb2Pj3QyeIlNNo7MCJRYS0YM21blY22wll6+Aa8P54emwcxxU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9708

DQoNCk9uIDkvMTYvMjUgMjM6MDMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNi4wOS4yMDI1
IDIxOjM1LCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+Pg0KPj4NCj4+IE9uIDkvMTYvMjUg
MTc6MjcsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE2LjA5LjIwMjUgMTQ6NDUsIERteXRy
byBQcm9rb3BjaHVrMSB3cm90ZToNCj4+Pj4gLS0tIGEvZG9jcy9taXNyYS9kZXZpYXRpb25zLnJz
dA0KPj4+PiArKysgYi9kb2NzL21pc3JhL2RldmlhdGlvbnMucnN0DQo+Pj4+IEBAIC05OCw2ICs5
OCwyMyBAQCBEZXZpYXRpb25zIHJlbGF0ZWQgdG8gTUlTUkEgQzoyMDEyIFJ1bGVzOg0KPj4+PiAg
ICAgICAgICAgZXZlbiB3aGVuIGRlYnVnLW9ubHkgYXNzZXJ0aW9ucyBsaWtlIGBBU1NFUlRfVU5S
RUFDSEFCTEUoKWAgYXJlIHJlbW92ZWQuDQo+Pj4+ICAgICAgICAgLSBFQ0xBSVIgaGFzIGJlZW4g
Y29uZmlndXJlZCB0byBpZ25vcmUgdGhvc2Ugc3RhdGVtZW50cy4NCj4+Pj4NCj4+Pj4gKyAgICog
LSBSMi4xDQo+Pj4+ICsgICAgIC0gSW4gdGhlIHNwZWNpZmljIGJ1aWxkIGNvbmZpZ3VyYXRpb24g
KHdoZW4gdGhlIGNvbmZpZyBDT05GSUdfQUNQSSBpcyBub3QNCj4+Pj4gKyAgICAgICBkZWZpbmVk
KSB0aGUgJ0JVRygpJyBtYWNybyBpcyBpbnRlbnRpb25hbGx5IHVzZWQgaW4gdGhlICdwcmVwYXJl
X2FjcGkoKScNCj4+Pj4gKyAgICAgICBmdW5jdGlvbiBpbiB0aGUgaGVhZGVyIGZpbGUgJ3hlbi9h
cmNoL2FybS9pbmNsdWRlL2FzbS9kb21haW5fYnVpbGQuaCcNCj4+Pj4gKyAgICAgICBkZWZpbmVk
IGFzICdzdGF0aWMgaW5saW5lJyB0byB0cmlnZ2VyIGEgcnVudGltZSBlcnJvciBpZiBBQ1BJLXJl
bGF0ZWQNCj4+Pj4gKyAgICAgICBmZWF0dXJlcyBhcmUgdXNlZCBpbmNvcnJlY3RseS4NCj4+Pj4g
KyAgICAgLSBUYWdnZWQgYXMgYGRlbGliZXJhdGVgIGZvciBFQ0xBSVIuDQo+Pj4NCj4+PiBJIHJl
c3BvbnNlIHRvIG1lIG91dGxpbmluZyBhIGRldmlhdGlvbi1sZXNzIGFsdGVybmF0aXZlIHlvdSB0
cmllZCBpdCBvdXQNCj4+PiBhbmQgc2FpZCBpdCB3b3Jrcy4gVGhlbiB3aHkgaXMgdGhlIGRldmlh
dGlvbiBzdGlsbCBiZWluZyBwdXQgaW4gcGxhY2U/DQo+Pg0KPj4gWWVzLCB0aGF0J3MgdHJ1ZS4N
Cj4+IEkgc3RhcnRlZCB3aXRoIHRoYXQgcHJlcGFyZV9hY3BpKCkgZnVuY3Rpb24gYW5kIEkgdHJp
ZWQgdG8gbW92ZSBpdCBpbnRvDQo+PiB4ZW4vaW5jbHVkZS94ZW4vYWNwaS5oIGhlYWRlciBmaWxl
IHVuZGVyIGFwcHJvcHJpYXRlICNpZmRlZjoNCj4+IGh0dHBzOi8vZ2l0bGFiLmNvbS94ZW4tcHJv
amVjdC9wZW9wbGUvZGltYXBya3A0ay94ZW4vLS9jb21taXQvZDE1Y2Y5MWRlOTJmMWY4ZWM2Nzkx
MWM1MWExM2U3ZjA5NWMxYmNkZA0KPg0KPiBCdXQgYW4gaW1wb3J0YW50IHBhcnQgb2YgbXkgcHJv
cG9zYWwgd2FzIHRvIGhhdmUgbm8gI2lmZGVmIGFyb3VuZA0KPiB0aGUgZGVjbGFyYXRpb24sIGlp
cmMuIFdpdGggdGhhdCwgbm8gdmlvbGF0aW9uIHNob3VsZCByZXN1bHQuDQpJIGRvbid0IHVuZGVy
c3RhbmQsIGhvdyBpdCBjYW4gaGVscCB0byBhdm9pZCBzY2FubmluZyBieSB0aGUgRWNsYWlyPw0K
SW4gcGFydGljdWxhciBidWlsZCBjb25maWd1cmF0aW9uIHRoZSAic3RhdGljIGlubGluZSIgdmVy
c2lvbiBvZiB0aGUNCmZ1bmN0aW9uIHdpbGwgYmUgcHJlc2VudCBhZnRlciBwcmVwcm9jY2Vzb3Is
IGFuZCBFY2xhaXIgd2lsbCBzY2FuIGl0Lg0KDQpKYW4sIHBsZWFzZSwgZXhwbGFpbiB5b3VyIHRo
b3VnaHQuIEkgdGhpbmssIEkgbWlzc2VkIHNvbWV0aGluZy4NCg0KPiBXaGV0aGVyIChvciB3aHkp
IG1vdmluZyB3b3VsZCBiZSByZXF1aXJlZCBJIGRvbid0IGtub3cuDQpJdCBzaG91bGRuJ3QgYmUg
bW92ZWQuIE5ldmVybWluZC4+DQo+IEphbg0KRG15dHJvLg0K


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:10:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:10:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125205.1467213 (Exim 4.92)
	(envelope-from )
	id 1uysrZ-0006cZ-P9; Wed, 17 Sep 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 1125205.1467213; Wed, 17 Sep 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 1uysrZ-0006cS-Lm; Wed, 17 Sep 2025 14:10:25 +0000
Received: by outflank-mailman (input) for mailman id 1125205;
 Wed, 17 Sep 2025 14:10: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 1uysrX-0006cM-Tg
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:10:24 +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 0a61e514-93d0-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 16:10:18 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3e98c5adbbeso2002152f8f.0
 for ; Wed, 17 Sep 2025 07:10:18 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54a3aa1c54sm16948400a12.50.2025.09.17.07.10.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 17 Sep 2025 07:10: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: 0a61e514-93d0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758118218; x=1758723018; 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=N/BX4olgEIXCsLtqILeXjW50qgehf+5wie1lr1W3osI=;
        b=MXfFpM/+CSOohGysWZI9pGV/cJDL1bV9944oe5ch/tbl+I0Qp/0TQ7S4j6UpQnfUh2
         /phyPveMKHHUacm/D9b5+h/tyIxPCcYcNogkmGQJ8xcRCcryvFYOdx4DvZ+Pdy29i5/z
         Xdaii884CwUfgkElvbBtRpq+27O+eR48HdNmyCJnR8dgjrlO/vbSzhKK/h9ciZLbWzRb
         FrsZ/5rejDjijsazfeUIQq2JPF7RaQdMElzKUnSmULp5fbYFvghoO55T61yp3PU+1wkc
         Xb526Cx35iFihJPxRX+3dcVpl7sWVYZK8EHAOV4DXFcxW+Y5igBsxE4FG9oPocSt0O50
         fePw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758118218; x=1758723018;
        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=N/BX4olgEIXCsLtqILeXjW50qgehf+5wie1lr1W3osI=;
        b=llI5JHLTXtNb67ejJm6xQFG0m5NxzLD4sUkFw4V9LN024RLIDgk1R0EpJ0uxQsGxrv
         GOac5rqkxc0UvDfUq90yXpCQe2yDRboYPgTn4Nys1FsWJaJHae1YbX8CQsprRUmKPKUl
         39pVv/q0HAvy5LcseITwGur207Smw64QIlAd4Jd8VF39kZHWEBydODD/WUD6uMnLNazW
         b6jlX/0Lf5BScgPwvJCRU5n/S5Wkk+/wiEPIwUjd2FmZtYwK2YPN5yo2waaxFBGm0Pel
         gus/DJMAzTFcIWbPtrQ2bt4bEKpN3yxO35i8TFFo4cRFxk0aAP05YfePb9HdDoOnm2Rm
         A0Rg==
X-Forwarded-Encrypted: i=1; AJvYcCXMl31lsxlYPoQdc+Fh+Y8a0vmOg+WGtN94R430jrhP2daFIWJsY74RPm5k+hcrjc7DKg04Dp/AySs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwwjB0nswN5GRL6vAz86SELc6Rw7zfha68x4j9CAzl6TYo4mls2
	QBQhPC3YnatlA7GS1sAn22KxZzZHHiRhSbyHq/lUtZvkc6WdzkuT0kwnh7HNahuIQA==
X-Gm-Gg: ASbGncs1ntHeJjzP32E5fjyjTMiRO6ZmmxSZvly7nMaGMVTyU3vyux8hNXdiR6Sbcz9
	WYeR4Z8TlZbX/Q4ghRerzSZ3KfBh0hxIBryrQ6B/88lXionAdd4IPOL3LWJ6oMwSOJslERqPq4n
	Hne0wNRRau/4IU4LY8+oieazkXD85g5VLDLl7Oq6xnIUbR+/gQaNG0W2FcqKaAQ0HVkEXRRg+VM
	u0itpaHXtNnb1vCBorc76LTeNKUyVLiDDEZOQd1k8Al3PLZV3AQk0ivMNyrtUyEwqAxoy0u8nkR
	KO23FpB8AV+/knyLEGtLqHEsHsjFhL8dl9S1tSP/k/SH+m4mMrRjloxUCBrkm9176vH6/1nA1fD
	I0+cUMGR779OViGYQXvYf7n1barb+5U4=
X-Google-Smtp-Source: AGHT+IEdIuLLanJMxKWnT+klcFEmrgjTFDfZABsFQ5u3fwzd2xSk1kktZ18knYjByxGt7Zw7j6/ekA==
X-Received: by 2002:a05:6000:4008:b0:3e2:fd26:10f0 with SMTP id ffacd0b85a97d-3ecdf9b88b6mr2164632f8f.11.1758118218004;
        Wed, 17 Sep 2025 07:10:18 -0700 (PDT)
Message-ID: 
Date: Wed, 17 Sep 2025 16:10:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domain: introduce DOMID_ANY
To: Andrew Cooper , dmukhin@xen.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, xen-devel@lists.xenproject.org
References: <20250916173702.871508-2-dmukhin@ford.com>
 <9e5c0735-1024-4d44-b1bd-1a8909ce2c37@suse.com>
 <71e80d9a-0210-490c-a3b0-6b370a18145f@xen.org>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <71e80d9a-0210-490c-a3b0-6b370a18145f@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.09.2025 22:51, Andrew Cooper wrote:
> On 16/09/2025 1:05 pm, Jan Beulich wrote:
>> On 16.09.2025 19:37, dmukhin@xen.org wrote:
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/xen.h
>>> @@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>>  /* DOMID_INVALID is used to identify pages with unknown owner. */
>>>  #define DOMID_INVALID        xen_mk_uint(0x7FF4)
>>>  
>>> +/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */
>> Considering this is an implementation detail of the hypervisor, ...
>>
>>> +#define DOMID_ANY            DOMID_INVALID
>> ... I don't think this should go in a public header.
> 
> Except we want it for the toolstack to use, as part of preventing 0
> being a magic number to XEN_DOMCTL_createdomain.

Where would the toolstack want to use it? Domain creation? And why 0
(which isn't DOMID_INVALID / DOMID_ANY)?

In any event, if exposure to the tool stack is wanted, then yes, this
wants to stay here, but guarded by a __XEN__ || __XEN_TOOLS__ check
like we do elsewhere.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:16:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:16:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125216.1467222 (Exim 4.92)
	(envelope-from )
	id 1uysxS-0007Et-Bn; Wed, 17 Sep 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 1125216.1467222; Wed, 17 Sep 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 1uysxS-0007Em-9I; Wed, 17 Sep 2025 14:16:30 +0000
Received: by outflank-mailman (input) for mailman id 1125216;
 Wed, 17 Sep 2025 14: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 1uysxR-0007Eg-9g
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:16:29 +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 e6c28c33-93d0-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:16:28 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3df15fdf0caso5380975f8f.0
 for ; Wed, 17 Sep 2025 07:16:28 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-25d49093074sm165452345ad.149.2025.09.17.07.16.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 17 Sep 2025 07:16: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: e6c28c33-93d0-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758118588; x=1758723388; 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=8/2Ux3mt+neWk7R5jMJpint+wFvErdyuY2hvaH8zDQ4=;
        b=UMg3HJcXHyZWwCEqSXcfTzM6mWTJBuUVaAo6JLX3087JKK86gf+Maln+ww8Kx+g6ei
         SMTDjPF73aEbGbhk7Gg/eDwImfR4oCbYFCNys4c4IhCBhv+ma2CqpMviVf294F6EsXoH
         HBurB7+73tSlPqZozlkEU8j5yA/KRuVUIDn8dAOaHGHcahXMcrhaYu4t7VuP3zV14M8a
         SqJhdYKX+dbyHlacDHq81oRwzDfJVmcIHkaa4WGIsk96QfA00YB7PCdGPaA7R2ZHt6je
         mPsqvQ67xWarrpfU1pMf5VaBVRtWJa0e5TUbW601h+p7N2LZ1UGDhljajQqQkJolwZqd
         ubcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758118588; x=1758723388;
        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=8/2Ux3mt+neWk7R5jMJpint+wFvErdyuY2hvaH8zDQ4=;
        b=rYltD1pJZELyi51GUTKtvFB14Xk6E/azxqHhsMUghqeXUpznGose+VtiN9YfRa+efF
         GPYIwBmP9uaItkT9TGAuUJsZE5tFHxSgpcXL3mZrkfMgc8xJ7mYREXzCxJsgQsGBqnYX
         li6rFmclGFRr9PgRoA9eWEgltQjaocFugz+XRsP2S5HWCO9jOUohfntvzdS0qTbBxuZW
         kWFlOaakGju9ZX64IvXQy8ahJH+QiRtkVdkrpKja7MOlDIHwM8uWLnGkUaKficb1Z+HM
         VKbiZwminFDGJYK6VzOZBRuGU9ZnaYbS1RDX0QiUsr8J9RWiQ/vdoV4HdvvUHck8Sg4E
         eYcg==
X-Forwarded-Encrypted: i=1; AJvYcCUmBoT1rlK5s3l50pXqbwmdVg+q1z14KfNnBnc+ekeamEBmo1/zexU/A8/XTOkFl3VTBPiaO2xHNuY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz1G8x1pDz/X5mVYFZ14biu/lGGe5bLaTHiA7pXGh8u9/lmkFaF
	uK8URVZXH422KcoP2ScnMfNNnpLydl8/6FK31nUEkS68z/uRFcHNxncEQwbzBwzkXA==
X-Gm-Gg: ASbGncs+cbwsHoOM8vM8/iozxN9pTbX7q9dboyKSbSI6cUgsac7BclvzMnevjjICARj
	T7ac+N1mXfDsRNy6nq+E2q9nDn7ZUB5uXzNHD4Rl5EuYWYFnWRCijVMuWNTFCpdwU8fqNT1gqj0
	LqWRoqfUhAMZSvjaNAWRell73D1agWBsqD6M/3e0D1wUJl7xnOXB5erWCdo9URcYkie9BKcHypm
	Pkm3SThttkdyt4Sgwa0O1CF9lzw3c8eAq1M5OG2+RxBMHVwLK7RlnynrC3bFICrQZevV6T7LSRQ
	W8CU0t8SwKdQumLq5/4MOsML+Ky75KbY36bFIkovcNUYf2cScsM2b7ELw15ME9+7K4/ev8zRTpD
	/5rEOVh4PxoLX/b0ySLEboIP2WpCmxuM=
X-Google-Smtp-Source: AGHT+IGgtr9BbvUkCmskO2aE9Zo2ZLjequgvWn0HhGfvXdTzgnywwpmH67z+DoZW7s6VLAZh4dN6kw==
X-Received: by 2002:a05:6000:2082:b0:3ea:9042:e676 with SMTP id ffacd0b85a97d-3ecdfa48003mr2368978f8f.53.1758118587685;
        Wed, 17 Sep 2025 07:16:27 -0700 (PDT)
Message-ID: <8b9d332f-e4f9-4023-b668-8a8957a45e7c@suse.com>
Date: Wed, 17 Sep 2025 16:16:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
To: Dmytro Prokopchuk1 
Cc: Nicola Vetrini ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
 
 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 15:59, Dmytro Prokopchuk1 wrote:
> 
> 
> On 9/16/25 23:03, Jan Beulich wrote:
>> On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> On 9/16/25 17:27, Jan Beulich wrote:
>>>> On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
>>>>> --- a/docs/misra/deviations.rst
>>>>> +++ b/docs/misra/deviations.rst
>>>>> @@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
>>>>>           even when debug-only assertions like `ASSERT_UNREACHABLE()` are removed.
>>>>>         - ECLAIR has been configured to ignore those statements.
>>>>>
>>>>> +   * - R2.1
>>>>> +     - In the specific build configuration (when the config CONFIG_ACPI is not
>>>>> +       defined) the 'BUG()' macro is intentionally used in the 'prepare_acpi()'
>>>>> +       function in the header file 'xen/arch/arm/include/asm/domain_build.h'
>>>>> +       defined as 'static inline' to trigger a runtime error if ACPI-related
>>>>> +       features are used incorrectly.
>>>>> +     - Tagged as `deliberate` for ECLAIR.
>>>>
>>>> I response to me outlining a deviation-less alternative you tried it out
>>>> and said it works. Then why is the deviation still being put in place?
>>>
>>> Yes, that's true.
>>> I started with that prepare_acpi() function and I tried to move it into
>>> xen/include/xen/acpi.h header file under appropriate #ifdef:
>>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/commit/d15cf91de92f1f8ec67911c51a13e7f095c1bcdd
>>
>> But an important part of my proposal was to have no #ifdef around
>> the declaration, iirc. With that, no violation should result.
> I don't understand, how it can help to avoid scanning by the Eclair?

I didn't say it would. Scanning will always happen. The question is
whether Eclair would flag anything.

> In particular build configuration the "static inline" version of the
> function will be present after preproccesor, and Eclair will scan it.
> 
> Jan, please, explain your thought. I think, I missed something.

If acpi_disabled is compile-time-constant false, all you need is a
declaration for prepare_acpi(). The call to it will then be DCE-ed.
No inline function, no #ifdef, no violation.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:23:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:23:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125228.1467233 (Exim 4.92)
	(envelope-from )
	id 1uyt3i-0000Rb-0q; Wed, 17 Sep 2025 14:22:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125228.1467233; Wed, 17 Sep 2025 14: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 1uyt3h-0000RU-UF; Wed, 17 Sep 2025 14:22:57 +0000
Received: by outflank-mailman (input) for mailman id 1125228;
 Wed, 17 Sep 2025 14: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 1uyt3g-0000RO-Ps
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:22:56 +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 cd771725-93d1-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:22:55 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3ece0e4c5faso737785f8f.1
 for ; Wed, 17 Sep 2025 07:22:55 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7760793b730sm19338127b3a.15.2025.09.17.07.22.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 17 Sep 2025 07: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: cd771725-93d1-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758118975; x=1758723775; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:cc:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=U03JiOX1pR4ni6BN6su9Z2bN0KkbdhKqHkKE9GUMhno=;
        b=KCn9KANxD3luPEMVr2iYOjE/KEdkecIWnhcGX3WeErl5PiChhTNZZsYeakAOWanPDo
         yDK6y/VTt6B4iMl4A21HcY8SXBPnNG7o6tLJMBAYF2LnHbgWxOlPLtHr/BwDWArcGqdS
         WklfaxU1IKC/OjGlhE6TJakeYYiEi0b3qsImH3uc7g+fXlX8Ke5f9K60zU/l9kx2I7OD
         gmkPzemL7aCSbKa4oKTjsniOhrhWolMzehuXISpQfkI0TbTxu86kgONKv10BovQ9hNEv
         vjy4O+NZjLzWpyHPJIoVKi+8k4y/LJhQvPHpXJNIVoXCSYKEHSwOg158NACoN0BdQVbz
         NxHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758118975; x=1758723775;
        h=content-transfer-encoding:in-reply-to: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=U03JiOX1pR4ni6BN6su9Z2bN0KkbdhKqHkKE9GUMhno=;
        b=GFevTvTH6VZ9kNy7tCzd3edKCIEIpf5osNtPi+LfgW5lX2B1KwUrcR8Ceu92vtVXB1
         20oUFGeXmr8AOJtrw2gnK7vyIeL2tarkyxBWTKtRdQIvarFoYowtgAtQM6OoDcTkOeV5
         joI80htbwacNgmRxvD+9eROvBUnAXvu1YzJFwY1f1oV6YFYs0oiowEW1i0SLjWGnqPon
         0IrNqySGLz5dIwNKAJ/zksY7IuCZDEyKoBota00HUMzsV2JZgu5fI2VhHBc1wXClv0Z9
         oy9NCDZTfrypgLhtXrxrsdviwUhNpIzEPr+nplMQ6Ju6Y5pVw5OqDX7xnWIA3UlCW4VM
         KqFg==
X-Gm-Message-State: AOJu0YztDH180uwubbum8jsL2MU22JOVFTe1tf/HoqJi7a5pTWKXjpKB
	MH6hBo9dHbGRoO3p1eimo1tkccLJrgsspPgWb3KOtyv7siI6jrcIe5EufS7UDrL7KvOUMRyAp2e
	Eie8=
X-Gm-Gg: ASbGncu6hTHtOdsFLdUeIoDEDOnbb7iu/WE2P4RIoE3zHNL9pi83z5qomcPrWyCDblR
	wO6qVqGi4uB2S+A9siEokT+ZkouVNX2fcFQKqKMU0QTeVPFhk2TauqigL7pOhGiUytglbtqFJwo
	KK9l3E9CoEVl8vIxh7xnxRjFofXtYuDHcaFWZb8GdD/JB9Qg1HIPotfYp2UW/m54SdMVuBm/2V5
	XaLMs2TEgFNCNFtL8e7RXmCuqYgmWS0y8e3sOuARCWwu0tmG8oviZRpOg9GUmvbsS0QvhPn6uJN
	d/cSsKy7dEUszJ5aQXckGJ3gplFcrD3bK2So6mZ9qBAye2AFwqNphfIB7KQ0XKp08kr6M4su6Kq
	VGBTCh3A8PWhydnNK+gxzF/sUT4h6gKI=
X-Google-Smtp-Source: AGHT+IF6amnpVsQn0Dst1pj0fA6A/2NJ+jYqmwQMPSoH17hP7L1nUUawH7VLPHVytlIxGaTbxoY4gQ==
X-Received: by 2002:a05:6000:2889:b0:3eb:d944:8888 with SMTP id ffacd0b85a97d-3ecdfa356b2mr2589572f8f.55.1758118974840;
        Wed, 17 Sep 2025 07:22:54 -0700 (PDT)
Message-ID: <110b04b1-f123-4421-9019-43713384a7b8@suse.com>
Date: Wed, 17 Sep 2025 16:22:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Summit 2025 - Design Discussion Notes - Xen ABI
To: "Alexander M. Merritt" 
References: 
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 06:49, Alexander M. Merritt wrote:
> Hi all, it was requested I send the notes I took during the design discussion on the ABI / APIs to the list.

Thanks much. We will want to try to have notes taken more systematically
today.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:52:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:52:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125245.1467244 (Exim 4.92)
	(envelope-from )
	id 1uytWH-0004jV-8Y; Wed, 17 Sep 2025 14:52:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125245.1467244; Wed, 17 Sep 2025 14: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 1uytWH-0004jO-3d; Wed, 17 Sep 2025 14:52:29 +0000
Received: by outflank-mailman (input) for mailman id 1125245;
 Wed, 17 Sep 2025 14: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 1uytWG-0004jI-4y
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:52:28 +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 ec97d14c-93d5-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:52:25 +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 55BE9206A3;
 Wed, 17 Sep 2025 14:52: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 D37E71368D;
 Wed, 17 Sep 2025 14:52:22 +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 KeoIMibLymiwEgAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:52: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: ec97d14c-93d5-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120744; 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=L6BoEVB67MQVk+5t0IisdIC5veavG4aoIDsIXi8t0tU=;
	b=RPFv+dnZnlgFjOhg/ujMRqSYaNo/zqANG7tI0s/Iw6Ip6ZBA/XIabW52qG0IdUi7rRi96h
	eDh4aOQVlKU8OtBoS71gT9KEc1Evkqdq4Qw7PtF3neBDkjsLUxCwbDNE08dJl9Tltx9S+j
	q6avLnl0p/xCt0paRdDmxUh7jQqKo9c=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=RPFv+dnZ
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120744; 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=L6BoEVB67MQVk+5t0IisdIC5veavG4aoIDsIXi8t0tU=;
	b=RPFv+dnZnlgFjOhg/ujMRqSYaNo/zqANG7tI0s/Iw6Ip6ZBA/XIabW52qG0IdUi7rRi96h
	eDh4aOQVlKU8OtBoS71gT9KEc1Evkqdq4Qw7PtF3neBDkjsLUxCwbDNE08dJl9Tltx9S+j
	q6avLnl0p/xCt0paRdDmxUh7jQqKo9c=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	loongarch@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kvm@vger.kernel.org
Cc: Juergen Gross ,
	Andy Lutomirski ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Peter Zijlstra ,
	Will Deacon ,
	Boqun Feng ,
	Waiman Long ,
	Jiri Kosina ,
	Josh Poimboeuf ,
	Pawan Gupta ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Russell King ,
	Catalin Marinas ,
	Huacai Chen ,
	WANG Xuerui ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Alexandre Ghiti ,
	Juri Lelli ,
	Vincent Guittot ,
	Dietmar Eggemann ,
	Steven Rostedt ,
	Ben Segall ,
	Mel Gorman ,
	Valentin Schneider ,
	linux-arm-kernel@lists.infradead.org,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Daniel Lezcano ,
	Oleg Nesterov 
Subject: [PATCH v2 00/21] paravirt: cleanup and reorg
Date: Wed, 17 Sep 2025 16:51:59 +0200
Message-ID: <20250917145220.31064-1-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[suse.com,kernel.org,linutronix.de,redhat.com,alien8.de,linux.intel.com,zytor.com,microsoft.com,infradead.org,gmail.com,oracle.com,lists.xenproject.org,broadcom.com,armlinux.org.uk,arm.com,xen0n.name,linux.ibm.com,ellerman.id.au,csgroup.eu,sifive.com,dabbelt.com,eecs.berkeley.edu,ghiti.fr,linaro.org,goodmis.org,google.com,suse.de,lists.infradead.org,epam.com];
	ARC_NA(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	RCVD_TLS_ALL(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	RCPT_COUNT_GT_50(0.00)[57];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:mid,suse.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Queue-Id: 55BE9206A3
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51

Some cleanups and reorg of paravirt code and headers:

- The first 2 patches should be not controversial at all, as they
  remove just some no longer needed #include and struct forward
  declarations.

- The 3rd patch is removing CONFIG_PARAVIRT_DEBUG, which IMO has
  no real value, as it just changes a crash to a BUG() (the stack
  trace will basically be the same). As the maintainer of the main
  paravirt user (Xen) I have never seen this crash/BUG() to happen.

- The 4th patch is just a movement of code.

- I don't know for what reason asm/paravirt_api_clock.h was added,
  as all archs supporting it do it exactly in the same way. Patch
  5 is removing it.

- Patches 6-14 are streamlining the paravirt clock interfaces by
  using a common implementation across architectures where possible
  and by moving the related code into common sched code, as this is
  where it should live.

- Patches 15-20 are more like RFC material preparing the paravirt
  infrastructure to support multiple pv_ops function arrays.
  As a prerequisite for that it makes life in objtool much easier
  with dropping the Xen static initializers of the pv_ops sub-
  structures, which is done in patches 15-17.
  Patches 18-20 are doing the real preparations for multiple pv_ops
  arrays and using those arrays in multiple headers.

- Patch 21 is an example how the new scheme can look like using the
  PV-spinlocks.

Changes in V2:
- new patches 13-18 and 20
- complete rework of patch 21

Juergen Gross (21):
  x86/paravirt: Remove not needed includes of paravirt.h
  x86/paravirt: Remove some unneeded struct declarations
  x86/paravirt: Remove PARAVIRT_DEBUG config option
  x86/paravirt: Move thunk macros to paravirt_types.h
  paravirt: Remove asm/paravirt_api_clock.h
  sched: Move clock related paravirt code to kernel/sched
  arm/paravirt: Use common code for paravirt_steal_clock()
  arm64/paravirt: Use common code for paravirt_steal_clock()
  loongarch/paravirt: Use common code for paravirt_steal_clock()
  riscv/paravirt: Use common code for paravirt_steal_clock()
  x86/paravirt: Use common code for paravirt_steal_clock()
  x86/paravirt: Move paravirt_sched_clock() related code into tsc.c
  x86/paravirt: Introduce new paravirt-base.h header
  x86/paravirt: Move pv_native_*() prototypes to paravirt.c
  x86/xen: Drop xen_irq_ops
  x86/xen: Drop xen_cpu_ops
  x86/xen: Drop xen_mmu_ops
  objtool: Allow multiple pv_ops arrays
  x86/paravirt: Allow pv-calls outside paravirt.h
  x86/paravirt: Specify pv_ops array in paravirt macros
  x86/pvlocks: Move paravirt spinlock functions into own header

 arch/Kconfig                                  |   3 +
 arch/arm/Kconfig                              |   1 +
 arch/arm/include/asm/paravirt.h               |  22 --
 arch/arm/include/asm/paravirt_api_clock.h     |   1 -
 arch/arm/kernel/Makefile                      |   1 -
 arch/arm/kernel/paravirt.c                    |  23 --
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/paravirt.h             |  14 -
 arch/arm64/include/asm/paravirt_api_clock.h   |   1 -
 arch/arm64/kernel/paravirt.c                  |  11 +-
 arch/loongarch/Kconfig                        |   1 +
 arch/loongarch/include/asm/paravirt.h         |  13 -
 .../include/asm/paravirt_api_clock.h          |   1 -
 arch/loongarch/kernel/paravirt.c              |  10 +-
 arch/powerpc/include/asm/paravirt.h           |   3 -
 arch/powerpc/include/asm/paravirt_api_clock.h |   2 -
 arch/powerpc/platforms/pseries/setup.c        |   4 +-
 arch/riscv/Kconfig                            |   1 +
 arch/riscv/include/asm/paravirt.h             |  14 -
 arch/riscv/include/asm/paravirt_api_clock.h   |   1 -
 arch/riscv/kernel/paravirt.c                  |  11 +-
 arch/x86/Kconfig                              |   8 +-
 arch/x86/entry/entry_64.S                     |   1 -
 arch/x86/entry/vsyscall/vsyscall_64.c         |   1 -
 arch/x86/hyperv/hv_spinlock.c                 |  11 +-
 arch/x86/include/asm/apic.h                   |   4 -
 arch/x86/include/asm/highmem.h                |   1 -
 arch/x86/include/asm/mmu_context.h            |   1 -
 arch/x86/include/asm/mshyperv.h               |   1 -
 arch/x86/include/asm/paravirt-base.h          |  29 ++
 arch/x86/include/asm/paravirt-spinlock.h      | 146 ++++++++
 arch/x86/include/asm/paravirt.h               | 331 +++++-------------
 arch/x86/include/asm/paravirt_api_clock.h     |   1 -
 arch/x86/include/asm/paravirt_types.h         | 269 +++++++-------
 arch/x86/include/asm/pgtable_32.h             |   1 -
 arch/x86/include/asm/ptrace.h                 |   2 +-
 arch/x86/include/asm/qspinlock.h              |  89 +----
 arch/x86/include/asm/spinlock.h               |   1 -
 arch/x86/include/asm/timer.h                  |   1 +
 arch/x86/include/asm/tlbflush.h               |   4 -
 arch/x86/kernel/Makefile                      |   2 +-
 arch/x86/kernel/apm_32.c                      |   1 -
 arch/x86/kernel/callthunks.c                  |   1 -
 arch/x86/kernel/cpu/bugs.c                    |   1 -
 arch/x86/kernel/cpu/vmware.c                  |   1 +
 arch/x86/kernel/kvm.c                         |  11 +-
 arch/x86/kernel/kvmclock.c                    |   1 +
 arch/x86/kernel/paravirt-spinlocks.c          |  24 +-
 arch/x86/kernel/paravirt.c                    |  42 +--
 arch/x86/kernel/tsc.c                         |  10 +-
 arch/x86/kernel/vsmp_64.c                     |   1 -
 arch/x86/kernel/x86_init.c                    |   1 -
 arch/x86/lib/cache-smp.c                      |   1 -
 arch/x86/mm/init.c                            |   1 -
 arch/x86/xen/enlighten_pv.c                   |  82 ++---
 arch/x86/xen/irq.c                            |  20 +-
 arch/x86/xen/mmu_pv.c                         | 100 ++----
 arch/x86/xen/spinlock.c                       |  11 +-
 arch/x86/xen/time.c                           |   2 +
 drivers/clocksource/hyperv_timer.c            |   2 +
 drivers/xen/time.c                            |   2 +-
 include/linux/sched/cputime.h                 |  18 +
 kernel/sched/core.c                           |   5 +
 kernel/sched/cputime.c                        |  13 +
 kernel/sched/sched.h                          |   3 +-
 tools/objtool/arch/x86/decode.c               |   8 +-
 tools/objtool/check.c                         |  78 ++++-
 tools/objtool/include/objtool/check.h         |   2 +
 68 files changed, 657 insertions(+), 828 deletions(-)
 delete mode 100644 arch/arm/include/asm/paravirt.h
 delete mode 100644 arch/arm/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/arm/kernel/paravirt.c
 delete mode 100644 arch/arm64/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/loongarch/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/powerpc/include/asm/paravirt_api_clock.h
 delete mode 100644 arch/riscv/include/asm/paravirt_api_clock.h
 create mode 100644 arch/x86/include/asm/paravirt-base.h
 create mode 100644 arch/x86/include/asm/paravirt-spinlock.h
 delete mode 100644 arch/x86/include/asm/paravirt_api_clock.h

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:52:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:52:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125246.1467253 (Exim 4.92)
	(envelope-from )
	id 1uytWN-0004yU-HS; Wed, 17 Sep 2025 14:52:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125246.1467253; Wed, 17 Sep 2025 14:52:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uytWN-0004yL-De; Wed, 17 Sep 2025 14:52:35 +0000
Received: by outflank-mailman (input) for mailman id 1125246;
 Wed, 17 Sep 2025 14:52:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uytWM-0004xi-0P
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:52:34 +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 f0064907-93d5-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 16:52:31 +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 7F097228CA;
 Wed, 17 Sep 2025 14:52: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 BEE021368D;
 Wed, 17 Sep 2025 14:52: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 83fyLC3Lymi/EgAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:52: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: f0064907-93d5-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120750; 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=Lnxctw4TkqNTc4ChtuCQgho9vGAJsGLt5RRgPYgHX4k=;
	b=uZ18W80B+W3BVzorEzzeTfLdkBOVkMzqlN7fThzkWL+TxyaFP/9Nz3hsOlVdZ29qrfjYsX
	rA2QE8GVWlAPvzxaexHjLxN404ysPyizlIj40Usp9tYaLoN3GtuHFTUFf022powaBhDjQJ
	XrrimtZFI6o6tiKY0C7TGMBQRAo0vAY=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=uZ18W80B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120750; 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=Lnxctw4TkqNTc4ChtuCQgho9vGAJsGLt5RRgPYgHX4k=;
	b=uZ18W80B+W3BVzorEzzeTfLdkBOVkMzqlN7fThzkWL+TxyaFP/9Nz3hsOlVdZ29qrfjYsX
	rA2QE8GVWlAPvzxaexHjLxN404ysPyizlIj40Usp9tYaLoN3GtuHFTUFf022powaBhDjQJ
	XrrimtZFI6o6tiKY0C7TGMBQRAo0vAY=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org
Cc: Juergen Gross ,
	Andy Lutomirski ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Peter Zijlstra ,
	Will Deacon ,
	Boqun Feng ,
	Waiman Long ,
	Jiri Kosina ,
	Josh Poimboeuf ,
	Pawan Gupta ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 01/21] x86/paravirt: Remove not needed includes of paravirt.h
Date: Wed, 17 Sep 2025 16:52:00 +0200
Message-ID: <20250917145220.31064-2-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:mid,suse.com:dkim,suse.com:email];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[suse.com,kernel.org,linutronix.de,redhat.com,alien8.de,linux.intel.com,zytor.com,microsoft.com,infradead.org,gmail.com,oracle.com,lists.xenproject.org];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Queue-Id: 7F097228CA
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51

In some places asm/paravirt.h is included without really being needed.

Remove the related #include statements.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/x86/entry/entry_64.S             | 1 -
 arch/x86/entry/vsyscall/vsyscall_64.c | 1 -
 arch/x86/hyperv/hv_spinlock.c         | 1 -
 arch/x86/include/asm/apic.h           | 4 ----
 arch/x86/include/asm/highmem.h        | 1 -
 arch/x86/include/asm/mmu_context.h    | 1 -
 arch/x86/include/asm/mshyperv.h       | 1 -
 arch/x86/include/asm/pgtable_32.h     | 1 -
 arch/x86/include/asm/spinlock.h       | 1 -
 arch/x86/include/asm/tlbflush.h       | 4 ----
 arch/x86/kernel/apm_32.c              | 1 -
 arch/x86/kernel/callthunks.c          | 1 -
 arch/x86/kernel/cpu/bugs.c            | 1 -
 arch/x86/kernel/vsmp_64.c             | 1 -
 arch/x86/kernel/x86_init.c            | 1 -
 arch/x86/lib/cache-smp.c              | 1 -
 arch/x86/mm/init.c                    | 1 -
 arch/x86/xen/spinlock.c               | 1 -
 18 files changed, 24 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ed04a968cc7d..7a82305405af 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index c9103a6fa06e..53e50b506471 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define CREATE_TRACE_POINTS
 #include "vsyscall_trace.h"
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 81b006601370..2a3c2afb0154 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -13,7 +13,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 07ba4935e873..e1de090e51dd 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -90,10 +90,6 @@ static inline bool apic_from_smp_config(void)
 /*
  * Basic functions accessing APICs.
  */
-#ifdef CONFIG_PARAVIRT
-#include 
-#endif
-
 static inline void native_apic_mem_write(u32 reg, u32 v)
 {
 	volatile u32 *addr = (volatile u32 *)(APIC_BASE + reg);
diff --git a/arch/x86/include/asm/highmem.h b/arch/x86/include/asm/highmem.h
index 585bdadba47d..decfaaf52326 100644
--- a/arch/x86/include/asm/highmem.h
+++ b/arch/x86/include/asm/highmem.h
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 73bf3b1b44e8..ee15657d25b3 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -9,7 +9,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index abc4659f5809..a9ab46fcb6a1 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/include/asm/pgtable_32.h b/arch/x86/include/asm/pgtable_32.h
index b612cc57a4d3..acea0cfa2460 100644
--- a/arch/x86/include/asm/pgtable_32.h
+++ b/arch/x86/include/asm/pgtable_32.h
@@ -16,7 +16,6 @@
 #ifndef __ASSEMBLER__
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 5b6bc7016c22..934632b78d09 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 00daedfefc1b..238a6b807da5 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -300,10 +300,6 @@ static inline void mm_clear_asid_transition(struct mm_struct *mm) { }
 static inline bool mm_in_asid_transition(struct mm_struct *mm) { return false; }
 #endif /* CONFIG_BROADCAST_TLB_FLUSH */
 
-#ifdef CONFIG_PARAVIRT
-#include 
-#endif
-
 #define flush_tlb_mm(mm)						\
 		flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL, true)
 
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index b37ab1095707..3175d7c134e9 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -229,7 +229,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/callthunks.c b/arch/x86/kernel/callthunks.c
index a951333c5995..e37728f70322 100644
--- a/arch/x86/kernel/callthunks.c
+++ b/arch/x86/kernel/callthunks.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 36dcfc5105be..d278d37c9690 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 73511332bb67..25625e3fc183 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define TOPOLOGY_REGISTER_OFFSET 0x10
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 0a2bbd674a6d..02ca90378bf9 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -12,7 +12,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/cache-smp.c b/arch/x86/lib/cache-smp.c
index c5c60d07308c..ae5a5dfd33c7 100644
--- a/arch/x86/lib/cache-smp.c
+++ b/arch/x86/lib/cache-smp.c
@@ -1,5 +1,4 @@
 // SPDX-License-Identifier: GPL-2.0
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index bb57e93b4caf..f52ebcac50d9 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 8e4efe0fb6f9..fe56646d6919 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:53:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:53:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125261.1467263 (Exim 4.92)
	(envelope-from )
	id 1uytWq-0005gb-OR; Wed, 17 Sep 2025 14:53:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125261.1467263; Wed, 17 Sep 2025 14:53: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 1uytWq-0005gU-LT; Wed, 17 Sep 2025 14:53:04 +0000
Received: by outflank-mailman (input) for mailman id 1125261;
 Wed, 17 Sep 2025 14:53: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 1uytWp-0004xi-Hh
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:53:03 +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 01f86ab6-93d6-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 16:53:01 +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 39702206DF;
 Wed, 17 Sep 2025 14:53:01 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 030AF1368D;
 Wed, 17 Sep 2025 14:52:59 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id CRHEOkvLymgAEwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:52:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01f86ab6-93d6-11f0-9809-7dc792cee155
Authentication-Results: smtp-out2.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	loongarch@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kvm@vger.kernel.org
Cc: Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Russell King ,
	Catalin Marinas ,
	Will Deacon ,
	Huacai Chen ,
	WANG Xuerui ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Alexandre Ghiti ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Peter Zijlstra ,
	Juri Lelli ,
	Vincent Guittot ,
	Dietmar Eggemann ,
	Steven Rostedt ,
	Ben Segall ,
	Mel Gorman ,
	Valentin Schneider ,
	linux-arm-kernel@lists.infradead.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 06/21] sched: Move clock related paravirt code to kernel/sched
Date: Wed, 17 Sep 2025 16:52:05 +0200
Message-ID: <20250917145220.31064-7-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-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-Action: no action
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]
X-Rspamd-Queue-Id: 39702206DF
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spam-Score: -4.00

Paravirt clock related functions are available in multiple archs.

In order to share the common parts, move the common static keys
to kernel/sched/ and remove them from the arch specific files.

Make a common paravirt_steal_clock() implementation available in
kernel/sched/cputime.c, guarding it with a new config option
CONFIG_HAVE_PV_STEAL_CLOCK_GEN, which can be selected by an arch
in case it wants to use that common variant.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/Kconfig                           |  3 +++
 arch/arm/include/asm/paravirt.h        |  4 ----
 arch/arm/kernel/paravirt.c             |  3 ---
 arch/arm64/include/asm/paravirt.h      |  4 ----
 arch/arm64/kernel/paravirt.c           |  4 +---
 arch/loongarch/include/asm/paravirt.h  |  3 ---
 arch/loongarch/kernel/paravirt.c       |  3 +--
 arch/powerpc/include/asm/paravirt.h    |  3 ---
 arch/powerpc/platforms/pseries/setup.c |  4 +---
 arch/riscv/include/asm/paravirt.h      |  4 ----
 arch/riscv/kernel/paravirt.c           |  4 +---
 arch/x86/include/asm/paravirt.h        |  4 ----
 arch/x86/kernel/cpu/vmware.c           |  1 +
 arch/x86/kernel/kvm.c                  |  1 +
 arch/x86/kernel/paravirt.c             |  3 ---
 drivers/xen/time.c                     |  1 +
 include/linux/sched/cputime.h          | 18 ++++++++++++++++++
 kernel/sched/core.c                    |  5 +++++
 kernel/sched/cputime.c                 | 13 +++++++++++++
 kernel/sched/sched.h                   |  2 +-
 20 files changed, 47 insertions(+), 40 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index d1b4ffd6e085..7921be052472 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1003,6 +1003,9 @@ config HAVE_IRQ_TIME_ACCOUNTING
 	  Archs need to ensure they use a high enough resolution clock to
 	  support irq time accounting and then call enable_sched_clock_irqtime().
 
+config HAVE_PV_STEAL_CLOCK_GEN
+	bool
+
 config HAVE_MOVE_PUD
 	bool
 	help
diff --git a/arch/arm/include/asm/paravirt.h b/arch/arm/include/asm/paravirt.h
index 95d5b0d625cd..69da4bdcf856 100644
--- a/arch/arm/include/asm/paravirt.h
+++ b/arch/arm/include/asm/paravirt.h
@@ -5,10 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 #include 
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 dummy_steal_clock(int cpu);
 
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
index 7dd9806369fb..3895a5578852 100644
--- a/arch/arm/kernel/paravirt.c
+++ b/arch/arm/kernel/paravirt.c
@@ -12,9 +12,6 @@
 #include 
 #include 
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/arch/arm64/include/asm/paravirt.h b/arch/arm64/include/asm/paravirt.h
index 9aa193e0e8f2..c9f7590baacb 100644
--- a/arch/arm64/include/asm/paravirt.h
+++ b/arch/arm64/include/asm/paravirt.h
@@ -5,10 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 #include 
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 dummy_steal_clock(int cpu);
 
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
index aa718d6a9274..943b60ce12f4 100644
--- a/arch/arm64/kernel/paravirt.c
+++ b/arch/arm64/kernel/paravirt.c
@@ -19,14 +19,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/arch/loongarch/include/asm/paravirt.h b/arch/loongarch/include/asm/paravirt.h
index 3f4323603e6a..d219ea0d98ac 100644
--- a/arch/loongarch/include/asm/paravirt.h
+++ b/arch/loongarch/include/asm/paravirt.h
@@ -5,9 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 
 #include 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
 
 u64 dummy_steal_clock(int cpu);
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/loongarch/kernel/paravirt.c b/arch/loongarch/kernel/paravirt.c
index b1b51f920b23..8caaa94fed1a 100644
--- a/arch/loongarch/kernel/paravirt.c
+++ b/arch/loongarch/kernel/paravirt.c
@@ -6,11 +6,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int has_steal_clock;
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
 static DEFINE_PER_CPU(struct kvm_steal_time, steal_time) __aligned(64);
 DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
 
diff --git a/arch/powerpc/include/asm/paravirt.h b/arch/powerpc/include/asm/paravirt.h
index b78b82d66057..92343a23ad15 100644
--- a/arch/powerpc/include/asm/paravirt.h
+++ b/arch/powerpc/include/asm/paravirt.h
@@ -23,9 +23,6 @@ static inline bool is_shared_processor(void)
 }
 
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 pseries_paravirt_steal_clock(int cpu);
 
 static inline u64 paravirt_steal_clock(int cpu)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index b10a25325238..50b26ed8432d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -83,9 +84,6 @@ DEFINE_STATIC_KEY_FALSE(shared_processor);
 EXPORT_SYMBOL(shared_processor);
 
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static bool steal_acc = true;
 static int __init parse_no_stealacc(char *arg)
 {
diff --git a/arch/riscv/include/asm/paravirt.h b/arch/riscv/include/asm/paravirt.h
index c0abde70fc2c..17e5e39c72c0 100644
--- a/arch/riscv/include/asm/paravirt.h
+++ b/arch/riscv/include/asm/paravirt.h
@@ -5,10 +5,6 @@
 #ifdef CONFIG_PARAVIRT
 #include 
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 u64 dummy_steal_clock(int cpu);
 
 DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
diff --git a/arch/riscv/kernel/paravirt.c b/arch/riscv/kernel/paravirt.c
index fa6b0339a65d..d3c334f16172 100644
--- a/arch/riscv/kernel/paravirt.c
+++ b/arch/riscv/kernel/paravirt.c
@@ -16,15 +16,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 1344d2fb2b86..0ef797ea8440 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -30,10 +30,6 @@ static __always_inline u64 paravirt_sched_clock(void)
 	return static_call(pv_sched_clock)();
 }
 
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
 __visible void __native_queued_spin_unlock(struct qspinlock *lock);
 bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index cb3f900c46fc..a3e6936839b1 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8ae750cde0c6..a23211eaaeed 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.c b/arch/x86/kernel/paravirt.c
index ab3e172dcc69..a3ba4747be1c 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -60,9 +60,6 @@ void __init native_pv_lock_init(void)
 		static_branch_enable(&virt_spin_lock_key);
 }
 
-struct static_key paravirt_steal_enabled;
-struct static_key paravirt_steal_rq_enabled;
-
 static u64 native_steal_clock(int cpu)
 {
 	return 0;
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 5683383d2305..d360ded2ef39 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/include/linux/sched/cputime.h b/include/linux/sched/cputime.h
index 5f8fd5b24a2e..e90efaf6d26e 100644
--- a/include/linux/sched/cputime.h
+++ b/include/linux/sched/cputime.h
@@ -2,6 +2,7 @@
 #ifndef _LINUX_SCHED_CPUTIME_H
 #define _LINUX_SCHED_CPUTIME_H
 
+#include 
 #include 
 
 /*
@@ -180,4 +181,21 @@ static inline void prev_cputime_init(struct prev_cputime *prev)
 extern unsigned long long
 task_sched_runtime(struct task_struct *task);
 
+#ifdef CONFIG_PARAVIRT
+struct static_key;
+extern struct static_key paravirt_steal_enabled;
+extern struct static_key paravirt_steal_rq_enabled;
+
+#ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
+u64 dummy_steal_clock(int cpu);
+
+DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
+
+static inline u64 paravirt_steal_clock(int cpu)
+{
+	return static_call(pv_steal_clock)(cpu);
+}
+#endif
+#endif
+
 #endif /* _LINUX_SCHED_CPUTIME_H */
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index be00629f0ba4..e723226e4e11 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -767,6 +767,11 @@ struct rq *task_rq_lock(struct task_struct *p, struct rq_flags *rf)
  * RQ-clock updating methods:
  */
 
+/* Use CONFIG_PARAVIRT as this will avoid more #ifdef in arch code. */
+#ifdef CONFIG_PARAVIRT
+struct static_key paravirt_steal_rq_enabled;
+#endif
+
 static void update_rq_clock_task(struct rq *rq, s64 delta)
 {
 /*
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 7097de2c8cda..ed8f71e08047 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -251,6 +251,19 @@ void __account_forceidle_time(struct task_struct *p, u64 delta)
  * ticks are not redelivered later. Due to that, this function may on
  * occasion account more time than the calling functions think elapsed.
  */
+#ifdef CONFIG_PARAVIRT
+struct static_key paravirt_steal_enabled;
+
+#ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
+static u64 native_steal_clock(int cpu)
+{
+	return 0;
+}
+
+DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+#endif
+#endif
+
 static __always_inline u64 steal_account_process_time(u64 maxtime)
 {
 #ifdef CONFIG_PARAVIRT
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 6442441b46d7..fdf3021bdf7d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -82,7 +82,7 @@ struct rt_rq;
 struct sched_group;
 struct cpuidle_state;
 
-#ifdef CONFIG_PARAVIRT
+#if defined(CONFIG_PARAVIRT) && !defined(CONFIG_HAVE_PV_STEAL_CLOCK_GEN)
 # include 
 #endif
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:53:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:53:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125267.1467273 (Exim 4.92)
	(envelope-from )
	id 1uytWw-0005yN-Vj; Wed, 17 Sep 2025 14:53:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125267.1467273; Wed, 17 Sep 2025 14: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 1uytWw-0005yG-T6; Wed, 17 Sep 2025 14:53:10 +0000
Received: by outflank-mailman (input) for mailman id 1125267;
 Wed, 17 Sep 2025 14:53: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 1uytWv-0004xi-2x
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:53:09 +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 05814902-93d6-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 16:53: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 0728E33833;
 Wed, 17 Sep 2025 14:53: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 9CF991368D;
 Wed, 17 Sep 2025 14:53: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 /8zUJFLLymgbEwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:53: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: 05814902-93d6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120787; 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=CqneFVXXIihK/cVOgMtk2arFvsOlazBtH0foGD0C9bU=;
	b=oUQz6O6EV51Jq/gWYRMorwIox2GETSg1CIbqsPIlwrmki8/cZeuszbk8hXfgdnXaJJN23x
	rJPR2By3XCpNT8fnDd+W/uFILyOnkssjb2JYBIhjMgQkl79qXC22gFcZ8QTzw0BJmG364q
	h1OyVgiWT+hN4EPy2E69FZ6pkN8Rvqc=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120787; 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=CqneFVXXIihK/cVOgMtk2arFvsOlazBtH0foGD0C9bU=;
	b=oUQz6O6EV51Jq/gWYRMorwIox2GETSg1CIbqsPIlwrmki8/cZeuszbk8hXfgdnXaJJN23x
	rJPR2By3XCpNT8fnDd+W/uFILyOnkssjb2JYBIhjMgQkl79qXC22gFcZ8QTzw0BJmG364q
	h1OyVgiWT+hN4EPy2E69FZ6pkN8Rvqc=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	virtualization@lists.linux.dev,
	x86@kernel.org
Cc: Juergen Gross ,
	Russell King ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	linux-arm-kernel@lists.infradead.org,
	xen-devel@lists.xenproject.org,
	"Peter Zijlstra (Intel)" 
Subject: [PATCH v2 07/21] arm/paravirt: Use common code for paravirt_steal_clock()
Date: Wed, 17 Sep 2025 16:52:06 +0200
Message-ID: <20250917145220.31064-8-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-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];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[13];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -6.80

Remove the arch specific variant of paravirt_steal_clock() and use
the common one instead.

This allows to remove paravirt.c and paravirt.h from arch/arm.

Until all archs supporting Xen have been switched to the common code
of paravirt_steal_clock(), drivers/xen/time.c needs to include
asm/paravirt.h for those archs, while this is not necessary for arm
any longer.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/arm/Kconfig                |  1 +
 arch/arm/include/asm/paravirt.h | 18 ------------------
 arch/arm/kernel/Makefile        |  1 -
 arch/arm/kernel/paravirt.c      | 20 --------------------
 drivers/xen/time.c              |  2 ++
 5 files changed, 3 insertions(+), 39 deletions(-)
 delete mode 100644 arch/arm/include/asm/paravirt.h
 delete mode 100644 arch/arm/kernel/paravirt.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b1f3df39ed40..48c3a36a63f8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1338,6 +1338,7 @@ config UACCESS_WITH_MEMCPY
 
 config PARAVIRT
 	bool "Enable paravirtualization code"
+	select HAVE_PV_STEAL_CLOCK_GEN
 	help
 	  This changes the kernel so it can modify itself when it is run
 	  under a hypervisor, potentially improving performance significantly
diff --git a/arch/arm/include/asm/paravirt.h b/arch/arm/include/asm/paravirt.h
deleted file mode 100644
index 69da4bdcf856..000000000000
--- a/arch/arm/include/asm/paravirt.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM_PARAVIRT_H
-#define _ASM_ARM_PARAVIRT_H
-
-#ifdef CONFIG_PARAVIRT
-#include 
-
-u64 dummy_steal_clock(int cpu);
-
-DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
-
-static inline u64 paravirt_steal_clock(int cpu)
-{
-	return static_call(pv_steal_clock)(cpu);
-}
-#endif
-
-#endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index afc9de7ef9a1..b36cf0cfd4a7 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -83,7 +83,6 @@ AFLAGS_iwmmxt.o			:= -Wa,-mcpu=iwmmxt
 obj-$(CONFIG_ARM_CPU_TOPOLOGY)  += topology.o
 obj-$(CONFIG_VDSO)		+= vdso.o
 obj-$(CONFIG_EFI)		+= efi.o
-obj-$(CONFIG_PARAVIRT)	+= paravirt.o
 
 obj-y			+= head$(MMUEXT).o
 obj-$(CONFIG_DEBUG_LL)	+= debug.o
diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
deleted file mode 100644
index 3895a5578852..000000000000
--- a/arch/arm/kernel/paravirt.c
+++ /dev/null
@@ -1,20 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- *
- * Copyright (C) 2013 Citrix Systems
- *
- * Author: Stefano Stabellini 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static u64 native_steal_clock(int cpu)
-{
-	return 0;
-}
-
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index d360ded2ef39..53b12f5ac465 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -10,7 +10,9 @@
 #include 
 #include 
 
+#ifndef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
 #include 
+#endif
 #include 
 #include 
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:53:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:53:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125283.1467282 (Exim 4.92)
	(envelope-from )
	id 1uytXP-0006iL-BK; Wed, 17 Sep 2025 14:53:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125283.1467282; Wed, 17 Sep 2025 14: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 1uytXP-0006iE-8r; Wed, 17 Sep 2025 14:53:39 +0000
Received: by outflank-mailman (input) for mailman id 1125283;
 Wed, 17 Sep 2025 14:53: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 1uytXO-0004jI-AA
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:53:38 +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 1733c5c7-93d6-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:53: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 B86E520725;
 Wed, 17 Sep 2025 14:53: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 065F21368D;
 Wed, 17 Sep 2025 14:53: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 ykCaOm/LymhREwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:53:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1733c5c7-93d6-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120816; 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=gztxpq9DX+nPOLwjlXTO5zTcC6KXOoTlESO5Ptm2kQY=;
	b=DjHHRNFlyxPa5V7hkd/f7bmc7195g1GjRLuYDDswEVlLP5Nx1z73ZQygsSLzkDHTWbSgZN
	PgiZRfmQBbt5R6HSFhFXCmsudbl2C/uhCuhWpJiA/KitXqfOAS4RSLKiti3aiqhZoKgpZF
	2jhCs/l+46nohVfezAUN3NsLp8Pd2q8=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120816; 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=gztxpq9DX+nPOLwjlXTO5zTcC6KXOoTlESO5Ptm2kQY=;
	b=DjHHRNFlyxPa5V7hkd/f7bmc7195g1GjRLuYDDswEVlLP5Nx1z73ZQygsSLzkDHTWbSgZN
	PgiZRfmQBbt5R6HSFhFXCmsudbl2C/uhCuhWpJiA/KitXqfOAS4RSLKiti3aiqhZoKgpZF
	2jhCs/l+46nohVfezAUN3NsLp8Pd2q8=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	linux-hyperv@vger.kernel.org
Cc: Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Daniel Lezcano ,
	xen-devel@lists.xenproject.org,
	"Peter Zijlstra (Intel)" 
Subject: [PATCH v2 12/21] x86/paravirt: Move paravirt_sched_clock() related code into tsc.c
Date: Wed, 17 Sep 2025 16:52:11 +0200
Message-ID: <20250917145220.31064-13-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[24];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -6.80

The only user of paravirt_sched_clock() is in tsc.c, so move the code
from paravirt.c and paravirt.h to tsc.c.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/paravirt.h    | 12 ------------
 arch/x86/include/asm/timer.h       |  1 +
 arch/x86/kernel/kvmclock.c         |  1 +
 arch/x86/kernel/paravirt.c         |  7 -------
 arch/x86/kernel/tsc.c              | 10 +++++++++-
 arch/x86/xen/time.c                |  1 +
 drivers/clocksource/hyperv_timer.c |  2 ++
 7 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 766a7cee3d64..b69e75a5c872 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -14,20 +14,8 @@
 #ifndef __ASSEMBLER__
 #include 
 #include 
-#include 
 #include 
 
-u64 dummy_sched_clock(void);
-
-DECLARE_STATIC_CALL(pv_sched_clock, dummy_sched_clock);
-
-void paravirt_set_sched_clock(u64 (*func)(void));
-
-static __always_inline u64 paravirt_sched_clock(void)
-{
-	return static_call(pv_sched_clock)();
-}
-
 __visible void __native_queued_spin_unlock(struct qspinlock *lock);
 bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index 23baf8c9b34c..fda18bcb19b4 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -12,6 +12,7 @@ extern void recalibrate_cpu_khz(void);
 extern int no_timer_check;
 
 extern bool using_native_sched_clock(void);
+void paravirt_set_sched_clock(u64 (*func)(void));
 
 /*
  * We use the full linear equation: f(x) = a + b*x, in order to allow
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ca0a49eeac4a..b5991d53fc0e 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 42991d471bf3..4e37db8073f9 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -60,13 +60,6 @@ void __init native_pv_lock_init(void)
 		static_branch_enable(&virt_spin_lock_key);
 }
 
-DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
-
-void paravirt_set_sched_clock(u64 (*func)(void))
-{
-	static_call_update(pv_sched_clock, func);
-}
-
 static noinstr void pv_native_safe_halt(void)
 {
 	native_safe_halt();
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 87e749106dda..554b54783a04 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -266,19 +266,27 @@ u64 native_sched_clock_from_tsc(u64 tsc)
 /* We need to define a real function for sched_clock, to override the
    weak default version */
 #ifdef CONFIG_PARAVIRT
+DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
+
 noinstr u64 sched_clock_noinstr(void)
 {
-	return paravirt_sched_clock();
+	return static_call(pv_sched_clock)();
 }
 
 bool using_native_sched_clock(void)
 {
 	return static_call_query(pv_sched_clock) == native_sched_clock;
 }
+
+void paravirt_set_sched_clock(u64 (*func)(void))
+{
+	static_call_update(pv_sched_clock, func);
+}
 #else
 u64 sched_clock_noinstr(void) __attribute__((alias("native_sched_clock")));
 
 bool using_native_sched_clock(void) { return true; }
+void paravirt_set_sched_clock(u64 (*func)(void)) { }
 #endif
 
 notrace u64 sched_clock(void)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index e4754b2fa900..6f9f665bb7ae 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index 2edc13ca184e..6397a7ba4a98 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -535,6 +535,8 @@ static __always_inline void hv_setup_sched_clock(void *sched_clock)
 	sched_clock_register(sched_clock, 64, NSEC_PER_SEC);
 }
 #elif defined CONFIG_PARAVIRT
+#include 
+
 static __always_inline void hv_setup_sched_clock(void *sched_clock)
 {
 	/* We're on x86/x64 *and* using PV ops */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:56:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125295.1467293 (Exim 4.92)
	(envelope-from )
	id 1uytZn-0007Rl-Od; Wed, 17 Sep 2025 14:56:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125295.1467293; Wed, 17 Sep 2025 14:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uytZn-0007Re-LV; Wed, 17 Sep 2025 14:56:07 +0000
Received: by outflank-mailman (input) for mailman id 1125295;
 Wed, 17 Sep 2025 14: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 1uytXI-0004xi-BL
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:53:32 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13671236-93d6-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 16:53:30 +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 8727433842;
 Wed, 17 Sep 2025 14:53: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 1256C1368D;
 Wed, 17 Sep 2025 14:53: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 FWccA2rLymg7EwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:53: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: 13671236-93d6-11f0-9809-7dc792cee155
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev
Cc: Juergen Gross ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Boris Ostrovsky ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	xen-devel@lists.xenproject.org,
	"Peter Zijlstra (Intel)" 
Subject: [PATCH v2 11/21] x86/paravirt: Use common code for paravirt_steal_clock()
Date: Wed, 17 Sep 2025 16:52:10 +0200
Message-ID: <20250917145220.31064-12-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-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-Spam-Level: 
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]
X-Rspamd-Queue-Id: 8727433842
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Flag: NO
X-Spam-Score: -4.00

Remove the arch specific variant of paravirt_steal_clock() and use
the common one instead.

With all archs supporting Xen now having been switched to the common
variant, including paravirt.h can be dropped from drivers/xen/time.c.

Signed-off-by: Juergen Gross 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/x86/Kconfig                | 1 +
 arch/x86/include/asm/paravirt.h | 7 -------
 arch/x86/kernel/paravirt.c      | 6 ------
 arch/x86/xen/time.c             | 1 +
 drivers/xen/time.c              | 3 ---
 5 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 023963a597d9..5e9c7458ac50 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -784,6 +784,7 @@ if HYPERVISOR_GUEST
 config PARAVIRT
 	bool "Enable paravirtualization code"
 	depends on HAVE_STATIC_CALL
+	select HAVE_PV_STEAL_CLOCK_GEN
 	help
 	  This changes the kernel so it can modify itself when it is run
 	  under a hypervisor, potentially improving performance significantly
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 0ef797ea8440..766a7cee3d64 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -17,10 +17,8 @@
 #include 
 #include 
 
-u64 dummy_steal_clock(int cpu);
 u64 dummy_sched_clock(void);
 
-DECLARE_STATIC_CALL(pv_steal_clock, dummy_steal_clock);
 DECLARE_STATIC_CALL(pv_sched_clock, dummy_sched_clock);
 
 void paravirt_set_sched_clock(u64 (*func)(void));
@@ -35,11 +33,6 @@ bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
 bool pv_is_native_vcpu_is_preempted(void);
 
-static inline u64 paravirt_steal_clock(int cpu)
-{
-	return static_call(pv_steal_clock)(cpu);
-}
-
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 void __init paravirt_set_cap(void);
 #endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index a3ba4747be1c..42991d471bf3 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -60,12 +60,6 @@ void __init native_pv_lock_init(void)
 		static_branch_enable(&virt_spin_lock_key);
 }
 
-static u64 native_steal_clock(int cpu)
-{
-	return 0;
-}
-
-DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
 DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
 
 void paravirt_set_sched_clock(u64 (*func)(void))
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 96521b1874ac..e4754b2fa900 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 53b12f5ac465..0b18d8a5a2dd 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -10,9 +10,6 @@
 #include 
 #include 
 
-#ifndef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
-#include 
-#endif
 #include 
 #include 
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:56:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:56:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125296.1467302 (Exim 4.92)
	(envelope-from )
	id 1uytZu-0007ly-0t; Wed, 17 Sep 2025 14:56:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125296.1467302; Wed, 17 Sep 2025 14:56: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 1uytZt-0007lp-TG; Wed, 17 Sep 2025 14:56:13 +0000
Received: by outflank-mailman (input) for mailman id 1125296;
 Wed, 17 Sep 2025 14:56: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 1uytXr-0004jI-ES
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:54:07 +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 28c92b55-93d6-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:54:06 +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 6AA9A219ED;
 Wed, 17 Sep 2025 14:54: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 06F581368D;
 Wed, 17 Sep 2025 14:54:05 +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 5FO2K43LymiBEwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:54:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28c92b55-93d6-11f0-9d13-b5c5bf9af7f9
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross ,
	Boris Ostrovsky ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Josh Poimboeuf ,
	Peter Zijlstra ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 17/21] x86/xen: Drop xen_mmu_ops
Date: Wed, 17 Sep 2025 16:52:16 +0200
Message-ID: <20250917145220.31064-18-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-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-Action: no action
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]
X-Rspamd-Queue-Id: 6AA9A219ED
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spam-Score: -4.00

Instead of having a pre-filled array xen_mmu_ops for Xen PV paravirt
functions, drop the array and assign each element individually.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 arch/x86/xen/mmu_pv.c | 100 ++++++++++++++++--------------------------
 tools/objtool/check.c |   1 -
 2 files changed, 38 insertions(+), 63 deletions(-)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2a4a8deaf612..9fa00c4a8858 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2175,73 +2175,49 @@ static void xen_leave_lazy_mmu(void)
 	preempt_enable();
 }
 
-static const typeof(pv_ops) xen_mmu_ops __initconst = {
-	.mmu = {
-		.read_cr2 = __PV_IS_CALLEE_SAVE(xen_read_cr2),
-		.write_cr2 = xen_write_cr2,
-
-		.read_cr3 = xen_read_cr3,
-		.write_cr3 = xen_write_cr3_init,
-
-		.flush_tlb_user = xen_flush_tlb,
-		.flush_tlb_kernel = xen_flush_tlb,
-		.flush_tlb_one_user = xen_flush_tlb_one_user,
-		.flush_tlb_multi = xen_flush_tlb_multi,
-
-		.pgd_alloc = xen_pgd_alloc,
-		.pgd_free = xen_pgd_free,
-
-		.alloc_pte = xen_alloc_pte_init,
-		.release_pte = xen_release_pte_init,
-		.alloc_pmd = xen_alloc_pmd_init,
-		.release_pmd = xen_release_pmd_init,
-
-		.set_pte = xen_set_pte_init,
-		.set_pmd = xen_set_pmd_hyper,
-
-		.ptep_modify_prot_start = xen_ptep_modify_prot_start,
-		.ptep_modify_prot_commit = xen_ptep_modify_prot_commit,
-
-		.pte_val = PV_CALLEE_SAVE(xen_pte_val),
-		.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
-
-		.make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
-		.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
-
-		.set_pud = xen_set_pud_hyper,
-
-		.make_pmd = PV_CALLEE_SAVE(xen_make_pmd),
-		.pmd_val = PV_CALLEE_SAVE(xen_pmd_val),
-
-		.pud_val = PV_CALLEE_SAVE(xen_pud_val),
-		.make_pud = PV_CALLEE_SAVE(xen_make_pud),
-		.set_p4d = xen_set_p4d_hyper,
-
-		.alloc_pud = xen_alloc_pmd_init,
-		.release_pud = xen_release_pmd_init,
-
-		.p4d_val = PV_CALLEE_SAVE(xen_p4d_val),
-		.make_p4d = PV_CALLEE_SAVE(xen_make_p4d),
-
-		.enter_mmap = xen_enter_mmap,
-		.exit_mmap = xen_exit_mmap,
-
-		.lazy_mode = {
-			.enter = xen_enter_lazy_mmu,
-			.leave = xen_leave_lazy_mmu,
-			.flush = xen_flush_lazy_mmu,
-		},
-
-		.set_fixmap = xen_set_fixmap,
-	},
-};
-
 void __init xen_init_mmu_ops(void)
 {
 	x86_init.paging.pagetable_init = xen_pagetable_init;
 	x86_init.hyper.init_after_bootmem = xen_after_bootmem;
 
-	pv_ops.mmu = xen_mmu_ops.mmu;
+	pv_ops.mmu.read_cr2 = __PV_IS_CALLEE_SAVE(xen_read_cr2);
+	pv_ops.mmu.write_cr2 = xen_write_cr2;
+	pv_ops.mmu.read_cr3 = xen_read_cr3;
+	pv_ops.mmu.write_cr3 = xen_write_cr3_init;
+	pv_ops.mmu.flush_tlb_user = xen_flush_tlb;
+	pv_ops.mmu.flush_tlb_kernel = xen_flush_tlb;
+	pv_ops.mmu.flush_tlb_one_user = xen_flush_tlb_one_user;
+	pv_ops.mmu.flush_tlb_multi = xen_flush_tlb_multi;
+	pv_ops.mmu.pgd_alloc = xen_pgd_alloc;
+	pv_ops.mmu.pgd_free = xen_pgd_free;
+	pv_ops.mmu.alloc_pte = xen_alloc_pte_init;
+	pv_ops.mmu.release_pte = xen_release_pte_init;
+	pv_ops.mmu.alloc_pmd = xen_alloc_pmd_init;
+	pv_ops.mmu.release_pmd = xen_release_pmd_init;
+	pv_ops.mmu.set_pte = xen_set_pte_init;
+	pv_ops.mmu.set_pmd = xen_set_pmd_hyper;
+	pv_ops.mmu.ptep_modify_prot_start = xen_ptep_modify_prot_start;
+	pv_ops.mmu.ptep_modify_prot_commit = xen_ptep_modify_prot_commit;
+	pv_ops.mmu.pte_val = PV_CALLEE_SAVE(xen_pte_val);
+	pv_ops.mmu.pgd_val = PV_CALLEE_SAVE(xen_pgd_val);
+	pv_ops.mmu.make_pte = PV_CALLEE_SAVE(xen_make_pte_init);
+	pv_ops.mmu.make_pgd = PV_CALLEE_SAVE(xen_make_pgd);
+	pv_ops.mmu.set_pud = xen_set_pud_hyper;
+	pv_ops.mmu.make_pmd = PV_CALLEE_SAVE(xen_make_pmd);
+	pv_ops.mmu.pmd_val = PV_CALLEE_SAVE(xen_pmd_val);
+	pv_ops.mmu.pud_val = PV_CALLEE_SAVE(xen_pud_val);
+	pv_ops.mmu.make_pud = PV_CALLEE_SAVE(xen_make_pud);
+	pv_ops.mmu.set_p4d = xen_set_p4d_hyper;
+	pv_ops.mmu.alloc_pud = xen_alloc_pmd_init;
+	pv_ops.mmu.release_pud = xen_release_pmd_init;
+	pv_ops.mmu.p4d_val = PV_CALLEE_SAVE(xen_p4d_val);
+	pv_ops.mmu.make_p4d = PV_CALLEE_SAVE(xen_make_p4d);
+	pv_ops.mmu.enter_mmap = xen_enter_mmap;
+	pv_ops.mmu.exit_mmap = xen_exit_mmap;
+	pv_ops.mmu.lazy_mode.enter = xen_enter_lazy_mmu;
+	pv_ops.mmu.lazy_mode.leave = xen_leave_lazy_mmu;
+	pv_ops.mmu.lazy_mode.flush = xen_flush_lazy_mmu;
+	pv_ops.mmu.set_fixmap = xen_set_fixmap;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
 }
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index c2a3079fe5f8..e2736b462c90 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -592,7 +592,6 @@ static int init_pv_ops(struct objtool_file *file)
 {
 	static const char *pv_ops_tables[] = {
 		"pv_ops",
-		"xen_mmu_ops",
 		NULL,
 	};
 	const char *pv_ops;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:56:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:56:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125300.1467309 (Exim 4.92)
	(envelope-from )
	id 1uytZu-0007pS-9h; Wed, 17 Sep 2025 14:56:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125300.1467309; Wed, 17 Sep 2025 14: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 1uytZu-0007pE-5K; Wed, 17 Sep 2025 14:56:14 +0000
Received: by outflank-mailman (input) for mailman id 1125300;
 Wed, 17 Sep 2025 14:56: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 1uytXl-0004jI-74
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:54:01 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 252c7641-93d6-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:54: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 5BF222073D;
 Wed, 17 Sep 2025 14:54: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 009E11368D;
 Wed, 17 Sep 2025 14:53:59 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Ng47OofLymh3EwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:53: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: 252c7641-93d6-11f0-9d13-b5c5bf9af7f9
Authentication-Results: smtp-out2.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross ,
	Boris Ostrovsky ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Josh Poimboeuf ,
	Peter Zijlstra ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 16/21] x86/xen: Drop xen_cpu_ops
Date: Wed, 17 Sep 2025 16:52:15 +0200
Message-ID: <20250917145220.31064-17-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-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-Spam-Level: 
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]
X-Rspamd-Queue-Id: 5BF222073D
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Flag: NO
X-Spam-Score: -4.00

Instead of having a pre-filled array xen_cpu_ops for Xen PV paravirt
functions, drop the array and assign each element individually.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 arch/x86/xen/enlighten_pv.c | 82 +++++++++++++++----------------------
 tools/objtool/check.c       |  1 -
 2 files changed, 33 insertions(+), 50 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 26bbaf4b7330..45ce2be41628 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1213,54 +1213,6 @@ static const struct pv_info xen_info __initconst = {
 	.name = "Xen",
 };
 
-static const typeof(pv_ops) xen_cpu_ops __initconst = {
-	.cpu = {
-		.cpuid = xen_cpuid,
-
-		.set_debugreg = xen_set_debugreg,
-		.get_debugreg = xen_get_debugreg,
-
-		.read_cr0 = xen_read_cr0,
-		.write_cr0 = xen_write_cr0,
-
-		.write_cr4 = xen_write_cr4,
-
-		.read_msr = xen_read_msr,
-		.write_msr = xen_write_msr,
-
-		.read_msr_safe = xen_read_msr_safe,
-		.write_msr_safe = xen_write_msr_safe,
-
-		.read_pmc = xen_read_pmc,
-
-		.load_tr_desc = paravirt_nop,
-		.set_ldt = xen_set_ldt,
-		.load_gdt = xen_load_gdt,
-		.load_idt = xen_load_idt,
-		.load_tls = xen_load_tls,
-		.load_gs_index = xen_load_gs_index,
-
-		.alloc_ldt = xen_alloc_ldt,
-		.free_ldt = xen_free_ldt,
-
-		.store_tr = xen_store_tr,
-
-		.write_ldt_entry = xen_write_ldt_entry,
-		.write_gdt_entry = xen_write_gdt_entry,
-		.write_idt_entry = xen_write_idt_entry,
-		.load_sp0 = xen_load_sp0,
-
-#ifdef CONFIG_X86_IOPL_IOPERM
-		.invalidate_io_bitmap = xen_invalidate_io_bitmap,
-		.update_io_bitmap = xen_update_io_bitmap,
-#endif
-		.io_delay = xen_io_delay,
-
-		.start_context_switch = xen_start_context_switch,
-		.end_context_switch = xen_end_context_switch,
-	},
-};
-
 static void xen_restart(char *msg)
 {
 	xen_reboot(SHUTDOWN_reboot);
@@ -1411,7 +1363,39 @@ asmlinkage __visible void __init xen_start_kernel(struct start_info *si)
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
-	pv_ops.cpu = xen_cpu_ops.cpu;
+
+	pv_ops.cpu.cpuid = xen_cpuid;
+	pv_ops.cpu.set_debugreg = xen_set_debugreg;
+	pv_ops.cpu.get_debugreg = xen_get_debugreg;
+	pv_ops.cpu.read_cr0 = xen_read_cr0;
+	pv_ops.cpu.write_cr0 = xen_write_cr0;
+	pv_ops.cpu.write_cr4 = xen_write_cr4;
+	pv_ops.cpu.read_msr = xen_read_msr;
+	pv_ops.cpu.write_msr = xen_write_msr;
+	pv_ops.cpu.read_msr_safe = xen_read_msr_safe;
+	pv_ops.cpu.write_msr_safe = xen_write_msr_safe;
+	pv_ops.cpu.read_pmc = xen_read_pmc;
+	pv_ops.cpu.load_tr_desc = paravirt_nop;
+	pv_ops.cpu.set_ldt = xen_set_ldt;
+	pv_ops.cpu.load_gdt = xen_load_gdt;
+	pv_ops.cpu.load_idt = xen_load_idt;
+	pv_ops.cpu.load_tls = xen_load_tls;
+	pv_ops.cpu.load_gs_index = xen_load_gs_index;
+	pv_ops.cpu.alloc_ldt = xen_alloc_ldt;
+	pv_ops.cpu.free_ldt = xen_free_ldt;
+	pv_ops.cpu.store_tr = xen_store_tr;
+	pv_ops.cpu.write_ldt_entry = xen_write_ldt_entry;
+	pv_ops.cpu.write_gdt_entry = xen_write_gdt_entry;
+	pv_ops.cpu.write_idt_entry = xen_write_idt_entry;
+	pv_ops.cpu.load_sp0 = xen_load_sp0;
+#ifdef CONFIG_X86_IOPL_IOPERM
+	pv_ops.cpu.invalidate_io_bitmap = xen_invalidate_io_bitmap;
+	pv_ops.cpu.update_io_bitmap = xen_update_io_bitmap;
+#endif
+	pv_ops.cpu.io_delay = xen_io_delay;
+	pv_ops.cpu.start_context_switch = xen_start_context_switch;
+	pv_ops.cpu.end_context_switch = xen_end_context_switch;
+
 	xen_init_irq_ops();
 
 	/*
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 14ae91cc246a..c2a3079fe5f8 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -592,7 +592,6 @@ static int init_pv_ops(struct objtool_file *file)
 {
 	static const char *pv_ops_tables[] = {
 		"pv_ops",
-		"xen_cpu_ops",
 		"xen_mmu_ops",
 		NULL,
 	};
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:56:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:56:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125304.1467322 (Exim 4.92)
	(envelope-from )
	id 1uytZx-0008LI-Pe; Wed, 17 Sep 2025 14:56:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125304.1467322; Wed, 17 Sep 2025 14: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 1uytZx-0008L9-MO; Wed, 17 Sep 2025 14:56:17 +0000
Received: by outflank-mailman (input) for mailman id 1125304;
 Wed, 17 Sep 2025 14:56: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 1uytXf-0004jI-Qw
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:53:55 +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 21b76108-93d6-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:53:54 +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 8E77C3383C;
 Wed, 17 Sep 2025 14:53:54 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 349C61368D;
 Wed, 17 Sep 2025 14:53:54 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id oFNnC4LLymhwEwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:53: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: 21b76108-93d6-11f0-9d13-b5c5bf9af7f9
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross ,
	Boris Ostrovsky ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Josh Poimboeuf ,
	Peter Zijlstra ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 15/21] x86/xen: Drop xen_irq_ops
Date: Wed, 17 Sep 2025 16:52:14 +0200
Message-ID: <20250917145220.31064-16-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-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-Action: no action
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]
X-Rspamd-Queue-Id: 8E77C3383C
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spam-Score: -4.00

Instead of having a pre-filled array xen_irq_ops for Xen PV paravirt
functions, drop the array and assign each element individually.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 arch/x86/xen/irq.c    | 20 +++++++-------------
 tools/objtool/check.c |  1 -
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 39982f955cfe..d8678c3d3971 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -40,20 +40,14 @@ static void xen_halt(void)
 		xen_safe_halt();
 }
 
-static const typeof(pv_ops) xen_irq_ops __initconst = {
-	.irq = {
-		/* Initial interrupt flag handling only called while interrupts off. */
-		.save_fl = __PV_IS_CALLEE_SAVE(paravirt_ret0),
-		.irq_disable = __PV_IS_CALLEE_SAVE(paravirt_nop),
-		.irq_enable = __PV_IS_CALLEE_SAVE(BUG_func),
-
-		.safe_halt = xen_safe_halt,
-		.halt = xen_halt,
-	},
-};
-
 void __init xen_init_irq_ops(void)
 {
-	pv_ops.irq = xen_irq_ops.irq;
+	/* Initial interrupt flag handling only called while interrupts off. */
+	pv_ops.irq.save_fl = __PV_IS_CALLEE_SAVE(paravirt_ret0);
+	pv_ops.irq.irq_disable = __PV_IS_CALLEE_SAVE(paravirt_nop);
+	pv_ops.irq.irq_enable = __PV_IS_CALLEE_SAVE(BUG_func);
+	pv_ops.irq.safe_halt = xen_safe_halt;
+	pv_ops.irq.halt = xen_halt;
+
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index d14f20ef1db1..14ae91cc246a 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -593,7 +593,6 @@ static int init_pv_ops(struct objtool_file *file)
 	static const char *pv_ops_tables[] = {
 		"pv_ops",
 		"xen_cpu_ops",
-		"xen_irq_ops",
 		"xen_mmu_ops",
 		NULL,
 	};
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 14:56:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 14:56:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125309.1467332 (Exim 4.92)
	(envelope-from )
	id 1uytZz-00009N-2u; Wed, 17 Sep 2025 14:56:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125309.1467332; Wed, 17 Sep 2025 14:56: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 1uytZy-000098-UU; Wed, 17 Sep 2025 14:56:18 +0000
Received: by outflank-mailman (input) for mailman id 1125309;
 Wed, 17 Sep 2025 14:56: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 1uytYF-0004jI-Ee
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 14:54:31 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 36d706c1-93d6-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 16:54: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 E1BA820750;
 Wed, 17 Sep 2025 14:54: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 1DF291368D;
 Wed, 17 Sep 2025 14:54: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 ZzqRBaXLymieEwAAD6G6ig
 (envelope-from ); Wed, 17 Sep 2025 14:54:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36d706c1-93d6-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120869; 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=8N8BNr/7G8ZPffjUZylDkTdtOKvkH1xYKfpPdWRSBgI=;
	b=ORDiEYWmAela846ojlOVLwooqr/l77scEgcBOUJ0aSiWHokuZRLUlxjJPjpX4ZD2MMFEwK
	P49ZJ81MPF/fWgauv0Qo4AJBsMaC7YWI4ZSHS8VWZs458lkcWRRCZpLeoPzwhR46fNLxPl
	Ip1sAzpb4AZ5JIvSAelSG9MV+ARGsbE=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758120869; 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=8N8BNr/7G8ZPffjUZylDkTdtOKvkH1xYKfpPdWRSBgI=;
	b=ORDiEYWmAela846ojlOVLwooqr/l77scEgcBOUJ0aSiWHokuZRLUlxjJPjpX4ZD2MMFEwK
	P49ZJ81MPF/fWgauv0Qo4AJBsMaC7YWI4ZSHS8VWZs458lkcWRRCZpLeoPzwhR46fNLxPl
	Ip1sAzpb4AZ5JIvSAelSG9MV+ARGsbE=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org
Cc: Juergen Gross ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	Josh Poimboeuf ,
	Peter Zijlstra ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions into own header
Date: Wed, 17 Sep 2025 16:52:20 +0200
Message-ID: <20250917145220.31064-22-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917145220.31064-1-jgross@suse.com>
References: <20250917145220.31064-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[24];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -6.80

Instead of having the pv spinlock function definitions in paravirt.h,
move them into the new header paravirt-spinlock.h.

Signed-off-by: Juergen Gross 
---
V2:
- use new header instead of qspinlock.h
- use dedicated pv_ops_lock array
- move more paravirt related lock code
---
 arch/x86/hyperv/hv_spinlock.c            |  10 +-
 arch/x86/include/asm/paravirt-spinlock.h | 146 +++++++++++++++++++++++
 arch/x86/include/asm/paravirt.h          |  61 ----------
 arch/x86/include/asm/paravirt_types.h    |  17 ---
 arch/x86/include/asm/qspinlock.h         |  89 ++------------
 arch/x86/kernel/Makefile                 |   2 +-
 arch/x86/kernel/kvm.c                    |  10 +-
 arch/x86/kernel/paravirt-spinlocks.c     |  24 +++-
 arch/x86/kernel/paravirt.c               |  21 ----
 arch/x86/xen/spinlock.c                  |  10 +-
 tools/objtool/check.c                    |   1 +
 11 files changed, 192 insertions(+), 199 deletions(-)
 create mode 100644 arch/x86/include/asm/paravirt-spinlock.h

diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 2a3c2afb0154..210b494e4de0 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -78,11 +78,11 @@ void __init hv_init_spinlocks(void)
 	pr_info("PV spinlocks enabled\n");
 
 	__pv_init_lock_hash();
-	pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops.lock.queued_spin_unlock = PV_CALLEE_SAVE(__pv_queued_spin_unlock);
-	pv_ops.lock.wait = hv_qlock_wait;
-	pv_ops.lock.kick = hv_qlock_kick;
-	pv_ops.lock.vcpu_is_preempted = PV_CALLEE_SAVE(hv_vcpu_is_preempted);
+	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
+	pv_ops_lock.queued_spin_unlock = PV_CALLEE_SAVE(__pv_queued_spin_unlock);
+	pv_ops_lock.wait = hv_qlock_wait;
+	pv_ops_lock.kick = hv_qlock_kick;
+	pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(hv_vcpu_is_preempted);
 }
 
 static __init int hv_parse_nopvspin(char *arg)
diff --git a/arch/x86/include/asm/paravirt-spinlock.h b/arch/x86/include/asm/paravirt-spinlock.h
new file mode 100644
index 000000000000..ed3ed343903d
--- /dev/null
+++ b/arch/x86/include/asm/paravirt-spinlock.h
@@ -0,0 +1,146 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _ASM_X86_PARAVIRT_SPINLOCK_H
+#define _ASM_X86_PARAVIRT_SPINLOCK_H
+
+#include 
+
+#ifdef CONFIG_SMP
+#include 
+#endif
+
+struct qspinlock;
+
+struct pv_lock_ops {
+	void (*queued_spin_lock_slowpath)(struct qspinlock *lock, u32 val);
+	struct paravirt_callee_save queued_spin_unlock;
+
+	void (*wait)(u8 *ptr, u8 val);
+	void (*kick)(int cpu);
+
+	struct paravirt_callee_save vcpu_is_preempted;
+} __no_randomize_layout;
+
+extern struct pv_lock_ops pv_ops_lock;
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init paravirt_set_cap(void);
+extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __pv_init_lock_hash(void);
+extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __raw_callee_save___pv_queued_spin_unlock(struct qspinlock *lock);
+extern bool nopvspin;
+
+static __always_inline void pv_queued_spin_lock_slowpath(struct qspinlock *lock,
+							 u32 val)
+{
+	PVOP_VCALL2(pv_ops_lock, queued_spin_lock_slowpath, lock, val);
+}
+
+static __always_inline void pv_queued_spin_unlock(struct qspinlock *lock)
+{
+	PVOP_ALT_VCALLEE1(pv_ops_lock, queued_spin_unlock, lock,
+			  "movb $0, (%%" _ASM_ARG1 ");",
+			  ALT_NOT(X86_FEATURE_PVUNLOCK));
+}
+
+static __always_inline bool pv_vcpu_is_preempted(long cpu)
+{
+	return PVOP_ALT_CALLEE1(bool, pv_ops_lock, vcpu_is_preempted, cpu,
+				"xor %%" _ASM_AX ", %%" _ASM_AX ";",
+				ALT_NOT(X86_FEATURE_VCPUPREEMPT));
+}
+
+#define queued_spin_unlock queued_spin_unlock
+/**
+ * queued_spin_unlock - release a queued spinlock
+ * @lock : Pointer to queued spinlock structure
+ *
+ * A smp_store_release() on the least-significant byte.
+ */
+static inline void native_queued_spin_unlock(struct qspinlock *lock)
+{
+	smp_store_release(&lock->locked, 0);
+}
+
+static inline void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
+{
+	pv_queued_spin_lock_slowpath(lock, val);
+}
+
+static inline void queued_spin_unlock(struct qspinlock *lock)
+{
+	kcsan_release();
+	pv_queued_spin_unlock(lock);
+}
+
+#define vcpu_is_preempted vcpu_is_preempted
+static inline bool vcpu_is_preempted(long cpu)
+{
+	return pv_vcpu_is_preempted(cpu);
+}
+
+static __always_inline void pv_wait(u8 *ptr, u8 val)
+{
+	PVOP_VCALL2(pv_ops_lock, wait, ptr, val);
+}
+
+static __always_inline void pv_kick(int cpu)
+{
+	PVOP_VCALL1(pv_ops_lock, kick, cpu);
+}
+
+void __raw_callee_save___native_queued_spin_unlock(struct qspinlock *lock);
+bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+void __init native_pv_lock_init(void);
+__visible void __native_queued_spin_unlock(struct qspinlock *lock);
+bool pv_is_native_spin_unlock(void);
+__visible bool __native_vcpu_is_preempted(long cpu);
+bool pv_is_native_vcpu_is_preempted(void);
+
+/*
+ * virt_spin_lock_key - disables by default the virt_spin_lock() hijack.
+ *
+ * Native (and PV wanting native due to vCPU pinning) should keep this key
+ * disabled. Native does not touch the key.
+ *
+ * When in a guest then native_pv_lock_init() enables the key first and
+ * KVM/XEN might conditionally disable it later in the boot process again.
+ */
+DECLARE_STATIC_KEY_FALSE(virt_spin_lock_key);
+
+/*
+ * Shortcut for the queued_spin_lock_slowpath() function that allows
+ * virt to hijack it.
+ *
+ * Returns:
+ *   true - lock has been negotiated, all done;
+ *   false - queued_spin_lock_slowpath() will do its thing.
+ */
+#define virt_spin_lock virt_spin_lock
+static inline bool virt_spin_lock(struct qspinlock *lock)
+{
+	int val;
+
+	if (!static_branch_likely(&virt_spin_lock_key))
+		return false;
+
+	/*
+	 * On hypervisors without PARAVIRT_SPINLOCKS support we fall
+	 * back to a Test-and-Set spinlock, because fair locks have
+	 * horrible lock 'holder' preemption issues.
+	 */
+
+ __retry:
+	val = atomic_read(&lock->val);
+
+	if (val || !atomic_try_cmpxchg(&lock->val, &val, _Q_LOCKED_VAL)) {
+		cpu_relax();
+		goto __retry;
+	}
+
+	return true;
+}
+
+#endif /* _ASM_X86_PARAVIRT_SPINLOCK_H */
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index ec274d13bae0..b21072af731d 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -19,15 +19,6 @@
 #include 
 #include 
 
-__visible void __native_queued_spin_unlock(struct qspinlock *lock);
-bool pv_is_native_spin_unlock(void);
-__visible bool __native_vcpu_is_preempted(long cpu);
-bool pv_is_native_vcpu_is_preempted(void);
-
-#ifdef CONFIG_PARAVIRT_SPINLOCKS
-void __init paravirt_set_cap(void);
-#endif
-
 /* The paravirtualized I/O functions */
 static inline void slow_down_io(void)
 {
@@ -522,46 +513,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 {
 	pv_ops.mmu.set_fixmap(idx, phys, flags);
 }
-#endif
-
-#if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
-
-static __always_inline void pv_queued_spin_lock_slowpath(struct qspinlock *lock,
-							u32 val)
-{
-	PVOP_VCALL2(pv_ops, lock.queued_spin_lock_slowpath, lock, val);
-}
-
-static __always_inline void pv_queued_spin_unlock(struct qspinlock *lock)
-{
-	PVOP_ALT_VCALLEE1(pv_ops, lock.queued_spin_unlock, lock,
-			  "movb $0, (%%" _ASM_ARG1 ");",
-			  ALT_NOT(X86_FEATURE_PVUNLOCK));
-}
-
-static __always_inline void pv_wait(u8 *ptr, u8 val)
-{
-	PVOP_VCALL2(pv_ops, lock.wait, ptr, val);
-}
-
-static __always_inline void pv_kick(int cpu)
-{
-	PVOP_VCALL1(pv_ops, lock.kick, cpu);
-}
-
-static __always_inline bool pv_vcpu_is_preempted(long cpu)
-{
-	return PVOP_ALT_CALLEE1(bool, pv_ops, lock.vcpu_is_preempted, cpu,
-				"xor %%" _ASM_AX ", %%" _ASM_AX ";",
-				ALT_NOT(X86_FEATURE_VCPUPREEMPT));
-}
 
-void __raw_callee_save___native_queued_spin_unlock(struct qspinlock *lock);
-bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
-
-#endif /* SMP && PARAVIRT_SPINLOCKS */
-
-#ifdef CONFIG_PARAVIRT_XXL
 static __always_inline unsigned long arch_local_save_flags(void)
 {
 	return PVOP_ALT_CALLEE0(unsigned long, pv_ops, irq.save_fl, "pushf; pop %%rax;",
@@ -588,8 +540,6 @@ static __always_inline unsigned long arch_local_irq_save(void)
 }
 #endif
 
-void native_pv_lock_init(void) __init;
-
 #else  /* __ASSEMBLER__ */
 
 #ifdef CONFIG_X86_64
@@ -613,12 +563,6 @@ void native_pv_lock_init(void) __init;
 #endif /* __ASSEMBLER__ */
 #else  /* CONFIG_PARAVIRT */
 # define default_banner x86_init_noop
-
-#ifndef __ASSEMBLER__
-static inline void native_pv_lock_init(void)
-{
-}
-#endif
 #endif /* !CONFIG_PARAVIRT */
 
 #ifndef __ASSEMBLER__
@@ -634,10 +578,5 @@ static inline void paravirt_arch_exit_mmap(struct mm_struct *mm)
 }
 #endif
 
-#ifndef CONFIG_PARAVIRT_SPINLOCKS
-static inline void paravirt_set_cap(void)
-{
-}
-#endif
 #endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_PARAVIRT_H */
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 01a485f1a7f1..e2b487d35d14 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -184,22 +184,6 @@ struct pv_mmu_ops {
 #endif
 } __no_randomize_layout;
 
-#ifdef CONFIG_SMP
-#include 
-#endif
-
-struct qspinlock;
-
-struct pv_lock_ops {
-	void (*queued_spin_lock_slowpath)(struct qspinlock *lock, u32 val);
-	struct paravirt_callee_save queued_spin_unlock;
-
-	void (*wait)(u8 *ptr, u8 val);
-	void (*kick)(int cpu);
-
-	struct paravirt_callee_save vcpu_is_preempted;
-} __no_randomize_layout;
-
 /* This contains all the paravirt structures: we get a convenient
  * number for each function using the offset which we use to indicate
  * what to patch. */
@@ -207,7 +191,6 @@ struct paravirt_patch_template {
 	struct pv_cpu_ops	cpu;
 	struct pv_irq_ops	irq;
 	struct pv_mmu_ops	mmu;
-	struct pv_lock_ops	lock;
 } __no_randomize_layout;
 
 extern struct paravirt_patch_template pv_ops;
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index 68da67df304d..a2668bdf4c84 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -7,6 +7,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_PARAVIRT
+#include 
+#endif
 
 #define _Q_PENDING_LOOPS	(1 << 9)
 
@@ -27,89 +30,13 @@ static __always_inline u32 queued_fetch_set_pending_acquire(struct qspinlock *lo
 	return val;
 }
 
-#ifdef CONFIG_PARAVIRT_SPINLOCKS
-extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
-extern void __pv_init_lock_hash(void);
-extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
-extern void __raw_callee_save___pv_queued_spin_unlock(struct qspinlock *lock);
-extern bool nopvspin;
-
-#define	queued_spin_unlock queued_spin_unlock
-/**
- * queued_spin_unlock - release a queued spinlock
- * @lock : Pointer to queued spinlock structure
- *
- * A smp_store_release() on the least-significant byte.
- */
-static inline void native_queued_spin_unlock(struct qspinlock *lock)
-{
-	smp_store_release(&lock->locked, 0);
-}
-
-static inline void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
-{
-	pv_queued_spin_lock_slowpath(lock, val);
-}
-
-static inline void queued_spin_unlock(struct qspinlock *lock)
-{
-	kcsan_release();
-	pv_queued_spin_unlock(lock);
-}
-
-#define vcpu_is_preempted vcpu_is_preempted
-static inline bool vcpu_is_preempted(long cpu)
-{
-	return pv_vcpu_is_preempted(cpu);
-}
+#ifndef CONFIG_PARAVIRT_SPINLOCKS
+static inline void paravirt_set_cap(void) { }
 #endif
 
-#ifdef CONFIG_PARAVIRT
-/*
- * virt_spin_lock_key - disables by default the virt_spin_lock() hijack.
- *
- * Native (and PV wanting native due to vCPU pinning) should keep this key
- * disabled. Native does not touch the key.
- *
- * When in a guest then native_pv_lock_init() enables the key first and
- * KVM/XEN might conditionally disable it later in the boot process again.
- */
-DECLARE_STATIC_KEY_FALSE(virt_spin_lock_key);
-
-/*
- * Shortcut for the queued_spin_lock_slowpath() function that allows
- * virt to hijack it.
- *
- * Returns:
- *   true - lock has been negotiated, all done;
- *   false - queued_spin_lock_slowpath() will do its thing.
- */
-#define virt_spin_lock virt_spin_lock
-static inline bool virt_spin_lock(struct qspinlock *lock)
-{
-	int val;
-
-	if (!static_branch_likely(&virt_spin_lock_key))
-		return false;
-
-	/*
-	 * On hypervisors without PARAVIRT_SPINLOCKS support we fall
-	 * back to a Test-and-Set spinlock, because fair locks have
-	 * horrible lock 'holder' preemption issues.
-	 */
-
- __retry:
-	val = atomic_read(&lock->val);
-
-	if (val || !atomic_try_cmpxchg(&lock->val, &val, _Q_LOCKED_VAL)) {
-		cpu_relax();
-		goto __retry;
-	}
-
-	return true;
-}
-
-#endif /* CONFIG_PARAVIRT */
+#ifndef CONFIG_PARAVIRT
+static inline void native_pv_lock_init(void) { }
+#endif
 
 #include 
 
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0d2a6d953be9..56d57944fa4b 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -126,7 +126,7 @@ obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
 
 obj-$(CONFIG_KVM_GUEST)		+= kvm.o kvmclock.o
 obj-$(CONFIG_PARAVIRT)		+= paravirt.o
-obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= paravirt-spinlocks.o
+obj-$(CONFIG_PARAVIRT)		+= paravirt-spinlocks.o
 obj-$(CONFIG_PARAVIRT_CLOCK)	+= pvclock.o
 obj-$(CONFIG_X86_PMEM_LEGACY_DEVICE) += pmem.o
 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index a23211eaaeed..a94376d04dca 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -825,7 +825,7 @@ static void __init kvm_guest_init(void)
 		has_steal_clock = 1;
 		static_call_update(pv_steal_clock, kvm_steal_clock);
 
-		pv_ops.lock.vcpu_is_preempted =
+		pv_ops_lock.vcpu_is_preempted =
 			PV_CALLEE_SAVE(__kvm_vcpu_is_preempted);
 	}
 
@@ -1105,11 +1105,11 @@ void __init kvm_spinlock_init(void)
 	pr_info("PV spinlocks enabled\n");
 
 	__pv_init_lock_hash();
-	pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops.lock.queued_spin_unlock =
+	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
+	pv_ops_lock.queued_spin_unlock =
 		PV_CALLEE_SAVE(__pv_queued_spin_unlock);
-	pv_ops.lock.wait = kvm_wait;
-	pv_ops.lock.kick = kvm_kick_cpu;
+	pv_ops_lock.wait = kvm_wait;
+	pv_ops_lock.kick = kvm_kick_cpu;
 
 	/*
 	 * When PV spinlock is enabled which is preferred over
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 9e1ea99ad9df..f9cf6f71395a 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -3,12 +3,20 @@
  * Split spinlock implementation out into its own file, so it can be
  * compiled in a FTRACE-compatible way.
  */
+#include 
 #include 
 #include 
 #include 
 
-#include 
+DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
 
+void __init native_pv_lock_init(void)
+{
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+		static_branch_enable(&virt_spin_lock_key);
+}
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
 __visible void __native_queued_spin_unlock(struct qspinlock *lock)
 {
 	native_queued_spin_unlock(lock);
@@ -17,7 +25,7 @@ PV_CALLEE_SAVE_REGS_THUNK(__native_queued_spin_unlock);
 
 bool pv_is_native_spin_unlock(void)
 {
-	return pv_ops.lock.queued_spin_unlock.func ==
+	return pv_ops_lock.queued_spin_unlock.func ==
 		__raw_callee_save___native_queued_spin_unlock;
 }
 
@@ -29,7 +37,7 @@ PV_CALLEE_SAVE_REGS_THUNK(__native_vcpu_is_preempted);
 
 bool pv_is_native_vcpu_is_preempted(void)
 {
-	return pv_ops.lock.vcpu_is_preempted.func ==
+	return pv_ops_lock.vcpu_is_preempted.func ==
 		__raw_callee_save___native_vcpu_is_preempted;
 }
 
@@ -41,3 +49,13 @@ void __init paravirt_set_cap(void)
 	if (!pv_is_native_vcpu_is_preempted())
 		setup_force_cpu_cap(X86_FEATURE_VCPUPREEMPT);
 }
+
+struct pv_lock_ops pv_ops_lock = {
+	.queued_spin_lock_slowpath	= native_queued_spin_lock_slowpath,
+	.queued_spin_unlock		= PV_CALLEE_SAVE(__native_queued_spin_unlock),
+	.wait				= paravirt_nop,
+	.kick				= paravirt_nop,
+	.vcpu_is_preempted		= PV_CALLEE_SAVE(__native_vcpu_is_preempted),
+};
+EXPORT_SYMBOL(pv_ops_lock);
+#endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 5dfbd3f55792..a6ed52cae003 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -57,14 +57,6 @@ DEFINE_ASM_FUNC(pv_native_irq_enable, "sti", .noinstr.text);
 DEFINE_ASM_FUNC(pv_native_read_cr2, "mov %cr2, %rax", .noinstr.text);
 #endif
 
-DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
-
-void __init native_pv_lock_init(void)
-{
-	if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
-		static_branch_enable(&virt_spin_lock_key);
-}
-
 static noinstr void pv_native_safe_halt(void)
 {
 	native_safe_halt();
@@ -221,19 +213,6 @@ struct paravirt_patch_template pv_ops = {
 
 	.mmu.set_fixmap		= native_set_fixmap,
 #endif /* CONFIG_PARAVIRT_XXL */
-
-#if defined(CONFIG_PARAVIRT_SPINLOCKS)
-	/* Lock ops. */
-#ifdef CONFIG_SMP
-	.lock.queued_spin_lock_slowpath	= native_queued_spin_lock_slowpath,
-	.lock.queued_spin_unlock	=
-				PV_CALLEE_SAVE(__native_queued_spin_unlock),
-	.lock.wait			= paravirt_nop,
-	.lock.kick			= paravirt_nop,
-	.lock.vcpu_is_preempted		=
-				PV_CALLEE_SAVE(__native_vcpu_is_preempted),
-#endif /* SMP */
-#endif
 };
 
 #ifdef CONFIG_PARAVIRT_XXL
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index fe56646d6919..83ac24ead289 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -134,10 +134,10 @@ void __init xen_init_spinlocks(void)
 	printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
 
 	__pv_init_lock_hash();
-	pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops.lock.queued_spin_unlock =
+	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
+	pv_ops_lock.queued_spin_unlock =
 		PV_CALLEE_SAVE(__pv_queued_spin_unlock);
-	pv_ops.lock.wait = xen_qlock_wait;
-	pv_ops.lock.kick = xen_qlock_kick;
-	pv_ops.lock.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen);
+	pv_ops_lock.wait = xen_qlock_wait;
+	pv_ops_lock.kick = xen_qlock_kick;
+	pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen);
 }
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index ca6ad92618d8..e9e1b5d321e5 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -549,6 +549,7 @@ static struct {
 	int idx_off;
 } pv_ops_tables[] = {
 	{ .name = "pv_ops", },
+	{ .name = "pv_ops_lock", },
 	{ .name = NULL, .idx_off = -1 }
 };
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:25:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:25:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125377.1467342 (Exim 4.92)
	(envelope-from )
	id 1uyuyW-0004iy-2j; Wed, 17 Sep 2025 16:25:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125377.1467342; Wed, 17 Sep 2025 16:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyuyV-0004ir-Vu; Wed, 17 Sep 2025 16:25:43 +0000
Received: by outflank-mailman (input) for mailman id 1125377;
 Wed, 17 Sep 2025 16: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 1uyuyU-0004il-EW
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:25:42 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ec50c653-93e2-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 18:25:29 +0200 (CEST)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-693-YtmfcQCKOC6r91WcsH294Q-1; Wed,
 17 Sep 2025 12:25:23 -0400
Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A86521956087; Wed, 17 Sep 2025 16:25:13 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id C0BCD1955F1A; Wed, 17 Sep 2025 16:24: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: ec50c653-93e2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126328;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=kUXP9ocaHqG4ZvLyR3c2nu51I8BLK/XgpriRiiBs2cY=;
	b=YtnNkCuoVzTvF/roE60q0Qbg5hTDxOKWWRUca3ux5t/Nm+gcKiJYdOeAYGiMDBQfmmoaCw
	Zn6QbSTH/zi9nouWTjKxfLvLvIlm3WgpU95pYn8Lq3agWvLnQ8KsxYMOmPu9WeOTBBuZ8w
	3/aYFWDrReAYUBiPmqsPUS0Oc2/U0Pg=
X-MC-Unique: YtmfcQCKOC6r91WcsH294Q-1
X-Mimecast-MFC-AGG-ID: YtmfcQCKOC6r91WcsH294Q_1758126316
Date: Wed, 17 Sep 2025 17:24:35 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 1/7] docs/devel: Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17

On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Remove the instruction to call object_unparent(), and the exception
> of the "do not call object_unparent()" rule for instance_finalize().
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  docs/devel/memory.rst | 19 ++++++-------------
>  1 file changed, 6 insertions(+), 13 deletions(-)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:26:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:26:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125390.1467354 (Exim 4.92)
	(envelope-from )
	id 1uyuzW-0005HO-Ia; Wed, 17 Sep 2025 16:26:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125390.1467354; Wed, 17 Sep 2025 16:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyuzW-0005HG-Du; Wed, 17 Sep 2025 16:26:46 +0000
Received: by outflank-mailman (input) for mailman id 1125390;
 Wed, 17 Sep 2025 16:26: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 1uyuzV-0004zg-Ke
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:26:45 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 18b2e9cb-93e3-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 18:26:44 +0200 (CEST)
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-416-hapfZl48PW2hRo36aERNxg-1; Wed,
 17 Sep 2025 12:26:40 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id D764318002C5; Wed, 17 Sep 2025 16:26:33 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 787DA180035E; Wed, 17 Sep 2025 16:26: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: 18b2e9cb-93e3-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126402;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=EqhuwGi6H3Q2byL0tqEwD6JYj4RMpDrC49lpCY7PLmg=;
	b=UJbyIN+HLH4biBqpHib7LjVFt14MNjDIskZ2xSPQdPhShhxxKeF/aUh1R3/1Iy4/JLOS2W
	POP2eRahzKK6Q5D0Ti0jHqfDNrFVGovexvUxD+cOJ10TgIXhFzjs6ZosSfuYF47aGVRxgm
	5qHkIKEu0qtcpmBg3pTZtuZhCUourhA=
X-MC-Unique: hapfZl48PW2hRo36aERNxg-1
X-Mimecast-MFC-AGG-ID: hapfZl48PW2hRo36aERNxg_1758126395
Date: Wed, 17 Sep 2025 17:26:01 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/7] vfio/pci: Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-2-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-2-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111

On Wed, Sep 17, 2025 at 07:13:27PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the insntance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  hw/vfio/pci.c | 4 ----
>  1 file changed, 4 deletions(-)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:27:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:27:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125402.1467364 (Exim 4.92)
	(envelope-from )
	id 1uyv0U-0005qZ-R7; Wed, 17 Sep 2025 16:27:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125402.1467364; Wed, 17 Sep 2025 16:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyv0U-0005qS-Mj; Wed, 17 Sep 2025 16:27:46 +0000
Received: by outflank-mailman (input) for mailman id 1125402;
 Wed, 17 Sep 2025 16:27: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 1uyv0U-0005pp-2Z
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:27:46 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3cd4faaf-93e3-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 18:27:44 +0200 (CEST)
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-SZbV2YjlNuOnI3UjfZyBFQ-1; Wed,
 17 Sep 2025 12:27:39 -0400
Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id D16311800284; Wed, 17 Sep 2025 16:27:33 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 1FFA51800446; Wed, 17 Sep 2025 16:27: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: 3cd4faaf-93e3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126463;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=IXOx+jvVJd3lNAzICcdpQlTQ2913UvUrv5ED+R6MTL0=;
	b=NYt3c9m9xXTZS7pNDybNXK4dv+4aJiJebiPNkD8cysjrQlXA2cSUat8ybhjxdHDyeiiNOe
	61UsDWvk0RupfEcXEzUoMh2Ku/Agq7mEneR2m3FgVIZkmB0O4Xcr+S37+Aj8vWQKWitEXS
	BA5wMGN/ooYW1Y195sg66rYcsMBv638=
X-MC-Unique: SZbV2YjlNuOnI3UjfZyBFQ-1
X-Mimecast-MFC-AGG-ID: SZbV2YjlNuOnI3UjfZyBFQ_1758126455
Date: Wed, 17 Sep 2025 17:26:59 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 3/7] hw/core/register: Do not unparent in
 instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-3-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-3-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93

On Wed, Sep 17, 2025 at 07:13:28PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  hw/core/register.c | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:28:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:28:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125412.1467372 (Exim 4.92)
	(envelope-from )
	id 1uyv1Z-0006N8-2W; Wed, 17 Sep 2025 16:28:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125412.1467372; Wed, 17 Sep 2025 16:28:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyv1Y-0006N1-W8; Wed, 17 Sep 2025 16:28:52 +0000
Received: by outflank-mailman (input) for mailman id 1125412;
 Wed, 17 Sep 2025 16:28: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 1uyv1Y-0006Mn-23
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:28:52 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 64065043-93e3-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 18:28:50 +0200 (CEST)
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-41-oHHjpyQePCWNg5nvpOTFhA-1; Wed,
 17 Sep 2025 12:28:46 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id E449D1800578; Wed, 17 Sep 2025 16:28:39 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 7CCE819560B1; Wed, 17 Sep 2025 16:28: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: 64065043-93e3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126529;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ZDezycxulpvqbuXIFVRvukz4G+S7KwYiBf/Z4wmzbGY=;
	b=iCE/EU852EhcQFzoUiHU2xmnpuVF7yUH03qeD3ualLiQIC6d/+LJkBomBuIZY6VYz5wL0+
	E7fKPqnMORDjAoWMDVBNsqvTEUt3HIEDYAVJCIjapWY5UDkkDSjf8oS+zVq9QFGejME9cl
	L5YJvFR+t2iIqFMddyv5zncGyHA/X8Q=
X-MC-Unique: oHHjpyQePCWNg5nvpOTFhA-1
X-Mimecast-MFC-AGG-ID: oHHjpyQePCWNg5nvpOTFhA_1758126521
Date: Wed, 17 Sep 2025 17:28:09 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 4/7] hv-balloon: hw/core/register: Do not unparent in
 instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-4-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-4-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12

On Wed, Sep 17, 2025 at 07:13:29PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  hw/hyperv/hv-balloon.c | 12 +-----------
>  1 file changed, 1 insertion(+), 11 deletions(-)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:32:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:32:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125426.1467383 (Exim 4.92)
	(envelope-from )
	id 1uyv56-0007x7-Hm; Wed, 17 Sep 2025 16:32:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125426.1467383; Wed, 17 Sep 2025 16:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyv56-0007x0-Eh; Wed, 17 Sep 2025 16:32:32 +0000
Received: by outflank-mailman (input) for mailman id 1125426;
 Wed, 17 Sep 2025 16:32: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 1uyv55-0007wu-M2
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:32:31 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e6be61c5-93e3-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 18:32:29 +0200 (CEST)
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-584-b9Lp2hCNOam4eNWv8jmttQ-1; Wed,
 17 Sep 2025 12:32:18 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 66E1B180057E; Wed, 17 Sep 2025 16:32:13 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 80EF81800451; Wed, 17 Sep 2025 16:31: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: e6be61c5-93e3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126748;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=RQ2Bf61nS5jFbyZtsZ/YA55Lz+xFQOEhfKXzsBREcpE=;
	b=YlafVJXQOhWTsigDbagdiYgiyFjjQilaDe4B1wavk9Juu1opcGfIS8e2SSltq2wzS7KeEY
	MZ06j3esGJuJ4wdYU2vME2Oy+LW+HzMcrkcfRI498lBN0ZgnMUev4tg1T2xuuYRSZmc1Rr
	41x8p5GtW2zhgAt6wUPbIoVuRGZ4Qvc=
X-MC-Unique: b9Lp2hCNOam4eNWv8jmttQ-1
X-Mimecast-MFC-AGG-ID: b9Lp2hCNOam4eNWv8jmttQ_1758126734
Date: Wed, 17 Sep 2025 17:31:45 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 5/7] hw/sd/sdhci: Do not unparent in
 instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-5-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-5-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111

On Wed, Sep 17, 2025 at 07:13:30PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  hw/sd/sdhci.c | 4 ----
>  1 file changed, 4 deletions(-)

Reviewed-by: Daniel P. Berrangé 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:33:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:33:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125437.1467392 (Exim 4.92)
	(envelope-from )
	id 1uyv69-0008S2-RK; Wed, 17 Sep 2025 16:33:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125437.1467392; Wed, 17 Sep 2025 16:33: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 1uyv69-0008Rv-Na; Wed, 17 Sep 2025 16:33:37 +0000
Received: by outflank-mailman (input) for mailman id 1125437;
 Wed, 17 Sep 2025 16:33: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 1uyv68-0007wu-Jq
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:33:36 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0dc25200-93e4-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 18:33:35 +0200 (CEST)
Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-282-mdTo4u2IMZGulAKYYby4XQ-1; Wed,
 17 Sep 2025 12:33:25 -0400
Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 3D541195608A; Wed, 17 Sep 2025 16:33:20 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 5C1011955F1A; Wed, 17 Sep 2025 16:32: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: 0dc25200-93e4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126813;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=tAGvM+L5yLHsw7sfS9oMqxsfwzeli5DfRDJbUeVscOs=;
	b=iaPk8ozXl1NZwVrYM1LD5qaYqT8DtDdWFYW3EKTzB2xxwgm9wC9/9N0mWITMzUCa5yJ1CP
	iuPIzJ0eLn/yKfWgjC3uzuXyI0IUch0wgpkcml5nm3ckXc+zjipNiX13urhaDPkEwb2Stu
	6qMP7/VVlWIqY2u6IF/DA/+ZdPAMtsw=
X-MC-Unique: mdTo4u2IMZGulAKYYby4XQ-1
X-Mimecast-MFC-AGG-ID: mdTo4u2IMZGulAKYYby4XQ_1758126800
Date: Wed, 17 Sep 2025 17:32:52 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 6/7] vfio: Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-6-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-6-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17

On Wed, Sep 17, 2025 at 07:13:31PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  hw/vfio/pci-quirks.c | 9 +--------
>  hw/vfio/region.c     | 3 ---
>  2 files changed, 1 insertion(+), 11 deletions(-)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 16:34:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 16:34:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125449.1467403 (Exim 4.92)
	(envelope-from )
	id 1uyv6p-0000Zu-8d; Wed, 17 Sep 2025 16:34:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125449.1467403; Wed, 17 Sep 2025 16:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uyv6p-0000Zn-5T; Wed, 17 Sep 2025 16:34:19 +0000
Received: by outflank-mailman (input) for mailman id 1125449;
 Wed, 17 Sep 2025 16:34: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 1uyv6n-0007wu-MY
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 16:34:17 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 261e8eb5-93e4-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 18:34:16 +0200 (CEST)
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-657-dNknvzp2MLq7dhSFEAxf0w-1; Wed,
 17 Sep 2025 12:34:12 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id CB93E19560B7; Wed, 17 Sep 2025 16:34:06 +0000 (UTC)
Received: from redhat.com (unknown [10.42.28.195])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id D1E1519560B1; Wed, 17 Sep 2025 16:33: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: 261e8eb5-93e4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758126854;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=IpiM46wSAYiXsuBoekrH+wzKI1uV9SibOc1jU8ryTmY=;
	b=DntkAbNiqOB8yhiaoOJFyZ/wgfNHdrKD9j7o6g2tO/Gla5A02H01deOdaqltUknAVvmLin
	u9FqAfJ5/ttJVY1qtehTPdRXIM8Jym9C2PnsF/UKQpFf5HzsZkFrh6a+mHNwUyRFUFOO1r
	/8XPpsHcG/qRt4huPXpS+0knFZChEjo=
X-MC-Unique: dNknvzp2MLq7dhSFEAxf0w-1
X-Mimecast-MFC-AGG-ID: dNknvzp2MLq7dhSFEAxf0w_1758126847
Date: Wed, 17 Sep 2025 17:33:40 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost , Peter Xu ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 7/7] hw/xen: Do not unparent in instance_finalize()
Message-ID: 
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-7-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250917-use-v3-7-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
User-Agent: Mutt/2.2.14 (2025-02-20)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12

On Wed, Sep 17, 2025 at 07:13:32PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  hw/xen/xen_pt_msi.c | 11 +----------
>  1 file changed, 1 insertion(+), 10 deletions(-)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 17:39:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 17:39:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125473.1467413 (Exim 4.92)
	(envelope-from )
	id 1uyw81-0000ng-Rt; Wed, 17 Sep 2025 17:39:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125473.1467413; Wed, 17 Sep 2025 17: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 1uyw81-0000nZ-P5; Wed, 17 Sep 2025 17:39:37 +0000
Received: by outflank-mailman (input) for mailman id 1125473;
 Wed, 17 Sep 2025 17:39:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uyw80-0000mz-B0
 for xen-devel@lists.xen.org; Wed, 17 Sep 2025 17:39:36 +0000
Received: from BN1PR04CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c110::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 45e1031f-93ed-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 19:39:35 +0200 (CEST)
Received: from BN9PR03MB6027.namprd03.prod.outlook.com (2603:10b6:408:118::7)
 by DS7PR03MB5656.namprd03.prod.outlook.com (2603:10b6:5:2d0::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.13; Wed, 17 Sep
 2025 17:39:31 +0000
Received: from BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779]) by BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779%6]) with mapi id 15.20.9137.012; Wed, 17 Sep 2025
 17:39:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45e1031f-93ed-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WZYxPBQ9ev9HMVyLrAukRZrBMxB/BGDl2nZc+zy2me3f5auSQ/b0A2vPr0sVlOtFVeClckEHmC05KbTQx9sGj2t3Ikoj8IE4o5U4RnSiSv3JtzjcoSsG+9GEd3IiELRXHVqegyo6KfJvDzWVqvLU2di2tfqLDV7FaquTsVIfRtaWNgsTThfFjhr/LNvLoPhTyCoyek0hYNZTismgOJ10ylP3Gg24kaLrT6xd9Zg/rBlnhXPWHH4tQp6dy9UasxR8wYNMsR1AP72Nj8dLqpv18cnnS/++G796VgRvXcLedLP08bpghezhD5hpcYmAOHTZL3msaHy8WN+gCICWRKUrsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xMUz5YWKZbS1DiZwLy5+Q9SeTceii7ScuxGwx2YOxWk=;
 b=QyySDQ52cmtjODUSswCKDhZKHq3kf90ydo/3PJX42pjOJH8Ogr88A1RLrNXnqXvtx4laCIvqDkLZDPi7QNZLGLCJwvV+LDj96Nimat3aDWEEsyk+/beCIdPKlmJZG9Ud4kFAPmbihKsRNY8f8FBt5MHyFIBqFIu0s4VresgvmJruvFGqyLkt9nTn9gUEuE2E6owAab18tEytklBjGIrmf2maD5kw4RbjIUlTrRt86Eu2d6UlC8X6YAP9jXVWiSjh+m4TAwt0tDXF9m8McsyyptonU1u9HL4jujOemHucm7+rpatMsp3ZcshSNugVjMlOuGsfSAyCrnvy8yGlsDhBtg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xMUz5YWKZbS1DiZwLy5+Q9SeTceii7ScuxGwx2YOxWk=;
 b=VxgqNwsXnOh+8PEnm06wzzzdIn0QL4cDSVUolcIXVWGMmWeUEV87A3jBl6M21wiprD+tqnYn6VdIQguclcLFYuF5BMO1RawslK1Mi4EBog12BV3O+jzyEDdqi4tkDWs02efqColuup5mis3zQ0BzUsy/QyDkT5ri3zlXjF1KEA0=
From: Alex Brett 
To: "xen-devel@lists.xen.org" 
Subject: Xen Summit 2025 - "feature tracking for releases" design session
 notes
Thread-Topic: Xen Summit 2025 - "feature tracking for releases" design session
 notes
Thread-Index: AQHcJ/naHDfZdbPcJE+n2aX6bSqg1A==
Date: Wed, 17 Sep 2025 17:39:31 +0000
Message-ID:
 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN9PR03MB6027:EE_|DS7PR03MB5656:EE_
x-ms-office365-filtering-correlation-id: 77eae75d-3e57-493c-a56c-08ddf61128dd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?i7D2bXbOPyi1xbLv84YxDbBNF5EH32Api1Di8+9qOyi/0k0udNZXXy4bkM?=
 =?iso-8859-1?Q?XV3peP4LOfQeKD5uvw8ZbZuWoUpPoiZicjurhytDeFqyg8aeLK72WfIC71?=
 =?iso-8859-1?Q?vPHfl1jSpNpNZCDtR0MWGBGlfCNSo3J1EFpVMkFXG1ILxkNl8aY9/Pf6st?=
 =?iso-8859-1?Q?KAy+FYuNnWRwZPQ5VFNzdrGfMY13ZcCZdSV9i+c3mxXf30b2PaRepbOWkm?=
 =?iso-8859-1?Q?fU3AUL9R8mLvOIU+dVIuT+02vDDPTd9J47gzhJrpbmCaYWDrtUOaYfhgbS?=
 =?iso-8859-1?Q?r2g3LiTW/CzbsxRTscccz5Viwbz8mWlXOyZsZZa6oBJQaR1VERMqZEs6Da?=
 =?iso-8859-1?Q?a0j7qIHD6eJDPPQcN/Hf/WLKDM6afDUpyshSkYMMCrDmfxM1b2O6z4MjwM?=
 =?iso-8859-1?Q?BnVigTX7etiOk/ZyN3Z2sJH3rRZsGplhUe1wv+mZWzXNEfe2CaoEt4WOCI?=
 =?iso-8859-1?Q?xCEgJgnpjAU8z+6IAwW5EXBgMC3rzX2lq0VCkanmezvlOgva2el5IvbNEn?=
 =?iso-8859-1?Q?adzpR7imFIx1KRPL2CmYWK9MsbRUWQvoGWCgnmDgznUuyBxjCmlHGMrX7G?=
 =?iso-8859-1?Q?0aFvBrtMB3IyebTcgqQUtn7v7okcfhZAHJVHC+sdrvBPd1TsOgb2eNjXV7?=
 =?iso-8859-1?Q?z1S5Q6c1Hba9zBn1eRUo6h9/6dmMQS95XnPXWvf4gyNLyEIpcwOfAk2JlL?=
 =?iso-8859-1?Q?OMk+JGiBX6/GnBvvMwwcV3WXezgAEeCYhBUgy242nuhczSztCHtBxd9bBU?=
 =?iso-8859-1?Q?4HxWqqtkXMeaQmG3yL/n9q1i3r6wCa1PwGN0rPVYrw3CCYqMFZITCbtpkW?=
 =?iso-8859-1?Q?UdeK8OHYPcaj1+wsH0bG3SRgO+9AilkH4GpJkav85GVikX/gPGQisxPVnD?=
 =?iso-8859-1?Q?yzQmsbRKrP84jwaaFFDf2xHDGIswaltd9g0049SSfE5TP1GqZ+gaxzA6W0?=
 =?iso-8859-1?Q?DooVXurfs/rRWd6SlbZ5bw+pegD/Mp9zHN7uHd5WOJKZKfMHTDyJG6LcGv?=
 =?iso-8859-1?Q?bvSp7Q3Y84YTT90ghZ7cV6Utn0xWkv13zuF/6IJ/K/njFxgvd2jSOD+tA3?=
 =?iso-8859-1?Q?TIMoJojstHRBNGCehWYyMGmz1ufZzOsbJE5C8QezJoJPTgpaJqalZEDcRF?=
 =?iso-8859-1?Q?tfr2zYgFe3LE29xw19gK5/pyhAJrRAcf0Rl+nB+8+TAEi+LCUf7IBzgDFB?=
 =?iso-8859-1?Q?mGMyhlbGoAHbzyyPS5JxoCX39Hef5kTbqlBc777aVSUa3S6aRNYqvmT8UQ?=
 =?iso-8859-1?Q?YVXpsjzlnZeq/7QaJMj2FzEolIh6/cnxX/1pW5MGkYKfnX9UZEklukLwEL?=
 =?iso-8859-1?Q?YwLoC+l0ldJcOQv1jt/QBZg6aRAPLW05LnXb2PjHbQqfNBEsg5vmui7Lzb?=
 =?iso-8859-1?Q?3Wa3ieT144+sf3lJi4wJRfvQBSTJisICp7AhhiQ8O0DNTLVzqj154cNs0F?=
 =?iso-8859-1?Q?ebdXEF7PnETFi33sVQt+s8QLI4JuIZNneE6ekAHbddDBD27j/ULgfbPQ4q?=
 =?iso-8859-1?Q?1RTjsC6jfoeY7+f7RK8K4TpP1QZAnXu3dyZEy10+qvWw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR03MB6027.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?VASlKnyu3dZKbtQFBd/Bx29uR0tSrLiNLRk1YuKu1g7MUhwpC6DiPhCvrP?=
 =?iso-8859-1?Q?sMDfZ2P7vaDL6MrHyyQSvRsgHQmNGD3cQQVg7zf671mCFvuspX95EZvwSh?=
 =?iso-8859-1?Q?0unPCxFAl/wD758G4oXOWcp/Ce7bs728Vnv8uS4/WNFAN7P5SyZEBiEI9D?=
 =?iso-8859-1?Q?XgoJMK10R4awx7E81lJUwZQLonpzDzuTpj1yqRlGxB7CDQL8LANGUITug8?=
 =?iso-8859-1?Q?yCDVxFqRIpwR8tOWdEiWZSSP1O9mgwfODQIpWQxEOVFuAhZUaOriWZtJTA?=
 =?iso-8859-1?Q?9ea+P5g9kSQ2puZTcK0ym+bdkde36d9MWvBC1EQti26KIMEQd0ESb/b0ny?=
 =?iso-8859-1?Q?1h26VMMWl9R3OHPGpCaMqPa8fyzQLt2BDE7PEhTRcTs0KyUwg4cWB+ukXy?=
 =?iso-8859-1?Q?m8vaA/7rS1h69TkEbfk4Zk0qRkqyk8ls4rllcLJpCGgo2EErA1eevOSA7q?=
 =?iso-8859-1?Q?6sTliEipg9BLgVPwvT5wOaQ9EqvhzkOEBdbcJuBBisYADz/7dNihmyI7YR?=
 =?iso-8859-1?Q?UGDoT59f00KLvyosGbjbRho4wsPOJO1l6l1Qa9ms20+3HUSHrwFZ0hEQ+j?=
 =?iso-8859-1?Q?EVrepSAAcidzbAiorRTlllituYBdkI8wJSrYV4eYsIkdUJGv81ds4YeTrP?=
 =?iso-8859-1?Q?NynNbt9RnLovTQBkeoQAuIHvvaBZycyiqUiCkQ2DhAbZPTjluZj2ZfwjV+?=
 =?iso-8859-1?Q?OETT0dPKGOrhBSd4zZGUfN+m/xLG3ljFSaPBnyJoiuA0jwAKJglYoilZC3?=
 =?iso-8859-1?Q?FRzamczeqcgKqyTTrLgA7F9rKq1Zi5kzuASfTMKtnd2LHFxNvHHpn65SAe?=
 =?iso-8859-1?Q?mxAZKIcMadv5TY4beUasmXZ+8uNW1mSP6xUDlLkGjQLxQxBh0USEdBSaww?=
 =?iso-8859-1?Q?GUwVVjCwcuqP7f4X9Mrg6xBIZtVTuOu6tLAOQjNnLXvWC7hhAjYGXHsK7D?=
 =?iso-8859-1?Q?iBHkHRT/PmjGXCNM/NpsLqS0i6aJWxi4sZsSjIkj3w+cmKZGQZi3SpOAZ8?=
 =?iso-8859-1?Q?ipwi6nt5sqBKFvigEg708qgtRIhsfYIC+nw8tk56ot8m7VWih0TK8BcM3g?=
 =?iso-8859-1?Q?hEKdpl5OnVw9dmLunJC55tFSz1B3p5uNI8MiLIHqeBkjjm0FVjWrpHNDup?=
 =?iso-8859-1?Q?wo8AnVre87rrg8n3Q7vtvoFHPN7qYms6Cdv5sgYtGsPsnUn9GNzwxwYCGf?=
 =?iso-8859-1?Q?LfnFfOnqmouawFCM0l5zXt4ji/r5bI76YyoX14jTw5y200EfPoNbUVCEFE?=
 =?iso-8859-1?Q?0/7FyO2hnfGN72WlGSa7OXbPt6eNZ4cSJJMb/Q+f+dUbcCkhhuCGu5ujnU?=
 =?iso-8859-1?Q?oT3G7V7FVSI8gaammb2FJOtBIXDYyh5oIOsQE254yaaYPE5AOuApBsW9Zo?=
 =?iso-8859-1?Q?FPihhihKPoZkrKmiSTHFbeQ1GvuKVQ/o+PW5Z/YLyo+OLGsgwsC/ntrd3C?=
 =?iso-8859-1?Q?Yg43GOhEp3tYzCrFc5jqt5TESG/Oy1PQ391biR4QQLjmd2DOS4BdvDjceW?=
 =?iso-8859-1?Q?iGURqAJBYkLBcu64R88WnyK5gJl+fcBnkMM+IiOscxnzzIKRxHX4tFpS1L?=
 =?iso-8859-1?Q?yLLTxIjK4jO7PgPTintm1N0VnDS06KxWpiOJ/aySxO/dnK0jmOy209wMwY?=
 =?iso-8859-1?Q?Qh2eylmpEtqM2F31srSNSxWT0tqt0ZVvJ+?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR03MB6027.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 77eae75d-3e57-493c-a56c-08ddf61128dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2025 17:39:31.6483
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cFPbEgovjqPHn9KKA/koDgi3wIVIXR1ixftD1C8Ru7v63FRNI2If8KWsEPw/OYe1YqL7a8wg+/0vWiKyfP3pJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5656

(Apologies in advance for any misquotes etc)=0A=
=0A=
Jan Beulich (JB):=0A=
Intention is not to talk about 4.21 (largely done feature wise), plan is to=
 think about a more structured way of deciding e.g. at beginning of a relea=
se cycle what features we'd like to have in the release.=0A=
=0A=
What we have been doing is a large set of work with no plan, not taking int=
o account importance / ordering etc.=0A=
=0A=
Andrew Cooper (AC): Everything we do is reactive, patches come along and ma=
y go in may not.=0A=
=0A=
JB: Patches indicate someone is interested in functionality, but in some si=
tuations may go in quickly, others may not or be abandoned by author etc. H=
aving an overview of what people want in a release and are committed to wor=
king on (both author and reviewers etc) (AC: and necessary testing) would b=
e good.=0A=
=0A=
Is it something people think could work, if at beginning of release cycle w=
e settled on a plan of what we want in the release. New things can of cours=
e appear, but we'd be in a slightly better position of knowing what a relea=
se can bring?=0A=
=0A=
Rich Persaud (RP): Is there still a single release manager for each release=
? (room: Yes)=0A=
JB: Don't want to move away from that model=0A=
=0A=
AC: Tried to do this for the previous few releases, e.g. on the community c=
all presented "here's what XenServer is thinking of doing in the next relea=
se".=0A=
JB: Only the first step, then need to keep track of progress on things we i=
ntend to be in the release.=0A=
=0A=
RP: How do you transfer knowledge from old to new release manager?=0A=
=0A=
JB: New manager turns to old one with questions.=0A=
Oleksii Kurochko (OK): This time had short meeting where previous manager (=
Henry) told what he thought was necessary to know.=0A=
=0A=
Daniel Smith (DS): Useful for people to know which items to focus on that a=
re likely to make a release over e.g. review work on things which are not.=
=0A=
=0A=
AC: Complexity of review grows as series get larger. FRED example - went in=
 with 5 different series (some of which didn't say FRED). Splitting things =
up makes things easier to review and can end up with some parts getting in =
to some releases (even with no overall feature to talk about in that releas=
e).=0A=
=0A=
AC: Wherever possible we should be helping people to get parts of series in=
 to simplify remaining parts.=0A=
=0A=
Discussion around whether this would affect decisions as to what goes in. W=
hat about when authors have multiple things they're working on - clarificat=
ion around multiple things from same author or different authors (subtlety =
as e.g. XenServer may have 3 things from different authors but same manager=
s etc).=0A=
=0A=
Roger Pau Monne (RPM): Can't force people as to what they should review=0A=
JB: No, but if we had defined features for the release it would help review=
ers make their own decisions knowing what is more important=0A=
AC: Tricky in some cases, e.g. XenServer and secure boot - we said it was t=
he most important thing for us, but then nothing happened for ages. Importa=
nce therefore decreased as it became clear other problems meant it wouldn't=
 make it. Need to have a way of knowing when things change in priority=0A=
=0A=
JB: Can't commit other people in an open source community=0A=
=0A=
Marek Marczykowski-G=F3recki (MM): Community update emails from release man=
ager have been very useful. Don't see why these couldn't include plans abou=
t things that are not yet posted to the list.=0A=
RPM: Mails could get crowded if it lists anything people just have an inten=
tion to do rather than actual patches.=0A=
JB: Status emails felt a bit crowded recently. Need to make sure anything w=
e do here isn't too fine grained, but also doesn't omit too many things.=0A=
=0A=
AC: Effectively we want to maintain a status of features in the release. Pe=
rhaps a dedicated section in the community call where we can look at any up=
dates. Only way this will work is to spend a small amount of time very regu=
larly keeping it up to date - community call or similar venue seems appropr=
iate.=0A=
=0A=
OK: Last time this took half an hour=0A=
RPM: If we ensure it is just status and not technical detail discussion, th=
is should be better=0A=
AC: Have to be quite brutal about stopping it going into technical detail. =
Keep it to a small amount frequently it should be less work than waiting se=
veral months to do lots of updates in one go.=0A=
=0A=
RPM: Problem I have is knowing what to work on during the release, currentl=
y have to be quite reactive. E.g. could have put ASI in but then wouldn't h=
ave done any work on it.=0A=
Anthony Perard (AP): As a maintainer knowing what's important would help pr=
ioritise what to review more quickly.=0A=
=0A=
Discussion around grooming and when things get dropped - AC: have to be qui=
te strict about dropping things off which aren't making any progress.=0A=
=0A=
JB: Do we know who will be doing release manager job after Oleksii?=0A=
OK: I can do it again=0A=
=0A=
Alexander Merrit (AM): Do we want two release managers so one shadows the o=
ther to handover?=0A=
OK: Don't think this is necessary=0A=
=0A=
AC: Release manager is supposed to be lightweight=0A=
RP: There are other things the release manager could do for community wide =
coordination. Should be a community wide plan driven by revenue for compani=
es involved.=0A=
JB: We are not a company=0A=
=0A=
RP: Example of companies joining projects to get certain things done, sched=
ule might need to move to accommodate. Advisory board may need to fund a de=
dicated role to handle this sort of thing and coordinate the business side.=
=0A=
=0A=
AC: Stefano is doing this on the safety side, which is one (large) part, bu=
t not everything.=0A=
RPM: Recently we've not been that bad about releases missing features - ver=
y few things that were very close but didn't make the cut.=0A=
AC/JB: Two at the moment (domctl stuff, ?something else?), so worse this re=
lease than it has been in past ones.=0A=
=0A=
AM: Would it make sense to differentiate features that are 'reactive' vs wh=
at's good for the project as a whole?=0A=
AC: API/ABI example - doing more than what XenServer needs, as it it's a on=
e-off opportunity=0A=
RP: Great example - shouldn't have to be done as a charity to help the proj=
ect. Not sustainable.=0A=
AC: Some expectation/responsibility on maintainers as to work that has to b=
e done (e.g. CI work). Xen has no developers who work for Xen, everyone wor=
ks for a company who allows them to spend time on Xen.=0A=
RP: Companies should allocate an amount of hours to be directed by the rele=
ase manager=0A=
JB: His opinion that won't work in open source=0A=
AM: Could we get money put in for specific items. Some projects seem ashame=
d to ask for money, is that the case here?=0A=
RPM: Difficult to find people with the right skills for Xen. Not the proble=
m with money, but a problem with time.=0A=
=0A=
RPM: Advisory board could maybe hire contractors through LF, but difficult.=
=0A=
RP: Go to contributing companies and say we want N hours of time from someo=
ne at company to improve release coordination, carves out a budget of time.=
 Release manager goes from having zero power to maybe 1% power as they can =
now direct some work.=0A=
=0A=
Actionable items:=0A=
- Grooming a list to discuss in community call=0A=
  Make clear to people they don't need to wait a month to update, can discu=
ss on a thread=0A=
  Put the list on the agenda=0A=
  Formal tracking stays with release manager=0A=


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 17:40:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 17:40:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125483.1467423 (Exim 4.92)
	(envelope-from )
	id 1uyw99-0002DJ-6e; Wed, 17 Sep 2025 17:40:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125483.1467423; Wed, 17 Sep 2025 17:40: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 1uyw99-0002DC-2P; Wed, 17 Sep 2025 17:40:47 +0000
Received: by outflank-mailman (input) for mailman id 1125483;
 Wed, 17 Sep 2025 17:40: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 1uyw97-0002D4-L8
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 17:40:45 +0000
Received: from BN1PR04CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c110::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e500556-93ed-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 19:40:43 +0200 (CEST)
Received: from BN9PR03MB6027.namprd03.prod.outlook.com (2603:10b6:408:118::7)
 by DS7PR03MB5656.namprd03.prod.outlook.com (2603:10b6:5:2d0::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.13; Wed, 17 Sep
 2025 17:40:40 +0000
Received: from BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779]) by BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779%6]) with mapi id 15.20.9137.012; Wed, 17 Sep 2025
 17:40: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: 6e500556-93ed-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EMFBCudxkmZF6bbzW/Nq6NQzUic1ytqzC30H4LiNgeHeu6PJqdnIEZQdsVlzXE2331qHUNteot85aVRU2Mu+OMlt/5yc41R9M2h7jHrS8NLnxFHS7Uk6UdsJ7H9PmOMAuSBVsQYmNWcwykiu1+GLqpSh3tW/p8e32499I/KRxGIWKJA5xG+c/6ox1MlwEna9AbEy4ZzDWp/6R7HmS7BYCGVW+BCy8Okbb1lQGoQKt/EYl+mR5Kz5zGyNhk8jRyS1bvADwOc/kLzgDbLvXSuziKPzdMhp3hzZiqhxZNlU9pE4uIPQlFWq0MPm5SG1l9OrtjHeCNKTUZqh/ruoXNqb9g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kbrb2wxqRuklyfzT+m16BmV/WY7n7MdaBKmHfR7ZfhQ=;
 b=Jm3jsfgfHZeD4/o4+C78s1hIK7A9bUpC1ACNZ9/l1D9VuIJ6ojjBSletKMvSr7PGXG2bs/ymRkRca0qtS3DUu1hlZwDY6L8U+lbnu4D+0ItLWYbRYf+uVrFgSVd893l1jfPOsL1eWPbtJQ6NKQ/pojMDY/9hux1+RtEFbgztLXsa/d9jJZ9wefpNhZZT4JcCzBE2JlmmxtPXbk2/gkuxaMlW7kBFd7I0EOTokIiYpfq5aT89dB3aE7hzVtPspHnmrU5/jN2VtMux7YWgR2A2p2QLCGBQHcWQrm1MjLPl9MKEnshNZC9iPxtp+AZAooTzqfDru0ckvuFRORVsxRn2RA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kbrb2wxqRuklyfzT+m16BmV/WY7n7MdaBKmHfR7ZfhQ=;
 b=K8yK6f0WhqbyD8b9cEQGMvKmpG93Bb3nD+xl+69NEZGmxSmajMExWCtuSrgz1yMZBIEhrLrqv5UackpK2BmJ2EB0YOa15PvphSxZbqz6tFRzDlPh+7TKIoFZ53QYXyA/exVUcx7HLJGMVEHvFr2Yr37r48a4uvQtGTVozcyiZpk=
From: Alex Brett 
To: "Alexander M. Merritt" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: Xen Summit 2025 - Design Discussion Notes - Xen ABI
Thread-Topic: Xen Summit 2025 - Design Discussion Notes - Xen ABI
Thread-Index: AQHcJ46CuGDSzyyGzUK1N7jB9+iAwrSXpRTH
Date: Wed, 17 Sep 2025 17:40:39 +0000
Message-ID:
 
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN9PR03MB6027:EE_|DS7PR03MB5656:EE_
x-ms-office365-filtering-correlation-id: 23633fe2-9366-4a28-4b28-08ddf611518e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?K79h4XRQYMxnUt6t2bX8Wo7819pU/mBdOAuKo6Q+i3lKVWXHrGd7+OmvgD?=
 =?iso-8859-1?Q?7xjt6QkyvdfxE1c07CCIwvnMUvuqyJ99z+NOIUcs+BkGUl9OFc09rPFj9z?=
 =?iso-8859-1?Q?BIq2i/rPTAekagGLfrF7eSOkHjn7bs1yJHbj4Ds6ttiJQJ5dt3nHKJeIhH?=
 =?iso-8859-1?Q?u8d3J65cxPoU83obJJ6U9LRdO4onAVsofFJmo3sco0hSUyms8262QkODv1?=
 =?iso-8859-1?Q?BuMBNYjk0JwSxOGtbl+t+NXJjwzON2vi7hqJxKZ3+KVgim41oIJyWzDag6?=
 =?iso-8859-1?Q?ieZqwBakgbFdvX8IP1/PDh7gPzWtLghtChK30RWLMfcRbyPNTMqe0hZWsX?=
 =?iso-8859-1?Q?3nang2+3F8GEtnquYhfyDoPO41YHs+m9TRUgG0xndESaqKkPqKJRRQyfHb?=
 =?iso-8859-1?Q?svXoqhJqG8rwZ9fNwy2EbdPLEKwdX39jayigA43eY2VEtbwsQkuPNYapGv?=
 =?iso-8859-1?Q?TBVOB1ee8qJalSTR5/gnSxtta666ZuJHMfL5hwyTueFnCId/RVnkUl3/Yw?=
 =?iso-8859-1?Q?z+bSCrtVWCrTUMU1CDSmN53BnmYb5IUCXBPh77DfCwYYCdRTzNl6GeBVF9?=
 =?iso-8859-1?Q?mST4Y/e7b9NW2YoMGgGFLGmro6K7iejhG4LFCad65jHjMI41UcM+MNc1IR?=
 =?iso-8859-1?Q?bANLhjOQNk8Zx+qoHnuGTnalNahsTtcYXYrDc/8DrMBAoAAe+JG2eVTkbU?=
 =?iso-8859-1?Q?yhtYHEEEC3YIWhno9hKTDy3f73hVszQmaS19ax5Zx/N+Snm9zVbGTev7iI?=
 =?iso-8859-1?Q?42A563PQ55QSJl5IEeEuiwyZ6pObVT0bXtVa3hjS5sgtyvgvN8nxmFYZuK?=
 =?iso-8859-1?Q?3tgW9nScQyzD+RFipr3lWs9T96yf2ODKbaEc3c+DcbdGcgbB9Ym36eP3mL?=
 =?iso-8859-1?Q?v281iPUUujmFjjMlnsyYSpUuNnwM8/sgorptcQMEgzfvouh+m1OpzWb6up?=
 =?iso-8859-1?Q?xAv+gzZOdBN6cRHq5EhVkFhr7fNqLKZImj7zGgm4NmD954oLyUyBGyvb4p?=
 =?iso-8859-1?Q?4OnIqIIMOwzsKXRmMGvY6C55mIUCr3CcHuq19qmGz67DDAFHV9odqBQUUV?=
 =?iso-8859-1?Q?GDJy3ylEbowre32Z71jO40iWXQShuF/sh+h+ahSQNEhmbMhmSJEc8uliLd?=
 =?iso-8859-1?Q?UDVV1EPDQlzQyXvlMIRsTAHalGFONzjgyjH94B1ivfTReh1/l4kLIV3VFk?=
 =?iso-8859-1?Q?v42jANQxO1/PlIrrqw74615eyK0kNabnChiIhKEQbafLWeV+4o9oFdNrxR?=
 =?iso-8859-1?Q?paHfAC3WUZVrrmdRNebCHWXvSa3x4ymSM1rCZeZ/BUxkXu0V9ttjidbU+o?=
 =?iso-8859-1?Q?BMyeZQVM6c/1OAcH/Sqk6YNKno7ZRajmQPYh6Z0JynbJwHH9+F+VO+SFyx?=
 =?iso-8859-1?Q?qOi/u+Gu5U5YTT1tMVJvtIzk0Y0Wb4wVhAurn0DKFjeiwE49tilEbZrRgq?=
 =?iso-8859-1?Q?qoOraK5ekydXfUk3BLtEuiPJbFiEjTdyOGX/GNwc4ztiepeqTNuVR/c2En?=
 =?iso-8859-1?Q?VGT+TnKIR6PNrLYui77Z+u1+denOOAi4SLQ9kqr+Mv4A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR03MB6027.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?AEsqntl2rNEYtszRL8v0XDZtQdVJINR4jel7wdoAJ9UU0kpinrI7v8IycK?=
 =?iso-8859-1?Q?gAMLSdnhbKPWxxZrO/6YvUC9RW0g/sPAtgB18BL17V3YfsD0fgAgjMr2Ed?=
 =?iso-8859-1?Q?9Otd5hxDGiN66k0bRBrqnxBMSzTdSTBeIBbXaQnY8nkii2Aop95FcmYc1Y?=
 =?iso-8859-1?Q?dB3tuocyBvZRvKUQcH95Arxawgzz7zl4ApEW1UkptaTBe3wDyRfXZCDrw0?=
 =?iso-8859-1?Q?zHfHFph1FuYUIXs5AHKbSzYAYd/wm1tMctg8vHfSDe/SaCYutIfFxSOylD?=
 =?iso-8859-1?Q?Ak5le6lKomY88qq+rzgZZ5cajDz6n7BvIbGfdz0/YYwH4+OFQoEByjGt2m?=
 =?iso-8859-1?Q?slzf/8712PSqt9ImDU1Rm1mso2z+3LMZ3qi+GzgbRwx3WshMTFPM+1QoWL?=
 =?iso-8859-1?Q?rHlVriaswtr5ngy0CTPy5ziSWJRNzpAfuUWmCOHed9oNt2YhUWjnnNRW/y?=
 =?iso-8859-1?Q?1CHSePfFllfLOuoenndNCDHlMpfjACEP1taPKD/Jrt27oH0Y+9rxosNs0S?=
 =?iso-8859-1?Q?MPSQwbCLweRhcXMHCfAwcYbDD5VdwqPNuNxJNkuVloMCPBrwRXJzovm2Fy?=
 =?iso-8859-1?Q?h9VX3+tnD/1LqHiZD7AJWDrclhnX7P+4Eu7PqjUvfed2vba0NXzc5+iYJ4?=
 =?iso-8859-1?Q?o74zXAUFc5gAGQ/royk/PxdvEjo7M8cvV3NEs79X9fG0kSp6pWYXntLrwv?=
 =?iso-8859-1?Q?qXDR+J/zIY9I2SCO37uZUN6O4ArvuDspx3rbkaLhhNDtKF+Zma+7hJMDfZ?=
 =?iso-8859-1?Q?fW7+nyj0+QMi8YQiGRKaEEi2aG9/ZnuXNtJCStTLqYiHJa5TBugYTWCC0n?=
 =?iso-8859-1?Q?iC3GnMF59qgwqNh7boKdl6sKR37ATTF+9EPysjErMRB599nXFGH5KVgfHl?=
 =?iso-8859-1?Q?mhPOXShctffy2javgHfWaeAHAP8CmH+3ZbWJ/X8YObx/R01uGKFbfQ6+Hi?=
 =?iso-8859-1?Q?3fKMJhI9Wnf1B1m2bj3lEPAtYnkHFESc7dZd36YgCAzdnDKfFbR6LfZgxI?=
 =?iso-8859-1?Q?QMtLxFMKQf5WNQR3V0Pupnu4JARVE/ZfXW2Xvx5apjmA9oTUSnSU1BPTF0?=
 =?iso-8859-1?Q?PTZ5xIThTzouLMc6P9e6EMqI06f2tbv5QGXFHq9nBsWpCBcrFjKRwaBH8P?=
 =?iso-8859-1?Q?bmAcPQzlYI9uBKkNIzeQOOXR3Iaow27DXXT4uwx7lO1AaXcT6daNyD4QGQ?=
 =?iso-8859-1?Q?r18m8hiN7TPr1MHPd4lq5kN6pgWphCuoYkH2ACuNtjw3wBqQBMh6iPUEyf?=
 =?iso-8859-1?Q?WXdUZZ2dHeYGGe1CfoSTWtU3ZFIWxqZzia/egqZ4YtVX6Q/bj2ZlpVep7Q?=
 =?iso-8859-1?Q?eRh6FoK9zmhBQk81OP68Rdz4Zo6EdBYccrEODUEBFUS7e3G1vhprg2BHJf?=
 =?iso-8859-1?Q?8JoM5mjSA4GSv459SydwP8iT7poCFizN4Z4mu+hSgXqhICKUE9BFduBKkW?=
 =?iso-8859-1?Q?H0B1OX899ty+R484UEbOMMr4eE9qgNq7vxtqpD867h3MfRPxyFDtqsDOB+?=
 =?iso-8859-1?Q?bWFqconfVsdmo5yXjB0Q3dMWHQeBusZbdMgqwTA0ECp+LvCgfXtgf0iL4e?=
 =?iso-8859-1?Q?G8FgxE0K+I+QVveUhviYlsAijlBC0o73jC/tLZIduUw+vHYjeMIOqPVpwS?=
 =?iso-8859-1?Q?svTjT6fH9XSqysuoFc3soAUtzHF67VJ7B/?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR03MB6027.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23633fe2-9366-4a28-4b28-08ddf611518e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2025 17:40:39.9085
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oJ+91ZM2pkGbrO616uArnLP9vbA0dx3uKImltOYEdiocVFOw04RBVZpabru/2NHdysVMYHZToV5qtscOiWssIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5656

I also took notes during this session - as usual apologies for any misquote=
s etc:=0A=
=0A=
Christopher Clark (CC): Preparing a collection of docs to understand the pr=
oblem space and what we want to achieve ahead of doing the work=0A=
- List of API/ABIs=0A=
- List of known limitations / issues / concerns with them, indexed back to =
the API/ABIs=0A=
=0A=
Andrew Cooper (AC): Previously tried addressing some of the issues, but add=
ressing only part of it results in a lot of the feedback being "what about =
this other thing?" etc. Designs presented so far fix part/some of the probl=
ems, but not all. Trying this time to identify all the problems before iden=
tifying a design to fix them.=0A=
=0A=
First enumerate the APIs and ABIs that currently exist. Set of problems not=
 apparent when you just think about API/ABIs, e.g. people think it's "just =
hypercalls", but it's not, there's things like enumeration information. Lon=
g history of bugs due to Xen originally being a monorepo and having forks o=
f kernel/qemu etc, so many ABIs not properly defined/enumerated. Also e.g. =
initial state of vCPUs is an ABI. ~46 hypercalls, but around half are speci=
fic to PV guests. Hypercalls are the way they are as Xen started with x86 P=
V guests, HVM guests were created by doing minimal adjustments to PV and th=
us resulted in lots of legacy poor choices (e.g. having to walk the guest p=
age tables).=0A=
=0A=
Other examples:=0A=
- evtchn_send passes a 32-bit pointer to the event channel to use, rather t=
han just the event channel id.=0A=
- hypercalls have a shift by 12 assuming 4k pages, causes problems in ARM=
=0A=
- Changing the version of Xen breaks userspace (intentional choice early on=
, but causes user pain) - unstable ABIs are killing Xen=0A=
- Security patches nominally/officially require rebuilding userspace (inclu=
ding qemu)=0A=
=0A=
This is relevant to work like host UEFI secure boot (introduces new privile=
ge boundary - admin with root in dom0 can't violate the MS defined boundary=
 of not reading/writing arbitrary memory, hypercalls work currently with /d=
ev/xen/privcmd which entirely violates this).=0A=
=0A=
All problems compound, want to look at all of them before figuring out solu=
tions.=0A=
=0A=
Bertrand Marquis (BM): Need to look at problem discussed yesterday - how we=
 create/configure a guest (two ways currently, dom0less and xl), duplicatin=
g code and configuration format etc. If modifying ABI between dom0 and Xen,=
 can we have a coherent format we can use in multiple places to solve probl=
ems like this and prevent duplication / reduce required hypercalls to creat=
e a guest.=0A=
=0A=
Alexander Merrit (AM): Regular applications don't make syscalls directly th=
ey use libraries, is that an option?=0A=
AC: Xen has libraries, but they currently need to be recompiled every time =
Xen changes=0A=
Jan Beulich (JB): This could be solved by having a user library vs the libr=
ary that actually calls into the hypervisor=0A=
AC: Libraries currently all C, would like libraries for other languages tha=
t are stable. Need to consider all these possibilities when designing a sol=
ution.=0A=
=0A=
JB: Concern about taking a global approach - will changing everything in on=
e go mean we never end?=0A=
AC: Idea is to come up with one global design. Parties have specific intere=
sts (e.g. XS around secure boot, Vates for SEV) that will lead to implement=
ation, but we should agree the approach up front rather than having people =
pulling in different directions.=0A=
=0A=
JB: Could we deal with e.g. the hypercall problem up front rather than havi=
ng to redesign everything else at the same time?=0A=
AC: Don't need e.g. function prototypes, but need the broad strokes agreed =
to ensure things don't diverge later on.=0A=
=0A=
AC: Important to ensure backwards compatibility (can't break HVM guests)=0A=
=0A=
AM: Is the problem unique to us, or are there historical references we can =
copy?=0A=
AC: No one problem we've found is unique, but there's enough overlap betwee=
n problems in different areas that we can't take something off the shelf=0A=
BM: Potential problems with lots of compatibility code etc - do we still ne=
ed it? (Room: Yes)=0A=
=0A=
AC/JB/BM: discussion around whether to use physical or virtual addresses fr=
om PV guests. Currently made HVM consistent with PV, should it be the other=
 way round?=0A=
=0A=
Rich Persaud (RP): Unlikely this task can ever be completed, but any work d=
one will be very useful to people after this task has failed. Xen already f=
orked once (Bromium), other hypervisors focusing on specfic verticals etc. =
Xen is last entity standing trying to pull all stakeholders together, uncle=
ar how long this will last, but the products which will last the longest ar=
e certified items, and whatever snapshot is taken at that point will thus b=
e the things which last the longest.=0A=
=0A=
Andrei Smenov (AS): Can Xen and guest negotiate which version to use?=0A=
AC/JB: Not really, can be multiple instances within a guest (bootloader, ke=
rnel, kexec kernels etc). Another example OVMF coming up to do boot service=
s (blkback) load a file then handing over to the kernel etc (can leave shar=
ed info page in a bad state)=0A=
=0A=
AC: Shared info page another problem by itself. Layout done with unsigned l=
ongs which change size between 32 and 64 bit code, so layout of shared info=
 page changes. Different vCPUs can be in 32 or 64 bit mode so we cache the =
mode of the vCPU at the point it makes one of two hypercalls, so final vCPU=
 to crash / go through kexec hypercall will change the format of the page. =
Something we need to address. Whatever we provide must have in mind aspects=
 like this.=0A=


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 18:52:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 18:52:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125510.1467433 (Exim 4.92)
	(envelope-from )
	id 1uyxG3-0002Kh-70; Wed, 17 Sep 2025 18:51:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125510.1467433; Wed, 17 Sep 2025 18: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 1uyxG3-0002Ka-4E; Wed, 17 Sep 2025 18:51:59 +0000
Received: by outflank-mailman (input) for mailman id 1125510;
 Wed, 17 Sep 2025 18: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 1uyxG1-0002KU-Dp
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 18:51:57 +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 618aa995-93f7-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 20:51:55 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by GV2PR03MB8727.eurprd03.prod.outlook.com (2603:10a6:150:7b::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.13; Wed, 17 Sep
 2025 18:51:49 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9115.020; Wed, 17 Sep 2025
 18: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" 
X-Inumbo-ID: 618aa995-93f7-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mOIKz349jGS/wKELwU0khXNNPLXemWlGUulkeGKkZBdR5nFCBSHDhvumWOERln2svwRurSh8B6iMGQqzQIjoSBmVIB1RTvy4bA+YABWMj+LRckUa/ZGh0PxmNWNlYSWgMgX6J74ptrazWeCm9DLrJDg/Y6fzdOj7Wuxa2pCbuh4KlIJwRpYEwygU8N5Ux6yaoD52oVyr3PuOtJyE3ZPECnvVrIYudfQAEP7GeiXkjzadpD1fUhgV95DwxTMeA5+LPC1qwVdixNiC4H/gkdKTyDjxFRUoGdhBk80t4NLuTeWjV2WYF2R6WTgcW90TsQQrYjxgPdZwxgvQYIN86tHKSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5B1mwtcXkpRXJJU4/uGxyVCJHB2Wt/7atY34Xqz/edc=;
 b=BfXt6N3s9EWZpN/Z+SQn8+J1/r9fidRTJlv1C+mu74J01NWm9dOuGdCdCGf1d+YwsTpwc1eZ1pbGACGV87kAC7/G8b/yeCQJyqtdCWZWETpsCGskfTxmJtAv7AnKSujLRkzp8XCk8EV2Q3RypvWu4M7m6KlHnLp/X2mlTMiVPpy4gMkUWSQgwUh1X3glMT/ixzP/TNMUFbjv1gtkKxTpNs0g+4OVtosgIXRkmpBxu1OidjNST6MwthTwRB77jP6ylF+NCph10SCRHGAJGCQVgDduE3f6sxJH73kQizV6+6SqHNZ/TNhYuXz8oVGtyfg9Wsn9yhmBnGdCxHafOsLLbQ==
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=5B1mwtcXkpRXJJU4/uGxyVCJHB2Wt/7atY34Xqz/edc=;
 b=uDHKwIloeK4FuZ4nCE9uPXvQaBJZVU4NG/ADM6xHvxwdbMvvsK3kv6Bp9hVglSagyHdJ1ABhPah/UcELIQebtkGKofZisIm14/lrfsOJv6k3I4+TqOoVMZSaC+edObbAf2ljev4i7lHUfK3LNt4iRMAeKwa7xi+nm6uQSp9IF82dv4C3jMcdDEZ47PhoyZVmsP5Lk+D8YSZiAWA6hvTEJsQcMf1QPhr8dcFWqiVOq7OVLkx8yR6Y68cMqn5T6/m+VLB/uKWMUAV9dSQppVzaWLxmNR7t+FThXy4l+bE8oivEvP1W1RHP0K8y6KCzTT87WMNcs6ZFRnP6nNcgo1taPQ==
From: Dmytro Prokopchuk1 
To: Jan Beulich 
CC: Nicola Vetrini , Doug Goldstein
	, Stefano Stabellini , Andrew
 Cooper , Anthony PERARD
	, Michal Orzel , Julien
 Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Topic: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
Thread-Index:
 AQHcJwfEWjVU7vF+102YDgRq9OEY77SV3fSAgABWKoCAAAe4AIABLJwAgAAEy4CAAEzxAA==
Date: Wed, 17 Sep 2025 18:51:49 +0000
Message-ID: <22bff8a6-b6d8-4002-a6fd-2f5f284e92a7@epam.com>
References:
 <0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454.git.dmytro_prokopchuk1@epam.com>
 
 
 
 
 <8b9d332f-e4f9-4023-b668-8a8957a45e7c@suse.com>
In-Reply-To: <8b9d332f-e4f9-4023-b668-8a8957a45e7c@suse.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: GV2PR03MB9572:EE_|GV2PR03MB8727:EE_
x-ms-office365-filtering-correlation-id: 4353e03c-af82-4755-b6ef-08ddf61b424d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|42112799006|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?OXZITE5manJHYkJSdnJWZFJsS3R3VGtHSTZVRFp6R0VPTjBRMDF4UVVyL0lU?=
 =?utf-8?B?ZEVNRExkc2R1TWtoc2hvQnlseHdYeGYvTUNnck5seld2QUxmaXFwNHNxUmlL?=
 =?utf-8?B?bGNPR3VPMDBlOTRqSWNPZHNQdzdjenFZbWhNc0RGa2NTYkFZRktWRzlyL1BN?=
 =?utf-8?B?eER6dGkwa1d5cnZ6aVdPSCtLbThDK1lGT0QvaG9zcWViYXR5ZytET0d1Z0RD?=
 =?utf-8?B?aEFuTTVNc0ROckUyWUlIYWZ6Z2s4ZmNGUkNSN3c2emdISVJhcjJpcGUzVGFB?=
 =?utf-8?B?N3VXOXVUbDd0aFBXOEF1NG5uREgxRlpjTC9pUnZWb053VTYxd05DZU11b1Nh?=
 =?utf-8?B?bzlhbnpXcThCUnpKamVjRnN0N1NXOFV5dGF6MUVwaCtjdzQ1eHJISmprM05o?=
 =?utf-8?B?USszOFdadjhrbE9wS3l2S3Z5YUVYcTRqL0dXbGpGZTBPeGpML1RFT1RyRTdX?=
 =?utf-8?B?Z1A3dFhtQzRFc0lEakdXSFZ0YlRJOUFrMFUxWnBZdFE3c2pORDZpVXZXUzkz?=
 =?utf-8?B?VXMrWTA0NjRKRTI5cU81VVRGaXlibXdvNVlOMHZReFJ3UEx4eXVmZVF2d00z?=
 =?utf-8?B?TmluNkhyUjdwQWFOV1ltWWhGaW8rdVBkVFBMNStNU0pqYk5wYk85WEJaaWlQ?=
 =?utf-8?B?Myt5ZEJPakNIYjNBN0RsdzR1YUVUTFVTMkt6SE9Gc2JFbkxKQk9Kemtwbks5?=
 =?utf-8?B?anpoUzcvdGpuUWtGOGNLYzk3Q094UmQ0bzFPOCttL2N5a09odkdyekJrV0hQ?=
 =?utf-8?B?d0k2WGJKRHpzVFFQRnk4OTBKRkdRNlpnWVkyVXp5VGFzVjFORHh1S3RtaFRj?=
 =?utf-8?B?L3UxeEwvNXhRcURlNjB2cndIMUlHY1o3OGVoaGVDQ1ljWlJ2cElSWkZpcDg3?=
 =?utf-8?B?ckMxeWNtNU5kMkR6dFZrVUVUaTJKSmRqRkw1bGVrWkcwWTNvdS94akVoNjBy?=
 =?utf-8?B?aEVxQ20rMUgwZ0l6UGtjOXhWZVlnZEpwUUNaSlBTeHBMZlM4Tm4rZnIybGg1?=
 =?utf-8?B?MVBiNmxENisrSTRWVTNaVWliRHVtSEV2c1dIdlhtMFFvYi8rcEVjaFd3dWtu?=
 =?utf-8?B?WkpGZUI0QnEwUTM0N29qT2lWajhFeWduQUdDTGszQ3hXRVkrYmU0ZU9PUkE4?=
 =?utf-8?B?U0RCRE1La2c2NXk3MWpvM3dCSm9CQnhudm15ZDBHQXV6YmNzL3VPc1VSSU1j?=
 =?utf-8?B?ZEEyN0EwN0t2VlhjbVZ6aHRXaHFzL0wzWXdWUk9yUE9DaWhTaWdPNmhMZ3E2?=
 =?utf-8?B?SFJIOEVldU1BTWpIeEdwSGt5ODRBYzdSTXBBclZqVFppdkJiMGlnWjNDM2o0?=
 =?utf-8?B?UXpHV2JmNDd5TDcwa3hVK3FJM0UraWpCRmJyZmt0N3llaEg2NW1ySjYwQXdS?=
 =?utf-8?B?emVqaCtVeVV3R1k3eE5adWFjdWtXcVkzWHE2MFE4N2dENlJVWEJBVlJvYnlr?=
 =?utf-8?B?c0xxM2cwQklRRkViUExULzU0OFFLV1UxODBzZHV3dWQ4ZkNMSmdCUnE0SEJM?=
 =?utf-8?B?NFRXS1NWUmtIMmRCQlg1bE84UlFJRTVKcHBuY29aVVc3dmlaRjQ0MTVnTVov?=
 =?utf-8?B?M3QzRThwRmRPYkplNzVvV1VOWUpzWEFZUWo3ZUlQZmVnNXlCUDUyblF1MFQz?=
 =?utf-8?B?YTdUWkZucHRwU25ZVS9TRkpSUGZrSlJIb2tDSVV1VHFWQ01IbkZrMURqNjZp?=
 =?utf-8?B?NlJDUUZwc2xoVlVBS1crTk5oVHpJY2c4K0NsT1pybHhmUk1ZemR3STBUbENZ?=
 =?utf-8?B?MVBLWlE5M2hkTElnWFA3SkZQMmVNbms4T0xnN0h1Qk1PVklDS3lJeWlMQm9w?=
 =?utf-8?B?bnlhMjcwczAvRk9FMGlyMDM1TVU4WWJacnZUMHZpaGY5WDliTzh1U1RHWGRB?=
 =?utf-8?B?UGQxTXVadW9jL29OdldJcEFIbHNFRSs3cEdUcFBud2dLTncyVU51RGZ2M09W?=
 =?utf-8?B?cjVXUjRJcGN3T0ZQWjdja0dsYTBYZUtYV3BOTWo2MzByVFNyRFBoV2wwdVFk?=
 =?utf-8?Q?NIPDX0+UoJiGCV06E2etUM4clrAZic=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(42112799006)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?YzVIL00wM2NBa1Ivbzc3dzNIcm5BNXVIRXlFZ2NwK1JCaGZodk1wcUNmUlhY?=
 =?utf-8?B?a1pGZUNjMWZyWlE3b0J1YkNSeDRZQUhHcDBOZXYyaXBWWlJFeDYxcEE0Z2hD?=
 =?utf-8?B?UXJEU3FmcDMwbTBsTm9MWHgzdUF1dFF1RWVwbExYeGpvcnBseG1LcHI3amt2?=
 =?utf-8?B?NHpqL1VUSlMvMmI5cVBRcDRWcmFvUDVJQWJZai9xMEJrMGdDTWRHV1hCdFVC?=
 =?utf-8?B?ZVFBRWQ5UzkyR09jL2NiZlcyak5mc28yY01UQUxOQzdzQ082S0tBWG5hTk5Z?=
 =?utf-8?B?eUFBRnBNakhQcDRhbTBYTDI3dUJQWFpsWlVmdjZNZk1aMU1PaGRYVnZmcGt3?=
 =?utf-8?B?N29UTm9sTlBiRUNzbEtLSUZKcEcvenlabCtDSjlTcGlHMHBTNzdKb1p6bnVW?=
 =?utf-8?B?Tmh3MzJONUFuWHFLOWtlNzhXYlpaVE15SjVFYTByRWRwL3hDMndSWTkyTXRX?=
 =?utf-8?B?Y3d2TXoxbjYxaExtczcvdWY2NTcvL1lnakNvSHJTR2RaUWdhQzJoSk0zTHlS?=
 =?utf-8?B?Nk5qRUUxTEhhSTNNOW4xUTN2YlVQc0lJb21LbEprMDZNekNpRjRqVUoyZmRJ?=
 =?utf-8?B?VnpXQ3BtYWlhYlg0WmsyQ29EVGVQVmE3R3UrcHFpU3M3ZFBxM21NdVMxdkFh?=
 =?utf-8?B?WVZtSUx1bVc0WGFibmd4OE1YakNCUm1GZDBnR3c1QlY4OFB1bW5RSnE1Vzht?=
 =?utf-8?B?UDJLYVNkdmRoQ25rTitVUTBvMk9OZC93dGppQkJUU2RkeWJKQTc4ekVNQnhH?=
 =?utf-8?B?dWJFOVBFTkE5c044RVNkYVBzeUkxcVQzWHo3LzREeTkwNlR5RXl3VmdMakFE?=
 =?utf-8?B?Y1VySCsxSUZ1RTBsb0xwOG1teXc2VVpiZXhwdFpiSVozRjBLbEFDR0ZQcllq?=
 =?utf-8?B?d3d5K0ZOaXIxSElETG12bmlEUndaVzltRE5mMVdVZkpkSW9JRThGMjg0M0E3?=
 =?utf-8?B?OGJzQ1VKMUNXejRQekVsaEJOa01MaTZwYm1kR1BqNHZRc2RSdUUwZWU1N2N2?=
 =?utf-8?B?ZXhjZHQwVHR4S1M0eXcvY001VG53eG04UTJ4bDQ1UWFuSFladXlQTklncFAr?=
 =?utf-8?B?WGJwcTFsbldiTXJMT2pISmNvZnJTUXh0ZFZkVWJrUW53WFhsbWZacG1GYXox?=
 =?utf-8?B?Y1BCc29WRVZiMUFyVFlnWG9nNi9FakNtNHJiUXpLSHFHOUxLdkFwQmhrbGgw?=
 =?utf-8?B?dzVIRDRMSG92elNqcm9nTzdDSDQyc3FIUExpbUUwYTZSUWJGelAxa3hJWGxG?=
 =?utf-8?B?Z1pSRWs3MVoxd2s4MnF6cDZsNWRlcUovbTFRa1orQnBvdlBYY1E4N055VW4v?=
 =?utf-8?B?LzJZR2swQTFYYXB6dk82VUE4THlzaFhBSEZlNGFValpaWS9pMjRGQTNqVk5t?=
 =?utf-8?B?RTZETjFMZWxMUWxHZEpkTStiQmF4citxeExteHhGWFpGZ3planlaWnhhcFlk?=
 =?utf-8?B?amVla0tqT21Hcm41WjNDN3FlWkxFditta01VUWF0cE1mNTN6WTZPZnp3UHJR?=
 =?utf-8?B?aFZPYVZtVXRyQUdGV2x5eklZK3lNZ0VscWFDZlVrWktwSWlrcjI5UTRCMXlY?=
 =?utf-8?B?MGl1VlQ0ZXhsei9INzc5MG1LeWlsRWpTRjV4NERrMzZtdHBDWmxKZUVrenRt?=
 =?utf-8?B?RW1pTmJrNVBmdldjdWUxUDBVYnlyZy81NlBDNUh5ZjRBLzFrYVpLOXEzYzRD?=
 =?utf-8?B?YXVEUFl6UEtLN2lxWjR0dHMvaXpobGhiWDM5MDVBZzA0bVJUeHJkd1ZOYU5k?=
 =?utf-8?B?MEF3c3FWOEpmS1FuTHE2cmF2U2F6SWpWZDVWaDlVcDFtZmVreERkbXZvdmxF?=
 =?utf-8?B?ejdNNDQ1MjJnenJGOTJGdFJWOTZhcis1MHZxSVpseUpMdzBVYjk3TTNuTVhJ?=
 =?utf-8?B?SU1tT3NwdnFDbit5ektKekhydWtwdW9nU0NoQlpjdEVQZjVvUDliY09Bc0Iz?=
 =?utf-8?B?cjRuc3hYVERvRjhodm82cUxCV0NxdUZLRkM5Y2NSWU9Yd2ZMMWlLUlVQeGpY?=
 =?utf-8?B?bm5IbUtNa2Y0UzFLT1NZWGdTZUR5d1pjOENUOTVoT1lzd0owKzNwMjduaE9w?=
 =?utf-8?B?OEZHR29ITy8xRnNlb2tOUllxaTRlb2ZyZWhRbDJZVi9PYnZtbGliU2xqZWZB?=
 =?utf-8?B?dVJTVHNoMGcySVdKMjdTdmJLeGdobXBrc3pRV0FoV1l1Y3dVb21MdlZMcjBa?=
 =?utf-8?B?cnc9PQ==?=
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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4353e03c-af82-4755-b6ef-08ddf61b424d
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2025 18:51:49.3392
 (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: mequ41i1p0WGE8alFWogNCplwnZEHLce+CcTL+0vFD2wm9NuRgqJdpES/zw1kBTiHJC1gywggPp54hxXwD7vEvzW6CN3nx76uHk2LwXuA+g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8727

DQoNCk9uIDkvMTcvMjUgMTc6MTYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4wOS4yMDI1
IDE1OjU5LCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+Pg0KPj4NCj4+IE9uIDkvMTYvMjUg
MjM6MDMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE2LjA5LjIwMjUgMjE6MzUsIERteXRy
byBQcm9rb3BjaHVrMSB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gOS8xNi8yNSAxNzoyNywg
SmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAxNi4wOS4yMDI1IDE0OjQ1LCBEbXl0cm8gUHJv
a29wY2h1azEgd3JvdGU6DQo+Pj4+Pj4gLS0tIGEvZG9jcy9taXNyYS9kZXZpYXRpb25zLnJzdA0K
Pj4+Pj4+ICsrKyBiL2RvY3MvbWlzcmEvZGV2aWF0aW9ucy5yc3QNCj4+Pj4+PiBAQCAtOTgsNiAr
OTgsMjMgQEAgRGV2aWF0aW9ucyByZWxhdGVkIHRvIE1JU1JBIEM6MjAxMiBSdWxlczoNCj4+Pj4+
PiAgICAgICAgICAgIGV2ZW4gd2hlbiBkZWJ1Zy1vbmx5IGFzc2VydGlvbnMgbGlrZSBgQVNTRVJU
X1VOUkVBQ0hBQkxFKClgIGFyZSByZW1vdmVkLg0KPj4+Pj4+ICAgICAgICAgIC0gRUNMQUlSIGhh
cyBiZWVuIGNvbmZpZ3VyZWQgdG8gaWdub3JlIHRob3NlIHN0YXRlbWVudHMuDQo+Pj4+Pj4NCj4+
Pj4+PiArICAgKiAtIFIyLjENCj4+Pj4+PiArICAgICAtIEluIHRoZSBzcGVjaWZpYyBidWlsZCBj
b25maWd1cmF0aW9uICh3aGVuIHRoZSBjb25maWcgQ09ORklHX0FDUEkgaXMgbm90DQo+Pj4+Pj4g
KyAgICAgICBkZWZpbmVkKSB0aGUgJ0JVRygpJyBtYWNybyBpcyBpbnRlbnRpb25hbGx5IHVzZWQg
aW4gdGhlICdwcmVwYXJlX2FjcGkoKScNCj4+Pj4+PiArICAgICAgIGZ1bmN0aW9uIGluIHRoZSBo
ZWFkZXIgZmlsZSAneGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2RvbWFpbl9idWlsZC5oJw0KPj4+
Pj4+ICsgICAgICAgZGVmaW5lZCBhcyAnc3RhdGljIGlubGluZScgdG8gdHJpZ2dlciBhIHJ1bnRp
bWUgZXJyb3IgaWYgQUNQSS1yZWxhdGVkDQo+Pj4+Pj4gKyAgICAgICBmZWF0dXJlcyBhcmUgdXNl
ZCBpbmNvcnJlY3RseS4NCj4+Pj4+PiArICAgICAtIFRhZ2dlZCBhcyBgZGVsaWJlcmF0ZWAgZm9y
IEVDTEFJUi4NCj4+Pj4+DQo+Pj4+PiBJIHJlc3BvbnNlIHRvIG1lIG91dGxpbmluZyBhIGRldmlh
dGlvbi1sZXNzIGFsdGVybmF0aXZlIHlvdSB0cmllZCBpdCBvdXQNCj4+Pj4+IGFuZCBzYWlkIGl0
IHdvcmtzLiBUaGVuIHdoeSBpcyB0aGUgZGV2aWF0aW9uIHN0aWxsIGJlaW5nIHB1dCBpbiBwbGFj
ZT8NCj4+Pj4NCj4+Pj4gWWVzLCB0aGF0J3MgdHJ1ZS4NCj4+Pj4gSSBzdGFydGVkIHdpdGggdGhh
dCBwcmVwYXJlX2FjcGkoKSBmdW5jdGlvbiBhbmQgSSB0cmllZCB0byBtb3ZlIGl0IGludG8NCj4+
Pj4geGVuL2luY2x1ZGUveGVuL2FjcGkuaCBoZWFkZXIgZmlsZSB1bmRlciBhcHByb3ByaWF0ZSAj
aWZkZWY6DQo+Pj4+IGh0dHBzOi8vZ2l0bGFiLmNvbS94ZW4tcHJvamVjdC9wZW9wbGUvZGltYXBy
a3A0ay94ZW4vLS9jb21taXQvZDE1Y2Y5MWRlOTJmMWY4ZWM2NzkxMWM1MWExM2U3ZjA5NWMxYmNk
ZA0KPj4+DQo+Pj4gQnV0IGFuIGltcG9ydGFudCBwYXJ0IG9mIG15IHByb3Bvc2FsIHdhcyB0byBo
YXZlIG5vICNpZmRlZiBhcm91bmQNCj4+PiB0aGUgZGVjbGFyYXRpb24sIGlpcmMuIFdpdGggdGhh
dCwgbm8gdmlvbGF0aW9uIHNob3VsZCByZXN1bHQuDQo+PiBJIGRvbid0IHVuZGVyc3RhbmQsIGhv
dyBpdCBjYW4gaGVscCB0byBhdm9pZCBzY2FubmluZyBieSB0aGUgRWNsYWlyPw0KPg0KPiBJIGRp
ZG4ndCBzYXkgaXQgd291bGQuIFNjYW5uaW5nIHdpbGwgYWx3YXlzIGhhcHBlbi4gVGhlIHF1ZXN0
aW9uIGlzDQo+IHdoZXRoZXIgRWNsYWlyIHdvdWxkIGZsYWcgYW55dGhpbmcuDQo+DQo+PiBJbiBw
YXJ0aWN1bGFyIGJ1aWxkIGNvbmZpZ3VyYXRpb24gdGhlICJzdGF0aWMgaW5saW5lIiB2ZXJzaW9u
IG9mIHRoZQ0KPj4gZnVuY3Rpb24gd2lsbCBiZSBwcmVzZW50IGFmdGVyIHByZXByb2NjZXNvciwg
YW5kIEVjbGFpciB3aWxsIHNjYW4gaXQuDQo+Pg0KPj4gSmFuLCBwbGVhc2UsIGV4cGxhaW4geW91
ciB0aG91Z2h0LiBJIHRoaW5rLCBJIG1pc3NlZCBzb21ldGhpbmcuDQo+DQo+IElmIGFjcGlfZGlz
YWJsZWQgaXMgY29tcGlsZS10aW1lLWNvbnN0YW50IGZhbHNlLCBhbGwgeW91IG5lZWQgaXMgYQ0K
PiBkZWNsYXJhdGlvbiBmb3IgcHJlcGFyZV9hY3BpKCkuIFRoZSBjYWxsIHRvIGl0IHdpbGwgdGhl
biBiZSBEQ0UtZWQuDQo+IE5vIGlubGluZSBmdW5jdGlvbiwgbm8gI2lmZGVmLCBubyB2aW9sYXRp
b24uDQo+DQo+IEphbg0KDQpZZWFoLi4uIFRoZSBrZXkgd29yZHMgd2VyZSAiTm8gaW5saW5lIGZ1
bmN0aW9uIi4gTm93IGl0J3MgY2xlYXIgdG8gbWUuDQpBbmQgaXQgd29ya3MgZmluZSBmb3IgdGhl
ICdwcmVwYXJlX2FjcGkoKScgYW5kDQonZ2ljdjNfaXRzX3NldHVwX2NvbGxlY3Rpb24oKScgZnVu
Y3Rpb25zLg0KTm8gaW5saW5lIGZ1bmN0aW9ucyAtPiBubyB2aW9sYXRpb25zLiBUaGUgRWNsYWly
IGlzIGhhcHB5Lg0KSW5zdGVhZCBvZiBydW50aW1lIGNoZWNraW5nIHdlJ3ZlIGdvdCBjb21waWxl
LXRpbWUgY2hlY2tpbmcgb2YgdGhlDQpmdW5jdGlvbnMgaW52YWxpZCB1c2FnZS4gT3JpZ2luYWwg
aWRlYSBpcyBwcmVzZXJ2ZWQuDQoNClVuZm9ydHVuYXRlbHksIHRoZSBmdW5jdGlvbiAnZ2ljdjNf
ZG9fTFBJKCknIGRvZXNuJ3QgaGF2ZSBhDQpjb21waWxlLXRpbWUtY29uc3RhbnQgZ3VhcmQgYXJv
dW5kIGl0LiBGdXJ0aGVybW9yZSwgaXQncyBhc3NpZ25lZCB0byB0aGUNCmNhbGxiYWNrIHBvaW50
ZXI6DQoNCiAgICAgLmRvX0xQSSAgICAgICAgICAgICAgPSBnaWN2M19kb19MUEksDQoNCkl0J3Mg
cG9zc2libGUgdG8gcmVtb3ZlIGlubGluZSB2YXJpYW50IG9mIHRoaXMgZnVuY3Rpb24sDQpwdXQg
dGhlIGZvbGxvd2luZyBjb2RlIGluc2lkZSAjaWZkZWYNCg0KICAgICAjaWZkZWYgQ09ORklHX0hB
U19JVFMNCiAgICAgICAgIC5kb19MUEkgICAgICAgICAgICAgID0gZ2ljdjNfZG9fTFBJLA0KICAg
ICAjZW5kaWYNCg0KYW5kIGNoZWNrIGNhbGxiYWNrIHBvaW50ZXIgbGF0ZXINCg0KICAgICBpZiAo
IGdpY19od19vcHMtPmRvX0xQSSApDQogICAgICAgICBnaWNfaHdfb3BzLT5kb19MUEkoaXJxKTsN
Cg0KQnV0IHdlIHdpbGwgbG9zdCB0aGUgb3JpZ2luYWwgaWRlYSAoSSBtZWFuIGhhdmluZyBjaGVj
a2luZyBtZWNoYW5pc206DQpydW50aW1lIG9yIGNvbXBpbGUtdGltZSkuDQoNCklmIHlvdSBoYXZl
IHNvbWUgaWRlYXMsIHBsZWFzZSBsZXQgbWUga25vdy4NCk90aGVyd2lzZSwgU0FGIGNvbW1lbnQg
c2hvdWxkIGJlIGNyZWF0ZWQgdGhlcmUuDQoNClRoYW5rcywNCkRteXRyby4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 19:08:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 19:08:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125523.1467442 (Exim 4.92)
	(envelope-from )
	id 1uyxWN-00049e-Ia; Wed, 17 Sep 2025 19:08:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125523.1467442; Wed, 17 Sep 2025 19: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 1uyxWN-00049X-Fi; Wed, 17 Sep 2025 19:08:51 +0000
Received: by outflank-mailman (input) for mailman id 1125523;
 Wed, 17 Sep 2025 19:08: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 1uyxWM-00049R-AY
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 19:08:50 +0000
Received: from CO1PR03CU002.outbound.protection.outlook.com
 (mail-westus2azlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c005::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd2738d6-93f9-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 21:08:49 +0200 (CEST)
Received: from BN9PR03MB6027.namprd03.prod.outlook.com (2603:10b6:408:118::7)
 by BY5PR03MB5348.namprd03.prod.outlook.com (2603:10b6:a03:21b::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.13; Wed, 17 Sep
 2025 19:08:44 +0000
Received: from BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779]) by BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779%6]) with mapi id 15.20.9137.012; Wed, 17 Sep 2025
 19:08: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: bd2738d6-93f9-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QYNpJpnc1dOAn1NXZkPCqMbsu3sb6oj2q2pJEQdvMkrK+AbmD2sC/U4ZATuo46AqRAG02gKljg7DXul61h+/suvJLUgg0P7DVnwoBHPd1VIKjn/wbYmf/sF9UMu71coAIOv47jj5Pz1g7XX+q5h8aZu0Sy6s8EcCMtgFS/fQxf9cENWEgI3XbSOkMYvjLukJ0CJJzuYvvZ89J1czXmnHj0jpyPJAep27Y919BDRkfqPIpW69DryDhc7qHqcH60O/+6txXeQ4cyFTGuGUGMKJGjGeEh1idAStPBoTkf6OZ+BsCSpIrRzYKXZ3qD09syyZIvODeEZIQ5dK9EqPyxk+jw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zfKvfNAc8fLC1ydjV2eD6mMlDM7z/rK57aEeTe5nO+k=;
 b=K7T8XP3g+6JoK7J9JhNfrTYWcnt6f0LV/a9yiOngiPCaSW6LkmgGxldvpCrVqjaEGOTF4kp0QCdF6eKCKsvbepVbKD/uW3S9n7wm/LgHxlPNo5M+gjP9qjjHGrXTl0YR0aEYJMGjlLcuS8Y37fqO8x0D7YO6IhpdeYp/GRD48WvqMplRXjtOQeyIHQt5J+ZhTMjXR2K+ggSc8rSBu+K6Iz32FBgDMtB2oUoiiabmoM9ryvXBAkWVSCduQMVNo49aSE5LEW1iMv8uoZenJIR0bapJCB7TbettrhlcRv8W3UivKUpxM2BJdNeqF0xinXewyraQodEKzcnSyJUQbI4bkg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zfKvfNAc8fLC1ydjV2eD6mMlDM7z/rK57aEeTe5nO+k=;
 b=ksVnP+7j9dj489UjdyH4lBhk+19yhLIxOdD2zUbFhCaSTi87sdnlA+aYPPtxyo3woD5rf3KZSDTp9B3/bG0T/sl+TFEvWFZgEkwF/5zm8ZYW2QDrKCRJqPNZooXaAteOxGVz4e9tmXoNKMm6aFCGpz+qsCgaL2TvaiW5npMfQek=
From: Alex Brett 
To: "xen-devel@lists.xenproject.org" 
Subject: Xen Summit 2025 - "Follow up Xen Toolstack new design proposal"
 design session notes
Thread-Topic: Xen Summit 2025 - "Follow up Xen Toolstack new design proposal"
 design session notes
Thread-Index: AQHcKAYj0uX1loOt8k++R8JgP7PhVw==
Date: Wed, 17 Sep 2025 19:08:44 +0000
Message-ID:
 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN9PR03MB6027:EE_|BY5PR03MB5348:EE_
x-ms-office365-filtering-correlation-id: a3f8811e-104d-42b6-64f3-08ddf61d9f84
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|3613699012|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?KmIul7mJRMfyDYTSKxGjkySYwr93hNOFXwY5u4lS+IuMbkMk1/19rXP8xg?=
 =?iso-8859-1?Q?UqxfAAyPT+h76ZD+6SjNEPZWuXCY9Frfsc27+oelmYC2PyLGsOI8iFOR1x?=
 =?iso-8859-1?Q?1+GP/PkLmB7grdUlgq3PEp5xklf2WEwZ+RWwrWdEGjyklZZA54sRSPt22s?=
 =?iso-8859-1?Q?YzOPzY5cmfM1q7EwEDgTHARFp033OUUlSwqWlBDEVYKe7B2SITncM+bGJ7?=
 =?iso-8859-1?Q?A9DYGrY2fac8DGBGgbdPMUnXEg2DXTVviak4yb0nM7pqRgm+xnekfkBjfP?=
 =?iso-8859-1?Q?zviY5oHh9QIPW910gCIC7aocZng4Grz7UDtwjUcKPAJlRde2SBzIYeBVgB?=
 =?iso-8859-1?Q?nnWq3NaZdZlCZEo/HvyWr8tOJETmpgyC7lOGcy0Ke6vXLNj+qILLBXip6V?=
 =?iso-8859-1?Q?fgUMjfjeEssHz55VgenQ8E182M4mfDG5qiBbGpyOINxUYhG6n2tXcN8w4/?=
 =?iso-8859-1?Q?E3v7mCBzQtpAUpYDG+d6eFhyVOVcY0H5O7jFW+YMt7EejLNKtFTKFNXoIP?=
 =?iso-8859-1?Q?RevoUQgcrEDHM//jsw7A4mGQMf62HNW7K3n0nGJA4vyUszxHpowVAqFJZB?=
 =?iso-8859-1?Q?eCr7SrRL3Dr4SgMLVTk6NBxnA2kdV0ElXYNzu5IvR9TFQUeY04EvdYQpER?=
 =?iso-8859-1?Q?sNwD+M+EQJKDhimGKuWbNPbgF22HQB+YrbX6q8XznhDjWz6BGvD47l4maL?=
 =?iso-8859-1?Q?/ceNtOz22Hvosr4D6YR2pq6Smc9G0Rn3r2puxO8CcQhOhHh2Y1ZNGeItqv?=
 =?iso-8859-1?Q?HkSS1t2bAIYD+X3Q4/C2K94SQDvZh/bWvWhUJ8iq3ZrcZ8TzZ5VgJMgkES?=
 =?iso-8859-1?Q?JtIh/8fxJ7U1MbbHnwnD5X/BA4NxWAlBMpgL2kK6mUlZTn4GQvT+lo1PRM?=
 =?iso-8859-1?Q?B4L0nHl6UoDdNNW4fRA7fieRbgrYxs8wx17voDhyDVObCPMmymdAlrTdKa?=
 =?iso-8859-1?Q?U79PrGC8PXmZm9sSO/YSh+eoemAhteZ0V9lxxG1MaDmWKVVjurOL+O/nPv?=
 =?iso-8859-1?Q?ywbKCo40VcNNtmLlRhEZ+w4zhOQmD+DQ6M/iG0kyIkkRmFW66NHGVUv/MC?=
 =?iso-8859-1?Q?fDXOCu+ufdp3cyYA3k551nXYO+i4VRHXI0exFg4jNv9BlYxTpsqpjhoXrF?=
 =?iso-8859-1?Q?RMLL6BI6D3ZzU2/FzLvb08q6+SO9bUM559n89kKi33yeL7OtQEliRvaefP?=
 =?iso-8859-1?Q?fH6/XMNLl+kJDwOlvRA9ibdj5Ness2UxJ22M6NMjbYEfQs5iTXtR0lZKJz?=
 =?iso-8859-1?Q?Cgmd+ONeIs03/sCCw0fb7ZvNovt8jM1YkRGlX34/ttlKQS3VwJYlTrDlcB?=
 =?iso-8859-1?Q?QBLzB0arKDmcbs6rKQrA0Elyx1AmWC6MGh5rC5yOEEvWNJPUduw4tbBObl?=
 =?iso-8859-1?Q?0BRyxfUc2P6Idvw3h0sTZs3+4IUzURlgVpqnDTEerJOjpptT55uTpg9DJk?=
 =?iso-8859-1?Q?zbhRpdoCmbDMeK8dAdg3CYLW/XwoRvjhjD1YgfGqPdIj/ZMFxNgrr1caoU?=
 =?iso-8859-1?Q?RIaue24JDOu71dRziCCo8vsnGJ9CEW8DSoQ+q6+/zLguwCzE4zvU3Qhur+?=
 =?iso-8859-1?Q?jYTZyRPnFmpeU8lM51+smxxnBuRF?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR03MB6027.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(3613699012)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?SCOICpi+BSvm0+5We5guQBNhNdt1Cmyf6A7n5zmsPZ/NMWJsz6lGy/Kk1b?=
 =?iso-8859-1?Q?KejB7GIbpoX3NiitMp6CIULcmQZr/ExdNEP3KkiXptp9oDH15vctV02nSt?=
 =?iso-8859-1?Q?M2VHMumEhGqgO/Ke0sap1nTXzKfd2UheAPZmics1Us0S8v5o56+B+ea6nQ?=
 =?iso-8859-1?Q?cf6woNwt0CqVG70FZUZ8JVUefns0VO7GxonMo2trnDpCm5iyixECstof0I?=
 =?iso-8859-1?Q?Vdgh7hodHNdNQWwWonvRlMGi3mUNoG8fqAHFktJKEw/TpDVxFWcRdE/x5D?=
 =?iso-8859-1?Q?4mme4cSKFBIjsTlOuuISvrKfd0A95gwQvIZzH/tXTBHO/0Hrw0C6uQk6Og?=
 =?iso-8859-1?Q?/Kf6vS838XH4ky+yHlhkm3yh0jszVnBpTf07R8C3wWirqf3ZcXZQIm1kH+?=
 =?iso-8859-1?Q?McCJLm0UdAe/z28OX02wGlKUgUbCMS/6f6XsTgJ+pJQMBQFUX1QsNhNNeY?=
 =?iso-8859-1?Q?4yOiRbC9I+a48lancz165kKn1CDWLMtJZQWrcPc6pFqye9UQhAV4DiOM8g?=
 =?iso-8859-1?Q?ymyL6SyFEQ820geywyWGfsUsk2lVW+6XdKMo0jqcLRpz0RHJbpdCOxBeKh?=
 =?iso-8859-1?Q?b9lFCOb7aCgLcYV2+prV0n5NJOM+yX1uy7IlBHMqyergWvCpILVrVJZOls?=
 =?iso-8859-1?Q?evRy6Fe9pRzfEPYAY/8qIqAwDBVHiuZ61qvj9e7r4/HQVXn2s8fvFr9YYq?=
 =?iso-8859-1?Q?JEKWBImbFyYuqq2UMwvR9kKCBFfv6FrZZSJek9w57i/STukHJCaW2DIkUU?=
 =?iso-8859-1?Q?VypKQK+M4ELLkCnLiCOmcEWIN/+clBtz1IHbKPMYtQ8gz8zooA5LP7bB/n?=
 =?iso-8859-1?Q?0Auw2ekMg+NsB0ONG4npZAcB2p+AMFMUluhDuZ6mya0Q9IlxnPH19cA6N6?=
 =?iso-8859-1?Q?dTTTTkCln/XE3cqoX4o2nYFjBsFt+ekkn8al4X+owWNPLlxklm6QcBlP9N?=
 =?iso-8859-1?Q?XVh9PU+SnZbn9y/lA/dujcqZoNDRoKV7DlMjS0QeiPITEOFdK2/coY01Lm?=
 =?iso-8859-1?Q?AIFP0HLDXBacXyq0IEJnSkrD8XUle8hYb+P6zivA9E9vPrsewsTR9fS80q?=
 =?iso-8859-1?Q?gaWpGaw4eR28Rh6btNlucvDTNgLQF3mUC3/e5Eqn+iR4eD14gpwHUMw0p7?=
 =?iso-8859-1?Q?S6xUePesW/Kmq9uZvMCykiriANoTtAek6abEb2ucistBFkW6yUa1okmWKX?=
 =?iso-8859-1?Q?4blkPNunKeoGTtgZAdASFiMaQ5idQaw4LLnnFZ/2AMT+xif85YCetwNF2+?=
 =?iso-8859-1?Q?vrV0hQ9vdMs/telp4hUJazLoCd8y58JHw3lsVeu7zPj477Xv0XXLdvC394?=
 =?iso-8859-1?Q?UJUQlhBSqbLgcL3b27X1/HZU553z/uxlG6KUXFrP5uhvB3u7QYGQ2ujpwx?=
 =?iso-8859-1?Q?UM2A5EObVZRtXnr2/N1j392CO1p7sMa0DEkTr/1+rL4U1kZB3YzpaDdvjT?=
 =?iso-8859-1?Q?CfJHXma0MDnvRrrOhHkV/V3vPgBs0+iMx/R1wyq3iWWCCOqkxuuVp3BG0I?=
 =?iso-8859-1?Q?o/fBbAHKs8mb2iXVMF27r09SCDmHP/gXusaju0lUA6C7p6Kn8bpD4JKHp4?=
 =?iso-8859-1?Q?2nZ/MO2yxJTHRHwtY7N6JR8xaP1y5hW0LGzh6W1PuCGjLvcTv0FhQVjj/m?=
 =?iso-8859-1?Q?h1Mym/cBuHkRayTrkkCZ+lBW1NuNVa2vl0?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR03MB6027.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3f8811e-104d-42b6-64f3-08ddf61d9f84
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2025 19:08:44.6640
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cxQUcNeDPcBfpO6sJeCLjA5EPdxKehjU4iaCTkSEdQi/jvH2QTJ3AQSYhIxpJOYf7Zqhziz9vQUyMh+uRxUfrw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5348

Using device tree to describe a guest=0A=
=0A=
Stefano Stabellini (SS): We're not stuck to the existing format, we can cha=
nge it if needed. The value is in having a common interface, not the curren=
t implementation.=0A=
=0A=
Daniel Smith (DS): Burden goes on to the toolstack to have to have the libr=
ary.=0A=
Alejandro Vallejo (AV): Don't have to use the library, compilers can do it.=
=0A=
=0A=
SS: Userspace not an issue, plenty of tools existing=0A=
=0A=
Andrew Cooper (AC): At the moment we have a bunch of hypercalls, some long =
running some short running. Xen doesn't have a model where one single threa=
d can run something for a minute (important for things like interrupt deliv=
ery etc). At boot we don't turn on this checking, but reusing hyperlaunch s=
tuff when VMs are already running can't be the same code as used at boot, a=
s you'd need e.g. hypercall check continuation at a minimum.=0A=
=0A=
AC: At the point you have a hypercall with a DTB blob, you can't take a min=
ute of time processing it.=0A=
=0A=
SS/Roger Pau Monne (RPM): Long running part is populating the p2m. Also iss=
ues around PCI reset (spec mandated).=0A=
=0A=
AC: At the moment domain create is reasonably long and can't be continued (=
as continuation needs to hang off a struct domain). Minimum amount which ne=
eds doing before you can start continuations.=0A=
=0A=
AC: Hypercall continuations are holding a vcpu hostage.=0A=
=0A=
SS: Could we have a different continuation? e.g. domain shutdown has a sequ=
ence of ~10 steps, and you remember which step you're in. Could have a sequ=
ence of steps on create that returns 'done step 1' etc.=0A=
=0A=
DS: Can we look at what is the minimal stuff to get to a struct domain, and=
 modify the logic so this is as short/atomic as possible so we can then get=
 to continuations quickly?=0A=
=0A=
AC: Currently lots gets done before you make the domain visible (e.g. max C=
PUs and event channels where Xen will expect structures to exist at the poi=
nt it can enumerate the domain), so we might end up having to make lots of =
other modifications.=0A=
=0A=
SS: Could still do the step thing, just need to make sure the step to get t=
o a struct domain is quick enough to not need a continuation.=0A=
=0A=
DS: Could we put a flag in struct domain that says "I'm in progress".=0A=
AC: Every single code path that enumerates domains would need modifications=
. Or maybe you make lookup return null but you'll still then need a special=
 call for the genuine case.=0A=
RPM: Similar to is_dieing flag. Could we reuse that?=0A=
=0A=
RPM: We should first try the simple way and see how long it takes, it may b=
e fast enough.=0A=
=0A=
AC: In a security issue we were forced to start allocating the p2m (limited=
 to 256 pages). This is allocating and zeroing memory - this is the kind of=
 thing which really needs to be in a continuation (RPM: Or not done there a=
t all).=0A=
=0A=
AC: If we can split it into the minimal set and then a huge bunch of work u=
sing continuations that might be OK.=0A=
SS: We don't need to be religious that it has to be one call, but today we =
have a dozen and it's not clear about the ordering etc, so going down to on=
e or two is still good.=0A=
AC: If you make it two there's a way to screw it up, but if the first set c=
an get to a point it's safe to do continuations, you just keep on continuin=
g until it comes back success or fail.=0A=
=0A=
DS: This would be a new call. What if we want to do it in __init.=0A=
SS: Had a request to trim Xen down for security - started KConfig'ing thing=
s off, but clear we need to do something about __init.=0A=
=0A=
RPM/SS: Clarified there are people who will use dom0less and want to remove=
 the new call. But dom0less people will still want to have __init, so you c=
an't take this code out if it's used in both places.=0A=
=0A=
AC: Works if you have a binary choice if you want to keep it at runtime or =
not, but when you have 2/3 choices it doesn't.=0A=
=0A=
SS: Safety will want the smallest possible amount of code, will want to KCo=
nfig things out. Can't KConfig out this code (as it'll break dom0less), so =
it needs to remain for init. Will still therefore need certifying anyway as=
 stuff in init has to be certified, so not a massive issue.=0A=
=0A=
DS: We're putting a lightweight toolstack inside the hypervisor for hyperla=
unch - currently OK as this is only used at boot, but if you leave it there=
 at runtime some people might get unhappy with this. Could you have a flag =
for adding this domain creation logic that controls it in both places?=0A=
=0A=
AC: Yes, would need to think of a name that's meaningful (similar to init o=
r livepatch).=0A=
=0A=
AC: The argument for doing this was to get rid of the toolstack and not hav=
e duplicate code in the toolstack. The only way you get there eventually is=
 to delete all the other hypercalls (obviously in a phased way). If we do t=
his, the layout of data in DTB is an ABI.=0A=
=0A=
RPM: Can we define extensions to the DTB?=0A=
DS/SS: Sort of already exists, but not defined=0A=
=0A=
< Discussion around API/ABIs that I couldn't keep up with to note sensibly =
>=


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:48:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:48:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125557.1467452 (Exim 4.92)
	(envelope-from )
	id 1uz00T-0005Ip-8v; Wed, 17 Sep 2025 21:48:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125557.1467452; Wed, 17 Sep 2025 21: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 1uz00T-0005Ii-5e; Wed, 17 Sep 2025 21:48:05 +0000
Received: by outflank-mailman (input) for mailman id 1125557;
 Wed, 17 Sep 2025 21:48: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 1uz00S-0005Ic-Ce
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:48:04 +0000
Received: from PH7PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170100009.outbound.protection.outlook.com
 [2a01:111:f403:c107::9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fbc9d382-940f-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:48:03 +0200 (CEST)
Received: from BN9PR03MB6027.namprd03.prod.outlook.com (2603:10b6:408:118::7)
 by CH1PR03MB8144.namprd03.prod.outlook.com (2603:10b6:610:2b1::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.12; Wed, 17 Sep
 2025 21:47:58 +0000
Received: from BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779]) by BN9PR03MB6027.namprd03.prod.outlook.com
 ([fe80::1479:e1e0:cc3f:e779%6]) with mapi id 15.20.9137.012; Wed, 17 Sep 2025
 21:47: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: fbc9d382-940f-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dcFUAHEz6s8hLN51hF8J516cheSUe7aOJ4c6c8PMvR/MysNR7MxWk5+w87/uX05wHvpDanwWGLB1jG1gNVKXkBckyrndQ5msl+PJjk4ssbVD2gkHzd6+3CONGEJgZacIQE51JJR7TuN+JQmDo/MhBgVmVhSEFusYPLHE4ZIcJK5vm8Bbg385fftf1APIyLL/ePH6skCja6F3YteVmNNWc3z4RkJTbTwgwov9BUK9vrPFq7qRvpI1Crm36H8r2bEow6EgiLgA8UTEuchPcw4CPcNKzwLgb4zXghS/dGKcxyyvaiyuqVexDLv3to7JXsukodbCQVZTtx9A5nxIFceh5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MqlyYNVNhXEp9Fi0bA+1lpK3XT6l3i5r82cA1VrtRwA=;
 b=Q/CTZmrRqk4mzNHcRmRZS4h2IHagdqoqUJ9rf0PpWFO/1yctYSi4JJ940REw0Ksxu/ZeDFJgXHQJVkvB8RuKGoAUyER1wuvYJexr/PA45oIUf3SnxFszlri9atNr6yQVWq9Pwg7o24L+kkRJwSFO1vWavSFbC3VrNaKmq5RKILqaT4SGxHG4za0FGCOhC300ChNDaBIFA178bf/J0+aSV0zk7djaX3/jNhjcGwtFaRQNrKRKI9nCFP4YnbFYH67xuIiIY6TeZgGy06xguBUKBAKWsCvWfb11GeQDa7xBTx4kXOsjEKWoVieV21MrZbPoYa9kUGzYJzX5l70+ULj53g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MqlyYNVNhXEp9Fi0bA+1lpK3XT6l3i5r82cA1VrtRwA=;
 b=D63X944sfaHsAZLXRBvUhleHs4rNFCzqTsX7lvKCYSsZoE08Mg7HYKMqjYK925UtqDh/sKLNgB/76MnwmhhPt4SZexiI4s17xZIhkXxiEuQrVEmduQFzdQJh1KMILNGbM8eCV5AahhY9C9MQGRq/mr/2LxDpg9DJSubXL5LLlvE=
From: Alex Brett 
To: "xen-devel@lists.xenproject.org" 
Subject: Xen Summit 2025 - "Secure boot lockdown" design discussion notes
Thread-Topic: Xen Summit 2025 - "Secure boot lockdown" design discussion notes
Thread-Index: AQHcKBy7JW6IllbzNUi2Us/gVvFCOw==
Date: Wed, 17 Sep 2025 21:47:58 +0000
Message-ID:
 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN9PR03MB6027:EE_|CH1PR03MB8144:EE_
x-ms-office365-filtering-correlation-id: ac003adc-5373-4223-94d7-08ddf633de27
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?SSbF8I0sfmx8518OgMpTvs2iZxQQjIW90WBC8Jl3tFZk4p9FX/p4g5H9I5?=
 =?iso-8859-1?Q?hjcZPn5yfq1ZA7NDrNhvHnZF2G4buIO/EtRB66p3iJapH9tLOBsr+eSAkC?=
 =?iso-8859-1?Q?zVHUazqhGI+PpUpbICq5hKB5lne4ur4gwL85YmnT55LvjIGGVQy89/rmPi?=
 =?iso-8859-1?Q?Fk7y7QBlnkwSYVBnzi+hCPpD5HWAnQvXnoISkkeaQtrxrs9CAWMvykgmpz?=
 =?iso-8859-1?Q?sjAIyEs+TYvZSrNoEYfpAF156JBraMFch2gcsg5McaZXsdi9CTFg6H5ouG?=
 =?iso-8859-1?Q?8yU9B//aM+3O8EWNQOKpnVUrpiyxiyNA7sJzaCAc9MEov9UgDj/cMufTIK?=
 =?iso-8859-1?Q?dSzGz5lK2DYfBmsjQqr8dN3/F9yrCnEB2/q5530To52foypw7TuGJURHho?=
 =?iso-8859-1?Q?SuMPnzcNcOkGLQj6t9FleHdeWZJlGIjszQFtsF+VWFF0/EWtM1NFabi/YV?=
 =?iso-8859-1?Q?YX3OB6CGmNMoGXlj64bWExdPrqj4p0xjrnZHUOC4LEsVt1Yd0aQDTvUh8X?=
 =?iso-8859-1?Q?ZfZAGAATqkhS1BSJxqyWzfUzF7wBXr6G+Mlybvu9BMCFbbUe87pFlCZc7C?=
 =?iso-8859-1?Q?rVufma+6OdjP5Af4tLONdwewV3Fh4t0nDWg/D1kMt+Qul1obX6c6wSfK1o?=
 =?iso-8859-1?Q?gOeYilSb4rbDh2twfrq/ei60D3e6gUGZOxKZP2ede+HBOVwFKqb/eCj00t?=
 =?iso-8859-1?Q?zOoCVjhxmEzhnSuiVsvq6Ms2m0WioPqcEH4keNCOTf0xnmHrvq0XfWeVTm?=
 =?iso-8859-1?Q?POEYY5wHamP12Hn5IessMEba/qW0oZCxY0YXgev8LG02ZwgtXx5EvL1leA?=
 =?iso-8859-1?Q?upDXAzsz3QS7rdoUHAKrzRq9FxnVfBBCi8sV8JVksms+PxTanfnq5FHRb7?=
 =?iso-8859-1?Q?SHMjh4JogjLyWkE3ab4shnKoyoHApeNAfDUycuWAlI72eOGFeEZ4vu33a6?=
 =?iso-8859-1?Q?G6qapgVlbhcHX5aBTgkUYL0ittVs2U8HyEvz9NykhSc+SHHv56368ugVGR?=
 =?iso-8859-1?Q?UUQG0wayz5Dy9VBqpn0rL1O1H2EzQ49g8G4nDQOjf80uB3ktM2vysyzqOf?=
 =?iso-8859-1?Q?D/5AkkBLZi5XXI6oHuwb2yBj6o+pDdqG7GTWQvtkDaLrfvEDXfPyidJqF1?=
 =?iso-8859-1?Q?NAMKyxBXkdM16EYBka+fMQsoD7ToZnr2SmbIpqseDDcYDfLq8qPKw7g27g?=
 =?iso-8859-1?Q?taiYX39YPtQ4Wpn1/LjftgjM/DCfTGxIua+7EUbadZhNt1rVyyRaUJWeNY?=
 =?iso-8859-1?Q?josd6VE9N5gJLFpD9dC8IdQLQDwh1At6lBvR4OQztUSFMEuQU/wQUReAju?=
 =?iso-8859-1?Q?xUWoxqTQUv9R3MW67po4rxByRJ/NdPGxvTr3O12opSphoQ4yKV2dINHlOP?=
 =?iso-8859-1?Q?Q0rueXSjw/ujaoPh2GWaCj5DeN1eZKe/qWA4dxy0Dae2UfZODkZoiSfWjO?=
 =?iso-8859-1?Q?ZJIl8XMGJnAgniFQNjTWZiqc8FlIf7XkZed9KYtC8/3/syZl1U9X/RVYLO?=
 =?iso-8859-1?Q?7pzqEoq+gf4YdBzdYbJpX3q4VD9dj4iaj1/m5SgynNTQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR03MB6027.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?hNNDtvBbp/JrnHFNywwhR/iNgGrYoLo/d6pC9/Y4aQB1AmOjqVMW3HWCtY?=
 =?iso-8859-1?Q?0tedHGSLA5cT4dHPL5y+9D3Ks548fPY3vAQWSLd1UoRxzegT4R9Zc7r0Zz?=
 =?iso-8859-1?Q?Lw9mznqEeL6JlMHgcwiQ/xSspqWAosXZNdMy3f8gcg7ZCmepIUVJH/Iyoa?=
 =?iso-8859-1?Q?lLg3NDD/835I8I4oBhSW48n9teslQnxVvZXkCGFd3vZC2eS0Pi3Cx8ay/S?=
 =?iso-8859-1?Q?fNG5CygKPGiq/1nl/zwkl7/yQxtlZ9yg9/UQi5/K3KYaIYwdV4L8LbqhZt?=
 =?iso-8859-1?Q?CPg++jJcm1y0RVX94PWc8+4HHwUyJCb92uFV/5+IvGXWjOinuT9Ocl3ogA?=
 =?iso-8859-1?Q?NA9dGJfaZf8HCrzDOug9Kk2qwxgt8y4LHAUhn5FfScbfAo1QpJT6ulM9/c?=
 =?iso-8859-1?Q?fqrdR/eLgZn3pEIYiQNnmUJ5Ekh1qfZUFQTY8ufwvyNc+6iY8/ROcF0Vc5?=
 =?iso-8859-1?Q?sWsakGJ8ilTAybexjPPP2BPiI/HfWkFfFc5eg3RD3FvgFyfAqtqmbKbGwW?=
 =?iso-8859-1?Q?7NLdNb4vH7UfqMr9TDlmkzrMzwfkeGWikrcGDtNOKbqcXJ8gStyZP39nzL?=
 =?iso-8859-1?Q?bvLELvWYxMdmH0P8EGlpeTRa3AXpjJG0hL2zJETB8Lb8xXPZnyUFPtyPw5?=
 =?iso-8859-1?Q?ZKjLzSmw/8zIM68s9mAztjMln/c8EkFemC0rO0fgUxyBckVMd5o9w1W/GV?=
 =?iso-8859-1?Q?JQBLP585taWPuHC1PTV4STsCXs+TwwgR8FnJhhPZtciLprT7DycXQZZY/N?=
 =?iso-8859-1?Q?zAkX6+r7AaY9/YAP69FHEdGZWz9KDtu8BZV8MI/uf81Qn349WCMfSjJBDP?=
 =?iso-8859-1?Q?itmnyHmyFELQaa2nGO2N1Sp0uBGhPwSUM5JmI2EhD6OmpyqJFlxjMjhJZ7?=
 =?iso-8859-1?Q?A8NVCYlsl0i2dlthw8GGre3fcDhNk3p/kaad7w1jbhwa8k4618FBknInpt?=
 =?iso-8859-1?Q?dc2+ALb4TJBjaDr16IQpVA0+swUWs82dSSLudsV+lTB2ayPZeoxsN0ZsTv?=
 =?iso-8859-1?Q?Dr9cqr4xCvhlnZXIAw2CZiouaTw471GoNKE6hNcDeai7PBKeGj9Rrxl5cE?=
 =?iso-8859-1?Q?qz3dP9svtyPDXJcnCMxz9m9GBRjeld25z+LgREBSLpe5ZurMPDaa7oCG8j?=
 =?iso-8859-1?Q?RJ+IyQ4zUkbwitV6VkHBGsP9zKWkEi1Kw9976qkqjnN/Dt40tWgvbtIZMW?=
 =?iso-8859-1?Q?iKd2++1PHzH1JKCVsvXXW2nalkfFV5s3Cq8u+hsSDZH2GMlWV50ZAsafp7?=
 =?iso-8859-1?Q?2Nnvg+9JBjiXt1F6VW7tsDPSXpsrOfnAmUBQzUqV5k7iBTYuBqYsBYmCkb?=
 =?iso-8859-1?Q?cw/Chy06tgmaCJkav5anj2ER0jJhI9T9l6Er8FmRc5B1qbdjPorR7Gng03?=
 =?iso-8859-1?Q?mTOaUlhLOPhU1V1V/L+PpMm9OzWMq5P75o+wSWnw4fORAbw3aW7Wrcrbeq?=
 =?iso-8859-1?Q?g8tEpydvdctMW5aA0HNpfFpZtrcFoBDbC8VDKCm6Uj+z5+Px7WzKbUT5dF?=
 =?iso-8859-1?Q?RlFDcf2L+Av9KUNcos7HoAudUyNbwoBFK+Zru2MIRF+yILdAY0LElFhcQs?=
 =?iso-8859-1?Q?V1kInT3YrfCi8qugqKpbgqFkaXtXFWhU5CER9WiTBRkWbwe8a6tPdNnzpY?=
 =?iso-8859-1?Q?quER0d5xigdHT+M63TPqdX0a0BMBP1hlMa?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR03MB6027.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac003adc-5373-4223-94d7-08ddf633de27
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2025 21:47:58.7271
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JoN0rID8tIKMaXRzbSOdnTZcTHrJm9fQZ6Mzk0DkK03BDyzC8tx4nlx96LPwLlQc9wtBv3QtjdZk/ybTzSNjbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR03MB8144

SBAT summary: Upstream Xen will not maintain a generation number, but will =
publish recommendations as to whether downstreams should bump theirs in XSA=
s etc.=0A=
=0A=
Lockdown: No patches currently merged.=0A=
=0A=
Andrew Cooper (AC): Done initial secure boot policy document, needs refresh=
ing to bring up to date and reposting. *ACTION*=0A=
Jan Beulich (JB): Document should be able to go in even close to the releas=
e.=0A=
Oleksii Kurochko (OK): No issue with that :)=0A=
=0A=
AC: Document is trying to state the security boundary. Get this merged, the=
n patch series will also include moving things from In Progress to now set =
in stone as appropriate. Document is used to define the judgement the secur=
ity team will apply when considering if an issue is security or whether it =
impacts SBAT etc.=0A=
=0A=
AC: With this in place, it feeds in to the design for lockdown in particula=
r. Lockdown named after Linux way of doing it, just a name (though hate it =
but can't think of a better one). Idea is if you boot in secure more it's f=
orced on, but want the ability to turn it on even without secure boot (for =
testing / ensuring you don't introduce things which are relying on it not b=
eing present etc). Framing lockdown mode like this does change quite a few =
of the discussions around e.g. command line parsing order etc.=0A=
=0A=
AC: Can say if a developer is using it for testing purposes, they should un=
derstand command line is parsed L-R and should therefore put lockdown optio=
n early etc.=0A=
Yann Sionneau (YS): Need to ensure we don't allow lockdown mode to be disab=
led when using secure boot (AC: that would be a security issue and need bum=
ping SBAT etc).=0A=
=0A=
JB: Lockdown mode outside of secure boot primarily for developers.=0A=
=0A=
AC: Don't want to worry about having to do multiple scans of command line e=
tc (for outside of secure boot enabled), as command line comes from multipl=
e places etc. Trust developer to put it in the right place.=0A=
=0A=
JB: How do we deal with something on the built in command line that's not p=
ermitted with lockdown?=0A=
AC: Should be allowed=0A=
JB: What about in secure boot mode?=0A=
AC: Good point - might need to pass a flag in=0A=
=0A=
Marek Marczykowski-G=F3recki (MM): In the unified image should the command =
line there be permitted to bypass lockdown options?=0A=
AC: Yes, the command line is part of the signed image etc at that point.=0A=
=0A=
MM: Should add a CI job with lockdown enabled. *ACTION*=0A=
AC: Yes, in the Trixie containers we're now far more amenable to testing th=
ese things. There's an OVMF ROM that has secure boot forced on along with t=
he private key to sign the test image that should enable doing this.=0A=
=0A=
YS: Is there a security issue if a command line in a unified image disables=
 lockdown?=0A=
JB: We wouldn't have an option for lockdown off, only to turn it on=0A=
AC: If as a downstream you sign an image that disables security, that's you=
r fault and you've got a security vulnerability. We can't always prevent pe=
ople shooting themselves in the foot.=0A=
=0A=
AC: In principal any binary that has had a signature check is in principal =
good, even if it does things that wouldn't be allowed in a runtime command =
line argument.=0A=
JB: If someone signs something with a wrong option, that's not Xen's fault =
and not a security bug in Xen.=0A=
YS: Agreed, but could we put code that shouldn't allow things to go in to a=
n insecure mode if secure boot is enabled?=0A=
AC: Gave an example of a HAP superpage option, which wasn't in the list of =
allowed options so was ignored by Xen (but is safe to change) - being able =
to embed that in a built-in command line makes sense.=0A=
=0A=
Daniel Smith (DS): At the end of the day Xen doesn't want to be in the busi=
ness of dictating to its users what's safe or not=0A=
AC: Gave an example of COM port options that are in most cases safe but IO =
base can allow a vulnerability. For some of the more complicated options it=
 will be difficult to know what's safe or not, so giving downstreams the ab=
ility to declare its safe and run with it is needed.=0A=
=0A=
privcmd=0A=
Alex Brett (AB) (on behalf of Ross Lagerwall (RL)): For lockdown of privcmd=
, the only part we think needs fixing is the raw hypercall access (IOCTL_PR=
IVCMD_HYPERCALL). In XenServer, we have done this using an additional filte=
ring layer. This is not something we want to upstream since it binds the ke=
rnel to a specific Xen ABI. Instead, we want to introduce a new stable hype=
rcall ABI that allows the kernel to filter in a generic way (much like dm_o=
p). We haven't scheduled the work to do this.=0A=
=0A=
AC: Explained that it's the guest kernel which needs to decide what userspa=
ce can and can't do to send hypercalls. In Linux secure boot requires you t=
o call access ok on every pointer or memory range etc. The new ABI in Xen w=
ould allow the kernel to do this without having to know about the Xen struc=
ture, by guaranteeing there are no pointers in it.=0A=
=0A=
AC: You have hypercalls that are safe, and ones that are not. With privcmd =
currently userspace can violate all kernel lockdown protections, so need to=
 ensure the unsafe hypercalls can only be issued by the kernel. Fine for th=
e kernel to offer e.g. /dev/xen/eventchn as the kernel is mediating the acc=
ess.=0A=
=0A=
AC: One thing to do in the document is to go through hypercalls and subops =
and classify if they're logically a privileged command or a control plane c=
ommand. This gives the separation of what's strictly kernel only/mediated, =
vs things a kernel wouldn't care about. *ACTION*=0A=
=0A=
AC: Other issues, e.g. toolstack uses eventchn_op targetting a new domain, =
but this would ideally be a domctl op.=0A=
=0A=
AC: Reason we said secure boot v1 will only allow a monolithic dom0 is othe=
rwise one privileged domain could target the other and violate specs. Also =
need to make sure certain operations can't be performed on yourself.=0A=
=0A=
AC: The XenServer filtering code (which will be released, just not upstream=
ed) is a good starting point for what needs looking at. Fits into the wider=
 API/ABI plans.=0A=
AC: The XenServer code is a stop gap to be able to ship (and hopefully get =
through the API/ABI community).=


From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:48:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:48:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125558.1467463 (Exim 4.92)
	(envelope-from )
	id 1uz00q-0005Yz-GB; Wed, 17 Sep 2025 21:48:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125558.1467463; Wed, 17 Sep 2025 21: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 1uz00q-0005Ys-Cz; Wed, 17 Sep 2025 21:48:28 +0000
Received: by outflank-mailman (input) for mailman id 1125558;
 Wed, 17 Sep 2025 21:48:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uz00p-0005Yi-Rx
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:48:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uz00p-00EY7N-1F;
 Wed, 17 Sep 2025 21:48:27 +0000
Received: from [149.199.65.200] (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 1uz00p-00F7dH-0s;
 Wed, 17 Sep 2025 21:48: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:
	Message-ID:Date:Subject:Cc:To:From;
	bh=XGb+gGeKyZDQMTF1ARe7eP6YHdANHrG833P8p7ukfEs=; b=f4HPfzJd1S8AoNGApw71ZGzBi8
	gfTRl7TJtxz9yfCUORsTH8CjfSc0QFblFffV5eKU4UVNAI0dRSBNngaxJB1V6v1CB9fodtE6FPJO8
	8X9jKnpW+pttkN1VsvbZ6kHaZnw3bcK4naF7zOkbfrCUjM3NhFcxtmpTLe9WxOjfoD4Q=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [RFC XEN PATCH] build: Require explicit .config update
Date: Wed, 17 Sep 2025 23:45:20 +0200
Message-ID: <20250917214519.64323-2-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

It is sometime unwelcome for the config of the hypervisor to change.

Make output will be something like that:
  tools/kconfig/conf  --syncconfig Kconfig

  *** The configuration requires explicit update.

  make[2]: *** [/xen.git/xen/tools/kconfig/Makefile:73: syncconfig] Error 1
    GEN     Makefile
  /xen.git/xen/Rules.mk:19: include/config/auto.conf: No such file or directory
  make[2]: *** No rule to make target 'include/config/auto.conf'.  Stop.
  make[1]: *** [/xen.git/xen/Makefile:620: xen] Error 2
  make: *** [/xen.git/xen/Makefile:179: __sub-make] Error 2

This also prevent update when the toolchain change and change CONFIG_*
values like CONFIG_GCC_VERSION.

Proposed-by: during design session
Signed-off-by: Anthony PERARD 
---

During the design session, the proposal was to compare .config before
and after syncconfig. But maybe KCONFIG_NOSILENTUPDATE is enough?

---
 xen/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index 49da79e10f..efeaaa557c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -379,7 +379,7 @@ $(KCONFIG_CONFIG): tools_fixdep
 # The syncconfig should be executed only once to make all the targets.
 include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
 	$(Q)rm -f include/config/auto.conf
-	$(Q)$(MAKE) $(build)=tools/kconfig syncconfig
+	$(Q)$(MAKE) $(build)=tools/kconfig syncconfig KCONFIG_NOSILENTUPDATE=1
 
 ifeq ($(CONFIG_DEBUG),y)
 CFLAGS += -O1
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125583.1467493 (Exim 4.92)
	(envelope-from )
	id 1uz086-0007oQ-Ta; Wed, 17 Sep 2025 21:55:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125583.1467493; Wed, 17 Sep 2025 21:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uz086-0007oH-Py; Wed, 17 Sep 2025 21:55:58 +0000
Received: by outflank-mailman (input) for mailman id 1125583;
 Wed, 17 Sep 2025 21:55: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 1uz085-0007Lu-B5
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:55:57 +0000
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [2607:f8b0:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 163b661f-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:55:56 +0200 (CEST)
Received: by mail-pl1-x632.google.com with SMTP id
 d9443c01a7336-25d44908648so3991235ad.0
 for ; Wed, 17 Sep 2025 14:55:56 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 163b661f-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146155; x=1758750955; darn=lists.xenproject.org;
        h=content-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=wQNGgSFWc/8UyDD0fnmeKMR4OiuAHPnjV1/CBg7F61M=;
        b=gp4Dqjx3POGVUZthjORo39D7RzCHoFbiDJHD2o4MN0hve3JJHgFxwLGpxcJnM4HEBH
         Fu6++0cxgD4ZkxCjCpX6aI4BmYlZBYbnYkfdY46c7tAAgEze4XVyx2d8QatsHLlTsPGG
         CbhoOwt4CivNp66e5IMVzdnaMNTwShCoSji9VzA2iQ1OyX34ldEG+2MEpWAfQPwdmF6E
         J9mu5z9HXcpuCX2AFCDeGJpZPmqXOnkfrB0mxhZ8LyYor5KeNKZfjyWD6kzZcXYIqBBp
         17WAYYp82vnD4iwJTWGPFjcb/Z5gKEPgzxV5Hhblx2H+RD4tbkIg23D9mDUJYPfUj+xx
         8Urw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146155; x=1758750955;
        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=wQNGgSFWc/8UyDD0fnmeKMR4OiuAHPnjV1/CBg7F61M=;
        b=H6OrRsx4L37a2cgkSn55qr3217/qT2vc1bvsnvqvm6zIf9gKyobZsC5FseoMFnoKf6
         kDp50TNfdVYCqDvoc5v4WWSFeeYqDGhUwWk9itsbYgCB2fKXXPlS7oTcNawnqG2TGyuB
         qXdorv5g6Z6taFiukadd3Hehivk5qsCjWUAzp022zqcO7KM1eRD4RUz3qszvXREMF08t
         +bVa5s2byO0zGTfJKFuzJQzjAq5hGsj0tB+Zn+U0VObFuVMtbU/4tZuwuhqV1gsn7HIC
         ppof0gQoqlthOf7IFzbEqJBeaFR3zFINJUT2MUnQPSTnb9SLGs4Xrc+Ip3m5NDSRSfZx
         gNew==
X-Gm-Message-State: AOJu0Yy40K3A6OG0wZpVJbqOUL1815R71LbYBxsG1YJfxvlUjriHpv/X
	gOJPuqYvZLLnAwUmKwFLUcK7XC03LThJDeRcypybSRPP+VL4lmeb+CuTh6BFLFnNMig=
X-Gm-Gg: ASbGnctktlfeXfN/jlSXQlZFbJJO+AxmqJZqxCpRrw6rWhvVNf8T5xC+nAv8PsodY2c
	BcAvFriBpThe/AUALWftF8GS9RNvVDdC1IFYahJhn8056PPEp1YFCa2w8HnMvpULBKalMEAeQ3m
	sicLNlMuuR32Hoc2uqL8A5hdHvMY8CjJznbhf0S+134Evfd9r4A2l79owz82R6CPjuuBui3j3ru
	bCVHT6Z2z8ZXRf9KkjFu6BZbUuW1AOIV6++UO3BLtUY4Hl1Ong4HNf4+yoFF7u5CEBNUZ7exQT8
	mU1ESMZ+7AbUEb6tnL2q8iOL+KkQpip0RWC6YtzShjPgT8YUx2R+eJXfr8RNfie7OCqs+z1Et/s
	JlwNevkNe9AwuoX2cdPZjiRM88aNOs69QseSz2wYMVrQk
X-Google-Smtp-Source: AGHT+IFgZhg0vaqNQC7y/3ouz/dOckqk2ZCdOyyRwoD3kmfAr06a/fD78QmY82yfUqaI6dGVCWSGiQ==
X-Received: by 2002:a17:903:985:b0:252:5220:46b4 with SMTP id d9443c01a7336-268137f250dmr42602945ad.37.1758146154660;
        Wed, 17 Sep 2025 14:55: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 v4 03/18] xen/riscv: introduce things necessary for p2m initialization
Date: Wed, 17 Sep 2025 23:55:23 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.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.
  - back pointer to domain structure.
- p2m_init() to initalize members introduced in p2m_domain structure.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Move an introduction of clean_pte member of p2m_domain structure to the
   patch where it is started to be used:
     xen/riscv: add root page table allocation
 - Add prototype of p2m_init() to asm/p2m.h.
---
Changes in V3:
 - s/p2m_type/p2m_types.
 - Drop init. of p2m->clean_pte in p2m_init() as CONFIG_HAS_PASSTHROUGH is
   going to be selected unconditionaly. Plus CONFIG_HAS_PASSTHROUGH isn't
   ready to be used for RISC-V.
   Add compilation error to not forget to init p2m->clean_pte.
 - Move defintion of p2m->domain up in p2m_init().
 - Add iommu_use_hap_pt() when p2m->clean_pte is initialized.
 - Add the comment above p2m_types member of p2m_domain struct.
 - Add need_flush member to p2m_domain structure.
 - Move introduction of p2m_write_(un)lock() and p2m_tlb_flush_sync()
   to the patch where they are really used:
     xen/riscv: implement guest_physmap_add_entry() for mapping GFNs to MFN
 - Add p2m member to arch_domain structure.
 - Drop p2m_types from struct p2m_domain as P2M type for PTE will be stored
   differently.
 - Drop default_access as it isn't going to be used for now.
 - Move defintion of p2m_is_write_locked() to "implement function to map memory
   in guest p2m"  where it is really used.
---
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/domain.h |  5 +++++
 xen/arch/riscv/include/asm/p2m.h    | 33 +++++++++++++++++++++++++++++
 xen/arch/riscv/p2m.c                | 20 +++++++++++++++++
 3 files changed, 58 insertions(+)

diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index aac1040658..e688980efa 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 vcpu_vmid {
     uint64_t generation;
     uint16_t vmid;
@@ -24,6 +26,9 @@ struct arch_vcpu {
 
 struct arch_domain {
     struct hvm_domain hvm;
+
+    /* Virtual MMU */
+    struct p2m_domain p2m;
 };
 
 #include 
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 9d4a5d6a2e..2672dcdecb 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -3,6 +3,9 @@
 #define ASM__RISCV__P2M_H
 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -10,6 +13,34 @@ extern unsigned long gstage_mode;
 
 #define paddr_bits PADDR_BITS
 
+/* Get host p2m table */
+#define p2m_get_hostp2m(d) (&(d)->arch.p2m)
+
+/* 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;
+
+    /* Back pointer to domain */
+    struct domain *domain;
+
+    /*
+     * P2M updates may required TLBs to be flushed (invalidated).
+     *
+     * Flushes may be deferred by setting 'need_flush' and then flushing
+     * when the p2m write lock is released.
+     *
+     * If an immediate flush is required (e.g, if a super page is
+     * shattered), call p2m_tlb_flush_sync().
+     */
+    bool need_flush;
+};
+
 /*
  * 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.
@@ -92,6 +123,8 @@ static inline bool arch_acquire_resource_check(struct domain *d)
 
 void gstage_mode_detect(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
index 56113a2f7a..70f9e97ab6 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -3,6 +3,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -89,3 +93,19 @@ void __init gstage_mode_detect(void)
      */
     local_hfence_gvma_all();
 }
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    /*
+     * "Trivial" initialisation is now complete.  Set the backpointer so the
+     * users of p2m could get an access to domain structure.
+     */
+    p2m->domain = d;
+
+    rwlock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    return 0;
+}
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125584.1467497 (Exim 4.92)
	(envelope-from )
	id 1uz087-0007ry-7S; Wed, 17 Sep 2025 21:55:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125584.1467497; Wed, 17 Sep 2025 21:55: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 1uz087-0007r2-22; Wed, 17 Sep 2025 21:55:59 +0000
Received: by outflank-mailman (input) for mailman id 1125584;
 Wed, 17 Sep 2025 21:55: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 1uz085-0007Lt-BE
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:55:57 +0000
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com
 [2607:f8b0:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 157d6874-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:55:55 +0200 (CEST)
Received: by mail-pl1-x631.google.com with SMTP id
 d9443c01a7336-2697899a202so3759705ad.0
 for ; Wed, 17 Sep 2025 14:55:55 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 157d6874-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146153; x=1758750953; darn=lists.xenproject.org;
        h=content-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=e2rhAU643kEGhrWe/jmglXVcJKnTIdAoGMitewIm5D8=;
        b=HHm2Um0bwr9HPfhgd2Ci6dGjM/HD8x87k75WZVapD8GB+EICCfx/4+n6JoU7FLJUf/
         LFSlupEFnjrT3hgfdMWEqCpf5fypDfdzq2bW33N3R7PGCoSw9ZuLjgBvul+mkRhQYu9i
         ozHF0kUmgizcEz1amemjS96st/wn7gb4bqxFgJuij9yl37NhTOPG3wyY/lQjRBlMzC/V
         aB/ZZnUxHU9BWOfRg5K/KD7GL3uTjNIdYDV5GnK8/3GcQIEOfvJyx10/GFm+rQuj3Pdm
         mUcjM1fBsRtqZiXZtwyBeICRCrxpODvFVSKrc62DJYYBFb8cVS8kDEw8r+2k5qH8xWQP
         egeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146153; x=1758750953;
        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=e2rhAU643kEGhrWe/jmglXVcJKnTIdAoGMitewIm5D8=;
        b=XxfsDZnGHwF58MPJR5xKAjRHCqXF4cf43SGjsvjumCdbqKlzzcJ63C5vYP3ho66N56
         DVwrpUNdjuchtRQikcYRpEWnMwN6mfLEHGHgF4Yp5kcnHQuQZHIgLAGbB51Bf0yloeXC
         Er5dLq9mbg9sPWjS8OZVA+75xNo0u4Wh0hLO+ZuqdrAkaPVWu4Sfm4iZstShQ7wCDsmz
         cDUiPN2DWVDQdtmimvHDNt08/Ngmj90cJhs2iK1T+RDSDoir10+IutU3pOuf3865x8gd
         zLZsncuf0fZqQe9WSuBeDWb3uh0g4fVPyrujyrI+QN36P8AqcI9Zxrlj9A0ZdZauHpaG
         CSAg==
X-Gm-Message-State: AOJu0YysNnxStp6IrTX6q93xIx5/LTZC9X6boARWgjUC6aRRPDDAYPQ3
	5VUAPOhfM+KHDUMkWfAa7jiuDCcG9F9MZagvvms+Ssq+kGjqPmBXr7Ud3rR0uwNve6Q=
X-Gm-Gg: ASbGncskLnJpSME6HLVHJqYZL3vsRmYka+lkZQBAyv+/qf84eiAaQPvpgAeKlkwO4ye
	ZCJLWHAqRAaA/JDNDgcN2vP1eEaazSdZfE/7JNHEaXx0uj/migESPzKjaUN7vlVpVo/kZ85ZNV0
	QqG1lu5hXhytlOwtNwOhaa21dsYKE/gZN7ByuGxrcLnwYyb98cKLPD6r1qW/NL0GALuJ7tVtazl
	LF8kwQ0+UFJXoDotmonAfOjm9qb95E+L3AfIlW1NgkwO4K9LAomV6qflduvAtvVCUC8k9nil8Dc
	L2zhYhDzfRRyfGl+neto7njXXyQ+4bM4eqKcxWI8JxTL7ybblIQ6lPbDBddfSG4m0Kn1IGCjlLN
	wTlwScWxnrwbSlC8Z2LAwRsmIbOqb54CaI0AlGvPZ6Yaa
X-Google-Smtp-Source: AGHT+IFveSNTsVORxRDcIl5097I7VH7hMXe0p5jI7fPGDtp5b3tIrxtMpAlnmNCixzaapY0XOodMjA==
X-Received: by 2002:a17:903:fa7:b0:24c:e9de:ee11 with SMTP id d9443c01a7336-2697ca570dbmr13830875ad.17.1758146153352;
        Wed, 17 Sep 2025 14:55: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 v4 02/18] xen/riscv: introduce VMID allocation and manegement
Date: Wed, 17 Sep 2025 23:55:22 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Current implementation is based on x86's way to allocate VMIDs:
  VMIDs partition the physical TLB. In the current implementation VMIDs are
  introduced to reduce the number of TLB flushes. Each time a guest-physical
  address space changes, instead of flushing the TLB, a new VMID is
  assigned. This reduces the number of TLB flushes to at most 1/#VMIDs.
  The biggest advantage is that hot parts of the hypervisor's code and data
  retain in the TLB.

  VMIDs are a hart-local resource.  As preemption of VMIDs is not possible,
  VMIDs are assigned in a round-robin scheme. To minimize the overhead of
  VMID invalidation, at the time of a TLB flush, VMIDs are tagged with a
  64-bit generation. Only on a generation overflow the code needs to
  invalidate all VMID information stored at the VCPUs with are run on the
  specific physical processor. When this overflow appears VMID usage is
  disabled to retain correctness.

Only minor changes are made compared to the x86 implementation.
These include using RISC-V-specific terminology, adding a check to ensure
the type used for storing the VMID has enough bits to hold VMIDLEN,
and introducing a new function vmidlen_detect() to clarify the VMIDLEN
value, rename stuff connected to VMID enable/disable to "VMID use
enable/disable".

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - s/guest's virtual/guest-physical in the comment inside vmid.c
   and in commit message.
 - Drop x86-related numbers in the comment about "Sketch of the Implementation".
 - s/__read_only/__ro_after_init in declaration of opt_vmid_enabled.
 - s/hart_vmid_generation/generation.
 - Update vmidlen_detect() to work with unsigned int type for vmid_bits
   variable.
 - Drop old variable im vmdidlen_detetct, it seems like there is no any reason
   to restore old value of hgatp with no guest running on a hart yet.
 - Update the comment above local_hfence_gvma_all() in vmidlen_detect().
 - s/max_availalbe_bits/max_available_bits.
 - use BITS_PER_BYTE, instead of "<< 3".
 - Add BUILD_BUILD_BUG_ON() instead run-time check that an amount of set bits
   can be held in vmid_data->max_vmid.
 - Apply changes from the patch "x86/HVM: polish hvm_asid_init() a little" here
   (changes connected to g_disabled) with the following minor changes:
   Update the printk() message to "VMIDs use is...".
   Rename g_disabled to g_vmid_used.
 - Rename member 'disabled' of vmid_data structure to used.
 - Use gstage_mode to properly detect VMIDLEN.
---
Changes in V3:
 - Reimplemnt VMID allocation similar to what x86 has implemented.
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/Makefile             |   1 +
 xen/arch/riscv/include/asm/domain.h |   6 +
 xen/arch/riscv/include/asm/vmid.h   |   8 ++
 xen/arch/riscv/setup.c              |   3 +
 xen/arch/riscv/vmid.c               | 193 ++++++++++++++++++++++++++++
 5 files changed, 211 insertions(+)
 create mode 100644 xen/arch/riscv/include/asm/vmid.h
 create mode 100644 xen/arch/riscv/vmid.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 264e265699..e2499210c8 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -17,6 +17,7 @@ obj-y += smpboot.o
 obj-y += stubs.o
 obj-y += time.o
 obj-y += traps.o
+obj-y += vmid.o
 obj-y += vm_event.o
 
 $(TARGET): $(TARGET)-syms
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index c3d965a559..aac1040658 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -5,6 +5,11 @@
 #include 
 #include 
 
+struct vcpu_vmid {
+    uint64_t generation;
+    uint16_t vmid;
+};
+
 struct hvm_domain
 {
     uint64_t              params[HVM_NR_PARAMS];
@@ -14,6 +19,7 @@ struct arch_vcpu_io {
 };
 
 struct arch_vcpu {
+    struct vcpu_vmid vmid;
 };
 
 struct arch_domain {
diff --git a/xen/arch/riscv/include/asm/vmid.h b/xen/arch/riscv/include/asm/vmid.h
new file mode 100644
index 0000000000..2f1f7ec9a2
--- /dev/null
+++ b/xen/arch/riscv/include/asm/vmid.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ASM_RISCV_VMID_H
+#define ASM_RISCV_VMID_H
+
+void vmid_init(void);
+
+#endif /* ASM_RISCV_VMID_H */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 87ee96bdb3..3c9e6a9ee3 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
@@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     gstage_mode_detect();
 
+    vmid_init();
+
     printk("All set up\n");
 
     machine_halt();
diff --git a/xen/arch/riscv/vmid.c b/xen/arch/riscv/vmid.c
new file mode 100644
index 0000000000..b94d082c82
--- /dev/null
+++ b/xen/arch/riscv/vmid.c
@@ -0,0 +1,193 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Xen command-line option to enable VMIDs */
+static bool __ro_after_init opt_vmid_use_enabled = true;
+boolean_param("vmid", opt_vmid_use_enabled);
+
+/*
+ * VMIDs partition the physical TLB. In the current implementation VMIDs are
+ * introduced to reduce the number of TLB flushes. Each time a guest-physical
+ * address space changes, instead of flushing the TLB, a new VMID is
+ * assigned. This reduces the number of TLB flushes to at most 1/#VMIDs.
+ * The biggest advantage is that hot parts of the hypervisor's code and data
+ * retain in the TLB.
+ *
+ * Sketch of the Implementation:
+ *
+ * VMIDs are a hart-local resource.  As preemption of VMIDs is not possible,
+ * VMIDs are assigned in a round-robin scheme. To minimize the overhead of
+ * VMID invalidation, at the time of a TLB flush, VMIDs are tagged with a
+ * 64-bit generation. Only on a generation overflow the code needs to
+ * invalidate all VMID information stored at the VCPUs with are run on the
+ * specific physical processor. When this overflow appears VMID usage is
+ * disabled to retain correctness.
+ */
+
+/* Per-Hart VMID management. */
+struct vmid_data {
+   uint64_t generation;
+   uint16_t next_vmid;
+   uint16_t max_vmid;
+   bool used;
+};
+
+static DEFINE_PER_CPU(struct vmid_data, vmid_data);
+
+static unsigned int vmidlen_detect(void)
+{
+    unsigned int vmid_bits;
+
+    /*
+     * According to the RISC-V Privileged Architecture Spec:
+     *   When MODE=Bare, guest physical addresses are equal to supervisor
+     *   physical addresses, and there is no further memory protection
+     *   for a guest virtual machine beyond the physical memory protection
+     *   scheme described in Section 3.7.
+     *   In this case, the remaining fields in hgatp must be set to zeros.
+     * Thereby it is necessary to set gstage_mode not equal to Bare.
+     */
+    ASSERT(gstage_mode != HGATP_MODE_OFF);
+    csr_write(CSR_HGATP,
+              MASK_INSR(gstage_mode, HGATP_MODE_MASK) | HGATP_VMID_MASK);
+    vmid_bits = MASK_EXTR(csr_read(CSR_HGATP), HGATP_VMID_MASK);
+    vmid_bits = flsl(vmid_bits);
+    csr_write(CSR_HGATP, _AC(0, UL));
+
+    /*
+     * From RISC-V spec:
+     *   Speculative executions of the address-translation algorithm behave as
+     *   non-speculative executions of the algorithm do, except that they must
+     *   not set the dirty bit for a PTE, they must not trigger an exception,
+     *   and they must not create address-translation cache entries if those
+     *   entries would have been invalidated by any SFENCE.VMA instruction
+     *   executed by the hart since the speculative execution of the algorithm
+     *   began.
+     *
+     * Also, despite of the fact here it is mentioned that when V=0 two-stage
+     * address translation is inactivated:
+     *   The current virtualization mode, denoted V, indicates whether the hart
+     *   is currently executing in a guest. When V=1, the hart is either in
+     *   virtual S-mode (VS-mode), or in virtual U-mode (VU-mode) atop a guest
+     *   OS running in VS-mode. When V=0, the hart is either in M-mode, in
+     *   HS-mode, or in U-mode atop an OS running in HS-mode. The
+     *   virtualization mode also indicates whether two-stage address
+     *   translation is active (V=1) or inactive (V=0).
+     * But on the same side, writing to hgatp register activates it:
+     *   The hgatp register is considered active for the purposes of
+     *   the address-translation algorithm unless the effective privilege mode
+     *   is U and hstatus.HU=0.
+     *
+     * Thereby it leaves some room for speculation even in this stage of boot,
+     * so it could be that we polluted local TLB so flush all guest TLB.
+     */
+    local_hfence_gvma_all();
+
+    return vmid_bits;
+}
+
+void vmid_init(void)
+{
+    static int8_t g_vmid_used = -1;
+
+    unsigned int vmid_len = vmidlen_detect();
+    struct vmid_data *data = &this_cpu(vmid_data);
+
+    BUILD_BUG_ON((HGATP_VMID_MASK >> HGATP_VMID_SHIFT) >
+                 (BIT((sizeof(data->max_vmid) * BITS_PER_BYTE), UL) - 1));
+
+    data->max_vmid = BIT(vmid_len, U) - 1;
+    data->used = !opt_vmid_use_enabled || (vmid_len <= 1);
+
+    if ( g_vmid_used < 0 )
+    {
+        g_vmid_used = data->used;
+        printk("VMIDs use is %sabled\n", data->used ? "dis" : "en");
+    }
+    else if ( g_vmid_used != data->used )
+        printk("CPU%u: VMIDs use is %sabled\n", smp_processor_id(),
+               data->used ? "dis" : "en");
+
+    /* Zero indicates 'invalid generation', so we start the count at one. */
+    data->generation = 1;
+
+    /* Zero indicates 'VMIDs use disabled', so we start the count at one. */
+    data->next_vmid = 1;
+}
+
+void vcpu_vmid_flush_vcpu(struct vcpu *v)
+{
+    write_atomic(&v->arch.vmid.generation, 0);
+}
+
+void vmid_flush_hart(void)
+{
+    struct vmid_data *data = &this_cpu(vmid_data);
+
+    if ( data->used )
+        return;
+
+    if ( likely(++data->generation != 0) )
+        return;
+
+    /*
+     * VMID 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("%s: VMID generation overrun. Disabling VMIDs.\n", __func__);
+    data->used = 1;
+}
+
+bool vmid_handle_vmenter(struct vcpu_vmid *vmid)
+{
+    struct vmid_data *data = &this_cpu(vmid_data);
+
+    /* Test if VCPU has valid VMID. */
+    if ( read_atomic(&vmid->generation) == data->generation )
+        return 0;
+
+    /* If there are no free VMIDs, need to go to a new generation. */
+    if ( unlikely(data->next_vmid > data->max_vmid) )
+    {
+        vmid_flush_hart();
+        data->next_vmid = 1;
+        if ( data->used )
+            goto disabled;
+    }
+
+    /* Now guaranteed to be a free VMID. */
+    vmid->vmid = data->next_vmid++;
+    write_atomic(&vmid->generation, data->generation);
+
+    /*
+     * When we assign VMID 1, flush all TLB entries as we are starting a new
+     * generation, and all old VMID allocations are now stale.
+     */
+    return (vmid->vmid == 1);
+
+ disabled:
+    vmid->vmid = 0;
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125582.1467482 (Exim 4.92)
	(envelope-from )
	id 1uz085-0007Zn-Eu; Wed, 17 Sep 2025 21:55:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125582.1467482; Wed, 17 Sep 2025 21:55: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 1uz085-0007Zd-Bx; Wed, 17 Sep 2025 21:55:57 +0000
Received: by outflank-mailman (input) for mailman id 1125582;
 Wed, 17 Sep 2025 21:55: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 1uz083-0007Lu-QT
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:55:55 +0000
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com
 [2607:f8b0:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 14b0e6dd-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:55:54 +0200 (CEST)
Received: by mail-pl1-x62a.google.com with SMTP id
 d9443c01a7336-26060bcc5c8so2755765ad.1
 for ; Wed, 17 Sep 2025 14:55:54 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 14b0e6dd-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146152; x=1758750952; darn=lists.xenproject.org;
        h=content-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=8ZKBeOzQlMI0H2OFn3PfjH1UwDz/qzKq2B8yZK4VfQM=;
        b=UBiGUh4WO/uimQQx4AcwOItA+dGGKK41OO6UrtOG3FVcM9KBbQK1SS0ZsN4eh5UTND
         bVFjCjOrMByj1OICSlQfTRCTXsOTfD3bIwpWiwB8LuVI9luGbCk7PWF2D2EZk0vhpVhD
         GjAPnlRGU6ARHOocmB5zZuqK3bKeu5TRzyPkUHRRLJAOa4wQhYG6FTbilqJYMDtVz6m4
         yrPDjfJM8LUJX+Hqasq4cLsi6mkiCSHejLp2abMOlZRguX3jepGG7tn5pKVZYrRJ51LN
         ZxWfUbtQ1zmHWUcLBC1n9ae8AFdmwvYOcWf4H0d4659nTAbSVAqDIX751ZOmlAmG0yG8
         Uueg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146152; x=1758750952;
        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=8ZKBeOzQlMI0H2OFn3PfjH1UwDz/qzKq2B8yZK4VfQM=;
        b=u0L6Q2Ie4S4cCJ6ev0HC6O+UzgOxz4qhOCtR0Szm44Ef1IXSsTqPRBuDv3q5KusvvS
         yiddt2tQsfQSttOM0z23x4QkI/bB0oyNmdDIJX47z8uCW3UPvjJdbNcebZhN4xQ28E87
         h4OKEIFof/3NB8o3vP+o2RLLH3htDceY5gu6lKWmhdLNfbu6YbrmdwqBvtQiGqvHWBgu
         TVWGxO8cUAk3xDRINHXk4zqF5b9gPsbJluyVCUZKfF/Ck70pZPo+U2dRWhivQY9s4fcl
         mmqsbY6YIvKTRQ/znIhljn7FJfiBdSjtNf0IVtQ8p3xljTZAISSstwP1UfrDVQpQLJEJ
         lMDw==
X-Gm-Message-State: AOJu0Ywe4WAuRGhSj2dP3Xr9KjSWxhNnqTkrynwcSLQX+4GXW6R3quuX
	GbLWwwUBMwKcZIzT3vTwVFbzqIx71KUuQt07yqx/5KZqYQB/WLGHP0ckXTQRJYqblfU=
X-Gm-Gg: ASbGnctkKDo6f3i3DPJA5vC0hIYxy/le9ZgJyjoqKi5dkkESyd6mZVi9fyADsK4Nwmj
	iKJt+moD5BFlgdFwM2xAR5pS5Uwa0X0rqjRxqD/DqAGcZEA6wggWhHlmvhgZudEEAAQxFT5pDpI
	LdiBDO5+IV6NsHWobhDB9mNGiWD5pe2K6qkkKh0bxmrcT4cKd5N7+8qDIPI5Ljw1PUDSXO1tKoK
	FTUpTAH5ISN3sCGcEg+7Ge+P/vYT7pm8jAuSPvTHrsVHG8GP+Hvcz7yKfQ0fVQDlRnknZ7eJwih
	kJ1D4FD//0PiuC1hu2m9Mf2uVHOrQd9QFaZDnlvQPu+sIT/jQGaoqOl3pdiAf/OAm0gcd2aVleE
	7sJv8Jq6rWxW/HzIvg0tdk3hJ6XN/xOzIxKAwZhVytegQ4XwSPhIWJrg=
X-Google-Smtp-Source: AGHT+IG+AQa3vNEfZDh2GYoeHvCiqtccLKi1evIwWX4dlloxp4goqioSadQ8Ej/G9S1lL+YRa9kMwg==
X-Received: by 2002:a17:902:f54f:b0:265:89c:251b with SMTP id d9443c01a7336-268137f24f6mr40577165ad.29.1758146152035;
        Wed, 17 Sep 2025 14:55: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 v4 01/18] xen/riscv: detect and initialize G-stage mode
Date: Wed, 17 Sep 2025 23:55:21 +0200
Message-ID: <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce gstage_mode_detect() to probe supported G-stage paging
modes at boot. The function iterates over possible HGATP modes
(Sv32x4 on RV32, Sv39x4/Sv48x4/Sv57x4 on RV64) and selects the
first valid one by programming CSR_HGATP and reading it back.

The selected mode is stored in gstage_mode (marked __ro_after_init)
and reported via printk. If no supported mode is found, Xen panics
since Bare mode is not expected to be used.

Finally, CSR_HGATP is cleared and a local_hfence_gvma_all() is issued
to avoid any potential speculative pollution of the TLB, as required
by the RISC-V spec.

The following issue starts to occur:
 .//asm/flushtlb.h:37:55: error: 'struct page_info'  declared inside
   parameter list will not be visible outside of this definition or
   declaration [-Werror]
 37 | static inline void page_set_tlbflush_timestamp(struct page_info *page)
To resolve it, forward declaration of struct page_info is added to

---
Changes in V5:
 - New patch.
---
 xen/arch/riscv/Makefile                     |  1 +
 xen/arch/riscv/include/asm/flushtlb.h       |  7 ++
 xen/arch/riscv/include/asm/p2m.h            |  4 +
 xen/arch/riscv/include/asm/riscv_encoding.h |  5 ++
 xen/arch/riscv/p2m.c                        | 91 +++++++++++++++++++++
 xen/arch/riscv/setup.c                      |  3 +
 6 files changed, 111 insertions(+)
 create mode 100644 xen/arch/riscv/p2m.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index e2b8aa42c8..264e265699 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -7,6 +7,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/flushtlb.h b/xen/arch/riscv/include/asm/flushtlb.h
index 51c8f753c5..e70badae0c 100644
--- a/xen/arch/riscv/include/asm/flushtlb.h
+++ b/xen/arch/riscv/include/asm/flushtlb.h
@@ -7,6 +7,13 @@
 
 #include 
 
+struct page_info;
+
+static inline void local_hfence_gvma_all(void)
+{
+    asm volatile ( "hfence.gvma zero, zero" ::: "memory" );
+}
+
 /* Flush TLB of local processor for address va. */
 static inline void flush_tlb_one_local(vaddr_t va)
 {
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index e43c559e0c..9d4a5d6a2e 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -6,6 +6,8 @@
 
 #include 
 
+extern unsigned long gstage_mode;
+
 #define paddr_bits PADDR_BITS
 
 /*
@@ -88,6 +90,8 @@ static inline bool arch_acquire_resource_check(struct domain *d)
     return false;
 }
 
+void gstage_mode_detect(void);
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h
index 6cc8f4eb45..b15f5ad0b4 100644
--- a/xen/arch/riscv/include/asm/riscv_encoding.h
+++ b/xen/arch/riscv/include/asm/riscv_encoding.h
@@ -131,13 +131,16 @@
 #define HGATP_MODE_SV32X4		_UL(1)
 #define HGATP_MODE_SV39X4		_UL(8)
 #define HGATP_MODE_SV48X4		_UL(9)
+#define HGATP_MODE_SV57X4		_UL(10)
 
 #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 +173,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 +185,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
new file mode 100644
index 0000000000..56113a2f7a
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+unsigned long __ro_after_init gstage_mode;
+
+void __init gstage_mode_detect(void)
+{
+    unsigned int mode_idx;
+
+    const struct {
+        unsigned long mode;
+        unsigned int paging_levels;
+        const char *name;
+    } modes[] = {
+        /*
+         * Based on the RISC-V spec:
+         *   When SXLEN=32, the only other valid setting for MODE is Sv32,
+         *   a paged virtual-memory scheme described in Section 10.3.
+         *   When SXLEN=64, three paged virtual-memory schemes are defined:
+         *   Sv39, Sv48, and Sv57.
+         */
+#ifdef CONFIG_RISCV_32
+        { HGATP_MODE_SV32X4, 2, "Sv32x4" }
+#else
+        { HGATP_MODE_SV39X4, 3, "Sv39x4" },
+        { HGATP_MODE_SV48X4, 4, "Sv48x4" },
+        { HGATP_MODE_SV57X4, 5, "Sv57x4" },
+#endif
+    };
+
+    gstage_mode = HGATP_MODE_OFF;
+
+    for ( mode_idx = 0; mode_idx < ARRAY_SIZE(modes); mode_idx++ )
+    {
+        unsigned long mode = modes[mode_idx].mode;
+
+        csr_write(CSR_HGATP, MASK_INSR(mode, HGATP_MODE_MASK));
+
+        if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode )
+        {
+            gstage_mode = mode;
+            break;
+        }
+    }
+
+    if ( gstage_mode == HGATP_MODE_OFF )
+        panic("Xen expects that G-stage won't be Bare mode\n");
+
+    printk("%s: G-stage mode is %s\n", __func__, modes[mode_idx].name);
+
+    csr_write(CSR_HGATP, 0);
+
+    /*
+     * From RISC-V spec:
+     *   Speculative executions of the address-translation algorithm behave as
+     *   non-speculative executions of the algorithm do, except that they must
+     *   not set the dirty bit for a PTE, they must not trigger an exception,
+     *   and they must not create address-translation cache entries if those
+     *   entries would have been invalidated by any SFENCE.VMA instruction
+     *   executed by the hart since the speculative execution of the algorithm
+     *   began.
+     * The quote above mention explicitly SFENCE.VMA, but I assume it is true
+     * for HFENCE.VMA.
+     *
+     * Also, despite of the fact here it is mentioned that when V=0 two-stage
+     * address translation is inactivated:
+     *   The current virtualization mode, denoted V, indicates whether the hart
+     *   is currently executing in a guest. When V=1, the hart is either in
+     *   virtual S-mode (VS-mode), or in virtual U-mode (VU-mode) atop a guest
+     *   OS running in VS-mode. When V=0, the hart is either in M-mode, in
+     *   HS-mode, or in U-mode atop an OS running in HS-mode. The
+     *   virtualization mode also indicates whether two-stage address
+     *   translation is active (V=1) or inactive (V=0).
+     * But on the same side, writing to hgatp register activates it:
+     *   The hgatp register is considered active for the purposes of
+     *   the address-translation algorithm unless the effective privilege mode
+     *   is U and hstatus.HU=0.
+     *
+     * Thereby it leaves some room for speculation even in this stage of boot,
+     * so it could be that we polluted local TLB so flush all guest TLB.
+     */
+    local_hfence_gvma_all();
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 483cdd7e17..87ee96bdb3 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     console_init_postirq();
 
+    gstage_mode_detect();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125581.1467472 (Exim 4.92)
	(envelope-from )
	id 1uz084-0007MC-7s; Wed, 17 Sep 2025 21:55:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125581.1467472; Wed, 17 Sep 2025 21:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uz084-0007M5-56; Wed, 17 Sep 2025 21:55:56 +0000
Received: by outflank-mailman (input) for mailman id 1125581;
 Wed, 17 Sep 2025 21:55: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 1uz082-0007Lt-Vu
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:55:55 +0000
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [2607:f8b0:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13e2b581-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:55:52 +0200 (CEST)
Received: by mail-pl1-x630.google.com with SMTP id
 d9443c01a7336-267f0fe72a1so1858795ad.2
 for ; Wed, 17 Sep 2025 14:55:52 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14: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: 13e2b581-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146151; x=1758750951; 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=t7wL9p64D8keeYetVsE8VmLXNMGlwrZzPrEEjyLI3t0=;
        b=blGO3N7e81BDUJ9nY1j2yUIxZYqEPQ+x8D4ap4hLn4JD9NngClCbC12CRlpfRNuomK
         AyaoSE4OUQM6EspYC6kf5R2Ci/VwGzLSZ5f6ihXbTbBoRlABybFr2XPe4fbTWxBSuocm
         kSiv4BMdbI5/SRGXiqZzFVD0SAJoqPqdBOpTY7HKRyp5nvF9NafkSzPU/fvTazmcS7YS
         fAyUmsxKnUjWv0jKw3sUW4iO9gFIAe8UME8bjIrwtjePbpZrabjb9yNwEKGmJhKsZNXM
         POaYDDZ3PRMS7kHJaqqGrNPSWUKhtMiXQAtAhDBpchNE22/mOIQqazYehzmK3v2hj6jE
         c1CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146151; x=1758750951;
        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=t7wL9p64D8keeYetVsE8VmLXNMGlwrZzPrEEjyLI3t0=;
        b=s6NRjpJfCCsSrWPF/90Tt+lQptCF+KVQCup8MY0nNzD6i7P/fQdC8jXHw1zT2GkX17
         KhPnqLTS1dc48oenaV7tlxyMYtAudAr2SxLnu768pvvnwkC5dwBacm3NQVZvPhEQiflg
         MIlNw2GWrb1EhrT9AgLJqJchf0ZaGA9X4syqKABHqnXKAWrNCyBW/TdilbgYPiffOMtr
         LIgFmyC3M3bW9RJBb7WAmcB0edEGaVr2vQW6AvBS+zmUWJGbZcXAJrZWQ7vu7co+zDJv
         ZqA2NFafWxUaqHHepcoZjDtaMMUIbIO5vOqJYrjoAjBEfvzYxVes0tPsfsrTL8R9vSEr
         gUxA==
X-Gm-Message-State: AOJu0Yzl1E1KiQD8G6FnYerLOZrzpMlC2OmSSaXrCJSIblQ4jJa2IsjK
	N8wU+kcmVoePCkc0zORFK4ArCMMH/8xNanqOTdsZCd4ibhTCF93bvpKm8KQ+fVzkXgY=
X-Gm-Gg: ASbGncv0qax9O0ApvHqmKRtWjxHnr5Bfk1O8m2/jRy70QBBikR1ubTIAhiHka0htbOt
	+968lzuPleQjkJg9dEpUYW5n9fb6TD4dlD2RCKIZcBv7qwEQN/ekpDIzxh87qK7TBRx+eVmlQjk
	wM0im92oCtOVfITx7V2Uj5EPOru0QfAwiNjLF6dYKXhwrcEAfgzRWcIvfMuvjxjsRON5COlMmTn
	MgZVdIWFrOFCdwbaxDd1txnDpzTK+LjFj3IH3Pk55S9rbQRbXkVd+u5c3Wryndzm0N4rbuCEZ4t
	VB1BLi5rbY3liNTuiw14b71BMTtGao0Edcvv4x+o60jRriUrdrYOF4SaRFOOkdwN9Xjwh6aP2j4
	gBuH8XO+m8Iy6+AWDB6KO2uEMMOHfVXRu/pHbqzeKOVqY
X-Google-Smtp-Source: AGHT+IEgHMUp3Oo/HXbN6jZZ4INo1TLXrt9jqtZfEzKCEIqFDtAh06tMdONG8vYNaOEe8Vlgv+vS1A==
X-Received: by 2002:a17:903:3888:b0:24c:7b94:2f87 with SMTP id d9443c01a7336-26811ba7117mr36774155ad.14.1758146150634;
        Wed, 17 Sep 2025 14:55: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 ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v4 00/18 for 4.22] xen/riscv: introduce p2m functionality
Date: Wed, 17 Sep 2025 23:55:20 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
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.

---
Changes in V4:
 - Merged to staging:
   - xen/riscv: introduce sbi_remote_hfence_gvma()
   - xen/riscv: introduce sbi_remote_hfence_gvma_vmid()
 - Drop "xen/riscv: introduce page_{get,set}_xenheap_gfn()" as grant tables aren't going to be introduced for the moment. Also, drops other parts connected to grant tables support.
 - All other changes are patch specific.
---
Changes in V3:
 - Introduce metadata table to store P2M types.
 - Use x86's way to allocate VMID.
 - Abstract Arm-specific p2m type name for device MMIO mappings.
 - All other updates please look at specific patch.
---
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.
 - All other changes are patch-specific. Please check them.
---

Oleksii Kurochko (18):
  xen/riscv: detect and initialize G-stage mode
  xen/riscv: introduce VMID allocation and manegement
  xen/riscv: introduce things necessary for p2m initialization
  xen/riscv: construct the P2M pages pool for guests
  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/dom0less: abstract Arm-specific p2m type name for device MMIO
    mappings
  xen/riscv: implement function to map memory in guest p2m
  xen/riscv: implement p2m_set_range()
  xen/riscv: Implement p2m_free_subtree() and related helpers
  xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration
  xen/riscv: implement p2m_next_level()
  xen/riscv: Implement superpage splitting for p2m mappings
  xen/riscv: implement put_page()
  xen/riscv: implement mfn_valid() and page reference, ownership
    handling helpers
  xen/riscv: add support of page lookup by GFN
  xen/riscv: introduce metadata table to store P2M type

 xen/arch/arm/include/asm/p2m.h              |    5 +
 xen/arch/riscv/Makefile                     |    3 +
 xen/arch/riscv/cpufeature.c                 |    1 +
 xen/arch/riscv/include/asm/Makefile         |    1 -
 xen/arch/riscv/include/asm/cpufeature.h     |    1 +
 xen/arch/riscv/include/asm/domain.h         |   23 +
 xen/arch/riscv/include/asm/flushtlb.h       |   13 +-
 xen/arch/riscv/include/asm/mm.h             |   29 +-
 xen/arch/riscv/include/asm/p2m.h            |  183 ++-
 xen/arch/riscv/include/asm/page.h           |   38 +
 xen/arch/riscv/include/asm/paging.h         |   20 +
 xen/arch/riscv/include/asm/riscv_encoding.h |    7 +
 xen/arch/riscv/include/asm/vmid.h           |    8 +
 xen/arch/riscv/mm.c                         |   71 +-
 xen/arch/riscv/p2m.c                        | 1337 +++++++++++++++++++
 xen/arch/riscv/paging.c                     |  137 ++
 xen/arch/riscv/setup.c                      |    6 +
 xen/arch/riscv/stubs.c                      |    5 -
 xen/arch/riscv/vmid.c                       |  193 +++
 xen/common/device-tree/dom0less-build.c     |    2 +-
 20 files changed, 2058 insertions(+), 25 deletions(-)
 create mode 100644 xen/arch/riscv/include/asm/paging.h
 create mode 100644 xen/arch/riscv/include/asm/vmid.h
 create mode 100644 xen/arch/riscv/p2m.c
 create mode 100644 xen/arch/riscv/paging.c
 create mode 100644 xen/arch/riscv/vmid.c

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125585.1467513 (Exim 4.92)
	(envelope-from )
	id 1uz088-0008Gh-Gp; Wed, 17 Sep 2025 21:56:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125585.1467513; Wed, 17 Sep 2025 21:56: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 1uz088-0008Ft-Cw; Wed, 17 Sep 2025 21:56:00 +0000
Received: by outflank-mailman (input) for mailman id 1125585;
 Wed, 17 Sep 2025 21:55: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 1uz087-0007Lt-KD
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:55:59 +0000
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com
 [2607:f8b0:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16eaf01c-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:55:57 +0200 (CEST)
Received: by mail-pl1-x629.google.com with SMTP id
 d9443c01a7336-24457f581aeso2938525ad.0
 for ; Wed, 17 Sep 2025 14:55:57 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 16eaf01c-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146156; x=1758750956; darn=lists.xenproject.org;
        h=content-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=+b7cabvx/1AnkoXHK5wCrIOJ3a++/hduz17G6Xo8SDw=;
        b=DFAnX5weIrb+sSSTbZxir36j+0izbHvqowEnRLeebulzhUG4Co4tTucjMlAiZUqRuB
         HOqg6MhpDkT56giezDuOLLf5b+hsJlu5gJrqrP4DDZRA7aXAB86xNCXryadYBbbRKr0z
         Ec2HOIOQavcL0sn2QmL9w35q4Ir/I1M++HOIdVgPHv1zNBJ4cR9s+4zHNRAzmwpQVexK
         OXLsvOWtHpNbDARrmw/+1u7XJDBnk5DPBFJFbis3isbUtgOApJ1YNsg/Zk2U6MuIfvN6
         np5NUvqYWxD2rXcFWv/eLK69xECik/ICe6ma7cEltMU6sfYE2vFgX6JgDtWVyefRAXcQ
         XFiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146156; x=1758750956;
        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=+b7cabvx/1AnkoXHK5wCrIOJ3a++/hduz17G6Xo8SDw=;
        b=Q/XLHAFAdKaIvgDcOTiSX/UneNdVk7TaTisPQqkJg8+bM8zVzRD0x3xlVgGbVq9ElB
         Vi5whyAN0nbk7u4haDOdxmZ8xgxdvvHjTPWlhk/Bv7Tnc01WbQ6lrixFhLcKYfSSVVMe
         3WXfELrVfSc7lu6x0hgQ1qSsLzuKC9eO2h6m1djyxTJ1qoAwNeVWFjk+BwbC9W2KipPW
         0Sp2oPv1K04nkrqI+rGlXVa7rufNSe3Egjl5wlWfdhG+V0p8kwnHSkMAPCQdMcRNdJ1b
         rj+J1YSEi5UVEqlaiDhacS0cHtdABs0eXAKQr175Qd/DLNSYgYcfBpVNC5MZICLizrGq
         1cmA==
X-Gm-Message-State: AOJu0YyhfJAvPAzUXjKoaPIUnQEsflC6WWPm8hSPRXIOSDC+3XCjmJqB
	SFSBplcxbFY7QHTUZjowF+avE/UAXkGp9KLsAgpttxCm0WR/sJU4zFEdPS4cb19t1tk=
X-Gm-Gg: ASbGncs/mfJww+jwhhR7PlwUO6i6dMdGElA+eviZU7X1h7bQz4o3vRSCZexn7X9DQC1
	e7xZYOnmmryQVIE0b5/HUXbveTgCIuPBHatjMJseiBrKO3AVWqOpyE1u+G1lguTkzXB2IG6uunj
	gMTlfniu8tRu5S0bD68xmOUPz+YyBu3RHZSO2T8BTuWOY6Ud2uSFe8Aso4JdjPXJ3eK7T5Xcna2
	kilu59A1TqqnV8fZ4DQUY7MFpu9YVVTCqJNc1NqgrQy5jtdgyRedwWv5p5QtH/zOER8I+k8D0OB
	njrNtifQFhpsYQQkHAaevpHsnuMpVp00KDo7FYiEVlJsPCWGmARgRLg0WWSeKjVLJIB4ZiU9fMq
	hxxE1nKZ/mkGummBQ8eyUbQUKR3OOptWxMTEWWxvV7qpb
X-Google-Smtp-Source: AGHT+IHJu1nig2OR8jLnjqHuRHXgBacdsnwzzap2pCjxjjqKKAsSAkK5zoktSpM/LMyqRPYaNDAndA==
X-Received: by 2002:a17:902:e94d:b0:24c:965a:f94d with SMTP id d9443c01a7336-26813cfd846mr42361995ad.46.1758146155951;
        Wed, 17 Sep 2025 14:55: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 v4 04/18] xen/riscv: construct the P2M pages pool for guests
Date: Wed, 17 Sep 2025 23:55:24 +0200
Message-ID: <5f678a78a8b19e0283662881c030db76abd6a2c9.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.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.
- Adding implementation of paging_freelist_adjust() and
  paging_domain_init().

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4:
 - s/paging_freelist_init/paging_freelist_adjust.
 - Add empty line between definiton of paging_freelist_adjust()
   and paging_domain_init().
 - Update commit message.
 - Add Acked-by: Jan Beulich .
---
Changes in v3:
 - Drop usage of p2m_ prefix inside struct paging_domain().
 - Introduce paging_domain_init() to init paging struct.
---
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/Makefile             |  1 +
 xen/arch/riscv/include/asm/Makefile |  1 -
 xen/arch/riscv/include/asm/domain.h | 12 ++++++
 xen/arch/riscv/include/asm/paging.h | 13 ++++++
 xen/arch/riscv/p2m.c                | 18 ++++++++
 xen/arch/riscv/paging.c             | 65 +++++++++++++++++++++++++++++
 6 files changed, 109 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/riscv/include/asm/paging.h
 create mode 100644 xen/arch/riscv/paging.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index e2499210c8..6b912465b9 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -6,6 +6,7 @@ obj-y += imsic.o
 obj-y += intc.o
 obj-y += irq.o
 obj-y += mm.o
+obj-y += paging.o
 obj-y += pt.o
 obj-y += p2m.o
 obj-$(CONFIG_RISCV_64) += riscv64/
diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
index bfdf186c68..3824f31c39 100644
--- a/xen/arch/riscv/include/asm/Makefile
+++ b/xen/arch/riscv/include/asm/Makefile
@@ -6,7 +6,6 @@ generic-y += hardirq.h
 generic-y += hypercall.h
 generic-y += iocap.h
 generic-y += irq-dt.h
-generic-y += paging.h
 generic-y += percpu.h
 generic-y += perfc_defn.h
 generic-y += random.h
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index e688980efa..316e7c6c84 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 
 
@@ -24,11 +26,21 @@ struct arch_vcpu {
     struct vcpu_vmid vmid;
 };
 
+struct paging_domain {
+    spinlock_t lock;
+    /* Free pages from the pre-allocated pool */
+    struct page_list_head freelist;
+    /* Number of pages from the pre-allocated pool */
+    unsigned long total_pages;
+};
+
 struct arch_domain {
     struct hvm_domain hvm;
 
     /* Virtual MMU */
     struct p2m_domain p2m;
+
+    struct paging_domain paging;
 };
 
 #include 
diff --git a/xen/arch/riscv/include/asm/paging.h b/xen/arch/riscv/include/asm/paging.h
new file mode 100644
index 0000000000..98d8b06d45
--- /dev/null
+++ b/xen/arch/riscv/include/asm/paging.h
@@ -0,0 +1,13 @@
+#ifndef ASM_RISCV_PAGING_H
+#define ASM_RISCV_PAGING_H
+
+#include 
+
+struct domain;
+
+int paging_domain_init(struct domain *d);
+
+int paging_freelist_adjust(struct domain *d, unsigned long pages,
+                           bool *preempted);
+
+#endif /* ASM_RISCV_PAGING_H */
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 70f9e97ab6..dc0f2b2a23 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 unsigned long __ro_after_init gstage_mode;
@@ -104,8 +105,25 @@ int p2m_init(struct domain *d)
      */
     p2m->domain = d;
 
+    paging_domain_init(d);
+
     rwlock_init(&p2m->lock);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
 
     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)
+{
+    int rc;
+
+    if ( (rc = paging_freelist_adjust(d, pages, preempted)) )
+        return rc;
+
+    return 0;
+}
diff --git a/xen/arch/riscv/paging.c b/xen/arch/riscv/paging.c
new file mode 100644
index 0000000000..2df8de033b
--- /dev/null
+++ b/xen/arch/riscv/paging.c
@@ -0,0 +1,65 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int paging_freelist_adjust(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.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 pages.\n");
+                return -ENOMEM;
+            }
+            ACCESS_ONCE(d->arch.paging.total_pages)++;
+            page_list_add_tail(pg, &d->arch.paging.freelist);
+        }
+        else if ( d->arch.paging.total_pages > pages )
+        {
+            /* Need to return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.freelist);
+            if ( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.total_pages)--;
+                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free pages, 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;
+}
+
+/* Domain paging struct initialization. */
+int paging_domain_init(struct domain *d)
+{
+    spin_lock_init(&d->arch.paging.lock);
+    INIT_PAGE_LIST_HEAD(&d->arch.paging.freelist);
+
+    return 0;
+}
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125586.1467523 (Exim 4.92)
	(envelope-from )
	id 1uz089-00006d-Ut; Wed, 17 Sep 2025 21:56:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125586.1467523; Wed, 17 Sep 2025 21:56: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 1uz089-00006M-Qa; Wed, 17 Sep 2025 21:56:01 +0000
Received: by outflank-mailman (input) for mailman id 1125586;
 Wed, 17 Sep 2025 21:56: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 1uz088-0007Lu-BM
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:00 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 17d37a5c-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:55:59 +0200 (CEST)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-2680cf68265so2365365ad.2
 for ; Wed, 17 Sep 2025 14:55:59 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 17d37a5c-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146157; x=1758750957; darn=lists.xenproject.org;
        h=content-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=KISvI+cSCGQuBbffB7BgGhIGyaXm3yteTEaBjxd0dvw=;
        b=hwc+KA/djX59hShLamXAJ8W1Ym6pcbUSk8vGcRXAleDHdbfFtdjWllZjEV5+7M3fXi
         MQ/u4unguCblMIZkdArAXBFPXppvp4E8cInf6H3han5j7A8vR2MqaQdSF8WPn/XIwBfK
         t1Xj83sBKcxFxG6QT/9yHnuM9BK40Dp7UpdeZQdtOdz4/RYJzIAir6MRz5/+uZZeFGCA
         l95xvLGrP2de9q8b2BP7pBtio5M5B4edarT7m4YRr6F3Fl2Wgyjd8n62GK+EQXHRIFmK
         e2qLHLRvjGc8d8IEDcOJc9bLoFbbmLQC8n4Qz5onMva7RuIcgrOTY4IMt5So9UZ4mVpz
         BXwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146157; x=1758750957;
        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=KISvI+cSCGQuBbffB7BgGhIGyaXm3yteTEaBjxd0dvw=;
        b=I5AlVK4R4XRDJQOcFjrEMl7GqCT5sWxndAlzuDbOWwpgI9aCLPk+wiOBYlwIyAeuK+
         V1Vnvnu+KxmMm/uink3d/4g8RtPxvddR5mj+LVWNFMhxFLPzNBas+w7JQzqYYwBdhkcA
         kMrQffeJum6zuVxayOPbYg/XxaeBrgRTL00XXess1FkUukirIZ6DDnchMgdlFnPIm6AN
         IyBVcroZL9WG435+lIobjAkFyeK4ZfVyWLi7e+/uLnAADZrwSwo2TiD7g7MesVHorwY/
         kdFPhI4nOZf4O7HQXkkcdXChyjo3noSqCuNnIfb4UlsrTIMLl1kMKx/LBLtrcMRgQo/1
         yKIw==
X-Gm-Message-State: AOJu0YzV9eOzuSWltj2HcBDlGh/HRncGDF7K3gfZNZG4jzRD7Dj1zK8F
	SnRH9VdVa44GkC++W+DodblAJxmrL4CIFY7+Jmd/Gc9hxoP+7Tai3C7hzD0Bth5feDs=
X-Gm-Gg: ASbGncvPH5Cw7jgGvwZR+I6T9ClI0ZIKWPInDM6johiTHaN3b4rEMpYgYNI4Nr5RMmO
	6ApyDgnJt1w52iephm2aEayHdyDRzTLtUUyqSc4pL6jRH3PEKl0LaM9kT8wp+6FluoPLB0/PcD4
	/g054Xr1hVmqLzG0v2Itz+Pjd0H+5LOn7jK40qwU/8/+aRWxM6bQ6laujXMEw+Gy5BsyLxO794J
	Pov1tJsEhP7dbzdNwAOS4b6xcWNxUZXJ6j6Dkc+5YN7xiGFtsBWZncozQP9DV4CNTcj1lgKvkiN
	3U2P0aCJZWITehRtFX5Wwz/a0mvacG3pCdO7A2RgsF+rVuYZlO4jCgHl1nSfe8E8mVUT/dbbCTc
	O1lJhgZWpcZ2poJYX6y5VySXpHZlSUweyAnH1pt2vKus3XXtLk13qYrk=
X-Google-Smtp-Source: AGHT+IH7EiuupKV2fG/SCMRtQtoVRqq5BxwZOQlRResiuZUa4MT3z9f4dMDqxoKUMA4xzS3nbJZfTA==
X-Received: by 2002:a17:902:ec86:b0:24c:7b94:2f53 with SMTP id d9443c01a7336-268119b8394mr52036305ad.6.1758146157270;
        Wed, 17 Sep 2025 14:55: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 v4 05/18] xen/riscv: add root page table allocation
Date: Wed, 17 Sep 2025 23:55:25 +0200
Message-ID: <2b636ea03bf82cae50df87d525e3f58b68f16cb2.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.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_alloc_root_table(), p2m_allocate_root()
  helpers to allocate and zero a 16 KiB root page table, as mandated
  by the RISC-V privileged specification for Sv32x4/Sv39x4/Sv48x4/Sv57x4
  modes.
- Update p2m_init() to inititialize p2m_root_order.
- Add maddr_to_page() and page_to_maddr() macros for easier address
  manipulation.
- Introduce paging_ret_pages_to_domheap() to return some pages before
  allocate 16 KiB pages for root page table.
- Allocate root p2m table after p2m pool is initialized.
- Add construct_hgatp() to construct the hgatp register value based on
  p2m->root, p2m->hgatp_mode and VMID.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Drop hgatp_mode from p2m_domain as gstage_mode was introduced and
   initlialized earlier patch. So use gstage_mode instead.
 - s/GUEST_ROOT_PAGE_TABLE_SIZE/GSTAGE_ROOT_PAGE_TABLE_SIZE.
 - Drop p2m_root_order and re-define P2M_ROOT_ORDER:
     #define P2M_ROOT_ORDER  (ilog2(GSTAGE_ROOT_PAGE_TABLE_SIZE) - PAGE_SHIFT)
 - Update implementation of construct_hgatp(): use introduced gstage_mode
   and use MASK_INSRT() to construct ppn value.
 - Drop nr_root_pages variable inside p2m_alloc_root_table().
 - Update the printk's message inside paging_ret_pages_to_domheap().
 - Add an introduction of clean_pte member of p2m_domain structure to this
   patch as it is started to be used here.
   Rename clean_pte to clean_dcache.
 - Drop p2m_allocate_root() function as it is going to be used only in one
   place.
 - Propogate rc from p2m_alloc_root_table() in p2m_set_allocation().
 - Return P2M_ROOT_PAGES to freelist in case of allocation of root page
   table failed.
 - Add allocated root tables pages to p2m->pages pool so a usage of pages
   could be properly taken into account.
---
Changes in v3:
 - Drop insterting of p2m->vmid in hgatp_from_page() as now vmid is allocated
   per-CPU, not per-domain, so it will be inserted later somewhere in
   context_switch or before returning control to a guest.
 - use BIT() to init nr_pages in p2m_allocate_root() instead of open-code
   BIT() macros.
 - Fix order in clear_and_clean_page().
 - s/panic("Specify more xen,domain-p2m-mem-mb\n")/return NULL.
 - Use lock around a procedure of returning back pages necessary for p2m
   root table.
 - Update the comment about allocation of page for root page table.
 - Update an argument of hgatp_from_page() to "struct page_info *p2m_root_page"
   to be consistent with the  function name.
 - Use p2m_get_hostp2m(d) instead of open-coding it.
 - Update the comment above the call of p2m_alloc_root_table().
 - Update the comments in p2m_allocate_root().
 - Move part which returns some page to domheap before root page table allocation
   to paging.c.
 - Pass p2m_domain * instead of struct domain * for p2m_alloc_root_table().
 - Introduce construct_hgatp() instead of hgatp_from_page().
 - Add vmid and hgatp_mode member of struct p2m_domain.
 - Add explanatory comment above clean_dcache_va_range() in
   clear_and_clean_page().
 - Introduce P2M_ROOT_ORDER and P2M_ROOT_PAGES.
 - Drop vmid member from p2m_domain as now we are using per-pCPU
   VMID allocation.
 - Update a declaration of construct_hgatp() to recieve VMID as it
   isn't per-VM anymore.
 - Drop hgatp member of p2m_domain struct as with the new VMID scheme
   allocation construction of hgatp will be needed more often.
 - Drop is_hardware_domain() case in p2m_allocate_root(), just always
   allocate root using p2m pool pages.
 - Refactor p2m_alloc_root_table() and p2m_alloc_table().
---
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            |  15 +++
 xen/arch/riscv/include/asm/paging.h         |   3 +
 xen/arch/riscv/include/asm/riscv_encoding.h |   2 +
 xen/arch/riscv/p2m.c                        |  90 +++++++++++++++-
 xen/arch/riscv/paging.c                     | 108 +++++++++++++++-----
 6 files changed, 193 insertions(+), 29 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 9283616c02..dd8cdc9782 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -167,6 +167,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 2672dcdecb..7b263cb354 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -2,6 +2,7 @@
 #ifndef ASM__RISCV__P2M_H
 #define ASM__RISCV__P2M_H
 
+#include 
 #include 
 #include 
 #include 
@@ -11,6 +12,9 @@
 
 extern unsigned long gstage_mode;
 
+#define P2M_ROOT_ORDER  (ilog2(GSTAGE_ROOT_PAGE_TABLE_SIZE) - PAGE_SHIFT)
+#define P2M_ROOT_PAGES  BIT(P2M_ROOT_ORDER, U)
+
 #define paddr_bits PADDR_BITS
 
 /* Get host p2m table */
@@ -26,6 +30,9 @@ 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;
+
     /* Back pointer to domain */
     struct domain *domain;
 
@@ -39,6 +46,12 @@ struct p2m_domain {
      * shattered), call p2m_tlb_flush_sync().
      */
     bool need_flush;
+
+    /*
+     * Indicate if it is required to clean the cache when writing an entry or
+     * when a page is needed to be fully cleared and cleaned.
+     */
+    bool clean_dcache;
 };
 
 /*
@@ -125,6 +138,8 @@ void gstage_mode_detect(void);
 
 int p2m_init(struct domain *d);
 
+unsigned long construct_hgatp(struct p2m_domain *p2m, uint16_t vmid);
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/include/asm/paging.h b/xen/arch/riscv/include/asm/paging.h
index 98d8b06d45..befad14f82 100644
--- a/xen/arch/riscv/include/asm/paging.h
+++ b/xen/arch/riscv/include/asm/paging.h
@@ -10,4 +10,7 @@ int paging_domain_init(struct domain *d);
 int paging_freelist_adjust(struct domain *d, unsigned long pages,
                            bool *preempted);
 
+int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages);
+int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages);
+
 #endif /* ASM_RISCV_PAGING_H */
diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h
index b15f5ad0b4..8890b903e1 100644
--- a/xen/arch/riscv/include/asm/riscv_encoding.h
+++ b/xen/arch/riscv/include/asm/riscv_encoding.h
@@ -188,6 +188,8 @@
 #define HGATP_MODE_MASK			HGATP32_MODE_MASK
 #endif
 
+#define GSTAGE_ROOT_PAGE_TABLE_SIZE	KB(16)
+
 #define TOPI_IID_SHIFT			16
 #define TOPI_IID_MASK			0xfff
 #define TOPI_IPRIO_MASK		0xff
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index dc0f2b2a23..ad0478f155 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -95,6 +96,70 @@ void __init gstage_mode_detect(void)
     local_hfence_gvma_all();
 }
 
+static void clear_and_clean_page(struct page_info *page, bool clean_dcache)
+{
+    clear_domain_page(page_to_mfn(page));
+
+    /*
+     * If the IOMMU doesn't support coherent walks and the p2m tables are
+     * shared between the CPU and IOMMU, it is necessary to clean the
+     * d-cache.
+     */
+    if ( clean_dcache )
+        clean_dcache_va_range(page, PAGE_SIZE);
+}
+
+unsigned long construct_hgatp(struct p2m_domain *p2m, uint16_t vmid)
+{
+    return MASK_INSR(mfn_x(page_to_mfn(p2m->root)), HGATP_PPN) |
+           MASK_INSR(gstage_mode, HGATP_MODE_MASK) |
+           MASK_INSR(vmid, HGATP_VMID_MASK);
+}
+
+static int p2m_alloc_root_table(struct p2m_domain *p2m)
+{
+    struct domain *d = p2m->domain;
+    struct page_info *page;
+    int rc;
+
+    /*
+     * Return back P2M_ROOT_PAGES to assure the root table memory is also
+     * accounted against the P2M pool of the domain.
+     */
+    if ( (rc = paging_ret_pages_to_domheap(d, P2M_ROOT_PAGES)) )
+        return rc;
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * 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, P2M_ROOT_ORDER, MEMF_no_owner);
+    if ( !page )
+    {
+        /*
+         * If allocation of root table pages fails, the pages acquired above
+         * must be returned to the freelist to maintain proper freelist
+         * balance.
+         */
+        paging_ret_pages_to_freelist(d, P2M_ROOT_PAGES);
+
+        return -ENOMEM;
+    }
+
+    for ( unsigned int i = 0; i < P2M_ROOT_PAGES; i++ )
+    {
+        clear_and_clean_page(page + i, p2m->clean_dcache);
+
+        page_list_add(page + i, &p2m->pages);
+    }
+
+    p2m->root = page;
+
+    return 0;
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -110,6 +175,19 @@ int p2m_init(struct domain *d)
     rwlock_init(&p2m->lock);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
 
+    /*
+     * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
+     * is not ready for RISC-V support.
+     *
+     * When CONFIG_HAS_PASSTHROUGH=y, p2m->clean_dcache must be properly
+     * initialized.
+     * At the moment, it defaults to false because the p2m structure is
+     * zero-initialized.
+     */
+#ifdef CONFIG_HAS_PASSTHROUGH
+#   error "Add init of p2m->clean_dcache"
+#endif
+
     return 0;
 }
 
@@ -120,10 +198,20 @@ int p2m_init(struct domain *d)
  */
 int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
 {
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int rc;
 
     if ( (rc = paging_freelist_adjust(d, pages, preempted)) )
         return rc;
 
-    return 0;
+    /*
+     * First, initialize p2m pool. 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 ( !p2m->root )
+        rc = p2m_alloc_root_table(p2m);
+
+    return rc;
 }
diff --git a/xen/arch/riscv/paging.c b/xen/arch/riscv/paging.c
index 2df8de033b..ed537fee07 100644
--- a/xen/arch/riscv/paging.c
+++ b/xen/arch/riscv/paging.c
@@ -4,46 +4,67 @@
 #include 
 #include 
 
+static int paging_ret_page_to_domheap(struct domain *d)
+{
+    struct page_info *page;
+
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    /* Return memory to domheap. */
+    page = page_list_remove_head(&d->arch.paging.freelist);
+    if( page )
+    {
+        ACCESS_ONCE(d->arch.paging.total_pages)--;
+        free_domheap_page(page);
+    }
+    else
+    {
+        printk(XENLOG_ERR
+                "Failed to free P2M pages, P2M freelist is empty.\n");
+        return -ENOMEM;
+    }
+
+    return 0;
+}
+
+static int paging_ret_page_to_freelist(struct domain *d)
+{
+    struct page_info *page;
+
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    /* Need to allocate more memory from domheap */
+    page = alloc_domheap_page(d, MEMF_no_owner);
+    if ( page == NULL )
+    {
+        printk(XENLOG_ERR "Failed to allocate pages.\n");
+        return -ENOMEM;
+    }
+    ACCESS_ONCE(d->arch.paging.total_pages)++;
+    page_list_add_tail(page, &d->arch.paging.freelist);
+
+    return 0;
+}
+
 int paging_freelist_adjust(struct domain *d, unsigned long pages,
                            bool *preempted)
 {
-    struct page_info *pg;
-
     ASSERT(spin_is_locked(&d->arch.paging.lock));
 
     for ( ; ; )
     {
+        int rc = 0;
+
         if ( d->arch.paging.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 pages.\n");
-                return -ENOMEM;
-            }
-            ACCESS_ONCE(d->arch.paging.total_pages)++;
-            page_list_add_tail(pg, &d->arch.paging.freelist);
-        }
+            rc = paging_ret_page_to_freelist(d);
         else if ( d->arch.paging.total_pages > pages )
-        {
-            /* Need to return memory to domheap */
-            pg = page_list_remove_head(&d->arch.paging.freelist);
-            if ( pg )
-            {
-                ACCESS_ONCE(d->arch.paging.total_pages)--;
-                free_domheap_page(pg);
-            }
-            else
-            {
-                printk(XENLOG_ERR
-                       "Failed to free pages, freelist is empty.\n");
-                return -ENOMEM;
-            }
-        }
+            rc = paging_ret_page_to_domheap(d);
         else
             break;
 
+        if ( rc )
+            return rc;
+
         /* Check to see if we need to yield and try again */
         if ( preempted && general_preempt_check() )
         {
@@ -55,6 +76,37 @@ int paging_freelist_adjust(struct domain *d, unsigned long pages,
     return 0;
 }
 
+int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages)
+{
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    for ( unsigned int i = 0; i < nr_pages; i++ )
+    {
+        int rc = paging_ret_page_to_freelist(d);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
+int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages)
+{
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    if ( ACCESS_ONCE(d->arch.paging.total_pages) < nr_pages )
+        return false;
+
+    for ( unsigned int i = 0; i < nr_pages; i++ )
+    {
+        int rc = paging_ret_page_to_domheap(d);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
 /* Domain paging struct initialization. */
 int paging_domain_init(struct domain *d)
 {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125587.1467533 (Exim 4.92)
	(envelope-from )
	id 1uz08B-0000Od-9E; Wed, 17 Sep 2025 21:56:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125587.1467533; Wed, 17 Sep 2025 21:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uz08B-0000N6-50; Wed, 17 Sep 2025 21:56:03 +0000
Received: by outflank-mailman (input) for mailman id 1125587;
 Wed, 17 Sep 2025 21:56: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 1uz08A-0007Lt-0B
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:02 +0000
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com
 [2607:f8b0:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 188a8614-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:00 +0200 (CEST)
Received: by mail-pl1-x629.google.com with SMTP id
 d9443c01a7336-26060bcc5c8so2756425ad.1
 for ; Wed, 17 Sep 2025 14:56:00 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 188a8614-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146158; x=1758750958; darn=lists.xenproject.org;
        h=content-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=TYl+pG2N9Nhab3KxViLh94cYkpftDfJm9blLM7BMKXo=;
        b=ZabRb93aMI/6jVxFRW65/LeNkDgD5LGWU8azLn5lD85DtbNeEwZHNHKw1oN7gVCIti
         YNWPUTuoMus5Ih/rfts9SpQ2Urc/SQH5LCur9Z0iJGOW/bKwVeKjU3qORwlEZnXMDiYr
         hFlXSceAyb87nmIE/n2SzIAD/pYmNne/UyR4nrFygVu0RQmFeLQjeelLQw14Gv0ipgER
         2Z6WHQgTmkaCr1fVomrAAMvPCcY0qrazIiHTkUfbUatbl9NSVZnrd5IR1tNUPlP3MJgY
         7BodOzkQ8eQAgOfJuuzq9m/6yHODvWEsMFheoGhZuyAM2/8nV8kMMUgSsSD9AVUzMJA5
         aY7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146158; x=1758750958;
        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=TYl+pG2N9Nhab3KxViLh94cYkpftDfJm9blLM7BMKXo=;
        b=tUzPrmqXmcwLZnEMGLz+9ftpxafQC42jczdH1qZubRqvuGec9oYHl1qbKBFLj7mtUR
         1bEKAT+oBXTzUgXllBmg7hTVmwrOvRYzmXEi1R6MlQ08A8IYs7scv3ugJOHIl/6qInjn
         4s985EQ3XtNqQQhhO5egt8Zyew8FzUhAJej9Hpc5rn6b1EJFtvpjpoms3sVGz2OhIK1J
         TVqTuTgOM/hD8LPJ7kaHZDUQQdHyZXOadV2qyH5kCVvTeecC5etbVmFkMmn2gDS9E3Bf
         tJD9m6wMXqEiS4PlKXsu54RzujmO9WYMyn7JUUs7lystaWwoyNVnrHf9x+Pkyun+3bzr
         ztPA==
X-Gm-Message-State: AOJu0YxVF3tiiNGc6JuEXy1+SlyRnsex17gu3kwHehev0zymK8qhDBTt
	n7nKjIhPA45/xQD1BDkedwwyxxnfF4arfkflkvY4Ut/kbhzCuxhGPzvwayIzNkpUChg=
X-Gm-Gg: ASbGnctQdL40e5moIb6zA8jKWHjVtw6OmRy7YYKk8625n2mOph2Koeh2BpDcE/jgZSy
	6Qp+rwcXypKVnhf3ou/NstPgoiumTQwIJdtf04XJ4i4HEB+zv/hm5KBCtKea8GCmSv7LGCv2ypT
	oH8TfPFaouQTLrkm7LUmVs8q+N+TRALodeAB+t67UOpgwgQ17YTCp8RSH5Y7knqrrG8K6H0IpUL
	NQ+fQTOmUuC3YWZij8NZCK/U7stO12T2qII9idxWHNG0+Jan/olRjbesy+JTk9xsVRdmhJIevwA
	agZntRQnZHQDWLNFlJIdQXtpX6dS7M/bGtClORiOGf4e3S4qfIxOgtfLhkmgtsCDL3+Y+BXAmPJ
	/K+quxbWNJoVeEutBmwcdVpJydWYKmRvTA+M3wKybcGSD
X-Google-Smtp-Source: AGHT+IFnumY9siDQegtICLpdxupa9QH6vR74mAKgKmfzrPcceZ89BYgc2V5zoRaIeToLTpYbTDMb8Q==
X-Received: by 2002:a17:902:ea03:b0:24b:4a9a:703a with SMTP id d9443c01a7336-2681216914bmr54014015ad.17.1758146158593;
        Wed, 17 Sep 2025 14:55: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 
Subject: [PATCH v4 06/18] xen/riscv: introduce pte_{set,get}_mfn()
Date: Wed, 17 Sep 2025 23:55:26 +0200
Message-ID: <88bac831f9d1dddd1186179f8fa6fbb44a07dd35.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.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 
Acked-by: Jan Beulich 
---
Changes in V4:
 - Nothing changed. Only Rebase.
---
Changes in V3:
 - Add Acked-by: Jan Beulich .
---
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 ddcc4da0a3..66cb192316 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -112,6 +112,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 bool pte_is_valid(pte_t p)
 {
     return p.pte & PTE_VALID;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125588.1467542 (Exim 4.92)
	(envelope-from )
	id 1uz08C-0000ek-L3; Wed, 17 Sep 2025 21:56:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125588.1467542; Wed, 17 Sep 2025 21: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 1uz08C-0000eV-HF; Wed, 17 Sep 2025 21:56:04 +0000
Received: by outflank-mailman (input) for mailman id 1125588;
 Wed, 17 Sep 2025 21:56: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 1uz08B-0007Lt-Gs
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:03 +0000
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com
 [2607:f8b0:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19608110-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:01 +0200 (CEST)
Received: by mail-pg1-x531.google.com with SMTP id
 41be03b00d2f7-b4cb3367d87so212305a12.3
 for ; Wed, 17 Sep 2025 14:56:01 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.55.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:55: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: 19608110-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146160; x=1758750960; darn=lists.xenproject.org;
        h=content-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=JZcLmNQkVQOLKgrTuI68wuQc9H659mDMILoNkE3vd5o=;
        b=Noln9XBpYP+9HGHlbEUySgHK4rUMu9nwiVdXhn1bBDjNjLGCHi8znj8bYNe7/p4DgA
         pC18TYGZn7fBYE2Xtgu1GwT9Iek+akIbKVAIT4KqdL4fkZjtEViTF74eNbGX3U4tolun
         gnni4gtbDT9Inw5HyM9uRb0YH096id6vp3MDURx9MPBbVJ8DmRdYk6dV2fktb4Wovaq3
         mFaJjwZ1G0i+qP0vCMxWJr4iszE9ejR9VNtsCGy3t382D+RCJhqGlaOt2lg7SfIG2oMZ
         MjJ44S4ISoNPvdy1sFrkT0Aeg+UGxPzP8Z5/PR7Blj7SZarS1U5FqSgGJeeOt08RElG2
         OOZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146160; x=1758750960;
        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=JZcLmNQkVQOLKgrTuI68wuQc9H659mDMILoNkE3vd5o=;
        b=fLN+gOCXj24Z5dEnEwzCCUGbXki1zleNs0gvo2LW5QZW+r431QwzWEdBtP4c/38APM
         EnQlRNXGvX3MkuAE8H8qz2efh4b7Ho0JNXrZvcOyI20r2GyVEmKDyDRm9xo8FcjvTs4V
         1oYucmyVBhnvX4sONhaMQZUUcXtqNvzYKOitclvZkLw+kZ+ciXrKjcOUYw+VlanxY9oG
         3kHIoRj6Kg1IpXz3nFttFZJXUemizEUWnGiTTyA4+9PVQ7Z4uGp1w3v48BE8Ll7LrQCy
         qb5ghXj6sXh0KztEzV3lgWyjhGV7aBBivB8LrbxFqyswCYFCtsccKJKzQh09rE73rKW9
         zWZw==
X-Gm-Message-State: AOJu0YxLiWVnLPK9k2rweQWtnUWegckTSfgjg8Of2eVTihU7y/DUnp2K
	kftIg7H7ej0Mztm2R931uZIMaGFgX3ER0TPLeGnP3224m5qIQJBczJCwC5XnDl9nR3g=
X-Gm-Gg: ASbGnctxmOZH419O8jDD/lGLew1l+ccPo1cN3RM1NYqN9XySV4W7ofJZmdW+qfGL8i2
	Szs9UFuWzGFOmnXbwpNJ8Bf5RVQMFVtVT+ntlepEbvKR4Tgidj5miinwzlf3AFyXx3zSrpN6y0Y
	NMIktwrguv8d1VEs1a0VKC2FwedCljGzrpvVMBZosRvib4lXGkagWRlR4nIP1iRpGF1TWBsj5XR
	qHzlG9G5T6cg2fP0LvYC5ejeOHXkteFi65CDFo2pI0z71zfCuqLMtWCFd8O3A2wwOex8l7HaRrb
	mbilpbGdrOyFWJAiCJvULqN/NY1pgdpyEXIvzBkUu1DvrvJ90kgXPZBgCqCbUJRN0Aavb5sQQjm
	E9AePJGf7PxdWAJ7XBlSYHua+amBc3fYuVOEZ8mWEKf0Z
X-Google-Smtp-Source: AGHT+IH8uiEcadEbIByO4YCuV4gqgC1K71GPzV6LiXaIFZ9r0h1xrpWNBIpY9saoXckBlG1bA29qmQ==
X-Received: by 2002:a17:903:2acd:b0:25d:d848:1cca with SMTP id d9443c01a7336-268136f9cccmr41990305ad.35.1758146159902;
        Wed, 17 Sep 2025 14:55: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 v4 07/18] xen/riscv: add new p2m types and helper macros for type classification
Date: Wed, 17 Sep 2025 23:55:27 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Extended p2m_type_t with additional types: p2m_mmio_direct,
  p2m_ext_storage.
- Added macros to classify memory types: P2M_RAM_TYPES.
- Introduced helper predicates: p2m_is_ram(), p2m_is_any_ram().
- Introduce arch_dt_passthrough() to tell handle_passthrough_prop()
  from common code how to map device memory.
- Introduce p2m_first_external for detection for relational operations
  with p2m type which is stored outside P2M's PTE bits.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Drop underscode in p2m_to_mask()'s argument and for other similar helpers.
 - Introduce arch_dt_passthrough_p2m_type() instead of p2m_mmio_direct.
 - Drop for the moment grant tables related stuff as it isn't going to be used in the nearest future.
---
Changes in V3:
 - Drop p2m_ram_ro.
 - Rename p2m_mmio_direct_dev to p2m_mmio_direct_io to make it more RISC-V specicific.
 - s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
---
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 | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 7b263cb354..8a6f5f3092 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -64,8 +64,29 @@ struct p2m_domain {
 typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_mmio_direct_io, /* Read/write mapping of genuine Device MMIO area,
+                           PTE_PBMT_IO will be used for such mappings */
+    p2m_ext_storage,    /* Following types'll be stored outsude PTE bits: */
+
+    /* Sentinel — not a real type, just a marker for comparison */
+    p2m_first_external = p2m_ext_storage,
 } p2m_type_t;
 
+static inline p2m_type_t arch_dt_passthrough_p2m_type(void)
+{
+    return p2m_mmio_direct_io;
+}
+
+/* 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))
+
+/* 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)
+
 #include 
 
 static inline int get_page_and_type(struct page_info *page,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125589.1467553 (Exim 4.92)
	(envelope-from )
	id 1uz08E-00010s-Ez; Wed, 17 Sep 2025 21:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125589.1467553; Wed, 17 Sep 2025 21:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uz08E-0000zg-96; Wed, 17 Sep 2025 21:56:06 +0000
Received: by outflank-mailman (input) for mailman id 1125589;
 Wed, 17 Sep 2025 21:56:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uz08C-0007Lt-EW
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:04 +0000
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com
 [2607:f8b0:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19f4cffd-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:02 +0200 (CEST)
Received: by mail-pl1-x636.google.com with SMTP id
 d9443c01a7336-267f0fe72a1so1859475ad.2
 for ; Wed, 17 Sep 2025 14:56:02 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 19f4cffd-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146161; x=1758750961; darn=lists.xenproject.org;
        h=content-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=Q+LjsUjHhvVbZESumoiysJfqjc0SNUhGIIys/BFmCGk=;
        b=Rb9Bxxa75/hl3ERzSiyFdmDc6UaMxadvnL0g0kFkTPtBkNVsjwaoj46a20MFhK4mfP
         vt5WJEqX7qWydFIn0XinYLaumMsOGJc9zFo6rtsMKBgR6qkkiyBTq8P79gtUn7MVD9oX
         1a+n3BjsJLlXJiw1wJIp4bCfhpXbP6zMROEpJb/3tTpoySHRKQHKUkjp33CYtmAUnPDW
         yR70f1YbL7XO2mfbZYoxGjtbIyEmT2Jn+WMydR4Gw11aBrSCYX0KB4pR30f7iLUV47zP
         mtZdZuKU2mBHX5ZR2Hh/QumW8j141M5l20ONCDiKM6ROQ6e2XE/CJd7E7jYxjUffixH2
         fh0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146161; x=1758750961;
        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=Q+LjsUjHhvVbZESumoiysJfqjc0SNUhGIIys/BFmCGk=;
        b=LBywySMLMnafwVPXMgRWdNx5Dd2+eZJcquTPxHJ6mnBRF52C6yPIcSe+cUTa6mmq8A
         pdOl1PS3D3cuxkwbXdKSjkN+3k3ONRDQYY+/m7xVp562zFueNG5TXbodOHqFmRQIjFQU
         k67fTjfEVGqqEEKvY+Iv0cIQX61LNkXVF2oR1yikfO0F2kGsnUP2VJUvTmYXWpZLQmoh
         ExBKAir7xQ09Dp1Z9vimfW8CM7ckOPm9OJv3zNrZDDfMtsUtQkHfaXguSrToXHG2iOaR
         ZuqvuHmyS9i4E5KafnRHXVz+cu8LfrXkgzUaVYLQoQIqZIggCtyjeQhEJUlkpjt/XVo9
         CAiw==
X-Gm-Message-State: AOJu0Yz3HPtT/06UIDOydrRcpwiT/i5DnYj3tv/q3yFTYwXN8Efab+d/
	hCQ40oNWWIWlZI79o8FseaP3n+SZ+i+BaLnvOmVhJlC4BFp8CuyxcI4bEyqhaQUH58I=
X-Gm-Gg: ASbGncsSTrAGTXPWWdWo4iDtA4lOp9CY5yZRAstRp3FiOecWKwUvZwg33XS0z2INFuA
	zilyNqQJ4rsWk2lkDUYVMtVisKvnWTx6PTomKz9K3OTEjmyKUS1FUKmC5PEuqaRvN1ZS/5Cya0x
	2EoRmRpa/wFjsMpGqQrq01jGvHQQo+wKx8VGRK596z9ZHCGZiC2HvfaQHbvymUTMeHtlrdX1EB2
	8IaNooXkvA9t7VAJ6avvn+fWMc21oqs3oPR/GSAQBX+q7Vqck7U7e9CayD2BPlMhckYCiLEp/XE
	e1BhIK91YKTj6BXcxGFt5jTic3m9Isk0njZ+b4qcUnDqAVqJvBp9dVvrZkMawm+yza7rEwixMkS
	ZCmTQRxnY8G4/kbwAR1Vs63VRBlG7srV/hOFvESgtBVDa
X-Google-Smtp-Source: AGHT+IGNPLadatCVRmi8Phsax/VmTFL+UZNvj6wraEgXA5r4ZJ+TzygZwFd7i7FiUN3kSaK5SnrXFA==
X-Received: by 2002:a17:902:fc86:b0:264:70e9:dcb1 with SMTP id d9443c01a7336-26813cfc1edmr43504565ad.56.1758146161001;
        Wed, 17 Sep 2025 14:56:01 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jan Beulich 
Subject: [PATCH v4 08/18] xen/dom0less: abstract Arm-specific p2m type name for device MMIO mappings
Date: Wed, 17 Sep 2025 23:55:28 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce arch_dt_passthrough_p2m_type() and use it instead of
`p2m_mmio_direct_dev` to avoid leaking Arm-specific naming into
common Xen code, such as dom0less passthrough property handling.

This helps reduce platform-specific terminology in shared logic and
improves clarity for future non-Arm ports (e.g. RISC-V or PowerPC).

No functional changes — the definition is preserved via a static inline
function for Arm.

Suggested-by: Jan Beulich 
Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Introduce arch_dt_passthrough_p2m_type() instead of re-defining of
   p2m_mmio_direct.
---
Changes in V3:
 - New patch.
---
 xen/arch/arm/include/asm/p2m.h          | 5 +++++
 xen/common/device-tree/dom0less-build.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/p2m.h b/xen/arch/arm/include/asm/p2m.h
index ef98bc5f4d..010ce8c9eb 100644
--- a/xen/arch/arm/include/asm/p2m.h
+++ b/xen/arch/arm/include/asm/p2m.h
@@ -137,6 +137,11 @@ typedef enum {
     p2m_max_real_type,  /* Types after this won't be store in the p2m */
 } p2m_type_t;
 
+static inline p2m_type_t arch_dt_passthrough_p2m_type(void)
+{
+    return p2m_mmio_direct_dev;
+}
+
 /* We use bitmaps and mask to handle groups of types */
 #define p2m_to_mask(_t) (1UL << (_t))
 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 9fd004c42a..8214a6639f 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -185,7 +185,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
                                gaddr_to_gfn(gstart),
                                PFN_DOWN(size),
                                maddr_to_mfn(mstart),
-                               p2m_mmio_direct_dev);
+                               arch_dt_passthrough_p2m_type());
         if ( res < 0 )
         {
             printk(XENLOG_ERR
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125591.1467562 (Exim 4.92)
	(envelope-from )
	id 1uz08F-0001Ia-Tk; Wed, 17 Sep 2025 21:56:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125591.1467562; Wed, 17 Sep 2025 21: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 1uz08F-0001I6-Mj; Wed, 17 Sep 2025 21:56:07 +0000
Received: by outflank-mailman (input) for mailman id 1125591;
 Wed, 17 Sep 2025 21: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 1uz08D-0007Lt-Vk
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:05 +0000
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com
 [2607:f8b0:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ac4f15e-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:04 +0200 (CEST)
Received: by mail-pg1-x530.google.com with SMTP id
 41be03b00d2f7-b54ff31192aso203547a12.0
 for ; Wed, 17 Sep 2025 14:56:04 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14: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: 1ac4f15e-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146162; x=1758750962; darn=lists.xenproject.org;
        h=content-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=V0jjeGz+AJmkN++UO+lcFEzMkDbdZhQ1G/5IcA1Gkfk=;
        b=fsdW1oc6zUNsgaJae1bCxeeeY3vxbz2g4EUwePgmcpCvoDRyQZu2IuKpi3NVhouiYd
         4Z8e/4NEK7l/z1x+rsvo6kz8iIivnZtIwjNWpTQ9vyIdDYZeEWlTCPb6d+z55MBCclU2
         wQ0ulL8xfistr0gx67QmNl5sUDjU7QifJjBtxUVJtirqJJoT30EFdxzNpD+gcCgs+Yns
         gcbztK/yn20kZbvb0dr4lofHkbc+4ojoyIlbHhIrhq8NITvXO6tc9phrk21xKNBd2LLD
         XEz3vywan7cg3UB8+6w5d3RZ35cQhFU5Pd/XIw8UQb41o7Ri9JNYin5DBAmlVxmXTT4W
         sArg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146162; x=1758750962;
        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=V0jjeGz+AJmkN++UO+lcFEzMkDbdZhQ1G/5IcA1Gkfk=;
        b=ZxHLy2AqEM1z98sknB+R9F2IILiSFeKwYNiS/r102AaNfQUXqxG6T+oINHmSeysty6
         db9AwFlhqLArJ/KClPn1HWDifakdfTC2MCK0qIoxhPM6XY829tKNPdCLfGZ3QqwrlPpD
         E7KONKWTEMybUF8Z7kTmKCF9FxmeJpZI7xfSxol1TM5lPefck6fFK66COSeiUH6d7KC3
         AhWwuE/3EK/Ise3391p6VNz/9VtFmyPprG00Eiq4g94Rjt9AD0MxkeO8wzifPUg4BYOz
         EdpCLeJDxdNanlBFdf9CLcn5c56QtU8MEaE8wUyAjW0DGFpU4/TmZNd9c6FzragEOgz1
         NGPg==
X-Gm-Message-State: AOJu0YwS2lhFZeES4tjD4XzHFV7h5lJckfOFfYjeEI8lG5qUt7W17ek0
	n3YBMo2cxd2CK83CNzOesOO8vWFJrQB2fzuKczUJWiJ1eI/lHahE61s6C9Jj94gAqzo=
X-Gm-Gg: ASbGnct4au217cTYv9h3pJX0MoGIe2CpMsK1PFMxY5rXZUoPiR1Xi8YOP25yva+KtpJ
	Hgeg9Y5Pa1AhLIvhGv3nzg+FuoA6hE5Fr/7cVorlKfkdeL+K+gULbi0qOFdPZl6kOJkq504/vWG
	GywzJCrYqZ29EPSgICIWAUPzbk0fz0+IyOUaGOPZGLXR4P89C6MZr/5RUVlvP6MX1u68j7Oc5ik
	gmWcVrt/Lhv2/o8hWuY4GscQMf8wrHWlsBqjD5SyN+8UHh51m/kRMZs+splIJtESmxui/lePZsG
	RjuWb0dXB0CwE3wUZsrMnMJrigU1sJWzuR10zarSKM+/sMMkF8m6LNtEeB5+M7BWxXCYjlP3k6w
	urdUDdV28gnPo+DrfsD7vixbbby5qgslp5ui8pJptst8S
X-Google-Smtp-Source: AGHT+IEl1PXxxQcfnhBxZpW+6bQmQIphWQfIkxt0ZsmMrWstNujnSHoS/naPDgcFU7ynZxNz6DLycQ==
X-Received: by 2002:a17:902:e94d:b0:24c:965a:f94d with SMTP id d9443c01a7336-26813cfd846mr42364795ad.46.1758146162260;
        Wed, 17 Sep 2025 14:56:02 -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 09/18] xen/riscv: implement function to map memory in guest p2m
Date: Wed, 17 Sep 2025 23:55:29 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement map_regions_p2mt() to map a region in the guest p2m with
a specific p2m type. The memory attributes will be derived from the
p2m type. This function is used in dom0less common
code.

To implement it, introduce:
- p2m_write_(un)lock() to ensure safe concurrent updates to the P2M.
  As part of this change, introduce p2m_tlb_flush_sync() and
  p2m_force_tlb_flush_sync().
- A stub for p2m_set_range() to map a range of GFNs to MFNs.
- p2m_insert_mapping().
- p2m_is_write_locked().

Drop guest_physmap_add_entry() and call map_regions_p2mt() directly
from guest_physmap_add_page(), making guest_physmap_add_entry()
unnecessary.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Update the comment above declaration of map_regions_p2mt():
   s/guest p2m/guest's hostp2m.
 - Add const for p2m_force_tlb_flush_sync()'s local variable `d`.
 - Stray 'w' in the comment inside p2m_write_unlock().
 - Drop p2m_insert_mapping() and leave only map_regions_p2mt() as it
   is just re-use insert_mapping().
 - Rename p2m_force_tlb_flush_sync() to p2m_tlb_flush().
 - Update prototype of p2m_is_write_locked() to return bool instead of
   int.
---
Changes in v3:
 - Introudce p2m_write_lock() and p2m_is_write_locked().
 - Introduce p2m_force_tlb_flush_sync() and p2m_flush_tlb() to flush TLBs
   after p2m table update.
 - Change an argument of p2m_insert_mapping() from struct domain *d to
   p2m_domain *p2m.
 - Drop guest_physmap_add_entry() and use map_regions_p2mt() to define
   guest_physmap_add_page().
 - Add declaration of map_regions_p2mt() to asm/p2m.h.
 - Rewrite commit message and subject.
 - Drop p2m_access_t related stuff.
 - Add defintion of  p2m_is_write_locked().
---
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 | 31 ++++++++++++-----
 xen/arch/riscv/p2m.c             | 60 ++++++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+), 9 deletions(-)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 8a6f5f3092..c98cf547f1 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -122,21 +122,22 @@ 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;
-}
+/*
+ * Map a region in the guest's hostp2m p2m with a specific p2m type.
+ * The memory attributes will be derived from the p2m type.
+ */
+int map_regions_p2mt(struct domain *d,
+                     gfn_t gfn,
+                     unsigned long nr,
+                     mfn_t mfn,
+                     p2m_type_t p2mt);
 
 /* Untyped version for RAM only, for compatibility */
 static inline int __must_check
 guest_physmap_add_page(struct domain *d, gfn_t gfn, mfn_t mfn,
                        unsigned int page_order)
 {
-    return guest_physmap_add_entry(d, gfn, mfn, page_order, p2m_ram_rw);
+    return map_regions_p2mt(d, gfn, BIT(page_order, UL), mfn, p2m_ram_rw);
 }
 
 static inline mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
@@ -159,6 +160,18 @@ void gstage_mode_detect(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 bool p2m_is_write_locked(struct p2m_domain *p2m)
+{
+    return rw_is_write_locked(&p2m->lock);
+}
+
 unsigned long construct_hgatp(struct p2m_domain *p2m, uint16_t vmid);
 
 #endif /* ASM__RISCV__P2M_H */
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index ad0478f155..d8b611961c 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -96,6 +96,41 @@ void __init gstage_mode_detect(void)
     local_hfence_gvma_all();
 }
 
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ */
+static void p2m_tlb_flush(struct p2m_domain *p2m)
+{
+    const struct domain *d = p2m->domain;
+
+    ASSERT(p2m_is_write_locked(p2m));
+
+    sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
+
+    p2m->need_flush = false;
+}
+
+void p2m_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    if ( p2m->need_flush )
+        p2m_tlb_flush(p2m);
+}
+
+/* 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 before the TLB invalidation has
+     * completed.
+     */
+    p2m_tlb_flush_sync(p2m);
+
+    write_unlock(&p2m->lock);
+}
+
 static void clear_and_clean_page(struct page_info *page, bool clean_dcache)
 {
     clear_domain_page(page_to_mfn(page));
@@ -215,3 +250,28 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
 
     return rc;
 }
+
+static int p2m_set_range(struct p2m_domain *p2m,
+                         gfn_t sgfn,
+                         unsigned long nr,
+                         mfn_t smfn,
+                         p2m_type_t t)
+{
+    return -EOPNOTSUPP;
+}
+
+int map_regions_p2mt(struct domain *d,
+                     gfn_t gfn,
+                     unsigned long nr,
+                     mfn_t mfn,
+                     p2m_type_t p2mt)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    p2m_write_lock(p2m);
+    rc = p2m_set_range(p2m, gfn, nr, mfn, p2mt);
+    p2m_write_unlock(p2m);
+
+    return rc;
+}
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125593.1467572 (Exim 4.92)
	(envelope-from )
	id 1uz08H-0001bM-9U; Wed, 17 Sep 2025 21:56:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125593.1467572; Wed, 17 Sep 2025 21:56: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 1uz08H-0001aR-3x; Wed, 17 Sep 2025 21:56:09 +0000
Received: by outflank-mailman (input) for mailman id 1125593;
 Wed, 17 Sep 2025 21:56: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 1uz08F-0007Lu-H6
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:07 +0000
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com
 [2607:f8b0:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ba20d68-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:56:05 +0200 (CEST)
Received: by mail-pg1-x536.google.com with SMTP id
 41be03b00d2f7-b4fb8d3a2dbso210003a12.3
 for ; Wed, 17 Sep 2025 14:56:05 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 1ba20d68-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146164; x=1758750964; darn=lists.xenproject.org;
        h=content-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=v7U+4TOofR9loysSZtzDcwVl9yN7TxjVK1uzTiKAwHE=;
        b=ngAK3NpFqTngAnn+ML1/T66GSZ1s+gjhQrTXRi5pe66XTFyOjB95RgBOuscZ0TMdY9
         FBpimrhaDg4xYlNmAKNLEay8NHcPsUQOzEybDtr/BeJclqzwu4SLsSKjWXOb5jfy4J3m
         vBa3jBCY1m8lWpvvOLqNl/mEk94J3WQcbnA1i5HOz+8rNMV4z0JUIc5TSF6fkGlcHnaU
         y6d4nwzy/X1BOFSfBgK3ePFrPZaQYI684VKCJ5oWhuIDllszKPVSNhIPyJS/8OvLAQZE
         PFVGt053s55UhJr55A4vz8OjX+CeL0k1cWTOdW640Wg3xNVZo14FT7JlFlhTH0C0LV0f
         kfQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146164; x=1758750964;
        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=v7U+4TOofR9loysSZtzDcwVl9yN7TxjVK1uzTiKAwHE=;
        b=DFXl6miZ40D0XxqiG95o5BnWGLvo3pb2jGyYXM/fuaKYCPoJe55VfD07fN3l98CUJk
         8H4HN+HMB1O90cigxHfOUTiNgojsu6ul1oy38/3wzKhR61mr2LfqHETgVslw6YZqMK/S
         0DbpGIafjDU2oe/V1QiUkekbCePzWjl5eph/Fhk2WK7Ch/ZFkGtKsoPTGKsg78doy6KH
         5jBJbfy1Q2ypuc/4HGzTUUrI53ggXgQK+SbkkuvUMCaSZK1W67QAvLCbJ8R+LNX3hjPk
         Y8rqrO21dnO2IKn8ukDZ6p5qp8P4BoSDj6yUvlWVkNb+YjHia30ERdDQdcEOmXq+zJvN
         cHMQ==
X-Gm-Message-State: AOJu0YxIdNl2qC/yNwrtnZ9Vax4L93Xecqtxr1Cr5/B/gO5yDfWzu0Xs
	5lT4If8OIqaWMFQt0tI/n8z2xPJpu7ufSkh/3Veg4btgKLKekHIYFi0NoOOsq2vVUlU=
X-Gm-Gg: ASbGnctdxIfnf72mscI91Cpo5LP+SsnzNO5Owyp1rgpIBtevO6mIgZk+d6ceJwwMhse
	e4AOW5XYUPyuCSGkIx5ddlkfz7H0ky4CJRqCE21/U2NT38Meo2Ol98e9n1gM9OJ4capjFF5WM8r
	ScVk0U0XlR78abz3Qf9o1lp/50NubTKm57rYTVFmUFI/PSmV1PkRKN6YL6vWqbTZSEkJ6R4madA
	0ohMOfvAW6w/Urb8G19Yd4vuxRFd+vvCkh5pI8142TAmAGLFj4NP4uvIyrvQhEzSps8vfRi3l+Y
	L4KvEwymKZY2vTFdESvgJBTc7baFH+602SePZ/607QvR0k+EskA7kwnnitIwu2fCt/d2NVujBY0
	6JeeDrXCLJZg3kt78US9+BseCOhhFfdhZUao4un2YFBOI
X-Google-Smtp-Source: AGHT+IGKiNzISMMsf0WKmsXB6YFsB1Yn53Cp4xHzKC3xZuPFi1YtGU7Po1yxBBcel6rAIeQws8EkUA==
X-Received: by 2002:a17:903:1b27:b0:266:ddd:772f with SMTP id d9443c01a7336-268119b3d31mr37327005ad.9.1758146163564;
        Wed, 17 Sep 2025 14:56: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 
Subject: [PATCH v4 10/18] xen/riscv: implement p2m_set_range()
Date: Wed, 17 Sep 2025 23:55:30 +0200
Message-ID: <5e325267a792a9a0f4cb387b4e3287d22dc8d173.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch introduces p2m_set_range() and its core helper p2m_set_entry() for
RISC-V, based loosely on the Arm implementation, with several RISC-V-specific
modifications.

The main changes are:
- Simplification of Break-Before-Make (BBM) approach as according to RISC-V
  spec:
    It is permitted for multiple address-translation cache entries to co-exist
    for the same address. This represents the fact that in a conventional
    TLB hierarchy, it is possible for multiple entries to match a single
    address if, for example, a page is upgraded to a superpage without first
    clearing the original non-leaf PTE’s valid bit and executing an SFENCE.VMA
    with rs1=x0, or if multiple TLBs exist in parallel at a given level of the
    hierarchy. In this case, just as if an SFENCE.VMA is not executed between
    a write to the memory-management tables and subsequent implicit read of the
    same address: it is unpredictable whether the old non-leaf PTE or the new
    leaf PTE is used, but the behavior is otherwise well defined.
  In contrast to the Arm architecture, where BBM is mandatory and failing to
  use it in some cases can lead to CPU instability, RISC-V guarantees
  stability, and the behavior remains safe — though unpredictable in terms of
  which translation will be used.
- Unlike Arm, the valid bit is not repurposed for other uses in this
  implementation. Instead, entry validity is determined based solely on P2M
  PTE's valid bit.

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_range() breaks a region down into block-aligned mappings and calls
p2m_set_entry() accordingly.

Stub implementations (to be completed later) include:
- p2m_free_subtree()
- p2m_next_level()
- p2m_pte_from_mfn()

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 V4:
 - Introduce gstage_root_level and use it for defintion of P2M_ROOT_LEVEL.
 - Introduce P2M_LEVEL_ORDER() macros and P2M_PAGETABLE_ENTRIES().
 - Add the TODO comment in p2m_write_pte() about possible perfomance
   optimization.
 - Use compound literal for `pte` variable inside p2m_clean_pte().
 - Fix the comment above p2m_next_level().
 - Update ASSERT() inside p2m_set_entry() and leave only a check of a
   target as p2m_mapping_order() that page_order will be correctly
   aligned.
 - Update the comment above declaration of `removing_mapping` in
   p2m_set_entry().
 - Stray blanks.
 - Handle possibly overflow of an amount of unmapped GFNs in case of
   some failute in p2m_set_range().
 - Handle a case when MFN is 0 and removing of such MFN is happening in
   p2m_set_entry.
 - Fix p2m_get_root_pointer() to return correct pointer to root page table.
---
Changes in V3:
 - Drop p2m_access_t connected stuff as it isn't going to be used, at least
   now.
 - Move defintion of P2M_ROOT_ORDER and P2M_ROOT_PAGES to earlier patches.
 - Update the comment above lowest_mapped_gfn declaration.
 - Update the comment above p2m_get_root_pointer(): s/"...ofset of the root
   table"/"...ofset into root table".
 - s/p2m_remove_pte/p2m_clean_pte.
 - Use plain 0 instead of 0x00 in p2m_clean_pte().
 - s/p2m_entry_from_mfn/p2m_pte_from_mfn.
 - s/GUEST_TABLE_*/P2M_TABLE_*.
 - Update the comment above p2m_next_level(): "GFN entry" -> "corresponding
   the entry corresponding to the GFN".
 - s/__p2m_set_entry/_p2m_set_entry.
 - drop "s" for sgfn and smfn prefixes of _p2m_set_entry()'s arguments
   as this function work only with one GFN and one MFN.
 - Return correct return code when p2m_next_level() faild in _p2m_set_entry(),
   also drop "else" and just handle case (rc != P2M_TABLE_NORMAL) separately.
 - Code style fixes.
 - Use unsigned int for "order" in p2m_set_entry().
 - s/p2m_set_entry/p2m_free_subtree.
 - Update ASSERT() in __p2m_set_enty() to check that page_order is propertly
   aligned.
 - Return -EACCES instead of -ENOMEM in the chase when domain is dying and
   someone called p2m_set_entry.
 - s/p2m_set_entry/p2m_set_range.
 - s/__p2m_set_entry/p2m_set_entry
 - s/p2me_is_valid/p2m_is_valid()
 - Return a number of successfully mapped GFNs in case if not all were mapped
   in p2m_set_range().
 - Use BIT(order, UL) instead of 1 << order.
 - Drop IOMMU flushing code from p2m_set_entry().
 - set p2m->need_flush=true when entry in p2m_set_entry() is changed.
 - Introduce p2m_mapping_order() to support superpages.
 - Drop p2m_is_valid() and use pte_is_valid() instead as there is no tricks
   with copying of valid bit anymore.
 - Update p2m_pte_from_mfn() prototype: drop p2m argument.
---
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 |  39 +++++
 xen/arch/riscv/p2m.c             | 281 ++++++++++++++++++++++++++++++-
 2 files changed, 319 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index c98cf547f1..1a43736855 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -8,12 +8,41 @@
 #include 
 #include 
 
+#include 
 #include 
 
 extern unsigned long gstage_mode;
+extern unsigned int gstage_root_level;
 
 #define P2M_ROOT_ORDER  (ilog2(GSTAGE_ROOT_PAGE_TABLE_SIZE) - PAGE_SHIFT)
 #define P2M_ROOT_PAGES  BIT(P2M_ROOT_ORDER, U)
+#define P2M_ROOT_LEVEL  gstage_root_level
+
+/*
+ * According to the RISC-V spec:
+ *   When hgatp.MODE specifies a translation scheme of Sv32x4, Sv39x4, Sv48x4,
+ *   or Sv57x4, G-stage address translation is a variation on the usual
+ *   page-based virtual address translation scheme of Sv32, Sv39, Sv48, or
+ *   Sv57, respectively. In each case, the size of the incoming address is
+ *   widened by 2 bits (to 34, 41, 50, or 59 bits).
+ *
+ * P2M_LEVEL_ORDER(lvl) defines the bit position in the GFN from which
+ * the index for this level of the P2M page table starts. The extra 2
+ * bits added by the "x4" schemes only affect the root page table width.
+ *
+ * Therefore, this macro can safely reuse XEN_PT_LEVEL_ORDER() for all
+ * levels: the extra 2 bits do not change the indices of lower levels.
+ *
+ * The extra 2 bits are only relevant if one tried to address beyond the
+ * root level (i.e., P2M_LEVEL_ORDER(P2M_ROOT_LEVEL + 1)), which is
+ * invalid.
+ */
+#define P2M_LEVEL_ORDER(lvl) XEN_PT_LEVEL_ORDER(lvl)
+
+#define P2M_ROOT_EXTRA_BITS(lvl) (2 * ((lvl) == P2M_ROOT_LEVEL))
+
+#define P2M_PAGETABLE_ENTRIES(lvl) \
+    (BIT(PAGETABLE_ORDER + P2M_ROOT_EXTRA_BITS(lvl), UL))
 
 #define paddr_bits PADDR_BITS
 
@@ -52,6 +81,16 @@ struct p2m_domain {
      * when a page is needed to be fully cleared and cleaned.
      */
     bool clean_dcache;
+
+    /* 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 updated to track 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 d8b611961c..db9f7a77ff 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -16,6 +16,7 @@
 #include 
 
 unsigned long __ro_after_init gstage_mode;
+unsigned int __ro_after_init gstage_root_level;
 
 void __init gstage_mode_detect(void)
 {
@@ -53,6 +54,7 @@ void __init gstage_mode_detect(void)
         if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode )
         {
             gstage_mode = mode;
+            gstage_root_level = modes[mode_idx].paging_levels - 1;
             break;
         }
     }
@@ -210,6 +212,9 @@ int p2m_init(struct domain *d)
     rwlock_init(&p2m->lock);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
 
+    p2m->max_mapped_gfn = _gfn(0);
+    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
+
     /*
      * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
      * is not ready for RISC-V support.
@@ -251,13 +256,287 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
     return rc;
 }
 
+/*
+ * Find and map the root page table. The caller is responsible for
+ * unmapping the table.
+ *
+ * The function will return NULL if the offset into 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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
+    if ( root_table_indx >= P2M_ROOT_PAGES )
+        return NULL;
+
+    /*
+     * The P2M root page table is extended by 2 bits, making its size 16KB
+     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
+     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
+     * only allocates 4KB pages).
+     *
+     * To determine which of these four 4KB pages the root_table_indx falls
+     * into, we divide root_table_indx by
+     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
+     */
+    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);
+
+    return __map_domain_page(p2m->root + root_table_indx);
+}
+
+static inline void p2m_write_pte(pte_t *p, pte_t pte, bool clean_pte)
+{
+    write_pte(p, pte);
+
+    /*
+     * TODO: if multiple adjacent PTEs are written without releasing
+     *       the lock, this then redundant cache flushing can be a
+     *       performance issue.
+     */
+    if ( clean_pte )
+        clean_dcache_va_range(p, sizeof(*p));
+}
+
+static inline void p2m_clean_pte(pte_t *p, bool clean_pte)
+{
+    pte_t pte = { .pte = 0 };
+
+    p2m_write_pte(p, pte, clean_pte);
+}
+
+static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t)
+{
+    panic("%s: hasn't been implemented yet\n", __func__);
+
+    return (pte_t) { .pte = 0 };
+}
+
+#define P2M_TABLE_MAP_NONE 0
+#define P2M_TABLE_MAP_NOMEM 1
+#define P2M_TABLE_SUPER_PAGE 2
+#define P2M_TABLE_NORMAL 3
+
+/*
+ * Take the currently mapped table, find the entry corresponding to the GFN,
+ * and map the next-level table if available. The previous table will be
+ * unmapped if the next level was mapped (e.g., when P2M_TABLE_NORMAL is
+ * returned).
+ *
+ * `alloc_tbl` parameter indicates whether intermediate tables should
+ * be allocated when not present.
+ *
+ * Return values:
+ *  P2M_TABLE_MAP_NONE: a table allocation isn't permitted.
+ *  P2M_TABLE_MAP_NOMEM: allocating a new page failed.
+ *  P2M_TABLE_SUPER_PAGE: next level or leaf mapped normally.
+ *  P2M_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 P2M_TABLE_MAP_NONE;
+}
+
+/* Free pte sub-tree behind an entry */
+static void p2m_free_subtree(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 gfn,
+                           unsigned long page_order,
+                           mfn_t mfn,
+                           p2m_type_t t)
+{
+    unsigned int level;
+    unsigned int target = page_order / PAGETABLE_ORDER;
+    pte_t *entry, *table, orig_pte;
+    int rc;
+    /*
+     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
+     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
+     * are still allowed.
+     */
+    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
+
+    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, gfn);
+    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
+        {
+            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
+            /*
+             * 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 : rc;
+            goto out;
+        }
+
+        if ( rc != P2M_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;
+
+    if ( removing_mapping )
+        p2m_clean_pte(entry, p2m->clean_dcache);
+    else
+    {
+        pte_t pte = p2m_pte_from_mfn(mfn, t);
+
+        p2m_write_pte(entry, pte, p2m->clean_dcache);
+
+        p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
+                                      gfn_add(gfn, BIT(page_order, UL) - 1));
+        p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, gfn);
+    }
+
+    p2m->need_flush = true;
+
+    /*
+     * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
+     * is not ready for RISC-V support.
+     *
+     * When CONFIG_HAS_PASSTHROUGH=y, iommu_iotlb_flush() should be done
+     * here.
+     */
+#ifdef CONFIG_HAS_PASSTHROUGH
+#   error "add code to flush IOMMU TLB"
+#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 previously MFN 0 was mapped and it is going to be removed
+     * and considering that during removing MFN 0 is used then `entry`
+     * and `new_entry` will be the same and p2m_free_subtree() won't be
+     * called. This case is handled explicitly.
+     */
+    if ( pte_is_valid(orig_pte) &&
+         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
+          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
+        p2m_free_subtree(p2m, orig_pte, level);
+
+ out:
+    unmap_domain_page(table);
+
+    return rc;
+}
+
+/* Return mapping order for given gfn, mfn and nr */
+static unsigned long p2m_mapping_order(gfn_t gfn, mfn_t mfn, unsigned long nr)
+{
+    unsigned long mask;
+    /* 1gb, 2mb, 4k mappings are supported */
+    unsigned int level = min(P2M_ROOT_LEVEL, _AC(2, U));
+    unsigned long order = 0;
+
+    mask = !mfn_eq(mfn, INVALID_MFN) ? mfn_x(mfn) : 0;
+    mask |= gfn_x(gfn);
+
+    for ( ; level != 0; level-- )
+    {
+        if ( !(mask & (BIT(P2M_LEVEL_ORDER(level), UL) - 1)) &&
+             (nr >= BIT(P2M_LEVEL_ORDER(level), UL)) )
+        {
+                order = P2M_LEVEL_ORDER(level);
+                break;
+        }
+    }
+
+    return order;
+}
+
 static int p2m_set_range(struct p2m_domain *p2m,
                          gfn_t sgfn,
                          unsigned long nr,
                          mfn_t smfn,
                          p2m_type_t t)
 {
-    return -EOPNOTSUPP;
+    int rc = 0;
+    unsigned long left = nr;
+
+    /*
+     * 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 -EACCES;
+
+    while ( left )
+    {
+        unsigned long order = p2m_mapping_order(sgfn, smfn, left);
+
+        rc = p2m_set_entry(p2m, sgfn, order, smfn, t);
+        if ( rc )
+            break;
+
+        sgfn = gfn_add(sgfn, BIT(order, UL));
+        if ( !mfn_eq(smfn, INVALID_MFN) )
+           smfn = mfn_add(smfn, BIT(order, UL));
+
+        left -= BIT(order, UL);
+    }
+
+    if ( left > INT_MAX )
+        rc = -EOVERFLOW;
+
+    return !left ? rc : left;
 }
 
 int map_regions_p2mt(struct domain *d,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125594.1467579 (Exim 4.92)
	(envelope-from )
	id 1uz08I-0001kE-9s; Wed, 17 Sep 2025 21:56:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125594.1467579; Wed, 17 Sep 2025 21:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uz08H-0001hk-OJ; Wed, 17 Sep 2025 21:56:09 +0000
Received: by outflank-mailman (input) for mailman id 1125594;
 Wed, 17 Sep 2025 21:56: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 1uz08G-0007Lu-9P
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:08 +0000
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com
 [2607:f8b0:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c5624d9-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:56:06 +0200 (CEST)
Received: by mail-pg1-x536.google.com with SMTP id
 41be03b00d2f7-b54fc45db56so246508a12.3
 for ; Wed, 17 Sep 2025 14:56:06 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 1c5624d9-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146165; x=1758750965; darn=lists.xenproject.org;
        h=content-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=S85/7YEfvWzEAWgm6nDQ8J3mMWbmh28C9PxVG5Fm6Vg=;
        b=HEeLLUXxFn7GKYlpm3eTbCr4d+NjkETO1IUXIDGvrWcjRdkjhNxX/0xHwW5CVarciJ
         7tl+sqBPE14glEIvxLPbAQVtmLJGnen69BU2Kwb8Ugx+49WChWHuglNxSefgN3TXmhE2
         A96TFnDUYUH2YYPbJ43mOH5a2H9X7PlxNb//InO3VPTOA52jurhdcV6QhEdHUzWeoOZE
         hCHOIkQmfYgds4asQmTPiezz56/djCFBoFKsvPO+dCpd4fpwAy0Jx5F5P0hprCYWFJzG
         1zCqYJrxiC59G9Q5Zf6Hg7DiBJMmGRQfcfOiQ55QUzaoxtTzPfWxGlTSrgxdFqLIUzGe
         Jwjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146165; x=1758750965;
        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=S85/7YEfvWzEAWgm6nDQ8J3mMWbmh28C9PxVG5Fm6Vg=;
        b=aEMtNYBLZDjlH96KPmWvbmddcBVsigKWQF4SSDr2JsTAhOWY/tEqD8hPfGeu3JQqu5
         ZPE7rz+a2X5At/pd5c2owHmweDP8m7oMfqNhfWinVJDvEqDiIQb7Rs5jX98vN62iYC6l
         NcLs8nhQV0CCPhfTWzFFyG2G9Zp0aHDS21DgXnlR7LUSn5LJlrSxTmZm5qvHjigKul7u
         2Fe9YgGiUNPHgTwaHO6cJ/pA7/h50wK5SNGvMzs/ZWuZ6ZneVKPwT/LGp8ak3e6Ba3R3
         PWDc35axwXO4RzFz1jE+4Qa0eSKH3bszJ067r0pXWlLbgbb/YRhGDEkwTzTTeEX1tS89
         +pAA==
X-Gm-Message-State: AOJu0YzWKoICJJ9aocFYXX7GACO1NJW25cZQUpd3rzLmz2JU+4ack0/j
	vTlm/z4b0uNiTwuZTtp/3In5AGQHOPelQdz3CmoH+Vvnz6bkCHUn0mvZrFdh2+yHQKI=
X-Gm-Gg: ASbGncsqjluKEUHI0v0Q8ixBb0k+aJXURkQcTkE+qIaDreGqxvdH02gOGniojazMBIQ
	z4hrUs3p1qYntZx+CZv1B3vC7Rwmr2RAigxvXdHbWbg+lX3FQpVxRsAuL1ghmt+WiqXZQZFTWQi
	5jkL+Yv7KS8K2Ls+PRcf/myV23sL04ddKtjjFyVzRmE9329IAenhHRXhYoy3qANnL7EplpzGac0
	qvW8QONVRMNw9IJiz/l5JS72iuc5+giUzs/xSc2mbWXP2oIXugG6GQd/iDF3RzqPeDnIenfEhLd
	11W2pUJ0hs9nai6AwH/SIOztE00WuWP0TzJ8/zzf9lHCIdqe4KKPPBjsbAS2cMcWkA00LiVtai6
	Qf8ds3IrlIaBSSVQmjPGkq5ezmnrgnVWabXwE0ZKOQGis
X-Google-Smtp-Source: AGHT+IFz5svr8DqExqXfJbwMC1EufVubPVjC8rKYpXhjFU6hgEsvH48jLhzLOrLFQ6owjGji5fKjIQ==
X-Received: by 2002:a17:903:41ce:b0:24c:cb60:f6f0 with SMTP id d9443c01a7336-26813ef9e7dmr50447375ad.58.1758146164894;
        Wed, 17 Sep 2025 14:56:04 -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 11/18] xen/riscv: Implement p2m_free_subtree() and related helpers
Date: Wed, 17 Sep 2025 23:55:31 +0200
Message-ID: <18ed5517721254a56e992d9cd9bc1a64672eda8a.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch introduces a working implementation of p2m_free_subtree() 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:
- Introduce and use p2m_get_type() 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 outside PTE. But, at the moment, handle only types
  which fit into PTE's bits.

Key additions include:
- p2m_free_subtree(): 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_get_type(): Extracts the stored p2m_type from the PTE bits.
- p2m_free_page(): Returns a page to a domain's freelist.
- Introduce p2m_is_foreign() and connected to it things.

Defines XEN_PT_ENTRIES in asm/page.h to simplify loops over page table
entries.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Stray blanks.
 - Implement arch_flush_tlb_mask() to make the comment in p2m_put_foreign()
   clear and explicit.
 - Update the comment above p2m_is_ram() in p2m_put_4k_page() with an explanation
   why p2m_is_ram() is used.
 - Add a type check inside p2m_put_2m_superpage().
 - Swap two conditions around in p2m_free_subtree():
     if ( (level == 0) || pte_is_superpage(entry, level) )
 - Add ASSERT() inside p2m_free_subtree() to check that level is <= 2; otherwise,
   it could consume a lot of time and big memory usage because of recursion.
 - Drop page_list_del() before p2m_free_page() as page_list_del() is called
   inside p2m_free_page().
 - Update p2m_freelist's total_pages when a page is added to p2m_freelist in
   paging_free_page().
 - Introduce P2M_SUPPORTED_LEVEL_MAPPING and use it in ASSERTs() which check
   supported level.
 - Use P2M_PAGETABLE_ENTRIES as XEN_PT_ENTRIES
   doesn't takeinto  into acount that G stage root page table is
   extended by 2 bits.
 - Update prototype of p2m_put_page() to not have unnecessary changes later.
---
Changes in V3:
 - Use p2m_tlb_flush_sync(p2m) instead of p2m_force_tlb_flush_sync() in
   p2m_free_subtree().
 - Drop p2m_is_valid() implementation as pte_is_valid() is going to be used
   instead.
 - Drop p2m_is_superpage() and introduce pte_is_superpage() instead.
 - s/p2m_free_entry/p2m_free_subtree.
 - s/p2m_type_radix_get/p2m_get_type.
 - Update implementation of p2m_get_type() to get type both from PTE bits,
   other cases will be covered in a separate patch. This requires an
   introduction of new P2M_TYPE_PTE_BITS_MASK macros.
 - Drop p2m argument of p2m_get_type() as it isn't needed anymore.
 - Put cheapest checks first in p2m_is_superpage().
 - Use switch() in p2m_put_page().
 - Update the comment in p2m_put_foreign_page().
 - Code style fixes.
 - Move p2m_foreign stuff to this commit.
 - Drop p2m argument of p2m_put_page() as itsn't used anymore.
---
Changes in V2:
 - New patch. It was a part of 2ma 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/flushtlb.h |   6 +-
 xen/arch/riscv/include/asm/p2m.h      |  18 ++-
 xen/arch/riscv/include/asm/page.h     |   6 +
 xen/arch/riscv/include/asm/paging.h   |   2 +
 xen/arch/riscv/p2m.c                  | 152 +++++++++++++++++++++++++-
 xen/arch/riscv/paging.c               |   8 ++
 xen/arch/riscv/stubs.c                |   5 -
 7 files changed, 187 insertions(+), 10 deletions(-)

diff --git a/xen/arch/riscv/include/asm/flushtlb.h b/xen/arch/riscv/include/asm/flushtlb.h
index e70badae0c..ab32311568 100644
--- a/xen/arch/riscv/include/asm/flushtlb.h
+++ b/xen/arch/riscv/include/asm/flushtlb.h
@@ -41,8 +41,10 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page)
     BUG_ON("unimplemented");
 }
 
-/* Flush specified CPUs' TLBs */
-void arch_flush_tlb_mask(const cpumask_t *mask);
+static inline void arch_flush_tlb_mask(const cpumask_t *mask)
+{
+    sbi_remote_hfence_gvma(mask, 0, 0);
+}
 
 #endif /* ASM__RISCV__FLUSHTLB_H */
 
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 1a43736855..29685c7852 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -106,6 +106,8 @@ typedef enum {
     p2m_mmio_direct_io, /* Read/write mapping of genuine Device MMIO area,
                            PTE_PBMT_IO will be used for such mappings */
     p2m_ext_storage,    /* Following types'll be stored outsude PTE bits: */
+    p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
+    p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */
 
     /* Sentinel — not a real type, just a marker for comparison */
     p2m_first_external = p2m_ext_storage,
@@ -116,15 +118,29 @@ static inline p2m_type_t arch_dt_passthrough_p2m_type(void)
     return p2m_mmio_direct_io;
 }
 
+/*
+ * Bits 8 and 9 are reserved for use by supervisor software;
+ * the implementation shall ignore this field.
+ * We are going to use to save in these bits frequently used types to avoid
+ * get/set of a type from radix tree.
+ */
+#define P2M_TYPE_PTE_BITS_MASK  0x300
+
 /* 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))
 
+/* Foreign mappings types */
+#define P2M_FOREIGN_TYPES (p2m_to_mask(p2m_map_foreign_rw) | \
+                           p2m_to_mask(p2m_map_foreign_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)
+#define p2m_is_any_ram(t_) (p2m_to_mask(t_) & \
+                            (P2M_RAM_TYPES | P2M_FOREIGN_TYPES))
+#define p2m_is_foreign(t) (p2m_to_mask(t) & P2M_FOREIGN_TYPES)
 
 #include 
 
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 66cb192316..cb303af0c0 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -20,6 +20,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:
@@ -182,6 +183,11 @@ static inline bool pte_is_mapping(pte_t p)
     return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
 }
 
+static inline bool pte_is_superpage(pte_t p, unsigned int level)
+{
+    return (level > 0) && pte_is_mapping(p);
+}
+
 static inline int clean_and_invalidate_dcache_va_range(const void *p,
                                                        unsigned long size)
 {
diff --git a/xen/arch/riscv/include/asm/paging.h b/xen/arch/riscv/include/asm/paging.h
index befad14f82..9712aa77c5 100644
--- a/xen/arch/riscv/include/asm/paging.h
+++ b/xen/arch/riscv/include/asm/paging.h
@@ -13,4 +13,6 @@ int paging_freelist_adjust(struct domain *d, unsigned long pages,
 int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages);
 int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages);
 
+void paging_free_page(struct domain *d, struct page_info *pg);
+
 #endif /* ASM_RISCV_PAGING_H */
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index db9f7a77ff..10acfa0a9c 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -98,6 +98,8 @@ void __init gstage_mode_detect(void)
     local_hfence_gvma_all();
 }
 
+#define P2M_SUPPORTED_LEVEL_MAPPING 2
+
 /*
  * Force a synchronous P2M TLB flush.
  *
@@ -286,6 +288,16 @@ 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_get_type(const pte_t pte)
+{
+    p2m_type_t type = MASK_EXTR(pte.pte, P2M_TYPE_PTE_BITS_MASK);
+
+    if ( type == p2m_ext_storage )
+        panic("unimplemented\n");
+
+    return type;
+}
+
 static inline void p2m_write_pte(pte_t *p, pte_t pte, bool clean_pte)
 {
     write_pte(p, pte);
@@ -342,11 +354,147 @@ static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
     return P2M_TABLE_MAP_NONE;
 }
 
+static void p2m_put_foreign_page(struct page_info *pg)
+{
+    /*
+     * It’s safe to call put_page() here because arch_flush_tlb_mask()
+     * will be invoked if the page is reallocated before the end of
+     * this loop, which will trigger a flush of the guest TLBs.
+     */
+    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 */
+
+    if ( p2m_is_foreign(type) )
+    {
+        ASSERT(mfn_valid(mfn));
+        p2m_put_foreign_page(mfn_to_page(mfn));
+    }
+}
+
+/* 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;
+
+    /*
+     * TODO: Handle other p2m types, but be aware that any changes to handle
+     * different types should require an update on the relinquish code to
+     * handle preemption.
+     */
+    if ( !p2m_is_foreign(type) )
+        return;
+
+    ASSERT(mfn_valid(mfn));
+
+    pg = mfn_to_page(mfn);
+
+    for ( i = 0; i < P2M_PAGETABLE_ENTRIES(1); i++, pg++ )
+        p2m_put_foreign_page(pg);
+}
+
+/* Put any references on the page referenced by pte. */
+static void p2m_put_page(const pte_t pte, unsigned int level, p2m_type_t p2mt)
+{
+    mfn_t mfn = pte_get_mfn(pte);
+
+    ASSERT(pte_is_valid(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.
+     */
+    switch ( level )
+    {
+    case 1:
+        return p2m_put_2m_superpage(mfn, p2mt);
+
+    case 0:
+        return p2m_put_4k_page(mfn, p2mt);
+
+    default:
+        assert_failed("Unsupported level");
+        break;
+    }
+}
+
+static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg)
+{
+    page_list_del(pg, &p2m->pages);
+
+    paging_free_page(p2m->domain, pg);
+}
+
 /* Free pte sub-tree behind an entry */
 static void p2m_free_subtree(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;
+
+    /*
+     * Check if the level is valid: only 4K - 2M - 1G mappings are supported.
+     * To support levels > 2, the implementation of p2m_free_subtree() would
+     * need to be updated, as the current recursive approach could consume
+     * excessive time and memory.
+     */
+    ASSERT(level <= P2M_SUPPORTED_LEVEL_MAPPING);
+
+    /* Nothing to do if the entry is invalid. */
+    if ( !pte_is_valid(entry) )
+        return;
+
+    if ( (level == 0) || pte_is_superpage(entry, level) )
+    {
+        p2m_type_t p2mt = p2m_get_type(entry);
+
+#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_get_type(p2m, entry)) &&
+             domain_has_ioreq_server(p2m->domain) )
+            ioreq_request_mapcache_invalidate(p2m->domain);
+#endif
+
+        p2m_put_page(entry, level, p2mt);
+
+        return;
+    }
+
+    table = map_domain_page(pte_get_mfn(entry));
+    for ( i = 0; i < P2M_PAGETABLE_ENTRIES(level); i++ )
+        p2m_free_subtree(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_tlb_flush_sync(p2m);
+
+    mfn = pte_get_mfn(entry);
+    ASSERT(mfn_valid(mfn));
+
+    pg = mfn_to_page(mfn);
+
+    p2m_free_page(p2m, pg);
 }
 
 /*
@@ -377,7 +525,7 @@ static int p2m_set_entry(struct p2m_domain *p2m,
      * Check if the level target is valid: we only support
      * 4K - 2M - 1G mapping.
      */
-    ASSERT(target <= 2);
+    ASSERT(target <= P2M_SUPPORTED_LEVEL_MAPPING);
 
     table = p2m_get_root_pointer(p2m, gfn);
     if ( !table )
diff --git a/xen/arch/riscv/paging.c b/xen/arch/riscv/paging.c
index ed537fee07..049b850e03 100644
--- a/xen/arch/riscv/paging.c
+++ b/xen/arch/riscv/paging.c
@@ -107,6 +107,14 @@ int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages)
     return 0;
 }
 
+void paging_free_page(struct domain *d, struct page_info *pg)
+{
+    spin_lock(&d->arch.paging.lock);
+    page_list_add_tail(pg, &d->arch.paging.freelist);
+    ACCESS_ONCE(d->arch.paging.total_pages)++;
+    spin_unlock(&d->arch.paging.lock);
+}
+
 /* Domain paging struct initialization. */
 int paging_domain_init(struct domain *d)
 {
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 1a8c86cd8d..ad6fdbf501 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -65,11 +65,6 @@ int arch_monitor_domctl_event(struct domain *d,
 
 /* smp.c */
 
-void arch_flush_tlb_mask(const cpumask_t *mask)
-{
-    BUG_ON("unimplemented");
-}
-
 void smp_send_event_check_mask(const cpumask_t *mask)
 {
     BUG_ON("unimplemented");
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125595.1467593 (Exim 4.92)
	(envelope-from )
	id 1uz08L-0002RZ-6I; Wed, 17 Sep 2025 21:56:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125595.1467593; Wed, 17 Sep 2025 21:56: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 1uz08K-0002PQ-P5; Wed, 17 Sep 2025 21:56:12 +0000
Received: by outflank-mailman (input) for mailman id 1125595;
 Wed, 17 Sep 2025 21:56: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 1uz08I-0007Lt-2I
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:10 +0000
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com
 [2607:f8b0:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d213bd6-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:08 +0200 (CEST)
Received: by mail-pl1-x634.google.com with SMTP id
 d9443c01a7336-2677a4d4ce3so3389945ad.0
 for ; Wed, 17 Sep 2025 14:56:08 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 1d213bd6-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146166; x=1758750966; darn=lists.xenproject.org;
        h=content-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=Vixp4rZSilRtfznTmIcEdZHTZIUxpbam21u9aaI4Ljs=;
        b=EI/Klr43q7NVgGkfblRBupGvdhyPP1NI7/WTxAhz3GkEIETzlPsBIrpPIGtkdDJN5i
         AKZYko9nq778uA3FKmfg7/+DnT4aXKSJsEPyFkuvsPMTxGJdlnUQFIzPGyuf7HfmSgLk
         XwKej4xFk0AdO9l/cTguqTuBTQKvU91dXiV4yZKZ99lI+EKklcaIOblBvV7J05fdBkQH
         wwlo3uzwfb5UmnCQ0pcwqLe0ktf2K202zww7wwnCJfAYrfRZhSzfpqoIE8205u4UFnxi
         jdp9YFD7hWpdAEIRteCWMgZv2MGvsgCedQgKzj3Y6iUgDXx5HF4fBPb1jkyBxSeowsr8
         V2yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146166; x=1758750966;
        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=Vixp4rZSilRtfznTmIcEdZHTZIUxpbam21u9aaI4Ljs=;
        b=oBjM+y5fxNirYofj9+BWDzbtMuO1hHDA4pZ6fHg6FQ9KbazOlemYDwutrW0KXzaT/p
         F1GwhvZc7aH5sxdDFgXJoD7oaOaXhneZL9EC/ClW4WXKCniCPIvuI+5PKD5T0KyAKmIm
         2+SPWDin0YW1L7WEkGnBMjvNC+vV9FWYd8gN6FwqdFeeSh+Mu0JJPhCi2ArlRLTmoVJ2
         4kG0S6LiDblRAT7Yor+GyED50gmmo98Gp4vuzj0s4zRerzVCKXajCYbESo7Aio2Y54gD
         1F5W1tk9hlks9n7M92sseomTz+vtuaxoQSKOGQmafixiKV6cdH2II8eF2VQHl+9V+wrK
         df1w==
X-Gm-Message-State: AOJu0Yxi5cgYfVNH+BENzfQGf5ltEoQ3+PqOyM7f8bSQiO/YeaIi71+V
	npl+0Z3CNCx69mlRQV89AvqaVym307/rN3TH1tGUDC+JPlelKnhGXrea6zHmwJMArsg=
X-Gm-Gg: ASbGncui01tujQBX1vJV6BspCG5la5J8lotTWcrnB9WI1vgAE7y17aK1uADA9fb27dr
	Kvqf2SLBdrArOXjkaheREo16SdU23XadCIY54hMhaQcApaSPf2obXWN8o4zQ9J9U3uzS0Z6ZQVS
	k462BLIFdMpra02c70wBlBLyPVBmvDDKbk6E7Lj4tLRv5y6zRazdFCEiYWO80vt9e949ZLyRlQE
	hNfCDRHSZCJnRx3HD6hGgyMWieYVNnxW93Bt2IRXP0XMe78uGQ/2zGd2lT06tSTaq/X0bjQjKtI
	pqu0pRViNucm76qklfPXneXAhqpwYChJRfaqdth0zqcQ5m9vmhZS6dFcIdP/ztn9wcIkOPGqd+g
	ToDVzVP9yTqcpldDvnHqiJWoiQ8mPcaefIU8YaLl8uvYX
X-Google-Smtp-Source: AGHT+IFNJ3k2Jd6YqvnePVPezggYrFvdtN2cprYFtJsXb3luDpwyEXMpH57sl8ziAFha5F2VyERQWQ==
X-Received: by 2002:a17:903:1983:b0:24c:cca1:7cfc with SMTP id d9443c01a7336-26813f01439mr46507205ad.59.1758146166263;
        Wed, 17 Sep 2025 14:56: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 
Subject: [PATCH v4 12/18] xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration
Date: Wed, 17 Sep 2025 23:55:32 +0200
Message-ID: <4495c8103548447f9a11963574a4cb9e01090e7a.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
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_pte_from_mfn(): Generates a valid PTE using the
  given MFN, p2m_type_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_set_type(): Stores the p2m type in PTE's bits. The storage of types,
  which don't fit PTE bits, will be implemented separately later.
- Add detection of Svade extension to properly handle a possible page-fault
  if A and D bits aren't set.

PBMT type encoding support:
- Introduces an enum pbmt_type_t to represent the PBMT field values.
- Maps types like p2m_mmio_direct_dev to p2m_mmio_direct_io, others default
  to pbmt_pma.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - p2m_set_permission() updates:
   - Update permissions for p2m_ram_rw case, make it also executable.
   - Add pernissions setting for p2m_map_foreign_* types.
   - Drop setting peromissions for p2m_ext_storage.
   - Only turn off PTE_VALID bit for p2m_invalid, don't touch other bits.
 - p2m_pte_from_mfn() updates:
   - Update ASSERT(), add a check that mfn isn't INVALID_MFN (1)
     explicitly to avoid the case when PADDR_MASK isn't narrow enough to
     catch the case (1).
   - Drop unnessary check around call of p2m_set_type() as this check
     is already included inside p2m_set_type().
 - Introduce new p2m type p2m_first_external to detect that passed type
   is stored in external storage.
 - Add handling of PTE's A and D bits in pm2_set_permission. Also, set
   PTE_USER bit. For this cpufeatures.{h and c} were updated to be able
   to detect availability of Svade extension.
 - Drop grant table related code as it isn't going to be used at the moment.
---
Changes in V3:
 - s/p2m_entry_from_mfn/p2m_pte_from_mfn.
 - s/pbmt_type_t/pbmt_type.
 - s/pbmt_max/pbmt_count.
 - s/p2m_type_radix_set/p2m_set_type.
 - Rework p2m_set_type() to handle only types which are fited into PTEs bits.
   Other types will be covered separately.
   Update arguments of p2m_set_type(): there is no any reason for p2m anymore.
 - p2m_set_permissions() updates:
   - Update the code in p2m_set_permission() for cases p2m_raw_rw and
     p2m_mmio_direct_io to set proper type permissions.
   - Add cases for p2m_grant_map_rw and p2m_grant_map_ro.
   - Use ASSERT_UNEACHABLE() instead of BUG() in switch cases of
     p2m_set_permissions.
   - Add blank lines non-fall-through case blocks in switch cases.
 - Set MFN before permissions are set in p2m_pte_from_mfn().
 - Update prototype of p2m_entry_from_mfn().
---
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/cpufeature.c             |  1 +
 xen/arch/riscv/include/asm/cpufeature.h |  1 +
 xen/arch/riscv/include/asm/page.h       |  8 ++
 xen/arch/riscv/p2m.c                    | 97 ++++++++++++++++++++++++-
 4 files changed, 103 insertions(+), 4 deletions(-)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index b846a106a3..02b68aeaa4 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -138,6 +138,7 @@ const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
     RISCV_ISA_EXT_DATA(zbs),
     RISCV_ISA_EXT_DATA(smaia),
     RISCV_ISA_EXT_DATA(ssaia),
+    RISCV_ISA_EXT_DATA(svade),
     RISCV_ISA_EXT_DATA(svpbmt),
 };
 
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
index 768b84b769..5f756c76db 100644
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -37,6 +37,7 @@ enum riscv_isa_ext_id {
     RISCV_ISA_EXT_zbs,
     RISCV_ISA_EXT_smaia,
     RISCV_ISA_EXT_ssaia,
+    RISCV_ISA_EXT_svade,
     RISCV_ISA_EXT_svpbmt,
     RISCV_ISA_EXT_MAX
 };
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index cb303af0c0..4fa0556073 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -74,6 +74,14 @@
 #define PTE_SMALL       BIT(10, UL)
 #define PTE_POPULATE    BIT(11, UL)
 
+enum pbmt_type {
+    pbmt_pma,
+    pbmt_nc,
+    pbmt_io,
+    pbmt_rsvd,
+    pbmt_count,
+};
+
 #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 10acfa0a9c..2d4433360d 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -288,6 +289,18 @@ 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_set_type(pte_t *pte, p2m_type_t t)
+{
+    int rc = 0;
+
+    if ( t > p2m_first_external )
+        panic("unimplemeted\n");
+    else
+        pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK);
+
+    return rc;
+}
+
 static p2m_type_t p2m_get_type(const pte_t pte)
 {
     p2m_type_t type = MASK_EXTR(pte.pte, P2M_TYPE_PTE_BITS_MASK);
@@ -318,11 +331,87 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_pte)
     p2m_write_pte(p, pte, clean_pte);
 }
 
-static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t)
+static void p2m_set_permission(pte_t *e, p2m_type_t t)
 {
-    panic("%s: hasn't been implemented yet\n", __func__);
+    e->pte &= ~PTE_ACCESS_MASK;
+
+    e->pte |= PTE_USER;
+
+    /*
+     * Two schemes to manage the A and D bits are defined:
+     *   • The Svade extension: when a virtual page is accessed and the A bit
+     *     is clear, or is written and the D bit is clear, a page-fault
+     *     exception is raised.
+     *   • When the Svade extension is not implemented, the following scheme
+     *     applies.
+     *     When a virtual page is accessed and the A bit is clear, the PTE is
+     *     updated to set the A bit. When the virtual page is written and the
+     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
+     *     address translation is in use and is not Bare, the G-stage virtual
+     *     pages may be accessed or written by implicit accesses to VS-level
+     *     memory management data structures, such as page tables.
+     * Thereby to avoid a page-fault in case of Svade is available, it is
+     * necesssary to set A and D bits.
+     */
+    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
+        e->pte |= PTE_ACCESSED | PTE_DIRTY;
+
+    switch ( t )
+    {
+    case p2m_map_foreign_rw:
+    case p2m_mmio_direct_io:
+        e->pte |= PTE_READABLE | PTE_WRITABLE;
+        break;
+
+    case p2m_ram_rw:
+        e->pte |= PTE_ACCESS_MASK;
+        break;
+
+    case p2m_invalid:
+        e->pte &= ~PTE_VALID;
+        break;
+
+    case p2m_map_foreign_ro:
+        e->pte |= PTE_READABLE;
+        break;
+
+    default:
+        ASSERT_UNREACHABLE();
+        break;
+    }
+}
+
+static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
+{
+    pte_t e = (pte_t) { PTE_VALID };
+
+    switch ( t )
+    {
+    case p2m_mmio_direct_io:
+        e.pte |= PTE_PBMT_IO;
+        break;
+
+    default:
+        break;
+    }
+
+    pte_set_mfn(&e, mfn);
+
+    ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK) || mfn_eq(mfn, INVALID_MFN));
+
+    if ( !is_table )
+    {
+        p2m_set_permission(&e, t);
+        p2m_set_type(&e, t);
+    }
+    else
+        /*
+         * According to the spec and table "Encoding of PTE R/W/X fields":
+         *   X=W=R=0 -> Pointer to next level of page table.
+         */
+        e.pte &= ~PTE_ACCESS_MASK;
 
-    return (pte_t) { .pte = 0 };
+    return e;
 }
 
 #define P2M_TABLE_MAP_NONE 0
@@ -580,7 +669,7 @@ static int p2m_set_entry(struct p2m_domain *p2m,
         p2m_clean_pte(entry, p2m->clean_dcache);
     else
     {
-        pte_t pte = p2m_pte_from_mfn(mfn, t);
+        pte_t pte = p2m_pte_from_mfn(mfn, t, false);
 
         p2m_write_pte(entry, pte, p2m->clean_dcache);
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 21:56:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 21:56:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125599.1467598 (Exim 4.92)
	(envelope-from )
	id 1uz08M-0002it-M7; Wed, 17 Sep 2025 21:56:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125599.1467598; Wed, 17 Sep 2025 21: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 1uz08M-0002fH-5H; Wed, 17 Sep 2025 21:56:14 +0000
Received: by outflank-mailman (input) for mailman id 1125599;
 Wed, 17 Sep 2025 21:56: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 1uz08K-0007Lt-2y
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:12 +0000
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com
 [2607:f8b0:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1de127b2-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:09 +0200 (CEST)
Received: by mail-pg1-x532.google.com with SMTP id
 41be03b00d2f7-b54dd647edcso246149a12.1
 for ; Wed, 17 Sep 2025 14:56:09 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 1de127b2-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146167; x=1758750967; darn=lists.xenproject.org;
        h=content-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=ZSDbiXfntjTDpIx6oGO3PjzMx5fUjcTMiZWj5cdZF5A=;
        b=FUkZZX5fuUAG/McSZBW4MZl4cdvynAev76940SY73JBQIFSe9NfmXBUBkUxm3LKapp
         Nw/BjgnUdzh0ZS8YBTTebg2xT6P+aefv2AlTbrnsH8MomPdPnW6hyJLKuIKuGwl61nnQ
         FofAZ8S+FJdLkIAnG+ZvhJMENMzvDnyEb8QhHzaaCkKvMKPQ5VSIR5+o+bdVn9ugtTIH
         dYZ43pAzryx6jIH4BkJJhmqXU0wQUMGWCICyg3FZoPo43C97HYnKF1eeiubbPyRzUMJt
         NxJ8pRECVZFxG6ICXBFW7fWFePlKlNLXYPALcxee4WqSA6a34I09pIWxI8HOOQiM/YyL
         fFVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146167; x=1758750967;
        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=ZSDbiXfntjTDpIx6oGO3PjzMx5fUjcTMiZWj5cdZF5A=;
        b=MERX49+LHzm/SqbIDGadOEfLNoJ5OouimQ3TLVxxVfOWdAuXh2rJ9p4OP9QF7YPpx5
         tGPrNAy/Ss0e3O3OPFRkHeTOlwha0CB8hBH2ZD3bbo+CM1mm+QTdVYBlx63MXcJ17fRP
         2fxCrHVh3qfxUkAg6RAhBuUTD2chKtLpQKUqCtRXRYN++lxMUeNyo6hMG1ilLlx7tusD
         CYMoIAMHazBNy87JZnjJ0AyVZYq7dgFgdA3Tju6uheOdrKTZPvjPDoRpCeoshrUnQW/5
         N0CtJ9m4mVxWmV0rX5S8xtsCvOmmRABi/2299EYYyOKOBURqFPttm9QdhE4faPNlONRq
         cZpQ==
X-Gm-Message-State: AOJu0YxKcHoKDucIGJGEw0zTktzbzZBOuehlqbWMSbcTS0VYvSZ0dG1f
	dBPdBF88j9DGOE17ayLX8UFVwZgpZ/kHsCNe41V0kw0HbS+TL3vhBKM9AC2Xotwa04A=
X-Gm-Gg: ASbGncuTQi37Z/EfKpSCgDvfhTQRSbHmYcNHK7W8jIbyacJq6LZxjJb/yjDGwJJMe7l
	X5ceJMqrH3/5IzQHaEn4hO2Yt5AOxPIrzXj/AxNHd7pJ/CSmrxZ06eJb1qwk4n4y6gnO4N20cz6
	Amiptuef49DhZwVmMyLmuUEcmEZXYifY6ptQRJgNwp25FEDE5xigBSIUoDuUxYDV1rlgmcCIWI7
	Mp43YNJkm7Iq94itOZzvvyhi/fb3AM+8vX96VgOlPBOqQNvT6ix9ixUqVeO2ezhxeQ+nvzRyI5c
	kb/ZsU2WUjvz7y1cwvwzLnyWKSaKJVsE6T8SSP5+bEcgw7MgCQ+VVt1LDexp8PqWpQuSsBGzL5T
	tViU+/xXy0XXbQZSVLsVRwBTnhJa7WacqcBM+cR7Gw74Q
X-Google-Smtp-Source: AGHT+IECYmCn9BXbpgApuxCBLKt9DNurYE551I03EeiaFrImSmWiiMpA8s3CPcvyywmoeUGGrNqoHw==
X-Received: by 2002:a17:902:ecd1:b0:263:57e7:8950 with SMTP id d9443c01a7336-2681217f3e4mr48631885ad.19.1758146167572;
        Wed, 17 Sep 2025 14:56: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 v4 13/18] xen/riscv: implement p2m_next_level()
Date: Wed, 17 Sep 2025 23:55:33 +0200
Message-ID: <30a203de44b04a06613aa1f873a072a4594c5bb4.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.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:
- 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 V4:
 - make `page` argument of page_to_p2m_table pointer-to-const.
 - Move p2m_next_level()'s local variable `ret` to the more narrow space where
   it is really used.
 - Drop stale ASSERT() in p2m_next_level().
 - Stray blank after * in declaration of paging_alloc_page().
 - Decrease p2m_freelist.total_pages when a page is taken from the p2m freelist.
---
Changes in V3:
 - s/p2me_is_mapping/p2m_is_mapping to be in syc with other p2m_is_*() functions.
 - clear_and_clean_page() in p2m_create_table() instead of clear_page() to be
   sure that page is cleared and d-cache is flushed for it.
 - Move ASSERT(level != 0) in p2m_next_level() ahead of trying to allocate a
   page table.
 - Update p2m_create_table() to allocate metadata page to store p2m type in it
   for each entry of page table.
 - Introduce paging_alloc_page() and use it inside p2m_alloc_page().
 - Add allocated page to p2m->pages list in p2m_alloc_page() to simplify
   a caller code a little bit.
 - Drop p2m_is_mapping() and use pte_is_mapping() instead as P2M PTE's valid
   bit doesn't have another purpose anymore.
 - Update an implementation and prototype of page_to_p2m_table(), it is enough
   to pass only a page as an argument.
---
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/p2m_is_mapping.
---
 xen/arch/riscv/include/asm/paging.h |  2 +
 xen/arch/riscv/p2m.c                | 79 ++++++++++++++++++++++++++++-
 xen/arch/riscv/paging.c             | 12 +++++
 3 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/include/asm/paging.h b/xen/arch/riscv/include/asm/paging.h
index 9712aa77c5..69cb414962 100644
--- a/xen/arch/riscv/include/asm/paging.h
+++ b/xen/arch/riscv/include/asm/paging.h
@@ -15,4 +15,6 @@ int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages);
 
 void paging_free_page(struct domain *d, struct page_info *pg);
 
+struct page_info * paging_alloc_page(struct domain *d);
+
 #endif /* ASM_RISCV_PAGING_H */
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 2d4433360d..bf4945e99f 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -414,6 +414,48 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
     return e;
 }
 
+/* Generate table entry with correct attributes. */
+static pte_t page_to_p2m_table(const struct page_info *page)
+{
+    /*
+     * p2m_invalid will be ignored inside p2m_pte_from_mfn() as is_table is
+     * set to true and p2m_type_t shouldn't be applied for PTEs which
+     * describe an intermidiate table.
+     */
+    return p2m_pte_from_mfn(page_to_mfn(page), p2m_invalid, true);
+}
+
+static struct page_info *p2m_alloc_page(struct p2m_domain *p2m)
+{
+    struct page_info *pg = paging_alloc_page(p2m->domain);
+
+    if ( pg )
+        page_list_add(pg, &p2m->pages);
+
+    return pg;
+}
+
+/*
+ * Allocate a new page table page with an extra metadata 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;
+
+    ASSERT(!pte_is_valid(*entry));
+
+    page = p2m_alloc_page(p2m);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    clear_and_clean_page(page, p2m->clean_dcache);
+
+    p2m_write_pte(entry, page_to_p2m_table(page), p2m->clean_dcache);
+
+    return 0;
+}
+
 #define P2M_TABLE_MAP_NONE 0
 #define P2M_TABLE_MAP_NOMEM 1
 #define P2M_TABLE_SUPER_PAGE 2
@@ -438,9 +480,42 @@ 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;
+    mfn_t mfn;
+
+    /* The function p2m_next_level() is never called at the last level */
+    ASSERT(level != 0);
+
+    entry = *table + offset;
+
+    if ( !pte_is_valid(*entry) )
+    {
+        int ret;
+
+        if ( !alloc_tbl )
+            return P2M_TABLE_MAP_NONE;
+
+        ret = p2m_create_table(p2m, entry);
+        if ( ret )
+            return P2M_TABLE_MAP_NOMEM;
+    }
+
+    if ( pte_is_mapping(*entry) )
+        return P2M_TABLE_SUPER_PAGE;
+
+    mfn = mfn_from_pte(*entry);
+
+    unmap_domain_page(*table);
+
+    /*
+     * TODO: There's an inefficiency here:
+     *       In p2m_create_table(), the page is mapped to clear it.
+     *       Then that mapping is torn down in p2m_create_table(),
+     *       only to be re-established here.
+     */
+    *table = map_domain_page(mfn);
 
-    return P2M_TABLE_MAP_NONE;
+    return P2M_TABLE_NORMAL;
 }
 
 static void p2m_put_foreign_page(struct page_info *pg)
diff --git a/xen/arch/riscv/paging.c b/xen/arch/riscv/paging.c
index 049b850e03..803b026f34 100644
--- a/xen/arch/riscv/paging.c
+++ b/xen/arch/riscv/paging.c
@@ -115,6 +115,18 @@ void paging_free_page(struct domain *d, struct page_info *pg)
     spin_unlock(&d->arch.paging.lock);
 }
 
+struct page_info *paging_alloc_page(struct domain *d)
+{
+    struct page_info *pg;
+
+    spin_lock(&d->arch.paging.lock);
+    pg = page_list_remove_head(&d->arch.paging.freelist);
+    ACCESS_ONCE(d->arch.paging.total_pages)--;
+    spin_unlock(&d->arch.paging.lock);
+
+    return pg;
+}
+
 /* Domain paging struct initialization. */
 int paging_domain_init(struct domain *d)
 {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 22:06:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 22:06:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125687.1467612 (Exim 4.92)
	(envelope-from )
	id 1uz0Hs-0007Xn-N5; Wed, 17 Sep 2025 22:06:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125687.1467612; Wed, 17 Sep 2025 22:06: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 1uz0Hs-0007Xg-KD; Wed, 17 Sep 2025 22:06:04 +0000
Received: by outflank-mailman (input) for mailman id 1125687;
 Wed, 17 Sep 2025 22:06: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 1uz08U-0007Lu-Jb
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:22 +0000
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com
 [2607:f8b0:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 21cc1b56-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:56:16 +0200 (CEST)
Received: by mail-pl1-x635.google.com with SMTP id
 d9443c01a7336-26983b5411aso1412745ad.1
 for ; Wed, 17 Sep 2025 14:56:15 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 21cc1b56-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146174; x=1758750974; darn=lists.xenproject.org;
        h=content-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=Ds+7Ox7wi39qespVZnaAV04YH/eEJPfsE5uBaveiQ6o=;
        b=X3k5Xdx1SdA3Lh4hyBJCOZfuBfrMKFPC+KVlPVTwQb3f8KBtYK9I+MHL5VGaWpth+M
         DeVp6elKvzbWVnzcavitHr7jeL7XqAX4kx4QIwtaMOrllJZwRtST5ZKnR3UaXKjyMoFW
         hszFbCfjs26Hor1C5F4O8R320LDz0r1KpSp2hSfZA9Hb5zIJ4G6Kdpk7GJHIZ4aHhHqB
         /5++0Y6vw3jk/y08GSqRlEFnALtiBbyu9qpBbmps6CZ+WxNlGWRy3qNGqiZWeqE0tAZl
         mMBRDwrw3rmIGWLDX2S7uK3Q2D77SAgaxgselHa+3LK6UVbOXS76eKb5Z5/D3h1b98Lf
         ijFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146174; x=1758750974;
        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=Ds+7Ox7wi39qespVZnaAV04YH/eEJPfsE5uBaveiQ6o=;
        b=ROFwxTu23+0gYBqmEB6sv9716KMxELbfV3xHkdAty5mvtFy9GFEz+Y9CdtW0DfnJ9o
         Gg4+iXLYOM3f6YkBzPmsqLQS+5nF1XaPt0uatsTjkisbt7z66yaF7awpmMmqPCtalcif
         Wa0nQ1NU1Nos8OOVLGoHClhp1Qu0p5oUv25Q/p1fGyMOsgnkROpbCUAs6+GwNq70U/fG
         +DxgsoAmK0RrS1VbUqvGdqqw8QmphdFQ6CLpDkkiV8DlsmJYXTwogr8Q8sa+2eWrucaY
         yay4CihJhREI3EtTHt4+1w5f6HFWdIFJNVEeYHbH9/RyoTJXPz38IwUcI+5rS7Jq2OPe
         kYxQ==
X-Gm-Message-State: AOJu0Yx08K61vjQL+HsHzuGl7vhcMg7Biq17HJENHvSuVk4A6IR0pOsk
	9EAM7BSo3EA0e4OEk6I6T3pAgONEZ1A3+daqA5VdxIFXgIKr+hjPLj4Vht1861skNZY=
X-Gm-Gg: ASbGnctatPBLQrEQy0Q4SGSGidS3EYyJj2k358f9ZkGU68Kj3CmLDJwWGstrRzcc+Cu
	WgzfLbZxbKL6N1iKAZbmMYVS9HQS9jTllxV7izch/Ax5GHE3158A3+hiU7boTKnNvvakWgmaxrK
	AcXgL+9cJFnjhQNkWfsIYnzeqkKgULV2bUleZMfH2XgjoZ7bckdoulPBeTzMvkt+RlDaGoJ/d8J
	GhDHP8G7++1pip1f6rFTdNdsvzzC/sCSG++TNmBISZZyCiZ+9Dm7gyJOBqyU/bzQXcMgPVLT41X
	SajT5rSPtnwXfORlbphdgb9mZjz0Ai7X/JlIkAQ/I6CWpX55OaWYODr2P907KWRMK0T+OpbcErT
	f+nN5egqJG5W99NDJXcMxl4o/K9Zb3W45VtdjJsBNl9Pj
X-Google-Smtp-Source: AGHT+IEAXrWsRpP+CUwqPeg1T17Oa8Q5eqNZLWNS3IJc6kCdn4FmDzismYUiV8EHK23q6btjvLkasw==
X-Received: by 2002:a17:902:ecce:b0:250:643e:c947 with SMTP id d9443c01a7336-268137ee403mr42768085ad.28.1758146173958;
        Wed, 17 Sep 2025 14:56: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 18/18] xen/riscv: introduce metadata table to store P2M type
Date: Wed, 17 Sep 2025 23:55:38 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

RISC-V's PTE has only two available bits that can be used to store the P2M
type. This is insufficient to represent all the current RISC-V P2M types.
Therefore, some P2M types must be stored outside the PTE bits.

To address this, a metadata table is introduced to store P2M types that
cannot fit in the PTE itself. Not all P2M types are stored in the
metadata table—only those that require it.

The metadata table is linked to the intermediate page table via the
`struct page_info`'s v.md.metadata field of the corresponding intermediate
page.
Such pages are allocated with MEMF_no_owner, which allows us to use
the v field for the purpose of storing the metadata table.

To simplify the allocation and linking of intermediate and metadata page
tables, `p2m_{alloc,free}_table()` functions are implemented.

These changes impact `p2m_split_superpage()`, since when a superpage is
split, it is necessary to update the metadata table of the new
intermediate page table — if the entry being split has its P2M type set
to `p2m_ext_storage` in its `P2M_TYPES` bits. In addition to updating
the metadata of the new intermediate page table, the corresponding entry
in the metadata for the original superpage is invalidated.

Also, update p2m_{get,set}_type to work with P2M types which don't fit
into PTE bits.

Suggested-by: Jan Beulich 
Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Add Suggested-by: Jan Beulich .
 - Update the comment above declation of md structure inside struct page_info to:
   "Page is used as an intermediate P2M page table".
 - Allocate metadata table on demand to save some memory. (1)
 - Rework p2m_set_type():
   - Add allocatation of metadata page only if needed.
   - Move a check what kind of type we are handling inside p2m_set_type().
 - Move mapping of metadata page inside p2m_get_type() as it is needed only
   in case if PTE's type is equal to p2m_ext_storage.
 - Add some description to p2m_get_type() function.
 - Drop blank after return type of p2m_alloc_table().
 - Drop allocation of metadata page inside p2m_alloc_table becaues of (1).
 - Fix p2m_free_table() to free metadata page only if it was allocated.
---
Changes in V3:
 - Add is_p2m_foreign() macro and connected stuff.
 - Change struct domain *d argument of p2m_get_page_from_gfn() to
   struct p2m_domain.
 - Update the comment above p2m_get_entry().
 - s/_t/p2mt for local variable in p2m_get_entry().
 - Drop local variable addr in p2m_get_entry() and use gfn_to_gaddr(gfn)
   to define offsets array.
 - Code style fixes.
 - Update a check of rc code from p2m_next_level() in p2m_get_entry()
   and drop "else" case.
 - Do not call p2m_get_type() if p2m_get_entry()'s t argument is NULL.
 - Use struct p2m_domain instead of struct domain for p2m_lookup() and
   p2m_get_page_from_gfn().
 - Move defintion of get_page() from "xen/riscv: implement mfn_valid() and page reference, ownership handling helpers"
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/mm.h |   9 ++
 xen/arch/riscv/p2m.c            | 247 +++++++++++++++++++++++++++-----
 2 files changed, 218 insertions(+), 38 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 1b16809749..1464119b6f 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -149,6 +149,15 @@ struct page_info
             /* Order-size of the free chunk this page is the head of. */
             unsigned int order;
         } free;
+
+        /* Page is used as an intermediate P2M page table */
+        struct {
+            /*
+             * Pointer to a page which store metadata for an intermediate page
+             * table.
+             */
+            struct page_info *metadata;
+        } md;
     } v;
 
     union {
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index a5ea61fe61..14809bd089 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -16,6 +16,16 @@
 #include 
 #include 
 
+/*
+ * P2M PTE context is used only when a PTE's P2M type is p2m_ext_storage.
+ * In this case, the P2M type is stored separately in the metadata page.
+ */
+struct p2m_pte_ctx {
+    struct page_info *pt_page;   /* Page table page containing the PTE. */
+    unsigned int index;          /* Index of the PTE within that page. */
+    unsigned int level;          /* Paging level at which the PTE resides. */
+};
+
 unsigned long __ro_after_init gstage_mode;
 unsigned int __ro_after_init gstage_root_level;
 
@@ -289,24 +299,98 @@ 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_set_type(pte_t *pte, p2m_type_t t)
+static struct page_info * p2m_alloc_table(struct p2m_domain *p2m);
+
+/*
+ * `pte` – PTE entry for which the type `t` will be stored.
+ *
+ * If `t` is `p2m_ext_storage`, both `ctx` and `p2m` must be provided;
+ * otherwise, they may be NULL.
+ */
+static void p2m_set_type(pte_t *pte, const p2m_type_t t,
+                         struct p2m_pte_ctx *ctx,
+                         struct p2m_domain *p2m)
 {
-    int rc = 0;
+    /*
+    * For the root page table (16 KB in size), we need to select the correct
+    * metadata table, since allocations are 4 KB each. In total, there are
+    * 4 tables of 4 KB each.
+    * For none-root page table index of ->pt_page[] will be always 0 as
+    * index won't be higher then 511. ASSERT() below verifies that.
+    */
+    struct page_info **md_pg =
+        &ctx->pt_page[ctx->index / PAGETABLE_ENTRIES].v.md.metadata;
+    pte_t *metadata = NULL;
+
+     /* Be sure that an index correspondent to page level is passed. */
+    ASSERT(ctx->index <= P2M_PAGETABLE_ENTRIES(ctx->level));
+
+    if ( !*md_pg && (t >= p2m_first_external) )
+    {
+        /*
+         * Ensure that when `t` is stored outside the PTE bits
+         * (i.e. `t == p2m_ext_storage` or higher),
+         * both `ctx` and `p2m` are provided.
+         */
+        ASSERT(p2m && ctx);
 
-    if ( t > p2m_first_external )
-        panic("unimplemeted\n");
-    else
+        if ( ctx->level <= P2M_SUPPORTED_LEVEL_MAPPING )
+        {
+            struct domain *d = p2m->domain;
+
+            *md_pg = p2m_alloc_table(p2m);
+            if ( !*md_pg )
+            {
+                printk("%s: can't allocate extra memory for dom%d\n",
+                        __func__, d->domain_id);
+                domain_crash(d);
+            }
+        }
+        else
+            /*
+             * It is not legal to set a type for an entry which shouldn't
+             * be mapped.
+             */
+            ASSERT_UNREACHABLE();
+    }
+
+    if ( *md_pg )
+        metadata = __map_domain_page(*md_pg);
+
+    if ( t < p2m_first_external )
+    {
         pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK);
 
-    return rc;
+        if ( metadata )
+            metadata[ctx->index].pte = p2m_invalid;
+    }
+    else
+    {
+        pte->pte |= MASK_INSR(p2m_ext_storage, P2M_TYPE_PTE_BITS_MASK);
+
+        metadata[ctx->index].pte = t;
+    }
+
+    if ( metadata )
+        unmap_domain_page(metadata);
 }
 
-static p2m_type_t p2m_get_type(const pte_t pte)
+/*
+ * `pte` -> PTE entry that stores the PTE's type.
+ *
+ * If the PTE's type is `p2m_ext_storage`, `ctx` should be provided;
+ * otherwise it could be NULL.
+ */
+static p2m_type_t p2m_get_type(const pte_t pte, const struct p2m_pte_ctx *ctx)
 {
     p2m_type_t type = MASK_EXTR(pte.pte, P2M_TYPE_PTE_BITS_MASK);
 
     if ( type == p2m_ext_storage )
-        panic("unimplemented\n");
+    {
+        pte_t *md = __map_domain_page(ctx->pt_page->v.md.metadata);
+        type = md[ctx->index].pte;
+        unmap_domain_page(ctx->pt_page->v.md.metadata);
+    }
 
     return type;
 }
@@ -381,7 +465,10 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
     }
 }
 
-static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
+static pte_t p2m_pte_from_mfn(const mfn_t mfn, const p2m_type_t t,
+                              struct p2m_pte_ctx *p2m_pte_ctx,
+                              const bool is_table,
+                              struct p2m_domain *p2m)
 {
     pte_t e = (pte_t) { PTE_VALID };
 
@@ -402,7 +489,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
     if ( !is_table )
     {
         p2m_set_permission(&e, t);
-        p2m_set_type(&e, t);
+        p2m_set_type(&e, t, p2m_pte_ctx, p2m);
     }
     else
         /*
@@ -421,8 +508,13 @@ static pte_t page_to_p2m_table(const struct page_info *page)
      * p2m_invalid will be ignored inside p2m_pte_from_mfn() as is_table is
      * set to true and p2m_type_t shouldn't be applied for PTEs which
      * describe an intermidiate table.
+     * That it also a reason why `p2m_pte_ctx` argument is NULL as a type
+     * isn't set for p2m tables.
+     * As p2m_pte_from_mfn()'s last argument is necessary only when a type
+     * should be set. For p2m table we don't set a type, so it is okay
+     * to have NULL for this argument.
      */
-    return p2m_pte_from_mfn(page_to_mfn(page), p2m_invalid, true);
+    return p2m_pte_from_mfn(page_to_mfn(page), p2m_invalid, NULL, true, NULL);
 }
 
 static struct page_info *p2m_alloc_page(struct p2m_domain *p2m)
@@ -435,22 +527,47 @@ static struct page_info *p2m_alloc_page(struct p2m_domain *p2m)
     return pg;
 }
 
+static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg);
+
+/*
+ * Allocate a page table with an additional extra page to store
+ * metadata for each entry of the page table.
+ * Link this metadata page to page table page's list field.
+ */
+static struct page_info *p2m_alloc_table(struct p2m_domain *p2m)
+{
+    struct page_info *page_tbl = p2m_alloc_page(p2m);
+
+    if ( !page_tbl )
+        return NULL;
+
+    clear_and_clean_page(page_tbl, p2m->clean_dcache);
+
+    return page_tbl;
+}
+
+/*
+ * Free page table's page and metadata page linked to page table's page.
+ */
+static void p2m_free_table(struct p2m_domain *p2m, struct page_info *tbl_pg)
+{
+    ASSERT(tbl_pg->v.md.metadata);
+
+    if ( tbl_pg->v.md.metadata )
+        p2m_free_page(p2m, tbl_pg->v.md.metadata);
+    p2m_free_page(p2m, tbl_pg);
+}
+
 /*
  * Allocate a new page table page with an extra metadata 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;
+    struct page_info *page = p2m_alloc_table(p2m);
 
     ASSERT(!pte_is_valid(*entry));
 
-    page = p2m_alloc_page(p2m);
-    if ( page == NULL )
-        return -ENOMEM;
-
-    clear_and_clean_page(page, p2m->clean_dcache);
-
     p2m_write_pte(entry, page_to_p2m_table(page), p2m->clean_dcache);
 
     return 0;
@@ -599,12 +716,14 @@ static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg)
 
 /* Free pte sub-tree behind an entry */
 static void p2m_free_subtree(struct p2m_domain *p2m,
-                             pte_t entry, unsigned int level)
+                             pte_t entry,
+                             const struct p2m_pte_ctx *p2m_pte_ctx)
 {
     unsigned int i;
     pte_t *table;
     mfn_t mfn;
     struct page_info *pg;
+    unsigned int level = p2m_pte_ctx->level;
 
     /*
      * Check if the level is valid: only 4K - 2M - 1G mappings are supported.
@@ -620,7 +739,7 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
 
     if ( (level == 0) || pte_is_superpage(entry, level) )
     {
-        p2m_type_t p2mt = p2m_get_type(entry);
+        p2m_type_t p2mt = p2m_get_type(entry, p2m_pte_ctx);
 
 #ifdef CONFIG_IOREQ_SERVER
         /*
@@ -629,7 +748,7 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
          * has failed (error case).
          * So, at worst, the spurious mapcache invalidation might be sent.
          */
-        if ( p2m_is_ram(p2m_get_type(p2m, entry)) &&
+        if ( p2m_is_ram(p2mt) &&
              domain_has_ioreq_server(p2m->domain) )
             ioreq_request_mapcache_invalidate(p2m->domain);
 #endif
@@ -639,9 +758,21 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
         return;
     }
 
-    table = map_domain_page(pte_get_mfn(entry));
+    mfn = pte_get_mfn(entry);
+    ASSERT(mfn_valid(mfn));
+    table = map_domain_page(mfn);
+    pg = mfn_to_page(mfn);
+
     for ( i = 0; i < P2M_PAGETABLE_ENTRIES(level); i++ )
-        p2m_free_subtree(p2m, table[i], level - 1);
+    {
+        struct p2m_pte_ctx tmp_ctx = {
+            .pt_page = pg,
+            .index = i,
+            .level = level -1
+        };
+
+        p2m_free_subtree(p2m, table[i], &tmp_ctx);
+    }
 
     unmap_domain_page(table);
 
@@ -653,17 +784,13 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
      */
     p2m_tlb_flush_sync(p2m);
 
-    mfn = pte_get_mfn(entry);
-    ASSERT(mfn_valid(mfn));
-
-    pg = mfn_to_page(mfn);
-
-    p2m_free_page(p2m, pg);
+    p2m_free_table(p2m, pg);
 }
 
 static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
                                 unsigned int level, unsigned int target,
-                                const unsigned int *offsets)
+                                const unsigned int *offsets,
+                                struct page_info *tbl_pg)
 {
     struct page_info *page;
     unsigned long i;
@@ -682,7 +809,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
     ASSERT(level > target);
     ASSERT(pte_is_superpage(*entry, level));
 
-    page = p2m_alloc_page(p2m);
+    page = p2m_alloc_table(p2m);
     if ( !page )
     {
         /*
@@ -707,6 +834,22 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
         pte = *entry;
         pte_set_mfn(&pte, mfn_add(mfn, i << level_order));
 
+        if ( MASK_EXTR(pte.pte, P2M_TYPE_PTE_BITS_MASK) == p2m_ext_storage )
+        {
+            struct p2m_pte_ctx p2m_pte_ctx = {
+                .pt_page = tbl_pg,
+                .index = offsets[level],
+            };
+
+            p2m_type_t old_type = p2m_get_type(pte, &p2m_pte_ctx);
+
+            p2m_pte_ctx.pt_page = page;
+            p2m_pte_ctx.index = i;
+            p2m_pte_ctx.level = level;
+
+            p2m_set_type(&pte, old_type, &p2m_pte_ctx, p2m);
+        }
+
         write_pte(new_entry, pte);
     }
 
@@ -718,7 +861,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
      */
     if ( next_level != target )
         rv = p2m_split_superpage(p2m, table + offsets[next_level],
-                                 level - 1, target, offsets);
+                                 level - 1, target, offsets, page);
 
     if ( p2m->clean_dcache )
         clean_dcache_va_range(table, PAGE_SIZE);
@@ -812,13 +955,21 @@ static int p2m_set_entry(struct p2m_domain *p2m,
     {
         /* We need to split the original page. */
         pte_t split_pte = *entry;
+        struct page_info *tbl_pg = virt_to_page(table);
 
         ASSERT(pte_is_superpage(*entry, level));
 
-        if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets) )
+        if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets,
+                                  tbl_pg) )
         {
+            struct p2m_pte_ctx tmp_ctx = {
+                .pt_page = tbl_pg,
+                .index = offsets[level],
+                .level = level,
+            };
+
             /* Free the allocated sub-tree */
-            p2m_free_subtree(p2m, split_pte, level);
+            p2m_free_subtree(p2m, split_pte, &tmp_ctx);
 
             rc = -ENOMEM;
             goto out;
@@ -856,7 +1007,13 @@ static int p2m_set_entry(struct p2m_domain *p2m,
         p2m_clean_pte(entry, p2m->clean_dcache);
     else
     {
-        pte_t pte = p2m_pte_from_mfn(mfn, t, false);
+        struct p2m_pte_ctx tmp_ctx = {
+            .pt_page = virt_to_page(table),
+            .index =  offsets[level],
+            .level = level,
+        };
+
+        pte_t pte = p2m_pte_from_mfn(mfn, t, &tmp_ctx, false, p2m);
 
         p2m_write_pte(entry, pte, p2m->clean_dcache);
 
@@ -892,7 +1049,15 @@ static int p2m_set_entry(struct p2m_domain *p2m,
     if ( pte_is_valid(orig_pte) &&
          (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
           (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
-        p2m_free_subtree(p2m, orig_pte, level);
+    {
+        struct p2m_pte_ctx tmp_ctx = {
+                .pt_page = virt_to_page(table),
+                .index = offsets[level],
+                .level = level,
+        };
+
+        p2m_free_subtree(p2m, orig_pte, &tmp_ctx);
+    }
 
  out:
     unmap_domain_page(table);
@@ -979,7 +1144,6 @@ int map_regions_p2mt(struct domain *d,
     return rc;
 }
 
-
 /*
  * p2m_get_entry() should always return the correct order value, even if an
  * entry is not present (i.e. the GFN is outside the range):
@@ -1082,7 +1246,14 @@ static mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
     if ( pte_is_valid(entry) )
     {
         if ( t )
-            *t = p2m_get_type(entry);
+        {
+            struct p2m_pte_ctx p2m_pte_ctx = {
+                .pt_page = virt_to_page(table),
+                .index = offsets[level],
+            };
+
+            *t = p2m_get_type(entry,&p2m_pte_ctx);
+        }
 
         mfn = pte_get_mfn(entry);
         /*
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 22:06:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 22:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125715.1467622 (Exim 4.92)
	(envelope-from )
	id 1uz0IL-0008C9-1o; Wed, 17 Sep 2025 22:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125715.1467622; Wed, 17 Sep 2025 22: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 1uz0IK-0008C0-V7; Wed, 17 Sep 2025 22:06:32 +0000
Received: by outflank-mailman (input) for mailman id 1125715;
 Wed, 17 Sep 2025 22:06: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 1uz08U-0007Lt-4g
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:22 +0000
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com
 [2607:f8b0:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 20fb241d-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:14 +0200 (CEST)
Received: by mail-pl1-x635.google.com with SMTP id
 d9443c01a7336-24b13313b1bso2093165ad.2
 for ; Wed, 17 Sep 2025 14:56:14 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14: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: 20fb241d-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146173; x=1758750973; darn=lists.xenproject.org;
        h=content-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=vfs2AsCBNAItTu5Fl9oEWjrrGVJNBfidRIAng3EmHkc=;
        b=G7Rk5pG/fcWwdycM+ATE8p+T/9n95vqciYYNymeKqIsCVRABUOfmr6Xdc7bizXy8fb
         QOER9zMRMHC/Q3AatFEU6gzDPQwq4dSVxX2AEETRatdTGDnavvG/aEuMkacJubWqachc
         CHk2GdGgj4PhbhDEk7jpPwcHfdxY6m710It7Rra6FVEAuZHidGZAnpWYwqsGa0ix5xO1
         WewTCUPlLt/6P4r5lI6JPZ+Hg67FlaNmAHeBqpUA06jMVwTHljMy57aEXoufwU/R8BrM
         Hj13dIsK5OxXl/LwpKfpI4YH+i5Dbz6hItucWYjYFE+i8V4NGUBU7U9y+e9A6IGTX1fX
         CvaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146173; x=1758750973;
        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=vfs2AsCBNAItTu5Fl9oEWjrrGVJNBfidRIAng3EmHkc=;
        b=P/2sRBQtgXzMtfI1TCwfZrMEDsMgaz3BM/i65OJBTTHFMi+ea1H7ZnQ7Y/QR3C1kbY
         PP1PV92tohkrS1gMzUP+tvsV4IaRk0kYyb9SHiMw3BxyqcSR+eBmAPbaEjnL7g4eL1Ki
         vO5YaYbO64swfs05f79GWAw6BrKA0PsB8P5LCKoyqWvgry2PuvzhVTZQEsd3sNx/TI4G
         CaTUm7zPi5k1SNy6lu7R2BA10tIQu4Q6w/E1CH9EyxohFMxRiKdqCw8Koxv3I/TSuOfR
         yMeLqVawqe/qnW6qQ4tLOXWztNk1ZWyS/Q4IRc4BvRKlIzjYmoIeiQgVE1SQUnhyYVfM
         8Ilg==
X-Gm-Message-State: AOJu0Ywp28H8KBzaAuE9ltHCFKNHyLrebzuq7dZlBCxmu6I+5qzrO4Wm
	1pg8t79edm0IMC2/k14CpBfWMlD2gpvbxzI6PJ4UQxc99YSwVG1ltzFZyiRgW3xVmMI=
X-Gm-Gg: ASbGncuDt2/5UB9wE0r3mw6Epy/hco7SI5L407SOZ0L3GghsZl01bRGCigDFKH8bCaH
	Q9T1JzVvcAbQhF4JJRWpC5ZDOwMebqmqVT/PEgK9jZVNbSMg3W0ktB8Wb1HBJpfdB69tqjgDE29
	uQQkbIwTBzzWsUqXD9bq9WAKZwmnmUDGSfa+ARk/JbnpjJeOLDS7gEkewWyZv98fwGlzmekMI2w
	Q48YvwvRsWX7hd6lCXXGlSZt/W576UVXwvJNv9kOj3ifwGF2RHup99P+DZ5L5bJci4Y3vzdSmAx
	TO1gk94w0w7MAwv7StFlc3xS4QcUp23ATr+OD4/Xyw3mudsxuAjsMUWxJ5FHvcjaGSAs7rl7no1
	ZzsGmfCDZQn0a4MOW4I9GBij1qlxt6oY1TKYGHtHPU/f7
X-Google-Smtp-Source: AGHT+IF5JNWP8YADOHVCKFGwMqryhhQhwOg2dDMlbKj2M+OKPCoLlTF0HNhA7NwXfYgS6rzQ8zcG4Q==
X-Received: by 2002:a17:902:ef0f:b0:24c:965a:f97e with SMTP id d9443c01a7336-26811ba541dmr52358885ad.2.1758146172665;
        Wed, 17 Sep 2025 14:56: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 17/18] xen/riscv: add support of page lookup by GFN
Date: Wed, 17 Sep 2025 23:55:37 +0200
Message-ID: <5065d9f1552fd940cc19087d8e00a0fa3519e66c.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.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.
 - Introduce get_page().

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 level
    numbering 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.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Update prototype of p2m_is_locked() to return bool and accept pointer-to-const.
 - Correct the comment above p2m_get_entry().
 - Drop the check "BUILD_BUG_ON(XEN_PT_LEVEL_MAP_MASK(0) != PAGE_MASK);" inside
   p2m_get_entry() as it is stale and it was needed to sure that 4k page(s) are
   used on L3 (in Arm terms) what is true for RISC-V. (if not special extension
   are used). It was another reason for Arm to have it (and I copied it to RISC-V),
   but it isn't true for RISC-V. (some details could be found in response to the
   patch).
 - Style fixes.
 - Add explanatory comment what the loop inside "gfn is higher then the highest
   p2m mapping" does. Move this loop to separate function check_outside_boundary()
   to cover both boundaries (lower_mapped_gfn and max_mapped_gfn).
 - There is not need to allocate a page table as it is expected that
   p2m_get_entry() normally would be called after a corresponding p2m_set_entry()
   was called. So change 'true' to 'false' in a page table walking loop inside
   p2m_get_entry().
 - Correct handling of p2m_is_foreign case inside p2m_get_page_from_gfn().
 - Introduce and use P2M_LEVEL_MASK instead of XEN_PT_LEVEL_MASK as it isn't take
   into account two extra bits for root table in case of P2M.
 - Drop stale item from "change in v3" - Add is_p2m_foreign() macro and connected stuff.
 - Add p2m_read_(un)lock().
---
Changes in V3:
 - Change struct domain *d argument of p2m_get_page_from_gfn() to
   struct p2m_domain.
 - Update the comment above p2m_get_entry().
 - s/_t/p2mt for local variable in p2m_get_entry().
 - Drop local variable addr in p2m_get_entry() and use gfn_to_gaddr(gfn)
   to define offsets array.
 - Code style fixes.
 - Update a check of rc code from p2m_next_level() in p2m_get_entry()
   and drop "else" case.
 - Do not call p2m_get_type() if p2m_get_entry()'s t argument is NULL.
 - Use struct p2m_domain instead of struct domain for p2m_lookup() and
   p2m_get_page_from_gfn().
 - Move defintion of get_page() from "xen/riscv: implement mfn_valid() and page reference, ownership handling helpers"
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/p2m.h |  24 ++++
 xen/arch/riscv/mm.c              |  13 +++
 xen/arch/riscv/p2m.c             | 186 +++++++++++++++++++++++++++++++
 3 files changed, 223 insertions(+)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 29685c7852..2d0b0375d5 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -44,6 +44,12 @@ extern unsigned int gstage_root_level;
 #define P2M_PAGETABLE_ENTRIES(lvl) \
     (BIT(PAGETABLE_ORDER + P2M_ROOT_EXTRA_BITS(lvl), UL))
 
+#define GFN_MASK(lvl) (P2M_PAGETABLE_ENTRIES(lvl) - 1UL)
+
+#define P2M_LEVEL_SHIFT(lvl) (P2M_LEVEL_ORDER(lvl) + PAGE_SHIFT)
+
+#define P2M_LEVEL_MASK(lvl) (GFN_MASK(lvl) << P2M_LEVEL_SHIFT(lvl))
+
 #define paddr_bits PADDR_BITS
 
 /* Get host p2m table */
@@ -229,6 +235,24 @@ static inline bool p2m_is_write_locked(struct p2m_domain *p2m)
 
 unsigned long construct_hgatp(struct p2m_domain *p2m, uint16_t vmid);
 
+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 bool p2m_is_locked(const struct p2m_domain *p2m)
+{
+    return rw_is_locked(&p2m->lock);
+}
+
+struct page_info *p2m_get_page_from_gfn(struct p2m_domain *p2m, gfn_t gfn,
+                                        p2m_type_t *t);
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 8c6e8075f3..e34b1b674a 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -675,3 +675,16 @@ struct domain *page_get_owner_and_reference(struct page_info *page)
 
     return owner;
 }
+
+bool get_page(struct page_info *page, const struct domain *domain)
+{
+    const struct domain *owner = page_get_owner_and_reference(page);
+
+    if ( likely(owner == domain) )
+        return true;
+
+    if ( owner != NULL )
+        put_page(page);
+
+    return false;
+}
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 1577b09b15..a5ea61fe61 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -978,3 +978,189 @@ int map_regions_p2mt(struct domain *d,
 
     return rc;
 }
+
+
+/*
+ * p2m_get_entry() should always return the correct order value, even if an
+ * entry is not present (i.e. the GFN is outside the range):
+ *   [p2m->lowest_mapped_gfn, p2m->max_mapped_gfn]).    (1)
+ *
+ * This ensures that callers of p2m_get_entry() can determine what range of
+ * address space would be altered by a corresponding p2m_set_entry().
+ * Also, it would help to avoid cost page walks for GFNs outside range (1).
+ *
+ * Therefore, this function returns true for GFNs outside range (1), and in
+ * that case the corresponding level is returned via the level_out argument.
+ * Otherwise, it returns false and p2m_get_entry() performs a page walk to
+ * find the proper entry.
+ */
+static bool check_outside_boundary(gfn_t gfn, gfn_t boundary, bool is_lower,
+                                   unsigned int *level_out)
+{
+    unsigned int level;
+
+    if ( (is_lower && gfn_x(gfn) < gfn_x(boundary)) ||
+         (!is_lower && gfn_x(gfn) > gfn_x(boundary)) )
+    {
+        for ( level = P2M_ROOT_LEVEL; level; level-- )
+        {
+            unsigned long mask = PFN_DOWN(P2M_LEVEL_MASK(level));
+
+            if ( (is_lower && ((gfn_x(gfn) & mask) < gfn_x(boundary))) ||
+                 (!is_lower && ((gfn_x(gfn) & mask) > gfn_x(boundary))) )
+            {
+                *level_out = level;
+                return true;
+            }
+        }
+    }
+
+    return false;
+}
+
+/*
+ * Get the details of a given gfn.
+ *
+ * If the entry is present, the associated MFN will be returned and the
+ * p2m type of the mapping.
+ * 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)
+{
+    unsigned int level = 0;
+    pte_t entry, *table;
+    int rc;
+    mfn_t mfn = INVALID_MFN;
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
+
+    ASSERT(p2m_is_locked(p2m));
+
+    if ( valid )
+        *valid = false;
+
+    if ( check_outside_boundary(gfn, p2m->lowest_mapped_gfn, true, &level) )
+        goto out;
+
+    if ( check_outside_boundary(gfn, p2m->max_mapped_gfn, false, &level) )
+        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, false, level, &table, offsets[level]);
+        if ( (rc == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
+            goto out_unmap;
+
+        if ( rc != P2M_TABLE_NORMAL )
+            break;
+    }
+
+    entry = table[offsets[level]];
+
+    if ( pte_is_valid(entry) )
+    {
+        if ( t )
+            *t = p2m_get_type(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(P2M_LEVEL_ORDER(level), UL) - 1));
+
+        if ( valid )
+            *valid = pte_is_valid(entry);
+    }
+
+ out_unmap:
+    unmap_domain_page(table);
+
+ out:
+    if ( page_order )
+        *page_order = P2M_LEVEL_ORDER(level);
+
+    return mfn;
+}
+
+static mfn_t p2m_lookup(struct p2m_domain *p2m, gfn_t gfn, p2m_type_t *t)
+{
+    mfn_t mfn;
+
+    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 p2m_domain *p2m, gfn_t gfn,
+                                        p2m_type_t *t)
+{
+    struct page_info *page;
+    p2m_type_t p2mt = p2m_invalid;
+    mfn_t mfn;
+
+    p2m_read_lock(p2m);
+    mfn = p2m_lookup(p2m, gfn, t);
+
+    if ( !mfn_valid(mfn) )
+    {
+        p2m_read_unlock(p2m);
+        return NULL;
+    }
+
+    if ( t )
+        p2mt = *t;
+
+    page = mfn_to_page(mfn);
+
+    /*
+     * get_page won't work on foreign mapping because the page doesn't
+     * belong to the current domain.
+     */
+    if ( unlikely(p2m_is_foreign(p2mt)) )
+    {
+        const struct domain *fdom = page_get_owner_and_reference(page);
+
+        p2m_read_unlock(p2m);
+
+        if ( fdom )
+        {
+            if ( likely(fdom != p2m->domain) )
+                return page;
+
+            ASSERT_UNREACHABLE();
+            put_page(page);
+        }
+
+        return NULL;
+    }
+
+    p2m_read_unlock(p2m);
+
+    return get_page(page, p2m->domain) ? page : NULL;
+}
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 22:06:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 22:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125717.1467629 (Exim 4.92)
	(envelope-from )
	id 1uz0IL-0008Ea-De; Wed, 17 Sep 2025 22:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125717.1467629; Wed, 17 Sep 2025 22: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 1uz0IL-0008DP-5t; Wed, 17 Sep 2025 22:06:33 +0000
Received: by outflank-mailman (input) for mailman id 1125717;
 Wed, 17 Sep 2025 22:06: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 1uz08O-0007Lt-3V
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:16 +0000
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com
 [2607:f8b0:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1f6bafdc-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:12 +0200 (CEST)
Received: by mail-pf1-x436.google.com with SMTP id
 d2e1a72fcca58-77459bc5d18so278201b3a.2
 for ; Wed, 17 Sep 2025 14:56:12 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 1f6bafdc-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146170; x=1758750970; darn=lists.xenproject.org;
        h=content-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=OEFrn7bFgdED7Mm9Ht8bmIsh0tehbilcDJysf+G4Gcc=;
        b=acPjci2PtpUhZzp5TrdlUKLL/D4sdhh3cBhs51FLPu5HcXLNifcySKAoJxwShxXFEb
         atFKrkY7Y+5UMPq5BsCbZdR2L8L55cteKYHo/D7OCl6P+34qDJvXVmpf5L40KvNd83eC
         hnXp9NIdEg5KYy1lS7TfQbRTwD1Cae9HH35QwzZr6oZbGwCBQgw1a1rSSe2c1vTo8oM2
         yLKQ7JOmLgFBvFk0mnf0Hc9iZjF9JHou6zPoEiGxP2+9PqfJLcrJHpiu71jP3yl/It+M
         xlZPw45b1x0cRwFy1HB3qJwLF+fdrcoHvEC2AqHqN73ReiJjgQC66dnB+AE/T7DL9AyY
         ZRdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146170; x=1758750970;
        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=OEFrn7bFgdED7Mm9Ht8bmIsh0tehbilcDJysf+G4Gcc=;
        b=f+ZJFR062U+UnJWRK2kYYxorqQlzcVfgh9WeL7DIPOKVI748mqLDVrvouuy1OWfVeu
         rAvLPpGP2eYxP0xX6HnQ+6oFDyLCg/HFiHHqB9DqevsLL5vxx/eVuRRAPuRlUQ33WwoG
         iGFqgOL8q+5fzPTdeH4EOeDwWi2wepZovFZ+Rs9RhgARQWyL2ucCyTgGfIXGLJewqnIj
         pBsmrXVBw+KKWJknqLkyCOwD8+31mr65mzi65/SHSk5zAmkcFvyYvPX5hrJG3h35ywWN
         j+kNUh6kn+qZMOTvnxXDp1grQJDyTlApQT6Qq3H4XVYT1hHCCFQhrjlurHvJkQTqZQ7Q
         DrLA==
X-Gm-Message-State: AOJu0YxvggrBtvUy3jK34+fv3nAFL2Qr0R3UaHm/vgWz8bbwKfO58p/p
	3QiKEM3lG7mlQ1vGJy3oJNHdu8MRUXAQLV6OVhpYeR03D+ldv0hUTucmzRlY/lbdXEs=
X-Gm-Gg: ASbGncvHXl8WNuELNoh4hUndJOCLaOmDJFstCh+K6/Dv4zTg1U7hV0b2XS9kV+VDIN5
	R/0GCT8iwlWA77FC8XTpoCRJw6qZnVwp0ySmZbi2veEJbjXt0kyiMdxKh0Gdyr94ZaJDOztsONn
	S3pIwl1DOpxDfsvp09IjuJYer9x59aPh9aAgJQ3QQsGjqbHBaeo1VJ98A/L0YP5FaILlKe1cUOr
	csOaSp59xgpwvtb8gx6dc2YpGJ8VkhkF9m0MG65/OXySzL84zZly+hisnhSyv+TYUdJcoisHJeV
	Nrv6jChkyEMBEtk5YZPBZ7ZR8i1bvWgIkclfx8ugGobe4t++R2gNTYvHRzs1epXVvkJJn6ltGTN
	2rWMEHJW/Nh9/46D+7PAs/OLT82sdHVG4uyF/4+D6OkuC
X-Google-Smtp-Source: AGHT+IEbE3jPdU8aTaDpG86S16LJMiVg4P6HEEc/DtrtGKmCbgcGMHL+lTNATodfNGmthDA3n2gheg==
X-Received: by 2002:a17:902:d4d2:b0:261:e1c0:1c44 with SMTP id d9443c01a7336-26813bf5032mr46134825ad.40.1758146170137;
        Wed, 17 Sep 2025 14:56:10 -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 15/18] xen/riscv: implement put_page()
Date: Wed, 17 Sep 2025 23:55:35 +0200
Message-ID: <269250b2b3c62f34446d9e7b9f72dbf2d4eca2e5.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement put_page(), as it will be used by  p2m_put_*-related code.

Although CONFIG_STATIC_MEMORY has not yet been introduced for RISC-V,
a stub for PGC_static is added to avoid cluttering the code of
put_page() with #ifdefs.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Update the comment message:
   s/p2m_put_code/p2m_put_*-related code.
   s/put_page_nr/put_page.
---
 xen/arch/riscv/include/asm/mm.h |  7 +++++++
 xen/arch/riscv/mm.c             | 25 ++++++++++++++++++++-----
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index dd8cdc9782..0503c92e6c 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -264,6 +264,13 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 /* Page is Xen heap? */
 #define _PGC_xen_heap     PG_shift(2)
 #define PGC_xen_heap      PG_mask(1, 2)
+#ifdef CONFIG_STATIC_MEMORY
+/* Page is static memory */
+#define _PGC_static       PG_shift(3)
+#define PGC_static        PG_mask(1, 3)
+#else
+#define PGC_static     0
+#endif
 /* Page is broken? */
 #define _PGC_broken       PG_shift(7)
 #define PGC_broken        PG_mask(1, 7)
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 1ef015f179..3cac16f1b7 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -362,11 +362,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");
@@ -627,3 +622,23 @@ void flush_page_to_ram(unsigned long mfn, bool sync_icache)
     if ( sync_icache )
         invalidate_icache();
 }
+
+void put_page(struct page_info *page)
+{
+    unsigned long nx, x, y = page->count_info;
+
+    do {
+        ASSERT((y & PGC_count_mask) >= 1);
+        x  = y;
+        nx = x - 1;
+    }
+    while ( unlikely((y = cmpxchg(&page->count_info, x, nx)) != x) );
+
+    if ( unlikely((nx & PGC_count_mask) == 0) )
+    {
+        if ( unlikely(nx & PGC_static) )
+            free_domstatic_page(page);
+        else
+            free_domheap_page(page);
+    }
+}
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 22:06:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 22:06:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125763.1467643 (Exim 4.92)
	(envelope-from )
	id 1uz0Ik-0000uB-If; Wed, 17 Sep 2025 22:06:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125763.1467643; Wed, 17 Sep 2025 22: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 1uz0Ik-0000u1-DC; Wed, 17 Sep 2025 22:06:58 +0000
Received: by outflank-mailman (input) for mailman id 1125763;
 Wed, 17 Sep 2025 22:06:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uz08M-0007Lt-39
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:14 +0000
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com
 [2607:f8b0:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1eb3aab1-9411-11f0-9809-7dc792cee155;
 Wed, 17 Sep 2025 23:56:10 +0200 (CEST)
Received: by mail-pf1-x435.google.com with SMTP id
 d2e1a72fcca58-7704f3c46ceso323471b3a.2
 for ; Wed, 17 Sep 2025 14:56:10 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 1eb3aab1-9411-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146169; x=1758750969; darn=lists.xenproject.org;
        h=content-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=KHAAkZYflTFjWq/L7+VdJfutxn9e76f5Fh7Kk/TWJlg=;
        b=TGgsuEx77p7cmZB1aWEe1PDzPji2nEFp1eVDM/qXtr+n/kjjncnMjOHZt9Cj4B2FkU
         d9i3sCjjCrSvc2ePavFHnGSr4AyDUX17tK964HIEuOxTp5r9sD9wq2Bu4vg/wie7TGDn
         0b6T4tHpQWK/np9A9/NLieTqkccoApV+WC3b5JMD72pbmjsm8WSKGiQsKZmlz66ECv5O
         MT9gk4J6gI2jZupx+88+Kdokf9VCTVVb0AUDvUvLMcMbaroCt/1s54JiLuJoDSAZ8EsY
         E8B+BxfFLish7/GhQL9WJ+Rm4M3BaCExso8Ut2WabSwfJlbW3ujbFwh/oKV5RuV/j9Kc
         UWIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146169; x=1758750969;
        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=KHAAkZYflTFjWq/L7+VdJfutxn9e76f5Fh7Kk/TWJlg=;
        b=TzE6AWDAntb+Kh8LR7eYj9SeQcgFKKjQaW2RskEGw9RTvjTRIBWHvbtz6182p5LOz0
         v1TnljuFEk3uEp8UxR1C9llAbBdUI4mJXzD4LiSmY+qDaTkwsTQTBgPhlRAYajK1UAPa
         SaD+7a+X01karuKJd/MlWre2I/lr8xxSw3SQHeVzQlSMWVgre/GY/k5P79MzVB6K/LOe
         poO+Bc1GBL0z/RRNQRj8+P2U2OtGlr3CzHqupuA1YHjpdAxhnx+WtwUHIHIk90IUYv1T
         ivvHHtrKnVsi2KqtNPSc3EM43wQt++LkMR36R9e0BxN8p9YLX5MUXYTtHCTpjCS6KVr9
         yNZQ==
X-Gm-Message-State: AOJu0Yxbtn6FfsaqsD3XlvJPfd7f0+9M1JLt21EVeKsWVldwoLDQ94FG
	6V0Ewr4GkmoH8fe9Hdf59eJvS1qqxVy2IjDZ7ys0/VsCDxX29gY9dUXDU4T8q5jzB08=
X-Gm-Gg: ASbGncsufNV2aKP5Y4VM0+JwtE+OsMrKv1J66NLV4RRmjL2BYLLpGvCk6X82DzbXDEI
	rGVGYHqSjVKhlhiktX5qCZVj7OPX0t8kfcTU6yHzyVsy3kudhMEJCOngnAKURy+px2zsMhdb3Xs
	Pfr4rpGn0RM/W8ezbOGMgNCoBApmTa/uizBHbdHxciE7R9N52n/02arw04bOXekYiHvClzNbTbo
	Dq/3E0A551LppTtDFYpeNvTmY+nc9ksF76mC7NWjM/pctmvkdUENO8silPonA0F6S3K4GIPPQYA
	0Kn09/Ssw9w6huYehDA0eHjTO8BrNQi4cwVQ51IX6vwgTST23ATcAaQiIQivoKTgSA4PujgCzh/
	lY3f5y8ciEkDfCpZhnNUMZo9rLKiL+1WvzPtVyvimUIoq
X-Google-Smtp-Source: AGHT+IFRc0lTC9CHjAt86cWRwA6G6UVKrzGQLeD8EdWUI1dDgx8UL2Vyp0U8TFn8LsBl0ymjvBZ1Jg==
X-Received: by 2002:a17:902:e745:b0:266:3098:666 with SMTP id d9443c01a7336-268137f202emr43875055ad.32.1758146168904;
        Wed, 17 Sep 2025 14:56:08 -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 14/18] xen/riscv: Implement superpage splitting for p2m mappings
Date: Wed, 17 Sep 2025 23:55:34 +0200
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
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, some parts are simplified
as according to RISC-V spec:
  It is permitted for multiple address-translation cache entries to co-exist
  for the same address. This represents the fact that in a conventional
  TLB hierarchy, it is possible for multiple entries to match a single
  address if, for example, a page is upgraded to a superpage without first
  clearing the original non-leaf PTE’s valid bit and executing an SFENCE.VMA
  with rs1=x0, or if multiple TLBs exist in parallel at a given level of the
  hierarchy. In this case, just as if an SFENCE.VMA is not executed between
  a write to the memory-management tables and subsequent implicit read of the
  same address: it is unpredictable whether the old non-leaf PTE or the new
  leaf PTE is used, but the behavior is otherwise well defined.
In contrast to the Arm architecture, where BBM is mandatory and failing to
use it in some cases can lead to CPU instability, RISC-V guarantees
stability, and the behavior remains safe — though unpredictable in terms of
which translation will be used.

Additionally, the page table walk logic has been adjusted, as ARM uses the
opposite level numbering compared to RISC-V.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - s/number of levels/level numbering in the commit message.
 - s/permissions/attributes.
 - Remove redundant comment in p2m_split_superpage() about page
   splitting.
 - Use P2M_PAGETABLE_ENTRIES as XEN_PT_ENTRIES
   doesn't takeinto  into acount that G stage root page table is
   extended by 2 bits.
 - Use earlier introduced P2M_LEVEL_ORDER().
---
Changes in V3:
 - Move     page_list_add(page, &p2m->pages) inside p2m_alloc_page().
 - Use 'unsigned long' for local vairiable 'i' in p2m_split_superpage().
 - Update the comment above if ( next_level != target ) in p2m_split_superpage().
 - Reverse cycle to iterate through page table levels in p2m_set_entry().
 - Update p2m_split_superpage() with the same changes which are done in the
   patch "P2M: Don't try to free the existing PTE if we can't allocate a new table".
---
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 | 114 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index bf4945e99f..1577b09b15 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -661,6 +661,87 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
     p2m_free_page(p2m, 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 long 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 = P2M_LEVEL_ORDER(next_level);
+
+    /*
+     * This should only be called with target != level and the entry is
+     * a superpage.
+     */
+    ASSERT(level > target);
+    ASSERT(pte_is_superpage(*entry, level));
+
+    page = p2m_alloc_page(p2m);
+    if ( !page )
+    {
+        /*
+         * The caller is in charge to free the sub-tree.
+         * As we didn't manage to allocate anything, just tell the
+         * caller there is nothing to free by invalidating the PTE.
+         */
+        memset(entry, 0, sizeof(*entry));
+        return false;
+    }
+
+    table = __map_domain_page(page);
+
+    for ( i = 0; i < P2M_PAGETABLE_ENTRIES(next_level); i++ )
+    {
+        pte_t *new_entry = table + i;
+
+        /*
+         * Use the content of the superpage entry and override
+         * the necessary fields. So the correct attributes 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
+     * for every entry to know whether the entry should be shattered.
+     */
+    if ( next_level != target )
+        rv = p2m_split_superpage(p2m, table + offsets[next_level],
+                                 level - 1, target, offsets);
+
+    if ( p2m->clean_dcache )
+        clean_dcache_va_range(table, PAGE_SIZE);
+
+    /*
+     * TODO: an inefficiency here: the caller almost certainly wants to map
+     *       the same page again, to update the one entry that caused the
+     *       request to shatter the page.
+     */
+    unmap_domain_page(table);
+
+    /*
+     * Even if we failed, we should (according to the current implemetation
+     * of a way how sub-tree is freed if p2m_split_superpage hasn't been
+     * finished fully) 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(page), p2m->clean_dcache);
+
+    return rv;
+}
+
 /*
  * Insert an entry in the p2m. This should be called with a mapping
  * equal to a page/superpage.
@@ -729,7 +810,38 @@ 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(pte_is_superpage(*entry, level));
+
+        if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets) )
+        {
+            /* Free the allocated sub-tree */
+            p2m_free_subtree(p2m, split_pte, level);
+
+            rc = -ENOMEM;
+            goto out;
+        }
+
+        p2m_write_pte(entry, split_pte, p2m->clean_dcache);
+
+        p2m->need_flush = true;
+
+        /* 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 == P2M_TABLE_NORMAL ||
+                   (rc == P2M_TABLE_SUPER_PAGE && target > 0));
+        }
+
+        entry = table + offsets[level];
     }
 
     /*
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 22:06:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 22:06:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125769.1467649 (Exim 4.92)
	(envelope-from )
	id 1uz0Ik-0000xi-Tm; Wed, 17 Sep 2025 22:06:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125769.1467649; Wed, 17 Sep 2025 22: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 1uz0Ik-0000wx-Mj; Wed, 17 Sep 2025 22:06:58 +0000
Received: by outflank-mailman (input) for mailman id 1125769;
 Wed, 17 Sep 2025 22: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 1uz08M-0007Lu-IJ
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 21:56:14 +0000
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com
 [2607:f8b0:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 202fd343-9411-11f0-9d13-b5c5bf9af7f9;
 Wed, 17 Sep 2025 23:56:13 +0200 (CEST)
Received: by mail-pl1-x62e.google.com with SMTP id
 d9443c01a7336-2570bf6058aso3814545ad.0
 for ; Wed, 17 Sep 2025 14:56:13 -0700 (PDT)
Received: from fedora ([149.199.65.200]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053da4sm5538095ad.20.2025.09.17.14.56.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 17 Sep 2025 14:56: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: 202fd343-9411-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758146171; x=1758750971; darn=lists.xenproject.org;
        h=content-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=ZWW/RPoHDDMmiNcnSl6hhO3V0ICFKFmoC7Uis76f4UI=;
        b=ABuzYF087xnXF8aZvIWexr/DQX5IOScDoJupi1bN1CQQsMRVlORkhZ+8j07nGgw7St
         t9O2aU1iv0pE/TWIxCUfKZ2r1NEioOjgbpRqHvWSZ7If/oemnnK9wRMsCwltsTKHyFA+
         0O8dN48vOQmf/d/DOwMhjXytuzkna3us94eCnGSkn21CYKYFquRzNyHDzI0s0d/7PBQD
         c5UoRS2hyIzrBQxUth32WXhpgL7pHUtH/xynr+byzqfm2H/leD7rhCoAX3x+oLbmy1+O
         tAtoXFntkbB61LKxgV3tgeHbK17pzMn3T1UFsVIogGBCgB8v76zUjvVTVAPPXNJuMTO/
         F5nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758146171; x=1758750971;
        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=ZWW/RPoHDDMmiNcnSl6hhO3V0ICFKFmoC7Uis76f4UI=;
        b=kTX8kD1lU9Ef0/C1xyrd+nclDq1NKnIwd/3SWC3iF0zFHzqVjqwX0bMvEIDjftqCz5
         nTU6pFxRY1wLfM9M8XivHWJif3EEAcZuOPKmJmf+7fUtmwQyT5mOk+ZkM+143EPjWOSM
         d+SrmxFs+QsprBL4Vzu2OmCxRrlsI3SHYeX+NkffttOp7h3ORXiUgyJtly065jodsjYf
         9FfvTK8S1sgevX2+Td029T2JBYZ9nqZhhWJKc7fXls2hyQfEWCJkhcJXXtUeti+A3KL6
         ugFC+dHMwW/P/djLFUQusbHiy0na4e72QZiDOOTxDAVWQZCGKeyJLp6i5D+O78tT7hhS
         Rf+g==
X-Gm-Message-State: AOJu0Yy62NTW19Js9w6T2/oYvofIO2pPU47DH5tSNrSnAZvU90iXDRKZ
	2FAexhKD68V+d5i42nv+J6GQsM4ROFoR68jNZONLAtuaFvEjbCKd6EjZYuEk6zLYIvA=
X-Gm-Gg: ASbGnctz8AeWI10+GvUwpstiP5U9PIDlHpKBV9fjzPzh6u/64+hTZMltQb6ycaa+rEw
	NmkavaTSrUd+sd2Ug8xKMExc2NJr6R62wfOY0tHIOfxXb4qNfE3W+r/9BAnRLOKAd18spcUfmPI
	iD9Et81C8nHBTT6zAhvEhrVJ/Ikp0TEWzkctRGX7tOUbxknlKCkLZyCZ86zgBKPbLvtieBi0SX5
	+JAMgu8EJ4fvXatO6wcSzY1GahjVdA3dRAEW/2V2nUrO+Fam/huvTkxsLSRTo3WMZ88xXLBFtRV
	/WJaMM72WrGHgZ7Q1g6TIBOQzCbYjb+jLKRSHkbi1mD96BvXMMcKo3GkLPdCvLAakw2r/LAEWZD
	aaNvI9OkOgPK5kvLGiEIF0dCdytOPsZAsx89u11sb4qqv
X-Google-Smtp-Source: AGHT+IFNulg9ua/1KcKiq1d9eq2CTw7cQ9UG4yEDrbmVuEwCKwmA/vPRU34oqpsarcTO/vxdiRpRjw==
X-Received: by 2002:a17:903:11c8:b0:25d:5b09:a201 with SMTP id d9443c01a7336-2681238073amr49800165ad.27.1758146171396;
        Wed, 17 Sep 2025 14:56:11 -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 16/18] xen/riscv: implement mfn_valid() and page reference, ownership handling helpers
Date: Wed, 17 Sep 2025 23:55:36 +0200
Message-ID: <09317ebbd1f6fb7dda9454aa7e0b1ba3cbd0726c.1758145428.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.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, initialize pdx_group_valid() by calling set_pdx_range() when
memory banks are being mapped.

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 `alloc_heap_pages':
  /build/xen/common/page_alloc.c:1054: undefined reference to `page_is_offlinable'
  riscv64-linux-gnu-ld: /build/xen/common/page_alloc.c:1035: undefined reference to `page_is_offlinable'
  riscv64-linux-gnu-ld: prelink.o: in function `reserve_offlined_page':
  /build/xen/common/page_alloc.c:1151: undefined reference to `page_is_offlinable'
  riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol `page_is_offlinable' isn't defined
  riscv64-linux-gnu-ld: final link failed: bad value
  make[2]: *** [arch/riscv/Makefile:28: 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.
- Implement page_is_offlinable() to return false for RISC-V.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Rebase the patch on top of patch series "[PATCH v2 0/2] constrain page_is_ram_type() to x86".
 - Add implementation of page_is_offlinable() instead of page_is_ram().
 - Update the commit message.
---
Changes in V3:
 - Update defintion of mfn_valid().
 - Use __ro_after_init for variable start_page.
 - Drop ASSERT_UNREACHABLE() in page_get_owner_and_nr_reference().
 - Update the comment inside do/while in page_get_owner_and_nr_reference().
 - Define _PGC_static and drop "#ifdef CONFIG_STATIC_MEMORY" in put_page_nr().
 - Initialize pdx_group_valid() by calling set_pdx_range() when memory banks are mapped.
 - Drop page_get_owner_and_nr_reference() and implement page_get_owner_and_reference()
   without reusing of a page_get_owner_and_nr_reference() to avoid potential dead code.
 - Move defintion of get_page() to "xen/riscv: add support of page lookup by GFN", where
   it is really used.
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/mm.h |  9 +++++++--
 xen/arch/riscv/mm.c             | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 0503c92e6c..1b16809749 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 
@@ -300,8 +301,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 tmp_mfn = mfn_x(mfn);                                 \
+    likely((tmp_mfn >= start_page)) && likely(__mfn_valid(tmp_mfn));    \
+})
 
 #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 3cac16f1b7..8c6e8075f3 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -521,6 +521,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 __ro_after_init start_page;
+
 /*
  * Setup memory management
  *
@@ -570,9 +572,13 @@ void __init setup_mm(void)
         ram_end = max(ram_end, bank_end);
 
         setup_directmap_mappings(PFN_DOWN(bank_start), PFN_DOWN(bank_size));
+
+        set_pdx_range(paddr_to_pfn(bank_start), paddr_to_pfn(bank_end));
     }
 
     setup_frametable_mappings(ram_start, ram_end);
+
+    start_page = PFN_DOWN(ram_start);
     max_page = PFN_DOWN(ram_end);
 }
 
@@ -642,3 +648,30 @@ void put_page(struct page_info *page)
             free_domheap_page(page);
     }
 }
+
+bool page_is_offlinable(mfn_t mfn)
+{
+    return false;
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page)
+{
+    unsigned long x, y = page->count_info;
+    struct domain *owner;
+
+    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 + 1) & PGC_count_mask) <= 1) )
+            return NULL;
+    }
+    while ( (y = cmpxchg(&page->count_info, x, x + 1)) != x );
+
+    owner = page_get_owner(page);
+    ASSERT(owner);
+
+    return owner;
+}
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 17 22:33:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Sep 2025 22:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125844.1467662 (Exim 4.92)
	(envelope-from )
	id 1uz0ht-0006av-TY; Wed, 17 Sep 2025 22:32:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125844.1467662; Wed, 17 Sep 2025 22: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 1uz0ht-0006ao-R4; Wed, 17 Sep 2025 22:32:57 +0000
Received: by outflank-mailman (input) for mailman id 1125844;
 Wed, 17 Sep 2025 22:32: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 1uz0hs-0006ai-VB
 for xen-devel@lists.xenproject.org; Wed, 17 Sep 2025 22:32:57 +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 40efcef3-9416-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 00:32:55 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-45decc9e83eso2923565e9.3
 for ; Wed, 17 Sep 2025 15:32:55 -0700 (PDT)
Received: from [10.10.152.155] ([149.199.65.200])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-330654bf948sm152653a91.0.2025.09.17.15.32.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 17 Sep 2025 15:32: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: 40efcef3-9416-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758148374; x=1758753174; 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=Xv9UNWdjEKb2GbD8pgOSbR6qFEwUYZTltwPh071cC68=;
        b=b9N+Xg+5K2Lp7Zs0TAqedhjU0BpqMFQZWxYqi2nqeSjpNhyv1ozvq2sbc7b8+cXmPg
         DCSu2NQ7X7Ufr/pSHY5LTkOnw6iDUqLB2dUlicSEXH/hWJuDT1vV1Tc3wY1PhxnQo9Zr
         AZyzK28wXa1tQgtwrIPuJwsloQIoWCT782Sw2D5sJURDUQahmBR5gQ8Mce/j+jp/2OzO
         krG6AelPcC8ebeDCx7Vpg6QMLiZI1k/dqPugDUvWEFUUu1SgD5u69M0jdcvVkiumFSeV
         eW4cpsT6Ej89yCXJvcT+ESkzk0msYJZgaZsT47pNRRdSKMsrLuiuM+KtKv7EN7FyG3/i
         RfiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758148374; x=1758753174;
        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=Xv9UNWdjEKb2GbD8pgOSbR6qFEwUYZTltwPh071cC68=;
        b=bC/PVYJtiCjyYttUX0EoQmYJ9Ux4WGYXC9bESE6/cczWm78RjI8gr2jssfXTAi6Yrx
         /Moz6SZbb7K/Cn2rHdw9Q2IoiZPBduhrMIFaRhZuF8kiINTQyDbrIzLd3d5p2fUt9LWd
         0xnHOK822h3aN61Cr1X+sYvSmBwqOE/Y8kG7VIfIOb1gXRXxDjUS0rrqi/x6vWpluUQz
         V59W9lVPcKBj+D4CQdgYHern04l0KFtCBAR27oiEdAaxmWAV1C4r3+NwTuJPhIdVb508
         qFnBk7shdr/017sRilZxfh0mEmcWUWRKVTgWgW66f3wprAIXIINt5KZ2e3NfFTkl6o3n
         1d3Q==
X-Forwarded-Encrypted: i=1; AJvYcCWUC5t2xL1JaVf30KCgdg92Ur8MQBPDzjoi8vz2Ilyo4DNJUVLiK3apCK6MFzAukb6D89X2hy4maoA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YywyK00P5cUE/ryXvpWQ//BhXC/YApL91sZvl5jf4iKK4womaX0
	cxb5fiw3MtnQPEZeysAlinDfAyE9CuPYiY95Rx0QVPkG5KQJqUIygOw6SMNVxCB67Q==
X-Gm-Gg: ASbGncs+KBkwDPaNsOIW4vixAidzAVUi4jeGyBO1sjjGD/b51jro1NiC03dfb6PNmrH
	MXNX7owOE2E3UevDVoUKsK04iijyVEGykp7d2Eb0kP7XOMXyASEWyyrQVNGyqYOtjVNO6BGBoYa
	OR/Hu1QoYLloTftHmInJqwt92zGW679yDQ9GXpWcCHaGms54jJQinQks3bJcfPeq4YvWsRtDAIh
	/X6YXbjVo4VSZGLxZiVFMxmYuhzjOsMv8nigJkBgFOOrNdEduIaHJG2dG4n6kHs291/zVm7QOna
	NgwH70+ml0ib/vwjpnkWJ9dKGSFhjg61iZ7WMQFUvz4vdcEdiJOeY2r6D819iA2kGTjFyO5PH/i
	Ux/UcySr4k8Y9jCm3PuJ0RjD+FQca/lLYtzuPYQjBgXLjeSpG2a/4
X-Google-Smtp-Source: AGHT+IGXC2D7CFFsIFWdM9Glpt++oKHeAvZAWq08Absw9NixPiV+85/2P0qLG2UDc4moJ7VEFuTsmQ==
X-Received: by 2002:a5d:5888:0:b0:3ec:a76e:95d6 with SMTP id ffacd0b85a97d-3ecdfa3f97cmr3681386f8f.55.1758148374344;
        Wed, 17 Sep 2025 15:32:54 -0700 (PDT)
Message-ID: 
Date: Thu, 18 Sep 2025 00:32:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC XEN PATCH] build: Require explicit .config update
To: Anthony PERARD 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250917214519.64323-2-anthony@xenproject.org>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250917214519.64323-2-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:45, Anthony PERARD wrote:
> From: Anthony PERARD 
> 
> It is sometime unwelcome for the config of the hypervisor to change.
> 
> Make output will be something like that:
>   tools/kconfig/conf  --syncconfig Kconfig
> 
>   *** The configuration requires explicit update.
> 
>   make[2]: *** [/xen.git/xen/tools/kconfig/Makefile:73: syncconfig] Error 1
>     GEN     Makefile
>   /xen.git/xen/Rules.mk:19: include/config/auto.conf: No such file or directory
>   make[2]: *** No rule to make target 'include/config/auto.conf'.  Stop.
>   make[1]: *** [/xen.git/xen/Makefile:620: xen] Error 2
>   make: *** [/xen.git/xen/Makefile:179: __sub-make] Error 2
> 
> This also prevent update when the toolchain change and change CONFIG_*
> values like CONFIG_GCC_VERSION.
> 
> Proposed-by: during design session
> Signed-off-by: Anthony PERARD 
> ---
> 
> During the design session, the proposal was to compare .config before
> and after syncconfig. But maybe KCONFIG_NOSILENTUPDATE is enough?

Didn't know something like this existed. It's sufficient imo, just that
we don't want to apply this mode unconditionally.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 02:46:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 02:46:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125880.1467673 (Exim 4.92)
	(envelope-from )
	id 1uz4ep-0001y4-Dt; Thu, 18 Sep 2025 02:46:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125880.1467673; Thu, 18 Sep 2025 02: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 1uz4ep-0001xl-8V; Thu, 18 Sep 2025 02:46:03 +0000
Received: by outflank-mailman (input) for mailman id 1125880;
 Thu, 18 Sep 2025 02: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 1uz4eo-0001xZ-CJ
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 02:46:02 +0000
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9a0ad899-9439-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 04:45:58 +0200 (CEST)
Received: from fmviesa007.fm.intel.com ([10.60.135.147])
 by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Sep 2025 19:45:56 -0700
Received: from lkp-server01.sh.intel.com (HELO 84a20bd60769) ([10.239.97.150])
 by fmviesa007.fm.intel.com with ESMTP; 17 Sep 2025 19:45:50 -0700
Received: from kbuild by 84a20bd60769 with local (Exim 4.96)
 (envelope-from ) id 1uz4ea-0002f9-0T;
 Thu, 18 Sep 2025 02:45: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: 9a0ad899-9439-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1758163559; x=1789699559;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=MGtmbYJr4izzxh9Q5fjjfxZ6vSiqc+Pmx0sDfZpsERU=;
  b=OoWePRmyBgaZU5T9GUvdj9DAvHE+ukWnmFsiMlLbu1AoudYTvfE1/xO6
   OWSgBsifuDMoi6il4eZik3W/tBnrkNwknyDU7MIOahCtFKevz6qpTZNkF
   27d8oWgi4yWVb3lqKfCfKv7RFVSqX8eCNF1MJ530nkAVWoWPA6SCsEOEP
   QzjMkG3vb/VuglicluKQPI0TWGUiGYYgJTYyNHMcwegDKHDjtWqXPEDVd
   BRKCv86qgftpQhd5Ke68e1k044MDNowZA6Jq2ZBcllFlpSOWkjZEXyHnU
   qwpMKvVObJ7aCmdCg4RDZE1B6QzzolKKBDvzVkPq4CFVNFEQAWj87AtkT
   w==;
X-CSE-ConnectionGUID: QnWNU6hSStG3VgKUza8P/A==
X-CSE-MsgGUID: DDyWc5KJTGGhzCkrTH9qjQ==
X-IronPort-AV: E=McAfee;i="6800,10657,11556"; a="71908145"
X-IronPort-AV: E=Sophos;i="6.18,273,1751266800"; 
   d="scan'208";a="71908145"
X-CSE-ConnectionGUID: BKE0jq5BSkG7P9Qe24Ll7w==
X-CSE-MsgGUID: 9xb6ixm/TWyg48SGy4T1TA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,273,1751266800"; 
   d="scan'208";a="175012948"
Date: Thu, 18 Sep 2025 10:45:17 +0800
From: kernel test robot 
To: Juergen Gross , linux-kernel@vger.kernel.org,
	x86@kernel.org, linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev, kvm@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	Juergen Gross ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu , Dexuan Cui ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	Josh Poimboeuf ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions
 into own header
Message-ID: <202509181008.MoLd2u4e-lkp@intel.com>
References: <20250917145220.31064-22-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250917145220.31064-22-jgross@suse.com>

Hi Juergen,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tip/sched/core]
[also build test WARNING on kvm/queue kvm/next linus/master v6.17-rc6 next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Juergen-Gross/x86-paravirt-Remove-not-needed-includes-of-paravirt-h/20250917-230321
base:   tip/sched/core
patch link:    https://lore.kernel.org/r/20250917145220.31064-22-jgross%40suse.com
patch subject: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions into own header
config: x86_64-randconfig-003-20250918 (https://download.01.org/0day-ci/archive/20250918/202509181008.MoLd2u4e-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250918/202509181008.MoLd2u4e-lkp@intel.com/reproduce)

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 
| Closes: https://lore.kernel.org/oe-kbuild-all/202509181008.MoLd2u4e-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> arch/x86/kernel/paravirt-spinlocks.c:13:13: warning: no previous prototype for function 'native_pv_lock_init' [-Wmissing-prototypes]
      13 | void __init native_pv_lock_init(void)
         |             ^
   arch/x86/kernel/paravirt-spinlocks.c:13:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
      13 | void __init native_pv_lock_init(void)
         | ^
         | static 
   1 warning generated.


vim +/native_pv_lock_init +13 arch/x86/kernel/paravirt-spinlocks.c

    12	
  > 13	void __init native_pv_lock_init(void)
    14	{
    15		if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
    16			static_branch_enable(&virt_spin_lock_key);
    17	}
    18	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 03:19:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 03:19:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125892.1467682 (Exim 4.92)
	(envelope-from )
	id 1uz5Aq-0005y0-OL; Thu, 18 Sep 2025 03:19:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125892.1467682; Thu, 18 Sep 2025 03: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 1uz5Aq-0005xt-LH; Thu, 18 Sep 2025 03:19:08 +0000
Received: by outflank-mailman (input) for mailman id 1125892;
 Thu, 18 Sep 2025 03: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 1uz5Ap-0005xn-13
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 03:19:07 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 390f3188-943e-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 05:19:03 +0200 (CEST)
Received: from orviesa004.jf.intel.com ([10.64.159.144])
 by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Sep 2025 20:19:00 -0700
Received: from lkp-server01.sh.intel.com (HELO 84a20bd60769) ([10.239.97.150])
 by orviesa004.jf.intel.com with ESMTP; 17 Sep 2025 20:18:55 -0700
Received: from kbuild by 84a20bd60769 with local (Exim 4.96)
 (envelope-from ) id 1uz5Aa-0002hN-0w;
 Thu, 18 Sep 2025 03:18: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: 390f3188-943e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1758165544; x=1789701544;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=BXxqhBJxXxvdickLzCyDX1rwS2LGPscfHrBsIJKBFHg=;
  b=gv5YNZZJ94ZK7jtClABAwIWpxIbJHWypQxQDOgINpcE4clvvtm8sc5KO
   hzOeBFxby8NXt7DuMvzbUCdDixj4+NHoD8tmRQrb3pTBReY5KbB126j67
   CInB7F4R0C9Wj7j6iPuIkXRtIsKrXph1pWZBr1u9n89iyCbfOpOIgzrZ4
   c0KdcJYsSkCSUIJ3g5eSj6c7915nNVuAEENVEg4qFLXAHOGx7zrkcVaRc
   8xW6/i+RIFp4DIiGmJmvG4PHHuQ9du9dByugHDQj4U476MoTAnMTdGvuB
   toSGy+qCEKJ80ATzfHxU3SSC71tIuU0Iwt3uxb8lrgh1F1qfcfws8RByD
   w==;
X-CSE-ConnectionGUID: NkGumBFJQFCTuNRdv+4Avg==
X-CSE-MsgGUID: qSnuh0ouQnubUxyJnz9wrQ==
X-IronPort-AV: E=McAfee;i="6800,10657,11556"; a="85925407"
X-IronPort-AV: E=Sophos;i="6.18,273,1751266800"; 
   d="scan'208";a="85925407"
X-CSE-ConnectionGUID: lnvzHdwpST6cNElr5TApng==
X-CSE-MsgGUID: LA6PePTrQ6WURP8TceJ/ag==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,273,1751266800"; 
   d="scan'208";a="179702293"
Date: Thu, 18 Sep 2025 11:18:00 +0800
From: kernel test robot 
To: Juergen Gross , linux-kernel@vger.kernel.org,
	x86@kernel.org, linux-hyperv@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	Juergen Gross , Andy Lutomirski ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu , Dexuan Cui ,
	Peter Zijlstra ,
	Will Deacon , Boqun Feng ,
	Waiman Long , Jiri Kosina ,
	Josh Poimboeuf ,
	Pawan Gupta ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/21] x86/paravirt: Remove not needed includes of
 paravirt.h
Message-ID: <202509181151.ja2As5H4-lkp@intel.com>
References: <20250917145220.31064-2-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250917145220.31064-2-jgross@suse.com>

Hi Juergen,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/sched/core]
[also build test ERROR on kvm/queue kvm/next linus/master v6.17-rc6 next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Juergen-Gross/x86-paravirt-Remove-not-needed-includes-of-paravirt-h/20250917-230321
base:   tip/sched/core
patch link:    https://lore.kernel.org/r/20250917145220.31064-2-jgross%40suse.com
patch subject: [PATCH v2 01/21] x86/paravirt: Remove not needed includes of paravirt.h
config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20250918/202509181151.ja2As5H4-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250918/202509181151.ja2As5H4-lkp@intel.com/reproduce)

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 
| Closes: https://lore.kernel.org/oe-kbuild-all/202509181151.ja2As5H4-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from kernel/cpu.c:13:
   In file included from include/linux/sched/isolation.h:5:
   In file included from include/linux/cpuset.h:18:
   In file included from include/linux/mmu_context.h:5:
>> arch/x86/include/asm/mmu_context.h:225:2: error: call to undeclared function 'paravirt_enter_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     225 |         paravirt_enter_mmap(mm);
         |         ^
>> arch/x86/include/asm/mmu_context.h:232:2: error: call to undeclared function 'paravirt_arch_exit_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     232 |         paravirt_arch_exit_mmap(mm);
         |         ^
   arch/x86/include/asm/mmu_context.h:232:2: note: did you mean 'ldt_arch_exit_mmap'?
   arch/x86/include/asm/mmu_context.h:61:6: note: 'ldt_arch_exit_mmap' declared here
      61 | void ldt_arch_exit_mmap(struct mm_struct *mm);
         |      ^
   In file included from kernel/cpu.c:42:
   In file included from include/trace/events/power.h:12:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:53:
   In file included from include/linux/security.h:35:
   In file included from include/linux/bpf.h:33:
   In file included from arch/x86/include/asm/rqspinlock.h:5:
   arch/x86/include/asm/paravirt.h:736:20: error: static declaration of 'paravirt_enter_mmap' follows non-static declaration
     736 | static inline void paravirt_enter_mmap(struct mm_struct *mm)
         |                    ^
   arch/x86/include/asm/mmu_context.h:225:2: note: previous implicit declaration is here
     225 |         paravirt_enter_mmap(mm);
         |         ^
   In file included from kernel/cpu.c:42:
   In file included from include/trace/events/power.h:12:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:53:
   In file included from include/linux/security.h:35:
   In file included from include/linux/bpf.h:33:
   In file included from arch/x86/include/asm/rqspinlock.h:5:
   arch/x86/include/asm/paravirt.h:742:20: error: static declaration of 'paravirt_arch_exit_mmap' follows non-static declaration
     742 | static inline void paravirt_arch_exit_mmap(struct mm_struct *mm)
         |                    ^
   arch/x86/include/asm/mmu_context.h:232:2: note: previous implicit declaration is here
     232 |         paravirt_arch_exit_mmap(mm);
         |         ^
   4 errors generated.
--
   In file included from kernel/workqueue.c:52:
   In file included from include/linux/sched/isolation.h:5:
   In file included from include/linux/cpuset.h:18:
   In file included from include/linux/mmu_context.h:5:
>> arch/x86/include/asm/mmu_context.h:225:2: error: call to undeclared function 'paravirt_enter_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     225 |         paravirt_enter_mmap(mm);
         |         ^
>> arch/x86/include/asm/mmu_context.h:232:2: error: call to undeclared function 'paravirt_arch_exit_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     232 |         paravirt_arch_exit_mmap(mm);
         |         ^
   arch/x86/include/asm/mmu_context.h:232:2: note: did you mean 'ldt_arch_exit_mmap'?
   arch/x86/include/asm/mmu_context.h:61:6: note: 'ldt_arch_exit_mmap' declared here
      61 | void ldt_arch_exit_mmap(struct mm_struct *mm);
         |      ^
   2 errors generated.
--
>> arch/x86/kernel/x86_init.c:90:15: error: use of undeclared identifier 'default_banner'
      90 |                 .banner                 = default_banner,
         |                                           ^
   1 error generated.
--
   In file included from arch/x86/mm/init.c:30:
>> arch/x86/include/asm/mmu_context.h:225:2: error: call to undeclared function 'paravirt_enter_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     225 |         paravirt_enter_mmap(mm);
         |         ^
>> arch/x86/include/asm/mmu_context.h:232:2: error: call to undeclared function 'paravirt_arch_exit_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     232 |         paravirt_arch_exit_mmap(mm);
         |         ^
   arch/x86/include/asm/mmu_context.h:232:2: note: did you mean 'ldt_arch_exit_mmap'?
   arch/x86/include/asm/mmu_context.h:61:6: note: 'ldt_arch_exit_mmap' declared here
      61 | void ldt_arch_exit_mmap(struct mm_struct *mm);
         |      ^
>> arch/x86/mm/init.c:827:2: error: call to undeclared function 'paravirt_enter_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     827 |         paravirt_enter_mmap(text_poke_mm);
         |         ^
   3 errors generated.


vim +/paravirt_enter_mmap +225 arch/x86/include/asm/mmu_context.h

a31e184e4f6996 Dave Hansen        2019-01-02  221  
c10e83f598d080 Thomas Gleixner    2017-12-14  222  static inline int arch_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
a1ea1c032b8f8c Dave Hansen        2014-11-18  223  {
a31e184e4f6996 Dave Hansen        2019-01-02  224  	arch_dup_pkeys(oldmm, mm);
c9ae1b10d95610 Juergen Gross      2023-02-07 @225  	paravirt_enter_mmap(mm);
82721d8b25d76c Kirill A. Shutemov 2023-03-12  226  	dup_lam(oldmm, mm);
a4828f81037f49 Thomas Gleixner    2017-12-14  227  	return ldt_dup_context(oldmm, mm);
a1ea1c032b8f8c Dave Hansen        2014-11-18  228  }
a1ea1c032b8f8c Dave Hansen        2014-11-18  229  
a1ea1c032b8f8c Dave Hansen        2014-11-18  230  static inline void arch_exit_mmap(struct mm_struct *mm)
a1ea1c032b8f8c Dave Hansen        2014-11-18  231  {
a1ea1c032b8f8c Dave Hansen        2014-11-18 @232  	paravirt_arch_exit_mmap(mm);
f55f0501cbf65e Andy Lutomirski    2017-12-12  233  	ldt_arch_exit_mmap(mm);
a1ea1c032b8f8c Dave Hansen        2014-11-18  234  }
a1ea1c032b8f8c Dave Hansen        2014-11-18  235  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 05:39:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 05:39:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125923.1467693 (Exim 4.92)
	(envelope-from )
	id 1uz7MX-0005ej-9f; Thu, 18 Sep 2025 05:39:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125923.1467693; Thu, 18 Sep 2025 05:39: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 1uz7MX-0005ec-7B; Thu, 18 Sep 2025 05:39:21 +0000
Received: by outflank-mailman (input) for mailman id 1125923;
 Thu, 18 Sep 2025 05:39: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 1uz7MV-0005eW-B2
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 05:39:19 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cf7a0b8a-9451-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 07:39:16 +0200 (CEST)
Received: from fmviesa010.fm.intel.com ([10.60.135.150])
 by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Sep 2025 22:39:13 -0700
Received: from lkp-server01.sh.intel.com (HELO 84a20bd60769) ([10.239.97.150])
 by fmviesa010.fm.intel.com with ESMTP; 17 Sep 2025 22:39:07 -0700
Received: from kbuild by 84a20bd60769 with local (Exim 4.96)
 (envelope-from ) id 1uz7MH-0002nP-0J;
 Thu, 18 Sep 2025 05:39: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: cf7a0b8a-9451-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1758173956; x=1789709956;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=y+jC5ADb61yhBWtArYZLqp9di3X9xAiUey258IJUPcs=;
  b=FkQuVnSYcpuZuW2WBlhX/Cr2rtvzopaiwW9sDplvcrUgEje6gDSHhar+
   6FEPqbCjtxHo0/5914DbKpxvTazqPvrQ8xYWFS93pgPKRkSGMgMhfr/7m
   09gt8xkU7a4tc0iegt2NyGZSxVkX6WtEc8VSD1QaOi04E3/fwwvX6e1Bj
   7r2Jq7pADTz85ruTEqOb7/jPXi3yMt+BS7n0qS9SAGZ2JlWUoB9An336K
   vDKQotSlKUe3+9lhI9F3p6zTKhYBiyrx0e3JfyU9pkrXx1JfjjVKG9WqN
   Uc0sFNgCHv6YNVNnaAAqz/Ykp1uNkcxzvOyl+aljmryaiDnOA76HkyCJR
   A==;
X-CSE-ConnectionGUID: SdiLoVRFSbSR4oSyOQfxLw==
X-CSE-MsgGUID: 4tOxUa3ES7KmH21/7xbMfA==
X-IronPort-AV: E=McAfee;i="6800,10657,11556"; a="60604380"
X-IronPort-AV: E=Sophos;i="6.18,274,1751266800"; 
   d="scan'208";a="60604380"
X-CSE-ConnectionGUID: Ufc8YFrWTvOutN5VHn7ZoQ==
X-CSE-MsgGUID: d+DbLpL5RNivQdPIyzn/tQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,274,1751266800"; 
   d="scan'208";a="176233971"
Date: Thu, 18 Sep 2025 13:38:27 +0800
From: kernel test robot 
To: Juergen Gross , linux-kernel@vger.kernel.org,
	x86@kernel.org, linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev, kvm@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	Juergen Gross ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu , Dexuan Cui ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	Josh Poimboeuf ,
	Peter Zijlstra ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions
 into own header
Message-ID: <202509181317.YubLCpdh-lkp@intel.com>
References: <20250917145220.31064-22-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250917145220.31064-22-jgross@suse.com>

Hi Juergen,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/sched/core]
[also build test ERROR on kvm/queue kvm/next linus/master v6.17-rc6 next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Juergen-Gross/x86-paravirt-Remove-not-needed-includes-of-paravirt-h/20250917-230321
base:   tip/sched/core
patch link:    https://lore.kernel.org/r/20250917145220.31064-22-jgross%40suse.com
patch subject: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions into own header
config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20250918/202509181317.YubLCpdh-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250918/202509181317.YubLCpdh-lkp@intel.com/reproduce)

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 
| Closes: https://lore.kernel.org/oe-kbuild-all/202509181317.YubLCpdh-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/alternative.c:4:
   In file included from include/linux/mmu_context.h:5:
   arch/x86/include/asm/mmu_context.h:225:2: error: call to undeclared function 'paravirt_enter_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     225 |         paravirt_enter_mmap(mm);
         |         ^
   arch/x86/include/asm/mmu_context.h:232:2: error: call to undeclared function 'paravirt_arch_exit_mmap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     232 |         paravirt_arch_exit_mmap(mm);
         |         ^
   arch/x86/include/asm/mmu_context.h:232:2: note: did you mean 'ldt_arch_exit_mmap'?
   arch/x86/include/asm/mmu_context.h:61:6: note: 'ldt_arch_exit_mmap' declared here
      61 | void ldt_arch_exit_mmap(struct mm_struct *mm);
         |      ^
   In file included from arch/x86/kernel/alternative.c:5:
   In file included from include/linux/perf_event.h:53:
   In file included from include/linux/security.h:35:
   In file included from include/linux/bpf.h:33:
   In file included from arch/x86/include/asm/rqspinlock.h:5:
   arch/x86/include/asm/paravirt.h:570:20: error: static declaration of 'paravirt_enter_mmap' follows non-static declaration
     570 | static inline void paravirt_enter_mmap(struct mm_struct *mm)
         |                    ^
   arch/x86/include/asm/mmu_context.h:225:2: note: previous implicit declaration is here
     225 |         paravirt_enter_mmap(mm);
         |         ^
   In file included from arch/x86/kernel/alternative.c:5:
   In file included from include/linux/perf_event.h:53:
   In file included from include/linux/security.h:35:
   In file included from include/linux/bpf.h:33:
   In file included from arch/x86/include/asm/rqspinlock.h:5:
   arch/x86/include/asm/paravirt.h:576:20: error: static declaration of 'paravirt_arch_exit_mmap' follows non-static declaration
     576 | static inline void paravirt_arch_exit_mmap(struct mm_struct *mm)
         |                    ^
   arch/x86/include/asm/mmu_context.h:232:2: note: previous implicit declaration is here
     232 |         paravirt_arch_exit_mmap(mm);
         |         ^
>> arch/x86/kernel/alternative.c:2317:2: error: call to undeclared function 'paravirt_set_cap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2317 |         paravirt_set_cap();
         |         ^
   arch/x86/kernel/alternative.c:2317:2: note: did you mean 'paravirt_ret0'?
   arch/x86/include/asm/paravirt-base.h:23:15: note: 'paravirt_ret0' declared here
      23 | unsigned long paravirt_ret0(void);
         |               ^
   5 errors generated.


vim +/paravirt_set_cap +2317 arch/x86/kernel/alternative.c

270a69c4485d7d arch/x86/kernel/alternative.c  Peter Zijlstra            2023-02-08  2288  
9a0b5817ad97bb arch/i386/kernel/alternative.c Gerd Hoffmann             2006-03-23  2289  void __init alternative_instructions(void)
9a0b5817ad97bb arch/i386/kernel/alternative.c Gerd Hoffmann             2006-03-23  2290  {
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2291  	u64 ibt;
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2292  
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2293  	int3_selftest();
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2294  
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2295  	/*
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2296  	 * The patching is not fully atomic, so try to avoid local
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2297  	 * interruptions that might execute the to be patched code.
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2298  	 * Other CPUs are not running.
7457c0da024b18 arch/x86/kernel/alternative.c  Peter Zijlstra            2019-05-03  2299  	 */
8f4e956b313dcc arch/i386/kernel/alternative.c Andi Kleen                2007-07-22  2300  	stop_nmi();
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2301  
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2302  	/*
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2303  	 * Don't stop machine check exceptions while patching.
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2304  	 * MCEs only happen when something got corrupted and in this
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2305  	 * case we must do something about the corruption.
32b1cbe380417f arch/x86/kernel/alternative.c  Marco Ammon               2019-09-02  2306  	 * Ignoring it is worse than an unlikely patching race.
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2307  	 * Also machine checks tend to be broadcast and if one CPU
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2308  	 * goes into machine check the others follow quickly, so we don't
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2309  	 * expect a machine check to cause undue problems during to code
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2310  	 * patching.
123aa76ec0cab5 arch/x86/kernel/alternative.c  Andi Kleen                2009-02-12  2311  	 */
8f4e956b313dcc arch/i386/kernel/alternative.c Andi Kleen                2007-07-22  2312  
4e6292114c7412 arch/x86/kernel/alternative.c  Juergen Gross             2021-03-11  2313  	/*
f7af6977621a41 arch/x86/kernel/alternative.c  Juergen Gross             2023-12-10  2314  	 * Make sure to set (artificial) features depending on used paravirt
f7af6977621a41 arch/x86/kernel/alternative.c  Juergen Gross             2023-12-10  2315  	 * functions which can later influence alternative patching.
4e6292114c7412 arch/x86/kernel/alternative.c  Juergen Gross             2021-03-11  2316  	 */
4e6292114c7412 arch/x86/kernel/alternative.c  Juergen Gross             2021-03-11 @2317  	paravirt_set_cap();
4e6292114c7412 arch/x86/kernel/alternative.c  Juergen Gross             2021-03-11  2318  
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2319  	/* Keep CET-IBT disabled until caller/callee are patched */
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2320  	ibt = ibt_save(/*disable*/ true);
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2321  
931ab63664f02b arch/x86/kernel/alternative.c  Peter Zijlstra            2022-10-27  2322  	__apply_fineibt(__retpoline_sites, __retpoline_sites_end,
1d7e707af44613 arch/x86/kernel/alternative.c  Mike Rapoport (Microsoft  2025-01-26  2323) 			__cfi_sites, __cfi_sites_end, true);
931ab63664f02b arch/x86/kernel/alternative.c  Peter Zijlstra            2022-10-27  2324  
7508500900814d arch/x86/kernel/alternative.c  Peter Zijlstra            2021-10-26  2325  	/*
7508500900814d arch/x86/kernel/alternative.c  Peter Zijlstra            2021-10-26  2326  	 * Rewrite the retpolines, must be done before alternatives since
7508500900814d arch/x86/kernel/alternative.c  Peter Zijlstra            2021-10-26  2327  	 * those can rewrite the retpoline thunks.
7508500900814d arch/x86/kernel/alternative.c  Peter Zijlstra            2021-10-26  2328  	 */
1d7e707af44613 arch/x86/kernel/alternative.c  Mike Rapoport (Microsoft  2025-01-26  2329) 	apply_retpolines(__retpoline_sites, __retpoline_sites_end);
1d7e707af44613 arch/x86/kernel/alternative.c  Mike Rapoport (Microsoft  2025-01-26  2330) 	apply_returns(__return_sites, __return_sites_end);
7508500900814d arch/x86/kernel/alternative.c  Peter Zijlstra            2021-10-26  2331  
a82b26451de126 arch/x86/kernel/alternative.c  Peter Zijlstra (Intel     2025-06-03  2332) 	its_fini_core();
a82b26451de126 arch/x86/kernel/alternative.c  Peter Zijlstra (Intel     2025-06-03  2333) 
e81dc127ef6988 arch/x86/kernel/alternative.c  Thomas Gleixner           2022-09-15  2334  	/*
ab9fea59487d8b arch/x86/kernel/alternative.c  Peter Zijlstra            2025-02-07  2335  	 * Adjust all CALL instructions to point to func()-10, including
ab9fea59487d8b arch/x86/kernel/alternative.c  Peter Zijlstra            2025-02-07  2336  	 * those in .altinstr_replacement.
e81dc127ef6988 arch/x86/kernel/alternative.c  Thomas Gleixner           2022-09-15  2337  	 */
e81dc127ef6988 arch/x86/kernel/alternative.c  Thomas Gleixner           2022-09-15  2338  	callthunks_patch_builtin_calls();
e81dc127ef6988 arch/x86/kernel/alternative.c  Thomas Gleixner           2022-09-15  2339  
ab9fea59487d8b arch/x86/kernel/alternative.c  Peter Zijlstra            2025-02-07  2340  	apply_alternatives(__alt_instructions, __alt_instructions_end);
ab9fea59487d8b arch/x86/kernel/alternative.c  Peter Zijlstra            2025-02-07  2341  
be0fffa5ca894a arch/x86/kernel/alternative.c  Peter Zijlstra            2023-06-22  2342  	/*
be0fffa5ca894a arch/x86/kernel/alternative.c  Peter Zijlstra            2023-06-22  2343  	 * Seal all functions that do not have their address taken.
be0fffa5ca894a arch/x86/kernel/alternative.c  Peter Zijlstra            2023-06-22  2344  	 */
1d7e707af44613 arch/x86/kernel/alternative.c  Mike Rapoport (Microsoft  2025-01-26  2345) 	apply_seal_endbr(__ibt_endbr_seal, __ibt_endbr_seal_end);
ed53a0d971926e arch/x86/kernel/alternative.c  Peter Zijlstra            2022-03-08  2346  
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2347  	ibt_restore(ibt);
ebebe30794d38c arch/x86/kernel/alternative.c  Pawan Gupta               2025-05-03  2348  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 05:56:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 05:56:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125940.1467702 (Exim 4.92)
	(envelope-from )
	id 1uz7dF-0008QC-OP; Thu, 18 Sep 2025 05:56:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125940.1467702; Thu, 18 Sep 2025 05: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 1uz7dF-0008Q5-Lq; Thu, 18 Sep 2025 05:56:37 +0000
Received: by outflank-mailman (input) for mailman id 1125940;
 Thu, 18 Sep 2025 05:56: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 1uz7dE-0008Pz-3t
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 05:56:36 +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 3b05824a-9454-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 07:56:33 +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 2908333791;
 Thu, 18 Sep 2025 05:56: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 3340013A51;
 Thu, 18 Sep 2025 05:56:31 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id pxnVCg+fy2ivEgAAD6G6ig
 (envelope-from ); Thu, 18 Sep 2025 05:56: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: 3b05824a-9454-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758174993; 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=lfjlZ5yEEW0FqZlSU5dEgD0szSxc6bYm56+XzUkjJTA=;
	b=AtMbUHaCjW8kIerM63RfMvkErkluHt/SoYLmUs6qb9k4NU1QSr5uWo9CkXYlH+YTU43Den
	2SWsUXvP/0Vt9uoqik9/L0vC3M6Z9G9AJAnbUrv7UO0QhwoTA03342SQ0Z9wQdLq4P6Gn+
	mimKXiWJmNXOH90iYfHk//qyq0p1d7E=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758174992; 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=lfjlZ5yEEW0FqZlSU5dEgD0szSxc6bYm56+XzUkjJTA=;
	b=R4leFrKiL6F0zpBOylDqOymlaGvFjHox96zXAMsfFKHxD7x/Vo3F/XX22z8mE/rPgM16Uv
	3WtffFPPrzbns2Sv1emStnm5M6qP0x6+Gq+iS6MPYF54AFpaC+6zybzxbhjlNHWXv2w5we
	Q8PLRwdm5uiZnu+zJ7NwCq14UO3rf0k=
Message-ID: <078d5556-c5a9-40f5-906d-f96253a22739@suse.com>
Date: Thu, 18 Sep 2025 07:56:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions
 into own header
To: kernel test robot , linux-kernel@vger.kernel.org,
 x86@kernel.org, linux-hyperv@vger.kernel.org,
 virtualization@lists.linux.dev, kvm@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
 "K. Y. Srinivasan" ,
 Haiyang Zhang , Wei Liu ,
 Dexuan Cui , Thomas Gleixner ,
 Ingo Molnar , Borislav Petkov ,
 Dave Hansen , "H. Peter Anvin" ,
 Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Paolo Bonzini
 , Vitaly Kuznetsov ,
 Boris Ostrovsky ,
 Josh Poimboeuf , xen-devel@lists.xenproject.org
References: <20250917145220.31064-22-jgross@suse.com>
 <202509181008.MoLd2u4e-lkp@intel.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: <202509181008.MoLd2u4e-lkp@intel.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------d9VnNNakkD8gVqBNvxOXiPAE"
X-Spamd-Result: default: False [-5.20 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.993];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[25];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	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)[01.org:url,imap1.dmz-prg2.suse.org:helo,suse.com:mid,intel.com:email,git-scm.com:url];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -5.20

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------d9VnNNakkD8gVqBNvxOXiPAE
Content-Type: multipart/mixed; boundary="------------Csi8XDs0o0YVMq0XLmHh6km5";
 protected-headers="v1"
From: Juergen Gross 
To: kernel test robot , linux-kernel@vger.kernel.org,
 x86@kernel.org, linux-hyperv@vger.kernel.org,
 virtualization@lists.linux.dev, kvm@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
 "K. Y. Srinivasan" ,
 Haiyang Zhang , Wei Liu ,
 Dexuan Cui , Thomas Gleixner ,
 Ingo Molnar , Borislav Petkov ,
 Dave Hansen , "H. Peter Anvin" ,
 Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Paolo Bonzini
 , Vitaly Kuznetsov ,
 Boris Ostrovsky ,
 Josh Poimboeuf , xen-devel@lists.xenproject.org
Message-ID: <078d5556-c5a9-40f5-906d-f96253a22739@suse.com>
Subject: Re: [PATCH v2 21/21] x86/pvlocks: Move paravirt spinlock functions
 into own header
References: <20250917145220.31064-22-jgross@suse.com>
 <202509181008.MoLd2u4e-lkp@intel.com>
In-Reply-To: <202509181008.MoLd2u4e-lkp@intel.com>

--------------Csi8XDs0o0YVMq0XLmHh6km5
Content-Type: multipart/mixed; boundary="------------zcB9cwd0ZBMDf0rsBpcDRZ9W"

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

T24gMTguMDkuMjUgMDQ6NDUsIGtlcm5lbCB0ZXN0IHJvYm90IHdyb3RlOg0KPiBIaSBKdWVy
Z2VuLA0KPiANCj4ga2VybmVsIHRlc3Qgcm9ib3Qgbm90aWNlZCB0aGUgZm9sbG93aW5nIGJ1
aWxkIHdhcm5pbmdzOg0KPiANCj4gW2F1dG8gYnVpbGQgdGVzdCBXQVJOSU5HIG9uIHRpcC9z
Y2hlZC9jb3JlXQ0KPiBbYWxzbyBidWlsZCB0ZXN0IFdBUk5JTkcgb24ga3ZtL3F1ZXVlIGt2
bS9uZXh0IGxpbnVzL21hc3RlciB2Ni4xNy1yYzYgbmV4dC0yMDI1MDkxN10NCj4gW2Nhbm5v
dCBhcHBseSB0byB0aXAveDg2L2NvcmUga3ZtL2xpbnV4LW5leHRdDQo+IFtJZiB5b3VyIHBh
dGNoIGlzIGFwcGxpZWQgdG8gdGhlIHdyb25nIGdpdCB0cmVlLCBraW5kbHkgZHJvcCB1cyBh
IG5vdGUuDQo+IEFuZCB3aGVuIHN1Ym1pdHRpbmcgcGF0Y2gsIHdlIHN1Z2dlc3QgdG8gdXNl
ICctLWJhc2UnIGFzIGRvY3VtZW50ZWQgaW4NCj4gaHR0cHM6Ly9naXQtc2NtLmNvbS9kb2Nz
L2dpdC1mb3JtYXQtcGF0Y2gjX2Jhc2VfdHJlZV9pbmZvcm1hdGlvbl0NCj4gDQo+IHVybDog
ICAgaHR0cHM6Ly9naXRodWIuY29tL2ludGVsLWxhYi1sa3AvbGludXgvY29tbWl0cy9KdWVy
Z2VuLUdyb3NzL3g4Ni1wYXJhdmlydC1SZW1vdmUtbm90LW5lZWRlZC1pbmNsdWRlcy1vZi1w
YXJhdmlydC1oLzIwMjUwOTE3LTIzMDMyMQ0KPiBiYXNlOiAgIHRpcC9zY2hlZC9jb3JlDQo+
IHBhdGNoIGxpbms6ICAgIGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3IvMjAyNTA5MTcxNDUy
MjAuMzEwNjQtMjItamdyb3NzJTQwc3VzZS5jb20NCj4gcGF0Y2ggc3ViamVjdDogW1BBVENI
IHYyIDIxLzIxXSB4ODYvcHZsb2NrczogTW92ZSBwYXJhdmlydCBzcGlubG9jayBmdW5jdGlv
bnMgaW50byBvd24gaGVhZGVyDQo+IGNvbmZpZzogeDg2XzY0LXJhbmRjb25maWctMDAzLTIw
MjUwOTE4IChodHRwczovL2Rvd25sb2FkLjAxLm9yZy8wZGF5LWNpL2FyY2hpdmUvMjAyNTA5
MTgvMjAyNTA5MTgxMDA4Lk1vTGQydTRlLWxrcEBpbnRlbC5jb20vY29uZmlnKQ0KPiBjb21w
aWxlcjogY2xhbmcgdmVyc2lvbiAyMC4xLjggKGh0dHBzOi8vZ2l0aHViLmNvbS9sbHZtL2xs
dm0tcHJvamVjdCA4N2YwMjI3Y2I2MDE0N2EyNmExZWViNGZiMDZlM2I1MDVlOWM3MjYxKQ0K
PiByZXByb2R1Y2UgKHRoaXMgaXMgYSBXPTEgYnVpbGQpOiAoaHR0cHM6Ly9kb3dubG9hZC4w
MS5vcmcvMGRheS1jaS9hcmNoaXZlLzIwMjUwOTE4LzIwMjUwOTE4MTAwOC5Nb0xkMnU0ZS1s
a3BAaW50ZWwuY29tL3JlcHJvZHVjZSkNCj4gDQo+IElmIHlvdSBmaXggdGhlIGlzc3VlIGlu
IGEgc2VwYXJhdGUgcGF0Y2gvY29tbWl0IChpLmUuIG5vdCBqdXN0IGEgbmV3IHZlcnNpb24g
b2YNCj4gdGhlIHNhbWUgcGF0Y2gvY29tbWl0KSwga2luZGx5IGFkZCBmb2xsb3dpbmcgdGFn
cw0KPiB8IFJlcG9ydGVkLWJ5OiBrZXJuZWwgdGVzdCByb2JvdCA8bGtwQGludGVsLmNvbT4N
Cj4gfCBDbG9zZXM6IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL29lLWtidWlsZC1hbGwvMjAy
NTA5MTgxMDA4Lk1vTGQydTRlLWxrcEBpbnRlbC5jb20vDQo+IA0KPiBBbGwgd2FybmluZ3Mg
KG5ldyBvbmVzIHByZWZpeGVkIGJ5ID4+KToNCj4gDQo+Pj4gYXJjaC94ODYva2VybmVsL3Bh
cmF2aXJ0LXNwaW5sb2Nrcy5jOjEzOjEzOiB3YXJuaW5nOiBubyBwcmV2aW91cyBwcm90b3R5
cGUgZm9yIGZ1bmN0aW9uICduYXRpdmVfcHZfbG9ja19pbml0JyBbLVdtaXNzaW5nLXByb3Rv
dHlwZXNdDQo+ICAgICAgICAxMyB8IHZvaWQgX19pbml0IG5hdGl2ZV9wdl9sb2NrX2luaXQo
dm9pZCkNCj4gICAgICAgICAgIHwgICAgICAgICAgICAgXg0KPiAgICAgYXJjaC94ODYva2Vy
bmVsL3BhcmF2aXJ0LXNwaW5sb2Nrcy5jOjEzOjE6IG5vdGU6IGRlY2xhcmUgJ3N0YXRpYycg
aWYgdGhlIGZ1bmN0aW9uIGlzIG5vdCBpbnRlbmRlZCB0byBiZSB1c2VkIG91dHNpZGUgb2Yg
dGhpcyB0cmFuc2xhdGlvbiB1bml0DQo+ICAgICAgICAxMyB8IHZvaWQgX19pbml0IG5hdGl2
ZV9wdl9sb2NrX2luaXQodm9pZCkNCj4gICAgICAgICAgIHwgXg0KPiAgICAgICAgICAgfCBz
dGF0aWMNCj4gICAgIDEgd2FybmluZyBnZW5lcmF0ZWQuDQoNCldpbGwgYmUgZml4ZWQgaW4g
VjMuDQoNCg0KSnVlcmdlbg0K
--------------zcB9cwd0ZBMDf0rsBpcDRZ9W
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-----

--------------zcB9cwd0ZBMDf0rsBpcDRZ9W--

--------------Csi8XDs0o0YVMq0XLmHh6km5--

--------------d9VnNNakkD8gVqBNvxOXiPAE
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/Ey8FAmjLnw4FAwAAAAAACgkQsN6d1ii/Ey+x
CQf+IQ1ng7WiKO4LhrrXkz1rSgyDCT7guo7w2f3gI6ps+45ddPrXGGTIGK0NrAjgRJnZW57Jnolf
AGGN0NdoQQ3GLzherZQ5xl710Ed5WuWi6zWMEf0xgkcFRHsfWO3+Qo8O4kzARZMrxPCs4EgprQsr
pEjdEqx7QK7jGQuGYQn5i7ItiB+lc0xXMAO0r3kcqickyQBiOBvQNuerpHkkbG+tcAiqg5ykGqNe
y7cQ56AudOXRuZn46scyapBudBJLJGkMrZCiBggp0EFEmvVO9loIwF4Hnj4mnyDlv7H/A9oI5Tj6
XbaXkcJ6a3s9ctqNarLQl404rq00+9moguCVUiQd9g==
=EGob
-----END PGP SIGNATURE-----

--------------d9VnNNakkD8gVqBNvxOXiPAE--


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 10:01:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 10:01:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1125986.1467713 (Exim 4.92)
	(envelope-from )
	id 1uzBSB-0003Kn-L7; Thu, 18 Sep 2025 10:01:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1125986.1467713; Thu, 18 Sep 2025 10: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 1uzBSB-0003Kf-Fb; Thu, 18 Sep 2025 10:01:27 +0000
Received: by outflank-mailman (input) for mailman id 1125986;
 Thu, 18 Sep 2025 09:52: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 1uzBJO-0002BG-NI
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 09:52:22 +0000
Received: from PH0PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c107::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28a9e8ae-9475-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 11:52:17 +0200 (CEST)
Received: from CY4PR03MB3382.namprd03.prod.outlook.com (2603:10b6:910:53::36)
 by PH7PR03MB7047.namprd03.prod.outlook.com (2603:10b6:510:2b0::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Thu, 18 Sep
 2025 09:52:13 +0000
Received: from CY4PR03MB3382.namprd03.prod.outlook.com
 ([fe80::2947:e6d0:817c:58e8]) by CY4PR03MB3382.namprd03.prod.outlook.com
 ([fe80::2947:e6d0:817c:58e8%4]) with mapi id 15.20.9137.010; Thu, 18 Sep 2025
 09: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: 28a9e8ae-9475-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g/TSds8bJKj2ewlyGJYBcU06Fn/zLwKMloIEwOze9b6YkN9WfduI3FH+fDGZ9IAl+EOrBhWpzIoh9ZS5osXjPPQAyw036ZmdxfleKhLsK8qEK0z2EALbJFCnFVoVNAZ08ZTpV5/5/bTm11GPFioqU66/SbKWmpSDk0pxBP5Od/b5EkE+IQgoRsFcW4NNNfGPwboNmMp4Wo0m+k20QRU+kZ4gJ++/nMeijJFj+OIyU5bIEDGiJZySJxQQ4CdcRrBFfWrrkGk5C8LR/MtBtMRbnPRlSRVC40/pUWxlGyVG8aKx3pIxbep0Pc+3Sp6QU5j6UMWQB+qaJPrazKvLqzeffA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ktzx6CKOqAF7tJgOGNm+G3PydSf4daiAaHEhq+rcEzI=;
 b=V6mZSpDQjzRNsUn07H1IQyYI40PEyK/zGTcIIRjQj6FJphOejv78PsidwzGb+xkx7tgNxW2jowoY+ZBrOY7dKAaBsvZU/GHgycmtUKT+HOh+hQD/ZSOegfHQPiyTtSrO4L0Xn4ZJVsHTimBYuLPd/O2Ik7Rkz3fchyFjaX9Ll+IbgeVTUthmfPZPXL57HAK6B6gdzKhtGCy/RA0EzZjBl8Sr7OYNcUDGakLu/54tWksxLK/l5gGfdZlNh513VEHqAZNyJ+YImpNpZwlAK00fX+SZ/6YqDVovCEYB3Db5CzrNBMVhh2OeaoKAVeGSD+NWr9kNZV38nMNMxoGBXUOUmg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ktzx6CKOqAF7tJgOGNm+G3PydSf4daiAaHEhq+rcEzI=;
 b=yAgsC6hx/qBwlWJ10IYVbJFav8Bbe8aMSFxYMnlVDV2dTMYXR67c3202YzeBG3vNXKrDC5nFGDPzEmwCiWd0iiK+w8vn9QAivWsAI/TeQh+Yy5o42WLf7fA9ZpIBLJ9FsxrwLd6CYLx1Me2yM1wYahqdRsnG95brbjJVAq9P7wA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Ross Lagerwall" ,
	"Konrad Rzeszutek Wilk" ,
	"Andrew Cooper" ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH livepatch-build-tools] Treat constant sections as string sections
Date: Thu, 18 Sep 2025 10:51:58 +0100
Message-ID: <20250918095203.19421-1-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.51.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: LO4P265CA0246.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:350::9) To CY4PR03MB3382.namprd03.prod.outlook.com
 (2603:10b6:910:53::36)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PR03MB3382:EE_|PH7PR03MB7047:EE_
X-MS-Office365-Filtering-Correlation-Id: 37109269-de42-48e7-9486-08ddf6990aab
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:
	=?us-ascii?Q?lBn4TNAL9qZCN2LM3QRmS+U27g51OUT6r/n7Ha2XiONvFUNzA3ZE+/xJI6Ws?=
 =?us-ascii?Q?EzV7lsMwr0X3uo40ZZu2YWTisz6M/aVbQDbv986Vm4vm2h0x5/DB+OQ9zXi+?=
 =?us-ascii?Q?UnJbSfYWoQ+QMBs13lBkGVzrhbcEMydFMnELcwGyEkPhOHH5MI6WiMAaFDRR?=
 =?us-ascii?Q?GRELgg7igA8hKqGFHCvl/fSXevmtoNOvh6G4VzdbvV7Ciy2usNKbJ5RQqnmm?=
 =?us-ascii?Q?KjXugaG+yzAoheArE+0t4dzoaM3hr94f6NVLOA8gsJH3QzH+gUbLnGH7QWJa?=
 =?us-ascii?Q?QnanFCII+/8kudnkUstJNIvHX2S1qX83cLq2KAgA50QXtSHkN3/AB3Z26ajf?=
 =?us-ascii?Q?OyJa2pT9FrEydeoEAms85Zxvfv/EJpMw0Xx3t5Y6o5geVEsMEYV1hSrwIthf?=
 =?us-ascii?Q?RrzgSoy9RzSCvO/tbXAaI29tsz7yZ0YUMLmRzknR3ymjYBQOEULEBz5F4NKf?=
 =?us-ascii?Q?/DX+gEmLoqlcW5XakqnV6TzNX0xDK/dSAXo3RdXGq6Buh2kuhnu2G7ZUjvGa?=
 =?us-ascii?Q?A7qjBtNgrLgrxmY9zoJGZuIkcHOaCjWMgFZ4Ks1pY9XCLNQ9RDB4GKGsu8kH?=
 =?us-ascii?Q?8TQ2d8N9L6P9T01kM00DconYGhoTLe4hiw0YV2Sy5Fjp22EVFURFMu63DP/N?=
 =?us-ascii?Q?g4hq9ibz+0YrSaC0n89VCghdJE1PGABVijwKEFzI5FkpM50LylKZM+g4t5oS?=
 =?us-ascii?Q?XIecifCVjlFSIQDwchF1il1ENRDiRVnByo7B5brAQPQrNKY5NhZjWtJf2bgz?=
 =?us-ascii?Q?RrpskH2y+P6HH4Z328Tf+TVYSUXAsSHV4SX/ePPwI7FAHuPlbd1HXKeWjGLQ?=
 =?us-ascii?Q?nbRyQSWGoMljtHocm42/zaHZkD+3JFKcq5IIBJgpIOGA9eW9CynlFHCdqWwM?=
 =?us-ascii?Q?TYgAJnXxLBKzDtUPRmidLWNRZB2Q6ZPDiDcwMatdR16tj2wi7xto0YPQRpvG?=
 =?us-ascii?Q?9+Jn9FOQhKGnG/API5mtVfu0rw2YqYwT41AyEgPGWoCeMZrD/17mQUD/ot0p?=
 =?us-ascii?Q?dj5GjOs2bhTCC11V0sEQTaUi/Zrnb3QamWA73tXFMYnf3o/MF1QuO85c8DSk?=
 =?us-ascii?Q?L8RMzbOiJxy8Deud5zk3OjgeuXrIJxS3vWqCAVyl8KL88J1O/YAW8D5aTS95?=
 =?us-ascii?Q?Biz5+zF5Mwqoc5Be13qrv1FutE8MYw3eBpKZ4Y9kiA0t9BE2QQtmZkoRU9Hz?=
 =?us-ascii?Q?G/BOEBf1q4ZagFrmkNTQiZCGIe2bcDLO9jGyhQ3k5ftU2pKaBl6j0bxRxhS5?=
 =?us-ascii?Q?RWAnrm1LkBAAu64J2+j9z236h7Iy22YHFtvlgRimaoECMIPmXMjt6/7ZnVlo?=
 =?us-ascii?Q?QK3rwnCFkBI93iFILVXHvUWDvrus/3wS4xHhNhwwvgu7H05A1t3+d7s5Ct6D?=
 =?us-ascii?Q?Yy8Ui9XUKtJBebFU9nlx1e2WPJraAqecEbBjTH9h2lwfmzYsqdauwX3h1PT8?=
 =?us-ascii?Q?6GnccY6mRg4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CY4PR03MB3382.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?UQphj1Xmh88vhmVeRqPQCS4rdiGNdQmYBAq2mNPo3tJW7BYKB2l5d3tK7HBx?=
 =?us-ascii?Q?0E7wMlve5MzFNSGepU9XLPvl5xWGQPlvsO/EXNL9xgfB501Kff8WD65Xj/GR?=
 =?us-ascii?Q?oKXaPMmtCdfqFAmGYFvxmvq58IQBk0zl3HOKGOnhvQhDYrftg5iu+L8kVbLG?=
 =?us-ascii?Q?gh+8vX79MkhuAnymIQKxZbxCm9gR0+crR5OIm3IRIt6slvJCstf58tNb4PN3?=
 =?us-ascii?Q?gnzx5fjheDszPW+qgGWa7sr83WNgOppZ0Prjg+qEijRsyrUnsq1TiGWnmYtJ?=
 =?us-ascii?Q?YoD2hdaCI324edNqezGEYVzyNfIlKlsWN7UVBpBjYF5AOU9OR9DIWWewbKpE?=
 =?us-ascii?Q?Jza7p09qa23yUfZze7E+1mz6o4sPV0hoFUZ323Sb6aVi6StI02hs03gVkyyt?=
 =?us-ascii?Q?QJDnAcWUUp9QeqN2owVrcg6+JcpSWtnT2asPIZoXCrGerlQr7UYvqD1ZEE6b?=
 =?us-ascii?Q?G3MiZUFCibWGEqCxqWIhb1e+b3Bna4iJbByqtOfKI9xaE8MHnDAqs2r/7MPd?=
 =?us-ascii?Q?2Ic3L7PUjIyRzVGQnOVlxlRfkkvau0JuZDrOqpf+5Xwvlu5l+S9fL1WrrHul?=
 =?us-ascii?Q?5aC7JoB0/DDmugLtAbXjzRKjZ0GJSA05eFLtdOl8hF3/9t3lBxprO6u/dyOu?=
 =?us-ascii?Q?0/JbqoIgAbdUT4jSI6/s1twXFy25eKmdPsKFwTdpTYmVuQmY/5IWeFdDRuDe?=
 =?us-ascii?Q?/i7rvyUUnmMzMonIQB9wd1A8mWxmZ3d4iFVG4WYJ+Ith3DFZiKxMH9mQU+3g?=
 =?us-ascii?Q?y6nhjl3QA9FxJzxnJ15gk1L+2O+NPklqXk1mMOcNCqINkHg/1RHk3aVjbNoq?=
 =?us-ascii?Q?SQZbIWNjbCEScsAYsn3wsw9p/dIaIv54n8WU+uj2rUaVg6NjpwiVleWNR63R?=
 =?us-ascii?Q?Qz4y1BKjev2wO5G7+N/t8LwfgbRJhGqTjzMKkvi76V+Yreoks9rY6yVZYeM6?=
 =?us-ascii?Q?Y1FrX4imvEZYBXyexmSI2akV9CnaZUw9ERQTKakjXtD/W6X/8Q+MoQymF48v?=
 =?us-ascii?Q?vHje9OHLKcdk7AheFD5rVnsE/KFAwvmFWrTm/lLH29B7XQRJYF17kz5Aq9I3?=
 =?us-ascii?Q?uoFQpYivWY/zWFp1jFJzZqd6V9/vtLCyhkblZOoi0Uk/9Caw7EnfGs2/q9Zi?=
 =?us-ascii?Q?5GEkvNtVGLSenpYjaeaV+v41C71/ozHnplqwerQ76GKS65Mzsaz/lI9mmRcO?=
 =?us-ascii?Q?mM9HNsqYooV/ES9b/fesrVsciHoNCF5RvLbJM7HHeS5QC012LiqxrbLP7L9j?=
 =?us-ascii?Q?NRC9kJYjN4cgdByPNuilDzIgpRJEKpt5Euo8hhxBNmPIRSqiHlOsZP/A1gHD?=
 =?us-ascii?Q?V10r0AEM9UVoi7WysSpKQHw9fjWwToMz2p+40F3clvhfh2fSm/rLkScBxpW/?=
 =?us-ascii?Q?JCabuePM6QjwyrrxLK9wT1QwiCZrfDM7a0LKd8F+8FvyAWTaydXNMsWwhZmx?=
 =?us-ascii?Q?sip5l9mbqPBYvp+Ea/U9VyCc8f7Hqwue4fldE106Fp3cQ6cJKdgahqSdu0sP?=
 =?us-ascii?Q?GT4upds8gu+B5I/bHMoFRcBDgxFJo63YsGB4Q7RCZyrbERNhnKND1z5BTccj?=
 =?us-ascii?Q?i+JqLIYNtTkn44GMQHR/Ce/JNS/TJ3+rYx5wENM4DhoXIeisnM+msGW/QihU?=
 =?us-ascii?Q?7g=3D=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 37109269-de42-48e7-9486-08ddf6990aab
X-MS-Exchange-CrossTenant-AuthSource: CY4PR03MB3382.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2025 09:52:12.8693
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: MFFntwDHClaazKv41AD/KxB6t/zQXIjuYSvMYJoZ0RQ+f9fiC40SCz8/kPK4KE5/ARR5FPi79bORhiLKHvnKAdz7P9SyF0wmtaNYtV8ypXc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB7047

Newer compiler can put some constant strings inside constant
sections (.rodata.cstXX) instead of string sections (.rodata.str1.XX).
This causes the produced live patch to not apply when such
strings are produced.
So treat the constant sections as string ones.

Signed-off-by: Frediano Ziglio 
---
 create-diff-object.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/create-diff-object.c b/create-diff-object.c
index 7e6138b..7acaf88 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1446,11 +1446,16 @@ static bool is_rodata_str_section(const char *name)
 {
 #define GCC_5_SECTION_NAME ".rodata.str1."
 #define GCC_6_SECTION_NAME ".str1."
+#define GCC_CSTR ".rodata.cst"
 	const char *s;
 
 	if (strncmp(name, ".rodata.", 8))
 		return false;
 
+	/* Check if name matches ".rodata.cst[0-9]+" */
+	if (!strncmp(name, GCC_CSTR, strlen(GCC_CSTR)))
+		return is_number(name + strlen(GCC_CSTR));
+
 	/* Check if name matches ".rodata.str1.[0-9]+" */
 	if (!strncmp(name, GCC_5_SECTION_NAME, strlen(GCC_5_SECTION_NAME)))
 		return is_number(name + strlen(GCC_5_SECTION_NAME));
@@ -1462,6 +1467,7 @@ static bool is_rodata_str_section(const char *name)
 	return is_number(s + strlen(GCC_6_SECTION_NAME));
 #undef GCC_5_SECTION_NAME
 #undef GCC_6_SECTION_NAME
+#undef GCC_CSTR
 }
 
 static void kpatch_include_standard_elements(struct kpatch_elf *kelf)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 12:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 12:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126023.1467735 (Exim 4.92)
	(envelope-from )
	id 1uzDZ2-0001hD-Ep; Thu, 18 Sep 2025 12:16:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126023.1467735; Thu, 18 Sep 2025 12: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 1uzDZ2-0001gO-7S; Thu, 18 Sep 2025 12:16:40 +0000
Received: by outflank-mailman (input) for mailman id 1126023;
 Thu, 18 Sep 2025 12: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 1uzDZ1-0001YH-5y
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 12:16:39 +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 532489aa-9489-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 14:16:37 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU0PR03MB8720.eurprd03.prod.outlook.com
 (2603:10a6:10:3ef::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Thu, 18 Sep
 2025 12:16:34 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 12:16: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: 532489aa-9489-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Wt0C7Lz5i7UvO9H6f+Td0B39yB88DHo0AhgBQfbR7RQhNhcigsDy8xr2ST8O/pW1JfkyeeVvPEkt9kyBmG3wX/B+xBUPVmm5ZD2JFGJo6KKAd3DEc7e1WQrWZEg31CSPKdoLBiqYIhZidmswZls60elT4Xcmmi3Hn88vl+MjUQDFkfTR0uamV7jVK++VsVQ9fyZS2Byxjg0/u67aUFFOHPkshO7vtkHYyAYSBEZwP+hPESzFsUhmqJhFxwpKlTUg4HvN6GvY5IzqEHIJV8XM4v73aMx1qpKfdQDLXryyAEfpA4k0xLDF9G6Q5pT7Kfc81wMT1OphyZzEpkad67GaSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NN+9v4HUcACKQP3UTIJ7uIDFEXsmW14cpvwu+bPQxAM=;
 b=X36EViaamCgUl7S0uZstEwyp0QwDnTUad8+dRG5STkT714Vq6hD8Q3LwCE+N4Wpq+XX/Aaiz7+0rRpAMGEZ91zrc0xdlW3UUu8b1yltw8G0raDNn6IpzSRtkJS+55PYvjdSOD2lYgjJgyzGY48Xx3M3yHNtiyrKjurXOzApichaEb3ZdGpjnOxQJtTwR4R2zy4JRATkUAXzMYCb3l+/lmwutR0qjaaq0tenu7liSBOcQ6MmVoGFzkBV9hjbkf593RiHvL8z0NgYUX/OEKfZCyeW8uBVHGV15zxAHl+WzTe39N6r8NaVwdB7B62xBS4LM/ZeCMS/Tm8wYho51vK71fg==
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=NN+9v4HUcACKQP3UTIJ7uIDFEXsmW14cpvwu+bPQxAM=;
 b=viyx9TeXvF/Fe9nCVYwFzbaror1St55N9Lk/5XjwMg6fRh7bgRo/4cwcK8wySeSzfdhW2ocKEuf/WpNdVPtgULlwPaIUvcw1qWQ3arCUeMXuanagSaVsZsTjE32N3wUDurXY1GWWdBDn4HjMZ19OXqJ8v9WkzGTHaHGjJJMmM+rk6YYzkZxWieNLuW3DK20YLZOvQy8dAX1N8TF9VnsKpteoYy8qz5bdtOMIlXa2FaRBI3kSUNVwzdu32uCqivqDWntt/S3UYBLsif2Xw1+mcKTtLHHm00a976lFfX+D8fcN/Kz3RTm0ezwImkhu8e0HyNH9rDhIv81roESkCXyVaA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v1 2/4] arm/gic: Use static irqaction
Thread-Topic: [PATCH v1 2/4] arm/gic: Use static irqaction
Thread-Index: AQHcKJYSC7sAxQi7Lk6HVSEybUuLWA==
Date: Thu, 18 Sep 2025 12:16:34 +0000
Message-ID:
 <772a7621c2d0976106c31e5d43205845b1e97a62.1758197507.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_|DU0PR03MB8720:EE_
x-ms-office365-filtering-correlation-id: cae7e762-8cac-4f01-2791-08ddf6ad3574
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?+dpW8LAhJ06u06AuGS/fjHa2MiFdTB5R0aXz/D/nRfgKeSL8sXkVfkXtOV?=
 =?iso-8859-1?Q?xy7vPZUN+LLPYCrc5/0ZlRbFpMnzSzgnWaOL5Shc+MtVyqjATHnvk205S1?=
 =?iso-8859-1?Q?poxMu+x2ck4MhFGJJw2MHxiX9b1gwv0DRP3PK+luab2pzLPYisK/rTYJ4E?=
 =?iso-8859-1?Q?RdIAprd+GHYfAEYRf91VpD6PXl0tczk2oMSV8s/mwR23NVyae14zZW3rDO?=
 =?iso-8859-1?Q?ek7/UXgenXLjMbBtt4oKIU8z7auEBui0bmgxKDTh3ICIj2H1IIlh7TwHeR?=
 =?iso-8859-1?Q?mH6tyzfMoSDq3hxCAiGiUEVvAV/VtypXrxTR20okjCmrEsLWp7pInym626?=
 =?iso-8859-1?Q?a1GlI5SfcXIBljC5vQvkD26JRy1c3eHFYZj+MSUKcH2sOxs+BBrgNVBhvB?=
 =?iso-8859-1?Q?CsjbCqPJmFa4I7gJ3guHrYDL6/bC4E/2FYCvJPxNsRFYqLnIJjoJB6MlCB?=
 =?iso-8859-1?Q?boK48vxxEzWszsbeR43p5J8dHKmuYyccpG2YgqzNtJgQoJntgMh2O1YR9O?=
 =?iso-8859-1?Q?RHggLLg/JMmASlsDHUt/bdhoGwSF8F6hdm6Rmgtt26Zvcg9rR8iTB5rBZ8?=
 =?iso-8859-1?Q?fQjauxgUE2c4+vVawFTkLhdV4jqKgzc/cRF4OewiGBKSeBjmBM2o9bcLr8?=
 =?iso-8859-1?Q?kURIz7UoA+oto4JaAq+a5uvo7FRbrqxMwaZkoPloC4MP886hSuj1Xw79u0?=
 =?iso-8859-1?Q?qw2vJpR1dDc5ZhDbHIA8AmfsAqK+mr7yp+y6BSdo+bLBMMBK1chtnnn5Rb?=
 =?iso-8859-1?Q?XQ+vLnHh6E+sxMcjCQSK+pecOpnnWwi2BOsi1OKSVtve0Z4udvNQuma1of?=
 =?iso-8859-1?Q?9+ilYnWm6pvCKfS+BOxt0ztEVLgdhhYWdY+tI2nxQMdI/r37G7gqKDLwbt?=
 =?iso-8859-1?Q?PXBVSMi+vw2OFjqr30e0yO4vs2cw03fZU+BcJQI1TUfwLt1PfVw5gZ4VE5?=
 =?iso-8859-1?Q?ZcsJWWuh9IpB+GE5rLLPTgo3aiY3YRNkBoWxHRexxGOJOHEFUAItx/GfyN?=
 =?iso-8859-1?Q?ZMSaOkpIol1QlcZeO0v11MNsycByrfIGied42vMgkh0hySlW1kci3j9G7l?=
 =?iso-8859-1?Q?J5wpI+4nLJRuLT1D9k0rrK6uzpUuh1DyixHCmyDO80DC+UvdIT1e2Z6wnU?=
 =?iso-8859-1?Q?LkkOMKLY2IjIgyLYYgdHgrQZf73cWTw+2DWrPh8gdDBCSOeOX91I8yG4gn?=
 =?iso-8859-1?Q?a7DZYn4k98G9GnM9b0/+FENEFTNlDyEWEc5de3lfRHCFYhraQIxxXX3Yk0?=
 =?iso-8859-1?Q?KLzpsKjaZXkqVjbNyAg6FZo4CX9gK2QyulRy2E/FMOMl3ncqFxtxUS0tnv?=
 =?iso-8859-1?Q?YlrUpeTje94rCh/T0MK2yTk5GfYu0K7JbtcMsHQFK39wsv4tANAYpStFft?=
 =?iso-8859-1?Q?me++CcCBpjClAnesnt30BksQVWCBo3NQhypcm4Io0gp1n3XYEC0YUu51xJ?=
 =?iso-8859-1?Q?9MesahjFAEmXKUeoVmtkAuQlsDMOCjl7OKPfmZifyOySgwfxmpOq4K0Qoz?=
 =?iso-8859-1?Q?1jzzh1SuB5V/HqfPiTK0nH8FXrqxOVT+9JvfU39Rlh+w=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?9AXeTR+sAmk+N8MS+D0lmqrXoWyEjQvd5qQnkiyp4pp4ZL/8iuEa0l8pB7?=
 =?iso-8859-1?Q?82skyVWL4WI0SrRckxWF4C2qnsgiNLSfcoLK9cvnOUdDNPbSSDXhodibln?=
 =?iso-8859-1?Q?gmlaSRdyf3+XvQe1+v4hom+w2Ls/bRM8xPzVjnwdU7P3FjfefSFWnqrNhf?=
 =?iso-8859-1?Q?7qQd/bWBNxMLTQaHfElQDFhpqM5SvqPJG48+HAdtgSQNvNdRWB/2M9AGe/?=
 =?iso-8859-1?Q?TgdTOl2zLkzKnoG9WGShwnKRRvredMczzkHAP2q17wycqEB9RzMVDE6TLk?=
 =?iso-8859-1?Q?NsuXIedNEtUTis3c3MRLREMVJKv4+WcZ3JsomDlJauyiMX/Avf1wtGmryO?=
 =?iso-8859-1?Q?6DLjE7/op2JzkPyfuyH1TlaB9GzsgiT6RUa98UdJd+YI7jLc7Zw1IakwuK?=
 =?iso-8859-1?Q?w07zVj6aKlsS0PIIG+hTKROEPoTlstIdqaQIJv4YPFej4Iro7bUKD7ULH2?=
 =?iso-8859-1?Q?tzlj15tTPuAkcWPqwm0iKChD2vD7aA2zIF0ePAGP8W/igZpsqZsYIaXz4t?=
 =?iso-8859-1?Q?UJ2E8un/MMs8YkxfGB5YHK1daOcSkkkt1ZFezvFvDrPQJOn2ziLBOkiEGl?=
 =?iso-8859-1?Q?Laib6T6FvWLnN0rOjFZwIDDhUO0G6+ekvdRc9A5oh1gdPTnWPpdp0q59C1?=
 =?iso-8859-1?Q?UtHm7769C9j0unYSE2Y6ef3CCjNmBhdddKXSNQkTUHySlJYtaBNQEqBzDQ?=
 =?iso-8859-1?Q?f5GzTQhAKcB+Vp9oQTDfdxGlJYpWW+YyQbBxk7SZIDpHMKijDM6PbvldA1?=
 =?iso-8859-1?Q?Yh1iGKiyA0INNbS8sadC1DbX7m6/t1R3fSYnuLXZBqYGPGp0lzD/n5fHU2?=
 =?iso-8859-1?Q?eTJ7qv6aNQ4Vtc2q+Lc5Hsh/dFclhneEMNiQqqlAMY0CBGQar0jIt0YDp/?=
 =?iso-8859-1?Q?IKqFzV+PHELihewmEz2ciFl2P1v4xCTAMvGQYSSK4REoyWfqG9XOn0BDIX?=
 =?iso-8859-1?Q?lHjjTcb07hp4vKPgfc9tRR6rdaosJAGBEIyniXR62Gb8mM55KWQ911I/s0?=
 =?iso-8859-1?Q?/1qrknxktmCUJea/bwYTnCEYv93R7GZ0c6f2ZYJV9YCChuhfZymUGdUKog?=
 =?iso-8859-1?Q?FAxtHPz7G/MoqmYQbbziUhczKknsSbTG5Gk3ByGyTMljlBdDbIv/Mnh+78?=
 =?iso-8859-1?Q?Oms6sKl+4ZWqNdRr9Msu9xUYKINm51+DHOX6f/vVaWpfORVtrj8ieMCYP/?=
 =?iso-8859-1?Q?UmJkLjnSRJCw9Du1YG+wWeT3Do9ZACya2/12/4M/Qo42tyIYQFaR63m/XS?=
 =?iso-8859-1?Q?D0Z4KxS1/R+1c+Q0lDGDKkNuXGRg5li0IzWko+hFv3/g2jgPw+3G+9TWyc?=
 =?iso-8859-1?Q?Z2HhSyMXCgEaCzBs2MU23iPGcqdZMd00vDw53S1RERNr9ZXdvxPZQ2JMDJ?=
 =?iso-8859-1?Q?HLzQAY2QpEB6NXV7xIAFJi0aPoHrDMCEId4a6IbWYvSLgnd+vEvOYatc+z?=
 =?iso-8859-1?Q?BQ7sAqpeAZ5llHyrEjNQ7ObXkFkCjXsPr3YJ3YxSDMJXQTiufeYakBnFPa?=
 =?iso-8859-1?Q?algavOjo702uh4f7bMD11Ct7NKt7Tzf5AowDNa8u5bX/D2U2OXJD7C3DxB?=
 =?iso-8859-1?Q?zaNxkVENRQCMvrKx616W/ylvzHTfVq3njmTBA2VYd1LueDSQ1/D+WRwmbT?=
 =?iso-8859-1?Q?1YEtJba9oblUR5zbsA/HvhNiyNmf8/lu9cPhX2T8xa+VFER0kni50DMg?=
 =?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: cae7e762-8cac-4f01-2791-08ddf6ad3574
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2025 12:16:34.3028
 (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: y8R8K8OacKiNJVLSdVHA74R5XaA7FdAH+7OonUEL2uTZCHNrsJCv4usnFBA1YpK+rwNueMSzpySn2rfglqfifg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8720

When stopping a core cpu_gic_callback is called in non-alloc
context, which causes xfree in release_irq to fail an assert.

To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.

Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/gic.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 260ee64cca..b00747a250 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -386,10 +386,16 @@ void gic_dump_info(struct vcpu *v)
     gic_hw_ops->dump_state(v);
 }
=20
+static struct irqaction __read_mostly irq_maintenance =3D {
+    .name =3D "irq-maintenance",
+    .handler =3D maintenance_interrupt,
+    .dev_id =3D NULL,
+    .free_on_release =3D 0,
+};
+
 void init_maintenance_interrupt(void)
 {
-    request_irq(gic_hw_ops->info->maintenance_irq, 0, maintenance_interrup=
t,
-                "irq-maintenance", NULL);
+    setup_irq(gic_hw_ops->info->maintenance_irq, 0, &irq_maintenance);
 }
=20
 int gic_make_hwdom_dt_node(const struct domain *d,
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 12:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 12:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126021.1467722 (Exim 4.92)
	(envelope-from )
	id 1uzDZ1-0001Ye-Qn; Thu, 18 Sep 2025 12:16:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126021.1467722; Thu, 18 Sep 2025 12: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 1uzDZ1-0001YX-Nb; Thu, 18 Sep 2025 12:16:39 +0000
Received: by outflank-mailman (input) for mailman id 1126021;
 Thu, 18 Sep 2025 12:16: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 1uzDYz-0001YH-JL
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 12:16:37 +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 52537508-9489-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 14:16:36 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU0PR03MB8720.eurprd03.prod.outlook.com
 (2603:10a6:10:3ef::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Thu, 18 Sep
 2025 12:16:34 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 12:16: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: 52537508-9489-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=km6aThQ7Mhvz2C04B/mdxpNvaW/XS8Got8rK1+f1sosjSvenkCLNOX1Sge1jWAIaVAtoLFhQJ3o9l8YYdv0cMU5k1umQcfPrhFQv3Plu7tR0vX4B46lm0AU3SqSazA3shSjufqsqPRs85fVvw66UwQQXl61oUqR2MMpO9s6XNiUrNTEYxtMpbuz+vTYEs6DjgnFrjh8iHrCRAWKZvGbawJDcon4AFPi7nDgeB2/eilUWtjlpQh5cb/D1s0aNZprB5RyqOtfvnsQibNqgai9UdHkqpsTZ6WS3RZWPa77c6s4E9sw38zOrvsm1vRhyBz3ukbQ0CYvcznrD/0q8ghBtwQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NjOMxcbZy0hyh0dIObKoLQ2p0jnzV1Yb02lrehaU3Hw=;
 b=wwAX46GDFuCrUJNGrHOckVW/We5/zneoZp4xUGeB45mIvNDUe0YdoMIg1Z8VfKZeneLCL04EgnWI413m/zb/WTgV5w6vzXC7edB30TTH/vwkG9QWYXV1kSiX5jIjund6hp9f187wubA/TEwGx33BB97yH+yig+41Miwar4kAgZXtK5jYH8NiEaTZNNVkJuuibhXvZfdPYgKh3SrBS+RWHZC/8btzG/bRPZrxHLrTNL16UQTp2e9I54UT1/TEGw41hwz32XHl/kBGdc0JYsuTPC2k1tsMT+FiMElRH4aGfQ8kfcaaXiiHY4HCaPNvkeeeDEwfdv9xI7x8BskdMEVoGQ==
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=NjOMxcbZy0hyh0dIObKoLQ2p0jnzV1Yb02lrehaU3Hw=;
 b=eocPpzRTztq3glkk+xS8o9PbVOf+aptaFZrvOlQCcZGFe6xXexqgVh4rwOf+crVqvtu2Sqpvl9G43zimJ3iG9p0TlYWOEq+LEfEc2ay2gUzLetqOgzABOjQLoLT7Vnrky2qC1z/dYuDeo0FzweJYcF6hPL1noqLn16ELgTECGSeePtoIziSa/TXVHEhwWUE/7zHcyvQy1HEqnTXA6kdvhNxQTc509140EymR2IwWZ6EP0s8Tjnfe9lATMNBfBAWVo4NW7KgBLwX/MDrk7ojt3BAPC7BJskIXm8xOfQwlCovmF4pT+8EVlzFawkVa3C7oUJ6NKP9YNLkcolWqPoDGyA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v1 1/4] arm/time: Use static irqaction
Thread-Topic: [PATCH v1 1/4] arm/time: Use static irqaction
Thread-Index: AQHcKJYSTyRyVCV94k2TjQUv8/ENTA==
Date: Thu, 18 Sep 2025 12:16:33 +0000
Message-ID:
 <9d10949d60aa930d6b281824f5879e804ff18918.1758197507.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_|DU0PR03MB8720:EE_
x-ms-office365-filtering-correlation-id: 31f31b0a-6ea6-47e2-99cc-08ddf6ad353c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?YzNTj8o+jkNn5B5E1TRG6hh3zQAfk3CsyF4ZnoeQBPtKBeP2YaJsfmFotd?=
 =?iso-8859-1?Q?BPI0j4ug3uRgL4bdt3WhA3vgbeGZK2+n1yNjuL9R21q8AK2oTH19lzPtPm?=
 =?iso-8859-1?Q?nTxMNfRR3cb1RLScMZN4SyVh18eRoTRUXon8COPaip2SO6lFkDj3Qn0IP/?=
 =?iso-8859-1?Q?L9tn/DjN68ekmukIDY++CW98ryDkyNFgKEjmfwk6xpv+FL5T6OcrY7qQik?=
 =?iso-8859-1?Q?9F1jfErNn8DHL1SVL1PYrefC9/zsg9VZoMAki5thHEGwtv1p7oQSJiTJQy?=
 =?iso-8859-1?Q?BECtLPe7yNa1+5CiN8CV/xp9pcF4722YQ1qTK7QdDoity2UZH5K6wuHHLB?=
 =?iso-8859-1?Q?ELJhyOtnW7viHfEZQbsQwqtE97KFwAoYlpu/VpVmD3Q2ppSFHSDyX1BPcp?=
 =?iso-8859-1?Q?Fsk811+41nzCUzHBwDwq8Ipt88vVFG13p4mwWf+PJqgjUjAc+o5TQ97K9I?=
 =?iso-8859-1?Q?YxzBH1rwK/GJFRFtypmV4uG6Esc0iywwvyHKmOGZ4OnoiDmQ9ocnvaNIvc?=
 =?iso-8859-1?Q?Oqr9RSIPJ1YdyWSON9xB4ktgTcrUfAmeHbnpiPfcz03hXjzc7nt6o0ZuSV?=
 =?iso-8859-1?Q?IE9uNvSuKb3hNwdDm5szNtMHzFNt0hfYfHlaK/lmkIabyRodW5B1DubaMl?=
 =?iso-8859-1?Q?DKIPwzTMNgy8iCYInj2RjRkmH26WSdnl7l5c79pGHjr7yo6nztE3SMFDYC?=
 =?iso-8859-1?Q?qybDdPEynADvUxi/pC5nUtJ4ClJ6sb8m7SiuQ1rop55Jr0Wh76OskD9uuz?=
 =?iso-8859-1?Q?bkE3UxD+i/3jO9FHrzsKrvJHKdgagZe+tGV6wYcSikIPfiMUxCIrMPEj36?=
 =?iso-8859-1?Q?6GX3DlhLCIfmYSUKOpQBSCl0hziCRPukK8WAjt1Tzjyg0dnx4x2yMl6OBO?=
 =?iso-8859-1?Q?bMrCoap+hJYgVTEVaZ0+/ucUZyLCeB7Pj9T4yoImElMkFPHIwQvTjACK0c?=
 =?iso-8859-1?Q?Fr30kHpS6tR4B4MvYvFPdt0pdRtEu0Ce00vZG+hXCZ5u8gqrYZ+vWunBX2?=
 =?iso-8859-1?Q?dRnONAfAGNK4DCYYa3ytyyaBYW2k78O2Q8NVQfVaIUWgbh14MmZkKAAs9p?=
 =?iso-8859-1?Q?D6Zg7wRMXk1KL9PNlODwjzq0lRNdsFMAOp6hX3H0zpduodb8J0n0nLvPIP?=
 =?iso-8859-1?Q?5skQUOfI12lVNE7p9FBto/r+1sijioTH43TlIsRcwDsuoIZfKOCJmRiWbd?=
 =?iso-8859-1?Q?dem7yxJ2bkSR2NL6p/VQM5kzeOjkWlX3ZGVbjBZbhXCdXOLF94dAskmW4n?=
 =?iso-8859-1?Q?PkAZM4FClEfAlXdQv1zGDe0ll3GkVe1dv/CqfyiVEyIN33q9qqwQMxtrWg?=
 =?iso-8859-1?Q?uhZWavcBwUKu2OozvrfjLWJ5oLxnQykof+x/ClIhfPYKfwYWidSjIzAVI6?=
 =?iso-8859-1?Q?XXF//YpOPSOb5NdCP4Q2u90r3ySXbvUirAI/S6FaU8rpUAxLpVcnJVGY0d?=
 =?iso-8859-1?Q?SjQCbwWWqQP7Tsvs1X1W1JaQhFe6HySzpQLCfjYmvYIU9rhuVoVPjILtxL?=
 =?iso-8859-1?Q?xHCRlTI3WHS3+Zp4rSBBTqreunDFk1hQi1eY4sIEZPKw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?f1/9zRhD6KxfdbHVyMtGGcyelbzJq28o1cTn0YbJN9/DfjcrIOQ+yh7/fJ?=
 =?iso-8859-1?Q?qr3oXgim8LBOwU+eX5OBZDwlzocYTYW+n74ycZAzswojkddp9/yVc7KjTc?=
 =?iso-8859-1?Q?zqW3JMHQthDpQGG/ubWMQBEdfSehV3/aj3CCUpm4pMcgNGfHecbtxEuOkD?=
 =?iso-8859-1?Q?kR6b806irkxxE8ysjT7PMvRi2IS7hTuKIKa+z0vUFxwDFfxAQKJmjv+YMK?=
 =?iso-8859-1?Q?YmjVt6GHEklVdK1argok/HVVUs2tt+clB4ovb3S7GyVin2MpVBSl+237TT?=
 =?iso-8859-1?Q?xPgW6MqRZCLEinPdcGrqF4rFypORD66C5XM0TmHFtPSLfwA1vHmYECla1N?=
 =?iso-8859-1?Q?vJ+4D1qGZz7FBNoeWMF9NT2swQvRMewDDH2kkJ9RfQiVtZ4irc9IVjgmcN?=
 =?iso-8859-1?Q?/Cu60UFam2LLdHGJuS7Mw/oBsoe1fFswvTitGTkXxRCPLc4ymv83ndnIse?=
 =?iso-8859-1?Q?Nic8/5EUnORSj7osz7q1pZF0JSOdOcm+0+nGHG2RXTDNP6m8zJ9bN7LeFV?=
 =?iso-8859-1?Q?y4p+YuWrMSNIOkyw96gvEseqNj1zcrb4yRl3WhUo5rCBovW5CJQ4FDO856?=
 =?iso-8859-1?Q?ggRehXP3lio5vBM8PkqHnHGWo1G8AVDZ7PIqv8ZzjtKZZSQflNcy8alL4N?=
 =?iso-8859-1?Q?mSne1cev80hH74HNQ4xsaSCR5ZeYmLBTz4OpsDgd/KR/cRpuHI2MBCmYTc?=
 =?iso-8859-1?Q?bL3A5R3QDmpfr+dCanIl6xKi+5SO3Jx+xtszbsKQUCoH3z4XPSG792QZxu?=
 =?iso-8859-1?Q?Z/u/lCYCz4WVadGpQM1JN3CSBRc6x90Qhc88wltxIjQlfWhhC/KFpF9Qyd?=
 =?iso-8859-1?Q?ex3IjtYg/idNmjAIaR+hOh7cZO6WnRPk+jolqHu23+kLPxijpjzs2+kXwx?=
 =?iso-8859-1?Q?eFXdtQoDL5FcqEr4RlfsqdrrDW+tkMoh3KdaPA2HiBIggnFP/HzEDQ05a4?=
 =?iso-8859-1?Q?PuX77oFm/DSoUE/JNXpLpB5Rw13R3cChkaBuq09DetI8JGsfqdTCA82QNv?=
 =?iso-8859-1?Q?7V7vFz7RLqWlXg85WU8hYmsZTu1aABncrAD7iuUj6W0wCKlWHQjNauWyZA?=
 =?iso-8859-1?Q?flJ+XkWEPe1d0ANThdj2u7wkOIIMB+38K0UoOem8hgsKWlGBGGAUeT2sTP?=
 =?iso-8859-1?Q?BScAHTqNTOqSR6vXtJbgb177InEUnU2dpcHZT9tifKlVCOZOFWGuN69pT8?=
 =?iso-8859-1?Q?/Zi8HHiFGoi8R0a6igtNa3/W71guRHfMYQjyt9uTsHcccDHUOkn88wmCvf?=
 =?iso-8859-1?Q?JpPaSC8HhrBRbY6tlp7CjmWW6zSd2yfAj36VkBnG4XcwpWLX2gmuPmYpde?=
 =?iso-8859-1?Q?6DG3wu/QSItodj4dx7kMgq/P2ztizKV+m7Q0aq7E33U2cZ3LWkPAiaa9gZ?=
 =?iso-8859-1?Q?9x4FiL/1aywP7I4U/Mrkv1cV23rUHG2GbxUWlSHMdg3qWD+ArQhX9LT8PB?=
 =?iso-8859-1?Q?8Q25y/Rfu3jjX3R9AGzm5epW6PdIluJ/6hF5h3uQZomQS2M8Mn0g8S/YNF?=
 =?iso-8859-1?Q?BiCzGqWkc/OlJWk7/6UWhrSYp6rcWKq98oYur09/QWsc5oSJ1X2l15iYlO?=
 =?iso-8859-1?Q?ZAjgnLtD2pMvv/9AKzJAFaPPNngIdjWWDE7LnEVZhzy4b0jjW3MaDCdd23?=
 =?iso-8859-1?Q?qAOMOhrjT0d+r8oRRNSHujGX1RF6B2mB9xwWfgUKqv8Md1ncmeaiEE4w?=
 =?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: 31f31b0a-6ea6-47e2-99cc-08ddf6ad353c
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2025 12:16:33.8766
 (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: 3FHIFFSrWQvE9ad+iUzBbqAjkCaPHJjjGORDkVQBmacKdV3QURPmy8lhckE4dX12Mq4jeQGhUMb25QDodvMUyg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8720

When stopping a core deinit_timer_interrupt is called in non-alloc
context, which causes xfree in release_irq to fail an assert.

To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.

Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/time.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index e74d30d258..6f215de210 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -303,6 +303,20 @@ static void check_timer_irq_cfg(unsigned int irq, cons=
t char *which)
            "WARNING: %s-timer IRQ%u is not level triggered.\n", which, irq=
);
 }
=20
+static struct irqaction __read_mostly irq_hyp =3D {
+    .name =3D "hyptimer",
+    .handler =3D htimer_interrupt,
+    .dev_id =3D NULL,
+    .free_on_release =3D 0,
+};
+
+static struct irqaction __read_mostly irq_virt =3D {
+    .name =3D "virtimer",
+    .handler =3D vtimer_interrupt,
+    .dev_id =3D NULL,
+    .free_on_release =3D 0,
+};
+
 /* Set up the timer interrupt on this CPU */
 void init_timer_interrupt(void)
 {
@@ -314,10 +328,8 @@ void init_timer_interrupt(void)
     WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
     isb();
=20
-    request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt,
-                "hyptimer", NULL);
-    request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt,
-                   "virtimer", NULL);
+    setup_irq(timer_irq[TIMER_HYP_PPI], 0, &irq_hyp);
+    setup_irq(timer_irq[TIMER_VIRT_PPI], 0, &irq_virt);
=20
     check_timer_irq_cfg(timer_irq[TIMER_HYP_PPI], "hypervisor");
     check_timer_irq_cfg(timer_irq[TIMER_VIRT_PPI], "virtual");
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 12:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 12:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126024.1467753 (Exim 4.92)
	(envelope-from )
	id 1uzDZ3-0002DY-PE; Thu, 18 Sep 2025 12:16:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126024.1467753; Thu, 18 Sep 2025 12: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 1uzDZ3-0002DR-Le; Thu, 18 Sep 2025 12:16:41 +0000
Received: by outflank-mailman (input) for mailman id 1126024;
 Thu, 18 Sep 2025 12:16: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 1uzDZ2-0001YH-69
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 12:16:40 +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 5370327d-9489-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 14:16:38 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU0PR03MB8720.eurprd03.prod.outlook.com
 (2603:10a6:10:3ef::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Thu, 18 Sep
 2025 12:16:35 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 12:16: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: 5370327d-9489-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yyK3FUYbMAeu5yWXorF4d6kmWs93NoCWQM8zwf79WZg5Mz0cp0iqsbKqrZheGRfcGtUA4zA+VsD5NyAknS212rVlb0NkOey8ayRLVG6Nej94uqDR5av4EKAY7r1qn82MMVjNsb579cN/Q/kESsDS0KTGP2YWUo6Cctv8fnPHx/s4Gn6eGG4BKP9UdbAISOas+O3XN1s3l5l8XWg2VoOM3LFBuQRWOdKsbEIe4aH2JjTy/ylmeRhgzXANU2iUQJZ2SIWljgmerCwI2W5e5gwreYjc+C/fV+lg2QNMoO8lQA/u/HQUsLGQldHB9fbM7QZNXWh9IizaUHMYeEeWw2jNew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XuWio91C+xwkw6tYgTKTQsH+XEeYXYKNaFzCjkYa/oE=;
 b=FQAVncwxQTsCFC8yfQ/JgsHQidcOhvACXWnQ6uhkWlLMynvTU9tfkjs92alQtCpP28WFLOlgyRRNZoxoZrg4wy+zh1/lfU/xJxWbxq27o+wY/yS/hMU/7g3HfIveLcZsKyIBlxROVy0/pE0FbnsKMO42CIQXViQY5OEQf8/esFiKPcVEX0/SJ7/44JXOktRetZtfPs/ZJZnlF1NL6lJVO/nmZhDbyOVTu0AMxY8Sa6tt6altpUt5+Tq+yxCDLH+yE8elJkQkVuGIM3gbAQH1A5ZH9EvvHWlVMwQv//dvTzTbrQLWf+YfgNn46B96dR9ZI7nRZnBc3fPdBvQpM+FJ5w==
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=XuWio91C+xwkw6tYgTKTQsH+XEeYXYKNaFzCjkYa/oE=;
 b=BZvTHDDRHnZfKoiRQhjTbROHQm+1hp9zSlfRhd/UeQukSinGbpQBjLFgIzC0VKmOVe3Tuq6quYRkMz84MOwu1VC2n6E7QPTVrso0ko6PKCnvdO+BmlljqTAWy6Tkcl0vkTUIcCiIHFggqkVGOorGmL1uROeQxYLys4G/XIbp0ZBOxsHiTbthR83UnFZ5XdWQsAAD4YLpA62g7TjTk8k4KOIe8a8d+Eo+w4lGnxvLVOy0rNpbPpM55vgvcrmaV8C7ToTzUvB1M/CmX+Mtzcra4joLVLpF5xZfoSrA6S5X6bhvonkuJ8TE5F5Fp1fFIvstPhcaNsFEW4GQ/h5ql54G1A==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Thread-Topic: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Thread-Index: AQHcKJYTkGTrKHgw3E6UlX6hg7Or+A==
Date: Thu, 18 Sep 2025 12:16:34 +0000
Message-ID:
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.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_|DU0PR03MB8720:EE_
x-ms-office365-filtering-correlation-id: 80a28292-0cb3-46c5-f841-08ddf6ad35de
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?rjOiLWoZgbnVVasupUXar9tanyBkeBgHAPjZLzMgV+6cIiiJZwmlNNEIr+?=
 =?iso-8859-1?Q?x+uniu4RvoA6CeQyXLtiU6CHG+W5x0nc7JXpRHyWimKzzD6rJDKkJb7Fe1?=
 =?iso-8859-1?Q?5gunxf8BcCHVFPl1KxuLTrFfOR24xGik+pxi62+1GQLRWe2HwoZzOqlG4+?=
 =?iso-8859-1?Q?2A/ZB8VImxhx5q1GIpjnl2anLDLBeYdMEfFDDjXVT547oPGzjzn+2vQEl/?=
 =?iso-8859-1?Q?FhgTC2AilJ8lEg680e5rekG2qxlHMKxHNvSSgXjMYKGX0YOgmKw24IIK/w?=
 =?iso-8859-1?Q?yStEx6mueEUXE3akyblrKTc1L9EzKV0kR+qJoa1bjQub+9GZzvma4hx5uI?=
 =?iso-8859-1?Q?SnU6/b1ca8LyCuDKXn310qddn+BslrkngFqymp+x6doT+b5PuFTQgRmNdb?=
 =?iso-8859-1?Q?w1Ii8wF241S6PwaaWRCEsZi2fX286EoR7eghxAkdNfz+aASlX9YFZRLTWK?=
 =?iso-8859-1?Q?iA91T4QywBYUDnGUH7Ci17j8Q4y5Mr/g10HokbP9nEyfIS5D0lREHEQq9C?=
 =?iso-8859-1?Q?FEgaVts1cMRpGrTCB7XHDkPaPHxyWFC6goYqsNVHJqgsc5GF5d0tItf5Ap?=
 =?iso-8859-1?Q?4m80Zc7fd7rEBj+pl3dyqr7MOdqA0TwrFajooNg4K/k7oG7rFpg6ADmlwk?=
 =?iso-8859-1?Q?0BCV0/BkbEeN83APstowzjJu/LOXieYLw+RPqSMmZ8sNSnLM7Pm3co6N7d?=
 =?iso-8859-1?Q?16UGm8T730JEmjPyAee7g9fYepRvwYsxiwXlSKkUb1jm4v9Aws/27ERDWV?=
 =?iso-8859-1?Q?z/HSCM75XVQLxPPCEDcLvs94OYZ6/M6fPKRL25N1eSB40hq9eIeL4A9bjm?=
 =?iso-8859-1?Q?lgvkdaGFC4Tq8Dby5qE0Kzf1Zj/pv+uOC/EzYOkjkyVr96ie6ytgq5546u?=
 =?iso-8859-1?Q?C+3CpGRLggk7WX0zoR74iizjaZ754YxjAf8wvez2qYKC886q1gAEfxeVyg?=
 =?iso-8859-1?Q?sx6vfOY16A7X+9VP1DEh8Mi8DcjX3FLYI2+sei4MwlNJDJI4UIOmavo/Bq?=
 =?iso-8859-1?Q?tMU26GdasegQ2yTCOpr/ayWQ7FMnyNHn7V84ALDmXSj7P1M+CpMBgeNJuO?=
 =?iso-8859-1?Q?YhXw4Kr4ClI4IsXRjjGakTsqIN+L15IbNXFSJqx6NmcLyjDqUQNWiR8tip?=
 =?iso-8859-1?Q?mm/eut6a+PAl6badwzt5b+M4iDxdn9UwTb7ueM+z7QDPguKlS3iynIaTIb?=
 =?iso-8859-1?Q?tl1BLRM0lJfQ9vmz2JBD8qcq31TUBJnxQ65tIeuRg33o7Fh6DkbFCyuZ1U?=
 =?iso-8859-1?Q?6nQtsUSLTyWkcn3ia83lt/Toc+dH74ElamA8drtM5XwtZy4YtPZh2It89Y?=
 =?iso-8859-1?Q?zU0bUA7OohNBgZWsOTbsaZme4P+7g1+KQX1omww0hbxFapd7g2RdBy8JPB?=
 =?iso-8859-1?Q?4GFvYpvk+4B24SAvWhoNfxX/gLsx22po93yLuX84vEOnbI85cGowEOANs0?=
 =?iso-8859-1?Q?FZ1oEXz16shouCK6x+rVyD1QA6Y7WPeTpYBt2Ed5b2IxRP43scsUevrhNX?=
 =?iso-8859-1?Q?DEqAh+KTgKixgqjZgcmAynUmfUPKdNDRquSissE58l+A=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?83SHEnBvnrYm4d0maDrXfZwy64TwRjXKkgMmtHwd8ZhUwo8Gt7ajROzIJq?=
 =?iso-8859-1?Q?Z2RP9L5bUfS94Hgq2WuO9o2cmKRuGKR1GltthLmjXvsmbdVYRmSaDEx0/P?=
 =?iso-8859-1?Q?VOEqxVuPQUq0tJSUkoMJnQaWQUltotupPtpfMy2hYZILc24uw/PreM9MQo?=
 =?iso-8859-1?Q?Nmuqd+a8V5GVTLm1ff2qnplsZNrJ1BX7QLh1zDVySvwDCVTWAz6J/k06Hi?=
 =?iso-8859-1?Q?J2zNufn1HSdM7q3qMdU4hUc+JTIihtZOFZvdJw6TwBqhl0gSDdWs7BAfYJ?=
 =?iso-8859-1?Q?jVpEL+T/Qrhd9JxX4EO4GntjDiSgu6Sdt6CS/LU07a69QxUwYSmq/QbPVy?=
 =?iso-8859-1?Q?+DScujj0zrNKVZmXHPcmf57eENHEk0urFlzpfQL1ymuGoZIuNe613zGbe4?=
 =?iso-8859-1?Q?LOe+b/xlnAfS/LrdCxIGENqaLg5qSz2S9USN7LT+BAmGWlc+EPvYUtsNXS?=
 =?iso-8859-1?Q?+M7Zq0kmL7QcOOP3ieGGIsrnf/QUL244zV3j4nTMjMHTp8970JSXKbT5Z5?=
 =?iso-8859-1?Q?ZvfEx7x1JdVBC2RSiPjiUKItiap3ZRzJctc+OlBivd+USTogJ02RAk9qrE?=
 =?iso-8859-1?Q?QixVozUIENztrPG2nZ+2OC9NV7OuifsR66S2lkJswpmnsIOTaJdtH/W3/5?=
 =?iso-8859-1?Q?zWjMpLjjdD1tqHi20quDADSsyqH7X8U4OkXEPADFlIVspYouH0zXGvezDi?=
 =?iso-8859-1?Q?zALcT6Sw5f288Yrhel5dlJQP1Pz0Fc+8Emn5D7nozZs3w/r8gIf0idjqin?=
 =?iso-8859-1?Q?kxHXQ5LD3vHljWCmoImJGsrPLCdi4/HhL+peNge+YslI/UUQZgJJc4403o?=
 =?iso-8859-1?Q?qysvf3h4OUpKmm53Mg4kIv9/sb1H56W51+YoRRcKfd2FePxpK5aC5JW8co?=
 =?iso-8859-1?Q?gSJiGCnIi4dhDZydOuBJA/zOTBsjdAUapEYpHQf3gn1aq8N7tTxlj7fhNR?=
 =?iso-8859-1?Q?WaoWTVY1NYCATF1fjrlzrgNSWGbXxIICGCE4nhxeFRJoZn54un+HfyEAnX?=
 =?iso-8859-1?Q?aHmETRXm07082q9SAn46eJBl1cbxD0JLTtrUGKC4epNTl2boT1acY3Zdm6?=
 =?iso-8859-1?Q?VHMVfrQA6n9xa55M6YofrCuxsF/6VUlj5Og79AUyT6tFhah0wteBMNn9qa?=
 =?iso-8859-1?Q?cMVyighzP/pWmBROmswuJuxuqadbQNUxyowwI6yzENDVHw/ShsYfLad9PT?=
 =?iso-8859-1?Q?p+8F6YLNR6Unc2otbz1iPVA6cHbYXrWRyhvAldGoCjwH4G//McbDQ0QPw8?=
 =?iso-8859-1?Q?Hj+UHM2AxyzMOCkMFl+iF3JX3gu2N7vMSl4VawS7IJ0OBxGTPIPT5/6X8v?=
 =?iso-8859-1?Q?nfDVzsE5s3KgAI9RNX5dW5ZsUlKntL32J+ZnXsIcF/ZHHh3V6uZNyADb8R?=
 =?iso-8859-1?Q?n1UnvnVKrrc/T81VPVK1DWV0K88+ka5fVL+1QKZfWAMn+oZrzZFy6ekQA5?=
 =?iso-8859-1?Q?Hu/zYjL+zr3emDJHI/esGhsNwJY9sj6UWWCeNQEQXuO+BoRhuJUJcyfGOe?=
 =?iso-8859-1?Q?3j2GPWdbpKFydh27RNBqq/uetPhjydzpxicyOlrsfWVjJe+eqkQWA1xDF7?=
 =?iso-8859-1?Q?CyCbJsWitLFuAc3ZOIy+b2LZYgIAnNR4+aeM+M7uHEOjzyjVuD6Tuysl1z?=
 =?iso-8859-1?Q?dhKh8WV9Cz4glu7OggmU2S5FZ1SAbkVjlpnRCMWy47UKvmh66127GXnQ?=
 =?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: 80a28292-0cb3-46c5-f841-08ddf6ad35de
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2025 12:16:34.9888
 (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: KqegHt7Xic3y2SaZSJiZuU0LZLeaywkJmkYVzP0OOgDxz0QdclrEEFSmBZqERYdswhh8NHb3c9MKbbiOEQHVlg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8720

Implement XEN_SYSCTL_CPU_HOTPLUG_* calls to allow for enabling/disabling
CPU cores in runtime.

Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/sysctl.c | 67 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 32cab4feff..ca8fb550fd 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
=20
@@ -23,6 +24,68 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
 }
=20
+static long cpu_up_helper(void *data)
+{
+    unsigned long cpu =3D (unsigned long) data;
+    return cpu_up(cpu);
+}
+
+static long cpu_down_helper(void *data)
+{
+    unsigned long cpu =3D (unsigned long) data;
+    return cpu_down(cpu);
+}
+
+static long smt_up_down_helper(void *data)
+{
+    bool up =3D (bool) data;
+    unsigned int cpu;
+    int ret;
+
+    for_each_present_cpu ( cpu )
+    {
+        if ( cpu =3D=3D 0 )
+            continue;
+
+        if ( up )
+            ret =3D cpu_up(cpu);
+        else
+            ret =3D cpu_down(cpu);
+
+        if ( ret )
+            return ret;
+    }
+
+    return 0;
+}
+
+static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
+{
+    bool up;
+
+    switch (hotplug->op) {
+        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
+            if ( hotplug->cpu =3D=3D 0 )
+                return -EINVAL;
+            return continue_hypercall_on_cpu(0, cpu_up_helper, _p(hotplug-=
>cpu));
+
+        case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
+            if ( hotplug->cpu =3D=3D 0 )
+                return -EINVAL;
+            return continue_hypercall_on_cpu(0, cpu_down_helper, _p(hotplu=
g->cpu));
+
+        case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE:
+        case XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE:
+            if ( CONFIG_NR_CPUS <=3D 1 )
+                return 0;
+            up =3D hotplug->op =3D=3D XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE;
+            return continue_hypercall_on_cpu(0, smt_up_down_helper, _p(up)=
);
+
+        default:
+            return -EINVAL;
+    }
+}
+
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -34,6 +97,10 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
         ret =3D dt_overlay_sysctl(&sysctl->u.dt_overlay);
         break;
=20
+    case XEN_SYSCTL_cpu_hotplug:
+        ret =3D cpu_hotplug_sysctl(&sysctl->u.cpu_hotplug);
+        break;
+
     default:
         ret =3D -ENOSYS;
         break;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 12:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 12:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126022.1467729 (Exim 4.92)
	(envelope-from )
	id 1uzDZ2-0001br-4p; Thu, 18 Sep 2025 12:16:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126022.1467729; Thu, 18 Sep 2025 12: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 1uzDZ1-0001bi-Vh; Thu, 18 Sep 2025 12:16:39 +0000
Received: by outflank-mailman (input) for mailman id 1126022;
 Thu, 18 Sep 2025 12: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 1uzDZ0-0001YH-5t
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 12:16:38 +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 52de59ac-9489-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 14:16:37 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU0PR03MB8720.eurprd03.prod.outlook.com
 (2603:10a6:10:3ef::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Thu, 18 Sep
 2025 12:16:33 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 12:16: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: 52de59ac-9489-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cGTQNHIOBgp8kr2qc5dOGEo3lO7RxOMGvRmM3amneqGXix75X0b0kzpalfuGwrzcYb11MGUp3WzQA+X1yCRXXlNTACZJ2fFRwdbF8+vXgCKLtEeCdayZPQMpWrgddxW5Ok7SgMTQa8czae6i4vP6v7NMezYTVJYy1+ull5I4XGO14pGnZTT8ferYIiBwQMmh+1TPWkNwmc0Z2dhKNyB1/vSwhBmheAM0w2V4/Kz9XtV6SuwFQnHkUvdc7ME2KCr9q0rJVupgdYTwEJjrEaAy3hKATGBlAwirnmM2f7VqkBb9mo2c2m259ayRgx4HGeeOpnvk/I624Z+0H4u7d6zYuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2sennabp90pHyVkqi/NAsNLhiu8Ito5EffSRJtk0ARQ=;
 b=qagio2egHXz328i18C3cYqI7K+VdtHPCUaM5fCsgk66y4OldAf1zcxMm4ZGv0tgqxmY/4EvuyogIgXzumXQKtvnkDuY7mrExfg8h7hXymQIJTwbASFF1s+N9OG7b/pOKBdcUs3GcV97qJZujFLnBz7qqAw+lSQAJkXXf2ADQwVVCALgvUAkPjGgnXv1aZSmDZG2VSVzzAZUE2Yq/gSSzNsdAkEIfIePnLonJxfYGbbQR59DbxiS/A4K4rt2l9tIFC9e2N2FTCcvp1yQjoa5PwZl4oNa3LM8kEXWXl7zYp8mvRwbA+ktDWVECWJEMPFcbxPadrkt07Ng73TlfnTURnA==
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=2sennabp90pHyVkqi/NAsNLhiu8Ito5EffSRJtk0ARQ=;
 b=U/L7aHQsJOyikmiu6uuKbNHvwmCpGJJVL/7vLADHPzauWVbLBB8xI9iCobxiTnRP7tufzXPJffqXGXGtqUbvb2G19XrjHZjgbeEazAGvdi2lU6PEQ869wf3FdKrwcxDv1SeO6EUXdg1XPdUGI0zUVlyVlLstal3VzUJpkgNY9wHl2yKCw2Cd/aJQN69XRcKYamBV4sFFl0VzE74xB/vmcN8XYtheshEhJIbnBljSapAGJYgN4ONwtPVnoOXuXhDUpTAkfv9jU6jAL6i9hAC0+2FOvuWugZS6Cg5Z4kfnuwzB6qySilzM3iiHhoaVW+0hx9Dxv0jZJbdiIzmD57flFw==
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?=
	, Juergen Gross 
Subject: [PATCH v1 0/4] Implement CPU hotplug on Arm
Thread-Topic: [PATCH v1 0/4] Implement CPU hotplug on Arm
Thread-Index: AQHcKJYSskXGqEBZlUi2OIJnUdiQ4g==
Date: Thu, 18 Sep 2025 12:16:32 +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_|DU0PR03MB8720:EE_
x-ms-office365-filtering-correlation-id: 250c0179-65fb-4382-337e-08ddf6ad34ba
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?sxeWfBQNHYiN3Ls55c1Ny8XP39lYt0cIysBwzgj3LOaeM+1QDb3YFIKrZ6?=
 =?iso-8859-1?Q?PQrKgaC2FsbrFqo1PIlnNToyG1BH/35cKhuDtCStrBwwZTKmI3gAXeAJi7?=
 =?iso-8859-1?Q?yW51RtnZA66kaCMJaYhIw2Fu+z6Mob6QvtQp5YEpNNPQAWYm8jq6MhQY75?=
 =?iso-8859-1?Q?acTWxNjSj+ZDE+6Z3PVQ7hv/714GfGj9djaJ7wo6rtpPktk+dF0YnlFipC?=
 =?iso-8859-1?Q?33OK/b9CaUFIjIPbrKPg72t4jdP8aAMR6aRipLNa95b4pgPbt7xCBiS4ah?=
 =?iso-8859-1?Q?CVF5RNZ/K/Rs9fdxCD85ma0ost7Wn17a2I95jASIS7E4AK/nVxj0XumDws?=
 =?iso-8859-1?Q?vz3Ojt+a2xz/IWAsz9wu8y0sCJwhPKeJgUfOLTSoLap58SerOH0ungiqCC?=
 =?iso-8859-1?Q?JsSSHl7iGFNzl+NkPj74jtKVFa6TsOUNb4eETrdm0hpsCSUeh3rjJxw1bW?=
 =?iso-8859-1?Q?qKVM6MGr/MbNTOQtKiSk53Pm4CQBJJcl2rMbn56vQXwvD+UZip4pj5R0X0?=
 =?iso-8859-1?Q?kL1sn/VUzjBjExwNnltsSE5TD9eMPXUN9Q/0DWU8KIodSaucne361SSbTm?=
 =?iso-8859-1?Q?B5gT6Ur8ttW90SNaXPzTmvtj562sAXvPUGEFDLTG2y8ZqcSxtnAuMpq/On?=
 =?iso-8859-1?Q?zlTGQbFvZsNjWPGLrzqevAc3nFB0IKbMT+xSm19aiNFHB9HQNM0jAfvKS8?=
 =?iso-8859-1?Q?G0yzTDug+yYXmn8nqi+QJBuQsbIMFJDjJTe9yCS/ov1m6VwCYuvWErkdlm?=
 =?iso-8859-1?Q?0BMvyS8LsHC5+d3JuYgl4W8Ycb7kMxDlsxB0M3z9OCpTJ/X7lx+VzHiG4+?=
 =?iso-8859-1?Q?MkCGz4D8OnK6Gd0qXZNV6IkljAgCmuX6+Ng8sTFhjZyCUZkVhW8gLIfsZd?=
 =?iso-8859-1?Q?Ndl6asXmNkRvuaD7mMO5JYc96o5JVkWhph1eoJldxxXCp6Y0t0vsCpz1hG?=
 =?iso-8859-1?Q?WRXSEt08nTpr0+eBVVXWh99J7k2XJu2frsDMDop2pHwAM6EBOrGVb+gC25?=
 =?iso-8859-1?Q?1EPc7uSx7bBIm8E9M69/z96jAAHFPg8+g/oK4eR0Yj/M3fhnwkVMOIT/2b?=
 =?iso-8859-1?Q?LUE37OIoHdkqfloNtSGsnWYRGgC05Ek8fGrGMNDg5IF5P/JDRO7/q565oj?=
 =?iso-8859-1?Q?JxAJNG5IxKJqxdt4OWdJ6nXBOK8CK8T9uY0pFXvCl8Jrmai7npDN14yNzi?=
 =?iso-8859-1?Q?pK/dIAehPRwonEuGQfK86+oIik+YVE3U/JAiLfaQ8MTm9vOKH8DYq1Jo+h?=
 =?iso-8859-1?Q?OcGUU6EEgcFq5oP1q1AJyI1YHq+KuZ7ENHq9pMfag6CnD+WT0GA8yV6G3W?=
 =?iso-8859-1?Q?kQRAwrjsq9vsQ33BciDYSOxNMWXmo+pNN5CPiEtwzaojDvLRpr9VYhPqw7?=
 =?iso-8859-1?Q?Tx6MW2jmXpO0l1r4x3QkblMN1Vwjq03OFVFXeWkpTg945Qbcr2xzddWwhk?=
 =?iso-8859-1?Q?3acU5IQ0yXqHNHC5l4482fCSZkKxj1f50neSpB/b5v7bqua6nxXEp39gr4?=
 =?iso-8859-1?Q?YIP4DhSpCvvVIIrp3vFKV6ei9r8JOignWUskvgCpN+5Q=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?U0i1rzqJZakDq4dk1Un69NvvVB7u+1XNVMQT0kdae3+XNgjDeXj3gr5fxU?=
 =?iso-8859-1?Q?UVJeNH1PNDJ6XPWTduz4qbRKAeXYEWvSBESykbGlgjUvvKMfVS/rkOObXN?=
 =?iso-8859-1?Q?+Yb6FvlnQtBabTXQpyGepjljYZvSNmD94Yx09MtBUb0Pu1xrU2T+MOLKzY?=
 =?iso-8859-1?Q?AWt3nGX1aSlwI1FH/HfqPjAYqngcyD28lGUStOrK5L3QRAHuGMaomDSc1i?=
 =?iso-8859-1?Q?eReb7f/IBxaJAUZzCwTiNgxAPfkPlm895Gba3PatuFzvfBFK2PF0ZscqUl?=
 =?iso-8859-1?Q?Bs6yQnvzwpabtMmQJ/ofXILhwRrp1hd5ZySPQTmIrDWIlKIcZKpe/N25cB?=
 =?iso-8859-1?Q?cT3vZaq8LDfHu82oNJL8RcJBLlFK49bPcRA3iUhB6VcNtdBMBa81TYASIa?=
 =?iso-8859-1?Q?/0GtHWUGvjhoJqLPrHnkyQtnw3BIgPqx+EX/J30UcBQBRA0PCnnqDuLrri?=
 =?iso-8859-1?Q?xyDQo3emz4PGvBfPb5gGN3M6xCIQsynBuLmDQSEVKyKgy/26kI6IJPcRBJ?=
 =?iso-8859-1?Q?+AZ+HrNw/1Y3jObPJUhwbN87ubfZ/tzXZGGVE55ufYoL6UKBpJQ4C8Cmik?=
 =?iso-8859-1?Q?I/rbPS3MsmhWsRViMDNH229ui4aszUh8g+4Dyh/BDSpAxClRVBXLdb2sD5?=
 =?iso-8859-1?Q?NtL5vr/w5OmmVCh3Gw/PIE5afYq7nPVzIyACEOrdjL13tLqZp5dgYPgoR4?=
 =?iso-8859-1?Q?ADxAE+n22geOaVh+t5GkfWQz6Mlv3HbHSTK9PeX18oIrUyjoXbneSrJlG2?=
 =?iso-8859-1?Q?q7Y962KGvA1KXVS/c7sk0K/P2PIiKX25k6WMDKgPFNrT19IqWk0SJrlVg8?=
 =?iso-8859-1?Q?BJKJPJWlL0U1HAvP8Dsa/fbbWhk/T1Cyxguc8HMcYmiGq39OoqYmGVV7aL?=
 =?iso-8859-1?Q?1lrgCZORTCYO4vG/adC2FjaWjd3B5aUxjczQzYLzbokV9hikwcctywhqAV?=
 =?iso-8859-1?Q?S4jPLi0H3BJLbEJ6YY2/CMSJRRMPNy6BlcRuN1XRZUSEZxeXpJF7+1//FT?=
 =?iso-8859-1?Q?Yuf/w3jMKTpyVYutdDKc4O4DnlKdu40J1f27ARAQ7kOrLEO9UWlfDgdyTH?=
 =?iso-8859-1?Q?bWd8VasvQUxq8zR3fZJCGh15lu6JQyGVF9uFOaz0jCOkrl/z22D5dDhne9?=
 =?iso-8859-1?Q?KLYAaKYW9of8uUSn4+ub4n40jfSxqHCkkXE8OS6qK04IND49HMl+UxvS3s?=
 =?iso-8859-1?Q?dYwQfMnAPTN3NqBT+FaKN05uucNM+x02xeP3Npsyd1t+NjMIbgQLyhRpq4?=
 =?iso-8859-1?Q?caa47MLOgAoOnGSmFOp7FNsKtaedMCJeGXeMKTwJEC72bX7CEdhXS63Mp6?=
 =?iso-8859-1?Q?dOwVgkwumXqiwRwq3aMm5yRg05u+LnPavNkXrugukwbLfx8bxBgaWocbKe?=
 =?iso-8859-1?Q?z3wh7yRo5mJghVWI3cPFoH03XauEGKXfhPQ/ZI+hVRFKmcuP8d/ehnaCo4?=
 =?iso-8859-1?Q?COZEptyCReN3Ljkgk0WWwyXL8Tw7KhYGhIKDht1/mXJWyXNft6rIShFwNU?=
 =?iso-8859-1?Q?u7ldYIW0yS70zwPIQEtbuvE0Yr7FvBytWMYnIVN8rSJ4LG4YDvLhJKZ8Ej?=
 =?iso-8859-1?Q?3ds1ZPbatpmdANs54oPSusvYhcezlGEBrpSzakasId4cDywlH4j4aSKWjZ?=
 =?iso-8859-1?Q?an2rrHbsmJ4UdD/L1lwB+r9MhSQC4K0xp2?=
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: 250c0179-65fb-4382-337e-08ddf6ad34ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2025 12:16:33.0821
 (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: fmmH78YRgaJYYKwKETQ4pWklYspMFlVO3jSmG9zqVMIbDydrcJPTjlqORGiqHQ+b+XAjQL1LqsxRzPH1r1vsqw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8720

This series implements support for CPU hotplug/unplug on Arm. To achieve th=
is,
several things need to be done:

1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented.
2. timer and GIC maintenance interrupts switched to static irqactions to re=
move
the need for freeing them during release_irq.
3. Enabled the build of xen-hptool on Arm.

Tested on QEMU.

Mykyta Poturai (4):
  arm/time: Use static irqaction
  arm/gic: Use static irqaction
  arm/sysctl: Implement cpu hotplug ops
  tools: Allow building xen-hptool without CONFIG_MIGRATE

 config/arm64.mk                  |  1 +
 config/x86_32.mk                 |  1 +
 config/x86_64.mk                 |  1 +
 tools/libs/guest/Makefile.common |  4 +-
 tools/misc/Makefile              |  2 +-
 xen/arch/arm/gic.c               | 10 ++++-
 xen/arch/arm/sysctl.c            | 67 ++++++++++++++++++++++++++++++++
 xen/arch/arm/time.c              | 20 ++++++++--
 8 files changed, 98 insertions(+), 8 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 12:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 12:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126025.1467762 (Exim 4.92)
	(envelope-from )
	id 1uzDZ6-0002TD-0G; Thu, 18 Sep 2025 12:16:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126025.1467762; Thu, 18 Sep 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 1uzDZ5-0002T5-Tw; Thu, 18 Sep 2025 12:16:43 +0000
Received: by outflank-mailman (input) for mailman id 1126025;
 Thu, 18 Sep 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 1uzDZ4-0001YH-LI
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 12:16:42 +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 55b51d1d-9489-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 14:16:42 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU0PR03MB8720.eurprd03.prod.outlook.com
 (2603:10a6:10:3ef::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Thu, 18 Sep
 2025 12:16:35 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 12:16: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: 55b51d1d-9489-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DPDsVc+eDVt76bCHLIid+pppMn9RI5e0/Fwy5gq6aEiFWsZueC9NVFkfDmEO6Y4hu0g/eeRSNM+yDLXeHiToKWy366fNxF0ScTS22w3hzJjk/DWYTz/cH6NP9nJ2eW1cZ8XZgaHsQmuNbBRq0K+X9lKjl2C3FHeLKm5iQzwVf0IWJpq1KZEnxXlXUCzPZNVdmgPj5MgRlnjPwEbv+s2BCjlohQiGRn71yAye8zvqnmN3L97Vcfp1D93j2shqYq/Z+lwsAZE9TVNaurilQj5rwNydL/4kfuEknJj3AvIoytOx8cuAsBU6442rlajau4b0MSni4o8ELbl1mSePhqEO6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=reDYiedqoZNI03qhIvZun1ctpUFxzc7JosMbd9+r4uE=;
 b=IQ3YeTiUDCEFSx7DeDI12MJQhS7vkG7px4hSZ0/L0vOLZ4X5+ffyqAGPy910FYkvUH+OMfZNubDNVS6trgZC4F+Bc5VjoonsHhk/QcrmuojLfdiZKJOaHpBBWzFHhYHlQGUwvZd+o+gEqTDCH/2dFx3pLebrBQvPB3epYqWLvc7DB0+p8dgWsbqJk/Tup0s2KPk883z0fo2LMYnVjlv/7n4biAlOHtR9soU3Lg2MiyRQQMos3G3o7bn4E3uYGLL5/LrPzKbqi0Fl+USk5ernXI9C6ZbxGckHllJ7Xeg4JUA/i1mVoAOIO5EqIZUuw7RXhgfk1fMQkFw57v/6hNVA2g==
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=reDYiedqoZNI03qhIvZun1ctpUFxzc7JosMbd9+r4uE=;
 b=HYhHi1yb2BpBcRhsRff8aplFw7rFb6R3/cPBAvYIlinGzzAs5CATqA0z7GN/tociu8ZOOKfcKJg4IHau0JgQKsUEMEYzMy8mJ2UHHMQRJaKINApl6frtRs6Pl8KdWpMbnzQ6naw6pBz6XOZkrC1bX2fUHycj31MH94eO8hNWGfOuEIHjWICrMc7aku2hpOj4Xo2nEIwB5itAgFDKnTn7EYmRccth4MTKWP5xfhvmLNpKStA1NudFCju9ZBV24+p8uzK9aeUFPCi12uLiuolepKfQR9HxUC4tlPTV/AekOTzG8BeG0q7VzbzlEtMUu8fP2mlnPFZ9IGjqujokNoPN0A==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Juergen
 Gross 
Subject: [PATCH v1 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Topic: [PATCH v1 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Index: AQHcKJYT9WcJIkqhZk6dQ6fXEj6SxA==
Date: Thu, 18 Sep 2025 12:16:35 +0000
Message-ID:
 <7d10f4d063a55920acbb8d477b885552379a6116.1758197507.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_|DU0PR03MB8720:EE_
x-ms-office365-filtering-correlation-id: 88da5d1d-48e1-45e9-c3c1-08ddf6ad3637
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?gU8UOtsZhsxsAdKxfAtXKoE5Kof0SrAktB+9VnxpdDx0sXIueTmiA62x7F?=
 =?iso-8859-1?Q?9ZPx8thfqOm5fR5zeUn26nPcoR+1JK0VRAqHd+JeRwMZCTKkU4o/8hobKf?=
 =?iso-8859-1?Q?LEGbkBmUY+nK1YH0mnYNOHDFz2TJwROX6S+tBQxFHcA3Mus4JuMKlhdMj6?=
 =?iso-8859-1?Q?pDpw2jZftiynaS31T7Fy6mmC1uEQMRLk/6DdXxiNetfBbcnnCsUR9TWzG1?=
 =?iso-8859-1?Q?eGMOlCMYsnq6EYKe5aWPShopIATeOvbgo3DGlEjMvIxhCUDF+Q7RKJGHBn?=
 =?iso-8859-1?Q?5H5IHJaVN3Snkyn96KUSWmlsxXGQxBUzL/zo0ygeUObLFFAlk5n2iLctTz?=
 =?iso-8859-1?Q?WAX2Cj/l3q7ieidXxc57pe9AIktevEGKjaW0GDrX89I9NCPjTWya58PYzY?=
 =?iso-8859-1?Q?QCxd8FfTIWQd2dGqfy4ZrFEZpLR0fkn+nAX7PPgDCE43fSw+oDzqfDK1AU?=
 =?iso-8859-1?Q?3zNgG2KA/yAqKbkJoRTrJtUkxwfBsVyyFsNCWswK1e+G5KWpNz2/sr1lyx?=
 =?iso-8859-1?Q?PxXHJO39rYOG4oUgVjhNFeiqzGzUCuysATfhfeEfaikp6eUWI+IQHwNFs9?=
 =?iso-8859-1?Q?TPqdYpnA9jeSvz8SyJQ75nHQUh8IyXhxFObxQc4r6V1oWImwB1g0Tu7PXr?=
 =?iso-8859-1?Q?wCsbu99/kL9/2VR+n3PSacqHmwh7U6LlL3HJ2MdU+2i0vkf3lh1r4heeCu?=
 =?iso-8859-1?Q?MjZRs3KHG484klZkxLVIsE+u1RzGrT2P38iTBMgMd2rwgIqIHvwOsARWlh?=
 =?iso-8859-1?Q?9ZM4CvldKN/cmKdsqqQGuIwes0EOJ3jk+OOIqNfKxzWU7aeGB4UAC7fZkI?=
 =?iso-8859-1?Q?zWgjp9k+xiQUXNPAx3U2NlQQZd9zqUOM9S7A5oiPN4gDnEOuBZ51TMm1tg?=
 =?iso-8859-1?Q?l7nhyoO3r7kr9H40E8Av2cljrlA8QlKlCeDCBeYJkibpqh8abinjoNEw3q?=
 =?iso-8859-1?Q?oi3rfhdzP24j+iqhPcSHdc2HI8vDiwmf/qJaVxhQSigs4IcEBkvgL87j3M?=
 =?iso-8859-1?Q?ag8PZCzvsQR95rnQCCLatTSsu2smC7LHiwHz56vZKQf9A+f8fsx+9YnAgM?=
 =?iso-8859-1?Q?P0Z2O6BDsawOQfXA9nW3UZ+R6324reyJVfyj/kUhpdKnjxx7Rts5w5MfJF?=
 =?iso-8859-1?Q?IT0+7pIABKF9/oEks4UchRXweUsItF4MBYRaVNkuZr6418eygYv81uCu/Y?=
 =?iso-8859-1?Q?O3eRMgcr6jI3qwztCj2SrUEsXjSD+/2N+O3FsmSZMFExDvBsjlteAnUQR5?=
 =?iso-8859-1?Q?AZNXbbBqcZ5U+YDkFnWVvkHaaByRaiZ5QuVlkmKhnEdgnjAcfu0MNLYhaa?=
 =?iso-8859-1?Q?wK3znByd7lYmO7hXUrCLDCi6R9Uwdj6ODELqD6b7jYvOcMt1Dnj3XIETBp?=
 =?iso-8859-1?Q?Tt7h1dpYmn6Iw1PRrugzSYv2exFN6WSmQeK5yCajhxHGthKgE8WTky0ASn?=
 =?iso-8859-1?Q?8i2/6GHA4h0T7drRmvyvYanXBIj2elgFDiTlpcKtYUjAf5ES+UPZuqJDSk?=
 =?iso-8859-1?Q?5ujCNSxor7O84kWUPbX92eHL3bm9IxPsumN3AB9aPenw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?dnV6VChZr/8hH7dCqFUYyikaQ4x8ze5rG+vYvnBOfGP66u58CN7TD3dq9D?=
 =?iso-8859-1?Q?6T7wLmzmuGW+RyNErxmKLK/At8wfD6hnNXvG3zQ+ExJ8rGSk7LAVvosJqN?=
 =?iso-8859-1?Q?1lkGsGPPwBFe5U0frLTB12qdBhsdjhnprHh36pR6kaw1rTAN+xVwRjOLys?=
 =?iso-8859-1?Q?f9bc0gNofyuB3wO2gwt4qrOGZxFWnOlSG7LNsiRqRjGj+Cb1PSwJwQRRVe?=
 =?iso-8859-1?Q?5t697cozgLfDcj3m4+Bb4ezhH/+BqYmba363mxAcIwPk71a4Kr4MFdlHwQ?=
 =?iso-8859-1?Q?6dB3rdHFC65rCIApj/75VTUE7YWjn6hHeuDlHyvXM43qAjhENI3FcLi1Ki?=
 =?iso-8859-1?Q?X+RyRO8mXa+c/QzAy9eQ4uLdjeHqQcUl1lj3TK6LJMwyGac7Y/zgMsP5bA?=
 =?iso-8859-1?Q?eyA/Gaf4p6wQrXdYjD4LvSdQPk6nRPbLLmxHtBjdhqYK3f1ikbGtw89ve7?=
 =?iso-8859-1?Q?uiL95uC1WECofU6L4+FP+OjMCb8rh+YUFpoLFECvVroKM6zWwKsHQxQ4iA?=
 =?iso-8859-1?Q?N5+gQkwuIRpc7w8ZzZ8afwS+y4OGhrbeDGBYOj/KMOBrgaLhKt3b3eTH/+?=
 =?iso-8859-1?Q?pJEPUEbSJMIWdk4C7YjxpFxj2mmmV70rIP4ja4aJvcL6FWc5XFZU9+eTRm?=
 =?iso-8859-1?Q?vOlJyJtL8m69c3JPv4vjOwOZA5+WtzLbxwSwHwXuSj3KOPvpIv1uLeXbZa?=
 =?iso-8859-1?Q?EspIx2x5vYCycJmv/bIo6mMuuEZY76aZfQEDDclKwvWo52pGAE/C9IVAfW?=
 =?iso-8859-1?Q?vl3XC+10uEFw8UJsZoNAmQf+N88YIti5KtkPXv+mpdgj7s8pnv4O/hvmj9?=
 =?iso-8859-1?Q?hrDfmWgXMAtstz7lv8c8JH8BCmJa6lMFRkOW7huUCvVvrZLRSqPEoa4Foz?=
 =?iso-8859-1?Q?XRZat3bgHrTF6EOe9HAFiGQihRsrE1i9zr4X62i2V95Bb2lq53dd8MQ6jY?=
 =?iso-8859-1?Q?A7MiajKEZ+JalNmHwuqeKw0dxxl0zPRAppY2DnXTu3c7Cftd5YTwGO98Bm?=
 =?iso-8859-1?Q?pFL34vUPYRCiUWbO5ig9i3+37iDAuwqMkgVLutneGcRLn8CZC/MdXAa34X?=
 =?iso-8859-1?Q?WDfLc1xAnHv69Wdjy5DmrOJy3Ddl5TdaexLB642y+M3eOVK98jBiC7NMvF?=
 =?iso-8859-1?Q?REvjFGD89HEZG1DHZPovFtSiJxC4ard/5uBisTzqUQMZ9yxgd33Snu4MrH?=
 =?iso-8859-1?Q?daB/WIVArBBrMoBIX8Bt0NLVGhXhFRcsNJyUNXitQtvyp4NvS+45pWsmcz?=
 =?iso-8859-1?Q?EEVBCDtU7qV0aixGkPJfzP2XP9AG/0zLtHaPiwkhOaNx5xg90IfNAu71c1?=
 =?iso-8859-1?Q?hyGBVAom/otxFCBFHF3o31nD9ud+i/H+1wHj7LsyjyNqUFMoxrcTvSzFJO?=
 =?iso-8859-1?Q?B2LG3u2692edRTyT+wCkSkZQhZVMHMZ5uXALmr/YM68D92qYKNKoOq9o6f?=
 =?iso-8859-1?Q?Z9cHHxNsvpQukVvqlDHlZpAs198WZS9m7PHPJq5U+766Ybmi3esHFWY2Tt?=
 =?iso-8859-1?Q?AgNY2FQTCLEkdiFBT7kzLJHG6u3+sU9CuaqQbKvc1x8zKHOYlUz5Rtz8Dy?=
 =?iso-8859-1?Q?OiPkmNpDSjxjeE/PJhdbjdoYHl7qB5VVAjJSeoYrZ9R7IrtOchdU/FiaIU?=
 =?iso-8859-1?Q?Ome/zPLtq8BfUPYUr6wnmLiUyYgjFG644lH2TxucVGIBCG7QG7/yECNA?=
 =?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: 88da5d1d-48e1-45e9-c3c1-08ddf6ad3637
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2025 12:16:35.5798
 (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: gPqztZdw3cEFfqK3/mMqDsTPavLr47teiUBDCiN/SoVPE3ATF4HYXbKDjhk0Cg+yxwsEjRXWR4HufAYe7Y0ioQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8720

With CPU hotplug sysctls implemented on Arm it becomes useful to have a too=
l
for calling them. Introduce new CONFIG_HOTPLUG to allow building hptool
separately from other migration tools and enable it for Arm.

Signed-off-by: Mykyta Poturai 
---
 config/arm64.mk                  | 1 +
 config/x86_32.mk                 | 1 +
 config/x86_64.mk                 | 1 +
 tools/libs/guest/Makefile.common | 4 +++-
 tools/misc/Makefile              | 2 +-
 5 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/config/arm64.mk b/config/arm64.mk
index c4662f67d0..d4995c8991 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -1,5 +1,6 @@
 CONFIG_ARM :=3D y
 CONFIG_ARM_64 :=3D y
+CONFIG_HOTPLUG :=3D y
=20
 CONFIG_XEN_INSTALL_SUFFIX :=3D
=20
diff --git a/config/x86_32.mk b/config/x86_32.mk
index 3cc046d9bc..0c88862ad3 100644
--- a/config/x86_32.mk
+++ b/config/x86_32.mk
@@ -3,6 +3,7 @@ CONFIG_X86_32 :=3D y
=20
 CONFIG_MIGRATE :=3D y
 CONFIG_XCUTILS :=3D y
+CONFIG_HOTPLUG :=3D y
=20
 CFLAGS +=3D -m32 -march=3Di686
=20
diff --git a/config/x86_64.mk b/config/x86_64.mk
index 8614457b03..25cf965507 100644
--- a/config/x86_64.mk
+++ b/config/x86_64.mk
@@ -3,6 +3,7 @@ CONFIG_X86_64 :=3D y
=20
 CONFIG_MIGRATE :=3D y
 CONFIG_XCUTILS :=3D y
+CONFIG_HOTPLUG :=3D y
=20
 CONFIG_XEN_INSTALL_SUFFIX :=3D .gz
=20
diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.c=
ommon
index a026a2f662..96a1141511 100644
--- a/tools/libs/guest/Makefile.common
+++ b/tools/libs/guest/Makefile.common
@@ -7,6 +7,9 @@ OBJS-y +=3D xg_private.o
 OBJS-y +=3D xg_domain.o
 OBJS-y +=3D xg_suspend.o
 OBJS-y +=3D xg_resume.o
+
+OBJS-$(CONFIG_HOTPLUG) +=3D xg_offline_page.o
+
 ifeq ($(CONFIG_MIGRATE),y)
 OBJS-y +=3D xg_sr_common.o
 OBJS-$(CONFIG_X86) +=3D xg_sr_common_x86.o
@@ -17,7 +20,6 @@ OBJS-$(CONFIG_X86) +=3D xg_sr_save_x86_pv.o
 OBJS-$(CONFIG_X86) +=3D xg_sr_save_x86_hvm.o
 OBJS-y +=3D xg_sr_restore.o
 OBJS-y +=3D xg_sr_save.o
-OBJS-y +=3D xg_offline_page.o
 else
 OBJS-y +=3D xg_nomigrate.o
 endif
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index c26e544e83..64b4d77051 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -16,7 +16,7 @@ INSTALL_BIN                    +=3D xencov_split
 INSTALL_BIN +=3D $(INSTALL_BIN-y)
=20
 # Everything to be installed in regular sbin/
-INSTALL_SBIN-$(CONFIG_MIGRATE) +=3D xen-hptool
+INSTALL_SBIN-$(CONFIG_HOTPLUG) +=3D xen-hptool
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-hvmctx
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-lowmemd
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 13:28:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 13:28:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126095.1467773 (Exim 4.92)
	(envelope-from )
	id 1uzEgR-00044u-Uc; Thu, 18 Sep 2025 13:28:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126095.1467773; Thu, 18 Sep 2025 13:28: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 1uzEgR-00044k-R1; Thu, 18 Sep 2025 13:28:23 +0000
Received: by outflank-mailman (input) for mailman id 1126095;
 Thu, 18 Sep 2025 13:28:23 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uzEgR-00044e-1t
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 13:28:23 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uzEgQ-00Fy4w-24;
 Thu, 18 Sep 2025 13:28:22 +0000
Received: from [15.248.2.235] (helo=[10.24.67.203])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uzEgQ-00GJyV-29;
 Thu, 18 Sep 2025 13:28:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=p0d+DH9Rwrr8mSaj8F4PvpwqI1NpdM2LwEMPJA8zEgs=; b=4/+Zhd70mPi2CdCTwLof0C0N6l
	vQ7LshE8euPJvDZR2fglwJs5jan9FBnIyVX7IAWmzxIwOZl54+qAPlHN6qfO8l2omGdXS6UBwTIZF
	aSMTCLTdC+xFDwx6qVmtnUSCOV58h6fJt8VMDNIRiwLfhXHvSwvyeUWTqxaLEyiOYKGw=;
Message-ID: <65fb96d3-3f5e-42fc-8330-e289bf029246@xen.org>
Date: Thu, 18 Sep 2025 14:28:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/4] arm/time: Use static irqaction
Content-Language: en-GB
To: Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <9d10949d60aa930d6b281824f5879e804ff18918.1758197507.git.mykyta_poturai@epam.com>
From: Julien Grall 
In-Reply-To: <9d10949d60aa930d6b281824f5879e804ff18918.1758197507.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykyta,

On 18/09/2025 13:16, Mykyta Poturai wrote:
> When stopping a core deinit_timer_interrupt is called in non-alloc
> context, which causes xfree in release_irq to fail an assert.
> 
> To fix this, switch to a statically allocated irqaction that does not
> need to be freed in release_irq.
 > > Signed-off-by: Mykyta Poturai 
> ---
>   xen/arch/arm/time.c | 20 ++++++++++++++++----
>   1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index e74d30d258..6f215de210 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -303,6 +303,20 @@ static void check_timer_irq_cfg(unsigned int irq, const char *which)
>              "WARNING: %s-timer IRQ%u is not level triggered.\n", which, irq);
>   }
>   
> +static struct irqaction __read_mostly irq_hyp = {
> +    .name = "hyptimer",
> +    .handler = htimer_interrupt,
> +    .dev_id = NULL,
> +    .free_on_release = 0,
> +};
> +
> +static struct irqaction __read_mostly irq_virt = {
> +    .name = "virtimer",
> +    .handler = vtimer_interrupt,
> +    .dev_id = NULL,
> +    .free_on_release = 0,
> +};

setup_irq() will update the field "next" in irqaction. So we need one 
instance per call. Effectively, this means one per CPU. Therefore, we 
want to use DEFINE_PER_CPU. This applies to the rest of the series.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 13:36:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 13:36:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126107.1467782 (Exim 4.92)
	(envelope-from )
	id 1uzEnl-0005cI-Kn; Thu, 18 Sep 2025 13:35:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126107.1467782; Thu, 18 Sep 2025 13: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 1uzEnl-0005cB-IH; Thu, 18 Sep 2025 13:35:57 +0000
Received: by outflank-mailman (input) for mailman id 1126107;
 Thu, 18 Sep 2025 13:35:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uzEnk-0005c5-ME
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 13:35:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uzEnk-00FyFa-0k;
 Thu, 18 Sep 2025 13:35:56 +0000
Received: from [15.248.2.235] (helo=[10.24.67.203])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uzEnk-00GKVy-0p;
 Thu, 18 Sep 2025 13:35: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=l3czIp3hSCM+jgKutsn+9ltPY+cNP43JxGW/OkrSBzk=; b=330WumM/FodOXMLJ3zk4w66dx/
	VHDUNRghBIg2WM4OEB8XvpDKar1S6BHM7PyhVEjUIDQngzNAb0eaW/MAgUd8VCBU1KuaidvzdMETq
	hp6DtIKr/YGvr1Ji9dmITu3VAs5+LlKbNYfJWeesdMIqZGVpDuvBlGe0ENzGOp+q2Mpg=;
Message-ID: 
Date: Thu, 18 Sep 2025 14:35:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Content-Language: en-GB
To: Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@epam.com>
From: Julien Grall 
In-Reply-To: <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykyta,

On 18/09/2025 13:16, Mykyta Poturai wrote:
> Implement XEN_SYSCTL_CPU_HOTPLUG_* calls to allow for enabling/disabling
> CPU cores in runtime.
> 
> Signed-off-by: Mykyta Poturai 
> ---
>   xen/arch/arm/sysctl.c | 67 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 67 insertions(+)
> 
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index 32cab4feff..ca8fb550fd 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -12,6 +12,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   
> @@ -23,6 +24,68 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>                                          XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>   }
>   
> +static long cpu_up_helper(void *data)
> +{
> +    unsigned long cpu = (unsigned long) data;
> +    return cpu_up(cpu);
> +}
> +
> +static long cpu_down_helper(void *data)
> +{
> +    unsigned long cpu = (unsigned long) data;
> +    return cpu_down(cpu);
> +}
> +
> +static long smt_up_down_helper(void *data)

Looking at the code, you will effectively disable all the CPUs but CPU0. 
But I don't understand why. From the name is goal seems to be disable 
SMT threading.

> +{
> +    bool up = (bool) data;
> +    unsigned int cpu;
> +    int ret;
> +
> +    for_each_present_cpu ( cpu )
> +    {
> +        if ( cpu == 0 )
> +            continue;
> +
> +        if ( up )
> +            ret = cpu_up(cpu);
> +        else
> +            ret = cpu_down(cpu);
> +

Regardless what I wrote above, you likely want to handle preemption.

> +        if ( ret )
> +            return ret;
 > +    }
> +
> +    return 0;
> +}
> +
> +static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
> +{
> +    bool up;
> +
> +    switch (hotplug->op) {
> +        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
> +            if ( hotplug->cpu == 0 )

I can't find a similar check on x86. Do you have any pointer?

> +                return -EINVAL;

On x86, they seem to check for XSM permission before continuing. Can you 
explain why this is not necessary? Same questions applies below.

> +            return continue_hypercall_on_cpu(0, cpu_up_helper, _p(hotplug->cpu));
> +
> +        case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
> +            if ( hotplug->cpu == 0 )
> +                return -EINVAL;
> +            return continue_hypercall_on_cpu(0, cpu_down_helper, _p(hotplug->cpu));
> +
> +        case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE:
> +        case XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE:

Why are we implementing those helpers on Arm?

> +            if ( CONFIG_NR_CPUS <= 1 )
> +                return 0;
> +            up = hotplug->op == XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE;
> +            return continue_hypercall_on_cpu(0, smt_up_down_helper, _p(up));
> +
> +        default:
> +            return -EINVAL;
> +    }
> +}
> +
>   long arch_do_sysctl(struct xen_sysctl *sysctl,
>                       XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>   {
> @@ -34,6 +97,10 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
>           ret = dt_overlay_sysctl(&sysctl->u.dt_overlay);
>           break;
>   
> +    case XEN_SYSCTL_cpu_hotplug:

This will also enable CPU hotplug on 32-bit Arm. Is this what you 
intended? (I see patch #4 only mention 64-bit Arm).

> +        ret = cpu_hotplug_sysctl(&sysctl->u.cpu_hotplug);
> +        break;
> +
>       default:
>           ret = -ENOSYS;
>           break;

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:04:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:04:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126126.1467792 (Exim 4.92)
	(envelope-from )
	id 1uzFFA-0001E1-SG; Thu, 18 Sep 2025 14:04:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126126.1467792; Thu, 18 Sep 2025 14:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFFA-0001Du-Pj; Thu, 18 Sep 2025 14:04:16 +0000
Received: by outflank-mailman (input) for mailman id 1126126;
 Thu, 18 Sep 2025 14:04: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 1uzFF9-0001Do-0D
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:04:15 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ac96565-9498-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:04:13 +0200 (CEST)
Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com
 [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-61-ebReSU0YM8uN14Z_M_oQJA-1; Thu, 18 Sep 2025 10:04:10 -0400
Received: by mail-qk1-f197.google.com with SMTP id
 af79cd13be357-8217df6d44cso161433985a.2
 for ; Thu, 18 Sep 2025 07:04:09 -0700 (PDT)
Received: from x1.local ([174.89.135.121]) by smtp.gmail.com with ESMTPSA id
 af79cd13be357-8363344e970sm165242485a.61.2025.09.18.07.04.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 18 Sep 2025 07:04: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: 5ac96565-9498-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758204252;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=oylp830QgzWCxYygQPu4YXMnJbTIkCEHwCADQS7PoK8=;
	b=gb8YW2X6GyTHcq1cYm9jVcVGeCa+yqlAiKn/xqomi54Dxmk2yuoFbKTY0wwBOSLxuH70Ac
	tlCSUPlWjhMLfhXDDS90e9EFeRdEuPl1TkJ8DPyO8aWB6SNR/IY1MxJtw9Cw1qH4dHr4lB
	7g1NuEAFfVsU0fkegsC4Z/K8+ANvC88=
X-MC-Unique: ebReSU0YM8uN14Z_M_oQJA-1
X-Mimecast-MFC-AGG-ID: ebReSU0YM8uN14Z_M_oQJA_1758204249
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758204249; x=1758809049;
        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=oylp830QgzWCxYygQPu4YXMnJbTIkCEHwCADQS7PoK8=;
        b=jsREnOp90QPDW4YD7U2ENjWtjnnHmIAb8SY68NrMPR3WGz5sq5QSVhjqtvE9hmHo2W
         39XLXb2gqPHtSZ/UjFoUkIfeAJLhOapersXKsVPtbDfAWE/v4HW4fws/swhhdqJtTiLa
         7fDXrOsRBxDPM2gHpHWhXYJtzFPEzrBUn0+Mt6hk6KQPvNWBdFHe6595a8XHEbb7P9uz
         q3pDVakvlo+L2GWJOL/phO5oJihvRzFB7bUUAP5cOv99nkg04Y+Pl3nUiYYfvpYogRno
         v04Q0w/Y4VW1YJOc3dPZUnmtPtPzo8GTBSPnbWEVb14MWKNA80zY51U1VrYHUlpyXw/r
         hKaQ==
X-Forwarded-Encrypted: i=1; AJvYcCXOjvrwS0XyfuM/silX6iGtR1V6bhj9LOW5iZYaAg0Md2bfs7EKRXZgb0LbLKnZmfx2+bOKH0e1vj0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzG1ozzr1nZU3TEiaiPG36CPM1oSMg6nMFW+vTlPKi327cHx1WZ
	8pBqnaImsRS7rATHrVPlJ9KrYVg43Wo0r4g7I4ja8T/j72wMon6BYhvt27Q3s08boXvSULk+5n1
	c/3HdNSX6pnexXiYsNeAdOHZhdWEpOX7001SSiRRpR4auoOmOoPJU332sO8xqJsaIB0GB
X-Gm-Gg: ASbGncvuiN8v3RVMLBTN3SQUnDvLau/8W3H1xLNB74yUtEWUWIg5Il8nJG5HugXzM9V
	eOvnekWcZN3TDw9q41Pwp66AdOsY22Za4X2Nmv+6fEdlDvmxZ+Kj7nuzvpyB7pWZeIGW4m3i+i5
	avJSnDv55EjwqM2yiThN4lEBG+WsPtpopY8vomHg1enbbXhoPbBvHY8oIflLCjTlGx0celM2Fnu
	10zU+5fI1jhHbrq3mHj7ZP9g6sJ4yJZFQUKF6fjgEGOpEdbKH0imDBX/wWHGgoSYSQHi20O1Otl
	dRlOnwMJp1DuoA19NefwOrjj3//ew0+J
X-Received: by 2002:a05:620a:2a07:b0:822:f45b:a5ef with SMTP id af79cd13be357-8310a6416admr643808985a.29.1758204249165;
        Thu, 18 Sep 2025 07:04:09 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHa8HlWVxiunhxh9YQWqVYN7oHdznhotjK4AQbo42C9SFdIf9dV/mPRmaLtfzCAOkZHoqjgOw==
X-Received: by 2002:a05:620a:2a07:b0:822:f45b:a5ef with SMTP id af79cd13be357-8310a6416admr643799885a.29.1758204248504;
        Thu, 18 Sep 2025 07:04:08 -0700 (PDT)
Date: Thu, 18 Sep 2025 10:03:54 -0400
From: Peter Xu 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= ,
	Eduardo Habkost ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: OfzqKQY38lv-94LIVMChFHDyTkZx_b917uRkBfTOWWw_1758204249
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> Based-on: 
> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")

Could I ask why this is a dependency?

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126139.1467802 (Exim 4.92)
	(envelope-from )
	id 1uzFKm-0002PT-Eq; Thu, 18 Sep 2025 14:10:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126139.1467802; Thu, 18 Sep 2025 14:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFKm-0002Oy-CF; Thu, 18 Sep 2025 14:10:04 +0000
Received: by outflank-mailman (input) for mailman id 1126139;
 Thu, 18 Sep 2025 14:10: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 1uzFKl-00023R-67
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10: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 2a80a570-9499-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:10: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 67FB560052;
 Thu, 18 Sep 2025 14:10:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AE6CC4CEE7;
 Thu, 18 Sep 2025 14:09: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: 2a80a570-9499-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204600;
	bh=Pi5T819TFc2iqtg/dEe1hcW6EHD16i+UrHXuy/WzDOY=;
	h=From:To:Cc:Subject:Date:From;
	b=N6hq4IZioMzxZVLrqPxIN1sDeyN1/MixcEr36decDtSa4WNTO48EIzoRtCfHURiTP
	 XMufzHtXGUQWyG32ltphrXys4JlT2/nPQzRJUepSs7aIKZ4Dt/Ss1EyEAK8QkC8zc3
	 vIl5lD0WF4qeZn8Z3KGVbFo72DRy50Klk5ZEVPZ2yeHGy8hIMfUDG6YgqbV6WFZxca
	 4kV/RF3TSWU8WIaiPtXWJzI2gXYl0Crd2VqYcMMNL6jc66qQmehT4vZSRFKtxGw7Jr
	 cRVkT6eGVn1SU0m0y41HUKDXp21LxO+guGGu3EyXnpZKW4XO6cr0Q6FOwPLQ0JkSJE
	 62ET1qQlR3oRw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 0/6] Preparation to .map_page and .unmap_page removal
Date: Thu, 18 Sep 2025 17:09:23 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Changelog:
v4:
 * Added Jason's ROB tags
 * Added "xen: swiotlb ..." patch to the list of patches which had .map_resource
 * Added extra patch "ARM: dma-mapping: Reduce ..." to remove struct
   page as much as possible.
 * Added call to .map_phys/.unmap_phys to dma_common_*_pages() functions.
v3: https://lore.kernel.org/all/cover.1758006942.git.leon@kernel.org
 * Rewrote the series to allow combination of .map_resource and
 * .map_page
   to one flow.
 * Added two new patches to convert and remove .map_resource.
v2: https://lore.kernel.org/all/cover.1752734252.git.leon@kernel.org/
 * Added default "else" section without map_phys and map_page
   callbacks (impossible).
v1: https://lore.kernel.org/all/cover.1753003879.git.leon@kernel.org
 * Changed "else if" instead of "if".
v0: https://lore.kernel.org/all/cover.1752734252.git.leon@kernel.org
---------------------------------------------------------------------

This is followup to "dma-mapping: migrate to physical address-based API" series
https://lore.kernel.org/all/cover.1757423202.git.leonro@nvidia.com

Thanks

Leon Romanovsky (6):
  dma-mapping: prepare dma_map_ops to conversion to physical address
  dma-mapping: convert dummy ops to physical address mapping
  ARM: dma-mapping: Reduce struct page exposure in arch_sync_dma*()
  ARM: dma-mapping: Switch to physical address mapping callbacks
  xen: swiotlb: Switch to physical address mapping callbacks
  dma-mapping: remove unused mapping resource callbacks

 arch/arm/mm/dma-mapping.c   | 180 +++++++++++-------------------------
 drivers/xen/swiotlb-xen.c   |  63 ++++++-------
 include/linux/dma-map-ops.h |  13 +--
 kernel/dma/dummy.c          |  13 ++-
 kernel/dma/mapping.c        |  20 ++--
 kernel/dma/ops_helpers.c    |  12 ++-
 6 files changed, 113 insertions(+), 188 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126140.1467813 (Exim 4.92)
	(envelope-from )
	id 1uzFKv-00036u-Mk; Thu, 18 Sep 2025 14:10:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126140.1467813; Thu, 18 Sep 2025 14:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFKv-00036n-JH; Thu, 18 Sep 2025 14:10:13 +0000
Received: by outflank-mailman (input) for mailman id 1126140;
 Thu, 18 Sep 2025 14:10: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 1uzFKt-00035d-H6
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10:11 +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 2cd4afc4-9499-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 16:10:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id DAECE60214;
 Thu, 18 Sep 2025 14:10:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F01F1C4CEE7;
 Thu, 18 Sep 2025 14:10: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: 2cd4afc4-9499-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204604;
	bh=ZvzOne7JVuKRt51UWjTla7x7wVEVuv97Aoq0lfqLgUE=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=O2sUbafDsMkWNheNKKvFdT0pthF4IgeoVmIjIo++piQ6FogpLWmh11dTZNVWb3Lgt
	 xVp0UuxUxSl+/XMTgvDsaAyPnd2xLvAzkXpBLbm5vCRv96x8WHPfJE+qiNWEth97mP
	 ++DZ3RgCBKBQkuqybTvt076vShyirPkNS59GSoA9yXyxPnHzGJEzNG8dO2TZw9CfZ8
	 X9bZOFqGSa2JOAjg4fXO6khWdhV9Kbgmm4YBoxToy/OHtelnqrqIRnZVosrpwLWJpK
	 Ujl4jM6AeazDmL80IJtF4LMtsDUun/4izas+/borBV4rJ/iv+dIbicjUwqa9UP2Va1
	 AojXJZ3AWcy9g==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 2/6] dma-mapping: convert dummy ops to physical address mapping
Date: Thu, 18 Sep 2025 17:09:25 +0300
Message-ID: <9a1d5ba5f4e5c4ac1216253e35a4a6a7cb941802.1758203802.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Change dma_dummy_map_page and dma_dummy_unmap_page routines
to accept physical address and rename them.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 kernel/dma/dummy.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/kernel/dma/dummy.c b/kernel/dma/dummy.c
index 92de80e5b057e..16a51736a2a39 100644
--- a/kernel/dma/dummy.c
+++ b/kernel/dma/dummy.c
@@ -11,17 +11,16 @@ static int dma_dummy_mmap(struct device *dev, struct vm_area_struct *vma,
 	return -ENXIO;
 }
 
-static dma_addr_t dma_dummy_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t size, enum dma_data_direction dir,
-		unsigned long attrs)
+static dma_addr_t dma_dummy_map_phys(struct device *dev, phys_addr_t phys,
+		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	return DMA_MAPPING_ERROR;
 }
-static void dma_dummy_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void dma_dummy_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	/*
-	 * Dummy ops doesn't support map_page, so unmap_page should never be
+	 * Dummy ops doesn't support map_phys, so unmap_page should never be
 	 * called.
 	 */
 	WARN_ON_ONCE(true);
@@ -51,8 +50,8 @@ static int dma_dummy_supported(struct device *hwdev, u64 mask)
 
 const struct dma_map_ops dma_dummy_ops = {
 	.mmap                   = dma_dummy_mmap,
-	.map_page               = dma_dummy_map_page,
-	.unmap_page             = dma_dummy_unmap_page,
+	.map_phys               = dma_dummy_map_phys,
+	.unmap_phys             = dma_dummy_unmap_phys,
 	.map_sg                 = dma_dummy_map_sg,
 	.unmap_sg               = dma_dummy_unmap_sg,
 	.dma_supported          = dma_dummy_supported,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126141.1467818 (Exim 4.92)
	(envelope-from )
	id 1uzFKw-0003BQ-21; Thu, 18 Sep 2025 14:10:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126141.1467818; Thu, 18 Sep 2025 14:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFKv-0003A5-RM; Thu, 18 Sep 2025 14:10:13 +0000
Received: by outflank-mailman (input) for mailman id 1126141;
 Thu, 18 Sep 2025 14:10:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzFKv-00035d-3o
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10:13 +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 2fbdbdab-9499-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 16:10: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 21F6540826;
 Thu, 18 Sep 2025 14:10:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 767C8C4CEE7;
 Thu, 18 Sep 2025 14:10: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: 2fbdbdab-9499-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204609;
	bh=7ctlDOwNiFgZVAZcPGLZSJOnlazVmdQdCYwzHXR5exA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=oyqwu64BZu6RjG9CnpKCr3myw4HDldvhOSfCWTkgNiDvrlE8uIAhIfcBCeVXmGVZ1
	 7umCbbQ1rkX/ipSoOD/4RSe4fc3dPqQlnTQQPXW5mgROoLKyXZGyhuVeRO8vVC4Bm4
	 Ya5UjyQSZykWjAs/mbE6JiW1lGgrnuInyF64+7D0FD+3db1GQBVAoxo7SV2P7U2vO/
	 XrBA0HfGqAPvG/9WZFcnNE3y7efxI0z4oHvfJRZDszI58XGdtYFbilpCXKZX1Q7ai2
	 +C+GLYL87J6QpD7PHzQDnkJX7tmCDP6r6jfMMWEd+mSevtuOibCVA8pXdo+pUAobaV
	 SyMXCEQEsZLOA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 3/6] ARM: dma-mapping: Reduce struct page exposure in arch_sync_dma*()
Date: Thu, 18 Sep 2025 17:09:26 +0300
Message-ID: <2f20069c2b616808c034ba4e75905820b94e0e22.1758203802.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

As a preparation to changing from .map_page to use .map_phys DMA
callbacks, convert arch_sync_dma*() functions to use physical addresses
instead of struct page.

Signed-off-by: Leon Romanovsky 
---
 arch/arm/mm/dma-mapping.c | 82 +++++++++++++++------------------------
 1 file changed, 31 insertions(+), 51 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 88c2d68a69c9e..449fe6bf525e5 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -624,16 +624,14 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
 	kfree(buf);
 }
 
-static void dma_cache_maint_page(struct page *page, unsigned long offset,
-	size_t size, enum dma_data_direction dir,
+static void dma_cache_maint_page(phys_addr_t phys, size_t size,
+	enum dma_data_direction dir,
 	void (*op)(const void *, size_t, int))
 {
-	unsigned long pfn;
+	unsigned long offset = offset_in_page(phys);
+	unsigned long pfn = __phys_to_pfn(phys);
 	size_t left = size;
 
-	pfn = page_to_pfn(page) + offset / PAGE_SIZE;
-	offset %= PAGE_SIZE;
-
 	/*
 	 * A single sg entry may refer to multiple physically contiguous
 	 * pages.  But we still need to process highmem pages individually.
@@ -644,17 +642,18 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
 		size_t len = left;
 		void *vaddr;
 
-		page = pfn_to_page(pfn);
-
-		if (PageHighMem(page)) {
+		phys = __pfn_to_phys(pfn);
+		if (PhysHighMem(phys)) {
 			if (len + offset > PAGE_SIZE)
 				len = PAGE_SIZE - offset;
 
 			if (cache_is_vipt_nonaliasing()) {
-				vaddr = kmap_atomic(page);
+				vaddr = kmap_atomic_pfn(pfn);
 				op(vaddr + offset, len, dir);
 				kunmap_atomic(vaddr);
 			} else {
+				struct page *page = phys_to_page(phys);
+
 				vaddr = kmap_high_get(page);
 				if (vaddr) {
 					op(vaddr + offset, len, dir);
@@ -662,7 +661,8 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
 				}
 			}
 		} else {
-			vaddr = page_address(page) + offset;
+			phys += offset;
+			vaddr = phys_to_virt(phys);
 			op(vaddr, len, dir);
 		}
 		offset = 0;
@@ -676,14 +676,11 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
  * Note: Drivers should NOT use this function directly.
  * Use the driver DMA support - see dma-mapping.h (dma_sync_*)
  */
-static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
-	size_t size, enum dma_data_direction dir)
+void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
+			      enum dma_data_direction dir)
 {
-	phys_addr_t paddr;
-
-	dma_cache_maint_page(page, off, size, dir, dmac_map_area);
+	dma_cache_maint_page(paddr, size, dir, dmac_map_area);
 
-	paddr = page_to_phys(page) + off;
 	if (dir == DMA_FROM_DEVICE) {
 		outer_inv_range(paddr, paddr + size);
 	} else {
@@ -692,17 +689,15 @@ static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
 	/* FIXME: non-speculating: flush on bidirectional mappings? */
 }
 
-static void __dma_page_dev_to_cpu(struct page *page, unsigned long off,
-	size_t size, enum dma_data_direction dir)
+void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
+			   enum dma_data_direction dir)
 {
-	phys_addr_t paddr = page_to_phys(page) + off;
-
 	/* FIXME: non-speculating: not required */
 	/* in any case, don't bother invalidating if DMA to device */
 	if (dir != DMA_TO_DEVICE) {
 		outer_inv_range(paddr, paddr + size);
 
-		dma_cache_maint_page(page, off, size, dir, dmac_unmap_area);
+		dma_cache_maint_page(paddr, size, dir, dmac_unmap_area);
 	}
 
 	/*
@@ -1205,7 +1200,7 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
 		unsigned int len = PAGE_ALIGN(s->offset + s->length);
 
 		if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-			__dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
+			arch_sync_dma_for_device(sg_phys(s), s->length, dir);
 
 		prot = __dma_info_to_prot(dir, attrs);
 
@@ -1307,8 +1302,7 @@ static void arm_iommu_unmap_sg(struct device *dev,
 			__iommu_remove_mapping(dev, sg_dma_address(s),
 					       sg_dma_len(s));
 		if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-			__dma_page_dev_to_cpu(sg_page(s), s->offset,
-					      s->length, dir);
+			arch_sync_dma_for_cpu(sg_phys(s), s->length, dir);
 	}
 }
 
@@ -1330,7 +1324,7 @@ static void arm_iommu_sync_sg_for_cpu(struct device *dev,
 		return;
 
 	for_each_sg(sg, s, nents, i)
-		__dma_page_dev_to_cpu(sg_page(s), s->offset, s->length, dir);
+		arch_sync_dma_for_cpu(sg_phys(s), s->length, dir);
 
 }
 
@@ -1352,7 +1346,7 @@ static void arm_iommu_sync_sg_for_device(struct device *dev,
 		return;
 
 	for_each_sg(sg, s, nents, i)
-		__dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
+		arch_sync_dma_for_device(sg_phys(s), s->length, dir);
 }
 
 /**
@@ -1374,7 +1368,7 @@ static dma_addr_t arm_iommu_map_page(struct device *dev, struct page *page,
 	int ret, prot, len = PAGE_ALIGN(size + offset);
 
 	if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-		__dma_page_cpu_to_dev(page, offset, size, dir);
+		arch_sync_dma_for_device(page_to_phys(page), offset, size, dir);
 
 	dma_addr = __alloc_iova(mapping, len);
 	if (dma_addr == DMA_MAPPING_ERROR)
@@ -1407,7 +1401,6 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
 {
 	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
 	dma_addr_t iova = handle & PAGE_MASK;
-	struct page *page;
 	int offset = handle & ~PAGE_MASK;
 	int len = PAGE_ALIGN(size + offset);
 
@@ -1415,8 +1408,9 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
 		return;
 
 	if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) {
-		page = phys_to_page(iommu_iova_to_phys(mapping->domain, iova));
-		__dma_page_dev_to_cpu(page, offset, size, dir);
+		phys_addr_t phys = iommu_iova_to_phys(mapping->domain, iova);
+
+		arch_sync_dma_for_cpu(phys + offset, size, dir);
 	}
 
 	iommu_unmap(mapping->domain, iova, len);
@@ -1485,14 +1479,14 @@ static void arm_iommu_sync_single_for_cpu(struct device *dev,
 {
 	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
 	dma_addr_t iova = handle & PAGE_MASK;
-	struct page *page;
 	unsigned int offset = handle & ~PAGE_MASK;
+	phys_addr_t phys;
 
 	if (dev->dma_coherent || !iova)
 		return;
 
-	page = phys_to_page(iommu_iova_to_phys(mapping->domain, iova));
-	__dma_page_dev_to_cpu(page, offset, size, dir);
+	phys = iommu_iova_to_phys(mapping->domain, iova);
+	arch_sync_dma_for_cpu(phys + offset, size, dir);
 }
 
 static void arm_iommu_sync_single_for_device(struct device *dev,
@@ -1500,14 +1494,14 @@ static void arm_iommu_sync_single_for_device(struct device *dev,
 {
 	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
 	dma_addr_t iova = handle & PAGE_MASK;
-	struct page *page;
 	unsigned int offset = handle & ~PAGE_MASK;
+	phys_addr_t phys;
 
 	if (dev->dma_coherent || !iova)
 		return;
 
-	page = phys_to_page(iommu_iova_to_phys(mapping->domain, iova));
-	__dma_page_cpu_to_dev(page, offset, size, dir);
+	phys = iommu_iova_to_phys(mapping->domain, iova);
+	arch_sync_dma_for_device(phys + offset, size, dir);
 }
 
 static const struct dma_map_ops iommu_ops = {
@@ -1794,20 +1788,6 @@ void arch_teardown_dma_ops(struct device *dev)
 	set_dma_ops(dev, NULL);
 }
 
-void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
-		enum dma_data_direction dir)
-{
-	__dma_page_cpu_to_dev(phys_to_page(paddr), paddr & (PAGE_SIZE - 1),
-			      size, dir);
-}
-
-void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
-		enum dma_data_direction dir)
-{
-	__dma_page_dev_to_cpu(phys_to_page(paddr), paddr & (PAGE_SIZE - 1),
-			      size, dir);
-}
-
 void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
 		gfp_t gfp, unsigned long attrs)
 {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126142.1467833 (Exim 4.92)
	(envelope-from )
	id 1uzFKy-0003an-6V; Thu, 18 Sep 2025 14:10:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126142.1467833; Thu, 18 Sep 2025 14:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFKy-0003ac-30; Thu, 18 Sep 2025 14:10:16 +0000
Received: by outflank-mailman (input) for mailman id 1126142;
 Thu, 18 Sep 2025 14:10: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 1uzFKx-00023R-8b
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10: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 3205f571-9499-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:10: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 7F85160213;
 Thu, 18 Sep 2025 14:10:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89A72C4CEE7;
 Thu, 18 Sep 2025 14:10: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: 3205f571-9499-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204613;
	bh=EBwyVcXAx8ZG32+m2XXWq6jJ96SEAu9YsPWb4/XSEXM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=g91qhJGxeoCacHMXVvMTz7RIXE3W5xSK+eWI3ZLQKEzqvjgAwd3KWhjzecEB9E9XW
	 Rog6AOcsA1/dXWOM5n73e63ivD27zsQZVe8Pd0yJtupjYQMR1BlhsemQeWHwRdWjHs
	 JU52tCUyMio20fbK9hzR2G+f4bLvtIhFNOhtpO7+0S9foMZCCJ6QioLxkx1s1F1nZ5
	 sqsdKXDyDwfs2QJPX9Ye4hYDNMVOMX+HVDKgXwQWdZ3DiDgAiH4+OI3r8YRkv/Szwm
	 pYMc+5LhUcjh+0xKf0SYlpfujhwDmXUrnf0YX8zhaTeFiJx+/JlbkjdZ6oTbI2n83v
	 2kL6eEufZWuLQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 1/6] dma-mapping: prepare dma_map_ops to conversion to physical address
Date: Thu, 18 Sep 2025 17:09:24 +0300
Message-ID: <24d324344913170315f66cb43ac6692b3132a145.1758203802.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Add new .map_phys() and .unmap_phys() callbacks to dma_map_ops as a
preparation to replace .map_page() and .unmap_page() respectively.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 include/linux/dma-map-ops.h |  7 +++++++
 kernel/dma/mapping.c        |  4 ++++
 kernel/dma/ops_helpers.c    | 12 ++++++++++--
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index 71f5b30254159..25603cb273769 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -37,6 +37,13 @@ struct dma_map_ops {
 	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
 			size_t size, enum dma_data_direction dir,
 			unsigned long attrs);
+
+	dma_addr_t (*map_phys)(struct device *dev, phys_addr_t phys,
+			size_t size, enum dma_data_direction dir,
+			unsigned long attrs);
+	void (*unmap_phys)(struct device *dev, dma_addr_t dma_handle,
+			size_t size, enum dma_data_direction dir,
+			unsigned long attrs);
 	/*
 	 * map_sg should return a negative error code on error. See
 	 * dma_map_sgtable() for a list of appropriate error codes
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index fe7472f13b106..4080aebe5debb 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -169,6 +169,8 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 		addr = dma_direct_map_phys(dev, phys, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
+	else if (ops->map_phys)
+		addr = ops->map_phys(dev, phys, size, dir, attrs);
 	else if (is_mmio) {
 		if (!ops->map_resource)
 			return DMA_MAPPING_ERROR;
@@ -223,6 +225,8 @@ void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size,
 		dma_direct_unmap_phys(dev, addr, size, dir, attrs);
 	else if (use_dma_iommu(dev))
 		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
+	else if (ops->unmap_phys)
+		ops->unmap_phys(dev, addr, size, dir, attrs);
 	else if (is_mmio) {
 		if (ops->unmap_resource)
 			ops->unmap_resource(dev, addr, size, dir, attrs);
diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
index 6f9d604d9d406..1eccbdbc99c1e 100644
--- a/kernel/dma/ops_helpers.c
+++ b/kernel/dma/ops_helpers.c
@@ -64,6 +64,7 @@ struct page *dma_common_alloc_pages(struct device *dev, size_t size,
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
 	struct page *page;
+	phys_addr_t phys;
 
 	page = dma_alloc_contiguous(dev, size, gfp);
 	if (!page)
@@ -71,9 +72,13 @@ struct page *dma_common_alloc_pages(struct device *dev, size_t size,
 	if (!page)
 		return NULL;
 
+	phys = page_to_phys(page);
 	if (use_dma_iommu(dev))
-		*dma_handle = iommu_dma_map_phys(dev, page_to_phys(page), size,
-						 dir, DMA_ATTR_SKIP_CPU_SYNC);
+		*dma_handle = iommu_dma_map_phys(dev, phys, size, dir,
+						 DMA_ATTR_SKIP_CPU_SYNC);
+	else if (ops->map_phys)
+		*dma_handle = ops->map_phys(dev, phys, size, dir,
+					    DMA_ATTR_SKIP_CPU_SYNC);
 	else
 		*dma_handle = ops->map_page(dev, page, 0, size, dir,
 					    DMA_ATTR_SKIP_CPU_SYNC);
@@ -94,6 +99,9 @@ void dma_common_free_pages(struct device *dev, size_t size, struct page *page,
 	if (use_dma_iommu(dev))
 		iommu_dma_unmap_phys(dev, dma_handle, size, dir,
 				     DMA_ATTR_SKIP_CPU_SYNC);
+	else if (ops->unmap_phys)
+		ops->unmap_phys(dev, dma_handle, size, dir,
+				DMA_ATTR_SKIP_CPU_SYNC);
 	else if (ops->unmap_page)
 		ops->unmap_page(dev, dma_handle, size, dir,
 				DMA_ATTR_SKIP_CPU_SYNC);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126144.1467843 (Exim 4.92)
	(envelope-from )
	id 1uzFL3-0003xd-K6; Thu, 18 Sep 2025 14:10:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126144.1467843; Thu, 18 Sep 2025 14: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 1uzFL3-0003xS-GU; Thu, 18 Sep 2025 14:10:21 +0000
Received: by outflank-mailman (input) for mailman id 1126144;
 Thu, 18 Sep 2025 14:10: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 1uzFL2-00023R-56
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10:20 +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 34b34a81-9499-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:10:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 05B6240336;
 Thu, 18 Sep 2025 14:10:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04D2CC4CEE7;
 Thu, 18 Sep 2025 14:10: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: 34b34a81-9499-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204617;
	bh=m3D6g8FDHOZH6474XMcPOpnGaU1UwHseRqgAFUOfdrA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=LsgW3cFpYtCJcNpT12ghofulEYz5SE3I1+MEc+VZwiV2aowmuN6OaLrwwHtaY3r62
	 Un7zmoh5+VozkXySig2p0YiWfk7Loy24bLch1JLoDULUJlZ0+s1bosOrGr6Qzps9G4
	 bTciv3Y9YjxxtlFXDXQOA/OUJnji3JaqIfapiByz1FAfMeEl6gUdz3r0CsibDAXsSL
	 hBODJnZhl/XMFnr2oqiyEBEmThANZ2dqKjUTgYaQXdmtJvFNokS+KVbOb2zKA5lM33
	 faKpQN6yt9V/166f9jvRgOthV1TZoTwvTEz1KV3BkmMtdElPbfE7H1ZPamvbmLHuL+
	 Z5qCSgG53oUHA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 5/6] xen: swiotlb: Switch to physical address mapping callbacks
Date: Thu, 18 Sep 2025 17:09:28 +0300
Message-ID: <997c0122a24c355b4d7ee353902041a7617f4c9e.1758203802.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Combine resource and page mappings routines to one function
and remove .map_resource/.unmap_resource callbacks completely.

Signed-off-by: Leon Romanovsky 
---
 drivers/xen/swiotlb-xen.c | 63 ++++++++++++++++++---------------------
 1 file changed, 29 insertions(+), 34 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index dd7747a2de879..48936179c940b 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -200,17 +200,32 @@ xen_swiotlb_free_coherent(struct device *dev, size_t size, void *vaddr,
  * physical address to use is returned.
  *
  * Once the device is given the dma address, the device owns this memory until
- * either xen_swiotlb_unmap_page or xen_swiotlb_dma_sync_single is performed.
+ * either xen_swiotlb_unmap_phys or xen_swiotlb_dma_sync_single is performed.
  */
-static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
-				unsigned long offset, size_t size,
-				enum dma_data_direction dir,
+static dma_addr_t xen_swiotlb_map_phys(struct device *dev, phys_addr_t phys,
+				size_t size, enum dma_data_direction dir,
 				unsigned long attrs)
 {
-	phys_addr_t map, phys = page_to_phys(page) + offset;
-	dma_addr_t dev_addr = xen_phys_to_dma(dev, phys);
+	dma_addr_t dev_addr;
+	phys_addr_t map;
 
 	BUG_ON(dir == DMA_NONE);
+
+	if (attrs & DMA_ATTR_MMIO) {
+		if (unlikely(!dma_capable(dev, phys, size, false))) {
+			dev_err_once(
+				dev,
+				"DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
+				&dma_addr, size, *dev->dma_mask,
+				dev->bus_dma_limit);
+			WARN_ON_ONCE(1);
+			return DMA_MAPPING_ERROR;
+		}
+		return phys;
+	}
+
+	dev_addr = xen_phys_to_dma(dev, phys);
+
 	/*
 	 * If the address happens to be in the device's DMA window,
 	 * we can safely return the device addr and not worry about bounce
@@ -257,13 +272,13 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 
 /*
  * Unmap a single streaming mode DMA translation.  The dma_addr and size must
- * match what was provided for in a previous xen_swiotlb_map_page call.  All
+ * match what was provided for in a previous xen_swiotlb_map_phys call.  All
  * other usages are undefined.
  *
  * After this call, reads by the cpu to the buffer are guaranteed to see
  * whatever the device wrote there.
  */
-static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
+static void xen_swiotlb_unmap_phys(struct device *hwdev, dma_addr_t dev_addr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	phys_addr_t paddr = xen_dma_to_phys(hwdev, dev_addr);
@@ -325,7 +340,7 @@ xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr,
 
 /*
  * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
- * concerning calls here are the same as for swiotlb_unmap_page() above.
+ * concerning calls here are the same as for swiotlb_unmap_phys() above.
  */
 static void
 xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
@@ -337,7 +352,7 @@ xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i)
-		xen_swiotlb_unmap_page(hwdev, sg->dma_address, sg_dma_len(sg),
+		xen_swiotlb_unmap_phys(hwdev, sg->dma_address, sg_dma_len(sg),
 				dir, attrs);
 
 }
@@ -352,8 +367,8 @@ xen_swiotlb_map_sg(struct device *dev, struct scatterlist *sgl, int nelems,
 	BUG_ON(dir == DMA_NONE);
 
 	for_each_sg(sgl, sg, nelems, i) {
-		sg->dma_address = xen_swiotlb_map_page(dev, sg_page(sg),
-				sg->offset, sg->length, dir, attrs);
+		sg->dma_address = xen_swiotlb_map_phys(dev, sg_phys(sg),
+				sg->length, dir, attrs);
 		if (sg->dma_address == DMA_MAPPING_ERROR)
 			goto out_unmap;
 		sg_dma_len(sg) = sg->length;
@@ -392,25 +407,6 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
 	}
 }
 
-static dma_addr_t xen_swiotlb_direct_map_resource(struct device *dev,
-						  phys_addr_t paddr,
-						  size_t size,
-						  enum dma_data_direction dir,
-						  unsigned long attrs)
-{
-	dma_addr_t dma_addr = paddr;
-
-	if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
-		dev_err_once(dev,
-			     "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
-			     &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
-		WARN_ON_ONCE(1);
-		return DMA_MAPPING_ERROR;
-	}
-
-	return dma_addr;
-}
-
 /*
  * Return whether the given device DMA address mask can be supported
  * properly.  For example, if your device can only drive the low 24-bits
@@ -437,13 +433,12 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
 	.sync_sg_for_device = xen_swiotlb_sync_sg_for_device,
 	.map_sg = xen_swiotlb_map_sg,
 	.unmap_sg = xen_swiotlb_unmap_sg,
-	.map_page = xen_swiotlb_map_page,
-	.unmap_page = xen_swiotlb_unmap_page,
+	.map_phys = xen_swiotlb_map_phys,
+	.unmap_phys = xen_swiotlb_unmap_phys,
 	.dma_supported = xen_swiotlb_dma_supported,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
 	.alloc_pages_op = dma_common_alloc_pages,
 	.free_pages = dma_common_free_pages,
 	.max_mapping_size = swiotlb_max_mapping_size,
-	.map_resource = xen_swiotlb_direct_map_resource,
 };
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126146.1467853 (Exim 4.92)
	(envelope-from )
	id 1uzFL7-0004JM-Q8; Thu, 18 Sep 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 1126146.1467853; Thu, 18 Sep 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 1uzFL7-0004JD-NJ; Thu, 18 Sep 2025 14:10:25 +0000
Received: by outflank-mailman (input) for mailman id 1126146;
 Thu, 18 Sep 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 1uzFL6-00023R-HZ
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10:24 +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 3726f996-9499-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:10:23 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 1BDC943EF1;
 Thu, 18 Sep 2025 14:10:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AEFAC4CEFB;
 Thu, 18 Sep 2025 14:10: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: 3726f996-9499-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204622;
	bh=+mItofUWbT/SzLs0Mrc6WXSkqZWGdUCuVYLGJSLcHDY=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=V9JsUocXjcR/CRRuPUbMLUrynQTHxnyRZUck8xrjf9keCJjbsa1bH9eWOXAHqWeqU
	 juQIOVyIP8IsObWlS/GQ+c+Uprfg0vQs/uSvxRKuOSh8ip7nCbACSbb1d2V8B94szO
	 gm7otPQ0YarFehrESzgfR/EeZvdmrVvboJRbxtk+1PNZhXi9imBesuxF1A4Rpoq0ll
	 6I34Kw2ZKFhTFUM3h5ErNDcdSGH3nZ6uRpyw5T2To3AYoFeaBoieE+XTvKRGewbaJI
	 34bqm0hVT5cN07YS2CqWqEONmyD00OuGPY64KYjPokFIOiGj3K230Si2JLMvb8d/wc
	 XDjD3ji1pCB0g==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 6/6] dma-mapping: remove unused mapping resource callbacks
Date: Thu, 18 Sep 2025 17:09:29 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

After ARM and XEN conversions to use physical addresses for the mapping,
there are no in-kernel users for map_resource/unmap_resource callbacks,
so remove them.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 include/linux/dma-map-ops.h |  6 ------
 kernel/dma/mapping.c        | 16 ++++------------
 2 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index 25603cb273769..a2ec1566aa270 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -53,12 +53,6 @@ struct dma_map_ops {
 			enum dma_data_direction dir, unsigned long attrs);
 	void (*unmap_sg)(struct device *dev, struct scatterlist *sg, int nents,
 			enum dma_data_direction dir, unsigned long attrs);
-	dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
-			size_t size, enum dma_data_direction dir,
-			unsigned long attrs);
-	void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
-			size_t size, enum dma_data_direction dir,
-			unsigned long attrs);
 	void (*sync_single_for_cpu)(struct device *dev, dma_addr_t dma_handle,
 			size_t size, enum dma_data_direction dir);
 	void (*sync_single_for_device)(struct device *dev,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 4080aebe5debb..32a85bfdf873a 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -157,7 +157,7 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
 	bool is_mmio = attrs & DMA_ATTR_MMIO;
-	dma_addr_t addr;
+	dma_addr_t addr = DMA_MAPPING_ERROR;
 
 	BUG_ON(!valid_dma_direction(dir));
 
@@ -171,18 +171,13 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
 	else if (ops->map_phys)
 		addr = ops->map_phys(dev, phys, size, dir, attrs);
-	else if (is_mmio) {
-		if (!ops->map_resource)
-			return DMA_MAPPING_ERROR;
-
-		addr = ops->map_resource(dev, phys, size, dir, attrs);
-	} else {
+	else if (!is_mmio && ops->map_page) {
 		struct page *page = phys_to_page(phys);
 		size_t offset = offset_in_page(phys);
 
 		/*
 		 * The dma_ops API contract for ops->map_page() requires
-		 * kmappable memory, while ops->map_resource() does not.
+		 * kmappable memory.
 		 */
 		addr = ops->map_page(dev, page, offset, size, dir, attrs);
 	}
@@ -227,10 +222,7 @@ void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size,
 		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
 	else if (ops->unmap_phys)
 		ops->unmap_phys(dev, addr, size, dir, attrs);
-	else if (is_mmio) {
-		if (ops->unmap_resource)
-			ops->unmap_resource(dev, addr, size, dir, attrs);
-	} else
+	else
 		ops->unmap_page(dev, addr, size, dir, attrs);
 	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
 	debug_dma_unmap_phys(dev, addr, size, dir);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:10:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:10:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126152.1467863 (Exim 4.92)
	(envelope-from )
	id 1uzFLB-0004gG-40; Thu, 18 Sep 2025 14:10:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126152.1467863; Thu, 18 Sep 2025 14:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFLA-0004ft-W6; Thu, 18 Sep 2025 14:10:28 +0000
Received: by outflank-mailman (input) for mailman id 1126152;
 Thu, 18 Sep 2025 14:10:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzFLA-00023R-4D
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:10:28 +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 3981cf27-9499-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:10:27 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 18DBB40C0D;
 Thu, 18 Sep 2025 14:10:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73A7EC4CEF7;
 Thu, 18 Sep 2025 14: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: 3981cf27-9499-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758204626;
	bh=bCSF8Et7U2q9+qx5MPBbsnViuVi0S7sFmZruYcbRwJE=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=MoVP/5b00YLfpONB+ZmiTt6bw1i/Juohr4q/ZKYvTZpHSp5bkKkRXU1owc5fimxKL
	 JEsDthAvGnkY9ujXmwjpMkELIgpmXqCejwBzjtfW4bEYdBEZezMp0IR2njJfDh4MIq
	 EFMZGE46XQiSkNEHXSpjI6QbfiAqc/DFCOObBoepOtJrsVd4G4/AEUGxjSWA35zitw
	 M6HJlzy+fVyWwp1dW5gJnd5gnkbJesqSXTVbmS/ccfh45O28M1ujNm1IzqCUV/n7Bl
	 6RbWxO+0Fhu8b5bqS8lHfOr9GkMWNeIAwu0W/zlJWFX+FfnQowWK3ntA4XWemR8xyz
	 Qbh3YgOgpdY4g==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v4 4/6] ARM: dma-mapping: Switch to physical address mapping callbacks
Date: Thu, 18 Sep 2025 17:09:27 +0300
Message-ID: <110f3bd0ad179b6a26cf236c3214818dbec6a723.1758203802.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Combine resource and page mappings routines to one function, which
handles both these flows at the same manner. This conversion allows
us to remove .map_resource/.unmap_resource callbacks completely.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Leon Romanovsky 
---
 arch/arm/mm/dma-mapping.c | 100 +++++++++-----------------------------
 1 file changed, 23 insertions(+), 77 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 449fe6bf525e5..a6606ba0584f4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -732,6 +732,9 @@ static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
 	if (attrs & DMA_ATTR_PRIVILEGED)
 		prot |= IOMMU_PRIV;
 
+	if (attrs & DMA_ATTR_MMIO)
+		prot |= IOMMU_MMIO;
+
 	switch (dir) {
 	case DMA_BIDIRECTIONAL:
 		return prot | IOMMU_READ | IOMMU_WRITE;
@@ -1350,25 +1353,27 @@ static void arm_iommu_sync_sg_for_device(struct device *dev,
 }
 
 /**
- * arm_iommu_map_page
+ * arm_iommu_map_phys
  * @dev: valid struct device pointer
- * @page: page that buffer resides in
- * @offset: offset into page for start of buffer
+ * @phys: physical address that buffer resides in
  * @size: size of buffer to map
  * @dir: DMA transfer direction
+ * @attrs: DMA mapping attributes
  *
  * IOMMU aware version of arm_dma_map_page()
  */
-static dma_addr_t arm_iommu_map_page(struct device *dev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     unsigned long attrs)
+static dma_addr_t arm_iommu_map_phys(struct device *dev, phys_addr_t phys,
+	     size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+	int len = PAGE_ALIGN(size + offset_in_page(phys));
+	phys_addr_t addr = phys & PAGE_MASK;
 	dma_addr_t dma_addr;
-	int ret, prot, len = PAGE_ALIGN(size + offset);
+	int ret, prot;
 
-	if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-		arch_sync_dma_for_device(page_to_phys(page), offset, size, dir);
+	if (!dev->dma_coherent &&
+	    !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO)))
+		arch_sync_dma_for_device(phys, size, dir);
 
 	dma_addr = __alloc_iova(mapping, len);
 	if (dma_addr == DMA_MAPPING_ERROR)
@@ -1376,12 +1381,11 @@ static dma_addr_t arm_iommu_map_page(struct device *dev, struct page *page,
 
 	prot = __dma_info_to_prot(dir, attrs);
 
-	ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len,
-			prot, GFP_KERNEL);
+	ret = iommu_map(mapping->domain, dma_addr, addr, len, prot, GFP_KERNEL);
 	if (ret < 0)
 		goto fail;
 
-	return dma_addr + offset;
+	return dma_addr + offset_in_page(phys);
 fail:
 	__free_iova(mapping, dma_addr, len);
 	return DMA_MAPPING_ERROR;
@@ -1393,10 +1397,11 @@ static dma_addr_t arm_iommu_map_page(struct device *dev, struct page *page,
  * @handle: DMA address of buffer
  * @size: size of buffer (same as passed to dma_map_page)
  * @dir: DMA transfer direction (same as passed to dma_map_page)
+ * @attrs: DMA mapping attributes
  *
- * IOMMU aware version of arm_dma_unmap_page()
+ * IOMMU aware version of arm_dma_unmap_phys()
  */
-static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
+static void arm_iommu_unmap_phys(struct device *dev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
@@ -1407,7 +1412,8 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
 	if (!iova)
 		return;
 
-	if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) {
+	if (!dev->dma_coherent &&
+	    !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO))) {
 		phys_addr_t phys = iommu_iova_to_phys(mapping->domain, iova);
 
 		arch_sync_dma_for_cpu(phys + offset, size, dir);
@@ -1417,63 +1423,6 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
 	__free_iova(mapping, iova, len);
 }
 
-/**
- * arm_iommu_map_resource - map a device resource for DMA
- * @dev: valid struct device pointer
- * @phys_addr: physical address of resource
- * @size: size of resource to map
- * @dir: DMA transfer direction
- */
-static dma_addr_t arm_iommu_map_resource(struct device *dev,
-		phys_addr_t phys_addr, size_t size,
-		enum dma_data_direction dir, unsigned long attrs)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t dma_addr;
-	int ret, prot;
-	phys_addr_t addr = phys_addr & PAGE_MASK;
-	unsigned int offset = phys_addr & ~PAGE_MASK;
-	size_t len = PAGE_ALIGN(size + offset);
-
-	dma_addr = __alloc_iova(mapping, len);
-	if (dma_addr == DMA_MAPPING_ERROR)
-		return dma_addr;
-
-	prot = __dma_info_to_prot(dir, attrs) | IOMMU_MMIO;
-
-	ret = iommu_map(mapping->domain, dma_addr, addr, len, prot, GFP_KERNEL);
-	if (ret < 0)
-		goto fail;
-
-	return dma_addr + offset;
-fail:
-	__free_iova(mapping, dma_addr, len);
-	return DMA_MAPPING_ERROR;
-}
-
-/**
- * arm_iommu_unmap_resource - unmap a device DMA resource
- * @dev: valid struct device pointer
- * @dma_handle: DMA address to resource
- * @size: size of resource to map
- * @dir: DMA transfer direction
- */
-static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
-		size_t size, enum dma_data_direction dir,
-		unsigned long attrs)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t iova = dma_handle & PAGE_MASK;
-	unsigned int offset = dma_handle & ~PAGE_MASK;
-	size_t len = PAGE_ALIGN(size + offset);
-
-	if (!iova)
-		return;
-
-	iommu_unmap(mapping->domain, iova, len);
-	__free_iova(mapping, iova, len);
-}
-
 static void arm_iommu_sync_single_for_cpu(struct device *dev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
@@ -1510,8 +1459,8 @@ static const struct dma_map_ops iommu_ops = {
 	.mmap		= arm_iommu_mmap_attrs,
 	.get_sgtable	= arm_iommu_get_sgtable,
 
-	.map_page		= arm_iommu_map_page,
-	.unmap_page		= arm_iommu_unmap_page,
+	.map_phys		= arm_iommu_map_phys,
+	.unmap_phys		= arm_iommu_unmap_phys,
 	.sync_single_for_cpu	= arm_iommu_sync_single_for_cpu,
 	.sync_single_for_device	= arm_iommu_sync_single_for_device,
 
@@ -1519,9 +1468,6 @@ static const struct dma_map_ops iommu_ops = {
 	.unmap_sg		= arm_iommu_unmap_sg,
 	.sync_sg_for_cpu	= arm_iommu_sync_sg_for_cpu,
 	.sync_sg_for_device	= arm_iommu_sync_sg_for_device,
-
-	.map_resource		= arm_iommu_map_resource,
-	.unmap_resource		= arm_iommu_unmap_resource,
 };
 
 /**
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:16:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:16:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126195.1467872 (Exim 4.92)
	(envelope-from )
	id 1uzFQT-0006Vw-Mo; Thu, 18 Sep 2025 14:15:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126195.1467872; Thu, 18 Sep 2025 14:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFQT-0006Vp-JU; Thu, 18 Sep 2025 14:15:57 +0000
Received: by outflank-mailman (input) for mailman id 1126195;
 Thu, 18 Sep 2025 14:15:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uzFQS-0006Vj-NY
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:15:56 +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 fdc470a9-9499-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:15:55 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-577dd4c1e84so1345469e87.0
 for ; Thu, 18 Sep 2025 07:15: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: fdc470a9-9499-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758204955; x=1758809755; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=H2UNlJV0Vw4pv3+GHxaqsbGCtynJeSBicB/lSvznXj0=;
        b=MFIJhdY1F5jHzyF/w/yg6g5uZ9T5ddy1f+6l7bbVNAujzs53ov2jFxiPNtFmFAhfcJ
         oTnm1M3RYAdzS7bH4o7ABMIeWtgo8MJ1lkzjR0turycYMDiysQAV10iMfu8iLlchPMeT
         Yte8WmSQGRt49pJQlpgYokH3VcuucLPflSQF4DXzIC4Wzec32PwwEYxVCDhN3UgW5ZMp
         MXo8tOcrrwIoWiO2w7zyPNrR57eJmvqCVDQ/e3pWmJhIa+BTGBT11djTJGzbK81u7y7A
         ISY4rLO/memhAw9kLkmTHoJqfvQ+/XZRlI5MgSYmR40hnj8K/ixD7sEs8zER/Gwd4x0b
         1Brw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758204955; x=1758809755;
        h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=H2UNlJV0Vw4pv3+GHxaqsbGCtynJeSBicB/lSvznXj0=;
        b=WredHR/ZyeI1HVUHFVmRHVCE+cI9NLZ73WviE91xix6mC7uCKP/yKxy3v9a4Xw4SCW
         SQzVumllq8dCmZLqNBLvclSF3vmhGvjarvGXwOIdijyskO2YXw9WaAyCEOQyYxF5szg2
         AX6Z4klIhLzGDYaXzusybKcByMtZjgv/IZ7aQGgD+30mgAXS4Sdk6rn862SiJa/L36og
         vtrRC+ZghbUxrPNNSEmgE6KaJl2/eKkI9f+wmU+Rj5aKKOXIxPVLhdfZthTQycN6KWz1
         a+iIyvMnvehRFtwDtjA2/stGBHWMFS3M3zx8JkgPWKDDXizd/BXTTuAGkd/mMh8y4GZq
         myoQ==
X-Gm-Message-State: AOJu0Yy0dS5Tyxv4/9nI/kZyz5dULIfBzcQhXzXABA41y8xSTJE2zZlr
	EU41x9Ur5r72PEWgDC6OsadKeN8C4QMGJ1NWDQn8eqTJsoQhOJpv8taA2qqBS84kXpif6w+xOXN
	LAxUo403xDgTBlNqkZgpEDYtPfBnd1tu9WWLB
X-Gm-Gg: ASbGnct4EDKswDbBTrJAcksHBWggT9YggJCZ3su/ie99YO2ahGCrSWfzH28uu6qgpJ4
	nbdataiYcLn5j0k6POkUeaUgWMMwC/JFscZB0FSD8ARMVw4uXlBIkzynO7nrKqS5kwJZxGzRHKJ
	NumU5q78ef3y2YP6bkFKett/ZNJcwIaOj0NiYp7WX9YQ+vQqFzz3M+ivmLj3mDkElr+hCMsf4No
	5bxKrYdqsrT3/2ctCpi2RCs
X-Google-Smtp-Source: AGHT+IF29FYnuzWbD7Sn9kzruNLO8IHcXj3Z2Z3AeewnB92LepxY48RilkxIi1RwwCdeKc/ng7IrLuCk8q/H4MoZXig=
X-Received: by 2002:a05:6512:6382:b0:566:41cb:66af with SMTP id
 2adb3069b0e04-57799cbb53dmr1891693e87.14.1758204954403; Thu, 18 Sep 2025
 07:15:54 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Clark 
Date: Thu, 18 Sep 2025 15:15:42 +0100
X-Gm-Features: AS18NWCygu6Z40U_cmh5wLb0JRP3ynb43j3aG3LHcHgw8_f6nRSjmj0TLDcqPs8
Message-ID: 
Subject: Xen Summit 2025 - Design Discussion Notes - Xen ABI, second session
To: xen-devel 
Cc: Andrew Cooper 
Content-Type: text/plain; charset="UTF-8"

Xen ABIs/APIs second session notes  (apologies for errors, etc.)

Andrew Cooper (AC): There are two classes of hypercall:

"privileged": ops such as: set trap table, PV load IDT, that must only
ever be issued by a kernel, and others such as grant and event
channel ops, because they act on per-domain resources, so mediation by the
kernel is required.

"logical": ones for userspace to invoke with general audit by the kernel, but
the kernel mostly just checks that the buffer passing is safe.

so: classify all the hypercalls as input to the new design.

Example design issue: separating event channel ops and domctls used during
domain construction from others due to the difference in privilege required.
Plan: split hypercall ops that are currently combined.

Longer term plan: Flask policy, and in general one entity will be more priv
than another.
Many domctls don't apply to self due to VCPU pause semantics.
Can't require kernels to know about hypercall parameters to know this one
should not be referenced.

So: need to evaluate what each (existing) hypercall op can do.

Yann Sionneau (YS): Q: before changing privcmd, need to implement the new ABI?

AC: Yes. XenServer has a filter driver in the kernel patch queue as a stopgap
for now, not upstreaming it since aiming for new ABI changes first; progress
slowed in discussion upstream.

Want to get to a plan, for example: XenServer will do ... , Vates will do ...
Have a stopgap for lockdown mode and a plan for upstream.

Christopher Clark (CC): Q: for background to this session: said previously
XenServer's motivator for the new ABI work is adding support for UEFI Secure
Boot, and Vates is interested for the Encrypted VM implementation:
are there other known major feature motivators?

AC: Edera's Rust toolstack is affected by interface stability.

Within XenServer, affected is mostly xenops, performance stuff,
"xenguest" tool for implementing save, restore, etc.

QEMU makes hypercalls and distros can't ship one compatible with arbitrary
toolstacks, although we also want to support PVH guests with no QEMU.

Tapdisk is userspace and using /dev/xen/evtchn.

Windows on PVH: there is a plan!
Can write a ACPI table to put initial drivers into Windows:
WPBT, and Windows will want the drivers to be signed.

Daniel Smith (DS): "Windows Platform Binary Table"

AC: Windows runs as gen2 VMs under HyperV - has VMBus with PV disk and network
ie. pure virtual environment with nothing else
so there is a plan for fully virtual Windows guest.

Alexander Merrit (AM): do we want to write a document for all the hypercalls,
since we stumble over things as we work on them?
DS: there are headers!
AC: previous documentation implementation avoided doxygen.
Plan: kernel document with the sphinx plugin.

AM: would like more than just the call plus arguments documented, also:
how to use the call to achieve a goal.

AC: an example doc is the "lifecycle of a domid".  is a precursor to
"how to build a domain".

A large amount of complexity is due to not knowing bootloader or firmware
options - is a lot more simple than people think
eg. build memory, populate images, ...
sometimes we put in hvmloader or ovmf or run pygrub in dom0 to get kernel off
the disk and put it in.

Hypercalls used to build a domain are not documented. libxenctl.

AM: valuable as meant to be a stable interface, so put effort into the document.

AC: docs are missing the higher level "how to start a domain".

Also relevant: Alejandro's plan, sent a while ago as RFC to the list, a
somewhat long, language agnostic fashion description of structs.

complexity is difficult to generate C that you would want to consume: if it's
not identical, or has complexity such as compat support, it is difficult.

Alejandro Garcia Vallejo (AGV): still want to generate in a language-independent
fashion, but it is hard due to compat.

AC: so can be done only for the new ABI.

Result is: for all hypercalls, there will be several changes to each operation
how it works.

Discussed other than using C to describe ABI, because
eg. struct handling by the compiler in complex,
it can and will make changes
so the canonical description must not be C.
Ideally text, and then generate C and Rust and Go, etc.

DS: like Intel and AMD table documents?

AGV: do not want to implement a new language to describe, but is ok to describe
fields one after another with preamble, for example, saying: no padding,
no holes, etc.
so you don't need to be so precise for each item.

AC: unions is a headache for any language not C.
so we want to avoid them in memory structure.

?: ban them?
AC: they are useful in C. eg. domctl: header, command, union
so we want individual ops instead, and then can drop
the existing unions with a different structure.
Is reasonable to say "no to unions" but don't want to
outlaw them since will likely need the option to use them.

AGV: the problem is not the union, it's the absence of the type.

AC: sched_op: has a union with a tag inside the union,
so you need to know that data before you can access it.

For reasons of Xen being an academic project initially,
a notable Xen book was published containing an exercise on
how to write a scheduler; it was attempting to be a variadic
call over multiple schedulers.

XSM op: hypercall that may or may not be compiled into the
hypervisor or not. Is an accident of the separation of
XSM and Flask implementation. Should create a flask_op.

DS: XSM implementations: dummy, silo, flask (plus possibly
another soon). Was written originally as flask_op though.

AC: and also want a way to ask what XSM is in place.

DS: do you want a hypercall per XSM module?
or to properly multiplex the xsm_op ?

AC: Would like to avoid multiplexing as complicated for bindings.

DS: but flask is very unique due to what it is being asked to do.

... (discussion)
AC: no known buffer

DS: theoretically a capability-based XSM versus sid-based.
If no multiplexing, then you have conditional ops.

AGV: with lockdown, there is a limit to the payload of ops: all
direct and indirect references must be marshalled ahead payload
for secure boot. They cannot be fully opaque.

DS: today you send in label and get back the SID.
Either you implement multiplexing or you need two ops.

AM: would it make sense to define a set of principles to
define hypercalls?
to avoid arguing over each hypercall?

AC: yes! this is how we (CC + AC) have structured the documents
that we are creating for this. Third document is about
Principles for Improvement.

Teddy Astie (TA): We want the new ABI to be somewhat stable, but
how do we introduce new operations to it?

Jan Beulich (JB): adding subops will always work.

AC: domctl and sysctl: we frequently tweak those.
domctl has an example of buffer sizing: will get an invalid
response if there is a mismatch: allows extending an existing op.
Can do this in some cases or may be better to add a new sub op.

AGV: See what Linux does: if an interface doesn't work, they
add another op.

DS: Could you consider a TLV structure for adding new items?
Is common in Linux.
AC: An encoder and decoder are needed.
AGV: a problem to avoid?
DS: Is a pretty straightforward format; just a suggestion to consider.

AM: Has the NOVA hypervisor been looked at? Their hypercalls?
They only have 5 or 6 plus a capability-based system.
Calls are low-level, very simple, so not much churn on hypercalls.
Can we take from that curated approach?
but they don't do backwards compatibility.

AC: We care about backwards compatibility, so that's a problem.

AM: Are the concepts in the design useful?
AC: Don't know.
AGV: Their IPC path is optimized to not take a long time. Xen took
a different view, eg. page-table walks.
eg. get/set cpu context: many bytes in vCPU state: could instead
be done by get/set each index, is extensible but would need many calls.
AM: Could we create a multi-op call?
AC: We have multicall
~end of discussion


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:52:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:52:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126253.1467882 (Exim 4.92)
	(envelope-from )
	id 1uzFzB-0003tk-HD; Thu, 18 Sep 2025 14:51:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126253.1467882; Thu, 18 Sep 2025 14:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzFzB-0003td-E1; Thu, 18 Sep 2025 14:51:49 +0000
Received: by outflank-mailman (input) for mailman id 1126253;
 Thu, 18 Sep 2025 14:51: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 1uzFz9-0003tX-Fw
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:51:47 +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 fb64a760-949e-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 16:51:39 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-45f2fa8a1adso17613235e9.1
 for ; Thu, 18 Sep 2025 07:51:39 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-32ed273e52fsm5762885a91.17.2025.09.18.07.51.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 18 Sep 2025 07: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: fb64a760-949e-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758207098; x=1758811898; 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=mkcFqcbtJTni0cLHegPKcXUH5nYMRFNY3ph4Pi0oGfo=;
        b=elMA3NvwFLROb4sa1z7d2YQtd4zbfmqRkC2GcQ4jl5CX1LQtfAPB5CJG3wK7TF1Iu/
         gLqvGrdLizhecocdW9voy7jLSt0PzflHSOUfXozNQy5dNIZOs0oJw5FY3JyrQdCYB5jW
         tNAAq6qNXZ8g6W7QofqkOsLNSkUTQUALM4G+oF5C+i4SV+rOZre0FRaNUY9eEpO4fD2H
         8wYmPP2/V5nMUJITH9Q2hQm0oRULpzKLK++tbw2HxcbFvMVAXoqQZjjDz//Z2j3KoY+8
         rmN+oZbuSRUkExOd5PyRR3UchD/eRtd+USjJkxPOhc16srv12oPXHXUfd/mooUrULGiX
         e20g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758207098; x=1758811898;
        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=mkcFqcbtJTni0cLHegPKcXUH5nYMRFNY3ph4Pi0oGfo=;
        b=Q+iP3b74mr7SPtUKINreaa5nMQ19CaDX+Fi5iNss7Xvcv0h5eo+S1kKEj4jbig4oSI
         keURwmAVTaUmL9W+NckXluJavGFA0lrcpC96uynw7rQfxymZy1E5iIqgh/Z80CA/E8W/
         Efyf1AZdVk4n4QNJrwm1oXNtJiivaqQTn4dOXoEX42ckd0ZzK8hIKvujSoqZvIKtCSC9
         4RQoDjVOEgTxETflu2mX2vBadwV4WQezCn0nVhfnPqUUcv8/AzzgerfjvD0SOajVAsSN
         +8YPfpdKZ6IXRRUl5wAZgNv00pKoEm2NP/SbLYProUfTpkToHA8POvzXv519WdMJxa2b
         cX7Q==
X-Forwarded-Encrypted: i=1; AJvYcCWsfqIiCWkUKqEb6NxVTLanAP5X18IQrP5zWBChzRbi5m5pdNmeX57pCnF0Rq39zI0HatphfBzqlWs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWNKQ32LmtesaQpaU8lJmm6yiCmrp2LngYEPOXPxZio08m55Bg
	O3BkVSLMlh/wgLcmNCHDw2llM4dlDlL//a7m0yt8zhTksbtCkzjEZLsMCeOH4OLPpw==
X-Gm-Gg: ASbGncvZkhr+vfpdtp7H4OR7ceViTxEB0Socbz0EKigE/vYJsf7CdA6jVDnCAPjohm3
	eSR0zCyo8MKj/gdIRvXc3zlJcIpxhkbLYoZputcrpRvFVCywLbaT4XDrLn/bdnczxYiDHmRmFFX
	NG6zZ5TKaD4fHN4Mo/3yNgyfbTCFLJYsqrwxvHwDc+4H+bSnNNQ5fSLJ+5kWa3edQ1DE3wtRaOL
	JGL6FjyIuEttoMJbfL+QJk082pGBqFc1q54xIKta39qWdU7WSB83SUzl5EvVDLbtyVcwF+GrrnY
	tSOjPPi0aOu7gZQkDP2BeJ8gjV4U0mxTywvZoPYvtUWB4i+xbR/+ZfCFNX0NpHX6wJ/pBPgBiR2
	EcgKdqxTNnEzxO5K3KEe34zrMvl1PG1CphN1EYEVWQ6EsSCU8MQ==
X-Google-Smtp-Source: AGHT+IF44L+QL593VS46mAuvrrAGaHXr6WomPwjNmRAa4fx/mFLPjh5UBbnjAblU16z8YH6lSCKaXA==
X-Received: by 2002:a05:6000:220d:b0:3ec:11a2:17f0 with SMTP id ffacd0b85a97d-3edd43ace8fmr3697970f8f.5.1758207098536;
        Thu, 18 Sep 2025 07:51:38 -0700 (PDT)
Message-ID: 
Date: Thu, 18 Sep 2025 16:51:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
To: Julien Grall 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
References: 
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@epam.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.09.2025 15:35, Julien Grall wrote:
> On 18/09/2025 13:16, Mykyta Poturai wrote:
>> +static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
>> +{
>> +    bool up;
>> +
>> +    switch (hotplug->op) {
>> +        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
>> +            if ( hotplug->cpu == 0 )
> 
> I can't find a similar check on x86. Do you have any pointer?

When CPU 0 cannot be brought down (see cpu_down()), tryin to bring it up
is kind of pointless, and hence can perhaps be short circuited like this?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 14:59:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 14:59:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126265.1467892 (Exim 4.92)
	(envelope-from )
	id 1uzG6O-0004iJ-53; Thu, 18 Sep 2025 14:59:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126265.1467892; Thu, 18 Sep 2025 14:59: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 1uzG6O-0004iC-2E; Thu, 18 Sep 2025 14:59:16 +0000
Received: by outflank-mailman (input) for mailman id 1126265;
 Thu, 18 Sep 2025 14:59: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 1uzG6M-0004i6-Jz
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 14:59:14 +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 079fcddd-94a0-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 16:59:09 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-45f2313dd86so9650425e9.2
 for ; Thu, 18 Sep 2025 07:59:09 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269802dec24sm28520165ad.95.2025.09.18.07.59.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 18 Sep 2025 07:59: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: 079fcddd-94a0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758207549; x=1758812349; 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=MTfkSnSYwiU5udv5diwAMqTPemsGptsgzUIXwiXjAHM=;
        b=MASaSB94nVG/8dRB/x4Q7dMVKUH3QFLqTOQXM9hJ17Ic1PHUcX5tF8PCRfd4LemKVZ
         1jnlLUCkH8qJ38VH0WR8xW01jonDTgX9rc42N0liMWbAVqb7AlxxY0oE8eM5JNv6KNu1
         EwGRIauP9qr0qNzaD4tnzje7v5ajH8cE44+Gp7BGxXM72GfdH/hcsxF6NFHxfPNTT7qA
         W/tfMF/QrUPmPQSNqHexlxN85gRgR2AMz1xCKdUY1BEfqpzycAKZDyJ3IoAAqsd5wlIB
         ctNe/CpjA41uAxnKsGwCnVweCrCxeXd90W+l9gz/oNOY80VtntbGfInC9JSiq27rRfsp
         6qyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758207549; x=1758812349;
        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=MTfkSnSYwiU5udv5diwAMqTPemsGptsgzUIXwiXjAHM=;
        b=LmdRM4ttIiwAWcqup3vwVnP91jn7JuXoaOBavDPQWVizs6XNjli/WxVPG5Z4qKyExC
         WdbnZ9Da2DTHrZMMW7B1n6NASlXhdiAbLM/y/QuwBCGCGdWOhz/1WSsQKsSwZGP8lC4+
         HUZ01DF81TisVBkGSULlg+77E00Mz0MwkhaeVYZoOo6Twtx3C3fWB5d9KvWec/xDL2Rb
         L7J47opa/MlM9Jp3/rWRCfMBMv82ZARUDzveyNoibwgOUkRPF3DH9n19fE/E3V74jCLz
         9/WEB0Ux1I3yNsiANoI69WwatUAHhj17s2WZXoynS/zQP1EtH7vhbSYys3va3fupwSF9
         ErzA==
X-Forwarded-Encrypted: i=1; AJvYcCVzvB0DyG1eGZ8Z13zXNt9zo20Twami1wv+BlruJ0RySxRPE+LmJFYFPjpon2pcgqWe5BXMvqhJnzg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2eny78C0K1AZa1oZeq9F6KJTvae74LQRAAp9RMgPjmgfrjBT7
	ejeDbk6j/AzfdmWvlGwlWSyjWMYqfDn7QBsgplN+Cet3u1qvOFXOuRLgZc7fTlPwdA==
X-Gm-Gg: ASbGncvanvHf49SaDLDonFFaarIp75qb5+YNn+UpQD1Qdpd1odPVK0SJhQNy1zvIjFj
	cjBo07ZqlF8wO9LMbrnS9cxyVJi3/WyBS73aulUBPiozkq7mLkS41ceVi5fjfq1+EBokkkVXQBQ
	eFx9iqQnDC9lB3XWg4GprkhXGOZya27lW6djJNFU7/LZ2gVgFfvB0Krgn6m2FuNhI2kRnTpEOcy
	aKwUtCsIWh3k5yit/KhSooSkDNH71ky4bd5wmjABU9oEKMa6qpYWa01Lr/JlEPoI/2rR9RayyDs
	U49nycxnvC6VyizcE+tOKWbitnEMUmFbeH7bcxr0g2kTd5iZBRLK4DivLZ2ii01KPzuHB/vULo2
	jbqLvls/+jDz5PLzA4mKa0saJUhGpChiOdeC4USUarrWZy4jNXw==
X-Google-Smtp-Source: AGHT+IH0+bxw/Xh3i0xQHHG1wNB7IZkixQekc0mjDdBAbUMZ4Nvc98UXDXX6wIVgutnADSb6YSFqsQ==
X-Received: by 2002:a05:6000:2512:b0:3ec:db87:e908 with SMTP id ffacd0b85a97d-3ecdf9afb8cmr5042088f8f.7.1758207548722;
        Thu, 18 Sep 2025 07:59:08 -0700 (PDT)
Message-ID: <337596e3-e522-4770-a64b-6c8137134739@suse.com>
Date: Thu, 18 Sep 2025 16:59:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
To: Mykyta Poturai 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 ,
 "xen-devel@lists.xenproject.org" 
References: 
 <7d10f4d063a55920acbb8d477b885552379a6116.1758197507.git.mykyta_poturai@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <7d10f4d063a55920acbb8d477b885552379a6116.1758197507.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.09.2025 14:16, Mykyta Poturai wrote:
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -1,5 +1,6 @@
>  CONFIG_ARM := y
>  CONFIG_ARM_64 := y
> +CONFIG_HOTPLUG := y
>  
>  CONFIG_XEN_INSTALL_SUFFIX :=
>  
> --- a/config/x86_32.mk
> +++ b/config/x86_32.mk
> @@ -3,6 +3,7 @@ CONFIG_X86_32 := y
>  
>  CONFIG_MIGRATE := y
>  CONFIG_XCUTILS := y
> +CONFIG_HOTPLUG := y
>  
>  CFLAGS += -m32 -march=i686
>  
> --- a/config/x86_64.mk
> +++ b/config/x86_64.mk
> @@ -3,6 +3,7 @@ CONFIG_X86_64 := y
>  
>  CONFIG_MIGRATE := y
>  CONFIG_XCUTILS := y
> +CONFIG_HOTPLUG := y
>  
>  CONFIG_XEN_INSTALL_SUFFIX := .gz

I realize you only do what is already being done, but I question this
way of doing things when the scope is tools-only. Any CONFIG_* put here
cannot have an identically named, but potentially set differently
Kconfig setting in xen/: Any use of such in a Makefile could end up being
wrong, and would pretty surely end up being confusing.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 15:15:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 15:15:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126280.1467902 (Exim 4.92)
	(envelope-from )
	id 1uzGLy-0007eV-CL; Thu, 18 Sep 2025 15:15:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126280.1467902; Thu, 18 Sep 2025 15: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 1uzGLy-0007eO-9Q; Thu, 18 Sep 2025 15:15:22 +0000
Received: by outflank-mailman (input) for mailman id 1126280;
 Thu, 18 Sep 2025 15: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 1uzGLx-0007eI-39
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 15:15:21 +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 4a48b4f1-94a2-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 17:15:20 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AM9PR03MB7773.eurprd03.prod.outlook.com (2603:10a6:20b:3dd::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.13; Thu, 18 Sep
 2025 15:15:18 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 15:15: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: 4a48b4f1-94a2-11f0-9d13-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NnxeLItOndXax13X+mAN83c9IWa0sjSTKmV37GYCpJjePwsUg8P+Z8j4MTFz8shfksuSxDLLF95UKntm/odtu6jK8EnQjDkp8/0sQiNY8zRO/fDi4QfQaDdGnyBiufDpuZsd++tUPZUiDJsmfNSYVSEw9dX7IUUsLfXmGDECc4GVdP1viI+7S/IvdU+q71ovS99CUlPSM6wKi1grHINN9AYKsy6h9FW4Cy2OIERxz12N9Ypq2GxGkMgwoPtd/O/IaIFnPK8Nwzi4nKaIFTegipXkTSb3F/YbCT05ka89IUdhA1tmN0+eaKfeTfy9hsTvfZL/Fp2BLlnCHGeOkozLuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A9IKaySqEZNszjYaZA+LnvfR+srgpuX3xSpmqyX04M0=;
 b=MkIbJwZjMMBxCTPddb5uQ+nhiQ1G7XekKfQ17yqqIFew8zI6Gnn83oq95cz+RRbprhiRcz/GrJH1SILnUNd1qpq1NXUJ0QiT+63EdKvcARdsXzTPqutfXt71F4wP4ikmMk7XrT2jCLXgLhN9FTdMIFJooDAWQBOaNiyQDwBM8HfRyePo5fC6VKvJ61Cb39pASTSNQ5Tv5a1+wESjXWlGLGztBp3RnisF1uhg81gL+r5tuQ4yc3BAgcuqpCD6WCfoAucL9sJfQhEzVxXKBr8BE2GqwVxfA+V2ewr6T95Wlv1rZIy82uq3YIuMPmYWBWTv9Hi2bM0YCcJX0gBvQzZsAg==
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=A9IKaySqEZNszjYaZA+LnvfR+srgpuX3xSpmqyX04M0=;
 b=HQrN3bQVL5E4PsjK6k0I3jNtPSnyJ8XsYRIttaUlkuGeBdYptnayZahX9zh4zZ8wfppqk+O7869ufdfwaL1LN8H7Gf9RDFfy7gZ3etF4EYUsjhzvHR4tUs6GjsRfWYVcvOlWDAwTVnbbeKwwpKGrVNBNAdfJSSKhGPK6ij5m6012h2ZN2jzEhymS/oMVAWhfGDRo/k+bNJA2o2bQoaXnM8vI+XPcgOieJFk0b/gUF++cc9ueyHg40lUrl2Is8dWATyqVLBW7yod9TDhqwG2HQxHLdRcMy1+hKLBzcChTgu188BoNrxVaxZXnY4zPjkCoAcvdfaw8Y4iBsELzibzp+w==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Thu, 18 Sep 2025 18:15:16 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: "xen-devel@lists.xenproject.org" 
Cc: Sergiy Kibrik , Jan Beulich ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <20250916134114.2214104-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-ClientProxiedBy: FR4P281CA0446.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:c6::12) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AM9PR03MB7773:EE_
X-MS-Office365-Filtering-Correlation-Id: dc11afcd-73b8-441b-d4c7-08ddf6c62d5d
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?SnQvRkNYWDY4U3Zxc1QxWjM4dmxoMXNhaFd4cjVmekI5S1hGT3BYcGRlMlUr?=
 =?utf-8?B?K1FadGU0WmNVd01FcjJOV3ZDczlnQ1crMU82ZUk5ajNvODBEeWFzakZ2TlZ0?=
 =?utf-8?B?TGRJVFJRV2UzN2xNVzl2L29kbWxOY3Y2ckd4cE40R2NjUm1JVHRrQTFIMlBG?=
 =?utf-8?B?UHF2UituMzhjUFhrYmxBLy95ZHdmeUc4dTNBZHVwVmZwTTg0U0tqdzg4ZTRB?=
 =?utf-8?B?ODlzcWVsTlkwWmhHTUczQ09vNjhZZUludndJcVN4N3VGMjRNM0tEaU9tOW16?=
 =?utf-8?B?ck11bkE1WEhLV2wzQmJyOTZxVXRQMXpDWjJ6MVlXc25lV3RRZ1hEd2VFUDJt?=
 =?utf-8?B?YnV0a1YyOHh0RGdUdWJxRlVnVHh5Tkp1ZTc1VUFUQjM3QUpWVWxNWHdORmdz?=
 =?utf-8?B?OC9LUXFIZmlrYXpVVEVCYWcxdTRlN0NLTDBORStRTURHV1YycFFnY0hkSnFH?=
 =?utf-8?B?am9RN0tnVGZPZDhyQVJyN1pCc2NEZ1JySWdXRjZrYWNBdmI4dGg4OENqdXpQ?=
 =?utf-8?B?Ukl4a0JQVkZta0ZYQVlGbTJnaWZobmtXQW1pcThSYkpOUzJlMzZhSEczcXl3?=
 =?utf-8?B?SGhldTdDMmw2ZEVaYTNVeEtydGVyTzJBZXpFNkNyNFJJZmlqekJaUXhTT3g0?=
 =?utf-8?B?Uzk5aXphWWlURENXWkUrQ2lFM2RIWnhwU1ZXK1NVSDRHLzh5VklZU2ZlMWdT?=
 =?utf-8?B?dDhDV2lSOVRCWWJnOFJHV0JnaUpCQkNlb1pVN2loNXRaRGNzenFUQXgrVUwv?=
 =?utf-8?B?TEJWK0JJMkY1L2NEVWFlYUptV2NMSVdVVGczYzBRL2szVnVCd2VXM3Q3b09L?=
 =?utf-8?B?algvUVk3V1d3NTlicVNEa1B5ZURiQkFvdHVzVVVKUjNidEt5Z3ZiVVUrem84?=
 =?utf-8?B?MkQ1ZGRPY1VqNUhJOUFkaVhSNlhIUks3VEtRQVZpSnBCTjVrQW56bk5CUW9S?=
 =?utf-8?B?eW95SkU5Y3c5UDUrTnYzKzhsQ3RsSUdwbFFPRkV2bGtvaVVrQ0d2QlNDLzVF?=
 =?utf-8?B?WDhnQVRtZFV6aFh5bE5Wb09LcysyakNPY3ZlZ1RJM2NKaVE4ZkYzWmdwdmdN?=
 =?utf-8?B?VzFwckRNcWNhQ3ZlNG00aGp5TnptZ3pUcjArdVBwTkhoSUwyM0tPWExjYnlS?=
 =?utf-8?B?OWVBKzZYUjdVWXVqWVdRMFJueUk0MnBIUXR2Z3lHOU4yRitaQVpMcHEvd1ZH?=
 =?utf-8?B?Sk1VN1BudVpXU3M4NUNXYUt1eTY2YjFkdlNrczV5anNyVDNyR0JVeTJwU05K?=
 =?utf-8?B?eExucEJndE1uMU8xdHMwLzVUTGYxWG41MUw1UWpsWjJuMTRscEptRU1KdlR2?=
 =?utf-8?B?c2Z1UXJEek0xU0R6OUhwd0p2TUNYejlrTTJBWC9QektnVythWkRnejFlV0E4?=
 =?utf-8?B?VFdhSlB5TDIrUDRCM1JZVklDbmJnQ21PcG1XQVEyWnRobTBBZEx3Vm1iSVVy?=
 =?utf-8?B?OVJ2UWgrNnBQaG9CQXBMN2xZelI5M3dQenhMa09DVDZpdEFyM1pleldMejVo?=
 =?utf-8?B?NGZrUVNQY3FWQUJDcndwWUk5Z0ZscmVkQ2NvalFaQkd5R3BwT29SRnFkR2xx?=
 =?utf-8?B?amZBYXI0VmMwbFhUT3pYYWhTQWh6TllpYWgrNE5qc29oRko3YzRQOXlpN2Za?=
 =?utf-8?B?eFYreDB1MG8vdDRyTWhYRVIvTmZZUkhPRmh1MDFXNEgwUzR4Rm02Z2lHaWc1?=
 =?utf-8?B?d2xPOHBvclUycGlEdk5LS09HYktleCtWanlqWk40STF2d2xKNlVMV1ZuMk4x?=
 =?utf-8?B?ZlRFcERGVzdWOUk1a0hWTTR2MzRrZ1NVUXlGOFIxMjdPVEFBQmh6bWlWR0Y5?=
 =?utf-8?B?bE1SWWpBWC9aM3loald5TjBkQ0pyait4d2ZTRlJCUmlMTFBjbHZFbGJGWlQ3?=
 =?utf-8?B?YjRQSVVTU1JpYXlpQVZRRnRrbzczS0lsZmVsS1FFelBpdlZPK3dwTTRKbkE0?=
 =?utf-8?Q?L5RRVGCOA5s=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VnpnSjRwTFhsYW1OeGM4Y29ML3Q4ajlxQjVkWlVsWkQ0d1NoVUc1MUVseTJ2?=
 =?utf-8?B?R3R0UHN4Z3cremc1dTF6dzlwMTB2RFE3Vi9QSXRYdVM0NHlzSnlxWEY0cExM?=
 =?utf-8?B?SGMreTBHcFRzUFVsb1dkSFlsRURXc3FIVnNnL21mMGFXL3FBL3FhYVJ5bjJM?=
 =?utf-8?B?S1lFeERuczFvVUt0YWRmbUZhVkhVZWMzWlcxU1lXRmM2Y2xmbVZRem8wbE5Z?=
 =?utf-8?B?THhTQWZTQkwwV2pBUlBjeEVYcmFnOUl3YlNmajI2RzJGZGtPSEpZcy9MdFJq?=
 =?utf-8?B?dExJeU5yL29tUUpZQUcyOFIvRWZWcGdCRUhPckI3ZytnVEc2dm0vQVFWUS9U?=
 =?utf-8?B?eTZvY2FvUzZ5NThOZGxBeCtqN253M2t1bDl0RjFiay9hdS9RUTk1aHkrbFlo?=
 =?utf-8?B?LzhLWVFOOXIwUVcxRDErRzlrMzArNXFtcXp4Q3dzN2NBTVlLRStaNk1aNisw?=
 =?utf-8?B?elFJWHBiWjE5R3g5QjhhMHg5SnhHdGxJb09UTG5rUGdITjY1MWR2NmRqenhM?=
 =?utf-8?B?Y294dzJlaC9FV0M4Tm13a0JwSGpVeDc4eUFCTFdaZjJObUJ6OUFpK3IwaWJv?=
 =?utf-8?B?enhpVFp6ckVPOFo2QTVBNm9aemMwM3NtV2xNUVB0WFVGazhQbkwxdWlwRHFX?=
 =?utf-8?B?S1BVQklzZFhMUUpqamRWdTJYR3IrRVpyWlFxUjlPZEpLRkE0NW9ONHRaelJY?=
 =?utf-8?B?YllCTUs3SitxRkdrMFc1UnZQN3l3MlloYlNoN1hYUzMxTUxDdVhHZktraUVs?=
 =?utf-8?B?RnhzRzFHN0NaRE41TXhTSnYvQU5YL1ArL2JBbE95Vjd1ZnpBQ2ZxQWtOOWsx?=
 =?utf-8?B?dEh6Ukxnazk5V1RMTUI5NjlwOEs2UG91N0tRM0QyQmlHTmxkTmVWc2hlV3My?=
 =?utf-8?B?U3BtaE1MOVJxMlVBVldxYVY3MlZoTUVxUCtNSUt6M3dOREo5bWNNMHo1QlFG?=
 =?utf-8?B?aFlpS3M4NHNLVVhHL0ZwQlB3am9na1l1NFVTSm9YNEZQK1plVGNZQS9Eclhi?=
 =?utf-8?B?ekNGZXBXNWpKenhFbytwdDFGK2RYMmdNVk5aeFRYN01aNXZuMVRBL01RdFFS?=
 =?utf-8?B?VVljSU9VbmJyK1FkcGF2UmduUktNMTY0ZktFZmlIUzBGaGdHVXJyL2VsMC83?=
 =?utf-8?B?cHNGYmcrTXFtK2kreW9TbHJ6QVdub1ppOTJzVFBEelZxcXNLdDBmenQ3a2lZ?=
 =?utf-8?B?bDF6NXlrNHM2MUhiY013Z2hWM0wvQmRDekhDaW1xVmdYaXhrMGF4ZGRiZDVP?=
 =?utf-8?B?eHhuaktBMEJkdE9peDd5M2VWTlN5MG1nVWJvVXNORytYQmVPbnR4amNINWFT?=
 =?utf-8?B?UEZRUk16TCtJeXdVcEcvRGxhZHhXY0poU2lTcGVFR1I0M01RckVvdmcyeWFw?=
 =?utf-8?B?c0l2Z2FZMXFXRFRzQWN0TGNpU01nTVNZK3FUUU0yWjlBbVlWcmUwTVJTVE9z?=
 =?utf-8?B?SVUzQUR6ZTRJcDcyV0R6SmRMeU1KZVdkbkxNT3BrTlNPejVyYkYzbWQwbG4v?=
 =?utf-8?B?amQ3QlFlOUpwek02Mk1pSmlRZDBOa1d4aWpmYTFBOHRIMEV4QTdVSzZTK0ho?=
 =?utf-8?B?L0xsOTdVSmtNMFZza2ZZMDBnOFdVdVF5NDQxRFJoQ3FDaExiUjVqcXhQeEJR?=
 =?utf-8?B?cEYyeXZ4aVJod2pWNjl3bzgzRFhuYVN0TFJST0JzY1lBSFBIWWszUVI5Q05j?=
 =?utf-8?B?L3NqSmZhVzJnQVMzeTVzTldXcGtqM0ZZMUZLNWQxdTh5eVJ0ZzNQWk5yaUM4?=
 =?utf-8?B?WGNVRmtHUWllTUVxRXlFQ3FvcGUveWVrbUtzd3FUbk84VzV1bHB1QWlZUXdX?=
 =?utf-8?B?VXZKRU9MR2pLbXZONHF6V2IzdkhDRWNFV0sxaTlrK0krWkZBSGFaWll1UHNu?=
 =?utf-8?B?aEF6QUZmTTB5UkZkR0dLa0VNTEdXTG40NjZUY2FRZE1FWmJHMXU4SzJxVWtv?=
 =?utf-8?B?cWlYSkNiSUxZOFFYY3QwY2ZOYk9NQnJ2RFV5eEVKVUZuK0J2NUU4b1F4MmpD?=
 =?utf-8?B?RGpDeEtSdVdWWjFCbGFxV3NvYjV1ditGUHlxYlRaZ3BGb3RGU3lzdjFwUi9a?=
 =?utf-8?B?bng0UWZ6dHU4MStreFZrdjhGYXNNVytJMndxQTBOS2E3VHIxTGlabndINDZS?=
 =?utf-8?B?M2ZoTzJUK0Z0bW9YQTBwV1dhOTlKbUtpRlFGejh5K3BBd1NRdnNvQ2lISm9D?=
 =?utf-8?B?R2c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc11afcd-73b8-441b-d4c7-08ddf6c62d5d
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2025 15:15:18.3037
 (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: 9w4DZvfYvyaY/Tp1Sb94oeyJtEGZt9TAIyMxJrBLLGi4cljngOIPcOyItEM7UeVbM24uCwYBK3thrRkpMDZOJyyy7eAAQdWocEazmeRP3iI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7773

Hi All,

On 16.09.25 16:41, Grygorii Strashko wrote:
> From: Sergiy Kibrik 
> 
> Add config option HVM_VIRIDIAN that covers viridian code within HVM.
> Calls to viridian functions guarded by is_viridian_domain() and related macros.
> Having this option may be beneficial by reducing code footprint for systems
> that are not using Hyper-V.
> 
> [grygorii_strashko@epam.com: fixed NULL pointer deref in
> viridian_save_domain_ctxt()]
> Signed-off-by: Sergiy Kibrik 
> Signed-off-by: Grygorii Strashko 
> ---
> changes in v3:
> - fixed NULL pointer deref in viridian_save_domain_ctxt() reported for v2,
>    which caused v2 revert by commit 1fffcf10cd71 ("Revert "x86: make Viridian
>    support optional"")
> 
> v2: https://patchwork.kernel.org/project/xen-devel/patch/20250321092633.3982645-1-Sergiy_Kibrik@epam.com/
> 
>   xen/arch/x86/hvm/Kconfig              | 10 ++++++++++
>   xen/arch/x86/hvm/Makefile             |  2 +-
>   xen/arch/x86/hvm/hvm.c                | 27 ++++++++++++++++++---------
>   xen/arch/x86/hvm/viridian/viridian.c  |  8 ++++----
>   xen/arch/x86/hvm/vlapic.c             | 11 +++++++----
>   xen/arch/x86/include/asm/hvm/domain.h |  2 ++
>   xen/arch/x86/include/asm/hvm/hvm.h    |  3 ++-
>   xen/arch/x86/include/asm/hvm/vcpu.h   |  2 ++
>   8 files changed, 46 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
> index 5cb9f2904255..cf2726ef6bc3 100644
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -62,6 +62,16 @@ config ALTP2M
>   
>   	  If unsure, stay with defaults.
>   
> +config HVM_VIRIDIAN
> +	bool "Hyper-V enlightenments for guests" if EXPERT
> +	default y
> +	help
> +	  Support optimizations for Hyper-V guests such as faster hypercalls,
> +	  efficient timer and interrupt handling, and enhanced paravirtualized
> +	  I/O. This is to improve performance and compatibility of Windows VMs.
> +
> +	  If unsure, say Y.
> +

Actually there is a question for x86 Experts -
Does it make sense to have HVM_VIRIDIAN enabled without enabled AMD_SVM/INTEL_VMX Virtualization extensions?

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 15:19:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 15:19:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126292.1467914 (Exim 4.92)
	(envelope-from )
	id 1uzGQ7-0008Qr-U7; Thu, 18 Sep 2025 15:19:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126292.1467914; Thu, 18 Sep 2025 15:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzGQ7-0008Qk-Q2; Thu, 18 Sep 2025 15:19:39 +0000
Received: by outflank-mailman (input) for mailman id 1126292;
 Thu, 18 Sep 2025 15:19: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 1uzGQ6-0008Qe-Bz
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 15:19: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 e3980e74-94a2-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 17:19:37 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3ee12332f3dso833271f8f.2
 for ; Thu, 18 Sep 2025 08:19:37 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269802fdfdfsm28729315ad.102.2025.09.18.08.19.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 18 Sep 2025 08:19: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: e3980e74-94a2-11f0-9d13-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758208777; x=1758813577; 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=ZbwCz2lCCCWc3XO4MtNdHpZcqN+Y4d1Inqq2N7dk448=;
        b=GojYeGh4v6iCpVD3tCj8EpTlHHDAhnI2cwGS2P2SEIBw4e7xL0+tmFEQD5jrLcKqEZ
         Quf8jj42rNSSuttpoyrLiRMblznjXE42nfQEnTjWoGvVfvrs4p0EDi7Nnp5q1sc3Cr+R
         UPbqMYS9DaxBDThJXHxZFT40ApN0iO9d1sX/vey+QJ9cCLXHp+1N+J/ZbG9D7H7l39Iz
         tfuRKKTVCxBhDvdwSqqfRfHBMW4yCxNM5u5cXRmVPb9aXMcb3ahXLV0OVZSeyccxnPNJ
         vx7AtPSCbbDGBLE4zFjf85DA3lNLemE52uaNdv/ZKz3R58HaJtz2TOlcysTqZV6GtHSV
         zaTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758208777; x=1758813577;
        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=ZbwCz2lCCCWc3XO4MtNdHpZcqN+Y4d1Inqq2N7dk448=;
        b=g6ujI05C+kohCvzzlMYQJMwZDYnD5zeZcGCCv2T5jKmxMi9Qcd5LUxZUBFi+Lzm8je
         70pzVkPcb9j4bNZoGFHvAadamw0VSquzkgsvzgfc1tnojpS3blc1QnPgCdjHWADoKh4H
         uVKPupjGrg0cnblYHFmHsBd7gDUCj+vuFOasl1l1p0BtvSlhwMpFubkKcU9y4C+NvKOr
         7LgGSj+L0kgCBZJ6MW9f5CasMxV3Ti/n7yz3Sqp/NeegJgYz/2Y+BOX5GgfTQemcS1B3
         7za9BR9fWk2BXI5CCapnGJKWrI/xrlVOkDkdNM2idUvTq5F/29yI+41TV2/yY13kyfYv
         CJFA==
X-Forwarded-Encrypted: i=1; AJvYcCXH273hSAQtCU4jRLTuo0/atvD205uLk9OuynH2xN/8SzjiX+qoRNzP9feeo7El30n9X8Yr8EHbeTI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzO4x4oNn5uPACZor5/2GqOEMHViMGCo7uOPTZZbtRQx8qjn0dI
	AA3xWhgMbIqTU6IGdKp8v7cpzY16XjIzgNhaBrX7/cBhXLqVq5mQZCuKphl9ZpKBNw==
X-Gm-Gg: ASbGnctPk7dP7jrmy607tJYB8Sc0E2k89MX+r8cvCon15qTx9nBV75cnYXsUqyauzgF
	uqgnZVFHso/DdFizDfVXCXeYyivN0oX3l6dV4yeY0BHzXIyWU7CHLF5Fo54oZ0aby9iM7ePeoUE
	NvgRXx9BeGXSzo8Osw8mZlaEIqn4J9MUp+WRtiQWZFd+Y6qPIxaWke+q/BdD6det/XX9diswKNH
	w+Oyoqc7tp8a0cADKswdqTfhvh6HgFPPSXxyB8l6ynUcBXsskoglPG3QrrWNVn4u4fKXMbKdAOa
	j3/kee5zITUpg1qx1pED2R//Zy817s06kQJpIRma5E5geNnCHkXfVtQk7aSYAwZrYKinZxJGC+G
	3LB7oioN3id9tef71iDoqEIcwGKD20NNGBIxXw4i/0VEYMJzl5g==
X-Google-Smtp-Source: AGHT+IEcLMrwFF6jAGGjQD0Df2c7egQCSUUfiv7iLG8h9pjhMHCTQ8rmyzMoLPBmp1A18j7JieYXaA==
X-Received: by 2002:a5d:64c8:0:b0:3ea:e0fd:28ea with SMTP id ffacd0b85a97d-3ecdfa0d2e6mr5337896f8f.39.1758208776523;
        Thu, 18 Sep 2025 08:19:36 -0700 (PDT)
Message-ID: 
Date: Thu, 18 Sep 2025 17:19:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: Grygorii Strashko 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.09.2025 17:15, Grygorii Strashko wrote:
> On 16.09.25 16:41, Grygorii Strashko wrote:
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -62,6 +62,16 @@ config ALTP2M
>>   
>>   	  If unsure, stay with defaults.
>>   
>> +config HVM_VIRIDIAN
>> +	bool "Hyper-V enlightenments for guests" if EXPERT
>> +	default y
>> +	help
>> +	  Support optimizations for Hyper-V guests such as faster hypercalls,
>> +	  efficient timer and interrupt handling, and enhanced paravirtualized
>> +	  I/O. This is to improve performance and compatibility of Windows VMs.
>> +
>> +	  If unsure, say Y.
>> +
> 
> Actually there is a question for x86 Experts -
> Does it make sense to have HVM_VIRIDIAN enabled without enabled AMD_SVM/INTEL_VMX Virtualization extensions?

It makes as much or as little sense as HVM=y with both of the ones you mention
turned off. Iirc Andrew in particular wanted to permit such configurations, to
allow to prove the (abstract) correctness of building them, even if the
resulting hypervisor may be of little use.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 15:29:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 15:29:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126307.1467923 (Exim 4.92)
	(envelope-from )
	id 1uzGZo-0001r3-S3; Thu, 18 Sep 2025 15:29:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126307.1467923; Thu, 18 Sep 2025 15:29: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 1uzGZo-0001qw-PC; Thu, 18 Sep 2025 15:29:40 +0000
Received: by outflank-mailman (input) for mailman id 1126307;
 Thu, 18 Sep 2025 15:29: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 1uzGZn-0001qq-K7
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 15:29:39 +0000
Received: from zero.eik.bme.hu (zero.eik.bme.hu [152.66.115.2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49843575-94a4-11f0-9d13-b5c5bf9af7f9;
 Thu, 18 Sep 2025 17:29:38 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id CC4D856F30D;
 Thu, 18 Sep 2025 17:29:36 +0200 (CEST)
Received: from zero.eik.bme.hu ([127.0.0.1])
 by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP
 id kz7_8Rgw4BnB; Thu, 18 Sep 2025 17:29:34 +0200 (CEST)
Received: by zero.eik.bme.hu (Postfix, from userid 432)
 id C875B56F2AE; Thu, 18 Sep 2025 17:29:34 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by zero.eik.bme.hu (Postfix) with ESMTP id C493656F295;
 Thu, 18 Sep 2025 17:29: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: 49843575-94a4-11f0-9d13-b5c5bf9af7f9
X-Virus-Scanned: amavis at eik.bme.hu
Date: Thu, 18 Sep 2025 17:29:34 +0200 (CEST)
From: BALATON Zoltan 
To: Peter Xu 
cc: Akihiko Odaki , qemu-devel@nongnu.org, 
    Alex Williamson , 
    =?ISO-8859-15?Q?C=E9dric_Le_Goater?= , 
    Paolo Bonzini , 
    =?ISO-8859-15?Q?Daniel_P=2E_Berrang=E9?= , 
    Eduardo Habkost , 
    David Hildenbrand , 
    =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , 
    Richard Henderson , 
    Helge Deller , 
    =?ISO-8859-15?Q?Marc-Andr=E9_Lureau?= , 
    "Michael S. Tsirkin" , Gerd Hoffmann , 
    John Snow , qemu-block@nongnu.org, 
    Keith Busch , Klaus Jensen , 
    Jesper Devantier , 
    Marcel Apfelbaum , 
    Nicholas Piggin , qemu-ppc@nongnu.org, 
    John Levon , 
    Thanos Makatos , 
    Yanan Wang , Jiaxun Yang , 
    Daniel Henrique Barboza , 
    David Gibson , 
    Harsh Prateek Bora , 
    Alexey Kardashevskiy , 
    =?ISO-8859-15?Q?Alex_Benn=E9e?= , 
    Fabiano Rosas , Thomas Huth , 
    Laurent Vivier , 
    Peter Maydell , 
    Aurelien Jarno , 
    Aleksandar Rikalo , Max Filippov , 
    =?ISO-8859-15?Q?Herv=E9_Poussineau?= , 
    Mark Cave-Ayland , 
    Artyom Tarasenko , 
    Alistair Francis , 
    "Maciej S. Szmigiero" , 
    Bin Meng , Stefano Stabellini , 
    Anthony PERARD , Paul Durrant , 
    "Edgar E. Iglesias" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
In-Reply-To: 
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp> 
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Thu, 18 Sep 2025, Peter Xu wrote:
> On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
>> Based-on: 
>> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
>
> Could I ask why this is a dependency?

It removes an address_space usage from raven so this series does not have 
to change that and I don't have to rebase that series. Otherwise these are 
not related. I'll check the problem reported about my series and send an 
updated one.

Regards,
BALATON Zoltan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 15:41:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 15:41:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126318.1467932 (Exim 4.92)
	(envelope-from )
	id 1uzGlQ-0004aZ-Tb; Thu, 18 Sep 2025 15:41:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126318.1467932; Thu, 18 Sep 2025 15:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzGlQ-0004aS-QR; Thu, 18 Sep 2025 15:41:40 +0000
Received: by outflank-mailman (input) for mailman id 1126318;
 Thu, 18 Sep 2025 15: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 1uzGlP-0004aM-Np
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 15:41:39 +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 f6f7217c-94a5-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 17:41:38 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3ece0e4c5faso1317779f8f.1
 for ; Thu, 18 Sep 2025 08:41:38 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269802de635sm29296045ad.82.2025.09.18.08.41.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 18 Sep 2025 08:41: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: f6f7217c-94a5-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758210098; x=1758814898; 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=c37evmbGxCNIzKG67AS/sRjwa/HfkKZUwl+jhxZ/Llg=;
        b=LZWKapQQT9PhV36Sk24RNX3dFzRSxyo3eFvfpMSrAUXHW3MsF/PSu+Y2bMptqzwkT6
         1l9DROC3bhrVT6k+oD30q3p5dQenmJsF5xKv6rgqas27SG0d3KpQ6i3lvN5yupVuVqCv
         HYGaEIynAL62oZbECts4FcjPZWdxEQivp1VH5DTqXcsWJtzGK0DnL8iKicU55Cahb99j
         ZYBsQcBj2rohFjd8fG6lFN7wUAFPrSa3fb6du4t9dzFo4n8+5ioC8pj/0hlzKnKNh5mU
         Eu77Dc1O4pwYctu6kJs3VoANyBwkDTbun2xMyWsKN3rzU6LifS+MK/6YyiqfXF9vfdsS
         oIew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758210098; x=1758814898;
        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=c37evmbGxCNIzKG67AS/sRjwa/HfkKZUwl+jhxZ/Llg=;
        b=vbsgR04QVy36+2ASae3V4gijY45lwEWLW3ZEt75NNKFdEYjH42WsYFFkR1fUCUE3nv
         siXnWQN6ZAgQ7YEfpS9m44qTkCmh9QTQeFLERkYsRjoeLlfza+8KOeDl6QdJBRlJEv1h
         ZN4P1yiRmIE7YKf8SZZziz0rHIqqExs8m9v1JsT7+u0B0zV8JnCiMOZC2flG1baNbXPO
         D8vf8i3qTAqr4eqlalddRgzcquwzi+v8WPa6jygYG6IjyT8Nm6N5w2yDNCC4ewWk6g2S
         xYQid1zfsyIsvmwcPCJIrGeE8+44wVybdN6YfPezdAkSmaRJIfP/LOBo9KZ8WGzJdlR9
         1XLg==
X-Forwarded-Encrypted: i=1; AJvYcCUtLu+9zMGTs1cgJBYAEK/Zg1+ULT5uO0i0YvvIbHSPWYPiFZw4rDj5k1mV+lN3YdNamlhVgsvZhmM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyO+SYMM7JfYgkkz9QZnYdZHQStT/fXN6wqlZ6+YAizkOqdlzUX
	7tLoWMEtIUmn4FAdpjZQ6U7LVW58i4+gAtkXbDaxXN8IJzuAqO86zrD9FiI9r/4BQA==
X-Gm-Gg: ASbGnct9capezK3WqzkKde0qzJdug51l1HJRMzD+amhhWHqHILomqXRmaknMQ9XuOPZ
	h3ApeTkECfYwJLRcJBfJn2rsNTrJMeKg1Qw/qSXmEEEroq6QDhodEeM4LdfcIXI5/aMrmM960yR
	V2AmY4uz9xD2lPeG4juOzikfO2jGCHh7okXbqfObkMFaguAeYfWxbo3/JsCE9jc0drPQBpmR6EZ
	U+b+7Rkryyz/XBiodcBjUsa9DNn/yrTgMi5jZAFBPNTelnVe8e5R5+DFISFXby1YmcwM+Tdnmp1
	nH+rozfdCnUKnG4uWXEmGu4TLLa/y5YCB8tNWdfhVQcu8une96bKVNxFWeD6UedkEZdyw6n6o7p
	3LmO0d56bdxlJkYDcI2+7iND2XArPf3+fNZ6BnzIuivOPBjUVFw==
X-Google-Smtp-Source: AGHT+IHy8YCk/qfMnyKOefto162rdksCO/pWGrBji3fdf/NhaCTAjlBczuM8W7NcWYabpNWuflWKow==
X-Received: by 2002:a05:6000:2902:b0:3e3:6b81:b482 with SMTP id ffacd0b85a97d-3ecdf9cb452mr6222209f8f.28.1758210097766;
        Thu, 18 Sep 2025 08:41:37 -0700 (PDT)
Message-ID: <0e1a6339-a4fb-4697-acfa-392168b391d4@suse.com>
Date: Thu, 18 Sep 2025 17:41:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: Grygorii Strashko 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250916134114.2214104-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.09.2025 15:41, Grygorii Strashko wrote:
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -62,6 +62,16 @@ config ALTP2M
>  
>  	  If unsure, stay with defaults.
>  
> +config HVM_VIRIDIAN

I may have said so already on v1: I'm not quite convinced of the need
or usefulness of the HVM_ part here. Viridian necessarily means HVM,
aiui.

> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
>  {
>      const struct domain *d = v->domain;
>      const struct viridian_domain *vd = d->arch.hvm.viridian;
> -    struct hvm_viridian_domain_context ctxt = {
> -        .hypercall_gpa = vd->hypercall_gpa.raw,
> -        .guest_os_id = vd->guest_os_id.raw,
> -    };
> +    struct hvm_viridian_domain_context ctxt = {};
>  
>      if ( !is_viridian_domain(d) )
>          return 0;

This check doesn't check for vd being non-NULL, so this still feels a little
fragile, even if it looks correct now.

> +    ctxt.hypercall_gpa = vd->hypercall_gpa.raw;
> +    ctxt.guest_os_id = vd->guest_os_id.raw,
> +
>      viridian_time_save_domain_ctxt(d, &ctxt);
>      viridian_synic_save_domain_ctxt(d, &ctxt);
>  

Just below here we have viridian_load_domain_ctxt(), which I'm pretty sure
now also needs to gain some check: Save records coming from user space, we
can't really rely on there being none of this type for a non-Viridian domain.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 15:54:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 15:54:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126330.1467943 (Exim 4.92)
	(envelope-from )
	id 1uzGxg-0006IO-Uu; Thu, 18 Sep 2025 15:54:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126330.1467943; Thu, 18 Sep 2025 15: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 1uzGxg-0006IH-SJ; Thu, 18 Sep 2025 15:54:20 +0000
Received: by outflank-mailman (input) for mailman id 1126330;
 Thu, 18 Sep 2025 15:54: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 1uzGxe-0006IB-U6
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 15:54:18 +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 b9111be2-94a7-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 17:54:13 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3ee15505cdeso372581f8f.0
 for ; Thu, 18 Sep 2025 08:54:13 -0700 (PDT)
Received: from [172.20.3.155] ([12.157.112.82])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54ff437784sm2630563a12.47.2025.09.18.08.54.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 18 Sep 2025 08:54: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: b9111be2-94a7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758210853; x=1758815653; 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=GhSMs68KB4zvHKuNzIr4t9C+2trQhoZOnppeZF8v5wk=;
        b=ASkql0cCjb9FaQDBtucwJqyD6toAVjIy/iZU+9AQdVU7AlFTy3kUHVg8z7CuSGmb/A
         ZU9hvtyRSQa4QkGvLtSdScZfgRZ6DDYLxBXWtApvnqQINf1/Cio6UQQbWX6YWmm2RCAp
         Hkl1uiTb5arh6QCtMN/0YxjvtUhdW2jkvklC5cNfO5PNLAdTqZiaKahZblNczVGm17hh
         /cKwb1N7Q4tCsIfymVsu6MfxN4NPTBqUxQ0z4Rg2y4g0kUOAEpMbPDRubkoFN2R11g3D
         zFn8LoIzHNpACQRD1yLshluPaDp+I3USbny/8pQZU69LEk+OIExml8Wo4+ajWiesMOLs
         rckQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758210853; x=1758815653;
        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=GhSMs68KB4zvHKuNzIr4t9C+2trQhoZOnppeZF8v5wk=;
        b=hkJnFTqlbQJxoTLnyOLIFzOb6gH++a6Y0SHuebRZZhky3eLTtSlfG1v2M2W/rgDewS
         cOlEj0fgUuzQ/knTkAOXtx9z+sDCHkPRqSWwQMIwR47GEbKLdeAds4eNud9lJSzOnbl7
         kgvPyg1SbnbPsgDiFqa1Tp3d8/pweBvP7/wj2oEGOyPWkl5wcXjMAbgJwIMrvd6SUwTe
         KQfl8JkeM8VtEgJR6dib/zHQ8f2/P/sJYTUtdURc59f9qs28YXTIgA4f6f1dQpC2kxje
         Ly4jlOzMnTpI9GuCc06pjwJfr3Tz2O3nDo8DiQn5SlCD18oA9qKO2J2vjZxf8AnKxssz
         IysA==
X-Forwarded-Encrypted: i=1; AJvYcCW1yB1uHCmq9QjGfaR6ED+UPsW5wf0Ar2FzsZRwFUypu2y6gFGPps1kx5oHvQ8uL8polm06+B8mpzA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPaMh5/AfBeHR9Z04gpbm7Im8p+aQBWBhUchfNwsGNaLdFTY7V
	hXVLgBrCC7Za3V5r4iD8z7cUb2DI3UZQdElM42VvVrlcMRHgCTU4mYSswanBWYCUDg==
X-Gm-Gg: ASbGncsY7clx9EBBcSWJyVWc2kBaREkCrikgz4JI1dLReUd9yUs0YWsHiN1KznoJ+u5
	sZkZ5mjFmayj8/RzJKMYMNLp1cyJPcBjZz9WcF7RmiTy31MNDAJP16pguRoIupqtwsDAL+OYfa0
	H1y0zv45WnAlQ8qZqQb0LmxY05Cy8BG7J4gVrwfq+LwLJmCHnbOkYg0/p2C7mjMfU2/fdoKmDpv
	Q+rsEoU5ILERWTdMHllGQU6W4smVuyPta6plQCIevqgPDzh/tBC0mUvKW71g+3I2puWsuK6KPh/
	Ll1e8l1gLNaQYKzny2VwFfoMTTOK7scxKwY7M/iYZ8riCnFdnEh0O+qNabXWHodQhlQ9PzER4Wa
	RyZfrEVnAcKa8r0BQ0E4htsBzTj53ar6sN75hEZnCVhdXM6/VXA==
X-Google-Smtp-Source: AGHT+IGYj8uD0vI2ehpiu8cFKj9q3CPXxcsGgjFLOvWZ9CjSc7N3Fo8eOzW5QbvEh6b2PFLTUdxfpA==
X-Received: by 2002:adf:a3cd:0:b0:3ee:11d1:2a1e with SMTP id ffacd0b85a97d-3ee11d13550mr1946442f8f.10.1758210852802;
        Thu, 18 Sep 2025 08:54:12 -0700 (PDT)
Message-ID: 
Date: Thu, 18 Sep 2025 17:54:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/18] xen/riscv: detect and initialize G-stage mode
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: 
 <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/p2m.c
> @@ -0,0 +1,91 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +unsigned long __ro_after_init gstage_mode;
> +
> +void __init gstage_mode_detect(void)
> +{
> +    unsigned int mode_idx;
> +
> +    const struct {

static and __initconst.

> +        unsigned long mode;

Here and also for the global var: Why "long", when it's at most 4 bits?

> +        unsigned int paging_levels;
> +        const char *name;

More efficiently char[8]?

> +    } modes[] = {
> +        /*
> +         * Based on the RISC-V spec:
> +         *   When SXLEN=32, the only other valid setting for MODE is Sv32,

The use of "other" is lacking some context here.

> +         *   a paged virtual-memory scheme described in Section 10.3.

Section numbers tend to change. Either to disambiguate by also spcifying
the doc version, or (preferably) you give the section title instead.

> +         *   When SXLEN=64, three paged virtual-memory schemes are defined:
> +         *   Sv39, Sv48, and Sv57.
> +         */
> +#ifdef CONFIG_RISCV_32
> +        { HGATP_MODE_SV32X4, 2, "Sv32x4" }
> +#else
> +        { HGATP_MODE_SV39X4, 3, "Sv39x4" },
> +        { HGATP_MODE_SV48X4, 4, "Sv48x4" },
> +        { HGATP_MODE_SV57X4, 5, "Sv57x4" },
> +#endif
> +    };
> +
> +    gstage_mode = HGATP_MODE_OFF;
> +
> +    for ( mode_idx = 0; mode_idx < ARRAY_SIZE(modes); mode_idx++ )
> +    {
> +        unsigned long mode = modes[mode_idx].mode;
> +
> +        csr_write(CSR_HGATP, MASK_INSR(mode, HGATP_MODE_MASK));
> +
> +        if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode )
> +        {
> +            gstage_mode = mode;
> +            break;
> +        }
> +    }
> +
> +    if ( gstage_mode == HGATP_MODE_OFF )
> +        panic("Xen expects that G-stage won't be Bare mode\n");
> +
> +    printk("%s: G-stage mode is %s\n", __func__, modes[mode_idx].name);

I don't think the function name matters here at all.

> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>  
>      console_init_postirq();
>  
> +    gstage_mode_detect();

I find it odd for something as fine grained as this to be called from top-
level start_xen(). Imo this wants to be a sub-function of whatever does
global paging and/or p2m preparations (or even more generally guest ones).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 18 16:21:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 16:21:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126348.1467952 (Exim 4.92)
	(envelope-from )
	id 1uzHNy-0002Fm-W5; Thu, 18 Sep 2025 16:21:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126348.1467952; Thu, 18 Sep 2025 16:21: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 1uzHNy-0002Ff-TF; Thu, 18 Sep 2025 16:21:30 +0000
Received: by outflank-mailman (input) for mailman id 1126348;
 Thu, 18 Sep 2025 16:21:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzHNy-0002FZ-GH
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 16:21:30 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c112ec3-94ab-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 18:21:10 +0200 (CEST)
Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com
 [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-673-zBUp8XwaMNS781BSQpwriw-1; Thu, 18 Sep 2025 12:21:07 -0400
Received: by mail-qv1-f70.google.com with SMTP id
 6a1803df08f44-78f6250f0cdso18023466d6.2
 for ; Thu, 18 Sep 2025 09:21:07 -0700 (PDT)
Received: from x1.local ([174.89.135.121]) by smtp.gmail.com with ESMTPSA id
 6a1803df08f44-793472c35c4sm15248966d6.24.2025.09.18.09.21.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 18 Sep 2025 09: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: 7c112ec3-94ab-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758212468;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=2pPot1YgRDZE6hCh7mQ2pocPU2SLwI5BRF837EyaCck=;
	b=ERsDXc+qh4uLQ5tLZzl1D2ZEIYX6w/zv2ZmWleD5eqx6AjE3kQLF6fIY9/GTl++Pljif0+
	lsNolM4iPC2mneLedyre9jjIivrF5SThRAfsOjvzsgtytfNS9rQF6tuYoCvUxTLdTLyMKf
	nmaFzIx9veQCqADD+L7BNSjsUFNFi0E=
X-MC-Unique: zBUp8XwaMNS781BSQpwriw-1
X-Mimecast-MFC-AGG-ID: zBUp8XwaMNS781BSQpwriw_1758212467
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758212467; x=1758817267;
        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=2pPot1YgRDZE6hCh7mQ2pocPU2SLwI5BRF837EyaCck=;
        b=n9CwN6cat+D5YUbT9NgoxztDVWbCVGyZV7HDVRsnXdOeR6WejHgfJjz0DpakpbgWU+
         5v6tnu2RUOXBP5oB+zCZEJs1u+IpuBWBRZ1NLC/sweO0JdBHr50tJ2EnIZ+Jum8eiKKA
         Ty/JT6v37egKYhZ6myPMEnf7N0RvlhkVmqNw3sSTOoclEbpY8CmOoGG9ikFkDreP+sc1
         I1jQ1m5f10y4riYB58TyLTeuCR0JaiExRYTwSPwkoCImrmbc9Hczg8bDlaLvme82Dq+S
         6REzqZJvfWAZMd8keg0o+kVAHVLalmUNv96EIjhYjDWeZzzg2sbRxKXBHWUR1GDrb4Hi
         ISmQ==
X-Forwarded-Encrypted: i=1; AJvYcCUole/Df6SChedF6tojFjcEEjIc4JeyTB/2qk4qEAMOmyMgDy69wzXc9qzmQ/w6beYrSTeoc+bIXuY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwbJGxTfvySa9oTMdnydM4DtYJhlg4vbePr+98E3hczdadhfTiR
	2r9QahQoKoPiEzLxRs+BDtcQcW9tWgE0Hl/3kEIOFtVKiL1KO20wRd4FGJtYYsJileaADWyC3p8
	Nf4iH/LaUK8squo/eejBBW8kj4+PAujrQGHIVZaeSS3QOF5hqnkUcvg7qCIRTjusmXwll
X-Gm-Gg: ASbGnctLQB1AVprJ7z8ls4QGGMvRUb3g9RN+eimu+SnzZ6IaJS/ddVi8ZU1pvdqwZip
	M9z8Y/nvj/L1iNU5lVhHr7uy6W4oMmRnpxDqhKz/Wx3jnwKMRMuJcwAwidoBWumoHmslstX3OSJ
	0qUhk3bl5Ipg4CeUhH+2oBb+wcQrRhfKJAX5Gj7ePx8YiBKTb3WbcXImdDqk1q36iL4GHySIYMq
	AzwKx2hoeHeiUJeaoup43l5XVV2QadCaaV48ZP0pdvlW91IXrzpNZELDhEtmp0E3FtUYQ3Zykvc
	s/cQrlLdPP5WRpwRjCopmSTUh9wrq+Zo
X-Received: by 2002:a05:6214:5010:b0:722:970:3af1 with SMTP id 6a1803df08f44-79912981a94mr326636d6.22.1758212466530;
        Thu, 18 Sep 2025 09:21:06 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IE5SggIi+tiry2DFo3y6iLI5iQBDlENMAhmnoVxB3dUWtLTqu/Fo+l7vs/qxtYyCGU32KLXQg==
X-Received: by 2002:a05:6214:5010:b0:722:970:3af1 with SMTP id 6a1803df08f44-79912981a94mr325736d6.22.1758212465766;
        Thu, 18 Sep 2025 09:21:05 -0700 (PDT)
Date: Thu, 18 Sep 2025 12:20:49 -0400
From: Peter Xu 
To: BALATON Zoltan 
Cc: Akihiko Odaki , qemu-devel@nongnu.org,
	Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= ,
	Eduardo Habkost ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
 
MIME-Version: 1.0
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: mSY1T-UE47bh85U87x2aElxIq2n-WKK9Kn_JDQ0wMzY_1758212467
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Thu, Sep 18, 2025 at 05:29:34PM +0200, BALATON Zoltan wrote:
> On Thu, 18 Sep 2025, Peter Xu wrote:
> > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > Based-on: 
> > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> > 
> > Could I ask why this is a dependency?
> 
> It removes an address_space usage from raven so this series does not have to
> change that and I don't have to rebase that series. Otherwise these are not
> related. I'll check the problem reported about my series and send an updated
> one.

This series should be a split of a previous mixed up series that may
contain address space changes while this one doesn't.  It also doesn't
touch raven.c and ppc/.

Can I then understand it as the dependency is simply not needed?

Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 17:13:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 17:13:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126377.1467962 (Exim 4.92)
	(envelope-from )
	id 1uzICM-0008Mf-KJ; Thu, 18 Sep 2025 17:13:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126377.1467962; Thu, 18 Sep 2025 17: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 1uzICM-0008MY-Gx; Thu, 18 Sep 2025 17:13:34 +0000
Received: by outflank-mailman (input) for mailman id 1126377;
 Thu, 18 Sep 2025 17:13: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 1uzICL-0008MS-CQ
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 17:13:33 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ccff7210-94b2-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 19:13:31 +0200 (CEST)
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com (2603:10a6:102:322::9)
 by VI0PR03MB10420.eurprd03.prod.outlook.com (2603:10a6:800:20a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Thu, 18 Sep
 2025 17:13:29 +0000
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd]) by PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd%5]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 17:13: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: ccff7210-94b2-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vngOfbvKJzjzjowqTqgL/HQHI/pgEZUsOqCXbhPCfm8ASYBfJSQGUI+X5cMZdDwQ27+nwNM1p5jyj+vpmRxDUrcpm2p6DAHY/aEd9i0PgVIbe9xPBOGC/MBppEml20TYRNfaw89z5/HFiA9h3cBpd0Iep0FNn+6t8twwfzisxpdFbDZSzHt9t059oqdRX4ZQR75pHqx/+QIWz2K7sLB1Q29dPBv5HtI0n84kAyBq/Skgdiu14W1t9pU0dGkYgKYO4H+E6r9aLgXfiRfce0TYvBUbsOuLRW5X5+b41hyOMQXgi13P9irMOVRchnvQ1/XOEAxak0IhKZFqo2WjT/Mbmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZL8IXhLsjCs0n4Fvevruujiq59sJrvq4hPUYosNbT0Q=;
 b=MqlU9UTvCUMwOc6NRnfQxhms2QWtZyi6ew9WRNg9BlEBsrFO0MpW01hIOchQEsE5bUqgPNIqF2hgadbhFTDNqF74fRCjUdD8ZCmuYkN3YczZYmf2rYvQMaOpfyohJVcm/2yCJd+cN9mrbUs64oxLZViEo6jYHMu6qzVrecv3ukCkIPsqVjRQPooo10C8r2JdjatE67tBhcKgSqQoa7HPNGALPZq/QHFVlNT8b3XBomLZ8noJr/o8O3BXxb/l2Y1C0sjn0HkTZpJwzlWyuy7+I6RUAU+ow/U9BqzP5kploF6hLEIPowgRHHh/hZvco4qDSry3ncInpBH+GPJheDRzgQ==
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=ZL8IXhLsjCs0n4Fvevruujiq59sJrvq4hPUYosNbT0Q=;
 b=PAhXSPGebRWMjaSMoNsXmLwjJo4r+JoGpsDiiyridpMlCml5+njS/7bRzfn4Zd4mFTQ15GLJzpQ/45pDRiuJNCSX8dJFWdTgv1a/J6TpU7nWQ9KZT1519X1Me2E25yAnEpNNqitsgadKrC8QPmc1+bmoKorNv/OlQRQ5YqhaoC5Oe7vQcRzukmD/85O1l12A25Q7QKQDWFu8B20zhq9tHiqnpPq78gmQGajPvXWZEV6pM0Ky+/Jm/aRYkZoqF8Sc2vW+O/AF5IZ/vPxOwifMi/IYWXDjlJmVmXSsPaWRM5tWtgxRqZ+OAurMbnOMzNIjBuIP2D5Dqk76DmzymrAJPQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <323babfe-2fe4-45ef-b3f7-fe15739c87da@epam.com>
Date: Thu, 18 Sep 2025 20:13:27 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: Jan Beulich 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
 
 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0153.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ba::14) To PAVPR03MB8921.eurprd03.prod.outlook.com
 (2603:10a6:102:322::9)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAVPR03MB8921:EE_|VI0PR03MB10420:EE_
X-MS-Office365-Filtering-Correlation-Id: f1b79d69-aa08-4414-6967-08ddf6d6afb5
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?ZGd0UXB5aTFqeGFLcCt3UnUxU3o1MURuSVMwZk9PTlhXVDRwMjVYNkhvNHNK?=
 =?utf-8?B?ak84Vys1L2dRSGZSTmxsTGMxMFdIdlZITEdDYTRyaWdwZ1Z3SDFxM2JONUVa?=
 =?utf-8?B?d3BDWHdjZTMvZWtWMmdLbXVCU0k1ZHdzM1Vmb3JUSjB4d2J0NHZ3UlhBcEpQ?=
 =?utf-8?B?MEppYS9aVXcyNTVXTVVyTjdkMGUyOFdVTTF4bng5MlNDcG5WdWduaU1tNzVM?=
 =?utf-8?B?UDVyRGhoMlZvRENyOTNYNEh5RlJBY1QrY1k3NVREM2ZyeGN6dWpPeUZZVGJT?=
 =?utf-8?B?MmxjbE82VnZMNGFqaTdabmVReWN0azhHakxoZldJWVZ0UGp1a3ZKdG5kNXhh?=
 =?utf-8?B?U1NCMDhORXUvV2Q1YmI1QWpiT3ZkZjd3dXJyVGJydjlhMHIwRkNUTkhFV3Bl?=
 =?utf-8?B?N2JsT3BrQVNsUkxnWGlpWTBGcVM4NERxVjdUU1pzNm5ES2lPVEdzZ0F6M1pZ?=
 =?utf-8?B?NGt0ZFpJN3R2OUdWbk4xSEsyUXZPTStBUXpKUkozZ0pySTByQU1PbUN1ZW1q?=
 =?utf-8?B?L1NTYm1PMzJ2RDJGMUtTMDNUQ2tTbWpsNlVjMjNRYTNNK2dmUzRvZEJQOEdk?=
 =?utf-8?B?REtJaHo2R1RyZGgra0swcHE0dEorMnhqSGx5TWhvUmVweSt0dVo3a3UzRjNz?=
 =?utf-8?B?M1NqOG01TitTUEIzMzZiSWtOMmt5cXJZemVKSzlxYi9KZkUwTEdTamhiK29q?=
 =?utf-8?B?Ym1xeC9OZFdkeTRaeVQ0cWxkd0hLd3dsa2dvTVp5b2RBQ2czU2I0ZlhuYVdM?=
 =?utf-8?B?Z0dJU3ZydVdQbThVdDhPOUZ6NVh0anNRV0NLd2NnbTBVT0hTdlllQlFNL1Fr?=
 =?utf-8?B?a1N6dGc1KzgzM1RwS1cyZGhxMjRweDZXSk1VZS9vVVJxQUY5VFRab1FOc2Rv?=
 =?utf-8?B?U0lkcldBbGZDMXp3b0RHVFdXODZCL0JrOFBDYS9FbGhnaHJySnBQY2RZaGZD?=
 =?utf-8?B?dEl1OXdNZkR3V1FWZ0c1WFlTdXY0ZEZLa1dIQjBWckpETExuMS9KV2d2bi9k?=
 =?utf-8?B?R3Q5Sm9BY1J3NHU1NDllQW1za3JMQUZFRVZwRG9qdkN5VTI3MjNNUGlqb3pO?=
 =?utf-8?B?ZHVCUHF3NnZUeHF1aFZhb1lPYUJPNWY5N1VaWGtZd2U4Y0J3ei80TDN0cDdW?=
 =?utf-8?B?M2FLUlY3QVpFTjRXbXFBaFRtNCtIazludmlDWDlBUU1JcldnSVlCMFJjbjZY?=
 =?utf-8?B?K2xEZUdTaTFJTStyV1pVK2luUGVuRTZUeEtCYlRDUUlTKytVTmNUT1NMOUli?=
 =?utf-8?B?aGlPQnE4RlFSZ0p3RStmQ21nMHRZOEU4LzNpMXM5eDJBQlJNaklWK0pjMDIy?=
 =?utf-8?B?UXlPNEdMcEJrUlVUN083eUxWTmJIMWJjbUEwdE5wT1E1eWtPNlY5SWd4bTQ3?=
 =?utf-8?B?NHNtM3AxSlB5S0t5TWpoRFM5YW5kNllwUXB2UVgvUnFIVlZVZFgwdFQ0Tkdt?=
 =?utf-8?B?UmZNRXV0YXNGRXpNRHZEQzgzQlMwclFYcEdzbUlDa1BteG5wTjlHSDh4RDhw?=
 =?utf-8?B?RWgrVXhuVUtsZ1RDSVpCbjZ2ZUFUMkVpemd6UXkzTnRuOWY2dndxNFRFbnBj?=
 =?utf-8?B?ci9iNHNBTEFxWUpxTmN5SFFuMGtLZy9OVkdTbVUwMTc0UDR0NVI0YTQrdHdO?=
 =?utf-8?B?Y1B1UzdUQ0tUbUMzL0FRanplV3RDeXVHUXNHS3ljMkRJS1NhcS93MHg2Z0cv?=
 =?utf-8?B?bUg0dEp0OVhINlA5MGhpR1NWMmZYM2NiNzVLbS9KME1tRWF6d3FEUTh5azJL?=
 =?utf-8?B?VmM4R1Ewb0JQRlBETjJsVm1zcElNMTF2bm80VkFWK2xSYXFaSDlna2ZmVHl3?=
 =?utf-8?B?L1gvU2ZtUzVkbXQ1Z3Y0ZGdZZlJ5V2dnSW5Rd0hzMzk2YWdvTFlCZDBRckpm?=
 =?utf-8?B?ZCtkODhsT0NjNlZQNExmb25GcU9RcXMyOTZuVnZVL05odTJvbGVKODF4amNC?=
 =?utf-8?Q?dLfnJJDQPhg=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8921.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bXJSK2djajh2RkQxZGVUTW1pczdGRnE2Z3U4emdaQlhtWmxQUXpjbmlYdytQ?=
 =?utf-8?B?OXRZVjhQUVlRZDVhOWJuQWFnNWZ3dXVjTlhlZjhPUS84NnZDYjNaaGx1YVVK?=
 =?utf-8?B?cHlOZzdsT2x0N1UremI5b1E0T3cwYmxoVUdkU1dCQWY2b2lBVGV3RHVOY2RD?=
 =?utf-8?B?UUVBeVE3M1QrVVUxb3NZa2ZQeHo2a2xSaUhDSVB4V0dCei9tNjZOUW02UGVv?=
 =?utf-8?B?QmVMTHRUNTNINlZWeHlwYVFXM0lLTFBGRGg2a0hQY1BIRi9PRjlNQWIrUHZG?=
 =?utf-8?B?eElUNFVNYlNmTndkaDJGK0h3UWdlSFdHcWhhcThDaU8rdmhIeFdlR091c3Fk?=
 =?utf-8?B?Y2d5clp5VGU1MlVuYmV1eEhsYzlvUHVkeERlOVAzR3pzbStYbzdqQkRFcXhF?=
 =?utf-8?B?RGxqSlljVUp0WDZaamo2ZDRHOWJBQjh2S1RBY1hvN0wyd2NoUUlNUVpUVEM1?=
 =?utf-8?B?aHhGK0xQaDhicENVUHZub2VUdStFbWI4akFKY1VYNmt4bXhlWGpnVXVNcFBq?=
 =?utf-8?B?MmdmM2NzRW1ReFBiSzk0UlBhdU41Q0JsZ0dBWkgrbTlRUnF1UVoyakFhTGhY?=
 =?utf-8?B?NHBzVjVyY093emVWK3U1bXJTUkQyc2lPdzh6T3ZNNXg5ZEt6N09uQjlwTm5s?=
 =?utf-8?B?NzNXUDRwVmg2ZWR1S2wvM0YvVU5CZkpRcVZ6RHFwY1NDSUJGUG9QSlBHVWFD?=
 =?utf-8?B?c2ljc3ZPOGJ1b24wcVJSa2xBdnBtTFZ4MEtJWTRMV1JKUzAyTExmaVZENE0w?=
 =?utf-8?B?L3FxeFFabk04dHFVL0VHd1dWM2RDQWsyaVVRYkhFUnExdmI0b0VvenRwckly?=
 =?utf-8?B?NnhVcXlOd3ZRUmFrQkI1clNMYTZyN2Y3SStsRzQxK1NieWRWTHBWamN4SDJU?=
 =?utf-8?B?NGJkYkVta09pQXNuWGVob0lkMXp5NFpCdnVLNEhpWjgxZXhRSDdzNHFDY2xw?=
 =?utf-8?B?TldWREwxYm5ua3hkMUFKQzhITmwrc1pmd0ZkN0h3MWZ0cWV0ZXc5cWxtMDdz?=
 =?utf-8?B?Ukg1K25DRGF5MUk5bjdxcG1YWEJaeUx0a3dKTExadk1IOGsvWWh2ejdGTlJU?=
 =?utf-8?B?RlF2Tzg3T3lwN2dnTnFvazZRVXBGZ08zS0luUElEd0FuUnVpS2pJSFp5MXRx?=
 =?utf-8?B?WlJvcXkwc2swdUxRczYrNEN0dFlEU2dQZE92SkVMTW9sMVdYY0pSMXRYTlBw?=
 =?utf-8?B?TWlZbTJWWWZVVVRBTm5lYy9ZeFFvMjgyYmo1V0dHTUlJdmI1OEY5eXArNUJC?=
 =?utf-8?B?UmhGUEZYS2FWY2NXa3pFNmVjZkJtcTBXdGs2TEd2dWcyeUFESjA5eXUxQ1Vs?=
 =?utf-8?B?R0h6bksyNFlNTUxRcVIxOXMrSHQ0N1l0bVEzUTdmS3JZc0FLTXpEek0yM2hp?=
 =?utf-8?B?UU1SQndmWUFJb1U2MEgrSURWeEhxb0t3NTVRL2E4YVRBTy8zT0lnQ2VSakkv?=
 =?utf-8?B?czNQYzJEejZ5U1ZaRlZRYnVwNWNOaEJCQXorRitTYTExZWlGNkQ0dDZGWWlr?=
 =?utf-8?B?QnREVWQ4bGhxR3lyb3YvTURYZndFeHJrLzNtTHcyN1JIOVM4aHhmMnJqVVNP?=
 =?utf-8?B?bmRzUmgvM1lRaEw1dGUrTG04WmhMK2creDVQZFVQdHNJY0o5OXgrclJCdFdB?=
 =?utf-8?B?QXBkY29qY2NzeFUxQTJ3cEJ0WWM5Z2hWWkhnSlhHNXlkN2h2R29xQ1VUTmp4?=
 =?utf-8?B?aEJ0M2FQM2t3K3lQUTA1cEFOWWdyMUt2aGU3dWt5Y1FubmJaRkE1MTZMVWZZ?=
 =?utf-8?B?eDdXZk1GUkdzd3VGQnhCTjVpcklFQVVrL3FlWUdFRHVtWWgxMXJGcmZGYnV0?=
 =?utf-8?B?V2FzVTg0aFIxZlN6blZBWkoxMkJ0Yk4xVnVHQjY2RjRQd0J1d3BVSFhLVmtw?=
 =?utf-8?B?VHhlZnhEQ1loUEY2L0k4eXFFRmEzMWpSSzFJVUx6Q0ZWVHhlZUFTSVNjSUFx?=
 =?utf-8?B?SXlVeHRpT2J0VFdOckN5YzYzd01wU1Q3R0ppRU1kODVsWUpNQ2NNNlBkWEZr?=
 =?utf-8?B?cVM4UUtzODZpb25vNjhKQ1VseG1JalFwbTZ4VGFFcXVVZS96RGJSbWdLWktt?=
 =?utf-8?B?UXRwaU02TEpsaEtZWlJuK3JTbHNSQVFNQUxaUzlRUG94c21McmdqQUcrNlht?=
 =?utf-8?B?RWNqN2lNMkpGcWs1aiswUDZuQmhmRzJpZmJNZHhvQmlJN0RIeEFtckdTNDVh?=
 =?utf-8?B?TlE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f1b79d69-aa08-4414-6967-08ddf6d6afb5
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8921.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2025 17:13:28.9383
 (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: JABZevCQvfJ7a6ZsliVRdj2aPHJPy7mqbhVlh4DfujQMTQmMDN5efvVntIV+VNzJpWQuWXJNT6FvOfKdvJOOZOLkKAGHnUdcUId7JXQYXe0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10420



On 18.09.25 18:19, Jan Beulich wrote:
> On 18.09.2025 17:15, Grygorii Strashko wrote:
>> On 16.09.25 16:41, Grygorii Strashko wrote:
>>> --- a/xen/arch/x86/hvm/Kconfig
>>> +++ b/xen/arch/x86/hvm/Kconfig
>>> @@ -62,6 +62,16 @@ config ALTP2M
>>>    
>>>    	  If unsure, stay with defaults.
>>>    
>>> +config HVM_VIRIDIAN
>>> +	bool "Hyper-V enlightenments for guests" if EXPERT
>>> +	default y
>>> +	help
>>> +	  Support optimizations for Hyper-V guests such as faster hypercalls,
>>> +	  efficient timer and interrupt handling, and enhanced paravirtualized
>>> +	  I/O. This is to improve performance and compatibility of Windows VMs.
>>> +
>>> +	  If unsure, say Y.
>>> +
>>
>> Actually there is a question for x86 Experts -
>> Does it make sense to have HVM_VIRIDIAN enabled without enabled AMD_SVM/INTEL_VMX Virtualization extensions?
> 
> It makes as much or as little sense as HVM=y with both of the ones you mention
> turned off. Iirc Andrew in particular wanted to permit such configurations, to
> allow to prove the (abstract) correctness of building them, even if the
> resulting hypervisor may be of little use.

I've been thinking about adding "depends on AMD_SVM || INTEL_VMX"
to cleanly note dependency.

It's very hard to understand dependencies within x86 code :(

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 17:18:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 17:18:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126392.1467973 (Exim 4.92)
	(envelope-from )
	id 1uzIGd-0000ff-8L; Thu, 18 Sep 2025 17:17:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126392.1467973; Thu, 18 Sep 2025 17:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzIGd-0000fY-5h; Thu, 18 Sep 2025 17:17:59 +0000
Received: by outflank-mailman (input) for mailman id 1126392;
 Thu, 18 Sep 2025 17:17: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 1uzIGb-0000fS-N5
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 17:17:57 +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 6b13ba52-94b3-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 19:17:56 +0200 (CEST)
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com (2603:10a6:102:322::9)
 by VI0PR03MB10420.eurprd03.prod.outlook.com (2603:10a6:800:20a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Thu, 18 Sep
 2025 17:17:46 +0000
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd]) by PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd%5]) with mapi id 15.20.9137.012; Thu, 18 Sep 2025
 17:17: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: 6b13ba52-94b3-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IVmmxeM1Mze2SbriNnJ9KiR4uhT1RjHLtRMxae6Y9vthiiW9TPldXQOTLNYR2I5h+yS/2WtSDjORyiy7/jcdfDy7QzpxE7v5N3WBu+pKjqipQwNDsJsmI5rWzoAFJTY1c0pOBVZ8eEbmFIImtQwGZRZH1KYIBlR4ZbEQNxT1WcJWUXkrawSBvDOWJzxXLPKgADwKDPEQvfPH5Q2WiNak63ihEoKFkcBHuvlQNqW0R0ha5ipw8AHJpFtZJHkO6m+mrSLhgmx3f+1Lbk0DOq6Mw75NS5XPUOw0VWIbbqT1cIar2fWEsF6ZdFlIHuwJkswt1Z8BYREHHlTlHg7aac7nkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9s29UzLn3S0yzMtXZih6lU9rifFrGf4nh6Jcza3sPhM=;
 b=XNg14fD8M/N+BQ1SaZ+BOX6/OW4sp5drf2K014A9XsYp59zT5wkcLk7b6h8P7v+VCTFAFENHtt1ad6cwMeo41TxLqyxPiwSSmDnq86kgij4Mk9ZxAo2wWusvE2OuB0g8m8fqMpSfATI1Xc2vyuLb/YWOH6XSZbY0P/zFaYPkrEBXm6oodIXvD7vCtOJ/ESj5as3Siup7NVZoXIJRj7fy4xhJx87jZCZxCrkKLBbniJ+W/FItLYWcQ0kUC01airjXJe25b41FH3iC+7A8WOZ/zZ1fYpXqH46G0DdFzRBcmMlDfTgzRpr6OOUi2UjorHHIzPkvva/JuMlwukvaawb6iA==
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=9s29UzLn3S0yzMtXZih6lU9rifFrGf4nh6Jcza3sPhM=;
 b=JMMde7Lz3Mxv8UtnAjpfOyIMEIy2hjU44XbplvN6T3ActCJ+O2ljsppXMunVGaDKg+IpUlpLQdHvZHEewkyVF2M3x9V6HQrHGxugFKjCleSr7P0hT+nm8EvqBby6cqqbEFe5bngUPMWJDtZvYlzM6VZNf/CcKTi3N4HqWTyTBRNTi2Ky/B+6TlviQKD9z+2lzuEYpWlFT13166mRxWgQYjWkaviKt5GAZYfEHllQX5fdLJZ51H2dr4YvcqVz7Sl1B8F9DXaYhowTNiAC6qwlv8nSaRQspvR1ZTjc0busrdMnQLac5/M6ph3Qe8gLZFL27GoW2dqo9AlTQa52JY0ZdA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <2d6e5cc6-15c1-40ce-8742-1b77b32203a9@epam.com>
Date: Thu, 18 Sep 2025 20:17:44 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: Jan Beulich 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
 <0e1a6339-a4fb-4697-acfa-392168b391d4@suse.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <0e1a6339-a4fb-4697-acfa-392168b391d4@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0182.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a4::17) To PAVPR03MB8921.eurprd03.prod.outlook.com
 (2603:10a6:102:322::9)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAVPR03MB8921:EE_|VI0PR03MB10420:EE_
X-MS-Office365-Filtering-Correlation-Id: 31389031-4eec-40c7-ca1e-08ddf6d74973
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?b1FWbkNwSnpSL2x0UU9WYXQrL3F5dkZ1OVBPL2krMWZjVmQ0aTR1dGM1Ym0r?=
 =?utf-8?B?QVBTbjFEbEhqbkR3UXc5Zm9BV3pxTnQyQUlXWmM3Mm5JZU5EanZhaGhVQWdU?=
 =?utf-8?B?UHM5N0k4R0VWeWoxYjU4dXpQbkhwb2dnSnFVZW5SR3Z4Z1NicE9iR01GQXB4?=
 =?utf-8?B?QW51TVE1T0ZqTS9vb0ZWcUZIOVBuTzdJYUhZNnRZOFJEaHBoNmdWSUZzYnNv?=
 =?utf-8?B?clRKcmZGc0hBTm9yckpzYmFhMjNmN1NqL0VGZ0hoamJ6blNEVlduelJ2WlFY?=
 =?utf-8?B?UTUvM1hSVHFpTHNwSTVNTGVXNS9zS0xuWUUyZkJXNXplQzRLblpBSFhuSjZI?=
 =?utf-8?B?UnJrN2xQMTNCcUtBZXpuRm0vM1pVZ1BnOGo0UmxQeDlMWTJOc1JWWHlkUVd1?=
 =?utf-8?B?SnAyVCs3MU1xeHRva3ltdDdBdTVRODNialdMeWpXZGRuT0Q4YjhtUCsrelcw?=
 =?utf-8?B?UGtueGw0TjM2VmRlb2JrcU5sZlB3ZXdWMUNOVmNEUVlDRjFiQ1FPYkJpSStD?=
 =?utf-8?B?THM3YTFHWmVadG54bTFvbml1SGdVR1NXaG1XRnJndnVnOVUvQjhaMUE0TVcz?=
 =?utf-8?B?am03bHVRYWxmTXk2YW5FY1NJcHZEUkdKZzhXV2xQR2pmSFdxL1dSeVd6cjNX?=
 =?utf-8?B?UFppaEJJcWdOY0pEY21ydk5sSTcyS3FydGp6Um5Ta1RVUi9ySzg2RGRKU29W?=
 =?utf-8?B?Q0pBcDZCWlpMdGFpTEZzNHozNzUwUEhqVjVqaWpwREIrdkh1SjJpcktjaXE5?=
 =?utf-8?B?bGhTMnkrZ2tkZFdyWkdyUjl6YllpUW1Id0ttcktyUTdRUDN5amM4Y0VlczdK?=
 =?utf-8?B?Mmw4NXlJUUt5U2ZwS2pGK0xScCtrUjZSRG5PUkYwNU9iQXk0NVRkVUhaUmFs?=
 =?utf-8?B?Sk5FV1pxTnkvbWcrY3FDOUR6cjhxK2ZZSzZIeGJDRWZyNXJTVGxXUVhvSis0?=
 =?utf-8?B?SjU5NG1BWWV2SGQ2dUd6Zml2UFIzM2RTUldJUE9EWW01Y2RCdUdEUjhDZDdz?=
 =?utf-8?B?eC9lZXNyQ3NscHBaYWszaUZWSk0ySmdhcnRNNXRiVWNTMzVHcHhaR2NsTkJK?=
 =?utf-8?B?SnVoWmIxQnZyZVpMa1dNNGM4alNtdDUrdVZ3Y2l3SzViVHV3NUVMTXF2TmRq?=
 =?utf-8?B?UkV3c3NnZ0t4d080eTRWcG1FOWtWRkNZblA0RGZIVVZmYlc0ZnFkQ01obUhB?=
 =?utf-8?B?TE9JcFRSTnFGNDFFUUVUR3NGVURxZTZ3clpxZFJhYTJXYlpFYmJCUk1UcFZ0?=
 =?utf-8?B?RjYrS1Z5N2xZTEZxdkRMSWpnc0pJdEVPWDRXUi9jZTl0dnRITW5iak14d2E1?=
 =?utf-8?B?MFc2WXlnVzVUaGZObG9KN1BBVElCSnBqbk9NY0xVemZGZ1d0Uis1SjBTSXFR?=
 =?utf-8?B?QnpTVERjNUJnenpoR2FlQzVJQU9XQ3c2QXBXVi9zZUZLbFN5N1RzK3pYVUFJ?=
 =?utf-8?B?c2hlYWh1MEx3M0RmaURINXZ2UFZ0M0Rndk12QlpERGo1c2lseU0xT2N1bFhs?=
 =?utf-8?B?SGpYYUVkN0V0dWIybXEwckorZkVNVEw2eGl6OWxFQUVCZXlHanJLbVgxbmdj?=
 =?utf-8?B?YUN6Q0U3dzV6KzFPdTl1UU9pRVU1Wnc3dk93YXJMeU1FOU5vV2RHSDF1b2N3?=
 =?utf-8?B?OGVrNk9lUEh3Vkkza25KVHlNU2lJa2NxZzl1TCs3S0hZWWhZMTFSRWRuY1BT?=
 =?utf-8?B?aVkxanMxK1BIUW5peVBta2k4d1RsY01DVDBjckNrS0NmRDNSUElQKzYveTJv?=
 =?utf-8?B?NWo4dlF0OEpvejBFamErNXRJbjdxakZTb2ZkcWI0WEdVdlpvTm5kRjJJbWd4?=
 =?utf-8?B?QVFrcUN1aEpFelp1Nnk3MkEzM25hM3pJbW96ZjMxY1RQS3FRVU5yTlRsUmYy?=
 =?utf-8?B?QlgrK0d5Y0tXTGpnUy95T0hialFyS3NYcExwd283cU9jbnVUZ3pIcUJ4VGxs?=
 =?utf-8?Q?N242neRn3xc=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8921.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZDlrL0RoUHhmNkx1ZW9zR0hOUjVTSEJvL3krUE1kSmtOeS9yOEVnZTVieU0v?=
 =?utf-8?B?Z2NtdjlHSFBOdm1EZ2Q4Yzd0UXpyZ0p1eHRjay91NFh5bEFzK2xuTnZST013?=
 =?utf-8?B?SEhwN3F0N2UrVUxoamdmU29SWmpFVVplT0NJVGk4cmp6R2hKb0wwTFZPTGVi?=
 =?utf-8?B?aDBCeGc0K3l5M3dhNXlRT0pnMWhJcEtDaEJ1SDg0T2FBUXZFWmVLMUVZNEtH?=
 =?utf-8?B?My84Ty9oNk9KVHJ6bHROUnQyMS8wR0NQUDNmZGptWDhZNmpnWG0zbjcxejlD?=
 =?utf-8?B?RWx2bC9ITlRTcGtHUlhBRk83TzVrUjE2VmN6WFhYM1FLMERCMStVRTk5cnpT?=
 =?utf-8?B?Nm9qNWdraWF2SkV2YnpITjNnd2dpMmttdXRTQnVvTjludGNVSEQ3YVRSVFg1?=
 =?utf-8?B?NlVORFlEeGRXb252YkZSaEs3ekoyOFZMNWFoR1hIc0xHUkFLMlBlV2h1VnE0?=
 =?utf-8?B?YksrdTBOdzVVbmdlZWhxbm1IN2lyYStITUNOSXc5YjFlYko2c2R4S2VhYWFv?=
 =?utf-8?B?NzVYOE5YMXhJbldsSUJlU3E2dHJWSDVoZ1pEeGZmc2Q2dzh6YTdOU01nWlJy?=
 =?utf-8?B?OXNtZmJBU2ZycEw2bUhhTWJDSERJZUF0QUQ4N3lEbVJLeVhqcDZLVHIzQkMw?=
 =?utf-8?B?UGV2NGtMVDc4S1R1QWZsUTNneEREQzZlY2oveXllTXdaV0w2NG8zbXYxc0ZR?=
 =?utf-8?B?QW0vdG5laHVNZEJHOFcwaTZZcVdoRGk4REF0MC9nMHlBR244aTlDUkVMWmdL?=
 =?utf-8?B?SXB0QjVXTnZyK05yTmRaVDJuYVA2djBmRHBBV2FmK3hVWndCV2tucjl2dDN5?=
 =?utf-8?B?RlJJaW54YjFsUXJIQ3lVZmt1UHpLUDduYmM1SHVEckc4QVc2ZWdmSWwwYjJL?=
 =?utf-8?B?ang5R3ZabVluOTZ5MmxCa3ZiQjJjQWtuVjVOZWhYL3BXMWJuWnlqNFp2TDl6?=
 =?utf-8?B?MHBqdWVOOS9WakJxUEVuWGZObDIraStaWElNTHpJZ3ExdGVEWlV1cHY5TmlN?=
 =?utf-8?B?UUViNEhqRHZtMHBYajJSS1FKdFNXU2hoMEova3B1K3ZuZWV3SVZ6MFlRWVM5?=
 =?utf-8?B?Qzdmck9zdGpZRlZacFdKQ01ieTIvWGVZYXB4Zkx0enhqcDA0TFRtUE02RzQ1?=
 =?utf-8?B?ZWFYUjkrNlpVMG9lTm1NMWpNYVJUbjBub2xKaVJzVG5KcUovZ2VoUm5XUzFi?=
 =?utf-8?B?MlBUZFhSOGxpcUUwM3dVTlJpbmkvNVFiRjBMc3E0VytDUHJ0ODlDem1RWHFZ?=
 =?utf-8?B?UEpuZ2hKTDQyamFqK1NzZm1VVzJnM1ZycElEL2VCeXFoN3p1b2hPT3VhYjNv?=
 =?utf-8?B?cERwbDBkN1lCKzVPYVltRkRJSVQ0SStSMEhBSHFJMUd0Vkl6OTBJOGYzZDZv?=
 =?utf-8?B?RU9oRnhpYmhORFVXM1R3NEcreDNCZUpJejI2TExnVjhlUEdObVZ2TGVJOVdN?=
 =?utf-8?B?dkI0eXZVRmo4TWRDVEJWMmNkN1E4UXkvNEx6NWpjd2lPWlpTRlZGanpoaWdK?=
 =?utf-8?B?QmMzdE9oaEhISVJHV1Jhb3IrMFptNWlGY2NYWEphMlEyQWZaV1AvNEV2MTVC?=
 =?utf-8?B?cHVvZVUvRnhsQ3puNldJMlNTRmtReWtvMnN1cmZCSjQxS0F6a0U2bklLM3ZP?=
 =?utf-8?B?bFdBdWZiR0Y4b3MrSVAvaEZQSk1WbXlkTDFaUVpBZkRnR3E1bkM1NEhITUVP?=
 =?utf-8?B?Y2QvREJ4MzZoWkRVTlFYRllCWHZmYjdnY05xeWR5dWgvRWI2eGp1YkgzSEYw?=
 =?utf-8?B?anhtMmM5V0dsNVlqN2lJQll0cTdpVjM0U3hLN0hHUUhDOVlKdzJwN2RkcjY3?=
 =?utf-8?B?QkRVL2s1WnhkWnNwM0VHdjN3NEdZQ3ZhbTBXY2RVVnlSR2FkRnhiakQzc3li?=
 =?utf-8?B?aFZLeEp3c1dkRkxqZ1F0NHJ0RWU3YXRSY3Y2SmwvT2c5QkwxNlRJNE5sZ2pX?=
 =?utf-8?B?TWdoSWkyWjFLTjhGeGpWWUEvaENvRllmR2dmUFBjUUVDckI2UjJuMXErQ0tX?=
 =?utf-8?B?UlF5eUJpV1dTaGx0Qkg1N3cwc3ZTaGgwWlJ2L09nTmdLYjIvMi85RERFVVB1?=
 =?utf-8?B?SlFHUzE3cnNlclJrRU5LVUl2RFlRM0dIK01xaGdmYzg5M0huNHFqaDJSZjJ2?=
 =?utf-8?B?ZlIrUFluOERndXNYcWtXNVBkdVRueWgyS3cwSC9pTm5sb2xCbDB0YXBhOVZL?=
 =?utf-8?B?YVE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 31389031-4eec-40c7-ca1e-08ddf6d74973
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8921.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2025 17:17:46.8657
 (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: HgzBBqn4U67GF1bEAuMhpGs6G4hPkyvkFL0IjTvNBcT4++Q+Ce1orI4WZnbs6QLZYHV7E9bGtS2dQw6M5qjihoV/JCl9sID7ZDP8WBk7P+A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10420



On 18.09.25 18:41, Jan Beulich wrote:
> On 16.09.2025 15:41, Grygorii Strashko wrote:
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -62,6 +62,16 @@ config ALTP2M
>>   
>>   	  If unsure, stay with defaults.
>>   
>> +config HVM_VIRIDIAN
> 
> I may have said so already on v1: I'm not quite convinced of the need
> or usefulness of the HVM_ part here. Viridian necessarily means HVM,
> aiui.

sure.

> 
>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>> @@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
>>   {
>>       const struct domain *d = v->domain;
>>       const struct viridian_domain *vd = d->arch.hvm.viridian;
>> -    struct hvm_viridian_domain_context ctxt = {
>> -        .hypercall_gpa = vd->hypercall_gpa.raw,
>> -        .guest_os_id = vd->guest_os_id.raw,
>> -    };
>> +    struct hvm_viridian_domain_context ctxt = {};
>>   
>>       if ( !is_viridian_domain(d) )
>>           return 0;
> 
> This check doesn't check for vd being non-NULL, so this still feels a little
> fragile, even if it looks correct now.

Hm. May be I missing smth., but
- if is_viridian_domain(d) and viridian_domain_init() succeeded
   then d->arch.hvm.viridian != NULL, like always
   (otherwise domain will not be created)

- if !is_viridian_domain() then code will not go further

so I'm missing to see how !d->arch.hvm.viridian (!vd) can happen here.

To be paranoid can also add:
  if (!vd)
     return -EINVAL;

> 
>> +    ctxt.hypercall_gpa = vd->hypercall_gpa.raw;
>> +    ctxt.guest_os_id = vd->guest_os_id.raw,
>> +
>>       viridian_time_save_domain_ctxt(d, &ctxt);
>>       viridian_synic_save_domain_ctxt(d, &ctxt);
>>   
> 
> Just below here we have viridian_load_domain_ctxt(), which I'm pretty sure
> now also needs to gain some check: Save records coming from user space, we
> can't really rely on there being none of this type for a non-Viridian domain.

As per my understanding:
viridian_load_domain_ctxt() calls hvm_load_entry_zeroextend() which
should not succeed if context was not saved (which shouldn't happen for
!is_viridian_domain(d) case).

To be paranoid can also add in viridian_load_domain_ctxt/viridian_load_vcpu_ctxt:
    if ( !is_viridian_domain(d) )
         return -ENODEV;

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:24:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:24:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126411.1467984 (Exim 4.92)
	(envelope-from )
	id 1uzJIY-0000Xq-S3; Thu, 18 Sep 2025 18:24:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126411.1467984; Thu, 18 Sep 2025 18:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzJIY-0000Xj-Nj; Thu, 18 Sep 2025 18:24:02 +0000
Received: by outflank-mailman (input) for mailman id 1126411;
 Thu, 18 Sep 2025 18:24:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzJIW-0000Xd-Ur
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:24:01 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a32decb5-94bc-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 20:23:57 +0200 (CEST)
Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com
 [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-546-CYFV9PqfN5aC21xg0NEZig-1; Thu, 18 Sep 2025 14:23:52 -0400
Received: by mail-qk1-f197.google.com with SMTP id
 af79cd13be357-81678866c0cso220576685a.2
 for ; Thu, 18 Sep 2025 11:23:52 -0700 (PDT)
Received: from x1.local
 (bras-base-aurron9134w-grc-11-174-89-135-121.dsl.bell.ca. [174.89.135.121])
 by smtp.gmail.com with ESMTPSA id
 af79cd13be357-8363344e970sm204144985a.61.2025.09.18.11.23.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 18 Sep 2025 11:23: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: a32decb5-94bc-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758219835;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=lNsw5JLeKY9uVflrGldSh1MSaksI/KlXGOcdfAP4dVg=;
	b=UJOlndqJOFQlrNaz4YKnqu+Q7YMYNrBPKseq2SGSRGhTV4NPUDPn5TyQytIWaj3q8/Q/dG
	CaU6ug0i+qg2rlqBMD6Qyh1q3uabYp/enttrehC/fKbn0HAINFuJx8yJrcWQ2OHR+6o238
	k1fvMTtjhqHxP+7qNrf/8wnjQYeLSZI=
X-MC-Unique: CYFV9PqfN5aC21xg0NEZig-1
X-Mimecast-MFC-AGG-ID: CYFV9PqfN5aC21xg0NEZig_1758219832
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758219832; x=1758824632;
        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=lNsw5JLeKY9uVflrGldSh1MSaksI/KlXGOcdfAP4dVg=;
        b=WOrOAdwTq+xTrEdwfStd3SqfRz2AeukqWYowCKFiBvz9G+Y1u5BVvYpDVlVJ/5Asl8
         QY9E0TEjldcGfqr1xABxDcOw5OZ7+ZEqEMPox2wFyjFfZYFnbeEa6p+dDKrxoZXZ2rpF
         Ra0QfdHT00Hmh27id30Jv92CJTQy9mgLyjv3b4hapFMMdBWV8YFJycG0AZoUHqb9ntkt
         IchIGXhvTTLhGSRh4blLQ/2IIvG/4rsvKKdOetmSfjygyKR8YmFFyFCOOjmIEM7Tm/5p
         73XfNjqVQifL+ceekswxScbnOA5KdlkxfoO+PW5qbEnFMElHF4qw8EJLBqSnekI1nf0O
         yZQQ==
X-Forwarded-Encrypted: i=1; AJvYcCWY5GZBC6cQv/alytxukxOSCHgFwL7/cPlE8ISba5SJ66gjmx/qENfADmXtQOp/Q5+MDecNDQZPIck=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGDuY9vWZhKQMTwqPudxylz8ek1AC0S9GG4aimgYaCEa2KVqJW
	urQqUbcACvA9L6qMY3fYCfidQmB0XvjxW5/D8+imTcU0zB5ZPmemHtxrx7jMmC8KhlSgLDUtBwC
	ndPzuIuQHvsGqSzEAhPwk+4mxROq7/RjLUVgBhi/ZPtkU2e7f4iMvs/KBcJkvXbF252Kd
X-Gm-Gg: ASbGnctyjrpQ6BbRauwdkhgVQ+WWiVtFHov158ovYWdlSmL+lK8bsRuZ6HctlilW7Gw
	c+uVn8tbHHQetb7w6lmT9/EBRIko6OAdVTkF5D3PRlj/cYAt68q2VwUlyJ6QJtfLxvEXY8Yae2F
	VQNLG0FZ17kejCrQ8pxgjEA261QIEAhwvY3Yn5ECdeos1nDEsZNL3z4hLmi2fIxuvB7xRqtWCAV
	t9lf4NV0p2E1h9gIdOhSSCqso4DOdmGuVYanRC617nodCBYDsCNU50AdBUQ6pOOGYI8wC4rGYio
	SiqV+Um9IGV16YGfftbFb0JWX5B14NRfTGUGWADD9wIye3z6dbhIzuv3soZm+cn/jxW3VVYSzcy
	g3hIPH/CkDmod8IkorHoUuA==
X-Received: by 2002:a05:620a:1a8c:b0:80d:a8d5:9857 with SMTP id af79cd13be357-83bab74d395mr64509485a.43.1758219831748;
        Thu, 18 Sep 2025 11:23:51 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFUpTtF0CBpm8iaj0vzODs7Wm2HXXsF9gB4ig///X5jqMVyDsGMScgSe8thOnLAxmi8d11Yfg==
X-Received: by 2002:a05:620a:1a8c:b0:80d:a8d5:9857 with SMTP id af79cd13be357-83bab74d395mr64504285a.43.1758219831243;
        Thu, 18 Sep 2025 11:23:51 -0700 (PDT)
Date: Thu, 18 Sep 2025 14:23:47 -0400
From: Peter Xu 
To: BALATON Zoltan 
Cc: Akihiko Odaki , qemu-devel@nongnu.org,
	Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= ,
	Eduardo Habkost ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
 
 
MIME-Version: 1.0
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: htwpcfRabXNpU05NIZKC441DLI9SpNnh4462It_tVWo_1758219832
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Thu, Sep 18, 2025 at 12:20:49PM -0400, Peter Xu wrote:
> On Thu, Sep 18, 2025 at 05:29:34PM +0200, BALATON Zoltan wrote:
> > On Thu, 18 Sep 2025, Peter Xu wrote:
> > > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > > Based-on: 
> > > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> > > 
> > > Could I ask why this is a dependency?
> > 
> > It removes an address_space usage from raven so this series does not have to
> > change that and I don't have to rebase that series. Otherwise these are not
> > related. I'll check the problem reported about my series and send an updated
> > one.
> 
> This series should be a split of a previous mixed up series that may
> contain address space changes while this one doesn't.  It also doesn't
> touch raven.c and ppc/.
> 
> Can I then understand it as the dependency is simply not needed?

I meant, it seems we don't need to wait for the other series to merge this
one, hence the there is no real dependency.

I didn't mean to drop that series for sure.. if it was confusing before..

Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:45:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:45:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126432.1467993 (Exim 4.92)
	(envelope-from )
	id 1uzJdO-0003Gv-CA; Thu, 18 Sep 2025 18:45:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126432.1467993; Thu, 18 Sep 2025 18:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzJdO-0003Go-8q; Thu, 18 Sep 2025 18:45:34 +0000
Received: by outflank-mailman (input) for mailman id 1126432;
 Thu, 18 Sep 2025 18:45: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 1uzJdM-0003Gi-EM
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:45:32 +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 a6ae65cd-94bf-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 20:45: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 7A3B96021D;
 Thu, 18 Sep 2025 18:45:29 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 340C7C4CEE7;
 Thu, 18 Sep 2025 18:45: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: a6ae65cd-94bf-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221129;
	bh=u6NaIt2RygsBlCtYn4hZiQqQdifJG8iCHYQXwiLX65E=;
	h=From:To:Cc:Subject:Date:From;
	b=Z28vS7zXihUdX9isz4tKX5bJfG+N6wgA49ZsUL9MzWkxVOZIaB9CEoaGCeOdF5Wlc
	 irtxfrEkcx12CNmXSpOaxnrWSE3uyQ9BLUGMgdMwz3ZkzTrB7vIU5S+RDvQ6dKM5ki
	 RxUJdVCwUhpNByj1sxF0SK4ASPa55TnwfCGcGHPBq14Ogh8/QuEEAY6ulYXQRiCrc/
	 gKhn/kbZmmAWPpdmUgqtKeJS0PBEgSw0hZoyR9kwDh1THqWJDw1i1JuxwJQDO1Fvaa
	 tjs8Xsk56/6qq7xSDRAZoHUF6JGB7I+NLrajHOGD2OUILv6g7xC1NJVMJM9wXp6cE/
	 8ldLVQITFO98w==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/9] Remove DMA .map_page and .unmap_page callbacks
Date: Thu, 18 Sep 2025 21:45:00 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi,

This series continues following two series:
1. "dma-mapping: migrate to physical address-based API" 
https://lore.kernel.org/all/cover.1757423202.git.leonro@nvidia.com
2. "Preparation to .map_page and .unmap_page removal"
Preparation to .map_page and .unmap_page removal

In this series, the DMA .map_page/.unmap_page callbacks are converted to newly
introduced .map_phys/.unmap_phys interfaces. This conversion allows us to reduce
or eliminate (for certain ARCHs) use of struct pages in DMA path.

Thanks

Leon Romanovsky (9):
  alpha: Convert mapping routine to rely on physical address
  MIPS/jazzdma: Provide physical address directly
  parisc: Convert DMA map_page to map_phys interface
  powerpc: Convert to physical address DMA mapping
  sparc64: Use physical address DMA mapping
  x86: Use physical address for DMA mapping
  vdpa: Convert to physical address DMA mapping
  xen: swiotlb: Convert mapping routine to rely on physical address
  dma-mapping: remove unused map_page callback

 arch/alpha/kernel/pci_iommu.c            | 47 ++++++++++--------------
 arch/mips/jazz/jazzdma.c                 | 20 ++++++----
 arch/powerpc/include/asm/iommu.h         |  8 ++--
 arch/powerpc/kernel/dma-iommu.c          | 22 +++++------
 arch/powerpc/kernel/iommu.c              | 14 +++----
 arch/powerpc/platforms/ps3/system-bus.c  | 33 ++++++++++-------
 arch/powerpc/platforms/pseries/ibmebus.c | 15 ++++----
 arch/powerpc/platforms/pseries/vio.c     | 21 ++++++-----
 arch/sparc/kernel/iommu.c                | 16 ++++----
 arch/sparc/kernel/pci_sun4v.c            | 16 ++++----
 arch/sparc/mm/io-unit.c                  | 13 +++----
 arch/sparc/mm/iommu.c                    | 46 ++++++++++++-----------
 arch/x86/kernel/amd_gart_64.c            | 19 +++++-----
 drivers/parisc/ccio-dma.c                | 25 +++++++------
 drivers/parisc/sba_iommu.c               | 23 ++++++------
 drivers/vdpa/vdpa_user/iova_domain.c     | 11 +++---
 drivers/vdpa/vdpa_user/iova_domain.h     |  8 ++--
 drivers/vdpa/vdpa_user/vduse_dev.c       | 18 +++++----
 drivers/xen/grant-dma-ops.c              | 20 ++++++----
 include/linux/dma-map-ops.h              |  7 ----
 kernel/dma/mapping.c                     | 12 ------
 kernel/dma/ops_helpers.c                 |  8 +---
 22 files changed, 208 insertions(+), 214 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:45:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:45:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126433.1468003 (Exim 4.92)
	(envelope-from )
	id 1uzJdW-0003Wc-K1; Thu, 18 Sep 2025 18:45:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126433.1468003; Thu, 18 Sep 2025 18:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzJdW-0003WV-Gg; Thu, 18 Sep 2025 18:45:42 +0000
Received: by outflank-mailman (input) for mailman id 1126433;
 Thu, 18 Sep 2025 18:45: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 1uzJdV-0003Vt-Ff
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:45:41 +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 a97f1076-94bf-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 20:45: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 D69A660234;
 Thu, 18 Sep 2025 18:45:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76C21C4CEF0;
 Thu, 18 Sep 2025 18:45: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: a97f1076-94bf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221134;
	bh=mRrCuK2cRKam5wDdOYPzkMc4IzLVg72Ycd5tZAIZOwA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=BrezbUs7YQQoFiEnq4O37fij9yQqGwhFFKxGtk7W85Qc/47lo4WDrX08x8pBhOMBl
	 x3C+EqTXn/J9a/3WVpKBvLTRlkB+do/ZfwaAE2Mb7IopCTXi7LrOLKMJkkNTJfvDUp
	 YqF2kAB3MxM4nlAlg21f/GeFvZw8zg11jBWISdL9T8Q0n5qtbkyadIU6XtD1/orTr1
	 7w2ouYNTNdHOHzAOrJP4usoDUr3cv4AUvmi2rODsSOE2yxEfZKK0CI1huASdVmWoDj
	 bBSTZ3whPx0z/NsNtq26Y7bbhfgNlmo/ggZU7pwAyS1i89RmTF6XqFtx+J2G8mxe/e
	 /R99gASdkRTZg==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/9] alpha: Convert mapping routine to rely on  physical address
Date: Thu, 18 Sep 2025 21:45:01 +0300
Message-ID: <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Alpha doesn't need struct *page and can perform mapping based on
physical addresses. So convert it to implement new .map_phys callback.

As part of this change, remove useless BUG_ON() as DMA mapping layer
ensures that right direction is provided.

Signed-off-by: Leon Romanovsky 
---
 arch/alpha/kernel/pci_iommu.c | 47 +++++++++++++++--------------------
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index dc91de50f906d..b62d9937d1d3a 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -224,28 +224,25 @@ static int pci_dac_dma_supported(struct pci_dev *dev, u64 mask)
    until either pci_unmap_single or pci_dma_sync_single is performed.  */
 
 static dma_addr_t
-pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
+pci_map_single_1(struct pci_dev *pdev, phys_addr_t paddr, size_t size,
 		 int dac_allowed)
 {
 	struct pci_controller *hose = pdev ? pdev->sysdata : pci_isa_hose;
 	dma_addr_t max_dma = pdev ? pdev->dma_mask : ISA_DMA_MASK;
 	struct pci_iommu_arena *arena;
 	long npages, dma_ofs, i;
-	unsigned long paddr;
 	dma_addr_t ret;
 	unsigned int align = 0;
 	struct device *dev = pdev ? &pdev->dev : NULL;
 
-	paddr = __pa(cpu_addr);
-
 #if !DEBUG_NODIRECT
 	/* First check to see if we can use the direct map window.  */
 	if (paddr + size + __direct_map_base - 1 <= max_dma
 	    && paddr + size <= __direct_map_size) {
 		ret = paddr + __direct_map_base;
 
-		DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %ps\n",
-		      cpu_addr, size, ret, __builtin_return_address(0));
+		DBGA2("pci_map_single: [%pa,%zx] -> direct %llx from %ps\n",
+		      &paddr, size, ret, __builtin_return_address(0));
 
 		return ret;
 	}
@@ -255,8 +252,8 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
 	if (dac_allowed) {
 		ret = paddr + alpha_mv.pci_dac_offset;
 
-		DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %ps\n",
-		      cpu_addr, size, ret, __builtin_return_address(0));
+		DBGA2("pci_map_single: [%pa,%zx] -> DAC %llx from %ps\n",
+		      &paddr, size, ret, __builtin_return_address(0));
 
 		return ret;
 	}
@@ -290,10 +287,10 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
 		arena->ptes[i + dma_ofs] = mk_iommu_pte(paddr);
 
 	ret = arena->dma_base + dma_ofs * PAGE_SIZE;
-	ret += (unsigned long)cpu_addr & ~PAGE_MASK;
+	ret += offset_in_page(paddr);
 
-	DBGA2("pci_map_single: [%p,%zx] np %ld -> sg %llx from %ps\n",
-	      cpu_addr, size, npages, ret, __builtin_return_address(0));
+	DBGA2("pci_map_single: [%pa,%zx] np %ld -> sg %llx from %ps\n",
+	      &paddr, size, npages, ret, __builtin_return_address(0));
 
 	return ret;
 }
@@ -322,19 +319,18 @@ static struct pci_dev *alpha_gendev_to_pci(struct device *dev)
 	return NULL;
 }
 
-static dma_addr_t alpha_pci_map_page(struct device *dev, struct page *page,
-				     unsigned long offset, size_t size,
-				     enum dma_data_direction dir,
+static dma_addr_t alpha_pci_map_phys(struct device *dev, phys_addr_t phys,
+				     size_t size, enum dma_data_direction dir,
 				     unsigned long attrs)
 {
 	struct pci_dev *pdev = alpha_gendev_to_pci(dev);
 	int dac_allowed;
 
-	BUG_ON(dir == DMA_NONE);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
-	dac_allowed = pdev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0; 
-	return pci_map_single_1(pdev, (char *)page_address(page) + offset, 
-				size, dac_allowed);
+	dac_allowed = pdev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0;
+	return pci_map_single_1(pdev, phys, size, dac_allowed);
 }
 
 /* Unmap a single streaming mode DMA translation.  The DMA_ADDR and
@@ -343,7 +339,7 @@ static dma_addr_t alpha_pci_map_page(struct device *dev, struct page *page,
    the cpu to the buffer are guaranteed to see whatever the device
    wrote there.  */
 
-static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void alpha_pci_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 				 size_t size, enum dma_data_direction dir,
 				 unsigned long attrs)
 {
@@ -353,8 +349,6 @@ static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr,
 	struct pci_iommu_arena *arena;
 	long dma_ofs, npages;
 
-	BUG_ON(dir == DMA_NONE);
-
 	if (dma_addr >= __direct_map_base
 	    && dma_addr < __direct_map_base + __direct_map_size) {
 		/* Nothing to do.  */
@@ -429,7 +423,7 @@ static void *alpha_pci_alloc_coherent(struct device *dev, size_t size,
 	}
 	memset(cpu_addr, 0, size);
 
-	*dma_addrp = pci_map_single_1(pdev, cpu_addr, size, 0);
+	*dma_addrp = pci_map_single_1(pdev, virt_to_phys(cpu_addr), size, 0);
 	if (*dma_addrp == DMA_MAPPING_ERROR) {
 		free_pages((unsigned long)cpu_addr, order);
 		if (alpha_mv.mv_pci_tbi || (gfp & GFP_DMA))
@@ -643,9 +637,8 @@ static int alpha_pci_map_sg(struct device *dev, struct scatterlist *sg,
 	/* Fast path single entry scatterlists.  */
 	if (nents == 1) {
 		sg->dma_length = sg->length;
-		sg->dma_address
-		  = pci_map_single_1(pdev, SG_ENT_VIRT_ADDRESS(sg),
-				     sg->length, dac_allowed);
+		sg->dma_address = pci_map_single_1(pdev, sg_phys(sg),
+						   sg->length, dac_allowed);
 		if (sg->dma_address == DMA_MAPPING_ERROR)
 			return -EIO;
 		return 1;
@@ -917,8 +910,8 @@ iommu_unbind(struct pci_iommu_arena *arena, long pg_start, long pg_count)
 const struct dma_map_ops alpha_pci_ops = {
 	.alloc			= alpha_pci_alloc_coherent,
 	.free			= alpha_pci_free_coherent,
-	.map_page		= alpha_pci_map_page,
-	.unmap_page		= alpha_pci_unmap_page,
+	.map_phys		= alpha_pci_map_phys,
+	.unmap_phys		= alpha_pci_unmap_phys,
 	.map_sg			= alpha_pci_map_sg,
 	.unmap_sg		= alpha_pci_unmap_sg,
 	.dma_supported		= alpha_pci_supported,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:45:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:45:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126434.1468009 (Exim 4.92)
	(envelope-from )
	id 1uzJdX-0003a2-0J; Thu, 18 Sep 2025 18:45:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126434.1468009; Thu, 18 Sep 2025 18:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzJdW-0003Yy-Oz; Thu, 18 Sep 2025 18:45:42 +0000
Received: by outflank-mailman (input) for mailman id 1126434;
 Thu, 18 Sep 2025 18:45: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 1uzJdW-0003Vt-66
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:45:42 +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 ac2cde88-94bf-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 20:45:40 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 6D84660211;
 Thu, 18 Sep 2025 18:45:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E3E1C4CEE7;
 Thu, 18 Sep 2025 18:45: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: ac2cde88-94bf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221139;
	bh=lYina26sWVeUcMXQiYVzGEsG3s2F3WRjYogRL1Hc1Kg=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=nmeOm+sqpgOPQj79lggvc1K6wpDOki3X4yJuxCb2vpWB7Yrit2zqRh0RiDIvOfhbE
	 evc12i0uWXAtIGkWhu78jwz295HLWPOAaZO6IZ/cviymzjBAJS/z9YITfLbhvXtCFj
	 ky8D8HIF4+CT3b196kV7uzpo4mZHe5HQ3Dm4EG7bvT2H0SCDQYzaGQ0o23uNJgkbi+
	 6aZi+d9itiPvwVg22aSegOmezzgMa5H8zXDrUjIenHJYjuH2xplO3ZAhthDLRLlTV2
	 U0DeJS9SxdDkBapfGs1dH8YVifrYc3iq4bbDeAIVs7BBOR9OCRgcGcxYPk4A43PYIU
	 SJ9lnFSV8Evzw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 3/9] parisc: Convert DMA map_page to map_phys  interface
Date: Thu, 18 Sep 2025 21:45:03 +0300
Message-ID: <56c4c3b14f46c0a785f196315b673b0b1bcfb3b1.1758219787.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Perform mechanical conversion from .map_page to .map_phys callback.

Signed-off-by: Leon Romanovsky 
---
 drivers/parisc/ccio-dma.c  | 25 +++++++++++++------------
 drivers/parisc/sba_iommu.c | 23 ++++++++++++-----------
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index feef537257d05..d45f3634f8270 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -773,17 +773,18 @@ ccio_map_single(struct device *dev, void *addr, size_t size,
 
 
 static dma_addr_t
-ccio_map_page(struct device *dev, struct page *page, unsigned long offset,
-		size_t size, enum dma_data_direction direction,
-		unsigned long attrs)
+ccio_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+	      enum dma_data_direction direction, unsigned long attrs)
 {
-	return ccio_map_single(dev, page_address(page) + offset, size,
-			direction);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return ccio_map_single(dev, phys_to_virt(phys), size, direction);
 }
 
 
 /**
- * ccio_unmap_page - Unmap an address range from the IOMMU.
+ * ccio_unmap_phys - Unmap an address range from the IOMMU.
  * @dev: The PCI device.
  * @iova: The start address of the DMA region.
  * @size: The length of the DMA region.
@@ -791,7 +792,7 @@ ccio_map_page(struct device *dev, struct page *page, unsigned long offset,
  * @attrs: attributes
  */
 static void 
-ccio_unmap_page(struct device *dev, dma_addr_t iova, size_t size,
+ccio_unmap_phys(struct device *dev, dma_addr_t iova, size_t size,
 		enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ioc *ioc;
@@ -873,7 +874,7 @@ static void
 ccio_free(struct device *dev, size_t size, void *cpu_addr,
 		dma_addr_t dma_handle, unsigned long attrs)
 {
-	ccio_unmap_page(dev, dma_handle, size, 0, 0);
+	ccio_unmap_phys(dev, dma_handle, size, 0, 0);
 	free_pages((unsigned long)cpu_addr, get_order(size));
 }
 
@@ -1004,7 +1005,7 @@ ccio_unmap_sg(struct device *dev, struct scatterlist *sglist, int nents,
 #ifdef CCIO_COLLECT_STATS
 		ioc->usg_pages += sg_dma_len(sglist) >> PAGE_SHIFT;
 #endif
-		ccio_unmap_page(dev, sg_dma_address(sglist),
+		ccio_unmap_phys(dev, sg_dma_address(sglist),
 				  sg_dma_len(sglist), direction, 0);
 		++sglist;
 		nents--;
@@ -1017,8 +1018,8 @@ static const struct dma_map_ops ccio_ops = {
 	.dma_supported =	ccio_dma_supported,
 	.alloc =		ccio_alloc,
 	.free =			ccio_free,
-	.map_page =		ccio_map_page,
-	.unmap_page =		ccio_unmap_page,
+	.map_phys =		ccio_map_phys,
+	.unmap_phys =		ccio_unmap_phys,
 	.map_sg =		ccio_map_sg,
 	.unmap_sg =		ccio_unmap_sg,
 	.get_sgtable =		dma_common_get_sgtable,
@@ -1072,7 +1073,7 @@ static int ccio_proc_info(struct seq_file *m, void *p)
 			   ioc->msingle_calls, ioc->msingle_pages,
 			   (int)((ioc->msingle_pages * 1000)/ioc->msingle_calls));
 
-		/* KLUGE - unmap_sg calls unmap_page for each mapped page */
+		/* KLUGE - unmap_sg calls unmap_phys for each mapped page */
 		min = ioc->usingle_calls - ioc->usg_calls;
 		max = ioc->usingle_pages - ioc->usg_pages;
 		seq_printf(m, "pci_unmap_single: %8ld calls  %8ld pages (avg %d/1000)\n",
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index fc3863c09f83d..8040aa4e6ff42 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -778,17 +778,18 @@ sba_map_single(struct device *dev, void *addr, size_t size,
 
 
 static dma_addr_t
-sba_map_page(struct device *dev, struct page *page, unsigned long offset,
-		size_t size, enum dma_data_direction direction,
-		unsigned long attrs)
+sba_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		enum dma_data_direction direction, unsigned long attrs)
 {
-	return sba_map_single(dev, page_address(page) + offset, size,
-			direction);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return sba_map_single(dev, phys_to_virt(phys), size, direction);
 }
 
 
 /**
- * sba_unmap_page - unmap one IOVA and free resources
+ * sba_unmap_phys - unmap one IOVA and free resources
  * @dev: instance of PCI owned by the driver that's asking.
  * @iova:  IOVA of driver buffer previously mapped.
  * @size:  number of bytes mapped in driver buffer.
@@ -798,7 +799,7 @@ sba_map_page(struct device *dev, struct page *page, unsigned long offset,
  * See Documentation/core-api/dma-api-howto.rst
  */
 static void
-sba_unmap_page(struct device *dev, dma_addr_t iova, size_t size,
+sba_unmap_phys(struct device *dev, dma_addr_t iova, size_t size,
 		enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ioc *ioc;
@@ -914,7 +915,7 @@ static void
 sba_free(struct device *hwdev, size_t size, void *vaddr,
 		    dma_addr_t dma_handle, unsigned long attrs)
 {
-	sba_unmap_page(hwdev, dma_handle, size, 0, 0);
+	sba_unmap_phys(hwdev, dma_handle, size, 0, 0);
 	free_pages((unsigned long) vaddr, get_order(size));
 }
 
@@ -1061,7 +1062,7 @@ sba_unmap_sg(struct device *dev, struct scatterlist *sglist, int nents,
 
 	while (nents && sg_dma_len(sglist)) {
 
-		sba_unmap_page(dev, sg_dma_address(sglist), sg_dma_len(sglist),
+		sba_unmap_phys(dev, sg_dma_address(sglist), sg_dma_len(sglist),
 				direction, 0);
 #ifdef SBA_COLLECT_STATS
 		ioc->usg_pages += ((sg_dma_address(sglist) & ~IOVP_MASK) + sg_dma_len(sglist) + IOVP_SIZE - 1) >> PAGE_SHIFT;
@@ -1085,8 +1086,8 @@ static const struct dma_map_ops sba_ops = {
 	.dma_supported =	sba_dma_supported,
 	.alloc =		sba_alloc,
 	.free =			sba_free,
-	.map_page =		sba_map_page,
-	.unmap_page =		sba_unmap_page,
+	.map_phys =		sba_map_phys,
+	.unmap_phys =		sba_unmap_phys,
 	.map_sg =		sba_map_sg,
 	.unmap_sg =		sba_unmap_sg,
 	.get_sgtable =		dma_common_get_sgtable,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:45:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:45:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126435.1468022 (Exim 4.92)
	(envelope-from )
	id 1uzJdb-000434-AF; Thu, 18 Sep 2025 18:45:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126435.1468022; Thu, 18 Sep 2025 18: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 1uzJdb-00042x-74; Thu, 18 Sep 2025 18:45:47 +0000
Received: by outflank-mailman (input) for mailman id 1126435;
 Thu, 18 Sep 2025 18:45: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 1uzJdZ-0003Gi-Gt
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:45:45 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aed91f74-94bf-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 20:45:44 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id BB6316021B;
 Thu, 18 Sep 2025 18:45:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92CC2C4CEF0;
 Thu, 18 Sep 2025 18:45: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: aed91f74-94bf-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221143;
	bh=A5MYBsSBE9JCUM3+eZAexfkVHCWWAKynqqD0ex2RShQ=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=VFTsFBtZuq3RVObanJ1b8fM2UGDGA4Zn3T9RhLMeI1McT3DbXl46onA5ciizSBNyt
	 e1Vw09lscJuL0hnn6ctfrD5eU+i7hLzqF3jIQGA/SfsG96PEvQDpJF6yBiUKZzSiiN
	 RNAJGFUHjhdtEDlComVmJQGBIYwgOkRmRy2rLupZxtPiW5SJcaI9uhtProb48+4fSX
	 JbKVzymUDqJfmrrPQcihptQS9xWeAWhDEYX4vllaFcywrHZ5boMeAplPClyw3NxKlp
	 Bs9mimCO1/mzRXV4Y1CUgSLgIAKGxCQi6jAm1nL7j5KU5pU+q0+gPCmFWy+umttOfe
	 UFfFNv7ET5k2w==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 4/9] powerpc: Convert to physical address DMA  mapping
Date: Thu, 18 Sep 2025 21:45:04 +0300
Message-ID: <6fd5222ca5eb2e6cba0d28e5cdab8ca3e6152ee5.1758219787.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Adapt PowerPC DMA to use physical addresses in order to prepare code
to removal .map_page and .unmap_page.

Signed-off-by: Leon Romanovsky 
---
 arch/powerpc/include/asm/iommu.h         |  8 +++---
 arch/powerpc/kernel/dma-iommu.c          | 22 +++++++---------
 arch/powerpc/kernel/iommu.c              | 14 +++++-----
 arch/powerpc/platforms/ps3/system-bus.c  | 33 ++++++++++++++----------
 arch/powerpc/platforms/pseries/ibmebus.c | 15 ++++++-----
 arch/powerpc/platforms/pseries/vio.c     | 21 ++++++++-------
 6 files changed, 60 insertions(+), 53 deletions(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index b410021ad4c69..eafdd63cd6c4f 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -274,12 +274,12 @@ extern void *iommu_alloc_coherent(struct device *dev, struct iommu_table *tbl,
 				  unsigned long mask, gfp_t flag, int node);
 extern void iommu_free_coherent(struct iommu_table *tbl, size_t size,
 				void *vaddr, dma_addr_t dma_handle);
-extern dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
-				 struct page *page, unsigned long offset,
-				 size_t size, unsigned long mask,
+extern dma_addr_t iommu_map_phys(struct device *dev, struct iommu_table *tbl,
+				 phys_addr_t phys, size_t size,
+				 unsigned long mask,
 				 enum dma_data_direction direction,
 				 unsigned long attrs);
-extern void iommu_unmap_page(struct iommu_table *tbl, dma_addr_t dma_handle,
+extern void iommu_unmap_phys(struct iommu_table *tbl, dma_addr_t dma_handle,
 			     size_t size, enum dma_data_direction direction,
 			     unsigned long attrs);
 
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 0359ab72cd3ba..aa3689d619179 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -93,28 +93,26 @@ static void dma_iommu_free_coherent(struct device *dev, size_t size,
 
 /* Creates TCEs for a user provided buffer.  The user buffer must be
  * contiguous real kernel storage (not vmalloc).  The address passed here
- * comprises a page address and offset into that page. The dma_addr_t
- * returned will point to the same byte within the page as was passed in.
+ * is a physical address to that page. The dma_addr_t returned will point
+ * to the same byte within the page as was passed in.
  */
-static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
-				     unsigned long offset, size_t size,
+static dma_addr_t dma_iommu_map_phys(struct device *dev, phys_addr_t phys,
+				     size_t size,
 				     enum dma_data_direction direction,
 				     unsigned long attrs)
 {
-	return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
-			      size, dma_get_mask(dev), direction, attrs);
+	return iommu_map_phys(dev, get_iommu_table_base(dev), phys, size,
+			      dma_get_mask(dev), direction, attrs);
 }
 
-
-static void dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void dma_iommu_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 				 size_t size, enum dma_data_direction direction,
 				 unsigned long attrs)
 {
-	iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
+	iommu_unmap_phys(get_iommu_table_base(dev), dma_handle, size, direction,
 			 attrs);
 }
 
-
 static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
 			    int nelems, enum dma_data_direction direction,
 			    unsigned long attrs)
@@ -211,8 +209,8 @@ const struct dma_map_ops dma_iommu_ops = {
 	.map_sg			= dma_iommu_map_sg,
 	.unmap_sg		= dma_iommu_unmap_sg,
 	.dma_supported		= dma_iommu_dma_supported,
-	.map_page		= dma_iommu_map_page,
-	.unmap_page		= dma_iommu_unmap_page,
+	.map_phys		= dma_iommu_map_phys,
+	.unmap_phys		= dma_iommu_unmap_phys,
 	.get_required_mask	= dma_iommu_get_required_mask,
 	.mmap			= dma_common_mmap,
 	.get_sgtable		= dma_common_get_sgtable,
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 244eb4857e7f4..6b5f4b72ce97f 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -848,12 +848,12 @@ EXPORT_SYMBOL_GPL(iommu_tce_table_put);
 
 /* Creates TCEs for a user provided buffer.  The user buffer must be
  * contiguous real kernel storage (not vmalloc).  The address passed here
- * comprises a page address and offset into that page. The dma_addr_t
- * returned will point to the same byte within the page as was passed in.
+ * is physical address into that page. The dma_addr_t returned will point
+ * to the same byte within the page as was passed in.
  */
-dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
-			  struct page *page, unsigned long offset, size_t size,
-			  unsigned long mask, enum dma_data_direction direction,
+dma_addr_t iommu_map_phys(struct device *dev, struct iommu_table *tbl,
+			  phys_addr_t phys, size_t size, unsigned long mask,
+			  enum dma_data_direction direction,
 			  unsigned long attrs)
 {
 	dma_addr_t dma_handle = DMA_MAPPING_ERROR;
@@ -863,7 +863,7 @@ dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
 
 	BUG_ON(direction == DMA_NONE);
 
-	vaddr = page_address(page) + offset;
+	vaddr = phys_to_virt(phys);
 	uaddr = (unsigned long)vaddr;
 
 	if (tbl) {
@@ -890,7 +890,7 @@ dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
 	return dma_handle;
 }
 
-void iommu_unmap_page(struct iommu_table *tbl, dma_addr_t dma_handle,
+void iommu_unmap_phys(struct iommu_table *tbl, dma_addr_t dma_handle,
 		      size_t size, enum dma_data_direction direction,
 		      unsigned long attrs)
 {
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index afbaabf182d01..6adcf76c70219 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -551,18 +551,20 @@ static void ps3_free_coherent(struct device *_dev, size_t size, void *vaddr,
 
 /* Creates TCEs for a user provided buffer.  The user buffer must be
  * contiguous real kernel storage (not vmalloc).  The address passed here
- * comprises a page address and offset into that page. The dma_addr_t
- * returned will point to the same byte within the page as was passed in.
+ * is physical address to that hat page. The dma_addr_t returned will point
+ * to the same byte within the page as was passed in.
  */
 
-static dma_addr_t ps3_sb_map_page(struct device *_dev, struct page *page,
-	unsigned long offset, size_t size, enum dma_data_direction direction,
-	unsigned long attrs)
+static dma_addr_t ps3_sb_map_phys(struct device *_dev, phys_addr_t phys,
+	size_t size, enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
 	int result;
 	dma_addr_t bus_addr;
-	void *ptr = page_address(page) + offset;
+	void *ptr = phys_to_virt(phys);
+
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
 	result = ps3_dma_map(dev->d_region, (unsigned long)ptr, size,
 			     &bus_addr,
@@ -577,8 +579,8 @@ static dma_addr_t ps3_sb_map_page(struct device *_dev, struct page *page,
 	return bus_addr;
 }
 
-static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
-				    unsigned long offset, size_t size,
+static dma_addr_t ps3_ioc0_map_phys(struct device *_dev, phys_addr_t phys,
+				    size_t size,
 				    enum dma_data_direction direction,
 				    unsigned long attrs)
 {
@@ -586,7 +588,10 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
 	int result;
 	dma_addr_t bus_addr;
 	u64 iopte_flag;
-	void *ptr = page_address(page) + offset;
+	void *ptr = phys_to_virt(phys);
+
+	if (attrs & DMA_ATTR_MMIO)
+		return;
 
 	iopte_flag = CBE_IOPTE_M;
 	switch (direction) {
@@ -613,7 +618,7 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
 	return bus_addr;
 }
 
-static void ps3_unmap_page(struct device *_dev, dma_addr_t dma_addr,
+static void ps3_unmap_phys(struct device *_dev, dma_addr_t dma_addr,
 	size_t size, enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
@@ -690,8 +695,8 @@ static const struct dma_map_ops ps3_sb_dma_ops = {
 	.map_sg = ps3_sb_map_sg,
 	.unmap_sg = ps3_sb_unmap_sg,
 	.dma_supported = ps3_dma_supported,
-	.map_page = ps3_sb_map_page,
-	.unmap_page = ps3_unmap_page,
+	.map_phys = ps3_sb_map_phys,
+	.unmap_phys = ps3_unmap_phys,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
 	.alloc_pages_op = dma_common_alloc_pages,
@@ -704,8 +709,8 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
 	.map_sg = ps3_ioc0_map_sg,
 	.unmap_sg = ps3_ioc0_unmap_sg,
 	.dma_supported = ps3_dma_supported,
-	.map_page = ps3_ioc0_map_page,
-	.unmap_page = ps3_unmap_page,
+	.map_phys = ps3_ioc0_map_phys,
+	.unmap_phys = ps3_unmap_phys,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
 	.alloc_pages_op = dma_common_alloc_pages,
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c b/arch/powerpc/platforms/pseries/ibmebus.c
index 3436b0af795e2..cad2deb7e70d9 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -86,17 +86,18 @@ static void ibmebus_free_coherent(struct device *dev,
 	kfree(vaddr);
 }
 
-static dma_addr_t ibmebus_map_page(struct device *dev,
-				   struct page *page,
-				   unsigned long offset,
+static dma_addr_t ibmebus_map_phys(struct device *dev, phys_addr_t phys,
 				   size_t size,
 				   enum dma_data_direction direction,
 				   unsigned long attrs)
 {
-	return (dma_addr_t)(page_address(page) + offset);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return (dma_addr_t)(phys_to_virt(phys));
 }
 
-static void ibmebus_unmap_page(struct device *dev,
+static void ibmebus_unmap_phys(struct device *dev,
 			       dma_addr_t dma_addr,
 			       size_t size,
 			       enum dma_data_direction direction,
@@ -146,8 +147,8 @@ static const struct dma_map_ops ibmebus_dma_ops = {
 	.unmap_sg           = ibmebus_unmap_sg,
 	.dma_supported      = ibmebus_dma_supported,
 	.get_required_mask  = ibmebus_dma_get_required_mask,
-	.map_page           = ibmebus_map_page,
-	.unmap_page         = ibmebus_unmap_page,
+	.map_phys           = ibmebus_map_phys,
+	.unmap_phys         = ibmebus_unmap_phys,
 };
 
 static int ibmebus_match_path(struct device *dev, const void *data)
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index ac1d2d2c9a88a..838e29d473785 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -512,18 +512,21 @@ static void vio_dma_iommu_free_coherent(struct device *dev, size_t size,
 	vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
 }
 
-static dma_addr_t vio_dma_iommu_map_page(struct device *dev, struct page *page,
-                                         unsigned long offset, size_t size,
-                                         enum dma_data_direction direction,
-                                         unsigned long attrs)
+static dma_addr_t vio_dma_iommu_map_phys(struct device *dev, phys_addr_t phys,
+					 size_t size,
+					 enum dma_data_direction direction,
+					 unsigned long attrs)
 {
 	struct vio_dev *viodev = to_vio_dev(dev);
 	struct iommu_table *tbl = get_iommu_table_base(dev);
 	dma_addr_t ret = DMA_MAPPING_ERROR;
 
+	if (attrs & DMA_ATTR_MMIO)
+		return ret;
+
 	if (vio_cmo_alloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl))))
 		goto out_fail;
-	ret = iommu_map_page(dev, tbl, page, offset, size, dma_get_mask(dev),
+	ret = iommu_map_phys(dev, tbl, phys, size, dma_get_mask(dev),
 			direction, attrs);
 	if (unlikely(ret == DMA_MAPPING_ERROR))
 		goto out_deallocate;
@@ -536,7 +539,7 @@ static dma_addr_t vio_dma_iommu_map_page(struct device *dev, struct page *page,
 	return DMA_MAPPING_ERROR;
 }
 
-static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void vio_dma_iommu_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 				     size_t size,
 				     enum dma_data_direction direction,
 				     unsigned long attrs)
@@ -544,7 +547,7 @@ static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
 	struct vio_dev *viodev = to_vio_dev(dev);
 	struct iommu_table *tbl = get_iommu_table_base(dev);
 
-	iommu_unmap_page(tbl, dma_handle, size, direction, attrs);
+	iommu_unmap_phys(tbl, dma_handle, size, direction, attrs);
 	vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
 }
 
@@ -605,8 +608,8 @@ static const struct dma_map_ops vio_dma_mapping_ops = {
 	.free              = vio_dma_iommu_free_coherent,
 	.map_sg            = vio_dma_iommu_map_sg,
 	.unmap_sg          = vio_dma_iommu_unmap_sg,
-	.map_page          = vio_dma_iommu_map_page,
-	.unmap_page        = vio_dma_iommu_unmap_page,
+	.map_phys          = vio_dma_iommu_map_phys,
+	.unmap_phys        = vio_dma_iommu_unmap_phys,
 	.dma_supported     = dma_iommu_dma_supported,
 	.get_required_mask = dma_iommu_get_required_mask,
 	.mmap		   = dma_common_mmap,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:45:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:45:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126438.1468033 (Exim 4.92)
	(envelope-from )
	id 1uzJdg-0004PD-H9; Thu, 18 Sep 2025 18:45:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126438.1468033; Thu, 18 Sep 2025 18: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 1uzJdg-0004P2-EU; Thu, 18 Sep 2025 18:45:52 +0000
Received: by outflank-mailman (input) for mailman id 1126438;
 Thu, 18 Sep 2025 18:45: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 1uzJde-0003Vt-Rq
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:45:50 +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 b1703eb6-94bf-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 20:45:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 441A56020F;
 Thu, 18 Sep 2025 18:45:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 160A2C4CEE7;
 Thu, 18 Sep 2025 18:45: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: b1703eb6-94bf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221147;
	bh=cZbejEi6nkNmkzheeCBAGk92h84S9bA1MI/LRocXjWE=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=sNr2edIlUVPpwBqbOV9yBQP1/FOhaJ6YeDv3YF3kmR8I+TMxL1QjnGjSU1FxrbpQ/
	 lQ6VcMvO1t0Fx87meU0SneChvQ6BiwlfAXAVkQw/+mZLpALEBWt/7dbuxqQajOetpg
	 E0UpfldbzcJ5ehVg/st5XBRiSC6U7x11vRJ6y4GDfv5SOH4qS/egi0PrkYatzt2/al
	 IaK4aFx2ASuaQdtIxto4VB/hGINa/kGkbBcnJ0j1gtF3HkRNcWWSOO8gn40Leemglo
	 4dtHyTyMQB3UcRW4eJch2wTwtgCcaQp2MoPH5kDS581Z+XWWHAWeK4xod4u549Jg4N
	 Sqf5FMk/Rnwhw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/9] MIPS/jazzdma: Provide physical address directly
Date: Thu, 18 Sep 2025 21:45:02 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

MIPS jazz uses physical addresses for mapping pages, so convert
it to get them directly from DMA mapping routine.

Signed-off-by: Leon Romanovsky 
---
 arch/mips/jazz/jazzdma.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/mips/jazz/jazzdma.c b/arch/mips/jazz/jazzdma.c
index c97b089b99029..45fe71aa454b7 100644
--- a/arch/mips/jazz/jazzdma.c
+++ b/arch/mips/jazz/jazzdma.c
@@ -521,18 +521,24 @@ static void jazz_dma_free(struct device *dev, size_t size, void *vaddr,
 	__free_pages(virt_to_page(vaddr), get_order(size));
 }
 
-static dma_addr_t jazz_dma_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t size, enum dma_data_direction dir,
-		unsigned long attrs)
+static dma_addr_t jazz_dma_map_phys(struct device *dev, phys_addr_t phys,
+		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	phys_addr_t phys = page_to_phys(page) + offset;
+	if (attrs & DMA_ATTR_MMIO)
+		/*
+		 * This check is included because older versions of the code lacked
+		 * MMIO path support, and my ability to test this path is limited.
+		 * However, from a software technical standpoint, there is no restriction,
+		 * as the following code operates solely on physical addresses.
+		 */
+		return DMA_MAPPING_ERROR;
 
 	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
 		arch_sync_dma_for_device(phys, size, dir);
 	return vdma_alloc(phys, size);
 }
 
-static void jazz_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void jazz_dma_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
@@ -607,8 +613,8 @@ static void jazz_dma_sync_sg_for_cpu(struct device *dev,
 const struct dma_map_ops jazz_dma_ops = {
 	.alloc			= jazz_dma_alloc,
 	.free			= jazz_dma_free,
-	.map_page		= jazz_dma_map_page,
-	.unmap_page		= jazz_dma_unmap_page,
+	.map_phys		= jazz_dma_map_phys,
+	.unmap_phys		= jazz_dma_unmap_phys,
 	.map_sg			= jazz_dma_map_sg,
 	.unmap_sg		= jazz_dma_unmap_sg,
 	.sync_single_for_cpu	= jazz_dma_sync_single_for_cpu,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126443.1468043 (Exim 4.92)
	(envelope-from )
	id 1uzJdl-0004s2-V7; Thu, 18 Sep 2025 18:45:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126443.1468043; Thu, 18 Sep 2025 18: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 1uzJdl-0004rv-R3; Thu, 18 Sep 2025 18:45:57 +0000
Received: by outflank-mailman (input) for mailman id 1126443;
 Thu, 18 Sep 2025 18: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 1uzJdk-0003Gi-Sj
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:45:56 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b4ba0a1e-94bf-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 20:45: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 F2518444D6;
 Thu, 18 Sep 2025 18:45:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BED33C4CEF1;
 Thu, 18 Sep 2025 18:45: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: b4ba0a1e-94bf-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221152;
	bh=t2K4sW07xLmohMbEHNKuCoco8SWkCKi7+Pye3QSpGNA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=ApQAftbQR/jnJU2HzvT/hfBSzMBH8l9oVxYJvIJILBwOkF6XJJC/bSesqHAbmBP6u
	 P4kPqKENM/py7u+cYWOMrhH3+pE/5jyp4qqyE4UDzVb5l/1iNNb4ImC6JoUa2UrQ9g
	 HoDSVJ65VO2VyCLe7wSh33JQyAtAUnbol0LakPZkT5VHxvJDQfwyo07wdmIvS+pi4k
	 JMnu0sgJrSZKHOTVtah/XqsI+nbf7OeODzaRmr6BIlvfuaSaKWkBbjh/9OLnt/fQR+
	 lKPYEZvVCBIvFLx87aT6KZk9bOv12pyvRFyBIive/3aZYoD0fFeZBsrH9oOTiFNFcj
	 4zp+LosB4q3Vw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 6/9] x86: Use physical address for DMA mapping
Date: Thu, 18 Sep 2025 21:45:06 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Perform mechanical conversion from DMA .map_page to .map_phys.

Signed-off-by: Leon Romanovsky 
---
 arch/x86/kernel/amd_gart_64.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 3485d419c2f5e..f1ffdc0e4a3ab 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -222,13 +222,14 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 }
 
 /* Map a single area into the IOMMU */
-static dma_addr_t gart_map_page(struct device *dev, struct page *page,
-				unsigned long offset, size_t size,
-				enum dma_data_direction dir,
+static dma_addr_t gart_map_phys(struct device *dev, phys_addr_t paddr,
+				size_t size, enum dma_data_direction dir,
 				unsigned long attrs)
 {
 	unsigned long bus;
-	phys_addr_t paddr = page_to_phys(page) + offset;
+
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
@@ -242,7 +243,7 @@ static dma_addr_t gart_map_page(struct device *dev, struct page *page,
 /*
  * Free a DMA mapping.
  */
-static void gart_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void gart_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 			    size_t size, enum dma_data_direction dir,
 			    unsigned long attrs)
 {
@@ -282,7 +283,7 @@ static void gart_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 	for_each_sg(sg, s, nents, i) {
 		if (!s->dma_length || !s->length)
 			break;
-		gart_unmap_page(dev, s->dma_address, s->dma_length, dir, 0);
+		gart_unmap_phys(dev, s->dma_address, s->dma_length, dir, 0);
 	}
 }
 
@@ -487,7 +488,7 @@ static void
 gart_free_coherent(struct device *dev, size_t size, void *vaddr,
 		   dma_addr_t dma_addr, unsigned long attrs)
 {
-	gart_unmap_page(dev, dma_addr, size, DMA_BIDIRECTIONAL, 0);
+	gart_unmap_phys(dev, dma_addr, size, DMA_BIDIRECTIONAL, 0);
 	dma_direct_free(dev, size, vaddr, dma_addr, attrs);
 }
 
@@ -668,8 +669,8 @@ static __init int init_amd_gatt(struct agp_kern_info *info)
 static const struct dma_map_ops gart_dma_ops = {
 	.map_sg				= gart_map_sg,
 	.unmap_sg			= gart_unmap_sg,
-	.map_page			= gart_map_page,
-	.unmap_page			= gart_unmap_page,
+	.map_phys			= gart_map_phys,
+	.unmap_phys			= gart_unmap_phys,
 	.alloc				= gart_alloc_coherent,
 	.free				= gart_free_coherent,
 	.mmap				= dma_common_mmap,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:46:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:46:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126449.1468053 (Exim 4.92)
	(envelope-from )
	id 1uzJdq-0005MW-5b; Thu, 18 Sep 2025 18:46:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126449.1468053; Thu, 18 Sep 2025 18:46: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 1uzJdq-0005LS-1d; Thu, 18 Sep 2025 18:46:02 +0000
Received: by outflank-mailman (input) for mailman id 1126449;
 Thu, 18 Sep 2025 18:46: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 1uzJdp-0003Vt-Ae
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:46: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 b6e99914-94bf-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 20:45: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 63592435E5;
 Thu, 18 Sep 2025 18:45:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65B01C4CEE7;
 Thu, 18 Sep 2025 18:45: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: b6e99914-94bf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221157;
	bh=1mDXfVNbsYLo4a+duzDpY85ZUnJWos79Vyrao8w+xkA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=uJjcqkjioeaPHR3oTtovXk7XnK/pd4Dpvt6tqBF2mLVNs5Q4naZBBRjxEELRfi2+Y
	 D4kIQlN6hJhac0eiwI3sASKq7B/5bGRMKu7BFRE0t7mA5u6NXWj4T2DNxp00i+Dz8P
	 CDKvCCa9nHcj0qbtseSusPltdxhIdxKZ4Yl5D4KaZQNkpzvLKwIkvugBIZkuUi+n41
	 sRDjxFx3/OcIdrXVx9M+pcPfgc0XKte5yCfdgAtR79e5ju1JRnVXErNA0tRs33R8Nz
	 1UIUOZkvr968XteLjAHpFkZyPWqxmq1DajIw+0WZAlLFornxw8ZulfpFSWmmyNnZ69
	 l7OvidjZ6KebQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 7/9] vdpa: Convert to physical address DMA mapping
Date: Thu, 18 Sep 2025 21:45:07 +0300
Message-ID: <517785de56c12927a782b6bc51cc84e06493958d.1758219787.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Use physical address directly in DMA mapping flow.

Signed-off-by: Leon Romanovsky 
---
 drivers/vdpa/vdpa_user/iova_domain.c | 11 +++++------
 drivers/vdpa/vdpa_user/iova_domain.h |  8 ++++----
 drivers/vdpa/vdpa_user/vduse_dev.c   | 18 ++++++++++--------
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c
index 58116f89d8dae..c0ecf01003cd3 100644
--- a/drivers/vdpa/vdpa_user/iova_domain.c
+++ b/drivers/vdpa/vdpa_user/iova_domain.c
@@ -396,17 +396,16 @@ void vduse_domain_sync_single_for_cpu(struct vduse_iova_domain *domain,
 	read_unlock(&domain->bounce_lock);
 }
 
-dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
-				 struct page *page, unsigned long offset,
-				 size_t size, enum dma_data_direction dir,
+dma_addr_t vduse_domain_map_phys(struct vduse_iova_domain *domain,
+				 phys_addr_t pa, size_t size,
+				 enum dma_data_direction dir,
 				 unsigned long attrs)
 {
 	struct iova_domain *iovad = &domain->stream_iovad;
 	unsigned long limit = domain->bounce_size - 1;
-	phys_addr_t pa = page_to_phys(page) + offset;
 	dma_addr_t iova = vduse_domain_alloc_iova(iovad, size, limit);
 
-	if (!iova)
+	if (!iova || (attrs & DMA_ATTR_MMIO))
 		return DMA_MAPPING_ERROR;
 
 	if (vduse_domain_init_bounce_map(domain))
@@ -430,7 +429,7 @@ dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
 	return DMA_MAPPING_ERROR;
 }
 
-void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+void vduse_domain_unmap_phys(struct vduse_iova_domain *domain,
 			     dma_addr_t dma_addr, size_t size,
 			     enum dma_data_direction dir, unsigned long attrs)
 {
diff --git a/drivers/vdpa/vdpa_user/iova_domain.h b/drivers/vdpa/vdpa_user/iova_domain.h
index 7f3f0928ec781..7c4546fd856ab 100644
--- a/drivers/vdpa/vdpa_user/iova_domain.h
+++ b/drivers/vdpa/vdpa_user/iova_domain.h
@@ -53,12 +53,12 @@ void vduse_domain_sync_single_for_cpu(struct vduse_iova_domain *domain,
 				      dma_addr_t dma_addr, size_t size,
 				      enum dma_data_direction dir);
 
-dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
-				 struct page *page, unsigned long offset,
-				 size_t size, enum dma_data_direction dir,
+dma_addr_t vduse_domain_map_phys(struct vduse_iova_domain *domain,
+				 phys_addr_t phys, size_t size,
+				 enum dma_data_direction dir,
 				 unsigned long attrs);
 
-void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+void vduse_domain_unmap_phys(struct vduse_iova_domain *domain,
 			     dma_addr_t dma_addr, size_t size,
 			     enum dma_data_direction dir, unsigned long attrs);
 
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index 04620bb77203d..75aa3c9f83fb5 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -834,25 +834,27 @@ static void vduse_dev_sync_single_for_cpu(struct device *dev,
 	vduse_domain_sync_single_for_cpu(domain, dma_addr, size, dir);
 }
 
-static dma_addr_t vduse_dev_map_page(struct device *dev, struct page *page,
-				     unsigned long offset, size_t size,
-				     enum dma_data_direction dir,
+static dma_addr_t vduse_dev_map_phys(struct device *dev, phys_addr_t phys,
+				     size_t size, enum dma_data_direction dir,
 				     unsigned long attrs)
 {
 	struct vduse_dev *vdev = dev_to_vduse(dev);
 	struct vduse_iova_domain *domain = vdev->domain;
 
-	return vduse_domain_map_page(domain, page, offset, size, dir, attrs);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return vduse_domain_map_phys(domain, phys, size, dir, attrs);
 }
 
-static void vduse_dev_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void vduse_dev_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 				size_t size, enum dma_data_direction dir,
 				unsigned long attrs)
 {
 	struct vduse_dev *vdev = dev_to_vduse(dev);
 	struct vduse_iova_domain *domain = vdev->domain;
 
-	return vduse_domain_unmap_page(domain, dma_addr, size, dir, attrs);
+	return vduse_domain_unmap_phys(domain, dma_addr, size, dir, attrs);
 }
 
 static void *vduse_dev_alloc_coherent(struct device *dev, size_t size,
@@ -896,8 +898,8 @@ static size_t vduse_dev_max_mapping_size(struct device *dev)
 static const struct dma_map_ops vduse_dev_dma_ops = {
 	.sync_single_for_device = vduse_dev_sync_single_for_device,
 	.sync_single_for_cpu = vduse_dev_sync_single_for_cpu,
-	.map_page = vduse_dev_map_page,
-	.unmap_page = vduse_dev_unmap_page,
+	.map_phys = vduse_dev_map_phys,
+	.unmap_phys = vduse_dev_unmap_phys,
 	.alloc = vduse_dev_alloc_coherent,
 	.free = vduse_dev_free_coherent,
 	.max_mapping_size = vduse_dev_max_mapping_size,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:46:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:46:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126452.1468063 (Exim 4.92)
	(envelope-from )
	id 1uzJdt-0005hJ-F5; Thu, 18 Sep 2025 18:46:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126452.1468063; Thu, 18 Sep 2025 18:46: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 1uzJdt-0005h4-Af; Thu, 18 Sep 2025 18:46:05 +0000
Received: by outflank-mailman (input) for mailman id 1126452;
 Thu, 18 Sep 2025 18: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 1uzJds-0003Gi-0f
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:46: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 b9e56101-94bf-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 20:46: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 4BFB160217;
 Thu, 18 Sep 2025 18:46:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF400C4CEE7;
 Thu, 18 Sep 2025 18:46: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: b9e56101-94bf-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221162;
	bh=RuMQ11goh2JNImFK4PcuJ9yLKsyHcn6/phLR164pkzU=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Q5B3soPWe59i7AumuQAtzGCpEErxVeTC7wi+Di8G6eOVT1MVZTt/JgzUnlVjGRPoW
	 ErCqMMeGsidHG1N+knFqgXjPEsOdPPiFQ0rIz4DZLI0HbYVEM3hq9hxORsFYl5H2fx
	 J60n2vb7xaJx4ibgjmaY8IKcwdgAFKEXlRg60rf39+CjCdf5WsqUpjL/TGOC7MGeDk
	 X/Ja5mBKKeU7UABgCctHcfJDW3VdXWr07H5WLSQu0NCMdcZtRlu/szIqbspA2f3jrE
	 yZJ63F0xUTPrPP7BvjqshrVIrvOkK4Vw3omPkJrYVm7ziJdzMMMM8Sk6cOqpJu0RSX
	 bLwC9O22I7FmA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 5/9] sparc64: Use physical address DMA mapping
Date: Thu, 18 Sep 2025 21:45:05 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Convert sparc architecture DMA code to use .map_phys callback.

Signed-off-by: Leon Romanovsky 
---
 arch/sparc/kernel/iommu.c     | 16 ++++++------
 arch/sparc/kernel/pci_sun4v.c | 16 ++++++------
 arch/sparc/mm/io-unit.c       | 13 +++++-----
 arch/sparc/mm/iommu.c         | 46 ++++++++++++++++++-----------------
 4 files changed, 48 insertions(+), 43 deletions(-)

diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c
index da03636925283..72bd7519ac2ab 100644
--- a/arch/sparc/kernel/iommu.c
+++ b/arch/sparc/kernel/iommu.c
@@ -260,9 +260,8 @@ static void dma_4u_free_coherent(struct device *dev, size_t size,
 		free_pages((unsigned long)cpu, order);
 }
 
-static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
-				  unsigned long offset, size_t sz,
-				  enum dma_data_direction direction,
+static dma_addr_t dma_4u_map_phys(struct device *dev, phys_addr_t phys,
+				  size_t sz, enum dma_data_direction direction,
 				  unsigned long attrs)
 {
 	struct iommu *iommu;
@@ -273,13 +272,16 @@ static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
 	u32 bus_addr, ret;
 	unsigned long iopte_protection;
 
+	if (attrs & DMA_ATTR_MMIO)
+		goto bad;
+
 	iommu = dev->archdata.iommu;
 	strbuf = dev->archdata.stc;
 
 	if (unlikely(direction == DMA_NONE))
 		goto bad_no_ctx;
 
-	oaddr = (unsigned long)(page_address(page) + offset);
+	oaddr = (unsigned long)(phys_to_virt(phys));
 	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
 	npages >>= IO_PAGE_SHIFT;
 
@@ -383,7 +385,7 @@ static void strbuf_flush(struct strbuf *strbuf, struct iommu *iommu,
 		       vaddr, ctx, npages);
 }
 
-static void dma_4u_unmap_page(struct device *dev, dma_addr_t bus_addr,
+static void dma_4u_unmap_phys(struct device *dev, dma_addr_t bus_addr,
 			      size_t sz, enum dma_data_direction direction,
 			      unsigned long attrs)
 {
@@ -753,8 +755,8 @@ static int dma_4u_supported(struct device *dev, u64 device_mask)
 static const struct dma_map_ops sun4u_dma_ops = {
 	.alloc			= dma_4u_alloc_coherent,
 	.free			= dma_4u_free_coherent,
-	.map_page		= dma_4u_map_page,
-	.unmap_page		= dma_4u_unmap_page,
+	.map_phys		= dma_4u_map_phys,
+	.unmap_phys		= dma_4u_unmap_phys,
 	.map_sg			= dma_4u_map_sg,
 	.unmap_sg		= dma_4u_unmap_sg,
 	.sync_single_for_cpu	= dma_4u_sync_single_for_cpu,
diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
index b720b21ccfbd8..d9d2464a948c9 100644
--- a/arch/sparc/kernel/pci_sun4v.c
+++ b/arch/sparc/kernel/pci_sun4v.c
@@ -352,9 +352,8 @@ static void dma_4v_free_coherent(struct device *dev, size_t size, void *cpu,
 		free_pages((unsigned long)cpu, order);
 }
 
-static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
-				  unsigned long offset, size_t sz,
-				  enum dma_data_direction direction,
+static dma_addr_t dma_4v_map_phys(struct device *dev, phys_addr_t phys,
+				  size_t sz, enum dma_data_direction direction,
 				  unsigned long attrs)
 {
 	struct iommu *iommu;
@@ -367,13 +366,16 @@ static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
 	dma_addr_t bus_addr, ret;
 	long entry;
 
+	if (attrs & DMA_ATTR_MMIO)
+		goto bad;
+
 	iommu = dev->archdata.iommu;
 	atu = iommu->atu;
 
 	if (unlikely(direction == DMA_NONE))
 		goto bad;
 
-	oaddr = (unsigned long)(page_address(page) + offset);
+	oaddr = (unsigned long)(phys_to_virt(phys));
 	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
 	npages >>= IO_PAGE_SHIFT;
 
@@ -426,7 +428,7 @@ static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
 	return DMA_MAPPING_ERROR;
 }
 
-static void dma_4v_unmap_page(struct device *dev, dma_addr_t bus_addr,
+static void dma_4v_unmap_phys(struct device *dev, dma_addr_t bus_addr,
 			      size_t sz, enum dma_data_direction direction,
 			      unsigned long attrs)
 {
@@ -686,8 +688,8 @@ static int dma_4v_supported(struct device *dev, u64 device_mask)
 static const struct dma_map_ops sun4v_dma_ops = {
 	.alloc				= dma_4v_alloc_coherent,
 	.free				= dma_4v_free_coherent,
-	.map_page			= dma_4v_map_page,
-	.unmap_page			= dma_4v_unmap_page,
+	.map_phys			= dma_4v_map_phys,
+	.unmap_phys			= dma_4v_unmap_phys,
 	.map_sg				= dma_4v_map_sg,
 	.unmap_sg			= dma_4v_unmap_sg,
 	.dma_supported			= dma_4v_supported,
diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c
index d8376f61b4d08..fab303cc33700 100644
--- a/arch/sparc/mm/io-unit.c
+++ b/arch/sparc/mm/io-unit.c
@@ -142,11 +142,10 @@ nexti:	scan = find_next_zero_bit(iounit->bmap, limit, scan);
 	return vaddr;
 }
 
-static dma_addr_t iounit_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t len, enum dma_data_direction dir,
-		unsigned long attrs)
+static dma_addr_t iounit_map_phys(struct device *dev, phys_addr_t phys,
+		size_t len, enum dma_data_direction dir, unsigned long attrs)
 {
-	void *vaddr = page_address(page) + offset;
+	void *vaddr = phys_to_virt(phys);
 	struct iounit_struct *iounit = dev->archdata.iommu;
 	unsigned long ret, flags;
 	
@@ -178,7 +177,7 @@ static int iounit_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
 	return nents;
 }
 
-static void iounit_unmap_page(struct device *dev, dma_addr_t vaddr, size_t len,
+static void iounit_unmap_phys(struct device *dev, dma_addr_t vaddr, size_t len,
 		enum dma_data_direction dir, unsigned long attrs)
 {
 	struct iounit_struct *iounit = dev->archdata.iommu;
@@ -279,8 +278,8 @@ static const struct dma_map_ops iounit_dma_ops = {
 	.alloc			= iounit_alloc,
 	.free			= iounit_free,
 #endif
-	.map_page		= iounit_map_page,
-	.unmap_page		= iounit_unmap_page,
+	.map_phys		= iounit_map_phys,
+	.unmap_phys		= iounit_unmap_phys,
 	.map_sg			= iounit_map_sg,
 	.unmap_sg		= iounit_unmap_sg,
 };
diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c
index 5a5080db800f5..dfcd981fa7efc 100644
--- a/arch/sparc/mm/iommu.c
+++ b/arch/sparc/mm/iommu.c
@@ -181,18 +181,20 @@ static void iommu_flush_iotlb(iopte_t *iopte, unsigned int niopte)
 	}
 }
 
-static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t len, bool per_page_flush)
+static dma_addr_t __sbus_iommu_map_phys(struct device *dev, phys_addr_t paddr,
+		size_t len, bool per_page_flush, unsigned long attrs)
 {
 	struct iommu_struct *iommu = dev->archdata.iommu;
-	phys_addr_t paddr = page_to_phys(page) + offset;
-	unsigned long off = paddr & ~PAGE_MASK;
+	unsigned long off = offset_in_page(paddr);
 	unsigned long npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
 	unsigned long pfn = __phys_to_pfn(paddr);
 	unsigned int busa, busa0;
 	iopte_t *iopte, *iopte0;
 	int ioptex, i;
 
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
 	/* XXX So what is maxphys for us and how do drivers know it? */
 	if (!len || len > 256 * 1024)
 		return DMA_MAPPING_ERROR;
@@ -202,10 +204,10 @@ static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
 	 * XXX Is this a good assumption?
 	 * XXX What if someone else unmaps it here and races us?
 	 */
-	if (per_page_flush && !PageHighMem(page)) {
+	if (per_page_flush && !PhysHighMem(paddr)) {
 		unsigned long vaddr, p;
 
-		vaddr = (unsigned long)page_address(page) + offset;
+		vaddr = (unsigned long)phys_to_virt(paddr);
 		for (p = vaddr & PAGE_MASK; p < vaddr + len; p += PAGE_SIZE)
 			flush_page_for_dma(p);
 	}
@@ -231,19 +233,19 @@ static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
 	return busa0 + off;
 }
 
-static dma_addr_t sbus_iommu_map_page_gflush(struct device *dev,
-		struct page *page, unsigned long offset, size_t len,
-		enum dma_data_direction dir, unsigned long attrs)
+static dma_addr_t sbus_iommu_map_phys_gflush(struct device *dev,
+		phys_addr_t phys, size_t len, enum dma_data_direction dir,
+		unsigned long attrs)
 {
 	flush_page_for_dma(0);
-	return __sbus_iommu_map_page(dev, page, offset, len, false);
+	return __sbus_iommu_map_phys(dev, phys, len, false, attrs);
 }
 
-static dma_addr_t sbus_iommu_map_page_pflush(struct device *dev,
-		struct page *page, unsigned long offset, size_t len,
-		enum dma_data_direction dir, unsigned long attrs)
+static dma_addr_t sbus_iommu_map_phys_pflush(struct device *dev,
+		phys_addr_t phys, size_t len, enum dma_data_direction dir,
+		unsigned long attrs)
 {
-	return __sbus_iommu_map_page(dev, page, offset, len, true);
+	return __sbus_iommu_map_phys(dev, phys, len, true, attrs);
 }
 
 static int __sbus_iommu_map_sg(struct device *dev, struct scatterlist *sgl,
@@ -254,8 +256,8 @@ static int __sbus_iommu_map_sg(struct device *dev, struct scatterlist *sgl,
 	int j;
 
 	for_each_sg(sgl, sg, nents, j) {
-		sg->dma_address =__sbus_iommu_map_page(dev, sg_page(sg),
-				sg->offset, sg->length, per_page_flush);
+		sg->dma_address = __sbus_iommu_map_phys(dev, sg_phys(sg),
+				sg->length, per_page_flush, attrs);
 		if (sg->dma_address == DMA_MAPPING_ERROR)
 			return -EIO;
 		sg->dma_length = sg->length;
@@ -277,7 +279,7 @@ static int sbus_iommu_map_sg_pflush(struct device *dev, struct scatterlist *sgl,
 	return __sbus_iommu_map_sg(dev, sgl, nents, dir, attrs, true);
 }
 
-static void sbus_iommu_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void sbus_iommu_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 		size_t len, enum dma_data_direction dir, unsigned long attrs)
 {
 	struct iommu_struct *iommu = dev->archdata.iommu;
@@ -303,7 +305,7 @@ static void sbus_iommu_unmap_sg(struct device *dev, struct scatterlist *sgl,
 	int i;
 
 	for_each_sg(sgl, sg, nents, i) {
-		sbus_iommu_unmap_page(dev, sg->dma_address, sg->length, dir,
+		sbus_iommu_unmap_phys(dev, sg->dma_address, sg->length, dir,
 				attrs);
 		sg->dma_address = 0x21212121;
 	}
@@ -426,8 +428,8 @@ static const struct dma_map_ops sbus_iommu_dma_gflush_ops = {
 	.alloc			= sbus_iommu_alloc,
 	.free			= sbus_iommu_free,
 #endif
-	.map_page		= sbus_iommu_map_page_gflush,
-	.unmap_page		= sbus_iommu_unmap_page,
+	.map_phys		= sbus_iommu_map_phys_gflush,
+	.unmap_phys		= sbus_iommu_unmap_phys,
 	.map_sg			= sbus_iommu_map_sg_gflush,
 	.unmap_sg		= sbus_iommu_unmap_sg,
 };
@@ -437,8 +439,8 @@ static const struct dma_map_ops sbus_iommu_dma_pflush_ops = {
 	.alloc			= sbus_iommu_alloc,
 	.free			= sbus_iommu_free,
 #endif
-	.map_page		= sbus_iommu_map_page_pflush,
-	.unmap_page		= sbus_iommu_unmap_page,
+	.map_phys		= sbus_iommu_map_phys_pflush,
+	.unmap_phys		= sbus_iommu_unmap_phys,
 	.map_sg			= sbus_iommu_map_sg_pflush,
 	.unmap_sg		= sbus_iommu_unmap_sg,
 };
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:46:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:46:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126461.1468073 (Exim 4.92)
	(envelope-from )
	id 1uzJe3-0006bh-OS; Thu, 18 Sep 2025 18:46:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126461.1468073; Thu, 18 Sep 2025 18:46: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 1uzJe3-0006bT-JC; Thu, 18 Sep 2025 18:46:15 +0000
Received: by outflank-mailman (input) for mailman id 1126461;
 Thu, 18 Sep 2025 18:46: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 1uzJe1-0003Vt-Re
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:46: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 bf29110f-94bf-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 20:46: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 4988060207;
 Thu, 18 Sep 2025 18:46:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41BE7C4CEE7;
 Thu, 18 Sep 2025 18:46: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: bf29110f-94bf-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221171;
	bh=uXtCKxAn4lJIk0uyzU0s1tMehbPq4hSpIpuFU2JE2Qo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=XcDUWomlStMMeFZ3/TJvShNKVI2ne4pT3ymiWQxIQ5cB6pCz+OArBrbwKpELnS63X
	 AsFRL1spAgwyeCLnIS2Br262lbJnqBbpCVd4ULOZVZtnj2C10kT6CvJ8n+8JUEAfYP
	 jFqxdtfM+opMXomXA3Ct9jKZuU3nvXXXih1anUIUmeYA2+NA0FUjI4Yl436qNKhCCW
	 Aa/Vm8u8X4+psfEgiqdpsNqbGjvUEPS8JA0bNbKSpeXk0dd7H1N/gfHZ8mh5pUso/C
	 fhMyzuZ9ej7kREv+eyKj/qcU15OhLAX2+3kVxzRJlcJjo/s2nJbBu1ygM503fdcjcp
	 lkA9Tjnlkw/og==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 8/9] xen: swiotlb: Convert mapping routine to rely  on physical address
Date: Thu, 18 Sep 2025 21:45:08 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Switch to .map_phys callback instead of .map_page.

Signed-off-by: Leon Romanovsky 
---
 drivers/xen/grant-dma-ops.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 29257d2639dbf..7f76e516fe24c 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -163,18 +163,22 @@ static void xen_grant_dma_free_pages(struct device *dev, size_t size,
 	xen_grant_dma_free(dev, size, page_to_virt(vaddr), dma_handle, 0);
 }
 
-static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
-					 unsigned long offset, size_t size,
+static dma_addr_t xen_grant_dma_map_phys(struct device *dev, phys_addr_t phys,
+					 size_t size,
 					 enum dma_data_direction dir,
 					 unsigned long attrs)
 {
 	struct xen_grant_dma_data *data;
+	unsigned long offset = offset_in_page(phys);
 	unsigned long dma_offset = xen_offset_in_page(offset),
 			pfn_offset = XEN_PFN_DOWN(offset);
 	unsigned int i, n_pages = XEN_PFN_UP(dma_offset + size);
 	grant_ref_t grant;
 	dma_addr_t dma_handle;
 
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
 	if (WARN_ON(dir == DMA_NONE))
 		return DMA_MAPPING_ERROR;
 
@@ -190,7 +194,7 @@ static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
 
 	for (i = 0; i < n_pages; i++) {
 		gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
-				pfn_to_gfn(page_to_xen_pfn(page) + i + pfn_offset),
+				pfn_to_gfn(page_to_xen_pfn(phys_to_page(phys)) + i + pfn_offset),
 				dir == DMA_TO_DEVICE);
 	}
 
@@ -199,7 +203,7 @@ static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
 	return dma_handle;
 }
 
-static void xen_grant_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void xen_grant_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 				     size_t size, enum dma_data_direction dir,
 				     unsigned long attrs)
 {
@@ -242,7 +246,7 @@ static void xen_grant_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
 		return;
 
 	for_each_sg(sg, s, nents, i)
-		xen_grant_dma_unmap_page(dev, s->dma_address, sg_dma_len(s), dir,
+		xen_grant_dma_unmap_phys(dev, s->dma_address, sg_dma_len(s), dir,
 				attrs);
 }
 
@@ -257,7 +261,7 @@ static int xen_grant_dma_map_sg(struct device *dev, struct scatterlist *sg,
 		return -EINVAL;
 
 	for_each_sg(sg, s, nents, i) {
-		s->dma_address = xen_grant_dma_map_page(dev, sg_page(s), s->offset,
+		s->dma_address = xen_grant_dma_map_phys(dev, sg_phys(s),
 				s->length, dir, attrs);
 		if (s->dma_address == DMA_MAPPING_ERROR)
 			goto out;
@@ -286,8 +290,8 @@ static const struct dma_map_ops xen_grant_dma_ops = {
 	.free_pages = xen_grant_dma_free_pages,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
-	.map_page = xen_grant_dma_map_page,
-	.unmap_page = xen_grant_dma_unmap_page,
+	.map_phys = xen_grant_dma_map_phys,
+	.unmap_phys = xen_grant_dma_unmap_phys,
 	.map_sg = xen_grant_dma_map_sg,
 	.unmap_sg = xen_grant_dma_unmap_sg,
 	.dma_supported = xen_grant_dma_supported,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 18:56:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 18:56:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126524.1468083 (Exim 4.92)
	(envelope-from )
	id 1uzJnn-0000xX-O6; Thu, 18 Sep 2025 18:56:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126524.1468083; Thu, 18 Sep 2025 18:56: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 1uzJnn-0000xQ-L1; Thu, 18 Sep 2025 18:56:19 +0000
Received: by outflank-mailman (input) for mailman id 1126524;
 Thu, 18 Sep 2025 18:56: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 1uzJdx-0003Gi-2c
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 18:46:09 +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 bce2820a-94bf-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 20:46: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 566A560213;
 Thu, 18 Sep 2025 18:46:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE03FC4CEE7;
 Thu, 18 Sep 2025 18:46: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: bce2820a-94bf-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758221167;
	bh=3bqXOAYctDiXe+OCMHlitClbfEhC7Di6QPs9FEZ1pPI=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=DrF4UB5vNiS1ar6EQULnP2g8xHqnzBBCJmALQvRpfCCwMERikovmxa5qLdv90lwcz
	 ISbg/kGE2Tx15VZG2vdkPFE7TQRrtuhFvEA4HHp4uvvjl43WFlncTqgHCP9W8wX6U0
	 xkIrRlvfY93G0GJ6rLphYBdU4/P5Y3W5660GWNxfdMbw9xHyNKR5bspM/f6LGlmcb0
	 udD+iUQiHebDEBJeOzgdkD6z4qs8pqG/CD7tfwkbjzQ863aDbZfxl2ejEdBKmr2Eva
	 UOsKQLShS++Ltzx7J/LCHkdw5NkgqooNDn4P7ThMastTfrzbD5CblRWK/tnQFtzeWT
	 PGzH6N+KD8OlA==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH 9/9] dma-mapping: remove unused map_page callback
Date: Thu, 18 Sep 2025 21:45:09 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

After conversion of arch code to use physical address mapping,
there are no users of .map_page() and .unmap_page() callbacks,
so let's remove them.

Signed-off-by: Leon Romanovsky 
---
 include/linux/dma-map-ops.h |  7 -------
 kernel/dma/mapping.c        | 12 ------------
 kernel/dma/ops_helpers.c    |  8 +-------
 3 files changed, 1 insertion(+), 26 deletions(-)

diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index a2ec1566aa270..e0a78991fa8a3 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -31,13 +31,6 @@ struct dma_map_ops {
 			void *cpu_addr, dma_addr_t dma_addr, size_t size,
 			unsigned long attrs);
 
-	dma_addr_t (*map_page)(struct device *dev, struct page *page,
-			unsigned long offset, size_t size,
-			enum dma_data_direction dir, unsigned long attrs);
-	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
-			size_t size, enum dma_data_direction dir,
-			unsigned long attrs);
-
 	dma_addr_t (*map_phys)(struct device *dev, phys_addr_t phys,
 			size_t size, enum dma_data_direction dir,
 			unsigned long attrs);
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 32a85bfdf873a..37163eb49f9fa 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -171,16 +171,6 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
 	else if (ops->map_phys)
 		addr = ops->map_phys(dev, phys, size, dir, attrs);
-	else if (!is_mmio && ops->map_page) {
-		struct page *page = phys_to_page(phys);
-		size_t offset = offset_in_page(phys);
-
-		/*
-		 * The dma_ops API contract for ops->map_page() requires
-		 * kmappable memory.
-		 */
-		addr = ops->map_page(dev, page, offset, size, dir, attrs);
-	}
 
 	if (!is_mmio)
 		kmsan_handle_dma(phys, size, dir);
@@ -222,8 +212,6 @@ void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size,
 		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
 	else if (ops->unmap_phys)
 		ops->unmap_phys(dev, addr, size, dir, attrs);
-	else
-		ops->unmap_page(dev, addr, size, dir, attrs);
 	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
 	debug_dma_unmap_phys(dev, addr, size, dir);
 }
diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
index 1eccbdbc99c1e..20caf9cabf699 100644
--- a/kernel/dma/ops_helpers.c
+++ b/kernel/dma/ops_helpers.c
@@ -76,11 +76,8 @@ struct page *dma_common_alloc_pages(struct device *dev, size_t size,
 	if (use_dma_iommu(dev))
 		*dma_handle = iommu_dma_map_phys(dev, phys, size, dir,
 						 DMA_ATTR_SKIP_CPU_SYNC);
-	else if (ops->map_phys)
-		*dma_handle = ops->map_phys(dev, phys, size, dir,
-					    DMA_ATTR_SKIP_CPU_SYNC);
 	else
-		*dma_handle = ops->map_page(dev, page, 0, size, dir,
+		*dma_handle = ops->map_phys(dev, phys, size, dir,
 					    DMA_ATTR_SKIP_CPU_SYNC);
 	if (*dma_handle == DMA_MAPPING_ERROR) {
 		dma_free_contiguous(dev, page, size);
@@ -102,8 +99,5 @@ void dma_common_free_pages(struct device *dev, size_t size, struct page *page,
 	else if (ops->unmap_phys)
 		ops->unmap_phys(dev, dma_handle, size, dir,
 				DMA_ATTR_SKIP_CPU_SYNC);
-	else if (ops->unmap_page)
-		ops->unmap_page(dev, dma_handle, size, dir,
-				DMA_ATTR_SKIP_CPU_SYNC);
 	dma_free_contiguous(dev, page, size);
 }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 19:59:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 19:59:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126571.1468093 (Exim 4.92)
	(envelope-from )
	id 1uzKmJ-00015M-2v; Thu, 18 Sep 2025 19:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126571.1468093; Thu, 18 Sep 2025 19: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 1uzKmJ-00015F-0M; Thu, 18 Sep 2025 19:58:51 +0000
Received: by outflank-mailman (input) for mailman id 1126571;
 Thu, 18 Sep 2025 19:58: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 1uzKmH-000159-A2
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 19:58:49 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e02c2246-94c9-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 21:58:42 +0200 (CEST)
Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com
 [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-653-aRxG5rpCMx6-Pb2hK5WnQw-1; Thu, 18 Sep 2025 15:58:38 -0400
Received: by mail-qt1-f199.google.com with SMTP id
 d75a77b69052e-4b7a5595a05so29153961cf.3
 for ; Thu, 18 Sep 2025 12:58:38 -0700 (PDT)
Received: from x1.local
 (bras-base-aurron9134w-grc-11-174-89-135-121.dsl.bell.ca. [174.89.135.121])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-4bdaa0c5156sm18265951cf.45.2025.09.18.12.58.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 18 Sep 2025 12:58: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: e02c2246-94c9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758225521;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ZhJgUVOrIl/9LhFZvU5vWNCdAStYK7nWNGdsvwSJnMA=;
	b=Xk/T2/0eg3aNeKzJuRENqlwy0f6ugZ7nRYkDMx9TRGAswTetDfQOZp0EG+zyY4GFN9Jhyc
	ASr393UiDEb7AlCUq4YlgBfqoGZPoJM0iT2uv94tMCaOKDDP+RR83C30Gvlf+lI23d858R
	yIaTPO4M9eB1an+G0FTbIBhyMUM8+II=
X-MC-Unique: aRxG5rpCMx6-Pb2hK5WnQw-1
X-Mimecast-MFC-AGG-ID: aRxG5rpCMx6-Pb2hK5WnQw_1758225518
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758225517; x=1758830317;
        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=ZhJgUVOrIl/9LhFZvU5vWNCdAStYK7nWNGdsvwSJnMA=;
        b=hxaQlyKYOjzMLS4IqVTXZfdvvpMGPJ11geWlR26yfTOJ1E2IM6wSKeoAEqcGG5j4zm
         aCe0i6YtX0Dy3vrCOhJk4TGhhaF0fqw5NmAlAoD1ygDMv9tIcItxvst2aV+mdGiMz5ca
         JXKeUH+YHrUEcZ8ax7GuvmeRIM8lkhByClUSDq44LiremSjmCk/vJFmaSZAG12nbmo5Y
         g+nXRsfKX8I7PVd0hHqXw1lNlbF5kAPD/GW1qebNqh5GOuA5NYmjxNStextO+8JzxHTR
         TF4fHlFRLzPrTKzUF0YGkjfl+eFZkvhnndAHWw8g+60XuxKyVL2UUp9kAcbNwmT3ULfy
         /lmQ==
X-Forwarded-Encrypted: i=1; AJvYcCWkhEKf2B5ebFgHzMnA2YKfV9HTzbvrR7mhi2mfok+cWVF9TeB4ElbV2Yt9pmLj1JeJvbibPhjnCxA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGTvrBxYXoEAH8njMoezSUmpPCFKUfAoqoDHBWa/W+vYWPonnS
	Io/YgdGWNDvvh8GRij/F9YGto1wIfoKorNkZjKMn6rdy6Qxg5Hz8ASkZNS/BCrDNc7G6sxCV5xQ
	hVFRce1a8PeDbZGftqIemUBFlRblIWOY32z2fdx4H02fdTOyLDDqY0KWINU9lJz1SbHUg
X-Gm-Gg: ASbGncuCGkuZq2LFF6RKD80yOgtnqPSL4ZYrExIIzqD/nSzYg6yhrE9TklGgaqA+AjO
	2IXC7ajyuaxqOwUk17SzkNPE5Qd3L+S+wJaLtgQ9uQbLL979UJTDA6penawNhphx7l7WUKrkeZZ
	Z4UjFxKbCNjghGgzXBPawHlTRjGM2pApv/H7Vcd8nHmD+Qsgk4xWbGpVDrEYxjM31hE/BPSZf8V
	Ve5adoXo+VkK1jT4jf6HriPUZWbkUeuzhtjp5gos3zOk4nsPhJbZRblOtnBEUFB3Gt1l0o5jDN3
	tpS/vO/R/lUzpGwVWkTlo6xs53B/ffMYzSbvRnoNDJ+7rUX3Yyjv9ZJMUCpl7g4gbKGl2aFyaG7
	iGH21Kyz8iDtfuHhESU1MzA==
X-Received: by 2002:ac8:6f15:0:b0:4b7:9aea:1a0d with SMTP id d75a77b69052e-4c0755a38cdmr6897491cf.76.1758225517485;
        Thu, 18 Sep 2025 12:58:37 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IG2L65vYNy7m4Z+UcdbfZGg3yWRQ/fGOSzmRN1Yhv/tl482ETUqjK3x9J9txcg/04v64li47Q==
X-Received: by 2002:ac8:6f15:0:b0:4b7:9aea:1a0d with SMTP id d75a77b69052e-4c0755a38cdmr6896771cf.76.1758225516835;
        Thu, 18 Sep 2025 12:58:36 -0700 (PDT)
Date: Thu, 18 Sep 2025 15:58:32 -0400
From: Peter Xu 
To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 
Cc: Akihiko Odaki , qemu-devel@nongnu.org,
	Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Eduardo Habkost ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
 
 
 
MIME-Version: 1.0
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: XTiPRqaDJkq9AHUL8Fa1SdICQKWJwd2mZCxb29MJ_6o_1758225518
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Wed, Sep 17, 2025 at 02:23:35PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 17, 2025 at 02:17:35PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> > > On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > > > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > > > Based-on: 
> > > > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> > > > > 
> > > > > Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
> > > > > ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
> > > > > 
> > > > > Children are automatically unparented so manually unparenting is
> > > > > unnecessary.
> > > > 
> > > > Where is automatic unparenting you're referring to being done ?
> > > > 
> > > > > Worse, automatic unparenting happens before the instance_finalize()
> > > > > callback of the parent gets called, so object_unparent() calls in
> > > > > the callback will refer to objects that are already unparented, which
> > > > > is semantically incorrect.
> > > > 
> > > > IIUC, object_property_add_child will acquire a reference on
> > > > the child, and object_property_del_child (and thus
> > > > object_unparent) will release that reference.
> > > > 
> > > > The 'object_finalize' method, and thus 'instance_finalize'
> > > > callback, won't be invoked until the last reference is
> > > > dropped on the object in question.
> > > > 
> > > > IOW, it should be impossible for 'object_finalize' to ever
> > > > run, as long as the child has a parent set.
> > > > 
> > > > So if we're in the 'finalize' then 'object_unparent' must
> > > > be a no-op as the child must already have no references
> > > > held and thus no parent.
> > > > 
> > > > IOW, the reason to remove 'object_unparent' calls from
> > > > finalize is surely because they do nothing at all,
> > > > rather than this talk about callbacks being run at the
> > > > wrong time ?
> > > 
> > > This patch series deals with the situation where the parent calls
> > > object_unparent() in its instance_finalize() callback. The process of
> > > finalization looks like as follows:
> > > 
> > > 1. The parent's reference count reaches to zero. Please note that there can
> > > be remaining children that are referenced by the parent at this point.
> > > 
> > > 2. object_finalize() is called.
> > > 
> > > 2a. object_property_del_all() is called and the parent releases references
> > > to its children. This is what I referred as "automatic unparenting". The
> > > children without any other references will be finalized here.
> > > 
> > > 2b. instance_finalize() is called. Past children may be already finalized,
> > > and calling object_unparent() here will cause dereferencing finalized
> > > objects in that case, which should be avoided.
> > 
> > Oh, so these object_unparent calls run by the parent, against the child
> > in fact use-after-free flaws.
> 
> Oh actually not a use-after-free since memory regions aren't directly
> freed by object_finalize.

We discussed this previously, I think so far it's 100% safe to call
object_unparent() twice, because step (2a) will reset child->parent=NULL.
Then at (2b) calling object_unparent() will be 100% safe because it's no-op
for an object that is orphaned.

So the series looks good, but it's kind of a cleanup, as object_unparent()
is just unnecessary for these MRs, same to the memory.rst doc suggestions
which can be avoided.

Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 20:04:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 20:04:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126585.1468104 (Exim 4.92)
	(envelope-from )
	id 1uzKrG-0002gC-Lr; Thu, 18 Sep 2025 20:03:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126585.1468104; Thu, 18 Sep 2025 20: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 1uzKrG-0002g5-Hg; Thu, 18 Sep 2025 20:03:58 +0000
Received: by outflank-mailman (input) for mailman id 1126585;
 Thu, 18 Sep 2025 20: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 1uzKrF-0002fu-Il
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 20:03:57 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b815562-94ca-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 22:03:57 +0200 (CEST)
Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com
 [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-379-4FgNIfiwPGqI7IfuebIWrg-1; Thu, 18 Sep 2025 16:03:54 -0400
Received: by mail-qt1-f198.google.com with SMTP id
 d75a77b69052e-4b60dd9634dso28278751cf.2
 for ; Thu, 18 Sep 2025 13:03:54 -0700 (PDT)
Received: from x1.local
 (bras-base-aurron9134w-grc-11-174-89-135-121.dsl.bell.ca. [174.89.135.121])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-4bda15f91a0sm19307741cf.1.2025.09.18.13.03.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 18 Sep 2025 13:03: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: 9b815562-94ca-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758225836;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=LgVRs4qDWWl/SassPeYOJGunpCbcT4oPhyAu1oaWNOQ=;
	b=S7Ki0vBOvTkGsDnbAugmyhW83aFqvZGqXhokZtk3aQrUJoHeQUqU2emEfsUZxamDcOt7Wl
	1phEZkaA+7AFuYsF20h6aEH3LBpVMtsVU1nLoSykrBjWfW8VWn59fYevUHxkQnT/GjQ9iL
	dIb5wk+wYHOMsIV4SsY5Lh08uHe1yDY=
X-MC-Unique: 4FgNIfiwPGqI7IfuebIWrg-1
X-Mimecast-MFC-AGG-ID: 4FgNIfiwPGqI7IfuebIWrg_1758225834
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758225834; x=1758830634;
        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=LgVRs4qDWWl/SassPeYOJGunpCbcT4oPhyAu1oaWNOQ=;
        b=Zl4Wn99oGVdrl0ETQTPhTU8H/a1nYcOfUw9S/VvOdgWJzq11pYk+e7wdqI2n/RO8pB
         QgvG24eydz0SLnWjcnFdeL0Uq5MmsJ5EQqGjizghjWwHXjoijImPnnivQc43yT9HBdk+
         0btJiICsGlLfI51Pz4F9O/nLpe8EqmTmWWGXZBh5SSdoOfQCfyQW/QwXJiykGhU2yp4T
         AZOOSbHbo6a/IlEOmNu2w6GHNs+NXvc/+X4YDfmXdIrHz+tr/GHgeGJAuYZBWTnzAR3+
         9MdjjtpZBa9VNiu9yZ1L5+U9GgXU/JtA2YqLiF9mvFFvNiPWEZWQ29Kd445mdJ0ZLfyq
         QwnQ==
X-Forwarded-Encrypted: i=1; AJvYcCVagIlIqWx38xajlMhnAvo222+CrdWjmqxULOA+7L5m0oojLEnxUsWaw9x/cX6EKYrzE145+2Re7pU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOSDxj5+jaKb9ZF9W1tsE4UU2V9YH0WQOZrQK6Z4qHR3HaSvyv
	SVLH+P+nYkFiRx00Igqed8Mlw1ChOGp9iN8eV5RjjdZ0pS5LCK8mKyDNLeZ3ZS6Z8+Xe9NsKEoh
	+PR0SOcztlgPAni0OWAIUKJQ3KEkb0zaNfl6CJjWlUwwHOZV5Ggc7JiL+fx62hJX+Kurh
X-Gm-Gg: ASbGncvPxgrwiQWBuYihJnkP8jahgfekuNSZEvmWP8EkVTXGd0sjgZswNRhZG1zQoxX
	xugf6apH41VwOYWenrd1GVQRJ+7aQjR5f/BPAcOVZrhEwxM/yrIfnC6J9MR7G66SqZiZc/SAatK
	cEwFOwa6THU/3n+eqaWLz+act5TRDvuQEU1kan0eDyiwt7Vy4Nh1hU+J9AkPwSRWh8GQcNWr4Lk
	FIZrB+KNFQbIKT0pNFNbYpkVFFRKUOmji5wCqDt0TRcyGDpzj7vD36Ba7bZhV9vpc4AmDxnvWxn
	aT0KI9AqoYUoFltzDQYxjsCOnbbSsH5vs/Mr94HMT+vkmtjNmyKHduUPNAwfvapcck3hWnCjEMN
	QK9Vhx1n9Mid6sxb5efPHmA==
X-Received: by 2002:a05:622a:5a88:b0:4b7:a98b:8933 with SMTP id d75a77b69052e-4c072d2d400mr6025911cf.62.1758225833754;
        Thu, 18 Sep 2025 13:03:53 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEB62ZbYxbCV9ZW2QX6E1EIwlRMLvImUy5ZMYB2/qRwmfyMDoEyMnXIs2TXp5P2RdybchVl+g==
X-Received: by 2002:a05:622a:5a88:b0:4b7:a98b:8933 with SMTP id d75a77b69052e-4c072d2d400mr6025121cf.62.1758225833133;
        Thu, 18 Sep 2025 13:03:53 -0700 (PDT)
Date: Thu, 18 Sep 2025 16:03:49 -0400
From: Peter Xu 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= ,
	Eduardo Habkost ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 1/7] docs/devel: Do not unparent in instance_finalize()
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
In-Reply-To: <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: DP4OJgtEntgX6uPWD2zYiopcK8FreBLhMwm9YZLDtfI_1758225834
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Remove the instruction to call object_unparent(), and the exception
> of the "do not call object_unparent()" rule for instance_finalize().
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  docs/devel/memory.rst | 19 ++++++-------------
>  1 file changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
> index 57fb2aec76e0..749f11d8a4dd 100644
> --- a/docs/devel/memory.rst
> +++ b/docs/devel/memory.rst
> @@ -161,18 +161,11 @@ or never.
>  Destruction of a memory region happens automatically when the owner
>  object dies.
>  
> -If however the memory region is part of a dynamically allocated data
> -structure, you should call object_unparent() to destroy the memory region
> -before the data structure is freed.  For an example see VFIOMSIXInfo
> -and VFIOQuirk in hw/vfio/pci.c.

Should we still keep some of these examples?  After the series they'll be
doing the right things.  Dynamic MRs are still slightly tricky, I think
it's still good to have some references.

> -
>  You must not destroy a memory region as long as it may be in use by a
>  device or CPU.  In order to do this, as a general rule do not create or
> -destroy memory regions dynamically during a device's lifetime, and only
> -call object_unparent() in the memory region owner's instance_finalize
> -callback.  The dynamically allocated data structure that contains the
> -memory region then should obviously be freed in the instance_finalize
> -callback as well.
> +destroy memory regions dynamically during a device's lifetime.
> +The dynamically allocated data structure that contains the
> +memory region should be freed in the instance_finalize callback.
>  
>  If you break this rule, the following situation can happen:
>  
> @@ -198,9 +191,9 @@ this exception is rarely necessary, and therefore it is discouraged,
>  but nevertheless it is used in a few places.
>  
>  For regions that "have no owner" (NULL is passed at creation time), the
> -machine object is actually used as the owner.  Since instance_finalize is
> -never called for the machine object, you must never call object_unparent
> -on regions that have no owner, unless they are aliases or containers.
> +machine object is actually used as the owner.  You must never call
> +object_unparent on regions that have no owner, unless they are aliases
> +or containers.

This looks like a completely separate change.  So we start to allow
machines to be finalized now?  I'm not familiar with machine object
lifecycles.  Maybe split it out even if it's true?

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 20:12:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 20:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126599.1468113 (Exim 4.92)
	(envelope-from )
	id 1uzKzK-0004Kt-DE; Thu, 18 Sep 2025 20:12:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126599.1468113; Thu, 18 Sep 2025 20:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzKzK-0004Km-9j; Thu, 18 Sep 2025 20:12:18 +0000
Received: by outflank-mailman (input) for mailman id 1126599;
 Thu, 18 Sep 2025 20:12: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 1uzKzI-0004Kg-9s
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 20:12:16 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0078c65-94cb-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 22:12:07 +0200 (CEST)
Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com
 [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-73-VBwf8nGCM1uiYMIaqUIzrA-1; Thu, 18 Sep 2025 16:12:04 -0400
Received: by mail-qt1-f199.google.com with SMTP id
 d75a77b69052e-4b5fbf0388eso18110091cf.3
 for ; Thu, 18 Sep 2025 13:12:04 -0700 (PDT)
Received: from x1.local
 (bras-base-aurron9134w-grc-11-174-89-135-121.dsl.bell.ca. [174.89.135.121])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-4bda23b2f56sm18877261cf.17.2025.09.18.13.12.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 18 Sep 2025 13:12: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: c0078c65-94cb-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758226326;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=oEVcW8H0ePrVkukmBhlQeYMXet9+27y8NnV6UVsaWN8=;
	b=gSPHM0yjwNoopRRUHJn9eZoRNY5uxy1pp041qJxzK7LW1ZToTjfKrI+6j/L2goQ3nX+j4q
	dfBBrRx9OA9AQJ9X48mct8j3SWDcYMwZ7ZAlrPyakrdFdI9syuVBFDnCKPkYeSNCygj7Y5
	MpreG3xHNVQcLIVMpZytib9/zUaEkgw=
X-MC-Unique: VBwf8nGCM1uiYMIaqUIzrA-1
X-Mimecast-MFC-AGG-ID: VBwf8nGCM1uiYMIaqUIzrA_1758226324
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758226324; x=1758831124;
        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=oEVcW8H0ePrVkukmBhlQeYMXet9+27y8NnV6UVsaWN8=;
        b=kjeuqpNQavzd2hC5kyqz27UWv5nAbKs7jKLTRMyZjyxYtqAsXtAG3Lk3Yah02e4PkW
         VH9X5q1inRvkRYK6297VQ9+0LmmivERFG8BK3EhwerXO5I80Uwermq0Xmwe7IyslgQt0
         cecT+F13O+rLhY9BwqNcuL9r/or0XmLTTPrNJ/o3MfmYPxvNf0rSwl4SSXthaly8pAqu
         R8YR1HlBkncCfZvQ5WkJ98uyjWjpKS6PzwJgx90V1a1B8JM6DGF/lM3hQDCAC2Gnk29a
         7eSPfrpATkjkSFqE3pGOvwbsLG/5tkmn/j7oGohd7+PE+VCQy+jr6uA7yaenQDsJJol/
         ePNw==
X-Forwarded-Encrypted: i=1; AJvYcCWtD5XWFcDdlQXHWTckThV7sj6LOU4k00H4al/gS57HB/XEw4SR0tSlc4UUg4NglAomWwdHZQrkYQc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBbtxIMQHmk3TAbPC+NUUqaY0W5pEXXPuiMoHYzLzNUC/EP7VK
	h5OeH3s0iTboFDBe3taz9RhLRVeon+r2by7jk8uYLWKze13UiYURgaETGHIZCCC4mvz8NgRLG8Y
	N4pRZCtXch3L5wsiplXzCY/NTDzP58UqqdJqTZ7uJqiSqY0SE4qUXi9L1kd+5ObHogqTl
X-Gm-Gg: ASbGncv9pzBr21MdRbMbZ7w6DrQ7sccW+oXbIq/Uhd4RuTPnYmmVPYZ5eqIYHkQzP7I
	CovH4GmVxkLzcgewfjpqBKr1Jl7ifhZIcbV/1MqsT+ItbkdTH09K5ikXJwktZ9sx0Iif+T3ln0e
	T5nTcdirJgVqe2AuzOEDD+8CMig9g2ZGbi/xhcbU34l7NQt76p/maZuiu2wvB0TIIZ1F7uw7Hj5
	G4yXERnmwJ9sd+90ZRh3nC9jsGbkhdqpWJkgAs4lGGaj8g+FwDfff5ho3Wk8BTrQ5xV89CUO4Ew
	zqvcQfJ3Yli6lJVDAWMfg6QaDBWM02AeaJ2BkRji+6QKRWvtKkJFei6UAY/EVQDX4YCIWrgkKlX
	8/M7FVP3Yxmt/YKd44I4tig==
X-Received: by 2002:a05:622a:1c15:b0:4b7:7c2c:8534 with SMTP id d75a77b69052e-4c06e3f8fe3mr6440771cf.15.1758226323614;
        Thu, 18 Sep 2025 13:12:03 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGlL/+jeC2xoiK55a+vc+/BjJtvtoJAoNqaFYRNOAjjjJKNk/RRtRDSXXsR7MkcplaBP8vv5Q==
X-Received: by 2002:a05:622a:1c15:b0:4b7:7c2c:8534 with SMTP id d75a77b69052e-4c06e3f8fe3mr6440401cf.15.1758226322974;
        Thu, 18 Sep 2025 13:12:02 -0700 (PDT)
Date: Thu, 18 Sep 2025 16:11:59 -0400
From: Peter Xu 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
	=?utf-8?Q?C=C3=A9dric?= Le Goater ,
	Paolo Bonzini ,
	Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= ,
	Eduardo Habkost ,
	David Hildenbrand ,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?utf-8?Q?Marc-Andr=C3=A9?= Lureau ,
	"Michael S. Tsirkin" ,
	Gerd Hoffmann , John Snow ,
	qemu-block@nongnu.org, Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin , qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	Alex =?utf-8?Q?Benn=C3=A9e?= ,
	Fabiano Rosas , Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?utf-8?B?SGVydsOp?= Poussineau ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S. Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 1/7] docs/devel: Do not unparent in instance_finalize()
Message-ID: 
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 
MIME-Version: 1.0
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: ewBEzSpwM5U06pT75eya7oFfG1QjkMRc16p7R5X04vc_1758226324
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Thu, Sep 18, 2025 at 04:03:49PM -0400, Peter Xu wrote:
> On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> > Children are automatically unparented so manually unparenting is
> > unnecessary.
> > 
> > Worse, automatic unparenting happens before the instance_finalize()
> > callback of the parent gets called, so object_unparent() calls in
> > the callback will refer to objects that are already unparented, which
> > is semantically incorrect.
> > 
> > Remove the instruction to call object_unparent(), and the exception
> > of the "do not call object_unparent()" rule for instance_finalize().
> > 
> > Signed-off-by: Akihiko Odaki 
> > ---
> >  docs/devel/memory.rst | 19 ++++++-------------
> >  1 file changed, 6 insertions(+), 13 deletions(-)
> > 
> > diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
> > index 57fb2aec76e0..749f11d8a4dd 100644
> > --- a/docs/devel/memory.rst
> > +++ b/docs/devel/memory.rst
> > @@ -161,18 +161,11 @@ or never.
> >  Destruction of a memory region happens automatically when the owner
> >  object dies.
> >  
> > -If however the memory region is part of a dynamically allocated data
> > -structure, you should call object_unparent() to destroy the memory region
> > -before the data structure is freed.  For an example see VFIOMSIXInfo
> > -and VFIOQuirk in hw/vfio/pci.c.
> 
> Should we still keep some of these examples?  After the series they'll be
> doing the right things.  Dynamic MRs are still slightly tricky, I think
> it's still good to have some references.
> 
> > -
> >  You must not destroy a memory region as long as it may be in use by a
> >  device or CPU.  In order to do this, as a general rule do not create or
> > -destroy memory regions dynamically during a device's lifetime, and only
> > -call object_unparent() in the memory region owner's instance_finalize
> > -callback.  The dynamically allocated data structure that contains the
> > -memory region then should obviously be freed in the instance_finalize
> > -callback as well.
> > +destroy memory regions dynamically during a device's lifetime.
> > +The dynamically allocated data structure that contains the
> > +memory region should be freed in the instance_finalize callback.
> >  
> >  If you break this rule, the following situation can happen:
> >  
> > @@ -198,9 +191,9 @@ this exception is rarely necessary, and therefore it is discouraged,
> >  but nevertheless it is used in a few places.
> >  
> >  For regions that "have no owner" (NULL is passed at creation time), the
> > -machine object is actually used as the owner.  Since instance_finalize is
> > -never called for the machine object, you must never call object_unparent
> > -on regions that have no owner, unless they are aliases or containers.
> > +machine object is actually used as the owner.  You must never call
> > +object_unparent on regions that have no owner, unless they are aliases
> > +or containers.
> 
> This looks like a completely separate change.  So we start to allow
> machines to be finalized now?  I'm not familiar with machine object
> lifecycles.  Maybe split it out even if it's true?

I didn't see anything elsewhere.  If you agree with above, I can queue this
series with above touched up, then no need to repost.

Thanks,

-- 
Peter Xu



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 20:16:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 20:16:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126621.1468123 (Exim 4.92)
	(envelope-from )
	id 1uzL3F-00055C-0D; Thu, 18 Sep 2025 20:16:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126621.1468123; Thu, 18 Sep 2025 20:16: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 1uzL3E-000555-TZ; Thu, 18 Sep 2025 20:16:20 +0000
Received: by outflank-mailman (input) for mailman id 1126621;
 Thu, 18 Sep 2025 20:16: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 1uzL3D-00054z-Vs
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 20:16:20 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 530c9be5-94cc-11f0-9809-7dc792cee155;
 Thu, 18 Sep 2025 22:16:13 +0200 (CEST)
Received: from localhost.localdomain (93-57-251-12.ip167.fastwebnet.it
 [93.57.251.12]) (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPSA id BD90C4EE8C90;
 Thu, 18 Sep 2025 22:16: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: 530c9be5-94cc-11f0-9809-7dc792cee155
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=93.57.251.12
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1758226573;
	b=gNkY2VaE/7oBZxEsIgxcjDha0yAGUgSuHrdhCk7l7/tEYBz9Y0XLftEVIChZXSWlsccV
	 XPr2irK0NdVchg4KrRejGtnbERvLXERzbS0foCB86G9gohzMyJcvIWMAWRrj7CSYDlctq
	 O8pOR6+8rnqKxLVK7jSU1oLC4NfNb+Ej7+mvyz5DoSXZyoTWKCz6P2e3YP5fX5jfiMgUg
	 I0BEjbEdJpQQh30khhOrJyCYytcn85Odh4l8Mn740QOT3k0l1STjgLj2B0tQMiZiUWwfC
	 UAC3SA85LYKVYK95X3QzaJs9lsXtugHE2GajL3Jh7iCjlZoxbd5kFHsJfrAmO5dF/Wnjn
	 TLDBsmm0TsbqrBeVRY54EqpB3/mQUXIBFdmvtpSFwWsgkrOJ+Zj+xq6JoXE/J/Lbkd7O+
	 LQVohEFutwwMeJbwjaWyscScguhg/ox4m7nNZGyR0IH7BCT9u/S0nQJmSsLc5Kj6chZlE
	 SYv6wG96UwnSgH2h/HnZj8tr2HB2b8pKWGwcfOv+G3AlRAvwsHKYdjEyG9cavXDXgWz/n
	 NXKrUT1vlYELCSAgdL2tPjClZmXDN9qcwtRv5rchedm0T8WJljjKcXBxuz1PA940xCRyH
	 ct17RGS/GXfsx8j6LmbpKj4Ue/clJzp70zURpHluiPU1iWtA7q4gNS6nhzxhwjA=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1758226573;
	h=DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer:
	 MIME-Version:Content-Transfer-Encoding;
	bh=qPTBLZ8UJbfLqGPM8eHSSCnZOzSzmEdxISP7KOJYQnI=;
	b=F86wEK5OXq3o/kvZ8NK5ogCZstzDRy0xuEjBe+neVQ5/QQmJdQl+WqoqBvtnyjHitJOL
	 B93/UCmFeUrMfWD6TTdN5TX3ecw/5/+r9W9PHXve92jEYzAV0HOzAr4W4wE9sHd7Fiotl
	 SytYkebyixWWXl4COKrzP3sQ9lhClWvr4+VTM0cXGYpWxWEj+HHndJQmv2VMWZpH2pjpJ
	 qIm+J8QtIiN0EjaJfNUAFVcnJd/0PzdK4ONmgj3KCHrvg8NCanw4bS6WryZBtnIlu7PC8
	 +I0o8BZ+31V/+iIVeSZGZbh2Jii6yOPkndhzDHFNaqHZhIV1T3BjBNmUiSL8QIjn6w3dE
	 9qds+Ul8yHjQziP94B8sFojDU4ejR64SVjjXI1e/foGOY/9CWMQ3EE28PRRrjsS3AQyV7
	 GTWrH+pmduA8lQf0E8tw9QYrB0eOdoj3hpkcNCM6UvcieywGTwdsnvWS7imgouiJo9e4P
	 jEM2wnDbnV3rdZkOVoW/3SWe/qTjXmZtK7m/IY3OitygFQD9td7aVHNlUuvuLTMF2TbeN
	 ocVbfZBZsibIOMoe4TPeUL7DAAu7y0w5fQ79YJUj8FctyBgTITA55FaMEWuqVMFpfTJN1
	 mYEVTk7XrLx7w8SiaarXnYxKmfqNcuK9inmTkcNwFwiqpUpvsghZGy0MPKJoo/I=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=93.57.251.12
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1758226573; bh=OuWNAloEC753OlhWTV9Q2rSFc2tQrl8vXxKS5qP4ONU=;
	h=From:To:Cc:Subject:Date:From;
	b=Bjr04aUGu7aW4qJYDw2N5wViVjX/HwoyYg8CvNgOYWnBzp05MARHC+zbirlKLYl3F
	 ZKtRzs9Nwfn4RkeA13Sg4yYCCBl1MTNMHTAEA4JeMmIj1umfV1d2uVJr2QNp/lZAxe
	 MmYd0t84piSg22Qfel6bdVD3lf+ljAkhWs7lF7Ua0JL0yAyMmbuUXZyiYfInLeNiN6
	 HUMi24AcUqUk+q956CtyKfJXZom/BVxoZEM0DgOoxNVLGumJrhohTu0bYUbALNRn9z
	 rI+gkuuYUCb3rNk4+dHLzoQ1cqHv4Kyn+2+Ju2rQMBPGGXIR7G41TCdJfvQqYCQ4uo
	 QlWwwhAVYLHvA==
From: Nicola Vetrini 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	consulting@bugseng.com,
	Nicola Vetrini ,
	Doug Goldstein 
Subject: [XEN PATCH] automation/eclair: add new analysis jobs with differing configurations
Date: Thu, 18 Sep 2025 22:16:08 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The following analysis jobs are performed:
- eclair-{x86_64,ARM64}: analyze Xen using the default configuration for
  that architecture; runs on runners tagged `eclair-analysis'.

- eclair-{x86-64,ARM64}-safety: analyze Xen using the configuration for
  safety, which is more restricted; runs on runners tagged
  `eclair-analysis-safety`.

- eclair-{x86_64,ARM64}-testing: analyze Xen using the default
  configuration for the purposes of testing new runner updates; runs on
  runners tagged `eclair-analysis-testing`.

Signed-off-by: Nicola Vetrini 
---
Naturally the right tags to the runners should be set beforehand for
this to work as intended:

xen-eclair-runner -> eclair-analysis-testing 
xen-eclair-runner2 -> eclair-analysis, eclair-analysis-safety
TBD -> eclair-analysis-safety

The last runner is not set up yet, but due to the redundancy can be
brought up anytime.
---
 automation/gitlab-ci/analyze.yaml | 38 +++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
index d50721006740..a4cca00fd100 100644
--- a/automation/gitlab-ci/analyze.yaml
+++ b/automation/gitlab-ci/analyze.yaml
@@ -45,6 +45,21 @@ eclair-x86_64:
     LOGFILE: "eclair-x86_64.log"
     VARIANT: "X86_64"
     RULESET: "monitored"
+
+eclair-x86_64-testing:
+  extends: eclair-x86_64
+  tags:
+    - eclair-analysis-testing
+  rules:
+    - if: $CI_PROJECT_PATH =~ /^xen-project\/people\/bugseng.*$/
+      when: always
+    - !reference [.eclair-analysis:triggered, rules]
+
+eclair-x86_64-safety:
+  extends: eclair-x86_64
+  tags:
+    - eclair-analysis-safety
+  variables:
     EXTRA_XEN_CONFIG: |
       CONFIG_AMD=y
       CONFIG_INTEL=n
@@ -75,6 +90,10 @@ eclair-x86_64:
       CONFIG_DEBUG_LOCKS=n
       CONFIG_SCRUB_DEBUG=n
       CONFIG_XMEM_POOL_POISON=n
+  rules:
+    - if: $CI_PROJECT_PATH =~ /^xen-project\/hardware\/xen$/ && /$CI_COMMIT_BRANCH =~ /^staging$/
+      when: always
+    - !reference [.eclair-analysis:triggered, rules]
 
 eclair-ARM64:
   extends: .eclair-analysis:triggered
@@ -82,6 +101,21 @@ eclair-ARM64:
     LOGFILE: "eclair-ARM64.log"
     VARIANT: "ARM64"
     RULESET: "monitored"
+
+eclair-ARM64-testing:
+  extends: eclair-ARM64
+  tags:
+    - eclair-analysis-testing
+  rules:
+    - if: $CI_PROJECT_PATH =~ /^xen-project\/people\/bugseng.*$/
+      when: always
+    - !reference [.eclair-analysis:triggered, rules]
+
+eclair-ARM64-safety:
+  extends: eclair-ARM64
+  tags:
+    - eclair-analysis-safety
+  variables:
     EXTRA_XEN_CONFIG: |
       CONFIG_NR_CPUS=16
       CONFIG_GICV2=n
@@ -120,6 +154,10 @@ eclair-ARM64:
       CONFIG_DEBUG_LOCKS=n
       CONFIG_SCRUB_DEBUG=n
       CONFIG_XMEM_POOL_POISON=n
+  rules:
+    - if: $CI_PROJECT_PATH =~ /^xen-project\/hardware\/xen$/ && /$CI_COMMIT_BRANCH =~ /^staging$/
+      when: always
+    - !reference [.eclair-analysis, rules]
 
 .eclair-analysis:on-schedule:
   extends: .eclair-analysis
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Sep 18 20:21:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Sep 2025 20:21:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126634.1468133 (Exim 4.92)
	(envelope-from )
	id 1uzL7f-0006bC-HC; Thu, 18 Sep 2025 20:20:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126634.1468133; Thu, 18 Sep 2025 20:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzL7f-0006b5-Db; Thu, 18 Sep 2025 20:20:55 +0000
Received: by outflank-mailman (input) for mailman id 1126634;
 Thu, 18 Sep 2025 20:20: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 1uzL7e-0006az-8J
 for xen-devel@lists.xenproject.org; Thu, 18 Sep 2025 20:20:54 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f96efdab-94cc-11f0-9d14-b5c5bf9af7f9;
 Thu, 18 Sep 2025 22:20: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 880164EEBC46;
 Thu, 18 Sep 2025 22:20: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: f96efdab-94cc-11f0-9d14-b5c5bf9af7f9
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=1758226852;
	b=vjpKQbaf3xGJ4eYygWmgWWIY3Cfj5ZUQ31+14WyvhLcIrFWZ1GtT3kOHoPUOUoEyKMuy
	 lFtji/ofr2hQhgEf5bgDYPgS7o+9adaxXUH25BomOQZ1HqDFNfnSe89Jx0D/535OQW0yO
	 OQa/7RkOSDG0crVzIgdRuJ007nvmn7v2fmBTZwscf8k5fzDuB4p+BCtWaraaUWK/5VDs2
	 Yk+45qB/apW6FgYEFo+TwKIzVUkFSfnAXo8y/mwayBKs+0lbmfWEtz0SNIdh8TC3nE2xE
	 S6uS/WV7iHknGUxqe5D4A4lbVTlu0YzjjvGrFlduX2V9ZqJ5MQlMypYFFTgVqDpqDZnw6
	 6dwkj2f+HYl3jlKS1IRF99luQWhvI0mwsDHxoOPMytkuqf6CUnGzAMJWNnh6vj/ibHcIK
	 KeigVrG7UefiHk0XIRC9Q2na6+/zYRuCvsHQQbTrv0xFr4Gwr87wJOzYVb2MySgKHHsRD
	 0ZsYj+6Kiehif94A2NUWKCgzEf6Pk0CsF45e8g6nvrhKhF3EzqjUxM9cxO1HzdxGH3lg2
	 KgGRlI16P3P8mngGOQLMqGQsNN1tadFVJDhLIp00xNbXPxr+s31OeZj2ukD3PoKSwg9P2
	 HLBbAMIx6XSZRqudG9mAn8PTmxA+GCHZkkhGs8qL/w0RZ6yHlpDvKa1d+wJGyCk=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1758226852;
	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=24zUaynGRgP2C6h9wNbYiP2S+tmjDNyTWTI96tpvjXI=;
	b=vc32Y/QN9mnFkyoFXJE70fiL8rQ/MzBGu/7T61F8nZ8/EvUFN6AglBWirmRzShrxOPEZ
	 GLOJbF71vUZYvvpZLV0wbf0ZLf+3l6IXYyo+AaIGAjCMNuExx9KfV9YJNLwVn5hqY2OI5
	 t4EygkJbZEc7Z9chw7sI90s48QWbWxbhBY1CxOx1KmQSnU8hM2Acr1G76InsspnLXUVht
	 QIs5XvlHCm413BbOiTL6UEORBC1JtO7LkmOOF9S9q+bIpqzm5rz+yTRCOHIGbQOIUKjtQ
	 1jIgA97ZMGMNf4BgtNMcmzv7ae8bcVS93z1/2OJ/FqVt6uoFuQnCZ75I05qFq+pt/rqcR
	 f8RoDmIlWth17/Px5LrWBBf5Wnq+1xWvFzV9vrKBAuJ+BMR/DJC/lHRtg7wHqMNmSJpjH
	 feevp1xPjIrTILZenKYnFJgTDNm1xFk+jN/EVymBjp0PaqoP4NqpVy436JaOwIczo4f6a
	 voi0Eu1P0J9thJsibju/twA+e26BzvF5CgJc3VSczQTSAfs9s/CQGbKSRo03uLPwvxEe7
	 hwGleR4Fb8yfqagKFkdtejoGfCAXbBqu2wrafs3klJJbwaKSOe3CeeCC2z+xefIvRuZeL
	 SMe8IN9q8EDTpyAeflEuIGXGUZFVPDr8c0Hr6hrhH3STCdv5pAx94n2Stm8Lk8o=
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=1758226852; bh=6iIra69cuzKV3VJWr1RJqp2ftMdT2ygbviSgAOwwgEI=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=NrNpXRuHSVbhi7tVk3H2UX+FPADPefL+Lyc0SamHPBMqNS70m8ElQOMPujffbLg4C
	 sAC9ce9QZuGoYeoN9Fk+aTIOoHO84LzU+OmoYrwonMllK6POsPabrnOJuZxhjWBq3H
	 jLKUCwZvfRq2AV/wX+kt9EgaqKmCoyDlrbbP0Yc6K9KtE3n9DfOrlIlLJKjRvG0DlF
	 zWpQ0hKxt9GElbRHho05xaDrG83loJ8I8X+JgPFM7vEp67zTGsK8KeQwblPaJa+wCA
	 YNMGDSp2GZfceKTuVyPaF5FVDo8aPQVxnDl3pULSIoLEtvHNmKUWviQC+lI9Jen25Q
	 0X9rC5VESMwwA==
MIME-Version: 1.0
Date: Thu, 18 Sep 2025 22:20:52 +0200
From: Nicola Vetrini 
To: victorm.lira@amd.com
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3r?=
 =?UTF-8?Q?ecki?= , Anthony PERARD
 , Doug Goldstein , Stefano
 Stabellini 
Subject: Re: [PATCH v1] automation: edit pipeline to prevent running
 non-selected jobs
In-Reply-To: <1437334569e10b76d1d7dc4e9fca7c25606855fb.1756862843.git.victorm.lira@amd.com>
References: <1437334569e10b76d1d7dc4e9fca7c25606855fb.1756862843.git.victorm.lira@amd.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-09-03 03:49, victorm.lira@amd.com wrote:
> From: Victor Lira 
> 
> Filtering jobs using the selected jobs regex is missing for
> qemu-export/yocto- jobs when running regular pipelines and eclair jobs
> when running scheduled pipelines.
> 
> Add the missing rules to filter out those jobs, and set a default value
> for the selected jobs regex to remove the need to always check if the
> variable is empty.
> 
> Signed-off-by: Victor Lira 

Reviewed-by: Nicola Vetrini  # ECLAIR

If this goes in before [1] (which is likely), then I should rebase 
because it will probably conflict

[1] 
https://lore.kernel.org/xen-devel/d4a0924c84e78b3f677b0d987c2f8e4b3f6b80a5.1758226234.git.nicola.vetrini@bugseng.com/T/#u

> ---
> example of the problem:
>   - 
> https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/2018353899
>   - SELECTED_JOBS_ONLY=/alpine-3.18-gcc$/ should produce 1 job only
> note:
>   - I tested only on sstabellini but the logic should work for 
> hardware/staging
>     too
> ---
> Cc: Marek Marczykowski-Górecki 
> Cc: Nicola Vetrini 
> Cc: Anthony PERARD 
> Cc: Doug Goldstein 
> Cc: Stefano Stabellini 
> Cc: xen-devel@lists.xenproject.org
> ---
>  .gitlab-ci.yml                    | 1 +
>  automation/gitlab-ci/analyze.yaml | 5 +++--
>  automation/gitlab-ci/build.yaml   | 9 ++++++---
>  3 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 7974ac4e82..64bed300a6 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -2,6 +2,7 @@ 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/"
> +    value: "/.*/"
> 
>  workflow:
>    name: "$CI_PIPELINE_SCHEDULE_DESCRIPTION"
> diff --git a/automation/gitlab-ci/analyze.yaml 
> b/automation/gitlab-ci/analyze.yaml
> index d507210067..1f58e13cb2 100644
> --- a/automation/gitlab-ci/analyze.yaml
> +++ b/automation/gitlab-ci/analyze.yaml
> @@ -31,8 +31,7 @@
>    rules:
>      - if: $CI_PIPELINE_SOURCE == "schedule"
>        when: never
> -    - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
> -    - if: $SELECTED_JOBS_ONLY
> +    - if: $CI_JOB_NAME !~ $SELECTED_JOBS_ONLY
>        when: never
>      - if: $WTOKEN && $CI_PROJECT_PATH =~ /^xen-project\/people\/.*$/
>        when: manual
> @@ -126,6 +125,8 @@ eclair-ARM64:
>    rules:
>      - if: $CI_PIPELINE_SOURCE != "schedule"
>        when: never
> +    - if: $CI_JOB_NAME !~ $SELECTED_JOBS_ONLY
> +      when: never
>      - !reference [.eclair-analysis, rules]
> 
>  eclair-x86_64:on-schedule:
> diff --git a/automation/gitlab-ci/build.yaml 
> b/automation/gitlab-ci/build.yaml
> index ab5211f77e..b2f96c1fe0 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -226,6 +226,9 @@
>        - binaries/
>      when: always
>    needs: []
> +  rules:
> +    - if: $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
> +      when: manual
> 
>  .yocto-test-arm64:
>    extends: .yocto-test
> @@ -261,6 +264,9 @@
>  .test-jobs-artifact-common:
>    stage: build
>    needs: []
> +  rules:
> +    - if: $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
> +      when: on_success
> 
>  # Arm test artifacts
> 
> @@ -468,20 +474,17 @@ yocto-qemuarm64:
>    extends: .yocto-test-arm64
>    variables:
>      YOCTO_BOARD: qemuarm64
> -  when: manual
> 
>  yocto-qemuarm:
>    extends: .yocto-test-arm64
>    variables:
>      YOCTO_BOARD: qemuarm
>      YOCTO_OUTPUT: --copy-output
> -  when: manual
> 
>  yocto-qemux86-64:
>    extends: .yocto-test-x86-64
>    variables:
>      YOCTO_BOARD: qemux86-64
> -  when: manual
> 
>  # Cppcheck analysis jobs
> 
> --
> 2.50.GIT

-- 
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 Sep 19 10:51:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 10:51:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126817.1468143 (Exim 4.92)
	(envelope-from )
	id 1uzYi4-0000A9-84; Fri, 19 Sep 2025 10:51:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126817.1468143; Fri, 19 Sep 2025 10:51: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 1uzYi4-00009j-2S; Fri, 19 Sep 2025 10:51:24 +0000
Received: by outflank-mailman (input) for mailman id 1126817;
 Fri, 19 Sep 2025 10:51:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uzYi1-00009Y-1f
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 10:51:22 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91dafea5-9546-11f0-9d14-b5c5bf9af7f9;
 Fri, 19 Sep 2025 12:51:19 +0200 (CEST)
Received: from [133.11.54.205] (h205.csg.ci.i.u-tokyo.ac.jp [133.11.54.205])
 (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58JAnSkG034536
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Fri, 19 Sep 2025 19:49:28 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 91dafea5-9546-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=MP/aWQfL5AeteLs3iYOvs5XOjlgtCOWSBWzrwpTeLHA=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=Message-ID:Date:Subject:To:From;
        s=rs20250326; t=1758278969; v=1;
        b=S5fu8gfxZZiPnzD5VRHNv/uTY6iJWyIUwLazMNVUmCBeynHTUOA2iEgcOHc6KflY
         emqbX/bQhivXM0ZJTrM3Kdix317VEnNTLuR55r4BD6CCS2KsNV+u6uR2Gu2MeHSQ
         lBZ4MUkNXjzKLJFzzUPNWcYrBs4hFzvr5zRMtUKMo/3Etb6/jheULNi1cf88hRVF
         09KetWzajL11CS43aTEF5Ibb+gEZWvRrpGktxAm4fHCDTmcDcDa8Ov/Q3dITg4E+
         n588HfUKfhFonV0Thdy6AMTm3LydrhGYm0/d08ebrVqGb/oTCwq/Tj1NiNFxZ9K/
         VBUOfiYyB4m/Du6sv1fF7Q==
Message-ID: <10834681-260f-4727-9687-77b3eef085bb@rsg.ci.i.u-tokyo.ac.jp>
Date: Fri, 19 Sep 2025 19:49:27 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
To: Peter Xu , BALATON Zoltan 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
        =?UTF-8?Q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 ,
        Eduardo Habkost ,
        David Hildenbrand ,
        =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?=
 ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?UTF-8?Q?Alex_Benn=C3=A9e?=
 ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo
 ,
        Max Filippov ,
        =?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
  
  
Content-Language: en-US
From: Akihiko Odaki 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2025/09/19 3:23, Peter Xu wrote:
> On Thu, Sep 18, 2025 at 12:20:49PM -0400, Peter Xu wrote:
>> On Thu, Sep 18, 2025 at 05:29:34PM +0200, BALATON Zoltan wrote:
>>> On Thu, 18 Sep 2025, Peter Xu wrote:
>>>> On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
>>>>> Based-on: 
>>>>> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
>>>>
>>>> Could I ask why this is a dependency?
>>>
>>> It removes an address_space usage from raven so this series does not have to
>>> change that and I don't have to rebase that series. Otherwise these are not
>>> related. I'll check the problem reported about my series and send an updated
>>> one.
>>
>> This series should be a split of a previous mixed up series that may
>> contain address space changes while this one doesn't.  It also doesn't
>> touch raven.c and ppc/.
>>
>> Can I then understand it as the dependency is simply not needed?
> 
> I meant, it seems we don't need to wait for the other series to merge this
> one, hence the there is no real dependency.

You are right. This series can be merged without the raven clean ups.

Regards,
Akihiko Odaki


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 10:53:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 10:53:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126833.1468153 (Exim 4.92)
	(envelope-from )
	id 1uzYk2-0000hz-G0; Fri, 19 Sep 2025 10:53:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126833.1468153; Fri, 19 Sep 2025 10:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzYk2-0000hs-D7; Fri, 19 Sep 2025 10:53:26 +0000
Received: by outflank-mailman (input) for mailman id 1126833;
 Fri, 19 Sep 2025 10:53: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 1uzYk1-0000hQ-0N
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 10:53:25 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db5ad10c-9546-11f0-9809-7dc792cee155;
 Fri, 19 Sep 2025 12:53:22 +0200 (CEST)
Received: from [133.11.54.205] (h205.csg.ci.i.u-tokyo.ac.jp [133.11.54.205])
 (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58JAkcQT033756
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Fri, 19 Sep 2025 19:46:38 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db5ad10c-9546-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=rWCFvrSz0E2oCjuTU959aed1+QCvq+UCU8sf+vOrvRg=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=Message-ID:Date:Subject:To:From;
        s=rs20250326; t=1758278798; v=1;
        b=CJhWqRXMK7EVEqt5O4fzgwRHkpbvNlCZaOFGT2JRrokvtE+QlXyrJW49lss+htTp
         KFQ9E4TwLqRPpCtI4tDvZhlu5p+VEeAg5rZ5h32ZHa35LPKVJVUy9pwNtE/60NSZ
         qq56vOq+zd3BaQf/Jvtr0LJAzESnC/31asffQw6Px03Q2E14OlyKOsrSBsT9SdS/
         sf6iBD4VFClJOHPImJDN5/M2qkalIoEDAePrmpoDFSsBz1S0IDQSBvgwEmvShJG+
         6hbf/Npf5//RO3LzPxRwYamdTAldhiXOb0FjhvPd7Yg15U62VVBLFDiaTcrYKflb
         uoErgJ/vf6oO0EVI+zRkug==
Message-ID: <7511a948-10ef-4325-9818-35775c522aee@rsg.ci.i.u-tokyo.ac.jp>
Date: Fri, 19 Sep 2025 19:46:38 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/7] docs/devel: Do not unparent in instance_finalize()
To: Peter Xu 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
        =?UTF-8?Q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 ,
        Eduardo Habkost ,
        David Hildenbrand ,
        =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?=
 ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?UTF-8?Q?Alex_Benn=C3=A9e?=
 ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo
 ,
        Max Filippov ,
        =?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org
References: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
 <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
  
Content-Language: en-US
From: Akihiko Odaki 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2025/09/19 5:11, Peter Xu wrote:
> On Thu, Sep 18, 2025 at 04:03:49PM -0400, Peter Xu wrote:
>> On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
>>> Children are automatically unparented so manually unparenting is
>>> unnecessary.
>>>
>>> Worse, automatic unparenting happens before the instance_finalize()
>>> callback of the parent gets called, so object_unparent() calls in
>>> the callback will refer to objects that are already unparented, which
>>> is semantically incorrect.
>>>
>>> Remove the instruction to call object_unparent(), and the exception
>>> of the "do not call object_unparent()" rule for instance_finalize().
>>>
>>> Signed-off-by: Akihiko Odaki 
>>> ---
>>>   docs/devel/memory.rst | 19 ++++++-------------
>>>   1 file changed, 6 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
>>> index 57fb2aec76e0..749f11d8a4dd 100644
>>> --- a/docs/devel/memory.rst
>>> +++ b/docs/devel/memory.rst
>>> @@ -161,18 +161,11 @@ or never.
>>>   Destruction of a memory region happens automatically when the owner
>>>   object dies.
>>>   
>>> -If however the memory region is part of a dynamically allocated data
>>> -structure, you should call object_unparent() to destroy the memory region
>>> -before the data structure is freed.  For an example see VFIOMSIXInfo
>>> -and VFIOQuirk in hw/vfio/pci.c.
>>
>> Should we still keep some of these examples?  After the series they'll be
>> doing the right things.  Dynamic MRs are still slightly tricky, I think
>> it's still good to have some references.

I agree. I'll restore it with the next version.

>>
>>> -
>>>   You must not destroy a memory region as long as it may be in use by a
>>>   device or CPU.  In order to do this, as a general rule do not create or
>>> -destroy memory regions dynamically during a device's lifetime, and only
>>> -call object_unparent() in the memory region owner's instance_finalize
>>> -callback.  The dynamically allocated data structure that contains the
>>> -memory region then should obviously be freed in the instance_finalize
>>> -callback as well.
>>> +destroy memory regions dynamically during a device's lifetime.
>>> +The dynamically allocated data structure that contains the
>>> +memory region should be freed in the instance_finalize callback.
>>>   
>>>   If you break this rule, the following situation can happen:
>>>   
>>> @@ -198,9 +191,9 @@ this exception is rarely necessary, and therefore it is discouraged,
>>>   but nevertheless it is used in a few places.
>>>   
>>>   For regions that "have no owner" (NULL is passed at creation time), the
>>> -machine object is actually used as the owner.  Since instance_finalize is
>>> -never called for the machine object, you must never call object_unparent
>>> -on regions that have no owner, unless they are aliases or containers.
>>> +machine object is actually used as the owner.  You must never call
>>> +object_unparent on regions that have no owner, unless they are aliases
>>> +or containers.
>>
>> This looks like a completely separate change.  So we start to allow
>> machines to be finalized now?  I'm not familiar with machine object
>> lifecycles.  Maybe split it out even if it's true?

I intended to remove phrase "since instance_finalize is never called for 
the machine object" because whether instance_finalize is called or not 
is no longer relevant, and thus object_unparent is always prohibited, 
whether regions have owners or not, unless they are aliases or containers.

The statement still mentions "regions that have no owner"; the 
restriction of object_unparent is enforced whether the regions have 
owners, so it is a bit misleading.

> 
> I didn't see anything elsewhere.  If you agree with above, I can queue this
> series with above touched up, then no need to repost.

I guess I will rewrite this patch, restoring the VFIOQuirk example, and 
re-check if this whole section is structured logically and consistently.

Regards,
Akihiko Odaki


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 15:29:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 15:29:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126910.1468163 (Exim 4.92)
	(envelope-from )
	id 1uzd3I-0006DP-Ij; Fri, 19 Sep 2025 15:29:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126910.1468163; Fri, 19 Sep 2025 15:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzd3I-0006DE-E5; Fri, 19 Sep 2025 15:29:36 +0000
Received: by outflank-mailman (input) for mailman id 1126910;
 Fri, 19 Sep 2025 15:29:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzd3H-0006D6-6D
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 15:29:35 +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 7175e53c-956d-11f0-9d14-b5c5bf9af7f9;
 Fri, 19 Sep 2025 17:29:33 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3df15fdf0caso2014043f8f.0
 for ; Fri, 19 Sep 2025 08:29:33 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2698033cd5csm56570205ad.136.2025.09.19.08.29.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 08:29: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: 7175e53c-956d-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758295773; x=1758900573; 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=HmOvKQ2Lgm8QOTcAN98WW76aXj91TXMiVdioKx/66XI=;
        b=X/RaMiXgkMi64Hu7jfjs6u5GDtVu/t9J21cz739dNUs863s7GYznBQrGfWqPx9Na+n
         MbcRNT7ljZNloOHxsPqs4ptycdzAEWF7/U60ImDsd3kmSDx1ShyebcEWNBQibbLZdsPv
         lTjrWVPOcYmndr4xkR2wVjN2Fuuc74s6xKn6QjiTg3OKLLh++i/PLPfplSLmz3uWr+VN
         QFY35ZOQtyyJ9BVpqoTQx5ydMcXN7DtmlY4tK0N4h4e7S4oCRjI6F/CHb5Q+2ZLIfjFe
         zAaZlAm75hmgfqLxOzJQwvbQIXURScn1lOaxMxV1SqcuHk/yqheZdHHdRpO+qDeVbETw
         XVxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758295773; x=1758900573;
        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=HmOvKQ2Lgm8QOTcAN98WW76aXj91TXMiVdioKx/66XI=;
        b=f5ItOb5JceblNn5EkwMN+ZJp259IhGiy4xwXB4RsVui/a07p8+FanYjoBMqkKlUaLB
         Eujvhy6MuY5G73jXWwc/6NwuVk7hCiVVfFoj/DVFa0He/L0qD3+Z9reTzE+JdBV4bt8c
         t1ncunPX5DuoZuZm98qe/GnbjecAX5WkbgfUHT1owslQjtkv3+j54DKaarutIjb5YP+x
         Wx3cYuSKfYjuWw0YIq0pANbmx6I7e4IdM6AM/L6iC0ZpPRZMTd42mCKR84Tu9p74/0cr
         v/3+bY61TO/DY08Mai1GPEUX/5BYsZ2YiiJlycvW2ER2t1hy1/FA3dfV2MAtKamXMeBM
         N4Yw==
X-Forwarded-Encrypted: i=1; AJvYcCXiKxU9Am6EVBn3WjRmBAPRX+TB61FqmhzsV16k4wYbNEEdsq2rzJXntBhMKRtN80nvMge+qF2KDCg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOV7o0M+aIK3eDPc2whmYDJ/BDqxB1lfwCADxV49ocZrW5jd7C
	xU8B9pGuoIcYtygf637KmpMA/Y62uUqaBUt99CjG9tJnN1aE/5CCD5mAu71frrPW7w==
X-Gm-Gg: ASbGncuIgUCZ/M/rdxkRVj6JUuX6B4nYdXwriQOeQbkeuudK5W17A2coGXgKw4cJe0G
	FHGxjIowwWqt64k4k6nY858v2XegywKHgYKvOWnylbORGpyzOBlqH3Uuicpkf2VewE8V8Fu1WSd
	s3OeHf9fhW+VaDE+kCt+fil+4QJkTbWWqN0YA4UY9Aawx5OzXvw92vNdPNJZudzApfPIqbgG4Oh
	f3twPmExpLk4slB3il3veDv9GrvhyjPMfRl74RUO9QpZbAhrvneYly4zJv4oNdqExhqVbXy7a0F
	Qs6i8/F1PRUNvPohSP8m62Ff/uOLqQ8GGBIRcnQkxoFE7Jj9OkWJp6vH+Ioo7CppKt46Z7vRsod
	Mpq2mpmocKsqP6j5/MfeFafyalzWqMOXFU/2lPv9v+nY=
X-Google-Smtp-Source: AGHT+IFVnEGwW60BREuwFEUl79/9sCKVWRvigl2eoFNG3bcqsQGBWBIGZzGWJAdXSFYVwExfhyDQqg==
X-Received: by 2002:a05:6000:1789:b0:3ec:df2b:14c8 with SMTP id ffacd0b85a97d-3ee7d0c8b68mr3236855f8f.20.1758295773092;
        Fri, 19 Sep 2025 08:29:33 -0700 (PDT)
Message-ID: <146fc872-2ba5-4dc5-9e0f-2d10e2836a2e@suse.com>
Date: Fri, 19 Sep 2025 17:29:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: Grygorii Strashko 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
 <0e1a6339-a4fb-4697-acfa-392168b391d4@suse.com>
 <2d6e5cc6-15c1-40ce-8742-1b77b32203a9@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <2d6e5cc6-15c1-40ce-8742-1b77b32203a9@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.09.2025 19:17, Grygorii Strashko wrote:
> On 18.09.25 18:41, Jan Beulich wrote:
>> On 16.09.2025 15:41, Grygorii Strashko wrote:
>>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>>> @@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
>>>   {
>>>       const struct domain *d = v->domain;
>>>       const struct viridian_domain *vd = d->arch.hvm.viridian;
>>> -    struct hvm_viridian_domain_context ctxt = {
>>> -        .hypercall_gpa = vd->hypercall_gpa.raw,
>>> -        .guest_os_id = vd->guest_os_id.raw,
>>> -    };
>>> +    struct hvm_viridian_domain_context ctxt = {};
>>>   
>>>       if ( !is_viridian_domain(d) )
>>>           return 0;
>>
>> This check doesn't check for vd being non-NULL, so this still feels a little
>> fragile, even if it looks correct now.
> 
> Hm. May be I missing smth., but
> - if is_viridian_domain(d) and viridian_domain_init() succeeded
>    then d->arch.hvm.viridian != NULL, like always
>    (otherwise domain will not be created)
> 
> - if !is_viridian_domain() then code will not go further
> 
> so I'm missing to see how !d->arch.hvm.viridian (!vd) can happen here.

Well, as said - it feels a _little_ fragile, as it's not the NULL-ness of
the pointer that is checked.

>>> +    ctxt.hypercall_gpa = vd->hypercall_gpa.raw;
>>> +    ctxt.guest_os_id = vd->guest_os_id.raw,
>>> +
>>>       viridian_time_save_domain_ctxt(d, &ctxt);
>>>       viridian_synic_save_domain_ctxt(d, &ctxt);
>>>   
>>
>> Just below here we have viridian_load_domain_ctxt(), which I'm pretty sure
>> now also needs to gain some check: Save records coming from user space, we
>> can't really rely on there being none of this type for a non-Viridian domain.
> 
> As per my understanding:
> viridian_load_domain_ctxt() calls hvm_load_entry_zeroextend() which
> should not succeed if context was not saved (which shouldn't happen for
> !is_viridian_domain(d) case).

I don't understand what you mean with "was not saved". To be free of security
issues, we need to cope with any (bogus or not) record appearing.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 16:08:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 16:08:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126935.1468172 (Exim 4.92)
	(envelope-from )
	id 1uzdf0-0003Ho-8b; Fri, 19 Sep 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 1126935.1468172; Fri, 19 Sep 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 1uzdf0-0003Hh-5d; Fri, 19 Sep 2025 16:08:34 +0000
Received: by outflank-mailman (input) for mailman id 1126935;
 Fri, 19 Sep 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 1uzdez-0003Hb-7b
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 16:08:33 +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 dff06662-9572-11f0-9809-7dc792cee155;
 Fri, 19 Sep 2025 18:08:27 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 581BF60140;
 Fri, 19 Sep 2025 16:08:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76C8EC4CEF0;
 Fri, 19 Sep 2025 16:08: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: dff06662-9572-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758298105;
	bh=KR7+2nE82F6C0RiPmuqmiCYxfBNwhzjUQ6Re6K7PmkQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=gxcwNWOdwyYYCt/Mr4IoNw/QjfiG4fCy9ykIixLtIZgzxpvEaTh0ZrsRzbEkVlnG2
	 m8b1wOyRgj64SHlplGanM4IqWdr6Ywznq35IYlrDTPSiuH1HbSJA9OSV6F3cLQ0fmv
	 gIfqZUpL6QTaZY7lchfgfbbV/HzPQ9GlWuIYB09YAq8LPsugW8lRkDPp3pD3pmqfjH
	 MMDTa/BarqpIPeeM6zxgfbm5MTp42dkz6/ahu8QcAFUE+eO/S+U7a/1bN3BopMvk86
	 +JRB492i+MxOTtI0yVlp8MJ781GY30PjuvtN+/6jEMPcnyQy8X2xhocLeJS5gf/FQl
	 TeUW9JwC+yaOg==
Date: Fri, 19 Sep 2025 10:08:21 -0600
From: Keith Busch 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: 
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250912090327.GU341237@unreal>

On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote:
> On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote:
> > >
> > > This series does the core code and modern flows. A followup series
> > > will give the same treatment to the legacy dma_ops implementation.
> > 
> > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it 
> > works fine in linux-next.
> 
> Thanks a lot.

Just fyi, when dma debug is enabled, we're seeing this new warning
below. I have not had a chance to look into it yet, so I'm just
reporting the observation.

 DMA-API: nvme 0006:01:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported
 WARNING: kernel/dma/debug.c:598 at add_dma_entry+0x26c/0x328, CPU#1: (udev-worker)/773
 Modules linked in: acpi_power_meter(E) loop(E) efivarfs(E) autofs4(E)
 CPU: 1 UID: 0 PID: 773 Comm: (udev-worker) Tainted: G            E    N  6.17.0-rc6-next-20250918-debug #6 PREEMPT(none)
 Tainted: [E]=UNSIGNED_MODULE, [N]=TEST
 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
 pc : add_dma_entry+0x26c/0x328
 lr : add_dma_entry+0x26c/0x328
 sp : ffff80009fe0f460
 x29: ffff80009fe0f470 x28: 0000000000000001 x27: 0000000000000001
 x26: ffff8000835d7f38 x25: ffff8000835d7000 x24: ffff8000835d7e60
 x23: 0000000000000000 x22: 0000000006e2cc00 x21: 0000000000000000
 x20: ffff800082e8f218 x19: ffff0000a908ff80 x18: 00000000ffffffff
 x17: ffff8000801972a0 x16: ffff800080197054 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000004 x12: 0000000000020006
 x11: 0000000030e4ef9f x10: ffff800083443358 x9 : ffff80008019499c
 x8 : 00000000fffeffff x7 : ffff800083443358 x6 : 0000000000000000
 x5 : 00000000000bfff4 x4 : 0000000000000000 x3 : ffff0000bb005ac0
 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000bb005ac0
 Call trace:
  add_dma_entry+0x26c/0x328 (P)
  debug_dma_map_phys+0xc4/0xf0
  dma_map_phys+0xe0/0x410
  dma_map_page_attrs+0x94/0xf8
  blk_dma_map_direct.isra.0+0x64/0xb8
  blk_rq_dma_map_iter_next+0x6c/0xc8
  nvme_prep_rq+0x894/0xa98
  nvme_queue_rqs+0xb0/0x1a0
  blk_mq_dispatch_queue_requests+0x268/0x3b8
  blk_mq_flush_plug_list+0x90/0x188
  __blk_flush_plug+0x104/0x170
  blk_finish_plug+0x38/0x50
  read_pages+0x1a4/0x3b8
  page_cache_ra_unbounded+0x1a0/0x400
  force_page_cache_ra+0xa8/0xd8
  page_cache_sync_ra+0xa0/0x3f8
  filemap_get_pages+0x104/0x950
  filemap_read+0xf4/0x498
  blkdev_read_iter+0x88/0x180
  vfs_read+0x214/0x310
  ksys_read+0x70/0x110
  __arm64_sys_read+0x20/0x30
  invoke_syscall+0x4c/0x118
  el0_svc_common.constprop.0+0xc4/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x1a0/0x340
  el0t_64_sync_handler+0x98/0xe0
  el0t_64_sync+0x17c/0x180
 ---[ end trace 0000000000000000 ]---



From xen-devel-bounces@lists.xenproject.org Fri Sep 19 16:32:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 16:32:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126948.1468183 (Exim 4.92)
	(envelope-from )
	id 1uze1X-00075b-1s; Fri, 19 Sep 2025 16:31:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126948.1468183; Fri, 19 Sep 2025 16: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 1uze1W-00075U-Ui; Fri, 19 Sep 2025 16:31:50 +0000
Received: by outflank-mailman (input) for mailman id 1126948;
 Fri, 19 Sep 2025 16:31: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 1uze1V-00075O-6R
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 16:31:49 +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 20703462-9576-11f0-9809-7dc792cee155;
 Fri, 19 Sep 2025 18:31:43 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB8865.eurprd03.prod.outlook.com (2603:10a6:20b:554::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Fri, 19 Sep
 2025 16:31:40 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9137.015; Fri, 19 Sep 2025
 16:31: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: 20703462-9576-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XC6bGJrSE74BjFlg3BT5H4r3Y9uD22HQTufKs0l0u/9ggG2M4ePw9cWl7BE0T+zSNu1pcyIlH+KluFVS8HF8GOz7JAqVxdbdDL005Li5W+xVt5s+Q6AMXbIYYVnUt//0TGB9KbV/vdz/ZjRPF6MN13zIflZnP7QApOMaK8QbExUu4xyig1pV1PSJcnAumZo7OPoYO3HHzx9x7Tpx8jPwaP4lNx5yrGQH+CqQu2gm6KaJqkFT9N8gsrdUNlwXOXdqQGjJ1T+OXHAoF0qEIyQbKA8W7H1YUFnZWpzakThRwZLAPpJdsIMSe80QB2LDlMPSb+MtshvqjSB1iw12TKNBZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NBngCzqWeLPwedEJWM3naBs/ymn3A3SkrGGYCFVM/L4=;
 b=A44b+L7NsVhd8EA7ADJth7EI/xUdJfv1BI7Obte0m7AOwv95J1SU16Hda+iu+ZBUts+jRmnptNTuzljabzo3t3BE5Vk7NF5E/iWJngIlhIXig+p7J7MGhJ6lQ3bPexsjwMZj+YYuZmlFI6aellIN8Xhl6GrkTRWfNdDl5f+S1OFw1jnDjRCDj7aleSMusPPTIAcmaIe6mTeEPSiZZ2r48Mr9V7IvIKr44eFeMpeWdNlVIvJH42p1103GSdwz/Pxwon+U+W7c59NIGmziXXFzbIvVAPl0gOFhGAR1IQznbkB4FSuXURtJT9JAp/GCjN82c6zp5p+gQNsJ5LMwghxe2A==
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=NBngCzqWeLPwedEJWM3naBs/ymn3A3SkrGGYCFVM/L4=;
 b=nDTtFlJ8KLlAWD9jMvziruVbdrhHYM7VAQdP6U4qjPj8PQGrxBB5ECuFHuOFg/LVodULFpTigYom0fd6Z+CZrVWsfrpKUu/xss72mMPnkepx3bmZR1gOFRA05JywHv8Gc308LGxzwLq0NGwyVopfyzy2fG7cf0V+bwROaVAcRQqmUjpkcw3X3y7h4UeVnKxYzDi6sSZZFS44m7x/dz1D7xSh6cVvlqBstnQoZbDzFwrDAkTFOy4ccIGKUNUcN3npEblmCFHUTi7tBPkG1j5jrxP11mO2jKiGwy+0zdrPDyUSRLXx+CZYl59BYXtCPMhW7J3D0gH7/JklHRVx4zGLoA==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Sergiy Kibrik , Jan Beulich ,
	Andrew Cooper , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Paul Durrant , Alejandro Vallejo
	, Grygorii Strashko
	
Subject: [PATCH v4] x86: make Viridian support optional
Thread-Topic: [PATCH v4] x86: make Viridian support optional
Thread-Index: AQHcKYLgAWeerUFTx0CrYmKq2dRJwA==
Date: Fri, 19 Sep 2025 16:31:40 +0000
Message-ID: <20250919163139.2821531-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB8865:EE_
x-ms-office365-filtering-correlation-id: 36678050-eabb-470a-eb3d-08ddf79a0335
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?/+iceIKj8rm0b+DojetilM1jhTY0gpsrsAMBGVVhh5XbZv893ils+4zFSL?=
 =?iso-8859-1?Q?XPt3zdJNaJMgtMYqygyF1ZXcLJ52kq1o/5Rl8ofCGrS9yYHRwVWdBog4m5?=
 =?iso-8859-1?Q?Au0+9VmuutPzIa3Xpk+cwNx4nt0qNFSqD83WWEwUz7W/t7Ccqhv4R7DdKB?=
 =?iso-8859-1?Q?xgHsfpdpIU1MG0uAmQ9ueTZMOzzKSCQ2XTYMBj2DrIPGerOwUjJjll8v7A?=
 =?iso-8859-1?Q?W3+VBSX+M7RIr668ZLw5QCamDpuN13FSG0HNhouFsF/kuU+POXFhyw1+O3?=
 =?iso-8859-1?Q?6HmH2baSghjk1iokaKKfuxiz+QYhbV4mmCpmut8VtogW37T1+JDpm0Wn9v?=
 =?iso-8859-1?Q?G5hD97vx4W/aOrXVEVh5ziIn5soHcUTL2xM+mlCjSnHuXtzf7woupZUoy1?=
 =?iso-8859-1?Q?aT7Zib//kFMU0a3vjNesNAMzk7Xd1VAVfVqEcuwdVgAcg7sCe/EEWgS0If?=
 =?iso-8859-1?Q?AYAoMyUdgOD5QdjZ4hVD92zHlnTIZ8e+HXgxM6NSCt0i4xFjZdCbEI+5jI?=
 =?iso-8859-1?Q?CJnhYEAvHi2cEGlsq0kQCPs4zyWlhSo9p/zZrkKZZIsMn6Dae26rToegpF?=
 =?iso-8859-1?Q?Fz8UPKKZgFjDvpIg1iRSPDan+ipg/ggcq7pLPWFi8Ge0xe7y0pTh9C+K8/?=
 =?iso-8859-1?Q?GwF9M26WZWc5WooS01UxLWNmXBQRjdxDLd2kH0JeO1s10QNYCqDsfQV4uc?=
 =?iso-8859-1?Q?xarEe9d5NbN6ffLxOY3W+1hjFSCJpFApE0m7gVsEVFk6f5IPmqh8ouYlZI?=
 =?iso-8859-1?Q?z8YveFJTuDStHuaylU6VXZQ70FpiLvnHKQT6CeAk72wiiMXGWXJoyl95kc?=
 =?iso-8859-1?Q?UD/ptm0eJA3GcLVYAHycdDzJQ9Yc098rVjF+9R4UTg8agmalNbOKA2An99?=
 =?iso-8859-1?Q?HQgBrWgoHaw8HINaJlUE8oCS+GiLoA5H+Jd6QCBvwyEDUA/ubm2zC9NnPB?=
 =?iso-8859-1?Q?YwTsHiTBGjxfJdDCM1EsbEWbJqAlvjNf4vlHDKAurITFDp4zB+JYewrKxp?=
 =?iso-8859-1?Q?otJ5v5/33pywYxxhTH/HijDbEZDbRScgb+u/R8pLWRA5POaziSLrxfgy1A?=
 =?iso-8859-1?Q?IqQjIx/vvidbiZoZ+7D3c+N3ewRKSmGk2Mc0VyYZYxLLkMx8zqF2GhcxIr?=
 =?iso-8859-1?Q?0ykyj+RAlxu9rmInUFZxiShO9kjOpEtEgadRZGQDJky5CMi8kuhYn12VEY?=
 =?iso-8859-1?Q?Cp01cM+1gzlbSIf1yg7evWtRhqG0nglYaCQpxiwEqs3wLw/elwhL+GdUPb?=
 =?iso-8859-1?Q?JDnz8JqP7HPCyoVTyym6MgTIrHIYpVdaL25PmCn3ume5Cem7JZlcw0yl71?=
 =?iso-8859-1?Q?1oF/sjjmwYXyDl3OZV1Gu/ri9aAtJqEl1q+qUa6dXnoFU7sP4lLkjAzmVH?=
 =?iso-8859-1?Q?lWHNH+f1F7qt20irP7o/f2u0K7LVI9iviyhwZn9IIfOpZX+QajBvWu+P7E?=
 =?iso-8859-1?Q?fDLAFuWLoPTQgMKtDGSdYQqyM/LbImNts/e5xRx97MB4pYvo4onUFkVDlu?=
 =?iso-8859-1?Q?iYK4/O7XlJ1RxM1RlAbUnaYadJQMgXa42+L2drVAzofA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?mjP/Xx5xjQRMr6UfEn5x5leO1tMWxOhOBYDJXFzl+RAfK5lOHqlMbdWD0Y?=
 =?iso-8859-1?Q?ICszp4aqInUJYRCQH6bE/2CEY6EwSR/FzafNmG7xdj+Y2vXf1mPtDUoF/0?=
 =?iso-8859-1?Q?UslrXkL+0ecCoNcC/ZYyOoc6F/VFollotA9xRJ4PA6vr6ZChY5M4LAd11D?=
 =?iso-8859-1?Q?uU7ybCcCjI3aYgs8rmdcHUV7uncOkl93yzVjVwIeTOw5xs8Oc/iaAn5q84?=
 =?iso-8859-1?Q?033LchJ21JvJc3rlFSxnAl6Ai+2/+juTLYj/W0xICWy/4VOppKyOG1So1Q?=
 =?iso-8859-1?Q?oWAdzq5irXOC0FPK474H3Ol224Pr92WNx1OjIwvx7w0pMQc4JSUttJccAn?=
 =?iso-8859-1?Q?QHUcrUcVD0LfVcR4PViIfDCbcGcJqFYD/FnHCZFIN2rGsQldShij7LclnS?=
 =?iso-8859-1?Q?K2eEmvEtDRxievQNfyowQZM2pqTWoTBkr15l8S6AM4SH3XcO0rmCeokgd1?=
 =?iso-8859-1?Q?q0B3LEND/aMzvcxB6YQu/V6I9jx9tUlSpdJcups6OaobT2A3qdhk6UBslj?=
 =?iso-8859-1?Q?aBxTrOlW1rvSoCVes2pjNC4PUeG6yeZmVSHMUnDVQgDhqsj4DFpx7Ybfvy?=
 =?iso-8859-1?Q?hM3J2Kqnncv5hiSChrCLYNP2EwdxD5DONSkAfPFrpY5kOcZmmPXgVpHX0Z?=
 =?iso-8859-1?Q?gYShuuowj2sYpOYDX2gVNTKQ2yw9wcXKFBYRs/kgFI1V9BpdmS+PD/N+bd?=
 =?iso-8859-1?Q?ewigbVklK4zrhzjAY9YtLBPFS6wR8NXjn9Sba3TaHvrunhPtDJziIPmXAM?=
 =?iso-8859-1?Q?xgqTdxJl4ZJL2IxtpJvj0LyKjPC2xYRqmgMFF2hFV6/67s3rqoDTD/1tHm?=
 =?iso-8859-1?Q?PvQJGmrsRztuiw6Fqz5In+f+179gY0abEosxPnr4hU8cW6pCHDq9FgbQB6?=
 =?iso-8859-1?Q?AzukQpyO5eeZ/m13lYnbAjcxibYCQONVdJGbzBoadFDM7aC0R/Pr5vWPEq?=
 =?iso-8859-1?Q?9VAVNeiv7dkhQzmQmb2l0SwBwI8nY7CaSxLwr8y4Ctr6M5FGIBz2AbKsbR?=
 =?iso-8859-1?Q?gI2TqQWQ8BenuCRs1XHKvDVVbjv69+0S5G1aQ6/XwiqS+uzRSHKtS9DqML?=
 =?iso-8859-1?Q?aBT437yb29Dv25MjEkYufvqaWIwCx8qUorsYS4w/naZSzgyZcVt2GlHAq8?=
 =?iso-8859-1?Q?EOLb5PNdpbJi5XVCvHm2AwlgdHYdw58eL8qzUwhfSIVYwyTbUjGhKRbS/l?=
 =?iso-8859-1?Q?EKgORiWOaqcby75q9rwnMHW46y1DZONs4B2TSbBz1BG0Pm205r7pIZm0VL?=
 =?iso-8859-1?Q?gP5MMt7MBKxOqGXodL0eFS6aq/PjDJfqmwN82v7+9ns+cJfVVAkrv+vYBh?=
 =?iso-8859-1?Q?q4RJIq9pPbstJQ0Pm2v20Q1ZjLsmYVQpsrvZt0S3cRl1ujVIkBH3y55fYH?=
 =?iso-8859-1?Q?MMP0w8yGK/ZajfARZEKhHofX5xyrDynm8xJz9DZ0p/XSkrXcaCXt/Udgtq?=
 =?iso-8859-1?Q?nN3tErdffAdkzInx4wA/8oXMzuy/ckjin4tR1RPKwPVauO53AFc5Q5t7Bo?=
 =?iso-8859-1?Q?yhIJDUdP1fsgjZs5GusdXP9w6nC4CJx0EnCSB1DuxpxAn9eO4TJV1MegeV?=
 =?iso-8859-1?Q?+HQP2nl0Qe3eWnxrmII8/CZJZX3aAaGUa/Cov5f0q5XN51Kn3rEfNWsPi7?=
 =?iso-8859-1?Q?0dOCUqXV7CRPqiBGOIHiqsK0L4l2sxhlLoROyf/QcdmKJJoNQwbsyhHQ?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36678050-eabb-470a-eb3d-08ddf79a0335
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2025 16:31:40.7008
 (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: t7DdPCDvVhVSguGt+JhZ//eSCYVPBTVyyAdEURFR6KpjabPfYdSRG4Ff85KYXgNwDnbadAPtZUNj2iiR9JFy2BLp6xYxzxXyxZrOuuSBjAQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB8865

From: Sergiy Kibrik 

Add config option VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related mac=
ros.
Having this option may be beneficial by reducing code footprint for systems
that are not using Hyper-V.

[grygorii_strashko@epam.com: fixed NULL pointer deref in
viridian_save_domain_ctxt()]
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Grygorii Strashko 
---
changes in v4:
- s/HVM_VIRIDIAN/VIRIDIAN
- add "depends on AMD_SVM || INTEL_VMX"
- add guard !is_viridian_vcpu() checks in viridian_load_vcpu_ctxt/viridian_=
load_domain_ctxt

changes in v3:
- fixed NULL pointer deref in viridian_save_domain_ctxt() reported for v2,
  which caused v2 revert by commit 1fffcf10cd71 ("Revert "x86: make Viridia=
n
  support optional"")

v3: https://patchwork.kernel.org/project/xen-devel/patch/20250916134114.221=
4104-1-grygorii_strashko@epam.com/
v2: https://patchwork.kernel.org/project/xen-devel/patch/20250321092633.398=
2645-1-Sergiy_Kibrik@epam.com/

 xen/arch/x86/hvm/Kconfig              | 10 ++++++++++
 xen/arch/x86/hvm/Makefile             |  2 +-
 xen/arch/x86/hvm/hvm.c                | 27 ++++++++++++++++++---------
 xen/arch/x86/hvm/viridian/viridian.c  | 14 ++++++++++----
 xen/arch/x86/hvm/vlapic.c             | 11 +++++++----
 xen/arch/x86/include/asm/hvm/domain.h |  2 ++
 xen/arch/x86/include/asm/hvm/hvm.h    |  3 ++-
 xen/arch/x86/include/asm/hvm/vcpu.h   |  2 ++
 8 files changed, 53 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index 5cb9f2904255..aed799fcb9c2 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -62,6 +62,17 @@ config ALTP2M
=20
 	  If unsure, stay with defaults.
=20
+config VIRIDIAN
+	bool "Hyper-V enlightenments for guests" if EXPERT
+	depends on AMD_SVM || INTEL_VMX
+	default y
+	help
+	  Support optimizations for Hyper-V guests such as faster hypercalls,
+	  efficient timer and interrupt handling, and enhanced paravirtualized
+	  I/O. This is to improve performance and compatibility of Windows VMs.
+
+	  If unsure, say Y.
+
 config MEM_PAGING
 	bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED
 	depends on VM_EVENT
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 6ec2c8f2db56..736eb3f966e9 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_AMD_SVM) +=3D svm/
 obj-$(CONFIG_INTEL_VMX) +=3D vmx/
-obj-y +=3D viridian/
+obj-$(CONFIG_VIRIDIAN) +=3D viridian/
=20
 obj-y +=3D asid.o
 obj-y +=3D dm.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a1d..95a80369b9b8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -701,9 +701,12 @@ int hvm_domain_initialise(struct domain *d,
     if ( hvm_tsc_scaling_supported )
         d->arch.hvm.tsc_scaling_ratio =3D hvm_default_tsc_scaling_ratio;
=20
-    rc =3D viridian_domain_init(d);
-    if ( rc )
-        goto fail2;
+    if ( is_viridian_domain(d) )
+    {
+        rc =3D viridian_domain_init(d);
+        if ( rc )
+            goto fail2;
+    }
=20
     rc =3D alternative_call(hvm_funcs.domain_initialise, d);
     if ( rc !=3D 0 )
@@ -739,7 +742,8 @@ void hvm_domain_relinquish_resources(struct domain *d)
     if ( hvm_funcs.nhvm_domain_relinquish_resources )
         alternative_vcall(hvm_funcs.nhvm_domain_relinquish_resources, d);
=20
-    viridian_domain_deinit(d);
+    if ( is_viridian_domain(d) )
+        viridian_domain_deinit(d);
=20
     ioreq_server_destroy_all(d);
=20
@@ -1643,9 +1647,12 @@ int hvm_vcpu_initialise(struct vcpu *v)
          && (rc =3D nestedhvm_vcpu_initialise(v)) < 0 ) /* teardown: neste=
dhvm_vcpu_destroy */
         goto fail5;
=20
-    rc =3D viridian_vcpu_init(v);
-    if ( rc )
-        goto fail6;
+    if ( is_viridian_domain(d) )
+    {
+        rc =3D viridian_vcpu_init(v);
+        if ( rc )
+            goto fail6;
+    }
=20
     rc =3D ioreq_server_add_vcpu_all(d, v);
     if ( rc !=3D 0 )
@@ -1675,13 +1682,15 @@ int hvm_vcpu_initialise(struct vcpu *v)
  fail2:
     hvm_vcpu_cacheattr_destroy(v);
  fail1:
-    viridian_vcpu_deinit(v);
+    if ( is_viridian_domain(d) )
+        viridian_vcpu_deinit(v);
     return rc;
 }
=20
 void hvm_vcpu_destroy(struct vcpu *v)
 {
-    viridian_vcpu_deinit(v);
+    if ( is_viridian_domain(v->domain) )
+        viridian_vcpu_deinit(v);
=20
     ioreq_server_remove_vcpu_all(v->domain, v);
=20
diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridi=
an/viridian.c
index c0be24bd2210..5e49fc286d76 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
 {
     const struct domain *d =3D v->domain;
     const struct viridian_domain *vd =3D d->arch.hvm.viridian;
-    struct hvm_viridian_domain_context ctxt =3D {
-        .hypercall_gpa =3D vd->hypercall_gpa.raw,
-        .guest_os_id =3D vd->guest_os_id.raw,
-    };
+    struct hvm_viridian_domain_context ctxt =3D {};
=20
     if ( !is_viridian_domain(d) )
         return 0;
=20
+    ctxt.hypercall_gpa =3D vd->hypercall_gpa.raw;
+    ctxt.guest_os_id =3D vd->guest_os_id.raw,
+
     viridian_time_save_domain_ctxt(d, &ctxt);
     viridian_synic_save_domain_ctxt(d, &ctxt);
=20
@@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt(
     struct viridian_domain *vd =3D d->arch.hvm.viridian;
     struct hvm_viridian_domain_context ctxt;
=20
+    if ( !is_viridian_domain(d) )
+        return 0;
+
     if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) !=3D 0 )
         return -EINVAL;
=20
@@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt(
     struct vcpu *v;
     struct hvm_viridian_vcpu_context ctxt;
=20
+    if ( !is_viridian_domain(d) )
+        return 0;
+
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL )
     {
         dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 993e972cd71e..79697487ba90 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -426,7 +426,8 @@ void vlapic_EOI_set(struct vlapic *vlapic)
      * priority vector and then recurse to handle the lower priority
      * vector.
      */
-    bool missed_eoi =3D viridian_apic_assist_completed(v);
+    bool missed_eoi =3D has_viridian_apic_assist(v->domain) &&
+                      viridian_apic_assist_completed(v);
     int vector;
=20
  again:
@@ -442,7 +443,7 @@ void vlapic_EOI_set(struct vlapic *vlapic)
      * NOTE: It is harmless to call viridian_apic_assist_clear() on a
      *       recursion, even though it is not necessary.
      */
-    if ( !missed_eoi )
+    if ( has_viridian_apic_assist(v->domain) && !missed_eoi )
         viridian_apic_assist_clear(v);
=20
     vlapic_clear_vector(vector, &vlapic->regs->data[APIC_ISR]);
@@ -1360,7 +1361,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
      * If so, we need to emulate the EOI here before comparing ISR
      * with IRR.
      */
-    if ( viridian_apic_assist_completed(v) )
+    if ( has_viridian_apic_assist(v->domain) &&
+         viridian_apic_assist_completed(v) )
         vlapic_EOI_set(vlapic);
=20
     isr =3D vlapic_find_highest_isr(vlapic);
@@ -1373,7 +1375,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
     if ( isr >=3D 0 &&
          (irr & 0xf0) <=3D (isr & 0xf0) )
     {
-        viridian_apic_assist_clear(v);
+        if ( has_viridian_apic_assist(v->domain) )
+            viridian_apic_assist_clear(v);
         return -1;
     }
=20
diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/a=
sm/hvm/domain.h
index 333501d5f2ac..95d9336a28f0 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -111,7 +111,9 @@ struct hvm_domain {
     /* hypervisor intercepted msix table */
     struct list_head       msixtbl_list;
=20
+#ifdef CONFIG_VIRIDIAN
     struct viridian_domain *viridian;
+#endif
=20
     /*
      * TSC value that VCPUs use to calculate their tsc_offset value.
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/=
hvm/hvm.h
index f02183691ea6..7312cdd878e1 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -510,7 +510,8 @@ hvm_get_cpl(struct vcpu *v)
     (has_hvm_params(d) ? (d)->arch.hvm.params[HVM_PARAM_VIRIDIAN] : 0)
=20
 #define is_viridian_domain(d) \
-    (is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
+    (IS_ENABLED(CONFIG_VIRIDIAN) && \
+     is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
=20
 #define is_viridian_vcpu(v) \
     is_viridian_domain((v)->domain)
diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm=
/hvm/vcpu.h
index 924af890c5b2..9ed9eaff3bc5 100644
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -176,7 +176,9 @@ struct hvm_vcpu {
     /* Pending hw/sw interrupt (.vector =3D -1 means nothing pending). */
     struct x86_event     inject_event;
=20
+#ifdef CONFIG_VIRIDIAN
     struct viridian_vcpu *viridian;
+#endif
 };
=20
 #endif /* __ASM_X86_HVM_VCPU_H__ */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 16:32:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 16:32:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126962.1468192 (Exim 4.92)
	(envelope-from )
	id 1uze2c-0007fB-DL; Fri, 19 Sep 2025 16:32:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126962.1468192; Fri, 19 Sep 2025 16:32: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 1uze2c-0007f4-Al; Fri, 19 Sep 2025 16:32:58 +0000
Received: by outflank-mailman (input) for mailman id 1126962;
 Fri, 19 Sep 2025 16:32: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 1uze2b-00075O-Bb
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 16:32:57 +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 4b81c796-9576-11f0-9809-7dc792cee155;
 Fri, 19 Sep 2025 18:32:55 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB8865.eurprd03.prod.outlook.com (2603:10a6:20b:554::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Fri, 19 Sep
 2025 16:32:53 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%5]) with mapi id 15.20.9137.015; Fri, 19 Sep 2025
 16:32: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: 4b81c796-9576-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=swIvZdjsTb+JLzkx4tHwcqslBs1DWT/qSvo2sEB7Su4zMA4Nqr1YtaKQ7mmgQJige7cHRacTUeVMZSdUfsUcnaEPTPLVk8zr/ZciGDwoomh9AXO/Am2pmpd9nWlfpliZtIROc6qW0Izzt7iMu7wknoCDCcbHg8Laaz0MZ74VilQXJaHvaAwOyRGDdqisyWRjkuyFeeowXHL6cRG47Ixn4stJMUgeypz6ZWPm3PHKZNctF7bP5Aa3+8UQFDtOTBYSwI2Bm63os1cpjTTB+5LKmjW1kHIu2rDM9IiW/gpOlxYb6umWEjpVZbynLQqwvfDTuzzpSmu7at0D8W1/4Oao+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=OgM0Wrl4PWhfRRDHmVgho+tLgEimXUfGsH20wH2d8BU=;
 b=u1N+DEEeQKWARLjw1XFW3jGBoMSrgwQv9zgfWuan8mD+uNdV73t4HDmf6HUHK1J8bHrNoZAECTRk11xlY2ZCAnzErndnHB1fTsLFDEeJ4N4ExLYP9Kkxjdu56UFH29JOPuqLkGbeIkQ6mVkXkweeqnOTy4ay5h1LaC4KKHosIOuctrQgZFiz1KFOP7OIh1oeTVBomrSk2fUz2ykysXT1jSCMx8v9rlhCnZfEky2BihAEV7SfPlaFmZumpVKkg+ISHg+ARfeYXAqsuKpq6RfXYqyE4/NnU3dagsQFIoogGbBZ2xoDbdcRZhWhh1Iy1UU4ohHgXYzkUbhicjEbw9Q1KA==
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=OgM0Wrl4PWhfRRDHmVgho+tLgEimXUfGsH20wH2d8BU=;
 b=D9oh3j6CEOt4c1RQJkQkBI6UVi9J6bdWeo8XEb03KY71ve2xvSflXWvbD0ur6sh3my8wIYpz3dkdmTvoILNl+OUQ5Vuevxws+efCBTO/8wEpl2JSQnaALnYFwpvBX2GR7ahM51oWZZ8yZ73cNAcDzd+tJYdMEd9hKbnxwsMwRU5tOO5w0W+NHXbMdAlfDSx/M3RkWUHI97u5Ixvj56XZUxbThqIxWqWVsSFNZ7DJ4W29l0wt77oMB87IaBZKFlRqoCNgaJg6prShYVUkmNIisWxzX0IgjiwN8644AZgz6iF/IWkYacOvuWUf9y/uCQHVDUyO/InPk4fCtc9q2A+q3A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <20faa8cb-5251-49f4-9f09-cc9abdad310f@epam.com>
Date: Fri, 19 Sep 2025 19:32:52 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
To: Jan Beulich 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
 <0e1a6339-a4fb-4697-acfa-392168b391d4@suse.com>
 <2d6e5cc6-15c1-40ce-8742-1b77b32203a9@epam.com>
 <146fc872-2ba5-4dc5-9e0f-2d10e2836a2e@suse.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <146fc872-2ba5-4dc5-9e0f-2d10e2836a2e@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0288.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e7::19) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AS2PR03MB8865:EE_
X-MS-Office365-Filtering-Correlation-Id: 60b9af6e-33e3-4eb1-2a39-08ddf79a2e9d
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?VGYwUDJBcjJZczFJYkJJaHlQdTVJWm53U2hsSkxhVzEzZDd1SFVzNkJBV3VZ?=
 =?utf-8?B?L2hEdUozWmpnOEkyQXZLWGhVeC9kWkduUFNzVUwyZ3lpaGpIUXdnZStEQ2xu?=
 =?utf-8?B?MmJCL0tadVY1VUU1SVJKNXBNc0swNFJyenNDZEx1NFk5WXZkdmZ2dkRQcUpY?=
 =?utf-8?B?NExKZ1hjelVOODgyamVpNmpxb1l3dlowdm1Zb0FHWExEU0tZMjZOd2F3WDgv?=
 =?utf-8?B?VlhzOVlCU0JvdXBSVyszRGRvZk1nRlJIM3BWZDMzQ3o5aE1EZFZ6MmVnYTk0?=
 =?utf-8?B?UWQrM3hndnFOYnZaZkd0dDQxT1hCWFB0cEQxcENCc0FiRko4NHdZLzFDbHFw?=
 =?utf-8?B?MHdFY1IzTVhkakZsTDJxai83MitJdGlObEFtMFNZeU8xbVJGcFVLZUpCQ1h1?=
 =?utf-8?B?V0hLbUE3WUlNYS9yKzd2TWRMclFUamZtQVlpeUt1SmJKVDhNTmtlaWF3UVpr?=
 =?utf-8?B?M2ZtUS9EeUxHbzZPWk5yOUY1QktCVGxjT1FQd3RNcGZUUTJlckF5SWVQc0hl?=
 =?utf-8?B?Y242OG82ZHRjMk4rMXpKMk1tZ1JBZ2RJOVBrcDgvUlAwcXA2OU1sK3VpZGVy?=
 =?utf-8?B?RnB6cDN3bTBObjEzSWF6cmduTkNYU0F2a1ZsSmhhQkk3NWMrV1RaaUJLZDI2?=
 =?utf-8?B?SEVoOGJsdjRVdnN4OHVMN2RyM0UzeC9kU24vdkJvd2JVOGpaZkMyRnF4RXE4?=
 =?utf-8?B?TVNQTVpUUUgvUU5SMGsyUk9XRit5V21BNlEvd2xyN1pvVjE0RGJzS1d1MjFF?=
 =?utf-8?B?a0V6RUlEMU43aVg2REcvYWhBNGFGWDV1K2V6OTNablZ3TW0yc3cxdURiZHRH?=
 =?utf-8?B?dlBRQjVUZWo0NFVIaVk0dEgxS2VzWmZGMWg3STF2eW43ZWJMVk1VSHo0NGpo?=
 =?utf-8?B?RnkrcHNiUVB2SzlwQ2dQQ0lzUE5YdU92SGlaU0tuNWYvUHhueExuSXZUN0cv?=
 =?utf-8?B?c1BKdCtNTkc1akV1dmVpZ2YyNWxDbHpWcDFkaUhiNmpQdUxGeFBVbHJWTk9u?=
 =?utf-8?B?Z3pTcW9zM0kwMHZxb0xiYXhxMEE4a0t4b0NzRUNLSWN5NU82YzdUNFcyNWpS?=
 =?utf-8?B?ZlVKSTRCNGxhZzBmQWtqYjZPb0VvSklUS3ZFdldEZ3l2UGNjMTY3NFEvaWJx?=
 =?utf-8?B?RE9RZjJvREFoSGtveE0vZzVFWmR1QVBoNGJ5cVpZT0RCSmFQUGNxb0dJQW85?=
 =?utf-8?B?TDg5UENmdTdXbC9YMEozUWwzU05KdldqZ1U4S290Wjd0NTBFNGZ6WlkxKzJJ?=
 =?utf-8?B?NHUvU0N2ZkRSeTdPTGxFenJPSFpCc01qcXE2WXpJOVNmeUlNM3QyRllOQms5?=
 =?utf-8?B?TnY4WTNkblcwR1g3cHpkQ2l5RnJYK2hreTBDS201Y0VVbE5rUE1leTBWZ3F5?=
 =?utf-8?B?SndvMUpCK2FJZG1wcVFlWXhaV0JPSUpYajhWdE9sVXBQMnlweWtxMURGNkcr?=
 =?utf-8?B?c3JGc1BWNG1wVTQrVUs3anRucEFybVcwcnloTmZXTDNIRm80UHVNeDFVbXhI?=
 =?utf-8?B?OHRQejBGNC91M0VuZGtYaHpLdHpvUHZxbEs0bms5THVxK1hYUDE5TEt0RDNY?=
 =?utf-8?B?T0x1NlhkN2RLZWgzeDY5MlNDQUNDbHVYTDhDZGxMYVl0OHEyYnJ2YXkxdVMy?=
 =?utf-8?B?S0Npa2g0UkpuSTF0Qk54djNSK3J6RWM0ak50dUZSYnU1aWdXSldDSmRzdHk4?=
 =?utf-8?B?V3NwV0N1aWtvY2VnK2kyT0JoYTVUR2k3MGtPY2FZZHB1VTY4VnhtNFNQMHBk?=
 =?utf-8?B?N3RaOUxRRGRYbHMwMkJvcFdMTXEyK0NvVzFMNk9QanFONEthSng0QU4wNmFH?=
 =?utf-8?B?dUJwb2dlbUI2blkyYUlNQ3lzU3lGenFNZVdQUzJ0VHlhNGxBc0srdkJyY3kv?=
 =?utf-8?B?MXF2a3oyQWtRZVE3cis1Z095YVZHVU5aa2lzdnZBdldwejhnd0lkYStDeG5E?=
 =?utf-8?Q?vr4SqKBPkZQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a0xreUh6MTBUR21XUTRiUExzMm9lVU5jbSt6Y2Y5dnV6d2VJdWE3WXhOMDMr?=
 =?utf-8?B?WkhOSzZHWUQ3VGN1Zmw4WWpkb0Z3MXBSSE9ReS93RjFDbUdYc0xNU2w4Rnl6?=
 =?utf-8?B?bnpjaC9zUDJia2NiS3E2bXFXVkJjVjZkbHEvOE1LZlFLMVIyVFpxTWg1MFh2?=
 =?utf-8?B?NFVRV2tYK21Nc1lmc0RKM2xXK1NWL0ZsR2xFWHFZbEsxRWRvK0g2UmFab1FC?=
 =?utf-8?B?eVNtOTFMN2NqR2ZZU2lRM1pQZzR6NVJJam9pT3pZMUxTbG56dDFMeEREV1lj?=
 =?utf-8?B?LzVpeFVGVG1VTXZFaVNjN1NGREw4bEdWQnlsRnRtQUJpemFwUHBCd1pOUENw?=
 =?utf-8?B?MlpjTDV2VG8rTXFmekxMM0gwaG9kUEtJWWlaa0NVd0Q5Kzl1STg4Y0JDaWEw?=
 =?utf-8?B?azJaSzNxYlB0Yzh3ZnVNelFoRmNqL2NxSktnaEZmaWF6bzJ5YmpCbU00RndP?=
 =?utf-8?B?cUpMYjlvTzhRUjZWY0VpRzR3L0lWRnJ4aEpxT2xBOHJoVFZqSVgxeGdvbFI0?=
 =?utf-8?B?eTRvSkxLNDZHOE1mTnlzUGxjSGxPOVBOVFpHeGV4cnFkMkRSN2gwL2dOeUMv?=
 =?utf-8?B?anVzTFJaNmVSNncwTzNBVC9VNFovak1KVmlyVXkydVZjQlNqTWJZM0VIT1oz?=
 =?utf-8?B?amMwNWsvR1I3a01aNTJtUHJ1bmJod09wTVNwR0N3MXppRExrdFNOZlE3aERu?=
 =?utf-8?B?S0ZMSzBMalhyQkJ5anVCUkV0SjVZOVhxUGx3OFd6eElQd2U0NFBRNFg0ZjhJ?=
 =?utf-8?B?Z2dFQnZEZithQXU2cWhzMFdPR3FSVjVPdGQ2Z2sybzkrcm94MlBnZUhObjR6?=
 =?utf-8?B?NjZrOGVhTEhJOFBmSysva2h1Umc2VWMyOHYwUlpueGM3NW1uNi9xSTZtSjZm?=
 =?utf-8?B?YWdycW81bDN2VkZiQVZVNDVROFhSdjZveE5VVVd2UklqTkZRcGlqcFU4Nk53?=
 =?utf-8?B?cXk1bDR2aTk4aENZaXVGS1grRTBRVWVlSWpqRy9MZHNHeS9vSWhwZU9vbXM0?=
 =?utf-8?B?R2hrd0NsQlhvRUtPend0UmxESDdRWFRMNFlKSkltME1vS1ViRmVzRloybEhR?=
 =?utf-8?B?UXlJRGNvSVQ5TkRWYStlVXhZRUJjUHBGek9ZWHRaV3k4c3dQR29rQWJNVkdr?=
 =?utf-8?B?KytCbkRaZFF6bjR6SEg0eWhwV0pMS0ZDTEgvMHhRZE5WV29pbkFMU3FaSU5V?=
 =?utf-8?B?cnE1V0dxZk9yYVlMb3grWVpCZDdrVnFaM2pDazEvVnVRU1hTL2lMRG5Ic2g5?=
 =?utf-8?B?ai9meWlYZHZuQXFaSmtOZDNuY3N0MzRhYnlGWDlWdWVSaXVDajYwVVNlN3dq?=
 =?utf-8?B?eW5xYkdWQ3QrNmErR0R6T0JEdjVuNG1MWHlWbVJJUTJyUmh1YmpJRHNnb1ZW?=
 =?utf-8?B?NXl6WktmZnhobTVMRkt1cmVnM0VyL2hjcElEUmwyNUNFZ0VYeUhoR2NValAr?=
 =?utf-8?B?eERGVU9JdzM5cDgzQTNOMTNnU3NiTGFaRXdyekwwQVBkQ3puQXdRZnMraEVm?=
 =?utf-8?B?MC9Kb0R0aldMdmZUSnpRTXovaDZuUVZ4a1JvYlNJbmJ6L2JtNHZnSXJvZXdN?=
 =?utf-8?B?Ly85WEZDcHAyTUpnTzdpSXh0S2FwMkdQQ0RFU0I1Mk5scVM5enFoTjlDbDJB?=
 =?utf-8?B?OHQremdIeTFoYmQweWVLem1jMGFCdmNaOWhtTUl3MEh4d09EQkxsb3dFWHBK?=
 =?utf-8?B?a3MwVFA3OXRLdkw2T243NXZaallZOEtjbSs1WDJlWGlueWdhekdqZ3hScHNm?=
 =?utf-8?B?ZkRnY2hBMWJoZDhSR3cvNTk2Z2J2eHRRclVjK2RYT05zNnFYLzdGRkpPTG9Q?=
 =?utf-8?B?WlZyKzhDZjBuL0IzTnNHQXUvd0xLemV3UEhhankxRGxjaFV0TUNtREFoMXhv?=
 =?utf-8?B?eUgzN1BVektPblIxV3d4YnVDZWhCaTB6dE9Jc2VrZzFpOHFhcExSVXdGQWlS?=
 =?utf-8?B?UDdobDhINy9iT0t4UUFoeVVQQ0NvV2hkTFJ4R2hnU0hjRDg3d25neVdMeU4z?=
 =?utf-8?B?NW9tZUNUVjVBRjVlSW1jVmpGVFNxZkR2UXJFWmpReGdEWmNHMHdBVlhPY2xE?=
 =?utf-8?B?emd5eVQrdXZVM2JIS2tQV0FOcndhRnNKb0oxOVJjTGEycXlPR2h1QmRCUVlu?=
 =?utf-8?B?SERQSnNTcWM4ZmdoRlB6RkV3bFROUGJsNDMxVzV5RHpFQ2g2VEY4RGd2ZjlG?=
 =?utf-8?B?U0E9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60b9af6e-33e3-4eb1-2a39-08ddf79a2e9d
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2025 16:32:53.6498
 (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: vM1prvGuxK9mbKDYf2F9MM8pR03hJY4+K5ifdxMAe4/fKzNXYb8StrfBAdYCMqpGuwNsKjaCQqbD8ZwwvGt9u2O2J2bUk6Z5NTviGVKd1x8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB8865

Hi Jan,

Thank you for your comments.

On 19.09.25 18:29, Jan Beulich wrote:
> On 18.09.2025 19:17, Grygorii Strashko wrote:
>> On 18.09.25 18:41, Jan Beulich wrote:
>>> On 16.09.2025 15:41, Grygorii Strashko wrote:
>>>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>>>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>>>> @@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
>>>>    {
>>>>        const struct domain *d = v->domain;
>>>>        const struct viridian_domain *vd = d->arch.hvm.viridian;
>>>> -    struct hvm_viridian_domain_context ctxt = {
>>>> -        .hypercall_gpa = vd->hypercall_gpa.raw,
>>>> -        .guest_os_id = vd->guest_os_id.raw,
>>>> -    };
>>>> +    struct hvm_viridian_domain_context ctxt = {};
>>>>    
>>>>        if ( !is_viridian_domain(d) )
>>>>            return 0;
>>>
>>> This check doesn't check for vd being non-NULL, so this still feels a little
>>> fragile, even if it looks correct now.
>>
>> Hm. May be I missing smth., but
>> - if is_viridian_domain(d) and viridian_domain_init() succeeded
>>     then d->arch.hvm.viridian != NULL, like always
>>     (otherwise domain will not be created)
>>
>> - if !is_viridian_domain() then code will not go further
>>
>> so I'm missing to see how !d->arch.hvm.viridian (!vd) can happen here.
> 
> Well, as said - it feels a _little_ fragile, as it's not the NULL-ness of
> the pointer that is checked.
> 
>>>> +    ctxt.hypercall_gpa = vd->hypercall_gpa.raw;
>>>> +    ctxt.guest_os_id = vd->guest_os_id.raw,
>>>> +
>>>>        viridian_time_save_domain_ctxt(d, &ctxt);
>>>>        viridian_synic_save_domain_ctxt(d, &ctxt);
>>>>    
>>>
>>> Just below here we have viridian_load_domain_ctxt(), which I'm pretty sure
>>> now also needs to gain some check: Save records coming from user space, we
>>> can't really rely on there being none of this type for a non-Viridian domain.
>>
>> As per my understanding:
>> viridian_load_domain_ctxt() calls hvm_load_entry_zeroextend() which
>> should not succeed if context was not saved (which shouldn't happen for
>> !is_viridian_domain(d) case).
> 
> I don't understand what you mean with "was not saved". To be free of security
> issues, we need to cope with any (bogus or not) record appearing.

I've posted v4 with additional check added.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 19 20:49:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 20:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127040.1468202 (Exim 4.92)
	(envelope-from )
	id 1uzi2V-0002nL-Cv; Fri, 19 Sep 2025 20:49:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127040.1468202; Fri, 19 Sep 2025 20:49: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 1uzi2V-0002nD-8U; Fri, 19 Sep 2025 20:49:07 +0000
Received: by outflank-mailman (input) for mailman id 1127040;
 Fri, 19 Sep 2025 20:49: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 1uzi2U-0002n7-Fq
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 20:49:06 +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 14527bfc-959a-11f0-9d14-b5c5bf9af7f9;
 Fri, 19 Sep 2025 22:49:05 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3ee1381b835so1485323f8f.1
 for ; Fri, 19 Sep 2025 13:49:04 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77f0401bdfcsm2057392b3a.76.2025.09.19.13.49.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 13: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: 14527bfc-959a-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758314944; x=1758919744; 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=eOwVNfUrJ+HsIf4zA/oPRdt1s5UoW/dvVzG5cIRIAHM=;
        b=bYhC8PKHuuciCDidJvAz8u0KmbEe7wnrHq9420rU5UYF9zMGOksyVrRx9FExl/xlxw
         vThqP6ZWES9YBVOEteqzxBNvr4fMONtrsGN3hX43IYIgmwcPk57j1SYi+NJLXWA40Lof
         Ag2j63LLzhbMqA/HLf9YuJ2Js680BSHiTGuJkLsFqASXxYKgxP2BwvLgoBQGnLCKWJc2
         XbxYTfsrXE3pgqLLUe21giwfia0nJxbjesw+ouRvNEKnq0l6gaZBXa2ogBtp/lj+XMmb
         hy7SaQdri1wXDqpalG60ANDbOPch93ypk4EvoPnZBpM03dFnU+QkJZ4mFw47dYUartmE
         p0/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758314944; x=1758919744;
        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=eOwVNfUrJ+HsIf4zA/oPRdt1s5UoW/dvVzG5cIRIAHM=;
        b=CwVQF9Dv9EnpgAQwqL84GQ8anV38RaDOsVY1ejv1XaJMVY6xAoikoKYaoZzl4AssLl
         bJTtS6wM9/e8ddz30HwAdpyq7TA1nBnLqUE6nM9imQoCzb+fA6gHBDdG2bSEyNHsCfjX
         4McqXj24/XXNxbH6FINSc/1DbMlk4eUESy0/H+jhrLhVPsk0BokK3zfV5W04Cf0hrDKx
         1vlGMcse2C34/yBkIbvCPX/TXBtEfP8YqcKK25c5IWfgsKmVsFQhgMlZZn+4Bc/tKCA6
         OTOw8dZgmhkzHvFVcJpwX58s+viWdesN76NDSE8hLenSD2UdHgybWs0mE8JiNbkmrteD
         0NJg==
X-Forwarded-Encrypted: i=1; AJvYcCUgQGeE51+3pSySmnEwdE2SEbMuY6Q4XWJ64/9AbSFdIlir6dXUmfdB374PdvuROfm8U0gXEc983K8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZSQy1v48FI4WQQ3zcU2+E+5o40DyOEc2e/3U02IoD0ZNVXkxD
	HgVr55v2Dy35jeKbk+XDD/Y7UFjiwqT4IuwnGgehKBFbW3Fku8zkpX/VGSGkxfWnVQ==
X-Gm-Gg: ASbGncsguK+dK69VcD7Ck7YiJbFS15pXXEnDiSmM/fsy4Shv/Id3AHFg3tOS93LOMSZ
	m4EH/mDFshq2RZp4W4N+AfNzinapd86ZgUVzWRQkY7B89N4hz+GXWLpoUKmHzAPXbRLqtHe7Pxn
	kofl5cENPIpLF13ba2e0MpUjaBbCtWSH9yV1+my9F9w09/xWcU/7Cy23NI1ZXmSPEegyPrdBL6K
	7mK9xHwk5ZxuL289iHc4E4b1P72tjrsFVICl50gVL/3wyRmnojKRoIyKMmRB8WpX6xaROq8hjSs
	W7tOWThRmfstiZHeFAKB6jjRaM2ChA9vQ5nHAI8FGtLQa8KCc2Nv5FSSwppXD8uwMXG1c2T+dwp
	XgPy7SByrNOYAvfkfuIeqOap+kO3hPgu+Ayqy/pja+Ec=
X-Google-Smtp-Source: AGHT+IG6DURXyjN39csO7ek/9oxUvovLqGCNJ5+sbNMxo1t1w2WR8utDdV/kVM53BL8D62+Okp0p2w==
X-Received: by 2002:a5d:5846:0:b0:3e7:4835:8eeb with SMTP id ffacd0b85a97d-3ee86d6cfbfmr4265889f8f.53.1758314944246;
        Fri, 19 Sep 2025 13:49:04 -0700 (PDT)
Message-ID: <5c495ffc-40c9-4c55-bfba-3e1c0d9955c6@suse.com>
Date: Fri, 19 Sep 2025 22:49:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86: make Viridian support optional
To: Grygorii Strashko 
Cc: Sergiy Kibrik ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250919163139.2821531-1-grygorii_strashko@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250919163139.2821531-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.09.2025 18:31, Grygorii Strashko wrote:
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -62,6 +62,17 @@ config ALTP2M
>  
>  	  If unsure, stay with defaults.
>  
> +config VIRIDIAN
> +	bool "Hyper-V enlightenments for guests" if EXPERT
> +	depends on AMD_SVM || INTEL_VMX

Looks like either there was a misunderstanding, or I wasn't clear enough.
Here the dependency should strictly be HVM. If anything, the dependency
above could appear for HVM (but as said, as of now it's deliberately not
there).

> @@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt(
>      struct viridian_domain *vd = d->arch.hvm.viridian;
>      struct hvm_viridian_domain_context ctxt;
>  
> +    if ( !is_viridian_domain(d) )
> +        return 0;
> +
>      if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> @@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt(
>      struct vcpu *v;
>      struct hvm_viridian_vcpu_context ctxt;
>  
> +    if ( !is_viridian_domain(d) )
> +        return 0;

I don't think we should let these go through, but rather flag an error.
And perhaps an intentionally exotic one (e.g. EILSEQ or something yet
more "odd").

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 21:26:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 21:26:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127071.1468213 (Exim 4.92)
	(envelope-from )
	id 1uzicw-0007fl-4H; Fri, 19 Sep 2025 21:26:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127071.1468213; Fri, 19 Sep 2025 21:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzicw-0007fe-0a; Fri, 19 Sep 2025 21:26:46 +0000
Received: by outflank-mailman (input) for mailman id 1127071;
 Fri, 19 Sep 2025 21:26: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 1uzicu-0007fY-OA
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 21:26: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 55ff0809-959f-11f0-9809-7dc792cee155;
 Fri, 19 Sep 2025 23:26:42 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3ee1381b835so1504894f8f.1
 for ; Fri, 19 Sep 2025 14:26:42 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54ff448058sm5733057a12.54.2025.09.19.14.26.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 14:26: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: 55ff0809-959f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758317202; x=1758922002; 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=4I5EgbgYVa8+ipb8/MYRk2x6DSiwj69u9DDmQY9UWto=;
        b=fuV/UJw2fdIIam9GOGyY7PF1eTdp+wWx+ixunndcArhKgNZlsc0yq+swxJ4Pe5vHNA
         S7cbumnvK9SandYFkUmulzs78DyWyu18Ryr3W9/BXFGcH4spJGb1jC4hXNGaw6TrYc6t
         Lh9royK+R/B1ozlLT5ZD65nCF5sisIvQQRsQssADMdfODGFIkOTUO/Ku1/vtlrw4h0IQ
         0CKUqlkkhR8dxhz519I/TYR7IP/21iOe5LCqBHi2tMSG093iAmDk6IQ/qTanOqyOQUt+
         AgSk6cCvRn0lAxkFc2EEJYEHxKAIZhLrLkcc/wPGo4519WmmOdFrTSWeeZrURnfrpEXP
         BdIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758317202; x=1758922002;
        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=4I5EgbgYVa8+ipb8/MYRk2x6DSiwj69u9DDmQY9UWto=;
        b=CiLhpBR5YSjsq6HBlKLLEDX1mIsye4k8ib/fjeHIJcPWIZm1TsRcway+Xwkz7mjFVY
         8WI6K+plNEnRcogb7jhA33xs9aehDOQRK3ZbWorhKk1GXGYzQJNfhDcArKuTaCZJC1nM
         9FetlVN+kXIiiLkDVLXhhaFjdmPszoZK3bhNzNcBfsE6ej2dHCsqLzC6vzMfpB7gTTz4
         Dj1ku5o26Pv5xVXLih7LEJ0Wmg36JUF6YZXvGjMA8Ol2Y3ZLYoTgnSy/Y6m4FdnduvHa
         v4ydT/nCg1SEGgW1HL95LAisGfbYFkdGMOwJn7D0PPFQ67DeZBa3JjBYVmAe+LYcNXnz
         Ognw==
X-Forwarded-Encrypted: i=1; AJvYcCUYDck29w9c3j9H3KNP8Nm/dvYdt21BJh2ydzxgC6BZCQ93zkKGHJQSi0V50slCIdCfVJK8lNPPaE4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQQ+/tGMCxANAD7djAkkWDTxUuz4KkRIywND3PJnKyoPnVYsYS
	bvYK7TI9Ewb2Q8RGiGRS3xrCAiUmJa8W+p8cVP7Dcld/WqPu74XUiKb92vcbvrNmLw==
X-Gm-Gg: ASbGnctmt9XiQeaV7GghNl6wXy+WVZDWGQGBX02Oq+IThzxKHI6j1j72JU2Ga/dqH6z
	fMPUQCP06xEMaGgQGpCqsiWo+F/EiHqD8Qdrb+Y32Fel1FcuzVMr48bUayknR9OL30A2blSlV7e
	OWnIbh/lfGPNeZJVyvlhmsbHQ7F7ax75ODZZ5yn5jyjFxhGr+cMicHSOTFHI1SF/kBoygyw289D
	R+t+iJPMh7mg/CuRnlu2i76aGdppYbCklNwns3RArzP3LECjaBOAkoRkRyEH2DmQkGmB1DazsrV
	NN34/t8OAjwpjO92YFqTTNu2QW4AE91WIAeRNSVuuk98aYrRQeXZZIHCokT91CyhqcS6fljfKrG
	BLQsvx7FaTsYpWeFHJBDaGU5RtUElKzoA
X-Google-Smtp-Source: AGHT+IEXz0dlCC3Q2Ddr+X2AEvOy8Vz025GNmBoPRcfvcAJ6iMLbzl95AsVpcX5122ycEEPWzxtzmw==
X-Received: by 2002:a05:6000:1ac8:b0:3e7:5f26:f1d3 with SMTP id ffacd0b85a97d-3ee7df1d066mr3713916f8f.17.1758317201885;
        Fri, 19 Sep 2025 14:26:41 -0700 (PDT)
Message-ID: <03c68390-fd9b-443b-a012-2846dda2a923@suse.com>
Date: Fri, 19 Sep 2025 23:26:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/18] xen/riscv: introduce 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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> @@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>  
>      gstage_mode_detect();
>  
> +    vmid_init();

Like for the earlier patch, I'm not convinced this is a function good
to call from the top-level start_xen(). The two functions sitting side
by side actually demonstrates the scalability issue pretty well.

> --- /dev/null
> +++ b/xen/arch/riscv/vmid.c
> @@ -0,0 +1,193 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Xen command-line option to enable VMIDs */
> +static bool __ro_after_init opt_vmid_use_enabled = true;
> +boolean_param("vmid", opt_vmid_use_enabled);

Is there a particular reason to not have the variable be simply opt_vmid,
properly in sync with the command line option?

> +void vmid_init(void)
> +{
> +    static int8_t g_vmid_used = -1;
> +
> +    unsigned int vmid_len = vmidlen_detect();
> +    struct vmid_data *data = &this_cpu(vmid_data);
> +
> +    BUILD_BUG_ON((HGATP_VMID_MASK >> HGATP_VMID_SHIFT) >
> +                 (BIT((sizeof(data->max_vmid) * BITS_PER_BYTE), UL) - 1));
> +
> +    data->max_vmid = BIT(vmid_len, U) - 1;
> +    data->used = !opt_vmid_use_enabled || (vmid_len <= 1);

Since you inverted the sense of variable and field, you also need to invert
the expression here:

    data->used = opt_vmid_use_enabled && (vmid_len > 1);

> +    if ( g_vmid_used < 0 )
> +    {
> +        g_vmid_used = data->used;
> +        printk("VMIDs use is %sabled\n", data->used ? "dis" : "en");

Same here - "dis" and "en" need to switch places.

> +    }
> +    else if ( g_vmid_used != data->used )
> +        printk("CPU%u: VMIDs use is %sabled\n", smp_processor_id(),
> +               data->used ? "dis" : "en");

And again here.

> +void vcpu_vmid_flush_vcpu(struct vcpu *v)

An reason to have two "vcpu" in the name?

> +{
> +    write_atomic(&v->arch.vmid.generation, 0);
> +}
> +
> +void vmid_flush_hart(void)
> +{
> +    struct vmid_data *data = &this_cpu(vmid_data);
> +
> +    if ( data->used )
> +        return;

Again the sense needs reversting.

> +    if ( likely(++data->generation != 0) )
> +        return;
> +
> +    /*
> +     * VMID 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("%s: VMID generation overrun. Disabling VMIDs.\n", __func__);
> +    data->used = 1;

And yet again.

> +bool vmid_handle_vmenter(struct vcpu_vmid *vmid)
> +{
> +    struct vmid_data *data = &this_cpu(vmid_data);
> +
> +    /* Test if VCPU has valid VMID. */
> +    if ( read_atomic(&vmid->generation) == data->generation )
> +        return 0;
> +
> +    /* If there are no free VMIDs, need to go to a new generation. */
> +    if ( unlikely(data->next_vmid > data->max_vmid) )
> +    {
> +        vmid_flush_hart();
> +        data->next_vmid = 1;
> +        if ( data->used )
> +            goto disabled;

And yet another time.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 21:43:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 21:43:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127085.1468223 (Exim 4.92)
	(envelope-from )
	id 1uzisp-0001t2-CS; Fri, 19 Sep 2025 21:43:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127085.1468223; Fri, 19 Sep 2025 21:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzisp-0001sv-9p; Fri, 19 Sep 2025 21:43:11 +0000
Received: by outflank-mailman (input) for mailman id 1127085;
 Fri, 19 Sep 2025 21:43: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 1uzisn-0001sp-6v
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 21:43:09 +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 a16ca53e-95a1-11f0-9d14-b5c5bf9af7f9;
 Fri, 19 Sep 2025 23:43:08 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3f42b54d1b9so44025f8f.0
 for ; Fri, 19 Sep 2025 14:43:08 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-32ed2685793sm9249128a91.5.2025.09.19.14.43.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 14:43:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a16ca53e-95a1-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758318187; x=1758922987; 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=nW8KJRWbZ6hFlOoFBWjVICnwu/SIoZCAWVK/u8Gpej8=;
        b=I0pK/YXNh1sUsZ7kKfhRf6jvW5/QJtS18Bap/++09kiZlqQ0qP54qSc4wT+S8hebVa
         TYHmXwPf9C9vjJFaDW3upiVeeQ6SZob60edcYr0esvEqCv8qZ2Q3pFWfoDgyDxEhf2eM
         DWRkTMtqNQfbhwabzGgDOk5oyFU5Nazw6t1PzWb16vfxyZxqOrG2bMaqdA3ro0zJzw8J
         FCwHpuQir1khROSEvPUL2hDBN52a4iNTvaBAxMXeYxNKxtQGrXf2eXTkiULo4kegCVmu
         zIKxt6YWtFYdqEgEOc85CiyRacICw3WlSoGvOkquoKLXqzGiRtx+pfBuwFrT6vA8fZnf
         ZEzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758318187; x=1758922987;
        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=nW8KJRWbZ6hFlOoFBWjVICnwu/SIoZCAWVK/u8Gpej8=;
        b=FBeO3eEId/oLUQLzDUEM55C+EtYmLaib5H5prbHZfp7kWkXCe86NR1VVULGzLHkwbU
         LiNaRIl3aO7OJhM1VHSdbtgb4+COS9T/Wwkz9Akk9l0mx8AntqCtZHSD66LPQ8cXOumC
         bpCx456o9iiA2VsprMFemyn1zoKvIIuyNdevVhzQCypYvDBp47T0aqhkmfCWBf04oRC7
         C0A74OAH2prpCXsRw6CsDA9l38Ei0DnwCQFgdEgc4h2iGlwT4y5JD7PszxLfzZv+sNjZ
         AlazZlABaxUBfLUr3Re0bqu7CRkJOXnK8M9QyQqtIJV8VRe6XtnAe7W2Ne+KE5nj1Ijq
         pqNw==
X-Forwarded-Encrypted: i=1; AJvYcCU1jHQqPv0QSuc0ZxVnHt+dCErYQdB3y07sEVFsNo5QsMXeZayILJzr5/SJTs+9eR9mUjnJ5qOBkrw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZrmFlN2GCyrpY6T2VOtdO0ik75T2QUz/ViYTG0+lgfeRfbPNz
	UNlq1wh1s3eVB3GMrypKelVqPRnUWHzrpIHwyZgya3LKvgU59WYpXijS0AF6u4ueDw==
X-Gm-Gg: ASbGnct9T+oI9hkKASs2NKD7JWgU0jMpHSwU7wUJXIBH69H7AJ+EAtR9xCZiuXKvIlZ
	t8ylkVl1HFUoRf8Br2K+4QuuYYJCYtBuG+fqC+MDGXSglpGXzEs1o4KlI0Bwnyh1uQdNuG1UCS8
	GA9OHXrYvZBolaD5xyZn7zeBaTnBhMbSuOu8KtF/g4G3lMyoM9rxhzAACisECgTRXxBAgAVls0H
	2hHXDp1C7lD9Pvz69rlmngf8zeXfY6fX5gVtTYJIkU3zigVii4RNjqT/aa7UbIztIzxmyr2x2mh
	8aQ+tWJ/ku8BphreV1+NWPWtitNdHL4EX1TTc3U7I4g/p48rgchriUQNvGIZcKKyKY+ss0BKuVS
	Dbx/cbCRsV+nETPLX+LrnQx0IbFVdT8Kf
X-Google-Smtp-Source: AGHT+IFPqfVh4eLEH0inY9OUEi2OeJe87qiwA2QzEijZdpZLmGepMTRXLvdh1tV1722OkjEDsAfUDQ==
X-Received: by 2002:a05:6000:1ac8:b0:3e1:734b:5393 with SMTP id ffacd0b85a97d-3ee7ea92d70mr4194843f8f.28.1758318187467;
        Fri, 19 Sep 2025 14:43:07 -0700 (PDT)
Message-ID: 
Date: Fri, 19 Sep 2025 23:43:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/18] 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: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, 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.
>   - back pointer to domain structure.
> - p2m_init() to initalize members introduced in p2m_domain structure.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri Sep 19 22:14:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 22:14:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127115.1468233 (Exim 4.92)
	(envelope-from )
	id 1uzjMp-0005sW-Sr; Fri, 19 Sep 2025 22:14:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127115.1468233; Fri, 19 Sep 2025 22: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 1uzjMp-0005sP-QC; Fri, 19 Sep 2025 22:14:11 +0000
Received: by outflank-mailman (input) for mailman id 1127115;
 Fri, 19 Sep 2025 22: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 1uzjMo-0005sJ-Km
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 22:14:10 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f6c59c62-95a5-11f0-9d14-b5c5bf9af7f9;
 Sat, 20 Sep 2025 00:14:09 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3f2ae6fadb4so445606f8f.1
 for ; Fri, 19 Sep 2025 15:14:09 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b551518480asm3703933a12.28.2025.09.19.15.14.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 15:14: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: f6c59c62-95a5-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758320048; x=1758924848; 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=8f4zoi5bjYWcV0t8htaNaF+7Q44g0kcNscqk/LR0FhY=;
        b=BdEX2efAoyWy7L1q9dTmZdihHftyl6SN9/K5Z1FcMH19mZ3O5vwlxvrzvozJjZeaQW
         fBnYFqUXHP0Pvc5/Iq3Y5Bx8rcrwyWVEl9BF6lqA1eOzZ5CGogu1/XO5B15zK2SjJDyM
         eMfoggwOaQSO7i9JHmCh8tTwiYMJX6hrkdvXEX541bvPzJ5spL+jqhCC9o+72E/5L4/a
         xJfAPvucfWXSQ5JcX8dFM1jfYAovIhiqqjk9Iqj2QP5DxtAzwc7tWTvvruznuSzN6cBY
         m4L1VwsFGYwREaj6rPT9kOyeDzMg5JMaM2ZNye2IoqjaHs3KjpUxmZgwhpvXralh7erN
         7gZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758320048; x=1758924848;
        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=8f4zoi5bjYWcV0t8htaNaF+7Q44g0kcNscqk/LR0FhY=;
        b=MOPsFOuBHNEeyOWnrUa17nvNOJfXAJMBJwYZ5b1PdNNks2RB6LmBIdnbO9iGOnXFh8
         GVZwtjp0aJMy9yBR53cfbYIOZEAfOh0CFuL8NAj+PuWQiQIFtSy0FFMiwA+BU/pH0YpJ
         zfrfl0PIhtexLeN58KwmuTcip8jt3dhypb+LqKxOo2oLFagXqm31fv+OfHnZ83u93wwG
         GAZAlgxfBhc7uiR0ISl06cuwq9JNmp1iCdxqweyAuDofF4FrVnUJwroY3DtlU4AxjssM
         LTMhqUw3M53qkdZZMJUzGDha63IsCjoQQFtNWxdc66zmhZv8U0MrzyzYYz5gWv3ozwMj
         W4Gg==
X-Forwarded-Encrypted: i=1; AJvYcCVIc5tA2YX1aYLCONrJPwpIaYILb4+C6jpUl+Zam8uNHIZN4MLMrIhJsWOm/F/sOfAApUJeDGVL/5o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKczFq4i/mSeAcptwGFtm0yizO3FKR4YP9l9+0V5isNhYWuVlp
	y8/8V9pAZ63UVD1ZMHm7YwRr0BObRJ052q7WqQ3hbYdg4MykwSlrTPcOMRhCTZFzYw==
X-Gm-Gg: ASbGncsewQ3n2b4W/1yh+uIyJXNxItvh8d4erW30ImDcwxoYGvZa7ffjwQVt9YkiquR
	8qjIglJjwZhX3Uq7xxJB8iSP/FuSZCQQAY/NP2AsXU8+drQceLn+zO/1a9S1A0ukO+E1+AVUvzE
	OeHj/+gCwk7tkqI6aLKFMuKKMe12np+KqRuz8R28Cy5SnuApF683Y4yDhYyQu5xjDjye/PfuyIx
	OYXAxPJ0AFyc5rcjjKbc+EwWW7U9CD/ghcbFbAoUibTeXCflIgM2k/mX7hEARty+aKyA/wvo0NN
	6vvTotDEDC6KLP8JZV1vKc/DAUXDqV7aOXJARTOousXQ9gOGd31SL2Iq36sToCe6xAiM9GnIyQ5
	SkUYt1dxqJ3HIk0yYffdaHJXcaWQzIYIZ
X-Google-Smtp-Source: AGHT+IF882BimS8eh/HKXC0JYo7P1gFUQXLFf+gzEej7W7pLAjcbJGZR+IE9CUPXYafGsg6q3mYN7g==
X-Received: by 2002:a05:6000:2285:b0:3ea:a694:ae0a with SMTP id ffacd0b85a97d-3ee852a4b54mr3948866f8f.48.1758320048598;
        Fri, 19 Sep 2025 15:14:08 -0700 (PDT)
Message-ID: 
Date: Sat, 20 Sep 2025 00:14:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/18] 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: 
 <2b636ea03bf82cae50df87d525e3f58b68f16cb2.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <2b636ea03bf82cae50df87d525e3f58b68f16cb2.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -3,6 +3,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -95,6 +96,70 @@ void __init gstage_mode_detect(void)
>      local_hfence_gvma_all();
>  }
>  
> +static void clear_and_clean_page(struct page_info *page, bool clean_dcache)
> +{
> +    clear_domain_page(page_to_mfn(page));
> +
> +    /*
> +     * If the IOMMU doesn't support coherent walks and the p2m tables are
> +     * shared between the CPU and IOMMU, it is necessary to clean the
> +     * d-cache.
> +     */
> +    if ( clean_dcache )
> +        clean_dcache_va_range(page, PAGE_SIZE);
> +}
> +
> +unsigned long construct_hgatp(struct p2m_domain *p2m, uint16_t vmid)

pointer-to-const?

> +{
> +    return MASK_INSR(mfn_x(page_to_mfn(p2m->root)), HGATP_PPN) |
> +           MASK_INSR(gstage_mode, HGATP_MODE_MASK) |
> +           MASK_INSR(vmid, HGATP_VMID_MASK);
> +}
> +
> +static int p2m_alloc_root_table(struct p2m_domain *p2m)
> +{
> +    struct domain *d = p2m->domain;
> +    struct page_info *page;
> +    int rc;
> +
> +    /*
> +     * Return back P2M_ROOT_PAGES to assure the root table memory is also
> +     * accounted against the P2M pool of the domain.
> +     */
> +    if ( (rc = paging_ret_pages_to_domheap(d, P2M_ROOT_PAGES)) )
> +        return rc;

I read the "ret" in the name as "return" here. However, ...

> +    /*
> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
> +     * 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, P2M_ROOT_ORDER, MEMF_no_owner);
> +    if ( !page )
> +    {
> +        /*
> +         * If allocation of root table pages fails, the pages acquired above
> +         * must be returned to the freelist to maintain proper freelist
> +         * balance.
> +         */
> +        paging_ret_pages_to_freelist(d, P2M_ROOT_PAGES);

... "return" doesn't make sense here, so I wonder what the "ret" here means.

> @@ -55,6 +76,37 @@ int paging_freelist_adjust(struct domain *d, unsigned long pages,
>      return 0;
>  }
>  
> +int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages)
> +{
> +    ASSERT(spin_is_locked(&d->arch.paging.lock));
> +
> +    for ( unsigned int i = 0; i < nr_pages; i++ )
> +    {
> +        int rc = paging_ret_page_to_freelist(d);
> +        if ( rc )

Nit (style): Blank line between declaration(s) and statement(s) please.

> +            return rc;
> +    }
> +
> +    return 0;
> +}
> +
> +int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages)
> +{
> +    ASSERT(spin_is_locked(&d->arch.paging.lock));
> +
> +    if ( ACCESS_ONCE(d->arch.paging.total_pages) < nr_pages )
> +        return false;
> +
> +    for ( unsigned int i = 0; i < nr_pages; i++ )
> +    {
> +        int rc = paging_ret_page_to_domheap(d);
> +        if ( rc )

Same here.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 22:18:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 22:18:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127131.1468243 (Exim 4.92)
	(envelope-from )
	id 1uzjRC-0006Yq-Ej; Fri, 19 Sep 2025 22:18:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127131.1468243; Fri, 19 Sep 2025 22:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzjRC-0006Yj-BD; Fri, 19 Sep 2025 22:18:42 +0000
Received: by outflank-mailman (input) for mailman id 1127131;
 Fri, 19 Sep 2025 22:18:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzjRB-0006Yd-3x
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 22:18:41 +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 98272faa-95a6-11f0-9d14-b5c5bf9af7f9;
 Sat, 20 Sep 2025 00:18:40 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ee12a63af1so1241595f8f.1
 for ; Fri, 19 Sep 2025 15:18:39 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77f1550f890sm1219235b3a.94.2025.09.19.15.18.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 15:18: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: 98272faa-95a6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758320319; x=1758925119; 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=baPEA6cf+OKNa1p61wS3dSmn5pKTAbVkmCQSRs6VlJ4=;
        b=PvhiY81Q3YN6GxETETQVB8TJrjJvwa/aE6unl0oqKzWNyL2C7xydmfa2bwh0AVjqjf
         cScQl2hBuQVlk/r/8UCOu9L1SuNKiYNfs5CferInASkcKjOtSjFOQBD/Ou7ylj68FvXY
         31Ml0HWMi28iRDis6OZEO3m79KWlbwoUVW1bKvFfqAsOXLLTgRXSbNBHN3ctzzwwC/Ty
         HqQYjQl59AFnFwmQ6XbWMPajWBmjN7GvLvLdZOzWJsyEJyUnneRXz+lrPMYA3XByibzz
         ftnPVf2CUVNZc9QRdgL6KE/Aj2197PujxcAisDJYpfCQJV1kTBNGDxyogXKYlIS54Iu5
         Jbhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758320319; x=1758925119;
        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=baPEA6cf+OKNa1p61wS3dSmn5pKTAbVkmCQSRs6VlJ4=;
        b=m3MDchTAbV+Dg7gYoFtKM0KRu5l2xfSlpCcIZj6MnORxZLQhPI8FKgXTZoc36mHLPo
         mUS01/J4EwSenOiSfxeBTym6OrkPvmrMSEdiOfg9mDYkdRrteDhZG2TQ74FUo56uBPgt
         FeJ6M6TFNxEL53gEF0qELF2KRT8n4NXjkD4RYE3gqhYXH5WkJgi6bGPjSxAUH1xP2HgX
         PhLal7oNn4DYX4DPOR87XO4ntWvTrWrbQaJJwmNx5HggOW/fCVJkFbdUSmSPiSjpdbL4
         W4ji0mKTIXi0O/L0ViczrBuoNC7C7qzogqgZqCuCvsk9oEXQAZbrVXKbVtY5NVc9uUrH
         y8jQ==
X-Forwarded-Encrypted: i=1; AJvYcCXQ1zRokcwvJiAoxqHb4hak8f7Yz70Hr5u0CFONDdezCQZV7kVOoBcjtPTcn4Kh/jJH9ompjYMhJzI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQHh+ddqUnQ8YUvPm+73BpQl2WTXHrelfTY2E/YB1r5apBiIOQ
	LXD4iE3eOxXd95Qjv+clIzo0MWnwHndqfrhjF4aSeU6v8tVVPaKkO8qxEpMZpo+qLw==
X-Gm-Gg: ASbGncumF4t6ERdvZiYQHA7kcbI3dtOPj50z82fdgjjU/BqmfCbla6rzwx7IF29jNH5
	Hugo2XLHB6fVuKPSZrbtO3DUMNlIyDOfQj5HgpaZONxhtRKOq7f0LFEoSK7Y35Ye+BPwIsTkGW3
	YjN5EgkKTrUDBAJOhA6KDzhO0VFirN2rPhGjZZuXxVL4ETBmOZcwLLgO/HrZdC+zvAQgpEHOYO1
	JVTaH9n4ZXhR281AhpzOS7LDeMR1oaUydC7R9p841FpWJ0QvJE/qowU/Ga2vZ6nFK+ZIaIJ/o5X
	4x7YTISkzXJQoLAXPnj7v/Qnu6iXt5+a1eo5D8l8V5xg6elx0ZglxiYpi2qU9kAjDXLZkAIx/Kn
	J7gl1v/DnYjm7kuj+xJnQY0yDNPrzR+cN07v7raN0px0=
X-Google-Smtp-Source: AGHT+IHtHES68iwcfr3MwCv3K44afpRZswTm4gwrCyRSXpXMm1rNMskjjkIvjw4jwJdJ+BsAYaFDYA==
X-Received: by 2002:a05:6000:1a8b:b0:3ea:80ec:854c with SMTP id ffacd0b85a97d-3ee7d0c8adbmr3929036f8f.19.1758320319301;
        Fri, 19 Sep 2025 15:18:39 -0700 (PDT)
Message-ID: <94703a57-aef4-4d74-af36-03b4b2bea666@suse.com>
Date: Sat, 20 Sep 2025 00:18:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 07/18] 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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> - Extended p2m_type_t with additional types: p2m_mmio_direct,
>   p2m_ext_storage.
> - Added macros to classify memory types: P2M_RAM_TYPES.
> - Introduced helper predicates: p2m_is_ram(), p2m_is_any_ram().
> - Introduce arch_dt_passthrough() to tell handle_passthrough_prop()
>   from common code how to map device memory.
> - Introduce p2m_first_external for detection for relational operations
>   with p2m type which is stored outside P2M's PTE bits.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V4:
>  - Drop underscode in p2m_to_mask()'s argument and for other similar helpers.

Except that ...

> --- a/xen/arch/riscv/include/asm/p2m.h
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -64,8 +64,29 @@ struct p2m_domain {
>  typedef enum {
>      p2m_invalid = 0,    /* Nothing mapped here */
>      p2m_ram_rw,         /* Normal read/write domain RAM */
> +    p2m_mmio_direct_io, /* Read/write mapping of genuine Device MMIO area,
> +                           PTE_PBMT_IO will be used for such mappings */
> +    p2m_ext_storage,    /* Following types'll be stored outsude PTE bits: */
> +
> +    /* Sentinel — not a real type, just a marker for comparison */
> +    p2m_first_external = p2m_ext_storage,
>  } p2m_type_t;
>  
> +static inline p2m_type_t arch_dt_passthrough_p2m_type(void)
> +{
> +    return p2m_mmio_direct_io;
> +}
> +
> +/* 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))
> +
> +/* 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)

... they're still present here. With these also dropped:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 23:12:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 23:12:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127155.1468252 (Exim 4.92)
	(envelope-from )
	id 1uzkH4-0005Va-58; Fri, 19 Sep 2025 23:12:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127155.1468252; Fri, 19 Sep 2025 23:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzkH4-0005VT-2K; Fri, 19 Sep 2025 23:12:18 +0000
Received: by outflank-mailman (input) for mailman id 1127155;
 Fri, 19 Sep 2025 23:12: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 1uzkH2-0005VN-Nd
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 23:12:16 +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 1432c0ae-95ae-11f0-9809-7dc792cee155;
 Sat, 20 Sep 2025 01:12:14 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3ee13baf2e1so1797622f8f.3
 for ; Fri, 19 Sep 2025 16:12:14 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2698019730dsm66047435ad.63.2025.09.19.16.12.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 16: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: 1432c0ae-95ae-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758323534; x=1758928334; 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=b5qMQhkQeGpHEygJsBFZiEEDWkyBSngSeyf238ocapg=;
        b=L7xumqCsQs2n1/lpgwfXW/Chc8B8zy8x2EKI3JpO4fz6ewJBUrWA7qN/pJSD53LNsx
         IRp3EaB8p5colwkkTyFG3eyTSb8GoDNPRWWPFjfI+81hr0U5hfrkLDy3otBcqwFy622Z
         2pCK0ffL1SoIlBrVeNWr2O8PRXV2aUIvdU/6ygEudDlDaa/AH4YPu63XzBa9HvWbIWgW
         78n2yoVnj+GMVY2QJ3wR6EZsh0zvlLQ4sCL1L7ZSwgkXVvo7BVZULZZ44BJ54CSx5OP0
         uoGDNvPCQZD0HA7tWUzRW7OUIMpX+TgsM3MK5NLMxYnYUYqgAVqsVnjA7idaSIyaQutu
         bijQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758323534; x=1758928334;
        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=b5qMQhkQeGpHEygJsBFZiEEDWkyBSngSeyf238ocapg=;
        b=s0VXdKzcC+skei60Meems8FzbjDC+dEImqC2+b78G23tDd8S74dQoKa/0QYzhkughg
         l/gbUdwFFHAs2H8hjMNEzqraXaAl9Okn9mcAjPTRAPpF7vzRSPhXnxxKwP0ChR14T5yj
         LxcPLz8RLIIUtpaMsPse8wwAT7m1j6Az40UowgqiVq1+uMzDVN3r3vYtsVB2HzVM7FvB
         vMQS2XpiDvZ5DZUBlNRs45wyW3FweMZXrwTeJZzCIvytGdGw+2MsNmzm8MjD/PPR1lgZ
         YZy+L/cKGiGLwzKF9VJWwXv3dr/x7sBpokLFdStom3yZAAWlddOnR+HsaY+R2jDWIHL4
         ZG7g==
X-Forwarded-Encrypted: i=1; AJvYcCUjt9PtZRx0iO6Ku8BeWPcEkxSjG8GethVwluDlJzXG5fqi9tyEoXG9/a1T8KciUlYMfjzU7c9MGr8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0SZv8Noly+0rey7vC7mg8hku2CW/zC9hwB95J5lSRhSrIse92
	zdaj1QRuApRWUGZN9/6+G/To2C9JUU9FKIzgkQoyz1jj4y3ClkytrYljNtgQgiFHqA==
X-Gm-Gg: ASbGncv7iuD1L9jgxIJRFHcApY9MuvE4VjYvCj67U/woRiIrwbZYvMg4NVswlqaBqq/
	pbPESl97/5NZW/oAD35/MzJqFai0CXr6SNH0AmcoHnEbTYO5KuVu2lQmq8EeE8ckmzLVzh0MMl2
	xEDNK/r1tVK3FtdpwPo0MG2CrLfDNp0zLCb0q9QX1mvCf4exUjXV0Qn3VIoL6aMRWQmhJcHUYFb
	xfRr8sPRPlEFJUXos3X6mxE9QV9DlZs03fso+ruPjXV0oqloX75rvkiMeR/0LPesZIebB84aI96
	s1+iPlxoMeRAJBAUhtLR1lEtqN7WyJHTdtf4qhe1RpPLKJzS/RXkMyXFW0uMlHpFZZFLaxz/oDL
	PHtUjikrnKFc90tLnXWPLYi4+CNE37gUn
X-Google-Smtp-Source: AGHT+IFfwLjxIJ020kbVMv48PnOuhEq0e7ktnQ6KZ5NGyk9xl+05mkejAx6olEhlmychQkvUhYmY/w==
X-Received: by 2002:a05:6000:2f83:b0:3d9:7021:fff0 with SMTP id ffacd0b85a97d-3ee8481fe2amr3258860f8f.37.1758323533980;
        Fri, 19 Sep 2025 16:12:13 -0700 (PDT)
Message-ID: <031a4dfd-6e4c-4373-b064-f87906ef85a1@suse.com>
Date: Sat, 20 Sep 2025 01:12:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 09/18] xen/riscv: implement function to map memory in
 guest p2m
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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -96,6 +96,41 @@ void __init gstage_mode_detect(void)
>      local_hfence_gvma_all();
>  }
>  
> +/*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
> + */
> +static void p2m_tlb_flush(struct p2m_domain *p2m)
> +{
> +    const struct domain *d = p2m->domain;
> +
> +    ASSERT(p2m_is_write_locked(p2m));
> +
> +    sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
> +
> +    p2m->need_flush = false;

While with the p2m lock held it shouldn't matter, purely for doc
purposes I would recommend to clear the flag before doing the flush.

> +/* Unlock the flush and do a P2M TLB flush if necessary */

Don't you mean "P2M" in place of the first "flush"?

Ideally with both adjustments:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 23:36:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 23:36:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127175.1468263 (Exim 4.92)
	(envelope-from )
	id 1uzkef-0008NF-12; Fri, 19 Sep 2025 23:36:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127175.1468263; Fri, 19 Sep 2025 23: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 1uzkee-0008N8-UE; Fri, 19 Sep 2025 23:36:40 +0000
Received: by outflank-mailman (input) for mailman id 1127175;
 Fri, 19 Sep 2025 23:36:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzkec-0008N2-QZ
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 23:36:38 +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 79c70d95-95b1-11f0-9809-7dc792cee155;
 Sat, 20 Sep 2025 01:36:33 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3e9042021faso1934019f8f.3
 for ; Fri, 19 Sep 2025 16:36:33 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-26980053201sm66193015ad.17.2025.09.19.16.36.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 16:36: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: 79c70d95-95b1-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758324993; x=1758929793; 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=/oRXW3JGWAIM3WD61rtwJF5PiZxqPQvTEOg1PZaCEEU=;
        b=OJ213T9i0rLAHKS3RXK2WuJRnRxTXyyzonyMh2J2b4Nlc3KqdyjEilUWqh+hsDOyFi
         ofLbqTI/j5Jx7zlDQS0iriJfkSkctpk5qALtYgzbzHptUpxKl1BW+g1CFzCSYBz14t1U
         iodFDI+IJCoGRLvFoGjUnwq5B3glsNO4v/4CELg4QtYT5kRPOF3k0iSGv49YYlhKYnkk
         vBiVGigRaWSsycFKs2eZyjZECVKYf63a46fCJT5yhD7SAYnyc51Gxw/xAlMNMBIQCBVb
         HaFaIwM9YUBB5pI7zWruuAq/MTZJ/LpJ8Qood7iLp6pI6YTFQte2zMWXuTxtKdJN1CCw
         U1gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758324993; x=1758929793;
        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=/oRXW3JGWAIM3WD61rtwJF5PiZxqPQvTEOg1PZaCEEU=;
        b=Zac6Y2xpxdu0fM0gjjS9UCj33a4R9gVdnC3+7fmweE4tXmGOrITyb40N1JZp2eg4Un
         g/AvPwT0YtIJjbpDJgnfcEGBmwB0/vu2zxyidjpkmEvL2Yk68hzeq1odccJyWjcqDUNH
         pPZ0GoEM1y8mpeqSH7vmAJ6DqJATf2nPlKc265XB3PHJLtbZZmw6zKDGKSHQMSElvfQr
         nww5C1WmPru0U4HV6h5rHZn8KdbSXsxNVqM4XHiKXbkSbdO43Iq2H7GE7/xNG33S8LEt
         i9F5uYn98HIA95WWed1VgKf4LEeBk87Na6nKZeQj9N4XiKSsCUnNMa6BedCTC+boSFWB
         mgbw==
X-Forwarded-Encrypted: i=1; AJvYcCVG1ie2f5M3couJjXS9r2zQCbyjAfGl0zoFryc/OpufxCevSmFXH9sCj8R+/hmC4QA299fnbnbrSVE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFFJG1ER8UTZGfL1jlbLWJix2X+6D4n3bjlExFnM3LTTOjUAPL
	qnqwvdgabZIm30QU95UwS2adAPdjrKBTdYVsdtEOwNCxjzKBt7L1VSYxvev0Xx9OoA==
X-Gm-Gg: ASbGncugXStTq/27CWdWa2IYAJ+d4iIjNbYyzeW7jQyQHt/MKcgnK7tml5uuOvSssL6
	EAoIcgw+qW1hN5j8o8lIjdw5bwcu8pTqP2qWpGa5bXdyxi5OgxAM5jKnofDuIqkTyO48Gq8WZ56
	GtaMgOS7Q0/oKhwgSSDMOYxa0gd6fyB0PLvVWHR7Jm9jNU+B6PtZEGm2gMFcr17EbAIvdsb+7g8
	/Hd3+wiu2kaovpJvIEtQYb7GDcu9Kdt7muG65spkrvYM4D2LwW/e2kNZQvHUr3z+fJsqivvUugH
	ymmoe5npo8Wst3Mh+MhiCObVg7lti+dHJxhMX6OJn47J5wj+E97SKHYttNi3fpmY3EBLM2aV/Fz
	BlLtadQfaj56oi2D7MyoWPTDzIGLFBtxT
X-Google-Smtp-Source: AGHT+IFpkHa7Fsng17P8IJk3bs+GZMuCgLISa7SuZxI9lIejC768Dz9aEaaztOCpQP2poS6HE3p8sA==
X-Received: by 2002:a05:6000:605:b0:3ea:5f76:3f7a with SMTP id ffacd0b85a97d-3ee7e0116d6mr2956081f8f.22.1758324992752;
        Fri, 19 Sep 2025 16:36:32 -0700 (PDT)
Message-ID: <6ee4846e-dd27-4588-aac5-f2fe2937db18@suse.com>
Date: Sat, 20 Sep 2025 01:36:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/18] xen/riscv: implement p2m_set_range()
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: 
 <5e325267a792a9a0f4cb387b4e3287d22dc8d173.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <5e325267a792a9a0f4cb387b4e3287d22dc8d173.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  unsigned long __ro_after_init gstage_mode;
> +unsigned int __ro_after_init gstage_root_level;
>  
>  void __init gstage_mode_detect(void)
>  {
> @@ -53,6 +54,7 @@ void __init gstage_mode_detect(void)
>          if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode )
>          {
>              gstage_mode = mode;
> +            gstage_root_level = modes[mode_idx].paging_levels - 1;
>              break;
>          }
>      }
> @@ -210,6 +212,9 @@ int p2m_init(struct domain *d)
>      rwlock_init(&p2m->lock);
>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>  
> +    p2m->max_mapped_gfn = _gfn(0);
> +    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
> +
>      /*
>       * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
>       * is not ready for RISC-V support.
> @@ -251,13 +256,287 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>      return rc;
>  }
>  
> +/*
> + * Find and map the root page table. The caller is responsible for
> + * unmapping the table.

With the root table being 4 pages, "the root table" is slightly misleading
here: Yu never map the entire table.

> + * The function will return NULL if the offset into 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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
> +    if ( root_table_indx >= P2M_ROOT_PAGES )
> +        return NULL;
> +
> +    /*
> +     * The P2M root page table is extended by 2 bits, making its size 16KB
> +     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
> +     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
> +     * only allocates 4KB pages).
> +     *
> +     * To determine which of these four 4KB pages the root_table_indx falls
> +     * into, we divide root_table_indx by
> +     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
> +     */
> +    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);

The subtraction of 1 here feels odd: You're after the root table's
number of entries, i.e. I'd expect you to pass just P2M_ROOT_LEVEL.
And the way P2M_PAGETABLE_ENTRIES() works also suggests so.

> +/*
> + * Insert an entry in the p2m. This should be called with a mapping
> + * equal to a page/superpage.
> + */

I don't follow this comment: There isn't any mapping being passed in, is there?

> +static int p2m_set_entry(struct p2m_domain *p2m,
> +                           gfn_t gfn,
> +                           unsigned long page_order,
> +                           mfn_t mfn,
> +                           p2m_type_t t)

Nit: Indentation.

> +{
> +    unsigned int level;
> +    unsigned int target = page_order / PAGETABLE_ORDER;
> +    pte_t *entry, *table, orig_pte;
> +    int rc;
> +    /*
> +     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
> +     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
> +     * are still allowed.
> +     */
> +    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
> +    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
> +
> +    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, gfn);
> +    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
> +        {
> +            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
> +            /*
> +             * 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).

I thought I commented on this or something similar already: Calling the
p2m tree "read-only" is imo misleading.

> It is a valid case
> +             * when removing a mapping as it may not exist in the
> +             * page table. In this case, just ignore it.

I fear the "it" has no reference; aiui you mean "ignore the lookup failure",
but the comment isn't worded to refer to that by "it".

> +             */
> +            rc = removing_mapping ? 0 : rc;
> +            goto out;
> +        }
> +
> +        if ( rc != P2M_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;
> +
> +    if ( removing_mapping )
> +        p2m_clean_pte(entry, p2m->clean_dcache);
> +    else
> +    {
> +        pte_t pte = p2m_pte_from_mfn(mfn, t);
> +
> +        p2m_write_pte(entry, pte, p2m->clean_dcache);
> +
> +        p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
> +                                      gfn_add(gfn, BIT(page_order, UL) - 1));
> +        p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, gfn);
> +    }
> +
> +    p2m->need_flush = true;
> +
> +    /*
> +     * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
> +     * is not ready for RISC-V support.
> +     *
> +     * When CONFIG_HAS_PASSTHROUGH=y, iommu_iotlb_flush() should be done
> +     * here.
> +     */
> +#ifdef CONFIG_HAS_PASSTHROUGH
> +#   error "add code to flush IOMMU TLB"
> +#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 previously MFN 0 was mapped and it is going to be removed
> +     * and considering that during removing MFN 0 is used then `entry`
> +     * and `new_entry` will be the same and p2m_free_subtree() won't be
> +     * called. This case is handled explicitly.
> +     */
> +    if ( pte_is_valid(orig_pte) &&
> +         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
> +          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
> +        p2m_free_subtree(p2m, orig_pte, level);

I continue to fail to understand why the MFN would matter here. Isn't the
need to free strictly tied to a VALID -> NOT VALID transition? A permission
change simply retains the VALID state of an entry.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 19 23:58:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Sep 2025 23:58:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127202.1468273 (Exim 4.92)
	(envelope-from )
	id 1uzkzD-0002sG-Q1; Fri, 19 Sep 2025 23:57:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127202.1468273; Fri, 19 Sep 2025 23:57:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzkzD-0002s9-MJ; Fri, 19 Sep 2025 23:57:55 +0000
Received: by outflank-mailman (input) for mailman id 1127202;
 Fri, 19 Sep 2025 23:57: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 1uzkzC-0002s3-PZ
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 23:57:54 +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 74202c78-95b4-11f0-9809-7dc792cee155;
 Sat, 20 Sep 2025 01:57:52 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ee15505cdeso1549401f8f.0
 for ; Fri, 19 Sep 2025 16:57:52 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b54ff445dd7sm5899543a12.51.2025.09.19.16.57.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 19 Sep 2025 16:57:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 74202c78-95b4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758326272; x=1758931072; 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=KiB2bJ6ZPemHmzYyrQApJbHwhKc2xCBxAJQiY2SS/xo=;
        b=Lj3S7kBaofQEoyV8liIjzjXJNmmPdZnUdzT0qG16G8aQyxFD4sm2Ae9AumQAQlf/d4
         uJuesI05Ne0Fc2lxnHvc03pq6pZRuFhsiU6q+5C2qjnkuMWygxAlhJTQEmT84QjM6heU
         fLHWQVmPwcG6ULG37zMwYhJc+Wd07WiYZs2Zkzm698GD/TwK993u1VCsRZ/G5ICal8IA
         hXCH1tMBLLEIpArvKUZunxayR28el0EgUr0NZvwhtPAnHV/B56UI7OINfVRbISALzOgb
         NrS12a207Fdf3ScF9FMw2gwwJ6nacjWo7vuJis756WG25qyOoG8iuIUux4Vn2emZEB0Z
         w7Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758326272; x=1758931072;
        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=KiB2bJ6ZPemHmzYyrQApJbHwhKc2xCBxAJQiY2SS/xo=;
        b=IELzdSM1qwwJ2CE/dXqFjysKvvkcWfh1CE2r6umNEnokAktQxIhJIjWTLsc9Ok0K1m
         B4QKPmuE6ju5H8+faORkAHSfyji6rn/FzBqre3bj1/xx29Gk+CEeILrIuU1z62/rit+E
         z0PxTMxYWiHoS6sMV1nlUa4fuvOUhsXJ921leLW8wRWXS2MA8bO5sI0nOgdPO6Mm9DvM
         gnirhf35iK1bWLQwaiNgvOU165AHv4iOJYaZeT8+iSTgVY82mxFlAUbEWWwVj/9MABLQ
         Rn84tt6XA1SDzpacwEro4MGcyS27mm37YoGFQ9RArol5zKMHxojEqxBd6b5AmGULcx0l
         f5/w==
X-Forwarded-Encrypted: i=1; AJvYcCVmlV2YcNx2Pak803H9p3Ob6OEGeQNSmdL4wLqbSH7DK85BKAarsfH6LCU7LlNlwZi958Q+PJ9b+Gc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdMwEJiV1D7EE4uc83eQdoZva+EXWie80jICBCDgG0f5IB6600
	QlY5J0VcLpXc4/VJX6V0FAFW6nl5GgwDtaBkDoy8R03BG7eXoS254CiyUKKQD1g5Fw==
X-Gm-Gg: ASbGncv3OKgOyiRvY+WdT7yNpNMkVrpzJe5CBN9p/9YeSsiurN5lgwb0iVP/woBGYpy
	1tfyMdeXwq5X9OjyEixileGyyx7jkx2HQTsZAVtboAO7X5PP5NRrZ/9YMQiwxwZXFLUvriRjEDD
	6DWBVLYKRg3ZMDBIpXtER6nbzzmXNTs5J9Ge+3q4k6z30QTEdXwej+/APugCmPa30cmeggORS9W
	KEh3rKrm2kvWQGewcfWEQ8l4PTu3PTEkWLoub0z84J7617ZW4oV6m2gyxqk9FXIM5ee/iBnT1Bs
	+BAX9rWqgYxIPB4UKog9Diujm39we4i+km2MrCZCdPesDKTCYzBX6aCxB85FBpmJ8yWzTTQzr90
	Dw+9A45TwWvnr8B75AGtYjkEw9U6NJNlz
X-Google-Smtp-Source: AGHT+IEJNkokwtPxBj5TVhHUY/OMcYq7/YWudHlwS40V38kdY+UNtOgZxaE7b3PWe17U5E28fAWb5A==
X-Received: by 2002:a05:6000:248a:b0:3df:22a3:d240 with SMTP id ffacd0b85a97d-3edd43ac9ebmr7278197f8f.4.1758326271853;
        Fri, 19 Sep 2025 16:57:51 -0700 (PDT)
Message-ID: 
Date: Sat, 20 Sep 2025 01:57:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/18] xen/riscv: Implement p2m_free_subtree() and
 related helpers
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: 
 <18ed5517721254a56e992d9cd9bc1a64672eda8a.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <18ed5517721254a56e992d9cd9bc1a64672eda8a.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> @@ -342,11 +354,147 @@ static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
>      return P2M_TABLE_MAP_NONE;
>  }
>  
> +static void p2m_put_foreign_page(struct page_info *pg)
> +{
> +    /*
> +     * It’s safe to call put_page() here because arch_flush_tlb_mask()
> +     * will be invoked if the page is reallocated before the end of
> +     * this loop, which will trigger a flush of the guest TLBs.
> +     */
> +    put_page(pg);
> +}

What is "this loop" referring to in the comment? There's no loop here.

> +/* Put any references on the page referenced by pte. */
> +static void p2m_put_page(const pte_t pte, unsigned int level, p2m_type_t p2mt)
> +{
> +    mfn_t mfn = pte_get_mfn(pte);
> +
> +    ASSERT(pte_is_valid(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.
> +     */
> +    switch ( level )
> +    {
> +    case 1:
> +        return p2m_put_2m_superpage(mfn, p2mt);
> +
> +    case 0:
> +        return p2m_put_4k_page(mfn, p2mt);
> +
> +    default:
> +        assert_failed("Unsupported level");

I don't think assert_failed() is supposed to be used directly. What's
wrong with using ASSERT_UNREACHABLE() here?

> --- a/xen/arch/riscv/paging.c
> +++ b/xen/arch/riscv/paging.c
> @@ -107,6 +107,14 @@ int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages)
>      return 0;
>  }
>  
> +void paging_free_page(struct domain *d, struct page_info *pg)
> +{
> +    spin_lock(&d->arch.paging.lock);
> +    page_list_add_tail(pg, &d->arch.paging.freelist);
> +    ACCESS_ONCE(d->arch.paging.total_pages)++;

More a question to other REST maintainers than to you: Is this kind of
use of ACCESS_ONCE() okay? By the wording, one might assume a single
memory access, yet only x86 can actually carry out an increment (or
alike) of an item in memory in a single insn.

Jan


From xen-devel-bounces@lists.xenproject.org Sat Sep 20 05:08:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Sep 2025 05:08:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1126907.1468283 (Exim 4.92)
	(envelope-from )
	id 1uzppG-0004bi-GK; Sat, 20 Sep 2025 05:07:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1126907.1468283; Sat, 20 Sep 2025 05:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzppG-0004bX-BC; Sat, 20 Sep 2025 05:07:58 +0000
Received: by outflank-mailman (input) for mailman id 1126907;
 Fri, 19 Sep 2025 15:18:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uzcst-00052K-Vp
 for xen-devel@lists.xenproject.org; Fri, 19 Sep 2025 15:18:52 +0000
Received: from CY3PR05CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c112::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1920fa7-956b-11f0-9d14-b5c5bf9af7f9;
 Fri, 19 Sep 2025 17:18:50 +0200 (CEST)
Received: from SJ0PR03CA0362.namprd03.prod.outlook.com (2603:10b6:a03:3a1::7)
 by DS5PPFEC0C6BDA1.namprd12.prod.outlook.com (2603:10b6:f:fc00::668)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Fri, 19 Sep
 2025 15:18:45 +0000
Received: from CO1PEPF000042AC.namprd03.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::76) by SJ0PR03CA0362.outlook.office365.com
 (2603:10b6:a03:3a1::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.14 via Frontend Transport; Fri,
 19 Sep 2025 15:18:44 +0000
Received: from mail.nvidia.com (216.228.117.160) by
 CO1PEPF000042AC.mail.protection.outlook.com (10.167.243.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Fri, 19 Sep 2025 15:18:43 +0000
Received: from rnnvmail201.nvidia.com (10.129.68.8) by mail.nvidia.com
 (10.129.200.66) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.34; Fri, 19 Sep
 2025 08:18:28 -0700
Received: from localhost (10.126.230.35) by rnnvmail201.nvidia.com
 (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.34; Fri, 19 Sep
 2025 08:18:27 -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: f1920fa7-956b-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wrXYES7tloy4GN7xmegmmq+QzIxvVMZuUUCrJfLLiY5FyFHXGmpCWwQK/Sir6EYKTPhoqCJ28nMmLpEPyHFw/lXu9Gv2qte/kCiiEigigaCsZuHF2xnDott96AnKEzjKt3jPvX74/Ck1v9/GRTI0a6e6+eDffdp9yRuYFHZwT7RMZh7eekW8seTvzW63oaaYQxYGP3cEl3Ymv3a/SS+yNRLtJQXs88ZjvCVK45xqkqjtxbu2VqPQukxSXWe8wo+ZMKpXMw7gKko8VI2eqAotu8EdK45FSTiuq36W+nOorSH/PdwKjy2LXhuLP3Rl0ZgEGpG/NEdxXCTOvTF2/4aY8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QK2nYFTHT+KpSlXE4qZHTuuO1xzq1cYHqgz67BqwHLI=;
 b=VOQxOCmyHMpqGvd50TSk8KZuY8a5dONPg0iYjGKIbAzBO16k/i/N74BZBO4mXwG7TkxOL7Es+EALZK9xvsCH926TnUmze/9RX6wnuYBet36WVAgqC71G2abEWZ3SlpmaOE7BYQheK8olW+Y20IEq/DSnLOZaGIoscWLfFzZHh527vYvUrkSymXnAIvYLXxOyxjXjQfGKtckx9rBGVfdlKt1I7JISNNq+hXG/++cpbKHJjIKjcyl+hqu5JJS2MvuKDjx3idLuTEpUzHXYAqpL1xllv2zbFlzKoNN+I3TjwNREn8PG46o59fwbJ6g9dd5z9KdJzbnaQE4AnclFa4NZ/w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 216.228.117.160) smtp.rcpttodomain=samsung.com smtp.mailfrom=nvidia.com;
 dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QK2nYFTHT+KpSlXE4qZHTuuO1xzq1cYHqgz67BqwHLI=;
 b=VDi04SoHli8++kWiAWLzcEfnAVuAslj9P/bMvuOiYKK3yNHwJ7E2A8Sp0J5txKqIVoaEZkG+O81q5h+SLrVcQvMenmOBEKHfct4/jSWpdoQPLYWLYyqWR2c3ku+91lNt/+/cSLji3RctQh6HcJi4+tC6cb4jwZJmo0iIxQAqOeozlqYTpuNFVSSXR86n7zpy5aGhju+8twGtF7Uyd60rza7AP5ngM/b1NocIdHvsHpc47OQfajInsf/GG7uFWZeD9F0LYfbBE0v+HDCntt4FKFUYMjx9yglGxLunnQw+2AeF5/KfZqfmlOXIlcU81emfJh6Gi5uUl8xFSXNVD7jpGg==
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.160)
 smtp.mailfrom=nvidia.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=nvidia.com;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.117.160 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.117.160; helo=mail.nvidia.com; pr=C
Date: Fri, 19 Sep 2025 18:17:23 +0300
From: Leon Romanovsky 
To: Marek Szyprowski 
CC: Jason Gunthorpe , , Juergen Gross
	, ,
	, Russell King ,
	"Stefano Stabellini" ,
	
Subject: Re: [PATCH v4 5/6] xen: swiotlb: Switch to physical address mapping
 callbacks
Message-ID: <20250919151723.GG10800@unreal>
References: 
 <997c0122a24c355b4d7ee353902041a7617f4c9e.1758203802.git.leon@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <997c0122a24c355b4d7ee353902041a7617f4c9e.1758203802.git.leon@kernel.org>
X-Originating-IP: [10.126.230.35]
X-ClientProxiedBy: rnnvmail202.nvidia.com (10.129.68.7) To
 rnnvmail201.nvidia.com (10.129.68.8)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AC:EE_|DS5PPFEC0C6BDA1:EE_
X-MS-Office365-Filtering-Correlation-Id: 1be5ae2f-3e5c-48be-c707-08ddf78fd25e
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?sInZGPm7TkDBijFXUj2OsW4w9zTsuWTb6mfZCqdO5HNrehIqFMYV81+AXn+z?=
 =?us-ascii?Q?y8uybBsu3zJgsvgnuurYQOfebcdO2D6+KY1IgHS4ivDI0tcyUZxMWGiuXXIV?=
 =?us-ascii?Q?kNGTQttFBPcSWZJRV902mPxTpxbSE5UnBaoLOczKHJJY4pzjTOMhZ/yf83G6?=
 =?us-ascii?Q?ieBHDqepP4A2ZnHC9ioU3HsD1zHkZ8c9rjAwt+O1J5mabZk+nEokWYJhPLUn?=
 =?us-ascii?Q?N0Y06rakyApRoCrYZQn8cncYHj7dIoyw3XDzeZkeiHMlSd7T9N14HQjRlCca?=
 =?us-ascii?Q?6pLWBY21zrmZDbqKb0DhxY58f+kvRE9mzQXdYNjw3+pw55GuWBDM9l80mta9?=
 =?us-ascii?Q?ILw8+MEXGRZAvJ2jZCfH/xevVGb7RNv14o/Cgpja3dekRBKHegXtKMvV6Qdj?=
 =?us-ascii?Q?LHXrfYJKC11cNTAAh1CAnheArarPh5oSh+vmlaKw7ziJlJEin2AeHaK91aoI?=
 =?us-ascii?Q?k1o9mw7aGiUotNfo3ruVRNTba/Kn26FGzQV69wuxBII53YNW4Ivagj/CfT6G?=
 =?us-ascii?Q?+9Cn1L+6bHjf70o6vUKaDGrXIKJZGSjrKWmlcWSGQ4F43dnyvIROAre2SsEF?=
 =?us-ascii?Q?Y3TU2Bc0Xig1ZyWIOt+snEDlHpx5F7pvXobgzbVcwTdisjUeybKp5fge4lg2?=
 =?us-ascii?Q?0Apd8uF3qlcL93pJoO2upollt/dW4xYBA4koRjQOu4ghWjWBbyCi8UXVUiLr?=
 =?us-ascii?Q?D6OT54DYq1CY37h2KM0xBsGg1zGisazBwO9Cn6nP+xecad2w7ClDLdqUUsx+?=
 =?us-ascii?Q?6V8CYlIQulM1mqsdmPfcCnfZekGOlQigtPjU4qWmV1wD1UKqPAHx4Kjc59+i?=
 =?us-ascii?Q?4k6AJSxCO+9g21RVMhOhpOfwyuBwLjx7dPtKnAYxOb0wtqXcsaTwKcRJ4chf?=
 =?us-ascii?Q?Q3LQaUqM33ES6dbmO4rUW4ScLVX/X+QaZGOyJ9nOjj9RkVriM3luRSR8n8Rf?=
 =?us-ascii?Q?1Ps2RIiqeNrXJsXL0C200CIwyM+BbC31VffDD8p8WrQk4LQhuXjxKBs5mYoS?=
 =?us-ascii?Q?kpWfxANkbAiA2mgRzEe7ieMwT2KnrZ+tLK6dImAxdnhTbxJbskclhyZp8zYg?=
 =?us-ascii?Q?ce4bI7QLKlp2KARFGcAd5P++K3e8/wCa+liDhI4lWIRn8frWLBPaQhlkq2qs?=
 =?us-ascii?Q?9O9qryFwG3TwqorycZSsuYKC+dFkIjE/UYNqvdolOPT9TRtvJD1ibrZBKA0Z?=
 =?us-ascii?Q?jqfuyIyMSAea672qiJj8nB0SK5z3mVkOSQevF74xlSSl+L31MDNMaHS25wtf?=
 =?us-ascii?Q?iSt9wNYXBSwETv0iOWCNasyrti5Ff30JpWaMHnQOweu5ro5PcEt5Q1Ei+LGA?=
 =?us-ascii?Q?RA6v1sH8IdXNEAVMRd+x2lY1foTNiBwV0kS9Mp/ZyB9MlOzZ0LLDO28Zdh4H?=
 =?us-ascii?Q?OgxBtUyNYQan8697egRF7oxDTtmWdDfXdAhLzgNMbPXrOwgVZZu8Bys6YkJe?=
 =?us-ascii?Q?FG14qkwjuy82E9+bjbAodLKfSt5C4mmvA4BSpKP8QtsXOAgJgIGGL7iBTPEQ?=
 =?us-ascii?Q?dGxMnMjNTz4tI6XYAnYCSW6fe43JkmrC3GqU?=
X-Forefront-Antispam-Report:
	CIP:216.228.117.160;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:dc6edge1.nvidia.com;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2025 15:18:43.6172
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1be5ae2f-3e5c-48be-c707-08ddf78fd25e
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.160];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AC.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPFEC0C6BDA1

On Thu, Sep 18, 2025 at 05:09:28PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky 
> 
> Combine resource and page mappings routines to one function
> and remove .map_resource/.unmap_resource callbacks completely.
> 
> Signed-off-by: Leon Romanovsky 
> ---
>  drivers/xen/swiotlb-xen.c | 63 ++++++++++++++++++---------------------
>  1 file changed, 29 insertions(+), 34 deletions(-)

<...>

> +	if (attrs & DMA_ATTR_MMIO) {
> +		if (unlikely(!dma_capable(dev, phys, size, false))) {
> +			dev_err_once(
> +				dev,
> +				"DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
> +				&dma_addr, size, *dev->dma_mask,
> +				dev->bus_dma_limit);
> +			WARN_ON_ONCE(1);
> +			return DMA_MAPPING_ERROR;
> +		}
> +		return phys;
> +	}

This need to be fixed by the following change (dma_addr->phys):

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 48936179c940b..ccf25027bec19 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -215,8 +215,8 @@ static dma_addr_t xen_swiotlb_map_phys(struct device *dev, phys_addr_t phys,
                if (unlikely(!dma_capable(dev, phys, size, false))) {
                        dev_err_once(
                                dev,
-                               "DMA addr %pad+%zu overflow (mask %llx, bus limit %llx).\n",
-                               &dma_addr, size, *dev->dma_mask,
+                               "DMA addr %pa+%zu overflow (mask %llx, bus limit %llx).\n",
+                               &phys, size, *dev->dma_mask,
                                dev->bus_dma_limit);
                        WARN_ON_ONCE(1);
                        return DMA_MAPPING_ERROR;

Thanks


From xen-devel-bounces@lists.xenproject.org Sat Sep 20 15:54:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Sep 2025 15:54:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127423.1468293 (Exim 4.92)
	(envelope-from )
	id 1uzzuW-0002Vr-Ls; Sat, 20 Sep 2025 15:54:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127423.1468293; Sat, 20 Sep 2025 15:54:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uzzuW-0002VY-Gl; Sat, 20 Sep 2025 15:54:04 +0000
Received: by outflank-mailman (input) for mailman id 1127423;
 Sat, 20 Sep 2025 15:54: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 1uzzuU-0002VS-Dw
 for xen-devel@lists.xenproject.org; Sat, 20 Sep 2025 15:54:02 +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 04ddd229-963a-11f0-9809-7dc792cee155;
 Sat, 20 Sep 2025 17:53:59 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 48CFD6014D;
 Sat, 20 Sep 2025 15:53:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60277C4CEEB;
 Sat, 20 Sep 2025 15:53: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: 04ddd229-963a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758383637;
	bh=74lAPVg94TJI1UJYgpgsOH2UQdl5PvTbgBIsxqD4zKU=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=qbW+7cTtf3ZC80yzIDcC6P8YiS7RGpwlDTYrGzG6j13dnssuecjvDInjgO1NGXAWT
	 hwAQh0KbTGofBujeWDAzo8uyHyjnB4klpbdUcdr3KuR2vqLH1ociavVauQR6s6LM4C
	 wtVOvrFkt2iXYZs5fqCArx+bz0wZR2AOL0I2MwUCesz5LxbYvHr8I0E7tiQwcKX2mh
	 /6u8BUT9rHwxjmbaoEZQ7oL93zaaJmT1SbIoB4zqQPQjKbmP8WBwznCmHZDgor62TB
	 Nrccq2E0zXdIiG+Jydr5UoWaXp7Rok6i3H1DFwLNWMk9eGO4TL+3lE8Pzt1MNtveO6
	 UwT9ZhNinKNOQ==
Date: Sat, 20 Sep 2025 18:53:52 +0300
From: Leon Romanovsky 
To: Keith Busch 
Cc: Marek Szyprowski ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250920155352.GH10800@unreal>
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Fri, Sep 19, 2025 at 10:08:21AM -0600, Keith Busch wrote:
> On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote:
> > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote:
> > > >
> > > > This series does the core code and modern flows. A followup series
> > > > will give the same treatment to the legacy dma_ops implementation.
> > > 
> > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it 
> > > works fine in linux-next.
> > 
> > Thanks a lot.
> 
> Just fyi, when dma debug is enabled, we're seeing this new warning
> below. I have not had a chance to look into it yet, so I'm just
> reporting the observation.

Did you apply all patches or only Marek's branch?
I don't get this warning when I run my NVMe tests on current dmabuf-vfio branch.

Thanks

> 
>  DMA-API: nvme 0006:01:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported
>  WARNING: kernel/dma/debug.c:598 at add_dma_entry+0x26c/0x328, CPU#1: (udev-worker)/773
>  Modules linked in: acpi_power_meter(E) loop(E) efivarfs(E) autofs4(E)
>  CPU: 1 UID: 0 PID: 773 Comm: (udev-worker) Tainted: G            E    N  6.17.0-rc6-next-20250918-debug #6 PREEMPT(none)
>  Tainted: [E]=UNSIGNED_MODULE, [N]=TEST
>  pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
>  pc : add_dma_entry+0x26c/0x328
>  lr : add_dma_entry+0x26c/0x328
>  sp : ffff80009fe0f460
>  x29: ffff80009fe0f470 x28: 0000000000000001 x27: 0000000000000001
>  x26: ffff8000835d7f38 x25: ffff8000835d7000 x24: ffff8000835d7e60
>  x23: 0000000000000000 x22: 0000000006e2cc00 x21: 0000000000000000
>  x20: ffff800082e8f218 x19: ffff0000a908ff80 x18: 00000000ffffffff
>  x17: ffff8000801972a0 x16: ffff800080197054 x15: 0000000000000000
>  x14: 0000000000000000 x13: 0000000000000004 x12: 0000000000020006
>  x11: 0000000030e4ef9f x10: ffff800083443358 x9 : ffff80008019499c
>  x8 : 00000000fffeffff x7 : ffff800083443358 x6 : 0000000000000000
>  x5 : 00000000000bfff4 x4 : 0000000000000000 x3 : ffff0000bb005ac0
>  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000bb005ac0
>  Call trace:
>   add_dma_entry+0x26c/0x328 (P)
>   debug_dma_map_phys+0xc4/0xf0
>   dma_map_phys+0xe0/0x410
>   dma_map_page_attrs+0x94/0xf8
>   blk_dma_map_direct.isra.0+0x64/0xb8
>   blk_rq_dma_map_iter_next+0x6c/0xc8
>   nvme_prep_rq+0x894/0xa98
>   nvme_queue_rqs+0xb0/0x1a0
>   blk_mq_dispatch_queue_requests+0x268/0x3b8
>   blk_mq_flush_plug_list+0x90/0x188
>   __blk_flush_plug+0x104/0x170
>   blk_finish_plug+0x38/0x50
>   read_pages+0x1a4/0x3b8
>   page_cache_ra_unbounded+0x1a0/0x400
>   force_page_cache_ra+0xa8/0xd8
>   page_cache_sync_ra+0xa0/0x3f8
>   filemap_get_pages+0x104/0x950
>   filemap_read+0xf4/0x498
>   blkdev_read_iter+0x88/0x180
>   vfs_read+0x214/0x310
>   ksys_read+0x70/0x110
>   __arm64_sys_read+0x20/0x30
>   invoke_syscall+0x4c/0x118
>   el0_svc_common.constprop.0+0xc4/0xf0
>   do_el0_svc+0x24/0x38
>   el0_svc+0x1a0/0x340
>   el0t_64_sync_handler+0x98/0xe0
>   el0t_64_sync+0x17c/0x180
>  ---[ end trace 0000000000000000 ]---
> 
> 


From xen-devel-bounces@lists.xenproject.org Sat Sep 20 17:48:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Sep 2025 17:48:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127453.1468302 (Exim 4.92)
	(envelope-from )
	id 1v01ge-0007db-BT; Sat, 20 Sep 2025 17:47:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127453.1468302; Sat, 20 Sep 2025 17:47: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 1v01ge-0007dU-8S; Sat, 20 Sep 2025 17:47:52 +0000
Received: by outflank-mailman (input) for mailman id 1127453;
 Sat, 20 Sep 2025 17:47:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v01gd-0007dO-M2
 for xen-devel@lists.xenproject.org; Sat, 20 Sep 2025 17:47:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v01gd-001bDx-08;
 Sat, 20 Sep 2025 17:47:51 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v01gc-003Bru-3C;
 Sat, 20 Sep 2025 17:47: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:MIME-Version:Message-ID:Date:
	Subject:Cc:To:From; bh=Nnhy/WcZtN3kTUljtGt+CfyIIvU2I2Q6XwMwbPjJp78=; b=6Rq3FY
	E76JcEFYMstY65SsAV/dQHW56hWyG41Iin2eJiV3IRMq7P3U9+jQwS9Tl03OSfkRG1XkWG5uo1GHr
	PFUNY69sVAKgsN/soPVlK+LR/JSxcnxQOtmBq8L5IPHjeQaa0yX282J0HYnvejJpyKKK8FNZTYh8y
	9lUBoAc1D08=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v2] xen/domain: introduce DOMID_ANY
Date: Sat, 20 Sep 2025 10:47:33 -0700
Message-ID: <20250920174732.1207847-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
of the code.

Update all relevant domid_alloc() call sites.

Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
Signed-off-by: Denis Mukhin 
---
Changes since v1:
- moved DOMID_ANY from the public header
---
 tools/tests/domid/harness.h             |  1 +
 tools/tests/domid/test-domid.c          | 12 ++++++------
 xen/common/device-tree/dom0less-build.c |  2 +-
 xen/common/domctl.c                     |  2 +-
 xen/common/domid.c                      |  2 +-
 xen/include/xen/domain.h                |  3 +++
 6 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/tools/tests/domid/harness.h b/tools/tests/domid/harness.h
index 17eb22a9a854..610b564d4061 100644
--- a/tools/tests/domid/harness.h
+++ b/tools/tests/domid/harness.h
@@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
 
 #define DOMID_FIRST_RESERVED            (100)
 #define DOMID_INVALID                   (101)
+#define DOMID_ANY                       DOMID_INVALID
 
 #endif /* _TEST_HARNESS_ */
 
diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
index 5915c4699a5c..71cc4e7fd86d 100644
--- a/tools/tests/domid/test-domid.c
+++ b/tools/tests/domid/test-domid.c
@@ -41,20 +41,20 @@ int main(int argc, char **argv)
         domid_free(expected);
 
     /*
-     * Test that that two consecutive calls of domid_alloc(DOMID_INVALID)
+     * Test that that two consecutive calls of domid_alloc(DOMID_ANY)
      * will never return the same ID.
      * NB: ID#0 is reserved and shall not be allocated by
-     * domid_alloc(DOMID_INVALID).
+     * domid_alloc(DOMID_ANY).
      */
     for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == expected,
                "TEST 3: expected %u allocated %u\n", expected, allocated);
     }
     for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == DOMID_INVALID,
                "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated);
     }
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
         domid_free(expected);
     for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == expected,
                "TEST 5: expected %u allocated %u\n", expected, allocated);
     }
@@ -72,7 +72,7 @@ int main(int argc, char **argv)
     /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */
     expected = DOMID_FIRST_RESERVED - 1;
     domid_free(DOMID_FIRST_RESERVED - 1);
-    allocated = domid_alloc(DOMID_INVALID);
+    allocated = domid_alloc(DOMID_ANY);
     verify(allocated == expected,
            "TEST 6: expected %u allocated %u\n", expected, allocated);
 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 9fd004c42af7..e2764768c983 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -848,7 +848,7 @@ void __init create_domUs(void)
         if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
             panic("No more domain IDs available\n");
 
-        domid = domid_alloc(DOMID_INVALID);
+        domid = domid_alloc(DOMID_ANY);
         if ( domid == DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node));
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 954d79022645..ca91686a03d8 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -410,7 +410,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     case XEN_DOMCTL_createdomain:
     {
         /* NB: ID#0 is reserved, find the first suitable ID instead. */
-        domid_t domid = domid_alloc(op->domain ?: DOMID_INVALID);
+        domid_t domid = domid_alloc(op->domain ?: DOMID_ANY);
 
         if ( domid == DOMID_INVALID )
         {
diff --git a/xen/common/domid.c b/xen/common/domid.c
index 2387ddb08300..76b7f3e7ae6e 100644
--- a/xen/common/domid.c
+++ b/xen/common/domid.c
@@ -19,7 +19,7 @@ static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
  * @param domid Domain ID hint:
  * - If an explicit domain ID is provided, verify its availability and use it
  *   if ID is not used;
- * - If DOMID_INVALID is provided, search [1..DOMID_FIRST_RESERVED-1] range,
+ * - If DOMID_ANY is provided, search [1..DOMID_FIRST_RESERVED-1] range,
  *   starting from the last used ID. Implementation guarantees that two
  *   consecutive calls will never return the same ID. ID#0 is reserved for
  *   the first boot domain (currently, dom0) and excluded from the allocation
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 8aab05ae93c8..cd3e32d17683 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -15,6 +15,9 @@ struct guest_area {
 
 #include 
 
+/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */
+#define DOMID_ANY            DOMID_INVALID
+
 typedef union {
     struct vcpu_guest_context *nat;
     struct compat_vcpu_guest_context *cmp;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 21 00:47:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Sep 2025 00:47:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127518.1468313 (Exim 4.92)
	(envelope-from )
	id 1v08Eu-0004Fo-Vr; Sun, 21 Sep 2025 00:47:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127518.1468313; Sun, 21 Sep 2025 00: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 1v08Eu-0004Fg-RE; Sun, 21 Sep 2025 00:47:40 +0000
Received: by outflank-mailman (input) for mailman id 1127518;
 Sun, 21 Sep 2025 00:47: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 1v08Et-0004FV-QU
 for xen-devel@lists.xenproject.org; Sun, 21 Sep 2025 00:47:39 +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 8f74c4ac-9684-11f0-9809-7dc792cee155;
 Sun, 21 Sep 2025 02:47: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 70099600AC;
 Sun, 21 Sep 2025 00:47:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F266C4CEEB;
 Sun, 21 Sep 2025 00:47: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: 8f74c4ac-9684-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758415652;
	bh=aFgKZNQUQCaJ2vrroedLHD+DNPOlwj6GGUlnWjzhG5w=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=fLUxwzDvBQpVLTwxkVcEMGkM0isY6OG/nLB20SsNVXIRKxxZrAbNIPP/lH+JLvuUn
	 Kib9NA0Qx8ucaR4Lud4LpP66fHzAfy4YMg/WGXGCNSBD/snmzPLJ/GJr5uZM4GRPA4
	 FmPuCrywKU63yNMwT+i1LUerAAz4LYMUpnupPis0tcH13QBvBt9TCQlrhzdIw9AGje
	 8PZjHxaN7jKNeL5CBfGmMNjS4nLwafvguDKC8M88c1TuvUDa7uTmWsQUU6EjD9ZRCh
	 q7PhsUzYYnzKkPRC+D+A2gtlVl3c6gXMUqXDS+5w81SLBHHJjwyUZmv9q7TG8Bge2K
	 OMtCSqZskSdHw==
Date: Sat, 20 Sep 2025 18:47:27 -0600
From: Keith Busch 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Jason Gunthorpe ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: 
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
 
 <20250920155352.GH10800@unreal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250920155352.GH10800@unreal>

On Sat, Sep 20, 2025 at 06:53:52PM +0300, Leon Romanovsky wrote:
> On Fri, Sep 19, 2025 at 10:08:21AM -0600, Keith Busch wrote:
> > On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote:
> > > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote:
> > > > >
> > > > > This series does the core code and modern flows. A followup series
> > > > > will give the same treatment to the legacy dma_ops implementation.
> > > > 
> > > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it 
> > > > works fine in linux-next.
> > > 
> > > Thanks a lot.
> > 
> > Just fyi, when dma debug is enabled, we're seeing this new warning
> > below. I have not had a chance to look into it yet, so I'm just
> > reporting the observation.
> 
> Did you apply all patches or only Marek's branch?
> I don't get this warning when I run my NVMe tests on current dmabuf-vfio branch.

This was the snapshot of linux-next from the 20250918 tag. It doesn't
have the full patchset applied.

One other thing to note, this was runing on arm64 platform using smmu
configured with 64k pages. If your iommu granule is 4k instead, we
wouldn't use the blk_dma_map_direct path.


From xen-devel-bounces@lists.xenproject.org Sun Sep 21 16:29:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Sep 2025 16:29:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127642.1468323 (Exim 4.92)
	(envelope-from )
	id 1v0MwC-00005P-8W; Sun, 21 Sep 2025 16:29:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127642.1468323; Sun, 21 Sep 2025 16: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 1v0MwC-00005G-32; Sun, 21 Sep 2025 16:29:20 +0000
Received: by outflank-mailman (input) for mailman id 1127642;
 Sun, 21 Sep 2025 16:29: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 1v0MwA-000055-MH
 for xen-devel@lists.xenproject.org; Sun, 21 Sep 2025 16:29:18 +0000
Received: from fhigh-b1-smtp.messagingengine.com
 (fhigh-b1-smtp.messagingengine.com [202.12.124.152])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c12e44e-9708-11f0-9809-7dc792cee155;
 Sun, 21 Sep 2025 18:29:15 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id A24587A0011;
 Sun, 21 Sep 2025 12:29:12 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Sun, 21 Sep 2025 12:29:12 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 21 Sep 2025 12:29: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: 1c12e44e-9708-11f0-9809-7dc792cee155
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=1758472152; x=1758558552; bh=WdNTOPpdVrK9P8u9jRJTdDiUUMVvKBOw
	ULXLYZcXJu8=; b=j9eLME9Y7nWi0s1EHw0wfRabUNFi8aulnOQorjWbbstzDf8q
	4+x8BzOSRKzmy9nCwrYh0a7oD92muzWkR0TPph3Lb0Vmi4++L9b9YQz+sOM5vK+D
	f+YD18dO80EBPkdTTShynrOTpfTRmTlO9NI6MHjfCafvxaRQBvQngxyNZru7vBvI
	PLQSP0cHnPCEq5Vulv+rkOa+SNWrRVX6b81YMI3Fa71OJxHunnpYDs6DvpVqILZ/
	zXDNsZ2OOl991uQG7wmI46nfwZnUYTAPnPvs79fmvPOyCsreZIhf9lueuR4QvLYr
	o44f1RSn55c410K5kWHNmt2Jpbi0XGasIPzzIw==
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=1758472152; x=1758558552; bh=WdNTOPpdVrK9P8u9jRJTdDiUUMVv
	KBOwULXLYZcXJu8=; b=TqM51bi2IKXztUWG4FcVpjVAHDKS4JfekjWKnsyOdJ6B
	1JkGpLGDuYqGBp1QYDtjzXM6aNKdrn/2hRFYtlKLhkrVX6MnPhQLbmy/kS3/fc39
	koabU7ZymSeb3WfMUbkL/8FRvqt2OMfTgfJGNj1+Bd6EBdjvEEQy70FwoyDH/VYO
	+6Q6DL3UbLhYEMd2KGrQELuQTwNW7PwsnsmIdHLw6Cp+CR1qt/vCfHEhSrHC83nc
	MJUH+xz8Nepmb7Ak5uI35ip6eIukTPO9XHE8L8YvDJz5LnaDm+OMrGAm08dSSIvL
	eu4+Kww0Cjqy/4E2g3QIbBtYnuP1cAZnXGIJJqMByg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdehheeghecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffogggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepkeekieevkeeu
    heefgeevjeevveeutdejieevgeeuhfdvffeuteeftdduvdeuteevnecuffhomhgrihhnpe
    hkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr
    ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd
    gtohhmpdhnsggprhgtphhtthhopeelpdhmohguvgepshhmthhpohhuthdprhgtphhtthho
    pehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtth
    hopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhr
    tghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopehsthgrsghlvg
    esvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehsshhtrggsvghllhhinhhi
    sehkvghrnhgvlhdrohhrghdprhgtphhtthhopeholhgvkhhsrghnughrpghthihshhgthh
    gvnhhkohesvghprghmrdgtohhmpdhrtghpthhtoheprhgrfhgrvghlrdhjrdifhihsohgt
    khhisehinhhtvghlrdgtohhmpdhrtghpthhtohepmhgrrhhiohdrlhhimhhonhgtihgvlh
    hlohesrghmugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdig
    vghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: linux-kernel@vger.kernel.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	=?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= ,
	stable@vger.kernel.org,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	"Rafael J. Wysocki" ,
	Mario Limonciello ,
	xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
Subject: [PATCH] xen: take system_transition_mutex on suspend
Date: Sun, 21 Sep 2025 18:28:47 +0200
Message-ID: <20250921162853.223116-1-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Xen's do_suspend() calls dpm_suspend_start() without taking required
system_transition_mutex. Since 12ffc3b1513eb moved the
pm_restrict_gfp_mask() call, not taking that mutex results in a WARN.

Take the mutex in do_suspend(), and use mutex_trylock() to follow
how enter_state() does this.

Suggested-by: Jürgen Groß 
Fixes: 12ffc3b1513eb "PM: Restrict swap use to later in the suspend sequence"
Link: https://lore.kernel.org/xen-devel/aKiBJeqsYx_4Top5@mail-itl/
Signed-off-by: Marek Marczykowski-Górecki 
Cc: stable@vger.kernel.org # v6.16+
---
 drivers/xen/manage.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index b4b4ebed68daf..f78d970949c0a 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -101,10 +102,16 @@ static void do_suspend(void)
 
 	shutting_down = SHUTDOWN_SUSPEND;
 
+	if (!mutex_trylock(&system_transition_mutex))
+	{
+		pr_err("%s: failed to take system_transition_mutex\n", __func__);
+		goto out;
+	}
+
 	err = freeze_processes();
 	if (err) {
 		pr_err("%s: freeze processes failed %d\n", __func__, err);
-		goto out;
+		goto out_unlock;
 	}
 
 	err = freeze_kernel_threads();
@@ -160,6 +167,8 @@ static void do_suspend(void)
 
 out_thaw:
 	thaw_processes();
+out_unlock:
+	mutex_unlock(&system_transition_mutex);
 out:
 	shutting_down = SHUTDOWN_INVALID;
 }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 06:06:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 06:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127706.1468333 (Exim 4.92)
	(envelope-from )
	id 1v0Zh5-0004Tf-DH; Mon, 22 Sep 2025 06:06:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127706.1468333; Mon, 22 Sep 2025 06: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 1v0Zh5-0004TW-7g; Mon, 22 Sep 2025 06:06:35 +0000
Received: by outflank-mailman (input) for mailman id 1127706;
 Mon, 22 Sep 2025 06:06: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 1v0Zh4-0004TQ-Mg
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 06:06:34 +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 47786c33-977a-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 08:06:29 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-45df0cde41bso25367405e9.3
 for ; Sun, 21 Sep 2025 23:06:29 -0700 (PDT)
Received: from ?IPV6:2003:e5:873d:be00:c26:b971:1ba7:9d8b?
 (p200300e5873dbe000c26b9711ba79d8b.dip0.t-ipconnect.de.
 [2003:e5:873d:be00:c26:b971:1ba7:9d8b])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3ee074106f4sm18265990f8f.25.2025.09.21.23.06.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 21 Sep 2025 23:06: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: 47786c33-977a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758521188; x=1759125988; 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=S33tBRFGEL/DOZHvKhG7BtJTvv1OFtfAiwgB5Qbf6Z0=;
        b=guDrchW+jtrPph/cqw2PG0fm0EkLtZUON/QElWOZ9VJ1P8tQttd3+HZqb0EP/mHo7d
         qlAY3MZdyHRrEom21XeztZXenn9ib067qiolFPHGwenQKFevenHr3fAVpfH/J2uFbAjx
         MstalBbVplvwhvyKwz27sW1/Dr4LnDi86ZcqFnL7W4nZ8bJnMmXavi0Kiszo5GtJBU8y
         wdWpx+gWOQD45s04txGwZGw+AZHOg+eh4GdXwfX1bYCO1j7cHQvfx9/9ORNI6OBqh18T
         6+JrYSJrLvdFBDpl4gAJZKV8xudl8XnVhQu4lvknwcldDhqK9NwrEWvyf41kw9FhE4Q5
         23KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758521188; x=1759125988;
        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=S33tBRFGEL/DOZHvKhG7BtJTvv1OFtfAiwgB5Qbf6Z0=;
        b=VhYjLLyPpe60DipYIc9gsS0c63v30fSx9/4rws6hMwYVInUR2iIkGWeoaBIHA/sHAd
         jNgEFSHT8phxXdarkk6N3+pLNik+yGJ07TZz1V4/uOvH1Cmd0e4O2BicSAJwIFVAb2+3
         7W8+D6RcK4kvnI6QbXGB+y5evOdoDBidbp8X+EKbvNgugCcw54jA/ZForSXUXsJg2gXB
         pp25T0HAq82+iPKi3H6qCwPN0D8d/PxVaFG6DmskLNFu/6bR2N3TwK5NYO98kFtZRP3G
         z8eij7kYIMH8ZzhEAbbKKY1WyB7yrJC8XeQg4f9Ksth8VGjNrAUjvtHoK22zSP6KjB6j
         hBUw==
X-Forwarded-Encrypted: i=1; AJvYcCXtJ6Pd0qZqB6ftw/Y1aPbMAfV8OpEXIXLrQG2VdOuN1hWCqlfMAjAcLJA5yXI5F7kvhM2qD9Awr2A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzfcsf/mHHWi7KpCoEdxtcP9NuKK5bT2rp0gygIyNih4ajD12Dl
	Dx9EDKitr5A1ebyFc3SeTkTLMQDez6OnXPSjm2Rp9o1RatG8jmRNgGeUQsprmVXtUNw=
X-Gm-Gg: ASbGncsqFri2gZYRCZ/UyK2/OHYWhm/9vkvIDTCr8jNlG5wJzYU4E1uSvaPJ5P8qNxR
	V1xi2K6JnyimHiDB12pGUsfYxmstejrz6YbpT1Y+qoL8AiK6EbmKK6JaeDj/SlEkFlkNuF1esru
	imRClD7ltFYRG0/H1vsULcdYDx7sQ8Vix9w3zENOzMBA3f/5KOq2KXHVVPCnBaGDwQJpX9DIVDL
	04PC9aMYWBdroMdYrrNuGv6pktB8HHOVU+8WbY/QrhlXLTb/PTWMxwmdUKZS3m2oEvtyixviJKG
	4Bjf/rdEQp8JRCDqGfv8i4RWP1wzPbbQ+Qm18aZ2n8R91Ly9Ue2HCVnBckR9/3ONjGJUQ+pMv8S
	U7Ct86KHtPtNuEULzeWTJ2MBFGBBN2jASSN6MkJhL1YwcrKMf0GAM+RF8JL8bVYe1zCaj53GieM
	PiNpv982t0d4dX2+vfoqXJI3+Y2EmZEcYfEilQ1Cdxurpp
X-Google-Smtp-Source: AGHT+IFD2CfjVpWeDi5iUTryBGhtdm4ngYLxtc/glzzILx3/6SMLU91M4jq7nuc4Yswkou5ELKp8EQ==
X-Received: by 2002:a05:600c:1f95:b0:461:8b9d:db1d with SMTP id 5b1f17b1804b1-467e75ea470mr106925685e9.7.1758521188377;
        Sun, 21 Sep 2025 23:06:28 -0700 (PDT)
Message-ID: 
Date: Mon, 22 Sep 2025 08:06:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: take system_transition_mutex on suspend
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 "Rafael J. Wysocki" ,
 Mario Limonciello ,
 "moderated list:XEN HYPERVISOR INTERFACE" 
References: <20250921162853.223116-1-marmarek@invisiblethingslab.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: <20250921162853.223116-1-marmarek@invisiblethingslab.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------whziD4bI9vuk0vBNxNwWgLTF"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------whziD4bI9vuk0vBNxNwWgLTF
Content-Type: multipart/mixed; boundary="------------MI4OlWCfs6VtvyAFMm5tUoqt";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 "Rafael J. Wysocki" ,
 Mario Limonciello ,
 "moderated list:XEN HYPERVISOR INTERFACE" 
Message-ID: 
Subject: Re: [PATCH] xen: take system_transition_mutex on suspend
References: <20250921162853.223116-1-marmarek@invisiblethingslab.com>
In-Reply-To: <20250921162853.223116-1-marmarek@invisiblethingslab.com>

--------------MI4OlWCfs6VtvyAFMm5tUoqt
Content-Type: multipart/mixed; boundary="------------xxNp610sdXCe0SVU03qz4z0d"

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

T24gMjEuMDkuMjUgMTg6MjgsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN
Cj4gWGVuJ3MgZG9fc3VzcGVuZCgpIGNhbGxzIGRwbV9zdXNwZW5kX3N0YXJ0KCkgd2l0aG91
dCB0YWtpbmcgcmVxdWlyZWQNCj4gc3lzdGVtX3RyYW5zaXRpb25fbXV0ZXguIFNpbmNlIDEy
ZmZjM2IxNTEzZWIgbW92ZWQgdGhlDQo+IHBtX3Jlc3RyaWN0X2dmcF9tYXNrKCkgY2FsbCwg
bm90IHRha2luZyB0aGF0IG11dGV4IHJlc3VsdHMgaW4gYSBXQVJOLg0KPiANCj4gVGFrZSB0
aGUgbXV0ZXggaW4gZG9fc3VzcGVuZCgpLCBhbmQgdXNlIG11dGV4X3RyeWxvY2soKSB0byBm
b2xsb3cNCj4gaG93IGVudGVyX3N0YXRlKCkgZG9lcyB0aGlzLg0KPiANCj4gU3VnZ2VzdGVk
LWJ5OiBKw7xyZ2VuIEdyb8OfIDxqZ3Jvc3NAc3VzZS5jb20+DQo+IEZpeGVzOiAxMmZmYzNi
MTUxM2ViICJQTTogUmVzdHJpY3Qgc3dhcCB1c2UgdG8gbGF0ZXIgaW4gdGhlIHN1c3BlbmQg
c2VxdWVuY2UiDQo+IExpbms6IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9h
S2lCSmVxc1l4XzRUb3A1QG1haWwtaXRsLw0KPiBTaWduZWQtb2ZmLWJ5OiBNYXJlayBNYXJj
enlrb3dza2ktR8OzcmVja2kgPG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+DQo+
IENjOiBzdGFibGVAdmdlci5rZXJuZWwub3JnICMgdjYuMTYrDQoNClJldmlld2VkLWJ5OiBK
dWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K
--------------xxNp610sdXCe0SVU03qz4z0d
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-----

--------------xxNp610sdXCe0SVU03qz4z0d--

--------------MI4OlWCfs6VtvyAFMm5tUoqt--

--------------whziD4bI9vuk0vBNxNwWgLTF
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/Ey8FAmjQ52MFAwAAAAAACgkQsN6d1ii/Ey9w
agf9EtF5ZEwY40ioARPpA3Uwj6TmMhq+8ONvmTy9b+fBkH3hLDun1yrAO5SQQ1tp8t9FeBvUOr4H
jWKH8/4iHaxFOzoN43TVAptMm5oNw7DnXEzKdC6yGx/nin0LkRt5zRfVhBMNhHH6DBBFpNm1lrjx
vOm8UKVYRL//GcM4cko+d5TnTKzuagPcyaNe45Jy3PK9mOKn0FKrM3q2NRd2J6Zi1u7xR5cMJjyy
PsIKZNFTbqjIPrsMb5HPRQGVY/nr4dLSj91tLO8D7kBHKH6OFOgDHyE0kIWwa+05p61f5u9moNBu
AuZmlWg1NNmmQkZobKf8bjg/9V2aTnvgwsSPSIcTPw==
=TmYL
-----END PGP SIGNATURE-----

--------------whziD4bI9vuk0vBNxNwWgLTF--


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 09:49:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 09:49:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127730.1468343 (Exim 4.92)
	(envelope-from )
	id 1v0dAg-00049Y-BZ; Mon, 22 Sep 2025 09:49:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127730.1468343; Mon, 22 Sep 2025 09:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0dAg-00049P-59; Mon, 22 Sep 2025 09:49:22 +0000
Received: by outflank-mailman (input) for mailman id 1127730;
 Mon, 22 Sep 2025 09:49: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 1v0dAe-00049J-Lk
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 09:49:20 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 66ea36ba-9799-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 11:49:16 +0200 (CEST)
Received: from AS9PR04CA0179.eurprd04.prod.outlook.com (2603:10a6:20b:530::21)
 by AM0PR08MB5505.eurprd08.prod.outlook.com (2603:10a6:208:18e::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 09:49:10 +0000
Received: from AM2PEPF0001C713.eurprd05.prod.outlook.com
 (2603:10a6:20b:530:cafe::35) by AS9PR04CA0179.outlook.office365.com
 (2603:10a6:20b:530::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 09:49:10 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM2PEPF0001C713.mail.protection.outlook.com (10.167.16.183) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.12
 via Frontend Transport; Mon, 22 Sep 2025 09:49:10 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com (2603:10a6:102:33e::18)
 by PAVPR08MB9858.eurprd08.prod.outlook.com (2603:10a6:102:300::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 09:48:36 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3]) by PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3%4]) with mapi id 15.20.9137.012; Mon, 22 Sep 2025
 09:48: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: 66ea36ba-9799-11f0-9809-7dc792cee155
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ryUswlh2bPfQjhtacTN4xP7rucK+2AvSM+ZaKQjG1Tk+yskweE3LNZjAUDcMnh4BhwoDh2bra3zBJ9xrAVpJbqTO1jcb3glpVoV9q1dzYYkM1x6QsUoM681fOu+rbyFEUyLOG5zYq8Mf8LqT5o1xxhaKoCQG0WTxVN+RHDphjK0BbAY4/sUnDAXuGw7tRUHlKR5ZLuvPDfReHriiN6DeymwHmHfMFhXRvinyu5amsF+dnOeE0qUeC3AZWH4D/qL1XiPa+SQrWdFw8O7S71Ng7Lll1qAmfVr9KDr4OoprV54e4dB+zsERUMMJKM6lCaLBpN5YoQluybw/xxUMtTuJww==
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=BCdKscu6ruRp97nwmqgS4IMyeU9XD9sfV9Qu+aXDYms=;
 b=bLMJ1VBE2vp6wMnux3kHiN1vkWn95mlpOs1SY3G3q0zWUEISvZ1ClMggN8TOdfdpWvES0KDbRf376mILy9xKNzEitTnQqP3NICA/NNZFsTl386nq/x6slu4RoxZda+7/vf5j2tirUaWT23KpcmA4aBp4xJUgQnItmDqdER9WgIHBOoHEiVg71sPSzkYBSOySDQkbOjoVohkxPYhO8LdRCacTw4ZHzTZRK3aAEoZYFbslI+Fgy6JJYtZklikucdItztxJnjIuWdp+7/VmdKciXlk5SV0qNiJdb8sXiyrc5I/LE23ITt05wVK7nUjzMNZ1G883bNNtMCdgJpPOxpwUcQ==
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=BCdKscu6ruRp97nwmqgS4IMyeU9XD9sfV9Qu+aXDYms=;
 b=BdWU/2gT8XlaY1CZ2JKMxF7BK+nSss56Dgmy4ER0FZ/eC2xNOn8BMTnYHm3fZSfLJoB+wJCjIs7Ow7wG7Blt/xJZ3Z/tXpTmrSEYfCSQ764CmnO5+uxkvLf/OM8xUq1nJKxLcV6CKSRMD1rFcN/vSduDn+UVXg2G1q67mL39NdI=
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=p2wZZdLOuigaRyhNap3K14f7tm+CZhxvv3gxiP2/s15X9cMDTfzSU7aQ60Xwstw0KjkbntY7XXPUnbChpLBbaKVnKIbzUaey+8dJ0QU91LiHR6MohER97x7pkMpL4HHaWQXs4Uz2insdx3CPAwVGe28SGkwe8T/TgchTAc+3eX0p5lN/YYf/qaaXoeRySnhpHOlvnfBRT2najaDQh/NdDRbITd6NuKqhKdAURSQOyYPT8Yit2u7vWqVLNrjulNwvDeOzqIZIoii8X1Qnn+46zMs75QcELrcoaObgjTr5jQLnLbLy5ayTfl8XawIhLdFiJTkNa7LKzZVxTIxN2gZrNg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BCdKscu6ruRp97nwmqgS4IMyeU9XD9sfV9Qu+aXDYms=;
 b=Ns72EQFYXXKs/zrAIh34b81Gm8sfgeIzfgrUCusE4iReDQ6mg23aZSDh52/UeRn2lIEPQK8eF4rIrpOs0BWct9wSm54EOStf8Knd7lCRcgG2Ap3bmBhN8Wf0J3EWSYYPhtXFt1W27LUb7QG9Zj6mlLwHpFGPq5F+gB+FMEPErIfVuhH17WjizH80H0fn2BU9n6o8e/uUl0Q8oxXqe+Or0WoANn3qJ8R69GU0q5FbVDTmKBxdnyfH5v2OM2HnVZH5CTTMgAmqO3UpcwkK82NLzJ5CYexfNYgmrrHw61u0PtRUHdg4g5Y+l+Jc76gZNwCo84tq6a4jXdGzugZKBTqIqQ==
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=BCdKscu6ruRp97nwmqgS4IMyeU9XD9sfV9Qu+aXDYms=;
 b=BdWU/2gT8XlaY1CZ2JKMxF7BK+nSss56Dgmy4ER0FZ/eC2xNOn8BMTnYHm3fZSfLJoB+wJCjIs7Ow7wG7Blt/xJZ3Z/tXpTmrSEYfCSQ764CmnO5+uxkvLf/OM8xUq1nJKxLcV6CKSRMD1rFcN/vSduDn+UVXg2G1q67mL39NdI=
From: Bertrand Marquis 
To: Stefano Stabellini 
CC: Julien Grall , Grygorii Strashko
	, "xen-devel@lists.xenproject.org"
	, Michal Orzel ,
	Volodymyr Babchuk 
Subject: Re: [XEN][PATCH] xen/arm: restrict cpu_up_send_sgi() to arm32
Thread-Topic: [XEN][PATCH] xen/arm: restrict cpu_up_send_sgi() to arm32
Thread-Index: AQHcJC1gjv9t41MjxkWbCWqmFW+v17SQHGmAgA7nUIA=
Date: Mon, 22 Sep 2025 09:48:36 +0000
Message-ID: 
References: <20250911081213.1323594-1-grygorii_strashko@epam.com>
 <705d4436-2263-462b-a582-5f0092821959@xen.org>
 
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.700.81)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PAWPR08MB9005:EE_|PAVPR08MB9858:EE_|AM2PEPF0001C713:EE_|AM0PR08MB5505:EE_
X-MS-Office365-Filtering-Correlation-Id: 18480cb0-7802-4bd3-db0c-08ddf9bd478c
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?GMoaELS6hJh4HBahlFsAWhchYYkXv0ceVPS+Hfp4rBk2IHqHMfv1aqx4o2Hk?=
 =?us-ascii?Q?vuTQjLz2X7+L/MI3I1JLNyHDVTb3+dcIIJ/pfGrDGvzf/Upc6sbcPcKDzobu?=
 =?us-ascii?Q?FuZYiDYwRqhhnKPzeBmK1IvG35xvF4I7CFMEJl3uGIsQ1ovINly444kNR/7J?=
 =?us-ascii?Q?ky5aXOqd3JjMX9Pc9nEYsLDTg+Rxy1iAJZBotAfd7PKLZ0dpOnlTX0S2Qu63?=
 =?us-ascii?Q?XPyzedvlfL/YvDCo3A5uPLCzQ0SMxehPEUrqEQhoae9DoOdSTMJb55XJyE4A?=
 =?us-ascii?Q?1CePSZZxzzXIQYgDtzWmMkb8qRI5iUVhioC8WY7lpR/IKJyg7RuGMqg2Mt6T?=
 =?us-ascii?Q?O6fO0GQ95CJzfwvmcAwsHiyQZZ8amlxO7+rIme2gFN6CHcbrFAMsr3DV2LhA?=
 =?us-ascii?Q?pA9O16MMomsjTrVawYJTT/5B6q5Aq2pvM9R0x7rgTdndVFVathhOnGs5SJWV?=
 =?us-ascii?Q?ouuXAD4mq0BN+oFoKxnx7Bo4IMrpT4LJCo3tcJcdjwueVd9bdotQdHWu8xcf?=
 =?us-ascii?Q?OGYNdsNUg5kzjbZoaNmxiXnT8zhQXBDXwkrOckNY0f2clsC4xeg9Nz3tnSfu?=
 =?us-ascii?Q?fNpzn4VAxjIT3fvugCISXsIIMv6qdTbvJmBkeihJVyYqRA0tg3kwLvDGpayR?=
 =?us-ascii?Q?tgnC4YNavrzrwrNjSR3qG4NESu8jC7lnwlR2jD6wkiObj/gmOcCOIpA/Q0js?=
 =?us-ascii?Q?14rVOTWVNSPDrmRLfjki9QDxLxYg9i3Sk6Nt/u1YzS55kmDFF6lmSvS48x+A?=
 =?us-ascii?Q?8teISowI28Otj9jdiCvgvZ2muw3KAT6PAf91hgjI4o0stF/OQxorzGUpEnoT?=
 =?us-ascii?Q?ms172K/4wo7zyi7lSdcynS6DNuecnO37yGfBrt82eLKYj4uarKIxTCBnJuWq?=
 =?us-ascii?Q?I2PvC6kWTYM2VvHewfNkSIvywySlkWk9Z7M92tx1tqKQ9IMSyD8wWGgKERuG?=
 =?us-ascii?Q?jFESR7AV++I1IDEBrvgKS4aUMiR5eBpYDLyTUG9iEB5F76h1m6PMWRhNmIhQ?=
 =?us-ascii?Q?siuTie3DivVg2nEg3VMxvYACtZI1jQ3f6Z9joEJsBq9gQPmxAoC7UVL/flFX?=
 =?us-ascii?Q?tY2tIFt7Z7B6bC+5SE93TDlwVbFdQ+vyeCiQIHpwMFuGHT9M0FJvGbeDtGX9?=
 =?us-ascii?Q?/5WDuwftVcUjjS6YubBQq0D051CcbuCleAR6xYkCqeWk/KrBiMeWy5T84mrK?=
 =?us-ascii?Q?z9lpEgqFVIvVzJ2v1Bz+iQZEqJH9d1HGhQV7mwDF5HP2CIiPvVHcilDGBzhr?=
 =?us-ascii?Q?rv+KsKEKgCZoYVSsRJWAhsdm80NpmIKmBomo3m5479evWQp7xUIqtc0QU+ZD?=
 =?us-ascii?Q?uw60Du2xV5wMgbXdZ0MB8y7r6S+GuS57w3R05ycr6sk/vEMkcuomeil8LF2W?=
 =?us-ascii?Q?3kuR/gSKETmEidTvx3LpZV6pVCWi5+eixNp3eI61JQac3wQ4A1w1y34quuaW?=
 =?us-ascii?Q?CkwrZoONqRSCKWBX3dNNynKTOW1LXphiEcqvoLRkfo9vyOU08NDNYeBu7sLd?=
 =?us-ascii?Q?XhdfAFU2NY3bs6E=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAWPR08MB9005.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <490EE14B0226E848BB26CDD6E38A9D18@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9858
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM2PEPF0001C713.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	34cf2371-4e01-4cd8-7ed6-08ddf9bd334e
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|14060799003|35042699022|376014|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?q1w+S5T9eLW4Nn0aE3yCAuNbncTEVTxz/UsjN8RwX29ST1S4jsuNMmTol8IF?=
 =?us-ascii?Q?3d2gB7HvfPQ39OC0U+MTOAH63K/vkdYzzhHSl9zigVanygXd69L/cQ45lMVM?=
 =?us-ascii?Q?i0sR8F5G3FCQVkjoyH8f3b+p8mYklxpioeRdR0Oi1IHOikVQAv1ihwfHWv/Z?=
 =?us-ascii?Q?M3l2KdcZKowYVqZQjgJuw0Qug6ArWLCxAbkZyrKpz3gr/V7xeXXmJNi8gi/Z?=
 =?us-ascii?Q?HbFDxp4GHJKog9YyTbCizep2Ei5GxY8R8VNRBDP7DxwrKjQe2DPlZRISJ6MP?=
 =?us-ascii?Q?3bnG59F3tl7CSomDG19V8GzSljAETJjea04Bq7Ps7qq4kFR+5LuFm9tB3foL?=
 =?us-ascii?Q?RM7JWUMhc/UkxRXgY2JXMGqqtDldYcaeerbbnBtZFrYLiNAOcVLvQxDdfyeL?=
 =?us-ascii?Q?DgMYPstW45nGx41vrbzBbDBxHeWyQfEFB2alP22rEPX51hc/gRuBnFnw14GF?=
 =?us-ascii?Q?AQn5da0+CtVMpzCs6KZxVUcBfCy6X7lRyxNM89hzUWfJ2sOKBHhJ6RjasPWV?=
 =?us-ascii?Q?W58l79830ZQLwImToqP6M002Zr7l1/24HDoBbSR3FL+jyuYpAcHByQk5XQW8?=
 =?us-ascii?Q?5we8N29S4AEHU70XJQkxeBgKrVEGYdoMBjXAmjg+KPF0mp/OiB6konE/4pMQ?=
 =?us-ascii?Q?TylFwXEB83CA7DP+c0LvpzB9d0h2HCuCmP/vlDTQTykay559HrqFFt+qemhj?=
 =?us-ascii?Q?Kghsv4/zxdIwMZ8wNamYH+YqpeNFeedOM1jMNr04uVe3OrlFbCDlfNFZkrA2?=
 =?us-ascii?Q?K8ylB+CxrQ1WktCLn1o0/7Mb8f8odI6DV/Ydx83Nre8u3rv3CT1CmTF6K6f6?=
 =?us-ascii?Q?9ISFUG7z0532cqWxlsk2ETQoOMtdcDXMgeSYPQmE2UbJmhfM+MYd7HxccTMn?=
 =?us-ascii?Q?0KXyhiW6ff2QHl2V1lmWaTy367z62vH75vHLF6SArxFCOllO+IqUvhPSCeT/?=
 =?us-ascii?Q?1P6bXg/oqxFCjFKfN/ypDMDiOc74bicx6lmDVhntYl/9uXVqNDveOMc5AeC0?=
 =?us-ascii?Q?4A9Lh05U+fcJFSZYwKm2/IXziblE/Hrc8YsPx5D/N8Y99wKTm8AgWkdhMggY?=
 =?us-ascii?Q?eAFMCaVuC/rCVnj78AFZgeIQ6tMOPtbJuXHiy4YErq36O7iqd5QMnEzpS5qD?=
 =?us-ascii?Q?ka0VdTlHSqigt+WTpbr5VrFN6oUdJKDu7lDgQNiRHoQFmo1hns7HFW5XXOo7?=
 =?us-ascii?Q?6m2jbusxXmRuWVDOsrJen3oPT5dZSlez1cBNBfR9WP+m7CaoE7+OFZT5yvyd?=
 =?us-ascii?Q?Dvt+eXGy7jUAjVPbiM4dkKgF6pJM0p3Bx90FpMHr0s2Bboqbas55BSf9Zgz5?=
 =?us-ascii?Q?8mS9i+RxP445u0lmtj1GjFcuc1aAU2UVmgZu+MWAOWYT/LVBfx4YM+XCGFy4?=
 =?us-ascii?Q?LE0uFvFJWnirOcjfMxv6EL4PTSOF0LHFAGU48gT2ccA7vNrnuR2vMpeinySq?=
 =?us-ascii?Q?XDvn6+rNNK+1Z1D5JCRDfxKk2zims3SayZQzVh1mpAPx6AFr5zR/lPJJjd+h?=
 =?us-ascii?Q?FFqDFP1uWDUZtgX3gQAGLmZ5ep8yJSTGp6QP?=
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)(14060799003)(35042699022)(376014)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2025 09:49:10.0012
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 18480cb0-7802-4bd3-db0c-08ddf9bd478c
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:
	AM2PEPF0001C713.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5505

Hi,

> On 13 Sep 2025, at 00:12, Stefano Stabellini  wro=
te:
>=20
> On Fri, 12 Sep 2025, Julien Grall wrote:
>> Hi Grygorii,
>>=20
>> On 11/09/2025 09:12, Grygorii Strashko wrote:
>>> From: Grygorii Strashko 
>>>=20
>>> Restrict cpu_up_send_sgi() function to arm32 code as it's used by arm32
>>> platforms only and unreachable on arm64 (Misra rule 2.1).
>>>=20
>>> Signed-off-by: Grygorii Strashko 
>>> ---> Logically cpu_up_send_sgi() should be moved in arm32, but source i=
s
>>> "GPL-2.0-or-later" while possible destination is "GPL-2.0-only", so put=
 it
>>> under ifdef for now.
>>=20
>> :(. I don't know if we will ever solve this license mess... Looking at t=
he
>> list of platform using cpu_up_send_sgi(), all the platforms are 10+ year=
s old
>> and to be honest except maybe the rcar2 development platforms. I doubt t=
here
>> are anyone using them.
>>=20
>> So I would be tempted to get rid of them and mandate PSCI when booting o=
n Xen.
>>=20
>> Bertrand, Michal, Stefano any thoughts?
>=20
> I am OK with that.

I am OK with that to.

Cheers
Bertrand

>=20
>=20
>> Meanwhile for this patch:
>>=20
>> Acked-by: Julien Grall 




From xen-devel-bounces@lists.xenproject.org Mon Sep 22 10:09:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 10:09:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127752.1468353 (Exim 4.92)
	(envelope-from )
	id 1v0dU5-000709-U2; Mon, 22 Sep 2025 10:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127752.1468353; Mon, 22 Sep 2025 10: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 1v0dU5-000702-Qo; Mon, 22 Sep 2025 10:09:25 +0000
Received: by outflank-mailman (input) for mailman id 1127752;
 Mon, 22 Sep 2025 10:09: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 1v0dU4-0006zw-Ep
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 10:09:24 +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 35c7580d-979c-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 12:09:23 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id 6D9C31D0006A;
 Mon, 22 Sep 2025 06:09:21 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Mon, 22 Sep 2025 06:09:21 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 22 Sep 2025 06:09:20 -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: 35c7580d-979c-11f0-9d14-b5c5bf9af7f9
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=1758535761;
	 x=1758622161; bh=LaDcwF2RDStxElNAadMYTwEC3oddn3HOqej1bLn2VXs=; b=
	SGnRJQKB29IgSE1m+6HFoI7Ko7fud7x1iXPL9i1WRvVEZr+3kssG7zodpzS8GAac
	6IQkHTq5+GbgR479HbBtZ425vcJLMpXobxjM7nFB18u3LVjVAyE1HPfQar6oazVH
	WURZ3sOdOucUgs3edoPaHeaROCshModUo0zmgLttY++eA46zPx3WFIfVCHHsDTtL
	Y/JQ/n6G3747+zyxrLD/Hj/qNoQDZOPHcQ1Ce3VxRV/yG8tGx/FFuczSYqhyrekI
	FGXt77O+frzBq7NIOQMwUTEixSYNZDqxYpB8c2cJ69AEwllqkjwmto43nisAQvYg
	jliclHm1CakUgVHKEZSqTQ==
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=
	1758535761; x=1758622161; bh=LaDcwF2RDStxElNAadMYTwEC3oddn3HOqej
	1bLn2VXs=; b=W3ql9YdUvVWEPbnBWKhz+wW2t5aSj8NWEgE3KtZlBveshpQpSEA
	e+Oig+GBlnwL5N1HHnngqq+rbYbWtdvNLUyS9o8pbXwF8Q5/hBAVnopxpV+jInzc
	M0w4C+vuiUwwImX4SwyzoHg4sSK6v8csACQseFFZCMYRCcrbn8PZpcoCoj7FgSAT
	FazAY1Wmf7cdcmypGJF6ABiVqHQgSu9phC73GC9uW2iE1aZ8mPONrNxzuXrlVIF2
	Wv1vLo/UdK3/A3qkke0UWsEAJWiwxs4LWE5VxXUrDtPqjieKZXp4BgkIKpW59jgi
	aD00y8rNJsiXZm7H0x9ypDSeKf/SWIm4ZvQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdehjeehkecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeukeetteeg
    gffgkeduheetgeeileejjeeiiefhjeegvefhtefggfetueetteeuteenucffohhmrghinh
    epghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm
    rghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsg
    drtghomhdpnhgspghrtghpthhtohephedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht
    ohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlse
    hlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsshhtrggsvghl
    lhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopeholhgvkhhsrghnughrpghthi
    hshhgthhgvnhhkohesvghprghmrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhr
    ohhvshhkhiesohhrrggtlhgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 22 Sep 2025 12:09:18 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Boris Ostrovsky 
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16
Message-ID: 
References: 
 
 <05e9628d-83e5-4feb-881d-5854b72bd560@suse.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="y2aJ/Rwljl2qe2Gi"
Content-Disposition: inline
In-Reply-To: 


--y2aJ/Rwljl2qe2Gi
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 22 Sep 2025 12:09:18 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Boris Ostrovsky 
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16

On Fri, Aug 22, 2025 at 08:42:30PM +0200, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Fri, Aug 22, 2025 at 05:27:20PM +0200, J=C3=BCrgen Gro=C3=9F wrote:
> > On 22.08.25 16:42, Marek Marczykowski-G=C3=B3recki wrote:
> > > On Fri, Aug 22, 2025 at 04:39:33PM +0200, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > Hi,
> > > >=20
> > > > When suspending domU I get the following issue:
> > > >=20
> > > >      Freezing user space processes
> > > >      Freezing user space processes failed after 20.004 seconds (1 t=
asks refusing to freeze, wq_busy=3D0):
> > > >      task:xl              state:D stack:0     pid:466   tgid:466   =
ppid:1      task_flags:0x400040 flags:0x00004006
> > > >      Call Trace:
> > > >       
> > > >       __schedule+0x2f3/0x780
> > > >       schedule+0x27/0x80
> > > >       schedule_preempt_disabled+0x15/0x30
> > > >       __mutex_lock.constprop.0+0x49f/0x880
> > > >       unregister_xenbus_watch+0x216/0x230
> > > >       xenbus_write_watch+0xb9/0x220
> > > >       xenbus_file_write+0x131/0x1b0
> > > >       vfs_writev+0x26c/0x3d0
> > > >       ? do_writev+0xeb/0x110
> > > >       do_writev+0xeb/0x110
> > > >       do_syscall_64+0x84/0x2c0
> > > >       ? do_syscall_64+0x200/0x2c0
> > > >       ? generic_handle_irq+0x3f/0x60
> > > >       ? syscall_exit_work+0x108/0x140
> > > >       ? do_syscall_64+0x200/0x2c0
> > > >       ? __irq_exit_rcu+0x4c/0xe0
> > > >       entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > > >      RIP: 0033:0x79b618138642
> > > >      RSP: 002b:00007fff9a192fc8 EFLAGS: 00000246 ORIG_RAX: 00000000=
00000014
> > > >      RAX: ffffffffffffffda RBX: 00000000024fd490 RCX: 000079b618138=
642
> > > >      RDX: 0000000000000003 RSI: 00007fff9a193120 RDI: 0000000000000=
014
> > > >      RBP: 00007fff9a193000 R08: 0000000000000000 R09: 0000000000000=
000
> > > >      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000=
014
> > > >      R13: 00007fff9a193120 R14: 0000000000000003 R15: 0000000000000=
000
> > > >       
> > > >      OOM killer enabled.
> > > >      Restarting tasks: Starting
> > > >      Restarting tasks: Done
> > > >      xen:manage: do_suspend: freeze processes failed -16
> > > >=20
> > > > The process in question is `xl devd` daemon. It's a domU serving a
> > > > xenvif backend.
> > > >=20
> > > > I noticed it on 6.16.1, but looking at earlier test logs I see it w=
ith
> > > > 6.16-rc6 already (but interestingly, not 6.16-rc2 yet? feels weird =
given
> > > > seemingly no relevant changes between rc2 and rc6).
> > >=20
> > > I forgot to include link for (a little) more details:
> > > https://github.com/QubesOS/qubes-linux-kernel/pull/1157
> > >=20
> > > Especially, there is another call trace with panic_on_warn enabled -
> > > slightly different, but looks related.
> > >=20
> >=20
> > I'm pretty sure the PV variant for suspending is just wrong: it is call=
ing
> > dpm_suspend_start() from do_suspend() without taking the required
> > system_transition_mutex, resulting in the WARN() in pm_restrict_gfp_mas=
k().
> >=20
> > It might be as easy as just adding the mutex() call to do_suspend(), bu=
t I'm
> > really not sure that will be a proper fix.
>=20
> Hm, this might explain the second call trace, but not the freeze failure
> quoted here above, I think?

While the patch I sent appears to fix this particular issue, it made me
wonder: is there any fundamental reason why do_suspend() is not using
pm_suspend() and register Xen-specific actions via platform_suspend_ops
(and maybe syscore_ops)? From a brief look at the code, it should
theoretically be possible, and should avoid issues like this.

I tried to do a quick&dirty attempt at that[1], and it failed (panic). I
surely made several mistakes there (and also left a ton of todo
comments). But before spending any more time at that, I'd like to ask
if this is a viable option at all.

[1] https://github.com/marmarek/linux/commit/47cfdb991c85566c9c333570511e67=
bf477a5da6
--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjRIE4ACgkQ24/THMrX
1yzjYQf/dkvWv8WyxX7AXNmw4fUQIj6Sb9+0XA7TYLo5Io5wuScg3TlDnOq5RsSU
BDqgX3yBYxMmObBpG630w02U7Uf5Hkn7QIfNCaHUMlJyPU/Jz8qgaN0AJK1DDpog
05/0DQ2JOjHCo5p25oKLAtGGhofGSE2fxBQJTeOozft5RF7IeTeZ2TNf+wcgATj3
3ilKt81kypFAQO1k1yk9GE7YS5pGbUeNTrB5N7PY5kxwyZ0UJKecCIXL9HRyfOwy
M6Rifg4iFtcHsj62f0/PFgw7mGvE2EO/BhdYuA6KYi+u2Aena6K3hRscKyuBYsFA
EB0pDt7ymLekaWZUb2nsFcuOoCG28A==
=KC7E
-----END PGP SIGNATURE-----

--y2aJ/Rwljl2qe2Gi--


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 13:08:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 13:08:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127781.1468363 (Exim 4.92)
	(envelope-from )
	id 1v0gGv-0002Gn-9X; Mon, 22 Sep 2025 13:08:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127781.1468363; Mon, 22 Sep 2025 13:08: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 1v0gGv-0002Gg-6G; Mon, 22 Sep 2025 13:08:01 +0000
Received: by outflank-mailman (input) for mailman id 1127781;
 Mon, 22 Sep 2025 13:07: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 1v0gGt-0002Ga-9B
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 13:07:59 +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 2881d615-97b5-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 15:07:57 +0200 (CEST)
Received: from DUZPR01CA0154.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4bd::24) by AS8PR08MB9885.eurprd08.prod.outlook.com
 (2603:10a6:20b:5b0::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 13:07:52 +0000
Received: from DU2PEPF00028D0F.eurprd03.prod.outlook.com
 (2603:10a6:10:4bd:cafe::b9) by DUZPR01CA0154.outlook.office365.com
 (2603:10a6:10:4bd::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 13:08:15 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU2PEPF00028D0F.mail.protection.outlook.com (10.167.242.23) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.12
 via Frontend Transport; Mon, 22 Sep 2025 13:07:51 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com (2603:10a6:102:33e::18)
 by VI0PR08MB11232.eurprd08.prod.outlook.com (2603:10a6:800:2c7::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 13:07:13 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3]) by PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3%4]) with mapi id 15.20.9137.012; Mon, 22 Sep 2025
 13:07: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: 2881d615-97b5-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=k9VbruogRqQKruUzGQgpuI30DxHrzD+6RsLf1oNOMUVb2nI7BItbbdJ716U9Q8PCXQByefEzLy2gdPESpWirSa3+UPLzCErs8UCJjQ0txtiAN00fown1DvZSPBjkDvdNCSgqYtGV7Rso4nUtBuWGQ+ZQ3LHv5cxWPQfx16x+CaHkxF0+XELCBGSLh5zaJqjGCdQaUhZ4AWjDgeTC2T6WKk4shwhwE52EHR6EklY+dpybzP6qSF89qhLVz7ZKpFxPkO59OgeBWk190emsBt8O1DdE9PaL2K6JUgvXenygGpHnF+lnW1at1wUASVhyIXxtAvnTnOxsHn5y1d8LVy1txg==
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=ixBSqbMwuWoOEI1qMiZBdWmBbeltSvl3nJZX70b5Vls=;
 b=oJOk+m9TMKK3yyeec2S7b+cN5lUVcCoHOnEoSzMqpeFE7qXCcxFtSyOYKQISQtITU8W/cjESZc8nOXTDxV1qxxn706EVyFhNGGNgje/qwD/s8CUwIMZ5lkBi+NM2TckpUA/qh814Bm1iSnLfVnlzD0w/Qp9G3BIy8BVOZ2wGk99U+DX+JzGQ0Yfw9mZ7f9JLjYNAVBBUvvCc4gxdUGu8NZJtbiVk5YUTuwM5zO6Lrr1dRq4PRhmxh2dPUhwBKjehc1qITto+vNdyrBQwO1o+WC65ZxQsqB/xVNNmruDqUEduLrzg/c7S6v8bd8JXd56nFFKUVmR2Yynf+FRVxB474Q==
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=ixBSqbMwuWoOEI1qMiZBdWmBbeltSvl3nJZX70b5Vls=;
 b=HSzOFLPvOjUsGGtu8+aH9NJylq936a51oQpbayU1eyOCkuptWshatGYeNB5gCEJh+iKuXILVMxKlKc7YFVsaMxCZW/gaYD2Hmiosvob5SqNSbuPzNNcfEJrqcu8h4yZTMoo052EgSUXzLByO+PGn7dUqSASYf2UOv3u6OQ1x7Wo=
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=GObu0iy09reVEheDS7OGDixC084QEbs0EKPfNPgkYLGUIKqXfTYTYdrD/ut7NqLTXYsIY06AbJvCdCMJfp0TizYkn16LXxcTVojK0dHWMVRhmfqUOBzl1gcZlW6dqbkjfvffUvJsUMBNAg93fK2bfpQN8DoStt0pjSsbLWPhATfEk44gYn7mFJCryoF0MfKG7wfIWWq3WqXv98NX8ptHcl9HNjoOid5woRsNdhIdGFEfPWHfYOTPwRT/pD8/1rTCe4aM2mDi4+1YtNEV0ubS6z5lEAMqwxFKnG/MAG3z6xyzq24WwOj87MUyFo0iURDTqhgbWUJxriLOG6Adg+5uZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ixBSqbMwuWoOEI1qMiZBdWmBbeltSvl3nJZX70b5Vls=;
 b=syeEUH5EZK5oce9FDOljV4TQIbGXFo1icblAPIutGnpuPQPM1nRbo8wxKXxAYAzenQXoNLGOa+MpBEBRCOv+/YR1PTAbad9k1eUBg+YstUWawiTu2CujJXq3hCOb7fs3XSPDyDQkUJhi0Jy7R8ytnmq/M0bgrtK4sqQZltV6i5QoBIRDBRS59LGFiyZRGatbTWy3Hwix2d7rvNQjAtPK6V0M7RjHxK58CmMwJKLVedOkQ/StaU/pEVYN/VhL+lACqJQznaMlBNKP7PDdL0vIlzaL+R4bUahj1c4peI1HClIbuhaPNZq1AcFo/WnkNgJoMHTM9NJ/VlJxOLM1PYmLUg==
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=ixBSqbMwuWoOEI1qMiZBdWmBbeltSvl3nJZX70b5Vls=;
 b=HSzOFLPvOjUsGGtu8+aH9NJylq936a51oQpbayU1eyOCkuptWshatGYeNB5gCEJh+iKuXILVMxKlKc7YFVsaMxCZW/gaYD2Hmiosvob5SqNSbuPzNNcfEJrqcu8h4yZTMoo052EgSUXzLByO+PGn7dUqSASYf2UOv3u6OQ1x7Wo=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Michal Orzel ,
	Artem Mygaiev 
Subject: Re: [PATCH v4 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Topic: [PATCH v4 2/2] docs: fusa: Add the requirements for some of the
 commands of XEN_VERSION
Thread-Index: AQHcEPw+jP/LO+G+sUGc0SEs/4ZL5bSfYZoA
Date: Mon, 22 Sep 2025 13:07:12 +0000
Message-ID: 
References: <20250819112709.3789987-1-ayan.kumar.halder@amd.com>
 <20250819112709.3789987-2-ayan.kumar.halder@amd.com>
In-Reply-To: <20250819112709.3789987-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.700.81)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PAWPR08MB9005:EE_|VI0PR08MB11232:EE_|DU2PEPF00028D0F:EE_|AS8PR08MB9885:EE_
X-MS-Office365-Filtering-Correlation-Id: a0a8ef7f-a61c-4e39-5925-08ddf9d90915
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|1800799024|366016|10070799003|38070700021|13003099007;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?3teFSv7bfkY7O8W3Usp79qHDZJRrQI1LRuA0hZf2fytOwyDD23nUaBRhxXsf?=
 =?us-ascii?Q?o+3YRJ2TfOxB4pfl0tmqvl2N8QkzLjUtYaMlPGywMEd/GeLHEP0b1cFUp8MD?=
 =?us-ascii?Q?uSf5VsC1VPV00PadVNyq3KTqOD7KRNdGYl4hLMDEjKqRPknIRFsr7D1Ij96y?=
 =?us-ascii?Q?VEcg/ioVb2M+faoL1pY8ZAGx97rlY0+P3nMvz45IqiDT5huFfDu6lS8Bm+m1?=
 =?us-ascii?Q?wajXge/rCC2FUT4UyPeFmzzVSWG47K2vsq6CqRB3kLlfVb2eRkRVTeO2xgbQ?=
 =?us-ascii?Q?ZUIVWFjELh/cAN4NJjmw23RpoLaxTyVcv8q7Rvx1b6/guXBw10mePDbRuQnF?=
 =?us-ascii?Q?cJIDb70b+bEVrw4H/6Ove/GhVCi5+GZi8nJ3xL0Cll71u1ZpeNRY2m6wFIZD?=
 =?us-ascii?Q?fIlXYDgvMIghUNOJZKC10slnY8+yalgraOlkiOKgOtaI4G7V5NgOda4NWtQK?=
 =?us-ascii?Q?DdqO5seeF8Hm72PdoxW+Wb5YuMuoAs0vaUZWJprsYMMXXsrjJ6S3hfH72l6q?=
 =?us-ascii?Q?49MHw+f697uoPPSl/z0D//LmiUyYMmk6hssUhhnR7DkpS6lBBt+JS0N6Iafg?=
 =?us-ascii?Q?0t+NpUXcSk6CtQ2Wd/WdkxyoYMGnflnCPEY8xY6bLE48eNBG9Ro9l7sgRzXZ?=
 =?us-ascii?Q?Dt4J5YdWZ8uLuqvrfY54flLJxBQ82VGWefmFbkpNXNjHbK8PFegJbbhYU5pY?=
 =?us-ascii?Q?uvcPXr8Rar6JWh9KgImla+uzk3tZN/KHscwsOW5L1cScKfehwS1fk5OfjXyz?=
 =?us-ascii?Q?lzqEsEbQn/cNcotHhbX5AF3VCEQkqJMlTGLOLEdsqihZe3VBejAZiMonh+qk?=
 =?us-ascii?Q?YAVCB2Yydk/i0voLLdmy/0n2z9QH1iURl4mTlNxRjczcCLe6NVyQBZA5B9y/?=
 =?us-ascii?Q?cU6ufU+y9FR5CF0NlIEmkHODJO2oCviZhqK/vT+pjNUkSMBXuUsS9z3K8M2B?=
 =?us-ascii?Q?ElMB7L2CdN79rE2SwdFxKOxfFtikEVfHOJl+r1X5fsdhmios2zcM6H21nIvm?=
 =?us-ascii?Q?wBr+2ebudQljy8WUv+5byJk2wPlL96P6KrXV7wOY2WBA6daWnDMwx5awIfi1?=
 =?us-ascii?Q?JM+Q7K1qotS0RH9UwCPOPxy1RSGfsoiRIpRCtClO7/DrcJ+/t2XZTS2bc3ZE?=
 =?us-ascii?Q?nkoF4T+BqMPp0/GJZ4TKyuzI6Hl+yUMzsgWt8oYzeVrKHDighxNI+NkmuXmp?=
 =?us-ascii?Q?3HZml59iJD9nwZ5RIK5zXrOe8ieHmC8+BzvD+LUgbL6RSKwYXC7oacZqoG9S?=
 =?us-ascii?Q?jnv43KW+uXsKfbTyjEFW+JF8HXjzpKtq9rl32R2Yqg28rwgEQyOhDMvysK8+?=
 =?us-ascii?Q?nFcYxYbTj6wC8eFct0jIH6wcab/jaUPdWn43PekSNCY2f33pP3gWarPS7niL?=
 =?us-ascii?Q?izENTKIdQxgXsb5p/Ta8NzSB5UY5hLgy1hv4fi1rFg2+9Y/YfS24OLlqz80q?=
 =?us-ascii?Q?PLkRV3me3Js=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAWPR08MB9005.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(10070799003)(38070700021)(13003099007);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: VI0PR08MB11232
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D0F.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	eeba0b2d-004c-4f53-fd93-08ddf9d8f240
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|35042699022|82310400026|376014|36860700013|1800799024|13003099007|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?eAoAGsJnxIkdKGfo8xS/OsG6be3Q+S8Z6Lci5DrLRDglaX2KefJcdAGi/0Ay?=
 =?us-ascii?Q?8W5UVCmu0v4BE5kwfAkYVhRZA5KsQsZ8MomqG1Bi/A8WthMYhKcw9Tr/uIXO?=
 =?us-ascii?Q?XsI8OdAJN9w+vTDMWHrevVLowQSbHWpzBUrkaWjO1DPTpsFUyyhgxe2aRl8O?=
 =?us-ascii?Q?kzdVdjkOhdqgy54hKMxRgMKAmM7nRguINyPJINoYFR1QHiNDMSjOzr31l6EB?=
 =?us-ascii?Q?30VsQDucSKTzvG5XWBLWTSZR4MgLXpfQRMJZMnUXoVgD3+POogFYBMkwMMGv?=
 =?us-ascii?Q?qGiUmh6vORp3Fc3EBiYQr7f6iaCIQy0z2x4CXkDN9iC0gIczluTyDaCrWNoA?=
 =?us-ascii?Q?mE8WJbNTu/YVS9x4BHNxvYexJYLndd+8H2QOXTpnBC5jW7GX38B7CppPLVr8?=
 =?us-ascii?Q?AeTGP1xZeOE9rJpMtBE/tZvxf7LrCXnJCv8oWRbi0nbDivlOBwkZjr2Rk3/Y?=
 =?us-ascii?Q?cGMX2jIS3k8nNS9oDbRuUlzlejyol1WZTUO0em3GHBIORk0G6yKs4wEocRkm?=
 =?us-ascii?Q?Ns2mjPFCNCozpZiJdE6jFXso8jH7uHGAGSlqkkiBbCkh8p9u+mtMK5/d8uD8?=
 =?us-ascii?Q?lNeYKrsQzzKLNxztjqiYXj5nHIjCgKReIVtulJUQKsZLvgfJhZlkk8xAT6TS?=
 =?us-ascii?Q?Q3pJGRKfKFbJhK3GmcAa1iw6sJ/C2NTZ7cFkMvC4iKuuv1iK2m9BqlkJG2O8?=
 =?us-ascii?Q?XwgBuPdwLe28KcFQCAITtWrjdnxKbjf2jFZzcv3JcB9J0Jt5zF4xjiyDX/1N?=
 =?us-ascii?Q?OknZT+TR/P1ok8YPnz7pL0pKihKb6JxnglKi+H//ar2FlVIiFlCOOjXoIZHl?=
 =?us-ascii?Q?m0ycwrkqAhixlvHaYJxkYsaPytEUqMvq2xQcH6/xgvD7exOTlE4VkwJ1ndR3?=
 =?us-ascii?Q?NZhep43G2DROeEuBgVADgP/dFE1BRivTHTgkVs4c+HvF8O6HBnZszOPS7yWC?=
 =?us-ascii?Q?RbELQjk+CHtpt6mtFb/nrp1J8bf7cZOTIFkGNv6VD4PiR1Ax8uT5rAZvUeID?=
 =?us-ascii?Q?4wfe6fpGJc4VU7ZdN67nDj7zUCmAuHr6nISJjybyHK4ieh8btq1Mgqk+H0Fm?=
 =?us-ascii?Q?aVo23JDz/KmHQZkxAQ+67pfumNZMcjnLsQwvJHZHBXeD95Zn4WvrgiYe/iRW?=
 =?us-ascii?Q?AkrC9wR89tqvKjYWzQaLhUzN9pr2XBwRwfkU/ubse/B9TLtoEiY1kw1NmcDz?=
 =?us-ascii?Q?bh0Hmaz6eqVHojt6DT3ZjkI7kUcVjhHQlRXZNlbabbIxBa+NiRcgc547IP+l?=
 =?us-ascii?Q?PT3UEBhOIm1kieQvT66y/iL+6SucW3DtDFiw5ejE8Xrk1TNPt9aaVpmTAZl2?=
 =?us-ascii?Q?ZDiHWX04TKpuy7APbTTErC8BNPOGmfzdwJDyIvTYpzBRrBv1JLeenMqKAo1S?=
 =?us-ascii?Q?iPHXQXz+oUL/R7ujWJgQF/bz/Po83Ubjo8uavGaYyW1VHySA0wVJBVIkmCZC?=
 =?us-ascii?Q?2cyh+qdIp3OL3PztC2gf72srBRVdKOxEhpfCAZaWnIaEEaqlZ4mMKA=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)(35042699022)(82310400026)(376014)(36860700013)(1800799024)(13003099007)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2025 13:07:51.0965
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a0a8ef7f-a61c-4e39-5925-08ddf9d90915
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:
	DU2PEPF00028D0F.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9885

Hi Ayan,

> On 19 Aug 2025, at 13:27, Ayan Kumar Halder  w=
rote:
>=20
> We have written the requirements for some of the commands of the XEN_VERS=
ION
> hypercall.
>=20
> Signed-off-by: Ayan Kumar Halder 

Looks good to me.

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes from -
>=20
> v1 - 1. Reworded the requirement so as to avoid mentioining variable name=
s
> or hardcoded strings. Otherwise, one would need to change the requirement
> each time the code changes.
>=20
> v2 - 1. Moved few changes to previous patch.
>=20
> v3 - 1. Removed the internal implementation details from the design requi=
rements
> so that they can be verified by black box tests.
>=20
> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 15 ++++
> .../design-reqs/arm64/version_hypercall.rst   | 32 +++++++
> .../reqs/design-reqs/version_hypercall.rst    | 63 ++++++++++++++
> docs/fusa/reqs/index.rst                      |  3 +
> docs/fusa/reqs/product-reqs/hypercall.rst     | 20 +++++
> .../reqs/product-reqs/version_hypercall.rst   | 85 +++++++++++++++++++
> 6 files changed, 218 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
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/r=
eqs/design-reqs/arm64/hypercall.rst
> index 82ecf690a3..3b4af18323 100644
> --- a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> @@ -58,3 +58,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 x0.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~hyp_err_ret_val~1`
> diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/doc=
s/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> new file mode 100644
> index 0000000000..ccfcb35a7a
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> @@ -0,0 +1,32 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Capabilities
> +------------
> +
> +`XenSwdgn~arm64_capabilities~1`
> +
> +Description:
> +Xen shall return xen-3.0-aarch64 to denote that the cpu is running in ar=
m64 mode.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> +Capabilities AArch32
> +--------------------
> +
> +`XenSwdgn~arm64_capabilities_aarch32~1`
> +
> +Description:
> +Xen shall return xen-3.0-armv7l to denote that the cpu is running in arm=
32 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..b05481b9dc
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
> @@ -0,0 +1,63 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version
> +-------
> +
> +`XenSwdgn~version~1`
> +
> +Description:
> +Xen shall return its version when XENVER_version 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 buff=
er.
> +
> +Rationale:
> +-EFAULT is one of the error code defined in
> +http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/include/publ=
ic/errno.h.
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~hyp_err_ret_val~1`
> +
> +Extraversion
> +------------
> +
> +`XenSwdgn~extraversion~1`
> +
> +Description:
> +Xen shall return its extraversion when XENVER_extraversion command is in=
voked.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_extraversion_cmd~1`
> +
> +Changeset
> +---------
> +
> +`XenSwdgn~changeset~1`
> +
> +Description:
> +Xen shall return its changeset when XENVER_changeset command is invoked.
> +
> +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/p=
roduct-reqs/hypercall.rst
> new file mode 100644
> index 0000000000..9fb46cf451
> --- /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 any hypercall fails, Xen shall return one of the error codes def=
ined
> +in http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/include/p=
ublic/errno.h.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fus=
a/reqs/product-reqs/version_hypercall.rst
> index b824c539b0..466eb4108b 100644
> --- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -40,3 +40,88 @@ Covers:
>=20
> 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 (ie version) and minor (ie subversion) =
number.
> +The minor number is encoded in the 16 least significant bits and the maj=
or number
> +is encoded in the top remaining bits.
> +
> +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.
> +
> +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 chang=
eset
> +to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Changeset is string denoting the date, time and git hash of the last cha=
nge
> +made to Xen's codebase.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> --=20
> 2.25.1
>=20



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 13:09:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 13:09:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127794.1468374 (Exim 4.92)
	(envelope-from )
	id 1v0gIG-0002l1-KD; Mon, 22 Sep 2025 13:09:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127794.1468374; Mon, 22 Sep 2025 13:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0gIG-0002ku-GD; Mon, 22 Sep 2025 13:09:24 +0000
Received: by outflank-mailman (input) for mailman id 1127794;
 Mon, 22 Sep 2025 13:09: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 1v0gIF-0002km-Di
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 13:09:23 +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 57fa19b3-97b5-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 15:09:18 +0200 (CEST)
Received: from AS9PR06CA0176.eurprd06.prod.outlook.com (2603:10a6:20b:45c::14)
 by AM7PR08MB5319.eurprd08.prod.outlook.com (2603:10a6:20b:dc::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Mon, 22 Sep
 2025 13:09:15 +0000
Received: from AM4PEPF00027A63.eurprd04.prod.outlook.com
 (2603:10a6:20b:45c:cafe::a8) by AS9PR06CA0176.outlook.office365.com
 (2603:10a6:20b:45c::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 13:09:15 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A63.mail.protection.outlook.com (10.167.16.73) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.12
 via Frontend Transport; Mon, 22 Sep 2025 13:09:14 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com (2603:10a6:102:33e::18)
 by VI0PR08MB11503.eurprd08.prod.outlook.com (2603:10a6:800:2fe::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 13:08:42 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3]) by PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3%4]) with mapi id 15.20.9137.012; Mon, 22 Sep 2025
 13:08: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: 57fa19b3-97b5-11f0-9809-7dc792cee155
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=atzh8oNQ7pVfmvbyA3HwfcV3R6nfcC0nYYODh7DGFLO6XhEIdr7AdB4qTR8Bx0sEF62zkK/pt8a34PtJ2pcgNzKudbMsgCfac9br114UyFy4hQ2gUwEoiobB/rXer9qIoKsYbbzkID/C6XsmJwG5w5/1Uel47gGY1j/veFxbFcisG9BuFy5Fq9OqaFwZF1e44w6rW9DLrd1Ir+p5PfE8oLReRVJRqw2avpJI40eMkxh54GCLc8k2uL/ntVkTNBumIEfxsWmzbmm/8Ft1MZhvVGjhueThAsii+sv1BgTsRMOGu0jl7tVtN/z4zCtmOChldDmU1xU4DZ6Hg4EAlxeAtQ==
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=XBqqU/+eKkIaSTMxva89/A1k/FmamY9z6GnWyO0ZZFM=;
 b=n96K4WNhv7U1tuznI+NTlrg82kPygZKZgFl+NKR/o/vTDJg8OSRKfs6d5013HD2hSbqSI9dRqJ/nlTD1IyjPP22B+L9psH9hErOLqTdGZuGKOJuyc7RRSx+DRdsoYX2MAR2v4HKLVbnkV76h9yfGQk6xfDrY9SEYR5amir2ZvmSNw2iIZE8XhQzQ8SGZS3KFBhb4sJVTK6yX/hFpJXyjqk5z1DqaMhGxtToxCtd+9+hdZ1rmb6/ZJx1EcjdGVIWoJGhLwoWdwbVsSXvDeNR1Ysg+H3e5hY9I8e6SIYuI9S/X4VFpeDVtNIIQaJn88HdQK3ZgNXtZd+oOZwAQGm67+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=XBqqU/+eKkIaSTMxva89/A1k/FmamY9z6GnWyO0ZZFM=;
 b=UgidHKUq2uarevsdWYxjKHCf0vSTE+YZsLmnEbHjsxHzucFNjYRxSpkjGKIL4Q8GkZMkkyHyNY9hJHdJtwmU+vtIfbfjqqiQH6DZCvwQmY1bcMVBfOFlsOuONarM/RqRJtUbDQSY6Et7Ivi3zOhTRK6l9L1Y+HrkZ4Rl+nJJm2g=
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=A8utCSFQmekJ2+FDXLjB5nWvGPj+7xUICYiV3OQHIspXQ5mN8z1eX2+le5Pj4r0RYi2c0nULYVFBOEYU6WahKZVsLuAi0zisyuSZLVR1W2Jr/tfrkJndP3xA0Y5VCrmT/b51AtxUTl+mEsK365tu3tq5PyLsFCHYl2BmtplGlQvRLZGUjXuouN1inHWejw6rjHLoX+DHNX6ey2HFj2Llls5u6l491xGw6ErxYe0FPHcHOWrwUoZm9ApZPjBZSO7bKE+CnsTRh1eGWW68yFKA8h5+uAqNLhyB5R9sQPMs5/uG1K4C0KBHp4QqTZ5lpQb6BTVidKNX7iSErcIEmQZzuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XBqqU/+eKkIaSTMxva89/A1k/FmamY9z6GnWyO0ZZFM=;
 b=U0bPEHsWH2WAx+gAaBbTl2iCYd4dO1KvCIb22H5eQKPqL89VRSU7/RadG3EP25bsfrlUbhXlR2IpydRRAsicnu+VeIWB73DkXm4hljpUAouTFPoPOv1vx6pWbfCQFdMbJFjX9q8aVTlYx9Z4SXXv54zfyL0tXGMeLLhoyPti3KzBJ1LSy+Gfh2kVxpkOmNa3bDS2VsrCQMKdg95v7mNljXFjEB+ZgFmROxejGfOszFZeFRnp6WZMDWvYO1zSrBfYCtIK+aQCsFrrBwjO8RJRGp2Mo1SwUhosYRfaUVm/IwatDRWudTTqe4PYUokD+xJ6lrbM2QhI3nLf12iOcjm6Mg==
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=XBqqU/+eKkIaSTMxva89/A1k/FmamY9z6GnWyO0ZZFM=;
 b=UgidHKUq2uarevsdWYxjKHCf0vSTE+YZsLmnEbHjsxHzucFNjYRxSpkjGKIL4Q8GkZMkkyHyNY9hJHdJtwmU+vtIfbfjqqiQH6DZCvwQmY1bcMVBfOFlsOuONarM/RqRJtUbDQSY6Et7Ivi3zOhTRK6l9L1Y+HrkZ4Rl+nJJm2g=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Michal Orzel ,
	Artem Mygaiev 
Subject: Re: [PATCH v4 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
Thread-Topic: [PATCH v4 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
Thread-Index: AQHcEPw+d611kJLkXEyjl3BM2lUCU7SfYgSA
Date: Mon, 22 Sep 2025 13:08:42 +0000
Message-ID: 
References: <20250819112709.3789987-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20250819112709.3789987-1-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.700.81)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PAWPR08MB9005:EE_|VI0PR08MB11503:EE_|AM4PEPF00027A63:EE_|AM7PR08MB5319:EE_
X-MS-Office365-Filtering-Correlation-Id: 47d2de23-cc85-4bc4-c9af-08ddf9d93ad3
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|10070799003|1800799024|366016|38070700021;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?EiGbZ+hZG2a8UQEPTdnr9zBUuqDaEHZWz0PeG1G5qsy7HBa15+tIkBw2ib2Z?=
 =?us-ascii?Q?gKlAUQFpGN7usu98qUvpEGgI6ByXBzJsi6pDgUmSs6bqiYSY+OZc8/AN6z2A?=
 =?us-ascii?Q?JBVNeo7vzJBdrwVt7dFlwWfaHTbcOkEYgWROeEmx8LxEuJuqlXEtMefg7K3Z?=
 =?us-ascii?Q?Wb55H4o5rNodQMLnnJqiG7TQCihntH9UXvGsv4b9fMnUoB1yAZ9US07BjScb?=
 =?us-ascii?Q?S7tQ5gc/2OtNa+DrWU51y6laxGXT6jplDB0FtN2nK+onU51bTHUjRQzOcc4G?=
 =?us-ascii?Q?0nSl7Y+qBoFWWXazKhHYkdOVKDyylTawUlKVpERtE23Ic/x8DH+GvnghQGz2?=
 =?us-ascii?Q?dk9uHj24eDbl2FEZwrwKYOrvq52A68EjC7W/eZth3JwMR1Keg4aUqxs/Ngao?=
 =?us-ascii?Q?X2UmV+mRVMBbHOxpawPyGuI9G7LtCD3yxawh30E1aHU/Ea/KBACUqlt+h5AQ?=
 =?us-ascii?Q?hAExQS0XpRUh089jU+8Up9wicaniktwOCL3rggebW1ztYhguIY3Gjfy3QAyU?=
 =?us-ascii?Q?uZWczjM/kok+/Sce259zEP1kCMTbhn2v4HGO6ObMwqPQQ1VXlOYB7Pq4+OBE?=
 =?us-ascii?Q?atVzPXpDkO9Fg4tbTHtAvbOa6cDHk/YQYT4VrB5el8B9mc+HpsphPbsapxZh?=
 =?us-ascii?Q?rlgTj4k7MholS9rErmv+LXBMX+7YmZ3BEk58L2G1bPPULL7VkWx5iglAVu9s?=
 =?us-ascii?Q?XcxzWZTM9rtQgwZx54F5WgNOdyIH+M69jsjSq/yVkG+qrX1PRyQnFti/8PCo?=
 =?us-ascii?Q?AnGL5J6C0JpF/spS2hoEK7iXfWOA65a6ZFLujGkwVwEsoUSKsApfRQZkYeSo?=
 =?us-ascii?Q?7odHhZZp0y4JDSf0WZIT+lUK4C7RsUH673ct9Q1vbKCaXfM8V6TSOSLg7T2U?=
 =?us-ascii?Q?nlPU+4lobWotyMUsP90nLlK/8tnAqQ44tD9fAW1502nuVxYvkYQXKjKE8nf1?=
 =?us-ascii?Q?G+7aNUz6KxH0OhYgGZQK8doSMcj3LRorj6sopiA20AoaFPPJbkm31bkcXp/3?=
 =?us-ascii?Q?LNHZhzyVZNwLt+eS8lew7dBLVxlpa/l5FVfC4A5CIZ+dPzrwQWKvbbd4wVfz?=
 =?us-ascii?Q?ypb+E19tO/+cINuWWUCgZzHUmqvOo+9xh58BJsGT0U2wZQI0Y2ZTA1nt5wb4?=
 =?us-ascii?Q?y/DUm0C2KJZmiYJ2akwqqDAKmD308q3dDCabRUPRAbb7MxImRjebd96sjqV1?=
 =?us-ascii?Q?ddjlC2E236qOsD2rlQLBmCFdlaYocftmRONqIwMSeRZKmqJ8u9/IUuiAgeXo?=
 =?us-ascii?Q?5LCeUybwb94EL22/AUgpUj8v/+1cH1kRQKDr9xD/wLmzfqAKoTw6VHho/OR1?=
 =?us-ascii?Q?eJTT2AtJoR7tBklVrZd8ncTXO6JseTm+bFeJP4faXZLvW7WUhp0/QkmqFIgY?=
 =?us-ascii?Q?7o8jw/2C2qf2I7TyRDWL8aF3rmyfVoaFbC/7q5dYhyaa9KI7IS2CR7LZoQn5?=
 =?us-ascii?Q?ZFlwYL6h3s4kXFbIEfIr+MzhA+fZTw/ySCn8Iyk2UrtTydAKaorg3A9yOHDR?=
 =?us-ascii?Q?O9C6xlZFBsU3t7w=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAWPR08MB9005.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(10070799003)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9AEDE525879DF74088692331758F65C1@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11503
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A63.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	d3744521-46eb-4b21-7f58-08ddf9d9277d
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|14060799003|82310400026|376014|35042699022|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?myI+NjuBWVKznoO89IWpMlT3aD93IDjbZ4qpMwIq8teSzIn96cPrkvtsuYoi?=
 =?us-ascii?Q?xUrawKTN+wkQqkd0jK9axJkJ69BmlxOZgN6mAanhLAwXiH97A0Pmm2mafZ24?=
 =?us-ascii?Q?DMmu7FEcvL01NsJppFd7Ih4NILWpnJCh98EY+oDCnBDTZJaC5ZVKCAJZco9L?=
 =?us-ascii?Q?MHlQ9w/BIsPIspARlBEvvow4N3J3/TVgaqiD7PDv7Kh2A41nrG/4b9Vq2w8p?=
 =?us-ascii?Q?fv19qEYeIBzHTR68ueb1C+Vz/h1pwGgJ6Kwv29llFRbZZFt3rO+9+pfHAvsg?=
 =?us-ascii?Q?dDZjYrr76o4X1oIxwp7NMMe8mSyT4ygqNs6fbpbADqoT1bbBIJf0v2dYXdqo?=
 =?us-ascii?Q?ulIz1TAny7ylW1UZXykvNrOWOYOjPn0gewNcGWCG9SphbnsrluHrNAKvA6on?=
 =?us-ascii?Q?PEze2BnNNuy8BCpZqbvfItdXjeploRv2UdIZ/U5VzdIYRE8c7pzwNkx1e40X?=
 =?us-ascii?Q?5K2Muzxadw4bkC9t8k0X8lf9Zwyt2YBC1YuF/5Kuta5fICC6vtse1RtsFUh9?=
 =?us-ascii?Q?tMXUXdyH1eylWI3fD/XBZxZTyAma48viwQslh6V69eo4ZFqLkoajs6iJTVpm?=
 =?us-ascii?Q?m8XvDlo7gl60l7zMOqOSTXVGd6+Ky9QgURwABnkODujI0ZGHtcxy614MVua8?=
 =?us-ascii?Q?i/rmqZB9O6P8b5w2p5MLNeuwnNewIBnsL5SP6V0u3ao+qRUIBBCRk0Io1bJo?=
 =?us-ascii?Q?FlTenCdzT9bwnb8AGOrNP4VPb6nw9P9DX9exWaoQcf3uXCY7zLlHZnOg8KJT?=
 =?us-ascii?Q?RCgA+aMak6Exi1ALQYFZtxl8RGo0mjujELEErSIE1PBVikzYNZ5q19R1o8pG?=
 =?us-ascii?Q?lskpG6KM64iw9+M5oVwkwGBdZI5vxKxfj/Qc8/W49nisXD2B+Dy6LjWxNVqT?=
 =?us-ascii?Q?uRFglxh0+eQAx/QmsUPCcutvtfeEPlYC8PkFqS81NJC9vVmdL9KY2PtwTpuQ?=
 =?us-ascii?Q?+2HBUP4I8IAtE2Seq7A7b4RiGleM3gKoyXg10MPB/5tnlzP0e1iugwvuMeE+?=
 =?us-ascii?Q?RQJWO5t3U+jUfBZHiwOEqKQY+JShZaICe606L3EPgEWaXgJuXZGkeJTgqlCi?=
 =?us-ascii?Q?igpy6EUavGn7H2TqW6JX0UqMOR7fknJjYnA1DP0pR5q/cRQXQrh5alL63k7b?=
 =?us-ascii?Q?zHeMHQ5Tgl+OCL0nL1odPklsg7ksbQ8IiRMQdCwLmRU412LcJJt6RN1ymQY+?=
 =?us-ascii?Q?aY37e1K9o35J3MvWoFMxposoW5h7PWVcQ63cgBZrANla3dJhp1xvSnb73Ms7?=
 =?us-ascii?Q?fIxL7iGfbzILtxDqOYWEpDaXgOyvx3TUBqpKlv65yAx5bZi8THrGCWPYUcQE?=
 =?us-ascii?Q?WK3Mnbuh/RkUSEH/INMLY0P4bHRcVOCba97tWQKxnGWdYQz3Vtzi/kObl8LN?=
 =?us-ascii?Q?5k45s+PBpjOGE/d24PbkgUqsGdWc/fSCaIXJZMcV62mugCtYkWitqpGBezJn?=
 =?us-ascii?Q?IXAC+40i9bAcAcgftTmltyZRLAk1QUQD5SbFrEJkXJ1QdJRPSB0nB2nKxQcx?=
 =?us-ascii?Q?SdBZo3pOt2wOhm7Qk1erxDnYrKtOotfNKqZD?=
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)(14060799003)(82310400026)(376014)(35042699022)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2025 13:09:14.5742
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 47d2de23-cc85-4bc4-c9af-08ddf9d93ad3
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:
	AM4PEPF00027A63.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5319

Hi Ayan,

> On 19 Aug 2025, at 13:27, Ayan Kumar Halder  w=
rote:
>=20
> Define the requirements which are common for all the commands.
>=20
> Signed-off-by: Ayan Kumar Halder 

Looks good

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes from -
>=20
> 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).
>=20
> v2 - 1. Specified the register details.
> 2. Specified the type of buffer.
>=20
> v3 - Fixed some wordings to make it precise (eg register details, bit fie=
lds).
>=20
> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 60 +++++++++++++++++++
> docs/fusa/reqs/index.rst                      |  2 +
> docs/fusa/reqs/market-reqs/reqs.rst           | 16 +++++
> .../reqs/product-reqs/version_hypercall.rst   | 42 +++++++++++++
> 4 files changed, 120 insertions(+)
> create mode 100644 docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> create mode 100644 docs/fusa/reqs/product-reqs/version_hypercall.rst
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/r=
eqs/design-reqs/arm64/hypercall.rst
> new file mode 100644
> index 0000000000..82ecf690a3
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> @@ -0,0 +1,60 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Hypercall
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +Instruction
> +-----------
> +
> +`XenSwdgn~arm64_hyp_instr~1`
> +
> +Description:
> +Xen shall treat domain hvc instruction execution (with 0xEA1) as hyperca=
ll
> +requests.
> +
> +Rationale:
> +
> +Comments:
> +Hypercall is one of the communication mechanism between Xen and domains.
> +Domains use hypercalls for various requests to Xen.
> +The exception syndrome register should have the following values :-
> +ESR_EL2.ISS should be 0xEA1.
> +ESR_EL2.EC should be 0x16.
> +
> +Covers:
> + - `XenProd~version_hyp_first_param~1`
> + - `XenProd~version_hyp_second_param~1`
> +
> +Parameters
> +----------
> +
> +`XenSwdgn~arm64_hyp_param~1`
> +
> +Description:
> +Xen shall use x0 - x4 core registers to obtain the arguments for domain =
hypercall
> +requests.
> +
> +Rationale:
> +
> +Comments:
> +Xen shall read x0 for the first argument, x1 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..7e3912c8f8 100644
> --- a/docs/fusa/reqs/market-reqs/reqs.rst
> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
> @@ -79,3 +79,19 @@ Comments:
>=20
> Needs:
>  - XenProd
> +
> +Version hypercall
> +-----------------
> +
> +`XenMkt~version_hypercall~1`
> +
> +Description:
> +Xen shall provide a hypercall for the domains to retrieve Xen's version,=
 type
> +and compilation information.
> +
> +Rationale:
> +
> +Comments:
> +
> +Needs:
> + - XenProd
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fus=
a/reqs/product-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..b824c539b0
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -0,0 +1,42 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version hypercall
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +First Parameter
> +---------------
> +
> +`XenProd~version_hyp_first_param~1`
> +
> +Description:
> +Xen shall treat the value stored in x0 as the command number for the hyp=
ercall.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Second Parameter
> +----------------
> +
> +`XenProd~version_hyp_second_param~1`
> +
> +Description:
> +Xen shall treat the value stored in x1 as a domain virtual address (mapp=
ed as
> +Normal Inner Write-Back Outer Write-Back Inner-Shareable) to buffer in d=
omain's
> +memory.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> --=20
> 2.25.1
>=20



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 15:24:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 15:24:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127821.1468383 (Exim 4.92)
	(envelope-from )
	id 1v0iOM-00020n-Ok; Mon, 22 Sep 2025 15:23:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127821.1468383; Mon, 22 Sep 2025 15:23: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 1v0iOM-00020g-Ll; Mon, 22 Sep 2025 15:23:50 +0000
Received: by outflank-mailman (input) for mailman id 1127821;
 Mon, 22 Sep 2025 15:23: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 1v0iOK-00020Z-P8
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 15:23:48 +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 1e033170-97c8-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 17:23:40 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3ee12a63af1so1984001f8f.1
 for ; Mon, 22 Sep 2025 08:23:40 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269803601e3sm136417365ad.144.2025.09.22.08.23.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 08:23: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: 1e033170-97c8-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758554620; x=1759159420; 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=cPCr2LK5pv/2B/54ptDrAwYpqRUMnsSaenADRpPpUkA=;
        b=baHE3IgFpIfgK3iXDeXP+Lxl34bvYPtWovnHQK8cyUM+mrAk5aWIUDHYlL/p+hZCxu
         9nYbi+kCKjRdKUBhkRlSBUbY4+2wReLtuyAmiGn0LFGn89uUQI6L45ul3v77B5FujP0g
         I+ZsaXi/45XFCxxR9OUzfMbS2ufPA7lFGYTC9/cFyiqUxPadiCMLC171jOST+873ejI3
         cm/dbsBtVBbOHNNhq+MknbiyQPsCJ4k8sVEfuq4kbIDzvS9hcCXQnIXHdh3kEI6m3Lq9
         bmYDOZKsT9lcQpd9hCYtENhXxj5kLg1MRqEumzbirEVqtP1Qxc1CFwlYE9/JqbRl0OYv
         ByGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758554620; x=1759159420;
        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=cPCr2LK5pv/2B/54ptDrAwYpqRUMnsSaenADRpPpUkA=;
        b=KP4uAnA4fDYsvkR5zWZPp/s/5SDTAUQmGlluqN3WQ2TeVYfGgFUt7+IeD6MtMRQ3jS
         zbq66kvMtSvoWQka1vkls21t2ErHZCMr/7O8w1Cchlw1cez3nu274ou0bZ+jsdxsxhHu
         HHhQNdkJqAql8+8qk3AqtzMvO8lkI16ft1dhbbmOETJHMqrWzT+cMy2W91gx0BQoxMC/
         vXiK/rsfYQKwvjM+jgwhXd43Vaawp3YQMT4A0rD+ppUJioiIKHxzOeY6VTX9eSraMyR6
         Ez1U10hOhszOmRosreOgoHPw6qREdqLrRELFfyvovTcfivFKwS9xTssr34xVfS4HVj4L
         6imw==
X-Forwarded-Encrypted: i=1; AJvYcCW18AQftZN7/nU/dOszZrKHzWNvRvUeWvfc0tjojOmhEUvp3dW+/EFtM+Dfoy2EFCGnnTGoplJv9zw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/faT2UaxSy9NNjUx6Vj+L9NTBjTNE7igTQoxEyznd8L56zGDw
	7PPeYavjXQ02Uxs6EAhre6Jcad+gmu8+zkROOU8tqpLBLzxZisZnCjx7UDfwKA841w==
X-Gm-Gg: ASbGncvoHu9D/uuVLoqHooFBc4CWvXim6k6VdVPGRU1sQAkc0aOgFvB6YRqpBM7Q4uP
	eBcQJf84OLpthk63R9/fkLxUxViBPbdMpjCb8ubFiN94v5AASzae8ABGcwqzfMYM4lAgXpVZWhm
	45i0/uNr0derfiC/PCo3U0WSYaHBMru6faGYopOjc5QFx+fjF5M6QnhAgNTcG3CGhRR4jOEibbS
	IeEwCaqtyulrqI7XJu4K3PTjuZiLa/5e1eqITCKP3FTGBKtYZPFvLcgwYBvBvLW6Mp/U2klhEAd
	W+iCKzc2pM+xFh5w9k+90hef51QobVThkGsGqS7iZhDQVx4ffeupgtKtupAs3pBPCo7Hg1oN6a2
	2zO3NoSu8X1DLrEXnypYkw8mJHb3sT7Ot
X-Google-Smtp-Source: AGHT+IFD9luHa/mC3+npNF1k+2YxYcrMfVgTGhDyzvabyJlzV52bsSqXYpGMmgo66b+uUPbwXOIGfQ==
X-Received: by 2002:a05:6000:22c7:b0:3ee:1357:e18f with SMTP id ffacd0b85a97d-3ee7bad15e4mr11203323f8f.12.1758554619677;
        Mon, 22 Sep 2025 08:23:39 -0700 (PDT)
Message-ID: 
Date: Mon, 22 Sep 2025 17:23:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/domain: introduce DOMID_ANY
To: dmukhin@xen.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, xen-devel@lists.xenproject.org
References: <20250920174732.1207847-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250920174732.1207847-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.09.2025 19:47, dmukhin@xen.org wrote:
> From: Denis Mukhin  
> 
> Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
> of the code.
> 
> Update all relevant domid_alloc() call sites.
> 
> Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v1:
> - moved DOMID_ANY from the public header

This addresses my comment, but not Andrew's subsequent response, specifically
aiming at ...

> --- a/tools/tests/domid/harness.h
> +++ b/tools/tests/domid/harness.h
> @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
>  
>  #define DOMID_FIRST_RESERVED            (100)
>  #define DOMID_INVALID                   (101)
> +#define DOMID_ANY                       DOMID_INVALID

... avoiding the need for any such secondary definitions.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 16:28:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 16:28:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127839.1468392 (Exim 4.92)
	(envelope-from )
	id 1v0jPC-0001E7-BZ; Mon, 22 Sep 2025 16:28:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127839.1468392; Mon, 22 Sep 2025 16:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0jPC-0001E0-8l; Mon, 22 Sep 2025 16:28:46 +0000
Received: by outflank-mailman (input) for mailman id 1127839;
 Mon, 22 Sep 2025 16:28:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v0jPB-0001Du-PM
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 16:28:45 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3451007a-97d1-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 18:28:43 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-45dd513f4ecso34184745e9.3
 for ; Mon, 22 Sep 2025 09:28:43 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77e8e756721sm9890087b3a.71.2025.09.22.09.28.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 09:28: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: 3451007a-97d1-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758558522; x=1759163322; 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=v2E7XnAKQsYmiy+PpiYdnLnz2lCA3Ze9v+aTiY5r6ns=;
        b=JanMKKV1k2ju9Nc6Y2aUT/mKbgu+rhuUpo+dstwS0q0djeYXB8QCg17K+jvzMvMg42
         pca8FIxdwPm56DfR7yOi2wUwo7WLvfYYRR6u8J9RCPPBwP06w1s4/clvVoYHtu37VEA3
         6Zm9IogowcZ+a/r4fEQ76YyY8UzT1Hwhh8h+2wPST1G+iJOrZWfBTAKETSwV98MXgr5W
         Un9mx2JCuClqIvC9mt4oGSYjaXuybaHIhqTEVXN2OyGoF+CzbLEJ/LSFZBiFMhBVXWfa
         SjJ93uzbhFxMxS16JxZVehtXsD/SBPZB7vRF54FDxorHd9l/99fH/J4fzKjTqk+ph33g
         9CKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758558522; x=1759163322;
        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=v2E7XnAKQsYmiy+PpiYdnLnz2lCA3Ze9v+aTiY5r6ns=;
        b=tQ7eTeXbqc215QRiPuksHLLRgnkv/GApW6gDUwQPGlfaERR0cBUeKSoZ1THmprWH8R
         GybehXCv3naCKWmZzwheuVoP2zg37txqTGIVjyzsXfPiEKnHg+qJi7wt0EPcoVgSGiN0
         2IxC6vmfoJiJUun3zYAYR1fGAv0Iy4ElykTIG80tPYkzuMTgyYOxO53lAPaDTujQKMaX
         4805TmHzl1NAbfmaQLCWyvt2+zEk3cRXex8m1T34+FmgJVXIvlzapFw/CJCPJQC8L71l
         OktZvr7QRrgpYHVCpF8vtSzLifLeYGj4fpDNs1xLbBgwoXNoUamtXTo8RqAQHMfLyJri
         OIhg==
X-Forwarded-Encrypted: i=1; AJvYcCUg+8DUnw1Khy+A+9hlDPo5wplnyDgmPGLlWBoc+uhiNErgehpqKqodPTYuXvDi5YynbrfL24glBrs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxo1wkLGmoHR/p0vdFDcMQ1MLnIeExSnCmptiKN66x1Sj9vrnQa
	CdK/5+GuSRvQHqcqA0kQawhwKf29ZYqtLl2VQiIK3oz86NOPU5QClbDilQQKdIMHGQ==
X-Gm-Gg: ASbGncs5oXRbujWQFnQvCN57p2vQuxSRwF5jr36ziZN1sRW397bYkGXPue54RZpJKNQ
	lLdD79Zsx5yFcsPYYYfE0eDx8prLzYg5BKfrzJ6+G6CIQ6Jz6tp7IZHLwGLPoa5C5qVBmSfi/Vl
	sqMaJsCNWxKfCBPr6r7a6QNTTLyR8GbM4mg3iLrIpE8p0DcO4zhOEjER/zYXvar/ospg+WXtN5e
	pTbj7hY7X7mUDtm44WHrQgwwfQuLLeTJEqIufyEH9habpvVYVbBnb2RXYK29QjOxUehx2UadT5s
	bdsP5WsGffqWSqoCNqQXACphToNBI5JmA2FxIf4iPPiMLMhGhO5hUsK3um0NnhPWKf71zRLEIMu
	XO6rYAzwk6iBZ7lL/hMa/zdsc3EmxMMUY+Y5q10nSg3o=
X-Google-Smtp-Source: AGHT+IH3AAfGlFF3EAvO0Jxe5BSurtG2ey0NoLs3UGGAGKnP29neCtVU74C/wJhuDm53zZpb6hFyDQ==
X-Received: by 2002:a5d:5f87:0:b0:3e4:5717:368e with SMTP id ffacd0b85a97d-3ee7c552b21mr13199665f8f.2.1758558522521;
        Mon, 22 Sep 2025 09:28:42 -0700 (PDT)
Message-ID: <7b51f40d-7ac7-460a-891d-afe1d9ab8991@suse.com>
Date: Mon, 22 Sep 2025 18:28:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 12/18] xen/riscv: Implement p2m_pte_from_mfn() and
 support PBMT configuration
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: 
 <4495c8103548447f9a11963574a4cb9e01090e7a.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <4495c8103548447f9a11963574a4cb9e01090e7a.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> @@ -318,11 +331,87 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_pte)
>      p2m_write_pte(p, pte, clean_pte);
>  }
>  
> -static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t)
> +static void p2m_set_permission(pte_t *e, p2m_type_t t)
>  {
> -    panic("%s: hasn't been implemented yet\n", __func__);
> +    e->pte &= ~PTE_ACCESS_MASK;
> +
> +    e->pte |= PTE_USER;
> +
> +    /*
> +     * Two schemes to manage the A and D bits are defined:
> +     *   • The Svade extension: when a virtual page is accessed and the A bit
> +     *     is clear, or is written and the D bit is clear, a page-fault
> +     *     exception is raised.
> +     *   • When the Svade extension is not implemented, the following scheme
> +     *     applies.
> +     *     When a virtual page is accessed and the A bit is clear, the PTE is
> +     *     updated to set the A bit. When the virtual page is written and the
> +     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
> +     *     address translation is in use and is not Bare, the G-stage virtual
> +     *     pages may be accessed or written by implicit accesses to VS-level
> +     *     memory management data structures, such as page tables.
> +     * Thereby to avoid a page-fault in case of Svade is available, it is
> +     * necesssary to set A and D bits.
> +     */
> +    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
> +        e->pte |= PTE_ACCESSED | PTE_DIRTY;

All of this depending on menvcfg.ADUE anyway, is this really needed? Isn't
machine mode software responsible for dealing with this kind of page faults
(just like the hypervisor is reponsible for dealing with ones resulting
from henvcfg.ADUE being clear)?

> +    switch ( t )
> +    {
> +    case p2m_map_foreign_rw:
> +    case p2m_mmio_direct_io:
> +        e->pte |= PTE_READABLE | PTE_WRITABLE;
> +        break;
> +
> +    case p2m_ram_rw:
> +        e->pte |= PTE_ACCESS_MASK;
> +        break;
> +
> +    case p2m_invalid:
> +        e->pte &= ~PTE_VALID;
> +        break;
> +
> +    case p2m_map_foreign_ro:
> +        e->pte |= PTE_READABLE;
> +        break;
> +
> +    default:
> +        ASSERT_UNREACHABLE();
> +        break;
> +    }
> +}
> +
> +static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
> +{
> +    pte_t e = (pte_t) { PTE_VALID };
> +
> +    switch ( t )
> +    {
> +    case p2m_mmio_direct_io:
> +        e.pte |= PTE_PBMT_IO;
> +        break;

Shouldn't this be limited to the !is_table case (just like you have it ...

> +    default:
> +        break;
> +    }
> +
> +    pte_set_mfn(&e, mfn);
> +
> +    ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK) || mfn_eq(mfn, INVALID_MFN));
> +
> +    if ( !is_table )
> +    {
> +        p2m_set_permission(&e, t);

... here? Or else at least ASSERT(!is_table) up there? Personally I think
all of this !is_table stuff would best be done here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 16:40:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 16:40:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127852.1468403 (Exim 4.92)
	(envelope-from )
	id 1v0jab-0003oF-CY; Mon, 22 Sep 2025 16:40:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127852.1468403; Mon, 22 Sep 2025 16:40: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 1v0jab-0003o8-94; Mon, 22 Sep 2025 16:40:33 +0000
Received: by outflank-mailman (input) for mailman id 1127852;
 Mon, 22 Sep 2025 16:40: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 1v0jaZ-0003o2-VS
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 16:40:32 +0000
Received: from BN8PR05CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c110::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d4f1bae1-97d2-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 18:40:24 +0200 (CEST)
Received: from BY3PR10CA0002.namprd10.prod.outlook.com (2603:10b6:a03:255::7)
 by LV8PR12MB9336.namprd12.prod.outlook.com (2603:10b6:408:208::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 16:40:19 +0000
Received: from SJ1PEPF000023CF.namprd02.prod.outlook.com
 (2603:10b6:a03:255:cafe::5a) by BY3PR10CA0002.outlook.office365.com
 (2603:10b6:a03:255::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 16:40:19 +0000
Received: from satlexmb08.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_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Mon, 22 Sep 2025 16:40:18 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 22 Sep
 2025 09:40:17 -0700
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 22 Sep
 2025 09:40:17 -0700
Received: from [10.71.195.192] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 22 Sep 2025 09:40:16 -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: d4f1bae1-97d2-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TQIFb+LYaR4ww7P+oUv7RdjG4hSuKWCRvyFoEN+QOq9muiK3x1c3BaPKwDoSgmmsNbtqJws7tTEfab8H6WBMbQVGO4TtM4D0G9v3Ok2RjSi3+5vQPupJqyyIkssHQOKpXkYg5f6FgTzFsQzwvtOkbXyLs5vGmTBDc35K6Xs2Jl9SCaq3ldQEkfArRvMuToSmBQuvc8PuKCTzYIzfSfCM0Fm1I3ZvfUCSPa8Ay/w+chLuEgwB78ajVRIiaj0Qb5BF9EWf/TqA8AIwri7oP8mof1H0QRfHvofzl5fNPFnLzUG3RVWVTqk8axNscUw/8Mz/b8qOug/8oOm4u3F0dLddWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9KSwD4q0Aahid8xmhKhxDgqFMYslyx5ICq3471gYpE4=;
 b=pnFnAbj1V8Gev3nN2Y+B+qcSzKKj5EIOlyKXba6gihaLRyw5RhxpJJj2MrPE1x5sjkyFKZybgKEMwVV85pbEpbrDw7FgHzJSiif6YzqP+kisi9ndc+SJUNqC8PZu3ytnSN+oTCP5wAM4sJYvGUx7443+2VpIG02VnjpwTctD2U5Ob/5WuRTb6v3WC5mJH2Rzp6LQV7vqUYgJ1cL07qMgpdmbu2fBK7Y6xRd13u6uZnNEcl32nW8x6KyVFOC51lDEVCZ58L8VelX/3wUvpGtGzKMGWyKpbsB2cVpgsyVPfrry7loEXgVxRVp7vdnb6D9YY3dVoHoF0dL+Caxf21qSHg==
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=9KSwD4q0Aahid8xmhKhxDgqFMYslyx5ICq3471gYpE4=;
 b=ah30m11NqOZ3zGH6j9XnDn/Y/RUGlYCnj1ZQtMjuveddGvjzxMMFbJmmc1IDF+xoYCYIDd7Uh6cJfO66nVEe+9ZzYf1AHKrb3+jdURoUVFQ0PtHbtSKL2Kjs0ZE/o35WgmRFtttxUQytZNby3bTnHuR0EAr1LHlz6uwvWVN3YJM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: 
Date: Mon, 22 Sep 2025 17:40:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Ayan Kumar Halder 
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
To: Julien Grall , Ayan Kumar Halder
	, 
CC: Stefano Stabellini , Michal Orzel
	, Bertrand Marquis ,
	Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
 <7bbd581f-bfa4-444e-9c76-bcb833a2ec74@xen.org>
Content-Language: en-GB
In-Reply-To: <7bbd581f-bfa4-444e-9c76-bcb833a2ec74@xen.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CF:EE_|LV8PR12MB9336:EE_
X-MS-Office365-Filtering-Correlation-Id: 0a93f81b-d1d6-49f9-8bfd-08ddf9f6b74e
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?OHZzMjFnaTNCMTJ3YTA1K1RwT2F0OUhFcnV2NXRkUFBiNmpOR0ZSOEszMVg1?=
 =?utf-8?B?QStCRkxHdGJUdUdYMUZVWVZkS0duMmUyUzI5NDZtZmt6RWNxYmJKK0swalVv?=
 =?utf-8?B?TXFNeTcxMzlMeE4zaGtnQ3NoTmNKd0twMW5GMUgrUDNiYVVBU2Z0Zm9xcjVV?=
 =?utf-8?B?clRWK2sxVmZxSkkzcEYybDIyRmV3dlFZNG9qM0VMd3JGK0I3ZURWdTJZV3Q3?=
 =?utf-8?B?WktMNXVPUFNyaThFNkFIbjd5c2VPVm13UnBNaENaV2JqdlY4UUhZNjcvRWx2?=
 =?utf-8?B?SmhaQUU2b2ZHM2F0SnJDL2pUZEsrRzZHM1B3OWorWmFvMzJ4RGVZT0JyTUsv?=
 =?utf-8?B?RUVWemg2cGw4SGZka3gvZ2VkaThWcnhxTHM3RE12REdLNTZFN3FGWWw0WTlj?=
 =?utf-8?B?MHByQ1R6SmYxbTFYLzk0dGZXNjJwMFN0bmxqc3BEbGw4OTVCcUFXZnpkMk9I?=
 =?utf-8?B?aktJMVZEMlAycFZMb01JUEpzWW9VUTBwMFBMWUsvNWlnbmd3Yk9ZcG1uRXBY?=
 =?utf-8?B?QnRIeHI4TmFtd3lRUGQyNHkrdkF5L1paMGVPYmxZNjJxVmJQY24rMFdOZWF2?=
 =?utf-8?B?djFuMmJubVVncWdZQTNKWFhaWHZDMlJ0aTdTV29BclNTZlBISDFaWGJNM29r?=
 =?utf-8?B?SW9RVFZOWnVuWnlDQTdpZmNqYzFya3pOWFZvTDluMVBrNVhkWUFpWHE3bHZK?=
 =?utf-8?B?cG9NVGZrcThLb2NpTXBqam5kaHZRMXZFR1ZqQ0lOZ2xhT3ZDaVQ4aUE2WEZ0?=
 =?utf-8?B?Z0d5VXlLNGRYRzltdGUrOUdCMVpPc3B4Q3lsOWFZN3NqejFiSVVkdHliaDVE?=
 =?utf-8?B?aEo5bzBzVEV6aVEvU1NMU3NJNnBPYllSSkdKTXpLdm9hMlFsdFlMdkJBTFV5?=
 =?utf-8?B?SmxWRFhBRWM2eXdVWFJSZEhrQlNtOGdjREhIOHI3SU1GUWxlSFh2OXd3MGFX?=
 =?utf-8?B?U01KdU4yVkpxR01PUkk5RGVTUC81Z0lwMS9rVzNHejVpcStkSzkxN2k0aVYr?=
 =?utf-8?B?NEVCS0VIYVE3WTJKbVVqckNFYUhnZDk1eWh4bDFzeDBmUVBkeEUrOGVGbkhz?=
 =?utf-8?B?dWRna0xrRGVNUTVzMDNSd2lvalRIRTBSZjd3R2orRzV4aHdiWi9SaG1QRTYv?=
 =?utf-8?B?b3pnUVpTQ3VtRWVIUk5MbTlETEEzRWdCOSt5VDNncDFHZktxWkF3aVo4N1dZ?=
 =?utf-8?B?S21FdmxvRGFjZHpIeUlvTVVBSEJKV0RxRGxGNDhlTVduNDVGNEZQc0VscXJO?=
 =?utf-8?B?T1dOS3RCcXpuN0o2cmdUckFSMGxnTFF6a1VCRUkvRTZuaDZYeGxsaGtYZ1NC?=
 =?utf-8?B?Q0k4YVZiMytjS25rcGVrTGNxRnhtNTJ1eHN0T091dFdwbjJEWW5Tem10eFVP?=
 =?utf-8?B?dm9ucUZUYk9NdzRzZ1pZdHdFUUNTclFveExqT3lDazFsQ2l0cjJIZUJaakth?=
 =?utf-8?B?cDdMaEZHOTlFMUY1bkt4NDNTVDc2WmhTWUx4YWs0ODh0dXJQT09Jc0RxYjYw?=
 =?utf-8?B?WnRlcUdzeldHRTVQRlRPVmdvT3VmNFk3WnVwa1QwMlNoSHNEZXBzY1kzTjEr?=
 =?utf-8?B?dXY2bEFVdzUxcCtLcno2UC9LRkVLZmpIdGxxR2p2ZE9wOVUrbnlTMThLVk5h?=
 =?utf-8?B?OXcwT2xpYUUyR1BCQWx6SjhqYXVRYjNhKzBCV25PTG5QWE5wQ1N1VWJEWkUr?=
 =?utf-8?B?WHBZLzNGdVZQS25WRGFhQnBTYTA1NmRlbC9Fak1BelBZRzA0bklORGlvWmwv?=
 =?utf-8?B?aHdHaEZveHBMdytQRHdPR0JKZjhPOHdndHJXVXlmSktDUTlJN3lPWmhXRFhj?=
 =?utf-8?B?Kzl2QldnUEljdjFsaHAzVTdieFRqUFBtVjZqdm1LVzBGeGJHbW00T0pnV0tj?=
 =?utf-8?B?TzRpSG1CRG9NRVNOYTRGS0tCSkpsQmFVb2daQXIwUk9jcVdDRS9qNnY5bWdY?=
 =?utf-8?B?MXB3UEFkMTJRZGpycWk3ejJ5WmJZaGc1WFR4QXZ1QkhzejB4dzdFbEFCZjZ3?=
 =?utf-8?B?cC9ocy93QU53RUtqK0xYalZTN1Fzc3NoTEp2S3paZjZKSWZUSGZTUTNrQXVa?=
 =?utf-8?Q?cdjcWJ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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: 22 Sep 2025 16:40:18.7786
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a93f81b-d1d6-49f9-8bfd-08ddf9f6b74e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023CF.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9336


On 15/09/2025 12:14, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
>
> On 12/09/2025 18:00, Ayan Kumar Halder wrote:
>> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
>> Test that Xen is able to generate SGIs.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> One of the aim of functional safety is to test hw/sw interface. This 
>> means that
>> Xen is able to configure the hardware correctly for the desired 
>> functionalities.
>>
>> Normally this is tested from the VMs. For eg if a VM is able to 
>> receive irq, this
>> implies that Xen has configured the GICv3 interface 'correctly'. 
>> However this is
>> a high level (or integration) test which uses not only the GICv3 
>> interface
>> between Xen and VM, but the interrupt injection code for Xen to VMs.
>>
>> We want to have some kind of unit tests to check that Xen is able to 
>> receive
>> various interrupts, set priorities, etc. Here, we have written unit 
>> tests for
>> software generated interrupts (SGIs) as example.
>>
>> These tests are expected to be triggered as Xen boots (right after 
>> Xen has
>> initialised the GICv3 interface ie gicv3_init(). The aim of this test 
>> is to
>> check whether Xen can trigger SGIs after gicv3_init() is invoked. If 
>> so, we can
>> claim that gicv3_init() was done properly to be able to trigger SGIs. 
>
> To clarify, this only guarantees that the boot CPU can send SGIs to self. 
Yes, this is the idea.
> Secondary CPUs are brought up later and will need their own setup to 
> enable SGIs.
Yes, we will have separate tests for them.
>
>> Likewise
>> we will have tests to check for priorities, SPIs, etc.
>>
>> A script will parse the logs and claim that Xen is able to trigger SGIs.
>>
>>   xen/arch/arm/Kconfig  |  8 ++++++++
>>   xen/arch/arm/gic-v3.c |  7 +++++++
>>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>>   3 files changed, 36 insertions(+)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 950e4452c1..739f99eaa9 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -73,6 +73,14 @@ config GICV3
>>         Driver for the ARM Generic Interrupt Controller v3.
>>         If unsure, use the default setting.
>>   +config GICV3_SELFTEST
>> +    bool "GICv3 driver self test"
>> +    default n
>> +    depends on GICV3
>> +    ---help---
>> +
>> +      Self tests to validate GICV3 driver.
>> +
>>   config HAS_ITS
>>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if 
>> UNSUPPORTED
>>           depends on GICV3 && !NEW_VGIC && !ARM_32
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 4e6c98bada..eb0c05231c 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>>         gicv3_hyp_init();
>>   +#ifdef CONFIG_GICV3_SELFTEST
>> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
>> +    send_SGI_self(GIC_SGI_DUMP_STATE);
>> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
>> +    send_SGI_self(GIC_SGI_MAX);
>> +#endif
>
> Looking a the code below, it seems like Xen will not be functional 
> after running the selftests? Is this intended? If so, we need to stop 
> Xen as soon as possible.

Tbh, I didnot realize this with the current test. However you are 
correct that for some of these tests, Xen will not be usable. We can put 
a while(1) after it completes the tests.

Or, I can invoke machine_halt() .

The important bit here is CONFIG_GICV3_SELFTEST cannot be enabled for 
normal usage of Xen. IOW, user should not expect Xen to run domains when 
this configuration is enabled.

They are used to run baremetal tests.

>
> Also, looking at start_xen(), we call local_irq_enable() a little 
> after gicv3_init() is called. So I am a little bit surprised this is 
> working?

This is working i.e. we are getting interrupts. However, I can put the 
test after local_irq_enable() as Xen is expected to terminate after 
running the tests.

- Ayan

>
> Cheers,
>


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 16:55:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 16:55:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127865.1468413 (Exim 4.92)
	(envelope-from )
	id 1v0jpK-0005V1-Jv; Mon, 22 Sep 2025 16:55:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127865.1468413; Mon, 22 Sep 2025 16:55: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 1v0jpK-0005Uu-Gs; Mon, 22 Sep 2025 16:55:46 +0000
Received: by outflank-mailman (input) for mailman id 1127865;
 Mon, 22 Sep 2025 16:55: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 1v0jpI-0005Uo-Vt
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 16:55:44 +0000
Received: from PH0PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c107::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f7eb22f0-97d4-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 18:55:42 +0200 (CEST)
Received: from SJ0PR13CA0212.namprd13.prod.outlook.com (2603:10b6:a03:2c1::7)
 by IA0PR12MB8748.namprd12.prod.outlook.com (2603:10b6:208:482::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.21; Mon, 22 Sep
 2025 16:55:36 +0000
Received: from SJ1PEPF00002320.namprd03.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::2f) by SJ0PR13CA0212.outlook.office365.com
 (2603:10b6:a03:2c1::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 16:55:36 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF00002320.mail.protection.outlook.com (10.167.242.86) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Mon, 22 Sep 2025 16:55:36 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Mon, 22 Sep
 2025 09:55:35 -0700
Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 22 Sep
 2025 11:55:35 -0500
Received: from [10.71.195.192] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 22 Sep 2025 09:55:33 -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: f7eb22f0-97d4-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AONnWHxOaGCryV3CkYDXCKXjRiqerQvkqDFdBzF4YjrCSpd3A1XvmPZOsTDbWB4A7X4oM8q4YdTiOUl/Qy5QaoLbafyDoA8NDjZkcG72bFxcu6GnSXuUqA7xQYUjEoHyrMgOOnq/uerUcR4MZAgXXxS54N8lsz+DggTx6sm3ye6biCc53eq1G+oA2309OX7iBXo9eHYkJ/C8Tgs/lSdr7V5ylCtG299I8ijC8Yljz5sUF4QQ/SxDo/D4mKlgjWODoNftGZOiFDbpkR5xize+mM00ebQaO9g2/dQ6VVHjGnLNE0sW5mekCpDsJ91TYLJz56OE8wtaB3vWhpRMGdI2RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k+HtFtnHizkVwm3iHtIBny6Q4Lf+QYAEmQX1AOlj1jE=;
 b=hmo1Q3Ax+s0vrQLLTUxc2BDJ/1byBSiejORl9O3JVLpiYlVSGjFKjEaNJsgzuwC9JaAcDaOWJLlsw0+IM+0N/DPEW+z/itNV2ze4jM4olnZsG2M7v4szQ6CesHoAV2JQZZ8CzAMZtrL0nK+1S4jtQ0gJyFelpkqa+1srqt4L/Etb5j0N2gDvwFqiBBXMctFT3rcoEh/ufUql2KMZRCxn+U7LynVhb8Cv4FMx59jF3VTrHz7fZHl7uNom5yatB/WIQzlMBlmPU38ROLWDaYusAomX5+g9BWfu1V+d9jrATF0ODNCrphBurlHLAE+itN+tE/Hry2B2xD/NKp9InKC+BA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k+HtFtnHizkVwm3iHtIBny6Q4Lf+QYAEmQX1AOlj1jE=;
 b=B4DFnWJmSs9nYrCH8WDAufdhD6Iudi6BZ1a47R7/7uRBkTBpJLxLLtit7s7QBft2RvQfOAbO0cdMWt1CThmv/7Xh2xBRXjn8BjDZnJeis7TvqFHefX6w64UWmz7VLAN9XfUQ5DUIoAOMY1nNCCqxclgbiY4ypBV2nLzBnEhU0So=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <762b9d19-f1dd-4bfe-a298-d88ab8e7bbd2@amd.com>
Date: Mon, 22 Sep 2025 17:55:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
Content-Language: en-GB
To: Grygorii Strashko , Ayan Kumar Halder
	, 
CC: Stefano Stabellini , Julien Grall
	, Michal Orzel , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20250912170055.3077923-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-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002320:EE_|IA0PR12MB8748:EE_
X-MS-Office365-Filtering-Correlation-Id: c281d26a-34b8-4349-583b-08ddf9f8da0a
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?TXdLV05ZUE56ZkY0bzlqdFZnWTgrdEo0WWhPb0xQM1BGbk5DZGthM0xaMlFQ?=
 =?utf-8?B?MHMxbWxDZjlBSWpRcGVLVjlKSGNibU5JUWJDTmhSVTBNMFhYK2txVThxY3hG?=
 =?utf-8?B?NzZBbVdPSFRtWDBFdDF6bEJTT3NMWHBoOWowbE1hOXA1SFQvT2o1UHRrSG4x?=
 =?utf-8?B?MHlYTjR1eTVzMXFKOEdUT0h4LytxRmFOZFI1TFhVMDc2R1I0NDVTVVRySita?=
 =?utf-8?B?Q3RpOS9sVldvM2JTajJ5TFBSdTVJZmt2R3dNemVpUDJ4UmNSYktTcnpKTDVR?=
 =?utf-8?B?OW1tcHF5eHZPeWcxamJOazBETWJjTlliRlpyWWNvVnd3cmhTM3VkWE9WazNs?=
 =?utf-8?B?Vytucm5UVG9zSm5XZFplOHJoNGxVMHRKdkhJZDBxKzFMM1E4T3NiWC80MlJr?=
 =?utf-8?B?MkJOcXJHbWhwOEdINnZGL0NkbzJsNENVbzhxUUtsSURKNTFHaEplbkpIUHNN?=
 =?utf-8?B?SFZFU1VTWS8xbWxiWHd2MHZLcTlIdWFIbTZTam5DSHlQOEhqaHN4cnp6K1c4?=
 =?utf-8?B?RDIyUkhPYU9XM0xHUXlrWDU2dEtMYlJocktyNFZJanMxZVZFcFRha1ltTGg3?=
 =?utf-8?B?bEJlTEl4SW5KYll2aHZmeVJzcGtLb1BnZ2IvRS9lcXJhdzRLL2w4QStaSXov?=
 =?utf-8?B?UTlVa0xhblpqVVdyVWxTbWtpWGMxb2tCYmFOZ0V4WHQ4RWlabEdML0cvcWF2?=
 =?utf-8?B?bUlLYWlsNWJzalM3Wk1UYzlUTWFxYlkwVnlyalVMT3hxVU9Oa2p3ZDJCWFZa?=
 =?utf-8?B?a01KZ1BGV0JkakMzRHJlMG5sNVFucFZhbG9EWG5ySE50ekZmMHFjcXBOanMy?=
 =?utf-8?B?TGIrNk1VYmVScTZ2cXNtZlNnZXJiNy8ybHg1TTg4UGZndVFxWUg3VkNEUTRG?=
 =?utf-8?B?cDZuK3FnWDJiODdoMkxFbU5qMGlkTytwTnYzc0Y0MGpTTkFaVHNSVlNMek5j?=
 =?utf-8?B?UEVxSWl1Zm10OFFUQVM2Y3lJMFBYWmtLTUt2clhUYjhzSXhucWF1NkoxZEw5?=
 =?utf-8?B?dlhkaW1CY3RRT3JiWWRCMUQxczZ5blYrOXNCZnM1cit0OTlsQkMrZFNuZm04?=
 =?utf-8?B?Z0NuK3EwUytuTHFQQkhuK1Nod2hKNVRkZWJJSmdzQ25MT2Z4MUlpVWc5ME1P?=
 =?utf-8?B?eG5HRHpHb1kwN1haUkZ2cHByTGpWUjdML2NFUTkrUFhxeGJXOWhHcU5xc2lM?=
 =?utf-8?B?TmtjZmJIWVhWbEc0Y1hUZ2VJNjh4MkVBOVNUMnBMYkx1OERTMk53dHZMdGl5?=
 =?utf-8?B?NHRGdHVremE3N1pZL0FhVnhrNkNnNFpEd0cyZWdFV3VsWUNqRUE2WWZWc0Z5?=
 =?utf-8?B?aTFPemFmOTFqY2JkTHBBdmdwc0F3VUFTK3hadXhmckxxZVVRdmFBeWVBZFll?=
 =?utf-8?B?MFQySnRYcXU4V0pPdFgvNFE0TmpUWkZJU21sZkNFbk5LM1VhZ3RuYXFmc2do?=
 =?utf-8?B?Zll0ekg1dWpTS3h6VHdaN0VUWExoZGhUUitwT3F5V0NsaGN0MWRnUFZ4WEdH?=
 =?utf-8?B?TnNmZTlpQzJNNklHVjJRUFFtb3BNb2RxeTQyY21wcGRWMU5uMDBUNU9HNmQ4?=
 =?utf-8?B?aWJRRkk0QmVqenh5QXZtR2RWY1JpYnBpdG5NQUJSVjdVazJkc1ZDdzJ3Qzk5?=
 =?utf-8?B?RHBrcExEMXRPcktqb0FUWlhCdFdRNVBMM1k3a2Q4RWFvcVI5KzJkN0Q5bFRE?=
 =?utf-8?B?V2NTdndaai9LZEZTci9oTHAxQkRPdngwL3JqaGVwL1pPKzBITXdyVVZ0cWJv?=
 =?utf-8?B?WWVQcGZZbFNJc2MrN1NObjlvM1l0ZXJPY2JIY1JqejlvSEY5VXZ0UTBVODdB?=
 =?utf-8?B?UDBOUlJQTkFDemNsUnAyNG1oK1J0bVpwdWZTd1E5ZnV1QmI3aWRKQ1AwZUZB?=
 =?utf-8?B?VXhoMCtkOHBiU2s2aWJlcGFZRjlNZis5WlZ0Z0FXZzY4ZVkrUTYzN3I0WXRu?=
 =?utf-8?B?RFlSajJlMmtiMG5keTk1TkpnM1Q4MnB6UGU3akZ6MHF4Y0tpQzlYSXgzUE5Z?=
 =?utf-8?B?M1hmTHk4b3FHbVVmQld4Z2NCTEsydTR3cFdkUXNHcGptdUtxVjFkTVFkUk5H?=
 =?utf-8?Q?y/e7Gr?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 22 Sep 2025 16:55:36.0453
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c281d26a-34b8-4349-583b-08ddf9f8da0a
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002320.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8748


On 16/09/2025 11:55, Grygorii Strashko wrote:
> Hi Ayan,
Hi Grygorii,
>
> On 12.09.25 20:00, Ayan Kumar Halder wrote:
>> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
>> Test that Xen is able to generate SGIs.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> One of the aim of functional safety is to test hw/sw interface. This 
>> means that
>> Xen is able to configure the hardware correctly for the desired 
>> functionalities.
>>
>> Normally this is tested from the VMs. For eg if a VM is able to 
>> receive irq, this
>> implies that Xen has configured the GICv3 interface 'correctly'. 
>> However this is
>> a high level (or integration) test which uses not only the GICv3 
>> interface
>> between Xen and VM, but the interrupt injection code for Xen to VMs.
>>
>> We want to have some kind of unit tests to check that Xen is able to 
>> receive
>> various interrupts, set priorities, etc. Here, we have written unit 
>> tests for
>> software generated interrupts (SGIs) as example.
>>
>> These tests are expected to be triggered as Xen boots (right after 
>> Xen has
>> initialised the GICv3 interface ie gicv3_init(). The aim of this test 
>> is to
>> check whether Xen can trigger SGIs after gicv3_init() is invoked. If 
>> so, we can
>> claim that gicv3_init() was done properly to be able to trigger SGIs. 
>> Likewise
>> we will have tests to check for priorities, SPIs, etc.
>>
>> A script will parse the logs and claim that Xen is able to trigger SGIs.
>>
>>   xen/arch/arm/Kconfig  |  8 ++++++++
>>   xen/arch/arm/gic-v3.c |  7 +++++++
>>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>>   3 files changed, 36 insertions(+)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 950e4452c1..739f99eaa9 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -73,6 +73,14 @@ config GICV3
>>         Driver for the ARM Generic Interrupt Controller v3.
>>         If unsure, use the default setting.
>>   +config GICV3_SELFTEST
>> +    bool "GICv3 driver self test"
>> +    default n
>> +    depends on GICV3
>> +    ---help---
>> +
>> +      Self tests to validate GICV3 driver.
>> +
>>   config HAS_ITS
>>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if 
>> UNSUPPORTED
>>           depends on GICV3 && !NEW_VGIC && !ARM_32
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 4e6c98bada..eb0c05231c 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>>         gicv3_hyp_init();
>>   +#ifdef CONFIG_GICV3_SELFTEST
>> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
>> +    send_SGI_self(GIC_SGI_DUMP_STATE);
>> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
>> +    send_SGI_self(GIC_SGI_MAX);
>> +#endif
>> +
>
> I'd like to ask, if possible, to minimize mixing selftest and 
> functional code.
> Like add gic-v3-selftest.c.

I can try that. However, the self test needs to be invoked from 
functional code.

Also, your suggestion gave me an idea. I can do :-

+static bool __initdata opt_gicv3_selftest = false;
+
+#ifdef CONFIG_GICV3_SELFTEST
+opt_gicv3_selftest = true;
+#endif

>
>>   out:
>>       spin_unlock(&gicv3.lock);
>>   diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index d922ea67aa..5cb58cdb92 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, 
>> enum gic_sgi sgi)
>>        */
>>       smp_rmb();
>>   +#ifdef CONFIG_GICV3_SELFTEST
>
> if (gic_selftest_run)
And then instead of ifdef, I can enclose the below under "if 
(gicv3_selftest)" .
>
>> +    switch (sgi)
>> +    {
>> +    case GIC_SGI_EVENT_CHECK:
>> +        printk("GIC_SGI_EVENT_CHECK received\n");
>> +        break;
>> +    case GIC_SGI_DUMP_STATE:
>> +        printk("GIC_SGI_DUMP_STATE received\n");
>> +        break;
>> +    case GIC_SGI_CALL_FUNCTION:
>> +        printk("GIC_SGI_CALL_FUNCTION received\n");
>> +        break;
>> +    case GIC_SGI_MAX:
>> +        printk("GIC_SGI_MAX received\n");
>
>        gic_selftest_done = true;
>
>> +        break;
>> +    default:
>> +        panic("Unknown SGI triggered\n");
>> +        break;
>> +    }
>
> Potentially GIC selftest code can be guarded by some 
> "gic_selftest_run/done" vars
> if xen boot is expected to proceed further after testing.

Ah no, Xen will terminate after running the self test.

- Ayan



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 17:10:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 17:10:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127883.1468422 (Exim 4.92)
	(envelope-from )
	id 1v0k3a-0008JR-TZ; Mon, 22 Sep 2025 17:10:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127883.1468422; Mon, 22 Sep 2025 17:10: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 1v0k3a-0008JK-R0; Mon, 22 Sep 2025 17:10:30 +0000
Received: by outflank-mailman (input) for mailman id 1127883;
 Mon, 22 Sep 2025 17:10: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 1v0k3Z-0008JE-Jn
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 17:10:29 +0000
Received: from CY7PR03CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c112::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 08138323-97d7-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 19:10:26 +0200 (CEST)
Received: from BY1P220CA0024.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::9)
 by DS0PR12MB9422.namprd12.prod.outlook.com (2603:10b6:8:1bb::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Mon, 22 Sep
 2025 17:10:15 +0000
Received: from SJ1PEPF00002324.namprd03.prod.outlook.com
 (2603:10b6:a03:5c3:cafe::8e) by BY1P220CA0024.outlook.office365.com
 (2603:10b6:a03:5c3::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 17:10:15 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Mon, 22 Sep 2025 17:10:14 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Mon, 22 Sep
 2025 10:10:14 -0700
Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 22 Sep
 2025 12:10:14 -0500
Received: from [10.71.195.192] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 22 Sep 2025 10:10:12 -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: 08138323-97d7-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VDHbd5M45M+3wbeVWasAnqVyr2Dr6rBmjwxo6wzghHJoCuZ1YbYNYn5brqP6SY4P10lFo54ukRN7IL6NVinxXKEE7uHB/tV8PamglvEhC1fM2O0E8d9TQ6rFRFfRBs0joVewM4rXGb6d5iSoYV/BzHN7JPBjV+hwaLMGGC9Q8H0qiASPnpAXaupi2pTV4W/zOcQiV3Ebf7sNxdmLzkS6P+LX5zK1379bH8YpqpPPC2ZDc5e1JL9zurvn2+by86jkVE+YO0y8mPD/iMMW4EPaXd8DG9bKO2JC1uugwJ88JvOOC/YeYEPfjANN3PDVyhirOI4aOGh1EtGSDBOi0YlaUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xecNqUaleM09+SwcGfMxl8bE1CdWDyZ2cVliD9ttxvg=;
 b=VJuVqyCmjpEdgZWyIEPpQkBzPUBMOGhjD8nnqalNJfy3lCvUUk53458stGbC+ygQ7hISjTqzPm2xm6SA5EcOdWCn/kAQF1fNxx0oY2j3KdEosUT26Up4DKxTR0uYNWfxyX/iHMgtc+/O1aVmFjrI+Jp6m06BDEeu6EkS99ZX6DUfOukYVJxzQb1bj9aTV7xFzRD2Wk/djehi3Ic6smSMJjx67jrvN3bMs8zBFtEGw1qKWHPO4/cao96hlYyeLCz6sNZw3x3gg1xm8FnFCCjRMoL1P69yo7bYW6lm4bkpp3k7h246nv0iP0diCnMg6WLwDNCxzvvU8gIXAvFhqV9npw==
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=xecNqUaleM09+SwcGfMxl8bE1CdWDyZ2cVliD9ttxvg=;
 b=Xuc2YBfrdTWAmmgnFjjdfGrixAyuR0gC6iHdKX9uJ3cOY5bm/zMvT7TGlBs2FAx7QtnuxmD/jvUc8veRoUmHtAlFSqtRZE6DM/23QR3NFtbzpzKcS5rFO1/2hbmEG1Hrrw/yVeClXH6A+Ncppc9X/K6IBf1Ss0ortCIZj7AoehI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: 
Date: Mon, 22 Sep 2025 18:10:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of
 device tree
Content-Language: en-GB
To: Ayan Kumar Halder ,
	
CC: , ,
	, ,
	, ,
	
References: <20250901123103.11418-1-ayan.kumar.halder@amd.com>
From: Ayan Kumar Halder 
In-Reply-To: <20250901123103.11418-1-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: ayankuma@amd.com does not designate
 permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002324:EE_|DS0PR12MB9422:EE_
X-MS-Office365-Filtering-Correlation-Id: 43adbf1a-22e9-4679-9822-08ddf9fae5aa
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?S2s0V2JjYUt6L3lUSUIydURkY2xGRTYwR09YMTAySnlIbTJDa2lma2lLNk5R?=
 =?utf-8?B?T0ZScWZrLzJVUWtmWmcybi93cXRXeDgxd0xGUjBwL3hxK3Nhc040V2xWTzBC?=
 =?utf-8?B?YklIcElEQVhtZDlwUWFlY0pTMGFrQWY5OEo0anNnNUdOZDdDQk9JVERtU2FY?=
 =?utf-8?B?Vmhtd2NvYUR6bkFDWkljbEpFUE5URnMvM2theHVObWxsT1VxZkc3akNVcEhy?=
 =?utf-8?B?bUM2YXIwVERJQVhmazNFSnRhUlF5TElWR09RM09FQUVuTHl4bS8zbjdsNHlS?=
 =?utf-8?B?emNBR2NxVXczTmoyK2JwN1BuVjhxeloxVVBiYllBMGtJVGxVc3VCa3BTU0Vi?=
 =?utf-8?B?SGlLOE4zUWJHd1NLUXBTcEhUWXZUM2pzeUViYTFsQTlUdENvMHVQbXoxYzhM?=
 =?utf-8?B?Rm91YWhaS1lqNkRRTXhJbG5ETGllYzhkYWR6YlRraktQcGh0d2VXcGdrZjRm?=
 =?utf-8?B?TUlXcW9CU2Q2eEVjVFMveDhoN2Nmb3I2OFJaMXpmYVlJUHBucHhoa1NjVHoz?=
 =?utf-8?B?NjJlM2VVQmRTM2tBc3QyY2F4L0lUK0JYVGNtQUJxMGhkb05OVyt1RzhnNUdN?=
 =?utf-8?B?SURKMVA1NWNtNG04c0dxd3gxSGRKaEVycVFJNWRLTnk0NmNNTE11cGhGR0FR?=
 =?utf-8?B?YVl1OHBtSE13L3VaZEtiZjliTkFIZjMrdEpVTWxvUm9ibWE4dVo3UWQ3YzZQ?=
 =?utf-8?B?ZE9GSGZMaG1ON251bEIxWG4rVEwxUHZMMjhLZGFSaGdkeFdTM29rZmhkbkNn?=
 =?utf-8?B?a0FhekhPQ2lwQk12Qm4wK0dGdEM1Q0FvcDV5OGE4cVgzaWhvWGNjTjA3RkZn?=
 =?utf-8?B?THpvcjJTZDg4bnRCUFNmcWhYVlpuUGdqajlpWFNJL2VmZ0l6SE8wbWd2YzNC?=
 =?utf-8?B?Q25HTk9pYkNpSU00N3dJb1JNOHJ0OVdGcWxZK1ZxbzdULzhnTUNxMmIxZUtL?=
 =?utf-8?B?V2VhWGtLRkxYM2dpbDh5T2RFNkdzbXJmbGhGazBjWUtsR3hZdlRzM0lZb0Ni?=
 =?utf-8?B?ZzJjdElZMGFYdVNkRzlwRjNwbGdGekhoK2UrRXB5cTdmRWxmQ3FtcDF6Q2gz?=
 =?utf-8?B?V0JDdmtoNHJHYStEcG5VMTJJdDFPRzY4SlpGWGU2cUhidkdnSW02emN3OHVQ?=
 =?utf-8?B?Z0UyVzFXM0RFVHZscFcxMVUxd2ZSOFFOcWRoMm9XenEzSmRvTlp6eStncGs1?=
 =?utf-8?B?R3o2MGk2Q2kzTUtWTUs3K0lEc254ZkNQT0tud0ZZVlNOcHZucy9TVExsb0JK?=
 =?utf-8?B?N2h1RVZrRHF4bmZURHlRZm15RzFMUVJ0RS9YL0VLWDRvT0pmVW1LZnJnYTNH?=
 =?utf-8?B?QS94cXZCeW03RW9RU3BKeTFFb2lyK1lJYXB5MDUzb1cxZnphblBXMzVFemxo?=
 =?utf-8?B?WE9GLy84T2ZUa1o0cEgxM2NCSHpCRWRmK2hlSXJHbHV0WDZzcXZZV2ROYmRy?=
 =?utf-8?B?WFJIUVlHdmhrVStuRTlWVFBOQnZ4Ukhmem84WEd2SVd1TFdIb29TSWJZeUlN?=
 =?utf-8?B?eTV0aktieXBZMWZja1pZYTE0cThvOTd6YmZWL0w3M3BoNEQ4Wm9DR1F2b2Jz?=
 =?utf-8?B?Qm02T2hibGNwRkRsamR6YXJKanVnamtOMzZWaGVKR01ObFVBZnlwNFBOS21E?=
 =?utf-8?B?SHJ5bUtoY3cyczdkNWMxdUppak1ZMVNYOUU2OTJNYnEzK1F3WXBxNmRFS242?=
 =?utf-8?B?Y1hvNVlmM2RmbC9IQnhlYVNzYU1VRGFyRHYvdXJCRFIyeFk5QzVCV1daK2pG?=
 =?utf-8?B?UWZZMWpHRExRV1lSZ2Vici9OU0NYcm1laWJRS1hqRDBNcy8ydmNEM1BRbmxK?=
 =?utf-8?B?VE5nRElyMy9lSTFNQms1c3pQZVNaaXlCaGtWRGVucjkvYVlLRHExbmdIM3ha?=
 =?utf-8?B?ek8vT0d6c01HQm1zN3RhcTF0UGsyYWVzUlV3bmM1WU9ad1dvMlhvM01weVhx?=
 =?utf-8?B?RmFYMDhnY0ExVWFnK2FYdE54WlZNVUQvdUpyRkFUZGl1QzBDMlU4SkpacVJh?=
 =?utf-8?B?YXZnbmo3RU01c01aRHpuQnpoOUJvYTFXcnozY0EvcExTbEQ4THVRU0NtaDc1?=
 =?utf-8?Q?JnW1hQ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 22 Sep 2025 17:10:14.5678
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 43adbf1a-22e9-4679-9822-08ddf9fae5aa
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002324.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9422

Hi,

After the FMEA discussion at Xen summit, I want to put a clarification.

On 01/09/2025 13:31, Ayan Kumar Halder wrote:
> Xen gives a panic if certain nodes are not present in the device tree. In order
> to prevent this panic, scripts/dt_sanity.py is written so that it checks if the
> node/s are present. If the node/s are not present, the script gives an error.
>
> User is expected to run the script against the device tree before booting Xen
> with dtb.
>
> Signed-off-by: Ayan Kumar Halder 
> ---
>
> Hi,
>   
> In some of the discussions with the safety experts and upstream folks, one issue
> that kept coming up is there are lots of ‘faulty system configuration’ and
> ‘impossible conditions’ checks in Xen.  While these conditions can rarely occur,
> Xen would panic if any of such condition does occur.
>   
> For example, during bootup, Xen parses the device tree .
> It checks if the device tree nodes are present for timer, interrupt-controller,
> memory, cpu, etc. If these nodes are not present, Xen panics.
>   
> As part of safety certification, we have 3 aims :-
> 1. We want to reduce the instances where Xen can panic. This is to improve the
> robustness.
>
> 2. We need to define a safe state when a fault is triggered in Xen. As faults
> (like the one mentioned here) are triggered during boot time and it is due to
> incorrect system configuration in device tree, it is hard to define a safe state.
>
> 3. Avoid validating all the instances of system configuration errors. By having
> an external tool, we push the responsibility to the system integrator. The system
> integrator needs to run the tool to validate all the properties that Xen checks
> for. This can be a justification for the coverage gap for those checks in Xen.

This isn't true as we will have tests to validate all possible system 
configuration errors. However, I want to use this script as a 
'prevention' mechanism to check for the sanity of device tree (which can 
be offloaded to the system integrator). There could be many of such 
errors arising from misconfiguration in device tree. Wherever possible, 
we will use a script or we can explain how to identify these errors 
before Xen boots.

We want to convey that certain failures in Xen are not possible (or 
there is atleast some mitigation) if the user has read the FMEA or 
safety manual or public documents.

- Ayan



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 17:22:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 17:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127896.1468433 (Exim 4.92)
	(envelope-from )
	id 1v0kEr-0001ZN-T7; Mon, 22 Sep 2025 17:22:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127896.1468433; Mon, 22 Sep 2025 17:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0kEr-0001ZG-QT; Mon, 22 Sep 2025 17:22:09 +0000
Received: by outflank-mailman (input) for mailman id 1127896;
 Mon, 22 Sep 2025 17:22:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v0kEq-0001ZA-Lg
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 17:22:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v0kEq-004kYP-0n;
 Mon, 22 Sep 2025 17:22:08 +0000
Received: from [2a02:8012:3a1:0:b59c:e142:82de:6ab8]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v0kEq-007Oh2-19;
 Mon, 22 Sep 2025 17:22: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=hRx4qSd5ff7i6y/kWg8c6/2M87Ca1BspaZ//MUGPlhw=; b=P0nU+YkpvVu1KKVNyoK1uWT9eR
	0kdDuHCgrSqvKIg3/Wuu8jSMXWKwlLjLOplRqdfrfXN0WhKSBoc337cmEpneubXLJTa+kAH8VUhXv
	6KeDPnPp4woR9AQWLX22DE/wGWVfwsu+sJ+obSiEbWpEWoNQuc/bxMS6CZSdfUTLn4TE=;
Message-ID: <7afc0bde-062d-4606-8a99-b57abf953710@xen.org>
Date: Mon, 22 Sep 2025 18:22:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
Content-Language: en-GB
To: Ayan Kumar Halder ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Michal Orzel ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
 <7bbd581f-bfa4-444e-9c76-bcb833a2ec74@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Ayan,

On 22/09/2025 17:40, Ayan Kumar Halder wrote:
> 
> On 15/09/2025 12:14, Julien Grall wrote:
>> Hi Ayan,
> Hi Julien,
>>
>> On 12/09/2025 18:00, Ayan Kumar Halder wrote:
>>> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
>>> Test that Xen is able to generate SGIs.
>>>
>>> Signed-off-by: Ayan Kumar Halder 
>>> ---
>>> One of the aim of functional safety is to test hw/sw interface. This 
>>> means that
>>> Xen is able to configure the hardware correctly for the desired 
>>> functionalities.
>>>
>>> Normally this is tested from the VMs. For eg if a VM is able to 
>>> receive irq, this
>>> implies that Xen has configured the GICv3 interface 'correctly'. 
>>> However this is
>>> a high level (or integration) test which uses not only the GICv3 
>>> interface
>>> between Xen and VM, but the interrupt injection code for Xen to VMs.
>>>
>>> We want to have some kind of unit tests to check that Xen is able to 
>>> receive
>>> various interrupts, set priorities, etc. Here, we have written unit 
>>> tests for
>>> software generated interrupts (SGIs) as example.
>>>
>>> These tests are expected to be triggered as Xen boots (right after 
>>> Xen has
>>> initialised the GICv3 interface ie gicv3_init(). The aim of this test 
>>> is to
>>> check whether Xen can trigger SGIs after gicv3_init() is invoked. If 
>>> so, we can
>>> claim that gicv3_init() was done properly to be able to trigger SGIs. 
>>
>> To clarify, this only guarantees that the boot CPU can send SGIs to self. 
> Yes, this is the idea.
>> Secondary CPUs are brought up later and will need their own setup to 
>> enable SGIs.
> Yes, we will have separate tests for them.
>>
>>> Likewise
>>> we will have tests to check for priorities, SPIs, etc.
>>>
>>> A script will parse the logs and claim that Xen is able to trigger SGIs.
>>>
>>>   xen/arch/arm/Kconfig  |  8 ++++++++
>>>   xen/arch/arm/gic-v3.c |  7 +++++++
>>>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>>>   3 files changed, 36 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index 950e4452c1..739f99eaa9 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -73,6 +73,14 @@ config GICV3
>>>         Driver for the ARM Generic Interrupt Controller v3.
>>>         If unsure, use the default setting.
>>>   +config GICV3_SELFTEST
>>> +    bool "GICv3 driver self test"
>>> +    default n
>>> +    depends on GICV3
>>> +    ---help---
>>> +
>>> +      Self tests to validate GICV3 driver.
>>> +
>>>   config HAS_ITS
>>>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if 
>>> UNSUPPORTED
>>>           depends on GICV3 && !NEW_VGIC && !ARM_32
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>> index 4e6c98bada..eb0c05231c 100644
>>> --- a/xen/arch/arm/gic-v3.c
>>> +++ b/xen/arch/arm/gic-v3.c
>>> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>>>         gicv3_hyp_init();
>>>   +#ifdef CONFIG_GICV3_SELFTEST
>>> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
>>> +    send_SGI_self(GIC_SGI_DUMP_STATE);
>>> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
>>> +    send_SGI_self(GIC_SGI_MAX);
>>> +#endif
>>
>> Looking a the code below, it seems like Xen will not be functional 
>> after running the selftests? Is this intended? If so, we need to stop 
>> Xen as soon as possible.
> 
> Tbh, I didnot realize this with the current test. However you are 
> correct that for some of these tests, Xen will not be usable. We can put 
> a while(1) after it completes the tests.
> 
> Or, I can invoke machine_halt() .

I think it would be better to use machine_halt(). This would tell QEMU 
to stop and hopefully we don't wait until it timeouts.

> 
> The important bit here is CONFIG_GICV3_SELFTEST cannot be enabled for 
> normal usage of Xen. IOW, user should not expect Xen to run domains when 
> this configuration is enabled.
> 
> They are used to run baremetal tests.
> 
>>
>> Also, looking at start_xen(), we call local_irq_enable() a little 
>> after gicv3_init() is called. So I am a little bit surprised this is 
>> working?
> 
> This is working i.e. we are getting interrupts. However, I can put the 
> test after local_irq_enable() as Xen is expected to terminate after 
> running the tests.

I don't understand how this is working. Can you check whether the 
interrupts are unmasked? If yes, it would be good to know who unmasked 
them because it is not meant to be safe to enable them until the call of 
local_irq_enable() in start_xen().

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 17:35:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 17:35:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127909.1468443 (Exim 4.92)
	(envelope-from )
	id 1v0kRx-0003KS-1X; Mon, 22 Sep 2025 17:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127909.1468443; Mon, 22 Sep 2025 17: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 1v0kRw-0003KL-Tv; Mon, 22 Sep 2025 17:35:40 +0000
Received: by outflank-mailman (input) for mailman id 1127909;
 Mon, 22 Sep 2025 17: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 1v0kRv-0003KF-Po
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 17:35: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 8cd88cbc-97da-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 19:35:37 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3f0ae439b56so2306818f8f.3
 for ; Mon, 22 Sep 2025 10:35:37 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3306064edb8sm13923125a91.7.2025.09.22.10.35.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 10:35: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: 8cd88cbc-97da-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758562536; x=1759167336; 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=orYSQfBASql4iF0wCOgQN3xflN64DbRXmnfV23xwClI=;
        b=EA4lbsC5oxJEKWa7jiHtZ922Xm74AoLtMz3nxxr/njHOiPqK4jxDZjOA8D64DNbdFO
         5LS5sbdIM92WI67aNTZXsTrlzDbMiRIaRvw66qqulvXha9KAMY91rZZRmgpgPZqqWSYc
         ZyBx/3KM1Yg3aBOBvx9SVxK0C+KDJIFuVXclXPP6u4C/xzjMB4qY2BT0iqaeNOBXGRMv
         oGgDv/5Qs1xRJ/XCR3rcpBFOHzI0lDce8jua5JszxIp4z2HcSJQtrwYzFsGhbVn8u1Lf
         aH6uB4xQGHTnE6cJAXszgmt1dMAxGbnJRLlXaTApcgyL9+YnvG20d2aL1n1ckjxsFCYH
         cqHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758562536; x=1759167336;
        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=orYSQfBASql4iF0wCOgQN3xflN64DbRXmnfV23xwClI=;
        b=V2vsdIQkDnSHveGomlsQuBV+sHxTmDelUfSXBa67Vfj/p2+THPIYBIleQzstBp7WYX
         1zW4pwQyV67tNo6qhOHc9UW6vzIq4XUdT4DecLZ/u5g8kWCrFgGsPMeh9Tro/FIPkVGS
         7f9WriiEo4Usd1GND8Xjf6EQyHgNqkmtjKN+IoHPBWLbLx61fuPbteASfFYqTINnON88
         wUhXLz6oOdToqt7RB2Z8lNX9WY8qd+M5i7X/o7xCi3U8/jTGWxIwCTptuZfZbxEqWN1Z
         /huQLr4/oLP9HyRW+l1qFbn8OOhFfJCSE56NOAVKBhMkj2xjxKc6qzT3B78qXbj5TJyX
         e/ug==
X-Forwarded-Encrypted: i=1; AJvYcCVARfVNjD6edoEK771xKiUX22sOpYSlAYJG+R8/i6btJ3DjD7bXan/OwsaDE6O4yRqcpeNfj9RCb/M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbQ8zpwjl/RTtvEjz6zGIBko08IfpFTbXIh9oCnr4I886peYEb
	HFTohB2LvzcH3KHBbJWLM4OoA12hIlyMAXNpkKrO4sJgn9r+/JVFCpyCJBFu8Jq/Ww==
X-Gm-Gg: ASbGncsNuO8FyihC5a6Nj0WvrrrRt+aDBoKBE3kYayWA/uBqN6FRm3bm/kzQ0hG8zMI
	02ZIlvxshWljHwIBDx1VbIlHnYItK8RiI/Aw34gIlmZRY8EaB7oAW115AA0h+M+Vi8HgTmHyKpU
	OR0o+WDb2Xu4mf8TowmuAYPRRvsMQL7sVkJ8pLc2dRfkN/Li/EkLMwFKkDqziDCoOy3TuAW6IPQ
	HjMItDeFjqZHaJeNgVw+EZV9vlhcdCxM1DUcSgbeLmuz5exDQVrqs0Iqlooe9I0fHeSzDZSEWSh
	ticiE8uu0sED9O5nSMJIztohA3XjNKuVpBHVDR3a8eDVkhOEdFuYS9GCjdnC7JbLs5r2sO1+nI/
	LjEpNtQqzEsQf6hgYx/jxoP37COXo/8DZ
X-Google-Smtp-Source: AGHT+IFZsuSpeBMsF8HsNI5Y3qjYF6Bf4uBmhPbNXJdp0EqPsQEkJlNBfoQAh4aYgh/R9qec5tVTNQ==
X-Received: by 2002:a05:6000:4210:b0:3da:e7d7:f1e0 with SMTP id ffacd0b85a97d-3ee7e6c0f4dmr12477861f8f.27.1758562536504;
        Mon, 22 Sep 2025 10:35:36 -0700 (PDT)
Message-ID: <0cf7a47f-f852-479a-bfb2-2f723f66c72e@suse.com>
Date: Mon, 22 Sep 2025 19:35:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 13/18] xen/riscv: implement p2m_next_level()
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: 
 <30a203de44b04a06613aa1f873a072a4594c5bb4.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <30a203de44b04a06613aa1f873a072a4594c5bb4.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> 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:
> - 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 V4:
>  - make `page` argument of page_to_p2m_table pointer-to-const.
>  - Move p2m_next_level()'s local variable `ret` to the more narrow space where
>    it is really used.
>  - Drop stale ASSERT() in p2m_next_level().
>  - Stray blank after * in declaration of paging_alloc_page().

When you deal with comments like this, can you please make sure you
apply them to at least a patch as a whole, if not the entire series?
I notice ...

> --- a/xen/arch/riscv/include/asm/paging.h
> +++ b/xen/arch/riscv/include/asm/paging.h
> @@ -15,4 +15,6 @@ int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages);
>  
>  void paging_free_page(struct domain *d, struct page_info *pg);
>  
> +struct page_info * paging_alloc_page(struct domain *d);

... there's still a stray blank here. With this dropped:
Acked-by: Jan Beulich 
I have one other question, though:

> +/*
> + * Allocate a new page table page with an extra metadata 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;
> +
> +    ASSERT(!pte_is_valid(*entry));

Isn't this going to get in the way of splitting superpages? The caller
will need to initialize *entry just for this assertion to not trigger.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 17:42:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 17:42:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127922.1468453 (Exim 4.92)
	(envelope-from )
	id 1v0kYv-00050G-Md; Mon, 22 Sep 2025 17:42:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127922.1468453; Mon, 22 Sep 2025 17:42: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 1v0kYv-000509-JX; Mon, 22 Sep 2025 17:42:53 +0000
Received: by outflank-mailman (input) for mailman id 1127922;
 Mon, 22 Sep 2025 17:42:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v0kYu-000503-Kt
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 17:42:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v0kYu-004kvM-0f;
 Mon, 22 Sep 2025 17:42:52 +0000
Received: from [2a02:8012:3a1:0:b59c:e142:82de:6ab8]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v0kYu-007QtQ-0e;
 Mon, 22 Sep 2025 17:42: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=wpILqGiJ7kMrDstks7MVXnKplG1k0Pb6L1+RBO3f3gE=; b=xav9WgkuQj+E3fbVju5HJ/ct8V
	dhbaNVYszUe/S2OvIOED5Jj9KyJ6jRAfeUDQvR7D0b8LW69rvxVvHh5NGIyahPeD5S3ydd1WHKr+s
	tGy6EJByRtksLcTyRmvZwfadrmW26L3Flx5DAMw9naQ0XlzD+TkNRa2lsni/nwqld0N8=;
Message-ID: <6476dc12-1f9f-4b37-b569-e994bde6bcdb@xen.org>
Date: Mon, 22 Sep 2025 18:42:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Content-Language: en-GB
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksii Kurochko 
References: <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
From: Julien Grall 
In-Reply-To: <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

(+ Release manager)

Hi,

On 14/09/2025 14:26, Oleksii Moisieiev wrote:
> Move the SCI (System Control and Management Interface) resource cleanup
> earlier in the domain_relinquish_resources() sequence to ensure proper
> cleanup ordering during domain destruction.
> 
> The SCI cleanup is now performed before TEE (Trusted Execution Environment)
> cleanup rather than after P2M mapping cleanup. This reordering ensures that
> SCI resources are properly released before other subsystems that might
> depend on them are torn down.
> 
> This change addresses potential resource cleanup dependencies where SCI
> resources need to be released before P2M mappings are cleaned up, preventing
> potential issues during domain destruction on ARM platforms with SCI support.
> 
> Fixes: e2cc10867b (xen/arm: add generic SCI subsystem, 2025-09-04)

I am not sure where you found this syntax. This is not the one we use 
for Xen. It should be:

Fixes:  ("")

Where the commit-id is 12 characters. For this patch it should be:

Fixes: e2cc10867b63 ("xen/arm: add generic SCI subsystem")

> 
> Signed-off-by: Oleksii Moisieiev 
 > --->
> Changes in v2:
> - rearrange enum by placing PROG_sci before PROG_tee
> - add "Fixes:" tag
> 
>   xen/arch/arm/domain.c | 11 ++++++-----
>   1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 1a8585d02b..e36719bce4 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -1042,6 +1042,7 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
>    */
>   enum {
>       PROG_pci = 1,
> +    PROG_sci,

Can you confirm this is fine to release the SCI resources *after* we 
releases the devices? Does this mean they are not linked somehow? For 
instance, if a device is re-assigned to another VM, could it fail 
because the associated (?) SCI resources were not yet released?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 17:55:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 17:55:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127939.1468463 (Exim 4.92)
	(envelope-from )
	id 1v0klF-0006qn-UX; Mon, 22 Sep 2025 17:55:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127939.1468463; Mon, 22 Sep 2025 17:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0klF-0006qg-Qg; Mon, 22 Sep 2025 17:55:37 +0000
Received: by outflank-mailman (input) for mailman id 1127939;
 Mon, 22 Sep 2025 17:55: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 1v0klE-0006qa-QM
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 17:55:36 +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 5673e72f-97dd-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 19:55:34 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3ee155e0c08so2912405f8f.2
 for ; Mon, 22 Sep 2025 10:55:34 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269802de5dbsm138326475ad.84.2025.09.22.10.55.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 10:55: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: 5673e72f-97dd-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758563734; x=1759168534; 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=2ZAIQmc5oqVUFqm1NDIob8VMMpZ4dgzoP/QlXFClA9M=;
        b=dmYHqbvBq7ADXpHz9lw/QFJp1t8ddBmmQC9t9bteziBn/mlfJcQGpueZ3rUqJPkErp
         u4c3nIR1/pmOUfIQQ2Ci5J2Uf8u7xitfXO2eEX91MmY+klhVlaYmn3dChABVA2BpHsyN
         mHnjLcsBD296EmoLft/3Kt8XYa+s9K70XZSWsBOPGrqnUB7PZYJshucKMtE5gVMKJgGZ
         Q+XAihYaZboNeL7JT5nm509KER5yHvddHlzM3/D1OOyAs8PBvgagx9rl9aTgAvFiwGfr
         9k2UiVEsFxO5QW1VcwQRxWyaXHws5Zzcq3wurs3M44IQbMAoNk4R0zxIC6MgbJllfpN3
         teIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758563734; x=1759168534;
        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=2ZAIQmc5oqVUFqm1NDIob8VMMpZ4dgzoP/QlXFClA9M=;
        b=dwvQPh2KWFl+gu0V7AxauFath6zAvWhKKqVLRTT1wwK/UwE0IXWq3H1W5T/vTfo1Ro
         BlE6yNtWyl0UfsFE6wd0HfvdgAyDqAtYYyzHdcSSjHH/XZQ51uBYbQ/BkbCCRzrPDK2y
         TjA5ud4K8sPrBjz11806oElimuha+jI9K2aXkw4KFFS6C+5+Ab0+ndk/CyVSsVTcktC+
         oCspGP7AKWGDcjBYTBc1FRiD4DzYAfUvL5p969lvBcxI/oH1KYAOYdEEhTVQiOkAsTI7
         LvOyLQOtdDaExWSsKDtgHk0FdgRvK51l8WZqpeouHyMj4Kd9eNGRCBIIJoQkd0OOH8yG
         71Ig==
X-Forwarded-Encrypted: i=1; AJvYcCWP3BZYYRX19FfHvarOc8A6JQkyNUaJWl2Mm2SrmT2sBTEskJ3t7s+1zTtsuok6+DhSAlfuQTxwbFw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxz1PLLok9c9bZGrUtVxd0Dx4MEGti8RjLI7Qj4uOvCDRrmUENS
	ULodISbesbdy0ugAOWGaG3ldlKAQ/Dp32RiHDgTXklG0fjSbCThE50pmoemJYr+94Q==
X-Gm-Gg: ASbGncsDn1CjFWkWMv8xvdZRLAnGt1xm//TILYwzS5ASviFH0JS9tgHHXB3AG0c3FMB
	xPDYVp52qKbk+3QFZ2FHBjs9KfhKZAk0kKst1SNPt95tSXPcHwl13EHG2Zr2BClY2Dk4NZR9EPB
	Rolal55/Ual2wV11/2wnTvm/jFMtNRzicZuZ9kUHCYWYs/tkjmq1ljukZPUL+Z8f4ps/Nxa+vus
	pqc7Lkz3QFGN5EZbc/tuKkFFS+LvxSYEZMuAvIYVHMJcM6tFgz4cIcm8w4xSQjVCfSvnGcNhrpu
	QnBIgWxTyC29mlA3dJquTueZThvcWTfJ1oShnPcte14JAcIeaYKpkR5ab/rzOSZnZYd0AndfDER
	zDsNI5J2NLBc+qWCdddYKL9ef4fdS9PAL
X-Google-Smtp-Source: AGHT+IHf6jg+Taji7WJschoIPIWprSLu/ZucdQNGs2FSg+3fTeAl+MRd4QO/wDwz2h/hpyG8q8ZhzQ==
X-Received: by 2002:a05:6000:2203:b0:3ee:1296:d9e8 with SMTP id ffacd0b85a97d-3ee7e1066dbmr10681064f8f.17.1758563733790;
        Mon, 22 Sep 2025 10:55:33 -0700 (PDT)
Message-ID: <0a5561bd-6aa6-4393-a58e-a0810ad19735@suse.com>
Date: Mon, 22 Sep 2025 19:55:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 14/18] xen/riscv: Implement superpage splitting for p2m
 mappings
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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> 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, some parts are simplified
> as according to RISC-V spec:
>   It is permitted for multiple address-translation cache entries to co-exist
>   for the same address. This represents the fact that in a conventional
>   TLB hierarchy, it is possible for multiple entries to match a single
>   address if, for example, a page is upgraded to a superpage without first
>   clearing the original non-leaf PTE’s valid bit and executing an SFENCE.VMA
>   with rs1=x0, or if multiple TLBs exist in parallel at a given level of the
>   hierarchy. In this case, just as if an SFENCE.VMA is not executed between
>   a write to the memory-management tables and subsequent implicit read of the
>   same address: it is unpredictable whether the old non-leaf PTE or the new
>   leaf PTE is used, but the behavior is otherwise well defined.
> In contrast to the Arm architecture, where BBM is mandatory and failing to
> use it in some cases can lead to CPU instability, RISC-V guarantees
> stability, and the behavior remains safe — though unpredictable in terms of
> which translation will be used.
> 
> Additionally, the page table walk logic has been adjusted, as ARM uses the
> opposite level numbering compared to RISC-V.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 18:36:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 18:36:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127957.1468472 (Exim 4.92)
	(envelope-from )
	id 1v0lOK-0003fc-Px; Mon, 22 Sep 2025 18:36:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127957.1468472; Mon, 22 Sep 2025 18:36: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 1v0lOK-0003fV-NN; Mon, 22 Sep 2025 18:36:00 +0000
Received: by outflank-mailman (input) for mailman id 1127957;
 Mon, 22 Sep 2025 18:35: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 1v0lOI-0003fN-Hs
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 18:35:58 +0000
Received: from CH1PR05CU001.outbound.protection.outlook.com
 (mail-northcentralusazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c105::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f7d9f1b7-97e2-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 20:35:53 +0200 (CEST)
Received: from SJ0PR03CA0332.namprd03.prod.outlook.com (2603:10b6:a03:39c::7)
 by PH0PR12MB8005.namprd12.prod.outlook.com (2603:10b6:510:26c::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.14; Mon, 22 Sep
 2025 18:35:45 +0000
Received: from SJ5PEPF000001D0.namprd05.prod.outlook.com
 (2603:10b6:a03:39c:cafe::f2) by SJ0PR03CA0332.outlook.office365.com
 (2603:10b6:a03:39c::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 22 Sep 2025 18:35:45 +0000
Received: from satlexmb08.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_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Mon, 22 Sep 2025 18:35:44 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 22 Sep
 2025 11:35:44 -0700
Received: from ubuntu.mshome.net (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 22 Sep 2025 11:35:43 -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: f7d9f1b7-97e2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZFrB9QlXFqY4ERlbWhkbPuT/+hHEjdw9VWKlVtz33rk80GYQtqrN6/1mX4NsqM76yKyXcyeKd2HyD7gpEY0JqL+P6qyUblRTNG5j7/bcCJXzW5XOY+5HqX6xiPaihwB3bgMB8dMaQDbEiH/Wvxs1C53IA4LhSuEoAt0aU6uhx6jiPBHshRu5gchyIFIucEikYcQMhZQRe8PUkcvE1nvqJeYiTDKe8aowX9eu9H97O2Ek6+jmgsS7F22En7jMFn1U15JwpIiJgq7th08GOd41MLT7B5GhusMLAwdzbLIpOOg3XMn5CLwHsgPxpW7lXA6/02GloVQqFctfitWdQdffnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ooOvjJ9DHe6Z8LVn14Sd59ANehwdCzGl1qi4gBik598=;
 b=Q9BNG6d0zOAiOy5Unuh10w+JBvggjNDWZrBU37ktTxmD0ilT1VKFoRgcsQyyl/aH37VkwC5gICrWGcA1SRh4xIasp61mp38X+FdPLJlIw4Q/hKnqdqkH1ctx25UNjVCuJx71LOrHovjgzDDIOJamGbTKsSEeyZSAvzOBxLJljYL3qS/uoptgx3cKtkQKGUh7a+PA7V/D7ERRvHGTHfUvY84iQJQ3YsLw8yghoC2UNxBaznLGmgAKjtZwb2b6QFzN2xnLQpdacjrLZEVOy9fM4sKpPhFSFN0gvzBjnM5VMCNjf8M/mdS7ISyaUewshKEuQ6JdUksKPz0sgJbzc/9hFg==
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=ooOvjJ9DHe6Z8LVn14Sd59ANehwdCzGl1qi4gBik598=;
 b=ko0kg3iJPq3YBYKmpCPjWMbEpDWnKiQ+pWTfK/9ZnXsXSrpgazUdztNs0USiQxTVMGOCRVEJLsSXZwT6ZP/fNiFwWwoIacpiR3+yn91uF80YHjXPVzRjxC1vFJFo+FCBCTJJrn9SHW8xCZf+5P4iNTDk3nMXlf6nbHOHZgxiJ0I=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH] MAINTAINERS: add myself as vPCI reviewer
Date: Mon, 22 Sep 2025 14:35:35 -0400
Message-ID: <20250922183537.8861-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D0:EE_|PH0PR12MB8005:EE_
X-MS-Office365-Filtering-Correlation-Id: a07e7674-21cd-4500-28a1-08ddfa06d78c
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?Qi9LWVNNTEp6SFdIUjJhNHlieTNrczE2VUxwelZFMGVqaDRxa2VyQ1Z4Y1dt?=
 =?utf-8?B?aDl5SHRqTmFsWTZkd1orOTUzSjZuZ1RZTzhYblB3QXpqdnpaUVAyanpQKzla?=
 =?utf-8?B?UUVCbjJEZzBucHdjZW9WUis2eGdVcS9sR1JnNE1Qem12NXE1UmVISSs4YXp2?=
 =?utf-8?B?VlpwMXpyeE9Ua2E4VmpLZEFyWnRZS1JlQzU2ZUFmT21ibUVtUEZNeUZ5MmNI?=
 =?utf-8?B?RTdsMHhmOEVuK0tYUWlzQW41VUNaZ2lSSExIOVR0eUMrbE8wa0NZTFY3YTBs?=
 =?utf-8?B?WGhwRTFjNkJvWFUyZnVvNjl3VkZWMFJBM1YrMHdSVlRWalBpSjdSc2xhVVNC?=
 =?utf-8?B?cjVVOE81WGxFWnVqYVNDd2U2Sk9hazF2b2VvR2M4V29GNWlvTVNsRUYvSzFl?=
 =?utf-8?B?blZqZjRpdHd5NFppKzFJN2NOeTE5NExNenFiT2h5aVE4UVdTS3J3YW83emw1?=
 =?utf-8?B?RWVKYVFZS2lXRzB6Zm14TkpEL2ZodUpyNnYxbHRFeE80dmV2SHdwbVZQQU40?=
 =?utf-8?B?MGliNDRLa3dHdEJCTEhzdmFVcWh2ampyOU5QcFhndytiQk5CakNseGdYRGZL?=
 =?utf-8?B?SDdXUTNMbmdNNjNVVDMxZ2tXbzc4dExPZnZLQXVObzQvdHFVbXBQTEI4ZlFY?=
 =?utf-8?B?SkVmZ0tWaitiZWZIZmwzSVh2WG55cGliWmRWc1lmN1BoNHd1NXVjSi91VGdT?=
 =?utf-8?B?Y3dzb2ZBb1ZEbzlWK3RNMnM2TlVoalhybnlSY3JDNm4rd1A2aU5sYkUvK3dt?=
 =?utf-8?B?Z1ExbTM0RVpJTGk5TFBya1FtdDZZaFhvdG1hYTdGM0lRQmJsQ3FMSC9zMXlt?=
 =?utf-8?B?TmJiWFZZV0VRaThGU3poS1NvOGxqZHJISnllZEhEaFNRUzNYZWRiM2hqUGU3?=
 =?utf-8?B?Q0hIWmx2M0diUFd4VUY5czBYWS9IR1V1b1Z4OVNFWTdSTmhKWE14c2FUZ1pD?=
 =?utf-8?B?OVpjWE9OVjZiZElRZkRkWlBvbmtWVERYWjhVQ2ZST0c5TkpERXMxczhPdCs5?=
 =?utf-8?B?aDFmbDRuOE5sbHJPNzg2eDJvY3IzOWt1SzBwa2JkY0FDQ1VZTnB0Q29yck9H?=
 =?utf-8?B?NHo2WlpZT0JIeEd2VmJpZTBWdEI2RDZXTVRsZGRZZ3krQUZSTDhRR3BoVVpv?=
 =?utf-8?B?YjRsWkhQVXlYcDMwcW81YlpFOWJQTTFZSkgxeUlTZ1NSdXc4OGp2QVJ0NFp6?=
 =?utf-8?B?Q0cvZWhROFJ3RjcxMnRQaGlQYnVtOXI3SXlieVdsajdxR0RaNXIwNUhpV25B?=
 =?utf-8?B?TFVSMnNFZUowM3UzNHhLV2pkMUVwRkdxVUwrY1JWSStwYkJQN2Z1R2toZzd4?=
 =?utf-8?B?UEZPbmVKRlpQYThWR1l4RjYvY2UyeFc5d3BCQ3E2QWZDb0NHbXl2YjlSb2pV?=
 =?utf-8?B?TEZvajFTSmRYZ1p6eWxYREROeHJrMTU2Tnp6UGJHcEJ5KytJYWR4QnFPd0Ns?=
 =?utf-8?B?Sm9DN0phMS85NExpSUEyekljM1MxS2JjYUJIUkJxOWNqYnU3b2I3VGthWnZj?=
 =?utf-8?B?bFFlYnpFT1RLYXVjVDQxUjJIdTJrYnA5VHlaL1pXaUtaK1k4RXR2Zkl4U1hI?=
 =?utf-8?B?TnNHUmdxY21FYzZzVmQxQnhWaTlFcDRQcEV2UWZ3cmdVZitCVGZpcDRiY3E3?=
 =?utf-8?B?ajRZZS95OU40ZnVBclVpSXFuUkVLQnk5YlphbklTUkxTUnFNM1lRTGxwMFJl?=
 =?utf-8?B?akFSb1U5RDBhYVdBcjk0MndUcllybVJ4UTdIdzF6LzBvcER4WFRNczFwemdw?=
 =?utf-8?B?cnBUcTlFdExrUEhPR21weitzSDAzNVF0QWlPRUNiSExWRTlER3JPYno2N1pO?=
 =?utf-8?B?YUR1N3A1RlI5dEcxUEJmaTIydDZnRmJQSWtHZ2N1YXg0SmpnNUtDSVBtT0NK?=
 =?utf-8?B?S3NrcmtqWEQyYUMwMmRaalhyQk1BNDUvcnFYRFQwaXA3WW1tRklIa016VE04?=
 =?utf-8?B?cnJkMXo3TlVvNDI2a3h1T0dTZVdoaVZtWUR1MHdSWFQrMW5SY0Fza25VVzVu?=
 =?utf-8?B?R0g5aDVWcU0wY05zVTFmeUJULytmcXdJSFQ2RTkyNGw0V0hOK0R3UnB5eUhl?=
 =?utf-8?Q?J80Fq1?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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: 22 Sep 2025 18:35:44.8168
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a07e7674-21cd-4500-28a1-08ddfa06d78c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8005

I'd like to take a more active role in reviewing vPCI bits.

Signed-off-by: Stewart Hildebrand 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 31dbba54bb6f..793561f63f83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -578,6 +578,7 @@ F:	xen/include/*/vm_event.h
 
 VPCI
 M:	Roger Pau Monné 
+R:	Stewart Hildebrand 
 S:	Supported
 F:	tools/tests/vpci/
 F:	xen/drivers/vpci/

base-commit: 656b9ca03bd340715aecf405da63c515afb344a1
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 22 19:27:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 19:27:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127970.1468482 (Exim 4.92)
	(envelope-from )
	id 1v0mBc-0001Gv-CU; Mon, 22 Sep 2025 19:26:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127970.1468482; Mon, 22 Sep 2025 19:26: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 1v0mBc-0001Go-9M; Mon, 22 Sep 2025 19:26:56 +0000
Received: by outflank-mailman (input) for mailman id 1127970;
 Mon, 22 Sep 2025 19:26: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 1v0mBb-0001Gd-46
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 19:26:55 +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 17ac3aa8-97ea-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 21:26: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 A53466013B;
 Mon, 22 Sep 2025 19:26:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29034C4CEF0;
 Mon, 22 Sep 2025 19:26: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: 17ac3aa8-97ea-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758569211;
	bh=yHy+k2O362f4ukNf9FzIDOn87yC3M5HXDUAgv+Iuww4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=V9AU/MQXHsJyBQENsH8WUGeS2qrvCgOwwKyD4exAyaSx4phInJHSSxFP+o950OTuH
	 HoYUKaK2kVxQUTQHpjf/WBZ73xyFyyE2dVVEYAM/Y8tA1mDw7T39pnqkUo+PKoSYDu
	 C9ejCtOhQMZouXL2XIXFR9Z/DrXuC83FBtH6rlvJWgESHtC2Nc5mQFtj3VdagSx7xr
	 QUg4oUKPb/4my9aDCxiBk1pI0siG9/i8TYX37LX0VKXc1kycDQ9u2S9nFxqJq8r+J7
	 W+aManWpR+fDWf05X5LUyvQhzxDr4iV34S/2EDbPlFE7lOnK6J1flbu2OB+TX6jJ53
	 A2RRTK5jMFInQ==
Date: Mon, 22 Sep 2025 12:26:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
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: add myself as vPCI reviewer
In-Reply-To: <20250922183537.8861-1-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250922183537.8861-1-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1574738169-1758569211=:2244509"

  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-1574738169-1758569211=:2244509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 22 Sep 2025, Stewart Hildebrand wrote:
> I'd like to take a more active role in reviewing vPCI bits.
> 
> Signed-off-by: Stewart Hildebrand 

Acked-by: Stefano Stabellini 


> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 31dbba54bb6f..793561f63f83 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -578,6 +578,7 @@ F:	xen/include/*/vm_event.h
>  
>  VPCI
>  M:	Roger Pau Monné 
> +R:	Stewart Hildebrand 
>  S:	Supported
>  F:	tools/tests/vpci/
>  F:	xen/drivers/vpci/
> 
> base-commit: 656b9ca03bd340715aecf405da63c515afb344a1
> -- 
> 2.51.0
> 
--8323329-1574738169-1758569211=:2244509--


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 19:55:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 19:55:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127982.1468492 (Exim 4.92)
	(envelope-from )
	id 1v0mcq-00054u-75; Mon, 22 Sep 2025 19:55:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127982.1468492; Mon, 22 Sep 2025 19: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 1v0mcq-00054n-4L; Mon, 22 Sep 2025 19:55:04 +0000
Received: by outflank-mailman (input) for mailman id 1127982;
 Mon, 22 Sep 2025 19: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 1v0mcp-00054h-8X
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 19:55:03 +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 05ff5217-97ee-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 21:55:00 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3f1aff41e7eso3765003f8f.0
 for ; Mon, 22 Sep 2025 12:55:00 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2698018a9b7sm141783005ad.61.2025.09.22.12.54.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 12: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: 05ff5217-97ee-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758570900; x=1759175700; 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=Kf6fVXTyKM/bSWl10urBHDESq7eI5nKWWBVDyag/ojM=;
        b=eYqTPzgXAAimoK9eH98JukThu8KyC8Lf4GxfA+lwlDTVSvJp7h3gHdyR9H/+4KJgbv
         pGAO7JNk8/YIN4FBTZ+3qrUl8y3G+JRnvX2a6vvzv1fzUKaz0c1VJvG+rDwICX+t8pcy
         t79Ba1BuQAYHrDmCJZF9cbDatdtGb1D4KKBJADXoEfsOgtHmJtpwE5fTJKMe00O5xs+3
         rBfYH3r89cGrovL7YmnruwgaK5/DpQz3+8VYP7yWlQjW0R17ygSGOz7p4egYs9/tU5ns
         YRxaf7LA9a6ZPqUZTei7/TsNVbhcfboygPs2Lui8SQ8fH8T43tuxXk05OacfmkPCiy/v
         3vKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758570900; x=1759175700;
        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=Kf6fVXTyKM/bSWl10urBHDESq7eI5nKWWBVDyag/ojM=;
        b=WSZPtbuiAj55CRnfLg4z+4lUW8BL9RwG/efDIyr8pex2ExrvlTKyH4nauZ7AqWxkJX
         K4t88OcoaZHyYcK6+0q7EUUA1DvZH6Al+dQPEVVqi+gVg4RXg5O+2+aEDeGWJ8UR9NR5
         QPGpt5Cj6gfFaA8JEXGUIuJkDMxxlZaIWzWkJX7v7CINm4Rv2FD7xZnAQ6LptWwo3qhZ
         mROGtqHSK1NHd0uIfv3tncMH/2aCMgb3h8ejsftIy25BbL1RsYsLxlLGYgRRiANdDVAD
         eDsu0ye7mdpPWskj4fUTZjNXzv5MZ0xFd39onQpSHKPFwmquIC4uwx0wgqfFECOPEsAq
         sLdA==
X-Forwarded-Encrypted: i=1; AJvYcCW2xa1y8Wl32DAg3O0OuP70K0jTB+VLk0hPNk38q+yFJS6sfd5hnOd0bHyyHX/Pj+moEUwgiTjARkk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyeU4xFHoJI/Ym+UjMeKzqSh7KbWPAWidJREEIhtx/W9rfhrqXA
	otDC8beTCKLQqSLgcQt2mBK4u0/ZXx8iOgS1sOHooVzbYwy6we1eL3WJQ/GvzWkBHA==
X-Gm-Gg: ASbGncuZ+0XnaYJORUaF+nOJVbZ+LX8lx2I4tx+4GfgzCl13qztlQhs3Bg1uxCiNSnL
	5hUtYRBUV8ElbQb2TSs40ieyS97VL0Y5uZdotLXSGKqd3Kyzv5PDGtXKoqTPT932FBdCHutuX3h
	wtxTxjpbDn6o0rOJQFLmas0l1qq9uEb/C1ypAi5L4MDjVwpO/W15lJZyNNTeseY+qePOiw0kQIp
	uHLnX+XL1eiXvPI7nvtDLCkmPe+YEWo5ULRz6nKFs6t05I+NTiGql2Qy8xhJ1zkk2KwMEJihQbL
	CRycF5gKZvec9uZYLbOcSUsIN1+Z6KH+BDFHaQWZY66/FqPQcZKI+p11oYsUKiOXBdoEhnn/3n7
	5DqQih7qnz6kLD7ocCeoCK+AMYAsq0rtM
X-Google-Smtp-Source: AGHT+IHf9yLkV4eGulB7092KsaIYrAZLwFx0GjyAKX6jZr1m6PnqlpM3W6NITB1mt7+Qv9KR/jAONw==
X-Received: by 2002:a5d:5f48:0:b0:3fa:ff5d:c34a with SMTP id ffacd0b85a97d-3faff5dc8femr6393521f8f.39.1758570900254;
        Mon, 22 Sep 2025 12:55:00 -0700 (PDT)
Message-ID: <085264a3-b42f-47fc-83c9-422854aeef83@suse.com>
Date: Mon, 22 Sep 2025 21:54:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 15/18] xen/riscv: implement put_page()
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: 
 <269250b2b3c62f34446d9e7b9f72dbf2d4eca2e5.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <269250b2b3c62f34446d9e7b9f72dbf2d4eca2e5.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> Implement put_page(), as it will be used by  p2m_put_*-related code.
> 
> Although CONFIG_STATIC_MEMORY has not yet been introduced for RISC-V,
> a stub for PGC_static is added to avoid cluttering the code of
> put_page() with #ifdefs.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 
with ...

> @@ -627,3 +622,23 @@ void flush_page_to_ram(unsigned long mfn, bool sync_icache)
>      if ( sync_icache )
>          invalidate_icache();
>  }
> +
> +void put_page(struct page_info *page)
> +{
> +    unsigned long nx, x, y = page->count_info;
> +
> +    do {
> +        ASSERT((y & PGC_count_mask) >= 1);
> +        x  = y;
> +        nx = x - 1;
> +    }
> +    while ( unlikely((y = cmpxchg(&page->count_info, x, nx)) != x) );

... style corrected here (just like for "do" the figure brace here also doesn't
want to go onto its own line).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 20:03:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 20:03:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1127995.1468503 (Exim 4.92)
	(envelope-from )
	id 1v0mkZ-0006kk-Uf; Mon, 22 Sep 2025 20:03:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1127995.1468503; Mon, 22 Sep 2025 20: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 1v0mkZ-0006kd-Rv; Mon, 22 Sep 2025 20:03:03 +0000
Received: by outflank-mailman (input) for mailman id 1127995;
 Mon, 22 Sep 2025 20:03: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 1v0mkZ-0006kX-5r
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 20:03: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 24309acf-97ef-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 22:03:01 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3f0ae439bc3so1813455f8f.1
 for ; Mon, 22 Sep 2025 13:03:01 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2698035d337sm137799115ad.139.2025.09.22.13.02.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 13: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: 24309acf-97ef-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758571380; x=1759176180; 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=atzPYGCgOqH/2Y8PzDOhEOycEOaBp1bZqsqy2w7npww=;
        b=O7lxIQ+sEQ52wKzoCXogEUBH4G1T3tI70+A+qK1al3IRDeBmNoIBJnu018bIOFGjnm
         n7/XjGQKqUdaVlMcOYqvWB1HpvUQet1y8Zb0XwKQ1LOPK2FVd/hoJza/rXZrA1NzDeiE
         kzmohiU7Za5zdfcSImlH6oQiLmkYf8xktFEAu56KuzL67vaa9GNY/Zj28i4chMInTrQQ
         Rtq+itzntCTSfZ1RexxmtDo0nF64mNz7pKymX6qLst38+jEqzzJWM1WM9cJVmHCgfDRf
         bDgMUbYcpb78vh4UPNE8bzM7QlVq634cAycYOHwfTbGfMjeSEB57qOvNcBE1eODNpIAe
         PXQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758571380; x=1759176180;
        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=atzPYGCgOqH/2Y8PzDOhEOycEOaBp1bZqsqy2w7npww=;
        b=NEQjRU4wa10zvab2R7G7uHNjoNodONLrr01nefDCMEdL0heT2Mpzz63RzqOcTQ7cGR
         imRm+98m6c/4J0IyzfytnF8PMKmQO34HC6Yb56SwYZxZFhJlCLr+cPBqR6U7uguT7v1k
         hQ/w3qubC3qm7/dCsKJkHCbCg3NLw8UPGRSiyCcGAN8vGXTXqnXiXDfy72uEZcL/Kzt1
         8oH9u7nDCHLiinYtFDkbteZFwUF1Fc2+UcLnRLcyz60zBVl8yysMoBe/4Q7QFME4y76Y
         8Oqxn6ca1+ZApVblpS4b+fJxwkRDhYQ7XlheAOtY4tq+vjFpX3sUvKi6GbM+FucHqb3V
         brUA==
X-Forwarded-Encrypted: i=1; AJvYcCWwR8Wno0FK4dPrxX/pl12KDL/FJbq0M2VQiAY/1zlemj8NiM9Dl+vpwSut3n1evstTQ6Z1PjE4/HM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsIqt6Pr9miQtyhONRxMR2ZmunTYVmEtDeIcs9igUgH4RLE+nA
	yULsssPOxN+LgqyPB1phns+UC5MobsOboAzPDyHeTpoyrK15WMEt4G0g9F8DUCOC8A==
X-Gm-Gg: ASbGncvbNn/Vp6jxx/YAg2CMUSHPJP4EFDkY1RADTVlp20eOc2ReQ2M7f+h9l8Yeifd
	RA1/8WaugykaaM+CJQvoySb08OodItK0LGueEg6P6uXCqBgm+aT7bAlQB89yZsC7Er3uyWiW1X8
	ke+58PRHvlFZr0Xko0zGNz/yr8n/0ZdNGL8CH2OvVUIWdDJ/9kL+0ecSRri+5VX4ZOofTldaHT5
	uXconS4qnGUbIkFaySBq5Vy3jumP3xt2l5L4N48i6SOalBrqm0fkjJv2WJ6obL8YlJZcd8hbjqw
	ZFmKFLnGHn0XeHw+IEVRofrCtF160TP4yzHAl7R9tSdZfHJ2YdoPGXdldJNE8nA9ukApYO9eHSp
	57wRXZwjSN9y55f2PNA+wHHN/CWSMd9Z7
X-Google-Smtp-Source: AGHT+IEcqnZgMFha6jm/TEB+aotOlCXivnGvdvual/2HisH28kWM5IrwCsAzg3iTxLcGkkZHTBhPBQ==
X-Received: by 2002:a05:6000:2404:b0:3e8:68:3a91 with SMTP id ffacd0b85a97d-3ee87327ab7mr11233343f8f.60.1758571380362;
        Mon, 22 Sep 2025 13:03:00 -0700 (PDT)
Message-ID: <0fcec56c-50cd-4427-864a-3c750d66f813@suse.com>
Date: Mon, 22 Sep 2025 22:02:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 16/18] xen/riscv: implement mfn_valid() and page
 reference, ownership handling helpers
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: 
 <09317ebbd1f6fb7dda9454aa7e0b1ba3cbd0726c.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <09317ebbd1f6fb7dda9454aa7e0b1ba3cbd0726c.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> 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, initialize pdx_group_valid() by calling set_pdx_range() when
> memory banks are being mapped.
> 
> 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 `alloc_heap_pages':
>   /build/xen/common/page_alloc.c:1054: undefined reference to `page_is_offlinable'
>   riscv64-linux-gnu-ld: /build/xen/common/page_alloc.c:1035: undefined reference to `page_is_offlinable'
>   riscv64-linux-gnu-ld: prelink.o: in function `reserve_offlined_page':
>   /build/xen/common/page_alloc.c:1151: undefined reference to `page_is_offlinable'
>   riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol `page_is_offlinable' isn't defined
>   riscv64-linux-gnu-ld: final link failed: bad value
>   make[2]: *** [arch/riscv/Makefile:28: 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.
> - Implement page_is_offlinable() to return false for RISC-V.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 
with two cosmetic adjustments:

> @@ -642,3 +648,30 @@ void put_page(struct page_info *page)
>              free_domheap_page(page);
>      }
>  }
> +
> +bool page_is_offlinable(mfn_t mfn)
> +{
> +    return false;
> +}

I think this wants to move elsewhere, or ...

> +struct domain *page_get_owner_and_reference(struct page_info *page)

... this wants to move up, such that the "get" and "put" logic are next
to each other.

> +{
> +    unsigned long x, y = page->count_info;
> +    struct domain *owner;
> +
> +    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 + 1) & PGC_count_mask) <= 1) )
> +            return NULL;
> +    }
> +    while ( (y = cmpxchg(&page->count_info, x, x + 1)) != x );

This again wants the figure brace placement corrected.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 20:47:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 20:47:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128018.1468512 (Exim 4.92)
	(envelope-from )
	id 1v0nR1-0003Nn-56; Mon, 22 Sep 2025 20:46:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128018.1468512; Mon, 22 Sep 2025 20:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0nR1-0003Ng-27; Mon, 22 Sep 2025 20:46:55 +0000
Received: by outflank-mailman (input) for mailman id 1128018;
 Mon, 22 Sep 2025 20:46:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v0nQz-0003Na-TF
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 20:46:53 +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 40ad501d-97f5-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 22:46:45 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3fc36b99e92so1007159f8f.0
 for ; Mon, 22 Sep 2025 13:46:45 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77ecd17bddbsm9892556b3a.46.2025.09.22.13.46.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 13:46: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: 40ad501d-97f5-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758574005; x=1759178805; 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=RMAuhS4M5Wh9tEZvNK3xTc2/DAJwSlJkAM9Ci9B42Xs=;
        b=T4cV+YrtObrCVQf/ScoD/ra0w5wZTA2X1X+/YT7NjuBnucnhO6tfcqEZlRETEE6Sp/
         8JutjN26jJ/1Q95UGB6gf0mVXwJhtPTSqDZRC5Kl8jGD5wJVwiXNt7O9QYSH4GrQe/gu
         5bswABxSJOrjZITonWUpIJRszNrlHmHFiztqdf2Jb6GDyYzL22T6+J7VNfhsdOL3JBBm
         hwjU8eCU+XKqKVsOoPljK5VAgX1fgz5zDBbyBT9M1x1wgCrFB+p9EEu3ms1QfcfleJnv
         eOil/YoIDVC5/iRR2Vc6G92I/O2hvatz72TVFDnDt3FvoENyr1I8RAKSuOaYrnOVRx2O
         Zagw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758574005; x=1759178805;
        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=RMAuhS4M5Wh9tEZvNK3xTc2/DAJwSlJkAM9Ci9B42Xs=;
        b=Ddi+mXUpLrskIB7dZcVA7jLp9/PBnrQqgtTS6rv8XRGIXrjeOFr3K0pWCEKkvHwUcS
         vrRrY/vBbdoRqMnxpEqm/cyv3p6LR0ZVw+1wFt7lKJzNOc/7ECmz5mbIQqo8tKWseVxC
         kflpRwIOIIBEftAQ4+8XD2ZHih6OasAXOyVNKtFGfEFgCvBA4qndxYFN312hLgHHAmCw
         3UTBRKtgcC/AQ7D0JpHgHpaWmaIQEzeh5EzVeh1qrWtsJ1FBObtDbfK3iEOVvGu6b0nC
         d5cW15aP10Eu90wxD229x378NrKjW7T8PNibcBx3kBAvjj2TJx1qI/KxmgudS8udEklH
         TTgQ==
X-Forwarded-Encrypted: i=1; AJvYcCXvmOj0vTuYdI/D25eKRKSeeQZf5ECcWLxuk1euJ5MN0hBGAtu0iK3GQ61OwMXLb+wfelZNfobR5AU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxAeh+ETLeeUGFi5rFy32oKT8lIj4/UxJE+3Ye2hE65xDIQ54Ti
	V23sCKA9MvjAGaLaYfGP0D1FqHr2V4nkORIX1UTTp4to7b9iJ56QLrjfBVzS2/Xffw==
X-Gm-Gg: ASbGncvz7SriZYJ66LwwzthkQm6dG/aBYDN43KIfjusb0C2V1oXjEqLVdLE01Mhogso
	W3nriE1MTanF2euRq85lNtFRz/b/GML6+LyWU3v0eVyjfx1zHYjABlg+lWzbOAQQPrPP8TM4rd6
	nbutVHNaXn/j5eSh5FhtoXvdJCI002K46TE2sf2p+ZVqmWz5fknNraRYBK//CDbdh+ChG+YD1pO
	efTCVaKGUikNgGX7Gise2izteK0mJhRqZekxDBmZl0kOw/OEtzgnmNitsNKdGtcOer4FxJDm+Wl
	NqFXAd3ubDmvXjTZZ/BkHCM7df5j3dtdJp3nb5eZWv4O4y7DwCob59AN+r1u61ISm5tpuKpNQaJ
	VVBucDxcTZtektDudkKyDdH0Ncdqvy7TR
X-Google-Smtp-Source: AGHT+IGsviZaYA6TnQq91jrrbiJfIJTxLJhofAoWtN/Ukup8rsD0Okg2tml2CZ97Mc8282hlvHhgSQ==
X-Received: by 2002:a05:6000:18a5:b0:3ec:42f9:953e with SMTP id ffacd0b85a97d-405cb1fbf3fmr60343f8f.7.1758574005094;
        Mon, 22 Sep 2025 13:46:45 -0700 (PDT)
Message-ID: <854ff53f-5af0-43bf-83b0-8e1e1e0deefc@suse.com>
Date: Mon, 22 Sep 2025 22:46:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 17/18] xen/riscv: add support of page lookup by 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: 
 <5065d9f1552fd940cc19087d8e00a0fa3519e66c.1758145428.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <5065d9f1552fd940cc19087d8e00a0fa3519e66c.1758145428.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -978,3 +978,189 @@ int map_regions_p2mt(struct domain *d,
>  
>      return rc;
>  }
> +
> +

Nit: No double blank lines please.

> +/*
> + * p2m_get_entry() should always return the correct order value, even if an
> + * entry is not present (i.e. the GFN is outside the range):
> + *   [p2m->lowest_mapped_gfn, p2m->max_mapped_gfn]).    (1)
> + *
> + * This ensures that callers of p2m_get_entry() can determine what range of
> + * address space would be altered by a corresponding p2m_set_entry().
> + * Also, it would help to avoid cost page walks for GFNs outside range (1).
> + *
> + * Therefore, this function returns true for GFNs outside range (1), and in
> + * that case the corresponding level is returned via the level_out argument.
> + * Otherwise, it returns false and p2m_get_entry() performs a page walk to
> + * find the proper entry.
> + */
> +static bool check_outside_boundary(gfn_t gfn, gfn_t boundary, bool is_lower,
> +                                   unsigned int *level_out)
> +{
> +    unsigned int level;
> +
> +    if ( (is_lower && gfn_x(gfn) < gfn_x(boundary)) ||
> +         (!is_lower && gfn_x(gfn) > gfn_x(boundary)) )

I understand people write things this way, but personally I find it confusing
to read. Why not simply use a conditional operator here (and again below):

    if ( is_lower ? gfn_x(gfn) < gfn_x(boundary)
                  : gfn_x(gfn) > gfn_x(boundary) )

> +    {
> +        for ( level = P2M_ROOT_LEVEL; level; level-- )
> +        {
> +            unsigned long mask = PFN_DOWN(P2M_LEVEL_MASK(level));

Don't you need to accumulate the mask to use across loop iterations here
(or calculate it accordingly)? Else ...

> +            if ( (is_lower && ((gfn_x(gfn) & mask) < gfn_x(boundary))) ||
> +                 (!is_lower && ((gfn_x(gfn) & mask) > gfn_x(boundary))) )

... here you'll compare some middle part of the original GFN against the
boundary.

> +            {
> +                *level_out = level;
> +                return true;
> +            }
> +        }
> +    }
> +
> +    return false;
> +}
> +
> +/*
> + * Get the details of a given gfn.
> + *
> + * If the entry is present, the associated MFN will be returned and the
> + * p2m type of the mapping.
> + * 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)
> +{
> +    unsigned int level = 0;
> +    pte_t entry, *table;
> +    int rc;
> +    mfn_t mfn = INVALID_MFN;
> +    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
> +
> +    ASSERT(p2m_is_locked(p2m));
> +
> +    if ( valid )
> +        *valid = false;

Wouldn't you better similarly set *t to some "default" value?

> +    if ( check_outside_boundary(gfn, p2m->lowest_mapped_gfn, true, &level) )
> +        goto out;
> +
> +    if ( check_outside_boundary(gfn, p2m->max_mapped_gfn, false, &level) )
> +        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, false, level, &table, offsets[level]);
> +        if ( (rc == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
> +            goto out_unmap;

Getting back P2M_TABLE_MAP_NOMEM here is a bug, not really a loop exit
condition.

> +        if ( rc != P2M_TABLE_NORMAL )
> +            break;
> +    }
> +
> +    entry = table[offsets[level]];
> +
> +    if ( pte_is_valid(entry) )
> +    {
> +        if ( t )
> +            *t = p2m_get_type(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(P2M_LEVEL_ORDER(level), UL) - 1));

May want to assert that the respective bits of "mfn" are actually clear
before this calculation.

> +        if ( valid )
> +            *valid = pte_is_valid(entry);
> +    }
> +
> + out_unmap:
> +    unmap_domain_page(table);
> +
> + out:
> +    if ( page_order )
> +        *page_order = P2M_LEVEL_ORDER(level);
> +
> +    return mfn;
> +}
> +
> +static mfn_t p2m_lookup(struct p2m_domain *p2m, gfn_t gfn, p2m_type_t *t)
> +{
> +    mfn_t mfn;
> +
> +    p2m_read_lock(p2m);
> +    mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL);

Seeing the two NULLs here I wonder: What use is the "valid" parameter of that
function? And what use is the function here when it doesn't also return the
order? IOW I'm not sure having this helper is actually worthwhile. This is
even more so that ...

> +    p2m_read_unlock(p2m);
> +
> +    return mfn;
> +}
> +
> +struct page_info *p2m_get_page_from_gfn(struct p2m_domain *p2m, gfn_t gfn,
> +                                        p2m_type_t *t)
> +{
> +    struct page_info *page;
> +    p2m_type_t p2mt = p2m_invalid;
> +    mfn_t mfn;
> +
> +    p2m_read_lock(p2m);
> +    mfn = p2m_lookup(p2m, gfn, t);

... there's a locking problem here: You cannot acquire a read lock in a
nested fashion - that's a recipe for a deadlock when between the first
acquire and the 2nd acquire attempt another CPU tries to acquire the
lock for writing (which will result in no further readers being allowed
in). It wasn't all that long ago that in the security team we actually
audited the code base for the absence of such a pattern.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 20:50:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 20:50:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128031.1468523 (Exim 4.92)
	(envelope-from )
	id 1v0nUp-0004vw-JF; Mon, 22 Sep 2025 20:50:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128031.1468523; Mon, 22 Sep 2025 20: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 1v0nUp-0004vo-GQ; Mon, 22 Sep 2025 20:50:51 +0000
Received: by outflank-mailman (input) for mailman id 1128031;
 Mon, 22 Sep 2025 20: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 1v0nUo-0004vg-Ae
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 20:50: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 d10f1d97-97f5-11f0-9d14-b5c5bf9af7f9;
 Mon, 22 Sep 2025 22:50:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 23D5744FA2;
 Mon, 22 Sep 2025 20:50:47 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15AAAC4CEF5;
 Mon, 22 Sep 2025 20:50: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: d10f1d97-97f5-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758574247;
	bh=nILeU37UX1ua/jwG/uBmy8uCKASAiO+/TPWVYEYKYDA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KY1fPMpYJccRRvRfSLaUdp8eBGZeeGSp1E+ETef+QBaXy5JBE1UnM1A2SNAgNqR2d
	 pTwGr2URIvq7Rhm6hthlcdQ/f54MALZb+ly91TMbO55Ax5RDjXPlPfQZm/dYXKWXcy
	 6cc8aVHF0jHl/ImezmQUkSV4yG/5fbCzbltrVV1B38naSIZNSeLdYFBUYgQM/qjNFj
	 sRdO8EqXU5plm6wxwmdg0jpHrQgr0UarDrx6tK9Ea+kNjGpFF8fJxJFWOhldpIeScx
	 rbA1iWM73CKVow/dctjcF6nYwrO70cbAQfvRquQ+f9/acNzMDv78zUAYxJRgU68EUu
	 Eqkr73iuM1H0g==
Date: Mon, 22 Sep 2025 13:50:44 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Ayan Kumar Halder 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Michal Orzel , 
    Bertrand Marquis , 
    Volodymyr Babchuk 
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
In-Reply-To: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
Message-ID: 
References: <20250912170055.3077923-1-ayan.kumar.halder@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, 12 Sep 2025, Ayan Kumar Halder wrote:
> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
> Test that Xen is able to generate SGIs.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---
> One of the aim of functional safety is to test hw/sw interface. This means that
> Xen is able to configure the hardware correctly for the desired functionalities.
> 
> Normally this is tested from the VMs. For eg if a VM is able to receive irq, this
> implies that Xen has configured the GICv3 interface 'correctly'. However this is
> a high level (or integration) test which uses not only the GICv3 interface
> between Xen and VM, but the interrupt injection code for Xen to VMs.
> 
> We want to have some kind of unit tests to check that Xen is able to receive
> various interrupts, set priorities, etc. Here, we have written unit tests for
> software generated interrupts (SGIs) as example.
> 
> These tests are expected to be triggered as Xen boots (right after Xen has
> initialised the GICv3 interface ie gicv3_init(). The aim of this test is to
> check whether Xen can trigger SGIs after gicv3_init() is invoked. If so, we can
> claim that gicv3_init() was done properly to be able to trigger SGIs. Likewise
> we will have tests to check for priorities, SPIs, etc.
> 
> A script will parse the logs and claim that Xen is able to trigger SGIs.

I like this approach and I think it is OK if Xen is not functional after
some of the SELFTESTS because it is not the goal to run those in a
working system.

My only suggestion is to separate the SELFTESTS in a separate __init
function, keeping them isolated from the rest of the code, for simplicy
and also ease of understanding.

See for example stub_selftest.


>  xen/arch/arm/Kconfig  |  8 ++++++++
>  xen/arch/arm/gic-v3.c |  7 +++++++
>  xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>  3 files changed, 36 insertions(+)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 950e4452c1..739f99eaa9 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -73,6 +73,14 @@ config GICV3
>  	  Driver for the ARM Generic Interrupt Controller v3.
>  	  If unsure, use the default setting.
>  
> +config GICV3_SELFTEST
> +    bool "GICv3 driver self test"
> +    default n
> +    depends on GICV3
> +    ---help---
> +
> +      Self tests to validate GICV3 driver.
> +
>  config HAS_ITS
>          bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>          depends on GICV3 && !NEW_VGIC && !ARM_32
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 4e6c98bada..eb0c05231c 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>  
>      gicv3_hyp_init();
>  
> +#ifdef CONFIG_GICV3_SELFTEST
> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
> +    send_SGI_self(GIC_SGI_DUMP_STATE);
> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
> +    send_SGI_self(GIC_SGI_MAX);
> +#endif
> +
>  out:
>      spin_unlock(&gicv3.lock);
>  
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index d922ea67aa..5cb58cdb92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>       */
>      smp_rmb();
>  
> +#ifdef CONFIG_GICV3_SELFTEST
> +    switch (sgi)
> +    {
> +    case GIC_SGI_EVENT_CHECK:
> +        printk("GIC_SGI_EVENT_CHECK received\n");
> +        break;
> +    case GIC_SGI_DUMP_STATE:
> +        printk("GIC_SGI_DUMP_STATE received\n");
> +        break;
> +    case GIC_SGI_CALL_FUNCTION:
> +        printk("GIC_SGI_CALL_FUNCTION received\n");
> +        break;
> +    case GIC_SGI_MAX:
> +        printk("GIC_SGI_MAX received\n");
> +        break;
> +    default:
> +        panic("Unknown SGI triggered\n");
> +        break;
> +    }
> +#else
>      switch (sgi)
>      {
>      case GIC_SGI_EVENT_CHECK:
> @@ -361,6 +381,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>          panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
>          break;
>      }
> +#endif
>  
>      /* Deactivate */
>      gic_hw_ops->deactivate_irq(desc);
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 21:36:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 21:36:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128046.1468533 (Exim 4.92)
	(envelope-from )
	id 1v0oCN-0001aP-QV; Mon, 22 Sep 2025 21:35:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128046.1468533; Mon, 22 Sep 2025 21:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0oCN-0001aI-NZ; Mon, 22 Sep 2025 21:35:51 +0000
Received: by outflank-mailman (input) for mailman id 1128046;
 Mon, 22 Sep 2025 21:35: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 1v0oCL-0001aC-Gg
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 21:35:50 +0000
Received: from 4.mo560.mail-out.ovh.net (4.mo560.mail-out.ovh.net
 [87.98.172.75]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 199c4069-97fc-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 23:35:46 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.109.231.96])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4cVxHQ2MTFzBQYg
 for ; Mon, 22 Sep 2025 21:35:46 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-qvgpv (unknown [10.110.113.47])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 60203C28BC;
 Mon, 22 Sep 2025 21:35:45 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.104])
 by ghost-submission-5b5ff79f4f-qvgpv with ESMTPSA
 id 0zxfCjHB0WiyvBoA7uDI/g
 (envelope-from ); Mon, 22 Sep 2025 21:35: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: 199c4069-97fc-11f0-9809-7dc792cee155
Authentication-Results:garm.ovh; auth=pass (GARM-104R005f2fac25f-e7ae-4f46-a376-a5805aa9834a,
                    4B26FE2FE36F17FB9A3A38C231369D4D6C4B196D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 23 Sep 2025 00:35:30 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 06/22] xen/arch/x86: reserve TXT memory during Slaunch
Message-ID: 
References: 
 <8d5ba2e7a0a8bd05bb9cdb89db3f15b831f7f4f7.1748611041.git.sergii.dmytruk@3mdeb.com>
 <45ed8b90-ce0c-419e-9c7d-2ab58ee539a2@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45ed8b90-ce0c-419e-9c7d-2ab58ee539a2@suse.com>
X-Ovh-Tracer-Id: 13921189398624187481
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTERb8Oxo8S/0Wa2nJbd9TjVIDg8LDD37hmyuj6GLjx15DRn6mxqxgBNx7HotMB8TL/+r3YBEgHX1gCu7kaAmGu2jq+or1m/Uw5O95CmvMLvIXkMJwBERTHs3ErCcPL1mSvkmNdvEZCUxdu3zWVv+309zPtm4RN5knzR0ENGVtwdVe5NbFLlda/dvE8eM2lS8q3B6phSwdyCP35OhY2+JxWbt2Xvu6JDIeVoY10rQch0au4SHFVExHZFoE1NSbkQ/eHEj/cMhQHf4ApQb2FQ54tCwTkUgAP2m/Q1zUVYgA0qc56Uhlf4luGTQTkeZK/H2Y+d7lPtq79yC0OiAk3SEYwcX1mNggXzSwtU9Uf1UF1NoWH+MZRd5LNKeUEyZQT/mbvGTq9xbVRdysVo+VsdZMQnkDQBbHjXyEQGEUofkJwP0gendHoygBUz53gI+Rwxz9a1q4f7KxWHS+3nfFE4Pp6zZEmgSK/F/eS1wBc5HBPPqKanNwu8Ip01v0ZUO3jwiJL4hJusBhlRDlQKFuhoRHzlkWCZegPitIcEdRvUMbWF+TGjk4QPdeStdDknNgnWDjWVculJteiYLxJFXH86iWNoUfou0aEON7U1bmGr/NZ7wR3y0ayKXBrtEqT06LJt6le2HGdmn9Adv8/WmHm3Jwos7q3RJnih9aY5SRmTSIk64Q
DKIM-Signature: a=rsa-sha256; bh=OHyhAsh96i6iRRchQGxJi+NXgMkVdO+Sskp5R016YII=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1758576946; v=1;
 b=msPS1QfvoNk+FFXYmX4uKj2cQmwXd6PaMpvtq7RO1AkFhHg4Zo9nKGvqNePeJA61m61KD0xU
 jJxJn8YTTZo/2OGnPww8P3l/2qxZh5ou6YlAil+o+xWYWgjkIIVlxBxjuBL+YBQnCkvAWhlAJCm
 /+/TmaCLCJLNtBOi1hDZ+pThcTQw/JM1fK84n5nQUDTEkGEYx5XJzj1XnOqWNGH/s5LqsmwQ2r/
 H7bI0TTZkD/gL6UeAsXxtkATbgiZc3ld3j/xiyrYZA8LjfLu2MgnLKlz5M/nm/eMavNCMJJwnVR
 /Pd0E7yXV7QAAlyWsZuL6HYI6mdFDJm3x6FB+WIYYu1lg==

On Thu, Jul 10, 2025 at 03:00:07PM +0200, Jan Beulich wrote:
> On 30.05.2025 15:17, Sergii Dmytruk wrote:
> > --- a/xen/arch/x86/include/asm/mm.h
> > +++ b/xen/arch/x86/include/asm/mm.h
> > @@ -106,6 +106,9 @@
> >  #define _PGC_need_scrub   _PGC_allocated
> >  #define PGC_need_scrub    PGC_allocated
> >
> > +/* How much of the directmap is prebuilt at compile time. */
> > +#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
>
> Better 1U or even 1UL?

Will change to 1UL.  L2_PAGETABLE_SHIFT is 21, so all variants are
essentially the same.

>From another email:
> Oh, also - I don't think mm.h is a good place for this. Please
> consider putting into setup.h.

Sure, mm.h just had a more suggestive name.

> > +/*
> > + * evt_log is assigned a physical address and the caller must map it to
> > + * virtual, if needed.
>
> In which case you want to use paddr_t, not void *.

Will change.

> > + */
> > +static inline void find_evt_log(const struct slr_table *slrt, void **evt_log,
> > +                                uint32_t *evt_log_size)
> > +{
> > +    const struct slr_entry_log_info *log_info;
> > +
> > +    log_info = (const struct slr_entry_log_info *)
> > +        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_LOG_INFO);
>
> In situations like this please use the less type-unsafe container_of().
> (Apparently applies also to at least one earlier patch.)

Will update all places.

> > +int slaunch_map_l2(unsigned long paddr, unsigned long size);
>
> While largely benign on x86-64, maybe better paddr_t and size_t. And then ...

OK.

> > +static uint64_t __initdata txt_heap_base, txt_heap_size;
>
> ... why suddenly uint64_t here (and then elsewhere below)?

These have 64 bits allocated for them in TXT register space.
The spec only talks about bits 31:0 (unless its a typo), so I'll add a
comment about that and use `uint32_t`.

> > +/* Mark RAM region as RESERVED if it isn't marked that way already. */
> > +static int __init mark_ram_as(struct e820map *map, uint64_t start,
> > +                              uint64_t end, uint32_t type)
> > +{
> > ...
> > +
> > +    /* E820_ACPI or E820_NVS are really unexpected, but others are fine. */
> > +    if ( map->map[i].type == E820_RESERVED ||
> > +         map->map[i].type == E820_UNUSABLE )
>
> Are you sure about permitting UNUSABLE here?

Not really, I'll drop it.

> > +        from_type = map->map[i].type;
> > +
> > +    return e820_change_range_type(map, start, end, from_type, type);
>
> Even if this function, for historic reasons, also returns int/0/1, please make
> new code with boolean results return bool/false/true.

OK.

> > +void __init txt_reserve_mem_regions(void)
> > +{
> > +    int rc;
> > +    uint64_t sinit_base, sinit_size;
> > +
> > +    /* TXT Heap */
> > +    BUG_ON(txt_heap_base == 0);
> > +    printk("SLAUNCH: reserving TXT heap (%#lx - %#lx)\n", txt_heap_base,
> > +           txt_heap_base + txt_heap_size);
>
> Please log ranges in a way that makes it unambiguous whether they're exclusive
> or inclusive (especially at the upper end).

I'll use start:end notation which I think suggests inclusive bounds.

> > +    /* TXT Private Space */
> > +    rc = mark_ram_as(&e820_raw, TXT_PRIV_CONFIG_REGS_BASE,
> > +                     TXT_PRIV_CONFIG_REGS_BASE + TXT_CONFIG_SPACE_SIZE,
> > +                     E820_UNUSABLE);
>
> Why UNUSABLE? Then, if all callers used RESERVED, this wouldn't need to be
> a function arguments anymore, and you also wouldn't need to change RESERVED
> ranges.

I think it was suggested during some review as a way to prevent an OS
from using a range (reserved ones can still get used), but I'm not sure
it even works, so will revert to always reserve memory.

> > - * Launch boot.
> > + * Launch boot at any point.
>
> This comment adjustment should probably move to where the comment is being
> introduced.

Thanks, I probably forgot to do it.

> > +struct slr_table *__init slaunch_get_slrt(void)
> > +{
> > +    static struct slr_table *slrt;
>
> __initdata?

Right, will add.

> > +    if (slrt == NULL) {
>
> Nit: Style.

Will fix.

> > +            panic("SLRT has invalid magic value: %#08x!\n", slrt->magic);
>
> While %#x is indeed the prefered form to use, in particular when padding that's
> not normally helpful, as the 0x prefix is included in the character count. And
> the value zero also ends up odd in that case, I think.

I constantly forget about prefix being included.  Won't specify width
here, it's not particularly useful in these cases.

> > +int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
> > +{
> > +    unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
> > +    unsigned long pages = ((paddr + size) - aligned_paddr);
> > +    pages = ROUNDUP(pages, 1ULL << L2_PAGETABLE_SHIFT) >> PAGE_SHIFT;
>
> Nit: Blank line please between declaration(s) and statement(s).

OK.

> > +    if ( aligned_paddr + pages * PAGE_SIZE <= PREBUILT_MAP_LIMIT )
> > +        return 0;
> > +
> > +    if ( aligned_paddr < PREBUILT_MAP_LIMIT )
> > +    {
> > +        pages -= (PREBUILT_MAP_LIMIT - aligned_paddr) >> PAGE_SHIFT;
> > +        aligned_paddr = PREBUILT_MAP_LIMIT;
> > +    }
> > +
> > +    return map_pages_to_xen((uintptr_t)__va(aligned_paddr),
> > +                            maddr_to_mfn(aligned_paddr),
> > +                            pages, PAGE_HYPERVISOR);
> > +}
>
> What is being mapped here is (silently?) assumed to be below 4Gb? The
> function could anyway do with a brief comment saying what it's intended
> to do, and what assumptions it makes.
>
> It further looks as if you may be doing the same mapping multiple times,
> as you don't record what was already mapped.
>
> Jan

There is a large comment in slaunch.h which explains that we don't care
about unmapping because memory pages are being rebuilt after this
function is used.  No need to track what's being mapped for the same
reason.

DRTM data is below 4 GiB, will add BUG_ON() calls and update a comment
to state that.

Regards


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 21:56:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 21:56:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128058.1468542 (Exim 4.92)
	(envelope-from )
	id 1v0oWP-0004N7-CO; Mon, 22 Sep 2025 21:56:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128058.1468542; Mon, 22 Sep 2025 21:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0oWP-0004N0-9M; Mon, 22 Sep 2025 21:56:33 +0000
Received: by outflank-mailman (input) for mailman id 1128058;
 Mon, 22 Sep 2025 21:56:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v0oWO-0004Mu-Fb
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 21:56:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v0oWJ-004pxL-1B;
 Mon, 22 Sep 2025 21:56:27 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v0oWJ-007nRZ-12;
 Mon, 22 Sep 2025 21:56: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=Klu5QEiSkhnW8sBi6uPAWE9QN7Q6Qb+CqegtJdVzPB8=; b=
	P927ngAtdQayCkZuXXsabyNvgjhKrzJepVgHDlz04/w+uNM5P2t2RHcaOEwneuJvEDwzTf56NChZK
	yPou+a2YdUI/vhDjo6IN+8+ZwtxhpoFEBrmw8iU4GKpsLpFb9BzMAkWbWTamc3LZ1cd+uN+1cmX7h
	F6ylMEfnhjCzh1Nuc=;
From: dmukhin@xen.org
Date: Mon, 22 Sep 2025 14:56:26 -0700
To: Jan Beulich 
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 v2] xen/domain: introduce DOMID_ANY
Message-ID: 
References: <20250920174732.1207847-2-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Mon, Sep 22, 2025 at 05:23:37PM +0200, Jan Beulich wrote:
> On 20.09.2025 19:47, dmukhin@xen.org wrote:
> > From: Denis Mukhin  
> > 
> > Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
> > of the code.
> > 
> > Update all relevant domid_alloc() call sites.
> > 
> > Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v1:
> > - moved DOMID_ANY from the public header
> 
> This addresses my comment, but not Andrew's subsequent response, specifically
> aiming at ...

AFAIU, toolstack should start using DOMID_ANY instead of 0 in
XEN_DOMCTL_createdomain.

I was planning to send a separate patch to address it if that's OK.

> 
> > --- a/tools/tests/domid/harness.h
> > +++ b/tools/tests/domid/harness.h
> > @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
> >  
> >  #define DOMID_FIRST_RESERVED            (100)
> >  #define DOMID_INVALID                   (101)
> > +#define DOMID_ANY                       DOMID_INVALID
> 
> ... avoiding the need for any such secondary definitions.

In the current design, unit test harness.h has to define DOMID_ANY.
Enabling xen/domain.h to compile for unit test is a separate task, IMO.

> 
> Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 22:42:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 22:42:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128076.1468552 (Exim 4.92)
	(envelope-from )
	id 1v0pEM-0001sk-Pl; Mon, 22 Sep 2025 22:41:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128076.1468552; Mon, 22 Sep 2025 22:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0pEM-0001sd-Mu; Mon, 22 Sep 2025 22:41:58 +0000
Received: by outflank-mailman (input) for mailman id 1128076;
 Mon, 22 Sep 2025 22:41: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 1v0pEK-0001sW-VS
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 22:41:57 +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 565fc3e5-9805-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 00:41:54 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3f0134ccc0cso3785953f8f.1
 for ; Mon, 22 Sep 2025 15:41:54 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3306061ab62sm14369871a91.5.2025.09.22.15.41.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 15:41: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: 565fc3e5-9805-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758580913; x=1759185713; 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=C1Bsn0OY3Xig92N/mGRRCwjcnHQL4lADUat1Obrt33Q=;
        b=NsAdaYuq+AIqqDH3+nxubW1ejhbOzCrPsp+lJrp4jHIaKsWNuSNzIB80S2y0FT+Mq6
         jhUceLMGbjQio+RYizqVJppZbfvX7keo7mhsjljPdfSXxzoUrsu3yqCZX7ZqYnq8jNFH
         37PRpYmz/Uiqh76GQ94qvleGVOl6/kpVAsKV2Na5r+b5jay3m+vnHtFH0DvUzmnVXwyC
         XnqUTrk6L9dvNsAX1mBFYt7JaceLUNTPCme9fTntaNAIKEYkreuLBw8ogb8ra0J+ttCO
         T1z1yq52JgoJh91CZJaxOkPhggCByzY8A663DttLTKQfXrm/CGLnWouGZpcB5EqrNTBc
         YPcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758580913; x=1759185713;
        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=C1Bsn0OY3Xig92N/mGRRCwjcnHQL4lADUat1Obrt33Q=;
        b=LUWlLGC6KVFfy3Tx1VdKonGc6v2d4XKwfXF3BbN8MSjL/fANaf8v/MCYk+PIQcT4zM
         g4l/HcpK5i6y8bTSStnq3nmKZYnlIWYxKh3UDvAdu8o4nptwBVGo5zBh296pazqQdJoC
         T9py0wOaKj6KFNmEreDypWc3GHKzeC1uvr8mV2/jDIyWJJ/WWPEJTJVnOyyuGpsnkn5B
         gBBxXCFQutJ6LxIC12axBhDqoBARgart/WIce1l10ldI2s/hioNPqTlxz1nNIs5QrdmM
         8b1+xyKFUmKu73qY5MzVFl4X5bxsxXoT+iKPChn8GvvUBzo6oY15ztZ8xalnukEaPDDn
         UAUQ==
X-Forwarded-Encrypted: i=1; AJvYcCWCv6/eSbR3ciqf087Bei+g/4vqCrzUUGN/9MC57R0VcaIMqujYQGymKUQj/LBYTz181EQWZQ7lkCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOWdJAH+b7+UnjHk74d6kM+FgQtHkGJiCB6OPgVNRXRGeGQIXs
	HWIBhsCpDIbEMLE/yM4Jznbxxrh7su/PPatRSGCaaN1i+64raGMOjzgXnajCddDZ4A==
X-Gm-Gg: ASbGncv9DsC9NT6lNvw4WJU5bv4ck9+5t6afh2s6hHrubsW/K74C7IHaDAHTRke9S+V
	/gwOrxnb85sAz6D1WUxtgHgiM9jtZEbcg+Z7P5LRi+CBSGjE1P5oyMeCg9E8KjsuqvyDHumK2f7
	2FCWWXh94g7LzqUOKWyF0dtQkaoX7JDY/Xg00darX1QbVsrPC+/rUMozBKURwvrLAo+ikijgXND
	ImN0yX5EgjR0F4tf5BXfx2WCTTJ/2xiG95ywAEepGOEL+cXpOW0AgyPzlQzdTc8+MWb7IwJtSsS
	GRijn598yr6DufTTO1EfqMqtmybql+dBsSvv+psFJSf0cOL8Xo4sDw8xDx4vYYuZgrZfQGJtFqt
	KRVZcq2PB8yOqlxZhwmqpUuBStFO3diW1
X-Google-Smtp-Source: AGHT+IG5pKDyHFkSQE+LiQfWe1zbzS9V8i8LkZTWZenbeTMSS9QRJVLZ4H7SLaRWlZbQgdKmn8pahA==
X-Received: by 2002:a5d:5d0b:0:b0:3e7:68b2:c556 with SMTP id ffacd0b85a97d-405c523c775mr230295f8f.26.1758580913469;
        Mon, 22 Sep 2025 15:41:53 -0700 (PDT)
Message-ID: <4c2eb99b-3e88-4364-8c3f-7c70d4064ef4@suse.com>
Date: Tue, 23 Sep 2025 00:41:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 18/18] xen/riscv: introduce metadata table to store P2M
 type
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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -149,6 +149,15 @@ struct page_info
>              /* Order-size of the free chunk this page is the head of. */
>              unsigned int order;
>          } free;
> +
> +        /* Page is used as an intermediate P2M page table */
> +        struct {
> +            /*
> +             * Pointer to a page which store metadata for an intermediate page
> +             * table.
> +             */
> +            struct page_info *metadata;

Any reason for this to not be "page" or "pg"? The metadata aspect is already
covered ...

> +        } md;

... by the "md" here.

> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -16,6 +16,16 @@
>  #include 
>  #include 
>  
> +/*
> + * P2M PTE context is used only when a PTE's P2M type is p2m_ext_storage.
> + * In this case, the P2M type is stored separately in the metadata page.
> + */
> +struct p2m_pte_ctx {
> +    struct page_info *pt_page;   /* Page table page containing the PTE. */
> +    unsigned int index;          /* Index of the PTE within that page. */
> +    unsigned int level;          /* Paging level at which the PTE resides. */
> +};
> +
>  unsigned long __ro_after_init gstage_mode;
>  unsigned int __ro_after_init gstage_root_level;
>  
> @@ -289,24 +299,98 @@ 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_set_type(pte_t *pte, p2m_type_t t)
> +static struct page_info * p2m_alloc_table(struct p2m_domain *p2m);

Nit: Stray blank again.

> +/*
> + * `pte` – PTE entry for which the type `t` will be stored.
> + *
> + * If `t` is `p2m_ext_storage`, both `ctx` and `p2m` must be provided;
> + * otherwise, they may be NULL.
> + */
> +static void p2m_set_type(pte_t *pte, const p2m_type_t t,
> +                         struct p2m_pte_ctx *ctx,
> +                         struct p2m_domain *p2m)
>  {
> -    int rc = 0;
> +    /*
> +    * For the root page table (16 KB in size), we need to select the correct
> +    * metadata table, since allocations are 4 KB each. In total, there are
> +    * 4 tables of 4 KB each.
> +    * For none-root page table index of ->pt_page[] will be always 0 as
> +    * index won't be higher then 511. ASSERT() below verifies that.
> +    */
> +    struct page_info **md_pg =
> +        &ctx->pt_page[ctx->index / PAGETABLE_ENTRIES].v.md.metadata;
> +    pte_t *metadata = NULL;
> +
> +     /* Be sure that an index correspondent to page level is passed. */
> +    ASSERT(ctx->index <= P2M_PAGETABLE_ENTRIES(ctx->level));

Doesn't this need to be < ?

> +    if ( !*md_pg && (t >= p2m_first_external) )
> +    {
> +        /*
> +         * Ensure that when `t` is stored outside the PTE bits
> +         * (i.e. `t == p2m_ext_storage` or higher),
> +         * both `ctx` and `p2m` are provided.
> +         */
> +        ASSERT(p2m && ctx);

Imo this would want to be checked whenever t > p2m_first_external, no
matter whether a metadata page was already allocated.

> -    if ( t > p2m_first_external )
> -        panic("unimplemeted\n");
> -    else
> +        if ( ctx->level <= P2M_SUPPORTED_LEVEL_MAPPING )
> +        {
> +            struct domain *d = p2m->domain;
> +
> +            *md_pg = p2m_alloc_table(p2m);
> +            if ( !*md_pg )
> +            {
> +                printk("%s: can't allocate extra memory for dom%d\n",
> +                        __func__, d->domain_id);
> +                domain_crash(d);
> +            }
> +        }
> +        else
> +            /*
> +             * It is not legal to set a type for an entry which shouldn't
> +             * be mapped.
> +             */
> +            ASSERT_UNREACHABLE();

Something not being legal doesn't mean it can't happen. Imo in this case
BUG_ON() (in place of the if() above) would be better.

> +    }
> +
> +    if ( *md_pg )
> +        metadata = __map_domain_page(*md_pg);
> +
> +    if ( t < p2m_first_external )
> +    {
>          pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK);
>  
> -    return rc;
> +        if ( metadata )
> +            metadata[ctx->index].pte = p2m_invalid;
> +    }
> +    else
> +    {
> +        pte->pte |= MASK_INSR(p2m_ext_storage, P2M_TYPE_PTE_BITS_MASK);
> +
> +        metadata[ctx->index].pte = t;

Afaict metadata can still be NULL when you get here.

> +    }
> +
> +    if ( metadata )
> +        unmap_domain_page(metadata);

According to the x86 implementation, passing NULL here ought to be fine,
so no if() needed.

>  }
>  
> -static p2m_type_t p2m_get_type(const pte_t pte)
> +/*
> + * `pte` -> PTE entry that stores the PTE's type.
> + *
> + * If the PTE's type is `p2m_ext_storage`, `ctx` should be provided;
> + * otherwise it could be NULL.
> + */
> +static p2m_type_t p2m_get_type(const pte_t pte, const struct p2m_pte_ctx *ctx)
>  {
>      p2m_type_t type = MASK_EXTR(pte.pte, P2M_TYPE_PTE_BITS_MASK);
>  
>      if ( type == p2m_ext_storage )
> -        panic("unimplemented\n");
> +    {
> +        pte_t *md = __map_domain_page(ctx->pt_page->v.md.metadata);

Pointer-to-const?

> +        type = md[ctx->index].pte;
> +        unmap_domain_page(ctx->pt_page->v.md.metadata);

I'm pretty sure you want to pass md here, not the pointer you passed
into __map_domain_page().

> @@ -381,7 +465,10 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
>      }
>  }
>  
> -static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
> +static pte_t p2m_pte_from_mfn(const mfn_t mfn, const p2m_type_t t,
> +                              struct p2m_pte_ctx *p2m_pte_ctx,
> +                              const bool is_table,

Do you really need both "is_table" and the context pointer? Couldn't
the "is intermediate page table" case be identified by a NULL context
and/or p2m pointer?

Also why "const" all of the sudden?

> @@ -435,22 +527,47 @@ static struct page_info *p2m_alloc_page(struct p2m_domain *p2m)
>      return pg;
>  }
>  
> +static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg);
> +
> +/*
> + * Allocate a page table with an additional extra page to store
> + * metadata for each entry of the page table.

Isn't this stale now? At which point the question is whether ...

> + * Link this metadata page to page table page's list field.
> + */
> +static struct page_info *p2m_alloc_table(struct p2m_domain *p2m)
> +{
> +    struct page_info *page_tbl = p2m_alloc_page(p2m);
> +
> +    if ( !page_tbl )
> +        return NULL;
> +
> +    clear_and_clean_page(page_tbl, p2m->clean_dcache);
> +
> +    return page_tbl;
> +}

... the function is needed in the first place.

> +/*
> + * Free page table's page and metadata page linked to page table's page.
> + */
> +static void p2m_free_table(struct p2m_domain *p2m, struct page_info *tbl_pg)
> +{
> +    ASSERT(tbl_pg->v.md.metadata);

Why, when you no longer unconditionally alloc that page?

> +    if ( tbl_pg->v.md.metadata )
> +        p2m_free_page(p2m, tbl_pg->v.md.metadata);
> +    p2m_free_page(p2m, tbl_pg);
> +}
> +
>  /*
>   * Allocate a new page table page with an extra metadata page and hook it
>   * in via the given entry.
>   */

This comment looks to have been inapplicable already when it was introduced.

>  static int p2m_create_table(struct p2m_domain *p2m, pte_t *entry)
>  {
> -    struct page_info *page;
> +    struct page_info *page = p2m_alloc_table(p2m);
>  
>      ASSERT(!pte_is_valid(*entry));
>  
> -    page = p2m_alloc_page(p2m);
> -    if ( page == NULL )
> -        return -ENOMEM;
> -
> -    clear_and_clean_page(page, p2m->clean_dcache);
> -
>      p2m_write_pte(entry, page_to_p2m_table(page), p2m->clean_dcache);
>  
>      return 0;

As per above I don't think any change is needed here.

> @@ -629,7 +748,7 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
>           * has failed (error case).
>           * So, at worst, the spurious mapcache invalidation might be sent.
>           */
> -        if ( p2m_is_ram(p2m_get_type(p2m, entry)) &&
> +        if ( p2m_is_ram(p2mt) &&
>               domain_has_ioreq_server(p2m->domain) )
>              ioreq_request_mapcache_invalidate(p2m->domain);
>  #endif

This change wants making right in the earlier patch, where "p2mt" is
being introduced.

> @@ -639,9 +758,21 @@ static void p2m_free_subtree(struct p2m_domain *p2m,
>          return;
>      }
>  
> -    table = map_domain_page(pte_get_mfn(entry));
> +    mfn = pte_get_mfn(entry);
> +    ASSERT(mfn_valid(mfn));
> +    table = map_domain_page(mfn);
> +    pg = mfn_to_page(mfn);
> +
>      for ( i = 0; i < P2M_PAGETABLE_ENTRIES(level); i++ )
> -        p2m_free_subtree(p2m, table[i], level - 1);
> +    {
> +        struct p2m_pte_ctx tmp_ctx = {
> +            .pt_page = pg,
> +            .index = i,
> +            .level = level -1

Nit: Missing blank after - . Also it is generally better to end such
initialization with a comma.

> @@ -707,6 +834,22 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
>          pte = *entry;
>          pte_set_mfn(&pte, mfn_add(mfn, i << level_order));
>  
> +        if ( MASK_EXTR(pte.pte, P2M_TYPE_PTE_BITS_MASK) == p2m_ext_storage )
> +        {
> +            struct p2m_pte_ctx p2m_pte_ctx = {
> +                .pt_page = tbl_pg,
> +                .index = offsets[level],
> +            };

Assuming using "level" is correct here (which it looks like it is), ...

> +            p2m_type_t old_type = p2m_get_type(pte, &p2m_pte_ctx);

... can't this move ahead of the loop?

> +            p2m_pte_ctx.pt_page = page;
> +            p2m_pte_ctx.index = i;
> +            p2m_pte_ctx.level = level;

Whereas - doesn't this need to be "next_level"?

> @@ -718,7 +861,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
>       */
>      if ( next_level != target )
>          rv = p2m_split_superpage(p2m, table + offsets[next_level],
> -                                 level - 1, target, offsets);
> +                                 level - 1, target, offsets, page);

And btw (alredy in the earlier patch introducing this code) - why isn't
it "next_level" here, instead of "level - 1" (if already you have that
variable)?

> @@ -812,13 +955,21 @@ static int p2m_set_entry(struct p2m_domain *p2m,
>      {
>          /* We need to split the original page. */
>          pte_t split_pte = *entry;
> +        struct page_info *tbl_pg = virt_to_page(table);

This isn't valid on a pointer obtained from map_domain_page().

> @@ -892,7 +1049,15 @@ static int p2m_set_entry(struct p2m_domain *p2m,
>      if ( pte_is_valid(orig_pte) &&
>           (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
>            (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
> -        p2m_free_subtree(p2m, orig_pte, level);
> +    {
> +        struct p2m_pte_ctx tmp_ctx = {
> +                .pt_page = virt_to_page(table),
> +                .index = offsets[level],
> +                .level = level,

Nit: Indentation is off here.

> @@ -1082,7 +1246,14 @@ static mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>      if ( pte_is_valid(entry) )
>      {
>          if ( t )
> -            *t = p2m_get_type(entry);
> +        {
> +            struct p2m_pte_ctx p2m_pte_ctx = {
> +                .pt_page = virt_to_page(table),
> +                .index = offsets[level],
> +            };
> +
> +            *t = p2m_get_type(entry,&p2m_pte_ctx);

Nit: Blank after comma please.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 22:44:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 22:44:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128087.1468562 (Exim 4.92)
	(envelope-from )
	id 1v0pGL-0002Pp-4E; Mon, 22 Sep 2025 22:44:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128087.1468562; Mon, 22 Sep 2025 22:44: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 1v0pGL-0002Pi-1E; Mon, 22 Sep 2025 22:44:01 +0000
Received: by outflank-mailman (input) for mailman id 1128087;
 Mon, 22 Sep 2025 22:43: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 1v0pGJ-0002PP-QP
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 22:43:59 +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 a04d9818-9805-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 00:43:58 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3ee13baf2e1so3466085f8f.3
 for ; Mon, 22 Sep 2025 15:43:58 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2698018167asm142213415ad.57.2025.09.22.15.43.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 15:43: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: a04d9818-9805-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758581037; x=1759185837; 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=1reynL0NO/WMAk1bmvRUNgObJOg6+q45A/OSLy/lsJg=;
        b=fefJIJOxRtlY9KVgDVJcvJmGrtAwwaFpDV+DtZfQU7N7FLZBQP/RZCsJ62orymzkXx
         ZeGPpmj0th9rQaF4ZpERMnZ2xyB579vc2z+ysvTqmyp4doR3WQkD/m1u5qHwmiy/Agek
         YZTD5PnPVrsFJU+IRhTlhP2z9/WITM6AB8kr3bbFOj3cQneUTIteIbQncTv5KnJ6sW/2
         GwS3Mj6DU9/YimYL195FyFOmGqNdDDFhC7BZjvpM9+enUUMzB3rdWZY3ktxj3n8SyFEx
         gMeNw1f3a39UR7mGY8VTwyXDUBJzqpuKMRTgOUgmwizaScLstZZ7lIQYsTNzodMu3TkT
         M0rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758581037; x=1759185837;
        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=1reynL0NO/WMAk1bmvRUNgObJOg6+q45A/OSLy/lsJg=;
        b=cLmY5wn1JQq/cYko5ug2gekIhMNCH9RqJKCh/F58V4PgDlGOiFJ9KHvpkwIrMzjrs2
         EPzUiT8n1w7B+2Q+UQaIjL3cBnx2etSOce+nHfBycKjJWpea0R3Plj9j+FhlQSJYOTZs
         y8R3ZRYSK2tX6Q+PF8tKbEgz9THQp06KMThu/wvUPDySfmDzubMt9yZeaqYiyyJK8QTo
         CCVh+eTKOkdOnnGzUDA+v6yJyHfjM5eGBDT3a6PKTWnS9YRNpBCVoLqFrnwWwAq3cW7J
         rOxt+qv68DY65CNCs2cj+BUj1KRvz0Brc4Xhg6/OIGQ3uzQ0p1nOXPSsv1Qq4/wTKYFP
         WyJA==
X-Forwarded-Encrypted: i=1; AJvYcCWoNLaoTiHGjXqbqQH6yaq0e/CikFC0M+USjr7tYEt8eKc+MmRdZx0OhK09wmTvoYgskWHUv/5T+5I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfIAnGHr2EE/uVI8fvgRF/+DKuEO+9zZ8KydX9uop/88GoFHZ+
	DoodQuLkII55NGpTQWNMtB8AKkNtzwu/UJic9SAZ//KFxPZMi19JCxxiEsRk83eLSg==
X-Gm-Gg: ASbGnctC5Bl2M+iA/Nt9ZJvuUjRm/9pKkQxCsNvdTYxso/SGcuo7r5pkWjPlb2y/XEg
	mCK4+z1NV8JkoeL6jXCzdQCIMpjp8xLFRFLy49qcaQVrAmk+l1wlrLMq5rZjz5aT3rjEIQkFFzb
	M6kLKVXJzuq3FwrtG4yBgSkRqdfpJuKy88pSY7uc3K7COazfeWz7dYXb7TW1M94LCfzzNqkIRST
	AeympCPCXuJBF1nfSS9MaZThnQ7gU+h3OLyfzA+wEacSNkAyou0kcUYG5B2jRE3K54KVHVXxcXg
	nF4/hzDJQI5MgrBbTv1TgVjppFkMiPvltqfP/B95cdsp2JtenvcJvIzWyAnRZk8JwFGR4G2V6Wo
	YR2AOSScGA/p+0UG1Valnd95VY6+O6Aus
X-Google-Smtp-Source: AGHT+IE9Ex6CZcskMDsvYNsODTnl7gCRLG0NzWVjWyJ1rDEI05ttOlNXgHfr3c5woqNah9qomcYSAw==
X-Received: by 2002:a05:6000:401f:b0:3ee:1296:d9e8 with SMTP id ffacd0b85a97d-405c4c80030mr212021f8f.17.1758581037571;
        Mon, 22 Sep 2025 15:43:57 -0700 (PDT)
Message-ID: 
Date: Tue, 23 Sep 2025 00:43:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/domain: introduce DOMID_ANY
To: dmukhin@xen.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, xen-devel@lists.xenproject.org
References: <20250920174732.1207847-2-dmukhin@ford.com>
  
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.09.2025 23:56, dmukhin@xen.org wrote:
> On Mon, Sep 22, 2025 at 05:23:37PM +0200, Jan Beulich wrote:
>> On 20.09.2025 19:47, dmukhin@xen.org wrote:
>>> From: Denis Mukhin  
>>>
>>> Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
>>> of the code.
>>>
>>> Update all relevant domid_alloc() call sites.
>>>
>>> Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
>>> Signed-off-by: Denis Mukhin 
>>> ---
>>> Changes since v1:
>>> - moved DOMID_ANY from the public header
>>
>> This addresses my comment, but not Andrew's subsequent response, specifically
>> aiming at ...
> 
> AFAIU, toolstack should start using DOMID_ANY instead of 0 in
> XEN_DOMCTL_createdomain.
> 
> I was planning to send a separate patch to address it if that's OK.
> 
>>
>>> --- a/tools/tests/domid/harness.h
>>> +++ b/tools/tests/domid/harness.h
>>> @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
>>>  
>>>  #define DOMID_FIRST_RESERVED            (100)
>>>  #define DOMID_INVALID                   (101)
>>> +#define DOMID_ANY                       DOMID_INVALID
>>
>> ... avoiding the need for any such secondary definitions.
> 
> In the current design, unit test harness.h has to define DOMID_ANY.
> Enabling xen/domain.h to compile for unit test is a separate task, IMO.

That wasn't suggested as an option. The #define wants to move back to
the public header, but be properly guarded there. See the v1 replies
you got.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Sep 22 22:49:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Sep 2025 22:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128102.1468574 (Exim 4.92)
	(envelope-from )
	id 1v0pLC-00035q-MC; Mon, 22 Sep 2025 22:49:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128102.1468574; Mon, 22 Sep 2025 22:49:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0pLC-00035j-I2; Mon, 22 Sep 2025 22:49:02 +0000
Received: by outflank-mailman (input) for mailman id 1128102;
 Mon, 22 Sep 2025 22:49:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v0pLA-00035d-UK
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 22:49:00 +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 538d4158-9806-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 00:48:58 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3f2ae6fadb4so2929125f8f.1
 for ; Mon, 22 Sep 2025 15:48:58 -0700 (PDT)
Received: from [192.168.42.55] ([74.50.221.250])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269800530b7sm144312795ad.18.2025.09.22.15.48.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 22 Sep 2025 15: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: 538d4158-9806-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758581338; x=1759186138; 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=PW1DxOozcSBOC2kGlK4owxTShNLt3wMc0LQR2Roa+jU=;
        b=H0TuYhmJYsagWFl40T9AeepPHUh9NjgF8JVnkNrmpl/WWzkz18JYSceCNBQK9JMJge
         1wupe0mPMGwwVVWiMkya3bDDJGnf0URbuJVHLJbAAwG8hCilsLC10ys23OKCOwS2o/cX
         k6co4Xd1q98g2qMYe29FPjVYJSmiJ1lzNb2zqPkGFvsxDVGmPOtaZtdVJZPDWhMMXKLV
         JAqbCkaywNq6brEFUKlO13X+jL9IKyESAah6e6xiA1OPyNsn8JVT3pOANmJd17AneXfE
         +F6zvzo6K/x89mKjxHUp63ndPX+FXp36eUrWpGB9iG5KU3P5txfKfF9nqoV22mu/Rg0M
         Yt2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758581338; x=1759186138;
        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=PW1DxOozcSBOC2kGlK4owxTShNLt3wMc0LQR2Roa+jU=;
        b=lkKDyHCBVBJjc0W1hwZOl3D3L00mze6b46TZ7307rsFAmpm/AJ9SDyHXP8mtDJ0kYZ
         Vz2ybcwTCJeImF9PR0zDdLV36OLELThQqLzVlr4+MuVKFrzwa3OysPC6y6FKMHnnWc2X
         ZCtLsUcxx522ZTv8c8N7dQzTn3gAE3vB53qGTrFEGW7Jygtty2a1RIrE4DyEc0Wbg1AF
         WO1byNbzVtIkkEPKlfNSZ6oeJ5VSv9WZRR/w3R7vIry52rR5jcRhLyDZdzYJORDmZ1su
         AZZSrCk4u5tOQZfpgZwYaplxYwsQaWPeUWYK6Kjn/BV0ZMQuvfTAx9cxMQ/19K5CLv5J
         QlcQ==
X-Forwarded-Encrypted: i=1; AJvYcCVeyWLM7yj70NORklT6/utBjgozLUEZnU95Dmt26HhmE5YWP3b3/wA/h1Bo20pSkihSfybBJfwQPrw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyp1DygWC6vMuYyfS9lvPSZrrsBDPDeZ3a6TKp7XDds58DcsUJk
	bY5HzgNN7CvWwp3NgFAa4L6ZuemAYhFwOHdZ7W3ZCFoOz9qtY2a5PjLgvgKP8t81EQ==
X-Gm-Gg: ASbGncuWoKcPie9PXqe+ikzSSpN/+WM5e2sB7ZCCU6CrcBcYqrvY8cWm5ubF4GYdUok
	yx+003uC1nQXG+KcF0N6wPGe2YekcWGiWArGkHzYRY7fzBOE0dfkseTWN0Am9jfSN6qd7HNcDBM
	u6Wuson1DHN+rmh0slF8pG/gh/rHueClgZJkgCFgKjdGXAcPFzc+F7cy6RyoYfqbE11gLZls4nk
	9uBSRmH8RK6C1eW2s4XHWQNhk/U6WpQ/UsNy8i4ZMBBn8Vtx2C3WR19/R8vAP94uXRLxVrRWVrZ
	Op7oNWO/0jPglk+SPXZgnCsEx0qQlJYRCDr8aUA1NAtg95Nth5CUhE3gyYKo9hLtj+EMIXmXHYO
	LLCN/JseBMiD+xI3ceVvbFjmYYix4VzzYsnO0H9VZtlI=
X-Google-Smtp-Source: AGHT+IHxLwq8YJ+Le7Qe9XKReLYZdjF5aLLqotGFK4bL8gH1oUqwVAOQBMUnkujQ8eW0af7AUW24zQ==
X-Received: by 2002:a05:6000:2003:b0:3e4:d981:e312 with SMTP id ffacd0b85a97d-405cc70f7eemr264302f8f.62.1758581338257;
        Mon, 22 Sep 2025 15:48:58 -0700 (PDT)
Message-ID: <0e901379-41a0-4fa0-bfbb-3407162437ff@suse.com>
Date: Tue, 23 Sep 2025 00:48:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/22] xen/arch/x86: reserve TXT memory during Slaunch
To: Sergii Dmytruk 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 Ross Philipson ,
 trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
References: 
 <8d5ba2e7a0a8bd05bb9cdb89db3f15b831f7f4f7.1748611041.git.sergii.dmytruk@3mdeb.com>
 <45ed8b90-ce0c-419e-9c7d-2ab58ee539a2@suse.com> 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.09.2025 23:35, Sergii Dmytruk wrote:
> On Thu, Jul 10, 2025 at 03:00:07PM +0200, Jan Beulich wrote:
>> On 30.05.2025 15:17, Sergii Dmytruk wrote:
>>> +void __init txt_reserve_mem_regions(void)
>>> +{
>>> +    int rc;
>>> +    uint64_t sinit_base, sinit_size;
>>> +
>>> +    /* TXT Heap */
>>> +    BUG_ON(txt_heap_base == 0);
>>> +    printk("SLAUNCH: reserving TXT heap (%#lx - %#lx)\n", txt_heap_base,
>>> +           txt_heap_base + txt_heap_size);
>>
>> Please log ranges in a way that makes it unambiguous whether they're exclusive
>> or inclusive (especially at the upper end).
> 
> I'll use start:end notation which I think suggests inclusive bounds.

Please use mathematical notation when logging ranges, i.e. [a,b) or [a,b].

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128120.1468593 (Exim 4.92)
	(envelope-from )
	id 1v0unz-0000qe-Gd; Tue, 23 Sep 2025 04:39:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128120.1468593; Tue, 23 Sep 2025 04: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 1v0unz-0000qX-E2; Tue, 23 Sep 2025 04:39:07 +0000
Received: by outflank-mailman (input) for mailman id 1128120;
 Tue, 23 Sep 2025 04:39: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 1v0uny-0000c8-FO
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:06 +0000
Received: from SJ2PR03CU001.outbound.protection.outlook.com
 (mail-westusazlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c001::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c04f00b-9837-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 06:39:04 +0200 (CEST)
Received: from BYAPR07CA0047.namprd07.prod.outlook.com (2603:10b6:a03:60::24)
 by DS7PR12MB6022.namprd12.prod.outlook.com (2603:10b6:8:86::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.19; Tue, 23 Sep 2025 04:38:58 +0000
Received: from SJ1PEPF000023D9.namprd21.prod.outlook.com
 (2603:10b6:a03:60:cafe::f7) by BYAPR07CA0047.outlook.office365.com
 (2603:10b6:a03:60::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:38:58 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023D9.mail.protection.outlook.com (10.167.244.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:38:57 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:38:55 -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: 3c04f00b-9837-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XAPBZSNR2acgG6nBwl90pC9kJfxulfzebqCFOwTWBprooMzhQY8g/EvGMsT3mMbwCa8IgoGzCw8M4aU/1gxSIH2MnfpySMQVIVgkm9bOXzSRto2fgu72K3L6J5hZ/grkVIF4MHigAbQWjNYrHoZ13YmmfOr+PGiPH7OHrM+OJ1yKt4Oro570VNXW/wvzmKXJaT/Fuwe9i36UEUrJAbZ6vGGcK2VRcqZ0qsSFSUN+MkCac5wMpXpQVlgezhGL29JLhw8CHF7hGW1T/mjgZeAKLj9L3/D1FFYIW7MOt4jvWkryKVTfb3Iqbb7oANDMq9D1py7PHK4B5tPqwwQkFeIcxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QU7mqu+2k15Y3Xtkgnh53PzMeEkvcBNFuqW8rgIayvU=;
 b=T2G5dmcEakVqML0h3RQEmIBSkfSICArv/61xw2BiOokH+9gIcY0W7HsqgLQFYq4sbpinKMMWTjLnr6roF3tIbpuWidvt2vhMXMbgrzyxmtJyE/NZdHl4hW0nv7R7cxV8IA+eTSY2mVUHph1Y59dblwF3twENoLToM9bkat4rKhGn4LShIi/HLrMGXZMZd5TT0vT43/9TcI2ecJua89BxMG97L3l9xGRfzmV2E8CEf+9HfU/J0i+rWQO6qisDI2FgEwfeWydU4Ap4nMu0+EzD8Q4Y2vguYo17fiyG4Qq0yEIaMbc4SiHo+Hjk+SHCSMF8dn1jgQkp+HrmOcDILfARLQ==
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=QU7mqu+2k15Y3Xtkgnh53PzMeEkvcBNFuqW8rgIayvU=;
 b=sndoIAf2Nd6eaUyOpBwXJvONU0XlHI6glJxBPTw07+Vf0oPvJZQBuZ2mXI+pCGubQRE7u4fgEW+d95ncuRpq8Ts71zcIR3wkAo6M3JwgBQ2QmcG9aI/zPMc417nvBBBh3IGNXOiDc8jeOhIvtigx7t1UJUxIK1sUE94Vio89Dok=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v10 1/8] xen/cpufreq: make HW_ALL the only expected value for CPPC mode
Date: Tue, 23 Sep 2025 12:38:19 +0800
Message-ID: <20250923043826.3831957-2-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D9:EE_|DS7PR12MB6022:EE_
X-MS-Office365-Filtering-Correlation-Id: ed1bea35-8364-4f5c-6063-08ddfa5b1c41
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?yu3XZ90LrO/gZWVWoecPO3jhB/ppRYH61JWuS9TF4XUIHJb3wbNSTeZEJCcJ?=
 =?us-ascii?Q?xyUjgq8z+G9Xl67owK+r8riOs70O63TfMAPs3u4bzfgm/jK3mp9Nsu8PWCSq?=
 =?us-ascii?Q?s81Ybtoxl3KxXVsGhuPavqyKz7nEd1PH4G8rHf/eiWrDvFNRk5OxFhRgoHC+?=
 =?us-ascii?Q?e6i4SYzHpifOqJLUSCUAiK2cv1gg8dEx5Q6JA/fQU7hUxZs9tjxEdZ1jVRAo?=
 =?us-ascii?Q?mKrOGJa15HLs1A3bv9sh0nlcGkyW80ezSWcPbUxPZEBOQ+dfacKmLCSC+SvZ?=
 =?us-ascii?Q?HlDL7blu5b+ZKKso7YMaViUvmsjn4rrztr7CZ6VmTbddjLG7ydT15DhdRYu7?=
 =?us-ascii?Q?sXDahVn7V69+GgNZ6JrztLiDImDjWFyCuhv+bw+5h8mZfVp0VFr1q1HmtPsY?=
 =?us-ascii?Q?T5nJQlARj88/bspJPc+AA2Ufd3Xu2blBKyxoW+wKtF3+lkbFttu3WRuoU1x0?=
 =?us-ascii?Q?X5tYnCboyP4cT+QOPgCu/gCye9CzR4fspRNS4Ih77Unqe0rqqsmqLBBJfK7g?=
 =?us-ascii?Q?8jwSVN9g+DhxLxFtMW5iwuyRu5mmmSQ0N0MzHs5agkvI09xtBqP7Qn4EdhMA?=
 =?us-ascii?Q?phHLApEzuxWewR0fk8w2LjfeH8PSurJnP3+jP+X3B4giJ/Hy//+ozpUbKKme?=
 =?us-ascii?Q?f8ndKsGPMQLmjea7d2mdm++F9nh5zz6thvGQqobbxk6UxsY35hNVAVYwTIE4?=
 =?us-ascii?Q?NFOMeEW9Acf4Ns6f9Fo5NG+JWQnxGty62BaQ/Hl7zASePeMI8+L4M1lHiBgJ?=
 =?us-ascii?Q?CMYDFJgy5USlepi8QY4pI/4DX70BvHeu2WuDvDcVrGSqaiCRoOpC+NfuBr8c?=
 =?us-ascii?Q?v/Kf2F2SJhOH+816I1lvMdRKS6BR2iLDRA0vJ3t6NlpDP9n+ydZnoXelLuyV?=
 =?us-ascii?Q?SqzClfAYZYX1RGdN8LHDV58WMIaiKh96WeHfAsndqs15EHO2XiUCd/nc3Hzs?=
 =?us-ascii?Q?in5xBxRTI9ijZfeppfsaGyUJoGVMs5rdkRry7fS2yhQbwvoimNZrXpSjdJ6i?=
 =?us-ascii?Q?KRD6MtlHYCfIGY/QnSBqKDJMVxiVKSwIYlWSdV3+P02k2R758+XLAglzdX7Q?=
 =?us-ascii?Q?iqYf01T1En9f/eYPZNgbCP8+iqpu0kUn+dEJGprAPr3IeK+CrRGI83hwTaw1?=
 =?us-ascii?Q?OMbDREHvc1o5d63R22w7WCs8fcqrZHjOs1whCkCyXFzhuTFT8OiVcHJaAC6+?=
 =?us-ascii?Q?BPkz4YGhmp8889K9sCupaW2wtfLHpdRXECO8qoeVKbY0pWshCsqpD7b7a2cj?=
 =?us-ascii?Q?uIrnQ0kvIxKgmj8W9KG/P/AgdvFaLbzP0eVLEzGSIJUubaAdHIkXgxfriYxB?=
 =?us-ascii?Q?KkSGdVXgc5UvLvrNC/uM0twP0LOLFFylqaDhNnb4aJxq2HcHobEAwqq46Hk/?=
 =?us-ascii?Q?AoS7l7UJMOnSpo+gPgAHEkOONOHsta0YjI9myG2GtkG1sDig7JlTjNmcvtBo?=
 =?us-ascii?Q?vxYp3f5J5JtpcjBVyK9YSjy4W48z0xefLTvX0JiK8xWrSEpu8TlHh7AlG5yQ?=
 =?us-ascii?Q?TCK8qT8jh885i2nj09nD4F/q/adfnGMve8D5?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 23 Sep 2025 04:38:57.8117
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ed1bea35-8364-4f5c-6063-08ddfa5b1c41
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023D9.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6022

Right now, no matter for code construction or hardware restriction, HW_ALL
shall be the only expected values in _PSD for AMD CPPC mode

Suggested-by: Jan Beulich 
Signed-off-by: Penny Zheng 
---
v9 - v10:
- new commit
---
 xen/drivers/cpufreq/cpufreq.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index fe6bd7ff25..4b74f5590b 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -765,6 +765,16 @@ int set_cppc_pminfo(unsigned int acpi_id,
         goto out;
     }
 
+    /* Right now, HW_ALL shall be the only expected value in CPPC mode */
+    if ( cppc_data->shared_type != CPUFREQ_SHARED_TYPE_HW )
+    {
+        ret = -EINVAL;
+        printk_once(XENLOG_ERR
+                    "Unsupported sharing type %u in CPPC mode\n",
+                    cppc_data->shared_type);
+        goto out;
+    }
+
     if ( cppc_data->flags & XEN_CPPC_CPC )
     {
         if ( cppc_data->cpc.highest_perf == 0 ||
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128121.1468603 (Exim 4.92)
	(envelope-from )
	id 1v0uo3-00016m-OU; Tue, 23 Sep 2025 04:39:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128121.1468603; Tue, 23 Sep 2025 04:39: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 1v0uo3-00016b-Ku; Tue, 23 Sep 2025 04:39:11 +0000
Received: by outflank-mailman (input) for mailman id 1128121;
 Tue, 23 Sep 2025 04:39: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 1v0uo2-00015C-10
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:10 +0000
Received: from CO1PR03CU002.outbound.protection.outlook.com
 (mail-westus2azlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c005::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d5b5c5b-9837-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 06:39:07 +0200 (CEST)
Received: from BYAPR07CA0062.namprd07.prod.outlook.com (2603:10b6:a03:60::39)
 by MW4PR12MB7482.namprd12.prod.outlook.com (2603:10b6:303:212::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 04:39:00 +0000
Received: from SJ1PEPF000023D9.namprd21.prod.outlook.com
 (2603:10b6:a03:60:cafe::ee) by BYAPR07CA0062.outlook.office365.com
 (2603:10b6:a03:60::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:39:00 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023D9.mail.protection.outlook.com (10.167.244.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:00 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:38:57 -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: 3d5b5c5b-9837-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=s7a8duobYZUFdA7fbFdU+MacV6ZNdvKE6jYYdcJfbwGY8qhQOapsTtHsERWruewxAm+n24CN0O8STxFQKLomb1PHB4Sund/1Jiu0VC096YpxgS1B544Nod8j6huvBEQ5UtvzsyeLYHe/+N6JCZXXNdrgyrXWwXAcdZX85ysbNChDdzi4j2R5w/ox/Y2rw5Ec+mKqS1thtseQUehybm2hdo/gUvJ3TY7e/jAfvWwum2d5fyzW5ptlQ89eFj/X2Nb52VNhTAFyirxWHzOa9jEoT8jFxLN71rq8nC/tWwtKhlj6eN3imH3c0xomweRTHJ0uBTU9ZKCprTRWhFRS3tmsBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DIpUdet+Q0SAJhQrpt5s0rufEWUnuCkjp1RtSAuMMTc=;
 b=Mi2b3XLk7xQvjdV8nFtvOk7WPRd8wS4Z1edW5FYrQqdybLAL8KHZXZ28Ufxv2H9jAbzDEaRt2yaLpts5Y/QgdfCVAZo9ODK8N3eF8mLmwQ95wNDi6gpFyrJKSiJf/JVP+NQps6D3u9gjSnXhjXcPssllUX4IOE1YnyDyyRR9TMzFYvqaDHK5ZI9Qeg5o5KFU86JFvLT2ECgpnGSXDewzofwyCctZtqavCue6j4HzTGECT+pq0F+VyXiLUlIPNQpRXLip/bpLzgedRfexVGiqSmAKa5B7xyz59hOQPMkOX2Ic4ulLLLczdlY+zSmub1tqglkW3CC9ZPLnar+TI9trZg==
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=DIpUdet+Q0SAJhQrpt5s0rufEWUnuCkjp1RtSAuMMTc=;
 b=RKQ3MZu558F2dqtEVRupQgCDzaQflqscpqDIOKCfwBlXrypRk3VP18chT1kRd0I1VdaGHzSOgNvXNiqQyLcdmsdiHLu2LYc6BVPkXG/weEZxxWBUWPJscEn/RW7Q+bIoRzBVSuWy4WoWw7farTLDXQ4/cnduCGpSX5vQQLJoL7s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v10 2/8] xen/cpufreq: implement amd-cppc driver for CPPC in passive mode
Date: Tue, 23 Sep 2025 12:38:20 +0800
Message-ID: <20250923043826.3831957-3-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D9:EE_|MW4PR12MB7482:EE_
X-MS-Office365-Filtering-Correlation-Id: c9458f07-6954-4402-9f4f-08ddfa5b1dee
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?bHZlRnVCYVlDWCtuVEpKUmVqNi8wR2ZKbG52ZFk4WGhaZktWL2xZRkVOVkNu?=
 =?utf-8?B?QWJlcUF6amd6QU5tRHBLSW5sYnhjRGFjc29lYjdMVDkvUjdNTnE1WHVjQmg4?=
 =?utf-8?B?cy9Edm5qbVIrUGFLb0J3K29aNmJ5WmJCUG9tc2NkNjI2MHFaeDlaWTU1bEpm?=
 =?utf-8?B?U285dGFnUDdZeEcwd2pDOGU3U2pCTHR3SkNuc0F0VzhaV1gwTVZSbG1KeWJS?=
 =?utf-8?B?ZG1FRlE5VitVdHRnVG1Yd01pMEZPVkZqUnJZQXpmeDVJNEQwcnZEdG1ETG8z?=
 =?utf-8?B?Njl2QUVCa3ZJWDluSlNRckNPenlTSE1ON1YxWDFrdm0wOEk5aVJiblJLNWxt?=
 =?utf-8?B?Y0VmQ0ZMSTNwRUo3WVMwNE5wNk1LU0JBL3BlYnlGcEVhY2lXUGdyYS9LMlZv?=
 =?utf-8?B?ZkFoNFJuMm9iZVhDT1A0TDlFR1lsYVR4dmNiYUw0MFlzbGIyRk80TDg2VUZr?=
 =?utf-8?B?OHQxWUM5UU9RWFJ6UExyaGJyMm1pWnB3SW5xd2RuWmsxcllzVnRma0VUVmtX?=
 =?utf-8?B?dXBLZnN4cEQ3Sml6NTNabHk3TU1uTHowdU1Eb252MkhudnpsVS8zMGp4OWow?=
 =?utf-8?B?cVJsZW1henYrVUIvK2FtUjY0bVIwbCs0YW92azVYck41VkNDUXM0S0pEeC9M?=
 =?utf-8?B?WVQ1SWNyUjdhcUR5eVJ5TlE1M1ZybktOVFQ2N1ZyZXZ6Z0NUR3RTakU1TnJU?=
 =?utf-8?B?azhITmF1clFJZzNzcDFPNlNnajMyYW9PZFdrcHVPUzBFaW1kZHZWK0hhRG1Y?=
 =?utf-8?B?UHFVZ3ZRNXRuTnBJVEtaT1V4dDMxV0RkSnNOZmdNUW9BanYwMlROZGo3dmRx?=
 =?utf-8?B?OWNldnJJdEhjN2RmaU5RRFl1VTlZZ05YemdzZngxUURzaGJxRWlRNlBQTjdP?=
 =?utf-8?B?bEFaajRLOTRhb3dWSGFZM2RjaG5rQnFxcmZSYjk5R04rMHN5N2llUnZ6WFNn?=
 =?utf-8?B?K1E0MjNQOU1PMi9vbURjS3gvMHhXTDBKWjZiVkkzcmdqb2lhbXRBSlVhWlF3?=
 =?utf-8?B?MDFwYW9VeUdqZlh4alMwM0tRclliVERVTkRVbkFLQUE5TW1JY0xNTlowTUtz?=
 =?utf-8?B?SjFIbUUwZXBZemsrMklSTStnMGZ0dDc0VEg2cjkyK0ZNODRDckovcmF5MlhD?=
 =?utf-8?B?N2V0T2V6UjYxTWZhYi9CYzFtVFVPR1ZVcnN4dHFVUkxQVHJxNlFyQnJORGJZ?=
 =?utf-8?B?K3dOSVF6UTdCbnNwR21PTFdaRkJqdVhRR2VuanNOeHhYU2xYTlBUNk01M25m?=
 =?utf-8?B?QmdrcEVXRWZZd1I1cHRZK1NjMGZTQk16dXJmb3J3b25MamU2ckN1eFNkWC8r?=
 =?utf-8?B?UlpXUnB1Rk9TR2NITHVYNXUvMkpUcE5KZGdtVWNaTmZwN3NtbFFRaGEyS2cw?=
 =?utf-8?B?L2thUWU0UWptb1F5WStBTHdJYUFQUkpoRk04QnAveTJsMVd2bGxqMFNxazVG?=
 =?utf-8?B?NUpPdWdEOGticzBQb1JaOXMzcG8wUmRtcE5PbWRPKzVkT2o2c1pBOXc2bncy?=
 =?utf-8?B?NUNKRmpEYjhoN01iUUlzRHYzSFRQZFhMNElpS3JydmRHdlJRYzdlZVZ5a2Nx?=
 =?utf-8?B?bmxXM3pwS1QxY1dqTWpMRlhROFl6TUluOXlRVmFSM1RzUmtIQjFQL1djYVlO?=
 =?utf-8?B?SXhxSTJQREdwOG9GUXRWL0pFbnJJMnBGRHR0dEh5a243d0RKdEtQOG01alBi?=
 =?utf-8?B?WEZIQUEvN085NG9NN0lXYVFCVkNqNENpY3hCb2JEcVczMFFrSFZsc2VCQ3U1?=
 =?utf-8?B?ZlZaUFF2dXgxT0gzZVF5d2VtODNONUVVWXRzS3FwUVhIUjVxTmx1SnFyRXY5?=
 =?utf-8?B?ampGS1Y0ZktzOG0vWi9WcnRmU0pXOTNJU0FKYjNqSmQ1a0tQM09ZdUxweVp1?=
 =?utf-8?B?TWF1OWJpSVl5eUh0NDlCK29nVUFlK1VrSmM3WmpYWnlzR0EwSTdhZ0I1b3BD?=
 =?utf-8?B?Q2xsWTdPVEtaK3UwbkpCVXhMeWV4YXlGMXoyL3oxQktKWmZCN2loQmVDQThx?=
 =?utf-8?B?OHZLTnk5Yzk2QTJxc3hlOUFTVHgvc2l6dDNVTzJqQ3c1MzJES2NaTTFIUllY?=
 =?utf-8?Q?bvehB3?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 04:39:00.6277
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c9458f07-6954-4402-9f4f-08ddfa5b1dee
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023D9.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7482

amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism. The new mechanism is based on
Collaborative Processor Performance Control (CPPC) which is a finer grain
frequency management than legacy ACPI hardware P-States.
Current AMD CPU platforms are using the ACPI P-states driver to
manage CPU frequency and clocks with switching only in 3 P-states, while the
new amd-cppc allows a more flexible, low-latency interface for Xen
to directly communicate the performance hints to hardware.

"amd-cppc" driver is responsible for implementing CPPC in passive mode, which
still leverages Xen governors such as *ondemand*, *performance*, etc, to
calculate the performance hints. In the future, we will introduce an advanced
active mode to enable autonomous performence level selection.

Field epp, energy performance preference, which only has meaning when active
mode is enabled and will be introduced later in details, so we read
pre-defined BIOS value for it in passive mode.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v1 -> v2:
- re-construct union caps and req to have anonymous struct instead
- avoid "else" when the earlier if() ends in an unconditional control flow statement
- Add check to avoid chopping off set bits from cast
- make pointers pointer-to-const wherever possible
- remove noisy log
- exclude families before 0x17 before CPPC-feature MSR op
- remove useless variable helpers
- use xvzalloc and XVFREE
- refactor error handling as ENABLE bit can only be cleared by reset
---
v2 -> v3:
- Move all MSR-definations to msr-index.h and follow the required style
- Refactor opening figure braces for struct/union
- Sort overlong lines throughout the series
- Make offset/res int covering underflow scenario
- Error out when amd_max_freq_mhz isn't set
- Introduce amd_get_freq(name) macro to decrease redundancy
- Supported CPU family checked ahead of smp-function
- Nominal freq shall be checked between the [min, max]
- Use APERF/MPREF to calculate current frequency
- Use amd_cppc_cpufreq_cpu_exit() to tidy error path
---
v3 -> v4:
- verbose print shall come with a CPU number
- deal with res <= 0 in amd_cppc_khz_to_perf()
- introduce a single helper amd_get_lowest_or_nominal_freq() to cover both
lowest and nominal scenario
- reduce abuse of wrmsr_safe()/rdmsr_safe() with wrmsrl()/rdmsrl()
- move cf_check from amd_cppc_write_request() to amd_cppc_write_request_msrs()
- add comment to explain why setting non_linear_lowest in passive mode
- add check to ensure perf values in
lowest <= non_linear_lowest <= nominal <= highset
- refactor comment for "data->err != 0" scenario
- use "data->err" instead of -ENODEV
- add U suffixes for all msr macro
---
v4 -> v5:
- all freq-values shall be unsigned int type
- remove shortcuts as it is rarely taken
- checking cpc.nominal_mhz and cpc.lowest_mhz are non-zero values is enough
- drop the explicit type cast
- null pointer check is in no need for internal functions
- change amd_get_lowest_or_nominal_freq() to amd_get_cpc_freq()
- clarifying function-wide that the calculated frequency result is to be in kHz
- use array notation
- with cpu_has_cppc check, no need to do cpu family check
---
v5 -> v6
- replace "AMD_CPPC" with "AMD-CPPC" in message
- add equation(mul,div) non-zero check
- replace -EINVAL with -EOPNOTSUPP
- refactor comment
---
v6 -> v7
- used > in place of !=, to not only serve a doc aspect, but also allow to
drop one part
- unify with UINT8_MAX
- return -ERANGE as we reject perf values of 0 as invalid
- replace uint32_t with unsigned int
- Move some epp introduction here, otherwise we will mis-handle this field here
by always clearing it
---
v7 -> v8:
- refine message text by removing 0
---
v8 -> v9
- embed struct amd_cppc_drv_data{} into struct cpufreq_policy{}
---
v9 - v10
- rewind the changes in v9
---
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 418 ++++++++++++++++++++++++++-
 xen/arch/x86/cpu/amd.c               |   8 +-
 xen/arch/x86/include/asm/amd.h       |   2 +
 xen/arch/x86/include/asm/msr-index.h |   6 +
 xen/include/public/sysctl.h          |   1 +
 5 files changed, 430 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 3377783f7e..5b99b86fb7 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -14,7 +14,98 @@
 #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);  \
+})
+
+/*
+ * Field highest_perf, nominal_perf, lowest_nonlinear_perf, and lowest_perf
+ * contain the values read from CPPC capability MSR. They represent the limits
+ * of managed performance range as well as the dynamic capability, which may
+ * change during processor operation
+ * Field highest_perf represents highest performance, which is the absolute
+ * maximum performance an individual processor may reach, assuming ideal
+ * conditions. This performance level may not be sustainable for long
+ * durations and may only be achievable if other platform components
+ * are in a specific state; for example, it may require other processors be
+ * in an idle state. This would be equivalent to the highest frequencies
+ * supported by the processor.
+ * Field nominal_perf represents maximum sustained performance level of the
+ * processor, assuming ideal operating conditions. All cores/processors are
+ * expected to be able to sustain their nominal performance state
+ * simultaneously.
+ * Field lowest_nonlinear_perf represents Lowest Nonlinear Performance, which
+ * is the lowest performance level at which nonlinear power savings are
+ * achieved. Above this threshold, lower performance levels should be
+ * generally more energy efficient than higher performance levels. So in
+ * traditional terms, this represents the P-state range of performance levels.
+ * Field lowest_perf represents the absolute lowest performance level of the
+ * platform. Selecting it may cause an efficiency penalty but should reduce
+ * the instantaneous power consumption of the processor. So in traditional
+ * terms, this represents the T-state range of performance levels.
+ *
+ * Field max_perf, min_perf, des_perf store the values for CPPC request MSR.
+ * Software passes performance goals through these fields.
+ * Field max_perf conveys the maximum performance level at which the platform
+ * may run. And it may be set to any performance value in the range
+ * [lowest_perf, highest_perf], inclusive.
+ * Field min_perf conveys the minimum performance level at which the platform
+ * may run. And it may be set to any performance value in the range
+ * [lowest_perf, highest_perf], inclusive but must be less than or equal to
+ * max_perf.
+ * Field des_perf conveys performance level Xen governor is requesting. And it
+ * may be set to any performance value in the range [min_perf, max_perf],
+ * inclusive.
+ * Field epp represents energy performance preference, which only has meaning
+ * when active mode is enabled.
+ */
+struct amd_cppc_drv_data
+{
+    const struct xen_processor_cppc *cppc_data;
+    union {
+        uint64_t raw;
+        struct {
+            unsigned int lowest_perf:8;
+            unsigned int lowest_nonlinear_perf:8;
+            unsigned int nominal_perf:8;
+            unsigned int highest_perf:8;
+            unsigned int :32;
+        };
+    } caps;
+    union {
+        uint64_t raw;
+        struct {
+            unsigned int max_perf:8;
+            unsigned int min_perf:8;
+            unsigned int des_perf:8;
+            unsigned int epp:8;
+            unsigned int :32;
+        };
+    } req;
+
+    int err;
+};
+
+static DEFINE_PER_CPU_READ_MOSTLY(struct amd_cppc_drv_data *,
+                                  amd_cppc_drv_data);
+/*
+ * Core max frequency read from PstateDef as anchor point
+ * for freq-to-perf transition
+ */
+static DEFINE_PER_CPU_READ_MOSTLY(unsigned int, pxfreq_mhz);
+static DEFINE_PER_CPU_READ_MOSTLY(uint8_t, epp_init);
 
 static bool __init amd_cppc_handle_option(const char *s, const char *end)
 {
@@ -50,10 +141,335 @@ 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 &&
+         data->caps.nominal_perf > data->caps.lowest_perf &&
+         cppc_data->cpc.nominal_mhz > cppc_data->cpc.lowest_mhz )
+    {
+        mul = data->caps.nominal_perf - data->caps.lowest_perf;
+        div = cppc_data->cpc.nominal_mhz - cppc_data->cpc.lowest_mhz;
+
+        /*
+         * 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 -EOPNOTSUPP;
+    }
+
+    res = offset + (mul * freq) / (div * 1000);
+    if ( res > UINT8_MAX )
+    {
+        printk_once(XENLOG_WARNING
+                    "Perf value exceeds maximum value 255: %d\n", res);
+        *perf = UINT8_MAX;
+        return 0;
+    }
+    if ( res <= 0 )
+    {
+        printk_once(XENLOG_WARNING
+                    "Perf value smaller than minimum value: %d\n", res);
+        return -ERANGE;
+    }
+    *perf = res;
+
+    return 0;
+}
+
+/*
+ * _CPC may define nominal frequecy and lowest frequency, if not, use
+ * Processor Max Speed as anchor point to calculate.
+ * Output freq stores cpc frequency in kHz
+ */
+static int amd_get_cpc_freq(const struct amd_cppc_drv_data *data,
+                            unsigned int cpc_mhz, uint8_t perf,
+                            unsigned int *freq)
+{
+    unsigned int mul, div, res;
+
+    if ( cpc_mhz )
+    {
+        /* Switch to kHz */
+        *freq = cpc_mhz * 1000;
+        return 0;
+    }
+
+    /* Read Processor Max Speed(MHz) as anchor point */
+    mul = this_cpu(pxfreq_mhz);
+    if ( !mul )
+        return -EOPNOTSUPP;
+    div = data->caps.highest_perf;
+    res = (mul * perf * 1000) / div;
+    if ( unlikely(!res) )
+        return -EOPNOTSUPP;
+
+    return 0;
+}
+
+/* Output max_freq stores calculated maximum frequency in kHz */
+static int amd_get_max_freq(const struct amd_cppc_drv_data *data,
+                            unsigned int *max_freq)
+{
+    unsigned int nom_freq = 0;
+    int res;
+
+    res = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
+                           data->caps.nominal_perf, &nom_freq);
+    if ( res )
+        return res;
+
+    *max_freq = (data->caps.highest_perf * nom_freq) / data->caps.nominal_perf;
+
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
+                                 policy->cpuinfo.max_freq);
+
+    return 0;
+}
+
+static void cf_check amd_cppc_write_request_msrs(void *info)
+{
+    const struct amd_cppc_drv_data *data = info;
+
+    wrmsrl(MSR_AMD_CPPC_REQ, data->req.raw);
+}
+
+static void amd_cppc_write_request(unsigned int cpu, uint8_t min_perf,
+                                   uint8_t des_perf, uint8_t max_perf,
+                                   uint8_t epp)
+{
+    struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
+    uint64_t prev = data->req.raw;
+
+    data->req.min_perf = min_perf;
+    data->req.max_perf = max_perf;
+    data->req.des_perf = des_perf;
+    data->req.epp = epp;
+
+    if ( prev == data->req.raw )
+        return;
+
+    on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs, data, 1);
+}
+
+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;
+
+    /*
+     * Having a performance level lower than the lowest nonlinear
+     * performance level, such as, lowest_perf <= perf <= lowest_nonliner_perf,
+     * may actually cause an efficiency penalty, So when deciding the min_perf
+     * value, we prefer lowest nonlinear performance over lowest performance.
+     */
+    amd_cppc_write_request(policy->cpu, data->caps.lowest_nonlinear_perf,
+                           des_perf, data->caps.highest_perf,
+                           /* Pre-defined BIOS value for passive mode */
+                           per_cpu(epp_init, policy->cpu));
+    return 0;
+}
+
+static void cf_check amd_cppc_init_msrs(void *info)
+{
+    struct cpufreq_policy *policy = info;
+    struct amd_cppc_drv_data *data = this_cpu(amd_cppc_drv_data);
+    uint64_t val;
+    unsigned int min_freq = 0, nominal_freq = 0, max_freq;
+
+    /* Package level MSR */
+    rdmsrl(MSR_AMD_CPPC_ENABLE, val);
+    /*
+     * Only when Enable bit is on, the hardware will calculate the processor’s
+     * performance capabilities and initialize the performance level fields in
+     * the CPPC capability registers.
+     */
+    if ( !(val & AMD_CPPC_ENABLE) )
+    {
+        val |= AMD_CPPC_ENABLE;
+        wrmsrl(MSR_AMD_CPPC_ENABLE, val);
+    }
+
+    rdmsrl(MSR_AMD_CPPC_CAP1, data->caps.raw);
+
+    if ( data->caps.highest_perf == 0 || data->caps.lowest_perf == 0 ||
+         data->caps.nominal_perf == 0 || data->caps.lowest_nonlinear_perf == 0 ||
+         data->caps.lowest_perf > data->caps.lowest_nonlinear_perf ||
+         data->caps.lowest_nonlinear_perf > data->caps.nominal_perf ||
+         data->caps.nominal_perf > data->caps.highest_perf )
+    {
+        amd_cppc_err(policy->cpu,
+                     "Out of range values: highest(%u), lowest(%u), nominal(%u), lowest_nonlinear(%u)\n",
+                     data->caps.highest_perf, data->caps.lowest_perf,
+                     data->caps.nominal_perf, data->caps.lowest_nonlinear_perf);
+        goto err;
+    }
+
+    amd_process_freq(&cpu_data[policy->cpu],
+                     NULL, NULL, &this_cpu(pxfreq_mhz));
+
+    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.lowest_mhz,
+                                 data->caps.lowest_perf, &min_freq);
+    if ( data->err )
+        return;
+
+    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
+                                 data->caps.nominal_perf, &nominal_freq);
+    if ( data->err )
+        return;
+
+    data->err = amd_get_max_freq(data, &max_freq);
+    if ( data->err )
+        return;
+
+    if ( min_freq > nominal_freq || nominal_freq > max_freq )
+    {
+        amd_cppc_err(policy->cpu,
+                     "min(%u), or max(%u), or nominal(%u) freq value is incorrect\n",
+                     min_freq, max_freq, nominal_freq);
+        goto err;
+    }
+
+    policy->min = min_freq;
+    policy->max = max_freq;
+
+    policy->cpuinfo.min_freq = min_freq;
+    policy->cpuinfo.max_freq = max_freq;
+    policy->cpuinfo.perf_freq = nominal_freq;
+    /*
+     * Set after policy->cpuinfo.perf_freq, as we are taking
+     * APERF/MPERF average frequency as current frequency.
+     */
+    policy->cur = cpufreq_driver_getavg(policy->cpu, GOV_GETAVG);
+
+    /* Store pre-defined BIOS value for passive mode */
+    rdmsrl(MSR_AMD_CPPC_REQ, val);
+    this_cpu(epp_init) = MASK_EXTR(val, AMD_CPPC_EPP_MASK);
+
+    return;
+
+ err:
+    /*
+     * No fallback shceme is available here, see more explanation at call
+     * site in amd_cppc_cpufreq_cpu_init().
+     */
+    data->err = -EINVAL;
+}
+
+/*
+ * AMD CPPC driver is different than legacy ACPI hardware P-State,
+ * which has a finer grain frequency range between the highest and lowest
+ * frequency. And boost frequency is actually the frequency which is mapped on
+ * highest performance ratio. The legacy P0 frequency is actually mapped on
+ * nominal performance ratio.
+ */
+static void amd_cppc_boost_init(struct cpufreq_policy *policy,
+                                const struct amd_cppc_drv_data *data)
+{
+    if ( data->caps.highest_perf <= data->caps.nominal_perf )
+        return;
+
+    policy->turbo = CPUFREQ_TURBO_ENABLED;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    XVFREE(per_cpu(amd_cppc_drv_data, policy->cpu));
+
+    return 0;
+}
+
+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 is taken effective, not only amd-cppc cpufreq core fails
+     * 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 core in CPPC mode\n");
+        amd_cppc_cpufreq_cpu_exit(policy);
+        return data->err;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    amd_cppc_boost_init(policy, data);
+
+    amd_cppc_verbose(policy->cpu,
+                     "CPU initialized with amd-cppc passive mode\n");
+
+    return 0;
+}
+
+static const struct cpufreq_driver __initconst_cf_clobber
+amd_cppc_cpufreq_driver =
+{
+    .name   = XEN_AMD_CPPC_DRIVER_NAME,
+    .verify = amd_cppc_cpufreq_verify,
+    .target = amd_cppc_cpufreq_target,
+    .init   = amd_cppc_cpufreq_cpu_init,
+    .exit   = amd_cppc_cpufreq_cpu_exit,
+};
+
 int __init amd_cppc_register_driver(void)
 {
     if ( !cpu_has_cppc )
         return -ENODEV;
 
-    return -EOPNOTSUPP;
+    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);
 }
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 567b992a9f..9767f63539 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -613,10 +613,10 @@ static unsigned int attr_const amd_parse_freq(unsigned int family,
 	return freq;
 }
 
-static void amd_process_freq(const struct cpuinfo_x86 *c,
-			     unsigned int *low_mhz,
-			     unsigned int *nom_mhz,
-			     unsigned int *hi_mhz)
+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;
diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index 9c9599a622..72df42a6f6 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -173,5 +173,7 @@ extern bool amd_virt_spec_ctrl;
 bool amd_setup_legacy_ssbd(void);
 void amd_set_legacy_ssbd(bool enable);
 void amd_set_cpuid_user_dis(bool enable);
+void amd_process_freq(const struct cpuinfo_x86 *c, unsigned int *low_mhz,
+                      unsigned int *nom_mhz, unsigned int *hi_mhz);
 
 #endif /* __AMD_H__ */
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index bb48d16f0c..df52587c85 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -252,6 +252,12 @@
 
 #define MSR_AMD_CSTATE_CFG                  0xc0010296U
 
+#define MSR_AMD_CPPC_CAP1                   0xc00102b0U
+#define MSR_AMD_CPPC_ENABLE                 0xc00102b1U
+#define  AMD_CPPC_ENABLE                    (_AC(1, ULL) << 0)
+#define MSR_AMD_CPPC_REQ                    0xc00102b3U
+#define  AMD_CPPC_EPP_MASK                  (_AC(0xff, ULL) << 24)
+
 /*
  * Legacy MSR constants in need of cleanup.  No new MSRs below this comment.
  */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index aafa7fcf2b..aa29a5401c 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -453,6 +453,7 @@ struct xen_set_cppc_para {
     uint32_t activity_window;
 };
 
+#define XEN_AMD_CPPC_DRIVER_NAME "amd-cppc"
 #define XEN_HWP_DRIVER_NAME "hwp"
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128119.1468583 (Exim 4.92)
	(envelope-from )
	id 1v0unt-0000cX-6e; Tue, 23 Sep 2025 04:39:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128119.1468583; Tue, 23 Sep 2025 04:39: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 1v0unt-0000cE-1I; Tue, 23 Sep 2025 04:39:01 +0000
Received: by outflank-mailman (input) for mailman id 1128119;
 Tue, 23 Sep 2025 04: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 1v0unr-0000c8-Ji
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:38:59 +0000
Received: from CH4PR04CU002.outbound.protection.outlook.com
 (mail-northcentralusazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c105::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36ac2dbf-9837-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 06:38:55 +0200 (CEST)
Received: from BYAPR08CA0013.namprd08.prod.outlook.com (2603:10b6:a03:100::26)
 by SJ2PR12MB9164.namprd12.prod.outlook.com (2603:10b6:a03:556::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 04:38:51 +0000
Received: from SJ1PEPF000023D7.namprd21.prod.outlook.com
 (2603:10b6:a03:100:cafe::63) by BYAPR08CA0013.outlook.office365.com
 (2603:10b6:a03:100::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:38:51 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023D7.mail.protection.outlook.com (10.167.244.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:38:50 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:38:44 -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: 36ac2dbf-9837-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TWSv2VIFYL+JwV777NKB+Bf+CPU1RvTX+h2qfOZ8LGZFohVdSfIA7fpwF7EN2UhmBtGgYb1SJpaghwncmeE+J66/Tenmeb/uT4i4LliojhCTexIkp8I3RFZQKunHet92eldQU3T+ODlw9z+PuZP/kl7wIBNEIGXMW7cQX7IuubBmMWPDoFm8cNLjSrNOJbFwitMIFB0sE1fr45adgZfEEpeIUNrK4yUO715oEo1VlvlViAwsi1Xul8ZXUs+56kLTsPbWbe7SoZvpo4QstzyvjAYMB6tlBwf197G9UtpWDnHUFw8h/92T0EFEU3zkb/E/sm39LcPn7BgDMjAp84A37w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aDKT571nNE3HEQZoCkNhftzvp3C5GIsHOtJv3Ch4T1Y=;
 b=bH6wmWbVSEjnjST0A2P0woQXTVoRs9z+4XPQb6imnlhe3Jq4u9wny0czgySLvvuLmCl0Lckn8DZvKeCS1t79n6RmPZpbBHg1S7hjp1yyPWmhYHaCFFrcWv4UcLxdjxmRWu935s5x7LiHOWk59/o1j3V/fIDUccLTxvxa8APZtl0AQqGyJXgojwsmVck0idwzdRTkrB/C4xE+07P78pheGDMgroEyO1nsD/cy+Gr+n7waPYOxMKa2Sna8aqp0ADpKrwjcwgznDZ66e9WLg5DT4jWBV0vdMzBGJUUjv4plz3e4Rt6GgqfdzjNA2nB9JDJvyIIl+kzVytqaQYesSPh1uw==
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=aDKT571nNE3HEQZoCkNhftzvp3C5GIsHOtJv3Ch4T1Y=;
 b=KqslLfArqr6wlzfe3wdV3RatUiarYhEkNitisyL1FMYMlbl6v6IWO8cDUlKcxhl9hLVtfOkOmnM3t+48cia9JwrBj2xb95x8OArouVNzHjyp5/n5ivZT08SO5ju2jbizywEd1gGwaGi4Phhdt3IMjlNwhw7PM/8qe2J/UAQJCwY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 ,
	"Juergen Gross" , Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v10 0/8] amd-cppc CPU Performance Scaling Driver
Date: Tue, 23 Sep 2025 12:38:18 +0800
Message-ID: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D7:EE_|SJ2PR12MB9164:EE_
X-MS-Office365-Filtering-Correlation-Id: 47bc600d-4ae5-451f-28b3-08ddfa5b17c6
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:
	=?us-ascii?Q?LoMEO/x1FBCOjlQrVoxV7smF3WoQAQWnyqPk6mXZ4edQCR7r4qojC9IpOPd2?=
 =?us-ascii?Q?ZxvKt8HLLpe/F8rDyd+b9eiuPASOVSB8hwqAmdNj7XUBQDDVyA03hQVtyoL/?=
 =?us-ascii?Q?U+bMm+DvPzlvq5QNjPgX8UIzwc2GYqOW16049VwonbXKJucEgCh7VRrr0y0P?=
 =?us-ascii?Q?LjsWrSSCTeA2eiVu9h9tKFzpZS89WgHyvmeV4K2+C1cubbsQLH1yIy2M9Izp?=
 =?us-ascii?Q?tLA1uPNRWVuxJNe6yMAX1RHr0Sj2CYgGI0hXUKVFZ6KAig46vGyXA7/MoMOH?=
 =?us-ascii?Q?6523TY9+63m5Zw6timOSEzrZdtyK0TFFhit9/7mIycKIxSZCu3EgFH9pgH7w?=
 =?us-ascii?Q?Scutngn2VGkVXBuLxlrSlfujGHmyGuHJDdIjio9maTHA4elQga/tOuHIA+3c?=
 =?us-ascii?Q?MdjPLIOYgUobMlKv4SDLNCoiJTw6Ol4P1X0r1mEa7WzIoXorKM7yWARbbOYZ?=
 =?us-ascii?Q?3UEKX8osCdTDi7TZ8+wckIB3br1mO5na3DbyXmi1zMWPwTTr6SXaIWpPntyB?=
 =?us-ascii?Q?+cyl0+gVruO43A84jzKdhP7m59EeZg/MGURS357Cx+TUf47uNz6ZylazNuf4?=
 =?us-ascii?Q?Qpxun4ChIbOkq6W6bkD5uAc46Hx42GzldxoM0L6zrpUSPjYuTEwDcrn2gIRc?=
 =?us-ascii?Q?ALvYBCUZQZwMMDr0CeP+hGqYP8hvoyTAyHb5hSfLmbf9sFH12TsbLf95Mnwd?=
 =?us-ascii?Q?FBWgxm/OVOjhKraXqsXL8SD7OgGQ5ag+/x40th9oYYfS9JDSjNXd8TECyJH5?=
 =?us-ascii?Q?QPyRuzew1zuGNRZviq5A89ycuYiCearenZVfyG+v9rZ/boR2PUZ/dP8VolYf?=
 =?us-ascii?Q?FzXCv6lFfwnynByNXm2ydt24iuMnypVo/gToU4eUMZgPM63mfZ+/qotsKrF8?=
 =?us-ascii?Q?QJcnRWaJLiwA14pYjnBtUIFqAwBRk2zJr08ftxui8KOrE3lxMurLg/Hh5FXc?=
 =?us-ascii?Q?lDI0GF41tVxtfr8e6bQaSqoEGCpuxLXDx732GhHHpPC1JZYZ3MW+0e8Tkj27?=
 =?us-ascii?Q?RfijC3z/4USiyLWzniQYBFCBxe9F6ANTBNZ77N2zSexK5jCKEqcsHqo6327L?=
 =?us-ascii?Q?22pDBl2QlG5oACh++q46Hd0uQ1ScYehkMtGNSxP9729uzZO5iY8FnMDOJI6M?=
 =?us-ascii?Q?VwdXVBmmcIErOyUVQ1GeVa7abvWANxZkiL4QvfiUEfiozgPgYH9iLpZG9Rnd?=
 =?us-ascii?Q?LjO8k6dwMZ2gMStOJTgbIFhm+7t3Pzcw+86I2ysyORkwIK7+ZA8WegqmwrVd?=
 =?us-ascii?Q?SJ3/wE5M+FvzRf77p7Ygu5rSF5kL8F9YsTFuyswXvP4QatoRxbFgER699YSk?=
 =?us-ascii?Q?Z56o23OZ751hUjUdOacOP514oDD0869/Pubt96Mhki+uqjaMk+nN/dzdWHfB?=
 =?us-ascii?Q?f33FEG+0n5tFfNWgyiVjlNCG8MDhvyAnojFoR8d+IYHPBcZvEZgjEQcVVr03?=
 =?us-ascii?Q?MPqj29XMZI8Vr//s9Ax29ZmYchvlnGRoG6WVskIC7RUVMEQUabPQeLt7Gl4G?=
 =?us-ascii?Q?ZuaX5IpkFQ9p/ooQL5NMeRLksbeaeC4xm6Ho?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 04:38:50.2967
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 47bc600d-4ae5-451f-28b3-08ddfa5b17c6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023D7.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9164

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 (8):
  xen/cpufreq: make HW_ALL the only expected value for CPPC mode
  xen/cpufreq: implement amd-cppc driver for CPPC in passive mode
  xen/cpufreq: implement amd-cppc-epp driver for CPPC in active mode
  xen/cpufreq: get performance policy from governor set via xenpm
  tools/cpufreq: extract CPPC para from cpufreq para
  xen/cpufreq: bypass governor-related para for amd-cppc-epp
  xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc
    driver
  CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq driver support

 CHANGELOG.md                         |   1 +
 docs/misc/xen-command-line.pandoc    |   9 +-
 tools/include/xenctrl.h              |  27 +-
 tools/libs/ctrl/xc_pm.c              |  47 +-
 tools/misc/xenpm.c                   | 118 +++--
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 709 ++++++++++++++++++++++++++-
 xen/arch/x86/cpu/amd.c               |   8 +-
 xen/arch/x86/include/asm/amd.h       |   2 +
 xen/arch/x86/include/asm/msr-index.h |   6 +
 xen/drivers/acpi/pm-op.c             |  78 ++-
 xen/drivers/cpufreq/cpufreq.c        |  10 +
 xen/drivers/cpufreq/utility.c        |  15 +
 xen/include/acpi/cpufreq/cpufreq.h   |  34 ++
 xen/include/public/sysctl.h          |  33 +-
 14 files changed, 985 insertions(+), 112 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128124.1468613 (Exim 4.92)
	(envelope-from )
	id 1v0uo7-0001PR-6n; Tue, 23 Sep 2025 04:39:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128124.1468613; Tue, 23 Sep 2025 04: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 1v0uo7-0001PI-47; Tue, 23 Sep 2025 04:39:15 +0000
Received: by outflank-mailman (input) for mailman id 1128124;
 Tue, 23 Sep 2025 04: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 1v0uo6-0000c8-Ih
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:14 +0000
Received: from BN1PR04CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c110::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 40c41230-9837-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 06:39:12 +0200 (CEST)
Received: from SJ0PR03CA0366.namprd03.prod.outlook.com (2603:10b6:a03:3a1::11)
 by MN0PR12MB5930.namprd12.prod.outlook.com (2603:10b6:208:37d::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 04:39:07 +0000
Received: from SJ1PEPF000023DA.namprd21.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::8) by SJ0PR03CA0366.outlook.office365.com
 (2603:10b6:a03:3a1::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:39:07 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023DA.mail.protection.outlook.com (10.167.244.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:07 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:39:03 -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: 40c41230-9837-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lNcZiBw+6a7X0e+90Q098D1T7AC4Sn/x6OENPZrNj189KVKYeNn679bNHXKccFaTeHR2qWfkwWYSUBWqXu+9Z1DTGrm2QtSCgqaax0c5aHhO1G6FJah1d0YZxdXqk5JTZ26IUnSALmLnwfI2gHZCEp6odnWqwHcHTHGffa/1017zIifi4c0LJhpIpoFbGKj4gGh+c3F4QFAVAMHN5svZu3Gb2wgEpkPrmbzuRflcnvyo1eCtLBFKJRt7UtHTxId6C8ShBoCvytrzOpNkCgqWHq3PBrVj9P+jpPATKv7G3BdOg88d1q9VLZDgETtmr8VBUnrRU6xCCQWWDREd6rxqzQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wwwi0tW4Ht3ef4KEnk99tP23MKB3LmcikYL/tmBwt+Y=;
 b=Q4BIAofmkcH1u4DWo1V8b65FUYai57bK/apOoWKrCHwJExH+PT5cOTEC2fWVMTfdZuh7D9mxSyOkyvhArF4w+8Zj+rfLTDat53GTcJGnFsxaziE3+o6qgo8XlxsBImjmbUm8Dvm49C8M+lB5PDABn/1SCVlivEwX4s2gKAJX4OGpDZSvcALpnYD3ToSTM6FYBuM2G+EsCnth9AC2s0pOsv8HsTszRNRQrz85g3EKWSXerKTtb+cb3zy7GD6KTD5eyRrLkBnj+mAN5qcT0aNwNTnSCZ7dhODJN+6ZcaiFJAQeNozn3KEjWdXMVU12WYbj/nmV/kHkrVtAAV8HeIQ41g==
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=wwwi0tW4Ht3ef4KEnk99tP23MKB3LmcikYL/tmBwt+Y=;
 b=4Ne/DI70kOuyNFcw2xMm4e3P7XvJgUk9c+wyd/dodFmCnn3lm0SvjHc+6P5eurIVWQzlieL1UcyLpVul+PGkbCokwQITIn2gESHyDMK3lzRgfU/WaGqtv3DWfRUeKkXxdPhyApNqj6yg6NaA2TQlwPCS6B7n4uaFnct2DzlwqqI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v10 4/8] xen/cpufreq: get performance policy from governor set via xenpm
Date: Tue, 23 Sep 2025 12:38:22 +0800
Message-ID: <20250923043826.3831957-5-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023DA:EE_|MN0PR12MB5930:EE_
X-MS-Office365-Filtering-Correlation-Id: d030d804-fb50-43a2-be77-08ddfa5b21bb
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?Mr4IqOx7R4bTUc0P4gRQ0/T+6G1WbwMCdYSblIRoSaNw40bBTRL52+Rrgh9l?=
 =?us-ascii?Q?0Ocm88aZHVLG0NcOn/BGKPENP9akON2cttuW5hBC9+eqT26TLdt1VEJ9VQoM?=
 =?us-ascii?Q?zFmYnJQY/X1Uyu3C71+GuV0+51bsbQF64egterYgnySa9kO2CKWGN9H42i0B?=
 =?us-ascii?Q?cDDRRbHWwNPNYAWj7aapMHGdSaKckzJelhGErZ8s5ZXrqJzdeo5UaQz84ksl?=
 =?us-ascii?Q?b7dsU5l5zFAgIzwXGlk9YiA+3CmwEEBXuYqHmymQ+8T7e95hZWn0UGxauuH9?=
 =?us-ascii?Q?xuOtd20XDRQjR8SpApi848dDzdc2hiWw5r0TjaqElNYbyZcXADlZ8YSb5hGT?=
 =?us-ascii?Q?PsBdGn4k4KUuPyHvKcZPL3/7PP1+LotAs4oS0n85rTvBbYRA8bTCXEDyORYc?=
 =?us-ascii?Q?8F5WRfVB/fvwLDR1Ny0LHpvWPNr/nPHUozJbB5ziz7Q2Z2O7WyH/wgzw1IIh?=
 =?us-ascii?Q?s/PhJhG8AaGDsBNV1gGwv486ybjJjevpNX4ZPmoipV4dChCVcr5Fj85nP4h7?=
 =?us-ascii?Q?Yj9fvd/dJEfw9RIo8Qv9hCwClwIOnUyErUVDSJGwDqD9jJ3r5DXkyWE+PDv1?=
 =?us-ascii?Q?j1eOLDMA+4/KLLZ7MesBtaj0SEKafXLPz65kt1a15ucKPwebMRXhqOLo2NHb?=
 =?us-ascii?Q?fK7uh5/Vq1avdY+sgU01nsJgWHmr3oiPR/Uq3bQ25OxkV7fnTLDIlIxCHmyw?=
 =?us-ascii?Q?0WyUjiqk0+4iJFuHg0z0JmuMKWkv7Zra7UYNQwa1xaggQJLs1xnb1lrHDA2A?=
 =?us-ascii?Q?R9C74qvVSK0qHaZfKe0XwpTFY1kMcKZdsySK3s5F5N0Cj0oJ3uazsamTZn0J?=
 =?us-ascii?Q?yz6xx4l8aQySEFpLFeZzC+c2SDC8GMti99MtXdFJtrBsILcIpFGHM0gfEDav?=
 =?us-ascii?Q?aq9xTi9402xyXAu0TCwvLw7C/TTlE2ozvM1yPh+I5w46if8ibRmjeVfMlkFx?=
 =?us-ascii?Q?Vtgk7V+QuLEcoiNyVWnMsxCgG3v15LvelONfN4bgWuV020hp5NDua+VrqiRl?=
 =?us-ascii?Q?68oCFuA9MY5aBk1YXQfTHx1uERKHb/lALeUpcw65tRigIrp4pppMt2jcBwxt?=
 =?us-ascii?Q?MCk16Krjzvzf9fWho8kIvfHwSRPBoWC7WtgkvFkysvlBRDfiWNsfjVwv8u7B?=
 =?us-ascii?Q?X9e6idZYH4iqfWnshiWMA5r+QvMw0taeAaIjtJs6PHCSN8NRxwWj+IdOEeMa?=
 =?us-ascii?Q?fn+ZA3sc3IBXvWUCKlY2TElVPoj5fP8kwTsJZbGUyf33RiETvwKv026ZKoFU?=
 =?us-ascii?Q?MHcGE7Bmnw2BOGG8kGGDFKdzfQ4SQUTnpB6c8FPvHArme5DUaK/IktxjSM7O?=
 =?us-ascii?Q?Igk/7Pbdgi5pCYSCnmtXqG+S8n6YAFkh4qsgccg83KGeEmrhXtmrAm+PxBNp?=
 =?us-ascii?Q?9a8fRk0K/TUopyyfz59RPJQpJgQ7X62qIuypm+iusqrFh+233pDFDIBeSMNb?=
 =?us-ascii?Q?/ApdWi2mCTwcEk07A5U0Y1Yx37O273xEFA+bSpABSoOs3bG1vmrPcgwxbnYL?=
 =?us-ascii?Q?wF7glNK8uTFR/l6ej0tmxLcnWvuAMrv+TF6R?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 23 Sep 2025 04:39:07.0050
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d030d804-fb50-43a2-be77-08ddfa5b21bb
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5930

Even if Xen governor is not used in amd-cppc active mode, we could
somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
apply through which governor they choose, such as:
If user chooses performance governor, they want maximum performance, then
the policy shall be CPUFREQ_POLICY_PERFORMANCE
If user chooses powersave governor, they want the least power consumption,
then the policy shall be CPUFREQ_POLICY_POWERSAVE
Function cpufreq_policy_from_governor() is responsible for above transition,
and it shall be also effective when users setting new governor through xenpm.

Userspace is a forbidden choice, and if users specify such option, we shall
not only give warning message to suggest using "xenpm set-cpufreq-cppc", but
also error out.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v4 -> v5:
- new commit
---
v5 -> v6:
- refactor warning message
---
v6 -> v7:
- move policy->policy set where it firstly gets introduced
- refactor commit message
---
v7 -> v8:
- policy transition is only limited in CPPC mode
---
 xen/drivers/acpi/pm-op.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index 2f516e62b1..a7eaf29c31 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -207,6 +207,17 @@ static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
     if ( new_policy.governor == NULL )
         return -EINVAL;
 
+    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+    {
+        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, Try \"xenpm set-cpufreq-cppc\"\n",
+                   new_policy.governor->name);
+            return -EINVAL;
+        }
+    }
+
     return __cpufreq_set_policy(old_policy, &new_policy);
 }
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128126.1468623 (Exim 4.92)
	(envelope-from )
	id 1v0uo8-0001ec-Hi; Tue, 23 Sep 2025 04:39:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128126.1468623; Tue, 23 Sep 2025 04:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0uo8-0001eT-E0; Tue, 23 Sep 2025 04:39:16 +0000
Received: by outflank-mailman (input) for mailman id 1128126;
 Tue, 23 Sep 2025 04: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 1v0uo6-0000c8-PZ
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:14 +0000
Received: from PH0PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c107::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4004859e-9837-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 06:39:12 +0200 (CEST)
Received: from SJ0PR03CA0389.namprd03.prod.outlook.com (2603:10b6:a03:3a1::34)
 by DM4PR12MB8500.namprd12.prod.outlook.com (2603:10b6:8:190::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 04:39:05 +0000
Received: from SJ1PEPF000023DA.namprd21.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::28) by SJ0PR03CA0389.outlook.office365.com
 (2603:10b6:a03:3a1::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:39:04 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023DA.mail.protection.outlook.com (10.167.244.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:03 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:39:00 -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: 4004859e-9837-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EKo8CVsnEy3gHR4qTB+ORmJ6JXsYkSmmQyuG+TZm8CItzYqsuwItbvamRtTbWp1I3ownp4Y8UuahdmSkd/pC2BiechHZGp21gzUEc4o1xM5wenvo2ziypI1Lt/ndPYOltIIqcf1WGThtuCWxBVABaAlUgqLrVHj5kdRdh0bxd2/lMVdKdm13aKRmTbg2pKaB+VP7ZMAyVLCmHrE0U2OIjYx4bdJsHFy34cIoe7IPD7blvaACNRTNdavkf4nOLN9XA+q9bF+vnH6Yx6wwI1cNdZg4v6+pbV9cpBlUGCpsJuGnbrXxfslMNFGSXKU6u75DfVVFlIjfShwy2bbdDkMm4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7ZfiAaMkEHd2Z9flw600hOdC8SYeEwbly8Qvsy0m8Ng=;
 b=Bw9roqnx1v5af7HNHp1CHON9ld52ekuaCDmVlKSz/MiiKli1U0o/GgHnfJEkG8MoDsQAJjXvBPpaCHbCmyZm+qF04sGthSLdEx5B4s2ULXmPGBHVikfC2LWs5pBdou+HXS5mZ0AoUCyUWMij0QSg8atbV2+1Lv0EQXDXXu1aCzBpPgJGOsWY5fJJtGbRSuoQLRe8AGLKfLDIydoUOCq+MHnDtawi8ns/S+j0SQIHA9SbSPMkj1rhiQ0niRSfuibdyIopmagEN9DVxddbuHYHP12pBmp3vX3XWeClIRl/UrrCnR66qY9Cfkta3I6cwtDNZY/ZTAStzY38Ut26yVGZCA==
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=7ZfiAaMkEHd2Z9flw600hOdC8SYeEwbly8Qvsy0m8Ng=;
 b=PZFGSiDJr0S4mbWVhpJsxk+sw7JqvmipMn97iyDZOOuk4PPF+6gLvMemWuOXzsWJ9DpTi8xmIC5XAQL/lPzNrzwhZLItvDkk3qDJkQNkx+wSvkXCmL0mvyFAtvUpx9wyb7Bfnlhmq7DPlddhn9H/1Y7f7U9nH8u0CeSFmhi4Tf8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: 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 v10 3/8] xen/cpufreq: implement amd-cppc-epp driver for CPPC in active mode
Date: Tue, 23 Sep 2025 12:38:21 +0800
Message-ID: <20250923043826.3831957-4-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023DA:EE_|DM4PR12MB8500:EE_
X-MS-Office365-Filtering-Correlation-Id: 71bff5e0-f9fa-4654-f0b2-08ddfa5b1fd8
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?RWDFmyP6gm2G9BarSqUnYIrOvrrIlsvyjcyY2XnHfTGVjSys1HCy8zt7/mC4?=
 =?us-ascii?Q?m205iF+HCKmoqUJJicSDPMev6MegCrIO6A2c1yvKcXvi2daSlxXqTzBNVn5H?=
 =?us-ascii?Q?SW1CPTZ09cKFsZm8SPkdAFWA3idEwHtXj6kNAk+lv+WuI+zoYA4cixieilF8?=
 =?us-ascii?Q?JUIml/ZKgkuAlHs8F38m6UZDetjd6/298k0eifFXSUMe2P9gc5wDFYzagS/W?=
 =?us-ascii?Q?ZXMFt5/Zfsgy5xXmaZ/bWQihVBAkNO12xBeFyuqf6NW9sSGaeFgUp/5Nf182?=
 =?us-ascii?Q?Dxu8FNL9iMDJ+OmbjVOeCBhfZKEcwyhcqNJc/gLtwyNvmu2AgZ+LS4qLRlTo?=
 =?us-ascii?Q?sGLW+AJN5uH4y8+eH3HEZisSK6yzbSlbUp9ZOMmaAgjBEF7u7OlOfFgXvICZ?=
 =?us-ascii?Q?/vkCHynNNoOU94YhAykepHOKh0TwV6AENoFeiZEuZt9v1fezbekdZjk0yCiI?=
 =?us-ascii?Q?3R7xAW5NX2I56XpoeaDzaUrjrtkz5OisZbgT1zQgJgaIangbvh9qxZ69OlRv?=
 =?us-ascii?Q?45MVSSxEXt/joxkP960q/ku0GG5I2PiGNPx9lmOqFMQ4WE3H5w8V8c7peda/?=
 =?us-ascii?Q?ntDnHSeGgsccYZo82uDqhXWb7lOdNXcrZnnzVInrx0mUOodVvTdtSZw14Dcl?=
 =?us-ascii?Q?JksolmyDo5+5xcgcvg62uelGxjOYn1KaqJxe2Mm+f65clWyCXZqc11xX+P8a?=
 =?us-ascii?Q?fhINgZSv+podbQDFyIujIN+Jf10pi30SiWnWtzyqt+jB92mrYf/iOTjH8xVF?=
 =?us-ascii?Q?TOmTMkgyplnD6fATAMgTZfYr2tnXlojHEWJiQJeDLNADWDkTldzvXyIZQ2Y5?=
 =?us-ascii?Q?Rw8ms8TOwfZonOy1T1tX+0ai3J/5w9JjI3aXvS/YESu8Em3mipy/TYHjjacb?=
 =?us-ascii?Q?FDcXMEpzymtg3/NrHKspeuSZybdhH0KxNS2ME3tKh6zezc6reYoxZsjsRdMX?=
 =?us-ascii?Q?LhRN0BZ1Xixg1wobmAwylBz3iVRLBR+kiXMEOq6x4B6izQ5E2/zHsu/VJmo3?=
 =?us-ascii?Q?vI3vCx5KqnSrkSW1/is/uLDSt0cozkwJRJc6j5y62p0MHiggl0KLZtunwd+i?=
 =?us-ascii?Q?Nk+UXPiL+lKV0JCoDVIzmXCQXHcx+ZQ4LWElYuYqhAeVO0FJBACM1p2ha9Nv?=
 =?us-ascii?Q?8TAH0D6LHP9dTAMccWGt8FyhoAH4qKhqE5O2bO2gRG11PwdlZhtd77xLvgZa?=
 =?us-ascii?Q?cvqdcE3YtXl0y7ugEo8K+PRMHstz7xJDQ08kOI4869vXJSqeUZ0sT3VW957C?=
 =?us-ascii?Q?odjvJX3amyi7Ygep0EQ/ewRG6z/nacPZ1e4nsoFBqLeEGdddMOvkuCo1nZ8b?=
 =?us-ascii?Q?4LvR54lbHVN+MkL6kuhyJWLf3Au7nd19x6vnYyY4nvqyByvypyb59bGlko+W?=
 =?us-ascii?Q?8BZ7X/rwXY/LJCmrhKk1v/uccNTodGzsCyaoXF4XKBaLJNtWSqNyH2wVb8Os?=
 =?us-ascii?Q?q7ET6kTMLmY3fsUFzc2LivAZcdjVUxGWJPfNOe+q6x64Rl2w6Te0ZK2DEb33?=
 =?us-ascii?Q?YTXJZ+JLmOz6Ean2hXvtOM1qIjSSSkOhTvI1?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 23 Sep 2025 04:39:03.8405
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 71bff5e0-f9fa-4654-f0b2-08ddfa5b1fd8
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8500

amd-cppc has 2 operation modes: autonomous (active) mode and
non-autonomous (passive) mode.
In active mode, we don't need Xen governor to calculate and tune the cpu
frequency, while hardware built-in CPPC power algorithm will calculate the
runtime workload and adjust cores frequency automatically according to the
power supply, thermal, core voltage and some other hardware conditions.
In active mode, CPPC ignores requests done in the desired performance field,
and takes into account only the values set to the minimum performance, maximum
performance, and energy performance preference registers.

A new field EPP (energy performance preference), in CPPC request register, is
introduced. It will be used in the CCLK DPM controller to drive the frequency
that a core is going to operate during short periods of activity, called
minimum active frequency, It could contatin a range of values from 0 to 0xff.
An EPP of zero sets the min active frequency to maximum frequency, while
an EPP of 0xff sets the min active frequency to approxiately Idle frequency.

We implement a new AMD CPU frequency driver `amd-cppc-epp` for active mode.
It requires `active` tag in Xen cmdline for users to explicitly select active
mode.
In driver `active-cppc-epp`, ->setpolicy() is hooked, not the ->target(), as
it does not depend on xen governor to do performance tuning.

We also introduce a new field "policy" (CPUFREQ_POLICY_xxx) to represent
performance policy. Right now, it supports three values:
CPUFREQ_POLICY_PERFORMANCE as maximum performance, CPUFREQ_POLICY_POWERSAVE
as the least power consumption, and CPUFREQ_POLICY_ONDEMAND as no preference,
just corresponding to "performance", "powersave" and "ondemand" Xen governor,
which benefit users from re-using "governor" in Xen cmdline to deliver
which performance policy they want to apply.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v1 -> v2:
- Remove redundant epp_mode
- Remove pointless initializer
- Define sole caller read_epp_init_once and epp_init value to read
pre-defined BIOS epp value only once
- Combine the commit "xen/cpufreq: introduce policy type when
cpufreq_driver->setpolicy exists"
---
v2 -> v3:
- Combined with commit "x86/cpufreq: add "cpufreq=amd-cppc,active" para"
- Refactor doc about "active mode"
- Change opt_cpufreq_active to opt_active_mode
- Let caller pass epp_init when unspecified to allow the function parameter
to be of uint8_t
- Make epp_init per-cpu value
---
v3 -> v4:
- doc refinement
- use MASK_EXTR() to get epp value
- fix indentation
- replace if-else() with switch()
- combine successive comments and do refinement
- no need to introduce amd_cppc_epp_update_limit() as a wrapper
- rename cpufreq_parse_policy() with cpufreq_policy_from_governor()
- no need to use case-insensitive comparison
---
v4 -> v5:
- refine doc to state what the default is for "active" sub-option and it's of
boolean nature
- excess blank after << for AMD_CPPC_EPP_MASK
- set max_perf with lowest_perf to get utmost powersave
- refine commit message to include description about relation between "policy"
and "governor"
---
v5 -> v6:
- expand comment for "epp" field
- let min_perf set with lowest_nonliner_perf, not lowest_perf, to constrain
  performance tuning in P-states range
- refactor doc and comments
- blank lines between non-fall-through case blocks
- introduce and add entry for "CPUFREQ_POLICY_ONDEMAND"
---
v6 -> v7
- make opt_active_mode __initdata when NDEBUG=y
- add assertion check for must-zero des_perf in active mode
- use the local variable max_perf and min_perf
- read_epp_init() doesn't worth a separate function
---
v7 -> v8:
- use "ASSERT(!opt_active_mode || !des_perf);" to remove #ifndef NDEBUG
- add a new helper amd_cppc_prepare_policy()
---
v8 -> v9:
- Adapt to changes of "Embed struct amd_cppc_drv_data{} into struct
cpufreq_policy{}"
---
v9 - v10
- rewind the changes in v9
---
 docs/misc/xen-command-line.pandoc    |   9 +-
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 135 ++++++++++++++++++++++++++-
 xen/drivers/cpufreq/utility.c        |  15 +++
 xen/include/acpi/cpufreq/cpufreq.h   |  18 ++++
 xen/include/public/sysctl.h          |   1 +
 5 files changed, 173 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 518e42d965..28a98321c7 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -515,7 +515,7 @@ If set, force use of the performance counters for oprofile, rather than detectin
 available support.
 
 ### cpufreq
-> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[verbose]]`
+> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[active][,verbose]]`
 
 > Default: `xen`
 
@@ -537,6 +537,13 @@ 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 don't rely on Xen governor to do performance monitoring
+  and tuning. Hardware built-in CPPC power algorithm will calculate the runtime
+  workload and adjust cores frequency automatically according to the power
+  supply, thermal, core voltage and some other hardware conditions.
+  The default is disabled, and the option only applies when `amd-cppc` is
+  enabled.
 
 There is also support for `;`-separated fallback options:
 `cpufreq=hwp;xen,verbose`.  This first tries `hwp` and falls back to `xen` if
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 5b99b86fb7..bb7f4e4a9e 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -67,9 +67,14 @@
  * max_perf.
  * Field des_perf conveys performance level Xen governor is requesting. And it
  * may be set to any performance value in the range [min_perf, max_perf],
- * inclusive.
+ * inclusive. In active mode, des_perf must be zero.
  * Field epp represents energy performance preference, which only has meaning
- * when active mode is enabled.
+ * when active mode is enabled. The EPP is used in the CCLK DPM controller
+ * to drive the frequency that a core is going to operate during short periods
+ * of activity, called minimum active frequency, It could contatin a range of
+ * values from 0 to 0xff. An EPP of zero sets the min active frequency to
+ * maximum frequency, while an EPP of 0xff sets the min active frequency to
+ * approxiately Idle frequency.
  */
 struct amd_cppc_drv_data
 {
@@ -106,6 +111,12 @@ static DEFINE_PER_CPU_READ_MOSTLY(struct amd_cppc_drv_data *,
  */
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned int, pxfreq_mhz);
 static DEFINE_PER_CPU_READ_MOSTLY(uint8_t, epp_init);
+#ifndef NDEBUG
+static bool __ro_after_init opt_active_mode;
+#else
+static bool __initdata opt_active_mode;
+#endif
+
 
 static bool __init amd_cppc_handle_option(const char *s, const char *end)
 {
@@ -118,6 +129,13 @@ static bool __init amd_cppc_handle_option(const char *s, const char *end)
         return true;
     }
 
+    ret = parse_boolean("active", s, end);
+    if ( ret >= 0 )
+    {
+        opt_active_mode = ret;
+        return true;
+    }
+
     return false;
 }
 
@@ -270,6 +288,7 @@ static void amd_cppc_write_request(unsigned int cpu, uint8_t min_perf,
 
     data->req.min_perf = min_perf;
     data->req.max_perf = max_perf;
+    ASSERT(!opt_active_mode || !des_perf);
     data->req.des_perf = des_perf;
     data->req.epp = epp;
 
@@ -417,7 +436,7 @@ static int cf_check amd_cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
     return 0;
 }
 
-static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+static int amd_cppc_cpufreq_init_perf(struct cpufreq_policy *policy)
 {
     unsigned int cpu = policy->cpu;
     struct amd_cppc_drv_data *data;
@@ -450,12 +469,103 @@ static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
     amd_cppc_boost_init(policy, data);
 
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    int ret;
+
+    ret = amd_cppc_cpufreq_init_perf(policy);
+    if ( ret )
+        return ret;
+
     amd_cppc_verbose(policy->cpu,
                      "CPU initialized with amd-cppc passive mode\n");
 
     return 0;
 }
 
+static int cf_check amd_cppc_epp_cpu_init(struct cpufreq_policy *policy)
+{
+    int ret;
+
+    ret = amd_cppc_cpufreq_init_perf(policy);
+    if ( ret )
+        return ret;
+
+    policy->policy = cpufreq_policy_from_governor(policy->governor);
+
+    amd_cppc_verbose(policy->cpu,
+                     "CPU initialized with amd-cppc active mode\n");
+
+    return 0;
+}
+
+static void amd_cppc_prepare_policy(struct cpufreq_policy *policy,
+                                    uint8_t *max_perf, uint8_t *min_perf,
+                                    uint8_t *epp)
+{
+    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data,
+                                                   policy->cpu);
+
+    /*
+     * On default, set min_perf with lowest_nonlinear_perf, and max_perf
+     * with the highest, to ensure performance scaling in P-states range.
+     */
+    *max_perf = data->caps.highest_perf;
+    *min_perf = data->caps.lowest_nonlinear_perf;
+
+    /*
+     * In policy CPUFREQ_POLICY_PERFORMANCE, increase min_perf to
+     * highest_perf to achieve ultmost performance.
+     * In policy CPUFREQ_POLICY_POWERSAVE, decrease max_perf to
+     * lowest_nonlinear_perf to achieve ultmost power saving.
+     * Set governor only to help print proper policy info to users.
+     */
+    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 = *max_perf;
+        policy->governor = &cpufreq_gov_performance;
+        break;
+
+    case CPUFREQ_POLICY_POWERSAVE:
+        /* Force the epp value to be 0xff for powersave policy */
+        *epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
+        *max_perf = *min_perf;
+        policy->governor = &cpufreq_gov_powersave;
+        break;
+
+    case CPUFREQ_POLICY_ONDEMAND:
+        /*
+         * Set epp with medium value to show no preference over performance
+         * or powersave
+         */
+        *epp = CPPC_ENERGY_PERF_BALANCE;
+        policy->governor = &cpufreq_gov_dbs;
+        break;
+
+    default:
+        *epp = per_cpu(epp_init, policy->cpu);
+        break;
+    }
+}
+
+static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
+{
+    uint8_t max_perf, min_perf, epp;
+
+    amd_cppc_prepare_policy(policy, &max_perf, &min_perf, &epp);
+
+    amd_cppc_write_request(policy->cpu, min_perf,
+                           0 /* no des_perf in active mode */,
+                           max_perf, epp);
+    return 0;
+}
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
@@ -466,10 +576,27 @@ amd_cppc_cpufreq_driver =
     .exit   = amd_cppc_cpufreq_cpu_exit,
 };
 
+static const struct cpufreq_driver __initconst_cf_clobber
+amd_cppc_epp_driver =
+{
+    .name       = XEN_AMD_CPPC_EPP_DRIVER_NAME,
+    .verify     = amd_cppc_cpufreq_verify,
+    .setpolicy  = amd_cppc_epp_set_policy,
+    .init       = amd_cppc_epp_cpu_init,
+    .exit       = amd_cppc_cpufreq_cpu_exit,
+};
+
 int __init amd_cppc_register_driver(void)
 {
+    int ret;
+
     if ( !cpu_has_cppc )
         return -ENODEV;
 
-    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+    if ( opt_active_mode )
+        ret = cpufreq_register_driver(&amd_cppc_epp_driver);
+    else
+        ret = cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+
+    return ret;
 }
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 987c3b5929..e2cc9ff2af 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -250,6 +250,7 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
     data->min = policy->min;
     data->max = policy->max;
     data->limits = policy->limits;
+    data->policy = policy->policy;
     if (cpufreq_driver.setpolicy)
         return alternative_call(cpufreq_driver.setpolicy, data);
 
@@ -281,3 +282,17 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
 
     return __cpufreq_governor(data, CPUFREQ_GOV_LIMITS);
 }
+
+unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov)
+{
+    if ( !strncmp(gov->name, "performance", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_PERFORMANCE;
+
+    if ( !strncmp(gov->name, "powersave", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_POWERSAVE;
+
+    if ( !strncmp(gov->name, "ondemand", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_ONDEMAND;
+
+    return CPUFREQ_POLICY_UNKNOWN;
+}
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 5d4881eea8..9ef7c4683a 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -81,6 +81,7 @@ struct cpufreq_policy {
     int8_t              turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
+    unsigned int        policy; /* CPUFREQ_POLICY_* */
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -131,6 +132,23 @@ 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
 
+/*
+ * Performance Policy
+ * If cpufreq_driver->target() exists, the ->governor decides what frequency
+ * within the limits is used. If cpufreq_driver->setpolicy() exists, these
+ * following policies are available:
+ * CPUFREQ_POLICY_PERFORMANCE represents maximum performance
+ * CPUFREQ_POLICY_POWERSAVE represents least power consumption
+ * CPUFREQ_POLICY_ONDEMAND represents no preference over performance or
+ * powersave
+ */
+#define CPUFREQ_POLICY_UNKNOWN      0
+#define CPUFREQ_POLICY_POWERSAVE    1
+#define CPUFREQ_POLICY_PERFORMANCE  2
+#define CPUFREQ_POLICY_ONDEMAND     3
+
+unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov);
+
 /* pass a target to the cpufreq driver */
 extern int __cpufreq_driver_target(struct cpufreq_policy *policy,
                                    unsigned int target_freq,
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index aa29a5401c..eb3a23b038 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -454,6 +454,7 @@ struct xen_set_cppc_para {
 };
 
 #define XEN_AMD_CPPC_DRIVER_NAME "amd-cppc"
+#define XEN_AMD_CPPC_EPP_DRIVER_NAME "amd-cppc-epp"
 #define XEN_HWP_DRIVER_NAME "hwp"
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128127.1468633 (Exim 4.92)
	(envelope-from )
	id 1v0uo9-0001v3-V7; Tue, 23 Sep 2025 04:39:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128127.1468633; Tue, 23 Sep 2025 04: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 1v0uo9-0001un-RK; Tue, 23 Sep 2025 04:39:17 +0000
Received: by outflank-mailman (input) for mailman id 1128127;
 Tue, 23 Sep 2025 04: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 1v0uo8-00015C-Be
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:16 +0000
Received: from BN8PR05CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c110::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4217b781-9837-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 06:39:15 +0200 (CEST)
Received: from SJ0PR03CA0363.namprd03.prod.outlook.com (2603:10b6:a03:3a1::8)
 by CH2PR12MB4264.namprd12.prod.outlook.com (2603:10b6:610:a4::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 04:39:11 +0000
Received: from SJ1PEPF000023DA.namprd21.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::e) by SJ0PR03CA0363.outlook.office365.com
 (2603:10b6:a03:3a1::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:39:11 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023DA.mail.protection.outlook.com (10.167.244.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:11 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:39:07 -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: 4217b781-9837-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=n8QQq2j2Bm6kajFQezWSZYXpYdyDaLrIR64uK8WgQeqUFxdXlk71hXPqtvgfkH26naGzlTjuq/KcPh0a4omMGmyC5UPSEamuCQfaO5V5tOISy+YqMOpcX1BYxjGEtaLDdhpRiIG8R0+AxB0afRWcJUwR1yMJWAX4s6hKZJ+e+s5t3z8VE1N31+OJwTM165CNgOJ2fafcmco2ZEJrjcjkGnWt+Yd0CzaPoZeumQnVdoN9kwM+rknLIBo85dfUSGVp+oCXz84SBccAzLutmjM82mHG5/8KKogJtkVZx7zqK7nBEiGF3plF433lX89uT/2JOVVEVRXq9LPBZwL+VHkERw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jPU48WtAWFZn4E4aJF1wkdR2jxhJrOPaI8KG+sd+2wA=;
 b=tg6iM8XyawQcW+b2QLxInc76xTIjTNasI7fDhAk/WHWGlofXq5SlWQQVlJT1rO2XOsQn13qz+0e8Jx0CTfn9hjEzDA1NEBd2swYZEZnwxpAT/gR6ZyMlv9YcBK8atFoutToMQH+BcHwU1Wec05jmwPZLYtaP1ad6ckD3zixokPA8HjXmrk5DCopz84GyfSekB6QIB7xAwV/13I9TI5RRA8cQG9eu4Vg7LOruU2Kfu39Jc6pPje/xNcuGCFUwFaM8MjN0UukLMoK3Z7hMHSWB4H3z+RfJ13sHMJq0RM6XY9Toghv36gRZpi+VpYyi589tXfvGHT+u1cVnXhesI30ANg==
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=jPU48WtAWFZn4E4aJF1wkdR2jxhJrOPaI8KG+sd+2wA=;
 b=rK04ZOurO78xLlij56vcyzYt2uGsgbE/Ct7DK0HE4U0ki9n7GwipktmGR4i2iBCCSrgExDWa1XwneePgIGQF2oRcKajrKZaYyyI6yfaxh/7I2ZfrjHanV8eCU7K7vP8btDNIgCMVS+mIM2tAb+wWxi8Turb8MP29nVdlcg1GIHY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Jan Beulich 
Subject: [PATCH v10 6/8] xen/cpufreq: bypass governor-related para for amd-cppc-epp
Date: Tue, 23 Sep 2025 12:38:24 +0800
Message-ID: <20250923043826.3831957-7-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023DA:EE_|CH2PR12MB4264:EE_
X-MS-Office365-Filtering-Correlation-Id: f0f8526a-c020-439a-7125-08ddfa5b2462
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?3Dp9q2iKOEBG5rBA8D3ku/iIaYFNtxVgNlzzc/kKviOqu2Sf6fIamsWynhze?=
 =?us-ascii?Q?+RHP0adiho5kTqueJ1hHgwQbSE8OS+sgJybI+7fUX+tiJDFzT1eS2rAG0CgG?=
 =?us-ascii?Q?KQ9/UFyt0voZMXzdRSKGZYzjHQ4dM5s7nfIsT5KhcRlf0LKCQ5gwazrrPdkT?=
 =?us-ascii?Q?z6ihfAoirWmq/Mspa28lpY0fjpoLv0gYt9CKlAOhRlfTzK1q1KELHMpcuniY?=
 =?us-ascii?Q?NkyIhDoa8+5Tjz5BmenKH8bmxwO/LMhL8UNi2LK/9G0vT5hBORYmB5hkdrhz?=
 =?us-ascii?Q?A4hPmIx3lvQmADuQzlEHkXjrSAUQ4wcq4xJB7vo7ovza8KOatToU5mdbBo9K?=
 =?us-ascii?Q?vygwMt42PqQUrHYtfIi2XUeGQfSBsJ5MT6+p1OBF/pgDyF0wJ46slxRsGfvv?=
 =?us-ascii?Q?vEC06KUMqwpOIfgZykk9JwlZkXUYv8HVZ8kpyZYgPuXbpmg6ME2FM5xnUNPt?=
 =?us-ascii?Q?popIZtUHdU/B3ZSEfFBixPgU+ZpBmZkvebggJeYl1IZVx3k8Z7S7HloRBuD/?=
 =?us-ascii?Q?zNWIBEZ4yZAVdkV0U3JyJHKPjSPTWcUm//Nde0EWdY8fUFCD0dTMalMkfh4M?=
 =?us-ascii?Q?pdg5WJVi/jMDR/uTnl3d9LHgEcRN5LXVfcoLTBC00RRF/fjB8kwtmTN8D/Ch?=
 =?us-ascii?Q?GkpteMxogu9gavGVk/F+WhP8027xuD+Bfw9StFC0vjflGZK5pboSRLw/jKEL?=
 =?us-ascii?Q?duP2bNGpSd+vgWkx+UPsADWg1S9Etwc9qMCRUDGY2erxv3SfWuwe/5zZT7Ro?=
 =?us-ascii?Q?CJfihhYqmefGfpRN5QnNirZ14/CQ0FVGVbgp3je7N99ypswa1saVk5kTY5q4?=
 =?us-ascii?Q?3Ax6ddl3w18oDI5yCy5NSYQfar1HpYmqSxZsne9JdQ2pLw1f++dsUtUjRJ/s?=
 =?us-ascii?Q?mODQ0GaSyCPPfMRyEr4e87Pge+1hCmZxrbMYvHmZi5jmcXzfT8PCJMWwrJfc?=
 =?us-ascii?Q?ry8HAzyG+9spwwtwmy9su2JJxmxjxD+izvNIcLeQ5M/ANMMBHwJnSQx24bY3?=
 =?us-ascii?Q?WKOyjSK4kWfTOEsjPmB3jHWre25YWqpsnu9aL39MDB9TN2sf8/gXCL46zCRD?=
 =?us-ascii?Q?cPVcd5l0Qs1R6/uqGqkugJ3Cta0lev3/+j5SMqX6Muq3pkzBWsDHvHHRgbOM?=
 =?us-ascii?Q?6IiuOD9rDK+AqhvybLXOEpfTEcQdvitluzC1VQRH9eG2Cnx2lZIZLyIlwnkH?=
 =?us-ascii?Q?oyyEzAlUhSzKmA68DDrhm2xSdWejz5v6UfL4633ux9c4/4PSF5+tQEsUQFkd?=
 =?us-ascii?Q?nn5dnobZl5PcUBp2SJ5rH+M4tTyK8/MDn6mr31xVEG/veSV2f//46/r8mYoY?=
 =?us-ascii?Q?w4g2GJtF9IsJpP2DLCEY2m3L5jqGHAGMXIh7jlWcpVKxyZtGYnjF9jXRZ2cQ?=
 =?us-ascii?Q?dB8j3qvXVyyQLYOBw5rlwLT9zSh6gSY47OYtUyBvxbBXx0RUvUaoZL8OL2Wo?=
 =?us-ascii?Q?MtRjVizrlQcyDdVndot8A3X1bqse0uI/UKPPGhKIfbbeDa+vAYsjT0mMe5+D?=
 =?us-ascii?Q?CycPrYd/a6lDtFCbh0KFSlwHktO5oF9jmvuf?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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 Sep 2025 04:39:11.4538
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f0f8526a-c020-439a-7125-08ddfa5b2462
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4264

HWP and amd-cppc-epp are both governor-less driver, so we introduce
"is_governor_less" flag and cpufreq_is_governorless() to help bypass
governor-related info on dealing with cpufreq para.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
Acked-by: Anthony PERARD 
---
v3 -> v4:
- Include validation check fix here
---
v4 -> v5:
- validation check has beem moved to where XEN_PROCESSOR_PM_CPPC and
XEN_CPPC_INIT have been firstly introduced
- adding "cpufreq_driver.setpolicy == NULL" check to exclude governor-related
para for amd-cppc-epp driver in get/set_cpufreq_para()
---
v5 -> v6:
- add helper cpufreq_is_governorless() to tell whether cpufreq driver is
governor-less
---
v6 -> v7:
- change "hw_auto" to "is_goverless"
- complement comment
- wrap around with PM_OP to avoid violating Misra rule 2.1
---
v7 -> v8:
- change "is_goverless" to "is_governor_less"
- make cpufreq_is_governorless() inline function
---
 tools/misc/xenpm.c                 | 10 +++++++---
 xen/drivers/acpi/pm-op.c           |  4 ++--
 xen/include/acpi/cpufreq/cpufreq.h | 12 ++++++++++++
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index c7f19cea28..682d092479 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -832,9 +832,13 @@ static void print_cppc_para(unsigned int cpuid,
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
-    bool hwp = strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) == 0;
+    bool is_governor_less = false;
     int i;
 
+    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
+         !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+        is_governor_less = true;
+
     printf("cpu id               : %d\n", cpuid);
 
     printf("affected_cpus        :");
@@ -842,7 +846,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
         printf(" %d", p_cpufreq->affected_cpus[i]);
     printf("\n");
 
-    if ( hwp )
+    if ( is_governor_less )
         printf("cpuinfo frequency    : base [%"PRIu32"] max [%"PRIu32"]\n",
                p_cpufreq->cpuinfo_min_freq,
                p_cpufreq->cpuinfo_max_freq);
@@ -854,7 +858,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 
     printf("scaling_driver       : %s\n", p_cpufreq->scaling_driver);
 
-    if ( !hwp )
+    if ( !is_governor_less )
     {
         if ( p_cpufreq->gov_num )
             printf("scaling_avail_gov    : %s\n",
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index f50acd7088..4cca42c4fc 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -154,7 +154,7 @@ 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() )
+    if ( !cpufreq_is_governorless(op->cpuid) )
     {
         if ( !(scaling_available_governors =
                xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
@@ -240,7 +240,7 @@ static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
     if ( !policy || !policy->governor )
         return -EINVAL;
 
-    if ( hwp_active() )
+    if ( cpufreq_is_governorless(op->cpuid) )
         return -EOPNOTSUPP;
 
     switch( op->u.set_para.ctrl_type )
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 9ef7c4683a..7caeae26cf 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -294,4 +294,16 @@ int acpi_cpufreq_register(void);
 int amd_cppc_cmdline_parse(const char *s, const char *e);
 int amd_cppc_register_driver(void);
 
+/*
+ * Governor-less cpufreq driver indicates the driver doesn't rely on Xen
+ * governor to do performance tuning, mostly it has hardware built-in
+ * algorithm to calculate runtime workload and adjust cores frequency
+ * automatically, like Intel HWP, or CPPC in AMD.
+ */
+static inline bool cpufreq_is_governorless(unsigned int cpuid)
+{
+    return processor_pminfo[cpuid]->init && (hwp_active() ||
+                                             cpufreq_driver.setpolicy);
+}
+
 #endif /* __XEN_CPUFREQ_PM_H__ */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128130.1468643 (Exim 4.92)
	(envelope-from )
	id 1v0uoD-0002HM-Av; Tue, 23 Sep 2025 04:39:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128130.1468643; Tue, 23 Sep 2025 04:39: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 1v0uoD-0002GV-4N; Tue, 23 Sep 2025 04:39:21 +0000
Received: by outflank-mailman (input) for mailman id 1128130;
 Tue, 23 Sep 2025 04:39: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 1v0uoA-0000c8-Um
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:19 +0000
Received: from BL2PR02CU003.outbound.protection.outlook.com
 (mail-eastusazlp17011000f.outbound.protection.outlook.com
 [2a01:111:f403:c100::f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42994bca-9837-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 06:39:16 +0200 (CEST)
Received: from SJ0PR03CA0379.namprd03.prod.outlook.com (2603:10b6:a03:3a1::24)
 by SA3PR12MB7829.namprd12.prod.outlook.com (2603:10b6:806:316::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.18; Tue, 23 Sep
 2025 04:39:10 +0000
Received: from SJ1PEPF000023DA.namprd21.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::a0) by SJ0PR03CA0379.outlook.office365.com
 (2603:10b6:a03:3a1::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:39:09 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023DA.mail.protection.outlook.com (10.167.244.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:09 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:39:04 -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: 42994bca-9837-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=InkQXB/oYYvDztmGOvNzuq0gdb7wGxCYKAP1vbr33jgjy99yQHsg6ym98vq2uhH03qCwsvclRjgTkxFX+khpKm1c61rM4i5bOuZmUMhZWNVs3o78BrzsdKCdpRwoKzD7EGWwUz3zK99JXjtqdCvE63TgdeQo8Fu0gam3pjJWIfBSwcRLYYCPa0Du+34Ftjhk9goLJT6Pr/DOPnjt3PRLzDwBC+l0zUvONifZxGLPUSqONfB6D8vL8dU27MjAuDJF6CZg95QJFkPU4B0UkbcI54/5QbcDIG2PyJirDkHLex5O3Z0puFt1WmOS+Aj7jYG/debBuN94m8I9XkSWieTKoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UK7p1dxIdAUwnp9/KlnmFuOMlvoXNyC3ltvAs175wZ0=;
 b=Hc3iSF9AIsX4PMi+eBB1vom6+2epv2fnDYW/Kst4vqHozLg+CrcG9A3V9H5XXwvoR/xIqMe/2ciNlnG+4vSeVgv2QE2OA8dkGhNE80+xbYYS7WKJtiI9xcOUCqBCw90PRK0/0ASPUZcEJu8g19nOfXplYxTSqkKl4DaJvEbefIjVxsqZehk1gm0Jo9AiNxlijrwoIYXIXhiNzdwdG/eia0QIJ+OAEyv5Ju+LzcqTCrs9gZRSdNmp6gaa4fHmOVjtVeZ54biUdETZQNcEZyTqJxz/G6+9VWhaUIQCqR3AFmKpVWkEPCY1iONwvN6T4Vq4RNxfuBjK88LKR1H/pAcJZA==
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=UK7p1dxIdAUwnp9/KlnmFuOMlvoXNyC3ltvAs175wZ0=;
 b=t3jvn98Dg337iCtF/PQLDIg5f2ThBJ3bTlGz286X5Qc8xQXCTlaBhhpTjxTAQ2joWfaYnyYSYvcOKuNDvmOBg8CV3ZVCaBwDLmkxWluDX16AXWU4eY04FR5e2RoPuUgb/BNphqDFnQog+xLgDOtJYqAazbwQFQo2eqBAS9ozK1M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Juergen Gross , Andrew Cooper
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH v10 5/8] tools/cpufreq: extract CPPC para from cpufreq para
Date: Tue, 23 Sep 2025 12:38:23 +0800
Message-ID: <20250923043826.3831957-6-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023DA:EE_|SA3PR12MB7829:EE_
X-MS-Office365-Filtering-Correlation-Id: 54b0e6f0-ac36-448d-8eb8-08ddfa5b236b
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?pvOsfUH2VGXNCRGcFkTXkNL8tnMhWyN6MYQoIptQnxJt0rzy4zQ2XtV0h/nO?=
 =?us-ascii?Q?AJMwxTZhir+QyeAeDa8zND7utCNJaJQ6boug1NMkdx1oKX5jwsa8pdUY0ySq?=
 =?us-ascii?Q?5vzMS62kRVZn8fpNVhbmrMCEpHmWUzdC4WWh2cR4PCuAdzNQFnY01TVTszsL?=
 =?us-ascii?Q?tvLGR0xQ4r/L5OOtst6l8wAOstUTd9D0LIokqt74AxMxt7siVNUHJj4qCfg9?=
 =?us-ascii?Q?UF5mqWf6NCXGKRYuyi5wovocKbbF7gxQcXFp+wF2DdeWqjW7kIOi6yFZq6ha?=
 =?us-ascii?Q?bR3rcyTTRvXSTY4+f9j0jvwu5v0TLK0YlAiS37KXkq7qO4dMP3lI5G2sJvtH?=
 =?us-ascii?Q?ENRLx6kpeWNuSKp1SVr6aSz59RbD+udUPebT1UW5stxKVG9rS8ZtOpC/uMq4?=
 =?us-ascii?Q?OyObK0ILOr1d3WXWunTJYVRDTRplb/xIGEbjKmRDHniGzuvwEc3KhKFUHQi4?=
 =?us-ascii?Q?m0TbE/QnKI5cyLAqOibDnOcDn0RWMHRMAsXv9QJNnIFnKYwN0FnIfBSruThl?=
 =?us-ascii?Q?VO25dDwuqVzgDKHr65i1aFUKzT8Pz0M14PULyfMIJNV8Hq6c/nYWE9zh1VCE?=
 =?us-ascii?Q?FmPV6/m62T6NmGXpEcHNZ82Spt8jJUuZaC3usRhTI0OayUg1YDwGDcO+fTaf?=
 =?us-ascii?Q?SPxh6vwZHa3NrIC1enV8oPVJPZ6ar4aHALYVnktnCoWyvOy5am1lPnEdJg6c?=
 =?us-ascii?Q?FQ0BNISDtpZwnG9jPC+WRUCGt2JkWp4tRNSBSPyzpZAtt6X/6xdOD+GtKer0?=
 =?us-ascii?Q?wQ4WK2CEXtaONvQWmwDPxMt50hpfgWeIi+2LkLIDAo53nPBhEYpq55fVnpD2?=
 =?us-ascii?Q?hoW1iTGqgkKFFy7YYxixKHM28HD1PRPyI3TRSeHOSzEdZgtoFSYaLl8oqOrY?=
 =?us-ascii?Q?2QMwLRwVNc/YXS/IjzhCCiAVsSpzmM386ojfptyQGFsCuo187VXByEF+NA3N?=
 =?us-ascii?Q?I0rNL4a/fFUvzvaxVLV4OvAUX2+yCmr27ijht4Qp1Y23hnybtEDrnocKi5Q1?=
 =?us-ascii?Q?INh10mntjSsHQYWufgqeafKe7sdR1tt5gMOfXxNRbA4Fp9oI9/YiMonVBLRC?=
 =?us-ascii?Q?RfQFziTVAbo2Tv3sqD2zuMSp3uTMfyM1y9zxMSGD3atJAIE0K0ctpDVm+2xh?=
 =?us-ascii?Q?0IqFCah+BhNZYw16BRUdcNFrvJF99xDYs6y/Oxq5g0Ali1XeDvoxS1Q3HNij?=
 =?us-ascii?Q?fEgx2lkfBxXn+yOimrIq90Dfszj1Vk200qVH1AaVwacmUnX5eAlpSSDfkRK7?=
 =?us-ascii?Q?M8wdNnZwoIGO9zKDKoSOqWIHTLbaGaHr2YLmSipfSDVts50w48sprvFhMC44?=
 =?us-ascii?Q?B/UTRi6e2IFid75BX1vrc/j41VUuSs/AW91oqXFfnNsZJruHR2brox9G1yjq?=
 =?us-ascii?Q?byNr5Vu0YjvCQbSpCwnuIN+2D3jOmBAuaDfH7p44RMaQfZ1SiSN1iP3HJhqs?=
 =?us-ascii?Q?I8xDScut4yJ2e6rv570FOn3eWxPW3l2Rypj6xDjC3detar6DvWP6r1JbmAle?=
 =?us-ascii?Q?Fh9ItOAlWO/TR2kgIWhBI0a4WHt8nfmtpmot?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 23 Sep 2025 04:39:09.8346
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 54b0e6f0-ac36-448d-8eb8-08ddfa5b236b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7829

We extract cppc info from "struct xen_get_cpufreq_para", where it acts as
a member of union, and share the space with governor info.
However, it may fail in amd-cppc passive mode, in which governor info and
CPPC info could co-exist, and both need to be printed together via xenpm tool.
If we tried to still put it in "struct xen_get_cpufreq_para" (e.g. just move
out of union), "struct xen_get_cpufreq_para" will enlarge too much to further
make xen_sysctl.u exceed 128 bytes.

So we introduce a new sub-field GET_CPUFREQ_CPPC to dedicatedly acquire
CPPC-related para, and make get-cpufreq-para invoke GET_CPUFREQ_CPPC
if available.
New helpers print_cppc_para() and get_cpufreq_cppc() are introduced to
extract CPPC-related parameters process from cpufreq para.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich  # hypervisor
Acked-by: Anthony PERARD 
---
v4 -> v5:
- new commit
---
v5 -> v6:
- remove the changes for get-cpufreq-para
---
v6 -> v7:
- make get-cpufreq-para invoke GET_CPUFREQ_CPPC
---
v7 -> v8:
- use structure assignment as it is a alias
- add errno info to the error print
---
v9 -> v10
- drop the outer union
---
 tools/include/xenctrl.h     |  27 +++++-----
 tools/libs/ctrl/xc_pm.c     |  47 +++++++++++-----
 tools/misc/xenpm.c          | 103 ++++++++++++++++++++++--------------
 xen/drivers/acpi/pm-op.c    |  43 +++++++++------
 xen/include/public/sysctl.h |  31 ++++++-----
 5 files changed, 155 insertions(+), 96 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 965d3b585a..c14ecd66aa 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1924,22 +1924,19 @@ struct xc_get_cpufreq_para {
     uint32_t cpuinfo_cur_freq;
     uint32_t cpuinfo_max_freq;
     uint32_t cpuinfo_min_freq;
-    union {
-        struct {
-            uint32_t scaling_cur_freq;
+    struct {
+        uint32_t scaling_cur_freq;
 
-            char scaling_governor[CPUFREQ_NAME_LEN];
-            uint32_t scaling_max_freq;
-            uint32_t scaling_min_freq;
+        char scaling_governor[CPUFREQ_NAME_LEN];
+        uint32_t scaling_max_freq;
+        uint32_t scaling_min_freq;
 
-            /* for specific governor */
-            union {
-                xc_userspace_t userspace;
-                xc_ondemand_t ondemand;
-            } u;
-        } s;
-        xc_cppc_para_t cppc_para;
-    } u;
+        /* for specific governor */
+        union {
+            xc_userspace_t userspace;
+            xc_ondemand_t ondemand;
+        } u;
+    } s;
 
     int32_t turbo_enabled;
 };
@@ -1953,6 +1950,8 @@ int xc_set_cpufreq_para(xc_interface *xch, int cpuid,
                         int ctrl_type, int ctrl_value);
 int xc_set_cpufreq_cppc(xc_interface *xch, int cpuid,
                         xc_set_cppc_para_t *set_cppc);
+int xc_get_cppc_para(xc_interface *xch, unsigned int cpuid,
+                     xc_cppc_para_t *cppc_para);
 int xc_get_cpufreq_avgfreq(xc_interface *xch, int cpuid, int *avg_freq);
 
 int xc_set_sched_opt_smt(xc_interface *xch, uint32_t value);
diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
index 6fda973f1f..5b4e489acf 100644
--- a/tools/libs/ctrl/xc_pm.c
+++ b/tools/libs/ctrl/xc_pm.c
@@ -274,25 +274,24 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
         /*
          * Copy to user_para no matter what cpufreq driver/governor.
          *
-         * First sanity check layout of the union subject to memcpy() below.
+         * First sanity check layout of the struct subject to memcpy() below.
          */
-        BUILD_BUG_ON(sizeof(user_para->u) != sizeof(sys_para->u));
+        BUILD_BUG_ON(sizeof(user_para->s) != sizeof(sys_para->s));
 
 #define CHK_FIELD(fld) \
-        BUILD_BUG_ON(offsetof(typeof(user_para->u), fld) != \
-                     offsetof(typeof(sys_para->u),  fld))
+        BUILD_BUG_ON(offsetof(typeof(user_para->s), fld) != \
+                     offsetof(typeof(sys_para->s),  fld))
 
-        CHK_FIELD(s.scaling_cur_freq);
-        CHK_FIELD(s.scaling_governor);
-        CHK_FIELD(s.scaling_max_freq);
-        CHK_FIELD(s.scaling_min_freq);
-        CHK_FIELD(s.u.userspace);
-        CHK_FIELD(s.u.ondemand);
-        CHK_FIELD(cppc_para);
+        CHK_FIELD(scaling_cur_freq);
+        CHK_FIELD(scaling_governor);
+        CHK_FIELD(scaling_max_freq);
+        CHK_FIELD(scaling_min_freq);
+        CHK_FIELD(u.userspace);
+        CHK_FIELD(u.ondemand);
 
 #undef CHK_FIELD
 
-        memcpy(&user_para->u, &sys_para->u, sizeof(sys_para->u));
+        memcpy(&user_para->s, &sys_para->s, sizeof(sys_para->s));
     }
 
 unlock_4:
@@ -366,6 +365,30 @@ int xc_set_cpufreq_cppc(xc_interface *xch, int cpuid,
     return ret;
 }
 
+int xc_get_cppc_para(xc_interface *xch, unsigned int cpuid,
+                     xc_cppc_para_t *cppc_para)
+{
+    int ret;
+    struct xen_sysctl sysctl = {};
+
+    if ( !xch  || !cppc_para )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_pm_op;
+    sysctl.u.pm_op.cmd = GET_CPUFREQ_CPPC;
+    sysctl.u.pm_op.cpuid = cpuid;
+
+    ret = xc_sysctl(xch, &sysctl);
+    if ( ret )
+        return ret;
+
+    *cppc_para = sysctl.u.pm_op.u.get_cppc;
+    return ret;
+}
+
 int xc_get_cpufreq_avgfreq(xc_interface *xch, int cpuid, int *avg_freq)
 {
     int ret = 0;
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 6b054b10a4..c7f19cea28 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -801,6 +801,34 @@ static unsigned int calculate_activity_window(const xc_cppc_para_t *cppc,
     return mantissa * multiplier;
 }
 
+/* print out parameters about cpu cppc */
+static void print_cppc_para(unsigned int cpuid,
+                            const xc_cppc_para_t *cppc)
+{
+    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");
+    printf("\n");
+}
+
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
@@ -826,71 +854,45 @@ 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",
                    p_cpufreq->scaling_available_governors);
 
-        printf("current_governor     : %s\n", p_cpufreq->u.s.scaling_governor);
-        if ( !strncmp(p_cpufreq->u.s.scaling_governor,
+        printf("current_governor     : %s\n", p_cpufreq->s.scaling_governor);
+        if ( !strncmp(p_cpufreq->s.scaling_governor,
                       "userspace", CPUFREQ_NAME_LEN) )
         {
             printf("  userspace specific :\n");
             printf("    scaling_setspeed : %u\n",
-                   p_cpufreq->u.s.u.userspace.scaling_setspeed);
+                   p_cpufreq->s.u.userspace.scaling_setspeed);
         }
-        else if ( !strncmp(p_cpufreq->u.s.scaling_governor,
+        else if ( !strncmp(p_cpufreq->s.scaling_governor,
                            "ondemand", CPUFREQ_NAME_LEN) )
         {
             printf("  ondemand specific  :\n");
             printf("    sampling_rate    : max [%u] min [%u] cur [%u]\n",
-                   p_cpufreq->u.s.u.ondemand.sampling_rate_max,
-                   p_cpufreq->u.s.u.ondemand.sampling_rate_min,
-                   p_cpufreq->u.s.u.ondemand.sampling_rate);
+                   p_cpufreq->s.u.ondemand.sampling_rate_max,
+                   p_cpufreq->s.u.ondemand.sampling_rate_min,
+                   p_cpufreq->s.u.ondemand.sampling_rate);
             printf("    up_threshold     : %u\n",
-                   p_cpufreq->u.s.u.ondemand.up_threshold);
+                   p_cpufreq->s.u.ondemand.up_threshold);
         }
 
         printf("scaling_avail_freq   :");
         for ( i = 0; i < p_cpufreq->freq_num; i++ )
             if ( p_cpufreq->scaling_available_frequencies[i] ==
-                 p_cpufreq->u.s.scaling_cur_freq )
+                 p_cpufreq->s.scaling_cur_freq )
                 printf(" *%d", p_cpufreq->scaling_available_frequencies[i]);
             else
                 printf(" %d", p_cpufreq->scaling_available_frequencies[i]);
         printf("\n");
 
         printf("scaling frequency    : max [%u] min [%u] cur [%u]\n",
-               p_cpufreq->u.s.scaling_max_freq,
-               p_cpufreq->u.s.scaling_min_freq,
-               p_cpufreq->u.s.scaling_cur_freq);
+               p_cpufreq->s.scaling_max_freq,
+               p_cpufreq->s.scaling_min_freq,
+               p_cpufreq->s.scaling_cur_freq);
     }
 
     printf("turbo mode           : %s\n",
@@ -898,6 +900,24 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
     printf("\n");
 }
 
+/* show cpu cppc parameters information on CPU cpuid */
+static int show_cppc_para_by_cpuid(xc_interface *xc_handle, unsigned int cpuid)
+{
+    int ret;
+    xc_cppc_para_t cppc_para;
+
+    ret = xc_get_cppc_para(xc_handle, cpuid, &cppc_para);
+    if ( !ret )
+        print_cppc_para(cpuid, &cppc_para);
+    else if ( errno == ENODEV )
+        ret = 0; /* Ignore unsupported platform */
+    else
+        fprintf(stderr, "[CPU%u] failed to get cppc parameter: %s\n",
+                cpuid, strerror(errno));
+
+    return ret;
+}
+
 /* show cpu frequency parameters information on CPU cpuid */
 static int show_cpufreq_para_by_cpuid(xc_interface *xc_handle, int cpuid)
 {
@@ -957,7 +977,12 @@ static int show_cpufreq_para_by_cpuid(xc_interface *xc_handle, int cpuid)
     } while ( ret && errno == EAGAIN );
 
     if ( ret == 0 )
+    {
         print_cpufreq_para(cpuid, p_cpufreq);
+
+        /* Show CPPC parameters if available */
+        ret = show_cppc_para_by_cpuid(xc_handle, cpuid);
+    }
     else if ( errno == ENODEV )
     {
         ret = -ENODEV;
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index a7eaf29c31..f50acd7088 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -77,6 +77,17 @@ static int read_scaling_available_governors(char *scaling_available_governors,
     return 0;
 }
 
+static int get_cpufreq_cppc(unsigned int cpu,
+                            struct xen_get_cppc_para *cppc_para)
+{
+    int ret = -ENODEV;
+
+    if ( hwp_active() )
+        ret = get_hwp_para(cpu, cppc_para);
+
+    return ret;
+}
+
 static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
 {
     uint32_t ret = 0;
@@ -143,9 +154,7 @@ 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() )
-        ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
-    else
+    if ( !hwp_active() )
     {
         if ( !(scaling_available_governors =
                xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
@@ -165,29 +174,29 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
         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;
+        op->u.get_para.s.scaling_cur_freq = policy->cur;
+        op->u.get_para.s.scaling_max_freq = policy->max;
+        op->u.get_para.s.scaling_min_freq = policy->min;
 
         if ( policy->governor->name[0] )
-            strlcpy(op->u.get_para.u.s.scaling_governor,
+            strlcpy(op->u.get_para.s.scaling_governor,
                     policy->governor->name, CPUFREQ_NAME_LEN);
         else
-            strlcpy(op->u.get_para.u.s.scaling_governor, "Unknown",
+            strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
                     CPUFREQ_NAME_LEN);
 
         /* governor specific para */
-        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
+        if ( !strncasecmp(op->u.get_para.s.scaling_governor,
                           "userspace", CPUFREQ_NAME_LEN) )
-            op->u.get_para.u.s.u.userspace.scaling_setspeed = policy->cur;
+            op->u.get_para.s.u.userspace.scaling_setspeed = policy->cur;
 
-        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
+        if ( !strncasecmp(op->u.get_para.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);
+                &op->u.get_para.s.u.ondemand.sampling_rate_max,
+                &op->u.get_para.s.u.ondemand.sampling_rate_min,
+                &op->u.get_para.s.u.ondemand.sampling_rate,
+                &op->u.get_para.s.u.ondemand.up_threshold);
     }
 
     return ret;
@@ -385,6 +394,10 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         ret = set_cpufreq_para(op);
         break;
 
+    case GET_CPUFREQ_CPPC:
+        ret = get_cpufreq_cppc(op->cpuid, &op->u.get_cppc);
+        break;
+
     case SET_CPUFREQ_CPPC:
         ret = set_cpufreq_cppc(op);
         break;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index eb3a23b038..66c9b65465 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -478,22 +478,19 @@ struct xen_get_cpufreq_para {
     uint32_t cpuinfo_cur_freq;
     uint32_t cpuinfo_max_freq;
     uint32_t cpuinfo_min_freq;
-    union {
-        struct {
-            uint32_t scaling_cur_freq;
-
-            char scaling_governor[CPUFREQ_NAME_LEN];
-            uint32_t scaling_max_freq;
-            uint32_t scaling_min_freq;
-
-            /* for specific governor */
-            union {
-                struct  xen_userspace userspace;
-                struct  xen_ondemand ondemand;
-            } u;
-        } s;
-        struct xen_get_cppc_para cppc_para;
-    } u;
+    struct {
+        uint32_t scaling_cur_freq;
+
+        char scaling_governor[CPUFREQ_NAME_LEN];
+        uint32_t scaling_max_freq;
+        uint32_t scaling_min_freq;
+
+        /* for specific governor */
+        union {
+            struct  xen_userspace userspace;
+            struct  xen_ondemand ondemand;
+        } u;
+    } s;
 
     int32_t turbo_enabled;
 };
@@ -523,6 +520,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
@@ -547,6 +545,7 @@ struct xen_sysctl_pm_op {
     uint32_t cpuid;
     union {
         struct xen_get_cpufreq_para get_para;
+        struct xen_get_cppc_para    get_cppc;
         struct xen_set_cpufreq_gov  set_gov;
         struct xen_set_cpufreq_para set_para;
         struct xen_set_cppc_para    set_cppc;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128134.1468653 (Exim 4.92)
	(envelope-from )
	id 1v0uoE-0002aW-Qq; Tue, 23 Sep 2025 04:39:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128134.1468653; Tue, 23 Sep 2025 04:39: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 1v0uoE-0002aD-MN; Tue, 23 Sep 2025 04:39:22 +0000
Received: by outflank-mailman (input) for mailman id 1128134;
 Tue, 23 Sep 2025 04:39: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 1v0uoD-0000c8-G3
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:21 +0000
Received: from MW6PR02CU001.outbound.protection.outlook.com
 (mail-westus2azlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c007::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4475362e-9837-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 06:39:20 +0200 (CEST)
Received: from SJ0PR03CA0361.namprd03.prod.outlook.com (2603:10b6:a03:3a1::6)
 by DS7PR12MB9504.namprd12.prod.outlook.com (2603:10b6:8:252::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 04:39:15 +0000
Received: from SJ1PEPF000023DA.namprd21.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::47) by SJ0PR03CA0361.outlook.office365.com
 (2603:10b6:a03:3a1::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 04:39:13 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023DA.mail.protection.outlook.com (10.167.244.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:13 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:39:11 -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: 4475362e-9837-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MMCuuInmbuamk9pOmLikTSoVcGfXLZfioVcGYZ1G8XPtY7cB5KHsMK7Zkezyz/dAhi9SE52J72w+yQfBCdZ5CAj87PEjXu90KzXuWnwOjN3ejoQDha9p0be5+AetFBnMf2LIlgtLs3s3ydNGeOSC27J+3qhLTdoNve7aF8ToxSP1Yn2qmL6Tge5Yf8n3EeWdRf7E1GyBnQ/wRO0Izo90d+j60X79jR46YtHBpaVr+EpEXoQCZPoyW6FUKTejR/BrPAIaQsjA4Bxtxzytrd/XWek0AJ/kVqfepzzPDnDENnJyynZB3Z7DqbEVru/w0p0Nr89bu2S9BI+HfRAhCPfGoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iHSBHsvRkf7cyjctVbYI9tR84Fi9705tET1QVUrA2lg=;
 b=RWQc7fS4etCpAO52vDgkxYSSC7PLE+kM2K+4clS/ahHD4xJso+Che4PLrlA+fciQMBJw/zZFCZ2w1erl7H8oRHAk6koaWkiM801cs81XLbyN7kCv88YvZ1A4+Q4dQK43Jver7E4pfXc9WCIXu02YGlpCxyrU9yXzclmKacO5XXhDOjN/sPTRzoGWoQ4sSdcrz+1fQJOPucisdSd+C0xrLyFs8wCgT2w78ufRmCHPLKvtnHyWFrhw9aFJwgIrag5YwY3b7B6NALDiwZvbXO7mjqGrAnautqdkw4Y4wIz6LoWRCKMoCs7AsQfY/IjY9EFyckWLcmKCoklFm9EdMyIyrg==
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=iHSBHsvRkf7cyjctVbYI9tR84Fi9705tET1QVUrA2lg=;
 b=RtWaNKMXpvqkK4JgHd6bvuv2Gjp0nQj7+CBlEwfeP1+EJBOpH65Hat46xiGmd0oiTd7mI1B1tFzAUg+Grste3Om3V8sAANmrmVGfi5foll+xbaIdgQ3oQ5qQpr58pSyX3iPowCsKLVxzuSLQW29PSgqWFAu1vqzUWgSPQuTImTQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v10 8/8] CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq driver support
Date: Tue, 23 Sep 2025 12:38:26 +0800
Message-ID: <20250923043826.3831957-9-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023DA:EE_|DS7PR12MB9504:EE_
X-MS-Office365-Filtering-Correlation-Id: 945c1050-1902-4975-cd52-08ddfa5b25c2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?DV2wq/6a7htnZ1kQFolniRfI3bTrPvgpnDb/U/pK4YGr75e6v26QvKYASbIp?=
 =?us-ascii?Q?BlcGYARtCxI1/u7cK39CtBrxyOOyyOCvhY9YlNLivGuXkriTuWOmS39CH9GJ?=
 =?us-ascii?Q?cU7BgrZlx8f3gD6ogo0IBD5xtw175J+M6dWGRlfWOXa8gFYR2km1qvd7+/n0?=
 =?us-ascii?Q?PXRObi0B6Gfcs+QB+LCraIJFK/mXj3TBTjgpEldQC/sqPjIC9GQkE8+GAleL?=
 =?us-ascii?Q?JSXXj9n7/8RP8+YVfARg7aWybdsxsiOU/IxvbI9Q4gEM6JyNPpWtKih1wzV7?=
 =?us-ascii?Q?EfYbRH2lB3frE4US+S809t3dgCBDKwcXgKZIjss3qqczxV0KQKTJ2ljNGmtw?=
 =?us-ascii?Q?e8qwCLYR65DBDkd85wINUwaAzkYmwh/rQ+iSTF5umnTrnqiViqpYuPDVAWb5?=
 =?us-ascii?Q?H8vys6miiJhEga2I2q586fK3AT2uBonL83rB5H3hInVX1p8HDiWqxW/euvfq?=
 =?us-ascii?Q?cM8m+e+5P7z8H4mUb998DJ9n8mfVDMy0LPwAJ//Hd2AUjwP8USZn3IvXPN26?=
 =?us-ascii?Q?IXBM6T1bNDaMLSS5cOCLLZxbpZH/LwSZ3FWnYnAkOivtmTnLz68iWKvoHdlK?=
 =?us-ascii?Q?EgpTM6jfqnHY1DAAHgOfAJtb0ve63VKHf7FENjUlhDbHKvb/j2WKn1FSoHd6?=
 =?us-ascii?Q?9lKEA2KztIKXZ77IbbLFzuqBzX7+03dK69OvZPXG89pHIwlU2MlxXfS/dNiQ?=
 =?us-ascii?Q?fUDRLpurLQBgHzYhybJnqH2iLrHH62KWcVya9mLIiTLaGHfCOjCeyfa0UPS5?=
 =?us-ascii?Q?nmYBCMdcSA6JIQdvSvEkzp9ZGv/Kvr7y7J8dq0EtS+5A/AUKyB8QDaZhaH+q?=
 =?us-ascii?Q?fwcaalojecec62lQhS5zWJt2LMZ102lEjlC1iVmhSTkkUCauXQwfwfUqipNl?=
 =?us-ascii?Q?F8qLFzxFxpu01SDz+bvcJYx5K2YqCcf4zqjyc10FfM1wwV2OnrfyFYqncqvB?=
 =?us-ascii?Q?jY1aRPeiPsjMD796mo/FGlh9u1lBqLTEYgTOsVkhqoGCf7GPLmU4WgxLLgUz?=
 =?us-ascii?Q?RCvuI0dYA+HRozYmIQidzj2cuRKSOdzjPISsiSXS3GFbiTyTvMBuRERh6Rt/?=
 =?us-ascii?Q?8pHiDHMDiw0TtxGPBDZqpWYNKN7+acs4gW+0KohNnovgshVA50DqizFuQS7t?=
 =?us-ascii?Q?X/06Yp0jZoXVa7mFpl1q5IBogcDsNhigrs7EW+lVt0XEIMUsrXtLXwH6sCTk?=
 =?us-ascii?Q?U6sGUv/9chT9Gpf1vTlwC12+4xDQL1l38umqlJk448jJBP5KhImwesRgqHlW?=
 =?us-ascii?Q?hbwry+qIjJVVUHBYRxi6zJUO2HxW3ptjd0803udGQX6psiGHZejkkaCrK8tl?=
 =?us-ascii?Q?cSR+61Nt1VjcIl2YpwTBkqeKkR4bbBPggmW2A1KchdyJ5x0t9qz2tylaYDzy?=
 =?us-ascii?Q?skQFs0wqhjbP9cQWXafD3H5lgjHpz6NVbPvS3f/gecW1lejktXAGPO5A1GGO?=
 =?us-ascii?Q?sG/hVnE6T8EulD7BvLxdecWx5pwaxci617P8POp5wuQTkWAJCSL8Uw=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 04:39:13.7379
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 945c1050-1902-4975-cd52-08ddfa5b25c2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9504

Signed-off-by: Penny Zheng 
---
v9 -> v10:
- s/Support/New/ and add a full stop at the end
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ca1b43b940..7b9518ff08 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -36,6 +36,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
      Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
      and 28 (Temperature Probe).
+   - New amd-cppc/amd-cppc-epp cpufreq driver.
 
  - On Arm:
     - Ability to enable stack protector
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 04:39:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 04:39:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128135.1468659 (Exim 4.92)
	(envelope-from )
	id 1v0uoF-0002eQ-BX; Tue, 23 Sep 2025 04:39:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128135.1468659; Tue, 23 Sep 2025 04:39: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 1v0uoE-0002dG-W6; Tue, 23 Sep 2025 04:39:23 +0000
Received: by outflank-mailman (input) for mailman id 1128135;
 Tue, 23 Sep 2025 04: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 1v0uoD-00015C-UH
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 04:39:22 +0000
Received: from DM5PR21CU001.outbound.protection.outlook.com
 (mail-centralusazlp170110009.outbound.protection.outlook.com
 [2a01:111:f403:c111::9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 45275ce6-9837-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 06:39:20 +0200 (CEST)
Received: from SJ0PR03CA0374.namprd03.prod.outlook.com (2603:10b6:a03:3a1::19)
 by DS0PR12MB8246.namprd12.prod.outlook.com (2603:10b6:8:de::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 04:39:12 +0000
Received: from SJ1PEPF000023DA.namprd21.prod.outlook.com
 (2603:10b6:a03:3a1:cafe::de) by SJ0PR03CA0374.outlook.office365.com
 (2603:10b6:a03:3a1::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.19 via Frontend Transport; Tue,
 23 Sep 2025 04:39:12 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ1PEPF000023DA.mail.protection.outlook.com (10.167.244.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9182.0 via Frontend Transport; Tue, 23 Sep 2025 04:39:12 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 22 Sep 2025 21:39:09 -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: 45275ce6-9837-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qaoqWsz/5L5gZWwdXECJu7PEFTpDrQvFO9cXmLC+XFfRB1newC06nHGywQr6QCaH5bTioVD9aSW47Os0yjxcbZ3SY3dsAs1JHAmz0QK7aFE5ZWoG8Gy0m8//nqH4QkoLwfTERhNRJu7tUavzUO290nEgWC82aae+L8xqwz9rIL+fBHDaCIP/oKCo14nafTqj03qQoLY+FTAKCom7aG5SvSQ4ZnHllD9NmbNS/chFrHP1Iy8PJ+htBkzPKvWF9Kt1jK1yfr7KaSQOwAyaYZtAt1k+i/XXH+ghZvyAlzUep6mM7q+PW4lrNe2DseMzEOaza+ezQUVYM43FRvkF7UA57w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7srDNjX3Fozlujk+KvOJtuDAG4CLu0iQunF49gZwo4Y=;
 b=GO8jJVQf7c3MKgb9/QSRDhfgv+UiDjXTYFosFM8ou400onKjVfcpd346VXc+bcmwtWa1uPRFZRiMYBF7upA3Er3voSWUHipqX5jDzPdbFoBg5mE5auW0rwqmuTIGDFJwdrwOfQIWIhyibkLOn2eC6GLjU4LGeC0HikE1hLC4GajT6CeXnk9sfgNDefYUhZMO3Ynn5NJErpI3ZIHd/3lHGwqiLqvRVEpnyP0ot5xjMu9d3hq7EjzPxFJ1IBpfe8dPQHhTNjzSf1VFaLZpjDV/5JYUqevY1JVdhYRZ5KG+U+G7Fbay3vr9jrxP+XXyNRxOa0FL2ETYM1oLDPDPb3WeBg==
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=7srDNjX3Fozlujk+KvOJtuDAG4CLu0iQunF49gZwo4Y=;
 b=ft7cka4vx5CKM7zDkDmlz4nDKU3rDgRJYyNAmkLET89KdYPV+4xF70QCmeKT7YyoK30h7ut+4/mR4+6HoHhRIyUH5514uQ7L7J4l/JNW4wP8b95NHZ6vqKs4NQ8inNmxzFnOv48PDd8rzrE1CyfyZsVd0a+7mw0+aHJeCS4qI4E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	
Subject: [PATCH v10 7/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver
Date: Tue, 23 Sep 2025 12:38:25 +0800
Message-ID: <20250923043826.3831957-8-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250923043826.3831957-1-Penny.Zheng@amd.com>
References: <20250923043826.3831957-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023DA:EE_|DS0PR12MB8246:EE_
X-MS-Office365-Filtering-Correlation-Id: 167bf80e-54d2-4add-b1dc-08ddfa5b24c9
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?U+O331bLXyaieYjuG2JwYrnjyznqYmSdZMI0j7tU6eofd7u9BBtR2wH1+FnS?=
 =?us-ascii?Q?pK2hr57yDzjk4r3JFb+RbH4LYIANNInihLioMDPiJRz31pShr1iR71iaa1yZ?=
 =?us-ascii?Q?9RCkkfOq+jyrINPKABg+FhnRraGq63Z0R+Rnsm97R04Nh5lVcKl1tCWrbOmD?=
 =?us-ascii?Q?NpPn8Eq46nuxkqy6NkLS9tEXd67AuTviSi/aMrly2ZNBb0kU6LBnnWHxw6n6?=
 =?us-ascii?Q?0dULUlk3Scld7AdU7Xz4jQqiAP6Qzafs6tqq0XVJta3u2xZtNU6vGRYdHNo1?=
 =?us-ascii?Q?rEbF1fGwBCXlgXcSlMoBSs/KDJrxnX2sG5in6OIRT3nzVGkP1qnZpF6MVWRn?=
 =?us-ascii?Q?hArnLFCVKil7Z0XQyXjO18xOTes84QXNZQBbhq7dy4cYlmwViwUVX5xyoOm7?=
 =?us-ascii?Q?KukJd/48GCf55DCz3cNyc9ucZRx/JhzdYsuk8ajgc1yPXBZPmvkPJvvYB93F?=
 =?us-ascii?Q?uIQfJ4pIw3WEEgHTfvFzMNcxp+ZmUjUQT1uC39OKbuv5yYIwL1cieMQjQPYo?=
 =?us-ascii?Q?8ueEGBWVBVxxly3E+4D59zvBDB5EjLefBr3JnzwDtSn0A9aNvZ8aJ2dEkC67?=
 =?us-ascii?Q?z2lSWLftXykInatjt5fneYRwZGa+2c3rvZ47onoqfh4AlEIXeALkV/Oepx7S?=
 =?us-ascii?Q?kONwdWoOM4AYVmjot38MXm5Jehb9P8lN2zMeRICH71BNE0CfXycmOJMucLlB?=
 =?us-ascii?Q?897LQx6NB1R/KjUxdx64gNTHnDaiKEvbOxV2P+MzOgtk80GuvhnqG7hvIl0W?=
 =?us-ascii?Q?9OkyZS6ER5Xgqo8woRefRGf8uwZEqsw+dN166f0FK2K33r0ZJHBtBKgyA442?=
 =?us-ascii?Q?PhaChKDidOTbyWGR0+tSTbvsXtnXiDBSVuG1XYjyFUTZVZ7yydu47HVkSaFW?=
 =?us-ascii?Q?d0eHJgzlANLELubn7z1M+5STlYkkKOkU3+j0HOGfd5Nl6lHdH2RfjCa+lquO?=
 =?us-ascii?Q?wYJB8oh+vF5yVovI03BLyUIo7GqfDDGroVaX7glOZlU6Tiwu9th974d/LjLo?=
 =?us-ascii?Q?L7k/uVhvNaOK1NSUpIWQ+MmIMtsQVcycRxI2PRO75YezbamWPsq91Lhkh+3J?=
 =?us-ascii?Q?vvN8ipYppR3sKYwHdOzV1yW8cIxmHoXaHqP8WmhAwUdqQXrM2290CgDrQpEm?=
 =?us-ascii?Q?uqQkSOuKG/zdIzk7GjYZ1af7SMF1Fol5KXNWYXKuDwtwEM5Rz3yZfIqmWwDs?=
 =?us-ascii?Q?pryXBOCS2n7VHVndAm/CVqJpUXXhVvg77CM6LC/lHbgbwZPms2otIkSAjZbu?=
 =?us-ascii?Q?awcf/rF1uo9NuuXhfLO+TN25wlvcpgGwE9GcdNG8Nk7zI5M8eV5IwJtxttc7?=
 =?us-ascii?Q?0LUautLhwNpjxiZYfgLAa54ymlZnDXP3hOM9lR9kkmIFqvn4Cu1X4FndkgcB?=
 =?us-ascii?Q?YXeRDV+epClcH6eX5ZglhzP+A++FnUJ1CtBKB9XmKgESu8np/rlhUe9hPUrK?=
 =?us-ascii?Q?O++o4r8p2V+QKx9Q9ksNUnAac4zTuGcSwwo53OGQ2NV0s/Sb4idinw64sgoI?=
 =?us-ascii?Q?u3QMPXCCMFVMN/wBULRMVS403s8OIU4tZn/W?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 23 Sep 2025 04:39:12.1302
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 167bf80e-54d2-4add-b1dc-08ddfa5b24c9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8246

Introduce helper set_amd_cppc_para() and get_amd_cppc_para() to
SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.

In get_cpufreq_cppc()/set_cpufreq_cppc(), we include
"processor_pminfo[cpuid]->init & XEN_CPPC_INIT" condition check to deal with
cpufreq driver in amd-cppc.
We borrow governor field to indicate policy info for CPPC active mode,
so we need to move the copying of the governor name out of the
!cpufreq_is_governorless() guard.

Signed-off-by: Penny Zheng 
Acked-by: Anthony PERARD 
---
v1 -> v2:
- Give the variable des_perf an initializer of 0
- Use the strncmp()s directly in the if()
---
v3 -> v4
- refactor comments
- remove double blank lines
- replace amd_cppc_in_use flag with XEN_PROCESSOR_PM_CPPC
---
v4 -> v5:
- add new field "policy" in "struct xen_cppc_para"
- add new performamce policy XEN_CPUFREQ_POLICY_BALANCE
- drop string comparisons with "processor_pminfo[cpuid]->init & XEN_CPPC_INIT"
and "cpufreq.setpolicy == NULL"
- Blank line ahead of the main "return" of a function
- refactor comments, commit message and title
---
v5 -> v6:
- remove duplicated manifest constants, and just move it to public header
- use "else if" to avoid confusion that it looks as if both paths could be taken
- add check for legitimate perf values
- use "unknown" instead of "none"
- introduce "CPUFREQ_POLICY_END" for array overrun check in user space tools
---
v6 -> v7:
- use ARRAY_SIZE() instead
- ->policy print is avoided in passive mode and print "unknown" in invalid
cases
- let cpufreq_is_governorless() being the variable's initializer
- refactor with the conditional operator to increase readability
- move duplicated defination ahead and use local variable
- avoid using "else-condition" to bring "dead code" in Misra's nomeclature
- move the comment out of public header and into the respective internal
struct field
- wrap set{,get}_amd_cppc_para() with CONFIG_PM_OP
- add symmetry scenario for maximum check
---
v7 -> v8:
- change function name to amd_cppc_get{,set}_para()
- fix too deep indentation, and indent according to pending open parentheses
- missing -EINVAL when no flag is set at all
- use new helper amd_cppc_prepare_policy() to reduce redundancy
- borrow governor field to indicate policy info
---
v8 -> v9
- add description of "moving the copying of the governor name"
- Adapt to changes of "Embed struct amd_cppc_drv_data{} into struct
cpufreq_policy{}"
---
v9 -> v10
- adapt to changes of "dropping outter union"
- rewind changes in v8
---
 tools/misc/xenpm.c                   |  13 ++-
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 164 +++++++++++++++++++++++++++
 xen/drivers/acpi/pm-op.c             |  28 +++--
 xen/include/acpi/cpufreq/cpufreq.h   |   4 +
 4 files changed, 196 insertions(+), 13 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 682d092479..1f3c104cfc 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -832,11 +832,14 @@ static void print_cppc_para(unsigned int cpuid,
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
-    bool is_governor_less = false;
+    bool is_governor_less = false, is_cppc_active = false;
     int i;
 
-    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
-         !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+    if ( !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+        is_cppc_active = true;
+
+    if ( is_cppc_active ||
+         !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) )
         is_governor_less = true;
 
     printf("cpu id               : %d\n", cpuid);
@@ -899,6 +902,10 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
                p_cpufreq->s.scaling_cur_freq);
     }
 
+    /* Translate governor info to policy info in CPPC active mode */
+    if ( is_cppc_active )
+        printf("policy               : %s\n", p_cpufreq->s.scaling_governor);
+
     printf("turbo mode           : %s\n",
            p_cpufreq->turbo_enabled ? "enabled" : "disabled or n/a");
     printf("\n");
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index bb7f4e4a9e..eca455240f 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -566,6 +566,170 @@ static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
     return 0;
 }
 
+#ifdef CONFIG_PM_OP
+int amd_cppc_get_para(const struct cpufreq_policy *policy,
+                      struct xen_get_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->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 amd_cppc_set_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, epp;
+    bool active_mode = cpufreq_is_governorless(cpu);
+
+    if ( data == NULL )
+        return -ENOENT;
+
+    /* 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;
+
+    /* Return if there is nothing to do. */
+    if ( set_cppc->set_params == 0 )
+        return 0;
+
+    /*
+     * Validate all parameters
+     * Maximum performance may be set to any performance value in the range
+     * [Nonlinear Lowest Performance, Highest Performance], inclusive but must
+     * be set to a value that is larger than or equal to minimum Performance.
+     */
+    if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
+         (set_cppc->maximum > data->caps.highest_perf ||
+          (set_cppc->maximum <
+           (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM
+            ? set_cppc->minimum
+            : data->req.min_perf))) )
+        return -EINVAL;
+    /*
+     * Minimum performance may be set to any performance value in the range
+     * [Nonlinear Lowest Performance, Highest Performance], inclusive but must
+     * be set to a value that is less than or equal to Maximum Performance.
+     */
+    if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
+         (set_cppc->minimum < data->caps.lowest_nonlinear_perf ||
+          (set_cppc->minimum >
+           (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM
+            ? set_cppc->maximum
+            : data->req.max_perf))) )
+        return -EINVAL;
+    /*
+     * Desired performance may be set to any performance value in the range
+     * [Minimum Performance, Maximum Performance], inclusive.
+     */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+    {
+        if ( active_mode )
+            return -EOPNOTSUPP;
+
+        if ( (set_cppc->desired >
+              (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM
+               ? set_cppc->maximum
+               : data->req.max_perf)) ||
+             (set_cppc->desired <
+              (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM
+               ? set_cppc->minimum
+               : data->req.min_perf)) )
+            return -EINVAL;
+    }
+    /*
+     * Energy Performance Preference may be set with a range of values
+     * from 0 to 0xFF
+     */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
+    {
+        if ( !active_mode )
+            return -EOPNOTSUPP;
+
+        if ( set_cppc->energy_perf > UINT8_MAX )
+            return -EINVAL;
+    }
+
+    /* Activity window not supported in MSR */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
+        return -EOPNOTSUPP;
+
+    des_perf = data->req.des_perf;
+    /*
+     * Apply presets:
+     * XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/ONDEMAND are
+     * only available when CPPC in active mode
+     */
+    switch ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_PRESET_MASK )
+    {
+    case XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE:
+        if ( !active_mode )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_POWERSAVE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
+        if ( !active_mode )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_PERFORMANCE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_ONDEMAND:
+        if ( !active_mode )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_ONDEMAND;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
+        if ( active_mode )
+            policy->policy = CPUFREQ_POLICY_UNKNOWN;
+        break;
+
+    default:
+        return -EINVAL;
+    }
+    amd_cppc_prepare_policy(policy, &max_perf, &min_perf, &epp);
+
+    /* Further customize presets if needed */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM )
+        min_perf = set_cppc->minimum;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM )
+        max_perf = set_cppc->maximum;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
+        epp = set_cppc->energy_perf;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+        des_perf = set_cppc->desired;
+
+    amd_cppc_write_request(cpu, min_perf, des_perf, max_perf, epp);
+
+    return 0;
+}
+#endif /* CONFIG_PM_OP */
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index 4cca42c4fc..ed4e0d4335 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -84,6 +84,8 @@ static int get_cpufreq_cppc(unsigned int cpu,
 
     if ( hwp_active() )
         ret = get_hwp_para(cpu, cppc_para);
+    else if ( processor_pminfo[cpu]->init & XEN_CPPC_INIT )
+        ret = amd_cppc_get_para(per_cpu(cpufreq_cpu_policy, cpu), cppc_para);
 
     return ret;
 }
@@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     else
         strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
 
+    /*
+     * In CPPC active mode, we are borrowing governor field to indicate
+     * policy info.
+     */
+    if ( policy->governor->name[0] )
+        strlcpy(op->u.get_para.s.scaling_governor,
+                policy->governor->name, CPUFREQ_NAME_LEN);
+    else
+        strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
+                CPUFREQ_NAME_LEN);
+
     if ( !cpufreq_is_governorless(op->cpuid) )
     {
         if ( !(scaling_available_governors =
@@ -178,13 +191,6 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
         op->u.get_para.s.scaling_max_freq = policy->max;
         op->u.get_para.s.scaling_min_freq = policy->min;
 
-        if ( policy->governor->name[0] )
-            strlcpy(op->u.get_para.s.scaling_governor,
-                    policy->governor->name, CPUFREQ_NAME_LEN);
-        else
-            strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
-                    CPUFREQ_NAME_LEN);
-
         /* governor specific para */
         if ( !strncasecmp(op->u.get_para.s.scaling_governor,
                           "userspace", CPUFREQ_NAME_LEN) )
@@ -321,10 +327,12 @@ static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
     if ( !policy || !policy->governor )
         return -ENOENT;
 
-    if ( !hwp_active() )
-        return -EOPNOTSUPP;
+    if ( hwp_active() )
+        return set_hwp_para(policy, &op->u.set_cppc);
+    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+        return amd_cppc_set_para(policy, &op->u.set_cppc);
 
-    return set_hwp_para(policy, &op->u.set_cppc);
+    return -EOPNOTSUPP;
 }
 
 int do_pm_op(struct xen_sysctl_pm_op *op)
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 7caeae26cf..e8b4e955a2 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -293,6 +293,10 @@ int acpi_cpufreq_register(void);
 
 int amd_cppc_cmdline_parse(const char *s, const char *e);
 int amd_cppc_register_driver(void);
+int amd_cppc_get_para(const struct cpufreq_policy *policy,
+                      struct xen_get_cppc_para *cppc_para);
+int amd_cppc_set_para(struct cpufreq_policy *policy,
+                      const struct xen_set_cppc_para *set_cppc);
 
 /*
  * Governor-less cpufreq driver indicates the driver doesn't rely on Xen
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 05:21:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 05:21:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128044.1468673 (Exim 4.92)
	(envelope-from )
	id 1v0vT9-0003hB-Lr; Tue, 23 Sep 2025 05:21:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128044.1468673; Tue, 23 Sep 2025 05: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 1v0vT9-0003h4-Iu; Tue, 23 Sep 2025 05:21:39 +0000
Received: by outflank-mailman (input) for mailman id 1128044;
 Mon, 22 Sep 2025 21:04: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 1v0nhw-0006fE-Ds
 for xen-devel@lists.xenproject.org; Mon, 22 Sep 2025 21:04:24 +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 b48d2bcf-97f7-11f0-9809-7dc792cee155;
 Mon, 22 Sep 2025 23:04:19 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b2fcfef5600so29458566b.3
 for ; Mon, 22 Sep 2025 14:04: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: b48d2bcf-97f7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758575058; x=1759179858; 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=uh7Hyul+h5lwAcNtxj/DI9qojjFccIciQ/b88SlaL0g=;
        b=CTol6M01TfvgNYX9ev8PGdJ4bjKLF7a3ZZv9QyBfRuVRIaOK4TXfUk5SurgC3XQgYG
         ako3VMN7tGM80G1Zz0bb78IAfpRggew7XgoJ81bFQMZpdLM0N9AveqiIRSx4hMFl6QCX
         Pc7vCuBkdr8/zeMDRLdjXTi422BL2HKSTHx7jkkCCLp6kNHP+AkkPR1hl30Q6HtVg2Jg
         MDx2TLYJw9GayujrFE4t63zoV/+6TuN14au94dZ5GOTpoqYQ2PBR8/AmOk3UzRApR07I
         B2lJnhb4uz4jaCKQH5yRMa2x53M7/Lsi9NMerXHS/cdT3XmxkwMiLf4PnwEdnDLf5h5p
         nZBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758575058; x=1759179858;
        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=uh7Hyul+h5lwAcNtxj/DI9qojjFccIciQ/b88SlaL0g=;
        b=VVazWcb/8JayU2YxYsV5EsBlV1PYK07Xl92XavPW8/PjDj/w4zsQbGK4VG0M7w4htZ
         QLLE1QHJuk8TVHCc4ySYO39n1sHiFTNDrsRUAuBEz2FxQdyXbWBrCKj1KpPpFnL7ftCA
         tiRTTYkcRxvN51sXPfu8Zff1adv4oHkTNSh9Mo1WjJ3/imBU0Gqw6T8Bqs+pP+qDWNBk
         kx/71NHxylVex8625pjwNaoHR2rUk9Ky7oEvzFZShGWOwEhK0CpSZBnklVXwFkSTfofS
         5dFWsPUr1JuRXU6BpYdxA2qYi9RAs7cV9l/I76r3yAw5Y9U8EpDaX8RVsYsyUVgAKk+u
         dbIA==
X-Forwarded-Encrypted: i=1; AJvYcCV2hqiaP8pwoKKYOUhbTrqiWJFB0jfyI08a6Ma3LA4jxpou95c3cDTv1KNvMpXD0J0imb/VxRhp+lE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQh7CctDsRgbJmQfXGChuMGeMsx97LspgZ/ERZUWfkENUrnY2H
	Si5m8OR2IkbDln/wb0DI8e0GEAA4eLfNJIPsYbOqfxVFppxMWtTT+kjMFJ20OeKCBDlcFgOrV5d
	lw7K6PoEhnHDWtpGy2QkGOoEFLhCkcAg=
X-Gm-Gg: ASbGncsqufJo6Dq/qnfaXOhX7gWQO0r81DYXyAr6c0asosGwde1FWHoL1PUPC9UTqEG
	xAInZkgeplDSLKq8udW4RGVQnIrYjGqJXBs7EPNChuQMpIvENRSjQOrp2H7qR+9rjSLXHf9jLlp
	rAq6gwIAprRWSUW2Ehma5WmvLY7MFy6tgjZZKLNqwejNKhiHLKRqtRFwGhRNTm+OMhYxDwv73EG
	yYQbkXAC0sXB7VUuLc=
X-Google-Smtp-Source: AGHT+IFr06URzpJ6aUp4DpRFc3gqIF/QKzvPatkXOguRNAK+5vyBht27Wi77YYUi7cw/QJFO8eHWzN6Nc8/pR3lh7aU=
X-Received: by 2002:a17:907:72cb:b0:afe:d590:b6af with SMTP id
 a640c23a62f3a-b3026c84e0cmr5356866b.20.1758575058272; Mon, 22 Sep 2025
 14:04:18 -0700 (PDT)
MIME-Version: 1.0
References:  <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
In-Reply-To: <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
From: Magnus Lindholm 
Date: Mon, 22 Sep 2025 23:04:06 +0200
X-Gm-Features: AS18NWDVFMZZnWEreuo7vPXyYUB8RQkWA0R_TESbZnVi7LcEMvax5dEHcVzVJVI
Message-ID: 
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical address
To: Leon Romanovsky 
Cc: Marek Szyprowski , Leon Romanovsky , 
	Jason Gunthorpe , Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 18, 2025 at 8:45=E2=80=AFPM Leon Romanovsky  w=
rote:
>
> From: Leon Romanovsky 
>
> Alpha doesn't need struct *page and can perform mapping based on
> physical addresses. So convert it to implement new .map_phys callback.


Hi,

SInce this patch affects the Alpha platform I got curious and decided to
try it out. The patch series requires some preparatory patches. Leon
provided me with links to his dmabuf-vfio branch, which had the
patches (and some prerequisite stuff) applied already.

Based on the dmabuf-vfio branch,  I've built a kernel and tested it on
my ES40 Alphaserver, the kernel booted fine but after a while of
moderate filesystem load I started seeing some ext3/4 related error
messages in the system logs. Rebooting with my old kernel into
single user mode, I was able to recover the filesystem using fsck.
Clearly this set of patches breaks things (at least on Alpha).

I haven't yet dug any deeper into the root causes of the file system
corruptions and I've only tested this on Alpha, maybe there has been
more testing done on other platforms targeted by this set
of patches?

Regards

Magnus Lindholm


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 08:09:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 08:09:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128273.1468684 (Exim 4.92)
	(envelope-from )
	id 1v0y5J-0005YV-5A; Tue, 23 Sep 2025 08:09:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128273.1468684; Tue, 23 Sep 2025 08:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0y5J-0005YO-0x; Tue, 23 Sep 2025 08:09:13 +0000
Received: by outflank-mailman (input) for mailman id 1128273;
 Tue, 23 Sep 2025 08:09: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 1v0y5G-0005YF-WD
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 08:09:11 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 905a4096-9854-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 10:09:02 +0200 (CEST)
Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com
 [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-668-0Qnh4dR9N_yVTwvC7su1nA-1; Tue, 23 Sep 2025 04:08:59 -0400
Received: by mail-ej1-f69.google.com with SMTP id
 a640c23a62f3a-b07cc3f115aso472526666b.3
 for ; Tue, 23 Sep 2025 01:08:59 -0700 (PDT)
Received: from [192.168.10.48] ([176.206.127.188])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-633148d2df3sm4465772a12.30.2025.09.23.01.08.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 23 Sep 2025 01: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: 905a4096-9854-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758614941;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cyh9GNwkSeiWX8VVWJet6cmrStrv1Y1BhHYKMAKCy08=;
	b=HHzI4akrgCC51lUxlU6IJ39vedVTf3gBdJBOX2YNY/n7M9iiYo1OiCFznxC5U9qaOFbEMv
	KwwWwaA9Y8abP1I1+mIirvJFLnev4Q164HA7yqZ94EacsxOP+PCGL81Q72DC23ogkqaCJ2
	C4eDHsKhWtAYExkE+hC1RC9+DZle020=
X-MC-Unique: 0Qnh4dR9N_yVTwvC7su1nA-1
X-Mimecast-MFC-AGG-ID: 0Qnh4dR9N_yVTwvC7su1nA_1758614939
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758614938; x=1759219738;
        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=cyh9GNwkSeiWX8VVWJet6cmrStrv1Y1BhHYKMAKCy08=;
        b=oGNw8+fKOH6iCdBgEx6L7jjUTI41VA69ZIzT/svM7bmoUsbnI9KVZkrQIpgQjZlx/l
         7vIPSYUJjP6jAM/q58pQwghLoIFlvCKl9dw8EeWsLrwtzCmDMTTZHOH88HemIyf9Xuju
         Uo5Y/YJk0PP18CAFu1+6TuOBzb+JgRNf3LWkfU6JZW0kHHAzbnKe4M7bYOAIBy5F+M1O
         bChWABV9HY1LAW9oopG3e1Xn/BF1lfSTMHMWOqdY5I5xvDe39+AZcEba+OeUSQXI7RbO
         XwH8gWCKIjCk8P2kLIoENPZEgb4ArcEGhkoo9ogJO5JmolR+K3vmlS3ivIFd8MlrEwpv
         MGTA==
X-Forwarded-Encrypted: i=1; AJvYcCWy8urwFn/G958/oKtW2AtO532HbnVPj//OmYYnFXZj5iDHXY56Lad6zOa8dhF/enXn1jLlYnY3d6Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxdc50jEZpivugilJcIDVqIlmiDld7SUag9gtv086A/eM32/5qq
	fFh2ZWEPtqlfd2XAj5tz9wGMHzb9wf8G1UbUwPYxaPKK/sl76WSVsPRPzcl+4d4LRWxnBFa09fA
	ciAvDtxUdM0vCd1+wvUCt/SDkaR0dRbXJAQ5/0KeuGyUuPdWk7spudo3scXrGmepq4GOm
X-Gm-Gg: ASbGncsR7+xyDVhV19GdCwBGqHcdah031x2Hak+YSYyGeR3QcUz1tGmv+5OL7uvFWKK
	WWLzk9YRUVmiZGAKay0KwDkXZNQPg1aB2O+d81MLyu7so7ptddQibs9ZDC2/qcLmh91rJIOqnz3
	l/bNrOJkfXJ22va/eF3Onc6OeLSGd2IUZ7As2/GnFmW4A44WOrdnBNH3lymJKX4HsqX2YDcYylt
	OH8cezRhsWgoByCfeQ0alhpdl9SfxVcFvCR+rzSP95Pe9UFhdWxNSmbA6UqgS5NDYgFEnfV48hS
	vMDCfVM/FgtJcVx4igz91ZRrUjMOhTUxNrS3lXplfZ2nHKLkVPf0HaVz3s+CuQWlwRXYbfW9ydx
	0TRhl3tM5WK+OWtyjeK88Nnu5ZBMlHOugpvxZb9nWCa5RmQ==
X-Received: by 2002:a05:6402:5041:b0:633:9e:4036 with SMTP id 4fb4d7f45d1cf-6346778e1b9mr1374753a12.11.1758614938530;
        Tue, 23 Sep 2025 01:08:58 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGfEVzMzlegsS8RRRWXf5AuMiTyV3RuuZ4ChXwgv3Yn5mo7kYPCIJoERh+giB7/42ECgMCO6g==
X-Received: by 2002:a05:6402:5041:b0:633:9e:4036 with SMTP id 4fb4d7f45d1cf-6346778e1b9mr1374717a12.11.1758614938103;
        Tue, 23 Sep 2025 01:08:58 -0700 (PDT)
From: Paolo Bonzini 
To: Akihiko Odaki 
Cc: qemu-devel@nongnu.org,
	Alex Williamson ,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= ,
	=?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= ,
	Eduardo Habkost ,
	Peter Xu ,
	David Hildenbrand ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Richard Henderson ,
	Helge Deller ,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= ,
	"Michael S . Tsirkin" ,
	Gerd Hoffmann ,
	John Snow ,
	qemu-block@nongnu.org,
	Keith Busch ,
	Klaus Jensen ,
	Jesper Devantier ,
	Marcel Apfelbaum ,
	Nicholas Piggin ,
	qemu-ppc@nongnu.org,
	John Levon ,
	Thanos Makatos ,
	Yanan Wang ,
	BALATON Zoltan ,
	Jiaxun Yang ,
	Daniel Henrique Barboza ,
	David Gibson ,
	Harsh Prateek Bora ,
	Alexey Kardashevskiy ,
	=?UTF-8?q?Alex=20Benn=C3=A9e?= ,
	Fabiano Rosas ,
	Thomas Huth ,
	Laurent Vivier ,
	Peter Maydell ,
	Aurelien Jarno ,
	Aleksandar Rikalo ,
	Max Filippov ,
	=?UTF-8?q?Herv=C3=A9=20Poussineau?= ,
	Mark Cave-Ayland ,
	Artyom Tarasenko ,
	Alistair Francis ,
	"Maciej S . Szmigiero" ,
	Bin Meng ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E . Iglesias" ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Date: Tue, 23 Sep 2025 10:08:53 +0200
Message-ID: <20250923080853.94322-1-pbonzini@redhat.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
References: 
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: dCc1UqQ-JHwdxpzX4-S8mTl9fAEMLxv9d_RO7Uq6qR0_1758614939
X-Mimecast-Originator: redhat.com
Content-Transfer-Encoding: 8bit
content-type: text/plain; charset="US-ASCII"; x-default=true

Queued, thanks.

Paolo



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 08:20:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 08:20:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128285.1468693 (Exim 4.92)
	(envelope-from )
	id 1v0yFk-0007BX-30; Tue, 23 Sep 2025 08:20:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128285.1468693; Tue, 23 Sep 2025 08: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 1v0yFj-0007BQ-Vn; Tue, 23 Sep 2025 08:19:59 +0000
Received: by outflank-mailman (input) for mailman id 1128285;
 Tue, 23 Sep 2025 08:19: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 1v0yFi-0007BK-AT
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 08:19:58 +0000
Received: from PH7PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170100009.outbound.protection.outlook.com
 [2a01:111:f403:c107::9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15b70326-9856-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 10:19:56 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SJ2PR12MB8160.namprd12.prod.outlook.com (2603:10b6:a03:4af::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.20; Tue, 23 Sep 2025 08:19: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%6]) with mapi id 15.20.9137.017; Tue, 23 Sep 2025
 08:19: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: 15b70326-9856-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uNzMKpqyvE6DgsoQ90OHb55nVF0RhTuaZ0l8Vz4EKTOBkafpQFNRHAmn3nucYXFqnJ2D9mDxDn5hwtoETeshL1+qkN/D9+Yd3P2nYw91ac7HeS5OugmkDMsVTE4xyrQ8SO0sarD+GWnq3FmsS9/tby5DkccIF2BjbjjJV8m4cdoGgUNnyQPp+1i+ajmfbczmPb1K6J/byiUkehZefBjAFAZrkzapfidQRq2PwwPqYO5eUhkWTp3K69dAvb1bxbwZ9y9V2u4R7HJuTebMe2wtuPlPBYqQXNQ/Yn6p8VVcpEYLFcFWL6p5QWjivy8B60nK+3lfvLEKBggBlhluwk3VyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FGBIt+yqnDvo4Z89ejw7xFiF0qp1iXvx2DrNNYc/YfA=;
 b=q83YbKpkzHMzUFRld0bp/x+cUxbxgIW3BjTJ4rSdEP0P0fGrql3K8CYQBNr9Wpe5etJtFVEP/fHzBwVyN5Fmu1lIGCV7sN0hX0aR8ykzMRSGlA90EBZsZOCGzpwNRwWzPGCUv2ab/kEjgZYXcXTgZy/G50yay4Ii/wK9bXLBVakTgcs2v4hjD9jrU5MqXgysxv+YC1cJTnaG0SAkH5ZpevSeJqxspOMc6gZCsy9i2PGJYKTKd5vV8jIdl6i5m8REFNa6cAGMyBbCzBQYLtO2PktrdjXNyitTb2ePM05KH86gbFAhF7nDO7NNZcTT0kt+jgEpDW6hgv5brswq0f5+yg==
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=FGBIt+yqnDvo4Z89ejw7xFiF0qp1iXvx2DrNNYc/YfA=;
 b=eEvymT9BkdBzvILcImD7roGnSTbw8pDpN/OcoN8JQco49RGP2JzPcunBSnoeTYK85KPXH3fogAN++ZgbEGOX67sLib2KzN36d5ar8pd7n/QVMVtv9gCagLN9ww0jCSoV9lh6eBWjx7JKxPhjkV6f1v/bAPZId33ORIUiO0n26co=
From: "Penny, Zheng" 
To: Jan Beulich , Tamas K Lengyel 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Alexandru Isaila , Petre
 Pircalabu , "xen-devel@lists.xenproject.org"
	, Oleksii Kurochko
	
Subject: RE: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
Thread-Topic: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
Thread-Index: AQHcI6ElsmPyKgPhO0m7bb5S2YBG5bSPJskAgBE+WYA=
Date: Tue, 23 Sep 2025 08:19:51 +0000
Message-ID:
 
References: <20250912045254.3731398-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-09-23T08:19:44.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_|SJ2PR12MB8160:EE_
x-ms-office365-filtering-correlation-id: a31bc470-ee9b-4b8c-6130-08ddfa79f7f6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?RmxNa3FtUjNHeThpYmk3QTJ3WHMycXdMQlM5MTIrS2s2YmNjZkl0Uy9PMWR1?=
 =?utf-8?B?ZXdKKy9ZTVdjM2l2VlRDbW8zVDVxYU1VcnNRQUxPeDZZQ0s1Y3ZQY0pGUU54?=
 =?utf-8?B?NExySjR0L3hxZmhoc3hwc3ZuTEVRUi9heUMrR2g4d21rMnVQUjZUd1RIa0JX?=
 =?utf-8?B?UTRSTVRTSDBtRWVHTUhjZU9zeVBQQkdvYldFNGcwei91a0Y3TXNxSWcybGNi?=
 =?utf-8?B?bjdTMHNvNGZFdlcreDhwTHArL3dnbERBcGpPTmhuN2UrQzlkRXFUMEZJR0po?=
 =?utf-8?B?UVMyQktHMzhxTC9pMzRiVTZLcXBmWXJobG1pS1hjNVI4TldWMUN5aGxmcW05?=
 =?utf-8?B?elkwK3U1WXlDVGFMbEFBZkxvQUlvMllUUFozMGduOUloQjgwQWF3YjRPczVC?=
 =?utf-8?B?QUVGbGw5SERNNGlyeFhLZ2ZodmlkZG9KUFg5SVRiVnRBdFN2UkttOUpxbExM?=
 =?utf-8?B?dHROTlZObmVHSEgzR1M3RGVFUkJDOVVUNnpwT0hwNGRGT0dyaGtVZTczSDFX?=
 =?utf-8?B?eUc5Z1NuYkQ2bHZSMW9YMUJiYUxTdWtwUkpMZ0F2KzVhYThRVFJJK1hQS1dC?=
 =?utf-8?B?bWRkLy9qS2hvKysvUVZZOFA0WUtWVE52WDVvU0JUUmtQbGdqcmZzZ2VhMklZ?=
 =?utf-8?B?MlNGcUZkT3BoMmtSU0FtYlVVaUFvQjZVcWJDdWhhd0JBSllaeVE3T043WFJC?=
 =?utf-8?B?Z1g0R3ZwT2hHS0VnUUdGYXMzSGpBcUxubVI2NHNaTlF0SW9lMW81QXBybWVk?=
 =?utf-8?B?ODlldVF6SGtwYnVXbTlyRDMraWgrVWtNbGhwSjJSSy8weHBzMy84a3krakNn?=
 =?utf-8?B?cjZEbG54OCtWbjVWVzZEbVBqYWRoUURzYU5DMExDTG5zSGZjcG1yU3ViM2d2?=
 =?utf-8?B?ak44dlpZR2VRMUVrSFpkODRsaE9QM09sRXBjVkc4bjFmejZTMWlNcHFEM2F3?=
 =?utf-8?B?c2xMcGVRTTJlTFBuejVEZ2k4ZzhseTFpUEVHY2RIUExaSHRVYmpxSk54QTNF?=
 =?utf-8?B?MmVCQUNIZXZHWHFPblRZMnpnOU9qYmJCNHc3cG11N051V1VCREZFaldCYWU1?=
 =?utf-8?B?ZjlUaVNnTHh1M0hXMkZFSTM2S1BWN2FBeEhrTTFTdFFadUpGMlIvQ1FiNTJ5?=
 =?utf-8?B?OEVuMUNQaWJFUE8wMm1BNmZ6YjBEYVBsUm9Ra3UvelcxY3FGU2RRWWwyV3Y0?=
 =?utf-8?B?emhqVnZDa2xLYjROY0RoTEhYUUlTVHVSY0w2QlFMc1didks1d3FiS1FLREh5?=
 =?utf-8?B?dW5TL2dQeFNhM1lyTGF2MmNPeTZ6N2xFenJQNUtUKy9RTG9JZUxnWVFWK3lp?=
 =?utf-8?B?Lzl3djFBUWZxL3hubWQ0NHdNRGNHbktMejBlajFEZ0NkSjhCVkpjZWhDV3lS?=
 =?utf-8?B?bzNNdzVRU0Q0ZGhlUkZ0SmpMVlpJaE0xREIxdTNnN0l5Si95U09meHpUZXpS?=
 =?utf-8?B?YjJ5MnZMTzdEUFVEWW92QVhQS3NLZENQaWJBZmVIdVgxc1RFcGNJTGdESGxQ?=
 =?utf-8?B?U2hPdVA5d2tjRnU5bTNvb29Ndk8vY2ttK2w4bC93R2xuV1JDN08yeG11dC9w?=
 =?utf-8?B?eGVPNEloSmgxdXl6R3AzeFUzODJRWExrUjlqeFF1VjVaekZLcGgvMGdxSUgy?=
 =?utf-8?B?Y3p3SUtCNUFuU0ZRV2JiVHVKRklWeGV2cnBGQmducmU2K1FGUWphbE9Ec1lE?=
 =?utf-8?B?TWF5KzMyWnppV3g0SVlPWHVhR0ZJY0hSdEsxOVlkL2pWNzc3U3VsOWp1MDVL?=
 =?utf-8?B?Z09VcUl2blFFdGVQZWxSL3VyTHVxb25zRjFHdVZ6UmFaL0YxUHVKWG51QkVr?=
 =?utf-8?B?VTk0SlNEaFczQjhqbnZhQWpPNEd0MDM1bVRJMGNPYVNWL0N6WjRmelRMSnhr?=
 =?utf-8?B?c0I4NTcxNWlVdU9tNGUyZkxzTnF4dGovZE1iTmxVQWxpaS9YZkJUZklyTGMv?=
 =?utf-8?B?Slp4cENmNEJwY2I1ODBwaXQzb3E2NXViT2V2bFZYWlNNbkRsVHlCMnNRY3Ny?=
 =?utf-8?B?S0Q3TjZrMDdRPT0=?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MGFDZVkwanZHaGVaSmxYUlFiRmtwazFsV042bzEwUXFsVFo4NEtBUWI4QjRa?=
 =?utf-8?B?UnFEbFhxUy96S2o0NmlXd2E0N0xTVVRYdy9JOE9SMGVPK2p1NlJXVXp4b1Zz?=
 =?utf-8?B?UW1TVzJ1Y3paZ29Bald2bEp3RHRwSmZGWTh0aFQ1b0pmUEtaTkE2aDdSUEt4?=
 =?utf-8?B?YkJLNC9RRmpyVmtHa1pkU3doWFQ1TURpSGhabkNlbk1hWklVYVU1V0pxbVhr?=
 =?utf-8?B?RjByL1lPRHZnWDVhNEVoMjI2UXZidjlydmpYUk9wT1l2dndqR2tPL1IyTzBx?=
 =?utf-8?B?T3pkNHp0K2Q5ZFYzMGh0YjFVQkhBSGNWRTBIY0xwdXZVd2w2NSs5eVZQK1Uz?=
 =?utf-8?B?S3B1M1ZSa1kzbUZFU3ZXV2h2NWhKSGFBS01QYlc2cG5RZWE1RTRiaElNOW1P?=
 =?utf-8?B?SVl5bWh4TXJyRVVWMXgydEdRajZ6eEQ0dEpUWFAyazZhNVErNjN3RnhGam9D?=
 =?utf-8?B?Mlp0M2dTTm5MR2FFM2RHVytJeTZSTGdjR3hJMXhGWWpMWUNwY0MzUGtEL1Y3?=
 =?utf-8?B?VzhuQUtPVWZpeVhrVjZoSlZiUEtKZXQ0YWNwSWUrdGY3V2Zna0svN3BGTzJw?=
 =?utf-8?B?SXlqVFJNNjg5eCtJRmY1QjluMElhdFZIdWtuckZxYkdKcHQwV2tDQy91MUtH?=
 =?utf-8?B?a2MxZFcrQUhsKys5ODdnNXBId1FmVStsQ3hVaFJlc21OcFVRTnJDaG1PNVFj?=
 =?utf-8?B?b2pzL0ZPVHZSQThibmZhamZCTmd5cHc3UEpWUTBBM29aV01ueCtHREVMVENZ?=
 =?utf-8?B?ZThQajQ5WkVjRnU5VmhEYW5TRHFESWZvS2xSeDZiME8zVFNOaHZTMXkvellv?=
 =?utf-8?B?cy9KaysyMkxWR0dleC9OcG45dmpXeVBpZUtCOFVUVDBmREtEOFhYRElmT2Fi?=
 =?utf-8?B?dEZGR2RpOUNicGVYdUY2S0dqL00rdGY2YmhmZWJZNXRHL0xETklpazhRRUVi?=
 =?utf-8?B?VExNa3ZFQnRZcWltK2J0cGphanYweE9TMVRZTkZveFhrZGVLVlRYV01oNUZB?=
 =?utf-8?B?N254QUdTN0VlVGpqTDJQbXovMUdzR1RvUGRkYUlWdkVSOW10R29xdFdxQkFr?=
 =?utf-8?B?VWpJbnFpdjVxSThKU2tjajg2YTBESExpY1RwZnZtTEFTQ21uUVFkWU0vQ0cr?=
 =?utf-8?B?WVgzc2RrN2h6VTNlWE44em9VMjk0ZDJXay9CbGdYTHZ4TkhhdHkxMEtGWGVN?=
 =?utf-8?B?bmhtZUp4TEJZb3JDQW5rODBBM3kwSlAvWjgvdUhVYjcrelZWaDFNeUN6R0Jv?=
 =?utf-8?B?Yms0cnlVRk8vR3lBenViWVNsRHYwMERKNjVIK3NZVGdhRG1JT0lNM2dtM1NW?=
 =?utf-8?B?SERkdjJ0TDVhb1o4cmNLTTZJNS9nQ1FzY0xTMEdQWkhyNG9oQ3FyQzEvU1Rz?=
 =?utf-8?B?V1p1K28zZ2xDcXlPU2V1cmltVkpKTEtyOUk2UHQ3MmxoZnQrSjhLbXl5RlYz?=
 =?utf-8?B?S0IzVUtBZWNvdGlmVG9RTkU2MTBFODJEeTVURW8rWEdpWm8xbnFjWU5YZE1L?=
 =?utf-8?B?Rzgxa1lJQjNTSXczaG9naW1IZGNSOWR1bjFzV2djWnBZMHNQM1Y1ek15VzBj?=
 =?utf-8?B?SjA4bVNnQncvVGRFZXpvZ3dxUS80MWdwOHJqeXNNeU1oRTBNRE1IMVc2STZI?=
 =?utf-8?B?S1UzV3pxRzFJeXBrSUF0OFNqVG1JSVI4ak9sV3lPdlZLa3hFc0VpdHVlUld4?=
 =?utf-8?B?MDBmVElIL0ZOR0dlczNsQWYrQVBsbDhIR0NtMkg0eFVnSWZiZGxYWmxGZUtk?=
 =?utf-8?B?S1EzeFRHZFpFeHpiSVY3NEFtb2p5b3V2b2lBRHpGT1AxR0krS1RXelB3Nkl5?=
 =?utf-8?B?a0RhZXdlNDU3M2RaODlTWUtOY3RKaGd6OTBOMEZBamRZVi9hMzJNYWN4ZXY4?=
 =?utf-8?B?cC9oK2Q2QTNqcnE0WXpSZnhKUnJRYzdJeHlMd1JISU0rVmRKZ3AxcVZtWGxn?=
 =?utf-8?B?cmNkOHdjWWJPdTA4ODZzZWozZDUya2M5YWwxUGRzS3hHbjRGdW5rUU1kaWFD?=
 =?utf-8?B?ZUUrQWkzTXRCdzIzNWFVcFE4clN3U0VyNFl5Si91YXBDM3dkd3NUdk1Od3VP?=
 =?utf-8?B?VmE0UE9kcHp2T0dxeUd2QjhyVTVaY2t2dEFGRTBvZTJTWHVZaEFYNnhpNVVB?=
 =?utf-8?Q?gxQw=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: a31bc470-ee9b-4b8c-6130-08ddfa79f7f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2025 08:19:51.4160
 (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: rsOUjZ9w5vRUyWOqjCMXaSRZnkEhOrcqEmZWFv4JW7pDmhCqeU25VYGyRdP/d/sdrdncUSLNbnR6nZepNtm2JA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8160

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEyLCAy
MDI1IDM6MzAgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT47IFRh
bWFzIEsgTGVuZ3llbA0KPiA8dGFtYXNAdGtsZW5neWVsLmNvbT4NCj4gQ2M6IEh1YW5nLCBSYXkg
PFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsNCj4gQWxl
eGFuZHJ1IElzYWlsYSA8YWlzYWlsYUBiaXRkZWZlbmRlci5jb20+OyBQZXRyZSBQaXJjYWxhYnUN
Cj4gPHBwaXJjYWxhYnVAYml0ZGVmZW5kZXIuY29tPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2pl
Y3Qub3JnOyBPbGVrc2lpIEt1cm9jaGtvDQo+IDxvbGVrc2lpLmt1cm9jaGtvQGdtYWlsLmNvbT4N
Cj4gU3ViamVjdDogUmU6IFtQQVRDSF0geGVuL3ZtX2V2ZW50OiBpbnRyb2R1Y2Ugdm1fZXZlbnRf
aXNfZW5hYmxlZCgpDQo+DQo+IE9uIDEyLjA5LjIwMjUgMDY6NTIsIFBlbm55IFpoZW5nIHdyb3Rl
Og0KPiA+IEBAIC0yNDYyLDkgKzI0NjEsOCBAQCBpbnQgaHZtX3NldF9jcjModW5zaWduZWQgbG9u
ZyB2YWx1ZSwgYm9vbCBub2ZsdXNoLA0KPiBib29sIG1heV9kZWZlcikNCj4gPiAgICAgIGlmICgg
bWF5X2RlZmVyICYmIHVubGlrZWx5KGN1cnJkLT5hcmNoLm1vbml0b3Iud3JpdGVfY3RybHJlZ19l
bmFibGVkICYNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vbml0b3JfY3Ry
bHJlZ19iaXRtYXNrKFZNX0VWRU5UX1g4Nl9DUjMpKSApDQo+ID4gICAgICB7DQo+ID4gLSAgICAg
ICAgQVNTRVJUKGN1cnItPmFyY2gudm1fZXZlbnQpOw0KPiA+IC0NCj4gPiAtICAgICAgICBpZiAo
IGh2bV9tb25pdG9yX2NyWChDUjMsIHZhbHVlLCBjdXJyLT5hcmNoLmh2bS5ndWVzdF9jclszXSkg
KQ0KPiA+ICsgICAgICAgIGlmICggdm1fZXZlbnRfaXNfZW5hYmxlZChjdXJyKSAmJg0KPiA+ICsg
ICAgICAgICAgICAgaHZtX21vbml0b3JfY3JYKENSMywgdmFsdWUsIGN1cnItPmFyY2guaHZtLmd1
ZXN0X2NyWzNdKQ0KPiA+ICsgKQ0KPiA+ICAgICAgICAgIHsNCj4gPiAgICAgICAgICAgICAgLyog
VGhlIGFjdHVhbCB3cml0ZSB3aWxsIG9jY3VyIGluIGh2bV9kb19yZXN1bWUoKSwgaWYgcGVybWl0
dGVkLiAqLw0KPiA+ICAgICAgICAgICAgICBjdXJyLT5hcmNoLnZtX2V2ZW50LT53cml0ZV9kYXRh
LmRvX3dyaXRlLmNyMyA9IDE7IEBADQo+ID4gLTI1NDQsOSArMjU0Miw3IEBAIGludCBodm1fc2V0
X2NyNCh1bnNpZ25lZCBsb25nIHZhbHVlLCBib29sIG1heV9kZWZlcikNCj4gPiAgICAgIGlmICgg
bWF5X2RlZmVyICYmIHVubGlrZWx5KHYtPmRvbWFpbi0+YXJjaC5tb25pdG9yLndyaXRlX2N0cmxy
ZWdfZW5hYmxlZCAmDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb25pdG9y
X2N0cmxyZWdfYml0bWFzayhWTV9FVkVOVF9YODZfQ1I0KSkgKQ0KPiA+ICAgICAgew0KPiA+IC0g
ICAgICAgIEFTU0VSVCh2LT5hcmNoLnZtX2V2ZW50KTsNCj4gPiAtDQo+ID4gLSAgICAgICAgaWYg
KCBodm1fbW9uaXRvcl9jclgoQ1I0LCB2YWx1ZSwgb2xkX2NyKSApDQo+ID4gKyAgICAgICAgaWYg
KCB2bV9ldmVudF9pc19lbmFibGVkKHYpICYmIGh2bV9tb25pdG9yX2NyWChDUjQsIHZhbHVlLA0K
PiA+ICsgb2xkX2NyKSApDQo+ID4gICAgICAgICAgew0KPiA+ICAgICAgICAgICAgICAvKiBUaGUg
YWN0dWFsIHdyaXRlIHdpbGwgb2NjdXIgaW4gaHZtX2RvX3Jlc3VtZSgpLCBpZiBwZXJtaXR0ZWQu
ICovDQo+ID4gICAgICAgICAgICAgIHYtPmFyY2gudm1fZXZlbnQtPndyaXRlX2RhdGEuZG9fd3Jp
dGUuY3I0ID0gMTsgQEAgLTM0MDcsNw0KPiA+ICszNDAzLDcgQEAgc3RhdGljIGVudW0gaHZtX3Ry
YW5zbGF0aW9uX3Jlc3VsdCBfX2h2bV9jb3B5KA0KPiA+ICAgICAgICAgICAgICByZXR1cm4gSFZN
VFJBTlNfYmFkX2dmbl90b19tZm47DQo+ID4gICAgICAgICAgfQ0KPiA+DQo+ID4gLSAgICAgICAg
aWYgKCB1bmxpa2VseSh2LT5hcmNoLnZtX2V2ZW50KSAmJg0KPiA+ICsgICAgICAgIGlmICggdW5s
aWtlbHkodm1fZXZlbnRfaXNfZW5hYmxlZCh2KSkgJiYNCj4gPiAgICAgICAgICAgICAgIChmbGFn
cyAmIEhWTUNPUFlfbGluZWFyKSAmJg0KPiA+ICAgICAgICAgICAgICAgdi0+YXJjaC52bV9ldmVu
dC0+c2VuZF9ldmVudCAmJg0KPiA+ICAgICAgICAgICAgICAgaHZtX21vbml0b3JfY2hlY2tfcDJt
KGFkZHIsIGdmbiwgcGZlYywNCj4gPiBucGZlY19raW5kX3dpdGhfZ2xhKSApIEBAIC0zNTM4LDYg
KzM1MzQsNyBAQCBpbnQgaHZtX3ZtZXhpdF9jcHVpZChzdHJ1Y3QNCj4gY3B1X3VzZXJfcmVncyAq
cmVncywgdW5zaWduZWQgaW50IGluc3RfbGVuKQ0KPiA+ICAgICAgc3RydWN0IHZjcHUgKmN1cnIg
PSBjdXJyZW50Ow0KPiA+ICAgICAgdW5zaWduZWQgaW50IGxlYWYgPSByZWdzLT5lYXgsIHN1Ymxl
YWYgPSByZWdzLT5lY3g7DQo+ID4gICAgICBzdHJ1Y3QgY3B1aWRfbGVhZiByZXM7DQo+ID4gKyAg
ICBpbnQgcmV0ID0gMDsNCj4gPg0KPiA+ICAgICAgaWYgKCBjdXJyLT5hcmNoLm1zcnMtPm1pc2Nf
ZmVhdHVyZXNfZW5hYmxlcy5jcHVpZF9mYXVsdGluZyAmJg0KPiA+ICAgICAgICAgICBodm1fZ2V0
X2NwbChjdXJyKSA+IDAgKQ0KPiA+IEBAIC0zNTU0LDcgKzM1NTEsMTAgQEAgaW50IGh2bV92bWV4
aXRfY3B1aWQoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MsDQo+IHVuc2lnbmVkIGludCBpbnN0
X2xlbikNCj4gPiAgICAgIHJlZ3MtPnJjeCA9IHJlcy5jOw0KPiA+ICAgICAgcmVncy0+cmR4ID0g
cmVzLmQ7DQo+ID4NCj4gPiAtICAgIHJldHVybiBodm1fbW9uaXRvcl9jcHVpZChpbnN0X2xlbiwg
bGVhZiwgc3VibGVhZik7DQo+ID4gKyAgICBpZiAoIHZtX2V2ZW50X2lzX2VuYWJsZWQoY3Vycikg
KQ0KPiA+ICsgICAgICAgIHJldCA9IGh2bV9tb25pdG9yX2NwdWlkKGluc3RfbGVuLCBsZWFmLCBz
dWJsZWFmKTsNCj4gPiArDQo+ID4gKyAgICByZXR1cm4gcmV0Ow0KPiA+ICB9DQo+ID4NCj4gPiAg
dm9pZCBodm1fcmR0c2NfaW50ZXJjZXB0KHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKSBAQCAt
MzY5NCw5DQo+ID4gKzM2OTQsOCBAQCBpbnQgaHZtX21zcl93cml0ZV9pbnRlcmNlcHQodW5zaWdu
ZWQgaW50IG1zciwgdWludDY0X3QNCj4gbXNyX2NvbnRlbnQsDQo+ID4gICAgICAgICAgaWYgKCBy
ZXQgIT0gWDg2RU1VTF9PS0FZICkNCj4gPiAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4gPg0K
PiA+IC0gICAgICAgIEFTU0VSVCh2LT5hcmNoLnZtX2V2ZW50KTsNCj4gPiAtDQo+ID4gLSAgICAg
ICAgaWYgKCBodm1fbW9uaXRvcl9tc3IobXNyLCBtc3JfY29udGVudCwgbXNyX29sZF9jb250ZW50
KSApDQo+ID4gKyAgICAgICAgaWYgKCB2bV9ldmVudF9pc19lbmFibGVkKHYpICYmDQo+ID4gKyAg
ICAgICAgICAgICBodm1fbW9uaXRvcl9tc3IobXNyLCBtc3JfY29udGVudCwgbXNyX29sZF9jb250
ZW50KSApDQo+ID4gICAgICAgICAgew0KPiA+ICAgICAgICAgICAgICAvKiBUaGUgYWN0dWFsIHdy
aXRlIHdpbGwgb2NjdXIgaW4gaHZtX2RvX3Jlc3VtZSgpLCBpZiBwZXJtaXR0ZWQuICovDQo+ID4g
ICAgICAgICAgICAgIHYtPmFyY2gudm1fZXZlbnQtPndyaXRlX2RhdGEuZG9fd3JpdGUubXNyID0g
MTsgQEANCj4gPiAtMzg1NCwxMiArMzg1MywxMCBAQCBpbnQgaHZtX2Rlc2NyaXB0b3JfYWNjZXNz
X2ludGVyY2VwdCh1aW50NjRfdCBleGl0X2luZm8sDQo+ID4gICAgICBzdHJ1Y3QgdmNwdSAqY3Vy
ciA9IGN1cnJlbnQ7DQo+ID4gICAgICBzdHJ1Y3QgZG9tYWluICpjdXJyZCA9IGN1cnItPmRvbWFp
bjsNCj4gPg0KPiA+IC0gICAgaWYgKCBjdXJyZC0+YXJjaC5tb25pdG9yLmRlc2NyaXB0b3JfYWNj
ZXNzX2VuYWJsZWQgKQ0KPiA+IC0gICAgew0KPiA+IC0gICAgICAgIEFTU0VSVChjdXJyLT5hcmNo
LnZtX2V2ZW50KTsNCj4gPiArICAgIGlmICggY3VycmQtPmFyY2gubW9uaXRvci5kZXNjcmlwdG9y
X2FjY2Vzc19lbmFibGVkICYmDQo+ID4gKyAgICAgICAgIHZtX2V2ZW50X2lzX2VuYWJsZWQoY3Vy
cikgKQ0KPiA+ICAgICAgICAgIGh2bV9tb25pdG9yX2Rlc2NyaXB0b3JfYWNjZXNzKGV4aXRfaW5m
bywgdm14X2V4aXRfcXVhbGlmaWNhdGlvbiwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBkZXNjcmlwdG9yLCBpc193cml0ZSk7DQo+ID4gLSAgICB9DQo+ID4gICAg
ICBlbHNlIGlmICggIWh2bV9lbXVsYXRlX29uZV9pbnNuKGlzX3N5c2Rlc2NfYWNjZXNzLCAic3lz
ZGVzYyBhY2Nlc3MiKSApDQo+ID4gICAgICAgICAgZG9tYWluX2NyYXNoKGN1cnJkKTsNCj4NCj4g
Rm9sbG93aW5nICJ4ZW46IGNvbnNvbGlkYXRlIENPTkZJR19WTV9FVkVOVCIgdGhpcyBmdW5jdGlv
biBpcyBhY3R1YWxseQ0KPiB1bnJlYWNoYWJsZSB3aGVuIFZNX0VWRU5UPW4sIHNvIG5vIGNoYW5n
ZSBzaG91bGQgYmUgbmVlZGVkIGhlcmUuIEl0J3MgaW5zdGVhZA0KPiB0aGUgdW5yZWFjaGFiaWxp
dHkgd2hpY2ggbmVlZHMgcHJvcGVybHkgdGFraW5nIGNhcmUgb2YgKHRvIHNhdGlzZnkgTWlzcmEN
Cj4gcmVxdWlyZW1lbnRzKSB0aGVyZS4NCj4NCg0KSSdtIGEgYml0IGNvbmZ1c2VkIGFuZCBtYXkg
bm90IHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSBoZXJlLg0KSnVzdCBiZWNhdXNlIHRoYXQgaHZt
X21vbml0b3JfZGVzY3JpcHRvcl9hY2Nlc3MoKSB3aWxsIGJlY29tZSB1bnJlYWNoYWJsZSBjb2Rl
cyB3aGVuIFZNX0VWRU5UPW4sIGFuZCB0byBhdm9pZCB3cml0aW5nIHN0dWJzLCB3ZSBhZGRlZCB0
aGUgdm1fZXZlbnRfeHh4IGNoZWNrIGhlcmUuIE9yIG1heWJlIHlvdSB3YW50IG1lIHRvIGFkZCBk
ZXNjcmlwdGlvbiB0byBzYXkgdGhlIG5ldyBjaGVja2luZyBhbHNvIGhlbHBzIGNvbXBpbGluZyBv
dXQgdW5yZWFjaGFibGUgY29kZXM/DQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 08:26:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 08:26:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128302.1468704 (Exim 4.92)
	(envelope-from )
	id 1v0yLg-0000Ni-Sg; Tue, 23 Sep 2025 08:26:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128302.1468704; Tue, 23 Sep 2025 08:26: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 1v0yLg-0000Nb-OS; Tue, 23 Sep 2025 08:26:08 +0000
Received: by outflank-mailman (input) for mailman id 1128302;
 Tue, 23 Sep 2025 08:26:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v0yLf-0000MD-H0
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 08:26:07 +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 f2ea9889-9856-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 10:26:05 +0200 (CEST)
Received: from PR3P189CA0083.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::28)
 by DB5PR08MB10256.eurprd08.prod.outlook.com (2603:10a6:10:4aa::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 08:26:01 +0000
Received: from AMS0EPF00000191.eurprd05.prod.outlook.com
 (2603:10a6:102:b4:cafe::eb) by PR3P189CA0083.outlook.office365.com
 (2603:10a6:102:b4::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 08:26:01 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF00000191.mail.protection.outlook.com (10.167.16.216) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.12
 via Frontend Transport; Tue, 23 Sep 2025 08:26:00 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com (2603:10a6:102:33e::18)
 by VI0PR08MB10488.eurprd08.prod.outlook.com (2603:10a6:800:203::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 08:25:22 +0000
Received: from PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3]) by PAWPR08MB9005.eurprd08.prod.outlook.com
 ([fe80::d65b:a08:278:38e3%4]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 08:25: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: f2ea9889-9856-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=tVnbQ3PMV7cQl+ca0S5u4wEpGRqxHi3Ne8TNN2BvmQhAs4Sw/PmRNmFUmT/q6M17Vl+terg+3YI92NLmamJ39ubry65NoSJ+KGYLlmrupKgdTPMvehUifrKlfoTpf2gQ2M+T397UGH9Zp4cCOiLASlIGwqXLwmAuD4kP8Hcpi1bQ2NXL0QZpc98X0t9CaQML/8RJBJQe+WY2YcqcwuLRQWCmKM7EVbVHNThkJtJ/WAA4hZInXUMVq4WBEm35orpxqld5G0ByeNYBV8f80ylHx/8QrfbhQSFIt/fWZMlmKEA6VHhPpidCx4oV4jw2tQmXvPiiGN9BTKrw9qFWVnfZ0g==
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=SP0OOSwrewED/qPMOJBcKwbVCgSapH/nyVp98pFg94o=;
 b=dWk7Ar11rxhaGWY6t5/zGJ6HE9LKwDc62ozgFFo7CvbrB0mCrEeiSOuQb5sgUNC3InPMGs8PZe0vL840YEAaVBQ4axlD7V62dpcLc6AZgnSu/rtEQDml++N2QAcjCMzBlkxm6ijYRThhSCGIF4Suy9s+ddUcMAHpRKuXN0dg6hWCzh6NcmcQ1Y8zebCsP35DG6g9fQUNXh4vOduAkbe3Pd0ev1eaT1KWl0167OH0CsFVFD/z+ZB+3Y/Don1+jqbHyyjzcrcJU+BKT6vFoF6Uc/aSesRBfh6YYo8MVud6CXmbE2KjtyxNDgiQekcbZnZkwVmIF0SFqym+lDc3idurOw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SP0OOSwrewED/qPMOJBcKwbVCgSapH/nyVp98pFg94o=;
 b=Q553d2g5FNQWPtY39BJSWdbemCLcvFRHBhha0aOQBtdORFaG3kPg6iLEYS6SlHWp19Z2UUV66uu+TJk+2AcWOaqcga5jWd/de3Hk4PMCAecv3lbg2c/P/Gd0gf1f1hyMqzUa0ss55XT0HgAjuwTJSkV5Awte8octy+O1UA3D5yA=
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=QYvThoqKTtHA1PTauf0ZQpfcXSqJ1zpQMX+cvFTP/4Sv4R8JWEHPHrXKqMrcXpKvK3Tt0MEEtCbFOHEHDNiBFKjcembGduATxKBDb29bB894JnA/768KHgeXWJamBH5oFYkM43EqR1/D24BoxLxYTJDGcg6sRjQQ3Fi5RRuK1cgPjU64KTo7LZ1vOGdDCM4bNumfo/fhUE8aFc0DlNzRu8oacRgAMO/WrdsfxaUJCYXYH8jSJsOAz5sh/C66sANcnNkiFtr0BA3SDgY3Sydp2nDAA02OWPc8sqhAKy+PsZ217WajvH4mlcOjBXtdnEtPR/CMQUcHZtNlyOoZCFOA+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=SP0OOSwrewED/qPMOJBcKwbVCgSapH/nyVp98pFg94o=;
 b=d71HjJUvjyYu3HLg1Zx0tbrDvwLunP5b3ClHgOe+suz6lh7nz5R0s1IxMlKkUubu3ttjkPnsmGnE4rQR/+B57aQfOim7V1PIe54GC2NnBiBV1WZGjfrIkIS2FGZBbiiq226tOCiIhE0fqXxRVtS/7asZ8iKnlt2ZK7lRCj6oH23fFfBecdCju6WmLbX7gQ6FA6FcB69Wx9FMEelt9YAnj5nXokXh2GYsFBjIZ6snTjd//ZlN2ZstBHpSRE++bSDQ0uhNSLaizGlWTA2bIjhzQSSuvsbsaWT8pOVcJDWR5YJEt742v08i5dmfeHu6YkxN0fVpXBY1Nf2Ubr9RckJM9g==
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=SP0OOSwrewED/qPMOJBcKwbVCgSapH/nyVp98pFg94o=;
 b=Q553d2g5FNQWPtY39BJSWdbemCLcvFRHBhha0aOQBtdORFaG3kPg6iLEYS6SlHWp19Z2UUV66uu+TJk+2AcWOaqcga5jWd/de3Hk4PMCAecv3lbg2c/P/Gd0gf1f1hyMqzUa0ss55XT0HgAjuwTJSkV5Awte8octy+O1UA3D5yA=
From: Bertrand Marquis 
To: Xen-devel 
CC: Viresh Kumar , "Bill Mills
 (bill.mills@linaro.org)" , "Edgar E. Iglesias"
	
Subject: Xen Summit 2025 - "Virtio Message challenges" design session
Thread-Topic: Xen Summit 2025 - "Virtio Message challenges" design session
Thread-Index: AQHcLGOZDZwUIN3nakWMTf8xAnZKbQ==
Date: Tue, 23 Sep 2025 08:25:19 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.700.81)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PAWPR08MB9005:EE_|VI0PR08MB10488:EE_|AMS0EPF00000191:EE_|DB5PR08MB10256:EE_
X-MS-Office365-Filtering-Correlation-Id: 67539f39-9798-4424-7123-08ddfa7ad415
X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr,ExtAddr
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|10070799003|376014|366016|1800799024|38070700021;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?YjR5NnBMNEJWUW9zd3UwNGRaWTBxamtDNm1nY1c1NEVJSUtOSi9vRTF2OVBP?=
 =?utf-8?B?NVppSS9RcFJ3YUlycmRJUFV5dXFQSGQzQlFERkhhTTd2Z3lBVEZKK0NBMVo5?=
 =?utf-8?B?SCt5Q0lIc0IvOWUrc3Z3Y2VrcjdGbk9FWkJsTG9mc3Rlc3JtZytzd0RMZmxK?=
 =?utf-8?B?Y1pENDhCK0NSM3BOMGgxWWhnWjd3VGhqMkRNQWlteEd1SWxUU0NXUW9yQ0NY?=
 =?utf-8?B?SzNXUWhXN09TNDFPOXJhQVBQdXBSeEE3c05xcm53Yzg3OVg0VjZlYmYxOXc0?=
 =?utf-8?B?dlpreXZZVDdqU0k4a3NOcHJsei9LT0t1a2t4M2kzRFJvUEhkUlU4NFR0QTBu?=
 =?utf-8?B?QW1rNWRHdVB5K0p1M3pTZWVrZGNtM2pXbU1abDY1NXp1MGpuWWJ4MC82c0ta?=
 =?utf-8?B?SkNERFZHaWdEZnk2T0tBT241SVpLYk9zNVdNcDlRN2ZmdjJoc0ZiZWtUdHF2?=
 =?utf-8?B?L3hqczdYWXMra29FMzJpVmVWRElkb2MvRzQ4YmZib2RhV0hzSjdKRzZtVi9R?=
 =?utf-8?B?T0RFZXV2T0Zad3QzK2U4RE4rTUE5RVByZkdvL0V4cHBsQWNCMkxrdzBYTG5t?=
 =?utf-8?B?ZXQvSUwwWVV3bTE4NHhOK2NobVVleVk5eEFLV1MvZXV2SDB3ekpiNlM4d2dR?=
 =?utf-8?B?bHNxMU95cUh3NkFVVEF5bmozQ0FkOFlTSUdLeHhjVUlGQXJOSmZHQmIwd0Rs?=
 =?utf-8?B?TEdsdXYyUnl1MXk4b0VhYnl4RlNqRmxrV0xiNm9WSFJIenV2dkoxaU9jTEVM?=
 =?utf-8?B?NjlSdWw5NysrNWIrMVpUOXNjMkRSR0wwaDhRN1Q3ZFhpT1FDbDh2UkpMQkZ3?=
 =?utf-8?B?YTNSQk1MZ0dJNnI3ckhwK2hONDRUbHIwNXozNjBabFNxOEhFUktIOWpnTitJ?=
 =?utf-8?B?d0xEWEJXOGFPaHYyVE5nYW8xUlA3NjlWMWk0Uy9zZG1kTVMvbjU0d2pMdnVB?=
 =?utf-8?B?TmdqSkFhc1d4bW5IdUlEdmRNVHRjczJDRURaWDdYNytGQjFDSkptdERzVURa?=
 =?utf-8?B?TnhEMFR3OFNKbU5qK3lKUS9iZkFkakEyYTFXNHlpVUJ6SDFJeWxsQlFtUGlF?=
 =?utf-8?B?YTZNZVY5c1FrNlVwUlVQVk8wYm9CanEvT0gwNTdIMFBpUFlFVGdRelVLVTd6?=
 =?utf-8?B?QWdBWG5sMHk4bERtS05hOTgzM0NHSG1CWGovRHVYdkdZL2VjTkpRS2JzeWZW?=
 =?utf-8?B?WUFXR1A1WURoRmRHM0xWZ000WTYyK290SjJpMUhDMVluRzZyY1l3NlJDRkl6?=
 =?utf-8?B?MjBFSEpVRVl5OWp3Mk5ac0lVUU5jUlBMb05jZHlnNmw0amdLRnlHUlRxVVBZ?=
 =?utf-8?B?RVc3U1NPakRDK1NzQ2cxNUM4M1U1ZVp1ay9jRUNaN1E1dHdzbnluZlRRV0lI?=
 =?utf-8?B?SXZJQ0RrZXExdmJ0TVFrSHV4YUFYWHJNMnVSdCtYSytOTWN5aFNMZ3ErMEdP?=
 =?utf-8?B?YWtkNlNyL2NMaEd6MzQ4dVJ0a01VdXJCcTU1L2k1YktuZkRPSmI3d05QSi93?=
 =?utf-8?B?S1dVZWNtK3Q2YUh3cTJKS0U0SjZYbnorVmtYaHlVcGdUempzemJUZHUzOXZs?=
 =?utf-8?B?bjRQZ285ejNELzZBSVlUNTIzZ3A2dWlqUFU2RU13RmlZSE4wNGF2ci9ENGRL?=
 =?utf-8?B?T3V0Qy9yd0lWaUErakRkaHA4eDFVVk1tTGphQ054WkZYYWI1aFZEbW9UVEo0?=
 =?utf-8?B?bDljNnNGWVRpSDlhend5TjRMaXZvY1BpUnk0QmlGTy9UQlJVZ3BQOGFuWmE0?=
 =?utf-8?B?d1JHNTVSclEwNldpengyR0ZNbU1Ca2hZdE1ISFBMTW9UV0RtOUJKUkN0SWM2?=
 =?utf-8?B?Y1RxVmZZZjB0WHY2QXBpaXhEUUlVTU4wSGVoeWFGZEhIakEzQi9tb3Y3TlhX?=
 =?utf-8?B?alRSMkhjUmZUTUpYZWlYMnVZTWx0bVh3enJ1ZStwNXIzWDVjek9LMlZYa3Fm?=
 =?utf-8?B?VjRxR2RvSDJ3aTVjeXBqWCt0NlUwcCtBWTNuenNoR2dTYzcxWmd6blpuTmNE?=
 =?utf-8?Q?aBRtygkS0d3Jqe71GxArWsNaB+IzRA=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAWPR08MB9005.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <58AA704E3DF6F143A05C584E37D57D33@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10488
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000191.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	588389ed-c8db-42bd-bfd3-08ddfa7abb93
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|35042699022|376014|36860700013|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eXVmRk1DUjZKKy9VaWVFRk5YZEEyclUxNFlmaGpIOW1UR042OXo2d2ZVVTVF?=
 =?utf-8?B?RXVYaHBNQU56RnY2QW9DRGJBcGhGalZUWUt1bzdzZ0svRkdSY0VaSzVkYU82?=
 =?utf-8?B?NWpnRmdZeURhVmN0UGg4S0FnZ2c4WUZzeitoMHM0cXhyZm5LeWV4SUUvRkZY?=
 =?utf-8?B?eWxIaFdHMUI2R3o4NjBlK2loZHgwT1hlOUNONHJIRXNoU3lUcFhsTk9hYjVI?=
 =?utf-8?B?NjFPdnJJT2Myc0hWcVFIbzhiQ21KbEFvbHMwRjFDMGxCSmxoOUFHREM3aEgw?=
 =?utf-8?B?Sjk0VGRCMkVRVU5zSVRiVklSem9RUjB0Y1RHcmE1aytPMkxDeCt5YXJPa2RW?=
 =?utf-8?B?VUJaRE5zUHhFa2dTa2E4b1RRL0MzVWlsWmt0MUt5elA4bzF3a3NyQzRoV1I2?=
 =?utf-8?B?bngzRG9IZ1dxbXUvQWtiL1hIQWxDaENtYzhadzhxOVJ6OUFNNDIyN2p6S2VW?=
 =?utf-8?B?dm4vbDJXTFdkK2dZbGNac1dYRHpRbjl4ek8xQ29GT3pjSkRYWXFaUGU3dmpN?=
 =?utf-8?B?R0F5L2FsbllzMUxwTS9kZVRtQTkvTkVYNk1QZTI2bnRON3AzK2Z5NFF5WDFh?=
 =?utf-8?B?L2JpNnV1NFhoU2dlK0ViTzA0T25oa3IvbzhVdlEwaTB3ZzU0NUNLZ2toMlpo?=
 =?utf-8?B?NzNza2ZqeW5Jd21RbGgyZlJ1dmxKUGR5L2tlOUNraTJsQi9YeXQwblNIWkdT?=
 =?utf-8?B?YnRpbW5kNGc4Um1CcEZ4MG4wTlJTdFd1RkxrOVB0VFh4ZHNtTlMvYWVhUWxR?=
 =?utf-8?B?ejYxZ3hYalBOb3lEdlVqNWtoQThUR21GcmVmMHkydTk2aERJaEJhRHpGS3Z5?=
 =?utf-8?B?QStGeGE0R1FEcm56QUwxdGdlYkFIYjk5NU1hdWJnVFFqSmdQUlhMNkI0cmNz?=
 =?utf-8?B?dzNzbTU4N2xDcXBDRHNyR1BoYUZRRmFYd1dLOVRiaDczTHdMMnAxVnY0OEl6?=
 =?utf-8?B?RFNwdTJZc25XTjNUQVNsWVZaZGU0R3M1bmRMbjd4aER2K1VwNktXQ01XN2Ry?=
 =?utf-8?B?YW5mRjlLa3E2RTJmWCtmcVpqZDNpKzFKVkNMQzNsVFEvU3pUTlUyVUpES25U?=
 =?utf-8?B?SVZqMHJaRFBqeVYyU21rbXljWUlKVGl3em9lSVBBSklRUERnOEJtbkJ2ZHBF?=
 =?utf-8?B?bVRNSTQyaVpHY2NweVZ2QWhvbWh5OEF5a29wcEI1b3VMaGFFVElvZ25nNERG?=
 =?utf-8?B?czRRTGY5QVFlbWRvMGdMN0o1cndMdDBjS2EvdVFnS3k3UzFFUk5XWTc2VWh5?=
 =?utf-8?B?ZDNOQmN6YzgxNkZkaW51eXB4WkEzNWY2ak9ETythbWFsVHE0cXo5VkxnMGtw?=
 =?utf-8?B?bmYxVEtQY1NmaEhyZ1o1ck1pNlBNV0RPekZhUmNqRlpiVHRvcDhRNHg4V1ly?=
 =?utf-8?B?UWwyV0JyMVlqNnYrNWk1dDVnUTlGYlNJdGR1REMwcmE1dXRpTFZWUnlhV2lo?=
 =?utf-8?B?bmdyaXBOeGhySzFFK3YwVXQrWVZkZlBtOVpCOUp3Z3pjb3Y4amlCRmtncHFu?=
 =?utf-8?B?MklHYXZvTlVLK1N2SlJGR0JSd2xENVJub05QSWo1MTdZWlZreGlTb2VHa3dk?=
 =?utf-8?B?T1A3bXBzZ04zNG5kSlJrUGRmK2t3RnBGZExZSFJxMjZqejd1djFaRXU4MEl5?=
 =?utf-8?B?UXFuQmErUlo1RzFvQkRiZERIOXdvMzlZc1E0MGJYWjUwUW5iWmZjZmVlUU1s?=
 =?utf-8?B?b3ZTWSt0T0xvT3RmZDltWU5xdVFpekJSRUtwSVRsMVM0NGhweWlZSDk1TkVn?=
 =?utf-8?B?eEhFWXp3MWN3M29DTlJKNVYxWGQzeWZBL2tRdnFtblVGQzJoUW9WMmU0dnNk?=
 =?utf-8?B?dlUwcVJQb0dmTzZpa2dvK3pseWhCN2J5VDVGbnljUmN0SnY4dEJyeXdmN2w1?=
 =?utf-8?B?bWNpeFBmdlNIa1pEYTdxUFNWbEtqTFBOQzlFUGFROUlsRTZjeldCLzJPTGdw?=
 =?utf-8?B?TTNBWE5wRHVSakV3ajA0ZitkcFd1T0x6T2R0dVVIN1RwMWw3M244Z2VsV1RL?=
 =?utf-8?B?d2hDNEdqWkttVTlSSjFqOWdQdGhYc1REenhqajRUd1Z3SUZINjduai9qQkVW?=
 =?utf-8?Q?Okf+5/?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(35042699022)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 08:26:00.6640
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 67539f39-9798-4424-7123-08ddfa7ad415
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:
	AMS0EPF00000191.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10256

SGksDQoNCkhlcmUgYXJlIHRoZSBub3RlcyAiTHVjYSBGYW5jZWxsdSIgdG9vayBkdXJpbmcgdGhl
IGRlc2lnbiBzZXNzaW9uIG9uIFZpcnRpbyBNZXNzYWdlOg0KDQotLS0tLQ0KQmVyOiB3ZSBoYXZl
IGNoYWxsZW5nZXMgaW4gWGVuIGFuZCBhbHNvIG90aGVyIHNjZW5hcmlvcywgSSB3b3VsZCBsaWtl
IHRvIGRpc2N1c3MgdG8gZG9uJ3QgcmUtaW52ZW50IHRoZSB3aGVlbCANCk1haW4gb25lIGlzIHRo
YXQgd2UgYXJlIGludHJvZHVjaW5nICJ2aXJ0dWFsbHkiIG5ldyBWTXMgKFNlY3VyZSBwYXJ0aXRp
b25zKSB3ZSBuZWVkIHRvIGRlZmluZSB3aG8gY2FuIGJlIGNvbnRhY3RlZCwgY29tcHJpc2luZyB0
aGUgc2VjdXJlIHBhcnRpdGlvbi4gV2UgaGF2ZSB1cCB0byA2NWsgcG9zc2libGUgcGVlcnMuIA0K
SURzIGFyZSAzMmsgYXJlIGZvciBub3JtYWwgd29ybGQsIG90aGVyIDMyayBmb3Igc2VjdXJlLiAN
CkluaXRpYWwgaWRlYSB3YXMgWFNNLUZsYXNrLCBidXQgaXQgZ29lcyBvdmVyIGl0cyBjYXBhY2l0
eS4gDQpXZSBkb24ndCB3YW50IHRvIHVzZSB4ZW5zdG9yZWQuICANCg0KQW5kcmV3OiBJdCdzIFhT
TS1GbGFzaywgd2hhdCB3ZSBoYXZlIHdhcyBwb3J0ZWQgZnJvbSBMaW51eCwgWHJheXMgY2FuIHNv
bHZlLCBzbyB3ZSBjb3VsZCBwb3J0IGl0IGZyb20gTGludXguICANCg0KQmVyOiBIb3cgZG8geW91
IGNvbmZpZ3VyZSB0aGlzPyBBdCBib290IHRpbWU/IENhbiB3ZSBtb2RpZnkgYXQgcnVudGltZT8g
DQoNCkFuZHJldzogWW91IGhhdmUgdG8gcmVsb2FkIHRoZSBwb2xpY2llcyBvZiB0aGUgc3lzdGVt
LiANCg0KQmVydHJhbmQ6IFlvdSBjYW4gaGF2ZSBWTXMgYXBwZWFyaW5nIGFuZCBkaXNhcHBlYXJp
bmcsIGRvIHdlIHRoaW5rIGl0J3MgdGhlIHJpZ2h0IHNvbHV0aW9uPyANCg0KTGltaXRhdGlvbiB3
b3VsZCBiZSwgeW91IHdpbGwgaGF2ZSB0byBoYXZlIGEgZml4ZWQgYW1vdW50IG9mIHBvbGljaWVz
LiBb4oCmXSANCg0KQW55b25lIGhhcyBhbnkgb3RoZXIgaWRlYT8gDQoNCkFub3RoZXIgcHJvYmxl
bSBub3csIGFkZCBhIGRpc2NvdmVyeSBzeXN0ZW0sIHdlIGRvbid0IGhhdmUgeGVuc3RvcmVkIG5v
dy4gDQoNCg0KQW5kcmV3OiBUaGUgaWRlYSBpcyB0byB1c2UgYXJnbyBwb3J0IHplcm8gYXMgYW4g
ZW51bWVyYXRpb24gc3lzdGVtLiANCg0KDQpCZXJ0cmFuZDogV2UgbmVlZCB0byBkaWcgb24gQXJn
bywgYW5kIFhTTS1GbGFzay4gTm93IGxhc3QgcHJvYmxlbTogVmlydElPIGJhc2VkIG9uIGdyYW50
IHRhYmxlIGFuZCBldmVudC4gTWFpbiBxdWVzdGlvbiBpcyBzaG91bGQgd2UgZG8gdGhpcyBhbmQg
d2hvIGlzIHdpbGxpbmcgdG8gaGVscD8gDQoNCldobyB0aGlua3MgaXQgdXNlZnVsIGZvciBzZXJ2
ZXJzPyANCg0KDQpBbmRyZXc6IExlZ2FjeSBTVyB3aWxsIGJlIHRoZXJlIGZvcmV2ZXIsIHRoaXMg
dGhpbmcgd2lsbCBoZWxwIGluIHRoZSBsb25nIHRlcm0uIEl04oCZcyBpbnRlcmVzdGluZyB0byBp
bnZlc3RpZ2F0ZS4gIA0KLS0tLQ0KDQpNYWluIGNvbmNsdXNpb25zOg0KLSBJbnZlc3RpZ2F0ZSBY
U00vRmxhc2sgZm9yIGRlZmluaW5nIHdobyBpcyBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggd2hv
IHdoZW4gRkYtQSBpcyB1c2VkIG9uIGEgc3lzdGVtDQoJLSBNaWdodCBub3QgYmUgcG9zc2libGUv
ZWFzeSB0byByZWNvbmZpZ3VyZSBhdCBydW50aW1lDQoJLSBXb3VsZCByZXF1aXJlIHRoZSB1c2Vy
IHRvIGRlZmluZSBzZXZlcmFsICJwcm9maWxlcyIgYW5kIGFzc2lnbiBlYWNoIFZNIHRvIGEgcHJv
ZmlsZQ0KCS0gRXhhbXBsZTogbWFzdGVyIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGFueSBWTSBhbmQg
c2VjdXJlIHdvcmxkLCBkb21VIGNhbiBvbmx5IGNvbW11bmljYXRlIHdpdGggZG9tMA0KLSBJbnZl
c3RpZ2F0ZSBob3cgQXJnbyBjaGFubmVsIDAgY291bGQgYmUgdXNlZCBmb3IgZGlzY292ZXJ5IG9m
IFZpcnRpbyBNZXNzYWdlIGJhY2tlbmRzDQoJLSBEZWZpbmUgYSBwcm90b2NvbCBvdmVyIENoYW5u
ZWwgMCB0byByZXRyaWV2ZSBhdmFpbGFibGUgZHJpdmVycy9iYWNrZW5kIGlmIGFueQ0KCS0gSG93
IGRvIHdlIGRpc2NvdmVyIGFsbCBWTXMgd2UgY2FuIGNvbW11bmljYXRlIHdpdGggdXNpbmcgQXJn
byA/IGNhbiB3ZSB1c2UgWFNNID8NCi0gQ29udGludWUgY3JlYXRpbmcgYSBQb0Mgb2YgVmlydGlv
IE1lc3NhZ2Ugb3ZlciBHcmFudC10YWJsZS94ZW4gZXZlbnRzDQoJLSBjaGVjayBwZXJmb3JtYW5j
ZSB3ZSBjYW4gYWNoaWV2ZQ0KCS0gY2hlY2sgaG93IGNvbmZpZ3VyYXRpb24gd291bGQgd29yaw0K
CS0gY2hlY2sgaG93IHRoaXMgY2FuIGxlYXZlIG9uIHRoZSBzaWRlIG9mIGV4aXN0aW5nIHB2IGRy
aXZlcnMNCg0KSWYgeW91IGhhdmUgYW55IGNvbW1lbnRzIG9yIHdhbnQgdG8gYWRkIHNvbWV0aGlu
ZyB3ZSBtaXNzZWQsIHBsZWFzZSBhbnN3ZXIgdG8gdGhpcyBtYWlsLg0KDQpSZWdhcmRzDQpCZXJ0
cmFuZA==


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 08:39:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 08:39:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128316.1468712 (Exim 4.92)
	(envelope-from )
	id 1v0yYy-00027o-01; Tue, 23 Sep 2025 08:39:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128316.1468712; Tue, 23 Sep 2025 08:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0yYx-00027h-TK; Tue, 23 Sep 2025 08:39:51 +0000
Received: by outflank-mailman (input) for mailman id 1128316;
 Tue, 23 Sep 2025 08:39: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 1v0yYv-00027I-D1
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 08:39:50 +0000
Received: from 10.mo575.mail-out.ovh.net (10.mo575.mail-out.ovh.net
 [46.105.79.203]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dc988644-9858-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 10:39:48 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.109.249.19])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4cWD1Z63skz5xZf
 for ; Tue, 23 Sep 2025 08:39:46 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-qvgpv (unknown [10.110.168.159])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id CF987C28F2;
 Tue, 23 Sep 2025 08:39:45 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.112])
 by ghost-submission-5b5ff79f4f-qvgpv with ESMTPSA
 id 5/dgI9Fc0mgKYxwA7uDI/g
 (envelope-from ); Tue, 23 Sep 2025 08: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: dc988644-9858-11f0-9d14-b5c5bf9af7f9
Authentication-Results:garm.ovh; auth=pass (GARM-112S006dd9377a4-e982-43c7-b819-bc527ffc762e,
                    4804EDC472500D38916C4D805CCC5D85F75C271A) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 23 Sep 2025 11:39:36 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 05/22] x86/boot/slaunch-early: early TXT checks and
 boot data retrieval
Message-ID: 
References: 
 
 <0024c24f-39a4-4b5e-af7b-536f7cebfaff@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0024c24f-39a4-4b5e-af7b-536f7cebfaff@suse.com>
X-Ovh-Tracer-Id: 6688408398192882777
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTG1tSPZGeNdD43htroYh5Q5QsWhRrwfRxFz1DfWq2bbDkc8kWbl8oSH7m9zAOp0K6Jsh2PIv3gLHtOliqc5w56bZ7XZvIx4b5NI3Yob8WfWy6Imu9OX5bC7kS4lad9a/0fbtoGqbC+TOSLEuqDR1M6yDwULuwLJUyVyWRFey0vgetPMzjjDYvnukzzVevMNiiVkWQ7VGywgIhXVS+hEDeKKedj5riva5xP+hhUFWGxmRTmpzwCqMG60cxFTLur4ojZe0O2Gi3kskxsKJUw6u5uQ5fK8LGvZXAQMq4KkoAUqLv2bdXW4HGjWSeRXD3qXYjfkcrK6dosdMcu5sKDrCbcatL9kT0GMItTlhEF6ARt6UpQ6NhbFQtP6qlp5rB1Q6k7n18da1JEFef0NnnUWbiN+TnN3dQB8BPwoQp+59FWuXmV/A2tg/n9QFlhu0psBxCMKWeMfd2csP4L+vYXKskkgg2qQVJZMQetDC4JODjNhPe55vUVrXJOwX2X7W6L7KMHr2R4rWweYrcdMpBxBeO6rF0/TFxq1LnmCsLcZaiRHv495+oK3Na/pyuBRrDBmK19vU38PIg88OMUTWYqxO27oRtyKec8d2ZMc+JRxizU++pTuIxfvGWO8lmrIhk7D/LzTE2+YM7h6+f8k3g2tpeDp2yEu6LWX4tAnGu1+n0YNcQ
DKIM-Signature: a=rsa-sha256; bh=MrZXviuwD1X+tppEyjVOgaltKaFgtrsSJ6ig/6M59Hs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1758616786; v=1;
 b=TiKU8h3CJgK7d2Sdk7T3wrkLqFrwIo2X7OS+4JRQ9ka871Oile4oJp/Rj8Tew+rO3zO06aJ0
 9chl+0upjuzgFzwy2iNHLSrqG5jrRYgTM+V2cO0NPEPeMeRWOllT4WmR2TTDeqnAvBOUbbAXsEx
 d6UydHiVgz1W4pMHqrlqYkRpAMg5xXtvUVLwGvvGVqAQaMeyEjzYyZ527jsI3xBDA4aqKx37vRH
 /MmgknTcHl0ZiQyqtr6ymaeUh+zZ3OFhcQj5lbqFpdlMm6wBPG7i8J9neNy6cY+ZfTQHOXWVysf
 3hvY1vzlPZfwlnAgC7si2LmHwPjOxoKuQhp8HigrrQCbQ==

On Tue, Jul 08, 2025 at 06:00:13PM +0200, Jan Beulich wrote:
> > +static inline int is_in_pmr(const struct txt_os_sinit_data *os_sinit,
> > +                            uint64_t base, uint32_t size, int check_high)
> > +{
> > +    /* 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 )
>
> If you leverage what the comment says in the 2nd comparsion, why not also
> in the first (which means that could be dropped altogether)? If the start
> is always zero, why does the field exist in the first place?

The range always starts at 0 here because txt_verify_pmr_ranges() reboots
earlier if this assumption doesn't hold.  The field can have non-zero
value, but I guess the more memory is protected the better.  I'll remove
the first part of the check as useless and clarify the comment.

> > +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;
>
> Just like Ross mentioned for the return value of is_in_pmr(), this one also
> looks as if it wanted to be bool.

Will update.

> > +    /* 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;
>
> The addition overflowing is only checked later, and that check may be bypassed
> based on the result here. Is that not a possible problem?

Thanks, that looks like a problem to me.  Moved the overflow check from
is_in_pmr() before this check.

> > +    /*
> > +     * 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,
>
> What is this "MBI" which "starts with 'uint32_t total_size'"? Do you perhaps
> mean multiboot2_fixed_t? If you really can't use a proper structure ref here,
> please at least mention whatever type that is in our code base, so the use
> can be found by e.g. grep.

Yes, it's MultiBoot2 Info.  Nothing precludes using multiboot2_fixed_t,
will update.

> These inline functions are pretty large. Why do they need to be inline ones?
>
> Jan

The functions are run at entry points, one of which is in 32-bit early
code and another in 64-bit EFI.  Having this in the header is simpler
than compiling the code twice.  Despite having many lines, it's just a
sequence of checks, so it didn't seem like too much for a header.

Regards


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 08:53:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 08:53:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128328.1468723 (Exim 4.92)
	(envelope-from )
	id 1v0yln-0004nN-3q; Tue, 23 Sep 2025 08:53:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128328.1468723; Tue, 23 Sep 2025 08:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v0ylm-0004nG-WA; Tue, 23 Sep 2025 08:53:06 +0000
Received: by outflank-mailman (input) for mailman id 1128328;
 Tue, 23 Sep 2025 08:53: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 1v0yll-0004n9-Ks
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 08:53:05 +0000
Received: from 19.mo583.mail-out.ovh.net (19.mo583.mail-out.ovh.net
 [46.105.35.78]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b78144f1-985a-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 10:53:04 +0200 (CEST)
Received: from director11.ghost.mail-out.ovh.net (unknown [10.110.37.252])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4cWDJv4jB6z6VSJ
 for ; Tue, 23 Sep 2025 08:53:03 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-q9x2g (unknown [10.110.96.9])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id B7DCAC5BA6;
 Tue, 23 Sep 2025 08:53:01 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.103])
 by ghost-submission-5b5ff79f4f-q9x2g with ESMTPSA
 id 9gqAIO1f0mjuYQAAD2cM0A
 (envelope-from ); Tue, 23 Sep 2025 08:53: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: b78144f1-985a-11f0-9d14-b5c5bf9af7f9
Authentication-Results:garm.ovh; auth=pass (GARM-103G0058440662f-1117-4644-be73-4f94ea993088,
                    4804EDC472500D38916C4D805CCC5D85F75C271A) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 23 Sep 2025 11:52: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 v3 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 <5da8e6c9fd2d986cd99be35774b850584e4a43ee.1748611041.git.sergii.dmytruk@3mdeb.com>
 
 
 <70869cab-ecd1-4756-a874-91fbc9b7ec35@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <70869cab-ecd1-4756-a874-91fbc9b7ec35@suse.com>
X-Ovh-Tracer-Id: 6912462481714361433
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTF3cPJaf/9hw6Nuh/cAQGE4V1JYeBNdgVI/FVLtRv8IAAr3IUPP98mKOx6sOSpJ88Rt4QXBM11KpFoxIIyWSdZcm79CcP1+2p2GWJ8K6zfY3w4OYO4QSf0EEmG+7JTO/ufFQSWlidzyEJhVbnO5O0qU4/Epx06vTRxPPmQp/AJsFi5l7mYBsuo3wtnwOIVqyhqopZSm4B68ikKIeroS31UYh4/1PWcmgNX2w0u/hM2eQDfR9wLIVfUWTmNPCUhWv+esPsIvosi4Ke36D/xXHA3Zks6SHHncmFALOFYJz/5h9yBfj1CaAKy04LziedOKO+WV8Vu3umMh3L4oKHL4YUP/L2VsZ1aVGefR2058ZeKb1eoa3YO99sPpyO06Ok2wBhU0e8vBHhviUwBscaHA9mFwHO5YXEwzcB9NRubfhH/cc9PkXHAcKwH4GI7xqpyx80eAa+mdA1U5s44qNMCMT6qjarPIS3U5ebJPn4Wd2hMShGGAkqnuj+bnUYAY3g7hleRyP1V61umJ5LgsuzSwx1f7Bo/UoxAs+BlF6Dd7WY3qoK0jMa2yUtjpVxCPT5V9lnFYW5LXDiKoEhAH9yjd0PmnSX9t3F9qUiKfOVwC7AHlPi2omZP2NbQidiJLLQY2zjp1KWBSy+VBddqP55N72xMP4MgFAPN35/VKFy9u4KuvHA
DKIM-Signature: a=rsa-sha256; bh=+auXqZgcWe7xQ7lN3jz0tyMvHEYH8Md1KLPy5CiipSE=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1758617583; v=1;
 b=lB87drY7jL9YkmEUbmkXVrPcnYH4yWz3g9wdUMaGRN0C8F9aC47qe4V7JRhyIMnUHAT+Br4v
 CaxFmi7ygbbW1vNvseJiScEqxjMqEHFGDtwTPbHh9zy5eE+U+NALuYmltnwUaBbnVp5iKM7ILPL
 45ztXjxKDEzmZIl3feWkGY4F+qRw73UjiPLSKqh/vZrtXvbn/Duns9NnELyBSMOqrT7WZgdZXzJ
 /iSCW6jizA0QoGtD3afOO8Nsg97NCRL/fPvhyFQOBH/a2+fmRrtX2Cd13b62nr/ef85AWBbH846
 jIzZmlcOsBUermPQmUyAWt+JM3rK4pkjI2J22+lVK8jkQ==

On Mon, Jul 07, 2025 at 10:24:37AM +0200, Jan Beulich wrote:
> On 06.07.2025 17:57, Sergii Dmytruk wrote:
> > On Wed, Jul 02, 2025 at 04:29:18PM +0200, Jan Beulich wrote:
> >> Btw, a brief rev log would be nice here. I saw you have something in the
> >> cover letter, but having to look in two places isn't very helpful.
> >
> > I don't really know how to effectively maintain 23 logs at the same time
> > given that changing one patch has cascading effects on the rest.  I'd
> > suggest using `git diff-range` instead, commands for which I can include
> > in cover letters for convenience.
>
> Well, no, doing this per patch is possible and relevant. For cascading
> effects their mentioning in a revlog can be pretty brief.

OK, will give it a try.

> >>> +    (void)txt_read(TXTCR_ESTS);
> >>
> >> I don't think the cast is needed.
> >
> > It's not needed, but I think that explicitly discarding unused return
> > value is a generally good practice even when there is a comment.
>
> In the context of Misra there has been discussion about doing so. But in our
> present code base you will find such as the exception, not the rule.

Will state the result is discarded in a comment instead.

> >>> +    txt_write(TXTCR_CMD_RESET, 1);
> >>> +    unreachable();
> >>
> >> What guarantees the write to take immediate effect? That is, shouldn't there
> >> be e.g. an infinite loop here, just in case?
> >
> > I'll return infinite loop from v2.  Tried adding `halt()` as Ross
> > suggests, but including  doesn't work in the early code
> > (something about compat headers and missing expansion of things like
> > __DeFiNe__).
>
> Yeah, untangling that may be a little involved. Open-coding halt() is an
> option, as long as you clearly indicate it as such (for e.g. grep to still
> find that instance).
>
> Jan

Will do that.

Regards


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 12:56:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 12:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128359.1468733 (Exim 4.92)
	(envelope-from )
	id 1v12Yw-0006uM-Ik; Tue, 23 Sep 2025 12:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128359.1468733; Tue, 23 Sep 2025 12:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v12Yw-0006uE-E0; Tue, 23 Sep 2025 12:56:06 +0000
Received: by outflank-mailman (input) for mailman id 1128359;
 Tue, 23 Sep 2025 12:56: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 1v12Yv-0006u8-Au
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 12:56:05 +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 a9e11ee5-987c-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 14:56:04 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b04ba58a84fso949298666b.2
 for ; Tue, 23 Sep 2025 05:56:04 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b29f45b5384sm671968266b.27.2025.09.23.05.56.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 05:56: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: a9e11ee5-987c-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758632164; x=1759236964; 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=5tBdwgS747dBZVBV0IIJCXA3915gEcA/QF5qizjHD+A=;
        b=l7R+VeEjazLebv+Nby664WWBpUTsnUd1J+PtLer6MDv8aU62iGoxH5yD/TJJlJZ+7Z
         a0joDS1hTYtmmvpHEkozzMLJln/DPCgeDmQekZdcPC0UJT6hLH/ntoC6mNMAnPmAqx2x
         Yyl5rERPEiCffgB3x8UnaaC8yNEpsSpTojOlssX3XhCATvs/iZ2W3N5pDVO6CP335+GU
         ZuqdJHQoq6Hrq0Tjvd+i0ZMQ+UorHvU6X01kUtSQeAeSntteEc6RJ/S2vercaNw54Deu
         ydaOpNZKl7lMkrj1WEirheWZq5e9HjzLMzg4AlbrKvcuG/M1nUV5O+rR7o/afksPj8GV
         NS4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758632164; x=1759236964;
        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=5tBdwgS747dBZVBV0IIJCXA3915gEcA/QF5qizjHD+A=;
        b=IM16iCWvXDNBZUaP5A4m6bQLrIgd6feSQQvEa7HLYIl/kZjR1bkUe4dakvhfyGn6eM
         p8BqTSARDLe4+sBhl9BVwGYNj8CLYwEA6k5yOZku84XUC5J84b22HfJ/OwTt0YIpzMhq
         c3htjAMhQtlgGoR846tcwIprPJVYUvMaYb3IAt0zYN0sy2s8TTPeO+N8dyJBPDvs412C
         aestWq77nwti95babF4BWde6YiIjj2Kkik35ktrRGCPIIu9OHyr9CfwtWHt0EatHTy4M
         vbTw162jefi9QSmNJhHbTWW8osQ704SUZPgQGYcEo3G+LbQDIx1Jqp0BoRwQx9xDG21H
         M9IQ==
X-Forwarded-Encrypted: i=1; AJvYcCVnE6LnMrpubFVTCj2gHtYArL2uGVCKv03wxOhugV180VrvW8ftgkg/6zD5yw/ZZuJ8/4gDij0NCdE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwuqTvx0zzFe7b+w8kDHEc2BmHyP6qj01puhTzx07rAK4Mu7sZQ
	saqQ4VIkMIXfpNMpDk/39pWgGEH+QCrVyBC5b/0LaUo2BxFVKqszgSQU
X-Gm-Gg: ASbGncuMS0V/nr2AztAFiODSdT1mobm8vxbgUr+TyAj6yTEADKu6CX8qUZS10R53cjo
	ZmIA2nEEiGm1jir6ecV2WHMFWNLOVZregJXWDsov1EvxJ0f0RGQ1Y6xOv1q67P5kfnp45bK+IkO
	TFGxyiJidz1NWKbGSFZR+3XcHT2moM7gRaYrVi4QLAPDLMbuF0E+SiYpHjr8732Lls6wMX35W2F
	gF2FkoAPByY+q9pQXozZRQgiA6dGynYFXTY1ExMUIgdn7Deh9oYwqmOeF8d94QhLa14KDOjo8WV
	ak466zXm8jnJWeJ6Y9MQxwB5u3LD9ZO7WjgvMrY0NyaLsu7wC3GtnklrATLIXenUhxEySx2C3Oa
	2nPNSa5aCyr9aC4XSBwI0lGJqYwQsInKcB59VuH5wD0VIEiJtzs7eYqR7Jl29NKjzjBbeV+5S
X-Google-Smtp-Source: AGHT+IGvTj04ixM3W6kjbnuE60+qySvz/SpECJ8DcJ/qV6ivZLIh4aVbvFs+qCHj/BZDKJlZg/tLAg==
X-Received: by 2002:a17:907:7f91:b0:b04:848f:a0d4 with SMTP id a640c23a62f3a-b30263b8326mr239483166b.13.1758632163362;
        Tue, 23 Sep 2025 05:56:03 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------D9E9RIuLltWrosOGlBe0fF4b"
Message-ID: 
Date: Tue, 23 Sep 2025 14:56:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 8/8] CHANGELOG.md: add amd-cppc/amd-cppc-epp cpufreq
 driver support
To: Penny Zheng , xen-devel@lists.xenproject.org
Cc: ray.huang@amd.com, Community Manager 
References: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-9-Penny.Zheng@amd.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250923043826.3831957-9-Penny.Zheng@amd.com>

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


On 9/23/25 6:38 AM, Penny Zheng wrote:
> Signed-off-by: Penny Zheng
> ---
> v9 -> v10:
> - s/Support/New/ and add a full stop at the end
> ---
>   CHANGELOG.md | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index ca1b43b940..7b9518ff08 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -36,6 +36,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
>        Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
>        and 28 (Temperature Probe).
> +   - New amd-cppc/amd-cppc-epp cpufreq driver.

LGTM: Acked-by: Oleksii Kurochko

Thanks.

~ Oleksii

>   
>    - On Arm:
>       - Ability to enable stack protector
--------------D9E9RIuLltWrosOGlBe0fF4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/23/25 6:38 AM, Penny Zheng wrote:

    

    

      
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
---
v9 -> v10:
- s/Support/New/ and add a full stop at the end
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ca1b43b940..7b9518ff08 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -36,6 +36,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
      Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
      and 28 (Temperature Probe).
+   - New amd-cppc/amd-cppc-epp cpufreq driver.

    

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

Thanks.

~ Oleksii



    

      
 
  - On Arm:
     - Ability to enable stack protector


    

  


--------------D9E9RIuLltWrosOGlBe0fF4b--


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 13:19:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 13:19:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128374.1468743 (Exim 4.92)
	(envelope-from )
	id 1v12vt-0001N8-Bk; Tue, 23 Sep 2025 13:19:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128374.1468743; Tue, 23 Sep 2025 13: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 1v12vt-0001N1-8N; Tue, 23 Sep 2025 13:19:49 +0000
Received: by outflank-mailman (input) for mailman id 1128374;
 Tue, 23 Sep 2025 13:19:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v12vr-0001Mv-Qt
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 13:19:47 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f7e3596e-987f-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 15:19:45 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by VI0PR03MB10354.eurprd03.prod.outlook.com
 (2603:10a6:800:209::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 13:19:38 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 13:19: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: f7e3596e-987f-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UjAo23NzGev5Ab2JJnhHqF0W05quE4sHRKH9i7kjxeU0Exh9vCwC4fpWoObmvw1jFRQG2PqjA5u6MZDRtxiaBRAwIWB3fMThZjo4eFIfJZRDSPfN9h72QNRoKd+vGiaqTo5B9Q7GAAH20WsgFceQajQjBeuLvLshoNWFjIlHE5YAp5XPIhS3qxX++l3qZPzHpw1uash5fwxGDVAAkNfkKi1SQZZAK5IP+lx/pdIyRbY98a9s14VFaec6LQH+sYgZTpdAVTQ5aa+OZMdDx46ZWceiKCE2XP0MgacunyuCxVGphvXKX3SESiuWh/sWQbK6qk4vgJlz5bzDgj6R0148gA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EiyiYclPvxXuCdt4j8G3TCLnJRhWWiPszQ8is/PTa54=;
 b=YV1Rag6DfFxfXj5evb/+Iw8YYQsB74yJmdkoerHICLQUDpMTIdjWp9e1qajDr/JaMCJgx8imrrxn6ucXvKuITEZ8Wu7BBwEsKI8u9BP0MGjTtMELQgxsV6KDBICQqe33fq4E+gdlTqmAwGJbiYb8jd0plqNFMuMc4iHgXBWV5qwX347yLfaWARJP5Y3KdlEpZDsQ/cua9YrP3fv+9N7RxTm/wc7RASuOfFz6en3+uUbflmijo0BytnnZpUEL5JWdYjt2CiM0zf1XSAnzm88Uo6N6CXAYeK0plV3z2vpHLAFLmNiLsH4m0+MXyM1JpeZkBaq0POZr5YwrmtH7Aji7cg==
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=EiyiYclPvxXuCdt4j8G3TCLnJRhWWiPszQ8is/PTa54=;
 b=lUo1GESMLcLqXDtMQWuaDWIhQ4mxKmqZyvuqWjOje39cspZcxrYqwDPQOqJxbBC1Dy3YT/mdJT5eqMTESJmJaHM9HREvIjaC/90EbYxrvI8K+io2kYGQ4uGsu2VQaAjyICPyaLRKBN0PjJ6dF8JHwxjfiawtklm+yir/rImnCyyuhAydG1yBlsNSF9BR9xgUVH7tIPAJHuP5hsrNX9b4qOms5lIdhSMX7y3UNFSLUOzjfzs7SpUIScKawaYQQpjTs9tiVwAvbclTsUrMrO4b3Ko1bacIRdd3MNPgGOvIPKvm/bjCwyns543cdO150gKPgJVpEFGteu063wdBLEvC9w==
From: Mykyta Poturai 
To: Jan Beulich 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , Julien
 Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Stefano Stabellini , Juergen
 Gross , "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v1 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Topic: [PATCH v1 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Index: AQHcKJYT9WcJIkqhZk6dQ6fXEj6SxLSZCGOAgAe/3QA=
Date: Tue, 23 Sep 2025 13:19:38 +0000
Message-ID: 
References: 
 <7d10f4d063a55920acbb8d477b885552379a6116.1758197507.git.mykyta_poturai@epam.com>
 <337596e3-e522-4770-a64b-6c8137134739@suse.com>
In-Reply-To: <337596e3-e522-4770-a64b-6c8137134739@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_|VI0PR03MB10354:EE_
x-ms-office365-filtering-correlation-id: 15354c46-3808-48c4-982c-08ddfaa3d93f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?dzFlalhzaW9aSGxBYzkyUTQ0V0d6WFhXM05ucFpuNzVZZmxCMFlhTXZyb1Nx?=
 =?utf-8?B?MjBmZjExRGE1bnBEZFJvc2FzdnIwS0JlcjVxTjh6b2RXdG9MWElOUFVtd2N3?=
 =?utf-8?B?SXZLNlFLOUpielZOT0F3NEo0RVc2LzRKY2x2MnZ6Q1RkWTJmZGhvRzBLSHRG?=
 =?utf-8?B?c1NSVlp1TTM5L01wYWN1V3ZXOWRSQ1JZUldONFVCblhYc2EyUkZoSlFsRlo4?=
 =?utf-8?B?KzREYld5UXdKMTlBaTMwdzRIMGk4WkVnNXZscmF3Zmc3TGVZcFRjVUgvRUZo?=
 =?utf-8?B?QWhVQ0laUlRuaS9jVGlObm1lTCtuWDYzZnIvVHVZQzl5bXFiK21VS3drUy9W?=
 =?utf-8?B?bkRMeEtXMmpoZVVWajVUNU1mb2V0NUxqN0xKRUZHVnJCZjFsWlRNQmxXYmJ3?=
 =?utf-8?B?OGZHU05NblVBUkR1bjg4S1doNUFDZ1dqa2FQWVRzRVRlaUN3OEJCbjlxZVRr?=
 =?utf-8?B?SGJscmVFeStXdmlWNDBNemxDQyszU2hYZ3RPMStEU3duWWRGaVFmUmRCMGhD?=
 =?utf-8?B?cVNoUkxDK0pVc0VXM2gzMlAvWjZlajRDR1dzdGxHUEExdXVOYkczT1I2eWh6?=
 =?utf-8?B?TkNCejIrb3B5RUN0K1lZNFN5ZmZRQmx4SVJLRW5xV0xKeThYNE1ReEw4NUho?=
 =?utf-8?B?Y0g1SzVZMTkxVVY1M1VlcjBDWnFTU0F0cHQ4TWlOYU81R1hBM3diRGJpMHZo?=
 =?utf-8?B?TDhBS1BxdHhuZmMrcVpUUXF3bjdXMjMvbUwzVXRhelZhR0lhMmJRcS85bzVL?=
 =?utf-8?B?cExxbUNoMXVrY0Nnb3F6Zk1JMVVjU1NUaTdXSlJjaEU2clJPSjQ5WnJRU1Na?=
 =?utf-8?B?V3c2d1M4UENtazBVcUVjcXBDcDFtQ3ArTnVLWlFEbEZHbDBSY1QwN3pJUzdM?=
 =?utf-8?B?S2dVNFY3RDFiNTQySGxUTVZ4M2ROWDlmd29KRE1EWjlBY3NlQ3cwNzFlalpi?=
 =?utf-8?B?bFNZQm1ZSTVRVW9aZ3QvSmtzMmlrcllWVnhSaVhBTWdzSWdsSlNCVzFBbXpq?=
 =?utf-8?B?ZUYvaTJMaVlOYXF4TDZQUlR6NnJOa1FuY3J4SWVrNlovOHhjV1Z1aEp6QkNT?=
 =?utf-8?B?dmRCdFBQb3lVYS8weWREOE0rSHltcDVubUY1UnBDMEVNRHJvUWRlazY2c3JR?=
 =?utf-8?B?SlB3VGRiNWI3U3JyWkxSdHpLSGQxekQ0Z3lVUnVrY25aSWdYNUpNRGdHekR1?=
 =?utf-8?B?bmhlVGJvNkVGclhyakViSS94M1l5ZWpoQUkraGcvSmM4aDd6d2poVEdIbHkw?=
 =?utf-8?B?QklnQkhaakZsaGtJQ0t3R2NWWFVsbUovZnhPV21IZUdCTlJ3eDdDWUxMNUlI?=
 =?utf-8?B?cFRmQ2h4N1dBNGYxaGtkWlNBWDRDREtvRFFiVThEYzJ4R1ZTdktjclhmUnFH?=
 =?utf-8?B?TnpHM1gzWEU3M0d6UjRFajJRVGJ0WWxiMDhZN2pvaXU2eVlKeitvQjVoVGF6?=
 =?utf-8?B?K056OHhVYUtqUmhnQXF2TVVJV1l5Y1ZZM3hkUlZvSnhOdDVVMnNJQkcrTHhG?=
 =?utf-8?B?WnV6bEd2SXdDMnBVcnFSTXlxWkhHS0lCaW9ES0tuU3RvZW1hT1pZL1J3S255?=
 =?utf-8?B?cW0xSzNLSzZCNkoyWEoraHpVdHNwK0JrRkJYa2FaY1dlY2J1ZlpHUHFFeFZW?=
 =?utf-8?B?T2V4ZEVrbDB2U21EYmZMam93VTc5bzVBcXRPSk9OMEsvVmlOOEt2Y3RzSEly?=
 =?utf-8?B?TmExZmFOWU90UXN5bytUMGJjdVVXbUhpUXMzais3YmxBMmhPSndpdDN6eEdM?=
 =?utf-8?B?Y040a29mTXY5SE1yZVcvTGxxNU9ock96TGFxMmJ5bXBFWWV1UmFpM0NvTDF6?=
 =?utf-8?B?Y3ZpZnF1RUFxTFpNOGlqWTBuSHQ5V3VRUDdwdWFJbU5Dc2dkc3V5bnlSSUdH?=
 =?utf-8?B?dzFHS3Q5dEZiOFdYMzVqVFpXM2tHM3FmMGVrU2tPRnFjNm91cisxYXhFSGNr?=
 =?utf-8?B?ZmczRitsQ2drS1J6bVdkdzhhd2ZkTiswQjFrbUd1UTVWWEQrR1J2bTFpWllE?=
 =?utf-8?Q?FA+QL5H0Q+yaJ3ZNsQU4en6Ayfy4R4=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)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TzhGVHZOekNqdzFpS1Y1bkh2L0tLVEdXVEhMZ2trTHA0T1N6dDUrZ2dvbnJD?=
 =?utf-8?B?NituSjFMMXI0MldEeFVCdmpuVE9rWWxiMHlzT0NJMnZWdCtCb3U3ei90NktB?=
 =?utf-8?B?d2VKek1uemZ1YVBxZlExcXNmcGJPdUxrNUg4SlZoOGRtMXA0dVpCTzQ2MWhr?=
 =?utf-8?B?M2RlSmpFSzBYNmZoSVMyT2dHWXhIUXJJTlBTV0dvOWFrWUpEaXIxWmtLalNO?=
 =?utf-8?B?VEY0dVQ2QWpqUEVvU0tBaWkvcVcwK25LUXUwQlExd2xwNFdFQ1llcUhKd0Ez?=
 =?utf-8?B?YUtHaDcvUTJBVFkxcnpDOXJuOGNOL1lhMGg0L2c2QVpPNjdYRTFrN3BpY3JZ?=
 =?utf-8?B?WVNHZkQrWldxYkZXa3FjeE5GNGJKUTFLQ05Sb3VNMnpPUW1JanNuSkRtMFRF?=
 =?utf-8?B?SmRjVkh0aGloMGV0VzcyU09jdVc4aXdhbEVtd0lxRW85N3YzM0ZZL244M3hG?=
 =?utf-8?B?ZW94eEhyTllRcnNtS3VDaXBENjZmWVo5cmhacHo3Y1Q2T2hZdkV3YjlNc0dB?=
 =?utf-8?B?bXUwOFhQUUV5SkFvbkdLYWxCSWVDZHFyelRjdXZ4WFMrUE85VW8yaWo1bXJD?=
 =?utf-8?B?S2dZaVZOcEZRbjJVdzYvOUNlTUlBNEpzeFh4QVNpUndwM3BoWUI2a0NCNWlO?=
 =?utf-8?B?TCt2TVkwS3ZGQWtsakRqeWxxY1p6MWtLOEZnNllDbDMzWXQweHpkd0V1cXhn?=
 =?utf-8?B?MWFhY3dES1RTRUliY3FSeUhQWEpDN0JSaHR2Q3BkQTZZZkQxdkgyaUs5Z2pl?=
 =?utf-8?B?ZDJzNTZRRVd6anNoNVFMRFl2dWJUaitnTHN2ak9FbmtWVkRlTTJXNWtQREFW?=
 =?utf-8?B?NTRaa0czRDdtSWtHa3lNREkwYjAwSTM4aFJNY1lXVWVrd2trNnBWVG5rT1JO?=
 =?utf-8?B?TThTUFR5ZjFEWS9MQnoxSjRUK2xkT04zTFRYenlBdlhjSnpscUtzSjlRV0h4?=
 =?utf-8?B?cWN0bFA1YlBJSlNxejd0K0pMN3VudEl6VnJGMlk5dE95OThQdnlMMVd6MUFE?=
 =?utf-8?B?bFFWNW5IWEFIRHRpdXNFNFZtRW8wdHQyVlM3aXk2azNlb1RTUVVOWEtyWGlr?=
 =?utf-8?B?d2NxSE5raGRZRFFKdzNBbWJJYlV0R1lkaHA2dUpLYXhZd1BLNFBOWDhKNTg1?=
 =?utf-8?B?ekxvSi9LZHlHQVJrSmxmOHV1Z2FlVDc1MjZrUVV3S1lGUk0rUnZBTnVPN0F2?=
 =?utf-8?B?MlVERGdhNVJydjU1WXZQcGtadU50K2tSaGhnaWJWaDFXSG1SdGdFeG1qZTV2?=
 =?utf-8?B?Ym83UzE3OVBTeXc2R3lDekkzN2lHUU5WcVgrLzJtaURrOERISEE4RG9UbGxl?=
 =?utf-8?B?ekRkb0EyYmk1eU82UWN1N0liY2VNZVE3V0FqNlNORTNCeXBUZ0hxN2hudXQ5?=
 =?utf-8?B?Y2xnQ0hzaWcxYUo5bXNZWUxGYnlvU01SVXdoc3lBZjVsSldveU94WGhUb3ZC?=
 =?utf-8?B?ZXZ6d2tJUTZlcER6cy9wcmVmT2Iyc0dqRTNvRHpvZGhEMFp5NXNJc2N3R2RM?=
 =?utf-8?B?N2pqTE1xL2JTSDVsSEkzOUJNS2phZzRLRHpKWDA5cW1sNHQ5djdBZ0ZpR0RY?=
 =?utf-8?B?Q0RZdW5WV1B5cGg4N21UVFZoNmZLSUMxTm42dkhkSjBPcjlMN2dtdzFWa2Iz?=
 =?utf-8?B?aDg1a0QvR2RSdzBtdHoyZFk1NDAyU0NSd1FPdktIZXFxUHdqa0VDc1lBWGRK?=
 =?utf-8?B?YUxtMEtQeitOdUdxdHFjcy9ubHN1a0ZaQ0w3R3VVa0dwdlMzZFQ1YnNlbVRr?=
 =?utf-8?B?ekNQRVhiNUhnODEvKzVlZkdBanNFT1BhVG14ZUFRUkw0anFQYTczbCsrdzVQ?=
 =?utf-8?B?VGFqYnBzc0llQ0RUQ3k5bm9ycUdaaXB4NkFsWlptd3EraWNVNXUzY2Y1TTZa?=
 =?utf-8?B?aWRUR0YzVXlEZHp4VGkwZWExS0FsSWNyZjVOZzNtS3FsSEhDZHhibHNIM0h2?=
 =?utf-8?B?L0JUMitmS2lzZmNvSm14ejNlNGRnUEUzbjhyWEcvdm96T3JocWFwQmUza0dV?=
 =?utf-8?B?THBQc2xiZTFzcnFVVGJHWlBhdTRVNytza080ZVZiLzZGajVCSXJrdkk0ZE9z?=
 =?utf-8?B?eitNYmxUaVo2OFJCUUtDMjZNTXlodENIa0Y5TVpMWVFzYlNIZTFoRnprWXFO?=
 =?utf-8?B?OWVjWDdETjB1VkpNeGxmcjhBbVBZbWVMODNZb0JRMDNXamFvUk9HUjhRZDJo?=
 =?utf-8?B?dWc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <512490C643F9B14399E7843F2D742D39@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: 15354c46-3808-48c4-982c-08ddfaa3d93f
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2025 13:19:38.7109
 (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: ocSYdT+t7aNqvALt1DBGHS2p65b34DFLXl4leurodFRCEsNG5YIA8VJv9DUasoXJOdx+f4QicU9ge8QBb6sWrA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10354

T24gMTguMDkuMjUgMTc6NTksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOC4wOS4yMDI1IDE0
OjE2LCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+IC0tLSBhL2NvbmZpZy9hcm02NC5taw0KPj4g
KysrIGIvY29uZmlnL2FybTY0Lm1rDQo+PiBAQCAtMSw1ICsxLDYgQEANCj4+ICAgQ09ORklHX0FS
TSA6PSB5DQo+PiAgIENPTkZJR19BUk1fNjQgOj0geQ0KPj4gK0NPTkZJR19IT1RQTFVHIDo9IHkN
Cj4+ICAgDQo+PiAgIENPTkZJR19YRU5fSU5TVEFMTF9TVUZGSVggOj0NCj4+ICAgDQo+PiAtLS0g
YS9jb25maWcveDg2XzMyLm1rDQo+PiArKysgYi9jb25maWcveDg2XzMyLm1rDQo+PiBAQCAtMyw2
ICszLDcgQEAgQ09ORklHX1g4Nl8zMiA6PSB5DQo+PiAgIA0KPj4gICBDT05GSUdfTUlHUkFURSA6
PSB5DQo+PiAgIENPTkZJR19YQ1VUSUxTIDo9IHkNCj4+ICtDT05GSUdfSE9UUExVRyA6PSB5DQo+
PiAgIA0KPj4gICBDRkxBR1MgKz0gLW0zMiAtbWFyY2g9aTY4Ng0KPj4gICANCj4+IC0tLSBhL2Nv
bmZpZy94ODZfNjQubWsNCj4+ICsrKyBiL2NvbmZpZy94ODZfNjQubWsNCj4+IEBAIC0zLDYgKzMs
NyBAQCBDT05GSUdfWDg2XzY0IDo9IHkNCj4+ICAgDQo+PiAgIENPTkZJR19NSUdSQVRFIDo9IHkN
Cj4+ICAgQ09ORklHX1hDVVRJTFMgOj0geQ0KPj4gK0NPTkZJR19IT1RQTFVHIDo9IHkNCj4+ICAg
DQo+PiAgIENPTkZJR19YRU5fSU5TVEFMTF9TVUZGSVggOj0gLmd6DQo+IA0KPiBJIHJlYWxpemUg
eW91IG9ubHkgZG8gd2hhdCBpcyBhbHJlYWR5IGJlaW5nIGRvbmUsIGJ1dCBJIHF1ZXN0aW9uIHRo
aXMNCj4gd2F5IG9mIGRvaW5nIHRoaW5ncyB3aGVuIHRoZSBzY29wZSBpcyB0b29scy1vbmx5LiBB
bnkgQ09ORklHXyogcHV0IGhlcmUNCj4gY2Fubm90IGhhdmUgYW4gaWRlbnRpY2FsbHkgbmFtZWQs
IGJ1dCBwb3RlbnRpYWxseSBzZXQgZGlmZmVyZW50bHkNCj4gS2NvbmZpZyBzZXR0aW5nIGluIHhl
bi86IEFueSB1c2Ugb2Ygc3VjaCBpbiBhIE1ha2VmaWxlIGNvdWxkIGVuZCB1cCBiZWluZw0KPiB3
cm9uZywgYW5kIHdvdWxkIHByZXR0eSBzdXJlbHkgZW5kIHVwIGJlaW5nIGNvbmZ1c2luZy4NCj4g
DQo+IEphbg0KDQpJIGhhdmUgY2hlY2tlZCB0aGUgd2hvbGUgY29kZWJhc2UgYW5kIGRpZG4ndCBm
aW5kIGFueSBvdGhlciANCkNPTkZJR19IT1RQTFVHLCB0aGUgb25seSBzaW1pbGFyIHRoaW5nIGlz
IENPTkZJR19IT1RQTFVHX0NQVS4gQW55d2F5LCBJIA0KY2FuIGNoYW5nZSBpdCB0byBzb21ldGhp
bmcgbW9yZSBzcGVjaWZpYyBsaWtlIENPTkZJR19IUFRPT0wgZm9yIGV4YW1wbGUuDQoNCi0tIA0K
TXlreXRh


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 13:38:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 13:38:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128387.1468753 (Exim 4.92)
	(envelope-from )
	id 1v13DR-0004ER-PS; Tue, 23 Sep 2025 13:37:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128387.1468753; Tue, 23 Sep 2025 13: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 1v13DR-0004EK-MP; Tue, 23 Sep 2025 13:37:57 +0000
Received: by outflank-mailman (input) for mailman id 1128387;
 Tue, 23 Sep 2025 13:37: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 1v13DP-0004EE-VL
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 13:37:56 +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 810c698c-9882-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 15:37:53 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PA4PR03MB7150.eurprd03.prod.outlook.com
 (2603:10a6:102:f1::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Tue, 23 Sep
 2025 13:37:49 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 13:37: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: 810c698c-9882-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=c8E7FtGdj+kUmYNXDFZ2KuRcXT66gY/vc0Cb9hc6xmgOnerPBx6URFQ8RN8MlLjZD0alebGxi3ISOp3/4VlJ7SVCc/WUbGl5RtZ4UMfy8m9gxaiQ2D3suVnhnsBWTcPgjXtG6BufIg1ZcTNa6mKjzSd6qPcYg9dMaMLx2lb/emwcHT8IavZk+9YnYM5hiTQRjad3HQyRctw3+DwLXezDEpb/WP20SZswj+PuinNINKMUq8/4XFuM2Emv1DNWuznwmPXrPNTv9JoxCWT8oMEmYgg9sneLieriEauZljFASb9gde+T6Dxge3qY6ROA5R3HfnJbN79IkRn6Xub/ljGtkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2xODpB8sHvEl/yb200BnZDDp3n6ihKEeBe5isyzfX0s=;
 b=pbY8Voeppg3IPRXtUEHKnZfCrB8PYk/W+2N9V36P6rjk79ra1MsY51GKOjLDXUMJrjaCr8K6/8Lnx4eiL868le30BfyU9E8bi0qMuKCZy0AShDWDxafTJH0MBH1ufqClAxkcjdAaVXUT9WLt5SneuxXeCFOMqR4lXqlpT1dJjBfWmCFMGWndWzikulNXb55Ad168NoGy9Ydjdd0U6TSRoYF/LaG+cN8Y5276sj/NQm8wK0xF2uUNskX/QZ3UHpRL6MnIh+pLlkilSWJQM0QdH8GPj97yFiaH5J7Y3PEJN4xNT6aINng3QHsrzxbsmTy8ofsa3r51Aj2WJhUvRIFxQw==
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=2xODpB8sHvEl/yb200BnZDDp3n6ihKEeBe5isyzfX0s=;
 b=IKsNQ4J4woi5yQloCXhFG9wKJcfzH/Glc2qvRaDELLRTkn5D2ShSkVvQUFzixUTOFvQs1lAt8OVX5mdQPC16PQ3TAKfYSLis/UIi9eSKupxvzZNyf50oW3Nmwci1m/OY14i9M1iwbpPNCQXD9ngNNMB7ifKHd/w/UAUVbeBLzNbraVZ2SEXLfkiVckeMC0qDhuxgSS+sZONjwtbfwHi4Cx6IrwrDKbSSFcLkKkrapZIf2FJXCAjt0Clk1yn6Zgnpb/YroYjONjDH5CyBKku8u/BdI4TnG1oQV9ZHHMHS2v2mQgLIR9ajbxP/PgdXQvabJJ5kr/zHH2vZ3VBcV9IifQ==
From: Mykyta Poturai 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: Re: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Thread-Topic: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Thread-Index: AQHcKJYTkGTrKHgw3E6UlX6hg7Or+LSY8SMAgAfcMoA=
Date: Tue, 23 Sep 2025 13:37:49 +0000
Message-ID: <721b5d6a-257e-447d-bac6-675ccedc3928@epam.com>
References: 
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@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: PAVPR03MB10102:EE_|PA4PR03MB7150:EE_
x-ms-office365-filtering-correlation-id: ee0b2e43-306a-4b74-981d-08ddfaa6637f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?U1NJd1h6TnFOVUZIeU0yak5ycDRxMllmeXd2V05IRCtXckFZdGhNa3Nhdm5Y?=
 =?utf-8?B?akNyTXhQRnd6Tms2RmJiNWhpelVXOCt0ckVCb2o4a3BlNUtyRERVTFBmZ0dp?=
 =?utf-8?B?RDVQbjJTR2w4eTVrenV3YjBGcGp5T01XK2UyZ1VLWjNuZEVLR0V1cnY0ZGNy?=
 =?utf-8?B?aGtxc3N2VFZqb3hvT01ZVEhJQTBsbUZkMzVvbUZnLzF6dSs0bjBtSkFLenhx?=
 =?utf-8?B?eFdNYXNaZ280a0w1MXBvdlpUUzUvUHNCVXRmN0dLdWk2TVVqUWNUYjlOYmtY?=
 =?utf-8?B?MmFnc2xVcThOdjdxZ3hYVGQrMmlaYjM1MnFoc29xV0tjMXBPc2VzdVFaNVh1?=
 =?utf-8?B?bE5UeGRVNmxTWVkvYk9KM21rSmZvRWd1YzdJb2lYOEg5eWtXUDh5RTI1Tmc5?=
 =?utf-8?B?TDlYbEFBd0p2UDFmcXBiVFdveVZHUW4yVGlXWlZ4RUY3UGxvV0dCOWNVQ09T?=
 =?utf-8?B?eVhJbkdwZFhZR0M4OU4yeWdkNmk3Vjk0VncyOGQ0OTNqSS83UkpUdTlDU09V?=
 =?utf-8?B?VFR3R0JkQncxL1BmSS82RzdXMmRHUjRXNWtQVE5GalpJRGVYOVBmOTlwWmpS?=
 =?utf-8?B?MXNqTXh0ZXg5MFk1dkNxZk4wNlpOczNXNEd5aWxrclRZOEdjUUVIanhPdE1t?=
 =?utf-8?B?S2lManYyWVE0N29xS0dZa1N6bzJ6U3VJVURpdWpUdVdqdk1iOTJvckN0WUZv?=
 =?utf-8?B?dEZFSmhQeC9xcHdKMnF2WkNhV3ltVVM4QXluaHBCY3Bqc1FZSklTV0src3ln?=
 =?utf-8?B?M0hqYmlEME1aMzZKUFR0MlNlQjA3NTBuemswekdDMGVSVk9kSjFFU004VzNL?=
 =?utf-8?B?SW1RTHoxR3RSeklyc3ZRbnZsSU4xSWYzVFdMc0thRjl4OEhxQzFFekhDcVBQ?=
 =?utf-8?B?VitPL0F2VVc4aFRYQTVuTVh0L0dnYWp2WFdtMFE4bUw0U3JyNjM2d3pXWmJU?=
 =?utf-8?B?YUpJTWNRTnBhcmdVS1FIYkNhT25EQ2dZQ2tHb2p5NmEzeVhnelhrOTJYZE10?=
 =?utf-8?B?SVhub0dTZTg3TDdZeFlyVzI3b2wyRTMzMHBQS1VzZUtvYkRlUEJJQ1JYZkxS?=
 =?utf-8?B?eWx1VTNoeU5aTXlpcGxoV0JuanJ4QXloUktYd3NhQkk1a3M5YWk1Q2E2TDl0?=
 =?utf-8?B?c01Qa0Iza2JueVRLUlEyTE5ka1dGMy9sOUg3bEdpV0xIc0lxbTlteTNTZkxT?=
 =?utf-8?B?Y1JNSEhmaXB1UFNvdm5RYWt1KzAxOEFFL1ora0JqeU9tdXJwWEQwdXIycXl0?=
 =?utf-8?B?Y3pqUGdaWFVDR29BcGVtaGdLM2ZVNEFORmQ5R0oxUlpBVG5RbEx0cEd0ajhZ?=
 =?utf-8?B?NE9RUkxvajhxL0xIM0ZyR3JlWmhyWUVUak1IRkR4cEZVTVJYUEkrRHdGWnVC?=
 =?utf-8?B?K3ZPQVpYZG9raGxjeVV5V3ZLcis3dFhORDN3V0N5TlFwWU85SXhHdGpVOGFh?=
 =?utf-8?B?ZTNDTUFLaGJvcVphQXIzWU5hcmRMbTlPdm5GMzZyKzZtSHN1WmxscTV0NDZj?=
 =?utf-8?B?K1ovV2VObVA0QnErU1Z2Q3hFY0hTa0htdUwwc0JlVW9sWFpFMENOZFNSUlh3?=
 =?utf-8?B?L25YU1RNYVh5MmZoR3cwNzU1M0FJY214a21SQk16S3hHS0FtSndBOTN6d3VD?=
 =?utf-8?B?ZWprN29tRWtIcE9RcXA1cTBFWGFFTmVPLzhYbVdvdmptdlR5UE9LQkdoNjk2?=
 =?utf-8?B?M05pczl3emptWmFBQS9lVzlsZzB1MGZGTWM2WVhWVHVQd2d3Qm9IWlhxSVZ5?=
 =?utf-8?B?U2UvYUZ5em5yMkl6b0ZCTU1WZFM4Qngwa0lyVnA4K080L0p3WkpzK2pIMzYw?=
 =?utf-8?B?VTVZNmZNenRva3dZd04xRDc1UzNxL3RXU0IyanFVTFpJejc4WVBOS3BZY3pF?=
 =?utf-8?B?NHljeTV0S3R6bXpVNTUzZVJhZ1BFYjZSVWc4V1dnUHpSTXcvV0ZoU09aUmNP?=
 =?utf-8?B?cWJsM05FQms2a2FOYklHVkdXeUcybFppTUdKUVNBMWdHbzFXak5aMkdoRDB5?=
 =?utf-8?Q?Q1SAcFJWmUvzKlOOBKCnfx7mFfHSI4=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)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?akx0UHh0Y3RIa2VzS2J2ZEZDR3lFeUttN0d3RUpudGNILzROUEJBQjUxUnd3?=
 =?utf-8?B?OTlMSVdubmoxeC91SWRmWFBPU3VrdmxQemo3N0NHK1pRbDlnYXZ3cUhST29m?=
 =?utf-8?B?UUJOMkRwSzNucVVJMTNvMk94V05lVitJN0hpVzRvUWdBQ0RUSnowRWxkOStl?=
 =?utf-8?B?MVhiazhhWUxDUyt6N29JZ2VWMFBLODhsS1FQZGZqMHBsbkFFMVhhRFlYUG91?=
 =?utf-8?B?N0xlZjQyUkt6M1FEbnZiUU00MTgwUks3eEdmcVZqMnF3VEpzRDEyMWZ3K3lD?=
 =?utf-8?B?bytBcjdRZ3paenNtaXNXNjd4OXd5Uyt4UCt1cWplc0gwYUJKenNENDFTcXBt?=
 =?utf-8?B?RDJpRVV1N1JxbjVRdFJhRktqZmFKQi85aHluVjF0R3ZLdEJyMGdKTXVkbk1U?=
 =?utf-8?B?d0RxQlRsSDdNOUFBOHVtc3gySVhKOUtscFc3L0hRdkxUMThRRkpIUS9jYzc1?=
 =?utf-8?B?VzZWdDdVUWpxbUcvMndxYWJGanVDaGE0Q0VOaEJLdjc2NXoxRE1DeWxkN09Z?=
 =?utf-8?B?aXV4OS95L0Y1YVhkd214Vm9pVXJqdFZhRVRaazRQMThLaDQ4U1J5WDNZdHpn?=
 =?utf-8?B?RmwvTUQ1aEFUWnBQUTJWVFo2WCtXNWV3VWJwYUZmbW13QXlSMUpPdExUb2N4?=
 =?utf-8?B?ZXAyVTZsaUpaU3RQaXArY2k3L1hzakxtT3JscjZNemptU0VzREZ6SzVSNklY?=
 =?utf-8?B?ZVNHZW9UbmJiQ2MwYWM3K3NXZ0Z0dUsrMWc0RitCcVYyQ1YrTnFlTnA2Q1k5?=
 =?utf-8?B?RnRMVmZpTlFTZlBpUGUzZkxzck94cFJuWkJ0b0NYakVjVXA1dEhyZVpGb1J2?=
 =?utf-8?B?dGQzZWJwNWlMZ0k5MVdFMkkyL0UwaFlkdjNRQjBYRmRNaGpFMFdEc0xmcTJD?=
 =?utf-8?B?NkE0M2ZLelhqZStOa2VwVlhTOExsV2hERVdzRGxadHlCeDZBa1FLRGZZY25K?=
 =?utf-8?B?aHBQaWF0c2ZSS0hzQjZpU05UYnl0TVc4VWFieGdiV0FPMVY3emZoSnpmaXBQ?=
 =?utf-8?B?YVRaL0xSTnRUZ1dYMUlGdmpIV1N3dEg0YlRsZ1k4b2tZR0szbGJ6RVRhRzha?=
 =?utf-8?B?bUwyMzhGYUFMSTFhclg3QXJlZExrYm1yWHlCZHdWVDJhdDljTjMyMGl4ajFu?=
 =?utf-8?B?ay9pYUhhd3YvSUVNQjdocmZyZ2J3VFVlditLdWRaQVp1VkdVQUhGVGIzRTZI?=
 =?utf-8?B?dTFtMGZYbUVPZHpPTUN2RGMrM1U1QndFZVkxNG9NdEhkM24wOWdKdVB2U2hq?=
 =?utf-8?B?WTRHWVp3QVpOTTZCT2FKUWJiR0dsVHdjN0N4UEZaSlluOWt2NDdGR2UvQ0Fv?=
 =?utf-8?B?eEswVVlKU2RkRGVzU0FuME50MUlUVVE1bE5lUXpORjRMamxtVzA0MlUwdFFI?=
 =?utf-8?B?V2pXd3pYTWZwcVloZjEzbUhzMGZ4dzFtaTEvTXJDUzBPOUNSakFXaGMyVS95?=
 =?utf-8?B?S08yRGUwZ3BNeFB5amMzTGYvaHNmVUtBMlhDYVdNT3BaSVNXWkc1Q04vWWFp?=
 =?utf-8?B?cUkzWXJLR1RFVXVWTmViMnVvb2tMV1I4eDFXTlhrRWhKZGU5VnprTStrUDZu?=
 =?utf-8?B?VmhrSHgvRWlHZ0RsZ0RLVTZ0bnNtMFU2M0RTaExzZXIrNzlIbjlNMStHUENE?=
 =?utf-8?B?WmZMZUJHRUIyYUNIWU91dXhZZC8zd3FmQ2hqZi9RUW5mdXlrM3phSno3OHg4?=
 =?utf-8?B?bEdwakJHM01aL0ZlekovZUduVlBURGgyQ1NJc2ljaXFWMmVIVHhjcmNOcCty?=
 =?utf-8?B?Rmp3end6YWdjRThHS2ZSS25hK0E3SDJaSFV2Y3VpY1B6R3k3V0hCb0lTbTJR?=
 =?utf-8?B?a1d6dFpJRzlIMGhDSUdvZTVZK1Bsc2pZUmRPdG91MkMvbitsVTNIam9jVXdF?=
 =?utf-8?B?OUlBWFhtL1A4NVlwZkFCNEJNaWJwVWJ2RUlLWiswaFFVd2k3WkZ3VlVRMW1B?=
 =?utf-8?B?RWtKbVI1bitWUDlGWDVDOWZvSEJCOExaUXBzREgxcWU0SzFyVUZZQk55dm9M?=
 =?utf-8?B?ZElSdEFyVXEwUFR1Q2xRcjlaeE1WNUNzODdPMENqeG0rQURKalhhbVdkRU93?=
 =?utf-8?B?WFRkK3QyelI2ZGVTdDNCL2xGa1Fic3gxbjVJeERHTkR2aUVFL2hwU0ZiV2lX?=
 =?utf-8?B?Tm1NcnNkRzNSckNQWHBDVWNxZHp5Z2VIQ2VGVmhNMEhuY1BFcmwwUytrZy93?=
 =?utf-8?B?WkE9PQ==?=
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: ee0b2e43-306a-4b74-981d-08ddfaa6637f
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2025 13:37:49.6993
 (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: NH15SRZi5NsE2iDUZkikF/xN7s6DwoL7nsywMgiOap13D/TDEqoVlCca1BfEUsgp1POId/8Bt6OyTkr6ntlrsw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7150

T24gMTguMDkuMjUgMTY6MzUsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgTXlreXRhLA0KPiAN
Cj4gT24gMTgvMDkvMjAyNSAxMzoxNiwgTXlreXRhIFBvdHVyYWkgd3JvdGU6DQo+PiBJbXBsZW1l
bnQgWEVOX1NZU0NUTF9DUFVfSE9UUExVR18qIGNhbGxzIHRvIGFsbG93IGZvciBlbmFibGluZy9k
aXNhYmxpbmcNCj4+IENQVSBjb3JlcyBpbiBydW50aW1lLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6
IE15a3l0YSBQb3R1cmFpIDxteWt5dGFfcG90dXJhaUBlcGFtLmNvbT4NCj4+IC0tLQ0KPj4gICB4
ZW4vYXJjaC9hcm0vc3lzY3RsLmMgfCA2NyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrDQo+PiAgIDEgZmlsZSBjaGFuZ2VkLCA2NyBpbnNlcnRpb25zKCspDQo+Pg0K
Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9zeXNjdGwuYyBiL3hlbi9hcmNoL2FybS9zeXNj
dGwuYw0KPj4gaW5kZXggMzJjYWI0ZmVmZi4uY2E4ZmI1NTBmZCAxMDA2NDQNCj4+IC0tLSBhL3hl
bi9hcmNoL2FybS9zeXNjdGwuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3N5c2N0bC5jDQo+PiBA
QCAtMTIsNiArMTIsNyBAQA0KPj4gICAjaW5jbHVkZSA8eGVuL2R0LW92ZXJsYXkuaD4NCj4+ICAg
I2luY2x1ZGUgPHhlbi9lcnJuby5oPg0KPj4gICAjaW5jbHVkZSA8eGVuL2h5cGVyY2FsbC5oPg0K
Pj4gKyNpbmNsdWRlIDx4ZW4vY3B1Lmg+DQo+PiAgICNpbmNsdWRlIDxhc20vYXJtNjQvc3ZlLmg+
DQo+PiAgICNpbmNsdWRlIDxwdWJsaWMvc3lzY3RsLmg+DQo+PiBAQCAtMjMsNiArMjQsNjggQEAg
dm9pZCBhcmNoX2RvX3BoeXNpbmZvKHN0cnVjdCB4ZW5fc3lzY3RsX3BoeXNpbmZvICpwaSkNCj4+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+PiBYRU5fU1lTQ1RM
X1BIWVNDQVBfQVJNX1NWRV9NQVNLKTsNCj4+ICAgfQ0KPj4gK3N0YXRpYyBsb25nIGNwdV91cF9o
ZWxwZXIodm9pZCAqZGF0YSkNCj4+ICt7DQo+PiArICAgIHVuc2lnbmVkIGxvbmcgY3B1ID0gKHVu
c2lnbmVkIGxvbmcpIGRhdGE7DQo+PiArICAgIHJldHVybiBjcHVfdXAoY3B1KTsNCj4+ICt9DQo+
PiArDQo+PiArc3RhdGljIGxvbmcgY3B1X2Rvd25faGVscGVyKHZvaWQgKmRhdGEpDQo+PiArew0K
Pj4gKyAgICB1bnNpZ25lZCBsb25nIGNwdSA9ICh1bnNpZ25lZCBsb25nKSBkYXRhOw0KPj4gKyAg
ICByZXR1cm4gY3B1X2Rvd24oY3B1KTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGxvbmcgc210
X3VwX2Rvd25faGVscGVyKHZvaWQgKmRhdGEpDQo+IA0KPiBMb29raW5nIGF0IHRoZSBjb2RlLCB5
b3Ugd2lsbCBlZmZlY3RpdmVseSBkaXNhYmxlIGFsbCB0aGUgQ1BVcyBidXQgQ1BVMC4gDQo+IEJ1
dCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5LiBGcm9tIHRoZSBuYW1lIGlzIGdvYWwgc2VlbXMgdG8g
YmUgZGlzYWJsZSANCj4gU01UIHRocmVhZGluZy4NCj4NCg0KU29ycnkgSSBoYXZlIHNsaWdodGx5
IG1pc3VuZGVyc3Rvb2QgdGhlIHg4NiBpbXBsZW1lbnRhdGlvbi9yZWFzb25pbmcgb2YgDQp0aGlz
IG9wcy4gSSB3aWxsIGRyb3AgdGhlbSBpbiBWMi4NCg0KPj4gK3sNCj4+ICsgICAgYm9vbCB1cCA9
IChib29sKSBkYXRhOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQgY3B1Ow0KPj4gKyAgICBpbnQgcmV0
Ow0KPj4gKw0KPj4gKyAgICBmb3JfZWFjaF9wcmVzZW50X2NwdSAoIGNwdSApDQo+PiArICAgIHsN
Cj4+ICsgICAgICAgIGlmICggY3B1ID09IDAgKQ0KPj4gKyAgICAgICAgICAgIGNvbnRpbnVlOw0K
Pj4gKw0KPj4gKyAgICAgICAgaWYgKCB1cCApDQo+PiArICAgICAgICAgICAgcmV0ID0gY3B1X3Vw
KGNwdSk7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAgcmV0ID0gY3B1X2Rvd24o
Y3B1KTsNCj4+ICsNCj4gDQo+IFJlZ2FyZGxlc3Mgd2hhdCBJIHdyb3RlIGFib3ZlLCB5b3UgbGlr
ZWx5IHdhbnQgdG8gaGFuZGxlIHByZWVtcHRpb24uDQo+IA0KPj4gKyAgICAgICAgaWYgKCByZXQg
KQ0KPj4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+ICA+ICsgICAgfQ0KPj4gKw0KPj4gKyAg
ICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGxvbmcgY3B1X2hvdHBsdWdfc3lz
Y3RsKHN0cnVjdCB4ZW5fc3lzY3RsX2NwdV9ob3RwbHVnICpob3RwbHVnKQ0KPj4gK3sNCj4+ICsg
ICAgYm9vbCB1cDsNCj4+ICsNCj4+ICsgICAgc3dpdGNoIChob3RwbHVnLT5vcCkgew0KPj4gKyAg
ICAgICAgY2FzZSBYRU5fU1lTQ1RMX0NQVV9IT1RQTFVHX09OTElORToNCj4+ICsgICAgICAgICAg
ICBpZiAoIGhvdHBsdWctPmNwdSA9PSAwICkNCj4gDQo+IEkgY2FuJ3QgZmluZCBhIHNpbWlsYXIg
Y2hlY2sgb24geDg2LiBEbyB5b3UgaGF2ZSBhbnkgcG9pbnRlcj8NCg0KSmFuIGNvcnJlY3RseSBt
ZW50aW9uZWQgdGhhdCBDUFUwIGNhbid0IGJlIGRpc2FibGVkIHNvIHRoaXMgaXMgYSBzaG9ydCAN
CmNpcmN1aXQgZm9yIGNsYXJpdHkuDQoNCj4gDQo+PiArICAgICAgICAgICAgICAgIHJldHVybiAt
RUlOVkFMOw0KPiANCj4gT24geDg2LCB0aGV5IHNlZW0gdG8gY2hlY2sgZm9yIFhTTSBwZXJtaXNz
aW9uIGJlZm9yZSBjb250aW51aW5nLiBDYW4geW91IA0KPiBleHBsYWluIHdoeSB0aGlzIGlzIG5v
dCBuZWNlc3Nhcnk/IFNhbWUgcXVlc3Rpb25zIGFwcGxpZXMgYmVsb3cuDQoNCkkgd2lsbCBhZGQg
WFNNIGNoZWNrcyB0aGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0Lg0KDQo+IA0KPj4gKyAgICAg
ICAgICAgIHJldHVybiBjb250aW51ZV9oeXBlcmNhbGxfb25fY3B1KDAsIGNwdV91cF9oZWxwZXIs
IA0KPj4gX3AoaG90cGx1Zy0+Y3B1KSk7DQo+PiArDQo+PiArICAgICAgICBjYXNlIFhFTl9TWVND
VExfQ1BVX0hPVFBMVUdfT0ZGTElORToNCj4+ICsgICAgICAgICAgICBpZiAoIGhvdHBsdWctPmNw
dSA9PSAwICkNCj4+ICsgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAg
ICAgICAgcmV0dXJuIGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9jcHUoMCwgY3B1X2Rvd25faGVscGVy
LCANCj4+IF9wKGhvdHBsdWctPmNwdSkpOw0KPj4gKw0KPj4gKyAgICAgICAgY2FzZSBYRU5fU1lT
Q1RMX0NQVV9IT1RQTFVHX1NNVF9FTkFCTEU6DQo+PiArICAgICAgICBjYXNlIFhFTl9TWVNDVExf
Q1BVX0hPVFBMVUdfU01UX0RJU0FCTEU6DQo+IA0KPiBXaHkgYXJlIHdlIGltcGxlbWVudGluZyB0
aG9zZSBoZWxwZXJzIG9uIEFybT8NCj4gDQo+PiArICAgICAgICAgICAgaWYgKCBDT05GSUdfTlJf
Q1BVUyA8PSAxICkNCj4+ICsgICAgICAgICAgICAgICAgcmV0dXJuIDA7DQo+PiArICAgICAgICAg
ICAgdXAgPSBob3RwbHVnLT5vcCA9PSBYRU5fU1lTQ1RMX0NQVV9IT1RQTFVHX1NNVF9FTkFCTEU7
DQo+PiArICAgICAgICAgICAgcmV0dXJuIGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9jcHUoMCwgc210
X3VwX2Rvd25faGVscGVyLCANCj4+IF9wKHVwKSk7DQo+PiArDQo+PiArICAgICAgICBkZWZhdWx0
Og0KPj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArfQ0KPj4g
Kw0KPj4gICBsb25nIGFyY2hfZG9fc3lzY3RsKHN0cnVjdCB4ZW5fc3lzY3RsICpzeXNjdGwsDQo+
PiAgICAgICAgICAgICAgICAgICAgICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fc3lzY3Rs
X3QpIHVfc3lzY3RsKQ0KPj4gICB7DQo+PiBAQCAtMzQsNiArOTcsMTAgQEAgbG9uZyBhcmNoX2Rv
X3N5c2N0bChzdHJ1Y3QgeGVuX3N5c2N0bCAqc3lzY3RsLA0KPj4gICAgICAgICAgIHJldCA9IGR0
X292ZXJsYXlfc3lzY3RsKCZzeXNjdGwtPnUuZHRfb3ZlcmxheSk7DQo+PiAgICAgICAgICAgYnJl
YWs7DQo+PiArICAgIGNhc2UgWEVOX1NZU0NUTF9jcHVfaG90cGx1ZzoNCj4gDQo+IFRoaXMgd2ls
bCBhbHNvIGVuYWJsZSBDUFUgaG90cGx1ZyBvbiAzMi1iaXQgQXJtLiBJcyB0aGlzIHdoYXQgeW91
IA0KPiBpbnRlbmRlZD8gKEkgc2VlIHBhdGNoICM0IG9ubHkgbWVudGlvbiA2NC1iaXQgQXJtKS4N
Cg0KSXQgd2Fzbid0IGludGVuZGVkLiBJIHdpbGwgYWRkaXRpb25hbGx5IGNoZWNrIGlmIGl0IHdv
cmtzIG9uIGFybTMyIGVuZCANCmV4cGxpY2l0bHkgc3BlY2lmeSBpdC4NCg0KPiANCj4+ICsgICAg
ICAgIHJldCA9IGNwdV9ob3RwbHVnX3N5c2N0bCgmc3lzY3RsLT51LmNwdV9ob3RwbHVnKTsNCj4+
ICsgICAgICAgIGJyZWFrOw0KPj4gKw0KPj4gICAgICAgZGVmYXVsdDoNCj4+ICAgICAgICAgICBy
ZXQgPSAtRU5PU1lTOw0KPj4gICAgICAgICAgIGJyZWFrOw0KPiANCj4gQ2hlZXJzLA0KPiANCg0K
LS0gDQpNeWt5dGE=


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 14:18:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 14:18:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128404.1468764 (Exim 4.92)
	(envelope-from )
	id 1v13qs-0000vt-TO; Tue, 23 Sep 2025 14:18:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128404.1468764; Tue, 23 Sep 2025 14:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v13qs-0000vm-OG; Tue, 23 Sep 2025 14:18:42 +0000
Received: by outflank-mailman (input) for mailman id 1128404;
 Tue, 23 Sep 2025 14:18:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v13qr-0000vg-CW
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 14:18:41 +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 339da682-9888-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 16:18:40 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3ecde0be34eso3401335f8f.1
 for ; Tue, 23 Sep 2025 07:18:39 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-33060619253sm16514548a91.4.2025.09.23.07.18.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 07:18: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: 339da682-9888-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758637119; x=1759241919; 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=7hnL+TBSgCYqTL4vGYnVPUwW+/cEh1JjfV8yMCpwGGk=;
        b=UM2tXDwSRrse9vfln+2OnKtA2ayRCYgCfF/uViYbKFzgvV4FeUPpZlS3l3C+GEs/h2
         h4+Wl6hMWnoaQBdIAKpUZfhLjW/T25zVzWnMob0XsLQIUK6OUKd6l4w5zme/fW7KPnpK
         I7QUzv13+F5o7qUREJgFqOx+wHgNiflfPDpjIdAwtjj2AUkguCX9L70gUszdNSWPmqFO
         obsDCQIcSF8+6IycHzUpc9MY+WwsB3vhm1uaFxYM2OZ1v0POMuUCwQCMxOPnNrb55N9P
         jArGHQxomyBNDAp0LYRUVunr8sXsgAHrE+RyjonUkgG4zxxSrVIohsp+biMx50NWT4Qw
         9sZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758637119; x=1759241919;
        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=7hnL+TBSgCYqTL4vGYnVPUwW+/cEh1JjfV8yMCpwGGk=;
        b=P2VyPtE+Jppb7ukL5KkM4jy1SP6JTUWNWolcT9yW86De2wHIFkDgM0HKqxDvSdqgmN
         b40yPXM2YtTY4ZgwPBvcoDFUrnz6SEogwpU4o4kFDJOffD/yAenbM40eDLJzwc0mqqIb
         mOWE1CkmPxx3sko8FGQeQCB2XYWV6kXt9/eHm/DHgpJKn+VmDySQVuutY4APVp4wrW0+
         MBTr5qArMdbgRIe+Qt/sfzLr9mKoiQ/OFhRzH3yZG8mxFwZbmlfH7ot6kJmYqnrSJ/R1
         x/InufXK1to6ExVQge6V3ZPkwxoWm6ax56M8yjTXIWNWtmpTITJ0ZIR16ISD51tYe64n
         X+sA==
X-Forwarded-Encrypted: i=1; AJvYcCWffDyxfi+knVXwi5WTNAzY3UrVmne2NdUSZOnI8EbLzK5mccpuhu43E5+AvaYaDUmTr0u15RCfwls=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyS0Ozc34UIwYkOLbDWdS1OP9Q4ORm1TGq3AD1ZsvOeRC2Vy71Z
	2oFHGotdEgsucjf8sTuBEZgsU+p/xOt6yp0YHmjAYHj7+DMi5GVBx+sam44KVHtuTQ==
X-Gm-Gg: ASbGncuZ/eNUGD+copXbhIYAikDxuxEfgzc2A93kxuwLfy1nLeMy7bSVUMH85GU67LE
	n2meIQ9aDq386XowbRJzZeWrlgtZYT1MFWStCpQiPTAuqFWRGunkpUvlXKDjS3PC3v9QcIzOMJN
	0osKwLLpnzhP+inIzobLdkZlcVuuaCar+yVfh95rASfoZuzoWmoXSEKtH71QgcDBUBcMX6RZkKY
	9zQ9ss9QxgGLNN5kxDpUQRW2KopBZWLFRmgJdJM7aOPcK2koinJ+lLd+k+8Npf6E/UGnP27Pnxr
	1We2oCUmtFkCX1+jZjaWKJ4iwlJ3wxDzCc2MyXqEBxgC4ebYr0CFYiuVxKSFoKGwqa4RbVxgokI
	JBR5pFGh+jPtwZetEVG2vX63wj99EYM/M
X-Google-Smtp-Source: AGHT+IENCRlBu4swxzv3D0VfPtVRhv6OQ8pilkQjOpw5Vc1Qr/O/f5yNEom/MPZYMaai4HLuVV8jGw==
X-Received: by 2002:a05:6000:178e:b0:401:2cbf:ccad with SMTP id ffacd0b85a97d-405cf9c1c48mr2182174f8f.17.1758637119142;
        Tue, 23 Sep 2025 07:18:39 -0700 (PDT)
Message-ID: <0c268124-b0a4-451e-8713-827b8074c767@suse.com>
Date: Tue, 23 Sep 2025 16:18:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 "xen-devel@lists.xenproject.org" ,
 Oleksii Kurochko ,
 Tamas K Lengyel 
References: <20250912045254.3731398-1-Penny.Zheng@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.09.2025 10:19, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Friday, September 12, 2025 3:30 PM
>> To: Penny, Zheng ; Tamas K Lengyel
>> 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Alexandru Isaila ; Petre Pircalabu
>> ; xen-devel@lists.xenproject.org; Oleksii Kurochko
>> 
>> Subject: Re: [PATCH] xen/vm_event: introduce vm_event_is_enabled()
>>
>> On 12.09.2025 06:52, Penny Zheng wrote:
>>> @@ -2462,9 +2461,8 @@ int hvm_set_cr3(unsigned long value, bool noflush,
>> bool may_defer)
>>>      if ( may_defer && unlikely(currd->arch.monitor.write_ctrlreg_enabled &
>>>                                 monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
>>>      {
>>> -        ASSERT(curr->arch.vm_event);
>>> -
>>> -        if ( hvm_monitor_crX(CR3, value, curr->arch.hvm.guest_cr[3]) )
>>> +        if ( vm_event_is_enabled(curr) &&
>>> +             hvm_monitor_crX(CR3, value, curr->arch.hvm.guest_cr[3])
>>> + )
>>>          {
>>>              /* The actual write will occur in hvm_do_resume(), if permitted. */
>>>              curr->arch.vm_event->write_data.do_write.cr3 = 1; @@
>>> -2544,9 +2542,7 @@ int hvm_set_cr4(unsigned long value, bool may_defer)
>>>      if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
>>>                                 monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4)) )
>>>      {
>>> -        ASSERT(v->arch.vm_event);
>>> -
>>> -        if ( hvm_monitor_crX(CR4, value, old_cr) )
>>> +        if ( vm_event_is_enabled(v) && hvm_monitor_crX(CR4, value,
>>> + old_cr) )
>>>          {
>>>              /* The actual write will occur in hvm_do_resume(), if permitted. */
>>>              v->arch.vm_event->write_data.do_write.cr4 = 1; @@ -3407,7
>>> +3403,7 @@ static enum hvm_translation_result __hvm_copy(
>>>              return HVMTRANS_bad_gfn_to_mfn;
>>>          }
>>>
>>> -        if ( unlikely(v->arch.vm_event) &&
>>> +        if ( unlikely(vm_event_is_enabled(v)) &&
>>>               (flags & HVMCOPY_linear) &&
>>>               v->arch.vm_event->send_event &&
>>>               hvm_monitor_check_p2m(addr, gfn, pfec,
>>> npfec_kind_with_gla) ) @@ -3538,6 +3534,7 @@ int hvm_vmexit_cpuid(struct
>> cpu_user_regs *regs, unsigned int inst_len)
>>>      struct vcpu *curr = current;
>>>      unsigned int leaf = regs->eax, subleaf = regs->ecx;
>>>      struct cpuid_leaf res;
>>> +    int ret = 0;
>>>
>>>      if ( curr->arch.msrs->misc_features_enables.cpuid_faulting &&
>>>           hvm_get_cpl(curr) > 0 )
>>> @@ -3554,7 +3551,10 @@ int hvm_vmexit_cpuid(struct cpu_user_regs *regs,
>> unsigned int inst_len)
>>>      regs->rcx = res.c;
>>>      regs->rdx = res.d;
>>>
>>> -    return hvm_monitor_cpuid(inst_len, leaf, subleaf);
>>> +    if ( vm_event_is_enabled(curr) )
>>> +        ret = hvm_monitor_cpuid(inst_len, leaf, subleaf);
>>> +
>>> +    return ret;
>>>  }
>>>
>>>  void hvm_rdtsc_intercept(struct cpu_user_regs *regs) @@ -3694,9
>>> +3694,8 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t
>> msr_content,
>>>          if ( ret != X86EMUL_OKAY )
>>>              return ret;
>>>
>>> -        ASSERT(v->arch.vm_event);
>>> -
>>> -        if ( hvm_monitor_msr(msr, msr_content, msr_old_content) )
>>> +        if ( vm_event_is_enabled(v) &&
>>> +             hvm_monitor_msr(msr, msr_content, msr_old_content) )
>>>          {
>>>              /* The actual write will occur in hvm_do_resume(), if permitted. */
>>>              v->arch.vm_event->write_data.do_write.msr = 1; @@
>>> -3854,12 +3853,10 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
>>>      struct vcpu *curr = current;
>>>      struct domain *currd = curr->domain;
>>>
>>> -    if ( currd->arch.monitor.descriptor_access_enabled )
>>> -    {
>>> -        ASSERT(curr->arch.vm_event);
>>> +    if ( currd->arch.monitor.descriptor_access_enabled &&
>>> +         vm_event_is_enabled(curr) )
>>>          hvm_monitor_descriptor_access(exit_info, vmx_exit_qualification,
>>>                                        descriptor, is_write);
>>> -    }
>>>      else if ( !hvm_emulate_one_insn(is_sysdesc_access, "sysdesc access") )
>>>          domain_crash(currd);
>>
>> Following "xen: consolidate CONFIG_VM_EVENT" this function is actually
>> unreachable when VM_EVENT=n, so no change should be needed here. It's instead
>> the unreachability which needs properly taking care of (to satisfy Misra
>> requirements) there.
>>
> 
> I'm a bit confused and may not understand you correctly here.
> Just because that hvm_monitor_descriptor_access() will become unreachable codes when VM_EVENT=n, and to avoid writing stubs, we added the vm_event_xxx check here. Or maybe you want me to add description to say the new checking also helps compiling out unreachable codes?

If the function becomes unreachable, it's not its contents which need
altering. Instead, the unreachable function should be "removed" (by
#ifdef-ary) altogether in the respective configuration. Recall that
unreachability is a Misra violation (or a rule that iirc we accepted).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 14:23:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 14:23:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128417.1468772 (Exim 4.92)
	(envelope-from )
	id 1v13vU-0002SJ-Ai; Tue, 23 Sep 2025 14:23:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128417.1468772; Tue, 23 Sep 2025 14:23: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 1v13vU-0002SC-85; Tue, 23 Sep 2025 14:23:28 +0000
Received: by outflank-mailman (input) for mailman id 1128417;
 Tue, 23 Sep 2025 14:23: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 1v13vS-0002S6-HV
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 14:23:26 +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 db67bd9a-9888-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 16:23:21 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3fc36b99e92so1522129f8f.0
 for ; Tue, 23 Sep 2025 07:23:21 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77f335995cbsm6907107b3a.63.2025.09.23.07.23.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 07:23: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: db67bd9a-9888-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758637401; x=1759242201; 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=MzK+IETyG2Lq3t2yFPuegv66ul4IJON4z1UQ6o9xoH4=;
        b=P3OvVmh9Uf5isJInHnKVdNVk+c3caN3I5l2e/8dya+JaBjn8Hv0ophQmJgJQi0hSIi
         hqpXeyUj/H4MF9SxY9JzviqyRz8Tf6XrEHIk0hVftch8hP6nW/DlHyXOneA5eqb9pn66
         yJT14/KdjQoKfNZK9trmzAbb9E4CbDPNpc5XD63H/RFeT2tmN8RAID1/0MVUVz7hFME6
         YPwizd19xhbpciYaF2O55ix+yxg4dJSBK3cLZRwAUFxEIUuNbqBN1dXEx2va2HI3wwWB
         6afI36sGieK0cP65TJCdEiwsYDJiyBbm11dBQJ1IEmCMQZvOwcPlj8dAO/CABNgM4XuX
         ybIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758637401; x=1759242201;
        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=MzK+IETyG2Lq3t2yFPuegv66ul4IJON4z1UQ6o9xoH4=;
        b=uUf/iS5UM74xCQIB2pXDejJaizUeeMSXIKikP83Qb8y0nz4EArushIU3+U7oYCrWmZ
         QS+jN1oPDqdwfSrnDEF6+bD9MhiLnzPhxm04ly607NZCwRSeGIUV9hCcrYqz3578EfCR
         O5rIdvt7eUZy0YoC2AQBkmsa548sqCTxTkRDCBuPB5Fx8rCPdOawpsnhBmwpw9ZjFQ7n
         tQGu5uV4rjxg92uMTDSsBHLMh76M8r0akcKA8FVxb6zTdqa/UKF2pbWrXrDQmpZkO9ij
         qAkqW5MZWNLZHI5ktsYjN1/4qv4338wa1TRU5awKAQPPb772kfM6p1oj/r8p+7sYyFUZ
         GAVQ==
X-Forwarded-Encrypted: i=1; AJvYcCW1fzkN0howBY5szlfZvq9psWOA5aqqi0PQalJFgAmjXLdPueNJZ79r0uHW7eC3gCU5UjB5qO9INSw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztQe0QRZwcb0lTCPJaDHQGnOIYvHwTzFlide5jA8G5zUZD099x
	QFjh8QXnZGplrUfUyRf+ns/sNB9SNxN2BQRu/QdVTF+lNj8jZnwqi0gE+4iOTKxTZA==
X-Gm-Gg: ASbGncvqONx814N/RXEBdrTOrdC5T6pCzHyVYOv/l+Noy0POmewhC63eNLkVCqIyLEx
	ZMQwok+BY/Mk3QsMTQt0fC0QwAEXlMLbaU30WzS/W1bn7RVnE4OW5XcW8mvaBRnDjg83+Vr6JUA
	tl/SBdUGnncyfFqn/+Bxl6jP2rXlCu3iWJR2/K4jwqmSknwW8khFnC5RBt4F8k04gNWW5q4i/eG
	Vtx1k7GOglBH54GO2ELpm/O08OWf2Am4uLcTmIJaHI39YvoLe+sfPyzNUb4PN4yVjIgDyR+e7QI
	kIdHmDAm6AbKC6huSXH1+2mEztCVwhOzSJe3D3ihM8YF8i1lgcCtLEKFp/Vj/mIihMcxQUst46F
	HNjOxHLR2xAuMHp4TSuWgtcajt9pDRdVK
X-Google-Smtp-Source: AGHT+IF2XG8J+l8e+Cg5twOHP7DA0dBQneimjUG4sowjs9kmFm8s5g9jExvxm9s5hcxat6NniJuQDQ==
X-Received: by 2002:a05:6000:2484:b0:3fd:7388:28a with SMTP id ffacd0b85a97d-405cb3e57efmr1983917f8f.8.1758637400816;
        Tue, 23 Sep 2025 07:23:20 -0700 (PDT)
Message-ID: <7e04b98f-18fb-4213-9276-a5ca97e75f0e@suse.com>
Date: Tue, 23 Sep 2025 16:23:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 05/22] x86/boot/slaunch-early: early TXT checks and
 boot data retrieval
To: Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
References: 
 
 <0024c24f-39a4-4b5e-af7b-536f7cebfaff@suse.com> 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 10:39, Sergii Dmytruk wrote:
> On Tue, Jul 08, 2025 at 06:00:13PM +0200, Jan Beulich wrote:
>> These inline functions are pretty large. Why do they need to be inline ones?
> 
> The functions are run at entry points, one of which is in 32-bit early
> code and another in 64-bit EFI.  Having this in the header is simpler
> than compiling the code twice.  Despite having many lines, it's just a
> sequence of checks, so it didn't seem like too much for a header.

Otoh especially the being compiled as 32-bit and as 64-bit can end up being
a pitfall - one wouldn't necessarily expect this when editing a header file.
A dual-built C file would be different in this regard, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 14:25:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 14:25:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128427.1468782 (Exim 4.92)
	(envelope-from )
	id 1v13xI-0002ze-Lc; Tue, 23 Sep 2025 14:25:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128427.1468782; Tue, 23 Sep 2025 14: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 1v13xI-0002zX-IH; Tue, 23 Sep 2025 14:25:20 +0000
Received: by outflank-mailman (input) for mailman id 1128427;
 Tue, 23 Sep 2025 14:25: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 1v13xH-0002zR-Rf
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 14:25:19 +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 20d44ec0-9889-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 16:25:17 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3f44000626bso2167182f8f.3
 for ; Tue, 23 Sep 2025 07:25:17 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3306085c115sm16197926a91.27.2025.09.23.07.25.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 07: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: 20d44ec0-9889-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758637517; x=1759242317; 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=3wqXA97QWrt85ZwfIGodKN2bsMkqO7Vow3883nPXPGA=;
        b=R+KEXnJZxRW+TvPWNNXI+5QHYQTPvNwZgOY83gpMURiwnJiQKP3CGK0N/0fuhbIVN6
         VkwDkrz9WoorfGgVlkjbNkH8uvTN3WWe6jfDc/rDO8b4CZOCc4ctr+Hu0W2flEGSeITL
         76gJe0m4NiGtNSq9qZgIeLYWp1wkmYyFqm+nVK5mCdazgGp+o0K/Me4oDV0jUWvQwirj
         RANCxziWnbRLmr5mKrcTxMrbG1xgd+Y8UQp2CQPiGBUAfa9kZpT24Yxp3oJjfQRsyv+2
         6kK4ESkgkj4msCdCBXs5nFlP/3cE41+RIN8tsHcK36E8PDoEG29Vhh8M091e6p+hHN5M
         uGBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758637517; x=1759242317;
        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=3wqXA97QWrt85ZwfIGodKN2bsMkqO7Vow3883nPXPGA=;
        b=fYHo2vcA0o9JVyWGZUp5wPMSqrzf2FFb023xglCWIQFi0NuA1r5Uz3s5VUZoOXGJd1
         l7E+9wolbtSRCOgFb6pgJOz/pdA67vhH18ustVkfOu8G5I9/S+RDp/OanZ/va4485jSi
         JK1VZ6wyNbE7MfZ/Kv1f38RmI6hOK5Xxud/89qvdNUnQQDgro7qWE7TJ5jAuhoIMOmeU
         2dXjp/DWLfp8k1AEL/15C+vG7IrO26VvWZjTnNtBzOuyleZvcF4utevMx1s+ZEjxCtCY
         6WTjWogAfvf2D2yxzfhGB6jWQYKoBA0WVLR3NRWHQZoUx6e7qQa2h/k+jZCnvRS2/350
         4h2g==
X-Forwarded-Encrypted: i=1; AJvYcCXlebh5X2HTPv/ibkqKyrBfdnOO8t+dEysomTANoC2rNPPiqnBT3oj77kMaU4OpKwkWhfrfiFOG/Gw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQwJRCOjSLp6+XdZU9vzRPFDquTjdzC8AN8CTZKTqZBg1kS1j9
	x1tvt0hOs9E78PHmSDGHtSjX8gpGaWD8SHj1Aqe0vfHV5hzx0fu1qpsbmV3w7BRWkA==
X-Gm-Gg: ASbGncv6BYqEKBfu5+Laf5ISf45SbB8+ujUussvzcICa0WUTZGuFiYZZw0oceCjwyPU
	91DeNwPXcJL1X2Uv/le9MW6aRpJy/vrZknVNct2Sq7q10TGeA7jiZJoHfW/GJ6TEFqQ+SWqIKXk
	RXUoNGN48Hevng89Oy0meleGfvjvjj1UPLN3eE1pLMyOBHBmgVlXYda4WDdsxslX7uLZhr67VWy
	HcGMv3j4gnWQOhdzAGGNjZHKoiaMRycrM7mQhjsALPX3eLio3+LrvwpXeoymGuecWMA0JKPOpZ+
	m4lxE6yiJZzWWq/NUWRJMahlYA7+cCehhfos1CcJ9+T58qm/5jWDsjdUNRsoaZC4XnawlrqLpl7
	pmylvVUBZJWiq5jaC3WRXcoemTczMF5ZW
X-Google-Smtp-Source: AGHT+IEA/HDBnhTjV90lTzA4OcI7ytEovfHngSizJTXJDCLz5cUHZ058RD2a9cFGZwKnC72QLm9ygA==
X-Received: by 2002:a5d:5f49:0:b0:400:ac58:b35f with SMTP id ffacd0b85a97d-405c523c254mr2261409f8f.21.1758637517209;
        Tue, 23 Sep 2025 07:25:17 -0700 (PDT)
Message-ID: <0e2b9162-1a4e-4a95-afcb-0d9e1e54e3a0@suse.com>
Date: Tue, 23 Sep 2025 16:25:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
To: Mykyta Poturai 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 ,
 "xen-devel@lists.xenproject.org" 
References: 
 <7d10f4d063a55920acbb8d477b885552379a6116.1758197507.git.mykyta_poturai@epam.com>
 <337596e3-e522-4770-a64b-6c8137134739@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 15:19, Mykyta Poturai wrote:
> On 18.09.25 17:59, Jan Beulich wrote:
>> On 18.09.2025 14:16, Mykyta Poturai wrote:
>>> --- a/config/arm64.mk
>>> +++ b/config/arm64.mk
>>> @@ -1,5 +1,6 @@
>>>   CONFIG_ARM := y
>>>   CONFIG_ARM_64 := y
>>> +CONFIG_HOTPLUG := y
>>>   
>>>   CONFIG_XEN_INSTALL_SUFFIX :=
>>>   
>>> --- a/config/x86_32.mk
>>> +++ b/config/x86_32.mk
>>> @@ -3,6 +3,7 @@ CONFIG_X86_32 := y
>>>   
>>>   CONFIG_MIGRATE := y
>>>   CONFIG_XCUTILS := y
>>> +CONFIG_HOTPLUG := y
>>>   
>>>   CFLAGS += -m32 -march=i686
>>>   
>>> --- a/config/x86_64.mk
>>> +++ b/config/x86_64.mk
>>> @@ -3,6 +3,7 @@ CONFIG_X86_64 := y
>>>   
>>>   CONFIG_MIGRATE := y
>>>   CONFIG_XCUTILS := y
>>> +CONFIG_HOTPLUG := y
>>>   
>>>   CONFIG_XEN_INSTALL_SUFFIX := .gz
>>
>> I realize you only do what is already being done, but I question this
>> way of doing things when the scope is tools-only. Any CONFIG_* put here
>> cannot have an identically named, but potentially set differently
>> Kconfig setting in xen/: Any use of such in a Makefile could end up being
>> wrong, and would pretty surely end up being confusing.
> 
> I have checked the whole codebase and didn't find any other 
> CONFIG_HOTPLUG, the only similar thing is CONFIG_HOTPLUG_CPU. Anyway, I 
> can change it to something more specific like CONFIG_HPTOOL for example.

Iff no other way (configure?) can be found, then yes, please use this more
specific name. But not extending this legacy way of "configuring" things
would be much preferred.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 14:36:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 14:36:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128442.1468793 (Exim 4.92)
	(envelope-from )
	id 1v1481-0004rR-Jy; Tue, 23 Sep 2025 14:36:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128442.1468793; Tue, 23 Sep 2025 14:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1481-0004rK-Gy; Tue, 23 Sep 2025 14:36:25 +0000
Received: by outflank-mailman (input) for mailman id 1128442;
 Tue, 23 Sep 2025 14:36: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 1v1480-0004qp-Ma
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 14:36:24 +0000
Received: from mail133-23.atl131.mandrillapp.com
 (mail133-23.atl131.mandrillapp.com [198.2.133.23])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ace9e44f-988a-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 16:36:23 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-23.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4cWMx156Ljz35hVQg
 for ; Tue, 23 Sep 2025 14:36:21 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 acfe7957fc674b7d9a61cb1cffdd2e0d; Tue, 23 Sep 2025 14:36: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: ace9e44f-988a-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1758638181; x=1758908181;
	bh=P8Oo8nkljt7Riu6h2XQ7dGEmIIPy5qgKPXON1CCjxu8=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=KH0qq21wYlv9MJxG7UOF14O2z9zy/k9r5K2xbVPY7OOErADjJvS2AK1LvHiHfIeSB
	 80BjF1trS+KLXxtu2SBD/iK5rqlAPACyQ5oNSIQgqq6ioriqVSkL+eBrQ03930iyWT
	 xn0UUJ/XarDP14Fnagmu9SMHSrVAN+axEy1t8go+tlc+oQx4hIX+4A3SpjlhktRh3i
	 woyu3g1Rh2N7vVtcn6Iljjgalf750jmwZJk5UZ33kbS6lWxBEq4Zlf5pmhJSOnH2jy
	 foWKjiavbNzCo6cP7WzfcN1QV05FKXnTM3/1RURWv48pkVR39tV++XmoqG6L+zd6cG
	 8Wnyrsv66qGPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1758638181; x=1758898681; i=yann.sionneau@vates.tech;
	bh=P8Oo8nkljt7Riu6h2XQ7dGEmIIPy5qgKPXON1CCjxu8=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=i965NleXoj797NhDg/X+66HXon8aS/JPpPBMtLn+P9QN7xH8SQJhANKmlzJ39CgiW
	 wA6eHi/t90p3X7XcECCtZhSUZEtq3nI4csA9tNJ2ZHUNh5BKwFFEPOo//pX0aOw8uD
	 vHSuGE2/5Ptmtn9EciXnaOW5sV9WxTDih4Q6lUQjpYeLhkAv3X13fvS2JSF9KlkBjC
	 uVINRL5mCQBbcJ/C1pC86Ib3IsjVXKMhfpznSxiNs5KFDkhBn0EV2PpuWnQFTGKtlN
	 eVjb8MwpUxPW132jpww2Qc8nOecR9sFLd4AwRzjWS7uOI59p4LCTw8fVi/cmMHcBOJ
	 ilu7dRXlHEN8w==
From: "Yann Sionneau" 
Subject: =?utf-8?Q?Xen=20Summit=202025=20-=20"x86=20Nested=20Virtualization=20-=20Project=20Plan"=20design=20session=20notes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1758638181050
Message-Id: 
To: "Xen developer discussion" 
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.acfe7957fc674b7d9a61cb1cffdd2e0d?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250923:md
Date: Tue, 23 Sep 2025 14:36:21 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Here are my notes from this design session: 
https://design-sessions.xenproject.org/uid/discussion/disc_ADNniRk2YcQ1wMOZ=
eMXc/view

I apologize for it being partial and maybe containing errors, it was not 
an easy task for a non-native speaker as well as someone who does not 
know the topic of nested virt.

####################
Wednesday 17/09

Nested Virt It=E2=80=99s going to be a requirement for windows in a couple =
of years.
Let=E2=80=99s present the bigger picture plan, how to break it down and how=
 
people can help
Also maybe prioritizing

*A break down in small pieces is shown on screen*

Feature prep :
Nested virt is a huge undertaking
Few bits are optional
In theory it=E2=80=99s just a couple of instructions
It=E2=80=99s easy to implement wrong and create security vuln
Idea is to try and have each small piece have testing (XTF?)

cpuid/msr it=E2=80=99s an old topic, we are struggling to finish this
we don=E2=80=99t have a good way of controlling the features in the hypervi=
sor
There is a lot of code that assumes that all VMs are configured the same 
way.

We need to control all nested features per domain

Lot of other work to do : hvm fixes.
Lot of work that is not actually nested virt related
Some is deleting code which is great.

Mostly it=E2=80=99s not integration with the emulator that causes most work
XenServer goal is to get VBS to work (Virtualization Based Security)
(Windows using HyperV underneath)
An issue is that Windows, if it sees that virt is available it could 
turn anything on.
It makes assumptions that a group of features are available in one group.
To make windows happy it will demand quite a number of features available
making WSL2 working is smaller than making VBS working according to Andrew.
Viridian nested work has to be proven to work safely, this is a 
performance improvement, it=E2=80=99s not a priority. However you really wa=
nt it 
because otherwise perf are bad.
=3D> Make existing code work towards our need
I=E2=80=99m not quite sure how much we can use existing code (Jan)
Some pieces will definitely need rewriting
NMI handling, breakpoint handling are broken
We have bugs to fix wrt to MSR: the check for the bitmap is in the 
generic hook
We need to fix them (bugs) in order not to have security vuln in the 
nested virt case

Maybe focusing on one vendor first (intel vs amd) to have it out more 
quickly?
AMD has 50 controls, intel has ~500.
If we look at AMD first =E2=80=A6 it would help to have something out
90% of the work is common.
Teddy : Nested paging handling is not in the shown breakdown
How do we transition from the old way of nested virt to the new one?
Would it be ok to send a patch to ditch the old way?
Andrew : I don=E2=80=99t think we want to slowly move from the old to the n=
ew
Andrew : I think we should rewrite from scratch, and by someone actively 
ignoring current code.
Andrew : we should remove code and put the new one in a single release
If we are building feature by feature it should be doable
Andrew : if we do it in 1 release we should put the removal of 1 feature 
and the restoration in one patch series.
Running hypervisor that are not Xen , on top of Xen, should be part of 
the testing
Today most likely only Xen on Xen works because their assumptions do align.
XAPI testing for instance uses a lot nested virt to just spin up lots of 
Xen and do pool join etc

Conclusion: let=E2=80=99s do a first basic working solution running on 1st 
generation hardware, from scratch.

####################

-- 


--
Yann Sionneau | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech






From xen-devel-bounces@lists.xenproject.org Tue Sep 23 14:44:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 14:44:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128461.1468802 (Exim 4.92)
	(envelope-from )
	id 1v14G4-0006Uu-HJ; Tue, 23 Sep 2025 14:44:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128461.1468802; Tue, 23 Sep 2025 14: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 1v14G4-0006Un-El; Tue, 23 Sep 2025 14:44:44 +0000
Received: by outflank-mailman (input) for mailman id 1128461;
 Tue, 23 Sep 2025 14:44:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v14G2-0006Uh-LN
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 14:44:42 +0000
Received: from mail133-23.atl131.mandrillapp.com
 (mail133-23.atl131.mandrillapp.com [198.2.133.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d4ed65ca-988b-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 16:44:39 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-23.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4cWN6Z1dV4z35hWC8
 for ; Tue, 23 Sep 2025 14:44:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 94d0a8d6c86a4ea9abe15f9c011bd057; Tue, 23 Sep 2025 14:44: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: d4ed65ca-988b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1758638678; x=1758908678;
	bh=DmKrUPickkfvJc0Xd5IFkjipDk3pdqzLI+e+o4I2eTw=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=mc8170emKNIkM3mGb8gQcDPdPd1A8kH52GsDWtnWSSC/sQE7g7MEJzJwAJUA/ZXuP
	 qSofImjLVZJX/m/52PDkGGPny2osfvcdxkIGY/jzN1l7DK9TMPeMVoQ74asg4ZsNuK
	 3TXL/edI568Ut+DqK7Rml5TRtUsOm2SqXMcfx8sH1bMH4YjWyw4GaSRrqwRC6OKN7l
	 mvOHc/Jkr6GwFX3cPRZLiRzxMSEiORvdomlvzUeUv/wxA4mQHhGXpt5dPfou2tu50r
	 DpLUc1+1oQpg9PFv+sZc3uT9TqV1PYVCyJpzLoi/fzMUEOK5aLFtHNaEJTjCDAXq7T
	 97Z+gw/LttT7w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1758638678; x=1758899178; i=yann.sionneau@vates.tech;
	bh=DmKrUPickkfvJc0Xd5IFkjipDk3pdqzLI+e+o4I2eTw=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=wGydgrOw8LAvnL/syjVh2IbE6dJG7HGd6WPY7Ns2KeqICWE4RXekby6QlYbDoawGq
	 QA2fiZlNi6CONxd0AUHjmM6lm2H7rpOryI6zd6ZS1K6UDl8zgc6EGSbtcyV2Aw8vbU
	 tjEhzYyIy3HxdNjVJxEhzFmSy1RxHZFBo8xci9cZZFZCAHZE1go7Ep0WfMqwmRCMc4
	 hhDTvV7ZSv+MRO7VCx2SV6lia+jA87auT5ylShLL23PLT9hdbq3m/9A2bK2HiN3R6M
	 2JD1YUhQ5xtM3Maj8nMnPYUdcBzGvz/WeZ3cmKqO4YgkzAtSFG5hWZhcldvQaL09GK
	 s7Fz+4oNalYcQ==
From: "Yann Sionneau" 
Subject: =?utf-8?Q?Xen=20Summit=202025=20-=20"Documentation=20Next=20Steps"=20design=20session=20notes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1758638676524
Message-Id: <68f987fb-4845-4811-b559-7999e283cf98@vates.tech>
To: "Xen developer discussion" 
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.94d0a8d6c86a4ea9abe15f9c011bd057?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250923:md
Date: Tue, 23 Sep 2025 14:44:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

"Documentation Next Steps" 
(https://design-sessions.xenproject.org/uid/discussion/disc_Jp2T9yq2I3sH00t=
eD0CT/view) 
design session notes

Animated by Cody.

The documentation kind of exist=E2=80=A6
There=E2=80=99s the wiki but you cannot register: it=E2=80=99s deactivated.
We had to put a control system because some people were crashing the 
wiki content.
Cody : the technical documentation is being created in Sphinx
It=E2=80=99s hard to find getting started, documentation and guides.
It=E2=80=99s in the wiki but it also contain outdated documentation.
Problem of the wiki is that it=E2=80=99s not related to some Xen version.
Sphinx is at least tied to some Xen version.
The wiki also contains how-to=E2=80=99s, list of boards, things that don=E2=
=80=99t 
really make sense in xen.git but are helpful to people.
If we write pages on the website the number of person to contribute to 
this will be limited.
The website is in a git repo now 
(https://gitlab.com/xen-project/www-xenproject-org)
Some wiki pages are outdated because they are only valid for some 
versions of Xen.
We should have a getting started guide which is well maintained.
We could have some information in the wiki like specific getting started 
for some specific boards and then put the link to the wiki pages in the 
website.
Real documentation should not be on the wiki because it=E2=80=99s getting o=
ut of 
date and is not tied to Xen versions.
We should prevent people from writing =E2=80=9Cgit clone xen.git; make=E2=
=80=9D in the 
wiki, we should always provide branch/tags/sha1 so that the information 
stays true.
It=E2=80=99s OK to have some outdated info, it=E2=80=99s better than having=
 no info at all.
We need to write more doc/info.
Also, what do we put in the documentation for instance to explain how to 
put Xen on an RPI? Since we don=E2=80=99t maintain yocto meta-virtualizatio=
n.
How do we provide the domU?
We should have a user documentation auto generated from git repo (sphinx?)
So first we would need to convert current doc (in xen.git and some parts 
of the wiki) into sphinx format. Before then adding new content.
We need to link to the new sphinx doc in the website 
(https://xenbits.xen.org/docs/sphinx-4.20-testing/ for instance).
- need a list of supported boards, should be listed on the website
We should put some text in the getting started to say =E2=80=9Cif you have 
difficulties, please email xen-users mailing list=E2=80=9D


-- 


--
Yann Sionneau | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech






From xen-devel-bounces@lists.xenproject.org Tue Sep 23 15:02:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 15:02:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128474.1468812 (Exim 4.92)
	(envelope-from )
	id 1v14XU-0000zH-Vo; Tue, 23 Sep 2025 15:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128474.1468812; Tue, 23 Sep 2025 15:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v14XU-0000zA-TE; Tue, 23 Sep 2025 15:02:44 +0000
Received: by outflank-mailman (input) for mailman id 1128474;
 Tue, 23 Sep 2025 15: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 1v14XT-0000z4-OJ
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 15:02:43 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ab0f778-988e-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 17:02:42 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ee1381b835so3778357f8f.1
 for ; Tue, 23 Sep 2025 08:02:42 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 ca18e2360f4ac-8a47d925092sm557549939f.17.2025.09.23.08.02.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 08:02: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: 5ab0f778-988e-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758639762; x=1759244562; 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=VJNox54r0lPmdy3UucKOhC4eXV0k2IyMBun8tm2qtpA=;
        b=eh+6FsaBjHZED1O279jp/iuk7OUKIt0uLiPfOiQCkBGEZoQbX28rYXBzs+NdfxuL3p
         eghM00MlWWpO6cIvnc2CZBaUivFP17owIn9NAxzIechyDMyjjYAB+NRXOaMSuEWTu8fI
         Dyf/yjVNGeZ9qIPAApJLLm9SmZThUS4kcPEonLjga/S1X1412VxKeJCNn/j9RXcn8GHk
         8Xa6YxTUebuqsHZzLUarwExPScK3xNrJWQRvmKMOa2IhlQRpPa2MuJ3CSvjleNx+VIxV
         X1aVQOpwuyDTGEWWddgg5sNvrPyehZxslsL7Ph057c50lEScSELZ2rRuZLxYlFVWOUSM
         jy9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758639762; x=1759244562;
        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=VJNox54r0lPmdy3UucKOhC4eXV0k2IyMBun8tm2qtpA=;
        b=MMC9rly0FXzA42cWhBICM7DUOseUoVMJvCTFeawz3gNnELAXbqtL2wMV4bhwqfhuhF
         Fn6jWUgGfhD25PQKgehBl52tdiGI5XsuvqQq/pSJ3SYtHKEUm7OvFiYMxEWWE+pdtQaO
         1SzW7TZ4GS1mMPgFN1Pi8wjHQlOgx5mNW4SFKXqySq5yHcIecgwaZeOKE7+ji6NRn7Cx
         yUwDhnFON70v/e+QqF/B0qV0l2L+wEv2HyxkRZpOAcIcyhkQG5VnRRKar3mGr7xzx9iE
         hjw86jRx4vIXpqjBTQ8oSBqIjc9lEtKgbRqdCQineUOE+EBLgpJiHYC5dgsJnMe8Z96i
         loFA==
X-Forwarded-Encrypted: i=1; AJvYcCWk+Wu3Tm3zMaojyP2ZfaKFWnU4peOqNTdOkxzmMucVjI+p0/OKvtlEb7pFcMxV8Q3aPQL4Keg1Gwg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6PgOWSZyDs5Hr0aAI9b9wfuV49oMyc/Xe2Ur27g6F2NI8d7L6
	2SzN5YElKE7ZCv/m/dIeYp9s558zY+0SRkK4g/3Z441FCe1uPeDclxiJFvfCU5Jv7w==
X-Gm-Gg: ASbGncs7XbUWRiXtpnsXkP5hyvqkiF8IZ5sYZa/jB1vDmy+xS3e0/ZsJDb5z3cK3A/k
	uAQ2OMhUVllLZOuXf/u3hT+bS2PaTSIw3AKjnmXM+Ds3LfGjsCsXZALiWx28IMuGp6bGNHN+xi7
	dSP4J8mtJWYtXTvttCZFwjrlJWtV0aEFv2u43qTBThkOX4WRRpIRPBg5rhS+gOwsk8hmKASLCKN
	KZDROcIuXl8U4cz9k2m2KABbUbad13K/8SM2Y9qDrMyJEimUVFcoUuQ/0I24QXK+s6YdjCp7JHe
	060LvWVP5Nx9hDHBAJiu6K/iqVkGQ0XoIZDYcUWSNHwuPXhKGPAGPMmS7SbNDloNlCcbIQytV2V
	masyBl01dZLkoueUtjRZVsXz8Nc+Xnuld
X-Google-Smtp-Source: AGHT+IEQ3qWt9QoMFUCF5HyL9xYSwZ/REK5zTfo9GjDs0juUbv8VJyuYBmhp+tcYhb16d858sRNKRQ==
X-Received: by 2002:a05:6000:200f:b0:402:5708:629c with SMTP id ffacd0b85a97d-405ca959e6amr2075020f8f.41.1758639761698;
        Tue, 23 Sep 2025 08:02:41 -0700 (PDT)
Message-ID: <83441882-6b4f-441c-a10e-49be26516054@suse.com>
Date: Tue, 23 Sep 2025 17:02:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 1/8] xen/cpufreq: make HW_ALL the only expected value
 for CPPC mode
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-2-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250923043826.3831957-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 06:38, Penny Zheng wrote:
> Right now, no matter for code construction or hardware restriction, HW_ALL
> shall be the only expected values in _PSD for AMD CPPC mode
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Penny Zheng 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 15:11:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 15:11:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128485.1468823 (Exim 4.92)
	(envelope-from )
	id 1v14gA-0002bl-Pp; Tue, 23 Sep 2025 15:11:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128485.1468823; Tue, 23 Sep 2025 15: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 1v14gA-0002be-NH; Tue, 23 Sep 2025 15:11:42 +0000
Received: by outflank-mailman (input) for mailman id 1128485;
 Tue, 23 Sep 2025 15:11: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 1v14g9-0002bY-4X
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 15:11:41 +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 9b28d063-988f-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 17:11:40 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3fc36b99e92so1560705f8f.0
 for ; Tue, 23 Sep 2025 08:11:40 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-269802df8aesm166193195ad.89.2025.09.23.08.11.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 08: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: 9b28d063-988f-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758640299; x=1759245099; 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=eGQ9guI+tCSuiyQKmyajSqUi/6qy2GdsmB01BXZmrs0=;
        b=T8Hy7Zqax/0j1diZKt2QhLDSHiaPdBl6fkPR3KmmiHqGJ4maZMeqjRZbkd0MH7k9qs
         oyfeiaIkSp2zn/VlBmks7A0sP8te18bDVwx1DrRtmesg2RKzD7oktJd0oPFZzCDmV6Zj
         LsE6zNENnY/keTYvLQw0yNjS014ViMbSyZYyUW4TiNVC72xPrAqbxsSt8qxoV0FWtlfK
         18PZirmlpO1nV22idaj5VjG+ND8qo7r9mpH+WGuwzlZk32o3bxdoBxybDTU16yBcQ6ZU
         yJXc1ueFVKakASnfVC6VRmgVlAQ+j6xbZ6rUkv5mLAcVEuTETdGYQf1UgHN23k3Ar5mq
         2/6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758640299; x=1759245099;
        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=eGQ9guI+tCSuiyQKmyajSqUi/6qy2GdsmB01BXZmrs0=;
        b=ITMbvibohXdNL5LC0zwMc3G96qXF5cP4nR+zqvSSAU63hPkA228//i4vddU+GpEvxY
         cOjMvLUQi/st16Y7GPrs/lHI2zlprPOwrg+et0gDkCxD/I0GpODfFQ9CGKgfoTNdUvE6
         RGSCylrSJ7WGzVT+dYRZKOxfXcIq4dSVKRvXpUQEET9AZ2VrzJ8rsFa9dFTIhiR82BAL
         sh6QwpvwmTIt4GfYQ5SHYiOCz3ldgk+CiResoW4PvtqRoYHOOm98cmfmvt0D88F7hIzV
         jSkQSRyFHoqPrs/PAscJp6caZlNRnCIeEt626PyYiwZ+AsTbErsy9hbQ0jDsxancr4nf
         0Qdg==
X-Forwarded-Encrypted: i=1; AJvYcCVL8XSBUrqEzVVAIxH+7ksFabYQ57JwDAl7+IXLO+dZ9av/dkumTJQxhYps7WuTC/R3fomJ12t7Dnw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAl3W9tytOKu9ZbnJXmwkqcmeqRn6CiQs8rI3B1T0n0p1B2mb3
	GGeiFGHg+nKp+DEQMmjeroBJhW11kJ2a0JXpQXQjQMNJ7hnH3cyx2ePCuD0VycG+JA==
X-Gm-Gg: ASbGncvButVgs5e9QwY6RDk8aYxLxts7LeZn0b+OKYQhzD01QDwLzp5/+DSLMjUBnu6
	3voE/bxOd7JO70xxGwJ2UqjzGgrFN9tKvjgSLIEz3XtT7wu7vv5vLUCygzO6YU0eFA4RCTQfy0Z
	URPvMlUBpbX5DFSlMJsBkJUXtWDWVCOdliMlXvgBtRruF/ipsUDGbgknR+8/bWxxCtUUw0KtH9H
	Sw0QePluffEAiCstImHMQkQJLcm7hq/Dmy7S1XxNg+mJ4oN+p/k9rl+ug0cnX0pvc25dnohCdo5
	gnep8xtpxIwMb9VmsZwSSlU9LBZeviZPpH9wPQe6tz/PNdTxUJBuOibZcbXm3d3fWJyuKufEFj/
	3H7HasxIpA97FCwPRvs4ohoEoAcwe5+1RVtXWDB2twzI=
X-Google-Smtp-Source: AGHT+IFw6K0qAM9XWVpoD8l/82NEoEfQqly5si5XlSkUN4OVx3dF3tFosl5G7b6PRrAX+OxYtmvpCA==
X-Received: by 2002:a05:6000:2485:b0:3ec:db88:bf1 with SMTP id ffacd0b85a97d-405cb2f125cmr3121567f8f.12.1758640299470;
        Tue, 23 Sep 2025 08:11:39 -0700 (PDT)
Message-ID: <5badf139-1c53-4573-821f-20c343de449f@suse.com>
Date: Tue, 23 Sep 2025 17:11:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 5/8] tools/cpufreq: extract CPPC para from cpufreq
 para
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: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-6-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250923043826.3831957-6-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 06:38, Penny Zheng wrote:
> We extract cppc info from "struct xen_get_cpufreq_para", where it acts as
> a member of union, and share the space with governor info.
> However, it may fail in amd-cppc passive mode, in which governor info and
> CPPC info could co-exist, and both need to be printed together via xenpm tool.
> If we tried to still put it in "struct xen_get_cpufreq_para" (e.g. just move
> out of union), "struct xen_get_cpufreq_para" will enlarge too much to further
> make xen_sysctl.u exceed 128 bytes.
> 
> So we introduce a new sub-field GET_CPUFREQ_CPPC to dedicatedly acquire
> CPPC-related para, and make get-cpufreq-para invoke GET_CPUFREQ_CPPC
> if available.
> New helpers print_cppc_para() and get_cpufreq_cppc() are introduced to
> extract CPPC-related parameters process from cpufreq para.
> 
> Signed-off-by: Penny Zheng 
> Acked-by: Jan Beulich  # hypervisor
> Acked-by: Anthony PERARD 
> ---
> v4 -> v5:
> - new commit
> ---
> v5 -> v6:
> - remove the changes for get-cpufreq-para
> ---
> v6 -> v7:
> - make get-cpufreq-para invoke GET_CPUFREQ_CPPC
> ---
> v7 -> v8:
> - use structure assignment as it is a alias
> - add errno info to the error print
> ---
> v9 -> v10
> - drop the outer union

In the interest of getting this series in I think we will want to take
this patch as is (I yet have to see the other, related patch though),
but ...

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -478,22 +478,19 @@ struct xen_get_cpufreq_para {
>      uint32_t cpuinfo_cur_freq;
>      uint32_t cpuinfo_max_freq;
>      uint32_t cpuinfo_min_freq;
> -    union {
> -        struct {
> -            uint32_t scaling_cur_freq;
> -
> -            char scaling_governor[CPUFREQ_NAME_LEN];
> -            uint32_t scaling_max_freq;
> -            uint32_t scaling_min_freq;
> -
> -            /* for specific governor */
> -            union {
> -                struct  xen_userspace userspace;
> -                struct  xen_ondemand ondemand;
> -            } u;
> -        } s;
> -        struct xen_get_cppc_para cppc_para;
> -    } u;
> +    struct {
> +        uint32_t scaling_cur_freq;
> +
> +        char scaling_governor[CPUFREQ_NAME_LEN];
> +        uint32_t scaling_max_freq;
> +        uint32_t scaling_min_freq;
> +
> +        /* for specific governor */
> +        union {
> +            struct  xen_userspace userspace;
> +            struct  xen_ondemand ondemand;
> +        } u;
> +    } s;

... I don't quite see why we'd need to retain the nested struct now
either. Imo we ought to be cleaning this up for 4.22.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 15:15:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 15:15:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128497.1468833 (Exim 4.92)
	(envelope-from )
	id 1v14k5-0003B5-AK; Tue, 23 Sep 2025 15:15:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128497.1468833; Tue, 23 Sep 2025 15: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 1v14k5-0003Ax-6P; Tue, 23 Sep 2025 15:15:45 +0000
Received: by outflank-mailman (input) for mailman id 1128497;
 Tue, 23 Sep 2025 15:15: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 1v14k3-0003Ar-ID
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 15:15:44 +0000
Received: from 7.mo575.mail-out.ovh.net (7.mo575.mail-out.ovh.net
 [46.105.63.230]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2b59cf86-9890-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 17:15:42 +0200 (CEST)
Received: from director5.ghost.mail-out.ovh.net (unknown [10.110.58.221])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4cWNpP3QCjz61Ct
 for ; Tue, 23 Sep 2025 15:15:41 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-qz28q (unknown [10.108.54.212])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5CC341002C5;
 Tue, 23 Sep 2025 15:15:40 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.105])
 by ghost-submission-5b5ff79f4f-qz28q with ESMTPSA
 id W8PTBZy50mgwnQAAfDlrFw
 (envelope-from ); Tue, 23 Sep 2025 15: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: 2b59cf86-9890-11f0-9d14-b5c5bf9af7f9
Authentication-Results:garm.ovh; auth=pass (GARM-105G006abded6f1-020e-4577-a8dd-717f329057bb,
                    4804EDC472500D38916C4D805CCC5D85F75C271A) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 23 Sep 2025 18:15:35 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 06/22] xen/arch/x86: reserve TXT memory during Slaunch
Message-ID: 
References: 
 <8d5ba2e7a0a8bd05bb9cdb89db3f15b831f7f4f7.1748611041.git.sergii.dmytruk@3mdeb.com>
 <45ed8b90-ce0c-419e-9c7d-2ab58ee539a2@suse.com>
 
 <0e901379-41a0-4fa0-bfbb-3407162437ff@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0e901379-41a0-4fa0-bfbb-3407162437ff@suse.com>
X-Ovh-Tracer-Id: 13374846470647690329
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTGW+fB3FvHuHalR6aa/VleIM8DGerkyqnGAZiWZTY3GNP//LyrJGoKNWHJwaW/EoQgHQ1JdLjIPtC8Bt9fxwhQXT2f8pZgJMSnNWpxAaCzefp3I5VZLbmnIfdtzlq0oDwhoay/jek9atYOS+1uo30iXKl1EZ3QZrjqCPDbKI8NAguC3NTi1eqUySaoUKeWydZWMTycS2SVFvjVbri15Pyy4OOf1Espje8kDQbPBIMcLwxI5yFO+rgp3wTey8Qs5nbobZY8cGRkNc11Y1kWsZ6D6svV3gCi82USuhI1GMLtj0chCzYrchedVzmPMn1S7kxL84UFep6vSr7k8f2uNds1JW1/+4vOxkSrREzAQnIbpWp2B6Hk2VUqFRPFVoj2ngm7pdXWVlduf5x4Y2vULftsqEh3wNUbB5/xzy+bkUeozh+21vg88rkYdB2iA5iWaleYxJNfxEeKN9hheHWIj45psSoZcI9vvnjgCSsyjGGHWX9LIjCuyKbJU4tiBcNGXEuffs5R1EMyIUg7UQ622pQZRGPUrKYWRE4B01Im0uDrbD386jDyEXm/2GXYrEZaK1eyd+zZ0P9tUpt0y8dlzQp2fbL0YAYYJNQUSHXrw4Mse4JqGEzxpBMqaoR/duSJ7OW/WdulmAVNLVZXSt7rxODvTRfjqJ2UT1/pPY+OqDpSStA
DKIM-Signature: a=rsa-sha256; bh=y/DqvfLeECh6dzUzGl4pfXs7tw2bn9zxdpOj5/tUNHU=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1758640541; v=1;
 b=MYOXOaZi403oYvn8gVHnX8ol99SV+rVgyMbvfm/Bc0sBNPnE+Fr00tYH0QQfm4pUxjWSdaZo
 mMHOJV5qQkekizq7H3JnA1dmJf+isoOKA4w3uoTjwKvg/fBM2tpMV3dhuvqYPDxWZY+IMhfbOuA
 PFVAZWFABsDBb0WNgceE6GgoZqxORWFIrSVwd/mHuq2S7Ty2LITc1xnOY8obz4tbwzVYN6/qHZa
 mGJxamzGMGD6OM+DIhLgVegW2ztS3nQMoZlggaovgV17CuAiZ+Y1dGBlhcODqRbHWibA7/xABhV
 BlhZSF21+yWhJbBZhHukYcyeh7G5EeTJ6br3/ow5vjdnw==

On Tue, Sep 23, 2025 at 12:48:55AM +0200, Jan Beulich wrote:
> On 22.09.2025 23:35, Sergii Dmytruk wrote:
> > On Thu, Jul 10, 2025 at 03:00:07PM +0200, Jan Beulich wrote:
> >> On 30.05.2025 15:17, Sergii Dmytruk wrote:
> >>> +void __init txt_reserve_mem_regions(void)
> >>> +{
> >>> +    int rc;
> >>> +    uint64_t sinit_base, sinit_size;
> >>> +
> >>> +    /* TXT Heap */
> >>> +    BUG_ON(txt_heap_base == 0);
> >>> +    printk("SLAUNCH: reserving TXT heap (%#lx - %#lx)\n", txt_heap_base,
> >>> +           txt_heap_base + txt_heap_size);
> >>
> >> Please log ranges in a way that makes it unambiguous whether they're exclusive
> >> or inclusive (especially at the upper end).
> >
> > I'll use start:end notation which I think suggests inclusive bounds.
>
> Please use mathematical notation when logging ranges, i.e. [a,b) or [a,b].
>
> Jan

OK, initially I thought it's too uncommon in log output.

Regards


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 15:38:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 15:38:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128512.1468843 (Exim 4.92)
	(envelope-from )
	id 1v155y-0006F2-1G; Tue, 23 Sep 2025 15:38:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128512.1468843; Tue, 23 Sep 2025 15:38: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 1v155x-0006Ev-UU; Tue, 23 Sep 2025 15:38:21 +0000
Received: by outflank-mailman (input) for mailman id 1128512;
 Tue, 23 Sep 2025 15: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 1v155w-0006Ep-KT
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 15:38:20 +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 539eb33c-9893-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 17:38:18 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3ee15505cdeso8325f8f.0
 for ; Tue, 23 Sep 2025 08:38:18 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-77dfbab0d7dsm14027525b3a.60.2025.09.23.08.38.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 08:38: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: 539eb33c-9893-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758641897; x=1759246697; 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=qkpa050QiuFYPeSbtJ50+R6ZAITj31cmBB1nCQNZsfI=;
        b=AyZLhsb9/DKQn8kTi+y91gkIBJxRzz8hdsvWwBULqbqrfZV8oi62JgbYCRi4S7i9Vg
         yGkFFd0KhTJCkZAJyrTX2C+UdVPpQ1FIMhEtpKKzCjtluk5Bdf72KzdYPGAxk1r9GUjA
         SlOZKps4hzMiwW52KG9C5ONgIbhHvbK98mDK/I+cVzoMRQYdLq20gP0bWCLirRnblwrq
         BDPh/FR5NLA0GQXS2daZrSgXbAfMXikapWKci/kr8XxkOpJFWtsDG08RFKHGlSHwKTW3
         2ZNiFP/4+/dOOCuBNZWAG2EgaK6U9Ve/uiWO4KZZNi9zw4u2vJgj7fv5qDW50kyeLYKZ
         GT7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758641897; x=1759246697;
        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=qkpa050QiuFYPeSbtJ50+R6ZAITj31cmBB1nCQNZsfI=;
        b=WI/qCCuFIlsUbqV6qGGP8ls84bE2YIrIbIIR7OzA49bUSQsNMLovcQgvSiiPB2XgZO
         PDrQg86lUhJqRfEEimHNe56WuHwjxzpRG8PfcadMVqmTXeE+H6+i0jDpEi03Wg4JhI2z
         gvBMDGIOsjCn4OM4LWw9iLr5AMvpqsGNaBFqGxGC7/Hnu4EY7nxihxuB2ZnDk1YbTSA5
         F0peAWiHmE7NdqqnOCob52AUx7IXOzuXa0YnzsPaxwpMiZh2kr+lbF2hIWeZmjL4ycNK
         0wIgQFcx+xVF0BLCv/V0mTiPtNcBNe2C43BpyJ0tdZpHFT7qt1ynshHv+2TkSd+TM7Gn
         XRNw==
X-Forwarded-Encrypted: i=1; AJvYcCVi9XTt8lPKOX+bKp/G7oVBBnriKqM9eVNDFFrFw/aEY70k9fjvDNXAl20JlwxGV1PJTFko+i1w29k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNTXSVnqBdu/IyeFFPQPZW3s1frgc0bcw8JQoipYF0PnF2T79l
	ANi7tAHdkqdyiCDEvH8SETb5f2/1hg+tbXeuSqF7w0eFjaR9dSP9XQOgMZEYv4LQpA==
X-Gm-Gg: ASbGncvHdp/j0ftjhsk/DZT5jyvwS0ooNTZEYuCqtQhfs6eROfNDkqXnOybIc/zaVeK
	SavFEa6L2ONOlxbe089yR3j+0QYxi2oxdp3FiBT3n2s6JjHWqVkk4DkMehrBT2MLz7FzTP1fIeI
	y3+Bc6iONyeqxzwXvkwM69+SsVuP5aUFzlGZS9O/9bEd9KRLYdtqeqaxBIzQTmhcIe1QLXeVjO3
	BBT1sSt7l92qr993Sg1VaF1UR516R6akOPj90UcpR4XfJ87bQdpdkQj6iQYtJU2lXJ29V9DS18C
	32t2BB1FPxKQP/aZSDM5lDGLpTVCegJeMJ0BHeNk+zi8CtQ9cUwyrmDdFY8NG0QIiNKq0tJb08e
	a87ZLfHBJQTPmr+EqJqq7lXHhmCZHUTVEnPft+m1EE3Y=
X-Google-Smtp-Source: AGHT+IFuZOw5+Sw+/gOiO5oP+KbpRlNGoJIXK7Lt06PWhToG3M/JX3V3sqXQkyTiNamM0l9u023UBg==
X-Received: by 2002:a05:6000:18a5:b0:3ec:42f9:953e with SMTP id ffacd0b85a97d-405cb1fbf3fmr3039734f8f.7.1758641897376;
        Tue, 23 Sep 2025 08:38:17 -0700 (PDT)
Message-ID: <5a2e887f-d6da-42e2-aff0-efe55b041749@suse.com>
Date: Tue, 23 Sep 2025 17:38:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Penny Zheng , Jason Andryuk 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-8-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250923043826.3831957-8-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 06:38, Penny Zheng wrote:
> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>      else
>          strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
>  
> +    /*
> +     * In CPPC active mode, we are borrowing governor field to indicate
> +     * policy info.
> +     */
> +    if ( policy->governor->name[0] )

amd_cppc_prepare_policy() may leave ->governor set to NULL afaics, so I
think you need to add a NULL check here alongside with pulling this out
of ...

> +        strlcpy(op->u.get_para.s.scaling_governor,
> +                policy->governor->name, CPUFREQ_NAME_LEN);
> +    else
> +        strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
> +                CPUFREQ_NAME_LEN);
> +
>      if ( !cpufreq_is_governorless(op->cpuid) )
>      {

... this conditional.

The description also continues to not mention the effect for HWP. I'm
actually somewhat confused, I suppose (Jason, question mainly to you):
HWP falls in the governor-less category, iirc. Yet it doesn't supply
a .setpolicy hook, hence __cpufreq_set_policy() goes through the normal
governor setting logic. What's the deal here? The answer may affect
whether I'd deem the pulling out of the conditional correct (or at least
benign) here as to HWP.

Jan

> @@ -178,13 +191,6 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>          op->u.get_para.s.scaling_max_freq = policy->max;
>          op->u.get_para.s.scaling_min_freq = policy->min;
>  
> -        if ( policy->governor->name[0] )
> -            strlcpy(op->u.get_para.s.scaling_governor,
> -                    policy->governor->name, CPUFREQ_NAME_LEN);
> -        else
> -            strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
> -                    CPUFREQ_NAME_LEN);
> -
>          /* governor specific para */
>          if ( !strncasecmp(op->u.get_para.s.scaling_governor,
>                            "userspace", CPUFREQ_NAME_LEN) )


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 15:49:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 15:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128529.1468853 (Exim 4.92)
	(envelope-from )
	id 1v15H6-00082J-4M; Tue, 23 Sep 2025 15:49:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128529.1468853; Tue, 23 Sep 2025 15: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 1v15H6-00082C-1K; Tue, 23 Sep 2025 15:49:52 +0000
Received: by outflank-mailman (input) for mailman id 1128529;
 Tue, 23 Sep 2025 15:49:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v15H4-000826-6V
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 15:49:50 +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 ee4c3385-9894-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 17:49:47 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3c6abcfd142so2969267f8f.2
 for ; Tue, 23 Sep 2025 08:49:47 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2698033d2a7sm162324465ad.132.2025.09.23.08.49.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 08:49: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: ee4c3385-9894-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758642586; x=1759247386; 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=YIXLZ6wtLSNO82FKH5qMMgF8Aw0iglLLXwNwoihRs7I=;
        b=NyRGaYT+vynd258YP/ucJ1MPTMTW4b57QTAVy2+/XBE1C7br2yTi0GBevFoqu5QF+0
         qYlu2TlXS1I838GZiTFwUhIhawMYx2Jmhbfz/K6C6gNDNjIYAjKcPadYM22wOWQYErhA
         Fxu7WPCgz2FQ/ZXqfefcHOV7bXba41s9q/46iY+EJCpMd/mHY92hfwsealwMjsAJzyc5
         iYL1t0Jei1t6uwXIUJbkE3/74EMAWhW4Bktwj1FLeLBUWuHc3UVlT0c5CMntd5XxGR2r
         n7ptvpcPUdVJ9MqoyhK581wMiBoigyID+JiTRNHBhripNZ+h6SvZQ3b+HPkndf+rmsD8
         J4tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758642586; x=1759247386;
        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=YIXLZ6wtLSNO82FKH5qMMgF8Aw0iglLLXwNwoihRs7I=;
        b=O1RfWfkJw6vm8oL1jAt4rhTDZaQjqZ3qKNdGlY5JvXPA3akWWOGRJX7Mwjs8Q6YElH
         xDm0qf/Y6RPrRo6K6rRqIGUJ6Z2ysraqkVB5p3fg863UWZGztZ9e6rABrLbKsJ+1xQrm
         3RzpjLxCNahBkprteutUEz7u1KnWiyLN3f/Jq0SDKNo4UOJUNC0MJZxQIH9fu43R310y
         +qF47qwHaA3EGuhlwUKmpaS+KtCWHTYRltTunUOsE1DGbKIdA6pTi1u7xPIIvXNVIhKo
         vgcL5RwLi5HcKzyIDc4B9E4n3VAibYTmAxyeEW4VXsAi2BAnRsQydS4Ch8NAz5zOonX2
         hRLQ==
X-Forwarded-Encrypted: i=1; AJvYcCXPZ3WmHm4Otvz3sIRvE5ET8KsGi1D/RvbeMyMfIannaY3wZGZQIJmT1GZwPKh8nIegMp3Inu7GDZo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz34GsxlKGtNcC9wG6Rjd23apyyNOnwLg+gmpjBPl+57+63/r1H
	7tUOW16ydUxtq/FEKCua2SoRXhk5liwRmksRpVPDYUbVF67KHY0ARsBeUYT46Qv7+Q==
X-Gm-Gg: ASbGncubJDSZqgBu5t4q+cY0N+YOBKM2fxEdFyb/x2EmKyMZB26ldY7N+ggL3aVtB4/
	UTk7YnakbJDh5BKsLE4It1WxkV84wWHP5qNOmk7tK/K6sqkch2M3f86rVEbLOY3lEBGQfhe2VZc
	HXr5e8b1ItzEfq6VW7AfmJ8v5wlKOPhQ+K0KkOjDSIYZUWDgM3yPAW9rvtCi3wm3V0Vw/X24lSM
	zPkUcjxUvYZdgjbOs4fiFqgaI8LepN4XBgRuFZpn11eHyM2I+e2dIpxI7Ex7ru1XPkpYIyOkOGg
	J6yLuVnNMVlRiR6jqTSy3ZhUiDPEeD09/w9q3cmtiwBsQby+HPvauYFqNIz7huQJmjxgFZXK80Q
	6Aois3pO+pncwAnpSUVPF5n61tAZU9HK0
X-Google-Smtp-Source: AGHT+IHDZO4d7554m56fpV/LMcCzijcOVPHpqvWSUxHwVTIcNmxdYtTqX9Dp+iA6oFJmJPlUMlImrg==
X-Received: by 2002:a05:6000:401e:b0:3e7:6104:35a8 with SMTP id ffacd0b85a97d-405c9a01d96mr2258466f8f.35.1758642586403;
        Tue, 23 Sep 2025 08:49:46 -0700 (PDT)
Message-ID: 
Date: Tue, 23 Sep 2025 17:49:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/7] xen/page_alloc: Simplify domain_adjust_tot_pages()
 further
To: Bernhard Kaindl 
Cc: Alejandro Vallejo ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: 
 <15ae395c6933e74da0cdd8f9d71d349a7bfad3f3.1757261045.git.bernhard.kaindl@cloud.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <15ae395c6933e74da0cdd8f9d71d349a7bfad3f3.1757261045.git.bernhard.kaindl@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.09.2025 18:15, Bernhard Kaindl wrote:
> When domain memory is allocated, domain_adjust_tot_pages(),
> also reduces the outstanding claim.
> 
> Replace the checks to not over-reduce the claim beyond 0
> by using min() which prevents the claim to become negative
> (and also not be over-conumed for the node and globally)

I'm okay with the code change now, but upon re-reading this it still
feels as if this was describing an issue with the original code that
is being corrected. Afaict there's no functional change here, and hence
the above may want re-wording accordingly.

> Cc: Jan Beulich 
> Signed-off-by: Bernhard Kaindl 
> 
> ---
> Changes:
> - Was added as 2/7 in v2, the review by Jan Beulich is applied.

This, imo, isn't a useful ChangeLog: It requires readers to go look up
the comments on the earlier version. You want to say what has changed;
upon what basis the changes were is (again imo) secondary.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 15:55:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 15:55:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128542.1468863 (Exim 4.92)
	(envelope-from )
	id 1v15Mq-00019W-Oa; Tue, 23 Sep 2025 15:55:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128542.1468863; Tue, 23 Sep 2025 15: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 1v15Mq-00019P-Ky; Tue, 23 Sep 2025 15:55:48 +0000
Received: by outflank-mailman (input) for mailman id 1128542;
 Tue, 23 Sep 2025 15: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 1v15Mp-00019D-1f
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 15:55:47 +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 c445ad2d-9895-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 17:55:46 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3ee12a63af1so2573169f8f.1
 for ; Tue, 23 Sep 2025 08:55:46 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 ca18e2360f4ac-8a46d5772ebsm567205539f.7.2025.09.23.08.55.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 08: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: c445ad2d-9895-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758642945; x=1759247745; 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=9Qfm+OzAnchWzhLAzcUVzHke/chdTkt5EecfMWvjA9E=;
        b=PY77ZHEuPrj6Rx23xN2RTpcwyCGqOvvqpklrOyIr/9YJzcjOEzyciuh72dNN5KtpQA
         P73Gd0EkT9ivxf0g24sOtEDqVlQT8GP6eW9VxUjECDzGk13jCTs1QEJqK5cWv5Le9OYs
         kyJUd3V0AxQs4yZQvlWIZdpSf7vp9qN5Dv/B3i0KT1Go7q6ktDz8S5Up7ZcgshWcBIvp
         nbxjsIdUhUZV5oZ+ALR3EAW3rU5ZQ35lwxD8xEQ4El8100WgP5WUup2TN6aeFJ0I5Gq5
         xLIVbU4616XssFFWm+Kbtehqgc6+7GhI3XI1KtwpxeOpX2DnOqS/+Dm0kqx5eS9/7AN2
         jnGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758642945; x=1759247745;
        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=9Qfm+OzAnchWzhLAzcUVzHke/chdTkt5EecfMWvjA9E=;
        b=Fhrv47AotnU70n8SgULjbhsFLrC3MMcCMdvqBGFGPumthgUUTDHYmciiO8DzKq8dQh
         Al1dtgqlyaRYJjAHITC8cLVQXrVGqbSXJ3YoQJiBDm6jeGCgIRFfGglK4BWLCdXRHudM
         AcNpFDogs6bidtLiIqpuPs8TZnn0TQu2JzlRfL8T5cFW6EC+FWYNtDOnEL3rL/OyFSQB
         W6RtltW8jO8RtKps23oc1/AFgA6THtfiUZTD/TEM7REn2HUq1KopklBe/uwVVufoS2o+
         ntPdO/+n77DsvonsuKgpWNfUwkitXvRMJqZ1A62i6Wpm8oSs2NIhfSK30pqUDd2obHyB
         aVKg==
X-Forwarded-Encrypted: i=1; AJvYcCUuT7BF2ZijiCO0AZgJQwKHuipFsiEI4ofoPY4B7rf0RXVvPI8fcMBNqRVcyYrzBRikhLgM9qKpJsY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCKjU2D5LkDjHcIn8he/i3Ua4v328GswK4jMf40eG5kqSYPxze
	Rutd8PoYJcptMNLmCQEQXnJm8FbIRb5qBAqNSE6FCg+x1aIvnSowcS9XdjKui92KKw==
X-Gm-Gg: ASbGncs5H6luQkqOKRqy1bjSL2d0uhL7l/bSEGKT3l5miwbd6CjysT62X0Nc0T+1QNm
	MmJ/MSxhCeTcwq5Msydyrd+/PKf25YTANqHesuA8/UWdFTBToiHKofjPGBtQX2VuMF7+oY/8hY0
	Q4ED7/xhDwmC6lPI976IZlajh6MpmhJJSt1PznCvha7D3pGO0gltVEmmUJzXfKoMmqovlS+8Pfr
	zykwVXzghlWufpAZa1a40yLatIFL7jsC1GiaWHR/lhd6AUT5IqV/Ok3td4GYRZ+LwGwMiiRBWfL
	WNBp2QOSeoonF9vZpAkGSKvOJ0P22HXBB9YiBdWsLeIO1n2RGo3W1sHD80otcB9EJ1SrZI6XsiA
	w77N/dcjTq2cmNrptka03EaGqmx3wLrb/
X-Google-Smtp-Source: AGHT+IF3A6r3XlVwD7NPIrOKt7r9xlsFK+UDbCrWOBDakls4fCsCcPx27AE5F7UNWoddQo1Sxfoh7g==
X-Received: by 2002:a05:6000:186d:b0:3e7:46bf:f8bd with SMTP id ffacd0b85a97d-405c5ccd210mr2388925f8f.23.1758642945377;
        Tue, 23 Sep 2025 08:55:45 -0700 (PDT)
Message-ID: <79be9616-f943-4ec5-ad1e-d1ad29e6d9c6@suse.com>
Date: Tue, 23 Sep 2025 17:55:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/7] xen/page_alloc: Add and track
 per_node(avail_pages)
To: Bernhard Kaindl 
Cc: Alejandro Vallejo ,
 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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.09.2025 18:15, Bernhard Kaindl wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -486,6 +486,10 @@ static unsigned long node_need_scrub[MAX_NUMNODES];
>  static unsigned long *avail[MAX_NUMNODES];
>  static long total_avail_pages;
>  
> +/* Per-NUMA-node counts of free pages */
> +DECLARE_PER_NODE(unsigned long, avail_pages);
> +DEFINE_PER_NODE(unsigned long, avail_pages);

Why both a declare and a define, but no static? A declare, if needed, would
need to go into a header, I expect. Whereas if only this CU needs access, no
declare should be needed, but static be added to the define.

> @@ -1074,6 +1078,8 @@ static struct page_info *alloc_heap_pages(
>  
>      ASSERT(avail[node][zone] >= request);
>      avail[node][zone] -= request;
> +    ASSERT(per_node(avail_pages, node) >= request);
> +    per_node(avail_pages, node) -= request;

Seeing the avail[] adjustment in context: What's the difference of that to
per_node(avail_pages)? I don't think the (apparent?) redundancy is properly
explained in the description.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 16:09:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 16:09:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128555.1468873 (Exim 4.92)
	(envelope-from )
	id 1v15Zu-0003gX-QT; Tue, 23 Sep 2025 16:09:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128555.1468873; Tue, 23 Sep 2025 16:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v15Zu-0003gQ-Ng; Tue, 23 Sep 2025 16:09:18 +0000
Received: by outflank-mailman (input) for mailman id 1128555;
 Tue, 23 Sep 2025 16:09: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 1v15Zt-0003gK-Mx
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 16:09:17 +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 a7610cf5-9897-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 18:09:16 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by PA4PR03MB6912.eurprd03.prod.outlook.com (2603:10a6:102:ed::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 16:09:13 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 16:09: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: a7610cf5-9897-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=erCHRTdJo9SV9hmG+pMBzAHKLO/9qdYHa0F9L+xx6KgcklUPLPQEdwIHhkVCHbHbWHEIK9yB0B/8bBIg/yuaoU2PT0bykuQAYOwVDH8z7puKkwwBsYlA8kes4+upc/4xf1rddg6u7KOzLA+msJwAMJJDMD2pyt+EoYhkyatHg7Tewy0volnmHsvknBF5GA3ygzdu+8+Igdsg0Tpn8z5kaI9ByWQg1e7gxP/h6p7KYn9GF0DCqq13/vhoCPgyc1vIzy8OIboNbhIJB38K6FMYD5RALyxx/82Ix/BP/0DaMPEDLWajfBK21iGL4NrCLgz/fBigQv14M5FJnJAOqPjDdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RgYbIqmPzaadCHsG1AUdsgMu2bZQyrWqSA+X/MCcE44=;
 b=S6qJ+0Pgv8OI0TX9NTaH7/0/NT+hiEX+9ITxm2TVvi1PHDQrjXuyx4Wf39njhagnEeYJyCwCVV4PWunUgN1vAG7jPwQVXLKr5WutIiYeKQ1T7sMuNB8AcyNbWK/aMpM3ieoJYlo8TuiS15PzJwJd4t5pg2nFP9Ncbpf3sW9UkLPp181pcwHPL9Z99EyS8zyzU9LZEIDyzWTv9F1RDugM2pzv7tIZvt+JbJTvQ8M3NVGc60Xy9Cfyx9cMOvwqt1UeszqPlSm3eKZ3+eHYyj+qHssqsm4FHMpTgDtu6zsYWlhswphnr7k6n89LbAh0Re6Jq3W62KR/mjlZZWE3nVmkJg==
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=RgYbIqmPzaadCHsG1AUdsgMu2bZQyrWqSA+X/MCcE44=;
 b=Z2XZMyvWcVdn50rPho5LjW+8be3zFVa5CWJiiLbb3MgBuTc/V/QVW4Bevo4fP7BBmoi0FBxusOp+PDjJbLtiyipg4xIc9xmdJodvf9ajotsTRgQSbRIZEzhY3mkRWABJjlxxRmmNLVobY5mbhDfnO8tyzH1lNJZc/fqwAeP6862fzF5BfYonNFRmNBfBknpRlfU8yXNPX3myogIUy9Tu7ywl/WLXOyzrI/y1dzhyLN3f3c8Lr9uopegQ1T64NQ8CJdle+WPgKovDM2UQ88tBQzLY7Zc3Y9UAVBSJ9QzWdRAKPz2AqSdCvd0Un2PTSaQam3qLzrv4pLzc0N2lTD0blQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <0e69a741-b6e1-4315-91f0-581f72092c68@epam.com>
Date: Tue, 23 Sep 2025 19:09:11 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/4] Implement CPU hotplug on Arm
To: Mykyta Poturai ,
 "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?= ,
 Juergen Gross 
References: 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0405.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:cf::11) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|PA4PR03MB6912:EE_
X-MS-Office365-Filtering-Correlation-Id: d1406d52-630c-44db-5cfe-08ddfabb8970
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OHRrYndtbzFzaTNOUW9RSGpqeG1oekNVREZMZkN2Ym1VbjFoRnFWMlZ3M0Rh?=
 =?utf-8?B?NC9MWXFldVdOUURnN1piWFo2Rm9VbVpzRXpvbW5uWjliWHhoamZFZDRub1lN?=
 =?utf-8?B?b2NSVUpDYlhOMTI5a0xzRzF3K0lqV21iWEpQWHFES1Y5M05DSjdDTm1sWlVE?=
 =?utf-8?B?N2pHaGU3RFo1S1RoaXpBelhjMkxxbU9aNENZYm5GVDltYzhidkc3S3g3YUpO?=
 =?utf-8?B?ZnBmdm1JV1ZxcmhLTEk0ZzdjQmtuazNuY05YejZKazVmdDlaR2JQZC8yeHVh?=
 =?utf-8?B?SGJzczFhaCtvTllvdEU0NjU4T2d2SUtoQkZjWFRFQVZwZDNhQ3hqWVlFdzJL?=
 =?utf-8?B?cVg3cDl0WnZlNEl1Yk50WUQ1V056U1dxTGR4bHBkT1lJcUx1TkpZQ0xqNjVq?=
 =?utf-8?B?dURYOGluQmhiaDdibFF4UU1rUm5QZkpRSWpXYzNrOW9mSXc2aUR2cjFCcUV0?=
 =?utf-8?B?L0Y5V0tqMWplR1BiTGFScldwRFBObTlhaGs5SzhGeTBYR3R4anB4QzVDYUtv?=
 =?utf-8?B?UUt1c0UzQitEejN5MGxFOWo2TjVsNkEzUlFsY3BYaWJwUm14QUk0NThUSGdy?=
 =?utf-8?B?Sks0b05qRmNUU2dWNEVENlgyOEg5LzdqcjR0RUNhK1JWdWNIUnBiZ3JFenVx?=
 =?utf-8?B?L2hxTXlVU0lYTlFhcGE4dXhtOG95T0hsUjFWdEhOTmQyQzRENktHeTJua1Vj?=
 =?utf-8?B?dy9ydk9UMXdWL2ovS0o4dEZuYWZhTElBdEZRQTR4NW4zZEw1OEY5T29INXM2?=
 =?utf-8?B?N05kMi9RWjVUbXg3b2lmYWxPWnhJOTVXcmI4NENzWlk0b095eDRRbkFnMnF4?=
 =?utf-8?B?QVI4OFFaaE9KUHNQMWczNUZtWHVYY2ZDVFFTV0tTTmdaY2JJK1dzVmxOYlVK?=
 =?utf-8?B?aWhsa0hCWkQySE5Bd1UxVTB2cmcwNnlMY1IxTkxabHVWM3p3MFEyUkFBWDFJ?=
 =?utf-8?B?V3c4OHF3alM5dXZrN3FSeld5b0JBdWxySjN3Z3JqZlNENE5ZT29CN3J5eDdB?=
 =?utf-8?B?WWNBakpUdTd5c3V3aEtZbjNOMU4xVHVCUHBoNHUrcjZNNVZBWURxNURSMjBG?=
 =?utf-8?B?Wi9uZlAzNWM4RHo5YThyQ1VhQWlnejVqU2FpQ3cwUjBCbjRmN0lXckdzT09J?=
 =?utf-8?B?RzYzMFoyR25FQ1Nha0V3Q2JLOHhMK2FBNFo2Y1dibGZPNGIzZnVlOURxYmhm?=
 =?utf-8?B?WUxMYVk1VHpNK2RvMkVCUnBiZUZueHUxcmVCbW1LOXRZaXVPaGhPRzVib0FK?=
 =?utf-8?B?elFITnpEeXpaNnZ4ZXIvUk96a2M5clg1d3dLVUdHQzVaa1JBRmNWVDJLbW55?=
 =?utf-8?B?S2EzOXM4RzZmekQ2K0lBU2FGb2YxbGFnclZyeVFoTHkxaGs2ZlJrNkYvV0F4?=
 =?utf-8?B?bExRVnYwbVRsMVdWZUZkR1FTRWhqZkFHUWlvdlhzUmwzZWhteWVHeklDVVFF?=
 =?utf-8?B?VjBzZlZNcml0a1pLTHlnT0NOS2ZncGVXSWh3a1EvUElYTXhRei8xcWxXYTBK?=
 =?utf-8?B?Y3M2ZHVCbGJoN0pKZHJmMU01bjB0S2k3NXdtNlZBbHVtYTljRjMzNEtoclhh?=
 =?utf-8?B?WXpBcVMyUGY3RDVYU1ppVnp5UEhUZmNnWHMrL3NWWmt6L2NaU3VaMVc1eTl2?=
 =?utf-8?B?SG9YWTJoM2tIT2hOWVdXY1BMcjd4UmdMejMraW1kb2I3RUtqSzIyQ3ZKVDhZ?=
 =?utf-8?B?d1ptK1NmNXRJY3cyZ3FHZmdjK2orNGhXUHQwUHR2dG5DaEhFS1BiTEZBaURU?=
 =?utf-8?B?czZjcWJTcXRvTU1hb2ttKzFValkyUk42T296dTZjQjR4OGc1V081UVczN1NT?=
 =?utf-8?B?OXVuQWxKTVNwQ29BWTIzSDFxcWxSYTVpWWN5RlJzSXd1VERRZXQrSWtnVk1k?=
 =?utf-8?B?Z050S2Y0M0xzdVh0Z0ZiT2JIM2FJZXczcnQ5VExQV0VxaHlIYjdLT1cxUUty?=
 =?utf-8?Q?EZbiu05cbM4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YVlYakJ3QjFnZmVmVzRSTE5ob3h0WkZReTQxdWFSb2tJaHdqbEZhdUFPeGxU?=
 =?utf-8?B?amtZZDlGSFlnZjdsVkFZcHNnaDhHc01uQlE5VkxyZEpuVE05SlRxdzFYUEVB?=
 =?utf-8?B?U3d0TmJVMExDcWV6bzBaWXNTcW5GUHZwaWRkbnpGMEM3cEJxTzAzYVJabDE3?=
 =?utf-8?B?bmhmd2VjMEk3Q1hpREtRZWRSTzBoc0pkWDN6NHc3a1NuTXo2ZGM3bEdQZ3lt?=
 =?utf-8?B?SFJnc3N5UnN1blBiSldIUWtDOUcvSXY3YjhaNGNCNnM0QVdXa1o3ZUhDUEhq?=
 =?utf-8?B?cFlURTRFN3BBUVg0a1FTeFYxeWk2Wnp6eHB5Q1orRmlHWDB4N2U1RXV5K0xB?=
 =?utf-8?B?ZXVUYXJxUVA3Vm5FSUdQbDl3T0UycUlXd3ltN0NUT0F4Qy9rdzlOR0sxZlhy?=
 =?utf-8?B?MTVoNHUrU004K21HNUx2NFRTd2ROMHJ2dFhyR3BGU1daTVJ3R2pwYlhhTWR3?=
 =?utf-8?B?OVdaMDBtRzMrYW0wdG9KME0rRXBSYXRDd2E1VUVBU1hYU0R1MFFaa1NGQjlu?=
 =?utf-8?B?REU3QWdxVGo4b0NmOU1kZDBEVWx1Q1U1TEZ4UGcyK2htY2RCMXVWZm13UXgz?=
 =?utf-8?B?TWtFOWlodnIwYTVCV1ZhT2FzU213aHUxcTlJTFpFQ1JuUDN3T0pTdFcwU0xs?=
 =?utf-8?B?UlU3RFhxSEovK1Y0RDgwT0MxdmVGS1hqNzE0THV4YVB6eWxRM3AwcUUxcmQ1?=
 =?utf-8?B?UG5XeitUMHVaWnpsV21GRDdCY0dnWlhKRWxWZHJHNWNOWXlPdVBKYzhkaXdQ?=
 =?utf-8?B?TEJDRHF4bkhIWXovMkZtUnpDaDZuRFBXTkZDMFB0b2dIb2hLN3hQdXg2N011?=
 =?utf-8?B?cjkrN3M4WkZGS1IrRHlUdXBGMjFaT3RzZktDbjZQMC9GMkZXSDlUTDJrZXVP?=
 =?utf-8?B?ek84Y01XeS9hdytWYkRiNTlpTTRzZXBDM0hpMEJtS2dmMkhqUGViV3ZhZGpC?=
 =?utf-8?B?TjJ3b0ZCM2M0VzJid0tFR3ZDL0xPY3RiRWE3UW5VNmxSNHZCdkF1WHFOdEVC?=
 =?utf-8?B?U1pUNFVBd2lLVHkvSUV0V1lWMzQ1ZjB6STY0b3puWUozQjBWdkRTR2xOKytt?=
 =?utf-8?B?UFpxUTE3eGZVaWNOZUJOU3hETVI3UU82KzM5MFNoWDNjazhCRmRHN25ndXZ3?=
 =?utf-8?B?d1RkbHZ0RmRVMm93WVRYSk1PaEJ0dUozekhiU3Q1RmhBRklDTnphekRqRWVs?=
 =?utf-8?B?M3k2bEg3VlIyU0lDZWlCb05nYUs2TWdmVU9vV0oxODRLNGlUK25HVGxWT3N1?=
 =?utf-8?B?aGR2L0Rsd045THBzSnE5RHV2OHhoQWVGc2dlRHM1WXI5SktjOUp2TUtNL3Jn?=
 =?utf-8?B?MXZud3RaUXJrWkIzeGZFY3Z6VkV4Qm9qRzBpaS9MT3l1OXRkUk5BQ241NlhH?=
 =?utf-8?B?b210aXR4MTBBNFhHaEhLaWp4QnQvYWxldjZRM21HTFVESUxkVG5JNmVENjBU?=
 =?utf-8?B?TFk1bnkwMkZsVU5BeDNoQW1DaGJLNlJEdVB1TUtISDA4NEROZ0xTQkZvTU51?=
 =?utf-8?B?RFA5ZzhzODRnTTc5VHU5L0t5TGppME1tTzBQbXVaVklUanlFdFJwemRCcEcv?=
 =?utf-8?B?YVFpTEF4OFpFc0JzbHduUUVGZnAwdjZqRjBRTUt3MnlDWVlqT3RMZ3NZVWts?=
 =?utf-8?B?dlUxT2lmR2F3RFVXMEcrbTBsYjRUVkRKdHBaWUh6MXJveElHR2lVTzRUZ3lN?=
 =?utf-8?B?Yzhib2V6YkxTUkxuS1pRRFpiaFVZeWp4c3c5c1pVUVM5bGh0R0gzTFA3M21B?=
 =?utf-8?B?UC9KNEJta3NKNjhiaVBtS3FhYnJGOXMyZnFwR1ZPTlE4cFBqSjB2aWQ1Y2E1?=
 =?utf-8?B?aHpFZHVvK3RrK2hwVkxvYlhLbllFRkFXdnhXK2NWNWREV3pFZGN2N0x3QmhJ?=
 =?utf-8?B?cFNVNEhTMitFZWRXRlpGY1NIL2ExeUpIdzkvZS85MFhCSkxJNVdabnJzcGVo?=
 =?utf-8?B?dTYxaHNUL3JBYVY2bXpycmVsbzdyK01ka0ZwWDJ6Y3BIMzlCZ3BsM2ZsNTNl?=
 =?utf-8?B?Zm5ZTGkrelloMVorRE5Uc0N1SzN0aERjTUE2VDZHOWtsd0lRMFVqZE5mU3Z5?=
 =?utf-8?B?SWVUMDhrYVdUbW1wR0w0UVNiM3lwaG9oejNmeGlZYW50VUw5Z29qbWZpaXZn?=
 =?utf-8?B?Yk5ZUkxkRVc5am9jRGs5ZzYzSmNGNlVnM1VBY2RGU3VoQXErVGFRQmtJZDlT?=
 =?utf-8?B?MVE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d1406d52-630c-44db-5cfe-08ddfabb8970
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 16:09:12.9590
 (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: ffuNNXAy9/jvfOkBucHK5oBO/yZYwhsjDb9FzBYEAHR+i6lBw04zhK3AbK56Tf1MhwcG8pkD69O4usSGDwG+22VVRK+RAITN5VyJ5TrDdcI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6912

Hi Mykyta,

Thank a lot for your patches.

On 18.09.25 15:16, Mykyta Poturai wrote:
> This series implements support for CPU hotplug/unplug on Arm. To achieve this,
> several things need to be done:
> 
> 1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented.
> 2. timer and GIC maintenance interrupts switched to static irqactions to remove
> the need for freeing them during release_irq.
> 3. Enabled the build of xen-hptool on Arm.
> 
> Tested on QEMU.
> 
> Mykyta Poturai (4):
>    arm/time: Use static irqaction
>    arm/gic: Use static irqaction
>    arm/sysctl: Implement cpu hotplug ops
>    tools: Allow building xen-hptool without CONFIG_MIGRATE
> 
>   config/arm64.mk                  |  1 +
>   config/x86_32.mk                 |  1 +
>   config/x86_64.mk                 |  1 +
>   tools/libs/guest/Makefile.common |  4 +-
>   tools/misc/Makefile              |  2 +-
>   xen/arch/arm/gic.c               | 10 ++++-
>   xen/arch/arm/sysctl.c            | 67 ++++++++++++++++++++++++++++++++
>   xen/arch/arm/time.c              | 20 ++++++++--
>   8 files changed, 98 insertions(+), 8 deletions(-)
> 

Hence you introducing new feature for ARM I'd very much appreciated if you
add corresponding documentation under docs/hypervisor-guide/arm/.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 16:09:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 16:09:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128560.1468883 (Exim 4.92)
	(envelope-from )
	id 1v15aH-00041A-2L; Tue, 23 Sep 2025 16:09:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128560.1468883; Tue, 23 Sep 2025 16: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 1v15aG-000413-Vk; Tue, 23 Sep 2025 16:09:40 +0000
Received: by outflank-mailman (input) for mailman id 1128560;
 Tue, 23 Sep 2025 16:09: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 1v15aG-0003gK-Hp
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 16:09:40 +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 b1098616-9897-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 18:09:32 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-46b303f755aso29417775e9.1
 for ; Tue, 23 Sep 2025 09:09:32 -0700 (PDT)
Received: from [172.20.5.108] ([50.239.116.157])
 by smtp.gmail.com with ESMTPSA id
 e9e14a558f8ab-42585a701eesm6905255ab.7.2025.09.23.09.09.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 23 Sep 2025 09: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: b1098616-9897-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758643772; x=1759248572; 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=md3OcWKWFoeMzSQmVx17gVX0YatX4wCX8y/G7Y7g2f4=;
        b=VnXAhRGRYJtQyGiZ+CsZXPPNndmsFhLI5gAJjgGfFA0ppqTlimmlP/z2LjRroXJ+SG
         b+qa7sklHT2jzIGHkJwWdJ71348O1gZvr+8cVuiJ3BqNWksRiA/BlAxxHvq8zXQjk6HG
         nvjSHzNVIoA/k87c4z9Df3kK1iTM/0uSlSgpSg0NJRmtPm4XaaknsK/mjJ7RCTjXT85V
         xqlFvwcgeIrLumKeA/tR8BWE4lPqAlAH6OQb7krC0zcQ1ZsDovgwwnx36TjLBU9aLI4A
         BAuR6DMU6TTj+sFd8XgkvW1agJKBWf6pF74q0egaO0v/VxRB4HAJiUYgQ1GsiWaxM075
         IfTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758643772; x=1759248572;
        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=md3OcWKWFoeMzSQmVx17gVX0YatX4wCX8y/G7Y7g2f4=;
        b=H2Dpla3Jl14DmR6myJmQlDgQaHSBkWhoo4eFiZnk6aYm67QdEwuaWfMmKl/oa1jNha
         +KVoY1Fqx+0jNCHdLSIBLPUq2neZIM3ZmS4Y4WkRq/L67e1K4uwDixnD6CawkHqnCP0A
         i0RG2/DsFxFT+NImqnJ15L0RqdbOSgHortMjjnjrZ7kRmSCfUqMwiXgag4eHv4diQH+S
         6hNgSnhnOoRP4lq6reu641otA7CkCM1sjKE4V68OccmO0DPwAcnetoyxyjd1EcjDogZa
         x3/a5m0Mrm6GUE100irnN3upJeShxKPxcyjuLZnZ4xeV4mRGSry8bv7aTanQnKo1kiah
         crtQ==
X-Forwarded-Encrypted: i=1; AJvYcCU6NnZIDrkmo22K5DONPaw+vaExE0W9iwD9QDUsOdfpx29j0frXneB6bqcxrp8F15LYnSBDSGQlRPs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YweelVQHeVwUx7qmnmMR0QXXh5W+SdBH3GWlEKIRUUEF6ctogyP
	wfdMkgalSMWa9BUTCV2piDGViJH4Xjv+0dRMuJ0gGZ2lngIU/PvmfHZzto/YpwOHEQ==
X-Gm-Gg: ASbGncsQgAjHVnoXKWCQ3b8UPdos1EtHN8Hjh1cXoh8t46vtHg7d9wBxn6jxuuneKgD
	S/j3X+M0nip5ANE2CNbQs38WBI+RMn17cjOmx+QCbQk0m9qyeLpMu1TJ3+3zRPW1adRg8cLTVYU
	6LcwbewDwTd6fuh0Arn/f/GUWsx2Qs+5g8i4F/o+PeQ33Dcr0yX1cjiSIq4LFhI85RJdarCploC
	f2uRTHVqNm3cbsBkDj6/jVW7Ac58g7wcJKhslU9nsy00JnxUlsdVvIEezPk9+WKwhBOmUv0FF9U
	M3F5K9HLz/HGpGuS8JbBYerB/yOlkTpfGChkKNm3cKuahVloMAnUjlyLkSzHU7VxNMCrpBxQsa3
	WNHxGP+wgbhKL9dW2DhdsmYzWVaCIRLuY
X-Google-Smtp-Source: AGHT+IEf9YumDmq+JfMP17oEAdNSk7b2T8g3BXcZjNkiik0z2n0utEBoRZoFQ4x84AdWKaSiFXkaJQ==
X-Received: by 2002:a5d:5703:0:b0:3ed:e1d8:bd73 with SMTP id ffacd0b85a97d-405ccbd7134mr2141266f8f.57.1758643772085;
        Tue, 23 Sep 2025 09:09:32 -0700 (PDT)
Message-ID: 
Date: Tue, 23 Sep 2025 18:09:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/7] xen/page_alloc: Add staking a NUMA node claim for
 a domain
To: Bernhard Kaindl 
Cc: Alejandro Vallejo ,
 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 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.09.2025 18:15, Bernhard Kaindl wrote:
> Update domain_set_outstanding_pages() to domain_claim_pages() for
> staking claims for domains on NUMA nodes:
> 
> domain_claim_pages() is a handler for claiming pages, where its former
> name suggested that it just sets the domain's outstanding claims.
> 
> Actually, three different code locations do perform just this task:
> 
> Fix this using a helper to avoid repeating yourself (an anti-pattern)
> for just only updating the domain's outstanding pages is added as well:
> 
> It removes the need to repeat the same sequence of operations at three
> diffent places and helps to have a single location for adding multi-node
> claims. It also makes the code much shorter and easier to follow.
> 
> Fix the meaning of the claims argument of domain_claim_pages()
> for NUMA-node claims:
> 
> - For NUMA-node claims, we need to claim defined amounts of memory
>   on different NUMA nodes. Previously, the argument was a "reservation"
>   and the claim was made on the difference between d->tot_pages and
>   the reservations. Of course, the argument needed to be > d->tot_pages.
> 
>   This interacs badly with NUMA claims:
>   NUMA node claims are not related to potentially already allocated
>   memory and reducing the claim by already allocated memory would
>   not work in case d->tot_pages already has some amount of pages.
> 
> - Fix this by simply claiming the given amount of pages.
> 
> - Update the legacy caller of domain_claim_pages() accordingly by
>   moving the reduction of the claim by d->tot_pages to it:
> 
>   No change for the users of the legacy hypercall, and a usable
>   interface for staking NUMA claims.
> 
> Signed-off-by: Bernhard Kaindl 
> Signed-off-by: Alejandro Vallejo 

This looks the wrong way round, and then I expect a From: is also missing.

> ---
> Changes in v3:
> 
> - Renamed domain_set_outstanding_pages() and add check from review.
> - Reorganized v3, v4 and v5 as per review to avoid non-functional
>   changes:

What's v3, v4, and v5 here (when we're only at v3)?

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1682,7 +1682,20 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          rc = xsm_claim_pages(XSM_PRIV, d);
>  
>          if ( !rc )
> -            rc = domain_set_outstanding_pages(d, reservation.nr_extents);
> +        {
> +            unsigned long new_claim = reservation.nr_extents;
> +
> +            /*
> +             * For backwards compatibility, keep the meaning of nr_extents:
> +             * it is the target number of pages for the domain.
> +             * In case memory for the domain was allocated before, we must
> +             * substract the already allocated pages from the reservation.
> +             */
> +            if ( new_claim )
> +                new_claim -= domain_tot_pages(d);

This is now racy (and hence a functional change): Without holding the heap
lock, a domain's total pages can change behind you back.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -492,6 +492,30 @@ DEFINE_PER_NODE(unsigned long, avail_pages);
>  
>  static DEFINE_SPINLOCK(heap_lock);
>  static long outstanding_claims; /* total outstanding claims by all domains */
> +DECLARE_PER_NODE(long, outstanding_claims);
> +DEFINE_PER_NODE(long, outstanding_claims);

See comment on the earlier patch.

> +#define domain_has_node_claim(d) (d->claim_node != NUMA_NO_NODE)
> +
> +static inline bool insufficient_memory(unsigned long request, nodeid_t node)

Except in special cases, no inline please for static functions in .c files.

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -405,6 +405,7 @@ struct domain
>      unsigned int     outstanding_pages; /* pages claimed but not possessed */
>      unsigned int     max_pages;         /* maximum value for domain_tot_pages() */
>      unsigned int     extra_pages;       /* pages not included in domain_tot_pages() */
> +    nodeid_t         claim_node;        /* NUMA_NO_NODE for host-wide claims */

I don't quite understand the purpose of this field: It looks to be a
hidden parameter to domain_adjust_outstanding_claim(), yet then why isn't
is a real one?

As I'm also having a hard time following the description, I fear I have to
stay away from making further comments (on the main part of the code
changes), until I understand better what's (intended to be) going on here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 16:47:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 16:47:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128585.1468893 (Exim 4.92)
	(envelope-from )
	id 1v16Ai-0001Ce-T8; Tue, 23 Sep 2025 16:47:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128585.1468893; Tue, 23 Sep 2025 16: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 1v16Ai-0001CX-Q2; Tue, 23 Sep 2025 16:47:20 +0000
Received: by outflank-mailman (input) for mailman id 1128585;
 Tue, 23 Sep 2025 16:47: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 1v16Ah-0001CR-7S
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 16:47:19 +0000
Received: from BYAPR05CU005.outbound.protection.outlook.com
 (mail-westusazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c000::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f595345e-989c-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 18:47:17 +0200 (CEST)
Received: from BYAPR06CA0058.namprd06.prod.outlook.com (2603:10b6:a03:14b::35)
 by SJ1PR12MB6099.namprd12.prod.outlook.com (2603:10b6:a03:45e::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 16:47:08 +0000
Received: from CO1PEPF000044F4.namprd05.prod.outlook.com
 (2603:10b6:a03:14b:cafe::ab) by BYAPR06CA0058.outlook.office365.com
 (2603:10b6:a03:14b::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Tue,
 23 Sep 2025 16:47:08 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CO1PEPF000044F4.mail.protection.outlook.com (10.167.241.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Tue, 23 Sep 2025 16:47:08 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 23 Sep
 2025 09:47:02 -0700
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 23 Sep
 2025 09:47:02 -0700
Received: from [172.20.229.150] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Tue, 23 Sep 2025 09:47:00 -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: f595345e-989c-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rwsrvIxavi2kwdodbPVo1N2iGMqK3f8+sRw1Gu6KyGFs2MMZRE1TOIhxk20HZ6w+owOQYJ7RyCgZc4K70odLXBWY4LyJLSBz2UR197XOON6zFOXzpA9/3OrJJ/Qkiw3F1E4CsbXfgumQiD00Md46Y7DrzmnsH55TaZfc/9ivUumbEueVxyXC6jgr5TTJVoqabNgdEH5xBms2qJE3CFgL5uuVgtHua2CUC1TBqJ3w6Rm8ZOMSZeOSGyBgUDFrKwiKRimoD0bEVNfdZ3rV6ZoIU5W5AGCKH0eoZ6WKBs4Or/xxLaKANDA1m2yFOJGQ2gnRQiD3fDH8FPHu7WiDdZ0nlw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=etSRuqcxug86BJLSlFeargc1Q+LCaWnLDyhcA0MdyGg=;
 b=KdEEYzGe4ysoIGrprFPW981icbzWsOl+mo4lWcetunztIvgw0R3h/ioGeJFokhnsNRSulYaEMbbQMXQqGDw+3LjC1jwEpJdNai8Ssjhx7RTM2AHLAieMHCrKJrcsq6cGRC8eKKR+S7SWzKZQjD5chv81cIsTtXP7LiBqkSYr1Dk131ZPuCugo5iyM3cxWUbcNhvfVDLC6g7mYMwdjf0uepwWGHlWVq1ddHGdIjKTL7gXwcYVMw0lfF63SD5wfL22ZWlPASjnR7uTUaADsYFlBUBlDCQJvYDuxjf2N127zP/csuXAJwEffbY/hFUGEr3m57S288R1EtRCEqFn6sSUBA==
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=etSRuqcxug86BJLSlFeargc1Q+LCaWnLDyhcA0MdyGg=;
 b=rbnN7jXY2NGKW+BAAgn9ilAvneBym3CZUl42joyM9AR7P76WYVCvH/3RO7MASh6oCGmGq1QcdFWlvNdR2yNNBwMTn9ywd6N4f0qSrJZ/nabKv8bAYPTcvu7gsqaxIyuK6Fmh5wcMADKHUMbpJMtORiLj1jsHiOl2o9jl263lhyw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <1106c080-508b-4328-a636-900ca8377d2d@amd.com>
Date: Tue, 23 Sep 2025 12:47:00 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Jan Beulich , Penny Zheng 
CC: , Anthony PERARD , "Andrew
 Cooper" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, 
References: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-8-Penny.Zheng@amd.com>
 <5a2e887f-d6da-42e2-aff0-efe55b041749@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <5a2e887f-d6da-42e2-aff0-efe55b041749@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: CO1PEPF000044F4:EE_|SJ1PR12MB6099:EE_
X-MS-Office365-Filtering-Correlation-Id: 385f10d3-4dde-494d-33d4-08ddfac0d606
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?SklZMGFrUTdJbmp3STBTclYrMnNnajVQbFg3L1JvcW9FWXM0aCtjVmNmWGlR?=
 =?utf-8?B?MFVJakU5M3Q3dkZMY1dPZTBtVG8vQmlBSTBUUHlUT05xSHVLZDJ4SlNRNGpC?=
 =?utf-8?B?SFlmNzBPbU9ramNDLzFYTWh1TnFwSzV5ZDR6R3pDbGUwTStXYjJNcis5K1RJ?=
 =?utf-8?B?clMyNjJCLzBDaUVyeWFQM2t0TUJSZlFhZzg1dW5lUW10M3NBdTNEdmRzL0ZL?=
 =?utf-8?B?SnZpaDZXQU4vb3YvVTRQSDE3YUdQNC9BTVJVTmNkc3RzWnhJNjRTWUgyOU9t?=
 =?utf-8?B?WEdnVjg2eTRJWlh0bnpiV2JwZmVDNFgyZyt6eDRLZGN6c01sTVc2aFJ2dENF?=
 =?utf-8?B?LzNLVmZENjVTM1NpbHA2RU1lTlpPb1J1UnNHZ3hnT2RiczdBR1dLNEdMQTUv?=
 =?utf-8?B?UCs1Um1tRHhQOUlJUkRiVFV0cEl1VTljSWwyZU5tTzVxV2M4Rkp6L2VEcHFX?=
 =?utf-8?B?bXBNb3NtK2k5YXovbmdDdThLRmhORTRNNWFjdWpuR1Z1S3UrNXVOTXp5M0NW?=
 =?utf-8?B?UnVXcDBYbTFGTWpEMGRFZFhxWk9FRnh3SjNBMFFmVFNtSHJ3U1hrdmwvamM3?=
 =?utf-8?B?MStqZ0F3RlBFRlpyL0tYTjNQMXNsWmU2K2lBQTNacFNBTG5WOFl1K2ZCQmVG?=
 =?utf-8?B?TGtVZ2lON0VHRjVaVldSWnVzMTJ4MFdOdVBaQ3UvQy8wR3laOVB1REEvZXNO?=
 =?utf-8?B?Sm5aYWJNeXpBNUxmbXhDb1BaWGxMMDYzWWR4VkFpN1p0T05GbUhrQi9JZ3J5?=
 =?utf-8?B?UWlHMWNJcUc4NFVqSjJpTm1zb01tQWhOUjJMT2l6aEZxWkl1N1RkdU1BcElV?=
 =?utf-8?B?UFo4eDZoSlpWcENPaXUzZXNLWk00U2prNkcrVHRUSW0zUDhsZUxobXU0aENT?=
 =?utf-8?B?RUl4REZLb20vT2Z0R2NTK0JLditRVm9lZFd5Z3lhTTFneGNDTmZtd2NkUnBS?=
 =?utf-8?B?WStKMHMvNnFGMnBLeE9DR2xGNGxVVW85TU03WUhIUWhqSFBVakk4bm1ob2hX?=
 =?utf-8?B?aEVrdFB2T3JZbWMrV2VwWUhrd3JOVWdvMEp2aGgybDV2Z2Y4eUk4bHhrdDlF?=
 =?utf-8?B?ZTA1c2NORDJpUyttb1RzTmtCTjVaZ0JZV0t0YjlEcTdvdjRtQjVYWXdSMU9U?=
 =?utf-8?B?bjhBSEVJbU9jZGhUTjhwZW92cGFFd2FoMmFpQnlVZ0d3S004ZkdBNktaVXpY?=
 =?utf-8?B?OVdyQ2t5K2pzOEoxcU9HY21MTXFmcTdmQlRHaUk5VkVITEpXeHpXa1kxaDVZ?=
 =?utf-8?B?RHpQc2NLN2dwcTFMcFZUYmRWSS85L3lrWUI2RUw3bHZwOGpZOXAxTWFNc2N5?=
 =?utf-8?B?bUhhbS9wWStPZzYrbGRTR0U0alRwZjNrR3JRemcxVzNGYnUvYkJVZ3gxV0th?=
 =?utf-8?B?OVpjODRSZzJPbkZZR1pwWHRzZU1NWEtTSjJ1WGY5UHhxSTNRNnVTUmdQT3FE?=
 =?utf-8?B?WHdpMWQyVytXb2w1MU1QTjVoWm9iSzRLQ0c1WEZiSkpnOVZHSVRJV0ZXZ2pz?=
 =?utf-8?B?OWFZaTdiOStWdmlwelNuazNkOVprZzg3WDRhNGl2TmtjNVpUbXlLcHZ1WGFW?=
 =?utf-8?B?MnltN2IzbVVTb3pSMFVCUlBwN3liRmt0QktBTkVUZ0xCdGMxc2xWZmt4VmxB?=
 =?utf-8?B?US94Y0s3cGFLZ084WCtwNGJuYjdjdHphZlBkT3BSdVFyQ05OSVdMZ0IzM0x2?=
 =?utf-8?B?NmxTTEZTMjBPcHFHdmdzaE5veWs2TEVNZFA1ZlBGbTZIb1VzVU9zbXBZT2Fl?=
 =?utf-8?B?SThSTkR6bEwzckJJcFZUdzUwYm1OSG45VmZqejBkMllHSTJHUVdZTGZCSWNX?=
 =?utf-8?B?M0RkZUlhMU1MUGxWZ1Y5Qm1mb1hqNUNEVHJVQkdkQU1WK0czSGlPNXZjSUth?=
 =?utf-8?B?WUhuQkNJdnMxMHNsN2lkdXQxU3o5YS9nSXYxNUNtaWxyZUl1Nkx4MVdidEJ0?=
 =?utf-8?B?SFdGT1BkbnVSTXNKckZZZlU4aFRkRFcyU1puQ1p4NXBvbmliN3gzZ1ZoN283?=
 =?utf-8?B?MDR6Mzc3ZWIraXVaWXFTRmh1R0ovRThaOUxsb0ZQVGRGMVZoV2ZORTJROWFL?=
 =?utf-8?Q?grxVQF?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 23 Sep 2025 16:47:08.6525
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 385f10d3-4dde-494d-33d4-08ddfac0d606
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000044F4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6099

On 2025-09-23 11:38, Jan Beulich wrote:
> On 23.09.2025 06:38, Penny Zheng wrote:
>> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>>       else
>>           strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
>>   
>> +    /*
>> +     * In CPPC active mode, we are borrowing governor field to indicate
>> +     * policy info.
>> +     */
>> +    if ( policy->governor->name[0] )
> 
> amd_cppc_prepare_policy() may leave ->governor set to NULL afaics, so I
> think you need to add a NULL check here alongside with pulling this out
> of ...
> 
>> +        strlcpy(op->u.get_para.s.scaling_governor,
>> +                policy->governor->name, CPUFREQ_NAME_LEN);
>> +    else
>> +        strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
>> +                CPUFREQ_NAME_LEN);
>> +
>>       if ( !cpufreq_is_governorless(op->cpuid) )
>>       {
> 
> ... this conditional.
> 
> The description also continues to not mention the effect for HWP. I'm
> actually somewhat confused, I suppose (Jason, question mainly to you):
> HWP falls in the governor-less category, iirc. Yet it doesn't supply
> a .setpolicy hook, hence __cpufreq_set_policy() goes through the normal
> governor setting logic. What's the deal here? The answer may affect
> whether I'd deem the pulling out of the conditional correct (or at least
> benign) here as to HWP.

Hi,

When I wrote HWP, I didn't realize using .setpolicy would bypass the 
governor code.  Instead, I implemented the no-op HWP governor, since I 
thought I needed something as a governor.

set_hwp_para() actually changes the configuration.  HWP only implements 
the equivalent of amd-cppc-epp autonomous (active) mode.

So I think HWP could switch to .setpolicy and drop its governor.

But looking at this hunk:

 > @@ -321,10 +327,12 @@ static int set_cpufreq_cppc(struct
 > xen_sysctl_pm_op *op)
 >      if ( !policy || !policy->governor )

Doesn't this !policy->governor prevent amd-cppc-epp from setting 
parameters?

 >          return -ENOENT;
 >
 > -    if ( !hwp_active() )
 > -        return -EOPNOTSUPP;
 > +    if ( hwp_active() )
 > +        return set_hwp_para(policy, &op->u.set_cppc);
 > +    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
 > +        return amd_cppc_set_para(policy, &op->u.set_cppc);
 >
 > -    return set_hwp_para(policy, &op->u.set_cppc);
 > +    return -EOPNOTSUPP;
 >  }

So there may be other checks that would need dropping or adjusting to 
support HWP without a governor.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 17:09:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 17:09:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128599.1468903 (Exim 4.92)
	(envelope-from )
	id 1v16WV-00046m-Hw; Tue, 23 Sep 2025 17:09:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128599.1468903; Tue, 23 Sep 2025 17:09: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 1v16WV-00046f-Es; Tue, 23 Sep 2025 17:09:51 +0000
Received: by outflank-mailman (input) for mailman id 1128599;
 Tue, 23 Sep 2025 17:09: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 1v16WT-00046Z-NK
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 17:09:49 +0000
Received: from PH7PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170100009.outbound.protection.outlook.com
 [2a01:111:f403:c107::9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ac56e5b-98a0-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 19:09:47 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 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.9137.14; Tue, 23 Sep
 2025 17:09:39 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 17:09: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: 1ac56e5b-98a0-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oWXggwVgG5+rl5z3SotJHQW1m4VjyXkt4rjniHHR2g+2Y3BHmjdoAqeVdP8k6mFe4IPb7kV+kge+ua1wSDvFL/quwLj4xhgtg8qlTIIUhCND6ACY1ARSrSYQ1pBHaSOpuwWRUe4OCI33oN+aektYyfNGfWTTlHi5lIwPl+an8UXKbN+hNUXK9Al/EyVpsysGtHD3vdUrEgNt1EMA7AVtqQwfJvPDoxL69kJrBOAbNaM3P//k0fFCX16uKv5cS6gw5sNS6VeWBk1hZgy5h50/yWGLyF4jP1+0rbw5DoPWdZbzD2HEXux/VkFJmyXHmptrQF3nI2FE+1vg30x+4Ui66g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zfBJt5ORyJeWyTmriSi9rxIRbYwbq9D6z6afL/pAXS8=;
 b=c4pMUCw0BfP/FSxTb+iJvOpFnhv2VZ5tk4N0rFUs3VE5JxKA+/LCYfsgEscOPhkcBmn8mnqWcvQBR8ozQh3kBNvhm/k8t/iXX0N3X3MAB7NL+3A7G+2SRwEnBiw9tNhNJ++RJMXlSFhasUB3UKspQrLRpqDBn809urbmvdRpCe8BQtw+rAQ3B6qSQMHUcXgjB97FDu8Z8M/QGUR/kkKu8BrcsyDg+z1FjySil2bvtHYp5VbPFYh3DrMT5KLkFnOVJE3g2Z9jrRPkrKYpnxDMu5ap+AsWNINW9UHaB4ftMQ/b789+skrb0bomTQOX2Z14ErVFPJGj3bG6xxi2XV3jKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zfBJt5ORyJeWyTmriSi9rxIRbYwbq9D6z6afL/pAXS8=;
 b=Clve4RHOxCmnuRZI1E6kaQWOMfhYl/gXKCQEkQ5MRl2kUIrjhbIR4RSReFQ4rSuBhHkpAhanzX9NW2skuKFHEmfVa54Dw9rU1UpMbeRRdeCaTVsqubTq5izKSmZ2udMsGlUy976lrNdGvdmcewLGFwRbyDxCvRPRoebjb0xsVLmuoCx7xSrUXpYQ2q6w72pNlFOj9SpzTionNFu8B24ImUw3Ndcfg55P7wKftC1gE6vXBr7HTN7jnMw935VCoF1V33cShDJxWK0rx+upcHZ3CsEhvN/LdNaaegoduC2dMaXY5bYkNtV4+9iHn88R4gzIty8gy1HBx5HgdWMNwtZsXg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Tue, 23 Sep 2025 14:09:36 -0300
From: Jason Gunthorpe 
To: Keith Busch 
Cc: Leon Romanovsky ,
	Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250923170936.GA2614310@nvidia.com>
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
 
 <20250920155352.GH10800@unreal>
 
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-ClientProxiedBy: BL0PR0102CA0062.prod.exchangelabs.com
 (2603:10b6:208:25::39) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|CY8PR12MB7097:EE_
X-MS-Office365-Filtering-Correlation-Id: bc204952-1979-427d-43f4-08ddfac3faa1
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:
	=?us-ascii?Q?SJmAD6P8WrWWuHZOaif2sELSogZjML3CSOMNpyLWiBOtInZlQ+z3+HEwPek+?=
 =?us-ascii?Q?xMrD+nXnpvB6+wyNA1MiGP7PUnMUXGOAo3Uji+JoeKTFjjpa2Wi8Tbdyy306?=
 =?us-ascii?Q?lwMaY9apU4XbSh6ZMNDCYILAWKLg9xO1o0WaQX8X0t8PvWqGVI05dXYUfaJS?=
 =?us-ascii?Q?dP23xF90g3yxrMg3E0ZweazGKCUtcpUk0BvZseMZ9Mn3ZEYPDC6SUqNTPyT5?=
 =?us-ascii?Q?h9T0/JdzXqp5RVHFb0bCnTeE1SrhMbi0i6Rwq9D+7fSAiRtjgDGvD08j6Dh4?=
 =?us-ascii?Q?9zDSElycQTqtC+SxuEXwPTeBP5j6mXPlytrpc/8I54CGMdxY0OT/iG0EKH+k?=
 =?us-ascii?Q?fKXK1lmN2YB3l8NfwJKB3i6Bz1OJ+8wsnPpvf5DTWI6QOizZNh1dlKcg9Ons?=
 =?us-ascii?Q?TwWJMjyGVaKnEc2KUnRHPRc9MXBxGdU2tpcoHFFMsv9ME5toHcHyY+5fBPyE?=
 =?us-ascii?Q?3Lb1wA0tfhFmNLq9dByW3S/Z+OHToqipzWlBOL6llXnYqFA+YekgTSmj5THl?=
 =?us-ascii?Q?IUevUbBBCkjpZQxFLPv0NEJI2jBOhEfviO8nRNoLyQPmgl2v4GXdiHmnd5B0?=
 =?us-ascii?Q?qgOqPkxSpeWRVpwdlX+vRBOY8V8aTOnh+PZoebudEvEnynv7uqK6MA0Pr1F4?=
 =?us-ascii?Q?+TlSLo1HaMFQ+fiKgoBluBBPW4Er7lSbish+pOk2mGuC9aJf+Flh7VdsNF6A?=
 =?us-ascii?Q?UBkhE3SDC/eCbRcZtuyp5GvG8SnptVS3yn2DsSwwLQpvFtNh5A2kh4ZNKih5?=
 =?us-ascii?Q?QE5ni5X10wtQk9Lj7T3AchwuQtLJwd4rBA7qvGl2P71YUZWb2LPuBW0/72Ko?=
 =?us-ascii?Q?HO0ZQDsdrG8umM0sZrIhMKAFizButughBB28ZD1cnb+YnbeglqerRHRo9O8o?=
 =?us-ascii?Q?1tTH5/UldaE30aM/XBB3HqZ6cRzzPdXjNJQwa2kWysbdYBzArHi4lJOq6uT+?=
 =?us-ascii?Q?mZxfrv0YS27avYVToN6qcOyuSpCKxEBWrDJacnMkhhw+w06PXPIWOVgcLgod?=
 =?us-ascii?Q?pRGBSZmi4gYf6GWVOypTrxrQ0KtcbuO8KCcCkSjevTbrbQp5gUbkFJW/lEoY?=
 =?us-ascii?Q?zELONf86F3MT5VsZE9116D1a+e6lzmJCL9whVQqkV5sdp1irFJ+ropB9qI/k?=
 =?us-ascii?Q?gGCmG061yMAzLvZxz6tc7q3/3RWpV+zHLlQxPe1v04t0wauH76R68fyv9HNn?=
 =?us-ascii?Q?zn9NF6ZRGRZ5r/qNo2Uw/19OKlKFBpbeXLMMvKu5NQTSsADFKP7IT7jD76xH?=
 =?us-ascii?Q?mn/fba6qnsgXbTXfsL0KdhGksYcRoJxVvi8p2TUhJ41p79ubs5tNZJcXm0IY?=
 =?us-ascii?Q?Nd/QX/TgbDELc27Fsek28z6L76ISG+5VrCn+LPiDjw7PEuA4X6IpJ76tIYcL?=
 =?us-ascii?Q?6ccVwWP77+YQSyB29uu+HetpBBRd/bjPUMECjnJO/TWb3cSYEl3+bHX392Dy?=
 =?us-ascii?Q?2VgYRkJLZZo=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.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:
	=?us-ascii?Q?9brSa+bdlvi/6eftqG0wEDppljbQgJEznYpb1kQH86dDICWbUMxtWiwK0/X7?=
 =?us-ascii?Q?4rEWjqAc1kRsokCGBoz/oQbnANRsFgz673fviV3zWc3btFSRfD9I/XSh4cqp?=
 =?us-ascii?Q?Q+Q+8h58Gm0cfSghyhxjy0uUK1l4e4fzZLwD04xX2uZPZxg3rHzASRTDh+us?=
 =?us-ascii?Q?qgCFEDJR1PuMoPABTM36UOjJ6ub0/RXqf1Q10EItpXz66f9Eqppjjk/LCCMf?=
 =?us-ascii?Q?49LiQkJ7Jeo39RkV8AIR7CtfJoLZrdV3MdmykRQ57YzURLJzvykAbUMGKRFx?=
 =?us-ascii?Q?OQFm3ar9RMXa+/T8WxRzXgwMvRW/YW7wivCv74tpewW3AhCRCEu+wj3SOSB+?=
 =?us-ascii?Q?4RlQ9MjNbsW7Jl9giTy6DXl4x6Fu9qIX6oRShn8Uilv+pRN/ry8KE3UcA+Wn?=
 =?us-ascii?Q?ULvpHSCX1TyG+D3TBfE5QuTqlCG3isyhf2JNFtZpdroPhK0r/PANzfcv3BWG?=
 =?us-ascii?Q?5+EH4FUjAbQPDabCUvlrG6EzUYfox05xMC6bLMoreyRPS7Ojy2mp1v2pIg7j?=
 =?us-ascii?Q?7c1YIEg/truGG6QwtrwM4sI/9Vf+vz4UxPJNkExIvW4XDBa07XUdpPIfdPwD?=
 =?us-ascii?Q?wx9RpRN+d13xiSLdQIFkuqZII6bHusCMmTb9E4narF0h5L/oEgpOqxsBcHBg?=
 =?us-ascii?Q?ewdVKMLIBuo4fNrUkHkFKGzyKxveEUg9bW8w2PUI6njWI+DQIkg5J+YF38uK?=
 =?us-ascii?Q?Ew1CW/yzGdWCvjC7hpcT8Ks7ALN72NOBDVhNCOMPtfuQ00fdyYU/ImkkcDCa?=
 =?us-ascii?Q?OgXhBxMQtCnHPN/94sn7nXKb42TanX5SvZSuubFyUn9YK/MPNCkdbSd2cvPd?=
 =?us-ascii?Q?O+eiBurynvlcVjvyQvC6tIMszTe9kXiIDrHL6h2TvytWCOgZyCSBQYmy8HjZ?=
 =?us-ascii?Q?AJE8h0BeCiD4GxdgQU0B9kVCJ7SRRuaVeWcG/byzaTRliSgzwspmNszSU7vI?=
 =?us-ascii?Q?w1zJZCrHgFDVq5KyG3ask7NK2W0l6gI+hQBLGORGHW4LJCSId4OVNZlD53px?=
 =?us-ascii?Q?qw+5w0iybqAX5cb/BcIO3BvJd+6Dvl9TTQXENrWmNE4hrPzOz3r/cCf6XjLK?=
 =?us-ascii?Q?MOa7ZLp/kRBF0xUqB0hEEAt7uVdrDwUHTBraQMBLZdDZS6Yh5Wmnam1J2ZZu?=
 =?us-ascii?Q?gL5lGS0Sa8F7GW+ZQWERfs/8h3BinfAAwALQr+XognophwGG/PoHnulu55wn?=
 =?us-ascii?Q?N6N61LxtGOTnozw9ccWDX9sp7X/5ZZUgMTNqDe5HPkkzf8E+TRIWQaSqsUMZ?=
 =?us-ascii?Q?h7hVC2StbNxHjI6L/97Q4lxxwCOl59nYpHes7gqUxhZIKkFj1NJ/QML71bGJ?=
 =?us-ascii?Q?SRBra1y1gGCD6HM4rDZdFiWixSvuP/Zl8olGEJUgiYR0LZo7l2+3qJ0DENnC?=
 =?us-ascii?Q?5qugSmfjHJFJVySpdCgDiGx7H/u147UlCRCnLlNsX1sBgdSO5fMLmg1bj1M1?=
 =?us-ascii?Q?8KkyHbCIbZvB+TBvJjr+HZZoL9DomFAIc8tlOZAIx2zdP7zX2hvfN/h9EOpe?=
 =?us-ascii?Q?dRp/8lGy1sAFgNZzIblQrUHChTBvYY7FFJUihHYLu0AQAC7CntY0Dde2YTGz?=
 =?us-ascii?Q?SOVUD2AqRajEjF69PyqwB/dZIVBwUeZ/PoDq/A15?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bc204952-1979-427d-43f4-08ddfac3faa1
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 17:09:39.1137
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ceigpDcxetN7qTmDdR6xf/u6VfAhbxjc3VgXcalLxLEkjfvE0x+7MsjxHGl5BBWd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7097

On Sat, Sep 20, 2025 at 06:47:27PM -0600, Keith Busch wrote:
> On Sat, Sep 20, 2025 at 06:53:52PM +0300, Leon Romanovsky wrote:
> > On Fri, Sep 19, 2025 at 10:08:21AM -0600, Keith Busch wrote:
> > > On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote:
> > > > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote:
> > > > > >
> > > > > > This series does the core code and modern flows. A followup series
> > > > > > will give the same treatment to the legacy dma_ops implementation.
> > > > > 
> > > > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it 
> > > > > works fine in linux-next.
> > > > 
> > > > Thanks a lot.
> > > 
> > > Just fyi, when dma debug is enabled, we're seeing this new warning
> > > below. I have not had a chance to look into it yet, so I'm just
> > > reporting the observation.
> > 
> > Did you apply all patches or only Marek's branch?
> > I don't get this warning when I run my NVMe tests on current dmabuf-vfio branch.
> 
> This was the snapshot of linux-next from the 20250918 tag. It doesn't
> have the full patchset applied.
> 
> One other thing to note, this was runing on arm64 platform using smmu
> configured with 64k pages. If your iommu granule is 4k instead, we
> wouldn't use the blk_dma_map_direct path.

I spent some time looking to see if I could guess what this is and
came up empty. It seems most likely we are leaking a dma mapping
tracking somehow? The DMA API side is pretty simple here though..

Not sure the 64k/4k itself is a cause, but triggering the non-iova
flow is probably the issue.

Can you check the output of this debugfs:

/*
 * Dump mappings entries on user space via debugfs
 */
static int dump_show(struct seq_file *seq, void *v)

? If the system is idle and it has lots of entries that is probably
confirmation of the theory.

Jason


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 17:18:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 17:18:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128612.1468912 (Exim 4.92)
	(envelope-from )
	id 1v16er-0005jq-Ab; Tue, 23 Sep 2025 17:18:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128612.1468912; Tue, 23 Sep 2025 17:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v16er-0005jj-87; Tue, 23 Sep 2025 17:18:29 +0000
Received: by outflank-mailman (input) for mailman id 1128612;
 Tue, 23 Sep 2025 17:18:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v16ep-0005ja-UK
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 17:18:27 +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 4fc291af-98a1-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 19:18: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 4D74B447D6;
 Tue, 23 Sep 2025 17:18:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76194C4CEF5;
 Tue, 23 Sep 2025 17:18: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: 4fc291af-98a1-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758647903;
	bh=1ANX/1Q+c1YQm6ycMdbCkLhJt5M0dGUVsHIE7DPPmR4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=g5Jqi9yueMAnnH73toGC0xOJKxvg0qa4gga/SeRhYNDlfhLJMDwAYoyYF5OeZMllT
	 4wGYFwIT9tNhvxI7Fwmxeam4DFzzKoOpEvYF6KzT3sugNB9IZN5QFtnFbWNJKdyahQ
	 njhRkpS4V2fDEMCIbaKPb5Fvro/sH2PrgzN3QArdRquI6/hD8MqkvT+BpL3TaOekdf
	 ivzyZBCGcNieZxwvItwvCdr8sC9432gSLRdJ+Qt9NVztv9FJs9EoyOLvflbrcT7TLo
	 fCDKOXnJOo3pz8pFrFpZX02l/lSsNuJ1YSx2nfsXC1cIkAfhePf3pibh9dO8eHGKV8
	 GZaMzjVv7a/9Q==
Date: Tue, 23 Sep 2025 20:18:19 +0300
From: Leon Romanovsky 
To: Magnus Lindholm 
Cc: Marek Szyprowski ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical
 address
Message-ID: <20250923171819.GM10800@unreal>
References: 
 <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Sep 22, 2025 at 11:04:06PM +0200, Magnus Lindholm wrote:
> On Thu, Sep 18, 2025 at 8:45 PM Leon Romanovsky  wrote:
> >
> > From: Leon Romanovsky 
> >
> > Alpha doesn't need struct *page and can perform mapping based on
> > physical addresses. So convert it to implement new .map_phys callback.
> 
> 
> Hi,
> 
> SInce this patch affects the Alpha platform I got curious and decided to
> try it out. The patch series requires some preparatory patches. Leon
> provided me with links to his dmabuf-vfio branch, which had the
> patches (and some prerequisite stuff) applied already.
> 
> Based on the dmabuf-vfio branch,  I've built a kernel and tested it on
> my ES40 Alphaserver, the kernel booted fine but after a while of
> moderate filesystem load I started seeing some ext3/4 related error
> messages in the system logs. Rebooting with my old kernel into
> single user mode, I was able to recover the filesystem using fsck.
> Clearly this set of patches breaks things (at least on Alpha).

I will try to setup Alpha architecture in QEMU in following days, but
would like to ask first. Did you test alpha on clean v6.17-rc5 (without
my patches) as a reference?

Thanks


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 18:31:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 18:31:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128630.1468923 (Exim 4.92)
	(envelope-from )
	id 1v17nI-0006gx-Ae; Tue, 23 Sep 2025 18:31:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128630.1468923; Tue, 23 Sep 2025 18: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 1v17nI-0006gq-7n; Tue, 23 Sep 2025 18:31:16 +0000
Received: by outflank-mailman (input) for mailman id 1128630;
 Tue, 23 Sep 2025 18:31:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v17nH-0006gk-6K
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 18:31:15 +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 742fed62-98ab-11f0-9d14-b5c5bf9af7f9;
 Tue, 23 Sep 2025 20:31:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 6BC3A4393E;
 Tue, 23 Sep 2025 18:30:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB030C4CEF5;
 Tue, 23 Sep 2025 18:30: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: 742fed62-98ab-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758652259;
	bh=gxKH7wZVbZJUgsdcRmV6yXRnCWQ9TqZ9bpedLe1yt7s=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=S4ZXIaWM41Ablw/mVVeAaJkiSYgUA1XjiTWt5LSH4qwLIacOxMZE3jScnz0xix1Wv
	 SAp5BLuT2R2dCAYXxRdOCtJez17N/cBe9kv8+xOmcpzYoZ/UpcFkDX5GmNuOLJGCFV
	 Bcs4RLVyhjVQyFhRGAbe1bDHxUFJbKgGu/3vW1Mt1BkujhZ/XZn25PIvUn5jT3S9nw
	 YVX4n2lhWFpC/hhBuXD/s3h9/tXRxQArUIgc5V0sUKhDNiOC8ABgtjM7Q3+LQGe+ys
	 cSfhtq2Jd52bcQy4LLrP2uqO++/e9zs0F7UgxrbinfFgheCfADXwZVzyKQ2yU+i53A
	 XGP2nnt2Bp5Ig==
Date: Tue, 23 Sep 2025 12:30:55 -0600
From: Keith Busch 
To: Jason Gunthorpe 
Cc: Leon Romanovsky ,
	Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: 
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
 
 <20250920155352.GH10800@unreal>
 
 <20250923170936.GA2614310@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250923170936.GA2614310@nvidia.com>

On Tue, Sep 23, 2025 at 02:09:36PM -0300, Jason Gunthorpe wrote:
> On Sat, Sep 20, 2025 at 06:47:27PM -0600, Keith Busch wrote:
> > 
> > One other thing to note, this was runing on arm64 platform using smmu
> > configured with 64k pages. If your iommu granule is 4k instead, we
> > wouldn't use the blk_dma_map_direct path.
> 
> I spent some time looking to see if I could guess what this is and
> came up empty. It seems most likely we are leaking a dma mapping
> tracking somehow? The DMA API side is pretty simple here though..

Yeah, nothing stood out to me here either.
 
> Not sure the 64k/4k itself is a cause, but triggering the non-iova
> flow is probably the issue.
> 
> Can you check the output of this debugfs:

I don't have a system in this state at the moment, so we checked
previous logs on machines running older kernels. It's extermely
uncommon, but this error was happening prior to this series, so I don't
think this introduced any new problem here. I'll keeping looking, but I
don't think we'll make much progress if I can't find a more reliable
reproducer.

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 18:38:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 18:38:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128647.1468933 (Exim 4.92)
	(envelope-from )
	id 1v17uF-0007Sy-51; Tue, 23 Sep 2025 18:38:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128647.1468933; Tue, 23 Sep 2025 18: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 1v17uF-0007Sr-1t; Tue, 23 Sep 2025 18:38:27 +0000
Received: by outflank-mailman (input) for mailman id 1128647;
 Tue, 23 Sep 2025 18:38:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v17uD-0007Sl-RY
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 18:38:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v17uD-006RJg-0k;
 Tue, 23 Sep 2025 18:38:25 +0000
Received: from [2a02:8012:3a1:0:5196:5816:243d:dc7b]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v17uD-009qei-0f;
 Tue, 23 Sep 2025 18:38: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=diiNjytD3faZaiTuTJ1+UiQGdUtcCjkghMbVBigeUX4=; b=PXFJKOyL/oEqnCLfQNuto/tL4A
	L0Kc+KKB+gsBMW7mSmh+bgdeaM5VsG6MC70pos+xnpA5zAw5If63Em9aH5ZdJv+KDAeCh06P/nrWz
	IbvgdVpPQFxracipTnJxS2adNU7jrv2QS7vTx6AXBvEneWvpzaZl7Lp3S9YuN3X0MNlc=;
Message-ID: <16c461a0-cbfc-4979-9513-4528d6b78463@xen.org>
Date: Tue, 23 Sep 2025 19:38:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/4] Implement CPU hotplug on Arm
Content-Language: en-GB
To: Grygorii Strashko ,
 Mykyta Poturai ,
 "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?= ,
 Juergen Gross 
References: 
 <0e69a741-b6e1-4315-91f0-581f72092c68@epam.com>
From: Julien Grall 
In-Reply-To: <0e69a741-b6e1-4315-91f0-581f72092c68@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Grygorii,

On 23/09/2025 17:09, Grygorii Strashko wrote:
> On 18.09.25 15:16, Mykyta Poturai wrote:
>> This series implements support for CPU hotplug/unplug on Arm. To 
>> achieve this,
>> several things need to be done:
>>
>> 1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented.
>> 2. timer and GIC maintenance interrupts switched to static irqactions 
>> to remove
>> the need for freeing them during release_irq.
>> 3. Enabled the build of xen-hptool on Arm.
>>
>> Tested on QEMU.
>>
>> Mykyta Poturai (4):
>>    arm/time: Use static irqaction
>>    arm/gic: Use static irqaction
>>    arm/sysctl: Implement cpu hotplug ops
>>    tools: Allow building xen-hptool without CONFIG_MIGRATE
>>
>>   config/arm64.mk                  |  1 +
>>   config/x86_32.mk                 |  1 +
>>   config/x86_64.mk                 |  1 +
>>   tools/libs/guest/Makefile.common |  4 +-
>>   tools/misc/Makefile              |  2 +-
>>   xen/arch/arm/gic.c               | 10 ++++-
>>   xen/arch/arm/sysctl.c            | 67 ++++++++++++++++++++++++++++++++
>>   xen/arch/arm/time.c              | 20 ++++++++--
>>   8 files changed, 98 insertions(+), 8 deletions(-)
>>
> 
> Hence you introducing new feature for ARM I'd very much appreciated if you
> add corresponding documentation under docs/hypervisor-guide/arm/.

I think some documentation is good. But why does this need to be Arm 
specific?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 18:41:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 18:41:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128659.1468943 (Exim 4.92)
	(envelope-from )
	id 1v17xM-0000VS-IQ; Tue, 23 Sep 2025 18:41:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128659.1468943; Tue, 23 Sep 2025 18:41:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v17xM-0000VL-Ex; Tue, 23 Sep 2025 18:41:40 +0000
Received: by outflank-mailman (input) for mailman id 1128659;
 Tue, 23 Sep 2025 18:41:38 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v17xK-0000VF-Oh
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 18:41:38 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v17xF-006RMu-36;
 Tue, 23 Sep 2025 18:41:33 +0000
Received: from [2a02:8012:3a1:0:5196:5816:243d:dc7b]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v17xF-009r5P-38;
 Tue, 23 Sep 2025 18:41: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=XQoMntzr3jRn5Fio9xgaseIZXKZnlh/BYdakeFBwYy8=; b=J145cdboYr3cRczGKlqSQTVevH
	rdj6KlBft1VqmPVf5EBdOoxEvXyHELymLIZfj8YZF6wkuMpNmN1FZ+s8OtKSbCxbnwlh30GviUucq
	nRnb3lFzqXiH53iWsRMcHBL6x14WXgSXNrSjUK2Id3C9KCENKYEuwMZRZki8403l8XPc=;
Message-ID: <7a12dbe0-c3dd-4e26-b52d-610e065236da@xen.org>
Date: Tue, 23 Sep 2025 19:41:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Content-Language: en-GB
To: Jan Beulich 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
References: 
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@epam.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 18/09/2025 15:51, Jan Beulich wrote:
> On 18.09.2025 15:35, Julien Grall wrote:
>> On 18/09/2025 13:16, Mykyta Poturai wrote:
>>> +static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
>>> +{
>>> +    bool up;
>>> +
>>> +    switch (hotplug->op) {
>>> +        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
>>> +            if ( hotplug->cpu == 0 )
>>
>> I can't find a similar check on x86. Do you have any pointer?
> 
> When CPU 0 cannot be brought down (see cpu_down()), tryin to bring it up
> is kind of pointless, and hence can perhaps be short circuited like this?

Thanks for the clarification, I missed the check in cpu_down(). That 
said, I don't see any value to short circuit it. In fact, I see this as 
more a risk because if we ever decide to allow CPU 0 to be offlined, 
then it would be more difficult to find places where we short circuit it.

So I would rather prefer if we remove the checks.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 18:45:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 18:45:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128672.1468953 (Exim 4.92)
	(envelope-from )
	id 1v181J-00014d-0K; Tue, 23 Sep 2025 18:45:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128672.1468953; Tue, 23 Sep 2025 18: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 1v181I-00014W-Tg; Tue, 23 Sep 2025 18:45:44 +0000
Received: by outflank-mailman (input) for mailman id 1128672;
 Tue, 23 Sep 2025 18:45:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v181H-00014Q-NL
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 18:45:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v181H-006RTL-0n;
 Tue, 23 Sep 2025 18:45:43 +0000
Received: from [2a02:8012:3a1:0:5196:5816:243d:dc7b]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v181H-009rfR-0u;
 Tue, 23 Sep 2025 18:45: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=cN8YcMWZlMZh5DbUFDu5aozwqjqXd2migigsxSiVLGY=; b=hgTLsJQ4b9PeEeUmJ9Cb19/X96
	1XjElB+/gO9kmS3qEQO05ggt11XW3W+CVP1C2EMTv+/GUIrTf7iq7v9FlBErCJx6LoH9V6fbIe15F
	rEuncnLsR6yuSeC3+KT4uZpKIKPiEBHdlZ+UBo6GW8YsuPqzvKTR8s0W2JXkhxa5WCaE=;
Message-ID: <81a1de69-0c42-450b-a97d-8d30cfe247de@xen.org>
Date: Tue, 23 Sep 2025 19:45:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
Content-Language: en-GB
To: Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@epam.com>
 
 <721b5d6a-257e-447d-bac6-675ccedc3928@epam.com>
From: Julien Grall 
In-Reply-To: <721b5d6a-257e-447d-bac6-675ccedc3928@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykyta,

On 23/09/2025 14:37, Mykyta Poturai wrote:
> On 18.09.25 16:35, Julien Grall wrote:
>> Hi Mykyta,
>>
>> On 18/09/2025 13:16, Mykyta Poturai wrote:
>>> Implement XEN_SYSCTL_CPU_HOTPLUG_* calls to allow for enabling/disabling
>>> CPU cores in runtime.
>>>
>>> Signed-off-by: Mykyta Poturai 
>>> ---
>>>    xen/arch/arm/sysctl.c | 67 +++++++++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 67 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
>>> index 32cab4feff..ca8fb550fd 100644
>>> --- a/xen/arch/arm/sysctl.c
>>> +++ b/xen/arch/arm/sysctl.c
>>> @@ -12,6 +12,7 @@
>>>    #include 
>>>    #include 
>>>    #include 
>>> +#include 
>>>    #include 
>>>    #include 
>>> @@ -23,6 +24,68 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>>>                                           
>>> XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>>>    }
>>> +static long cpu_up_helper(void *data)
>>> +{
>>> +    unsigned long cpu = (unsigned long) data;
>>> +    return cpu_up(cpu);
>>> +}
>>> +
>>> +static long cpu_down_helper(void *data)
>>> +{
>>> +    unsigned long cpu = (unsigned long) data;
>>> +    return cpu_down(cpu);
>>> +}
>>> +
>>> +static long smt_up_down_helper(void *data)
>>
>> Looking at the code, you will effectively disable all the CPUs but CPU0.
>> But I don't understand why. From the name is goal seems to be disable
>> SMT threading.
>>
> 
> Sorry I have slightly misunderstood the x86 implementation/reasoning of
> this ops. I will drop them in V2.
> 
>>> +{
>>> +    bool up = (bool) data;
>>> +    unsigned int cpu;
>>> +    int ret;
>>> +
>>> +    for_each_present_cpu ( cpu )
>>> +    {
>>> +        if ( cpu == 0 )
>>> +            continue;
>>> +
>>> +        if ( up )
>>> +            ret = cpu_up(cpu);
>>> +        else
>>> +            ret = cpu_down(cpu);
>>> +
>>
>> Regardless what I wrote above, you likely want to handle preemption.
>>
>>> +        if ( ret )
>>> +            return ret;
>>   > +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
>>> +{
>>> +    bool up;
>>> +
>>> +    switch (hotplug->op) {
>>> +        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
>>> +            if ( hotplug->cpu == 0 )
>>
>> I can't find a similar check on x86. Do you have any pointer?
> 
> Jan correctly mentioned that CPU0 can't be disabled so this is a short
> circuit for clarity.

I have replied to Jan. In short, the clarify you are referring is what 
would make more difficult to support offlining CPU0. So I would rather 
prefer if they are not present.
>>
>>> +            return continue_hypercall_on_cpu(0, cpu_up_helper,
>>> _p(hotplug->cpu));
>>> +
>>> +        case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
>>> +            if ( hotplug->cpu == 0 )
>>> +                return -EINVAL;
>>> +            return continue_hypercall_on_cpu(0, cpu_down_helper,
>>> _p(hotplug->cpu));
>>> +
>>> +        case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE:
>>> +        case XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE:
>>
>> Why are we implementing those helpers on Arm?
>>
>>> +            if ( CONFIG_NR_CPUS <= 1 )
>>> +                return 0;
>>> +            up = hotplug->op == XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE;
>>> +            return continue_hypercall_on_cpu(0, smt_up_down_helper,
>>> _p(up));
>>> +
>>> +        default:
>>> +            return -EINVAL;
>>> +    }
>>> +}
>>> +
>>>    long arch_do_sysctl(struct xen_sysctl *sysctl,
>>>                        XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>>>    {
>>> @@ -34,6 +97,10 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
>>>            ret = dt_overlay_sysctl(&sysctl->u.dt_overlay);
>>>            break;
>>> +    case XEN_SYSCTL_cpu_hotplug:
>>
>> This will also enable CPU hotplug on 32-bit Arm. Is this what you
>> intended? (I see patch #4 only mention 64-bit Arm).
> 
> It wasn't intended. I will additionally check if it works on arm32 end
> explicitly specify it.

It will not work properly on arm32 because of the page table code. We 
have per-CPU pagetables (see init_domheap_mappings()) and they will need 
to be freed.

Note this is not a request to add support for arm32 CPU offlining.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Sep 23 19:34:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 19:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128693.1468963 (Exim 4.92)
	(envelope-from )
	id 1v18mn-0007ap-Fy; Tue, 23 Sep 2025 19:34:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128693.1468963; Tue, 23 Sep 2025 19:34: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 1v18mn-0007ai-Ci; Tue, 23 Sep 2025 19:34:49 +0000
Received: by outflank-mailman (input) for mailman id 1128693;
 Tue, 23 Sep 2025 19:34:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v18mm-0007ac-2w
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 19:34:48 +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 5b597a7a-98b4-11f0-9809-7dc792cee155;
 Tue, 23 Sep 2025 21:34:44 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-62fbc90e6f6so8101349a12.3
 for ; Tue, 23 Sep 2025 12:34: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: 5b597a7a-98b4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758656084; x=1759260884; 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=++d3dqdiBWxrOtz0QgpiS/0g7+oJyTqlQjLbyxgEnJo=;
        b=KxaO1att+YSOo9JmuvAo4yqzfYX4vr5qIAuJoYcQwSa5gA3CvvrsNgYpSS2xJLz5yc
         pizt9ClrPQr1n6c+lSitmdXksIYx0AwWP8AHV01Am2yHz/9ufFnCwf2TvNik6BNiAQRR
         9WnqtXrQJccwsa6D7v+kbh+ulE3ZzJWah3Qr4Us92be9LhS85lNsjPifQ7oyBmVxrEO8
         nFWT/e9AXTxQUHQAPUmwVY0mjGq/uicDGnPU4GHV/PA5WiEvA650IQ8hsUfIoroqCvJo
         uW19IKde0uPWaBNpAWD1cm7x/LfDCFGBet4K90bzHlK3WiV7MGpnbT6cJ4eyRvE+93nB
         /GKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758656084; x=1759260884;
        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=++d3dqdiBWxrOtz0QgpiS/0g7+oJyTqlQjLbyxgEnJo=;
        b=DWhEFRHn4/tIcAJ+5FHE1n56RRVBGq4lcMANIu32uPSU9KMxVQgPAFl0w5IibiTdPI
         Y8h3oRHGD4bYFuGGKmrdg4jwSDguHyUcu7jUDybZEh76nVwG1kbIVJ+rkQ+FN6LiCj/e
         HGC0u48X3xmt9ZoYZMcbe7jhi5jpF4kGcRSnuVO4JTBODaO2EjllxZzz2St5c+t7Zuev
         Un3v0DQpX6MV5XPeMKjOCR1755XrPQMYek6hDQ7lAQJXv733qPlByYi4YnseMVmz5Um8
         grtCQiqSVJh+mVmVOmhpsEp2eNctryHjHy8NFqcuA2MeM99Lmlk4I6ffo4aVhxE5IZri
         OhqA==
X-Forwarded-Encrypted: i=1; AJvYcCXiccJAd4M46BR6qo5OlHN6KYzb3qmYZAdGVf9eHf1v1MyuT4nHT1zTjpOzXvSv6WRUqAH0tcP8bAo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywo8ihugyuhC0pO/4gjrTw/pEDcWLUYiAHvf+k8HyS0ZmJMOdY+
	80XZtmqXhW6JBGf08Lo/melJmpSSy3hEsGpyhOFEh5gJsT4fXl+4uxFYLAd6w4vqt/b8IlLWwP3
	QJLOQPS3szYoH/qW0r8tev9kR6TJ1Jp8=
X-Gm-Gg: ASbGnct9NaWBwofxfPAn2gcUpsPBHO8EUODgN55Y1U+djpr80zfGt9wH18c7jQjlYYk
	gQQ4Dt4e0OE+lON3siv+G9ILzET3iCso0f7jfYWgXg7B22Hai62RMlj3b8tyK4L+E3bE+5ZO/TX
	N/xuF567uzCw9AeBJ6iqAx7Vs9emLhsveAo+GqVa3YTNB692ZdWfQitdtXsbPGPgBVOh//XNLVJ
	xRxGRy8
X-Google-Smtp-Source: AGHT+IG+y6U2HPtJWiJ06zINgKFsCV3h5cNmzOdYimKubd6x0uYI1nvJ7cf5K8syyZNEK08ri4tKiPSTOpp4XlvA7nY=
X-Received: by 2002:a05:6402:520a:b0:633:8c43:eff8 with SMTP id
 4fb4d7f45d1cf-63467a15e4cmr3129540a12.36.1758656083579; Tue, 23 Sep 2025
 12:34:43 -0700 (PDT)
MIME-Version: 1.0
References:  <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
  <20250923171819.GM10800@unreal>
In-Reply-To: <20250923171819.GM10800@unreal>
From: Magnus Lindholm 
Date: Tue, 23 Sep 2025 21:34:31 +0200
X-Gm-Features: AS18NWB41C3D5JsYFHuNFW-M81tws8xiK0mHlB-cBnQqvONalyjABahoz4jqIPg
Message-ID: 
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical address
To: Leon Romanovsky 
Cc: Marek Szyprowski , Jason Gunthorpe , 
	Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

>
> I will try to setup Alpha architecture in QEMU in following days, but
> would like to ask first. Did you test alpha on clean v6.17-rc5 (without
> my patches) as a reference?
>
I'm running now on a fresh git pull from today so it's more like a
6.17-rc7. So no problems running the latest git at least.  I can
dig deeper into this to see if we can figure this one out. First
of all, is this alpha specific?

Regards

Magnus


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 22:22:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 22:22:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128721.1468972 (Exim 4.92)
	(envelope-from )
	id 1v1BP1-0001ll-Rf; Tue, 23 Sep 2025 22:22:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128721.1468972; Tue, 23 Sep 2025 22:22: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 1v1BP1-0001le-Os; Tue, 23 Sep 2025 22:22:27 +0000
Received: by outflank-mailman (input) for mailman id 1128721;
 Tue, 23 Sep 2025 22:22: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 1v1BP1-0001lY-26
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 22:22:27 +0000
Received: from CO1PR03CU002.outbound.protection.outlook.com
 (mail-westus2azlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c005::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c6d7110f-98cb-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 00:22:24 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by PH7PR12MB7353.namprd12.prod.outlook.com (2603:10b6:510:20c::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9115.22; Tue, 23 Sep
 2025 22:22:19 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 22:22: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: c6d7110f-98cb-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iAi4sSpYU9zuO+eSlj02D1mT2vZrlCE9aXEYDzIMmitSqBQN+2VX1ibr/mnZKWw3OrO8UObY54jLJ8nPhouBUlHrKK0TI/5UrLPi6iTMXVIMSDrwPXT54A/HWJST6s9TH8x4fuVHLPtNeQ/GPsgSm8G6Cxrm0oPjOp/dv4CQ2FIev4ns7z6x7ZSAqa/50wrjuoBY13BrPTMGIIvubM/9cKpAyI2F6Zb8ZiHjmKJKykdT6ZCs6cS1iCCfGtYQXg+uE12N+DopvzfWy7JkzScecOd/cT8esGFZZGJblulMzMY7qLbqcAgFogLzfmhiy8juUJnIyLO5vYIHPKdQx4SEBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6hQxSPueRjqivytB2WxD4yT9ZIay1EdItgh7HO++yOU=;
 b=HvIek/lX0cBUYLNPcCkNtxHIxjUBoUl+vCN0NfSnVju3LMp/5msW9gaUGEMk5/HjQWrwPTvU+XIafpSQR75SjAXzCdycH2xD5Vo7bKXuWS3d6I6o7hXuO6lgfG/UrY1JiYp77HsUFLrqxGVq9z4Vb+SH9Q3OYbx4wSR67er4Fp6XCmObaF2iUzMgSxtdPrYx803AN9Pn1acmlVMd1vGI4t2mkGIw9plvILU4jU8XIgIj5o4cWItiXzHgn5+o/iohSI4ff//MX5KCr6Ds3GVi9FCNG5jJOyJgmIs+DqXz1JQI0S7uqoyfvYwo4O7QqfiLZtU1nU4iYSnmvum6bIq+ag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6hQxSPueRjqivytB2WxD4yT9ZIay1EdItgh7HO++yOU=;
 b=o6lXNIV2qcDbOVBz3hScRzhykjeJrAvH7uSY94JvgF+nxPIuz0abEbY8ZddkS1WLHE8Xj5MaFxug5Mn8T0Up/ObnQ01ZScIvPOLF/LI8trb/QBejrpCBAsKZXBny0IbHrhbe/p6FJgiesrH8kpLwKipC9Hqiy3t5qi5JIiGG2KOv1tcExgLAzKLXArBLQv2ck5tJtncJzhYxKwESG4lSQpaG1tpUCzf+5p6CloJTmHQBvMBH25Y8qSO84C8Mib4pJUIQeNAhMniB/ntJWYePSk40kipGvmTUOOL6iz3CpmaFQ5IxbBOy+hkdElhG352ld4WLKDZpkALEgbB2VuMWiw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Tue, 23 Sep 2025 19:22:16 -0300
From: Jason Gunthorpe 
To: Keith Busch 
Cc: Leon Romanovsky ,
	Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: <20250923222216.GC2617119@nvidia.com>
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
 
 <20250920155352.GH10800@unreal>
 
 <20250923170936.GA2614310@nvidia.com>
 
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-ClientProxiedBy: SA9PR13CA0121.namprd13.prod.outlook.com
 (2603:10b6:806:27::6) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|PH7PR12MB7353:EE_
X-MS-Office365-Filtering-Correlation-Id: 52108b48-523e-4f64-a2fa-08ddfaefa842
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?HiFBaYaRi7DKEeQsmk6X/SYEgHfzNbu+M4du3xz9VIsxZ0oTPo570go6akJ4?=
 =?us-ascii?Q?2Or3ISNvnQmC1mSqyVZmAV0T2v/xkUXeqZHTEw57a5SxJS8OEIZVRvbzA3M4?=
 =?us-ascii?Q?zUeDxw3aXP1TqOHp/iiZ2FpshQBy2l8J+Nw9WjaXA/oolcCTguOEMyxKwMt1?=
 =?us-ascii?Q?VQvnaXFAXLHFEtkOWiUc9U3JBFrQn626RugY1Kx9u1+zZsLfZwURSftiRyJ2?=
 =?us-ascii?Q?AbRMek5TJ7C/C84eUmGjJf4cI3Fm03XZR7ptnfD76nofpP49hHMx7bOJwLf0?=
 =?us-ascii?Q?AK87VzDSV2liyg0oxstJCPZJ6zjUzy+pFSI1LRXSIL1mEi2bipw1u0pIvevb?=
 =?us-ascii?Q?21wu0KiRuiYmYHdR98L56KVV2qvGXUeT0OWnIrXpR6/tJnK0InA4JAK+q5YB?=
 =?us-ascii?Q?+PNqDo6n/Dz+1BJEAop5huCiDGVdEMB6IUMbGBAAViw6vt+9DYyU+fARydRv?=
 =?us-ascii?Q?VebmValwMPP+ipL63zSb+8coNQCLdhuzjejtPsEFbmo7sFWdRUHZ+SQicAB/?=
 =?us-ascii?Q?by9BGvHbm8YEYES6o68SKe0MRz7M/8DLLJWiGy1FEsX08mAJClRA25ASHqOn?=
 =?us-ascii?Q?9qbt998ToEEpx10C9M08G8UMWKk5IYX9hEmhM6W1XCF3FuIRhHlDniLnnyB/?=
 =?us-ascii?Q?Y0OBUif48DiAy4Qgmx6adV5z4hqXyOAyDd6xu9HSAjwsEbMv7ebhagxAbaJ8?=
 =?us-ascii?Q?tbqGDJJwMHSenWkE8Sp7/kTJx4UYgN1N7X6Pe+3Uw3P+yHCuKVhKmY2E+6Zk?=
 =?us-ascii?Q?r3NpokqBnTBOt6qYL/QF1p/Z/x6u1sKKXW24wlsjStbZNcrk/Ic4iZTA0yp8?=
 =?us-ascii?Q?Ado4kY7x1S6Ce+/bE9t5OGEIHKqSu1XJZaQY2/SC6J9sGb9xY6arvDY/e9yP?=
 =?us-ascii?Q?RWMNN2GEO9PPVY7GQ5mGRFbNn9+jd5o2/Pvz+sPyLUjTtng+O5eji2+cuvtZ?=
 =?us-ascii?Q?t68MCCJgoOVFIxQ4ClfY9/Yu+dqAGIa/AeO+mSDGiCjp4lL5TBWsZdWTubA8?=
 =?us-ascii?Q?5TkQ1oa6XRJcZrXjCwA30d/52w/7HPD57aOxIeQElVE28aV2LTvn2L60eEb1?=
 =?us-ascii?Q?X+ahd1MEFeQy+S/eh00gdgnBmIo5mwR+ubove1EtAoBvfJZQq8fJHRrmPQJu?=
 =?us-ascii?Q?URGBj3q0D1/sVUM+qLwM+taVSl2Q7LWKpCL2sm7O6JkFMotz6AfTRpbA9Xtp?=
 =?us-ascii?Q?R2sdQvjZ0ZX8/+XlV1oRvcz1DrFf2f+xbcy+McKo8J29DmvfmH+cKe1otjcU?=
 =?us-ascii?Q?TmSTeKKjU1L1dBbqDD+Ku+EM5WV4FzyWYRDFGQ1b8mL1qdim6VFY0yN/TAcH?=
 =?us-ascii?Q?DDRNlp83lJc+hT93VKW/mY0ScUrjh61HDhCiPtfRAB43+1vHo7KGLEwIMFwV?=
 =?us-ascii?Q?vvVy7B2jYyZakP+T8+su0vdooier05WIvIUvvLxjdw5XvhJ/DbrG2Rv2rvUk?=
 =?us-ascii?Q?aG+ybpQ9Iz8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?eVGNJdmby9Ocx1dT6CLNPZSYywtZ5BQQPj0z919YXfiHa+uvZCqKScTu7K+h?=
 =?us-ascii?Q?TEhVf3NybTrETxq9+DUNdWg6sUmVul7WgplkbHU8WxcPyscVyqucyWj39Iq9?=
 =?us-ascii?Q?DIBRmS3r1wvzR+ThMQaAl9M3yWH4pN6WhLRib2oK1rlh4sIZv594wK3XES/i?=
 =?us-ascii?Q?ppzmrzxmupDAqwLzMdIybgoOe4Q3FHGa1+jpzZQmCa1PqrEWAgXz8w1OxdMD?=
 =?us-ascii?Q?RqiJd4P4iHVUuNPwNV61LALwTpaQ8wb43sdHVIGPh+WXBNVbn36vYHACN7Wh?=
 =?us-ascii?Q?lEMAUmtTbu8hqVLBIZ727iR6GXDpGJy90XKuqQmGOTzfpqAKdH5s5nAVm68g?=
 =?us-ascii?Q?gCekI4E+feogQTAbMMlwcIR8I5D/NvIhwo6poYenL0IgTSapHG5nXBtDBgy+?=
 =?us-ascii?Q?hLp0loRIWvIQz2FsUDFcxkfGG158SXFVwEmQ7zyKcnwngO3FKZi3ghsoLqQJ?=
 =?us-ascii?Q?h8Hb/47//9zgVehIZ57TYxVhDgNbwBGmJYxSn5ZPB15AUL2LzYZSqWaOaVVs?=
 =?us-ascii?Q?1pH0qxN8vFtk8M0Z3zUjIs8wRAZ2ZnT460HWvYV1B0VGgeCFtU7BdJVfxR2P?=
 =?us-ascii?Q?x4phMDLxNk8HiFuJTLkUvo4PYEeNnO1HWc2Kp6Vt/uQ6K4yuyRFhTO+x0FBf?=
 =?us-ascii?Q?0IpY4BLkzsCYfaApAZtbvUQzIxbIojvg6D1JOBUoD3azc5mW0NKSrI197gYA?=
 =?us-ascii?Q?GJBqME/8N/RhwtzSW/tU9Djna9U8SbbeOjM1A+z4ADhfzf4Tz5Y++RN58UQ1?=
 =?us-ascii?Q?7BneyeEdGNqb3T9E1i4PsGbfTYOREYyhWED0aS4Af4zMcxxZx2yhGsa0hqqT?=
 =?us-ascii?Q?jDFDoe3YmI5+6T8UAwCbiVMixiVSqn01f603+7MB9V76s3Vfyhw+XR8mVpvl?=
 =?us-ascii?Q?NrFMuOvp4BECPmrykWHZzeyE6WKEGSxcZ/ES2liREp9ffszRLshxPBH+TC9A?=
 =?us-ascii?Q?6m7h5pYOfEpB7IMYNxYWiPCtgJ9Gtee/Um9osjzrExO+me55q3Yag8zswFgZ?=
 =?us-ascii?Q?we1jHVNJPK6WenRlpnFTpkW/mxoLeYL8gNcg6JWDNN6eZr1PEycYp8QIgCBV?=
 =?us-ascii?Q?RjiWXfHybAR2sszZ58LyRJkQlICq5jDSB0d4ghx0FGv6J24o6O/DcxJS64Of?=
 =?us-ascii?Q?C5eSS00vfQ/Ydb0l45BZ9TUED86C+Ikm2JIdhnzuuC3Qr4laf95QDbqzWuqH?=
 =?us-ascii?Q?0kRFLVYcKLGqPsWFAM9ExzmqsaxNXvbAytZ2BvK3RdHvgfciBvrB+4csMTIz?=
 =?us-ascii?Q?sQDOIiMdUjkn1dtEnC5Z7O5d142aAKRB/RlkMxYETjhYybWAS7qAvgql/Y4e?=
 =?us-ascii?Q?FQhGrarH+Y0W9rSIm39edFyxw3IMIVAmJ276+/BQYroKqeQ0Swe1Ie87k032?=
 =?us-ascii?Q?DZvlfF55aIXBy9F5zH57lQbqtVteAYQM1eN9kz2jVVXfTsuGiv2tZY/60JCo?=
 =?us-ascii?Q?EagVYUGYoylHGbdohYaptXBcK92YyzJmWukOI7tEEIL0SHsClNhzvktkLOMy?=
 =?us-ascii?Q?bLcjUSWcf6NJUoO+Nz7g3di1JPENGEj44yIOJtSxez3StVK2pe18DCj7Zcld?=
 =?us-ascii?Q?ncLYB5SOSnXrQKAyoRZJT9Q9bI+rqWwmBAZlW0l2?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 52108b48-523e-4f64-a2fa-08ddfaefa842
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 22:22:18.6133
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NGLYkxWEuDdqsEtURp8syALj/D+W0jy8uzr92XEQX0IUKCZEPeugcvMAO9ufQqtp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7353

On Tue, Sep 23, 2025 at 12:30:55PM -0600, Keith Busch wrote:
> I don't have a system in this state at the moment, so we checked
> previous logs on machines running older kernels. It's extermely
> uncommon, but this error was happening prior to this series, so I don't
> think this introduced any new problem here. I'll keeping looking, but I
> don't think we'll make much progress if I can't find a more reliable
> reproducer.

Okay, that's great. It needs to get resolved but it is not this series
at fault.

Very rare is a different perspective, I mis-thought it was happening
reproducible all the time..

It seems to me it is actually a legitimate thing for userspace to be
able to trigger this cache line debug. If you do concurrent O_DIRECT
to the very same memory it should trigger if I read it right..

So it may not even be an actual bug???

Jason


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 22:35:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 22:35:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128737.1468982 (Exim 4.92)
	(envelope-from )
	id 1v1BbR-0003SY-3d; Tue, 23 Sep 2025 22:35:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128737.1468982; Tue, 23 Sep 2025 22:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1BbR-0003SR-0l; Tue, 23 Sep 2025 22:35:17 +0000
Received: by outflank-mailman (input) for mailman id 1128737;
 Tue, 23 Sep 2025 22:35: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 1v1BbP-0003SL-TK
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 22:35:15 +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 914e38aa-98cd-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 00:35:13 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 34F4144593;
 Tue, 23 Sep 2025 22:35:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68E0DC4CEF5;
 Tue, 23 Sep 2025 22:35: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: 914e38aa-98cd-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758666911;
	bh=K+REPAt7YGROMU060Sut8pDiJmmKCZ4JFkal1RQOmGs=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=NfvKLIECePVJSfIsLMzuzmM3Lfkth90P9jpbucNQ1bDMKtxnUUxV5JFtKuhdhpmWb
	 Cw3GZEX3eQpIT/PWZ/yXnZMG824R5TCQPjlm98ugF9huAG8DeaThH3gkBcbwr/TZuE
	 vm/De9fznWxi8yL9W3hbwpzVsdSjYKdJINx4sFLGsP2083YAha5J9C5fBwD4MqMtXT
	 ir+xFYNttlpYqZZmrRAZCSLQPAaJ5po2rCCjv7hee+rH9n2nEI6G7JOlhDYZQf0/X1
	 1DkImokD6CqYRTWU50ZSiWc781Xdx+oofE6BqZqS50/4CeH67G98lYY+2B9ZA6UvmX
	 2kJmK3McZDdRg==
Date: Tue, 23 Sep 2025 16:35:07 -0600
From: Keith Busch 
To: Jason Gunthorpe 
Cc: Leon Romanovsky ,
	Marek Szyprowski ,
	Abdiel Janulgue ,
	Alexander Potapenko ,
	Alex Gaynor ,
	Andrew Morton ,
	Christoph Hellwig , Danilo Krummrich ,
	David Hildenbrand , iommu@lists.linux.dev,
	Jason Wang , Jens Axboe ,
	Joerg Roedel , Jonathan Corbet ,
	Juergen Gross , kasan-dev@googlegroups.com,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nvme@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-trace-kernel@vger.kernel.org,
	Madhavan Srinivasan ,
	Masami Hiramatsu ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Miguel Ojeda ,
	Robin Murphy , rust-for-linux@vger.kernel.org,
	Sagi Grimberg ,
	Stefano Stabellini ,
	Steven Rostedt ,
	virtualization@lists.linux.dev, Will Deacon ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 00/16] dma-mapping: migrate to physical address-based
 API
Message-ID: 
References: 
 
 <0db9bce5-40df-4cf5-85ab-f032c67d5c71@samsung.com>
 <20250912090327.GU341237@unreal>
 
 <20250920155352.GH10800@unreal>
 
 <20250923170936.GA2614310@nvidia.com>
 
 <20250923222216.GC2617119@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250923222216.GC2617119@nvidia.com>

On Tue, Sep 23, 2025 at 07:22:16PM -0300, Jason Gunthorpe wrote:
> Very rare is a different perspective, I mis-thought it was happening
> reproducible all the time..

Yes, sorry for the false alarm. I think we got unlucky and hit it on one
of the first boots from testing linux-next, so knee-jerk reaction was to
suspect the new code that showed up in the stack.


From xen-devel-bounces@lists.xenproject.org Tue Sep 23 23:53:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Sep 2025 23:53:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128757.1468993 (Exim 4.92)
	(envelope-from )
	id 1v1Cp7-0004QZ-Dx; Tue, 23 Sep 2025 23:53:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128757.1468993; Tue, 23 Sep 2025 23:53:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Cp7-0004QS-9z; Tue, 23 Sep 2025 23:53:29 +0000
Received: by outflank-mailman (input) for mailman id 1128757;
 Tue, 23 Sep 2025 23:53: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 1v1Cp5-0004QJ-7k
 for xen-devel@lists.xenproject.org; Tue, 23 Sep 2025 23:53:27 +0000
Received: from SJ2PR03CU001.outbound.protection.outlook.com
 (mail-westusazlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c001::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7d397f55-98d8-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 01:53:24 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by SA3PR12MB9159.namprd12.prod.outlook.com (2603:10b6:806:3a0::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Tue, 23 Sep
 2025 23:53:20 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9137.018; Tue, 23 Sep 2025
 23:53:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d397f55-98d8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kzuGb0YPnnZDypK46oCieMglXQVvJxHJXNXHxaP0O/18UoLSHb48v9dyhR7dIgm1CzHOTFRcOntHSxGmLlIwBf+MlacK8F/kCgHwq+wiCRsgQ3A+6BdRDDSQwqdhk3TLB+up9oUmMSCzKxN3kO0mbk0/o1DeMsy9PEFLPAwshCXxW/u/4o5M1o4rT5aNa0SiiECQRdR3XZ0/DG5Xm3Mgq/VdavXqjE66h3BnwiIBo3LaJ/miEZNKN8JuHIVNEfnf9MqWKSUwMFiDjapV6tyYnx17T2dUPkaqTmP98dHQvyOeTs4GdGIxg6/EGNxvZVifPfU2mLXksP+J9y+SXbKgbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dOqcF1qx3uRM59GkEJfLCCyAt/XruVhRcf20l7ynlzg=;
 b=tCbK+2g47JGuqbS6eV6WP1jReD8ESsLu/f9L9aMJNHyzyOFRhCoFOlFYnBwFHqpfH/vyvlTUgj1toMVS3YiQ+4C3OM9TEBLSXLbFlJPxe50Mdj7zR+M86SV+tVeeuddhJSluqjTZ5Fe95LXzR2adq5A+dT+9xfHHwc2NLYaB9HIBaVtmUnkF4A8doD9U75r/jFyRPo9R8PU0RXTbDWm1dc5yjeUgauPoIUxb+2d05GtKiM0HnvYbJHSAvA8+vx7KXcZUz2/JdWVTRSgpFJAR63LVptGKlovwYZUnC8mHeA4o1Rjx1VT+8Ac9IR2PXHIdm777M/GW2ifsd8RKu0zk2w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dOqcF1qx3uRM59GkEJfLCCyAt/XruVhRcf20l7ynlzg=;
 b=JsC5banjwSLEvQH/7wtP276/J8UoIwtyfOWgWbR+GHOP+JsSu2kyFipmAIUQZfLE2xa2Yan3GBXhLPj4RWU6pLvNEsusbIBOQhHCcgwE2eCiPZHhxm1hd3d+s+GPEaiKvojvHufCYB8/+h/2CcgeNizRtiBd74pjKiXzSiL1Drk8jC+q7Ee4u7d0JSeGFUeEpdjMPmy6ck4jaj/3v0eetafJtomRU6yvUtZt8x7fLqYmdJxC4ZNDlWb/xNmQNRaYCt8jLbdsGzl2ybB0ZznSvH5zNL2HMx4xjbt9/58mWjv3sBomqjUW77I2EMtLARWflN92vqj0Ynfohpg7yPfK7w==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Tue, 23 Sep 2025 20:53:18 -0300
From: Jason Gunthorpe 
To: Magnus Lindholm 
Cc: Leon Romanovsky ,
	Marek Szyprowski ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical
 address
Message-ID: <20250923235318.GD2617119@nvidia.com>
References: 
 <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal>
 
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-ClientProxiedBy: SJ0PR05CA0050.namprd05.prod.outlook.com
 (2603:10b6:a03:33f::25) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|SA3PR12MB9159:EE_
X-MS-Office365-Filtering-Correlation-Id: b183311f-b954-4ab0-5432-08ddfafc5f73
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:
	=?us-ascii?Q?ASdrlY+8Zb9njeOBHMqcfc/eh8Zg2SFJXx/lvxniYDxmTalUE3idJma3mgNz?=
 =?us-ascii?Q?XQTBE7Dagc9zhrGW/xUTu/ZBQ9LK1y4QWHg1v+aRJTvGLYKNrwJjmlPiueq8?=
 =?us-ascii?Q?AwgHMrURRS7lE/VbRC8xXyYTf1EAGcj6+tPb8ii0VmcOtV3xn5FpiH0QKJIK?=
 =?us-ascii?Q?LuxlskD59bHvpho5az0JH5QWUsLpr4joCdx1smQHhPmCAhmtQyYoAWm7jMv1?=
 =?us-ascii?Q?34pkDyFJFJvr4GyR/Q9IucRI+H9oHBj0adJQqhboz8QkNxIVeBTTZBwvjFAA?=
 =?us-ascii?Q?pTUVHjcXpXc9fVuHyRQ0mj/dxNpi6jMmIEHt1c4vodSNBaCJH2NSvFwckNTm?=
 =?us-ascii?Q?wLVqUQuP2b3I9p4JZOyNnsx6AqnfEZu9VAT2MjGl3RuTSfvExtwVKZseaQc0?=
 =?us-ascii?Q?HsPr92lkfK0+Iagrxjb6ktI5SinqXWlo+rlmrTVtCCDR7j02M950eo6W5sVB?=
 =?us-ascii?Q?xeUCUloYPNwVdupdJtemp6GEHIFf+seqKMQ1ss5JgdUb2hVLL5P2cCu6Z7sZ?=
 =?us-ascii?Q?ouu3LlZXe3nDDIxKsxucv62W6Lj4Oum5ulcg546CbzdG35DfmkxHKtmzTgnh?=
 =?us-ascii?Q?a+WwcvrivQjMYsSmssBFtQsOb1Q4JKEbPFlmYAvtK89MQr6QaNoaxfX5Izd8?=
 =?us-ascii?Q?XzI355bA71jECy0ua0t804kjIURmWZW/kWozx8DetwKNeBjrVFePGdwkav0m?=
 =?us-ascii?Q?K23I9kidRwjYud2683BgMP22R0pi0zrRWyJcxe75Queus4v4wojV0Ivi/4kf?=
 =?us-ascii?Q?2VMToxp4YS1iVQ3Kk0WhyaH193itlEn1+Dwwzw6niB/1WPGWKm9BVvYP36Sy?=
 =?us-ascii?Q?R8vzpTeWkP98n5zGqGRkzP9fTrX0NX4GLmdfPkO0SqkeLD1C5AwP5NVcJvF8?=
 =?us-ascii?Q?ma8GuMagOgv2+tuHQJn8dZQsot8Mwz4jZ5J7P5tJSBDr2R9+3DXxobhJi1tE?=
 =?us-ascii?Q?pBMuYn5qPotVnDi7mpYQjCCi8pjF3zwSc/495AOgLHpd8CaC9mnA3CbJYNTz?=
 =?us-ascii?Q?OJYMQBSP9UVnGNZd77AIHCrG45y12Ah/0zjeMD9Ohr9hqHkAZ6m2xGQk1BHy?=
 =?us-ascii?Q?cEWfiUIXV2/YY/gpXBsdq7nbfsTlCCFgSOoUd/QVYgqGNAPwabUSIiYKvWYH?=
 =?us-ascii?Q?mpacuxdAgGzQP9FOZeNqgxShkBGJ7djUu4hI3QxsHfHXPTCVHZU++OdNSRQ6?=
 =?us-ascii?Q?EKbcTZwOI/Njh92G195TofwiiEcSuikA6Gs1W6oLQxo5g5gvjqrnpFzDCmKO?=
 =?us-ascii?Q?SyAIvzs/PXKIiPx0YXHwkA5c3LNYAFfebL4nkjQS5B2kHB3Zpz7ry1YhhDzc?=
 =?us-ascii?Q?tGOAQpkGVz1O8UmnluQ39EEgU8/cTfCezIq4ggbsThsv+yyPV9FYifNbFNd9?=
 =?us-ascii?Q?QVcc3i7PFaugBpNMUBlqBGdfT02H73zGnDOwOzYREpwe4Nl+CeG69VmADcRg?=
 =?us-ascii?Q?OFHmLIK7rhs=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.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:
	=?us-ascii?Q?peXJ0Z7S3XrLMQ/hE1F1WLFaJfiuFa2yW5FCC7liy+MWHRTVuE6BDgKAU9nN?=
 =?us-ascii?Q?gYjiM+lzfGWKwd4liZ/Sm10uI/L+0lx9Tk0Rzm692OP6zDjsnE5nub3th8ua?=
 =?us-ascii?Q?Z0hkSo7wO316O8AmEg802J3NyxO1uK2szgA727mLkf83/+Om/Pbn7pYREAtF?=
 =?us-ascii?Q?D5ayhgk3wVmdByjsha2O65qiYm7uVfeAnmMFo3ARaLsynjRlVu550p1fMfqG?=
 =?us-ascii?Q?56ARmZ0mVCHcw/fBs5Wh0MfHjW/JxVhlGTpJGZAiH4BXKaD92qpvllgt8BRL?=
 =?us-ascii?Q?TI7O7gqWQez6EaLdg684Owognx88D1zBdvcurQOYAy8g5+KfDWneiGC5oxxM?=
 =?us-ascii?Q?xUkmw/QpIf//l1V2lxgMfqwb8glFd08SLNaACnKKEAjn7cxV+N7oa/NHiwpp?=
 =?us-ascii?Q?DhC0jLEk2Zj5FhLDrLrVUl3lgL6BrexFA3NVxnBDQGOMULXRyZOZu70s+k69?=
 =?us-ascii?Q?xVpiFuiyZrwxwT7got4V93PNa872Yn6edlfzhpdb648c5Jf6ZVHBNkJRc2B0?=
 =?us-ascii?Q?xINHWoHsWjwP7fkGAU9Z0yUoHV2gTwsVokeRDB6UD0tVNMe5lg8iU4Txeux8?=
 =?us-ascii?Q?CbwwbL5lzhex+vzIa5fUKrMfHs0kIhFDEgKfm4mM2g/DJIskN6J/y1AW6z87?=
 =?us-ascii?Q?htRs43Szjwr/q3AARKtcHSDwJZTPDObjU+h1Fb3KqMiU/vhVRE3AacuSy0As?=
 =?us-ascii?Q?WmDhMYzW46bUf9fHxSICWyHfW6W7xUS6l7iMbeRIGn5xqBr1OBbGsSUeH6C8?=
 =?us-ascii?Q?ZQpjivRpStjAwxi5Ia/mK3SCwM0enBBofdGS3SYwr5uf5M8eI5iKArJoPdbo?=
 =?us-ascii?Q?8CCc26kT3KWSLXbnN2DgkICkRSYZx4DUfPjKtHdQuY6DF2vDHeJlPengLRSH?=
 =?us-ascii?Q?g4C9wV2z799ijnjdhF1Z38DEpxG73bmZwYr9lRHR5n50R9uh7HFX4L+fT96K?=
 =?us-ascii?Q?KM9M0BwaGRsAws3gF50PAAsHqOcd0DdLLtTEBEoU09mND7bltLkmhwseilrB?=
 =?us-ascii?Q?vXwgsel8sbs+dF6BaU90yf5VVUVCi7HbDhyCtUF9KYdTLf+EaSolk7BepAre?=
 =?us-ascii?Q?Wkkm7lcDuEQLWeF1AMzMaLzczOKp/33uuCg6JhZY7TzyMiMCHcyqhNIXl/zo?=
 =?us-ascii?Q?mSZkH6thaHsT3iHV7GKq0x0oljb3tHeQ6hVJrZ892iiqk1jLY823G6/y+lxq?=
 =?us-ascii?Q?33iAo39CDpJZWIfUB95bGUly3LYxqfjkojRPykbAIZy8v/d+QhFjy1iRHjr6?=
 =?us-ascii?Q?N16RZMjM1oK8h/2Zm3RTFzS6z8y+kRD5sbK+7wYKNIZX5gTZz83FZTklgsvU?=
 =?us-ascii?Q?pIZ3H636tyvtM8oyfrl7wo+2y/Rc+6HiA9XoxI+a/R58INEMv1J3E/0H8tnb?=
 =?us-ascii?Q?8x1XekGodPX2zYMiB9sHodPR+1SV2JCa9iuDMhDbc/pgkiOBT1xYZILv9fCj?=
 =?us-ascii?Q?9UYR6TRQ5OhTD5/1ENb6wMc8oRYIL7i/uR1E8UwIVIiE9TQcGjJz7ltoVL1A?=
 =?us-ascii?Q?wBACfJmJcsWq91TIFPdNvw/FNFxjH/FAgNhZkTojV8xoAub3hkyc4NCGHrvX?=
 =?us-ascii?Q?Cz/DSXNBWFre1ItR9KuaZZ5NWdFZBGYHmF48mzzz?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b183311f-b954-4ab0-5432-08ddfafc5f73
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2025 23:53:19.8299
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1hf0pOWCX3e5dXk6AaQB06RjIj3yBdW2VjcD/zO5seEmRunAO1bhNpobnPLGfv2k
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9159

On Tue, Sep 23, 2025 at 09:34:31PM +0200, Magnus Lindholm wrote:
> >
> > I will try to setup Alpha architecture in QEMU in following days, but
> > would like to ask first. Did you test alpha on clean v6.17-rc5 (without
> > my patches) as a reference?
> >
> I'm running now on a fresh git pull from today so it's more like a
> 6.17-rc7. So no problems running the latest git at least.  I can
> dig deeper into this to see if we can figure this one out. First
> of all, is this alpha specific?

I spent a bit of time looking at the alpha patch and could not spot a
typo, it looked OK to me. I was worried for a bit that virt_to_phys()
vs __pa() were different, but I could not find a difference.

Suggest testing the same branch with the alpha patch reverted just to
rule out any issue in the core code. If it reproduces suggest to
bisect Leon's branch.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 02:44:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 02:44:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128784.1469003 (Exim 4.92)
	(envelope-from )
	id 1v1FUj-00071W-7c; Wed, 24 Sep 2025 02:44:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128784.1469003; Wed, 24 Sep 2025 02:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1FUj-00071O-3d; Wed, 24 Sep 2025 02:44:37 +0000
Received: by outflank-mailman (input) for mailman id 1128784;
 Wed, 24 Sep 2025 02: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 1v1FUi-00071I-8y
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 02:44:36 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6546c396-98f0-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 04:44:32 +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 58O2i9W5051387
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Tue, 23 Sep 2025 22:44:14 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.18.1/8.15.2/Submit) id 58O2i7Pf051386;
 Tue, 23 Sep 2025 19:44:07 -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: 6546c396-98f0-11f0-9809-7dc792cee155
Date: Tue, 23 Sep 2025 19:44:07 -0700
From: Elliott Mitchell 
To: Anthoine Bourgeois 
Cc: Juergen Gross ,
        Stefano Stabellini ,
        Oleksandr Tyshchenko ,
        Paul Durrant , xen-devel@lists.xenproject.org
Subject: irt: [PATCH v2] xen/netfront: Fix TX response spurious interrupts
Message-ID: 
References: <20250715160902.578844-2-anthoine.bourgeois@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250715160902.578844-2-anthoine.bourgeois@vates.tech>
X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no
	autolearn_force=no version=4.0.1
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com

Trimming Cc list a bit since this follow-up topic doesn't need quite as
wide distribution.

On Tue, Jul 15, 2025 at 04:11:29PM +0000, Anthoine Bourgeois wrote:
> We found at Vates that there are lot of spurious interrupts when
> benchmarking the PV drivers of Xen. This issue appeared with a patch
> that addresses security issue XSA-391 (see Fixes below). On an iperf
> benchmark, spurious interrupts can represent up to 50% of the
> interrupts.



> Moreover, this problem is amplifyed by the penalty imposed by a spurious
> interrupt. When an interrupt is found spurious the interrupt chip will
> delay the EOI to slowdown the backend. This delay will allow more
> responses to be handled by the request path and then there will be more
> chance the next interrupt will not find any work to do, creating a new
> spurious interrupt.

When this was first discovered the problem was reported as being more
severe on systems with AMD processors and less severe on systems with
Intel processors.

Have you been able to look deeper to analyze the reason for this?

I wonder whether that difference might point to some deeper issue.
Latency in interrupt handling/propogation causing problems?  There are a
few other bugs which could be explained by issues with interrupts.


-- 
(\___(\___(\______          --=> 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 Wed Sep 24 02:55:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 02:55:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128796.1469012 (Exim 4.92)
	(envelope-from )
	id 1v1FfL-0000Ah-46; Wed, 24 Sep 2025 02:55:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128796.1469012; Wed, 24 Sep 2025 02: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 1v1FfL-0000Aa-1C; Wed, 24 Sep 2025 02:55:35 +0000
Received: by outflank-mailman (input) for mailman id 1128796;
 Wed, 24 Sep 2025 02:55:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v1FfK-0000AU-4f
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 02:55:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v1FfE-007nFH-2R;
 Wed, 24 Sep 2025 02:55:28 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v1FfE-00AfxO-2Q;
 Wed, 24 Sep 2025 02:55:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID
	:Subject:Cc:To:Date:From; bh=orwyACm+gh+YvTKkVksUkaEaEhRuZ8OT27zUHDN6yHA=; b=
	GYKa1TKTFDLTUzPmyMSJmvpesmMOczX9skAD0gaIA60J6yNIgaNC0gLYiHvbXpptZ2PAq4uQLgWBP
	8AMkZlouF2kOlMYyQaVziB9Zbn6sc9E6vPkiZy5wsHBJuyGLvG6msKJjM4DtJ4ZWqcLocQDFNEW57
	+1NqwBrLdu0KvTUWk=;
From: dmukhin@xen.org
Date: Tue, 23 Sep 2025 19:55:27 -0700
To: Jan Beulich 
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 v2] xen/domain: introduce DOMID_ANY
Message-ID: 
References: <20250920174732.1207847-2-dmukhin@ford.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Tue, Sep 23, 2025 at 12:43:54AM +0200, Jan Beulich wrote:
> On 22.09.2025 23:56, dmukhin@xen.org wrote:
> > On Mon, Sep 22, 2025 at 05:23:37PM +0200, Jan Beulich wrote:
> >> On 20.09.2025 19:47, dmukhin@xen.org wrote:
> >>> From: Denis Mukhin  
> >>>
> >>> Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
> >>> of the code.
> >>>
> >>> Update all relevant domid_alloc() call sites.
> >>>
> >>> Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
> >>> Signed-off-by: Denis Mukhin 
> >>> ---
> >>> Changes since v1:
> >>> - moved DOMID_ANY from the public header
> >>
> >> This addresses my comment, but not Andrew's subsequent response, specifically
> >> aiming at ...
> > 
> > AFAIU, toolstack should start using DOMID_ANY instead of 0 in
> > XEN_DOMCTL_createdomain.
> > 
> > I was planning to send a separate patch to address it if that's OK.
> > 
> >>
> >>> --- a/tools/tests/domid/harness.h
> >>> +++ b/tools/tests/domid/harness.h
> >>> @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
> >>>  
> >>>  #define DOMID_FIRST_RESERVED            (100)
> >>>  #define DOMID_INVALID                   (101)
> >>> +#define DOMID_ANY                       DOMID_INVALID
> >>
> >> ... avoiding the need for any such secondary definitions.
> > 
> > In the current design, unit test harness.h has to define DOMID_ANY.
> > Enabling xen/domain.h to compile for unit test is a separate task, IMO.
> 
> That wasn't suggested as an option. The #define wants to move back to
> the public header, but be properly guarded there. See the v1 replies
> you got.

Got it, thanks.
Will send v3.


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 03:06:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 03:06:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128808.1469022 (Exim 4.92)
	(envelope-from )
	id 1v1FqB-0001nO-1X; Wed, 24 Sep 2025 03:06:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128808.1469022; Wed, 24 Sep 2025 03:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1FqA-0001nH-VL; Wed, 24 Sep 2025 03:06:46 +0000
Received: by outflank-mailman (input) for mailman id 1128808;
 Wed, 24 Sep 2025 03:06:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v1FqA-0001nB-6k
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 03:06:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v1Fq9-007nTL-1t;
 Wed, 24 Sep 2025 03:06:45 +0000
Received: from [19.12.91.86] (helo=localhost)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v1Fq9-00Ah6Q-1y;
 Wed, 24 Sep 2025 03:06: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:MIME-Version:Message-ID:Date:
	Subject:Cc:To:From; bh=fnFz8JkCkgwlxqLvlzprdKyhKzICse/YqhN2WV/X1/s=; b=6JjPHF
	zZwmuOtVgdLmQUoa+iUHSnYz2XpkHLdx+va9ikHGKwnhGKk/Mf3284+XsyaVPtFakS3Y9RcY8nwgh
	44oPuLhDWdrffiaFMKf8bHxKc7xsl7Lr25mA9PhcA1HRwsLe2uM8lsYbfacfTDWanQVBds7Y7Z6rq
	0dFsv4NZhgo=;
From: dmukhin@xen.org
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	dmukhin@ford.com
Subject: [PATCH v3] xen/domain: introduce DOMID_ANY
Date: Tue, 23 Sep 2025 20:06:31 -0700
Message-ID: <20250924030630.122229-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Denis Mukhin  

Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
of the code.

Update all relevant domid_alloc() call sites.

Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
Signed-off-by: Denis Mukhin 
---
Changes since v2:
- move DOMID_ANY back to the public header; add proper guards
- CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2056319227
- Link to v2: https://lore.kernel.org/xen-devel/20250920174732.1207847-2-dmukhin@ford.com/
---
 tools/tests/domid/harness.h             |  1 +
 tools/tests/domid/test-domid.c          | 12 ++++++------
 xen/common/device-tree/dom0less-build.c |  2 +-
 xen/common/domctl.c                     |  2 +-
 xen/common/domid.c                      |  2 +-
 xen/include/public/xen.h                |  5 +++++
 6 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/tools/tests/domid/harness.h b/tools/tests/domid/harness.h
index 17eb22a9a854..610b564d4061 100644
--- a/tools/tests/domid/harness.h
+++ b/tools/tests/domid/harness.h
@@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr,
 
 #define DOMID_FIRST_RESERVED            (100)
 #define DOMID_INVALID                   (101)
+#define DOMID_ANY                       DOMID_INVALID
 
 #endif /* _TEST_HARNESS_ */
 
diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
index 5915c4699a5c..71cc4e7fd86d 100644
--- a/tools/tests/domid/test-domid.c
+++ b/tools/tests/domid/test-domid.c
@@ -41,20 +41,20 @@ int main(int argc, char **argv)
         domid_free(expected);
 
     /*
-     * Test that that two consecutive calls of domid_alloc(DOMID_INVALID)
+     * Test that that two consecutive calls of domid_alloc(DOMID_ANY)
      * will never return the same ID.
      * NB: ID#0 is reserved and shall not be allocated by
-     * domid_alloc(DOMID_INVALID).
+     * domid_alloc(DOMID_ANY).
      */
     for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == expected,
                "TEST 3: expected %u allocated %u\n", expected, allocated);
     }
     for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == DOMID_INVALID,
                "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated);
     }
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
         domid_free(expected);
     for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ )
     {
-        allocated = domid_alloc(DOMID_INVALID);
+        allocated = domid_alloc(DOMID_ANY);
         verify(allocated == expected,
                "TEST 5: expected %u allocated %u\n", expected, allocated);
     }
@@ -72,7 +72,7 @@ int main(int argc, char **argv)
     /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */
     expected = DOMID_FIRST_RESERVED - 1;
     domid_free(DOMID_FIRST_RESERVED - 1);
-    allocated = domid_alloc(DOMID_INVALID);
+    allocated = domid_alloc(DOMID_ANY);
     verify(allocated == expected,
            "TEST 6: expected %u allocated %u\n", expected, allocated);
 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 9fd004c42af7..e2764768c983 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -848,7 +848,7 @@ void __init create_domUs(void)
         if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
             panic("No more domain IDs available\n");
 
-        domid = domid_alloc(DOMID_INVALID);
+        domid = domid_alloc(DOMID_ANY);
         if ( domid == DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node));
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 954d79022645..ca91686a03d8 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -410,7 +410,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     case XEN_DOMCTL_createdomain:
     {
         /* NB: ID#0 is reserved, find the first suitable ID instead. */
-        domid_t domid = domid_alloc(op->domain ?: DOMID_INVALID);
+        domid_t domid = domid_alloc(op->domain ?: DOMID_ANY);
 
         if ( domid == DOMID_INVALID )
         {
diff --git a/xen/common/domid.c b/xen/common/domid.c
index 2387ddb08300..76b7f3e7ae6e 100644
--- a/xen/common/domid.c
+++ b/xen/common/domid.c
@@ -19,7 +19,7 @@ static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
  * @param domid Domain ID hint:
  * - If an explicit domain ID is provided, verify its availability and use it
  *   if ID is not used;
- * - If DOMID_INVALID is provided, search [1..DOMID_FIRST_RESERVED-1] range,
+ * - If DOMID_ANY is provided, search [1..DOMID_FIRST_RESERVED-1] range,
  *   starting from the last used ID. Implementation guarantees that two
  *   consecutive calls will never return the same ID. ID#0 is reserved for
  *   the first boot domain (currently, dom0) and excluded from the allocation
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 82b9c05a76b7..29b7c81ba1bb 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -608,6 +608,11 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
 /* DOMID_INVALID is used to identify pages with unknown owner. */
 #define DOMID_INVALID        xen_mk_uint(0x7FF4)
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */
+#define DOMID_ANY            DOMID_INVALID
+#endif
+
 /* Idle domain. */
 #define DOMID_IDLE           xen_mk_uint(0x7FFF)
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128835.1469040 (Exim 4.92)
	(envelope-from )
	id 1v1HHx-0003ws-Lr; Wed, 24 Sep 2025 04:39:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128835.1469040; Wed, 24 Sep 2025 04:39: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 1v1HHx-0003wN-FC; Wed, 24 Sep 2025 04:39:33 +0000
Received: by outflank-mailman (input) for mailman id 1128835;
 Wed, 24 Sep 2025 04:39:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1HHu-0003tk-6P
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:39:31 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 730b5eda-9900-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 06:39:27 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSmu091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:39 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 730b5eda-9900-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=jWpLp8n23CdClF2nwSY2mTKMJfX9C2XmSiyVTvW4DxU=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688660; v=1;
        b=Z/ywqlxOJlUU34+E0osmWrMy3ELkCuh2OmBTrboInpXjOqD4SffZwY/4CYZU9EMl
         Dzx+hMFZXJ69msVRzYu3/rva7z862cW0LJjoo/7a+OQagfk8KQoAs9iIRpTaSSa0
         pt61xjJaSVVPqRurq0vu8rPC19jEuObo8buUpNjAPokMhv64OcpL5QB9Y95TzlPO
         DlIeieX9/8KQLvSGtaM+M1bC9SwqmIQfS3fxvyYmqXzx7aCq3R7AM6yqLJEfDQ+v
         CJWE+1FHrkF22D4QuYAryKLCEdfm+xmGbKGgorUxyLRleupCLTsp+J1Kg+Ny5fWK
         7e33gFmpWCJMRvhjM4Rrxw==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:21 +0900
Subject: [PATCH v4 2/7] vfio/pci: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-2-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the insntance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 hw/vfio/pci.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index d14e96b2f82d..bc0b4c4d562b 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2025,7 +2025,6 @@ static void vfio_bars_finalize(VFIOPCIDevice *vdev)
         vfio_region_finalize(&bar->region);
         if (bar->mr) {
             assert(bar->size);
-            object_unparent(OBJECT(bar->mr));
             g_free(bar->mr);
             bar->mr = NULL;
         }
@@ -2033,9 +2032,6 @@ static void vfio_bars_finalize(VFIOPCIDevice *vdev)
 
     if (vdev->vga) {
         vfio_vga_quirk_finalize(vdev);
-        for (i = 0; i < ARRAY_SIZE(vdev->vga->region); i++) {
-            object_unparent(OBJECT(&vdev->vga->region[i].mem));
-        }
         g_free(vdev->vga);
     }
 }

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128838.1469060 (Exim 4.92)
	(envelope-from )
	id 1v1HHy-0004LL-MI; Wed, 24 Sep 2025 04:39:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128838.1469060; Wed, 24 Sep 2025 04:39: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 1v1HHy-0004KW-FM; Wed, 24 Sep 2025 04:39:34 +0000
Received: by outflank-mailman (input) for mailman id 1128838;
 Wed, 24 Sep 2025 04:39: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 1v1HHw-0003tk-9s
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:39:32 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 737f76b0-9900-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 06:39:28 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSn1091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:42 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 737f76b0-9900-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=vi4sMCmLJjgfxvWMbOYby11DlXiXjOhpwer283mUMTs=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688663; v=1;
        b=vMUFXDPYCmcF3lkI3BSe8blrWRLpmkSDNiuoijwb8afjg4NFFoXRVFRUcZKqSDWZ
         UxyHm40QSJbHGmhdgwFt2tLNGNwgCN9rY3rBjQRTYhwEgeOZHxvqM8it4xuvLD2I
         Y64/RVkv+TGrq1SHjZX01HPGzBAE1tXU/+8KZ9eiHUy+bjnBFdvJZGS56faG53Pm
         ayjh52pqL+SyZAbZWvtUf/zdn43pa9CblMdEmFQi+w3kalRFalhT9Gcto4h5FPcD
         kHSwZrG/MFphOqwon+RkDuWJB+7ep1P8/2N8JN+8Xus32JicITr97APzWeqPas3v
         utrloMLlNHbmgml831WcIQ==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:26 +0900
Subject: [PATCH v4 7/7] hw/xen: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-7-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 hw/xen/xen_pt_msi.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 09cca4eecb1c..e9ba17317aba 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -637,14 +637,5 @@ void xen_pt_msix_unmap(XenPCIPassthroughState *s)
 
 void xen_pt_msix_delete(XenPCIPassthroughState *s)
 {
-    XenPTMSIX *msix = s->msix;
-
-    if (!msix) {
-        return;
-    }
-
-    object_unparent(OBJECT(&msix->mmio));
-
-    g_free(s->msix);
-    s->msix = NULL;
+    g_clear_pointer(&s->msix, g_free);
 }

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128837.1469053 (Exim 4.92)
	(envelope-from )
	id 1v1HHy-0004BR-A2; Wed, 24 Sep 2025 04:39:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128837.1469053; Wed, 24 Sep 2025 04:39: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 1v1HHy-0004At-3l; Wed, 24 Sep 2025 04:39:34 +0000
Received: by outflank-mailman (input) for mailman id 1128837;
 Wed, 24 Sep 2025 04:39: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 1v1HHw-0003tj-3L
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:39:32 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7478f1a8-9900-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 06:39:30 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSmt091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:39 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7478f1a8-9900-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=stt1PYHjZPmmH11DgDaK1e3bftbIHLz7TmtRdVRF/9A=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688659; v=1;
        b=lKHDilw5Fq1/cnZFtWrkLQsf0wSND4A4CU0I4JhwbBbzg1lFKYlm5Q6wiWuBCtxG
         CBRYgMu6tQ2BVB7pBZ4GKpjKjWSZFTvVUm0oTmudZfXEsN8GNwYfzHYCC7V2sEjn
         SWwyuMCezPLlRWJoNUlfxXyyK+NclfnGNRTrHEZnjUWn2czlf+auXXMRtpwS0RGD
         0eOCj+jtWsvogScD6U0vQbVzanTlRUywY+cLXorEA1hhfKVYP1sH1Uj43IJdxQUo
         kvY6GCE+/eIZjhpVu+LCvIvEwMqhx+YtYzSwQh4kYV8v9fTB/B5MDHg2SQtUp3+c
         sOnfgKokiFWh2MNIuOFJvA==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:20 +0900
Subject: [PATCH v4 1/7] docs/devel: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-1-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Remove the instruction to call object_unparent(), and the exception
of the "do not call object_unparent()" rule for instance_finalize().

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 docs/devel/memory.rst | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
index 42d3ca29c431..11858543f256 100644
--- a/docs/devel/memory.rst
+++ b/docs/devel/memory.rst
@@ -165,17 +165,14 @@ and finalized one by one.  The order in which memory regions will be
 finalized is not guaranteed.
 
 If however the memory region is part of a dynamically allocated data
-structure, you should call object_unparent() to destroy the memory region
-before the data structure is freed.  For an example see VFIOMSIXInfo
-and VFIOQuirk in hw/vfio/pci.c.
+structure, you should free the memory region in the instance_finalize
+callback.  For an example see VFIOMSIXInfo and VFIOQuirk in
+hw/vfio/pci.c.
 
 You must not destroy a memory region as long as it may be in use by a
 device or CPU.  In order to do this, as a general rule do not create or
-destroy memory regions dynamically during a device's lifetime, and only
-call object_unparent() in the memory region owner's instance_finalize
-callback.  The dynamically allocated data structure that contains the
-memory region then should obviously be freed in the instance_finalize
-callback as well.
+destroy memory regions dynamically during a device's lifetime, and must
+never call object_unparent().
 
 If you break this rule, the following situation can happen:
 
@@ -201,9 +198,7 @@ this exception is rarely necessary, and therefore it is discouraged,
 but nevertheless it is used in a few places.
 
 For regions that "have no owner" (NULL is passed at creation time), the
-machine object is actually used as the owner.  Since instance_finalize is
-never called for the machine object, you must never call object_unparent
-on regions that have no owner, unless they are aliases or containers.
+machine object is actually used as the owner.
 
 
 Overlapping regions and priority

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128834.1469032 (Exim 4.92)
	(envelope-from )
	id 1v1HHx-0003uM-Ba; Wed, 24 Sep 2025 04:39:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128834.1469032; Wed, 24 Sep 2025 04:39: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 1v1HHx-0003uE-8Q; Wed, 24 Sep 2025 04:39:33 +0000
Received: by outflank-mailman (input) for mailman id 1128834;
 Wed, 24 Sep 2025 04:39: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 1v1HHu-0003tj-E6
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:39:31 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 734bab1e-9900-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 06:39:28 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSms091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:38 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 734bab1e-9900-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=4Lrx+OHmEWMxnbxoN2F7Ox37ZHsYr5d+IsqXMnVqT1o=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Subject:Date:Message-Id:To;
        s=rs20250326; t=1758688659; v=1;
        b=UAXiXKO4Ji2vMqO4/0Y9wj6BVXDQ0BLFjbEBQlzZfWNdKZ7EehKftBG/zVO7C2CD
         gZMA31hZQaPekdxCHeEquvjPWsJ+tNGhTgp3tH4qQ++pq3IOJn0j5WbkZhrmtH0P
         8J4BUrEuD5GSWFI7bGB/xClYcXwviVMSPSwBpsOq0aemdfD/EnhdyjvbU6IA/gVg
         yZJMAHLl/323C6NqM3uIurnJq0/txBN/IPFkMf9CrwXtbQp6+cLx/gbIiXkGbPDB
         /VcwOelMjazEgXZIaR+olA4iYG20nC81SCiN0e/gP4FYvURae3M1ucgYB4HCJ2Cp
         bfMmFGxBXYoh+4tIcWKsRw==
From: Akihiko Odaki 
Subject: [PATCH v4 0/7] Do not unparent in instance_finalize()
Date: Wed, 24 Sep 2025 13:37:19 +0900
Message-Id: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-B4-Tracking: v=1; b=H4sIAH9102gC/33MTQ6CMBCG4auYrm3TH6HgynsYF3WYQjWxpAUiI
 dzdAhtc6PKdzPdMJGJwGMn5MJGAg4vOv1KcjgcCjXnVSF2VmkguM17ynPYRqdIIUHJlSuQkfbY
 BrXuvyvWWunGx82Fc0UEs1+/9ICinkAkwxlYC7/oSYs3AMcd62vnn6JkB9mjJgg1yB4hsA2QC7
 Am0tULdLZZ/AbUH9AaoBGgJ0uRFoSGHn8A8zx+kFuP8JQEAAA==
X-Change-ID: 20250906-use-37ecc903a9e0
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
---
Changes in v4:
- Removed Based-on:.
- Restored the examples of VFIOMSIXInfo and VFIOQuirk in
  docs/devel/memory.rst.
- Ensured that the timing to call object_unparent() and free memory
  regions is mentioned once for each.
- Link to v3: https://lore.kernel.org/qemu-devel/20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp

Changes in v3:
- Added patches to remove other object_unparent() calls in
  instance_finalize().
- Dropped patch "qdev: Automatically delete memory subregions" and the
  succeeding patches to avoid Ccing many.
- Link to v2: https://lore.kernel.org/qemu-devel/20250915-use-v2-0-f4c7ff13bfe9@rsg.ci.i.u-tokyo.ac.jp

Changes in v2:
- Added a reference to "[PATCH] docs/devel: Prohibit calling
  object_unparent() for memory region", which does something similar to
  patch "docs/devel: Do not unparent in instance_finalize()" but I
  forgot I sent it in the past.
- Fixed a typo in patch
  "docs/devel: Do not unparent in instance_finalize()" and
  "[PATCH 02/22] vfio/pci: Do not unparent in instance_finalize()".
- Dropped patches to move address_space_init() calls; I intend to
  QOM-ify to fix memory leaks automatically as discussed in the
  following thread:
  https://lore.kernel.org/qemu-devel/cd21698f-db77-eb75-6966-d559fdcab835@eik.bme.hu/
  But the QOM-ification will be big so I'll send it as a separate
  series.
- Rebased on top of "[PATCH v2 00/14] hw/pci-host/raven clean ups".
  https://lore.kernel.org/qemu-devel/cover.1751493467.git.balaton@eik.bme.hu/
- Link to v1: https://lore.kernel.org/qemu-devel/20250906-use-v1-0-c51caafd1eb7@rsg.ci.i.u-tokyo.ac.jp

---
Akihiko Odaki (7):
      docs/devel: Do not unparent in instance_finalize()
      vfio/pci: Do not unparent in instance_finalize()
      hw/core/register: Do not unparent in instance_finalize()
      hv-balloon: hw/core/register: Do not unparent in instance_finalize()
      hw/sd/sdhci: Do not unparent in instance_finalize()
      vfio: Do not unparent in instance_finalize()
      hw/xen: Do not unparent in instance_finalize()

 docs/devel/memory.rst  | 17 ++++++-----------
 hw/core/register.c     |  1 -
 hw/hyperv/hv-balloon.c | 12 +-----------
 hw/sd/sdhci.c          |  4 ----
 hw/vfio/pci-quirks.c   |  9 +--------
 hw/vfio/pci.c          |  4 ----
 hw/vfio/region.c       |  3 ---
 hw/xen/xen_pt_msi.c    | 11 +----------
 8 files changed, 9 insertions(+), 52 deletions(-)
---
base-commit: ab8008b231e758e03c87c1c483c03afdd9c02e19
change-id: 20250906-use-37ecc903a9e0

Best regards,
--  
Akihiko Odaki 



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128836.1469046 (Exim 4.92)
	(envelope-from )
	id 1v1HHx-00044I-VD; Wed, 24 Sep 2025 04:39:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128836.1469046; Wed, 24 Sep 2025 04:39: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 1v1HHx-00042t-PW; Wed, 24 Sep 2025 04:39:33 +0000
Received: by outflank-mailman (input) for mailman id 1128836;
 Wed, 24 Sep 2025 04:39: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 1v1HHw-0003tk-30
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:39:32 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73138fe5-9900-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 06:39:27 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSmw091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:40 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73138fe5-9900-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=7V8/qJWDXy9ssgUKD3EAH/SqAL55N0OPmxt1YNRhgjg=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688661; v=1;
        b=fpEBclbjIpKxVrq15ObmeGZp2X/hB8cpT+Fe9ZF5ZwtxWHg367i9ECVMpItYYweS
         DohE22Tg/9jZhCUI5s7FKc1H9W8MlVuCMARv6JIyr9D1c0NGzhDk38GWl3Jz5q1Q
         YAVE8A1GB/BpemF3PehrsfWVyGLx1vCtH3YsngVEfqcRhi9+YPgRGYG0xATeQakf
         HVIfH42Ks5Db+qbIX5PdX/z41TkljcGjQagV5kudvXnF0DNKDzVqwMlwubuCP0Ut
         QxcNW98yc5qReI0Pr5yJWdlE5fRwA7dRt504qTCEgqhDK6WEw2+MpzoUpE6FY0Za
         ciOhUwfZuaYV4vSgEyu1YA==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:23 +0900
Subject: [PATCH v4 4/7] hv-balloon: hw/core/register: Do not unparent in
 instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-4-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 hw/hyperv/hv-balloon.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/hw/hyperv/hv-balloon.c b/hw/hyperv/hv-balloon.c
index 6dbcb2d9a29d..2d6d7db4ee0e 100644
--- a/hw/hyperv/hv-balloon.c
+++ b/hw/hyperv/hv-balloon.c
@@ -1475,16 +1475,6 @@ static void hv_balloon_ensure_mr(HvBalloon *balloon)
     balloon->mr->align = memory_region_get_alignment(hostmem_mr);
 }
 
-static void hv_balloon_free_mr(HvBalloon *balloon)
-{
-    if (!balloon->mr) {
-        return;
-    }
-
-    object_unparent(OBJECT(balloon->mr));
-    g_clear_pointer(&balloon->mr, g_free);
-}
-
 static void hv_balloon_vmdev_realize(VMBusDevice *vdev, Error **errp)
 {
     ERRP_GUARD();
@@ -1580,7 +1570,7 @@ static void hv_balloon_vmdev_reset(VMBusDevice *vdev)
  */
 static void hv_balloon_unrealize_finalize_common(HvBalloon *balloon)
 {
-    hv_balloon_free_mr(balloon);
+    g_clear_pointer(&balloon->mr, g_free);
     balloon->addr = 0;
 
     balloon->memslot_count = 0;

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128839.1469071 (Exim 4.92)
	(envelope-from )
	id 1v1HHz-0004aP-99; Wed, 24 Sep 2025 04:39:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128839.1469071; Wed, 24 Sep 2025 04:39: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 1v1HHz-0004XL-2I; Wed, 24 Sep 2025 04:39:35 +0000
Received: by outflank-mailman (input) for mailman id 1128839;
 Wed, 24 Sep 2025 04:39: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 1v1HHx-0003tk-34
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:39:33 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73fc3e63-9900-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 06:39:29 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSmx091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:41 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73fc3e63-9900-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=p0MeB9ovOb3PqHuXUYX0hwqcDvAIFVXeIlzsht53Eeo=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688662; v=1;
        b=LTCUXD0uGPlzR8Pa60OGDZF2aSHGue6kyd2Ye2fG7uK+uilOq14/6lNS7XZ/MHqv
         yeCEKtcHEdSgIBWEK4yEhreziwwT8hweA32gXhao6fR4WuxoVV0pwTW0YcjgGRze
         zKqRaeiZWcNTHJ5YL/kY3ezAkhJqQKVftt29SWB+FTHQ4fmIwizwua2Wpzll4YcY
         86gZkXM5JmqpjsvX87KMH6S7y6t4iKQsv0kklqPtbfd3AGZFovDPCWJMZhAdf3LQ
         rog7FQrQ9kJVXn4NHY3cRcUM0z+5AIUkP+GOPIp2VghG3n3bZLeUQoo920VLYnFc
         skkyPiU+ovb54jjVOFps8Q==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:24 +0900
Subject: [PATCH v4 5/7] hw/sd/sdhci: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-5-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 hw/sd/sdhci.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 3c897e54b721..89b595ce4a5a 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1578,10 +1578,6 @@ static void sdhci_sysbus_finalize(Object *obj)
 {
     SDHCIState *s = SYSBUS_SDHCI(obj);
 
-    if (s->dma_mr) {
-        object_unparent(OBJECT(s->dma_mr));
-    }
-
     sdhci_uninitfn(s);
 }
 

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:44:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:44:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128902.1469093 (Exim 4.92)
	(envelope-from )
	id 1v1HMY-00082t-O8; Wed, 24 Sep 2025 04:44:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128902.1469093; Wed, 24 Sep 2025 04:44: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 1v1HMY-00082m-Kz; Wed, 24 Sep 2025 04:44:18 +0000
Received: by outflank-mailman (input) for mailman id 1128902;
 Wed, 24 Sep 2025 04:44: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 1v1HMY-00082g-16
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:44:18 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f0acf47-9901-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 06:44:16 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSn0091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:42 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f0acf47-9901-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: a=rsa-sha256; bh=ZLD6q50HK2lQwLzxRbQaSBBUwzyTsangDxSOgNJJx8I=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688662; v=1;
        b=HoN1iIkjYTsHEWCTgud6NoTyf1nD5F3t22JXFPqbYILfMLp+Xrv09z7OyGyuwUSk
         YYTcgI7g/+wZoGi91mRCqJFylcf+umFGGjaeZoaPi4MZwGG/W+j/T5X7jHjQYz6W
         ZcIRQ+yOnar0zOtxrCDqHIvyOsXVRnI8GS8sclqgSjFxHKXsPZOliFvo2dR2qGyo
         wwkcnvo1PhlyJ9qEjPaI+Ifqu5GIL1FKT++9yCSM6DDEEwNPND0Loz+98LE4Ta2b
         7OfpePR7t1PFBMnbhLklDPAfrosOVAlQHA/niUjo66Ttb31aBuFGkLYkcPcWkWNW
         jurSTzbiNvWzl9uoid98OQ==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:25 +0900
Subject: [PATCH v4 6/7] vfio: Do not unparent in instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-6-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 hw/vfio/pci-quirks.c | 9 +--------
 hw/vfio/region.c     | 3 ---
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index c97606dbf194..b5da6afbf5b0 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -1159,15 +1159,12 @@ void vfio_vga_quirk_exit(VFIOPCIDevice *vdev)
 
 void vfio_vga_quirk_finalize(VFIOPCIDevice *vdev)
 {
-    int i, j;
+    int i;
 
     for (i = 0; i < ARRAY_SIZE(vdev->vga->region); i++) {
         while (!QLIST_EMPTY(&vdev->vga->region[i].quirks)) {
             VFIOQuirk *quirk = QLIST_FIRST(&vdev->vga->region[i].quirks);
             QLIST_REMOVE(quirk, next);
-            for (j = 0; j < quirk->nr_mem; j++) {
-                object_unparent(OBJECT(&quirk->mem[j]));
-            }
             g_free(quirk->mem);
             g_free(quirk->data);
             g_free(quirk);
@@ -1207,14 +1204,10 @@ void vfio_bar_quirk_exit(VFIOPCIDevice *vdev, int nr)
 void vfio_bar_quirk_finalize(VFIOPCIDevice *vdev, int nr)
 {
     VFIOBAR *bar = &vdev->bars[nr];
-    int i;
 
     while (!QLIST_EMPTY(&bar->quirks)) {
         VFIOQuirk *quirk = QLIST_FIRST(&bar->quirks);
         QLIST_REMOVE(quirk, next);
-        for (i = 0; i < quirk->nr_mem; i++) {
-            object_unparent(OBJECT(&quirk->mem[i]));
-        }
         g_free(quirk->mem);
         g_free(quirk->data);
         g_free(quirk);
diff --git a/hw/vfio/region.c b/hw/vfio/region.c
index d04c57db630f..b165ab0b9378 100644
--- a/hw/vfio/region.c
+++ b/hw/vfio/region.c
@@ -365,12 +365,9 @@ void vfio_region_finalize(VFIORegion *region)
     for (i = 0; i < region->nr_mmaps; i++) {
         if (region->mmaps[i].mmap) {
             munmap(region->mmaps[i].mmap, region->mmaps[i].size);
-            object_unparent(OBJECT(®ion->mmaps[i].mem));
         }
     }
 
-    object_unparent(OBJECT(region->mem));
-
     g_free(region->mem);
     g_free(region->mmaps);
 

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:44:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:44:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128903.1469103 (Exim 4.92)
	(envelope-from )
	id 1v1HMb-0008Hc-Uc; Wed, 24 Sep 2025 04:44:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128903.1469103; Wed, 24 Sep 2025 04:44: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 1v1HMb-0008HV-Rr; Wed, 24 Sep 2025 04:44:21 +0000
Received: by outflank-mailman (input) for mailman id 1128903;
 Wed, 24 Sep 2025 04:44: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 1v1HMa-0008Gs-Sd
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:44:20 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 201c4b3c-9901-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 06:44:18 +0200 (CEST)
Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp
 [133.11.54.205]) (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4bSmv091795
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:37:40 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 201c4b3c-9901-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=kiY10umG59rX3Ai7tv8N39IcOWzLTG5ZJdgQouDTy2w=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=From:Date:Subject:Message-Id:To;
        s=rs20250326; t=1758688660; v=1;
        b=bYISStphDJwegYwwc2rICh89XnoVbrBbd3Jr4ouFuJjLVwyeUjtqjTleQ7UE6nED
         5vJ/TcBEBn6sqzYTNLaB0oj75gpOKIDdYgCYt5vEDn3Mh8WY/o+35Ii2LIHZkf4e
         i53fFpswin9p5Dm26bNuRVKY1LjWr0XkMmbBPdYo07Jdh9cSvgRGW4Nw0i6V/Sac
         oeN0eaoO9HSSEzaOTVMKg4JVUIVXrmZozVIxOLaPkgluMFw3jzAe5zFT85PN1xe8
         yYj56giV4oVv2QBk7zRIo+fuDGTQ5cYYRBMn5TcacbjlD+WA4psk/qNrLJOGp3yq
         4VVjbYMEuou5BrRW0FwIqw==
From: Akihiko Odaki 
Date: Wed, 24 Sep 2025 13:37:22 +0900
Subject: [PATCH v4 3/7] hw/core/register: Do not unparent in
 instance_finalize()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20250924-use-v4-3-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
In-Reply-To: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
To: qemu-devel@nongnu.org
Cc: Alex Williamson ,
        =?utf-8?q?C=C3=A9dric_Le_Goater?= ,
        Paolo Bonzini ,
        =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?utf-8?q?Marc-Andr=C3=A9_Lureau?= ,
        "Michael S. Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?utf-8?q?Alex_Benn=C3=A9e?= ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo ,
        Max Filippov ,
        =?utf-8?q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S. Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E. Iglesias" ,
        xen-devel@lists.xenproject.org,
        Akihiko Odaki 
X-Mailer: b4 0.15-dev-179e8

Children are automatically unparented so manually unparenting is
unnecessary.

Worse, automatic unparenting happens before the instance_finalize()
callback of the parent gets called, so object_unparent() calls in
the callback will refer to objects that are already unparented, which
is semantically incorrect.

Signed-off-by: Akihiko Odaki 
Reviewed-by: Daniel P. Berrangé 
---
 hw/core/register.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/core/register.c b/hw/core/register.c
index 8f63d9f227c4..3340df70b06e 100644
--- a/hw/core/register.c
+++ b/hw/core/register.c
@@ -314,7 +314,6 @@ RegisterInfoArray *register_init_block64(DeviceState *owner,
 
 void register_finalize_block(RegisterInfoArray *r_array)
 {
-    object_unparent(OBJECT(&r_array->mem));
     g_free(r_array->r);
     g_free(r_array);
 }

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 04:58:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 04:58:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128955.1469113 (Exim 4.92)
	(envelope-from )
	id 1v1Ha6-00020P-3y; Wed, 24 Sep 2025 04:58:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128955.1469113; Wed, 24 Sep 2025 04: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 1v1Ha5-00020I-W6; Wed, 24 Sep 2025 04:58:17 +0000
Received: by outflank-mailman (input) for mailman id 1128955;
 Wed, 24 Sep 2025 04:58: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 1v1Ha4-00020C-Ag
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 04:58:16 +0000
Received: from www3579.sakura.ne.jp (www3579.sakura.ne.jp [49.212.243.89])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1220e519-9903-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 06:58:13 +0200 (CEST)
Received: from [133.11.54.205] (h205.csg.ci.i.u-tokyo.ac.jp [133.11.54.205])
 (authenticated bits=0)
 by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 58O4v1bp000967
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 24 Sep 2025 13:57:01 +0900 (JST)
 (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1220e519-9903-11f0-9809-7dc792cee155
DKIM-Signature: a=rsa-sha256; bh=cd/OY0sVpO3j7ySDAUzhckm3Gg6FS6EGdkyaTPK5n78=;
        c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp;
        h=Message-ID:Date:Subject:To:From;
        s=rs20250326; t=1758689822; v=1;
        b=PRIUb/dE2rgiU8IHj/cAJvQVfnrr0YlovEPeKt1e5AoSCmkau4Ac0iUsRz/8ZVLM
         ObxkFsGiMSUSvHeky1/cqtsGCD90eKL4yO5EHz+A8Fef5r83rx0yOtmIth78Rq+i
         ZWRaYUmcs5PTWx4a8vJwr06dU9AB5aG6iNfFpUZ7dGO3iAn8wbfIiNH0d3XB3wsE
         I44oAiJRuPEW+srhS1ToKNlcAOUVozFOOGKDTopBagmreQoy9w5bQrK/m4ZLjdYg
         pUQnI9NzsWQrApAUHWr5pdL+nPLtM29M7I+muPBGNNGcaNXp7ZvDpqB9byLvAdUA
         XfUF6cOFxt3DGWt9EKMR2Q==
Message-ID: 
Date: Wed, 24 Sep 2025 13:57:00 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
To: Paolo Bonzini 
Cc: qemu-devel@nongnu.org, Alex Williamson ,
        =?UTF-8?Q?C=C3=A9dric_Le_Goater?= ,
        =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= ,
        Eduardo Habkost , Peter Xu ,
        David Hildenbrand ,
        =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
        Richard Henderson ,
        Helge Deller ,
        =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?=
 ,
        "Michael S . Tsirkin" ,
        Gerd Hoffmann , John Snow ,
        qemu-block@nongnu.org, Keith Busch ,
        Klaus Jensen , Jesper Devantier ,
        Marcel Apfelbaum ,
        Nicholas Piggin , qemu-ppc@nongnu.org,
        John Levon ,
        Thanos Makatos ,
        Yanan Wang ,
        BALATON Zoltan ,
        Jiaxun Yang ,
        Daniel Henrique Barboza ,
        David Gibson ,
        Harsh Prateek Bora ,
        Alexey Kardashevskiy ,
        =?UTF-8?Q?Alex_Benn=C3=A9e?=
 ,
        Fabiano Rosas , Thomas Huth ,
        Laurent Vivier ,
        Peter Maydell ,
        Aurelien Jarno ,
        Aleksandar Rikalo
 ,
        Max Filippov ,
        =?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
        Mark Cave-Ayland ,
        Artyom Tarasenko ,
        Alistair Francis ,
        "Maciej S . Szmigiero" ,
        Bin Meng ,
        Stefano Stabellini ,
        Anthony PERARD , Paul Durrant ,
        "Edgar E . Iglesias" ,
        xen-devel@lists.xenproject.org
References: <20250923080853.94322-1-pbonzini@redhat.com>
Content-Language: en-US
From: Akihiko Odaki 
In-Reply-To: <20250923080853.94322-1-pbonzini@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2025/09/23 17:08, Paolo Bonzini wrote:
> Queued, thanks.
> 
> Paolo
> 

I sent v4 to address comments in the following thread:
https://lore.kernel.org/qemu-devel/aMxlpfp_LSgiIk9Z@x1.local/

Regards,
Akihiko Odaki


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 06:39:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 06:39:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1128983.1469122 (Exim 4.92)
	(envelope-from )
	id 1v1JAA-0005Vu-Tx; Wed, 24 Sep 2025 06:39:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1128983.1469122; Wed, 24 Sep 2025 06:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1JAA-0005Vn-R3; Wed, 24 Sep 2025 06:39:38 +0000
Received: by outflank-mailman (input) for mailman id 1128983;
 Wed, 24 Sep 2025 06:39:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1JA9-0005Vg-IV
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 06:39:37 +0000
Received: from PH8PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170120001.outbound.protection.outlook.com
 [2a01:111:f403:c107::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3bd1afd1-9911-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 08:39:35 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DM4PR12MB8523.namprd12.prod.outlook.com (2603:10b6:8:18e::13) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.20; Wed, 24 Sep 2025 06:39:31 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 06:39:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3bd1afd1-9911-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KK359Zcq1bLL8rCrslV8sVs1H23zML6iUVS8YOfVa7fZsWTysCUXilJz3bOGNX3oAf4gOPFB08sE2gvYZyEP/d4CaoLwrcxvj7iiVrS5gIP0L4mY3IryFBOQEwyO7sdFl/RvMm/gbGhoDcImmt3nJIoUsNSL2pb8q3Eu4FCNlSqej4DZpD48tty1p6hj18SFo9OGQtq5pdLZiQCr+K075AuVBZLKVKEDr8SaoW52DcvqsrA8A4L2+SiohZ8XDVrXSJD5fw7CBOJ1MDRpBr19NtziDZihkcj9UwACFYeo4DPP0CHTdAQaNraBfil0xVUTOrmjwVtBn0YW3wUiDCL49Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lptSSdVNYZRu2s6aCMuWaga4bKrS3C8zZyyGgUczNx4=;
 b=CIRQkeaUf3KvZUvRaBZ0+e01fovmmLlVN8UZNtODoqnJrWAbmuSB5wX5Tf1zhZPGtjCy1jqrzCxXBtqAj+HC4uDTBlrJmiVMXv+oRZJ8YzE4fbOpamaobAi+Ngem+t64T2ijW80EByeA1U3U61mI3DwvAeXAGP1KNKf50wXrcHlMPeulfSC0ndeYRvOm6zEyg+gVSBcSs863VVSxXF1M04wyH02iaYrQG5xChXTjb6LBLznION4Ofk72k2N3DLzYBvIQDSLaIandzLz28xKU2ZBTbBBl1GuKxbjfxvAOc1lNPwgI9hahjg2QUXFTWxmBLnlxyXXQw+uA8Dxs6r1WXQ==
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=lptSSdVNYZRu2s6aCMuWaga4bKrS3C8zZyyGgUczNx4=;
 b=P2J9k2S+Hmg09qNViW9D6Al4/vWeNqVfcsWZP4oWvb5ckOHB34b8xz26YVSHwQdGoNri/b/hZ6k+A1AuFG5HMaIQDRTCxx9u5D4s7AdRFf74Uji3+0HuBD6KQKgcvmmm7P3hEZ6AcdFVq7Yc184wnheQaDFC+5q8kuZ6OyWgSDY=
From: "Penny, Zheng" 
To: Jan Beulich , Tamas K Lengyel 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Alexandru Isaila , Petre
 Pircalabu , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
Thread-Topic: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
Thread-Index: AQHcIiYDHxl9uXccpkex+vWb0p4h67SMggMAgAVG3ICAAPOvgIAPObqA
Date: Wed, 24 Sep 2025 06:39:31 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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-09-24T06:39: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_|DM4PR12MB8523:EE_
x-ms-office365-filtering-correlation-id: 1a6fbac4-2311-44b5-99c6-08ddfb351e3e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?VUNUT2I3VWwvc1Ava2FNWWtiQm5nWldhTHpJa09ET1p1TlNKUXpMamNUQ3E2?=
 =?utf-8?B?ajhwZU01dzQwQ0M1QnVIRVVnVFVxbDhZclhvUmRQYTFjbTIwQS8vcVhkNEZj?=
 =?utf-8?B?UWcxcXF2cklEbUpmbU5DYnpYNFJsU2U2NDlCOWVLUHpxQmVJK3oybXkrUTdB?=
 =?utf-8?B?LzU5WXN6ZHVDRGpDeXVrQUtQQ3pla1VOalkrZVJvWEE2QnRzTkhpSFVFOS9Q?=
 =?utf-8?B?eTY4aFBWTC9lTW9SancvU2JGQkxpV3JuZ0g4b1dNQW42a2ZjRXVvNEpLZS9Z?=
 =?utf-8?B?dU9sL1o2U3BRL29qOHk3S1prSTF0L3h3a3N0OFJhNnpocW10ckU0aUFocGRI?=
 =?utf-8?B?TGx6Ym1VQjF1L1VBcmRVb1VvcUtHOHBKUEFhcFhxZEZFUmFGRGdjQkpGMFds?=
 =?utf-8?B?SGhDMHcvclJxaVRjSXdyOStjTmphb05tZW16TXA0YVFjZGxtMGRlMmFiWWQw?=
 =?utf-8?B?TWZDdWk0RXpXWVZnSS9OY2xWY0dlSkNjd3lqOXphMGtHaHZHc1J2dkJXVHJ4?=
 =?utf-8?B?Yk1pQlZIUnAzZEtrNHl5ZzNNVGhLY2s2ZmY3YW1uejk3TDhSSjFvODlWMFFQ?=
 =?utf-8?B?UFVkbTVTOVZ6V3FwNG1RVHkrdHRUb1huYjVaV0ozRW01WmlWaS83QTFRN3pH?=
 =?utf-8?B?VWpnZWwwcXZQTXJ4U1pjMUYxeUdWY1ZaN084RmJ2VmREdmJWRU9xMm9pNjhu?=
 =?utf-8?B?blFhemVqdEovUHJ1Wm9mS08rTmt1TmJSdFJjTFhWMk81aHE1c0Z3QlFWbkxr?=
 =?utf-8?B?N0Z1elMxZW9kNUpUK0lmQit5VS9wV2M1OUc4TGRsUEdpUEVBelVrRFdjQmZi?=
 =?utf-8?B?MHlGSm5XejVCR09UOGNremxYV1NhUkRiMkRuN3d5QTlqN28zRmFMczFzSElO?=
 =?utf-8?B?QTNkenMyQlNmeEs5Wk1HZ0xSN2YramF1d0NOdVVjdS96YzVPNk1QRVpBZHgv?=
 =?utf-8?B?OUZudjNuTVBYUEl6TS9RSWhVWVJISmRVeUw4cGlIUXUweTV5QklDY0lzdFZU?=
 =?utf-8?B?YkdkM1pRVFFSSXArdnc4WGtUajA5a2t1UDhDRUtpY2s1bU5GVjhxejhmT2VJ?=
 =?utf-8?B?dUtyTW9ielVSTmNMaDN1YTFXall6OGwzQ0tHODVWNXJ5U2JsRGFwN3pYWUFj?=
 =?utf-8?B?Smc3SFkxTCtLWEZRYUk4czZoQVpicU1ra2tXbnk0OXdUT09CZU5UaXBtT2VX?=
 =?utf-8?B?aHl5S2t0ZWRPWThlOFIrcUNvRkFHZGhNWnZkWmF2Q2xTQ3Zmb3VDTFJPZk9m?=
 =?utf-8?B?c2FJbWlpdkNjQWhzVXJ4TW9id2krd0Y4THdGUXdwM01YNGNtTW1sSmZJNWVR?=
 =?utf-8?B?TUZDVkQ5S0lhR1crR1oyZElMNE9TTGQzZWZDN0hxQVZ6MDc3OEd1ZFJmRzBO?=
 =?utf-8?B?WjNiQ09QOGpzYk1MM21GMkZCMDhYSGo2bDZTTlFKZFVIdzBMVlZDTzBrbHc0?=
 =?utf-8?B?ZU81OU9vZFAveDVpanU4TUIxcW96dHdhakpKY0VMR1VsbGZObGVyZDEvRk84?=
 =?utf-8?B?bGFHQmtXVzZHbnNwekdVWWVOQUlqZGVKOGprVHc0MWpheTNlYU1PUWJWZmg1?=
 =?utf-8?B?cjVaeC9BUGljS3BRalUrWGpNenU4djFDMkErY3lQVWJzdmRpNWNmOUdDMDlZ?=
 =?utf-8?B?SkpoT2dsR2loWHA0Q1lpMUtndERsamtpQnFLdGI0U2tNckhicGlWdkRPT3Z6?=
 =?utf-8?B?bjVmc2VoYms4a2hiVS9ONG9JenFzbUFUOVZ1bFhoUWpTRjA5Z0UwZktzY1Fn?=
 =?utf-8?B?aXZROW5RWHFYaUdoalNvRmQ3TE9zMFpEL0lXeFpteFRQSlBBd0Z3ZWVUbnBy?=
 =?utf-8?B?M1QwWHRXcm5UMS9sSlRDaVByanhjVUFzZW8xb0xyQTBtU2I3enpIMjJUZFpv?=
 =?utf-8?B?dnVEMk0wVGpDSXhtSkNQVVgrcThDNy9GOE0rKzFETlhzTmkwRDVvUUpraHNZ?=
 =?utf-8?B?cDd4VlhsYkc1VTZvQ29LMDc3dkFQYWt3Z0xSY0pNVlpPeE5tOUdFUktTU0lI?=
 =?utf-8?Q?U5G7axBGjD9VX5IOQAcg3Rcy0p+UgA=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RHA2ZVBicCtMQkJIcTgxblRHYVY0NHFQelY3Q2VCOVkzTmI5VytXa2UrL055?=
 =?utf-8?B?VllJQVROL2J3enZxeVRmZTJZSG5tVUp2Q1BTUkRNRzg2N0FHbXROUVBmT0Jo?=
 =?utf-8?B?VElxQVhhMmFmb2RMSldMNFBtTGpqcExOeDVjMUJ3RldmYzlTbGVvYUJodVZ0?=
 =?utf-8?B?QjdveEtFZE1UeXo4dzdpYk4zV0dPckQ2aUxnekVzUFZITHZBVHNlRCtSSldv?=
 =?utf-8?B?VzVYOElmTy9VOTBrRUtGWnZ0cVhBanpEZWUzYnU4bkQrVHVWSHlscm9aenpB?=
 =?utf-8?B?KzI3OTFQN3E1b2d3dW5FK01UNU1hOWRnQmdOMEY3QVQwY3ZOc1U4MGtxTUVZ?=
 =?utf-8?B?VDUyN3F5bW5iRXlNYVVGcWF1QmJkeEEzeGRTa0pwUndPRjAwY0V3VVYzbTd6?=
 =?utf-8?B?QWQzQ2ljdjdsZE9YclVidHJ6SDlKOEgwcVdIZUhlQW1CU0M4aU5UcWN5czJ5?=
 =?utf-8?B?ZWgxaWRkb1E2S0NhSWNEYTZubWNNT2svRGpzUGhsUCtUTUc3bnRuVXBDaUY1?=
 =?utf-8?B?RXFPT3VEWTlqeVgwOGZxN2NRSDhmbFVGdjVxL3pvNjJPck42NzJHcG5OOHdW?=
 =?utf-8?B?NlJlOXZMZURaRVg1TjgzamFwWklVRGI0RmpuejU5MmZ0eXZ5dkpUd1BVTGhY?=
 =?utf-8?B?Mmx3SDFiZ3RSVFp6Y2dVcS9SU1Rkd0wyMm8wRExKek1jbDFCR0dmWmwyL1RT?=
 =?utf-8?B?Smk1UjJNYml4MFhvSVNPZUYyMVdIQ2ZyakM4TXNKWEhnNTd5WkRITFFsdHFl?=
 =?utf-8?B?dFd4a3ZWNkdIck5oRjJEUlVleHdwQThrOXBrcjlNeTZnYlhIUmNCTHZzbGlF?=
 =?utf-8?B?QzZJUzl3T2FoRkVRVkJlMDJOeXRVL0Vyd1RibnVyNFhkM3lVRXF2R0pTYzZZ?=
 =?utf-8?B?UGVBaXZUY21HWm9iTktITlBpeFZpb1JRckNRcVJuUUhsYmEwbFNES3EyYjlw?=
 =?utf-8?B?Qmdmdy9sM1JyWlMyNng2ZGVFclRNREltUmtQRWFkS0Y3NklYNHpVc1I3eTdi?=
 =?utf-8?B?bFNVVHBYcDJwejRlSzBCYit1ZU1MR21KR2ZCbVI5SjRRV2JLWlFLb3I0UGpJ?=
 =?utf-8?B?TFl0MEtyMDVWOTBvaEErTVdhY2V1WkVyUlp2cXFOaWJ1VWl5eS9WV3hTdERy?=
 =?utf-8?B?eTA4TUNlSmxUNzdPaWpwYXNmbGo5WHN0enIzdmZtS09QM1FPZVFoT3JZYVE0?=
 =?utf-8?B?aEkrQU5BbUo4R01lSUxxQmNRdkl1RFJWWTliNjREZDllczg0K0FmcnJnUVpx?=
 =?utf-8?B?ek1BeFExU0dYSmRpQWxPUWE4YzlqMUM4ZUwzV0pJaDdxMkVmNnRWY0RWajlw?=
 =?utf-8?B?cmRYbzlxZkxJdWxIU3VvNEVWb01jWE9WMnR2QkNocHJtVjFnNjBURTR2YlRx?=
 =?utf-8?B?NCtjNW10TFBuVXdWcy9sK1RDNEJyMlVtWlJKSTg5bzBHUFZXd2Q1SjE1TlQ4?=
 =?utf-8?B?K0lTT3IrSzdLZ0dmeDM5S1NoWWtIRTlCeDd3Vlp3NDc4citxUksyYmVvcHRw?=
 =?utf-8?B?cGZ1czdOeHphOVUwT3JOS28vQi9RZzVkbDJhVjlJbW52eU85Q1IvTTBKY1Jv?=
 =?utf-8?B?RmtJUWdGNVRPeTAwUmhYdlc5M0grdGxVRm5KSjBJcDNrOW1jWjlQT1RrL3RY?=
 =?utf-8?B?bVRiMEdDZXB3ZC9rbDNSS0lFUzZ4Unk4SXpMcm1nRVN4NUhWSFUzUHVLMXBV?=
 =?utf-8?B?RWxMRkNyTTMyUGpJWHltMzVjYlFUaXRrSkQzV2lncFhFSVVyOTZnT01STDF5?=
 =?utf-8?B?ZFpLNzlNcmtyaEMwMGhnUWJIdi9CcW51OExteG10L1E4aGhQTkJwTnNtM0Rh?=
 =?utf-8?B?UnN1TXpYVTl6b0h5Q2t6QmdQMTByRXMwSmhRQnRtUjdLRG9TOHFqbnRiaDF4?=
 =?utf-8?B?bGl2RjNkZE9RTGNEcGZoYlpoZTRWT0FjeTlPUzg0YXhHSmRwZWhQejVmNXpP?=
 =?utf-8?B?b2hWUXZ2UW5EMUZyY2x6S3orU284dDk2QW53QURYQ2dzZzRKWGMrTVlESzJq?=
 =?utf-8?B?RXpsbDZnRXp1aFg1UDlSL1orZ2R5ODc4N0xMUURtdVU4dEN5bGNnT0J3dllv?=
 =?utf-8?B?RVlaMENmdis4U2piMmFLWFozSGlUSHRXQ2owWmZhSnVPRFZ1TzBWdDNJdnk4?=
 =?utf-8?Q?tvHo=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: 1a6fbac4-2311-44b5-99c6-08ddfb351e3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 06:39:31.5232
 (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: eSOWZxPlEdgDytiOsMW8cNKRKIz4Mfe7HyT2h6SQ7xPX2RsLbIgRMatTP+9Rh9bM8f4o47oWlyQtoY1IfbJQaw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8523

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBTdW5kYXksIFNlcHRlbWJl
ciAxNCwgMjAyNSAxMDowNCBQTQ0KPiBUbzogVGFtYXMgSyBMZW5neWVsIDx0YW1hc0B0a2xlbmd5
ZWwuY29tPjsgUGVubnksIFpoZW5nDQo+IDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBDYzogSHVh
bmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+
Ow0KPiBBbGV4YW5kcnUgSXNhaWxhIDxhaXNhaWxhQGJpdGRlZmVuZGVyLmNvbT47IFBldHJlIFBp
cmNhbGFidQ0KPiA8cHBpcmNhbGFidUBiaXRkZWZlbmRlci5jb20+OyBEYW5pZWwgUC4gU21pdGgg
PGRwc21pdGhAYXBlcnR1c3NvbHV0aW9ucy5jb20+Ow0KPiB4ZW4tZGV2ZWxAbGlzdHMueGVucHJv
amVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAwNC8yNl0geGVuOiBjb25zb2xpZGF0
ZSBDT05GSUdfVk1fRVZFTlQNCj4NCj4gT24gMTQuMDkuMjAyNSAwMTozMSwgVGFtYXMgSyBMZW5n
eWVsIHdyb3RlOg0KPiA+Pj4gQEAgLTk5LDEwICs5OCw0MCBAQCBsb25nIHAybV9zZXRfbWVtX2Fj
Y2Vzc19tdWx0aShzdHJ1Y3QgZG9tYWluICpkLA0KPiA+Pj4gaW50IHAybV9nZXRfbWVtX2FjY2Vz
cyhzdHJ1Y3QgZG9tYWluICpkLCBnZm5fdCBnZm4sIHhlbm1lbV9hY2Nlc3NfdA0KPiAqYWNjZXNz
LA0KPiA+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IGFsdHAybV9pZHgp
Ow0KPiA+Pj4NCj4gPj4+IC0jaWZkZWYgQ09ORklHX1ZNX0VWRU5UDQo+ID4+PiAgaW50IG1lbV9h
Y2Nlc3NfbWVtb3AodW5zaWduZWQgbG9uZyBjbWQsDQo+ID4+PiAgICAgICAgICAgICAgICAgICAg
ICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fbWVtX2FjY2Vzc19vcF90KQ0KPiA+Pj4gYXJn
KTsgICNlbHNlDQo+ID4+PiArc3RhdGljIGlubGluZSBib29sIHhlbm1lbV9hY2Nlc3NfdG9fcDJt
X2FjY2Vzcyhjb25zdCBzdHJ1Y3QgcDJtX2RvbWFpbg0KPiAqcDJtLA0KPiA+Pj4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeGVubWVtX2FjY2Vzc190IHhh
Y2Nlc3MsDQo+ID4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBwMm1fYWNjZXNzX3QNCj4gPj4+ICsqcGFjY2Vzcykgew0KPiA+Pj4gKyAgICByZXR1cm4g
ZmFsc2U7DQo+ID4+PiArfQ0KPiA+Pg0KPiA+PiBTbyB0aGlzIGlzIG5lZWRlZCB3aGVuIFZNX0VW
RU5UPW4gYW5kIEFMVFAyTT15LiBUYW1hcywgaXMgdGhpcyBhDQo+ID4+IGNvbmZpZ3VyYXRpb24g
d2hpY2ggbWFrZXMgc2Vuc2U/DQo+ID4NCj4gPiBZZXMsIGFsdHAybSBzaG91bGQgYmUgZnVuY3Rp
b25hbCB3aXRob3V0IHZtX2V2ZW50IGJlaW5nIGVuYWJsZWQuIFRoZXJlDQo+ID4gY291bGQgdmVy
eSB3ZWxsIGJlIGluLWd1ZXN0IG9ubHkgdXNlIG9mIGFsdHAybSB2aWEgI1ZFLiBUaGlzIGZ1bmN0
aW9uDQo+ID4gaXMgdXNlZCBpbiBwMm1faW5pdF9uZXh0X2FsdHAybSB3aGljaCBtZWFucyBpdCBi
ZWluZyBzdHViYmVkIG91dCBsaWtlDQo+ID4gdGhpcyB3aGVuIHZtX2V2ZW50IGlzIGRpc2FibGVk
IGJyZWFrcyBhbHRwMm0uDQo+DQo+IE9oLCBpbmRlZWQgLSB0aGUgc3R1YiBzdGlsbCBuZWVkcyB0
byBoYW5kbGUgWEVOTUVNX2FjY2Vzc19kZWZhdWx0LiBPZiBjb3Vyc2UNCj4gd2l0aCBNRU1fQUND
RVNTPW4gaXQncyBub3QgcXVpdGUgY2xlYXIgdG8gbWUgd2hhdCBwMm0tPmRlZmF1bHRfYWNjZXNz
IG91Z2h0DQo+IHRvIGJlOyBpbW8gaW4gcHJpbmNpcGxlIHRoYXQgZmllbGQgb3VnaHQgdG8gYWxz
byBnbyBhd2F5IGluIHRoYXQgY2FzZSAoYmVjb21pbmcgaGFyZC0NCj4gY29kZWQgcDJtX2FjY2Vz
c19yd3gpLiBXaGlsZSBkb2luZyB0aGF0IHdpbGwgYmUgYSBsYXJnZXIgcGF0Y2gsIHBlcmhhcHMg
dXNpbmcgdGhlDQo+IGhhcmQtY29kZWQgdmFsdWUgaGVyZSBzaG91bGQgYmUgZG9uZSByaWdodCBh
d2F5Lg0KPg0KPiBPbmNlIHRoZSBjb2RlIGNvcnJlY3RseSBoYW5kbGVzIE1FTV9BQ0NFU1M9biBh
cyBhbiBpbXBsaWNhdGlvbiBmcm9tDQo+IFZNX0VWRU5UPW4sIGl0J3MgYWxzbyBxdWVzdGlvbmFi
bGUgd2hldGhlciBNRU1fQUNDRVNTX0FMV0FZU19PTg0KPiBzaG91bGQgYmUgcmV0YWluZWQuDQo+
DQoNCklmIHdlIGludGVuZCB0byByZW1vdmUgTUVNX0FDQ0VTU19BTFdBWVNfT04sIEkgc3VnZ2Vz
dCB0byBkbyB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbiBvbiBWTV9FVkVOVCB0byBzdGlsbCBr
ZWVwIHkgb24gZGVmYXVsdCBvbiB4ODY6DQpgYGANCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL0tj
b25maWcgYi94ZW4vY29tbW9uL0tjb25maWcNCmluZGV4IDdiZDhhMDQ3MzAuLjYxZDQ4YTUxMjAg
MTAwNjQ0DQotLS0gYS94ZW4vY29tbW9uL0tjb25maWcNCisrKyBiL3hlbi9jb21tb24vS2NvbmZp
Zw0KQEAgLTE3MCwxMyArMTcwLDEwIEBAIGNvbmZpZyBIQVNfVk1BUA0KIGNvbmZpZyBMSUJGRFQN
CiAgICAgICAgYm9vbA0KDQotY29uZmlnIE1FTV9BQ0NFU1NfQUxXQVlTX09ODQotICAgICAgIGJv
b2wNCi0NCiBjb25maWcgVk1fRVZFTlQNCi0gICAgICAgZGVmX2Jvb2wgTUVNX0FDQ0VTU19BTFdB
WVNfT04NCi0gICAgICAgcHJvbXB0ICJNZW1vcnkgQWNjZXNzIGFuZCBWTSBldmVudHMiIGlmICFN
RU1fQUNDRVNTX0FMV0FZU19PTg0KKyAgICAgICBib29sICJNZW1vcnkgQWNjZXNzIGFuZCBWTSBl
dmVudHMiDQogICAgICAgIGRlcGVuZHMgb24gSFZNDQorICAgICAgIGRlZmF1bHQgWDg2DQogICAg
ICAgIGhlbHANCg0KICAgICAgICAgIEZyYW1ld29yayB0byBjb25maWd1cmUgbWVtb3J5IGFjY2Vz
cyB0eXBlcyBmb3IgZ3Vlc3RzIGFuZCByZWNlaXZlDQpgYGANCg0KDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:12:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:12:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129004.1469132 (Exim 4.92)
	(envelope-from )
	id 1v1JfZ-0001yE-F5; Wed, 24 Sep 2025 07:12:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129004.1469132; Wed, 24 Sep 2025 07:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1JfZ-0001y7-CN; Wed, 24 Sep 2025 07:12:05 +0000
Received: by outflank-mailman (input) for mailman id 1129004;
 Wed, 24 Sep 2025 07:12: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 1v1JfY-0001y1-SJ
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:12:04 +0000
Received: from CY3PR05CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c112::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c20a3d4a-9915-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:11:58 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DS0PR12MB8295.namprd12.prod.outlook.com (2603:10b6:8:f6::21) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9; Wed, 24 Sep 2025 07:11:53 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 07:11: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: c20a3d4a-9915-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cUeZhW3QL7ad4HsMbB2YvYHy3+A0Q+BCOHCrsPLWwzPKKa8fQQC0eG4btCdKv89zHomQq73zmYaYjRsfnFaG5jgn4s89WPdennKhxFHgjmGZGElzCr8ybBlcD6rn3CQpY7puFMajCumROeu7N6bOsiQuI51OQ4uMw1OeFqee1no4DexSCbA3Lbwbs9lIqRk68shyVgO7SHDp2MvW6RgIwYIqA9MdTpbSlSTrzq7hvJRwMBYJqm8sUgZwQseCH4Rn0cETuJx0sk6+nG/eLa8HORftA+auFeEPCy4kSFneYS9XZeGcR0XvbS8mCf+mrCvhXvKGomtmpj29/HgjDlRbOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kwdAdAa7M+69MdMkwP13EIIAqpDEPr/avoIE8DCxgCk=;
 b=T7Fuox2SxeudGD/WzIG6qGd/YpXZW6wvPrrNZU4Y7AZ6fMTPwsv+lez4+1sJj4rGtyWQoCxwzHxphx4POmn/B254Vp/Pf8QajKGD2C2Oi71arLG2KGVb//yoq9Be6Ap7LZFLQxA3Iz8Otc1coJA0NDA0oJT3GEnYoS5PNAPvwwPmd/T1jJJYnrfBsItEXAa8JAndRRWq2uy+K+rRgotdhj6A8HD130aQ3YuBcMeTRZZ55219nGDNvEDlQAI7oEY/aRL4G8vy1wbbqWe/80WPGsAO4irU7sv97nEvJ1ioCoPyLxb9cPdiJV5VMOmakRe9Aj2KBpVLTGO3k9ueaK+h6g==
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=kwdAdAa7M+69MdMkwP13EIIAqpDEPr/avoIE8DCxgCk=;
 b=1KbhTfyvymjYTyFl4CbZX4gYQIOTMtcBCGVnfOQ0OJrUCItV5rm8f0O0cD6pTW9/hLOObaAoH1omACdF91xr+m2nZeH67jUrBpqmHDwUbADD1jAW8EOs3K1OVYgaLdHuo9ky34MT1SJXG+ad6IF7qUi2YHRTMoB5aO4wWN1atFE=
From: "Penny, Zheng" 
To: Jan Beulich , Stefano Stabellini
	
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v2 07/26] xen/domctl: wrap
 domain_pause_by_systemcontroller() with MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 07/26] xen/domctl: wrap
 domain_pause_by_systemcontroller() with MGMT_HYPERCALLS
Thread-Index: AQHcIiYFaSMS8x+uC02GcRYZiIpQDbSMhVsAgBV2NTA=
Date: Wed, 24 Sep 2025 07:11:53 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-8-Penny.Zheng@amd.com>
 <99737b48-2f14-4d49-85f8-5acd4a434dde@suse.com>
In-Reply-To: <99737b48-2f14-4d49-85f8-5acd4a434dde@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-09-24T06:53:35.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_|DS0PR12MB8295:EE_
x-ms-office365-filtering-correlation-id: c18e2d21-1356-45e3-2e78-08ddfb39a3be
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bVRRaFNUZWJ4b05DTlZjNjRPeUpvYTZIQzMzQzZaMlhuKzBDbnpJWnJDcHFa?=
 =?utf-8?B?bE9udDA5dVM2VHZlemNFdUdZY3A5dXBtdnhuZHpRWDFJNkVGWHBCaXNlRllL?=
 =?utf-8?B?L0dYdXEzRWZKWEQrUXZkSGlhQWljRkhkSmhXNVp1b2FGMC9RVTJVb1lXbGVS?=
 =?utf-8?B?T0Z1aEI2RWl0TWVrSk9Fa2JCOGx1U1Zpa05qWCszRUdvWWxlUWhpd1I4NXRl?=
 =?utf-8?B?Z1dmaFJEcWtQUHM4MGF3ajRONCtNbXBSZ01wVDZiTnJ5aUZZcmJvbGFPVFFz?=
 =?utf-8?B?ZW9tVXpFRFY3cnNZamZiblM1cFNGTkR5QUR3bnY0NGZuMzZrVjkvNWZjQjdS?=
 =?utf-8?B?eUdKVnFVVTF6Q0RicWZaeUt6YnBYUFFzVEN1M2tpRjdPWDZqTG9hNjV6aW80?=
 =?utf-8?B?MUZSSjNOQlBoQzgxZS9oalV1eGJwbGE3TkxMTU4xN2pvT0FrdXhyeDRSSmMx?=
 =?utf-8?B?R2k0bkJiNXpKekc2NjZHUFJyblVRWFpXUjRMZDZwZTRzZ014ODhNbmVIRUxG?=
 =?utf-8?B?bzFLdWFTeTRXSWNNMjVnTkk2Wk91ZW8rYnFEcUoyQ1NhMUo2VUs2Yk1NTGEz?=
 =?utf-8?B?YzJvZkZVZS92UUhDdi9QU2JFaVh3U09TKytncWFYNWszMHBOY2l3TU1VUDVw?=
 =?utf-8?B?ckdHY0tITFI4a1ZSYkNxeUhxYmhvaXVkSmhYTUJYVTNiU3JaNjQvamZSbGxo?=
 =?utf-8?B?emZEdTI2VEFiQW1qUHg1TXpNWmJWK2xPT042T0ZLQnluTHRzUHEvMThJSHdQ?=
 =?utf-8?B?RWVDemdqSEZyZVlSZ2Y1NzF1M3Q5U0lGQkNkQjRISUJCR0xKQmU3ekN2T2xk?=
 =?utf-8?B?YjdmcFB3VU1OV0JMQmt2ZHhLLzJuekFKeGJVdGd2Z1VyYWxia0NQMEhWM0Qw?=
 =?utf-8?B?dXpKMlQzS28rNnUyODU2UTBId2UvdlhvMDQvRS9uN0R6MWt3WUJoYm1sNWNE?=
 =?utf-8?B?ZGdSMnBuRXdROTNmS0hoUE81R2tEVlBXaDFyeFp6SWU4YVVVb2RUZmRUa3Qz?=
 =?utf-8?B?TFo4ZmNOdWx3RmZSQXNXVVJucy8wRU9xYWFKTlROdE5wZFptQSttTUpacTRM?=
 =?utf-8?B?dzhMWWdhaEx3WVVQbzdKS0xwRjAvVXF4TUdwQlVCRFdCcW1Ib3V1c29aaU5Y?=
 =?utf-8?B?ejZONUhpbWRBWFhOQkpYU1dpU0lOeEN6eXhIY1YyclRQSUloZ1hJNVFMcWsr?=
 =?utf-8?B?ajA3b0JOMjZ5ZWFUN1kxK1JJT280UVJ3by9rc1lUcUUybFc0V3JQY3NZTm1H?=
 =?utf-8?B?ZzdMalhINHJmdDdySUxEdTloZW9ybmxEbVZQako2Q1lGK0hldmFyaktZdTk0?=
 =?utf-8?B?UWlhc0VBU0pCYUJHcjNDemdpUHpZOFRHdWRzYjY5by9rdUgxWWlNK3hXa0ZW?=
 =?utf-8?B?MXNheVN4S21xSFVmOGViY05uZnV2U0JXcCtaaXh0bXE5c2xzaUJrNnd1RjRa?=
 =?utf-8?B?WmFyMFd2aytVeFoxNURBL1VUQzJNWStNa1NEYkQwc0Q4WGxpOFRmNU5Kb1pV?=
 =?utf-8?B?V1lKcHZnZXQyWDQ3RnpMVWdURFR4RjB4SHdMVHAzRGFtZTFKVU9sOS9yMmF0?=
 =?utf-8?B?R2Z6dE5DNnBCMG96S080TUJKQU1CeVM0am9MbW0rYzFNbVNYUlVSenhHUDdN?=
 =?utf-8?B?NjlmblNUOW1Sb3MwZWd5SWxKZVJKNnMweUE1YXkxVzBwT2dLOFVKaVhVNGc5?=
 =?utf-8?B?ZTArRldHL0dxNzRuQ01ublVSaHZHaGYrckNUYi80bHFsdjFiamptU25aSStP?=
 =?utf-8?B?REloUy9UWVBkNlcrcm1reGFMVDBYRHpJZlp0N3B2QlZVTTI0MWFsWCtKYlgy?=
 =?utf-8?B?NHZuYTh3UlY0blJSdlduY3YycUF1U2xEdWs0WG1VWTFxZTArTEJtWHVDSDYy?=
 =?utf-8?B?VXhpK0hLQXpmOUJDeFNLSXVkQkpWeTJxbUFrSllrQ1lpZVRUbXZXYVZ2Zi93?=
 =?utf-8?B?WDUxMDNxRUozNWE2ZmpMN29HalE4Z2VYSzhIVUZaMFRmOUYyY2RMRXZucGNm?=
 =?utf-8?Q?WOCic1f3Up8ZOkw0SZRZ+XFWV/S208=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TE1zcUllOXk0ZVRHaFVOelpRVTFtd1M2U0RxcXVBZy9UM0hiczk1S0RKNDN6?=
 =?utf-8?B?QUpyMWxKZEFKS0pBTHdNWHpzU2Rha1pMOTVTTjFaU3FxZUl3MkpzeE4wTWpj?=
 =?utf-8?B?Um1jb3lod1ZmbGREaWVyNXc1ZUg2QS9udGtDdUxOeVViQVMyYjlyZHdSL283?=
 =?utf-8?B?VjBYV2ROU2NkN0NMbmN0OFlrYVRJS2FRTk1CL0xMTmdkQnZ6UnlJNTlac3Bv?=
 =?utf-8?B?aEs4RktEZDBkWktRU0g3SWxIL2dLWTlnZ0VscFo1MWYzK09GamNJY045aUlo?=
 =?utf-8?B?cFZzblN1VW84Z3IycXY2WWZwSFNqL0RFOHdkV1FXYkxFK2Z2OERBQUQxRVVy?=
 =?utf-8?B?WStCK3V4YnI3dlI0V2pBaVR4QlNsOEw4bnAvSGd6RThnMVE1R2hoeHVZOFFJ?=
 =?utf-8?B?Z2tJR3kxd1BTUGRLRFE3ZHdVYUplUmo1Y2JBeFp3OXpQWHVYWngwaHZvdlpm?=
 =?utf-8?B?VFh4eEVvbGVYWWhYem5nUEw0b2RWeTFoektGVUVNVk1lMzBDZ3ZvUjdQYng0?=
 =?utf-8?B?ZUN1Vml2ZVZKa0hmaFMvb1NhbUF3L2YyQkIzMVh6TlZLRUl0bHFzK3hqS3Uv?=
 =?utf-8?B?blpERzFId0t3VW8wY0hsNlp4bmpEWE4wekdBZHZMLzVUUXFOQU1Ea2l6Z0d2?=
 =?utf-8?B?WXhOa0loRURwT0VYbFRTSGw1c2Mrejd0U2dyQSs2Z0xzdnlSTDM0UmtTWTVE?=
 =?utf-8?B?cWtRbDB4VkQxWFVsR1NKR0dPeVd2QnBkQkJya2FXdVl0YWpNSG5qTllUd1h5?=
 =?utf-8?B?blp6UFBUVjJUUnF1bkExcEZYa05tY2orejRFN1d2bkVvZnZ2cGhlMU53a0lj?=
 =?utf-8?B?TEZxTEhNTmpuUitGYk16SWxPR0xHWmZ6aWViaTE0bzMzZTIrMWNIc2o4d0Zt?=
 =?utf-8?B?b0xFc3dFbmZ1Z1l5MW50ZjlETWRvUG1odDZsTVhzQTlubFRkM1llaU4zNFBv?=
 =?utf-8?B?TjdzOU54ZDl5Uk9VRmpRZmRIUGF1SnBzVWtHbHJiMzd4VWZ4WlFvZ2FBdmJk?=
 =?utf-8?B?Ti9FeWVMNnZMeEZQYzN0Z0dzRUFSWm1nTmpsWVFUR3ZwclFGbHo0NDVUT2ts?=
 =?utf-8?B?WEorc3BBOW9vdmhxNGlzMEF0cTZBOHVEQWhsbURpMVVndEk5eVFZZVcvM1Ar?=
 =?utf-8?B?TkhCWnRiN3VOR2dzL1cwZklkZTVpTkRzczZPeUplV3ZJc1g4d01jY2JhWE4x?=
 =?utf-8?B?UUg1QUl6NUwwVkxlNzF5ekRqNzJ6VytkbDVtNkVmRTVFMGpOdUhPaW9POEpn?=
 =?utf-8?B?ZmRwRnluTVF1RXVhdG84dStJMUhTRVVudzl4WjNKanNwVFI0Umpob2pFZHVs?=
 =?utf-8?B?T0RVTnJFMzZyZCt4bENOa21iVXNQRURWQzZIVjhLYjlQNndXVFpxTSsrQ2c4?=
 =?utf-8?B?Q2JYV0k3bFBuTm1xUGo2OGUvblB0OUtWTkMyVkZGOFlJZkpMaGE0OE1ZZVZt?=
 =?utf-8?B?ejJ4SWI5QTRvL2RXbXBWNzhQdkhMK09tS2l3cU5NSUk1UGZmeG5hQkViZmJI?=
 =?utf-8?B?UE1XN056OTBIM2pKVkd4N1M5WjNzVmNLdldFdmpkck40bmpMU1RHcTZEcktI?=
 =?utf-8?B?UFdEdnBqVzhQQlNIL1kzeTFuRHlWUWErK2o5dGF5VlEvaDA1cUVlL2FqcTFu?=
 =?utf-8?B?UDdGMzgzS1pLQXBhZEhqdU1SUSs4U2svVjR5SEVIZ2Q4OCtGdWVlejhuUHVF?=
 =?utf-8?B?c1hTMENlRVJCcXg0MEVZQkQ1bVFoL3JxN3R5SUNWZ0ZQWXVpa0kyQ0dnSTJR?=
 =?utf-8?B?NElBVklCZDM5OGRyU3VRUHpLWkNzT2FITHNpRXNsMWlXbFVIbWdOenNzVVl2?=
 =?utf-8?B?TldkM3BtcnJWeWJTam1xQTFoS1NnQUh3TG5IQjladGlEUFlBVWFYNWwwWkFM?=
 =?utf-8?B?VmxocE5mTFNKKzlYWVE2eEFlYlpUcGh6Uk9tNDNCSjRWUVRjK1RFdXdObXlZ?=
 =?utf-8?B?SjBXaStsVGpsZjUxL25rNHJycGlEcXE0UzRuREhDQTBCMXdFb3lHeURUb2lB?=
 =?utf-8?B?NG5SVnBWbWVQV2djcXVEMi80QStCYVZFTXVwQVdIZThwWFZ1MW9vS2JlSCt1?=
 =?utf-8?B?Wk1zSXlCTEZVQWRTRVArRE5BOWZML1FmOGxOZDZjbFN0Q1BvQTVDWVVCNTZh?=
 =?utf-8?Q?869w=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: c18e2d21-1356-45e3-2e78-08ddfb39a3be
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:11:53.5163
 (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: vnIhdbQqc0prwF+QuypvDp3AeTbD2Jjd74tmukfk33U18nDMdLHWwiSxMVuLAZ+V958ohU4iKXWVp6U/O4mbRQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8295

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEw
LCAyMDI1IDExOjA5IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4g
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJh
cmRAdmF0ZXMudGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsg
SnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyIFBhdQ0KPiBNb25uw6kgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu
b3JnPjsgeGVuLQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTog
W1BBVENIIHYyIDA3LzI2XSB4ZW4vZG9tY3RsOiB3cmFwDQo+IGRvbWFpbl9wYXVzZV9ieV9zeXN0
ZW1jb250cm9sbGVyKCkgd2l0aCBNR01UX0hZUEVSQ0FMTFMNCj4NCj4gT24gMTAuMDkuMjAyNSAw
OTozOCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gLS0tIGEveGVuL2NvbW1vbi9kb21haW4uYw0K
PiA+ICsrKyBiL3hlbi9jb21tb24vZG9tYWluLmMNCj4gPiBAQCAtMTYwNiwxMCArMTYwNiwxMiBA
QCBzdGF0aWMgaW50DQo+IF9kb21haW5fcGF1c2VfYnlfc3lzdGVtY29udHJvbGxlcihzdHJ1Y3Qg
ZG9tYWluICpkLCBib29sIHN5bmMpDQo+ID4gICAgICByZXR1cm4gMDsNCj4gPiAgfQ0KPiA+DQo+
ID4gKyNpZmRlZiBDT05GSUdfTUdNVF9IWVBFUkNBTExTDQo+ID4gIGludCBkb21haW5fcGF1c2Vf
Ynlfc3lzdGVtY29udHJvbGxlcihzdHJ1Y3QgZG9tYWluICpkKSAgew0KPiA+ICAgICAgcmV0dXJu
IF9kb21haW5fcGF1c2VfYnlfc3lzdGVtY29udHJvbGxlcihkLCB0cnVlIC8qIHN5bmMgKi8pOyAg
fQ0KPiA+ICsjZW5kaWYgLyogQ09ORklHX01HTVRfSFlQRVJDQUxMUyAqLw0KPiA+DQo+ID4gIGlu
dCBkb21haW5fcGF1c2VfYnlfc3lzdGVtY29udHJvbGxlcl9ub3N5bmMoc3RydWN0IGRvbWFpbiAq
ZCkNCj4gPiAgew0KPg0KPiBJIHdvdWxkIGhhdmUgYWNrLWVkIHRoaXMgaWYgdGhlcmUgd2FzIG9u
bHkgdGhpcyBwYXJ0LCBidXQgLi4uDQo+DQo+ID4gLS0tIGEveGVuL2NvbW1vbi9kb21jdGwuYw0K
PiA+ICsrKyBiL3hlbi9jb21tb24vZG9tY3RsLmMNCj4gPiBAQCAtMzkwLDExICszOTAsMTMgQEAg
bG9uZw0KPiBkb19kb21jdGwoWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVf
ZG9tY3RsKQ0KPiA+ICAgICAgICAgIGJyZWFrOw0KPiA+ICAgICAgfQ0KPiA+DQo+ID4gKyNpZmRl
ZiBDT05GSUdfTUdNVF9IWVBFUkNBTExTDQo+ID4gICAgICBjYXNlIFhFTl9ET01DVExfcGF1c2Vk
b21haW46DQo+ID4gICAgICAgICAgcmV0ID0gLUVJTlZBTDsNCj4gPiAgICAgICAgICBpZiAoIGQg
IT0gY3VycmVudC0+ZG9tYWluICkNCj4gPiAgICAgICAgICAgICAgcmV0ID0gZG9tYWluX3BhdXNl
X2J5X3N5c3RlbWNvbnRyb2xsZXIoZCk7DQo+ID4gICAgICAgICAgYnJlYWs7DQo+ID4gKyNlbmRp
ZiAvKiBDT05GSUdfTUdNVF9IWVBFUkNBTExTICovDQo+ID4NCj4gPiAgICAgIGNhc2UgWEVOX0RP
TUNUTF91bnBhdXNlZG9tYWluOg0KPiA+ICAgICAgICAgIHJldCA9IGRvbWFpbl91bnBhdXNlX2J5
X3N5c3RlbWNvbnRyb2xsZXIoZCk7DQo+DQo+IC4uLiBhcyBleHByZXNzZWQgZWxzZXdoZXJlIEkn
bSBub3QgaGFwcHkgYWJvdXQgdGhpcyBvbmUsIGFzIGl0J2xsIG5lZWQNCj4gdW5kb2luZyBpbiBh
IGxhdGVyIHBhdGNoIG9mIHRoaXMgc2FtZSBzZXJpZXMuDQo+DQoNCkkgc2hhbGwgYWRtaXQgdGhh
dCB0aGlzIGtpbmQgb2Ygc3R1YiByZWFsbHkgaGVscHMgbWUgdGVzdCBNR01UX0hZUEVSQ0FMTFM9
biBmb3IgdGhpcyBiaWcgc2VyaWUgY29tbWl0IGJ5IGNvbW1pdCBhdCB0aGUgdmVyeSBiZWdpbm5p
bmcuIE90aGVyd2lzZSwgaXQgY291bGQgYmUgb25seSBkaXNhYmxlZCAoYW5kIHRlc3RlZCkgaW4g
dGhlIGVuZCwgYW5kIGFjY3VtdWxhdGUgdGhlIG1pc3Rha2VzLi4uDQpCdXQsIGFzIHlvdSBzYWlk
LCBhbGwgdGhpcyB0cmFuc2llbnQgdGhpbmcgbmVlZHMgdG8gYmUgcmV2ZXJzZWQgaW4gdGhlIGxh
c3QsIGFuZCBJIGNvdWxkIGFjY2lkZW50bHkgbWlzc2luZyBzb21ldGhpbmcgYW5kIGxlYXZlIGRl
YWQgY29kZS4uLg0KQXMgQ09ORklHX1NZU0NUTCBpcyBhbHJlYWR5IGEgcHJvbXB0IG9wdGlvbiwg
dGhlbiBtYXliZSBJIG5lZWQgdG8gcmFpc2UgYSBuZXcgY29tbWl0IHRvIG1ha2UgaXQgYXMgZGVm
X2Jvb2wgYWdhaW4gb25seSBmb3IgdGhpcyBwYXRjaCBzZXJpZSB0cmFuc2llbnRseSBvciBqdXN0
IGFkZHJlc3MgaXQgaW4gIiB4ZW4vc3lzY3RsOiByZXBsYWNlIENPTkZJR19TWVNDVEwgd2l0aCBD
T05GSUdfTUdNVF9ET01DVEwgIiA/DQoNCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:32:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:32:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129018.1469142 (Exim 4.92)
	(envelope-from )
	id 1v1JzC-0004kd-2A; Wed, 24 Sep 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 1129018.1469142; Wed, 24 Sep 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 1v1JzB-0004kW-Vd; Wed, 24 Sep 2025 07:32:21 +0000
Received: by outflank-mailman (input) for mailman id 1129018;
 Wed, 24 Sep 2025 07:32: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 1v1JzA-0004kQ-Uh
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:32: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 99d90ffe-9918-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:32:18 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-62fbfeb0870so7057418a12.2
 for ; Wed, 24 Sep 2025 00:32: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: 99d90ffe-9918-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758699138; x=1759303938; 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=v9ogATJZj1jG8raAY2zUuQe4EmJHk/4W4xvGLcmqNCI=;
        b=Vj1V7LkEIweSdGCUmr8JpbCXEMN/br8VfnB7Cxl3kgGHYamUjaor6o4rjcI9tcIVzA
         sDBmhPCLwVh5PraVQQ8tyxI/x/CvZ+gNqy1vP2/gmRAxUln9tNIDOajPgc4iBJ1MwvCu
         dON9AF3Z2eIAmRzNDcXlP70t7iF9WZbGBfxgT2I0ANLN2vt/Myi7yxBf+D3796+9TPal
         zteP+Jcx0FQoZV+qPb0r4QqrOf1uU6eTKbb/bnlt6lc6/q17HV7iqV3bBvZvyMDOg8OP
         gQUwmYgAMrSUkpAVGZMBXKeKryP2L5Y6Nga2F6bHqX9Kcu8IkwyS9b49PH0+kTg8J2cM
         XBog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758699138; x=1759303938;
        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=v9ogATJZj1jG8raAY2zUuQe4EmJHk/4W4xvGLcmqNCI=;
        b=NYxDyHtPXt8waVKX4gh4YOsANhJKE9Y3M6Y58RgEYfxz07dskMPZ/qSrVoxBqfioVk
         1PBAV//cQzd8hD3PwgpxljLstkU46G4AevUEbFZI2XUKFUr1Sic4tcZVop6oHX9dW0OA
         eNNol/RL9Btt9gvU3M+KMJ0/KMkQ1miYOnbLVSVR7Ks60K3So5ytdKswTx8xSin80RDK
         2lRKB5Y4VS+icZgvWVWqEQ0DFi5vBPrz20+JoHgrUql/jdN1Hbfe7M3mBTZbQgpMhbfe
         MRLrDuD9Bl0tj/1GgW9B/7iF9UM5R+ab0BMO29wBO4+yPcRwZg+mF5I/5/hvqeEtEoE4
         Aweg==
X-Forwarded-Encrypted: i=1; AJvYcCU4DG+QhGuGH7N1X2n6JnKxEgWBxDuHS05KmKcgo+sFWtD1bhJiYc4OKaNgpsTLHG/crqK7Jzgn5zM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztRL5X6SBlmkfyPJNoFGU7EVLKprmVrz8N2PntL6InzAGpgeKL
	RMOCJosrbsFMBnGskfC6K9nIffYTdPUNa+/rQ0YJ+AY/3LjAgKPEl5af2apytVRZd6JIfLv7heM
	HmtUsVO0dyX6slZ4a9k2ELHasFRglz7A=
X-Gm-Gg: ASbGnct0rJuILWZP8TVLgcF7YoOsg440I+OSofRo6aLhQaSJvOoJv6MzN51E4W12U/v
	07ryecDS4OsygeC1/P41P7r1QodSZbIFVRpT2aUExvWsgauY+07buPB582WbuAiE5nDn12l6qyV
	u4juGG2s/8KYxwwYrkzJVSN3keu2RwNzc5SNq+9I5iVe6S0A7TPY8TjEt/og7J7F9W5KKRoKxB/
	9ultk1b
X-Google-Smtp-Source: AGHT+IEsD22J4a5V9bbdMWtQv1Ep8AmuRuA2KpP+ndq9VMyD7XFtjS94kSm5rlJirOSxMvazqqoNAsq4GX/ON5RyqyA=
X-Received: by 2002:a05:6402:44dc:b0:633:4726:a077 with SMTP id
 4fb4d7f45d1cf-63467796df4mr4258422a12.15.1758699137992; Wed, 24 Sep 2025
 00:32:17 -0700 (PDT)
MIME-Version: 1.0
References:  <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal> 
 <20250923235318.GD2617119@nvidia.com>
In-Reply-To: <20250923235318.GD2617119@nvidia.com>
From: Magnus Lindholm 
Date: Wed, 24 Sep 2025 09:32:06 +0200
X-Gm-Features: AS18NWBrVH-9-wBlZ7ZFV3RxYYp-7iSL9DfIPq4jDzU8rxFLx7xmKKzveUA49as
Message-ID: 
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical address
To: Jason Gunthorpe 
Cc: Leon Romanovsky , Marek Szyprowski , 
	Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

> Suggest testing the same branch with the alpha patch reverted just to
> rule out any issue in the core code. If it reproduces suggest to
> bisect Leon's branch.
>
I can try to revert just the patch containing the alpha-specific stuff and
see what happens and then, as  you say, maybe do a bisect from there.
First I'll just try the same kernel again a few times more just to make sure
that this is really reproducible.

/Magnus


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129036.1469202 (Exim 4.92)
	(envelope-from )
	id 1v1KPT-0000QI-Od; Wed, 24 Sep 2025 07:59:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129036.1469202; Wed, 24 Sep 2025 07: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 1v1KPT-0000Ph-Hh; Wed, 24 Sep 2025 07:59:31 +0000
Received: by outflank-mailman (input) for mailman id 1129036;
 Wed, 24 Sep 2025 07:59: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 1v1KPR-0007np-Nu
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:29 +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 650f9624-991c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:59:28 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB8118.eurprd03.prod.outlook.com
 (2603:10a6:20b:445::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:22 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 650f9624-991c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mlCB6a0BpZcQaBFCGXnQTZfJI4GKNxeP3EIQWeYGbdnEWNEC8A66bCj1/gD85+Z7GGN1skllJ9VnBruKjus4eNc1PcWjIoefrJ3JEFadwpqVtpVqeE6hhQ565UobcNjyMVAiWtYPhtkvFHKTxUj+aLW494rAL++wnB6LaD71RnRluqGexiNX8Db0iIcMPwQ1s9TzifzIyqf0dEjuI2sYC3WEsKCmwS0knKi0gc+lnceKJ4AtjuPtCkFhnLhU41+2A4r2P0loknWtR8fqB5bpTvWPul+UN8dF/kqxCBFM2y5Shm0KEq+rkuMwxSkeXQT0Bdft5YzhI/k4HsXS3jEj6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/J+B8SmmFZkxU0vI4rRuSl7qd5Ef4KyDBUosgN+zjEU=;
 b=nF+I9MsJOqKBxptTKiwvxob8V7rmP7QQM27P7qllIOUXW3dXLqeUGuktwC5G5HDRCIbeC7vGsjjTqe8yhd1maZ3LwrJyLOQ8voqjfrLAVWPM9HtgLywFB/XA2tUC6K/4CwH/t3KfNzAGIlJR4k8n2RoBOKIVmcR/zlj/UiRXQGPDc7SscimcGmmxY4SIw+vgVuKJFxxo7bFHZ0TyHyUmRcPXXa/B5VN/U/5UPrU2VAbFnNhfGJbimLKdSfsSLGc2NsVe71HvnBQUej12kvxDed+1Wn5E8gWLZaxNL+AUOgZqvraDf+q197wLXHjA9sLHu1WUCSSt4TjITqxA9sq2zg==
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=/J+B8SmmFZkxU0vI4rRuSl7qd5Ef4KyDBUosgN+zjEU=;
 b=hCXGGMNgQMqSumOXMtUs9tjBrvnCzjVq9djbNibet4Vn3E8pG88KV+hwUdAtn5BVTEUgOijrBdEG91/soIs8hi8KWsy0WsVxW2scCHGmwGom0MQ46b84iVdBhQJEjqpnVpPJoA4NLIEzWng/6MKNkD1kCUmxhRPtR3rVuKGN8InJq3j87EEctqmK9s9T58NlMktNXoyFWrcRg39tYm3bPYHLvNCGa9EHwZxbH649NNs/6tdzSGSn9ibX/hllO50fAjh8Wgw8GANGf/dVNd9ERnivfcwWewNMa88jYwLLU+MrtHpcuxu4pAGBRzJhx+OAl2cDUOLTsf3XUFLofLXPeA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Luca Fancellu , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Stewart
 Hildebrand , Mykyta Poturai
	
Subject: [PATCH v1 4/8] xen/pci: disable pci_device_{add,remove} when hwdom
 uses vpci on arm
Thread-Topic: [PATCH v1 4/8] xen/pci: disable pci_device_{add,remove} when
 hwdom uses vpci on arm
Thread-Index: AQHcLSkjp9oz81JUVE62TQagPRX78w==
Date: Wed, 24 Sep 2025 07:59: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_|AS8PR03MB8118:EE_
x-ms-office365-filtering-correlation-id: 51be07f0-1935-401a-9589-08ddfb4045cc
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|376014|7416014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?6WaYqXLW0PryVPDGcm3j12UT0+whM6BkCsNUEZ9NTrsJOBhG61OEwWwk+y?=
 =?iso-8859-1?Q?2bRE2Yx07y1rxEHpXIHaRm5YWs3Rn1kF7OPUEYsA1fO00Z4uT8T2PdTW5Y?=
 =?iso-8859-1?Q?C5bNeXH+RXuc1jcnBpe/R6aEJwg2E+lN4gRFbX1y26YV1yjNeYBSQo/d01?=
 =?iso-8859-1?Q?e3n2W07YvyHIoBmoKC+UjfwuvsK7tvt8dGXiC7GUoHu06hI382eAsdZ1qg?=
 =?iso-8859-1?Q?y59ROmLRp+y2ZeBY51TXPGiCtsiV37KFJBjAs3u/8fnUMSyniTN6XkJr3N?=
 =?iso-8859-1?Q?Fw8XyEoQwy/ptS6Do2PdkgxYpVgVIZjT+IU1cPHeKjLNXciCj3qQ2M7ir1?=
 =?iso-8859-1?Q?brR9QoECJ6PZrZPReR9UladrS90fHTgAPsG+CmK+JJWTmQZqRfb0x+aJl9?=
 =?iso-8859-1?Q?+vIEp9FvK9xN9qUOtG/O5HzgF0Xf3MGd4QtufjltiHbpLlUxUpPNOf8Xip?=
 =?iso-8859-1?Q?TpUrZaoFqXd57HzrjpfFHcC0f4gOVB/5Iyg5OdVtf/CnR5Fm6HslZ/dFP7?=
 =?iso-8859-1?Q?Z5Oq5ezFW3EMLPdgjNOv/U9NfF2PDxqpYwuMGz8/QmDonMIf5SfC4QAEdX?=
 =?iso-8859-1?Q?/IrpiV2hUg7yU1jhoHk+dU62T3FxpnXndFC/bpojF9JasxxDk68Rn7UV9d?=
 =?iso-8859-1?Q?62+oQb6IUq7LI462dL95//rkGcEQco4D0j6S3e09Ahv7IyUaB3JbcpTjM4?=
 =?iso-8859-1?Q?KBKCiKyMOaWOBMd3GSgrModRee7zXz+X/1RTPH6Hj5PP3QWRX0ALfd8HaH?=
 =?iso-8859-1?Q?xxVZEipcweeGJVRPEsgvOqH6mjG6oCF+iffiq1TzjZoFJMxZ0aEdnqEqw9?=
 =?iso-8859-1?Q?wqEX7jZvZoWTWl7w5BT6BYuHdt3TF4f6IXx+hBmo/rp4AqDZ9bC+rpxklN?=
 =?iso-8859-1?Q?eY13302VWz4/AEffBAweB5OXnVkvpVqo9Sne5xag2r/mVyeXt+4DpfBGS/?=
 =?iso-8859-1?Q?VxhFwK3mJCGoJt2tE48o70g9ef/03pEebx9dWddt2ODMq4/i4YhZ3/XcPm?=
 =?iso-8859-1?Q?zm8JZLwjaG/ubdypLIUgt0c6lOGzjKhEkV2+Se50jXJJr9U96rnJfNi5EY?=
 =?iso-8859-1?Q?u161o8BLgqq5WKFOeiorTax85dJHZNsfuj/2l4E0sJD1VQd6cXg/5zu6ce?=
 =?iso-8859-1?Q?nuVf1BKvkCzAt/SQnPedbqV+Jrk++1o0lW11hwOJ/+RhoDoIr4fyHJmKJw?=
 =?iso-8859-1?Q?0TYVArGuPLfOhxxJL0MSB1iamyRkbRkhFM07BjJY01yvPK1WtSf1T7ikqh?=
 =?iso-8859-1?Q?l+sWYdVqWZAIIl8ra/fYyFjAh9PYoF0Bsd4e5t5sj9IyuiJ0g2rB6z07br?=
 =?iso-8859-1?Q?OpjtgZT+WqLrjiEoXGX8q9jeZbUVWZ12RnBM7eS5BDtlmws4GfEe0VJpQV?=
 =?iso-8859-1?Q?2zSfs06QfZstF/eQ7GdlosEehOJHbUC5UEQmliqD1IEKfCf427yZKbyYbS?=
 =?iso-8859-1?Q?oSUPb3f1l3FtRk756lZLz492Z3aT+BhnVwJLkgjLSHrDFq8LQBSFoPnSYT?=
 =?iso-8859-1?Q?TmI4J5OkS+Sxqr3wmwIqtmwyZV86osZVJxmMBs3X+JcckLN03utju90hkP?=
 =?iso-8859-1?Q?qsiRZ98=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)(7416014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?e6lms9sMeq2L1ytNFkI4fdPbxVa1GLK6AySRNoDtMrdDC5QdUYO/FHPDzy?=
 =?iso-8859-1?Q?wyWvBRHWDUNohN40ThMBBtgoISXWx+uDd5Al2jMqjez1sJRwkcnICOddxA?=
 =?iso-8859-1?Q?FyJzJbpOYtFB8LDgF2V+JZlh4LEQjQGtdph6vQCz+CpbnnebALoRb4ZOvn?=
 =?iso-8859-1?Q?+sYGoiqmiL7eGTNdyDCDkNcgaG4ugY6sncCtELK6KVlZXUgbLPwiTs1Vwz?=
 =?iso-8859-1?Q?GvzgDVgIzcqVCRKaR1VDh2zhVIfqXTZy/vD+3DEcRa8KCIiGxr/FKvu6RZ?=
 =?iso-8859-1?Q?LQXymUAv1l6I3uZDXZHlrMdL7NJMBTsQd+jnlVbSO3WZBbcPieUF5BwVPx?=
 =?iso-8859-1?Q?dHJ+JkSdl1zFLgdo49fGZ2WpcuNUHrocxFFWJeFSoNyUVXaFMrsBdwAfY9?=
 =?iso-8859-1?Q?XrKPgZf1RRUnTEH/XA4VzScOLCzglQAY2uk+9b8KkmxB6OlVtslmEPuxqX?=
 =?iso-8859-1?Q?SWUlo0fbkGsKTE5u6Vw8oTwS4fjPZKO/ao9TMixWKQcmUcJL2JE9kyvbu8?=
 =?iso-8859-1?Q?KApAzSegs4Fzb6sDTy12wGqZ7g1IHG0uGyNpXNwhnlxAV+PB20Bsn66/fP?=
 =?iso-8859-1?Q?WifaPHYMFwxMt+EpofGU4pA2VwQoFGtC4YUEXbyZjQf7ze3IepzdsK1eMc?=
 =?iso-8859-1?Q?PBcIohnSwyeLyd6eNfsaWcJ8rlKX3qQ4ZRbT/sjXqZYtWxzGLTt8/dmDD9?=
 =?iso-8859-1?Q?OG/YAEIAtlCU78ynGSZJKhjYYkKcazQ/2KbUaNCiWgP/NrSBMw+Vd+jQgs?=
 =?iso-8859-1?Q?Vge/1dBckgkm8M9MYGygcCxaw4PhXOz8+mjQQ7gSyVpsdND4fN6gf8gXF7?=
 =?iso-8859-1?Q?CeVlcghkMmeeXfc6HT9IrSdZyoouqA3bbH8v51ly8aIY72Ar+H4ts4hXkX?=
 =?iso-8859-1?Q?4PK+18ffw8PtEXqzP0nSzm7AqN5UPrSfu4EmDRZVmoSewMOoz2O1IU6cg+?=
 =?iso-8859-1?Q?LBB3CnhNwS48EhMHvrWq1XiPfUa3l1xrEK7Q3R6Fz9kBvUkM4AgGjzewZ5?=
 =?iso-8859-1?Q?DmPvub4bvkjWP9tKsCU2QbT8q1PlahNWAM9wnYivB3/EGxmG8imN9klckK?=
 =?iso-8859-1?Q?Jk0XkKr24jf7U658pe4uyN73EImHoU5HUUDal9+RIRgPvPukL4shURV70B?=
 =?iso-8859-1?Q?g4O8pbzehbRbZcCpe/2zXUKyNtFQnxCYrbapGIh4aoPIA+KB69pSbXd+0a?=
 =?iso-8859-1?Q?LA6+l/h3K6Q15YgnyB2V71lHFh6axnzt3XVJxCXe1fJ0ypWn5TXRczur8/?=
 =?iso-8859-1?Q?n2xoDN6VfRXSAECiS0skcol/l9KKUv/e6BljlVKtZvDeNeoE20PxZk3A2x?=
 =?iso-8859-1?Q?ZNkxc417KnjzNfmn0sRfEALYxXkUri7XeN0uA9qbnPLeIc8GIaGmzenCJ8?=
 =?iso-8859-1?Q?VmdtUVS5flq210JTM5zfG2AxMcs80PM7QjyEQgkPbGhJkEH3SskpfPi5Wd?=
 =?iso-8859-1?Q?wnTJTcYHIJumR3tolvpv75CeyD5PW8z+esH6Swh2iEifn4lHNyjzPssJQK?=
 =?iso-8859-1?Q?zH51TwMTYtb6pVnJuwdVlWvLdwWguZFbGuW7auqTbYAXZEHlxz+P0m8aJB?=
 =?iso-8859-1?Q?QEoXb0DKAZnJG1ztWjpPjXrxMptFzK7aqqW1F2wzXlxlEk3SEbgiayOMyw?=
 =?iso-8859-1?Q?ueL4uuGYxNIeNiqI5GYyQYCPUd3va8Aek4IWO8VIolVCimH1BzTLRE8g?=
 =?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: 51be07f0-1935-401a-9589-08ddfb4045cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:22.3130
 (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: giB6UVB7ILmWIHwqgPk8nNeXf92/0/giQVUVPBOtoE1gAVI4MsBMdGE8RT8ZFmaexqrl/mSC5nn2s+/eMWg2Tg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8118

From: Luca Fancellu 

On ARM, if the hardware domain is using the emulated bus, it should not
be allowed to add/remove pci devices, so return EOPNOTSUPP in that case.

Signed-off-by: Luca Fancellu 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
 xen/drivers/pci/physdev.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
index d46501b884..5b3f8dde14 100644
--- a/xen/drivers/pci/physdev.c
+++ b/xen/drivers/pci/physdev.c
@@ -19,6 +19,9 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void=
) arg)
         struct pci_dev_info pdev_info;
         nodeid_t node =3D NUMA_NO_NODE;
=20
+        if ( hwdom_uses_vpci() )
+            return -EOPNOTSUPP;
+
         if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop()=
 )
             return -EOPNOTSUPP;
=20
@@ -57,6 +60,9 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void=
) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
=20
+        if ( hwdom_uses_vpci() )
+            return -EOPNOTSUPP;
+
         if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop()=
 )
             return -EOPNOTSUPP;
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129031.1469163 (Exim 4.92)
	(envelope-from )
	id 1v1KPR-000825-E2; Wed, 24 Sep 2025 07:59:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129031.1469163; Wed, 24 Sep 2025 07: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 1v1KPR-00081y-9v; Wed, 24 Sep 2025 07:59:29 +0000
Received: by outflank-mailman (input) for mailman id 1129031;
 Wed, 24 Sep 2025 07: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 1v1KPP-0007np-Ab
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:27 +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 631d4f55-991c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:59:25 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB8118.eurprd03.prod.outlook.com
 (2603:10a6:20b:445::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:20 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 631d4f55-991c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sWE/BPUjP/H8ZNFgxR2g2q2ZlTAIEnW92LYsMR3FaZSNVN0w2P76P3WVs61I6/hyfsG3kdqr2EgpSh7nJi5bitAryGwC8D0ZFUKn+4uYDXvUC7zUgNguyzpPECguZ0aeCL6EJHsc+IyvnP1EQUufcm2hUo+oLGeCH64Uoh1bhNhVfjxxAy3Y5rJugTLBPU4JKkpkVCpWnn9UGcm6TS864xxjp9fx4pG9wKhbYI3WUrpsIL7l1K8aC6Y48Fkpyzn89U6GQUFsP5lqlc5yUTtVPAIlt8jeDibBlqawgJF5b/1uHX3NqSyBKernMzxgQvh0t5oHeQZoc3bZ9EDQ7loUeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qTwXTNysux3iP3L58FkRp17XcK5UFJFmSy4ETHEy7e4=;
 b=Jdc/u+LXuaa+gkEE3YaMRYF2Sqy6mHkuXAfSNx83qsM7i9fCW9vPDJAJzQlcQNHCtL26EgMplmwyYPEy8dBCDlWMg8Ri9BnKtWmq22YHZwtqLa6EuFTW1jF9mQuAJQeNxN2pSi1fyL3wBT+AJip5s4x656UMfWo18+fT3gdytpy9o8vJ45/Z9HK/PAnGe23AZLLJiK++QUt5fhevwTejDzYVBdRWPnw5c+yl0sGGjIdV7W/rLgcn8Idr17AI+rl5jinPoXQQwu59UQdzD8m1XNi79tKGoU1teii+zhrStNvujWDQ/QXYWR/EJn/R7hSvny7eDdCOs8sAm//7BCczsg==
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=qTwXTNysux3iP3L58FkRp17XcK5UFJFmSy4ETHEy7e4=;
 b=Sx/tQ9w5Lmd0XeoWNpfCkVC62eBQ/03KTP2szu8o3OFjs3YApAxHFE1JOEiqBu2w9sfInC008BcaUqzQrB7XIjhmNtHJuVcGsrcPb/K7FDlx+sg1z8s4Q2JFk2DlIhA4bbFDsCzt2xRPWQcDtE6WoTGKogb432PGwxhGBOOYsFUKDG1VK68KrQC1i8BAJHrWfS6Heh6Sm9HA/wM5TusgQVIPqWtfOTAHpUT9/PYTq2USr73IaLf4HS3HUsgNCh9EpQjrch25g4Eb5Ui3HqQZcNo38F/WDa4bR0L9P/8T1iBkUZCq+JrUkaSVpGyUV5XEIh8FLEQsvZec72bB+MfVKg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: [PATCH v1 0/8] Implement PCI device enumeration on Arm part 1
Thread-Topic: [PATCH v1 0/8] Implement PCI device enumeration on Arm part 1
Thread-Index: AQHcLSkhRXSikUEA50SGGeDzHe8jnA==
Date: Wed, 24 Sep 2025 07:59:19 +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_|AS8PR03MB8118:EE_
x-ms-office365-filtering-correlation-id: b18ece0f-493f-4507-aa48-08ddfb404432
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?37kzeYOjchjULRONejyV1WvlPhV7+IzF+vJK6MEmqYOnlZIn6rIWQStu/R?=
 =?iso-8859-1?Q?D8mTgdWZ5m4RwAd3Rpvkl2VQmZAO+GY5PHH0q28GQUJ787H2q6xTsZQRHL?=
 =?iso-8859-1?Q?5h9ucY5Nwo6WL/D4Ta2tKUh1TlFksDJT+HFawKd1jY4OkzWHx/syM90zdz?=
 =?iso-8859-1?Q?LPVlQLA0c24CfvBn/b7yiNX509PrsbUNEYm8lc3ulL9zJuxeP0L0zGO0xO?=
 =?iso-8859-1?Q?D04/Nt/V3nXstmY3g8VFaSSTdGV4qjzsoTZzrEUuJ93w8AktLy5R0fcieR?=
 =?iso-8859-1?Q?31QKA1k+zAidtQ5rBj0x6IakRGEXz+PWI4xagRhcqbb860Pn5rfvu+8kkn?=
 =?iso-8859-1?Q?Wtdx/tdYjk9C8ITMz4IN0UUd1EHEQtfhJAce6v5SnLgPqfGndwXh0l8bqu?=
 =?iso-8859-1?Q?6zfTGpol+o7Ycqsf5wDYkCa7bNdyKzKBTROe9ZPeVpbQkdq3fgMHtlG4Wz?=
 =?iso-8859-1?Q?OE2Lh/pw4UExC5YOOq6fpMJQLDZqj+tEvGq22ciqDvQiiqbFNwGgf/2vCg?=
 =?iso-8859-1?Q?gKvobiAZdOc6AXgprr+dDXkzaFU1l5UItjRaSwP1xMOB3pNo5Wi3Desbr0?=
 =?iso-8859-1?Q?KEyMAiLB43AOhMXOeb0GBgSOv0So3WvgKmlpkveUCaQL13JGSoKXkcWsim?=
 =?iso-8859-1?Q?U922d2cf4DYcieu1/iCZOI4vz+GpJ6wQHb8qnoKTVw0HrxzeelRz8dKwid?=
 =?iso-8859-1?Q?LiMPIwl0XCC2w18kSLyqTZqvnjgLt4ZWU2piPa1tyBESFWe2PEgG1lbgK1?=
 =?iso-8859-1?Q?dO2nuZWOD4u2U8FzboLXPaDBc24/ymQfuwtSMBHe4oaYx+ZMveF1ITRxd6?=
 =?iso-8859-1?Q?G2E5LqFNZXBZ6H7mDGBBrMGlHYJ4xKhBD1WEvMTyCRtnzDFhXrYsUyIMPw?=
 =?iso-8859-1?Q?Rshbij3iy50FsFxGO0HNMa2DhBaNUdl1VuLK8x/2VdAZ5GZuhuGIdOyah/?=
 =?iso-8859-1?Q?HAKA7wvVzJvbTtpuCZDoJKPp4n7r9E16W1DBPL8k7c3SWgOkWuFR4NRsUN?=
 =?iso-8859-1?Q?O9BB9WmiWoOiwdSIy1Oi16naBOBNrIGSS962Ms7vMfTPH6cpat6ozOCXXn?=
 =?iso-8859-1?Q?uVRE4MVRqIf9sUecEyICVgKw5I0uTNMaE6hfGrjw95B5a9o4+foOb0hBFh?=
 =?iso-8859-1?Q?cUMw+OfcqbqoxaG2SklbbV77s23fnR3J4Q5fA+SOGwsr7iSpckj4jXmizp?=
 =?iso-8859-1?Q?MfuMEswqbVRv6gfTRIV5xUUQA0o7WslFk/vnuwGamrFt9zl5+qYuWIfGnB?=
 =?iso-8859-1?Q?Tga8OAuLuWa5og1BFlWu+Fffgo2VQ4wnpzvFX9DvJsZO3ew1tBKU/1R8VA?=
 =?iso-8859-1?Q?8vXZkGYDB887XuGFPs1iVq2ogaj6iTCYQfW3h2W14jCYqJZPkI2j7i06A/?=
 =?iso-8859-1?Q?q/NqdVHy9Rcn1bXiZthYoBGutS8jsnljgGAVU3EtwK43PzN0J6j+CmU9DV?=
 =?iso-8859-1?Q?b0cSCjJhRV7aEHGOCPSZbRwH3coDeYS/0i+qJAIa/dz/shwdB6fH2UilJQ?=
 =?iso-8859-1?Q?3wPJkTI3d7N3b5xZYdIg/wz1mVOVD1wZRVXnYrHi38Bj3QEzge7R36Mj0L?=
 =?iso-8859-1?Q?kb3gd64=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)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?3Ys2MrN8Zi5k6D6jZh8yWD9WZ6HYDN/DzEz56yobt2FoMZvtizbiXbyCEC?=
 =?iso-8859-1?Q?qHIAuKgouXCA9qX+/3jhi2Z6m4Pivvr59CHxIW8fYX2ajrHWtBN9+S0lMa?=
 =?iso-8859-1?Q?eBLWy2FMbi1r4LlwpJ9TVBWyQGc0ZDLjWJoXBoD0D+wR0sgJ4KEvxclKao?=
 =?iso-8859-1?Q?+oSBpbfD2cRrmDtyPzAVE2xIWs1SPHXo/IPdCXeN3sdF7ASxQucPXA6GXM?=
 =?iso-8859-1?Q?cc9UM/6dsyvhYwwDkUzvwsyFE4tarN6UKP+4wUHPztiOBUTeV2ikEV5TtU?=
 =?iso-8859-1?Q?QhffE5SwVa++tYKmorzt/sOvSJYWH3N63J9XF3LVhOEMpO/gLJC/d5hoP2?=
 =?iso-8859-1?Q?otYjIfb7g8lw3Q7sXVn0jP1nFXaaD/7lGq78Rep2ZmacSXNr3/HuB4NfXo?=
 =?iso-8859-1?Q?Zsk+mhbO4lcBvySsF51Tk9uKmGYTy0PSur0oKQWaxcSrBUXB0SQJwGq1bQ?=
 =?iso-8859-1?Q?vbc7+w82WKU5V2L2FXxB5KrusLrSwo+bJ1CJJr5/o54C1mcdvdUQIPeCwZ?=
 =?iso-8859-1?Q?1IsnOxUgyTY9L4/wXaNHDRxziO3+zdOagD1v08B40IS1stTzB+VLU35tq7?=
 =?iso-8859-1?Q?syfVlXTXVTnHyPH3l8ewGjBO30atYmoUZ2FVLCtfe00/7Qs/eMEobx974c?=
 =?iso-8859-1?Q?CghZhQVe4Crg/Qhp0ijIJ2Yo6WWUotA3y4l2S5MBR402oIZ4BxwYAgUIhm?=
 =?iso-8859-1?Q?1P2xMwW6VngdRdCtl6a+mblZT9n98KBI6BluH8IzoR/jjuBcaeYgJEo36V?=
 =?iso-8859-1?Q?D34gLUZ71FceVOCp3PtggPijqmH9axDVYwzwp5ySmKyS42L6rmCUcMU4XH?=
 =?iso-8859-1?Q?cYJVCLiNTtIeac7azZQgQ+roV7JdGo2xq5vTevuGua/y9R1p/JZWAnndom?=
 =?iso-8859-1?Q?eWBtTqf0lgCWinjbowG/p3zjuqphWt08gYxdzmBLj7BDkvpdUi+MKUXNIs?=
 =?iso-8859-1?Q?AAjv8wx0fexxnnjMpGo5EJtjQRrl9ewpxSaHNAA87Vxq8a/J3WzCX552NO?=
 =?iso-8859-1?Q?sQYpDuT5viXMkkvYEmNANGrweTUP/YDATuxs/dF6x25NyNitAEruVtN9WY?=
 =?iso-8859-1?Q?SIxv0FE08iUG/ccdCZE4/HADHwwZwthqBp+C+Rpv8VmArYeZ1tsz+Fcrw5?=
 =?iso-8859-1?Q?UVb3r9WdwLTSECss9piPih2mJ3h1Jf0h3cwZ7hP5YltkZsuCBt1Hxh5eAZ?=
 =?iso-8859-1?Q?BSAHxUAZupzcaAxlv5rSHeI/0TkhZKPbRmLn7YEsoQ5lLmlvUkPxz46xIH?=
 =?iso-8859-1?Q?dSqwJiaRumoUODvDPFFcAFkwwZt7b21TDN7ESaFlinrf6LdQ140W8Er0G8?=
 =?iso-8859-1?Q?VpzbfHLrJ0iVQTnz66gk2SN0Naa4IM8bu1l+78SfDgEw5fK0U+m83h0Bbp?=
 =?iso-8859-1?Q?IJTKudpVhjXcyGXpTnr+rd4jmdpD6paMeS8aIpnkLDPMHAasZlqNMfRZDB?=
 =?iso-8859-1?Q?ah+m0X+dI2bcgvuMnDQ5E/1jCHBR0TvCYN+CagDbjLbMCXF3UhESBqwrm0?=
 =?iso-8859-1?Q?HoowciFakRbn1TFxnHVrmqRxri5X2j/qrzBLZ5DLxMMRpWvnYv7clEYwRm?=
 =?iso-8859-1?Q?i8Dp8gqko6QKnZGcCVuot10w0zMhNM34f2Ffs/Cubs8OHMOCs2t9zb+GNP?=
 =?iso-8859-1?Q?hZ2IEobJYVe091hGsKQCa0a97SKew4PfRKxm/6NNmudzO5Pd6vf1BKLA?=
 =?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: b18ece0f-493f-4507-aa48-08ddfb404432
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:19.6428
 (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: QaVwfiWjkts2MldqktCjTqHDhrnxUcgB1JIAxHwKUPchMMD7SUPBvgXnvcluxJmSHJNZsG1lyedcuiJvwJnVhQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8118

This series adds basic PCI device enumeration in Xen on Arm. This will allo=
w us
to not rely on Dom0 enumeration for supported controllers, which will enabl=
e PCI
passthrough for dom0less setups.

Enumeration is disabled by default and can be enabled with "pci-scan" cmdli=
ne
option.

For now the discovered devices are only assigned to HW domain. To achieve t=
his,
several things need to be done:
1. A VPCI node is created for HW domain device tree, and the real PCI nodes=
 are
hidden from it.
2. Discovered devices BARs are initialized.
3. Register handles for VPCI are updated to change behaviour depending on
whether or not the calling domain uses VPCI or HW PCI, instead of relying o=
n
is_hardware_domain()
4. PCI physdev ops are disabled for HW domain using VPCI.

Edward Pickup (1):
  arm/pci: Add pci-scan boot argument

Luca Fancellu (3):
  xen/pci: update DT for hwdom when it uses vpci
  xen/pci: disable pci_device_{add,remove} when hwdom uses vpci on arm
  xen/pci: assign discovered devices to hwdom

Mykyta Poturai (1):
  arm/pci: enable vpci for hwdom when pci-scan is enabled

Stefano Stabellini (1):
  xen/pci: introduce has_vpci_bridge

Stewart Hildebrand (2):
  xen/dt: pass flags to callback in dt_for_each_range()
  xen/pci: initialize BARs

 docs/misc/xen-command-line.pandoc       |   9 ++
 xen/arch/arm/device.c                   |   4 +-
 xen/arch/arm/domain_build.c             | 154 +++++++++++++++++++++++-
 xen/arch/arm/include/asm/domain.h       |   3 +-
 xen/arch/arm/include/asm/domain_build.h |   1 +
 xen/arch/arm/include/asm/pci.h          |  25 ++++
 xen/arch/arm/include/asm/setup.h        |   2 +-
 xen/arch/arm/pci/pci-host-common.c      |  83 ++++++++++++-
 xen/arch/arm/pci/pci.c                  |  24 +++-
 xen/arch/x86/include/asm/pci.h          |  20 +++
 xen/common/device-tree/device-tree.c    |   5 +-
 xen/common/rangeset.c                   |  35 ++++++
 xen/drivers/passthrough/arm/iommu.c     |   9 ++
 xen/drivers/passthrough/pci.c           | 119 +++++++++++++++++-
 xen/drivers/pci/physdev.c               |   6 +
 xen/drivers/vpci/header.c               |  14 +--
 xen/drivers/vpci/vpci.c                 |   4 +-
 xen/include/xen/device_tree.h           |   2 +-
 xen/include/xen/rangeset.h              |   6 +-
 xen/include/xen/vpci.h                  |   9 ++
 20 files changed, 509 insertions(+), 25 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129035.1469207 (Exim 4.92)
	(envelope-from )
	id 1v1KPU-0000Vm-50; Wed, 24 Sep 2025 07:59:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129035.1469207; Wed, 24 Sep 2025 07:59:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1KPT-0000UZ-U7; Wed, 24 Sep 2025 07:59:31 +0000
Received: by outflank-mailman (input) for mailman id 1129035;
 Wed, 24 Sep 2025 07: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 1v1KPR-0007no-Ng
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59: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 64f23e9a-991c-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 09:59:28 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU5PR03MB10523.eurprd03.prod.outlook.com
 (2603:10a6:10:525::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:24 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 64f23e9a-991c-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=X1Lq4NfbRMoUUme+iW/ZmcTQaGLo3/1cFeQF+vPbNdKvo2yMI23JpLMVa4O1nFYqGRjglyn0RTaeQed7Laj94pxaTn1WbLALShurZJXMrmyU3LKyQCaM/PYr4usKe6Tgwx6QhHTMJYmTr6eCCZ5HzSiOybUoLyoaPDK5jiiRg+Yqgc6tkaItQWMxMiP7TzlyivxEmsevQCLoFEcp8DTjSun89hS+FdBRlkOy1SlHN6TyVV/Q9Kw30+MsO5gZmFCYtFGz6LzzFHQvpaiRqw1JzmUZ9hqqORx64YBcGBZzcR+SmVhe9XOp4TXQ9x/IB0Nv06ZYwN2w3ZKv7tZWu+QbVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4eHiYxqylL9naaTy3qk16KarDfJtDb7zV8vKSWL+Tjg=;
 b=LZK6K4xudjU09lhKYF52SAkc839z242xnJX+haXMsbjCa/qwQHoCnFqc0eP+i9lvfap4dmLm9Mc8GbCsmU5M/5Ckpa1a/ptRjvfSnFUmG4lOz1EAhy2NI4rxKMgsTvPmDUuOmtRW31HA0ts+xJkykwJZguanlJvOY13XisWuSNybg4ur1XxDcvmyY1nJrk0sYSgTV1LEYSoSEniKU6PSIjlD0wGugUMmlIw3/UAiMJiT4sYWBF5OCQWlZ5K5OV9jMSmgyvt/UoWmf2KVx1QcmzDWOPknP2KvYEyW38fYXhU6Npdkl6gA4l0ETPv9plf6yuGLVtZucTq6jGfh4XAkuA==
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=4eHiYxqylL9naaTy3qk16KarDfJtDb7zV8vKSWL+Tjg=;
 b=UmE3MFVDjHpCEyO+l9MU+KZyV8OSP9qltWMnJUVAv4m+kehqkanRX+/4Y5GIiRzQCjIoArCLwchzou/f/0Xq8k5zGekCibXsz7s8uyRunnJGbYanuqNy7UU0Muw8B6slK2FZMzR9fnjovea1e17eUOjkLD7Eb1sueaYGeTaZCZ9JvnM1sthKZ/gVIs/AwOZ/ptWmNm5621Vf9KQU2JvGJ5njhioY8/QP0qkcR8f83bxeYmYGN76M5MTsDFznfLgYn7jeEn2JcajTPVqbbu0XX7OBW3DaFLZ3mx2yf3ZfO5pjpQ28rvSRCqwG+4oLwKAFVrpJ7+olmqjsiMMR2lI04Q==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v1 8/8] arm/pci: enable vpci for hwdom when pci-scan is
 enabled
Thread-Topic: [PATCH v1 8/8] arm/pci: enable vpci for hwdom when pci-scan is
 enabled
Thread-Index: AQHcLSkkrFCa0+UvQk64FYmsNCFhTg==
Date: Wed, 24 Sep 2025 07:59:24 +0000
Message-ID:
 <2ac11726b5a236b022da5c51235e9a4efd92087f.1758618839.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_|DU5PR03MB10523:EE_
x-ms-office365-filtering-correlation-id: 5b503497-6275-45e2-ab53-08ddfb404711
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?FIqJeBUwzTddogCAwXZuOcupEjR5Zvlz1Lp06v+ckHIhYIRwQk7xL+v90p?=
 =?iso-8859-1?Q?qpBUrGAH8tOXtMtl/er+L7Gw//xVXwCD/wxNnYsn9JGoXE0DaYWX8aW5fQ?=
 =?iso-8859-1?Q?vZobbuZGLvKCclavaSeiRBQ47laRrMKjqNww3iVTSxmHaLx4jlqLOw9vOK?=
 =?iso-8859-1?Q?mUoTVpNQt2LuAvQnNQBaTVtriS9/R/tpWCembXtqYH3JT/BjUkQVB/ZQTq?=
 =?iso-8859-1?Q?RPDahSy0NGJJzYMs17rIue7p7I7iuDWKCiZ8MEh0XbuK/AS9/YdTv3KIMo?=
 =?iso-8859-1?Q?r8nXYhMVipXYysFpfiHf9sD5siUlZKJRFHFQt5hS8Y+xVAJys4KxexghYc?=
 =?iso-8859-1?Q?RV408wkeMtfnhXPBZUqBZceSpTtRrm6PSzIn+9gjHJ8pRpkpmGp4Ud/nQB?=
 =?iso-8859-1?Q?CtPGHYfheQ3eNiocG1vBVStDhS9HOKXyRYDI2KTKzT55AxDipaKKdjhmHt?=
 =?iso-8859-1?Q?CLSuQul0cPI5VUl9k+9WAuwNAu5DbBL8Srn+YMQGe9LEJgdsBdKmWWfutb?=
 =?iso-8859-1?Q?uNc5PrQcOHInIpOUQPU/BMrHFRIhPp5aYUfyCHRQoJYXuP77sIhZWVIelK?=
 =?iso-8859-1?Q?WaI49ox7B7EDcXh+gnCYLS4BAiOatFAaCWZ6BZwKPKMAxX+8sPtKC1r2TO?=
 =?iso-8859-1?Q?yLVEm7ZmjLZ8as5FnUOmGc+Kkfv7NS6rJvaUEEBC443RzTBHsuRC3ncSMs?=
 =?iso-8859-1?Q?pfYg8OgoWss8jN8zpQGHmUjNXRE5b2KjERka7LJbEs2FFKCOeAPwX4eKSA?=
 =?iso-8859-1?Q?eb/zoKtKo2k7Q8HJn4DO9jVGpMF4rvjiob24b+aa0UA99dm5WeTBFaxWxO?=
 =?iso-8859-1?Q?kSfwtjPLJsE+16tjer3BJHXCMVMEWsLEfBpPZf8Z4/daEH4AGejYAGJ9OH?=
 =?iso-8859-1?Q?IPy0WznlZMzWniBGyhZC3mOWlMN9Q8nYPfKIzX3xDrzhJraHVmoukNz1FA?=
 =?iso-8859-1?Q?duDGexb3BYWFcJWYywWPLmzYqu5PU+QjOaEdvbjpRIMbYJBQ0nohn8W2FK?=
 =?iso-8859-1?Q?B573VwaDCDNDkyAXqY2Pjv4cw7jAF4TrROjL6vWOdDQOAyfDgCD/Kiqejw?=
 =?iso-8859-1?Q?ECw9BC7ydkQbNyKPXJ/53FmD0bz/4zYMAiTUWGropvaEdQF03qHUtqCxmr?=
 =?iso-8859-1?Q?ADvuL8sWyjPf7abxq1MEXle0OsFhs4A6mlp+CtnYR6xykc22zVKy+4E9mX?=
 =?iso-8859-1?Q?Npv3WGzMu5KUbG7riQ5Oay4azM1cO4gqaZUbkfp0OfU3Ygn4CsNR98Ttzy?=
 =?iso-8859-1?Q?bzsdUPBROsrvLmPnLUOGA3SaJgKDq81qNO5g6xnmLMOkNmxFJ6luTTOJ9R?=
 =?iso-8859-1?Q?jlW3N+Ck5AL9FHogsvNxSLiIBQldr2zK6htcTSG2QwSPiB2nYEYISHHZDX?=
 =?iso-8859-1?Q?RV3k8CYUFQJliEAGRkDrwdCEEQaUHMiIb7HDE8EXTC7vYZzhInEK3BM7GU?=
 =?iso-8859-1?Q?Fn+aQ5zRdlKqn6xtYGUQWQ+yWSJ/yFM43VCBRGA8lTpUsAGmnsJjXEMUtO?=
 =?iso-8859-1?Q?zTA+8fdoALHYMNy44EgzpwtUI6aMxUGwxroRv+jrFZ1MKTXpexnpY2Fx/b?=
 =?iso-8859-1?Q?ncEx6RM=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)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?HY5ctcj8rZEZxH4MikYfQ+gduxtxLJepKs/VV00QAVCF6kJczqafF4Djz4?=
 =?iso-8859-1?Q?vTaXtjGLALxLD1vclKKRWaKB1iuadvbAHotcL60COpDf7Y/TSKSCn6u6RF?=
 =?iso-8859-1?Q?knB2AF+xsoKSc7GutY0g64oki5flqLAi8ZeDG4OfEw9jn/bADsXrIVTnLd?=
 =?iso-8859-1?Q?3HbxuwJC2gBPM3GGusaP5dw8Hgdmg5+SNnXxEVppDa+3rzqYxXqVN5SVPI?=
 =?iso-8859-1?Q?sgdUmGNcmT0id5n7SvLFLPLBZ6lFhd1bq54L9SQ86jb0HWlZmpwW9gQunS?=
 =?iso-8859-1?Q?ou6P1X8dH/6lCBDOdUIzt/3y4GMQBKko9tqygJ35S0iDRIS8fT8wCW4glh?=
 =?iso-8859-1?Q?r1ZFGcdm34UCM46zJi5SMjoraiHmQJAk5uFmMfsLvdPPPxGI98LI9eStlD?=
 =?iso-8859-1?Q?DSExXCmt/VZS3a4wukeAVQdutDLOrL+KQpujoXwivv8SSyq7XxpMPIn9Kl?=
 =?iso-8859-1?Q?dMxViryMCiZout4RxLnWxYASrpxKY6szUnzt4XWK1NScUhv53z0cD7a9MM?=
 =?iso-8859-1?Q?JKNLeuJcEK68akOz5V22GKnBggzXTtVR1WexA9PiIIth9ZByVsjC0LDVZ3?=
 =?iso-8859-1?Q?ImVnJ6N5OFNb0sfggkHXZTu19PG1I8Y4yY6BTGF0tp9hJr91HAE32Ld+9I?=
 =?iso-8859-1?Q?mg0rIDjZ8ZuIimTN8SdXyP4T620FrvYotfhLD4BJIJM+8e20GwAOLUr2Q/?=
 =?iso-8859-1?Q?z82TWTlarnB1OsGBlCqUraMI4uOrnPe0tEz3Nqt8GP8eLt+CLrpr/mdzma?=
 =?iso-8859-1?Q?/GfZSNPYzeqoGCs2eKHAnsH46PHokrvTlLTGM1nVKnaLv6rmKK1en3RBiu?=
 =?iso-8859-1?Q?w6phVBJ2LVsNK/ySEcwQ/5cwADcXE5xH+6lwJV5xCoVeRbgN7NE06DzdZG?=
 =?iso-8859-1?Q?+v+m2rumm1Fwn8FCC1nf2gQlIa336MRLdpAsbsRNXYdYFqUZlHMENRLQuu?=
 =?iso-8859-1?Q?lYEO3z3cJnYDDYoFYcbTTH+9yxWjNQcu9hWouGxQaqTfnpqqxdRE0AxxED?=
 =?iso-8859-1?Q?jV0mGnYIw3/NMdacXKZAkUtRRJB/jRwnjnBKjjef72pqw0ozcIjuaXr61R?=
 =?iso-8859-1?Q?xU3/8dQ+FACDsojHxwHhG1VXNd/p6IuYBLt6wbpduI/y9rsSrUIfBM23p1?=
 =?iso-8859-1?Q?iWPu3eUXzfxJYehIaLTPtIW1vr9UsT44gX68BfKgTgU2oc8SjpJ/F9W5+l?=
 =?iso-8859-1?Q?hyONv7/ngdcWfQApWHqrXarFbb6bgyS+cMkWQLxzL2Cc1zIoGyqLtiWNcX?=
 =?iso-8859-1?Q?G+Tvcjv4+4mj+czZOM9yEHP6uTum5tKYLaq3nubyWjU8EvU0VLZaoXEs48?=
 =?iso-8859-1?Q?bgZr1jfBuLIFBCvJAoR6WvyOaZR9ted+L2WCGvn/c3N+t/FgEWi5pJFtXR?=
 =?iso-8859-1?Q?HrqWbQdtNXeOI57KjAVQ5wCatkmTcBO3hH79hxpzqHO9KuwfdsLA+SKnln?=
 =?iso-8859-1?Q?+AtvWfjJ5OH77qyowbObi6DM9wAcFS2AICvw8yUFXALe+9TVUtYfz1dzv9?=
 =?iso-8859-1?Q?CYtn7cbbHli5P8yf5AwSSmUem4lcvcOWiGTjV5XOI7Y/bKgidixTAVeHmf?=
 =?iso-8859-1?Q?bu+sIKM1Zc8vLrNYG4UrM57kiHDbvf9L8H6g+WsEDceGaronZ6M9ayf0Ic?=
 =?iso-8859-1?Q?c7iaG4FNLHmTznoqNIoRmJK0VFh+Vs89JZtdc97Bn5Wdm5NFqBnFC0hQ?=
 =?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: 5b503497-6275-45e2-ab53-08ddfb404711
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:24.4781
 (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: ddc6Shw1P1AReHaP/QJpUx4aU8MqlYi3cZ4kbRnslP5u6dTi81tuW/N6W0IOS9o4IkVcL2ChdeHW8Bs1mxeFEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10523

With pci-scan implemented it is now possible to use vpci for hardware
domains. Update has_vpci to reflrect this change.

Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/include/asm/domain.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index af3e168374..dbe3347cea 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -305,8 +305,7 @@ static inline void arch_vcpu_block(struct vcpu *v) {}
=20
 #define arch_vm_assist_valid_mask(d) (1UL << VMASST_TYPE_runstate_update_f=
lag)
=20
-/* vPCI is not available on Arm */
-#define has_vpci(d)    ({ (void)(d); false; })
+#define has_vpci(d)    (is_hardware_domain(d) && hwdom_uses_vpci())
=20
 struct arch_vcpu_io {
     struct instr_details dabt_instr; /* when the instruction is decoded */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129032.1469169 (Exim 4.92)
	(envelope-from )
	id 1v1KPR-00085L-P8; Wed, 24 Sep 2025 07:59:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129032.1469169; Wed, 24 Sep 2025 07: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 1v1KPR-00085A-IF; Wed, 24 Sep 2025 07:59:29 +0000
Received: by outflank-mailman (input) for mailman id 1129032;
 Wed, 24 Sep 2025 07: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 1v1KPP-0007no-NV
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:27 +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 641925d5-991c-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 09:59:26 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU5PR03MB10523.eurprd03.prod.outlook.com
 (2603:10a6:10:525::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:23 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 641925d5-991c-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fY4Ocp1A3fYhI4EA4KWUYcla1ll3W5XYrzd2jGHJwUgYNNcNlc9jZuMpAX6TBQmoQ4TjftciKltRAexYpRM5hgHo2lliSTqj4Sm3YA9Af9yRZybqnuX06X9DKMOiocat/vhkBE5J8ZYSfQ5WcfKQpo+nX47DLj4a6PWIUz5aJsUVdw4RhMopQZvkyoeo8jXsR/oJJ63Zh3RLHwh8FjkGrFFi7t2rfY6nE8wzoWptldsgfqETdUGVVS2wjb60+psNquWGSqoKugKnqwKpFY7TPHQNbXkMyPjOjNhcHYYj7rYwOERPaLe2Tc7GgRS1wxqP/ojZRD/XGQO+D1J5f7RDzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bNV6Y6o2sz7AQ4bcrVfEpSjNRMiw4hKSwkvuVDIqZEw=;
 b=Q+SChlSXGtVoY2fj3b13oHnnznCG1aLfa1qEbjzGxunGbJxjHg6ggPU4nXVIOQqNbm7eT8mKYnMQ924Zj7/hghayGZZThjpGjXXJ9XNjEOg/t7fDUhHhLMmrGK8ngHdqONb9DMvi9CwGRSfxgswu6KoO/WUN1Ag10X3Vl+r3ShDKmPaAP1XVLlh+KzMj4vHYe0e0KBorMIcq0p0yQOnLwK3mjI2ElVbVDLNQm6WEun0umiKW21Iv8sNmLx+uS2FCtRPFsJtLYle5gGCQ2cWHDFuyPcr6TBCrUmTcy0p27HiICieg5CsEDSq7tfqx7Q66QozoxJ2qMiS03pA+W8K/yw==
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=bNV6Y6o2sz7AQ4bcrVfEpSjNRMiw4hKSwkvuVDIqZEw=;
 b=IQ3hyCZi9tQHBFAjl0Zgq1BLGMCA4w5Fc+qBs3/0K+Q220UXS4iTN3KqP51eiGkcpe9Fu3d48OZDzT9jWxgyVbYi4Wdic4AKNgUvjKEfb3bVg2w4u5dfHjR/5VKGsJp4CimFfJk7msQreSazDqThr7U6SJPWykEtKhG9TdfqBQ4JDEt51LhujXpoDGqH0PAuj3apuiSN4iJHHa3XZU0+WSV0OS9j2wpMt/VeRO+DLwDzQP0Xs+y8RsyXPtntMo/cw6R/DuntmR6AM2dDOyImrMnQ3CumKSSlzrBJtQIecY1az/GGcorutvoo6tF9uDlqPE+G/4OuocqS2bJ9qEWVPw==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Andrew Cooper
	, Anthony PERARD , Jan
 Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Mykyta Poturai 
Subject: [PATCH v1 6/8] xen/pci: initialize BARs
Thread-Topic: [PATCH v1 6/8] xen/pci: initialize BARs
Thread-Index: AQHcLSkjNTjer4+LIk6OKFhehALrog==
Date: Wed, 24 Sep 2025 07:59:23 +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_|DU5PR03MB10523:EE_
x-ms-office365-filtering-correlation-id: 50217c18-6c5b-478b-286c-08ddfb404688
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|376014|7416014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ZQmZYdC88wbYFBHsn+GKuGdChUZ0pmiA8Dz0HemuszMk8HWJhC14SinMqQ?=
 =?iso-8859-1?Q?IWKBzrNRtJTZ7QnzshnA8gmxKs/ciMOxSY/9hDkJuhmah5SMj1LRSCOUra?=
 =?iso-8859-1?Q?/J24EAXX8WDoY5y4uUp8OHvBaq5fPvu/8/C1uuXxif9488n5yk01AsJWiz?=
 =?iso-8859-1?Q?7R+uY/Bpp5F5asnd+eoDaQtpaL1rn7ehMC4nwn/yUat0TYgW8KjqL6kjhb?=
 =?iso-8859-1?Q?ECECT6KPNi9Rt3KrKLffRxD2D3mHoiaRvfs7NVNrhG9+biKV096b/6iG1q?=
 =?iso-8859-1?Q?FhRKMGZ5ScIjm0JR5PoRmRihBkXMT5d2nZO/2j4uLd6yMEHglZNQvP262t?=
 =?iso-8859-1?Q?lNXJ4YzOSASrN3jFDQNwtiKw5glSTQ5dzLISNqu94bdpfAFiuC9WDJq8M5?=
 =?iso-8859-1?Q?p3W74CC49O4mG9aNaw6bRDCfyvAkrHLfWJCWLwgA8dvgiiJoLa0f4pE9Ea?=
 =?iso-8859-1?Q?FfNE1+ejOsAvkCqTMbowvwOvf4wzZ18dgBsidnP6L8NT2X9bkvurLApddC?=
 =?iso-8859-1?Q?BXowPv3znZ42wrzviK5lxlnewYk6OWSCrZP035FeptVicjP0qQg0qz8jYf?=
 =?iso-8859-1?Q?TEn0odfboBOB9zud7wPMJVLyQ/CLPbWtPvHmZuBnJQu5oALPSpwElRz1nf?=
 =?iso-8859-1?Q?K8IM73k4Mw5BjBSLW2sudwa/jL0krJOxQtrb4p8rZ63/4jj/KpqvfVRqdp?=
 =?iso-8859-1?Q?xnYK3z83iwX75hRLyJwdB/9fQ8XSsPIH31c58dn4G57QKPV1bUBJHtNUDp?=
 =?iso-8859-1?Q?Afo6IpfHsP2gNEf/sfMP1O3e7GwUaeSU/nk+ldhtTXwvOHUTrF6/C9E364?=
 =?iso-8859-1?Q?JG3Xxz7iL5/0qULHOAdI85CukvE9Rii9NEy8x+yzUu63pXGjWNIv+hcYVN?=
 =?iso-8859-1?Q?NsHOZ3IZnvo4MtDFB2Szz0+KKIYMw9c365JOnV5b27j/EVnYCst8O5qycG?=
 =?iso-8859-1?Q?8rWpWniBiRIP96PhT6hudDYjWNodJ9LF4bu9mvLqECmv3SGJ7S911y6y6D?=
 =?iso-8859-1?Q?c9S/vEr5ZM8RtyZSvmmLDIHbuJBuYwSMP9xq6h2Rjsnyaqlxty/hq8AtL8?=
 =?iso-8859-1?Q?o2j6JuBe4oJvftwm6IcOHzcZs3SgeOfgMOuBYp9+NqMV45WdC1NWKRyvN7?=
 =?iso-8859-1?Q?eWVhiF2tUrVpfgSkDgkNJs5ZfIjzw4Uq9qJIcsga1g1sHpn9xJ5oo7aH19?=
 =?iso-8859-1?Q?PMAHPVzXjeCMA6omL6fuz3D5mKHuaVZAqWKSRZ15rGnImDVjhWpf//JjRM?=
 =?iso-8859-1?Q?jAQrwLOMYmJt0h/cM5MSvVVOEWthx61z5An3OGpMJPokl/unwA7AxF+e4D?=
 =?iso-8859-1?Q?2stgBosBiwBbBT2f0/GFkV3naNoGJoaVLdXdfuqV9P+7b00I7rHEUQbjOY?=
 =?iso-8859-1?Q?APkHHBBkau0NvDZgB9yYPC5UUOSrD91kR24Ki5odEpzf3520DHGOopTp5a?=
 =?iso-8859-1?Q?sfT+cJquSy/xQoxJd29TKM5cpKDwG2snlTpqsTIU3phMUU1+0999VErrEt?=
 =?iso-8859-1?Q?W2DXF50A9UA3wsPKBjTOdL9wCTJm5AsQJCDYh/DFlE79of9JpAfNV8tl6J?=
 =?iso-8859-1?Q?oH2ysY4=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)(376014)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?bilJVjYo7T88EBH9D3E/iIS31Ogl+1diuZvmXE62zhqX7M7IR6viEqZ5j8?=
 =?iso-8859-1?Q?dL0Uw8RFyBKOEctQtUBKBcQpnAZJOgh3N+11DhOxKghuKT+5fBeYvYLFh3?=
 =?iso-8859-1?Q?z+dlajZrgxFvc8s+EopD8vw+Q9FlTcUZE11J66sMuvHUiGnklBhK7mG9OG?=
 =?iso-8859-1?Q?ID1BUA5xvOvj1VV/AJN2iIuGn/2V1YGhNZXFsIWOMTErfrPo/1/+PxV51n?=
 =?iso-8859-1?Q?owpAuZStNth+HynJJNs8sYCAAuS5bUHGa1xNC7bS0cHo9O9GPOPNGhPtVh?=
 =?iso-8859-1?Q?j9YZpDiQE4Bx4IsknHOn500XjjkZ+CVGNANNvugtRHQZHVoLf2FYMspxJE?=
 =?iso-8859-1?Q?qfKEk0NwBIm1n/dxOgjVyENrIdZPUze8Wm8h8b7U6Jf5xv+67JVZ7PJLW7?=
 =?iso-8859-1?Q?9kWK5q3OiBxd6i0277u7AY3hTOsvhIIbm5I01bUUcR5ehOktrEjvLFR3Ti?=
 =?iso-8859-1?Q?KvngpOu+t6MtNJjt7bxSxab/le8rivB7G3ENMa76+spEFPcXq2axsm3qeu?=
 =?iso-8859-1?Q?BJxq4NE6dFyvPkUhdK97+i/DWqZbJMGdBetxvZ2hGj2gZRWmjuuGasIcnH?=
 =?iso-8859-1?Q?ysPmvQGh/ocO50Gn4cSf8bst+lehz7YclTL1LGqrK+Zwvha37HszeeRnXH?=
 =?iso-8859-1?Q?8KHcUHUSGrCnkbMD3V3GF0JKLNwSsoBO/AWL+OBpEKv8+nhf9HNSI0bd67?=
 =?iso-8859-1?Q?YJnrEEemk9w/sYyoz9EaiH2TzhfjYMDCz4796H+voJ6AXoB5w39uS5KiK/?=
 =?iso-8859-1?Q?Nxn/nnGXM7+wvwV+qKc4AjMD9u7Dsh9FIwzbzE6A5O5/BkEHYcPHrcOABK?=
 =?iso-8859-1?Q?3xoblzcTIi0dRK26yEkD518S4gY5X0Bj+zrU4HQXYWq4F/rmmPDZgBjv9Z?=
 =?iso-8859-1?Q?KW+kBOMkvJYHGZ6H/XVO6II5vYkRKx9/ZwLz0GkZHYIsaL5b1eUhin4YsO?=
 =?iso-8859-1?Q?Ms1FXJ5R5n/E6G8f3NN4WZZHo0fojUckaBhThuHUALw+8sX6l1opJ5DhR3?=
 =?iso-8859-1?Q?PItO3QldMZTUji9k1MOYtvYUpNomfD1sl6KgLQD2lJhGpeBUhWNTLewx2C?=
 =?iso-8859-1?Q?d4B8eTPBmrF9IW/znoTu6ffE/hacig63qQLNWucmQ1Hcx71WKC7CMNga6P?=
 =?iso-8859-1?Q?4weROrVy6MysobcmIgbCy1GvQMODi6v1Ufyp2JtxLx8EFwYdgM8LHBAz93?=
 =?iso-8859-1?Q?WmUKq+Bu5avpVaXWII0a3jJ9zI/Qo4zcFQsR2M34CSZ5yjfhLs4MktxPtd?=
 =?iso-8859-1?Q?rAs4IQMtHB8alU03pnFPpRDR1kqjMVaZndO33P7mhT8sAzVbHRUMtegSOH?=
 =?iso-8859-1?Q?AJQTx+Io0QpfCQ28jXrJmg+BnevWZjyrpUgnHz9X98K74nj0F4MuPiXa5T?=
 =?iso-8859-1?Q?zJPoF9eBko//AtFKtDHw9/LpzG8spjJmM45SXbwZIja7G8K8JHukxLbLww?=
 =?iso-8859-1?Q?DFIAonoJCh/4BhCXxLqYUUwydMGWr9ww6UWs8PYHqcv0DTWSRNVjCzbjgU?=
 =?iso-8859-1?Q?30TH5QN399HYlhVIMULtMOr1Z0yI7+K0sZxRW+Uqar0wR7wc/jml0jEWqK?=
 =?iso-8859-1?Q?O3VP7wrXRiE+7SmtbbD8/OxL7t14R0KewcrKFgCPLqG194O+iqY+IFIEkG?=
 =?iso-8859-1?Q?kcQbwWPeiAxgvjF6zpiFhPwk8puQ/wHMOH7Uv5j/6exMAaBrfMm5+oeQ?=
 =?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: 50217c18-6c5b-478b-286c-08ddfb404688
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:23.4293
 (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: uF5EnbxXLgFxVHEUWqmQcS59oRDUv/yKRMxpTNnk5a9MfPl1zU09DPHDutMzr1wwQZybcjaJLwcNtHIxyL7T6A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10523

From: Stewart Hildebrand 

A PCI device must have valid BARs in order to assign it to a domain.  On
ARM, firmware is unlikely to have initialized the BARs, so we must do
this in Xen. During setup_hwdom_pci_devices(), check if each BAR is
valid. If the BAR happens to already be valid, remove the BAR range from
a rangeset of valid PCI ranges so as to avoid overlap when reserving a
new BAR. If not valid, reserve a new BAR address from the rangeset and
write it to the device.

Avaliable ranges are read from DT during init and stored in distinct
rangesets.

Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/include/asm/pci.h     |  7 +++
 xen/arch/arm/pci/pci-host-common.c | 78 +++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/pci.h     | 14 ++++++
 xen/common/rangeset.c              | 35 +++++++++++++
 xen/drivers/passthrough/pci.c      | 79 ++++++++++++++++++++++++++++++
 xen/include/xen/rangeset.h         |  6 ++-
 6 files changed, 218 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 4fc46da315..ba4caa56ae 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -74,6 +74,8 @@ struct pci_host_bridge {
     struct pci_config_window *child_cfg;
     const struct pci_ops *child_ops;
     void *priv;                      /* Private data of the bridge. */
+    struct rangeset *bar_ranges;
+    struct rangeset *bar_ranges_prefetch;
 };
=20
 struct pci_ops {
@@ -154,6 +156,11 @@ void pci_generic_init_bus_range_child(struct dt_device=
_node *dev,
=20
 bool arch_pci_device_physdevop(void);
=20
+uint64_t pci_get_new_bar_addr(const struct pci_dev *pdev, uint64_t size,
+                              bool is_64bit, bool prefetch);
+int pci_reserve_bar_range(const struct pci_dev *pdev, uint64_t addr,
+                          uint64_t size, bool prefetch);
+
 #else   /*!CONFIG_HAS_PCI*/
=20
 #define pci_scan_enabled false
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index 67447d8696..bfe610a403 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #include 
=20
@@ -232,6 +233,21 @@ static int pci_bus_find_domain_nr(struct dt_device_nod=
e *dev)
     return domain;
 }
=20
+static int add_bar_range(const struct dt_device_node *dev, uint32_t flags,
+                         uint64_t addr, uint64_t len, void *data)
+{
+    struct pci_host_bridge *bridge =3D data;
+
+    if ( !(flags & IORESOURCE_MEM) )
+        return 0;
+
+    if ( flags & IORESOURCE_PREFETCH )
+        return rangeset_add_range(bridge->bar_ranges_prefetch, addr,
+                                  addr + len - 1);
+    else
+        return rangeset_add_range(bridge->bar_ranges, addr, addr + len - 1=
);
+}
+
 struct pci_host_bridge *
 pci_host_common_probe(struct dt_device_node *dev,
                       const struct pci_ecam_ops *ops,
@@ -286,6 +302,14 @@ pci_host_common_probe(struct dt_device_node *dev,
     pci_add_host_bridge(bridge);
     pci_add_segment(bridge->segment);
=20
+    bridge->bar_ranges =3D rangeset_new(NULL, "BAR ranges",
+                                      RANGESETF_prettyprint_hex);
+    bridge->bar_ranges_prefetch =3D rangeset_new(NULL,
+                                               "BAR ranges (prefetchable)"=
,
+                                               RANGESETF_prettyprint_hex);
+    if ( bridge->bar_ranges && bridge->bar_ranges_prefetch )
+        dt_for_each_range(bridge->dt_node, add_bar_range, bridge);
+
     return bridge;
=20
 err_child:
@@ -476,6 +500,60 @@ bool pci_check_bar(const struct pci_dev *pdev, mfn_t s=
tart, mfn_t end)
=20
     return bar_data.is_valid;
 }
+
+uint64_t pci_get_new_bar_addr(const struct pci_dev *pdev, uint64_t size,
+                              bool is_64bit, bool prefetch)
+{
+    struct pci_host_bridge *bridge;
+    struct rangeset *range;
+    uint64_t addr;
+
+    bridge =3D pci_find_host_bridge(pdev->seg, pdev->bus);
+    if ( !bridge )
+        return 0;
+
+    range =3D prefetch ? bridge->bar_ranges_prefetch : bridge->bar_ranges;
+
+    if ( size < PAGE_SIZE )
+        size =3D PAGE_SIZE;
+
+    if ( is_64bit && !rangeset_find_aligned_range(range, size, GB(4), &add=
r) )
+    {
+        if ( rangeset_remove_range(range, addr, addr + size - 1) )
+        {
+            printk("%s:%d:%s error\n", __FILE__, __LINE__, __func__);
+        }
+        return addr;
+    }
+    if ( !rangeset_find_aligned_range(range, size, 0, &addr) )
+    {
+        if ( !is_64bit && addr >=3D GB(4) )
+            return 0;
+        if ( rangeset_remove_range(range, addr, addr + size - 1) )
+        {
+            printk("%s:%d:%s error\n", __FILE__, __LINE__, __func__);
+        }
+        return addr;
+    }
+
+    return 0;
+}
+
+int pci_reserve_bar_range(const struct pci_dev *pdev, uint64_t addr,
+                          uint64_t size, bool prefetch)
+{
+    struct pci_host_bridge *bridge;
+    struct rangeset *range;
+
+    bridge =3D pci_find_host_bridge(pdev->seg, pdev->bus);
+    if ( !bridge )
+        return 0;
+
+    range =3D prefetch ? bridge->bar_ranges_prefetch : bridge->bar_ranges;
+
+    return rangeset_remove_range(range, addr, addr + size - 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.=
h
index 08e8959d0d..2cabbbb5d0 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -82,4 +82,18 @@ static inline bool hwdom_uses_vpci(void)
     return false;
 }
=20
+static inline uint64_t pci_get_new_bar_addr(const struct pci_dev *pdev,
+                                            uint64_t size, bool is_64bit,
+                                            bool prefetch)
+{
+    return 0;
+}
+
+static inline int pci_reserve_bar_range(const struct pci_dev *pdev,
+                                        uint64_t addr, uint64_t size,
+                                        bool prefetch)
+{
+    return 0;
+}
+
 #endif /* __X86_PCI_H__ */
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 0e3b9acd35..c1c6f8610c 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -357,6 +357,41 @@ int rangeset_claim_range(struct rangeset *r, unsigned =
long size,
     return 0;
 }
=20
+int rangeset_find_aligned_range(struct rangeset *r, unsigned long size,
+                                unsigned long min, unsigned long *s)
+{
+    struct range *x;
+
+    /* Power of 2 check */
+    if ( (size & (size - 1)) !=3D 0 )
+    {
+        *s =3D 0;
+        return -EINVAL;
+    }
+
+    read_lock(&r->lock);
+
+    for ( x =3D first_range(r); x; x =3D next_range(r, x) )
+    {
+        /* Assumes size is a power of 2 */
+        unsigned long start_aligned =3D (x->s + size - 1) & ~(size - 1);
+
+        if ( x->e > start_aligned &&
+             (x->e - start_aligned) >=3D size &&
+             start_aligned >=3D min )
+        {
+            read_unlock(&r->lock);
+            *s =3D start_aligned;
+            return 0;
+        }
+    }
+
+    read_unlock(&r->lock);
+    *s =3D 0;
+
+    return -ENOSPC;
+}
+
 int rangeset_consume_ranges(struct rangeset *r,
                             int (*cb)(unsigned long s, unsigned long e,
                                       void *ctxt, unsigned long *c),
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 3edcfa8a04..4f5de9a542 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1172,6 +1172,80 @@ int __init scan_pci_devices(void)
     return ret;
 }
=20
+static void __init cf_check reserve_bar_range(struct pci_dev *pdev, uint8_=
t reg,
+                                              uint64_t addr, uint64_t size=
,
+                                              bool is_64bit, bool prefetch=
)
+{
+    if ( pci_check_bar(pdev, maddr_to_mfn(addr),
+                       maddr_to_mfn(addr + size - 1)) )
+        pci_reserve_bar_range(pdev, addr, size, prefetch);
+}
+
+static void __init cf_check get_new_bar_addr(struct pci_dev *pdev, uint8_t=
 reg,
+                                             uint64_t addr, uint64_t size,
+                                             bool is_64bit, bool prefetch)
+{
+    if ( !pci_check_bar(pdev, maddr_to_mfn(addr),
+                        maddr_to_mfn(addr + size - 1)) )
+    {
+        uint16_t cmd =3D pci_conf_read16(pdev->sbdf, PCI_COMMAND);
+
+        addr =3D pci_get_new_bar_addr(pdev, size, is_64bit, prefetch);
+
+        pci_conf_write16(pdev->sbdf, PCI_COMMAND,
+                         cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO));
+
+        pci_conf_write32(pdev->sbdf, reg,
+                         (addr & GENMASK(31, 0)) |
+                         (is_64bit ? PCI_BASE_ADDRESS_MEM_TYPE_64 : 0));
+
+        if ( is_64bit )
+            pci_conf_write32(pdev->sbdf, reg + 4, addr >> 32);
+
+        pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
+    }
+}
+
+static int __init cf_check bars_iterate(struct pci_seg *pseg, void *arg)
+{
+    struct pci_dev *pdev;
+    unsigned int i, ret, num_bars =3D PCI_HEADER_NORMAL_NR_BARS;
+    uint64_t addr, size;
+    void (*cb)(struct pci_dev *, uint8_t, uint64_t, uint64_t, bool, bool) =
=3D arg;
+
+    list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
+    {
+        if ( (pci_conf_read8(pdev->sbdf, PCI_HEADER_TYPE) & 0x7f) =3D=3D
+             PCI_HEADER_TYPE_NORMAL )
+        {
+            for ( i =3D 0; i < num_bars; i +=3D ret )
+            {
+                uint8_t reg =3D PCI_BASE_ADDRESS_0 + i * 4;
+                bool prefetch;
+
+                if ( (pci_conf_read32(pdev->sbdf, reg) & PCI_BASE_ADDRESS_=
SPACE)
+                     =3D=3D PCI_BASE_ADDRESS_SPACE_IO )
+                {
+                    ret =3D 1;
+                    continue;
+                }
+
+                ret =3D pci_size_mem_bar(pdev->sbdf, reg, &addr, &size,
+                                      (i =3D=3D num_bars - 1) ? PCI_BAR_LA=
ST : 0);
+
+                if ( !size )
+                    continue;
+                prefetch =3D !!(pci_conf_read32(pdev->sbdf, reg) &
+                              PCI_BASE_ADDRESS_MEM_PREFETCH);
+
+                cb(pdev, reg, addr, size, ret =3D=3D 2, prefetch);
+            }
+        }
+    }
+
+    return 0;
+}
+
 struct setup_hwdom {
     struct domain *d;
     int (*handler)(uint8_t devfn, struct pci_dev *pdev);
@@ -1263,6 +1337,11 @@ void __hwdom_init setup_hwdom_pci_devices(
     struct setup_hwdom ctxt =3D { .d =3D d, .handler =3D handler };
=20
     pcidevs_lock();
+    if ( hwdom_uses_vpci() )
+    {
+        pci_segments_iterate(bars_iterate, reserve_bar_range);
+        pci_segments_iterate(bars_iterate, get_new_bar_addr);
+    }
     pci_segments_iterate(_setup_hwdom_pci_devices, &ctxt);
     pcidevs_unlock();
 }
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 817505badf..e71e810f82 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -56,11 +56,15 @@ void rangeset_limit(
 bool __must_check rangeset_is_empty(
     const struct rangeset *r);
=20
-/* Add/claim/remove/query/purge a numeric range. */
+/* Add/claim/find/remove/query/purge a numeric range. */
 int __must_check rangeset_add_range(
     struct rangeset *r, unsigned long s, unsigned long e);
 int __must_check rangeset_claim_range(struct rangeset *r, unsigned long si=
ze,
                                       unsigned long *s);
+int __must_check rangeset_find_aligned_range(struct rangeset *r,
+                                             unsigned long size,
+                                             unsigned long min,
+                                             unsigned long *s);
 int __must_check rangeset_remove_range(
     struct rangeset *r, unsigned long s, unsigned long e);
 bool __must_check rangeset_contains_range(
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129037.1469215 (Exim 4.92)
	(envelope-from )
	id 1v1KPU-0000k5-Q3; Wed, 24 Sep 2025 07:59:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129037.1469215; Wed, 24 Sep 2025 07:59:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1KPU-0000gd-Ig; Wed, 24 Sep 2025 07:59:32 +0000
Received: by outflank-mailman (input) for mailman id 1129037;
 Wed, 24 Sep 2025 07:59: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 1v1KPT-0007np-E1
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:31 +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 65ea5722-991c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:59:29 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB8118.eurprd03.prod.outlook.com
 (2603:10a6:20b:445::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:22 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 65ea5722-991c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fE/Y5HaNfdLRN3m42138AiaC5jBKVwBxgjcrxIxLonSGvCn9/ujonyhy9gurupGuFwD/gUcNaBBZ45y8sJzwceyFAyEcfffafVlpK2ak6ef/w+byLmhnR4KGS04FsOOVPOt4HnKbvk06U878FMn9ZTNdhCY4rHSN/lt32jn4VUgUq9v8Z4djCM9GgR9yZxmqQopbGC2wB2tkLDmW5rdPHzROXo25bLdfiNCosO1kF9Cux68ppQTXIwN3Q4ywjLLWw0SDAyeAdpYk2jRwxaRp8nylbj4sfLbC7Uk6xD485ScBvGPtSnx58QTfPQ9uCaAfkO7KIzcOaxorPAxgpgl6ow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jXNUfWRmkjORiC7yyrgzg//uXWPFCbV0Om1VThH2SYk=;
 b=ItX+9E4+w+7t0pHFqrQ4FYGoBSkgGj/wA4WFRKDolTylceDjiZTLX6Y1Xtj1sqV4wRdYsueHGQNKohihBju69uYXbcJ/QJg8OXuyys+vqnF4uONljx7LaxAq8tjQS/1JP5io0r4IbI1bMQO6arhdn6RMG81bWAh6oZn67sHH+L7GTy2T85JrfPsylk1ThvkRL6h9h3CX2iYOSVL2kFGcF9NotIn/P0uylBOdneFkga/o3aaHObbjzfHDfDC0YaTOx19qgNsEkabjZodmUVbwiIdvl8jhzSFZmyvIEwVpBnzNzKv1vqDCZVhw+5L47sPdXi2hR/5VYxkaFf/3ObmECQ==
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=jXNUfWRmkjORiC7yyrgzg//uXWPFCbV0Om1VThH2SYk=;
 b=N5RaAnOuss5j/0K09zkWs+LTL0Gk1sF1+OoRxtLq16NazsDl8b9eq+Fcs339TMyJYaYKfycyiIcL5yQ6gUGP03QOj+HhxuaAwXcnV1NMLo6XKyRyjA+uadO1+NCnvjIrL+K+8WJ8+9HmfnFAXtb9rZMGwaxnb20CLOpzEtHyZIda15dGc4tROijpSmvtqHJ9Nr+7Q6QlCiekXv2Jy8CZDxIOYNpbL+JuA9wJ8vxa8pTJKVtZKpOHavRuqQDqmCICCUF/D5iJT1AkcUMYuUBe/OrxFIIbp7TIODbjZo7eJBPnYqERHzuVEczMMI92CjWmOYUUldpk43HPlhfT9tMYcA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Luca Fancellu , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v1 3/8] xen/pci: update DT for hwdom when it uses vpci
Thread-Topic: [PATCH v1 3/8] xen/pci: update DT for hwdom when it uses vpci
Thread-Index: AQHcLSki3XdXcYrDmUyuu7Fte47UGQ==
Date: Wed, 24 Sep 2025 07:59: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_|AS8PR03MB8118:EE_
x-ms-office365-filtering-correlation-id: 3f5f2b92-c18f-4538-e5f4-08ddfb40457b
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|376014|7416014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?qjHsEZSfTN/Yue0EZAHmJjDJpuDD2dvx3uYSCPc9L8lFK1VlEGkDotlSVV?=
 =?iso-8859-1?Q?nON1xaJlFVdzT8wmwR/ts+XYQgTYRruErVBY2wQIH/TAtBiPYTz1xSPU1N?=
 =?iso-8859-1?Q?+ywlpFB903tdNa4KuRwBubIh2aWWUsBvQMCRK1pyCTyBgfoPhtmhvte8YZ?=
 =?iso-8859-1?Q?UA5k6JvO/eGNU+N0gOAjM8Kpp9xnWoKBNXfTaBqEIE8zL12v1FTIyeDLaD?=
 =?iso-8859-1?Q?A3I0DZtFB3hpPMRLRwLP3y6qoNzYL6/24q0SLV57eZtw+nevJZIWNT0m+4?=
 =?iso-8859-1?Q?1ezeJ7+czIdmtcpavUQgLjAN7lKP/1vmhoZF8lz0IgOHaoj1IiDOL6KLKV?=
 =?iso-8859-1?Q?C0VG2hJj5wSsWPgEyX0whrIESrqvDAsDqbZPLCRkqKbLGSGzimeKzIM+rR?=
 =?iso-8859-1?Q?NQ5tJ9nk/urf3IR0VuGYf3KYcB3xtrwpZdytahwduMApKDl72oNwfnWQ6e?=
 =?iso-8859-1?Q?cLikheraQBxrpR1HQOfM1TaENolKXW9t4yh3yGd1A+dOS4O0fRE9caCK3Q?=
 =?iso-8859-1?Q?duXd1ZXT6g0qihri/z/YX3wqv0aTBbEY7oy4vVLwgHqt4QZvJ0jxNIyIba?=
 =?iso-8859-1?Q?gigicZcB0V4qVvXK7hUwT9uwaywPYeBuHmsUUsNl07/ItvvW86E82Lnxjw?=
 =?iso-8859-1?Q?phNbOeMD5fVev6XcxoCAQpTyDloKa6jKfPFnRHB0R7zqpZY9fZ6CfJsCz8?=
 =?iso-8859-1?Q?egZm8qc/3+dYnu3joQzPs/PT0OwITlWIiQtegxrX1UV1ZS+5ZM/B6N4tAK?=
 =?iso-8859-1?Q?h4LJIfrduLnluyX4C0N2O0ez2eGsxf2fI0cU8ju2jpTtk5ZmtPZ5927PWk?=
 =?iso-8859-1?Q?2UE/qwR7Zp1imyrQ0KkIRoqQfyfqnhI9rXvaDpeB46MWWGtk+r3tSWhD8Q?=
 =?iso-8859-1?Q?W5Cy5Zf1EHhNkPSNHrxL6O6TemCoBr4VEZPWfOtjNljDH5V3zNlwn9ZEzz?=
 =?iso-8859-1?Q?DnauFwrSd5Tip+UHnYfbvjlQm1pZbsDkIEVbfK+AF2Y6WFAdWJKIMSUz94?=
 =?iso-8859-1?Q?FJoLV1PKV4XlcU5PmYxf9v9et7D+f+5n630N84GaHBUcFaSEUWVCae0Hq3?=
 =?iso-8859-1?Q?kMtPibXe4TERWZ3DgewiP8+PIBILeua4LLNuMKvkUvruuZ21i0jKWjPfMV?=
 =?iso-8859-1?Q?YepKSB1VjEiS84VD8pNHUG5afWTRhwzk0SXNxzZ9/U0ik/ssAKLhzwP22Z?=
 =?iso-8859-1?Q?O2C+Q2SHr0ZnSCgC/tiG9svTDFG1O/++XHlq3cZ6gUNsyADUfWQfbRdaNP?=
 =?iso-8859-1?Q?Z09zh4jYb/WvpwrTh2ayi6mTU8Sa9WwR/CBZHCkhHDSl7CuC7pIZkoouwd?=
 =?iso-8859-1?Q?mCdfnbTlAWvlAUBMcwT4jA2exXMJw8b7qx6gK57308BiPs+4cfZdQfgknR?=
 =?iso-8859-1?Q?himGKu4W7UlJs4h2U6hwBuPSrSPGv3CSF2E6z4rj/5lg3R2paaGUNnjyWe?=
 =?iso-8859-1?Q?jYm8HBmAhcuZIoPNpsEBMC+axmDrch8GCOErjuKVWGq1SbaRUp9lgqehJL?=
 =?iso-8859-1?Q?bbQ7csud+7PStL//gpN9hjWezRlxEh2IrHAlV1vMLMnAbz2v9KexXrG0KS?=
 =?iso-8859-1?Q?ChAEU7k=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)(7416014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?3ND8saamag5hUylyhfZ2GcxCaHC0Ni86l/VWm+s+8JOpxWHV+/3IrIcxsg?=
 =?iso-8859-1?Q?zldrhjb/XhnmPTL1ILwdlYPVgdaofIP1nfc1I6Qzc6N8k/7lno/8cwSNpc?=
 =?iso-8859-1?Q?AezxBFWbx9mgLBil8yDCeblhRfJ92Vi10IxSQucR/8tLku/etBldp8UTrN?=
 =?iso-8859-1?Q?v8evmQOEGGRbVxl7Yiu02T1NLAx5hXzrjopaDLhYsIF+mqQb9p8k30uB2H?=
 =?iso-8859-1?Q?ladPiRCGDVhEKUXLNyzkeVADKiizynJblJBUDZmK8Ri91ySdr0hoVI7UeF?=
 =?iso-8859-1?Q?OZ1LfLS3nmA2lDg8hEdfbiKMsHiCqAXYilxmGLmKS00FoSUpS9dCbdNmEi?=
 =?iso-8859-1?Q?Nn/pVjeq+PJXhJDePTuIyxNHUBDzfPpbOvjYjTmhkzFY+6J1Wyh11w3s3I?=
 =?iso-8859-1?Q?suyXGf4/36I/zQ1+m7Dd2He7aF7vLOf4/MHYJLo501SqIJRrGAeo5PbhFG?=
 =?iso-8859-1?Q?T6oVL5xBZwRil6Rm2CCTQPitRw+QZYck7OgCG9hChTBVh6l8rREuoCfhn1?=
 =?iso-8859-1?Q?0SH4ZPNZ/jxI4+r67Nwe/zGe9cR/bI6MvFS+G8Lu6UBxJtn71b3wPcT9b8?=
 =?iso-8859-1?Q?LMegUPwhBLVHiypOH8Zdf/BOnGwtD7wBqjFtC60Y8oLjqrM/RlIvwhpd0M?=
 =?iso-8859-1?Q?hP167Yz28yOLLuJ25uBGshVwkuAkFdH49lk9sr2zEaICeS6cJro9X3b//x?=
 =?iso-8859-1?Q?z+k7ZNJDAzFqlvkWloV/oSj09lpRP064WZD4J1RUrVMtF9I0eKld+OUe4H?=
 =?iso-8859-1?Q?126BaNkG+HfIYTXlvbnZuLrKuLDYRT3AnLoM/GssscQffKUkEONM5hE9xX?=
 =?iso-8859-1?Q?huX7TWGPk3qhelH6GVaS8bhPSfgGymG6vq2OraKmYPn6kUXjStqPpIkNOq?=
 =?iso-8859-1?Q?cglhblt3vTHcW3VPikybfzVjifBmGgDen3o5ovxZRB0jbgptHrPMgllBRy?=
 =?iso-8859-1?Q?Sj6DT9WdGizlt4X/dpLtWVTyWc3bZG4oA7UJmFf+nlpoQElzRMFyKT2lbP?=
 =?iso-8859-1?Q?QQUH2FyE1/YWbsKDmDUgA/QSO04r5dPPNtrg4N2zD0XSf1sYm9ABkbAESQ?=
 =?iso-8859-1?Q?k5SdWefsMX8Pnv8uv7kv8JJGuHZw6qC2VCncqgxDc7rKKE+qfhkvaL9K4O?=
 =?iso-8859-1?Q?jGZPxGoWWcUXiD4D/BXZTLY6qQn0P80x/V4mJRXMxxWbV1l/Rb9t8hp1sX?=
 =?iso-8859-1?Q?uuSjdqzuGEGf6iyyR/aXdZP0PAPYCtKn7SzvSv8WwZPoLZLGlgy1d9D91O?=
 =?iso-8859-1?Q?WiuI60TLV6IadRMCP2cqjCpDpxwqwsaS6AxXcVBF/8MaI3IvEHCBKV9LTC?=
 =?iso-8859-1?Q?ka1+XZTyR8uUV1maDldbC0HRDCfRHEHjdbZv1ka3wvPmFtA5jIitUUfXmz?=
 =?iso-8859-1?Q?e2V8i1QV9X+opAQjbPZCmAjz0aE3RwL8vgtiYxEomi2LAbz1/BdfgeMR/I?=
 =?iso-8859-1?Q?a8RwNsZWbUnpYOnJ7l9Y2c+OQNCgS23Yp2ThFy1XbKcV0DQw9rR/DULMeW?=
 =?iso-8859-1?Q?wmux9EigXwMmrk1l149c0SMRJzuTrUD93LY9yFiz4lGKmc52e1p++TyUnl?=
 =?iso-8859-1?Q?ewogeoYKQqMQvWZ+OPtF1GjXYN8DPaW+ktHoJQ4wo7kA5uKaTCrFpQLdtI?=
 =?iso-8859-1?Q?p4x8D9uX0oeYdkUCCm96wiGIuo+OIPnfExHC7nvB4+G6PiQjBRLHsKhw?=
 =?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: 3f5f2b92-c18f-4538-e5f4-08ddfb40457b
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:21.8547
 (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: y9JKalcRrg83AiMNX7Asej4LWvN+lDj14qUhBUCcMfB9NwQ7Lzs0CRodAnMzjzJOD8WIBm3NdKgDi0cfIrlRfw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8118

From: Luca Fancellu 

When pci-scan is enabled and Xen supports vpci for guests, Xen will
scan the pci bus to find devices and emulate the pci bus, so the hw
domain must see the emulated bus instead of the real one.

A new helper function, hwdom_uses_vpci, is implemented and returns true
when pci-scan is enabled and Xen is built with
CONFIG_HAS_VPCI_GUEST_SUPPORT=3Dy. When hwdom_uses_vpci() is true, a vpci
node is created for the hwdom device tree.

Depending on whether the guest is using vPCI or not, and whether the
domain is using host layout or not, generate the appropriate device tree
nodes for the guest and handle the right MMIO regions traps.

Signed-off-by: Luca Fancellu 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
 docs/misc/xen-command-line.pandoc       |   4 +-
 xen/arch/arm/domain_build.c             | 151 +++++++++++++++++++++++-
 xen/arch/arm/include/asm/domain_build.h |   1 +
 xen/arch/arm/include/asm/pci.h          |  15 +++
 xen/arch/x86/include/asm/pci.h          |   6 +
 5 files changed, 175 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line=
.pandoc
index 4a66c5a8f9..ac8e7bfb7a 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2077,7 +2077,9 @@ Flag to enable or disable support for PCI passthrough
=20
 > Default: `false`
=20
-Flag to enable or disable Xen PCI scan at boot.
+Flag to enable or disable Xen PCI scan at boot. When the flag is enabled, =
the
+hardware domain cannot have access to the real PCI bus, it will see the bu=
s
+emulated by Xen.
=20
 ### pcid (x86)
 > `=3D  | xpti=3D`
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4bbffdf535..f49e0e6486 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
@@ -1557,6 +1558,142 @@ int __init make_chosen_node(const struct kernel_inf=
o *kinfo)
     return res;
 }
=20
+#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
+struct vpci_param {
+   uint64_t vpci_ecam_base;
+   uint64_t vpci_ecam_size;
+   uint64_t vpci_mem_base;
+   uint64_t vpci_mem_size;
+   uint64_t vpci_mem_prefetch_base;
+   uint64_t vpci_mem_prefetch_size;
+};
+
+static int __init handle_vpci_range(const struct dt_device_node *dev,
+                                    uint32_t flags, uint64_t addr, uint64_=
t len,
+                                    void *data)
+{
+    struct vpci_param *vpci =3D (struct vpci_param *)data;
+
+    if ( !(flags & IORESOURCE_MEM) )
+        return 0;
+
+    if ( !(flags & IORESOURCE_PREFETCH) && addr < GB(4) )
+    {
+        vpci->vpci_mem_base =3D addr;
+        vpci->vpci_mem_size =3D len;
+    }
+    else if ( flags & IORESOURCE_PREFETCH )
+    {
+        vpci->vpci_mem_prefetch_base =3D addr;
+        vpci->vpci_mem_prefetch_size =3D len;
+    }
+    return 0;
+}
+
+int __init make_vpci_node(struct domain *d, void *fdt)
+{
+    /* reg is sized to be used for all the needed properties below */
+    __be32 reg[((GUEST_ROOT_ADDRESS_CELLS * 2) + GUEST_ROOT_SIZE_CELLS + 1=
)
+               * 2];
+    __be32 *cells;
+    char buf[22]; /* pcie@ + max 16 char address + '\0' */
+    int res;
+    struct vpci_param vpci =3D {
+        .vpci_ecam_base =3D GUEST_VPCI_ECAM_BASE,
+        .vpci_ecam_size =3D GUEST_VPCI_ECAM_SIZE,
+        .vpci_mem_base =3D GUEST_VPCI_MEM_ADDR,
+        .vpci_mem_size =3D GUEST_VPCI_MEM_SIZE,
+        .vpci_mem_prefetch_base =3D GUEST_VPCI_PREFETCH_MEM_ADDR,
+        .vpci_mem_prefetch_size =3D GUEST_VPCI_PREFETCH_MEM_SIZE
+    };
+
+    if ( domain_use_host_layout(d) )
+    {
+        struct pci_host_bridge *bridge;
+
+        bridge =3D pci_find_host_bridge(0, 0);
+
+        vpci.vpci_ecam_base =3D bridge->cfg->phys_addr;
+        vpci.vpci_ecam_size =3D bridge->cfg->size;
+
+        res =3D dt_for_each_range(bridge->dt_node, handle_vpci_range, &vpc=
i);
+        if ( res < 0 )
+            return -EINVAL;
+    }
+
+    snprintf(buf, sizeof(buf), "pcie@%"PRIx64, vpci.vpci_ecam_base);
+    dt_dprintk("Create vpci node\n");
+    res =3D fdt_begin_node(fdt, buf);
+    if ( res )
+        return res;
+
+    res =3D fdt_property_string(fdt, "compatible", "pci-host-ecam-generic"=
);
+    if ( res )
+        return res;
+
+    res =3D fdt_property_string(fdt, "device_type", "pci");
+    if ( res )
+        return res;
+
+    /* Create reg property */
+    cells =3D ®[0];
+    dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_C=
ELLS,
+                       vpci.vpci_ecam_base, vpci.vpci_ecam_size);
+
+    res =3D fdt_property(fdt, "reg", reg,
+                       (GUEST_ROOT_ADDRESS_CELLS +
+                       GUEST_ROOT_SIZE_CELLS) * sizeof(*reg));
+    if ( res )
+        return res;
+
+    /* Create bus-range property */
+    cells =3D ®[0];
+    dt_set_cell(&cells, 1, 0);
+    dt_set_cell(&cells, 1, 255);
+    res =3D fdt_property(fdt, "bus-range", reg, 2 * sizeof(*reg));
+    if ( res )
+        return res;
+
+    res =3D fdt_property_cell(fdt, "#address-cells", 3);
+    if ( res )
+        return res;
+
+    res =3D fdt_property_cell(fdt, "#size-cells", 2);
+    if ( res )
+        return res;
+
+    res =3D fdt_property_string(fdt, "status", "okay");
+    if ( res )
+        return res;
+
+    /*
+     * Create ranges property as:
+     * <(PCI bitfield) (PCI address) (CPU address) (Size)>
+     */
+    cells =3D ®[0];
+    dt_set_cell(&cells, 1, GUEST_VPCI_ADDR_TYPE_MEM);
+    dt_set_cell(&cells, GUEST_ROOT_ADDRESS_CELLS, vpci.vpci_mem_base);
+    dt_set_cell(&cells, GUEST_ROOT_ADDRESS_CELLS, vpci.vpci_mem_base);
+    dt_set_cell(&cells, GUEST_ROOT_SIZE_CELLS, vpci.vpci_mem_size);
+    dt_set_cell(&cells, 1, GUEST_VPCI_ADDR_TYPE_PREFETCH_MEM);
+    dt_set_cell(&cells, GUEST_ROOT_ADDRESS_CELLS, vpci.vpci_mem_prefetch_b=
ase);
+    dt_set_cell(&cells, GUEST_ROOT_ADDRESS_CELLS, vpci.vpci_mem_prefetch_b=
ase);
+    dt_set_cell(&cells, GUEST_ROOT_SIZE_CELLS, vpci.vpci_mem_prefetch_size=
);
+    res =3D fdt_property(fdt, "ranges", reg, sizeof(reg));
+    if ( res )
+        return res;
+
+    res =3D fdt_end_node(fdt);
+
+    return res;
+}
+#else
+static inline int __init make_vpci_node(struct domain *d, void *fdt)
+{
+    return 0;
+}
+#endif
+
 static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
                               struct dt_device_node *node,
                               p2m_type_t p2mt)
@@ -1615,7 +1752,12 @@ static int __init handle_node(struct domain *d, stru=
ct kernel_info *kinfo,
         dt_dprintk("  Skip it (blacklisted)\n");
         return 0;
     }
-
+    /* If Xen is scanning the PCI devices, don't expose real bus to hwdom =
*/
+    if ( hwdom_uses_vpci() && dt_device_type_is_equal(node, "pci") )
+    {
+        dt_dprintk("  Skip it (pci-scan is enabled)\n");
+        return 0;
+    }
     /*
      * Replace these nodes with our own. Note that the original may be
      * used_by DOMID_XEN so this check comes first.
@@ -1766,6 +1908,13 @@ static int __init handle_node(struct domain *d, stru=
ct kernel_info *kinfo,
             if ( res )
                 return res;
         }
+
+        if ( hwdom_uses_vpci() )
+        {
+            res =3D make_vpci_node(d, kinfo->fdt);
+            if ( res )
+                return res;
+        }
     }
=20
     res =3D fdt_end_node(kinfo->fdt);
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include=
/asm/domain_build.h
index c6fec3168c..bb36e0150b 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -6,6 +6,7 @@
=20
 typedef __be32 gic_interrupt_t[3];
 int make_psci_node(void *fdt);
+int make_vpci_node(struct domain *d, void *fdt);
 void evtchn_allocate(struct domain *d);
=20
 /*
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 7289f7688b..4fc46da315 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -176,4 +176,19 @@ static inline int pci_get_new_domain_nr(void)
 }
=20
 #endif  /*!CONFIG_HAS_PCI*/
+
+#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
+static inline bool hwdom_uses_vpci(void)
+{
+    return pci_scan_enabled;
+}
+
+#else  /*!CONFIG_HAS_VPCI_GUEST_SUPPORT*/
+
+static inline bool hwdom_uses_vpci(void)
+{
+    return false;
+}
+#endif  /*!CONFIG_HAS_VPCI_GUEST_SUPPORT*/
+
 #endif /* __ARM_PCI_H__ */
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.=
h
index 0b98081aea..08e8959d0d 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -76,4 +76,10 @@ int pci_sanitize_bar_memory(struct rangeset *r);
=20
 void pci_setup(void);
=20
+/* Unlike ARM, HW domain does not ever use vpci for x86 */
+static inline bool hwdom_uses_vpci(void)
+{
+    return false;
+}
+
 #endif /* __X86_PCI_H__ */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129038.1469234 (Exim 4.92)
	(envelope-from )
	id 1v1KPX-0001IJ-9q; Wed, 24 Sep 2025 07:59:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129038.1469234; Wed, 24 Sep 2025 07:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1KPX-0001Hy-4T; Wed, 24 Sep 2025 07:59:35 +0000
Received: by outflank-mailman (input) for mailman id 1129038;
 Wed, 24 Sep 2025 07:59:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1KPV-0007np-08
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:33 +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 66ecb384-991c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:59:31 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB8118.eurprd03.prod.outlook.com
 (2603:10a6:20b:445::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:21 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 66ecb384-991c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IU+OmY1zCbjTPrNSM81LjG5rGveBcVa7iVJ9dfyDng7btMmMZYtMllGrlawo81fC8K6zgjlu74dLwAGOQJYZH9rSftn/nOl2xvS/Zhy9/XzjADIH7xjIboVCN7crfyZLTtWmKFjXf7yN/CeVgHdjP5OhSDQ8EM0pzS4BrX/5yhrcPAu4t3VC4HEG34ygtHHbCW6DBuBKEnVZumRJFg1VummUhLNzDutbiTQA9WDbeNrx8T6cwRe87LV2inSon/6l73gM/5I6zxJRwnp1sWk0bLv9iv50EZdWofR8Ucwf7zGW4M8X0tKId+0zGkJ/ns9XlcsxG/cZTwHpiOngz63R6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7aM5rnffTBG1FpJH3fZkryHS/mhGD1pkq5OAg1z03Yo=;
 b=Kme1/Wo5OdmjA+O+8HEELmR+rj0hmMT7Psn0KUcmcHgPJPzfKikUuiY9K37F4xTS/uYyZutqFTigIF0JJ4BIbd9MYQWgw4b2gLFHDp8eH/4iS3OU2y/AtmEISanZ77f80mJW4aVRTND6HwD1leYB0D6djzl51najDmc1RB8FAEAJC3UCTTDzxobPJQ9OM2OPtFbzzuk8Fcnncf3i8ZivzsiVpymCnpP64pVvSza1HLiwYWv/O7caP40xuwoJYbGXUws2JbgP4CV50iHGOz7gBL8e5hG4stJmGTwExTwySOMfeiFNeo6s7JJFC4ueHX6dC8644S/f+kXq1lt4J/KzRg==
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=7aM5rnffTBG1FpJH3fZkryHS/mhGD1pkq5OAg1z03Yo=;
 b=V9z3IWBGPm5jCoIdiFQ0JmvceqHK0aBpMACH0cakUgEiC5QFOGRemvoVkhs/4Iy+N8dUlpr4zXLcYBzIZ2Wtx4RpK06TQlORQxKAbHCNJDaayTGZcYVSbAHfEfsL/BD3AFDQzjkNt9p3r5fe6zuMmsu41nfzsmZrnsaIPdHVGPMu5WNoBkm0919tRoDCX2pyGTtTK9ZA9w5xBZmNq5YAIHKvLkhiGllExX6eu3lWXXQhqZaUSp/WKOV89Zz+on93KsZLxy6zFwH5JJirpmyWYiLhzuJ4/YMwp/5i6o9VQ6qZLjL/Imbyn+STBWcXlpndR+uSQqXm2+VARUGg0QyqdA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Mykyta Poturai
	
Subject: [PATCH v1 2/8] xen/dt: pass flags to callback in dt_for_each_range()
Thread-Topic: [PATCH v1 2/8] xen/dt: pass flags to callback in
 dt_for_each_range()
Thread-Index: AQHcLSkipAtIZfzr6k2Dq8DXInWg0g==
Date: Wed, 24 Sep 2025 07:59: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_|AS8PR03MB8118:EE_
x-ms-office365-filtering-correlation-id: 040f4619-f7bc-4b83-34fc-08ddfb404521
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|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?JsjPOgEkaSmvFo6VZQuZopEsmMay6duMLV1FZhmZBkog5RoMfMThYtJkZJ?=
 =?iso-8859-1?Q?YKhXvtkp80pGo2IqYc5WUGWlOrUaUvrSXhLWCd739vcTz9u0yNJuuIldL6?=
 =?iso-8859-1?Q?TN8PSGQL4TxMOusfezLC34AO622epYS6hFZiL54EJPYIE0bnBtjoJ9K65j?=
 =?iso-8859-1?Q?7+sUhWhvhKrceJB0gE4d+R/4KXJZuFgvKQIhzAoxugxNomOVwOM9wWacb/?=
 =?iso-8859-1?Q?EDLZMULw3VwwmSYafxcBC+xsZebJRC6Bmwus1i22l7sPCAaAvG67/606NZ?=
 =?iso-8859-1?Q?ED0HnLewYBSYuwpZ0oeD8kK088lW8qzMJb6sV3Tp4m6OrNswpbHCytigfI?=
 =?iso-8859-1?Q?dOoMuUwjwH1FN7p8iyDOr6i3Av+3ooubrXmCN4zye3+K/zgWgorHhlV7FS?=
 =?iso-8859-1?Q?UMrhC/9IS626ALXSJwPsVctjEbNO55exN0pB6BU+6stG9gVsOPS+IfBPP+?=
 =?iso-8859-1?Q?MkqSOxbg0FGchXFkg6Gz6EpUFzB04ws+lswlQdUQU7Hv4GyQ8UBEnM0X6o?=
 =?iso-8859-1?Q?fAFsqUHCbY/gk0Q7wIshknhgdnoUPrO3mFPH6H8UQzf5a4N6NLeMOAeuJn?=
 =?iso-8859-1?Q?bkdbqmlqd0FGKT/Y2umDj/CML/6s6sNASeQgBIZQJKgXl3JTwszAGvUaAE?=
 =?iso-8859-1?Q?H9iBe2GgpnnTO++kbqF/felp5ay7PilBofy51fL+Z7lYynr0vxhhRekfjH?=
 =?iso-8859-1?Q?0BsFYLnzoMY5VXfH4K9y4gskKK5qhsEzFEgLRWo6F407e6l6jUDEWNUKvI?=
 =?iso-8859-1?Q?tcyS+QlbOXoGszA8d05RHFMmfaJw2hYTi/SA+YFCDEsq/jQM3OHVhOtlf1?=
 =?iso-8859-1?Q?o9iffsegbmNg4Izu1bFFYeNej86bQy1dT9DYT0kV0S8AyBUJRtYV5ckhmC?=
 =?iso-8859-1?Q?1KpC9VbEVL8FTt8l5DbQx2MTiutsr1b+C2k+obb7f2PGK/eXAKpJoj85uY?=
 =?iso-8859-1?Q?ayg5Tf4El336cwCBvdXksMKMfQNv0ojo8FFmYDWgWR5HKTa4TKCzC7Rrv+?=
 =?iso-8859-1?Q?XiPm0UOvciriBYB0wYcMQTCUSv2ntGZYnPgUyhyrGG0Kf6TXoxarVkjFAf?=
 =?iso-8859-1?Q?zqR6+8aTEjHrQzGvf5/6BwdKUdXu1PTsNg43kvZ2D73l+ffPw3wy005clu?=
 =?iso-8859-1?Q?qsaveL3gqPJHvt3f2BDEq1gWG/EmgNI4ell6720TQUAMA6YmFWQRGYGgHA?=
 =?iso-8859-1?Q?nxq/UQw4xnvyDgAct3A+KzQswoOP9rOIrrU05UY1C5+m5GpEcG64UFsXO1?=
 =?iso-8859-1?Q?yZKkrS5e6JichrIHjxNZsisflMHViFfKgl5hCQMsEHxcZOobgDmznHhh8h?=
 =?iso-8859-1?Q?3qp4NqiegodtybRVra0GqIyCJ3iFgM1D9LiZufIzygfnFyImdKZzrYisfe?=
 =?iso-8859-1?Q?aOOoP8jFZli9iJA0olPktQX0lL+XU43T72fClLek0aRsgor+LW40aj57zs?=
 =?iso-8859-1?Q?spkyjqbIEM8IrHlC1zM5t8vtRyVaNenfvmZx7UI8iA2fZaFgJ+beShgQAw?=
 =?iso-8859-1?Q?OG+XYXXB8GM0VL94j/KT6H35Ndc/bAWVxI24haF1LUgArwRFtzw1LXRZEs?=
 =?iso-8859-1?Q?t7W/quY=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)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?fvzkgSuRFe21nR60IkFM8ju/OVR4njXDVIJF+Aw7HsKUs8RQzBXf63GfNf?=
 =?iso-8859-1?Q?z9E+B73diODEw9Zb+44j0fX1TlBU+6Fz5+f1FRvrM2nyMaWyahgzx6uns1?=
 =?iso-8859-1?Q?KVmEnt8IeP2eGRlVS6028pgsX7uXGtdqUzajurSdDHD0dmma6K5tLzYGLf?=
 =?iso-8859-1?Q?h83yt5dR/Ssxf33KqMpz074fwb/bPqy8pjwjs1OWusYDqIXVvOTEmL+ij4?=
 =?iso-8859-1?Q?BfifzI1LT9PVeK71NaWT/4lB011dNwhteywjMWbebGGu2CFFeLXGw1VNql?=
 =?iso-8859-1?Q?F+lZrmV6gVe0R+X/YdvxFTEmNtmwduIlKNgMp26fSuIgplgXB7qROEN5Gd?=
 =?iso-8859-1?Q?cGuWW8AkK+E6FXLEWbudGE9H1kpVsm2LSekLrF6B5hWpEVUfai95F2S+7r?=
 =?iso-8859-1?Q?5lnXARHo6ZCgosIHA9H4eIx2PER1+brhJRqkXhXZb7qDsdZOmtGyFpr1YI?=
 =?iso-8859-1?Q?GSSuOhKMU20dmM7Xe3uOe95xuGFmnE3/uNFg7DY+J/XKuYSRkplqJ9fKAb?=
 =?iso-8859-1?Q?e/+2q/gTBwymgBXAJAx0+alE+O9MADeicvjQ2xOo5CBgVzyYP1bnCGdCEj?=
 =?iso-8859-1?Q?JGBJ66G3ud4pWx0zwRucTbNB8CV2XkDOkWAufdFXqoi7KddVfJhv4lYP3x?=
 =?iso-8859-1?Q?Oh87rajPD8VROfkZfgYI1DOA5y1IpST51CrwNWJqzbLXnkpEZyRUwA4gmE?=
 =?iso-8859-1?Q?oPxse3RjhlevHJyuuHeRDevLFRvma7dU32xHtuGjUN1vGSwmSyrrTpvEBw?=
 =?iso-8859-1?Q?fen6JQfWqhACZDlKqONR+SyjCB6XUDThMvxNH5RjzlZv6Os4tZaMG368Qf?=
 =?iso-8859-1?Q?uKdaToc2F0HYKvuSro8Pso9GMUXz0KEZ+cGcpBXsvRblY3WUJ7QWpn7fxA?=
 =?iso-8859-1?Q?y1AgRwaIpFLQojKUenX/FLhZlaLuC1g/k+Ty0lPAm4b6N1cm//4hT47OSB?=
 =?iso-8859-1?Q?2sCFjUfgRtZzyq+Tl3yXcMxu+hZCLgMXxSBIpfW25AwS/NcSLsl1hFn/+d?=
 =?iso-8859-1?Q?rxmvN63Q+pNYxcY9okWMtVuF/PlZuyl+elX4gcraJXWHHAc2xzzLGFX7lC?=
 =?iso-8859-1?Q?FcpdFvckCsCNMQMUdRA+28Jnpb65ZFL404P7W80cLp0RjZluAARwZFwlgG?=
 =?iso-8859-1?Q?ihPxVCejln9v5jnyPvOiCPoNijqSYYsgqt1CBsBrPXxG4sEGycne8r6Lme?=
 =?iso-8859-1?Q?txnuhWnjr+zhIHfMXjIyKKVWjk5nDOZc5fEVoG/iLAA4FLaLBE3tAbDLBY?=
 =?iso-8859-1?Q?15Vu0Rnyt3SLXjPJZ1NJmJiDH6ua4y1MdlCrqokS+tlkhUXohumrLWXjaS?=
 =?iso-8859-1?Q?EjOualmOnTFb0g5P7bhjoFBrR+Z9TBlNBLgqZ1StnmAERR0zZ1yjZo3XJA?=
 =?iso-8859-1?Q?wkYZKv6Witm0PisFoLlP7boGbt+UViDj9trs8f0LzsebWeqnc/VihKuwY5?=
 =?iso-8859-1?Q?bRH9OIRD221fSTF6VcpSe190opMvcEj1RDGGKDTpnFBxAjBWoiZc701jTW?=
 =?iso-8859-1?Q?EKlty4pGYvykJFOOvim7M7nwkblAspU137C2b4k2h5BcOIMFXseVqxnymM?=
 =?iso-8859-1?Q?ASghpEEksRo26WxEO1w54zPKT3jm7r9P0kkD/ZsJAIL1nL75l0WcROquYj?=
 =?iso-8859-1?Q?LaBnMlamhVpjWcXqcjX697OmkyjTotOVImW8dPecmoB4J3/BOo2KM9Pw?=
 =?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: 040f4619-f7bc-4b83-34fc-08ddfb404521
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:21.2187
 (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: iElgvWhH+3QLrGswYf9SVlfZx/JVquEc0mis8MLqvlBgtU5lHs0wSbDJHs+TPppekQWDhSPEoeU7bK7sujNGhQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8118

From: Stewart Hildebrand 

PCI ranges have prefetchable / non-prefetchable flags that will be
needed in the callback. Pass the flags to the callback.

Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/device.c                | 4 ++--
 xen/arch/arm/domain_build.c          | 3 ++-
 xen/arch/arm/include/asm/setup.h     | 2 +-
 xen/arch/arm/pci/pci-host-common.c   | 4 ++--
 xen/common/device-tree/device-tree.c | 5 +++--
 xen/include/xen/device_tree.h        | 2 +-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 74b54cad34..cc0759023e 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -50,7 +50,7 @@ int map_irq_to_domain(struct domain *d, unsigned int irq,
 }
=20
 int map_range_to_domain(const struct dt_device_node *dev,
-                        uint64_t addr, uint64_t len, void *data)
+                        uint32_t flags, uint64_t addr, uint64_t len, void =
*data)
 {
     struct map_range_data *mr_data =3D data;
     struct domain *d =3D mr_data->d;
@@ -325,7 +325,7 @@ int handle_device(struct domain *d, struct dt_device_no=
de *dev, p2m_type_t p2mt,
             return res;
         }
=20
-        res =3D map_range_to_domain(dev, addr, size, &mr_data);
+        res =3D map_range_to_domain(dev, 0, addr, size, &mr_data);
         if ( res )
             return res;
     }
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fb8fbb1650..4bbffdf535 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -762,7 +762,8 @@ int __init add_ext_regions(unsigned long s_gfn, unsigne=
d long e_gfn,
 }
=20
 static int __init handle_pci_range(const struct dt_device_node *dev,
-                                   uint64_t addr, uint64_t len, void *data=
)
+                                   uint32_t flags, uint64_t addr, uint64_t=
 len,
+                                   void *data)
 {
     struct rangeset *mem_holes =3D data;
     paddr_t start, end;
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/se=
tup.h
index 1eaf13bd66..97bc5f90a1 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -62,7 +62,7 @@ int map_device_irqs_to_domain(struct domain *d, struct dt=
_device_node *dev,
 int map_irq_to_domain(struct domain *d, unsigned int irq,
                       bool need_mapping, const char *devname);
=20
-int map_range_to_domain(const struct dt_device_node *dev,
+int map_range_to_domain(const struct dt_device_node *dev, uint32_t flags,
                         uint64_t addr, uint64_t len, void *data);
=20
 struct init_info
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index d3481b05eb..67447d8696 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -418,7 +418,7 @@ int __init pci_host_bridge_mappings(struct domain *d)
                     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);
+                err =3D map_range_to_domain(dev, 0, addr, size, &mr_data);
                 if ( err )
                     return err;
             }
@@ -434,7 +434,7 @@ int __init pci_host_bridge_mappings(struct domain *d)
  * right place for alignment check.
  */
 static int is_bar_valid(const struct dt_device_node *dev,
-                        uint64_t addr, uint64_t len, void *data)
+                        uint32_t flags, uint64_t addr, uint64_t len, void =
*data)
 {
     struct pdev_bar_check *bar_data =3D data;
     paddr_t s =3D bar_data->start;
diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/=
device-tree.c
index 0b5375f151..5ee1fa4eb1 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -976,7 +976,7 @@ int dt_device_get_paddr(const struct dt_device_node *de=
v, unsigned int index,
=20
 int dt_for_each_range(const struct dt_device_node *dev,
                       int (*cb)(const struct dt_device_node *dev,
-                                uint64_t addr, uint64_t length,
+                                uint32_t flags, uint64_t addr, uint64_t le=
ngth,
                                 void *data),
                       void *data)
 {
@@ -1041,13 +1041,14 @@ int dt_for_each_range(const struct dt_device_node *=
dev,
     {
         uint64_t a, s;
         int ret;
+        uint32_t flags =3D bus->get_flags(ranges);
=20
         memcpy(addr, ranges + na, 4 * pna);
=20
         a =3D __dt_translate_address(dev, addr, "ranges");
         s =3D dt_read_number(ranges + na + pna, ns);
=20
-        ret =3D cb(dev, a, s, data);
+        ret =3D cb(dev, flags, a, s, data);
         if ( ret )
         {
             dt_dprintk(" -> callback failed=3D%d\n", ret);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 06d7643622..1091e34a10 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -667,7 +667,7 @@ int dt_for_each_irq_map(const struct dt_device_node *de=
v,
  */
 int dt_for_each_range(const struct dt_device_node *dev,
                       int (*cb)(const struct dt_device_node *dev,
-                                uint64_t addr, uint64_t length,
+                                uint32_t flags, uint64_t addr, uint64_t le=
ngth,
                                 void *data),
                       void *data);
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129034.1469181 (Exim 4.92)
	(envelope-from )
	id 1v1KPS-0008IJ-I0; Wed, 24 Sep 2025 07:59:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129034.1469181; Wed, 24 Sep 2025 07:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1KPS-0008Gl-99; Wed, 24 Sep 2025 07:59:30 +0000
Received: by outflank-mailman (input) for mailman id 1129034;
 Wed, 24 Sep 2025 07:59:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1KPQ-0007no-Ne
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:28 +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 64a08838-991c-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 09:59:27 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU5PR03MB10523.eurprd03.prod.outlook.com
 (2603:10a6:10:525::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:24 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 64a08838-991c-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FMnuVJZDifYgnpS9h+mWCmdkgTsbGpz1inOaM2EUWY0xtWeKVKeWFV8p0KWRdwUFD4SuW/JBu42bbPDGKGKSr8pH8LyTvWLJugRj3A+4F9X35sEjKaRpgSq67DUKkJzgcUOU5tPk0nOi2ncncvuwFp3CTcfMhG4d6T4tmxI1gt/0/em+ZlBCRgAw9aCII9o9fH0tEIHnVyapoL4juMOJfvDWRq2kiAYrvgLc1uWCuQz9W2VDn75NLfMdxtAOvqsOqV7b0CvYxEFqWzJnsC91Mr8Y3Ix4Logej3AfV5wPzHRek2nDAyHjBabNZWDC8xU2A/IJO+vcA6NMEg+3cKsEEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bmIJngmNAJaHcrvOaGKlWpNmiqsAzrA72rwaTEJwhf4=;
 b=EW+e3XunmQdPLn4KblXb1cpeM+SClHC670JtW12hX2rR2wxGITwnCKg4RDq9GaIN5leVdvxr7Z2l7a3obu8eyd2bol0h1UKVI5BEhuZ4bjf6IzGwdqxzWRZ2BySwEHzszok6uAkBUqJmmflSnpfTd+iY6d2DsEkB0j6OZFYQdL/XWysTJAxitml5+8uiQGqacb/0UGDnQ+XchHwq1YCoOv5KmfZX2t7x27aBlvvYoT1P8cBT/s/rlGKgdNqKYuyWd616TXVrNgw1P9z1i6prQ648ZpcOta69g0GqiezV6TCxBGjfqNcY8llM7e5sIFvIXmmDdTnHzsMlk6aQXyQ4nw==
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=bmIJngmNAJaHcrvOaGKlWpNmiqsAzrA72rwaTEJwhf4=;
 b=Oy00EC29OX4zWTTdaICK8G343JRM/8CkG8ynBqxZW++hdaVzuvNtKMQHa7ezea3vs4Z6c0/rH4Gb34tueceWeT44c+LxtgGHnRclxwAUToFgjXE16IfS+4CSO8yoau92cFNjEIR3VLkwZOPvWr8FCZi+uK8WLZeLNXFIOsizA+Fg/THa7sVoIwBHhRLPL8++X2eg3SLBmiDAVcyXn/inojsFGki8yUV5TIA/azJQfOBQI4YhTtGhqck/vd7EoD3TUszjCfmcD0tLpVa2MiTDFdU4VXp24Z7GNgjhBxtO0EvWICD+sDF7TQd3cIwLgKLeE5c5U+s6i98GxQz3ha6aRg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Luca Fancellu , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Jan Beulich ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v1 7/8] xen/pci: assign discovered devices to hwdom
Thread-Topic: [PATCH v1 7/8] xen/pci: assign discovered devices to hwdom
Thread-Index: AQHcLSkkWmtwb4NRmEuuI8pQV3Va3w==
Date: Wed, 24 Sep 2025 07:59:23 +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_|DU5PR03MB10523:EE_
x-ms-office365-filtering-correlation-id: 86aae18c-4bfd-482b-066d-08ddfb4046ce
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|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?qxEiTwlwFFx4/qtbMvl8Ej/2UaYGeZq7aZhNpqL7VbTtFsBOrDVT7gyGrM?=
 =?iso-8859-1?Q?TxagX6frc4BJNc7XWVvWD2w1dKMYbdJBlnQjc2RYMVRZZrjWbwa798Skrg?=
 =?iso-8859-1?Q?R9BYjDvfJ94kd9GECb5VkIKTJvNfZfO8dD6P4fBs8etyrFsDfjr1R033l+?=
 =?iso-8859-1?Q?hMhL/QPMz4dJz0yZ/8EnzCVWNvtbwpMVpTqBvjlBhqNi8ggFeS+IUI5Nxy?=
 =?iso-8859-1?Q?5L4fVStZsE/7ipk5vgV87GzBBpU8zWsE5a7Pcy+IYnb6swukQMtVqyhomt?=
 =?iso-8859-1?Q?Uh9pSCwHMhmG+KsCDJTmOb2kV1MZ4tmH2xA2QmtzpP1hz4VGWyq0vAcFp7?=
 =?iso-8859-1?Q?R6N+0t5PJ/jARIcO61I4/EYxvhqD1EWbC00U++CNYI6NIv+3N9kiHE2vl1?=
 =?iso-8859-1?Q?2C1T0bH/eJsJcQ6oRtag23EghcILuMPbNlAorF2MDUgX/KuwIFKxU0m5mP?=
 =?iso-8859-1?Q?hXCuQm/o0MihOdxVS+TscEOd2RRxG7vFh5nezBEZIpX8ErtjTtWyv83N7w?=
 =?iso-8859-1?Q?F3jX6hoR5Pyo/ml04s7cdHS0Azh0lxACGh+Y0ltd4yGCnaiJdc1t+ogcv3?=
 =?iso-8859-1?Q?xF8F6+s7ctCA1VILUsdEwqDNPcNZovlN1NW2ewCL2/OWRAvhTreCxnZtBF?=
 =?iso-8859-1?Q?l4zrhypJK/2xMYwCqsV8xiTPFgECBX4L3o2v72nGwxIM+dNfAAmeO1Jqew?=
 =?iso-8859-1?Q?t2QKPAMw4yDO6TyEypFX2kzQxYGQNqdlKioGMin+B5+RsjyYleyVZ9rLL6?=
 =?iso-8859-1?Q?twHKFWgimQXT13nDHOjMtXDlJHoif+ZOK/+ZzVoaaO7U3xgN8jdrhEH6Fb?=
 =?iso-8859-1?Q?OnM3o4ZiLwUu7ScCKVTYrFo4FpNiI/PLgE2f1uwrdkSJ/H4yDxxJU1/JMt?=
 =?iso-8859-1?Q?j5LPULAwe1L3E2aDM/4JH2zoGw9oOsRa8uAha74CQKkuhSE0waG6+F2lHc?=
 =?iso-8859-1?Q?ExaZ8rHO3PESBr24vYJTeNzIa7iRL3wUv5s6sl+0IRUkolm1PmmHKT/BGt?=
 =?iso-8859-1?Q?JHRAJsT6DSyqUSzcWgz2xWI2ad7EtaeWYikAeNwjEn4I6eq/sRFMxmXahW?=
 =?iso-8859-1?Q?7hJn8XG9p0GeNzMjNaBIKaw0XlNZ1Rk1hYoo2VJFdxSL95DB63S+A21apD?=
 =?iso-8859-1?Q?66JjXrHE5p2Xbt6VniP3YdZi6VcqvbD2jEBpat5TBJzPsjVBn3brjR61jy?=
 =?iso-8859-1?Q?336djYXFAozcwgiQc/XFqSp8KHLQ7ewB2HaA6VcXR1l5+LfeTN99qmgxC8?=
 =?iso-8859-1?Q?A2eI7LEoOZ3tFR/XNmHV8ywADCOFPMwCJjYBlRxYv/dSxYLTEeLPIKEhUl?=
 =?iso-8859-1?Q?bmYMRiPUNh7c7eROBsfW8y/Ke/V4oX01eEXj0fiXP+60tPULGEt7A5M1cr?=
 =?iso-8859-1?Q?kQNsL4i7YfziUgN64UMVQjcBliJNzdmyVGmvBpQUnfyJulPmHS8TjzroZZ?=
 =?iso-8859-1?Q?4YWo5wuhjlu2Utvvb7dd6SUGXAg/TXr2fowt3+zbtRmQqwrpo22S8MMAoD?=
 =?iso-8859-1?Q?XG3Q7hl4qRpoV8JKv2F/MYQLZuL0Jj2RiEy1y9Oy2J4vFg/ro4IEAnYAOV?=
 =?iso-8859-1?Q?e69WhQ4=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)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?OW7bShq5XUekY0H8Re+GjVliUP1fhorve3/jzr8ww/fIYGxEtgkllFj9bv?=
 =?iso-8859-1?Q?JGVRm/lF32lh2YC37o1GFwX+2Ta5vjdAKHXd1jgA+967xj2eiKi+HG9mgd?=
 =?iso-8859-1?Q?iQdxvLUhMBoWIXVhAYt9YU5wcVBjQtQ5FmgeXQCsx/0G8LcSMDrU2UkMB8?=
 =?iso-8859-1?Q?xbQSBTTGAOBUBtwDVaZcjqEajn0dTX2awsb1BuYKes33Kwmi5b5wIofEIp?=
 =?iso-8859-1?Q?kMwPSxqUyBv2wn1arGjHNMJhPpipHYT0Hu5C2bjylVIEX6tLmbm4fS/V2n?=
 =?iso-8859-1?Q?spdosQmJV3iUnkRTzdGbo9qb/UinIN0jAA1Kq722G8lktEG3uMfVgbW0C5?=
 =?iso-8859-1?Q?21Xw0Q6FGm1UESbeA75HoW7Ll5uHdaVRHJH4GkFUxpeqMUq/pzqoEbaV+h?=
 =?iso-8859-1?Q?LU7MIE0ybZApzsHhm+KSa1vqJf/woEcZmV8tb3/IsT961IrelutH+qkQ7g?=
 =?iso-8859-1?Q?h8AIhDjKL2yTPeLY8YmOqoPXv9O49fvvTC7Llh/fIXqf+VA+WYcDWx4Xta?=
 =?iso-8859-1?Q?d0vJZAfC4NVMSoCdE/8qe2h++/vM+omRxXPoeeM52Qf5V5Ubm9mzSph6JK?=
 =?iso-8859-1?Q?FtM0tGGdOdJabpcLT1oqHwT5iJP69XDDBAXIeVKg0Spb7pasuf/fL2AJ8c?=
 =?iso-8859-1?Q?HLmCyuVZqxOiP9znzCrL6EBYrp+oEBwHMCutyNPNu4+nPPtZ5H3NJVBGSK?=
 =?iso-8859-1?Q?B+dkfwwGViKmMNqkN49sMWKMJKttnrMjS1np3zFajRkkAQKxEPD3oA2wnX?=
 =?iso-8859-1?Q?n2S+sTEyEErSmkjSNqBefcVW2ob3qiCSNzqbkcNvgjH6h9T5SLH/gDKhWH?=
 =?iso-8859-1?Q?qJ2UFmyCGTt1BA0Hck8oKRNEDrJlOXF/odm8S74mwETIRt1jPj3/GKUni3?=
 =?iso-8859-1?Q?8u0Hcnm+O/pzKL3WycDt9fltKqhtGXoqX1YpjV+kooy5CEHkX0IOdO0IdX?=
 =?iso-8859-1?Q?XiodddtMW9/LPgmWhIR9on9adDHnXz5fIFX+EjVK8MvO60WrRITThuJzKM?=
 =?iso-8859-1?Q?4B4KgJPRnjsCpb6WrqTbRr0vySX/u8DYQAJ4Wn19UnpgyNqKRnDGd1gJxb?=
 =?iso-8859-1?Q?yIUw9jyWeB3GK2jSL2eU0l9CR5YZ9y/zwQnd+RMyH3U2o2mqVatV08OwOK?=
 =?iso-8859-1?Q?5u09Y3jMQMLQRUirQQmp6hXkt0FPEyd+K8lqUEOfaJWf+H4GVL8MEhOQMC?=
 =?iso-8859-1?Q?BrPNkEoyOpcMWOW21An6l5wVtrur2zYrV2gXAv1NPL2cyTxWOHdiRaF8Le?=
 =?iso-8859-1?Q?H4KYPYQG2+4YpiqBrLmYViE4gIbaQjr8K61h4JaUTIHemS6rgoPWozHcOP?=
 =?iso-8859-1?Q?Fo9/qrmwPRSpspMX4nBl97n5q/ItTpl8VeHEo4Fpe6w41do1s8wUuqzOaw?=
 =?iso-8859-1?Q?kTClq0VdSJZlKiKnskAhK0G+TCpws0ThtMwF6VzBO6SHquMiE1X+YPXA25?=
 =?iso-8859-1?Q?rFyiM85cymOuZAeAxGnCW7VeN3jlT2Hp+U4FNaQVrxz6ysMWJE9i8a7XP7?=
 =?iso-8859-1?Q?WHCA6k+1dUUzU8KH4CR+x/c1w5jc9BM9K0T223fYCF2XOnjjN/K9DQkQNr?=
 =?iso-8859-1?Q?ihF8j4FpQbsLlV+sHTxt9AVXLycdStBu7LDK49KYhqX8HrxHWF21LV+Nbh?=
 =?iso-8859-1?Q?7FTwNwmZKRT3ZCJHLb2K6qLbBFIkM2g2PRr2PZjqViTYxirt38fyH0lQ?=
 =?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: 86aae18c-4bfd-482b-066d-08ddfb4046ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:24.0356
 (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: US9NGmlwluJ1fV72i9rCbwiqsP4olR6W6OaQbDwzfRL4R58Pk+CDW9/pdqneTd4e+3NBjt7V21GF638zZRBu4w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10523

From: Luca Fancellu 

Hook up existing PCI setup routines for hwdom into Arm iommu
initialization sequence, only assign endpoint devices.

During scanned PCI device assignment, also permit access to the BAR
ranges if hwdom is using vpci.

Signed-off-by: Stewart Hildebrand 
Signed-off-by: Luca Fancellu 
Signed-off-by: Mykyta Poturai 
---
 xen/drivers/passthrough/arm/iommu.c |  9 +++++++
 xen/drivers/passthrough/pci.c       | 40 ++++++++++++++++++++++++++++-
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/=
arm/iommu.c
index 100545e23f..d110520e0d 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #include 
=20
@@ -133,6 +134,12 @@ void arch_iommu_domain_destroy(struct domain *d)
 {
 }
=20
+static int iommu_add_hwdom_pci_device(u8 devfn, struct pci_dev *pdev)
+{
+    const struct domain_iommu *hd =3D dom_iommu(hardware_domain);
+    return iommu_call(hd->platform_ops, add_device, devfn, pci_to_dev(pdev=
));
+}
+
 void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
 {
     /* Set to false options not supported on ARM. */
@@ -142,6 +149,8 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *=
d)
     if ( iommu_hwdom_reserved =3D=3D 1 )
         printk(XENLOG_WARNING "map-reserved dom0-iommu option is not suppo=
rted on ARM\n");
     iommu_hwdom_reserved =3D 0;
+
+    setup_hwdom_pci_devices(d, iommu_add_hwdom_pci_device);
 }
=20
 /*
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 4f5de9a542..534faaaa84 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1040,6 +1041,12 @@ enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn)
     return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI;
 }
=20
+static bool pdev_is_endpoint(struct pci_dev *pdev)
+{
+    enum pdev_type type =3D pdev_type(pdev->seg, pdev->bus, pdev->devfn);
+    return type =3D=3D DEV_TYPE_PCIe_ENDPOINT || type =3D=3D DEV_TYPE_PCI;
+}
+
 /*
  * find the upstream PCIe-to-PCI/PCIX bridge or PCI legacy bridge
  * return 0: the device is integrated PCI device or PCIe
@@ -1255,7 +1262,7 @@ static void __hwdom_init setup_one_hwdom_device(const=
 struct setup_hwdom *ctxt,
                                                 struct pci_dev *pdev)
 {
     u8 devfn =3D pdev->devfn;
-    int err;
+    int err, i, rc;
=20
     do {
         err =3D ctxt->handler(devfn, pdev);
@@ -1276,6 +1283,34 @@ static void __hwdom_init setup_one_hwdom_device(cons=
t struct setup_hwdom *ctxt,
     if ( err )
         printk(XENLOG_ERR "setup of vPCI for d%d failed: %d\n",
                ctxt->d->domain_id, err);
+
+    if ( !hwdom_uses_vpci() )
+        return;
+
+    for ( i =3D 0; i < PCI_HEADER_NORMAL_NR_BARS; i +=3D rc )
+    {
+        uint64_t addr, size;
+        uint8_t reg =3D PCI_BASE_ADDRESS_0 + i * 4;
+
+        if ( (pci_conf_read32(pdev->sbdf, reg) & PCI_BASE_ADDRESS_SPACE)
+             =3D=3D PCI_BASE_ADDRESS_SPACE_IO )
+        {
+            rc =3D 1;
+            continue;
+        }
+
+        rc =3D pci_size_mem_bar(pdev->sbdf, reg, &addr, &size,
+                              (i =3D=3D PCI_HEADER_NORMAL_NR_BARS - 1)
+                                  ? PCI_BAR_LAST : 0);
+
+        if ( !size )
+            continue;
+
+        err =3D iomem_permit_access(hardware_domain, paddr_to_pfn(addr),
+                             paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+        if ( err )
+            break;
+    }
 }
=20
 static int __hwdom_init cf_check _setup_hwdom_pci_devices(
@@ -1294,6 +1329,9 @@ static int __hwdom_init cf_check _setup_hwdom_pci_dev=
ices(
             if ( !pdev )
                 continue;
=20
+            if ( hwdom_uses_vpci() && !pdev_is_endpoint(pdev) )
+                continue;
+
             if ( !pdev->domain )
             {
                 pdev->domain =3D ctxt->d;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129033.1469174 (Exim 4.92)
	(envelope-from )
	id 1v1KPS-00089Z-30; Wed, 24 Sep 2025 07:59:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129033.1469174; Wed, 24 Sep 2025 07:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1KPR-000892-R3; Wed, 24 Sep 2025 07:59:29 +0000
Received: by outflank-mailman (input) for mailman id 1129033;
 Wed, 24 Sep 2025 07:59:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1KPQ-0007np-9d
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:28 +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 64278f53-991c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 09:59:26 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB8118.eurprd03.prod.outlook.com
 (2603:10a6:20b:445::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:20 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 64278f53-991c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FFIPAnGn8br5xxgnj3EiCJqMlI2GVIazx6oOZ9UUWexe6KsRV7ep26sdvAA7Zn/Z1oo4Gakt34durMf2BL9AXM8q6KZzNDAmZpiUwv02qPsmrR2II+vobnkm5gNNY+zQwIdWotd7UaYhIQfO2gMW59o/CLNmdoDPD+VAy7T97X46YLlQiS2kIIkJRv6ouXF8yYsfaIx9iai8jnX9e3tuucVlEPfEV2Es/ErUDbaRJuHQdP/d1lhAIME9Kp6n0FSmdOp0X25ORO2rNzuvXlJNWhjekXOJVUR5ThUcB9Hq9Gu4HVjf7VedR1Zm34VzlV8CBw9yXaFSPD0/NKpDtXgjrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7ULNxCLY/jmCoKaMjog/ApjkLvSJVKSwnm5oihu+azo=;
 b=AVkus8RUv6EKNarb1ICnHuNpNvuMwPnuwqh6gD3GvWms/b1UcOMFT0ITBVXQXSpWJBAyYmPCP/3BD2jxS8nMQPc0t7elZRZ0K3qSJmadLpH4v7AXGFMEG/oJWHxPrYW75A8FmMvj55qTc9+lesx1x+8/nveExvkY7tJ+0HP2qtE48vjGeCXwJJ5ceor8ShWdiz6rQ+Ixvjmg8WLYKWSRVvXQ0QJZvWfaUELU/WGp6ay8d1fjSEZgKBaRy+LqUBZouJojGXMvO3hVKOMAy6N65u180QaaqoFG6L0HrFXZja9aJ9Uj7+luYZ04D7WCbFfutM8VGTfSPl+q/62Q5jv6qQ==
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=7ULNxCLY/jmCoKaMjog/ApjkLvSJVKSwnm5oihu+azo=;
 b=f8PuHn5dTBMbrf7YbNI3ZYG0muWQ/y8rAPA1u9bV4ORMQ715VXOwC5+e48UGIx2mfT0zV9rlari5QoNjdNHSXWhp+4HFrhyoQC8rstfmA+6mKR3SBEC2a4eWcM3Ut+xt5F9czaSROwuMHzHv7bUeYDPPALEQYUXJ3rktB7ZXm9m2DQU3TrQ3oEbJyNMm4EeRfVjfprMOuDUMyA6vlIPhFo3ZALI04Wq+/mymIJDWFMF0RhZk7LRU+yCReBQoqpmsjGSPqNc0Z0Y624paT8yuUnW+Wbw/LCtlZUaaZ9thcw+jIYhZxu7pvPzSS9DhAh44wAT+lf978yAVejPFit6ESg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Edward Pickup , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, Luca Fancellu , Stewart
 Hildebrand , Mykyta Poturai
	
Subject: [PATCH v1 1/8] arm/pci: Add pci-scan boot argument
Thread-Topic: [PATCH v1 1/8] arm/pci: Add pci-scan boot argument
Thread-Index: AQHcLSkihW+vIVPOD0C8lQtI9fOeZQ==
Date: Wed, 24 Sep 2025 07:59:20 +0000
Message-ID:
 <38d8a5b16f55cfe903c86073c48fe0d6d7af107c.1758618839.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_|AS8PR03MB8118:EE_
x-ms-office365-filtering-correlation-id: dbb0c5c3-7cd2-4aa7-9db3-08ddfb4044d3
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|376014|7416014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?a6cO5h9MTuBIDy12rb7uTh9slhbucGMmqsUVlxuxGhcKr8DD4FXx3qSVRb?=
 =?iso-8859-1?Q?lg2CilCSEq0iMGsd0dIXhEJtBUTQiyn9D5g2sZtf03JmI9aej8PPiBYLva?=
 =?iso-8859-1?Q?IPKwuamGCu9aN1+9bIiMAb70QQjqTL4OaCVSCXEO8gdeazzVZzF1ABPV74?=
 =?iso-8859-1?Q?65APPAnVkHfvvZysicFpXWnEEfK4Oi1eMTEbeUR9D6a+YfcGzX6qEIGj7u?=
 =?iso-8859-1?Q?B1R6ZbRH/vLFbRVRn7ufGn20SiYbrwctQ2eAKN3FhZ6PfXEs8plGi19Zpd?=
 =?iso-8859-1?Q?F8Fwd83oyhmrGgHXJTJGQP32BycWIB+L8METOaeF1qo74+pIfyyzE8cIan?=
 =?iso-8859-1?Q?k0FYm862TCzgzB6BwVhZ72CqMh+jomARiMXmlZROUWefpo0QyGEFjT5tjf?=
 =?iso-8859-1?Q?JFM1+jguR34ykllEBaVJ2U2egXT0zQyaXU2Vb5dKCFPaJWvSuqwnUE5bBg?=
 =?iso-8859-1?Q?FBOdibYVJLNJJfFTEiKNbVrnYURDUvtaX4NSqlTzcKs0qNPakKFwCicNOF?=
 =?iso-8859-1?Q?d4+w01g0qTKMxo8w32v2HtXjBTOsLETDD7nF9polCg/RkIDI3rzIH19+7Q?=
 =?iso-8859-1?Q?p/RI5kzkyDVmXpawF5t3WvPkjO++gerdS3FwIy6ph92MkpF4B0WIV2dwjb?=
 =?iso-8859-1?Q?0UdhFb3LQEsdEwNsURgudtIlVkx56A76H/QKG34AOV+utPKFmiLLx+/weV?=
 =?iso-8859-1?Q?ujjGNicSx20FojxU/EdiXsT9fh2mAcoqx5iVwJ2PCf+pTrBpW+ACAtjh6F?=
 =?iso-8859-1?Q?k9iHDJeqDBosf+G2tQaJzCjHzja928+c0B3FPdQlXhS6DqPOpaP02fB1Ma?=
 =?iso-8859-1?Q?YtWoKrJv1ySedkEG84AiEbLxmf1EoVaGDCPkAjDMaWsERceSxGNI+1V8DK?=
 =?iso-8859-1?Q?rof2u6CkLkALabZSUrNm09eTmd/Mmn2DgZFX3NMra6YVHL7K7dPcNX5jb8?=
 =?iso-8859-1?Q?pTiQ9Y4cMchsXcx5RRkNo+k/h0543FmH1pWum+h8cNsNxRJbinUNThavuS?=
 =?iso-8859-1?Q?yMxtNRg137QzFgnlKQEtlZesBKA9upym2s3lFcOJj2GM6YryO5X3uYSf2Z?=
 =?iso-8859-1?Q?PyVs8M25BnObDEZDz4uKah5TMLzbAI4MPGuYRjDvVnewIK8TVhfcv1YfYo?=
 =?iso-8859-1?Q?VL3qbnjUNcDaFWwyffpMXgIJy6Gmdrdp6q0ItSSrhQaiOrJjn+OQQh2A8Y?=
 =?iso-8859-1?Q?gahxaK3WQmoX9LDwzZhy0ZvT7dPPOlUWlCutd7Opscwpos98jMVrQcbt8H?=
 =?iso-8859-1?Q?dG7wbAsGLjeN4fBuFo47k2oAwD0xcri1k6Bn5cGZUF/5+KCfrKBN9LwxXk?=
 =?iso-8859-1?Q?Xv3O30Acw3fUVuPJfG9TA+xqicWIDGMjupj32NR4zSxsyjIvU9DFqGy/RY?=
 =?iso-8859-1?Q?uFgxCIJAXr/HKSdIJKEjGOEU/u0YF7yQjVks5E8XM87wfu3WNRizK/UDGA?=
 =?iso-8859-1?Q?WZLSpOIN3akOnkwepFI0aljiMIIUoWY6iFTmwD+ofAWmGj/i37U2isGZ4r?=
 =?iso-8859-1?Q?M=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)(7416014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?JHw5qgZR/rwXEothMbxBa2yA1902msuOOje/xr6xbPc1ugNWhK8vKY8UYU?=
 =?iso-8859-1?Q?Yg16p72YjtHLSIBvPkjigqkDoLkWn+bE1uePpHI/id9bMkr7JPUKxEes2X?=
 =?iso-8859-1?Q?89+n6lojYiglWam/jvwdNUbAOTQ8Pq9dvwTV+pR0hAduOvgKHqrsmBXhTZ?=
 =?iso-8859-1?Q?nmtLPzHZWqme+1QYVc0e7/1ofmBaLaLPGSyS4uD8RCB487kyw6tXu/ujLZ?=
 =?iso-8859-1?Q?rt8RzsFmrMASPd3+PR5KGZ8JKAZN98yQJ5oReKLtRw03SZIPfzh41wRmT0?=
 =?iso-8859-1?Q?6b/aC9lbCim/MVbBTsa7AM1YkSy9KNpP9nO2JYPxfBOUlxJ2fypv0F+CnP?=
 =?iso-8859-1?Q?ywfAgCMPsWAMTycPx5R53k4dU5y8mHf7TDaUdKq6UWZj+1JZm4jcctY3Su?=
 =?iso-8859-1?Q?DOOtdRDLh+1K99pEHxGsePX3aHY77Pqfcow9xroymTepe8bAstexdBmW0P?=
 =?iso-8859-1?Q?RZtWH3nvnQfHV1ieEEcWfx3+DqI3JEYtVJGW9ua1h5ZzYlCLl4+Q/dPQE9?=
 =?iso-8859-1?Q?x7+SkV1hsIYchcRSRPI+aY18eZzTuOZRzLVVvij7FJFLHBGP2ksI2GugC+?=
 =?iso-8859-1?Q?hv1YqFxAUykfr6inYw5birqRd7ajGzHhvp92MJTFWc9LW5vbpNtyPkAdVU?=
 =?iso-8859-1?Q?qT5QLIWP+2d7DRpHsjBexw/Fz7dN+RYd+0sRtJDIJpYQpGsvHemytLYOO/?=
 =?iso-8859-1?Q?tJoMg2KGk7uMikYmd1LKCUxlRbDy4xTdhTLV/jstG+8asGChxITVIVlIMK?=
 =?iso-8859-1?Q?9UvdBuHAgJPbkb+FFssNlSHuj05pABZqkco4Ei4FSDOtOO34EbKoaQAKFr?=
 =?iso-8859-1?Q?SVODuXC/sQYlhCcMIPkjZBWOt6xeG73K1EVOvRyL5hKIi1B0oMLVnX1ZIk?=
 =?iso-8859-1?Q?yz00+K0TzH3PNeFU7KEVOtMucRNrS5Jzr5rQGVnBpfiiMeYtKxyJPRPIrJ?=
 =?iso-8859-1?Q?rBuaa+Q6yUB2aoeY7AnIRdZC/TvGyWqJEK4HviCXcVsnGzxHddJpdh2UDT?=
 =?iso-8859-1?Q?gFgmJ7YRtCpHQodAcm3cX9R048fxHgO9uBM72h+FkCR2mpgruLHEBv4ZIL?=
 =?iso-8859-1?Q?SoyYCmxooI5cet9Wj3ZbZ1Xf0DbYTBGidqunuY+UnjJf4K94gbfj8nbM6u?=
 =?iso-8859-1?Q?w4RS9LF0ZOPiRcKpYCqAtZQJ/LvZVQGy+JhBPehJ4S2XctOVHdiFH0VLbk?=
 =?iso-8859-1?Q?Nz+cmIul0bMqLSrpuAPG0Ve2n0MZ0oG3NF3AIWa+YaF4Ee+lpIHNXuJbmz?=
 =?iso-8859-1?Q?RoTr2726JFBIXzjC72Dn23t/b81LuIy3y0hOAAXt+/ZMezm3qH+5+b+jZN?=
 =?iso-8859-1?Q?Ts8+zRhYSePY9gd4FUHzYp7rxmdem7XjfBqjMSp/0ZIgQm9tra0OWRpDm1?=
 =?iso-8859-1?Q?p1+dhE2nvOom8V3HzeCkuPRtLrflj/QPpAOnavvOvwx/aTe1Ju3bVf2+9c?=
 =?iso-8859-1?Q?VI8jFMtIOSeoQwscH3xTCb9QjBx8heSIxnlJXxEvuehFpq6X+FzZRQUd+x?=
 =?iso-8859-1?Q?alRFpw5KRn3NDK74FPTrcFixLQXoB+Lp6msjvTgkjwIZPiINWmUGfPn3L9?=
 =?iso-8859-1?Q?B78OcWErxMBqar/3JOfY0hU5zdX6WKNUzX92drBrF41Qpx9MNnyWWvJSuv?=
 =?iso-8859-1?Q?Qu0dbZjnBbYsVa4a5jZHtXXbezmZTTKUC2RP9ujCJx0b4IMNEYG2tQtw?=
 =?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: dbb0c5c3-7cd2-4aa7-9db3-08ddfb4044d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:20.5065
 (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: U85c6BSaM4/krmTAmcFLCyjWNngZ0zX3R4hE2viht0/NuJwImKhwWLgZSiDIu3ig9YVO90ta/rI44ASleWnSiQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8118

From: Edward Pickup 

This patch adds a Xen boot arguments that, if enabled, causes a call to
existing code to scan pci devices enumerated by the firmware.

This will be needed ahead of dom0less support for pci passthrough on
arm.

Signed-off-by: Luca Fancellu 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
(cherry picked from commit bce463e1588a45e1bfdf59fc0d5f88b16604e439 from
 the downstream branch poc/pci-passthrough from
 https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc.git)

v1->v2:
* remove is_pci_scan_enabled wrapper
* make pci_scan_enabled ro_after_init
* drop debug prints
* drop Edward's SOB

changes since cherry-pick:
* s/always_inline/inline/
* replace additional kconfig option with config DEBUG
---
 docs/misc/xen-command-line.pandoc  |  7 +++++++
 xen/arch/arm/include/asm/pci.h     |  3 +++
 xen/arch/arm/pci/pci-host-common.c |  1 +
 xen/arch/arm/pci/pci.c             | 24 ++++++++++++++++++++++--
 4 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line=
.pandoc
index 518e42d965..4a66c5a8f9 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2072,6 +2072,13 @@ This option can be specified more than once (up to 8=
 times at present).
=20
 Flag to enable or disable support for PCI passthrough
=20
+### pci-scan (arm)
+> `=3D `
+
+> Default: `false`
+
+Flag to enable or disable Xen PCI scan at boot.
+
 ### pcid (x86)
 > `=3D  | xpti=3D`
=20
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 08ffcd4438..7289f7688b 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -23,6 +23,7 @@
 #define pci_to_dev(pcidev) (&(pcidev)->arch.dev)
=20
 extern bool pci_passthrough_enabled;
+extern bool pci_scan_enabled;
=20
 struct rangeset;
=20
@@ -155,6 +156,8 @@ bool arch_pci_device_physdevop(void);
=20
 #else   /*!CONFIG_HAS_PCI*/
=20
+#define pci_scan_enabled false
+
 struct pci_dev;
=20
 static inline void arch_pci_init_pdev(struct pci_dev *pdev) {}
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index 487c545f3a..d3481b05eb 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -284,6 +284,7 @@ pci_host_common_probe(struct dt_device_node *dev,
     }
=20
     pci_add_host_bridge(bridge);
+    pci_add_segment(bridge->segment);
=20
     return bridge;
=20
diff --git a/xen/arch/arm/pci/pci.c b/xen/arch/arm/pci/pci.c
index beb1f971fa..1b34e17517 100644
--- a/xen/arch/arm/pci/pci.c
+++ b/xen/arch/arm/pci/pci.c
@@ -91,8 +91,14 @@ bool arch_pci_device_physdevop(void)
 bool __read_mostly pci_passthrough_enabled;
 boolean_param("pci-passthrough", pci_passthrough_enabled);
=20
+/* By default pci scan is disabled. */
+bool __ro_after_init pci_scan_enabled;
+boolean_param("pci-scan", pci_scan_enabled);
+
 static int __init pci_init(void)
 {
+    int ret;
+
     /*
      * Enable PCI passthrough when has been enabled explicitly
      * (pci-passthrough=3Don).
@@ -104,9 +110,23 @@ static int __init pci_init(void)
         panic("Could not initialize PCI segment 0\n");
=20
     if ( acpi_disabled )
-        return dt_pci_init();
+        ret =3D dt_pci_init();
     else
-        return acpi_pci_init();
+        ret =3D acpi_pci_init();
+
+    if ( ret < 0 )
+        return ret;
+
+    if ( pci_scan_enabled )
+    {
+        ret =3D scan_pci_devices();
+
+        if ( ret < 0 )
+            return ret;
+
+    }
+
+    return 0;
 }
 __initcall(pci_init);
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 07:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 07:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129030.1469153 (Exim 4.92)
	(envelope-from )
	id 1v1KPQ-0007oB-1i; Wed, 24 Sep 2025 07:59:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129030.1469153; Wed, 24 Sep 2025 07: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 1v1KPP-0007o4-U8; Wed, 24 Sep 2025 07:59:27 +0000
Received: by outflank-mailman (input) for mailman id 1129030;
 Wed, 24 Sep 2025 07: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 1v1KPP-0007no-37
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 07:59:27 +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 63adaf53-991c-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 09:59:26 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU5PR03MB10523.eurprd03.prod.outlook.com
 (2603:10a6:10:525::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 07:59:23 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 07:59: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: 63adaf53-991c-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yyJeX7+teZ7HFarLCW6oH2S6uMpNjW7A+mYVnCUd9f6Ngz4yOGuA2k6YTBmTG7X83dfahf5z2a9V+Qj+wsMhXLLB0wNAJKQQqeNVmTAqOJCDlA/8GT3glvrNgrCYJw31SlEAg54oq3/38rOZUgOx26EsiWmGJ+QlcpP5DiKSmf4/YAsDjzVpOH2AXK8csvbn4x8HVb2QPoWKz1qaLtY13JBwotmBMHPeHwKCWTUK5F4rI50jr3p/cXM0RR1pFI571QFPo6Y/D2CD5h7WfOrk5h6BHWJNw0HgzYcGM9yqG44IEVp/UxsMI6xIqnt6251FILjUVhJl2SFmhhlBWWtw5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EWE34pPSdrkRg9iSVEGUFEHrO/WwevjtA4xzWvp4GgM=;
 b=cYStA/AqAVSlUO9mmPrtjaak2jx/LvYA6pPHb229Nhzkcp1dvzQX46e71oaWFUnoWCm/0nKHybW5lOHVVgESLfadvnvY+toVgqLuyfXxnwAavWAe+5ScGVxQUpSOqlRO6wy2ke1l3gYTjwx8rVcif9c28ZTSXWg2M1FmqoOzYhbc3+l2UyOw6Czz0JScsOlFHwVopQLLe5hkh+JsyBUoxdEQQFz2oclIhIYiVmeWckVXksfMVxJkoJwcu6F4tbYQmGHc8lt0dVDb4mMJ16XPZvOlhhfCzSG7yfK5b3XV+5OXhoPNI3ZC13XaeAEG1X25TGQDjcTPbxIFuJ2tcwZO/w==
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=EWE34pPSdrkRg9iSVEGUFEHrO/WwevjtA4xzWvp4GgM=;
 b=ty/JYW5JsduU6Me+5dDlSC735olXR+WJEDoBj4YYHOtxljW0Q7nu/J7tgcAcya2mHOQ+Xa1HOiwecUTVY1LRFHOYCLC0X4hSoYHjUsXV93rKR7iyC2DKinoar6sSJQ0BYpY2FXSNmd7xI9bfbuXu9V1wImzp0ukEFHpvCdaVnoBMY/zvPEpx0P9HzmcWBKUPgdBtBy+F+55IDqNlCU0O8FtTtMfUseH4CQGI/oByQh5E8J6LlssDOdr7QJrS7VHub5Ajofu1/zoizL08pkztGfpWgDA/VqTkBAHMPr8IYNRhsgjJVsxUd5oxMEzQvF/cCXgpbCKXcGWXRmRwmdt94A==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v1 5/8] xen/pci: introduce has_vpci_bridge
Thread-Topic: [PATCH v1 5/8] xen/pci: introduce has_vpci_bridge
Thread-Index: AQHcLSkjUCcQVsMHP0qfA2BNpZwKyQ==
Date: Wed, 24 Sep 2025 07:59: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_|DU5PR03MB10523:EE_
x-ms-office365-filtering-correlation-id: fc83916b-2a3a-4316-5baa-08ddfb404607
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|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?4ptxk+qtGLyV3JFrCFgetBZKaWyN8ZG2oNfAqM3rM0oOO4ew7sk2BDMBnz?=
 =?iso-8859-1?Q?eYjC/iuD2h9QXLFt73RSNc6f8PfQ2aJHrMpmiVVk+/4p+jI1DzLXGltIbC?=
 =?iso-8859-1?Q?mkiDEdh+GzrU72Vs/hVzXRrNylXIhr5BXLqJLQJU5rxcYjAhkOKRayczmM?=
 =?iso-8859-1?Q?uOnzMyWWqpkGOD+81Z99/2KN2ioZ/RDKdHcs7n6RuXAYjr+bQnPLI6M1jE?=
 =?iso-8859-1?Q?Jw3mA8X2L7+fOM2A8HCRHAqQo2UJNlF3Ps1pcYxurRZQlrEHg7oae6zvr9?=
 =?iso-8859-1?Q?wsSREsJqpItMv43NDh7Bd8P6eGlW+dcf/Tb1QLN7hRn9t2DWoiyQuGydj2?=
 =?iso-8859-1?Q?pUISjgQcKekFxm2F1XxE8td86oeddNNfDKpBdmuuCWRg7uu/ofqKvm6OFj?=
 =?iso-8859-1?Q?GDPFTav9TrGZ5MefYkoZRm9WSlTfGRp+cBJhUzmv9f5NpNQpuelpcfHJr7?=
 =?iso-8859-1?Q?2dRhdm67b0qpn6yUV+qv3BJFvek8k5bgmdv2X4GwQtDgvmN7f4bQZhMh5h?=
 =?iso-8859-1?Q?A4olCAN0iZJfT661D4CeyTMX+5qNDk5m2speJ9dF1dWIW3vDwr+XJcAdpX?=
 =?iso-8859-1?Q?H3Kju6Dm9AP+ZKOBcyvzszFuNSaiR6qz25oJEiv04mnD3o3FY9GgImcl9L?=
 =?iso-8859-1?Q?R15ts08wYHZYZ33+tqohlVNyXcfTl7C6YtQLKAiFEW6Mr9T+RrzSI14IBl?=
 =?iso-8859-1?Q?cVNgw+BBhqygo5XcyW6jalCZXrhYsee0mnPcc5Bi+1L/13Q8kKzQCuvhal?=
 =?iso-8859-1?Q?tn5PAor2Z/w4OySAjb+CL41m1oK7JkcFl7+5RyKwi8/yD/xc2eDkWi34j7?=
 =?iso-8859-1?Q?c3Khkwj9u388on06T0fnIpKpEl4m3rxCEaEth9LUmyct2u3Q4h5wk1Ksd4?=
 =?iso-8859-1?Q?a9cG3AfreA6m69T79DMz8o5FVZ3T4Ne3XEKkFG0/PRyUU8nuqdXtgy3H4B?=
 =?iso-8859-1?Q?5NydmpkJK5jv2OLfMWbyiHRgTscFYCinSU4e6GlEmBuDYSWEiTapn3hrB0?=
 =?iso-8859-1?Q?rdJqAzAMCoE+XEWxT1bKn0uCAfuIdWdnC7+pJpOTLgddnTk0ccYzr6QJb9?=
 =?iso-8859-1?Q?jXOyDVaYCPd+d9CYBVS90z7dJCOk0uJNblQQR/QCe4bXW4ivFLX2m3zyTu?=
 =?iso-8859-1?Q?7e5ntGMRPX/V9uxg8Y2KP6BOwjlecPRQVz4Ieh8kd4+ULzP+ZaJrtTxhFM?=
 =?iso-8859-1?Q?0Ww33nkMRWCpZuxkWza107eCpnWFhvAnV0puOLRyB4pRcxZRQqegAk+mQC?=
 =?iso-8859-1?Q?8rkn3DRzKGGru0Rfr5FFlG/vkaMHRGwsPuKlSMHEtTM4gyM9NGzlc6j8Sr?=
 =?iso-8859-1?Q?m54rmqIKoZeFIXWBwqq4stN4xZr+YHiAUf2+ficUNygZ1CAneN+ofzfoq3?=
 =?iso-8859-1?Q?BGlGwzDgFDfYCxzGjbCtIHKPUrv5KL8H9TcuOLFhiwjEPTZMeIOClaBuCk?=
 =?iso-8859-1?Q?DzG+wFrJNWmzRnaDhhy1kxcxy3+7VFJgFoD+I9zt9rpYEWFw/7KdGAWekc?=
 =?iso-8859-1?Q?yaBEb9Z5N/Trr8XylSsAzLRyrTviPmKizU30/jr/ys9K6zY2W9JXiOFNTx?=
 =?iso-8859-1?Q?uMGLowY=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)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?C9C/A/yHwVYlaliFW7o4TkJETi4RRoAUYpfnpLvpvvjCY6US/ce249H/XI?=
 =?iso-8859-1?Q?Up3SDbcWI2H4FA4z7dcH764TBFnTcLReq16sIPABiPA4V1IIEu1YnhfMsm?=
 =?iso-8859-1?Q?ftDeQDXzW5y6WdIlw7Wutth8OQjHVspMmV6eNfSABMdIFrVgehJFqVjEyL?=
 =?iso-8859-1?Q?lxVcKVQOR/GVM3OE5BVGyAOlCEcGO0BdF21WWDJ7Ge+7/QVXUxM9d0PEB7?=
 =?iso-8859-1?Q?s7Xtj+zG6A+mCnTu5FkpyfBnUvAkzXn1ebst3bESent3jmA2Fp9rMcIwNw?=
 =?iso-8859-1?Q?MANdLAwU7YAHA+3TY4uybBEusr90EsCsSb3sWQugslZaQ6vb0Hd4/kfUPc?=
 =?iso-8859-1?Q?xK/7RpiTeYqP1qV7OOzmTSttcKt9F0IAybqdIWPP1uT9+M2r//YhnKHj4x?=
 =?iso-8859-1?Q?WoABjpgpq9lIj5NyUvJvDV3hB6L/veM9w7m5VzW7hrbDQ1FBBxnMWw5Zr7?=
 =?iso-8859-1?Q?DlatwkpRbQKqxGdXTMmGPn3oSyrhlPgmh673jzoQoZLASB0Ge4OW0v/2R7?=
 =?iso-8859-1?Q?uD5MaAdQkchP76rv8IVrBrHMGNTvt3Csxg2WKLBdQ9/U6pSikI8poQ/BNF?=
 =?iso-8859-1?Q?QmZ9XRFSu30sRpH13SlKq/J4LYcm5Jwb7RpGejtvJuhWBOyxQX8x77Ymkq?=
 =?iso-8859-1?Q?YRiqM4P2P9Gf07SxkAM/xBViUOL26rB5MpDLUPZP57RWbdMa+EF81Z1sDi?=
 =?iso-8859-1?Q?y1TPP34E5EDz2b5kvHpS10jMn4XxJHOu/xgUbt6jsSn0INtQyiExsAVvKn?=
 =?iso-8859-1?Q?k4Y3aGI2AerlmJCFgQ0FLvHgOfHkOANezrtE1d6YGOYw53fhtvrWKwpKkK?=
 =?iso-8859-1?Q?ro4vPKqbkgLf0x75qTcg7nJP6+6EBglFr3/HrSjpdKH2kkJJy2j2RrWJ59?=
 =?iso-8859-1?Q?Rdf8l5a8oI26fl0pKN6ISqMHm+VZuGZzbOLm2GoaO5FTUjuzbpkFrqECBi?=
 =?iso-8859-1?Q?o9LohJ8K5VWCun7a2QVVDEFlGhaZOY2aqPurDNv3gDMH6wNAwHltpgFA/1?=
 =?iso-8859-1?Q?UxPGF55hYHC/yvMIjhxYI1EAoND/WnsYm1HWhw7MmOGoEolwSXqF/KzEiP?=
 =?iso-8859-1?Q?SL9a5n378tjgx4yM54s/ZRghDaKLgX1k5IanUc0YGbp6iramhyKOsnk2w1?=
 =?iso-8859-1?Q?ciS2WBEtUtdTpnxCjdKvGqTzR8X7aWIOhT3AqbsJifHetVSxR8XjPl9Hqj?=
 =?iso-8859-1?Q?8u/ESn9XRkiyE3TYZ73sIXhfnQHzXmcJOJAQODlJqDFyZFyxVZe0Axoma4?=
 =?iso-8859-1?Q?krh8Q4eoNE15vhQI0O1oJ0YUOxDFMXk4v8AA0Q1PcxwhdJ/B2m+or0XUir?=
 =?iso-8859-1?Q?2OmkUq9sPO4i0p+s7ZUQfwOctaDESeppKWPIonJMAmiz1hlYmQb1YWFMz4?=
 =?iso-8859-1?Q?BULBy0wH8ZsE5zkFd1ylsBH4BzGC/Esu4xiyP9QbcARgnvcOWL7ljlPEw9?=
 =?iso-8859-1?Q?yDLvHoL2W/aMC2h0/qDuwJ3ePZ3j0U7u+yHKutNWKDVJQEW9r8DnIex8X8?=
 =?iso-8859-1?Q?EuqL3aYpETFn7XQ7DZ1OnbNGo6VflrMOTUeBhwolXEI+hEmKSnzXAf7gPi?=
 =?iso-8859-1?Q?j1UiMaslWyXM6DxiTHTJsNIBIa27NS5jLZv1/kDcVSdcxedBRtZtQxlrcz?=
 =?iso-8859-1?Q?jn4yw+orvK8VMU6rTbfASEStfFcBQrky/2T7ZUTQU4EOo1T9w7NPmYJA?=
 =?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: fc83916b-2a3a-4316-5baa-08ddfb404607
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 07:59:22.7380
 (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: AU20rAM3gDiGsnL/z74o7dr7IYOm3J5/7ioOiXa2ZEzJEm/20OQ7kDSliE+DEMr9VJUnVQr5lW4MPJObQAqjsA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10523

From: Stefano Stabellini 

has_vpci_bridge is a macro to check if the domain is a domU or is dom0
with vPCI (pci-scan=3Dyes) enabled.

Use the macro in drivers/vpci.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
 xen/drivers/vpci/header.c | 14 +++++++-------
 xen/drivers/vpci/vpci.c   |  4 ++--
 xen/include/xen/vpci.h    |  9 +++++++++
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 469f497744..903168ff96 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -230,7 +230,7 @@ bool vpci_process_pending(struct vcpu *v)
=20
             read_unlock(&v->domain->pci_lock);
=20
-            if ( !is_hardware_domain(v->domain) )
+            if ( has_vpci_bridge(v->domain) )
                 domain_crash(v->domain);
=20
             return false;
@@ -492,7 +492,7 @@ static int modify_bars(const struct pci_dev *pdev, uint=
16_t cmd, bool rom_only)
             }
         }
=20
-        if ( !is_hardware_domain(d) )
+        if ( has_vpci_bridge(d) )
             break;
=20
         d =3D dom_xen;
@@ -522,7 +522,7 @@ static void cf_check cmd_write(
 {
     struct vpci_header *header =3D data;
=20
-    if ( !is_hardware_domain(pdev->domain) )
+    if ( has_vpci_bridge(pdev->domain) )
     {
         const struct vpci *vpci =3D pdev->vpci;
=20
@@ -564,7 +564,7 @@ static void cf_check bar_write(
     struct vpci_bar *bar =3D data;
     bool hi =3D false;
=20
-    ASSERT(is_hardware_domain(pdev->domain));
+    ASSERT(!has_vpci_bridge(pdev->domain));
=20
     if ( bar->type =3D=3D VPCI_BAR_MEM64_HI )
     {
@@ -747,7 +747,7 @@ static int vpci_init_capability_list(struct pci_dev *pd=
ev)
 {
     int rc;
     bool mask_cap_list =3D false;
-    bool is_hwdom =3D is_hardware_domain(pdev->domain);
+    bool is_hwdom =3D !has_vpci_bridge(pdev->domain);
=20
     if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
     {
@@ -829,7 +829,7 @@ static int vpci_init_ext_capability_list(const struct p=
ci_dev *pdev)
 {
     unsigned int pos =3D PCI_CFG_SPACE_SIZE;
=20
-    if ( !is_hardware_domain(pdev->domain) )
+    if ( has_vpci_bridge(pdev->domain) )
         /* Extended capabilities read as zero, write ignore for DomU */
         return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
                                  pos, 4, (void *)0);
@@ -866,7 +866,7 @@ int vpci_init_header(struct pci_dev *pdev)
     struct vpci_header *header =3D &pdev->vpci->header;
     struct vpci_bar *bars =3D header->bars;
     int rc;
-    bool is_hwdom =3D is_hardware_domain(pdev->domain);
+    bool is_hwdom =3D !has_vpci_bridge(pdev->domain);
=20
     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
=20
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 07c7071d0a..8ea89b9805 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -48,7 +48,7 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
=20
     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
=20
-    if ( is_hardware_domain(d) )
+    if ( !has_vpci_bridge(d) )
         return 0;
=20
     /*
@@ -429,7 +429,7 @@ static const struct pci_dev *translate_virtual_device(c=
onst struct domain *d,
 #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
     const struct pci_dev *pdev;
=20
-    ASSERT(!is_hardware_domain(d));
+    ASSERT(has_vpci_bridge(d));
     ASSERT(rw_is_locked(&d->pci_lock));
=20
     for_each_pdev ( d, pdev )
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 9ae75d946a..e0aecfac72 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -339,6 +339,15 @@ static inline int __must_check vpci_reset_device(struc=
t pci_dev *pdev)
     return vpci_assign_device(pdev);
 }
=20
+#ifdef CONFIG_ARM
+#include 
+
+#define has_vpci_bridge(d) (!is_hardware_domain(d) || \
+                           (is_hardware_domain(d) && pci_scan_enabled))
+#else
+#define has_vpci_bridge(d) (!is_hardware_domain(d))
+#endif
+
 #endif
=20
 /*
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 08:54:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 08:54:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129178.1469242 (Exim 4.92)
	(envelope-from )
	id 1v1LGR-0003mX-BZ; Wed, 24 Sep 2025 08:54:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129178.1469242; Wed, 24 Sep 2025 08:54:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1LGR-0003mQ-90; Wed, 24 Sep 2025 08:54:15 +0000
Received: by outflank-mailman (input) for mailman id 1129178;
 Wed, 24 Sep 2025 08:54: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 1v1LGQ-0003mJ-28
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 08:54:14 +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 0aaf4667-9924-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 10:54:12 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB8665.eurprd03.prod.outlook.com (2603:10a6:20b:54b::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Wed, 24 Sep
 2025 08:54: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%5]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 08:54: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: 0aaf4667-9924-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cogcIfnzIQEh94CprxZA+S/6VV/IXnFvSydl+EcLErXW6CsGqOsOZ+jaGOzCUpVmJCiQ/oLv1dxu5F7f0DpM/QA30cqpM5Sgp3VeCxOZScuyuw0+meNhp7WivvUvpniNQ2Q6ioRxjJv7dEQ1kbZKj2sVFoQTrh/yv1iX5wkcYsUkBla/G3bG0agmRHwIbFBbwlHGj9MUrDXGKbOaWr5PvUyWGHGds1tloAOay9mQwneSYkpz8GPIped/ONnM8fWlDWbtWKICZ1dTYvkD1XOQbQ/ACJAwZ6nhIN2DOVQnWbCqVAfL8x2RnSfNEHbbJ+ZZBzX23e3ddr/Uhnbfj6+Eiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KPzWaI8ECtuovcPkRp2gxC7xqQHeV5oSsCr7QsGxeF0=;
 b=FM+try783nuSHXD92h4514AHvap4L2nJcx6N7v0vqTSvuFizi25Hqa/pfiBHm8niz2vWRCC80yrjw/cnxWZvVycwjDj6JV4e3bBHB4JjD8ew5w5noInkEbztuIMLtpTWhEU3j6Ur8IajUtJ5fXCmAaVZuHEg+U1anms63aDUKKQjYtkZMvJScOS9eD0f+QIVjb9WdTm2YUWL7xsAkBU8/QRmWIpH+LJm/GktkvytNnjymrlDMcrkFMFueV/xfaDYwUJSQ4vZqIsPeLhsemVMzU2TTxz+qPmUTaMfuuJoFatnPK8iy0rnA6FLMUqvm3gmBquDAZcgzYLSpuFtefxjOg==
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=KPzWaI8ECtuovcPkRp2gxC7xqQHeV5oSsCr7QsGxeF0=;
 b=aVSpOy750GQ6DdQmesR7msK+4aRlDSHK2E95PD7DuVxVlt+bVXt0UKIRpo1RtqXZ6FofSoixNTZerKlRw2ulBOM+12/Pj4AzLr0eFE77HF6hpUnC6XotUmYAThne4bPy1D16mb4MM4sTVOWtYE3TjwQ+by2OInV8mDQQRfNvMmRiY3GUBmubA5WJpQojdJ+3L/JFpxL+mz3YBLNEESXwsnfqEp8JQ8a8wbdVQ4SrxSa1lBuh0iCJOj9/pJoAOV6tWfpHWmANbquhalPssD7BWmF7xHcqzSutsbGaQNwDumuvI/qYGnIwBC811hMN5vSeXTWcHWmTTT6HpAGdEJepUg==
From: Oleksii Moisieiev 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Oleksii Kurochko
	
Subject: Re: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Topic: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Index: AQHcJXs1K3LqZ5+aqE65C1kspBdxM7SfhaoAgAKQ8gA=
Date: Wed, 24 Sep 2025 08:54:09 +0000
Message-ID: <4b1cab53-e2dc-4cd4-86b5-1d1be974d089@epam.com>
References:
 <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
 <6476dc12-1f9f-4b37-b569-e994bde6bcdb@xen.org>
In-Reply-To: <6476dc12-1f9f-4b37-b569-e994bde6bcdb@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_|AS8PR03MB8665:EE_
x-ms-office365-filtering-correlation-id: 0eed37ac-4d9b-406a-0247-08ddfb47ed2e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?QlpjUTZsOThHd3hEWmlQcjE1UU1KeTRIZ21xQTJpM0Z2NDN5ZDdJa09MeStW?=
 =?utf-8?B?RmZaZnFHVVBoajZ4NFpFYzhsUlZpaHNVaDF0RlFCZzNzMFcrR3FOdUwwUW9Z?=
 =?utf-8?B?KzJueTQweHpOZitudUYvU1gyNzk0YVBxbnJSNHBZMmhaVTJyK0NtdkRVZnlO?=
 =?utf-8?B?a0ExQUlhdjY3V3MwUUlieDdzNkpucG8vdklZRGpvOW85Zi9xazVrSzhPcEI4?=
 =?utf-8?B?b2RONEl2Q00zQ0N4NC9kVFk4Z0hOZGxCZUcyZ1RkbDRWblZOVExWSVJuaDhN?=
 =?utf-8?B?RWx6L3RJYkR6WWpEUUl6WW50eGQ1aFAycjVsMnRCQlUvNkJyRU4yTHZPak42?=
 =?utf-8?B?VVh5dTROVFdwbE5URnlYSFVlOE1Bb0t6U0w3YmxRQTVyMkZHRkVzdnZXcW1E?=
 =?utf-8?B?TGdCNFBkRERDS3A3Y0pxMStUUnZiUWp0dFczSlpidVdoOXRKcnA4UWcxd05w?=
 =?utf-8?B?NkdPSUYyWFloN1R0UGRvQ0hzYTRYUnh3SlluVGhkaWh4QlpNeGZEekRwa2Nq?=
 =?utf-8?B?THZKTW9NNzdXZEZTeVpjMlNzczF3YW9UZVpCcGkyemg5bHZ5OE5EaGtUdWdX?=
 =?utf-8?B?U3hqemh0K2t3N1g3V2EzL0hJd0xtMDRLWThMZHQ2cWE4NlNzRTJHUHVZemVv?=
 =?utf-8?B?dThxcldvY0k3ZXF2MlMxY3V3WUM5aUJQSUcvOWtRdjk4aStpR2lwRUg1STF6?=
 =?utf-8?B?T2JFOGNUaFhlMHRGMTBKVjQ1YTYrMHcvVDYrdnJVaEkvZitJZVBJcVo5ckg2?=
 =?utf-8?B?L1lVYTFaTzFLQjdqZDBVUmwwcXRCQ1lxUzQwQVpVY3RKamVBTXBRbXg2K0N4?=
 =?utf-8?B?dlR1RnJ3cWdXaCtjZk44aHFqZWJTOUJPQ3hucVdrSlFkYjZFT2RtTDZqN29S?=
 =?utf-8?B?WkNPQXUxWWpxMVB5WkdqMHZCNEx2bXRTU1Blb3RUWkxEbHBhclBScU93MVky?=
 =?utf-8?B?WkEvS01ta1lXb3ZOdVR6RU5LRlZWRkE5WXdoSGdZWnhrRWpUUHppN3JVcXBV?=
 =?utf-8?B?bkw4Q0d6WW04NTRCd1FaZXdxQTlWMm45OVZEYVRIVXVBN3UzNUdCTVVvb3M4?=
 =?utf-8?B?ZTRocUtndStDWTR3RlU4ZXQwbE5Ca0pqN1VNK3l1SERzdVhYMkREKzhQU1Q5?=
 =?utf-8?B?TG04RVBXbjZLWEl2cS80a1hsVGN3dC83UFV6WitXeEZ3dE9QdHJIR1lTYnFi?=
 =?utf-8?B?eThtUEp6NXNucDhRWnJwZzNuK0JRcFVGZVlmOXpncWxBWUI0Q2hBYzd0cDBB?=
 =?utf-8?B?eWp1aHNtTHhvUGV0djFrLzlySFJXMEZsVlE5UldQd1lWWDFIa0ZnckdVMkEv?=
 =?utf-8?B?c05ONXNwZ0tocE9adHpqNU1BVWFwK20rd1Y5QXllNHN0cEplMmEzdktDOXN3?=
 =?utf-8?B?cXk1cURHMEU4dGpjM2lKanpnbVp4a2lXQTIyUGdwT3dOM3pUUWd6TFV2Ym56?=
 =?utf-8?B?NGxUbHNXVG0vbng1YVQ3YzRXUUpPTkQrK2xHRGZYdFFYZW1NVitTbXFLOXBZ?=
 =?utf-8?B?empRTjdwR0JESHg3ZU5aOFJZYnh2MjFNK1ptWVZGL2t5dDJ2a2FHajZGemxV?=
 =?utf-8?B?RmJOSGJGL21RNEVtUE11NC9PZGhHTVhYcytPQXEyaC94cVpLN0I2eFdhRk4w?=
 =?utf-8?B?VEovZ1dRWVlCY1JhVGlVcStYQ2lVRlRIM1pyU3k1czBsQURqdHRNenpSa1Fv?=
 =?utf-8?B?WFpoVlFCWExnLzk3REZCVWtua3lvK0gyZklrVk9XSFBRenFpcVo4Q2RVK2tu?=
 =?utf-8?B?Mlc4UkdTT0QyTEdMTHBBQUVNWC9mNjMwZ3BTSXR6TFFMaWxWUFhLZ3V1SkNU?=
 =?utf-8?B?TTF1dzBReFRvdFVyMWkxV2FWNHZiUzlWaGFwcWdBcCtReWZ0WEs4M0VWbVR0?=
 =?utf-8?B?NGQ3ZnVDYzI0NUM5dktEWmVoaUtFYk9VL3hFa2RHYzc0ZnIxdWhzclBLUlNN?=
 =?utf-8?B?MHorbEM2clVUUFZOdUFmYk9OdDB3L1F5NHowRXF2ZCs2bDFLSmZmcWdoN0to?=
 =?utf-8?Q?Dw1JfcnL6cxMXmBsPFgb8hvvrLYj9w=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?YVY0aXdTZXBjanBqTnVZT3dlNlZuUkVMaDdSKzZ1dkdPbm5pbVFtRlpnckdO?=
 =?utf-8?B?eUlHWnFBMUt4VlZvMEZvQjVzZ3QrVUxlNTdJYmtrN09GNmxleEs4eTcyaDRC?=
 =?utf-8?B?UVpWOUVsZUlneFkzL2tzUkxSbENYSXFzeDdhZ0hDQ1hGRmwvc0Nvam1hZkEr?=
 =?utf-8?B?aElwa2NTemhqTXZsSC92N2tLQkpFT3VRUHFKZGtHSVBBMFB6VGVJVlZCaVZr?=
 =?utf-8?B?R05ickM2d1JsZ2hLd1IrRytwc1htNTlYd2xOQlcwU2pMVjFZWGJ4UnlvekYw?=
 =?utf-8?B?WnFHTzY3RE5UeS9PZHpuanBJMHk0czdURnFLMEcvalpCSVoycVJKWWJtMTFM?=
 =?utf-8?B?UFVGQTF6UlduNzdncDdYQXJ1RHpIU3o3WWZQSlhscHhISVFBeThFUENxNklO?=
 =?utf-8?B?blBKNzF5ejNlUzhSQU5BQURWNFkzcnVra2srempRK1pkVzVsSVBmUy9ZUWVW?=
 =?utf-8?B?WTI3RnM1WktKeitCNkJoc3NkeHhmeTM0UzA5ME53dkZDT2lZNHhRS3BMaitS?=
 =?utf-8?B?bWt0K2pML2xwSnBKUUFGemVFbVdSbzVjTWgzYjNMSTBabGpUVFhvdjIwT3RV?=
 =?utf-8?B?aHdSK3B0TEVLZlVBYjJHeXZ0SjVNclE3VzdFNEl1SEI4bXVLZXQ5aDh5ZUxB?=
 =?utf-8?B?bitERVdrNDh6WWtGcWMxNVN4VFZxWW4wOS96Mi9sczBBbFJ4MmZkT2czVTd0?=
 =?utf-8?B?ZmoyejQrdkl6N1pKWEFJc2E0RU1aTFVCNGluRVkvcW12bmY4cHJtQUE5WFhx?=
 =?utf-8?B?QzhUNHNnOHBFUU9nVU1CVitwL21zNG5HWGxnVmw1Ylc5T3czMVRNVFEwZ2dx?=
 =?utf-8?B?dlo4c3lvY1kweVFhSjJEUkRSMDFINVdSUzhGbkxXV0xtREQxS2JkQlBKd09S?=
 =?utf-8?B?UVlPR3VVM3ZIQTAwVUJIZWdMMHZ3b3VxU0FWeW9xTjVHa3AyMzV4YzJUTXcx?=
 =?utf-8?B?Z3NsTjdVKytTcE9xKy81TmMwZzJCNCtvT2pxWXdJZ1N5a29taGdDbjJpR2ZF?=
 =?utf-8?B?S2dZLytJUTNxZU9DeGVGaEJvdlhsYUo2QzFzbnJxQm5NbTRGYWhmWVRHUGtn?=
 =?utf-8?B?OSs0OFhlU0puTUlpVVdVeXNpakZscllVL1JCNnhnbDJtZ084Qmo3Rmk1dis3?=
 =?utf-8?B?REdiclVUY0FNT1d5TWJIK2RpVVk4d0VPWmxSNW8vdTFGL2lqNWRLb0p1Tnls?=
 =?utf-8?B?RzZqbGp2QVhGMzVHN2FPeDNPSjRQMksxTFVDYnZGeFJEbExPOEdIYWd0bDNj?=
 =?utf-8?B?djlMdytXeXNUQTd5QXJTemh6RUg3SFZMd0VlejBucStYQW1YcmFjdTFUN2s2?=
 =?utf-8?B?QUV3N3N1M2xQZmp3c2NXNVB5cUJGbXVJbEhHcGtWeVRiOHFzRmtVWXRud2cv?=
 =?utf-8?B?SWExVHlJb3VEZTVGTW9ObG1iQ1BTTUc4TzFNWmt1SXJyRm81dlZwRWRucFM0?=
 =?utf-8?B?YWExN2JBeEJJdVNqVU41dGxPWkdNdWtuNUpEUzFDTk0vUUlmeDFOOUQwQ0lt?=
 =?utf-8?B?SURQVEdOOW81V0hGYURVOENZY1pHL2p3emxVNW5jWWRsalJoU2VFcG42Qjl4?=
 =?utf-8?B?S1VsOFU5UVdXaTllUkExUmhFdmYzL1ZJdElTUGZveVJwb0VNdGRCek5CMlZu?=
 =?utf-8?B?OWc2MmZZQjJkQzByajY0NFZreUdFWGVjK0U5ZGdTcDZJc2dhOWppRTNhQ1ZN?=
 =?utf-8?B?NkVTYUZGZXVDZXVMb2VPRVZHNTZpcmJzNzZIMUN5VFZtYnIvQ1oyQVkrcVgv?=
 =?utf-8?B?N01tVlBqNjVDdUpsK1JndW0zVVdpTEQxRkR0K0JDVHdQWC90SkJIVTB6cmdh?=
 =?utf-8?B?RXpYSzdlbXlIRFdXK2ViQnd0RWkyL0twWW9wOXltN3V5MUxIMUZJcU9qUzA3?=
 =?utf-8?B?ZVJKeDZOUzlvZEFZakJhalBqTVN0bzJsaXhLdjNncWZvL2VoMzVmUDc5Y0c3?=
 =?utf-8?B?cDU5cUxad3VrOFFWTGtmOW5oYXhEb3lhZEtKejE5bzBoSngyNjFIOWh5RWtD?=
 =?utf-8?B?dHNrK0haS1lzNjNuRW5oWUxweGtmUlFkZEhnLzRTZ0dwOHNZU1lIeDc5Vi9D?=
 =?utf-8?B?Y3B4RGtsbi92NjVCazlPRnlMMTZyNzdSb3c4NVFaZVV1eFZoQTU5THdUZHlh?=
 =?utf-8?B?ZDhzbU1wYkJwWmxlRldVbGVwc0FoeWV2NWFOUzZ3Q0dPeDJZNXc3QVlzV3E2?=
 =?utf-8?B?VEE9PQ==?=
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: 0eed37ac-4d9b-406a-0247-08ddfb47ed2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 08:54:09.6493
 (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: IW0VbJ6QhZYvh8uXgIM/60g4Fmvk6Ap25h5NuqTltjCWxwNfmLfVFJopfM+nPy3IbP/UyXdZOa650hvRZIOoBzUbkE6q8R3LzLPRa4dwzfw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8665

SGkgSnVsaWVuLA0KDQpPbiAyMi8wOS8yMDI1IDIwOjQyLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+
ICgrIFJlbGVhc2UgbWFuYWdlcikNCj4NCj4gSGksDQo+DQo+IE9uIDE0LzA5LzIwMjUgMTQ6MjYs
IE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gTW92ZSB0aGUgU0NJIChTeXN0ZW0gQ29udHJv
bCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UpIHJlc291cmNlIGNsZWFudXANCj4+IGVhcmxpZXIg
aW4gdGhlIGRvbWFpbl9yZWxpbnF1aXNoX3Jlc291cmNlcygpIHNlcXVlbmNlIHRvIGVuc3VyZSBw
cm9wZXINCj4+IGNsZWFudXAgb3JkZXJpbmcgZHVyaW5nIGRvbWFpbiBkZXN0cnVjdGlvbi4NCj4+
DQo+PiBUaGUgU0NJIGNsZWFudXAgaXMgbm93IHBlcmZvcm1lZCBiZWZvcmUgVEVFIChUcnVzdGVk
IEV4ZWN1dGlvbiANCj4+IEVudmlyb25tZW50KQ0KPj4gY2xlYW51cCByYXRoZXIgdGhhbiBhZnRl
ciBQMk0gbWFwcGluZyBjbGVhbnVwLiBUaGlzIHJlb3JkZXJpbmcgDQo+PiBlbnN1cmVzIHRoYXQN
Cj4+IFNDSSByZXNvdXJjZXMgYXJlIHByb3Blcmx5IHJlbGVhc2VkIGJlZm9yZSBvdGhlciBzdWJz
eXN0ZW1zIHRoYXQgbWlnaHQNCj4+IGRlcGVuZCBvbiB0aGVtIGFyZSB0b3JuIGRvd24uDQo+Pg0K
Pj4gVGhpcyBjaGFuZ2UgYWRkcmVzc2VzIHBvdGVudGlhbCByZXNvdXJjZSBjbGVhbnVwIGRlcGVu
ZGVuY2llcyB3aGVyZSBTQ0kNCj4+IHJlc291cmNlcyBuZWVkIHRvIGJlIHJlbGVhc2VkIGJlZm9y
ZSBQMk0gbWFwcGluZ3MgYXJlIGNsZWFuZWQgdXAsIA0KPj4gcHJldmVudGluZw0KPj4gcG90ZW50
aWFsIGlzc3VlcyBkdXJpbmcgZG9tYWluIGRlc3RydWN0aW9uIG9uIEFSTSBwbGF0Zm9ybXMgd2l0
aCBTQ0kgDQo+PiBzdXBwb3J0Lg0KPj4NCj4+IEZpeGVzOiBlMmNjMTA4NjdiICh4ZW4vYXJtOiBh
ZGQgZ2VuZXJpYyBTQ0kgc3Vic3lzdGVtLCAyMDI1LTA5LTA0KQ0KPg0KPiBJIGFtIG5vdCBzdXJl
IHdoZXJlIHlvdSBmb3VuZCB0aGlzIHN5bnRheC4gVGhpcyBpcyBub3QgdGhlIG9uZSB3ZSB1c2Ug
DQo+IGZvciBYZW4uIEl0IHNob3VsZCBiZToNCj4NCj4gRml4ZXM6IDxjb21taXQtaWQ+ICgiPHBh
dGNoLXN1YmplY3Q+IikNCj4NCj4gV2hlcmUgdGhlIGNvbW1pdC1pZCBpcyAxMiBjaGFyYWN0ZXJz
LiBGb3IgdGhpcyBwYXRjaCBpdCBzaG91bGQgYmU6DQo+DQo+IEZpeGVzOiBlMmNjMTA4NjdiNjMg
KCJ4ZW4vYXJtOiBhZGQgZ2VuZXJpYyBTQ0kgc3Vic3lzdGVtIikNCj4NCkdvdCB0aGlzIGJ5IHVz
aW5nIGNvbW1hbmQgZ2l0IHNob3cgLXMgLS1wcmV0dHk9cmVmZXJlbmNlIDxzaGE+DQpXaWxsIGZp
eC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9tb2lz
aWVpZXZAZXBhbS5jb20+DQo+ID4gLS0tPg0KPj4gQ2hhbmdlcyBpbiB2MjoNCj4+IC0gcmVhcnJh
bmdlIGVudW0gYnkgcGxhY2luZyBQUk9HX3NjaSBiZWZvcmUgUFJPR190ZWUNCj4+IC0gYWRkICJG
aXhlczoiIHRhZw0KPj4NCj4+IMKgIHhlbi9hcmNoL2FybS9kb21haW4uYyB8IDExICsrKysrKy0t
LS0tDQo+PiDCoCAxIGZpbGUgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygt
KQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluLmMgYi94ZW4vYXJjaC9h
cm0vZG9tYWluLmMNCj4+IGluZGV4IDFhODU4NWQwMmIuLmUzNjcxOWJjZTQgMTAwNjQ0DQo+PiAt
LS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9kb21haW4u
Yw0KPj4gQEAgLTEwNDIsNiArMTA0Miw3IEBAIHN0YXRpYyBpbnQgcmVsaW5xdWlzaF9tZW1vcnko
c3RydWN0IGRvbWFpbiAqZCwgDQo+PiBzdHJ1Y3QgcGFnZV9saXN0X2hlYWQgKmxpc3QpDQo+PiDC
oMKgICovDQo+PiDCoCBlbnVtIHsNCj4+IMKgwqDCoMKgwqAgUFJPR19wY2kgPSAxLA0KPj4gK8Kg
wqDCoCBQUk9HX3NjaSwNCj4NCj4gQ2FuIHlvdSBjb25maXJtIHRoaXMgaXMgZmluZSB0byByZWxl
YXNlIHRoZSBTQ0kgcmVzb3VyY2VzICphZnRlciogd2UgDQo+IHJlbGVhc2VzIHRoZSBkZXZpY2Vz
PyBEb2VzIHRoaXMgbWVhbiB0aGV5IGFyZSBub3QgbGlua2VkIHNvbWVob3c/IEZvciANCj4gaW5z
dGFuY2UsIGlmIGEgZGV2aWNlIGlzIHJlLWFzc2lnbmVkIHRvIGFub3RoZXIgVk0sIGNvdWxkIGl0
IGZhaWwgDQo+IGJlY2F1c2UgdGhlIGFzc29jaWF0ZWQgKD8pIFNDSSByZXNvdXJjZXMgd2VyZSBu
b3QgeWV0IHJlbGVhc2VkPw0KPg0KPiBDaGVlcnMsDQo+DQpUaGlzIGlzIG5vdCBhbiBpc3N1ZSBm
b3IgYSBzaW5nbGUtYWdlbnQuIFRoaXMgaXMgYmVjYXVzZSBzaW5nbGUtYWdlbnQgDQpkb2Vzbid0
IGltcGxlbWVudCByZWxpbnF1aXNoX3Jlc291cmNlcyBjYWxsYmFjay4NCkZvciBtdWx0aWFnZW50
IGltcGxlbWVudGF0aW9uIHJlbGlucXVpc2hfcmVzb3VyY2VzIGlzIGRvbmUgYnkgc2VuZGluZyAN
ClNDTUlfQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OIG1lc3NhZ2UgdG8gdGhlIGZpcm13
YXJlIHdoaWNoIHNob3VsZCANCmRyb3AgYWxsIGFnZW50IGNvbmZpZ3VyYXRpb24gcHJldmlvdXNs
eSBkb25lLg0KSWYgd2Ugc3RhcnQgYW5vdGhlciBWTSB3aXRoIGFzc2lnbmVkIGRldmljZSBzeXN0
ZW0gd2lsbCBhc2sgZGV2aWNlIA0KcGVybWlzc2lvbiBmcm9tIHRoZSBmaXJtd2FyZS4gQW5kIGlm
IGRldmljZSBpcyBhc3NpZ25lZCB0byBhbm90aGVyIGFnZW50IA0KLSBlcnJvciBzaG91bGQgYmUg
cmV0dXJuZWQuDQoNCi0tDQpPbGVrc2lpDQo=


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 09:36:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 09:36:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129205.1469253 (Exim 4.92)
	(envelope-from )
	id 1v1Lv6-0000Yl-HO; Wed, 24 Sep 2025 09:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129205.1469253; Wed, 24 Sep 2025 09: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 1v1Lv6-0000Ye-Eg; Wed, 24 Sep 2025 09:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1129205;
 Wed, 24 Sep 2025 09: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 1v1Lv5-0000YY-AZ
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 09:36:15 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9752e3f-9929-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 11:36:13 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-b0b6bf0097aso1182819566b.1
 for ; Wed, 24 Sep 2025 02:36:13 -0700 (PDT)
Received: from fedora (user-109-243-67-38.play-internet.pl. [109.243.67.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b29f45b5384sm856040566b.27.2025.09.24.02.36.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 24 Sep 2025 02:36: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: e9752e3f-9929-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758706573; x=1759311373; 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=eM13Ah7EvPl7q7ylYUqO4dw83eLOYYf8SpoQ1C3vCO4=;
        b=E0KTT77AH23gK5L7Xg3yBXPwJizZVm3u683uTE9IBb+srDO9FQ7bVJAyQH2h5zofh+
         09S8YtnBqti0btGw5h7YvOWU55n6VvBpKCzjdMS53BKn0eGAhXsAd++/5m8UKp+V0sc7
         XkRfhVFbySL8jsjom9acaoMZo8p2OjMQcMS/yPsogDVDSgEJgC511aeeSSVfukXae2Ds
         Ma3LC6MATwI3PF5VmxrfpO/b6VysNefgQosDDMYOonODTZk6AP0040fqX0lQmnVYlgP+
         lnlEWSL52R/C7MgBmap9qCgez21jqUEA/Gf9do/mn8gNfjVugz3q7icTqLA7XwDY2C+t
         s2mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758706573; x=1759311373;
        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=eM13Ah7EvPl7q7ylYUqO4dw83eLOYYf8SpoQ1C3vCO4=;
        b=klbB70Zq2FQpcLwxzY2mczSs7PihKX7EReMiaBHpMsaglRAus9A6e75OsjNxDfrMUe
         K3fjXd8oB8jd4l1hyXzzcPnzCkqnalFW0oh1uawFXZncj4w/P6K7e77yy2F3vWDyvpzn
         8WCr0X/iLFVE5zBuXURMhfBeQuTmc4zjMeHoqUo3dazHpsIOsTK0cil8gXgsmtsjhG57
         +QhehzG7wxFEw5LNslZsFYGHlIAstTdUs4iaKRMi+yRd/QodE/22ffmPpogkUX3iFBSx
         eqjTfRSwneQ8UG5swKhTDmepCKl8KK5vM0YDah/RummGnsBVk2knXE5mQkiEVaFe7M34
         sr9Q==
X-Gm-Message-State: AOJu0YymFvCxuT92jeM+flO0pq83XmW8RgWdUhI/H1j4vo0e2pqTXZqi
	EWX0F8pHppJsJm2oYBH6g+r82s8sAO/bUHqHKBtTTjVhOizQ+onh7zdq3/thaQxC
X-Gm-Gg: ASbGncvE3vq/TQOJKSwJBmsp9J+EYyQ3OsKQYV4Dkah2FyhyR4V9jjuGrdr/eeYWaj9
	74rBsaYolcCAPrdIVT/XdxRqHZ75uFbJyFt7GFzwCANKZawvAnskt8Sa0LHCGyEVrbeqjRbOAkp
	xlAFsUFdga1ZqBUKMvVAzp512Ey1MmKpv5FXOICXxzuXtVeHPshr/39D4c9oqquexGEnxdumVu2
	m34B0Eol0iODv3f15DPuBND+z/ltpeRtkITqpndFzggFWJHUymXWxgM7qg1avYoPTdE4sm3SnGY
	nHBPscIgW6WtPVpJdn9BuAjikE2vjpRusnXrPBlmluN9+MlBot0r45P3Hhx5dceFooZAKJNa/r5
	s9Q/nwrAlgwZfSfGWJzzk4JDRr4IUJDTQO1oSqOyyh0Gk4RWNyefYscajxXBw3UWsVEcdO55lYA
	==
X-Google-Smtp-Source: AGHT+IG3WifV+IqHTvoUsXBBrRoGqXZpCVxcU3HUWzNtVXFHkS4wwBMF2KyBT6FI7avwk4Lkz80OUA==
X-Received: by 2002:a17:907:3d56:b0:b04:4175:62f7 with SMTP id a640c23a62f3a-b302a17bd6amr626528666b.33.1758706572718;
        Wed, 24 Sep 2025 02:36:12 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: committers@xenproject.org,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH] CHANGELOG.md: Update for 4.21 release cycle
Date: Wed, 24 Sep 2025 11:36:04 +0200
Message-ID: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
---
 CHANGELOG.md | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ca1b43b940..5a0902cc3e 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
    to the baseline change.
  - Linux based device model stubdomains are now fully supported.
+ - Remove libxenctrl usage from xenstored.
 
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
@@ -21,6 +22,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - 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.
+   - Allow to unflatten DTs.
 
 ### Added
  - Introduce new PDX compression algorithm to cope with Intel Sierra Forest and
@@ -36,11 +38,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
      Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
      and 28 (Temperature Probe).
+   - Basic kexec support to Mini-OS for running in PVH mode.
 
  - On Arm:
-    - Ability to enable stack protector
+    - Ability to enable stack protector.
     - GICv3.1 eSPI (Extended Shared Peripheral Interrupts) support for Xen
       and guest domains.
+    - SMMU handling for PCIe passthrough.
+    - R-Car Gen4 PCI host controller support.
+    - SCI SCMI SMC single-agent support.
+    - Initial support for MPU, R82, and R52: reaches the early boot stages.
+
+ - On RISC-V:
+    - Basic UART support and external interrupts (APLIC/IMSIC only) handling
+      for hypervisor mode.
 
 ### Removed
  - On x86:
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 09:50:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 09:50:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129218.1469263 (Exim 4.92)
	(envelope-from )
	id 1v1M8Y-0003Ci-PM; Wed, 24 Sep 2025 09:50:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129218.1469263; Wed, 24 Sep 2025 09:50: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 1v1M8Y-0003Cb-LL; Wed, 24 Sep 2025 09:50:10 +0000
Received: by outflank-mailman (input) for mailman id 1129218;
 Wed, 24 Sep 2025 09:50: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 1v1M8W-0003CV-Fs
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 09:50:08 +0000
Received: from mail180-36.suw31.mandrillapp.com
 (mail180-36.suw31.mandrillapp.com [198.2.180.36])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d90a2ae9-992b-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 11:50:06 +0200 (CEST)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-36.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4cWsXD3jnmzlfqVk
 for ; Wed, 24 Sep 2025 09:50:04 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 a95f437e87e14ac58dcb47320785c0ef; Wed, 24 Sep 2025 09:50: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: d90a2ae9-992b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1758707404; x=1758977404;
	bh=+T+rqHkFzieoA2dv9XOW5DVES6ipn2iPK5DazaGcEFg=;
	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=uxbXQCDJ1eVRAQLUZ0X+1d/9V8R5mDdGbP71ofZsf47qbBNXrF0EQPfWiARq6cm4T
	 noF/L/JTlxzyX7qO9SfsE9xSTENRfasUOutS3EWCmoDmbQy3xvemwctVbeKPhy++un
	 PskfunL1gsiBhvvHwZImn5cvwfWlgDLzKerNaTARgshKMsYtBoHpX6AZYEoG4XItYm
	 uVxjsUxxolOoTH9aBCQxN4cgg+yQgLWVbCi9v0rhli4HoyiVtUhhbnlHUJwyvxVQuy
	 gSL6fJG81hoDIoJm+cxs81Fo8wqFsRlSo/vpnhsv3XH23LeOj+GLc6+8pAc7E3ISjt
	 pmy8c3nr62Jig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1758707404; x=1758967904; i=yann.sionneau@vates.tech;
	bh=+T+rqHkFzieoA2dv9XOW5DVES6ipn2iPK5DazaGcEFg=;
	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=MOIsg1WLeWnxxpEC3iyWQJ4HPtxfF9WabwSooGok5gyOp2HxH0XPaDliBhxouar4T
	 xPLV9tCYsMRzrd/9YeZy72QmiJmFGtFo21FtV76wcnfKnvbXS7BZ80/PEwATVZkGnF
	 1HZSx1OXVf62flcoTTjmzcHLUNy8m/KmzYz2fesCRz/8t/YUgJoyAeB35cXzv3Z5aN
	 02uQoM6L2ztAbyFCHd0ixTDctMDChn2lr0lk1g2MEYnfm7XB0uhZbMQL+JWqjLMAVr
	 P66DrvtVsswO2WBLBVNxG4SCJyhOFxV/7QbO6Oi51opE50ft6QvHdMyfsuLgvNA1m7
	 wBAvsvZO9g/Pg==
From: "Yann Sionneau" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v1=208/8]=20arm/pci:=20enable=20vpci=20for=20hwdom=20when=20pci-scan=20is=20enabled?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1758707403897
Message-Id: <1a591f0d-78cc-439a-b5d9-42f63fb3bd79@vates.tech>
To: xen-devel@lists.xenproject.org
References:  <2ac11726b5a236b022da5c51235e9a4efd92087f.1758618839.git.mykyta_poturai@epam.com>
In-Reply-To: <2ac11726b5a236b022da5c51235e9a4efd92087f.1758618839.git.mykyta_poturai@epam.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.a95f437e87e14ac58dcb47320785c0ef?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250924:md
Date: Wed, 24 Sep 2025 09:50:04 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 9/24/25 10:01, Mykyta Poturai wrote:
> With pci-scan implemented it is now possible to use vpci for hardware
> domains. Update has_vpci to reflrect this change.

Small typo in commit message "reflect".

> 
> Signed-off-by: Mykyta Poturai 
> ---
>   xen/arch/arm/include/asm/domain.h | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index af3e168374..dbe3347cea 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -305,8 +305,7 @@ static inline void arch_vcpu_block(struct vcpu *v) {}
>   
>   #define arch_vm_assist_valid_mask(d) (1UL << VMASST_TYPE_runstate_update_flag)
>   
> -/* vPCI is not available on Arm */
> -#define has_vpci(d)    ({ (void)(d); false; })
> +#define has_vpci(d)    (is_hardware_domain(d) && hwdom_uses_vpci())
>   
>   struct arch_vcpu_io {
>       struct instr_details dabt_instr; /* when the instruction is decoded */


-- 


--
Yann Sionneau | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Wed Sep 24 10:14:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 10:14:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129235.1469273 (Exim 4.92)
	(envelope-from )
	id 1v1MVb-00068C-Ji; Wed, 24 Sep 2025 10:13:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129235.1469273; Wed, 24 Sep 2025 10:13: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 1v1MVb-000685-GG; Wed, 24 Sep 2025 10:13:59 +0000
Received: by outflank-mailman (input) for mailman id 1129235;
 Wed, 24 Sep 2025 10:13: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 1v1MVa-00067z-Ps
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 10:13:58 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2ec67b77-992f-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 12:13:57 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU5PR03MB10304.eurprd03.prod.outlook.com (2603:10a6:10:51e::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 10:13:54 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 10:13: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: 2ec67b77-992f-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ER76Dphd3IiRw99mTfBAdZYmZV6B4SqyBNFdYYnwsUD+ZJdSRgjnPfEkyBzfJ6Vg+u0D7jv7xgRoe3lm7fdBpjLXbC9QGOKzc59gRwApNs2XN/0W1VVqDbPGkov+xGgxe1KssK9mM4reYhi+fHmrL+f+6aka/+wfxmdfpm965u4zFxPazXX4Qu8pnXuGeGuCaTeoRNXKStclL4H8qevFANLDIpJD3V1gdAW+/VfiNCN3XlLfYzVXWplOjFCm1Hv75SeDtpUqqxRHC25brvOlS5g70pHJdigLw15UvEaFf1nggX5M/gjKMEz5o9ZgYgnWegr5aKmp34DusgaH8DGr8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BZh24mg9yneXZeRrOk1njoyYCQYbTxK2zbMrRvHMnjY=;
 b=UYRimua3/ySGwrK997sD6LlZPGFlVyp0wWWFOuDYLJYow0Sr4XLZhIx3P/CoSP7RkphGs0vsjPu7FbtRl+HumRLB72W26x9C56uOTZPi+zCieMNayCoWUOTtQkE9KtRi0+5ORxwcPMsuPzObFAlg1VFESVbvJE8opHuAnHPKPe8332llr+XU768oCEdu60BWdT5a6h1VOdMpWHhyfdefDx0rl0dyirrD3Df2I52oXh9tYSG9N4A9mgAMEFMzC4cpN0FfY7rCUEBwsE1nDuqhFdU4/YOIF9IKzT9x89byoiMii1VY0skK9wrw7QWKBKforiGKTggIEzJt6beMGjd9gw==
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=BZh24mg9yneXZeRrOk1njoyYCQYbTxK2zbMrRvHMnjY=;
 b=sESfSFmKXrRPRcUXGLNE3BzOH7YEMGwGuai4BAi2AUiLJSZJxDFydAjkE7QEpiR2AIIcHRzTQ8A1fh28mD/efsjVCbTE9r3UYQH6x+YIc2HJxmpLoajHoX76SPH3343llKbmrGGBTqwwr3Jt7WGeanVT07f27+LTWuWyxbN4tx3PvwKf1xcW3LhGcPu0c/NWB85ak89sEShTUs6ObRAWsqmJwtoYtXdKKy9xB210tGxuRkqvndf6Y+AK2iIXS9/VcbjxMmJzJd/L2db5kzwI/nG7dN+pNkG6SIIg6/6RNmHSqZmn6ZULZs04yv628Dq1gjPWz4OI1KuR5hnunGuNOw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <74460196-3bf2-4927-ae38-dcb52755ff04@epam.com>
Date: Wed, 24 Sep 2025 13:13:52 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86: make Viridian support optional
To: Jan Beulich , Andrew Cooper 
Cc: Sergiy Kibrik ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" 
References: <20250919163139.2821531-1-grygorii_strashko@epam.com>
 <5c495ffc-40c9-4c55-bfba-3e1c0d9955c6@suse.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <5c495ffc-40c9-4c55-bfba-3e1c0d9955c6@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0108.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a3::11) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DU5PR03MB10304:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e2ab933-af1b-495c-9337-08ddfb5310a1
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?STIycGczeUFCbHRwY1VNZHp6WHFQKzNyUHBsSkZFaG9tUGhYR2pWOWFXM2Fi?=
 =?utf-8?B?c3BhSjl6dGxsYzJqMFZ2SG5sTXNBUFZrT3hnY2FjY2tRQ2lPZS9kTUtqRCt4?=
 =?utf-8?B?NStMZ2VWN3dTZi9JTm4yWkl2Qm90SE0vdmVibVR6dWdrcFJFN0tXeURsZEd1?=
 =?utf-8?B?SlNtaTlkdGpSYy91OGFaNy9QSjVKczliVzRsdVIxV1RTbktMMkRIVEhDWnQ4?=
 =?utf-8?B?QmNGcFlybURNbjQwSDJ5cDRJcEtrbE9XS2pIUFpFRVIzMjFWQ0hDQ3loMXJV?=
 =?utf-8?B?QlhKd3B3bzBoWTUzdUYwTVI0eFNuYWlycjdVb3RmVytJbzkrYnk1TVFqVm1x?=
 =?utf-8?B?OXZzdXhiN3JxdFdyS1pKaHFuSTVsQUh6MXNlVmdta3FNOW5yOUhibExsV0l2?=
 =?utf-8?B?aVBFZEhkbnVJbGVqYk04dFMreGFoVGxDOGF2bm4rbS84TUVLdFVUY3VKWjE3?=
 =?utf-8?B?bHc2c2J4VituSFJ1UHdwcHBiS09Wc1paVjRYRG5TY0FLRHhsdFFLRCtUQTJG?=
 =?utf-8?B?WEptOFZNNndDVFlJRTFLMSs5NkdmQ2xrZGl2dU5US01VYWxVTFpkQ2N5cTYv?=
 =?utf-8?B?QWFFQmM1cEVrTEQrVzkrMXRYSGZVZVhybjNKcFpPVTZiemlDWEV5blFGY3dL?=
 =?utf-8?B?SWM1SjVnN1cycGtLNXpzSXBIWWVZdnYwUDF5WXVrY2J5WVhUZmVlNjA3Ukxh?=
 =?utf-8?B?bExMdXZtY0Zld09Ba2ZWd29yMzBaUTl1M0lRRzdqRlU0MUJ5bk92VC9BK280?=
 =?utf-8?B?MEFVNW0xbEpxWUZxNEo2SHpzWTAyUEt0bFMrS3NGRitOQ2dqL1RPU3VlMHBX?=
 =?utf-8?B?NTkrS015SnlTMXBRaDQzUWhzTDlQeVkvWkZZT21FZ0lhK0dqOGNFRC9UK1lr?=
 =?utf-8?B?MmVRamU2MDFaUFg3MHlQSWV3elN5cmZ3VUh0OW9KdExBL0NYazFvMHpRU2hq?=
 =?utf-8?B?NDR0MEpVOEdZb2JJUGtWN1hwTTVtQTljazlMMk13NHpxbTZqR3UyQjc0Kzha?=
 =?utf-8?B?emhFUFdhSkFsOFIveUVtbjg3MjZXekxxa0FVcnlBN2N2ZFJKSU5Gd1o0QUZF?=
 =?utf-8?B?UWYrWGFJbVBIWGxaU0IzM096aWZRb2pqaXdzZjBWV1Ivc0JUN1A2K3F1bTI2?=
 =?utf-8?B?WDh3NzRmTVUvTmdzLzllY09ZWFBwTnVCV2NGZXNKRG1xZThTNUQvV3Rxekhj?=
 =?utf-8?B?WHhXanM3QVo4ZjlFN1BxMlVFTTdOR2Zuc0d5Tm1ic01WUGRhdkNNbUxwaW9K?=
 =?utf-8?B?bnowUDlMa0UxRWFyaFlZNTlKcHd4ZCtOWE1UbTRpVVZlbE9tT1pTaGs3YlAz?=
 =?utf-8?B?eFJ0aVJhcUF6RkZkeVlCYkRQZkdxWDZGL1NJb21YTGhHMjQvekc2T2xoVHpH?=
 =?utf-8?B?M2pVbFcwV3FzYmhlWlBEOStOMHRwaTZiYXB5dld2V3lPeWtZZjIyQnY4WXlG?=
 =?utf-8?B?N2Y1eUI2aFBpWmEvQkhnZWt6dExtc1Q5a0RXQmJYT1h2Y0FxSzBXclFHNnpP?=
 =?utf-8?B?Tmw2VHhJeWcvdVp3R1ZzVDJDWGFqODRBMGhjYXNtNmc2T3RsODdyTTArOExx?=
 =?utf-8?B?UDE0YjNwYzRpeUwyQzlXenpycDdwR3dtOERoT3pBMVpyRjl4SWFTdUIzRmlq?=
 =?utf-8?B?VmNyZ0sySWk0VkREdXhnMUlpVzBCeE1Ga0MzUW40TmNCZTZyaE9sTWlZNHZu?=
 =?utf-8?B?ZjZEWVQxeEllcWdPREZwUE94OENMeEtYMmpKV2hKbEQ3Yk16Tnh4L1g2K21X?=
 =?utf-8?B?YUgwSnNnajR6Q0lXcExleGJWcUV1VXBRckVZSmxURUxBODZVaUZXS1g3NnhM?=
 =?utf-8?B?b2RyK1lsTzFaSm1GY2JYRWMrcFQrVm1qaXJwNXlDOTRBemZZZXJtaGRIa1or?=
 =?utf-8?B?bU5uY0lRUXZlYlZVaFhvU3RWSzhsczdtYmdZaGI4RlZza2puSGh6d0lKZkRz?=
 =?utf-8?Q?vR8iKjlBuQU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NnlBeVdLb0NyMHMvZ2UxRC9RTUNlRmhLYWQyQ2cxam9rU1NxdGcxc0hPSmtD?=
 =?utf-8?B?MTZLTk8wWlk3TmtuOGhVSVhRT1VFeUo3a3hRSDVaZkVvSTljUDhuNTJaY2ZQ?=
 =?utf-8?B?NlQ0L1RRbXNWdTZNUGZqQkw4TkZQN1dPeFY3NmVnaldWU2h3SktBeEl6Wm01?=
 =?utf-8?B?NVVWais1VjlQT0hlejBzbXZNTGVoZ2ZPWFFoV2ZIcnJEYzhEZnFlUU9pMDBi?=
 =?utf-8?B?eXE3NUpPaXVITjFVbm5xVUFkK3hsanp5ZHlzV1Nzc3diMVVCbFY4UGc5bnB2?=
 =?utf-8?B?Y3RWSE5qeFRrVUd1aDU1cFZIbGFjT3c5VC9vcGRFRnhJK25oemZDZFUvRVFl?=
 =?utf-8?B?Tk5iR0EybGFJU2hJM1A4dEJ1VmswbFl3UTlSTi9BbEhMRXlrVFRIUmw1WEN6?=
 =?utf-8?B?YS9RWW9jaTlBRkRsQ0twRWppZDR3akRubm9iV0k1Q2dTUUh2RktuRnkrRVI3?=
 =?utf-8?B?RnloME5uMUhEaDViVGc2QzRLVkxORWFIMWloVTlRZjdZWjJLcU5jdHd1eTVo?=
 =?utf-8?B?Q1EvU2Fva2pWNmxjTGhUVEl4RzdkZ2hiNjAxMFZ1K1JPbGVYVUJrNVRXSWMx?=
 =?utf-8?B?MjAreFpjaEc3TjdHYkY2Mk13dXJUL294Vnk5WTZSZEFHVUM0aUY2MHhpbVVY?=
 =?utf-8?B?NSt3aUFNV1hld0dvM3FyazJtMGx2K2xjTWxHWkxFZUYzQSttRXJhcVJ1VWo5?=
 =?utf-8?B?VjlOU2hCMVkzSUxQZTViUU5ob0lvVFBvaWR5ZWRmWDc1V3MzWms3VDdWNjdC?=
 =?utf-8?B?aTdNUlNvVzVCQmxWc1NPM3pCREgzUVpFOXVjdGdiektuekNVTld0akxwWXU3?=
 =?utf-8?B?NTA5L1JJS0NUMEJxSjdqSHVjN29yL0MvNUNkNnU1NUNSbktMM2lZWFBvNnNu?=
 =?utf-8?B?SnN2ZGV6SWR5UlNBenQ0ajNEQWxkeHpaWTBtanpGSU01bDROekU0SlRNOEFI?=
 =?utf-8?B?b3pXYWNwT3hjZC9DbDNCLytNd21xN2w1UUUvMW9udk1maEFyNXQ5N2xlb1Iz?=
 =?utf-8?B?bEpma2txT2F5d0VyT0NTdDhXY0Zqc0RCR01wS04vOEtlc3NVa2RlTnQxa0V1?=
 =?utf-8?B?MEo0RG8xMW92WEM1Um85MUJ0WkhQeEFXbXptcEdEMnN0RmRSNE8yTlRXNFhT?=
 =?utf-8?B?YnZ5RDdIVXVNeUZqU2REZjBmbUlJUytPT1J6aEpWZndYWDZncTJUQzF1WU5O?=
 =?utf-8?B?NWxCa2FoWHZoenBNL1UvQXBDaWc3empBci9RazhyazczRkFrUTl0TkVlTFdS?=
 =?utf-8?B?aUd6Qjc2ZUNERnJqV2pMVmFTMHM2blJHRFR0aXhDcFd5U1FQbTM3VVZsYU5C?=
 =?utf-8?B?MFNpOHJrZ2V0T3ZNTWhIaUxucmdBRjIzOWJiZmEzWm81TlZGV3haTTY1aWp4?=
 =?utf-8?B?WDJRM3JEZStFdkxxcG9WODF5OFNuVDB1VEJkOGFhQU4wbktFWStON3lzYnkw?=
 =?utf-8?B?K2F5ZlViblFYMVNkVWNkcFBYODFVak5WNUo3REtqSDkwbXVPVG9qNGQzRmlP?=
 =?utf-8?B?anlRT3ZDUEV4OGk2SFVJU3BBRS9aUWJtaUw2N0NZenF3TnVDdzd6Njh2OXkx?=
 =?utf-8?B?YWVDNEJjQWc0NnMxZVQ2VCsyVXVQMGN1dXdUZVdrT2ZLQ1hybml4QlA2NUQz?=
 =?utf-8?B?R0R0Nk5zL2c4S3Jac0tuaEtRMndxbHFmcUNpcUxSUFNmMUFXOUdBQzJCZHFm?=
 =?utf-8?B?aWoxYkFHdFdzQVl6YkltSjBiL1VDNUxRTDFkc2M4UHBWZTkrN3Y5ZFc0R21o?=
 =?utf-8?B?RVE2TUxMMDFOZ1laZjg0UkE3VVNVN1BaVktOZTYraVZ2OFNXTWhreWhoQ1Fu?=
 =?utf-8?B?Tis2VlNybTBaQU1Ra0pERGV2OU1TdktaUzhmcEJDNm1HSW5aVXhWRzFhUjBM?=
 =?utf-8?B?S3JUKzdwTVgrdzZYbExCbHBmVnZ5Qm42MXNSNzhiZ3JSeHpkSWNMeGhnRFNm?=
 =?utf-8?B?WkJKdSszelQ1RzBTbzF0aFB0Zjc3Y004V29EYWFyVmJKc0dOak5zdU1GOHYv?=
 =?utf-8?B?Mzl5YkVqOElCcy90d3JmZEVEaGN6eEVrak1iblQyeXVFRE9BWkhqc0dic2I4?=
 =?utf-8?B?THgwYzRZajNqdVk0SFBhQlBRZ3VsWG5HeHBVVUl1eU50KzBhWkZKN2sxQzFB?=
 =?utf-8?B?c0YwUWZMZGt5L1Z4bG9OLzlycmhSaWEzYzBENTMzSXJMUFNiZDg4TkJXbjlM?=
 =?utf-8?B?SFE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e2ab933-af1b-495c-9337-08ddfb5310a1
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 10:13:53.9251
 (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: To+XYQiSxU0ylTNYfOKSmZrXr0x91JHddOTcnMs16fnBe04HPe13XftgPEKUnJHjNUHKNJD0i+o4EUyweq6NY4Nhie2S7yN4clLeJxBRzhI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10304



On 19.09.25 23:49, Jan Beulich wrote:
> On 19.09.2025 18:31, Grygorii Strashko wrote:
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -62,6 +62,17 @@ config ALTP2M
>>   
>>   	  If unsure, stay with defaults.
>>   
>> +config VIRIDIAN
>> +	bool "Hyper-V enlightenments for guests" if EXPERT
>> +	depends on AMD_SVM || INTEL_VMX
> 
> Looks like either there was a misunderstanding, or I wasn't clear enough.
> Here the dependency should strictly be HVM. If anything, the dependency
> above could appear for HVM (but as said, as of now it's deliberately not
> there).


Sorry, I misunderstood you. I'll drop above "depends on".


> 
>> @@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt(
>>       struct viridian_domain *vd = d->arch.hvm.viridian;
>>       struct hvm_viridian_domain_context ctxt;
>>   
>> +    if ( !is_viridian_domain(d) )
>> +        return 0;
>> +
>>       if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>>           return -EINVAL;
>>   
>> @@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt(
>>       struct vcpu *v;
>>       struct hvm_viridian_vcpu_context ctxt;
>>   
>> +    if ( !is_viridian_domain(d) )
>> +        return 0;
> 
> I don't think we should let these go through, but rather flag an error.
> And perhaps an intentionally exotic one (e.g. EILSEQ or something yet
> more "odd").

Most of existing load_x() returns -ENODEV (for example pit_load() for !has_vpit()).
Some -EOPNOTSUPP.

I'd be very much appreciated if you could explicitly specify err code to be used.
-EILSEQ? or -ENODEV? or ..


-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 10:14:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 10:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129242.1469283 (Exim 4.92)
	(envelope-from )
	id 1v1MW2-0006WG-RK; Wed, 24 Sep 2025 10:14:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129242.1469283; Wed, 24 Sep 2025 10:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1MW2-0006W7-Oa; Wed, 24 Sep 2025 10:14:26 +0000
Received: by outflank-mailman (input) for mailman id 1129242;
 Wed, 24 Sep 2025 10:14: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 1v1MW1-0006Vn-Cz
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 10:14:25 +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 3e066a39-992f-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 12:14:23 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9931.eurprd03.prod.outlook.com (2603:10a6:20b:643::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Wed, 24 Sep
 2025 10:14:20 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 10:14: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: 3e066a39-992f-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=krCuK+3v9RYXOsfcQ0DdZRaHdsK1q4uFb5hYTzQzKUwLob9/IEcAyzyNrEvw3MqLZ0EFUIH56OuR3KaekYkUjW+sNDMgRXGqk4ojbgzDUKh08OTZcIleSaP0+KLMtvGtIrVbxXz9ayUzbWNySle6efcifQmKzQxtINah+H7SUhVL4ctov3+pTgk+/E3VXu1de/5EZGehMk+RBli88kgRZ/JdJiiTHwy1S8Hb6Vp7GX0dW4ZgPAaIvsffK+O+16zuR93LjR1Wsl7WGbNxrIgnsIRrQCUkNtJdN3ugTYonP/yZmj0csvnlLqbjPatgbo6ZQ++M2zULPAqtUB3A4HCH5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LLmc699oXlLG5mSYjMYHmCNDmt537LCCPHJmUJDwiL8=;
 b=WL1Ldt6ym2doOHJiaAOTZXj+bIDK2RIRALpwF7jJ9lSX0izRMw4TSkkUjw4h7e7sIn5BFJ/3Xm9ZLqGxt4UnRSdaHlX+0eSrlxBTn5G2gRNvkXbvk26q5YS7rKkCjBjGfZv6lJJARjP7pSahazuH9IOWXDAwklNS87/dTqAUP1vbK94aSwvEluk4M7DfBiJs7dIvYPPei5abuQeR7wkisPTFgkshsulEGYmKj1q9vM6A/D+OoTuQgIKD57lfAJU3fmuFPT2Lu+5j7/LmRtQYdwQeNgKWz/eqpHZLnfmtEp5vxamlCiFR9O+R39l8BtOqo+cMNhI1A8jZO4ISjhQiTA==
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=LLmc699oXlLG5mSYjMYHmCNDmt537LCCPHJmUJDwiL8=;
 b=G9Ts0yIazJl5kKafTR0fL7R5D9q5YrFt5p9WEATtpzGFu++lR+UfYdFqEDMpvCCdZ2nqmqb388lF/KCpHpGjq9mpAv/bQffnKtVSV2tl/Ljlvzd5sLOdtbQpdPP6yEpmLQVqMXfr09DMb342BD/4NVfpncd6g89bZfZUK6Hp9jKxXaJaauqtfxUwjgT5eV207tET92tdOSbkpVHr2AJVgMOPyOHTDKh7CNdu7jfcnbaREHPKCqtf3ky9p/jxhiFG8UzrKm819anC0CJGhwjyaGTPrXn2jwiCLz/KkTW9aRxfYV8FBHqpL6FjmU4/nMeKtukkutHPJzHJHBRfIhNpRg==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alejandro Vallejo
	
Subject: [XEN][PATCH] x86/hvm: revise "cpu_has_vmx" usage for
 !CONFIG_INTEL_VMX case
Thread-Topic: [XEN][PATCH] x86/hvm: revise "cpu_has_vmx" usage for
 !CONFIG_INTEL_VMX case
Thread-Index: AQHcLTv95iVXlAGVVkGmfKuqtAYpwg==
Date: Wed, 24 Sep 2025 10:14:19 +0000
Message-ID: <20250924101417.229108-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS2PR03MB9931:EE_
x-ms-office365-filtering-correlation-id: ca0bd3e8-64aa-4e0e-b9f5-08ddfb532040
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ggUGvNQDxnPMCQm4fOf/ir1FIxeqma6QyOaJhXSq+DAET5MQdMSHYSNk/d?=
 =?iso-8859-1?Q?0T2a+KyHF8V13i783Nf2On2kttzA+QAcyuBR2BaJnSuLemegKdpOczDuaU?=
 =?iso-8859-1?Q?O2zVQueP9j1dVXb5A324NE3Rl1DdKbu7l6wY6DvJQlwAe2+3e6+Z5BKSDo?=
 =?iso-8859-1?Q?VoIhGJF4mPgkEFsn+P9dqFj8Ukm5HhRYaEf/MfsrrL1FiKApNsdhMaZvVh?=
 =?iso-8859-1?Q?cAwHOmeNtZ/n5XAGgMiNvDU97OjULA02hpeY08n+NPRR6SzmEQ8Pk/h9iW?=
 =?iso-8859-1?Q?azk3xuHEGb5mxGi0vSmx0v+mwJakpUYjpiv/Cukfdb9PavQmtcg+ldIbJi?=
 =?iso-8859-1?Q?9V5ha7XU1epx/V48FXqt5m8TC/Ka/TXNTgjASM+zLa7l/9T64hrmjb+qxb?=
 =?iso-8859-1?Q?Xi9KJ6FE7k+IDDzgE/6iZr5Mtonl3EFW48yNNIr+d9fZMyHgZVvDtYk1zU?=
 =?iso-8859-1?Q?eKD0UBi9sBHBsvX36CJe9iEV/rwYzAo/EgwT84rHYnI8Vzz5idDBurX8QE?=
 =?iso-8859-1?Q?nDAYCm50ylYwBr1knZazqYg8a29pLd0HgHUfbLZgmaqEvz4terKu1hjnS1?=
 =?iso-8859-1?Q?4LRaY5vpW3JBBOxp86y2gMNNUq1pHxfaewWt7FIrdEf+Ui+SnLWsn7uYpA?=
 =?iso-8859-1?Q?swM9u7iL9n2pyJ7xlyJ4zhfyS4q17evSv6tys/r/7MIyMhKrWi/ohGHtSl?=
 =?iso-8859-1?Q?C5NrYGFZJAUh0vKjbh6GAuNmixNTSTAbRSviffoMzZCjs1SKyrxfPe3pSn?=
 =?iso-8859-1?Q?8aH3Uiyn5D/F7oXDeYnaaFNrNbbfyOJ2Am92PqYCWNiqeTQIFHCDi7YwSW?=
 =?iso-8859-1?Q?GfaHsnbv12auGhDeLxJ28RR1B7dnZE1RKV0z6sU/v4qlxhfIDiI9QviesZ?=
 =?iso-8859-1?Q?VhmNVxZiboAh9GKQxhfhn1aFNo0yHxCpU0j2zrKBDIRKSykuQB+ftijNL7?=
 =?iso-8859-1?Q?FrZ1lXRC3QRFAs0AsrL4eCWtcdF0yZFisp7BxqeCgmTL8x7P7xh2VcOTwj?=
 =?iso-8859-1?Q?rXSKnR76FiyMVaIOixnQ6xCgcYfOYUjVywOtbRb2jUheXb8VqTSZs5L0jo?=
 =?iso-8859-1?Q?ixZy2CdtuuAZI6tH6AsNI4rNlVQoLvFamTxs66Wh35CxVsUoX/CDc8ShM2?=
 =?iso-8859-1?Q?4vFeWYHcGAwLLRFiMuhm40Zm8h/vFiBJeKUFFub1uXBvvjqzcIvD5LpOJa?=
 =?iso-8859-1?Q?a0ne9MOWjOBfJi79CcwcVn/oWmIC31hGFrGDc3Z9b5V8gTYCEc+MoVrmXF?=
 =?iso-8859-1?Q?eLZke9eBSY1QtNtQ05OnA0ZQvRobfejhUjdVZdrAG4jkgHN6DPhFCyhxnO?=
 =?iso-8859-1?Q?lhvqiPYb96jGM/4xiycWgrv8vgjDq3L8CkS2m6Wt7Q1ZQij710qpOqbGJv?=
 =?iso-8859-1?Q?cvTR2oYZ3jTPjU/Y3iDUAF4+UPIxeybsrL0eYMJ9FG6x9+oeIr0sEJt3bn?=
 =?iso-8859-1?Q?GLP+NQ57By4HC75ljyRvLrbBAjNJEyQhLWoGZHIVZDGK7zEMo9a0HD7BgU?=
 =?iso-8859-1?Q?trcHC+IoZkbdMuQzvgQaPq5M+Y6T5/yA7hA2ZuXkXduw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?VQc/memkJ6zhT64ptY/WueAORZ88YTW6jqPxfhhIAEYC6bjJSC1YxBNRIx?=
 =?iso-8859-1?Q?bHL25TzoAhaDzB1EocABU/cnEgm4XxooZey/B01jJ4BAoI+3Y3IMWaQjfc?=
 =?iso-8859-1?Q?h8MNANRY7ZZ3UwUi2qpdmfy5kx3xHKYxmRPDaXTzSqN7W7q7uWGruN/jV9?=
 =?iso-8859-1?Q?Dqcq5zVjylEjp2K2GYGiIPfgf7ce06XfCOPk2QwBF8R64NzNMbIzZtbzAy?=
 =?iso-8859-1?Q?sCrolt3a1XC9PoW7W/61TjlOONdj4mWnjOYsWl+pFAxmfeJGWymTIUZVpG?=
 =?iso-8859-1?Q?ypa/HQfKOBgOBMd7dQN7Fc9qfkjks+DBcxr3ZRs6SzdCthBUFS5VIlC4pE?=
 =?iso-8859-1?Q?FXXNwG7yt1RZzLOz40Io/BGsxbQtjMDarMKWRZB5j1o4LH5Bx9RC39yyZy?=
 =?iso-8859-1?Q?dzSdqP06Ez81Tc8Q3qMMEhJP0grJBIsUF6DEeNGIz8QtrCig7sHVQ7KNJ4?=
 =?iso-8859-1?Q?Bw1NzwIQhcr89l+xJnEj1aoLl8VUb/vU/DgqE0Ly1sZ/271nH8xyBd+Vnk?=
 =?iso-8859-1?Q?p5nD6VNu6BPth06jKAMNKx0fRnPsT17IKePQIO073Oe1KQbGH+l1BwKmBn?=
 =?iso-8859-1?Q?JuzOc1CPKkxuMLtP01s96RRl8XAaroBmaPJQml2bgda4r+PdgRO9yCnuuA?=
 =?iso-8859-1?Q?7nQTRsin9RRaodVgoOZadQuMOyRH1LXUvpwtALKJ5fsXav8ih28SOCAl1w?=
 =?iso-8859-1?Q?zdTvr4cglVi4RCmvL4RCGcbBkWKjur47XshBT0u0YqShp0d/J+7zR0Kcq0?=
 =?iso-8859-1?Q?7H0zZyZBFJmO8h/6pJkwGlE6sv9Px9M01odY7xU1XQzNL+xm7eNe2L9nbT?=
 =?iso-8859-1?Q?yHT/Qt1nd1tCffiGb+6Gu4e0bQMvMWp0KVmdPm4B4Ot4fT2m4StYoHuIkZ?=
 =?iso-8859-1?Q?uYLeZv79GtP0aTjvOf2LLYvgNJmOR5CbNIaENAvTIMbFOn6Fwc2gQdc6dt?=
 =?iso-8859-1?Q?qqhIaZvnd/6UtPxoxmp/sYsW7e+ns1bTXUbDZfalT0o1go0icQiu+F4Ucy?=
 =?iso-8859-1?Q?Kusm30p6ImLRRvea8Z4nygZxg5ogN1KwLxYBpPEI4j+Q//TyH8DjXy1UV9?=
 =?iso-8859-1?Q?zagMFE9ZkuFtNKfT70b7gQwuhGm4k+IAMQ8OhbQbBRvYznktkzP7fL4k2G?=
 =?iso-8859-1?Q?necE8lT10phftBTuGuDromPJEZPqCErb7jTXjQHULdGhEjU0H8GP7bTek0?=
 =?iso-8859-1?Q?IX0bj+4INjNFyyADEat7nbbEZVmXxOYfSse0bmvdHjFzCWHlD7LycTHN9x?=
 =?iso-8859-1?Q?uI0MCsHn8dkenodLKcGhL8pWULieydUuK+7zDCHjUcnOcPYr4MKK8Gk4e7?=
 =?iso-8859-1?Q?vITYGQPMOy/2/5cQyqqnRCcIlhZHJVgIjUUTmbYAHCvTdRrfyTghilAhDt?=
 =?iso-8859-1?Q?YA/o9Do788Mv+IxZBTd3aol33nhDc+EGPtcyH47JUDWWD8Y8CivgVs+LsV?=
 =?iso-8859-1?Q?TR95XVBtshbqNZNCCm1KKPxw5IBd1Syd2b4QWLAIbD1IipYmnpWulVQuLy?=
 =?iso-8859-1?Q?Bi3nV8X+BnMx8Y5pGIRdK9I0bOKe1aGy9lccSCa6PqD+E1+DFmypA0edle?=
 =?iso-8859-1?Q?ovjqvLGyqQwCdwfyPUQC69hIzEIKQr4IQCpQTI9Mrwg6mZfbqlJhoNCLnO?=
 =?iso-8859-1?Q?CwBwIfXvPogbEfqwxvcw6ksZQ7+ne0XaR3+iUUUVV4IbD4BvjXxPAuPQ?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ca0bd3e8-64aa-4e0e-b9f5-08ddfb532040
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 10:14:19.8348
 (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: 15w5fESrl5SDYmtDoeYRZp0evUtuEaPBHeDfQ01FXmXuBVTsYSETvpwdXYepbc4hugvJkph5y1f0UWOD5mCA9b1zYxT3lhrGz2rLKvFgw8o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9931

From: Grygorii Strashko 

Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
HVM Intel VT-x support can be disabled, but it still keeps VMX
code partially built-in. Particularly in HVM code there are two places:

1) hvm/dom0_build.c
 dom0_construct_pvh()->pvh_populate_p2m()
    ...
    if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
    {
        ...
        [unreachable for !cpu_has_vmx case]
        rc =3D pvh_setup_vmx_realmode_helpers(d);

pvh_setup_vmx_realmode_helpers() allocates memory and configures
 HVM_PARAM_VM86_TSS_SIZED
 HVM_PARAM_IDENT_PT

2) hvm/hvm.c
 hvm_set_param()
    ...
    case HVM_PARAM_IDENT_PT:

        if ( !paging_mode_hap(d) || !cpu_has_vmx )
        {
            d->arch.hvm.params[index] =3D value;
            break;
        }
        [unreachable for !cpu_has_vmx case]
        ...

Hence HVM_PARAM_IDENT_PT/HVM_PARAM_VM86_TSS_SIZED are used only by VMX code
above code become unreachable in !cpu_has_vmx case and can be optimazed
when !CONFIG_INTEL_VMX.

Replace "cpu_has_vmx" with using_vmx() to account !CONFIG_INTEL_VMX and all=
ow
compiler DCE to optimize code.

Signed-off-by: Grygorii Strashko 
---
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-604 (-604)
Function                                     old     new   delta
hvm_set_param                               1602    1473    -129
dom0_construct_pvh                          4438    3963    -475
Total: Before=3D3567191, After=3D3566587, chg -0.02%

 xen/arch/x86/hvm/dom0_build.c | 2 +-
 xen/arch/x86/hvm/hvm.c        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 5551f9044836..5ac2cf8394d8 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -473,7 +473,7 @@ static int __init pvh_populate_p2m(struct domain *d)
         }
     }
=20
-    if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
+    if ( using_vmx() && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
     {
         /*
          * Since Dom0 cannot be migrated, we will only setup the
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 95a80369b9b8..70331aeec9a0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4302,7 +4302,7 @@ static int hvm_set_param(struct domain *d, uint32_t i=
ndex, uint64_t value)
          * Only actually required for VT-x lacking unrestricted_guest
          * capabilities.  Short circuit the pause if possible.
          */
-        if ( !paging_mode_hap(d) || !cpu_has_vmx )
+        if ( !paging_mode_hap(d) || !using_vmx() )
         {
             d->arch.hvm.params[index] =3D value;
             break;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 10:17:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 10:17:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129265.1469293 (Exim 4.92)
	(envelope-from )
	id 1v1MYt-0007OG-Dl; Wed, 24 Sep 2025 10:17:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129265.1469293; Wed, 24 Sep 2025 10:17: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 1v1MYt-0007O9-A5; Wed, 24 Sep 2025 10:17:23 +0000
Received: by outflank-mailman (input) for mailman id 1129265;
 Wed, 24 Sep 2025 10:17: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 1v1MYr-0007O3-NB
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 10:17:21 +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 a797ec9d-992f-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 12:17:20 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by FRWPR03MB11125.eurprd03.prod.outlook.com (2603:10a6:d10:1a4::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 10:17:17 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 10: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: a797ec9d-992f-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yuZy2FejwKYYkFobmrhLti8dx4dRKfxJI4mBQRXi0VxnnLY6VuxsrGwcCvCYImNjcAZ/hkelz4rzqEWl9gLNoKM8xKYIHzNZRWyrYQP1HKI44qmJxapmRfMd7Hu7WiibR6R12613elnNZ1dkYmV1i6fu9SFnhjRHMRHEi6wbexhDGKy+8e20uCI5YbvK/SxHETjQ2fZkXlPTKQPeQocc9BRyD4PCAkAEC2AvzI4QQ3zCb5qw98N5MC0nlCfllz5XJ//kPX5ihLibIbET6CEFtY6A+n1danOC0CxOSc9r+yUFbIriy25t6YkPEUEpB4vMiUQMvNq1rrfrpuu/QsAGrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7yUNZknybc/BOz4wBSL9nDmCm9z+DxWnWzRIYOEnah0=;
 b=EtLiiR1r4MPb7lqIJt0rShSPvLvlcd7ShoxcDcn7UhXFMxvTe1VOfH/0T6BhZaaSx3hKnGWFd4z6ceeskKhBb9kLWqXrUU03g6mtBS+h8tUFaYL+gKxftC1ibDjZZOzCB9MZELLBXZ4eLeNeOI8ExMVmpBHubkGsJISPu5HpR2yrzT+NiuZF7yRgiMttw3fDkheRr3nUK0KG4Pm8TDfzxJZlC09Cyk0vk3InQMqwW6MK8kD7w6ywumeCva+t1W6VaDRUXPe1hszHWaWH2ggiBOZ5sRGcrO4B3LA0I/0iqHHnTKXRxnOW5Q66zMmmXhNvjJ6uYLyw0cNHuyh1I5FI+A==
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=7yUNZknybc/BOz4wBSL9nDmCm9z+DxWnWzRIYOEnah0=;
 b=TaruePPWzsxsZwW8URLsTJ7XG8nYeGpRgf+tf5bGSmfj+8zvOt8s2ZgKRJcrOmCD4nHwHY5Cr4W0EuaITicaPD3PDKNTcB4nVnkoS8CvxcC2/fCADMaDTlH85RtxsGNDtSgmZhMVAWY52fhQB3+QIEZNiQ9d1fq3Vi0w7Iu4qqfHaLLb4IRHgw7yaOn42VgSjR/I1KQit8niRgxQuM8j7p7i7RKUzkKA2fCrX4Ykm+OY+z7RGlhMWTpLFIYCUDVzP4a5HTrxmWNzm3pGeG8KUj/ALjYWVTYhjX6nG3HGYGlQINvim42OypjZfZRlcVCXos+YbvUOXNwhZedwlCp7Yw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <8f6b8f08-ca62-467b-a6be-4d33208e5393@epam.com>
Date: Wed, 24 Sep 2025 13:17:15 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 
Cc: xen-devel ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Boris Ostrovsky 
References:  
 <05e9628d-83e5-4feb-881d-5854b72bd560@suse.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: FR4P281CA0237.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e9::12) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|FRWPR03MB11125:EE_
X-MS-Office365-Filtering-Correlation-Id: cfd9f5f1-7a3d-4de7-9b0a-08ddfb5389dd
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?eWZFN253eERUSmpOcktNejhXVDJMZldKK05pSEhZTnhmUkQ3aDlXQkJ5TG9s?=
 =?utf-8?B?cWNSZ2l5RUU5UHh6RE5rZkgvMWRITGFpV0R5NzBTWXVYUERYbDhzZVE0cEF6?=
 =?utf-8?B?QVcvblZkMCtlNUFPOUlzdG0rTkZxQUdZZnBHNFd0bEJ1THRUY3ZYdDVWTlp0?=
 =?utf-8?B?UlJTcGtKdUZWazA3TGdwcklVT0dOWEpqdjloYzdUSWtjZVFXMHUrbVl2aFpw?=
 =?utf-8?B?ZFJXaDU0b3dDOWZLSUZNbGhhL29oN1gxZGVlaXhOOTNWTUF4dlZvUmwzc1ph?=
 =?utf-8?B?OWxLWE1lLzlNeDJuMEVQbGtSWWlSRk9Ca2llWDlxYUFjUFp5NU0vZU8ybHgy?=
 =?utf-8?B?bEVCYmMwTTN4dUtaSXBKSTRDRElydXVwTzRpMG1aU295QlBDWTN4V1Y0Ri94?=
 =?utf-8?B?NktqblhTQThNTUh3RU5xUUFmRjh0N1lqeFIyenl1VmhqSnB4LzJMajluZE4x?=
 =?utf-8?B?U2xUVDlJbW1rQkpiUXBpVkJXajNodmZIdU5hcVRIVm95ZFU3aGZGcVMvSGxz?=
 =?utf-8?B?eERWRXpBaitSVkRXZDlPb2FBMmhoTC9ZVzJ2SURnMmdFNWdMNGhFWWwxbnRH?=
 =?utf-8?B?b3luMXc5NWlKTVF0Ump2cDFLcjZjcVNZQzQ0Ri9mbVFjTUNJTDZkdGwrUnBB?=
 =?utf-8?B?Um9qOU1kblgzSXNsZ1VpVUhoWTR5K3ZlZjVNUkt4MStJYTkvQmh2V3JzWGFW?=
 =?utf-8?B?ME0wOHk1bStTTkJlWGZxcWpabGZBQ1Q1alFCZVpSNmd4VnVtUERDMGd5V0hr?=
 =?utf-8?B?Y003Znp2Zk9vWm11UUVKVDRJbFVtWWpvSkJvWHJUWENIZmdkekFHOW5jU2N5?=
 =?utf-8?B?dDh6ZnZ1QzJFS01tdlV0L3dCMGVQTTY5cURMVUpoSk55TC9jVWx1ZEZGdUxG?=
 =?utf-8?B?MjZxK2NsaGZGTkdTL1VWeXFteXVvS2tzNFhjT3M0Kyt0WlAxWlFmbU8vdzhC?=
 =?utf-8?B?VnlQbVEzdXhMa21JckNTWHU0V1F1eVJJZC9DZURsL3gxd1VoR1JlcFEvZ0lo?=
 =?utf-8?B?eTZVWjYySkNUWVVDNTl4dkdQK2FMUVRCNGdKalk0U2NmVS9aVjltNkJVY2N4?=
 =?utf-8?B?RHFMMGZLZ1JlSFV6Ym16clAvdW1RSmtFZGpiZjg3anRYSXNBd1VIQUFtL2ZS?=
 =?utf-8?B?MFdNelN4b29DRjBDZFp3bE1yTUtWd1FHRGJQTXVqN0dOMCtvNE02c0ZIRHlk?=
 =?utf-8?B?eGhUZE52ZkpPSFZJMTN3RmNSQytpRW5QczVZcDNhTHdZL00yd1ZNR21DMkNN?=
 =?utf-8?B?bk9VZkFwdmlWUjdTSnRTTC9ZR2VuaDkxc0dWMC9SQlRMOGE2TitGYnI3RVhv?=
 =?utf-8?B?c3N2Yk9tVWZ3dW9tL3hHMnBCWGtKUmVHWEc5ZDNQNWl1YXJFUVhkOUMxZEV3?=
 =?utf-8?B?anNKbmVWSjNhL1hYaXdlNDVkSVQ4RlFBcXMxdFNYUmFOaEVzSXozMFphcmZL?=
 =?utf-8?B?WU82b3I0MW5EaWplb3FEeTVUd0dZeklSRnA0WlM0aE5kZ21xZ09CY0xJcXJs?=
 =?utf-8?B?OHptUHd3YWdzNFNpanFuVFNBN29vWVZ5OXFJWkFwekZYVWMzV0h4UzV4enBq?=
 =?utf-8?B?TmdvVW45ZE1CbzJiRDQxcEdLVDRxYlNqUUN1NENoMkFpeGVmY3E2T2tsN1lz?=
 =?utf-8?B?dkFYbm53OWNsc0xxQnFVSGttdTY3dmJqemNFMkprQ0VPek5mbVFXZ2NlUEc5?=
 =?utf-8?B?RndXY0ZpbnhNRXhPR3BYOXpTNlU1S3ZkeXB0RndyZDZqOFpvQXRha2huS0Y5?=
 =?utf-8?B?SWxkVCtMVVhTWEZ2S1laSmU5dUpFQ0FtbTdKVVd3Ymd3NjZxMnU1RzhMRlB1?=
 =?utf-8?B?YldhYlhRRWRCVUZsWHJ1UTBoTVBMOUFwbkY3T3lNUUNGYy9WUm5vZUkvNkg0?=
 =?utf-8?B?ZU52WXNodW1uS1FySkhlV1lHcVBGUUQ5NTZTMnY0by9OQk14K2V5blRTKzNl?=
 =?utf-8?Q?+suTgYPVPn8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?eHFWZzBDSGUwa1JYV256TXNJL3pLeXRFZnNzaEYvT1VacWxFVEE4MUlTcW04?=
 =?utf-8?B?eTdpN1BiTjljZEF5SUFOdmJzdmh3cW0zcE4rS3RkaEJpUmhZbm14eXpiMkRt?=
 =?utf-8?B?MGt4TytxbFFqYVRYLzVwY09obERQQ1FwUnVWMUx0RFRLSWxGMjI4MlowSWpK?=
 =?utf-8?B?ZENBSFBBaVB1citBd2xOc1BSUzNJVFVPWkRGeXFqdGVqU0NnMUhQOVI0VzJD?=
 =?utf-8?B?VE13aE5vaHdBUWNzeUorRlVYNGxOVyt2ck5GMHozUjZDSy9wM3l5MzJVbyt6?=
 =?utf-8?B?eUlRd2t5c1VPSTdxMlkrSjZVUTRlWGMySW1OaW5ScDU4QkRGUHkrNlE5VlNU?=
 =?utf-8?B?TDhFS1JpaGdYaktuU3dQR1dpZTZieTFyT2Y1TW1kZit4VjVEeE9UbkJVWWs5?=
 =?utf-8?B?US9IVWtML0JzekYvVkhpRFkwQ01HWVN4TVR2bTN4QTBtUmZoTjFPTElLOUc2?=
 =?utf-8?B?SlJvUkRCMm8vQm13c0E3aEp2bjUvQ2F0OFA0WEpJLzl1dUJzOXNhUHY3NWU1?=
 =?utf-8?B?UUhXdVZJL2VQempKRUh1eXNNMDVaamMrdk9GRkRDSGVqRDhXMytFZTRRa2lD?=
 =?utf-8?B?MzRvVXVPUUdOQ3VzME5WRkNuY21qbktyZTlia0tDUTNnVWt4Q21RVUZlWm1C?=
 =?utf-8?B?QWpHcC9iMTNJVTFaWEluTGg4cGtyR0xHditRQVg1d1JDSmJCQU40elZoZnZH?=
 =?utf-8?B?cXQxQzViNG5IdC9xNXhBLzdqMjBGY3VadXg5WlB4VXhnUnhpVUE1MUFpWDZG?=
 =?utf-8?B?OEFPRHppcDlmWXJNWjVUakRwM1AwU2hkM0JLK2IvRXRwRGhpckc4UnkraWMv?=
 =?utf-8?B?ekZFdUNoQVM5TStmUDF0cExxcjZ5Q0NmUDVOZU1TQlhaV0RqQnlvdGhEcE13?=
 =?utf-8?B?QWo2SFdlQ05oVzBoS2ZjcGVpQzhuY25VTDZ1K1NMbldtR3ZaK09obCsyL2x3?=
 =?utf-8?B?SGc4RFBtSFhzT2c4YUVsMElPKzFqRWRHbnZuMkg1U05jMFloQlBjd1grQ05S?=
 =?utf-8?B?ekQrR1NNKzF1b2tYbnJoZDBRWUk3aW52VExodHF2YmFOSi9EVk5zZGpBUEYv?=
 =?utf-8?B?QUpicktYdEdGQWhJUGNYSmw1Y3ZpWXNEbnp6ckd3cWhRWGZ0aXB0N2cwUHlU?=
 =?utf-8?B?VTJnVjA5YjJVWUZROG12SW5takVqM0szZ1JaRTJOOW56aVVQY09Sc1NaMWdJ?=
 =?utf-8?B?VGVKZEVXQWdaVEdpZTR4OTNxV1pRRk1IZE9EWjBHampFazNORk5hNjdTSEhT?=
 =?utf-8?B?N1lYOFRYNUtwT0ZyTkxxVFhQaEI4MkszQmZ1a2JlTlYrZXJlKzF3eHAxKy96?=
 =?utf-8?B?ck1xZW94K3VTTS9mR05nMjkrWk5ubnFwMEl1ZSsvaC9oSkZQVmdiQ244YzE0?=
 =?utf-8?B?UGE2OTVFbk50TlhJMDI4UVhMaldHT3VrU28wVHZIYkorOHpZZFpYTVRETFI4?=
 =?utf-8?B?MmpyL2NnMmh3a2YwUytVNFNmeHFXNTZLUmpCbDZKenJqUHJSSEpSZzlONFFQ?=
 =?utf-8?B?dDNRU3VndXQvb2hoK2tDRFpDRXM3bnlnZlZJTlFTUTVwTUNOVkJ2TTRGeDM5?=
 =?utf-8?B?MXhpd2JSbHY4V0FzWDdxbnY0cnNGYTY4a2N5aHJIUmZzS2E2STdpUmFmVjVp?=
 =?utf-8?B?ekdPbXVWMkN5WjF0RUhvSzVudWVQMVYvVEFiUE54Z2ZKOUVzdmNHMEdnMml3?=
 =?utf-8?B?VlRMQ2ptUHFncHgzWmpERGxMNi81MGIzRUlnd01oaEh0YUxJY1J0T0pXYUZB?=
 =?utf-8?B?bXNLZXlzT04ybksxd00zcThOeTdVN2ZlTWJLSFNBT1ROL1pVRnFoeHRTN25s?=
 =?utf-8?B?R1VJcDk3YTl4RTZYQmRhdnpYM0JmZndncVdJWVYyZWJxNnRWTTc4cUF6MmMz?=
 =?utf-8?B?N1RDMUZzNW91R012ZXNKVDdXNi84TkFsdHFDRk81SVI3Nk9nQW1XVGZsL2pP?=
 =?utf-8?B?bTE0MzlWZHhTL29CT0JhSGp1Y3AvKzl3SmFCVDdXNUxaMW82L1hTQ3FsREpn?=
 =?utf-8?B?UzBiRVZZWnJuc1M0Ymg1TzhLVTFvem1FKzZDT1VFVkM2aEtDZjZjTlhHcW1H?=
 =?utf-8?B?eFZhVTRqOFNHQUJleHpRT2JUTjFxaVZjN1c1VzFHS3lrN0VXenNQVC9HUDhN?=
 =?utf-8?B?Nlc1ZlQzUXdrSVgwQ1FPT2s0YUN1YzEyOUJlYm85ZlVrS0g2L0VGN0Z4dzFQ?=
 =?utf-8?B?N3c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cfd9f5f1-7a3d-4de7-9b0a-08ddfb5389dd
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 10:17:17.3485
 (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: y2clFY4uTsbvWumjHEUBxjIGDVdeD0t/2JHbIOc1ZzPlophC4vIuABCO1ENaP0VmffGbnbvdYvXPewazTBlS7ZPk+vmcg46bA1/SMEWTpLI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRWPR03MB11125



On 22.09.25 13:09, Marek Marczykowski-Górecki wrote:
> On Fri, Aug 22, 2025 at 08:42:30PM +0200, Marek Marczykowski-Górecki wrote:
>> On Fri, Aug 22, 2025 at 05:27:20PM +0200, Jürgen Groß wrote:
>>> On 22.08.25 16:42, Marek Marczykowski-Górecki wrote:
>>>> On Fri, Aug 22, 2025 at 04:39:33PM +0200, Marek Marczykowski-Górecki wrote:
>>>>> Hi,
>>>>>
>>>>> When suspending domU I get the following issue:
>>>>>
>>>>>       Freezing user space processes
>>>>>       Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
>>>>>       task:xl              state:D stack:0     pid:466   tgid:466   ppid:1      task_flags:0x400040 flags:0x00004006
>>>>>       Call Trace:
>>>>>        
>>>>>        __schedule+0x2f3/0x780
>>>>>        schedule+0x27/0x80
>>>>>        schedule_preempt_disabled+0x15/0x30
>>>>>        __mutex_lock.constprop.0+0x49f/0x880
>>>>>        unregister_xenbus_watch+0x216/0x230
>>>>>        xenbus_write_watch+0xb9/0x220
>>>>>        xenbus_file_write+0x131/0x1b0
>>>>>        vfs_writev+0x26c/0x3d0
>>>>>        ? do_writev+0xeb/0x110
>>>>>        do_writev+0xeb/0x110
>>>>>        do_syscall_64+0x84/0x2c0
>>>>>        ? do_syscall_64+0x200/0x2c0
>>>>>        ? generic_handle_irq+0x3f/0x60
>>>>>        ? syscall_exit_work+0x108/0x140
>>>>>        ? do_syscall_64+0x200/0x2c0
>>>>>        ? __irq_exit_rcu+0x4c/0xe0
>>>>>        entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>>>       RIP: 0033:0x79b618138642
>>>>>       RSP: 002b:00007fff9a192fc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>>>>>       RAX: ffffffffffffffda RBX: 00000000024fd490 RCX: 000079b618138642
>>>>>       RDX: 0000000000000003 RSI: 00007fff9a193120 RDI: 0000000000000014
>>>>>       RBP: 00007fff9a193000 R08: 0000000000000000 R09: 0000000000000000
>>>>>       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
>>>>>       R13: 00007fff9a193120 R14: 0000000000000003 R15: 0000000000000000
>>>>>        
>>>>>       OOM killer enabled.
>>>>>       Restarting tasks: Starting
>>>>>       Restarting tasks: Done
>>>>>       xen:manage: do_suspend: freeze processes failed -16
>>>>>
>>>>> The process in question is `xl devd` daemon. It's a domU serving a
>>>>> xenvif backend.
>>>>>
>>>>> I noticed it on 6.16.1, but looking at earlier test logs I see it with
>>>>> 6.16-rc6 already (but interestingly, not 6.16-rc2 yet? feels weird given
>>>>> seemingly no relevant changes between rc2 and rc6).
>>>>
>>>> I forgot to include link for (a little) more details:
>>>> https://github.com/QubesOS/qubes-linux-kernel/pull/1157
>>>>
>>>> Especially, there is another call trace with panic_on_warn enabled -
>>>> slightly different, but looks related.
>>>>
>>>
>>> I'm pretty sure the PV variant for suspending is just wrong: it is calling
>>> dpm_suspend_start() from do_suspend() without taking the required
>>> system_transition_mutex, resulting in the WARN() in pm_restrict_gfp_mask().
>>>
>>> It might be as easy as just adding the mutex() call to do_suspend(), but I'm
>>> really not sure that will be a proper fix.
>>
>> Hm, this might explain the second call trace, but not the freeze failure
>> quoted here above, I think?
> 
> While the patch I sent appears to fix this particular issue, it made me
> wonder: is there any fundamental reason why do_suspend() is not using
> pm_suspend() and register Xen-specific actions via platform_suspend_ops
> (and maybe syscore_ops)? From a brief look at the code, it should
> theoretically be possible, and should avoid issues like this.
> 
> I tried to do a quick&dirty attempt at that[1], and it failed (panic). I
> surely made several mistakes there (and also left a ton of todo
> comments). But before spending any more time at that, I'd like to ask
> if this is a viable option at all.

I think it might, but be careful with this, because there are two "System Low power" paths in Linux
1) Suspend2RAM and Co
2) Hybernation

While "Suspend2RAM and Co" path is relatively straight forward and expected to be always
started through pm_suspend(). In general, it's expected to happen
  - from sysfs (User space)
  - from autosuspend (wakelocks).

the "hibernation" path is more complicated:(
- Genuine Linux hybernation hibernate()/hibernate_quiet_exec()

I'm not sure what path Xen originally implemented :( It seems like "suspend2RAM",
but, at the same time "hybernation" specific staff is used, like PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE.
As result, Linux suspend/hybernation code moves forward while Xen stays behind and unsync.

So it sounds reasonable to avoid custom implementation, but may be not easy :(

Suspending Xen features can be split between suspend stages, but
not sure if platform_suspend_ops can be used.

Generic suspend stages list
- freeze
- prepare
- suspend
- suspend_late
- suspend_noirq (SPIs disabled, except wakeups)
   [most of Xen specific staff has to be suspended at this point]
- disable_secondary_cpus
- arch disable IRQ (from this point no IRQs allowed, no timers, no scheduling)
- syscore_suspend
   [rest here]
- platform->enter() (suspended)

You can't just overwrite platform_suspend_ops, because ARM64 is expected to enter
suspend through PSCI FW interface:
drivers/firmware/psci/psci.c
  static const struct platform_suspend_ops psci_suspend_ops = {

As an option, some Xen components could be converted to use syscore_ops (but not xenstore),
and some might need to use DD(dev_pm_ops).

> 
> [1] https://github.com/marmarek/linux/commit/47cfdb991c85566c9c333570511e67bf477a5da6

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 11:01:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 11:01:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129283.1469302 (Exim 4.92)
	(envelope-from )
	id 1v1NFB-000566-HW; Wed, 24 Sep 2025 11:01:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129283.1469302; Wed, 24 Sep 2025 11:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1NFB-00055z-Ev; Wed, 24 Sep 2025 11:01:05 +0000
Received: by outflank-mailman (input) for mailman id 1129283;
 Wed, 24 Sep 2025 11: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 1v1NF9-00055t-FS
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 11:01:03 +0000
Received: from CY7PR03CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c112::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1aded1a-9935-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 13:01:01 +0200 (CEST)
Received: from CH2PR03MB5223.namprd03.prod.outlook.com (2603:10b6:610:9c::21)
 by DM8PR03MB6231.namprd03.prod.outlook.com (2603:10b6:8:32::24) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 11:00:58 +0000
Received: from CH2PR03MB5223.namprd03.prod.outlook.com
 ([fe80::64db:a9da:5b27:8665]) by CH2PR03MB5223.namprd03.prod.outlook.com
 ([fe80::64db:a9da:5b27:8665%4]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 11: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: c1aded1a-9935-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O1bt6fDV12qlGhftPfp74ZjENhnLbRO2GgOzDND3c6ZiLfvSKjT0Bgp/hFsv7tvKHM8nRG8HbyfiXPqWU6c0ivFWetuM2Aa/vLV5V/9TQ6p23/Mp2q3LzSroHOKI05Q1dcmUaFZBLVm5Iu+rs0+5PC7XoLoHxdhdJ8KjWECpSG9lohNPIbIyOMUgg7LM6nu/JWwtoSX/e4QbKJB277sOYIHIerf688GBqWQ0of8sOX2CMGl0KwOPGtHNUk5RR9o7HCumPjgTBHuKS9L82Uksyer1iZ0KnPuj5nLgHH+fWr4ERe1+e861xFhHsaVZzMfomig85z9sXyz1JsAuYT3eTw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+bJS5bgeabBkmkOmKmzz/bgIFX1Wj9kkd8dwy01iarU=;
 b=SxEYAduI49iv0IrlA3Wgp8O0EV/vds8TIsXg7aNOffdX8BtbEqFHdTAaaAt7pZ/7MjYIAcUOD7Xwh/xCsHVo0JnrGNjHmwOQcMtP9WWY8mWEzMdj49VnAU8MGcEo/+sSoS26WZIco51ItrX8fYGY4S6poC/3M53ACHJYQwMB+zz3c9OvJIYu/mWxPtLgoHP/Py5cCoYX7rodi7ITmrjBYkGNnXwogp2n0jTo/UX7LPpDy0OL7WiU/Mo/H4UQXmxhZgNMVA0Q13yrHnBGmd0+d+o+/xkG4zF/jmobwGmo6Pghx65ezk+XQA6mMW5//3eETzAswn7CBlI0vuz4Eb0EIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+bJS5bgeabBkmkOmKmzz/bgIFX1Wj9kkd8dwy01iarU=;
 b=ClGNfZKxVnYniSz+Xk1PtKvJKipePSosW+MBYyo1tv91E8cb9UBRHf4KLQhe3orj2FVKU+q6sAC13FyK7CY6VtrsZi/42bD8eCiIccyNlELxm4F1Ty57TtRyDaE86wU/BgaRoFbR+LTg4Mg17LRTem/mZ+88UshpILT0Elb9+Zk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: oleksii.kurochko@gmail.com,
	Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early for self-snoop detection
Date: Wed, 24 Sep 2025 13:00:51 +0200
Message-ID: <20250924110051.2160-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.51.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: MA2P292CA0027.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::16)
 To CH2PR03MB5223.namprd03.prod.outlook.com (2603:10b6:610:9c::21)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PR03MB5223:EE_|DM8PR03MB6231:EE_
X-MS-Office365-Filtering-Correlation-Id: 47df74dd-9450-46e5-e5fb-08ddfb59a3d8
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?SGo0eWNlcW1LQkpncWVQajZzL0lNWk1nNjZmM24wRkJ3M3hyOHd6cjNZTWsw?=
 =?utf-8?B?NW9ndmRMWjFKL09TMFhRTEFHT2U4U0l3OGlvUERVL0VidVcyYk9SS2I4SDcy?=
 =?utf-8?B?RW8rbnY3Wi9uVFVXeGVsL0NxUFRVcmVKWlMrWGRLRE9OZXFmZ3ljcWJLKzJW?=
 =?utf-8?B?bERNU3BZQUkrSFg1aXg4T0hDMG8zQjBKQ2JVSWxWSkhKZEgzQTAwV1RoWTU5?=
 =?utf-8?B?bGVsaFJLSHFTdk5IQStXN2wxZTVZMkRabWJLbklkd2lNWUk0ajNLYmpaaE9V?=
 =?utf-8?B?Nlk2R0VJRmE2djU0emFmRm9zd3VTSDFEeE1EOWtCUkF1UzlSQ0Rrc3BYb2hl?=
 =?utf-8?B?VURPMEsxa2ZqZEtDeVFudmFDNE9icFY5M3FNd1dYcyttZTBSRzVCT0hkSXNP?=
 =?utf-8?B?M1dRS2cxR00zQnl6SW15R3FnL25UT2t4bU9jdGF5SEJIS1JhSWU1OUNsdWd2?=
 =?utf-8?B?RU9IaUJ1TWVIcUpGZ0N2K0VQb0Q1Z2pFSUQ1aDZkNUZhdkdGWWNKQjNBZ1VT?=
 =?utf-8?B?VTZqWlNoRmN1aHFQQzE5ODZQUkRabmxFTG51cTZvNHpsTjhNTlpUalRrVHRI?=
 =?utf-8?B?ekpRVE5pajZ4ZXEweHZTQzdqcnZZL2h1M1dpTXBRSEpFT1BDNVI4Y3VkSUVG?=
 =?utf-8?B?KzFpQlVoM3pCSFAzakxMM3ZRdGxReUZJNlBPQWNrUmRjVHkxTjBSQ0pxenh5?=
 =?utf-8?B?bHlWbzlTK2NQZ3ZpRTEvcG0vWjVHOVUvWkx3aW1CZEtzcjNKVGJVYVYrTVo5?=
 =?utf-8?B?c1pGNVVBdnlXTFc0NmFDcHBFclc4T01MLzVYUmRZNnRTWC9wMGZhbzlIZHd2?=
 =?utf-8?B?TGhNTkZSYjgva0o1UXlERmdJYXBVSUhhWS9PT2JOZ0JEamxBUUZMcU9yTWx5?=
 =?utf-8?B?TldGNHd1YThXRS9mSXYyRjJtVHFZY1dRNS8vUk9CQnlTU081SVBNSUhrU0Yv?=
 =?utf-8?B?R1RVN2FzVXJyaGFqaVhyZGZ1dkl5UHFKMzRDK015cDRZOEZkS2hqQjFjbmNZ?=
 =?utf-8?B?aDdmUWlWN1NXaElZWUozV043MTN3RVQ0Z0RPcmlpUVJyS0ZROVdKVVFIOWtl?=
 =?utf-8?B?L1VvdWN4bTBjdTl2QnFHWTh3MXp4Q290MGphVDhpakp1REw3OU9zSmR2eEZF?=
 =?utf-8?B?T3UvMUpFRk16SkxsWDMyb1Y3RkVIdUFwM1RVaXREenh5UFRQV09pbzArU3hN?=
 =?utf-8?B?c3VkVW1ROGhTLysxempBRzBrem9WTnBDUFZzSnJkQmpvbjdrL2p0cmFid2pq?=
 =?utf-8?B?ZkNlMElaZlNWZWhZT1RtOWpvamlyZUFzbGtCdlRNdEVyOEVmN0VhdlVNSTlr?=
 =?utf-8?B?RkhaVkxyUllYTVR6VnFoelZ2U2UxendUOEJQeHRiMklmalB4a2tUdmxqc0lp?=
 =?utf-8?B?cFZhMUlUVFZnSSszWXdvMXEyUGJVMEhpZFNPaHpPbTdqOGxqdWphb0xjTkdZ?=
 =?utf-8?B?NmxnSi95N2N5ekRqejRvY3dpd3JYRitTRFdudi9hdW5VZGR4aEdsNDlmM0Nl?=
 =?utf-8?B?WUxEZEtDVnpYdTVya3dlcHZwSTdFK2VQTVBPMmdxV2JNbkhVamtZTm00eDFy?=
 =?utf-8?B?TFpLOXZJTVZKNFphaUdpbVpYYnNyUmVnNnFWL01rMHlUNjlEOXd1Q0I3OHlW?=
 =?utf-8?B?OHlQL2hUaU80dFk3M0dqUDBjbjErcGVUbW9OWmJqdjRIV1RCWVFkTWMwNnB2?=
 =?utf-8?B?dDRUVXRBYUwrUzlydldxMmtRb3EweDRwWnFUZGx4dW05bHhiZDhXTVBUOXVV?=
 =?utf-8?B?Z0phSWhYb2VTWEdCc2hSUzEwYmxVdjl4Z0pueFRYSkZlSms5U0pCRVpqcHU0?=
 =?utf-8?B?QXNIcW1oNHF5TmxUYmU5MkRkUUpRNlNzczNPaUZ4UzVBUUs2T3puKzcrU2Fl?=
 =?utf-8?B?NUJjUTU0MEZST3ZrTFFNUzFIdGJPdTZZVzE3NU9vcGEzYnc5NXRqS0d4Ris4?=
 =?utf-8?Q?WY9q9PmSuPM=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR03MB5223.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZW90RTVvcG4wc01RNG1veFNZMUtQSXlLMEF0MjBWYXJIWHhldzlNcFZuM2M1?=
 =?utf-8?B?WUp5QldTTjZBb1JSUkxBZFZMaWRqNklwMW9PMGpkMDZYdTlHQkFyZ3owdUlM?=
 =?utf-8?B?eE9HR0ExMUhCa2h5SEVwQjNZUS9jOE1aN1QrbzNJaXJTVWZKMGRnYU90TWxX?=
 =?utf-8?B?VEJoL1JIQUhlOFhBanN2UktSY2pnUWttbTdmclJiYzIrUnh2WkVkRVl2d2t6?=
 =?utf-8?B?U3VuRW5IODBqTDA3THB0aTNqQ2E2dnhQK2xCc2Z1OUZrOGozUThpN3d3VElt?=
 =?utf-8?B?L2hBN29rSnlUL0lUaFRPclZoZXVKalpxRmFWcGljTGg2WGpJMll4Um55NVgy?=
 =?utf-8?B?M3FQSllzYWtoZmQxZ2VMa25oSzQrVlRJa3k3cjg3cmZoV3labHkzYklNZ1FM?=
 =?utf-8?B?K0EzUW9qSjNxcEl6Tjd3Z2p3eTBoblBVZnlqSm90N09ZUWVjS2s1NWltT3Jx?=
 =?utf-8?B?eEpYUFNlS0dZU2F6M1NxaGUwamg3a1F3TTVxK3pwcU9RTmhEY3ZTYWEzNHY5?=
 =?utf-8?B?Q1lHZlFLNDJwb2VwOVdEYkhXK2hLN0VoRUJXQUdtU1d0cFNUWTlLYmxqVVZx?=
 =?utf-8?B?Z2F0WFlqM1gxMURuemZGeWdTMFd5NnMxQ0lmOHB0WGFlb2txWHdkb2QzYUNX?=
 =?utf-8?B?Mkp4SWxBZkcxdkN6WThQU1RUd0RydTF2bE5ISTlBbTZIUTd0N2NLMStnNXVz?=
 =?utf-8?B?UjN5MmVodWVvVnQ2Unl5VndJMEFTTzZnUUpMNUx6dTRTb1RPNk9ZYlVDbnRE?=
 =?utf-8?B?MDNVWUlZdllvN1N0c0VkK1R3OXZBZGhkKzJydCtqaVZnZWtmNEdKUU5NQ25Q?=
 =?utf-8?B?NktBc3NzR1pqSUZYY052bDhzcnU4a0RyUmJRR3pLbituN2REQUlVV1d2UXMr?=
 =?utf-8?B?cEJOeElLOWJkN0tKeGJoMDhpMFhoZnJjckVkQkpoL0dGeTA2VmliU1NWeW4x?=
 =?utf-8?B?L2tBTk1HZkFVZHV6Vitqb0RTdW9CQnRsUE9mYUJ3T2hQZmtzUFZMd0t5N1FZ?=
 =?utf-8?B?MGZRVWhGTHIrWTU4a3kvM3Q1OGdWNXFpaEdkREgvUXVYMzNuMEJGSTBZU3ZU?=
 =?utf-8?B?WnAzZUJydjFvK0FvL0p3TEFoWXVwdGVFb0djNXlqZzZNamdKanZCSHJ6VkpM?=
 =?utf-8?B?NnhhWlQxRDRCMUdwbU9aVlY5SEI2eVVyZGFBdGszL1FMY250NnpNWnNUZDlv?=
 =?utf-8?B?eDJ4MVZORUh4YUo2SVhZSURKcjhFNFliMC8yRGNTSUpISWlVREU2eUdsei9O?=
 =?utf-8?B?YlF3Y09ZNGRjTnE3ZEcwbkQyN0xXT3Z6dHZZQmk5cVdDaDVYbFN2V2c3eEtj?=
 =?utf-8?B?bmhQalppKzFnSHJJSk5vNzliTEErU2hKRTBCVUI3QXhCWndKV2oxOTdzMjhT?=
 =?utf-8?B?MHBobjBiV256Z2hGZmwyYVJWODc5VVNDOGViQVJiVUZhcExlNjUzQkFGTXNH?=
 =?utf-8?B?VmIxUDRJQ0pHeGxRYkpDOGJCR1UzQWZhVmg5bjhESjgwU0ExOE5hcmtPM3B2?=
 =?utf-8?B?TmZUeUxUTHgwVm1IWThMSVdsWnFRbVlmakVESnAzVzJ6ejdiT3JTUCtlb3ZD?=
 =?utf-8?B?Y1dqK0RINXBkc0pNNW8xOE1OTGhzaWJpU0NmK1NFZm1NYlQ2dm9sd2dyZWN1?=
 =?utf-8?B?bzFCbkdZenhzWElSNS9acU9aWjBTRUNEa0UyZ1NaZzhBM0VPVU9RZVhBazNS?=
 =?utf-8?B?NWZkWEVGTytNM2pjcE9aTWZWQndmdVorTGZ0RTdhUkh2V3RpbTUrbDk4TDFk?=
 =?utf-8?B?c050eHA2bG03KytxQWVNVlFnTktYUmJDSStCRndKSGFuMGpqWlBXSDAvaFNC?=
 =?utf-8?B?V3A5Q01lL0g1QnVyRXRDQWV4YW1WcUZnSWVEY1lTb0hkWUQwb2N3MnVjaXdC?=
 =?utf-8?B?ejlmM1oyd3lGT2I2V1c2T2tsK2JvOWVXbHl3Ujl1aDZaZ2sxUTJpbytoczdv?=
 =?utf-8?B?clpjUGZXNWplT1hmUXpJNFRCNzlJZkkvNFg5bXZBRzJMSWp5WS91ak5YT2JL?=
 =?utf-8?B?UmFpT2JDdFg2WHlSUjAyN3p2SVVUTmx3c0R1UXliM1RRSHhGNlk2bWw4VU9t?=
 =?utf-8?B?UTZQZmNJY2tFZzArNEcvdmZwLy8yN0M4T2RKYVlBb2EvSm9OazcyM1VxNk9P?=
 =?utf-8?Q?m3iMmg8AYhFsdYaO/I1GFUZaI?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47df74dd-9450-46e5-e5fb-08ddfb59a3d8
X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5223.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 11:00:57.8637
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: mdp37mX3uC55JY6cpvZdBMP0w/eEpwNUdlCOYx9hwgX89RYaobZvmFXaEcPdBndekg/B3mcRdfCxvnzMLqU5cw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR03MB6231

Otherwise the check for the SS feature in
check_memory_type_self_snoop_errata() fails unconditionally, which leads to
X86_FEATURE_XEN_SELFSNOOP never being set.

We could also avoid this by not doing the reset_cpuinfo() for the BSP in
identify_cpu(), because SS detection uses boot_cpu_data.  However that
creates an imbalance on the state of the BSP versus the APs in the
identify_cpu() code.

I've opted for the less controversial solution of populating FEATURESET_1d
in generic_identify(), as the value is already there.  The same is done for
the AMD faulting probe code.

Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/cpu/common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 530b9eb39abc..35dcdf0c8801 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -490,6 +490,9 @@ static void generic_identify(struct cpuinfo_x86 *c)
 	c->apicid = phys_pkg_id((ebx >> 24) & 0xFF, 0);
 	c->phys_proc_id = c->apicid;
 
+	/* Early init of Self Snoop support requires 0x1.edx. */
+	c->x86_capability[FEATURESET_1d] = edx;
+
 	eax = cpuid_eax(0x80000000);
 	if ((eax >> 16) == 0x8000)
 		c->extended_cpuid_level = eax;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 11:22:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 11:22:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129301.1469313 (Exim 4.92)
	(envelope-from )
	id 1v1NZv-0007wv-77; Wed, 24 Sep 2025 11:22:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129301.1469313; Wed, 24 Sep 2025 11:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1NZv-0007wo-46; Wed, 24 Sep 2025 11:22:31 +0000
Received: by outflank-mailman (input) for mailman id 1129301;
 Wed, 24 Sep 2025 11:22:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1NZt-0007wi-RN
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 11:22:29 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c06424c1-9938-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 13:22:28 +0200 (CEST)
Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com
 [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-593-7O7_IitvOie3eLey579gAg-1; Wed, 24 Sep 2025 07:22:23 -0400
Received: by mail-wr1-f69.google.com with SMTP id
 ffacd0b85a97d-3ee13e43dd9so2807472f8f.1
 for ; Wed, 24 Sep 2025 04:22:23 -0700 (PDT)
Received: from ?IPV6:2a01:e0a:280:24f0:576b:abc6:6396:ed4a?
 ([2a01:e0a:280:24f0:576b:abc6:6396:ed4a])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2aae3d58sm30912385e9.21.2025.09.24.04.22.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 04: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: c06424c1-9938-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758712947;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=KQXPYLh+of7Gb6x92qz6TH1PpHfEJDOd50U9lMltvh8=;
	b=YypqHN1NfLTTsxuBzFLtC+4aR0shp0FJA4DYFxtJp1lg+xBm+Zu3SVfGtXE6byoUre4zb1
	UDqE72ySq3u+WSQ6OOD8kBifrfx8Diw8rEe0z8JGqCZaIyr4A13/lvjTj7MidYoJLFF55/
	y+As8CMt7TRLNXGxRg7xf+mXajg3F9Q=
X-MC-Unique: 7O7_IitvOie3eLey579gAg-1
X-Mimecast-MFC-AGG-ID: 7O7_IitvOie3eLey579gAg_1758712943
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758712942; x=1759317742;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=KQXPYLh+of7Gb6x92qz6TH1PpHfEJDOd50U9lMltvh8=;
        b=ty63CHjAz5oMnHr4ngZBcd8UWXmHf5KLyQxDMmTyE2I3KcFeGYF6XSik1r9bW3PB5Q
         7fBZNqYX603VdeWHvLzQ0bjT5UBp9oF5SCmCkJWUlyytP5DHggAD9E589e6SM4HRSFOW
         quxXS9LlkMiUAuoMaPH5v7kyX3C0V0AQ2l3nzIfJQwIcapwu7cWlb6DFKjQjXi7BzOSN
         7E3w6b4XWKZrnD/g6llYByjNLTZI+RdJX58S6ewnfr6hFcY0l3TH4zTVTUWjHkN+IiyE
         OH/wNBfiZhGYt4guLGF77KWrkfZzsadm8l4IuN1rq2FmbC5VXB9T+EzwYBEbI4y1rAX4
         yarw==
X-Forwarded-Encrypted: i=1; AJvYcCVBvBs+ptl19CA840ctz65n/1GGNwiPcLmS1nFuTOpJCvyZ/RpUiXpe+KqEpLC5IUjr2BX0VsZQqL4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywu0mXrjPFlIvcm9Q4w7Hipm6zU+T/Eo7gTSNlhrHmusI4EAjZX
	CqCiCghiRhhxUxLFxHewB+8oS1lb1DJSL/HOUuc8L/CCvyyu7yiSRN/Cw4ux5muGjxcMS+EAFbE
	H30W6IfNVlTR/8Xek2WAF+wXaqX92Jb7uhpsA8SCo5H5mc68fRvjRM7Q6cH3t3QzGSahr
X-Gm-Gg: ASbGncucchKhzd3iItZ+4h7nwNrm6kSxsBLK1A5S2nira86ZYrMUAwcgvgDgXZjjSnI
	jJUOnaueCtJFW0ozPGeH2MPDgJBmjknfvo4hfMSXMUmJRNFCMglBN7N+datpHe+5YGZlEQW6pFU
	AUdIcpNklVfY6/3JAgIYBmz1ZpF63/Ljj7PT+qDnLQuqVOa4w/lXG9/FcLR8VRUGm7ms6bexrct
	R/NWGu0MI1wRsdwcI8gvV+XTU5mlZ5pHUazvm4opcup+ldPmTittFgqwcrdlJhM6GiZRPwf0xmE
	jG00udqYrDu6iZ5lzB/WS7oJZTzCzkeKlL04yNXD4uesaep1AQCb3CmGp/Vi5t4ejxiDesu3hQu
	rEz0=
X-Received: by 2002:a05:600c:1c27:b0:46d:7fa2:7579 with SMTP id 5b1f17b1804b1-46e1d97f519mr61733495e9.9.1758712942615;
        Wed, 24 Sep 2025 04:22:22 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IH4zxIdqb0bQt7+O6bR7wlR8dDmENCHycIYRfk3vyL1fyeHgFfcRcxjXOAAR51hT9R4ZdiPfA==
X-Received: by 2002:a05:600c:1c27:b0:46d:7fa2:7579 with SMTP id 5b1f17b1804b1-46e1d97f519mr61732805e9.9.1758712942128;
        Wed, 24 Sep 2025 04:22:22 -0700 (PDT)
Message-ID: <2e5a20cd-7ea6-44fd-9401-82e741a089ff@redhat.com>
Date: Wed, 24 Sep 2025 13:22:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/7] vfio/pci: Do not unparent in instance_finalize()
To: Akihiko Odaki , qemu-devel@nongnu.org
Cc: Alex Williamson ,
 Paolo Bonzini , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 , Eduardo Habkost ,
 Peter Xu , David Hildenbrand ,
 =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 Richard Henderson ,
 Helge Deller , =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?=
 , "Michael S. Tsirkin" ,
 Gerd Hoffmann , John Snow ,
 qemu-block@nongnu.org, Keith Busch ,
 Klaus Jensen , Jesper Devantier ,
 Marcel Apfelbaum ,
 Nicholas Piggin , qemu-ppc@nongnu.org,
 John Levon ,
 Thanos Makatos ,
 Yanan Wang , BALATON Zoltan ,
 Jiaxun Yang ,
 Daniel Henrique Barboza ,
 David Gibson ,
 Harsh Prateek Bora ,
 Alexey Kardashevskiy , =?UTF-8?Q?Alex_Benn=C3=A9e?=
 , Fabiano Rosas ,
 Thomas Huth , Laurent Vivier ,
 Peter Maydell ,
 Aurelien Jarno , Aleksandar Rikalo
 , Max Filippov ,
 =?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
 Mark Cave-Ayland ,
 Artyom Tarasenko ,
 Alistair Francis ,
 "Maciej S. Szmigiero" ,
 Bin Meng , Stefano Stabellini ,
 Anthony PERARD , Paul Durrant ,
 "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
 <20250924-use-v4-2-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= 
Autocrypt: addr=clg@redhat.com; keydata=
 xsFNBFu8o3UBEADP+oJVJaWm5vzZa/iLgpBAuzxSmNYhURZH+guITvSySk30YWfLYGBWQgeo
 8NzNXBY3cH7JX3/a0jzmhDc0U61qFxVgrPqs1PQOjp7yRSFuDAnjtRqNvWkvlnRWLFq4+U5t
 yzYe4SFMjFb6Oc0xkQmaK2flmiJNnnxPttYwKBPd98WfXMmjwAv7QfwW+OL3VlTPADgzkcqj
 53bfZ4VblAQrq6Ctbtu7JuUGAxSIL3XqeQlAwwLTfFGrmpY7MroE7n9Rl+hy/kuIrb/TO8n0
 ZxYXvvhT7OmRKvbYuc5Jze6o7op/bJHlufY+AquYQ4dPxjPPVUT/DLiUYJ3oVBWFYNbzfOrV
 RxEwNuRbycttMiZWxgflsQoHF06q/2l4ttS3zsV4TDZudMq0TbCH/uJFPFsbHUN91qwwaN/+
 gy1j7o6aWMz+Ib3O9dK2M/j/O/Ube95mdCqN4N/uSnDlca3YDEWrV9jO1mUS/ndOkjxa34ia
 70FjwiSQAsyIwqbRO3CGmiOJqDa9qNvd2TJgAaS2WCw/TlBALjVQ7AyoPEoBPj31K74Wc4GS
 Rm+FSch32ei61yFu6ACdZ12i5Edt+To+hkElzjt6db/UgRUeKfzlMB7PodK7o8NBD8outJGS
 tsL2GRX24QvvBuusJdMiLGpNz3uqyqwzC5w0Fd34E6G94806fwARAQABzSJDw6lkcmljIExl
 IEdvYXRlciA8Y2xnQHJlZGhhdC5jb20+wsGRBBMBCAA7FiEEoPZlSPBIlev+awtgUaNDx8/7
 7KEFAmTLlVECGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQUaNDx8/77KG0eg//
 S0zIzTcxkrwJ/9XgdcvVTnXLVF9V4/tZPfB7sCp8rpDCEseU6O0TkOVFoGWM39sEMiQBSvyY
 lHrP7p7E/JYQNNLh441MfaX8RJ5Ul3btluLapm8oHp/vbHKV2IhLcpNCfAqaQKdfk8yazYhh
 EdxTBlzxPcu+78uE5fF4wusmtutK0JG0sAgq0mHFZX7qKG6LIbdLdaQalZ8CCFMKUhLptW71
 xe+aNrn7hScBoOj2kTDRgf9CE7svmjGToJzUxgeh9mIkxAxTu7XU+8lmL28j2L5uNuDOq9vl
 hM30OT+pfHmyPLtLK8+GXfFDxjea5hZLF+2yolE/ATQFt9AmOmXC+YayrcO2ZvdnKExZS1o8
 VUKpZgRnkwMUUReaF/mTauRQGLuS4lDcI4DrARPyLGNbvYlpmJWnGRWCDguQ/LBPpbG7djoy
 k3NlvoeA757c4DgCzggViqLm0Bae320qEc6z9o0X0ePqSU2f7vcuWN49Uhox5kM5L86DzjEQ
 RHXndoJkeL8LmHx8DM+kx4aZt0zVfCHwmKTkSTQoAQakLpLte7tWXIio9ZKhUGPv/eHxXEoS
 0rOOAZ6np1U/xNR82QbF9qr9TrTVI3GtVe7Vxmff+qoSAxJiZQCo5kt0YlWwti2fFI4xvkOi
 V7lyhOA3+/3oRKpZYQ86Frlo61HU3r6d9wzOwU0EW7yjdQEQALyDNNMw/08/fsyWEWjfqVhW
 pOOrX2h+z4q0lOHkjxi/FRIRLfXeZjFfNQNLSoL8j1y2rQOs1j1g+NV3K5hrZYYcMs0xhmrZ
 KXAHjjDx7FW3sG3jcGjFW5Xk4olTrZwFsZVUcP8XZlArLmkAX3UyrrXEWPSBJCXxDIW1hzwp
 bV/nVbo/K9XBptT/wPd+RPiOTIIRptjypGY+S23HYBDND3mtfTz/uY0Jytaio9GETj+fFis6
 TxFjjbZNUxKpwftu/4RimZ7qL+uM1rG1lLWc9SPtFxRQ8uLvLOUFB1AqHixBcx7LIXSKZEFU
 CSLB2AE4wXQkJbApye48qnZ09zc929df5gU6hjgqV9Gk1rIfHxvTsYltA1jWalySEScmr0iS
 YBZjw8Nbd7SxeomAxzBv2l1Fk8fPzR7M616dtb3Z3HLjyvwAwxtfGD7VnvINPbzyibbe9c6g
 LxYCr23c2Ry0UfFXh6UKD83d5ybqnXrEJ5n/t1+TLGCYGzF2erVYGkQrReJe8Mld3iGVldB7
 JhuAU1+d88NS3aBpNF6TbGXqlXGF6Yua6n1cOY2Yb4lO/mDKgjXd3aviqlwVlodC8AwI0Sdu
 jWryzL5/AGEU2sIDQCHuv1QgzmKwhE58d475KdVX/3Vt5I9kTXpvEpfW18TjlFkdHGESM/Jx
 IqVsqvhAJkalABEBAAHCwV8EGAECAAkFAlu8o3UCGwwACgkQUaNDx8/77KEhwg//WqVopd5k
 8hQb9VVdk6RQOCTfo6wHhEqgjbXQGlaxKHoXywEQBi8eULbeMQf5l4+tHJWBxswQ93IHBQjK
 yKyNr4FXseUI5O20XVNYDJZUrhA4yn0e/Af0IX25d94HXQ5sMTWr1qlSK6Zu79lbH3R57w9j
 hQm9emQEp785ui3A5U2Lqp6nWYWXz0eUZ0Tad2zC71Gg9VazU9MXyWn749s0nXbVLcLS0yop
 s302Gf3ZmtgfXTX/W+M25hiVRRKCH88yr6it+OMJBUndQVAA/fE9hYom6t/zqA248j0QAV/p
 LHH3hSirE1mv+7jpQnhMvatrwUpeXrOiEw1nHzWCqOJUZ4SY+HmGFW0YirWV2mYKoaGO2YBU
 wYF7O9TI3GEEgRMBIRT98fHa0NPwtlTktVISl73LpgVscdW8yg9Gc82oe8FzU1uHjU8b10lU
 XOMHpqDDEV9//r4ZhkKZ9C4O+YZcTFu+mvAY3GlqivBNkmYsHYSlFsbxc37E1HpTEaSWsGfA
 HQoPn9qrDJgsgcbBVc1gkUT6hnxShKPp4PlsZVMNjvPAnr5TEBgHkk54HQRhhwcYv1T2QumQ
 izDiU6iOrUzBThaMhZO3i927SG2DwWDVzZltKrCMD1aMPvb3NU8FOYRhNmIFR3fcalYr+9gD
 uVKe8BVz4atMOoktmt0GWTOC8P4=
In-Reply-To: <20250924-use-v4-2-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: SchNzHXNnjs-JEJIRyJ-edVWWGAnq8Bdlz9h_-cIM-A_1758712943
X-Mimecast-Originator: redhat.com
Content-Language: en-US, fr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 9/24/25 06:37, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the insntance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> Reviewed-by: Daniel P. Berrangé 
> ---
>   hw/vfio/pci.c | 4 ----
>   1 file changed, 4 deletions(-)
> 
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index d14e96b2f82d..bc0b4c4d562b 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2025,7 +2025,6 @@ static void vfio_bars_finalize(VFIOPCIDevice *vdev)
>           vfio_region_finalize(&bar->region);
>           if (bar->mr) {
>               assert(bar->size);
> -            object_unparent(OBJECT(bar->mr));
>               g_free(bar->mr);
>               bar->mr = NULL;
>           }
> @@ -2033,9 +2032,6 @@ static void vfio_bars_finalize(VFIOPCIDevice *vdev)
>   
>       if (vdev->vga) {
>           vfio_vga_quirk_finalize(vdev);
> -        for (i = 0; i < ARRAY_SIZE(vdev->vga->region); i++) {
> -            object_unparent(OBJECT(&vdev->vga->region[i].mem));
> -        }
>           g_free(vdev->vga);
>       }
>   }
> 



Reviewed-by: Cédric Le Goater 

Thanks,

C.




From xen-devel-bounces@lists.xenproject.org Wed Sep 24 11:24:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 11:24:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129318.1469322 (Exim 4.92)
	(envelope-from )
	id 1v1NbU-0008WO-M1; Wed, 24 Sep 2025 11:24:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129318.1469322; Wed, 24 Sep 2025 11:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1NbU-0008WF-J8; Wed, 24 Sep 2025 11:24:08 +0000
Received: by outflank-mailman (input) for mailman id 1129318;
 Wed, 24 Sep 2025 11:24: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 1v1NbS-0008Vb-V0
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 11:24:07 +0000
Received: from BN1PR04CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c110::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa1e77dd-9938-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 13:24:05 +0200 (CEST)
Received: from PH1PEPF000132F3.NAMP220.PROD.OUTLOOK.COM (2603:10b6:518:1::38)
 by PH7PR12MB7938.namprd12.prod.outlook.com (2603:10b6:510:276::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Wed, 24 Sep
 2025 11:23:57 +0000
Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com
 (2a01:111:f403:f912::4) 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.9137.19 via Frontend Transport; Wed,
 24 Sep 2025 11:23:56 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Wed, 24 Sep 2025 11:23:56 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 24 Sep
 2025 04:23:54 -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: fa1e77dd-9938-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JRMkRlVBYZX35HXUseKZopbzGYhXj2Z1lq8LQEXqyhJi2+tANNDe3Efxlau37Tuk9+lrNuyp63x7asTmSFue6KOA/Hrtn8TdlT74z5A5XsuVywwi55oY7mbvEE5z4nXMPouJCDSRJWCLay+derZF4bCwIVcGW2jnK7rm+9dsAZZ50co2qCPGfd5AcylLL02G4rdmCVi1VZM/bsIot4yiunQGtCMs4OcQl2M1aGWAsTlQbo46OXiD5IZ5PU03A0XXyMhc4pvoDrFzk1HtlI0bzxW/I3+7JlvCaz8OsaoK1+7Fg030o18d2dyhYD7KbmRJkieJzNh6/BtQ0xFLwYJgeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TJ1tSyabFMHOybYVns4qVp3jMn68goaH320dG5GL//I=;
 b=CTV9UcAaD5nd4O9Z/XwvxmnI+xsmsT66BB75L/bDbv9AoTzN5h7/muCRGq4gGEG7uaSinN2mPLjwJbrPDX9abNKYyrMHyaOmDLPPwqIJhI8t8RQHVceTZlIrWeNz8C3+ejB6FMAX45j9Lu6O7QlhVrxzchrmXp78uIY770PmpcDZuqnPwZLkBc2E0pSrOq5oF6dTHd1p4RJ+qpJZDlCtWTfzwnVbMiQ0uKT0Gc7eLJU/k3S+7/eqo2tZ597FAgVjHU5H8C5Wjl3oRIhOWuOM/OAsDXKbjAevfqGgkhHaazxopChOVUqO8GWm9ba0xhjvPpnZbJDPH7C/X+V9bZjFkA==
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=TJ1tSyabFMHOybYVns4qVp3jMn68goaH320dG5GL//I=;
 b=DeUsyd2h555B9FZD37iTvNHR9AeaowBv8UF4iHK45/MNLudSBY75WEd3/HD0FttCEGTd3Kj/vf/02jx/CyR2qwHsBccDt3UhKcDrKJT9NhSArKEFHUEHcZGKs+hd3a/Eb9lOEpwCFTKhBHipDa/ezRG9JShw0zjjrTSnFqtGWQs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 24 Sep 2025 13:23:53 +0200
Message-ID: 
CC: Andrew Cooper ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Oleksii Kurochko
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
From: Alejandro Vallejo 
To: Andrew Cooper , Grygorii Strashko
	, Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
 <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
 
 <88cc4cf1-3bc9-47f5-b8f7-e04f01b027ee@xen.org>
In-Reply-To: <88cc4cf1-3bc9-47f5-b8f7-e04f01b027ee@xen.org>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D2:EE_|PH7PR12MB7938:EE_
X-MS-Office365-Filtering-Correlation-Id: bbebd8ed-c60b-4f03-5878-08ddfb5cd9bd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bTRVVER6bS9oRDRSTVdaK3RmUkd6U0VGdE9Uay9mQ29lbTRidUFOSGNQL2Qr?=
 =?utf-8?B?cTJ3L2NTWEE2aXVpTzdWaUJBcVl5NHVnSmZ3aU1HekxsYTg5QzVzMnZvM21t?=
 =?utf-8?B?WHo1cXQ0Zk9YbjRZZXF5Qml2SVNtWlloSGpQdVJVam1QYjlqOE45eEpiNVRv?=
 =?utf-8?B?Zld2VzJRQVUrTVY5ODQwd29zbzF2TnVMaUJxQjNreGhkb0llUVpQQmNtZjJl?=
 =?utf-8?B?cy9WTXo2SHV5QWJJclNnYkVuT25sdDdXamcvMnBzWFF4aWcvYWg5SWt5cWIw?=
 =?utf-8?B?ODRWY3A1R1Y4SVFzSW1IelJvSDJRV0M1L0hQRHVtTWExTUxZK0FCZ1FhRGNw?=
 =?utf-8?B?aVBHUldxLytERWVxRUFabnpvOENRR2tJMnMrcU9GNXpRMCtrUGRzLzYzR01h?=
 =?utf-8?B?cGRERzdTRC9JL3Q0Nm5MRFNrajRNOTBib2hBZENYc3hxTUtOT0NTL3ZPN0sw?=
 =?utf-8?B?SUYwbHUrZ0J0eURSMS8rMDI0dUFIU0Q2ZnljYjNXenNpY2tkUXJWQit3WXFZ?=
 =?utf-8?B?VnJJNnpSMEhFQWdMcVU2MFRhSzUrZXdYemVvUkN6NmVxbjhGZGpEbjJXVDVF?=
 =?utf-8?B?WE1nVGNscmRnVW45VTBKWkU3Mmh5ci9jTkFVNlVXRlJVZ3M2Qjk3eEtPY0Rn?=
 =?utf-8?B?N0M0SDJwN0I5VW11dUk4L29MdFdoT0h3dFA1cUJkQzZ2Nld5b09IbTYvTmtq?=
 =?utf-8?B?N2Naei9wRC94cTZJUk9YNlJEa3loQk10Mk1pTXprTjRiNjYzaFMyRkp4Mmd6?=
 =?utf-8?B?dHB5dDJWQUZ5RVB5OExmc3FSZUN6SndqN05UWU1rM2NPNk50WDdqYUhIYTlj?=
 =?utf-8?B?WVg0Z0pUU3hWeU9iWEtjZ2svUEVFS1hZTDRNOFh0YkpadFRjbnBucWNTeTRh?=
 =?utf-8?B?NE9SRlhBN0xPcjhzeUgvcVIxME1oNm5BaVV5S3I0TzBhSVdBU2p5ODZuTUU1?=
 =?utf-8?B?Z1Z2M1psZEhQT2tUWWRveHc5cEdnNldwWmV4TCtJVWRDZUxkQ1VlcmFiV3Uw?=
 =?utf-8?B?QzVHblFIbzFJa1hTbFJ6bWtoMUZxdVpGT3pCbXRmSTQxOHZpaGo3Q0VTT0Vj?=
 =?utf-8?B?ckRXOGNlZ1grTFdwQzY3L0dTR01QWk1xV0JNSmZUb1JORnN3M2kzTlJ1akZt?=
 =?utf-8?B?ZmNKQkJld083QVYvbUpGTWFkZTlGcXI1Y0xGTVFPbHM2czdwbnptVzFSUlBN?=
 =?utf-8?B?MDd2UUxIb3ZZb3JlTFlTc0V2WDI1bEtEUEFGbDAxUWxCcFlmYVNmT0xteUJT?=
 =?utf-8?B?MW0xUHRFakVVOHczM2UrS3JoWkJNTzRxVGI5K1RhOUhvbjdWUmdqN2wzUkFZ?=
 =?utf-8?B?VDZCWUhRMG9iejZFdVpBdU1rMytRc0ZHRUllV1BCeXBCVnVDQ2ZiQnN6NjEx?=
 =?utf-8?B?MHZtOWh5YkpEZGdJK1Nmb3JKWGp4a3JMWmNQTlhUWUo1NVo5OGZNRWZ2K3Vp?=
 =?utf-8?B?NGRkK1JuQlRXQ21vRUo2b1VnSG00RGRYcG9mUFE5SkdjbDVkN2RvYTFscXlu?=
 =?utf-8?B?RFZDNEdGRHpDbHhxRUd3R0hiNkR0V2dPODhORzZLclQ4YWZTdUpjbERHMm8r?=
 =?utf-8?B?eW1NejZ1ZUJsSkd5QXNRL2gzM1k0NmtvdTlMdXJGdjhhM2k0SWpFVVNGM1RJ?=
 =?utf-8?B?QmJ4RzczQmU4LzYrcGN3YUozRnlnSHZnOWZUVk0wNjNoNXNSWXFsc0dIS0pq?=
 =?utf-8?B?bFRlVG14c0xVMUQ4T3BkUEhnNEwrM0ZmbUUreFMvRysvWmZHN0UxRVNLOVR4?=
 =?utf-8?B?ODhUbFpMeGpXTk1mbGNURXNyTlBGT2p6RjZhbERCV0REYSs5YmtOTFFUK2lp?=
 =?utf-8?B?L2ZIRnN0SmRzSnRqOUowY0w4MnJaZEtoQlowWjJ6ZmZZSEp2V1d5VkNQWHI3?=
 =?utf-8?B?SXB0dHBmYXdPenFqWUdabXMxNjF6WEJ4TCtuL2dHZ3ZJcFVadXBuSXBNbVdz?=
 =?utf-8?B?ZklNdXRlRG14K2g4eGxudUJHSmxnVGRlelBYZHBTeVFCRzBzN0U0ODh6cHlF?=
 =?utf-8?B?WWJpSHdMei9HMVZMOUdyRFovTm1GajBicnZ2Z29PMXZHdndEY3pONGVFNVNm?=
 =?utf-8?B?Y1JNRnJqdGF5OTkzcmpJTDBUN3F6RzA2aG93Zz09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 11:23:56.4238
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bbebd8ed-c60b-4f03-5878-08ddfb5cd9bd
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D2.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7938

On Tue Sep 16, 2025 at 7:14 PM CEST, Andrew Cooper wrote:
> On 16/09/2025 9:57 am, Grygorii Strashko wrote:
>> Hi Jan,
>>
>> On 16.09.25 17:34, Jan Beulich wrote:
>>> On 16.09.2025 12:32, Grygorii Strashko wrote:
>>>> From: Grygorii Strashko 
>>>>
>>>> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX
>>>> dependency") the
>>>> HVM Intel VT-x support can be gracefully disabled, but it still
>>>> keeps VMX
>>>> code partially built-in, because HVM code uses mix of:
>>>>
>>>> =C2=A0 - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_V=
MX cfg
>>>> =C2=A0 - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX c=
fg
>>>>
>>>> for runtime VMX availability checking. As result compiler DCE can't
>>>> remove
>>>> all, unreachable VMX code.
>>>>
>>>> Fix it by sticking to "cpu_has_vmx" macro usage only which is
>>>> updated to
>>>> account CONFIG_INTEL_VMX cfg.
>>>>
>>>> Signed-off-by: Grygorii Strashko 
>>>> ---
>>>> Hi
>>>>
>>>> It could be good to have it in 4.21, so vmx/svm disabling
>>>> option will be in complete state within 4.21 version.
>>>
>>> Imo this isn't release critical and has come too late. It's of course
>>> Oleksii's call in the end.
>>>
>>>> --- a/xen/arch/x86/include/asm/cpufeature.h
>>>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>>>> @@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>>>> =C2=A0 #define cpu_has_sse3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 boot_cpu_has(X86_FEATURE_SSE3)
>>>> =C2=A0 #define cpu_has_pclmulqdq=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b=
oot_cpu_has(X86_FEATURE_PCLMULQDQ)
>>>> =C2=A0 #define cpu_has_monitor=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 boot_cpu_has(X86_FEATURE_MONITOR)
>>>> -#define cpu_has_vmx=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 boot_cpu_has(X86_FEATURE_VMX)
>>>> +#define cpu_has_vmx=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 (IS_ENABLED(CONFIG_INTEL_VMX) && \
>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boot_cpu_has(X86_FEATURE_V=
MX))
>>>
>>> I'm pretty sure using_vmx() was introduced precisely to avoid the use o=
f
>>> IS_ENABLED() here. What is completely missing from the description is a
>>> discussion of the effect of this change on pre-existing uses of the
>>> macro. ISTR there being at least one instance which would break with
>>> that change. And no, I'm not looking forward to digging that out again,
>>> when I already did at the time the using_vmx() was suggested and then
>>> implemented. (I can't exclude it was the SVM counterpart; we want to
>>> keep both in sync in any event, imo.)

Apologies if this has already been discussed, but I didn't participate in p=
rior
discussions. Targeted lookups in lore are not shedding a lot of light eithe=
r.

>>
>> Thank you for your comments and sorry for not digging into the history o=
f
>> the related patches.
>>
>> All, please ignore these patches as existing places. where
>> cpu_has_vmx/smv
>> are still used, need to be revised one by one.
>>
>
> Off the top of my head, fixups to MSR_FEATURE_CONTROL, and AMD SKINIT
> need cpu_has_vmx/svm not guarded by Kconfig like this.
>
> ~Andrew

What do you mean? AFAICS SKINIT is guarded by cpu_has_skinit, not cpu_has_s=
vm.

And MSR_IA32_FEATURE_CONTROL tweaking seems self-contained in xen/hvm/vmx/ =
which
is compiled out when !CONFIG_INTEL_VMX.

For the hypothetical case in which we might want to know the real HW value
we can go look at the raw policy, as in "raw_cpu_policy.basic.vmx" or
"raw_cpu_policy.extd.svm". Or what's mentioned in passing here.

https://lore.kernel.org/xen-devel/a881c6a6-2c36-4e5c-8336-21cd0e14b873@suse=
.com/

Forcing the common case to use a helper and leaving the rare case in the
shorthand macro seems like a bad idea. This ought to follow what cpu_has_nx
already does.

Is there a specific code instance in which having IS_ENABLED() in the
cpu_has_{svm,vmx} macros would cause issues today? While there are some dub=
ious
choices of svm vs vmx with or without negation, they all seem to resolve
to correct code, with less codegen after IS_ENABLED() ends up in all the
conditionals.

IOW: I have seen fear of incorrectness, but not proof of it. Now, obviously=
 the
burden of proof rests on the submitter, indeed, but I'd like to know where =
we
stand in terms of what that proof would look like. A naive grep shows not m=
any
sites to check.

  $git grep cpu_has_svm | grep -v cpu_has_svm_ | wc -l
  6

  $git grep cpu_has_vmx | grep -v cpu_has_vmx_ | wc -l
  11

cpu_has_X_Y would be off when cpu_has_X is off, but those shouldn't matter =
for
this discussion.

Am I missing something here?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 11:31:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 11:31:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129331.1469333 (Exim 4.92)
	(envelope-from )
	id 1v1NiT-0001lg-Cc; Wed, 24 Sep 2025 11:31:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129331.1469333; Wed, 24 Sep 2025 11:31: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 1v1NiT-0001lZ-9t; Wed, 24 Sep 2025 11:31:21 +0000
Received: by outflank-mailman (input) for mailman id 1129331;
 Wed, 24 Sep 2025 11:31: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 1v1NiS-0001lT-8J
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 11:31:20 +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 fd3bcab1-9939-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 13:31:19 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-62fc89cd630so8088882a12.2
 for ; Wed, 24 Sep 2025 04:31:19 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62fa5f121f2sm12674695a12.28.2025.09.24.04.31.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 04:31: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: fd3bcab1-9939-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758713478; x=1759318278; 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=LPFDb3PbtCP5J2g852+Vzx93vzGoEbOujSKET5GEjgU=;
        b=luUXoBSeKX+vgs0QKGes7ZdA6qJwoYSJyf8/QdkkuBReH7dVcWC+cu0vqEf34ROgF5
         GX1TSXXZ2eSbBj9b3tXn05QOBbCV5qgeo/v8/nXvTgjej7uAWdgAejkpOFZ8DOUBKyog
         DcW1/u6zzjzEtIsg4Sl41WN+Dp7CgeM5I35HJXcGj/ZfDrNdbqh/HhJaUlsJGoCXeKyV
         ylEgpB2bwPriqOa4IKV+mfMJt+kRFJfeyHP/1GDUl2VmhPA2+2vBpz9o8MZPbeYfaFLe
         pHDZvBTqBI8hRY+sJEHeYP4ln9hGzqSpms7htz7C2vGs7mum3T6fR7TXCu5sWuyEjufM
         4lRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758713478; x=1759318278;
        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=LPFDb3PbtCP5J2g852+Vzx93vzGoEbOujSKET5GEjgU=;
        b=DIMFvmeqVunFVb9dP80awLbJN3qmXzEYYKT+iYm2S6yB08JPDOcO5HyjEsjx67mtAr
         yx32ZRQO2rOP16NCN/4E/K+lqIsjVGGItsZRHn3TnyUnXg4KBrF6X2r93qyKDO/jSKqL
         bODgOYFzEAfGulrTNImGDMrpILwInECztm9TgVWEpsjMw1wZ1KhLiqmmX6HXdvl0vcZt
         Y9Eu4rsZUtY/eFzZ2yscTBgE01bS3nzE20NKtVS+p2NrRaUbuKvtzWzjYWSeqHh0Sm4N
         2gwENXsFHiMCRy2iGu3c7sqnml3VXOGiP8DKjIxlbZy34yKqY3vFl+lgfRv+BHFS1Ofk
         pZlg==
X-Forwarded-Encrypted: i=1; AJvYcCW8tky87BeUfGAJ/G1jeJ4x6VDSgdAVYWrz+yk9hH2fTUDAZcRe/WWl5zTh98Z0vwLjHDejWp7zOfc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZX/BN2O/7xZYKmC71eJgl92YUhWFp22HTcf7FUgJ2x8MNgPrA
	/g+dA8UtxJNmoV9QLxIbu5FmhX/hW9WQXTPDXXU7afHvb4rywryt+2eV
X-Gm-Gg: ASbGncvyIOt1a2fl/2Bd0TPo9ywg5FStbOZ/dFRa2impWd6Q88/Qsyj4FciXk0C27dQ
	lMk9OgvSw2SNBgimdvTxw7BcgdGqdl75tP10NAVKHWe3DXHlpqVCMtJ1XVKqEIXp7KQQiHhBNbL
	hmqUeO1dmEINXvC866LSTOwC1DRBnZ0cBVUZ0752QbwmEviWTPPg2KsDCca8DyZvphX6bZ5N1dA
	TTkPr8r/FMxNn8PRprzcWzp9XelfdSX5itLWNnhvvVF+vBnol5jxKgX3fG7m2ucT8ewGb7wRl7X
	CP45LBIfc55RwEVhRpKw6Dudw+toD/BHguwGamTnFH0S0ffTOJ/CQvZRS1pGNk2LHsUX5MLpme+
	GL6vVPnS/4AQv/A6VyZWHyKw8acK9XipSaxkF9JLtW8cIAvBphh/cXQBRw87vZyEgH7l443A2
X-Google-Smtp-Source: AGHT+IFcNa1vMx5+l6VzxZ2nObDBx+4GF2C0kd1VIk0Eikj2mNMYn0Rq7/I00cVr3UOrfdGrR4VnPA==
X-Received: by 2002:a05:6402:2690:b0:631:a0ed:6471 with SMTP id 4fb4d7f45d1cf-63467678a38mr4779058a12.2.1758713478155;
        Wed, 24 Sep 2025 04:31:18 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------d2qVW7ePvJk7iwiPY4HR0j6d"
Message-ID: <0c4e446b-abe1-481c-91a6-60a49459b486@gmail.com>
Date: Wed, 24 Sep 2025 13:31:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/18] xen/riscv: detect and initialize G-stage mode
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: 
 <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/18/25 5:54 PM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -0,0 +1,91 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +unsigned long __ro_after_init gstage_mode;
>> +
>> +void __init gstage_mode_detect(void)
>> +{
>> +    unsigned int mode_idx;
>> +
>> +    const struct {
> static and __initconst.
>
>> +        unsigned long mode;
> Here and also for the global var: Why "long", when it's at most 4 bits?

No specific reason now. In the first version of this function they were used
directly to write a value to CSR register which is 'unsigned long'.
Considering that MASK_INSR() and MASK_EXTR() are used, 'char' should be enough
to describe mode.

>
>> +        unsigned int paging_levels;
>> +        const char *name;
> More efficiently char[8]?

I wanted to be sure that the name will always have correct length. But I agree
that char[8] is more efficient and a length could be checked "manually". I will
use char[8] instead of 'char *'.

>
>> +    } modes[] = {
>> +        /*
>> +         * Based on the RISC-V spec:
>> +         *   When SXLEN=32, the only other valid setting for MODE is Sv32,
> The use of "other" is lacking some context here.

I will add the following:
   Bare mode is always supported, regardless of SXLEN.

>
>> +         *   a paged virtual-memory scheme described in Section 10.3.
> Section numbers tend to change. Either to disambiguate by also spcifying
> the doc version, or (preferably) you give the section title instead.

I will take that into account in the future. For now, I think that this part
of the comment could be just dropped as here it doesn't matter what is a scheme
of Sv32.

>> --- a/xen/arch/riscv/setup.c
>> +++ b/xen/arch/riscv/setup.c
>> @@ -22,6 +22,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>   
>>       console_init_postirq();
>>   
>> +    gstage_mode_detect();
> I find it odd for something as fine grained as this to be called from top-
> level start_xen(). Imo this wants to be a sub-function of whatever does
> global paging and/or p2m preparations (or even more generally guest ones).

It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
when the latter is introduced.
Probably, I will move the current patch after p2m_init() is introduced to make
gstage_mode_detect() static function.

Thanks.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/18/25 5:54 PM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/macros.h>
+#include <xen/sections.h>
+
+#include <asm/csr.h>
+#include <asm/flushtlb.h>
+#include <asm/riscv_encoding.h>
+
+unsigned long __ro_after_init gstage_mode;
+
+void __init gstage_mode_detect(void)
+{
+    unsigned int mode_idx;
+
+    const struct {


      

      
static and __initconst.



      

        
+        unsigned long mode;


      

      
Here and also for the global var: Why "long", when it's at most 4 bits?

    

    
No specific reason now. In the first version of this function they were used
directly to write a value to CSR register which is 'unsigned long'.
Considering that MASK_INSR() and MASK_EXTR() are used, 'char' should be enough
to describe mode.



    

      



      

        
+        unsigned int paging_levels;
+        const char *name;


      

      
More efficiently char[8]?

    

    
I wanted to be sure that the name will always have correct length. But I agree
that char[8] is more efficient and a length could be checked "manually". I will
use char[8] instead of 'char *'.



    

      



      

        
+    } modes[] = {
+        /*
+         * Based on the RISC-V spec:
+         *   When SXLEN=32, the only other valid setting for MODE is Sv32,


      

      
The use of "other" is lacking some context here.

    

    
I will add the following:
  Bare mode is always supported, regardless of SXLEN.



    

      



      

        
+         *   a paged virtual-memory scheme described in Section 10.3.


      

      
Section numbers tend to change. Either to disambiguate by also spcifying
the doc version, or (preferably) you give the section title instead.

    

    
I will take that into account in the future. For now, I think that this part
of the comment could be just dropped as here it doesn't matter what is a scheme
of Sv32.



    

      

        
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -22,6 +22,7 @@
 #include <asm/early_printk.h>
 #include <asm/fixmap.h>
 #include <asm/intc.h>
+#include <asm/p2m.h>
 #include <asm/sbi.h>
 #include <asm/setup.h>
 #include <asm/traps.h>
@@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     console_init_postirq();
 
+    gstage_mode_detect();


      

      
I find it odd for something as fine grained as this to be called from top-
level start_xen(). Imo this wants to be a sub-function of whatever does
global paging and/or p2m preparations (or even more generally guest ones).

    

    
It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
when the latter is introduced.
Probably, I will move the current patch after p2m_init() is introduced to make
gstage_mode_detect() static function.

Thanks.

~ Oleksii

  


--------------d2qVW7ePvJk7iwiPY4HR0j6d--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 11:32:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 11:32:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129342.1469343 (Exim 4.92)
	(envelope-from )
	id 1v1NjV-0002Hz-MK; Wed, 24 Sep 2025 11:32:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129342.1469343; Wed, 24 Sep 2025 11:32: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 1v1NjV-0002Hs-If; Wed, 24 Sep 2025 11:32:25 +0000
Received: by outflank-mailman (input) for mailman id 1129342;
 Wed, 24 Sep 2025 11:32: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 1v1NjT-0002Hk-S1
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 11:32:23 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22093ac1-993a-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 13:32:21 +0200 (CEST)
Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com
 [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-563-1e7dVatdNqCk6R9CasEJ7A-1; Wed, 24 Sep 2025 07:32:18 -0400
Received: by mail-wr1-f70.google.com with SMTP id
 ffacd0b85a97d-3f44000639fso3576086f8f.0
 for ; Wed, 24 Sep 2025 04:32:18 -0700 (PDT)
Received: from ?IPV6:2a01:e0a:280:24f0:576b:abc6:6396:ed4a?
 ([2a01:e0a:280:24f0:576b:abc6:6396:ed4a])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3ee15bfab67sm24078831f8f.43.2025.09.24.04.32.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 04:32: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: 22093ac1-993a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1758713540;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=3wm4aQYa97ehJU5fswKMnk8HHXPm1syDq073s2wb1ds=;
	b=Ewqynfj1Cl/zGy4ektfXpRZ3jpYGvR4dddq1k9ZIAEGeHytttrdRG49/h8Gbre+0UigTwJ
	dSpBMZ/FnsMbYbAybtBPcZqQZserg2ed1uOqczx71uRba9P0Ro60+QBqkYpqM8KOjAhRc8
	FdDicdOY0uFg+3iK4W8DCYTuqPcwuac=
X-MC-Unique: 1e7dVatdNqCk6R9CasEJ7A-1
X-Mimecast-MFC-AGG-ID: 1e7dVatdNqCk6R9CasEJ7A_1758713537
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758713537; x=1759318337;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3wm4aQYa97ehJU5fswKMnk8HHXPm1syDq073s2wb1ds=;
        b=f/zbuSFLkMIxEmZu0eSURzpoBFFrG6peJlSb8Xgj1n7Ej5a+eoRYvjY7tjDvpjbp0k
         BZ7TIXGz1g26uMx/oB31K5Kl0TJzBcqpjk/8fyE4h5RR/GYTVmEuFj+gNP+Rl3I4Mp/q
         vFLR5qLGttdlsQCpXTU6vpz/7vsIRgucxhJX85H0ITR1/EEmWtVQmX1KeDQn/qIV9D6J
         jsI58X/4LJOUmVzDu4Tfjvi9XgsQjwRGv5xuBowafBy5sQyTmPB7ma63UqiaR8l/uelV
         ZALLTnE3awExxMc2nm/P2gQCO8wH/7nqRpXcR60rWkRI+Uyx8dcRivtPaxk0MQXcBQoD
         x/kw==
X-Forwarded-Encrypted: i=1; AJvYcCWFVj5HBurkaOpfS0XhtLz1OOvAqIWbFhHhTM+MGRziEk1y3RmeDeyVn4bleEwdbVXgKUpH83X7j9s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPf+t0IwY39gjR6VFz7weU09LHLqub+GM59Uu0zxHJ+YMNihHN
	MadFkqyIm7wKalWTloacuyGxNw6knvSEJq3NcOOej8314zI3+ue+5FXmrLjADJg5CXB3HzzjrwD
	3+LWvBLhn03ZclrqlIc6zY5guqXMHHT9mKj3CmrGPyoBbAJT50jx5LoDwIQw1xHRVycQG
X-Gm-Gg: ASbGncuJ7+av7gmvZ7ojscOg484iG5sijCEUdiz376eFuD2w+uu9eVAU08jreqVo65C
	3gXYjy4rZNJKFi7UXioKvI2JTtddwy9S2VyOIVBCLczBxrst6NosxqhZgBEHN9/pnVncl/eCIhP
	o53/tF15sk0FEQcTSK1FFxcS00nDN5eWDCaglMXzyM37sNa/jntOjkEIMj+pyrfAd+8ZtK3VH2U
	waCASZ+c8S/DmdZ34mIScizhmt1Hz//ghnexes2vHz+tO+6jVUvEs+ygQ4B73zb4VNOOAn3w7b+
	UGVLeW8QSv6yO1Gg9zmSluYeR1U/8u2f6eIzdG5gMyLbRrS0F4mUUREASWpqIN2B3SKyjN4+TCE
	705Q=
X-Received: by 2002:a05:6000:2802:b0:405:ed47:b285 with SMTP id ffacd0b85a97d-405ed47c21bmr2970234f8f.58.1758713536871;
        Wed, 24 Sep 2025 04:32:16 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFoNAZLN+nDh03f9cXRCLX0UgIm+FEEbH1KWxZOtQMveos7vpMCeoUcTE8YA9R2fRZI1we1Gw==
X-Received: by 2002:a05:6000:2802:b0:405:ed47:b285 with SMTP id ffacd0b85a97d-405ed47c21bmr2970171f8f.58.1758713536387;
        Wed, 24 Sep 2025 04:32:16 -0700 (PDT)
Message-ID: 
Date: Wed, 24 Sep 2025 13:32:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 6/7] vfio: Do not unparent in instance_finalize()
To: Akihiko Odaki , qemu-devel@nongnu.org
Cc: Alex Williamson ,
 Paolo Bonzini , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 , Eduardo Habkost ,
 Peter Xu , David Hildenbrand ,
 =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 Richard Henderson ,
 Helge Deller , =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?=
 , "Michael S. Tsirkin" ,
 Gerd Hoffmann , John Snow ,
 qemu-block@nongnu.org, Keith Busch ,
 Klaus Jensen , Jesper Devantier ,
 Marcel Apfelbaum ,
 Nicholas Piggin , qemu-ppc@nongnu.org,
 John Levon ,
 Thanos Makatos ,
 Yanan Wang , BALATON Zoltan ,
 Jiaxun Yang ,
 Daniel Henrique Barboza ,
 David Gibson ,
 Harsh Prateek Bora ,
 Alexey Kardashevskiy , =?UTF-8?Q?Alex_Benn=C3=A9e?=
 , Fabiano Rosas ,
 Thomas Huth , Laurent Vivier ,
 Peter Maydell ,
 Aurelien Jarno , Aleksandar Rikalo
 , Max Filippov ,
 =?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
 Mark Cave-Ayland ,
 Artyom Tarasenko ,
 Alistair Francis ,
 "Maciej S. Szmigiero" ,
 Bin Meng , Stefano Stabellini ,
 Anthony PERARD , Paul Durrant ,
 "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
References: <20250924-use-v4-0-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
 <20250924-use-v4-6-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= 
Autocrypt: addr=clg@redhat.com; keydata=
 xsFNBFu8o3UBEADP+oJVJaWm5vzZa/iLgpBAuzxSmNYhURZH+guITvSySk30YWfLYGBWQgeo
 8NzNXBY3cH7JX3/a0jzmhDc0U61qFxVgrPqs1PQOjp7yRSFuDAnjtRqNvWkvlnRWLFq4+U5t
 yzYe4SFMjFb6Oc0xkQmaK2flmiJNnnxPttYwKBPd98WfXMmjwAv7QfwW+OL3VlTPADgzkcqj
 53bfZ4VblAQrq6Ctbtu7JuUGAxSIL3XqeQlAwwLTfFGrmpY7MroE7n9Rl+hy/kuIrb/TO8n0
 ZxYXvvhT7OmRKvbYuc5Jze6o7op/bJHlufY+AquYQ4dPxjPPVUT/DLiUYJ3oVBWFYNbzfOrV
 RxEwNuRbycttMiZWxgflsQoHF06q/2l4ttS3zsV4TDZudMq0TbCH/uJFPFsbHUN91qwwaN/+
 gy1j7o6aWMz+Ib3O9dK2M/j/O/Ube95mdCqN4N/uSnDlca3YDEWrV9jO1mUS/ndOkjxa34ia
 70FjwiSQAsyIwqbRO3CGmiOJqDa9qNvd2TJgAaS2WCw/TlBALjVQ7AyoPEoBPj31K74Wc4GS
 Rm+FSch32ei61yFu6ACdZ12i5Edt+To+hkElzjt6db/UgRUeKfzlMB7PodK7o8NBD8outJGS
 tsL2GRX24QvvBuusJdMiLGpNz3uqyqwzC5w0Fd34E6G94806fwARAQABzSJDw6lkcmljIExl
 IEdvYXRlciA8Y2xnQHJlZGhhdC5jb20+wsGRBBMBCAA7FiEEoPZlSPBIlev+awtgUaNDx8/7
 7KEFAmTLlVECGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQUaNDx8/77KG0eg//
 S0zIzTcxkrwJ/9XgdcvVTnXLVF9V4/tZPfB7sCp8rpDCEseU6O0TkOVFoGWM39sEMiQBSvyY
 lHrP7p7E/JYQNNLh441MfaX8RJ5Ul3btluLapm8oHp/vbHKV2IhLcpNCfAqaQKdfk8yazYhh
 EdxTBlzxPcu+78uE5fF4wusmtutK0JG0sAgq0mHFZX7qKG6LIbdLdaQalZ8CCFMKUhLptW71
 xe+aNrn7hScBoOj2kTDRgf9CE7svmjGToJzUxgeh9mIkxAxTu7XU+8lmL28j2L5uNuDOq9vl
 hM30OT+pfHmyPLtLK8+GXfFDxjea5hZLF+2yolE/ATQFt9AmOmXC+YayrcO2ZvdnKExZS1o8
 VUKpZgRnkwMUUReaF/mTauRQGLuS4lDcI4DrARPyLGNbvYlpmJWnGRWCDguQ/LBPpbG7djoy
 k3NlvoeA757c4DgCzggViqLm0Bae320qEc6z9o0X0ePqSU2f7vcuWN49Uhox5kM5L86DzjEQ
 RHXndoJkeL8LmHx8DM+kx4aZt0zVfCHwmKTkSTQoAQakLpLte7tWXIio9ZKhUGPv/eHxXEoS
 0rOOAZ6np1U/xNR82QbF9qr9TrTVI3GtVe7Vxmff+qoSAxJiZQCo5kt0YlWwti2fFI4xvkOi
 V7lyhOA3+/3oRKpZYQ86Frlo61HU3r6d9wzOwU0EW7yjdQEQALyDNNMw/08/fsyWEWjfqVhW
 pOOrX2h+z4q0lOHkjxi/FRIRLfXeZjFfNQNLSoL8j1y2rQOs1j1g+NV3K5hrZYYcMs0xhmrZ
 KXAHjjDx7FW3sG3jcGjFW5Xk4olTrZwFsZVUcP8XZlArLmkAX3UyrrXEWPSBJCXxDIW1hzwp
 bV/nVbo/K9XBptT/wPd+RPiOTIIRptjypGY+S23HYBDND3mtfTz/uY0Jytaio9GETj+fFis6
 TxFjjbZNUxKpwftu/4RimZ7qL+uM1rG1lLWc9SPtFxRQ8uLvLOUFB1AqHixBcx7LIXSKZEFU
 CSLB2AE4wXQkJbApye48qnZ09zc929df5gU6hjgqV9Gk1rIfHxvTsYltA1jWalySEScmr0iS
 YBZjw8Nbd7SxeomAxzBv2l1Fk8fPzR7M616dtb3Z3HLjyvwAwxtfGD7VnvINPbzyibbe9c6g
 LxYCr23c2Ry0UfFXh6UKD83d5ybqnXrEJ5n/t1+TLGCYGzF2erVYGkQrReJe8Mld3iGVldB7
 JhuAU1+d88NS3aBpNF6TbGXqlXGF6Yua6n1cOY2Yb4lO/mDKgjXd3aviqlwVlodC8AwI0Sdu
 jWryzL5/AGEU2sIDQCHuv1QgzmKwhE58d475KdVX/3Vt5I9kTXpvEpfW18TjlFkdHGESM/Jx
 IqVsqvhAJkalABEBAAHCwV8EGAECAAkFAlu8o3UCGwwACgkQUaNDx8/77KEhwg//WqVopd5k
 8hQb9VVdk6RQOCTfo6wHhEqgjbXQGlaxKHoXywEQBi8eULbeMQf5l4+tHJWBxswQ93IHBQjK
 yKyNr4FXseUI5O20XVNYDJZUrhA4yn0e/Af0IX25d94HXQ5sMTWr1qlSK6Zu79lbH3R57w9j
 hQm9emQEp785ui3A5U2Lqp6nWYWXz0eUZ0Tad2zC71Gg9VazU9MXyWn749s0nXbVLcLS0yop
 s302Gf3ZmtgfXTX/W+M25hiVRRKCH88yr6it+OMJBUndQVAA/fE9hYom6t/zqA248j0QAV/p
 LHH3hSirE1mv+7jpQnhMvatrwUpeXrOiEw1nHzWCqOJUZ4SY+HmGFW0YirWV2mYKoaGO2YBU
 wYF7O9TI3GEEgRMBIRT98fHa0NPwtlTktVISl73LpgVscdW8yg9Gc82oe8FzU1uHjU8b10lU
 XOMHpqDDEV9//r4ZhkKZ9C4O+YZcTFu+mvAY3GlqivBNkmYsHYSlFsbxc37E1HpTEaSWsGfA
 HQoPn9qrDJgsgcbBVc1gkUT6hnxShKPp4PlsZVMNjvPAnr5TEBgHkk54HQRhhwcYv1T2QumQ
 izDiU6iOrUzBThaMhZO3i927SG2DwWDVzZltKrCMD1aMPvb3NU8FOYRhNmIFR3fcalYr+9gD
 uVKe8BVz4atMOoktmt0GWTOC8P4=
In-Reply-To: <20250924-use-v4-6-07c6c598f53d@rsg.ci.i.u-tokyo.ac.jp>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: voN5DcSkEb90Cspy8x6PBWLgJbdc6keBsX94M7rzTsI_1758713537
X-Mimecast-Originator: redhat.com
Content-Language: en-US, fr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 9/24/25 06:37, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
> 
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
> 
> Signed-off-by: Akihiko Odaki 
> Reviewed-by: Daniel P. Berrangé 
> ---
>   hw/vfio/pci-quirks.c | 9 +--------
>   hw/vfio/region.c     | 3 ---
>   2 files changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
> index c97606dbf194..b5da6afbf5b0 100644
> --- a/hw/vfio/pci-quirks.c
> +++ b/hw/vfio/pci-quirks.c
> @@ -1159,15 +1159,12 @@ void vfio_vga_quirk_exit(VFIOPCIDevice *vdev)
>   
>   void vfio_vga_quirk_finalize(VFIOPCIDevice *vdev)
>   {
> -    int i, j;
> +    int i;
>   
>       for (i = 0; i < ARRAY_SIZE(vdev->vga->region); i++) {
>           while (!QLIST_EMPTY(&vdev->vga->region[i].quirks)) {
>               VFIOQuirk *quirk = QLIST_FIRST(&vdev->vga->region[i].quirks);
>               QLIST_REMOVE(quirk, next);
> -            for (j = 0; j < quirk->nr_mem; j++) {
> -                object_unparent(OBJECT(&quirk->mem[j]));
> -            }
>               g_free(quirk->mem);
>               g_free(quirk->data);
>               g_free(quirk);
> @@ -1207,14 +1204,10 @@ void vfio_bar_quirk_exit(VFIOPCIDevice *vdev, int nr)
>   void vfio_bar_quirk_finalize(VFIOPCIDevice *vdev, int nr)
>   {
>       VFIOBAR *bar = &vdev->bars[nr];
> -    int i;
>   
>       while (!QLIST_EMPTY(&bar->quirks)) {
>           VFIOQuirk *quirk = QLIST_FIRST(&bar->quirks);
>           QLIST_REMOVE(quirk, next);
> -        for (i = 0; i < quirk->nr_mem; i++) {
> -            object_unparent(OBJECT(&quirk->mem[i]));
> -        }
>           g_free(quirk->mem);
>           g_free(quirk->data);
>           g_free(quirk);
> diff --git a/hw/vfio/region.c b/hw/vfio/region.c
> index d04c57db630f..b165ab0b9378 100644
> --- a/hw/vfio/region.c
> +++ b/hw/vfio/region.c
> @@ -365,12 +365,9 @@ void vfio_region_finalize(VFIORegion *region)
>       for (i = 0; i < region->nr_mmaps; i++) {
>           if (region->mmaps[i].mmap) {
>               munmap(region->mmaps[i].mmap, region->mmaps[i].size);
> -            object_unparent(OBJECT(®ion->mmaps[i].mem));
>           }
>       }
>   
> -    object_unparent(OBJECT(region->mem));
> -
>       g_free(region->mem);
>       g_free(region->mmaps);
>   
> 

What about vfio_subregion_unmap() calling object_unparent() too ?

C.



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 11:50:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 11:50:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129361.1469352 (Exim 4.92)
	(envelope-from )
	id 1v1O0j-0005Pc-7w; Wed, 24 Sep 2025 11:50:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129361.1469352; Wed, 24 Sep 2025 11: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 1v1O0j-0005PT-5V; Wed, 24 Sep 2025 11:50:13 +0000
Received: by outflank-mailman (input) for mailman id 1129361;
 Wed, 24 Sep 2025 11: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 1v1O0i-0005PG-07
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 11:50:12 +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 9fd85506-993c-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 13:50:11 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-46e1e318f58so17202605e9.2
 for ; Wed, 24 Sep 2025 04:50:11 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2a9ac5basm35884395e9.7.2025.09.24.04.50.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 04: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: 9fd85506-993c-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1758714610; x=1759319410; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=w4NUC+z63X17U9VukrJh/ccZd6HBxfTIkH8sGzGx5f0=;
        b=TRfCaJ9hZV6H0eQwtVHwvef94UeVOpwLRgUSsASHbFG9LUJMaIjjRomv3wklIbP/qV
         GtOr3O11moZCtcEs5rONXGC0RJCfjCViNfn0K0tJA2VhHiwetOnsAQFdSHN27Lz9DqUr
         4ztM3kHKmB/TqJ8NThRKQJs+YDYWoLDIPqQiU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758714610; x=1759319410;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w4NUC+z63X17U9VukrJh/ccZd6HBxfTIkH8sGzGx5f0=;
        b=jN2eWVOEMldt2gAHbkQwWkystSDw0g5eW8f3naEuuhdjvsauWCfkHv2wXQDId2eZRE
         N8o00Tpn8Mw0dIawzV7tAxtsLICPQ9QpPatxG8oq10ZAQ/GDaMMi7bsA9GU6rZ4swU5w
         bnoVfSnI2BgjpbqB802cdn/yxJ4PCrHNyG9o/euLmffhobMJCLRf2UyQbjJJUn86ew0P
         wyhmGmBC6rmkscJ5XExFSEvj5OO6uB+/PzQWhQK6QkahU89JO+Wb4j0W3mjYgEPp6Ggp
         zk1Z4sU49JiB31Cs4r502FvMBbnudl2jcLjL7yTIgP9B+/k4OvcBeQE3HgQq9EN5Y0xx
         T4HA==
X-Forwarded-Encrypted: i=1; AJvYcCU8FmcB++BHt493+4ttD08GCRJ3iMGv2meOVWzLrBRjwSGzFVnzn7BD1KPLSBMHYDT4i3NQJMks1wY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwrC0aN7OOQdhMVfmgFdskXxdHwAgxW7OLT8fB6MC0nwfssxSMw
	AuU8Ab0AOd0ns5dE18Zew3DotlNYccSZn/vdJX3RrIdbDLWUboRcwGgZqm+kmTksoaY=
X-Gm-Gg: ASbGncv7QJCwrsOb5WRZ7YOk0JJHHA6/7qB5Mwowz1S7m/bd6rsBOcPDo7Du4ikIDg6
	OAaVrISb9LG2/ORRVfk1sJk1MgDqKc0wIDqdsJwHEwplmzwDP3kab/CT4GPhRrG4foq8X+PFW6R
	Iu3Wy2X/LXSojkrtPki1YYuRudh/DVtG8n0f1+/z0IgcaQRqnK94blICl/+yCEwllP31IOsHRZN
	zkodtFNVIK3lzm2tzpcZ1bkWz//Pv5eJr+RgESvyLv2TPuMZ+8KRtkvgG7aEUF2CoXMuBJcv5VK
	ABEhLPDZnoHO3/ZOosRsBclozPUnZmCPrGPR0JA7Lsj+J6jPm0XPo2vHVg5Q0s8tsFqiEX6iFdU
	ifCUEpwgXN2TTYL41CpBQ80GDTFfwjJ6FV7VH39x11dXCa6f/n1ZWJuacnxATsXZl9C4k
X-Google-Smtp-Source: AGHT+IHgx3vivsXPC3nEl5EvQKu276zSNzNPLu04iQtOsxUzKjcliAZOzbj+64dlkAlS2tIKkVeb0w==
X-Received: by 2002:a05:600c:1ca5:b0:468:9798:2043 with SMTP id 5b1f17b1804b1-46e1dabf75bmr70088985e9.26.1758714610245;
        Wed, 24 Sep 2025 04:50:10 -0700 (PDT)
Message-ID: 
Date: Wed, 24 Sep 2025 12:50:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: oleksii.kurochko@gmail.com, Jan Beulich ,
 Andrew Cooper 
References: <20250924110051.2160-1-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: <20250924110051.2160-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24/09/2025 4:00 am, Roger Pau Monne wrote:
> Otherwise the check for the SS feature in
> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
> X86_FEATURE_XEN_SELFSNOOP never being set.
>
> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
> identify_cpu(), because SS detection uses boot_cpu_data.

Doesn't this, mean ...

>   However that
> creates an imbalance on the state of the BSP versus the APs in the
> identify_cpu() code.
>
> I've opted for the less controversial solution of populating FEATURESET_1d
> in generic_identify(), as the value is already there.  The same is done for
> the AMD faulting probe code.
>
> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
> Signed-off-by: Roger Pau Monné 

... this Fixes tag is incorrect?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 13:13:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 13:13:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129390.1469362 (Exim 4.92)
	(envelope-from )
	id 1v1PJQ-0006m0-4J; Wed, 24 Sep 2025 13:13:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129390.1469362; Wed, 24 Sep 2025 13: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 1v1PJQ-0006lt-1B; Wed, 24 Sep 2025 13:13:36 +0000
Received: by outflank-mailman (input) for mailman id 1129390;
 Wed, 24 Sep 2025 13:13: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 1v1PJO-0006lm-Tt
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 13:13:35 +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 4190f18f-9948-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 15:13:28 +0200 (CEST)
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com (2603:1096:604:2d7::7)
 by OS9PR01MB12454.jpnprd01.prod.outlook.com (2603:1096:604:2e7::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Wed, 24 Sep
 2025 13:13:22 +0000
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1]) by OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1%7]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 13:13: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: 4190f18f-9948-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j9iGc+6x1qRpShhre/pPxlycMeKMvtOKvUpMDB0znyEhJ47dTzRMMgDuCvNKFAoG5C+IDtN1xSEm1XiYOtNi1MzRyie+Nuj1FVm9YrXMekbwd4NcZcgj6ug5HpQTWSfuP7e6dNtl2kA1EipbgavzG1rlT4W012N5Xzh8OdYOCpMNxjD5ime5UM4B9MBb+x54cK0w2KEE0B+WY07gvtZ5/DSFVQMiUMwXcmyCa4yuN2mn7GTlGCIPpZEyi3XdXALl4vyACRTnCKCsr9Gan4uUrLTTeaz7yHJyabixj4CQPlKIfBG/YlTmBHTIlxRXL3Urh2ZhNeYiz95PjzsmFfdZpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KNBc339dmDuvSur9RcpUtIUmh2SjL42Vj0uSxaKWbi4=;
 b=cRkmHsAWRX2GyHTLW086Ft13S6v3GWk0v6rEW7g8zDQyWBW5rhpS1/W2iW84aUWZs0D3Z+tAylvghbGE46HOF6LQgAuaP7Ch1vOgwk1tVJ8mQe3VqgzoRxlsBrZUlDPvvBfNK/ZnJZJLiI+AoetEKL3CEiUR8n6vdPliglBBiwBK+pOqFPLFZ5ixMi9/MKSa6rRW/w+jMyjZccrRUSmtd5tjMnXwKNQ9pYLl5YeL+QNcn4XI7DfD5iSObIdbQwL7rUEpBEbtgfrRRZ+DS05RT79pQuXRSeNg0IAStH/pTKHPeY9nYTY7nCYGWUpjhv0KNPQRSgqXzRb7TTU24QZ3aA==
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=KNBc339dmDuvSur9RcpUtIUmh2SjL42Vj0uSxaKWbi4=;
 b=Xx/JwKG1XzpNjomZZAktLpYBOCGtBc+SMt5RxCNefIXhjyQnco8lqsEIb94Qc/6gTvTmyoyef9LsVrYGO/rC+wYCdFOIHy/oOlgVRishO/qA7vhNedmEkBPkjInOJ+PbH1bd/XzMgh4Tb3jPuJlAiGrZewfw0RDZ8n6uQMkf+Vg=
From: Jahan Murudi 
To: Anthony PERARD 
CC: "xen-devel@lists.xenproject.org" , Jahan
 Murudi 
Subject: RE: [PATCH] docs/xentop: Add documentation for physical CPU
 monitoring feature
Thread-Topic: [PATCH] docs/xentop: Add documentation for physical CPU
 monitoring feature
Thread-Index: AQHcHcD1JxP+jqaKQEWwakPuid7f3bSibgcA
Date: Wed, 24 Sep 2025 13:13:22 +0000
Message-ID:
 
References: <20250904172525.2795998-1-jahan.murudi.zg@renesas.com>
In-Reply-To: <20250904172525.2795998-1-jahan.murudi.zg@renesas.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_|OS9PR01MB12454:EE_
x-ms-office365-filtering-correlation-id: ec2e652c-0706-4ff4-978a-08ddfb6c235d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?DIyXbjpyZn5vvTjv1ufOudaWnQ1ywsQfWUf1aIbFdPYOhAAmhRE4ES++bhvB?=
 =?us-ascii?Q?0+IoA9ouKzW/asJTIccdb3QowHrOxkeLzFBijf9G6TgC09XM0McdPPsZ7eS8?=
 =?us-ascii?Q?28hWNWh5WhCJrXQkjSJOxEhrXkEWpKAypkbA02LEi6MsAo3cKkJNzOuqzpJ0?=
 =?us-ascii?Q?hOEFZg23wdcB7NcejanInp5aYnn6zv/0Qt/bdjSocc6JZnt9yRGNkq0yWt22?=
 =?us-ascii?Q?va4OGtgv8xBQzPVUPCkd/vNY4LK/kmCQR66y+uMzdcKk5L3wvFHCK8N83i1h?=
 =?us-ascii?Q?GWauphKyvL0lH+/E2ZhvaO3ttmg1PwYHsXwpK80CtcFiSMyoR67UmO1axO5K?=
 =?us-ascii?Q?TxdtUQ5UuFtX9ffsK88vyLSZtamXVxwmSxjzcEQvZXRc2clrsYnhCe3v1euX?=
 =?us-ascii?Q?OIEMPKa5QjdwJQXC/2FUVnq0O9QYxor6QhhVNTc9ZecqRAJh2qCXANI9O2ga?=
 =?us-ascii?Q?LHUlx/tUC4MXWAUvNN1WgbrgwKxfztNEzl+aTyPfoT1VMb/CjNWWK9Dfa30/?=
 =?us-ascii?Q?sXqeG7Xw45iMuLO0UiD4z8UiNaF1UK5/mzwlcqkT1oUhmn/8c9zjt88pcCnR?=
 =?us-ascii?Q?J7EIWJMdeGD+nI64oFZA6P5uoAtYTcSZoE/99erMzVU6GwIsfyGI0KnafFAi?=
 =?us-ascii?Q?gERoxwKl9YrpHLSORbNjBxOdy9uTjowP20P+Sdk7RG33LyrDsNhtEzYlC2Uw?=
 =?us-ascii?Q?ewXYsWGQXmOY0g+QJ9p+or6TUyv7457Dq8XrDCzq2Le0H2ps2hCNEs/d1Uta?=
 =?us-ascii?Q?96ltwN1XzgYmZ5SXN+UlrY2mXO+4rgpnsV2r8kBxc/Rpr+ACjr7OA4o66EOL?=
 =?us-ascii?Q?1z3nu6c0NcH+mAIlut3Z+zbwyBFyeZFMFkKA/978lRAMhA8knoLrbnDGGZ+3?=
 =?us-ascii?Q?+iS5rusipi+waFRHeM+IFcahB0B0vq+8QC7IBTeB8Fzds65UjYjsHcE2O4n4?=
 =?us-ascii?Q?LNZA5906n8l/p3f55pI1A/gIIe+gCML2+zDlMr73Nv7cP54ItORc8Q49se2F?=
 =?us-ascii?Q?C9gWotIMGo5azUSrhcDM6OaP8KXxhXnkATVZypttCGvPtWMhxt+9QqIlVH93?=
 =?us-ascii?Q?lOAkRuzLK4o6Jj9wI5kLIzMwCSsbxOBCTUxdShY03gXL3aELI5XAto1IcDP0?=
 =?us-ascii?Q?tm3d+wpU2GrVmJFyApENHB7qdRcnOZtFAOOp9rl0CACAXC5FzeiSq84zZFtW?=
 =?us-ascii?Q?vtCgIm3tOr0WH/0FWXaGolvtZPxNq5WZThVUGl9mLwkLRxyA+Z0hZelfRpQ0?=
 =?us-ascii?Q?rtX+nHH935PaxvUsXNniac10F6/M7z9LI0I5OHf46Qk2l0lLyA/xzfWVyvp2?=
 =?us-ascii?Q?p5VqRRpU777n7N0Vlo34ACqJGNMqQVXU8pk0E5Mgd2JGv+C9a9Rr/FWF9tjj?=
 =?us-ascii?Q?BgOUDXznTg2zVD07kgDR84RFo858zo5nqOpgdK1Vjw7c9MGQbI8DrNjKLr2Q?=
 =?us-ascii?Q?r+HsaZY7VkP+JBoY08K6CSPPzokiInIEpCWqcULDQLksr2xudU5+8A=3D=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)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?aN/07sTv3DQnMVa3mxxOPYScygxBvJWXfHW44Bp9u9kgiy8kCTJwaGWoGfvt?=
 =?us-ascii?Q?btbI4QQKb59Gye42yXX+h/hfq1WFWyOUd9qGOzDmyxPLXnUAB+5AdEkziLCn?=
 =?us-ascii?Q?7rvWpi7ahQhsVKu2bY03biuISoWDLVlbvqMpQzyYfnjsRWsB+4cqeMzB8tlG?=
 =?us-ascii?Q?coVs2GqqrrnxCHCbmYtBOtxswQzLvE7HsQM8BIJxvE18u0xGurChzCwETFng?=
 =?us-ascii?Q?phJxik6L8py1urLsz+z6dgujIcv1f8QKTZ8DvCy8PIAOz6TnylMSSueVXbO4?=
 =?us-ascii?Q?H+YMksoPnP49/y3A//n6oT249u7oaJQ/yKrYmTYdaCehlx61Egt0uO0CzbpP?=
 =?us-ascii?Q?Yj/UclKqfQjSDoD0nO1Uiw9X5L7eH0Rby98qqlWr6BhToHjKcCr1Xjch7J07?=
 =?us-ascii?Q?TDvBNZUrSzPJj3ZoyS1nxZndudHCpZ5bHCT1Iwdp8z0y756Q3Kvf5UMHfnOu?=
 =?us-ascii?Q?e6l88FU6URxQ3wTGJAq5vHSaaChnTgRpURvxbkXo1k9R6ZfALymlNnzJUfrh?=
 =?us-ascii?Q?tasCiZa2vHhHYnnAst+LmBDvIisPYIpkpLY6st8ZJ4HMNQO6tetZ+7gLgPvm?=
 =?us-ascii?Q?weRtIQq0up2l7cU9/GeoHH+l9ipd/HZHWUGXfomIExFZxVjZcvSYrJQiyd9w?=
 =?us-ascii?Q?R9+RFz+ij/C9fAz5j7rFlvD5bEqclR2BvMgjyNiqGv255qCJrZR9003rqDEy?=
 =?us-ascii?Q?JhDQLeNNf/guJmP9R9hbvxF2G/5uuMtyAG5ol0xsIx4h44v4FJTEPTzvm/kc?=
 =?us-ascii?Q?IKnrTiWtsCy4cH7ma5xUwAw/8McTF+AaHUVuzSjNNmPS60jYvhCKfECWaopa?=
 =?us-ascii?Q?dkQGZwIPmslCFU0RD4SFQffbM1bzhHaMI8Ie1lxSMUi1KgrYr6rLUaUkFBiY?=
 =?us-ascii?Q?M6l7yhhwYVTLQQNr6872nWXjbbcPRRkQ6YjGCSCA+gSXuOhMh0vJH6gBhiGm?=
 =?us-ascii?Q?r7cabPDP79cPih5oUztKdSHkd+3iZxtGpzfI4uLnoLsTf5Zq417dVCcX9Kcp?=
 =?us-ascii?Q?cuyTFpGgwLZeJqniFNk5pepEwGqVVcGzfIqIVYn3cQ8R1xzETbIzqDq+7o9A?=
 =?us-ascii?Q?PUlvdPmB62VLuq8tmsVevOKcufSkqHqy0W0yKSKJ7Am0g7yq92os7FvM7I4U?=
 =?us-ascii?Q?wyx17rYRJnOCE/9bMPRXnzuOcsQk0foEkt4GRAIwFCQ3CpQu0JNk2Gwb+0wl?=
 =?us-ascii?Q?CCeqwx7lCl4+p6jK+EpfaWaYh6fv5kuWCi66pqETMWeefhlNHd3HmKu0kpWq?=
 =?us-ascii?Q?5xSGgor9+1VB0wGFWAPqjJP0RRiL6FWC1Ldvd2mh1mu+zzCEL4uebIcSnZTn?=
 =?us-ascii?Q?yB3KvqKk1fT70kC2rj7PNXCdx+MMmDY31b5rVJIUzrglqdjZ2Q/zL91qdbuE?=
 =?us-ascii?Q?SdsFqGnVI77y5rY7853GqtsPGw9ROTX/HZTzMl3cdbtSbvNyPcjhAoqfnMIv?=
 =?us-ascii?Q?fLk0L5f39q/nfHNvfPXBW1EgC4ucUO6y7DAUa2/ZLuL3LY3zIEDT2RNCKmXH?=
 =?us-ascii?Q?3kH3FFoLAEMXR/1Ji/uKdXTVr4FR1mEO+TAWTuYNrB6YFLeQOcifT+GTIw3q?=
 =?us-ascii?Q?PqFsRPWGCd4CxM2rR12Ogk43a+ePrIPFb1xVdanp8XuxZ3YvC3Y4ts2BPF0a?=
 =?us-ascii?Q?Dg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: ec2e652c-0706-4ff4-978a-08ddfb6c235d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 13:13:22.4356
 (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: IxFFfmsOhynjMETkA2j2VpZzTVp4jVH1WGBXdqbSMEHHoQGnAoALzrWmwmh8v0DODvKTkSNrOEuXlsvkKekRrxZAD+G7N8vTk8bkJ8oruqk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9PR01MB12454

Hi Anthony,

Just a gentle reminder regarding the patch that adds man page documentation=
 for the new -p/--pcpus flag in xentop. If everything looks good to you, pl=
ease feel free to merge it. Otherwise, I'm happy to address any feedback or=
 concerns.

Thanks,
Jahan


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 13:30:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 13:30:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129404.1469372 (Exim 4.92)
	(envelope-from )
	id 1v1PZT-00016Q-FF; Wed, 24 Sep 2025 13:30:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129404.1469372; Wed, 24 Sep 2025 13:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1PZT-00016J-Bj; Wed, 24 Sep 2025 13:30:11 +0000
Received: by outflank-mailman (input) for mailman id 1129404;
 Wed, 24 Sep 2025 13:30: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 1v1PZS-00015u-4C
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 13:30:10 +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 95e1269f-994a-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 15:30:07 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id 55198EC01B1;
 Wed, 24 Sep 2025 09:30:06 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Wed, 24 Sep 2025 09:30:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 24 Sep 2025 09:30: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: 95e1269f-994a-11f0-9d14-b5c5bf9af7f9
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=1758720606;
	 x=1758807006; bh=513jZbBrdfpU61xZqq4wuE9Lce/OwZsVPgheNUmfSoY=; b=
	aRIp4rn3YbF/ufdqlaG8YYEiyHOUcGDljDsSFlBkT7AZfNbGrbfTdZZH3CFRgZFp
	hA7xWmJ1LasG10mj+sPDYbMlvBWgdxhiKdB5d7RrfKAJ+WU9XGanjYMgFnMTQs7c
	lCWHvoRQFmQkJ0V86xR7Hun6myOHSfj5PTka47OhZEboAZBwBrBs34S5q4oSG0sw
	iU0Ku5vyl3/vWX3N7eniuti2T4CdT10J1Idmo+AgdK1pvFbNcYOH3opCOSmsiwIj
	3JvIkiYrqJWsCXsi21ILTqONhv0dnVlbv6QVfDLce7P4imm/ndFkEnDShn7+DyTM
	Ejt1Tg3BWrPB3oNDUz52Bg==
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=
	1758720606; x=1758807006; bh=513jZbBrdfpU61xZqq4wuE9Lce/OwZsVPgh
	eNUmfSoY=; b=dw9MS/KQ9FfYzDdUMLqSYQV+uZxa+me3n1JgMYvrtN+Zcfp5t2A
	X+eSDYZYjucl8Q4n186BL0Zwy6ds/3jOnG2ftds/ZfrVNnlx3x0nc1AcH7NxL9bs
	1XAMjWznItkMpv5wiyXdPQNJ6WBqYqvgWjQhArX6r+t6y9SVbmtiH44qVfSRL7Ki
	dtOTys1hr0NU39vaRwlsGLahoMyvh0PiRBkgtN1I8GPZ+I+gaY+AKlT2EQyJJpxQ
	2hWdDrIB/efvg58VCQKPLe34Bq4UayKYWv5aTFkKg1ejQCP7BTSxPpzp9+VsShLC
	E343/Y4YJ2TVDe13zj2546ymI6LwCN61uYA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeifeejfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeukeetteeg
    gffgkeduheetgeeileejjeeiiefhjeegvefhtefggfetueetteeuteenucffohhmrghinh
    epghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm
    rghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsg
    drtghomhdpnhgspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht
    ohepghhrhihgohhrihhipghsthhrrghshhhkohesvghprghmrdgtohhmpdhrtghpthhtoh
    epjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehl
    ihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsshhtrggsvghllh
    hinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopeholhgvkhhsrghnughrpghthihs
    hhgthhgvnhhkohesvghprghmrdgtohhmpdhrtghpthhtohepsghorhhishdrohhsthhroh
    hvshhkhiesohhrrggtlhgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 24 Sep 2025 15:30:03 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Grygorii Strashko 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	xen-devel ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Boris Ostrovsky 
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16
Message-ID: 
References: 
 
 <05e9628d-83e5-4feb-881d-5854b72bd560@suse.com>
 
 
 <8f6b8f08-ca62-467b-a6be-4d33208e5393@epam.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="CW/IsT6ZQUUs61cd"
Content-Disposition: inline
In-Reply-To: <8f6b8f08-ca62-467b-a6be-4d33208e5393@epam.com>


--CW/IsT6ZQUUs61cd
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Sep 2025 15:30:03 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Grygorii Strashko 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	xen-devel ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Boris Ostrovsky 
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16

On Wed, Sep 24, 2025 at 01:17:15PM +0300, Grygorii Strashko wrote:
>=20
>=20
> On 22.09.25 13:09, Marek Marczykowski-G=C3=B3recki wrote:
> > On Fri, Aug 22, 2025 at 08:42:30PM +0200, Marek Marczykowski-G=C3=B3rec=
ki wrote:
> > > On Fri, Aug 22, 2025 at 05:27:20PM +0200, J=C3=BCrgen Gro=C3=9F wrote:
> > > > On 22.08.25 16:42, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > On Fri, Aug 22, 2025 at 04:39:33PM +0200, Marek Marczykowski-G=C3=
=B3recki wrote:
> > > > > > Hi,
> > > > > >=20
> > > > > > When suspending domU I get the following issue:
> > > > > >=20
> > > > > >       Freezing user space processes
> > > > > >       Freezing user space processes failed after 20.004 seconds=
 (1 tasks refusing to freeze, wq_busy=3D0):
> > > > > >       task:xl              state:D stack:0     pid:466   tgid:4=
66   ppid:1      task_flags:0x400040 flags:0x00004006
> > > > > >       Call Trace:
> > > > > >        
> > > > > >        __schedule+0x2f3/0x780
> > > > > >        schedule+0x27/0x80
> > > > > >        schedule_preempt_disabled+0x15/0x30
> > > > > >        __mutex_lock.constprop.0+0x49f/0x880
> > > > > >        unregister_xenbus_watch+0x216/0x230
> > > > > >        xenbus_write_watch+0xb9/0x220
> > > > > >        xenbus_file_write+0x131/0x1b0
> > > > > >        vfs_writev+0x26c/0x3d0
> > > > > >        ? do_writev+0xeb/0x110
> > > > > >        do_writev+0xeb/0x110
> > > > > >        do_syscall_64+0x84/0x2c0
> > > > > >        ? do_syscall_64+0x200/0x2c0
> > > > > >        ? generic_handle_irq+0x3f/0x60
> > > > > >        ? syscall_exit_work+0x108/0x140
> > > > > >        ? do_syscall_64+0x200/0x2c0
> > > > > >        ? __irq_exit_rcu+0x4c/0xe0
> > > > > >        entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > > > > >       RIP: 0033:0x79b618138642
> > > > > >       RSP: 002b:00007fff9a192fc8 EFLAGS: 00000246 ORIG_RAX: 000=
0000000000014
> > > > > >       RAX: ffffffffffffffda RBX: 00000000024fd490 RCX: 000079b6=
18138642
> > > > > >       RDX: 0000000000000003 RSI: 00007fff9a193120 RDI: 00000000=
00000014
> > > > > >       RBP: 00007fff9a193000 R08: 0000000000000000 R09: 00000000=
00000000
> > > > > >       R10: 0000000000000000 R11: 0000000000000246 R12: 00000000=
00000014
> > > > > >       R13: 00007fff9a193120 R14: 0000000000000003 R15: 00000000=
00000000
> > > > > >        
> > > > > >       OOM killer enabled.
> > > > > >       Restarting tasks: Starting
> > > > > >       Restarting tasks: Done
> > > > > >       xen:manage: do_suspend: freeze processes failed -16
> > > > > >=20
> > > > > > The process in question is `xl devd` daemon. It's a domU servin=
g a
> > > > > > xenvif backend.
> > > > > >=20
> > > > > > I noticed it on 6.16.1, but looking at earlier test logs I see =
it with
> > > > > > 6.16-rc6 already (but interestingly, not 6.16-rc2 yet? feels we=
ird given
> > > > > > seemingly no relevant changes between rc2 and rc6).
> > > > >=20
> > > > > I forgot to include link for (a little) more details:
> > > > > https://github.com/QubesOS/qubes-linux-kernel/pull/1157
> > > > >=20
> > > > > Especially, there is another call trace with panic_on_warn enable=
d -
> > > > > slightly different, but looks related.
> > > > >=20
> > > >=20
> > > > I'm pretty sure the PV variant for suspending is just wrong: it is =
calling
> > > > dpm_suspend_start() from do_suspend() without taking the required
> > > > system_transition_mutex, resulting in the WARN() in pm_restrict_gfp=
_mask().
> > > >=20
> > > > It might be as easy as just adding the mutex() call to do_suspend()=
, but I'm
> > > > really not sure that will be a proper fix.
> > >=20
> > > Hm, this might explain the second call trace, but not the freeze fail=
ure
> > > quoted here above, I think?
> >=20
> > While the patch I sent appears to fix this particular issue, it made me
> > wonder: is there any fundamental reason why do_suspend() is not using
> > pm_suspend() and register Xen-specific actions via platform_suspend_ops
> > (and maybe syscore_ops)? From a brief look at the code, it should
> > theoretically be possible, and should avoid issues like this.
> >=20
> > I tried to do a quick&dirty attempt at that[1], and it failed (panic). I
> > surely made several mistakes there (and also left a ton of todo
> > comments). But before spending any more time at that, I'd like to ask
> > if this is a viable option at all.
>=20
> I think it might, but be careful with this, because there are two "System=
 Low power" paths in Linux
> 1) Suspend2RAM and Co
> 2) Hybernation
>=20
> While "Suspend2RAM and Co" path is relatively straight forward and expect=
ed to be always
> started through pm_suspend(). In general, it's expected to happen
>  - from sysfs (User space)
>  - from autosuspend (wakelocks).
>=20
> the "hibernation" path is more complicated:(
> - Genuine Linux hybernation hibernate()/hibernate_quiet_exec()

IIUC hibernation is very different as it puts Linux in charge of dumping
all the state to the disk. In case of Xen, the primary use case for
suspend is preparing VM for Xen toolstack serializing its state to disk
(or migrating to another host).=20
Additionally, VM suspend may be used as preparation for host suspend
(this is what I actually do here). This is especially relevant if the VM
has some PCI passthrough - to properly suspend (and resume) devices
across host suspend.

> I'm not sure what path Xen originally implemented :( It seems like "suspe=
nd2RAM",
> but, at the same time "hybernation" specific staff is used, like PMSG_FRE=
EZE/PMSG_THAW/PMSG_RESTORE.
> As result, Linux suspend/hybernation code moves forward while Xen stays b=
ehind and unsync.

Yeah, I think it's supposed to be suspend2RAM. TBH the
PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE confuses me too and Qubes OS has a
patch[2] to switch it to PMSG_SUSPEND/PMSG_RESUME.

> So it sounds reasonable to avoid custom implementation, but may be not ea=
sy :(
>=20
> Suspending Xen features can be split between suspend stages, but
> not sure if platform_suspend_ops can be used.
>=20
> Generic suspend stages list
> - freeze
> - prepare
> - suspend
> - suspend_late
> - suspend_noirq (SPIs disabled, except wakeups)
>   [most of Xen specific staff has to be suspended at this point]
> - disable_secondary_cpus
> - arch disable IRQ (from this point no IRQs allowed, no timers, no schedu=
ling)
> - syscore_suspend
>   [rest here]
> - platform->enter() (suspended)
>=20
> You can't just overwrite platform_suspend_ops, because ARM64 is expected =
to enter
> suspend through PSCI FW interface:
> drivers/firmware/psci/psci.c
>  static const struct platform_suspend_ops psci_suspend_ops =3D {

Does this apply to a VM on ARM64 too? At least on x86, the VM is
supposed to make a hypercall to tell Xen it suspended (the hypercall
will return only on resume).

> As an option, some Xen components could be converted to use syscore_ops (=
but not xenstore),
> and some might need to use DD(dev_pm_ops).
>=20
> >=20
> > [1] https://github.com/marmarek/linux/commit/47cfdb991c85566c9c33357051=
1e67bf477a5da6
>=20
> --=20
> Best regards,
> -grygorii
>=20

[2] https://github.com/QubesOS/qubes-linux-kernel/blob/main/xen-pm-use-susp=
end.patch

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjT8lsACgkQ24/THMrX
1yzVCgf/RedEYV3RMxwKwUdKHRyb9e7+GwToxwOjxy8RRxMo7G3kiDU1JHwAbfvR
eRS9xAvoHhKnSKMd/xFlSkZlf0vf5Q+CrZay6ACNa7oUFLvXauBZCCtIOyC6kjUs
D3bK5PPYOotbsfR/MtgNdjoa7Lb3iJdIAEzAo1LO+7SUlob3RdUoNCNlcAHfuwnZ
vM5N85FkRF8G37CVvAKkI76vT8VnFAekT2gm2g/d4RAWvtSUAOQN8Ki1Ku1lJ3AM
6VUoGebLFjor+Km0S/ZmSy6bd2cIAqq+XV5NlRObwCOL0bNkdzqVETNLXjidn/76
owM4rVxzdyUI/VUnpJH7/tySz5tCRA==
=9U9s
-----END PGP SIGNATURE-----

--CW/IsT6ZQUUs61cd--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 13:41:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 13:41:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129417.1469383 (Exim 4.92)
	(envelope-from )
	id 1v1Pk9-0002nH-Dp; Wed, 24 Sep 2025 13:41:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129417.1469383; Wed, 24 Sep 2025 13:41:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Pk9-0002nA-AC; Wed, 24 Sep 2025 13:41:13 +0000
Received: by outflank-mailman (input) for mailman id 1129417;
 Wed, 24 Sep 2025 13:41: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 1v1Pk7-0002n4-Sh
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 13:41:11 +0000
Received: from BYAPR05CU005.outbound.protection.outlook.com
 (mail-westusazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c000::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1eefcde3-994c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 15:41:08 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by DS7PR03MB8242.namprd03.prod.outlook.com (2603:10b6:8:258::24) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 13:41:04 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 13:41: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: 1eefcde3-994c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WGp5xRP8rdErWWHznv5cdD3/cMjv4eMhT1XOWRHb4KSgeGe+f0ZHTDyvcy5dyPIFJICdjNk997Qo62mA/gky8Ln7CZ5B1aTZ6qimRkg1MDXLMmwIo44xvZ6RvMBbMiaD8t+JWTBMyxs35VudUnPeax0kNml+1Nikspv61zxNTzkDnK/vGFw8ulvET5acOfONz9lNHwntNsefqMyLZgneUnGnufLJq1Sog7rHf4Gr7UeLdadAVAE+Wv2tkzOYxJY0DHKGiJMo1oW79dMfNSLeo0qxj8MU3azQpavNaW/TrRsRtowqI6RlJwihDHzPNNuvFsVUY11g/4odlotDNYvPpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=v+xFrjZukHVrNFRXboPB7i891m4nPCVndE4tYppH4iU=;
 b=v8ngqyJOc2Doe+k+B8f5jYl54vfOnWBcueLMLtcYsRUNxjM8utykdk0SL8fEk9KGt4AjTuWcQSChcexj7semYnD7alU38FBsUd4bubNvOj4u0wHkNnVSpmGd9ebT9UTg0JvGsrWAB6BkDaaj+y751yjJ45Wr9Mx4L5WuEdTNwl7I0AHFvrB+Bpi2chc1dVTqeVyYUINWWsbfUdkjij/nZzJEojAEb0XgmDU/YjADJMAH8w37vPo8W/yexa3pfOWpaJeqnN5wz3+DQ2KyQhULu4vsiuppoN6GDYNOnvRjIRjig+A/EeE89Sy+8n06lU6PIYN9HOj5evZxD8dTjVyVoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=v+xFrjZukHVrNFRXboPB7i891m4nPCVndE4tYppH4iU=;
 b=MlL9afuxROLswXAdELu2hlTZue/d7l4US+5gdFdYAKtuLECDx6yLPx1RJDiXkjoG1sQ5H+Y8gChUhKU1DXfEwhUWwBIiMlXp1EzNlakyZxG/bVE/O47bleXQNy2vfydp7NAvkDn513/SEAsgUM61CaRVfHdrYzRH01dMw3e8PW8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Wed, 24 Sep 2025 15:40:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: "xen-devel@lists.xenproject.org" ,
	"oleksii.kurochko@gmail.com" ,
	Jan Beulich 
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
Message-ID: 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
X-ClientProxiedBy: PAZP264CA0071.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:1fd::6) To DM6PR03MB5227.namprd03.prod.outlook.com
 (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|DS7PR03MB8242:EE_
X-MS-Office365-Filtering-Correlation-Id: a1c8af9f-afb7-48b1-9efc-08ddfb700175
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?ZDBZWHZ6RTh0Nm5uL2NDUVlORHd5SWlHaEQ3RHhjSzhRTzgvSitHUDI0YzdT?=
 =?utf-8?B?VWpqRFVkbDBVYzFZWEJUZVpobmJvZ1pqWDFBVUgycUI4VElJYmUya2JPUkRj?=
 =?utf-8?B?WHZlYWg1WlFQQWJudDRaa2x3QWtTYnc3OTJwUnpXenE0Myt2TkRKSFpjQ3U4?=
 =?utf-8?B?eUVpa2M3R0c0RzVZbEpzemJBaEhUY0dGYnV3UUd6ZEU2Z3o0a3ZxeGs4T2pw?=
 =?utf-8?B?ek01eXRaZncwajYvY2Nmc3ZVNmlJVGdEdGQ2RDVSc0I5ayt4ZmdSN2pwUnRo?=
 =?utf-8?B?NVlRM1Fsci9RSVRuZlRuWm5xc0Jza1AyODlxdUFQcUVMSzVjdTlhS3B6QTRS?=
 =?utf-8?B?TW9sVFJNMVhQYVpTbTYxT1Qvak1qRk1BZFdHVEZiWGpwOVlWcm1hUzgrMlBB?=
 =?utf-8?B?WlZGM2c2Ly9MUXQzdXhjQm8rMXlCaVpmeHk5UUVVM3V3eURlaXRyNkExOVE4?=
 =?utf-8?B?enRScXd3ZEJ6SHVhR3NYUUlma3M2VHZ4VVVSVms0VkdCdlhLWjB0MU05UnZi?=
 =?utf-8?B?Z290N1Q2bDdLVHdVbUFVRG95ZjJ3c1R6aWNBSnVMOGJHeDB3eDBibmxJRzRG?=
 =?utf-8?B?U0ZqeFpjSmVEam5GTENibm1hcTRtbGhxZ3BtN3ZDSWJQRzZFdUdEK0pJb2tr?=
 =?utf-8?B?SzNjWG1aVjRtV0tQaW5TdzNwSzJxWVpITTBrZndDSTloLzByTXc0NDYrbzJT?=
 =?utf-8?B?S3dvTEFKa0FXM3F5QllVejg4dEFUYWtjUHN4WEhxWnR4N3VRMno3K1NCUFVP?=
 =?utf-8?B?YTRDN0RNc1BSSnFmWEMwK2VCOFRXczBlWW5QazMxMlJsQ050VXRSMDRxTThJ?=
 =?utf-8?B?dnd5dWZkZkRJRnZTdjlhRzlTOFR1S093elpwY3BuRnBkc1d1S0lGRW1KbzB4?=
 =?utf-8?B?MlpwcUJhZVZKT2tvM0FiQTFZMkQ1b0lGNW9SVWtxU2Jsd203b0IrTnR0M0NI?=
 =?utf-8?B?VGpwQk42K1FMa0J3R2hHSDdQSUhzRk9NRFV0bkF2T05DZHpSVkJ0Umk0elAy?=
 =?utf-8?B?b2VUNER4TDZ0U0t3ejdRaUxZajFhVkZNTXIybkorVjdmOFNpRHdORUdvUnZP?=
 =?utf-8?B?OHpxZ29lQlhPZTBTMFNHNFdiVjFReFBuM3AzdXZWY1RiSEZLdmltZWNBY0RC?=
 =?utf-8?B?dWxUS1dMcTA5SlA0OWJaaWhlZDZnUWMyTHBwY3NVSkk3Z2gwK3c1RGJJakxF?=
 =?utf-8?B?dHZtcUllOFRpTzdpcE9vTFV1L1dSdXZTS2tIMEdpMTljVGJ3dW9VZzduUWpE?=
 =?utf-8?B?MGF2TE1ocHpraEw5em5IckZDKytUd3I5cU1mRGxhQTh2ZzUvdURHV1pYRnJy?=
 =?utf-8?B?WG9Vb3NRYVd1S2pKMEw4QkRoeWZUd1FSM0VKbyt4b2JTNHhmTmpQaHVCTFEv?=
 =?utf-8?B?WnVGd0ExTVdQdXQ4dkZTZzhtS1NEd05QWW1CbzRtOHlnMG0rZjUyOHBhVCtO?=
 =?utf-8?B?S3JhR1ZWQTBtMnVSdWlveXZEUE4zV1hFSnBoL0ZmeHFmWCttekxoMDd3clZa?=
 =?utf-8?B?U2pwOXNmWWsxM2ZaUitpRno5dmFoY0VhbHY3Y0RjUWxSdCsrRG0vZnY3dlYz?=
 =?utf-8?B?YzRQWk05dnhWQjh1RGhpOGVueVQzTW5rUnNMOEo2YzY0NzJTK3ozcXpncU03?=
 =?utf-8?B?eFJQNXdaWmVzUVhrVDVOUFVCeUExL1o2RlNFVDkxMXNYZ1NEWlU4UVNIejlk?=
 =?utf-8?B?MVAvbUEvRFhzbW9sWW9IdE1FblFjMldMRVZZRTRKMzkyUlptTmd2K3hjQkpt?=
 =?utf-8?B?Y0grVDlhbTlrd1dlaTJrN1NyOUtvbjNtMzBmN2oxRTYwNmpzcGZ6NVBBOGRP?=
 =?utf-8?B?d1hkZWwvTWFnaCt3SHlXWkxIVEZGOG1WcklwZllldDZuOFloNkpaRUxTUWVx?=
 =?utf-8?B?c1Z6MEtqU0IyZzFMdEJheUZlWnIvWFhSQWdJWENKMGJVWXhuR1RnUjNBUmVY?=
 =?utf-8?Q?brqUQ0QEX5I=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MUR5eW80UVc3bnpMTExLYUdBdE11cmh6SGZ2eWdpNE9vbFIxUkpzOGdGQ1F6?=
 =?utf-8?B?ek5lSkpST1dNREg3MWNIaHdWVHhtcFE5MFF4OW5OWFFFTGlUV1JVYjJXNlJW?=
 =?utf-8?B?MSthNUE0NE5HZDFZeFQ4ZlZaMDF6ZVNaYVBpY1RzTzcxMVlJMFh0cytYYUtq?=
 =?utf-8?B?Q0hoMGQ3dTNCNFZsL1llSmFoaU03VG03QTFqUWMvTHBTeGpzQkZ6R2l0ZEYr?=
 =?utf-8?B?WVZFWmQwejVTZWdaaHlQUlo1VFV4R25zUis0SDl4bXA1TEhHU2c5V2I2eVNK?=
 =?utf-8?B?Qy8vNzExZ1VVcDZhclBnaHZobFdaNWU0aGFRYzA3RFZNOE9BcmR2U08zcm1K?=
 =?utf-8?B?bHJ4RFErd3RZcGFxTFpKNnpjTDM4OXhYWXRlOXN5K3lVcGZ5d1R0YksrYlQy?=
 =?utf-8?B?aGd6QWQ0QVlMV0Y0S3JGb3UyK3Rxd1JpdXdTQjBWeWZMTUM1Q0FTK2drYWtG?=
 =?utf-8?B?SndrVjNkUWVRZ0V1WGJTcWxuRi8vd0xnblNWMk14aE8rZitybTA3U0hXc0ky?=
 =?utf-8?B?eWRIc2luMmxYSDR4VE1lMEVodjFoWUl6aTFJWGlWU1lVRDJleXFCbFc2dFNK?=
 =?utf-8?B?Nlp0YlZzdG42cURFQ2hLdHBPVk4vclBRbXVTRmJTQ1JjWHNCSGxvSU5VVFVl?=
 =?utf-8?B?UVhsWSs3TWhhTHJCZWJUWStHTEcwNWxxUEhIZGkvWENyb2VtNFdLVUZyNVRw?=
 =?utf-8?B?RmJOL2Z2YmZvOEtZWlAvSW0rNFRUT2o2OWt6OEhIdVZtdlRFa2ZnM0ZEN3Zu?=
 =?utf-8?B?YWNiYTZ1V2xFRkRuQVVFUk9INmdLclpoK2xXZ1RMemY4Y2phMGMrWjltdDRO?=
 =?utf-8?B?TGpVT29OY3BPZldoTEZ2WkZYSW8yaTVxZXArdENva1A1amFwY0oxRktQcGdU?=
 =?utf-8?B?UXdSb0tJcmhETjR5QnR0UWM3L1VyMzNOa0xjYVJYbTJqTDh2aiszekRDTFJI?=
 =?utf-8?B?WXJidU0yRFE3REhsRGx5c0srWDJMNTBnN2xkZ2NiR1lHUDV0d0NjRE5wTS9x?=
 =?utf-8?B?eFZIajJJQkdPN0piM3ZKNW15NFdFMUlBcHkxSC9BK3dITi9rRWhCeUdRRVpL?=
 =?utf-8?B?YzdWdmw5cDE4eEMyL0ZIak9DUDNpYVVYZzA2M2NPZXZkWVBaY2xGS0owTHU1?=
 =?utf-8?B?elVaUWFpYWRuZnVTM2dLMDlYaWliVUMrcDMzZk9lUXNNVkxKQkZHVnNsOGs3?=
 =?utf-8?B?NjFsWmpWbnIrZlJpeDZpdVM0Y1R3bEhtRDhlR3NBTjF1b1dxbGZndFNsdThy?=
 =?utf-8?B?T2FQL0xzOXNzQW04SkFSSk1pWFUzQ2Qzdk84ZkdXSGF0Y0YzVzdlSmN2MzhT?=
 =?utf-8?B?bUtCUDVoQkpSWUFjTDBqVUFYdmdaTnlLeHh4WXByZFlOdnh6WUNGKzBYdHhs?=
 =?utf-8?B?UE5vVEZQUDZIc3VUY1ZEM2F0bmhaZlB1amZIZkNTbEZHUWlJaENZa0RzVU1l?=
 =?utf-8?B?R0hjRTM5dWhKRUJxeTJYRCtEdU5ESUxnMkR5OTRjUThQb2hzYWg3SWo1N3Zt?=
 =?utf-8?B?Znh2OTJOUlcrT3pob21CenZiTEVtZ3hoY1NBd2VvWEprOEtuN2Z1ZjViMHBx?=
 =?utf-8?B?aTdORTFFSkl2UEVwNk9PbFlNY1VQVHdHVC8zYjladnJlMGZOUU5LK1FjYkxE?=
 =?utf-8?B?N2NpMXY3M0UxZEZzd0VaTi81RVZxamRFdHVRLzgxT01pR0FUUkpFaEp0b1Q0?=
 =?utf-8?B?bVpCby9EQ3k1dDkvSGxONVBSTElaUUthZ1BaWTNvUHZzY1BDNHFJRWFuSzhn?=
 =?utf-8?B?N21lUlZHOU94Mk12cm42R2lpQXNUTThmRGJCWmQwdG9sejQ5dVh6VVVIMnFw?=
 =?utf-8?B?TVg5ZVg4ZTNTUHNWSzc1SnlJSU9QR1dERklQYW9iOHgwZExkOVdlMjQyTis1?=
 =?utf-8?B?UmhldzBNN2o3NEdiamE1NGcxZEtvbUl5WC9rY0JSSUoxSGd1Z0YrSXZNQUJ6?=
 =?utf-8?B?WGVGSDZhZm0wN1E2cVpmVlptVExnTFF5RXFFVnM4aENjenZkTTV4Y2MwMWlU?=
 =?utf-8?B?Uy9tdFZVYllSMmdMdEM4UkdZSjhvRjB3dmh1WXpGUEplM0lQaEpUSkhmSVRn?=
 =?utf-8?B?UFk3ZW1QQk42b2ZwdnJLdHg5SldxdStyOHAyWTY4Q0pSTXNRcFI2UE1qdHVr?=
 =?utf-8?Q?daQQinxPnDnt1ecfgwuPV5sX6?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a1c8af9f-afb7-48b1-9efc-08ddfb700175
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 13:41:04.3541
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: r9rowoA/eOtmraM2nSgKpyXTuyzEySk1S58lHfESJoKXo9+HGnKGKB2CrKmIFQ8bF6eJwfRmDwzlo4tGhlO3cA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB8242

On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
> > Otherwise the check for the SS feature in
> > check_memory_type_self_snoop_errata() fails unconditionally, which leads to
> > X86_FEATURE_XEN_SELFSNOOP never being set.
> >
> > We could also avoid this by not doing the reset_cpuinfo() for the BSP in
> > identify_cpu(), because SS detection uses boot_cpu_data.
> 
> Doesn't this, mean ...

Well, that's the reason for the rant here.  The reset at the top of
identify_cpu() has been there since 2005.  It's arguably to make sure
the BSP and the APs have the same empty state in the passed
cpuinfo_x86 struct, as for the BSP this would be already partially
initialized due to what's done in early_cpu_init().

The underlying question is whether we would rather prefer to not do
the reset for the BSP, but that would lead to differences in the
contents of cpuinfo_x86 struct between the BSP and the APs.  In the
past we have arranged for leaves needed early to be populated in
generic_identify(), like FEATURESET_e21a, hence the proposed patch
does that for FEATURESET_1d.

> >   However that
> > creates an imbalance on the state of the BSP versus the APs in the
> > identify_cpu() code.
> >
> > I've opted for the less controversial solution of populating FEATURESET_1d
> > in generic_identify(), as the value is already there.  The same is done for
> > the AMD faulting probe code.
> >
> > Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
> > Signed-off-by: Roger Pau Monné 
> 
> ... this Fixes tag is incorrect?

I think the Fixes tag is accurate; the code was OK before that change.
Nothing in c_early_init hooks depended on (some of) the x86_capability
fields being populated, which is required after the change.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 14:25:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 14:25:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129440.1469393 (Exim 4.92)
	(envelope-from )
	id 1v1QRB-00084i-NL; Wed, 24 Sep 2025 14:25:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129440.1469393; Wed, 24 Sep 2025 14:25: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 1v1QRB-00084b-Jh; Wed, 24 Sep 2025 14:25:41 +0000
Received: by outflank-mailman (input) for mailman id 1129440;
 Wed, 24 Sep 2025 14: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 1v1QRA-00084V-7r
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 14:25:40 +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 573647d8-9952-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 16:25:38 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-b2ee3c13aa4so424988766b.3
 for ; Wed, 24 Sep 2025 07:25:37 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b2636394de6sm1223271166b.39.2025.09.24.07.25.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 07:25: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: 573647d8-9952-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758723937; x=1759328737; 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=KstcK8ZG6CA6t+q9gqOKzR7wqHg3pnJye8/K8xAI22U=;
        b=Z4Q5xBhB4sDofUxflAckYnNXjYeZQ4PKpLUKBHAjt4oikhhgcqlxdLEXr6mWVVS9GY
         IJCcS3q4JMnetLoVQccqBBlBLIn2O2gGH7HwXxMYJo41+CxMUH9b5wdJG/FWITqUzD/T
         5rjtQJ9lCgHaxY0LvYiVllVFJ78ZmLO4H69gb3VPTlzstgBTqtOd8oVVeDZNmx2vksrP
         u5hjU+fRzGE1bzTHDtG6uJW7hMLkCMaHLq4Fza/TPI2SzMCWmZwOE1MZkfrySr4oy6xv
         YePFf5+Q5RWy10aE3DGuR9l7+JHYR/SsCWJq7ySN6+ro+izEV+sWq0iCpMcUOnUqLfHU
         6T6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758723937; x=1759328737;
        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=KstcK8ZG6CA6t+q9gqOKzR7wqHg3pnJye8/K8xAI22U=;
        b=H2CA4lMiwM8frqJd0brKltzDa37gR7va+npmiGxu3Jcv6Vi1hISZ/oSUn3ohc0vCM5
         KMwBDOxymUKlr0trAuu/fPaNYzOhSH9J/RpIz/QgMIs/3Kjt9Xce/SoEEfgzPh2GpOw9
         kk+LceTLlP0PqEsFGwPsCohFsYlkBNlRJqKeBO4JkU9enCjctu+xNKNxQwHoS0rJFt7E
         6b6WAQoja8XuuJPcVHkHrHPY73tJOTSFEIJbh8vwYT+RpLF0Q0iGPTSEAAjNagMS5+la
         2Bvbg9ii1NXZID/1KDmPhadzH2Q1X/oRfolowKJNECZBtUz47EviW+p8EoT/Ly6zJZq3
         aj8g==
X-Forwarded-Encrypted: i=1; AJvYcCWl9RM200SSGg6uOY8QRQunKl97FFsSLn3F4sKYD//JIs7MEaK0S0rjfVS3FafvLWfZqZtrFz5DmEg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhWMDxhKM79KhLKqrVjKU30JXYHrl+zulOzO/00C+51QBQ4zVz
	1ko8YFLvU32u0e3IvJTdt0QoNyahMD6LtRQwr9DpudNfI78rjogsD5Fp
X-Gm-Gg: ASbGncsNNK5YmAQ8s4VxMD3YPDBmCOp+51W1zK8fiNZ9PLT0x7HSlusJUOnZweeJR/A
	T4d7TZW3qkczlbVZmPBf+vuR9HtvVa1dVHfCBj5Oe8YFK3o2EefiMvy7aSnKrp9XyXxADBEl6EF
	wd6MUOooRw2I1+YmVH4VeMFmx6B8WDECbKbHMN5pnwTTA2WKPdylEIcMfGQ5J7Owho9yyFGJdz7
	Q0LYp3mW5XX2lBUhPMFusohq0kEfbOHfNl5OnuayIpKtQnBGjQ/iz04wacQN3f+etWxVciZ3n+3
	D0wHKaTTrhVX+cpXtGDr7F+ra0tf5Tt8ikS/kZ/o0Z6a1dDzuhSmScDy7+pWTJWJsj+bH7qbSoo
	BFoPDQiEWLstEs04DbBKCmJC1i7nD0dKlJ2HSGTjtpEttxhpwBELNlOz2F7PPmDIhF+0eYHhs
X-Google-Smtp-Source: AGHT+IEq3qGGBqynw9iYKp7Zxm2ZZGeVftR1bzziQ4fPNmPhGYbWkaXK06UC9wwpE0FFUdjuMHb9xg==
X-Received: by 2002:a17:907:9447:b0:b30:880:8d50 with SMTP id a640c23a62f3a-b34bad22678mr2548966b.21.1758723937002;
        Wed, 24 Sep 2025 07:25:37 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------60CPG0me079SX3gr2E7yEmVM"
Message-ID: <1be98c7f-59ff-4808-957c-daa55d1f441d@gmail.com>
Date: Wed, 24 Sep 2025 16:25:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v4 02/18] xen/riscv: introduce 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: 
 
 <03c68390-fd9b-443b-a012-2846dda2a923@suse.com>
Content-Language: en-US
In-Reply-To: <03c68390-fd9b-443b-a012-2846dda2a923@suse.com>

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


On 9/19/25 11:26 PM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> @@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>   
>>       gstage_mode_detect();
>>   
>> +    vmid_init();
> Like for the earlier patch, I'm not convinced this is a function good
> to call from the top-level start_xen(). The two functions sitting side
> by side actually demonstrates the scalability issue pretty well.

In the case of vmid_init(), it could be a good place to call it here since
vmid_init() is expected to be called once when a pCPU is booted. For the boot
CPU, all "setup" functions are called in start_xen(), so vmid_init() could
potentially be called there as well.

For other (non-boot) CPUs, vmid_init() could be called somewhere in the
__cpu_up() code or at the CPU’s entry point.

>> --- /dev/null
>> +++ b/xen/arch/riscv/vmid.c
>> @@ -0,0 +1,193 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Xen command-line option to enable VMIDs */
>> +static bool __ro_after_init opt_vmid_use_enabled = true;
>> +boolean_param("vmid", opt_vmid_use_enabled);
> Is there a particular reason to not have the variable be simply opt_vmid,
> properly in sync with the command line option?

There is no a specific reason for that, just made it in sync with x86.
opt_vmid could be used instead. I will do s/opt_vmid_use_enabled/opt_vmid.

>> +void vcpu_vmid_flush_vcpu(struct vcpu *v)
> An reason to have two "vcpu" in the name?

The first "vcpu" should be really dropped.

Thanks.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/19/25 11:26 PM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
@@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     gstage_mode_detect();
 
+    vmid_init();


      

      
Like for the earlier patch, I'm not convinced this is a function good
to call from the top-level start_xen(). The two functions sitting side
by side actually demonstrates the scalability issue pretty well.

    

    
In the case of vmid_init(), it could be a good place to call it here since
vmid_init() is expected to be called once when a pCPU is booted. For the boot
CPU, all "setup" functions are called in start_xen(), so vmid_init() could
potentially be called there as well.

For other (non-boot) CPUs, vmid_init() could be called somewhere in the
__cpu_up() code or at the CPU’s entry point.



    

      

        
--- /dev/null
+++ b/xen/arch/riscv/vmid.c
@@ -0,0 +1,193 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/domain.h>
+#include <xen/init.h>
+#include <xen/sections.h>
+#include <xen/lib.h>
+#include <xen/param.h>
+#include <xen/percpu.h>
+
+#include <asm/atomic.h>
+#include <asm/csr.h>
+#include <asm/flushtlb.h>
+#include <asm/p2m.h>
+
+/* Xen command-line option to enable VMIDs */
+static bool __ro_after_init opt_vmid_use_enabled = true;
+boolean_param("vmid", opt_vmid_use_enabled);


      

      
Is there a particular reason to not have the variable be simply opt_vmid,
properly in sync with the command line option?

    

    
There is no a specific reason for that, just made it in sync with x86.
opt_vmid could be used instead. I will do s/opt_vmid_use_enabled/opt_vmid.



    

      

        
+void vcpu_vmid_flush_vcpu(struct vcpu *v)


      

      
An reason to have two "vcpu" in the name?

    

    
The first "vcpu" should be really dropped.

Thanks.

~ Oleksii


  


--------------60CPG0me079SX3gr2E7yEmVM--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 14:28:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 14:28:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129454.1469403 (Exim 4.92)
	(envelope-from )
	id 1v1QU0-0000Cw-3S; Wed, 24 Sep 2025 14:28:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129454.1469403; Wed, 24 Sep 2025 14:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1QU0-0000Cp-0b; Wed, 24 Sep 2025 14:28:36 +0000
Received: by outflank-mailman (input) for mailman id 1129454;
 Wed, 24 Sep 2025 14:28:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1QTz-0000Cj-FI
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 14:28:35 +0000
Received: from mail133-23.atl131.mandrillapp.com
 (mail133-23.atl131.mandrillapp.com [198.2.133.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bd23b7ed-9952-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 16:28:29 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-23.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4cWzjS05gzz35hVPZ
 for ; Wed, 24 Sep 2025 14:28:28 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 a98839dc42fd49e79c01c9d6a6713886; Wed, 24 Sep 2025 14:28: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: bd23b7ed-9952-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1758724108; x=1758994108;
	bh=I3lFFSoa02TJXzdxyNLeFataHBQIEM+VA7FdOYdTGzQ=;
	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=ZOUZRMpmLkdO1QegQ0USalxi3k1pmErBU+3BqH0Ma2nZuoReX+N93X4i8hSTDCZx6
	 PcYvL6byTkU+OtDqeWoOhqb1hPjWC6aN9juGmfuoEyp5CrQObe5w1yDJ3Xfxd/5d3f
	 ACHB4+SgDTt/3il4InfxY1LhvXXEG1fBjxpjUzGpEkCDc8PZzuTTyIfZ3Xigxye/qH
	 +QmslABbTgkrEaxeK+lTBx0jh4S5nHVsdnHfI7nKm2rUPHkKKZ6XIkvGMMlNI6OkpR
	 vci3aKyN7PuQXqg9p9m2Gx9wUQ7DvIh+azDainA7cgUasIwireO6WoIE6ssOFuWUSA
	 qVD5FDEZ3BafA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1758724108; x=1758984608; i=yann.sionneau@vates.tech;
	bh=I3lFFSoa02TJXzdxyNLeFataHBQIEM+VA7FdOYdTGzQ=;
	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=by28HNSZYj3NH10USQ65ibm0C+ykRx8PLtWOhpqGLfedbyR6eRtFoqbX/2Wxujn4e
	 voDwSHWabxpcuojLIODr/1ggsKR4a6LARnTVpj0WVQUpaQJ6olP5SlOvrNsJIEHm7k
	 tgjZIubxjeYOSdI/qrbakEJxzvxPhbee4GTaZA/A5Nh0bdSAHWjXOieoSmOumuzCCc
	 hg87hk2lctDYJwoCkkx5HFwyKMkdlNBEW+coYxrIcOkEU0DX9whpmkLHjDLi1RBg2+
	 ial9vSQe3Xqv3FvViJi2hgW4tONJEO8HwDpAkgtIYu441czmY0z18BjiugqTAs8gqo
	 mJ7qk/0zamrhg==
From: "Yann Sionneau" 
Subject: =?utf-8?Q?Re:=20domU=20suspend=20issue=20-=20freeze=20processes=20failed=20-=20Linux=206.16?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1758724106932
Message-Id: <32097dc9-761f-4319-9fa8-6bcb15c06a82@vates.tech>
To: xen-devel@lists.xenproject.org
References:   <05e9628d-83e5-4feb-881d-5854b72bd560@suse.com>   <8f6b8f08-ca62-467b-a6be-4d33208e5393@epam.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.a98839dc42fd49e79c01c9d6a6713886?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250924:md
Date: Wed, 24 Sep 2025 14:28:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 9/24/25 15:30, Marek Marczykowski-G=C3=B3recki wrote:
> On Wed, Sep 24, 2025 at 01:17:15PM +0300, Grygorii Strashko wrote:
>>
>>
>> On 22.09.25 13:09, Marek Marczykowski-G=C3=B3recki wrote:
>>> On Fri, Aug 22, 2025 at 08:42:30PM +0200, Marek Marczykowski-G=C3=B3rec=
ki wrote:
>>>> On Fri, Aug 22, 2025 at 05:27:20PM +0200, J=C3=BCrgen Gro=C3=9F wrote:
>>>>> On 22.08.25 16:42, Marek Marczykowski-G=C3=B3recki wrote:
>>>>>> On Fri, Aug 22, 2025 at 04:39:33PM +0200, Marek Marczykowski-G=C3=B3=
recki wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> When suspending domU I get the following issue:
>>>>>>>
>>>>>>>        Freezing user space processes
>>>>>>>        Freezing user space processes failed after 20.004 seconds (1=
 tasks refusing to freeze, wq_busy=3D0):
>>>>>>>        task:xl              state:D stack:0     pid:466   tgid:466 =
  ppid:1      task_flags:0x400040 flags:0x00004006
>>>>>>>        Call Trace:
>>>>>>>         
>>>>>>>         __schedule+0x2f3/0x780
>>>>>>>         schedule+0x27/0x80
>>>>>>>         schedule_preempt_disabled+0x15/0x30
>>>>>>>         __mutex_lock.constprop.0+0x49f/0x880
>>>>>>>         unregister_xenbus_watch+0x216/0x230
>>>>>>>         xenbus_write_watch+0xb9/0x220
>>>>>>>         xenbus_file_write+0x131/0x1b0
>>>>>>>         vfs_writev+0x26c/0x3d0
>>>>>>>         ? do_writev+0xeb/0x110
>>>>>>>         do_writev+0xeb/0x110
>>>>>>>         do_syscall_64+0x84/0x2c0
>>>>>>>         ? do_syscall_64+0x200/0x2c0
>>>>>>>         ? generic_handle_irq+0x3f/0x60
>>>>>>>         ? syscall_exit_work+0x108/0x140
>>>>>>>         ? do_syscall_64+0x200/0x2c0
>>>>>>>         ? __irq_exit_rcu+0x4c/0xe0
>>>>>>>         entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>>>>>        RIP: 0033:0x79b618138642
>>>>>>>        RSP: 002b:00007fff9a192fc8 EFLAGS: 00000246 ORIG_RAX: 000000=
0000000014
>>>>>>>        RAX: ffffffffffffffda RBX: 00000000024fd490 RCX: 000079b6181=
38642
>>>>>>>        RDX: 0000000000000003 RSI: 00007fff9a193120 RDI: 00000000000=
00014
>>>>>>>        RBP: 00007fff9a193000 R08: 0000000000000000 R09: 00000000000=
00000
>>>>>>>        R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000=
00014
>>>>>>>        R13: 00007fff9a193120 R14: 0000000000000003 R15: 00000000000=
00000
>>>>>>>         
>>>>>>>        OOM killer enabled.
>>>>>>>        Restarting tasks: Starting
>>>>>>>        Restarting tasks: Done
>>>>>>>        xen:manage: do_suspend: freeze processes failed -16
>>>>>>>
>>>>>>> The process in question is `xl devd` daemon. It's a domU serving a
>>>>>>> xenvif backend.
>>>>>>>
>>>>>>> I noticed it on 6.16.1, but looking at earlier test logs I see it w=
ith
>>>>>>> 6.16-rc6 already (but interestingly, not 6.16-rc2 yet? feels weird =
given
>>>>>>> seemingly no relevant changes between rc2 and rc6).
>>>>>>
>>>>>> I forgot to include link for (a little) more details:
>>>>>> https://github.com/QubesOS/qubes-linux-kernel/pull/1157
>>>>>>
>>>>>> Especially, there is another call trace with panic_on_warn enabled -
>>>>>> slightly different, but looks related.
>>>>>>
>>>>>
>>>>> I'm pretty sure the PV variant for suspending is just wrong: it is ca=
lling
>>>>> dpm_suspend_start() from do_suspend() without taking the required
>>>>> system_transition_mutex, resulting in the WARN() in pm_restrict_gfp_m=
ask().
>>>>>
>>>>> It might be as easy as just adding the mutex() call to do_suspend(), =
but I'm
>>>>> really not sure that will be a proper fix.
>>>>
>>>> Hm, this might explain the second call trace, but not the freeze failu=
re
>>>> quoted here above, I think?
>>>
>>> While the patch I sent appears to fix this particular issue, it made me
>>> wonder: is there any fundamental reason why do_suspend() is not using
>>> pm_suspend() and register Xen-specific actions via platform_suspend_ops
>>> (and maybe syscore_ops)? From a brief look at the code, it should
>>> theoretically be possible, and should avoid issues like this.
>>>
>>> I tried to do a quick&dirty attempt at that[1], and it failed (panic). =
I
>>> surely made several mistakes there (and also left a ton of todo
>>> comments). But before spending any more time at that, I'd like to ask
>>> if this is a viable option at all.
>>
>> I think it might, but be careful with this, because there are two "Syste=
m Low power" paths in Linux
>> 1) Suspend2RAM and Co
>> 2) Hybernation
>>
>> While "Suspend2RAM and Co" path is relatively straight forward and expec=
ted to be always
>> started through pm_suspend(). In general, it's expected to happen
>>   - from sysfs (User space)
>>   - from autosuspend (wakelocks).
>>
>> the "hibernation" path is more complicated:(
>> - Genuine Linux hybernation hibernate()/hibernate_quiet_exec()
> 
> IIUC hibernation is very different as it puts Linux in charge of dumping
> all the state to the disk. In case of Xen, the primary use case for
> suspend is preparing VM for Xen toolstack serializing its state to disk
> (or migrating to another host).
> Additionally, VM suspend may be used as preparation for host suspend
> (this is what I actually do here). This is especially relevant if the VM
> has some PCI passthrough - to properly suspend (and resume) devices
> across host suspend.
> 
>> I'm not sure what path Xen originally implemented :( It seems like "susp=
end2RAM",
>> but, at the same time "hybernation" specific staff is used, like PMSG_FR=
EEZE/PMSG_THAW/PMSG_RESTORE.
>> As result, Linux suspend/hybernation code moves forward while Xen stays =
behind and unsync.
> 
> Yeah, I think it's supposed to be suspend2RAM. TBH the
> PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE confuses me too and Qubes OS has a
> patch[2] to switch it to PMSG_SUSPEND/PMSG_RESUME.
> 
>> So it sounds reasonable to avoid custom implementation, but may be not e=
asy :(
>>
>> Suspending Xen features can be split between suspend stages, but
>> not sure if platform_suspend_ops can be used.
>>
>> Generic suspend stages list
>> - freeze
>> - prepare
>> - suspend
>> - suspend_late
>> - suspend_noirq (SPIs disabled, except wakeups)
>>    [most of Xen specific staff has to be suspended at this point]
>> - disable_secondary_cpus
>> - arch disable IRQ (from this point no IRQs allowed, no timers, no sched=
uling)
>> - syscore_suspend
>>    [rest here]
>> - platform->enter() (suspended)
>>
>> You can't just overwrite platform_suspend_ops, because ARM64 is expected=
 to enter
>> suspend through PSCI FW interface:
>> drivers/firmware/psci/psci.c
>>   static const struct platform_suspend_ops psci_suspend_ops =3D {
> 
> Does this apply to a VM on ARM64 too? At least on x86, the VM is
> supposed to make a hypercall to tell Xen it suspended (the hypercall
> will return only on resume).
> 
>> As an option, some Xen components could be converted to use syscore_ops =
(but not xenstore),
>> and some might need to use DD(dev_pm_ops).
>>
>>>
>>> [1] https://github.com/marmarek/linux/commit/47cfdb991c85566c9c33357051=
1e67bf477a5da6
>>
>> -- 
>> Best regards,
>> -grygorii
>>
> 
> [2] https://github.com/QubesOS/qubes-linux-kernel/blob/main/xen-pm-use-su=
spend.patch
> 

On my setup I get a weird behavior when trying to suspend (s2idle) a 
Linux guest.
Doing echo freeze > /sys/power/state in the guest seems to "freeze" the 
guest for good, I could not unfreeze it afterward.
VCPU goes to 100% according to XenOrchestra
xl list shows state "r" but xl console blocks forever
xl shutdown would block for some time and then print:
Shutting down domain 721
?ibxl: error: libxl_domain.c:848:pvcontrol_cb: guest didn't acknowledge 
control request: -9
shutdown failed (rc=3D-9)

Do you think it's related to your current issue?

Regards,

-- 


--
Yann Sionneau | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech





From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:00:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:00:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129472.1469413 (Exim 4.92)
	(envelope-from )
	id 1v1Qz6-00054r-H7; Wed, 24 Sep 2025 15:00:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129472.1469413; Wed, 24 Sep 2025 15:00: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 1v1Qz6-00054k-CZ; Wed, 24 Sep 2025 15:00:44 +0000
Received: by outflank-mailman (input) for mailman id 1129472;
 Wed, 24 Sep 2025 15:00: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 1v1Qz5-00054e-5A
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:00:43 +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 3cc0982a-9957-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 17:00:41 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b3194020e86so239496166b.1
 for ; Wed, 24 Sep 2025 08:00:41 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b1fcfe88bc3sm1518750466b.51.2025.09.24.08.00.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 08:00: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: 3cc0982a-9957-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758726040; x=1759330840; 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=9zOkKFPq4CC24R3bi95T/aso0CoAmoXY+s+fWRaSHdo=;
        b=NfJ7WowCLDrSrgYPXfo/30bz1aUA38UWOJ1DoLVFuwG+Li83vQfz+wlVD7jsxzX10H
         7NWPUhoPotrMngecIquKW84M8b10TAfcxwTsHvwk2sjjIQ0KDBqzenC9bVe6T1EqTZac
         LQn4mWzRKCr0Q7nIhFJ7yACf3+241nyGe8lch2HXBuasqpRBQNupRIytYVigPVoekiLA
         l5HB+qT4C7gpfBPvMU0xYixCqTa6F+PAWntGR8wAtKzs6mEPFz9FshQ5GO1iUv1B+p5m
         NRk/Fmt4qHTaRaoZAQjToKxn0Rh2RcwfCMFfg2tBatIzbM0lyhZsL291gkKXbe136BsL
         gTxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758726040; x=1759330840;
        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=9zOkKFPq4CC24R3bi95T/aso0CoAmoXY+s+fWRaSHdo=;
        b=gdBI4b0cJxbqvpeShw04HmlT7Z6LcFDIYhH0J4F+4Njr4K3K7e0/EPPypbOPFmEVZF
         8/l6jz5gwBLvbbIc87YUCOouz7jTyVd6f1XnJvJV3GZOxrFvmrQ9fLM+0zpQMxuBC0RL
         AnDBZBGI5XfGWxE6PO1u8jeCP72dfoElAmjDQFby2CncU1m1MnnkoN+SGdMghsT5tCTk
         yCE7SumX4FB1m8HqnyI1vqXzlMyriQJFmqqtfCvZHIDQQGIt/5+QVcmiM1Xsudl+tVfu
         7YvOGnHpin8QupuekEVDRsl3ASIXl5u4hM2n8mtdBbxd1tqFSQ7IVZJgb9PMAwY7DJT1
         9JMg==
X-Forwarded-Encrypted: i=1; AJvYcCW0cxx3RcXIUoifXN7uzTYnYkPyhxKDgMN6BYxC/s0iJkBgKyVSumIn4UThzHtIcFECNt4OuR1A+3Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcBKWJSzdtPAxN8Pl/GoFrT5Jgrot/Vxnbv7NB3cBvcejw3+u0
	6iqN/AchRHExT8jCXq1cJznCxtnfB1fqCvBatmrAovTLAuXCy7mBgXIM
X-Gm-Gg: ASbGnct0+d2ZZepVWsaO8Ym/3e47oNFskPMEpQwYZVCfdherp9b6XSeAFvTyx5I7u/W
	egUChetOjD6fctRbfM5Tat8Gwk7KW1ngIF/142m17f2ckz/ssSV3QGVe6jz6IqztIuMUlTos2Lr
	xYi0thQ6KKtb72Kx7XkcWcPhisLbTh1RfprQ7rb+6w27xFGekGbGl0+fccfmh5FKRKeo2EIH3Xh
	6U38BGp5D5JpuUBfpDS3uYOzg2TxRpwPIsS6w8Uvquluv4u8NxD268ClPQrgL0RyGucg8T/emTY
	1L7JsWd9Cqb0c6/IZl1Fjq332c7Y8N6QC6ihijms3tCMJbR8gwAL7ig34PfEhdsOxzjLmP9JuPL
	qUquucX+OAsxzww/AFb+mr14ckKSESabUqVBEQSzxgTcZM8I1iZZ4mPf4156jQUxtFADOTDIN
X-Google-Smtp-Source: AGHT+IFZSGZ4L39d/bFsUa7gfK4s2fgyR+7IytjjyOq+2DiRCwBG+WQwRM2iby6cLJCKX1qmiLXOtA==
X-Received: by 2002:a17:906:6a13:b0:aff:9906:e452 with SMTP id a640c23a62f3a-b34bbbd9a07mr13896166b.31.1758726040063;
        Wed, 24 Sep 2025 08:00:40 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------8L7dDMun6u8WXMmZV5QmgvQm"
Message-ID: <9777e972-8ea1-4dfa-bab0-ee7e13f0a0e6@gmail.com>
Date: Wed, 24 Sep 2025 17:00:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/18] xen/riscv: detect and initialize G-stage mode
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: 
 <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
 
 <0c4e446b-abe1-481c-91a6-60a49459b486@gmail.com>
Content-Language: en-US
In-Reply-To: <0c4e446b-abe1-481c-91a6-60a49459b486@gmail.com>

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


On 9/24/25 1:31 PM, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/setup.c
>>> +++ b/xen/arch/riscv/setup.c
>>> @@ -22,6 +22,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>>   
>>>       console_init_postirq();
>>>   
>>> +    gstage_mode_detect();
>> I find it odd for something as fine grained as this to be called from top-
>> level start_xen(). Imo this wants to be a sub-function of whatever does
>> global paging and/or p2m preparations (or even more generally guest ones).
> It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
> when the latter is introduced.
> Probably, I will move the current patch after p2m_init() is introduced to make
> gstage_mode_detect() static function.

Maybe putting gstage_mode_detect() into p2m_init() is not a good idea, since it
is called during domain creation. I am not sure there is any point in calling
gstage_mode_detect() each time.

It seems that gstage_mode_detect() should be called once during physical CPU
initialization.

A sub-function (riscv_hart_mm_init()? probably, riscv should be dropped from
the name) could be added in setup.c and then called in start_xen(), but
is it really needed a separate sub-function for something that will be called
once per initialization of pCPU?

~ Oleksii

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



  
    
  
  
    


    

    
On 9/24/25 1:31 PM, Oleksii Kurochko
      wrote:

    

    

      

        

          
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -22,6 +22,7 @@
 #include <asm/early_printk.h>
 #include <asm/fixmap.h>
 #include <asm/intc.h>
+#include <asm/p2m.h>
 #include <asm/sbi.h>
 #include <asm/setup.h>
 #include <asm/traps.h>
@@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     console_init_postirq();
 
+    gstage_mode_detect();


        

        
I find it odd for something as fine grained as this to be called from top-
level start_xen(). Imo this wants to be a sub-function of whatever does
global paging and/or p2m preparations (or even more generally guest ones).

      

      
It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
when the latter is introduced.
Probably, I will move the current patch after p2m_init() is introduced to make
gstage_mode_detect() static function.

    

    
Maybe putting gstage_mode_detect() into p2m_init() is not a good idea, since it
is called during domain creation. I am not sure there is any point in calling
gstage_mode_detect() each time.

It seems that gstage_mode_detect() should be called once during physical CPU
initialization.

A sub-function (riscv_hart_mm_init()? probably, riscv should be dropped from
the name) could be added in setup.c and then called in start_xen(), but
is it really needed a separate sub-function for something that will be called
once per initialization of pCPU?

~ Oleksii


  


--------------8L7dDMun6u8WXMmZV5QmgvQm--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:02:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:02:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129488.1469422 (Exim 4.92)
	(envelope-from )
	id 1v1R0z-0005fP-VC; Wed, 24 Sep 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 1129488.1469422; Wed, 24 Sep 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 1v1R0z-0005fI-SK; Wed, 24 Sep 2025 15:02:41 +0000
Received: by outflank-mailman (input) for mailman id 1129488;
 Wed, 24 Sep 2025 15:02: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 1v1R0y-0005fC-06
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:02:40 +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 82445dff-9957-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 17:02:37 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by PA4PR03MB6992.eurprd03.prod.outlook.com (2603:10a6:102:e3::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 15:02:35 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 15:02: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: 82445dff-9957-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MgpWgbl05+rFSTzyzTjig9a9otKvulS8IETKA47uKYx51qXySkNtrqrjFMSWpNt0U330LGiYpNzYaautXTlHu4LEQWJyoHolCvXklsF65w4or6D8wiPHE6I5gHftWj+/DQtSKjnz8Ry9E/uYVTJY6D4gXZHR1Y+nzlkRpdFyOAgAdKwV9/HSSeYi+aC6za6b5+AnnBx7b/7lZZx9+L+61vIdsx6wHSfqg8fN7HD9uJIl7QN5qSDxmN52Veeva/l8pd8AJrT4v9OyA5gbGrANfoNzjWNw/03rmcg3/Gxzcb5ciVXNKgTVinygwRrtNBU3mXWB3N5+S9satzEHfV1GQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JVZnX4ULP295CayncxiVgpVqhfvOZOT/j+OGAfYSWww=;
 b=A22JJKvhXAEmG6wabZlPWxULj4Ie9O2X6stMFvisq6IqLdOxS2Ql/pU9SUTh3bvWNf7Wzk72rcMUqrluBvgPHbNp9opOEJqJSTFTqQw72eFewqlhdQpCbu+ahcSUozXfEZAyAhJuJ7Gp1F68IidkHgv41/1u0xCkxYuMXNgMTqdDz1jhqH1YMqKa1/pi0a/+bxhAQLWg3g84hdHeVMCXxIMiXu7Ot2D6hY6M6R0nGycayenAwMs1+xLU0dWFyFjVj2q2sTJbcND533SK/lvNufgs2ZP8g4yEBKmpHm1kHfUA0MPrMjExJubKKO3SR8apH18VfJ5IOyF1PCVE9tEMJw==
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=JVZnX4ULP295CayncxiVgpVqhfvOZOT/j+OGAfYSWww=;
 b=VStoRBbzwrrouIaRrRqZKOa7lK5tL1lLRDKxOpUEkkSVUhh9pAvZNma5pXJOn7KjynfGCBI6z4GiLbFjpkcERYj52k0IR6dNBVksM7bBxsYHRJ88TeEoeF4igMFVKvA6D+CfytHyHPaPib6MZ8aLF3XPnAVNGzUyL/ulDRf+hR5mH/ezTG5Cm7L4KTvMeDrNOLOx3p7zphAZv7fAFWAI9Cejd39VqNYvWoLs2BCt4+HvxddRo7szeip6aa6eXN10tEu3JUy/1a9yAN2X319QB1i33c7cA/YeqXlMrfHVUdV4rjYZQGikbBcPwHOHfZb9jx5YJBxagvwcfKJ8TdqeFg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <05ac348d-b392-42ab-b769-8a1c1355a4af@epam.com>
Date: Wed, 24 Sep 2025 18:02:34 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
To: Alejandro Vallejo ,
 Andrew Cooper , Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko ,
 "xen-devel@lists.xenproject.org" 
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
 <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
 
 <88cc4cf1-3bc9-47f5-b8f7-e04f01b027ee@xen.org>
 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: WA2P291CA0009.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::6) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|PA4PR03MB6992:EE_
X-MS-Office365-Filtering-Correlation-Id: 0bf7aa47-94a1-4bd3-a2e8-08ddfb7b6513
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|3122999003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WFJVd0hSeFVqcUVWY0wrWnk2THRiUDU1TUJldUpQZHdibnUvNWZvYmp3ZTBR?=
 =?utf-8?B?clBCaWo1VENaMThtZkNDQURLaE85TVdqaUt2ZGdtS1lJMHdGV0VNUVNvTlU2?=
 =?utf-8?B?V1VqTXgxUUk3VE5mREtXOCtpOUlTYVZ4YzFHUWNOUTZjZ3ZPTWZNSkY3QnBW?=
 =?utf-8?B?UkluRnRaRjRhd1pJd1hnM1NuL2YxY2hnQTB6U1RGMnRhSkhlbDN1dnBFODZG?=
 =?utf-8?B?UlM5YlZUc1pkdEpKMFlMaTk2L1dBT2RLdjNlTXlhQVRWb081ZFhsb0VSbDla?=
 =?utf-8?B?dGRnRVFpMFJ2T28xVG5wNHVJS1lYcUhCWVlMU0xuQ3hjaXFHY2kwblpTRlFw?=
 =?utf-8?B?VEtENUdpRkdweUZYM3J1RnFXV0JOTTdKYWFvUVRaZndBM3JyZ0hrZ0xmRFJM?=
 =?utf-8?B?dG4ybXB2NUFCWkNNWUQrdGRaVGx0VVppWkJFNzRneExaenpOUXB0RmVkaE1P?=
 =?utf-8?B?RlpKUE9Tc3AxRFI0aDExVnQrOW16WGZlemRQajVyNUM3cXNva1RkVFU2eGhF?=
 =?utf-8?B?V2NSZ1Y2cEExYVZ1VGtjUzJ2Ym1Xdm1PazhOTXJGNFNveXRvVHdlNUt3R1BU?=
 =?utf-8?B?VlZsZUtlbXlSREM3dkh6czRZT1hieWl2UHcxQTFMSmRHUDlmdlc2RVZhenZT?=
 =?utf-8?B?aWN5Wkt3QkhQSEo4N3dvamdGc2c1ZzRnczkvWXhPUm16YkxIb3VOOGk2WGZh?=
 =?utf-8?B?RjdFaWVoYkNzdldnbUtic2RyUmJHRWY3MnJMN3ZzTWtqTjVmcnFISjdSQzU2?=
 =?utf-8?B?dWpldWFYNEFnem5xMEJLOHhITklVdVVHRzUxaEpzQ2pkUmJDM1g5ODFWTWZl?=
 =?utf-8?B?bkhUaGFQdDIrSGZNNklMRU9iNU85TlRjaGNZcHZYeWlUUFlHRUJIOTN5ZDMz?=
 =?utf-8?B?RDZhdjBqV00wdmJHOEUxN2doNWZDWG93aDExTElWWlBPNmpPRDZSWHdDYmdC?=
 =?utf-8?B?TlBseWRpMVE5djZjUHRmcmhtMmN3L0pEd01tU1ZJNTlXdEJyeFFnWXRuNWhl?=
 =?utf-8?B?eW1ZR2pUekZEYm5CVk4rMWhQRjJUbU9IMjdnbEtaNXc2SHZxajc0eFNOQ29X?=
 =?utf-8?B?amg1S2VCall1TEwyUFZZd0kyQUkvdnRWcFhMNUtyS2twVVgvYWVtVWZsMjB2?=
 =?utf-8?B?a0tGVUhMUitpak9ndkdrckloQkFKOW5lTHgxREVEd3N6akVxKyt1UjRNMkM4?=
 =?utf-8?B?RmRRT21EMVZUa2ZkSmZ0ZEtESGU3dXZEdDgzL1czSUJtU0Q5alhUSU9CQnFz?=
 =?utf-8?B?VkxrVW5GQWdmb2NwNEhxbmJvL3lDRkhBTlg4RmhtQmI1MEpzMTdhcFRrb0Jx?=
 =?utf-8?B?cjJnU1lmdEdJMmRnWkxYdkdQZnU2VG5BQkpGcURhc0JWZS9pVWxNODlueFdZ?=
 =?utf-8?B?U0p1czYwS0hpNXdpSDVsVlVob1hRRVVJZktJNkxEVEtjcEQ0bXROM0ZoODdM?=
 =?utf-8?B?K1N4T1JzOHFkUm1Gc09FUUkzNnU5WWxzUFBESmRvVzB6Tkd6N1lweld2ZlhT?=
 =?utf-8?B?S1V2cFBkWC9RTXdqK1lXTTZBdlpNek5NdmxQQkpOQ3VsVWNDUWw4YU01Tm52?=
 =?utf-8?B?bGxsRGs3YmNoOElycEYyazVmcERnOXpXaUlDTXBPeXhYeGZ1WGJ2UTVmV1VC?=
 =?utf-8?B?WEdYZG51YTUvSDNOMzJZSkt1Nzc4K2QrcS9OMXBPVm04ak5rbmtNUHU5MnVY?=
 =?utf-8?B?Uk1RS3FqcXRWM1YwaDhkaEtDTGdJLzN4RTNIWi9rT2pHZnlkc085cU5SbzNu?=
 =?utf-8?B?bWs1bmJQY2dyNkZTd0l1K3J2cTNSMlhJcDZXVHJRUEh0RFNvcDRKYkZzV2lL?=
 =?utf-8?Q?P4cq8BFsxqzFQ9C8LGZpE35YnVnAeCQSdwzH8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(3122999003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TWFvRG1NRTZ0ZHdxNGIwZy9MNkFVMkZ0QkQ4QzE1eUVKMUZOc1JiMzFSV0Fy?=
 =?utf-8?B?L2x4d1ZxaFJsY1JoV0M4eG1xd2ZSTW91UUdqZGlSa3hhUkZxRW9tWnVZaStG?=
 =?utf-8?B?NSs2eDkyVHBkQlFlaUYxTHJNQmVIV1JLZEszTnN6SERQUFlkYUxBRFUxOGFV?=
 =?utf-8?B?RkNKS3U3Mm1leXhYT0NrOHNTQzc5TE9keFh6UkRGMTliWkVZT3pWZGsrb2tO?=
 =?utf-8?B?dXFWNG9pTnVFdjBVWTJvSEx6Q2wwQ2VZRTdjZURnc3Z4MG5RZEdYLzQ1aHZa?=
 =?utf-8?B?cm1yQnlFTjN2T3BxcTgxU1lCQXg4alJpRWdOQmFTeGloUWY3ZnJCc0RXYkds?=
 =?utf-8?B?bHZ1S0l5VlhTN05COU9ZcWxxTzRhR0s4NlZuU0Z0UGttTHQzb3g0NERZeVBh?=
 =?utf-8?B?emVCQVR1dHFZVHRzKzR3S0EwNlI2NDF2VUV1WXJIVVh4d1dua1ZNQm1GV2Vo?=
 =?utf-8?B?N3F2UXRhWUJPWWR5OHp5cWI2bDVGUXlMdThmMCt2WWdqVnVuZVVhdW9IZHdj?=
 =?utf-8?B?aTladW5TMVBrcDc0aitxUjM5ZDM1cE56Tkt2NVZzWWdNcnVwOUptQVdSemRu?=
 =?utf-8?B?ME94VDczZFVJWlo0MUxHamRqN3pCUkN0Q09RTERUVUVlWmkzN3kvYXdVTG9E?=
 =?utf-8?B?SE1KTldlSUd0V0NCRlZyZDJHcGlyeW5rNFIyVFltYzArbFVYUTVjakJJMERY?=
 =?utf-8?B?MGtpczZWQlJYYmlQUGFaKy9SL2p5WDZqZ0hOUnc5eERiaW55ZDFmb1gyQTBS?=
 =?utf-8?B?MW9jR2kvanU1K1R0NHN4ZzdabWhMSkNISklVQ3A2MXFMVXJzQ1BNaFZjSTJN?=
 =?utf-8?B?NUVBOVNEbmR3ZjRBSDRyT2FKdmk5Nmc5ZlhxYUdoRzlxTmtuemk2dlhlcEpV?=
 =?utf-8?B?QXBqNDBNTkhQUTd1V2grVlUzY1lucGg2OVFxTldpT2poUUVYMFFucXByQkY2?=
 =?utf-8?B?T21Xd2lXN2hYYkU4Ui9RaFVHcTRrcGErWmcrUEpISDk4TVJILzE4Q0dudkkv?=
 =?utf-8?B?TEpObWRxcHZ2N2dMMzgxZXRZdjBFY3hLbWFTdURyOTIwUm1sUk1RUzU4bGVa?=
 =?utf-8?B?MFBSVnF6YUZTcE1XNEsrcjg0QkZ3QW9tVjhNYk8yN0xXNTIyd1hQT1gycWxR?=
 =?utf-8?B?ajM1UGZEalE0WVp2SXpQZWZLQkY3VkVEUTlrdkphUCtXWUM5Qnk1YmQwNnhl?=
 =?utf-8?B?ZlRHUGR3T29Gbml1MFZhTWdXSXZsL2MxRGtwMUFLbkE4WnkxK1YwSi82WE9k?=
 =?utf-8?B?RG02bU5SSWl6UzZFNzIxZHlGemdySTdxWjFXYkVkVGo2dlkzNGRiM2NqL25y?=
 =?utf-8?B?aXE0MlJyUHBUN0lUWDA5TXBucUt1N1Q2aVpQbmp2MWh1aVZMKzFiLzNBUjBr?=
 =?utf-8?B?dXBndzc3dUZqeDJ6VEJ5ZE80bEpEc0xQeFJWdzRXT0NscUZTVVp1bUVFaWhm?=
 =?utf-8?B?a2NxS3ZNTDJhK09DR250TDY2cSsxVXlYOEZrL05oejVMUkpoOUFXeER3WFc0?=
 =?utf-8?B?ZmJFeXJIU2pkT3lkWFRjVFR2OE5lN1YvcWFEZ0pLbVlzZzFpVVVIbndjZzlr?=
 =?utf-8?B?a0hlV0lHUFJxaU1qNXJHVTlCMmk5TW4zejNNcmp1QXhRZ29OaWc3REExZjh3?=
 =?utf-8?B?S3gxRXJHWFF0RjZMaHZNTm5aRm9wUHFsNTZOc2NEeHRQYlpWVS81WStoUkJs?=
 =?utf-8?B?UWRvSkcrODdBeXBmVlV2L21oc1lkWWRpN2xIcHlSQytmaTdPYmJkOVFyYXdj?=
 =?utf-8?B?T25aSXJxcmM3Y0RydXRZWnk1endkd0ZTYXJGQk1oRDA0V3RxdXdyaEpEc1px?=
 =?utf-8?B?OWl5QXZHVE1MTlA0ZVM4RTdYMWZVNldxVUNMTGdNT3lyaWpyZVRCUHN4bVNP?=
 =?utf-8?B?aVdReFhYTVhvb1g5ZVg4Q2xpT29Md29CZXpWS3pyVmhmdEZOQ3ZWNzI3djZp?=
 =?utf-8?B?RVAvVWRGWXZycTBJSG1SN0FjcTlMNFNkNkxqOGJJdnNUNlU1SUdIdUkzVll2?=
 =?utf-8?B?NkZoMGtiQXhUQUd5c1JWOXg5TURMMm5KVVllYXVQQzJUUzI0R3R3S1NQRHlD?=
 =?utf-8?B?UHlLMks1bWFsVEpqQ0pBQk5EMG04WVZUQlBLMnRLV0dUYU15MVgwZlRzL2JN?=
 =?utf-8?B?UkdINitGWHdTaEdWTEpTTnpreHl1UStrOExqczJhRDlQV3hSdHA5VHA1bWZN?=
 =?utf-8?B?THc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0bf7aa47-94a1-4bd3-a2e8-08ddfb7b6513
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 15:02:35.4036
 (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: SvkYLCN5EP2+qVPqPIilPxyTfIh04TuftlYv4KqRaJ9yf5BoLDWWKlII62l9E30/OKJBE6AqwxDLcFLfj/zCXKoT7Z5LLt6b0hrF7xzBYZ4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6992

Hi Alejandro,

On 24.09.25 14:23, Alejandro Vallejo wrote:
> On Tue Sep 16, 2025 at 7:14 PM CEST, Andrew Cooper wrote:
>> On 16/09/2025 9:57 am, Grygorii Strashko wrote:
>>> Hi Jan,
>>>
>>> On 16.09.25 17:34, Jan Beulich wrote:
>>>> On 16.09.2025 12:32, Grygorii Strashko wrote:
>>>>> From: Grygorii Strashko 
>>>>>
>>>>> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX
>>>>> dependency") the
>>>>> HVM Intel VT-x support can be gracefully disabled, but it still
>>>>> keeps VMX
>>>>> code partially built-in, because HVM code uses mix of:
>>>>>
>>>>>    - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_VMX cfg
>>>>>    - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX cfg
>>>>>
>>>>> for runtime VMX availability checking. As result compiler DCE can't
>>>>> remove
>>>>> all, unreachable VMX code.
>>>>>
>>>>> Fix it by sticking to "cpu_has_vmx" macro usage only which is
>>>>> updated to
>>>>> account CONFIG_INTEL_VMX cfg.
>>>>>
>>>>> Signed-off-by: Grygorii Strashko 
>>>>> ---
>>>>> Hi
>>>>>
>>>>> It could be good to have it in 4.21, so vmx/svm disabling
>>>>> option will be in complete state within 4.21 version.
>>>>
>>>> Imo this isn't release critical and has come too late. It's of course
>>>> Oleksii's call in the end.
>>>>
>>>>> --- a/xen/arch/x86/include/asm/cpufeature.h
>>>>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>>>>> @@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>>>>>    #define cpu_has_sse3            boot_cpu_has(X86_FEATURE_SSE3)
>>>>>    #define cpu_has_pclmulqdq       boot_cpu_has(X86_FEATURE_PCLMULQDQ)
>>>>>    #define cpu_has_monitor         boot_cpu_has(X86_FEATURE_MONITOR)
>>>>> -#define cpu_has_vmx             boot_cpu_has(X86_FEATURE_VMX)
>>>>> +#define cpu_has_vmx             (IS_ENABLED(CONFIG_INTEL_VMX) && \
>>>>> +                                 boot_cpu_has(X86_FEATURE_VMX))
>>>>
>>>> I'm pretty sure using_vmx() was introduced precisely to avoid the use of
>>>> IS_ENABLED() here. What is completely missing from the description is a
>>>> discussion of the effect of this change on pre-existing uses of the
>>>> macro. ISTR there being at least one instance which would break with
>>>> that change. And no, I'm not looking forward to digging that out again,
>>>> when I already did at the time the using_vmx() was suggested and then
>>>> implemented. (I can't exclude it was the SVM counterpart; we want to
>>>> keep both in sync in any event, imo.)
> 
> Apologies if this has already been discussed, but I didn't participate in prior
> discussions. Targeted lookups in lore are not shedding a lot of light either.
> 
>>>
>>> Thank you for your comments and sorry for not digging into the history of
>>> the related patches.
>>>
>>> All, please ignore these patches as existing places. where
>>> cpu_has_vmx/smv
>>> are still used, need to be revised one by one.
>>>
>>
>> Off the top of my head, fixups to MSR_FEATURE_CONTROL, and AMD SKINIT
>> need cpu_has_vmx/svm not guarded by Kconfig like this.
>>
>> ~Andrew
> 
> What do you mean? AFAICS SKINIT is guarded by cpu_has_skinit, not cpu_has_svm.
> 
> And MSR_IA32_FEATURE_CONTROL tweaking seems self-contained in xen/hvm/vmx/ which
> is compiled out when !CONFIG_INTEL_VMX.
> 
> For the hypothetical case in which we might want to know the real HW value
> we can go look at the raw policy, as in "raw_cpu_policy.basic.vmx" or
> "raw_cpu_policy.extd.svm". Or what's mentioned in passing here.
> 
> https://lore.kernel.org/xen-devel/a881c6a6-2c36-4e5c-8336-21cd0e14b873@suse.com/
> 
> Forcing the common case to use a helper and leaving the rare case in the
> shorthand macro seems like a bad idea. This ought to follow what cpu_has_nx
> already does.
> 
> Is there a specific code instance in which having IS_ENABLED() in the
> cpu_has_{svm,vmx} macros would cause issues today? While there are some dubious
> choices of svm vs vmx with or without negation, they all seem to resolve
> to correct code, with less codegen after IS_ENABLED() ends up in all the
> conditionals.
> 
> IOW: I have seen fear of incorrectness, but not proof of it. Now, obviously the
> burden of proof rests on the submitter, indeed, but I'd like to know where we
> stand in terms of what that proof would look like. A naive grep shows not many
> sites to check.
> 
>    $git grep cpu_has_svm | grep -v cpu_has_svm_ | wc -l
>    6

arch/x86/flushtlb.c:    bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow);
arch/x86/hvm/hvm.c:    if ( nestedhvm_enabled(v->domain) && cpu_has_svm &&
arch/x86/spec_ctrl.c:        if ( !cpu_has_svm )

not checked yet.

> 
>    $git grep cpu_has_vmx | grep -v cpu_has_vmx_ | wc -l
>    11

Here:
1) arch/x86/hvm/dom0_build.c:    if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
    arch/x86/hvm/hvm.c:        if ( !paging_mode_hap(d) || !cpu_has_vmx )

^ is safe to opt-opt. I've sent patch [1]
It gives biggest coverage benefit actually.

2) arch/x86/hvm/viridian/viridian.c:    *(u8  *)(p + 7) = (cpu_has_vmx ? 0xc1 : 0xd9);
There is strict dependency on HW. In general, viridian should never be enabled on INTEL, for example,
if !INTEL_VMX. So, could be opt out

3) arch/x86/mm/mem_sharing.c:        if ( unlikely(!is_hvm_domain(d) || !cpu_has_vmx) )
MEM_SHARING has strict dependency on INTEL_VMX, so it is "doesn't matter" case.
MEM_SHARING should never be enabled if !INTEL_VMX.

4) arch/x86/hvm/nestedhvm.c:    unsigned nr = cpu_has_vmx ? 2 : 3;
There shadow_io_bitmap pages allocated, page number to be used returned by
nestedhvm_vcpu_iomap_get(). Opt-out should be safe for !INTEL_VMX as nr==3 and
nestedhvm_vcpu_iomap_get() will never overflow shadow_io_bitmap[].

5) arch/x86/mm/mem_access.c:    return is_hvm_domain(d) && cpu_has_vmx && hap_enabled(d);
It is p2m_mem_access_sanity_check() called from mem_access_memop().
Seems like whole XENMEM_access_op (MEM_ACCESS) depends on INTEL_VMX on x86.
But there is dependency on VM_EVENT is defined already.

How to proceed???

6) arch/x86/hvm/monitor.c:    if ( cpu_has_vmx )
This is hvm_monitor_descriptor_access():
     if ( cpu_has_vmx )
     {
         req.u.desc_access.arch.vmx.instr_info = exit_info;
         req.u.desc_access.arch.vmx.exit_qualification = vmx_exit_qualification;
     }

Should be safe to opt-out.

7) arch/x86/cpu-policy.c:    if ( cpu_has_vmx )
    arch/x86/cpu-policy.c:    if ( !cpu_has_vmx )
It is calculate_hvm_max_policy()

Place (a)
     if ( cpu_has_vmx )
     {

[below features have to be cleared if !INTEL_VMX, so can't just out-out cpu_has_vmx here.
  Possible option: remove "if ( cpu_has_vmx )"]

         if ( !cpu_has_vmx_rdtscp )
             __clear_bit(X86_FEATURE_RDTSCP, fs);

         if ( !cpu_has_vmx_invpcid )
             __clear_bit(X86_FEATURE_INVPCID, fs);

         if ( !cpu_has_vmx_mpx )
             __clear_bit(X86_FEATURE_MPX, fs);

         if ( !cpu_has_vmx_xsaves )
             __clear_bit(X86_FEATURE_XSAVES, fs);
     }

Place (b)
     if ( !cpu_has_vmx )
         __clear_bit(X86_FEATURE_PKS, fs);

Should be safe to out-out


> 
> cpu_has_X_Y would be off when cpu_has_X is off, but those shouldn't matter for
> this discussion.
> 
> Am I missing something here?

[1] https://patchwork.kernel.org/project/xen-devel/patch/20250924101417.229108-1-grygorii_strashko@epam.com/

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:39:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:39:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129508.1469434 (Exim 4.92)
	(envelope-from )
	id 1v1RaY-0001NH-M0; Wed, 24 Sep 2025 15:39:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129508.1469434; Wed, 24 Sep 2025 15:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1RaY-0001NA-Hw; Wed, 24 Sep 2025 15:39:26 +0000
Received: by outflank-mailman (input) for mailman id 1129508;
 Wed, 24 Sep 2025 15:39: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 1v1RaY-0001N4-62
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:39:26 +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 a55ea08d-995c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 17:39:24 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AM9PR03MB7074.eurprd03.prod.outlook.com (2603:10a6:20b:2dc::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 15:39:21 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 15:39: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: a55ea08d-995c-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=l4g1WMmtwAIW9U2QGGXnq0tMGRacrf+ISrlqLjiq/q64FhFsS/X3kmkOD2nWF0WG05eu9IjJxt7/z7NyCeh8Z8yMZXWJT9d0pawl5jVL+KYs0kal0gvMqXh/0/jyMihdF3xihYPuDAMUYvadC6EC/ikpFquf1zmrSNpoE8W6sSeWjX0hwuHJV54CvYh9JV8qwF4mZHCSKH9C1q1Mp5ZO5hPdOWtiYsWl/lz8dDY3HmpEN+LqNkhCnogWNP6tiMN+PiFvQaM1+VwcU4EECKUMO9MsQt8DykvFsMg4peBSE8Ts55bF+cm8i7GtS1tJMBLDZiJmVgBo+KgckmGCTK5HqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A4Z9+LUwwUfJH4SrNkv1fo7udWuHs5t2KQpnN/guLrA=;
 b=xIXIIUhayAbWbiOzIkwkadKSMV+YSUSRFOzFRbfoLpy5XLhY8z94zJdiZ+DTlI9can3V8UCxsblkqGtZCpCa5vZ03JknW7n35rr0eD0OKJh6alWZBTIThc3+oowFxXA/V8TDJvbhsdY4cLzaMIjc1Cfs1o7SClrBzULXr74tGsOsbkk8I+UvBt7iOklDddvtWLQtZaHmr6gDDGTWkTQCKzXO/bi+XGj4t6I26IVL7cZN5JQTgmGhg0SlewqghW0OpVC3LUtSzYDjRI0t6UwAbr7TlEz3MtlDnlqtvkD10jcGZw3mpMdXcHHjzazl5I51mUm36xn8jlEOsyq02O5u8g==
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=A4Z9+LUwwUfJH4SrNkv1fo7udWuHs5t2KQpnN/guLrA=;
 b=LHjqoRzt5SlobxPRICWxv+lCEDW762cMavpSEiweutSgXcjRW4rngjrNXaTpHqMpMf4fm5QG/ThzLSA2Uo8PMsg7MiHbiPI8xDHrCretrNmT54RvnHOcwfTzsX+g5kR+vNhn8zXCfocKjYmMGSqAvMb0L2XgOarL5MXwuRHvIlzrCZQ+Bs5f6SqAHEi7jdnwn0C6DKJkRc/nZLcumOj3iwaAC2VQ4/Z8jKfmXZcvsdTC0IOdG9vgTlN+KzPKbG3ExunD9QS/asFjwFud0uxRlBkpKM7u+SSoW0TvlSzALv5exdCzM72YzUAexMuVKLwg78UhU75yz+U2UUL9EaIXsw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <691c8b06-b30a-4d2c-b371-fc4f47bf431d@epam.com>
Date: Wed, 24 Sep 2025 18:39:17 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 xen-devel ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Boris Ostrovsky 
References:  
 <05e9628d-83e5-4feb-881d-5854b72bd560@suse.com> 
  <8f6b8f08-ca62-467b-a6be-4d33208e5393@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: WA2P291CA0003.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::7) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AM9PR03MB7074:EE_
X-MS-Office365-Filtering-Correlation-Id: 30a3eaf4-3dea-4f4b-679b-08ddfb808683
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?N2lBVURpRGRaaWJROWVhTjBQS01JTGZTMjNaMGlpenVXNXZCY09XMHNuQm82?=
 =?utf-8?B?Q2E5TWFEZjl0VER6NzBQbHFQMDNZaVROZytqb0pJZCtiS3Bod0JZT0p4ck93?=
 =?utf-8?B?SjliQW5WWSs1a1JaZ2Nxc2NseWJrWUZaMFJKMnBIY2w5NU5uNGFka1FyOVMy?=
 =?utf-8?B?azJnU090TklCenJmWjBHbjBLZUFaWk44QlNQSnFjR09UbDZIVHhXYW81MW5h?=
 =?utf-8?B?MnovOWdkYzd1TXgyWjIrWkVYZTBSRzV2VXRXdjJWN1ZBeXYwTTZibitSZk40?=
 =?utf-8?B?a2FVN1cyTG95RDk0amFFUm1XMk5uQm5KNXdGRE5UU2ovZXI4WjR4Q2NodXR2?=
 =?utf-8?B?UTRJUVRtWnp4SS96aXIrSFpRdnlxUktRSXdDeFJZbnl0RU1mcWw2b2RTSE9a?=
 =?utf-8?B?bDJ5K0pKTWowb1gxdlNBY1pDaFN4SU5LN1dYaU9oOHhSbTJmRHpmc051WlNT?=
 =?utf-8?B?SjdXNWQ3SW41NHJ0RGJ6Q0JBSFV5SlorMDkzLytYRythWUFVVzBwVGFlWW9z?=
 =?utf-8?B?VW9xR0J3V1ZEYXY3NkUydWZoUW8rc0I1T0dGMGJlUE1MWGFWNDFIWG1seUJE?=
 =?utf-8?B?WEY1S3lKOFU5UGVFbXI1MDRyWktsZjd6TCtlS1czaHNuaS94SlFEbjhWVWZo?=
 =?utf-8?B?R2h3b2RKbVB6NFpKNXY5THJ3N1ZKcGc2cTgxYnY4T3lOVERkTlBWOHFiNENs?=
 =?utf-8?B?TVVWS0FPMGRBN2Vob3Q4djdoRmhLNDUxSXI0RWV0SUhTcWZMc0E2dXBBcnJl?=
 =?utf-8?B?K3hIR3UwQzQ4Z1BjTnA5WVZZcmE1NS9zN2xuc1ZiczBsRk0ybUZOSW5iRThw?=
 =?utf-8?B?cVNQdEJucitnRE1EVHFHdW1tRHVjUHdBT2MzTVdqRUZNaVU2aWxlZk1kQjc2?=
 =?utf-8?B?NVNoelZZOXE1WWtMTFk5MDFFR3I1cTNXZlBjeVRHUXJCMG50NkVNV2tITGJG?=
 =?utf-8?B?VHQ0OUdWUUU0aFlxUkZwV2dMWHN1Q3hORWRoRkpEa2Z1YURzb3dYcVhENXRm?=
 =?utf-8?B?TDNGSWpyVGxqY2pzcEFqMFlRRjhhTkVnQy9vTzdIWG5hZzNHV0Z5OWVseDFo?=
 =?utf-8?B?SVlpblJZNHBSMDdrSDdoNzhDbXYvRUoxSWIxcGlPQ1BnRXNHbFJNRDFqWS94?=
 =?utf-8?B?cHR3YWp4Rmc1bi91cGRwSG5PS01TcTVYdmxlNU5XSFlsQkJ4by9JT3pnWkJ2?=
 =?utf-8?B?L096MGJ4cS92MkJBSEpvUThMUHhUODRBUE1SQUhpWU8yN096OFB2aUhVU28w?=
 =?utf-8?B?SGRBdDZVTjlHK0hMeG1BSHRSYlJHSUFRZnNXaVVaZUQ2R1pEbmFDZ3Z4b0Ro?=
 =?utf-8?B?aUF0NGUxZFpEbUphb1pwNU5FVjRXdFlnaFl2aEtQYXpOeG9wNHQ0aHJqT1V1?=
 =?utf-8?B?eTMyenE4cnRiekt0eFR5S1NLRXFnYTlaSFpYaDRyY3dONUpHMmVOSGF4S3lD?=
 =?utf-8?B?dFNTVnVyUDJ4TnJSOWdjM1hVazJoTEJMRWdRUmFqaWRLNjlidFRaREdIOE5P?=
 =?utf-8?B?VVZKMDl2VGY1b1dTMVFaVW1CUStCYjdQVFoyeEV1cmJIcVlRQlBnN2MzV2M2?=
 =?utf-8?B?THF2dUxTTHQ0ZFk1Z094MmZJSVAxSENTUXNHNG83Mi9Rb1RIMEROTjE2d1hl?=
 =?utf-8?B?dGx6TEIyT0hvbWRTMGE4MmIvTUFWaHFXdHFOWnJtSUc5RlpwcXorM2xscnpi?=
 =?utf-8?B?QVN2YjJSTFpHKzR4UUpJS2FGL3RweXU4YldBTkdjL09jT0N3ZklqcmhsZTFs?=
 =?utf-8?B?TDRtOUp2aXU5d1k0V1lwdFVNbldlSklTSGhLZFc4cUZjYXdxYlIxazNjZ1dK?=
 =?utf-8?B?bCtWQUViS2ZlM2N5cDFINzFYMDUzWThJNXRrY3A4cjRKZUdBcjhtVVZDNVFI?=
 =?utf-8?B?Q0xRcnhWRC9oWitLVHVLYlJTdVZkQzRYK29DQkxTRUsxNncxT3VjVlczaTk5?=
 =?utf-8?Q?RNTPmPQYUIw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZzAzTU1hRERJZDFwQ0R1UUVhY0lBZ2RhazZvNWp2ZVYzRXozZURFdnNSeEc0?=
 =?utf-8?B?YzZONENhb0NUbCtkS0hhUEZzWGVEZm8rUWZMczVCMmhkR28zR3FhYkZrQTlm?=
 =?utf-8?B?RTZTT3I0SkZVU1pVRG82dGpPTklxd1FMUk01REl5bDNsRkVRazdwL3lsb09q?=
 =?utf-8?B?Zk1Cb1ZtOFBsN3dxV0RmdTZFV1NVd2x0bzl5QWg2K1V0MFRZM2FRdjNjd3Zm?=
 =?utf-8?B?aVNabzVJTkpWemRHanhSTDRyTlA5YWhyODZZOGg5L1p1cG53MTlRZmdGZlli?=
 =?utf-8?B?cU1VdERNYUs1VFV1TVU1dWw1WEZNRWZsaWF6OUtTUDZkSmx2N20wNmhHbmFG?=
 =?utf-8?B?dW13QXRiNGx2MWtRS1hKTkVjQzhxSW5aZG00N0pkN0EwTmxpTkJVN0NrSk45?=
 =?utf-8?B?QWsraUxma2g3WnAwVVVRcnRkdkwxMmRXblBsTGVlVDRBZ0R4Z0g0dTJhOExh?=
 =?utf-8?B?bWdHRmcwc2w1RnF3YUdvUGkwZ1FvcFViQTkzcDFwNW4rWHhmcTJZNVo0eXkw?=
 =?utf-8?B?N3FKWXhyb2RoZFRlNG00OHl4a3JTUHpHWHltNWNIaXRtT29tOEVDeFZzWGh5?=
 =?utf-8?B?ZmJqS3RuYjZHWW1XSXI5MjQ0R3dMSWNiczZaVVAxUGxjOGJCWFFZLzI2dTVU?=
 =?utf-8?B?OThQc3ZDdGdxTTN0SW85S3VpbUsxM3pCMVgzV012OHZZZ0tsTmc2VFhkb2N2?=
 =?utf-8?B?TjVGUjJIWjgrOHZWTktsNVp3ZThTZGxVRVJZZGg2Wkt6dXFmOExNaDhwbE1V?=
 =?utf-8?B?eUI0Y3pQd0V5cWlaU1BDRVRGU1JFNUtBWTVYWm5SSWlwb1dWaXROVENVMzNG?=
 =?utf-8?B?Sms1OE01bVYzMVh5M2lnZjZtd0ZaWG1FN1ZEcUtBNUlaRUNxVmc2UGVxYWJt?=
 =?utf-8?B?OUgvSlVibllCeUhBdVB6aTRaaDRvQkl2bEwrbHM5akUrUTI2UHZJSmFwTlZ3?=
 =?utf-8?B?bStxRzRERk9sQ0hIUFUvQUZseE9SeTlRc3Z5SXJ0ZFh1WjEzSkN1TnhNcWZp?=
 =?utf-8?B?R2VyeWxkSXhQMkozNUhKUnR0dWNjbTZzSFlDMStTeWxBb2pRaWJXb3BsZkF0?=
 =?utf-8?B?THNSVWtLYVNhODgraURybjk2RWFtUDFPMkdLcE81UHdRaThvRWZHb05FSEZP?=
 =?utf-8?B?QUlVWlZVSzhNZzFRaDRPWlNSTmx6c1IwVm8vTU5FNGQwNmloRGdTUnk5Z3BK?=
 =?utf-8?B?bUM2S2plY3FGUWFHMzlZdWVHcUxYa1VpZHVFUXZTb1dJNCsyQ3o2OE9KTlpQ?=
 =?utf-8?B?TkVRUS9WKzkwYUhxcDArQ2dneFJ5WEE5eUhaaE50ZHY3aitYOVdmTXhoQWR1?=
 =?utf-8?B?ZVRvMEdIaWVKUW5tZkhzazNZdThWaDBIaUhkOW5tOWVDd1B5ZitMallCNjM5?=
 =?utf-8?B?YWg3b3BNWHpHSjg5STFsRnJPc29RUGlrbU9Yb1docWRUMjlvQVZVaEdXL1k5?=
 =?utf-8?B?WXc1ZkdEZEdLK0kwREhZbGtwNGQzRnJmZHcwdEs3eTR1NTh4NkY2YmRTa252?=
 =?utf-8?B?UlZRaENGWllvVnEvbmR0bVhuZStQS0hGc1poTmJ6T1FuZnExTndSOGZhNTVa?=
 =?utf-8?B?N1RpK3U1SEhTTTBMeWtWd0dyUGw0dms3ZzVSQUlUWU9ObnVja3FSakMwR3lH?=
 =?utf-8?B?aFBndGFjb0wyZWltKzd6V3ZPMmo3WWc0UWtRN1JIREF5dTNoMWxCVVc4d2pX?=
 =?utf-8?B?eUZaZ1ExclBiL0p6V0lPTks5K0hvVTYzTVlWaXpWMzBjMVU2TnNaNnZ2QWor?=
 =?utf-8?B?VUNaVVNTTnFkMmo5TXA2RzRXSUZHdVJZTWF2eWt2cVlQMXVTeFhoT01nbHNQ?=
 =?utf-8?B?UFg5Ymk2Zk5xM1ZNN1VoZzVMeWlZVWlpUkllUEV1Myt3WUVWb1B0am0vUzho?=
 =?utf-8?B?a3p0R3FFbkUrWlJBOWxiY3c4RlNPUnZZaXpyQjl0NWg3cGpqMFIvaklkbHFS?=
 =?utf-8?B?OUpzM0JlaHQ4czhabkFWWUhJYjdaRndEV2dJTXZsR0NrSzZwVmZ0bVZQTGJw?=
 =?utf-8?B?cGJ0NHJaRFZYa0Z0ZTl1WTg4M1JlSDVTQ05HUFVxRi80Mmx5Z1JhaHA3enQz?=
 =?utf-8?B?SHFIYXZsZk5GRkJzZEk0aWt4azBDbUp4Q0d5UjhKWGZjZDJPelFwYUR2alRy?=
 =?utf-8?B?MW41cDh1N25RNjJEU2ZncU9pZVZnQkJ6aFVrWDZvV1RkV3M1bmplTjdwenJk?=
 =?utf-8?B?SEE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30a3eaf4-3dea-4f4b-679b-08ddfb808683
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 15:39:18.9111
 (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: o5KxIL1+Vehce5Aa9kMsPvb8gYe9g10jsrrB79tUUpssqXxikzRGZSynCvBkhvuTkeJdK4IdDP6b/3IwTu+CRHAP43XgAt+B9aqOiywwNh4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7074



On 24.09.25 16:30, Marek Marczykowski-Górecki wrote:
> On Wed, Sep 24, 2025 at 01:17:15PM +0300, Grygorii Strashko wrote:
>>
>>
>> On 22.09.25 13:09, Marek Marczykowski-Górecki wrote:
>>> On Fri, Aug 22, 2025 at 08:42:30PM +0200, Marek Marczykowski-Górecki wrote:
>>>> On Fri, Aug 22, 2025 at 05:27:20PM +0200, Jürgen Groß wrote:
>>>>> On 22.08.25 16:42, Marek Marczykowski-Górecki wrote:
>>>>>> On Fri, Aug 22, 2025 at 04:39:33PM +0200, Marek Marczykowski-Górecki wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> When suspending domU I get the following issue:
>>>>>>>
>>>>>>>        Freezing user space processes
>>>>>>>        Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
>>>>>>>        task:xl              state:D stack:0     pid:466   tgid:466   ppid:1      task_flags:0x400040 flags:0x00004006
>>>>>>>        Call Trace:
>>>>>>>         
>>>>>>>         __schedule+0x2f3/0x780
>>>>>>>         schedule+0x27/0x80
>>>>>>>         schedule_preempt_disabled+0x15/0x30
>>>>>>>         __mutex_lock.constprop.0+0x49f/0x880
>>>>>>>         unregister_xenbus_watch+0x216/0x230
>>>>>>>         xenbus_write_watch+0xb9/0x220
>>>>>>>         xenbus_file_write+0x131/0x1b0
>>>>>>>         vfs_writev+0x26c/0x3d0
>>>>>>>         ? do_writev+0xeb/0x110
>>>>>>>         do_writev+0xeb/0x110
>>>>>>>         do_syscall_64+0x84/0x2c0
>>>>>>>         ? do_syscall_64+0x200/0x2c0
>>>>>>>         ? generic_handle_irq+0x3f/0x60
>>>>>>>         ? syscall_exit_work+0x108/0x140
>>>>>>>         ? do_syscall_64+0x200/0x2c0
>>>>>>>         ? __irq_exit_rcu+0x4c/0xe0
>>>>>>>         entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>>>>>        RIP: 0033:0x79b618138642
>>>>>>>        RSP: 002b:00007fff9a192fc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>>>>>>>        RAX: ffffffffffffffda RBX: 00000000024fd490 RCX: 000079b618138642
>>>>>>>        RDX: 0000000000000003 RSI: 00007fff9a193120 RDI: 0000000000000014
>>>>>>>        RBP: 00007fff9a193000 R08: 0000000000000000 R09: 0000000000000000
>>>>>>>        R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
>>>>>>>        R13: 00007fff9a193120 R14: 0000000000000003 R15: 0000000000000000
>>>>>>>         
>>>>>>>        OOM killer enabled.
>>>>>>>        Restarting tasks: Starting
>>>>>>>        Restarting tasks: Done
>>>>>>>        xen:manage: do_suspend: freeze processes failed -16
>>>>>>>
>>>>>>> The process in question is `xl devd` daemon. It's a domU serving a
>>>>>>> xenvif backend.
>>>>>>>
>>>>>>> I noticed it on 6.16.1, but looking at earlier test logs I see it with
>>>>>>> 6.16-rc6 already (but interestingly, not 6.16-rc2 yet? feels weird given
>>>>>>> seemingly no relevant changes between rc2 and rc6).
>>>>>>
>>>>>> I forgot to include link for (a little) more details:
>>>>>> https://github.com/QubesOS/qubes-linux-kernel/pull/1157
>>>>>>
>>>>>> Especially, there is another call trace with panic_on_warn enabled -
>>>>>> slightly different, but looks related.
>>>>>>
>>>>>
>>>>> I'm pretty sure the PV variant for suspending is just wrong: it is calling
>>>>> dpm_suspend_start() from do_suspend() without taking the required
>>>>> system_transition_mutex, resulting in the WARN() in pm_restrict_gfp_mask().
>>>>>
>>>>> It might be as easy as just adding the mutex() call to do_suspend(), but I'm
>>>>> really not sure that will be a proper fix.
>>>>
>>>> Hm, this might explain the second call trace, but not the freeze failure
>>>> quoted here above, I think?
>>>
>>> While the patch I sent appears to fix this particular issue, it made me
>>> wonder: is there any fundamental reason why do_suspend() is not using
>>> pm_suspend() and register Xen-specific actions via platform_suspend_ops
>>> (and maybe syscore_ops)? From a brief look at the code, it should
>>> theoretically be possible, and should avoid issues like this.
>>>
>>> I tried to do a quick&dirty attempt at that[1], and it failed (panic). I
>>> surely made several mistakes there (and also left a ton of todo
>>> comments). But before spending any more time at that, I'd like to ask
>>> if this is a viable option at all.
>>
>> I think it might, but be careful with this, because there are two "System Low power" paths in Linux
>> 1) Suspend2RAM and Co
>> 2) Hybernation
>>
>> While "Suspend2RAM and Co" path is relatively straight forward and expected to be always
>> started through pm_suspend(). In general, it's expected to happen
>>   - from sysfs (User space)
>>   - from autosuspend (wakelocks).
>>
>> the "hibernation" path is more complicated:(
>> - Genuine Linux hybernation hibernate()/hibernate_quiet_exec()
> 
> IIUC hibernation is very different as it puts Linux in charge of dumping
> all the state to the disk. In case of Xen, the primary use case for
> suspend is preparing VM for Xen toolstack serializing its state to disk
> (or migrating to another host).
> Additionally, VM suspend may be used as preparation for host suspend
> (this is what I actually do here). This is especially relevant if the VM
> has some PCI passthrough - to properly suspend (and resume) devices
> across host suspend.
> 
>> I'm not sure what path Xen originally implemented :( It seems like "suspend2RAM",
>> but, at the same time "hybernation" specific staff is used, like PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE.
>> As result, Linux suspend/hybernation code moves forward while Xen stays behind and unsync.
> 
> Yeah, I think it's supposed to be suspend2RAM. TBH the
> PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE confuses me too and Qubes OS has a
> patch[2] to switch it to PMSG_SUSPEND/PMSG_RESUME.
> 
>> So it sounds reasonable to avoid custom implementation, but may be not easy :(
>>
>> Suspending Xen features can be split between suspend stages, but
>> not sure if platform_suspend_ops can be used.
>>
>> Generic suspend stages list
>> - freeze
>> - prepare
>> - suspend
>> - suspend_late
>> - suspend_noirq (SPIs disabled, except wakeups)
>>    [most of Xen specific staff has to be suspended at this point]
>> - disable_secondary_cpus
>> - arch disable IRQ (from this point no IRQs allowed, no timers, no scheduling)
>> - syscore_suspend
>>    [rest here]
>> - platform->enter() (suspended)
>>
>> You can't just overwrite platform_suspend_ops, because ARM64 is expected to enter
>> suspend through PSCI FW interface:
>> drivers/firmware/psci/psci.c
>>   static const struct platform_suspend_ops psci_suspend_ops = {
> 
> Does this apply to a VM on ARM64 too? At least on x86, the VM is
> supposed to make a hypercall to tell Xen it suspended (the hypercall
> will return only on resume).

On ARM64 Guest expected to trigger PSCI(SYSTEM_SUSPEND) (which is HVC - trap, similar to hypercall on x86)
PSCI is Arm Power State Coordination Interface which defines unified FW interface for PM.
So if you overwrite platform_suspend_ops (which is Singleton) it will break ARM Guest suspend.

> 
>> As an option, some Xen components could be converted to use syscore_ops (but not xenstore),
>> and some might need to use DD(dev_pm_ops).
>>
>>>
>>> [1] https://github.com/marmarek/linux/commit/47cfdb991c85566c9c333570511e67bf477a5da6
>>
>> -- 
>> Best regards,
>> -grygorii
>>
> 
> [2] https://github.com/QubesOS/qubes-linux-kernel/blob/main/xen-pm-use-suspend.patch
> 

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:40:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:40:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129522.1469443 (Exim 4.92)
	(envelope-from )
	id 1v1Rbn-0002rD-1h; Wed, 24 Sep 2025 15:40:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129522.1469443; Wed, 24 Sep 2025 15:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Rbm-0002r6-VD; Wed, 24 Sep 2025 15:40:42 +0000
Received: by outflank-mailman (input) for mailman id 1129522;
 Wed, 24 Sep 2025 15: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 1v1Rbl-0002pn-Dc
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:40:41 +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 d26fb0b3-995c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 17:40:39 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-62fce8b75a3so9679809a12.1
 for ; Wed, 24 Sep 2025 08:40:39 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-62fa5cfa883sm12792294a12.11.2025.09.24.08.40.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 08:40: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: d26fb0b3-995c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758728439; x=1759333239; 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=wVBKlxFl0q41Dyy+SNAdonJB3IkGEvRpEGHFUwik7Jw=;
        b=feoQ6gpXkki8v6XuX9GbZDGvqN8nMytXJv1ZThVRazpOZ1F5qsNBLg5rftbM6jsgKW
         zLepeQZT8w1FuUFsYPFGz5W4iRB+SH+QJDDy6Ghiv48TH+Dvye4HdjjSGhx82tT2mmU6
         pPz7DA+IDGqX7xxIvcVXlJqvnvq8pkbqNQprPlaLHv+GdsTBS3pNDpfeyHupbJxeJ8Zh
         fBA8eF2aBj/gyWYFRoE+CiawghA45N7w4vffr9uB5OtPkylOOq8I+3gFppKqQb8XBDD7
         v+6cmeEkJF6hvBTUgez2KQEGyK+dS9Em6yicEjWWe8NGz5Ma0jQRMmJk/C92H26bRzFL
         cE9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758728439; x=1759333239;
        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=wVBKlxFl0q41Dyy+SNAdonJB3IkGEvRpEGHFUwik7Jw=;
        b=c1zh6m3HoOv9oWxqwc7rR7Qq89JOl0XUWkxgtRn6OP8naaq81lBPwAsxk7Y4hh6YXm
         mnBtaXRWLGrpJhKUKjCxfCLanpqJ/zLlaoAgXlY7W7S/8sIbBOnnn2NVcE8oHA8r+phu
         a+FvlOVePp/ElZOgYzZ+/UtIPN8dAyyHMH+QuIGPIZsaf2e44+RyPUIr3s/snklbSHdc
         ngwvvcllvyMushZ39b7Asa1qUzBY1VyBT+SQLvstz4Bo1ry9XsY2+X47YaQJprY5ZpdR
         vvSGLWJKuL0YFwznIFwji1zkNdvYQcSgm5oxKnaf38jt9DeJq72dbEtceuDv4UP7cWIP
         cu9A==
X-Forwarded-Encrypted: i=1; AJvYcCUPJ/6SvnLNX5Y602HwEG1+7JPoGzg4QWLfS0j09EvzBOM6QtYvnjaQcBSW5dCqxgAUTQuELY8FiDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzJOAfBfzsOwNL/cXNdJ4HMvQ2jIr3YNC4O7idM/SwyU3lYYuW
	xiMIPv11Gqz3xenyBkeG3ric72VK2tiQNcxvtKo8jgzLZ5aNBf6x3umC
X-Gm-Gg: ASbGnctx17yHPBRx+VwiR6GEOnK7xVPPndkIUfHclyvyhR+Ios35R3Obtck7QpWsQNK
	C0rzskO/04y31F04MCtOoZYu0+Is+gHi3Hv9ziuY8YMx/vR49EDhdd8VU745EFceZU4FKY006hi
	ROq6jPJry+pkQFIRWpuzhfUWjuafvM/hFwSj7Ca1diiNzl+0/BnHZJ5GWZkp2IqCYEeom6ugzEG
	qrmUMbw/5Tld2GRZOzzzNuhQ1SdMiISHDC+ROOKVvN0G3KOV/0cnv10euhbd7ZhqLKey45/9BUb
	dPDYUfVkHdmhM3MrxRxnwKpUTOEeYbpuU7GqerkUbKiiCqIerfdXt7Bo9Ak0d7sKkiHyD1XWpH/
	U84GHyAw48GEat7U+IB0L2dQV3zYfYCdnGs9D/hmwz8mEeUe/AGbbUtRm8cu3aaZB4uZKzDZ6
X-Google-Smtp-Source: AGHT+IERDAEwh5Zcaqw9MJW4RwnxelL38x+IM1tVUdsvkKUm82nki96yCEqfNnZB7mu68in5mS03Mw==
X-Received: by 2002:a17:907:7245:b0:b0d:d831:6fb8 with SMTP id a640c23a62f3a-b34bc584811mr25134866b.62.1758728437255;
        Wed, 24 Sep 2025 08:40:37 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------6YyVHfXiWVeBQLQJtUOQiw52"
Message-ID: <31a0e82c-6855-41d3-ad9c-282261012656@gmail.com>
Date: Wed, 24 Sep 2025 17:40:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/18] 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: 
 <2b636ea03bf82cae50df87d525e3f58b68f16cb2.1758145428.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/20/25 12:14 AM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>
>> +{
>> +    return MASK_INSR(mfn_x(page_to_mfn(p2m->root)), HGATP_PPN) |
>> +           MASK_INSR(gstage_mode, HGATP_MODE_MASK) |
>> +           MASK_INSR(vmid, HGATP_VMID_MASK);
>> +}
>> +
>> +static int p2m_alloc_root_table(struct p2m_domain *p2m)
>> +{
>> +    struct domain *d = p2m->domain;
>> +    struct page_info *page;
>> +    int rc;
>> +
>> +    /*
>> +     * Return back P2M_ROOT_PAGES to assure the root table memory is also
>> +     * accounted against the P2M pool of the domain.
>> +     */
>> +    if ( (rc = paging_ret_pages_to_domheap(d, P2M_ROOT_PAGES)) )
>> +        return rc;
> I read the "ret" in the name as "return" here. However, ...
>
>> +    /*
>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>> +     * 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, P2M_ROOT_ORDER, MEMF_no_owner);
>> +    if ( !page )
>> +    {
>> +        /*
>> +         * If allocation of root table pages fails, the pages acquired above
>> +         * must be returned to the freelist to maintain proper freelist
>> +         * balance.
>> +         */
>> +        paging_ret_pages_to_freelist(d, P2M_ROOT_PAGES);
> ... "return" doesn't make sense here, so I wonder what the "ret" here means.

In both cases,|ret| was supposed to mean/"return"/, since in both cases we
“return” memory.
I agree that in the case of|paging_ret_pages_to_freelist()|, the flow is
slightly different: a page is allocated from the domheap and then added back
to the freelist. That looks more like/adding/ than/returning/. Still, I felt that
“return” could also apply here, as the page is being given back.

For more clarity, do you think it would make sense to rename
|paging_ret_pages_to_freelist()| to|paging_add_page_to_freelist()|?

~ Oleksii


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



  
    
  
  
    


    

    
On 9/20/25 12:14 AM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:



      

        
+{
+    return MASK_INSR(mfn_x(page_to_mfn(p2m->root)), HGATP_PPN) |
+           MASK_INSR(gstage_mode, HGATP_MODE_MASK) |
+           MASK_INSR(vmid, HGATP_VMID_MASK);
+}
+
+static int p2m_alloc_root_table(struct p2m_domain *p2m)
+{
+    struct domain *d = p2m->domain;
+    struct page_info *page;
+    int rc;
+
+    /*
+     * Return back P2M_ROOT_PAGES to assure the root table memory is also
+     * accounted against the P2M pool of the domain.
+     */
+    if ( (rc = paging_ret_pages_to_domheap(d, P2M_ROOT_PAGES)) )
+        return rc;


      

      
I read the "ret" in the name as "return" here. However, ...



      

        
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * 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, P2M_ROOT_ORDER, MEMF_no_owner);
+    if ( !page )
+    {
+        /*
+         * If allocation of root table pages fails, the pages acquired above
+         * must be returned to the freelist to maintain proper freelist
+         * balance.
+         */
+        paging_ret_pages_to_freelist(d, P2M_ROOT_PAGES);


      

      
... "return" doesn't make sense here, so I wonder what the "ret" here means.

    

    
In both cases, ret was supposed to mean "return", since in both cases we
“return” memory.
I agree that in the case of paging_ret_pages_to_freelist(), the flow is
slightly different: a page is allocated from the domheap and then added back
to the freelist. That looks more like adding than returning. Still, I felt that
“return” could also apply here, as the page is being given back.

    
For more clarity, do you think it would make sense to rename
paging_ret_pages_to_freelist() to paging_add_page_to_freelist()?

~ Oleksii


    

    

  


--------------6YyVHfXiWVeBQLQJtUOQiw52--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:45:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:45:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129539.1469453 (Exim 4.92)
	(envelope-from )
	id 1v1Rfz-0003T9-Ir; Wed, 24 Sep 2025 15:45:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129539.1469453; Wed, 24 Sep 2025 15:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Rfz-0003T2-FN; Wed, 24 Sep 2025 15:45:03 +0000
Received: by outflank-mailman (input) for mailman id 1129539;
 Wed, 24 Sep 2025 15:45: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 1v1Rfy-0003Sw-0M
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:45:02 +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 6e1e7c46-995d-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 17:45:01 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-45e03730f83so31301765e9.0
 for ; Wed, 24 Sep 2025 08:45:00 -0700 (PDT)
Received: from [192.168.1.183] (host-195-149-20-212.as13285.net.
 [195.149.20.212]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e32b4db71sm627895e9.1.2025.09.24.08.44.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 08:44: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: 6e1e7c46-995d-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1758728700; x=1759333500; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt: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+IHe9qKQVrqrZmSJcCWnSM95WGYUKAaUtGK45Vyh9I=;
        b=JCDjJvpJrfSE7si8YjtP+jivMJO92JYhSjiVmDjEk2MO4NVkDFSRYIMR82b1MavJRs
         886tmUlXohdoYbmOQHsQpflphY7FbrbO3J7srPPzYJzpTTmsln5LffmH2FXG5qhI2KhE
         I5HB7jigz6XztIgDwH0uu2tPWNbPKkxVGOXQ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758728700; x=1759333500;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references: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+IHe9qKQVrqrZmSJcCWnSM95WGYUKAaUtGK45Vyh9I=;
        b=MpYx13736VSZaZ7tIt+xpvThjF/egp67c6wR8JggzhQS0fwLe4VgTGDW62RbF0qmcC
         VmkXhDjRZXN0BkU0zpRth420KfeCe7r5ENKVlfSSeWycTuPjXJdyx9ach8h8hJf+i50C
         1Ds+vP76R/lrxlo3S1UwszBzrq/W9At8F5J2s6CYX7/SHDeYsI5TLkv/45XDFszxpGw2
         eTnfmyzwOrWJX8vKGldFbGUaPjF5xWR/qUjj+x0safyNMmnrwaVOmu7NZmt/4i6Sq0FX
         QFNmpsMLHEyccBbY3qw6sz2+YHXyjkgivcIQP1Tosv2NzVxCnkf2fYFftx1xytGhKLnk
         bpvw==
X-Forwarded-Encrypted: i=1; AJvYcCVR0ZobqehvdEtHmSjW1TuME9Ruic+J1cdxpLbddYsljYxvUmfD/RCTJGexAZrYvXeYVpTD/vnIjVY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzA0oC8ECoUcuQbO4OGjal+RhsIY4fEOUP+lKwCtOp92RDXN3Ls
	HNTMcKgbLMwM3Y7SASjLyN8Bg7raw4T83NVzdS5UCYLVRruAgdnHwv2O8KbkP0RmgLs=
X-Gm-Gg: ASbGncuiQ6xOIxRuFqBaYAH+YhbTlN1kEmc3ilUCFdDgPh7ksCzFI4KtJK3qEj2HfMB
	0K/0KsNDOeyAytOqp1frefkRwL+xZ3juG6d2cXwNBvvhfnVdZabcyGpz541D+ovjLCsjbb8kcBK
	wG12z5vIIZard9W8srQO7NTD7rLtC79UwsZocJi0WBIwrLXeBg11PMzwz97DKe8WVbYHvObcOdw
	1eyBWWt/uGhT+zeMR0l/AwjIA2xMBRdEXd30F0s1sZWveqkWS69ij+I80SEldvpEH59gY9Mm5FJ
	bLt3Hp7CPhisS+ycMXG1QT/biEfqYHV9AABbgWEt69+NWE7sAH7Q/7dPSIXTXgxk4oxMcp1FiGH
	2To6M6QkB8ev15y/oOdtLKiygnHUcEB3z/oHbqs5sCL9ga7zJHlGf/kI7JRMMJ4pt7tkI
X-Google-Smtp-Source: AGHT+IE2Fxv2nPIF15hQ4Z5YMTqJ5ocrjxDevA9lxfUnk2qmvzgeqB+K/1s1jaY/GcRPraEbvCNO6A==
X-Received: by 2002:a05:600c:3b8f:b0:46e:23d3:6415 with SMTP id 5b1f17b1804b1-46e3299ee26mr3675385e9.6.1758728700121;
        Wed, 24 Sep 2025 08:45:00 -0700 (PDT)
Message-ID: 
Date: Wed, 24 Sep 2025 16:44:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/xentop: Add documentation for physical CPU
 monitoring feature
To: Jahan Murudi , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Oleksii Kurochko 
References: <20250904172525.2795998-1-jahan.murudi.zg@renesas.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: <20250904172525.2795998-1-jahan.murudi.zg@renesas.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04/09/2025 10:25 am, Jahan Murudi wrote:
> Add man page documentation for the new '-p/--pcpus' flag that displays
> physical CPU utilization metrics. This provides hypervisor-level CPU
> usage insights alongside existing domain statistics.
>
> Changes include:
> - Add '-p' flag to SYNOPSIS section
> - Document '--pcpus' option with description
> - Maintain consistency with existing documentation style
>
> Signed-off-by: Jahan Murudi 

Acked-by: Andrew Cooper 

This needs a release ack now for Xen 4.21 (CC Oleksii), but it's a docs
patch for a new feature so ought to be considered.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:48:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:48:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129551.1469462 (Exim 4.92)
	(envelope-from )
	id 1v1RjW-0004BZ-0l; Wed, 24 Sep 2025 15:48:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129551.1469462; Wed, 24 Sep 2025 15:48: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 1v1RjV-0004BS-Tx; Wed, 24 Sep 2025 15:48:41 +0000
Received: by outflank-mailman (input) for mailman id 1129551;
 Wed, 24 Sep 2025 15:48: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 1v1RjU-0004BM-Jd
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:48:40 +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 ea466ede-995d-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 17:48:29 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS8PR03MB9048.eurprd03.prod.outlook.com (2603:10a6:20b:5b5::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Wed, 24 Sep
 2025 15:48:22 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9137.018; Wed, 24 Sep 2025
 15:48: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: ea466ede-995d-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Pm1vsnrHPZOq8+ZH7cL8b8tmGQe055bSyLGeTZF3I3N29AlMjE+0KqjR041BjQMq50t/qnYnHQU/ZlX80On/6wfkow8H4Zwms1uASSgePIGYqzAKQsaeqZsxwlZVdo0WZzJPX40HfhhnVMHzwxVHZ4SALyZj6Cld6NmXsv2j5fc8vvmLWWvLr626pywsrWIJRzeHqWrgO/Hkz8W1IwBmauxQnjy6S1TNMiMMT+nFbSwLIUFnreCGWKagT6XrCKoBitXgjLXBpO25nUmn3SrPNtdGOatm+navFjPdbclMx+iVh38XrYHzW6fX5qnXNnRHbgZ7M3x7K8pKeD0lxEVg8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4MfyHMCRP8HPtzZVYgkMnCz4+pmtmTOZLz4wlduRlZU=;
 b=ic0ezPJW0OfzV3cvwWbLGN+9Cgv9KwwWIRIhinsbsLiLoJcn3aORoG0gJsafbwcIB0aeMXbvphVQmR3lV0nTqUN6kj4FyUdwksC/UtIsb2K/jJjde426OlrLCEafcsMEWsmmqGPPR9NXq3JBwiX9SXG6heJGSxbO8FfHlJPF9IPFGiAJuYrLYy1vKevf9Lw9X/SzaL+poQICZaph+aY1p39J4gckoTy5jpQSqlXRpVjPoldYcSO/Wvu1iknd9lokujAB9AymAB1ToX/kRE4WG0SgVXsIDCeJ7wqD7D/L8dg9cjQRpPzwLGU3TpF7cwL6rWUQ6bUTQLuIyaVvaXVikg==
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=4MfyHMCRP8HPtzZVYgkMnCz4+pmtmTOZLz4wlduRlZU=;
 b=oZ+XSFHGzh9aDOP8PMR6Z4Ocvdq1rqEMCodgWzMtA5L2KJjm5WGqmSc/A6WEZSBlBsj5fzDdLldGUBiaXF0qqlvaafxEpGtPmlkRxQhm7vWIuSHFk8tOadKaPyfYDDRKYQML4KtLKAesPRGDUjvNZ4AD7qWmAilRGr/A9axiHG6IGakkhwAfgVkngaJAKy5MpRzWfr/lq0IsVk60E61a6ALV0MK4ibwEOQC5EJbenrCryXhqT5zuXtIJOfK3D+320kQRsCmzxc06w3iNSjIeowGx0sIxzhRW7rDgVjO57bWZrU9J7q3UHo+rAljOzbA3psWwkXZoVLkq0n8g5AER0Q==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <054b31c6-8911-495b-a8b4-b7a807c95786@epam.com>
Date: Wed, 24 Sep 2025 18:48:21 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
To: Ayan Kumar Halder ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Michal Orzel ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
 
 <762b9d19-f1dd-4bfe-a298-d88ab8e7bbd2@amd.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <762b9d19-f1dd-4bfe-a298-d88ab8e7bbd2@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: WA2P291CA0009.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::6) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AS8PR03MB9048:EE_
X-MS-Office365-Filtering-Correlation-Id: 58f2c99b-fa92-45b4-d1e9-08ddfb81caa1
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?NWZRZnNrTWtjVGZ5dDdWWSt1dkZ0NXpaYjdGdGNibzJscEduZFlXQmZZT1FM?=
 =?utf-8?B?UUcvd3oxVGZEYUwrdHpGOExFU05XYmNObDI3R1FxZ1FTVml0VGJaRXFYWFJN?=
 =?utf-8?B?dm5TMHgxUWtCaGV0NlkycWYyck9kRWIraVFocVR6MmFWUk5Hb3dadGdtMVE5?=
 =?utf-8?B?cGVlUndndlVxK1lNanAzMXhxWU1LMkpYYmhmS0xHZEZDWnQ1N1NYUjhzOS9y?=
 =?utf-8?B?NTdWaW5KV3FPMzVRKzE0MDdrQUpnOTJVajR4K1owb0pQbENaTnlWNUdsVll2?=
 =?utf-8?B?eXJDOEN6cEpmOXRnQjlCQS9zRW5wRU1xZy9vZGVFN1Fwbk1rSXRRKzh6djlq?=
 =?utf-8?B?OEl0bmhaRUJ1d2JyUUVac245R28zL3VuRFNxUXZyNGVpVHQ2RjBFR0hrZGJT?=
 =?utf-8?B?eUo0VU5xRDY4UkFlYXFBYXh6U04vMEp1NC8wbllEU2RnYUI3T1UrRENOMC9G?=
 =?utf-8?B?bnNXOEpSaG51c3pZT3I4M1pGVElNR1FsNGhzVHpCUE5QcnFhSEUydTFMbC9n?=
 =?utf-8?B?RG1TQ3U3LzAwVWlWVHE2dDJ6OTJ3ZTRpZ3JKWFlsUFBkTkluSUlkYjNzZUR5?=
 =?utf-8?B?L2NnQ2s2WXI1dG9BRk4zWVdTM1JUcWNCcmRoZVBjNHNQRnJYamtiVmpVMkFG?=
 =?utf-8?B?M0hsZ0IvQnhJUkpPS0pMNVM2Z1BZN3k4TjVjUVRacm5ScHJrUEtlZGk3ZCtR?=
 =?utf-8?B?YnExUE9CdHVDeTZMaFdhMVZRLzRpbVQzd1VrNmVoV2VZU3ZvUjZFY2JtU1lU?=
 =?utf-8?B?L0NsbTQvMHkrMFZEVkwrRXZjaFBqYWYwWmtNK25lTzF2ai9UNzhSb2MwK1BO?=
 =?utf-8?B?NWNnbkRsdy9WM2RmeGV5ZGl4VE1UR2d2eTR3SlR5N1RaYXpzTjF6M0FRMFo0?=
 =?utf-8?B?UXc2ZTdRWWdWeXorcUpodTgrVUtqcVRVWkxnOGR4VXFNZ2ExdjNIbmpSTG04?=
 =?utf-8?B?V1NQQnArbSthM1JrbHlseGs1Q3BPTEhEVWFzSjRxMDRGVXVtNFVnWU0ya1lJ?=
 =?utf-8?B?bUowUXVCQm5KQTNoQm9tSFdpVVpFWlExdC9xUGEyL29BZTNDbFVEeWUzcDd0?=
 =?utf-8?B?cmJmbG5ueHlkVEU5ZUExN1pXVmJNKzR0VllHdG0rOUJTeGpMaUtyK250WUk0?=
 =?utf-8?B?VW5vRlBpUFp6MlluMHhRMHZ6YXE2bW1qWXFTNWc5cS9ZSVVFOEhNbEdKUHhS?=
 =?utf-8?B?dUFWL3FkSnVBeXRUUUE0NEJGalFlMkdldlEwbzVpajNNY3hGWlZFZXk0MFNz?=
 =?utf-8?B?VFZHZ3hLMllGQ09rT3cxWXdCZ25qVFJBQlBvTFozVTZrL3p1dHBDV0EwWmtw?=
 =?utf-8?B?VG8vc01keWxObVBKbXFSWnpSSjBvL0wwR0hjL3V5d3g2ZDdmeFdFMG1UZEdR?=
 =?utf-8?B?VGI5b245Mmc2ZWZ5VldSRGlqeENTZmZRSmxmWVpvMUw0VHdUd0pvUWtGb2NQ?=
 =?utf-8?B?RFNyOVJRbDFiYWxLOFBZVVRZbVVBMjBZb0F4b1Nma0d6bFZpWGRiZS8zbTgx?=
 =?utf-8?B?VXZRM3ZXTFpWOURwbTF6YVZxTVdZU3pvUzgyTnFXYVVVT3llNmY4dXNpU3VE?=
 =?utf-8?B?bUo0TXpIVnVkUmlhN05ITUd4blc3eGZnM2FnVTRCUUNtYVpMeVBiZFlCTll2?=
 =?utf-8?B?WE9NbXY5VmdYVzNGMjI1d2pVb2haUkdNajFEanAzMW5wNjF2QWNVVmdvVk9I?=
 =?utf-8?B?SHorWFJELzZtbGpqVFQ0UUptRDBTZXZFbW92S0RlbXpJeXp1anRWR2Q2b2Q1?=
 =?utf-8?B?d0pTTUhOOUtDYjlMWXM0WTdsdFE2MG1PcFdMdHFCTWg2cWZqQld6NlVIT3c4?=
 =?utf-8?B?Z2VvMmhSNUc3RzEyNmdwaUdIS2EybW5KKzJmdWZwTG5TTnVEWk5pSitwR2pR?=
 =?utf-8?B?SlpvZWcrMmtGcVE4dTVBNUp4Q0JPZmxNZnpzdkZQQmsrR29IMVJBTHdHd2Ra?=
 =?utf-8?Q?kejke7TbG2w=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZGhCdURPWkZBang5YUduQUtlZHF5V0VDL1JkSVZIeld2Zlh3SmpTME5GOU9w?=
 =?utf-8?B?SmUxVkk4dUNiUm5EdHk4UFhtUEVTanY5WXBrMTRMNC9xamI2c0x0QmxhY213?=
 =?utf-8?B?cXVyRzNMSk1RSnNpcS9XWmswSzdLV1hKU0VlazdaQVNWWFdFcC9tRXVIck4y?=
 =?utf-8?B?bk5BNjd1VFdUMnhhOWxXcjNmaHA2MWVtUCtDS21pV0puYWdaWjBEKzFOQVZR?=
 =?utf-8?B?RVlpcFoydVYyZ0U3M0ZEc3llUEFyV0U1MGJZUEgyZWlqN1dMbTVSVmJuYmZO?=
 =?utf-8?B?V0ZoSWpVMVh3b3Rtc3dMWDVITkFIckNNdDEzdmltVEJ4MWlodDBOT21xWjFQ?=
 =?utf-8?B?ZXJ0R0dYcVRpdkJNZzZxY0tiVEpBTzRrTW9MSVNIREhXc1NPaTh5dHIyY0tn?=
 =?utf-8?B?VGpiMzcxdFJORkQxUThIWkVFRVVKY2RUeWVLN0FDMUlUazk1eFFreWpDUm5U?=
 =?utf-8?B?VldGazY2K3J3V3RYcTRzZ2h6NGxKL1QxVlBnQ29VSFFkMUdVU1E1Vi9lRUZT?=
 =?utf-8?B?Y1FLVHdMdXlKd1V2VHVrZGlyeVllVDdMSHcxYis3WVE1VlNYK25oc3BQN3ox?=
 =?utf-8?B?NE5HM1hrVXI4QlVUYlN0c0FMTVQyTUpWS2xMR2liRGxybnVSdlpCcEMyYWxq?=
 =?utf-8?B?Q0wrbFVmejNVd05MWk9rcE9HRFNDNElyR1RueVcyaWNETXhVTUpaYzJCT0Vw?=
 =?utf-8?B?SjRJMjNIbk1sT2hKUjVJNlhLdDdMNHI4L29NN1VBdmlxbkpDdjl3MzJjcjZq?=
 =?utf-8?B?Q1NKRUFDOWpHaFhPYXhjUTJRTHUzVTkzVE1CWVh4NWJVSURibWNxNzZmd1JM?=
 =?utf-8?B?S2ZYMUJjV0poZE9SMnNVSnZzdHBScVB1YVdhTDR3VU01MTBYN1ZPa21mb0lH?=
 =?utf-8?B?NEFMVUVQMUZ4NXI0Z0xwSW1QdGthT3hiZTZBaTJzdmZwR3hwaUM0eXFhZlc0?=
 =?utf-8?B?U0JMNGp1MEVSVGdraThtSU53QmhSYitQNnM0K1Rqc0E4L1ArYjlKVzN3YXJK?=
 =?utf-8?B?VmF1RVdrS2ZNRlVNWkdLZzF6UnRYVHphekpWeFl1akh0OWRDNmF5RE0wY0ph?=
 =?utf-8?B?eUhUN3FpeE5aSm1mOUdlTmNYOVBnVW8vY0VZL1hqZW42NmdiN09PeU5wWkUz?=
 =?utf-8?B?eU1KMlIyVHNYQkdXTUh0b0RjSzFSUmhHc0g2MFNGZ1Y3ZTZtL1hkdEdDallR?=
 =?utf-8?B?SUNxd2lPeEdCOXpEbU5UN2tMSUVzUEFzL0FhRlFaOGlJNnhwS0x2dENOSFRr?=
 =?utf-8?B?MktTdWpMLzVsdDgrMFBCMFA1MWZnWkxRODdSanBleUllVW1LTy9COUFEeTVU?=
 =?utf-8?B?akNhTjlVRXFCMmlSZWNoU0FjWmtpYXp0d2pxb2d1OStsdVFKSzd5cmNQdzdE?=
 =?utf-8?B?UEJnWFNrWmZlaC95TmlOUlJ3OFpOUGdXZUh1TW0zSStzRjhNQVhqci9odTVR?=
 =?utf-8?B?RGFzNGdBTG5BQlZZT2lONjJRUEVmMjN1UnQ5YjJ0dTdRNEhFSjJPUXhKMGpn?=
 =?utf-8?B?cGFZOG9PRXoyVEdjMms2Yytlc1NBSzBDd0lVTHBObnYwUHhVTTRyclgwSXRV?=
 =?utf-8?B?VjM2VGpEc3BuekVTUUlQTlppZHNMdjZ3QXp6NFhta0lNa05WL3owbExRUTgx?=
 =?utf-8?B?V2NkN09CbzhNOEZkd1NreTRVc2RON3Azd0d1QUFESy9zbTRJV0FlMnNHYmoy?=
 =?utf-8?B?eWx6aHVjaktEelRyZ01UL3ZQMG5yWlFVYTIvamFJSHR3dTlsbnYxQW5TSGYz?=
 =?utf-8?B?ZkFROFMwUFczRGtwUFQwRDR5THN3dWlkV0xhTWtqbmRpcENSdml4dGVzSmV3?=
 =?utf-8?B?NUw0c2RYSWdBcGprMTQrYmxqTGhSZythTXZPUXhJLzg2T3ppV2VEQ3Mwa0Js?=
 =?utf-8?B?dDNXVGNwRVRkVTMwOWVPK2pUbFZRZW1uMUEzNHJjUThrV3E1VENvdVhVMnZY?=
 =?utf-8?B?Y3FhcWF5WHBTdGk5T1A3Y0VuWXhoZHIwazYxd0hpYmkrMk4rYmgxbWJVTTAv?=
 =?utf-8?B?cHg3YkR1RDRNdHYzbVlacGRzek1HVTBITldFbGtQbEw4VEhOcVhzUUhmVkUx?=
 =?utf-8?B?eGlSQkZsUUR5VngyZ2xyS2FlemI2Y0tmQXlqamJMR21tak9acXFwTnNuYlVn?=
 =?utf-8?B?L2tDTEQ4QmV2ZVdiOUVIdVdrbGpabjBRZTdwMmJyWjZncENUNjd2aHhTWHlE?=
 =?utf-8?B?NWc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 58f2c99b-fa92-45b4-d1e9-08ddfb81caa1
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2025 15:48:22.6755
 (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: +/IMhs1tyOaRTVD5thzX4zi9L8nWad0X8XBOXPOhS2qnJysjHzIxACpxumExxBDfwN/EhEyy8xGkLL5UH+pqRQ5iWY0teO40fcOX9YOzFig=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9048

Hi Ayan,

On 22.09.25 19:55, Ayan Kumar Halder wrote:
> 
> On 16/09/2025 11:55, Grygorii Strashko wrote:
>> Hi Ayan,
> Hi Grygorii,
>>
>> On 12.09.25 20:00, Ayan Kumar Halder wrote:
>>> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
>>> Test that Xen is able to generate SGIs.
>>>
>>> Signed-off-by: Ayan Kumar Halder 
>>> ---
>>> One of the aim of functional safety is to test hw/sw interface. This means that
>>> Xen is able to configure the hardware correctly for the desired functionalities.
>>>
>>> Normally this is tested from the VMs. For eg if a VM is able to receive irq, this
>>> implies that Xen has configured the GICv3 interface 'correctly'. However this is
>>> a high level (or integration) test which uses not only the GICv3 interface
>>> between Xen and VM, but the interrupt injection code for Xen to VMs.
>>>
>>> We want to have some kind of unit tests to check that Xen is able to receive
>>> various interrupts, set priorities, etc. Here, we have written unit tests for
>>> software generated interrupts (SGIs) as example.
>>>
>>> These tests are expected to be triggered as Xen boots (right after Xen has
>>> initialised the GICv3 interface ie gicv3_init(). The aim of this test is to
>>> check whether Xen can trigger SGIs after gicv3_init() is invoked. If so, we can
>>> claim that gicv3_init() was done properly to be able to trigger SGIs. Likewise
>>> we will have tests to check for priorities, SPIs, etc.
>>>
>>> A script will parse the logs and claim that Xen is able to trigger SGIs.
>>>
>>>   xen/arch/arm/Kconfig  |  8 ++++++++
>>>   xen/arch/arm/gic-v3.c |  7 +++++++
>>>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>>>   3 files changed, 36 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index 950e4452c1..739f99eaa9 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -73,6 +73,14 @@ config GICV3
>>>         Driver for the ARM Generic Interrupt Controller v3.
>>>         If unsure, use the default setting.
>>>   +config GICV3_SELFTEST
>>> +    bool "GICv3 driver self test"
>>> +    default n
>>> +    depends on GICV3
>>> +    ---help---
>>> +
>>> +      Self tests to validate GICV3 driver.
>>> +
>>>   config HAS_ITS
>>>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
>>>           depends on GICV3 && !NEW_VGIC && !ARM_32
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>> index 4e6c98bada..eb0c05231c 100644
>>> --- a/xen/arch/arm/gic-v3.c
>>> +++ b/xen/arch/arm/gic-v3.c
>>> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>>>         gicv3_hyp_init();
>>>   +#ifdef CONFIG_GICV3_SELFTEST
>>> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
>>> +    send_SGI_self(GIC_SGI_DUMP_STATE);
>>> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
>>> +    send_SGI_self(GIC_SGI_MAX);
>>> +#endif
>>> +
>>
>> I'd like to ask, if possible, to minimize mixing selftest and functional code.
>> Like add gic-v3-selftest.c.
> 
> I can try that. However, the self test needs to be invoked from functional code.
> 
> Also, your suggestion gave me an idea. I can do :-
> 
> +static bool __initdata opt_gicv3_selftest = false;
> +
> +#ifdef CONFIG_GICV3_SELFTEST
> +opt_gicv3_selftest = true;
> +#endif

I'd like to propose to consider other approach according to the following assumptions:
1) the goal is "Test that Xen is able to generate SGIs.". According to the goal and your code
- for this test, it doesn't matter which one (SGI) is tested. Any way you don't call real handlers for
  GIC_SGI_x.

2) there are 16 SGIs available, only 3 are statistically defined (enum gic_sgi) and
It's possible to reserve one more for testing purposes,
like GIC_SGI_SELFTEST

Then, gic SGI selftest might work without breaking Xen boot (probably for gicv2 also)

gic.c:
   do_static_sgi()
   {
    ...
    #ifdef CONFIG_GIC_SELFTEST
         case GIC_SGI_SELFTEST:
           gic_sgi_selftest();
         break;
    #endif

git-selftest.c

   gic_sgi_selftest()
   {
     // process test SGI, like count number of triggers
   }

   void [__init __constructor?] test_gic_sgi_selftest()
   {
	setup test 1
	send_SGI_self(GIC_SGI_SELFTEST)
	setup test 2
  	send_SGI_allbutself(GIC_SGI_SELFTEST)
	setup test 2
	send_SGI_mask(cpu_mask, GIC_SGI_SELFTEST)
   }




> 
>>
>>>   out:
>>>       spin_unlock(&gicv3.lock);
>>>   diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index d922ea67aa..5cb58cdb92 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>>>        */
>>>       smp_rmb();
>>>   +#ifdef CONFIG_GICV3_SELFTEST
>>
>> if (gic_selftest_run)
> And then instead of ifdef, I can enclose the below under "if (gicv3_selftest)" .
>>
>>> +    switch (sgi)
>>> +    {
>>> +    case GIC_SGI_EVENT_CHECK:
>>> +        printk("GIC_SGI_EVENT_CHECK received\n");
>>> +        break;
>>> +    case GIC_SGI_DUMP_STATE:
>>> +        printk("GIC_SGI_DUMP_STATE received\n");
>>> +        break;
>>> +    case GIC_SGI_CALL_FUNCTION:
>>> +        printk("GIC_SGI_CALL_FUNCTION received\n");
>>> +        break;
>>> +    case GIC_SGI_MAX:
>>> +        printk("GIC_SGI_MAX received\n");
>>
>>        gic_selftest_done = true;
>>
>>> +        break;
>>> +    default:
>>> +        panic("Unknown SGI triggered\n");
>>> +        break;
>>> +    }
>>
>> Potentially GIC selftest code can be guarded by some "gic_selftest_run/done" vars
>> if xen boot is expected to proceed further after testing.
> 
> Ah no, Xen will terminate after running the self test.
> 
> - Ayan
> 

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Wed Sep 24 15:54:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 15:54:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129569.1469472 (Exim 4.92)
	(envelope-from )
	id 1v1Rp0-0005m4-Mm; Wed, 24 Sep 2025 15:54:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129569.1469472; Wed, 24 Sep 2025 15:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Rp0-0005lx-Jv; Wed, 24 Sep 2025 15:54:22 +0000
Received: by outflank-mailman (input) for mailman id 1129569;
 Wed, 24 Sep 2025 15:54: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 1v1Roz-0005lk-6q
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 15:54:21 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bbbfed30-995e-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 17:54:20 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-62f4a8dfadcso8556785a12.1
 for ; Wed, 24 Sep 2025 08:54:20 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b2b4c9d2d7csm798325266b.62.2025.09.24.08.54.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 08:54: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: bbbfed30-995e-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758729260; x=1759334060; 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=k4seeNUS1Motd3RgPuX+CvlDpM4UWjKvUnpbCOP+NCI=;
        b=aMgezdGyeR+fauK8JexQpAn/VvKiKD34f0bUAX5r/LBcXhBlE4oHaOKggl8dxq1hiu
         r0/1Z+ZaMhif5du2SWfa+YyulONH0sbdIwA+1VIo88+pcYhdXhEdl4PT/2BPpZ4NTue5
         jI89/TtS1n0VJYgyh3sqD7+fLUGC++gbmdgP6GkAX9T314WWhnuDbTp+jo8rY+YLx6B4
         JprHPgHykLfO5/Rc2xLsfSOf3kB8sCoSw5gI4qTllUOn2EIugTGowPfviHRO58gMlGzf
         Hw+Q0izuSOiPMeqQa4v2twfSiw5ZMI30JlfjVa69Upua+zU0T97tUzfthbo2OXpPSlZG
         hqCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758729260; x=1759334060;
        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=k4seeNUS1Motd3RgPuX+CvlDpM4UWjKvUnpbCOP+NCI=;
        b=f/z589c8dKuBeGBxLuP46nKfQjVWTjnjeG/utbHZjttQFBzB2BKfWmWdkXv3s+44sS
         bVW91Rd0ldzdyzMP2sNF9gQBH4fNTyfRB4kzHTe6Z5rDWonxVXSB4Ci6+Op39TcEq63p
         1y9HQuKDGcc0EGpJ87zr8xJhZnOqV1SB9zuBMdwF6EEgQH6d4DLcF2HJiXMuudyUMzBB
         eTiZYYwK//QGENIu0qcL+0BmVr85TyZpuq/C5r/U6MAljIzurVN1P0XGrjT52LI7ypNM
         C7coAXCYD0bNwzx7Fmvz0mj6JlSJNDymflDbUGV5kgyXfPbTXkTAlyIHeVHYJHQtpKiU
         b0mQ==
X-Forwarded-Encrypted: i=1; AJvYcCWntSra3IJJCsJCFEdDIKmlk6qM0oeP+dRM4F7A8OfuDexWveoeMMJcEw+aY59yV68O0pcbKvhm62E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyP6hZUzkDqVYm57BQL3NCmZSXcFwZzFTiZJFwoKhFkgeCEgaf3
	U0ahe+tQiq+LIg9Jh3QIgZF/47ke8I+NLbth5lB8rdC74mAT/Hp+8VBNf7L0gQ==
X-Gm-Gg: ASbGncvNiFXABTBM1BYmB6fkKCjJa5mLFJfy9Y0p8KS/789AshvgmJwNtYZhofLvZbR
	8RSAVyGxenWFWvad9mRKaKgMOPf9R1lP5fhZec73Yom2FL8XruU3lxsCGOS2RbDwRzqUx9dywx0
	FyFiMU+RWbUmc/rl2kYnO2KqJpVpLXTAEgQdWVC9rhuffj8GIWRaGX7lz9r4NUXr8pfgluzWZx1
	siQSnOMyIG7zR24d3utg+tqv6Te1BrgWJYRUsPfVS9/OU6SMt469sGkwK8ujN44ezTgCHWFQFrD
	fAl0yh8rR1QXAJURsCHNNhugv9FRNUq8T+XEgm9LRix64vbSH8Wf0VKpQtH0fr2cEV0n3I5m83J
	fwuVSS01R5sNIYUbItVur6G2uxUkSFTUIMymEpnsqUpR9bhalsWTjbDbLbx8ITDCeETo8gECt
X-Google-Smtp-Source: AGHT+IHRZyg5+/LFoAYtF0Sm6laMt9QSwNRR7QNVAdzVbHAouwOtyaEm/0miyRw+Hz1M0SuY6rM7qQ==
X-Received: by 2002:a17:907:960a:b0:b07:957e:b64c with SMTP id a640c23a62f3a-b34bef9896cmr25392866b.52.1758729259654;
        Wed, 24 Sep 2025 08:54:19 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------6Oj0BrYdqCnnDZWF2tIj0zYR"
Message-ID: <7a58d59e-0ca3-431c-81f1-2029dc6c073d@gmail.com>
Date: Wed, 24 Sep 2025 17:54:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/xentop: Add documentation for physical CPU
 monitoring feature
To: Andrew Cooper ,
 Jahan Murudi , xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
References: <20250904172525.2795998-1-jahan.murudi.zg@renesas.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/24/25 5:44 PM, Andrew Cooper wrote:
> On 04/09/2025 10:25 am, Jahan Murudi wrote:
>> Add man page documentation for the new '-p/--pcpus' flag that displays
>> physical CPU utilization metrics. This provides hypervisor-level CPU
>> usage insights alongside existing domain statistics.
>>
>> Changes include:
>> - Add '-p' flag to SYNOPSIS section
>> - Document '--pcpus' option with description
>> - Maintain consistency with existing documentation style
>>
>> Signed-off-by: Jahan Murudi
> Acked-by: Andrew Cooper
>
> This needs a release ack now for Xen 4.21 (CC Oleksii), but it's a docs
> patch for a new feature so ought to be considered.

It is okay with me to have this docs patch in Xen 4.21:
   Release-Acked-by: Oleksii Kurochko

Thanks.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/24/25 5:44 PM, Andrew Cooper
      wrote:

    

    

      
On 04/09/2025 10:25 am, Jahan Murudi wrote:


      

        
Add man page documentation for the new '-p/--pcpus' flag that displays
physical CPU utilization metrics. This provides hypervisor-level CPU
usage insights alongside existing domain statistics.

Changes include:
- Add '-p' flag to SYNOPSIS section
- Document '--pcpus' option with description
- Maintain consistency with existing documentation style

Signed-off-by: Jahan Murudi <jahan.murudi.zg@renesas.com>


      

      
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

This needs a release ack now for Xen 4.21 (CC Oleksii), but it's a docs
patch for a new feature so ought to be considered.

    

    
It is okay with me to have this docs patch in Xen 4.21:
  Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii


  


--------------6Oj0BrYdqCnnDZWF2tIj0zYR--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 16:01:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 16:01:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129582.1469482 (Exim 4.92)
	(envelope-from )
	id 1v1RvO-0007zn-BC; Wed, 24 Sep 2025 16:00:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129582.1469482; Wed, 24 Sep 2025 16:00: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 1v1RvO-0007zg-8T; Wed, 24 Sep 2025 16:00:58 +0000
Received: by outflank-mailman (input) for mailman id 1129582;
 Wed, 24 Sep 2025 16:00: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 1v1RvN-0007za-6E
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 16:00:57 +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 a789ab13-995f-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 18:00:56 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GV1PR03MB10453.eurprd03.prod.outlook.com (2603:10a6:150:163::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Wed, 24 Sep
 2025 16:00: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%5]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 16: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: a789ab13-995f-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SJTIlWxu12hXT+RvTs8/k8wK1eA13fDC2ZbMfj3Lat+JhAL7uSwQD70uACvaAAqkMOOFZaMPdXQWnffrPgXHj3fTs3Ie6OvmfRTB9irZ9mak36yMtn8vZdCZn0TWdKD3k29F7uzu/TlvpUdp+h29XxT6/Bw6KivBuofu0lSnckadLnGZHsSzLI5usaZ56LntuWKrQvy0VZOIN5SqECNi0htd0vjlD8dQE+Rrx4R4o0+sWgZKnwc0yCdQWz4MX/hkPpIQOYseWlCusYEco8nJFGz4323IKn7uzbzOgOkiaVObBY3nBv+HThHq7bQUKN5z7HE3taa9UesMur+3bYcNkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mXHkDLEcQEJEL5AkDvPJQb/6BZVPIsiemLYpoWTK8+0=;
 b=C8ChghN7LEn8PjTwkKz/QvQB24qNlpUPzUZZxEn9UiGhdoaZsi7r/NyUbybNqG7t4s77eTx6c16RT+m/xHPxjtVCy/8y6uPl84yZ1ZjakK6JpPhtpwUP8JLoGu8AN+B+pAvuBiQNdMiQ6kkqk/c3t6YEa1sBpYsfPFFLoj8CcJmamLQgGTfa2yDhtgSFG60pw4mRjYls1CHl3EQbySKm28OTSdQfVrmo6xd38fMHsqi+9D4GjxZr6noJvvJS5otl4eZwP2pOofKKS/jxMNCLvTsFzqNu5M7xCC1PvqQYpKT0hI2orY78vF6KXGA/nsOhd/xgDABii0npBeA+YYIIYw==
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=mXHkDLEcQEJEL5AkDvPJQb/6BZVPIsiemLYpoWTK8+0=;
 b=op2TftCtNV2Lquwwzs0J5M7N4E6aC7Az85Zd6ceeP20xx8FrovrzLZtPSmJneB7ZWeA3c3ipkQHXdVxalsE/W/v28gzwJgdpPllBgs/G6jGZs89b6RuqACgH6ljO4Cc6xTXN7fnb8QDZVBDUyU8qy5cfYPoChEKyZakuwAHySrJMfO8GkJ/ZWj3unB4/WcAUCg/0YvnE62jjwh0ng0kIp4CBgJHMHwK2woKs9CmjNtjSdZ1KZA33FRzSpHp6wcufzaPIxMvT+oS1GfQYyBi7xij/AFyDset6c5yybGggXY/CeG1bMIAuqK9fS6NnPcQbzTGs9a2RouH67T/xqyA0Zw==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Julien Grall , Michal Orzel
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Oleksii Moisieiev
	
Subject: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control Dom0
 boot
Thread-Topic: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Index: AQHcLWxn561sYuCM3E640/FLnKWxSg==
Date: Wed, 24 Sep 2025 16:00:53 +0000
Message-ID:
 <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|GV1PR03MB10453:EE_
x-ms-office365-filtering-correlation-id: 6018e314-4e63-487e-fdc3-08ddfb838a08
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?d8htwbVIUud8iCzIQS+l1O15JYtQWm9LLGeS0aWNBaHdQor/wBKu1gIlHz?=
 =?iso-8859-1?Q?J1a+eI7b164cu69aOz7jliNYlb47lKO2kZXWzW9OLqapwbA/4785b8dgVQ?=
 =?iso-8859-1?Q?5b4VeLcZGq/p1f9QEFC1MZcRP/uUH06xPoY1R0AyFiMoP6EoKtmX0P0JHC?=
 =?iso-8859-1?Q?E5ctyCLSL5M5ZEetYZNS7npW2mMrhfdvd2hKbgm5wJZwoaahFVQOmAEDyt?=
 =?iso-8859-1?Q?/vOh7ddO0jqo+hHkrlMsusTXKCOHXxTG7iWFTGG4j5HEJrN9OdZzcPv1k0?=
 =?iso-8859-1?Q?FkcdKhfjTyRSfIyFnNZNA5QI1QhKkhz6NrQzn3qj+GxrmBdY+8LOlYFInx?=
 =?iso-8859-1?Q?C3w3M0qlXyOJCkIWv9pQGU1SdKxH9HWTgrKor+K0CEY6Nt2yAToaFdpJAz?=
 =?iso-8859-1?Q?8feWNi5Ijg5dBE2yk0Lh2ey5IJvzlpr0Wo/+mBjASWSxklbbsme8wgAwgB?=
 =?iso-8859-1?Q?U1cNemiP5RJVTxveGH7GTvfjjmkZfqrqtiHemNqxeRWmNeNw2kwzCP9QSs?=
 =?iso-8859-1?Q?hFNGvAz/ci9hdd4sN9UGHHx0rIkvUcr+GGdkqBUo6y8tKjxoRp6Gg/Y6j4?=
 =?iso-8859-1?Q?OfF1RyXmdUt3CEbLPc1bvViTd+f8tfcu/umHah8Qz2MSFfDJQwWpI0DeTx?=
 =?iso-8859-1?Q?m+uWtiqMlj0uzrtdxyJ/Isvw0mVp0q/SAMtXZinetclIsy8NTFhLHRcrLX?=
 =?iso-8859-1?Q?h9WdxxxipMTFYeNWXLRv/dePeLA9SYxgHiSVS6WyCm724adXVNYTCwYSE4?=
 =?iso-8859-1?Q?72FHDw73rHoE4XqXhpZci1QDOBgz3ab1FVQSp0yeIKzkd8usB/7TzR5qLB?=
 =?iso-8859-1?Q?h7OPF4HR7C4sZG/Qw4H+vbxOpFMe7owka+lTsOm0Wj3YS7TLFk2jhRxMF6?=
 =?iso-8859-1?Q?sVW1fz7pv39d1vf9Gf72qslF/s+s1oymGEr7szv3P185rGGYXZbDG76hF7?=
 =?iso-8859-1?Q?0wf2vIALJSAuQwCfx3vYkgRuPyE3tQAGjrSGFq83bXRUe/BqjYmqBUfST7?=
 =?iso-8859-1?Q?hkCjcgJ6vzx6Vw62+zGGw5LrmlrK+OgFUaxzYK6ImzUeJHNXoM/JHIqIok?=
 =?iso-8859-1?Q?EqeqZWXUC7YSQ+ebDX4DcwMWwn5hWeuZeLvEjfmKkJcvqhrQYDnJdRUwox?=
 =?iso-8859-1?Q?EuSwB2njx47ReFFlXRIyLb4vTr/iEnO7luVYORmPClUbgbyNASiSm9AGo2?=
 =?iso-8859-1?Q?jr4oVVe0TXluW3z5m8gRlqCXkDse9FLgD2AQz4VS11xWH/+9NZ+QB2PXfo?=
 =?iso-8859-1?Q?ErJQXJGcIzkun0YpJoqCptyLriJ/1TdmbQGiBk2okMnfvkKWPzHMct0B0v?=
 =?iso-8859-1?Q?E6iUJJOlGWCjLwKoVfpjyk3Hi8CPq0PHZk2MKCl/yZlTi88uKy/EnzdIzf?=
 =?iso-8859-1?Q?A99hwAVyRocwgKl3PBbKM+SCesYCphi4LheleJRDwS183WVjFI7vVXcFZp?=
 =?iso-8859-1?Q?j5uq52rZUxvi9wFoGEdCNVFu5AVFcSyhEsfxFUtxKBKkp3pzpQbh98dDAm?=
 =?iso-8859-1?Q?2R9+goSw6hZYU0MiDK4z3NK5NMCUbNDZrwuLRoHRoChsZ9RlvVgqcoSAbm?=
 =?iso-8859-1?Q?OYHBBtI=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)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?KHe+trvAXEhJXnWwvJYYyCuz5dk2o+QpSr0VUTvBbd+9l3w2TDSWqZBrvf?=
 =?iso-8859-1?Q?G61NNNP3PWiWEb/u+K6IVoBdf0nauhZKAhknFw9yc60eHM2hjyC+a3Xowm?=
 =?iso-8859-1?Q?TTqlvXcmbpBR7eHV4fWxFZIZRXUfQnXAg3yBuhf76m7Ezs87+Ofaq7edHb?=
 =?iso-8859-1?Q?G9WvMVrNzeiQUbkJW1aC44D5nQ5NZHpkRAAZBW6OQFYvyiFc9HS1yoTVtf?=
 =?iso-8859-1?Q?TUN2u8zBeKi8AfX1sLWAaa94SKAeDaep0ULZev2K3JDENLJLCTsyh2ge9/?=
 =?iso-8859-1?Q?fQdwyMkQeWEw7Z9cID6ABM6QiLCtOptq3FX7qWkxS3nUyQf9KOYjQOcLvA?=
 =?iso-8859-1?Q?DJgzQ5J8tXZmjn2NVmlCwfAqx0iTso5bKPi23Wjan+K7TrxxhyEWoxXxTR?=
 =?iso-8859-1?Q?qYFlzLx5aOyOgDKo9HLu2foZ9EdbHlZJTBAcmXRgIDMcyCtLUnldQs8saD?=
 =?iso-8859-1?Q?6l4PvZzybLJN1z5kFddFF3CcKQ7gmW8wK1hlXeXbFKx6et1de1XHIrpY0G?=
 =?iso-8859-1?Q?i5X/i6+vqG0XhVgf7b2jbgp2jFfqAqNapnWFQabfe6z7vm50N1F+sc39+t?=
 =?iso-8859-1?Q?fv3VWGXx7VhQgWE4KTVLFQ59l4lExj0id1h1Gp4U6iI74TIKZbVLtEpCXK?=
 =?iso-8859-1?Q?7FqeckE5yJZK7TtikyLoKOYbzWjW9ybKCVTkSb3XMxdTdcqx20bG7ESF8K?=
 =?iso-8859-1?Q?WP019Y/QW3aF892Hc/Ksq4TAvEWSMa7GFarLZz1//uPDISUB6H4uHWBXLF?=
 =?iso-8859-1?Q?uETW5Ldd0H5l7Xyq91+H/j7zW7HfHNTOKnHKpQ5uCrOGowYm18/KsxsCVn?=
 =?iso-8859-1?Q?3VNDFO5WYi9UYLXjB3S8VHTitf69BocbjBuUpsbGRbBJmV+odlnUAwZ8UF?=
 =?iso-8859-1?Q?mD1iJ6Q0B0cSkLKIc1gKE7ywTMHexTu51wvCeU2lmwYjFTWK20uYklfKjD?=
 =?iso-8859-1?Q?FcT1IibCw1o8mgxN3bZDQRqij0I1uRPrgb1v0erIZixt+TZMmjJOG9d+Ef?=
 =?iso-8859-1?Q?kElCFnPqEc1OJ8FhsTWJAwa2+wxcJc3ZEsj41XBtR47MQpBSuVujKBwB1T?=
 =?iso-8859-1?Q?SzJOKmeIoaYBoGQ3aGVMOzQmnwwlHSGMwFzeXfkpFpYYjszAnnToyS79CQ?=
 =?iso-8859-1?Q?u8PDNfFvx0kvIwYWr83N5WhUOoTg7N1GBN46MN/JwI3/v3yqZzsQcQ9Yss?=
 =?iso-8859-1?Q?p7cJUb9UJGXNd5WdXDdl+XOjuU+TY2mzAuvAhL6oHW+Mx9LhzHRtw7TP3/?=
 =?iso-8859-1?Q?OW6HioBesDCGR24lbuCpBuXDB48L4l62bBXbujdpbC90qu5j6WVW6bz6Af?=
 =?iso-8859-1?Q?lZVTB9ECYNXxNcNEWiHZHh2nEWM9Bv1BKImwgUbo5G5P0P7QjQuuSqRjL4?=
 =?iso-8859-1?Q?teEO/GrF9lGxRwHE+2Ezu3v6Uk7XwZop/792yqG++j5jizlaoDuMQM43y6?=
 =?iso-8859-1?Q?9r8vJ6XnjxqulkEUEb8lFN62UF0zwrFUJDBw3bygWOC8rHf/rnyyOL3HfL?=
 =?iso-8859-1?Q?mZyEcYgsBGfYQt9IjrTRM2aoPK9qqwdTwYB1isqHvbGr75gVgRXz4hrQbX?=
 =?iso-8859-1?Q?7fIL/9YEEY2hkr0xnejUancKDOOQyX9dT/Yd62SqLKIehViwc914SktEVy?=
 =?iso-8859-1?Q?RtidE/XBJ5/G3ukLfKWI/YmEfUTuY3f0Rcd7EZJ3KeMX4eQBZxYf5HXA?=
 =?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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6018e314-4e63-487e-fdc3-08ddfb838a08
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 16:00:53.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: jHuTIu6mGGZtVP9t4TmikZnQvEiFiWnpSIHWXjyOWi3z25K706InqlomuJ4+t5PfIAYgKBXzEsp/zb6K28q8O0MImsqB+wic5QbbkNtYpqg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10453

This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
allow for building Xen without support for booting a regular domain (Dom0).
This functionality is primarily intended for the ARM architecture.

A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
default for ARM and X86 architecture. This symbol signifies that an
architecture has the capability to support a Dom0.

The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
expert users, this option can be disabled (`CONFIG_EXPERT=3Dy` and no
`CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
creation code on ARM. This is useful for embedded or dom0less-only
scenarios to reduce binary size and complexity.

The ARM boot path has been updated to panic if it detects a non-dom0less
configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid
boot.

Signed-off-by: Oleksii Moisieiev 

---

Changes in v3:
- rephrase error message when dom0less mode wasn't detected while dom0
is disabled.
- rephrase help message for DOM0_BOOT config option
- update DOM0_BOOT dependencies for X86

Changes in v2:
- decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
suggested in ML) because in this case HAS_DOM0LESS should be renamed
either.
- fix order of HAS_DOM0 config parameter
- add HAS_DOM0 option to x86 architecture.

CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
regular (legacy) domain an optional feature that can be compiled out
from the Xen hypervisor build.

The primary motivation for this change is to enhance modularity and
produce a cleaner, more specialized hypervisor binary when a control
domain is not needed. In many embedded or dedicated systems, Xen is
used in a "dom0less" configuration where guests are pre-configured and
launched directly by the hypervisor. In these scenarios, the entire
subsystem for booting and managing Dom0 is unnecessary.

This approach aligns with software quality standards like MISRA C,
which advocate for the removal of unreachable or unnecessary code to
improve safety and maintainability. Specifically, this change helps adhere =
to:

MISRA C:2012, Rule 2.2: "There shall be no dead code"

In a build configured for a dom0less environment, the code responsible
for creating Dom0 would be considered "dead code" as it would never be
executed. By using the preprocessor to remove it before compilation,
we ensure that the final executable is free from this unreachable
code. This simplifies static analysis, reduces the attack surface,
and makes the codebase easier to verify, which is critical for
systems requiring high levels of safety and security.

---
 xen/arch/arm/Kconfig        |  1 +
 xen/arch/arm/domain_build.c |  8 ++++++++
 xen/arch/arm/setup.c        | 14 ++++++++++----
 xen/arch/x86/Kconfig        |  1 +
 xen/common/Kconfig          | 11 +++++++++++
 5 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cf6af68299..336b2ed242 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,6 +17,7 @@ config ARM
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE_DISCOVERY
+	select HAS_DOM0
 	select HAS_DOM0LESS
 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
 	select HAS_STACK_PROTECTOR
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fb8fbb1650..62602afc78 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,8 +42,10 @@
 #include 
 #include 
=20
+#ifdef CONFIG_DOM0_BOOT
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+#endif
=20
 /*
  * If true, the extended regions support is enabled for dom0 and
@@ -104,6 +106,7 @@ int __init parse_arch_dom0_param(const char *s, const c=
har *e)
  */
 #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
=20
+#ifdef CONFIG_DOM0_BOOT
 unsigned int __init dom0_max_vcpus(void)
 {
     if ( opt_dom0_max_vcpus =3D=3D 0 )
@@ -116,6 +119,7 @@ unsigned int __init dom0_max_vcpus(void)
=20
     return opt_dom0_max_vcpus;
 }
+#endif
=20
 /*
  * Insert the given pages into a memory bank, banks are ordered by address=
.
@@ -1962,6 +1966,7 @@ int __init construct_domain(struct domain *d, struct =
kernel_info *kinfo)
     return 0;
 }
=20
+#ifdef CONFIG_DOM0_BOOT
 static int __init construct_dom0(struct domain *d)
 {
     struct kernel_info kinfo =3D KERNEL_INFO_INIT;
@@ -1993,6 +1998,7 @@ static int __init construct_dom0(struct domain *d)
=20
     return construct_hwdom(&kinfo, NULL);
 }
+#endif
=20
 int __init construct_hwdom(struct kernel_info *kinfo,
                            const struct dt_device_node *node)
@@ -2046,6 +2052,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
     return construct_domain(d, kinfo);
 }
=20
+#ifdef CONFIG_DOM0_BOOT
 void __init create_dom0(void)
 {
     struct domain *dom0;
@@ -2103,6 +2110,7 @@ void __init create_dom0(void)
=20
     set_xs_domain(dom0);
 }
+#endif /* CONFIG_DOM0_BOOT */
=20
 /*
  * Local variables:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7ad870e382..fbb290df60 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -481,12 +481,18 @@ void asmlinkage __init noreturn start_xen(unsigned lo=
ng fdt_paddr)
     enable_errata_workarounds();
     enable_cpu_features();
=20
-    /* Create initial domain 0. */
-    if ( !is_dom0less_mode() )
+    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
+    {
+        /* Create initial domain 0. */
         create_dom0();
+    }
     else
-        printk(XENLOG_INFO "Xen dom0less mode detected\n");
-
+    {
+        if ( is_dom0less_mode())
+            printk(XENLOG_INFO "Xen dom0less mode detected\n");
+        else
+            panic("Neither dom0 nor dom0less mode was detected, aborting\n=
");
+    }
     if ( acpi_disabled )
     {
         create_domUs();
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3f0f3a0f3a..2aeb361c63 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_DOM0
 	select HAS_EHCI
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 76f9ce705f..10a8fc8718 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -26,6 +26,14 @@ config DOM0LESS_BOOT
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
=20
+config DOM0_BOOT
+	bool "Dom0 boot support" if EXPERT
+	default y
+	depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_=
HELPERS) || (X86 && HAS_DOM0)
+	help
+	  Dom0 boot support enables Xen to boot to the all-powerful domain (Dom0)=
.
+	  If this isn't enabled Xen is expected to boot in dom0less mode only.
+
 config DOMAIN_BUILD_HELPERS
 	bool
=20
@@ -125,6 +133,9 @@ config HAS_DEVICE_TREE_DISCOVERY
 	bool
 	select DEVICE_TREE_PARSE
=20
+config HAS_DOM0
+	bool
+
 config HAS_DOM0LESS
 	bool
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 16:06:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 16:06:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129595.1469493 (Exim 4.92)
	(envelope-from )
	id 1v1S16-0000Eb-0J; Wed, 24 Sep 2025 16:06:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129595.1469493; Wed, 24 Sep 2025 16:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1S15-0000EP-TW; Wed, 24 Sep 2025 16:06:51 +0000
Received: by outflank-mailman (input) for mailman id 1129595;
 Wed, 24 Sep 2025 16:06:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1S14-0000EJ-Fx
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 16:06:50 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7928f76e-9960-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 18:06:48 +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 1F9374EEBC4C;
 Wed, 24 Sep 2025 18:06: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: 7928f76e-9960-11f0-9809-7dc792cee155
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=1758730006;
	b=sXCTB07OwASPmXY7cqREGznQkTNgEqNHt2MSl3D5v3wk8hBxyq05RoMhqkOvL/dACDn4
	 bGzVlZ1AhnJaqN1qgaoJWZLK/vFUsbhxklNlebRdriUJLXTRzQxRPPPtelNgWMbH0PJsq
	 z5Qu21rS/DxwFISUTOJk0dReMOZ1ov++ju603xu+NVn8MDa9gkNAd1U1FFFCMGornazqr
	 kRpVi5bucQvZGOPsbKhMp3FeUUG0QYGoOd49xPC2QSBl6rxmgxammk12a4PVmUsqMdKhf
	 2zlONIJ6kIlEoMuWH7hHlCVNax6EYu4vDyk8TvnCgL+z7oUHQLSVv3Q1PqlujJ4JhbdI5
	 K1ldPIWCuapXpL/6f5AhyyayC6PN4+JcVy38lk/JF50+O31mZuV0ewoMIs0ru3J9nyggL
	 3ufn0CpJlOQGxz+Nq/gHQ0kFuFvylmq4KrkPcstHm6DYHilPbObO6reRrC9remsQBMXYI
	 NopRAW6fmSbOeIgqDPN/yJv1w8Qh0+CL6++ssSWjmUH4eYOebspgNB5U/D56x2dYWqEBV
	 Zklbt/lDYD63aLOY5Gmfxt2nyO3I0Ww0yUQjDA9QL5feOtW91oDIM2S8l1QzOO+25tK6M
	 vd6WwLI/W4WEDgIsziN6oLyBlfYD9l9NFpLnp/mxSkRpxadgUDo2lukiAZc86r0=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1758730006;
	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=MSpaDpUyDpI8hGrZh8BcNoDhOMGAqD+oi+QjymgT2XE=;
	b=z4KSXZNN+Fclt/MOC74rNtp5TzTOzOkH490jI1g2CmABSB8K+u6eqUcTRveadDqczrkp
	 3WyMRyrD3fC2OMGYAdkS9rbBSbUmAzZmXOF2+4JIC/KeJlGOe6FehGtJiQ3TlaB8g6bJh
	 hs1VfTlduY4eUr8PibH9rphQWwFmqbWBYpFL+NvicVTHXHOI1Zd48hKSL6sBlDeLCwMsf
	 QPdp5N/cNMJcQWTqxZ2Kq/yuaBMxWR8Dod1k0aLyFC+8gnvuT0ggFeCzoQJ8m/GaCPzqd
	 Qs7cLACyqqclvEO7Qs199HT8pq5T+RLOvowQmZbR/zZFEMiNJi+Pjn8juUkhafkI5b2VH
	 Sl3JO1+G86ofNW6ZnFhxcHvGtg/MVYhQ4YUtM9AuH9RXQfSTkvZYs8oZGgo7LGNBBYwef
	 cWHtjKKZnEB1BVfsPPuGQEHPR4mGczMxi6HOSlvWf6wNr7tEOgfXv0ABRan/pAIP4Gijw
	 uOn2VumYFqj9mI5KFTdlvlWs28gbYwEaqLvs6wvp84C0Hz3FqtdLxS3HMw1FeDZ5cPML8
	 VFQCYO4ZDX0G7hkAgAFfHo4XBcP9bgIXxp/iWjYA51MwQyRM3WCaKRwyM+UYx6S44eHB7
	 UsinXOKA+zIJFIxQ4p830wOUkHW9dRyf7GtgRwEZt0gMv3HNPDeJFoMdRQWuEH0=
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=1758730006; bh=ERgvP1ajrjoOeceRyDJZFJrmHh1tAcZUi5xsZmrTazs=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=s53p7whezYAYl/ELjWaCW3GvKxcJjiPPtsxZEiuUTqlqc+1Yjc38V+1aGsGzSnJQ3
	 WnkZ5+6ZLfZMJZj7nfGqSoQKfZssM1Ni5hYKOOO7Uud6Di/aoTmjSgg6mhN6HqImCn
	 +KnEMheeVwW3XXS/YADoVqOE6vsrZ3EDLHZ/eHwMiUcLKxIVqdV3Hf+xJ/kmlx1/Ik
	 J1n8vnUFc+p/eMA0M2Ne0DnL1t4JFFg/jMU9KhHEtA12bKyVZDwEd+kYfxR/HJYsyD
	 Aj1/NTcWbRlT2ukDO7nThwbqZe3gkweecDUCuQ5SrnKGLOG5+qozo6tcTSTtO61PrM
	 nSkDdAa67v3Jw==
MIME-Version: 1.0
Date: Wed, 24 Sep 2025 18:06:46 +0200
From: Nicola Vetrini 
To: Oleksii Moisieiev 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Julien Grall , Michal Orzel
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk 
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
In-Reply-To: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
Message-ID: <8fd7c0f5d203aa0f13cd8efe5129b6f3@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-09-24 18:00, Oleksii Moisieiev wrote:
> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
> allow for building Xen without support for booting a regular domain 
> (Dom0).
> This functionality is primarily intended for the ARM architecture.
> 
> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
> default for ARM and X86 architecture. This symbol signifies that an
> architecture has the capability to support a Dom0.
> 
> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
> expert users, this option can be disabled (`CONFIG_EXPERT=y` and no
> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
> creation code on ARM. This is useful for embedded or dom0less-only
> scenarios to reduce binary size and complexity.
> 
> The ARM boot path has been updated to panic if it detects a 
> non-dom0less
> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an 
> invalid
> boot.
> 
> Signed-off-by: Oleksii Moisieiev 
> 
> ---
> 
> Changes in v3:
> - rephrase error message when dom0less mode wasn't detected while dom0
> is disabled.
> - rephrase help message for DOM0_BOOT config option
> - update DOM0_BOOT dependencies for X86
> 
> Changes in v2:
> - decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
> suggested in ML) because in this case HAS_DOM0LESS should be renamed
> either.
> - fix order of HAS_DOM0 config parameter
> - add HAS_DOM0 option to x86 architecture.
> 
> CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
> regular (legacy) domain an optional feature that can be compiled out
> from the Xen hypervisor build.
> 
> The primary motivation for this change is to enhance modularity and
> produce a cleaner, more specialized hypervisor binary when a control
> domain is not needed. In many embedded or dedicated systems, Xen is
> used in a "dom0less" configuration where guests are pre-configured and
> launched directly by the hypervisor. In these scenarios, the entire
> subsystem for booting and managing Dom0 is unnecessary.
> 
> This approach aligns with software quality standards like MISRA C,
> which advocate for the removal of unreachable or unnecessary code to
> improve safety and maintainability. Specifically, this change helps 
> adhere to:
> 
> MISRA C:2012, Rule 2.2: "There shall be no dead code"
> 
> In a build configured for a dom0less environment, the code responsible
> for creating Dom0 would be considered "dead code" as it would never be
> executed. By using the preprocessor to remove it before compilation,
> we ensure that the final executable is free from this unreachable
> code. This simplifies static analysis, reduces the attack surface,
> and makes the codebase easier to verify, which is critical for
> systems requiring high levels of safety and security.
> 

Misra's definition of "dead code" is code that is executed, but can be 
removed without changing the behavior of the program, while unreachable 
code is code that is not executed, so I would cite MISRA C Rule 2.1 ("A 
project shall not contain unreachable code"), rather that R2.2.

> ---
>  xen/arch/arm/Kconfig        |  1 +
>  xen/arch/arm/domain_build.c |  8 ++++++++
>  xen/arch/arm/setup.c        | 14 ++++++++++----
>  xen/arch/x86/Kconfig        |  1 +
>  xen/common/Kconfig          | 11 +++++++++++
>  5 files changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index cf6af68299..336b2ed242 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -17,6 +17,7 @@ config ARM
>  	select GENERIC_UART_INIT
>  	select HAS_ALTERNATIVE if HAS_VMAP
>  	select HAS_DEVICE_TREE_DISCOVERY
> +	select HAS_DOM0
>  	select HAS_DOM0LESS
>  	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
>  	select HAS_STACK_PROTECTOR
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index fb8fbb1650..62602afc78 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,8 +42,10 @@
>  #include 
>  #include 
> 
> +#ifdef CONFIG_DOM0_BOOT
>  static unsigned int __initdata opt_dom0_max_vcpus;
>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> +#endif
> 
>  /*
>   * If true, the extended regions support is enabled for dom0 and
> @@ -104,6 +106,7 @@ int __init parse_arch_dom0_param(const char *s, 
> const char *e)
>   */
>  #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
> 
> +#ifdef CONFIG_DOM0_BOOT
>  unsigned int __init dom0_max_vcpus(void)
>  {
>      if ( opt_dom0_max_vcpus == 0 )
> @@ -116,6 +119,7 @@ unsigned int __init dom0_max_vcpus(void)
> 
>      return opt_dom0_max_vcpus;
>  }
> +#endif
> 
>  /*
>   * Insert the given pages into a memory bank, banks are ordered by 
> address.
> @@ -1962,6 +1966,7 @@ int __init construct_domain(struct domain *d, 
> struct kernel_info *kinfo)
>      return 0;
>  }
> 
> +#ifdef CONFIG_DOM0_BOOT
>  static int __init construct_dom0(struct domain *d)
>  {
>      struct kernel_info kinfo = KERNEL_INFO_INIT;
> @@ -1993,6 +1998,7 @@ static int __init construct_dom0(struct domain 
> *d)
> 
>      return construct_hwdom(&kinfo, NULL);
>  }
> +#endif
> 
>  int __init construct_hwdom(struct kernel_info *kinfo,
>                             const struct dt_device_node *node)
> @@ -2046,6 +2052,7 @@ int __init construct_hwdom(struct kernel_info 
> *kinfo,
>      return construct_domain(d, kinfo);
>  }
> 
> +#ifdef CONFIG_DOM0_BOOT
>  void __init create_dom0(void)
>  {
>      struct domain *dom0;
> @@ -2103,6 +2110,7 @@ void __init create_dom0(void)
> 
>      set_xs_domain(dom0);
>  }
> +#endif /* CONFIG_DOM0_BOOT */
> 
>  /*
>   * Local variables:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7ad870e382..fbb290df60 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -481,12 +481,18 @@ void asmlinkage __init noreturn 
> start_xen(unsigned long fdt_paddr)
>      enable_errata_workarounds();
>      enable_cpu_features();
> 
> -    /* Create initial domain 0. */
> -    if ( !is_dom0less_mode() )
> +    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
> +    {
> +        /* Create initial domain 0. */
>          create_dom0();
> +    }
>      else
> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
> -
> +    {
> +        if ( is_dom0less_mode())
> +            printk(XENLOG_INFO "Xen dom0less mode detected\n");
> +        else
> +            panic("Neither dom0 nor dom0less mode was detected, 
> aborting\n");
> +    }
>      if ( acpi_disabled )
>      {
>          create_domUs();
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 3f0f3a0f3a..2aeb361c63 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_DOM0
>  	select HAS_EHCI
>  	select HAS_EX_TABLE
>  	select HAS_FAST_MULTIPLY
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 76f9ce705f..10a8fc8718 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -26,6 +26,14 @@ config DOM0LESS_BOOT
>  	  Xen boot without the need of a control domain (Dom0), which could 
> be
>  	  present anyway.
> 
> +config DOM0_BOOT
> +	bool "Dom0 boot support" if EXPERT
> +	default y
> +	depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY && 
> DOMAIN_BUILD_HELPERS) || (X86 && HAS_DOM0)
> +	help
> +	  Dom0 boot support enables Xen to boot to the all-powerful domain 
> (Dom0).
> +	  If this isn't enabled Xen is expected to boot in dom0less mode 
> only.
> +
>  config DOMAIN_BUILD_HELPERS
>  	bool
> 
> @@ -125,6 +133,9 @@ config HAS_DEVICE_TREE_DISCOVERY
>  	bool
>  	select DEVICE_TREE_PARSE
> 
> +config HAS_DOM0
> +	bool
> +
>  config HAS_DOM0LESS
>  	bool

-- 
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 Sep 24 16:37:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 16:37:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129622.1469502 (Exim 4.92)
	(envelope-from )
	id 1v1SUf-0004TU-D4; Wed, 24 Sep 2025 16:37:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129622.1469502; Wed, 24 Sep 2025 16:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1SUf-0004TN-AV; Wed, 24 Sep 2025 16:37:25 +0000
Received: by outflank-mailman (input) for mailman id 1129622;
 Wed, 24 Sep 2025 16:37:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1SUe-0004TH-3z
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 16:37:24 +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 be528bde-9964-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 18:37:23 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS2PR03MB9050.eurprd03.prod.outlook.com (2603:10a6:20b:5f6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Wed, 24 Sep
 2025 16:37:18 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 16:37: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: be528bde-9964-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Re80LtKSDMfsKdMx5Zwvok7P6bHJHkeqaae0B+9HsGMNsTQlcaFEeHFmKjdy6iBBEoIVNiuTnEroP73G8UClQfKV6T+KtvUNL8AvypBbIj+7dK8nk1dHTi216tcUKj7w41TWZ/KdwVikW0OMLdTvCGKWd5C1QtJgS9ZGnof2i22uZLiu8QENtDgvlrk5Q+1abRNmgx7FQKrM08qauVrYCxKutdT2kH6ckJozeP8sA+qeRVKx2+A3pwcOpeWf7TXiZYm2SaV3iNiGH58Hne6vq1X/sfY8UKwVJdyrKJBJNYYaQgHbq4UuUW9s4dGjLRvEgr3juNIcM3N9KP3ahOl2HA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SYpGp+mJ8EiOqiOhwilYMfzfaT/Y+RnMZ7SX2Mphe7I=;
 b=BkCAIaY5plXN8ycINUgasQEFxUS/dzXfwzpRD6YCIli+3efMPIsw1ldORZeMtaBk3xwstiXv59DniGYREeAMR0B7DZ8PDX1KfWiwocsAteYdkd+5fqIkKY/xas7MzXn02CadsRPTJB6ZiWjjxGthAlZN/jiPd5X9liQ/jEVOFDVufzt4DYty50vg5BbrUAGgxIta3YJryjbqTpm063yQMORDyDS9rjHwPRkr0aF0VHzvzHQhXhprXkM/3ubB/uV3gum8++RMhH//HH6HW0btu4pCazgki2lyNnBSYlt009sTT0PgEfAEAnuC+dhGjlx4HhqshR0Glhm+O/UF3I+RxQ==
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=SYpGp+mJ8EiOqiOhwilYMfzfaT/Y+RnMZ7SX2Mphe7I=;
 b=jjgZNQD5RQBHvtHwPznsfwKlCYBGpWO6qBAz0Fol9Tmlxyl7vCKS2lec7zyLZbN74D4BKVj7YqkcWOS1l+teOLSfT8LUxP4SNgbakZ+IAoni2wSSEWF6gAlp9+aZDHlr0UOVbMndlLs6W5Mygix9aKUR9dZIlasW3t1mp9QdgGBHx8jEJLW0eQRonIRyBnNaYpQmJ5qGdAewA+tNtKE3etE46mD+6KucAOWQRg2qCjdHUuhU4bsHXecZkeqQ46Z5vv524/6g61H3D2KrMba0zhKV3Q1N2zwh/Uo4mBSSv04L4kxNBDW/LGuKizxkkg5pZLtgrqb33SrY0kVodOkkww==
From: Oleksii Moisieiev 
To: Nicola Vetrini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Stefano Stabellini ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Topic: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Index: AQHcLWxn561sYuCM3E640/FLnKWxSrSif5oAgAAIh4A=
Date: Wed, 24 Sep 2025 16:37:18 +0000
Message-ID: 
References:
 <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
 <8fd7c0f5d203aa0f13cd8efe5129b6f3@bugseng.com>
In-Reply-To: <8fd7c0f5d203aa0f13cd8efe5129b6f3@bugseng.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_|AS2PR03MB9050:EE_
x-ms-office365-filtering-correlation-id: 615ceaba-a5d6-41e1-a257-08ddfb88a0a6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|7416014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?OE9xeXpvZk5GNlZMTWpYVFIvbmN5bnhrY3JpM3Y0Yno0Mk54dXRWa2g1cG1O?=
 =?utf-8?B?RW9aTHJNQVVqUkprcy82ZXRpWFhzRWtWcFNFeER6bmE3Rzl5TVFPTE9Gek9L?=
 =?utf-8?B?b1lrM2tRaEY4Q2liak5FNmJjNFFzTGhsNGNydFlNQVFmY1h6V2JFZkxRWjZp?=
 =?utf-8?B?K0lDVVA3VmxJQjJqVnhkZkY5d29jTnZHQVo1T1oyN3N5SjAwZjFKL3ZSSjJO?=
 =?utf-8?B?SkpncWN1V0szRXJWR3M1dXgzdHVrQ0lTSkNZemFDYys0cjhPbDVXU3UvbDkx?=
 =?utf-8?B?VHpOSGYzdDR3bXBQbW5qWXRjSzRZakVJdzhVQXBPelAvdkNidFNwZTZwd1pN?=
 =?utf-8?B?V24wQkJFT2VLU3JMNjNlVDF2ZUIwRGV5QUNsWUc3dy94Rk5MQStieFJyc1Y0?=
 =?utf-8?B?Q2RiWURsQngxNktPdU9rQUVVcFcxMTNpaUFGckZGN3h6ZlNEc2ZjSktmM2h3?=
 =?utf-8?B?MTBaMlk1eXNFTm03UTBZUjNoclpkSWkyWVAxRG1UWGZ0OTQwVldrMllsczdm?=
 =?utf-8?B?cTNzSkFyVS8vQmMyUmZIb0h4MEkva29RZHdOczE0dVA2OWI1c3pUdmNPc2o0?=
 =?utf-8?B?Z3ZnbEJLZjJxRVZidFcrU0o0T3Zxb1lxcTlLdUtYUUsrS1J1RkJJd3BkdDA0?=
 =?utf-8?B?YjJaOUplMms2aHhkVlNOa3ZBUlFFZ0V0b1hlRmw3VlJTODlrTWNyRGU3c04x?=
 =?utf-8?B?QzRVZlR3Ti8yU0RxVWlFczNyRXBZYkJtQjFCZFpwaDBZN0pQY1JsMGk1MSsr?=
 =?utf-8?B?dldiWFRKc0djdmFYc0t4ZFJlbmlGa1NWZVo1c1czRjA5eGlMOFNJWmEvVytj?=
 =?utf-8?B?czlYd0VYbnFmSVFLakZSNGYxQlhta1BSWlkrdHlha1hnV2gzRGxEUEEwSmZQ?=
 =?utf-8?B?RWhYUFR5aGpmdENwcGZPQTdiSmNhUHdiT1FMTWZYNE5wVFd2MEhDRlhGSUxD?=
 =?utf-8?B?QkRJbkJKeDBZcUR3ZnJXQXAxMzYyTFBteGt1aXlBUTVlQzJjWVljUk1FTVRE?=
 =?utf-8?B?VWI3Z1ZRNUNwbXFOdGZGYWZraHVodmM2aWZmWmdLMktzOWRXZWJ5bVhYVnZV?=
 =?utf-8?B?VXNVWDkveXFDUEdkMS9SU0tPdWo0bWU1NE0vbXR1YzlHMndOb1d4V0FQZTJm?=
 =?utf-8?B?dG1mdFhmMmVkOVFlc2Q1QWNxNSswN1VUMGZEU3JBUmNrMUNjT04wd2F3OXZH?=
 =?utf-8?B?ZmpVeENSYzB0RW1SdzhodnFEWDQ1L2cxNWFBQkpFbDhBUFViMnRiUEFDbW01?=
 =?utf-8?B?KzJuRFgvbnpnVXduTkRRSTRrZGJwS0w2S2tVQmVUNlc0ckU4TWhSTUhSMzRH?=
 =?utf-8?B?M2tGazcwSThwODh0T3Z0RjJCWDljQ0k0Y3VaZElhL3QzWk1Jc2ZuQUd1V3V2?=
 =?utf-8?B?clJKRzlabmVkOGFnSzV2YjRDdDlWQmpBT1ZzNHRvYlMwcWtyUUxYR2F4UFE5?=
 =?utf-8?B?aUkrYXhuTE81bWpXQmMxdmdabUxTQ3oyWjVNSWVFM1JrdnRaU202UG1weTB5?=
 =?utf-8?B?bWNKdmFuaFhNREcrK0x1Zkt3ZnJpWFdHUlpOdVdnMmNGb0RVa3dxUWdKNElN?=
 =?utf-8?B?T1ZPNEVpMlpBWVNvMnJGdU1BQjBCY1ArRDdHRFlnNzNXT1g1RjJsaTRPb2pO?=
 =?utf-8?B?cythTGdoSWpJM09ETm9EL3RXd0FZY3RGbUpYbzdCSGs5Ylk0K2hDcFRhM25Q?=
 =?utf-8?B?Q2U4M1FhMzdwNnZZYjkrRjd1d2sxSzF6N0pkejZkTitFYlZBYVZtUHppYWky?=
 =?utf-8?B?ZlRkY0x3bzZsQ3JjNVV0NzB0Mm5nOGZmamh2NVpxS0s2a2VDSjFuQkw4c3Jq?=
 =?utf-8?B?NkgrVkNyQXRpUmx4eHIzRzIra0ZhMnVCL2pYeGRuYjNsRmlCV25ZOU4xY3du?=
 =?utf-8?B?MFFtSkFpUERyVkRGQjFiOTVtTFdrV094SHNSTTdpRHUyZ3NYaXl4NEY1dmlZ?=
 =?utf-8?B?Lzl3cFpWWDIweVdJTUlzbWVKMGZ1WUtabm9VRlcxa0pKOXQxWFhXZTVtYno2?=
 =?utf-8?Q?ZHWudgd9FMNU2SkcaFY9K1I78gaT0Y=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)(376014)(7416014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?K1hkOVlWODloRHZiWmJoWEZzUk1zSnNXZTBwa0tzbDJ3M25KWUc4NWxiaGVp?=
 =?utf-8?B?OTUxZU9CcmpJd01XeUFMUzNMRkpMcUFudTBjYzlidmp2OXQrTzRmKzluTndR?=
 =?utf-8?B?dUsyWTFyc29va0wrOWxZbG5sN1JaZVpmbHVySkVNWlJsakFXQkMxN2EwbzZR?=
 =?utf-8?B?bGR2RVUxUEFWb05DQmFlcHBHcjJCOHl1bWtNaVBrcVozT3A1dUV4MDltU253?=
 =?utf-8?B?L2EyM3YrdTc5dVQ1N3ZnOCtwYXJya1RZUUFIOVFHQTRPOFJMaThKN1E5b3R2?=
 =?utf-8?B?YUJKVTBNZklhTVZUOFRrdVRRa0ZkQVVSaWR6NEg0N2E5YWlWaE81ZHIvVDVo?=
 =?utf-8?B?VHFLL1BacCt4WXRGL2JZUVBrZWxIYUJjcGIwcjN5eWthU0dZRHBEZ2J5WlNW?=
 =?utf-8?B?K1FJR1ppNmFBOWpITDVwdnFHSUhVWHhDd29uMjl2dWNhU2ozcnVPNkVySXpN?=
 =?utf-8?B?QXZ2UnJLM2dvdHpPSWZrWi9wNUw5cW0xTjNGblBDQndhQlhycEJSMEZJaEFj?=
 =?utf-8?B?RVpEamxOQ2o5ZEdTS0pOUTg4ODU4MTVvdU50QVI5RmNkeDdmcFdQbnZvV2Jj?=
 =?utf-8?B?cTlETjVVNGdaeEE0UFFoWHFLWEtCb0RKb2FOYm9TdFVRNDB2a29YZm5KdnVl?=
 =?utf-8?B?MTBYMHYxZUZFQ01aSm4wSllpTmNDZ25RdnBYK3pzNWQwTkRKRUl6cmIrN2NQ?=
 =?utf-8?B?bSt0TktrMjRxZlk2S3VrUjNxUlVBNWN0SXlHdVNpVUo1bjV6QlpsRFRCMFpq?=
 =?utf-8?B?T1FxSnVxcFI2NTJmWXFML0ltTjRCRUFvUTVodVRpeFBab21VYXlsTFl6WDNu?=
 =?utf-8?B?cXRNc3lWRFI2aDhqZnFrZk9UdWpSd3lidVZEVVcvQXYxeC9zNzRBSlBEUm44?=
 =?utf-8?B?YWtESklNOXk0QUY3M2gxZXorSm9vditWamtlY1VJMU1JYnl1elZxZ3pvWktm?=
 =?utf-8?B?aXIvZlVWRWcvbk9XRVZZZEtPbHlFTXlZTGx3enpyZ0trMlY4OU9ZeWY1amcv?=
 =?utf-8?B?bGRXZU80aE9yUDFoNUZwVFVtcnhDeWxOSUM0bFpZWm1RMG9sWGQvSTBtcUhD?=
 =?utf-8?B?WjBGZm5PZnVjTm8ySHZNRUVQZXpPVEZBR2hOMzlwR3BwUUVBWG5UNEJCQ2Rw?=
 =?utf-8?B?K1RGOFBzNmdWL212aUR1T1Z0aDd6US8vMmVrejhKc0FMT1A0cFF3b2djM3NN?=
 =?utf-8?B?MkcyN0pZbkxQMFZ4YUNMaTZDM3JwNjhSSzZRQVNobG5wOFhES3gwcktTUW53?=
 =?utf-8?B?MXc5UWlLN2lZaVR5bjJtTWFUZ3JrbGF1UUcwZTBDZzg5ODRmWFVUU2dEd3Qx?=
 =?utf-8?B?T2dtTjhzOXJIR285QXpEYTBrTFRxbFdJcW5YSzNHN0kvZ25hQW1XRVdoTGZR?=
 =?utf-8?B?eTRVU2llMUtWNFlnV0xPZ2NQYysrdTFNdEN6ZGU2aVJEUDFoWWpWeHZZNTgz?=
 =?utf-8?B?NDBXazFXZXBBRVhXMGU2V3FiWlk0WE4vV2J5aUxHQWJoWTg0MHZ2VmgyMGRo?=
 =?utf-8?B?eWhMK2crY2pydVJkK2o3M3N3OVVNV3FFS1QrakdydTVwb05hRnNGckFzZnNp?=
 =?utf-8?B?aEJHdUZPbjYzbFNKbXkyQ1lIRnVvOEN1NjhrOW8wdWg5cW5OWFVEWmtwc2FZ?=
 =?utf-8?B?STVUVzRaMm5QQ0t6T2JwMDRobUdVSnJ5Q1U0dCtjbC9aUUh2WEJhdXZUOXAy?=
 =?utf-8?B?cXprTmI1M3g4VzFpZGgvSjczSkVJU0NwdUpKOXJFTy82SGFRcmF4dHZ4c2RI?=
 =?utf-8?B?bVZUSDkwSmY5Z0Zobzg4ZG9Ia3M0cVc3R2NremtvSzQ0RGVOSGpYWDc3dFEw?=
 =?utf-8?B?OEFkcVhGdTVQRG55cElqL2JaL1BRSk84ei93bkNocUgwUEpVaXhjb1hzWm51?=
 =?utf-8?B?WVQxZzYyNlVmL09JdEpQMmtJLzl2ZnllTUIzZWF5NVpwUkRubmdXS2VyZ0Vx?=
 =?utf-8?B?Q1lQWEdpclp1S3ZCY3BwWEZBRFg0cm5mb003SzliQ3EydUh5MmFXWVJ0Z1BP?=
 =?utf-8?B?eWFaN1kyZVBLbUhLY0ZyQklENHFHU2lCdmlpb21UVlpnU3JVTlBaMnJLU2tC?=
 =?utf-8?B?WDZlVm5PVmttNUI3eWd3NGxOTXVvVldsVzJhZ2ZONFFNLzJNVVlldzVLMDRi?=
 =?utf-8?B?d01zazcrQ1hjNlloNEJIT3E1RnVERDNlYS9DNkJuSTlkNkRkZzdCTzNVUzdR?=
 =?utf-8?B?Vmc9PQ==?=
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: 615ceaba-a5d6-41e1-a257-08ddfb88a0a6
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 16:37:18.5384
 (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: 2jB3Qt0SxIoscV79FFk9mAaO8Y7+gnmRG8XwAp/I2kmFsa6lO++5mh60cnyQKgRMCRxcby2jDi9qvkPZW07Ml5ZFV93M2KWHx3KtNBwIj5w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9050

DQoNCk9uIDI0LzA5LzIwMjUgMTk6MDYsIE5pY29sYSBWZXRyaW5pIHdyb3RlOg0KPiBPbiAyMDI1
LTA5LTI0IDE4OjAwLCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IFRoaXMgY29tbWl0IGlu
dHJvZHVjZXMgYSBuZXcgS2NvbmZpZyBvcHRpb24sIGBDT05GSUdfRE9NMF9CT09UYCwgdG8NCj4+
IGFsbG93IGZvciBidWlsZGluZyBYZW4gd2l0aG91dCBzdXBwb3J0IGZvciBib290aW5nIGEgcmVn
dWxhciBkb21haW4gDQo+PiAoRG9tMCkuDQo+PiBUaGlzIGZ1bmN0aW9uYWxpdHkgaXMgcHJpbWFy
aWx5IGludGVuZGVkIGZvciB0aGUgQVJNIGFyY2hpdGVjdHVyZS4NCj4+DQo+PiBBIG5ldyBLY29u
ZmlnIHN5bWJvbCwgYEhBU19ET00wYCwgaGFzIGJlZW4gYWRkZWQgYW5kIGlzIHNlbGVjdGVkIGJ5
DQo+PiBkZWZhdWx0IGZvciBBUk0gYW5kIFg4NiBhcmNoaXRlY3R1cmUuIFRoaXMgc3ltYm9sIHNp
Z25pZmllcyB0aGF0IGFuDQo+PiBhcmNoaXRlY3R1cmUgaGFzIHRoZSBjYXBhYmlsaXR5IHRvIHN1
cHBvcnQgYSBEb20wLg0KPj4NCj4+IFRoZSBgRE9NMF9CT09UYCBvcHRpb24gZGVwZW5kcyBvbiBg
SEFTX0RPTTBgIGFuZCBkZWZhdWx0cyB0byAneScuIEZvcg0KPj4gZXhwZXJ0IHVzZXJzLCB0aGlz
IG9wdGlvbiBjYW4gYmUgZGlzYWJsZWQgKGBDT05GSUdfRVhQRVJUPXlgIGFuZCBubw0KPj4gYENP
TkZJR19ET00wX0JPT1RgIGluIHRoZSBjb25maWcpLCB3aGljaCB3aWxsIGNvbXBpbGUgb3V0IHRo
ZSBEb20wDQo+PiBjcmVhdGlvbiBjb2RlIG9uIEFSTS4gVGhpcyBpcyB1c2VmdWwgZm9yIGVtYmVk
ZGVkIG9yIGRvbTBsZXNzLW9ubHkNCj4+IHNjZW5hcmlvcyB0byByZWR1Y2UgYmluYXJ5IHNpemUg
YW5kIGNvbXBsZXhpdHkuDQo+Pg0KPj4gVGhlIEFSTSBib290IHBhdGggaGFzIGJlZW4gdXBkYXRl
ZCB0byBwYW5pYyBpZiBpdCBkZXRlY3RzIGEgbm9uLWRvbTBsZXNzDQo+PiBjb25maWd1cmF0aW9u
IHdoaWxlIGBDT05GSUdfRE9NMF9CT09UYCBpcyBkaXNhYmxlZCwgcHJldmVudGluZyBhbiANCj4+
IGludmFsaWQNCj4+IGJvb3QuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVp
ZXYgPG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4NCj4+IC0tLQ0KPj4NCj4+IENoYW5n
ZXMgaW4gdjM6DQo+PiAtIHJlcGhyYXNlIGVycm9yIG1lc3NhZ2Ugd2hlbiBkb20wbGVzcyBtb2Rl
IHdhc24ndCBkZXRlY3RlZCB3aGlsZSBkb20wDQo+PiBpcyBkaXNhYmxlZC4NCj4+IC0gcmVwaHJh
c2UgaGVscCBtZXNzYWdlIGZvciBET00wX0JPT1QgY29uZmlnIG9wdGlvbg0KPj4gLSB1cGRhdGUg
RE9NMF9CT09UIGRlcGVuZGVuY2llcyBmb3IgWDg2DQo+Pg0KPj4gQ2hhbmdlcyBpbiB2MjoNCj4+
IC0gZGVjaWRlZCBub3QgdG8gcmVuYW1lIEhBU19ET00wIChIQVNfT1BUSU9OQUxfRE9NMCB3YXMg
YW5vdGhlciBvcHRpb24NCj4+IHN1Z2dlc3RlZCBpbiBNTCkgYmVjYXVzZSBpbiB0aGlzIGNhc2Ug
SEFTX0RPTTBMRVNTIHNob3VsZCBiZSByZW5hbWVkDQo+PiBlaXRoZXIuDQo+PiAtIGZpeCBvcmRl
ciBvZiBIQVNfRE9NMCBjb25maWcgcGFyYW1ldGVyDQo+PiAtIGFkZCBIQVNfRE9NMCBvcHRpb24g
dG8geDg2IGFyY2hpdGVjdHVyZS4NCj4+DQo+PiBDT05GSUdfRE9NMF9CT09UIEtjb25maWcgb3B0
aW9uIHdhcyBpbnRyb2R1Y2VkIHRvIG1ha2UgdGhlIERvbTANCj4+IHJlZ3VsYXIgKGxlZ2FjeSkg
ZG9tYWluIGFuIG9wdGlvbmFsIGZlYXR1cmUgdGhhdCBjYW4gYmUgY29tcGlsZWQgb3V0DQo+PiBm
cm9tIHRoZSBYZW4gaHlwZXJ2aXNvciBidWlsZC4NCj4+DQo+PiBUaGUgcHJpbWFyeSBtb3RpdmF0
aW9uIGZvciB0aGlzIGNoYW5nZSBpcyB0byBlbmhhbmNlIG1vZHVsYXJpdHkgYW5kDQo+PiBwcm9k
dWNlIGEgY2xlYW5lciwgbW9yZSBzcGVjaWFsaXplZCBoeXBlcnZpc29yIGJpbmFyeSB3aGVuIGEg
Y29udHJvbA0KPj4gZG9tYWluIGlzIG5vdCBuZWVkZWQuIEluIG1hbnkgZW1iZWRkZWQgb3IgZGVk
aWNhdGVkIHN5c3RlbXMsIFhlbiBpcw0KPj4gdXNlZCBpbiBhICJkb20wbGVzcyIgY29uZmlndXJh
dGlvbiB3aGVyZSBndWVzdHMgYXJlIHByZS1jb25maWd1cmVkIGFuZA0KPj4gbGF1bmNoZWQgZGly
ZWN0bHkgYnkgdGhlIGh5cGVydmlzb3IuIEluIHRoZXNlIHNjZW5hcmlvcywgdGhlIGVudGlyZQ0K
Pj4gc3Vic3lzdGVtIGZvciBib290aW5nIGFuZCBtYW5hZ2luZyBEb20wIGlzIHVubmVjZXNzYXJ5
Lg0KPj4NCj4+IFRoaXMgYXBwcm9hY2ggYWxpZ25zIHdpdGggc29mdHdhcmUgcXVhbGl0eSBzdGFu
ZGFyZHMgbGlrZSBNSVNSQSBDLA0KPj4gd2hpY2ggYWR2b2NhdGUgZm9yIHRoZSByZW1vdmFsIG9m
IHVucmVhY2hhYmxlIG9yIHVubmVjZXNzYXJ5IGNvZGUgdG8NCj4+IGltcHJvdmUgc2FmZXR5IGFu
ZCBtYWludGFpbmFiaWxpdHkuIFNwZWNpZmljYWxseSwgdGhpcyBjaGFuZ2UgaGVscHMgDQo+PiBh
ZGhlcmUgdG86DQo+Pg0KPj4gTUlTUkEgQzoyMDEyLCBSdWxlIDIuMjogIlRoZXJlIHNoYWxsIGJl
IG5vIGRlYWQgY29kZSINCj4+DQo+PiBJbiBhIGJ1aWxkIGNvbmZpZ3VyZWQgZm9yIGEgZG9tMGxl
c3MgZW52aXJvbm1lbnQsIHRoZSBjb2RlIHJlc3BvbnNpYmxlDQo+PiBmb3IgY3JlYXRpbmcgRG9t
MCB3b3VsZCBiZSBjb25zaWRlcmVkICJkZWFkIGNvZGUiIGFzIGl0IHdvdWxkIG5ldmVyIGJlDQo+
PiBleGVjdXRlZC4gQnkgdXNpbmcgdGhlIHByZXByb2Nlc3NvciB0byByZW1vdmUgaXQgYmVmb3Jl
IGNvbXBpbGF0aW9uLA0KPj4gd2UgZW5zdXJlIHRoYXQgdGhlIGZpbmFsIGV4ZWN1dGFibGUgaXMg
ZnJlZSBmcm9tIHRoaXMgdW5yZWFjaGFibGUNCj4+IGNvZGUuIFRoaXMgc2ltcGxpZmllcyBzdGF0
aWMgYW5hbHlzaXMsIHJlZHVjZXMgdGhlIGF0dGFjayBzdXJmYWNlLA0KPj4gYW5kIG1ha2VzIHRo
ZSBjb2RlYmFzZSBlYXNpZXIgdG8gdmVyaWZ5LCB3aGljaCBpcyBjcml0aWNhbCBmb3INCj4+IHN5
c3RlbXMgcmVxdWlyaW5nIGhpZ2ggbGV2ZWxzIG9mIHNhZmV0eSBhbmQgc2VjdXJpdHkuDQo+Pg0K
Pg0KPiBNaXNyYSdzIGRlZmluaXRpb24gb2YgImRlYWQgY29kZSIgaXMgY29kZSB0aGF0IGlzIGV4
ZWN1dGVkLCBidXQgY2FuIGJlIA0KPiByZW1vdmVkIHdpdGhvdXQgY2hhbmdpbmcgdGhlIGJlaGF2
aW9yIG9mIHRoZSBwcm9ncmFtLCB3aGlsZSANCj4gdW5yZWFjaGFibGUgY29kZSBpcyBjb2RlIHRo
YXQgaXMgbm90IGV4ZWN1dGVkLCBzbyBJIHdvdWxkIGNpdGUgTUlTUkEgQyANCj4gUnVsZSAyLjEg
KCJBIHByb2plY3Qgc2hhbGwgbm90IGNvbnRhaW4gdW5yZWFjaGFibGUgY29kZSIpLCByYXRoZXIg
dGhhdCANCj4gUjIuMi4NCj4NCkdvb2QgcG9pbnQuIFRoYW5rcyBhbG90Lg0KPj4gLS0tDQo+PiDC
oHhlbi9hcmNoL2FybS9LY29uZmlnwqDCoMKgwqDCoMKgwqAgfMKgIDEgKw0KPj4gwqB4ZW4vYXJj
aC9hcm0vZG9tYWluX2J1aWxkLmMgfMKgIDggKysrKysrKysNCj4+IMKgeGVuL2FyY2gvYXJtL3Nl
dHVwLmPCoMKgwqDCoMKgwqDCoCB8IDE0ICsrKysrKysrKystLS0tDQo+PiDCoHhlbi9hcmNoL3g4
Ni9LY29uZmlnwqDCoMKgwqDCoMKgwqAgfMKgIDEgKw0KPj4gwqB4ZW4vY29tbW9uL0tjb25maWfC
oMKgwqDCoMKgwqDCoMKgwqAgfCAxMSArKysrKysrKysrKw0KPj4gwqA1IGZpbGVzIGNoYW5nZWQs
IDMxIGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL2FybS9LY29uZmlnIGIveGVuL2FyY2gvYXJtL0tjb25maWcNCj4+IGluZGV4IGNmNmFm
NjgyOTkuLjMzNmIyZWQyNDIgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vS2NvbmZpZw0K
Pj4gKysrIGIveGVuL2FyY2gvYXJtL0tjb25maWcNCj4+IEBAIC0xNyw2ICsxNyw3IEBAIGNvbmZp
ZyBBUk0NCj4+IMKgwqDCoMKgIHNlbGVjdCBHRU5FUklDX1VBUlRfSU5JVA0KPj4gwqDCoMKgwqAg
c2VsZWN0IEhBU19BTFRFUk5BVElWRSBpZiBIQVNfVk1BUA0KPj4gwqDCoMKgwqAgc2VsZWN0IEhB
U19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkNCj4+ICvCoMKgwqAgc2VsZWN0IEhBU19ET00wDQo+PiDC
oMKgwqDCoCBzZWxlY3QgSEFTX0RPTTBMRVNTDQo+PiDCoMKgwqDCoCBzZWxlY3QgSEFTX0dSQU5U
X0NBQ0hFX0ZMVVNIIGlmIEdSQU5UX1RBQkxFDQo+PiDCoMKgwqDCoCBzZWxlY3QgSEFTX1NUQUNL
X1BST1RFQ1RPUg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyBi
L3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gaW5kZXggZmI4ZmJiMTY1MC4uNjI2MDJh
ZmM3OCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gKysr
IGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiBAQCAtNDIsOCArNDIsMTAgQEANCj4+
IMKgI2luY2x1ZGUgPGFzbS9ncmFudF90YWJsZS5oPg0KPj4gwqAjaW5jbHVkZSA8eGVuL3Nlcmlh
bC5oPg0KPj4NCj4+ICsjaWZkZWYgQ09ORklHX0RPTTBfQk9PVA0KPj4gwqBzdGF0aWMgdW5zaWdu
ZWQgaW50IF9faW5pdGRhdGEgb3B0X2RvbTBfbWF4X3ZjcHVzOw0KPj4gwqBpbnRlZ2VyX3BhcmFt
KCJkb20wX21heF92Y3B1cyIsIG9wdF9kb20wX21heF92Y3B1cyk7DQo+PiArI2VuZGlmDQo+Pg0K
Pj4gwqAvKg0KPj4gwqAgKiBJZiB0cnVlLCB0aGUgZXh0ZW5kZWQgcmVnaW9ucyBzdXBwb3J0IGlz
IGVuYWJsZWQgZm9yIGRvbTAgYW5kDQo+PiBAQCAtMTA0LDYgKzEwNiw3IEBAIGludCBfX2luaXQg
cGFyc2VfYXJjaF9kb20wX3BhcmFtKGNvbnN0IGNoYXIgKnMsIA0KPj4gY29uc3QgY2hhciAqZSkN
Cj4+IMKgICovDQo+PiDCoCNkZWZpbmUgRE9NMF9GRFRfRVhUUkFfU0laRSAoMTI4ICsgc2l6ZW9m
KHN0cnVjdCBmZHRfcmVzZXJ2ZV9lbnRyeSkpDQo+Pg0KPj4gKyNpZmRlZiBDT05GSUdfRE9NMF9C
T09UDQo+PiDCoHVuc2lnbmVkIGludCBfX2luaXQgZG9tMF9tYXhfdmNwdXModm9pZCkNCj4+IMKg
ew0KPj4gwqDCoMKgwqAgaWYgKCBvcHRfZG9tMF9tYXhfdmNwdXMgPT0gMCApDQo+PiBAQCAtMTE2
LDYgKzExOSw3IEBAIHVuc2lnbmVkIGludCBfX2luaXQgZG9tMF9tYXhfdmNwdXModm9pZCkNCj4+
DQo+PiDCoMKgwqDCoCByZXR1cm4gb3B0X2RvbTBfbWF4X3ZjcHVzOw0KPj4gwqB9DQo+PiArI2Vu
ZGlmDQo+Pg0KPj4gwqAvKg0KPj4gwqAgKiBJbnNlcnQgdGhlIGdpdmVuIHBhZ2VzIGludG8gYSBt
ZW1vcnkgYmFuaywgYmFua3MgYXJlIG9yZGVyZWQgYnkgDQo+PiBhZGRyZXNzLg0KPj4gQEAgLTE5
NjIsNiArMTk2Niw3IEBAIGludCBfX2luaXQgY29uc3RydWN0X2RvbWFpbihzdHJ1Y3QgZG9tYWlu
ICpkLCANCj4+IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQo+PiDCoMKgwqDCoCByZXR1cm4g
MDsNCj4+IMKgfQ0KPj4NCj4+ICsjaWZkZWYgQ09ORklHX0RPTTBfQk9PVA0KPj4gwqBzdGF0aWMg
aW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMChzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gwqB7DQo+PiDC
oMKgwqDCoCBzdHJ1Y3Qga2VybmVsX2luZm8ga2luZm8gPSBLRVJORUxfSU5GT19JTklUOw0KPj4g
QEAgLTE5OTMsNiArMTk5OCw3IEBAIHN0YXRpYyBpbnQgX19pbml0IGNvbnN0cnVjdF9kb20wKHN0
cnVjdCBkb21haW4gKmQpDQo+Pg0KPj4gwqDCoMKgwqAgcmV0dXJuIGNvbnN0cnVjdF9od2RvbSgm
a2luZm8sIE5VTEwpOw0KPj4gwqB9DQo+PiArI2VuZGlmDQo+Pg0KPj4gwqBpbnQgX19pbml0IGNv
bnN0cnVjdF9od2RvbShzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZvLA0KPj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbnN0IHN0cnVjdCBk
dF9kZXZpY2Vfbm9kZSAqbm9kZSkNCj4+IEBAIC0yMDQ2LDYgKzIwNTIsNyBAQCBpbnQgX19pbml0
IGNvbnN0cnVjdF9od2RvbShzdHJ1Y3Qga2VybmVsX2luZm8gDQo+PiAqa2luZm8sDQo+PiDCoMKg
wqDCoCByZXR1cm4gY29uc3RydWN0X2RvbWFpbihkLCBraW5mbyk7DQo+PiDCoH0NCj4+DQo+PiAr
I2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+IMKgdm9pZCBfX2luaXQgY3JlYXRlX2RvbTAodm9p
ZCkNCj4+IMKgew0KPj4gwqDCoMKgwqAgc3RydWN0IGRvbWFpbiAqZG9tMDsNCj4+IEBAIC0yMTAz
LDYgKzIxMTAsNyBAQCB2b2lkIF9faW5pdCBjcmVhdGVfZG9tMCh2b2lkKQ0KPj4NCj4+IMKgwqDC
oMKgIHNldF94c19kb21haW4oZG9tMCk7DQo+PiDCoH0NCj4+ICsjZW5kaWYgLyogQ09ORklHX0RP
TTBfQk9PVCAqLw0KPj4NCj4+IMKgLyoNCj4+IMKgICogTG9jYWwgdmFyaWFibGVzOg0KPj4gZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9zZXR1cC5jIGIveGVuL2FyY2gvYXJtL3NldHVwLmMNCj4+
IGluZGV4IDdhZDg3MGUzODIuLmZiYjI5MGRmNjAgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9h
cm0vc2V0dXAuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3NldHVwLmMNCj4+IEBAIC00ODEsMTIg
KzQ4MSwxOCBAQCB2b2lkIGFzbWxpbmthZ2UgX19pbml0IG5vcmV0dXJuIA0KPj4gc3RhcnRfeGVu
KHVuc2lnbmVkIGxvbmcgZmR0X3BhZGRyKQ0KPj4gwqDCoMKgwqAgZW5hYmxlX2VycmF0YV93b3Jr
YXJvdW5kcygpOw0KPj4gwqDCoMKgwqAgZW5hYmxlX2NwdV9mZWF0dXJlcygpOw0KPj4NCj4+IC3C
oMKgwqAgLyogQ3JlYXRlIGluaXRpYWwgZG9tYWluIDAuICovDQo+PiAtwqDCoMKgIGlmICggIWlz
X2RvbTBsZXNzX21vZGUoKSApDQo+PiArwqDCoMKgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRE9N
MF9CT09UKSAmJiAhaXNfZG9tMGxlc3NfbW9kZSgpICkNCj4+ICvCoMKgwqAgew0KPj4gK8KgwqDC
oMKgwqDCoMKgIC8qIENyZWF0ZSBpbml0aWFsIGRvbWFpbiAwLiAqLw0KPj4gwqDCoMKgwqDCoMKg
wqDCoCBjcmVhdGVfZG9tMCgpOw0KPj4gK8KgwqDCoCB9DQo+PiDCoMKgwqDCoCBlbHNlDQo+PiAt
wqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhFTkxPR19JTkZPICJYZW4gZG9tMGxlc3MgbW9kZSBkZXRl
Y3RlZFxuIik7DQo+PiAtDQo+PiArwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIGlz
X2RvbTBsZXNzX21vZGUoKSkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHByaW50ayhYRU5M
T0dfSU5GTyAiWGVuIGRvbTBsZXNzIG1vZGUgZGV0ZWN0ZWRcbiIpOw0KPj4gK8KgwqDCoMKgwqDC
oMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHBhbmljKCJOZWl0aGVyIGRvbTAg
bm9yIGRvbTBsZXNzIG1vZGUgd2FzIGRldGVjdGVkLCANCj4+IGFib3J0aW5nXG4iKTsNCj4+ICvC
oMKgwqAgfQ0KPj4gwqDCoMKgwqAgaWYgKCBhY3BpX2Rpc2FibGVkICkNCj4+IMKgwqDCoMKgIHsN
Cj4+IMKgwqDCoMKgwqDCoMKgwqAgY3JlYXRlX2RvbVVzKCk7DQo+PiBkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L0tjb25maWcgYi94ZW4vYXJjaC94ODYvS2NvbmZpZw0KPj4gaW5kZXggM2YwZjNh
MGYzYS4uMmFlYjM2MWM2MyAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnDQo+
PiArKysgYi94ZW4vYXJjaC94ODYvS2NvbmZpZw0KPj4gQEAgLTE4LDYgKzE4LDcgQEAgY29uZmln
IFg4Ng0KPj4gwqDCoMKgwqAgc2VsZWN0IEhBU19DT01QQVQNCj4+IMKgwqDCoMKgIHNlbGVjdCBI
QVNfQ1BVRlJFUQ0KPj4gwqDCoMKgwqAgc2VsZWN0IEhBU19ESVQNCj4+ICvCoMKgwqAgc2VsZWN0
IEhBU19ET00wDQo+PiDCoMKgwqDCoCBzZWxlY3QgSEFTX0VIQ0kNCj4+IMKgwqDCoMKgIHNlbGVj
dCBIQVNfRVhfVEFCTEUNCj4+IMKgwqDCoMKgIHNlbGVjdCBIQVNfRkFTVF9NVUxUSVBMWQ0KPj4g
ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vS2NvbmZpZyBiL3hlbi9jb21tb24vS2NvbmZpZw0KPj4g
aW5kZXggNzZmOWNlNzA1Zi4uMTBhOGZjODcxOCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9jb21tb24v
S2NvbmZpZw0KPj4gKysrIGIveGVuL2NvbW1vbi9LY29uZmlnDQo+PiBAQCAtMjYsNiArMjYsMTQg
QEAgY29uZmlnIERPTTBMRVNTX0JPT1QNCj4+IMKgwqDCoMKgwqDCoCBYZW4gYm9vdCB3aXRob3V0
IHRoZSBuZWVkIG9mIGEgY29udHJvbCBkb21haW4gKERvbTApLCB3aGljaCANCj4+IGNvdWxkIGJl
DQo+PiDCoMKgwqDCoMKgwqAgcHJlc2VudCBhbnl3YXkuDQo+Pg0KPj4gK2NvbmZpZyBET00wX0JP
T1QNCj4+ICvCoMKgwqAgYm9vbCAiRG9tMCBib290IHN1cHBvcnQiIGlmIEVYUEVSVA0KPj4gK8Kg
wqDCoCBkZWZhdWx0IHkNCj4+ICvCoMKgwqAgZGVwZW5kcyBvbiAoQVJNICYmIEhBU19ET00wICYm
IEhBU19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkgJiYgDQo+PiBET01BSU5fQlVJTERfSEVMUEVSUykg
fHwgKFg4NiAmJiBIQVNfRE9NMCkNCj4+ICvCoMKgwqAgaGVscA0KPj4gK8KgwqDCoMKgwqAgRG9t
MCBib290IHN1cHBvcnQgZW5hYmxlcyBYZW4gdG8gYm9vdCB0byB0aGUgYWxsLXBvd2VyZnVsIA0K
Pj4gZG9tYWluIChEb20wKS4NCj4+ICvCoMKgwqDCoMKgIElmIHRoaXMgaXNuJ3QgZW5hYmxlZCBY
ZW4gaXMgZXhwZWN0ZWQgdG8gYm9vdCBpbiBkb20wbGVzcyBtb2RlIA0KPj4gb25seS4NCj4+ICsN
Cj4+IMKgY29uZmlnIERPTUFJTl9CVUlMRF9IRUxQRVJTDQo+PiDCoMKgwqDCoCBib29sDQo+Pg0K
Pj4gQEAgLTEyNSw2ICsxMzMsOSBAQCBjb25maWcgSEFTX0RFVklDRV9UUkVFX0RJU0NPVkVSWQ0K
Pj4gwqDCoMKgwqAgYm9vbA0KPj4gwqDCoMKgwqAgc2VsZWN0IERFVklDRV9UUkVFX1BBUlNFDQo+
Pg0KPj4gK2NvbmZpZyBIQVNfRE9NMA0KPj4gK8KgwqDCoCBib29sDQo+PiArDQo+PiDCoGNvbmZp
ZyBIQVNfRE9NMExFU1MNCj4+IMKgwqDCoMKgIGJvb2wNCj4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 18:11:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 18:11:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129620.1469512 (Exim 4.92)
	(envelope-from )
	id 1v1Tx1-0007kP-TG; Wed, 24 Sep 2025 18:10:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129620.1469512; Wed, 24 Sep 2025 18:10:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Tx1-0007kI-QS; Wed, 24 Sep 2025 18:10:47 +0000
Received: by outflank-mailman (input) for mailman id 1129620;
 Wed, 24 Sep 2025 16:24:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1SIY-0003AP-Fw
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 16:24: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 ff7e5d69-9962-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 18:24: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 4E92160205;
 Wed, 24 Sep 2025 16:24:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 629B9C4CEE7;
 Wed, 24 Sep 2025 16:24: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: ff7e5d69-9962-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758731091;
	bh=YDQXTVGOYTWva8EDpEwYuBr0RgnUKG4x/JRMrHY45WA=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=rv4cs34/Qim8+evoo8ovxwouSo7ZGm3TI9LuDHjLvPp+9BNsAW86i5ETDW2z9zgbS
	 t1jCkRpP3DUkUTDh/pkjL6LwA58lCk3aAbmFSPmU+fs70OS8Ja80hE4+ougHuXWAdx
	 a8vFkzPrjcaO1uCAFBl37t3oCls0JUSZ0fuZn0l9N1EV531V1cnesgWHxjrkr1Hao8
	 r9rBsgtCOcl8qT7JR2g8zQ9SMGIHZ3sfQREqWI1i74rpoz0CvMeGDKWf/hLsg7wyNX
	 lpAuzlykFkUGgmFZxwgjHgnBF312aBL288V6fwXbKcCgN4y/GEpY5+nI93lu030Fht
	 FjJ6Fs4CbVVCA==
Message-ID: <38a9db70-c6dc-40f0-a506-942fb799fa86@kernel.org>
Date: Wed, 24 Sep 2025 11:24:49 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: take system_transition_mutex on suspend
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 "Rafael J. Wysocki" ,
 "moderated list:XEN HYPERVISOR INTERFACE" 
References: <20250921162853.223116-1-marmarek@invisiblethingslab.com>
 
Content-Language: en-US
From: Mario Limonciello 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 9/22/25 1:06 AM, Jürgen Groß wrote:
> On 21.09.25 18:28, Marek Marczykowski-Górecki wrote:
>> Xen's do_suspend() calls dpm_suspend_start() without taking required
>> system_transition_mutex. Since 12ffc3b1513eb moved the
>> pm_restrict_gfp_mask() call, not taking that mutex results in a WARN.
>>
>> Take the mutex in do_suspend(), and use mutex_trylock() to follow
>> how enter_state() does this.
>>
>> Suggested-by: Jürgen Groß 
>> Fixes: 12ffc3b1513eb "PM: Restrict swap use to later in the suspend 
>> sequence"
>> Link: https://lore.kernel.org/xen-devel/aKiBJeqsYx_4Top5@mail-itl/
>> Signed-off-by: Marek Marczykowski-Górecki 
>> 
>> Cc: stable@vger.kernel.org # v6.16+
> 
> Reviewed-by: Juergen Gross 
> 
> 
> Juergen

Reviewed-by: Mario Limonciello (AMD) 


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 19:33:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 19:33:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129679.1469523 (Exim 4.92)
	(envelope-from )
	id 1v1VEx-0000Mt-Mo; Wed, 24 Sep 2025 19:33:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129679.1469523; Wed, 24 Sep 2025 19: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 1v1VEx-0000Mm-Jj; Wed, 24 Sep 2025 19:33:23 +0000
Received: by outflank-mailman (input) for mailman id 1129679;
 Wed, 24 Sep 2025 19:33:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1VEw-0000Mg-9F
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 19:33:22 +0000
Received: from fout-b7-smtp.messagingengine.com
 (fout-b7-smtp.messagingengine.com [202.12.124.150])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 531445a9-997d-11f0-9d14-b5c5bf9af7f9;
 Wed, 24 Sep 2025 21:33:20 +0200 (CEST)
Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52])
 by mailfout.stl.internal (Postfix) with ESMTP id A8B021D0008C;
 Wed, 24 Sep 2025 15:33:18 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-12.internal (MEProxy); Wed, 24 Sep 2025 15:33:18 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 24 Sep 2025 15:33:17 -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: 531445a9-997d-11f0-9d14-b5c5bf9af7f9
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=1758742398;
	 x=1758828798; bh=B5ttDfSsGgDCbZiM+N4h1AzDTCDphKCk7GkTUmZUHhA=; b=
	f/Uy+LQ7CYtWIkYY4z6sgxi2D4uWXPe05AJI1rSfRaQzaEh6NyC9yWaRcb59Nl+n
	z8BQOyAmsg91eY9vF13+9awE2VUiuB+FuLSLmyPUsvmJtokDQi2+LDQFr+5fc84C
	D0NLGm/sesWuqxWwLAZhFC6I5NnA9QrG5PlIMaO25RjqvHISoZck/HsX1bKYGvHD
	NoU26sj+Amw2bEsD09teT24LV0u5F8hzkInzu30c+hJHzOkA2vTclqT6e9XfKXfX
	v7/8rtqQL2DfZnYB9uF0MD3d2eYGa/0TTCKJj0bMzA54bKiXoL3gQPTPSiBgSsA7
	ak6P2anBxGhTttkerghvaQ==
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=
	1758742398; x=1758828798; bh=B5ttDfSsGgDCbZiM+N4h1AzDTCDphKCk7Gk
	TUmZUHhA=; b=ChBNh34FnElEvh4NlCH+u+fe6zfGP4ltpHmPojFQeMBfCumK4LU
	d3QhWUByc05eLUJTToveTOwS6HbCRWO/e6bCHnKVC1t3lhL9mwksW5eRfSmZ2x1R
	OzU1a8ZgoCRdtRWImMrmOJXasj0r641GqX61BMe7WavU+Er3idh218TYYYXTj51G
	nqWy3SdWDmEqeQSLRa0gwwYC279+2LYrTkP95j2yarnfNLSO7/sOwCfA9aWh74/O
	2ZBxEPNXJ9Py7QKiGBDR3ms9juQWibfgiNTW/7fgRU5Lt1HT5erodFYsdUxOo03q
	KuExUWxIgHlp1jah9vbGzLur8R8cQb51SCw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeigeeghecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeukeetteeg
    gffgkeduheetgeeileejjeeiiefhjeegvefhtefggfetueetteeuteenucffohhmrghinh
    epghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm
    rghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsg
    drtghomhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthht
    ohephigrnhhnrdhsihhonhhnvggruhesvhgrthgvshdrthgvtghhpdhrtghpthhtohepgi
    gvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 24 Sep 2025 21:33:15 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Yann Sionneau 
Cc: xen-devel@lists.xenproject.org
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16
Message-ID: 
References: 
 
 <05e9628d-83e5-4feb-881d-5854b72bd560@suse.com>
 
 
 <8f6b8f08-ca62-467b-a6be-4d33208e5393@epam.com>
 
 <32097dc9-761f-4319-9fa8-6bcb15c06a82@vates.tech>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="iQNCPjvv7VHlfBcR"
Content-Disposition: inline
In-Reply-To: <32097dc9-761f-4319-9fa8-6bcb15c06a82@vates.tech>


--iQNCPjvv7VHlfBcR
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Sep 2025 21:33:15 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Yann Sionneau 
Cc: xen-devel@lists.xenproject.org
Subject: Re: domU suspend issue - freeze processes failed - Linux 6.16

On Wed, Sep 24, 2025 at 02:28:27PM +0000, Yann Sionneau wrote:
> On 9/24/25 15:30, Marek Marczykowski-G=C3=B3recki wrote:
> > On Wed, Sep 24, 2025 at 01:17:15PM +0300, Grygorii Strashko wrote:
> >>
> >>
> >> On 22.09.25 13:09, Marek Marczykowski-G=C3=B3recki wrote:
> >>> On Fri, Aug 22, 2025 at 08:42:30PM +0200, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> >>>> On Fri, Aug 22, 2025 at 05:27:20PM +0200, J=C3=BCrgen Gro=C3=9F wrot=
e:
> >>>>> On 22.08.25 16:42, Marek Marczykowski-G=C3=B3recki wrote:
> >>>>>> On Fri, Aug 22, 2025 at 04:39:33PM +0200, Marek Marczykowski-G=C3=
=B3recki wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> When suspending domU I get the following issue:
> >>>>>>>
> >>>>>>>        Freezing user space processes
> >>>>>>>        Freezing user space processes failed after 20.004 seconds =
(1 tasks refusing to freeze, wq_busy=3D0):
> >>>>>>>        task:xl              state:D stack:0     pid:466   tgid:46=
6   ppid:1      task_flags:0x400040 flags:0x00004006
> >>>>>>>        Call Trace:
> >>>>>>>         
> >>>>>>>         __schedule+0x2f3/0x780
> >>>>>>>         schedule+0x27/0x80
> >>>>>>>         schedule_preempt_disabled+0x15/0x30
> >>>>>>>         __mutex_lock.constprop.0+0x49f/0x880
> >>>>>>>         unregister_xenbus_watch+0x216/0x230
> >>>>>>>         xenbus_write_watch+0xb9/0x220
> >>>>>>>         xenbus_file_write+0x131/0x1b0
> >>>>>>>         vfs_writev+0x26c/0x3d0
> >>>>>>>         ? do_writev+0xeb/0x110
> >>>>>>>         do_writev+0xeb/0x110
> >>>>>>>         do_syscall_64+0x84/0x2c0
> >>>>>>>         ? do_syscall_64+0x200/0x2c0
> >>>>>>>         ? generic_handle_irq+0x3f/0x60
> >>>>>>>         ? syscall_exit_work+0x108/0x140
> >>>>>>>         ? do_syscall_64+0x200/0x2c0
> >>>>>>>         ? __irq_exit_rcu+0x4c/0xe0
> >>>>>>>         entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >>>>>>>        RIP: 0033:0x79b618138642
> >>>>>>>        RSP: 002b:00007fff9a192fc8 EFLAGS: 00000246 ORIG_RAX: 0000=
000000000014
> >>>>>>>        RAX: ffffffffffffffda RBX: 00000000024fd490 RCX: 000079b61=
8138642
> >>>>>>>        RDX: 0000000000000003 RSI: 00007fff9a193120 RDI: 000000000=
0000014
> >>>>>>>        RBP: 00007fff9a193000 R08: 0000000000000000 R09: 000000000=
0000000
> >>>>>>>        R10: 0000000000000000 R11: 0000000000000246 R12: 000000000=
0000014
> >>>>>>>        R13: 00007fff9a193120 R14: 0000000000000003 R15: 000000000=
0000000
> >>>>>>>         
> >>>>>>>        OOM killer enabled.
> >>>>>>>        Restarting tasks: Starting
> >>>>>>>        Restarting tasks: Done
> >>>>>>>        xen:manage: do_suspend: freeze processes failed -16
> >>>>>>>
> >>>>>>> The process in question is `xl devd` daemon. It's a domU serving a
> >>>>>>> xenvif backend.
> >>>>>>>
> >>>>>>> I noticed it on 6.16.1, but looking at earlier test logs I see it=
 with
> >>>>>>> 6.16-rc6 already (but interestingly, not 6.16-rc2 yet? feels weir=
d given
> >>>>>>> seemingly no relevant changes between rc2 and rc6).
> >>>>>>
> >>>>>> I forgot to include link for (a little) more details:
> >>>>>> https://github.com/QubesOS/qubes-linux-kernel/pull/1157
> >>>>>>
> >>>>>> Especially, there is another call trace with panic_on_warn enabled=
 -
> >>>>>> slightly different, but looks related.
> >>>>>>
> >>>>>
> >>>>> I'm pretty sure the PV variant for suspending is just wrong: it is =
calling
> >>>>> dpm_suspend_start() from do_suspend() without taking the required
> >>>>> system_transition_mutex, resulting in the WARN() in pm_restrict_gfp=
_mask().
> >>>>>
> >>>>> It might be as easy as just adding the mutex() call to do_suspend()=
, but I'm
> >>>>> really not sure that will be a proper fix.
> >>>>
> >>>> Hm, this might explain the second call trace, but not the freeze fai=
lure
> >>>> quoted here above, I think?
> >>>
> >>> While the patch I sent appears to fix this particular issue, it made =
me
> >>> wonder: is there any fundamental reason why do_suspend() is not using
> >>> pm_suspend() and register Xen-specific actions via platform_suspend_o=
ps
> >>> (and maybe syscore_ops)? From a brief look at the code, it should
> >>> theoretically be possible, and should avoid issues like this.
> >>>
> >>> I tried to do a quick&dirty attempt at that[1], and it failed (panic)=
=2E I
> >>> surely made several mistakes there (and also left a ton of todo
> >>> comments). But before spending any more time at that, I'd like to ask
> >>> if this is a viable option at all.
> >>
> >> I think it might, but be careful with this, because there are two "Sys=
tem Low power" paths in Linux
> >> 1) Suspend2RAM and Co
> >> 2) Hybernation
> >>
> >> While "Suspend2RAM and Co" path is relatively straight forward and exp=
ected to be always
> >> started through pm_suspend(). In general, it's expected to happen
> >>   - from sysfs (User space)
> >>   - from autosuspend (wakelocks).
> >>
> >> the "hibernation" path is more complicated:(
> >> - Genuine Linux hybernation hibernate()/hibernate_quiet_exec()
> >
> > IIUC hibernation is very different as it puts Linux in charge of dumping
> > all the state to the disk. In case of Xen, the primary use case for
> > suspend is preparing VM for Xen toolstack serializing its state to disk
> > (or migrating to another host).
> > Additionally, VM suspend may be used as preparation for host suspend
> > (this is what I actually do here). This is especially relevant if the VM
> > has some PCI passthrough - to properly suspend (and resume) devices
> > across host suspend.
> >
> >> I'm not sure what path Xen originally implemented :( It seems like "su=
spend2RAM",
> >> but, at the same time "hybernation" specific staff is used, like PMSG_=
FREEZE/PMSG_THAW/PMSG_RESTORE.
> >> As result, Linux suspend/hybernation code moves forward while Xen stay=
s behind and unsync.
> >
> > Yeah, I think it's supposed to be suspend2RAM. TBH the
> > PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE confuses me too and Qubes OS has a
> > patch[2] to switch it to PMSG_SUSPEND/PMSG_RESUME.
> >
> >> So it sounds reasonable to avoid custom implementation, but may be not=
 easy :(
> >>
> >> Suspending Xen features can be split between suspend stages, but
> >> not sure if platform_suspend_ops can be used.
> >>
> >> Generic suspend stages list
> >> - freeze
> >> - prepare
> >> - suspend
> >> - suspend_late
> >> - suspend_noirq (SPIs disabled, except wakeups)
> >>    [most of Xen specific staff has to be suspended at this point]
> >> - disable_secondary_cpus
> >> - arch disable IRQ (from this point no IRQs allowed, no timers, no sch=
eduling)
> >> - syscore_suspend
> >>    [rest here]
> >> - platform->enter() (suspended)
> >>
> >> You can't just overwrite platform_suspend_ops, because ARM64 is expect=
ed to enter
> >> suspend through PSCI FW interface:
> >> drivers/firmware/psci/psci.c
> >>   static const struct platform_suspend_ops psci_suspend_ops =3D {
> >
> > Does this apply to a VM on ARM64 too? At least on x86, the VM is
> > supposed to make a hypercall to tell Xen it suspended (the hypercall
> > will return only on resume).
> >
> >> As an option, some Xen components could be converted to use syscore_op=
s (but not xenstore),
> >> and some might need to use DD(dev_pm_ops).
> >>
> >>>
> >>> [1] https://github.com/marmarek/linux/commit/47cfdb991c85566c9c333570=
511e67bf477a5da6
> >>
> >> --
> >> Best regards,
> >> -grygorii
> >>
> >
> > [2] https://github.com/QubesOS/qubes-linux-kernel/blob/main/xen-pm-use-=
suspend.patch
> >
>=20
> On my setup I get a weird behavior when trying to suspend (s2idle) a
> Linux guest.
> Doing echo freeze > /sys/power/state in the guest seems to "freeze" the
> guest for good, I could not unfreeze it afterward.
> VCPU goes to 100% according to XenOrchestra
> xl list shows state "r" but xl console blocks forever
> xl shutdown would block for some time and then print:
> Shutting down domain 721
> ?ibxl: error: libxl_domain.c:848:pvcontrol_cb: guest didn't acknowledge
> control request: -9
> shutdown failed (rc=3D-9)
>=20
> Do you think it's related to your current issue?

Maybe? Is it a HVM guest or PV?

Regarding s2idle, we have another patch:
https://github.com/QubesOS/qubes-linux-kernel/blob/main/xen-events-Add-wake=
up-support-to-xen-pirq.patch
but it fixes wakeup, not really going to sleep.

It was posted also to this ML, but still waiting for review (see link
in the patch header).

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjUR3sACgkQ24/THMrX
1yyGCgf/UlGeDdaLKbch3r2mmzvaetImPwjEuU3+tgIuYdDF7dnCKnpr6CQqcCQl
qR/lt+cSDqxQSMEF3Vk37VzegMpJtekF/5ZPQ3dQn0soAPdAUuoTFf02pokCM45G
Ta5GiK45X2CpAnnGSGLng9G5H/k5MXbWrMfiy4bv65M5RtvlMNcq20mrFe61wuEl
mWydYzIZQUva74K+T/fUWqv4JOAgAyOC3Cs6ygT5bqUheivGFvI8bpOtgI9Pvnq4
Elt2kkmWCi/3/NGcHv51pq7RxZWajnyK2lznS3+JJUkWuqt0aRGW5jLt8TuvQpZ0
TtEJPsKWp5b5mnBIeBRbVwiTvxPr2g==
=meio
-----END PGP SIGNATURE-----

--iQNCPjvv7VHlfBcR--


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 20:36:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 20:36:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129704.1469532 (Exim 4.92)
	(envelope-from )
	id 1v1WDM-0007q3-3U; Wed, 24 Sep 2025 20:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129704.1469532; Wed, 24 Sep 2025 20:35: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 1v1WDM-0007pw-0o; Wed, 24 Sep 2025 20:35:48 +0000
Received: by outflank-mailman (input) for mailman id 1129704;
 Wed, 24 Sep 2025 20:35: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 1v1WDK-0007pm-Br
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 20:35: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 0aee235d-9986-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 22:35:43 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by AS4PR03MB8205.eurprd03.prod.outlook.com (2603:10a6:20b:4f8::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Wed, 24 Sep
 2025 20:35:40 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.008; Wed, 24 Sep 2025
 20:35: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: 0aee235d-9986-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XpgIu36CfE41baqJK7QWmOs9J5+os3jDk+Bwm83O2f2WVQdHBUihMyn/7Ne/bM6+mPcWnB8w6yc/1jUz/RC1ahOrK11p9ARrPDMc9QlJOvrq6D4vG1JxGgjNbnCOshTdzFbU5wsYWjPpvCrze/oZkBiy/vHfzeq9RG0YF19PqNmU6p6sqTuhuDCer/+m1xRG5ckeKCXsERRtxY3ST1s6nlErxkezhW/67gy6NpfG5Ag7bM4/Dq+V2M9314Wz/t7omb7ezQ2nLgXzwhvB0AsNK3d6Iln9NcfiQdB3f6lnZ3yOKN7tiHdYAxj4DGboNFAWEAUBzhT61VlPVgZmbVWesg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sB0+C1pxh8R+Ds/c0r1Xd+nU31NJsXRp6/WwQyk7idg=;
 b=Aus6GIuejqWCT1gEhNkSPCsbia1/Jhh29dfnqGzKLYkBZuJ/5+MLuP2BTZM7V+rIUWBW+ulwdxT/3gNA3Ar2oLBl75FZdLAXyVblzkkPIGH+57ZHcmnpeY5XlqteGpkn0K0l74a5iUSTQGE2BvA32+uHDEGniIvB43Ts50iWjzkLMvSIEp5dFsxzomyTBQ3GIRyl8wazmroL3QW2dnRbNrzOvG/EJNd++K7uOqGwO/PfPDsLagoOgX8JRYukym2Awq1fXngbfo/ATCxaCo02jmISYc5yjU0q05L2Vln+ScPxkM6aV9gLtODAteXPSfiA5PmgNnOz7uIk/YY2o4BMbg==
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=sB0+C1pxh8R+Ds/c0r1Xd+nU31NJsXRp6/WwQyk7idg=;
 b=c84SM+dRJio53FnMSbqAw3T7PZnYr+SwZ4Kv5tQA+iIty7mfRAsX5ZAPi9jPrOuOQ9yGd4HHjlC3vrIzDFqXV2DVfiy/uoUleAToofdV520nwSZgJIU5jini97c2e5WQa82XEVks61yAcVi5DLRKBQd80B+WYTuxSocuwJ23IXW0HkPtxMXg8OQUMLZOzZYO9jy1K2hlI6ZbwpFjr+kF/XUb6e7w1igTxArtxZ9oMHMAZCzHT+uDLbEVFkmvLObxtIOQlpDBCOZY4Y0ndJ5E9yv8D5itnYTz0U8GOgAS17ofcUgchK8ksOeBa3X2ulWEAYr/+ZwT4vy0bL+N+JQ3zw==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v3] arm: address violations of MISRA C Rule 2.1
Thread-Topic: [PATCH v3] arm: address violations of MISRA C Rule 2.1
Thread-Index: AQHcLZLK+ABBtomrNE+mTHydZzSxzQ==
Date: Wed, 24 Sep 2025 20:35:40 +0000
Message-ID:
 <620eb8fe22204e204cb471e93d2ea789f879d854.1758744144.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: GV2PR03MB9572:EE_|AS4PR03MB8205:EE_
x-ms-office365-filtering-correlation-id: 77500320-1a9c-4d72-6e4d-08ddfba9ed1c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|42112799006|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?bkL2t7gx/GmcDeVKIjNhExMenKNlEGoE+mXqxNXcQZ33kzxWB2XI9+NRGL?=
 =?iso-8859-1?Q?6YyEFSwQ0HzbqCwpg/j3CqdTXG8rUrWzqqYz/hxiFPY1Aalq7M/5+Upj55?=
 =?iso-8859-1?Q?bkHRdzTsoNjCsrGw4IVQiQnx/TVkYming5OdszGSdUneeMhr+7oT78soPU?=
 =?iso-8859-1?Q?9eJ5V+MdixFABeSuTRxBU6hJUk6m0oPVDl7TDX6Ip1p/xWyWmVNfJqPS3B?=
 =?iso-8859-1?Q?5v1DGb/J86SiMSdH0XMpLjLw8zogtQ26mMiWYJCELQezcWTN+lKJvHjtgd?=
 =?iso-8859-1?Q?wb5Q669j/Z7+iiyNX3rna9kapPMQ3gz43trhbPy1Np7Eq/V7EMEXifFlhg?=
 =?iso-8859-1?Q?z+KokJqwE8hgGTDCUMLr0/dJa7Mu0T2akafXaij10QQbcT/Ih2ymF1xBsO?=
 =?iso-8859-1?Q?9XVBzrwa0tnfgTZd2RlS1QA9OdVHhxqIA2JnrYSKtRBotJ9UQfSbwRafGc?=
 =?iso-8859-1?Q?6LSJ2Ztvpwc/aRHuhFx/ym3dcnOcSs+/BMZEIAAzUStyMLbTysQnILw/u4?=
 =?iso-8859-1?Q?4DNPfp0vj1eCiC9bPhTqUdCBYOvycvVKEEVlnXJn5FSZGWOCb7E9uGWfHL?=
 =?iso-8859-1?Q?ftr8L5jXSi47qj64q12qlfZQAPWOTHrwG5wXDcmaqxX9g+E6DCI75/wmr3?=
 =?iso-8859-1?Q?sAEcLpUpMHjvnpVR7NWOiCchRjgnfUpAUjgEBklKFXn7R/v6IJxHlkuRo9?=
 =?iso-8859-1?Q?FA9B2Jey+hYds48t79yAlPTQUliCh6sFbHLyiGNW2CouGoMdqXkvUMetdJ?=
 =?iso-8859-1?Q?8v1XgAlp8B8k4IKysicvOxpKhNRnwMCTAmIZuUxBuHEm+cQwUitL13wQD5?=
 =?iso-8859-1?Q?CDQPjjAOa0Hj3022orGgbnc3M6YhnniCQzhFCnclEWeZYztygEwHeJgexP?=
 =?iso-8859-1?Q?zE9bBUDArrhAgf14JI9q794zGy3tN6t6cvE94iYSfYWaApv2x7UEiJ4FDY?=
 =?iso-8859-1?Q?GZ89ib4YeWqrkmS3FH5ZuFzXBJDBY1L9INaKVmFqbGSdEl54qDzzWAVgXe?=
 =?iso-8859-1?Q?ZIfZJ/p+QPUzk/ejR+c5+EtKW1WPuLTRFnGBZnQsEKpUQvSXGmT9riivSX?=
 =?iso-8859-1?Q?5oBT+Rndg2tkMzbvwrlh4sedBHagR/pfjFbDOKR818XcqxLS4+irSAh2sB?=
 =?iso-8859-1?Q?Cp5PaaYUF80UkvAG6QxAKFQg2T5622LUh3XpmW08rfAz24TH6ha6N38ZH9?=
 =?iso-8859-1?Q?JBmmOJxCUH1sjGLfkl+iGn0TuaHAFA2XSGkpfHp3YVjFZx2rz2tyJcEXjI?=
 =?iso-8859-1?Q?TclZxFLbXOtcMMDpqF1UtZa80i3dZsPDHsy+ZYl/47imPAnRlfQC5T4VXu?=
 =?iso-8859-1?Q?BRGtagEIXe7I5EVh4S2a3RgOIeqARZGvGHDMqJv2na80rCzJtmBuIYke/T?=
 =?iso-8859-1?Q?LWSqY0H9rOAsZizvoU1kE8x8STwQql4IeBqVRAwosiovfRX7pESezhHpoo?=
 =?iso-8859-1?Q?KHcnKwVNpAb4vMRNm2svpHbAsBN0O92AXoZruINOVBp3IKx6bRw6AoBemp?=
 =?iso-8859-1?Q?M=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(42112799006)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?eygDxR09523dJHRCHvLQkYrx25gAL7dSUub+frvpBONvgIkuF/DIRVfg87?=
 =?iso-8859-1?Q?Sh483XI7g0JgTgQ+dfbTOQ5DdrevQJY8beoXqeOPf3O5fGYuW4FAcMyjOV?=
 =?iso-8859-1?Q?owgNlZVV9xvC6cWYyzLZhkKGQGH1Uc+26KMZfMMqksrFK7wHn7OcZvC5iQ?=
 =?iso-8859-1?Q?e0v2nlr9Dh/bPg79tXMVBXWdEJXuScIwe7u23sUFHimHhyMOxtvlhKMGUU?=
 =?iso-8859-1?Q?pI/4YVWEDpe6YSWE20EQ0Ma/lG5Ft0DPWBfvXQY1AfKxbDGdsERbzVm7bB?=
 =?iso-8859-1?Q?C/qxeRwB6rwFCOwbB6J/lTwQpB3Q+pkz2Xh2JSZ17lM03bs/SPDTtOcsd2?=
 =?iso-8859-1?Q?rmgLZrWRhWJHKF2w39zqpj2az89VJeC/z4AfWfevjVzed/wN+SPoq7XFzJ?=
 =?iso-8859-1?Q?np+YvzgGhrBKw+XFMEmntuOrF70K/SEaixd9aUgBevZt7CzAKZ0w3xjRxR?=
 =?iso-8859-1?Q?oASo3zezbkOycnK1GbdVyefY6ObsHzZ1RuR9hMalmUT6EtdSJe8T0bGdOA?=
 =?iso-8859-1?Q?quZlJd+wE807GYOsKapfQQCQboXSTZIEG28RNTWkvLRxzeoc6zwr9oiFId?=
 =?iso-8859-1?Q?ByIBu92lfqx+WH+MVUG4Cw/4I766drssNzUwBv86LLirJcx3/xr2uwdYQl?=
 =?iso-8859-1?Q?Oo2cs5hqDkXe34vf5EfsAkfEiC0Do8gctmsbBwWiWQetI7kTsldzYQCJFK?=
 =?iso-8859-1?Q?Zeub6wfdPQJEUlZqEQmAe9UooConOPsN15x4SrWLczyHTPn8ImY5tT9sy1?=
 =?iso-8859-1?Q?7VGRAPWX3+tIIpxiGZ6xjcjgdqKZqZCxMkl/1pmisJakO8hPmZDZEWxxI6?=
 =?iso-8859-1?Q?s2FJUBAu5xej8uWlllVQ0Ok5R1qUQ0pyzAIbjAJFCq6NI167Bq7UMp4zSa?=
 =?iso-8859-1?Q?WTk81zPTIJydANe3LfFMet+Yn57SB38bIPWbhbw54F6rVwsIkRrG9kPE52?=
 =?iso-8859-1?Q?765Dmd8WdwnUNwTWMuxsO5GquH5mmoF0MCmwM+/0Elsgwl/HRljnjWqAJ6?=
 =?iso-8859-1?Q?KG3VwLEcjQSyNM7fPq7voMtLhKiWHWZNZN93yZ+HIECC97zmMh3cEbgFap?=
 =?iso-8859-1?Q?pm6cSxNw6f0knIxB2gCH+7voB99RNrqNw575AhuKPN/Jn6GL8q4iOZZxxv?=
 =?iso-8859-1?Q?99GiBY4IZduEboyHukzk5KVn+OmUNIgTs8NARgauZbhEwUats9+Vcz1uKu?=
 =?iso-8859-1?Q?Z5Y+cccYsjg3j2xzO7bEO9LriiH6e5YYNqWrebdGm0Pn2AUrsCiDTjKS8b?=
 =?iso-8859-1?Q?tCaJxfwuPHe+m0fAnFs/WhDEUguNp6ebyz9sqAL0OxZmiOIdhtBk/3HPhb?=
 =?iso-8859-1?Q?IImnAT+X6wDTEFocs973Yfny0y7bHAqXoubvdIKOBeowOe1Tyw+QJmQpMw?=
 =?iso-8859-1?Q?qJ0UlAeIDw3hhunvalqDzDOb6gQIkXBxvdLXCcXw5EWbvvxecNm0oFRo1f?=
 =?iso-8859-1?Q?mrSlqp2MWTzcm/Oqn5ZbBQyb1vz+q+Nt73GEHvjxDG64mAceRhb3pdoybz?=
 =?iso-8859-1?Q?w8K3ctG9Sm/adjVE2JVYcEVRHQB2iPmo44klO7cf418trW55ovaKU4+VKP?=
 =?iso-8859-1?Q?8g1cw3FJvIHmUgtRegcIMzc11PCPw3qpGwAscdpcn0XivHEJnfn/DLrGN4?=
 =?iso-8859-1?Q?JtSSousc6VN+srPm7+SxZZ1ju/khjJV9BUVadewbgz1lnrl3nXmsTYdg?=
 =?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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 77500320-1a9c-4d72-6e4d-08ddfba9ed1c
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2025 20:35:40.2466
 (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: Td12YReJS+9zHrzQaLb934Tz7pqI1kMqMfc537v3MGHOoZ0H15brs9bYhVtvQgQ4yK3kKE/FWQKglGusrKn4lPfuDh8zWaspMxhQqBXxhaE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8205

MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
In certain  build configurations the following functions 'prepare_acpi()'
and 'gicv3_its_setup_collection()' are defined as inline functions and
contain the macro 'BUG()'. This resulted in violations due to these
functions became non-returning.

To ensure compliance with MISRA C Rule 2.1 remove inline function
implementations and their 'BUG()'-based unreachable code. Provide
unconditional function declarations for 'gicv3_its_setup_collection()'
and 'prepare_acpi()'. Rely on the compiler's DCE to remove unused function
calls in builds where these configs 'CONFIG_ACPI' or 'CONFIG_HAS_ITS' are
not enabled.

Signed-off-by: Dmytro Prokopchuk 
---
Link to v2:
https://patchew.org/Xen/0adc0a8f75cb88b0b26d38289d1dd5823386290d.1758024454=
.git.dmytro._5Fprokopchuk1@epam.com/

Changes in v3:
- updated commit subject and message
- removed inline functions with unreachable code
- provided unconditional function declarations

Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2060806048
---
 xen/arch/arm/include/asm/domain_build.h |  9 ---------
 xen/arch/arm/include/asm/gic_v3_its.h   | 11 ++---------
 2 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include=
/asm/domain_build.h
index c6fec3168c..6674dac5e2 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -15,16 +15,7 @@ void evtchn_allocate(struct domain *d);
 void set_interrupt(gic_interrupt_t interrupt, unsigned int irq,
                    unsigned int cpumask, unsigned int level);
=20
-#ifndef CONFIG_ACPI
-static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo=
)
-{
-    /* Only booting with ACPI will hit here */
-    BUG();
-    return -EINVAL;
-}
-#else
 int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
-#endif
=20
 int add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data);
=20
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/a=
sm/gic_v3_its.h
index 0737e67aa6..fc5a84892c 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -131,6 +131,8 @@ struct host_its {
     unsigned int flags;
 };
=20
+/* Map a collection for this host CPU to each host ITS. */
+int gicv3_its_setup_collection(unsigned int cpu);
=20
 #ifdef CONFIG_HAS_ITS
=20
@@ -160,9 +162,6 @@ int gicv3_its_init(void);
 void gicv3_set_redist_address(paddr_t address, unsigned int redist_id);
 uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta);
=20
-/* Map a collection for this host CPU to each host ITS. */
-int gicv3_its_setup_collection(unsigned int cpu);
-
 /* Initialize and destroy the per-domain parts of the virtual ITS support.=
 */
 int vgic_v3_its_init_domain(struct domain *d);
 void vgic_v3_its_free_domain(struct domain *d);
@@ -256,12 +255,6 @@ static inline void gicv3_set_redist_address(paddr_t ad=
dress,
 {
 }
=20
-static inline int gicv3_its_setup_collection(unsigned int cpu)
-{
-    /* We should never get here without an ITS. */
-    BUG();
-}
-
 static inline int vgic_v3_its_init_domain(struct domain *d)
 {
     return 0;
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Wed Sep 24 21:22:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Sep 2025 21:22:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129727.1469544 (Exim 4.92)
	(envelope-from )
	id 1v1Ww0-0005Wk-ET; Wed, 24 Sep 2025 21:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129727.1469544; Wed, 24 Sep 2025 21:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1Ww0-0005Wd-9U; Wed, 24 Sep 2025 21:21:56 +0000
Received: by outflank-mailman (input) for mailman id 1129727;
 Wed, 24 Sep 2025 21:21:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1Wvy-0005WS-QL
 for xen-devel@lists.xenproject.org; Wed, 24 Sep 2025 21:21:54 +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 7ba1fbad-998c-11f0-9809-7dc792cee155;
 Wed, 24 Sep 2025 23:21: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 CBBAE44761;
 Wed, 24 Sep 2025 21:21:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 892F6C4CEF8;
 Wed, 24 Sep 2025 21:21: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: 7ba1fbad-998c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758748908;
	bh=M5aVdWR5CNz8WiT95YERrCl2nb5p78koFdCQP8Bz/YI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aGq8FLsDCaN2/NWnddqfblnsnuscWMlZ9Qvbq714+U3IHYOiDWFdpts7IjbSx9zlb
	 5ZdqjRke0SN+ZE82BOXcs62AZ0x6FycYjdqPuxy/4CyorWFQ4Ej+TCwkZH+fAfSV+i
	 yarOG8DT5ZXfFU5CtfH84u3+4GmuxBYvh3eoqo8tCOIPG+bjm/sMPBusu9cWBBOl/J
	 BIXIld/GF5hi9lNgfL1kbSnWull39CiqYFIIQt5mErGidMwT1Dyp8DSHHETF1PH/Rf
	 sIE+UMdZ9maI6Rr9QAiuJxS2Ccn8KmHEzdT3R6ELztJ72oBQXP2DVmGjch4sYQEZYL
	 zGDR80Taq2QWg==
Date: Wed, 24 Sep 2025 14:21:46 -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 , 
    Anthony PERARD , 
    Stefano Stabellini , 
    Jan Beulich 
Subject: Re: [PATCH] CI: Switch the alpine containers to be non-root
In-Reply-To: <2c91d873-7f13-4f78-a0d8-8f67f06c88b2@citrix.com>
Message-ID: 
References: <20250910113416.1835988-1-andrew.cooper3@citrix.com>  <2c91d873-7f13-4f78-a0d8-8f67f06c88b2@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-525722612-1758748908=:2244509"

  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-525722612-1758748908=:2244509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 10 Sep 2025, Andrew Cooper wrote:
> On 10/09/2025 12:57 pm, Marek Marczykowski-Górecki wrote:
> > On Wed, Sep 10, 2025 at 12:34:16PM +0100, Andrew Cooper wrote:
> >> Testing on staging-4.19 is hitting a reliable failure, caused by alpine/3.18
> >> being a root build container, but debian/12-x86_64 being a non-root test
> >> container.  Specifically, the test container can't copy XEN_PAGING_DIR and
> >> XEN_DUMP_DIR (both 700) from the build root in order to construct the initrd.
> >>
> >> staging-4.20 and later do not repack the initrd in this way, so are not
> >> affected.
> >>
> >> Switch both alpine containers to being non-root.  This is still slightly
> >> fragile, but better than depending on using root containers for both.
> > This will likely explode done as is...
> >
> > First, grub.cfg is not writable anymore:
> > https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11305545275#L170
> >
> > I'm not sure what 'user' gets remapped to here, but the whole container
> > is running under rootless podman, as gitlab-runner user. Files on the
> > host are owned by gitlab-runner user.
> >
> > But second, repacking initrd as non-root, without any extra care will
> > result in broken initrd. At the very least /sbin/mount is suid root -
> > when repacked as normal user, it will end up as suid to non-root,
> > breaking it quite effectively. I've run into this issue when needing to
> > repack rootfs anyway and ended up using fakeroot (again):
> > https://gitlab.com/xen-project/people/marmarek/xen/-/commit/bab939159127a9f8e56e119c1fa553c7bbb6d4f7
> >
> > At least your "CI: Create initrd fragments explicitly as root" patch may
> > need backporting, but TBH I'm not sure if that's enough. /dev will
> > likely be messed up too.
> 
> There's a lot of collateral damage here.  Summarising things a little.
> 
> * We cannot change the root-ness of alpine/3.18-arm64v8.  Like
> xilinx-xenial, it does need root to drive real hardware

Apologies for joining this thread late. I wanted to add that it is
OK to separate containers intended to drive real hardware, such
as xenial-xilinx, from regular build containers. For example,
3.18-arm64v8 could be moved out and used only in .adl-x86-64,
similar to how xenial-xilinx is used only in .xilinx-arm64.
Normal build jobs, such as alpine-3.18-gcc-arm64, could use a
different container.

I suggest we rename 3.18-arm64v8 to something else and create a new
3.18-arm64v8 specifically for builds, to be used only in build jobs.

The renamed original 3.18-arm64v8, together with xenial-xilinx, could be
moved under test-artifacts/ or another appropriate location, as they do
not quite belong with the other build containers. This separation also
aligns with the root/non-root distinction.

--8323329-525722612-1758748908=:2244509--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 05:44:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 05:44:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129833.1469553 (Exim 4.92)
	(envelope-from )
	id 1v1emC-000280-IR; Thu, 25 Sep 2025 05:44:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129833.1469553; Thu, 25 Sep 2025 05: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 1v1emC-00027q-DU; Thu, 25 Sep 2025 05:44:20 +0000
Received: by outflank-mailman (input) for mailman id 1129833;
 Thu, 25 Sep 2025 05: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 1v1emB-00027k-6I
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 05:44:19 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aab2eb65-99d2-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 07:44:13 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-62fa99bcfcdso1107538a12.0
 for ; Wed, 24 Sep 2025 22:44: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
 4fb4d7f45d1cf-634a365093asm612580a12.18.2025.09.24.22.44.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 22: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: aab2eb65-99d2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758779053; x=1759383853; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rLBQ1A9VcSHpoybROb7rfRVVoXLeQZXYgMx9RyaCD+E=;
        b=UoxaBtbfYGw7mrphKmAYpTM/q8IMZKN44xKKa+XifIOKIG39KfUkx+4Y0fJUZQmKkU
         5Sfa9o9qUPpa0ayxtVOWcvOImkv4OxzLV0Bewz2OhnhA9B16OkfVE7KXzqcCJWnsOQiv
         /La+ir8AOX9ek4UqxCaq3Q9Fi75tMUl8fY2SlFcZ0FuQZlgwpoaZM0g119oJ4GqfS9l8
         EJwbib4oi/G4Vvyw9Ge+d3g+t8TShtHKSzbDLAyojPVvnOvQfbINtQxjKmfGIJ0zLlrm
         LPpia7YTHVfRbPMcSzrecg9bW9WGFW90Ox28NdfPYsiVXXhdzSPr/0lTfmk0Dp2fx3Cb
         UDbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758779053; x=1759383853;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rLBQ1A9VcSHpoybROb7rfRVVoXLeQZXYgMx9RyaCD+E=;
        b=O9zUEAFJ223SWmm8d8fKbM18ANIV2IATWfZkXM5yY6fJVbccx3J2B7AsZkHi+ly6MU
         ywm0jviJ3DaifZSIaUKnXJ/VePzrwoMOv5iZQmS7DovZX0khDVF7aoQwpUOjC5Yy/3xA
         AVPE2OJwlETGgL69bIdfrpCcDr8h9BwE6Dm37BWom9+X4EPY6Z5Ya/Hh/WA2o8bQZg5u
         weEJXU3trE6mmwR3DC2Z9umgU6ZEH9BGMVojp3xXH04Hw/Nyan5KRgaJLuxkB5wA6maf
         X76cCDEjQEaz3y3dlMermWtS+eahUS9QM9Ap2TYKzVemYPnhCz/Rmw8QzD9cQ0soACe9
         cz3Q==
X-Forwarded-Encrypted: i=1; AJvYcCXJeuncBDlrd7IcDuqruK+npn3lRiAl7S40ZD0gcgnyfopPM7sm7f8zvfd3jrmzLxDq3fUHFA+KMRo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxY1FVgjQXkK/caOiwVGFFwXK6rQeSgB/ej4rvfNB7Ol1NGQ/pa
	vSZwOtbuN9b+WEliRSeV8UYCaks4rDsxSOxwZchVToPPfgxMRS/ps24c66Qzm1SjAA==
X-Gm-Gg: ASbGncvVLV/8vJ3M6sJSf1BREuEixJt7p1CTIpP/jRs24Eyvpfll3RYHAAAcBaXQdNY
	prBrEvPIVfOSRLpuKrIdw+VhJ2N/zyoqoow1bTAXtUoPnl55VSCulJpgmTf0qqCqqibBwPbxXhM
	eZireAOborHdSMKagqy3m/ScsCWJ4lzU9+tFxGBQOXPCzSR7wUcatrddnIG91bVhkkg4vVwpYJS
	yf6SkU6OL9xTxjhESxHBkQ0PxRd03w30eOX8w6MWyZPWM3qWPPdvtzptBWhx1dXoOg1qaJuPt4Z
	SzIem4iMVtuCkPkI/aiWBY2EmaiM6n981rGCd83YOGsmnN4YkkEiMh80o/NhcTQP7spQujT8wtc
	fsh0EUBe9Hg+e5JTbdl6C5r39fr2HIvrXO0Al0khdj9mtsRBX9VA4umU6uRFMtGnfHQBFNOyAqr
	ZiBWppuks=
X-Google-Smtp-Source: AGHT+IGMajGtJ8WmWHv5rRGl5i4ZwfS9F4shxXK6bZ43ApJ8oPxcMhaBsSqfxmiq7K9nzIbgd9asHw==
X-Received: by 2002:a05:6402:2383:b0:634:5791:605f with SMTP id 4fb4d7f45d1cf-6349f9d26a5mr1449144a12.4.1758779053009;
        Wed, 24 Sep 2025 22:44:13 -0700 (PDT)
Message-ID: <3e0e8291-e1c5-459f-b13f-c0aaa8b7778d@suse.com>
Date: Thu, 25 Sep 2025 07:44:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/4] arm/sysctl: Implement cpu hotplug ops
To: Julien Grall 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
References: 
 <34c9b488ad949cbcd93bd8578dd5bc180fab8738.1758197507.git.mykyta_poturai@epam.com>
 
 
 <7a12dbe0-c3dd-4e26-b52d-610e065236da@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: <7a12dbe0-c3dd-4e26-b52d-610e065236da@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 20:41, Julien Grall wrote:
> On 18/09/2025 15:51, Jan Beulich wrote:
>> On 18.09.2025 15:35, Julien Grall wrote:
>>> On 18/09/2025 13:16, Mykyta Poturai wrote:
>>>> +static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
>>>> +{
>>>> +    bool up;
>>>> +
>>>> +    switch (hotplug->op) {
>>>> +        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
>>>> +            if ( hotplug->cpu == 0 )
>>>
>>> I can't find a similar check on x86. Do you have any pointer?
>>
>> When CPU 0 cannot be brought down (see cpu_down()), tryin to bring it up
>> is kind of pointless, and hence can perhaps be short circuited like this?
> 
> Thanks for the clarification, I missed the check in cpu_down(). That 
> said, I don't see any value to short circuit it. In fact, I see this as 
> more a risk because if we ever decide to allow CPU 0 to be offlined, 
> then it would be more difficult to find places where we short circuit it.
> 
> So I would rather prefer if we remove the checks.

In fact I agree (and I merely wanted to point out the present situation):
CPU0 not (normally) being possible to be brought down is, I think, pretty
much an x86 thing. I.e. I think the check would want to go away from
common code.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 05:45:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 05:45:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129845.1469562 (Exim 4.92)
	(envelope-from )
	id 1v1enh-0002cx-QP; Thu, 25 Sep 2025 05:45:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129845.1469562; Thu, 25 Sep 2025 05:45: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 1v1enh-0002cq-Nh; Thu, 25 Sep 2025 05:45:53 +0000
Received: by outflank-mailman (input) for mailman id 1129845;
 Thu, 25 Sep 2025 05:45: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 1v1enh-0002ck-1h
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 05:45:53 +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 e4b7f769-99d2-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 07:45:50 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-62fca01f0d9so1020081a12.3
 for ; Wed, 24 Sep 2025 22:45: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
 a640c23a62f3a-b353e5cf32asm94454566b.1.2025.09.24.22.45.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 22:45: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: e4b7f769-99d2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758779150; x=1759383950; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DErEVvkViAAR6Hn2FQ1S1eWGQGRWMMcsknoFlSU0QH8=;
        b=eWFNTsTrF28DwFYOlqDp4EtUH5X3OyKDDslabJOjHAlR7Ypnp2/ZW9o2p2dIMOJ9ql
         4az/VqsbV4zon+++wYWttKGL87M+P9odoy4znYUiuwQoCeL1hSMKrSt2oj6uFUafcafZ
         D+gTx1756loAhcBssuexV6nqcM+/2sgPBkvO4eXkIBJQDsCIXgk6zZ+waUuv+NLUPsJ0
         E9YQcrFbFjWMFhIFhJKBKOgoz/jq4Zd+JozWFCIH1MVAMG805KSw+m8CUJcexoYacXC0
         Uc6JH1bLa6aEXBRVgrNfNJBb/sgvktoh9/LaeqBS6e+me04wkcJf+u9UUVXZsXznH6zy
         V9xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758779150; x=1759383950;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DErEVvkViAAR6Hn2FQ1S1eWGQGRWMMcsknoFlSU0QH8=;
        b=JYR6hHdylqNvrx/jghBsHn0+SC378oQfpnRhZWJu+iHTu2LcCOvWCZ9ugwAQNnzozv
         6Gt77guZysnM2rUEonIpHi54PLw67mPucqE3Ynaa0wXc1lZuhOiOb3YLpa1LiEv1hOSL
         3PCs6QJfuoeDSmzRnTzt/PBebRkOGi29i4WmCEUSBS3158DIR0+TKjmNzdPY+gQFE5wL
         4QGkKUy7Xsn9u9+p8/hAnVI9+O8GKI5TDrki0B51+UWnv5isll3wJiZUBldCnRHT5dpN
         DtBScNEaPF09/NRgko+qDrIKfKSsRChDN7SyXM6X9/GhU9z2W2gt3Uxmogs8rjJeVsfm
         DXeA==
X-Forwarded-Encrypted: i=1; AJvYcCXik9xMmw1CtbMetGnuYBNNiPO5btWESa31UYf3VXTPdByyLmaaR+Oj+phra0iMx4UOSyhl7fDGmB8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUNymoBQ2cgqbqiqAHFeJBSocDvSuu4lq6PDiSYZYQNdWb0jF0
	PmtKbRXUAi+USDcclCtoJhhmxXiw8L2z6tPAAGwnKO5xcd5t8ihDmAJhSi8tenYWjw==
X-Gm-Gg: ASbGncuZKI4Ve4+vZNTG7KYSVDGd/dwZc6OzpZy03MtTZiewRMxqfRRXwpnhVyP3U1s
	q5A4C8TE4k/eKWw2Yc3Yn1CS1AqJkvDEZufSQmNFbp7a3nx85IesCXf+/DpYHmY3ymqpUFwoqqF
	L7hFZi9ydY7NgpkQiVnQoUYewDLVu9fbzCeTdVp85UcIhOIaKo9EmRT9+nG8iQq035QsA6fFgST
	+Svr/C2XjEdvgPowtlrxF7skJFiuCnJAuSO9D8i1qnnZIQegKXBZTt9MBpyFMBy+3l/bWohovQX
	qW7zq8E8QNKMxaUqiNzTWdxKKrZOZBarRv4LYU6rlw+NXPk8+CiOs7r+1F4nyJTmS0SK1cOZZMR
	8icrpZr5LyRv35zpgBqb+fIheEagGB5qw6U6SYw7JU3yAgyWzm/UhKX/xYKgyPVWVhJ4pYYcAFg
	gmVpfKYPGs017uRaYiPQ==
X-Google-Smtp-Source: AGHT+IHDhBw+ESO9/uyJPQJ5SMlbtdNu2wLC4wRvQeNXoGxU+YkWpQPU50ZIsmTRPCbH9/FHdi5ARA==
X-Received: by 2002:a17:907:6093:b0:b04:6a58:560b with SMTP id a640c23a62f3a-b34ba93ce11mr240848266b.39.1758779150380;
        Wed, 24 Sep 2025 22:45:50 -0700 (PDT)
Message-ID: <67342536-40d0-4473-b796-42fd556d5553@suse.com>
Date: Thu, 25 Sep 2025 07:45:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
To: "Penny, Zheng" ,
 Tamas K Lengyel 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24.09.2025 08:39, Penny, Zheng wrote:
> [Public]
> 
> Hi,
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Sunday, September 14, 2025 10:04 PM
>> To: Tamas K Lengyel ; Penny, Zheng
>> 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Alexandru Isaila ; Petre Pircalabu
>> ; Daniel P. Smith ;
>> xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT
>>
>> On 14.09.2025 01:31, Tamas K Lengyel wrote:
>>>>> @@ -99,10 +98,40 @@ long p2m_set_mem_access_multi(struct domain *d,
>>>>> int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t
>> *access,
>>>>>                         unsigned int altp2m_idx);
>>>>>
>>>>> -#ifdef CONFIG_VM_EVENT
>>>>>  int mem_access_memop(unsigned long cmd,
>>>>>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t)
>>>>> arg);  #else
>>>>> +static inline bool xenmem_access_to_p2m_access(const struct p2m_domain
>> *p2m,
>>>>> +                                               xenmem_access_t xaccess,
>>>>> +                                               p2m_access_t
>>>>> +*paccess) {
>>>>> +    return false;
>>>>> +}
>>>>
>>>> So this is needed when VM_EVENT=n and ALTP2M=y. Tamas, is this a
>>>> configuration which makes sense?
>>>
>>> Yes, altp2m should be functional without vm_event being enabled. There
>>> could very well be in-guest only use of altp2m via #VE. This function
>>> is used in p2m_init_next_altp2m which means it being stubbed out like
>>> this when vm_event is disabled breaks altp2m.
>>
>> Oh, indeed - the stub still needs to handle XENMEM_access_default. Of course
>> with MEM_ACCESS=n it's not quite clear to me what p2m->default_access ought
>> to be; imo in principle that field ought to also go away in that case (becoming hard-
>> coded p2m_access_rwx). While doing that will be a larger patch, perhaps using the
>> hard-coded value here should be done right away.
>>
>> Once the code correctly handles MEM_ACCESS=n as an implication from
>> VM_EVENT=n, it's also questionable whether MEM_ACCESS_ALWAYS_ON
>> should be retained.
>>
> 
> If we intend to remove MEM_ACCESS_ALWAYS_ON, I suggest to do the following modification on VM_EVENT to still keep y on default on x86:
> ```
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 7bd8a04730..61d48a5120 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -170,13 +170,10 @@ config HAS_VMAP
>  config LIBFDT
>         bool
> 
> -config MEM_ACCESS_ALWAYS_ON
> -       bool
> -
>  config VM_EVENT
> -       def_bool MEM_ACCESS_ALWAYS_ON
> -       prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
> +       bool "Memory Access and VM events"
>         depends on HVM
> +       default X86
>         help
> 
>           Framework to configure memory access types for guests and receive
> ```

Yes (at least for the time being; eventually we may want to make this default N
even on x86).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 05:47:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 05:47:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129861.1469573 (Exim 4.92)
	(envelope-from )
	id 1v1epT-0003G8-9J; Thu, 25 Sep 2025 05:47:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129861.1469573; Thu, 25 Sep 2025 05: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 1v1epT-0003G1-6Y; Thu, 25 Sep 2025 05:47:43 +0000
Received: by outflank-mailman (input) for mailman id 1129861;
 Thu, 25 Sep 2025 05:47: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 1v1epS-0003Fv-74
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 05:47: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 2608c577-99d3-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 07:47:40 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b2bddecc51aso89269166b.2
 for ; Wed, 24 Sep 2025 22:47: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
 a640c23a62f3a-b353f395349sm91719566b.34.2025.09.24.22.47.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 22: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: 2608c577-99d3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758779260; x=1759384060; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NSf2Qme/BPp/C6Fp7xsplOCNMwXgPlzTGiH99lB+pt4=;
        b=RXHdGVeYiaj8H1zqg0mmBXjgR9T08+prCKKG1QyvXzeOCsgrNVcb1lsE9KvyH8tzpp
         Pe8zHR8f1pCh3aWVgv076wrsMbT0TuRiPLRW0F1FTdLjiky0sTQjW6Bxqhr7KwESkPIH
         5aheTqjA0tpKXVvMKSypSgy7KEoV/tCFaRqCrYq+iBIBx+rxZrmoChO4SzuZw9uZJdWO
         9lxMaRkFZPHDnMns/w4zi2ZMqT11nCiGyN0G/WiJGiEUiblhLkfkSaiQVHmFgrcUMcdM
         yW99Stp/T/ijk7W+qJZkBu221UXBeNo7j5TIcURYkl6k6OKjfE6lDgD3viR+lLKWu/VX
         wx2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758779260; x=1759384060;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NSf2Qme/BPp/C6Fp7xsplOCNMwXgPlzTGiH99lB+pt4=;
        b=KiE0CE5t/Z05GGEU871x9W6OHGEdyVsBwDr5Zr8Braf6NYAezOeUBf7r3Oove+cg4x
         qzwK5n5jfqQ4BtAspGMOpwCRdjB24Tk6K/RoRrPQogRAqn/OqEB6KHcuj3gVOwP2/n+c
         GS+PGysKpyIIM/QUGmx8EtKlmRG7VZvEXOKxjUZPcWgKr1szcw+7VZWnyWBhN5iW5yQi
         /XEYmsIrYZaN449MTLaVuC5iRgNhTjd0290WKbI7g0eTlpVzmTuotAjDcQThRObAj+I4
         ox2X1IY0Ft8yaijqFfUYKMxcfXYyXIDzSx4SvCTdBEaKjTJTsycS2nWdRXqPrEL+OMNZ
         pKKw==
X-Forwarded-Encrypted: i=1; AJvYcCW7O7ZAFTmG4bcdJWESLEzUaeY7bLFcEOWOIraKidhNYMpXGTNpSIt3NqM3+VJM6n4RCqQQjMGI+no=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyyYANI6ke+4kCIt1ZsVdFP1NG4yy2s1hVylKSiBqEqBHi3CWIj
	QTp/bfGuBHX9+8Lk30VO3qfjnD//yzAwXS/jnycptQ2Wlt+yTZqWwzxpBTSydRdPSA==
X-Gm-Gg: ASbGnctwKQ9kZAlXrxyIUMNWF0RS/3DoqPuGYmiRawmGjGmtzAfsRw5Wbl3LKCAV2uo
	UGOF+22B6lBTlOdmruDTbJnW6vmAdq0raYFsTecTaxVh2V58bkq7+2ZxuL60HOLPMuxUD7enBh0
	oYYS3S5nYvP3iGO4HjaPlNxy+lgYoK9d6oLVyhFohIFy2Z8vd2RqdvG0YUJIwfy7pvuuAQ/4nrl
	aVuvgXD+b1NC9cE27i/rO4o45VhBnHX39wQIV81voFAp/TlX3I+7fC4et4twr5RS8czC+s1k53c
	sJsAi0rSD7d/5QiW26xIjEczWmRuq6bZz6slbg3L7C9vQamNhmsX0qvg1dItLzJBZUW5tPH3qBD
	nANqyCscS+oVQ6Gg/ez6/N6+75e/GIrLb3e1AHL5Tv7jBJRiyNzay3OR7pD5o3DzoAfMBfGFl2+
	d0klVzQJs=
X-Google-Smtp-Source: AGHT+IFZFBUUxcYTwyNn336hiw+xCadb96hkZXkMh9ua2RWbdSe00luppmIpAFO/PiU+1BmcuIYPpg==
X-Received: by 2002:a17:906:6a08:b0:b2e:34f1:9ddc with SMTP id a640c23a62f3a-b34b80b16f1mr213035566b.15.1758779259956;
        Wed, 24 Sep 2025 22:47:39 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 07:47:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/26] xen/domctl: wrap
 domain_pause_by_systemcontroller() with MGMT_HYPERCALLS
To: "Penny, Zheng" ,
 Stefano Stabellini 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-8-Penny.Zheng@amd.com>
 <99737b48-2f14-4d49-85f8-5acd4a434dde@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.09.2025 09:11, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, September 10, 2025 11:09 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 v2 07/26] xen/domctl: wrap
>> domain_pause_by_systemcontroller() with MGMT_HYPERCALLS
>>
>> On 10.09.2025 09:38, Penny Zheng wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -1606,10 +1606,12 @@ static int
>> _domain_pause_by_systemcontroller(struct domain *d, bool sync)
>>>      return 0;
>>>  }
>>>
>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>  int domain_pause_by_systemcontroller(struct domain *d)  {
>>>      return _domain_pause_by_systemcontroller(d, true /* sync */);  }
>>> +#endif /* CONFIG_MGMT_HYPERCALLS */
>>>
>>>  int domain_pause_by_systemcontroller_nosync(struct domain *d)
>>>  {
>>
>> I would have ack-ed this if there was only this part, but ...
>>
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -390,11 +390,13 @@ long
>> do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>          break;
>>>      }
>>>
>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>      case XEN_DOMCTL_pausedomain:
>>>          ret = -EINVAL;
>>>          if ( d != current->domain )
>>>              ret = domain_pause_by_systemcontroller(d);
>>>          break;
>>> +#endif /* CONFIG_MGMT_HYPERCALLS */
>>>
>>>      case XEN_DOMCTL_unpausedomain:
>>>          ret = domain_unpause_by_systemcontroller(d);
>>
>> ... as expressed elsewhere I'm not happy about this one, as it'll need
>> undoing in a later patch of this same series.
>>
> 
> I shall admit that this kind of stub really helps me test MGMT_HYPERCALLS=n for this big serie commit by commit at the very beginning. Otherwise, it could be only disabled (and tested) in the end, and accumulate the mistakes...
> But, as you said, all this transient thing needs to be reversed in the last, and I could accidently missing something and leave dead code...
> As CONFIG_SYSCTL is already a prompt option, then maybe I need to raise a new commit to make it as def_bool again only for this patch serie transiently or just address it in " xen/sysctl: replace CONFIG_SYSCTL with CONFIG_MGMT_DOMCTL " ?

Removing the prompt again (whether in a separate patch or in the renaming one I
wouldn't care much) was what I suggested from the very beginning, but which also
is what faced Stefano's opposition.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 05:49:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 05:49:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129876.1469583 (Exim 4.92)
	(envelope-from )
	id 1v1erD-0003pW-KI; Thu, 25 Sep 2025 05:49:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129876.1469583; Thu, 25 Sep 2025 05: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 1v1erD-0003pP-GT; Thu, 25 Sep 2025 05:49:31 +0000
Received: by outflank-mailman (input) for mailman id 1129876;
 Thu, 25 Sep 2025 05:49: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 1v1erC-0003pJ-AL
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 05:49:30 +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 66cdf8eb-99d3-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 07:49:29 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b07d4d24d09so102867266b.2
 for ; Wed, 24 Sep 2025 22:49:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353f86f974sm93334266b.40.2025.09.24.22.49.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 22:49: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: 66cdf8eb-99d3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758779369; x=1759384169; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+PIBE5q8wFs8PC7X+SaNo9tntrkpVIkUvLafSlsmqgY=;
        b=cBcbcgBzPCAEp/r7YR1Zfjx4mDzfesYQwHfyOf3V//WUNiZ6wWit6zvwcv1EVrhKpI
         So96pE64DolYpKpTpnx2CjlDo3+FDiHh/9Mjaoob9DHCOCLbTP6wDiBoHRyOR1npmqpa
         jeWGiWXZ+pEx2GKiGIlFoY2tcYQUUIl4Lxtw9zYqFrfdF2vlo4fXKpJIBcuEP3NZKGwT
         Sr7xgSgbHOG4gAzRDx9y2QTYpCi+H4/71QYVBgLUXDwJ36rn4knQndYDycN8xlM9vh5U
         xeF4Mt29Z8L/gx5TRPJhQRC0XIOB5gzp3l24utWVsvcXUSjKEmbTL3lq/NFm3r6++XRE
         xP/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758779369; x=1759384169;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+PIBE5q8wFs8PC7X+SaNo9tntrkpVIkUvLafSlsmqgY=;
        b=XuPzUFZx6dPuHSGvcq7rpbH8gDg6/ahxM/o+ck64q3/7CkgT7C5K9l5jzjcxhMqPZ6
         8SNkMcrZaMt3W94A3OhPXjYHEfX4IEW2yjEQAlHgBIh7SvgLsiF3pMWydgn56PhEOzRH
         IyonFv9a4t+Tx+ubZewig23DYw5CL1kte3R3lmnzBgFnwfLQmohz4dBGHLRF2wrcxzWv
         Hy9ddrQ09t3g2iv5/k5HgGPwuDH9PrKk19FqS7b090Y6BvZhAkzipS4pgqVGMzAjBeiA
         qchPjTYlSBZBOfiEdZrdSnwHTNBNFjfyKHlENsNRrtyDB41s/Klar//c/+YdJbFnFf5h
         Jx0g==
X-Forwarded-Encrypted: i=1; AJvYcCWklinL/zlrd1KLh7UA80B6RX9w23MGgUjrwDcBxLBBwTmsJAkwfPU2nD9/rodO6Mw6h9J/N3Ok794=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywaj/NgIFYtNuUhppRjHpVGN+3fBGQHz8jAIsQwXnDadSdAGkkj
	maLFSNTX2lXFeYOoY9HSQ2ePUZe7o7u9uwJgGzNK6oGcWVg3HwOpIAFiop+p0DotNw==
X-Gm-Gg: ASbGncvmkp/7FJwCOphcjNDtbIQt2eVa9betFH/VaXt+qHYWDHcxOoeCZlOKAMG5whT
	iBUIQlWEvLerqvWm/ffswGN7HImZeuwSc5kObHpBokQyAHp5wag5RMMaBUUGaZxrOF2iceuJsN2
	Bjq1zF3xmP5K0QEc3UmxxT68Hi5331QPDog5OgI5RHO0FM4ZySv/nUC/TNz7cWNwGIc3jyyZE+G
	ugGAQhhcUAG3ev8TGfELdVAhEvxXOcouTpd51P+N2PGHNrtx8LYEsbncb78dnCaF5KajIgadnVW
	nTdzIL443KR5KVFEUqqtQzlvq6EaDBBvtXqZW9qOVDS3LAUOwWJdIXHTqjpUAx2BdBV5IV8MPEm
	VcbLYgdXWSWqtz9/WHbsctkXJ2kJZ0K/zIoHzncfrcp3SytDp30yunB6PSShzOG2mVzGvpsqofY
	WSRij42rM=
X-Google-Smtp-Source: AGHT+IH2xcKyhUr+DJoZnuELcwsAOepRxs5FaqsHcYOF6VK9OEQZyqsq83u8jwP1ZHfdGHWHs4vNsA==
X-Received: by 2002:a17:907:2d26:b0:b07:b50d:df70 with SMTP id a640c23a62f3a-b34bd44061amr240888066b.34.1758779368623;
        Wed, 24 Sep 2025 22:49:28 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 07:49:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86: make Viridian support optional
To: Grygorii Strashko 
Cc: Sergiy Kibrik ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Paul Durrant ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <20250919163139.2821531-1-grygorii_strashko@epam.com>
 <5c495ffc-40c9-4c55-bfba-3e1c0d9955c6@suse.com>
 <74460196-3bf2-4927-ae38-dcb52755ff04@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: <74460196-3bf2-4927-ae38-dcb52755ff04@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.09.2025 12:13, Grygorii Strashko wrote:
> On 19.09.25 23:49, Jan Beulich wrote:
>> On 19.09.2025 18:31, Grygorii Strashko wrote:
>>> @@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt(
>>>       struct viridian_domain *vd = d->arch.hvm.viridian;
>>>       struct hvm_viridian_domain_context ctxt;
>>>   
>>> +    if ( !is_viridian_domain(d) )
>>> +        return 0;
>>> +
>>>       if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>>>           return -EINVAL;
>>>   
>>> @@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt(
>>>       struct vcpu *v;
>>>       struct hvm_viridian_vcpu_context ctxt;
>>>   
>>> +    if ( !is_viridian_domain(d) )
>>> +        return 0;
>>
>> I don't think we should let these go through, but rather flag an error.
>> And perhaps an intentionally exotic one (e.g. EILSEQ or something yet
>> more "odd").
> 
> Most of existing load_x() returns -ENODEV (for example pit_load() for !has_vpit()).
> Some -EOPNOTSUPP.
> 
> I'd be very much appreciated if you could explicitly specify err code to be used.
> -EILSEQ? or -ENODEV? or ..

Well, I did already suggest EILSEQ, didn't I? I merely wanted to leave open for
you to pick "something yet more odd".

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 05:58:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 05:58:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129892.1469592 (Exim 4.92)
	(envelope-from )
	id 1v1f04-0005Zc-De; Thu, 25 Sep 2025 05:58:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129892.1469592; Thu, 25 Sep 2025 05:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1f04-0005ZV-Ao; Thu, 25 Sep 2025 05:58:40 +0000
Received: by outflank-mailman (input) for mailman id 1129892;
 Thu, 25 Sep 2025 05:58: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 1v1f02-0005ZP-H4
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 05:58:38 +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 ad68a486-99d4-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 07:58:37 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-631845b51e2so611165a12.3
 for ; Wed, 24 Sep 2025 22:58: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
 4fb4d7f45d1cf-634a365093asm627828a12.18.2025.09.24.22.58.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 22:58: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: ad68a486-99d4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758779916; x=1759384716; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=cZjkbxKWrgIkfZ1tUIa7NXcyB06M2RYOUMqTSLQfcJY=;
        b=gLz1pxZuGrmKodaSA9qfNl2LT1qCubMiktzpe885we+wBuS/mLutnVaLjntyBre1GP
         l8GMBNjHhWTDhnxDQ9K3FrqFCiIBWZ70/WJRbOZTVPXETurdQUQi0QONFIUbB/Bq15zJ
         NvQ6iq5/ASFHoLBcdidOnkPplgPqLgQ3ej+wP4MHqFPSM6JKTXypFOjkWxE9N7TKAo9/
         RVbL8rFXwvtTABGUxfBueY27Jd/0RZBP+0zGIXPG8pWl/aY+cqoBvy2zi7OK4LDVdl4R
         QE2crU7e4aEug65ZVwDn8CyoCccKUEVPoLhWJa4ezIjHO8cL2fGRWG88SjZfy849z6iB
         /QDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758779916; x=1759384716;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=cZjkbxKWrgIkfZ1tUIa7NXcyB06M2RYOUMqTSLQfcJY=;
        b=CufSTd9D8dvuPbtResJ0rRR6WN/+sj5RzTRwLPDMLNhSERLhhCxiPCsf2V4nAuq0T4
         M+XYvkkS0k6vFyyT6F+22SYvxhezt9ucGnJs4sGklgVMJprgt1Su9KjyOZGQLGIC5KFL
         8V/LSFmdc7IDuG0pxw90MnkxanY9YPxOVib4fRCRhiXllkzeszBD9hb+qVzC5o9GCZin
         q0QnE575+hnS9SaxXRYRSdHkytvRHkwI28U3W0/YAnwRqDGUHTw4XeHXEvOCltLtnqjG
         WyA1M8lyQfH7i4Q2qfsT0hJtX9h0jnJWot0/tszAVWcCaw3ridp2tHRyh2w8dDsdIjYU
         2OpA==
X-Forwarded-Encrypted: i=1; AJvYcCXvhgXCMS6Qi1PaYYW8/5IxirFC0t72S2EGZdOopGgXTDpE4H7fahViIb3Hjv4ofiH0RMQdraM3vd4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw5b/8ZUvyj28DIg2zyMjoUp1Y4bw+6kAiU/e73j10fCI05ObPx
	CNnxbta9syUhdETTTAOli1PAKPWG4q32WAxAbSMvAMCGIGzpOjrEr7lOMz3qdnbU5A==
X-Gm-Gg: ASbGncuABdZU+k1nUfnAkyiqdlfl0EQgm+4QM3N0UHi4poVBlpoH8YNZzgrc/FcwvJ+
	8VZYnn8PFX/61t6UyrO2mVYyUg6xFVl93B1l+NpmlLCXFlpGvA6PlGmfKvfPhSn/DbehWwhxhc0
	ulF0hfH9XIUg9wIO/dRIGYvTaOIW5qtbIEPbIxoHsfn7llwHCa3D5QQ51TuLV4kjirpAtnOM0eb
	yp8Bn4NXMcwYuP9KuluAdXkiG0NP5fNhvgHnou3EB0TWsiZuvU3ALsG5z/7W9kebZklyELBLu3L
	A20PGQKNXBeKlIRI+F8hgr3SFOytxYxdCMSg+TcWO4cu5YvCHcbvXuuezcHD1vI6VQF59NMpfj8
	hCopTovi9EjlYTMqWH/ulo8ns5wSLzHsmifx4kQCCYAJJI4pkzHB6kae9BVo6a+SJCnge6o2hDJ
	FP7Yrr104=
X-Google-Smtp-Source: AGHT+IFqaHGlAiJrxJ1BHzG4ru52kaCya5IwOHsTk6YUShppCyGe+BI2Q0RrlYasU2jVhWQhipTjSQ==
X-Received: by 2002:aa7:dbd8:0:b0:634:7224:c6b5 with SMTP id 4fb4d7f45d1cf-6349fa8f109mr1274277a12.28.1758779916475;
        Wed, 24 Sep 2025 22:58:36 -0700 (PDT)
Message-ID: <84cd0eeb-ff5c-474d-b0d0-eb79c4a33c9b@suse.com>
Date: Thu, 25 Sep 2025 07:58:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH 1/2] x86: hvm: vmx: fix runtime vmx presence check
 for !CONFIG_INTEL_VMX case
To: Alejandro Vallejo ,
 Grygorii Strashko 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <20250916103251.2144449-1-grygorii_strashko@epam.com>
 <3baf457c-d32b-4965-96bb-022a2f92bb9d@suse.com>
 
 <88cc4cf1-3bc9-47f5-b8f7-e04f01b027ee@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 24.09.2025 13:23, Alejandro Vallejo wrote:
> On Tue Sep 16, 2025 at 7:14 PM CEST, Andrew Cooper wrote:
>> On 16/09/2025 9:57 am, Grygorii Strashko wrote:
>>> Hi Jan,
>>>
>>> On 16.09.25 17:34, Jan Beulich wrote:
>>>> On 16.09.2025 12:32, Grygorii Strashko wrote:
>>>>> From: Grygorii Strashko 
>>>>>
>>>>> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX
>>>>> dependency") the
>>>>> HVM Intel VT-x support can be gracefully disabled, but it still
>>>>> keeps VMX
>>>>> code partially built-in, because HVM code uses mix of:
>>>>>
>>>>>   - "cpu_has_vmx" macro, which doesn't account for CONFIG_INTEL_VMX cfg
>>>>>   - "using_vmx()" function, which accounts for CONFIG_INTEL_VMX cfg
>>>>>
>>>>> for runtime VMX availability checking. As result compiler DCE can't
>>>>> remove
>>>>> all, unreachable VMX code.
>>>>>
>>>>> Fix it by sticking to "cpu_has_vmx" macro usage only which is
>>>>> updated to
>>>>> account CONFIG_INTEL_VMX cfg.
>>>>>
>>>>> Signed-off-by: Grygorii Strashko 
>>>>> ---
>>>>> Hi
>>>>>
>>>>> It could be good to have it in 4.21, so vmx/svm disabling
>>>>> option will be in complete state within 4.21 version.
>>>>
>>>> Imo this isn't release critical and has come too late. It's of course
>>>> Oleksii's call in the end.
>>>>
>>>>> --- a/xen/arch/x86/include/asm/cpufeature.h
>>>>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>>>>> @@ -136,7 +136,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>>>>>   #define cpu_has_sse3            boot_cpu_has(X86_FEATURE_SSE3)
>>>>>   #define cpu_has_pclmulqdq       boot_cpu_has(X86_FEATURE_PCLMULQDQ)
>>>>>   #define cpu_has_monitor         boot_cpu_has(X86_FEATURE_MONITOR)
>>>>> -#define cpu_has_vmx             boot_cpu_has(X86_FEATURE_VMX)
>>>>> +#define cpu_has_vmx             (IS_ENABLED(CONFIG_INTEL_VMX) && \
>>>>> +                                 boot_cpu_has(X86_FEATURE_VMX))
>>>>
>>>> I'm pretty sure using_vmx() was introduced precisely to avoid the use of
>>>> IS_ENABLED() here. What is completely missing from the description is a
>>>> discussion of the effect of this change on pre-existing uses of the
>>>> macro. ISTR there being at least one instance which would break with
>>>> that change. And no, I'm not looking forward to digging that out again,
>>>> when I already did at the time the using_vmx() was suggested and then
>>>> implemented. (I can't exclude it was the SVM counterpart; we want to
>>>> keep both in sync in any event, imo.)
> 
> Apologies if this has already been discussed, but I didn't participate in prior
> discussions. Targeted lookups in lore are not shedding a lot of light either.
> 
>>>
>>> Thank you for your comments and sorry for not digging into the history of
>>> the related patches.
>>>
>>> All, please ignore these patches as existing places. where
>>> cpu_has_vmx/smv
>>> are still used, need to be revised one by one.
>>>
>>
>> Off the top of my head, fixups to MSR_FEATURE_CONTROL, and AMD SKINIT
>> need cpu_has_vmx/svm not guarded by Kconfig like this.
>>
>> ~Andrew
> 
> What do you mean? AFAICS SKINIT is guarded by cpu_has_skinit, not cpu_has_svm.
> 
> And MSR_IA32_FEATURE_CONTROL tweaking seems self-contained in xen/hvm/vmx/ which
> is compiled out when !CONFIG_INTEL_VMX.
> 
> For the hypothetical case in which we might want to know the real HW value
> we can go look at the raw policy, as in "raw_cpu_policy.basic.vmx" or
> "raw_cpu_policy.extd.svm". Or what's mentioned in passing here.
> 
> https://lore.kernel.org/xen-devel/a881c6a6-2c36-4e5c-8336-21cd0e14b873@suse.com/
> 
> Forcing the common case to use a helper and leaving the rare case in the
> shorthand macro seems like a bad idea. This ought to follow what cpu_has_nx
> already does.
> 
> Is there a specific code instance in which having IS_ENABLED() in the
> cpu_has_{svm,vmx} macros would cause issues today? While there are some dubious
> choices of svm vs vmx with or without negation, they all seem to resolve
> to correct code, with less codegen after IS_ENABLED() ends up in all the
> conditionals.
> 
> IOW: I have seen fear of incorrectness, but not proof of it. Now, obviously the
> burden of proof rests on the submitter, indeed, but I'd like to know where we
> stand in terms of what that proof would look like.

Such a proof could be a statement clarifying that all use sites were audited. If
then a reviewer found an issue with that, it would get interesting (as [possibly]
in: it being questionable whether an audit was actually done; what I mean to say
here is that it's not a matter of merely stating that an audit was [supposedly]
done).

Jan

> A naive grep shows not many
> sites to check.
> 
>   $git grep cpu_has_svm | grep -v cpu_has_svm_ | wc -l
>   6
> 
>   $git grep cpu_has_vmx | grep -v cpu_has_vmx_ | wc -l
>   11
> 
> cpu_has_X_Y would be off when cpu_has_X is off, but those shouldn't matter for
> this discussion.
> 
> Am I missing something here?
> 
> Cheers,
> Alejandro



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 06:11:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 06:11:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129905.1469603 (Exim 4.92)
	(envelope-from )
	id 1v1fCT-0008PR-HF; Thu, 25 Sep 2025 06:11:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129905.1469603; Thu, 25 Sep 2025 06: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 1v1fCT-0008PK-Cw; Thu, 25 Sep 2025 06:11:29 +0000
Received: by outflank-mailman (input) for mailman id 1129905;
 Thu, 25 Sep 2025 06:11: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 1v1fCR-0008PC-K0
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 06:11:27 +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 77ae1da6-99d6-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 08:11:26 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-62fca216e4aso1072008a12.0
 for ; Wed, 24 Sep 2025 23: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
 4fb4d7f45d1cf-634a364fee9sm636715a12.16.2025.09.24.23.11.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 23: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: 77ae1da6-99d6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758780685; x=1759385485; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MBv6ftHUSjPzTuW9B1LXl5PGydN16VlgcmlbMWeGDeI=;
        b=UiqwPpdNzyPkbP0+IizbhhkjrkeZjRPOyplr/uE4nDRMijgQ0+P5rfNselynWJaonV
         2b/uPH4JKekB4esq+mqnjaOhUvfGl10fj/zPgsUgY3QPZeNLeWRtDxyw7OWqIAwWQ98A
         G9SqleLfIigKrxt2AVxPYjZH1KBQUdNkCb4bC76ranFQMlZm4tdzkgpXuCoHTvxD3+pA
         mNMCChKW+qa0aZa7j26sCLiQfA1KeIdiHihBh68GtO2veb8Sf295Tk/q4EiSF+Y9ceG1
         vCNCbsJXceIuysvvmrXF7AIxvoZ5cIEMhdjTwaqKck1RtUsKxUO0X1iLJSoEMWcULmVq
         hM2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758780685; x=1759385485;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MBv6ftHUSjPzTuW9B1LXl5PGydN16VlgcmlbMWeGDeI=;
        b=kz2vZqzRA/pf38s2l4WcoIoMmcjOpzkVUbN75IOyATbFkEg9mjDCG4X/1qb1JlZpDo
         x1D/aod9tnoYtM3xuQ9Q9NuEWRpquv5LY9ref/aqXc9dVT4U13cZSmj2HhC4ce5b9xTQ
         EUSJvksxhNJ2gsa0ZUCsgAAzmlUVH11bVxIAF4kSh1rqW1CGRlAsKeJgdcHOJ2KJIbWh
         UQKpr5wHPLTg62TmP/2qEJYe0fChSJw6upOjGhUoxYKfCdbmGT2eyqsj4fgl8LtXdm28
         zemcjaj3t2lEwUIVi3fSmirPM5qe8u2cgJkkE5t22YUxRSVzwh4g4Vydi+Mbgmlyhid6
         g1nw==
X-Forwarded-Encrypted: i=1; AJvYcCUpJyhipZ76KkbuIAOPd5t5KodJuVjPV91TrdT0/Dj0kQiWQwkIJoRbUSgXkhoSzcSkd5RCaqhsZ2E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8GPbUeFVx4dCT1i/ilm/AbOMiN8ACuR7/sf8ecZUrBeBSwovH
	uMEDrpD4ZiCrXygSbv3RcGu36yqf+T7hsBhYEa9E7O9EMY9LLkM1ps9oZ4fKXqERPA==
X-Gm-Gg: ASbGncuBJFZI5ZiGSlrVSK076fGAWgu7a8ihjZjcamJPRhzmJw6Ik/o7vgX5feMwjw2
	4VPEwKm/9g9HP0h/2Rfj7uS2jPH9hA1GQOqZu8T/5yVVVAHs/bFZw4z1wcNN2L/dNqZPPvqBSa8
	akOB/MQ/TCAHSNKaEXa1fs+hrMlx0hbT1/GrF/wXbltdnr1Wxm394n55pF9IX4a+TDyEXU1WaPa
	g2hj/nDW/PGy8kRZTMiPtiUFw1CeXtT2fVbuReo80J4e17LVudbsp6qUAMHtL65I5YKuQ/+MGaz
	eqb0tA97MLqz9GU9a1wy21Elua1kn9wwf4CEkXg8d8vO5h/y4P4LW6W/064po4CzRVzwZgoKHdk
	wODMxZF6UDv3yo5kK/zVJDjRfzSXMmSWIfezGK75xYG7uAYsm4GZLDNVwrSupxF5bFTWr/Z04ce
	RjWvSdhas=
X-Google-Smtp-Source: AGHT+IFLw+dfTHbh1IdN169leXpJQ8ehjhvkJC19+T9DrNY1dZ35CQDZZeee84SxjkSGaashcp4v5A==
X-Received: by 2002:a05:6402:234d:b0:634:54f3:2fbb with SMTP id 4fb4d7f45d1cf-634a292cddcmr1512674a12.3.1758780685412;
        Wed, 24 Sep 2025 23:11:25 -0700 (PDT)
Message-ID: <83116585-65ef-45fa-9358-586ae46753aa@suse.com>
Date: Thu, 25 Sep 2025 08:11:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/8] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Jason Andryuk , Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-8-Penny.Zheng@amd.com>
 <5a2e887f-d6da-42e2-aff0-efe55b041749@suse.com>
 <1106c080-508b-4328-a636-900ca8377d2d@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: <1106c080-508b-4328-a636-900ca8377d2d@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 18:47, Jason Andryuk wrote:
> On 2025-09-23 11:38, Jan Beulich wrote:
>> On 23.09.2025 06:38, Penny Zheng wrote:
>>> @@ -154,6 +156,17 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>>>       else
>>>           strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
>>>   
>>> +    /*
>>> +     * In CPPC active mode, we are borrowing governor field to indicate
>>> +     * policy info.
>>> +     */
>>> +    if ( policy->governor->name[0] )
>>
>> amd_cppc_prepare_policy() may leave ->governor set to NULL afaics, so I
>> think you need to add a NULL check here alongside with pulling this out
>> of ...
>>
>>> +        strlcpy(op->u.get_para.s.scaling_governor,
>>> +                policy->governor->name, CPUFREQ_NAME_LEN);
>>> +    else
>>> +        strlcpy(op->u.get_para.s.scaling_governor, "Unknown",
>>> +                CPUFREQ_NAME_LEN);
>>> +
>>>       if ( !cpufreq_is_governorless(op->cpuid) )
>>>       {
>>
>> ... this conditional.
>>
>> The description also continues to not mention the effect for HWP. I'm
>> actually somewhat confused, I suppose (Jason, question mainly to you):
>> HWP falls in the governor-less category, iirc. Yet it doesn't supply
>> a .setpolicy hook, hence __cpufreq_set_policy() goes through the normal
>> governor setting logic. What's the deal here? The answer may affect
>> whether I'd deem the pulling out of the conditional correct (or at least
>> benign) here as to HWP.
> 
> Hi,
> 
> When I wrote HWP, I didn't realize using .setpolicy would bypass the 
> governor code.  Instead, I implemented the no-op HWP governor, since I 
> thought I needed something as a governor.
> 
> set_hwp_para() actually changes the configuration.  HWP only implements 
> the equivalent of amd-cppc-epp autonomous (active) mode.
> 
> So I think HWP could switch to .setpolicy and drop its governor.
> 
> But looking at this hunk:
> 
>  > @@ -321,10 +327,12 @@ static int set_cpufreq_cppc(struct
>  > xen_sysctl_pm_op *op)
>  >      if ( !policy || !policy->governor )
> 
> Doesn't this !policy->governor prevent amd-cppc-epp from setting 
> parameters?

Only if amd_cppc_prepare_policy() took the default case path of its switch(),
aiui. Penny?

Jan

>  >          return -ENOENT;
>  >
>  > -    if ( !hwp_active() )
>  > -        return -EOPNOTSUPP;
>  > +    if ( hwp_active() )
>  > +        return set_hwp_para(policy, &op->u.set_cppc);
>  > +    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
>  > +        return amd_cppc_set_para(policy, &op->u.set_cppc);
>  >
>  > -    return set_hwp_para(policy, &op->u.set_cppc);
>  > +    return -EOPNOTSUPP;
>  >  }
> 
> So there may be other checks that would need dropping or adjusting to 
> support HWP without a governor.
> 
> Thanks,
> Jason



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 06:26:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 06:26:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129922.1469613 (Exim 4.92)
	(envelope-from )
	id 1v1fR5-00026b-Uk; Thu, 25 Sep 2025 06:26:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129922.1469613; Thu, 25 Sep 2025 06:26:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1fR5-00026U-RN; Thu, 25 Sep 2025 06:26:35 +0000
Received: by outflank-mailman (input) for mailman id 1129922;
 Thu, 25 Sep 2025 06:26: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 1v1fR5-00026O-7m
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 06:26:35 +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 94083976-99d8-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 08:26:32 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b0787fa12e2so76523766b.2
 for ; Wed, 24 Sep 2025 23:26:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353efa406asm98043466b.23.2025.09.24.23.26.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 23:26: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: 94083976-99d8-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758781592; x=1759386392; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=leNqK+DTF+M/jsIecEuMggMwHPT00Chc3JwzndCGorY=;
        b=KdJYJufZ9qp7vfRwIAryRoJKHvEKQkznLlptciBJMV3bfIxlhbonANkGGhWjwg0gxw
         TtU0JaExADi3RKaZ1NdoUA2IDsyfP6TTxMpX4c2D5TWsSQ+9rDKXo9Up0vs9MBI30h6X
         eg2vQEwsKHqhu4aHenWVLQxZa6OmZ5xsLa9p3KRUL9MAccRQyfFmKV2+t8PkAbsKwZPa
         1o6CSQ++vsF4tcoTyjNiecRGK0Hja+JnEV2M3/W7z0fqlE3dtrHlgJ8L/zk+1Pi296aQ
         VTOlhd/rh/+Tjga0F3+kqZ2EBN4rdA6E9zaOsE+652RmLUWNDhLVnTgIZ0tPTvz3yXta
         rOIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758781592; x=1759386392;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=leNqK+DTF+M/jsIecEuMggMwHPT00Chc3JwzndCGorY=;
        b=T+19/41KUTLg278EtzgOdykhDbY2jafXI13MF/pD/2ihKj0USUm+7gyj1iHnt/VhUF
         7ftfiW+tpAd7oWudLcxLIBUM1Lta4Bxl2I+nSnBGiJzKIzNKKXPpUkZtTgxSQ8rMU3KV
         6YHtaJssV0cP38AgVNkRuHvfVxk4qF1Q5b2da8eCzNkTvsudxsAjqsjg0FJUcBBspmoo
         MPVKszmcdnDBNCYyIlczsy/jao5B8GKkE6GDLiS4DMLxWp0xpqxWqCPjCfaNaMM6RE83
         WQzGZJavmXE4VcSQ3hkYfCJtv3I2XnE6PZLRkjKIOl/1BnTQWuWA0VB8ZZCNYBaXijQk
         4Bnw==
X-Forwarded-Encrypted: i=1; AJvYcCVaXBZD9d2vs4fSy/iLaks9T+2+x9UwpdqALCLfqsgq4qx76sji6Rl9LF5PiPlHEjiNBeNEPnfYgPw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVovJCPeYS8PmyxboC+js5Ut3eBAfdv+c9u0wiQsCKAN7S9ZHk
	THs+FBw1ku2E7f8nUFaYqDrdmjfkEGfI+m7D1Nzqmn+L79Kku27Wih37gcCKivHDCVIoZB6EHU+
	5kQs=
X-Gm-Gg: ASbGncs0smVkUYTOR/aGvvnPmGauYn1h9WFYhUGvL7UkXpq3WwxOrMkHYDpKLRyGeXm
	JX2ZA5pGbS9R7Is5FuzB/P6DpJHzbc5Xro1MMGd/czyFZhEu7qqi3J7PvWkbxlCWHD9RDxspJh0
	sP2vHpYBK9w3ERH9U3cX7e/V90o3AKOKU7k19Wx7lMg4dW4VOiv7NkoP0Xx8Wqoy/0P7fz5bBXd
	UoIc3Tcr3M74htDi86qnWEIuOe8ON0xxg+o/iH1TQ74YDrLSwmzA1b3QYnd9a0a5YkU4ocZio+m
	Kbew3M8MqUjTpiSTVwNOZ1eJ0VaFlOcGwqrGOKxxfOvWXON0pulZnOfw2RhVOlqu2f7XrKNetNI
	d4UySGvq4kB65a0iUKLZ/0iAP/zlo/4OFwtfaIId+3p7QKSpjxyPiQABZhi41YpXdFV4ZsPC00q
	n3I2ejY1c=
X-Google-Smtp-Source: AGHT+IET+T6aTzAz3NbyPXyZ3E7qw/l9Ky1FlVRdu9OSvPdReuRWU7hfTelxrQwR+YqhBu1vsebl/w==
X-Received: by 2002:a17:907:3e8d:b0:b34:103b:4846 with SMTP id a640c23a62f3a-b34b8d96456mr283652766b.25.1758781591964;
        Wed, 24 Sep 2025 23:26:31 -0700 (PDT)
Message-ID: <814501c8-94e3-4930-87ed-88e7506456ed@suse.com>
Date: Thu, 25 Sep 2025 08:26:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CHANGELOG.md: Update for 4.21 release cycle
To: Oleksii Kurochko 
Cc: committers@xenproject.org,
 Community Manager ,
 xen-devel@lists.xenproject.org
References: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.09.2025 11:36, Oleksii Kurochko wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -14,6 +14,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
>     to the baseline change.
>   - Linux based device model stubdomains are now fully supported.
> + - Remove libxenctrl usage from xenstored.
>  
>   - On x86:
>     - Restrict the cache flushing done as a result of guest physical memory map
> @@ -21,6 +22,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - 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.
> +   - Allow to unflatten DTs.

What is this about? There continues to be no use of DT on x86, so without context
this feels pretty much meaningless to me.

> @@ -36,11 +38,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
>       Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
>       and 28 (Temperature Probe).
> +   - Basic kexec support to Mini-OS for running in PVH mode.

Hmm, MiniOS isn't an integral part of a Xen release, so I wonder if such really
belongs here. Yes, I also understand that there's not really anywhere else to
put such.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 06:34:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 06:34:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129942.1469622 (Exim 4.92)
	(envelope-from )
	id 1v1fYm-0003hB-Lp; Thu, 25 Sep 2025 06:34:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129942.1469622; Thu, 25 Sep 2025 06:34: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 1v1fYm-0003h4-JE; Thu, 25 Sep 2025 06:34:32 +0000
Received: by outflank-mailman (input) for mailman id 1129942;
 Thu, 25 Sep 2025 06:34:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1fYl-0003gy-3G
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 06:34:31 +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 b011a4d9-99d9-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 08:34:29 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b28e1b87aa7so89798966b.3
 for ; Wed, 24 Sep 2025 23:34: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-634a3b052e0sm652782a12.47.2025.09.24.23.34.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 23:34:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b011a4d9-99d9-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758782068; x=1759386868; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ozP4ICgetyfPLvldh5KQA27y5QCFNaRSs6nV+auII+I=;
        b=aLTCH3kQ5u+DL6rAVki/B+42T0lWDUnK1ZRwn6HQxuDZ0yR+1zav5SW7CBU1jAI9Bd
         AsJnSKWQu7mS8srv01zlkboBNikmmdcRH8B2RWQscqYIx3VyW668xWA47jhSYgjmpC1I
         Fy2ioQq+GOJTFirY3/YJOLXH6bWTCRrRMcpGxsijBDWw4S9TtRU36Gto/3lfkz2bnQFH
         pfJxAOVs9HXs+kJfPUWk4a6Et8KTGiIMJIgzLIFzn9RwrFVh9kiiIQ9SFePQyJI6U2Hh
         O2YeJLOceofxfNvObv0tbNOXnf2FmhksP46F2/M7HMtK9ZnUHEQK+TMVWd9Gt4QX92SO
         4YPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758782068; x=1759386868;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ozP4ICgetyfPLvldh5KQA27y5QCFNaRSs6nV+auII+I=;
        b=DyZ2v7kxVeAUd1GZLro7Frckj7fH590UGgVp2T/3BIUwVEzxdv+ohQ3Rps8McBInCu
         KAL2NOjkBCPmiSGTtqsIk9PffLtjwTWPi2kPyTqhzV41Wc9S3piPNEAtPmg6xQVGOx6O
         QrNG0xTXwry/tSytTG4IQWzwhX8x/Bz17WQELVlsXjHEz+h4J5oj4fhBqjPhYBH8hGRh
         obajf5wc4IYfOEkv1MxH55HqjzOSrWEqgd3y1g9PJng6GH5IAKSGrmqbMCWdIE0GxBDB
         bfjRmV7byRD7vbQJ7NSc5rMx9Ta+LM5qzQM+CPk7jX7a7JzqdMOHviLPyS2ivPLg16Ia
         7C9g==
X-Forwarded-Encrypted: i=1; AJvYcCVrwqxlAZ1sidS7iKYj/IoBt4xxzPSmJfN1Tbpd6ND9A5mXtWgk6Eb7E/UetuITkZX722xzFVeLrDo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxB1kbj7UsZT8fetCOXbdWX1P0evnAxV1PMaxsnI7579sTelWH1
	Yj8v8YwvwX5rL5TXsGoYVgGvQJXEc4DF+XSIpMXcR3gY8h44Smp/gZYV9QrQlWLXiw==
X-Gm-Gg: ASbGncv7PiDAxri54rTWtyu5lZm4x2CFaMgRpFEZQyMJtpbQDf0rkyzAUDG2lBk6F5j
	5JYLo880Bhn6kfbLOtJD6EJxZI/Ix4nK8YmlWgRwcqg0caRgOBMx9C3AtPbXsiepLCoQLPf0MAD
	biOQq8OEanGpKhP3DVFZ1ApO6MknqMKjz93f5PTx5ryyUUZERbNfyGxab/UrhI4hlvmvG77EQxs
	13XjbPhZLC207vPOKQ8qv7YBXMEy1oQgOjIVIqKB8dVeiE8M06/yJUsnCIRfwHTGhHkj1cUHe1t
	jWI4my2d608UuIu3WPnaWPv1H09c92X6s0xPKj5kIVp6Bgaop3JTtiFjk3BJo2vdTKtRbco42Cs
	sQKSI3ufv30nI4jZqmqsFQCFe3dQWHU5HHup5v0kwG/bmOdt/8xvOPh9zDSSz1qwX+6PVtUxjZN
	EyeWCoBxU=
X-Google-Smtp-Source: AGHT+IHzLCTXuKAPq1YsMXuj+To6GOOACzY7Bx/GCZC4Q4Waa8Q1tRyHjTVFuuopP6tPuIJSZtLR6Q==
X-Received: by 2002:a17:907:1c15:b0:afe:87bd:da59 with SMTP id a640c23a62f3a-b34be2f5318mr221327666b.42.1758782068489;
        Wed, 24 Sep 2025 23:34:28 -0700 (PDT)
Message-ID: <9507e775-f9c3-4351-9c76-ca939c1147bc@suse.com>
Date: Thu, 25 Sep 2025 08:34:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
To: Oleksii Moisieiev 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 "xen-devel@lists.xenproject.org" 
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@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: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.09.2025 18:00, Oleksii Moisieiev wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -26,6 +26,14 @@ config DOM0LESS_BOOT
>  	  Xen boot without the need of a control domain (Dom0), which could be
>  	  present anyway.
>  
> +config DOM0_BOOT
> +	bool "Dom0 boot support" if EXPERT
> +	default y
> +	depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS) || (X86 && HAS_DOM0)

This line is too long, and really would have wanted to be broken up anyway. Clearly
"depends on HAS_DOM0" can be separated out. I'm not quite sure about the extra
Arm-specific dependencies: Are these two really Arm-only (as in: not also affecting
e.g. RISC-V)? Furthermore, what if I turned this option off for x86? Doing so would,
aiui, have no effect at all right now. An option without any effect imo better
wouldn't be exposed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 06:41:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 06:41:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129955.1469633 (Exim 4.92)
	(envelope-from )
	id 1v1fff-0005Ms-Bg; Thu, 25 Sep 2025 06:41:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129955.1469633; Thu, 25 Sep 2025 06:41: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 1v1fff-0005Ml-8X; Thu, 25 Sep 2025 06:41:39 +0000
Received: by outflank-mailman (input) for mailman id 1129955;
 Thu, 25 Sep 2025 06:41: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 1v1ffe-0005Mf-Ew
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 06:41:38 +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 aeaf3d30-99da-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 08:41:36 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-afcb78ead12so99447266b.1
 for ; Wed, 24 Sep 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
 a640c23a62f3a-b3545a98300sm98485866b.106.2025.09.24.23.41.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 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: aeaf3d30-99da-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758782496; x=1759387296; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yMkb/XBISukaOBYe2gqGsOGKEi6LHXY5IpwYrRA0BPg=;
        b=EaHybm54TldGV8RW2LUKF53QuyKzxDh5jRLNZNjRjte+CtpA8WPS1lIZ6y6zayr37e
         xc/ROO0G868dhCEe8mOPgd57D5sRJ7e8HwJfFllIMxZwzU0sY+O7T0sofRK1Orr7Ql84
         0mW0m2CU4JKRMehGV8u/v/aPokhrHhULur8G/7MeF5tYDg5FjuKLZpg0GjJwP4iG7j/R
         R0NsAdqVkfaF54Ef/QYbb6WYTKyGTa4Rsjfix7/r/iFF8ULO4Vef+GmlrGn7YipRIlrJ
         Uw4i8nVJWeFeJl9X62e7KuftJyE7FvyEDBb8KPgowS5lXObbBBE/v94f13NJjblcAzWu
         V30Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758782496; x=1759387296;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yMkb/XBISukaOBYe2gqGsOGKEi6LHXY5IpwYrRA0BPg=;
        b=uQdmc6lJvUePt7ONiyhfbbXAq0f7c74gnkNUZriJTcHWisgxsLImEUdkm0/AZ8vIJz
         uPDFDPprO+Wk+ypWBdp9NtMh0Sf8E+jcBE+wndsWGd94CnxM+QDfbEpK6xW4v2UwlNmU
         vEm4ZpTIeA+NTiWy77dKT/aGVqM/dxX2L+crlrJsK9Eh+KNKTzEHrUNfWcyJWBa3kRqs
         zBVXR/8BU1V4ICriik1JbDNmWyptUjDwmScwfFIONKN/gK7CBsbLSXo+ilrg24gf2g23
         D7iC3wGeTuEmQU5g9maTYHBKaDABFdsove0A3jKq+SVDF/eEnxd6IJJuIF2ZEPfC7yGT
         GHCw==
X-Forwarded-Encrypted: i=1; AJvYcCVLo3VOZeIAHVIelHuvdVmQHQAG64By2BzqikxLOvuChtok+tNW6+E6aPHu0Og7w2LLZL+p70ElZRw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwniKv159Is+MCMF4mxDGW3kp/Wj6S3MtTEGz1Gr5BQ0x0thsVn
	/5Yq8tD8IVvddhoVSlHnUezo+E7Rbhv/AYmzg9jziEMfYS5AN6jSTB0KtQSrvinhMQ==
X-Gm-Gg: ASbGncunhPmd1xGQ9ECi9Pfra7ok2z903JBesUK+kEARzSYuHDeYusn/AcdbmQ7fESA
	bggJ+//Eu/9axL/ptAziQA1Rpaa/E8CrWv4ZGwCZC2oNEo2eYh9j6p5prm4vo1a5/ukOjlFPbKu
	oqt0PgssjGhbupVXgpP8ky23vwrkZS3IsaN6SMZQR4ZKlUQh3mxGfEsh+Qi57nA9d3Fm5aLRTr3
	xr6HuJKoSxosmzX4tTr3sucVnLcJ2d9QqZCFwS+/lGAG74+go/fk2t7toGR54MY+cMA0hSKRC+G
	FItODWPXu8UWVjJ/RfNxAlIRnP+fiFfTWlY4rrVrEGUmXfG5U0iwF99LSnhdQZQQaFisMY4DpWG
	+JO6zPxY6ESW5/BZEYxakZ2n7MXGY3pHXHxKMBGCC+zjbm7WGRKGuUtFNhlyfEjsUWtYFc7MVLy
	sy4VyWfQ8=
X-Google-Smtp-Source: AGHT+IEh/iREEYFeuR6RUeuim7C4uEtzhEZ+Zn2ukY4ZuMk63D/1oFARHpvFfTEApT2WXxJBXp4uMg==
X-Received: by 2002:a17:906:6a0a:b0:b04:85f2:d272 with SMTP id a640c23a62f3a-b34bc97172cmr242016366b.49.1758782495589;
        Wed, 24 Sep 2025 23:41:35 -0700 (PDT)
Message-ID: <5ca4c3e6-4dd6-4de3-a7cc-4070ab3e1d41@suse.com>
Date: Thu, 25 Sep 2025 08:41:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] arm: address violations of MISRA C Rule 2.1
To: Dmytro Prokopchuk1 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "xen-devel@lists.xenproject.org" 
References: <620eb8fe22204e204cb471e93d2ea789f879d854.1758744144.git.dmytro_prokopchuk1@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: <620eb8fe22204e204cb471e93d2ea789f879d854.1758744144.git.dmytro_prokopchuk1@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.09.2025 22:35, Dmytro Prokopchuk1 wrote:
> MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
> In certain  build configurations the following functions 'prepare_acpi()'
> and 'gicv3_its_setup_collection()' are defined as inline functions and
> contain the macro 'BUG()'. This resulted in violations due to these
> functions became non-returning.
> 
> To ensure compliance with MISRA C Rule 2.1 remove inline function
> implementations and their 'BUG()'-based unreachable code. Provide
> unconditional function declarations for 'gicv3_its_setup_collection()'
> and 'prepare_acpi()'. Rely on the compiler's DCE to remove unused function
> calls in builds where these configs 'CONFIG_ACPI' or 'CONFIG_HAS_ITS' are
> not enabled.

Imo it would have helped if you had stated the respective predicates which end
up compile-time constant. (Likely the two changes also could have been done
separately, as they're entirely independent of one another afaict.)

> Signed-off-by: Dmytro Prokopchuk 

Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 06:48:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 06:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129968.1469643 (Exim 4.92)
	(envelope-from )
	id 1v1fmE-00069R-1V; Thu, 25 Sep 2025 06:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129968.1469643; Thu, 25 Sep 2025 06: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 1v1fmD-00069K-UF; Thu, 25 Sep 2025 06:48:25 +0000
Received: by outflank-mailman (input) for mailman id 1129968;
 Thu, 25 Sep 2025 06:48: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 1v1fmC-00069E-I9
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 06:48:24 +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 9d166cfa-99db-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 08:48:16 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-b256c8ca246so122283866b.1
 for ; Wed, 24 Sep 2025 23:48: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-b35446f7506sm99531066b.52.2025.09.24.23.48.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 23:48: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: 9d166cfa-99db-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758782896; x=1759387696; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=p1AgoaW7coxI7lgNEoGPE9cIu1g2s2aCLioDA2QRJhs=;
        b=aaZHvRsZPszYbVHAnSTX9LXHkvUqdlyxqOHUCOA4ieIq7V7ruF17c/HyR6OHkzUuY5
         unRrUgjTphpy/+wO3RuomffM2N9w5TwcCHpKa33fs7eci1v9VZIYdmyOcZan95GKQp+2
         dKLdlhIcIUZaUQOLTo/kwUqRUFnLnzffYLYZWbMJD8UiZGqPE4CM8d7GLmsAL+I9vj5A
         qa8RIFQsgMXv8BNFI3HxaLAilUdTSrrFbzriGrWDZKYaUzJeIcftscvJ7pu9IaUg+wSN
         zrE9Q1CM7aBLbMvTzhRglBsQCmeMBDJbzuv61BIabEs4Fv47ZEjf17QBPyzu+j3fyV3W
         2alg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758782896; x=1759387696;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=p1AgoaW7coxI7lgNEoGPE9cIu1g2s2aCLioDA2QRJhs=;
        b=jVhGUZkPLMFLx+WsHrwHae9aBIGEUHMc8gB7HSfKZPec2LNRAckNLCl0aknZtCSx6M
         Emp6G+oTNY2MD11HNW+//d3D2PZ+m7odYvH/cgoqIPTQrNGOqdU0+UYAj96BpoPjo8hU
         qdz+0tMYrIo5R/MfXKNq3cMGTnF/u73Vc8RL861EEpe6eok04Kbus2pH0jSSWBDLakly
         bFS5iQv+K/COdmSOqSOsIzd3iyesF38V9pL+9DUwDG5IQBxKjsOGSh0P6P3XrdpZhGNr
         xAFsBxNoZVBn16OZMfA3u+6IjkMfDtbw8Fhi8mrD4sj6JP6fnZB+WjNOXiuR8OM6CgHj
         DN3Q==
X-Forwarded-Encrypted: i=1; AJvYcCWW53mF/evj5D4Dwbo3qaqNlu4/PxVxJWULF8hHcwRHc2cqquXByTUdyoA2lH+loKXPmLD15U4sqQo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWP4e9OFwBFzCDKux+Cp8zxkJ9LnKKXeU/xujSKK0AcuWYzijR
	5Q4g70CaInRID7fwELH5yFJPGNHLCN7085wuujYV5TVGjt0Oc0I2KvMf6XFa7TI+5A==
X-Gm-Gg: ASbGncsQQxABOTVTLry5gjPbCwqz8kDoCoenYZFexGY+S9w93LbsSzS6hRaM6n5laiS
	H/g0RyEzVsRCWxi4kx/GfATuXfvuMWS6w/wt7scXIUht1ZlOWJvBQ7GoMZYMSyuxDszlQpMvSHg
	A6ZCcuKQ17ZxaTgePPuH8lCWBR6uAJFqg4S2JcmQ2HtBFdpFUi8WSvz93t5lXLSTY25wA7bZTAR
	EQhYeVgnvioXydqBEPYO/O74ePsSofx3dO0lMDApKCG322dyWI0x2rbgti6WzxQK2GZIDK2lb7f
	D9GsYi31NxCvNXJ3gk+mV4Dc1oAACVP8sQhAVtRGqdsckv9LJX8CxFRV4eHcO86cuLVGMuwAfA4
	v396CkwSC8/IKzGa5orzCQp3Tm1cClGpGtCQop4Ig7SIdxqF8NrEv5VrS879YbCsVa9itOm8Jqy
	fj9EB/Kuc=
X-Google-Smtp-Source: AGHT+IEqWsX1wpsa2jFTfLWaXxQedDhT48zZXJVkODGg9FSo0SCVIDPjUP9qc5lh56G4gRn5lKeCzQ==
X-Received: by 2002:a17:907:7fac:b0:b2e:b50c:9f8 with SMTP id a640c23a62f3a-b34bad28543mr234093866b.23.1758782895630;
        Wed, 24 Sep 2025 23:48:15 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 08:48:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/8] arm/pci: Add pci-scan boot argument
To: Mykyta Poturai 
Cc: Edward Pickup ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Luca Fancellu ,
 Stewart Hildebrand ,
 "xen-devel@lists.xenproject.org" 
References: 
 <38d8a5b16f55cfe903c86073c48fe0d6d7af107c.1758618839.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: <38d8a5b16f55cfe903c86073c48fe0d6d7af107c.1758618839.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.09.2025 09:59, Mykyta Poturai wrote:
> --- a/xen/arch/arm/include/asm/pci.h
> +++ b/xen/arch/arm/include/asm/pci.h
> @@ -23,6 +23,7 @@
>  #define pci_to_dev(pcidev) (&(pcidev)->arch.dev)
>  
>  extern bool pci_passthrough_enabled;
> +extern bool pci_scan_enabled;

At this point of the series this isn't needed, ...

> @@ -155,6 +156,8 @@ bool arch_pci_device_physdevop(void);
>  
>  #else   /*!CONFIG_HAS_PCI*/
>  
> +#define pci_scan_enabled false

... this is entirely unused, and ...

> --- a/xen/arch/arm/pci/pci.c
> +++ b/xen/arch/arm/pci/pci.c
> @@ -91,8 +91,14 @@ bool arch_pci_device_physdevop(void)
>  bool __read_mostly pci_passthrough_enabled;
>  boolean_param("pci-passthrough", pci_passthrough_enabled);
>  
> +/* By default pci scan is disabled. */
> +bool __ro_after_init pci_scan_enabled;

... and hence this wants to be static __initdata. Otherwise, strictly
speaking, this is "unreachable data" post-init as per Misra's unreachable
code criteria (which surely ought to extend to data as well).

> @@ -104,9 +110,23 @@ static int __init pci_init(void)
>          panic("Could not initialize PCI segment 0\n");
>  
>      if ( acpi_disabled )
> -        return dt_pci_init();
> +        ret = dt_pci_init();
>      else
> -        return acpi_pci_init();
> +        ret = acpi_pci_init();
> +
> +    if ( ret < 0 )
> +        return ret;

I understand this is merely transforming existing code, but I don't see
what actual use the returning of an error here and hence also ...

> +    if ( pci_scan_enabled )
> +    {
> +        ret = scan_pci_devices();
> +
> +        if ( ret < 0 )
> +            return ret;

... here has. The system will continue booting nevertheless, iirc without
even a diagnostic from caller.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 06:50:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 06:50:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129984.1469652 (Exim 4.92)
	(envelope-from )
	id 1v1fo2-0007eL-GG; Thu, 25 Sep 2025 06:50:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129984.1469652; Thu, 25 Sep 2025 06:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1fo2-0007eE-DX; Thu, 25 Sep 2025 06:50:18 +0000
Received: by outflank-mailman (input) for mailman id 1129984;
 Thu, 25 Sep 2025 06:50: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 1v1fo1-0007e8-BX
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 06:50:17 +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 e41db2a6-99db-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 08:50:15 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-62fbc90e6f6so873297a12.3
 for ; Wed, 24 Sep 2025 23:50: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
 a640c23a62f3a-b3545991dcdsm99559266b.92.2025.09.24.23.50.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Sep 2025 23:50: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: e41db2a6-99db-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758783015; x=1759387815; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iFUQSlpWaroYSYw75Hr7KvAGMNXe6nKQPNtGFl/1BPg=;
        b=V9i1s53m4H0QcAhBwJpEmkVq6Eptg3Ze88N4ex8wnbawfUjNjjRLHktOK722BvDeBI
         L7kyVlAsOA7y7g5PPQyf4gXFM/c7F5eEieNVlqIPi5agHTx5Zsbi2ve729IxCxO5RrN6
         7tYAU/R4MRhef5ULawgKA/Y/XtSAgiK8Lqzh/+rQ/PO5dRIbXcyPNCkuNneEP39hJo7d
         2AcvA8BZFKbb/7mU0PV5WKR+LIb15R0EgM1XAXtSUV1V6f+oCQAQSV3v+lF4tlkVuQV5
         NlCtJNZuJ0PnI2Hv0Zvris0mjKCGnFx0Ixbx2jNNqREiMxyJDaxtZaGFbmRU6hTNKNo+
         7sJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758783015; x=1759387815;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iFUQSlpWaroYSYw75Hr7KvAGMNXe6nKQPNtGFl/1BPg=;
        b=HtkcROtewOROEt91cvfm4/fgUWblllPBIialVLDuQzyYj7E0JPfG7DU8RCtvtFFyvW
         /G3Ie/ZBnb9aMdargwZHdqRf2GWn4NtUHq3l946Xu94yLVRDpSFUArnN5z/sQyedxAlZ
         BQxkeSE6BMagXaavYIGsvuF7BpOst6fAeo1Tgc0lfQeOlrSeGdNIEGmXMippEFxZrYY5
         qU7dyshbtFblm1+Xb9jWqwIEjrU7A5k9yqG2324K7/f4DvXKZZqQ4QyWO3rR+Ko/DFmc
         wjZRXIw7Y/RfiUOg7d7VXtAQrUp5OWztqhtb1celQdzW0Is5araFy+/K0/9NGkRwo80r
         plHA==
X-Forwarded-Encrypted: i=1; AJvYcCV3pUzR4PzeHp9D4JvZUmDjGNfkYusZKTLK2nWylnbXWIsiaIBVw/tysi6i+lMQtGbGNg1DW83pf2U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwaV+DpChE8LaOODG58csbcu3i2Nk5YvGs9Ox13nEKCm+Dfnjnw
	4MhMma2kesKjsbbgIyopEZJf6BzRmRn8e9InnfdA/Diz/mXg1eRSJKKgZ6On2O/0rA==
X-Gm-Gg: ASbGnct6PA6LRZbzzeKA7c4EeBJxMO0XDIiHvROVFmI4eEId2EGu79UT0Xvn5Zwqssw
	XpT8HMRWXIwlWwy9ABR16fPvar4EKh4lPeNY6paE+JLZzVXWQwO7lXuJUMJkZlXiZPuGyLLBtoA
	gXtlDpAh014yCdm7VMDE5pHuHnjJZTj6LFxAmSumd9CE8m55bVsuIqpOFn7SMttl16WloEW+oYl
	KE2nsIM3aMR5JmZEIsnSaQ1RQYW57KBnNp1nuiOTN7COHLommCgKzFAQvVcdhoitd/HQMcZT7IH
	acDvwJcrqxCUqQlTxiVE7XHaun/j9J9yoHXfDOVrrPdPMXX1uK1NYkpy59z0qNz7RNkLll+NVkM
	pdx+GUxfktubfOrA/jHYNZ0AdE4+MEn4fX/Lulzwoj4b4u/+BR+zenwuRvfPbZnxTVCzxstQf75
	PXxp9yYio=
X-Google-Smtp-Source: AGHT+IErGt9RwqYcUfVWMmOam1RilUB2C7WuL1zrDzr1knQGknniBgOl8CpascIonP4GYMJut5eQVw==
X-Received: by 2002:a17:907:9407:b0:b2b:f498:e2f9 with SMTP id a640c23a62f3a-b34bd443af5mr262775366b.60.1758783014781;
        Wed, 24 Sep 2025 23:50:14 -0700 (PDT)
Message-ID: <2a881ace-eddc-4656-9e3b-3784cbcb6c17@suse.com>
Date: Thu, 25 Sep 2025 08:50:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/8] xen/pci: update DT for hwdom when it uses vpci
To: Mykyta Poturai 
Cc: Luca Fancellu ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Stewart Hildebrand ,
 "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.09.2025 09:59, Mykyta Poturai wrote:
> --- a/xen/arch/x86/include/asm/pci.h
> +++ b/xen/arch/x86/include/asm/pci.h
> @@ -76,4 +76,10 @@ int pci_sanitize_bar_memory(struct rangeset *r);
>  
>  void pci_setup(void);
>  
> +/* Unlike ARM, HW domain does not ever use vpci for x86 */

What did you derive this from? PVH Dom0 very well uses vPCI. In fact that's
what it was first introduced for, iirc.

Jan

> +static inline bool hwdom_uses_vpci(void)
> +{
> +    return false;
> +}
> +
>  #endif /* __X86_PCI_H__ */



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:03:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:03:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1129997.1469663 (Exim 4.92)
	(envelope-from )
	id 1v1g0L-000132-Iw; Thu, 25 Sep 2025 07:03:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1129997.1469663; Thu, 25 Sep 2025 07: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 1v1g0L-00012v-FH; Thu, 25 Sep 2025 07:03:01 +0000
Received: by outflank-mailman (input) for mailman id 1129997;
 Thu, 25 Sep 2025 07:03: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 1v1g0K-00012p-U3
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:03:00 +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 ab5971a8-99dd-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 09:02:59 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-afcb78ead12so102507966b.1
 for ; Thu, 25 Sep 2025 00:02: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
 a640c23a62f3a-b35446f7472sm102925266b.57.2025.09.25.00.02.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 00:02: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: ab5971a8-99dd-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758783778; x=1759388578; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qXfTsvr5LGr8oL3ZbSYuAdZO4jHsITLutkexUXEdZUc=;
        b=RBt1sEeuE0cJdsIfIZeKPrPxfcPBlTgNJl4RuHvdXW1bb3mj/VEYh5sgpbSC8/5+jN
         cKWUvpq5x/jw+kyzMuF+8nYAOFEmu7zfPeLkreiSKjlCh9knC/hc4qYEaOneGmoVYT/c
         298SMX/FDtAnL9Seu1w32xGyYKugjfES6MEAp5k3BGQU8RevfofbUU3s+vUI4jmbOCdW
         Y6Bax85q3Ly0BUxkP09+Gb4iHbRor8GokqSMVnjXBHw0eOR1/+D5J44iH432YtHqLKfP
         wmOtcw0VsZUZiTb8RyFpLvO06S8yRF7de+sC3DNUZNERnYLe/awJZKWL9QDCxl1hNtZW
         m62w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758783778; x=1759388578;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qXfTsvr5LGr8oL3ZbSYuAdZO4jHsITLutkexUXEdZUc=;
        b=W8vCfVTG7EloRlUqvYkIMUKIV20qazEWNaLdwdmcIjR+Z2zS3HjhAYx8c2Kq2UP9OL
         XxJuHrzxmszEOQtoPtcqGAvqZzOA5N6WmPYNro38YOZm0Pf6TKUdk3rksxuMDOQH2Vn7
         0EN9tnuUNlSn91sXQGxUTnxCpvC6LIOcCjkIi5Pt0iVohmEoQdHhe2ySnJVCxP9L4exF
         Fk8yUjbH1/bRkAEM7Peb8xyEl8wbzsj5adX79JA/54JZjCqFKFAyi/uoQwPEf8AU7D9J
         TIvgQHWj3YomfqVIGvi7o5bgtO/QqP53vX+35C+Jt1nmgF6ykvbK54zHp2+CyhOFvEA4
         lOrg==
X-Gm-Message-State: AOJu0YwacRIUFPNYD1WhadtXZvDJIm6K5BZ8zxpTbQZgyR4Dg2snMuOM
	4TlIcJNUxkhmeAj3Hkk9bWrpBrOp4vA82SEwGq6Tr4twwvV8FPgXGQLlOokU1H7N0g==
X-Gm-Gg: ASbGncus/mLpDciClKSQdlFtRoC3XUNS0iRmPREcI/Xgy72/c2ys9hijhzbAi6qjbiq
	faNJsJ+ndl+plP38CmVN8eQFLBpjoQN8UgesYONqv1FqBBIa/zHiZrPQPoGIkEcEMrPeo9ssO+1
	6Ln/Prq1AlGWH9ZrQtTZNFGVhJxu2mpwc7YNX+8/ruQsqLPi6piYyKqiWzCMUN8mCFJ/cxbhh5t
	Utst9aMZ6+FHZRKPqZ5+qx3pHLnPPx2RkPTCGvzud++aFw7r4+eXvhHKvdnZBQGEqPbDPMI2Z/y
	nPPqUHYp2I9HMyWm0r9DD/3GA7rT8K5SKbg8rTEgtNhvytO9brvKhd8uv8r36d8EcCcGBWgoKD/
	vqPEJ+4u8t8aJ28ERKSnEw+joBsiQEFE2U8S/BEMJh7yWDbqQDX5R+DiXjePRs00kBOwqHhMVCl
	UoSyKEdq0=
X-Google-Smtp-Source: AGHT+IFkh/ypWGz1LPM8SPv8MCqUdDE3rvFo8B8/uDPplQ6qjJMMKj3S4BAxWJtU+1YDeMsuni9xQA==
X-Received: by 2002:a17:907:3eaa:b0:b30:852e:bea with SMTP id a640c23a62f3a-b34bd62cd56mr250537766b.63.1758783778490;
        Thu, 25 Sep 2025 00:02:58 -0700 (PDT)
Message-ID: <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
Date: Thu, 25 Sep 2025 09:03:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 "oleksii.kurochko@gmail.com" ,
 Andrew Cooper 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+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.09.2025 15:40, Roger Pau Monné wrote:
> On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
>> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
>>> Otherwise the check for the SS feature in
>>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
>>> X86_FEATURE_XEN_SELFSNOOP never being set.
>>>
>>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
>>> identify_cpu(), because SS detection uses boot_cpu_data.
>>
>> Doesn't this, mean ...
> 
> Well, that's the reason for the rant here.  The reset at the top of
> identify_cpu() has been there since 2005.  It's arguably to make sure
> the BSP and the APs have the same empty state in the passed
> cpuinfo_x86 struct, as for the BSP this would be already partially
> initialized due to what's done in early_cpu_init().
> 
> The underlying question is whether we would rather prefer to not do
> the reset for the BSP, but that would lead to differences in the
> contents of cpuinfo_x86 struct between the BSP and the APs.  In the
> past we have arranged for leaves needed early to be populated in
> generic_identify(), like FEATURESET_e21a, hence the proposed patch
> does that for FEATURESET_1d.
> 
>>>   However that
>>> creates an imbalance on the state of the BSP versus the APs in the
>>> identify_cpu() code.
>>>
>>> I've opted for the less controversial solution of populating FEATURESET_1d
>>> in generic_identify(), as the value is already there.  The same is done for
>>> the AMD faulting probe code.
>>>
>>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
>>> Signed-off-by: Roger Pau Monné 
>>
>> ... this Fixes tag is incorrect?
> 
> I think the Fixes tag is accurate; the code was OK before that change.
> Nothing in c_early_init hooks depended on (some of) the x86_capability
> fields being populated, which is required after the change.

I agree. Hence:
Reviewed-by: Jan Beulich 

I wonder though whether while there we wouldn't want to also store ecx if
we already have it. (Really there is the question of whether we haven't
other cpu_has_* uses which similarly come "too early".)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:14:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:14:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130012.1469673 (Exim 4.92)
	(envelope-from )
	id 1v1gBJ-0002jp-GV; Thu, 25 Sep 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 1130012.1469673; Thu, 25 Sep 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 1v1gBJ-0002ji-Dg; Thu, 25 Sep 2025 07:14:21 +0000
Received: by outflank-mailman (input) for mailman id 1130012;
 Thu, 25 Sep 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 1v1gBI-0002jc-Aq
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:14:20 +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 3fb09e33-99df-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 09:14:17 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b29ebf9478bso86524366b.0
 for ; Thu, 25 Sep 2025 00:14: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
 4fb4d7f45d1cf-634a364fd05sm727080a12.13.2025.09.25.00.14.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 00:14: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: 3fb09e33-99df-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758784457; x=1759389257; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=F2sXIVpQ2sRQqf9olGrpp/u0HOjr6xauSwIcL3FIM2k=;
        b=Zwl265KS52DFMO5zzSgnT7sLwN1VYTwZvTsheIHXG974jCFoScDXh0lwvqckX5OYAZ
         DcCS19k74gGlBliCPhy9ZQ8zVJAbJGyKfezkeQgEvDVqr2Ds8NXqJxfYrEYcBYu3UkBt
         Zs+wbb6yOyl1hblAtq2TXDqVGjEBvdKhk9RhJk6bFi91z1ISVr414rjLex8iuk1uY2e5
         QsXDatFsmwXVyqxDihZnzzOM0Axcc80Co1J8YPoMWd128rBXEmuk6oh48bi1e51/w+wi
         1aFaXRACGW+vZqCIiJW7xTy91n7b7SUrpn3wM7hVNOc5gMMVLUsgAHCTYfmEFojl1JIk
         fNgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758784457; x=1759389257;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=F2sXIVpQ2sRQqf9olGrpp/u0HOjr6xauSwIcL3FIM2k=;
        b=NJ4hxMTcrZ26aYCX7sAVHSM8mCVMEv7SK3jZuJ0sUMLc+ZkhcuR1ZoR6jtlZ7kd3fw
         PPDodDDfqYBb4b/UiukaVHA/NLGaIGngi34n+olBUgS+pRrnfuJg7dqTQtJrs/tWPG5s
         0VYl2PMyaaRz0QHztt6e+p9jlw7msu+C96D4ATve13ac/Xr96bwG1rAiaUaeBG6fXDl+
         z54E8VaDGLLKgGxgdUeNuVq7XGj6C/5xmhJNo006npewVKqNiEPhUW0xGa3TSK3tX3Rs
         XCXLMfr+YeWwTkUMwqSFpcejguY2+xbfRcPv+anzHDt4gosWcWEvtxE0JhQUkt8ybbMf
         0NgQ==
X-Forwarded-Encrypted: i=1; AJvYcCUWUDoxCXGdoXQhyS5UF/D+M1c0NTcV+tDBun5+EHbXNPH2liUYZL4mm16zL9xCJSzraMBcBN7gUmw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBYfviHVYeUlR5sVuTRB9W/1D5kxS4/iynLlKmUZ0LbrB8uth0
	bvqAI3b4LXBu0RYnOX5ZgruFh2TTXpivqcVDL6Vf+kBHmCTDdmxH7ZnWQctAkVREXQ==
X-Gm-Gg: ASbGncue4kF7bRxUby5AtLk/fSWUt7lPbrr1p1N/phuUitkI2fGknyS17b00OeWmczs
	/GR6fa41Sejl+rF/ym3Jkn3lLoBQylzXPfDif0cCzGQbnGCNaSCD3GQUivGTuF6Gz6uaKSY79w7
	5zNSHdXXT/2ZRXi+UHPjtPs04LpBw9O43afZBr7mLnthUf1xkHVqyqH0OAqjjfo2Z9ILTc8Gu1d
	8PxAN9rMCkHPbfhsm3DGtibFYJL7rP5aOvYh1ieFpN4+QG9tlGuSBDDBRqcMzB6h4hiX2FrPV7I
	0uGpTVFT895AQtx//hAM1+a6iPAK8OJ4OVJceQsd24oX9hs+NILcFrevoph2DzRpT7ft8mUotE3
	2qUJSmS1NdpGf4ZfNtiufP6ihZMTBRXOAcVJ9FmRdzDKUmnmUocIZb85Z8lWNspt832OSDWEnnc
	Jw+VS/qQ4KnUsjvAItmidy8omkb/Lqpl8XDEy0
X-Google-Smtp-Source: AGHT+IFMs4FlDj9UhXEMusS3nmd/2eu0qvNcfeL6FIUA+q5E9pqbKp7en4ff0YPxzegDbfwG3FwT+g==
X-Received: by 2002:a17:907:7f05:b0:b0c:8280:4f40 with SMTP id a640c23a62f3a-b34b7209e3bmr279727266b.4.1758784456843;
        Thu, 25 Sep 2025 00:14:16 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 09:14:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Ping: [PATCH 0/3] efi: Shim LoadImage improvements
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P. Smith" 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Gerald Elder-Vass ,
 Xen-devel 
References: 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.09.2025 10:24, Gerald Elder-Vass wrote:
> A previous series for supporting Shim's LoadImage protocol had some
> outstanding comments after it had been accepted, and internal review
> revealed an improvement to be safe when unloading the image.
> 
> This patch series includes those changes.
> 
> https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2032454096
> 
> Gerald Elder-Vass (3):
>   efi: Fix line length in init_secure_boot_mode
>   efi: Protect against unnecessary image unloading
>   efi: Limit Shim's Verify success to EFI_SUCCESS

Can there please be timely responses to small fixes like these ones?
Especially patch 3 wants to go in rather sooner than later.

Thanks, Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:35:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:35:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130035.1469683 (Exim 4.92)
	(envelope-from )
	id 1v1gVI-0005ZJ-3d; Thu, 25 Sep 2025 07:35:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130035.1469683; Thu, 25 Sep 2025 07: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 1v1gVI-0005ZC-10; Thu, 25 Sep 2025 07:35:00 +0000
Received: by outflank-mailman (input) for mailman id 1130035;
 Thu, 25 Sep 2025 07:34: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 1v1gVG-0005Z6-LQ
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:34:58 +0000
Received: from MW6PR02CU001.outbound.protection.outlook.com
 (mail-westus2azlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c007::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 22364298-99e2-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 09:34:57 +0200 (CEST)
Received: from CH2PR03MB5223.namprd03.prod.outlook.com (2603:10b6:610:9c::21)
 by BY5PR03MB4999.namprd03.prod.outlook.com (2603:10b6:a03:1e7::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 07:34:52 +0000
Received: from CH2PR03MB5223.namprd03.prod.outlook.com
 ([fe80::64db:a9da:5b27:8665]) by CH2PR03MB5223.namprd03.prod.outlook.com
 ([fe80::64db:a9da:5b27:8665%4]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 07:34: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: 22364298-99e2-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LNRne1WDxQqeeXsSiXeavoHQaWffC2q1VXI/zrt/AbJGxPn2LyKJiW0FzWdvDOyvrcAnbZx06r8yM/sdUKKg9KVMjytdAZvaFtbRAjSW+Zqwyt27mygNDlLBGWaU3k0LetJo+ZDt54pPoWeBAiDjtlaAZQ06uoH0C+mAW4szlspo2jt5Wz8/MobRxE/sL8dBBm0Odwqs/vFIkmWdyxq9J6Rhc8XwtieiMRYXIFVaXZq/YOms+xSlwlDuEIR+L+H1jVY8e2R7sqnAvPCMvpguNwExSv9G0qY9FK6jv58LLkj9G/kqxTcCanShjTj5WtU8UbHbq6rMda3+qM8H7aIZNA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tXF5asecZjQkbdkSLXxEXtiY2QfjGxz9zAvHG5v+R0w=;
 b=B9gZbOYaNPGa7d2w5eBJvCbTM5MX7a0eTH1snDqsw2Me5/DcyZSXwv901nyzlEbO6F5oAyGvoM+s95sJFFUXiThbLAFafnamY/fTRkWfdzeknFEBS1vwsmXFvmKrP2WhxiD9uIBeI3my+v3/QWKZdlTkXrsPSi14a2VdiAaX80Bc8EXMK3BuDNwrFeBR7spe+V17CtJRZOGPhiZCzn/JXQ97u2xu325W6ubnISzehJrV2VVCbSZ4FtvvLiTuoEnPk0AFHoB0fnMkg6SjsE1w3K5b3K5LteiRzsfaJurkNQVWqmA8KTxbiJHs/rtaBaOvTV425qXgacZXJpN1lGztjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tXF5asecZjQkbdkSLXxEXtiY2QfjGxz9zAvHG5v+R0w=;
 b=yNaQBJ3ATpeZC0X7hGZdu7baqZYaR2BLTQYwicleCUDrcIOPQZf4idA1pRMGB/KWAyeXDOInIfJGIRNF8+RkJjFoNd8M5xRuLRrJTc+ci40Erxsv26j4XgzeDJkmtZH3T3ZkKcWBOiUsyxjmzXlWfYZOJycDZNmCRH64/ceYqhM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Thu, 25 Sep 2025 09:34:45 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	"oleksii.kurochko@gmail.com" ,
	Andrew Cooper 
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
Message-ID: 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
 
 <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
X-ClientProxiedBy: PR0P264CA0113.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:100:19::29) To DM6PR03MB5227.namprd03.prod.outlook.com
 (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PR03MB5223:EE_|BY5PR03MB4999:EE_
X-MS-Office365-Filtering-Correlation-Id: 644c952a-85ef-474c-7901-08ddfc060374
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?OXJYM0liejVYVVlTc2w3UXlPY2pEQUo1QnZ0Ri9sS2NzQ2k3YS9SYlFXUkpV?=
 =?utf-8?B?WjZUVzI0R3BJdkJ1ckxNTEpHZzc3R0E5YUFFcm1mYkZ1eHdZU3k5RVNOaWc1?=
 =?utf-8?B?cElRSEFrMEY1WVQzbzE5SElzRXNmWFZPeEZjZjlEY0l1cGMzbkpJeGUvM3Ex?=
 =?utf-8?B?bnNjSU9iYXQxT3FoS1RDQStQQm5zZWUvOWpWYzNQRE11ZGFTbHpsWUtlTzA1?=
 =?utf-8?B?SHZ2L2NaS2lhcVpwS0VOaEphMU1FNXY1R01sTHBWOU96YktIYWMxMG42Z3Fj?=
 =?utf-8?B?OHUyUVBCSU1NdVV0T21ZaGcrRXlJQVVSOGpkMUV2cVBQbHAxVXh5RktWNDFG?=
 =?utf-8?B?R0JpbjNMRW41Y3d6K0ErVzhJWVZyd0g0eE9DSkoyRWhYWWw0YTIyUWp1TXI3?=
 =?utf-8?B?a014VU5ENXMxc2djdXIxdEtkNzVPSVErQjF2ZUpYZGQwZ3JiTTZDT1BIcUZj?=
 =?utf-8?B?Y1N1Y1BTK1lPd2JaSWJzYXAzcDVpbnhadGxGK0R5UEljNldMNEJIQVpqQ08r?=
 =?utf-8?B?ZE9YdW5YdmdpTCtvVTVIbXBMNzdNVGVQSktWdnpNNXY5WDJDaFNMWEMveFN6?=
 =?utf-8?B?aFdKbytlUWxlUkppMjQ5bDlIV3paUk9aVlRSdmliUWRyNWI3a1NZNTVpWi9X?=
 =?utf-8?B?cTV2RUJWUmo2U2h5QVR4M3pwYXNMbDZ5dkFhVnZmcHVvb2xwYzBkS1pZejR2?=
 =?utf-8?B?V2JyNHFqTDFGL1o3dGtXN0dHQU1IU3NQNzlGUmJCMVlSelV2dS9la1F0TFht?=
 =?utf-8?B?Q1V2Vkc0ZDllUTltRVZ3VTRRZUJKTWg5WjZKaEN0OEVVTTJiT1BUbklSSXpz?=
 =?utf-8?B?UmRob2FTRjVldnhSQUpKOGhqQjNOZXBSRlR5OFpsR2hna3dlZ3dlVnBRUVB0?=
 =?utf-8?B?MzJzTDB3Sk5yak5jTUNxR24rUXFzT2dGd0ZDRVZ5VjNEZE8rK05CcHhCaEhy?=
 =?utf-8?B?bkZCODd4dGFod1dmZTNLV1hNT3FRa2VONTFOeCszRmpZNUtCTVd4RXcwT1RX?=
 =?utf-8?B?NnFXdFIzTTBoaTFLQWdpSWloMUh0SmkxNnBBZ2dRdmpRaXd4Vm8zbzE3aEJa?=
 =?utf-8?B?QW1jMkpuSVMxM0NqbjQzQW5rdzh3VHNDZDFUYXFTVFQ1NkxlYTcvSHlLM3V2?=
 =?utf-8?B?d05ueWdRZDdEemVVNFB4VHdnL3h1N0V5QVNTWUlFOHNvbDFUbWVya3B2aE9T?=
 =?utf-8?B?QTRoSndENityQ2pBcUpXL2lLeTlFTTk0RU9SUjRJY3ZOR2JzYWdCT2EwaWR5?=
 =?utf-8?B?VVpGck5NN2lDZ3FvOFg0d2JmMHN3bU9NSVJMaUErUmE2SEpWbG9uT0o5QklZ?=
 =?utf-8?B?amRnQXFHU0VrVmt3dHVSVXJWWUF2S3Y0ZGNSaDNmRW44UkhLWEdBWjJ4VWEv?=
 =?utf-8?B?bng3dTIrSVJNTW9PRDk0Rlhhd1dCYmM4NnRJb255RWxwWkg0M2wwczVwQzh3?=
 =?utf-8?B?THVOVUJNZWJuTFZLNExwTHljVlROUXRJaXJXT2prdm9LYUwybGVKdW1ZbWov?=
 =?utf-8?B?dGMyU2xDUi9YQ1hTbFNxQWVpUWdwMjd5UmpqNW9POXNnN1pwVFJPODZ1T0NV?=
 =?utf-8?B?WHFlV2lHazZMVWtLVUllTnlYZEFLaWsxYkNyL1hndUluU1JrNktueVJNZlpy?=
 =?utf-8?B?YmVQejliczZYM05ZWmlvRURZUlE2bUh0dEpGNVN0bUw0T04veHJOY09TSDFG?=
 =?utf-8?B?YitXZmtOMXpPME1JRk0xbGJsMHdzR2RpQzZpa0s5OTNDcHJiV3dSVnNwNkwz?=
 =?utf-8?B?WkVmb0hEMkN4ZlpvMGxkVGtJYXhQVnExRGNaalFhaXhDVHo3TVJvOFh5eEY1?=
 =?utf-8?B?T0YrMWxMdTVIakRKS0tnZlNPZm1KWDg4dWl5b1ZjNXdRWmJQZ1RHbDFZRUtx?=
 =?utf-8?B?V280cFNYajg0amdJQUd6T2dKbFlheE42Z3ZJZk15dTBmdkJvc1JsVnViazNT?=
 =?utf-8?Q?7rIVf3sCBtQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR03MB5223.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?c2hscGVqWnAvc1hYYU5mZGdwd1paVWgwY2dwVDE1ZmR6eXBUWmZVSExSbFpr?=
 =?utf-8?B?bVNXbUY4a0pGTE42c09GaHF2SG9UcmZwM0RFbnVsYzFFV3lFNE4xY2lOSDlq?=
 =?utf-8?B?UHFBbitWNkluNkY1bDM5dkZndW82ME1rb24vU1dvY2JxQXR2djVUVE1rNXVk?=
 =?utf-8?B?MlBVVGdiSC81ZlMzQUZpZ2daR21ZTGg3QkxBOXJvM05xZzZKbHNUTUloY1dH?=
 =?utf-8?B?VnZWL0JnMjFxY0EvTVFPUENyd0xtb0pJemNPODU4U0dsN0F6L2o2anphTEtp?=
 =?utf-8?B?YmhRYmJLRXhnTjVFN1U1UUpnazlIM1dzUlBScGlibUhYODRIWm9WL1VnYUhF?=
 =?utf-8?B?a1VQY29Id0ExUVFDeW04VDU5MUE1YjlCOTZheE9ZVUdhdG1FUUtESW1sTE4y?=
 =?utf-8?B?NldoMVREUXpHRno1YkZ2UjNLTDFpbWV4WTZMTTRaVkVPNVFvam9UNW41dUJa?=
 =?utf-8?B?ZkI4Lzh4TTRDcTltMTBHRUNKUGVWdXZkMEVmYU1aMTBHaGJ1QmZndC9iT2I4?=
 =?utf-8?B?ajJZa2t0QmhWS2tYYkJHendhS3dqWHpvcFk4b1V3d210a0hLL3YzRWtPNk5i?=
 =?utf-8?B?Rmw5OGpDUmJQY0Nnb1JHY3VDc09XRUV6Z21FSFZuMG5NU0tLa0lKMHllbHZs?=
 =?utf-8?B?S2pOY0pkMVFwMnhnWHlmSXJFUjNibDBqTkF2T0dXcURtaUwxbDhtRkp1Q1NF?=
 =?utf-8?B?N1g4ZWVJMFZNVjFNVXV4bmRVbnlzQ2tQTFpPZWhVNVkwa0xiWlZtbDN2d3F6?=
 =?utf-8?B?Q2orelhWamo0YXRXSUVPR2xNd3VUZXAwY0EyakJvQlVlUkh1S2JoZnFWR2NR?=
 =?utf-8?B?N3BmOUMyai9uQm9TTTI4aGZyNS9HRUZIL3NlKys0WVJhcmJVb05nS2VNQmlt?=
 =?utf-8?B?NnhSbDUyOXd5NTlSWjhndWdkeTJHNWFldlRlMXhiNEZzVGdSMys0dXppU2wx?=
 =?utf-8?B?aEg4UmxGUmhIemxDVXdPVU5RT2Y5YTF3RFVibVJITkxua2g0TDd4UWRWSVpF?=
 =?utf-8?B?MmZTcmVBeFhTL2RtQVFMTG9Od2NhNHdqMTc1QUxBeEQxM3lRS3ZBOVAzbTlU?=
 =?utf-8?B?VjR6OTlCWFpITnpzbXNtbXA0RjJLWFdwallLeVZZdUtlcmVPWFExRUZYK1VF?=
 =?utf-8?B?Qk0vWWp4N2REbDBuVFVzZlZNOXBqWmlVd3k3MnhmRHZTejVTOTFUdDB5Tmc4?=
 =?utf-8?B?UmtWcDRqVndWNkNhNkZPQnprNlVqMjhhckZtNzV2cFJxM2gwczdMemJFajFO?=
 =?utf-8?B?dmxBOEp1QzJocW40QU1IQTd5ME5mSk9EZGVHSzdONnJIQlRpSDJUVHdqU0Vt?=
 =?utf-8?B?TEN5L1FOTXVvNzYySndOa3U5MGNxZFpFZUNFNFZOM01zNHdiaUlkSTkzM3Av?=
 =?utf-8?B?VkZnUHNVNm9CUWkyS1FYYzcrNUovSjNtU2NrZVoycXF3dmN4REJqYkMxd2dm?=
 =?utf-8?B?YTYvNHZ4SE1pOWg4SHc0Z1ZZM050TmdaS202L2lvaFRpWjZTM3hjVlgzK05X?=
 =?utf-8?B?Nm1NZUtBZHJpL3docms5dURyYWx4QnJXQUc3VEN6MllvSXhZUUxLV3h3WlVw?=
 =?utf-8?B?NXVQRldGcVZWN3JYcEhkQkpSaE1aM2UrcG1JaTdpQ0w1UmthN2k3ODZRUkFv?=
 =?utf-8?B?bEVrZEppVUhNNmtMSktEZWYvS2lJeERLVzBLQW9vS21oc0hwTVFubzFYMlkz?=
 =?utf-8?B?c3RTWk4wL2J1emNyVjJtREVEV1p3aG82N0liMUFVWUhuVm03elhNZjNseUhq?=
 =?utf-8?B?dWxDOGdHUUdhcm1sRlU5ZlJjNTJxaHVpTUhLZTM3Q2pWL2J4dHJOaU1CU1FD?=
 =?utf-8?B?bCt2M25ZaUdnN0JZVmJuUytGZy90Q1VnaHhWRjBWWEZQbHZaVnNyUWlzM1By?=
 =?utf-8?B?SjhZUnpWN3NhRUdWY3hDLzBKVmF4ZGVuenBzZXJOVG5rQUxWNUpvN3R0WXFB?=
 =?utf-8?B?TFJDNmdYZ1NtS3lUa3lSQVNDdVhneHNDY3pINUgxZmpCeXhWY3J6YXFqT1cv?=
 =?utf-8?B?VDhuSDVXSkRvbkQrSHpFajc1ZG1wNGprcDBJK1pKQjJMTUthc0RKb01jSmhn?=
 =?utf-8?B?U25hczg5QXFRWWxnRk9pQ250ZEVkbG1TczFJaHRCcmNUdnRQaVVwSWJ0YVFj?=
 =?utf-8?Q?yFuMBEvkS3dxF/RGMPrbZPT0k?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 644c952a-85ef-474c-7901-08ddfc060374
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 07:34:52.6954
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RdlkJ8XuVYcQ5RJjXy1f2QpK9WZw8xmSr6NYFgvKUob8ctVVy5qATtWkr/Z+PxVMQ4IqAYne6CFB8+sf42ROTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB4999

On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:
> On 24.09.2025 15:40, Roger Pau Monné wrote:
> > On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
> >> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
> >>> Otherwise the check for the SS feature in
> >>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
> >>> X86_FEATURE_XEN_SELFSNOOP never being set.
> >>>
> >>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
> >>> identify_cpu(), because SS detection uses boot_cpu_data.
> >>
> >> Doesn't this, mean ...
> > 
> > Well, that's the reason for the rant here.  The reset at the top of
> > identify_cpu() has been there since 2005.  It's arguably to make sure
> > the BSP and the APs have the same empty state in the passed
> > cpuinfo_x86 struct, as for the BSP this would be already partially
> > initialized due to what's done in early_cpu_init().
> > 
> > The underlying question is whether we would rather prefer to not do
> > the reset for the BSP, but that would lead to differences in the
> > contents of cpuinfo_x86 struct between the BSP and the APs.  In the
> > past we have arranged for leaves needed early to be populated in
> > generic_identify(), like FEATURESET_e21a, hence the proposed patch
> > does that for FEATURESET_1d.
> > 
> >>>   However that
> >>> creates an imbalance on the state of the BSP versus the APs in the
> >>> identify_cpu() code.
> >>>
> >>> I've opted for the less controversial solution of populating FEATURESET_1d
> >>> in generic_identify(), as the value is already there.  The same is done for
> >>> the AMD faulting probe code.
> >>>
> >>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
> >>> Signed-off-by: Roger Pau Monné 
> >>
> >> ... this Fixes tag is incorrect?
> > 
> > I think the Fixes tag is accurate; the code was OK before that change.
> > Nothing in c_early_init hooks depended on (some of) the x86_capability
> > fields being populated, which is required after the change.
> 
> I agree. Hence:
> Reviewed-by: Jan Beulich 
> 
> I wonder though whether while there we wouldn't want to also store ecx if
> we already have it. (Really there is the question of whether we haven't
> other cpu_has_* uses which similarly come "too early".)

Yeah, I was about to do it, but it's not strictly needed for
c_early_init, and it's done anyway just after the call to
c_early_init.  I can set that field also, but then I would need to
tweak the comment ahead, something like:

	/*
	 * Early init of Self Snoop support requires 0x1.edx, while
	 * there also set 0x1.ecx as the value is already in context.
	 */
	c->x86_capability[FEATURESET_1d] = edx;
	c->x86_capability[FEATURESET_1c] = ecx;

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:36:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:36:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130052.1469692 (Exim 4.92)
	(envelope-from )
	id 1v1gXA-0006Ew-Hd; Thu, 25 Sep 2025 07:36:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130052.1469692; Thu, 25 Sep 2025 07: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 1v1gXA-0006Ep-Er; Thu, 25 Sep 2025 07:36:56 +0000
Received: by outflank-mailman (input) for mailman id 1130052;
 Thu, 25 Sep 2025 07:36: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 1v1gX8-0006Ee-Oy
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:36:54 +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 60762e79-99e2-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 09:36:41 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-63163a6556bso1314191a12.1
 for ; Thu, 25 Sep 2025 00:36: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
 4fb4d7f45d1cf-634a366116esm756513a12.21.2025.09.25.00.36.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 00:36: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: 60762e79-99e2-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758785800; x=1759390600; 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=o+vmBTrttjFBsGU7mSbaGhj/zdpSBS+dYN95fMNlirQ=;
        b=M6sdl6nMUgaMVzGA0Zavanz8QhlBOjVBjkZlgmpc8m6szJlX4DQinmwGbFds9C8oo0
         E1J6lCJeazL9t7GflFl6eettqZzyQz7g4EvV/PZ+XzDuX1yHD4enUWrd6E2OmqsJIdgI
         Syh5MWDHwrkffkPMAQtFO2Fc2JRXbNw9e7jIjoylcmkTk+3oAsIY7nxFXLGzLyh49aTq
         igCpogcTHXr8trKCOOf6blto+SWlrlSZtyZaRBaO3R+tbYbfEbDJ1U718mYk2frGmDOk
         Q0bqcXL6yOBE87C7mD4g2/SMvCcDWnqKVTJtRQqfq7w1yeeZWsAeUBpEbiOcbCJDFemr
         XL4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758785800; x=1759390600;
        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=o+vmBTrttjFBsGU7mSbaGhj/zdpSBS+dYN95fMNlirQ=;
        b=hg+3FDO/9A5FZFJzxmCf7PWIl0yP/ax4AOWb3AGtGwvPS9z2zQ+qgwwQ+/XO6zwa1J
         2h44abhv+tjBIMuP0Gxp/vi89br0/PVBA5y+YlKoZW1nKRVSXBR8GLWLZizoHTT+MV01
         3H7E+yM3B0aAQnPLEbJmLcQvueMql8uLf+xrm8yFdvmhWAeTb+Tsqb+CbAaddoTHwJyl
         2pFYPmMGX1zTnE3xALl0DKZ2w87OUVWT4WqGBhVxbu5SnM1/z7OpnkTiViPz8b9O+hur
         0WJP9mVxJJDdFgVL6dXVlFG4C9rsG2KUYxFE1Vf7CyEnBAnli0hn0yzT8IXRMs1xC5L6
         LiRQ==
X-Gm-Message-State: AOJu0YzjTcHOhozNY8rkbJdgnjCrQsAovdAbps2XMC3JL5QaRpLSyXRs
	n4ji3qHnajyPfgdK0kxZf9qJAC6G9rRA/0sDIujfym6nSQ8H4EhFcqXkpIqHM5xmDg==
X-Gm-Gg: ASbGncs8UWFeVqwN/ihbQ5O/y4JAlxsvlu/qYRku0eItwtqgcPkUkbJOxAqfg96WGPx
	aexCzjtjePpyv06+3a5CyYkVA1qMwmx3/yNZXJaLtUjmDYaflVb1BilUykJR6Cm0g+/D5fcylwF
	yfHCSIHc9iIJEru5eg34G8hlB17KRsg4ztXd1Zt4QFN5YE8qBPNFJNBAb0tMTkNZ2j0L7zo8uIc
	1j4e0QATVlgXn/3yxAVp87lITY9kve/n2ydKc48sOLJHKjGyibbuUMDnYSjIXLendSGBo/DdU6G
	rn5uA+BbSDf4DF3j2dNh3f9ogd4FdetBNyV2jaaMoJSYBmcamWh76ZJQEuNDP3DdytkLPffQEnR
	DdxzaWdamKNz39mU200nEyu1lB+ysu3xKK7qSBJ1NZmE0rHDgkjUEmH7NCcjqO0cWS6F2o3/4oX
	E1sKZHB2U=
X-Google-Smtp-Source: AGHT+IEJQcNsMEU96TbCtf1DQwSR6UxFle5gquwgY/P1j6ERZA+7+A0lc2B2YVV/C6Bi2FNkaVMMXg==
X-Received: by 2002:aa7:c993:0:b0:62a:82e8:e1f6 with SMTP id 4fb4d7f45d1cf-6349faa698dmr1440511a12.36.1758785800418;
        Thu, 25 Sep 2025 00:36:40 -0700 (PDT)
Message-ID: <6fb3e095-172e-4cd4-8c26-60be6c5de704@suse.com>
Date: Thu, 25 Sep 2025 09:36:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Ping: [PATCH] symbols: discard stray file symbols
From: Jan Beulich 
To: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
Cc: "xen-devel@lists.xenproject.org" ,
 Oleksii Kurochko 
References: <2412a7a0-bdcd-4647-8ea2-8d2a927dcde3@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: <2412a7a0-bdcd-4647-8ea2-8d2a927dcde3@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.04.2025 11:00, Jan Beulich wrote:
> By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
> when linking xen.efi. Due to the nature of file symbols in COFF symbol
> tables (see the code comment) the symbols_offsets[] entries for such
> symbols would cause assembler warnings regarding value truncation. Of
> course the resulting entries would also be both meaningless and useless.
> Add a heuristic to get rid of them, really taking effect only when
> --all-symbols is specified (otherwise these symbols are discarded
> anyway).
> 
> Signed-off-by: Jan Beulich 

May I please ask for feedback here, so that hopefully we can have this
sorted in 4.21?

Jan

> ---
> Factor 2 may in principle still be too small: We zap what looks like
> real file symbols already in read_symbol(), so table_cnt doesn't really
> reflect the number of symbol table entries encountered. It has proven to
> work for me in practice though, with still some leeway left.
> 
> --- a/xen/tools/symbols.c
> +++ b/xen/tools/symbols.c
> @@ -213,6 +213,16 @@ static int symbol_valid(struct sym_entry
>  	if (strstr((char *)s->sym + offset, "_compiled."))
>  		return 0;
>  
> +	/* At least GNU ld 2.25 may emit bogus file symbols referencing a
> +	 * section name while linking xen.efi. In COFF symbol tables the
> +	 * "value" of file symbols is a link (symbol table index) to the next
> +	 * file symbol. Since file (and other) symbols (can) come with one
> +	 * (or in principle more) auxiliary symbol table entries, the value in
> +	 * this heuristic is bounded to twice the number of symbols we have
> +	 * found. See also read_symbol() as to the '?' checked for here. */
> +	if (s->sym[0] == '?' && s->sym[1] == '.' && s->addr < table_cnt * 2)
> +		return 0;
> +
>  	return 1;
>  }
>  



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:37:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:37:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130063.1469703 (Exim 4.92)
	(envelope-from )
	id 1v1gXs-0006kN-Pr; Thu, 25 Sep 2025 07:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130063.1469703; Thu, 25 Sep 2025 07:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1gXs-0006kG-N9; Thu, 25 Sep 2025 07:37:40 +0000
Received: by outflank-mailman (input) for mailman id 1130063;
 Thu, 25 Sep 2025 07: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 1v1gXr-0006jh-Oe
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:37:39 +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 82d9d2ac-99e2-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 09:37:38 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b2e0513433bso109453366b.1
 for ; Thu, 25 Sep 2025 00:37: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
 a640c23a62f3a-b35446f7506sm107325966b.52.2025.09.25.00.37.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 00: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: 82d9d2ac-99e2-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758785858; x=1759390658; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7Xvx4s58dldW+GlipghvEvDWsOe4ZLY/FBatQDA7RN8=;
        b=N/AeIbE90ehi52GduOunb1hFw22N+uxvC1Wtqf8LO1rAMgcVsaUfR9fjU/YhL8eWjv
         w5XR/ffhPmMbXb7cxek3UIgXBTBHIR3GtCK0RTt08yPWFN+jsatPk7BHrvuOH8vFz+YY
         vpmWiIS9ws2E5Mu6bxjZeAC7l44yZUF+SwXDkb4Z+XZ408azn0JTPrj0Fs2w607hSGDm
         oz7mBujhxVmdrYoIDwI6PQ9KS749UmOO83MA3fh8aXhSAPbkeK9gs5Vpen75eRJbF4QJ
         Dqf6LppfEzRneutCjzU/ltcYaL5X25zkN4zX+qH7A3Ig6m5XVkf/Qe/83MHjDgHAOsS0
         guQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758785858; x=1759390658;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7Xvx4s58dldW+GlipghvEvDWsOe4ZLY/FBatQDA7RN8=;
        b=dl2tPVyjUUQV0wt5KD+OSdl9uviJu9nyfqpsj3QEo7fwQ27tNKdJHAQr5K2774dy+r
         MuTdfX9tG/7zeW+82lOLzCOx6Lo3t3dvTlYeilOwvSfVuGrVBsRkmwrUcxJibC/c85ir
         25LrFrXKfTdNDSf35qalcZamARbOFVRU6liVBsqHN9g3pALIuZM+G+N98p04kLqu4vOw
         JedBZUVGE1kGTeLp0rD6Nu3ydkqnQmJ91qk9TQVX7L1UB6+NmkYg6q8vyPXkEAEC3/Uk
         +8z8nziQ2VldK7+HRlE/f+hKkKOe1rnOrJQHqi8eGAL0hziz6kAIif9q0IoY9MC+kA/b
         5WWw==
X-Gm-Message-State: AOJu0YzjVtgYzrlZGCoCIGwC+HfCKT+UyonJnxs4j0qH6PSb0JNkR3uW
	YVA18zIAo1iGJQT/QnJCaO7H9TKaar3x9QdwKH3IdkLufRqRi0IcfXVrHoabmW3tww==
X-Gm-Gg: ASbGncv9sXpRhp7Af51dzcI1mMfywWmDULYzMXWwWbhng74oZL+WAMACh9LB5b8pOhL
	qvXFMbKr8zsg6svOGnwuhCyonAaZgWU92nCqhDaOg57Yi2diDQmG/xoCauv+brfBafiZVLr2wl+
	g8un/QBRN8J8JqWeXEfPF90NqTMdO5TyjwHobKnq53anV3z0zLrWWe4kuQa+YOYe8ygjJNzoCSO
	RpuGH+6yCUxCh1qy6Jq/ziEb0LC+GuJduiGWUSioCuJ4Y82vbTvgOjGi1IzHLRBADmnxECzlpb1
	WH5k1HZUsNHTJ/Do55OpozWl9by9wyhidTYMKWru/TvqlXFWqLvRkDZHiTHK8O09PeXZ6ZGXekb
	6H9XiI1yqES9jNUDYVjePIF7/eaqYZ1d7jepQQnByIR1vHQBeEfGxtNZ5ineZp3Dcv33xtDAUDw
	u6bEKA3Ws=
X-Google-Smtp-Source: AGHT+IENSUcX3TmRxiupZ7nlZ5fxcIh1147qMW3Yztr4ZA8VNammjLuiigVsM6EhOPa83h459kHx3A==
X-Received: by 2002:a17:907:97d3:b0:b07:da17:79fd with SMTP id a640c23a62f3a-b34b9e59f5bmr247281166b.17.1758785857936;
        Thu, 25 Sep 2025 00:37:37 -0700 (PDT)
Message-ID: <1083faae-d565-48ab-8e41-3a5a12178a9f@suse.com>
Date: Thu, 25 Sep 2025 09:37:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 "oleksii.kurochko@gmail.com" ,
 Andrew Cooper 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
  <3d45a9e8-a836-46bf-a3bc-321551ac755b@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.09.2025 09:34, Roger Pau Monné wrote:
> On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:
>> On 24.09.2025 15:40, Roger Pau Monné wrote:
>>> On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
>>>> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
>>>>> Otherwise the check for the SS feature in
>>>>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
>>>>> X86_FEATURE_XEN_SELFSNOOP never being set.
>>>>>
>>>>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
>>>>> identify_cpu(), because SS detection uses boot_cpu_data.
>>>>
>>>> Doesn't this, mean ...
>>>
>>> Well, that's the reason for the rant here.  The reset at the top of
>>> identify_cpu() has been there since 2005.  It's arguably to make sure
>>> the BSP and the APs have the same empty state in the passed
>>> cpuinfo_x86 struct, as for the BSP this would be already partially
>>> initialized due to what's done in early_cpu_init().
>>>
>>> The underlying question is whether we would rather prefer to not do
>>> the reset for the BSP, but that would lead to differences in the
>>> contents of cpuinfo_x86 struct between the BSP and the APs.  In the
>>> past we have arranged for leaves needed early to be populated in
>>> generic_identify(), like FEATURESET_e21a, hence the proposed patch
>>> does that for FEATURESET_1d.
>>>
>>>>>   However that
>>>>> creates an imbalance on the state of the BSP versus the APs in the
>>>>> identify_cpu() code.
>>>>>
>>>>> I've opted for the less controversial solution of populating FEATURESET_1d
>>>>> in generic_identify(), as the value is already there.  The same is done for
>>>>> the AMD faulting probe code.
>>>>>
>>>>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
>>>>> Signed-off-by: Roger Pau Monné 
>>>>
>>>> ... this Fixes tag is incorrect?
>>>
>>> I think the Fixes tag is accurate; the code was OK before that change.
>>> Nothing in c_early_init hooks depended on (some of) the x86_capability
>>> fields being populated, which is required after the change.
>>
>> I agree. Hence:
>> Reviewed-by: Jan Beulich 
>>
>> I wonder though whether while there we wouldn't want to also store ecx if
>> we already have it. (Really there is the question of whether we haven't
>> other cpu_has_* uses which similarly come "too early".)
> 
> Yeah, I was about to do it, but it's not strictly needed for
> c_early_init, and it's done anyway just after the call to
> c_early_init.  I can set that field also, but then I would need to
> tweak the comment ahead, something like:

Sure, i.e. fine with me.

Jan

> 	/*
> 	 * Early init of Self Snoop support requires 0x1.edx, while
> 	 * there also set 0x1.ecx as the value is already in context.
> 	 */
> 	c->x86_capability[FEATURESET_1d] = edx;
> 	c->x86_capability[FEATURESET_1c] = ecx;
> 
> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:40:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:40:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130078.1469713 (Exim 4.92)
	(envelope-from )
	id 1v1gaQ-0008Ib-47; Thu, 25 Sep 2025 07:40:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130078.1469713; Thu, 25 Sep 2025 07: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 1v1gaQ-0008IU-1N; Thu, 25 Sep 2025 07:40:18 +0000
Received: by outflank-mailman (input) for mailman id 1130078;
 Thu, 25 Sep 2025 07:40: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 1v1gaO-0008IO-Pk
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:40:16 +0000
Received: from SJ2PR03CU001.outbound.protection.outlook.com
 (mail-westusazlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c001::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0173e79-99e2-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 09:40:16 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by SJ0PR03MB6533.namprd03.prod.outlook.com (2603:10b6:a03:386::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Thu, 25 Sep
 2025 07:40:10 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9160.010; Thu, 25 Sep 2025
 07:40: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: e0173e79-99e2-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j/jKWvZt+Ozz7NkF50R6zA+j6iz1G4Q4Y/8BBAFMEcd14C/hlxsC1+d0WeE8GQBjfXI03gnvzIOACGMt9BLB5T40fVMJ5GEx0zpam6Nn2iVqt/LvhmsHQta8xypAlhBp1C0vtc4JtIxSJdlmy9i/fCppf54K8as2JAXUip3bWPWCjKV8gpUHXaFXCmYx39dF3SFfZq8LShvPhegM6bFkcH7LmzNDKiz1W8q0L4OoK16RIjXjA4kh0L+VHB9xJNsO+jUaRdq+5EPb4ek8f9rxn6vQT/nqsA6q+lR+8Y0OhDH9sdLo6rgBsssuWMu1j4gSN2qLUOapvPFgyPxOfcq3GA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5COQ8dcTyJJGWWOqKjJlSNFbCc+dGX+wai3hyaQme30=;
 b=uYAonev2KJoZzHgbMaGI4C2eqJcOk4bVyBUsieB/AKszOTyYdpzAJFdSTkPl72Gq3g/sDtpf/B3/iXpFq/4EOW53OpPZXaE5EstHDlwEH0Qfni6y0L/Ev7cNOh7P3mnOoVxV1A/CBGgiNUIRJFl2dtuDxKCtkJJ88yJ7T2etlxSvdX5/fx2a+8RGBg3G3+f9+gujhgxhbbzI55K1MGjduJHZSlPPtdloU7hIWfYypQ9X9RGYJuIz4sZY+aT2ontG7nYLkkel2mesWZH5GyUQA4MumoTNLdW9l9bRe1XS6pIDbqW7S6cbQLjublemW9G0XxG4cL/yZP7AkcldFiSCxw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=5COQ8dcTyJJGWWOqKjJlSNFbCc+dGX+wai3hyaQme30=;
 b=XGPLfEB8s00z5MOPaTy5FVmET159a8SNag24d8E43SPIq6+eBRSqWCtkCedfcsXZkVoR7q4mNfRY2Jh8pcReRkt8Jj22BTrqVTlS+QQreMW2C88yD/jHnWQFBRddBJ1y0vt4M+D2ZoVJdL6FjIdTc343u28EsVQ1C8fXEEDsb3s=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Thu, 25 Sep 2025 09:40:04 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich , oleksii.kurochko@gmail.com
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
Message-ID: 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
 
 <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
 
 <1083faae-d565-48ab-8e41-3a5a12178a9f@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1083faae-d565-48ab-8e41-3a5a12178a9f@suse.com>
X-ClientProxiedBy: PR1P264CA0064.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:2ca::16) To CH2PR03MB5223.namprd03.prod.outlook.com
 (2603:10b6:610:9c::21)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|SJ0PR03MB6533:EE_
X-MS-Office365-Filtering-Correlation-Id: 94e09975-b712-4c33-4642-08ddfc06c0ed
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?dHJsNTlWUzZaTVduQ3ZVL0xpQW05L21vV2RiZEQ5SVhQNStTVVZlMVE4ZnZI?=
 =?utf-8?B?WTBpZHp0WFJLRnMyMW1xcHFrTEo2R1ZjRElTdDFEQ3ZMT1pWckczQzdrOWsw?=
 =?utf-8?B?L0xhN3p1RFI5OXhjbG5pdEpGM1FVU1FseWo0L285bFpQdmpNSUVTMmhHNlVi?=
 =?utf-8?B?a0JBSG0xQW5adHB0SlJidHd0M3Z5cGZSUGJXeUc3cHo5dlgwZnJ6c2tCSldx?=
 =?utf-8?B?SjJyQmcvYUdJVzUySkQwbEFDVDloT0QxUzBLcnZNT1EzNzJiWUFDS0kvN2NY?=
 =?utf-8?B?c0J2WjNja3Zkb2pSajRtSmNxcDdoMDkxd08zNWp5eHRxWUJDTmMrV0pmbHV0?=
 =?utf-8?B?dis2U1BwR0YwUW9pZldMckI4Skg0SEVST0JFNDRXc2hKTGc1dFI2MUcvNmNY?=
 =?utf-8?B?cHpQZm9zK0pHNStwTnNyc2diL2RCNEdza05wQU8yOXNTVSs0emRFaFY0MHoy?=
 =?utf-8?B?a2g1aElLbUtyVHFQWThjQm9vWENpaEFSNlI2NkdiK204Q1lBUG8zd3Bka3RZ?=
 =?utf-8?B?WnVUcVE0eGRBekZrdm0wOW9IY1k0Mm5hdC9mdUlJOEtxMTJRV01PQ0VGNDI5?=
 =?utf-8?B?Z0FMUXhyZkl1MmFyVU9tdUUwV0xGYkdxemFKZ3BIUFJYYWFGdjU3cjZyaGlU?=
 =?utf-8?B?YnBleUN4Vkt2VGZhMFZyTFAyblVORGhsNmpvdlNXVlhJTHBlaVRINDZ0aWQr?=
 =?utf-8?B?SitjTTR0aTR6S0s1UzViRElJRURZR0E4R3pHNUVVZ1lTMkkvc2I3UDBMdzZC?=
 =?utf-8?B?ZUxZVGVSeVJDbkZDSWc4VGdIa3hkMTM3OElZOXhpdnBvVzFDL0JDdDlTY0VN?=
 =?utf-8?B?S2RxZG56azZRQ1c1Q0N2TjVWLzkxUkNXMHRyV01ZQ0p5NlAvL2k2ZEU5UHlt?=
 =?utf-8?B?dlNLMTVzd3pOeGZGeFl4N3FXWDZKK2t3a2cxOEU0alB1MDVtZ1h0Ky8zMko3?=
 =?utf-8?B?RUZaTG1qSTN3NVppMkk1TVRwSHV6c24rZFdBa0t5SDZ4ZDRpcHc4VzBSQk5o?=
 =?utf-8?B?enFjR0tTdzJ1NmVQVWc2RXJ4dmpDbko1cWZqbGtpUVF0MElZM1BzZDdoMGtF?=
 =?utf-8?B?TklIdDhjUjBxblpmeXFIZVBpR3ZrWFNlN2Y3N2dUdVdRalowK3JlV1lNVXMr?=
 =?utf-8?B?WjQzQXo0ZzJJYXJHZ0R2M3FxR0R3NkpIVlhaZWhFSW1LUjhXTXY5OWZHc0Zq?=
 =?utf-8?B?U3JTUGVuNDdXcklaYzZGdWduR3NQbmVpWkxWMU5xUDhNODRBai9ZQ0NEVzdR?=
 =?utf-8?B?b2UyU3dzNHJYV293WlBiemRSb3NUV25JeUJ2Y2pURGNwV01IWFJ1ZEF1bitF?=
 =?utf-8?B?Tmhzb3FaVzZneDNESEhib0puMnZjdW8wNysrUDBITHZiM3V1RERrR0luT3Bm?=
 =?utf-8?B?SnRoNGZFVGxtVjNRcWYwSEJRejk0WE5TRTFZdjM2dy9kdWx5VG95Z2tadFdF?=
 =?utf-8?B?emJ3WkZkbTkwSFcrOFoxTThmdmNKd095R0ZWSVRDbWJlWVVMZjNic3NrQ212?=
 =?utf-8?B?a2dkOWh3amQ2bkZ4bkF6b3QrSFpGZWJQeXhhcjVJeExIclRISTdSNVNsNHZj?=
 =?utf-8?B?UkU3TjB6NWFPaXJtNnFJWFI2Mnl6TzVkaGI1MU9nWWF4cTJjTE9WL3hUQVEv?=
 =?utf-8?B?RUY5ZU12RXplbXEyTFU3Qlp6Y2c4Vm5pVFZVK1JYT1VEYnZobmpadzh0ZTRS?=
 =?utf-8?B?OHZUQ0lKSGNvZXZBQ2xYS2IvRlR6WXlHa2VwRjh6dCtHcUFyUjFTcVF4dVNv?=
 =?utf-8?B?dXNaaW1nZFpRdmYrYkxmSHhKOXc2Q0ZSQUpQczNBdVdNdDJuRkRTU2JsMnJi?=
 =?utf-8?B?K3Z1SjJpZWszaFVuVXlpVGNuTGhxQUhlR3p6OHFhL1R2VVA2ZkVpZFdSTkkv?=
 =?utf-8?B?cGpGTDl3RFdsM0tpNmNTeTNPV09LQlRmMTJyejM4M1pBemV3QTNFanAySkJj?=
 =?utf-8?Q?Lotgc3X3NX0=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bEF2YmYvNnA3NFZvb216N3B6ZGVHVExSbHhiRUEwRFJVdWRCSmNPNEJqR25I?=
 =?utf-8?B?ZkZuZWRsMmU5OVhFK1AyUExJMHZuRnkxZzRldFBhSWtKaTRvZFJQTmtwcTlL?=
 =?utf-8?B?c1hiZlJKRktYWHR4VnNzelNXeUlWbjFLRXN5N3F1ZUNKWEp4bmlnRGtCTWRH?=
 =?utf-8?B?dXNsZG5rSVR6TklaeGxtWXlCSTdlVm9XeEJBWXRVWHM1WkxzbXpUTFBkaEdj?=
 =?utf-8?B?cWcxSWMxalltMTAzbFg0Q01tSEZ2QThkamc4WjdMdmR5VEZzRnRSK0hPNnli?=
 =?utf-8?B?ckRjWmZsQmcwQ3JxckhkWW00d1ZJNlkzS1VmS0ZOWkhEcU1NSGwxRk55azRI?=
 =?utf-8?B?R1B5K3lsNnd1T0pYeVNCZHVFeFRVVGlUZGUxNGcrdUYvMGtDRWN5aWhxbyto?=
 =?utf-8?B?b2pSa3NjbGpWODZBeTFwTE1yaFZMbTZwTGhoMnJCL2ppY3ZhVFh6NmtCdnR6?=
 =?utf-8?B?REZ0MGc4SzV6OXkwMXpmcU92OGh5TG9nYTFncndlSUtZa3pnK1NRdk80ODJr?=
 =?utf-8?B?MGlEM2N1b2pFOE9VK2lQZzlxeWtMTXI3TVdSNzJIU21iV0FmTDd1OWFjWDQ0?=
 =?utf-8?B?b2YzV3RQWG53YmxzcWcrcFoyc1M0ZjlrelJMaXUrcU9yWi9xaWprSzhyUEg2?=
 =?utf-8?B?V0wrd1ZpWVJ3TkFjUmlQQmxLRjd1NzQvaml5MUVJbjRYT0M0Q3c1OVdrUTVx?=
 =?utf-8?B?RHBwU2lOZHVmcnlFclRRZmQ2anZnbTBkT2J1VjhUQVRwSE5oWmJkbnZGT2VP?=
 =?utf-8?B?bHluYnVSam5nN1RVYUc5ZWhoQ2JLUnFwb1F1QkIyN1hQWnQxSGhmalk4WExV?=
 =?utf-8?B?UU0rRDgydE8zbElSc21Ob2RKZUZ4T0V0T1A0eVVVSFJXTjFnR2JFV2Jwczhj?=
 =?utf-8?B?dnh5eVNRR1VHcEtyRFZxMldsT1BwazN3R2R0bWlzVGxHSHovRWRBOThTNFQ0?=
 =?utf-8?B?QVlCd0hHTU1UM1FGVlB2L2Z1SWdHSktpREx5c3I5bFZqQ3p0ajMyampaU1RI?=
 =?utf-8?B?OTlMajFyU0hVZkdieDhPbFhzS1EyYTRoMi9FdlZqcldoamRkamFvaVpJalVM?=
 =?utf-8?B?VFpCc1hpWS9IVkRyVFhvSmhhVDcvYnAxdlJ0Qm5nSm11OGVXd21LMHlXR1BK?=
 =?utf-8?B?NlM1NHVsSFFjRWJXalQxaFBJSXJIWkhRQnNPcFB1bEM2QVN1eUVGNTB0dW8v?=
 =?utf-8?B?L1FGMVI3U0h2ckNMZEYxOTl2NDB0NVhldmlScCs2eHpCOGJZaG0vNkRKNy92?=
 =?utf-8?B?c1JCVU1Na0pvMXpxZEs2aFZtZU9ZMzJaWjM4RERqUmMrN1BuZGdVanJQeUdk?=
 =?utf-8?B?aGpNWW5PaWdaTHQvaCs1Z3hUTHUzOHprcy9TSHpaWWJ1YjR5ZWtqSFErTXd3?=
 =?utf-8?B?TURYNVhQdmlSM3pOVFVXeE9SVENHektvZzYwblh0a2NBLytTQ0ZqcCs2ZnlJ?=
 =?utf-8?B?bTBOT21vbkZ4SkwxbnN6akFHTU1SSVFEK2tuNVYzZVZyMlhkQ0prV2tnRk9j?=
 =?utf-8?B?TjdhbUVDV0FKYWwwUUgxVmhpbUIzM281cmt0OUJ4K3NDU0hhR2tmbmtLVGNR?=
 =?utf-8?B?VmZYZ0hndkx0Qjh3MnZUZGNaNmQyZ1Yxa3VoU29VbDIzbzc3Y280QS9VTVZu?=
 =?utf-8?B?SndGbVNmNEJPclZRQWx2b3M3TWN6MnJzWFBybkNuZzF0Mlpjcnh0OVN5bVAv?=
 =?utf-8?B?K0krSWMrSUVDZkZzZXlrN09XUFhIOHZ4VURnb3NuVjZBQUFBMHhmWTd3dSts?=
 =?utf-8?B?WFlKVUd1QjU5L0dKUktvVmFRUEw4aURFTmdpRU5udHZmNHBBMW0rcS9KOCtH?=
 =?utf-8?B?VUJDUWdBcFVYNkFyaHl4K3FZQ1RCOFQ3UkFxSGZzNmFDUUgxU2dNMFkwUUg1?=
 =?utf-8?B?U3hacUlnZEFHTGZ2TXVzSDU4N3VkNVFzSzY0U2pyYmF2VE9QOGlxTUFWcDhV?=
 =?utf-8?B?djJYaVpJWFBxam1TejFhTytEbW1jY2RlK1gyWFE3NGg0NTNUK04vRXRtWkRW?=
 =?utf-8?B?ZXpSZ1RHM3R0MXRFNUVzOHJYdk9DdDN2NVA1ME1kNVlqOUdFWHRBWTd6REJy?=
 =?utf-8?B?Q1J5Sm4wZGlzcFZsYjBkTFpqMGVGM1I5MVN2YTNlRXRTbHZZSkNRWDJXdVNM?=
 =?utf-8?Q?aE9Yaye7PVbrx7H/TdnPDWQhA?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94e09975-b712-4c33-4642-08ddfc06c0ed
X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5223.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 07:40:09.8970
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZUoNoCBVXuNJz8PUthGKHyB+mczLZ8WgJuCLb2WCNRnmbCbGGGhi0+SlqhC3T1n0f0xv5qzuQ76bOnoAmAnCew==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6533

On Thu, Sep 25, 2025 at 09:37:46AM +0200, Jan Beulich wrote:
> On 25.09.2025 09:34, Roger Pau Monné wrote:
> > On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:
> >> On 24.09.2025 15:40, Roger Pau Monné wrote:
> >>> On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
> >>>> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
> >>>>> Otherwise the check for the SS feature in
> >>>>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
> >>>>> X86_FEATURE_XEN_SELFSNOOP never being set.
> >>>>>
> >>>>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
> >>>>> identify_cpu(), because SS detection uses boot_cpu_data.
> >>>>
> >>>> Doesn't this, mean ...
> >>>
> >>> Well, that's the reason for the rant here.  The reset at the top of
> >>> identify_cpu() has been there since 2005.  It's arguably to make sure
> >>> the BSP and the APs have the same empty state in the passed
> >>> cpuinfo_x86 struct, as for the BSP this would be already partially
> >>> initialized due to what's done in early_cpu_init().
> >>>
> >>> The underlying question is whether we would rather prefer to not do
> >>> the reset for the BSP, but that would lead to differences in the
> >>> contents of cpuinfo_x86 struct between the BSP and the APs.  In the
> >>> past we have arranged for leaves needed early to be populated in
> >>> generic_identify(), like FEATURESET_e21a, hence the proposed patch
> >>> does that for FEATURESET_1d.
> >>>
> >>>>>   However that
> >>>>> creates an imbalance on the state of the BSP versus the APs in the
> >>>>> identify_cpu() code.
> >>>>>
> >>>>> I've opted for the less controversial solution of populating FEATURESET_1d
> >>>>> in generic_identify(), as the value is already there.  The same is done for
> >>>>> the AMD faulting probe code.
> >>>>>
> >>>>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
> >>>>> Signed-off-by: Roger Pau Monné 
> >>>>
> >>>> ... this Fixes tag is incorrect?
> >>>
> >>> I think the Fixes tag is accurate; the code was OK before that change.
> >>> Nothing in c_early_init hooks depended on (some of) the x86_capability
> >>> fields being populated, which is required after the change.
> >>
> >> I agree. Hence:
> >> Reviewed-by: Jan Beulich 
> >>
> >> I wonder though whether while there we wouldn't want to also store ecx if
> >> we already have it. (Really there is the question of whether we haven't
> >> other cpu_has_* uses which similarly come "too early".)
> > 
> > Yeah, I was about to do it, but it's not strictly needed for
> > c_early_init, and it's done anyway just after the call to
> > c_early_init.  I can set that field also, but then I would need to
> > tweak the comment ahead, something like:
> 
> Sure, i.e. fine with me.

Thanks!

Oleksii, can I please get a release-ack for this to go in?

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:40:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:40:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130090.1469722 (Exim 4.92)
	(envelope-from )
	id 1v1gb2-0000PS-Eh; Thu, 25 Sep 2025 07:40:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130090.1469722; Thu, 25 Sep 2025 07:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1gb2-0000PL-C9; Thu, 25 Sep 2025 07:40:56 +0000
Received: by outflank-mailman (input) for mailman id 1130090;
 Thu, 25 Sep 2025 07:40:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1gb0-0008IO-W4
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:40:54 +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 f77b2a8f-99e2-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 09:40:54 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-62ec5f750f7so933968a12.3
 for ; Thu, 25 Sep 2025 00:40:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a36508a9sm755444a12.15.2025.09.25.00.40.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 00:40: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: f77b2a8f-99e2-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758786054; x=1759390854; 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=t8MPA9oNypKPaWXdVSX9BKS3bRKo1OjXaFYTtDNO6SY=;
        b=SaiTazicThNxGT1D+tj9l8OV2uXV/JEwOh32WqMn7+yWbFnxh94RnBwYxzKmT0/kng
         42JWsMyL/2g/SF3jKhd4wEKw5YL2oPw7BP4R/rzoQE1QutYACEcdHZCeOXRsXKe/m2WW
         5uCPTJ3hWEljhcCuq3PoxfQoTzxEZ/wczZMoI8IHG1VSeFROBwSsWhRYtqG3ddR+ayi0
         rK8zyiBmsaDNi5JpTFexr1KS9imbKWFoQClvNZNFbSjCx35tm8fBG03ZKnRLZLBtVLSH
         dc5DWH2Q9kvoXKRsmDMaOr8J6rR8YUPWIlNBtHNWDFnAsTZd5qoqp6gteZ3mZjUfp9TG
         S1GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758786054; x=1759390854;
        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=t8MPA9oNypKPaWXdVSX9BKS3bRKo1OjXaFYTtDNO6SY=;
        b=My3JuFSGSTFCQ8+pcTK0Aqhrn94pQaFfOoNFVnnw6ayG9h+CusVlyFz5Zc84RQ+4FL
         NLv2rJlIhjNa5nc/U3lz7LLOlR5N+yUBC0hpWpSFwuVKOzH9OE1FXDDz6uyt/ADEetTC
         uPfj4BdwHf74acaGOQ3LzhzeNEBxI0M4I/ujnGYF1oerZcaSeJGU0gkKSzlBnL9V5T98
         GQoBR90Zb15UrOQ/k4jF+RaUNkw+dRcrGk50HX7cEVeUAyPV82bB8kHIRKBOhuIRINzA
         Gcv2Ik9llEVEAB8vJzk+4uR69dRXnP8fnby66XT0V0ybZ0H/j4qu3ulbo5RrNchcGVua
         LjCw==
X-Forwarded-Encrypted: i=1; AJvYcCXCjjhHYbDJGVEPpKFo72tmZ13Nn4OVGKk9RgwIF3UaS2/ngoZLw6Qyy6zgKuzqCFJWV/Hz+LqapbA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYUjhTo9IAzuldsulHjzBY6s6mholws9SLQlynECYUvVOJoUFF
	NkjdxPAOaZw1SnJGRQFZrIBu2O23nlXuwQKkkEQldXefzleT/Zk3gzJ7/rVUNlFFWQ==
X-Gm-Gg: ASbGncudAbWzqw2O+5cqlOs/uA5M+huoXXx7AhgAcHnJb8F80Ed8Ak+S2wPgKDwEM/b
	UWfx+cceFjnTeV6S6v+eP7pj7Nfi0D3ulpuGPEI4ggeSmbWl/6OtXwWaXN+AT21DtFdEt09IEQ8
	1+Obhn8JpwU++lJ0B5G5w3o2ckiWB3EuPJMzEH8pfxS98c3VadSdN87TVgqi9eZUiQGD7Qri2wW
	HVjcquYyFCZcdXEiG4EuZRHxBmS1MuVZ8rGW1ohAkZ0WgBhW8U59kYhlkTWPkFlIWe+DIDTuDMw
	DjuIJ5AbSxhSRPwPBIoaZ/0MSMyDNfECgNBInHZT60DESFlXIZoELMlves+W4+yBoLsr9u9c8ya
	Uya3QcIA36ncRCjm0auBpJrzn5nt7F2XprMskbjNMxEhyVaNDTzHVWCBPoN5039VbDghZuFR1gV
	qYJGHg7Gc=
X-Google-Smtp-Source: AGHT+IGTLbsYatgm8H2Dh8n9o7FDaiecRvtS3c8jPjkduVCnaK2No5O36cwmsrsK2dgjRTDTcfIewA==
X-Received: by 2002:aa7:c543:0:b0:633:b513:c5be with SMTP id 4fb4d7f45d1cf-6349fa24029mr1728764a12.14.1758786053675;
        Thu, 25 Sep 2025 00:40:53 -0700 (PDT)
Message-ID: <3855eca2-2961-4ca4-8c26-f51ceae70e9d@suse.com>
Date: Thu, 25 Sep 2025 09:41:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Arm: tidy page_get_owner_and_nr_reference()
From: Jan Beulich 
To: Julien Grall 
Cc: Stefano Stabellini ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 "xen-devel@lists.xenproject.org" 
References: <0d330757-ed73-42bc-8634-e8d445f69c4c@suse.com>
 
 <5e52900c-97fb-4895-bde5-33ccfb132986@suse.com>
 <079ead0e-e613-4c58-89f4-8a0df1294ba9@xen.org>
 
 
 <1110e604-0eeb-4786-a829-8f92280b7dd8@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: <1110e604-0eeb-4786-a829-8f92280b7dd8@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.07.2025 09:26, Jan Beulich wrote:
> On 12.07.2025 12:37, Julien Grall wrote:
>> On 03/07/2025 11:04, Jan Beulich wrote:
>>> On 03.07.2025 10:52, Julien Grall wrote:
>>>> On 02/07/2025 14:37, Jan Beulich wrote:
>>>>> On 02.07.2025 15:18, Julien Grall wrote:
>>>>>> On 02/07/2025 14:06, Jan Beulich wrote:
>>>>>>> When the bumping by  (instead of just 1) was introduced, a comment
>>>>>>> was left untouched, and a bogus ASSERT_UNREACHABLE() was inserted. That
>>>>>>> code path can in principle be taken (depending on configuration coming
>>>>>>> from the outside), and we shouldn't assert anything we didn't check
>>>>>>> elsewhere.
>>>>>>
>>>>>> I suggested to add the ASSERT_UNREACHABLE (see [1]). My take is the
>>>>>> overflow is not something that should happen and it is good to be able
>>>>>> to catch very clearly in debug build.
>>>>>
>>>>> But catching an anomalous entry in DT (which aiui the values come from,
>>>>> even if perhaps indirectly) isn't going to depend on people using debug
>>>>> builds. It depends on what DT blobs they use. And issues there shouldn't
>>>>> be checked by assertions, as those blobs live outside of Xen.
>>>>
>>>> I agree we probably want check upfront. But I still don't think we want
>>>> to remove this ASSERT_UNREACHABLE().
>>>>
>>>> By the way, I am not asking you to add those checks.
>>>
>>> Sure, I wouldn't even know where and what. I can re-send just the comment
>>> change, but that would feel wrong as long as the ASSERT_UNREACHABLE() is
>>> actually reachable.
>>
>> I am guessing you mean this change:
>>
>>           /*
>> -         * Count ==  0: Page is not allocated, so we cannot take a 
>> reference.
>> -         * Count == -1: Reference count would wrap, which is invalid.
>> +         * Count ==   0: Page is not allocated, so we cannot take a 
>> reference.
>> +         * Count >= -nr: Reference count would wrap, which is invalid.
>>            */
>>
>> If so, I think it is still valid regardless whether we continue to use 
>> ASSERT_UNREACHABLE().	
> 
> Yes, that's the comment change which is valid regardless. My reply was about
> the dropping of the ASSERT_UNREACHABLE(), though: To me, dropping that
> change simply feels wrong, as it was put there by mistake at the same time
> as the comment was left unaltered. So to me both changes still go together,
> unless by a patch going in earlier the unreachability of that return path
> was indeed guaranteed.

I think we want this sorted for 4.21. I'm happy to shrink the patch to just
the comment change, but only if ahead of that whatever other change goes in,
making the assertion actually legitimate to live there.

> In fact I guess I should have added a Fixes: tag to the patch.

Locally I've added
Fixes: 5951b856d8d0 ("xen/arm: introduce put_page_nr and get_page_nr")

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:41:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:41:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130104.1469733 (Exim 4.92)
	(envelope-from )
	id 1v1gbi-0000vC-OB; Thu, 25 Sep 2025 07:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130104.1469733; Thu, 25 Sep 2025 07: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 1v1gbi-0000v5-KX; Thu, 25 Sep 2025 07:41:38 +0000
Received: by outflank-mailman (input) for mailman id 1130104;
 Thu, 25 Sep 2025 07: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 1v1gbh-00008I-2q
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:41:37 +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 0ffaa0f2-99e3-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 09:41:35 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b3164978f11so117022466b.3
 for ; Thu, 25 Sep 2025 00:41: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
 a640c23a62f3a-b353f772528sm109967866b.37.2025.09.25.00.41.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 00:41: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: 0ffaa0f2-99e3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758786095; x=1759390895; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tXaai3UohyP+lHt/qeEGBbGZ9Pgak2DrtpXTUW/RqNo=;
        b=N4kX8bHdGX5J8eTKANDuc6m2qg3zcUQwy9gcPiqag8qaR3YgGTHBFZx4AMAqqY+1Wk
         DzQ2RlKioiAUN8iXMVH217G8Sf4CHddpYBZE41ud5dmehPydYhSZu2hzRtMd6gy22c2M
         KwIl9ZPyDFHRMqwFMJai5Sj7g4QwrNPsxVkcr39CD2QCs2s3eyNLORLP8NP9nCv+8IuJ
         gid9Xx5YcNlolVAJ70n4ImXXx4wH2pSnnE9F30IW/D5BBhz2FXaT9rWLyx2KQbsgVbY/
         PPmssMc7MXhpIh4OGaeQFXBltNsAP1o5wVOlIjJ5h+ZTQUl3pVo2BcVrmk0Abz0uQITG
         K99g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758786095; x=1759390895;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tXaai3UohyP+lHt/qeEGBbGZ9Pgak2DrtpXTUW/RqNo=;
        b=l1aLmMxA38Z9OKnKb2dnGyjnKwHAx1KOZipGXcPS/6Fvx0WoWi0s2KXjIHB1rp6BJY
         5TMbWHmsZUAj0NMYnosf7F4ACmNiXAclyAqYfhIAncThPS/87TFqrONvQNq1vNJSRJxS
         z+rZBpUXc/P0IRDcBpe+SdNhu1//lYrGkKZChvetUPgdMDj8UaiLbAHnp6VHvpJZ/iUI
         vDxQ7cpPNOza+Zn8MMsz27RcGZWDIm/gq5S+K0ifivyfJMKi2vqpFDheVcxvBpvShV2E
         hSianUTml17XCLsQk5Okj2Ny51WrS64/CqqYvUzgCS5ACpgRBHb/jlokKV3cmxPNV29E
         ivOw==
X-Gm-Message-State: AOJu0YwHkx+uQw90OKxovW8JYOh8Ms+K6RSFmK2zixDbv2tDkYZlKSkw
	98okx8FBF2GTB5cWTlNf9f/4dAw0OmA5r6/iN7sUI8QlsKru++MybVXbstS3a/a8d5ig8zPX/rb
	qkSQ=
X-Gm-Gg: ASbGncvQgHyIBLW4Cvk76UWMAADoeexhQn25s9Jd11SgGymmOMVWGtKP8Xclfsl9loY
	t2R3DNpIrsEVyXe+8gGj6PlBLBuCPGiA+Jg75PBrGZvMYf7wg3XN2jssX388aepT4qa9gHxUHb1
	jFojke4NRN5FPOVOVgyUUT/nw28A0sa9dEx8gGD00+LZDmzZulUg9adhxbUWrlYFrmesIQ5tLat
	Tt3hwNWVjfMAmko4mt1ufFQ4YBs96Henkb69XARVacJCPUYXnT343s02RwTnuAyABk4MaTC5/Os
	j5ZjjbOd9aJThIl3/5A9azDLENUy+bVBKNUiBN0+hu8XY0qk0SNhKZzhmYxrKXzh3mNBqVmZuTp
	biNVsWjvzp7jX92UTs1SmXtZ69e7+ADhi2MT2/2yOD8fJdTtRL6Ll4Kxzfjpv0rcFZlpgUpYeZ3
	eMCAWCfpo=
X-Google-Smtp-Source: AGHT+IHhhppDkxJTYjt3CYCF84J7S0MhJd4Ff5TU4ZCnZ+3EVfrPRTSULxdITOTqCdZ0qHUNMCzhCQ==
X-Received: by 2002:a17:907:940e:b0:b32:58e2:a20c with SMTP id a640c23a62f3a-b34bc8765c1mr261044766b.65.1758786094921;
        Thu, 25 Sep 2025 00:41:34 -0700 (PDT)
Message-ID: <58e5e9ae-9b57-41b0-a2d9-bdd2f312293b@suse.com>
Date: Thu, 25 Sep 2025 09:41:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , oleksii.kurochko@gmail.com
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
  <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
  <1083faae-d565-48ab-8e41-3a5a12178a9f@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.09.2025 09:40, Roger Pau Monné wrote:
> On Thu, Sep 25, 2025 at 09:37:46AM +0200, Jan Beulich wrote:
>> On 25.09.2025 09:34, Roger Pau Monné wrote:
>>> On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:
>>>> On 24.09.2025 15:40, Roger Pau Monné wrote:
>>>>> On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
>>>>>> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
>>>>>>> Otherwise the check for the SS feature in
>>>>>>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
>>>>>>> X86_FEATURE_XEN_SELFSNOOP never being set.
>>>>>>>
>>>>>>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
>>>>>>> identify_cpu(), because SS detection uses boot_cpu_data.
>>>>>>
>>>>>> Doesn't this, mean ...
>>>>>
>>>>> Well, that's the reason for the rant here.  The reset at the top of
>>>>> identify_cpu() has been there since 2005.  It's arguably to make sure
>>>>> the BSP and the APs have the same empty state in the passed
>>>>> cpuinfo_x86 struct, as for the BSP this would be already partially
>>>>> initialized due to what's done in early_cpu_init().
>>>>>
>>>>> The underlying question is whether we would rather prefer to not do
>>>>> the reset for the BSP, but that would lead to differences in the
>>>>> contents of cpuinfo_x86 struct between the BSP and the APs.  In the
>>>>> past we have arranged for leaves needed early to be populated in
>>>>> generic_identify(), like FEATURESET_e21a, hence the proposed patch
>>>>> does that for FEATURESET_1d.
>>>>>
>>>>>>>   However that
>>>>>>> creates an imbalance on the state of the BSP versus the APs in the
>>>>>>> identify_cpu() code.
>>>>>>>
>>>>>>> I've opted for the less controversial solution of populating FEATURESET_1d
>>>>>>> in generic_identify(), as the value is already there.  The same is done for
>>>>>>> the AMD faulting probe code.
>>>>>>>
>>>>>>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
>>>>>>> Signed-off-by: Roger Pau Monné 
>>>>>>
>>>>>> ... this Fixes tag is incorrect?
>>>>>
>>>>> I think the Fixes tag is accurate; the code was OK before that change.
>>>>> Nothing in c_early_init hooks depended on (some of) the x86_capability
>>>>> fields being populated, which is required after the change.
>>>>
>>>> I agree. Hence:
>>>> Reviewed-by: Jan Beulich 
>>>>
>>>> I wonder though whether while there we wouldn't want to also store ecx if
>>>> we already have it. (Really there is the question of whether we haven't
>>>> other cpu_has_* uses which similarly come "too early".)
>>>
>>> Yeah, I was about to do it, but it's not strictly needed for
>>> c_early_init, and it's done anyway just after the call to
>>> c_early_init.  I can set that field also, but then I would need to
>>> tweak the comment ahead, something like:
>>
>> Sure, i.e. fine with me.
> 
> Oleksii, can I please get a release-ack for this to go in?

Do bug fixes actually need release-acks just yet?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 07:43:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 07:43:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130117.1469743 (Exim 4.92)
	(envelope-from )
	id 1v1gdQ-0001W2-2G; Thu, 25 Sep 2025 07:43:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130117.1469743; Thu, 25 Sep 2025 07:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1gdP-0001Vv-VQ; Thu, 25 Sep 2025 07:43:23 +0000
Received: by outflank-mailman (input) for mailman id 1130117;
 Thu, 25 Sep 2025 07:43: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 1v1gdO-0001VW-AS
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 07:43:22 +0000
Received: from BL2PR02CU003.outbound.protection.outlook.com
 (mail-eastusazlp17011000f.outbound.protection.outlook.com
 [2a01:111:f403:c100::f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4bfe76ea-99e3-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 09:43:16 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB5973.namprd12.prod.outlook.com (2603:10b6:510:1d8::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 07:43:11 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 07:43: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: 4bfe76ea-99e3-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K9xZ+QjAqh6LzqoLVbmBPDKc+sJ4jEifS8x9fNvjl5pEngGoR/nIX9eEnDCc9tkzNfM3vx/Yc3lpOX1VRPRLcxQGcQzcHXFUwbNklpyJyVjmLk0ydTD8if9t62+yw+Evqyrkke00/cV0TzYiGXzo3khYFwMaybHwM2DxwQDsAg/Uvy1JzOvhp9gHTeyHWcmbU8OEX2MY3s8Mo2KxlxxgWjNwVQA0hZrKOBin85Vn0gBgSrsuxO/reiY/NBxOaIp55Fi3EAA4I8Bef84vd+mp6K5mtW4cO1uJy0Eo7hbjBFXGKQULtxPE9fMCj7P+azfRns11m1vDVMht2nZy5eAneQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lwIPbeGfZniNvdyIZumgValRYfibb1bd9mmv50BqNpk=;
 b=pyPB9VFpPGqOOLh++yyi6fHOShUpttbVFGKh3cVp2x47I/UBNwIkOHlm41HhzLvg9GAJOpG+J9LO3DUcefmPztmSTYLctaWGdnZKD+uGz8vN/WKn0bbf9dn2cW0DEVnMg+cHQk3YaMmr+6XHynL/9vKQQ9zuMOuC84D5D6YFnV6lPlRBZ4EkTvFyZvNVqQ4LST/c7AzyWeis3u0rbEAhS4c296gNwkNZeDukV7GT2ia4NNt/05CAoW8KUuJ9ME4a7QjpD+9vUJ2onVj9H6w+eQy6n4qPRVPxo8W608TrXTi5Gh5747J+ObR0DpNyrjlCR2osmjYMrUhWbNyvlZELaQ==
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=lwIPbeGfZniNvdyIZumgValRYfibb1bd9mmv50BqNpk=;
 b=0e4RYuGWYe1LXaLFivH8HwNesjWsJcpl/OZ7ovW6OM7TYqSdmQR9vLIKLCRr8gnZf74CMSLV2smpVBAs46BWGL4Ffr4C2XtSk4OCPxJ/svye9V9quYUQgaCJUMuvMmTifgMxkVShqi1rmZYIaxs8ofpJGM1Kujzdy6/S85A2k9c=
From: "Penny, Zheng" 
To: Jan Beulich , "Daniel P. Smith"
	
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 15/26] xen/domctl: wrap
 xsm_{irq_permission,iomem_permission} with CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 15/26] xen/domctl: wrap
 xsm_{irq_permission,iomem_permission} with CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYTs0Y1R/o960quInjC4q0w67SN0scAgBXIIBA=
Date: Thu, 25 Sep 2025 07:43:11 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-16-Penny.Zheng@amd.com>
 <1bb90323-6071-4aec-9f6f-33163e6f769d@suse.com>
In-Reply-To: <1bb90323-6071-4aec-9f6f-33163e6f769d@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-09-25T07:42: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_|PH7PR12MB5973:EE_
x-ms-office365-filtering-correlation-id: be27e34c-b174-4d27-4f30-08ddfc072d99
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bVNwVVpHWXYwdlVjbThnOGw1R1FnMnZuK3B5TWNCbFM0ZkFsQUZHSFhTMmY5?=
 =?utf-8?B?Z01XM0dTSDJqeG9hOFgvMTFqK3Rvb0cyb0ZFY2pnVlVnQkFVdFFkdGJlRENR?=
 =?utf-8?B?bXBQQ3pOVXFzNFo1ZkRDVFZ3UkJ3dThNYTRRdUVBeDdBQWljeWVyQzNFMFk4?=
 =?utf-8?B?Yk90dVpLWC91dElIZHJNaVN3M2pEdUF0QVN6VVVGY2lrVnFZY1hiSDEwR3Ey?=
 =?utf-8?B?NDhyS1UrSmhWUVp6WHpvSTNrNzNEbEZyWGovajNpZWgxS3Iwc0xwa1JrRlNm?=
 =?utf-8?B?TkdoNThrTmpHQTNFUUg2OHc0V1I3UXBQZHltRHFpdmlBOUhyUk0rVXdsK09X?=
 =?utf-8?B?ejg0NVU1bHQ5dEMyUjJHcExFUDlKb0tSVnFPSVFncHNzNTM2RFptT0ZXa2hN?=
 =?utf-8?B?OUJvUFBHRHU1Q3gyNEVRVXMxTDJ4QmNCTXZ0NU9TMk1FZFFrMXFpNmkwWUky?=
 =?utf-8?B?SFdPckJsQXdrYlgvb0lLUWd3RitmYjdEajQvdW1pbG5kOWJmTTVybVBFMU9X?=
 =?utf-8?B?a1A3R3lWK1NyemliUWFaYkZ3VG92S0RkNm1hQjFZZk5yV3lYWW1PNzhROWZk?=
 =?utf-8?B?OStsR3RGOVBSUGEwOUxhOVM4N2Rla2Rsc3NrN0JIdXFGbDRYTi9jYm5MbXEr?=
 =?utf-8?B?bUp6WFQzWFE0cHc5dzhwbGc0RUVudzRYd0toVThubTBjZTY4bERtQ2l4aWZz?=
 =?utf-8?B?Y2RwMGovZzNWWmZYTG8xNkpWNnZGanVKVU4zQmNpOXZTVjJsLzB4eWM5cUZn?=
 =?utf-8?B?K3M4b0RoczZYZWt2Wk8zaFdXK24rZXNGVmM0NktPbHdDSllMTkZUZklKWFNw?=
 =?utf-8?B?OGt1K05tazZuVis1M2ZkWTRqcTlENjRiR096eUdJbmpETTdQZ3haSjZJYnNB?=
 =?utf-8?B?Y216V2tDUHVUdDgzek1TN21XZmhqelZLekRIYmRXb2EvWFB0TlYyTmF0NFVM?=
 =?utf-8?B?dnJLYzVxN2ZzRlc1N1JDcFNjQnRuN3RzdDl3OW1NdVJwa1RpdE1iNy8rSDJI?=
 =?utf-8?B?OFlrL0FVU0NWdG5VclpJRjBUNnk3MTdBcGhNdmx5TDUxWWZVWVA4U3pEeE13?=
 =?utf-8?B?L0IzcitKU3cySUlEeG5FMG9hK3NVeDRFby9IWHpLM1BIK2hObkhkVEE5RTFZ?=
 =?utf-8?B?M0JyM2hGK3NobXJGdTNTNUpmbUdxbjhtTzFiS0tQbFRPcklYeCs0U3UrVG5O?=
 =?utf-8?B?dWNwQ2pLOUI2WnErM1FITzVSNGdlbEI1WUJ6djNDTkdlZnA4T2ZYMks1RnM4?=
 =?utf-8?B?bGVmZ3pIVldhemowd0lnYkhueC9XRnpGTWJwTTBoK0ZVUVR1enJndmcxZi9t?=
 =?utf-8?B?Ukh3YWlzVzVSL0N5OVBtVkc2ZTY2b3BkMGtlaE9YK0lTRGlsazRucmI1SU02?=
 =?utf-8?B?NGFvOW9LckpUY0YxS0RwWFBaOENsVklxaVg2Vm44QlZKcHJldHB2VEdhWTA3?=
 =?utf-8?B?UDg3M1Q3MkZNQkY5TkowTmRQQVVvckJJa0lIR1RmdlR6dkxjSkR6VjFFajZC?=
 =?utf-8?B?ZVp3SHFUL2ZmQ2RaVkVVZjNwRnEvTExPdGNnbnd6WXR1azBFd1FmWjhXU2py?=
 =?utf-8?B?TmxFczVLTnFTQ2xSYThqNVpoQXpWcnhwbzMxWXdoQzRrUmZVL0pGc1d6TElx?=
 =?utf-8?B?MUJoWm9GNkllUDM3cWhmbkFFTmhUN0FzOExpUFpVUTdnL2hSOGZTV2tEOEw0?=
 =?utf-8?B?Yng5Yy9xbFVPYnpYMU16bWJ0UXpTUEs2SmpTbDRvNFh0N25jRjRDK0VrZThB?=
 =?utf-8?B?ZEp4TnExZ0F0d1hucWpkeERUS0F3Vzl3Q1JjZ3R5dG9zdFJKU0N4Zmw2ZG4r?=
 =?utf-8?B?TE1ldDZEekphaDk1cnhWM1lyL3VTUHp3T2gxa2pJUVRZUGl2a2RTSlc3bVMz?=
 =?utf-8?B?UUFTVmp4Ykh4eFF3U21HQmJWdDh5blIraW1SL0Qvb29pYW85QVR1Zkl2UEE3?=
 =?utf-8?B?VFoyZ0tuR0czMDFJRzU5TXZSUWwwZytZNzYxb1FTN0xoUDJ1YVV1czdlUzhT?=
 =?utf-8?B?ZjYrODAyYmVrR1Z1NHN5TGd1VWtHT2RnTVUyamdOOWk4UlpCbit5K1ZXZDhQ?=
 =?utf-8?Q?Yu+/Pa?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?dG56SWJqM013MmFpdW40OXFUSDB3b1AxK21ZME9QS0VmWHVYdnZEY2lrM0pY?=
 =?utf-8?B?RFRad2dkWndwM1hDRStXbnN5b0xlaWcvM3JWdHJuTnJtcm5IZEE1T1VJbTNs?=
 =?utf-8?B?MllWRlI2alRuNWliN09uMm5vY01jTEZkTVpHQ0RCZHZneCtBMWJmM0tUYmtl?=
 =?utf-8?B?REVFTHR6S0VWTFFwU1kwdWhzQUNqN0RqeG4xNS83TXdVd1VIY3JBOHlwMXdQ?=
 =?utf-8?B?TnpoVGVUbmFoaGFVbi8vYjFXaDFuRGRPMktCVFRUdXpZVUtCT3VnYmNJMG1V?=
 =?utf-8?B?R25mak0rK016REE3dWsrZTRUeGtHeGowRmpuODl2UlRYS1dsU2hPdFhlVlR5?=
 =?utf-8?B?bjR5cVJscHdKWjZjbTNxbmU5am5jenRDU0FCZWhEQm13ZjJJaUxkUnl5Z2Y4?=
 =?utf-8?B?bmxzaFh0Wmtldy90QUU0NXRFeXBMdHhVdWFNZURqSFBES0pYOHRpUmJUalhh?=
 =?utf-8?B?V2dSdVR0NjU1U0MvUm5JM2xnMk1zejU5OCtpenRLOVdKNXQ5dEJUTlRrSVR0?=
 =?utf-8?B?amhLWnJPaXBURGltNXhseERoN2VkcTdraEZVakcxWkx5U0dKcnA5YUxaek1H?=
 =?utf-8?B?K3RUbHFONm9rR2lxVEx4bWNvK1lHK28rMW9BNVFTcEF4dWZXNTUrN2J0Z1FJ?=
 =?utf-8?B?YXRlWjFKZ3gxOVFuV3R4eDN3N205RTdIM1RBQSt6MUVXcUdLVEt6WDhZaktl?=
 =?utf-8?B?aVltUERWWVdMTkJNYnVxVmF3YzdNR0Fpb1JPYkpWa3JONGNRSlZzc1c3UHpZ?=
 =?utf-8?B?VHdKbU54alBhQlhTUExBbEFRSktwU1FmQlowSHRhckpzbjUxTXdRbkRvQUx4?=
 =?utf-8?B?WWh1M1lrUVV6dC9tcnBleXZiMFMxNVBLQzd5OW1OcU82b0xNK3R2SUV4Z3FT?=
 =?utf-8?B?RWI1cUVFZkFsa0F4K3BOUjNoRXVLNUJzV09aTG1MdjltWmwwU0s0QUV5cDZP?=
 =?utf-8?B?OTJ2YlRTMzR1L2pyL3BJL0VZMCtWZG1VZlVLZUg2V1BSRjZQNXJ4ekZURlBv?=
 =?utf-8?B?bFgvbnFKNEpmSldLY21WZkFzaDRPYndmUXN0OGw5VUtEdHRSenJsN3pzSnNn?=
 =?utf-8?B?bC9nRzgrcE50YWZHL2MyTEJaRFR1bUo1OUI2TUFWWkUzNzhRL09Vc0xMd2tU?=
 =?utf-8?B?aDQ2Y1JLd0dya3NEd1hPNHhhK094RHVDZy9zc1ZhWk1DSmlGVy94NXNiSEl5?=
 =?utf-8?B?alh4NSs5UWRpSXpKVXd5OFJKNXlSam10aXhWVkVXazNKazk4MWJsa2oySFZo?=
 =?utf-8?B?eUI4M3dieFJWTjNFR1RPcmhNUk5NQTRZZlNnYW1leGZUNEZUNjQrRkIrV1lX?=
 =?utf-8?B?RmlNUy9jc1VON1M5RlpobWNSeFh3MHQxMUY5Y2R5MFdaTUNuMTMvRUF5TTZ6?=
 =?utf-8?B?QzRyVTF2MW5BOVVady9HWWEyNmNGa2lEeDhZRGZLL3J6aHh6RzNMY1Nidk9B?=
 =?utf-8?B?M1pDaXpyb3ExTUhrd3JGR2U4Rm5wQk0xaXUzY2VhamN3eXZMYzNEZHB4TW55?=
 =?utf-8?B?SHFjVUtjUXl2WllFTEoyY29EK0xXVGJBTlpqc1c2anNyU1hDUDlBLzQyQkg1?=
 =?utf-8?B?ZXlVSllIT3RuNWhIc1JTSGk5VDVkRHZ4MGJQYzE5cWZCMzNMTVgzTXkrRndl?=
 =?utf-8?B?ZlZvR3lPeExOck83UTNpZFJzVFptLy9TOTJoTjBYWDVRYjNrcWdoU2dLc3N0?=
 =?utf-8?B?ZW53ckJCK0Y1a2NlSHNkOEZMTHRQenNrdmpLZ3dRZGRybjA3NWZQaEZuNDhv?=
 =?utf-8?B?RFZSNERia212S3MvOENaRFdRSnlTTXpMWWRGaGxEZmh3dGFxTWh2VExZZS95?=
 =?utf-8?B?RVgwNGdqNjJzZFZBU29pQ1lkdC9pU3IrVUV6VUpEWHFwYVlHYnpLMnc1dVQz?=
 =?utf-8?B?Q3lLa3MrMWFwMDhTL2phTDJYZGcrTXhJQTRWRnlqWTFkcGpGbXVQZlhzUi85?=
 =?utf-8?B?U29CaG5GZFZXbUhMZWdLZVZUdTNCYVg2UTYvTkxuNWFTamltL2MyYzZidW9H?=
 =?utf-8?B?Z1FFOU9JNHhZZzdvZkJCZnB6SHltMTg0ZFVWWFRhaHNuanFaR0I1aGYyWm9C?=
 =?utf-8?B?QmxtdUdTeHJ0dGdyRGl0M0hFdlNQNFhKM3dON3htV1k0R1FQbTJrZ1ZsL1A5?=
 =?utf-8?Q?oIj4=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: be27e34c-b174-4d27-4f30-08ddfc072d99
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 07:43:11.5905
 (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: 8awVM6GHkDwC35RViHgR6rmsbKzneJgLVhIGY19dU42hGtG1vJGvEs5UT/W4l2Pv+klmoBXb9yoDqegV3YBqZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5973

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEs
IDIwMjUgNzowMiBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPjsg
RGFuaWVsIFAuIFNtaXRoDQo+IDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tPg0KPiBDYzog
SHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVj
dC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAxNS8yNl0geGVuL2RvbWN0bDogd3JhcA0K
PiB4c21fe2lycV9wZXJtaXNzaW9uLGlvbWVtX3Blcm1pc3Npb259IHdpdGggQ09ORklHX01HTVRf
SFlQRVJDQUxMUw0KPg0KPiBPbiAxMC4wOS4yMDI1IDA5OjM4LCBQZW5ueSBaaGVuZyB3cm90ZToN
Cj4gPiAtLS0gYS94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCj4gPiArKysgYi94ZW4veHNtL2ZsYXNr
L2hvb2tzLmMNCj4gPiBAQCAtMTExMSwxMiArMTExMSwxNCBAQCBzdGF0aWMgaW50IGNmX2NoZWNr
IGZsYXNrX3VuYmluZF9wdF9pcnEoDQo+ID4gICAgICByZXR1cm4gY3VycmVudF9oYXNfcGVybShk
LCBTRUNDTEFTU19SRVNPVVJDRSwNCj4gUkVTT1VSQ0VfX1JFTU9WRSk7DQo+ID4gfQ0KPiA+DQo+
ID4gKyNpZmRlZiBDT05GSUdfTUdNVF9IWVBFUkNBTExTDQo+ID4gIHN0YXRpYyBpbnQgY2ZfY2hl
Y2sgZmxhc2tfaXJxX3Blcm1pc3Npb24oDQo+ID4gICAgICBzdHJ1Y3QgZG9tYWluICpkLCBpbnQg
cGlycSwgdWludDhfdCBhY2Nlc3MpICB7DQo+ID4gICAgICAvKiB0aGUgUElSUSBudW1iZXIgaXMg
bm90IHVzZWZ1bDsgcmVhbCBJUlEgaXMgY2hlY2tlZCBkdXJpbmcgbWFwcGluZyAqLw0KPiA+ICAg
ICAgcmV0dXJuIGN1cnJlbnRfaGFzX3Blcm0oZCwgU0VDQ0xBU1NfUkVTT1VSQ0UsDQo+ID4gcmVz
b3VyY2VfdG9fcGVybShhY2Nlc3MpKTsgIH0NCj4gPiArI2VuZGlmIC8qIENPTkZJR19NR01UX0hZ
UEVSQ0FMTFMgKi8NCj4gPg0KPiA+ICBzdHJ1Y3QgaW9tZW1faGFzX3Blcm1fZGF0YSB7DQo+ID4g
ICAgICB1aW50MzJfdCBzc2lkOw0KPiA+IEBAIC0xOTQzLDggKzE5NDUsMTAgQEAgc3RhdGljIGNv
bnN0IHN0cnVjdCB4c21fb3BzIF9faW5pdGNvbnN0X2NmX2Nsb2JiZXINCj4gZmxhc2tfb3BzID0g
ew0KPiA+ICAgICAgLnVubWFwX2RvbWFpbl9pcnEgPSBmbGFza191bm1hcF9kb21haW5faXJxLA0K
PiA+ICAgICAgLmJpbmRfcHRfaXJxID0gZmxhc2tfYmluZF9wdF9pcnEsDQo+ID4gICAgICAudW5i
aW5kX3B0X2lycSA9IGZsYXNrX3VuYmluZF9wdF9pcnEsDQo+ID4gKyNpZmRlZiBDT05GSUdfTUdN
VF9IWVBFUkNBTExTDQo+ID4gICAgICAuaXJxX3Blcm1pc3Npb24gPSBmbGFza19pcnFfcGVybWlz
c2lvbiwNCj4gPiAgICAgIC5pb21lbV9wZXJtaXNzaW9uID0gZmxhc2tfaW9tZW1fcGVybWlzc2lv
biwNCj4gPiArI2VuZGlmDQo+ID4gICAgICAuaW9tZW1fbWFwcGluZyA9IGZsYXNrX2lvbWVtX21h
cHBpbmcsDQo+ID4gICAgICAucGNpX2NvbmZpZ19wZXJtaXNzaW9uID0gZmxhc2tfcGNpX2NvbmZp
Z19wZXJtaXNzaW9uLA0KPiA+DQo+DQo+IEl0J3Mgb2RkIHRoYXQgZmxhc2tfaW9tZW1fcGVybWlz
c2lvbigpIHJlbWFpbnMgYXMgYSBmdW5jdGlvbiwgYnV0IGZvciB0aGUgbW9tZW50DQo+IHRoYXQg
bG9va3MgdG8gYmUgbmVjZXNzYXJ5LCBhcyBpdCdzIChvZGRseSBlbm91Z2gpIGNhbGxlZCBmcm9t
DQo+IGZsYXNrX2lvbWVtX21hcHBpbmcoKS4gSG93ZXZlciwgZm9yIHRoYXQgb25lIEkgYWdhaW4g
Y2FuJ3QgZHJpdmUgZnJvbSB0aXRsZXMgb2YNCj4gc3Vic2VxdWVudCBwYXRjaGVzIHdoZXJlIGl0
IHdvdWxkIGJlIHRha2VuIGNhcmUgb2YuDQo+DQo+IERhbmllbCAtIGlzIHRoaXMgbGF5ZXJpbmcg
YWN0dWFsbHkgaGVscGZ1bD8gQ2FuJ3Qgd2UgZWl0aGVyIGRyb3ANCj4gZmxhc2tfaW9tZW1fbWFw
cGluZygpICh3aXRoIHRoZSBiZW5lZml0IG9mIGEgY2ZfY2hlY2sgZGlzYXBwZWFyaW5nKSwgb3Ig
aGF2ZSBpdCBkbw0KPiBkaXJlY3RseSB3aGF0IGl0IHdhbnRzIGRvbmUsIHJhdGhlciB0aGFuIGNh
bGxpbmcgdGhlIG90aGVyIGhvb2sgZnVuY3Rpb24/DQo+DQoNCklmIHdpdGggbm8gZXhwbGljaXQg
d29ycmllcywgSSdsbCBjcmVhdGUgYSBuZXcgY29tbWl0IGluIG5leHQgc2VyaWUgdG8gcmVtb3Zl
IHJlZHVuZGFudCB4c21faW9tZW1fbWFwcGluZygpLiBUaGVuIGhlcmUsIHdlIG9ubHkgc2hhbGwg
dGFrZSBjYXJlIG9mICB4c21faXJxX3Blcm1pc3Npb24oKQ0KDQo+IEhhdmluZyByZWFjaGVkIHRo
ZSBib3R0b20gb2YgdGhlIHBhdGNoIC0gd2hhdCBhYm91dCB4c20vZHVtbXkuaD8NCj4NCj4gSmFu
DQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:01:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:01:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130146.1469753 (Exim 4.92)
	(envelope-from )
	id 1v1gul-0005FO-QZ; Thu, 25 Sep 2025 08:01:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130146.1469753; Thu, 25 Sep 2025 08: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 1v1gul-0005FH-MV; Thu, 25 Sep 2025 08:01:19 +0000
Received: by outflank-mailman (input) for mailman id 1130146;
 Thu, 25 Sep 2025 08:01: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 1v1guk-0005FB-Jq
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:01:18 +0000
Received: from CH1PR05CU001.outbound.protection.outlook.com
 (mail-northcentralusazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c105::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ceda7514-99e5-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 10:01:15 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 BY5PR12MB4242.namprd12.prod.outlook.com (2603:10b6:a03:203::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9; Thu, 25 Sep 2025 08:01:10 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 08: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: ceda7514-99e5-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=k2/jEchnOAv+g7rYOJG45sBSi9p2QqgzgRE9M3kHSzeVJtLLsnPkL8KWQfzAkm/nxglmNWAPmx1p3Cxy/lrGIY44jLklZ/iFPMTmY4ScmY/sWbjpsQGrGVxCr1ULnojfJyJdGcGGYtfoLwdLBj0tRO+ljNvD/xHmTvTJCv/Ia376kTLYbJ7WzSPNMFr57Yj8KAp6Q8wpQSXJW5gPfP+Hv55JwIa/rMyTwqvR2LjY2LsXPTeB52Ic493m5eebp6pTfYohnw0dqu/lhJZbesE+y67nrbjzZY68d09bXnQgeqbdWg8ycZdUlOYIkpSXQ2ylbwxpQNF5zMAZpOzH+uhSrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lf4IFhFuD8Di93RYEIE05Acw8s3Dm4KQr/5bJzi0AZA=;
 b=WebUqCwiV5K58QR7XwErtQkNmB2YQKgxDIkEvVvpf/6I5ajR2Q9PDHyWvxm/lDP0I84L7hbwkSJoKJ0+Jc30FpTMAkr2TNVyZia1cKKYwgtEdVjeEo+jr7VhsDvXE3TRXgYTP+r3Dfhu4avaUfgGA5bjR3aNiX2J/K5ptNQIyMYdSmxIvYAKDUte3R75OAJG7WlHN7iT94fI9WASGy2GYrlCdJ7ju6tBwC0m3qpfn+Z76ls6AC+EdPSYuenjrShXkQQV/NMMUIsjnfOsqjgjWsc2/OhsxLR9mpXiBA5OXK3t805g3srA47I646oS7qd2zqfyrP3mpY2hQzpu+uAisw==
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=lf4IFhFuD8Di93RYEIE05Acw8s3Dm4KQr/5bJzi0AZA=;
 b=csHMq5mGq/k5VaithGgGoDFQjx6QD7WWqV2Vz13uB6RyzrL4nqWx2LP7RdW5nfD3GFJ77qGH4liNtcBoDskijnpmecj5jHXdm1AcvX/EF7avCcj5OhcAkIy+H4Fn49iBzVtO9TTuIccg27nxh/jkXgC+e1wlS+zbAa85dcuAYoU=
From: "Penny, Zheng" 
To: Jan Beulich , Stefano Stabellini
	
CC: "Huang, Ray" , Julien Grall , Bertrand
 Marquis , "Orzel, Michal" ,
	Volodymyr Babchuk , Andrew Cooper
	, Anthony PERARD ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v2 16/26] xen/domctl: wrap arch-specific
 domain_set_time_offset() with CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 16/26] xen/domctl: wrap arch-specific
 domain_set_time_offset() with CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYVha7/RUmVzU62kcSZyqSE7LSN2dWAgBXF6hA=
Date: Thu, 25 Sep 2025 08:01:10 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-17-Penny.Zheng@amd.com>
 <2d4bed7a-352b-4090-a07a-fd617e2f932b@suse.com>
In-Reply-To: <2d4bed7a-352b-4090-a07a-fd617e2f932b@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-09-25T07:57: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_|BY5PR12MB4242:EE_
x-ms-office365-filtering-correlation-id: cc986f6a-2dd9-48c5-1fef-08ddfc09b0cc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?emVlOFZrZktZQTE5VXZJRzI5MjREcFNPRm1EVzJxRy83czRUWDBPZUdwWHFR?=
 =?utf-8?B?VlhJNkJEcXNpbHZDZVVHR1RmU1UvTHBENFVjak91RzRLYnFBS0RVTnNZL1Zz?=
 =?utf-8?B?ZDk5RGRaY2J4UWh6YXVGekUzNzJEdWlOM2VNRU9wY0NEOHNxRkM2NUV1aEMz?=
 =?utf-8?B?MGRMbHBzamt3Szh0MW8yVXkzMUtoYUtIWnJVbGlORzlZMHo4S3ZXNkNhcnZl?=
 =?utf-8?B?TEpjZ0VZalU4eUVuRG9wSmhFSXVXbUM0NXA3bk55UUVodUx1THEzNWVUNWg1?=
 =?utf-8?B?cEpmK1oyYnoxMTlKeVhFVXFoVWR3eUZDTC9uejhLeGtvZ1VxSVUrUEJWdUVT?=
 =?utf-8?B?Ymk3bDVOOVBBUEJadDYwem5hZFRRSDNXNFZsTnI0UThhS1NGSndRWnRwRGVZ?=
 =?utf-8?B?ekRLSE1wQ2lxUnZXRmpIcmN5d05ZMEM2d21MOStraUYyVEhzV3I5Z0gxZDg5?=
 =?utf-8?B?bG5JV3pQTjEvQkdCV001RUhFSEowSlRmU3JwNjBWbU84cU41Z09BQ2xycURt?=
 =?utf-8?B?NmNiWkZaL1h0SDdaazEzamJvQk84OThyZy9nWmMxdUFvRWRGbnlBZHV1NUo1?=
 =?utf-8?B?Vyt1d2NWSEY1RmdnaHdZakZEc2lyRFQ2anR6LzF2K0gvSjlkaGx6dlRuUEd4?=
 =?utf-8?B?TEsvVVVmaGpscWo1bWQ4em9PN01FOXkydjYzZHlxQ3k5YjVhdTFxREc5WFNX?=
 =?utf-8?B?eTdHRDZ1MUtQcFEvUmJjRkllNGpablcyYmE5S1hiV1Ntb29sY3R1aU5ObVZ4?=
 =?utf-8?B?QTh4OTNXelVNSjUvN2F0NVdLai85UHVpeWVVYjVna3dhZXhVMFA5SHB2SHFJ?=
 =?utf-8?B?NDZEbVZhRnkrTkdheUkwL0xXV2NLMTBYOGVoemRiUTRkU2tMQjA1REloRDdh?=
 =?utf-8?B?ODJYSmFQcjkwemZmdkxwNWpYRlN1QndTMTcycXJISzV6dFJyelJ5T1lZNHJx?=
 =?utf-8?B?cHlqZDRleU5zendsTTNsMFhVNDg0QUJrMDNsbDVEb2N3NWZ1dkFlbDlaRU41?=
 =?utf-8?B?cGNxM0NrUy9NN21mVjhWUmRyaW1XMzI0SDlrMmpIRmlERXJIaW9MMnl1bHl2?=
 =?utf-8?B?em1MY05mbVBSUnNGTVNJQzRXM2NlaHFDRGdqODg1dVZ1eEo4TFRja1JYcHdo?=
 =?utf-8?B?NmNHOUVtWXpBbjdxSkpDWW5WWjVyUWlDWnNlQTFLVzc1aXA1NjFEME9zV3ZL?=
 =?utf-8?B?ZFFyQzNHVUpkQ2ZwR1hraEljckxzemVJZHc0cmVLZGpFVnlic1pzZ1V0VTR1?=
 =?utf-8?B?SVFXTzFsTTg0djEyWlZpWnZsRmFQNUFwOGwydHpleGxXNitYWVZ5cUZQcU5i?=
 =?utf-8?B?c3lMSXZERWhGWXhka0VPczBub0FWRHdCM2pKVkVBdjVaaU9Ic2FoL0NJSkFV?=
 =?utf-8?B?Vlk2T3JqNzVDZjNtTEwrWXpkUkQ0VVVjNzhobkFkNk94aGxCQWtCZkdjK0NC?=
 =?utf-8?B?ZEFReTNqQTduRVZGWHFCNUcveXFOaGVTakN3UWdETVpTNTMxcWJsaFNGVkM4?=
 =?utf-8?B?dDBDL0NJUG8rTElSdy8rSDhueVg0dituSDBMOUo3K3B4WjNtSSs3NTJtc0lj?=
 =?utf-8?B?VTk3ZkhHZkZ1ejNQc0R4ZUVia0tCRHVCbFAwd2hEbXhOQ1IyUnF0cVJxTzR5?=
 =?utf-8?B?WDdDZm5XN2NyZmF5SjhRd2dBUGdGRXp3MGhSRUpTZXZIc0JCSXdQc3Zzelp4?=
 =?utf-8?B?QVJ4QW9YWEp3RlB2anJudWVzNFpnRVFObGtBWUVlakFvZlRZQ1JIK0dsckg0?=
 =?utf-8?B?MDdXZllLeXh5aTlKa1I3RDRGQmJUUW5jRTk3N3F2MkMvYkcvM0IybFI2SDZF?=
 =?utf-8?B?cStNRDlRM1FjeTkvLzFSTCtPUmRKbGhVQmpxODBqMGxJOGV1eVRjZFdkSlhq?=
 =?utf-8?B?RDQ4SGkwT3pISXJsRjB4K01FeHVEOXhNb2ptQ1VxRU1zR3NzcFJEWURIMit3?=
 =?utf-8?B?QVpKSHJ4a0tKVThzRWFwcGV0b0c4OTNpWXpmL0ltU1RrOVR6L2xkWWJoMys4?=
 =?utf-8?B?NnN2T1Zid1JRPT0=?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MTBPSStQMnF6MHBFbnpsUG9IRkxOb1ZQK0xSaU16eks4cWx3QTlFeUd4eTFQ?=
 =?utf-8?B?ckxRcFdVMk5TdjJKTEMrSnBRczk1L01nUkdFNkUwVnVJZ2tzbkJtMkE5cnN4?=
 =?utf-8?B?QWFRdUdVNk9oMkxHdEZiL2sxeEZVbTJXNXRuSHZ5NVhYNmZNVGdLSXJ2bEll?=
 =?utf-8?B?RkZmeHJzdlBVUVloT3lpTlRjQ3N4TGhIMWNTL3lzRmhKbW5nWWt2ZHBRN0RL?=
 =?utf-8?B?SndMMU1xRmwvaktqUVRKdHQ4V28xSEZHOC9oakI3ZUVKTFlhTkQza1pIbk05?=
 =?utf-8?B?UGJXVHZhektXZFdFZVRIVkUzQ0lRL2J1eXIwdmc3Ujk4UkNyQm9HbVByVE1X?=
 =?utf-8?B?Yzl0TUpieFJ0emhIRVYzVWVhQkN6Qzk2Y0N0U0VmbHFBY2pSakxkYld1ekhk?=
 =?utf-8?B?TnNBRjBqVkF3MnlGTTJkeDZ1b0JFcmVUQTRpNWlFUGkwU1A0MFRoVEFIeVl0?=
 =?utf-8?B?RGdqQ01nNlFVOTJiQ2s2QWpXemFpclBab2d6WjNxMlVEcXZmQmpYS0FOZ1Ju?=
 =?utf-8?B?SisrNHpNRWhUcDhOWDhyQlR3L1dlUThTMXQyOTZUYjlQRU52L01scUxKcWha?=
 =?utf-8?B?LzhQYTQ2OEZ2R3AySUs5dG5VMTFydTRab1p2Y09qd2QyMlpFUkNRd0NKcVMz?=
 =?utf-8?B?M0k3QVpPRUNNcGd3L0huTmtHZk9CUHhPZTJncHpCQUNhUk5jY0FyUnlremJv?=
 =?utf-8?B?UG56cFMwK2JVU0ZUM1A1bzRYcktBRUZmdDFqTDVYUUVKWHFhQmpaT0NLTi9q?=
 =?utf-8?B?UVgxOEVvTmxuTUQ0TmxCTFZhblI1TjN6MlNMcnVlem9LVVBRSC9ma1c3NXU4?=
 =?utf-8?B?R3ZteW1tbkxFNHE2WWZPN2hLbVZlRGJ6ZThrTDlsbldIRkhnQ2gvbkMvakJW?=
 =?utf-8?B?clQ3akN1eVd0a2dnaUFqdE9PMm4rM2FPSEM1bUVUTlMzVmptNmkvdXdwM2s2?=
 =?utf-8?B?UVkzRTlManIrL0t3WXFPbGJJeTN5bXZWQi9mZVhQejAwY0NtQWdzMGZrVXBq?=
 =?utf-8?B?aSszeUFXZEh6aUJMWWFOTU42NGR4UWhjcER2T2QwMTViZkxDWEs1Y3hWREFq?=
 =?utf-8?B?Rlp5QUNRNmdtYWZ2d3ZOMmdHa29vdnRacGJKRFVhUDlxYTNTZFdsQkh2U3hQ?=
 =?utf-8?B?RkF3NzRGdFlLaDFZSlBRZ0F6MjlqWFJDOWhZRGR1UUlPZkVlVXk0NjFKMVlj?=
 =?utf-8?B?L1pkNU9WSFVjcUJJdmRVWGZKT0JTSVZkaUxEYk1LSkIzYXhSVWpTKzM4T2F4?=
 =?utf-8?B?NTNYNVhIRE5rL1E2blJ2eWhpcWN1ejdHRzdXRFkrM3BsNVZmaW5Pa1lJa1Rl?=
 =?utf-8?B?eWFPSGk3V1FCMkFkY2prbDZKMU95bUpqRWh5VEFzdi9NNEtjdjZCRVNKUFll?=
 =?utf-8?B?dkhCOXk1UDFjTlpXL2ROOWNFVk9aWUU5RXZUTFNkekFQTkdoZHVCLzZTV0hm?=
 =?utf-8?B?VEorSmtQZDQxK2pWTzNwVURHUDR5dXU5SFZEZDZmd2tVN2xuV1c5MjhkNTUx?=
 =?utf-8?B?NjNnRVR3Mlhya2lsZ2xTZUhDZlAza0RQV2tBaEpVMlN1RFkveXZXb3lZSnBI?=
 =?utf-8?B?Yi9kSTh0WEcxc005c3A0VTVoY25DNEQvMG1iSnhOYmJPZTd0d0wvNDBaZEhq?=
 =?utf-8?B?MkwybXRibGtxWmUvSjZyeUE4LzdMU0syNE5uQUd4L3h6eVoyalFTcldBUWk5?=
 =?utf-8?B?bEFhekx5WkJXQzdvZVBtK3BIdkFjdWpnNDduUmFqTUVYTTFKbHRXNVVDWHhr?=
 =?utf-8?B?eWR6TTEwdXZFSE9GaXU3anVsZDFKNnQwRFRpcWZsRFp0aWw1d2JvblFUZlJF?=
 =?utf-8?B?Vk5LWngrdHVJTjl3cTh4bVM5aUZML1VLN0pBUHlMbkt4VDkvSGdTcmdBWGRx?=
 =?utf-8?B?eGozZVhJWktzNjZ2WUtHc0lxZzFuTFkwRldqeDA4SzY3dmQ3bEx0SnZOajdp?=
 =?utf-8?B?Rkg1U29sOExBWnZaRWRLNjN6WERyRFcvRnZiemY3aGNSaENuK1duYVFrRHl2?=
 =?utf-8?B?UHdCZUc1bnJ0c2EzblM2c2xzRUFJd21JRVJLeG5ZdWw0SW5sMWVnMWkvRGJq?=
 =?utf-8?B?QTVybjVJcTlVRk1DaEFtaC90cWYrU1RBSDRsSUNlK0N1Q2ZENWxFK2hyYzZt?=
 =?utf-8?Q?+a80=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: cc986f6a-2dd9-48c5-1fef-08ddfc09b0cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 08:01:10.7522
 (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: 5p2I1VZ6QI5qM3LGz3hNVnIISHPDLWQnmEF7aKHoUheTrTWJCfVf/7UheQcpAf0aHnUBZu1uIpNIlJLcldRGsg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4242

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEs
IDIwMjUgNzoyOCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPjsg
U3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPiBDYzogSHVh
bmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3Jn
PjsgQmVydHJhbmQNCj4gTWFycXVpcyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPjsgT3J6ZWws
IE1pY2hhbCA8TWljaGFsLk9yemVsQGFtZC5jb20+Ow0KPiBWb2xvZHlteXIgQmFiY2h1ayA8Vm9s
b2R5bXlyX0JhYmNodWtAZXBhbS5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRyZXcuY29vcGVy
M0BjaXRyaXguY29tPjsgQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+
Ow0KPiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IHhlbi1kZXZlbEBs
aXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHYyIDE2LzI2XSB4ZW4v
ZG9tY3RsOiB3cmFwIGFyY2gtc3BlY2lmaWMNCj4gZG9tYWluX3NldF90aW1lX29mZnNldCgpIHdp
dGggQ09ORklHX01HTVRfSFlQRVJDQUxMUw0KPg0KPiBPbiAxMC4wOS4yMDI1IDA5OjM4LCBQZW5u
eSBaaGVuZyB3cm90ZToNCj4gPiBBcmNoLXNwZWNpZmljIGRvbWFpbl9zZXRfdGltZV9vZmZzZXQo
KSBpcyByZXNwb25pc2JsZSBmb3INCj4gPiBYRU5fRE9NQ1RMX3NldHRpbWVvZmZzZXQgZG9tY3Rs
LW9wLCBhbmQgc2hhbGwgYmUgd3JhcHBlZCB3aXRoDQo+ID4gQ09ORklHX01HTVRfSFlQRVJDQUxM
UyBXcmFwIFhFTl9ET01DVExfc2V0dGltZW9mZnNldC1jYXNlDQo+IHRyYW5zaWVudGx5DQo+ID4g
d2l0aCBDT05GSUdfTUdNVF9IWVBFUkNBTExTLCBhbmQgaXQgd2lsbCBiZSByZW1vdmVkIHdoZW4g
aW50cm9kdWNpbmcNCj4gPiBDT05GSUdfTUdNVF9IWVBFUkNBTExTIG9uIHRoZSBjb21tb24vZG9t
Y3RsLmMgaW4gdGhlIGxhc3QuDQo+DQo+IEFzIEkga2VlcCBzZWVpbmcgdGhpcyBzYW1lIHdvcmRp
bmcsIEkgZmluYWxseSBoYXZlIHRvIHNheSBzb21ldGhpbmcgdGhlcmUgYXMNCj4gd2VsbDogRm9y
IG9uZSwgdGhlIGxhc3QgcGF0Y2ggZG9lc24ndCBpbnRyb2R1Y2UgQ09ORklHX01HTVRfSFlQRVJD
QUxMUyBvbg0KPiBjb21tb24vZG9tY3RsLmMuIEluIGluc3RlYWQgbWFrZXMgdGhlIGJ1aWxkaW5n
IG9mIGNvbW1vbi9kb21jdGwubyBjb25kaXRpb25hbA0KPiB1cG9uIHRoYXQgY29udHJvbCBiZWlu
ZyBzZXQuIEFuZCB0aGVuLCAiaW4gdGhlIGxhc3QiIChidHcgLSBsYXN0IHdoYXQ/KSBpcyBhcyB1
bmhlbHBmdWwNCj4gYXMgImluIHRoZSBuZXh0IHBhdGNoIiBvciAiaW4gdGhlIHByZXZpb3VzIHBh
dGNoIi4gV2hlbiB3cml0aW5nIGNvbW1pdCBtZXNzYWdlcywNCj4geW91IHdhbnQgdG8gbWFrZSBz
dXJlIHRoZXkgbWFrZSBzZW5zZSBhbGwgb24gdGhlaXIgb3duLCBubyBtYXR0ZXIgaW4gd2hhdCBv
cmRlcg0KPiBwYXRjaGVzIGFyZSBjb21taXR0ZWQgKGluIHBhcnRpY3VsYXIgcG9zc2libHkgcGll
Y2VtZWFsIGFuZCBpbnRlcnNwZXJzZWQgd2l0aCBvdGhlcg0KPiBwYXRjaGVzKS4gUG9zc2libGUg
cmVwbGFjZW1lbnQgd29yZGluZzoNCj4NCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgY2xhcmlm
aWNhdGlvbiEgTGVhcm5lZCBhbmQgd2lsbCBmaXgNCg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:04:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:04:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130159.1469763 (Exim 4.92)
	(envelope-from )
	id 1v1gxT-0005nf-5d; Thu, 25 Sep 2025 08:04:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130159.1469763; Thu, 25 Sep 2025 08:04: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 1v1gxT-0005nY-2b; Thu, 25 Sep 2025 08:04:07 +0000
Received: by outflank-mailman (input) for mailman id 1130159;
 Thu, 25 Sep 2025 08:04: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 1v1gxR-0005nS-US
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:04:06 +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 34273c4e-99e6-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 10:04:04 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by AM4PR03MB11150.eurprd03.prod.outlook.com (2603:10a6:20b:6cd::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Thu, 25 Sep
 2025 08:04:02 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 08:04: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: 34273c4e-99e6-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cwTewvEEZ/X1q11z8iXDr/ETVotq2QsUNbPmMh83/BoUfQwudtIe1pjLLV0HuRzzhaReboBIf3WCSLoU1fM8kyhcjryXhnd9O7OWRt0isBZmOFVBUnxxO3P8izCSMohzEbOrPEKf48Fwqv+xYdEZwECVN3r4pzbqW+9cpXItJJIwJVa5On1aovLlCRycPugjT+5KStId93vDPJ/n3T9s96DHSlwaxua8Uw8Ozzc5VQQN50FOPnadETzJnlyTONm86HTIBUdSohH92r0swwBwCyrJUptzfcZCmHCMBjCQqc7Xcm8wGI8x3O6cfbffTwNddsuR0ANX23p0WjdAmfdyow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i8V2jw3fijVSbwQ06T/ajwKaq0sDOYQhSJ9TEUxgnxU=;
 b=lFB+ZT3upn2jmcxFCgW/93gX/Yojxc1SJCMfjqOt7TrvoME3Q4whtoFRJZ5fjONZArZPbFNnKbwXr/+d2Dtu6QGQ7Qvbk3prY0rFT5QIi8gq3+YivhquUf01e3YuoNsTET0nxXU1v6mD1hAvJBbjTIvcmZya3c6OrqMya3C95kfinws/KQbyhHIF2B8P5p9i9zNOqxw2SK/zFmGKptSbZDgiNwVZ6lhR0YAeLcAjh07OuGDFgRTKkP25Iuw3EOttwi4ImyetuEdPmeB1rv7LPSsYKzKCeHN75UcpDt7ehHmnGx/rz9TuC4WgMNLTSnqIxsTUBkZb24DuwrUfGeHfxg==
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=i8V2jw3fijVSbwQ06T/ajwKaq0sDOYQhSJ9TEUxgnxU=;
 b=nGeE21kQuUa2rmzlQBT6Q/jrvRkg//ZFA7uhzToBWUchwKHF5U7dMExPQvYh1zpGbTdhKBn8dyUtC/x6fumYeUGgERXOq9PaLT13I5k7gWg+N1uO5+2vagkF/QmzlGDEMyT/8xLFoL/1PSSY67GiGz4Z37OAJCMnEW0Bq4ugmoJEevG8reF6+Cfnwxl7HRQqiV0b3hsUHH71t21m+4TIAafasECiGdn5NyTRbd5jkszxdFivjVFOuGDz+5k6yoRuGPopCgWaAVtX39nbxfVovfogw81YiaXyx9mXMBRqMSZlRSGak7Vhxbw4EGMxOzrCS1ku/Ic6qpK+wNOvXAAA3w==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Nicola Vetrini
	, Doug Goldstein , Stefano
 Stabellini , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	
Subject: [PATCH v2] misra: consider conversion from UL or (void*) to function
 pointer as safe
Thread-Topic: [PATCH v2] misra: consider conversion from UL or (void*) to
 function pointer as safe
Thread-Index: AQHcLfLzOeq7/eyxK0Kcj9l07Fl9Xw==
Date: Thu, 25 Sep 2025 08:04:01 +0000
Message-ID:
 
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: GV2PR03MB9572:EE_|AM4PR03MB11150:EE_
x-ms-office365-filtering-correlation-id: 1abf08cd-f089-4e9b-47e8-08ddfc0a1656
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|1800799024|366016|42112799006|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?y+DdM+fkXr0hiiiSTum27aAicNTDe10hzJwSbhgmnc7+qnkQrGVtgFA7NA?=
 =?iso-8859-1?Q?m+bqNCUeRElrenyyP6SCFTXJN9ECwI8AHSApF9driAn9bje1by7knFXexk?=
 =?iso-8859-1?Q?yFfr2KRmCc7TTG33k/XG1dspVkmFAwfgn7SvW/BJsvr1BvE6Z6YpmLiblT?=
 =?iso-8859-1?Q?1Eibvc6NwapmSOgOAjglh3xdtQASmGl2ukDLIOKesOc2UxP7vnobYw2WZ9?=
 =?iso-8859-1?Q?WG4I4WjIp/hQ5uP1HyiFQY99pEF636XFZb8ZzlWHdfwwWh7euXGvVtSrWm?=
 =?iso-8859-1?Q?X2EuDRCSXFnv1SoEm/+cViS4XJwI0BSqDvSkwJ/8qWmeXGo2k4o/PgoAYv?=
 =?iso-8859-1?Q?mcEHwvhqKvNZVdBlkBkFFioNHrcsLDdXSiaxOWU++l+CyiyqF7cyxLWROU?=
 =?iso-8859-1?Q?Z1R0GRCbyEXxOa71fqUMTCPJP6O+it9PwhAa2omf19rhWWyGxl8X0hqa8a?=
 =?iso-8859-1?Q?WapN3+xyjnK0hFzYd7lmgd51O/h4mAgov1zn6H9Pap11OhkUoudcDQiTeJ?=
 =?iso-8859-1?Q?RpDNj4elvSTClYGgd3WSKPD3cW99/HiaFpq/sgW4ywFwhw/VG09ukjbJN9?=
 =?iso-8859-1?Q?ef8SIUGKwDOhEqQza05QWb1VRFGe9Mltvpz8jRTwLvtN55od70484LQ50y?=
 =?iso-8859-1?Q?dcC3hNeS56HxHwY68YRASWXbW6vIun1rTmkhGfH0WYdpe5yegSFfbEoZRn?=
 =?iso-8859-1?Q?vl4EzENCOwT0GVlDWfv6zvuj8q+D8BqP7o3rYlOMiHl8GEeVz5cJ4EhOde?=
 =?iso-8859-1?Q?vijlOlc0Nlxk/5072gj++Xslr94tvQauQdhLMetUFvtRPyeJgnlXvamhm2?=
 =?iso-8859-1?Q?4Jhe1nFFX5wZKnnR9OsmOffuizlm6QGKoQkuKgG++FxRy2q5KScSWlIwn/?=
 =?iso-8859-1?Q?h5wqYI1rq5vlgx+iTvuyRi6JtWdSHPC+gHaXISw1MUDehrERglI/R1Uzk3?=
 =?iso-8859-1?Q?RFhC/MIy+BQF5qsioNv7nbIUMe8emMy0KYeFrWY9FRGvwWZNApAIDwvzTN?=
 =?iso-8859-1?Q?xGWp29XpGLdgYW/E1tdnCV4y5w/QGP5Q6QUUCEF+bqkIDjyoKyFAx4wRD4?=
 =?iso-8859-1?Q?DxCXff3VmeTGYhFcy7lPgkNvkPN33kzH/CHGUVafFzEvwidD0A4q7IbBzb?=
 =?iso-8859-1?Q?ca7orjqftBPBualAZZlOaeh/bu6Vlc02yEbSRFkDptXk1tY9283i5hBzSt?=
 =?iso-8859-1?Q?IruVK/srMvPImT8Bjh8rwIr9VepjvdkEC9gP+xhA8n17b77hVSo8mNEna3?=
 =?iso-8859-1?Q?+7A6HxOP+52CrQG9ra1opMtCy+jsB1KJgA7ynG2lkhgfu4RiO7EGYj4Sis?=
 =?iso-8859-1?Q?lv4hLio71NDsxUx0ptzIh36fYljGyQ6zZfrqM1nxHyH+Qj+MfzCCw0gHMq?=
 =?iso-8859-1?Q?a8UKAmPc0AC8jvWUpd8M/i34nREeq+Rg+Jj7FmPcdHgW+QKW4uYhRJl56I?=
 =?iso-8859-1?Q?yXtffzKaKG8bMpiEPM2gcdWVnKL819y+apRwgD0KOB4ooLZmXb7G24UNWx?=
 =?iso-8859-1?Q?o=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(42112799006)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?XXpqWeU4VXvI8oUVMe3kuEXlaym2XYKHPdsWSutGOrLNlIAg3cRUXjwF4L?=
 =?iso-8859-1?Q?OKzRbIzR38A0JqdkwDgiAuRLFGw5Tt/N2m8y+hkFaNOAEqTYudm5H/jo3L?=
 =?iso-8859-1?Q?cLyht0JYuCI/AzsUnWoomRl96SP/Ncm76yWxQl2ONrPOQCnVPkFfDwyE3+?=
 =?iso-8859-1?Q?MD8afI2NaXSqJdnDDcY/1IYZXFy+8zREqkr+bhIa5lS8griVjNgx4A4z5z?=
 =?iso-8859-1?Q?wyfx2jaZO2UDsjxlX9hKLFMsfVdrUQVQ7d0G6MooBJztiubSFA2uutqAfH?=
 =?iso-8859-1?Q?2I324hF8Wz9AOIleSIzf38VKUNdSA95VZ+0xBoiOQESzgidsOvN5NS0CvH?=
 =?iso-8859-1?Q?iwXCMTuG4JxWvAgMkSV3AlFe+7/wDMaXpD0SjaBfzuz/UhBddpql19l5rG?=
 =?iso-8859-1?Q?+J5hXf+5TS8eyTytbdmTHs3sPmEK8Fq8t4OTpFrTbXAtjqd8HRlmYV9Rou?=
 =?iso-8859-1?Q?lNqrFyBq0gLbtyIrlmK4mupjXCBcO9eikpKzydX0xlAdOGkPIddus4HeEH?=
 =?iso-8859-1?Q?ifJ9em/y+Jl0mM4iXhaVQyni0Lm9mtoPiPU/axI1chUC05DFSNOmEqbFFM?=
 =?iso-8859-1?Q?cJUmr/cEIY4wUmQQVgtEgA3xUOFfUt+jS6XVJGVXU+CIMByR+Y4i0qn3Fn?=
 =?iso-8859-1?Q?jra18o9qVtVs9t3L3oekLVdzor/w+iQvnZEOpUNHzmN8mX3ddt2noThT6u?=
 =?iso-8859-1?Q?0t/zpXyQan/hFyti9f9jPuwxXLtBQzc058TyBkYjdc+Ng/taXp4APMLbAd?=
 =?iso-8859-1?Q?uaNK7s5N2+4kJmLSmvDbcWR7mQGiD3VKaedGNjz+1f7UXOQiUEB4WuKwza?=
 =?iso-8859-1?Q?FwdXzXBFHAPtGVpqHNQxCywxJ5eCsO5zeQmpGB1vJIJoylnWTW6fQq6xTd?=
 =?iso-8859-1?Q?WvDCUZ8maH47E+6gGVybaRMxA9aN+BOyNZPLMZjnWqP5sdDyVYd55v0mVh?=
 =?iso-8859-1?Q?iMXpPxjN5qcbM5auvgnYrixpBfgcJxEDbWj9/WxBjgHtTXm82zEKO7rZA2?=
 =?iso-8859-1?Q?rTZitOVQttdVTsyTqYV4OBYnjSBmyZOnhDHLGRWVGxyTeOZjMNTUr+P9qN?=
 =?iso-8859-1?Q?1T6oTqr19CT482Q/gk1YAH/0vxaSL7N+qaLF5+Y08//2ASof8/jwMCLpav?=
 =?iso-8859-1?Q?c8U8dOPtUU/RnGn9nW3go5w972L9TgkRcr3b0ILA8oSV7zNSlKnWuSerXk?=
 =?iso-8859-1?Q?X+uSKh9OZyOpSYDtEubecYB59RcSYQ89vKUzKJ/1rcM4Zw+WYFIjz3IMaP?=
 =?iso-8859-1?Q?9RWV51C22IhGwTW9BwEW5sFL8wViSSl0cFWgxWuiwqqB7puqTAe66+OpnD?=
 =?iso-8859-1?Q?9JD3LLwfuZbHS+hlHMtTiaD2UwK5zv0ofp2G7rt/Q/57uUi+4dq60cClht?=
 =?iso-8859-1?Q?D94bUmPJ9sWxofj8pgAL3j7gpaKbH+kYgKpRbic5njL3XuNyyombQ+nETr?=
 =?iso-8859-1?Q?qdgCND50nvF56/2omPwTqmkRbqqKtqOrj4v0TnE787D1nQFhg9aVZz8wxx?=
 =?iso-8859-1?Q?XQ+yPIf7vhupQqqaASjC4e6nUuEzKbDC0B07VEdOY10JyqnOWfIRAob7Dr?=
 =?iso-8859-1?Q?loOVnT75SCaRkjNWe8J6hKjkAQHpBzxHxBkwQviOmqsx6NtAWpnJ0k34qy?=
 =?iso-8859-1?Q?A+iM1yhPYqmh6++YROY7fDDeTmGEtpzzOZS8xKjgBk10IVA3+Fv2vteA?=
 =?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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1abf08cd-f089-4e9b-47e8-08ddfc0a1656
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 08:04:01.0904
 (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: BPJbV8KnhRsupnrMZoGkXgUjtljGYh+aEvXc4wfwyfUomKAOBA0uX+nsNt3bufSnQP2JzKZQSXt+W2/bATpXi4D1a8e2TbKxDOzFoBEnYoc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB11150

Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."

This deviation from Rule 11.1 relies on both ABI definitions and compiler
implementations supported by Xen. The System V x86_64 ABI and the AArch64
ELF ABI define consistent and compatible representations (i.e., having
the same size and memory layout) for (void *), unsigned long, and function
pointers, enabling safe conversions between these types without data loss
or corruption. Additionally, GCC and Clang, faithfully implement the ABI
specifications, ensuring that the generated machine code conforms to these
guarantees. Developers must note that this behavior is not universal and
depends on platform-specific ABIs and compiler implementations.

Configure Eclair to avoid reporting violations for conversions from
unsigned long or (void *) to a function pointer.

Add a compile-time assertion into the file 'xen/common/version.c' to
confirm this conversion compatibility across all target platforms
(assuming this file is common for all platforms).

References:
- System V x86_64 ABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/arti=
facts/master/raw/x86-64-ABI/abi.pdf?job=3Dbuild
- AArch64 ELF ABI: https://github.com/ARM-software/abi-aa/releases
- GCC: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
- Clang: https://clang.llvm.org/docs/CrossCompilation.html

Signed-off-by: Dmytro Prokopchuk 
Reviewed-by: Nicola Vetrini 
---
Changes in v2:
- updated commit message and deviation wording
- added Nicola's tag
- replaced "(void \*)" by a quoted form in one place

Link to v1:
https://patchew.org/Xen/9e5e4ff2c7ba0a90a6ac403e2de9318e18949274.1755628705=
.git.dmytro._5Fprokopchuk1@epam.com/
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 10 ++++++++++
 docs/misra/deviations.rst                        | 13 ++++++++++++-
 docs/misra/rules.rst                             |  7 ++++++-
 xen/common/version.c                             | 11 +++++++++++
 4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/=
eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..432a68ae5a 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -375,6 +375,16 @@ constant expressions are required.\""
 }
 -doc_end
=20
+-doc_begin=3D"The conversion from unsigned long or (void *) to a function =
pointer is safe because it relies on both ABI definitions and compiler impl=
ementations supported by Xen
+which define consistent and compatible representations (i.e., having the s=
ame size and memory layout) for (void *), unsigned long, and function point=
ers, enabling safe
+conversions between these types without data loss or corruption."
+-config=3DMC3A2.R11.1,casts+=3D{safe,
+  "from(type(canonical(builtin(unsigned long)||pointer(builtin(void)))))
+   &&to(type(canonical(__function_pointer_types)))
+   &&relation(definitely_preserves_value)"
+}
+-doc_end
+
 -doc_begin=3D"The conversion from a function pointer to a boolean has a we=
ll-known semantics that do not lead to unexpected behaviour."
 -config=3DMC3A2.R11.1,casts+=3D{safe,
   "from(type(canonical(__function_pointer_types)))
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 3271317206..565e65a6a3 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
      - Tagged as `safe` for ECLAIR.
=20
    * - R11.1
-     - The conversion from a function pointer to unsigned long or (void \*=
) does
+     - The conversion from a function pointer to unsigned long or '(void *=
)' does
        not lose any information, provided that the target type has enough =
bits
        to store it.
      - Tagged as `safe` for ECLAIR.
=20
+   * - R11.1
+     - The conversion from unsigned long or '(void *)' to a function point=
er is
+       safe because it relies on both ABI definitions and compiler impleme=
ntations
+       supported by Xen which define consistent and compatible representat=
ions
+       (i.e., having the same size and memory layout) for '(void *)', unsi=
gned
+       long, and function pointers, enabling safe conversions between thes=
e types
+       without data loss or corruption. The compile-time assertions (BUILD=
_BUG_ON
+       macro) is integrated into 'xen/common/version.c' to confirm convers=
ions
+       compatibility across all target platforms.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.1
      - The conversion from a function pointer to a boolean has a well-know=
n
        semantics that do not lead to unexpected behaviour.
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 4388010ec9..4e94251887 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -431,7 +431,12 @@ maintainers if you want to suggest a change.
      - All conversions to integer types are permitted if the destination
        type has enough bits to hold the entire value. Conversions to bool
        and void* are permitted. Conversions from 'void noreturn (*)(...)'
-       to 'void (*)(...)' are permitted.
+       to 'void (*)(...)' are permitted. Conversions from unsigned long or
+       '(void *)' to a function pointer are permitted.
+       Example::
+
+           unsigned long func_addr =3D (unsigned long)&some_function;
+           void (*restored_func)(void) =3D (void (*)(void))func_addr;
=20
    * - `Rule 11.2 `_
      - Required
diff --git a/xen/common/version.c b/xen/common/version.c
index 553b97ba9b..7091a6d440 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -217,6 +217,17 @@ void __init xen_build_init(void)
 #endif /* CONFIG_X86 */
 }
 #endif /* BUILD_ID */
+
+static void __init __maybe_unused build_assertions(void)
+{
+    /*
+     * To confirm conversion compatibility between unsigned long, (void *)
+     * and function pointers for all supported architectures.
+     */
+    BUILD_BUG_ON(sizeof(unsigned long) !=3D sizeof(void (*)(void)));
+    BUILD_BUG_ON(sizeof(void *) !=3D sizeof(void (*)(void)));
+}
+
 /*
  * Local variables:
  * mode: C
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:11:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:11:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130179.1469773 (Exim 4.92)
	(envelope-from )
	id 1v1h44-0007dY-Vq; Thu, 25 Sep 2025 08:10:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130179.1469773; Thu, 25 Sep 2025 08:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1h44-0007dR-Sd; Thu, 25 Sep 2025 08:10:56 +0000
Received: by outflank-mailman (input) for mailman id 1130179;
 Thu, 25 Sep 2025 08:10: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 1v1h43-0007dL-Qt
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:10:55 +0000
Received: from BYAPR05CU005.outbound.protection.outlook.com
 (mail-westusazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c000::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 271dfe40-99e7-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 10:10:53 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB5620.namprd12.prod.outlook.com (2603:10b6:510:137::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.19; Thu, 25 Sep 2025 08:10:48 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 08:10: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: 271dfe40-99e7-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JqDzJxPulIu74dNkEE9ukhNibm6RlFj5qYtA1PMQzM4L5T/m3sWJ8cNYUdKI1BRG5ebBE86I6b0P/FFTsBgfXm+4xZSnqtwlhEUwAAwjyOoo5h39yU+xWl2f4grGqxmIR+8ECA5pppd5TUyFu9cgSOaGs9m/H2jRpvGDDHAO7gDZlUctFmN0osWSqJYX/ScEggzBHe+zBLOWafqKc/TTAkUFB7jZPVrU4o0wjCmRdwnQT6Mx90L6A9er9TNkK3VRq47mJ7lcboM3DJYNyGRW6EJQQwaUddXQnvQ/M6ZdvTHfdda9HevLUwYPmqt82fO2vE97Ecb5q5Sj/xPye8lG0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ve0AF8Q8uTN+d7J109dtLBBvDpkWypkIvr7VpucyulM=;
 b=mkv5Bcl3ZYPV1f8wQbZ25xx1lH5kQBS0K9PBvGjiWlEF+KUmPLRJHxuJMgIiJFPVTfhljvTF1IZ0PXkLYZ0vBRrs7JwOSCqZNG8WRdG+3vnFi551kjCUbTeJ+zk7LCWhsSKtX1IxDOcLroGMd+aemWZf9pNorqcpCun14vm+LtFA0rUCD+zwGGPv0WLe4qdHDeZUKJ67C34eApai9lBsCrNTJHBqv3hQ8KXU2u2imC0GiGrqoJkjPzg38m5TU04OxB2umaFC75NbIjC6hRgWhw2engjN1A+dw9R2dZcOJMDjiE5QbaZjEvjFAQS9k64OzNpF8r21puqTIRfWgUIhAQ==
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=Ve0AF8Q8uTN+d7J109dtLBBvDpkWypkIvr7VpucyulM=;
 b=Y0+Npw++tVh9gTf78yWCX6SXG9X4+jGtRiSW3Uldr84/8Ev/Su6COAZNyxX6R9aQsK6MsVQBet/zEVBw08/vpSOW2juDAimqSg4kzZA7RaO+55vCoWJYUe54Jscpr6Mzn8xFgD74WT/MYb+4ECHRHTmNMkM3qn1NXfs7PRQseqM=
From: "Penny, Zheng" 
To: Jan Beulich , Stefano Stabellini
	
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Daniel P. Smith" ,
	Stefano Stabellini 
Subject: RE: [PATCH v2 17/26] xen/domctl: wrap xsm_set_target() with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 17/26] xen/domctl: wrap xsm_set_target() with
 CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYXdlMjGvcRv02JcgghJSn63bSNRauAgACV6QCAFcYywA==
Date: Thu, 25 Sep 2025 08:10:48 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-18-Penny.Zheng@amd.com>
 
 <62c80f82-d85d-4d11-a7f2-4193bc882911@suse.com>
In-Reply-To: <62c80f82-d85d-4d11-a7f2-4193bc882911@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-09-25T08:04:53.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_|PH7PR12MB5620:EE_
x-ms-office365-filtering-correlation-id: 60139f70-c0fe-46f2-30a2-08ddfc0b094c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?T0VpU0dGWWkydytEcFovYWxlYW42bE5tSUFEQ0I3eTdWM2tTRGM3L21zekUx?=
 =?utf-8?B?UkZDZFR1Y0Fmc09iZHRldkdDZ3E4NENROVhQSnZhb1VaVlpRMDJ3aUxjRVhy?=
 =?utf-8?B?NXo2YU5IRGkrbS9aZXMvV0pKNDlmMjBtb2ZINUxOWFo2RnNBVWZHTTBpcUZm?=
 =?utf-8?B?OWt1bDhVZmVicWpPSk5CS1BYQURCcVBxUlVpTTdOVmk4RWdPdWpQTDd1b0xh?=
 =?utf-8?B?K2RaMk5sbTUrb1F0UndtcFZkOVI1TUs5Q2laZmFWNGJleThiR1VNN3FuMnhu?=
 =?utf-8?B?dnF5bFRnRXVLaHE2NjBlMkZLZE1QMXhQeXBicFhjSTJCSGFoemYvZGNPMWxo?=
 =?utf-8?B?bjN1QmhuL2pXM3h0d0ozY0V1RFNKUDFRT2ZSNHhwRUxia2NiOG5QMUxPa1M3?=
 =?utf-8?B?K1ZrQ2dTcnFLMjhIeFUvL2hJdDBnVWxLUDlWOXdkNVF6MHdhcDhBLzJOc3R6?=
 =?utf-8?B?eXlrRldjeFNvYkFhcUlVcDlqZlNBZVExWU1IMXFCMFpIOGFZRFg3TFJQazZ5?=
 =?utf-8?B?bGFxdEcvbnN3cExVclhTVkdMTU5sT2Y2L1BaTnBySHFKbnVONXhVZ1NGRWNw?=
 =?utf-8?B?MTVsYU9ub3pXRDZaQjcvYk0vWHpyMVNRczdpMHNXaG01M1R0czE0MHoyYVll?=
 =?utf-8?B?YnMzYlhFQjdhV2c2Wmh4L0xzeUM1blB3b29QZWNsa3hpeEJHcGNUUm9SM3FJ?=
 =?utf-8?B?OGJPWDNhVzVidU9VdExEUjh0aGJrZnllMExyUEEzZFRkNVFyd21icEhRY0Jy?=
 =?utf-8?B?M09leU5kYm05ODNTZXVYYS9hNnNuMlZFRjJBbmNvSUY2OEMyZVl6UDN1YUhS?=
 =?utf-8?B?aFdMc1hEcmNOV1l3bWhibDN4K1AxU3dlSnh2ZFFJYmdCeW5meVhCRld3Yk43?=
 =?utf-8?B?RFdaei9NSzM1RFZpVmdqK01qNkxwTlVpeVhZZEtNVGJ2dTkwa1Q0c3owclUv?=
 =?utf-8?B?akRVUmtYSWdPQ0J5L2xJell1M1VacG14TXhqcWdaWjR5YVhEYXZpaVJVWXNh?=
 =?utf-8?B?T213bnJTYnRiUVRFcDFTTUlucmpmYitackN0MDF5ZU9WL3BHNTA5OFB0L2pZ?=
 =?utf-8?B?N1hnTlRWa0dONDdUZ0gvTXNpcEdCTklMZmU5L2ZzeTlrc29FSGJscUhiT2tW?=
 =?utf-8?B?YisyU2RVRXFMSzl6d25yaWtISnZsUVlzUktabFY0eXc5dDBBczJjQnA0UjJN?=
 =?utf-8?B?TCtqeFNrVS9PQmFGOWdONCttc1pzUEZTN29sb3RmaTdVclVKT2pwbEdqL1Nr?=
 =?utf-8?B?bmpUU05EclIxWE5IR0FpY2pYYnYvNmFTdlBMNlFpc2dnODZpM3k0S3B0NTNH?=
 =?utf-8?B?N0ZjTTFHSk5ia3FNVkxwM2pXU0lkOXBZcFhFYzMyYnJZNXVwVUNuVTN1bkUv?=
 =?utf-8?B?cFlGLzk4czBQazRLOGpMNzRyUkJJSDRxQjRvVXErQjQ1WG1lUEN2Q2M1WGFu?=
 =?utf-8?B?dUdlbkp4S3RrRW1VQWkvaUtIV0RxZlBFdXV0bjVkRy9iWlp3bzBtT1hLODc0?=
 =?utf-8?B?ZnhSTnkxcncwbmt3SEtIa3M4TUM0ZTBtdllqaWxncG16WFdqbzNjOUJzUVZj?=
 =?utf-8?B?L09RL0YrZVVyS3doUFBHWC9GeGtSMG04eXFORS93blN1NkdtdTdHSndNV3Z6?=
 =?utf-8?B?SjkxU1FmcWVRZ1MxM2s0Z3hHSG9BcW5jTGg2alJ3d2RGSHNtb2NoSm1WTUpa?=
 =?utf-8?B?bXIzMDF0T0hPZVdqbTkzZ05ud0xnVEI0ZE9RNTFHY2czRG1NYnRQR1ZlSEhQ?=
 =?utf-8?B?RnF4WFhYQmFDaVhhV0tDaDVxUzFzd2Fid2tZaDRqZTNCdVk0cW5zcVh5QjJG?=
 =?utf-8?B?OHZiRVJsSzRHNHZRTjRXMHlOS2g2QXl4dDlFQzkwWWZiMW4wdEkvS29lQW1p?=
 =?utf-8?B?ZVZPTGxzL2FSa1BLYjQvV2VGdXpPUlhDajQwU1JBQWhVa2Via0pTcURjRnRI?=
 =?utf-8?B?MHpDZHYyU2NMd1JPOGFEbGZFUjgxU002V3lZVmVLb2F0bVpvQ3c3YWRlNUpG?=
 =?utf-8?B?OXh0M3dtSzdvbWJzNllIOWtscGdDUHM3L1lOTDdWakZIYlFscWxNL3M2M0dE?=
 =?utf-8?Q?7NtrGn?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SG9MQ0Flb0RESWVMaE1pQmdXREdDYkJEQ1V2SFNFUHlZWncrc2FaR09hWHoz?=
 =?utf-8?B?WW1LNTFGQTNncSs1MHdENDNXNG1tMjkrSmNSc1N1YmkySU1CVUtud3ZuOC9q?=
 =?utf-8?B?bldRZ1MrNitEcnVjSHFCandzS1BwMVRyMDBRTW8rRlQ5OHAydlZCbXZXRVp6?=
 =?utf-8?B?a1JUQmZHMGJYaW1XZDJnK253b29VVlBmeHNRT21HSklaQVRoYzNNNEdscVRr?=
 =?utf-8?B?Zy9yQ2hlRnlycjFxNjd3Z0tUVmcrTzMyaXlwaDQvdlp4d3lmaGYyZkpVZGc1?=
 =?utf-8?B?dzJBWVY1alp5dEpTM3p4bWdRUFlONnpHQnFmd3dicHJORzRCKzNOTzRuOWVM?=
 =?utf-8?B?OE44N3dvNDlNcUl0R05XczlYMHpNclRtbTh3R0JabUIvVlJlL3RjOC84WWM0?=
 =?utf-8?B?R2N4SXgxZmpzTnRXVmtjUGs5L2hkeGxBOHlaV1RYanExc3I5cnFxemxHSjdI?=
 =?utf-8?B?TjN4eCtpS2pZb3ZzRUIvNEhqVU5UVkFEcFdDTTBienMyd01TeCtZZjN3Q2dZ?=
 =?utf-8?B?TXB3d2NmTzVHUTN6WGxRMUlSb2tYZit0cG1hbXNIOUd2UUlDcmNGUHozcHVa?=
 =?utf-8?B?dnlTKzhNU3pVdW5Wc0NPN2N4Tyt0SVRQcmpzeHBEK0ZXRXRzSFZleUpqeDk1?=
 =?utf-8?B?Q0FKeThxcWhYSk04RU8zWkx6bGJVWCs5NkM5SjRUVW91akl0NGpIcFJPN3Q4?=
 =?utf-8?B?V3d1cE9sQXVnYXFmcGxrRHRYeUtqMjZxSnNKcXpqenpRYzRyOTdoVmM3dlJE?=
 =?utf-8?B?QTlXcXB5eVI5aEtJY3RrZEVQQ29ZRHVpeVZIWTJzTUg1TzdPVjFzNTN3S0pr?=
 =?utf-8?B?VndnblZkeDc2aHRYbThCRXZ2VmdDdWI4YjQ4SllYODB2RDdWbDZaMmkreHA4?=
 =?utf-8?B?cVFONGM0WUZ1amNQVEVDQ1A2TjIvcUlzL2JqRnlrYVdHR01PMkVwVW5sZnoy?=
 =?utf-8?B?enQwUm9FeFZ1QjZpQUM2VGMrUGZCMHVPaU1XcFdsRjBRMEw0Y01EWWdBQXpC?=
 =?utf-8?B?cWN3VTk2QzRyTldUbUdoZCt6NDBITmVCVEJFR29KZ1l5cVZjb3dGQ3VUNEx3?=
 =?utf-8?B?cU9IaUQ3cm9KejJUSDBiZGxudjZFNE5IcC9SQnd0Z2dUVVZ2azZ3N2k2SS8w?=
 =?utf-8?B?TmhkSDQ5eU5lS2FHbngxUXlLeHVNNHh0Q1NDRERTVGVZWmo5dXFkT2ZBblda?=
 =?utf-8?B?V0g5VXVtVHZ2QVMzVDRQbEY1bEsvSmRnRnNMVWNuOTExaFFQS2ZMOG0xU0lr?=
 =?utf-8?B?d1VOb2s5YTE3N0ovOVRQQVdrQVl4WVJpWlk0R29PT3Q3cUhUTU1CdGdmQnUw?=
 =?utf-8?B?TFJRelVoUlVON01kb2RBZmZIYlFRMXlNKy9kRUFSeDhMc1RPQm4vY0JqQ3Z3?=
 =?utf-8?B?b08rSzBmdHhINEJTdklTSmxOcE9naE51STlEbXhPeDdYNFdrUis0R0U2bUIv?=
 =?utf-8?B?aUppT1BVb2JzSGptZFhkdGFtTm9wL29LQmtPNkNoaXFGdDQvZThMeG9sM3V1?=
 =?utf-8?B?cEVSb3lsb1VjUGdaRHM5eVhhbGpORC83TXhydW1PSVZ3VGtpSlhncXp0T21B?=
 =?utf-8?B?eFl4U2E5eGJyM0puaHVLRzJJZTFVVFdDN3NZaGxPd1hTZHVjU0RsNHdrZmZ6?=
 =?utf-8?B?L0g3ak5KU2FPejU4VUdnRGhkREhWem5UaitDMm1Gb1pMOUFYQ1ZwTk4zbHlv?=
 =?utf-8?B?bnU2cDdwLyttT2xJMklZRUErZXByVEQxaWtUNTZjV1gyTlNHMlE3RVBPRnJu?=
 =?utf-8?B?Tm1zRzBHK2JqVE85S2I3UE1KT1dmTUp1TURrby9SU094WlFEM1FGMHgrUktZ?=
 =?utf-8?B?UldPdXJFSDNKd2s4d1pOamZid0hPVVgxVWJqTjRSMllKbXFCajNjSTJQNEQw?=
 =?utf-8?B?d05aUER4QnQzQTh4Q2d1Y05hUGhhY1lzRmt3aDd3emFyRzRPNEFLU0xSQTcz?=
 =?utf-8?B?L04zNXZGcnBsR1IwbmpvdStnMHNEeWtiNUhEMUNWVUNKdjM4b3JWS3piV2pK?=
 =?utf-8?B?ZXU1U1cvWkUvZDNnQ2d3Zi91ZmxXTVhzeGxqdkF0Vllyd3hRRmJiTFU3dVhO?=
 =?utf-8?B?bU9BckVsZGszTkY5U1RGazc4QURjVGlzQ1ZxS0ZmaE5naUp3WCs0SnNOd3NO?=
 =?utf-8?Q?GYGU=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: 60139f70-c0fe-46f2-30a2-08ddfc0b094c
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 08:10:48.7093
 (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: hyC6kjej8kH0OuApcDHNBxxvrhDSuoh1ls3eyweuyQa570euh4TuoICgEzMKsC60llXWN27ZWIILarJBRU1ppQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5620

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEs
IDIwMjUgNzozNCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K
PiBDYzogeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnOyBIdWFuZywgUmF5IDxSYXkuSHVh
bmdAYW1kLmNvbT47IERhbmllbA0KPiBQLiBTbWl0aCA8ZHBzbWl0aEBhcGVydHVzc29sdXRpb25z
LmNvbT47IFN0ZWZhbm8gU3RhYmVsbGluaQ0KPiA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4NCj4g
U3ViamVjdDogUmU6IFtQQVRDSCB2MiAxNy8yNl0geGVuL2RvbWN0bDogd3JhcCB4c21fc2V0X3Rh
cmdldCgpIHdpdGgNCj4gQ09ORklHX01HTVRfSFlQRVJDQUxMUw0KPg0KPiBPbiAxMS4wOS4yMDI1
IDA0OjM3LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+ID4gT24gV2VkLCAxMCBTZXAgMjAy
NSwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4+IEZ1bmN0aW9uIHhzbV9zZXRfdGFyZ2V0KCkgaXMg
b25seSBpbnZva2VkIHVuZGVyIFhFTl9ET01DVExfc2V0X3RhcmdldA0KPiA+PiBkb21jdGwtb3As
IGFuZCBzaGFsbCBiZSB3cmFwcGVkIHdpdGggQ09ORklHX01HTVRfSFlQRVJDQUxMUy4NCj4gPj4N
Cj4gPj4gU2lnbmVkLW9mZi1ieTogUGVubnkgWmhlbmcgPFBlbm55LlpoZW5nQGFtZC5jb20+DQo+
ID4+IC0tLQ0KPiA+PiB2MSAtPiB2MjoNCj4gPj4gLSBhZGFwdCB0byBjaGFuZ2VzIG9mICJ1bmlm
eSBET01DVEwgdG8gTUdNVF9IWVBFUkNBTExTIg0KPiA+PiAtLS0NCj4gPj4gIHhlbi9pbmNsdWRl
L3hzbS94c20uaCB8IDYgKysrKystDQo+ID4+ICB4ZW4veHNtL2R1bW15LmMgICAgICAgfCAyICst
DQo+ID4+ICB4ZW4veHNtL2ZsYXNrL2hvb2tzLmMgfCA0ICsrLS0NCj4gPj4gIDMgZmlsZXMgY2hh
bmdlZCwgOCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gTm8gY2hhbmdl
IHRvIGRvbWN0bC5jID8NCj4NCg0KVXNlIGluLWZ1bmN0aW9uICNpZmRlZi1lbHNlLCBsaWtlIC4u
Lg0KDQo+DQo+ID4+IC0tLSBhL3hlbi9pbmNsdWRlL3hzbS94c20uaA0KPiA+PiArKysgYi94ZW4v
aW5jbHVkZS94c20veHNtLmgNCj4gPj4gQEAgLTU5LDggKzU5LDggQEAgc3RydWN0IHhzbV9vcHMg
ew0KPiA+PiAgI2lmZGVmIENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4gPj4gICAgICBpbnQgKCpk
b21jdGxfc2NoZWR1bGVyX29wKShzdHJ1Y3QgZG9tYWluICpkLCBpbnQgb3ApOw0KPiA+PiAgICAg
IGludCAoKnN5c2N0bF9zY2hlZHVsZXJfb3ApKGludCBvcCk7IC0jZW5kaWYNCj4gPj4gICAgICBp
bnQgKCpzZXRfdGFyZ2V0KShzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgZG9tYWluICplKTsNCj4g
Pj4gKyNlbmRpZg0KPiA+PiAgICAgIGludCAoKmRvbWN0bCkoc3RydWN0IGRvbWFpbiAqZCwgdW5z
aWduZWQgaW50IGNtZCwgdWludDMyX3Qgc3NpZHJlZik7DQo+ID4+ICAgICAgaW50ICgqc3lzY3Rs
KShpbnQgY21kKTsNCj4gPj4gICAgICBpbnQgKCpyZWFkY29uc29sZSkodWludDMyX3QgY2xlYXIp
OyBAQCAtMjU4LDcgKzI1OCwxMSBAQCBzdGF0aWMNCj4gPj4gaW5saW5lIGludCB4c21fc3lzY3Rs
X3NjaGVkdWxlcl9vcCh4c21fZGVmYXVsdF90IGRlZiwgaW50IGNtZCkNCj4gPj4gc3RhdGljIGlu
bGluZSBpbnQgeHNtX3NldF90YXJnZXQoDQo+ID4+ICAgICAgeHNtX2RlZmF1bHRfdCBkZWYsIHN0
cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkb21haW4gKmUpICB7DQo+ID4+ICsjaWZkZWYgQ09ORklH
X01HTVRfSFlQRVJDQUxMUw0KPiA+PiAgICAgIHJldHVybiBhbHRlcm5hdGl2ZV9jYWxsKHhzbV9v
cHMuc2V0X3RhcmdldCwgZCwgZSk7DQo+ID4+ICsjZWxzZQ0KPiA+PiArICAgIHJldHVybiAtRU9Q
Tk9UU1VQUDsNCj4gPj4gKyNlbmRpZg0KPiA+PiAgfQ0KPg0KPiBBZ2FpbiBJIHdvdWxkIGhhdmUg
ZXhwZWN0ZWQgZm9yIHRoaXMgaW5saW5lIGZ1bmN0aW9uIHRvIGJlIHdyYXBwZWQgYXMgYSB3aG9s
ZTsgdGhlDQo+IHRpdGxlIHNheXMgZXhhY3RseSB0aGF0LCBpbW8uDQo+DQoNCi4uLiBjb3VsZCBh
dm9pZCBhZGRpbmcgaW4tcGxhY2Ugc3R1YiBpbiBkb21jdGwuYy4gVGhhdCdzIG15IG9yaWdpbmFs
IGludGVudC4gQnV0LCBhcyBqYW4gc2FpZCBpbiBvdGhlciBzaW1pbGFyIGNvbW1pdHMsIGl0IHdp
bGwgbGVhdmUgdW5yZWFjaGFibGUgY29kZXMgd2hlbiBNR01UX0hZUEVSQ0FMTFM9bi4NClRoZSB3
aG9sZSBpbmxpbmUgZnVuY3Rpb24gbXVzdCBiZSB3cmFwcGVkIGFzIGEgd2hvbGUuDQoNCj4gSmFu
DQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:11:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:11:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130190.1469782 (Exim 4.92)
	(envelope-from )
	id 1v1h4r-000871-82; Thu, 25 Sep 2025 08:11:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130190.1469782; Thu, 25 Sep 2025 08: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 1v1h4r-00086u-5O; Thu, 25 Sep 2025 08:11:45 +0000
Received: by outflank-mailman (input) for mailman id 1130190;
 Thu, 25 Sep 2025 08: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 1v1h4p-0007tH-AN
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:11:43 +0000
Received: from MW6PR02CU001.outbound.protection.outlook.com
 (mail-westus2azlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c007::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41f9347a-99e7-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 10:11:38 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by SA6PR03MB7855.namprd03.prod.outlook.com (2603:10b6:806:42c::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Thu, 25 Sep
 2025 08:11:34 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9160.010; Thu, 25 Sep 2025
 08:11: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: 41f9347a-99e7-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rralwjLiYyP+y3A8zI8zH3j0iblpJ+ZFj7sMNjM8xcyHJ4bxZqhcb3ueoG/zVIUzL2IBvVCCfh86IOPSNh9m3RcSpBB+oqCo5Q1CgJCLpx0pHt6MYYWowdJnUkL4HDGVe5KZ3cijNBahhcTdkYjYDxB9090g+CpAk5VRu6A21yv7HJfBLsIUTa25hnv3v8pRl2A2PFHwE3SmYcpEZsdx3m5MPX0RZfXX3NftneC542x7c75dNrrrtb9koP5fA9v0uSuy/DJBCvsd7+rBC470urh6wSLFjbxNz70laDGdyhLkZ3mbCLXySiHJcL878nBYhjcDD9zEC8gfV2Pm6+JRug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JBZXJt7yW1WiAgNZSVMolrLF1fqf8EzbZIDx2yqPEfc=;
 b=JbBClEud8dHBrKn1mhLvPMIhTOK22yHuOp1DwjsUuPNCgIizwuLvL+cAOEaq45DKm4SrM4oMpg/Ji8kEJ2WaW6WnJNtPnLTOYSG2MgegSKuTCZEe71BJbHAWiNWHst0IrhVF4wzHCOfE436Clg8LsX2lUzBQl0vAwrB6t2s/OXehAb8LIECw3FqdI2c6dFYNFGIBkr0cBMtEVKwsMskt77wFodLhk2mbOjqsZkKXE7oS+cwjI86ZiUPU/GmDQOOpqwP21GWDPAmKwyEUKcoTXQ8OpI8xibUKa7klE61myd5Qv4AEwJwcWzqASeUAgCrqVW9hZ7+3B9+GS1Y7X5Ohbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JBZXJt7yW1WiAgNZSVMolrLF1fqf8EzbZIDx2yqPEfc=;
 b=VaRqHor4t0KPnrucVRlbu4zQ+rLREuv7AspJsU2cD7/8BWbUC0LGkg14fidMJljUWTZtMa5OEbn/P2O0G3Meg3AFOTzvcUYp6/6jD57E+/RDbMP02z3lECiwSQy1Cqm0J5LqdPEMP3qsiK84rqbC6tcPYVtGY3XovIsVBydYs9Y=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Thu, 25 Sep 2025 10:11:29 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	oleksii.kurochko@gmail.com
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
Message-ID: 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
 
 <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
 
 <1083faae-d565-48ab-8e41-3a5a12178a9f@suse.com>
 
 <58e5e9ae-9b57-41b0-a2d9-bdd2f312293b@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <58e5e9ae-9b57-41b0-a2d9-bdd2f312293b@suse.com>
X-ClientProxiedBy: MA2P292CA0017.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::20)
 To DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|SA6PR03MB7855:EE_
X-MS-Office365-Filtering-Correlation-Id: cafade7f-7926-4d2a-b5ed-08ddfc0b23c1
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?dXhDNDB3dGFnTnhNYXYwZmN4REdmZHhTRThqdGxTSzdVeG5ST3I0dnhGcUxs?=
 =?utf-8?B?MjVFSnB0RGVmMGdLNnlFRXFqU1I1TUxtUXBmZVpFdHJwQkJTVzE0d2ZIOERa?=
 =?utf-8?B?RlpGb2xpZVNZVUt5VzAwRFpsa3hiQVFXbFFid1BzQlJwVFhGUURhVVF0Ky9H?=
 =?utf-8?B?Vk96SWhPMWZkMFM1dVZ3SzdJS1IwcFAxTng3dlBwajRRemp3Z2x0aDVVKzFy?=
 =?utf-8?B?cFp1a2dMVCt0dGw5VkovK09lK1NBOTVDcEpFQ0xRMHdmUTM5dWFIS2Faak5p?=
 =?utf-8?B?S25IZmRUTUQ2ckJHc1JDYWdRSWJYSFlFL0RzRlpoZ1ZrajF4L1N2akNpb3Rw?=
 =?utf-8?B?M3hBejc1R3lCMFlTcHIvVFlvWVkySUNJaG0raHRrU2Y2SXZEckpySGg2SUtL?=
 =?utf-8?B?VCszTHpUYjVLbnZkWVRrUzF6OGUyQU9PbW56ZG10S01aWmczWUllUUg0dHJJ?=
 =?utf-8?B?bGh3Qm9zRXFrV2ZlNUljSE9IdFBnWnJ2blhGekh5SXlicXJleHdlM0JzdGFG?=
 =?utf-8?B?OUVvQXZwYWRmbS9rSWhRZnA3TFdCZnZJKzBlRUtZZ2hHMjY0ODNMbmVOSXps?=
 =?utf-8?B?MXpwakVnR3lMWlV5UzV4WDBsRVpPMUgxZG1wVWlUd3BTQmRFam1YSytRQzMv?=
 =?utf-8?B?Uzd3b2h3RGsxWHR5OU5jZUNPTXh5a21HODR6a0l5bjBLQTVzY2dRMXFkcEpR?=
 =?utf-8?B?QitiWUdiRW9pTkhPUzBhdC9mZ1kxQnRtdWxJTTZMb2xSbEhoUkN3RTFaTXZQ?=
 =?utf-8?B?STVhUFRHSm5wb2F5VFNGWm5XWG9mQnBibWI3dmVuYjkyUXhyd3dDUlp4Ylhj?=
 =?utf-8?B?aVhzaGQrYXZSbkdIRkVLNU51TmtIdE9OR3k4dWtJNlhCdjFTUlFBZ25Sc0pK?=
 =?utf-8?B?MlRCNEdYdDQ2eXlmWGF3V1hwY3RUa21ZTERmN0JFS3N3SnQ4VXE1OVNJdjNW?=
 =?utf-8?B?V1hvR1RGL051UFcyWWxheitiZWZGZUlzQVM2eXVMNjMxMFJiZm1na1UrN0k5?=
 =?utf-8?B?OW95QlY5Yk5rMmp4eXR4dGdyU25ZOWJaclA0NGFub0c3ZEU1Q1ZQU0E4YTRN?=
 =?utf-8?B?VWc2MzcyLzA1YmQ0RjN0aGVRM0k3alVLZDBEbjB0c2s3by9GNy9Xb2RWbW5s?=
 =?utf-8?B?emVBbEpUeTBkVGNNbi9HZGFNQ2NxUG11bkhzNnQwS2t2L1c5ZVBpWG1MOEZn?=
 =?utf-8?B?RnBuOTlROFpSS1Q0VVBLTDBrRWFuMXp0aUxnMjk3UitMMlJYSTdJV0VScCtO?=
 =?utf-8?B?bnZVdGxvaTg5dHlsenFVKyt5RklhTFliNnJkNVp1N3ZyeVlINkdwOXdDY2pi?=
 =?utf-8?B?M3lvbkRwOHBtYkhRdHU4bkdJdjVNeUNBVnR6SDNDYm5IYUphNm9RL1cxbUIy?=
 =?utf-8?B?ZHRJMVFMWnp0NE82c1Vpbm94UjRYcWtCaXFZT1JYOER0bjZLU2xmZWczRlFH?=
 =?utf-8?B?SzhTZmdQMWhQTS9ObWN1S00xNThOS3V0L1BwRUJYTysvS1Z3YnI0TzNoNmY2?=
 =?utf-8?B?aXBLdGJVMjMzN1dYRkdocDIvTDdxS3R1dG94YnZPZ05mUVpjckJoLzRtN2pI?=
 =?utf-8?B?OFp5RmdnY0Y4eHdSRnR4YkVNZTEySUFkanNYU2IvK2xaeW5paXY0aW9VN05E?=
 =?utf-8?B?UmNGRGpvT1BsVTUzbGhVSVNhdW9EaHArWXpNd1V1SkwzL2NhV2VjSkQwVW1I?=
 =?utf-8?B?MmM4S0w4MnFsbW5PdUtRcEJVVzJnS2RMWmhtNVU5WmVWVGlybENjY0JoNjRE?=
 =?utf-8?B?UTd1WWc3ZmkydG9XanFaMHNNZEtXNlNvSTNlQjdSOXkremYrbUZyZ0o0MjNS?=
 =?utf-8?B?Y1BtR2paYmViNXkvaSsrVEhiTFVIM0ZrU0gyZ0VWRFpnR3YybS82VHZLd2RX?=
 =?utf-8?B?dTVSNEdLMlNQUi93OTg4ODVMTGwxcTR2NVdTZFc0UDVpOHRYOExBNVZESmxw?=
 =?utf-8?Q?mfOx5DHw8o4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?REE0MTFTZzVCeDR2OFowUEZEblBxVXc5RWxPMlQyeFFjWE5CdGFrTnhvNyt1?=
 =?utf-8?B?YjNUczR0R1lsblRacTNzV1JjcVNDd0g1cURCS3htTHA0czN4eVhCNUN0bGVo?=
 =?utf-8?B?VG5TNzlKekY5eEFqaTMyUEVtZ0tsUkNBeUg5RFBxV21pRklYQWhyWmxTSllu?=
 =?utf-8?B?QjRIVmoreU1XQXFaUmFHdWRSWDczSFpvZlNQcmp4akR0SjZkNFBKNnU2aUkr?=
 =?utf-8?B?ZUVrZTByREhQaTA1ZlBZOXFPaG81aEwyZTZCNmVHK0d2aUNMSnhWUUpxOE1S?=
 =?utf-8?B?MS90aVRpK0t1RTIrSGc0cW9oZS9XbTZFMUlaVDNHSGJ0N25BMmNnWmxyRitW?=
 =?utf-8?B?dXV0Q1RmbnpZRGprZEwvdkRwQ21Jc3ZZOTdYdXBnU0gxbHZvSm9iUm1DVzdR?=
 =?utf-8?B?NlBWK1g2K1ZSRUJRVnZtL3BZMlFpbjAwb3VSQzRpY1NmblB6UUVPMFllZlN4?=
 =?utf-8?B?T2Fjank2SmVWZUorVzBRMVozelpvUHhnVXpveHRVOTlmNXN4bGZXdzJveFUv?=
 =?utf-8?B?ZllGRUN6c1cyUnRYRDB4Vmo1VGFoRkh2M2IyVnU3UVJ0S0M2dlZqWllYL2dL?=
 =?utf-8?B?TmpyenpwV1lNUzROTXFaU2tqTmZzd2MxajNPbnFPSEVQeUtJODllNlE1Vnpn?=
 =?utf-8?B?TE4rL09WQUhBK1NaUHJvaUVFSTVqQ25DYytxUTMyZUxYS2JRNU9rSjBvb2RS?=
 =?utf-8?B?S2Q1aUdlVjFUS25pZnRObWs1NHNGeTNYNVBrdVcrWnpzZlNLc1RUWTdueXVK?=
 =?utf-8?B?LzdTdkEvdGNibVlJUXJnbXFkVWJrQnBHZERYUzd6TVJ6Qmc4RlFHdXcycGl2?=
 =?utf-8?B?S2QwWmhZMGNhUFhuSFdyZzc3a2VjODhGSGVtLzR1Y21qNk5NSDJyeEEwWUxv?=
 =?utf-8?B?L0pDekJKNGpoQXJCVWl4VGo5RnpXQWRrOTNRbVliVm9sTFJjOVN2QWxINy9l?=
 =?utf-8?B?WEpreC9HTmQ3TzJxSnYySDdVZnUxUWJVQ1ZhUS8va1VHWXRyYzRjL3hGbkNB?=
 =?utf-8?B?eUJmaVhxdUxJY1RDdm9yRDh0SE9EM2VZWGNac05MaG5sY0lwaVVxTDl2RXRQ?=
 =?utf-8?B?Yk1qVnorYktqcDF2ODlEbTlkQ0R1d0tNbHE4MTNWcFZ2L2MxSzQyejgzckI4?=
 =?utf-8?B?V3dBSUhaNHhITmZQZWRabTlQNFZKMEhWQ2pEd0xVblBENS9vKzRvVjIyM2c2?=
 =?utf-8?B?bXlsdWdkemhyenpqbmlZK0FLdzl3QmpLTEorQ1VPOGpnNENrQ3Z3L2tGNXFm?=
 =?utf-8?B?ZVhlSCtoRmFTVVQ2TFRoendBeVNJMHl5bXFPME1BYUJyOTNzaXh5aitJY0ZP?=
 =?utf-8?B?MDB2U0lwb3JXOUdPZ29hY2RxL2hSV2RvYWZzTi9tMTNNd2RQODhsR3JSdmpP?=
 =?utf-8?B?ZUJLVnJSWGIrcXFtU0UwNmNDN29COWtNcFQvWGtBY2JhMEFqRDRwRXd2WkUw?=
 =?utf-8?B?VmVidEJGc2FpWVNsT3I2U0tJZ0JaWWZodWhHV1poemp4S0lUSDZ0WVM0OTBM?=
 =?utf-8?B?bElMMWZsVFIzUHFaNHlKK1psb3d3S1pHa2RZNUdpV0JrTTlMZTVYZkdaQm9J?=
 =?utf-8?B?dkdUZjlOUHhWTUN2TzU0RUJGNzVFT2diOStucWZzcjZtM2k4eERYY2RRdFYy?=
 =?utf-8?B?MWdqdnljTDNJN2w0WFJuekxKSjFsTHlReG5GYzh3TS9YU2pFNitlWEd3YVNK?=
 =?utf-8?B?MWcvbGlrbytZR2pSVU9aREI2R2llZjVrbHV5aHJxSVE4RnI5eU81QzExWUpl?=
 =?utf-8?B?S2V4eTlTdC82Y3E4WmhCdzI1U3FFSjJkM245QWsyakpDUmdLVFN4TEVaRmNp?=
 =?utf-8?B?NDI5VEJNcWpKbmJndTltWTA2bTVFbFk2Q0MrL1pvTUJTRHRIVkZqRlhuTUVp?=
 =?utf-8?B?Vmg0SWRjaTVEcXNXcWlrZTZNcmp6ZHlIc2ZaNUJRS0cwZFE3YkgvcThOdFRz?=
 =?utf-8?B?OXVWckJCL2tTODY1eHRHS2FhbTY5dTZYREdyVzdKekRvOWEreHdzYXY0bWFk?=
 =?utf-8?B?TGJ2NGJkTHVqSWJVWC80eTFZaWhWN3Q0UU5JYjNNYTd2VnhHMkM1Vys3SFpQ?=
 =?utf-8?B?ZWt4cWR1QzMxVUpCSXRUUU5yNWpabUE5ODNFMlBLejY0SjFlOUZUdmNCNHox?=
 =?utf-8?Q?eWkt47Qq0xv3Nax0IRg86nCgs?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cafade7f-7926-4d2a-b5ed-08ddfc0b23c1
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 08:11:34.6373
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 5h+XtKhqu7yRyAo6Tq1u0H1MYA3tODqJGfv3a4Tpm67+6RLR2YLNQEZ5UoJHTweFfcPxoEESkoEM45AhZxOg+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7855

On Thu, Sep 25, 2025 at 09:41:43AM +0200, Jan Beulich wrote:
> On 25.09.2025 09:40, Roger Pau Monné wrote:
> > On Thu, Sep 25, 2025 at 09:37:46AM +0200, Jan Beulich wrote:
> >> On 25.09.2025 09:34, Roger Pau Monné wrote:
> >>> On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:
> >>>> On 24.09.2025 15:40, Roger Pau Monné wrote:
> >>>>> On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
> >>>>>> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
> >>>>>>> Otherwise the check for the SS feature in
> >>>>>>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
> >>>>>>> X86_FEATURE_XEN_SELFSNOOP never being set.
> >>>>>>>
> >>>>>>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
> >>>>>>> identify_cpu(), because SS detection uses boot_cpu_data.
> >>>>>>
> >>>>>> Doesn't this, mean ...
> >>>>>
> >>>>> Well, that's the reason for the rant here.  The reset at the top of
> >>>>> identify_cpu() has been there since 2005.  It's arguably to make sure
> >>>>> the BSP and the APs have the same empty state in the passed
> >>>>> cpuinfo_x86 struct, as for the BSP this would be already partially
> >>>>> initialized due to what's done in early_cpu_init().
> >>>>>
> >>>>> The underlying question is whether we would rather prefer to not do
> >>>>> the reset for the BSP, but that would lead to differences in the
> >>>>> contents of cpuinfo_x86 struct between the BSP and the APs.  In the
> >>>>> past we have arranged for leaves needed early to be populated in
> >>>>> generic_identify(), like FEATURESET_e21a, hence the proposed patch
> >>>>> does that for FEATURESET_1d.
> >>>>>
> >>>>>>>   However that
> >>>>>>> creates an imbalance on the state of the BSP versus the APs in the
> >>>>>>> identify_cpu() code.
> >>>>>>>
> >>>>>>> I've opted for the less controversial solution of populating FEATURESET_1d
> >>>>>>> in generic_identify(), as the value is already there.  The same is done for
> >>>>>>> the AMD faulting probe code.
> >>>>>>>
> >>>>>>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
> >>>>>>> Signed-off-by: Roger Pau Monné 
> >>>>>>
> >>>>>> ... this Fixes tag is incorrect?
> >>>>>
> >>>>> I think the Fixes tag is accurate; the code was OK before that change.
> >>>>> Nothing in c_early_init hooks depended on (some of) the x86_capability
> >>>>> fields being populated, which is required after the change.
> >>>>
> >>>> I agree. Hence:
> >>>> Reviewed-by: Jan Beulich 
> >>>>
> >>>> I wonder though whether while there we wouldn't want to also store ecx if
> >>>> we already have it. (Really there is the question of whether we haven't
> >>>> other cpu_has_* uses which similarly come "too early".)
> >>>
> >>> Yeah, I was about to do it, but it's not strictly needed for
> >>> c_early_init, and it's done anyway just after the call to
> >>> c_early_init.  I can set that field also, but then I would need to
> >>> tweak the comment ahead, something like:
> >>
> >> Sure, i.e. fine with me.
> > 
> > Oleksii, can I please get a release-ack for this to go in?
> 
> Do bug fixes actually need release-acks just yet?

I always err on the side of caution and ask for them.  Maybe Oleksii
can state if/when he formally wants release-acks for bugfixes.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:14:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:14:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130205.1469793 (Exim 4.92)
	(envelope-from )
	id 1v1h7P-0000Hr-LU; Thu, 25 Sep 2025 08:14:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130205.1469793; Thu, 25 Sep 2025 08: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 1v1h7P-0000Hk-IX; Thu, 25 Sep 2025 08:14:23 +0000
Received: by outflank-mailman (input) for mailman id 1130205;
 Thu, 25 Sep 2025 08: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 1v1h7O-0000HI-Mr
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:14:22 +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 a12a844f-99e7-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 10:14:17 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GV2PR03MB8583.eurprd03.prod.outlook.com (2603:10a6:150:77::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 08:14:13 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 08:14: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: a12a844f-99e7-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M2pHc2Qdydswqmr08DwzAP9l880h15mu2v5q5W9j1+BnfhMHuq5ArAeXeq8BES5pOlTBFkqTIukBIwlVx4QdYjpA52fdbM8eat3pzidZIvRCT1W7E080x2bk93lbR/ylYVTWRlSNZSGo2A73yKG072Dce9TielfwhrZRPUK8Rxk27ceYAeI6rhUfcEpFcbRb40Jwt7v05IUwEM7TLa+YuJpJQ19gs/0lCTjzvLHe4dSY0Ubse+bdEZrrXbGQhTr82qQskR4C9DZBEfYGAmtnSEIhhctHyhSI+g1cIEpYp1uIKsH4/twUcYHuk559Eza0gqsfT+/qK+EbkHpY+JenRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8iDhYqQ1ZAJ9/W11nuhGfG3cuPN7qiNQ43xN42sm1lw=;
 b=CgOopAVPBAiqJUGzYtIEZmkem4xnBR4JTmAgERXIF9wqFnGvTiELvJTYUluaMCTe7HATUmHH0ruSnZ1E6VPRvNVrNQQOKQJqwWqnCmDF+UGL7tFnf2zYR52umGvLQmKfCSysjUHEVeDIg/DqN2hB28nHXaM9Yp1EWZ01GRnwIe+E3QDt9//uW02Tku9Hq1hwNdHV9Zgvxkhmf7lTbgPALTfUvMv/WZsB2Zq2Sqy/imtaBwKuuMGAlteWrk8OA7N/7wVWefkiUIw0n/Yx3/p+yT0njpZncqdtZ4dw91n9plKF6fZuMEIWRhpUjV+5FhaMkjC/fxvpWe9FMrRwWToCkg==
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=8iDhYqQ1ZAJ9/W11nuhGfG3cuPN7qiNQ43xN42sm1lw=;
 b=A/VOkrXQYbDEbI5R6seV1kmjg+IKVfXX/Bhlwxu91rMUKrsyCTq6BqiVyM/E5WRM2zvKbohJdZiUXdGqa2nKQ76PaiJJWr8nxMXpnPKZuowYZ+KAZTg2FQ/3znpDhuXaXbEjqxbx/0zACvuR0YHwCXRNdVscLu03hSGIBpk4VYvjLed4g9cIsIf9TOVtq8kbr9vT7qYKUgYuU3LUsdPNiEF5qKT7Ogs64Y3n3lwurgwfnhZheQ4WgTxNWoAsrGcqJdrs9cKftbQ6uTtENljoWCR3E8CaUWuAmfAwBAp86oy19c2mgVt59Ll2swjJV93pUyG4+lkd7SQLwG4uOVtkIw==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Julien Grall , Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , Volodymyr Babchuk
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Topic: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Index: AQHcLWxn561sYuCM3E640/FLnKWxSrSjchMAgAAbxQA=
Date: Thu, 25 Sep 2025 08:14:13 +0000
Message-ID: 
References:
 <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
 <9507e775-f9c3-4351-9c76-ca939c1147bc@suse.com>
In-Reply-To: <9507e775-f9c3-4351-9c76-ca939c1147bc@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_|GV2PR03MB8583:EE_
x-ms-office365-filtering-correlation-id: a553573a-9445-4f7d-8ea8-08ddfc0b8340
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?WVFabEp3QnA5M3dNUUFaOXVpbHVWMjZFV1dmNkxRMFJ2Rm4yam9ocllOUEVo?=
 =?utf-8?B?S1M5QndLeGZxWGlkOFUrY1R5Q25lRDdTYnNnWVdOTkNpcGpIZTJNMDZXL1VW?=
 =?utf-8?B?WUsrbEpyM1ZuU3h3OFVhQldPNnhUQjAxU0lFU0xqNUY0SlNXT2ZkdE9WNjJs?=
 =?utf-8?B?S0dnYXB1OCtpcTM5dkcweFNJMU5KOHJzZWVFMEp0M3FKTGpKWVdpRnM2dWpF?=
 =?utf-8?B?VzV3bGVVV3JFSDZGbmlka2VPYmdwaHNXM0VvV1FSbXlBM2ZtdEVjaXhkd0xk?=
 =?utf-8?B?SEQ4T0M5M1pIVHhUTkNaYXRHMUp5TGZvQ1EzeWk5Y0pxcTROeUdKK3B1VEhE?=
 =?utf-8?B?eE4rK3RUWkYzaFlwaVFraTgvOUs2UWxuQngvK0UvdDR6SCs5anpxZ0dZREg5?=
 =?utf-8?B?b0JCUzEvWUdlY1hydWQxUkIyN2V6UDBDSWZ4WkRCV1EyY25WMGtrdXhTSStq?=
 =?utf-8?B?d1drOTJUOExCeUUyS29DUVZIRDhCSUZUL1lRancvbEFhblkwK3pOZTlZVTg3?=
 =?utf-8?B?VVQ4ajRRSndqbTZGRU9LK2hVNDlJNXM2bkx1Wmx6cldMSWwva2xwYTR6czgz?=
 =?utf-8?B?UkdvbHRkQnZONGdrc0xLelZZVVFzY0hOc0NzeFprTVgzaytmMENBcXRmQzdi?=
 =?utf-8?B?NmFwamhteDQrUXZVbzNQN2R2NzdSZk9KL3pOazdGcDNUWENEVmlFUlBURnd6?=
 =?utf-8?B?dzJUeEo1MkQ4MXZFWUJlb3NkdkxISTl6eEFLTGIvdkwxWnNGNDdlTkZGYWY3?=
 =?utf-8?B?c0Z2K1oxUnhKdk5HOGUxSVV5RkxkU3B3dHJnTXF1S2NRVm5sZHRETGhQVDUx?=
 =?utf-8?B?cUk2Vk5JQ3hnK2prdUExWWpoWURpWU1xc3J1UjZ0UjZhOVNxTjI2YXhnSndq?=
 =?utf-8?B?ZXVEbDRQcUZhUGJCdVVHOHIvSG1kcW1wTHNpaGFVcnlkRHFTWEU2ajVxemhD?=
 =?utf-8?B?dmVNb1R6V0tQbDRGRUdtcHRMN1poWC9JcVZEbXdqQUJDam1TWkczQzhWUHlB?=
 =?utf-8?B?R3pGQyt5dlFVNnhEUzlZcUxieXpCTC9ha0hudURDeEJGUFVmTHdRR2VqMERs?=
 =?utf-8?B?REk0ajZoTU5jNTYvRVhNY0pJalJJVWQ5MHYwbWJVRHRjTHRvQXVvQ2Z6SFdm?=
 =?utf-8?B?NUEzeXJkeE1CdlZIQUMySHU1YkVjZDN2S2gvM2hrQ2NEUzFFWjNjeVRpc25J?=
 =?utf-8?B?bDRaSkpNb1ZkcUxJeTlNQzh2WkhkN3plai9xUnYvWGJUaVRlUlFkclgxdmhH?=
 =?utf-8?B?NUxDQ0lkenFnUHdLK1pSTElCbjE0emYwTHFSV2VKdStBaG5LTUxqUnN6b1U4?=
 =?utf-8?B?Zi9PV2dETVM3bU5xbDZTNytDMi9lUEVHV3FQeThWdURscGh1ZTFHTUZkcHRH?=
 =?utf-8?B?MUFmdEVhc2dUQmszWFhLZGtDYnpOak9oM2xvU0QvL3lCbmFYbWtwOEthcWVU?=
 =?utf-8?B?K0ZKR0dCZ0hGN3VJQ1UwSUpYTEZPV1lJUlZiTVk4SXFraUEyWnVTbmU1L250?=
 =?utf-8?B?SzNYY0hoN1FVY3dJVFBQRFhUdzlCMlNyeUI3UzMySjFVbmJFUmIrTEk0RnI3?=
 =?utf-8?B?T2xLbzFMVU94bk9uYTlDZDR6MEF6eVhqOXZsc3BTVm1QZDlLcEo3dFdVMFZQ?=
 =?utf-8?B?N3plWkRmWitOTkVtcDY3c3RmbHFlMWNSelpVNVlMU3FBUDJkZnlkNzB1V2la?=
 =?utf-8?B?bHEvVTVtdDgxYnExYTNVeVNYT0dRVXNoL3hGamZGNENqU0M5d3lCL3NhbUJi?=
 =?utf-8?B?OTZhQmFkT0tnM2h3d29YY1A1eE8rNTlCU2JiWWFQWVlvdkFLM3JRTTVjRlV5?=
 =?utf-8?B?UGthVW94ZmVCVHlWSzBuT3RvRi9iWEdIUmhVVDJBZkFlbHRYVXBuRHFibDlP?=
 =?utf-8?B?bFAxSlpmSGJjdk9raVFSVjNQWjcvblhacGQ5eEREL0krVE1mUUd0T3NqaEdz?=
 =?utf-8?B?UGJwRHY5VFUyQlQzaGhDMTdKcXFza0Y5RzZKbG45dXFsRld5c0hFZW5EZ1dK?=
 =?utf-8?Q?DTnEHkvMfi+c/Z32ika0gTjldcW6Wk=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?aDNOWEpZSk5uTjBhck40b3BsRkNhMCtPbGwxOCtCS0Foc0RyRFVqK2dDcUk3?=
 =?utf-8?B?a1BUbWJza1c0TWFPWmIwcnVGUnZCU1hOa3BRY1VDRXN0SWxBdXg3dnk3b2Rp?=
 =?utf-8?B?TzlNRDZ1cC9NU3VJRzZLVnM5bENOOEJVR3JWclNyVlVZcE8xYngxRzczbU1y?=
 =?utf-8?B?TEhEY0VuY1J6RkFtVXVTMDJaUHkvdzVkYktzVkVtUTVqRHlrY2lzWm1XM29l?=
 =?utf-8?B?RzZDVDVrajlmVTdQKzk0YlNtRndSWlhITXFZK2JEOU5QcTVEUGVhbi9Fc2VJ?=
 =?utf-8?B?c3RucURHRWJKNUpmY1BjcktNUno3Q1FTVVpEU1RHRUFJWklGTzAzSDJlUzBG?=
 =?utf-8?B?QXI5WTNJT3JiVDRiaTYvblJLQ2Y2Rzdmd0NhUVdMY2s2NWsrVTAzNnd2aVd0?=
 =?utf-8?B?ZVBhUmRlRkF2Z3dyc21EYklNWEFDS3Vkb1FGU0FJRFVBUlE0eUFCYlhWcVla?=
 =?utf-8?B?TnVJMXVrQStPcnlMMG9CQ2R3MU96TUhoNllJZTREc2VWNG8yQW5rKzB1Y1Yr?=
 =?utf-8?B?aDJ4VEFrR0syajIzZmNoeG8rZk9IOVpIYWY5d01DTXRYWFhQNHY4WWdUK0Mv?=
 =?utf-8?B?ampmWXJ3Y1U2RlQrMkpQR2J0blMveE1OSmw5bnFKL093SWlNbU1pOGp1NnA2?=
 =?utf-8?B?NkJwNFprN1JuZmtiZWFSanB6UG5JbFYzeEh6K3VERDd6N0VTOVFTOGZOL095?=
 =?utf-8?B?ak5CcllpckZDejl2c3N2UHY5Y1BWR0swZ2xxL2d4cUl6S3VRZE42WEdlZ2Rr?=
 =?utf-8?B?TzVhbGRpaUpxTG92Yy9ZNm11emJtU2ZHdm5nNzZRTmU3aVZVdDJhWFIzeWdB?=
 =?utf-8?B?cStybUVrcHIwQ0ZZbWhpU2NaQ1NodEpLbHNRWmtGN2JtMHR4b0poYmViVVRB?=
 =?utf-8?B?bmdDMHBiNjlrVlRmZENyUzhlN3VEbE1xSUpQeXQ4UGh6NkpHRVVjN1BkQlZU?=
 =?utf-8?B?ZnVzMC9hNFl0bzBWbFlBUVc4OGxxanF1THViQmdScnRlcEN3WjNmRWtyRUZr?=
 =?utf-8?B?K0pUR2tuWjhRQjRvcWliOVZtd1ZUeW42cEhPUGFhV1lhd2NPSHhqSzgvS2hi?=
 =?utf-8?B?b2lnc2F0aS96Y1QxcWo3bEdmYk92OHdYeHZHUDNVYW1kUWxpdjlYa2xyTmRw?=
 =?utf-8?B?RzFrSlBDWmtZNzJNZUdpNGFHZUo3SmRrM3FFOC92VGM0OTNBK01acWREdkRL?=
 =?utf-8?B?eWVCdnpXc3RzUjZ4SnhuNWx6eVVEVW4rT1h0RlNvaE50OExmU2I0N05sWlNw?=
 =?utf-8?B?TGpuR3B1bWlQNDVxRk02WlVIZUx6Zjc5YmdsU1UrRFVwYzJlZTVwalVaMzRG?=
 =?utf-8?B?a1BZK01vRllEUDFUeHJ5NmhKTEVPYzdSakxIYWs1VHVoelFHbnpEWGQvUzdK?=
 =?utf-8?B?TXZndWpTdHJsQkxPYlJjNUFsWkhnMnlLYTd6eGxmRmh0TGNodGNkMjRhR0Zl?=
 =?utf-8?B?Uk1hVmZrYjhPR0s3NU1aTzZBb295dFl4ZnFIS01Nc0JRemY5SlhiNjREc2o0?=
 =?utf-8?B?bjVlSGx5SnFuckdXT3ZXMnhXQTRqeFVMRXh1VURzKzFSaUdLRnFhd1dwdFpS?=
 =?utf-8?B?c0F4MlF0Z2pOY1VGYkE5MlUzV0oxOFNya1lFdExNTlIvSnR5RUhGTGF2MHhp?=
 =?utf-8?B?Z1dyRmR3SloyTWgxQjQ1dFJwZFBQeUxMdGNlN0dKQlN1VGxYY3FVb3cyRGlM?=
 =?utf-8?B?UkU5L09mTnIxakFBR0ZLdk1VWTJobk9zblBNWFBwNUJVTE4wcUtZbkY1bWV4?=
 =?utf-8?B?SVk2Zk5qelFKTlJobUt4aUkvK0RhNUkveEZLSGk4UStodTBJNExEMFg1Qlpa?=
 =?utf-8?B?M3poK0VoZ0FibUl5MGFNVi9VVVFRTTBKZGc1SHJIbThEQytVbHZiS3p6ang0?=
 =?utf-8?B?alg0MnBDM2R4RW01NkpFZFJKWUdONW5lUnYwcURkdW82UDdvZE5lbFdnc0FQ?=
 =?utf-8?B?bTZmWnVRSGxmajd6cFZ3blgvQnFLL2c3WTZRenBTRW1XOERiZzkvcVNJcUwx?=
 =?utf-8?B?dDhpcExJQU1iSnRVUTE0SkFvWXYzQlFwOUlkOFpMM29kTkdtM1RURExXT01u?=
 =?utf-8?B?anlRQW1Yd3AxOHFCajloaktlWnp5YTZPZ2pkaFpoTUtLVjZUc3N5QkFxRVU3?=
 =?utf-8?B?ZzhSSEZ3ZS8rMERaZE1sbmZvNFh0aTBQSXU5b3l6SnV5UTVyYktCQmN4S2Jm?=
 =?utf-8?B?ZWc9PQ==?=
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: a553573a-9445-4f7d-8ea8-08ddfc0b8340
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 08:14:13.3216
 (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: iTdL9eXlSF8Yl6JqXe1VRszxJQDvy9BeS2OqJL6D8KCYS8l9Qs0yoiwhwB2q1yXzwp+he2z0sWSyh10Gt6fLSZn+l8dzBt9jvHOeQLnr6Mo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8583

DQoNCk9uIDI1LzA5LzIwMjUgMDk6MzQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNC4wOS4y
MDI1IDE4OjAwLCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IC0tLSBhL3hlbi9jb21tb24v
S2NvbmZpZw0KPj4gKysrIGIveGVuL2NvbW1vbi9LY29uZmlnDQo+PiBAQCAtMjYsNiArMjYsMTQg
QEAgY29uZmlnIERPTTBMRVNTX0JPT1QNCj4+ICAgCSAgWGVuIGJvb3Qgd2l0aG91dCB0aGUgbmVl
ZCBvZiBhIGNvbnRyb2wgZG9tYWluIChEb20wKSwgd2hpY2ggY291bGQgYmUNCj4+ICAgCSAgcHJl
c2VudCBhbnl3YXkuDQo+PiAgIA0KPj4gK2NvbmZpZyBET00wX0JPT1QNCj4+ICsJYm9vbCAiRG9t
MCBib290IHN1cHBvcnQiIGlmIEVYUEVSVA0KPj4gKwlkZWZhdWx0IHkNCj4+ICsJZGVwZW5kcyBv
biAoQVJNICYmIEhBU19ET00wICYmIEhBU19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkgJiYgRE9NQUlO
X0JVSUxEX0hFTFBFUlMpIHx8IChYODYgJiYgSEFTX0RPTTApDQo+IFRoaXMgbGluZSBpcyB0b28g
bG9uZywgYW5kIHJlYWxseSB3b3VsZCBoYXZlIHdhbnRlZCB0byBiZSBicm9rZW4gdXAgYW55d2F5
LiBDbGVhcmx5DQo+ICJkZXBlbmRzIG9uIEhBU19ET00wIiBjYW4gYmUgc2VwYXJhdGVkIG91dC4g
SSdtIG5vdCBxdWl0ZSBzdXJlIGFib3V0IHRoZSBleHRyYQ0KPiBBcm0tc3BlY2lmaWMgZGVwZW5k
ZW5jaWVzOiBBcmUgdGhlc2UgdHdvIHJlYWxseSBBcm0tb25seSAoYXMgaW46IG5vdCBhbHNvIGFm
ZmVjdGluZw0KPiBlLmcuIFJJU0MtVik/IEZ1cnRoZXJtb3JlLCB3aGF0IGlmIEkgdHVybmVkIHRo
aXMgb3B0aW9uIG9mZiBmb3IgeDg2PyBEb2luZyBzbyB3b3VsZCwNCj4gYWl1aSwgaGF2ZSBubyBl
ZmZlY3QgYXQgYWxsIHJpZ2h0IG5vdy4gQW4gb3B0aW9uIHdpdGhvdXQgYW55IGVmZmVjdCBpbW8g
YmV0dGVyDQo+IHdvdWxkbid0IGJlIGV4cG9zZWQuDQpNeSBpbnRlbnRpb24gd2FzIHRvIGludHJv
ZHVjZSBzYW1lIGJlaGF2aW9yIGZvciBib3RoIHg4NiBhbmQgYXJtLg0KQWRkZWQgdGhpcyBjb25m
aWcgcGFyYW1ldGVyIGFzIHdhcyBzdGF0ZWQgaW4gdGhlIGZvbGxvd2luZyByZXBseSBmb3IgdjEg
WzBdDQpGb3Igbm93LCBzaW5jZSBoeXBlcmxhdW5jaCBpcyBub3QgbWVyZ2VkIHlldCB0aGUgb25s
eSBvcHRpb24gZm9yIHg4NiBpcyANCkRvbTAgc28gaXQgd2lsbA0KdGFrZSBubyBlZmZlY3QgZm9y
IHg4NiByaWdodCBub3cuDQoNClswXWh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC85
ODE0MTQ0Yi01ZWI0LTQyMWEtOTNmMy0yYTE1MjMyYTdkZDNAc3VzZS5jb20vDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:18:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:18:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130222.1469802 (Exim 4.92)
	(envelope-from )
	id 1v1hBT-0001E9-9N; Thu, 25 Sep 2025 08:18:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130222.1469802; Thu, 25 Sep 2025 08:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1hBT-0001E2-6o; Thu, 25 Sep 2025 08:18:35 +0000
Received: by outflank-mailman (input) for mailman id 1130222;
 Thu, 25 Sep 2025 08:18:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1hBS-0001Dw-43
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:18:34 +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 39c000d9-99e8-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 10:18:33 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b07e3a77b72so299593766b.0
 for ; Thu, 25 Sep 2025 01:18:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b35446f667asm116355866b.50.2025.09.25.01.18.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 01:18: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: 39c000d9-99e8-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758788312; x=1759393112; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7oB8D/DRhjwCKPnuI1xXrJHxU3Q5k/Cg5ZzsFYXwBHI=;
        b=FMvVe4hOA5Hb45kIKMUthGHYbjchisZac37x3eYNZ5I3jQRS4ziKdNCIzdXXFidC6S
         XqgRawcB3umXuKMKuCwpunLg0vBgIihltYWDDJuCKQmyfE/lC6/vW7L/wYURuo5U/PDL
         RgR8/7BmFvK40+K5P6/WiHW/jhFDqoKLXpLJevrDHnmS/ua39/sooiGzjHlTyQ5rZs2W
         Z8iio0JoOULzKYkY8pPC6L0fekFmNQ9/jNTFPbMostd9MPpNL0u4pv1xC/qljbqjNTsi
         EOkWWvYVBhy8xTAl0AMAgBRebzUW/qg6fwGyD96rXbJqcueRagA6uEJqZg8mcEfpuejY
         2TCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758788312; x=1759393112;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7oB8D/DRhjwCKPnuI1xXrJHxU3Q5k/Cg5ZzsFYXwBHI=;
        b=vtGX9Y6GU+sgyQMooVQzjOUFgNRjTgs3BVbbW2XQdvZIgFJDcdL4eFxxWvMV82T3+J
         9ey77WHxqp2KLQv0HKpotS8/fDW9aBR986+T4Pc8VyuB4vARpX1CgPQarOmzsUDLtHr3
         q+rCNJDNJIWZTb2NwDExDU5bNQeEmBxMWryxX9EYR5TNqDAeaRiahRpUC/fqpYNF0ngv
         PnYKFJkbzsqeFJS/PL+wRlEmIXseDlGpkuErlAvL7380IKtGsQ7lRasMVAllQLdJHIuQ
         FoxcgJdWyq3adXRmmaYxjAv1AiCj1XyraIY7g3QpyofWVk9JH3NHiZ7T5/85IYMgxwSV
         QR1g==
X-Forwarded-Encrypted: i=1; AJvYcCUEgGRDS3qnt6aHIrs8qCLZR1kNqUcuNZk1xHqJdQupPNFb8UJBAgAtm5swTU3TQTyXojz4gpl8hiQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxRbpTJ4C7qEhoIGUQMdWmLnnlzwE+k5oBpUj7NZNvJ/2T3yVsv
	nXU4RMJl68ixotshGSsVwzI3huylj1w4MmnJayyLxYGR1XG0JUbiGvQAOui0QNE88A==
X-Gm-Gg: ASbGncsWsM48XbPAyi6nyNBa5Bug+8coogVOHL2XFtVN3evpw5TD4QKS7DukEqXXo9l
	JhFnnjKy//XyRJjoBzP6gmjqm7gcKT1scczL/gHhZ3tc8YuGTjRdlKxpBqvxt85pCHoAM/grPCG
	ecS4j7OM1Fc7qEYktehx7btNP6seU1pxqPY2qIh1U+Vqc/mNfNZZofrUUudOuwKK9yLJkuuTkky
	0GR+Tx7pQghRxqP2nhnYy3v2Kb58A3U5aVK5bqPRpntHeizm7kyE0HUM77f8Unpj3RoQuAT4Ysk
	fr6Ikc4FmhJBc20suFGDItC67sMNLMg9YLAECVxtV7XHFPljh83NGEjRsw6g8NhiHy6/MrYhgPE
	hCW50HbemSVgDVMR43+I0G1+2WZA7pnUEHcL7jBqfUSyI/tUNImuzpTpAhp+HB2zOGp1zbPtuVm
	MMbiw4uxA=
X-Google-Smtp-Source: AGHT+IHg69n3u3Cn7ur47mR67y5MWbU7SdrIzz1gRMAWUFxQI0zjtDVSfLnlN88S/F9ereTA9zMwSA==
X-Received: by 2002:a17:907:890d:b0:b2f:65e5:a5dc with SMTP id a640c23a62f3a-b35486d76b5mr197840266b.6.1758788312369;
        Thu, 25 Sep 2025 01:18:32 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 10:18:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 6/8] 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: <20250923043826.3831957-1-Penny.Zheng@amd.com>
 <20250923043826.3831957-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: <20250923043826.3831957-7-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.09.2025 06:38, Penny Zheng wrote:
> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -294,4 +294,16 @@ int acpi_cpufreq_register(void);
>  int amd_cppc_cmdline_parse(const char *s, const char *e);
>  int amd_cppc_register_driver(void);
>  
> +/*
> + * Governor-less cpufreq driver indicates the driver doesn't rely on Xen
> + * governor to do performance tuning, mostly it has hardware built-in
> + * algorithm to calculate runtime workload and adjust cores frequency
> + * automatically, like Intel HWP, or CPPC in AMD.
> + */
> +static inline bool cpufreq_is_governorless(unsigned int cpuid)
> +{
> +    return processor_pminfo[cpuid]->init && (hwp_active() ||
> +                                             cpufreq_driver.setpolicy);
> +}

I have to admit that I'm quite disappointed, considering that I had made it
clear that you're expected to make sure you submit Misra-clean patches: This
introduces a new rule 5.3 violation. Which is even more so odd when - iirc -
there, earlier on, already was an issue with you naming a variable or
parameter "cpuid". Once again, in the interest of getting this in, I will
fix this up for you, but you really shouldn't be using committers' time like
this.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 08:46:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 08:46:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130246.1469813 (Exim 4.92)
	(envelope-from )
	id 1v1hcI-0005Lv-BY; Thu, 25 Sep 2025 08:46:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130246.1469813; Thu, 25 Sep 2025 08: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 1v1hcI-0005Lo-8d; Thu, 25 Sep 2025 08:46:18 +0000
Received: by outflank-mailman (input) for mailman id 1130246;
 Thu, 25 Sep 2025 08:46: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 1v1hcH-0005Li-0j
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 08:46:17 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 118219a9-99ec-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 10:46:03 +0200 (CEST)
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com (2603:10a6:102:322::9)
 by PAVPR03MB10177.eurprd03.prod.outlook.com (2603:10a6:102:32a::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Thu, 25 Sep
 2025 08:45:57 +0000
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd]) by PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 08:45: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: 118219a9-99ec-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j6OIItD6Z0+40cCSnwG5N/LQLnVcERzzgvzyO5556EeKWkhGfQlV+SUmbd6Z5fVWYpXQc7x1QGEobMNeAtoM4YgoItKK7X5frnATXLuwmq9MVbu7fYvPpGqlbbTUAi3bUz0xQvTnA8zvKMHgnaFK+Boy+yY/tueXnzcaiNe+/oImxZxH6hqrraN7yCo4X4v7QdYqx7+9T6Crz7/99QdcF9rCG4n/Vmf2R3Rpg+9huhUkVYJf78hes2EzLcHro4xjhUqQpaS4M1bzS3wrb/dOhaQSOVfYi0mtPuwQ2VlKoUd4n9nJja4pNXWazAt+MYs0dTxXUZ5X4bZKr26ACHQSkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=16u00z1+mtyVpnPty5YPkHMzdWoFNdqBIY/vClrtpuY=;
 b=k9I22jU5hYAVpSMFsToKC96pA4hHc8w4/cijhkKqeYFTVBeIzLXrRaAH8OwvZG5hstU+ncZz5hYIj8F7gHgjuEaR304mF2GzEgwc6pTGEAkSRt0QIDfBsfb0luE0NVzlpF7Ld2ZJptXYcPTnn7bXohyAeV2cxGyRTrYN2sjm+78rWfGNXWHQWPvu9kJQvfiih4+FSGfK7tlWtXPfHliU2toetEycdS1oFWR774YxZFx6+e1KthDDnAGEuuhylj5Xu68LcsnG82OfAvGaelXcxIoluXxaQF/ItiaS7XnNWqNjpBe+Orff2qhG2hirPT+ZcGibl5OOxT7CV1Iz1GbMow==
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=16u00z1+mtyVpnPty5YPkHMzdWoFNdqBIY/vClrtpuY=;
 b=f4ZlzN+gNZAiQXiIvvYGVZqp8tupmFC25jf6EcxTp+9Y7Cwo0hRw99AbzAzjPWbCPrdzBEaTACgbylU2ug4qqNX9zWyoyRYcqceYCP/+XyvgPJl9BA68g88a7Sab086pKGouERxOOIVhSu8L/9w8ZUfaAW/vJEdkxklOR42WLr5PNRqGRRBZ3efQUK+aAzik2jDmWRPzQsPbX8Xh4bQPiXDwb4YJANNjxrjpS415LpMU1EsLyg8aGNHIPAjaYlSxgr1ShSojmXRI4s/x4UMHzJmUlVX/MHxfj9TnLg6M1LFx2iOOoSJx9no5qVFuzxBrwf9XHkvLJzi6fVM6pdHM2w==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Thu, 25 Sep 2025 11:45:54 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/4] Implement CPU hotplug on Arm
To: Julien Grall , Mykyta Poturai ,
 "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?= ,
 Juergen Gross 
References: 
 <0e69a741-b6e1-4315-91f0-581f72092c68@epam.com>
 <16c461a0-cbfc-4979-9513-4528d6b78463@xen.org>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <16c461a0-cbfc-4979-9513-4528d6b78463@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR3P281CA0065.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:4b::20) To PAVPR03MB8921.eurprd03.prod.outlook.com
 (2603:10a6:102:322::9)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAVPR03MB8921:EE_|PAVPR03MB10177:EE_
X-MS-Office365-Filtering-Correlation-Id: e28a1825-9e96-45d1-e045-08ddfc0ff19c
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?d0lTcDVZWVovbk5sSnliaGJocVEwSmpHbFYwVjhPcHp2MWRCZVZpL0dBcWxX?=
 =?utf-8?B?dzdRZjV0V1p1dUZVSnhLWjNPbGlyeTY1NHR1MGsvMFRrNUN5bndaanFCcDI3?=
 =?utf-8?B?dkd6Zlo2UUdweTNvd0hiY3UydWcyV0cveHB3N04yZkFrTWl6L3o3OE55SjlQ?=
 =?utf-8?B?aGhsaXhFUnpta1hwTlRXVmJNOUMzd29UWDV0ZERBWWFxTEZsdG8wM2ZZakEx?=
 =?utf-8?B?WThJZlU5UTJFRkw4TmR1SlN4OHRKMTlNc25oZHNPaElEOHFpL3BLRTdUSG91?=
 =?utf-8?B?OU11b3BNQzd6RU04VGRsN3BXUFk3L20rVHEyc1lIMUxNclBubnhHV0V1ZmtH?=
 =?utf-8?B?Z2ttYzdpbHVuZWFwYXZCUDVhbU9iVTdzbmE1ekhtUlJrc2c3REI4dUI0Sis5?=
 =?utf-8?B?a1pMUFNrdTdnbFBVNUUyWUhKRjN2TzVjYkdJQ3h2dkpwcnpDdUR0N1luQ1Q0?=
 =?utf-8?B?M0t6RU1XUHM5N0hFNUp4RU4yOW1zSTg1aXJMWWdtYjhIYjhKZ0ZOdU1HK25C?=
 =?utf-8?B?ZXplaDVFSVZpWlU1bXpZM2dRK3NNVkVuOUlTTG9lWG1odXkwa29LbGhXRFJY?=
 =?utf-8?B?R3crb3Z3Z2xPVW01VkFwYXA3TDEwZEpLTEtrUzNsSTJQOGI4S2lCbEhDOXd0?=
 =?utf-8?B?VnovOUpPeTVMUVBjRGorYkhNRUE2VVNjYXM2ZWtKNG8xTFc3Qm1DWnl2YVhH?=
 =?utf-8?B?UDUrcHN5akppcU1iYWVhbU1lUk4xT283bmpQbUJZZ3VlN01UR0NJdVFVb2Ns?=
 =?utf-8?B?bjBmK01Ec2NSL0FIbzBYWFczbDZwN25rSDB6SW1jeVlCWlo0ZzFwaFNrb2Jh?=
 =?utf-8?B?RFJMa09GWThLcFpSTEdGZzJVeW1SVG9mVDVCUEt4NzFZdmowakpObVdBVzNH?=
 =?utf-8?B?RUlqYlMyZ1Qrazdxa1l2WGJ3bW90VEdrL244a213aG9DTHgvQ1dHZ2xsa2xD?=
 =?utf-8?B?V1EvUDVFODBvbDJWZmVRSmdmbnBJTHRtR1FXdlpFdUVSZytYaGFJNHZ3QXNV?=
 =?utf-8?B?Snk2dFB3OURxVU9rSWZqUDQ5dWxKRWlvWkVVTmk1OVhtOVowdVdVcEM0OUdX?=
 =?utf-8?B?YUFab3l3eUFSdll2MThKTTF2TWlVZ2tBQk1ac0RUSy9lVEhRbW83VWwyWll1?=
 =?utf-8?B?eG1ZakJRUXNqa1drcGhwZUlXc1VuWENRbGE1TWxlRFN6Rng2d05rcUd4YVhT?=
 =?utf-8?B?QUhKMzBNcGNBTXY2a1UwVDR1NHlxSERjd09EYUd6NFRmaE9jMmQ4T0RTNlZS?=
 =?utf-8?B?cWZxeVpoczlMOTdHd1NzUzBMVTZLTUFkeVFlZ1JEUmlxeEhjcWlDNzd3aUYy?=
 =?utf-8?B?Ujd4MmhseDZWdXFqUTc0RVo5V3JMNjUxZWRhaFJoZjdIYWVBdzBSMDEwQ3U3?=
 =?utf-8?B?OTlpMitYOGdSUkdjTk56OXY2aDRnZmtKRXlPWWt1U21jRnpnRkRkTU5GNzZW?=
 =?utf-8?B?Y0pqUjJFeWJpSEgvTHNROTdoMENuZFR3c1FWWkNQTjdWYVp4QzI5NVZIS1di?=
 =?utf-8?B?MnNNYjZ4aEZWdUtzRzZ0VVlzcjBwNlRsWmFlaGNTV0xLa2xINkJYWmYweDdM?=
 =?utf-8?B?eDRGSWplZTE1ankyR0t0dWZKMll2OHNhbW1VZ1E3THI2WTZDWWNiRGRKOFdl?=
 =?utf-8?B?Z01FblJLN3ozSEZCcDNHTTJudXNEdXRGNlorOUtudkhVMTdJckdoWUNoemZX?=
 =?utf-8?B?ZmVZNWZ3dTdna0ZZUkVpQnp6Qy9aTjdFa0V3a0xVZktyUHZvU3VIclpYOFFZ?=
 =?utf-8?B?UXZlTkdUQkNJME02WjJVb2dpelBhVlNzdlJUM1g2QXBRM0JtTjdVSjRZR3dr?=
 =?utf-8?B?OEhZVzhRbjNFZVpSUWgwU29ENG1XWWlwMkpkdm5PZ0NiVU4yTXJNTHd5bnh1?=
 =?utf-8?B?T0x5OGdnaTVQSlBEQTkxYk5YUzV6MStXRm1zK2V6Tk44Q1Z6QWpzVzl2R2c0?=
 =?utf-8?Q?3Neg6uqGl0t6oJZ9I/LrOwgPlz1Vl3RT?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8921.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?YWk1dWZONFdLNkVLSDBVQUNMaHJsNDdEUFlqMEMwTmxZQUxEdnN2NjYydStR?=
 =?utf-8?B?RDRjcWpVTTBUcVJhN3BnaVphUTg0OXQxWWgwN2xyc2J5MmI1TXdVOXVraWtC?=
 =?utf-8?B?Sjh4SUU2MUIxYVlhb2YycUs1L05IU1h5NUpWS1VhSFZiVXl1dFZwWDBGb0gy?=
 =?utf-8?B?NXFWbWdRUThkVG9kOWJLRXdKYUZ6eVlOR3REYlZPYjRpNUdraGZidVVmMC9q?=
 =?utf-8?B?bTRaQVl2cVBjR1hWWHNIdWRjOEhlRCttOFB2cStPNXFGVkR6Njgzb3l4VTRX?=
 =?utf-8?B?QW92czNjWkRLUkFmL2ZIaENTcjJTL0tXRmtjeFkyYm56TXRDK2ZYd21ERHh1?=
 =?utf-8?B?QzB1RHhPNS84Y3NvRGoyZlVFT0xHVGVMZjA0M1gzTDhLMjBvclhhQlFhWFJi?=
 =?utf-8?B?MGEvVmRMUW1aQXBZN1JmMUxuQ3ZPak1XU3hvS2NJYU9HaERuZVdESjZVNkZT?=
 =?utf-8?B?NGZYV3RWc3BtQUpDbjcvd20wTFR0N2IzV093Y1BLd0JSbGVnTVBPZ0IrU1FT?=
 =?utf-8?B?aXJRQVFTS0ZVZ2lnbTdVaStkdjIwNEU1NjAvODdvVzR5aDZiRVlraTJJQWM0?=
 =?utf-8?B?OEJ0Z2FBbEUzU0MwUkFaWUp6WGtzYjRUbnhHVUo4aVlaUnFGa1B1VU1JWm8v?=
 =?utf-8?B?aUdSa1dxRVRqc1Q0TFQ1dStPTXlUWmVjT3J4Zy9Ba1VRSi9ocHNrTHA4Vzlp?=
 =?utf-8?B?cllJQ3pXUjNqR250cmtXdUl4am96WWxCU2haM3FlazllWms2SzZlS0YzenZX?=
 =?utf-8?B?dUZ3UHY0ZXYrcGlpUU8rbGx5RVlyNEoyVXF5dStkczBXeDdnTWNML3dpamJk?=
 =?utf-8?B?N0VpRFRGQWdwekZweXNDTHpxLzNTWU1QUldONTlqa3hhbVdiU3hpRllOUElR?=
 =?utf-8?B?Nm12WXlWTGUyejRyc1d5VmRFR013aHdrR2d1UzdWM3Yva3NkUjArL1RZeElr?=
 =?utf-8?B?QkUzbnhNVEgvQlA2S3ZkcTZPSTZJT1Z3c2VGbEVGUjVLc1JkdlNDS0FCRktH?=
 =?utf-8?B?WUpaYTh3ODNCQU0zVkFDaUhNZjBuM1pHOUt2ZzFYTStWanV1Yk1DSWhkWlla?=
 =?utf-8?B?RERMN1lXM2NmNHJGTW1XYzd4bldNb1RUU2V1SDVjcGpXVWxIVkV2cHVKUjJ3?=
 =?utf-8?B?a3hvTWJmU252TVp0c2JDSit0NEtwYktaeFMrNW1ka2tvV1kzNko1UUYzVUNR?=
 =?utf-8?B?ajBESnNzeGNpVVBBM2k3ZGlOSzRGWEtPV0JHMHNZQ0lNdzNsTnczRVZLbzYr?=
 =?utf-8?B?OXFPVEFCcU9UTWE0czZGRHB4aWpwU1RVcExCV3U5K2RCWlFPSFdTM1ZjaTdN?=
 =?utf-8?B?cWFxRlZqVnZRbXFIYUtXYS9mSE9iQzNGWmsyS2FrWnhZUU84ODJEL28yNERT?=
 =?utf-8?B?L2EwYlIvT3h3UTJXTFg2REx3dGJ5MytWZWM0blFlNkpPRXl0c1QxVTVwaGFm?=
 =?utf-8?B?VUZ1cENOcE11YnZvdHdWQ2pIeW9XaGFQdUJCenJKeXc3YzlKVUo0UFVNOGxW?=
 =?utf-8?B?RmorOWRQeFo5RkUxSTNDK0VnZGVpSmliWUFROEpYQ3JQVjhNWVBFVWRzeVpC?=
 =?utf-8?B?MVFUVnFQd1lHeU5tYzcwWjd3K1VOa0pYVThUUzBxTmt0ckQrY1FaVGxyZnZm?=
 =?utf-8?B?dHQxT243OGV0WWVPRm5SQVphNzdSMFgvZGpKUEdMSmpPa2lXWGwvS3hTL1Rn?=
 =?utf-8?B?a0JpVFZQTTdsYklJeC9salVtRTZad3dBS0NENmpENkI5R1h6R0w3UmFyTEts?=
 =?utf-8?B?VjBFQnRlUHFuWmd1T1FIRmllTVJkWkZxY2NkR3V0VVV4Nmxrc2tlSkxsSjY2?=
 =?utf-8?B?U2c3QUNyNnNzcXpIWkNEbVhZclpyeVIzTytCU3NnQzNSQUdlbS84OHJiL1pp?=
 =?utf-8?B?NVA2MmJiYkhWV05VMFZZN0VwWXhDNmI4aTRPTVArbnhPUVlJZmlYaGR4cHFw?=
 =?utf-8?B?cnNDaDhDQVBGdkNsbEl5dUtGSDJqMW84c01pVjllY09VY3ZndzJyZ1BSbkRx?=
 =?utf-8?B?WkV0Z3FXRVFraGZwSTdBZ3ptM2M2ZUQvMFcxWkptT1QvRUp5OHQ2R25RM1px?=
 =?utf-8?B?dFZEbmFFRTFDbUk4VnVKWk5taGhBZ1d4aHhoaE0xSGVoT2hKVytjMkhzbDBX?=
 =?utf-8?B?WlJpYmlqdXpMTGs3bVFJZW9hZFhsSHFxU0ZmaHJNSzVkMTZpelZjM1NhSzZr?=
 =?utf-8?B?SHc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e28a1825-9e96-45d1-e045-08ddfc0ff19c
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8921.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 08:45:57.0895
 (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: f8KUXti8LkxfAUthaaw/8+i4OlurDcqeS77ahX1fD36GedQmwwnIa3Nz/fgBkSRB738HdcX3ENvpoGV4PNJ6iFuGtp7N6X1dtfM75/5F52E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB10177



On 23.09.25 21:38, Julien Grall wrote:
> Hi Grygorii,
> 
> On 23/09/2025 17:09, Grygorii Strashko wrote:
>> On 18.09.25 15:16, Mykyta Poturai wrote:
>>> This series implements support for CPU hotplug/unplug on Arm. To achieve this,
>>> several things need to be done:
>>>
>>> 1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented.
>>> 2. timer and GIC maintenance interrupts switched to static irqactions to remove
>>> the need for freeing them during release_irq.
>>> 3. Enabled the build of xen-hptool on Arm.
>>>
>>> Tested on QEMU.
>>>
>>> Mykyta Poturai (4):
>>>    arm/time: Use static irqaction
>>>    arm/gic: Use static irqaction
>>>    arm/sysctl: Implement cpu hotplug ops
>>>    tools: Allow building xen-hptool without CONFIG_MIGRATE
>>>
>>>   config/arm64.mk                  |  1 +
>>>   config/x86_32.mk                 |  1 +
>>>   config/x86_64.mk                 |  1 +
>>>   tools/libs/guest/Makefile.common |  4 +-
>>>   tools/misc/Makefile              |  2 +-
>>>   xen/arch/arm/gic.c               | 10 ++++-
>>>   xen/arch/arm/sysctl.c            | 67 ++++++++++++++++++++++++++++++++
>>>   xen/arch/arm/time.c              | 20 ++++++++--
>>>   8 files changed, 98 insertions(+), 8 deletions(-)
>>>
>>
>> Hence you introducing new feature for ARM I'd very much appreciated if you
>> add corresponding documentation under docs/hypervisor-guide/arm/.
> 
> I think some documentation is good. But why does this need to be Arm specific?

Only because this series is for ARM, if it could be generic (at least partially) - even better.


-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 09:23:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 09:23:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130263.1469822 (Exim 4.92)
	(envelope-from )
	id 1v1iBq-0001uH-5P; Thu, 25 Sep 2025 09:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130263.1469822; Thu, 25 Sep 2025 09: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 1v1iBq-0001uA-2j; Thu, 25 Sep 2025 09:23:02 +0000
Received: by outflank-mailman (input) for mailman id 1130263;
 Thu, 25 Sep 2025 09:23: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 1v1iBn-0001u4-U2
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 09:23:00 +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 37fc059a-99f1-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 11:22:55 +0200 (CEST)
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com (2603:10a6:102:322::9)
 by AS8PR03MB7703.eurprd03.prod.outlook.com (2603:10a6:20b:402::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 09:22:52 +0000
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd]) by PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 09:22:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 37fc059a-99f1-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a86yOlctfUdQLlfs05XKHyPYKxLkxYr/oupQ4jgkDrE27a31w+lI3aI7Tf8kGNkZFkLSC8GgPvcTEdt62kYqwvv8ojEDKTuCBSqfACqpsGYAc9ID3T18/IKEStSzvEHh4Vx4B5NIUVoIN5VMUkkZy7kgRmSF40Jfw1l/IytHmFMb15OjWEXL/6tF0PpowyCKjnowZUyjN9ZFVs78zY6PdDt+zQaXqrcWiSBiS/8fdgthzU/sozaMt7KmBE/AHV1YNj5psVskDiRXa5Mav5xrZoRUz3Og4PMYxF73BL/8JzF0Mg7U395ab89u5B5iiY0MeeQ+h5FebhtSCPHqXu/ORQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=R7TvybvwjUfYCGoxuWlBmuojT+Oy4LB42lpufqmkQJ4=;
 b=O2qBMk7jd6MQ9PPoFdRKCU7+nq6legI8cWgvyWvRZjumGDhMRMkHQxmFlkw45P0j79fZ8RCKKN8ipk/+q4C7SrBtfylFAOlGB4qE3Zx60VmVS/FMwkv4rFreRYnvk8rAyFcax5+hk+xt7qPgie+Kus8l7chQe9w8JP7POx4Y72tEvAgVlC+jgwpno4uatiBLOmRWVMdKSra+OyhiLToqDhpfXhsLqU7xAKbsaTjqaScASoWuvgZWTmyT2AL/HE8aW1duTeIEUdtayxV6whVF6uOJ07R0oRGNoI0NHfMcXho6aaPLvnkVyI28dYmMpPCFO1kfktkyP5Ak9jgwXtUOgQ==
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=R7TvybvwjUfYCGoxuWlBmuojT+Oy4LB42lpufqmkQJ4=;
 b=tfsH7QIOieb7sliBAE2O6BdCeMGVTwe/oLyAzstO9w3sgWNNnizNg51YTjRQFcW5nCLqDoCQ5iZlOahTTP8KCVcT/CeoSB26yRZ2W/jAjJpogx6ZtjsZvKOTinmJ8s4P9d0BKvAeoVJc0r32VeKHQaY0J1FPeck/xU8z9wciRXB83vGLhOCVSmrZe1+dAMqmAch22XHNDS8dT9Gz1Haf3hqFugj9yyp8cN3d/9LenTHji419sIZTkjAukUb/0LqNRQke/f28AR+xvBBV63E/tMi/06/+B7uP5/rX6OPzTbK+zX1qEZql82mPv1q1S3mkiwcS2kqSuaXiQg7GWhjfVg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <2954ab89-cf30-4b00-87c5-37449a571fdd@epam.com>
Date: Thu, 25 Sep 2025 12:22:50 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk 
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0360.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f4::13) To PAVPR03MB8921.eurprd03.prod.outlook.com
 (2603:10a6:102:322::9)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAVPR03MB8921:EE_|AS8PR03MB7703:EE_
X-MS-Office365-Filtering-Correlation-Id: 69dc6496-2e8f-4792-a95b-08ddfc151a2e
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?NU1BTVFsYWpUbFZrOW84NEpPcTZ1THFVQ3h1ZjV3TDVHZVBoZnJ2cnJFUFli?=
 =?utf-8?B?MzdGenhlNE9TZlJJU3JSNTNlZ28zRHpsKzJiRVR6Smo5Y2IrQzFOSURuNmZG?=
 =?utf-8?B?enc5OW4wRElGYU9iZGNKQTJvdlhZMlZUanlnbnU2K0xFQlR4bkR1WjdhcXpa?=
 =?utf-8?B?RXBmeURoMU9ZT3NkY0xqZmNFUmlEbVk5cWR4eHdKaExpZWZhc0dyaFVzVjVU?=
 =?utf-8?B?NVg3SE1GT1FESmpOMUx0bGhOeEVNSEFpTjZ6NUZPcUlXSWxtRHgySWFSc2J4?=
 =?utf-8?B?RTQyT1BLbGR6SjkrTEl6S3k3c0l1VEFUbHE3RHhMcC9KZ0t4dWwxTU5Qclhz?=
 =?utf-8?B?UGgyTUEvNjZGNmRwcWdEWGw2K3NSSWRPRTRQbGg3ZUtwR2VSOWdSeGRpYjdl?=
 =?utf-8?B?eDJvSWVzc3Ivb2Nsd1VuUExwT05ZL0psWFJrcHRKS1dTWjZwMWtRWldmVU4x?=
 =?utf-8?B?RUUyS0JvcE9sWkhFUmovbDQ3aWxXSldMS1NwZGZucGg4bzZiR2YzNDVyM200?=
 =?utf-8?B?TFBKV2pyT2RIcXY2c1BnZDhSREloZFdjb2p4WlVrNVNrcXJ4VmNpYWpxclJZ?=
 =?utf-8?B?R3ZPWlRDUTNtOWJyZXVRSUsvL0pzcW42VTBVK0JNRmpKb05lSzhPa3FXQk1U?=
 =?utf-8?B?SlhhcTF2WXNFMnB1MVN1QkpnUytqcWQyRVU5QnRiTVMrVmkyRmdGSFYxQm9z?=
 =?utf-8?B?NnZ4dmQ0REoxczJvNW1BaEtFUU9TUXV0V1VZb1lRbDM3UWtZendDdmg4VEVx?=
 =?utf-8?B?eVk4VlN5cGpFWUJRY0hnclgyckNXOElqb21TOFIrOFdTK2NPOFVYSnBheThG?=
 =?utf-8?B?NHV0NXBNL2xWS0Z3U2VvaGtPeVBKSGJKaElnellZcy9VWE9zdWVoNzh6dktH?=
 =?utf-8?B?NDVLQVY1ZEJzQllxMTllclNPUlF0c2xlVThsTXV2NWhyQUp6VUExS2tOQUwx?=
 =?utf-8?B?QXgwNXUzdDlNVFVOaUo5VlFPaHRLZjFhcVR4RkRzY3pwN09vclQyYjRYa1BM?=
 =?utf-8?B?NXlXYkFDSEtQbW4wRnZHTkZHOHhFNFk5NUc4eDgyWXBFSTZzLzNBUTRFUy9T?=
 =?utf-8?B?TTFTa3B6UmFsaXBoVHpTbktZd1hqQTZtbE45UDdkeFlMK3lUVE40RkJudEtu?=
 =?utf-8?B?Q1JzaXFDa0tXbDIzcUdVd29VdENCR1p4WVp6bmZDUldGQXkybHEwd0xzVXgv?=
 =?utf-8?B?QVNJN3dQNXlFL2NWcVh3K0IwYTM4K2ljOVBleDVHOEd2NW5CbnJPckVnVFVu?=
 =?utf-8?B?bGN4aHRxVGh1b0RMZXJJckh3bGxlVG0wM2xhUktDUEY0eUJmSTh4N2dGZGdo?=
 =?utf-8?B?QXJOMTB5QXZnQ09wUERrMlUvVXZrcWJqTHBNaHQwa3JVYnVLbUxjOEJ6elpT?=
 =?utf-8?B?WjJ3bFdKMWs3OUxwY09LSFZja1cwbk1KcEVLSCtCczZSMHJLY3RLU0ZmZGZ2?=
 =?utf-8?B?N0g3cEgxeHR4OHJ6KzByWmRKZURZUE9yQVBxQk9QUDFpWGZHTW1Ic3NRWjNi?=
 =?utf-8?B?Qld5Uk9TYTNrR09KbmM5cnBuWFdxOFJqZnYwWFlaM0UzQzY5dkwrRkswSERP?=
 =?utf-8?B?Ky9aMUxwcWp5ZVhSL040bG1BREFEVnA3ZURqY1lwc3MxYTZ6Z1laY2xQYzVO?=
 =?utf-8?B?VTEyWkprYlJydHJOOGRIc1NIREdiSDArTUJueVJZcUFIUHJMeFJzVEw4MmZa?=
 =?utf-8?B?UkFScjNvbFVmbi8wRm40aDBiZXlyRDl4Zmk2djdhcEJQN0V1eDNjZU1GUjZ2?=
 =?utf-8?B?N2wwYVJNWnVsd3k4TElIZmpVMW5ZV2taeDZZUDgwbW5NVWh1VFdrL3ptc05u?=
 =?utf-8?B?bFRueWFxV0RGeDhLeVR3WGNUU2xJQnNuSXRiZHVObTJhMzd5emtKUGt3KzZM?=
 =?utf-8?B?ZlkwVmRVY1hlUTRUSTF1dzNHNkUzVnNPRUdPMEUrQitNTUJ6K0lra05DTm5Z?=
 =?utf-8?Q?yOZl+/qPHTw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8921.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?di9heGpKR3h3STFvTFgvV0w1VDZlV1NVZ3cxdWM4MlFwQjdwczdybHo4ZEJN?=
 =?utf-8?B?ZVkrMUFsSGMrd0VaTUhlTjh6dWJ3THgvekczSWM0QU14bTllZ3pkTG1zcERV?=
 =?utf-8?B?elZCY3hna2MzUUlVa1ZLOTFqUlRzTFpPUVcvYTV3emFQVDZTSjFzK1BsUE9v?=
 =?utf-8?B?MnB5bnA0Ri8xNUd2S3R1T09HOVFJUU8zek1OQis4RVc5MnprT3dGaVBndDJu?=
 =?utf-8?B?SlZwbFpzcEVaZC9KUHlQU2kwZWJhVkh2bWttcW5GOUFBQzhOZDJ1UFA1MS80?=
 =?utf-8?B?cHloVm54VUhxWS9MS0ttdWxydERjL3hkTFRhVEZkY2JiQVRtZ1krOWVKTzJk?=
 =?utf-8?B?WjhqaFE3dFZpU0hGQ2VNenA3M1g5bjlQcERJaWtFVEdyeTB3eHBPek9tUFVr?=
 =?utf-8?B?ZGNKRHZldkFYK213bW5WcE5LM1d1Z2JVeFh0dWNjaVVZNW1sVmJuLzQzTE5u?=
 =?utf-8?B?NnlOOXNzSWpSL2RwN1loOGs2VFJIT29MOURSN3d2a29FSy9EUWgyTXVBbFdp?=
 =?utf-8?B?cUFMYklJNFFDTXVzTW5zVkJvVmlud0Z1QVI4Z2dsOVBWTVZSRWFZeGhkQTFQ?=
 =?utf-8?B?LzFuQXU2K3QwbXBOSEJaQjdHeGpGeE8yL0U3MVlpYmJTZVBzWVZJWkFhbE9m?=
 =?utf-8?B?YlY1bDhlNzEzVUJrUUhzb1dQcE9VTm1kZXcrTXJ5eWRXTXJBdkxwcE00SlpL?=
 =?utf-8?B?cmpGQ1BmY1JEcjhWU3BiNXFUYXBhVURsTGY2YzVyVk0yNzJTYm1qL3lKNzdk?=
 =?utf-8?B?c01EeG01L1dWSW92aTcwcjQ3MXFlSDIreTB0eUlWLzkwUWdSRWh4aldBU3hh?=
 =?utf-8?B?aS9PNE5KdkpkMkZ3eXA1RzEzRlJQTEV1ZFMzVnNRRTNPNU1yMTU4VHRBYkhw?=
 =?utf-8?B?RlJvWFFOUk03cE8rb1BDenpuZ01rbnMvVHBXM0tkaWlGTkJUdGFNOVVOck11?=
 =?utf-8?B?QWlSY0I1V2JRaUNUd3g4U2NiOThwRmNtWWcwZDFSL0tFSFBJV3kzVEVzR2d1?=
 =?utf-8?B?Z2c5M3FhdW1tMEZsZENGd2FvcHVKR1FTL0FwcE5EelJ4aXdVZ0N2dTNXaFhm?=
 =?utf-8?B?ZGFVMWllZmlxb1c2bFlaZFl0bWFnaUZ4dmFzS05mK2NmYUl6MVFsSWdyam9z?=
 =?utf-8?B?RzR3ZmxOcmg4QVB6cnNUdXdRbVVwZzFmRjlaSi9RMDlLWTJ0OE9KeGZ5Rk0y?=
 =?utf-8?B?cmF2dXcybWxoV1B6Wjd4aGFUUGJOdFNlWW52eHRvTTZRZ3dsQjdvRi9qRlhk?=
 =?utf-8?B?U3JQa0tSU1VVQkxYY0dtc0cxazZ5a0cwWU55em1ZVTlFQVNTQm0wZDFkSkNv?=
 =?utf-8?B?ZzF5Q0IvSUJKUEFOelZhOGk2NWR1WUhGRG4vb2U2aVlDcWdpU3hxa1k5cWJE?=
 =?utf-8?B?RzA0QS9LNER0ZVpPT0tKbVpOdHhwakhyd0ZJSUk4MHVQWDJNRHVpcGN6SHI3?=
 =?utf-8?B?WGU4T0h1UDROWEpSTS8weGFVYkRWNHRsZnh2UE1Fc3V1VjY2THlWZm1QMUxH?=
 =?utf-8?B?bW1xcjdxdVVrZTNCYnBYTVVqUDdBOEp3ZEVJbWF1VmFFcmNjY1lZbGVIZmUw?=
 =?utf-8?B?dVRtU3I0R2Q3dnd1QWVndmVSV1Vqa0RjdTRzeW15aFdYdnpaMHp1WWc1ekFv?=
 =?utf-8?B?UTUrbUlzOWN1TWE1cnhKUys1NWdubEN4L1hKMDJVdGh4WkRSMjhLTmVFdytX?=
 =?utf-8?B?QWwwSi9HTWRzVGZUMktCRXNTcTZBRDFid21sVzRlRXFiV2srKzFBZzBJOTdo?=
 =?utf-8?B?M0p6Q20zTFY0MnhmY0h1cXlMRTZjM3M5Y1ExNEpKMGd0U0IyTGxZTjdLeTg3?=
 =?utf-8?B?NElRa0NuM0ZSK3h6TStKempPMmlkZWd0eG1seWxNek5jUW92dkZuaUlkR055?=
 =?utf-8?B?OEpCVmhTNmlJWWxvRlM0VGF6KzNDcnJVWEpUbGFSNEdXS2hnK0pZakttRnUy?=
 =?utf-8?B?MzVZWUJEL1dZREliMVg1eXhLNUwxVFpmMTEwTEUyU25RRDE3aFJiZ1B3QlpK?=
 =?utf-8?B?THVtZ0lOdkgxQzduc2hYRWtWdFhzL3oxZkYzcldOajhGaVd4OUcxNmJHNFhU?=
 =?utf-8?B?RUs0Y3BUS1JUQmxoTTJvbmw2S054VmQ0SlVSZzdpeW93bVpLR09TQXlWZ1RP?=
 =?utf-8?B?NVpTQWYwOXZDV0U4akY4YldkMjBtek1xa0dad1ZVb2xseTRqZlBpa3dCamxD?=
 =?utf-8?B?WGc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69dc6496-2e8f-4792-a95b-08ddfc151a2e
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8921.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 09:22:52.1973
 (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: RmDryI2lSaeohPvOzHo9yvFyddc7n0Ru9m2rNCkffdqL/RWQ3JqLV8jSHSZzzeqowovcHR++S+mgAcviDssQabJbLARgthiW//bMR7i5Wio=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7703



On 24.09.25 19:00, Oleksii Moisieiev wrote:
> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
> allow for building Xen without support for booting a regular domain (Dom0).
> This functionality is primarily intended for the ARM architecture.
> 
> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
> default for ARM and X86 architecture. This symbol signifies that an
> architecture has the capability to support a Dom0.
> 
> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
> expert users, this option can be disabled (`CONFIG_EXPERT=y` and no
> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
> creation code on ARM. This is useful for embedded or dom0less-only
> scenarios to reduce binary size and complexity.
> 
> The ARM boot path has been updated to panic if it detects a non-dom0less
> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid
> boot.
> 
> Signed-off-by: Oleksii Moisieiev 
> 
> ---
> 
> Changes in v3:
> - rephrase error message when dom0less mode wasn't detected while dom0
> is disabled.
> - rephrase help message for DOM0_BOOT config option
> - update DOM0_BOOT dependencies for X86
> 
> Changes in v2:
> - decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
> suggested in ML) because in this case HAS_DOM0LESS should be renamed
> either.
> - fix order of HAS_DOM0 config parameter
> - add HAS_DOM0 option to x86 architecture.
> 
> CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
> regular (legacy) domain an optional feature that can be compiled out
> from the Xen hypervisor build.
> 
> The primary motivation for this change is to enhance modularity and
> produce a cleaner, more specialized hypervisor binary when a control
> domain is not needed. In many embedded or dedicated systems, Xen is
> used in a "dom0less" configuration where guests are pre-configured and
> launched directly by the hypervisor. In these scenarios, the entire
> subsystem for booting and managing Dom0 is unnecessary.
> 
> This approach aligns with software quality standards like MISRA C,
> which advocate for the removal of unreachable or unnecessary code to
> improve safety and maintainability. Specifically, this change helps adhere to:
> 
> MISRA C:2012, Rule 2.2: "There shall be no dead code"
> 
> In a build configured for a dom0less environment, the code responsible
> for creating Dom0 would be considered "dead code" as it would never be
> executed. By using the preprocessor to remove it before compilation,
> we ensure that the final executable is free from this unreachable
> code. This simplifies static analysis, reduces the attack surface,
> and makes the codebase easier to verify, which is critical for
> systems requiring high levels of safety and security.
> 
> ---
>   xen/arch/arm/Kconfig        |  1 +
>   xen/arch/arm/domain_build.c |  8 ++++++++
>   xen/arch/arm/setup.c        | 14 ++++++++++----
>   xen/arch/x86/Kconfig        |  1 +
>   xen/common/Kconfig          | 11 +++++++++++
>   5 files changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index cf6af68299..336b2ed242 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -17,6 +17,7 @@ config ARM
>   	select GENERIC_UART_INIT
>   	select HAS_ALTERNATIVE if HAS_VMAP
>   	select HAS_DEVICE_TREE_DISCOVERY
> +	select HAS_DOM0

Here HAS_DOM0 is selected and all dependencies also selected ( HAS_DEVICE_TREE_DISCOVERY, DOMAIN_BUILD_HELPERS)

>   	select HAS_DOM0LESS
>   	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
>   	select HAS_STACK_PROTECTOR
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index fb8fbb1650..62602afc78 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,8 +42,10 @@
>   #include 
>   #include 
>   
> +#ifdef CONFIG_DOM0_BOOT
>   static unsigned int __initdata opt_dom0_max_vcpus;
>   integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> +#endif
>   
>   /*
>    * If true, the extended regions support is enabled for dom0 and
> @@ -104,6 +106,7 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
>    */
>   #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>   
> +#ifdef CONFIG_DOM0_BOOT
>   unsigned int __init dom0_max_vcpus(void)
>   {
>       if ( opt_dom0_max_vcpus == 0 )
> @@ -116,6 +119,7 @@ unsigned int __init dom0_max_vcpus(void)
>   
>       return opt_dom0_max_vcpus;
>   }
> +#endif
>   
>   /*
>    * Insert the given pages into a memory bank, banks are ordered by address.
> @@ -1962,6 +1966,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>       return 0;
>   }
>   
> +#ifdef CONFIG_DOM0_BOOT
>   static int __init construct_dom0(struct domain *d)
>   {
>       struct kernel_info kinfo = KERNEL_INFO_INIT;
> @@ -1993,6 +1998,7 @@ static int __init construct_dom0(struct domain *d)
>   
>       return construct_hwdom(&kinfo, NULL);
>   }
> +#endif
>   
>   int __init construct_hwdom(struct kernel_info *kinfo,
>                              const struct dt_device_node *node)
> @@ -2046,6 +2052,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
>       return construct_domain(d, kinfo);
>   }
>   
> +#ifdef CONFIG_DOM0_BOOT
>   void __init create_dom0(void)
>   {
>       struct domain *dom0;
> @@ -2103,6 +2110,7 @@ void __init create_dom0(void)
>   
>       set_xs_domain(dom0);
>   }
> +#endif /* CONFIG_DOM0_BOOT */
>   
>   /*
>    * Local variables:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7ad870e382..fbb290df60 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -481,12 +481,18 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr)
>       enable_errata_workarounds();
>       enable_cpu_features();
>   
> -    /* Create initial domain 0. */
> -    if ( !is_dom0less_mode() )
> +    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
> +    {
> +        /* Create initial domain 0. */
>           create_dom0();
> +    }
>       else
> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
> -
> +    {
> +        if ( is_dom0less_mode())
> +            printk(XENLOG_INFO "Xen dom0less mode detected\n");
> +        else
> +            panic("Neither dom0 nor dom0less mode was detected, aborting\n");
> +    }
>       if ( acpi_disabled )
>       {
>           create_domUs();
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 3f0f3a0f3a..2aeb361c63 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_DOM0
>   	select HAS_EHCI
>   	select HAS_EX_TABLE
>   	select HAS_FAST_MULTIPLY
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 76f9ce705f..10a8fc8718 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -26,6 +26,14 @@ config DOM0LESS_BOOT
>   	  Xen boot without the need of a control domain (Dom0), which could be
>   	  present anyway.
>   
> +config DOM0_BOOT
> +	bool "Dom0 boot support" if EXPERT
> +	default y
> +	depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS) || (X86 && HAS_DOM0)

Here you repeat the same dependencies. In general, if you introduce HAS_DOM0,
which is expected to be selected by ARCH, then all you need is

	depends on HAS_DOM0

It's ARCH decision to select HAS_DOM0, or not.

> +	help
> +	  Dom0 boot support enables Xen to boot to the all-powerful domain (Dom0).
> +	  If this isn't enabled Xen is expected to boot in dom0less mode only.

"is expected to boot and launching all domains in dom0less/Hyperlaunch mode only."?

> +
>   config DOMAIN_BUILD_HELPERS
>   	bool
>   
> @@ -125,6 +133,9 @@ config HAS_DEVICE_TREE_DISCOVERY
>   	bool
>   	select DEVICE_TREE_PARSE
>   
> +config HAS_DOM0
> +	bool
> +
>   config HAS_DOM0LESS
>   	bool
>   

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 09:41:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 09:41:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130284.1469832 (Exim 4.92)
	(envelope-from )
	id 1v1iTU-0004ee-Nc; Thu, 25 Sep 2025 09:41:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130284.1469832; Thu, 25 Sep 2025 09: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 1v1iTU-0004eX-L5; Thu, 25 Sep 2025 09:41:16 +0000
Received: by outflank-mailman (input) for mailman id 1130284;
 Thu, 25 Sep 2025 09: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 1v1iTT-0004eR-6q
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 09:41:15 +0000
Received: from CY7PR03CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c112::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1405e63-99f3-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 11:41:05 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB7938.namprd12.prod.outlook.com (2603:10b6:510:276::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9137.19; Thu, 25 Sep 2025 09:41:01 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 09:41: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: c1405e63-99f3-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qfLilHEFV+Kak1n+nCMGUVtFbHu2qh0E+c5ba7C/9wfGTLXtq+S9Wv/DwelVnmkw8vBaow1guFLsl+eivCFP0fjDkJ75K1jYo8skiokzTaKUigtVI6rHOjTzPJJwXSiP2qt8zXkZmjFEst8qS7vi+o6/wg7H8LSJjTD/HYwNmNDarB68oPqNOwcRkW5pg7u5CCLzCU09Ur/9e9MrfgruREY7MlseI0iMmeIbz3HJRQ91dQeAicQnKW5xE9i//RRyvoIlwOSLtbTmvJKr3e+glldkqo8cDcIfi9cPG6o45n6MYfakaojb+L04J4/lmsFrQU0RkNrt0HhPkDJHNklhSA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ko3JZ8qdP4Qi1Vru36LVAxvI5i0fpqb8xxCJswln1N4=;
 b=C7TNXPe0dB05k87mUXPe4bezCzendomW9Fq13AmxiEBPNV5rNn1BZwx/wbxYH9VOBBo9l7Jo2ljxu0kn3X46Ffnq0GuVNGY5LmrdGnzauX2DEd2acWmRhF4RZeE3SFOlDKF07/Y03HPcqTVfhIWSSfrXx252AlDN2FPaWWnMa27uVQujlwADokMXS42KSI1zbwNpTL7Y0KZTk/X2X68LV/0unvsrG0sXNDHJlI3UDViy7P7WU6J2rty0jPzaatHvYVYzyNPLTZR/azPO01PvsuVAcbYabEm7oakJFd2wY6+cZwLBrk2D2MxHgHEN0AEEvrzwdCa1RoSW8sCwl397IQ==
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=ko3JZ8qdP4Qi1Vru36LVAxvI5i0fpqb8xxCJswln1N4=;
 b=J0QYFSjkJybQsLYU0OxHbA7Ds7ftFwk09qeXapRrijZ1oBqV8LjIz6kTNYHOd8EpJYM9+uli1qScJNTRPfs7vwNaMW5g+zstadXJkoira4Ha2c7x0ZoZDDAtjnl3pq7Yc3N5ro3ORgfsjiJK/O/5/2aQ+TMw8Y/gNUAx89oRbMQ=
From: "Penny, Zheng" 
To: Jan Beulich , "Andryuk, Jason" ,
	"Stabellini, Stefano" 
CC: "Huang, Ray" , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYYEaVyPVCsmkah0K573htVM7SN/BaAgBWuJIA=
Date: Thu, 25 Sep 2025 09:41:01 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-Mentions: Jason.Andryuk@amd.com,stefano.stabellini@amd.com
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-09-25T08:35:04.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_|PH7PR12MB7938:EE_
x-ms-office365-filtering-correlation-id: c5021881-bca6-420f-3652-08ddfc17a368
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?OFlyYmk5K0NhNDdiNHptNWZ3L1JpQzN0aUlpdDBvTzhaQnNrOUpLVXBGVGlo?=
 =?utf-8?B?aHg3UU9rdXZtTzNqSG1yTzNCc05nU3A0NGZqTkNtcEVkUlJuUkVRaE1qNmdC?=
 =?utf-8?B?c3ZJbFhCUWRueWZFQzlXZDIzeDZ0K0lWNGhxZGRaTExZcUsxd2s5Vi9Hbktx?=
 =?utf-8?B?eDBnNnVwWjVwUCtYYllLWG5WaURreG9ZMFVnOG5mNmlsUktnWTQzS1JZeUM1?=
 =?utf-8?B?SFZXK0h1ejhBUnIrNW9nS0RFRjNjL2UwcTdiNVA3NGhMOG1zRXhkMUxPcjRC?=
 =?utf-8?B?S2tlNWJ3clJPeFpEUDQxcjk0ZU1zZ0ltRGZTeGNENWFoREMwWjFPaDFha2JG?=
 =?utf-8?B?TjZBWFg4ZXR2b2M3ZkR5QlA4cmtudGZCeXE5SzNNOE4rMUpOdmp1bkNwZHFM?=
 =?utf-8?B?M0FGK0NKRVkvSUpqdHF2UXUwS0ZqaEw4Y1hFbmlmZ3F5aWl6SjNBVFpkcmFa?=
 =?utf-8?B?RlVtblk4d0pNeUsrWllQS3A2ZCtPYTNNQzJWQTJoeFQ4cENKS1NCdTVaL0p4?=
 =?utf-8?B?eXplVXNVV0ZzNVFCN0lrYlA0TEMwSm9pS3cvSDBiM21UNzJHb0s2SGdUODJt?=
 =?utf-8?B?ZlhQL056N3NBQ0Q0Qk5HZUs5UjkxU29QYmRMNTBma1NYS2VPV045cnRzKzFZ?=
 =?utf-8?B?M1p1UFZQUmlNVlpvWjZJc0UzeTlNNktROElUaER2WWRJYTdwS3NHYkJHSDlq?=
 =?utf-8?B?d3AyRzNwWTRNaEIwN1R3MldrMFBIZE5jaHlkYXUyNnlDWUNrVTJ2R2pYZ1Rs?=
 =?utf-8?B?dDhQelVwMGordEFORVhJQmpKR3ZjeS9Sb2pBek9iZkVKTHVmZUJtOW9HQWxn?=
 =?utf-8?B?a1hGbW9sclNpd0NPZDVwRlJDZ0NrSmJnOHhQWmVPcThKMk5adlVOWnNMWHZ2?=
 =?utf-8?B?bWVmdzdLOUVjT0ljM1JhdVdmd2hsN0hlcGFGYTdqOEpKblJYeW5IOGNJelVv?=
 =?utf-8?B?TFhvT1dDMldrNnVkQmRuQmlmSGxUdEtvVFo2RU5tMHNvSGtZYWdGcHRnRk1j?=
 =?utf-8?B?ZS9XalhZT0VlZUN0L3hIUkR5c1p3VGFHb3pqdHVEQStMTDM3SndYN1ZKd3lz?=
 =?utf-8?B?OCtacERzdEpML1lDaENrcURNRXMrNnYvSjdnS2I0bWRIaWlhVEJyT3hzY2Q4?=
 =?utf-8?B?NFJqaW96VjBKUjFkSjNveFB2bVhxQmEzTnhlNnJBOUJacjVoeUtSRkpDUmla?=
 =?utf-8?B?cGVBdWllcnphcmhYbHFLN0tiZDNnK2pjajNTOXhJMkZ2WFF6VEdGQjYrNytI?=
 =?utf-8?B?TUdqZ3VTd25RUzhlRTF0bkVBWVhCWnNtZGZCNkx6ZG9YeDc4TUxna280UmUz?=
 =?utf-8?B?UWVlSnArM3N3Z3QxZUE0S1pMalFNQStSd3E1eWcyV0w1TE1oeUVWUTBhZHlu?=
 =?utf-8?B?RTJ3TWx4c084dUhzL2ZyRnFMS2ovVUxiSkhYSkxCeGdyKy8wMUF5cjBSb05N?=
 =?utf-8?B?RHlxQmxEWURPR2d2eSt6Y0Y3V2xVWGdWTjVqUVRlNENNdjlrZDNndXhtQ29N?=
 =?utf-8?B?RTByOXhuRjRaREl3ZC9HWGNEZkF0bUZ2dUxVQnViV1F4ckFPdFBSQytBeFdw?=
 =?utf-8?B?cU1YcysyL1N3OEMxMlUzZlRud0ZuWmk1M0pYNzEveHhvUEVpbVFpYjAvMjFB?=
 =?utf-8?B?QUY5c1JhTlgyUThLRWxyRWU0OEcxR05ZUEtNK2NBSnA5L0lTRkhVWURDMmJB?=
 =?utf-8?B?MjRLQUZKakNkSDdXWCtCSXR5aFRKVHdneExOeUFMd2R2ZFFEemFqN3ExbWpD?=
 =?utf-8?B?VzlPOElZVVp2U0lQanp0b1MvTGtjdzIvbzlHejZ1a1RZZE1TTnRJd1EwU0Ny?=
 =?utf-8?B?bW02bSt2bEVBL1lvWEo5UmtqeGRobzA4MEVYcWpGTUdCTG14S2FKT0R1Qmdh?=
 =?utf-8?B?dDRkWnJzS0FacVZlaUhJblduelZoc0xIRHFQZWVHdDBUN2FhZmE5S3NQNmNm?=
 =?utf-8?B?OUhsREZ3MTEwOUN5YXgrc2lvdnlrVndVUzgzeVArMnFpTkhVK1ROK2FRTzdG?=
 =?utf-8?Q?LqTJCPRGRCNe2LZyo8gR6PMC3giGZU=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bElQT3ZrNUVldzZGZEVwQVZxQWxkZnM3NTZGU3NlRUNTVmlxMFZKRGtPczJl?=
 =?utf-8?B?THhHL0gzeSt3ZllrcHJEYnNLT0VvdEk1Lzh2aUluMUNGK0owMFVEaFgya0Nl?=
 =?utf-8?B?OHZaWFN1UzhuUUdVcXZ5ZzlOZGxUREdJNUV4WHhlVGVEVUVJRHFRWlBHcWpL?=
 =?utf-8?B?UmZsQzJ4MG1CcmZqQm5URUhlQUlrL0s4aStMSktyMUVQbTB4K1pocVE5TXhU?=
 =?utf-8?B?ZllpQUcxZFBLazZCZFpxNkVVbm1NWGNqRHkrNmU0NWlwTFlDZG9zSDUvMlVH?=
 =?utf-8?B?eEUzYXV6bVI4R3BlRGRGeU1IVCt6UEpZMW5uMWQrOGVBVjFiWVNrS2VySmhu?=
 =?utf-8?B?NURGZUI4K3daYnpjbkJrZ2FpbC9HRGU3QVU0SjdKR3MzNWdOTm5FK2sxSlNj?=
 =?utf-8?B?dG9tc0NYTFR4VE1rN3FPSXFRaUdnbVhwU1pESmlUanZqdWZLWmdqRW5GVjI1?=
 =?utf-8?B?U1Q0NGhJR1ZMQ3pxNEVFcDlqbTU5VzB4SGhlY0pDa2JuY2JoWlFVQlpDQTBw?=
 =?utf-8?B?T3FwM1UvZWU5M1pDNTBOR2p2eFUrZXdqcDBHSGxTeVQzVUFzSUFDYmZaZVhR?=
 =?utf-8?B?Y1JySFFZYnkyK0dmMHRyUmtLNk9xVnRZOUpQT2lWOWZoRWlQd1gzZWhuQks3?=
 =?utf-8?B?S3VKb1U5VE5WUTl0Q2VyRVBkSzBqbkUvYjJlRjRoWkQzNHRpY096YmpWdmtU?=
 =?utf-8?B?R1FPL3ROZ3ZrRGlCd3JCZHprM1B6VG9hM3E0R3RQUkh5V1FkK09HOFMyOEky?=
 =?utf-8?B?aCsxeTd4c2QwaEFkMGFVTnBwdWFLNkNESWdlakg5dEZ3czRSY1FZd0trOXFM?=
 =?utf-8?B?ZmpkQVprcjJUSVlGRFMzV2syZkRjYU9oNnNvWDVmNzRwcGtoZzdJczFLb1lx?=
 =?utf-8?B?YjFmWmRQcnBaTVlKRDJKc2lwMFgwa0pxb2h2dkJuVlhrZjVPRllHVVI5ZkRx?=
 =?utf-8?B?NElPVG5CM0hXUzNpK2RPTEcwaXc1WU93VFozeDMvN3hlejlZaEsvMkZJbnps?=
 =?utf-8?B?R3VYUWtHdjUyN2xYNWZtQ3ExVE1CSUVZaXJBUld0NXpaK1VLT3BKYi9BaGwx?=
 =?utf-8?B?emFrWTdnT0dzaHgzeFMrTGMzTk5KWW8yYTdRYXBuOXE2bFJleUN5Vm45M3U2?=
 =?utf-8?B?VjRBZlZiSEpRYktmSWNMNlJ4aEwveUNTUk1TSGFBbDROY09QY1FwVTJqZmdq?=
 =?utf-8?B?UHNGcXFPY052ckxDRzZOV3FVaTd2cHZSWFhNYnhEUkEwcld4T2w4L0RTNStX?=
 =?utf-8?B?NG1sRGlzeVNYd0xHQ0JWTlNDTGhFcmttWGR5YnY4bXRudnIzYkFCaEJHaXE4?=
 =?utf-8?B?YytoYnVpUXlydVBSUmtkZkdyVi9hdlp4SUlBS0MzdWZrYmYxV29VNm9TdjMr?=
 =?utf-8?B?NkorMUI3UXY0RDdzN3VoOUpOQ09TYm5XNndYV01pQnhuREJXdzJQY0V0TTV6?=
 =?utf-8?B?MkFMQXZrQTRFWUlHaHMyQ2tUdnUreHluZXRKL1IwTkNqTzRRdXo0b1o0RkMy?=
 =?utf-8?B?bGoxNEh4WWJ6QkVRcnZNa0VZTW1aRUswZlNnSWx2cUY0Y3d0T2ZBd0kwMkpH?=
 =?utf-8?B?UThabk1pRXVLbWVJNmkyTUtQY0Rzb1lkWElIMkVjOXl1U2JCdFpmMEsvNW13?=
 =?utf-8?B?d1I3aVp4MHVHRVFrMFJDZUpaU09yWUREVGZkYWdJS05TdlNoV0I0ZDFRK1dK?=
 =?utf-8?B?VWw2TjExRVJ4L0xocm9PdWdYbTYyZnFudUExYmdaRXhsM0phd1VpM2JWSlhI?=
 =?utf-8?B?UGMyOXVhU1NTVzA3U1kvYVJ6amZaUURVV1pxT3hSWkVGa2swTjQ5TmFGMVVj?=
 =?utf-8?B?WXFGREdpQzg3ckhrblhCWU8wUU9vMXlRTExCVEtyb3luNWl1d24vT3RTaldi?=
 =?utf-8?B?T0EvT2NIT0N4OUUyZkhacHNiMlNkZ2NIajRrWlYvRFpVeEQraEozOXF1S2lD?=
 =?utf-8?B?MVBwcU5ldzlJNmhJYVV1WEUyQWo5TFJSTjhad0V0bHlEZjhWN3NPVkZ1bUk0?=
 =?utf-8?B?cHoxdHAvYTNrcmpRWjIrdllhMEdFZTlwVG01U0FrWlI2dUxlTnlKU01nN1hW?=
 =?utf-8?B?NlgzUzBzOFBKcEkyazBuUUlDazRNc2JrNkJyK29JdjNidHkxU3FTMEY4d3Az?=
 =?utf-8?Q?cQtg=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: c5021881-bca6-420f-3652-08ddfc17a368
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 09:41:01.2161
 (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: frB0PNLLgoPYj8sQ+5myDbIfhDfoP5dn+Chry1eVK32vSBj5Slma3+DOYeUdi+bSn7NGmFBsdXkMaV2lG22YIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7938

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEs
IDIwMjUgOTozMCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K
PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBEYW5pZWwgUC4gU21pdGgNCj4g
PGRwc21pdGhAYXBlcnR1c3NvbHV0aW9ucy5jb20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVj
dC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAxOC8yNl0geGVuL2RvbWN0bDogd3JhcCB4
c21fZ2V0ZG9tYWluaW5mbygpIHdpdGgNCj4gQ09ORklHX01HTVRfSFlQRVJDQUxMUw0KPg0KPiBP
biAxMC4wOS4yMDI1IDA5OjM4LCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiAtLS0gYS94ZW4vaW5j
bHVkZS94c20veHNtLmgNCj4gPiArKysgYi94ZW4vaW5jbHVkZS94c20veHNtLmgNCj4gPiBAQCAt
NTUsOCArNTUsOCBAQCBzdHJ1Y3QgeHNtX29wcyB7DQo+ID4gICAgICB2b2lkICgqc2VjdXJpdHlf
ZG9tYWluaW5mbykoc3RydWN0IGRvbWFpbiAqZCwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZXRkb21haW5pbmZvICppbmZvKTsNCj4gPiAg
ICAgIGludCAoKmRvbWFpbl9jcmVhdGUpKHN0cnVjdCBkb21haW4gKmQsIHVpbnQzMl90IHNzaWRy
ZWYpOw0KPiA+IC0gICAgaW50ICgqZ2V0ZG9tYWluaW5mbykoc3RydWN0IGRvbWFpbiAqZCk7DQo+
ID4gICNpZmRlZiBDT05GSUdfTUdNVF9IWVBFUkNBTExTDQo+ID4gKyAgICBpbnQgKCpnZXRkb21h
aW5pbmZvKShzdHJ1Y3QgZG9tYWluICpkKTsNCj4gPiAgICAgIGludCAoKmRvbWN0bF9zY2hlZHVs
ZXJfb3ApKHN0cnVjdCBkb21haW4gKmQsIGludCBvcCk7DQo+ID4gICAgICBpbnQgKCpzeXNjdGxf
c2NoZWR1bGVyX29wKShpbnQgb3ApOw0KPiA+ICAgICAgaW50ICgqc2V0X3RhcmdldCkoc3RydWN0
IGRvbWFpbiAqZCwgc3RydWN0IGRvbWFpbiAqZSk7IEBAIC0yMzQsNw0KPiA+ICsyMzQsMTEgQEAg
c3RhdGljIGlubGluZSBpbnQgeHNtX2RvbWFpbl9jcmVhdGUoDQo+ID4NCj4gPiAgc3RhdGljIGlu
bGluZSBpbnQgeHNtX2dldGRvbWFpbmluZm8oeHNtX2RlZmF1bHRfdCBkZWYsIHN0cnVjdCBkb21h
aW4NCj4gPiAqZCkgIHsNCj4gPiArI2lmZGVmIENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4gPiAg
ICAgIHJldHVybiBhbHRlcm5hdGl2ZV9jYWxsKHhzbV9vcHMuZ2V0ZG9tYWluaW5mbywgZCk7DQo+
ID4gKyNlbHNlDQo+ID4gKyAgICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+ID4gKyNlbmRpZg0KPiA+
ICB9DQo+DQo+IFRoaXMgaXMgaW4gdXNlIGJ5IGEgWGVuc3RvcmUgc3lzY3RsIGFuZCBhIFhlbnN0
b3JlIGRvbWN0bC4gVGhlIHN5c2N0bCBpcyBoZW5jZQ0KPiBhbHJlYWR5IGJyb2tlbiB3aXRoIHRo
ZSBlYXJsaWVyIHNlcmllcy4gTm93IHRoZSBkb21jdGwgaXMgYWxzbyBiZWluZyBzY3Jld2VkIHVw
LiBJDQo+IGRvbid0IHRoaW5rIE1HTVRfSFlQRVJDQUxMUyByZWFsbHkgb3VnaHQgdG8gZXh0ZW5k
IHRvIGFueSBvcGVyYXRpb25zIGF2YWlsYWJsZQ0KPiB0byBvdGhlciB0aGFuIHRoZSBjb3JlIHRv
b2xzdGFjay4gVGhhdCdzIHRoZSBYZW5zdG9yZSBvbmVzIGhlcmUsIGJ1dCBhbHNvIHRoZSBvbmVz
DQo+IHVzZWQgYnkgcWVtdSAod2hldGhlciBydW4gaW4gRG9tMCBvciBhIHN0dWJkb20pLg0KDQpN
YXliZSBub3Qgb25seSBsaW1pdGVkIHRvIHRoZSBjb3JlIHRvb2xzdGFjay4gSW4gZG9tMGxlc3Mv
aHlwZXJsYXVuY2hlZCBzY2VuYXJpb3MsIGh5cGVyY2FsbHMgYXJlIHN0cmljdGx5IGxpbWl0ZWQu
IFFFTVUgaXMgYWxzbyBsaW1pdGVkIHRvIHB2aCBtYWNoaW5lIHR5cGUgYW5kIHdpdGggdmVyeSBy
ZXN0cmljdGVkIGZ1bmN0aW9uYWxpdHkoLCBvbmx5IGFjdGluZyBhcyBhIGZldyB2aXJ0aW8tcGNp
IGRldmljZXMgYmFja2VuZCkuIEBBbmRyeXVrLCBKYXNvbiBAU3RhYmVsbGluaSwgU3RlZmFubyBB
bSBJIHVuZGVyc3RhbmRpbmcgY29ycmVjdGx5IGFuZCB0aG9yb3VnaGx5IGFib3V0IG91ciBzY2Vu
YXJpbyBoZXJlIGZvciB1cHN0cmVhbT8NClRyYWNraW5nIHRoZSBjb2RlcywgaWYgWGVuc3RvcmUg
aXMgY3JlYXRlZCBhcyBhIHN0dWIgZG9tYWluLCBpdCByZXF1aXJlcyBnZXRkb21haW5pbmZvLWRv
bWN0bCB0byBhY3F1aXJlIHJlbGF0ZWQgaW5mby4gIFNvcnJ5LCBJIGhhdmVuJ3QgZm91bmQgaG93
IGl0IHdhcyBjYWxsZWQgaW4gUUVNVS4uLg0KDQo+IElPVyBJIHRoaW5rIHRoZXJlJ3MgYSBjb25j
ZXB0dWFsIGlzc3VlIHdpdGggdGhpcyB3b3JrIHdoaWNoIG5lZWRzIHJlc29sdmluZyBmaXJzdC4N
Cj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 10:15:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 10:15:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130313.1469886 (Exim 4.92)
	(envelope-from )
	id 1v1j05-0000lL-KR; Thu, 25 Sep 2025 10:14:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130313.1469886; Thu, 25 Sep 2025 10:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1j05-0000lE-Hl; Thu, 25 Sep 2025 10:14:57 +0000
Received: by outflank-mailman (input) for mailman id 1130313;
 Thu, 25 Sep 2025 10:14:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1j03-0000l8-M0
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 10:14:55 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ac99db8-99f8-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 12:14:54 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-62fc28843ecso925480a12.1
 for ; Thu, 25 Sep 2025 03:14: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
 a640c23a62f3a-b3544fd0a64sm137302066b.85.2025.09.25.03.14.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 03:14: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: 7ac99db8-99f8-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758795293; x=1759400093; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aeAeXlAbXoeVkWJUyNGQ1wkJMedtU3dM69DenLizizs=;
        b=OaZX01b1hqWtyoZ4h3+OWbF+Ep7ePnWZtX/Uxq1W30FVOSoGXxGBcfdGtDWqp92viD
         1mQGtLDqDw1LARd3jLIyxPiqXIRw4Yq/Z8vBqhsJ7kMJz+5Rka0/S+rP33nQY5+8Kz4k
         7VUmJFOkBGU974UiiwBuwpwdQvqRJ23wKfQo2KBITCoOM/4AdvCU67U63rjBol+d2PoV
         HyGsmnSHhpwlCQgJeIOkI2/rITHq+qyn/Z+nP50FIXfi+Gi3lH1Hn5IJgM6c0i9BuCIL
         LSNfhPctGyA84S9aciymAPWigtc2H4Ds45H2a9Fbmgjejirii40G4A61quC9bOGLeztR
         XuDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758795293; x=1759400093;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aeAeXlAbXoeVkWJUyNGQ1wkJMedtU3dM69DenLizizs=;
        b=oBbV1x5wWjpMaGafv0+SEAVjFXv7jzn4//uEQvtuBYFpZMOvGYCCNvomoCjnnVGZ4d
         jA4t0WUz9MsqduxYbrKEnemMjLUYPl8rdIxEdcaP64LmTRmfqaahLGFkIh1ON0dLME4o
         Axhx/ld5tPGIpa+Mg7k0roxbjOA9eegazm43WsMxOFq2+ZmklIwmm4Azf09ISdTbRETd
         MarFat0k5gXZePB7R6rnK7K+GJqqNtXsb9KdRN75Do+TZKroqjgdnxCbsFAUAENNnekS
         0vW8K5kEGNNKrFb2opafzzcT7GgPOpt+yWk4oRq2HGYsD8YBuc4EcqS+fnK9d0VIekcT
         19Yg==
X-Forwarded-Encrypted: i=1; AJvYcCUM6dKAXYN2hWU2KxRH7jw5xnHed+TTq0qfDHFCElau4WZTGdsuZJyn+SwviuI+PK8b6Spnc7xNop8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxE3FbdVWbaU6XlBbIM3TkyO6hYUG6XfwMWbLe6gkFscmsLMEwI
	uTCzdkWI8g1e6x/PI1DtxLMdpvDGuqArCElpgUwRcW5/HSkPNza5n/BBJnY8M0fTQQ==
X-Gm-Gg: ASbGncuflmod+45xel+2izqvUpe/kPQzpMMaelwL2sXTzzHUEDIqEFkEa7XrmdutAo6
	yiebE16zVgoVulHK1g2WARa4mjmYfYrUcWG9VDuO+rmFmto6ghwdmvGwqmHSuZ2lT5gBaaAp7xK
	3rhFIT9TEkmnpJxDfP8UE5fIMG0HfrgtoISGmCPdjqvhiMYRj4/Pu/Jzz3WNYH+RuBLxbHSwUIY
	ff40xQz/zSHFH9/OaskCIc3SEYwq9+mzxbFN6XdWNTw7QFcuNKmDcMiaF0GjsNh4Ur/neseWdh6
	EgVdSRHPnGy7Fx0BV7D3mSOeaYcim8cDDl/fLbJ/xYwkO6m/2kOAFgEd2hkV1h2mhPDbdxhTDqT
	QT7bxU3EVMZ6+UJfnoRJ68rHV2ncE9eJKBLKzVqUZpxgd/rSNjicPeflTVKrxfIE9Dt3Da+25Yz
	U3qq5vEOg=
X-Google-Smtp-Source: AGHT+IEprk6688V+XUNP41hZ3jJNhAQ8lPGp8D9qvrj71UFU5NPPjzab73oozCNYZVKEAcWL2+NMag==
X-Received: by 2002:a17:906:4fce:b0:b2d:b5d3:9630 with SMTP id a640c23a62f3a-b34bcd58344mr336683066b.48.1758795293351;
        Thu, 25 Sep 2025 03:14:53 -0700 (PDT)
Message-ID: <303871e2-f81a-45f7-a396-7bb449606dc7@suse.com>
Date: Thu, 25 Sep 2025 12:15:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
To: Oleksii Moisieiev 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 "xen-devel@lists.xenproject.org" 
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
 <9507e775-f9c3-4351-9c76-ca939c1147bc@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.09.2025 10:14, Oleksii Moisieiev wrote:
> 
> 
> On 25/09/2025 09:34, Jan Beulich wrote:
>> On 24.09.2025 18:00, Oleksii Moisieiev wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -26,6 +26,14 @@ config DOM0LESS_BOOT
>>>   	  Xen boot without the need of a control domain (Dom0), which could be
>>>   	  present anyway.
>>>   
>>> +config DOM0_BOOT
>>> +	bool "Dom0 boot support" if EXPERT
>>> +	default y
>>> +	depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS) || (X86 && HAS_DOM0)
>> This line is too long, and really would have wanted to be broken up anyway. Clearly
>> "depends on HAS_DOM0" can be separated out. I'm not quite sure about the extra
>> Arm-specific dependencies: Are these two really Arm-only (as in: not also affecting
>> e.g. RISC-V)? Furthermore, what if I turned this option off for x86? Doing so would,
>> aiui, have no effect at all right now. An option without any effect imo better
>> wouldn't be exposed.
> My intention was to introduce same behavior for both x86 and arm.
> Added this config parameter as was stated in the following reply for v1 [0]

No. What I said was "Imo at this point x86 should have this option set to Y
unconditionally." That's not what the above construct does.

Jan

> For now, since hyperlaunch is not merged yet the only option for x86 is 
> Dom0 so it will
> take no effect for x86 right now.
> 
> [0]https://lore.kernel.org/xen-devel/9814144b-5eb4-421a-93f3-2a15232a7dd3@suse.com/
>> Jan



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 10:45:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 10:45:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130345.1469937 (Exim 4.92)
	(envelope-from )
	id 1v1jTk-00052I-BG; Thu, 25 Sep 2025 10:45:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130345.1469937; Thu, 25 Sep 2025 10:45: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 1v1jTk-00052B-7v; Thu, 25 Sep 2025 10:45:36 +0000
Received: by outflank-mailman (input) for mailman id 1130345;
 Thu, 25 Sep 2025 10:45: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 1v1jTi-00051i-Mk
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 10:45:34 +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 c3348513-99fc-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 12:45:33 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-afcb7a16441so126284966b.2
 for ; Thu, 25 Sep 2025 03: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
 a640c23a62f3a-b3545a98300sm138765266b.106.2025.09.25.03.45.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 03: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: c3348513-99fc-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758797133; x=1759401933; 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=Pd/akF4fVwQ7syFrc17Agl01p6IeVAe0WtHVGjlR85w=;
        b=W1dzOOhTOUluY/y4lqlMGJSwXySefLkOEQcBdW2O/G5Eat/zxjvfFJgE7uf9HOdyS2
         RfewlffFvuOLNEurX1n23pNM+QVCNN8R+ktkh2kUSSMN7La7NMHqnIL5oviHQ83Cr3vB
         U2VU98rjPigv/CacXs39b48/DiS0Ka57MjW5ZkFqrmr0K81uQGjWehfI0fJkPQ3MDnQN
         wSlq8YZyMKLnm+i+mZJCpSIe0HlrBIm8K+z6xQBvCllcNmkKEi9yIYi5TX1hvalRgkEA
         I8y7dzBF9BS6l/nt5+ApqMgrBHJPDC0Kxb03D0mer4m6zl+8kqPkT4kF+j9D6pRHWVbm
         2Q0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758797133; x=1759401933;
        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=Pd/akF4fVwQ7syFrc17Agl01p6IeVAe0WtHVGjlR85w=;
        b=tUeti7zhdx9pmHmy9Mh7BDwo55F155cXsqcl1NxihuheTaIR7qKWt5xpP1lmDF4kKK
         iI5ipIDrTgjQr3oae4p+qS6I8n42Go5EMiBRCNgfmMxzWZsVAkr9GwNGiiBpz34KOMCA
         zVw0HHs3Gs7MpW3eZsPdUe21XXZ7yg1e03JjF5cMV3maJu9MBRAIqySHLeci86j7lCKv
         8g7+xKxSo1PTKf3iZD/qAUzcV7kR/3K5ctWkIr3Mb8MvvZR3GpEexMa4ItNV4dwWw9od
         9gBYvOExkTfsMMeSy36KUzPOSsEVvqMKlW6/fh5E6dwuLqK83FJ/RK9KpMjPRHO0QAjI
         B0wQ==
X-Gm-Message-State: AOJu0YwdVKV0NuaYfZK1RvRdkqU93qux3BUXAAqNvN9cliVpUR8i1J4j
	8h5Y0QxYuflePaiBliXrf1IZwUdx+tg9QyHjNxFvudlG/WGwNuZP9425cRvz+oh4yLgIk7hzGbW
	l3Wo=
X-Gm-Gg: ASbGnctv5Ey2GOZVs7n1HAONTIbXNin8IWNCOzJeCNh/7l63B6ZjRhx7OfUt255v8Vw
	M4kHxUyoCS89mBCqdD58LU6xnYkQmBTMtwwzkJlbH1irD81ZqqE5//yc113CxAGIIkVGQsTa2Zy
	wJoksRSqezoQ5I3SdtE/yBLE9Qav/D+lU0O/oSKxcq0a6JwYZUleznAlrjPZLoTTV+OLb7BFKmA
	UIaPuK5J9A4qWHOIVcms2uwana2Da/0vvf7s7xXEepIsMeEM8A2ydIuD2Hn6rb6RbOAcatDCGVx
	yySu38mJx1Dmq9MhrK+TfT2o+35EqtDZWTaZJ9Gcj9hrLyThzeWAh67qHYrJvrrPEOEl3yOA/Eb
	xDlFBbA26gbCS5VzB2zmhdK6EjUcH8vBaof6nH3Wn+R/BsPM2Ih/yAQiGAFb6QKichUtGBzRckM
	ujgGN4cs8=
X-Google-Smtp-Source: AGHT+IHNtWncJZsgjHcmNtNir/KdI4G/5BqfYa0uQvBMy6Fmmq3SGnxHumcGsWOiSUc+dkGqjYjpRg==
X-Received: by 2002:a17:907:9628:b0:b2f:e1df:1b52 with SMTP id a640c23a62f3a-b34bc67b048mr284843566b.47.1758797132787;
        Thu, 25 Sep 2025 03:45:32 -0700 (PDT)
Message-ID: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com>
Date: Thu, 25 Sep 2025 12:45: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?= 
From: Jan Beulich 
Subject: [PATCH 0/2] x86: ERMS follow-on
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Patch 1 is definitely intended for 4.21, to limit possible performance fallout
from the ERMS series. Patch 2 may be too intrusive to consider taking at this
point.

1: x86/AMD: avoid REP MOVSB for Zen3/4
2: x86: guard synthetic feature and bug enumerators

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 10:46:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 10:46:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130356.1469951 (Exim 4.92)
	(envelope-from )
	id 1v1jUu-0005cR-N1; Thu, 25 Sep 2025 10:46:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130356.1469951; Thu, 25 Sep 2025 10:46:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1jUu-0005cK-Ie; Thu, 25 Sep 2025 10:46:48 +0000
Received: by outflank-mailman (input) for mailman id 1130356;
 Thu, 25 Sep 2025 10:46:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1jUs-0005cA-W7
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 10:46:46 +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 ed0836b4-99fc-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 12:46:43 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b2ef8e00becso163000466b.0
 for ; Thu, 25 Sep 2025 03:46: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-b35446f7472sm141276666b.57.2025.09.25.03.46.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 03:46: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: ed0836b4-99fc-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758797203; x=1759402003; 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=Sou60HWqNHvUljooVDmBcMtkjAZ+GcrOgZ1byfQcMzE=;
        b=Fo2yBaH5xRTehsiKFMiWL99aeFGDWaVySGoy43PlrRm6ijLAmUV2Vw4gngffCousHm
         to39zIWs4syqjvuoVw63oWiWSX+KBubXdHIS8Mo9fRee7GRhiL1SQRK1Vu47spqloUT3
         LudkaA3tvxGdVfn9PRxMimZDCKwhfkMy/W5MBIk7wugOIyY5M7PE//eu7/kmy40d4Blp
         l5yNpxCwK3byJOeHCWfoMFVXJbBBIvf20BsS2/uA1pGy6w2h9a6G3+UsYayAfMyFZRJt
         pDxk1o6lbh22tQieS4h+xF6Prh4CwtxgTmcWqTuiEpWUsqd/XHAgntfQXc3bYbUlrFPT
         InNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758797203; x=1759402003;
        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=Sou60HWqNHvUljooVDmBcMtkjAZ+GcrOgZ1byfQcMzE=;
        b=wF8BaZA1hwXphcBEX1ampq+mn8AkxPfU3sdgGcWo2nDgQJOPpc8kYlpm/9C5VsNOZh
         pjmtd4UvyMOyzIumBKspO59bHjyO63yF7QdGwtk9mf1eeypEioYoCkxYibG1zKK3X3Jt
         jBaFeIHH0bVEGFHuOYUnxiQuXJleQXhIZ31Mli6Sf0ya6vuhnVVY1q55KmN+jer0qcp3
         z1QhGqEWc8TdVGtLU2+SufoXdmEz/pMuJ1RAEiE87catnqZTCS062UbNxs+LwVeYiv0z
         U7rHAbu9xcCkWJ2Xr5OoCciOxnd7lDfOzBQmeOZr5bw0oIaFemgfaJQ8jMaIxSejuNdy
         offA==
X-Gm-Message-State: AOJu0Yy/mCCIy+nJ16oe1ZoREMaGVyc8VM+p/wWIsJ0GSrJ9fijUPEkd
	H8etNdGralynynzKqViiJrXWuFarp60DN+5HNcjbtKL4Esldp16ezDnFjkNhiU5u3aqJCMxFc95
	oyq8=
X-Gm-Gg: ASbGncuSoFd96k9bcscEb43KFSudwnthTk/JclEPCGjIIuVmu72aabPEhO5UdQzVWBk
	Xci2uDGyasB2ImP4P9A0B7+C/T+ZLT58jbI8d6P2TfJ//e7Z1PgJjNJbxSPLLXEk5ND4Z4XdX4e
	MX9wfR6KiGi9fdvCZL6b7Ze43/HCb3dhNwswGwz36EyukTVj39MIFITHg7YYNmIxcVt8Y68J/kM
	1r9TsKuXfHuBM8/FsZ4O0rfozlBMekYu49PGWlSQ1yl63pu9jA3uEtedjK+hGK3BpETz+fNH2ud
	e0MWshXV9RsufGpdiFZnXuTEChEzorP9UYK/0nJo/HGyRINJ9m7LvIQfso62viXJ1tSy5hRI6Ft
	cn5r/ldmLh8TwWyD8iktjGS5HOAEcww9dhqLB3NUVC6gWBbwMPJI6tPDbhxFUEgADt46rRyPfpr
	/SFgJWRhw=
X-Google-Smtp-Source: AGHT+IHfPKu0e+qE5+gpPqP/8uHmVswfZmQrUlr9XLAs5JiI0ePew/p8xaVsUN6pP1jFGS6lqHp6Jw==
X-Received: by 2002:a17:907:6ea3:b0:b07:d904:4b9c with SMTP id a640c23a62f3a-b34ba147a47mr343958566b.12.1758797203115;
        Thu, 25 Sep 2025 03:46:43 -0700 (PDT)
Message-ID: <6bcaa5b7-4e34-40c9-85e6-48a0a5869b86@suse.com>
Date: Thu, 25 Sep 2025 12:46:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH for-4.21 1/2] x86/AMD: avoid REP MOVSB for Zen3/4
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko 
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@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: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Along with Zen2 (which doesn't expose ERMS), both families reportedly
suffer from sub-optimal aliasing detection when deciding whether REP MOVSB
can actually be carried out the accelerated way. Therefore we want to
avoid its use in the common case (memset(), copy_page_hot()).

Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
Question is whether merely avoiding REP MOVSB (but not REP MOVSQ) is going
to be good enough.

--- a/xen/arch/x86/copy_page.S
+++ b/xen/arch/x86/copy_page.S
@@ -57,6 +57,6 @@ END(copy_page_cold)
         .endm
 
 FUNC(copy_page_hot)
-        ALTERNATIVE copy_page_movsq, copy_page_movsb, X86_FEATURE_ERMS
+        ALTERNATIVE copy_page_movsq, copy_page_movsb, X86_FEATURE_XEN_REP_MOVSB
         RET
 END(copy_page_hot)
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1386,6 +1386,10 @@ static void cf_check init_amd(struct cpu
 
 	check_syscfg_dram_mod_en();
 
+	if (c == &boot_cpu_data && cpu_has(c, X86_FEATURE_ERMS)
+	    && c->family != 0x19 /* Zen3/4 */)
+		setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
+
 	amd_log_freq(c);
 }
 
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -684,6 +684,9 @@ static void cf_check init_intel(struct c
 	 */
 	if (c == &boot_cpu_data && c->vfm == INTEL_SKYLAKE_X)
 		setup_clear_cpu_cap(X86_FEATURE_CLWB);
+
+	if (c == &boot_cpu_data && cpu_has(c, X86_FEATURE_ERMS))
+		setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
 }
 
 const struct cpu_dev __initconst_cf_clobber intel_cpu_dev = {
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -7,7 +7,7 @@
 #define FSCAPINTS FEATURESET_NR_ENTRIES
 
 /* Synthetic words follow the featureset words. */
-#define X86_NR_SYNTH 1
+#define X86_NR_SYNTH 2
 #define X86_SYNTH(x) (FSCAPINTS * 32 + (x))
 
 /* Synthetic features */
@@ -43,6 +43,7 @@ XEN_CPUFEATURE(IBPB_ENTRY_PV,     X86_SY
 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 */
+XEN_CPUFEATURE(XEN_REP_MOVSB,     X86_SYNTH(32)) /* REP MOVSB used for memcpy() and alike. */
 
 /* Bug words follow the synthetic words. */
 #define X86_NR_BUG 1
--- a/xen/arch/x86/memcpy.S
+++ b/xen/arch/x86/memcpy.S
@@ -10,7 +10,7 @@ FUNC(memcpy)
          * precautions were taken).
          */
         ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
-                    STR(rep movsb; RET), X86_FEATURE_ERMS
+                    STR(rep movsb; RET), X86_FEATURE_XEN_REP_MOVSB
         rep movsq
         or      %edx, %ecx
         jz      1f



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 10:48:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 10:48:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130375.1469961 (Exim 4.92)
	(envelope-from )
	id 1v1jWh-0006HR-5Q; Thu, 25 Sep 2025 10:48:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130375.1469961; Thu, 25 Sep 2025 10:48:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1jWh-0006HK-2P; Thu, 25 Sep 2025 10:48:39 +0000
Received: by outflank-mailman (input) for mailman id 1130375;
 Thu, 25 Sep 2025 10:48:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1jWf-0006HA-8h
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 10:48:37 +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 2f6010d8-99fd-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 12:48:35 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-63486ff378cso2409212a12.0
 for ; Thu, 25 Sep 2025 03:48: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
 a640c23a62f3a-b353efa4696sm141811766b.27.2025.09.25.03.48.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 03:48: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: 2f6010d8-99fd-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758797314; x=1759402114; 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=YMihasvWL1RRVVTZNRiWGSCKAq2TFuVC0buNt4sTSJk=;
        b=gaRpYnQlQhV9k6F1PF24h2V7lpGYccSOQaESBr89SVQpGm+OZ72KgydxpYslBP47mL
         Bg2sUqd6rprT5HijsiTeAve8g0glePLRGc/JIXnJX1zpAb7i8g5pz/YdHR8ZxNRjfHx2
         0Z9W2Q/vHtTU8BSkxPMCSimkg3MuPx/f84/d/pP0lY6T3kL6pMRkvffhhPXejnZmbcZY
         aCPmm9ruLeLpLyL4P3nPJT7SSyN6wC8lJ1QUTxbqgGMGh6lwnWKmB+xG7dUmaucqa3Il
         7dsesMizloDZgB5DIRRiJlKRmFh533MR5+L+xPM1NaI6PwLzVToiBQpqIKNf613uf9qE
         XuIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758797314; x=1759402114;
        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=YMihasvWL1RRVVTZNRiWGSCKAq2TFuVC0buNt4sTSJk=;
        b=fHvwYLgPIg2+pbICNUznVKnvCMljNGp6J+k2ayszvt10m1r9IVuspRNzyAyz6XhMnJ
         IfDvPVyFgyv2NfM768gNbdgIVRpiT+p245z5XXIZHzuBCLKia2dQbQ/ISsUovY2Nnufi
         wqGVQSfn+unHsDlIv0Ss+xAf3DOkmmc6cHNmDzyf9sgvgGgfLpw1NdBk+3Of+GryabxJ
         lqTphcRNYihZ+ZKIlGlSmP1WPZlBeAf1/meflZk2BMFZ4fhX5mo+aXc5sn5AYUVj1l+7
         XdKJcP2RtujA14AHmK8yR4dwDhmMGZEVsUlc9bNtlCntK9ODT332VbHBiTxMLxkYosCc
         0WGQ==
X-Gm-Message-State: AOJu0Yz/BgNKFQfHKROYHrUH55R1vfg5++srycGNzvMxUTsDkTeCyGe3
	tXszaVhieeBbl8M87A+zyrvsNgqWx852VV+cOR87TLlZVtbz99o7zmmeaARWK4juDVW3uGLNLCX
	YQNE=
X-Gm-Gg: ASbGnctPMTsbucnfyLnxw2SE/Dol4R1GG7x1l1+DYA3c8zac3QFTYT2iMzDvmMcNwjB
	yvR1nkAp4v7HZu/Cmo+H9yCBSFmFQ+5zJsJ1bVT+PATidglUCIldefphaU5Bi4ElI7mTeGigbO4
	S6tE/nuQcuwiBqthCrKCYEArbvHjz2fKZJO9obe9ZkorOe7FgdgT+1gG0UfrNY3bh4Pqjr+lThp
	OwlK5xvjcvYuvCfzBE3esLKjEvJA/XX68roe7i0M4XTMubBAUIpF1vUth3aaYMIAiIwdNeZaaS2
	nDc0BiTnq98S7r5VuhmAZMBzYahFD3mbpPcwHZ6WyWyks+b4s3W7wrccAe7shrdlexvaIM4GbW7
	VST/QAyxUSvoOiKmlbHvWDk7wC2Eco30ugjwRza6U3Pc+JDDY8QcgnBdejLrjyKTWsLK+VUzSYI
	Xrqs7goFg=
X-Google-Smtp-Source: AGHT+IFnf3sK4qUpnmU9CLGk2EfLfjeEP4XC8KY8xUjfb4U5kfXZjVeQTG+x/9RT8Tp38tpopupCwg==
X-Received: by 2002:a17:907:3f1d:b0:b11:ce93:4388 with SMTP id a640c23a62f3a-b354c63b3aamr252252866b.25.1758797314320;
        Thu, 25 Sep 2025 03:48:34 -0700 (PDT)
Message-ID: <48dcc0e0-2772-49b9-9383-5bf69f922053@suse.com>
Date: Thu, 25 Sep 2025 12:48:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 2/2] x86: guard synthetic feature and bug enumerators
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@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: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While adding new enumerators one may overlook the (rare) need to bump
X86_NR_{SYNTH,BUG}. Guard against that happening by adding respective
checking. The use of BUILD_BUG_ON_ZERO(), however, entails a number of
other changes, as the expansion may not appear in the assembly produced.
Furthermore inputs to file-scope asm() are only supported in gcc15 (or
newer).

No difference in generated code (debug info, however, grows quite a bit).

An implication from the changes is that users of the alternatives patching
macros may not use unnamed asm() input operands anymore, as the "injected"
new operands would break numbering expectations.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/include/asm/alternative.h
+++ b/xen/arch/x86/include/asm/alternative.h
@@ -70,12 +70,12 @@ extern void alternative_instructions(voi
                     alt_repl_len(n2)) "-" alt_orig_len)
 
 #define ALTINSTR_ENTRY(feature, num)                                    \
-        " .if (" STR(feature & ~ALT_FLAG_NOT) ") >= " STR(NCAPINTS * 32) "\n" \
+        " .if (%c" #feature " & " STR(~ALT_FLAG_NOT) ") >= " STR(NCAPINTS * 32) "\n" \
         " .error \"alternative feature outside of featureset range\"\n" \
         " .endif\n"                                                     \
         " .long .LXEN%=_orig_s - .\n"             /* label           */ \
         " .long " alt_repl_s(num)" - .\n"         /* new instruction */ \
-        " .word " STR(feature) "\n"               /* feature bit     */ \
+        " .word %c" #feature "\n"                 /* feature bit     */ \
         " .byte " alt_orig_len "\n"               /* source len      */ \
         " .byte " alt_repl_len(num) "\n"          /* replacement len */ \
         " .byte " alt_pad_len "\n"                /* padding len     */ \
@@ -127,14 +127,14 @@ extern void alternative_instructions(voi
  */
 #define alternative(oldinstr, newinstr, feature)                        \
     asm_inline volatile (                                               \
-        ALTERNATIVE(oldinstr, newinstr, feature)                        \
-        ::: "memory" )
+        ALTERNATIVE(oldinstr, newinstr, [feat])                         \
+        :: [feat] "i" (feature) : "memory" )
 
 #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
     asm_inline volatile (                                               \
-        ALTERNATIVE_2(oldinstr, newinstr1, feature1,                    \
-                      newinstr2, feature2)                              \
-        ::: "memory" )
+        ALTERNATIVE_2(oldinstr, newinstr1, [feat1],                     \
+                      newinstr2, [feat2])                               \
+        ::  [feat1] "i" (feature1), [feat2] "i" (feature2) : "memory" )
 
 /*
  * Alternative inline assembly with input.
@@ -148,14 +148,14 @@ extern void alternative_instructions(voi
  */
 #define alternative_input(oldinstr, newinstr, feature, input...)        \
     asm_inline volatile (                                               \
-        ALTERNATIVE(oldinstr, newinstr, feature)                        \
-        :: input )
+        ALTERNATIVE(oldinstr, newinstr, [feat])                         \
+        :: [feat] "i" (feature), ## input  )
 
 /* Like alternative_input, but with a single output argument */
 #define alternative_io(oldinstr, newinstr, feature, output, input...)   \
     asm_inline volatile (                                               \
-        ALTERNATIVE(oldinstr, newinstr, feature)                        \
-        : output : input )
+        ALTERNATIVE(oldinstr, newinstr, [feat])                         \
+        : output : [feat] "i" (feature), ## input )
 
 /*
  * This is similar to alternative_io. But it has two features and
@@ -168,9 +168,9 @@ extern void alternative_instructions(voi
 #define alternative_io_2(oldinstr, newinstr1, feature1, newinstr2,      \
                          feature2, output, input...)                    \
     asm_inline volatile (                                               \
-        ALTERNATIVE_2(oldinstr, newinstr1, feature1,                    \
-                      newinstr2, feature2)                              \
-        : output : input )
+        ALTERNATIVE_2(oldinstr, newinstr1, [feat1],                     \
+                      newinstr2, [feat2])                               \
+        : output : [feat1] "i" (feature1), [feat2] "i" (feature2), ## input )
 
 /* Use this macro(s) if you need more than one output parameter. */
 #define ASM_OUTPUT2(a...) a
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -6,9 +6,16 @@
 /* Number of capability words covered by the featureset words. */
 #define FSCAPINTS FEATURESET_NR_ENTRIES
 
+#if !defined(__ASSEMBLY__) && __GNUC__ >= 15
+#include 
+#define X86_CHECK_FEAT_NR(x, n) BUILD_BUG_ON_ZERO((x) / 32 >= X86_NR_ ## n)
+#else
+#define X86_CHECK_FEAT_NR(x, n) 0
+#endif
+
 /* Synthetic words follow the featureset words. */
 #define X86_NR_SYNTH 2
-#define X86_SYNTH(x) (FSCAPINTS * 32 + (x))
+#define X86_SYNTH(x) (FSCAPINTS * 32 + (x) + X86_CHECK_FEAT_NR(x, SYNTH))
 
 /* Synthetic features */
 XEN_CPUFEATURE(CONSTANT_TSC,      X86_SYNTH( 0)) /* TSC ticks at a constant rate */
@@ -47,7 +54,8 @@ XEN_CPUFEATURE(XEN_REP_MOVSB,     X86_SY
 
 /* Bug words follow the synthetic words. */
 #define X86_NR_BUG 1
-#define X86_BUG(x) ((FSCAPINTS + X86_NR_SYNTH) * 32 + (x))
+#define X86_BUG(x) ((FSCAPINTS + X86_NR_SYNTH) * 32 + (x) + \
+                    X86_CHECK_FEAT_NR(x, BUG))
 
 #define X86_BUG_FPU_PTRS          X86_BUG( 0) /* (F)X{SAVE,RSTOR} doesn't save/restore FOP/FIP/FDP. */
 #define X86_BUG_NULL_SEG          X86_BUG( 1) /* NULL-ing a selector preserves the base and limit. */
--- a/xen/arch/x86/include/asm/cpufeatureset.h
+++ b/xen/arch/x86/include/asm/cpufeatureset.h
@@ -12,8 +12,13 @@ enum {
 };
 #undef XEN_CPUFEATURE
 
+#if __GNUC__ >= 15
+#define XEN_CPUFEATURE(name, value) asm (".equ X86_FEATURE_" #name ", %c0" \
+                                         :: "i" (X86_FEATURE_##name));
+#else
 #define XEN_CPUFEATURE(name, value) asm (".equ X86_FEATURE_" #name ", " \
                                          __stringify(value));
+#endif
 #include 
 #include 
 
--- a/xen/arch/x86/include/asm/pdx.h
+++ b/xen/arch/x86/include/asm/pdx.h
@@ -13,9 +13,9 @@
     asm_inline goto (                               \
         ALTERNATIVE(                                \
             "",                                     \
-            "jmp %l0",                              \
-            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
-        : : : : label )
+            "jmp %l1",                              \
+            [feat])                                 \
+        : : [feat] "i" (ALT_NOT(X86_FEATURE_PDX_COMPRESSION)) : : label )
 
 static inline unsigned long pfn_to_pdx(unsigned long pfn)
 {
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -73,7 +73,7 @@ static always_inline void spec_ctrl_new_
 
     /* (ab)use alternative_input() to specify clobbers. */
     alternative_input("", "DO_OVERWRITE_RSB xu=%=", X86_BUG_IBPB_NO_RET,
-                      : "rax", "rcx");
+                      "i" (0) : "rax", "rcx");
 }
 
 extern int8_t opt_ibpb_ctxt_switch;
@@ -163,7 +163,7 @@ static always_inline void __spec_ctrl_en
      * (ab)use alternative_input() to specify clobbers.
      */
     alternative_input("", "DO_OVERWRITE_RSB xu=%=", X86_FEATURE_SC_RSB_IDLE,
-                      : "rax", "rcx");
+                      "i" (0) : "rax", "rcx");
 }
 
 /* WARNING! `ret`, `call *`, `jmp *` not safe after this call. */
--- a/xen/arch/x86/include/asm/tsc.h
+++ b/xen/arch/x86/include/asm/tsc.h
@@ -29,8 +29,7 @@ static inline uint64_t rdtsc_ordered(voi
     alternative_io_2("lfence; rdtsc",
                      "mfence; rdtsc", X86_FEATURE_MFENCE_RDTSC,
                      "rdtscp",        X86_FEATURE_RDTSCP,
-                     ASM_OUTPUT2("=a" (low), "=d" (high), "=c" (aux)),
-                     /* no inputs */);
+                     ASM_OUTPUT2("=a" (low), "=d" (high), "=c" (aux)));
 
     return (high << 32) | low;
 }



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 10:53:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 10:53:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130388.1469970 (Exim 4.92)
	(envelope-from )
	id 1v1jb8-0007o4-MY; Thu, 25 Sep 2025 10:53:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130388.1469970; Thu, 25 Sep 2025 10: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 1v1jb8-0007nx-Jz; Thu, 25 Sep 2025 10:53:14 +0000
Received: by outflank-mailman (input) for mailman id 1130388;
 Thu, 25 Sep 2025 10:53: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 1v1jb7-0007nr-8t
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 10:53:13 +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 d44ae859-99fd-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 12:53:11 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by PAVPR03MB9631.eurprd03.prod.outlook.com (2603:10a6:102:317::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Thu, 25 Sep
 2025 10:53: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%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 10:53:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d44ae859-99fd-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qgL2nAkDGd3idI6X2w51VmQ/6ypvIVVANDdMkPFvS6AxJnAQA3xh1syJUvCLPvseeVC1qiBj+Ys92Yd5rkhHa7sZqh1yb1tTlSdpXmfS2be5MM0ENGb0gZCWbmdUCEYALrSpvwPr5AgoL17XPyBhbELYfFh9ktJWC8lkipusrWiw5cQF41jcmdnmUbJL6qFS7WasNdo5bMvQOqqYWTUN3rmnS0XfNkXQeK7PLYgqu7srRpCyre0V9FzV+iOZug9BBs09uCxzLwfzIQsJ1CHh5ZQlPAJY8sAG9Uz6VRESabKXCdMmxUFSv47ohB5Ibzh+EarliTHaw4cTJM4zlq52vg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PHW6w3Y14+MLUw7ClYPkkSRiS/Q+Dik2E1sBw58HUGY=;
 b=jbvcYWmgfkeo3MCONbdKT56qY4NvcHfJx0GCeECZptrfXDaiCPmnheGzWgyeF7dFMQuxqkHM50E4Ek/Ed2xjC2JBu/MuyuRuGCOY0N/s0+ijYtnp9Wev3ZqLR9BcxWlfJmirkXWZv14kCEIJ30qCc76SmyMeBzpNmGPBJXHR9avlTJvG6sKexBcBjgwgFdA8m1sRd65J7S7ciNgTS8Ur5+8uFJa2R2VvwPHPr16gzdBvIEVetTbL2rnDMvS5XZqojhBtO3q1Uetm62FmcsB93apfrZBUkYHQcWhKP94zemze2ht8N/GUf04KJe9OcPLi7t1Qq25OnTOy9Dsec8Xm/A==
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=PHW6w3Y14+MLUw7ClYPkkSRiS/Q+Dik2E1sBw58HUGY=;
 b=LXLBz8CfbftxsP9OXmGZmNbNmeawQqwqs2NJS4mcADUEt4SMr6Xk6O4DKPDHHKxv4VYyXehcvfIv4gpGD0pYAQ9g92SipNimVgv1ZFJjcWJgbYnqciSSKUKlj5TI3ArAK2sAQlSrkXQh9WtkgPH1kZgTXZF2vC86spxQCk3zLFkQ26bsgfc52lJVuVtMj5ShQKMPhTa7Vp0Jrcv7bHfS5J9uW+77fRCiaR8lDz+Z2SFZn5agiDHds0kEARORSkawxYgTtU+EK+Xj/6x7qWez92I7U0WNBTToDrtgfcSKqEtQ9JB2J0wTCPuDXeSqCkzfYzpysHhYM0NnPieyMD4+Fg==
From: Oleksii Moisieiev 
To: Grygorii Strashko ,
	"xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Stefano Stabellini ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Topic: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Index: AQHcLWxn561sYuCM3E640/FLnKWxSrSjoRQAgAAZOYA=
Date: Thu, 25 Sep 2025 10:53:08 +0000
Message-ID: <2475e7ad-e9da-491c-80b3-dd39b81d7c1c@epam.com>
References:
 <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
 <2954ab89-cf30-4b00-87c5-37449a571fdd@epam.com>
In-Reply-To: <2954ab89-cf30-4b00-87c5-37449a571fdd@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|PAVPR03MB9631:EE_
x-ms-office365-filtering-correlation-id: 1a127054-59f0-460e-67d7-08ddfc21b6bb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bzRxV1ArTHBJQzFWV3hQamdoMEZ0N2FZM3pnR0VMRlNXN2t4SHV4Q0ZjTzdM?=
 =?utf-8?B?cVVmL085T3FRSnRtdGVqbzFTbXVOQmhsUndXaTZnZDJHbVUyejlIcExhbis5?=
 =?utf-8?B?MnpBVmZvL0MyTythM0krL1Iwak91bEdSV09LYzJwOTNLYW9HcGxtMUJKTHYz?=
 =?utf-8?B?MnIrVlM2Ri9OZEVvNEZFMEtoclI5UGxSM2JsdktpTkxHMXkzN1FWSk9keUp4?=
 =?utf-8?B?Y1hPODhkdkpwSkhNVnBONHpZV0hXaHNxZGhTdTBnaVVhbHZ3OTFCVVdHWjMy?=
 =?utf-8?B?cG1tUjhRcldCU3hSU0c0MUh5ZFFtU3liL2pZRS8vRnJDaEJKRUJ6MXY0czlX?=
 =?utf-8?B?Q1BjcExaZjFZUjMvN0hGZGZDOVVMSTlNdUJCdDJnblBSQU05WjhVZ09HNnNZ?=
 =?utf-8?B?QmV4enlGTnRUM084NjhyWThYMGl5cTBMUkR3RHlhZ1lZZFNZVVc0dmpFY1VV?=
 =?utf-8?B?MkRJTzh2M1VjeEk5T3N0TzVEQlkwRWpNWlFJZjJyN21UMk15TzZEUUNRYVJn?=
 =?utf-8?B?WGJsSCtPOExKMXF6Sm4rYlVBOW1sWFpJOVpNWE1sb01CUDhlSWF6SHZXMkdV?=
 =?utf-8?B?c2txZ3ZwYUJRTktpcDh1a2VpTElKWDNBcURjSUpZSkxFelVMM0htT3doaDRK?=
 =?utf-8?B?NVJ6WGtiVVhjTUlJeWhRUEJ0RWVmd3VYUHY1akRvRmJ6UDRDNDFaUUJEYlla?=
 =?utf-8?B?RDNtQzJzMWNBK3k0Mm9ESTZXbnIvczVMTDgwanJvcU1uTkZ3bjF4UXZvTndv?=
 =?utf-8?B?QnhJWWtOVFhFL0pWQ1VqY2RyZnlYd3VDcXJrSkxyeDhYVEZJZ1RhNUtvU0Zs?=
 =?utf-8?B?UkFIY2UrUnVpRkN1cmI3QU91TGc2SXdNWUVJQXJDMzJzZkJLczk2VlM1aysr?=
 =?utf-8?B?MjZLNDRrNTVYeThGVytQU2tZQWpJd1NmMFVzcVJ3WWZ6eEZZWVhkWEdrN2dZ?=
 =?utf-8?B?V0Y2dUhoMFFXRXo3Zm1jZStYdTc4VWdwbFhDcEM2bE1GT0NQYmtTRzhWS2xB?=
 =?utf-8?B?ZmVWWkdmTk9CN3ZmZmRWNlEyeW5JZkNHQTU4T215QkRTN0dsdTIySTVrc040?=
 =?utf-8?B?N01UcTgxMzA2TUxHTzNIRUxNKytMbmttSWVuV1p4cUdGSTRjZCtzQ3F5cFJk?=
 =?utf-8?B?cEZTcWdvck1FOWRQNG1kVzE3RDFnM3hsOGpDTnZHQ0JjcmFBdkp6eHZ6R2ZH?=
 =?utf-8?B?MUp4bmRoaUdXb2gxbnpCbGhsVDNFb0l6Y0V0ZldZZjZ6L2Vzc1gxcEVBK1RZ?=
 =?utf-8?B?RjdQV1Qzd2RRdFR0M0I2UlZYOG5iOG9qU1NKc2NzL3FORDBOcFQrVUlXWlp0?=
 =?utf-8?B?cmdXQUdRWFQ2d2lwdG5iQldOUFJmOE1ZOXBUbllxc0JjNURPK0NyNFJVTmFj?=
 =?utf-8?B?NGxOUkh4WmsyZ1g2OE52bXphcXNxeUNtMk03V3I0dHpTR0FPeU12dThnZElB?=
 =?utf-8?B?QWkydnJnK2QvekEzR3NlSjRIOXNZQ1Z6VWU1YlBhek55WGhxYlJnRnZpOG1G?=
 =?utf-8?B?b2pQeVZXNVM3UVVJTFdPRGp0QkpBbll4M2U3emhobEZNZ0p1U3gxdTM5NFpk?=
 =?utf-8?B?elZBWWtTUHFPeUlXU2tWZU1pNldtVUFlTTQzK0xObXVhbmJ4bXQwVjZIL1RQ?=
 =?utf-8?B?aW4rNWs1a0pIL1lmeDY2dCsrVkNneitVSTFJcDZsTHBXL1F0VEYxa2cwR0JN?=
 =?utf-8?B?OU9jdEhOZHJnMTBWWGdpTWV2eGsvRmlWK0hEV3VzeE53LzFtODVIK1hEVW9Z?=
 =?utf-8?B?T25KY3JkSi9wcmY3SCt5cmFKRDNESFBDUW9idFNiSnpTSERvSFVldDRhZWxq?=
 =?utf-8?B?NUU5RjV3Rk15S00wR2lQcm14OFdNWlFscld3cFI1Q0VuK3dEd1Z5Ynp1Wnh1?=
 =?utf-8?B?c2tscHlNQ1IrY1Q2S0E5N0hEelZiV3RIcGMrOEpYVDd4QzNlZ0wrVStEVktG?=
 =?utf-8?B?V1hoVG45ZXF6a0xxa1ozSTlzVzJtL1BwbllWZFptK1lIc3M1TTUzYnFtNzFV?=
 =?utf-8?Q?TbUZNJao93pBa3ismRSAVQ83lDB7+I=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)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?ZmZDTm9ENitWRDBLRHBLRmhTdlF2QW5lR2hPWCtBa1NleVovNm9TeGI4NVF0?=
 =?utf-8?B?TEozY3d0dU01VkFlTXBkdC9ubEk4d29aZ0NDWFhjRHpCcTBheVJrOGplMTVZ?=
 =?utf-8?B?bE0yendkL1BUdllTTmRvNE81bnBRL2R4VXNuQ3pDbzhGVmJmRUx1RE9DczU3?=
 =?utf-8?B?ZWZWb3FqNXJRMDZPcVBaU1JtY2hpZ2ExS3JheG9vVkIxM2NlWE9VdUxOdmRZ?=
 =?utf-8?B?cDlDcG93L3FHQyswdnVoVjBZSG1BWHBna1dCM0pmb3diQ3NNdUVUbmp4dkkr?=
 =?utf-8?B?ZURkb1ZkcVM5RXR6eHpKOTdRRHF4R2Z5NE9MTmEzNkNGbjVwRjJ5dGNQeEVs?=
 =?utf-8?B?UkF1SVhReDcrazJyYzhqRFJ1QjRTYlB5OWpIa3BJY2lSaGlHN2tIRGtBZTZn?=
 =?utf-8?B?NVd6QlEveENSbTB5dERaT3ZnZWltdURKVERXa3hMQVBzbm1ybm13UkZPenpV?=
 =?utf-8?B?amMwWUQyS0ltaXl5dU1abnluaFQzOHMyK3NjQlVDaTJFV3h5ZzROL1JQci9v?=
 =?utf-8?B?TTFLU25Mc2xTdHhHOHRSYVJBc1RhQllNOGl1azN1NEM5OUtGbjEwYWJ4dDNF?=
 =?utf-8?B?ak5aOG9tKzhvRUlHWEYzbG1JcnBqYjArVlZySi94QjBac2ZZaGVLWVcxUnZ6?=
 =?utf-8?B?cVFENjBXaHN2Q1NWYkFaa0I1SFg2dTd6dmhIdTdoNFRGeTArcWs0TEp1UElD?=
 =?utf-8?B?UGRGZkxpMjVzUXNYNDVXeEJTbWxEcFF5L05LOE1xdXQzSUFUV3ZNeEk1U01D?=
 =?utf-8?B?NWU3QytGY01YWk5oZFVpTmZmWEs0cnhlMVM5aTluTE8xU1RzNU81Zys3WmZn?=
 =?utf-8?B?V0ttc2hod2dMTHdFZkJpMG9odmZYSTJQUEw3QVNRZW5McUI1MHc0eDJna0Jw?=
 =?utf-8?B?NnA4dHlVYmZBRkZCMEwwNFhkckYraVdVZWFsLzRRRC9PTEw2L2tvejdyek5E?=
 =?utf-8?B?MUc5d1pVVUVZcHBNMDVWQzhBWU9ldlZWUmE1L3lPL04rdEFnUEV5VnRQQzlv?=
 =?utf-8?B?Z2IzZjRia0phbitIZFNUZWxXYlNVSDRwNGlwTjZEamhTRUR2dDdQTFk4blFB?=
 =?utf-8?B?c05yem8zZkxPZTBHdGRjZ3FKcFEzbmdiN1lzMlI1dk55WkkxbjBMQVZrVm5a?=
 =?utf-8?B?THlBQWI5WjNiNTZmUlRNQUxTNXU0a2haNTZlZFROdktLWjdIK1hPbDhuZENo?=
 =?utf-8?B?Yy80YWxUNU5kTGtmRUNNZTliREk1YkZHQmR5Q2RhUXplS2xuaHpBQWJ4UFFV?=
 =?utf-8?B?MWtRQUpuUFFGbnUrU0FrNTdHZlc3VTU5eFFsa2VEdERsZjZiMkE2Q1ROdWJP?=
 =?utf-8?B?U2JwclBIQVdUMmFxTXA0RWZ3dzNPeE5YbjNLWkFMUUQ2d3BXRmhoRkJ1YTdt?=
 =?utf-8?B?SjNXTFllRlJSTzR0Z21ZZEd0eG1LdmYveTRGOVVFa0FlWS9lNmZDMVVteU9D?=
 =?utf-8?B?cG92TTR3TjBRcVhlQjAvc3h0RjBWa3p6cHdpbC9Qc1ZZTFQ3bE9SeXkrQTc3?=
 =?utf-8?B?MlNodkVJMTNjZlArTzk3Smt4a1NLSlhqYXFjaSt4R2h6U05zcTM1ZkZhQnV5?=
 =?utf-8?B?QjVtcVdMSUpDeUlDZHFmbVRtUXZJb3YzZTBTcHdVUFZHWnlHVTJEdnVvN0NQ?=
 =?utf-8?B?WXhDS0xBYlNRT05mdENHMGVZbGlxOFJLbldQc25NRzZkcng1YUxMMXJIMEFv?=
 =?utf-8?B?Y1ZpNFBVNUp5REdCb080ek42RGl4L1BLZzc5VnBOaXpmSnlFMFNPNmZLV1VX?=
 =?utf-8?B?SHorOFNIRk9YNU8xY3BsRGxlVEZTdFYrQktiUThJa3ZSam1PMkxJZkVEd0gx?=
 =?utf-8?B?dytGdVh4d01GMkVhVUEySFowMHp3Z2hzb05mdllOUHRzR0x3aklzYklEZUZJ?=
 =?utf-8?B?Z1lKL2pzdlRjZjNVNTBtejNseDBuM3QyTDVSdW5IVlllZ3RpaW5JcXhBVWhv?=
 =?utf-8?B?YmhKZHFvVGpQQnBUVkNjQnphaDAzVzhBVXFNS29UTTJpUFJSdVVSMy80bzVQ?=
 =?utf-8?B?UVJNZWQ0S3RnQ284VElmSkNxNElpajJ6ODl1TUNYNVRiNENpVHRjd0wwYVpU?=
 =?utf-8?B?T1VGaUNIVUR4a2NrdGs3TmJ6NGpBcnpaa2tSd2gwQ2RsWHA5S0ZEeVNCT1J0?=
 =?utf-8?B?NUgwTlRqKzdFdE1qcVQ5cXRvL2NZRGpVN3R3c2VnRitrSHhvak1pNkhCd08v?=
 =?utf-8?B?YWc9PQ==?=
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: 1a127054-59f0-460e-67d7-08ddfc21b6bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 10:53:08.5959
 (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: AGJzDjwtbqheIHEnZHlHnYIhRimlN1QxOyudKZskXZT1QD6D5xhAb9lYRbZx4cAQUFp/c5S0Mjb0/q4RJKFECVFCW4YrxHXZfWTf+y/aNB0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9631

DQoNCk9uIDI1LzA5LzIwMjUgMTI6MjIsIEdyeWdvcmlpIFN0cmFzaGtvIHdyb3RlOg0KPg0KPg0K
PiBPbiAyNC4wOS4yNSAxOTowMCwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBUaGlzIGNv
bW1pdCBpbnRyb2R1Y2VzIGEgbmV3IEtjb25maWcgb3B0aW9uLCBgQ09ORklHX0RPTTBfQk9PVGAs
IHRvDQo+PiBhbGxvdyBmb3IgYnVpbGRpbmcgWGVuIHdpdGhvdXQgc3VwcG9ydCBmb3IgYm9vdGlu
ZyBhIHJlZ3VsYXIgZG9tYWluIA0KPj4gKERvbTApLg0KPj4gVGhpcyBmdW5jdGlvbmFsaXR5IGlz
IHByaW1hcmlseSBpbnRlbmRlZCBmb3IgdGhlIEFSTSBhcmNoaXRlY3R1cmUuDQo+Pg0KPj4gQSBu
ZXcgS2NvbmZpZyBzeW1ib2wsIGBIQVNfRE9NMGAsIGhhcyBiZWVuIGFkZGVkIGFuZCBpcyBzZWxl
Y3RlZCBieQ0KPj4gZGVmYXVsdCBmb3IgQVJNIGFuZCBYODYgYXJjaGl0ZWN0dXJlLiBUaGlzIHN5
bWJvbCBzaWduaWZpZXMgdGhhdCBhbg0KPj4gYXJjaGl0ZWN0dXJlIGhhcyB0aGUgY2FwYWJpbGl0
eSB0byBzdXBwb3J0IGEgRG9tMC4NCj4+DQo+PiBUaGUgYERPTTBfQk9PVGAgb3B0aW9uIGRlcGVu
ZHMgb24gYEhBU19ET00wYCBhbmQgZGVmYXVsdHMgdG8gJ3knLiBGb3INCj4+IGV4cGVydCB1c2Vy
cywgdGhpcyBvcHRpb24gY2FuIGJlIGRpc2FibGVkIChgQ09ORklHX0VYUEVSVD15YCBhbmQgbm8N
Cj4+IGBDT05GSUdfRE9NMF9CT09UYCBpbiB0aGUgY29uZmlnKSwgd2hpY2ggd2lsbCBjb21waWxl
IG91dCB0aGUgRG9tMA0KPj4gY3JlYXRpb24gY29kZSBvbiBBUk0uIFRoaXMgaXMgdXNlZnVsIGZv
ciBlbWJlZGRlZCBvciBkb20wbGVzcy1vbmx5DQo+PiBzY2VuYXJpb3MgdG8gcmVkdWNlIGJpbmFy
eSBzaXplIGFuZCBjb21wbGV4aXR5Lg0KPj4NCj4+IFRoZSBBUk0gYm9vdCBwYXRoIGhhcyBiZWVu
IHVwZGF0ZWQgdG8gcGFuaWMgaWYgaXQgZGV0ZWN0cyBhIG5vbi1kb20wbGVzcw0KPj4gY29uZmln
dXJhdGlvbiB3aGlsZSBgQ09ORklHX0RPTTBfQk9PVGAgaXMgZGlzYWJsZWQsIHByZXZlbnRpbmcg
YW4gDQo+PiBpbnZhbGlkDQo+PiBib290Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IE9sZWtzaWkg
TW9pc2llaWV2IDxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+DQo+PiAtLS0NCj4+DQo+
PiBDaGFuZ2VzIGluIHYzOg0KPj4gLSByZXBocmFzZSBlcnJvciBtZXNzYWdlIHdoZW4gZG9tMGxl
c3MgbW9kZSB3YXNuJ3QgZGV0ZWN0ZWQgd2hpbGUgZG9tMA0KPj4gaXMgZGlzYWJsZWQuDQo+PiAt
IHJlcGhyYXNlIGhlbHAgbWVzc2FnZSBmb3IgRE9NMF9CT09UIGNvbmZpZyBvcHRpb24NCj4+IC0g
dXBkYXRlIERPTTBfQk9PVCBkZXBlbmRlbmNpZXMgZm9yIFg4Ng0KPj4NCj4+IENoYW5nZXMgaW4g
djI6DQo+PiAtIGRlY2lkZWQgbm90IHRvIHJlbmFtZSBIQVNfRE9NMCAoSEFTX09QVElPTkFMX0RP
TTAgd2FzIGFub3RoZXIgb3B0aW9uDQo+PiBzdWdnZXN0ZWQgaW4gTUwpIGJlY2F1c2UgaW4gdGhp
cyBjYXNlIEhBU19ET00wTEVTUyBzaG91bGQgYmUgcmVuYW1lZA0KPj4gZWl0aGVyLg0KPj4gLSBm
aXggb3JkZXIgb2YgSEFTX0RPTTAgY29uZmlnIHBhcmFtZXRlcg0KPj4gLSBhZGQgSEFTX0RPTTAg
b3B0aW9uIHRvIHg4NiBhcmNoaXRlY3R1cmUuDQo+Pg0KPj4gQ09ORklHX0RPTTBfQk9PVCBLY29u
ZmlnIG9wdGlvbiB3YXMgaW50cm9kdWNlZCB0byBtYWtlIHRoZSBEb20wDQo+PiByZWd1bGFyIChs
ZWdhY3kpIGRvbWFpbiBhbiBvcHRpb25hbCBmZWF0dXJlIHRoYXQgY2FuIGJlIGNvbXBpbGVkIG91
dA0KPj4gZnJvbSB0aGUgWGVuIGh5cGVydmlzb3IgYnVpbGQuDQo+Pg0KPj4gVGhlIHByaW1hcnkg
bW90aXZhdGlvbiBmb3IgdGhpcyBjaGFuZ2UgaXMgdG8gZW5oYW5jZSBtb2R1bGFyaXR5IGFuZA0K
Pj4gcHJvZHVjZSBhIGNsZWFuZXIsIG1vcmUgc3BlY2lhbGl6ZWQgaHlwZXJ2aXNvciBiaW5hcnkg
d2hlbiBhIGNvbnRyb2wNCj4+IGRvbWFpbiBpcyBub3QgbmVlZGVkLiBJbiBtYW55IGVtYmVkZGVk
IG9yIGRlZGljYXRlZCBzeXN0ZW1zLCBYZW4gaXMNCj4+IHVzZWQgaW4gYSAiZG9tMGxlc3MiIGNv
bmZpZ3VyYXRpb24gd2hlcmUgZ3Vlc3RzIGFyZSBwcmUtY29uZmlndXJlZCBhbmQNCj4+IGxhdW5j
aGVkIGRpcmVjdGx5IGJ5IHRoZSBoeXBlcnZpc29yLiBJbiB0aGVzZSBzY2VuYXJpb3MsIHRoZSBl
bnRpcmUNCj4+IHN1YnN5c3RlbSBmb3IgYm9vdGluZyBhbmQgbWFuYWdpbmcgRG9tMCBpcyB1bm5l
Y2Vzc2FyeS4NCj4+DQo+PiBUaGlzIGFwcHJvYWNoIGFsaWducyB3aXRoIHNvZnR3YXJlIHF1YWxp
dHkgc3RhbmRhcmRzIGxpa2UgTUlTUkEgQywNCj4+IHdoaWNoIGFkdm9jYXRlIGZvciB0aGUgcmVt
b3ZhbCBvZiB1bnJlYWNoYWJsZSBvciB1bm5lY2Vzc2FyeSBjb2RlIHRvDQo+PiBpbXByb3ZlIHNh
ZmV0eSBhbmQgbWFpbnRhaW5hYmlsaXR5LiBTcGVjaWZpY2FsbHksIHRoaXMgY2hhbmdlIGhlbHBz
IA0KPj4gYWRoZXJlIHRvOg0KPj4NCj4+IE1JU1JBIEM6MjAxMiwgUnVsZSAyLjI6ICJUaGVyZSBz
aGFsbCBiZSBubyBkZWFkIGNvZGUiDQo+Pg0KPj4gSW4gYSBidWlsZCBjb25maWd1cmVkIGZvciBh
IGRvbTBsZXNzIGVudmlyb25tZW50LCB0aGUgY29kZSByZXNwb25zaWJsZQ0KPj4gZm9yIGNyZWF0
aW5nIERvbTAgd291bGQgYmUgY29uc2lkZXJlZCAiZGVhZCBjb2RlIiBhcyBpdCB3b3VsZCBuZXZl
ciBiZQ0KPj4gZXhlY3V0ZWQuIEJ5IHVzaW5nIHRoZSBwcmVwcm9jZXNzb3IgdG8gcmVtb3ZlIGl0
IGJlZm9yZSBjb21waWxhdGlvbiwNCj4+IHdlIGVuc3VyZSB0aGF0IHRoZSBmaW5hbCBleGVjdXRh
YmxlIGlzIGZyZWUgZnJvbSB0aGlzIHVucmVhY2hhYmxlDQo+PiBjb2RlLiBUaGlzIHNpbXBsaWZp
ZXMgc3RhdGljIGFuYWx5c2lzLCByZWR1Y2VzIHRoZSBhdHRhY2sgc3VyZmFjZSwNCj4+IGFuZCBt
YWtlcyB0aGUgY29kZWJhc2UgZWFzaWVyIHRvIHZlcmlmeSwgd2hpY2ggaXMgY3JpdGljYWwgZm9y
DQo+PiBzeXN0ZW1zIHJlcXVpcmluZyBoaWdoIGxldmVscyBvZiBzYWZldHkgYW5kIHNlY3VyaXR5
Lg0KPj4NCj4+IC0tLQ0KPj4gwqAgeGVuL2FyY2gvYXJtL0tjb25maWfCoMKgwqDCoMKgwqDCoCB8
wqAgMSArDQo+PiDCoCB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgfMKgIDggKysrKysrKysN
Cj4+IMKgIHhlbi9hcmNoL2FybS9zZXR1cC5jwqDCoMKgwqDCoMKgwqAgfCAxNCArKysrKysrKysr
LS0tLQ0KPj4gwqAgeGVuL2FyY2gveDg2L0tjb25maWfCoMKgwqDCoMKgwqDCoCB8wqAgMSArDQo+
PiDCoCB4ZW4vY29tbW9uL0tjb25maWfCoMKgwqDCoMKgwqDCoMKgwqAgfCAxMSArKysrKysrKysr
Kw0KPj4gwqAgNSBmaWxlcyBjaGFuZ2VkLCAzMSBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygt
KQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vS2NvbmZpZyBiL3hlbi9hcmNoL2Fy
bS9LY29uZmlnDQo+PiBpbmRleCBjZjZhZjY4Mjk5Li4zMzZiMmVkMjQyIDEwMDY0NA0KPj4gLS0t
IGEveGVuL2FyY2gvYXJtL0tjb25maWcNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9LY29uZmlnDQo+
PiBAQCAtMTcsNiArMTcsNyBAQCBjb25maWcgQVJNDQo+PiDCoMKgwqDCoMKgIHNlbGVjdCBHRU5F
UklDX1VBUlRfSU5JVA0KPj4gwqDCoMKgwqDCoCBzZWxlY3QgSEFTX0FMVEVSTkFUSVZFIGlmIEhB
U19WTUFQDQo+PiDCoMKgwqDCoMKgIHNlbGVjdCBIQVNfREVWSUNFX1RSRUVfRElTQ09WRVJZDQo+
PiArwqDCoMKgIHNlbGVjdCBIQVNfRE9NMA0KPg0KPiBIZXJlIEhBU19ET00wIGlzIHNlbGVjdGVk
IGFuZCBhbGwgZGVwZW5kZW5jaWVzIGFsc28gc2VsZWN0ZWQgKCANCj4gSEFTX0RFVklDRV9UUkVF
X0RJU0NPVkVSWSwgRE9NQUlOX0JVSUxEX0hFTFBFUlMpDQo+DQo+PiDCoMKgwqDCoMKgIHNlbGVj
dCBIQVNfRE9NMExFU1MNCj4+IMKgwqDCoMKgwqAgc2VsZWN0IEhBU19HUkFOVF9DQUNIRV9GTFVT
SCBpZiBHUkFOVF9UQUJMRQ0KPj4gwqDCoMKgwqDCoCBzZWxlY3QgSEFTX1NUQUNLX1BST1RFQ1RP
Ug0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyBiL3hlbi9hcmNo
L2FybS9kb21haW5fYnVpbGQuYw0KPj4gaW5kZXggZmI4ZmJiMTY1MC4uNjI2MDJhZmM3OCAxMDA2
NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gKysrIGIveGVuL2Fy
Y2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiBAQCAtNDIsOCArNDIsMTAgQEANCj4+IMKgICNpbmNs
dWRlIDxhc20vZ3JhbnRfdGFibGUuaD4NCj4+IMKgICNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+DQo+
PiDCoCArI2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+IMKgIHN0YXRpYyB1bnNpZ25lZCBpbnQg
X19pbml0ZGF0YSBvcHRfZG9tMF9tYXhfdmNwdXM7DQo+PiDCoCBpbnRlZ2VyX3BhcmFtKCJkb20w
X21heF92Y3B1cyIsIG9wdF9kb20wX21heF92Y3B1cyk7DQo+PiArI2VuZGlmDQo+PiDCoCDCoCAv
Kg0KPj4gwqDCoCAqIElmIHRydWUsIHRoZSBleHRlbmRlZCByZWdpb25zIHN1cHBvcnQgaXMgZW5h
YmxlZCBmb3IgZG9tMCBhbmQNCj4+IEBAIC0xMDQsNiArMTA2LDcgQEAgaW50IF9faW5pdCBwYXJz
ZV9hcmNoX2RvbTBfcGFyYW0oY29uc3QgY2hhciAqcywgDQo+PiBjb25zdCBjaGFyICplKQ0KPj4g
wqDCoCAqLw0KPj4gwqAgI2RlZmluZSBET00wX0ZEVF9FWFRSQV9TSVpFICgxMjggKyBzaXplb2Yo
c3RydWN0IGZkdF9yZXNlcnZlX2VudHJ5KSkNCj4+IMKgICsjaWZkZWYgQ09ORklHX0RPTTBfQk9P
VA0KPj4gwqAgdW5zaWduZWQgaW50IF9faW5pdCBkb20wX21heF92Y3B1cyh2b2lkKQ0KPj4gwqAg
ew0KPj4gwqDCoMKgwqDCoCBpZiAoIG9wdF9kb20wX21heF92Y3B1cyA9PSAwICkNCj4+IEBAIC0x
MTYsNiArMTE5LDcgQEAgdW5zaWduZWQgaW50IF9faW5pdCBkb20wX21heF92Y3B1cyh2b2lkKQ0K
Pj4gwqAgwqDCoMKgwqDCoCByZXR1cm4gb3B0X2RvbTBfbWF4X3ZjcHVzOw0KPj4gwqAgfQ0KPj4g
KyNlbmRpZg0KPj4gwqAgwqAgLyoNCj4+IMKgwqAgKiBJbnNlcnQgdGhlIGdpdmVuIHBhZ2VzIGlu
dG8gYSBtZW1vcnkgYmFuaywgYmFua3MgYXJlIG9yZGVyZWQgYnkgDQo+PiBhZGRyZXNzLg0KPj4g
QEAgLTE5NjIsNiArMTk2Niw3IEBAIGludCBfX2luaXQgY29uc3RydWN0X2RvbWFpbihzdHJ1Y3Qg
ZG9tYWluICpkLCANCj4+IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQo+PiDCoMKgwqDCoMKg
IHJldHVybiAwOw0KPj4gwqAgfQ0KPj4gwqAgKyNpZmRlZiBDT05GSUdfRE9NMF9CT09UDQo+PiDC
oCBzdGF0aWMgaW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMChzdHJ1Y3QgZG9tYWluICpkKQ0KPj4g
wqAgew0KPj4gwqDCoMKgwqDCoCBzdHJ1Y3Qga2VybmVsX2luZm8ga2luZm8gPSBLRVJORUxfSU5G
T19JTklUOw0KPj4gQEAgLTE5OTMsNiArMTk5OCw3IEBAIHN0YXRpYyBpbnQgX19pbml0IGNvbnN0
cnVjdF9kb20wKHN0cnVjdCBkb21haW4gKmQpDQo+PiDCoCDCoMKgwqDCoMKgIHJldHVybiBjb25z
dHJ1Y3RfaHdkb20oJmtpbmZvLCBOVUxMKTsNCj4+IMKgIH0NCj4+ICsjZW5kaWYNCj4+IMKgIMKg
IGludCBfX2luaXQgY29uc3RydWN0X2h3ZG9tKHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+
PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpDQo+PiBAQCAtMjA0Niw2ICsyMDUy
LDcgQEAgaW50IF9faW5pdCBjb25zdHJ1Y3RfaHdkb20oc3RydWN0IGtlcm5lbF9pbmZvIA0KPj4g
KmtpbmZvLA0KPj4gwqDCoMKgwqDCoCByZXR1cm4gY29uc3RydWN0X2RvbWFpbihkLCBraW5mbyk7
DQo+PiDCoCB9DQo+PiDCoCArI2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+IMKgIHZvaWQgX19p
bml0IGNyZWF0ZV9kb20wKHZvaWQpDQo+PiDCoCB7DQo+PiDCoMKgwqDCoMKgIHN0cnVjdCBkb21h
aW4gKmRvbTA7DQo+PiBAQCAtMjEwMyw2ICsyMTEwLDcgQEAgdm9pZCBfX2luaXQgY3JlYXRlX2Rv
bTAodm9pZCkNCj4+IMKgIMKgwqDCoMKgwqAgc2V0X3hzX2RvbWFpbihkb20wKTsNCj4+IMKgIH0N
Cj4+ICsjZW5kaWYgLyogQ09ORklHX0RPTTBfQk9PVCAqLw0KPj4gwqAgwqAgLyoNCj4+IMKgwqAg
KiBMb2NhbCB2YXJpYWJsZXM6DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3NldHVwLmMg
Yi94ZW4vYXJjaC9hcm0vc2V0dXAuYw0KPj4gaW5kZXggN2FkODcwZTM4Mi4uZmJiMjkwZGY2MCAx
MDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+PiArKysgYi94ZW4vYXJjaC9h
cm0vc2V0dXAuYw0KPj4gQEAgLTQ4MSwxMiArNDgxLDE4IEBAIHZvaWQgYXNtbGlua2FnZSBfX2lu
aXQgbm9yZXR1cm4gDQo+PiBzdGFydF94ZW4odW5zaWduZWQgbG9uZyBmZHRfcGFkZHIpDQo+PiDC
oMKgwqDCoMKgIGVuYWJsZV9lcnJhdGFfd29ya2Fyb3VuZHMoKTsNCj4+IMKgwqDCoMKgwqAgZW5h
YmxlX2NwdV9mZWF0dXJlcygpOw0KPj4gwqAgLcKgwqDCoCAvKiBDcmVhdGUgaW5pdGlhbCBkb21h
aW4gMC4gKi8NCj4+IC3CoMKgwqAgaWYgKCAhaXNfZG9tMGxlc3NfbW9kZSgpICkNCj4+ICvCoMKg
wqAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19ET00wX0JPT1QpICYmICFpc19kb20wbGVzc19tb2Rl
KCkgKQ0KPj4gK8KgwqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgLyogQ3JlYXRlIGluaXRpYWwg
ZG9tYWluIDAuICovDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgY3JlYXRlX2RvbTAoKTsNCj4+ICvC
oMKgwqAgfQ0KPj4gwqDCoMKgwqDCoCBlbHNlDQo+PiAtwqDCoMKgwqDCoMKgwqAgcHJpbnRrKFhF
TkxPR19JTkZPICJYZW4gZG9tMGxlc3MgbW9kZSBkZXRlY3RlZFxuIik7DQo+PiAtDQo+PiArwqDC
oMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIGlzX2RvbTBsZXNzX21vZGUoKSkNCj4+ICvC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHByaW50ayhYRU5MT0dfSU5GTyAiWGVuIGRvbTBsZXNzIG1v
ZGUgZGV0ZWN0ZWRcbiIpOw0KPj4gK8KgwqDCoMKgwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHBhbmljKCJOZWl0aGVyIGRvbTAgbm9yIGRvbTBsZXNzIG1vZGUgd2FzIGRl
dGVjdGVkLCANCj4+IGFib3J0aW5nXG4iKTsNCj4+ICvCoMKgwqAgfQ0KPj4gwqDCoMKgwqDCoCBp
ZiAoIGFjcGlfZGlzYWJsZWQgKQ0KPj4gwqDCoMKgwqDCoCB7DQo+PiDCoMKgwqDCoMKgwqDCoMKg
wqAgY3JlYXRlX2RvbVVzKCk7DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L0tjb25maWcg
Yi94ZW4vYXJjaC94ODYvS2NvbmZpZw0KPj4gaW5kZXggM2YwZjNhMGYzYS4uMmFlYjM2MWM2MyAx
MDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnDQo+PiArKysgYi94ZW4vYXJjaC94
ODYvS2NvbmZpZw0KPj4gQEAgLTE4LDYgKzE4LDcgQEAgY29uZmlnIFg4Ng0KPj4gwqDCoMKgwqDC
oCBzZWxlY3QgSEFTX0NPTVBBVA0KPj4gwqDCoMKgwqDCoCBzZWxlY3QgSEFTX0NQVUZSRVENCj4+
IMKgwqDCoMKgwqAgc2VsZWN0IEhBU19ESVQNCj4+ICvCoMKgwqAgc2VsZWN0IEhBU19ET00wDQo+
PiDCoMKgwqDCoMKgIHNlbGVjdCBIQVNfRUhDSQ0KPj4gwqDCoMKgwqDCoCBzZWxlY3QgSEFTX0VY
X1RBQkxFDQo+PiDCoMKgwqDCoMKgIHNlbGVjdCBIQVNfRkFTVF9NVUxUSVBMWQ0KPj4gZGlmZiAt
LWdpdCBhL3hlbi9jb21tb24vS2NvbmZpZyBiL3hlbi9jb21tb24vS2NvbmZpZw0KPj4gaW5kZXgg
NzZmOWNlNzA1Zi4uMTBhOGZjODcxOCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9jb21tb24vS2NvbmZp
Zw0KPj4gKysrIGIveGVuL2NvbW1vbi9LY29uZmlnDQo+PiBAQCAtMjYsNiArMjYsMTQgQEAgY29u
ZmlnIERPTTBMRVNTX0JPT1QNCj4+IMKgwqDCoMKgwqDCoMKgIFhlbiBib290IHdpdGhvdXQgdGhl
IG5lZWQgb2YgYSBjb250cm9sIGRvbWFpbiAoRG9tMCksIHdoaWNoIA0KPj4gY291bGQgYmUNCj4+
IMKgwqDCoMKgwqDCoMKgIHByZXNlbnQgYW55d2F5Lg0KPj4gwqAgK2NvbmZpZyBET00wX0JPT1QN
Cj4+ICvCoMKgwqAgYm9vbCAiRG9tMCBib290IHN1cHBvcnQiIGlmIEVYUEVSVA0KPj4gK8KgwqDC
oCBkZWZhdWx0IHkNCj4+ICvCoMKgwqAgZGVwZW5kcyBvbiAoQVJNICYmIEhBU19ET00wICYmIEhB
U19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkgJiYgDQo+PiBET01BSU5fQlVJTERfSEVMUEVSUykgfHwg
KFg4NiAmJiBIQVNfRE9NMCkNCj4NCj4gSGVyZSB5b3UgcmVwZWF0IHRoZSBzYW1lIGRlcGVuZGVu
Y2llcy4gSW4gZ2VuZXJhbCwgaWYgeW91IGludHJvZHVjZSANCj4gSEFTX0RPTTAsDQo+IHdoaWNo
IGlzIGV4cGVjdGVkIHRvIGJlIHNlbGVjdGVkIGJ5IEFSQ0gsIHRoZW4gYWxsIHlvdSBuZWVkIGlz
DQo+DQo+IMKgwqDCoMKgZGVwZW5kcyBvbiBIQVNfRE9NMA0KPg0KPiBJdCdzIEFSQ0ggZGVjaXNp
b24gdG8gc2VsZWN0IEhBU19ET00wLCBvciBub3QuDQo+DQo+PiArwqDCoMKgIGhlbHANCj4+ICvC
oMKgwqDCoMKgIERvbTAgYm9vdCBzdXBwb3J0IGVuYWJsZXMgWGVuIHRvIGJvb3QgdG8gdGhlIGFs
bC1wb3dlcmZ1bCANCj4+IGRvbWFpbiAoRG9tMCkuDQo+PiArwqDCoMKgwqDCoCBJZiB0aGlzIGlz
bid0IGVuYWJsZWQgWGVuIGlzIGV4cGVjdGVkIHRvIGJvb3QgaW4gZG9tMGxlc3MgbW9kZSANCj4+
IG9ubHkuDQo+DQo+ICJpcyBleHBlY3RlZCB0byBib290IGFuZCBsYXVuY2hpbmcgYWxsIGRvbWFp
bnMgaW4gZG9tMGxlc3MvSHlwZXJsYXVuY2ggDQo+IG1vZGUgb25seS4iPw0KPg0KVGhhbmtzIGZv
ciB0aGUgcmV2aWV3LiBIeXBlcmxhdWNoIGlzIG5vdCBtZXJnZWQgcmlnaHQgbm93IHNvIEkgZG9u
J3QgDQp0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIGludHJvZHVjZSBuZXcgdGVybS4NCkFncmVl
IHdpdGggb3RoZXIgc3RhdGVtZXRzIGFib3ZlLg0KPj4gKw0KPj4gwqAgY29uZmlnIERPTUFJTl9C
VUlMRF9IRUxQRVJTDQo+PiDCoMKgwqDCoMKgIGJvb2wNCj4+IMKgIEBAIC0xMjUsNiArMTMzLDkg
QEAgY29uZmlnIEhBU19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkNCj4+IMKgwqDCoMKgwqAgYm9vbA0K
Pj4gwqDCoMKgwqDCoCBzZWxlY3QgREVWSUNFX1RSRUVfUEFSU0UNCj4+IMKgICtjb25maWcgSEFT
X0RPTTANCj4+ICvCoMKgwqAgYm9vbA0KPj4gKw0KPj4gwqAgY29uZmlnIEhBU19ET00wTEVTUw0K
Pj4gwqDCoMKgwqDCoCBib29sDQo+DQo=


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 10:59:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 10:59:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130405.1469981 (Exim 4.92)
	(envelope-from )
	id 1v1jgp-00007z-AQ; Thu, 25 Sep 2025 10:59:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130405.1469981; Thu, 25 Sep 2025 10: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 1v1jgp-00007s-7D; Thu, 25 Sep 2025 10:59:07 +0000
Received: by outflank-mailman (input) for mailman id 1130405;
 Thu, 25 Sep 2025 10:59:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1jgo-00007m-8r
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 10:59:06 +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 a41216ac-99fe-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 12:59:00 +0200 (CEST)
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com (2603:10a6:102:322::9)
 by PR3PR03MB6410.eurprd03.prod.outlook.com (2603:10a6:102:7c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 10:58:58 +0000
Received: from PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd]) by PAVPR03MB8921.eurprd03.prod.outlook.com
 ([fe80::1fbe:d673:80a7:6ebd%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 10:58: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: a41216ac-99fe-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rLp+runs/gsYFEWsb1gw7aBQ22VZ3JsrMbLL9V6SGL/LhVUJScH15mNizXq9wN4Bf2cjYlqdnPp+mLPjg1reFf1umk6ezilHVDK3sqsRTB2cZWIacePyHKkYtTGUmbiqzXqJcTw/3pyhatKPwziBjpLyWHtfSlvuRR3/XidsOL5XMBzDp1R51YH9regIDHJ8jfR41TJBgARJ9aYXtrLy1LWM+8Tb9Xx1Z8EqESc8lOeG6RCWCvU66oHdaxfJ+fSN1JCrPxq1H74AibQsd/9IUhfjYD2YR+90y7fulOnvFoimlIoo790pM7frgsSUKLRzgfZoMTLGGOj9w/oBjSQ4Cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xp+sKjvwtCRLj0REPVNn5U0LAcgr2vdjnzREMqTFThI=;
 b=x3pHqxjVfQjcb4majXX5QpG8160jgckWkGDUQ+1DlRsV66TC/oi9paePD45FyIJ/YFi1UJpaaS+GfAFaBK/I/q/8iu2k1Spu6eq7tRHwte4eJyOhwyT+B2f1lTfY4cGg3iiUcdqKUZcB/nEeZUsTtgx9oM+F5fBrCEI78JPpeeG/ph7HNE4rJNQpvr/XmReXBOXNjU2cMr80HT8E8gVi3+MOq+8Lvswv+biSPxS/ocETj0AsfngDxsv4zwDy1gLdJiIhgbf6FJExEg4MOVIYEeIoDe+yXtbQmBaxCr7+sI8umjsT3leD57c0xfLJeU3c72beyD9sC/zioE1edEneEQ==
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=xp+sKjvwtCRLj0REPVNn5U0LAcgr2vdjnzREMqTFThI=;
 b=t6LBcWym/vXRIQRT3AP0hQ4TY7q3TGR+Xxg7uFakW86U26EjOZPZ2kuCluaN46nnmqho+EQPL9O0rQTk+aoUKEqbyK+EzFRPjGwTrTPuEMheo/Ivwj7jrPloWxZOT5O5M2VWlndYuRH2LZK5+IMStI17hhMGWjjoiuzG6Yy4WketPe+Ihs6mzAqt4fDNJD3u+bXdOO5lZXwG7sa0OY9rV2zliA15ULxH+/F3F9uSdQ1aJf2vifMzgh2lEKo149LoqpsjuDkKQYlzEUYJ+cz9jjhhEq8iWIjvOnfh5s24d5euwVaqkDVc2SK3wXAchDpyLb0ra0l0wWSAw5WL6JmNGA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <9e6a8f9e-977e-43b1-b1f9-182b28512445@epam.com>
Date: Thu, 25 Sep 2025 13:58:56 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 "Alejandro.GarciaVallejo@amd.com" ,
 Jason Andryuk 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk 
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
 <2954ab89-cf30-4b00-87c5-37449a571fdd@epam.com>
 <2475e7ad-e9da-491c-80b3-dd39b81d7c1c@epam.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <2475e7ad-e9da-491c-80b3-dd39b81d7c1c@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0384.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f7::18) To PAVPR03MB8921.eurprd03.prod.outlook.com
 (2603:10a6:102:322::9)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAVPR03MB8921:EE_|PR3PR03MB6410:EE_
X-MS-Office365-Filtering-Correlation-Id: 137eb653-ae20-46d0-e9c3-08ddfc2286ee
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MTU3T0FFa0lGRC9VNVFUZUZPMmN1SVlWeHArZFhNQjVtYWNsc1RhZ1k1MzBZ?=
 =?utf-8?B?QTdIM3pJVEI5enZETkVETDZLNng4RlZlMkd0SDk3dXhicFlncmE0N3FlSGpW?=
 =?utf-8?B?NVp0ZUx1ZmZEQlJyOGJkWm5rVXlnWDFVQUpobCtkbisxVTNpM3UvLytxWTJp?=
 =?utf-8?B?azVYYmdXejR4VWtNY243Q2MyWFFxNU4xeVB0UW4xRk9pdFpENWMveE1MRXNu?=
 =?utf-8?B?b3o2Q3dGdXR0VDRpR2NnaDBWbGY1b0pZUWpxY2V2elZFWUdFd0R0T2ljTEVu?=
 =?utf-8?B?VURSTzZkcFpDMmVyTmhQVHBONFdESytEMVpFRVBvN0RvK1dyTE1SbXh5V2ZR?=
 =?utf-8?B?OWdJODBIZ1F6b1dxeEhuVzR4M2dhS3RnWk5WeEJaSlQ2cFBxekF4UEd2NWps?=
 =?utf-8?B?Q0t2cW9iMzFXQXFGdmora1pFZFVOczVDK3BtTno2MnlxWnNCVzN1THBvRG9r?=
 =?utf-8?B?LzkxLzFJd3VXWVdxK3poaWhtTlFnQmNGSStncW1obkY4M0dYL2dySituOHNu?=
 =?utf-8?B?Y29ybXh5M3Z6M2tqZXhIS2lKTU45RVg5TFU1alQxS3lHbElJWXIrSXZJNGg4?=
 =?utf-8?B?WWtmeGQrT3k1SlQxcTdBckZZTlZkNVE2YU5VK1hlMlUxcDZyVlZ0ckFJVEJu?=
 =?utf-8?B?RS8ydmR3enRQQ1BGNTUzdTY0bjcyU1hiRDMxTkhDZGFXNFZDazJ3czBnS3Ix?=
 =?utf-8?B?ZmgralducWFrYXdqTTNVMlJ1RUNTR2RTY0dkWDdkZzNJaWovN1ZpSzRrT09u?=
 =?utf-8?B?NnZuU1VkREtiVXM0T1NoVCtQb0dBYWoyZFV2WXl4cG9FcXNIVkx0RkJUWkIx?=
 =?utf-8?B?SnRkdU43TEQrbXROcGs0NGlKY0E2cG9MbnJJVG5RLzRrU0hualc1eEorQ2RH?=
 =?utf-8?B?V0VWUnE3MHZGQVk3dkJra2pYdkVyb05KVmk4anBicFcwT0wvWloxeGdQQ1hG?=
 =?utf-8?B?SUxGeSthM2Q1RlQyMzQwTjRrb3h3UlVBN0lUaXRtSGNzYTZpeURuVGFpR2Yr?=
 =?utf-8?B?SkwrKzB3UEVUOHoycHFnSzJvZHM0bkJDWXM5NlF0TldjdGRJeGZsVUpDa0Mr?=
 =?utf-8?B?bHo1a1dmeWpOSksvdkg4L3FYSkVOa2pPVndHeHRiQlFBbGI1Mk1QZUhwMGNF?=
 =?utf-8?B?RFMvMlE4Rzd1RkFzRkI4d1Vmb3QrWHlyTCtiZkloemx3SW1xbVJQc085aTE0?=
 =?utf-8?B?UTEvWDNjQ1FQb1dSN3pLSU1JUndIU0I5K1Z0MWE5OEJ4TkhqaUhoRytXNnh3?=
 =?utf-8?B?QWpCZitwNDFnU1NJa0NqbGUwS0YvK2REYTA2ZXhYUFBuY0xNZkhuMC9sSnBD?=
 =?utf-8?B?NXB3VWVtbkJVRnZzOGk1YW5PdnNTM2NqOUtKMmR5c0Y5MXJwbk51ZENYUDdD?=
 =?utf-8?B?aHpWVUN1SDNlaW5aWFB3dGRLNmJiMUUwbjNVczN2NDRscUpZT3RtaXRybEVY?=
 =?utf-8?B?a094U2REU0o4bk90eUp0WVdoZ2I1cndhM0NxN054clVGRTEvNnFkdkloMTdH?=
 =?utf-8?B?S2p1TEVPSUpELzkweDFxeEhFTjh0ZXBRYlFGNHQxVnJlY2JlNnVTbHpZeHds?=
 =?utf-8?B?dlVVd0hWS3R1NmoxVU50R21ENTV5N1U5T3VoTWtrS3JSaXhnNkJQU29KTGtZ?=
 =?utf-8?B?QnkrNDh2WnVQOEpzakhpZjl6R2tUamprVGVVbE1XdVBmclZPdGo0a1lMb09q?=
 =?utf-8?B?VHFjdDhUQzI3Wlo0dUEycC9wdVAwWDBGZ1Z3U2NpMEdOdTcvWWlzYmdOSjZ5?=
 =?utf-8?B?KzdYSTR2bDNJTTlQakhRYlVCR0JLU2hIcTl6OXJLajUzYlN6TlZzODU5c2dD?=
 =?utf-8?B?Szhvcmo1SlFHdVhPQ0I5WGxSWGJ4QW5OdkZlZ0xlbGowS3VnTCs3V0lRdGVC?=
 =?utf-8?B?ZjFRNklwSDdEdDBlcDcvTDlJcTNtYlFpaVhaSDBnZXBxRUlPaExhbmtReUdT?=
 =?utf-8?Q?ENuHE+Z4LOaLU6t1AKXD7tHBIWok7DqF?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8921.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZjFodysrRW1QR0MvOTJuRUZDSjN4ejNiMG9rN1B2Y09MYldBU2VJTnYrT2h6?=
 =?utf-8?B?RjVka3BHQ1JwRnlKZmUwSnpyZkxBaURDcGpCNXF3RHIwendwZWc5MUZoRDJ5?=
 =?utf-8?B?QlVTOENtaEU2NUpKZEIzNkpZT21MYkpUUkRJM3JrelBMNE43Y3lydDZIK0ty?=
 =?utf-8?B?MnB4QXFXNXRCbXlWckpYaHo1b2lnVVBoNER2Sk5OWU9SSEgrMEdJK2NxQkM3?=
 =?utf-8?B?eTBzTmlMcDE1eHlDazVzUGhpYjlFZWtRcnFGWmhqNFIwU0lWclltRnFIQ2NP?=
 =?utf-8?B?ZHpXTWJxU3d1aitzSHA2eVdXLzFGekozemtwSVIwaktUUms0eDRHT0U2aVNM?=
 =?utf-8?B?cmQrcnRoeFoxclEyVTJnMXE0UGt6QmV1Y3ZVTzk5S1d3eXV0ZWpScVpBd0pB?=
 =?utf-8?B?aUE4aVVLREgwL3dDSTJ2blhLMElBRC91N3FFYTM0Z0c3Mm9DRm9PdEdyaG1T?=
 =?utf-8?B?T2t6NE0raWIwdXhrUXMyaXZXVXp6ZFlsUUViTjB3R0tIWWJFd2x5S21oeDVs?=
 =?utf-8?B?ZUhINFpIVW53d0JYTDdmVXAvOGFPYnFwOTgvbVNnY2MzNnhyd1RRVk5pZHYv?=
 =?utf-8?B?eEQwZVFiUUJNQUtxM1p3SGhLTzN6NFFRWEl0RkkwZHVWYndMUCtoYVNIYlpS?=
 =?utf-8?B?NXRVMEl6b1c3bWtaTjZ4TWRpM2pRbEcxa2htcFR6RHJZNXAveGlldWlZVFpK?=
 =?utf-8?B?SEMreEdrR0YxVTRwdmtnU2FwQ1pNNnpQU3lUeVF4S2U2Z2NaWFNOc2MzMnlP?=
 =?utf-8?B?VWVYVVprZVVvVTVTL2NTWTNmRkdyTVFpcnZ3NzQyUHh0RWEwelcrQk1ONWtQ?=
 =?utf-8?B?ODh2RVBWTmVERkF6QytoeWFCVGVpbklOQjloUVFYS1FMQjhqODJOZkNzWUsy?=
 =?utf-8?B?SEpuaHZFeUVxbnduem1xeEtFZUlybXNDY1hZTmE5cyttTG1CeTllWnpxVkRH?=
 =?utf-8?B?ZU9EVjhDTk5SSWlVS0xkRlVGVUdhcTBaWk5RWjYyYXJ3VjV4Q21xbkhVYzVU?=
 =?utf-8?B?dkdOcFJGcXhpaGYrUmZDUnpxUis4K1VLOVdjaURIaFBWaTBvVlF3VXlaMDFF?=
 =?utf-8?B?cGpaRzFqdHhmKzVuMlFrRkwrZC9vU2NGaEprQW1Pc0xKNVZsdmxIeFBweVY5?=
 =?utf-8?B?WjZsWEZJOWxnUlZUVVJraUxpbzdveW5ocnNPd2dYOHdyTjFwSEJKQjNTb1Zm?=
 =?utf-8?B?NTBUL0MrOUtOU1BXbC9uQkIvQUlzR1Yya3NDbmkwN0IzN1ZUN3NzVFlGNmRJ?=
 =?utf-8?B?RlBuRUQ0NTBoQ3pSNGs3eTd3U3RRWkpVcmZ2emtGTHVXVGQ2T1UrangzeUlC?=
 =?utf-8?B?VzJybWNRS1ptWEZ1eERBRVZTTzludWJVbnAxTlBsY0J2TUpSaWZYOWNRUHBz?=
 =?utf-8?B?TUF0WXpzcXNLTTF0MWJ1Wm11YmpCbzN1TlpkdWtnaS9wNDlQTUlrdHhIclZs?=
 =?utf-8?B?RTg5dnhFT09ieXFlM3pTRjRXS0tOZ1dDVFBwWGdvR2kzKzUyQlozd3o0Vmh0?=
 =?utf-8?B?TEJXMlBPYUhvTEJBTXBzYVJ5SjVGcWxYZjhyTXdXZGJkRnZ3c0x0ZmhFRzd0?=
 =?utf-8?B?SlJkYVBUWFo4SmxweWlxZzdFY2lEcytQeER4UkpNZmlmN0drL3JubFR0eVgw?=
 =?utf-8?B?RGV1WlhYdi83eVZ4WDF3cVFFQ1pwaW4vQkNmNXZWNGZKMUNxZm41cUN1Vyt4?=
 =?utf-8?B?OFdRYnZRMGUxV1I2bVFoL1dYdVkzTzl1ckdmdW1XTjFXVVNNQnR4djI4MXVG?=
 =?utf-8?B?bDFVYjdpWUxZejNMTm9qV0dDUDlER3hhRWlpays4aGFFSHdybi8xWHJ0QVNu?=
 =?utf-8?B?TG9Xd0I0cjRQRS9GQ2xENEcxb29LOWFsNmp1NFlINlNraTZXTWRxRGk2c3Bz?=
 =?utf-8?B?QlZJQ0pqejdTUUJTRDV6b0FRUnNMV1lUR2VrM2ozVzBMOG1zYUFsV2h6cmVL?=
 =?utf-8?B?QXg0bS9RYnFnNkpPc214eTc4L2w3amdxTWw5dWhicm00V08rblBITDZHNlR1?=
 =?utf-8?B?cWtlZitrTHRrZU5JTEpUNXN3Q3NqK0ZxSmdUT3BJYUI1QWRNS21kVnhlVkZ3?=
 =?utf-8?B?bENwbHpWRVN6TnljaTVhN2EzRFpTQy9JOGZCTllScjFDQUo5SHhDNkkrL3Zu?=
 =?utf-8?B?Yk1RV3E5dUgyZTcyY1hyS2VoYk1DMUd6WVphaFFsbEg3UHg5dmdKWWExdkxC?=
 =?utf-8?B?N0E9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 137eb653-ae20-46d0-e9c3-08ddfc2286ee
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8921.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 10:58:58.2247
 (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: CoUcz4DO+/uhAGgsRL7V2u87mAcRXGkZq1hY182XY+IjkijAcEAnh5EPLLHqcd5juDDrnXLZsa09ZcsiXcIkKpNHWjj7qtiUl2ppaA13OCk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6410



On 25.09.25 13:53, Oleksii Moisieiev wrote:
> 
> 
> On 25/09/2025 12:22, Grygorii Strashko wrote:
>>
>>
>> On 24.09.25 19:00, Oleksii Moisieiev wrote:
>>> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
>>> allow for building Xen without support for booting a regular domain
>>> (Dom0).
>>> This functionality is primarily intended for the ARM architecture.
>>>
>>> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
>>> default for ARM and X86 architecture. This symbol signifies that an
>>> architecture has the capability to support a Dom0.
>>>
>>> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
>>> expert users, this option can be disabled (`CONFIG_EXPERT=y` and no
>>> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
>>> creation code on ARM. This is useful for embedded or dom0less-only
>>> scenarios to reduce binary size and complexity.
>>>
>>> The ARM boot path has been updated to panic if it detects a non-dom0less
>>> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an
>>> invalid
>>> boot.
>>>
>>> Signed-off-by: Oleksii Moisieiev 
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - rephrase error message when dom0less mode wasn't detected while dom0
>>> is disabled.
>>> - rephrase help message for DOM0_BOOT config option
>>> - update DOM0_BOOT dependencies for X86
>>>
>>> Changes in v2:
>>> - decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
>>> suggested in ML) because in this case HAS_DOM0LESS should be renamed
>>> either.
>>> - fix order of HAS_DOM0 config parameter
>>> - add HAS_DOM0 option to x86 architecture.
>>>
>>> CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
>>> regular (legacy) domain an optional feature that can be compiled out
>>> from the Xen hypervisor build.
>>>
>>> The primary motivation for this change is to enhance modularity and
>>> produce a cleaner, more specialized hypervisor binary when a control
>>> domain is not needed. In many embedded or dedicated systems, Xen is
>>> used in a "dom0less" configuration where guests are pre-configured and
>>> launched directly by the hypervisor. In these scenarios, the entire
>>> subsystem for booting and managing Dom0 is unnecessary.
>>>
>>> This approach aligns with software quality standards like MISRA C,
>>> which advocate for the removal of unreachable or unnecessary code to
>>> improve safety and maintainability. Specifically, this change helps
>>> adhere to:
>>>
>>> MISRA C:2012, Rule 2.2: "There shall be no dead code"
>>>
>>> In a build configured for a dom0less environment, the code responsible
>>> for creating Dom0 would be considered "dead code" as it would never be
>>> executed. By using the preprocessor to remove it before compilation,
>>> we ensure that the final executable is free from this unreachable
>>> code. This simplifies static analysis, reduces the attack surface,
>>> and makes the codebase easier to verify, which is critical for
>>> systems requiring high levels of safety and security.
>>>
>>> ---
>>>    xen/arch/arm/Kconfig        |  1 +
>>>    xen/arch/arm/domain_build.c |  8 ++++++++
>>>    xen/arch/arm/setup.c        | 14 ++++++++++----
>>>    xen/arch/x86/Kconfig        |  1 +
>>>    xen/common/Kconfig          | 11 +++++++++++
>>>    5 files changed, 31 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index cf6af68299..336b2ed242 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -17,6 +17,7 @@ config ARM
>>>        select GENERIC_UART_INIT
>>>        select HAS_ALTERNATIVE if HAS_VMAP
>>>        select HAS_DEVICE_TREE_DISCOVERY
>>> +    select HAS_DOM0
>>
>> Here HAS_DOM0 is selected and all dependencies also selected (
>> HAS_DEVICE_TREE_DISCOVERY, DOMAIN_BUILD_HELPERS)
>>
>>>        select HAS_DOM0LESS
>>>        select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
>>>        select HAS_STACK_PROTECTOR
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index fb8fbb1650..62602afc78 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -42,8 +42,10 @@
>>>    #include 
>>>    #include 
>>>    +#ifdef CONFIG_DOM0_BOOT
>>>    static unsigned int __initdata opt_dom0_max_vcpus;
>>>    integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>> +#endif
>>>      /*
>>>     * If true, the extended regions support is enabled for dom0 and
>>> @@ -104,6 +106,7 @@ int __init parse_arch_dom0_param(const char *s,
>>> const char *e)
>>>     */
>>>    #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>>>    +#ifdef CONFIG_DOM0_BOOT
>>>    unsigned int __init dom0_max_vcpus(void)
>>>    {
>>>        if ( opt_dom0_max_vcpus == 0 )
>>> @@ -116,6 +119,7 @@ unsigned int __init dom0_max_vcpus(void)
>>>          return opt_dom0_max_vcpus;
>>>    }
>>> +#endif
>>>      /*
>>>     * Insert the given pages into a memory bank, banks are ordered by
>>> address.
>>> @@ -1962,6 +1966,7 @@ int __init construct_domain(struct domain *d,
>>> struct kernel_info *kinfo)
>>>        return 0;
>>>    }
>>>    +#ifdef CONFIG_DOM0_BOOT
>>>    static int __init construct_dom0(struct domain *d)
>>>    {
>>>        struct kernel_info kinfo = KERNEL_INFO_INIT;
>>> @@ -1993,6 +1998,7 @@ static int __init construct_dom0(struct domain *d)
>>>          return construct_hwdom(&kinfo, NULL);
>>>    }
>>> +#endif
>>>      int __init construct_hwdom(struct kernel_info *kinfo,
>>>                               const struct dt_device_node *node)
>>> @@ -2046,6 +2052,7 @@ int __init construct_hwdom(struct kernel_info
>>> *kinfo,
>>>        return construct_domain(d, kinfo);
>>>    }
>>>    +#ifdef CONFIG_DOM0_BOOT
>>>    void __init create_dom0(void)
>>>    {
>>>        struct domain *dom0;
>>> @@ -2103,6 +2110,7 @@ void __init create_dom0(void)
>>>          set_xs_domain(dom0);
>>>    }
>>> +#endif /* CONFIG_DOM0_BOOT */
>>>      /*
>>>     * Local variables:
>>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>>> index 7ad870e382..fbb290df60 100644
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -481,12 +481,18 @@ void asmlinkage __init noreturn
>>> start_xen(unsigned long fdt_paddr)
>>>        enable_errata_workarounds();
>>>        enable_cpu_features();
>>>    -    /* Create initial domain 0. */
>>> -    if ( !is_dom0less_mode() )
>>> +    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
>>> +    {
>>> +        /* Create initial domain 0. */
>>>            create_dom0();
>>> +    }
>>>        else
>>> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
>>> -
>>> +    {
>>> +        if ( is_dom0less_mode())
>>> +            printk(XENLOG_INFO "Xen dom0less mode detected\n");
>>> +        else
>>> +            panic("Neither dom0 nor dom0less mode was detected,
>>> aborting\n");
>>> +    }
>>>        if ( acpi_disabled )
>>>        {
>>>            create_domUs();
>>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>>> index 3f0f3a0f3a..2aeb361c63 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_DOM0
>>>        select HAS_EHCI
>>>        select HAS_EX_TABLE
>>>        select HAS_FAST_MULTIPLY
>>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>>> index 76f9ce705f..10a8fc8718 100644
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -26,6 +26,14 @@ config DOM0LESS_BOOT
>>>          Xen boot without the need of a control domain (Dom0), which
>>> could be
>>>          present anyway.
>>>    +config DOM0_BOOT
>>> +    bool "Dom0 boot support" if EXPERT
>>> +    default y
>>> +    depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY &&
>>> DOMAIN_BUILD_HELPERS) || (X86 && HAS_DOM0)
>>
>> Here you repeat the same dependencies. In general, if you introduce
>> HAS_DOM0,
>> which is expected to be selected by ARCH, then all you need is
>>
>>      depends on HAS_DOM0
>>
>> It's ARCH decision to select HAS_DOM0, or not.
>>
>>> +    help
>>> +      Dom0 boot support enables Xen to boot to the all-powerful
>>> domain (Dom0).
>>> +      If this isn't enabled Xen is expected to boot in dom0less mode
>>> only.
>>
>> "is expected to boot and launching all domains in dom0less/Hyperlaunch
>> mode only."?
>>
> Thanks for the review. Hyperlauch is not merged right now so I don't
> think it's a good idea to introduce new term.
> Agree with other statemets above.

Hyperlauch is partially in "git log --oneline | grep -i hyperl" and hope is to get it in
the next version.

That's, actually, a good reason to have this option in common and not ARM specific.

>>> +
>>>    config DOMAIN_BUILD_HELPERS
>>>        bool
>>>    @@ -125,6 +133,9 @@ config HAS_DEVICE_TREE_DISCOVERY
>>>        bool
>>>        select DEVICE_TREE_PARSE
>>>    +config HAS_DOM0
>>> +    bool
>>> +
>>>    config HAS_DOM0LESS
>>>        bool
>>

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Thu Sep 25 11:57:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 11:57:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130431.1469990 (Exim 4.92)
	(envelope-from )
	id 1v1kax-0007SF-DL; Thu, 25 Sep 2025 11:57:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130431.1469990; Thu, 25 Sep 2025 11:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1kax-0007S8-AA; Thu, 25 Sep 2025 11:57:07 +0000
Received: by outflank-mailman (input) for mailman id 1130431;
 Thu, 25 Sep 2025 11:57: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 1v1kav-0007Rw-Ob
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 11:57:05 +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 ba83920b-9a06-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 13:56:54 +0200 (CEST)
Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52])
 by mailfout.phl.internal (Postfix) with ESMTP id 37D77EC01B4;
 Thu, 25 Sep 2025 07:56:53 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-12.internal (MEProxy); Thu, 25 Sep 2025 07:56:53 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 25 Sep 2025 07:56: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: ba83920b-9a06-11f0-9809-7dc792cee155
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=1758801413;
	 x=1758887813; bh=zteHaL9KF3LqnN3cNTlk/wtnTwJ1Zyvgq0wx3UtS3b4=; b=
	bqroH2YxczKCnbOiVliGRCrT0vKN8w35hHddTPeZOf2pEcbF+Aq8e7lYn0S6nICl
	FmY8J2GWWJdWBNRMbhmtLlRlK6s2X49xTStJwE/LkXmurTbqgYZvQzrr8NMDY5gF
	mGw42mOwsTi5vstbfs49Dq+1frt1JKUkG7dGIkltcmZfJjB+W/JIN9ylsSJlzl/2
	95AuUVMKqywfkJs+eimg5nvSZCGqq078yq15cGjQQcJvF+vHJ7eEwZJEVx+XpSen
	TSKsXUse+glmzSg5sKzaMrivarom04waypq7aRB5iWdOyJJsDw/VYCMR0ZIiII14
	3KU8ING2fLg5LYHxVVvnEw==
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=
	1758801413; x=1758887813; bh=zteHaL9KF3LqnN3cNTlk/wtnTwJ1Zyvgq0w
	x3UtS3b4=; b=iFJ/RQwQXOis4PscnS8++c7tr+hIcLfqVmbYGQtJGIX/xVIMc96
	T3XB/XuplCJX04/e6dStDJi2o8x2369uIun4K5cUgQdu2kEmtSZ8J7ngN4tLoBVL
	iGOzGlsCXBGRSVYJrX7PzTLr/q6TQUbHQvScM+uI64emzHyu+R0/+ZFtU9YUGQFk
	9l2ICTYxhFH4reqpR7SdGlvc+LJocJi1tvhjH4eUhXiHfR77NdMNj1ETt7RjdcMc
	VAUoRpvRTg4177ZMNW99gF+L6Zp6P+jKNs3B0n/SsrW/uguvFk8NjVDAI5R3BACo
	EsJFPDKITeuNMa4J0oXQlZjPZuXa7pyKdAg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeiieegfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpedvgffhieeu
    tdevueelgeejgedvkeeuueetgedvhedvieehfeetkedvfefgkeetvdenucffohhmrghinh
    epuhgvfhhirdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi
    lhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtg
    homhdpnhgspghrtghpthhtohepuddvpdhmohguvgepshhmthhpohhuthdprhgtphhtthho
    pegrlhgvjhgrnhgurhhordhgrghrtghirghvrghllhgvjhhosegrmhgurdgtohhmpdhrtg
    hpthhtohepghgvrhgrlhgurdgvlhguvghrqdhvrghsshestghlohhuugdrtghomhdprhgt
    phhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
    dprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdrtgho
    mhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtoheprg
    hnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhht
    hhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrg
    hlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdho
    rhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 25 Sep 2025 13:56:49 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Alejandro Vallejo 
Cc: Gerald Elder-Vass ,
	Xen-devel ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH 2/3] efi: Protect against unnecessary image unloading
Message-ID: 
References: 
 <1f7b5737d4b36623af2734d525c895b77fef08fc.1757519202.git.gerald.elder-vass@cloud.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="O4Zuhw5ZLN64wCwi"
Content-Disposition: inline
In-Reply-To: 


--O4Zuhw5ZLN64wCwi
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Sep 2025 13:56:49 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Alejandro Vallejo 
Cc: Gerald Elder-Vass ,
	Xen-devel ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH 2/3] efi: Protect against unnecessary image unloading

On Thu, Sep 11, 2025 at 07:20:33PM +0200, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 10:24 AM CEST, Gerald Elder-Vass wrote:
> > Commit 59a1d6d3ea1e introduced Shim's LoadImage protocol and unloads the
> > image after loading it (for verification purposes) regardless of the
> > returned status. The protocol API implies this is the correct behaviour
> > but we should add a check to protect against the unlikely case this
> > frees any memory in use.
>=20
> Any what memory in use? The function loads an image, it's not a consumer.
>=20
> It can't free anything because it doesn't know where it came from. It mig=
ht've
> been embedded in your own binary, and it can't compromise its integrity l=
ike
> that.
>=20
> >
> > Signed-off-by: Gerald Elder-Vass 
> > ---
> > CC: Marek Marczykowski-G=C3=B3recki 
> > CC: "Daniel P. Smith" 
> > CC: Jan Beulich 
> > CC: Andrew Cooper 
> > CC: Anthony PERARD 
> > CC: Michal Orzel 
> > CC: Julien Grall 
> > CC: "Roger Pau Monn=C3=A9" 
> > CC: Stefano Stabellini 
> > ---
> >  xen/common/efi/boot.c | 11 ++++++-----
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index 69fc022c18ab..ca162db0d8d3 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -1062,7 +1062,7 @@ static void __init efi_verify_kernel(EFI_HANDLE I=
mageHandle)
> >      static EFI_GUID __initdata shim_image_guid =3D SHIM_IMAGE_LOADER_G=
UID;
> >      static EFI_GUID __initdata shim_lock_guid =3D SHIM_LOCK_PROTOCOL_G=
UID;
> >      SHIM_IMAGE_LOADER *shim_loader;
> > -    EFI_HANDLE loaded_kernel;
> > +    EFI_HANDLE loaded_kernel =3D NULL;
>=20
> This isn't required if unloading checks for the success case or the only =
error case
> that has a successful load. See below.
>=20
> Furthermore, you don't really know if the callee clobbered it.
>=20
> >      EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> >      EFI_STATUS status;
> >      bool verified =3D false;
> > @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE=
 ImageHandle)
> >              verified =3D true;
> > =20
> >          /*
> > -         * Always unload the image.  We only needed LoadImage() to per=
form
> > -         * verification anyway, and in the case of a failure there may=
 still
> > -         * be cleanup needing to be performed.
> > +         * If the kernel was loaded, unload it. We only needed LoadIma=
ge() to
> > +         * perform verification anyway, and in the case of a failure t=
here may
> > +         * still be cleanup needing to be performed.
> >           */
> > -        shim_loader->UnloadImage(loaded_kernel);
> > +        if ( loaded_kernel )
>=20
> Not sure this is what you want. The image needs unloading only when there=
's no
> error OR the error is EFI_SECURITY_VIOLATION. See section 7.4.1:
>=20
> https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html#efi-boot-=
services-loadimage
>=20
> ... and shim being a drop-in replacement, it's meant to be spec-compliant.
>=20
> Trying to unload based on the assumption that loaded_image will remain un=
disturbed is
> an assumption waiting to be broken.
>=20
> IMO, this wants to be instead:
>=20
>   if ( !EFI_ERROR(status) || (status =3D=3D EFI_SECURITY_VIOLATION) )
>       // unload

I agree, this version would be better.

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjVLgAACgkQ24/THMrX
1ywxmQf/SjhzScRx9o9ZI/dlYVm14fUlIrw4U+y4u92wFEm++l7fuphwAAiM1DxR
4hVH/2EAwuVzLIdEFOBb0SGPfb7+5LwhKDeb5QxPpDW6P8f6/LKLHKp23k5nWW31
c1M3V7yFRoOOkhsQnoigxkkfXjza6igocxw6xXs0LYRaEoW1II/qKZQHbZBz3yWu
UBroXr70pBZ2Yu1R8+wqMN+i8EaaSWSSS8DaV2gaAVW+uhS0mEwPzMoETQKxO/ON
WQ+AXpEkqztvOtSaAY4yI3mdGSWbXySL2m8rZndPK3zDmiFXHpXSwz8tSVI8/n/7
C1TzpEpPx1gH2KcRpk00VuZX+s7sGQ==
=3Rs7
-----END PGP SIGNATURE-----

--O4Zuhw5ZLN64wCwi--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 11:57:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 11:57:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130436.1470000 (Exim 4.92)
	(envelope-from )
	id 1v1kbI-0007qh-P3; Thu, 25 Sep 2025 11:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130436.1470000; Thu, 25 Sep 2025 11: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 1v1kbI-0007qa-MJ; Thu, 25 Sep 2025 11:57:28 +0000
Received: by outflank-mailman (input) for mailman id 1130436;
 Thu, 25 Sep 2025 11: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 1v1kbH-0007lR-MX
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 11:57:27 +0000
Received: from fout-a5-smtp.messagingengine.com
 (fout-a5-smtp.messagingengine.com [103.168.172.148])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cdf77aa4-9a06-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 13:57:27 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51])
 by mailfout.phl.internal (Postfix) with ESMTP id 4E4B2EC0203;
 Thu, 25 Sep 2025 07:57:26 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Thu, 25 Sep 2025 07:57:26 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 25 Sep 2025 07:57:24 -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: cdf77aa4-9a06-11f0-9d14-b5c5bf9af7f9
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=1758801446;
	 x=1758887846; bh=NNjvJ9DFViRSIHc6zj2a3bLS1JHSQWbqqG7AXEFCrHs=; b=
	bF7gi29KxeYE8Z8gWTvBdEPcL/xOy77sQGgDk5oS+omMsgOkgDJSLhClmecj9Zml
	5fjODrTuR2IIAWYfsHOz/Z9yethLsBByPSSdTfYVHYaGfZysV8psYAsd494KTwJZ
	FPYyXUmFd/3ToFCQ5vSf4wTgiO1xRBh+Agj/5HZUxvYGI9JX/2hcy3FLZQstfBMO
	ZKmbv8Yz4Je2RA15rLlavXkIsE8ERI7glUMpsU7M/modLK/norZBUOaOUITaJJR/
	67IGkHDqVnY6M/zy7OTektqGOO2t92vcVozgZuw29t+NbtF3+0d0RckNBj0XpIa1
	uGsVI54UIjcH84CNTjT4Cg==
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=
	1758801446; x=1758887846; bh=NNjvJ9DFViRSIHc6zj2a3bLS1JHSQWbqqG7
	AXEFCrHs=; b=RfXMFSpeMr94an6JdmGeCZSRn4XOH/eLO9eH84KuvKabHw9yqzj
	W9jPuyuXz2IQr2rGjUOHLr2qCHZFVkItUOUKL+WGHOCIx5Aj9yBTCG8FnFTdl5de
	/tYPBvi2UWr+ykSRjOrZRvd4bHhtHZ1WcOVYQeKqza0PNT0jYDhvqSSveUiV/v3H
	skqW/CzKEEYifZieAapXIou6q9Ci3sSiPUlGQhqp+aFMmG+/UlfV4umggoANTQob
	9JBCDTGo5rU6SAPj8dFRP7XcBoEVyJ72Dxmp7uki66djQPxbQcTJxIf7/uNl9sv0
	atZ+iBtnUvP7ue4gslIb9kvQNHA/lQH3pwg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeiieegvdcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedutddpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepghgvrhgrlhgurdgvlhguvghrqdhvrghs
    shestghlohhuugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrd
    igvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhht
    uhhsshholhhuthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhush
    gvrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidr
    tghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtg
    hhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthht
    ohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestg
    hithhrihigrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 25 Sep 2025 13:57:22 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH 1/3] efi: Fix line length in init_secure_boot_mode
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="FGkb3Ncgfg56v8so"
Content-Disposition: inline
In-Reply-To: 


--FGkb3Ncgfg56v8so
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Sep 2025 13:57:22 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Gerald Elder-Vass 
Cc: Xen-devel ,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini 
Subject: Re: [PATCH 1/3] efi: Fix line length in init_secure_boot_mode

On Thu, Sep 11, 2025 at 08:24:27AM +0000, Gerald Elder-Vass wrote:
> Commit cb41b4ce14a9 introduced init_secure_boot_mode but one line was
> not wrapped appropriately.
>=20
> Signed-off-by: Gerald Elder-Vass 

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

> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: "Daniel P. Smith" 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Julien Grall 
> CC: "Roger Pau Monn=C3=A9" 
> CC: Stefano Stabellini 
> ---
>  xen/common/efi/boot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index b86c83d3348c..69fc022c18ab 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -923,7 +923,8 @@ static void __init init_secure_boot_mode(void)
> =20
>      if ( status =3D=3D EFI_NOT_FOUND ||
>           (status =3D=3D EFI_SUCCESS &&
> -          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RU=
NTIME_ACCESS) &&
> +          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +                   EFI_VARIABLE_RUNTIME_ACCESS) &&
>            size =3D=3D 1 && data =3D=3D 0) )
>          /* Platform does not support Secure Boot or it's disabled. */
>          efi_secure_boot =3D false;
> --=20
> 2.47.3
>=20

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjVLiIACgkQ24/THMrX
1yx0+Af+LVmJiLk3dA97mddOBx9AyE6OLb/ZubKU4YvfAYvgtDwBK8W6Uckotj8H
9HXMxEXSDkbg5Q/Ge7puL8YorDD5N33ShlzBRV/VLB1lJjyQIXKXkAyLy7C9X/d9
dwf8VS3VCIKct7u0/sM/c6ccsQRfRO0NGv5/4kPR+R5qgiKLqygFfjr2g9L1gIY2
lSoRujyuePypGdCb1rNG/Oihf5CFepj5+lwWIYczS093kNFs/W+VLTHi+PT9Qtm2
x46fyXeaeCa9h3cR2hpwtmr+vU9aveo1k3pwOZMmXcIB/QY3Jyxp+/OfgqaZGAkc
3KyIhNFcPhCv++9ZNLbebcuOJU57Bw==
=L83s
-----END PGP SIGNATURE-----

--FGkb3Ncgfg56v8so--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 11:58:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 11:58:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130457.1470012 (Exim 4.92)
	(envelope-from )
	id 1v1kc3-0008Up-2y; Thu, 25 Sep 2025 11:58:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130457.1470012; Thu, 25 Sep 2025 11:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1kc2-0008Ui-US; Thu, 25 Sep 2025 11:58:14 +0000
Received: by outflank-mailman (input) for mailman id 1130457;
 Thu, 25 Sep 2025 11:58: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 1v1kc1-0007lR-1r
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 11:58:13 +0000
Received: from fout-a5-smtp.messagingengine.com
 (fout-a5-smtp.messagingengine.com [103.168.172.148])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e904b889-9a06-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 13:58:12 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id AC176EC020D;
 Thu, 25 Sep 2025 07:58:11 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Thu, 25 Sep 2025 07:58:11 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 25 Sep 2025 07:58:09 -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: e904b889-9a06-11f0-9d14-b5c5bf9af7f9
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=1758801491;
	 x=1758887891; bh=HX9p3K2wchkmc/8ivOZi6vofoPtMjR9YTrC7j5IT+1E=; b=
	nI8iWDzymrOGRjlg1ERb+CPrjjPQdfCEB3hbM7X8rqYuCHVijGfAkTYGwHsycG2I
	BBtNXLgjRhkOGwAv1eh9VzuBDCWZUMHBwxoO2zUZaFAa9YDn2YE5pJ14nsjcQMoZ
	p0QvBGOkgSMF2qiQ6TWuQPNNWmTFLfUAoi6kaDtNErCihCVUt//sZ2cb040rM9V1
	fwCkE/C+7AezYDVHqIq4LYwWq8G67nWyGc2gc5nGHyLOZaMqyFumXxQFejuf3Et/
	3EEWfPjS68aMee+g71NvYCZLO1okjeHiXvdMO4sAcseuLDNW/CPni55CVFFeJrf5
	IoUpGBtixnNFyWDP40Fo/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=
	1758801491; x=1758887891; bh=HX9p3K2wchkmc/8ivOZi6vofoPtMjR9YTrC
	7j5IT+1E=; b=K/H6qgtRGSb15gEOrYiGXLsokjvWcxTsqLufazsqGlG1TX+9nmP
	VPxjsh4yRQC/FR8l8HLXJVto+DDc31woA/mtTsi1JqGMJLEAU2lEnb4AcSmwu4og
	KQ97y8Z3HyQPgX05LqcGpD+fcR76mtX1NEaJg5xx2f/BVzpGXtKJmcRzEtmK4H1N
	42JYvR8K58uS3gV8zNJx+h4NZbaTaACwHIA1R3xmMN8Gd+4yG/kZzmLnSwC9w/vb
	/L8YjwjNEkBPSzkopPHWkzmHj+qAE0eh6OwQabmQ9Je7YhszFavszODPM/8Dtcti
	1ITZUZP1klhOtCn1Xy0iE1fFbfdcgXt5TEA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeiieegfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedutddpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho
    mhdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhssegtlhhouhgurdgtoh
    hmpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgt
    ohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomh
    dprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhr
    tghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjh
    hulhhivghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhr
    ihigrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorh
    hg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 25 Sep 2025 13:58:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Gerald Elder-Vass ,
	"Daniel P. Smith" ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH 3/3] efi: Limit Shim's Verify success to EFI_SUCCESS
Message-ID: 
References: 
 <20fa42c198ab257085a49e157a2d0e58a0010393.1757519202.git.gerald.elder-vass@cloud.com>
 <2a1df546-c0b5-4937-9d9f-4d1c58c3e925@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="3pgFQ4hiFj6ZSUDD"
Content-Disposition: inline
In-Reply-To: <2a1df546-c0b5-4937-9d9f-4d1c58c3e925@suse.com>


--3pgFQ4hiFj6ZSUDD
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Sep 2025 13:58:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Gerald Elder-Vass ,
	"Daniel P. Smith" ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Xen-devel 
Subject: Re: [PATCH 3/3] efi: Limit Shim's Verify success to EFI_SUCCESS

On Thu, Sep 11, 2025 at 10:35:51AM +0200, Jan Beulich wrote:
> On 11.09.2025 10:24, Gerald Elder-Vass wrote:
> > Commit 59a1d6d3ea1e replaced the Verify status check with
> > !EFI_ERROR(...), this changed the behaviour to consider any warnings
> > (EFI_WARN_) to be considered a successful verification.
> >=20
> > This commit reverts that behaviour change.
>=20
> Reported-by: Jan Beulich 
> Fixes: ...
>=20
> > Signed-off-by: Gerald Elder-Vass 
>=20
> Reviewed-by: Jan Beulich 

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

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

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

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjVLlAACgkQ24/THMrX
1yzHBQf+Mee4Vmm4EwggcQq9NZzRK89dmD/+aDFOKUNI1wfA/Ai3zI0FNpbey67F
tCsc67NUGydRRb6PHG41YqfCzrJSipiJnKLISkSv0CO0dZUqFiOtOZv2oCgF57Y2
njKn5+WMF3y+259/dFy1qdi/fFJCTGEH93GhwkYyEaou6agqrs4Lo4O7k1vn/DLI
TcNsVmthNBXyRcMErUJu7T3YIA28ljAVNmCtCwPo9JAxDEZmrjtDESj+8O33f3FS
RbNeWmPPpBJRJhSxIgA4IlxNYIotqO+1H6Njr8LIxKQq+YQIDoF/whrAQ3erYMWv
Bkaj2zppQakgCiD/n7uVjex+AwF+mw==
=yVRv
-----END PGP SIGNATURE-----

--3pgFQ4hiFj6ZSUDD--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 12:18:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 12:18:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130482.1470020 (Exim 4.92)
	(envelope-from )
	id 1v1kvS-0003DQ-J1; Thu, 25 Sep 2025 12:18:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130482.1470020; Thu, 25 Sep 2025 12:18:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1kvS-0003DJ-GS; Thu, 25 Sep 2025 12:18:18 +0000
Received: by outflank-mailman (input) for mailman id 1130482;
 Thu, 25 Sep 2025 12:18:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1kvR-0003DD-PB
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 12:18:17 +0000
Received: from mail180-36.suw31.mandrillapp.com
 (mail180-36.suw31.mandrillapp.com [198.2.180.36])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b3d08c11-9a09-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 14:18:11 +0200 (CEST)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-36.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4cXXmf2sRwzlg1Zh
 for ; Thu, 25 Sep 2025 12:18:10 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 9ee169bf4786479b9503b6ed6a8e7e30; Thu, 25 Sep 2025 12:18: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: b3d08c11-9a09-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1758802690; x=1759072690;
	bh=JKilhYpTE5ep7HfJnAYoiJxWkDZWfvDEUgMJdk37F0U=;
	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=Ay5lyo8JHwF0oKSE3V04sLiW2G3DERtKoQEYGtRwn32NKPBjrR2iDjPfu7E1QcfZ1
	 7mElpSiIOaT+9bAWlGH4tAyJSi7zqSaIIEDM+yTktbBEz9UZsnHu30yXWaQj3iOmVi
	 J40h6mvEtfgTKaI6SwG2XcbYGfKr31V2yqUzj8ewM9kQ220B5ArjaHK398Bft/8hu5
	 FR+dcm55DiUPewEfRh9YpqOxAa70kOgoqxgWVPyWfi7ax8Cc3wSyzE0mP6flb3c7jU
	 trBYYQSwRw8+oXQwvl+Ld3EbOSOGRrtnqhrBxP+uz5OmrVbx3xWKMwR3PdMHFoOkq6
	 BSxyWwhkYdFGA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1758802690; x=1759063190; i=teddy.astie@vates.tech;
	bh=JKilhYpTE5ep7HfJnAYoiJxWkDZWfvDEUgMJdk37F0U=;
	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=krcOr2oMw4I9/0YWttZXvT+JAGYjvUsQGpDDFLDJX/laOrjItJNIu/RCRjvwmYUyf
	 Y7rHuRWUIDfpkEpDfe0aPBN06RiFJd/P31xYvkpWBcO01lUA4iLB4ufn2ebZKyT6TU
	 4uhF3tCUqeCh6f+8WpStrhM1I8CjAMVj8KZpLE3EWXcPYedU+R/jaTK7MGuEGOMJZ1
	 ax5aW9/LoGQnX+aJGHb/zlwSrIWiAvRTAvlfhzFaM69UyXhXYe9NDY/UZGxgjSS+kO
	 /H9bGhVUslHuh1gF1Z3VqlgUNrMoZh5+PiDum/3So4n+N9Lae+CIiNzRdpTJLx65LO
	 aNMBqlS3O2HYA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20for-4.21=201/2]=20x86/AMD:=20avoid=20REP=20MOVSB=20for=20Zen3/4?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1758802689248
Message-Id: <485889ed-2820-4bb3-b450-88553dbb719e@vates.tech>
To: "Jan Beulich" , xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Oleksii Kurochko" 
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com> <6bcaa5b7-4e34-40c9-85e6-48a0a5869b86@suse.com>
In-Reply-To: <6bcaa5b7-4e34-40c9-85e6-48a0a5869b86@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.9ee169bf4786479b9503b6ed6a8e7e30?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250925:md
Date: Thu, 25 Sep 2025 12:18:10 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 25/09/2025 =C3=A0 12:48, Jan Beulich a =C3=A9crit=C2=A0:
> Along with Zen2 (which doesn't expose ERMS), both families reportedly
> suffer from sub-optimal aliasing detection when deciding whether REP MOVS=
B
> can actually be carried out the accelerated way. Therefore we want to
> avoid its use in the common case (memset(), copy_page_hot()).

s/memset/memcpy (memset probably uses rep stosb which is not affected IIUC)

> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> Question is whether merely avoiding REP MOVSB (but not REP MOVSQ) is goin=
g
> to be good enough.
> 

This probably wants to be checked with benchmarks of rep movsb vs rep 
movsq+b (current non-ERMS algorithm). If the issue also occurs with rep 
movsq, it may be preferable to keep rep movsb even considering this issue.

> --- a/xen/arch/x86/copy_page.S
> +++ b/xen/arch/x86/copy_page.S
> @@ -57,6 +57,6 @@ END(copy_page_cold)
>           .endm
>   
>   FUNC(copy_page_hot)
> -        ALTERNATIVE copy_page_movsq, copy_page_movsb, X86_FEATURE_ERMS
> +        ALTERNATIVE copy_page_movsq, copy_page_movsb, X86_FEATURE_XEN_RE=
P_MOVSB
>           RET
>   END(copy_page_hot)
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -1386,6 +1386,10 @@ static void cf_check init_amd(struct cpu
>   
>   =09check_syscfg_dram_mod_en();
>   
> +=09if (c =3D=3D &boot_cpu_data && cpu_has(c, X86_FEATURE_ERMS)
> +=09    && c->family !=3D 0x19 /* Zen3/4 */)
> +=09=09setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
> +

May it be fixed through a (future ?) microcode update, especially since 
rep movs is microcoded on these archs ?

>   =09amd_log_freq(c);
>   }
>   
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -684,6 +684,9 @@ static void cf_check init_intel(struct c
>   =09 */
>   =09if (c =3D=3D &boot_cpu_data && c->vfm =3D=3D INTEL_SKYLAKE_X)
>   =09=09setup_clear_cpu_cap(X86_FEATURE_CLWB);
> +
> +=09if (c =3D=3D &boot_cpu_data && cpu_has(c, X86_FEATURE_ERMS))
> +=09=09setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
>   }
>   
>   const struct cpu_dev __initconst_cf_clobber intel_cpu_dev =3D {
> --- a/xen/arch/x86/include/asm/cpufeatures.h
> +++ b/xen/arch/x86/include/asm/cpufeatures.h
> @@ -7,7 +7,7 @@
>   #define FSCAPINTS FEATURESET_NR_ENTRIES
>   
>   /* Synthetic words follow the featureset words. */
> -#define X86_NR_SYNTH 1
> +#define X86_NR_SYNTH 2
>   #define X86_SYNTH(x) (FSCAPINTS * 32 + (x))
>   
>   /* Synthetic features */
> @@ -43,6 +43,7 @@ XEN_CPUFEATURE(IBPB_ENTRY_PV,     X86_SY
>   XEN_CPUFEATURE(IBPB_ENTRY_HVM,    X86_SYNTH(29)) /* MSR_PRED_CMD used b=
y Xen for HVM */
>   XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead =
of VMMCALL */
>   XEN_CPUFEATURE(PDX_COMPRESSION,   X86_SYNTH(31)) /* PDX compression */
> +XEN_CPUFEATURE(XEN_REP_MOVSB,     X86_SYNTH(32)) /* REP MOVSB used for m=
emcpy() and alike. */
>   
>   /* Bug words follow the synthetic words. */
>   #define X86_NR_BUG 1
> --- a/xen/arch/x86/memcpy.S
> +++ b/xen/arch/x86/memcpy.S
> @@ -10,7 +10,7 @@ FUNC(memcpy)
>            * precautions were taken).
>            */
>           ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
> -                    STR(rep movsb; RET), X86_FEATURE_ERMS
> +                    STR(rep movsb; RET), X86_FEATURE_XEN_REP_MOVSB
>           rep movsq
>           or      %edx, %ecx
>           jz      1f
> 
> 

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 Sep 25 12:59:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 12:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130505.1470031 (Exim 4.92)
	(envelope-from )
	id 1v1lYk-00089n-G4; Thu, 25 Sep 2025 12:58:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130505.1470031; Thu, 25 Sep 2025 12:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1lYk-00089g-DF; Thu, 25 Sep 2025 12:58:54 +0000
Received: by outflank-mailman (input) for mailman id 1130505;
 Thu, 25 Sep 2025 12:58:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1lYi-00089a-VB
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 12:58:52 +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 62387fd3-9a0f-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 14:58:51 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-b256c8ca246so182570966b.1
 for ; Thu, 25 Sep 2025 05:58: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-b353f86f478sm162128066b.39.2025.09.25.05.58.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 05:58: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: 62387fd3-9a0f-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758805131; x=1759409931; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=o6dI5yisvnmQTqPx86XiW79Jlw8g8mW4bVsbS4Do1S8=;
        b=QtIBeet4OCB02LCSXqfgDmDziyF1S/cyMKcFLxIVkHvnKbnO3vi4CZVu5g7BDblWaz
         46r5N8fEpbdtOSmoqeULXIoBZSsyRzjSebP55LjM0zWVQIVUBlcTfbJFTBoO5WMMXj3L
         IfGhUYfNuaLqW0k9CANCl8+07p8oqHBKYaBZWohMWMwTVGFn+kgy06vcMlQ8+JPzFQnV
         kjNer7b5rHZBAjaGgkoyVuTUMDaI6UfO/GkPy1w1xMQApXzL7nidrwIHOYxdAVk2e+Y5
         qQZr38OlaiQehAK/p0nbkCunsTOAQ8KugjKrSLubI6BN23w36eg0DV/Y/IFUZRuZ/7L9
         PHbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758805131; x=1759409931;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=o6dI5yisvnmQTqPx86XiW79Jlw8g8mW4bVsbS4Do1S8=;
        b=PY5llx1+z5e74Ac7tuA19MoP+BZ7gvWg5SJj/QZ/M5IE9zfpmomS2kv+cqScmtgVr+
         5OlVS4vLGWYEL50swTdn/D/dWe1u3PjI4FDfIcJG4xLDpxDsuSzK4M7S5TOZENv5iFFq
         iZCMpRNKKOKN/hCj2vP9OTwBEeZFumhgOgJ/asefZs5YA85GEuHm6cpwX5b307VOxa1a
         78a9NZ7Z7ZrQqdfCA194/Gmc3Y19ZEcFr7cRa+yb9lD7MAx74z/l8FbkIKFzSB8sAdar
         +/PBLPXJwgSAL98SMVqco27Kx6nwiu8v2fwIPV2sqAMc17zNlplIiEDT4ppGUEV7ziwS
         6vqQ==
X-Forwarded-Encrypted: i=1; AJvYcCU2yWSjlMzIBt8OR4n4kTPew0N29fmgcb3I8Im1zm/ylrpXh/Og6msckj/RBEwPD7LzBeYOZ5uC5Rk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzAeAJRFWvQ29AVQGLmDZDTsaSTPFd70eHXgoOuSa6TvEleBBYg
	KLIQ9mKX9xqOde5QGpw/O1APkQO6ve02AXfY5Ydtrpe3EvxVkBEEpxH9XiE0jmuZSw==
X-Gm-Gg: ASbGncs4cGmX1q0NH38Ici+ZtKmGZ5pTRLseGOalSnMQzqP2Wlttk+tBy/bLD83XEsu
	Q39Is+SnDnGxruCiKVdQSsNRNPFG3vtUiPrU7vCnukwNZvxpBSSdIPxp3GWt2ryQwIVVe08HiUn
	Iinj6j/5bBl0BAQj2EIPcHV0uIYRKAtTuRgbF642z6bCwVfiU+Jsacocea1JhoYn7yhwXxj1G7T
	mIgn3myF9wR9NLM8wYumbxnFPQKhdowgAS2C8MtBNaeCvQPcGsVE4RgCtIS8lFAvRxrA42Eu0A6
	Vxg8cHIjnI9lGzExt9sbAeFwlovsmBlDv39UGFAO//9WGtiU6niWTXHqIG8btmCgRKax8PEcmaK
	mT2FfBI1Rds6zrai/tu5yxgXY3C7MeIw1US8RW70FNMEmuPS8FyRULeGqhWmrFIHCPwvyYNt5yd
	OAFFnHwJc=
X-Google-Smtp-Source: AGHT+IExMvGCmJOJ6D0XNS07MRffiRvQdhPyELUfDztBhs28uoshG+Y39+3MNJO8FBiamtsR1daHQw==
X-Received: by 2002:a17:907:3f1c:b0:b04:3f35:9761 with SMTP id a640c23a62f3a-b34ba147a6bmr309492666b.1.1758805130756;
        Thu, 25 Sep 2025 05:58:50 -0700 (PDT)
Message-ID: <446909d8-f446-42f0-a236-47d5d64ea908@suse.com>
Date: Thu, 25 Sep 2025 14:58:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21 1/2] x86/AMD: avoid REP MOVSB for Zen3/4
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko , xen-devel@lists.xenproject.org
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com>
 <6bcaa5b7-4e34-40c9-85e6-48a0a5869b86@suse.com>
 <485889ed-2820-4bb3-b450-88553dbb719e@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: <485889ed-2820-4bb3-b450-88553dbb719e@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.09.2025 14:18, Teddy Astie wrote:
> Le 25/09/2025 à 12:48, Jan Beulich a écrit :
>> Along with Zen2 (which doesn't expose ERMS), both families reportedly
>> suffer from sub-optimal aliasing detection when deciding whether REP MOVSB
>> can actually be carried out the accelerated way. Therefore we want to
>> avoid its use in the common case (memset(), copy_page_hot()).
> 
> s/memset/memcpy (memset probably uses rep stosb which is not affected IIUC)

Oops, yes.

>> Reported-by: Andrew Cooper 
>> Signed-off-by: Jan Beulich 
>> ---
>> Question is whether merely avoiding REP MOVSB (but not REP MOVSQ) is going
>> to be good enough.
> 
> This probably wants to be checked with benchmarks of rep movsb vs rep 
> movsq+b (current non-ERMS algorithm). If the issue also occurs with rep 
> movsq, it may be preferable to keep rep movsb even considering this issue.

Why? Then REP MOVSB is 8 times slower than REP MOVSQ.

>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -1386,6 +1386,10 @@ static void cf_check init_amd(struct cpu
>>   
>>   	check_syscfg_dram_mod_en();
>>   
>> +	if (c == &boot_cpu_data && cpu_has(c, X86_FEATURE_ERMS)
>> +	    && c->family != 0x19 /* Zen3/4 */)
>> +		setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
>> +
> 
> May it be fixed through a (future ?) microcode update, especially since 
> rep movs is microcoded on these archs ?

I don't know, but I also don't expect that to happen.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 13:17:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 13:17:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130521.1470041 (Exim 4.92)
	(envelope-from )
	id 1v1lr4-0002YY-Uw; Thu, 25 Sep 2025 13:17:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130521.1470041; Thu, 25 Sep 2025 13:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1lr4-0002YR-R0; Thu, 25 Sep 2025 13:17:50 +0000
Received: by outflank-mailman (input) for mailman id 1130521;
 Thu, 25 Sep 2025 13:17: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 1v1lr3-0002YL-7N
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 13:17:49 +0000
Received: from CO1PR03CU002.outbound.protection.outlook.com
 (mail-westus2azlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c005::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 068b62e4-9a12-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 15:17:47 +0200 (CEST)
Received: from SA1P222CA0015.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:22c::33)
 by PH8PR12MB7157.namprd12.prod.outlook.com (2603:10b6:510:22b::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 13:17:41 +0000
Received: from SN1PEPF0002529D.namprd05.prod.outlook.com
 (2603:10b6:806:22c:cafe::6a) by SA1P222CA0015.outlook.office365.com
 (2603:10b6:806:22c::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.22 via Frontend Transport; Thu,
 25 Sep 2025 13:17:41 +0000
Received: from satlexmb08.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Thu, 25 Sep 2025 13:17:40 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 25 Sep
 2025 06:17:39 -0700
Received: from [10.71.195.192] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Thu, 25 Sep 2025 06:17:38 -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: 068b62e4-9a12-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GQvNkfEVr19tGpC0LSPYpNn5JBF/RwaXF1plVP0luBDn/XYNmFFAEQPboNQU1PH+WEwkaLFWG6hO7uHDKHBc9pBlh58j8dRORt+niSAG87Pf8xtzmRPh3LrcujZP1JwuZSKUeOccP4RrOEzWeLqUXkZ+CxvefTRz0wuewVLUkOmrGB1HJkj+bl1pgCUJPpTfjyKAOwYuvER2sGO37LlCjRVEQi0L5ZcVmyGCimn1k6uZKc8/DlZUTRgTpjZ3Y3zXI7tkynMCmDTy7FCgNETnTImqysZMnyjUl5QVDbz07SmrmUhEfowy0ZJobaFmUYtIqFkfbI7mS0LOg2skqu+OoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=86drkz1ZF5qoikkRw7605ruVIVQHB6U9CrJXiDuFzgU=;
 b=zBoq4cnjB5s5SFjtFzSzIn8r9uTIwVkeuyt6kWBsRqtth+N8NyfIsLz8ptIeOjRfvV3Xdp7wq25FwVTj8VtVnXXXcl3LhjMcFmzjA4Mdqy6RhqbCeDRWr08H1+AUEbv3Y/dTqE0uRm5+21wIzNvdUVx+cL2V8nR6wzKWaznGfZxqvpxIOklL6phaE4VvzswsYUBe+t3algHGYwVr9gy/5Co8J2ZDCneBDEOM8+zgIxccqq+9qRjceKOiKXHHCzOBbW3mnTlBexJwdjvRbVHU3A0G3Yfm0pTkyDj2ItxFcb4knOA8qpvqSihnzquMCMgtJicawb32bK4KIXR3nabpGw==
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=86drkz1ZF5qoikkRw7605ruVIVQHB6U9CrJXiDuFzgU=;
 b=RhvSxb2Iv38D87O1hA3EgI+JG3irnlGa4S1/BXRvqLoNyq7zYS4j/5Emp5sAYmJL4GZ9gkoKA+EAJPooRB3zeoE/N8RYa9+vPZrORsPbRX5+mW0dLVgaL2eZrfV1P9qhS4NiRC/dpjuCgVEdsauNL0H8Tbtc9OJ1T5ThymCTMvg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <7d8964c9-6de6-4d90-af47-17fa55463cdf@amd.com>
Date: Thu, 25 Sep 2025 14:17:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
Content-Language: en-GB
To: Julien Grall , Ayan Kumar Halder
	, 
CC: Stefano Stabellini , Michal Orzel
	, Bertrand Marquis ,
	Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
 <7bbd581f-bfa4-444e-9c76-bcb833a2ec74@xen.org>
 
 <7afc0bde-062d-4606-8a99-b57abf953710@xen.org>
From: Ayan Kumar Halder 
In-Reply-To: <7afc0bde-062d-4606-8a99-b57abf953710@xen.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002529D:EE_|PH8PR12MB7157:EE_
X-MS-Office365-Filtering-Correlation-Id: 66b8b399-5a92-41dc-c4bc-08ddfc35e793
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RHE1QmtHQWtnbERpcTZmV3hYQUxVai91cW5iUGVUVkttVXhibFBqTTNxa0ZV?=
 =?utf-8?B?SHdLTDIxcXRUSXRmeDZCeU5oUStFZ1pHQkc1eE5jeWtNWDE5WjJtOVJDbnZm?=
 =?utf-8?B?Rm1JVkZOL0dsUlpOdnEzN1FYQlhTdkJnc1NZLzBEbC8zV3hTVmQ4VzFHamdQ?=
 =?utf-8?B?b01qZ0I0ejY1bWUrUC9FYi9wdUVLYkp4N3JWTEx1UlVkWUY2YUFNdHUzV09F?=
 =?utf-8?B?L29YZHpoVUJyQ3JFdjN3TjRwZnJwZ2FabTlDU0dGaDZRUjMveHhWQmxCMVUy?=
 =?utf-8?B?bzdHMWFFcjN4ZmgxKzFic2c4SzNXNE0vTXFNU056dTNCOWEzTitGK2VzSld4?=
 =?utf-8?B?UEUrblIvSG5zWUIzSXB6T0ZQTzA3OHdGQjZaQkhQeEp5K2szbm9NM0lwcGdZ?=
 =?utf-8?B?dXBPM1lMaGlxRlROMDd0VWdFWmhqejJZd3lzSlZ6TUFVOVZPTlU5UEZacURI?=
 =?utf-8?B?L2ltdEV2ckgwN1ppSWRnRGNrb1dVcEVOWU5iUndvVmxBTm9KczJMYS9tWXVE?=
 =?utf-8?B?aXkxY2FhbHdOZy9WUzUrUGRLTXd4OFFhZ0Z6eTNUMW9WSFRCenltOVNLU254?=
 =?utf-8?B?cjVzeFgxb0xLUzhhajhDaWlhMUx0UHJ6WHRnNmVzSzVUR2JMQkZocWozbVhs?=
 =?utf-8?B?Z3ZXYzV3Q1Fsbzg4OVhLVGpFampvbnRNZldIeHhNOWtIeERhbUNMN29KY1RD?=
 =?utf-8?B?YzB5bHIwazNpUitTb3RUaDBVTElMb1N3NW10QWtHa0hHeHlocUIwVDM5U003?=
 =?utf-8?B?elJyUDlFVVZxRklWYnBxeVJ1U045M1JVQVdaL1JJUjg1SUVrK1JMOGI0MnE5?=
 =?utf-8?B?QTUrRmt0cUx4QUZQZEs5cWkzYlVod3gySCtheHF2OEJTbVF3R2RTNkQ2ZzJ3?=
 =?utf-8?B?VUFlMHcxditmOEJEa1V0ekdKMTVuTTQzWTFDN2gzWlRBaUxSQjBRdGdLckQy?=
 =?utf-8?B?VCs2S2VWUUhGNDYxQWwvTFN5NXR4R3JvWVJDRG9xcjJpR1VvT2cwb0ppNWdV?=
 =?utf-8?B?aE0xRXVWWDE5VXVZZXZrTDFvaGx5UCt2emhzcnJWYjFIM21SWlRMQmhzNTNa?=
 =?utf-8?B?UXR5VGh2QnY2bFRhcWdGcFBrM0pJL3ZrSUdOYkpZaVZhMjhkOGF1UytXNlBr?=
 =?utf-8?B?WU51Qis2ZWFXY1NqaFVrZTk4QUJJM01HN3o2Um5ObEhWRVV6djFaR2NJdEdn?=
 =?utf-8?B?ZUYrcmJUZ0d4M1ZNZWpoNVhGMzR1bTQ2K0x1anE1NERYL1E5bi9OcUVjVFlD?=
 =?utf-8?B?SVpTNWJKQkFHOHZ1OG9DUGliWENwKzhyTURvUm5ZWmFpMWNJNm5pSXpKRmtp?=
 =?utf-8?B?QmtyS2xvNTk4eC80ak95NmlSUU4yaUQ3akVUU21IY0s5bHA0NXV2UEtYei9O?=
 =?utf-8?B?M2tNOWpaSFBVMURWeGE3L0k0b0ozYnBLZXlnekVjNlQ3dlhIcGZ2VXBrTG1Y?=
 =?utf-8?B?NHo4VWR1bEpLT2hDVkdCZTBreHRyaEljaW9KaWVIc2F3RXRPQzdvTFhiY1c2?=
 =?utf-8?B?TTlScWk2eTRNcGVDaW1BaGhIUHlCd2crRmZ6Ylo3SFZhYXlyV01RenVpcFNh?=
 =?utf-8?B?L09vdWNlZHRyZnp6WHJ1N25DejlFc3k5SWlsdWNneWRYSU9TUm1ZTWVBYlBX?=
 =?utf-8?B?UlcvNWllQ1lONUFrMVlreEd1djk4R2g4U2hGUlF4OHhUU2pTM2JWZ2xvQ1kw?=
 =?utf-8?B?NkVDZzl3SHZZRTFVcTljM0JVMnVrSmI4UFBHS1YwU0xBWTBRU2Z3WUFaRDNv?=
 =?utf-8?B?K0NyUGdwYU1IenJ6L2M1VXhrNzUrT0FqYk9LT1dScCtYa0ZHZFNZSk1oTklL?=
 =?utf-8?B?VGwvRDhabkZ6N2hPd0ZIZVN1bHNqN2R0ckVWVlhvMHFiWHV0VEhSalYwZnkw?=
 =?utf-8?B?RjR0ais3aWtFaW1tdTFXaXdSTnpnb2tPdGgrYXA5T25xYWFkQXdNOGhzdjds?=
 =?utf-8?B?YWtacVNPblhySDFxYk5DUkFLcFpSbmJhVEJWR2RlUUphOWNET3JCVDhWYnlJ?=
 =?utf-8?B?QjlzUmNPTlQwK0x5dDM4aDhUK2xhOGtRb0EwY01HV3BxSTdsdmtPYXJubDJt?=
 =?utf-8?Q?PHZk4x?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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: 25 Sep 2025 13:17:40.4562
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 66b8b399-5a92-41dc-c4bc-08ddfc35e793
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002529D.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7157


On 22/09/2025 18:22, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
>
> On 22/09/2025 17:40, Ayan Kumar Halder wrote:
>>
>> On 15/09/2025 12:14, Julien Grall wrote:
>>> Hi Ayan,
>> Hi Julien,
>>>
>>> On 12/09/2025 18:00, Ayan Kumar Halder wrote:
>>>> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
>>>> Test that Xen is able to generate SGIs.
>>>>
>>>> Signed-off-by: Ayan Kumar Halder 
>>>> ---
>>>> One of the aim of functional safety is to test hw/sw interface. 
>>>> This means that
>>>> Xen is able to configure the hardware correctly for the desired 
>>>> functionalities.
>>>>
>>>> Normally this is tested from the VMs. For eg if a VM is able to 
>>>> receive irq, this
>>>> implies that Xen has configured the GICv3 interface 'correctly'. 
>>>> However this is
>>>> a high level (or integration) test which uses not only the GICv3 
>>>> interface
>>>> between Xen and VM, but the interrupt injection code for Xen to VMs.
>>>>
>>>> We want to have some kind of unit tests to check that Xen is able 
>>>> to receive
>>>> various interrupts, set priorities, etc. Here, we have written unit 
>>>> tests for
>>>> software generated interrupts (SGIs) as example.
>>>>
>>>> These tests are expected to be triggered as Xen boots (right after 
>>>> Xen has
>>>> initialised the GICv3 interface ie gicv3_init(). The aim of this 
>>>> test is to
>>>> check whether Xen can trigger SGIs after gicv3_init() is invoked. 
>>>> If so, we can
>>>> claim that gicv3_init() was done properly to be able to trigger SGIs. 
>>>
>>> To clarify, this only guarantees that the boot CPU can send SGIs to 
>>> self. 
>> Yes, this is the idea.
>>> Secondary CPUs are brought up later and will need their own setup to 
>>> enable SGIs.
>> Yes, we will have separate tests for them.
>>>
>>>> Likewise
>>>> we will have tests to check for priorities, SPIs, etc.
>>>>
>>>> A script will parse the logs and claim that Xen is able to trigger 
>>>> SGIs.
>>>>
>>>>   xen/arch/arm/Kconfig  |  8 ++++++++
>>>>   xen/arch/arm/gic-v3.c |  7 +++++++
>>>>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>>>>   3 files changed, 36 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>> index 950e4452c1..739f99eaa9 100644
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -73,6 +73,14 @@ config GICV3
>>>>         Driver for the ARM Generic Interrupt Controller v3.
>>>>         If unsure, use the default setting.
>>>>   +config GICV3_SELFTEST
>>>> +    bool "GICv3 driver self test"
>>>> +    default n
>>>> +    depends on GICV3
>>>> +    ---help---
>>>> +
>>>> +      Self tests to validate GICV3 driver.
>>>> +
>>>>   config HAS_ITS
>>>>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if 
>>>> UNSUPPORTED
>>>>           depends on GICV3 && !NEW_VGIC && !ARM_32
>>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>>> index 4e6c98bada..eb0c05231c 100644
>>>> --- a/xen/arch/arm/gic-v3.c
>>>> +++ b/xen/arch/arm/gic-v3.c
>>>> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>>>>         gicv3_hyp_init();
>>>>   +#ifdef CONFIG_GICV3_SELFTEST
>>>> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
>>>> +    send_SGI_self(GIC_SGI_DUMP_STATE);
>>>> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
>>>> +    send_SGI_self(GIC_SGI_MAX);
>>>> +#endif
>>>
>>> Looking a the code below, it seems like Xen will not be functional 
>>> after running the selftests? Is this intended? If so, we need to 
>>> stop Xen as soon as possible.
>>
>> Tbh, I didnot realize this with the current test. However you are 
>> correct that for some of these tests, Xen will not be usable. We can 
>> put a while(1) after it completes the tests.
>>
>> Or, I can invoke machine_halt() .
>
> I think it would be better to use machine_halt(). This would tell QEMU 
> to stop and hopefully we don't wait until it timeouts.
Ack. I agree.
>
>>
>> The important bit here is CONFIG_GICV3_SELFTEST cannot be enabled for 
>> normal usage of Xen. IOW, user should not expect Xen to run domains 
>> when this configuration is enabled.
>>
>> They are used to run baremetal tests.
>>
>>>
>>> Also, looking at start_xen(), we call local_irq_enable() a little 
>>> after gicv3_init() is called. So I am a little bit surprised this is 
>>> working?
>>
>> This is working i.e. we are getting interrupts. However, I can put 
>> the test after local_irq_enable() as Xen is expected to terminate 
>> after running the tests.
>
> I don't understand how this is working. Can you check whether the 
> interrupts are unmasked? If yes, it would be good to know who unmasked 
> them because it is not meant to be safe to enable them until the call 
> of local_irq_enable() in start_xen().

Yes, you are correct.

I put a while(1) after local_irq_enable() and then I could see the 
interrupts. Before that, we do not get the SGIs.

This means we should be doing this.

      local_irq_enable();
+
+    mdelay(1); /* to allow some time for interrupts to be received */
+    machine_halt();

I will think of something to avoid ifdef in common code. May be write a 
wrapper for local_irq_enable() which will invoke the GICv3 self tests.

- Ayan

>
> Cheers,
>


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 13:26:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 13:26:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130544.1470050 (Exim 4.92)
	(envelope-from )
	id 1v1lyr-0004Bc-Qp; Thu, 25 Sep 2025 13:25:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130544.1470050; Thu, 25 Sep 2025 13: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 1v1lyr-0004BV-OH; Thu, 25 Sep 2025 13:25:53 +0000
Received: by outflank-mailman (input) for mailman id 1130544;
 Thu, 25 Sep 2025 13:25: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 1v1lyq-0004BP-3L
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 13:25: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 27928e26-9a13-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 15:25:50 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b28e1b87aa7so150259266b.3
 for ; Thu, 25 Sep 2025 06:25: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
 a640c23a62f3a-b35446f5c36sm167579166b.54.2025.09.25.06.25.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 06:25: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: 27928e26-9a13-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758806750; x=1759411550; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3zygVjSJt3HOEAYXtJDeUJse47jyPQumbp70tWWPRFg=;
        b=TL6qp9LKh50r5gFlTwaI9/fuQd4xOx1prTbvGvDlfDWmVrL6jWACRGE38TmY5FKDLX
         wZz6/MHm8d49HUVJZVYnuVo17NB96kpM7uR7DE07IEBnHY2A1V0BTnX6ivNf+vBFe9jX
         t3QXdWYl1B1ufE9MRoVun+1OPr7Tf4gIIWfDoB8t8vdUw8oLo77190TcSiiu4QgBRmlf
         IhJ20f5hskYsWAFvaCGuvpcZnVmefpkxeSHiThgXsCYpoaCimod+zmNqZRc/YC13iCLU
         XV4SUZmkyALBQuGOgJU7VvxLae9c5IpGiQSVPML6ESE9n4mVSpn5qsx+/SxqDkzguTy6
         kf3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758806750; x=1759411550;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3zygVjSJt3HOEAYXtJDeUJse47jyPQumbp70tWWPRFg=;
        b=gH44AwDx3bF/ruKbDsvkrVr67d+grU9svlgE2yvGREKIG1nbt6Wl60gGWjlRfL0pWq
         PNlkrDPFr4kL//BJmtv4KeXyeTqoUrbazXX+XvsxPbK0gLfhUQ9UaKstHn1ymRLfR6H+
         ErXWtDUq+K1uNOOTc+2yYJJIcV9AdMkj2i2/iMFNODAaDu8MMkQPjWntMVzJ22s3WssD
         Hlreq2sggwmWEIDsuzvtqw+Y5eJAeytCK6uWtWST/mgArxbSp+9tAs4r4px9XA0YlR6g
         b8uS30hgom5QscJlEZLVHUkgJA7mTHxPhcMYhev4JbUmwe/KM/NhYeQFMSqSPGpSx/Ao
         qUqQ==
X-Forwarded-Encrypted: i=1; AJvYcCX9zRb4ceb0CkbtbSbNhXjZPg0YSxgKXQ/+S9nylzzSgZ+kr6DeqvCtQRb5Kepd5b+M0jKIBOkorzY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzUmNEmrjEZ0KJFRnxyue8VJPz8pgNYVkH3oZ9PnaSy3MuRtKB0
	1cnQywtdHVHXvNIlFQsSEzSUU2oRBkp2v1MCE7DyB3XbwNxZajYOPkg6rHs1nn4SiA==
X-Gm-Gg: ASbGncutTbxUFamge6gGJPVDqAKQ4w9Krsil5SJVwgCWehrLaotwYs+61cfJyaDapqL
	7VG7sZeuY+Vbc8wtgQYwIVkin5yavXRDDmxP1JawN335BcCuo+8nilRWRQjduZwvWP4hNngNRt6
	f31HQz1oMxZmhGV+zd3Avj8Ej0PI0QkFJShvyKwHzVyDAm5HsJdY0HZVSmoFZogAGAq4vV1QNLk
	x/kCV+nS0o1LyFj8EjcMgKGZnj8YVevtnJGzhJR94vPiHk/jAs3p/xJyXdYsNtd3FyzTPAfJbGx
	V8nPfAQR8nmDq+50rePcAEjwp2Q4CVIanRjqKwJ8ydDCR/OHWpc6C7Ltan3R+6IzRqtw5OeWYY7
	kOKWwVMOBf7hUlRuqMM4R+VIhM2NT6l3OIaqB2eW/fpYpmNB0vUpvcMFC0JOdvCVK0Pmc9FaeXo
	kcfOFFHkg=
X-Google-Smtp-Source: AGHT+IEnZy9Q6X/ohu3rhj6rh9y7O7A48Oq9+lMskewJV+pvFypwFZ7KDvQ3BNd9LsmjJeCQ10CXxQ==
X-Received: by 2002:a17:907:7e93:b0:b33:a7d6:8b58 with SMTP id a640c23a62f3a-b34baa348f3mr407296466b.16.1758806748690;
        Thu, 25 Sep 2025 06:25:48 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 15:25:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: consider conversion from UL or (void*) to
 function pointer as safe
To: Dmytro Prokopchuk1 
Cc: Nicola Vetrini ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , 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 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>       - Tagged as `safe` for ECLAIR.
>  
>     * - R11.1
> -     - The conversion from a function pointer to unsigned long or (void \*) does
> +     - The conversion from a function pointer to unsigned long or '(void *)' does
>         not lose any information, provided that the target type has enough bits
>         to store it.
>       - Tagged as `safe` for ECLAIR.
>  
> +   * - R11.1
> +     - The conversion from unsigned long or '(void *)' to a function pointer is
> +       safe because it relies on both ABI definitions and compiler implementations
> +       supported by Xen which define consistent and compatible representations
> +       (i.e., having the same size and memory layout) for '(void *)', unsigned
> +       long, and function pointers, enabling safe conversions between these types
> +       without data loss or corruption. The compile-time assertions (BUILD_BUG_ON
> +       macro) is integrated into 'xen/common/version.c' to confirm conversions
> +       compatibility across all target platforms.

As you use (and mean) plural, s/is/are/ ? I also think the "The" at the start
of the sentence wants dropping.

Further, why this very dissimilar wording compared to what's said about
conversions _from_ function pointer types?

And then ...

> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>  #endif /* CONFIG_X86 */
>  }
>  #endif /* BUILD_ID */
> +
> +static void __init __maybe_unused build_assertions(void)
> +{
> +    /*
> +     * To confirm conversion compatibility between unsigned long, (void *)
> +     * and function pointers for all supported architectures.
> +     */
> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
> +}

... I'm unconvinced checking merely the sizes is sufficient. On architectures
involving function descriptors (e.g. ia64) converting in this direction is
safe only if earlier on the value was obtained as the result of a conversion
in the opposite direction (and all of this within a single component, which
of course is guaranteed for Xen).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 13:46:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 13:46:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130562.1470060 (Exim 4.92)
	(envelope-from )
	id 1v1mJ6-000774-DR; Thu, 25 Sep 2025 13:46:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130562.1470060; Thu, 25 Sep 2025 13:46:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1mJ6-00076x-Ak; Thu, 25 Sep 2025 13:46:48 +0000
Received: by outflank-mailman (input) for mailman id 1130562;
 Thu, 25 Sep 2025 13: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 1v1mJ4-00076r-Mj
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 13:46: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 0ef586f7-9a16-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 15:46:38 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b07d4d24d09so192723866b.2
 for ; Thu, 25 Sep 2025 06:46: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
 a640c23a62f3a-b353fb5a6b1sm173858866b.49.2025.09.25.06.46.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 06:46: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: 0ef586f7-9a16-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758807997; x=1759412797; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WfpJy7TlMBMd8hvcVkMmj8g87znN76f6f5pz63Zwsqw=;
        b=KngfsZesObbU8PbUrODccLRTw6075EdZEbZ+Co2MgrL7Fedu9JQif3FE+wgOJ/vSZO
         LI8520D4JIv1nA50DBZU5TE0qPMBdPGoNNI6Vwz51Mtbm6WZ/JqlisONgw+CM1Fmg+oB
         j2BNqHQlq5Igohxg3U5yReKENoOoRN4qtivu0YKxzY2X0PlaGhK9ho8qsKBXNrs/wld5
         gLLFzXFUPgj54lZbUWbjf3lG7qHc/ESlyF3ZTA7CcMX6G68zIZ1FNmgXmC5nvsE6x/J7
         qCYYcX6wpP8WwIvyEgi+UwDyEatOa2SEkH71d2sHBeJJ0vkwf893QZ8bM0l9Yd9PmG96
         6TiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758807997; x=1759412797;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WfpJy7TlMBMd8hvcVkMmj8g87znN76f6f5pz63Zwsqw=;
        b=o4cx7yqKcPEXcjDPoWqPDf4S0MH0L+Qe1GMdCoWQoYlNdcV54DvMVyxFNl9zFNfyMD
         e/hwG8HSLDUmcBkGPaD7iT0AW8lYw8rqt1U24e+ZQu6RATrccQEdfCLL4GOYrYxQuN7w
         +k/3nCarE+z/lsfGBq2cqJXz0bPgbURpCUCI/yxcaIeFCEoEk4QPvXadK25eDdIpA3wl
         VRvBF84Vk0CHrz2eOyTpXx+amZ1tYdA+DCOYCM7Lq+21mjcVA/EBHElRLRi6Uev0370a
         A4GNaSdT3VC4mAaCMYHDCWkehk6sJ3gSiNTsDHrh6+lv0mVgLb4DoRyz3NZEcwCGM8rr
         b4Lg==
X-Forwarded-Encrypted: i=1; AJvYcCWyBJFd020ZQjpzd0Ly0VhP6NBni2zLFzxFf6VGKr7Eye7A8bxwaN/H/ZodRRWVmiCJaszYrCQnD7A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YziZIZF0Lcvy42orcrxJCWRCXyvLKfusgxAjtQiX6c6R3VT9q64
	6VlMi6Q2GVVpENKRozsZH9q3i5irOJnbnpS7wCq5t4jZqxIa/q9tB41nW/ZQICvI/g==
X-Gm-Gg: ASbGnctolB+GfQ4oj3KGo6szdxtXzFAGPjpjJRvnJ692CIJgHG/Lc/Aa1qezPSi/beb
	3YhR71y2V/GZJ8u4N86CC08+CdKzvDZyx/1YVEmrKGQEJsLmSaaitcice/HBMpL0ND7YV5tGJgb
	VSdSnIzT12SyApV5aT9Gvx9FIrZ3RLUypLmzbdhlwoJn2Lpy9kyiUkMCt+99ZMrefJvRtY0JJjz
	d24idQxWKPO4zTF0kOBw7sK99TSONJCqYhwfHLntsRDPtF4wP3+eZaIfF1858+ebLv+NjKXq0D1
	iKELsD+mRDCKmVFYTJ30By32T/u0g+lBgaXe82W49nCpzZlrIuNsv1vQuHM3mDcuhF/o+OgQQOU
	uHt5f3AyyOEusKlXlQWSjb8PbR2oFNnBNCHOqS7G3cNbkh/pbyOApn+e+EgHcelw5N4iXqEhb3b
	dpHHxU804=
X-Google-Smtp-Source: AGHT+IGC/ssWrq/rpfmwSfNJCyCz38yTd5CGp9GTbjTeT7Xz/NlXCafd4PVIBOHw873jafCdrSqskg==
X-Received: by 2002:a17:907:2d26:b0:b07:b50d:df70 with SMTP id a640c23a62f3a-b34bd44061amr380672566b.34.1758807997491;
        Thu, 25 Sep 2025 06:46:37 -0700 (PDT)
Message-ID: 
Date: Thu, 25 Sep 2025 15:46:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/18] xen/riscv: detect and initialize G-stage mode
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: 
 <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
 
 <0c4e446b-abe1-481c-91a6-60a49459b486@gmail.com>
 <9777e972-8ea1-4dfa-bab0-ee7e13f0a0e6@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: <9777e972-8ea1-4dfa-bab0-ee7e13f0a0e6@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.09.2025 17:00, Oleksii Kurochko wrote:
> 
> On 9/24/25 1:31 PM, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/setup.c
>>>> +++ b/xen/arch/riscv/setup.c
>>>> @@ -22,6 +22,7 @@
>>>>   #include 
>>>>   #include 
>>>>   #include 
>>>> +#include 
>>>>   #include 
>>>>   #include 
>>>>   #include 
>>>> @@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>>>   
>>>>       console_init_postirq();
>>>>   
>>>> +    gstage_mode_detect();
>>> I find it odd for something as fine grained as this to be called from top-
>>> level start_xen(). Imo this wants to be a sub-function of whatever does
>>> global paging and/or p2m preparations (or even more generally guest ones).
>> It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
>> when the latter is introduced.
>> Probably, I will move the current patch after p2m_init() is introduced to make
>> gstage_mode_detect() static function.
> 
> Maybe putting gstage_mode_detect() into p2m_init() is not a good idea, since it
> is called during domain creation. I am not sure there is any point in calling
> gstage_mode_detect() each time.
> 
> It seems that gstage_mode_detect() should be called once during physical CPU
> initialization.

Indeed.

> A sub-function (riscv_hart_mm_init()? probably, riscv should be dropped from
> the name) could be added in setup.c and then called in start_xen(), but
> is it really needed a separate sub-function for something that will be called
> once per initialization of pCPU?

Counter question: Is this going to remain the only piece of global init that's
needed for P2M machinery? Right in the next patch you already add vmid_init()
as another top-level call.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 13:53:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 13:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130575.1470071 (Exim 4.92)
	(envelope-from )
	id 1v1mPk-0000G8-3N; Thu, 25 Sep 2025 13:53:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130575.1470071; Thu, 25 Sep 2025 13:53: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 1v1mPj-0000G1-Vc; Thu, 25 Sep 2025 13:53:39 +0000
Received: by outflank-mailman (input) for mailman id 1130575;
 Thu, 25 Sep 2025 13:53: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 1v1mPj-0000Ft-5d
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 13:53:39 +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 09660469-9a17-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 15:53:38 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-b3331adeadbso288761666b.1
 for ; Thu, 25 Sep 2025 06:53: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
 a640c23a62f3a-b35446f74fbsm169349366b.51.2025.09.25.06.53.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 06:53: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: 09660469-9a17-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758808418; x=1759413218; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ad7moKFCCJNMEpHmJMVE/TQCTp5JiBqNPpo6LQlNXhA=;
        b=FjnYNrd69lVtnRutxGC/CnQ1fiW2ZrFNQEDb+RHb+17cw9sDOw8OZMQolxvpF8Fq+X
         EBfZTV3zoAZwWKKgGl5xRi2cWEVjhrqWzwQjRqY36jt2cnLvoq1CbXP5okJdEqCoO2f5
         xBZuI0rLr/91zXqbRNNw0sbnpZVUNa8bmMujJ7tzvy22mSlmOkP9E6UNfFPQTC9QexVM
         5VOEahLyxRY5hfvsVP0JA1v2hRHzY3piGzoNjRwEAdp3x0WB7UFeW1Lr61gtJvhngbIv
         msS6jLbbPcFXSm3h3o4N8f+9yvOpJ/92FPN2v/39itWpO/BG0LM/Zy+1nZG5aluH43Pw
         wVog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758808418; x=1759413218;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ad7moKFCCJNMEpHmJMVE/TQCTp5JiBqNPpo6LQlNXhA=;
        b=nG9ublWkpUZ5MGDAs0OcwLCCLGv9ziN0EI/gTWnN+coLZlx1w7ELihoPsmHd/9oAE2
         8fy/nKnxz2/we6IrVinGVbHX1RqE11bE8jUtuTn8jinss8teRTG2m7va6bJi+cTkpjLb
         +KSiB3ku3oWhHPET+1xoO3Bu66Z01gLH+SYAmFBmpi7xG2GigIhIZ7FM0pxREH60LbZO
         wqqfozDb7W5ZnIYsCkWaqRb3ayDPtWLPPg3hH46VtRCyx5ftw6jWHPtCH392kDmcsP2O
         1qLUl7Qv9ob2QpGZoBKih13BBf2+dRpgXdAT/gLKYMB4KI75nyU9vGu2V7zVWeEhpKzC
         XXrw==
X-Forwarded-Encrypted: i=1; AJvYcCVk0xJm299KmsN/qZM/omK8BBE5BwP6Jxn799/6WmmRPjs9iVMZ2tat8uyHptgTKWq4e9AOOE+Lsmo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzxGQnyF8Ol4GF/30oqEZH24mLhqvx7acgHH4UnjwlcPFtNHnbh
	oWe+QWhGIHnYNxrSFAP23H9PtOJ6sUMdZp+7oN8Uh+mScw7sEnbCnzg0w/s3hTaXyA==
X-Gm-Gg: ASbGncsF9IncFaT12+gS8pqPxWkizE+/5nfwSsaAnBlqQjmph9wCvROgADJhk30Zzik
	NuNYGQtMOAU+Gr4YVRAO7YeQIK8R373ECLtf4jaZTjqYAYIqxIvqkKbGHwd7kNaTkcdwOR95Kqw
	oKi6SmwRlvsiwKfjOdFEaOVxReB15lL5BUeiHSJ73Uk2R6eAFanGtq30W+Vse/ZHlr0gOr5M274
	05ZzZxyLTd0wzhbe/+ZNyAuRGWMraGBKO6cbK1XHwqWyvanDB0AHtWUX446Yl2ZXwABmzWqp8/F
	SN6k3csCPJlQufWH4NdzzSUTaQSQbBv9nrcPN1iKUykG8M1JDIG+JKGiBGOfYmidDBmALmZGbqO
	UlKnJMIPKT2yXs9iVk6kDTBH+MfKy3Zpvj7NNXpp1Kf9rH4ykF1P+x7D795Xx9eC4zFQgStrr6G
	LWGYg5joM=
X-Google-Smtp-Source: AGHT+IHiBHN0SAmPR0OToRUpcXTbPySvE3aJfmw3vQy3eTpHWPp8nx1w+4Gx7z1DkNEEQWJOzh/Uog==
X-Received: by 2002:a17:907:7fa7:b0:afe:159:14b1 with SMTP id a640c23a62f3a-b354a2b1cd5mr301963066b.9.1758808417713;
        Thu, 25 Sep 2025 06:53:37 -0700 (PDT)
Message-ID: <27f9632c-2aa4-4953-b731-9d3c523bff79@suse.com>
Date: Thu, 25 Sep 2025 15:53:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/18] xen/riscv: introduce 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: 
 
 <03c68390-fd9b-443b-a012-2846dda2a923@suse.com>
 <1be98c7f-59ff-4808-957c-daa55d1f441d@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: <1be98c7f-59ff-4808-957c-daa55d1f441d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24.09.2025 16:25, Oleksii Kurochko wrote:
> 
> On 9/19/25 11:26 PM, Jan Beulich wrote:
>> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>>> @@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>>   
>>>       gstage_mode_detect();
>>>   
>>> +    vmid_init();
>> Like for the earlier patch, I'm not convinced this is a function good
>> to call from the top-level start_xen(). The two functions sitting side
>> by side actually demonstrates the scalability issue pretty well.
> 
> In the case of vmid_init(), it could be a good place to call it here since
> vmid_init() is expected to be called once when a pCPU is booted. For the boot
> CPU, all "setup" functions are called in start_xen(), so vmid_init() could
> potentially be called there as well.
> 
> For other (non-boot) CPUs, vmid_init() could be called somewhere in the
> __cpu_up() code or at the CPU’s entry point.

And then perhaps many more functions. This simply doesn't scale well. See
how we have hvm_enable() for the boot CPU part of this, and then
{svm,vmx}_cpu_up() for the secondary CPUs.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 13:56:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 13:56:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130585.1470081 (Exim 4.92)
	(envelope-from )
	id 1v1mSV-0000sc-G5; Thu, 25 Sep 2025 13:56:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130585.1470081; Thu, 25 Sep 2025 13: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 1v1mSV-0000sV-CP; Thu, 25 Sep 2025 13:56:31 +0000
Received: by outflank-mailman (input) for mailman id 1130585;
 Thu, 25 Sep 2025 13: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 1v1mSU-0000sP-Pa
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 13:56:30 +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 6fb7abc4-9a17-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 15:56:29 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-b0787fdb137so168341366b.0
 for ; Thu, 25 Sep 2025 06:56:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353e5d0526sm170866866b.12.2025.09.25.06.56.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 06:56: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: 6fb7abc4-9a17-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758808589; x=1759413389; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=f6aYRcOSIqmRMg8VMGaixy+OhIDN0i7t3lVN3bkr+eg=;
        b=eITo8+0pE/pp93GP+8bsyw0sK/EPCmTu+0f6/nxMlXdEFxU5QwVwwa6LEKRBena6ic
         s8s6eaYzQidTAkuzVcPBip960INN7VpUgnzo4Q1UN+pSmt0mOU1ExcHC7aMy8CpeA/v2
         WNIazcyeCVy2dGeEZK8okx8pxHVYrmHRVCX6Zm3uZOIWMmsT+7Grwsb9Uy4fdRJI6Jgg
         SerTPmbwbpx4EW2Zr77Wbd0IYvh3k6YGYmRfLPeFoc/v97LtNUvb17YfGkE9eV+RFK2m
         G+t52O63/4A0rPHOvFnwgVGnpMi+V8zSTYtiFK9j/kHWR5SpyjH06xFobjDUCeu3NnAc
         yu2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758808589; x=1759413389;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=f6aYRcOSIqmRMg8VMGaixy+OhIDN0i7t3lVN3bkr+eg=;
        b=rylNUZYOiXfWS6ei5paQbw+H2+rX3V+IvHpRx/tyG+oId+Qjs/0b2VZNkzYMgsRpTu
         TyFhHxzoF2D7+DjMBX06Eg3oLSCrBUYdPyEkknXlr55oE3EyMHERVi8lfqy9aAeaIpk4
         XZfOXB3oXGahJ0/BJq9mPyeA8BD9EZuMHP/pUWIWTUB2/zCsXKhkcoKUjELTCtTdNNlo
         r5XOulrlwfhWoprgKc6Ab6FpKAwVw5J7OsIJqaVE9PM9EEQso4+auba3AucjGXAIhIpq
         lIPjK2vds4RG0yhSBholTgTRGVsJlQXN2ebvw4ejs2tzJ4cHlebBULPCUMNuRhpH/2OA
         PUVQ==
X-Forwarded-Encrypted: i=1; AJvYcCV6jA6IQxPeYUuln+inhwz/Hy0vmx7SCpfwulXiCzajBJQ/anl6bhKuyev/JxM8av8XppHQtSc5Fd0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtqriSEYJLFIPG1N3+PoQySj7q10N+P+p0hSig4z+sx3ezGhW/
	UFwKsxlqkt75yzGwBbA/aaz7pypB0IItIXdK/aQXccH+AeWXWR73136/yZxZDnqB9w==
X-Gm-Gg: ASbGncvCFtrsznHq1FWS3V2BI/wons/jQEEkcKDGUQymgwiKcKCsVXmBs5n1WTuNcbv
	3uAZ37fpct0AVQIJJhwt9BKgZQ1aVC7AA4KFV0ktWqzg47wsxzvhqnslped7TVfSUq5Xbt/rfP2
	QYFAHfVeRmCXPDyHLg5kmQtIWN/h7FWxh2a5GWwV+stBYOrg0yFCZC6Q306DkMm/jMPMRZF2VNW
	WfraIS1rM58Jo8iBQ/lQpTSo6htexuuwPOOasOr7Z1enAGFTo8CXk7eLfbxZSGayPDZE8e5Gr+U
	cC/tTOUBN4YQtExzZ80R7i9aSHX3ZtO5zEBDI4+GOqp348ghZKJkWazflrS8FZmBfNIF3/SjSYi
	0KoCpq9jhm3F7A9IYHTJy9NqCLf8q53IIl6XNKSVSUmxw2uehaKeEF4xF8B8BFLHFrE9ByK4uJ9
	lquwhb88c=
X-Google-Smtp-Source: AGHT+IGj6q/wE9SglkIVr9Qo5J4sdy/s3P8+MpRrfv9Znz6HRgo0Md7b6bepGBcafIVvyPpcEhZM9Q==
X-Received: by 2002:a17:906:24cd:b0:b35:6d55:9c10 with SMTP id a640c23a62f3a-b356d55a3bemr249580366b.50.1758808589310;
        Thu, 25 Sep 2025 06:56:29 -0700 (PDT)
Message-ID: <68048d73-b29d-4ef7-982d-bf0c2a179ed6@suse.com>
Date: Thu, 25 Sep 2025 15:56:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/18] 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: 
 <2b636ea03bf82cae50df87d525e3f58b68f16cb2.1758145428.git.oleksii.kurochko@gmail.com>
 
 <31a0e82c-6855-41d3-ad9c-282261012656@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: <31a0e82c-6855-41d3-ad9c-282261012656@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24.09.2025 17:40, Oleksii Kurochko wrote:
> 
> On 9/20/25 12:14 AM, Jan Beulich wrote:
>> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>>
>>> +{
>>> +    return MASK_INSR(mfn_x(page_to_mfn(p2m->root)), HGATP_PPN) |
>>> +           MASK_INSR(gstage_mode, HGATP_MODE_MASK) |
>>> +           MASK_INSR(vmid, HGATP_VMID_MASK);
>>> +}
>>> +
>>> +static int p2m_alloc_root_table(struct p2m_domain *p2m)
>>> +{
>>> +    struct domain *d = p2m->domain;
>>> +    struct page_info *page;
>>> +    int rc;
>>> +
>>> +    /*
>>> +     * Return back P2M_ROOT_PAGES to assure the root table memory is also
>>> +     * accounted against the P2M pool of the domain.
>>> +     */
>>> +    if ( (rc = paging_ret_pages_to_domheap(d, P2M_ROOT_PAGES)) )
>>> +        return rc;
>> I read the "ret" in the name as "return" here. However, ...
>>
>>> +    /*
>>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>>> +     * 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, P2M_ROOT_ORDER, MEMF_no_owner);
>>> +    if ( !page )
>>> +    {
>>> +        /*
>>> +         * If allocation of root table pages fails, the pages acquired above
>>> +         * must be returned to the freelist to maintain proper freelist
>>> +         * balance.
>>> +         */
>>> +        paging_ret_pages_to_freelist(d, P2M_ROOT_PAGES);
>> ... "return" doesn't make sense here, so I wonder what the "ret" here means.
> 
> In both cases,|ret| was supposed to mean/"return"/, since in both cases we
> “return” memory.
> I agree that in the case of|paging_ret_pages_to_freelist()|, the flow is
> slightly different: a page is allocated from the domheap and then added back
> to the freelist. That looks more like/adding/ than/returning/. Still, I felt that
> “return” could also apply here, as the page is being given back.
> 
> For more clarity, do you think it would make sense to rename
> |paging_ret_pages_to_freelist()| to|paging_add_page_to_freelist()|?

In place of "add" I'd perhaps use "refill" and then really refill_from_domheap
to properly indicate the opposite of ret_to_domheap. (For both of these: If
already you want to use such long-ish names.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 14:28:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 14:28:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130611.1470099 (Exim 4.92)
	(envelope-from )
	id 1v1mxR-0005Iy-WC; Thu, 25 Sep 2025 14:28:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130611.1470099; Thu, 25 Sep 2025 14:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1mxR-0005Ir-TH; Thu, 25 Sep 2025 14:28:29 +0000
Received: by outflank-mailman (input) for mailman id 1130611;
 Thu, 25 Sep 2025 14:28:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v1mxQ-0005Ik-S8
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 14:28:28 +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 e6a03707-9a1b-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 16:28:27 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-631845b51e2so1213362a12.3
 for ; Thu, 25 Sep 2025 07:28:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b35446f76a9sm176160866b.60.2025.09.25.07.28.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 07:28: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: e6a03707-9a1b-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758810507; x=1759415307; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=POSxx/CzD6aDdQqQY9sJI3SYM4DNPaqNJIL9XBTXcmE=;
        b=cHtije0YqoJwS0CUj1uV0Y9dFU505k/8ecKSxMVWCp5Q2aU443b3eZ6/+CmHU4P441
         WWc/xayveszbmqXjtck5kQvDXkglgFGJ3hXbiHqL71USHLyrAuMIBXHprONVo9etfIPV
         UQvtc0agUmIxXsz4EEhqTwb92miKbsRy2vOIg6YkFQ6sWYHKP54VkdsvuU6lWL/glZVZ
         dbYmK2g6I8nw3Mv+AZfm+JhuQdI60OExRdLTpHUxP4+DdfXAl8XSiQqM+iP/XIRfqc4w
         V/vmwIMIAzyXR0MFIWWZbJ6ZAOCcd46ZqFfIXB2R4sK/z4DdlQMOv8oK7h8s+VuMlLND
         IA4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758810507; x=1759415307;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=POSxx/CzD6aDdQqQY9sJI3SYM4DNPaqNJIL9XBTXcmE=;
        b=ju5xRh+K3YPNzkuymuz1Qp8BTAZzoDhFEOlWC2mO7Uzx6p+qjz0ZLcRY/zYqzOKQNW
         za5M42b/4MpW6B9xjzBihF1sawi+CzA6ZtaMkMbDutnqg690fkHdGSUxz2xEhc2I7CjT
         fptrJ7lfa5ZgvHwpyE8ExnKYdODUyw6220Hev+GSHioXkNZMVoIosYE0LCR0rU5I4XAG
         Sd0SFZ3co6qS/Ac5yiruGMA8thcaOXqm5s+rU2yRc2cZ26mzRX5NQ68OOebx4KImMY7r
         14r/59Tl0AL9bK9gPRrW8KBa9hdsvqcFG96TLjPHBXsmwjTUgok8ELC6v5R/qt9E25tX
         HpcA==
X-Forwarded-Encrypted: i=1; AJvYcCX5XbzkmpvKtARr/45ql0PwEg1cbgl6Hb/2MzaL5+GmxEX+w8hVhWqRGn6B7znHR2qvT8/xTDFVa4o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGimjrkdeComJ/NbmJlb1B11AzMFLnfRZIpXSKS7dVVSVaZM5A
	Sih5H8Q2W5W/QxCtB7pEILbiZZt/0nQblNjpW0p9JT0XCsahwGOZnepuh6YP0gartA==
X-Gm-Gg: ASbGncvECz08eWsdtSKycGiFsGv8v/GelppTlgGVyixzTX+dc77N2oJGomneR1ZMqCD
	D5aCcnZMyKNafX9SofrxM6Uzzr2fz4ejeXKIKSP41PhcbeBkfOqXiHHOABoWKVw6OKJbkgLOa5v
	aHaqi0ph6EGtHF1yPlGhKP0igDmkmhsFfr0TEvQp3aL1IDl6QWYrlqZra5DJKPg4PBia3poybNU
	UT2U2y4xqIxOfQemzPUkasbiliAJTmAt3XKWj3RJIEu+K/j4fCU0PVlql71znzjsNZcm4/EVtA8
	eTb1b+tvFueHeJlMwjbLWcDLCc219NEom2GkHpidhyMO9/z5D25PSzkj0nMHwvQM1h6B9D4g1OS
	1Tu63WfkJ3kMxZdW3gV3haQUdBVfZWrfBScYNcsjfaALhWbU01DLudMW+Arw7JhhE6Zo43hzvQg
	vQbFMTmWE=
X-Google-Smtp-Source: AGHT+IFSddq+yuJQaYFPWt7nYRUWeLSXrotuLshcfLfixA6lP2Hg4AE780jEMo+FeSm7LJmvaRKmlA==
X-Received: by 2002:a17:906:5a4d:b0:b0e:8cd4:e2d3 with SMTP id a640c23a62f3a-b3503555d83mr279615866b.19.1758810506697;
        Thu, 25 Sep 2025 07:28:26 -0700 (PDT)
Message-ID: <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@suse.com>
Date: Thu, 25 Sep 2025 16:28:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" ,
 "Andryuk, Jason" ,
 "Stabellini, Stefano" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.09.2025 11:41, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, September 11, 2025 9:30 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Daniel P. Smith
>> ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
>> CONFIG_MGMT_HYPERCALLS
>>
>> On 10.09.2025 09:38, Penny Zheng wrote:
>>> --- a/xen/include/xsm/xsm.h
>>> +++ b/xen/include/xsm/xsm.h
>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>      void (*security_domaininfo)(struct domain *d,
>>>                                  struct xen_domctl_getdomaininfo *info);
>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
>>> -    int (*getdomaininfo)(struct domain *d);
>>>  #ifdef CONFIG_MGMT_HYPERCALLS
>>> +    int (*getdomaininfo)(struct domain *d);
>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
>>>      int (*sysctl_scheduler_op)(int op);
>>>      int (*set_target)(struct domain *d, struct domain *e); @@ -234,7
>>> +234,11 @@ static inline int xsm_domain_create(
>>>
>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct domain
>>> *d)  {
>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>      return alternative_call(xsm_ops.getdomaininfo, d);
>>> +#else
>>> +    return -EOPNOTSUPP;
>>> +#endif
>>>  }
>>
>> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl is hence
>> already broken with the earlier series. Now the domctl is also being screwed up. I
>> don't think MGMT_HYPERCALLS really ought to extend to any operations available
>> to other than the core toolstack. That's the Xenstore ones here, but also the ones
>> used by qemu (whether run in Dom0 or a stubdom).
> 
> Maybe not only limited to the core toolstack. In dom0less/hyperlaunched scenarios, hypercalls are strictly limited. QEMU is also limited to pvh machine type and with very restricted functionality(, only acting as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly and thoroughly about our scenario here for upstream?
> Tracking the codes, if Xenstore is created as a stub domain, it requires getdomaininfo-domctl to acquire related info.  Sorry, I haven't found how it was called in QEMU...

It's not "it"; it's different ones. First and foremost I was thinking of
 * XEN_DOMCTL_ioport_mapping
 * XEN_DOMCTL_memory_mapping
 * XEN_DOMCTL_bind_pt_irq
 * XEN_DOMCTL_unbind_pt_irq
but there may be others (albeit per the dummy xsm_domctl() this is the full
set). As a general criteria, anything using XSM_DM_PRIV checking can in
principle be called by qemu.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 14:56:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 14:56:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130631.1470108 (Exim 4.92)
	(envelope-from )
	id 1v1nOd-0000nO-SF; Thu, 25 Sep 2025 14:56:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130631.1470108; Thu, 25 Sep 2025 14: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 1v1nOd-0000nH-Ph; Thu, 25 Sep 2025 14:56:35 +0000
Received: by outflank-mailman (input) for mailman id 1130631;
 Thu, 25 Sep 2025 14:56: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 1v1nOc-0000nB-F0
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 14:56: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 d0ee41f3-9a1f-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 16:56:29 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DBBPR03MB10413.eurprd03.prod.outlook.com (2603:10a6:10:52e::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Thu, 25 Sep
 2025 14:56: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%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 14:56: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: d0ee41f3-9a1f-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BBlVll8drYavLzFXW8fAiJE0GQwPEjCuw15QrLBU/EGnUCFU/IrM+do1+2d0GTuxtO6uNv+gQrhocC4O6KJIqlHqoluZ+BcwcMbb+5izU6GA403VEwh0rcFBw6xAtrIwmzG01g03aFiVzCGPiYR6wbl9yrXBRIEz+dNRto0Uzd/Lhd2NRTcQVvn7xp2FiFgTzr+YIwJJU2F2OA51W6yd9MvtHqH17071iUbJjhzBhV2kp/Y364OV55K72koRarO0/paWWl7WVnKQc0x+tgiR7JjCgswjk9kfqYXSRsJ/qi9qoKfoZOspzbW9NWKgQB50b3OTyKmTfZNHKiqP1mPUfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n5oC2vy5mX8U9cZ4g5E3ajLBRuHTbUitpl+oGK5+iJ0=;
 b=NX74nu4lsV1zXx2NLgFxLLku9da4w3JTdmCil3HfnRjDRMyeOvSdpEN9di+wa7PDBnJnSCJVlWwjHz1mvr8RfpI5/YlkXVglyINiqf8jBd0+Xt7lbt4BqtshRfu3Rdj7bu8Cqus97UKYAM11H17PxMfi1xRWLRYH13prrlxzaMdmur3Fu2s+yIo0Q0uXstNlFn8YznvvKTuB2mANdfcgEVibK2zxVWM3YN/4mR5jUcuiG0l3i5lBzG5EwWh34Qb90Rq58LfhmCUZAe4swNl4waNUrXwugW1TBq2KUGwyuEZoo2LOJzRmu1OvLck2sOFYD2iyPDi05fmKvnsZW1OgAw==
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=n5oC2vy5mX8U9cZ4g5E3ajLBRuHTbUitpl+oGK5+iJ0=;
 b=oKrNQlYMTU6haklBQ0NSXVnZzt8I+4hJpDz+IQcNHVxJPh1ZSHtD6j/Tl6IQe5CZyhKxrYDhhageo/1g20FKoQqA60cxRcdN8+P7F1jWdviMging69kvMgNwrkxPIQPvdkGoh/Wrg0Oy7/VW0rVFTvHo5jLKLmiqkrJOKVZSR1ihP8vqelES7ZEDZxwtv+Te+dP8UlyZFBG+ik8R05YVJTglU4hGpCDRRCZK0BmHkTZUy9euDiAnwMEne1bVfsj8miM5bAMsV2aFNs55/IzLVb2Bs0c3m1qs3B2iIDmEFRnn4vmj3Prfv2GjMjlu3/MS3yTxpx9xxDuQGbgjZ4S+8g==
From: Oleksii Moisieiev 
To: "xen-devel@lists.xenproject.org" 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Julien Grall , Michal Orzel
	, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Oleksii Moisieiev
	
Subject: [PATCH v4] xen/arm, xen/common: Add Kconfig option to control Dom0
 boot
Thread-Topic: [PATCH v4] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Index: AQHcLiyQ3fkFbkmvJUapaW4Nz2vAhw==
Date: Thu, 25 Sep 2025 14:56:25 +0000
Message-ID:
 <90d39f2050e6028a2fce494381ad0df76f49e541.1758812103.git.oleksii_moisieiev@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|DBBPR03MB10413:EE_
x-ms-office365-filtering-correlation-id: 19aa59ee-5114-4f6a-975b-08ddfc43b361
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?C154c+df67WzqnnAaPp2QcITYeTrR562RADajI2ehBZc/pCq14rG3d8sZQ?=
 =?iso-8859-1?Q?TUUX92P+DaZvXlnhWNPDlE5OO/5LjOeRf3phdMmvTM8Ksu4auaKzLcEsra?=
 =?iso-8859-1?Q?82vTroPVsGm/L4goUVaAPznhg7z8HdKKJ9846I+TveB3Q4qYvjpqB/R9rc?=
 =?iso-8859-1?Q?+JWZxrX4B4KlgpMmZp0oB+YFdnvQMgktRg38TSEvRNYCooNrX0aicLlITS?=
 =?iso-8859-1?Q?LySy+gGi45osHkVY715LiC50QxUWiqtqVZNyjp/Wz4HLPqfW4XTelPF6PM?=
 =?iso-8859-1?Q?n+CFsnpk0MwLhZ5oIJ8yA5USiRL9C1sIyVEsKYkBsPHHAuDifAim1fhp/c?=
 =?iso-8859-1?Q?qmHCbNDFQl8haEvqAxJRtfCGaYDvVcDdiKaXc47MP7jfZiNSRJt9xnF983?=
 =?iso-8859-1?Q?XFSNSjL9gJbPtLKtwcfIloDxO5aCA/tEGrlu04QNxLnk6XLLkXkRgUq5c9?=
 =?iso-8859-1?Q?/mhkuguUYiNUOWNDvk8tRj6extAfJZyiJhnYhgMG/pS+P2kHq3XcVln2Dg?=
 =?iso-8859-1?Q?x3jU1Xd19/m2AWWauceX9LqLby+juCw9SDeAww1SL23yVuG03epY+cU9B1?=
 =?iso-8859-1?Q?2+0KoQlu+1IPdV9x48i3Ary3dvykddYJ7PfiXeJSEc9PE9p8nTxsOGzhlJ?=
 =?iso-8859-1?Q?B3m9geJA6YZUhi5tmKFrfsm1be+HI7u6t48t3L/Yp8p9fjtJfgBSaIl0LN?=
 =?iso-8859-1?Q?wSQh+7SEQjzwBZscvU8R0mLz9IoDJHaAKbGF5AoxHJXxblOlnkfUVjwGna?=
 =?iso-8859-1?Q?9i19YqnvOnP9Tyeq3iby1aYwcW70AbYheg7fbjS1VgHWuLkFZjaXIzofNM?=
 =?iso-8859-1?Q?vaIaQ8bq/EIiW4NGz8phsL8FCUu3qIhUSGjWxQ3DLrGC2UJujRE0PM4D1J?=
 =?iso-8859-1?Q?xW9u5PgPTwR9jDFOthIIdmCKwEPI8MC+ud74r6ajK4qH2by3lJOG3lw3UB?=
 =?iso-8859-1?Q?mV8fTNESz6EauqbtpKHaQSqwBAt9rOvHSpFGTJta4tNPh23q6RBk2kpdZX?=
 =?iso-8859-1?Q?oNri70a4I4TAsY0/u+QrECjUsh04Syrnl0ouSwxD5oC0RROe6hJ8vCdu87?=
 =?iso-8859-1?Q?sE+84EF6z4zldxVPUZU4eF7mL/2ai3i/g5lWKfYE0tLyM4PrlYavPDUAag?=
 =?iso-8859-1?Q?HIT0H2JblulcbgR28YpqmnUj5mQb6I6CcBTZoZO6omCtmx/gv6L+cELPLX?=
 =?iso-8859-1?Q?ywdlWn1U2SnS/ET+IrcmfBvJiB1EZRnSTFmhPWwAwiPJfdzJ9n4WsVoWzp?=
 =?iso-8859-1?Q?usa/SH5SqiMLCn2mm8ljZO4uHrYnHE6ASvIInjevdkyJi0S4QWFbX33bvB?=
 =?iso-8859-1?Q?YzkUwE3xH/0SMl1vyRHW06DJdBD9wg8s4BjnHNsCCfjf0ZZNccaxcfD5rr?=
 =?iso-8859-1?Q?hTdsplBZmxEVUy86NIMKBDnxIyCtGiTs67TOfCppwIPScQNRCDmDyqS4H3?=
 =?iso-8859-1?Q?fpPx76HOs4Xyd1l9CIR4HCotlUJmkX4UqIK9Z7BCR41ly75SdX5ojNm9JR?=
 =?iso-8859-1?Q?A9NBsiY9i9lrkd+q/P+wYfQHtAlZ69l3cRsDA64vZKjiPLF+W2dnAgCAhD?=
 =?iso-8859-1?Q?39KDZcM=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)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?unj9PGgthznzvE72eV9cPhhl9F1tzCf+llf4HFEjQCqTp7zFlgPCdlhArx?=
 =?iso-8859-1?Q?4TVsQB90C1Lxotp5oV5tegW8UCq3+gCDW95KZ1U1DaTPrRGGjnY8Ej+bil?=
 =?iso-8859-1?Q?uY+RIHdafMcERdMK8bHVkMO4hyr8Or9k0DT3Qd8DDwChNgXN3pOKXLYucv?=
 =?iso-8859-1?Q?9EQiI7bRHd6jpdy/fcHYh4aLL8Wcctv0K1XtB1KABojcV2+cHP7glgGtPi?=
 =?iso-8859-1?Q?eD9dDxFK1i4igFqEVJFrJ/4pA9teNnbkSkIxBznGm+41bNvQo0wGQCJgqg?=
 =?iso-8859-1?Q?aZ1rR9YcE9G0LNWW23uZAXaQUBqXN1tT/RTHX08OW6hM++J4znJmVCnmMu?=
 =?iso-8859-1?Q?gA+tt80jRKTlCbTpgY9l7nf3Ap2KS4LHRTYU7jXhtv+ckm/p1nLOhlpukp?=
 =?iso-8859-1?Q?Hc8+fMGOu90s9km9Yk7Y/ZY6Y5ZUoKe+f17HhgFfgEYn9AHElDvRVWFMxG?=
 =?iso-8859-1?Q?PPMowI5KxoPKMDb4dDDi1dsVHB8HI82L2vIonQxqBrpb03BzuxlVhrvYpk?=
 =?iso-8859-1?Q?TH75ngWLxw1m6Nog91Zk32lF95w8iVfK0wU1elpdxkO8rUztht1SP6HVo/?=
 =?iso-8859-1?Q?TZt2mnSZ4XQ583eeWtumCt0XCcOjQOG9fSvf6xBO7AflW9LHSu0ts5gA4r?=
 =?iso-8859-1?Q?HrxjKgnxc/y+02bU1ndB3pu5Y2mGgysKL4DhIdZGg14gnQnw9xaeJfjG0N?=
 =?iso-8859-1?Q?KfxAApMTH+oVBVWskpxiFRMkm9x4P3lGMnwZou1Xadt0hapg/J2IxWkD3h?=
 =?iso-8859-1?Q?H5QjNBLsKsVeBo+iWeMaUrvjgdch1oblbphRrySqxKNNktfMsqXqKST4WY?=
 =?iso-8859-1?Q?mh7F8ombKYcXWgXc5RBpzAsDGCZn87+cK4fQ3KEPOcxw58bytni4/7hTlo?=
 =?iso-8859-1?Q?f6Gqx7SjCo0i1hLTiM35dnNOE6PcLaDQG8M+1/5Rc8ZwrOKPgiCqQgjhhC?=
 =?iso-8859-1?Q?UI/u3P86s8rK+YaYbZR4/St/9wBFwNAgIpSh0IMJOdIMmfeeS9laT3+iRt?=
 =?iso-8859-1?Q?QfCaSY1wYvgJsqVHm5is/FJtO5aSJVHRR15eITlk90EmgHULvuOp38yi7A?=
 =?iso-8859-1?Q?IHX3L5C7RGLhoU3YOp2CjmvgbXh7jwkI8p6JHpudGMChwSFd6rKJ8Ds/w1?=
 =?iso-8859-1?Q?6d6RqtwM6dHfEwBNwbWX5bHweLwutpsWkdtfiIhh3ozQ9yvlqWHwFMA7Zm?=
 =?iso-8859-1?Q?1pwOS7LNZ3crIPsJkZkn00xatqfrNTa+zcysc5q+Q1/LHhteutAV8VbuUf?=
 =?iso-8859-1?Q?uUWOOcB8RcVKtklbY6gUe1935SUTHQp1uMMrfQ5ZROGWsh6Z3CjVzsmupb?=
 =?iso-8859-1?Q?zRZivLPgt6ESLIdMNoPSvnHC7hLjcwqDC7zMR4aw7AoDU8iE96xGqXgQ89?=
 =?iso-8859-1?Q?lQtEC/SyIefKphUQGVRJmhFi5XQksmXLEJaUPLMy9pSPwWynp5rcPXUEdR?=
 =?iso-8859-1?Q?0X+QjyF1eaj72eH3dYp1chBz7ILluqyD9T7Lu7r2G/S6PAptBHBG0Tbz8P?=
 =?iso-8859-1?Q?iF4qhmWzvwBVaEHIFe4kDFmYrzph4ER57GyZ+gSY0k9l1i1yH0Jh6+lcND?=
 =?iso-8859-1?Q?JqUHpBvHV3UfZ5A7PzBwUjxNGXBlo9U9zFjnv1lghZMc8PPNHcVX0eDPJH?=
 =?iso-8859-1?Q?1gxy+Djral7B72k0yfUPbWl4ZZOqBNzfY02vdrwa9l1dNQc+ArHpYvXQ?=
 =?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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19aa59ee-5114-4f6a-975b-08ddfc43b361
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 14:56:25.8980
 (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: 5orOyEoWGMGsvRu+TODtjoi1edqoTpqwEfRjObKTUMdlVsGVxA8RxSmSeGedg4uC2wDQ6FeoXwPmPKFShLcHOfj4Dj4GZfLZlBX8/UobRns=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10413

This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
allow for building Xen without support for booting a regular domain (Dom0).
This functionality is primarily intended for the ARM architecture.

A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
default for ARM and X86 architecture. This symbol signifies that an
architecture has the capability to support a Dom0.

The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
expert users, this option can be disabled (`CONFIG_EXPERT=3Dy` and no
`CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
creation code on ARM. This is useful for embedded or dom0less-only
scenarios to reduce binary size and complexity.

The ARM boot path has been updated to panic if it detects a non-dom0less
configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid
boot.

Signed-off-by: Oleksii Moisieiev 

---

Changes in v4:
- change Misra rule to 2.1 from 2.2 in description
- remove extra dependencies for ARM architecture from DOM0_BOOT
- rephrase DOM0_BOOT help by adding hyperlaunch
- DOM0_BOOT is not mandatory for x86 architecture

Changes in v3:
- rephrase error message when dom0less mode wasn't detected while dom0
is disabled.
- rephrase help message for DOM0_BOOT config option
- update DOM0_BOOT dependencies for X86

Changes in v2:
- decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
suggested in ML) because in this case HAS_DOM0LESS should be renamed
either.
- fix order of HAS_DOM0 config parameter
- add HAS_DOM0 option to x86 architecture.

CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
regular (legacy) domain an optional feature that can be compiled out
from the Xen hypervisor build.

The primary motivation for this change is to enhance modularity and
produce a cleaner, more specialized hypervisor binary when a control
domain is not needed. In many embedded or dedicated systems, Xen is
used in a "dom0less" configuration where guests are pre-configured and
launched directly by the hypervisor. In these scenarios, the entire
subsystem for booting and managing Dom0 is unnecessary.

This approach aligns with software quality standards like MISRA C,
which advocate for the removal of unreachable or unnecessary code to
improve safety and maintainability. Specifically, this change helps adhere =
to:

MISRA C:2012  Rule 2.1: "A project shall not contain unreachable code"

In a build configured for a dom0less environment, the code responsible
for creating Dom0 would be considered "dead code" as it would never be
executed. By using the preprocessor to remove it before compilation,
we ensure that the final executable is free from this unreachable
code. This simplifies static analysis, reduces the attack surface,
and makes the codebase easier to verify, which is critical for
systems requiring high levels of safety and security.

---
 xen/arch/arm/Kconfig        |  1 +
 xen/arch/arm/domain_build.c |  8 ++++++++
 xen/arch/arm/setup.c        | 14 ++++++++++----
 xen/arch/x86/Kconfig        |  1 +
 xen/common/Kconfig          | 12 ++++++++++++
 5 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cf6af68299..336b2ed242 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,6 +17,7 @@ config ARM
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE_DISCOVERY
+	select HAS_DOM0
 	select HAS_DOM0LESS
 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
 	select HAS_STACK_PROTECTOR
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fb8fbb1650..62602afc78 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,8 +42,10 @@
 #include 
 #include 
=20
+#ifdef CONFIG_DOM0_BOOT
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+#endif
=20
 /*
  * If true, the extended regions support is enabled for dom0 and
@@ -104,6 +106,7 @@ int __init parse_arch_dom0_param(const char *s, const c=
har *e)
  */
 #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
=20
+#ifdef CONFIG_DOM0_BOOT
 unsigned int __init dom0_max_vcpus(void)
 {
     if ( opt_dom0_max_vcpus =3D=3D 0 )
@@ -116,6 +119,7 @@ unsigned int __init dom0_max_vcpus(void)
=20
     return opt_dom0_max_vcpus;
 }
+#endif
=20
 /*
  * Insert the given pages into a memory bank, banks are ordered by address=
.
@@ -1962,6 +1966,7 @@ int __init construct_domain(struct domain *d, struct =
kernel_info *kinfo)
     return 0;
 }
=20
+#ifdef CONFIG_DOM0_BOOT
 static int __init construct_dom0(struct domain *d)
 {
     struct kernel_info kinfo =3D KERNEL_INFO_INIT;
@@ -1993,6 +1998,7 @@ static int __init construct_dom0(struct domain *d)
=20
     return construct_hwdom(&kinfo, NULL);
 }
+#endif
=20
 int __init construct_hwdom(struct kernel_info *kinfo,
                            const struct dt_device_node *node)
@@ -2046,6 +2052,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
     return construct_domain(d, kinfo);
 }
=20
+#ifdef CONFIG_DOM0_BOOT
 void __init create_dom0(void)
 {
     struct domain *dom0;
@@ -2103,6 +2110,7 @@ void __init create_dom0(void)
=20
     set_xs_domain(dom0);
 }
+#endif /* CONFIG_DOM0_BOOT */
=20
 /*
  * Local variables:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7ad870e382..fbb290df60 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -481,12 +481,18 @@ void asmlinkage __init noreturn start_xen(unsigned lo=
ng fdt_paddr)
     enable_errata_workarounds();
     enable_cpu_features();
=20
-    /* Create initial domain 0. */
-    if ( !is_dom0less_mode() )
+    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
+    {
+        /* Create initial domain 0. */
         create_dom0();
+    }
     else
-        printk(XENLOG_INFO "Xen dom0less mode detected\n");
-
+    {
+        if ( is_dom0less_mode())
+            printk(XENLOG_INFO "Xen dom0less mode detected\n");
+        else
+            panic("Neither dom0 nor dom0less mode was detected, aborting\n=
");
+    }
     if ( acpi_disabled )
     {
         create_domUs();
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3f0f3a0f3a..2aeb361c63 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_DOM0
 	select HAS_EHCI
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 76f9ce705f..5115f0ede8 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -26,6 +26,15 @@ config DOM0LESS_BOOT
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
=20
+config DOM0_BOOT
+	bool "Dom0 boot support" if EXPERT && !X86
+	default y
+	depends on HAS_DOM0
+	help
+	  Dom0 boot support enables Xen to boot to the all-powerful domain (Dom0)=
.
+	  If this isn't enabled Xen is expected to boot in dom0less/hyperlaunch
+	  mode only. Note: This option is mandatory for X86 architecture.
+
 config DOMAIN_BUILD_HELPERS
 	bool
=20
@@ -125,6 +134,9 @@ config HAS_DEVICE_TREE_DISCOVERY
 	bool
 	select DEVICE_TREE_PARSE
=20
+config HAS_DOM0
+	bool
+
 config HAS_DOM0LESS
 	bool
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 16:03:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 16:03:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130663.1470127 (Exim 4.92)
	(envelope-from )
	id 1v1oR2-0001Gb-Lp; Thu, 25 Sep 2025 16:03:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130663.1470127; Thu, 25 Sep 2025 16: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 1v1oR2-0001GU-HS; Thu, 25 Sep 2025 16:03:08 +0000
Received: by outflank-mailman (input) for mailman id 1130663;
 Thu, 25 Sep 2025 16:03: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 1v1oR1-0001GN-AS
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 16:03:07 +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 1f076c44-9a29-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 18:03:05 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-62fc28843ecso1427655a12.1
 for ; Thu, 25 Sep 2025 09:03: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-b353e5d0526sm190558666b.12.2025.09.25.09.03.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 09:03: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: 1f076c44-9a29-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758816185; x=1759420985; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WI/J3F9qFL74lFhq4vmgFT3/Ut/PZbcdz415wWjcTPM=;
        b=cUnRtjWniPPHAMeBfK6I2+QYC/N69bwl1cvmv5oCu4PWhnrnx+93EKn4wA5PsD0QF9
         0VntIeFO1Tz9Hq1QboAZ6mzBCi6xczutfJI/sw0lRSZPWaxUuxtIZMKbu6C1HZ+0P7b2
         BWVgEj1JYa0w3X5+Ed+Ar/TWZZN4gwnuyr7YaiywryZA4UvH23cb5rxbtumUjtPtorCI
         xZkgj7Bn0zh12ZW5UKfOClcmEpyxNEOziiWGs5IPspLNgBC8gf7SZidbyOyaFlK44fzg
         Ic3BKDg6/biFo4v/KO7ckLM5TSHZvswjvSqjIdd63TifAPQEQuspwuhfR65LuEOS8A1d
         dHdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758816185; x=1759420985;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WI/J3F9qFL74lFhq4vmgFT3/Ut/PZbcdz415wWjcTPM=;
        b=ZZjuXtmIcWdlCkrZZDP1161AVBRMVr7piILj5K6y7z4o8w7e7XLkvb306kSgTPz65u
         unqOPRK6WPBnQ26uLmS9bLUBscjmgQghVmLBb/RahyGtXilstYEyn5QvQi+BphKMA7GD
         yrxAJXwyuSV6m3Tx9W0qWa1LEKO2fcJ+K20elyhXqFEKXI0aflerb1IGeGw/v+iorrzn
         Ly2rrdMNMW2SP8EEAKX6/085zJ+kJzCxGbC5DCpmFTu/pHmtxrcjAM/euvwaFxd4WSkD
         PLjRqalnbTUBEQ0o642LfXKNL9NK3Okygfmx7/rYRQC/C9sRp7wXW3iNx/vaj3GZ0/iw
         oI8w==
X-Forwarded-Encrypted: i=1; AJvYcCXCqhD1+O8mNKnLk5/XVjZNhwlRlY/1OM/q5Z4k+3pgsheQmT+HxvFkcaVlDePl7egXp9eehTQ+W7Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxxzNILeBXg9DqUjCcgkzystqMatIp45RXIOg7mVcIkN328oKy3
	NQSp3Eo4bbe+NcCOYkGZ1s3iPOhmmjVDZSOuEEb2TmQDaP/EtDV0ST2vwg42v28s7A==
X-Gm-Gg: ASbGncth9Qf0Xl4MBHRojzobsgkC90kbZi9jYIZxYq64CJI9wkfTm/6i7jWtEKYHxp3
	G3Zqs//zg8twWOtL7oSEO2JYryzFUUPcGUtZ2jjchp7sP906bAvvtsAFUvzcyFeBLgE9uU7+rJI
	MRErNAPTsX+3038DJF77YFh0NFeI2STsqAkTS/GbInRmCygchavW04cXnN+FOtb+TWHOnnW3bkI
	q7xMghvTM/IX4xw+TPisNhkkfEcqQ68rxGJ759rRfHSyl173YYKnu2j/bNdsY6lia/d65odeb7y
	csIA/4Wk0Un/UpbVfT9bts3w1uvrv49louK9KxXkUqgIAts0zl3tDuK++49Hhs3BRtrDWEjAujt
	UcWTPKucn0mj2C1F11+pqSBsPKLE7sxnK//9qVr+dcZaA0XkHN8rBeQS1cRDx/cTOmaZw3X4px4
	dkY8l/FzjJ8LPNTaof1A==
X-Google-Smtp-Source: AGHT+IE1T2E61PW8Q9+coi5XjdCddCAlZgCMc4o8PiMF/2G+xmgD84BUgUXOCdPeJuQ/ASnaukl98A==
X-Received: by 2002:a17:907:7244:b0:b07:6538:4dc5 with SMTP id a640c23a62f3a-b34bd93d0edmr386220666b.64.1758816184767;
        Thu, 25 Sep 2025 09:03:04 -0700 (PDT)
Message-ID: <7cf80206-18da-4eae-b297-d1ab23bc66d0@suse.com>
Date: Thu, 25 Sep 2025 18:03:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
To: Oleksii Moisieiev 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 "xen-devel@lists.xenproject.org" 
References: <90d39f2050e6028a2fce494381ad0df76f49e541.1758812103.git.oleksii_moisieiev@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: <90d39f2050e6028a2fce494381ad0df76f49e541.1758812103.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.09.2025 16:56, Oleksii Moisieiev wrote:
> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
> allow for building Xen without support for booting a regular domain (Dom0).
> This functionality is primarily intended for the ARM architecture.
> 
> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
> default for ARM and X86 architecture. This symbol signifies that an
> architecture has the capability to support a Dom0.
> 
> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
> expert users, this option can be disabled (`CONFIG_EXPERT=y` and no
> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
> creation code on ARM. This is useful for embedded or dom0less-only
> scenarios to reduce binary size and complexity.
> 
> The ARM boot path has been updated to panic if it detects a non-dom0less
> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid
> boot.
> 
> Signed-off-by: Oleksii Moisieiev 
> 
> ---
> 
> Changes in v4:
> - change Misra rule to 2.1 from 2.2 in description
> - remove extra dependencies for ARM architecture from DOM0_BOOT
> - rephrase DOM0_BOOT help by adding hyperlaunch
> - DOM0_BOOT is not mandatory for x86 architecture

Luckily this is merely wrong here ("not" should be dropped), but correct
in the actual Kconfig logic, so:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 18:37:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 18:37:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130727.1470148 (Exim 4.92)
	(envelope-from )
	id 1v1qqN-0001uf-I3; Thu, 25 Sep 2025 18:37:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130727.1470148; Thu, 25 Sep 2025 18:37: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 1v1qqN-0001uY-E2; Thu, 25 Sep 2025 18:37:27 +0000
Received: by outflank-mailman (input) for mailman id 1130727;
 Thu, 25 Sep 2025 18: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 1v1qqL-0001uR-LZ
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 18:37: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 ada2731e-9a3e-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 20:37:24 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by AS4PR03MB8698.eurprd03.prod.outlook.com (2603:10a6:20b:58d::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Thu, 25 Sep
 2025 18:37:22 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 18:37: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: ada2731e-9a3e-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U+5HYgaRbNz9sFCJq58tEMH0T4M2pOgq04OV2T/ApPVrmbFT5D20MD8PKJJm8NGU3pjCDOpReHsXKtR0zaYUlSc1zRUCVK7Ah7y9TFR+9gg6+IK9bGmb3hSSKM94dXhWyKydJ9HZUHfx4CCUSs12dsvalVh4GdRkuBFU2jysOLJ14PWDqM87LX+4/vokXqMr90DV+4cXQL4NhrgsAirJoH5O5wfaZHhmx2u9aKknZu46EKcteUPli98UHr1MSxS7eIJu87FWnIkIhvdicToUaxir4FFbcZ7RU9EIhPV7dbE5fi9uNwZweFMRq1nFRJU2CQNg6T6l6DEDArWthbTKuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WFghAQKEJC3l/KiXFTMy1qzVHRKCyUkDxx/3I9yy3Yc=;
 b=pC/aN7ZeM9Kbz6OlD1MyjttG1EQGNa+HGM4NCw74qntAbaIGgEaqhXV/M2IBpUsUmlQUYPSWdIW7AgWVPIw1W+sF4X0OzWZoy4QiEgOzQEAtU70bTV9CRNA1lpTWIc+Zf/Rq2uB276x48+DN+QVMPJEJxUMuK1Wt2+ed1bCUqQ1FRxLAPULJdjRX/MIUWFG5eOSdjWmZ4UM0eG9dhEB2FkyFHBs9tD2/43SYxIOKiStflIlwVmlbJtrnKkIXIs2zhr9dGFTcTCRp8XFFALrm2ZZcN6i8Ea/xhqeQg8gFlHGQUDDaVHA3Bs4gu5X0qw4oDBwZhf2PywHn0Dy74CTnqQ==
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=WFghAQKEJC3l/KiXFTMy1qzVHRKCyUkDxx/3I9yy3Yc=;
 b=M0mCNTlA0y16woNgzpdrMZS23PLp8RBAIHHNhT2V46MZ0/9uQCSt6xSimJ3p51edaJ3H6nFBaNS3gS+Eq9m+7uYnJ9FY8XiGj+h3GJU5s/f72b1iW+AfT2N7MPtPCfg7+1IWGgXDzr+9tlkTaSrH/YgtHctNzJOsrYZJ9nkZaWjKtqYQuhfHzw1YIKfB5Zi85EZTD/Ln8BNmlHvQZL+QQmJc9w1MCOtNbsehxc42z0DXa+IyHHzOiiE1Y55WczB/IjME/8QPrzMoxzAsKPVWLOnof/fXwLV30onUH9cwO8UFSnh+XYmXgYoYTnwsZVBCmcWAXKIUCWY/M+jBqLxHDA==
From: Dmytro Prokopchuk1 
To: Jan Beulich 
CC: Nicola Vetrini , Doug Goldstein
	, Stefano Stabellini , Andrew
 Cooper , Anthony PERARD
	, Michal Orzel , Julien
 Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v2] misra: consider conversion from UL or (void*) to
 function pointer as safe
Thread-Topic: [PATCH v2] misra: consider conversion from UL or (void*) to
 function pointer as safe
Thread-Index: AQHcLfLzOeq7/eyxK0Kcj9l07Fl9X7Sj4/SAgABXAYA=
Date: Thu, 25 Sep 2025 18:37:21 +0000
Message-ID: 
References:
 
 
In-Reply-To: 
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: GV2PR03MB9572:EE_|AS4PR03MB8698:EE_
x-ms-office365-filtering-correlation-id: acccd588-84fb-458f-1d08-08ddfc629090
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|376014|7416014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?VnVtdDJUTExPZDJEYkthZThzQ2xsNHo4bFRNWTRwS21ZVU4vdW0zQndPZmg1?=
 =?utf-8?B?RXMzZmZmS29McHp0U0pNemRTbVZ2NVJQaG5hRmFIQWw5ODhyUlZSSlVIUTlD?=
 =?utf-8?B?cnF4OUZvbXhFeUsvN0w3S0hMZTA5a2hNbFI3M3JIVU9peXN6M3Fackk0clg5?=
 =?utf-8?B?ZG5oa3pEOUVqejZkbExPcjJBdlZsNDByK0Jhbm1WWUREZ2J4TUhsQnJlWmlq?=
 =?utf-8?B?aUhxNEdwcmlOYVB6WFFNVmFNL3dBMGZ6dGRIMFB2d1ArZDJhbEtBajA5enhG?=
 =?utf-8?B?THFXL0R2S1ZDN0RRdzNoVWN5Ky80ck0vRDRKOUxDTC9TQzdWT1ltTUJpS0JJ?=
 =?utf-8?B?Skt6ZDU0c083d1Y5SUJpeUNCZkZVMkVpdmtUZnpWWis1STFSalZuZjVPdHZ3?=
 =?utf-8?B?MTFLSE1IOG1LVndKSTAyQnFKYUd1UnhhZ3Bic1l1TW1wbjV4VlNRdmZpSVVV?=
 =?utf-8?B?b0RyRFJRd01OK2N1ayt1WUxaWXBQeGVyRUpIRXhxQ09yaW5GV1pnS1hqV1NW?=
 =?utf-8?B?RHd6VmpmQ2hKT2hpOCsraXNnYjBRcXpTM0kvbTdZV2FacHNYYTdiY0NYbzl6?=
 =?utf-8?B?UXZPSk9aUXkzYjlqdnYveWZmUjJ2ellpakJNM2FSTnAwcEdpbTgyU2IzTnBW?=
 =?utf-8?B?ejViWGIxaUg0Vy9pTldCNllOTHgwcHEybDI2Q2d0dFRkemFNN2Z0YzlLRFE1?=
 =?utf-8?B?c1NVSEtWYVRqbHdZU2hrWjE1bWcrYXJuOGhUTUo2V3lLMk9mSlhMV1JKNkpr?=
 =?utf-8?B?Y28ydGJxbVl6UzJrUjJrMWpaS3hVblNCTXU2UWZtUDZWQkkvZG9tYndyZnMy?=
 =?utf-8?B?UkE3U0owYURpUEcxVHNkakZ4dXU5QkxVNFRNeXVTK3YvNnBJV3ptK1hETVY1?=
 =?utf-8?B?L0tCcFA2QmE4azlBK2owN216dTFaRHkzZzRKc3d4SXlTVFg5cUt0RTlGbm0x?=
 =?utf-8?B?TnpvdXlQeUJiQ0hLKzRramQwM29raEtaeFJVdFcxR04yTVRQOEJDTzAwLzNy?=
 =?utf-8?B?L09lZjVRNndGRUFlMDRLYkZhYmJzUGwrUUV4OEFnQkdyUW5sbGEyMm5FYUJt?=
 =?utf-8?B?dTFRNWc5Y1o3NCtJUmcrOU1KN0NpY0VDUzI2cTl6OVg1YVJGZDBZQ2FYUXor?=
 =?utf-8?B?RDRYSVBwT2dKRU5KMXNyNDZHM1o0MC9vWTg4Zmw0MUVTWUwvN2FVZDZZZ0Fw?=
 =?utf-8?B?WndhV0ZDM3BNY3RsQ3dzcGRib0E2aE9SMkM2ZHJhcWp0VU9TYlFqMHJ3Y3dB?=
 =?utf-8?B?VjdIdU85bTlOSXNXOVNJNnNYTUpMVjFKZVZMcGwrcmRvNlo0Mm5kVFFiTzRp?=
 =?utf-8?B?Ujl3ZmVBeDhiL3BIaFB2Z1MxeWFNNmt0alhMNUR5SDJlb21zeS9VSXBjcnBH?=
 =?utf-8?B?Vk9OVVBaM0RyS2k4UTdaQW0rUk9vZ1BLN1BSZU5mZGZzbWIrU2ZxTkk0dkdk?=
 =?utf-8?B?TkNTTDhPNlVTSElYU3NrNE5MMnRtM0V5SWJaU08xTEZST2x4bUJiMEVNZ3hl?=
 =?utf-8?B?UVF1cjNCcHJEbjZVQTFzNzJISHRvTnNyL1EyQ0JOSEJxdmFvYUh3TU5GaWRt?=
 =?utf-8?B?NEhEQ211b203UDhRN1Q0TWtMMklxWjdEMnQ0NGN3cUs5V3ZnZ200d0xUb3JX?=
 =?utf-8?B?Q29SeE9PdXY1U1U0UkFkVXR0ZnIyRkthWHAvTThtSEExQk5RVmV0Vjh2MUty?=
 =?utf-8?B?Wm9ja1N0SlgrRVdjclRneUhWa3FCamhsODFOWlpUTXJVSGxRaTc1bUt3K2hT?=
 =?utf-8?B?bXYyUmd5NDBQcTVXMlIyUHp2YnJITVFoa1Jmd05PcDdiMTBJa1Y2UFdHZFRy?=
 =?utf-8?B?d0UyV2hLMmE2cU1FVEtoblFzRUsrZWRVZmsxdHBzY2JXakF3SFpoRGQ4QUoy?=
 =?utf-8?B?OEtYZXNNVUVMa3l1WitvRnNPYVRVYTBydWdsNFo1U28xYmFuTDBkckc0aXhs?=
 =?utf-8?B?TjJTcWxaT1QvVEpRaHBwaTJ3cmJRZFRzenBGQitUTHJJblM1dTdDazNJL01K?=
 =?utf-8?Q?t0JOfSkQkyCPqWga+a0DjQ9FNAP9Iw=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(7416014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TXZSeVVVUVJVdTE4MDV0b3Nod21nQUluS29xbWhnU1FBSmJnN3liaEk3Ung4?=
 =?utf-8?B?c3d0R2tnanpIb0k1R3YyaFhGTUN5VFMwWXZibHZxekZHM1lnUHlPZFlvYnlq?=
 =?utf-8?B?dXpKK3dOZzBHem0vakFEZ0EvUmUrbmtLRlFaNVowM08wSnNKUWpMRnY5cU0w?=
 =?utf-8?B?UDNEelI1dVFtTXVLSUFZSnFDV1R3amYzWWY3SFdZQkhWcmN0SjF0bmRNdU1x?=
 =?utf-8?B?WW8xZnZJRmZuRVI3VUFFcmtaWDZXVis3aFREaFpzR25vNmhoRURZTTBmRnlV?=
 =?utf-8?B?Q1BxZGViZVpHTXJ5QnJyck5TZWJ1elFJYTNSTllWNUt2MXBJOTZnazNtd0s4?=
 =?utf-8?B?Wm5ydEpySEJMdUtjc2o5NVpBd2VTN0c1ck4wcWlIOFlxVDNBdWJUdWFoYmd3?=
 =?utf-8?B?QVlFVHFoTGpibGJqQ1VOMFd5TE51eDUrY3VBMU1uOGI4WFo5V20yUFQ1WCs4?=
 =?utf-8?B?alZlcEd3dVA4dWs0MFlTMkFnblpTQkZiaXBJMVY1cVRzbkJOWXY1a21kSjR1?=
 =?utf-8?B?TFVzU210TjBXc3Fhckx3aFlCZVBOSWZJRnVLbTB5eWxlUEx3ekxwVllESG1C?=
 =?utf-8?B?Tzl5UGVuNFZFSEJUbC96RzFBcmNrTUtZNjdXMzVPaHhhYU1PZUhkRDFzZWNH?=
 =?utf-8?B?ZXZWMW95bEVUNHdjMFQ3TXdvNjVybVlFcFdQU01SSmJ1ZUx1NmpYWGZvUFph?=
 =?utf-8?B?QzZ0VUNNZTdOSkI3ZnRxVjFmekRJc2ZpNU8xVnBKOVNzbnVQYXhwM2tSeVBq?=
 =?utf-8?B?N29jMVcrZ0Y0Q0I4ZExFcXd2R0o2T1FEZzZiTFVtTDcyWlg3SGd6KytlL0xa?=
 =?utf-8?B?VlNLTkk0UUNCWnEvUG9hcEF1ZEJsa29RTmVESmlxa2ROVDZpVW1vdjJaOTVi?=
 =?utf-8?B?d204ZFc0SHhRR0VpaTlRWWltalJHZXJLSVFrRDl1TkordXg2RE5MZjVsM0NH?=
 =?utf-8?B?eldhSjFVQWpwRnhSZXhBeDRUTkpkMU43bnBVbEFzR3o4TFFPYmhJYkZHRmw2?=
 =?utf-8?B?d0R0VCtTMlh4V2czQk1wTFVlakUwZTN6M20vVVV0WXlrL2FlOW13Q1l0OVJQ?=
 =?utf-8?B?eTlQOERjdVNFNG9FM1M5bVlyVVFMSURvcTZuWnhZUGZDUlQ0c0ZXUFY3ZGFz?=
 =?utf-8?B?bVVkNHpmdEVZZWlqWWdSSjhkQUkzK0diVW9OVE1VOXhQWHhPYlhHaEFnN2Fz?=
 =?utf-8?B?aXZTU0d1a0ZRN3pEVExXS2J1SzZ5UU93TTZEN0NnWml5RHZDMkxHRFhVbU5t?=
 =?utf-8?B?N1lnWFdsaEZmOUJzck93cFVKQUgxczZRVlNYQjc0bHBHcEhUdHp6b3cvV2VB?=
 =?utf-8?B?OVFRSXFHSkFTc3lXVTVmMDlXZmdrNUxpa2d2TXQ3Ym1STTlYZi9Hb0d1bStR?=
 =?utf-8?B?eGQ1MFZBcDN4L2l4SXd3Z1I1WHdrbXFuNmM2MXdYZVhvWUM3aHVTQjAzclg0?=
 =?utf-8?B?NmMyUHBoSWJtdXdpaGNPblAwWnE4Z0FEL1NMQUkvcEVHNmxMRmsyZUxmZ3FR?=
 =?utf-8?B?cElpeVNBOW01b3NrYXJhZ0ZnamdaUnBTNjg2WHRQWE9FTUtkdDl2SHpZSDBj?=
 =?utf-8?B?SHJOWW1hcUFsbm5GNUFGc3Jld2wvd3BZZVV2VjRwVjZJZU1zQm1IZU9pcVRj?=
 =?utf-8?B?dVM4aDFuUVdzemlNcUl1U29MemZIWjJTV2NvQ2xxYWZZa0hIV082VW55Sm9q?=
 =?utf-8?B?Sm9kbGtPb0diWEliUDZ4S1VUdExndnBqSS9HNzRpeDRuMENqckVNanBKOWI1?=
 =?utf-8?B?SG9xczNBd2crd0tua25qRkg4SEphejRjYnVkQnl5Kzd5aCtBYSsva29XS04w?=
 =?utf-8?B?S0JwYVhBZE9BMFJFdHB0VlF1QWZQMkNlNEZ4QVBXSEFmVDJnUloraXh6VE9W?=
 =?utf-8?B?b1R4V0l3bTZLM2o4WUFCRlFCdnFWZGRJcWRwL2QzYitkQmlFMDY4MkJkVFho?=
 =?utf-8?B?Q2plc0doVkI1eGF0OXRGLzMvVHh6Q2RieEZSeGdvdzAvcXVmYUhyNFZzcVc5?=
 =?utf-8?B?alE3My8zSXZ5UEwrMHhGTUNwRXd5L0Izd3d6SjZ6VlE5eHdyaC90T054SVlh?=
 =?utf-8?B?YjE3TFJjbkFiWThUaXVuTXk5QTlsRUgvcnhoVldUT0RTbWo2ZXRuZ3A4MmNQ?=
 =?utf-8?B?eEx6RE40MVBHL1JoMUN2L1pPVmhKZWg1VlgzeUVEOTIrbzNIeXh6dHBWVkVx?=
 =?utf-8?B?M1E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <8362069BFE8F124A9B438E24D7A0ADD3@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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: acccd588-84fb-458f-1d08-08ddfc629090
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 18:37:21.8807
 (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: kA2jqHlWqmoHKa6jgJjdoCwOBx3R4vnpFRIE60ihKGnxag5HqarV9bU8S7mwkPY88/GXuvRSl3r+5uvpNacJzIVHcdC/m7lN/dHt6pPCFZw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8698

DQoNCk9uIDkvMjUvMjUgMTY6MjUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNS4wOS4yMDI1
IDEwOjA0LCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+PiAtLS0gYS9kb2NzL21pc3JhL2Rl
dmlhdGlvbnMucnN0DQo+PiArKysgYi9kb2NzL21pc3JhL2RldmlhdGlvbnMucnN0DQo+PiBAQCAt
MzY2LDExICszNjYsMjIgQEAgRGV2aWF0aW9ucyByZWxhdGVkIHRvIE1JU1JBIEM6MjAxMiBSdWxl
czoNCj4+ICAgICAgICAtIFRhZ2dlZCBhcyBgc2FmZWAgZm9yIEVDTEFJUi4NCj4+ICAgDQo+PiAg
ICAgICogLSBSMTEuMQ0KPj4gLSAgICAgLSBUaGUgY29udmVyc2lvbiBmcm9tIGEgZnVuY3Rpb24g
cG9pbnRlciB0byB1bnNpZ25lZCBsb25nIG9yICh2b2lkIFwqKSBkb2VzDQo+PiArICAgICAtIFRo
ZSBjb252ZXJzaW9uIGZyb20gYSBmdW5jdGlvbiBwb2ludGVyIHRvIHVuc2lnbmVkIGxvbmcgb3Ig
Jyh2b2lkICopJyBkb2VzDQo+PiAgICAgICAgICBub3QgbG9zZSBhbnkgaW5mb3JtYXRpb24sIHBy
b3ZpZGVkIHRoYXQgdGhlIHRhcmdldCB0eXBlIGhhcyBlbm91Z2ggYml0cw0KPj4gICAgICAgICAg
dG8gc3RvcmUgaXQuDQo+PiAgICAgICAgLSBUYWdnZWQgYXMgYHNhZmVgIGZvciBFQ0xBSVIuDQo+
PiAgIA0KPj4gKyAgICogLSBSMTEuMQ0KPj4gKyAgICAgLSBUaGUgY29udmVyc2lvbiBmcm9tIHVu
c2lnbmVkIGxvbmcgb3IgJyh2b2lkICopJyB0byBhIGZ1bmN0aW9uIHBvaW50ZXIgaXMNCj4+ICsg
ICAgICAgc2FmZSBiZWNhdXNlIGl0IHJlbGllcyBvbiBib3RoIEFCSSBkZWZpbml0aW9ucyBhbmQg
Y29tcGlsZXIgaW1wbGVtZW50YXRpb25zDQo+PiArICAgICAgIHN1cHBvcnRlZCBieSBYZW4gd2hp
Y2ggZGVmaW5lIGNvbnNpc3RlbnQgYW5kIGNvbXBhdGlibGUgcmVwcmVzZW50YXRpb25zDQo+PiAr
ICAgICAgIChpLmUuLCBoYXZpbmcgdGhlIHNhbWUgc2l6ZSBhbmQgbWVtb3J5IGxheW91dCkgZm9y
ICcodm9pZCAqKScsIHVuc2lnbmVkDQo+PiArICAgICAgIGxvbmcsIGFuZCBmdW5jdGlvbiBwb2lu
dGVycywgZW5hYmxpbmcgc2FmZSBjb252ZXJzaW9ucyBiZXR3ZWVuIHRoZXNlIHR5cGVzDQo+PiAr
ICAgICAgIHdpdGhvdXQgZGF0YSBsb3NzIG9yIGNvcnJ1cHRpb24uIFRoZSBjb21waWxlLXRpbWUg
YXNzZXJ0aW9ucyAoQlVJTERfQlVHX09ODQo+PiArICAgICAgIG1hY3JvKSBpcyBpbnRlZ3JhdGVk
IGludG8gJ3hlbi9jb21tb24vdmVyc2lvbi5jJyB0byBjb25maXJtIGNvbnZlcnNpb25zDQo+PiAr
ICAgICAgIGNvbXBhdGliaWxpdHkgYWNyb3NzIGFsbCB0YXJnZXQgcGxhdGZvcm1zLg0KPiANCj4g
QXMgeW91IHVzZSAoYW5kIG1lYW4pIHBsdXJhbCwgcy9pcy9hcmUvID8gSSBhbHNvIHRoaW5rIHRo
ZSAiVGhlIiBhdCB0aGUgc3RhcnQNCj4gb2YgdGhlIHNlbnRlbmNlIHdhbnRzIGRyb3BwaW5nLg0K
T2suDQoNCj4gDQo+IEZ1cnRoZXIsIHdoeSB0aGlzIHZlcnkgZGlzc2ltaWxhciB3b3JkaW5nIGNv
bXBhcmVkIHRvIHdoYXQncyBzYWlkIGFib3V0DQo+IGNvbnZlcnNpb25zIF9mcm9tXyBmdW5jdGlv
biBwb2ludGVyIHR5cGVzPw0KRG8geW91IG1lYW4gdGhlIGZvbGxvd2luZyB3b3JkaW5nIHNob3Vs
ZCBiZSBwbGFjZWQgaW5zdGVhZCAodG8gYmUgDQpzaW1pbGFyIHdpdGggcHJldmlvdXMgb25lKT8N
Cg0KIkNvbnZlcnNpb25zIGZyb20gdW5zaWduZWQgbG9uZyBvciAodm9pZCAqKSB0byBhIGZ1bmN0
aW9uIHBvaW50ZXIgZG8gbm90IA0KbG9zZSBhbnkgaW5mb3JtYXRpb24sIHByb3ZpZGVkIHRoYXQg
dGhlIHNvdXJjZSB0eXBlIGhhcyBlbm91Z2ggYml0cyB0byANCnJlc3RvcmUgaXQuIg0KDQpBbmQg
d29yZGluZyBhYm91dCAiQUJJLCBjb21waWxlci4uLiIgc2hvdWxkIGJlIG9ubHkgaW4gY29tbWl0
IG1lc3NhZ2U/DQoNCj4gDQo+IEFuZCB0aGVuIC4uLg0KPiANCj4+IC0tLSBhL3hlbi9jb21tb24v
dmVyc2lvbi5jDQo+PiArKysgYi94ZW4vY29tbW9uL3ZlcnNpb24uYw0KPj4gQEAgLTIxNyw2ICsy
MTcsMTcgQEAgdm9pZCBfX2luaXQgeGVuX2J1aWxkX2luaXQodm9pZCkNCj4+ICAgI2VuZGlmIC8q
IENPTkZJR19YODYgKi8NCj4+ICAgfQ0KPj4gICAjZW5kaWYgLyogQlVJTERfSUQgKi8NCj4+ICsN
Cj4+ICtzdGF0aWMgdm9pZCBfX2luaXQgX19tYXliZV91bnVzZWQgYnVpbGRfYXNzZXJ0aW9ucyh2
b2lkKQ0KPj4gK3sNCj4+ICsgICAgLyoNCj4+ICsgICAgICogVG8gY29uZmlybSBjb252ZXJzaW9u
IGNvbXBhdGliaWxpdHkgYmV0d2VlbiB1bnNpZ25lZCBsb25nLCAodm9pZCAqKQ0KPj4gKyAgICAg
KiBhbmQgZnVuY3Rpb24gcG9pbnRlcnMgZm9yIGFsbCBzdXBwb3J0ZWQgYXJjaGl0ZWN0dXJlcy4N
Cj4+ICsgICAgICovDQo+PiArICAgIEJVSUxEX0JVR19PTihzaXplb2YodW5zaWduZWQgbG9uZykg
IT0gc2l6ZW9mKHZvaWQgKCopKHZvaWQpKSk7DQo+PiArICAgIEJVSUxEX0JVR19PTihzaXplb2Yo
dm9pZCAqKSAhPSBzaXplb2Yodm9pZCAoKikodm9pZCkpKTsNCj4+ICt9DQo+IA0KPiAuLi4gSSdt
IHVuY29udmluY2VkIGNoZWNraW5nIG1lcmVseSB0aGUgc2l6ZXMgaXMgc3VmZmljaWVudC4gT24g
YXJjaGl0ZWN0dXJlcw0KPiBpbnZvbHZpbmcgZnVuY3Rpb24gZGVzY3JpcHRvcnMgKGUuZy4gaWE2
NCkgY29udmVydGluZyBpbiB0aGlzIGRpcmVjdGlvbiBpcw0KPiBzYWZlIG9ubHkgaWYgZWFybGll
ciBvbiB0aGUgdmFsdWUgd2FzIG9idGFpbmVkIGFzIHRoZSByZXN1bHQgb2YgYSBjb252ZXJzaW9u
DQo+IGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gKGFuZCBhbGwgb2YgdGhpcyB3aXRoaW4gYSBz
aW5nbGUgY29tcG9uZW50LCB3aGljaA0KPiBvZiBjb3Vyc2UgaXMgZ3VhcmFudGVlZCBmb3IgWGVu
KS4NCkFzIEkga25vdyBtYWlubGluZSBYZW4gZG9lc24ndCBzdXBwb3J0IElBLTY0IGN1cnJlbnRs
eSAodGhpcyBzdXBwb3J0IHdhcyANCmRyb3BwZWQpLg0KV2h5IHdlIHN0aWxsIG5lZWQgdG8gbWVu
dGlvbiBhYm91dCBJQS02NCBoZXJlPw0KDQpBbnl3YXkuLi4NClllcywgdGhpcyBkZXZpYXRpb24g
d291bGRuJ3Qgd29yayB3aXRoIGFyY2hpdGVjdHVyZXMgd2hlcmUgdGhlIA0KcmVwcmVzZW50YXRp
b24gb2YgYSBmdW5jdGlvbiBpbnZvbHZlcyBtb3JlIHRoYW4ganVzdCBpdHMgYWRkcmVzcyAoZS5n
LiANCklBLTY0KS4gSWYgbm90IHByb3ZlZCB0aGF0IHN1Y2ggY29udmVyc2lvbiBpcyBzeW1tZXRy
aWMuDQoNClByb2JhYmx5LCBhZGRpdGlvbmFsIGd1YXJkIG1heSBiZSBhZGRlZCBiZWxvdyB0byBl
eGNsdWRlIHN1Y2ggDQphcmNoaXRlY3R1cmVzIChlLmcuIElBLTY0KToNCg0Kc3RhdGljIHZvaWQg
X19pbml0IF9fbWF5YmVfdW51c2VkIGJ1aWxkX2Fzc2VydGlvbnModm9pZCkNCnsNCiNpZiBkZWZp
bmVkIChfX0lBNjRfXykgfHwgZGVmaW5lZCAoX19pYTY0X18pDQojZXJyb3IgIkNvbnZlcnNpb25z
IHRvIGZ1bmN0aW9uIHBvaW50ZXIgaXNuJ3Qgc2FmZSAtICBhcmNoaXRlY3R1cmUgdXNlcyANCmZ1
bmN0aW9uIGRlc2NyaXB0b3JzLiINCiNlbmRpZg0KDQogICAgIEJVSUxEX0JVR19PTihzaXplb2Yo
dW5zaWduZWQgbG9uZykgIT0gc2l6ZW9mKHZvaWQgKCopKHZvaWQpKSk7DQogICAgIEJVSUxEX0JV
R19PTihzaXplb2Yodm9pZCAqKSAhPSBzaXplb2Yodm9pZCAoKikodm9pZCkpKTsNCn0NCg0KQnV0
IGlmIHNvbWVvbmUgcmVhbGx5IHdpbGwgdHJ5IHRvIHJ1biBYZW4gb24gc3VjaCBwbGF0Zm9ybSwg
dGhlIGJ1aWxkIA0Kd2lsbCBmYWlsLg0KDQpPciBqdXN0IG1lbnRpb24gZXhwbGljaXRseSB0aGF0
IG90aGVyIGFyY2hpdGVjdHVyZXMgKGUuZy4sIElBLTY0KSBtaWdodCANCm5vdCBiZSBzYWZlIGZv
ciBzdWNoIGNvbnZlcnNpb25zPw0KDQpEbXl0cm8uPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 18:46:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 18:46:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130741.1470157 (Exim 4.92)
	(envelope-from )
	id 1v1qyf-0003SW-9d; Thu, 25 Sep 2025 18:46:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130741.1470157; Thu, 25 Sep 2025 18:46: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 1v1qyf-0003SP-76; Thu, 25 Sep 2025 18:46:01 +0000
Received: by outflank-mailman (input) for mailman id 1130741;
 Thu, 25 Sep 2025 18:45: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 1v1qyd-0003SJ-PO
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 18:45:59 +0000
Received: from BL2PR02CU003.outbound.protection.outlook.com
 (mail-eastusazlp17011000f.outbound.protection.outlook.com
 [2a01:111:f403:c100::f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df410973-9a3f-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 20:45:57 +0200 (CEST)
Received: from SJ0PR03CA0103.namprd03.prod.outlook.com (2603:10b6:a03:333::18)
 by DS0PR12MB8365.namprd12.prod.outlook.com (2603:10b6:8:f8::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.9; Thu, 25 Sep
 2025 18:45:53 +0000
Received: from SJ1PEPF00002322.namprd03.prod.outlook.com
 (2603:10b6:a03:333:cafe::24) by SJ0PR03CA0103.outlook.office365.com
 (2603:10b6:a03:333::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.22 via Frontend Transport; Thu,
 25 Sep 2025 18:45:53 +0000
Received: from satlexmb08.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Thu, 25 Sep 2025 18:45:52 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 25 Sep
 2025 11:45:52 -0700
Received: from [10.71.195.192] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Thu, 25 Sep 2025 11:45:51 -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: df410973-9a3f-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Uaui5JdAhgqo5FaEB9n3Q+rJpd32MO7aupt1qUb4AaSkuxLMB1K9wHy0sSN3NyekFJGp3EjN1jTCES+St2OZhbopH+HioT/DEbGwiZZHut1hYPpJLV6+WUFkiCMMOBV8AQ/7T/UNnEXolM/FTF71IKi9hF2a/Xh0URKBfGIUmiw637X1W2E3TYNoAtEBa5YPljQshj+TKvl00yu3sN75Td1imsW4GHEGeqKxyd5BCgO232jBiFQ+psqRWFZMk/W4cr7HG6b+4RnN8q286JNQNJ1TNGh1YpFIFNxzLSOh4KI6gowvGqG2uhMSteL7obRXVqHftE+4G26tf5Dr0f+VVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6WK6JEI2NPrrhjlYUehGgTpiNDft3cd2ZTkSrs8nuDg=;
 b=jm5mysyz1sARKxtf2d8LHlTPqdKKCYNwPpGTnum+dORGikjc4RevBrGvA0bvM+TreK3UxD/FJk8phUJe9SJuuO0jJ87WUKd6zvOfsSx0sxYDDl9lzlaPEJZ9ahO2mA5plChCC7WJc4aklstbKG4rgXNb6afXYA/ETnzcHBz7Gmcx0g+yxf1bfrqdpPruEPqT5pDiWLXs5DqqFfCQDd/RBL9ZQPcTI4S50psn1C29RvQn4O5Eg6F7DdCmNoqef90cqtZpg0XlhQPpNsgMLCTjBiqdEwtoXYMAfvIgiLljzLkteo59Hh6AbsajoumhMSwtMOpEYhm+WeL0NCtMxxwy4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6WK6JEI2NPrrhjlYUehGgTpiNDft3cd2ZTkSrs8nuDg=;
 b=KwCOS6j+csICj7wfXsH96tFkVVbbZ+lZ2V3x27+XOmd1uZMntrCkNien5bjWOG5aWgAO6iXx8wjoi3m5JEMgRT619Y4cpZIwEK9S1tT81LN2OIMbS+ORfR09O/K3TRCp0VXRhT/n0M7134CTOBP54NpGcHmwWTOQUXYEpvWSE7c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <542fef14-a123-4d7b-9bd6-8bc280276684@amd.com>
Date: Thu, 25 Sep 2025 19:45:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests
To: Grygorii Strashko , Ayan Kumar Halder
	, 
CC: Stefano Stabellini , Julien Grall
	, Michal Orzel , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20250912170055.3077923-1-ayan.kumar.halder@amd.com>
 
 <762b9d19-f1dd-4bfe-a298-d88ab8e7bbd2@amd.com>
 <054b31c6-8911-495b-a8b4-b7a807c95786@epam.com>
Content-Language: en-GB
From: Ayan Kumar Halder 
In-Reply-To: <054b31c6-8911-495b-a8b4-b7a807c95786@epam.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002322:EE_|DS0PR12MB8365:EE_
X-MS-Office365-Filtering-Correlation-Id: d9611c75-fdff-4675-47c2-08ddfc63c130
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?ZDY4Q0hJempIU3VmMVltL1YxVjJSaHB4RkcyVXFjdGJuU2ZRbzNWNHNON0Zu?=
 =?utf-8?B?RnJ0UDEvK1JSNVBCSEZRc2dmKzJiRjhCVzZvMEErd2E1WmN0UVNNdjRpSFFT?=
 =?utf-8?B?STZVZ0lWSjBLVGZNay9TR0d2em5yU1BDN1M3SW1Ea05zMmFvQWtLQkVuUi9I?=
 =?utf-8?B?dG5OVXRTQ2ZPVjlKelNqanNnR3F0cUR1MkNRS0Zyb2h6Nm1BNXNZTjU2bWky?=
 =?utf-8?B?TksrQUlBWHA1REVRb1cxRXRZSE5lQlpTaVJLTitsaEZ1Q3lSUmUxeUJsRU83?=
 =?utf-8?B?NUNJZHJZN0RmVXAxSjZtY1lyamQwSWF0aENtamtoRVdzbHNlYUxUL04zejZa?=
 =?utf-8?B?bHVRdU5rWXlXNFl3NUNBUll2WnNkbUU3Yk5RaDVGaTJha3kwNGwyNkQ5T1o3?=
 =?utf-8?B?d0FSK0FjemkrUktjd2VJNHQ2SnRCVStuemRMTFZ5UStheldkOFZuTVBwcWVH?=
 =?utf-8?B?dHQ0WGZuZGZtck5QMkxld1NoY2dTYXl6WXB1c01pdU9ZNE5BQ3cvNzBZZ3Ja?=
 =?utf-8?B?cVVkaHRpVkFJbVp0V2FtQUQ2dWhGY3puQzlkV1BiYTkrOHJ0VnA3N3BJOFlE?=
 =?utf-8?B?b05IYk81SU52aHQ0aWxUVGR6M0hmc042cVRDcU43a0VRNmlqZFpZdGFvOFVj?=
 =?utf-8?B?b0JpMEdGRG84K1VhczJIeCtYQWxUQlN4bUJMZHhGS2tGQzA1b21Ia0p2b0hR?=
 =?utf-8?B?SEFvektUeWE5eXB5TGF6SUE4K05IL1VSZi9tbmZIUmF1cDJmY3NINWQ5NTEx?=
 =?utf-8?B?Q21WVFUzL3FNRGVvcHFra0I3VU9oUUhmMEdjN3EvSzRKN3N2MXpuR0E5anVn?=
 =?utf-8?B?QUpBZVY1aVNQUGozZEt0TW91SENhM1k0a2lFODhXV0lpMzlRbDRGamE2WHdj?=
 =?utf-8?B?V2MydWlZMnlKeUZ1OWlidWdqUGRkU3MxV3pnY2U3eFVYNUdiZ2xIWThZMzdF?=
 =?utf-8?B?VTVjdHUyc2VtZkxMMVd4QkVaRjNqV2s4WXlJR2xwbGlvbDQ0d0hPb3paRHhX?=
 =?utf-8?B?MmlWclk2R1Y0Zm4vNXJMWHF1aG5aRWwxUG9ZdVR4VVIwRGtudkJYMTViaUVW?=
 =?utf-8?B?Tnk5VTVKS3VXeXA5eTdjLzczNnRGMkFtcTZuOEN1eXlqN2xBWjlkZzRqcExB?=
 =?utf-8?B?Z1A2VWU2YzF4K2plckVXYUZRZDczRUIvaWVQbHU0UDRsU0p3UDNLUHpjY3d5?=
 =?utf-8?B?Lzl3NDlvemhqcUUwNUFqcTJJRmp2STk0b2g0RW9CZnVaM0tmSzIzTDBpb2ly?=
 =?utf-8?B?aXNXVzk5UWFUWG1obW5kU0dDTnVodjN0RkRHVnFRUzV6a0E0MnFJNDJGRWZH?=
 =?utf-8?B?bFRMSWNJMmhINmRZRm9tWit4TjgyU1NnU2RSdU11SUZYUDl4VUJyVmpyZkZQ?=
 =?utf-8?B?TXQ4RGpic2J0cFBmUWRId1FtdjFGRFVVc1FINlVHaHJvTnN1Z1Y0U2VGUW91?=
 =?utf-8?B?ZHJ6Wk1rQmF1VWUxR3prTWU3cWdXeTRJV2d5UjNvN2tlbGk2eTlTeEgyWHZx?=
 =?utf-8?B?SnNMRmRXT2JuVVBPQ09yQTl1TWJBRGJESDRIVE9VRWhQaVZJOU82VlRib1RS?=
 =?utf-8?B?NEdIWDZrM2RsOVR5YXNUcy9OelU3VndRYUdMaGYzTXdhdThQNll5TUpJVEZ1?=
 =?utf-8?B?QTA2eE84Si9ySklLT3Z4Q0k4WG54dXd3WWU4dDJHYVFBMklZWkdSOURTT2E1?=
 =?utf-8?B?N0t2Yjg5WkpEdXJXRzc3RXRXbWFwQ1JGYWxQSkNvTTdjUTJaTksxV2NHUGRR?=
 =?utf-8?B?UTJIRElJY3dhNm4vRUZ2WGN3SWx3U1dwNVlIWlMxRWgyNFpXTjN5bEswdm5z?=
 =?utf-8?B?cUJmLzdZM1ZBM2xIY2J2TkNMSUl0OHVsTjZBK2k0TUVhdVJUdmFld1VwZTBK?=
 =?utf-8?B?NThRb2pLU0loMUQ5STdUVXF3aVU4SlY1cGhUL0xjR2gvbDA1eDdlN3FRcUFq?=
 =?utf-8?B?cDNaUEVPY25STUJNSkxNYmpwWGgyZ1R5amd3ZTFwMWI2eHpZdE9CcVdTSTdM?=
 =?utf-8?B?N2FCdzREbXVMY2V4V0o1N2pCT2VaVkJ0YzNXQnF2ZVMwYUs5V095eUJVVmdL?=
 =?utf-8?Q?NUaI2s?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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: 25 Sep 2025 18:45:52.8257
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d9611c75-fdff-4675-47c2-08ddfc63c130
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002322.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8365


On 24/09/2025 16:48, Grygorii Strashko wrote:
> Hi Ayan,
Hi Grygorii,
>
> On 22.09.25 19:55, Ayan Kumar Halder wrote:
>>
>> On 16/09/2025 11:55, Grygorii Strashko wrote:
>>> Hi Ayan,
>> Hi Grygorii,
>>>
>>> On 12.09.25 20:00, Ayan Kumar Halder wrote:
>>>> Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
>>>> Test that Xen is able to generate SGIs.
>>>>
>>>> Signed-off-by: Ayan Kumar Halder 
>>>> ---
>>>> One of the aim of functional safety is to test hw/sw interface. 
>>>> This means that
>>>> Xen is able to configure the hardware correctly for the desired 
>>>> functionalities.
>>>>
>>>> Normally this is tested from the VMs. For eg if a VM is able to 
>>>> receive irq, this
>>>> implies that Xen has configured the GICv3 interface 'correctly'. 
>>>> However this is
>>>> a high level (or integration) test which uses not only the GICv3 
>>>> interface
>>>> between Xen and VM, but the interrupt injection code for Xen to VMs.
>>>>
>>>> We want to have some kind of unit tests to check that Xen is able 
>>>> to receive
>>>> various interrupts, set priorities, etc. Here, we have written unit 
>>>> tests for
>>>> software generated interrupts (SGIs) as example.
>>>>
>>>> These tests are expected to be triggered as Xen boots (right after 
>>>> Xen has
>>>> initialised the GICv3 interface ie gicv3_init(). The aim of this 
>>>> test is to
>>>> check whether Xen can trigger SGIs after gicv3_init() is invoked. 
>>>> If so, we can
>>>> claim that gicv3_init() was done properly to be able to trigger 
>>>> SGIs. Likewise
>>>> we will have tests to check for priorities, SPIs, etc.
>>>>
>>>> A script will parse the logs and claim that Xen is able to trigger 
>>>> SGIs.
>>>>
>>>>   xen/arch/arm/Kconfig  |  8 ++++++++
>>>>   xen/arch/arm/gic-v3.c |  7 +++++++
>>>>   xen/arch/arm/gic.c    | 21 +++++++++++++++++++++
>>>>   3 files changed, 36 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>> index 950e4452c1..739f99eaa9 100644
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -73,6 +73,14 @@ config GICV3
>>>>         Driver for the ARM Generic Interrupt Controller v3.
>>>>         If unsure, use the default setting.
>>>>   +config GICV3_SELFTEST
>>>> +    bool "GICv3 driver self test"
>>>> +    default n
>>>> +    depends on GICV3
>>>> +    ---help---
>>>> +
>>>> +      Self tests to validate GICV3 driver.
>>>> +
>>>>   config HAS_ITS
>>>>           bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if 
>>>> UNSUPPORTED
>>>>           depends on GICV3 && !NEW_VGIC && !ARM_32
>>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>>> index 4e6c98bada..eb0c05231c 100644
>>>> --- a/xen/arch/arm/gic-v3.c
>>>> +++ b/xen/arch/arm/gic-v3.c
>>>> @@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
>>>>         gicv3_hyp_init();
>>>>   +#ifdef CONFIG_GICV3_SELFTEST
>>>> +    send_SGI_self(GIC_SGI_EVENT_CHECK);
>>>> +    send_SGI_self(GIC_SGI_DUMP_STATE);
>>>> +    send_SGI_self(GIC_SGI_CALL_FUNCTION);
>>>> +    send_SGI_self(GIC_SGI_MAX);
>>>> +#endif
>>>> +
>>>
>>> I'd like to ask, if possible, to minimize mixing selftest and 
>>> functional code.
>>> Like add gic-v3-selftest.c.
>>
>> I can try that. However, the self test needs to be invoked from 
>> functional code.
>>
>> Also, your suggestion gave me an idea. I can do :-
>>
>> +static bool __initdata opt_gicv3_selftest = false;
>> +
>> +#ifdef CONFIG_GICV3_SELFTEST
>> +opt_gicv3_selftest = true;
>> +#endif
>
> I'd like to propose to consider other approach according to the 
> following assumptions:
> 1) the goal is "Test that Xen is able to generate SGIs.". According to 
> the goal and your code
> - for this test, it doesn't matter which one (SGI) is tested. Any way 
> you don't call real handlers for
>  GIC_SGI_x.
>
> 2) there are 16 SGIs available, only 3 are statistically defined (enum 
> gic_sgi) and
> It's possible to reserve one more for testing purposes,
> like GIC_SGI_SELFTEST

I do like this approach. The only mild concern is that the test 
introduces a new SGI. IOW, it is not testing the existing SGIs which are 
used by Xen.

I need to think a bit more on this.

>
> Then, gic SGI selftest might work without breaking Xen boot (probably 
> for gicv2 also)

The goal of these kind of self tests are to validate Xen drivers (or 
rather Xen's configuration of the HW component). We will not be running 
Xen with any domains. Also, we don't intend to have the self tests run 
during regular boot of Xen as it adds a significant amount of code to be 
executed during boot time.

These tests will help to isolate issues when there is a potential 
misconfiguration of Xen for the hardware component or the hardware 
component does not work correctly with Xen.

>
> gic.c:
>   do_static_sgi()
>   {
>    ...
>    #ifdef CONFIG_GIC_SELFTEST
>         case GIC_SGI_SELFTEST:
>           gic_sgi_selftest();
>         break;
>    #endif
>
> git-selftest.c
>
>   gic_sgi_selftest()
>   {
>     // process test SGI, like count number of triggers
>   }
>
>   void [__init __constructor?] test_gic_sgi_selftest()
>   {
>     setup test 1
>     send_SGI_self(GIC_SGI_SELFTEST)
>     setup test 2
>      send_SGI_allbutself(GIC_SGI_SELFTEST)
>     setup test 2
>     send_SGI_mask(cpu_mask, GIC_SGI_SELFTEST)
>   }
>
>
I do like the coding suggestion.

- Ayan




From xen-devel-bounces@lists.xenproject.org Thu Sep 25 19:11:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 19:11:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130768.1470168 (Exim 4.92)
	(envelope-from )
	id 1v1rN8-0007PU-Cw; Thu, 25 Sep 2025 19:11:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130768.1470168; Thu, 25 Sep 2025 19: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 1v1rN8-0007PN-AH; Thu, 25 Sep 2025 19:11:18 +0000
Received: by outflank-mailman (input) for mailman id 1130768;
 Thu, 25 Sep 2025 19:11:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1rN7-0007PH-AR
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 19:11:17 +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 6648e24a-9a43-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 21:11:12 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by DBAPR03MB6678.eurprd03.prod.outlook.com (2603:10a6:10:191::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 19:11:08 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 19:11: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: 6648e24a-9a43-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xH46NqBWLchb5Olav/R5+Le4KSBQltCq0SWpO85Mqn4l6WS+ZOoSd53FhlwfxJiFuOMsvVykiwD59td8awBTNc9hSZNWCCgdocVvkKJXQq2Jlg0+9vFgYwbqd3xHXWS0We2GNXpTb/0nP7i2vIs5RT8/MAvYrnUeLvyk1tRw86NbxDpRBKZbeqGK2VkqQDIwd+uRYG5abob5XiXkpIJK/kw/SkeRDj3DXMpzAkNpz6yBtcv+VYgXPneJwoGoGHkT3zr6C4A6vm0rkyCYeMSWBYCz+OK/4GCOPvdGYUl+fbap4WEPSyIlwIaXGlieE2ZCYJoK8v8JVIJDcOuBj45bGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lewHeEG9bcwJLUXMtZ+779xDAXJ2awm1T9kV5kQc5V0=;
 b=e8/yPYwceSLDauwq/dpgquOqddkcdswdusHNyQDy8cFgW1q8DffiRV0Tsql0Mjjyq7dfGH4/SH0jD+xmqfR6oMue6IuqpRsqsQA0YcmiD0r0dM6eG/s7EM/J31AK7KCDruXTY8gAxspUgimla/Ez3uAOSz+cLKTOcyHxH43NPBMM1IDxHlv1mBV4wgJQ+HYNzu6JM1NKPYjQcw4P5X5SCkci3s2XiMmMqt+sLduOtZZEPJzsQz61DcESZH0avDt+/t+x3R7+yZ3Ghkze9EOGYdDFFrvyX8FjUoEC7WhidOMyx4WloIAB7YAVLhOq2v0bbtDamcGV33n75khDEDn5Ig==
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=lewHeEG9bcwJLUXMtZ+779xDAXJ2awm1T9kV5kQc5V0=;
 b=CGmiWKcMJ2ZrdjIl3292OC+8w1nPFpm/pQDEkGZUXDfNLGZEr2OTXFR9kxcyWWF4rs2oegMnEuLnJyhe0VDn1RdwekH2DLfJr6PHLvI8yt4ROakCLsw6Yz4es3nKhzZaoOUIPj0zzBklgzWJRB3DfJHMuQer+SHGOgjX9XKpKB2hiWOfMQSeEJXtFcT3LDqGOug3U+e9OzwZtdrUZv04cTkU2OAyijoY/e2PgWZC52mJr3rXzacKlDRMHW4ncolSfTJmonI2fKEPBpQWu3Dbm8FDCXNCPtEiKhkAzNNSLcCTtxCp0vUus2e8KABoQNapf0cgCQUC5tXb1ns20yDtpQ==
From: Dmytro Prokopchuk1 
To: Nicola Vetrini , Stefano Stabellini
	
CC: Doug Goldstein , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" , Jan
 Beulich 
Subject: Re: [PATCH v2] misra: add deviation for MISRA C Rule 11.3
Thread-Topic: [PATCH v2] misra: add deviation for MISRA C Rule 11.3
Thread-Index: AQHcFRxkNZTwf+a94EKUOod0hf+3z7RzKlMAgDFLvoA=
Date: Thu, 25 Sep 2025 19:11:08 +0000
Message-ID: <278915c9-0049-4e25-90ab-9bb3da7ecee1@epam.com>
References:
 <859503540c6b7447f13365c2b70b386c2975edd0.1756056144.git.dmytro_prokopchuk1@epam.com>
 <21268b36-ca49-4628-835e-1708ad313946@suse.com>
In-Reply-To: <21268b36-ca49-4628-835e-1708ad313946@suse.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: GV2PR03MB9572:EE_|DBAPR03MB6678:EE_
x-ms-office365-filtering-correlation-id: 2add8418-72ac-4c5f-3a45-08ddfc67486c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|376014|7416014|42112799006|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?cFd6bjJJNzE4UlE3d3FuNVBab3ZueFZHdUVzOWd1bHZVbE9DaVhlS2R0UW9D?=
 =?utf-8?B?L1NVQTVPZERMWG9BQjJjTG9oR2NLUUFoNGJZUi9uWEZXeHZDZFRoMXdPaExn?=
 =?utf-8?B?QWJBN2RGZjgrTzFncGU5Yk9aTm5QUklYNHBuQnBBVkpGYnRNcVlXZGRlTnBh?=
 =?utf-8?B?aENPbG44R2RyNGRzMGtKOGE3MFRVdFNwMWVkc3QyKzhmZkJMZkkxTjZPa0x5?=
 =?utf-8?B?bkdJQkMrR21uYVp1M001S3pTYjgwT1FnVUFPbjdZMkxEK3pCUEdXNVpJMWNI?=
 =?utf-8?B?Y0twYm5wVlVJdXh5Ri9LMzJiaEJWdVZNL1NXV0ozeTNSSjd3RnpGa1dFK0NO?=
 =?utf-8?B?aU1GZmNrSXVTZStQRm9WWXB3d0hUVXZjZG1QdGd3WnZsSXBJUkhJUDk0Wnc4?=
 =?utf-8?B?Ky96ajJqclFOSjlKcmt1Q2hnbGxEYTVqeUU5T29IRVRhMlJiREd1VGZyT09p?=
 =?utf-8?B?VEhKeDZvbkU1Um9DM0gwdU1Cc0FKSlVYV29vQzczMjd3dElBZnJRNXcyMU9w?=
 =?utf-8?B?R1pxWTI4ay9jMWdiN1VMcHA5WE5NckNZT1NXSlFGd3g2WEowcGJCenRXQmts?=
 =?utf-8?B?OHJ3aUtPWGg5Nnd5dlhMaVAyUGQ0eUJCNS9QTHJlNUpXWFp4YVQvL2gvYitR?=
 =?utf-8?B?N05wREF5SUJqL3RsamY5MmVmL01PUU9QeVR5clM0WnUxemg5dk44dFJEWnJI?=
 =?utf-8?B?am9pYnI0aXZlcFZON1RvOHYzYUJ2L1h6aTZrUzJoUzUraXI0NWdWck5vYXRJ?=
 =?utf-8?B?cHg2aWhGUlMyN0x3b2ZyZW5kZ3pZUjlsaXoxcXVOMjBQTmxxby9nMHk5ZFM4?=
 =?utf-8?B?am5hM1hwZnlzdTBGcG0wdE9VUVRrRnBNQmxqSEk4ZW9FSXJEQTUrVjRqNDNw?=
 =?utf-8?B?VjdEK3p2REQxYWFQSWtMVjZLcXhaczR2RExKQ3RQYm9IM2RmYzJDUkphYmxJ?=
 =?utf-8?B?d3pGUENqS1V5Qjh2ZXl0ellpbml2L1VLR0hsUXlMSW5weU9oUENiTkRiYVZR?=
 =?utf-8?B?ZllITmxUVGIycFU1UWpORzJVZm1uMGtrTXFNTlFROVNvM3RHa3dYNk9Ra1Fj?=
 =?utf-8?B?SlkvaWkrNHkrdW9PSWtadVdxb25GdkM5dzNVS1g2emxJZ2NOVHdKMnJ5NXAw?=
 =?utf-8?B?R3h4MXA4WGFKVUtENWkybkZMNE8rZHVtUjBzMUd6RnBzRWVZWUpNcGcxZC9h?=
 =?utf-8?B?K01qOUxETzROWjZiZUxuS1NvRzN6NW5VeXYyZkpxT1BBWEZBUjdReXM3NnF3?=
 =?utf-8?B?N01KWnF3bkFpSDV1a1R3bWhVR1ZGNEc5MXg0SzdhZ0lyV3dab29PWldZM0Jk?=
 =?utf-8?B?bGpiWTA4VUZDNnhNYjVUbEErRlZpOC92RnRLZ2pYWGJ6ZjNCR1N1TXplZGhv?=
 =?utf-8?B?RTVQcGY3WmlleThINWJDTlZjOHZrKzhMTkxFNy95aDhDRlRIL1FKNmJVZmNE?=
 =?utf-8?B?Ni9Lc0hVb3RzVUVjbzhkcnBSbU5DbXcvSkNrMU9uRVpiTmtzVEdlRjZMOEZD?=
 =?utf-8?B?cURLQ29xS21tKzV2ekJ4R2FxTG1OZ09lTU94UFJwd0IzM0R3eTBsYlhxcVQ5?=
 =?utf-8?B?Mzh0SzgyQlQ2azlBYkNyT2JheWpwbFIyMDRBWXZSRXB5YVpYU2VJSHV4WjBT?=
 =?utf-8?B?Z0J3MEpnQUhKUVk4T2pEK2xBUzlMTWppY1ZHVWdVRXdGR0gwdkhjdTZQNWtV?=
 =?utf-8?B?ckdHVWx4Q2lKTmtGcnVURTBJak1WSFhTa2lsb2ZIK3U2eTFtSEFBVFZISFFX?=
 =?utf-8?B?eVpIbkJwYnJHWEtINVF6eVhsc3lWbWMvQUxTZTJtSjExMnltZ1BvL2l4MjJL?=
 =?utf-8?B?ekN6Q2o3SHhrUGZidWdaUlZjOTdNMHNMVmFUV28rZHFGZFdCWGF0T1A0aU44?=
 =?utf-8?B?d0JYQlJocytHNDE4ZW1IKys3Q3BZRVJjays0c0cwQWZyK0F3Z1VsYnBKUUZy?=
 =?utf-8?B?cVVnNGZ2d3pjR3paaUkxRXZBQUt6ZDBtUnhHcVpRcGdzWUZyUnEyRWlSTG1n?=
 =?utf-8?B?a1RKcjJ5NkVRPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(42112799006)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?QkRVajBNd3orSkdITmVSR3lPQ3QrL0d2VWRvd0N4a3NpdkkxMDVLdWUyQi9B?=
 =?utf-8?B?MlNXc3JoczNnV0t6Ym1SRzdOSWl5V1VueTJFWGJpd1lKMFNpRGxvODQ1S05D?=
 =?utf-8?B?aU1LQ3kzcmJ2YXZXOEk3N2ZiSDFzZ1lSbGhsNlB5NEROTmdHaHoyN2pQZFA2?=
 =?utf-8?B?eDdlTDVPRkR4a1kxamFiYzZCcWlSclZQcUVsZmduTGV2Z3plNHA4Zk5OK2Yy?=
 =?utf-8?B?a0lFVW9yVVB3YTQ1RWJ1UllhdVJ0SDZWYVROZ2o0dnJaUWpHS2dWZzM2VENy?=
 =?utf-8?B?U01TTVlmem9sUmtjVXYyVFQ4WGs0MTZTVVM5VndCVmpmYytxUjdBenZGaWcx?=
 =?utf-8?B?ak5KUmljYTQxR1JlUmZpMlB3dFc0TGZtSGNtQm5wYWM5aFVOK3lWeHhuZWtN?=
 =?utf-8?B?WXo4cmxRTlE1UUp2Y0t2MDNjbmZCb3I3TVZFV1EwQXBZSm9jR3RTUlhjS0NL?=
 =?utf-8?B?Qm5wSUQ3VFc5cC9lZ0VWL2EzdldqaDJmZUtGYUpnMmVxY1crL0pBZFRlVVhp?=
 =?utf-8?B?c1VGWUpHTUJONnFpZHBOazVnbXE5VWs2cFM3ZnZwTW9Zc0hnUVNic2JkQzRz?=
 =?utf-8?B?bGViclRpRlNkT2pyRkZMYUVQZkowZzlMNkVDOFJwUkdhalJVYVhVWXlyQ2Y3?=
 =?utf-8?B?M3VreG5lZHhIZnU2MlVBdjVGQXZobzliY2xkM2lQdk5nQkc0UzFSQzQ4K2Rh?=
 =?utf-8?B?bGRKc0RHQm4vRE9reHNqSzByNEVGUHBmQzR4aVArL052WEFLTTlwQU9NWlk0?=
 =?utf-8?B?MVRWbnBvTFhvdFRNSC8yMTN6b1kyQlMxak9EVzdQejMrOTVQOVE2dDd4MXBM?=
 =?utf-8?B?bE50K0F5L29LOUFOUUJEQ21mYlBQVnpRa1lMU24wZTZtOXRndnFlQ0dCMlEz?=
 =?utf-8?B?SVkrZHQ4T2J0cDVLTExDS2Q1SWJEL1dxR3pKSmdURWZ3UmZLZHZOU3ZHOEN0?=
 =?utf-8?B?VEtVYytiQmN6TzY5K0FLWkNtcnVPNlVuVkNrZG1MUXcvMW1XU0kvMFVBUFpa?=
 =?utf-8?B?QnJYQnE2cXRFVFRocmlwcldENTlDaEFVK0xGejA0K0dnTmkxb1BFRnZYNjdl?=
 =?utf-8?B?bnNORVlvZC8vNG1YRUtEUGxBdmZZNXpOUlcxTEE4VE5BV0NVVnMxbEMyOGJM?=
 =?utf-8?B?VXBmMHBudDU4ZFg1NTJuSk16UXMzL2VqVlFNd3Q5NHFLOGNKQnBuVzhjTVFm?=
 =?utf-8?B?VVdVZExkVkRUSHN2MC9iZFhQY0hPNDV5Z1dYOFBzbFBwTHUrZmpOSXRKczdr?=
 =?utf-8?B?TjFRNlZOYWMzdE1yN1BGa2VhY2NvcDJIamF3c3c1aWQzV2V0ZWdvNWErTEVx?=
 =?utf-8?B?YWwyWU8xblk2U0dUVzAvb04ybEptaDVwS1MxSytRRlNDSWl5T2xLemtZOWpC?=
 =?utf-8?B?d1NCMUlaNldraTJub3BoOE1NbGFCOUpTSDdGOVF5aURGdHlHVHJObWFGUUkv?=
 =?utf-8?B?YmovaGRLWGVyUGpBeU9LODV1R25SOVhDMFFIczdTY0pmbENZNUhqSWhzTGlE?=
 =?utf-8?B?SXlvSkVGSmJpZ3pKbkY1RkRlc0FKR1ZHVlhCWUc2UGs3alIzS0plb3l1WUVq?=
 =?utf-8?B?M3pzSUxYa3Z5bEFOZHV3N3F6MWJiaEtMcDI4UnVIdkVRV0tCREpnS1hQcHY4?=
 =?utf-8?B?K1lQeTZ5NEgvZVFnN0laK3FtUDRpdmFhWm9pVVRUS2oyYkpaVEo1MUZ2dG9a?=
 =?utf-8?B?ZGdZTVRNVFAzWkhnYnVmU0Y0WU11RFlKaWZHeWhBaXdYcUpoNWdoTEI4bEZB?=
 =?utf-8?B?ckpUSGYvWDZvYXAxckVwTmx1b3oyZUVmaDhKbW9qendQdTJaK2RNU0UrWDA3?=
 =?utf-8?B?VGV6SkhycEVlRkxPS2c0SEFFaEV5VURFa25DSHRKeUF0R1pwOFh4c1lhRmJK?=
 =?utf-8?B?UTYxcnFWc1RKQWRPbXpVWWdwT2RaNFBBN1Z1QitaL241RzZ6bHV3RkViTmVo?=
 =?utf-8?B?cGY3SFNuRUdIWmhURHVLWHVRR2hPR0hDREU0bUE3YldiVi9kZDNuaE1pbkJ0?=
 =?utf-8?B?ZWJQMVpLd1lMSVU4cDlvVjJ2OXp6M3Uyb3JYK1d0TEZuR2g0emN0aDZhMGp6?=
 =?utf-8?B?eFVqZ2U3TkJhYzhielZvTHNHQ05YY2lxR2ZpT2EzRWJNbjRGT3lIcnFlanNI?=
 =?utf-8?B?dGhBUEM5azRWY0V0ZHRUcmZaYW9lRUdQYkxHc2J0QmJJb2g1RVNTcVlPMjd4?=
 =?utf-8?B?QXc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2D74CE083A2A054891536B0725962970@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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2add8418-72ac-4c5f-3a45-08ddfc67486c
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 19:11:08.3288
 (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: JxBFqDvniiIgphgbGWx8SLFZWn13+HpnlDigIjCaaIsQfuaBBtl8I4J0fTIfvENVUe/z6YcCvXLmxOn4WR/LGppHzQFCGTVnucBiquCR+O4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6678

DQoNCk9uIDgvMjUvMjUgMTM6MjMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNC4wOC4yMDI1
IDE5OjI3LCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+PiBNSVNSQSBDIFJ1bGUgMTEuMyBz
dGF0ZXM6ICJBIGNhc3Qgc2hhbGwgbm90IGJlIHBlcmZvcm1lZCBiZXR3ZWVuIGEgcG9pbnRlcg0K
Pj4gdG8gb2JqZWN0IHR5cGUgYW5kIGEgcG9pbnRlciB0byBhIGRpZmZlcmVudCBvYmplY3QgdHlw
ZS4iDQo+Pg0KPj4gVmlvbGF0aW9ucyBvZiB0aGlzIHJ1bGUgYXJpc2UgZHVlIHRvIHRoZSAnY29u
dGFpbmVyX29mKCknIG1hY3JvLCB3aGljaCBjYXN0cw0KPj4gYSBtZW1iZXIgb2YgYSBzdHJ1Y3R1
cmUgdG8gaXRzIGNvbnRhaW5pbmcgc3RydWN0dXJlOg0KPj4gICAgICBjb250YWluZXJfb2YocHRy
LCB0eXBlLCBtZW1iZXIpICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+PiAgICAg
ICAgICAgICB0eXBlb2ZfZmllbGQodHlwZSwgbWVtYmVyKSAqX19tcHRyID0gKHB0cik7ICAgICAg
ICAgICAgIFwNCj4+ICAgICAgICAgICAgICh0eXBlICopKCAoY2hhciAqKV9fbXB0ciAtIG9mZnNl
dG9mKHR5cGUsbWVtYmVyKSApO30pDQo+Pg0KPj4gVGhlICdjb250YWluZXJfb2YoKScgbWFjcm8g
aXMgc2FmZSBiZWNhdXNlIGl0IHJlbGllcyBvbiB0aGUgc3RhbmRhcmRpemVkIGFuZA0KPj4gd2Vs
bC1kZWZpbmVkICdvZmZzZXRvZigpJyBtYWNybyB0byBjYWxjdWxhdGUgdGhlIG1lbW9yeSBhZGRy
ZXNzIG9mIHRoZQ0KPj4gY29udGFpbmluZyBzdHJ1Y3R1cmUsIHdoaWxlIGFzc3VtaW5nIHByb3Bl
ciBhbGlnbm1lbnQgYW5kIGVuc3VyaW5nIG5vDQo+PiB1bmRlZmluZWQgYmVoYXZpb3IsIHByb3Zp
ZGVkIHRoYXQgdGhlIGlucHV0IHBvaW50ZXIgaXMgdmFsaWQgYW5kIHBvaW50cyB0bw0KPj4gdGhl
IHNwZWNpZmllZCBtZW1iZXIuDQo+IA0KPiBJIG1heSBoYXZlIHNhaWQgc28gYmVmb3JlOiBUaGlz
IGFsbCByZWFkcyBva2F5IHRvIG1lLCBqdXN0IHRoYXQgSSdtIHVuc3VyZQ0KPiBpdCB3b3VsZCBh
Y3R1YWxseSBiZSBjb252aW5jaW5nIHRvIGFuIGFzc2Vzc29yLiBUaGUgInByb3ZpZGVkIHRoYXQg
Li4uIiBpcw0KPiBhIHByZXR0eSBzdHJvbmcgcmVxdWlyZW1lbnQsIHdoaWNoIGlzbid0IG92ZXJs
eSBoYXJkIHRvIGdldCB3cm9uZy4gU3RlZmFubywNCj4gTmljb2xhIC0gd2hhdCdzIHlvdXIgdGFr
ZSBoZXJlPw0KPiANCj4gSmFuDQoNClN0ZWZhbm8sIE5pY29sYSwNCg0KZ2VudGxlIHJlbWluZGVy
Lg0KDQpEbXl0cm8u


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 19:56:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 19:56:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130796.1470185 (Exim 4.92)
	(envelope-from )
	id 1v1s4g-000457-UQ; Thu, 25 Sep 2025 19:56:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130796.1470185; Thu, 25 Sep 2025 19:56: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 1v1s4g-00044m-N2; Thu, 25 Sep 2025 19:56:18 +0000
Received: by outflank-mailman (input) for mailman id 1130796;
 Thu, 25 Sep 2025 19:56: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 1v1s4f-00041Q-Gz
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 19:56:17 +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 b24d7644-9a49-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 21:56:16 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DB4PR03MB8516.eurprd03.prod.outlook.com (2603:10a6:10:38f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 19:56:08 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 19:56:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b24d7644-9a49-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q5CWZmKRBCU+KVzvIP+LEgFEu/CoEj3hLep2Gtc39MPc6UJz0GIj0Pi9bYjtZABzW9ObCNIpd68AJlhT9OfKa55qEG1UbH7E8nedDgy6BL4ExKLUNqPT9bCuer1wrFuUVIiZSzAakSqvggJB7PiXIMECgPDG0tz430JvX+/ToYNNZYwuZYZpQP5Lib7PVwdgBtI5uizzCNQJFtp/yMA9GRNrGUg8OJ3RpZLpsyA55XDY2A3N4jZkg6uUd6hZidwOsm6g2O2Mto5N0BeZuvSckHILVugRmvYHpnOjWN4L9gW762pca/+dU2ot/QdtgLp4rZRiDtr2Gm7mE2fjqCSNQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dY1u4Kifw0Qjg1VPQXbApa6JsxI2wU/3D2Mww3XVG9s=;
 b=frLOPQht0u//wncbDil7z0VI3v0yt5ePkuFd4PpImaBHU7EDKQdgskyJYFTNXtV0eLUfeHjdoZD+q5jj1AZnv88+T4R4JXbCHUAvPK7rr3lijKgDo/LeLFIY8/r/DH1wnHn25iGbK1KABVnJRESqXmE4qHmJ3ZT3voSBTUePnRh+Oukyj85Abw3ln4jPKEtrlzlmMeoLKb12ogB0wWs88NrZ8q5pjVpZ8UidVEpW19ao5spcvha0EWIW56p+7K+quIz2UtddKUuCvOzJyN5GxvVK1LaGlFjKGJQSx6He9hf3J+fqEJKwzjWo4qqUx1yqRgOgYX8g8DN2fKBbkmhLyA==
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=dY1u4Kifw0Qjg1VPQXbApa6JsxI2wU/3D2Mww3XVG9s=;
 b=t9AwQGnAC+yv/0oxX4K4sO+Nyopk4vM/k+ivnrBLV7qDA1DtxPCona0RO86GUFW+V+GXVQhhL2Hc3tEIq/r9Ubb99GFuH/1WIq9jfScI88ev/5IfJ3l0o+2e+uvy+3FnYsxoS7dGiS0bjm9K2Aj6e6joa1nOkW0uYVGgZHllemgY7GlbmezRHJ9lfOrMk+8+2ZXnskaXSCGCRtCC9zKqWWEU2aVcAt/PHLCGfNuMlPBy4/qw5x81y1A6K71FOk2WDpvfFnBSowaR1R+kgvYlgAYViXdWFgzgMD0nH65YYsP2m/uYv/hPVY9X/LC70fpkvng+oXmT/aflPu5RIzc3FQ==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alejandro Vallejo
	
Subject: [XEN][PATCH] x86/hvm: mem_sharing: add dependency from
 CONFIG_INTEL_VMX
Thread-Topic: [XEN][PATCH] x86/hvm: mem_sharing: add dependency from
 CONFIG_INTEL_VMX
Thread-Index: AQHcLlZvmNyA5ChnWE+hK8ZrAp/wbA==
Date: Thu, 25 Sep 2025 19:56:07 +0000
Message-ID: <20250925195607.521021-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|DB4PR03MB8516:EE_
x-ms-office365-filtering-correlation-id: 8234000b-a3f0-4ce0-53eb-08ddfc6d9197
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?C/sh87aSYktVYiuThsNSwy60DAFOaJJ7KiGU1NG1ttY7hp9vzXhngBBpS9?=
 =?iso-8859-1?Q?Qgw38i/nkDF2Mj51qE/UDsZbQAGF7MCLOJUGET7y2lcnwVY1QHPxUhSVJQ?=
 =?iso-8859-1?Q?Hba28Z4WdO7TdAdCVqhzKmMtdLKSIK11Ee8ei32EuDx0FgffA0YPXMScw2?=
 =?iso-8859-1?Q?PCGoS695SDQhOEe3dnq00vQnAC49k76It+WDVxwbxBV5jMQiWbU0a05CJ4?=
 =?iso-8859-1?Q?ns8IVngG1fVdPqbh6aYZQ7zmgmZMZlRkcti3IQn4hF2ZB802QU2w/cZhXd?=
 =?iso-8859-1?Q?WfVPKa8jLM8Z7ZQBVLIpYVBYUYZdwE0oYEnETiQeZNH+OAYmNVhS9EeLln?=
 =?iso-8859-1?Q?mY3hetzzXbVNtB/j58cizemLyzsIM26pQYlLtj0xsd1TvgZnlsk/wjBBta?=
 =?iso-8859-1?Q?CNelmCA5HAzo+PfYU6rOHwqJJgqGUCnUXkLI6cZumKDBTdz6Au/up0huxw?=
 =?iso-8859-1?Q?gtdazW9C3Yoq6/2xGaC1i07dCXHl734/c/6PfG+aJPZO2UroYaY1WdTnZf?=
 =?iso-8859-1?Q?3jHvwtAiJzJKhlJycPw6/5w8AZHDLHKB72bv7Zjne7gLdLBIpKRMfyEi1D?=
 =?iso-8859-1?Q?+J1hNDIgf0lGRtapfaaBjIwu5PoTmsJpLU6gTatzh2M9QACySky9EBqB71?=
 =?iso-8859-1?Q?mN2lHPxGLooXExAKbZsMAmzpGDVo01kObfWNV0CvYIzY0kPI6kjpr4iYYR?=
 =?iso-8859-1?Q?Nzq+HiM12XswuS2NY/BBF7bx0JSd1UINPOILpA6gQD9nNxHU7ns07MMqZ5?=
 =?iso-8859-1?Q?81eLi69UBtHPgTiMyAa7UftZSC5PURv2TPKIGqMC9RCfCQxa2/n+Oksfat?=
 =?iso-8859-1?Q?gYZe5GOqMv0XgW9dXVVGRxxRrp8Uys84JrXlGw4k6sUGMscADPOVWWXmvD?=
 =?iso-8859-1?Q?8uIst3UB/VfSs/sY0A+X+KqYlEtIMwEJb0GaoiQjOOybXMKS49PoDwsGOp?=
 =?iso-8859-1?Q?dTOXf6oJ9L0/t3+IXPnwCWswsyWOtKiAqG1WXB1IWvP0Px+fpr66EbS8We?=
 =?iso-8859-1?Q?Yu79ll/JNfmSvY+FwOM/mOR9OqGPkfvvsLYFHr0HS7tiud/SdL/RoKhgp1?=
 =?iso-8859-1?Q?q2UcBs7O2I3rXzQ2byQgtrMgG3dC7XwCcfuI94YzR3n7ujLhLFJ9crv8KO?=
 =?iso-8859-1?Q?YLyBaUOP5tCcQgu0gRJg85R7QGtViFv5MSFIQoQAzz5RjEkFkhZJLVkvpo?=
 =?iso-8859-1?Q?LIAPZzJchhdGKgpq37We/cBXeRKJkofoYNyeTZgcAe3YFCJ/G11HP8Srjw?=
 =?iso-8859-1?Q?Fbe3N+sKDyglhWHHiuv3QFFpgVcN7CyZoXpRChVcM0Fm8B3ayc93vFSXmX?=
 =?iso-8859-1?Q?2YJg7RaKgyYDJlrn9jDtdgATmMMogzSlneWXG+qWvpQDsejxU183kRC/V6?=
 =?iso-8859-1?Q?X3tohW0q1eqDmP8UUOOrlcYRH0gPbePLF52RD5VTXDDJiom45l4j/pZTIP?=
 =?iso-8859-1?Q?EVSh6EomGQCT0ntH3LxhiWIpaZF8sPSP7QjHLBL22PhOEIq0g5JbaAg2ly?=
 =?iso-8859-1?Q?/akHHImgK5SJriCquLahiQ+t0r1RRXcS5dC8SyVDrX4tlbO5KzIxOdzVpl?=
 =?iso-8859-1?Q?Hjxuc9jDCLnsTa3JL0rWb+a34L1L?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?INaILMXTRh5IfNtA4nb7b1XW3tQpxsdyY7P/3O0SvVGiTEqLzg/qNsVG6u?=
 =?iso-8859-1?Q?0rSXgMig0k4jDgMtzWX6pBR2FGA3SeySbfwXTerF6T00ctqHxWHYmPLKuJ?=
 =?iso-8859-1?Q?XtT6UfaMbaSwghFnDKXdgwAvni3fqVPJzlvCrUlb+Pz7MiOQE9ZGwD+hmc?=
 =?iso-8859-1?Q?E4AuvtEmU4reEMZH54el/NbGGWMZDI6UkQmNu8VCXgrkFSzP8Rm6pVlOl+?=
 =?iso-8859-1?Q?uJjWXaiXB8hQD3D5OPvo7moT1RQAFc/7mVEHhLGEOXzy60Py6xkDp7S9Ds?=
 =?iso-8859-1?Q?rKsB1QgT2CnU5tEdJyPYQtVRzIXa1ebTyMHhmL1EIDYQt1l/la0Jp8gDVV?=
 =?iso-8859-1?Q?xG99hM+b0Z7HFW0fQXQu2kTvTaMrb/WAE8sbYlcFxh4ebC+CjtLARd2kIF?=
 =?iso-8859-1?Q?leVjmOl0A4c68xQcOacWI5I7Eql9H5/UBQU4rwHEqTMMORFDrEAbN0iN6J?=
 =?iso-8859-1?Q?SXf1O+/SNNVj7WkL95EZuT1XX/uc+GBZaCktSmUv66Q6SerVP/1XtyODKK?=
 =?iso-8859-1?Q?1nT+7g1y0lmISjo5dgi3Ip8WjpymQKvstPZ3ygU2PBd3MWX4VU4q3S8zx9?=
 =?iso-8859-1?Q?VsmO007bSch5mbs6Ze8Vcoz79k7YmO9qJKriHhabJ9Vl8MTGpVhX9y/C75?=
 =?iso-8859-1?Q?ITtuARsAj7vqgGobFs0KeBTe1agFzpkalDf9VNWFJAm5fhuqFDvOKlsz3G?=
 =?iso-8859-1?Q?SUBr2GsuQZJTOUTcIdIut7ltb2T5xJdFGF1bnneRlYddPmuPyBvJ6acY4s?=
 =?iso-8859-1?Q?TzXmN1bmr1+SZRDkejRWAmO2GiC1AN7EXDFBCIr9IxChJRcAzrgm21o+Ia?=
 =?iso-8859-1?Q?cptqdwL8Ii2qo4Xt4dfLSTQgxjUaLLsr9zLahUEeXF7w2p4XxWNPv3SCN1?=
 =?iso-8859-1?Q?UU3rcdJy2kfPm9R62kAmT1GSReWN66RFmQIrcuYjfihw2Lh+AyL7fEyMbR?=
 =?iso-8859-1?Q?jc8dqnDsnw9OfIccLXWBIni8+WfajffMLNkJIooGYstxGih5chSSeAB0HV?=
 =?iso-8859-1?Q?97mCYt30e/2lRWC03NkefHh8vBxURviLBK5TLElKh6nWf9l4fLNnI2V2nJ?=
 =?iso-8859-1?Q?TMy+jgkaDNyIci1lqFNMDvX7VUNuarxXANNRbIUEL9WC85kzT/MKXmzeb5?=
 =?iso-8859-1?Q?h+UQ1ZUIFpWzk0n2fXqxMl1NrjuE8tTesP+96ndDpOgXqefrNn5jKm+BJG?=
 =?iso-8859-1?Q?1LyDj8d1iNO8438K7MVhjJbMCh1HCxP4qPwTidfvBRCGfW7ax7Lk4pAbvW?=
 =?iso-8859-1?Q?QxXMdol2iVPAKaVNLkAF/YqLd81dNWefSES5NB6q017V98oMLNqm3KDKew?=
 =?iso-8859-1?Q?fpL2IHsfOZkk45lKH1tAraeDHfH6lWyLevGltcU2I+jxm5rjCpg5DoLvpK?=
 =?iso-8859-1?Q?VTEIzBfVMlh7PMYZf8A4P7NZ8HOjlY3zO1T/V437Z9iBs5u8uBlcINMkTp?=
 =?iso-8859-1?Q?dz0d/s8hZkaRZHGFYqjOZEymCC2yV+4SNiPi862YRhNB5FhlhmQcQB3wty?=
 =?iso-8859-1?Q?NydRYhGCztWozKDSHWLFfZUVXFxEFMQsCgxqMNkry4OS8AYAKnpbMjk8dI?=
 =?iso-8859-1?Q?JqxXZ4W/7raO7KflyHoaMDANi1HG/sFaj2ySKa5O3azDYHVBxs9KVlOAFh?=
 =?iso-8859-1?Q?hjLm8yLbe8z4MGMxjnflxJrH8H2BLxOO0h7ER2Ha5OfpzOGpd8OcaBbA?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8234000b-a3f0-4ce0-53eb-08ddfc6d9197
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 19:56:08.0378
 (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: nqhTKX+mwWE2qqK+ySkrbIIP6cwIQdNtdrjwjX3nt9ZvHK00Obj62OelPy5oEmmolnipLPvJ0NOAj6Q+3nPUj8GtGQykWUJqjqs7EAvAoqw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB8516

From: Grygorii Strashko 

According to the commit b66e28226dd9 ("x86/mem_sharing: gate enabling on
cpu_has_vmx") the Xen memory sharing support is only possible on platforms
with "Intel VT-x" (INTEL_VMX=3Dy) enabled.
The same commit is also added runtime check for "cpu_has_vmx" in
mem_sharing_control() which blocks access to XENMEM_sharing_ops if
!cpu_has_vmx.

Hence add dependency from INTEL_VMX for MEM_SHARING Kconfig option.

Signed-off-by: Grygorii Strashko 
---
It has took me a time (including digging deep in git history) to understand
presence of this dependency, so this patch. Hope it helps other people and =
they
will not need waste their time digging.

 xen/arch/x86/hvm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index aed799fcb9c2..d62492d2043c 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -79,5 +79,6 @@ config MEM_PAGING
=20
 config MEM_SHARING
 	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
+	depends on INTEL_VMX
=20
 endif
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 19:56:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 19:56:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130795.1470178 (Exim 4.92)
	(envelope-from )
	id 1v1s4g-00041i-IJ; Thu, 25 Sep 2025 19:56:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130795.1470178; Thu, 25 Sep 2025 19:56: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 1v1s4g-00041b-Em; Thu, 25 Sep 2025 19:56:18 +0000
Received: by outflank-mailman (input) for mailman id 1130795;
 Thu, 25 Sep 2025 19:56: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 1v1s4e-00041Q-TM
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 19:56:17 +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 aa7d99bf-9a49-11f0-9d14-b5c5bf9af7f9;
 Thu, 25 Sep 2025 21:56:03 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DB4PR03MB8516.eurprd03.prod.outlook.com (2603:10a6:10:38f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Thu, 25 Sep
 2025 19:56:00 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.008; Thu, 25 Sep 2025
 19:56: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: aa7d99bf-9a49-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mLqJir9+aUROOt4NrSsSK0UjM83lSMKXQzvMU5NTqvnambZIc5ZZSAH4I8Aev6AgBSCxmEE5/pL7JaVJrPSPyUrwnTxON5p3kKiYSqTiAYoUS5bDkygdu2mzeqmNon1W+ss+47PnXEE3yVuKp4VQ7kjEikol6W8VPYYK/9eUl/ZJNbz0TStrSkJ6gFiBMgLyTydYWJ45yWaqzq95mwcj4yTBD+d4SlKeM7uO75UXUxVHtN7bxOnw9sVL1e3Od2qp87pSsQPmVd8CLULM8u2cY8/3NVzsipd7Yjy3qjaU7DUI2tYguR7vhthrhR6kSuOsCreQxktrTbmnDjD5HNyMmA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gzPredjRp3u8PrwWB70yDOQkOKdPO3jfQAYUIuRpkf4=;
 b=XEKHW6BYZdc48buQNlsBqmMQ7uFmU7yNeDC1ISE7m1nEym9r9Xl1j53D7jWYKw9SCEumAPi2OC4taMZJ9ykVxeWmF4asE/L0hopTIEXPdMk2hsdmddcyZXpACZfH2Y7C1eSLVeAOK1ORXxWMh7Rt+jo48A9q4lKTgBrhAx2T2lhcP6eeJN8tAyJy+FlhJuLPMg6SAplSUpohaF5GM517R6VlfUOhcFl2/qXX51jH8NFDSMman+o3LzalqkL/W0M6REkE4EFy+Y41pkxn4ub/QE9gVya2IqeNBKu3xPliEgL2Vaq2eY0GXBCAHrHkbK+9ebnGEBYdJ2FKFa3d+bsTnA==
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=gzPredjRp3u8PrwWB70yDOQkOKdPO3jfQAYUIuRpkf4=;
 b=Upo37Jqu54sQYFHDiMGmrmYHFRSU3KIThjDlZM2DmDwTi6uhCV1FgKvITAP6Em9TjAQoFCWPRIURmj+Hx8e7gjgY7MflrbanKQWZZdwinstm5LdUIeb25bMMPLpAsZpBuq1Q5mTUxw6d1oaLLfyQzkFsRUMgYdrJR7w8zL1N/XK4ZJ1u6KUYWvchmWh1vwYPKlOQ8gjX0u1PxOkAzevI+YWbmBOCYVdkpO0Z4vxl66Xj19rxgS+1raJttymW9epOdtzOdHdBpi/PlNT1R8TL8tY0VaKsjouLoSG8Mk9TFJ1ZDmOTgw2Bvev3pNLWb1xBOcTncjJcHVQz8FAFC6EZyQ==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alejandro Vallejo
	, Jason Andryuk 
Subject: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
Thread-Topic: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
Thread-Index: AQHcLlZqbf0MGzslLEaqcqespx3CAw==
Date: Thu, 25 Sep 2025 19:55:59 +0000
Message-ID: <20250925195558.519568-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|DB4PR03MB8516:EE_
x-ms-office365-filtering-correlation-id: b7e70640-fd23-474a-fe86-08ddfc6d8cde
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?DY3x2yoNzGXJTQtbsX9AvJr0k0OE/dnhmOPqNupD4szRKAGmfv5haTX8wk?=
 =?iso-8859-1?Q?40KLQZ7gvNla4K6kEwSCCB7MiNFlGiJ9RK257Rer4SdvNTJIFNiIUNb0T3?=
 =?iso-8859-1?Q?pBVS0bWABzD5M8opQcJA3bNiKr8Ry8W+6ftItddDDx5pxR1CDQT1HXy30O?=
 =?iso-8859-1?Q?nEQni1JxTFZk0kUfRGK5IB7qq5Xzri4lWqbwPyO0QvFPK2RM+Tde+jzjrO?=
 =?iso-8859-1?Q?p7WXQ48T8z6FT8mVLJZFKzNzhcx6qSv5Ae7CxKQxnqLIRAr37pCs4REooE?=
 =?iso-8859-1?Q?+CDVIImfDXla6Gcx2WMG12cOzeIfIGjmqPSe2ggrM+p1FcM9slxAUXhbK6?=
 =?iso-8859-1?Q?7VHO0AaLBoxC0XmOJDUN73FXlFajrr5k7vrMhVoxUBhctF9tBeBuhENdWW?=
 =?iso-8859-1?Q?3i/3ODhLb71FQ0ZqiM4PHbZj6TKrDydWunuIw1t0o75uoO+YOXuet1bxLF?=
 =?iso-8859-1?Q?HzgUOdpBLNlaRxOgLlLxlBZKdm4QmnMAHe3dUpA38u3AcwCd/gGpxxC5f2?=
 =?iso-8859-1?Q?LKT4xHC08E3n/NqvWSYGDN+KwYp6cYThVwaxaMnC7Asl5cqMdadQrtkC8D?=
 =?iso-8859-1?Q?FDWMbPO7tmnSX5PUeQZzmXsqkrbJsyMXnEnNnUVpT4ZgiqRM644pkJD/+c?=
 =?iso-8859-1?Q?LZQvLCU3sWLSNkk2wSROlFzNiXi3O43ibRMNFlQ8XfgXIUf4lXRWEbNcih?=
 =?iso-8859-1?Q?7cvN9H11j4dXnwo+4wZtOA47WbECMBMZWFi1bFTaDxq44SxUpk5kQFXtgl?=
 =?iso-8859-1?Q?CiTr1/IsPiFPwSx+Dh3o8v7COuNQNjX2U2YcGzRQj6MKffgFU1W3ZXPM4i?=
 =?iso-8859-1?Q?MwiwU6LQzSvixPHDcibm5XS4rWMxWOa5tif3SEICxej4wkUdgN5zejEP00?=
 =?iso-8859-1?Q?aF0kGlqU3b795v4Lg7GSS1ZuUYPiIr+QFZ+SbkvnGxyB8bWiTAWYG4diD/?=
 =?iso-8859-1?Q?1zg1zio7CXz33svALyVo6Ii/mjD13ka8/uqzjSGndZgYRhDrg/+ilvD0T8?=
 =?iso-8859-1?Q?SlZLuDG6i9MLqGcyezPERD5WMSNgHOx31jNgz8Es+BUgb1JADn2njUUuED?=
 =?iso-8859-1?Q?o6qDULgRrCm9UthS+NQ4Yw4PNnJEcFkWaUGFPXGukdrf6abFjXjaBFFpQn?=
 =?iso-8859-1?Q?6gdksLWXXXY/A66ghcJL2VIc2bcqywmUn1R4nGimDmdzN+EOtwg3GUnTE4?=
 =?iso-8859-1?Q?E99iy6H1VgFLWlIBNtz1r7XPq4RKEbXcQ5bGv2Cd7urUIWjg7Xbowz3SsN?=
 =?iso-8859-1?Q?tTlOrlT3NKUWKHNbU86weYa7vIzyuJmiOB3DVFA2pdRLjp0NQ2Yd2JVJxA?=
 =?iso-8859-1?Q?rEOMl4rlozDX4Iqch2HTuuPaOYMrLXhDb5oJA7MXvVqeIW1qSGsxtblbKn?=
 =?iso-8859-1?Q?1E0IBatwF4SWKEg44vglfCqtM+pwdCQ5lrFML/TjLL0NzpIMD1UDPsip1e?=
 =?iso-8859-1?Q?wfqrD0Udx0QyIFP6YRpCC8tjp82pLCBMbkckrcjxcjXsxPL99/obkLIwrm?=
 =?iso-8859-1?Q?2QFA3/rad87hKe3/RBPVRjNhic4Fx7T4yNG5yIouM+Nc7YyA2Os1kdIr/Y?=
 =?iso-8859-1?Q?frMq6k3NLWbhpEt7Ia46w/EjlRFt?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?iznMBIf4bSEWiVkuq3SxrY3CCHcFCjveDXOh1nxIAe3mGiI3G4GW0Nxi/j?=
 =?iso-8859-1?Q?G6xG4hga4VIxVq5Ol4SKQyzb0SjW9QowgKn3h/I8YNW7HOtcDJosKhGO5F?=
 =?iso-8859-1?Q?B3JVBH9nJJhIcE0yZjr+4CNPGisTaK+GIY+3ZeogIWvO7EHCOL5KYzpDSy?=
 =?iso-8859-1?Q?/o6p4RYlX032fsGYp1y2XxgCmNU3f+QR2qi9VZtFaUwMAzP5f3yFcqSXP7?=
 =?iso-8859-1?Q?j9XH4dg1lg/wfOAfakMRkftsIJRl8pDVunqCrjF65kVvQizPcZ6WWnStPK?=
 =?iso-8859-1?Q?rCmTfIMZmpbqVRd1q2pY6cVLNZa4mnDg8fsexYYejRjwE5LCTzsCJSq6zK?=
 =?iso-8859-1?Q?z1bi/2WUt0LGuTBG7iQJnaPqF45pmFZpNdbNiKPyEjwKHaqJK9/haETB/c?=
 =?iso-8859-1?Q?UXn5+csJ1+Z3FcVfs6H34hBUlnUtRQmHO/Pnxbv1k9QCXJa16enXzW8Zxv?=
 =?iso-8859-1?Q?4UAYPV9wRIzNAdOjKHkolNSHtWEhfBWs+bmEBa840zKWHV9da4xzwHi467?=
 =?iso-8859-1?Q?fCP2AfbXoDdNaTAmAZc1McBMxf4dXVB6Ss7ZErho2DzLsNQCZmCOCqbrd9?=
 =?iso-8859-1?Q?9zm9o2k/8pHKs6NNEfqwpA55XOKabmhVUuPzQr7IVHYt40FGST3SWTZwyq?=
 =?iso-8859-1?Q?okyAfnFqzwUgVjEDApUWtf/U4byMRKG3Bg2yaTBRVwb9jJUozpvo7lSW8j?=
 =?iso-8859-1?Q?k73OvhIzgbdf2oclMAHVNucCaVaio9/JhmMHKE1uodCmcW8v4JABzPbm7o?=
 =?iso-8859-1?Q?WFclE4R457vWb4c0Xe3NOQqiJBi4uIsBRxe9ghxU8CqeeR/DKg9k8iy9+/?=
 =?iso-8859-1?Q?b6neQxfshA6aShP5b2IjVY+zlPoQUQae5WLFoq3yIWzo8tHVDHXnWd4l8V?=
 =?iso-8859-1?Q?5z8m8NNXkexJw/QMFvw83R5asiaLh7YX1h58zI9uDPvRbH8//vifh4lFl3?=
 =?iso-8859-1?Q?jDmbJ8zSWaoHS9tR0rdVA/+xvWJAGX08Dr8ShkcMvYl/4ajrfvNiiRdiXl?=
 =?iso-8859-1?Q?RQ5Croma1/EpVp6lap6rEXzbv/+vrihMT7RHuGAqGm9iBeqm7wQGlNit1c?=
 =?iso-8859-1?Q?pRU7udXXjQ4oqZrl4WpBWmpGxYt24MQgzMlBFD7ZbKi1C+mLZQKbStt1kN?=
 =?iso-8859-1?Q?gSw30aavMRN/U1zgVjZ7Fv2bvfUC+n2my4BqF0jiC/THTkgPxIIRh9d3mN?=
 =?iso-8859-1?Q?/ClqhEvs05j9F9SZ1C0YJA4irpibW95/8MxkaPr/qXtCG9SIVHWbAPxVzA?=
 =?iso-8859-1?Q?85C7ti7x8lDdqtHZ7KdpmW9/LINRtiiCQZv1Kv4SmfJalH32vHhaPFXKFS?=
 =?iso-8859-1?Q?ywT15GQxoaZo+CRvUkIz7YfkfyMJSZf952RqIGBnhs2fC/pQ3p6FX/BlsP?=
 =?iso-8859-1?Q?keoRCSu4sfOgpKerOZEpKrnABzAroHrB/rcs15eDBlQyTAAIAWexHIuDb2?=
 =?iso-8859-1?Q?R04fx9gHBh7zTFXg5vznx/LShTivJRstOuo8TDtF9dFJMSCKvAHp5mWoGk?=
 =?iso-8859-1?Q?827A+qHC3hDeOxTE5cGSybp/cmwSJz17t6UvexOE3vd+9GI/R3v6lKVPhk?=
 =?iso-8859-1?Q?kP7NUq3jzh0wRCSDuN0kczRqDMGaCTgn6g4Jvk1Sw6jIFDAlbqO4M+4eiL?=
 =?iso-8859-1?Q?thOe5Ac9bkBR/58aZ9qcQ/d8bdUF1uL/ffKZfhuf9tKbSR6UukyxLN4A?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b7e70640-fd23-474a-fe86-08ddfc6d8cde
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2025 19:56:00.0943
 (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: FqjkteIo+ZecS0MlvK4e4S2R/dPAeIEeYtRH8KY/V0E6xA5/LhgwzkmYChSEhO2Fvxi2N0chKCQRWMBOIimD3F6ORkywNLBxDNd6oXxvspI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB8516

From: Grygorii Strashko 

The LAPIC LVTx registers have two RO bits:
- all: Delivery Status (DS) bit 12
- LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
  This bit is reserved for other LVTx regs with RAZ/WI access type (MMIO), =
while
  WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bits
  (MBZ access type).
and the current vLAPIC implementations allows guest to write to these RO bi=
ts.

The Delivery Status (DS) is not emulated by Xen - there is no IRQ msg bus, =
and
the IRQ is:
- or accepted at destination and appears as pending
  (vLAPIC Interrupt Request Register (IRR))
- or get rejected immediately.

The Remote IRR Flag (RIR) behavior emulation is not implemented for LINT0/L=
INT1
in Xen for now.

Hence it is definitely wrong to allow guest to write to LVTx regs RO bits,
fix it by unconditionally cleaning up those bits in vlapic_reg_write().

Signed-off-by: Grygorii Strashko 
---
 xen/arch/x86/hvm/vlapic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 79697487ba90..78162afe7711 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -880,6 +880,7 @@ void vlapic_reg_write(struct vcpu *v, unsigned int reg,=
 uint32_t val)
         if ( vlapic_sw_disabled(vlapic) )
             val |=3D APIC_LVT_MASKED;
         val &=3D array_access_nospec(vlapic_lvt_mask, (reg - APIC_LVTT) >>=
 4);
+        val &=3D ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING);
         vlapic_set_reg(vlapic, reg, val);
         if ( reg =3D=3D APIC_LVT0 )
         {
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 20:09:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 20:09:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130827.1470198 (Exim 4.92)
	(envelope-from )
	id 1v1sGy-0006Q3-1O; Thu, 25 Sep 2025 20:09:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130827.1470198; Thu, 25 Sep 2025 20:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1sGx-0006Pw-UA; Thu, 25 Sep 2025 20:08:59 +0000
Received: by outflank-mailman (input) for mailman id 1130827;
 Thu, 25 Sep 2025 20:08: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 1v1sGw-0006Pq-EY
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 20:08:58 +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 76c3ad20-9a4b-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 22:08:55 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-62fc89cd68bso2854918a12.0
 for ; Thu, 25 Sep 2025 13:08:55 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3b052d4sm1654928a12.48.2025.09.25.13.08.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 13:08: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: 76c3ad20-9a4b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758830935; x=1759435735; 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=SOxYxHOxZqS8QpjJBA9HbC+BdH9IE3gaGYDE+8DTsVI=;
        b=Kr0RdjLh8LWIxMIXBACdbT5WFCdmrm++MrjHAFHS96er5Y+Qwn2DqIh7Gr9TZa/yoS
         rELGHAMGr0DIkKGlpG2Xyj5vJm2vil+YEHWp+ads6KV9k/HosfE5ncVUn7GIcvQ1W/xL
         ZRvbEiV6s9s1LolINt0PmahPiUO8QLKeOZdeoYiDTsTkTyWfUbvEbA30pjtNjzVA4XwH
         BGmCZ8VK69FJyU+u1EZVlShWOEQDDb3Q9SdYiIakF64TmAauwWh2klb0n0NWfPfuRrC8
         EW1ISyskeka078sE3YZOrdWXfsU+D5XbW7FkAn+icpO48+JCQYX6M7zHMkv21q/r5Q7g
         Cm2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758830935; x=1759435735;
        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=SOxYxHOxZqS8QpjJBA9HbC+BdH9IE3gaGYDE+8DTsVI=;
        b=L6KrOSZqKfFLJXNXI8MdXyfOznspTUpWQH44PR8lSE8mddUWHyAWaduJpiKiRNsKtE
         eBTz5156/7QNBImwPOyUTihr3kn1nCxonD3KhO9DbtOzF0R7T6H4ka9AxzQ3AieQlCsh
         202M1pFL8SjmVHDljI8isBGeGI36LECA3H1/GZsU58csJ2RbnIjcb8WhCS45xdCyaGRj
         iD79UU1wocCWGoo+wVQ89mOQxUoMkEvtsyfw4G3czOrMNXOmN8+JOO/6WhZqsOAHmTcR
         M0zT9eNzRoj2T82LTxhRzaQ6QJxnIXRNTjlMNB90zmDV6QRBAdaJtG8ma99ztwkWzvKA
         6pYQ==
X-Forwarded-Encrypted: i=1; AJvYcCUbX+1E/RgWjjCy1Wq2ENAoppag/i+1rdLMt1hzKHiqDNQb070qsAzjSBEBV9JmFbRLPBj7s5vdxIs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yytbnws+r71eeOF5yxDHD176brvW6QUfLqGG8nJxYf3hwvF3hzc
	hJepKz0OfIdxVyWDpbgAmCTg5+ime2GXwmimOg7OslsWUaV47RLgRVQO
X-Gm-Gg: ASbGncv34xo5rsCIaL9BVNRhGexZnkg8j4dfqoZqujBUGs+yVceLltmXHRbJ6JB0sKn
	6nKgkqQh9zu0T8frsf1c7mlZG2DpFHa7egbDOwLO+vdMKForHF8TWaQovLkFj3Ymn8jRbwUEDVA
	EzA/xAQiWNM6z161NzfnuSRkptDJUMVR6KlJ6ulTIoZHG7cA4i9Fj/fUfsJLlTi0WYfts8b0Ce1
	ycJnj6Rktrc+HFtZZKg4oV0VlFOhvfL7eyI8N337ZZ/kDOGT8oMKolskSOD6MhHWKpTMiSZSf6U
	sM0io181b0OKRZLfvDg2T1KsjAQZYO9tujH/UsDu1QrtV8Yho/hpzAPM04o5WiE3bQcDsK0Yvgi
	9AM/KCHY9Ds9DYoxyiN4vcvGNMXwpVwZIWpcU47c6iTOf+SJk5BmJjEVhyrVs96p5zpwOWnZw
X-Google-Smtp-Source: AGHT+IE0Ol4xet1x2KghTPSyBOufMpYjr7yoLlMUMoSzaBWC+Ph4JtVV6wqvSI+zMWJ/RdfkkbckaQ==
X-Received: by 2002:a05:6402:2552:b0:632:115b:6e72 with SMTP id 4fb4d7f45d1cf-6349f9ee308mr3809457a12.9.1758830934244;
        Thu, 25 Sep 2025 13:08:54 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------pZj6uq0YlIktb3xtf1mh4GXg"
Message-ID: 
Date: Thu, 25 Sep 2025 22:08:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/18] xen/riscv: implement p2m_set_range()
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: 
 <5e325267a792a9a0f4cb387b4e3287d22dc8d173.1758145428.git.oleksii.kurochko@gmail.com>
 <6ee4846e-dd27-4588-aac5-f2fe2937db18@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <6ee4846e-dd27-4588-aac5-f2fe2937db18@suse.com>

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


On 9/20/25 1:36 AM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/p2m.c
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -16,6 +16,7 @@
>>   #include 
>>   
>>   unsigned long __ro_after_init gstage_mode;
>> +unsigned int __ro_after_init gstage_root_level;
>>   
>>   void __init gstage_mode_detect(void)
>>   {
>> @@ -53,6 +54,7 @@ void __init gstage_mode_detect(void)
>>           if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode )
>>           {
>>               gstage_mode = mode;
>> +            gstage_root_level = modes[mode_idx].paging_levels - 1;
>>               break;
>>           }
>>       }
>> @@ -210,6 +212,9 @@ int p2m_init(struct domain *d)
>>       rwlock_init(&p2m->lock);
>>       INIT_PAGE_LIST_HEAD(&p2m->pages);
>>   
>> +    p2m->max_mapped_gfn = _gfn(0);
>> +    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
>> +
>>       /*
>>        * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
>>        * is not ready for RISC-V support.
>> @@ -251,13 +256,287 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>       return rc;
>>   }
>>   
>> +/*
>> + * Find and map the root page table. The caller is responsible for
>> + * unmapping the table.
> With the root table being 4 pages, "the root table" is slightly misleading
> here: Yu never map the entire table.

I will update the comment then to:
/*
  * Map one of the four root pages of the P2M root page table.
  *
  * The P2M root page table is larger than normal (16KB instead of 4KB),
  * so it is allocated as four consecutive 4KB pages. This function selects
  * the appropriate 4KB page based on the given GFN and returns a mapping
  * to it.
  *
  * The caller is responsible for unmapping the page after use.
  *
  * Returns NULL if the calculated offset into the root table is invalid.
  */

>
>> + * The function will return NULL if the offset into 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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
>> +    if ( root_table_indx >= P2M_ROOT_PAGES )
>> +        return NULL;
>> +
>> +    /*
>> +     * The P2M root page table is extended by 2 bits, making its size 16KB
>> +     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
>> +     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
>> +     * only allocates 4KB pages).
>> +     *
>> +     * To determine which of these four 4KB pages the root_table_indx falls
>> +     * into, we divide root_table_indx by
>> +     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
>> +     */
>> +    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);
> The subtraction of 1 here feels odd: You're after the root table's
> number of entries, i.e. I'd expect you to pass just P2M_ROOT_LEVEL.
> And the way P2M_PAGETABLE_ENTRIES() works also suggests so.

The purpose of this line is to select the page within the root table, which
consists of 4 consecutive pages. However, P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL)
returns 2048, so root_table_idx will always be 0 after devision, which is not
what we want.

As an alternative, P2M_PAGETABLE_ENTRIES(0) could be used, since it always
returns 512. Dividing root_table_idx by 512 then yields the index of the page
within the root table, which is made up of 4 consecutive pages.

Does it make sense now?

The problem may occur with DECLARE_OFFSET(), which can produce an incorrect
index within the root page table. Since the index is in the range [0, 2047],
it becomes an issue if the value is greater than 511, because DECLARE_OFFSET()
does not account for the larger range of the root index.

I am not sure whether it is better to make DECLARE_OFFSET() generic enough
for both P2M and Xen page tables, or to provide a separate P2M_DECLARE_OFFSET()
and use it only in P2M-related code.
Also, it could be an option to move DECLARE_OFFSET() from asm/page.h header
to riscv/pt.c and define another one DECLARE_OFFSETS in riscv/p2m.c.

Do you have a preference?

>
>> +/*
>> + * Insert an entry in the p2m. This should be called with a mapping
>> + * equal to a page/superpage.
>> + */
> I don't follow this comment: There isn't any mapping being passed in, is there?

I think this comment should be dropped, it was about that requested mapping
should be equal to a page/superpage(4k, 2m, 1g), the correct order is always
guaranteed by p2m_mapping_order().

>
>> +static int p2m_set_entry(struct p2m_domain *p2m,
>> +                           gfn_t gfn,
>> +                           unsigned long page_order,
>> +                           mfn_t mfn,
>> +                           p2m_type_t t)
> Nit: Indentation.
>
>> +{
>> +    unsigned int level;
>> +    unsigned int target = page_order / PAGETABLE_ORDER;
>> +    pte_t *entry, *table, orig_pte;
>> +    int rc;
>> +    /*
>> +     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
>> +     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
>> +     * are still allowed.
>> +     */
>> +    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
>> +    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
>> +
>> +    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, gfn);
>> +    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
>> +        {
>> +            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
>> +            /*
>> +             * 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).
> I thought I commented on this or something similar already: Calling the
> p2m tree "read-only" is imo misleading.

I will change then "read-only" to "not allocatable".

>
>> It is a valid case
>> +             * when removing a mapping as it may not exist in the
>> +             * page table. In this case, just ignore it.
> I fear the "it" has no reference; aiui you mean "ignore the lookup failure",
> but the comment isn't worded to refer to that by "it".

I will update the comment correspondingly.

>
>> +             */
>> +            rc = removing_mapping ? 0 : rc;
>> +            goto out;
>> +        }
>> +
>> +        if ( rc != P2M_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;
>> +
>> +    if ( removing_mapping )
>> +        p2m_clean_pte(entry, p2m->clean_dcache);
>> +    else
>> +    {
>> +        pte_t pte = p2m_pte_from_mfn(mfn, t);
>> +
>> +        p2m_write_pte(entry, pte, p2m->clean_dcache);
>> +
>> +        p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
>> +                                      gfn_add(gfn, BIT(page_order, UL) - 1));
>> +        p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, gfn);
>> +    }
>> +
>> +    p2m->need_flush = true;
>> +
>> +    /*
>> +     * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
>> +     * is not ready for RISC-V support.
>> +     *
>> +     * When CONFIG_HAS_PASSTHROUGH=y, iommu_iotlb_flush() should be done
>> +     * here.
>> +     */
>> +#ifdef CONFIG_HAS_PASSTHROUGH
>> +#   error "add code to flush IOMMU TLB"
>> +#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 previously MFN 0 was mapped and it is going to be removed
>> +     * and considering that during removing MFN 0 is used then `entry`
>> +     * and `new_entry` will be the same and p2m_free_subtree() won't be
>> +     * called. This case is handled explicitly.
>> +     */
>> +    if ( pte_is_valid(orig_pte) &&
>> +         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
>> +          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
>> +        p2m_free_subtree(p2m, orig_pte, level);
> I continue to fail to understand why the MFN would matter here.

My understanding is that if, for the same GFN, the MFN changes fromMFN_1 to
MFN_2, then we need to update any references on the page referenced by
|orig_pte| to ensure the proper reference counter is maintained for the page
pointed to byMFN_1.

>   Isn't the
> need to free strictly tied to a VALID -> NOT VALID transition? A permission
> change simply retains the VALID state of an entry.

It covers a case when removing happens and probably in this case we don't need
to check specifically for mfn(0) case "mfn_eq(pte_get_mfn(*entry), _mfn(0))",
but it would be enough to check that pte_is_valid(entry) instead:
   ...
   (removing_mapping && !pte_is_valid(entry)))) )

Or only check removing_mapping variable as `entry` would be invalided by the
code above anyway. So we will get:
+    if ( pte_is_valid(orig_pte) &&
+         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) || removing_mapping) )
+        p2m_free_subtree(p2m, orig_pte, level);

Does it make sense now?

~ Oleksii

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



  
    
  
  
    


    

    
On 9/20/25 1:36 AM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -16,6 +16,7 @@
 #include <asm/riscv_encoding.h>
 
 unsigned long __ro_after_init gstage_mode;
+unsigned int __ro_after_init gstage_root_level;
 
 void __init gstage_mode_detect(void)
 {
@@ -53,6 +54,7 @@ void __init gstage_mode_detect(void)
         if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode )
         {
             gstage_mode = mode;
+            gstage_root_level = modes[mode_idx].paging_levels - 1;
             break;
         }
     }
@@ -210,6 +212,9 @@ int p2m_init(struct domain *d)
     rwlock_init(&p2m->lock);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
 
+    p2m->max_mapped_gfn = _gfn(0);
+    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
+
     /*
      * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
      * is not ready for RISC-V support.
@@ -251,13 +256,287 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
     return rc;
 }
 
+/*
+ * Find and map the root page table. The caller is responsible for
+ * unmapping the table.


      

      
With the root table being 4 pages, "the root table" is slightly misleading
here: Yu never map the entire table.

    

    
I will update the comment then to:
/*
 * Map one of the four root pages of the P2M root page table.
 *
 * The P2M root page table is larger than normal (16KB instead of 4KB),
 * so it is allocated as four consecutive 4KB pages. This function selects
 * the appropriate 4KB page based on the given GFN and returns a mapping
 * to it. 
 *
 * The caller is responsible for unmapping the page after use.
 *
 * Returns NULL if the calculated offset into the root table is invalid.
 */



    

      



      

        
+ * The function will return NULL if the offset into 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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
+    if ( root_table_indx >= P2M_ROOT_PAGES )
+        return NULL;
+
+    /*
+     * The P2M root page table is extended by 2 bits, making its size 16KB
+     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
+     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
+     * only allocates 4KB pages).
+     *
+     * To determine which of these four 4KB pages the root_table_indx falls
+     * into, we divide root_table_indx by
+     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
+     */
+    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);


      

      
The subtraction of 1 here feels odd: You're after the root table's
number of entries, i.e. I'd expect you to pass just P2M_ROOT_LEVEL.
And the way P2M_PAGETABLE_ENTRIES() works also suggests so.

    

    
The purpose of this line is to select the page within the root table, which
consists of 4 consecutive pages. However, P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL)
returns 2048, so root_table_idx will always be 0 after devision, which is not
what we want.

As an alternative, P2M_PAGETABLE_ENTRIES(0) could be used, since it always
returns 512. Dividing root_table_idx by 512 then yields the index of the page
within the root table, which is made up of 4 consecutive pages.

Does it make sense now?

The problem may occur with DECLARE_OFFSET(), which can produce an incorrect
index within the root page table. Since the index is in the range [0, 2047],
it becomes an issue if the value is greater than 511, because DECLARE_OFFSET()
does not account for the larger range of the root index.

I am not sure whether it is better to make DECLARE_OFFSET() generic enough
for both P2M and Xen page tables, or to provide a separate P2M_DECLARE_OFFSET()
and use it only in P2M-related code.
Also, it could be an option to move DECLARE_OFFSET() from asm/page.h header
to riscv/pt.c and define another one DECLARE_OFFSETS in riscv/p2m.c.

Do you have a preference?



    

      



      

        
+/*
+ * Insert an entry in the p2m. This should be called with a mapping
+ * equal to a page/superpage.
+ */


      

      
I don't follow this comment: There isn't any mapping being passed in, is there?

    

    
I think this comment should be dropped, it was about that requested mapping
should be equal to a page/superpage(4k, 2m, 1g), the correct order is always
guaranteed by p2m_mapping_order().



    

      



      

        
+static int p2m_set_entry(struct p2m_domain *p2m,
+                           gfn_t gfn,
+                           unsigned long page_order,
+                           mfn_t mfn,
+                           p2m_type_t t)


      

      
Nit: Indentation.



      

        
+{
+    unsigned int level;
+    unsigned int target = page_order / PAGETABLE_ORDER;
+    pte_t *entry, *table, orig_pte;
+    int rc;
+    /*
+     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
+     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
+     * are still allowed.
+     */
+    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
+
+    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, gfn);
+    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
+        {
+            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
+            /*
+             * 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).


      

      
I thought I commented on this or something similar already: Calling the
p2m tree "read-only" is imo misleading.

    

    
I will change then "read-only" to "not allocatable".



    

      



      

        
It is a valid case
+             * when removing a mapping as it may not exist in the
+             * page table. In this case, just ignore it.


      

      
I fear the "it" has no reference; aiui you mean "ignore the lookup failure",
but the comment isn't worded to refer to that by "it".

    

    
I will update the comment correspondingly.



    

      



      

        
+             */
+            rc = removing_mapping ? 0 : rc;
+            goto out;
+        }
+
+        if ( rc != P2M_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;
+
+    if ( removing_mapping )
+        p2m_clean_pte(entry, p2m->clean_dcache);
+    else
+    {
+        pte_t pte = p2m_pte_from_mfn(mfn, t);
+
+        p2m_write_pte(entry, pte, p2m->clean_dcache);
+
+        p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
+                                      gfn_add(gfn, BIT(page_order, UL) - 1));
+        p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, gfn);
+    }
+
+    p2m->need_flush = true;
+
+    /*
+     * Currently, the infrastructure required to enable CONFIG_HAS_PASSTHROUGH
+     * is not ready for RISC-V support.
+     *
+     * When CONFIG_HAS_PASSTHROUGH=y, iommu_iotlb_flush() should be done
+     * here.
+     */
+#ifdef CONFIG_HAS_PASSTHROUGH
+#   error "add code to flush IOMMU TLB"
+#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 previously MFN 0 was mapped and it is going to be removed
+     * and considering that during removing MFN 0 is used then `entry`
+     * and `new_entry` will be the same and p2m_free_subtree() won't be
+     * called. This case is handled explicitly.
+     */
+    if ( pte_is_valid(orig_pte) &&
+         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
+          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
+        p2m_free_subtree(p2m, orig_pte, level);


      

      
I continue to fail to understand why the MFN would matter here.

    

    
My understanding is that if, for the same GFN, the MFN changes from MFN_1 to
MFN_2, then we need to update any references on the page referenced by
orig_pte to ensure the proper reference counter is maintained for the page
pointed to by MFN_1.

    

      
 Isn't the
need to free strictly tied to a VALID -> NOT VALID transition? A permission
change simply retains the VALID state of an entry.

    

    
It covers a case when removing happens and probably in this case we don't need
to check specifically for mfn(0) case "mfn_eq(pte_get_mfn(*entry), _mfn(0))",
but it would be enough to check that pte_is_valid(entry) instead:
  ...
  (removing_mapping && !pte_is_valid(entry)))) )

Or only check removing_mapping variable as `entry` would be invalided by the
code above anyway. So we will get:
+    if ( pte_is_valid(orig_pte) &&
+         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) || removing_mapping) )
+        p2m_free_subtree(p2m, orig_pte, level);

Does it make sense now?

~ Oleksii


  


--------------pZj6uq0YlIktb3xtf1mh4GXg--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 20:22:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 20:22:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130844.1470208 (Exim 4.92)
	(envelope-from )
	id 1v1sUP-0000dn-4j; Thu, 25 Sep 2025 20:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130844.1470208; Thu, 25 Sep 2025 20: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 1v1sUP-0000dg-1k; Thu, 25 Sep 2025 20:22:53 +0000
Received: by outflank-mailman (input) for mailman id 1130844;
 Thu, 25 Sep 2025 20:22: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 1v1sUO-0000da-4Z
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 20:22:52 +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 680d9e0d-9a4d-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 22:22:49 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-b28e1b87aa7so208818166b.3
 for ; Thu, 25 Sep 2025 13:22:49 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3ae3227sm1716997a12.28.2025.09.25.13.22.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 13:22: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: 680d9e0d-9a4d-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758831769; x=1759436569; 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=UbcLYtMnNA+Jyh0i0G4D9kZWWK8dybnKoE4FEnaFBC0=;
        b=gkyyaaDmEOE31swIn/oAFyNSSH7idTVMEIvcTgzPQjsQ1Cqaurs+bWblVIt9wzQnyR
         7qWMEIkF67kTRSu3PsF21Z9wNABUdNBq9NSZixVdqtaGFrSiWV9HesXO56xUihexNFxA
         G8lls4p5N8WV/orRIRFHZX0MN2BOoxJvCoZQYNQx8lLX8s+Zm8XGFykUSONQsJ0d2+DV
         XgDoSobQLwX1Dsc/9kXxZmpapFmEr3W1B7Rc2Thny4WIdNQRyY5lVJoVdlLB782kVTbM
         pPwe6IZVXi5VIGpMvNLFZSu0SlTBpOcNbC7572Bu5EGZICNPGlNW1snPWJHVQQsS2aIE
         bAKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758831769; x=1759436569;
        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=UbcLYtMnNA+Jyh0i0G4D9kZWWK8dybnKoE4FEnaFBC0=;
        b=umkjda9sobZl7lth+58f9QreSJm6hHLIhw2+FUD+W6r99qhhLyPt5QEdz6+muYxEJP
         konaTXLIAFst1Ft2h+cRK4IDN8CosgS/Cq5sgXYpRptqVRtCxHOmb2+lB4aHrkBlxCQZ
         oSiGGhpqVtr9yhGeeHvDZ4hAOz9aFcmnYmdKKAhJqPyiwZwTFACPHKifLYPepkqfu3JU
         rqNPhqnUFocyUeO2qYqvmUQxSLhIRcYWH0EzT2ev2sGhgWqPQllgINfT0f8JfN2YamkG
         dF0EmdeB0L23mYE43uG7SrvV2K1oilVwbuBs8G71VTCd1XBgmj70IS7cPKS5Lgl6iZsg
         ch2w==
X-Forwarded-Encrypted: i=1; AJvYcCVaG/3k8vY2ZC53PGjR8eDgFzC8FXGlqbRagSGaFjpo5H4PpfQWs+uDHKrKKZvV3bbtKAe5gJ0+Nkk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywf829YjYW60tZgitZZu8b8s4ztaAzoktIWq3mG0mkgwksGmjTg
	odrvs848ubZOjFGLHxKjJCobWJlgX14qng8oyNU0OJ4WQsnehCAUAeBG
X-Gm-Gg: ASbGncsmvJlfXZFZJsI499pX9kXaIlfPOhR66B245oZcpaFb/NkeRe7LO1Adl9OR8YV
	t0oJ3UPObMbIoLT2EK8hNX7WqYi7JHTH+LaEU7nWQAWsNofzRv2MEeJ+DMv406MqhvbYd/mPkj1
	b4/t7yQUMr5WFlASbzvZ8MPzDFZZcHMlKAP/LkVaUWZ4d8GPe+tvazHSR7wAL0uxYmagUHdnz/n
	vDDPECSt53GR0N55azbcNgOinnUG7hwDyMibYzipnwASPX5ANPpKR9YPTW/dn6yZZ8wQuYBZHfj
	2ACy5M94J8SdFsO02TZxsFDWux7NY1SdH7UPm99pBbfYH6nz1iaIF4iJ/5E3Ux7eDOG1EyEw2gC
	sJfrBjQ/Oaz74QJX3BymVkXRjDj2Yzsy6Jq76DO4nn2h96BOo1eja36p0Wwm7Wri8PEx6/7Ypo9
	4WpLftAj4=
X-Google-Smtp-Source: AGHT+IG3dJacIiSoHeRTH5XUJgv+ZeiKSC8JZsc1F4WzD9BvK0EmH5ExVwkkhXf0rQfOgQdR7NOs+w==
X-Received: by 2002:a17:906:7954:b0:b04:848f:a0d4 with SMTP id a640c23a62f3a-b34b9f5b524mr561238066b.13.1758831769098;
        Thu, 25 Sep 2025 13:22:49 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------x2H67mzQyCiVpP00MH70Xlnu"
Message-ID: <97488f35-3f94-42b0-8443-4feacf3d587d@gmail.com>
Date: Thu, 25 Sep 2025 22:22:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CHANGELOG.md: Update for 4.21 release cycle
To: Jan Beulich 
Cc: committers@xenproject.org,
 Community Manager ,
 xen-devel@lists.xenproject.org
References: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
 <814501c8-94e3-4930-87ed-88e7506456ed@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <814501c8-94e3-4930-87ed-88e7506456ed@suse.com>

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


On 9/25/25 8:26 AM, Jan Beulich wrote:
> On 24.09.2025 11:36, Oleksii Kurochko wrote:
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -14,6 +14,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>    - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
>>      to the baseline change.
>>    - Linux based device model stubdomains are now fully supported.
>> + - Remove libxenctrl usage from xenstored.
>>   
>>    - On x86:
>>      - Restrict the cache flushing done as a result of guest physical memory map
>> @@ -21,6 +22,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>      - 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.
>> +   - Allow to unflatten DTs.
> What is this about? There continues to be no use of DT on x86, so without context
> this feels pretty much meaningless to me.

I am referring tohttps://lore.kernel.org/xen-devel/20250722000525.7247-1-alejandro.garciavallejo@amd.com/.

>
>> @@ -36,11 +38,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>      - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
>>        Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
>>        and 28 (Temperature Probe).
>> +   - Basic kexec support to Mini-OS for running in PVH mode.
> Hmm, MiniOS isn't an integral part of a Xen release, so I wonder if such really
> belongs here. Yes, I also understand that there's not really anywhere else to
> put such.

I decided to put it here since we include information about stubdoms in|CHANGELOG.md|,
and MiniOS is related to that.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/25/25 8:26 AM, Jan Beulich wrote:

    

    

      
On 24.09.2025 11:36, Oleksii Kurochko wrote:


      

        
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
    to the baseline change.
  - Linux based device model stubdomains are now fully supported.
+ - Remove libxenctrl usage from xenstored.
 
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
@@ -21,6 +22,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - 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.
+   - Allow to unflatten DTs.


      

      
What is this about? There continues to be no use of DT on x86, so without context
this feels pretty much meaningless to me.

    

    
I am referring to https://lore.kernel.org/xen-devel/20250722000525.7247-1-alejandro.garciavallejo@amd.com/.



    

      



      

        
@@ -36,11 +38,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
      Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
      and 28 (Temperature Probe).
+   - Basic kexec support to Mini-OS for running in PVH mode.


      

      
Hmm, MiniOS isn't an integral part of a Xen release, so I wonder if such really
belongs here. Yes, I also understand that there's not really anywhere else to
put such.

    

    
I decided to put it here since we include information about stubdoms in CHANGELOG.md,
and MiniOS is related to that.

~ Oleksii


  


--------------x2H67mzQyCiVpP00MH70Xlnu--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 20:40:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 20:40:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130861.1470218 (Exim 4.92)
	(envelope-from )
	id 1v1slI-0003PI-G8; Thu, 25 Sep 2025 20:40:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130861.1470218; Thu, 25 Sep 2025 20: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 1v1slI-0003PB-DG; Thu, 25 Sep 2025 20:40:20 +0000
Received: by outflank-mailman (input) for mailman id 1130861;
 Thu, 25 Sep 2025 20:40: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 1v1slH-0003P5-7y
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 20:40:19 +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 cf3a2833-9a4f-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 22:40:02 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-b2ee3c13aa4so221032066b.3
 for ; Thu, 25 Sep 2025 13:40:01 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b35446f7806sm239149166b.70.2025.09.25.13.39.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 13: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: cf3a2833-9a4f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758832801; x=1759437601; 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=nXaUO2sQ3n/Q+JfDPL6ct2++ofgMqz7sXZdZYgJeZ6U=;
        b=Y8GzL0l36mK7rifv5RM7vv++vZJh5FHbCEs/UKyDwui/pKR+v4qKuqrrls2zFLvHHK
         L9etgsz8nyX/Bya/oVa/FKynxOyiWj3FHsrB07EPHD52/hItLI4R09Wi6QMzFV8sRO9e
         chcTv+rSskzJ1PM0Yqh7eZzJLp+uXsRRD4t5QKY4QXRpcZO0ML8MwAFe/O5qb05D5T7/
         CCy1ElqRgi6OpFXrPOfYk1LJbcDyW2ESaIus4rljAeOJopdLoaktWY8VY2JRC/Ji95CZ
         YxG7ivRpAeXyH4bvfClAHW5QWe2xel2a12mOw9f7M4+cHCBCXVj4RsDSfmaXel+xLC67
         cvkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758832801; x=1759437601;
        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=nXaUO2sQ3n/Q+JfDPL6ct2++ofgMqz7sXZdZYgJeZ6U=;
        b=Ojp85Pq8SbD9cvDgY1z9HO8nzOJFxG23wKHCj68K9sWYjbr8QZN1LTpaJh9GPieCWt
         Q6Bu1zRTtnLVES6BLmOal3LLdPnxYnfL1T/Kw+Ex7e/zIdN7PWDNEA7/DUGjBC1DBaz6
         cU/Zq7OE6b+4fgzkNexzlFd9nN4RgKncP0Hwk7EQHYa3fZo7Cpb6HQmXLRQxJANRdTmK
         eiyf17kt6QH3Q25ccW5tLUrz9HnAgGWgqpeQEgBXZSXyrl1RxUc++Go2p8OzBOe3m/rY
         MxVUem04HNhnIcaSlWwg4zntfRn1khtoWDWBDCrIZKsGEKpXmJVNHBePFrrdzPZd/HNu
         Te0g==
X-Gm-Message-State: AOJu0YxKFhg8XYJkRhWzjxPsEJdeuFmPVnk6KeIHpZ6yFEsuofjbpHWn
	E3vL143LrVoc43be6Q3Rae9EMBufZwoYgfvlRVU6ezXn+GAgcwaspAnn
X-Gm-Gg: ASbGncu77Yud4VqiTe93wrTy7vu5LnBlJFg0HNG3hsuq9QkwzRZxc1PqZLn/nig3Xg+
	zFg7kadUVKBOhK9LTyNpmpfyhfiYJdWord1zUr6Kxd/4c0M26iQYSODCjV4o3esJvPmCdcZgFR+
	8EgvIP76nFpQnrCnp4EqJ9tAzv8Hm87EtmwbkwNWFPpJlPkaohn2FF0Dn2BmDjA/oRWNBKYeIPh
	tQTUvCHA8kYLVjvpSbZnCYKiMXJigCMIl7/1J8pARj/3KtUirO9b07yo1XV81Gl3PBQ4lIX0yjy
	q6va/+q0Iv8PA7rIzZI58+AC9wN3mmIW634uUDiSl4W+5ZJ+kUrjOpD1ANfUMaftqW584ctqxzA
	WQydCLYvNFXwv0cEhwwOxUIr0UDRtKwGXBEOQG4fA4jbAJivFrucS48yu/a3mr5WEACEkQext
X-Google-Smtp-Source: AGHT+IH557yebrMNF5LAESwPiXNFyyEHkixaUB8rRbQv9yvbVM0FUKYt6kv91y1ztIoLjLDzLVouzQ==
X-Received: by 2002:a17:906:4fcd:b0:b2c:dc13:89e4 with SMTP id a640c23a62f3a-b34ba147a90mr538291066b.9.1758832800941;
        Thu, 25 Sep 2025 13:40:00 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------GEgyVgrdSSmxrKd3BGf0Cp6X"
Message-ID: 
Date: Thu, 25 Sep 2025 22:39:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Ping: [PATCH] symbols: discard stray file symbols
To: Jan Beulich , Andrew Cooper
 , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
Cc: "xen-devel@lists.xenproject.org" 
References: <2412a7a0-bdcd-4647-8ea2-8d2a927dcde3@suse.com>
 <6fb3e095-172e-4cd4-8c26-60be6c5de704@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <6fb3e095-172e-4cd4-8c26-60be6c5de704@suse.com>

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


On 9/25/25 9:36 AM, Jan Beulich wrote:
> On 16.04.2025 11:00, Jan Beulich wrote:
>> By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
>> when linking xen.efi. Due to the nature of file symbols in COFF symbol
>> tables (see the code comment) the symbols_offsets[] entries for such
>> symbols would cause assembler warnings regarding value truncation. Of
>> course the resulting entries would also be both meaningless and useless.
>> Add a heuristic to get rid of them, really taking effect only when
>> --all-symbols is specified (otherwise these symbols are discarded
>> anyway).
>>
>> Signed-off-by: Jan Beulich
> May I please ask for feedback here, so that hopefully we can have this
> sorted in 4.21?

It is okay for me to have this change in 4.21:
  Release-Acked-by: Oleksii Kurochko

~ Oleksii

>
> Jan
>
>> ---
>> Factor 2 may in principle still be too small: We zap what looks like
>> real file symbols already in read_symbol(), so table_cnt doesn't really
>> reflect the number of symbol table entries encountered. It has proven to
>> work for me in practice though, with still some leeway left.
>>
>> --- a/xen/tools/symbols.c
>> +++ b/xen/tools/symbols.c
>> @@ -213,6 +213,16 @@ static int symbol_valid(struct sym_entry
>>   	if (strstr((char *)s->sym + offset, "_compiled."))
>>   		return 0;
>>   
>> +	/* At least GNU ld 2.25 may emit bogus file symbols referencing a
>> +	 * section name while linking xen.efi. In COFF symbol tables the
>> +	 * "value" of file symbols is a link (symbol table index) to the next
>> +	 * file symbol. Since file (and other) symbols (can) come with one
>> +	 * (or in principle more) auxiliary symbol table entries, the value in
>> +	 * this heuristic is bounded to twice the number of symbols we have
>> +	 * found. See also read_symbol() as to the '?' checked for here. */
>> +	if (s->sym[0] == '?' && s->sym[1] == '.' && s->addr < table_cnt * 2)
>> +		return 0;
>> +
>>   	return 1;
>>   }
>>   
--------------GEgyVgrdSSmxrKd3BGf0Cp6X
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/25/25 9:36 AM, Jan Beulich wrote:

    

    

      
On 16.04.2025 11:00, Jan Beulich wrote:


      

        
By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
when linking xen.efi. Due to the nature of file symbols in COFF symbol
tables (see the code comment) the symbols_offsets[] entries for such
symbols would cause assembler warnings regarding value truncation. Of
course the resulting entries would also be both meaningless and useless.
Add a heuristic to get rid of them, really taking effect only when
--all-symbols is specified (otherwise these symbols are discarded
anyway).

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


      

      
May I please ask for feedback here, so that hopefully we can have this
sorted in 4.21?

    

    
It is okay for me to have this change in 4.21:
 Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii


    

      

Jan



      

        
---
Factor 2 may in principle still be too small: We zap what looks like
real file symbols already in read_symbol(), so table_cnt doesn't really
reflect the number of symbol table entries encountered. It has proven to
work for me in practice though, with still some leeway left.

--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -213,6 +213,16 @@ static int symbol_valid(struct sym_entry
 	if (strstr((char *)s->sym + offset, "_compiled."))
 		return 0;
 
+	/* At least GNU ld 2.25 may emit bogus file symbols referencing a
+	 * section name while linking xen.efi. In COFF symbol tables the
+	 * "value" of file symbols is a link (symbol table index) to the next
+	 * file symbol. Since file (and other) symbols (can) come with one
+	 * (or in principle more) auxiliary symbol table entries, the value in
+	 * this heuristic is bounded to twice the number of symbols we have
+	 * found. See also read_symbol() as to the '?' checked for here. */
+	if (s->sym[0] == '?' && s->sym[1] == '.' && s->addr < table_cnt * 2)
+		return 0;
+
 	return 1;
 }
 


      

      

    

  


--------------GEgyVgrdSSmxrKd3BGf0Cp6X--


From xen-devel-bounces@lists.xenproject.org Thu Sep 25 20:43:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Sep 2025 20:43:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130874.1470228 (Exim 4.92)
	(envelope-from )
	id 1v1so1-0003yH-TG; Thu, 25 Sep 2025 20:43:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130874.1470228; Thu, 25 Sep 2025 20:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v1so1-0003yA-QM; Thu, 25 Sep 2025 20:43:09 +0000
Received: by outflank-mailman (input) for mailman id 1130874;
 Thu, 25 Sep 2025 20:43:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v1so0-0003y4-6e
 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2025 20:43:08 +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 3ce0c5b3-9a50-11f0-9809-7dc792cee155;
 Thu, 25 Sep 2025 22:43:05 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-afcb7ae31caso193341066b.3
 for ; Thu, 25 Sep 2025 13:43:05 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3544fcde34sm234001966b.73.2025.09.25.13.43.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 13:43: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: 3ce0c5b3-9a50-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758832985; x=1759437785; 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=MNZBPjENghkHar9VDG+i1SkRR2uSbbOVXQHDNwfwvzg=;
        b=Gkze9Bm1734w/c5/ctiAjs2YBk1Y+j9wKhYBVQwCqHOMERU9ehfBgx36bHPpDka1cW
         p45c/qRXpgJCzH3AqZFc00Y/T7EdBUl9gsj8c099Mn9ASaqcux6f9RpRbJfDwnghaSyX
         uAaXlf4+Pr8BAMSXafGdpKjlD3dOkJM+Lk2PZR6Jgwip17jCQRyojXa8ont/1DQ6qo0Y
         vb3vDeL2Xmev2s6LgV54KACDckIn52zxXvs2kyrEelety/175NsAikSYCxHEZnbmglcy
         g0cFgLCQF9Ide9hGZY8u6Vb3lTeq+49EOeinxojTBwlBnOiyy9gLag+GxIAZFEtpcaw5
         SCvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758832985; x=1759437785;
        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=MNZBPjENghkHar9VDG+i1SkRR2uSbbOVXQHDNwfwvzg=;
        b=kuurqRyWtT0KU2ulvwvSGhh/wg8nxShs1Hhpu9oDDAZmLkq+u3zalnZyW53tBgAae/
         x3ytki/gBXv/dMfG8SWBySlkGg+RbiyN4HUwkJn4ILJzOHELLcLJ7qEjlaHe/Jt2LUs1
         D3iCq9iHD2fcZfW4bkX/0vD5xaLEZ82Kym29Ss9UlylVUbY4NRwDpoXxsRh9kBnuujOT
         oX0NrAbL6sQZLbFdDslbXAPfFFMfjIs2gKvcA75utC121UhV/6CXhaBQShFjvjYWeP6F
         Zz422sBGRNF++y2CTleLpCjnenomGKhUh414DejTX8h1DFEV+fAPSxjrQe3klgwkiuA+
         GncQ==
X-Gm-Message-State: AOJu0YzJ1pcmBZGLpJDEfdaiKv42+Hq3rmvXs4+9PlbKOFdaLKldnF4z
	0kcFPD6T49jVRuvDhPMZhiYbBAAJktFfUqlLfyqF2LtUE5yVwsXfBQBv
X-Gm-Gg: ASbGnctCPsMP1X8WPP9nnZLVviM+ZZn66pW8mqmB+6BV2E7gRLSYk+oAnfrCY7bQ3/N
	S1aFjUZJszJiDIgd4zbSaAKYo15RiQqySKAhyoOJD6WHdy/sovqVYpJO2ec+2E2E2CH9O/IhN0e
	DtCpCJllc6dBGHc3waX0+rzKamQ7TTQq3LBbpI4T1h9AizEfcxv/14X+Q2FUbQEc0wLvOOqB95K
	617F7AP3KxUS6X0ZrzuBUuZPpJDuKEJL7NZp/doIslWAADtqt7NLURrc3eW6p3lhIS8JRJkQTHo
	MNqGqI5OpeWfrHvIVNjmDm+gsHYUxt5ziceFwTMasKOEzlJSVSofr4eeQzGZP5q0/PHcXufRIEB
	/VecAE8JYZvVOY3g0uAPbHONd57GF0J8xPinah4VqYZWrsauU9PHsN63A0D5uPoTtcUmotL1k
X-Google-Smtp-Source: AGHT+IHj3a9hhtdKz7xLdDmj7OBCR7aSaDmpYQnb/3rg4GOUQ2tmp7wtQGHC8/NeMtRp2jbZ1WQ1IA==
X-Received: by 2002:a17:907:60d4:b0:b2e:ca89:dcc4 with SMTP id a640c23a62f3a-b34bad22510mr443061966b.37.1758832985172;
        Thu, 25 Sep 2025 13:43:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------uedu0LlpqIQn4v00k4cqBRWM"
Message-ID: <913d7e21-72ec-4823-9a4c-84d8a5e97cba@gmail.com>
Date: Thu, 25 Sep 2025 22:43:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] x86/cpu: populate CPUID 0x1.edx features early
 for self-snoop detection
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <20250924110051.2160-1-roger.pau@citrix.com>
 <2d17d2d502df489f97b51e43a2d86535@DM6PR03MB5227.namprd03.prod.outlook.com>
  <3d45a9e8-a836-46bf-a3bc-321551ac755b@suse.com>
  <1083faae-d565-48ab-8e41-3a5a12178a9f@suse.com>
  <58e5e9ae-9b57-41b0-a2d9-bdd2f312293b@suse.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/25/25 10:11 AM, Roger Pau Monné wrote:
> On Thu, Sep 25, 2025 at 09:41:43AM +0200, Jan Beulich wrote:
>> On 25.09.2025 09:40, Roger Pau Monné wrote:
>>> On Thu, Sep 25, 2025 at 09:37:46AM +0200, Jan Beulich wrote:
>>>> On 25.09.2025 09:34, Roger Pau Monné wrote:
>>>>> On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:
>>>>>> On 24.09.2025 15:40, Roger Pau Monné wrote:
>>>>>>> On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:
>>>>>>>> On 24/09/2025 4:00 am, Roger Pau Monne wrote:
>>>>>>>>> Otherwise the check for the SS feature in
>>>>>>>>> check_memory_type_self_snoop_errata() fails unconditionally, which leads to
>>>>>>>>> X86_FEATURE_XEN_SELFSNOOP never being set.
>>>>>>>>>
>>>>>>>>> We could also avoid this by not doing the reset_cpuinfo() for the BSP in
>>>>>>>>> identify_cpu(), because SS detection uses boot_cpu_data.
>>>>>>>> Doesn't this, mean ...
>>>>>>> Well, that's the reason for the rant here.  The reset at the top of
>>>>>>> identify_cpu() has been there since 2005.  It's arguably to make sure
>>>>>>> the BSP and the APs have the same empty state in the passed
>>>>>>> cpuinfo_x86 struct, as for the BSP this would be already partially
>>>>>>> initialized due to what's done in early_cpu_init().
>>>>>>>
>>>>>>> The underlying question is whether we would rather prefer to not do
>>>>>>> the reset for the BSP, but that would lead to differences in the
>>>>>>> contents of cpuinfo_x86 struct between the BSP and the APs.  In the
>>>>>>> past we have arranged for leaves needed early to be populated in
>>>>>>> generic_identify(), like FEATURESET_e21a, hence the proposed patch
>>>>>>> does that for FEATURESET_1d.
>>>>>>>
>>>>>>>>>    However that
>>>>>>>>> creates an imbalance on the state of the BSP versus the APs in the
>>>>>>>>> identify_cpu() code.
>>>>>>>>>
>>>>>>>>> I've opted for the less controversial solution of populating FEATURESET_1d
>>>>>>>>> in generic_identify(), as the value is already there.  The same is done for
>>>>>>>>> the AMD faulting probe code.
>>>>>>>>>
>>>>>>>>> Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
>>>>>>>>> Signed-off-by: Roger Pau Monné
>>>>>>>> ... this Fixes tag is incorrect?
>>>>>>> I think the Fixes tag is accurate; the code was OK before that change.
>>>>>>> Nothing in c_early_init hooks depended on (some of) the x86_capability
>>>>>>> fields being populated, which is required after the change.
>>>>>> I agree. Hence:
>>>>>> Reviewed-by: Jan Beulich
>>>>>>
>>>>>> I wonder though whether while there we wouldn't want to also store ecx if
>>>>>> we already have it. (Really there is the question of whether we haven't
>>>>>> other cpu_has_* uses which similarly come "too early".)
>>>>> Yeah, I was about to do it, but it's not strictly needed for
>>>>> c_early_init, and it's done anyway just after the call to
>>>>> c_early_init.  I can set that field also, but then I would need to
>>>>> tweak the comment ahead, something like:
>>>> Sure, i.e. fine with me.
>>> Oleksii, can I please get a release-ack for this to go in?
>> Do bug fixes actually need release-acks just yet?
> I always err on the side of caution and ask for them.  Maybe Oleksii
> can state if/when he formally wants release-acks for bugfixes.

I am okay not to have release-acks for bugfixes until the end of code
freeze.

When I will announce a next stages of release process,
I would put such the information explicitly.

Thanks.

~ Oleksii

> Regards, Roger.
--------------uedu0LlpqIQn4v00k4cqBRWM
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 9/25/25 10:11 AM, Roger Pau Monné
      wrote:

    

    

      
On Thu, Sep 25, 2025 at 09:41:43AM +0200, Jan Beulich wrote:


      

        
On 25.09.2025 09:40, Roger Pau Monné wrote:


        

          
On Thu, Sep 25, 2025 at 09:37:46AM +0200, Jan Beulich wrote:


          

            
On 25.09.2025 09:34, Roger Pau Monné wrote:


            

              
On Thu, Sep 25, 2025 at 09:03:06AM +0200, Jan Beulich wrote:


              

                
On 24.09.2025 15:40, Roger Pau Monné wrote:


                

                  
On Wed, Sep 24, 2025 at 11:50:02AM +0000, Andrew Cooper wrote:


                  

                    
On 24/09/2025 4:00 am, Roger Pau Monne wrote:


                    

                      
Otherwise the check for the SS feature in
check_memory_type_self_snoop_errata() fails unconditionally, which leads to
X86_FEATURE_XEN_SELFSNOOP never being set.

We could also avoid this by not doing the reset_cpuinfo() for the BSP in
identify_cpu(), because SS detection uses boot_cpu_data.


                    

                    
Doesn't this, mean ...


                  

                  
Well, that's the reason for the rant here.  The reset at the top of
identify_cpu() has been there since 2005.  It's arguably to make sure
the BSP and the APs have the same empty state in the passed
cpuinfo_x86 struct, as for the BSP this would be already partially
initialized due to what's done in early_cpu_init().

The underlying question is whether we would rather prefer to not do
the reset for the BSP, but that would lead to differences in the
contents of cpuinfo_x86 struct between the BSP and the APs.  In the
past we have arranged for leaves needed early to be populated in
generic_identify(), like FEATURESET_e21a, hence the proposed patch
does that for FEATURESET_1d.



                  

                    

                      
  However that
creates an imbalance on the state of the BSP versus the APs in the
identify_cpu() code.

I've opted for the less controversial solution of populating FEATURESET_1d
in generic_identify(), as the value is already there.  The same is done for
the AMD faulting probe code.

Fixes: f2663ca2e520 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>


                    

                    
... this Fixes tag is incorrect?


                  

                  
I think the Fixes tag is accurate; the code was OK before that change.
Nothing in c_early_init hooks depended on (some of) the x86_capability
fields being populated, which is required after the change.


                

                
I agree. Hence:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

I wonder though whether while there we wouldn't want to also store ecx if
we already have it. (Really there is the question of whether we haven't
other cpu_has_* uses which similarly come "too early".)


              

              
Yeah, I was about to do it, but it's not strictly needed for
c_early_init, and it's done anyway just after the call to
c_early_init.  I can set that field also, but then I would need to
tweak the comment ahead, something like:


            

            
Sure, i.e. fine with me.


          

          
Oleksii, can I please get a release-ack for this to go in?


        

        
Do bug fixes actually need release-acks just yet?


      

      
I always err on the side of caution and ask for them.  Maybe Oleksii
can state if/when he formally wants release-acks for bugfixes.


    

    
I am okay not to have release-acks for bugfixes until the end of code
freeze.

When I will announce a next stages of release process,
I would put such the information explicitly.

Thanks.

~ Oleksii


    

      
Regards, Roger.


    

  


--------------uedu0LlpqIQn4v00k4cqBRWM--


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 04:41:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 04:41:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1130971.1470238 (Exim 4.92)
	(envelope-from )
	id 1v20Gs-00078A-KI; Fri, 26 Sep 2025 04:41:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1130971.1470238; Fri, 26 Sep 2025 04: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 1v20Gs-00077r-F1; Fri, 26 Sep 2025 04:41:26 +0000
Received: by outflank-mailman (input) for mailman id 1130971;
 Fri, 26 Sep 2025 04:41: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 1v20Gr-00077l-9M
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 04:41:25 +0000
Received: from PH8PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170120001.outbound.protection.outlook.com
 [2a01:111:f403:c107::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0b9bc330-9a93-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 06:41:19 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH8PR12MB9792.namprd12.prod.outlook.com (2603:10b6:610:2b5::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Fri, 26 Sep
 2025 04:41: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%6]) with mapi id 15.20.9160.008; Fri, 26 Sep 2025
 04:41: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: 0b9bc330-9a93-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gP9FElv+5JI4EhHO2ki/+miGga52hkZ+RpshxyedmF0GcWZMmJ8gltLnNdFmy1zdNOZ+opTqgiG8Tk799EtmPf1KprfAvZchXFxrPbTEYkFlklXUgnqoaM/dGNQohzaFRMGio9HyVR6tJyk9+lKlX7b+Klk3R8ZYuVimN6UMN+3Lyee1MaSkVpoA5Wv3ebvbsYDKZE37fhSchpsQkE51NKeju2SWm4tDqSzQCjfzg1c1YG3lnG0dIiy7Yqzr2/aXDhLYXsmFVj7UvxHZSwh4vEldR63lgRmX9x6fnuX75q9SNobs7wbcAnQC4mwvvkEztThQGf/dHYTVVLuWuBU0ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WyDPKCJQwg4Wc2D17b+N6+AnfjJEfB6pNcUtvhh98FI=;
 b=rtvVmOv4WQMlQunVjF6LOC18+/jtOCR+OYIqZQ8B6WNBBe8rD005p3WjkPXmPErAefkA4toxHvau3J5FYn2yqlrUAM8pnYUXd3wjxCyIsWdrqzcVA7fHAYg/OHXbExFHez22z8zl+nUMpe446fmUSs6QIeka2cIW48+mXYfEC8GC06O3GWVETp2U9g64zB7muCq7gThBRh0PMvfjf0n6Ovr8hpAu9BMRFnZbMfFRcj0fF5zSLM9QffAVFP/pIsOFbte3BBYBvhqIqdMkNAD/gIiV8Gu0c1y5HQaJQYsX94AuTNkwhmBdwyNQTm49L2MykETfcpRnzorF7ffZR/lTaw==
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=WyDPKCJQwg4Wc2D17b+N6+AnfjJEfB6pNcUtvhh98FI=;
 b=zbpgPLvgeJKzy+7vuJyEsSmB3xyVJCEJ0xnZwtUy4qUJb/e2QQ95t+9PN0Mnw4iczt8J+53IR5frPu5kH3nAVBrxeysLS6XTNtqKEtkl6dgxuWLzvthnMMQfOocCZPPvBq7Tr2TNg4DyQKdhxXG+7P9NkpL8SA42OOK3japC6Vg=
From: "Penny, Zheng" 
To: Jan Beulich , "Stabellini, Stefano"
	, "Andryuk, Jason" 
CC: "Huang, Ray" , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	, "Andryuk, Jason" ,
	"Stabellini, Stefano" 
Subject: RE: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYYEaVyPVCsmkah0K573htVM7SN/BaAgBWuJICAAGLSAIAA6DCQ
Date: Fri, 26 Sep 2025 04:41:15 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@suse.com>
In-Reply-To: <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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-09-26T04:39: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_|CH8PR12MB9792:EE_
x-ms-office365-filtering-correlation-id: b7ccaa0d-1bf7-4302-ecb9-08ddfcb6ed6e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bVFwSHE5eU4yNGk2QVFvM1p0ZTllQkQ3S0RrbVNncDhXb2Rvejh4bDBaQy8x?=
 =?utf-8?B?UFdWR2JiRlNURzFYY3I1Kzg4RVRNSU1TeTBiRWJDWlo4VnI3dkpPcEpLZEp4?=
 =?utf-8?B?d0xPMnJJUzhib1FUclR1RkhPMVZQSW9ROXNoNUVJTmN3Ly9MSkxnN1dLalN1?=
 =?utf-8?B?OTg1bXpTa1U3R0QxYjQ2YVNOYzBySG1IZUJQdEtDVGlIYjJ1TzZvVjFkc1J6?=
 =?utf-8?B?b1JKeXM1ak5NL2VBdmp1YW1VYnBuN0dpWjZXQ1dyaVE0c2VXZEdMWGxTWE05?=
 =?utf-8?B?WDN3eUI3YkxYalJQeGl2V3R4bGMveGZTb2ZkOEtxd2MwVEV0UXptYVRycWZM?=
 =?utf-8?B?Tk1vNGZWa0tObTMxNUZCa0VySzNRVkt2RTF5K2NXRFJIQlhab2RFREthQ0hS?=
 =?utf-8?B?TXg2Vi9kaW1weWxLMDZsblBScDNXR0J5WlVkeURBbUhTSGRldm9EZVFxcHp3?=
 =?utf-8?B?dmlOOXJ1UEViUFVFcXMvVjhRTkFnWFZxaVlwcFlBQ0d3OHplMHE1RFBLdGE2?=
 =?utf-8?B?aVhmQjF0RHY2WklGUTl3VG9aY3ZFYmlONURtUWJKKysxcG9JWXZJcm9mV0kw?=
 =?utf-8?B?dS92QjhuUzV0b0QzbnA1N0FZTFVQd0YrRDNiMzcxZDNJKy95amRZbHdGWS9W?=
 =?utf-8?B?MFA3WDdSdnpxTUgxQit3bkRWdTZNT09lSW9WdTJ5U3drTCtqWm10RmZ2ZnlX?=
 =?utf-8?B?VmV2S2VSVUpYUGdGeEdWdkw3cnZFVWNKK1lXZ1lXSDg3RlA0QmRiMlBwc0lW?=
 =?utf-8?B?cW9JbENKdXRJOUkxMHliT2xZUFNQczExZXRibTFyOUl5QnZiY3kxY2NQNGIv?=
 =?utf-8?B?bmJHT2hCOTBNVmliKzdpdUloM1VOY2I3bWptU1hsNUxBL293TVNUVGNkTGxL?=
 =?utf-8?B?OS92R1dZZi9sc09na2Q4LzZwWCttZkxDVVE1ejdNc3Eybk1pem41MVpqYUNW?=
 =?utf-8?B?b2ZNNitrTlZZWHU0cHB5UEp5V1E5dUc2ZkZxaG9vNC8wdnhrVHpDN3dnc3c3?=
 =?utf-8?B?VU8xRFlPSFFrSUd0MjVGRmkvaWtoRG1PYTl5ZUxmMnlQTXg5RzE4bmU1bWFi?=
 =?utf-8?B?U0JMc3JpUHQwalF5Vk9Bb3hVM3pSMUNkdHNYWHRlQTZrQWk2ZGt1VjkzN0Nr?=
 =?utf-8?B?bmJFa3VhNVZuQXNNWlMwTVlyUktxdi81M0pJaEZtUWQ3V2dUcDR0MFRKMkxP?=
 =?utf-8?B?Y1dPazRIWTBnOHVsdFlXdEVMQXZMK3ZQeWgrNDRYdjhBdHNmS1RNZU9FcFF2?=
 =?utf-8?B?b2M3cGRpWE53WnFjV3c1TUw4Tzh2YnZrV3B0V2xURGhaYzJHRkRYcVRTSytq?=
 =?utf-8?B?TFlpQmtNcGxDWmF2NzhtM2xkcjhCOHZWRitDZ0hQQ0tPdVhKQ0kyMW8rb1R5?=
 =?utf-8?B?VG5OY2xTTXdPc29OU210eUlFUDJxcHdLNm8zK1ludHhNN29jY0FIT040RHZF?=
 =?utf-8?B?NW02MWFCSURpN095bnpxN0dNOFpGRnpLMFgzN1NORlVoQnZuVnlzV3dUQjZF?=
 =?utf-8?B?RFcvTk5NMFVkamNuZHhZaEhaVWtpNTRYT0xMTHZZTXdLbmlCYlRkeG80NTY2?=
 =?utf-8?B?MW1uM3ZtRHNIeWFoeEY3UVRCZEpUczkxZUdiTnBtTS9vK3drSXg1Tm1zdkRV?=
 =?utf-8?B?Z1RabXNwYzc1b1RiY29PeTM2N09HMTNXV1hEazBMVkRsWjVLOGR2QkJLWUd0?=
 =?utf-8?B?bE1EWXNNTTRNUnNpeHRsS0IrdTlBQVU3SllhVDVqUG1vYjRGaDFMT242OVpK?=
 =?utf-8?B?Z1czL2ptQkw0eUJWOFJNZzR3aGYyc0pJdDNXL3NTbGE3SnFjcXRVZlRWNXZa?=
 =?utf-8?B?c0dHMEx3SFJsbjJyVzRyZS93QktIL2ZYN2FzQ0tnY3pEWlBZNVlVZ3F2UEE2?=
 =?utf-8?B?WWhjc0ExajN3UDFxSzdETnlrNy9Pa0ZGNXkrNmhFRllxYjBITEdTWVBFMmp1?=
 =?utf-8?B?ZFJxM0hLa3VuTEcwUFlGWWN3dnhhU1Z6TFdUNEN4dTU3VnhCa0RDSG01Y2gx?=
 =?utf-8?Q?RVtGVvte+8HDnEpddS0BMaTlOdhRpw=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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SEpEV09aa2RlZWUwQlFwVkJtSE1mWktIVUhWZEhyM3VMU3Q1enlxVklQQ1J6?=
 =?utf-8?B?Sk1WVnl2UGRqTlZuVVFCVEp2eXBNaU1hOFlSbWVpdXFZTVEzNUpYWEFQMjBl?=
 =?utf-8?B?Si9Uak9qODBIcVVTRk8xcFlIQ1lvYnZURmtPSjlET1ZnaXE2OUpWZDBFOEVa?=
 =?utf-8?B?WFpZQVA2aHNFdUorci9WUHEwOWREL2hvTTJldkVGS2pMV2kxdnM0WWRBSEE4?=
 =?utf-8?B?M2J2OVFmYTZpQlV3d2YrQmxoQ212YzNHcmo3djNKY3lCRFJMcEpUeG9qUHBX?=
 =?utf-8?B?TjJ3VkJTVVk0UUZ6Yi9kSXFuaDd4YjVYam1XV29ITk44Vm5WcjJwaWRXTmdh?=
 =?utf-8?B?d0txOXc2Ty9qdWE2SmRCUytaN1BtamRQa01FQldsVEhXVllRanZmZFhmZFc4?=
 =?utf-8?B?UWZ1UERoMjlPN25UbVQvZXo0Y3JwL1pKWUE1M0dxQW9lRm9jMjNQOHBUbnhF?=
 =?utf-8?B?Y21FWTJhY2lBWmZrUklFZUZ4QVZsUjE1YzdEbGliQmtxNUREVkM4VXluV3VS?=
 =?utf-8?B?NEtzbXBhcXZiNEtxblU3QWpHekMxMmE2eHljSitReURuUVJBemdkekVTMXhw?=
 =?utf-8?B?eXpaTVh0VGFuQVE4RG14bTEwWlJDQ2tFdFdaVm9qNndPNHQ5VU5kLzB0NWlF?=
 =?utf-8?B?cDd5ZTFocFd4dTZJcUhwdURIR1RQNWhZVGlyN1luekR1L1ZOT2lOcFhSYTJJ?=
 =?utf-8?B?eFlmWDR6MjA0MjNXVkhTenU2UnJLd1FpTmQ0Yk1XMDNYem9IUTkrRTZhTkQ0?=
 =?utf-8?B?N0ZJT0Z4SEZhbVdOaFIyNFNQc2hkWDcrK2psWkRVYzdYbDNvM3lYdy9seVoz?=
 =?utf-8?B?RVl0YVZxRnJLdUgvSjl3V2VVM1lnWlh0SzRCNXEzSWR1SXJ5Yi9DT0p6SERG?=
 =?utf-8?B?SEJRQWNXV3BrVjlrWFlXK2JJMWIvdmYzanpla0RiRDNkTjNDNEVmMTdmbU04?=
 =?utf-8?B?amVWY3V6Y2NybGFzV2hGUjRpaGF2eTg4VVB1ZkkzdTMxQy9qRnlkZCttTjVi?=
 =?utf-8?B?VlllZzFCOUp0M01yenZ1RnpNUmJsNW5TczJWZFd0VW5UbVNLVWJrU2prWDF6?=
 =?utf-8?B?RDE3OCs1THJIZ2xIdm55M3RzUGp2Q2JEdUhZb0ZPZCt6L2tSY3JudzFtaHpZ?=
 =?utf-8?B?M1R6V1pVeHAwQmFjbWNJKzNKMDBuaVlUVGN5dWpneFBVQzBFb052bC82M0ds?=
 =?utf-8?B?VDQ1SEp2MEhISzhzZkwxQnNrZlNIWEU3c2FBVnBkYTdzUkZZWXFRZEdPU3Nx?=
 =?utf-8?B?KzdPbjZQYS9WMzFVcnd6Q1RlR0JuUzBVbUVvSXJZV3hTYnJ2SmI0NTM2N0pS?=
 =?utf-8?B?Q1JPWUQ2YW5FQ09NdTFDemFUR0lMZHFPamN4anFnU2MzVnpneGgzckhYbGNR?=
 =?utf-8?B?ak1wMGNocXdvYS8vQU91UUJCaWNsazF3ektRSWE3S2JnM05jOUdlV1VDTjV5?=
 =?utf-8?B?NTkvbFltNVV3NWFYQ2djUjVFbDJqa2pqY1RMV04xc3Y5Y1pIcy8zQmR6ZHlT?=
 =?utf-8?B?WmFpbXV2N3djbVhKYWJiZmlDanhvOFVDZ2hhTUE2WTc4MUtscStmMndvVm9i?=
 =?utf-8?B?UEd2VEZGU1I4ODJVemJDdWtvaE82WGE3c1dBTkI1MWJuaGN6Y21nUE90WWNX?=
 =?utf-8?B?d0VOaTVWUUs1eHdsS0tWTE1kQk9SYjVTcnNVb2VqV3pUbGdwNTVVMEM5WFY4?=
 =?utf-8?B?MUpPTDNHZjAvU3Vzc0swSlBtei93eHY5ellUS3p6ZUlsNWNuYVhIWHJNV1RG?=
 =?utf-8?B?VjNqR2FhTVYyZ0gyVzd6cjVXeDBaNVVQUjM2ZjNtTW1UVmZPdERvK1JucU9O?=
 =?utf-8?B?cCt2QXNxaTdCNW9zQlhia0tNZEFGTFkydFZzYitLZkZmQVNVVkdRK3VYMlEv?=
 =?utf-8?B?M1BEYXNQOEdsN3B0Q09hM3pBUUova2kvVjEzTTkxWkxzdS81TnMzVGdudExw?=
 =?utf-8?B?T3FmZ2FrMlpnSTV5ajJYSkJVUk42MnBvWVVSUXZjWWdGalJhdy9lQUFtWjE5?=
 =?utf-8?B?Zm5lRVFNVXFNL1g5d2srU2dNYnFzVVJwKzIzUVBzVHNuQzEzckJaeFRqQ0RU?=
 =?utf-8?B?Ym5Ic0pHcGkzMm1rS3RvOUNlOEttRWJ0K1cyS3pYVTk1cUFLdXU3U0RFcVBT?=
 =?utf-8?Q?gL1k=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: b7ccaa0d-1bf7-4302-ecb9-08ddfcb6ed6e
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2025 04:41:15.3742
 (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: jTkSZKbvQ48dOhhEDgMgVBh0PrloG+C6EwKSjzabBJ7Xw7VFbZLADWWnkfer70L5hTTj0bq82y6r4x3wD/oRQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR12MB9792

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUs
IDIwMjUgMTA6MjkgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4N
Cj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgRGFuaWVsIFAuIFNtaXRoDQo+
IDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2pl
Y3Qub3JnOyBBbmRyeXVrLCBKYXNvbg0KPiA8SmFzb24uQW5kcnl1a0BhbWQuY29tPjsgU3RhYmVs
bGluaSwgU3RlZmFubyA8c3RlZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+DQo+IFN1YmplY3Q6IFJl
OiBbUEFUQ0ggdjIgMTgvMjZdIHhlbi9kb21jdGw6IHdyYXAgeHNtX2dldGRvbWFpbmluZm8oKSB3
aXRoDQo+IENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4NCj4gT24gMjUuMDkuMjAyNSAxMTo0MSwg
UGVubnksIFpoZW5nIHdyb3RlOg0KPiA+IFtQdWJsaWNdDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
Pg0KPiA+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDI1IDk6MzAgUE0NCj4gPj4g
VG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gPj4gQ2M6IEh1YW5nLCBS
YXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgRGFuaWVsIFAuIFNtaXRoDQo+ID4+IDxkcHNtaXRoQGFw
ZXJ0dXNzb2x1dGlvbnMuY29tPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+ID4+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMTgvMjZdIHhlbi9kb21jdGw6IHdyYXAgeHNtX2dldGRv
bWFpbmluZm8oKQ0KPiA+PiB3aXRoIENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4gPj4NCj4gPj4g
T24gMTAuMDkuMjAyNSAwOTozOCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4+PiAtLS0gYS94ZW4v
aW5jbHVkZS94c20veHNtLmgNCj4gPj4+ICsrKyBiL3hlbi9pbmNsdWRlL3hzbS94c20uaA0KPiA+
Pj4gQEAgLTU1LDggKzU1LDggQEAgc3RydWN0IHhzbV9vcHMgew0KPiA+Pj4gICAgICB2b2lkICgq
c2VjdXJpdHlfZG9tYWluaW5mbykoc3RydWN0IGRvbWFpbiAqZCwNCj4gPj4+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dldGRvbWFpbmluZm8gKmlu
Zm8pOw0KPiA+Pj4gICAgICBpbnQgKCpkb21haW5fY3JlYXRlKShzdHJ1Y3QgZG9tYWluICpkLCB1
aW50MzJfdCBzc2lkcmVmKTsNCj4gPj4+IC0gICAgaW50ICgqZ2V0ZG9tYWluaW5mbykoc3RydWN0
IGRvbWFpbiAqZCk7DQo+ID4+PiAgI2lmZGVmIENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4gPj4+
ICsgICAgaW50ICgqZ2V0ZG9tYWluaW5mbykoc3RydWN0IGRvbWFpbiAqZCk7DQo+ID4+PiAgICAg
IGludCAoKmRvbWN0bF9zY2hlZHVsZXJfb3ApKHN0cnVjdCBkb21haW4gKmQsIGludCBvcCk7DQo+
ID4+PiAgICAgIGludCAoKnN5c2N0bF9zY2hlZHVsZXJfb3ApKGludCBvcCk7DQo+ID4+PiAgICAg
IGludCAoKnNldF90YXJnZXQpKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkb21haW4gKmUpOyBA
QA0KPiA+Pj4gLTIzNCw3DQo+ID4+PiArMjM0LDExIEBAIHN0YXRpYyBpbmxpbmUgaW50IHhzbV9k
b21haW5fY3JlYXRlKA0KPiA+Pj4NCj4gPj4+ICBzdGF0aWMgaW5saW5lIGludCB4c21fZ2V0ZG9t
YWluaW5mbyh4c21fZGVmYXVsdF90IGRlZiwgc3RydWN0DQo+ID4+PiBkb21haW4NCj4gPj4+ICpk
KSAgew0KPiA+Pj4gKyNpZmRlZiBDT05GSUdfTUdNVF9IWVBFUkNBTExTDQo+ID4+PiAgICAgIHJl
dHVybiBhbHRlcm5hdGl2ZV9jYWxsKHhzbV9vcHMuZ2V0ZG9tYWluaW5mbywgZCk7DQo+ID4+PiAr
I2Vsc2UNCj4gPj4+ICsgICAgcmV0dXJuIC1FT1BOT1RTVVBQOw0KPiA+Pj4gKyNlbmRpZg0KPiA+
Pj4gIH0NCj4gPj4NCj4gPj4gVGhpcyBpcyBpbiB1c2UgYnkgYSBYZW5zdG9yZSBzeXNjdGwgYW5k
IGEgWGVuc3RvcmUgZG9tY3RsLiBUaGUgc3lzY3RsDQo+ID4+IGlzIGhlbmNlIGFscmVhZHkgYnJv
a2VuIHdpdGggdGhlIGVhcmxpZXIgc2VyaWVzLiBOb3cgdGhlIGRvbWN0bCBpcw0KPiA+PiBhbHNv
IGJlaW5nIHNjcmV3ZWQgdXAuIEkgZG9uJ3QgdGhpbmsgTUdNVF9IWVBFUkNBTExTIHJlYWxseSBv
dWdodCB0bw0KPiA+PiBleHRlbmQgdG8gYW55IG9wZXJhdGlvbnMgYXZhaWxhYmxlIHRvIG90aGVy
IHRoYW4gdGhlIGNvcmUgdG9vbHN0YWNrLg0KPiA+PiBUaGF0J3MgdGhlIFhlbnN0b3JlIG9uZXMg
aGVyZSwgYnV0IGFsc28gdGhlIG9uZXMgdXNlZCBieSBxZW11ICh3aGV0aGVyIHJ1biBpbg0KPiBE
b20wIG9yIGEgc3R1YmRvbSkuDQo+ID4NCj4gPiBNYXliZSBub3Qgb25seSBsaW1pdGVkIHRvIHRo
ZSBjb3JlIHRvb2xzdGFjay4gSW4gZG9tMGxlc3MvaHlwZXJsYXVuY2hlZA0KPiBzY2VuYXJpb3Ms
IGh5cGVyY2FsbHMgYXJlIHN0cmljdGx5IGxpbWl0ZWQuIFFFTVUgaXMgYWxzbyBsaW1pdGVkIHRv
IHB2aCBtYWNoaW5lIHR5cGUNCj4gYW5kIHdpdGggdmVyeSByZXN0cmljdGVkIGZ1bmN0aW9uYWxp
dHkoLCBvbmx5IGFjdGluZyBhcyBhIGZldyB2aXJ0aW8tcGNpIGRldmljZXMNCj4gYmFja2VuZCku
IEBBbmRyeXVrLCBKYXNvbiBAU3RhYmVsbGluaSwgU3RlZmFubyBBbSBJIHVuZGVyc3RhbmRpbmcg
Y29ycmVjdGx5IGFuZA0KPiB0aG9yb3VnaGx5IGFib3V0IG91ciBzY2VuYXJpbyBoZXJlIGZvciB1
cHN0cmVhbT8NCj4gPiBUcmFja2luZyB0aGUgY29kZXMsIGlmIFhlbnN0b3JlIGlzIGNyZWF0ZWQg
YXMgYSBzdHViIGRvbWFpbiwgaXQgcmVxdWlyZXMNCj4gZ2V0ZG9tYWluaW5mby1kb21jdGwgdG8g
YWNxdWlyZSByZWxhdGVkIGluZm8uICBTb3JyeSwgSSBoYXZlbid0IGZvdW5kIGhvdyBpdCB3YXMN
Cj4gY2FsbGVkIGluIFFFTVUuLi4NCj4NCj4gSXQncyBub3QgIml0IjsgaXQncyBkaWZmZXJlbnQg
b25lcy4gRmlyc3QgYW5kIGZvcmVtb3N0IEkgd2FzIHRoaW5raW5nIG9mDQo+ICAqIFhFTl9ET01D
VExfaW9wb3J0X21hcHBpbmcNCj4gICogWEVOX0RPTUNUTF9tZW1vcnlfbWFwcGluZw0KPiAgKiBY
RU5fRE9NQ1RMX2JpbmRfcHRfaXJxDQo+ICAqIFhFTl9ET01DVExfdW5iaW5kX3B0X2lycQ0KPiBi
dXQgdGhlcmUgbWF5IGJlIG90aGVycyAoYWxiZWl0IHBlciB0aGUgZHVtbXkgeHNtX2RvbWN0bCgp
IHRoaXMgaXMgdGhlIGZ1bGwgc2V0KS4gQXMNCj4gYSBnZW5lcmFsIGNyaXRlcmlhLCBhbnl0aGlu
ZyB1c2luZyBYU01fRE1fUFJJViBjaGVja2luZyBjYW4gaW4gcHJpbmNpcGxlIGJlDQo+IGNhbGxl
ZCBieSBxZW11Lg0KPg0KDQpVbmRlcnN0b29kLg0KSSBhc3N1bWUgdGhhdCB0aGV5IGFyZSBhbGwg
Zm9yIGRldmljZSBwYXNzdGhyb3VnaC4gV2UgYXJlIG5vdCBhY2NlcHRpbmcgZGV2aWNlIHBhc3N0
aHJvdWdoIHZpYSBjb3JlIHRvb2xzdGFjayBpbiBkb20wbGVzcy9oeXBlcmxhdW5jaC1lZCBzY2Vu
YXJpb3MuIEphc29uIGhhcyBkZXZlbG9wZWQgZGV2aWNlIHBhc3N0aHJvdWdoIHRocm91Z2ggZGV2
aWNlIHRyZWUgdG8gb25seSBhY2NlcHQgInN0YXRpYyBjb25maWd1cmVkIiBwYXNzdGhyb3VnaCBp
biBkb20wbGVzcy9oeXBlcmxhdW5jaC1lZCBzY2VuYXJpbywgd2hpbGUgaXQgaXMgc3RpbGwgaW50
ZXJuYWwgLCBpdCBtYXkgYmUgdGhlIG9ubHkgYWNjZXB0IHdheSB0byBkbyBkZXZpY2UgcGFzc3Ro
cm91Z2ggaW4gZG9tMGxlc3MvaHlwZXJsYXVuY2gtZWQgc2NlbmFyaW8uDQpUaGUgbWFqb3Igcm9s
ZSBvZiBRRU1VIGluIGRvbTBsZXNzL2h5cGVybGF1bmNoLWVkIHNjZW5hcmlvIGlzIHRvIHByb3Zp
ZGUgbGltaXRlZCB2aXJ0aW8tcGNpIGRldmljZXMgYmFja2VuZC4gU28gd2UgbmVlZCBoeXBlcmNh
bGxzIG1ham9ybHkgaW52b2x2aW5nIGlvcmVxIHNlcnZlciwgZXZlbnQgY2hhbm5lbCwgdmlydHVh
bCBpbnRlcnJ1cHQgaW5qZWN0aW9uIGFuZCBmb3JlaWduIG1lbW9yeSBtYXBwaW5nLCB3aGljaCBz
aGFsbCBub3QgdXNlIFhTTV9ETV9QUklWKHhzbV9pb21lbV9wZXJtaXNzaW9uKCkveHNtX2lycV9w
ZXJtaXNzaW9uKCkveHNtX2lvbWVtX21hcHBpbmcoKSkgY2hlY2tpbmcsIEkgYXNzdW1lLg0KDQo+
IEphbg0K


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 05:49:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 05:49:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131004.1470248 (Exim 4.92)
	(envelope-from )
	id 1v21Kl-0006JH-EO; Fri, 26 Sep 2025 05:49:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131004.1470248; Fri, 26 Sep 2025 05: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 1v21Kl-0006JA-BX; Fri, 26 Sep 2025 05:49:31 +0000
Received: by outflank-mailman (input) for mailman id 1131004;
 Fri, 26 Sep 2025 05:49: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 1v21Kk-0006J4-8S
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 05:49:30 +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 9118b182-9a9c-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 07:49:29 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-62fa99bcfcdso3524663a12.0
 for ; Thu, 25 Sep 2025 22:49:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353efa494esm304224366b.25.2025.09.25.22.49.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 22:49: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: 9118b182-9a9c-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758865768; x=1759470568; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lnvG1FMq1SWrhj6l5gEFEm0Eiokgh0DtQ0BA/ZHRrUI=;
        b=Zk9FgQS/RKd1UvIjHVmtw8ONqxgs+z79BWaEiQqoUFTtnYC3fs+Q4u9fiLKY9hMz1k
         wbcEeR0vus69xKapDsieaCQ0+N5bUKfrCkD6leJeQU8imKAtoVcXXdGlMHb848SbEPgV
         MLMCclyY26FiZyTdGLpl0etcytvPz4efJcnG62PTuxh1DeWyUlDhr1r4yjkjxB6wEsUi
         VLyRMYbuZctEhVFtloD0/L1rHCH9KqMtNKey4fRtdKqgsgVli9g1SFxRxradIYyIXX/f
         H4vjmvtqxvTmEuxe7Nz9ZjZDNtGB/bSM1djL0BBpxMQgC0yWJQPW0ttRbzx2rkJYOJtf
         5XTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758865768; x=1759470568;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lnvG1FMq1SWrhj6l5gEFEm0Eiokgh0DtQ0BA/ZHRrUI=;
        b=eyx+6VxATMdaEaBR2BIZLIyihPARx1ngj9ThuTbAJFT/gNCSrvPztsYHCMlUXhTDgh
         bkd845J5mX1/fyCuJWjDU3aNTDnxVDm7GhWtrw6Ktgq7sJuZmshHnBDgYM0KL3AmmKCF
         La5FlZWJaU/WlQ7gySMyjybHseqaq9vd7bqlI1xUoIWeoUWdWs0iD+k1z3D15T0Y7Qz3
         9Tl1CDXSA0UbRayF8VYcARtMyd+qNqmFFnL1UdBA9guDT1s86iET+yNzrZtkB4y9vgCQ
         GAflYBUyKaNYyU+/qi+2KdUvBvfwp9IXy8ix2Gh9RfnJFyD+MZa8A4GhQpMSn6fynjS+
         tCSg==
X-Forwarded-Encrypted: i=1; AJvYcCXtcoTT0T0XXbAxPUZjsQUfHz4UviiRaduBP9OYIFHQ17TvfXzS0z4huemj6VAy6it9tIlDtvs51/4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzjNDMOGm+93Y9DE1pXHEj7jS0A5wEetvckVcS8uGgHZ/fovM4f
	+6ZaBF7SmEFgBhqPd0+rhujwZ8C5Yyj1Mgl4AU7vqgNXhQT/RA4KU5eVr+ywml8P5Q==
X-Gm-Gg: ASbGncuANa/ddWYavs0YRrB0w5hCS2S2zV2Gcqpa8MKVzbhLwFLtM7FnN22wtIUtc8b
	BlYzTsWwUI1byeBXNFgNXoF03G72jLG/AkqZgSdzDOirDqYckwRr7elTikz+lFkIkMN5WqaR8RM
	wesRiMBITefoJO41eZLkcO6IGvaPLSt1gpHotpigV3WOlLA3v1ioupuE6imvOgmgcEuNy1FQBQW
	H27o6dSYT4rYWQOo9OouYIen5rqxKUymwv1aK+i9N2SVk8aBfqJ3vcnJ7AsYMKMb7yDkyD2Enx7
	Id81KVJn0N+V4YlTgKqsVTCyiIRzJSvVHuNzImN+E5f/GpIaTKjGY/wuxIE7H20iZlsByUA88cb
	YToptBZ4NECFKCan1pVVrkYHbqsFqdDexk6NLx4nlD3551vPI5jG47zgYjam9geF9OrrgWXd+FV
	CyilUkNpG+KRDcsUoKBQ==
X-Google-Smtp-Source: AGHT+IGRxONJWsWBYVkLgy2x/gdVqrEy8Hjsfs2zwBhI3CehH9je4dWluplYv3D1dDEP6MOLRDRz6A==
X-Received: by 2002:a17:907:9411:b0:b07:a76e:db6e with SMTP id a640c23a62f3a-b34b80b0fecmr622467266b.21.1758865768356;
        Thu, 25 Sep 2025 22:49:28 -0700 (PDT)
Message-ID: <68350569-4e53-4845-b3df-22ec15e4ee30@suse.com>
Date: Fri, 26 Sep 2025 07:49:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CHANGELOG.md: Update for 4.21 release cycle
To: Oleksii Kurochko 
Cc: committers@xenproject.org,
 Community Manager ,
 xen-devel@lists.xenproject.org
References: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
 <814501c8-94e3-4930-87ed-88e7506456ed@suse.com>
 <97488f35-3f94-42b0-8443-4feacf3d587d@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: <97488f35-3f94-42b0-8443-4feacf3d587d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.09.2025 22:22, Oleksii Kurochko wrote:
> On 9/25/25 8:26 AM, Jan Beulich wrote:
>> On 24.09.2025 11:36, Oleksii Kurochko wrote:
>>> --- a/CHANGELOG.md
>>> +++ b/CHANGELOG.md
>>> @@ -14,6 +14,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>    - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
>>>      to the baseline change.
>>>    - Linux based device model stubdomains are now fully supported.
>>> + - Remove libxenctrl usage from xenstored.
>>>   
>>>    - On x86:
>>>      - Restrict the cache flushing done as a result of guest physical memory map
>>> @@ -21,6 +22,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>      - 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.
>>> +   - Allow to unflatten DTs.
>> What is this about? There continues to be no use of DT on x86, so without context
>> this feels pretty much meaningless to me.
> 
> I am referring tohttps://lore.kernel.org/xen-devel/20250722000525.7247-1-alejandro.garciavallejo@amd.com/.

Sure, but what practical use does this have for anyone using Xen?

>>> @@ -36,11 +38,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>      - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
>>>        Connector), 9 (System Slots), 26 (Voltage Probe), 27 (Cooling Device),
>>>        and 28 (Temperature Probe).
>>> +   - Basic kexec support to Mini-OS for running in PVH mode.
>> Hmm, MiniOS isn't an integral part of a Xen release, so I wonder if such really
>> belongs here. Yes, I also understand that there's not really anywhere else to
>> put such.
> 
> I decided to put it here since we include information about stubdoms in|CHANGELOG.md|,
> and MiniOS is related to that.

Stubdom code is part of the git repo and hence the tarball. MiniOS isn't.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:32:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:32:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131024.1470258 (Exim 4.92)
	(envelope-from )
	id 1v220g-0003s2-HY; Fri, 26 Sep 2025 06:32:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131024.1470258; Fri, 26 Sep 2025 06:32: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 1v220g-0003rv-Eb; Fri, 26 Sep 2025 06:32:50 +0000
Received: by outflank-mailman (input) for mailman id 1131024;
 Fri, 26 Sep 2025 06:32: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 1v220e-0003rn-R1
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:32:48 +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 9bf3894d-9aa2-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 08:32:44 +0200 (CEST)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by PAXPR03MB8084.eurprd03.prod.outlook.com (2603:10a6:102:223::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Fri, 26 Sep
 2025 06:32:40 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292%4]) with mapi id 15.20.9160.008; Fri, 26 Sep 2025
 06: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: 9bf3894d-9aa2-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VNLUr2yUHIVT59pl8K+2UUS3fmJJxPHm9lCtPTquEbHRLi5vRlVESlSHPDCECZn50rtqgRRSnNRoGLc/v1EHKYZkYMx/UtrXsXRHIM35TmHt8osCuMHTTGmNOGOhTOO/l+RwC2Mfomn/CQc6wculflAjnnTDCYUhWBvGGM9x99WXcefSSFiB0hQ9PB16YgYC4ZaGHJKUg3OM1TTjwYDtpuTIFyxxSLg4oFfpZl14cxqBNWjPlS8NzMA2f+tanyIR0K6eSuToVIQhKn/UoquiODuUwry0vUiCO7LrbRLwqBgB5qeGM+w74QZ62QAPOHol6QI6dFkAw8hgmHaCvHv/3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=m4ah3Tq65ga8DUMZGxx2igrEChh0oFq2p5n4iT/UrUU=;
 b=H0n2zMMlsmAHC+Jb5z/cAKackkFngunvRiktl1q7Yf/VcobRS3Qmjeo5DmzzrqDCnWiDje06KSUD5FX3jedRYkbAGSZf0/h1dlBnrHyIFH/X2rQVnLooaS5/oErWacGOjNpg97dg7cXiFswk9KSUu6MYueLccgrEJUdB/BimeNNIFnlewSEcGAFjjcc86cjsm2GK801pnXF1zu5knko+ofZLUPc5iLsJ2fbpThxnwZ2gdl2WKdtwMAtZUntEdNAuVYJWOQF74zyP0xTS7856FBNmIHPtVta3PlvYty7BGroAkWomsQZE/3J8tX0tr+o5utKYVoT3ZA/12qvwF4EHZw==
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=m4ah3Tq65ga8DUMZGxx2igrEChh0oFq2p5n4iT/UrUU=;
 b=V+uOy6442ndl+tD1lvzFRxkRLXc5XL4EI1UQLcMJ9biTSO5fit1ggoPs68L+ZeXi0TdCPAurSiEcBga6EQcg2Xg2HjTutExZ0WQLR3ntcYpSyVuKSZxVdcT7ZMDiKwpizFPa06aWgmakqhZkL4nGOMAJXAXwo9HgnJAbT0TxlNG/eXN6FjS/SgjnLamWSNxVgxZmPmGLjlkRiemHS88t0sTyVjpdk3qNqXLqitTvnH48fD6crL9XmEfYErWAaVgE8UeSkABKDU6nTp1uFFPePC3PPW8bHcDs3YivQ0Cf9NtpwoJq7mUVXiCH0E6+++bKrjFbZz4q2WWrMTLEETLMTw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Fri, 26 Sep 2025 09:32:36 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] xen/flask: limit sidtable size
To: "Daniel P. Smith" ,
 Jan Beulich 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250901105231.1570041-1-Sergiy_Kibrik@epam.com>
 
 <7b36e8fe-c19d-40eb-b1d7-d869cdfb1a28@apertussolutions.com>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <7b36e8fe-c19d-40eb-b1d7-d869cdfb1a28@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA1P291CA0021.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:19::21) To AS8PR03MB9192.eurprd03.prod.outlook.com
 (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|PAXPR03MB8084:EE_
X-MS-Office365-Filtering-Correlation-Id: 7c60487e-5c4d-4ee0-81b2-08ddfcc67de2
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?d09xSno0bXloNFpyNHRZZ2YwNkxPS3Bqb0E2ZUt1aEtKUnVnUUVZN3dqbkJs?=
 =?utf-8?B?TVdudEtsMGhEZUdMNnpSL3QwbzRoVmxNVWpSV2R2YjhFNFZacSsvcWdEditw?=
 =?utf-8?B?aXJOaW56TlZRWUcwY3ljMndYS1QzR0hYTFI0eGlNVHAvMU5pTklva3BzZDE4?=
 =?utf-8?B?Q1BDdHErcUJ6a2VqR3FnR3FaTVRuMk5WVmluU1BxZGNncXFzdUplb2hXNmIr?=
 =?utf-8?B?M003SWZ4V2I2S3lUTFpUbEkvYXAzbDdBRmVzcEdROWZyd2JPdTlVSEx0ZFdM?=
 =?utf-8?B?akthYkdmSmwzWG9nem4zWFgxR0x2dkM2dmlkZURnUE9vRWJBdWxMdEVNL0Fo?=
 =?utf-8?B?MnkxdGMwR0t5V0Rnb3h6T0ZXb2luTUt2Wlh2WVdZUGcwTHhqZDcwdFBLL2VE?=
 =?utf-8?B?dDZSU0VESk5COUJVRnNwenRMVFJDa1Y0QjhHb2RXVEp0YWZ1S1ROY0V5MUd2?=
 =?utf-8?B?VzRjT2QvUXA1QlR4NWhZKzRsTU5OaVRSSzZxNjMzMEF2SklhWDhoY09FdnV0?=
 =?utf-8?B?Y09jUmljeU5QZVNJSks4Z2tsUFpnWUVXUnA2eURoaDY0RSt1b25sMFZta0NT?=
 =?utf-8?B?YlNmUlpEYTBHS2hob0xIeXl3Q21mWERZclEyYTRNcW5hTkNyZzBpYUFUR2hv?=
 =?utf-8?B?MnJ3ZTZxbE5WL1F5VWEwa2QvWDUvMEpmUkt3VG0wN09yR25qZytIdHhoS05R?=
 =?utf-8?B?WVFxMkc3ZHl0Q2pxckhuQVg4YlQ2RFhkbTAyZkpiSjVmOWM2Sk1oSmF4bEtj?=
 =?utf-8?B?MldrTWM0WGlIN29tbmxhZ0FNOUZkOG11Mzd6YzFMMlN1ZjJPUDFDTyt1NkdX?=
 =?utf-8?B?MVRSZ1dHSnVXb296T3BwUE0wbVcxbHBXMUg1c0JXZ2k1S3FmZzVrWWFHTG1x?=
 =?utf-8?B?aUtOc0o4ZUFiaTdhRXBDV0hxNXdCZy9QRnlDRFZKY3Q1NEQ5eHFYZzNkTkhG?=
 =?utf-8?B?Tk5JSjllM0NZRnp5RkVzVmY2UHUvTGk2VFMzVFZoRFQzbVZuSVVZM3R0UUtM?=
 =?utf-8?B?VVMzV0w4R1EwN0h5WkgwbFEra0Rxa0dUYlFKQmtsY3pWT3lTWUtaUlNpVHRk?=
 =?utf-8?B?MDZkcmNtVjFxRWZ2N3FtVlFFWWJqaDVFMklCZFVHYzFEWFJzMG9ZSmFwOTdk?=
 =?utf-8?B?WXVDdmJWUVBoS1BNVkdjUnB2aitlZUpYSDBjVEVCeEVWRFc1NTB1eUdvaXpS?=
 =?utf-8?B?SktEZTVneGFoSUFUV3MvdG5FVHJ0dWFNSTRZZFQrUGF4cWY2TVk2VEpPVzdr?=
 =?utf-8?B?ZHlrNE9iZFk3Yzg0WFhEZTNuWC9hTk56RWJiRE1nZFVCbkwyUjJZOUVYa1hO?=
 =?utf-8?B?dWFOd29uUXJJQ3MyVzJpNEFWQ1lZa1ZkMEJJMzJXNjl6TFh1V25mWWhaeXR6?=
 =?utf-8?B?Q0g2a0lETHlNVzRGNU84L29RZW10d3BMcnRxUGdpaU04aU9Ic25WYm04Qk55?=
 =?utf-8?B?S1c4b3F2bmFrR25RZGZlLzZSb200bXRNcktQaWMvdGZVMm1JaVUrMldRbEJC?=
 =?utf-8?B?c2Y2dFZaZmhUbml0SHRDRGcxdEx6emtXcWlxTW11SGNqS2ljSFhFYzFMSXZW?=
 =?utf-8?B?cER1Z1pDZWZScWNJVFhSSDNVblZWem1qZUEycUhCKzlTazM0UUJLd3RYbkNk?=
 =?utf-8?B?em1KT2RlMnYvMjZSSUd3bWdxaTc2NE1xejhVUFhpTldzM1BhUDdzUURlczUv?=
 =?utf-8?B?MngxN2R0UGp6cEkzOXdyYzZnNG96a1JzYXQxN254REczQXRNUEduQ3N4YlVj?=
 =?utf-8?B?RUxtY01mbktadmluMDVHbzY4aFFta2VpdWZXVUNQWXpDRkx5WjhYRi9UVXFa?=
 =?utf-8?B?aGc5VFJrT2draHpvRUlVNUJRbWRrMnQxT2tRNkw4MGpWWGlBcUx1WVNvVkxX?=
 =?utf-8?B?Vm1MQThpbEdDQTIvSkl1M2VlSEJIWVluV3JUbWhBODJUR2x3YjluUnc2ZWJH?=
 =?utf-8?Q?X4sttYu6BE4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SWtNN1FIcG44d2lzNzVqMXd1Rkl3OFNNQjBONW5zL2dRaUIwWng5MFd4c2Vi?=
 =?utf-8?B?OURpcUJ2OWhWdTJ0aHhiU2pyMXJLMjFTM2RQVzNqdGVBNlF2MXhTTVIySlNz?=
 =?utf-8?B?Q09YVTMxS2xseE1LTHd5RkhtM040Qk4vRTBGMG5IQkF4Q3ZncEp2Qm9zOXFh?=
 =?utf-8?B?ME5ZMmF4dGY5eTBzWDdWNTRvclpaaTNwZmRsYmhTTHhRaWxqeEtvc0EzaGNw?=
 =?utf-8?B?Vitkb0NzdzRFT04wUlpKc1dyTVVsKzc2Zzd1M3FQY2pPRGxWRDFlOTcwTkdW?=
 =?utf-8?B?aWwySTdxZ1lhUHBCUUJVQm8xZ21YLzF1ZGIydFBFbGpZb2RxK2NRRTd2eEZ2?=
 =?utf-8?B?OEhpWlllaVhCZTRjMDZxZUpXT29PTnFUTTJjRkJUSngvcWYyUTRZcEFITUgv?=
 =?utf-8?B?ajdKQTVrUXdXdzBmRGRrYldYdnpFVVUyWmZBZEx3YUJpZzkvVnR4RFFieWxW?=
 =?utf-8?B?bkdNcjVHcFRrQjRYeUhYRlJJUjlsOUxxZGY5N2RjZ2VmMlpkd2RXbGxnaXJX?=
 =?utf-8?B?NlZGQ2JjcTF6b2FSNFlYWjJtTUhwNG5Vc3d5Sno0VUNjVGpranRYU2t3ZDRp?=
 =?utf-8?B?NTZtQUZDTGJ1RjdVS0JLZTBzRHRQdUhDemMzSk1GamNwcGhOZU9qeVd0OW80?=
 =?utf-8?B?VVhPbHlISUc0K0c5NnJUY1dtdVJNUkYzZzRYQXFZMXd6TmJDbklZbTVTWVYy?=
 =?utf-8?B?Z01ZOTBrKzZqY29IdGFFSStYYUovK0wrRGlWT1JHSWl0WEQxRllFcEZBVXNi?=
 =?utf-8?B?ck9qRXhndWthTkd6UklYS0c1VWZ0NFM5Mk9Qd0xsMm5DWkZaVTdoWWhXRHEw?=
 =?utf-8?B?KytxTWk2SEVmWi9UdTB5WUZsNDRrRmZKbFByUDRkR0ZOZWVVMWVNU3dwSlhI?=
 =?utf-8?B?MEV1a0phVW9LU0MzdjdmWHhvb1FTUzlZNXFZd3J1Z3FCVUI5bzZGK1V1SnBJ?=
 =?utf-8?B?eWNsUzQ3aEZjRzQzUEdhSmNPVmduazVvVTZmQTFJcVdtMUY1WisrdUVNWTc1?=
 =?utf-8?B?QVhjd2FENkxGQ1IzVzRXZEovS2xjQi9QMHdTZkkzTmsyY3liL1VyM2o4M0dL?=
 =?utf-8?B?bEFieGg1ckR5aGE0ZjlIUE9QZXJXZ1hPUStGangyV2NMOW5pZEh5NHg0RDNB?=
 =?utf-8?B?ZkFpZExRcU91MzBXNTh4TnZnUWkwL1d1WElEak4xMTFnVC9iZGc1Z254WXFx?=
 =?utf-8?B?Z09qa3QvMlo1eWhLME1JZ1pTQitDRDI1R0pWbks0MEI5RlBqQ2FPTi83TDFY?=
 =?utf-8?B?YTJWMGhyZXpZMFNLallVeWxsczRQWXhDN09ZQXFTWTNCbFBrYmlVRnRkYlg3?=
 =?utf-8?B?U0oydWgvNlc5RkpIRTFLeWRvUm1BVmpVV1dRUlpNblRpelhjNWNwSmkzWk9n?=
 =?utf-8?B?YnppWUJtWXRhWjBjMmRYRitzbCszRmhrTnEzNHNRbXlLNjN3b0FkU051UUI5?=
 =?utf-8?B?SnZ2ZmlMemtyM0FoMDdOTjBjMWdvK2tNRnJTaXQvZkVjREJ6RXFNbEZ3UmpH?=
 =?utf-8?B?THFjU0lGdTJ3c05nWHNQYURSQk9HSkFyMlQvVGlSU0I0QjJiZm9zdU5UdG95?=
 =?utf-8?B?QkE5YlZhbTFIbDY5S2c5UnMzczFFNDdXZmZRQks3V2JnQUtiS3R5QS9lYThk?=
 =?utf-8?B?ZzI3Q1lwM2ZoQ0F0cWx3L3B1ZmVjN1dYb21KNkNCanRKa3huZ2Q4bURoR3Vi?=
 =?utf-8?B?Rk5GN2hEdW1Td3BXNTl2R2VvK3QxNlN6dFY1VnJPVDZJbGxwRlBxNWVBTFRx?=
 =?utf-8?B?cHlXOWh1MTVNRFlvemFJeDN1cFRKVFI0c05WV0tqcTNGVlRXZkVNV0JWQ1h6?=
 =?utf-8?B?b2JvM2xFVXFiKzJIVjJUbEMxa3NnYWVDK0kzWVkrZi84citJNlliemxFbVg0?=
 =?utf-8?B?eEp5QkZnQVJ5eEpHVGdrY2p3Z0luSjByU3pCQXZNeDZFNUxLdEI5RzBnRGIr?=
 =?utf-8?B?aEtWcm4wSWFFUEF3TW14VDlmL0JVS1lLMzJHdmcybGxPRk5LWnBuZmdGTHBC?=
 =?utf-8?B?TmZWWjVVVURVV2xhSS9UdXNlc0pjMDVJVUNOWkw0akpUWTl4dVRCMTFUdlc5?=
 =?utf-8?B?bEVaNUs1OGREMk9Zc2NBMHhYY20vSEZTTzg3a2E5VWRNK2I5c0loRVdjZWNi?=
 =?utf-8?B?REFKVGtqRkJCaVVPWHROYWFpeHQ2dGZrMFFVUWZmZmorejFuQnloSUFZbTFI?=
 =?utf-8?B?WHc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c60487e-5c4d-4ee0-81b2-08ddfcc67de2
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2025 06:32:40.4887
 (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: TGItNSnO4f1ouA8/C9rQgT0WsYfBYKucAhpnV9lG3O0O9ecpZxXS4zjpkEOtZ3a+gvDIRztszkszAEzwtEr3Cg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB8084

06.09.25 01:01, Daniel P. Smith:
> Hi Sergiy,
> 
> If you don't mind, please CC me directly, as I am the only XSM 
> maintainer for which you will need my Ack. And for whatever reason, I 
> cannot find the v2 post in my xen-devel folder. If you want to resend me 
> v2, it would be greatly appreciated.
> 

yes, sure

> 
> On 9/2/25 05:41, Jan Beulich wrote:
>> On 01.09.2025 12:52, Sergiy Kibrik wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS
>>>   
>>>   	  If unsure, say Y.
>>>   
>>> +config XSM_FLASK_SIDTABLE_ORDER
>>> +	int "Maximum number of security identifiers (base-2 exponent)" if EXPERT
>>> +	range 4 32
>>> +	default 32
>> When 32 is chosen (i.e. also the default when the prompt is hidden), ...
>>
>>> --- a/xen/xsm/flask/ss/sidtab.c
>>> +++ b/xen/xsm/flask/ss/sidtab.c
>>> @@ -14,6 +14,8 @@
>>>   #include "security.h"
>>>   #include "sidtab.h"
>>>   
>>> +#define SID_LIMIT ((1UL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1)
>> ... for Arm32 I expect either already the compiler will not like this construct,
>> or the latest an UBSAN checker would object.
>>

you're right, arm32 toolchain is not building this.
Would the following be acceptable then? :

#define SID_LIMIT ((1ULL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1)

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:37:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:37:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131037.1470268 (Exim 4.92)
	(envelope-from )
	id 1v225M-0004Tn-2m; Fri, 26 Sep 2025 06:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131037.1470268; Fri, 26 Sep 2025 06:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v225L-0004Tg-Vc; Fri, 26 Sep 2025 06:37:39 +0000
Received: by outflank-mailman (input) for mailman id 1131037;
 Fri, 26 Sep 2025 06:37:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v225K-0004Ta-HB
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:37:38 +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 4a622c5f-9aa3-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 08:37:36 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-63486ff378cso4027407a12.0
 for ; Thu, 25 Sep 2025 23:37:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353f87511dsm315579466b.43.2025.09.25.23.37.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 23:37: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: 4a622c5f-9aa3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758868656; x=1759473456; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bis+KU+KA0PLLk4iULkzRwvbb9QPLHDV6ubN40wZ3+M=;
        b=J4aRVX5JZ9v6G5o39qk+vyqUzuHyUQ/CHMO5eWStLi46fory7jnQJ0o7QpzC2jbblJ
         VKk0OHh0oZ1TJ4B+vpQsWDvYpq5376EyJcdRYAoiSivdcw6tgUpXrU1PF0DlB+jlSaMI
         knJlWRtPHPNPiVbmxC1C8ByQxbTIoN8DbAuX0MWwxw1NhHDy28AlHq2OBMd5uOL4CKkU
         p/AH1XosM0DOgGGi/6REiINnG8ti7M+4X7xfnHyK4G7hK8/3H05ux5MozrWg+f+alI29
         ydfFnvtg9hrzvRoEAV2iZbEBpwlXH0PFcuW84egLPF8RKOVHofBpFk3ytbh8ebrVaet0
         YK1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758868656; x=1759473456;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bis+KU+KA0PLLk4iULkzRwvbb9QPLHDV6ubN40wZ3+M=;
        b=CWHyMTeS5MhKnEqTP7YVhOtyMGvZeRQisbxX7f8o7divGCPJfJjW+e9HeoC8TWX20d
         SeNHUt2ONhkdqQxuNLC46oYMQDPlF6rw0O2SKlpZCJww0rvaTRMDIkYITBmV79s4OX/t
         yB69sXzvmf+Kn8TrFhQdt5BK1UotE5YKdW1Mw/LOhhplEnWcwehcKEnGGxpyQUX+hXFe
         BkVms8mSzDH75BdIVkH2Pz2rh5tUQsngP0OP7hoW+XkIEwFUD4mru+zOFWzxdbKLQU+7
         XqV281BGX+ScXTnCMasabrbsLLwp/JERwpDlNPAkGtU4fmlroC0CtwWXx7Z8AMMTZAy6
         hbKw==
X-Forwarded-Encrypted: i=1; AJvYcCVLP7RrYJZi2WS7g0zleqZmGfl5UA30ugqrHqPaucFj0prq+5sSgGpa2rQcrtZiE4oCoHWMl8+E1j4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPeLahE1RnHQ3n6bsCISedxWlnINvKm0PqGgZkTagOqgdbbhpf
	qtHWiEzeJk+ZQAH6lufmQXlrZXjE7rAh5W8e6uQdhJiBlxecuALuCMJ5yw0UBQ6seg==
X-Gm-Gg: ASbGncud7GDxWkGFdTjd0BoYKItNd1pi0JALh83N8kiJQi3mQsTDHaRvZUM/OgvxbZT
	XO7njiN3Sl0D56ZTxIMwn77j8JFMgOuufYnBgpUsz8ZjfuU8bP6oPVUSN+PSjzIlTgqyAxphkkX
	IOyXSZfBXY1BT+u5pHUCO3Wd6zPpu7vBy3qToTYVGb34ay6Yv4Z3Rh14yOj1gfszeuqrb7z1ANu
	4iK+0HaPIu3bzPL3Rs2x/kRy3DntLIArsH3sKIasLRUlA1b3pANPPtXFtaexfRKea3Y7MJS34Pz
	udkRnSlI7UKwIpXw/ZWwabUIek8oNeZKzY9YpiRXZwZUfXkL5I3x4PHjoKPXXHBeK13OVKNrP8r
	JKdTbCESkNNTjIyRXBQnE8lkYccpu65eKdU/ZxslWCQYLKenPEOd/EJcmLc6FivpC/2dup44swl
	p35ovX5NY=
X-Google-Smtp-Source: AGHT+IGm9fNyKC8AyW7U7CGWYJkV5quAiBqaelRy7qa8Qn4MRuHwxl2D7JNf6BzieBnlO/NuDtW7Nw==
X-Received: by 2002:a17:907:1c16:b0:b0b:5d7f:6ae4 with SMTP id a640c23a62f3a-b35490f2f27mr516485166b.8.1758868656253;
        Thu, 25 Sep 2025 23:37:36 -0700 (PDT)
Message-ID: <9cf8925c-87c6-44ec-9d46-f8b0ed30f94a@suse.com>
Date: Fri, 26 Sep 2025 08:37:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: mem_sharing: add dependency from
 CONFIG_INTEL_VMX
To: Grygorii Strashko 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" ,
 Tamas K Lengyel 
References: <20250925195607.521021-1-grygorii_strashko@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: <20250925195607.521021-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.09.2025 21:56, Grygorii Strashko wrote:
> From: Grygorii Strashko 
> 
> According to the commit b66e28226dd9 ("x86/mem_sharing: gate enabling on
> cpu_has_vmx") the Xen memory sharing support is only possible on platforms
> with "Intel VT-x" (INTEL_VMX=y) enabled.
> The same commit is also added runtime check for "cpu_has_vmx" in
> mem_sharing_control() which blocks access to XENMEM_sharing_ops if
> !cpu_has_vmx.
> 
> Hence add dependency from INTEL_VMX for MEM_SHARING Kconfig option.
> 
> Signed-off-by: Grygorii Strashko 

Reviewed-by: Jan Beulich 

You should have Cc-ed Tamas, for being the maintainer of mem-sharing.

> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -79,5 +79,6 @@ config MEM_PAGING
>  
>  config MEM_SHARING
>  	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
> +	depends on INTEL_VMX
>  
>  endif

Wouldn't this want accompanying by replacing the cpu_has_vmx in
mem_sharing_control() with using_vmx()? The gain in this case may not
be very high, but it would serve a doc purpose.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:41:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:41:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131050.1470278 (Exim 4.92)
	(envelope-from )
	id 1v228p-0005xz-I9; Fri, 26 Sep 2025 06:41:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131050.1470278; Fri, 26 Sep 2025 06: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 1v228p-0005xs-F2; Fri, 26 Sep 2025 06:41:15 +0000
Received: by outflank-mailman (input) for mailman id 1131050;
 Fri, 26 Sep 2025 06:41: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 1v228o-0005xh-4i
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:41:14 +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 cb5a3310-9aa3-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 08:41:13 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b3194020e86so308152966b.1
 for ; Thu, 25 Sep 2025 23: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
 a640c23a62f3a-b35446f76b4sm305704266b.64.2025.09.25.23.41.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 23: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: cb5a3310-9aa3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758868873; x=1759473673; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=imjnvPcdq+TnzWHoWy3kQ55QTfnBETriswp4UbSSVOw=;
        b=edG3qMCHXCE6jKExtzxxZPKGzSDMYkNwMw8SGRXVdZdwvJfU+cIquK16uGmFZ5c4J6
         6cp/POeoGYBym0lDbkROqB0p4GqIVV9omCCm0tx8ghTuc+InFcHi42xF4rhqhRAWvD72
         FqfHNxXWuNd390HwIg7GgGrq0OgXXrYm9/RiiIavhQnuwPxUDOVJeB2fQ/ddNrrKMrjs
         sZ/26m4bMYZRiFky9nScIkrkaEw3MVZ/x1IKL6/QjD/DXxumAGMtYqeRm5Ri0EUzus7w
         rq5I42bX933XMf8k89SkUm7Jau9YPbzw8HU7Nyz2kJEvQYdNLiAbNIIYgJx+U0CCDCg0
         L/jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758868873; x=1759473673;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=imjnvPcdq+TnzWHoWy3kQ55QTfnBETriswp4UbSSVOw=;
        b=WDz5I59KW/ZRJ5fPJ15ROfkUuqSqmAGXQMKIP5ZAGji2FgLksS4q/8RUF+4SS33DAx
         mYIC1hsyb+tTA/tRBjw+irjD1XbvsY49zsMffkFK/IHSRfR6xr0Y6Hxy7VLRLgIf3dcZ
         YT57NlywSr6vWPX1yMjG9fFzVx5HjhPuEQG/FA7hoPum8WDYZVRUIDsn1qsT/BobjkNF
         rIelgaOkyWXh0yVnDQD4IFGv9A1Qq9tWnlSuiG1VV0FdKRJw+EfoWCiz1X4qwC3mopzL
         ZIL/SOv+uzxlsI9EFu3wAtN1EVbRLc441BpH3Mhu0N+clUMejp+0IQFgGxITgQC3rAfZ
         291g==
X-Forwarded-Encrypted: i=1; AJvYcCVBFKFkFOnjHSfTN7P3rhjgadu8rlgbMZnlFI0oHEy5KJzenRe4vgjQSICo1/gZb/yw4pVdtKOyPo8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypI6e5PHUEUnmscFv1Of3Q1yw2E+L90MCWHvYawplG0oRfZnco
	BH2if4fOUCa0h9wFcGHCMqJo9NuwUHDtxIsPfOCk+iJylux9/Dvwv7QLfn+zX0ubig==
X-Gm-Gg: ASbGnctgszR5C31zX7lMaNltYWrEuZB4vP6/GjvbCZ3uLdXCKbejJ7QCaMjn/RUWp91
	lHdhLcBlX41iXVzY5n+11EMVsz7mwqCy7ebRgMMvnmtcfM0vAZ5BXVwNnj82xJP/hAhUPxklCkT
	Icc/7EZLfHVaxgCTlufsyaI3MG4Tz750BXi2YvaEVspRXPAFWV2MyHSweTrt0TuAFFVubihex6d
	tUnQ0IMviVqcQkdnImU4hlEJJN4fUUo5xpveBMKmmgul+X6eGMa44C27iQhQe9xmSbJvJ9P517R
	4X07T0T+W/OG3VirKFwPLU249LLc/BDbOX1PYdNdy3N0zmkw1e0mHaWc0TyXq/qYcCtzYObs9mo
	Pq5InhVcGcyfsjqVFG1hxtpdEBlSYAzf6+rDnO2XCh9szrE5p7owUqcw1+OpGo3icHyCShNueI9
	Paw8t71KI=
X-Google-Smtp-Source: AGHT+IFpcLiKxmjxMB4PaIYkjDteFzI1TGx+1meyKHiqpCOZ5CCWwoIP7cpLCveES4u999mEPY9z0g==
X-Received: by 2002:a17:907:86a8:b0:b0a:aa7e:a193 with SMTP id a640c23a62f3a-b34b8d7de70mr672985666b.21.1758868872588;
        Thu, 25 Sep 2025 23:41:12 -0700 (PDT)
Message-ID: 
Date: Fri, 26 Sep 2025 08:41:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] xen/flask: limit sidtable size
To: Sergiy Kibrik 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org,
 "Daniel P. Smith" 
References: <20250901105231.1570041-1-Sergiy_Kibrik@epam.com>
 
 <7b36e8fe-c19d-40eb-b1d7-d869cdfb1a28@apertussolutions.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.09.2025 08:32, Sergiy Kibrik wrote:
> 06.09.25 01:01, Daniel P. Smith:
>> On 9/2/25 05:41, Jan Beulich wrote:
>>> On 01.09.2025 12:52, Sergiy Kibrik wrote:
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>> @@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS
>>>>   
>>>>   	  If unsure, say Y.
>>>>   
>>>> +config XSM_FLASK_SIDTABLE_ORDER
>>>> +	int "Maximum number of security identifiers (base-2 exponent)" if EXPERT
>>>> +	range 4 32
>>>> +	default 32
>>> When 32 is chosen (i.e. also the default when the prompt is hidden), ...
>>>
>>>> --- a/xen/xsm/flask/ss/sidtab.c
>>>> +++ b/xen/xsm/flask/ss/sidtab.c
>>>> @@ -14,6 +14,8 @@
>>>>   #include "security.h"
>>>>   #include "sidtab.h"
>>>>   
>>>> +#define SID_LIMIT ((1UL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1)
>>> ... for Arm32 I expect either already the compiler will not like this construct,
>>> or the latest an UBSAN checker would object.
> 
> you're right, arm32 toolchain is not building this.
> Would the following be acceptable then? :
> 
> #define SID_LIMIT ((1ULL << CONFIG_XSM_FLASK_SIDTABLE_ORDER) - 1)

Personally I'd consider this an abuse of the ULL suffix. But it'll be Daniel
to judge in the end.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:43:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:43:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131069.1470287 (Exim 4.92)
	(envelope-from )
	id 1v22Ad-0006ap-Uq; Fri, 26 Sep 2025 06:43:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131069.1470287; Fri, 26 Sep 2025 06:43: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 1v22Ad-0006ai-S8; Fri, 26 Sep 2025 06:43:07 +0000
Received: by outflank-mailman (input) for mailman id 1131069;
 Fri, 26 Sep 2025 06:43: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 1v22Ac-0006ac-Lg
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:43:06 +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 0e471162-9aa4-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 08:43:05 +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 8BA523780B;
 Fri, 26 Sep 2025 06:43: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 0024F1386E;
 Fri, 26 Sep 2025 06:43:02 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id xMyoN/Y11mheVgAAD6G6ig
 (envelope-from ); Fri, 26 Sep 2025 06:43: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: 0e471162-9aa4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758868984; 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=s95gG8P6E+JOosFV8j1P+CDQDaWDLCmy7Zvv46XlY4Q=;
	b=At2l4p9rPjjCQDlPa3InSeYZ2kcNp+ZZmR89kF58IbpSITAe5CacHUVhfryr7ktZgwI3Ma
	mf3e1qm4GIFLXD7npbyOLw2SAHukBW6RGjV9ww4UBS28Yqmo+nFznLWl0YpEgVMQh9yKVa
	KOryntfR5whUSJVq9xCzw8iE8QP0+hs=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=lMhdDjyi
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758868983; 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=s95gG8P6E+JOosFV8j1P+CDQDaWDLCmy7Zvv46XlY4Q=;
	b=lMhdDjyindCEZ6OkEcXv4OX4VcYCDQoIITv0qcN7wR4pVJzOYa70wBJwoZNuYcJ8ja6Rz2
	/v4WHVX4zMDmvw2VnILRTEDLvShqCKuyQ1/ZL8x8MkgC0Mj9w99E4+4jfBYwRDl6pyX174
	l2xVXlsnscF/o7a7FsKGDSbHQT0ZbNw=
Message-ID: 
Date: Fri, 26 Sep 2025 08:43:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CHANGELOG.md: Update for 4.21 release cycle
To: Jan Beulich ,
 Oleksii Kurochko 
Cc: committers@xenproject.org,
 Community Manager ,
 xen-devel@lists.xenproject.org
References: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
 <814501c8-94e3-4930-87ed-88e7506456ed@suse.com>
 <97488f35-3f94-42b0-8443-4feacf3d587d@gmail.com>
 <68350569-4e53-4845-b3df-22ec15e4ee30@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: <68350569-4e53-4845-b3df-22ec15e4ee30@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Wqa2F5vdNx0iwsQO7dYkyecv"
X-Spamd-Result: default: False [-3.91 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	SUSPICIOUS_RECIPS(1.50)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FREEMAIL_TO(0.00)[suse.com,gmail.com];
	TO_DN_SOME(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:mid,suse.com:dkim]
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Queue-Id: 8BA523780B
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.91

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Wqa2F5vdNx0iwsQO7dYkyecv
Content-Type: multipart/mixed; boundary="------------WR8t6nSfrv6VcY6eAP63Wzdc";
 protected-headers="v1"
From: Juergen Gross 
To: Jan Beulich ,
 Oleksii Kurochko 
Cc: committers@xenproject.org,
 Community Manager ,
 xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH] CHANGELOG.md: Update for 4.21 release cycle
References: <20250924093604.17110-1-oleksii.kurochko@gmail.com>
 <814501c8-94e3-4930-87ed-88e7506456ed@suse.com>
 <97488f35-3f94-42b0-8443-4feacf3d587d@gmail.com>
 <68350569-4e53-4845-b3df-22ec15e4ee30@suse.com>
In-Reply-To: <68350569-4e53-4845-b3df-22ec15e4ee30@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=

--------------WR8t6nSfrv6VcY6eAP63Wzdc
Content-Type: multipart/mixed; boundary="------------lA3Ugdz2eb0EE437sc6RV1yr"

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

T24gMjYuMDkuMjUgMDc6NDksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNS4wOS4yMDI1
IDIyOjIyLCBPbGVrc2lpIEt1cm9jaGtvIHdyb3RlOg0KPj4gT24gOS8yNS8yNSA4OjI2IEFN
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAyNC4wOS4yMDI1IDExOjM2LCBPbGVrc2lp
IEt1cm9jaGtvIHdyb3RlOg0KPj4+PiAtLS0gYS9DSEFOR0VMT0cubWQNCj4+Pj4gKysrIGIv
Q0hBTkdFTE9HLm1kDQo+Pj4+IEBAIC0xNCw2ICsxNCw3IEBAIFRoZSBmb3JtYXQgaXMgYmFz
ZWQgb24gW0tlZXAgYSBDaGFuZ2Vsb2ddKGh0dHBzOi8va2VlcGFjaGFuZ2Vsb2cuY29tL2Vu
LzEuMC4wLykNCj4+Pj4gICAgIC0gRGViaWFuIFRyaXhpZSBhZGRlZCB0byBDSS4gIERlYmlh
biBCdWxsc2V5ZSByZXRpcmVkIGZyb20gQ0kgZm9yIFJJU0MtViBkdWUNCj4+Pj4gICAgICAg
dG8gdGhlIGJhc2VsaW5lIGNoYW5nZS4NCj4+Pj4gICAgIC0gTGludXggYmFzZWQgZGV2aWNl
IG1vZGVsIHN0dWJkb21haW5zIGFyZSBub3cgZnVsbHkgc3VwcG9ydGVkLg0KPj4+PiArIC0g
UmVtb3ZlIGxpYnhlbmN0cmwgdXNhZ2UgZnJvbSB4ZW5zdG9yZWQuDQo+Pj4+ICAgIA0KPj4+
PiAgICAgLSBPbiB4ODY6DQo+Pj4+ICAgICAgIC0gUmVzdHJpY3QgdGhlIGNhY2hlIGZsdXNo
aW5nIGRvbmUgYXMgYSByZXN1bHQgb2YgZ3Vlc3QgcGh5c2ljYWwgbWVtb3J5IG1hcA0KPj4+
PiBAQCAtMjEsNiArMjIsNyBAQCBUaGUgZm9ybWF0IGlzIGJhc2VkIG9uIFtLZWVwIGEgQ2hh
bmdlbG9nXShodHRwczovL2tlZXBhY2hhbmdlbG9nLmNvbS9lbi8xLjAuMC8pDQo+Pj4+ICAg
ICAgIC0gQWxsb3cgY29udHJvbGxpbmcgdGhlIE1UUlIgY2FjaGUgYXR0cmlidXRlIG9mIHRo
ZSBYZW4gcGxhdGZvcm0gUENJIGRldmljZQ0KPj4+PiAgICAgICAgIEJBUiBmb3IgSFZNIGd1
ZXN0cywgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZSBvZiBndWVzdHMgdXNpbmcgaXQgdG8gbWFw
IHRoZQ0KPj4+PiAgICAgICAgIGdyYW50IHRhYmxlIG9yIGZvcmVpZ24gbWVtb3J5Lg0KPj4+
PiArICAgLSBBbGxvdyB0byB1bmZsYXR0ZW4gRFRzLg0KPj4+IFdoYXQgaXMgdGhpcyBhYm91
dD8gVGhlcmUgY29udGludWVzIHRvIGJlIG5vIHVzZSBvZiBEVCBvbiB4ODYsIHNvIHdpdGhv
dXQgY29udGV4dA0KPj4+IHRoaXMgZmVlbHMgcHJldHR5IG11Y2ggbWVhbmluZ2xlc3MgdG8g
bWUuDQo+Pg0KPj4gSSBhbSByZWZlcnJpbmcgdG9odHRwczovL2xvcmUua2VybmVsLm9yZy94
ZW4tZGV2ZWwvMjAyNTA3MjIwMDA1MjUuNzI0Ny0xLWFsZWphbmRyby5nYXJjaWF2YWxsZWpv
QGFtZC5jb20vLg0KPiANCj4gU3VyZSwgYnV0IHdoYXQgcHJhY3RpY2FsIHVzZSBkb2VzIHRo
aXMgaGF2ZSBmb3IgYW55b25lIHVzaW5nIFhlbj8NCj4gDQo+Pj4+IEBAIC0zNiwxMSArMzgs
MjAgQEAgVGhlIGZvcm1hdCBpcyBiYXNlZCBvbiBbS2VlcCBhIENoYW5nZWxvZ10oaHR0cHM6
Ly9rZWVwYWNoYW5nZWxvZy5jb20vZW4vMS4wLjAvKQ0KPj4+PiAgICAgICAtIFN1cHBvcnQg
aW4gaHZtbG9hZGVyIGZvciBuZXcgU01CSU9TIHRhYmxlczogNyAoQ2FjaGUgSW5mbyksIDgg
KFBvcnQNCj4+Pj4gICAgICAgICBDb25uZWN0b3IpLCA5IChTeXN0ZW0gU2xvdHMpLCAyNiAo
Vm9sdGFnZSBQcm9iZSksIDI3IChDb29saW5nIERldmljZSksDQo+Pj4+ICAgICAgICAgYW5k
IDI4IChUZW1wZXJhdHVyZSBQcm9iZSkuDQo+Pj4+ICsgICAtIEJhc2ljIGtleGVjIHN1cHBv
cnQgdG8gTWluaS1PUyBmb3IgcnVubmluZyBpbiBQVkggbW9kZS4NCj4+PiBIbW0sIE1pbmlP
UyBpc24ndCBhbiBpbnRlZ3JhbCBwYXJ0IG9mIGEgWGVuIHJlbGVhc2UsIHNvIEkgd29uZGVy
IGlmIHN1Y2ggcmVhbGx5DQo+Pj4gYmVsb25ncyBoZXJlLiBZZXMsIEkgYWxzbyB1bmRlcnN0
YW5kIHRoYXQgdGhlcmUncyBub3QgcmVhbGx5IGFueXdoZXJlIGVsc2UgdG8NCj4+PiBwdXQg
c3VjaC4NCj4+DQo+PiBJIGRlY2lkZWQgdG8gcHV0IGl0IGhlcmUgc2luY2Ugd2UgaW5jbHVk
ZSBpbmZvcm1hdGlvbiBhYm91dCBzdHViZG9tcyBpbnxDSEFOR0VMT0cubWR8LA0KPj4gYW5k
IE1pbmlPUyBpcyByZWxhdGVkIHRvIHRoYXQuDQo+IA0KPiBTdHViZG9tIGNvZGUgaXMgcGFy
dCBvZiB0aGUgZ2l0IHJlcG8gYW5kIGhlbmNlIHRoZSB0YXJiYWxsLiBNaW5pT1MgaXNuJ3Qu
DQoNClJpZ2h0LiBUaGUga2V4ZWMgc3VwcG9ydCBpbiBNaW5pLU9TIHdhcyBwcmltYXJpbHkg
YWRkZWQgaW4gb3JkZXIgdG8gc3VwcG9ydA0KUFZIIHhlbnN0b3JlLXN0dWJkb20gbGl2ZSB1
cGRhdGUuIFRoaXMgaGFzIGFscmVhZHkgYmVlbiBhZGRlZCB0byB0aGUgY2hhbmdlbG9nLA0K
c28gdGhlcmUgaXMgbm8gcmVhbCByZWFzb24gdG8gbWVudGlvbiB0aGUgTWluaS1PUyBjaGFu
Z2UgaGVyZSBhcyB3ZWxsLg0KDQoNCkp1ZXJnZW4NCg==
--------------lA3Ugdz2eb0EE437sc6RV1yr
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-----

--------------lA3Ugdz2eb0EE437sc6RV1yr--

--------------WR8t6nSfrv6VcY6eAP63Wzdc--

--------------Wqa2F5vdNx0iwsQO7dYkyecv
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/Ey8FAmjWNfYFAwAAAAAACgkQsN6d1ii/Ey+w
jwf+IFnnvyqZkZsnchbRiNzXP58VuBQhgB0S2WmEsXXD0CGEDabs1lFxRoa1MZVNNC1z/bix2AZy
swEnJVo5o8gGpPyoEW44Dv3M2mGuybCB/tpQvQdfqRJPOFu/jlMYb0AgMknLx5BfV4Fv7ClsQnTy
zXUNgFJBlVTOVQVrZcGCfIHwj+zFbb4/hju4EIEMmzkOAVc5PD0ZsHrvyhyDlWodf8QVDAr6jPbH
UDmNEZtnFX8OeL4qQ5/cph5oPN3DL7pMmLmo3Ap/eloaCMTCO53WidAX5azg519pV4YyATKmTdOk
sZx8w2lbgPGGnTvqjFKye9surb8nkxBR3agQPU6ClA==
=4+Vu
-----END PGP SIGNATURE-----

--------------Wqa2F5vdNx0iwsQO7dYkyecv--


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:47:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:47:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131081.1470298 (Exim 4.92)
	(envelope-from )
	id 1v22EM-0007Ei-CW; Fri, 26 Sep 2025 06:46:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131081.1470298; Fri, 26 Sep 2025 06:46: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 1v22EM-0007Eb-93; Fri, 26 Sep 2025 06:46:58 +0000
Received: by outflank-mailman (input) for mailman id 1131081;
 Fri, 26 Sep 2025 06:46: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 1v22EL-0007ET-2t
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:46:57 +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 97ae0b64-9aa4-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 08:46:56 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-62fc2d92d34so3135402a12.2
 for ; Thu, 25 Sep 2025 23:46:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b35446f79besm308240266b.69.2025.09.25.23.46.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 23:46: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: 97ae0b64-9aa4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758869215; x=1759474015; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/0QTzDwEw+SBDEP5K1nabRP6P6t/vMtgLq8U1uG7AYk=;
        b=T5V4UT9MbuQLEgQrfYFooRU98uh+6aQCFqqyktEI4J40InMCu15Tw40afQz7zeqCM1
         xDtmvzOea3Q1kLcwIh0kBFely9wT/JUm2+kZ0a0HObpjn7BqOW2kNAWlF1JHQgvOrOyo
         l5Yz7kIEPpctjyk2Vxs53Jsrejj9HYUs8dxLZsWF8jRELW/PoZ/Lb3mpTbKEYWLAt+p5
         rj+Q/phQLQeQnygTlCsrKqYRp1nTo9DgWhl6RPQ9YIGu+fOjIo0hAXX1UaYnA1d6nJAG
         FxjzWglwcOVnc3lCpBze4VJai4dmuORi8Lt5T/75L3NkRMNImHsFOpPRh33vt2LxTiyN
         Dipg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758869215; x=1759474015;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/0QTzDwEw+SBDEP5K1nabRP6P6t/vMtgLq8U1uG7AYk=;
        b=NjtVwTmNMg274wFw1vw7LrqF7NS7Oexe1EXHEcnU8CXzNn/C1tfG6WgCC0qAbhDZSB
         s66YUvi8wgR3mmccFcOH/slj7BvnKYwRUL7XdIOIKbj+Nd4sa4YMP1oo0udNPTTXvYhf
         2C/ctrR+WrU8uqL3qA5+Bts/A9u8RFS6HejKaSSNRDQ5SuM5yq0j5GcUjBXm6b6Xc/Y5
         OPnUi3fSpXQszPdDyVIZWOh+vm+q18jRaisdcfUDnXlkgtcL7ODY6f0AK+vIxrMJe6MU
         RVZptOmSox5qx0BXmSIb1//W6ftvDWr5apa+tbH2DMRGRzXD/QbDQ10zf0COeBtmViJT
         6jHg==
X-Forwarded-Encrypted: i=1; AJvYcCXBZ2/uX8w0ybDrt1Y4lS7T+CXGY7mObOzKt4iSP+rIFGgtB8S6Pz3Ql5nFKSn0E6enooE4dkFp6kc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2y/cT8r4S++MdhYbNYXBl49JBlKqHvdnCBxItFp7MPzWozMxM
	I3d83slCVJ+0bKE8RUdni+XTeyOW4h+ZTsguAQefziRu+I/rNUFiNwcwFTmCTrXExw==
X-Gm-Gg: ASbGnctjdBB4aZsMTFEE3s+yLRTb36Ko8b6o0DMsxEdxAN91vgFHmmYMPX7+8Y08ugg
	NGvHVMfLp8lF7MOdPMlVVH/NzacCnW+klMkYUSwEY/QDYfV6MEchC/wN+Ucan9m20cajIK8AnLr
	Jq4WblW/1MhU1NfQtfVKsURzRiJ5HrGV/VMrm5kSe0nyXN4aW9/z0Fowb5Xr83Qb1SUfH77L1RA
	zNbNMtnRjxZybtPTydMD6QdfwqyBWZwT+6JrW5ZcURoFwl4N8huRfbc9k3ORNUqyaBHac61Qmw6
	AcKO2ghcaXDYtqr70uc+SiPa/eno2Q27cF3iiVgdnerec3XxD5eUMQRdq6lYbN4Nrxh1kwdJbS3
	3SIxrVT/If8LN14gSO0pz2tI4XpoVIRwwBWDIKvJQ7zt6lJdadBD2kZzjE6n2aRwFMLcEqe6v+X
	wqhLkr2nU=
X-Google-Smtp-Source: AGHT+IFnrsQvRnNcb3k/xSEObDzxEt7O4Gca9AEOoa54u/4818ahjOwryXalAzt92wD+zaBG6ebWTQ==
X-Received: by 2002:a17:906:4fcd:b0:b2c:dc13:89e4 with SMTP id a640c23a62f3a-b34ba147a90mr687172966b.9.1758869215383;
        Thu, 25 Sep 2025 23:46:55 -0700 (PDT)
Message-ID: 
Date: Fri, 26 Sep 2025 08:46:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: consider conversion from UL or (void*) to
 function pointer as safe
To: Dmytro Prokopchuk1 
Cc: Nicola Vetrini ,
 Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , 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 25.09.2025 20:37, Dmytro Prokopchuk1 wrote:
> On 9/25/25 16:25, Jan Beulich wrote:
>> On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>>>        - Tagged as `safe` for ECLAIR.
>>>   
>>>      * - R11.1
>>> -     - The conversion from a function pointer to unsigned long or (void \*) does
>>> +     - The conversion from a function pointer to unsigned long or '(void *)' does
>>>          not lose any information, provided that the target type has enough bits
>>>          to store it.
>>>        - Tagged as `safe` for ECLAIR.
>>>   
>>> +   * - R11.1
>>> +     - The conversion from unsigned long or '(void *)' to a function pointer is
>>> +       safe because it relies on both ABI definitions and compiler implementations
>>> +       supported by Xen which define consistent and compatible representations
>>> +       (i.e., having the same size and memory layout) for '(void *)', unsigned
>>> +       long, and function pointers, enabling safe conversions between these types
>>> +       without data loss or corruption. The compile-time assertions (BUILD_BUG_ON
>>> +       macro) is integrated into 'xen/common/version.c' to confirm conversions
>>> +       compatibility across all target platforms.
>>
>> As you use (and mean) plural, s/is/are/ ? I also think the "The" at the start
>> of the sentence wants dropping.
> Ok.
> 
>>
>> Further, why this very dissimilar wording compared to what's said about
>> conversions _from_ function pointer types?
> Do you mean the following wording should be placed instead (to be 
> similar with previous one)?
> 
> "Conversions from unsigned long or (void *) to a function pointer do not 
> lose any information, provided that the source type has enough bits to 
> restore it."
> 
> And wording about "ABI, compiler..." should be only in commit message?

Perhaps.

>> And then ...
>>
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>>>   #endif /* CONFIG_X86 */
>>>   }
>>>   #endif /* BUILD_ID */
>>> +
>>> +static void __init __maybe_unused build_assertions(void)
>>> +{
>>> +    /*
>>> +     * To confirm conversion compatibility between unsigned long, (void *)
>>> +     * and function pointers for all supported architectures.
>>> +     */
>>> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>>> +}
>>
>> ... I'm unconvinced checking merely the sizes is sufficient. On architectures
>> involving function descriptors (e.g. ia64) converting in this direction is
>> safe only if earlier on the value was obtained as the result of a conversion
>> in the opposite direction (and all of this within a single component, which
>> of course is guaranteed for Xen).
> As I know mainline Xen doesn't support IA-64 currently (this support was 
> dropped).
> Why we still need to mention about IA-64 here?

Because I needed to use an example I know. Aiui there are other architectures
which use function descriptors (or alike).

> Anyway...
> Yes, this deviation wouldn't work with architectures where the 
> representation of a function involves more than just its address (e.g. 
> IA-64). If not proved that such conversion is symmetric.
> 
> Probably, additional guard may be added below to exclude such 
> architectures (e.g. IA-64):
> 
> static void __init __maybe_unused build_assertions(void)
> {
> #if defined (__IA64__) || defined (__ia64__)
> #error "Conversions to function pointer isn't safe -  architecture uses 
> function descriptors."
> #endif

Well, no, I didn't mean to ask that you add dead code.

>      BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>      BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
> }
> 
> But if someone really will try to run Xen on such platform, the build 
> will fail.
> 
> Or just mention explicitly that other architectures (e.g., IA-64) might 
> not be safe for such conversions?

My main point really is that once again I wonder how convincing such an
argument would be to assessors, when it's clearly not generic (yet being
worded and the checking coded as if it was).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:53:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131094.1470307 (Exim 4.92)
	(envelope-from )
	id 1v22Kh-0000O0-Vm; Fri, 26 Sep 2025 06:53:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131094.1470307; Fri, 26 Sep 2025 06: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 1v22Kh-0000Nt-T8; Fri, 26 Sep 2025 06:53:31 +0000
Received: by outflank-mailman (input) for mailman id 1131094;
 Fri, 26 Sep 2025 06: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 1v22Kg-0000Nn-Lp
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:53:30 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8234ea77-9aa5-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 08:53:29 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-b3164978f11so326408266b.3
 for ; Thu, 25 Sep 2025 23: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
 a640c23a62f3a-b3545899fc9sm306151766b.91.2025.09.25.23.53.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 25 Sep 2025 23: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: 8234ea77-9aa5-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758869609; x=1759474409; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pOJA2bSz0c3Nk1Psq18q/DfKHEnHmwSaoMrIRG8ZQTA=;
        b=XWQwzU6sJdq+GFo6yY3OXGOc4YKYJluMgBw6VXDLY7qnIH9cv/6kPmlo7LgbYFkoE0
         5ShOp3J0kWigw0RWcTPNGdUwT8DRHob7UH232gNuh7OzjVJ8iLImkKN2V+S/sEtcQdv1
         QsCcD/gXUpwlChjvp20sSmp/Hy20dZ77greD6Lu4C0hQ8x4tT8yMvc+DL00v6BumavDq
         mRO4TRsFLKAHYNSOPsG56Lo1KwQLr+7ExSfzS7REzgjNkVXapa2s7iKrlu55xjmF8Ref
         hdB6Dx+vfRM7F41pIGrky5ILsUpHn+ctXl7LPe/XWodnpOKW7nhC0syyy0gtuiSaDEsG
         o5EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758869609; x=1759474409;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pOJA2bSz0c3Nk1Psq18q/DfKHEnHmwSaoMrIRG8ZQTA=;
        b=p66wZn8hEi88WzlaYknzc4UtUCBjlwME0SmXVs6aFfDATw2C0Wk1YfRSogIesnS5Ls
         6Q5e8+GX4iq0edMYnRwpCBR2IXXElYkmkgN5QtGv/4M25k39zhl6MNbbwuXCXz47kKPo
         fcw8CuCI2v25fG/yKEcj+nM/4EI7qyEKbqhxORDqN1xVdp00O/Jnj5CNRI8xm38XBXRH
         4PMAbqVD5Ywh1KODdQfzhZmof0B1cxk2ftjbMuj8S/XpXfvRpBMTXFhGWrdFkVxLzeL2
         dx19q8LUD97ewPaQJjiEU6AL6Pt8wFJWhZlOsdhAKWhfz6z0WVTTY2F4gtEkCwD7+ENJ
         +ygQ==
X-Forwarded-Encrypted: i=1; AJvYcCXseoomQ9FnZuOhLjVO5pQtmPkfEc7GoUE6QSqkysKXwYfN0NjPct1BX7qPax8mEfReTqvxjuUzL5A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz969qm3J7Je20L7vJ69Vs6ObkPrWRpEyUeuifLxXiHQRwht+9F
	eCZFftM813KU+lPkZgNaenB1V90dd9eEfO4dkh/6/MQoMX/OL1Hpndrvs/Jzjg4xVA==
X-Gm-Gg: ASbGncv3YPNXy588x6Sh7rtMRPtcF0vu/Xw9vz6m4DqJRHYvlwVkp4ZVk3RHBuaT8WE
	r8P+Bm9lHY4YFbcsJcsejq1SzN25/D6WmLD9AEtpRCqBhbQOhd869L5QrtYSa3Lnm4BmU7B5GfM
	G/p1TZXNRWf8So0ITyLzjENCHHGYn+QFKaXu8r3zk8d9F2ftxQ18Aq+uR4HT/snN/6LnJxTDLrP
	dTG2mOPQYzN4IRP8C19fcvSi62r2qyZdalWcNUzLHXctIPm1NvXb6kuW5z6k5adaS5/y08V5oja
	UUnmzBrjuweJ2Jv4BVRtTxSRILd9ZPeHYAE3NaWE8UPOALeVOjYl2u2M+i9BZdciqv91ae0RXTZ
	uDe3+tJ2i7JJh73f0aH/BW6Sw06Rp4cCCc/Ax5l6QAOx4fOjmmbqdBWyapg5Z7Qz9eFzmhSzAsb
	vWj+Y/2wCGM1KhVbMwIg==
X-Google-Smtp-Source: AGHT+IEpe2eeEYthqrXrv+qkhH313rrXvNKrKGULeFXh/zx6k6qWWwasHjRZI5WTyLP1oWcDK9QEhQ==
X-Received: by 2002:a17:907:6092:b0:afe:ea46:e808 with SMTP id a640c23a62f3a-b34baf43ad8mr624040966b.47.1758869608819;
        Thu, 25 Sep 2025 23:53:28 -0700 (PDT)
Message-ID: 
Date: Fri, 26 Sep 2025 08:53:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" ,
 "Stabellini, Stefano" ,
 "Andryuk, Jason" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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.09.2025 06:41, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, September 25, 2025 10:29 PM
>>
>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>
>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>> --- a/xen/include/xsm/xsm.h
>>>>> +++ b/xen/include/xsm/xsm.h
>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>      void (*security_domaininfo)(struct domain *d,
>>>>>                                  struct xen_domctl_getdomaininfo *info);
>>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>> -    int (*getdomaininfo)(struct domain *d);
>>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
>>>>> +    int (*getdomaininfo)(struct domain *d);
>>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>      int (*sysctl_scheduler_op)(int op);
>>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
>>>>> -234,7
>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>
>>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>> domain
>>>>> *d)  {
>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
>>>>> +#else
>>>>> +    return -EOPNOTSUPP;
>>>>> +#endif
>>>>>  }
>>>>
>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl
>>>> is hence already broken with the earlier series. Now the domctl is
>>>> also being screwed up. I don't think MGMT_HYPERCALLS really ought to
>>>> extend to any operations available to other than the core toolstack.
>>>> That's the Xenstore ones here, but also the ones used by qemu (whether run in
>> Dom0 or a stubdom).
>>>
>>> Maybe not only limited to the core toolstack. In dom0less/hyperlaunched
>> scenarios, hypercalls are strictly limited. QEMU is also limited to pvh machine type
>> and with very restricted functionality(, only acting as a few virtio-pci devices
>> backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly and
>> thoroughly about our scenario here for upstream?
>>> Tracking the codes, if Xenstore is created as a stub domain, it requires
>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found how it was
>> called in QEMU...
>>
>> It's not "it"; it's different ones. First and foremost I was thinking of
>>  * XEN_DOMCTL_ioport_mapping
>>  * XEN_DOMCTL_memory_mapping
>>  * XEN_DOMCTL_bind_pt_irq
>>  * XEN_DOMCTL_unbind_pt_irq
>> but there may be others (albeit per the dummy xsm_domctl() this is the full set). As
>> a general criteria, anything using XSM_DM_PRIV checking can in principle be
>> called by qemu.
>>
> 
> Understood.
> I assume that they are all for device passthrough. We are not accepting device passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has developed device passthrough through device tree to only accept "static configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still internal , it may be the only accept way to do device passthrough in dom0less/hyperlaunch-ed scenario.

Right, but no matter what your goals, the upstream contributions need to be self-
consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving them
may be an option here.)

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 06:57:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 06:57:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131110.1470317 (Exim 4.92)
	(envelope-from )
	id 1v22Ol-0001DU-Ig; Fri, 26 Sep 2025 06:57:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131110.1470317; Fri, 26 Sep 2025 06:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v22Ol-0001DN-FS; Fri, 26 Sep 2025 06:57:43 +0000
Received: by outflank-mailman (input) for mailman id 1131110;
 Fri, 26 Sep 2025 06:57: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 1v22Oj-0001DH-S5
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 06:57:42 +0000
Received: from MW6PR02CU001.outbound.protection.outlook.com
 (mail-westus2azlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c007::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 145c2491-9aa6-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 08:57:35 +0200 (CEST)
Received: from IA1PR12MB8467.namprd12.prod.outlook.com (2603:10b6:208:448::9)
 by MW6PR12MB8950.namprd12.prod.outlook.com (2603:10b6:303:24a::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Fri, 26 Sep
 2025 06:57:31 +0000
Received: from IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e]) by IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e%6]) with mapi id 15.20.9160.008; Fri, 26 Sep 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: 145c2491-9aa6-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HmrTGq3Y7t8H8tYEs/Y/05HwEBoDwNM4eFj5LitfHikIBtR8Y0/jT+TE8JLOd6A3YW3igzelDjrcjMbDSEF6H3SBP1yvw8593KUudR2jARaGh0NLip9RcOhEwFO7yatLUmDCHZB8tnS3OWW+IZShmB9CIH5jEu9kuqxU3sBMVhPOj+HkVwt4Sf3XTNY5z8ifNxGaT9ae4HofVqZCI6HdGNqzTwh94nMZ90xGry6NO2QWtPxlY/IfhRXC1lWpwA1NVHpP7jQjX8o+s3hKdZu5xilJSsD3wnCGNPto3KkQ8/4Qap9j5zvpkobul5zNGE1jxDvTPNVNwWE2oM2ppHGXzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UsWE8zRfk+e3Px7//gF/wZR5IUFDweX/byn1Tiau7Vg=;
 b=Z9TYKzp2kALYMF8Kyi/bVRPYjGPEFJAIF5eiDXjQPLkpW8isELVQpKt4fyzV5x69N1Hp8XNVtfaGA0ZkvUuwNcoBAguKovMWoTZ8yS40smFwtOPPjx0TXrjFGa1nNDUJZ3kuwfNAPb5GT4VNCKHYI2UsvImN1ZmN2jMW2JWoRGAoCxu11rIr3SyIAPTIYA/ZcnSpbskueR8YLbKnI7BTELFOuLtsZuU74k5Sn2UsP5eZVL51CkeTD6MW02tDkvnDz75ggozWufy+lKrFM4ufAcTZurGwIO4BA5cuh6vBkcHYo22KrQl9eOcQnMRCygtHlNnYt+WYYFDaBaC5nsmuQQ==
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=UsWE8zRfk+e3Px7//gF/wZR5IUFDweX/byn1Tiau7Vg=;
 b=hj0YLlLp+uhur3wxTQTINmDp7G1+Rr5V+52CyLj60femvteGMIcuhVWydsNnQf4W9//XUeeFNt4/vuJgZpGlEw1Bmdzlv/qiP95D1+SBMPb7h1+ztwWW/VnDa/Pc6lM9SjlaE07Kzt/vjG9VCoPdJieiR9U3OS/yGQWSOgsLE38=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	, "Stabellini, Stefano"
	, "Andryuk, Jason" 
Subject: RE: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Index:
 AQHcIiYYEaVyPVCsmkah0K573htVM7SN/BaAgBWuJICAAGLSAIAA6DCQgAAq/ICAAADyQA==
Date: Fri, 26 Sep 2025 06:57:31 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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-09-26T06:57:24.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: IA1PR12MB8467:EE_|MW6PR12MB8950:EE_
x-ms-office365-filtering-correlation-id: 84631df8-3a75-44be-e5b7-08ddfcc9f69c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?WnlrZXlQOVlQVzhRV28ydGZjNVhSVVUrbG1kc3RHSWs3YTh5VWUwOXBZODBo?=
 =?utf-8?B?WjRFUVhjc0h1VGNSSFJVOEdQUjlRSHlwZTBCSklwZlFhblBDU2tIZnJ4Szds?=
 =?utf-8?B?WWZkTWxxNENyZDVIaDVhdW1Lc2dGSlhiVE91cVZjVmc4YlJHMjZBM1VUOUhm?=
 =?utf-8?B?UG9rMUJFWDJjaGVEY1p6K0UxSUV0ak1BN0pOcGdOU3JhMnpaeFdpa21FT05R?=
 =?utf-8?B?UDYyYzV1ZjI2ZDNuMkd5STNDeVJHNi9vK1A5S2pmVW1hbjQ2azBmMzg0K2pk?=
 =?utf-8?B?UEhneUtTWGtwNGNkQjEzSHE3VVZJS2dvNElEcXJBWjFwSjZ2cDI4clQwYWtn?=
 =?utf-8?B?Tlp3MkdtUVlHUnMzU1Uydk1qeXpOL0x2aTFnajFoRVZIMVFCSmZPUlM5Nlh6?=
 =?utf-8?B?dVRCK2pLbXFaTzJ5Vm5XanRXR1FuYk1XTldZdWF6WEFwSXZaSTg0LytQUzFz?=
 =?utf-8?B?R0pocXdzSW9VWUpObWlEUFVUNnp3MkJRYXYzSE13ak0vUVFEam52ZGttdW0w?=
 =?utf-8?B?RmZiMGhBMlM4am81a3BoZE1FMGNqYXNLNDg2QTdVK3BRTjFzbFVrcFh5aVJr?=
 =?utf-8?B?VXRGY2RMTk5iZC8yNjJQck82TXJoZzk2WmtnWTJObDRzUkU1ak1KL3FFem1L?=
 =?utf-8?B?b09NQ0tUQjZOd0Z5SFVIbjdyRkdZVmQ4TDNKZEh4ZjNkL0hBSGxxaW4rUURx?=
 =?utf-8?B?bFNuTEU4RlZieUhiU2pKNlV4NkhTZkRaOXVjS0lGaEFXM2FRYURBdFAwSzE2?=
 =?utf-8?B?Rm5NQ3RneXRVbVFONU94c2hzWWRjckpoOFBqSlRvc3dmU1laamZweDFhdHp5?=
 =?utf-8?B?aXFrckUybTdwc2RqbmRDYitCSWV1RjdKNnQxZTJKQnRONmlwaWJsNHBCanNY?=
 =?utf-8?B?NXV5Uml0bzI2blhrK2p5elN1bUpySEUxSnBPRlR4R2dwWVpnUTBucm1DT1V6?=
 =?utf-8?B?anJpb1pic1pkWnRGWDl5Y1hzcmZiWUV1UGwzZ01VNTU4bUJnemp4ODI0Z1Ry?=
 =?utf-8?B?dGYrL2hPZ3F5QjdKLzhla0d2V3R3SncxMnZvVEJpNlhiNjlOQ1RxclN1LzlT?=
 =?utf-8?B?N2FPYVZMc3gyVEIwNlVXZjJ6d1JtSzNSU0tQZFRKSFZreXc1M2JBS2k0RGhY?=
 =?utf-8?B?L0owQ01KK292aUtGbFkycVdQQ1RNYUs4OUZDdWE3NnZ4NW5PZUIyTHc1NFkw?=
 =?utf-8?B?VldSc3o5Q3M2QzJsMTlreUVnL2JVeU5DU1d2WVZXRTJJNWxyRklXWDRHUlVu?=
 =?utf-8?B?WUpIQ1hmN1B1RWk3NHhldmZ1aE00RGw1d3VVMS9Lbk5kcmo1ZjIxZms3U25p?=
 =?utf-8?B?Q284Z0tzUmlyejNPcEhSOG9DOEZ2eDJJc0xOZCs5VWh1VVlUK0pTMzRIaVp4?=
 =?utf-8?B?cHZxRGpMSFYwZ0xqWmZnUml2VnFFZm9rVU5jajRNUjVmUDRBRzBwTE55S1cv?=
 =?utf-8?B?TWF3ZHhMajFheDI0ektWNUxEbXEwZFY4SEZLbUhTTjZibnBSWUZwK1pMNXFi?=
 =?utf-8?B?VXVhWGc5NjJXd3dtR05WUmhVYmVLVER4STluTWRaeURoM1RtZVNWYWx2ckUr?=
 =?utf-8?B?QkNrWnNsbzQ3bU9oQ3IvalhaMEhhY3Z1Sks3b0lhTG5wditQblZJS0s5MURG?=
 =?utf-8?B?WUdmcGVTMTlOeTJwMUllMGhPeXUybDZhZ2YrK09iZ2dwUDN6WnBvTXgxUXBz?=
 =?utf-8?B?SVhoSnU2ZHY2RmRzc0FUMWtHdUdTM1RvcnlhS0NZaGpUUTJ4aGlwcGNLMnV4?=
 =?utf-8?B?L052eWtTSmpSQ3lqTTdCTDhTaXRHbmRQdmh5WWpnNlhZQ0pFQlRqR0xMc282?=
 =?utf-8?B?SkRnRGxrVnRXcDdONHpUV3hBaDBSaWlHU0hYZVdqWGkrblFUb3RvN1V4Rm5R?=
 =?utf-8?B?dlFic0VRcFJCckZiSnlNYk5qZnhKblMzOTJNS3FsRjhLVXQxYTgwNEw3elpO?=
 =?utf-8?B?VHhlUFdmTFNTaUNmZXlleGRKQTlQRnUzVFdJSVBaSzdoa1NicXJIV09jVjdK?=
 =?utf-8?B?amFqU21BTVdJOTAxK3RFQUNHQ3R1eVJ5QzZWaGg3UWdjdm9PZExPMXV0L1k5?=
 =?utf-8?Q?z9e+Fl?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB8467.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WmQrRFArbkJuQXQyUndhV2hXU0xZc1RLVThpNktsRkZmQkVDVm1qYldwanFn?=
 =?utf-8?B?QVpTTFR3MEt0OUlESlEzQ21uMnJNTmtiT3p0cGxTMW5kOFVYbXd4TnlaaGdW?=
 =?utf-8?B?TlBDZkF3TEQ0V1c1YU9kbFJjdWhsVWpWdmUxNWIrZ1N1SEhGMzkraVYxMXR5?=
 =?utf-8?B?bzhIWkxML3NQUzVIYUprMlU1SS9xQjJCcnZLekduSTZ5aHFtZEUyNVh6a1E3?=
 =?utf-8?B?MTVmZXpVdE9hbmhOWWpTNDlNMHFPRStwVUZycnRIYXhLTHNaSUdsckNKSVln?=
 =?utf-8?B?S1BKaUZCR29EZ2VyUFNqUVNuM3ZGYlFHRW50SHllMG04UlA5NjZDN0ZONmtn?=
 =?utf-8?B?amEybk9WclJETlBDUmYwSWdaTGlXWS9hSm5BV0d0UzZ6YjNMZk1hYWRycGNn?=
 =?utf-8?B?U0ZhWGtOWjEvTS9IN25lSlJyU3gwdlJvSHVpM2RBRW5OTVVrVnpJczZSRkhx?=
 =?utf-8?B?NVlXVUVZUVE1USs1ZERoV0ZRUGNDSlZMMmQ0aDdidVNPUXliM3dUTm5vUkhr?=
 =?utf-8?B?VTN2bERDSitUTzVwNHhjRmdNVmR5eC9ETlJTQWlab0JjZ0JUeTl2ZXJYaGtE?=
 =?utf-8?B?ZmxrNGI3VDdCTVlVL2Y3WW5NRXpjYWxCRzRGSGNESys1YmJOdHNURnJjNUpt?=
 =?utf-8?B?QTBQRUZUUjZHeVY0blpOZ2t5MjJ2Y1hmRk9jN3BoaWRmdlRBV2NFQUxkUE0x?=
 =?utf-8?B?L2xhUVBCU3hsajIyNm1aT0hHcUtpVDJINmpKVERId01oU3hoK3FsTHEzQnVh?=
 =?utf-8?B?TWFybHVjYWNFTzludlNRaUcrMUlsVVZoWHFTZTIwVDBtcjNUMXg1NGxZN2dR?=
 =?utf-8?B?TWRJb2x6a1NsK1h1MGJ0MG1FL2toRERjeU9MU0lEcUxoUnpWTWx1S0NSL3BI?=
 =?utf-8?B?ZjBWV2dhSWxncFlqdngrajUxMFVEQkZHajhVRTN4Q1Vtc1hMRXZHc0dSb1Ew?=
 =?utf-8?B?RXJjeXo1dGhGMWpheEpWcTBZazdNN0Rzd0QrTlNoT1VDc1BXb3p5dWYrQjF1?=
 =?utf-8?B?RWY4Rldqalo1bjRzTmJUdzBsRUdNaktraFpnVCtEVmhHNDF5NkdNRGVxajJX?=
 =?utf-8?B?NUNLNlZXeUJOVUY2cVo4aDRsOWlzN2FLaWRSaU00ajhjbW84QTVreHljN0I3?=
 =?utf-8?B?amk0eGNlODE4aWprNjNJY2gxL1NmRGoxMWpGeEhqZzNzeUhvNWNDaWpyNnp5?=
 =?utf-8?B?Q0dLQm1TZjVlQWQrME9FaFh3dDE5dnBScEsxeko5TG5oVnB3b2tqd01tNW50?=
 =?utf-8?B?NVVJNFJmUUc2bTJOQjBMRXJaUGxrUVFFVHFEbXFENFljUzh6MEFlZjRuOGtF?=
 =?utf-8?B?N1R4U3JNalFmNEhNaFZWQkJSd3pha0VhOXpPQ09JNXZDVkVsZ0orcFI4Mlp5?=
 =?utf-8?B?U1dla3NJc2MxcDVzdUU2V3J3WVpPTitiZFQra2EwTWxTRkY5R1hHL1BWK2ZP?=
 =?utf-8?B?Q1hEQUhlTTcwNDRlMUJYS1JvREhiMkxjM3VJNit1TTlYZmlnTm1OSHhHRmJh?=
 =?utf-8?B?REdHQ3JvcUJtb01FQVJxVWM2TFhlMG9TWHVKbGRVWDJHYlJmTlUvcFFtMmg1?=
 =?utf-8?B?dURCUXQ2aTltKzJzN21vbXhxYWFDOXJoWTlkQXRlWnRWNUUxSy9yTHFQcE1V?=
 =?utf-8?B?Y1B4VUhCbStDaXFSOUpaWUhwc0ZObGQvK1ZJL2JEb1VQbVI5VFliVitFRkdN?=
 =?utf-8?B?R0VaekRWZUhGMTBNL01rZi9tdWxpa3o2VzE0dmdqTkEwWi9OTTlJc0ZZR0ZZ?=
 =?utf-8?B?djdiM1RFWGRMYW9ISDkrZWh0MFFNT1Z2MEZFcGlxRFJMVUZuNE83cHYxV0gy?=
 =?utf-8?B?NUNKZ3R4K0k2eWhXSGJBYnFWOEJ6dU03Y3ZqZmFVbi9wdG1tYUpuRmIxVEpY?=
 =?utf-8?B?Q3hCWXpkOVZZZTdHcnE0M00zNjVScFNwY09qNit4ZDRoOGo2cHNqTVdoWFpP?=
 =?utf-8?B?M09tZE9HbXNPYkhJd2FGS05TWlVhRnV4UVRMc2dKM0NWcjdFRmNydCtaVXl4?=
 =?utf-8?B?aDNJLzF1Wjlhb2ZvOFhlL2RmWjdSL3VzQ1pjUnpGK2RIQnEzSGFxQTBSWmtC?=
 =?utf-8?B?VDEzM3lGVXVoYXpTRG5wbEZkWXhIdTZvdVJwb3RjYzA1N2o3eURBY3RyT2Ev?=
 =?utf-8?Q?EyfI=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: IA1PR12MB8467.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84631df8-3a75-44be-e5b7-08ddfcc9f69c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2025 06:57:31.2272
 (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: lkUPhxIWWLxYsoAgSr2sSa74qZVV/4Wk4ypbkhk134mTKOGhNTJR2/ZphbsaWzXuLgOvHSz013/ovCOmo8m44A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8950

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAy
MDI1IDI6NTMgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4g
Q2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgRGFuaWVsIFAuIFNtaXRoDQo+IDxk
cHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qu
b3JnOyBTdGFiZWxsaW5pLA0KPiBTdGVmYW5vIDxzdGVmYW5vLnN0YWJlbGxpbmlAYW1kLmNvbT47
IEFuZHJ5dWssIEphc29uDQo+IDxKYXNvbi5BbmRyeXVrQGFtZC5jb20+DQo+IFN1YmplY3Q6IFJl
OiBbUEFUQ0ggdjIgMTgvMjZdIHhlbi9kb21jdGw6IHdyYXAgeHNtX2dldGRvbWFpbmluZm8oKSB3
aXRoDQo+IENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4NCj4gT24gMjYuMDkuMjAyNSAwNjo0MSwg
UGVubnksIFpoZW5nIHdyb3RlOg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+
PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+ID4+IFNlbnQ6IFRodXJz
ZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMjUgMTA6MjkgUE0NCj4gPj4NCj4gPj4gT24gMjUuMDkuMjAy
NSAxMTo0MSwgUGVubnksIFpoZW5nIHdyb3RlOg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4+Pj4gRnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiA+
Pj4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMjUgOTozMCBQTQ0KPiA+Pj4+DQo+
ID4+Pj4gT24gMTAuMDkuMjAyNSAwOTozOCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4+Pj4+IC0t
LSBhL3hlbi9pbmNsdWRlL3hzbS94c20uaA0KPiA+Pj4+PiArKysgYi94ZW4vaW5jbHVkZS94c20v
eHNtLmgNCj4gPj4+Pj4gQEAgLTU1LDggKzU1LDggQEAgc3RydWN0IHhzbV9vcHMgew0KPiA+Pj4+
PiAgICAgIHZvaWQgKCpzZWN1cml0eV9kb21haW5pbmZvKShzdHJ1Y3QgZG9tYWluICpkLA0KPiA+
Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZXRkb21haW5pbmZvICppbmZvKTsNCj4gPj4+Pj4gICAgICBpbnQgKCpkb21haW5fY3JlYXRlKShz
dHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCBzc2lkcmVmKTsNCj4gPj4+Pj4gLSAgICBpbnQgKCpn
ZXRkb21haW5pbmZvKShzdHJ1Y3QgZG9tYWluICpkKTsNCj4gPj4+Pj4gICNpZmRlZiBDT05GSUdf
TUdNVF9IWVBFUkNBTExTDQo+ID4+Pj4+ICsgICAgaW50ICgqZ2V0ZG9tYWluaW5mbykoc3RydWN0
IGRvbWFpbiAqZCk7DQo+ID4+Pj4+ICAgICAgaW50ICgqZG9tY3RsX3NjaGVkdWxlcl9vcCkoc3Ry
dWN0IGRvbWFpbiAqZCwgaW50IG9wKTsNCj4gPj4+Pj4gICAgICBpbnQgKCpzeXNjdGxfc2NoZWR1
bGVyX29wKShpbnQgb3ApOw0KPiA+Pj4+PiAgICAgIGludCAoKnNldF90YXJnZXQpKHN0cnVjdCBk
b21haW4gKmQsIHN0cnVjdCBkb21haW4gKmUpOyBAQA0KPiA+Pj4+PiAtMjM0LDcNCj4gPj4+Pj4g
KzIzNCwxMSBAQCBzdGF0aWMgaW5saW5lIGludCB4c21fZG9tYWluX2NyZWF0ZSgNCj4gPj4+Pj4N
Cj4gPj4+Pj4gIHN0YXRpYyBpbmxpbmUgaW50IHhzbV9nZXRkb21haW5pbmZvKHhzbV9kZWZhdWx0
X3QgZGVmLCBzdHJ1Y3QNCj4gPj4+Pj4gZG9tYWluDQo+ID4+Pj4+ICpkKSAgew0KPiA+Pj4+PiAr
I2lmZGVmIENPTkZJR19NR01UX0hZUEVSQ0FMTFMNCj4gPj4+Pj4gICAgICByZXR1cm4gYWx0ZXJu
YXRpdmVfY2FsbCh4c21fb3BzLmdldGRvbWFpbmluZm8sIGQpOw0KPiA+Pj4+PiArI2Vsc2UNCj4g
Pj4+Pj4gKyAgICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+ID4+Pj4+ICsjZW5kaWYNCj4gPj4+Pj4g
IH0NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgaXMgaW4gdXNlIGJ5IGEgWGVuc3RvcmUgc3lzY3RsIGFu
ZCBhIFhlbnN0b3JlIGRvbWN0bC4gVGhlDQo+ID4+Pj4gc3lzY3RsIGlzIGhlbmNlIGFscmVhZHkg
YnJva2VuIHdpdGggdGhlIGVhcmxpZXIgc2VyaWVzLiBOb3cgdGhlDQo+ID4+Pj4gZG9tY3RsIGlz
IGFsc28gYmVpbmcgc2NyZXdlZCB1cC4gSSBkb24ndCB0aGluayBNR01UX0hZUEVSQ0FMTFMNCj4g
Pj4+PiByZWFsbHkgb3VnaHQgdG8gZXh0ZW5kIHRvIGFueSBvcGVyYXRpb25zIGF2YWlsYWJsZSB0
byBvdGhlciB0aGFuIHRoZSBjb3JlDQo+IHRvb2xzdGFjay4NCj4gPj4+PiBUaGF0J3MgdGhlIFhl
bnN0b3JlIG9uZXMgaGVyZSwgYnV0IGFsc28gdGhlIG9uZXMgdXNlZCBieSBxZW11DQo+ID4+Pj4g
KHdoZXRoZXIgcnVuIGluDQo+ID4+IERvbTAgb3IgYSBzdHViZG9tKS4NCj4gPj4+DQo+ID4+PiBN
YXliZSBub3Qgb25seSBsaW1pdGVkIHRvIHRoZSBjb3JlIHRvb2xzdGFjay4gSW4NCj4gPj4+IGRv
bTBsZXNzL2h5cGVybGF1bmNoZWQNCj4gPj4gc2NlbmFyaW9zLCBoeXBlcmNhbGxzIGFyZSBzdHJp
Y3RseSBsaW1pdGVkLiBRRU1VIGlzIGFsc28gbGltaXRlZCB0bw0KPiA+PiBwdmggbWFjaGluZSB0
eXBlIGFuZCB3aXRoIHZlcnkgcmVzdHJpY3RlZCBmdW5jdGlvbmFsaXR5KCwgb25seSBhY3RpbmcN
Cj4gPj4gYXMgYSBmZXcgdmlydGlvLXBjaSBkZXZpY2VzIGJhY2tlbmQpLiBAQW5kcnl1aywgSmFz
b24gQFN0YWJlbGxpbmksDQo+ID4+IFN0ZWZhbm8gQW0gSSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Rs
eSBhbmQgdGhvcm91Z2hseSBhYm91dCBvdXIgc2NlbmFyaW8gaGVyZSBmb3INCj4gdXBzdHJlYW0/
DQo+ID4+PiBUcmFja2luZyB0aGUgY29kZXMsIGlmIFhlbnN0b3JlIGlzIGNyZWF0ZWQgYXMgYSBz
dHViIGRvbWFpbiwgaXQNCj4gPj4+IHJlcXVpcmVzDQo+ID4+IGdldGRvbWFpbmluZm8tZG9tY3Rs
IHRvIGFjcXVpcmUgcmVsYXRlZCBpbmZvLiAgU29ycnksIEkgaGF2ZW4ndCBmb3VuZA0KPiA+PiBo
b3cgaXQgd2FzIGNhbGxlZCBpbiBRRU1VLi4uDQo+ID4+DQo+ID4+IEl0J3Mgbm90ICJpdCI7IGl0
J3MgZGlmZmVyZW50IG9uZXMuIEZpcnN0IGFuZCBmb3JlbW9zdCBJIHdhcyB0aGlua2luZw0KPiA+
PiBvZg0KPiA+PiAgKiBYRU5fRE9NQ1RMX2lvcG9ydF9tYXBwaW5nDQo+ID4+ICAqIFhFTl9ET01D
VExfbWVtb3J5X21hcHBpbmcNCj4gPj4gICogWEVOX0RPTUNUTF9iaW5kX3B0X2lycQ0KPiA+PiAg
KiBYRU5fRE9NQ1RMX3VuYmluZF9wdF9pcnENCj4gPj4gYnV0IHRoZXJlIG1heSBiZSBvdGhlcnMg
KGFsYmVpdCBwZXIgdGhlIGR1bW15IHhzbV9kb21jdGwoKSB0aGlzIGlzDQo+ID4+IHRoZSBmdWxs
IHNldCkuIEFzIGEgZ2VuZXJhbCBjcml0ZXJpYSwgYW55dGhpbmcgdXNpbmcgWFNNX0RNX1BSSVYN
Cj4gPj4gY2hlY2tpbmcgY2FuIGluIHByaW5jaXBsZSBiZSBjYWxsZWQgYnkgcWVtdS4NCj4gPj4N
Cj4gPg0KPiA+IFVuZGVyc3Rvb2QuDQo+ID4gSSBhc3N1bWUgdGhhdCB0aGV5IGFyZSBhbGwgZm9y
IGRldmljZSBwYXNzdGhyb3VnaC4gV2UgYXJlIG5vdCBhY2NlcHRpbmcgZGV2aWNlDQo+IHBhc3N0
aHJvdWdoIHZpYSBjb3JlIHRvb2xzdGFjayBpbiBkb20wbGVzcy9oeXBlcmxhdW5jaC1lZCBzY2Vu
YXJpb3MuIEphc29uIGhhcw0KPiBkZXZlbG9wZWQgZGV2aWNlIHBhc3N0aHJvdWdoIHRocm91Z2gg
ZGV2aWNlIHRyZWUgdG8gb25seSBhY2NlcHQgInN0YXRpYw0KPiBjb25maWd1cmVkIiBwYXNzdGhy
b3VnaCBpbiBkb20wbGVzcy9oeXBlcmxhdW5jaC1lZCBzY2VuYXJpbywgd2hpbGUgaXQgaXMgc3Rp
bGwNCj4gaW50ZXJuYWwgLCBpdCBtYXkgYmUgdGhlIG9ubHkgYWNjZXB0IHdheSB0byBkbyBkZXZp
Y2UgcGFzc3Rocm91Z2ggaW4NCj4gZG9tMGxlc3MvaHlwZXJsYXVuY2gtZWQgc2NlbmFyaW8uDQo+
DQo+IFJpZ2h0LCBidXQgbm8gbWF0dGVyIHdoYXQgeW91ciBnb2FscywgdGhlIHVwc3RyZWFtIGNv
bnRyaWJ1dGlvbnMgbmVlZCB0byBiZSBzZWxmLQ0KPiBjb25zaXN0ZW50LiBJLmUuIG5vdCAocmlz
ayB0bykgYnJlYWsgb3RoZXIgZnVuY3Rpb25hbGl0eS4gKFJlYWxseSB0aGUgZm91ciBkb21jdGwt
cw0KPiBtZW50aW9uZWQgYWJvdmUgbWlnaHQgYmV0dGVyIGhhdmUgYmVlbiBwdXQgZWxzZXdoZXJl
LCBlLmcuIGFzIGRtLW9wcy4gTW92aW5nDQo+IHRoZW0gbWF5IGJlIGFuIG9wdGlvbiBoZXJlLikN
Cg0KVW5kZXJzdG9vZC4NCkknbGwgbW92ZSB0aGVtIGFsbCB0byB0aGUgZG0tb3BzDQoNCj4NCj4g
SmFuDQo=


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:08:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131122.1470328 (Exim 4.92)
	(envelope-from )
	id 1v22Ye-00036X-G2; Fri, 26 Sep 2025 07:07:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131122.1470328; Fri, 26 Sep 2025 07: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 1v22Ye-00036Q-CH; Fri, 26 Sep 2025 07:07:56 +0000
Received: by outflank-mailman (input) for mailman id 1131122;
 Fri, 26 Sep 2025 07:07: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 1v22Yc-00036K-OI
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:07:54 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 84f316e5-9aa7-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 09:07:53 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-62faeed4371so2503703a12.1
 for ; Fri, 26 Sep 2025 00:07: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
 4fb4d7f45d1cf-634c35ae6afsm36316a12.51.2025.09.26.00.07.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 00:07: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: 84f316e5-9aa7-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758870472; x=1759475272; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Qe3bt3rkV9A+PuHOZ7dOcd39UK1d6aX6LjaRjBMORfc=;
        b=O1Iyd9cpfaoCn93tFbfpMfnpg5IIFd/+VEffFomkBVaQCE7v6VGz21GEtVCHYY8cQU
         32onWrK2dITMkStM719tC8jTpSOnvexiLU9aVc79kC6ubNGM6s/fb5az0bCqhRUoXpZ0
         uXKSU0nsfI+vo7+FpVPCUIeIVllzOrBX2dJfFVTJVav8c7z1nKu1HnAQWTuk8RPlHrws
         ARx713bfVjl/3Vv7BKkG+ujWXRwyV9Cf8JGzXD09VQxIyBZFK8XcbzZJ0QZgGuyhk84J
         /C2gOO9DJdMklro85Uihxj59lB3y1qICiswLtHCX/lAk04agI5fnm6u55TDsjFMaQJ1U
         Q8Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758870472; x=1759475272;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Qe3bt3rkV9A+PuHOZ7dOcd39UK1d6aX6LjaRjBMORfc=;
        b=hE2IK4K9mCs+lon4GsbsUoGUmR+CUD/AJ+lBJl6FwyfMlybUvOnadolajhoI2UUPEI
         AaIhN9jk9NUPJ5aLGZhHCh+tNIvZTVB8pWC1LRGMqpxk3bgs1yGGu06JqTpZBTTDyBcW
         qyGwRIo+2/ceIi8u9+OxizB0oUo9x1BUy1CCN3Pm+p/+DY+PxX+hUSf1CdQUmNrsk0/A
         5FHC30igiK/lSMoEFq/+Hxci2m2QjIcDliT5fWKUhmmyBoHMx+tD9qYTPNgNiY52fm/z
         13nnB0RzGrSNeEKadOtcJ1sEyUAZUOHP4ZZN20UCfjOc8I4Ul46cELs2s5F85B0DRth/
         TATg==
X-Forwarded-Encrypted: i=1; AJvYcCVMZ97rho6uVlcL/TxTASD/RX+HwrDW4zulC8NPVAMcLIQjJknGaix3tMAyW6bli+SMae9Kyj8Z1rc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw635SaWXU91c/KNEHGkCCQvhbPLiCqPq08V8dSGvUm/iuk55eg
	nqoifNu4zWT0Q9tpv04ClabF8FzuFxTT44OdbahiKsNXB9BducXUWlsccqenrniUcw==
X-Gm-Gg: ASbGnctihDSMWr3VPn3Mfhy3uFwswchMBSyCRXtuX/BMxuJC2ol4q7surk6YDiwjWnp
	yxySrI79Y8z2Dn236XRvgql1DDIvSe/5q1RmPNk9mgHsO5+/ud9caSGMfnV2kZUJqiRhKcqrngN
	trwlWlOddSBqiwJye+TzbHUMrraqTliYG4j4vuJLPX2rKyjqOLgEqQbKY+SAGuOgPeyL1fuWhvF
	F3xQ/V42BkG+fEJjurTno/vFFAPrXgWOzlOaO8Hn59zPL40X295XCCrn3S96CNkxCjywnwHdu3j
	ptCDbYKmTWz8dcvsPUwSW3MOigRXE+vnZJC0fZ/EKpEB+k+ZblDfoB09DFxQgIcuw5SETpX2FjM
	4heM5j4Dt/EwiilDGCkmxRxIbvzuDe2VapHcTbbr/L0hKMDXwt0VXYxkU6W1yYMrrviUdCBZe3P
	20ro6+dm5h6DOSJhUxGQ==
X-Google-Smtp-Source: AGHT+IH2L1TcKSHnhF/098Yya8erV+kjS1wsmyQTUiGCNaWaGJnmBTlA9Qm1qN22WWJ3Ah+TCySfVA==
X-Received: by 2002:a05:6402:4381:b0:62f:ce1f:3a2f with SMTP id 4fb4d7f45d1cf-6349f9ef060mr5648945a12.10.1758870472340;
        Fri, 26 Sep 2025 00:07:52 -0700 (PDT)
Message-ID: <6b62cf4c-8367-47dc-9911-206c220fb050@suse.com>
Date: Fri, 26 Sep 2025 09:07:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/18] xen/riscv: implement p2m_set_range()
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: 
 <5e325267a792a9a0f4cb387b4e3287d22dc8d173.1758145428.git.oleksii.kurochko@gmail.com>
 <6ee4846e-dd27-4588-aac5-f2fe2937db18@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.09.2025 22:08, Oleksii Kurochko wrote:
> On 9/20/25 1:36 AM, Jan Beulich wrote:
>> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>>> +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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
>>> +    if ( root_table_indx >= P2M_ROOT_PAGES )
>>> +        return NULL;
>>> +
>>> +    /*
>>> +     * The P2M root page table is extended by 2 bits, making its size 16KB
>>> +     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
>>> +     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
>>> +     * only allocates 4KB pages).
>>> +     *
>>> +     * To determine which of these four 4KB pages the root_table_indx falls
>>> +     * into, we divide root_table_indx by
>>> +     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
>>> +     */
>>> +    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);
>> The subtraction of 1 here feels odd: You're after the root table's
>> number of entries, i.e. I'd expect you to pass just P2M_ROOT_LEVEL.
>> And the way P2M_PAGETABLE_ENTRIES() works also suggests so.
> 
> The purpose of this line is to select the page within the root table, which
> consists of 4 consecutive pages. However, P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL)
> returns 2048, so root_table_idx will always be 0 after devision, which is not
> what we want.
> 
> As an alternative, P2M_PAGETABLE_ENTRIES(0) could be used, since it always
> returns 512. Dividing root_table_idx by 512 then yields the index of the page
> within the root table, which is made up of 4 consecutive pages.
> 
> Does it make sense now?

Yes and no. I understand what you're after, but that doesn't make the use of
P2M_PAGETABLE_ENTRIES() (with an arbitrary level as argument) correct. This
calculation wants doing by solely using properties of the top level.

> The problem may occur with DECLARE_OFFSET(), which can produce an incorrect
> index within the root page table. Since the index is in the range [0, 2047],
> it becomes an issue if the value is greater than 511, because DECLARE_OFFSET()
> does not account for the larger range of the root index.
> 
> I am not sure whether it is better to make DECLARE_OFFSET() generic enough
> for both P2M and Xen page tables, or to provide a separate P2M_DECLARE_OFFSET()
> and use it only in P2M-related code.
> Also, it could be an option to move DECLARE_OFFSET() from asm/page.h header
> to riscv/pt.c and define another one DECLARE_OFFSETS in riscv/p2m.c.
> 
> Do you have a preference?

Not really, no. I don't like DECLARE_OFFSETS() anyway.

>>> +static int p2m_set_entry(struct p2m_domain *p2m,
>>> +                           gfn_t gfn,
>>> +                           unsigned long page_order,
>>> +                           mfn_t mfn,
>>> +                           p2m_type_t t)
>> Nit: Indentation.
>>
>>> +{
>>> +    unsigned int level;
>>> +    unsigned int target = page_order / PAGETABLE_ORDER;
>>> +    pte_t *entry, *table, orig_pte;
>>> +    int rc;
>>> +    /*
>>> +     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
>>> +     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
>>> +     * are still allowed.
>>> +     */
>>> +    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
>>> +    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
>>> +
>>> +    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, gfn);
>>> +    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
>>> +        {
>>> +            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
>>> +            /*
>>> +             * 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).
>> I thought I commented on this or something similar already: Calling the
>> p2m tree "read-only" is imo misleading.
> 
> I will change then "read-only" to "not allocatable".

That'll be only marginally better: What's "allocatable"? Why not something
like "... does not exist and none should be allocated"? Or maybe simply
omit this part of the comment?

>>> +    /*
>>> +     * Free the entry only if the original pte was valid and the base
>>> +     * is different (to avoid freeing when permission is changed).
>>> +     *
>>> +     * If previously MFN 0 was mapped and it is going to be removed
>>> +     * and considering that during removing MFN 0 is used then `entry`
>>> +     * and `new_entry` will be the same and p2m_free_subtree() won't be
>>> +     * called. This case is handled explicitly.
>>> +     */
>>> +    if ( pte_is_valid(orig_pte) &&
>>> +         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
>>> +          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
>>> +        p2m_free_subtree(p2m, orig_pte, level);
>> I continue to fail to understand why the MFN would matter here.
> 
> My understanding is that if, for the same GFN, the MFN changes fromMFN_1 to
> MFN_2, then we need to update any references on the page referenced by
> |orig_pte| to ensure the proper reference counter is maintained for the page
> pointed to byMFN_1.
> 
>>   Isn't the
>> need to free strictly tied to a VALID -> NOT VALID transition? A permission
>> change simply retains the VALID state of an entry.
> 
> It covers a case when removing happens and probably in this case we don't need
> to check specifically for mfn(0) case "mfn_eq(pte_get_mfn(*entry), _mfn(0))",
> but it would be enough to check that pte_is_valid(entry) instead:
>    ...
>    (removing_mapping && !pte_is_valid(entry)))) )
> 
> Or only check removing_mapping variable as `entry` would be invalided by the
> code above anyway. So we will get:
> +    if ( pte_is_valid(orig_pte) &&
> +         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) || removing_mapping) )
> +        p2m_free_subtree(p2m, orig_pte, level);
> 
> Does it make sense now?

Not really, sorry. Imo the complicated condition indicates that something is
wrong (or at least inefficient) here.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:13:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:13:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131138.1470338 (Exim 4.92)
	(envelope-from )
	id 1v22dl-0004i0-5R; Fri, 26 Sep 2025 07:13:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131138.1470338; Fri, 26 Sep 2025 07:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v22dl-0004ht-1c; Fri, 26 Sep 2025 07:13:13 +0000
Received: by outflank-mailman (input) for mailman id 1131138;
 Fri, 26 Sep 2025 07: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 1v22dj-0004hn-Km
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:13:11 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3fa9b915-9aa8-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 09:13:06 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DU0PR03MB9636.eurprd03.prod.outlook.com (2603:10a6:10:42c::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Fri, 26 Sep
 2025 07:13:00 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9160.011; Fri, 26 Sep 2025
 07:13:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3fa9b915-9aa8-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Xki7iCe14Sx7UxnMsLUuHukpQmftljYWy+dCWDAfP8EWAalsg03JE2iDa0yo+tdpYRax8rtMX30tq1LNro6AkNuOFMGEPFRaMZRACibNLk9Cw6/exSQ5cvkoY94mGtcMKRglFZF5swhNzFULpJzAQuUeQ+42Jg2EK+xPugmO/fOLqnXnODp5DqNCuUyOEIaxgwgsx2Fn50GdhWpqKFMepegSdpfHR/Kqjj8BxkhQ++iqwxBzXLG1KnooemWRnMJlqFf1efu1snd53qY5j9ei+Dld2Oj9MF1YL0/QkZGXsFKLIRXlKJ/NFEOPsx+ug/w//7up4e6mYd623I6LeYXu2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WJQxmK4vy5OunDTKz5gEJ4UhncBojmgKbB4Rq8HH8e0=;
 b=stj8PUaWRz1ipxVe7Uzye5fR4Sj66c1dR5YC2UKEuUUOc8hy/ZDwCu3hZ8qtCqVgttMjvmc7cZSJh+c4Z3KnP9foyz8U22tT21++L1lY2gSwS50U9xuOzYmW03MkfmRAPpP/tR5FdJL2qrQVoObLCsWzF8YAJLZXyEQTBZka9OhZHYBOUecfkOwP9Utl4odIZKMPr95bGzGEKhIhQyR4H1P2GAd5NzXguzIgDVQW01TVBfWlmALLtzcQqKRYk2qw/pl9tL+wB2BWLXdcZr4X8vNaLPpGNZ1vjnnw7eGsvDPZjz2eOo7tRtJXNnKPgchNRaVCkxpyCeLkA8CzLkTYzA==
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=WJQxmK4vy5OunDTKz5gEJ4UhncBojmgKbB4Rq8HH8e0=;
 b=id/DD39JqQgK6Dm1Nvxk9mon7D66Zg8nCGbXH7oG2alnz65ltXuCBC9KPn3tX372cniOTQJGeJP6Q6ou3qiZZFo5DEfQUBT3CSzjeyUUfFR8/b9/unmSh2EPPrBxpzvLBTOJcWB2UdshU9DlIUN544C8SYgVAa0XOHLNc2eN5nR2xAl1w/KFiSdyfyzasnb7+p9CXoOotZr+dhbbzWI4F20D+HhzpY7xQQXAS2QyAgzt1/jjf67ZEi0DeGuuy9/FMvMcjLJS5ED6xVrV7UsONBOa/NMN/4U731MyTeJWg+JSBvrmsxpt0F0dBmDUGtxnF030Y2K/LNdrGoJjuvM5ww==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Julien Grall , Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , Volodymyr Babchuk
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v4] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Topic: [PATCH v4] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
Thread-Index: AQHcLiyQ3fkFbkmvJUapaW4Nz2vAh7SkD2WAgAD+OgA=
Date: Fri, 26 Sep 2025 07:13:00 +0000
Message-ID: 
References:
 <90d39f2050e6028a2fce494381ad0df76f49e541.1758812103.git.oleksii_moisieiev@epam.com>
 <7cf80206-18da-4eae-b297-d1ab23bc66d0@suse.com>
In-Reply-To: <7cf80206-18da-4eae-b297-d1ab23bc66d0@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_|DU0PR03MB9636:EE_
x-ms-office365-filtering-correlation-id: c8650d70-37d1-4f4a-078e-08ddfccc2059
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?NExHZ3ZQZHhDZzRoTkVLNkg5YnhEa0lkcGJTZHpNbmRMRHlFVVZjMnU5Umgv?=
 =?utf-8?B?cTVmcGFvUGpVQXVNUG5kcEUyMnB3VWYwaGNGM2RmUmNmVVNqcEtORkxQUER2?=
 =?utf-8?B?U2M1TXNmU2hDTUk0blF6enVra0w4VzJBZFY0Nldkb1h1WVg5S05qMFpEK2ZH?=
 =?utf-8?B?WWVqemgyUUg3TEtybnRrTEpYeDZZb2tGOEdhcHV4OXVLcXVEOUxGanpHOW1E?=
 =?utf-8?B?QWxtUERxK2UvbjlvRFkzaTdsNHBpa3FHUlcrbjZvNzVUTFZoT1BlR0kybE9w?=
 =?utf-8?B?Nnlrd1FyT0kwOVIzOWk4cXBXRjlEdEVsS1ZYbnNiSFRsZnU2VDJHNjJVSDJG?=
 =?utf-8?B?YUpTOXU0Z3FHZWgyNU9ZM0pwTVk3dGpoU0d3RUlSbUV5bE15UXdEVDFSd05z?=
 =?utf-8?B?aHErOUlvVEVjNWNGZk45OGQ0bTE2Y1dRSTVBVGZocUZ6UGJSVmFHTklDMGFC?=
 =?utf-8?B?SVdjZi9Ya0pKNW0zQW9EQkdpL1pSRHBXZjRhWlo1d00rOWhTZVdhWmRxQ0VI?=
 =?utf-8?B?cXZiQXVaTThSY2VZOUhSUGRySys1clA4ZGNacWdIOTRibXJ6VkhVM2dZajNu?=
 =?utf-8?B?ZE44NUNGd29oZDZZNmdNR1pXaFUvN1BCdUNvK3RVenU0eUNZNDNUODFlemll?=
 =?utf-8?B?dm1MOXU1RndFdUJ6U1RrOW1XanAzZlU0RWRyeklpVklNSVhQTTgyNEVua21l?=
 =?utf-8?B?SXJ3OFlCYUZpTm5LWkQ5VEZISWdyRlNFMFc0VFBHSGNveDR3NHdaZ0xDZlpM?=
 =?utf-8?B?THVkaThQeFhlWGg4Skh0NHYxTDkxc0JJYlZsdW5JN2MrRGRUem9zT0FkQVhs?=
 =?utf-8?B?QlpzK3VXSW9nR3JCVzl6SXo1RTBMRlJhUnFYM0V2dXhsbVNQZC8rblA2eHJn?=
 =?utf-8?B?T2dGRGNlaTVWMTBlQlc1ZEV2MDU0eTdYaHF6eldpellpNDZaOUdBUzBkc082?=
 =?utf-8?B?OHJzL1M4c2hQdlZOS2VMaEdtM3lFaEZ5eWtxNnhnZTRFLzR3MTZpRHZ5Ujdp?=
 =?utf-8?B?S2hyVnArYm14WWtJelZlQVNJeDB5SjNDTmt1bWc3SHhKTFVtN2c2WXRxUGJx?=
 =?utf-8?B?dmRVNTkycXg3K1h5ZzhlU2JPbTI0NFltR2p2QWw0QzRQUHJtYW1zYkVwQ3gw?=
 =?utf-8?B?aDgrc3B3NC9VK0tzZzE3LzVuV2JGbW5vRkpiVzEwUXVUcERjNVdGQUhmR295?=
 =?utf-8?B?dnBDWHJUcHBRYWh4c0lxL3U2OGxjNjlPOGl5dkNlV3ZkQWxiNjlBeE5Dbzcz?=
 =?utf-8?B?TCtFaGdGVVZUWnhKKytSazNrYWh5YWgvVjhobFp0OTNESGtiL3Y0K1VSTVUy?=
 =?utf-8?B?cENRS3Q5YlY2SUQ3SGlFUjRCWFZIY014dHJtU2M5SkUydGlsRnNqemVsT3B3?=
 =?utf-8?B?LzZ0ZXZvQThzT05mMndRUVVBd0FTSXVvNThzeFZmYUtOV0NSc0ROQXMzM1dw?=
 =?utf-8?B?bEczM3pDNVU3RnZ5eXB3YVo3UlBDdmVOdk9TQ1FueFBRSUc0OFhnclNPMUZk?=
 =?utf-8?B?RU9yZVdnYWpSYXlFYUoxWkt4VUM3SEtiUTQzSVN5NUYxYUpvZnE2eElSMDFQ?=
 =?utf-8?B?aWFRWHJLWWZoaGdHYnM0eFFLT21ja3hOZDRQZVBYd29QSWNDdVBrQW4xamZo?=
 =?utf-8?B?eU9TTzl1Wk1SdExHQVZYRkMvdEJYaWpWcWhkQ24rMXQvNXpUWUNSNjBRM3pw?=
 =?utf-8?B?YVYwVUhzbjRrb3lZRk9QT3JoOFFnenNGZWw1VG1pcDhMeHZmTGs3WEh3dXMz?=
 =?utf-8?B?VzY0L3dxdUJXNDREdUVOdU9kWFhRenJ4cVdJWE8vcEhoVkgzbGRvSE1tSS9Z?=
 =?utf-8?B?V3phVkw1WEloUFlPeHYveW9qTEw1QUhWNzE3ZEFKajFCa0p4VFdjaDFpK01i?=
 =?utf-8?B?L0Q4TEFoWmJRcmEyV2twZXM5WDRlQXBJZnZFWG95U0NycTdueXd4NWV2c0Mv?=
 =?utf-8?B?enZzajJGNG5xSUJoY3BDYi95VWpYTVdJZiswTTNJK2huVnJRVDFlckxoV2ZG?=
 =?utf-8?Q?kj8DfzJcAtOu5RQlAgLxyMwqfAXIGA=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)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VlZOanFPbkg2YUlsV29SNERzaGQ4S2xKOFhGVGdIWllMRFBxdnBiWUt0ZFRs?=
 =?utf-8?B?MUhZaUZzayt5NmxXTldDTi9PSzJ5TWxCSXdyOFAzODdwa0JhWVFhZ0QyaHBs?=
 =?utf-8?B?aWs1UXFSeUlEbTFsbnowcGJlTFNwV0IrSkFjTEx1bmdkRTBkWGdnL1FCRTdQ?=
 =?utf-8?B?aTJ3T01WbzFwdDduNVNOM0xMOWFHSlF2amxKcXJpMzVYTnFacS9JWmYrZ2Nv?=
 =?utf-8?B?dENmb0kwYVBWYXFmSFdxS0M5TEJKckVGUzlOWG9lLzh3U09neGliUjVwVDNm?=
 =?utf-8?B?QWYwTExYdnIrZjNHY3cxa1dyZmI2K1Fnd3JFZ1AzY1VUcXVZS3NHNkxCZmlK?=
 =?utf-8?B?OTFYbUp6ZEdKVVB5V2lJaUxOZnloQll6ZEY5WE5aa2VUS3dxajdRcThCTFIx?=
 =?utf-8?B?Y3BrR3J5VElTNE9QZy9LRHh3c0lBcUFsbnh5Umk0V3J3c0RuMzh1T0pjenNO?=
 =?utf-8?B?NFVxdFVGSkZocVpMT1VxM3YzWGZhQ3NldVkrZitlNmgvY1JLL2xzTExWT0p6?=
 =?utf-8?B?eTFaQzljUmUzdUFpRm41WkhIT3ZaNjdtL1MrSG5RUXlYUFp0OUE4UUdSRzhs?=
 =?utf-8?B?Z3ZaSlRhenJ3WUtjWjFqUHp1WThvU2krZ1MrMm45STJwLy92ejdVeGdGSU5U?=
 =?utf-8?B?MkJhbDV0ZW04UmhuMjJoMnZWNEQrSEFGWHVnVEdTT1EwWVRVakZjS1dMNlRW?=
 =?utf-8?B?a1oxR1poTkl4elh6dUszMVBMR0JxVGtsVUxBaldhTUozVDFqcW1rWFhUdEZp?=
 =?utf-8?B?YTc1ckU3Y0RWNGpGM20xYURKNTlVUnRzUzgwc1hqTk1US0l0REJyY25PZGpS?=
 =?utf-8?B?MHFmaW9WbFoxS095bDVnQVE5Mkx3YWRlaUxCL1NDWTVOeWd3NjdEdnNTUGFh?=
 =?utf-8?B?bGt6YklGN0JabjRKYmNhZXE4UXN4N3R6ZEdJOExDMDNsNzlldytmSDN1U21N?=
 =?utf-8?B?citQakhmN0VESForSkFlekJkMkhRRyt2RUp4VEFOTDZHQTFEcEdwU0s2a3c5?=
 =?utf-8?B?M0RwZXFKS1c2RCtPVlF0Skp2Q1oreXc3bmdQV1FQSndrbmcwRVBlMmxueXFh?=
 =?utf-8?B?NHRMRWxwSmphSHl5ZHZGSUNHdzJTSzNsTmo4Y1ZTZVdZZEdLTG1KblhYNU8x?=
 =?utf-8?B?ODNzb010bzlsVUUxcWlWRXlUeW1JWU1RYmVXTzB6Uy9oMUZzR0RxR3JkcSta?=
 =?utf-8?B?Ti9QMUV5RzBIbzkrSGFIWnlVT0NEb2RxQ2pkekJiQnNoWUhTbUxIazk0MGFl?=
 =?utf-8?B?eVFkWWNkWE9zQm1vNlJSeWZtQkIvanQrUXhxWjlJbWQ2bHY2dC9aVXR3Z202?=
 =?utf-8?B?L29uUU5VdXRBRC9uRTNHVUtobWZiakVyQ04vYnd6dWVWUzRTRzcyVDN6WU9w?=
 =?utf-8?B?SVplTzhxVDY1WmVSUWsrSXBPR0oveTlqaHRZZ1dWQko2QVcvWUtjeW1QRWxP?=
 =?utf-8?B?YVM2cGRmcndZbnhBRE5jdXhsOVMxVThiRTYwaW8zOVlxdm5NcUtaKzE3TjBT?=
 =?utf-8?B?UjZVSW41cm1Rc1piSEZpallJQ0tMbmtld1laSkZPMXVqcFd0b0JmaHBOdTQr?=
 =?utf-8?B?OFAwM1pobk0wSEplYytQZTFHeURtaEFFcHc3U3dBTWg1cjd4bmYvZ1VLeVNG?=
 =?utf-8?B?MnRjSEFabmF0L2wzOUJ5b2V4QWZObkIzWTF2d2hHNjduZHZxUWJuMEdDU0xh?=
 =?utf-8?B?eG9JdUhwTkM1b2kvTkxpbUhMK3FwN1MzT0tBWG43ck04SkM3a2dGVjFKSUJX?=
 =?utf-8?B?U0k0ZW0wZ25WbGJjYlg4YXRRRzhKZ0xjeVZJcDU0Yjk0TnV4SWVlVmUrME43?=
 =?utf-8?B?VnpxbGF4a1ErNllmUFFUQ1JuY3hCTG4vOEsva0hHeCtTREpKQ3ExVG1ianNz?=
 =?utf-8?B?bnlUOS9YKzZEUUllMDI2WjZTUmR2eHNkZmtIRHJGbllBZGVPY2kybytwMXAz?=
 =?utf-8?B?WnEvNXFGM2FBMmVkd24xY3NFTVdOblNvejNoQWd3Uzk0STdLQnpDSkZEeVgr?=
 =?utf-8?B?R0VUSDBGeXVKbFpQTWMwclV4STdWVEw5Mk5aQ0I0Vm0wNno5Vy85WEp5ZWRr?=
 =?utf-8?B?RzR1ODcwOGpsS2ljTHZCSzNJbzlBUFBiRHpZdDZtK0ljcUFOdzRucndMNzNn?=
 =?utf-8?B?ZG02VTV0RUp2WCtkbjgzYy9JUmd2azR2eEw0U3V0cy9SVDNZS1FVTyt0UWU0?=
 =?utf-8?B?T0E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0DD3B78516822341B45CC55F20BA1205@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: c8650d70-37d1-4f4a-078e-08ddfccc2059
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2025 07:13:00.2447
 (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: 8sMc3A4TaLHNmQZmNbX3TjBjIqs8cU2VwEMuvtLICVGJqKy644BU9BVyO3PcxxiYY4Psbt29/1qAODFSwEEU5IF2pHWpMr48/lfGwVeHmxg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9636

DQoNCk9uIDI1LzA5LzIwMjUgMTk6MDMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNS4wOS4y
MDI1IDE2OjU2LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IFRoaXMgY29tbWl0IGludHJv
ZHVjZXMgYSBuZXcgS2NvbmZpZyBvcHRpb24sIGBDT05GSUdfRE9NMF9CT09UYCwgdG8NCj4+IGFs
bG93IGZvciBidWlsZGluZyBYZW4gd2l0aG91dCBzdXBwb3J0IGZvciBib290aW5nIGEgcmVndWxh
ciBkb21haW4gKERvbTApLg0KPj4gVGhpcyBmdW5jdGlvbmFsaXR5IGlzIHByaW1hcmlseSBpbnRl
bmRlZCBmb3IgdGhlIEFSTSBhcmNoaXRlY3R1cmUuDQo+Pg0KPj4gQSBuZXcgS2NvbmZpZyBzeW1i
b2wsIGBIQVNfRE9NMGAsIGhhcyBiZWVuIGFkZGVkIGFuZCBpcyBzZWxlY3RlZCBieQ0KPj4gZGVm
YXVsdCBmb3IgQVJNIGFuZCBYODYgYXJjaGl0ZWN0dXJlLiBUaGlzIHN5bWJvbCBzaWduaWZpZXMg
dGhhdCBhbg0KPj4gYXJjaGl0ZWN0dXJlIGhhcyB0aGUgY2FwYWJpbGl0eSB0byBzdXBwb3J0IGEg
RG9tMC4NCj4+DQo+PiBUaGUgYERPTTBfQk9PVGAgb3B0aW9uIGRlcGVuZHMgb24gYEhBU19ET00w
YCBhbmQgZGVmYXVsdHMgdG8gJ3knLiBGb3INCj4+IGV4cGVydCB1c2VycywgdGhpcyBvcHRpb24g
Y2FuIGJlIGRpc2FibGVkIChgQ09ORklHX0VYUEVSVD15YCBhbmQgbm8NCj4+IGBDT05GSUdfRE9N
MF9CT09UYCBpbiB0aGUgY29uZmlnKSwgd2hpY2ggd2lsbCBjb21waWxlIG91dCB0aGUgRG9tMA0K
Pj4gY3JlYXRpb24gY29kZSBvbiBBUk0uIFRoaXMgaXMgdXNlZnVsIGZvciBlbWJlZGRlZCBvciBk
b20wbGVzcy1vbmx5DQo+PiBzY2VuYXJpb3MgdG8gcmVkdWNlIGJpbmFyeSBzaXplIGFuZCBjb21w
bGV4aXR5Lg0KPj4NCj4+IFRoZSBBUk0gYm9vdCBwYXRoIGhhcyBiZWVuIHVwZGF0ZWQgdG8gcGFu
aWMgaWYgaXQgZGV0ZWN0cyBhIG5vbi1kb20wbGVzcw0KPj4gY29uZmlndXJhdGlvbiB3aGlsZSBg
Q09ORklHX0RPTTBfQk9PVGAgaXMgZGlzYWJsZWQsIHByZXZlbnRpbmcgYW4gaW52YWxpZA0KPj4g
Ym9vdC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9t
b2lzaWVpZXZAZXBhbS5jb20+DQo+Pg0KPj4gLS0tDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NDoNCj4+
IC0gY2hhbmdlIE1pc3JhIHJ1bGUgdG8gMi4xIGZyb20gMi4yIGluIGRlc2NyaXB0aW9uDQo+PiAt
IHJlbW92ZSBleHRyYSBkZXBlbmRlbmNpZXMgZm9yIEFSTSBhcmNoaXRlY3R1cmUgZnJvbSBET00w
X0JPT1QNCj4+IC0gcmVwaHJhc2UgRE9NMF9CT09UIGhlbHAgYnkgYWRkaW5nIGh5cGVybGF1bmNo
DQo+PiAtIERPTTBfQk9PVCBpcyBub3QgbWFuZGF0b3J5IGZvciB4ODYgYXJjaGl0ZWN0dXJlDQo+
IEx1Y2tpbHkgdGhpcyBpcyBtZXJlbHkgd3JvbmcgaGVyZSAoIm5vdCIgc2hvdWxkIGJlIGRyb3Bw
ZWQpLCBidXQgY29ycmVjdA0KPiBpbiB0aGUgYWN0dWFsIEtjb25maWcgbG9naWMsIHNvOg0KPiBB
Y2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPg0KPiBKYW4NClllYWgs
IEkgaGFkIHdvcmQgIm5vdyIgaW4gbWluZCB3aGlsZSB0eXBpbmcgdGhpcy4uLg0KT2xla3NpaQ==


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:14:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:14:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131152.1470349 (Exim 4.92)
	(envelope-from )
	id 1v22ed-0005CS-Ev; Fri, 26 Sep 2025 07:14:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131152.1470349; Fri, 26 Sep 2025 07: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 1v22ed-0005CL-AY; Fri, 26 Sep 2025 07:14:07 +0000
Received: by outflank-mailman (input) for mailman id 1131152;
 Fri, 26 Sep 2025 07:14: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 1v22ec-0004hn-1g
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:14:06 +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 623fbaf4-9aa8-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 09:14:04 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b2b4096539fso318250166b.1
 for ; Fri, 26 Sep 2025 00:14: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-b353efa4696sm312600166b.27.2025.09.26.00.14.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 00:14: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: 623fbaf4-9aa8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758870844; x=1759475644; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sTIC/0L6sFxkiu2SVYZaQ8jw3l3Vg3Sc1juVtjkc9fU=;
        b=MPbrf/FG6V1L46/KaRthz/c90y+9wZr8CoQ+uKtxDuFwi/5Wyrr1MUkgICrANrN5WI
         cNYL7/UwLzvAWr7EOPxaVrElk8tBHzc1RdFjVZaMu3P3yo7BDlG383DTD9wysC9XVJsQ
         GGA3CcX8oxuYF2Fia533gasLXR274SZLXIUTc7W1z/JFRk/dD9c6fyoT/LGO5qUEC/Na
         dtD0F72J1xsbWZLtNUkcnmMaSoYx+T9C5oyQXXM+YDvPoi4PcjMWHtXdjaqRqPd+eBx7
         Twp4uXlv5TTnnnntSug8yoPsWyeuUl86DrTIVYA2FuGi+yygAGO4RSpFsDd8MloLVJ1p
         lPtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758870844; x=1759475644;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sTIC/0L6sFxkiu2SVYZaQ8jw3l3Vg3Sc1juVtjkc9fU=;
        b=NyLoprAEzPgqW904ujNQBqPX8iN5jz9q4DjirYLMNJTH1ZGCT+yoPBmk3U2nOMS9vs
         p+toMpvVoxnd4BG/nQwyDM9UKTZW3cjhsm0TmmqggdNKyvCxv/kY7BLLRr6YVg5e6lUy
         +9j+md3VZWuAD4QjjvDGVSS+Uv+k2Gr5tIUBh0RS+QDzbAM+2VExAc+h333VSsWkK80j
         csjwpy+ys2tU+4trUnL1kQbB1NH2eMArj0LStGl5aeS9MYfaaO8iRHBuMw6ut/KACEVt
         8mt2BJhb2khDdZ29TVf1eWb+kK3GFyhpXn86nwrKngxR+YYPa8Bi/0yI7BP8Q4UC716B
         uUug==
X-Forwarded-Encrypted: i=1; AJvYcCV5G1Ca+N/Zm8OHRXg7PPZZ30XK9/akgpgM6uy6fb1/bx1OW2QCPzDGJIibZrBVx028BS5Th5hcpBc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxd6Ie1Y3C/BU6Nbzur9mEq6ScFqWI/E/m4le+vZQrZY9HLavMB
	CbCWETWs/KubVLmxO3RWmJWwayMBTR3VU0/b+dEguT0XJhQoeUiejhQ8dbiPOaDtmw==
X-Gm-Gg: ASbGncugE+un3bhOMe/PptmTwZSn0bPdO5KgqMZvqZ+zqEb3yc+BRWTlT9P5fdvQcdM
	wB8XQtAx5FOKuW0mb9+50HKEYd508G0qsGYrdG6zzcwH3Ix7AEIUgS/wJ5QOE6ffjCOIKPjNX5Y
	SOorljzXCMQCAauajzE/A/bsu1ddfvKxwRsfAhHmp7FLaOu7/e7RB1LxNPHZmUdpGoDc25u27mN
	XOf/a6ZNci4ZT2KVJJrgqZi3enoiv3dpt4Pce9Ul1iW4s2SGkjRbbjhqm2/jqMuTbeEs4P1XAx+
	3IBgpHnP82yLqoOhjkjJlEvtRx+Sn3on4s/QcD61T6D/oFdA2hnzrEL35p4zd47HO4qmEssvbWt
	ApqX589Vq22/UNJMm81/052g9jhUTX2ygQrftaT3VeWrGIEk01At433GEu0GPuM6bG3IyP9lfrr
	wHQ+Mbovk=
X-Google-Smtp-Source: AGHT+IFKaWfIsiQNl3CO572ZITMaToH7dz9HK9VGaqt5gx6iE2J6JafJ/4XgVNBPo9efzdLBrog32Q==
X-Received: by 2002:a17:907:7fa7:b0:afe:159:14b1 with SMTP id a640c23a62f3a-b354a2b1cd5mr566185166b.9.1758870843691;
        Fri, 26 Sep 2025 00:14:03 -0700 (PDT)
Message-ID: 
Date: Fri, 26 Sep 2025 09:14:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" ,
 "Andryuk, Jason" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Oleksii Kurochko 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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.09.2025 08:57, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Friday, September 26, 2025 2:53 PM
>>
>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>
>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich 
>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>
>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>      void (*security_domaininfo)(struct domain *d,
>>>>>>>                                  struct xen_domctl_getdomaininfo *info);
>>>>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>> -    int (*getdomaininfo)(struct domain *d);
>>>>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>> +    int (*getdomaininfo)(struct domain *d);
>>>>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>      int (*sysctl_scheduler_op)(int op);
>>>>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>> -234,7
>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>
>>>>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>> domain
>>>>>>> *d)  {
>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>> +#else
>>>>>>> +    return -EOPNOTSUPP;
>>>>>>> +#endif
>>>>>>>  }
>>>>>>
>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>> really ought to extend to any operations available to other than the core
>> toolstack.
>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>> (whether run in
>>>> Dom0 or a stubdom).
>>>>>
>>>>> Maybe not only limited to the core toolstack. In
>>>>> dom0less/hyperlaunched
>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>> pvh machine type and with very restricted functionality(, only acting
>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
>> upstream?
>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>> requires
>>>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
>>>> how it was called in QEMU...
>>>>
>>>> It's not "it"; it's different ones. First and foremost I was thinking
>>>> of
>>>>  * XEN_DOMCTL_ioport_mapping
>>>>  * XEN_DOMCTL_memory_mapping
>>>>  * XEN_DOMCTL_bind_pt_irq
>>>>  * XEN_DOMCTL_unbind_pt_irq
>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>> checking can in principle be called by qemu.
>>>>
>>>
>>> Understood.
>>> I assume that they are all for device passthrough. We are not accepting device
>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
>> developed device passthrough through device tree to only accept "static
>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
>> internal , it may be the only accept way to do device passthrough in
>> dom0less/hyperlaunch-ed scenario.
>>
>> Right, but no matter what your goals, the upstream contributions need to be self-
>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
>> them may be an option here.)
> 
> Understood.
> I'll move them all to the dm-ops

Before you do so, please consider the consequences, though (I said "may" for a
reason). Also please allow others to chime in. (In this context I notice that
several REST maintainers weren't even Cc-ed here, and hence may not have seen
the earlier discussion.)

One thing seems pretty clear to me: This work likely isn't going to be suitable
for 4.21 anymore. Hence we're back to considering alternatives to address the
still pending build issue. (My take on it remains: Revert the tail of the
sysctl work.) Adding Oleksii to Cc as well.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:18:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:18:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131165.1470357 (Exim 4.92)
	(envelope-from )
	id 1v22ic-00064Z-TR; Fri, 26 Sep 2025 07:18:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131165.1470357; Fri, 26 Sep 2025 07: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 1v22ic-00064S-QQ; Fri, 26 Sep 2025 07:18:14 +0000
Received: by outflank-mailman (input) for mailman id 1131165;
 Fri, 26 Sep 2025 07:18: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 1v22ib-00064M-Pe
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:18:13 +0000
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com
 [2607:f8b0:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5bb4875-9aa8-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 09:18:12 +0200 (CEST)
Received: by mail-pg1-x530.google.com with SMTP id
 41be03b00d2f7-b4f9d61e7deso1328196a12.2
 for ; Fri, 26 Sep 2025 00:18: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: f5bb4875-9aa8-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758871090; x=1759475890; darn=lists.xenproject.org;
        h=content-transfer-encoding:to:subject:message-id:date:from
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=FDT+m8A/96uy+EHTKMHVogsXak3+W4RoK/TV/Hdaj/U=;
        b=LwSw/RoVDaPUqFNUYk1gJHLkVH/zTbCl2wg2oVlZspP6HtWdoXtg2JQQuXI6M+nwbz
         nJFIY6vyZZq3mRuMsxvMTpOKr/2Sr5rpjrbbWzmCVqsNkIaafwoQ8GYeFBAMxCQEzgSl
         a9H1obHGQq5rcDrSNXvZWhneMbmFPWEfUWTzSDIJS5WPn6dK7VBAdpn2tgL+XJXBEmi8
         s9XiXZQQwzNZynVii6DwnC/wE8uKL06RD7bKI4pwWeVfXgnYZPJQYVUjL78wcCi1aadP
         KR0DTWjKrxXiPmsxSPadRI5sLkpB9bbf1TEg0zdotBL3NJHroxV9dXtviLlmEfs7DpLl
         nLsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758871090; x=1759475890;
        h=content-transfer-encoding:to:subject:message-id:date:from
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=FDT+m8A/96uy+EHTKMHVogsXak3+W4RoK/TV/Hdaj/U=;
        b=qTTrgtEt+Y+yimpAiW5nIWHyPW3WR2L2b/UwgLfJxOS/D4/DRz/fzNYNdDTbUTUE7B
         fwgcGRbVmXmSFR29EljLkWUjpww5clo4QOjbK0ckjxUqkhJkVTq9aZ6a2go+wDL+gmKE
         yuXPaHHM9FPyfmamussaDn33nLqYxj+EnzH9NQYga1A3Rp/b+1zPj/fCcxBx2VW0fNlv
         +RTbDIcPbzgx/IfVGyiTTKQGYYtH02QUo4h9NkXS4e5Qwpmd3lfCk9HN7hp8fklX7RFP
         TT1GHiBQTmL0RaA8SZGmW4a9T+ArU0EW6yNctSbz1FK1zwhVOMdh3GznQGCHddZcQa0x
         A9rg==
X-Gm-Message-State: AOJu0YynOteUG0H+wa762Onk1+XdxDlsBLNS3s5Es88KIcepdenXX3vH
	fdDbiirKHM/7vcSKVSXTqtZ61o1fpVEt6IClPCPKmkXOR6cX1lLhBBGkROG2XTJtILSpCt5gqX9
	gso4k8xoKiqeBQBvhCmM3A/weBUlYDY25JllfV3Sn7GTy
X-Gm-Gg: ASbGncuhHIkrpdrSIvsQV6Qqh2K9tlSUKjE1CqWl1em8GqJibz63JK8DM1eBp7mziSh
	LGohQ1z1bK2xIjBr6/FpyfapecHJLBqI+5iAj1XsQImoe/tvS2BoFSnsIG0NXpWu5lR2OU9MDYK
	Bni8BKundjXAN6/QNYt9tiwIeqaq37OT6oOXgzxQHo0rumIiXVgm6yYQuB9mC6f0avopeAFACAu
	Hd0
X-Google-Smtp-Source: AGHT+IH6G1Qfts+Eup9LUP00KZH7cduDW7LI9JDyMxbMS09gzMQijMsO+fjsAecy89tJT/NokZ7veYtFfJGlzv1gYa4=
X-Received: by 2002:a17:903:32c3:b0:27c:3a0f:f066 with SMTP id
 d9443c01a7336-27ed49d0a47mr60362045ad.22.1758871090436; Fri, 26 Sep 2025
 00:18:10 -0700 (PDT)
MIME-Version: 1.0
From: Igor Korkin 
Date: Fri, 26 Sep 2025 10:17:59 +0300
X-Gm-Features: AS18NWBzv6tM-WwilUsX2piuTa0kb817jZtG6bX9GimDTH2NElOGBXzcHWESaCU
Message-ID: 
Subject: [Question] Unexpected growth of nr_cpu in `credit` Xen scheduler?
To: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

I'm observing a steady and abnormal increase in the `nr_cpu` value
reported by the `credit` Xen scheduler
(visible via `sudo xl dmesg; sudo xl debug-keys r`).


This behavior occurs consistently when the system is subjected to
heavy synthetic load (e.g., multiple VMs running stress workloads that
fully saturate vCPUs).
Over time, `nr_cpu` grows far beyond the actual number of physical or
logical CPUs (48 in our case), and this correlates with noticeable
performance degradation, especially under high VM density.

We=E2=80=99re running on a dual-socket x86_64 server (2 =C3=97 12-core Inte=
l Xeon
Silver 4310 CPUs with Hyper-Threading, total 48 logical CPUs) under
Xen 4.19.

Is this growth of `nr_cpu` expected in the credit scheduler?
If not, it may indicate a bug in CPU accounting or runqueue management
that warrants further investigation.


Environment details:
- xen_version            : 4.19.0-5.25.0.38431
- xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_641
- xen_scheduler          : credit
- Hardware : Dual-socket Intel Xeon Silver 4310 @ 2.10GHz (12
cores/socket, HT enabled, 48 logical CPUs)
- NUMA nodes : 2
- Dom0 kernel : Debian 6.1.147-1 (6.1.0-38-amd64, SMP PREEMPT_DYNAMIC)
- nr_cpus                : 48
- nr_nodes               : 2
- release                : 6.1.0-38-amd64
- version                : #1 SMP PREEMPT_DYNAMIC Debian 6.1.147-1 (2025-08=
-02)
- machine                : x86_64
- nr_nodes               : 2
- cores_per_socket       : 12
- threads_per_core       : 2
- cpu_mhz                : 2100.000
- virt_caps              : pv hvm hvm_directio pv_directio hap shadow
iommu_hap_pt_share vmtrace gnttab-v1 gnttab-v2
- total_memory           : 130724
- free_memory            : 54064


I=E2=80=99d appreciate any insight=E2=80=94whether this is known behavior, =
a
configuration issue, or a potential bug in the scheduler.

Thanks in advance,

Igor Korkin


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:30:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:30:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131183.1470368 (Exim 4.92)
	(envelope-from )
	id 1v22ua-0000Wg-2N; Fri, 26 Sep 2025 07:30:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131183.1470368; Fri, 26 Sep 2025 07:30: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 1v22uZ-0000WZ-VQ; Fri, 26 Sep 2025 07:30:35 +0000
Received: by outflank-mailman (input) for mailman id 1131183;
 Fri, 26 Sep 2025 07:30:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v22uY-0000WT-S4
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:30:34 +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 afc96ac5-9aaa-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 09:30:33 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-afcb7322da8so358624766b.0
 for ; Fri, 26 Sep 2025 00:30:33 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353e5d1210sm320286066b.9.2025.09.26.00.30.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 00:30: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: afc96ac5-9aaa-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758871833; x=1759476633; 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=hVa20+lIhjQpraHsX4Gj70ClwZooh72ry2FkROBk2uw=;
        b=Qnhd/np2RHLoSK/ffcWVZvxPfEBrlCcPtryxeuN8DehndblXiUtTsFdW1X6oPtbetK
         7ga5xa7pLkoK3uO4LoYfW+L702RNTZUkkLCzGmgXHKKkCwDPT0235unFO1pI2IitZwin
         y4XGQrTrgLl5gsWLYEuH/gkczZbNOa17DuwJflOfKFuJxHl2kJnoJF77+iiShusWS5Wu
         UMQCLEf078GQP/TrY7UmplWcsWSKPMrS6a1SITmODfs/gfzwcVbspIL3xdfK4RXJnCvw
         NiEzrABafFMmrQAT8vzKzNEJCu9EtrlgScHL1KgBiS4x6u/RRUjjsj9JEoTRg2wpvk+J
         kFdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758871833; x=1759476633;
        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=hVa20+lIhjQpraHsX4Gj70ClwZooh72ry2FkROBk2uw=;
        b=mVebF7G8rcjvQIqj1NiniLpORswu26/nrxezTgHPKrDbt/T7iiLS/U24ek8R+Veyo2
         9fSY+z0k2hk4bMcJkKlfHTc9mmDRoldlhs75VoFSEqO/Mt+C1LC6IGTJ1vasahE8GEPy
         ni+hBVr7MRDUG4ND+mMwNlZBui91BNRwYKbZxW2knjUBgstGWm0gjQXP111HzpFxMslk
         pLp5rLALXwI64OrF4tXEexue0g5E/R31jzcveLQvxrGsdZgFyDKaictQNvzGTUE4Gpr3
         ja8odFt5i9GumvU6x5S4eBZeJtdNcaE+g+3Gg5NpVqf+v2DH2G4eJAn4RO5P6ZHjLeAW
         sPzg==
X-Forwarded-Encrypted: i=1; AJvYcCUOwBs7Bs17jZBFankeRbOkMtt0ccTaXiwebrqIIcCcR9F8lO4Vf16avmgt3BYu2Io4adVgxN3Ub/Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxP5NLz6PBn9IMVlOZwYArLIb2SO0zg/CgVY1mL4i+3/lpNO8tB
	B25a4yHNcVcHoUOuSZ5tuuP46dZb7xNqWkrQmILEYp98MI9DaasqNTJq
X-Gm-Gg: ASbGnctAhy+v1ApqxaKvEAXhQXFt53226UZ/NThP8ORSuxGxQhsUqkBtTvf0XfiBXXI
	kS4hg52jTREbpO2GnjWREMD9MwM1j/amhn9CyluzONZ5jlrOjkdS4814mo6RcCTgzyeW6rxBOcF
	xB/brcLY4JZ0q9rgCz076vOvUqReSpSdM0dhUMRUv/sp4MXZ1AHWgnxW0f072nbjxv2BWjaSxoz
	VnQ1atDpr/k3f8vffEeaLLsoRnBL+yFFClIaXIhHqiznLCkKqhv/fgwKOpFNBQXRn/mRhywud9D
	dsdsjjNKOAF/pUyxMvHg+J4j88cBLgTb3KEp2eBC8noWcslS5TqnGiHwqV9coudKVdYSBSc4/ns
	hkKWaXTytpdMu+fT1+SF1P9vULFRF1sW/4e/d31RGuXx/YK3s0VafRI64plsBT89yWVwKTZ/R
X-Google-Smtp-Source: AGHT+IHHNAYnDkt0p8Zfwh5uaiMKrPEpCRdx+LGWAy0snUTLHHK8d3jK7bbDqxdbFNyRQkRb/lNN0A==
X-Received: by 2002:a17:907:9803:b0:b18:63b8:c508 with SMTP id a640c23a62f3a-b34be0fd02cmr583570766b.44.1758871832559;
        Fri, 26 Sep 2025 00:30:32 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------6SEF60HfqpTLDm8Sl0rw5G4x"
Message-ID: <2ee558fe-1366-43d1-98f6-ee729c097aae@gmail.com>
Date: Fri, 26 Sep 2025 09:30:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/18] xen/riscv: detect and initialize G-stage mode
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: 
 <7cc37e612db4a0bfe72b63a475d3a492b2e68c83.1758145428.git.oleksii.kurochko@gmail.com>
 
 <0c4e446b-abe1-481c-91a6-60a49459b486@gmail.com>
 <9777e972-8ea1-4dfa-bab0-ee7e13f0a0e6@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/25/25 3:46 PM, Jan Beulich wrote:
> On 24.09.2025 17:00, Oleksii Kurochko wrote:
>> On 9/24/25 1:31 PM, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/setup.c
>>>>> +++ b/xen/arch/riscv/setup.c
>>>>> @@ -22,6 +22,7 @@
>>>>>    #include 
>>>>>    #include 
>>>>>    #include 
>>>>> +#include 
>>>>>    #include 
>>>>>    #include 
>>>>>    #include 
>>>>> @@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>>>>    
>>>>>        console_init_postirq();
>>>>>    
>>>>> +    gstage_mode_detect();
>>>> I find it odd for something as fine grained as this to be called from top-
>>>> level start_xen(). Imo this wants to be a sub-function of whatever does
>>>> global paging and/or p2m preparations (or even more generally guest ones).
>>> It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
>>> when the latter is introduced.
>>> Probably, I will move the current patch after p2m_init() is introduced to make
>>> gstage_mode_detect() static function.
>> Maybe putting gstage_mode_detect() into p2m_init() is not a good idea, since it
>> is called during domain creation. I am not sure there is any point in calling
>> gstage_mode_detect() each time.
>>
>> It seems that gstage_mode_detect() should be called once during physical CPU
>> initialization.
> Indeed.
>
>> A sub-function (riscv_hart_mm_init()? probably, riscv should be dropped from
>> the name) could be added in setup.c and then called in start_xen(), but
>> is it really needed a separate sub-function for something that will be called
>> once per initialization of pCPU?
> Counter question: Is this going to remain the only piece of global init that's
> needed for P2M machinery? Right in the next patch you already add vmid_init()
> as another top-level call.

No, it isn’t the only piece — at least|gstage_mode_detect()| and|vmid_init()| are
also needed for the P2M machinery.

Okay, then it would be better to introduce a sub-function now and re-use it later
for other pCPUs as well.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/25/25 3:46 PM, Jan Beulich wrote:

    

    

      
On 24.09.2025 17:00, Oleksii Kurochko wrote:


      

        
On 9/24/25 1:31 PM, Oleksii Kurochko wrote:


        

          

            

              
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -22,6 +22,7 @@
  #include <asm/early_printk.h>
  #include <asm/fixmap.h>
  #include <asm/intc.h>
+#include <asm/p2m.h>
  #include <asm/sbi.h>
  #include <asm/setup.h>
  #include <asm/traps.h>
@@ -148,6 +149,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
  
      console_init_postirq();
  
+    gstage_mode_detect();


            

            
I find it odd for something as fine grained as this to be called from top-
level start_xen(). Imo this wants to be a sub-function of whatever does
global paging and/or p2m preparations (or even more generally guest ones).


          

          
It makes sense. I will move the call to gstage_mode_detect() into p2m_init()
when the latter is introduced.
Probably, I will move the current patch after p2m_init() is introduced to make
gstage_mode_detect() static function.


        

        
Maybe putting gstage_mode_detect() into p2m_init() is not a good idea, since it
is called during domain creation. I am not sure there is any point in calling
gstage_mode_detect() each time.

It seems that gstage_mode_detect() should be called once during physical CPU
initialization.


      

      
Indeed.



      

        
A sub-function (riscv_hart_mm_init()? probably, riscv should be dropped from
the name) could be added in setup.c and then called in start_xen(), but
is it really needed a separate sub-function for something that will be called
once per initialization of pCPU?


      

      
Counter question: Is this going to remain the only piece of global init that's
needed for P2M machinery? Right in the next patch you already add vmid_init()
as another top-level call.

    

    
No, it isn’t the only piece — at least gstage_mode_detect() and vmid_init() are
also needed for the P2M machinery.

    
Okay, then it would be better to introduce a sub-function now and re-use it later
for other pCPUs as well.

~ Oleksii


  


--------------6SEF60HfqpTLDm8Sl0rw5G4x--


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:49:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:49:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131200.1470378 (Exim 4.92)
	(envelope-from )
	id 1v23Cf-0002jv-Ge; Fri, 26 Sep 2025 07:49:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131200.1470378; Fri, 26 Sep 2025 07: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 1v23Cf-0002jo-D5; Fri, 26 Sep 2025 07:49:17 +0000
Received: by outflank-mailman (input) for mailman id 1131200;
 Fri, 26 Sep 2025 07:49: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 1v23Cd-0002ji-7t
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:49:15 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4916ad17-9aad-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 09:49:09 +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 509574EEBC4D;
 Fri, 26 Sep 2025 09:49: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: 4916ad17-9aad-11f0-9809-7dc792cee155
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=1758872948;
	b=hxFbrJg0HD1mrPZrjhJEMHtfhfDkKhaIP4pFSe8syEAicIOsWZEJUvbUPXAn+7nUraXB
	 JaC29VkOzt0h2NV6FWdN5NJRh+HdwOPxYky6nsCoTJCZ+XX3vvqODkfk8rr6NsOcjflqz
	 ls9s36ZmQZ6uUlns5PBtOoGSk7hTK4daNJxxQSuym/CWHaDAvBILvt0Xcbs68eTQe4UOR
	 4zm/FmNopRKooKo9nbP/J4PzoxXAin9nmFkgc5bKc5ES66X1ahRYnCkAlLIbrbr/nxp3I
	 +z8Z5mmgGoXwbTRrdwGSXKMW7P9fpcEUT7X36txafnWhlvNZ35y/e+KK0fNR+1R3WvGiy
	 95ofcW9xTWb3WXRbpHdEFwbA7lFinsju8D8i/DkjQP+itHCxvUjad4t8ItkRyZ1bneoP+
	 QLoC2ExL4YPfRBrAl1gJoLnhKMUKmpMr90LgRxZrzCtRDkn2WRtA4rwi/bqr23DLFrKEH
	 hMGeUQ7H8zfQZ/otN4+Ig6UAwgLRtoehjbR0WKTZvuURpbOkt0+u/Qa4AO6VP3i181hbc
	 lRzl6H8L2JOTNY+wB7ddHt+hfSYBx0yDHRC7iTezvN7DP83cMDaYglngAIQwfadxH+5OA
	 tm5UwmeInxQ1jvZWp+YeInUORXPOhNw3Ou25CTrOU/Q+WR2V/p8PSAFMlpyJ/ls=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1758872948;
	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=hOX7BXjqXFIc87ZFW5RPol29CzZmaqU6Ty3bcp9Rj24=;
	b=pG0eS/YCx5btoq7YWTFj8h7cDTnrFfyrb1XNBwuNUzrx4bVhbOLeYkSQfldUr/iD8VMy
	 0PTLWn930BfE1jGupF7wEqAX/f8Cto8CxA4J7hxha8vXO4jEwNLGQaMCxr3glScnp4Mpf
	 8kzDobdo1fdJdxa68dDTGxE4ljeqLQp6Va/YyFw2pmNcJbZ7cu3xpG95UK5EbPthtmdVx
	 Gh3/caTsFboDevKMCNPGoWNO3whDJuZrWVgdWLp8taazo7X4zfdVbylJT8+W9wjtxFHwI
	 zHNWH/1GdHvNVRbDetcBhawLgdx930RPmU7q2Q9AWKlJkAkZrarDKQ4woAffnz133gPON
	 etMWvSEUPaJlVbHb3VAUVbCI7kzR1OLWgL87sZz21zlhbMNhJxWTaPu1XAeogi5C4D06R
	 7nfvxTjbY//sE5DzcywVxdm3MCCZuwKBcxY8F+h0mas6j5hfLAd+/Zb0yHdAoxfiCdOy9
	 cauuI6nmKMqXmpHG47mqvz4k3nCkXU5bm2zPOeKQHfJifIv5hG6hdB5mveo2HhQvT1lIt
	 CTa8InMXFW3rB/Brp2EQbCmQy82hOm7wjeucVkkCL7L8QW+R/fur12KMtWCzZOr5/m3ds
	 J6YQUQazJ0NptmqJTjVGKcLDcKpQHIl2JzbSi/JvxljlhAxXJBrnkSnFC/5lFXc=
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=1758872948; bh=LYEoNRNlkar+Ws+T5bjZtE0Pzl/yxLwBSaDqoyDFass=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=L3yKAlcRPzx6iPXDze0pc1Gfh+5t195AhLvddOImUAg+sjqh6aiA/Xqrc84o7ERw0
	 1YXFvm+9M8gNlTuJ52yplKC5F7jvTPwWQcuzKQ37UNDe7jpevW/ozrqn95Du0Jxv+1
	 3yFc9SVn4CczAUwoyWKUXMlDwb7ls5Oa+6SFxMwoAf2h08kofK7hqxxWddg2iuY5L7
	 zKoI2ZMCBxzG90tVzr653yLUWHCgJqyu/0Fs7StxFyH8ETuuWdOeZxgUm3xnJHloss
	 owCBx9CwdiQcrC8GcTxP2/VZHS4/ZZNLprujNmPOy1nnlBLIp3H8fg8d/k0rdDfipL
	 i7a1aRpDBUU8A==
MIME-Version: 1.0
Date: Fri, 26 Sep 2025 09:49:08 +0200
From: Nicola Vetrini 
To: Dmytro Prokopchuk1 
Cc: Stefano Stabellini , Doug Goldstein
 , Andrew Cooper , Anthony
 PERARD , Michal Orzel ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org, Jan Beulich
 
Subject: Re: [PATCH v2] misra: add deviation for MISRA C Rule 11.3
In-Reply-To: <278915c9-0049-4e25-90ab-9bb3da7ecee1@epam.com>
References: <859503540c6b7447f13365c2b70b386c2975edd0.1756056144.git.dmytro_prokopchuk1@epam.com>
 <21268b36-ca49-4628-835e-1708ad313946@suse.com>
 <278915c9-0049-4e25-90ab-9bb3da7ecee1@epam.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-09-25 21:11, Dmytro Prokopchuk1 wrote:
> On 8/25/25 13:23, Jan Beulich wrote:
>> On 24.08.2025 19:27, Dmytro Prokopchuk1 wrote:
>>> MISRA C Rule 11.3 states: "A cast shall not be performed between a 
>>> pointer
>>> to object type and a pointer to a different object type."
>>> 
>>> Violations of this rule arise due to the 'container_of()' macro, 
>>> which casts
>>> a member of a structure to its containing structure:
>>>      container_of(ptr, type, member) ({                             \
>>>             typeof_field(type, member) *__mptr = (ptr);             \
>>>             (type *)( (char *)__mptr - offsetof(type,member) );})
>>> 
>>> The 'container_of()' macro is safe because it relies on the 
>>> standardized and
>>> well-defined 'offsetof()' macro to calculate the memory address of 
>>> the
>>> containing structure, while assuming proper alignment and ensuring no
>>> undefined behavior, provided that the input pointer is valid and 
>>> points to
>>> the specified member.
>> 
>> I may have said so before: This all reads okay to me, just that I'm 
>> unsure
>> it would actually be convincing to an assessor. The "provided that 
>> ..." is
>> a pretty strong requirement, which isn't overly hard to get wrong. 
>> Stefano,
>> Nicola - what's your take here?
>> 
>> Jan
> 
> Stefano, Nicola,
> 
> gentle reminder.
> 
> Dmytro.

The fact that you can't guarantee that the pointer you receive is 
aligned was the main reason why I didn't already introduce such a 
deviation in the first place. Now, as Stefano pointed out unaligned 
accessed are largely ok on ARM and x86, with the exception on MMIO 
pointers (hard fault) and some niche cases in x86 which probably don't 
matter for Xen dealing with vectorized data types. So the crucial point 
(not just for this specific deviation) is ensuring that pointer are 
properly aligned when it matters, which in this case is the same as 
making sure that "ptr" indeed points to a struct member. What might be a 
convincing argument is to have sufficient testing and sanitizers (ASAN 
mostly helps here) to show that this assumption is met with some degree 
of confidence.

-- 
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 Sep 26 07:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131213.1470387 (Exim 4.92)
	(envelope-from )
	id 1v23E6-0004BC-PD; Fri, 26 Sep 2025 07:50:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131213.1470387; Fri, 26 Sep 2025 07: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 1v23E6-0004B5-Mg; Fri, 26 Sep 2025 07:50:46 +0000
Received: by outflank-mailman (input) for mailman id 1131213;
 Fri, 26 Sep 2025 07:50: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 1v23E6-00049y-0C
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:50:46 +0000
Received: from BL2PR02CU003.outbound.protection.outlook.com
 (mail-eastusazlp17011000f.outbound.protection.outlook.com
 [2a01:111:f403:c100::f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8145f695-9aad-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 09:50:43 +0200 (CEST)
Received: from CH0PR03CA0337.namprd03.prod.outlook.com (2603:10b6:610:11a::27)
 by DS0PR12MB7969.namprd12.prod.outlook.com (2603:10b6:8:146::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Fri, 26 Sep
 2025 07:50:39 +0000
Received: from DS2PEPF0000343A.namprd02.prod.outlook.com
 (2603:10b6:610:11a:cafe::d0) by CH0PR03CA0337.outlook.office365.com
 (2603:10b6:610:11a::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.11 via Frontend Transport; Fri,
 26 Sep 2025 07:50:39 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Fri, 26 Sep 2025 07:50:38 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 00:50:37 -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: 8145f695-9aad-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KGn8KemVexQNfB3BUCkyEgKffrTlDvBiFWK4jRezJ/AdafbzjgF5Sbfmn6oTg0WiyjDm2BdxxRQZnEw/+I/8Ix2G7QJNEyBkTJmgapKyW02AMdGf6UNeIqkIoL5FgJVQSbWFolWEnTW0sYa/DoeBsyH55BtaAUEUWwZrHlMICXdazkYYvb2tfZCq/PKfxcl+gAgebC/yD0fsaOHHpXjpXHACV5safSiewO6ZZAVnmQc83gyp9ns+FtAUnXjfpY/7EeuSuZHZOnamcB0RUlEex01+wr+g0yGXfi6lgoAg+R7T5JU6C7hSD1whWXZwOv5tk6ij/kBURKqB8VpgkMPpXg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HHj0ImhXHdcvnNj/FB/XwmW3uqXeNHk5nKS/vuiRWew=;
 b=AaK0QohuDnoCERimE33V6ZCM9HnarUUTJzXlfRdl/xS5ZAMUunKXBdK4CzrQ6eUo46U0LGpnAcKT4ycwR84nDyqoOlDpMWKEWwDX2XABE36b0iXe/un3NWQF9iVb/QooISHUb26jeqDeOplwQIn0vf1tn/ed2ukErty9Jdq9eTe8JIUahkufQ5BVIwr0YvkDxQEbpbFAyiHhXZD+zN18OaJQtKTSf9/7cctpGU+dQsfRqWoIJGKdpnAGD/6nr3VHf8FQ90hWQUlGCHvvqihH/54m3RefCUhoEjHYeu9soVDophylkoeU4n2j9+IM1lsdpVE4CHkX7qMmJTkd3hVltA==
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=HHj0ImhXHdcvnNj/FB/XwmW3uqXeNHk5nKS/vuiRWew=;
 b=IrEQVOZWhNdvLWh3P+PngsQfUlLFfxsamXiX0iLsaYoafPAFybFEXx+55UGEksiFC74C7wSmGGoDYU4/iJjj8WCi5bE4K1R1jhKQjBKrsY/N078Tfx5aCmi6buWZ6Gy3t3qHC1RnRLAa41QO6POFfRcYK0GZ46h2aWr1sEOwcQI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v12 0/3] Support hiding capability when its initialization fails
Date: Fri, 26 Sep 2025 15:50:18 +0800
Message-ID: <20250926075021.27967-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343A:EE_|DS0PR12MB7969:EE_
X-MS-Office365-Filtering-Correlation-Id: 887d9876-d884-4e17-b03a-08ddfcd162ac
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?anIwNk9Sdzd4U0xVMjdpWnhwTlgvNGhTZ2JtRStYRlVCcFVGRDNvcHQxb1o3?=
 =?utf-8?B?eVU0dTQzV3FmVC9UT0l1aVBJY1VpcFlZMjBxRFo1Y0I3TksrYkM2V2xPTlhQ?=
 =?utf-8?B?S3pMQjVWV3U4TTRadG9kN20yRkI5SStNZW5XQkRKRWJnVWgxcFUxV1RNTU5E?=
 =?utf-8?B?QkxtOFd3NmFSZTRRQjlhYWxpZmczKzg5TnlOQmxoeFJlUFpLTWtzS1RkMWs1?=
 =?utf-8?B?THdldytYVHZiNlpEQ214M2dmRC8rQmdSa1pGYmt1b0hnTkZYK1lDUm0zaW9p?=
 =?utf-8?B?WGk3bzRRdXZEeDRzVk9udkRkYmhpVVNSS3phUUVNVDRDZjV0MDA0MWQ5ZkF3?=
 =?utf-8?B?aTRicXVwQlFTaGdtRFJkUXdneXF2WHRhZnJvU1MwYi9UYi8xWWYwNm90M0Z4?=
 =?utf-8?B?ck1ualp3empnR2JITE10WHVqTm05NVBnd2tiMi9SMkFHNjlBM1VwMGNkODY3?=
 =?utf-8?B?ZWxJTHBudDVuMzFid21KcXpNYjZZaCtIVmRZUlJOQWtPRzhwVWRDN05xRW9q?=
 =?utf-8?B?MU0zSmlRNlVXU0sraEU4QmxtaFdhU1ExeVpxRnE3aXdidnh4UkNhcGV3Mmsr?=
 =?utf-8?B?VzRXbnh3RXFMaXZKcFFDTmwwR0tiN1YzRUlURzJiQUx5ek81UFhpeDNzenZU?=
 =?utf-8?B?RkgxdFFFQThTbVluazY0aW9UdG5BcWl5SU9zZjVpaEdORGhWMmZwblFKRk9s?=
 =?utf-8?B?YnBJT3hwL2ZRMlFieFpWWk1nTmozclZLQ1B2aEd0SFEwZkw1aC9XeXJDN0JF?=
 =?utf-8?B?bW1PZ21wWXpST2hVYVVJWnJiQXZCSnluSzN5cWhmY3dVL29FOWREeXVGMmlD?=
 =?utf-8?B?bVpnVEtqemozYnNNcjZrQUZUQnY2THhJSlNtSVRMNVlIamtrUG9ybmt0a3Ft?=
 =?utf-8?B?R050RW9vZUhFQndPVitHbWRQclJwRTRlMEpJSnNSUGJJQlBDTzZFWHFsMlBV?=
 =?utf-8?B?MDFRT1creTllYXY5V2VkMmozRzRsa1hSdEdhR2lDYlFFNERuTVRleVUreEtF?=
 =?utf-8?B?VzhhdTJvbmthVTM5L05xWW1tRlpjWGk4aC8wbHNiajJPRmVwV3BubklrMU81?=
 =?utf-8?B?dWJWM2U2Sk5aOUREaWpZMzZORHo0YXRGTnBsQlloaGtHeUN1UGYwRjJRLzhz?=
 =?utf-8?B?d1I2NjZ6NjBNTThZcWxQMkhyZjlFTlp0eHNvVEhjVWZEclNEYXZDUm1STFdC?=
 =?utf-8?B?Y1FabUtXVWNEQzhPSXZwSXNXc2VsZ1J5WklEb2x0cUEvVU4wNXBDMHVTS2xH?=
 =?utf-8?B?NjloaFo0YnU5Y2VYOTk2VW8xWTl1RzhidFQzaUpxUXVXMXVESFMyN0JBdXFI?=
 =?utf-8?B?TTZDdEVEMkpjenFjMy9kaXFQOWVsTGZSS1dwUUx4b0N5V1ExeE5NZlZQK2pI?=
 =?utf-8?B?WVFDdlFZOXhDM2l5NE1WVVM2bTNzMGRnUWcyYzdKQ1lyb1F6OXdhYi9VYUlq?=
 =?utf-8?B?WUdZWVBQemtvR2FZNnJSVXJoT09qUVZhc3JCUWJQQ2Z2bHBjdTRJdFdLT3hs?=
 =?utf-8?B?ZTJmNzEwbjB4MTJhaGdTSDNWd2MyWW9WdUNsSExzb2F2ak43MndFRHNybW9Y?=
 =?utf-8?B?UDJ2ZlAwbW1JTFNZYTVZZzQ2b3FtZmM0V3hJd0RLa3h3WU9wTDlEeTFVcXhJ?=
 =?utf-8?B?NkkyU1hSS2xtUFhDa3oxRHNpcXN5c2ZCUGVKZjFYb2dJQTlyLzVUVTlERXo5?=
 =?utf-8?B?VG9zbHhRMXZTUGo3ZkNsZi9XelNxZ2JJcXllRGZSeEllaHJueG1rZFRKSUNx?=
 =?utf-8?B?TjdQTlI2ZE9VUkEyTERoaStySHkzWUE5dmZlcytjVTZQQkpWY2EySkg3NVZM?=
 =?utf-8?B?KzlnUlhSUTkxcDNhaWtxeVkrNHlUYXU4cUNuM0hkT1hoQnVPdHpndCtjbnUw?=
 =?utf-8?B?cDRIMXdxeE1WREZiaC9YdDZqYUc3VVJ1dzVUaEV1blVIZCtjWFVYcGVqMGEz?=
 =?utf-8?B?cGpLWk1wYkdaL1p5R0xTRUllcUVOQ2MrZ0hvUHFlQXhRT2RFcW13US9sKzFG?=
 =?utf-8?B?dDZLV3JVeElHbm10aUtkVmJlL2RjaFI1d1JHMnU4WmFhbXhCK2YraktpVzYr?=
 =?utf-8?Q?13bosi?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 07:50:38.9604
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 887d9876-d884-4e17-b03a-08ddfcd162ac
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7969

Hi,

This series is to
emulate extended capability list for dom0;
hide legacy and extended capability when its initialization fails;
above two parts had been merged.
remove all related registers and other resources when initializing capability fails, including patch Rebar #1, MSI #2, MSIX #3.

Best regards,
Jiqian Chen.
---
cc: "Roger Pau Monné" 
---
Jiqian Chen (3):
  vpci/rebar: Implement cleanup function for Rebar
  vpci/msi: Implement cleanup function for MSI
  vpci/msix: Implement cleanup function for MSI-X

 xen/drivers/vpci/msi.c   | 55 ++++++++++++++++++++++++++++++++++-
 xen/drivers/vpci/msix.c  | 44 +++++++++++++++++++++++++++-
 xen/drivers/vpci/rebar.c | 62 ++++++++++++++++++++++++++++++++++------
 xen/drivers/vpci/vpci.c  |  9 ------
 4 files changed, 150 insertions(+), 20 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:50:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:50:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131214.1470398 (Exim 4.92)
	(envelope-from )
	id 1v23EA-0004Q0-0w; Fri, 26 Sep 2025 07:50:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131214.1470398; Fri, 26 Sep 2025 07:50: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 1v23E9-0004Pt-U6; Fri, 26 Sep 2025 07:50:49 +0000
Received: by outflank-mailman (input) for mailman id 1131214;
 Fri, 26 Sep 2025 07:50: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 1v23E8-00049y-Gz
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:50:48 +0000
Received: from SA9PR02CU001.outbound.protection.outlook.com
 (mail-southcentralusazlp170130001.outbound.protection.outlook.com
 [2a01:111:f403:c10c::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 82ef4daa-9aad-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 09:50:46 +0200 (CEST)
Received: from CH2PR05CA0030.namprd05.prod.outlook.com (2603:10b6:610::43) by
 MW4PR12MB6731.namprd12.prod.outlook.com (2603:10b6:303:1eb::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.10; Fri, 26 Sep
 2025 07:50:42 +0000
Received: from DS2PEPF0000343C.namprd02.prod.outlook.com
 (2603:10b6:610:0:cafe::13) by CH2PR05CA0030.outlook.office365.com
 (2603:10b6:610::43) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9182.5 via Frontend Transport; Fri,
 26 Sep 2025 07:50:41 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF0000343C.mail.protection.outlook.com (10.167.18.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Fri, 26 Sep 2025 07:50:41 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 00:50:39 -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: 82ef4daa-9aad-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SGpJf5pvpCncbXnoNtXZGHFR9xn0pC4ViyjwUojvZ5R2PZuqMIQpmiaM3ryVKNwYcllh2C4IKn/0ahUryEltqsOV536E0OP63RSfn4MUGbfJOQf3ncmFtZ/DhY2ValX54EWs72k3BsKadlYUFQyp8NyPoaEQS7CG4J51Nlmrba7YoUOsudGdl38TtMpv7Y5QOSVHtnZIHLAVP7k4/w9d0Nh69npTX5g5tAr73isZXWeOFExd/Zlf7wce2KusrScuwc55FS3RN7X9KiSzTesEKlDMPumBhbiifDwB8cYBFacmTNib6pJJwqgFuLcaIKgL2R3ie6OGb52dt9teR4QnfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ludIB4tomAkFHdVYMp26SsnX4Cy76mwEPAwccNGqB8k=;
 b=RhoaHPKkTdsrt/oL46qlRI0qYj6YlmaXlHnspeWLOVJpt8pOh/hORWs2hpb601+cqruvfBGCR4YrSlLZ2zx46JLwN200lmkr3wdAXYIZmbzS2ALQQWnWET5Ez/U43wLAdVqSP4GW1U4U/JTTCntxyxSsUwteCVP5Ahkc3pMEuT0SY6AbayOdk/l36mh9eaT6wXRdCxU+/AmWNQhN/XB8GXMDegBfolVNb111GIfSFviVeiCaXyW9cjnK/gL509QMK8rlvyG5q31QnZB2GzAvXPtMfutrextHgd7Lu2HjmofT0fCNNQxC6taDGlSTJjs3FpwzJpWXh3Dld1mcIfPx+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=ludIB4tomAkFHdVYMp26SsnX4Cy76mwEPAwccNGqB8k=;
 b=rmW4kcRPA/jUKemZ4LQjudr9/+rEwCRnzV667C77Jm3Fx7ODLs4u6z6wQYGa1uM6yhe5Eu1MkTnx/AExJoOdCgGJtUPQGkJoiD+5B380EDmp7RXbrgGsfMuUunVy5F4C5ktnZxzdI2L6tgEIGMKFUYNh0Einms8eQEUK4WZIZdI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v12 1/3] vpci/rebar: Implement cleanup function for Rebar
Date: Fri, 26 Sep 2025 15:50:19 +0800
Message-ID: <20250926075021.27967-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250926075021.27967-1-Jiqian.Chen@amd.com>
References: <20250926075021.27967-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343C:EE_|MW4PR12MB6731:EE_
X-MS-Office365-Filtering-Correlation-Id: 8a13f36e-261b-4e89-ffdb-08ddfcd163f7
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?TnlOQklycEZDd2E4Ujh2ejlodmNWMHFTU0VyeGFjSytzUWZJMnpKUGhqU25J?=
 =?utf-8?B?WkI1WnUzRHBxbTQ0NzFONEEydklLQkVXd3BqbkFTV3F0RGh6Qi9QdlVITHY4?=
 =?utf-8?B?SmxzTDdZeUloQnJuck1PSGo0ZCtNUkNtUGlTWWkzNVg0OERBaXZuUlczUlR3?=
 =?utf-8?B?SVpNMDg2TUtTWGVsVDgxNm5vZHRHYk1uSm0yY0h0TCtmTk9JRWdvV1l5OEY1?=
 =?utf-8?B?T2lJaDFoYzJEd1dzUHBPQ0ZwTVVnNXFKT2I2bmVlQkJjcFcyaWRpQjlzS29E?=
 =?utf-8?B?S2dMcnZsOVJrOERJNTY5WWFHcVlqcGdZMkxoOEJ4ODZ3Q1B5U1pVdGxYTlpv?=
 =?utf-8?B?NitYZEN4YTFzRmRmaG8vazhnelRDTlpOVlJMenNKczZDSG5RWXFuY2l2RWxB?=
 =?utf-8?B?VndSK3JYUnpBL1R6bTlISlFmV3hORVJjZ2tBV1FoRVJZMnRoRnppenI4aDhE?=
 =?utf-8?B?Mko0bFAxZHRnbXVob1RwR045RHcvV0p5TWNSK0V4WjVNYjEvVG82dlBVWG95?=
 =?utf-8?B?bjIwM0JoZythYVNSb1RVN2JtU3F4bDNqZU1tMlRGS0tOZExuSG8yQm5lTzRC?=
 =?utf-8?B?UWZCTzlNdWNrRDJyM0J0OFkzU0V0RDgwdW1jcUNKVzVhaXBKb1VTNVo1aDNW?=
 =?utf-8?B?ZmxsMlE3cXIwdEEzalYzejlsWlhlS2pGK0RBNWc2WE9jTW9hMmxuMjk2YTE2?=
 =?utf-8?B?d2ZWTGp6bXlZa21BTVhUUzBtQnVZenZyZCtGakxHa1lxTnRvMXlVVXhWcWlI?=
 =?utf-8?B?Yi9WcnNFV3VhSC9vTjFKZUNGQk1JV2dxSUU0WTZmNXk0Rm9WUXhlOWMwTTRu?=
 =?utf-8?B?NUJ4WWs4K0d3Wmx2SklzNFY1cncrWEFVRVVTeThFRXIxbVpmSklEUWsyc1Jj?=
 =?utf-8?B?TE9SLyt6RDNWd2gzMWp3Z2FrUHM2M0tYdDQxdjdVcUVPbkVZdjdoQVN1RXpL?=
 =?utf-8?B?bUdsTUc3OS9jei9vZVBjOTV6cEZuL25yaFJFczljdEtpTWE2Wm9DckVMYTBI?=
 =?utf-8?B?K2FNUEdXS0R1YWE0ZFB6ejQzTVRXRkkrdllySSsvWUZEZkh1Q2crQnI1anNv?=
 =?utf-8?B?dWFoc2dqYWtZQjk0akxmbHlZK1U2czQzbFZ2N01vbldkT1kxWURQSjJ3MW5u?=
 =?utf-8?B?TDUzejljN1lVcjZKQndEMjJDNFQ5NVR5KytrZzFVd3Z4YnlPaTlsNktMZnpY?=
 =?utf-8?B?V3ZWaldKZG9rTWdnaGFiVEc2dnJGT1Ixd1FuNXhTS1NZTjFzREtVWU9OcUVi?=
 =?utf-8?B?U0NJY2JOK2xkWjdNM2dyaW1ERUUzVGI3Y29JakU2ZVBwbHFRUGJTb0V1a3pl?=
 =?utf-8?B?SFVIai8wNzZqKzdrNGZieldmWDVZSURJMEduNk9GZ2Fucklhb1JzVWpsRmlG?=
 =?utf-8?B?N0U4eUhQZkhqd1I2WGFsWTFoLy9tbEUvQlk1bkxGOHlWdXV3STg2aTN1ZUph?=
 =?utf-8?B?SkV0NnM2RjFyeDkwLzJFRnNHaVZQTmJFL1hXSkQwMnZYSnNEWXVtTnk4ZHd2?=
 =?utf-8?B?VkJBakNwdWMrc1kvazAxMGI0THRrb2p3dGN1VWlWek1xVzM4MnNsaTJjU3o5?=
 =?utf-8?B?RkNBWllTcUVFUS9EdWI5YzBhdXNEYXZmaDdHMStLalhrZlhuanI1SGJQcEtQ?=
 =?utf-8?B?clRCUkFRM2tjWjlDVXZqM0xwb1VZdlA0Z0JsbHpKTGVibmhnak1qNE51YUk3?=
 =?utf-8?B?N2tkNWFhdGhaMktyMGZ2alBieXBDUEpoMWNLOVJuSmFrZlBsOTNXTFhJQUdF?=
 =?utf-8?B?ZmpJZzR5QkZBbTJwc3U2dE9rR0RkckF1aWV2Zmk4VWpoR3pNZGh4aTFZVWMv?=
 =?utf-8?B?UHN6MVZ4RURFd1JRbGQ4eHBHb1dFS00rVjAra05sUHBPSndvbHJvZVZLN0NI?=
 =?utf-8?B?a3VvTnpEb21SMGRZaUJxK013TUx6L3hLNlVCZ2JoQlpob3llc1JMNTJxdXVB?=
 =?utf-8?B?ZmpaMUlhZzhQNjNuY2NNYmtSS3lsRW5EbU1nWW11bHRVZjlmaThlVlFSd3Z2?=
 =?utf-8?B?NTAzRVd0aGtocmMxRlZEV2hwUjlMdzVma2xHcXVqM2ZFVlA4RVBGekJIc3A3?=
 =?utf-8?B?OHpNNksyN2IwZ3VIYmhaZ3BXZmdhU3Y3WW1Ydz09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 07:50:41.1241
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a13f36e-261b-4e89-ffdb-08ddfcd163f7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343C.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6731

When Rebar initialization fails, vPCI hides the capability, but
removing handlers and datas won't be performed until the device is
deassigned. So, implement Rebar cleanup hook that will be called to
cleanup Rebar related handlers and free it's associated data when
initialization fails.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v11->v12 changes:
* In cleanup_rebar(), move the check "if ( !hide )" above the vpci_remove_registers().
* In init_rebar(), change return rc to continue when "if ( index >= PCI_HEADER_NORMAL_NR_BARS )" and
  "if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )"

v10->v11 changes:
* Add ASSERT_UNREACHABLE() when vpci_remove_registers() fails
* When hide == true, add handlers to let Rebar ctrl be RO.
* Remove Roger's Reviewed-by since patch change.

v9->v10 changes:
v8->v9 changes:
No.

v7->v8 changes:
* Add Roger's Reviewed-by.

v6->v7 changes:
* Change the pointer parameter of cleanup_rebar() to be const.
* Print error when vpci_remove_registers() fail in cleanup_rebar().

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 | 62 ++++++++++++++++++++++++++++++++++------
 1 file changed, 53 insertions(+), 9 deletions(-)

diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 3c18792d9bcd..3651e9613b4c 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -49,6 +49,57 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
     bar->guest_addr = bar->addr;
 }
 
+static int cf_check cleanup_rebar(const struct pci_dev *pdev, bool hide)
+{
+    int rc;
+    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;
+    }
+
+    if ( !hide )
+        return 0;
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+
+    rc = vpci_remove_registers(pdev->vpci, rebar_offset + PCI_REBAR_CAP(0),
+                               PCI_REBAR_CTRL(nbars - 1));
+    if ( rc )
+    {
+        printk(XENLOG_ERR "%pd %pp: fail to remove Rebar handlers rc=%d\n",
+               pdev->domain, &pdev->sbdf, rc);
+        ASSERT_UNREACHABLE();
+        return rc;
+    }
+
+    /*
+     * The driver may not traverse the capability list and think device
+     * supports Rebar by default. So here let the control register of Rebar
+     * be Read-Only is to ensure Rebar disabled.
+     */
+    for ( unsigned int i = 0; i < nbars; i++ )
+    {
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, NULL,
+                               rebar_offset + PCI_REBAR_CTRL(i), 4, NULL);
+        if ( rc )
+        {
+            printk(XENLOG_ERR
+                   "%pd %pp: fail to add Rebar ctrl handler rc=%d\n",
+                   pdev->domain, &pdev->sbdf, rc);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+
 static int cf_check init_rebar(struct pci_dev *pdev)
 {
     uint32_t ctrl;
@@ -97,14 +148,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 +162,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_EXTCAP(REBAR, init_rebar, NULL);
+REGISTER_VPCI_EXTCAP(REBAR, init_rebar, cleanup_rebar);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:50:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:50:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131215.1470402 (Exim 4.92)
	(envelope-from )
	id 1v23EA-0004SA-9U; Fri, 26 Sep 2025 07:50:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131215.1470402; Fri, 26 Sep 2025 07:50: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 1v23EA-0004RR-4X; Fri, 26 Sep 2025 07:50:50 +0000
Received: by outflank-mailman (input) for mailman id 1131215;
 Fri, 26 Sep 2025 07:50: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 1v23E9-0004PV-Bt
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:50:49 +0000
Received: from MW6PR02CU001.outbound.protection.outlook.com
 (mail-westus2azlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c007::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 82df3347-9aad-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 09:50:47 +0200 (CEST)
Received: from CH2PR05CA0031.namprd05.prod.outlook.com (2603:10b6:610::44) by
 DM6PR12MB4170.namprd12.prod.outlook.com (2603:10b6:5:219::20) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9; Fri, 26 Sep 2025 07:50:42 +0000
Received: from DS2PEPF0000343C.namprd02.prod.outlook.com
 (2603:10b6:610:0:cafe::15) by CH2PR05CA0031.outlook.office365.com
 (2603:10b6:610::44) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9182.4 via Frontend Transport; Fri,
 26 Sep 2025 07:50:42 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF0000343C.mail.protection.outlook.com (10.167.18.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Fri, 26 Sep 2025 07:50:42 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 00:50:40 -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: 82df3347-9aad-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NxUIvesYJ7WINpQTTE3gdfDsN61h1JpgpMdEwYlMhMUuCOqHhyIwOtiWItYoYtjDcwQ5P5WRSfk8LcaCtIZYmQcpLvOV08KbaQGFlDTuZAyaxKFZNmf68WjA5XFN4WHmETLKANzRFYdQF1npD7l3IaigNwMNdbYLwiRKWZqs2ZjX/DVUXF1f2zuCj8KyHYb4kt8m2SdPwMy7Nsvl6NQ026fAwJp8XGOc4Y/+iQXBDgwI6BCrXF/f7Lw/4CJD/6dkMVjgduGwMMHkWal7SxCM1Gh02tri2IPE/YSnTpuFQUYYC+NKqrTFxf8/+3XfGZ6iOoz9hGCigamCYMI7PYvT8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=e4ll3zGyqnoS22DY6zoekAmF0Bra4jeTbZ+pxTmziEM=;
 b=r0jZ8PXzeO3EOMtOruWZMdbLj4+GVIywbb96zz3I+tvg0qZBpLZbVe54RazYLkWHpz1ghDTZc73N8FkrbJpTmqiEjxW+bEiDQu7OhgT+N617axPMT5zX22tJnLLi5BcQHMHUwHt2Y+sd/nuUNeW0kERnqD4yasnMfGXAhYh42pagol4blr5m4Vn8ASYPujoxnIksWNCLQPgRgFhS+/nkAsYc2l++oivDLrdbUAs/BOnO8jNqbyu1Kw0zfmswbmb6vh0OIVqxqhmmD0thH+XcHPdi1IZJ8dcyXbTMB4fWc0jwPeyGO+y3oMV45n4xLixVIPgXLAIQclg0+8qbob7cag==
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=e4ll3zGyqnoS22DY6zoekAmF0Bra4jeTbZ+pxTmziEM=;
 b=xyot2SmJjJUMbpbA5KD2T6K+Vk3eCIFyHu+n8XjviNJn/cU53V7Ry/ffVQ53tH/Syt4L/bX0FQJM2eBnyKJaPIl9E+xPcDxIIYqHfsc63thlrB28WUH+I+MNhpopgnjdTZWVTYbrrEAo4oeZ2QgHn5ZJHc5to/TMgr9aRagNzLE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v12 2/3] vpci/msi: Implement cleanup function for MSI
Date: Fri, 26 Sep 2025 15:50:20 +0800
Message-ID: <20250926075021.27967-3-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250926075021.27967-1-Jiqian.Chen@amd.com>
References: <20250926075021.27967-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343C:EE_|DM6PR12MB4170:EE_
X-MS-Office365-Filtering-Correlation-Id: 3a2d4d50-4def-4740-018b-08ddfcd164d0
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?RXNGZnNpSzloQkwzK2xjcEhjdFNvZy9NY0ZzTzR3U0xPMS9ndmdxOUdlNFd1?=
 =?utf-8?B?YkZweTdjSHFib2FaR2VaNkFkbE55QXFzaXdKV1RFUVNmVE5lVkJoQm9OUGtJ?=
 =?utf-8?B?SnhPbVNxakpweGhESkswZnhBWG5xRkdhbFlrN3c1Q0c4OWV2VHM1N1lHWFFL?=
 =?utf-8?B?MFVLcWY5K21aZENCYVVqc2lVWGJ6MGpicDliV1dabktjTFFJSmt2eUtTQkdN?=
 =?utf-8?B?M2pHTit1K2ZXTE51Q1Q4YVJEOUZQdlhEdHgxdC9lczNzeTNvUEJZdnV4Vm9p?=
 =?utf-8?B?bDY2VWIzbmVuWFd3bmhXUThKL29NZ21jQkRISkhLVWlCdTZ1RFNrQnlTRlpv?=
 =?utf-8?B?TGYycFlUNnUxekVhd0NZdEFrblMzU01XOGFzKzF0Z2k5TVQzaXVuSkk4Rk1i?=
 =?utf-8?B?TS90WktGLzhvY3VQUlUvZW43NHlOV2JseUFqVmt0SUpnYStzbVZpVGk5dXQ5?=
 =?utf-8?B?S0dSSGJtMUgvZ0dscmRRNUk2TU9aWW5BSVdWWWNsL0N2RjlSRUMwcDhsWGhO?=
 =?utf-8?B?aHpHaGJsa2VHVkhHNWVPcFpuVGFCbDJKUGRwRWJ0dXlMVGdtUlRFV1pNbjAw?=
 =?utf-8?B?VDFlQlJBVTVWOEJBc3BQdThRTHFVakh4UmUrYkUwQzZaRmpCMDVsWXcrR1RB?=
 =?utf-8?B?NHhITFUyYTZoa09LajlpaXlVRHFyRDRJWEJwWWpIUG45Wm8wMWliU1JQdFM3?=
 =?utf-8?B?Vmk1WEFZK1ZKTHF1WE1MeWk1eWRGdXRPcVJjNmFrOU40cExsb3d4Rjh5NEVF?=
 =?utf-8?B?WEYxVXFGVUJuWlFpUWRuVW10S20vd2xCN010YmRnVGMzUHhES1AzbU5VaWJZ?=
 =?utf-8?B?Ri85V1YvaEkvUjRwaWZ3dDlDUmFHUmJKZ0lIR2FYbzl3bTRYbzBmbGRqNXVl?=
 =?utf-8?B?Y0pSaGZPbVVVb0szaFl2aEJZQkVsNGFwN1BrODVMSDVUSVBCZTNRSG5iei9R?=
 =?utf-8?B?ZGV3a3pIRGUwRzR6SGNpenFVR1p4RGZLNENVU1VLOVJaejM0Y21EeEFSZUZP?=
 =?utf-8?B?aGJzc0J6dlBEckttQ0RLQWIwNVdycFkvZjVTUFNFZWNKeW5aMWV6K3BVd2FV?=
 =?utf-8?B?Qytaa1FuNklhdFpoTWJOMUhpYzN0QS9HN1ZBU0R3eXNNRHVPcWpwSjRuUWZR?=
 =?utf-8?B?Q0hPa2wrZzFkMXlqQ0dWbVRXbXNmYy9uanA3Zkp0alpzRkRVZmF6cUtvUWhW?=
 =?utf-8?B?akhqZFNERFlWWk5paytndnBlUFJKNlpyWHFTRDZVeVpTZVpsRlVETHJHYXE1?=
 =?utf-8?B?QThtVDhIajdjTjBjT21SSXFLY3NlNHZobWJTdXJaaGdzYVNYZXM1b3pWUkFD?=
 =?utf-8?B?Y3o5NEk1WTBGYTFBRm5iL3NXakpZS0pTT0tGVzdWQ1JyNHdJZDNtTnhLTU9x?=
 =?utf-8?B?MGZHRDM3VU9nT0tJMGlVdjJSZURJSVpXdHBOUzJwVDJrbkIwSWpJaWZHZDd6?=
 =?utf-8?B?VUV1LzVPZ1FxM243RUw0OWxvUDU3YWpQNjAxcXpJZmplaUkxdWVHeDA3RWpR?=
 =?utf-8?B?N3Jia2FYdkQ0VVoxWlBxWXF0K2JUQThVcVhVSklxaVNmR3YyVGhBNTViUExk?=
 =?utf-8?B?aHM3dzU2NGhESm1Pd1ZjTXFWWEU5MXpHcy9pNmpCOEpwQkkyYm1idWZ1VjE3?=
 =?utf-8?B?N2JqNUpIdmd5a1BaYXR2RUlycHpCOUhTMnpxM0lhMnUxVklBK1hOZWtyaXA3?=
 =?utf-8?B?dlU1Vy9YV2Z2THNxT1JNendyWEdUd0F0OTN4TzhTckMwQzVvV2t1dlh5L3pr?=
 =?utf-8?B?OU9NV0p5MitYTFVyd2ZZWDhYVjliSi9LVGRHV3M4TndYeVhnc0U4NENlT05S?=
 =?utf-8?B?eloyam1iUlA5RkRkbjBmdXB4N0wzR2M1QVFlNEhZV1MzbXBIWUFOcWZ6bitC?=
 =?utf-8?B?Q1ZNV20ycTd2MXRpbDRoaUdiRE9iT3pMcGNSWGFiemk5eW54NzFNb0x0UGNB?=
 =?utf-8?B?dDkzRXFQQUFyTHgrdzQ5REcybGNEdFd5TVg5TVFnYXlPckEvcHJhbFh0bGR6?=
 =?utf-8?B?Kzlid283Szl0aGFteDRsajNKMHh2cXQzV21wV1lPRlFsSUxRckIwSitDUDVJ?=
 =?utf-8?B?dFRzN2pBV3ZwSXFTUGIxT3l3azJQYmhLYU91R2RkN1JONXpla1oxc1FJVWlZ?=
 =?utf-8?Q?Y7dw=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 07:50:42.5392
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a2d4d50-4def-4740-018b-08ddfcd164d0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343C.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4170

When MSI initialization fails, vPCI hides the capability, but
removing handlers and datas won't be performed until the device is
deassigned. So, implement MSI cleanup hook that will be called to
cleanup MSI related handlers and free it's associated data when
initialization fails.

Since cleanup function of MSI is implemented, delete the open-code
in vpci_deassign_device().

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v11->v12 changes:
* In cleanup_msi(), move "if ( !hide )" above vpci_remove_registers()
  since deassign device will do removing registers itself.
* Read address64 and mask info from hardware since they are not reliable
  when init_msi fails.

v10->v11 changes:
* Add hide paratemer to cleanup_msi().
* Check hide, if false return directly instead of letting ctrl RO.
* Delete xfree(pdev->vpci->msi); in vpci_deassign_device().
* Remove Roger's Reviewed-by since patch change.

v9->v10 changes:
No.

v8->v9 changes:
* Add Roger's Reviewed-by.

v7->v8 changes:
* Add a comment to describe why "-2" in cleanup_msi().
* Given the code in vpci_remove_registers() an error in the removal of
  registers would likely imply memory corruption, at which point it's
  best to fully disable the device. So, Rollback the last two modifications of v7.

v6->v7 changes:
* Change the pointer parameter of cleanup_msi() to be const.
* When vpci_remove_registers() in cleanup_msi() fails, not to return
  directly, instead try to free msi and re-add ctrl handler.
* Pass pdev->vpci into vpci_add_register() instead of pdev->vpci->msi in
  init_msi() since we need that every handler realize that msi is NULL
  when msi is free but handlers are still in there.

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  | 55 ++++++++++++++++++++++++++++++++++++++++-
 xen/drivers/vpci/vpci.c |  1 -
 2 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index c3eba4e14870..181ec902dffb 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -193,6 +193,59 @@ static void cf_check mask_write(
     msi->mask = val;
 }
 
+static int cf_check cleanup_msi(const struct pci_dev *pdev, bool hide)
+{
+    int rc;
+    unsigned int end;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msi_pos = pdev->msi_pos;
+    const unsigned int ctrl = msi_control_reg(msi_pos);
+
+    if ( !hide )
+    {
+        XFREE(vpci->msi);
+        return 0;
+    }
+
+    if ( vpci->msi )
+    {
+        uint16_t control = pci_conf_read16(pdev->sbdf, ctrl);
+        bool address64 = is_64bit_address(control);
+
+        if ( is_mask_bit_support(control) )
+            end = msi_pending_bits_reg(msi_pos, address64);
+        else
+            /*
+            * "-2" here is to cut the reserved 2 bytes of Message Data when
+            * there is no masking support.
+            */
+            end = msi_mask_bits_reg(msi_pos, address64) - 2;
+
+        rc = vpci_remove_registers(vpci, ctrl, end - ctrl);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%pd %pp: fail to remove MSI handlers rc=%d\n",
+                pdev->domain, &pdev->sbdf, rc);
+            ASSERT_UNREACHABLE();
+            return rc;
+        }
+
+        XFREE(vpci->msi);
+    }
+
+    /*
+     * 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);
+    if ( rc )
+        printk(XENLOG_ERR "%pd %pp: fail to add MSI ctrl handler rc=%d\n",
+               pdev->domain, &pdev->sbdf, rc);
+
+    return rc;
+}
+
 static int cf_check init_msi(struct pci_dev *pdev)
 {
     unsigned int pos = pdev->msi_pos;
@@ -270,7 +323,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_CAP(MSI, init_msi, NULL);
+REGISTER_VPCI_CAP(MSI, init_msi, cleanup_msi);
 
 void vpci_dump_msi(void)
 {
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 07c7071d0a17..7aaf015f63d4 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -368,7 +368,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
         rangeset_destroy(pdev->vpci->header.bars[i].mem);
 
     xfree(pdev->vpci->msix);
-    xfree(pdev->vpci->msi);
     xfree(pdev->vpci);
     pdev->vpci = NULL;
 }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:50:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:50:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131216.1470418 (Exim 4.92)
	(envelope-from )
	id 1v23EC-0004u8-N9; Fri, 26 Sep 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 1131216.1470418; Fri, 26 Sep 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 1v23EC-0004u1-JO; Fri, 26 Sep 2025 07:50:52 +0000
Received: by outflank-mailman (input) for mailman id 1131216;
 Fri, 26 Sep 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 1v23EA-0004PV-IS
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:50:50 +0000
Received: from SN4PR0501CU005.outbound.protection.outlook.com
 (mail-southcentralusazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c10d::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 842b5f11-9aad-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 09:50:49 +0200 (CEST)
Received: from CH2PR05CA0004.namprd05.prod.outlook.com (2603:10b6:610::17) by
 LV3PR12MB9403.namprd12.prod.outlook.com (2603:10b6:408:217::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.13; Fri, 26 Sep
 2025 07:50:44 +0000
Received: from DS2PEPF0000343C.namprd02.prod.outlook.com
 (2603:10b6:610:0:cafe::ea) by CH2PR05CA0004.outlook.office365.com
 (2603:10b6:610::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9182.4 via Frontend Transport; Fri,
 26 Sep 2025 07:50:44 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 DS2PEPF0000343C.mail.protection.outlook.com (10.167.18.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Fri, 26 Sep 2025 07:50:44 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 00:50:42 -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: 842b5f11-9aad-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cr21t+ej57ajwAedNluHt0xaBz6MH4WAIwDAo5ckvOEdEwUXkfoiAs3N2tRpLcc8RGxIeoVjFyT/VtTj4iydiCHrPl0GdpBw2E28a8gTWkHl56X/KP8E7MJe4CBtxIDlWkRxEQTecjsmO86Fjs6QaMGheuiU3rK5RXGH4kiLAQJszsl/ExTFGJwR/6+AhSGXrDUjUUvScxW+YXF3P+ImzgNhBbsag14+Y8xbOMqLnayFgTg7DpweXjJ7Dx67h1Sm4MoY2pka7zXAf4hZc+wdc2iN6k7ApgnxU9qUBE69Cjxby5AKeR3aNuGg38G8PicS9v2RXqUvxd2m0BLTdXqQBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MaLJ7+pe1aPBvQLtTo9+A9wNYi42Nr55akKCwiM69gw=;
 b=kU+T8MNkYUOHUcjmIKkp65H2yE1dk+1aTTctSSNvF4yTIOezAMHOHXBUP3XpPrP0qt9vlN1bh8BWrkBEl3YfbOAT59icdPKFxRQhfaGM0mh23eJSTJ1EncTICFyBFMAke3avYEVW77DAdJH2mtV0w0jMf2arWqPB0Dj5X1oMHI+GnRmC9OGnZjg9e1ovt8xr8q54+pL3QLP2q1H++yD02UzzbHpXq9ZfT14D7w3ZBjjaeyvbZHJkGXUbEiqNuMg/6u8TvKnBKtqiHeIhBV24Reb/JmJWx4Z1D2dLCe/m5PRoGloIdQ38R8VlyVJaQLaMC/uPQFUXX5u6jAY9ESbKnQ==
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=MaLJ7+pe1aPBvQLtTo9+A9wNYi42Nr55akKCwiM69gw=;
 b=amhUsKrADTz3gJKQHLszK5Ba6/Bdi+eEb+iWNKaZDrVfMTAkfPFP8/Gvs+5iCsWWbbouoJX6hdT3F5AAYw+MX2zWBYgu+yhfFIKA0JfjQ7HWESq+CQwKmCnOHuRLi7Fo/5Gyn5tSEvLUJ9WkkumhykEHW5/4OY+ibYHq9/BeTts=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v12 3/3] vpci/msix: Implement cleanup function for MSI-X
Date: Fri, 26 Sep 2025 15:50:21 +0800
Message-ID: <20250926075021.27967-4-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250926075021.27967-1-Jiqian.Chen@amd.com>
References: <20250926075021.27967-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: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343C:EE_|LV3PR12MB9403:EE_
X-MS-Office365-Filtering-Correlation-Id: 4e354947-da3b-4df5-df94-08ddfcd165b5
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?aXdGTThpSGpYNG1oR0g1NUdJMzgzZlUrMXZML2dsbkhoSVc1aG5DMjhBWVlG?=
 =?utf-8?B?T25rNWdUVkN3dTBuQUU4bytJWmx0czZITHNkQTBGNEROaUdpbDZ0NXhJNTNZ?=
 =?utf-8?B?NWFwb0RpS053ZWN4S1h2SXRxNzJVNmpicnhaSnV4MGRsNjUwbVZReDlTOFlr?=
 =?utf-8?B?U2NYaUtoNExHbGJrZ24rTnM1Z2tPbEVPeDZ2Mjd0czNEeVBPbGxSR3AwM1RB?=
 =?utf-8?B?N2FxUDBaRGl1NVBOQVpSVE04NDlXcUtyZS9maFF4Z2plejRiSytaaWE5MG5w?=
 =?utf-8?B?WTNldnhDQkk1SDRsWXVmaUpybDEzU1VkcW9QZWRFd29UeWhyUDg4dGZEL0Ur?=
 =?utf-8?B?TjNKL1NqcFRHeXVJVmV1cTlIaXVhOTc5QzNIK20xbUJuWmNoQ3dDb05qZFhR?=
 =?utf-8?B?SWpycE42eVRKZk1nTGRGSGxlMzgvd2JWMnoxYnZML0pPZlJHY3VPcjM1ZzNI?=
 =?utf-8?B?aVRrTFAzVUVyWmRBRkZwd2tyZFNDRWFqQXA5Y2NNQ1ZZb1QwNzJaWVVHQWlQ?=
 =?utf-8?B?UFN6Qjl6b1krYklXSG5EY0N5VTJmWlZkYTVNVXVwSGJyZERXeGQzQ2ZrNWhZ?=
 =?utf-8?B?dExjY3RKdkIwYmhldnNXYVFHcDA1WndkamVhcDlTWXFUUHJrRVptRG5kQk1G?=
 =?utf-8?B?c2RFSy9RbEovMU9oaGxBV3BNY2htZGVuc000Ly96aFQ3U3JPMDR2dFFlRG52?=
 =?utf-8?B?YU05NmRRdEVKTEZ4VVQzc0doTkRKekhYTnBwWW5jOENaaFNxeHcwc05UUCtT?=
 =?utf-8?B?K2FBanlhRThWaGpkUVJRSGNGMlJFWEZmQTNIQ1VhWWlNQit3MzAwbzdGSDRF?=
 =?utf-8?B?R3poakNVQmFoNkp5MEJad3duc2Q2NGRtcWJtZDJzaFN6OEZrTzFpamkraHBi?=
 =?utf-8?B?MmRHV3dIbFY1TzRyaDhnVGZqYnlVcTNuNmRzYmN1TmpSbDdHNVhXd1Q0T1Fa?=
 =?utf-8?B?ck9SY0JkcENaV2ZTT2dZTzNNd0RpVmFEM0V5T2dDZ2VHQXJkL3JPY1l6TjQv?=
 =?utf-8?B?NG9pYlkzVThNSXJPd1BqMVFiV0xBSlBzOGJRVnlncVQ5am9USWFCaGRPeGx4?=
 =?utf-8?B?WEt1OVV6c1YvWkltV1J3d2FNRWVlcDhaVTdjaC9qcS9jbnlERlBESkpzMkFj?=
 =?utf-8?B?Y2ltN01PVVJJNlR2KzAveUJlcGh3a3hmdzRkeVFuL2ZIb3NGaDd5VEdUUklx?=
 =?utf-8?B?Y01pQ1M2eUdSckwwa0EzRWdGU3FyT3J5bEIrUWZsR0szRVZlMU90alhqWWZN?=
 =?utf-8?B?V3JCdG4yZWF1YmtadHNpT3BuNkxOQTJ2eTFpNkNGV3NpVkVtSnZ3T1hRQW1y?=
 =?utf-8?B?T0N6aGx1aTZtNHhWNGxQVVBZYW16QStZOURzbjlZdGxTalUzYzFMWHlXU05j?=
 =?utf-8?B?K0xURDZrVTEzTDF1MkR3aDVJNGlsNXlQMzNZd0luMkNaUTZ0NnJvUnJuVkVC?=
 =?utf-8?B?YWlZOHcva1ZFOURNTWRpeE9jZXc2QkEwNXJ2K09EYXRWd0oyWW9NQ2VOa25s?=
 =?utf-8?B?aHZTZG90bkN3aTM5Q1NWODUzUzhsYnZ1Zm1mWVZGU1lOOWdZUFZwVjVpY0c0?=
 =?utf-8?B?WjY3dCtQRUJGckVpcWJWMkdldFZWZHk3TXpTTGc5MzdWQWhIVS9nWEtTMkpq?=
 =?utf-8?B?bkYzMFBwUmxreTVlMXFzbndtWnRldFd3dWVTbWlMckg4U0tVMDZVdWpTNXJ1?=
 =?utf-8?B?WHkwTFFOVW42NHdkZkdVcUVzdUdVTXdxaXEvY1B6TCt6dHFsRVZTWXRoeWQ2?=
 =?utf-8?B?OXprYUF4d21QU0JIaDRaR05UcUpzajNGcUJqYkNzUG00MCtNV0xETGd2Um5l?=
 =?utf-8?B?dDdveXJHYmxLWlFBdTZ2L0Nia3E3N2VPRy9nNkpFaWhESTZHVVZJVm05RzhU?=
 =?utf-8?B?NnZKbENHaTJLTmN6cjFMOHFjdXRLeloxWVZsd3FuYUNINTBRN1pWdHlHUDNr?=
 =?utf-8?B?bWg1aldsVm1NMUVibXd6STNWNzYzVFVMQldtcmVCYWFPaTNibnA2eUlza3lB?=
 =?utf-8?B?RHZCZmFhL0NZV1hzdEwrbnJpUnVNUGJRRFpmSUNIb01mWlVnMHBhRnVhU0tU?=
 =?utf-8?Q?2VrcqD?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 07:50:44.0458
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e354947-da3b-4df5-df94-08ddfcd165b5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343C.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9403

When MSI-X initialization fails, vPCI hides the capability, but
removing handlers and datas won't be performed until the device is
deassigned. So, implement MSI-X cleanup hook that will be called
to cleanup MSI-X related handlers and free it's associated data when
initialization fails.

Since cleanup function of MSI-X is implemented, delete the open-code
in vpci_deassign_device().

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v11->v12 changes:
* In cleanup_msix(), move check "if ( !hide )" above vpci_remove_registers().
* Remove the check "!pdev->msix_pos" since current callers already do that.

v10->v11 changes:
* Move calling all cleanup hook in vpci_deassign_device() out of this patch.
* Add hide parameter to cleanup_msix().
* Check hide, if it is false, return directly instead of letting ctrl RO.

v9->v10 changes:
* Call all cleanup hook in vpci_deassign_device() instead of cleanup_msix().

v8->v9 changes:
* Modify commit message.
* Call cleanup_msix() in vpci_deassign_device() to remove the open-code to cleanup msix datas.
* In cleanup_msix(), move "list_del(&vpci->msix->next);" above for loop of iounmap msix tables.

v7->v8 changes:
* Given the code in vpci_remove_registers() an error in the removal of
  registers would likely imply memory corruption, at which point it's
  best to fully disable the device. So, Rollback the last two modifications of v7.

v6->v7 changes:
* Change the pointer parameter of cleanup_msix() to be const.
* When vpci_remove_registers() in cleanup_msix() fails, not to return
  directly, instead try to free msix and re-add ctrl handler.
* Pass pdev->vpci into vpci_add_register() instead of pdev->vpci->msix in
  init_msix() since we need that every handler realize that msix is NULL
  when msix is freed but handlers are still in there.

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 | 44 ++++++++++++++++++++++++++++++++++++++++-
 xen/drivers/vpci/vpci.c |  8 --------
 2 files changed, 43 insertions(+), 9 deletions(-)

diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 54a5070733aa..38a14c0ded05 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -655,6 +655,48 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
     return 0;
 }
 
+static int cf_check cleanup_msix(const struct pci_dev *pdev, bool hide)
+{
+    int rc;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msix_pos = pdev->msix_pos;
+
+    if ( vpci->msix )
+    {
+        list_del(&vpci->msix->next);
+        for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
+            if ( vpci->msix->table[i] )
+                iounmap(vpci->msix->table[i]);
+
+        XFREE(vpci->msix);
+    }
+
+    if ( !hide )
+        return 0;
+
+    rc = vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "%pd %pp: fail to remove MSIX handlers rc=%d\n",
+               pdev->domain, &pdev->sbdf, rc);
+        ASSERT_UNREACHABLE();
+        return rc;
+    }
+
+    /*
+     * The driver may not traverse the capability list and think device
+     * supports MSIX by default. So here let the control register of MSIX
+     * be Read-Only is to ensure MSIX disabled.
+     */
+    rc = vpci_add_register(vpci, vpci_hw_read16, NULL,
+                           msix_control_reg(msix_pos), 2, NULL);
+    if ( rc )
+        printk(XENLOG_ERR "%pd %pp: fail to add MSIX ctrl handler rc=%d\n",
+               pdev->domain, &pdev->sbdf, rc);
+
+    return rc;
+}
+
 static int cf_check init_msix(struct pci_dev *pdev)
 {
     struct domain *d = pdev->domain;
@@ -710,7 +752,7 @@ static int cf_check init_msix(struct pci_dev *pdev)
      */
     return vpci_make_msix_hole(pdev);
 }
-REGISTER_VPCI_CAP(MSIX, init_msix, NULL);
+REGISTER_VPCI_CAP(MSIX, init_msix, cleanup_msix);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 7aaf015f63d4..3c9bebcbe977 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -356,18 +356,10 @@ void vpci_deassign_device(struct pci_dev *pdev)
         xfree(r);
     }
     spin_unlock(&pdev->vpci->lock);
-    if ( pdev->vpci->msix )
-    {
-        list_del(&pdev->vpci->msix->next);
-        for ( i = 0; i < ARRAY_SIZE(pdev->vpci->msix->table); i++ )
-            if ( pdev->vpci->msix->table[i] )
-                iounmap(pdev->vpci->msix->table[i]);
-    }
 
     for ( i = 0; i < ARRAY_SIZE(pdev->vpci->header.bars); i++ )
         rangeset_destroy(pdev->vpci->header.bars[i].mem);
 
-    xfree(pdev->vpci->msix);
     xfree(pdev->vpci);
     pdev->vpci = NULL;
 }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 07:58:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 07:58:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131264.1470429 (Exim 4.92)
	(envelope-from )
	id 1v23Lc-0006jz-GE; Fri, 26 Sep 2025 07:58:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131264.1470429; Fri, 26 Sep 2025 07:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v23Lc-0006js-Bf; Fri, 26 Sep 2025 07:58:32 +0000
Received: by outflank-mailman (input) for mailman id 1131264;
 Fri, 26 Sep 2025 07:58:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v23Lb-0006jm-43
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 07:58:31 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 971aee1a-9aae-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 09:58:30 +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 E95264EEBC4D;
 Fri, 26 Sep 2025 09:58:28 +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: 971aee1a-9aae-11f0-9d14-b5c5bf9af7f9
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=1758873509;
	b=iPccSyZWojS+W56+gd/B+janPrQ9ZUlj5+1f6BUJuTH89PPoxT7U8eCEjIa7BNH1o5iF
	 8mUrauwUkiq/0S2RdK2wJqzfyhL2IjSslFv3Uro99Iqx+KQ1hfSFk0+Y2NeBKqqtOpIEn
	 UoGg2GaAKK2uN2VAStod5XfMS+TknYMO2VvWP3FhyNtX0DRCMGrKlIk9rmae5kEQ0KQrG
	 7xrxu2zMuAVD+pXJWwWf0JjKqXR0h9tOZhRJ8jiwOtqj/YSVMI4mQtLOAmKbDgeakfUv+
	 gYijQzlr4FEkawaV1Cipl6m3q5+QpqAPIP2gIx8v40p9ql6dNMncMRh4gA3QmR6INOMYW
	 LKSv5dv7FMpAq3mFAOwHJKRGphYEoBNhIOz4WvJHpGKhfIX8Tfszy+o3IoyEipLa4VTw5
	 +g0MPxRUqmBJXixY8Mid0FpwcQtjCmK3qcxTXuc29phH0q7yB/ismOJqmTKBtwgGeAcxb
	 ySWMtnSRfVKOZgkqeUZ+QFB7Qy9UZdApznXaQQZGU87RkWPRFgScLu+LP5W1cdkz9L1p3
	 DQZmliqFxkZspOCHBhg9+79JehcCwXnfhIgRpf6SZV37fiaSpyWKpI92y8s9VD9iVmYB3
	 FrkKxsg8lLRxiwyjY0kehymG4qqIfRujj/9CiKuQVtoepAD1fM4wSWyBhqszK08=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1758873509;
	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=mM1vYtKxLsTOkPWlKHfseeZ/b++Q5ticVBzhPq2YdsA=;
	b=uo3eqjuJkRIhQUVf5f83OkJU8Dtp9QquYC29NQHugfycliArZkaF07WCwqLW5rlPxZmC
	 byCZS17iL01ARorqUPc8GkrGXjetlcTgCswLcYyxoVnH++jkZgOzmHl4Zxp3oqqh1ICbj
	 uDgLz2YBbpene55teRdifnH5AMP8DZTUe1iUoEbkzbTdoGgEKXqCZ3JRdIb7ecTlvthOb
	 0v1bASdDVl4pZIIZNrNYw7z3XSLIRFh5a5uD2pYp9ey+bhvmM52ExBBwcOr8sYkLZGlBm
	 A4jdL58KFB/ocOhH4tRMQx38JuvxPqJGc8683Q2GdUnvtgfhzQO6Yutf8wK+lQRrqCN00
	 omnsDpCVUisRv7qW5ddTXQx6GncCaE5Zt+KxhJZMR6W0g4C/vbopxhT6RMJ3BLwWc5VuE
	 MxwNln1LgDTjgql9QMKUMzbFIoWsPnHDTItQOsibPgTMtEGqTIw2NJ/i9p1tChEnqZZXD
	 t5FhWv8xy0r1CF73aQzsUfduu01cVcipU5PChXsfijv6XbVJzHETnVnENkxxFyqZo4g8+
	 HzrYKHa8AkXuueCZU81qP1NoVS4/lEA8OhhkWWkgU1KbrYAsA6lm2Slrd4h3/BlOW/+8k
	 ZZ+4cfvStxZV5lqAd7eTpwZ9KjnZSGXKbsjZYCTDvMWAQQs1MY6dQgYVqg4mEIs=
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=1758873509; bh=/moFs4Tb6+CfXCTLNjYtX5YtI/NGoevVaImGhrOIhhw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=ikTEQS06sVRFXB5gxZ4csyZJkZlKncOzkwFB20zlsgLuQJTQYC687JZy90HsgwAA1
	 RlYwpf6mD2vWaEjhF7ZIIU6foIJEmUgf0SdBAt052vQPclkkqNO4pY9aB/W55lCzq9
	 kyPmMbuvwcJ6sb5dKPzWAgypdOFugo/yh/PcEld7pVVLSKQfiBeKRNFSNsYRqP3Rhl
	 TJtuUjou/Ys9yEJ8jwtD2iSwY+IsqvMG5JIrdboRyKcgzLoX+5eUE5JEMsXEv1xOJG
	 gETaBEzpJPQsenmbO1PWrVee9/QNj9lS2QrbgnySmQKeFS1uNZ6vEnAkoDkzbv7Wdz
	 KqnY9yVbEuD3A==
MIME-Version: 1.0
Date: Fri, 26 Sep 2025 09:58:28 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: Dmytro Prokopchuk1 , Doug Goldstein
 , Stefano Stabellini , Andrew
 Cooper , Anthony PERARD
 , Michal Orzel , Julien
 Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] misra: consider conversion from UL or (void*) to
 function pointer as safe
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-09-26 08:46, Jan Beulich wrote:
> On 25.09.2025 20:37, Dmytro Prokopchuk1 wrote:
>> On 9/25/25 16:25, Jan Beulich wrote:
>>> On 25.09.2025 10:04, Dmytro Prokopchuk1 wrote:
>>>> --- a/docs/misra/deviations.rst
>>>> +++ b/docs/misra/deviations.rst
>>>> @@ -366,11 +366,22 @@ Deviations related to MISRA C:2012 Rules:
>>>>        - Tagged as `safe` for ECLAIR.
>>>> 
>>>>      * - R11.1
>>>> -     - The conversion from a function pointer to unsigned long or 
>>>> (void \*) does
>>>> +     - The conversion from a function pointer to unsigned long or 
>>>> '(void *)' does
>>>>          not lose any information, provided that the target type has 
>>>> enough bits
>>>>          to store it.
>>>>        - Tagged as `safe` for ECLAIR.
>>>> 
>>>> +   * - R11.1
>>>> +     - The conversion from unsigned long or '(void *)' to a 
>>>> function pointer is
>>>> +       safe because it relies on both ABI definitions and compiler 
>>>> implementations
>>>> +       supported by Xen which define consistent and compatible 
>>>> representations
>>>> +       (i.e., having the same size and memory layout) for '(void 
>>>> *)', unsigned
>>>> +       long, and function pointers, enabling safe conversions 
>>>> between these types
>>>> +       without data loss or corruption. The compile-time assertions 
>>>> (BUILD_BUG_ON
>>>> +       macro) is integrated into 'xen/common/version.c' to confirm 
>>>> conversions
>>>> +       compatibility across all target platforms.
>>> 
>>> As you use (and mean) plural, s/is/are/ ? I also think the "The" at 
>>> the start
>>> of the sentence wants dropping.
>> Ok.
>> 
>>> 
>>> Further, why this very dissimilar wording compared to what's said 
>>> about
>>> conversions _from_ function pointer types?
>> Do you mean the following wording should be placed instead (to be
>> similar with previous one)?
>> 
>> "Conversions from unsigned long or (void *) to a function pointer do 
>> not
>> lose any information, provided that the source type has enough bits to
>> restore it."
>> 
>> And wording about "ABI, compiler..." should be only in commit message?
> 
> Perhaps.
> 
>>> And then ...
>>> 
>>>> --- a/xen/common/version.c
>>>> +++ b/xen/common/version.c
>>>> @@ -217,6 +217,17 @@ void __init xen_build_init(void)
>>>>   #endif /* CONFIG_X86 */
>>>>   }
>>>>   #endif /* BUILD_ID */
>>>> +
>>>> +static void __init __maybe_unused build_assertions(void)
>>>> +{
>>>> +    /*
>>>> +     * To confirm conversion compatibility between unsigned long, 
>>>> (void *)
>>>> +     * and function pointers for all supported architectures.
>>>> +     */
>>>> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>>> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>>>> +}
>>> 
>>> ... I'm unconvinced checking merely the sizes is sufficient. On 
>>> architectures
>>> involving function descriptors (e.g. ia64) converting in this 
>>> direction is
>>> safe only if earlier on the value was obtained as the result of a 
>>> conversion
>>> in the opposite direction (and all of this within a single component, 
>>> which
>>> of course is guaranteed for Xen).
>> As I know mainline Xen doesn't support IA-64 currently (this support 
>> was
>> dropped).
>> Why we still need to mention about IA-64 here?
> 
> Because I needed to use an example I know. Aiui there are other 
> architectures
> which use function descriptors (or alike).
> 
>> Anyway...
>> Yes, this deviation wouldn't work with architectures where the
>> representation of a function involves more than just its address (e.g.
>> IA-64). If not proved that such conversion is symmetric.
>> 
>> Probably, additional guard may be added below to exclude such
>> architectures (e.g. IA-64):
>> 
>> static void __init __maybe_unused build_assertions(void)
>> {
>> #if defined (__IA64__) || defined (__ia64__)
>> #error "Conversions to function pointer isn't safe -  architecture 
>> uses
>> function descriptors."
>> #endif
> 
> Well, no, I didn't mean to ask that you add dead code.
> 
>>      BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>      BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>> }
>> 
>> But if someone really will try to run Xen on such platform, the build
>> will fail.
>> 
>> Or just mention explicitly that other architectures (e.g., IA-64) 
>> might
>> not be safe for such conversions?
> 
> My main point really is that once again I wonder how convincing such an
> argument would be to assessors, when it's clearly not generic (yet 
> being
> worded and the checking coded as if it was).
> 
> Jan

Well, it is true that the intended scope of those deviations is for the 
architectures and compilers that are subject to the analysis, because 
adding a new architecture or compiler to the mix would mean that all the 
assumptions need to be re-evaluated for that compiler/arch (this is an 
IDB in the first place, so it is unlikely that a general statement can 
be made). Perhaps the BUILD_BUG_ON should be limited to these 
arch-es/compilers, so that there is little doubt about the intended 
motivation of the check.

-- 
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 Sep 26 08:05:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 08:05:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131288.1470439 (Exim 4.92)
	(envelope-from )
	id 1v23Rt-0000SK-Bi; Fri, 26 Sep 2025 08:05:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131288.1470439; Fri, 26 Sep 2025 08: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 1v23Rt-0000SD-7S; Fri, 26 Sep 2025 08:05:01 +0000
Received: by outflank-mailman (input) for mailman id 1131288;
 Fri, 26 Sep 2025 08:05: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 1v23Rs-0000RE-1P
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 08:05:00 +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 7f1eb5b4-9aaf-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 10: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 8909B6B062;
 Fri, 26 Sep 2025 08:04:57 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6A8CA1373E;
 Fri, 26 Sep 2025 08:04:57 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id COQjGClJ1mibbgAAD6G6ig
 (envelope-from ); Fri, 26 Sep 2025 08: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: 7f1eb5b4-9aaf-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758873897; 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=4sQh/CiinmBC59T4F3kvNbGZCHfl6iTQQwPV43dmacA=;
	b=PU6NGCkqodSIIY9wm2kn/FnRtDLysmv5gDbUt9EcG2e6y2T+Pc+CTiert36E8fayjBMCtI
	3ZQclQxi/hGqDoeX5T6PrgnYc9w/J5Kn9fGT/TKpVy5cu8666mDbIbDM2uOlUUumpMVoQ3
	TNW7FDXS6iu89jYFdcM+VoTpV10BLCM=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=PU6NGCkq
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758873897; 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=4sQh/CiinmBC59T4F3kvNbGZCHfl6iTQQwPV43dmacA=;
	b=PU6NGCkqodSIIY9wm2kn/FnRtDLysmv5gDbUt9EcG2e6y2T+Pc+CTiert36E8fayjBMCtI
	3ZQclQxi/hGqDoeX5T6PrgnYc9w/J5Kn9fGT/TKpVy5cu8666mDbIbDM2uOlUUumpMVoQ3
	TNW7FDXS6iu89jYFdcM+VoTpV10BLCM=
Message-ID: <9a2c77f3-fbdf-4d8a-8793-7d75f9ffb538@suse.com>
Date: Fri, 26 Sep 2025 10:04:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Question] Unexpected growth of nr_cpu in `credit` Xen scheduler?
To: Igor Korkin , xen-devel@lists.xenproject.org
References: 
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="------------xKkZs2uT0YZrbDtpkOISbGHW"
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 8909B6B062
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TAGGED_RCPT(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:dkim,suse.com:mid]
X-Spam-Score: -5.41

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------xKkZs2uT0YZrbDtpkOISbGHW
Content-Type: multipart/mixed; boundary="------------HJjWm7veJp2SSCfsX1IZIhOI";
 protected-headers="v1"
From: Juergen Gross 
To: Igor Korkin , xen-devel@lists.xenproject.org
Message-ID: <9a2c77f3-fbdf-4d8a-8793-7d75f9ffb538@suse.com>
Subject: Re: [Question] Unexpected growth of nr_cpu in `credit` Xen scheduler?
References: 
In-Reply-To: 

--------------HJjWm7veJp2SSCfsX1IZIhOI
Content-Type: multipart/mixed; boundary="------------U6BH36iCPGn8AA4Wv6XOlzll"

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

T24gMjYuMDkuMjUgMDk6MTcsIElnb3IgS29ya2luIHdyb3RlOg0KPiBIaSBhbGwsDQo+IA0K
PiBJJ20gb2JzZXJ2aW5nIGEgc3RlYWR5IGFuZCBhYm5vcm1hbCBpbmNyZWFzZSBpbiB0aGUg
YG5yX2NwdWAgdmFsdWUNCj4gcmVwb3J0ZWQgYnkgdGhlIGBjcmVkaXRgIFhlbiBzY2hlZHVs
ZXINCj4gKHZpc2libGUgdmlhIGBzdWRvIHhsIGRtZXNnOyBzdWRvIHhsIGRlYnVnLWtleXMg
cmApLg0KPiANCj4gDQo+IFRoaXMgYmVoYXZpb3Igb2NjdXJzIGNvbnNpc3RlbnRseSB3aGVu
IHRoZSBzeXN0ZW0gaXMgc3ViamVjdGVkIHRvDQo+IGhlYXZ5IHN5bnRoZXRpYyBsb2FkIChl
LmcuLCBtdWx0aXBsZSBWTXMgcnVubmluZyBzdHJlc3Mgd29ya2xvYWRzIHRoYXQNCj4gZnVs
bHkgc2F0dXJhdGUgdkNQVXMpLg0KPiBPdmVyIHRpbWUsIGBucl9jcHVgIGdyb3dzIGZhciBi
ZXlvbmQgdGhlIGFjdHVhbCBudW1iZXIgb2YgcGh5c2ljYWwgb3INCj4gbG9naWNhbCBDUFVz
ICg0OCBpbiBvdXIgY2FzZSksIGFuZCB0aGlzIGNvcnJlbGF0ZXMgd2l0aCBub3RpY2VhYmxl
DQo+IHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLCBlc3BlY2lhbGx5IHVuZGVyIGhpZ2ggVk0g
ZGVuc2l0eS4NCg0KQ2FuIHlvdSBwbGVhc2Ugc2hhcmUgdGhlIHJlbGF0ZWQgb3V0cHV0PyBF
c3BlY2lhbGx5IG9uZSBpbnN0YW5jZSBvZg0KdGhlICJ4bCBkZWJ1Zy1rZXlzIHI7IHhsIGRt
ZXNnIiBiZWZvcmUgdGhlIHRlc3QgaXMgc3RhcnRpbmcsIGFuZCBvbmUNCndpdGggdGhlIHdy
b25nIG51bWJlciBvZiBjcHVzIGluIHRoZSBkYXRhLg0KPiBXZeKAmXJlIHJ1bm5pbmcgb24g
YSBkdWFsLXNvY2tldCB4ODZfNjQgc2VydmVyICgyIMOXIDEyLWNvcmUgSW50ZWwgWGVvbg0K
PiBTaWx2ZXIgNDMxMCBDUFVzIHdpdGggSHlwZXItVGhyZWFkaW5nLCB0b3RhbCA0OCBsb2dp
Y2FsIENQVXMpIHVuZGVyDQo+IFhlbiA0LjE5Lg0KPiANCj4gSXMgdGhpcyBncm93dGggb2Yg
YG5yX2NwdWAgZXhwZWN0ZWQgaW4gdGhlIGNyZWRpdCBzY2hlZHVsZXI/DQo+IElmIG5vdCwg
aXQgbWF5IGluZGljYXRlIGEgYnVnIGluIENQVSBhY2NvdW50aW5nIG9yIHJ1bnF1ZXVlIG1h
bmFnZW1lbnQNCj4gdGhhdCB3YXJyYW50cyBmdXJ0aGVyIGludmVzdGlnYXRpb24uDQo+IA0K
PiANCj4gRW52aXJvbm1lbnQgZGV0YWlsczoNCj4gLSB4ZW5fdmVyc2lvbiAgICAgICAgICAg
IDogNC4xOS4wLTUuMjUuMC4zODQzMQ0KPiAtIHhlbl9jYXBzICAgICAgICAgICAgICAgOiB4
ZW4tMy4wLXg4Nl82NCBodm0tMy4wLXg4Nl8zMg0KPiBodm0tMy4wLXg4Nl8zMnAgaHZtLTMu
MC14ODZfNjQxDQo+IC0geGVuX3NjaGVkdWxlciAgICAgICAgICA6IGNyZWRpdA0KPiAtIEhh
cmR3YXJlIDogRHVhbC1zb2NrZXQgSW50ZWwgWGVvbiBTaWx2ZXIgNDMxMCBAIDIuMTBHSHog
KDEyDQo+IGNvcmVzL3NvY2tldCwgSFQgZW5hYmxlZCwgNDggbG9naWNhbCBDUFVzKQ0KPiAt
IE5VTUEgbm9kZXMgOiAyDQo+IC0gRG9tMCBrZXJuZWwgOiBEZWJpYW4gNi4xLjE0Ny0xICg2
LjEuMC0zOC1hbWQ2NCwgU01QIFBSRUVNUFRfRFlOQU1JQykNCj4gLSBucl9jcHVzICAgICAg
ICAgICAgICAgIDogNDgNCj4gLSBucl9ub2RlcyAgICAgICAgICAgICAgIDogMg0KPiAtIHJl
bGVhc2UgICAgICAgICAgICAgICAgOiA2LjEuMC0zOC1hbWQ2NA0KPiAtIHZlcnNpb24gICAg
ICAgICAgICAgICAgOiAjMSBTTVAgUFJFRU1QVF9EWU5BTUlDIERlYmlhbiA2LjEuMTQ3LTEg
KDIwMjUtMDgtMDIpDQo+IC0gbWFjaGluZSAgICAgICAgICAgICAgICA6IHg4Nl82NA0KPiAt
IG5yX25vZGVzICAgICAgICAgICAgICAgOiAyDQo+IC0gY29yZXNfcGVyX3NvY2tldCAgICAg
ICA6IDEyDQo+IC0gdGhyZWFkc19wZXJfY29yZSAgICAgICA6IDINCj4gLSBjcHVfbWh6ICAg
ICAgICAgICAgICAgIDogMjEwMC4wMDANCj4gLSB2aXJ0X2NhcHMgICAgICAgICAgICAgIDog
cHYgaHZtIGh2bV9kaXJlY3RpbyBwdl9kaXJlY3RpbyBoYXAgc2hhZG93DQo+IGlvbW11X2hh
cF9wdF9zaGFyZSB2bXRyYWNlIGdudHRhYi12MSBnbnR0YWItdjINCj4gLSB0b3RhbF9tZW1v
cnkgICAgICAgICAgIDogMTMwNzI0DQo+IC0gZnJlZV9tZW1vcnkgICAgICAgICAgICA6IDU0
MDY0DQpQbGVhc2Ugc2hhcmUgdGhlIGNvbXBsZXRlICJ4bCBpbmZvIiBvdXRwdXQsIGluY2x1
ZGluZyB0aGUgeGVuIGNvbW1hbmQgbGluZS4NCg0KQXJlIHRoZXJlIGFueSBjcHVwb29scyBp
bnZvbHZlZD8gQW55IGNwdSBob3RwbHVnIG9wZXJhdGlvbnM/DQoNCg0KSnVlcmdlbg0K
--------------U6BH36iCPGn8AA4Wv6XOlzll
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-----

--------------U6BH36iCPGn8AA4Wv6XOlzll--

--------------HJjWm7veJp2SSCfsX1IZIhOI--

--------------xKkZs2uT0YZrbDtpkOISbGHW
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/Ey8FAmjWSSgFAwAAAAAACgkQsN6d1ii/Ey/L
gggAk2YPNJHDmOexGlb/FBwKOtgKujRy+LA/0tVewOzWTkqm4MdSbhphBzUx2FixhU+dHCYilIV/
IOtJ7P8W+Ecr/E8VeCgOIC8wA8RB/HG7czbMWyJW0zIHNAinNRVNCdMImMbgqcrptmNrL+H7mcVo
sDMQYBxURIPJiF1xzFzztYUHEcWlimhPay0LDvccZJ9gBDyprlCpYKblx4PbFQmbsak3pYBulNI8
DATnud0oS7SODqtPJseDnNUjbv58LThV9VoJOcwCjFSNTvvib3qPNYlAJ4dS+NB7U5JLYxrtTIvf
uxssxrYFUIGs1VG0L4hUkvykcgZ5Rvt+STc0I7Q2GQ==
=454j
-----END PGP SIGNATURE-----

--------------xKkZs2uT0YZrbDtpkOISbGHW--


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 08:17:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 08:17:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131303.1470447 (Exim 4.92)
	(envelope-from )
	id 1v23dz-0002ki-BF; Fri, 26 Sep 2025 08:17:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131303.1470447; Fri, 26 Sep 2025 08: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 1v23dz-0002kb-8X; Fri, 26 Sep 2025 08:17:31 +0000
Received: by outflank-mailman (input) for mailman id 1131303;
 Fri, 26 Sep 2025 08:17:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v23dy-0002kV-8i
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 08:17:30 +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 3e1c485c-9ab1-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 10:17:29 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b2bddecc51aso277614566b.2
 for ; Fri, 26 Sep 2025 01:17:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b37b3b46ba0sm118850166b.2.2025.09.26.01.17.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 01:17: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: 3e1c485c-9ab1-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758874648; x=1759479448; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Cs2I1+OSxuF8Sr6UbB64Dw+Dzy+1s8GX9PeJCHm1Yug=;
        b=X9yyzY8EXinaZ4FFyVBH4o0SioRZ3NLGz9pdkyhssbH1jyHHRyR1Rpqv1FXHRSwHGg
         l+aMKEECPPGNDhMiiozolNDNOuhIBXCW7832OSuVS3DlZn4J6a1O78tk9HqXMqZ+0pJr
         BLlLqTrwBvqCIuQ1tF79NXd1j3rUQK9qdx4AuSb+lzWWyqRlw8Ma56okY3oqjpSjtpHz
         4jhvxKzHlGbTOVZy03UFTqERjW2dP1A1G4RYerwy1AkKo6CKYH6YIltkNQpQayALsN6y
         ZGj5ns3lW3GKpBL+r51XY2wuSpH5CbqPplMxFL2if2MAjJb6I/uSpxtBiB6fm7E0PQkJ
         pAzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758874648; x=1759479448;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Cs2I1+OSxuF8Sr6UbB64Dw+Dzy+1s8GX9PeJCHm1Yug=;
        b=CsKQqOyej57J3HNT87MW67BAzvhwCAYOfZXByeqp1iMZWzYwatUqOXs4+x1kY57yLn
         6I85mUsZU2zJVQmw7ig8Jl+jIbJ/cXaPNvN9X5eD0w0es4VFWtaO70pUPsBIkmd/fkV5
         uzVm3XcPgA7QdI6jzQ8FWAP4ap1T4UboJpfJzUj9OHSeIgLNRDnSst1Q2APhS11CJHfO
         L6C0Fj3bb7HUR7xTmn2iDXyU/dQqqthuZft/MNevKLJG9DLxgMn2407BYQ8JP1DtBWzG
         www11dJF1wPOMyugBQTaniNP7neKMGrtuus6u5RJK+yvSeOIHVp14im+iwZLpGz4uzcq
         vLcQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4mIZUMJGxYf8aF9TprhbUymEF2hcU6OkK186Ha49xtHn68rKOWJBSgeIn5wCBX6W/nv1u8QxLX9Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3xpy3NPlyDVYsFUCVcMhUE2e/a8skMFhvS6RPs974yATY5/k1
	FEl05BxOJd15HLACHtT/vV4KwNn6b/IfcZjcw+9zy/b5jCbjlkhs+aQthS5f8n+38w==
X-Gm-Gg: ASbGncttSOPB3Fb/7NiwrmCMIKAmhw/wUNBmPSto+WPiUM3QRpdnw6+AFjZFFBPf/cP
	6UOK8SfuK5i/FHyohml0847Y3biJWe5DaeaFG4P0jHTg0shOrrDjf8SbKyvdGxQPrRWMHEO37o8
	lpm6rsT5YUjrhLlLYvBqGyFC0Yg/RCKeP5CWR8fAlqM+fWo7z36f3GemcsglHipg5t1cuZGPxsQ
	l+2NxIdevmRAI2V2RqkQ5kE0FVQGMEyxbaWRM6ltYks90TgVWWujL7rMiit/fgKMsZWHsjOndJS
	1whz6RQuscbVgMr7AkK9PYM3o8/zbNAxoPzZmZr4dSa0ESOAc+by34AKK//nZWDdVmFz91tAd+q
	ieMGOcG2M4T4Zdv4x5hBt2g8SM6u5q7cDo69qvuTi+lyRNKRCh1b/rA7Gw2QhNsXX/Q/SRZqB3Q
	9LpXrmbKg=
X-Google-Smtp-Source: AGHT+IH9uwwURUyKes29IiQ7UrpZEd9kPHN0CzbT2qqMjD7PLrbGD9+0C4X7WctdtlxEdOpGssZEtQ==
X-Received: by 2002:a17:907:7e88:b0:aeb:3df1:2e75 with SMTP id a640c23a62f3a-b34bb8f2acemr689961566b.46.1758874648505;
        Fri, 26 Sep 2025 01:17:28 -0700 (PDT)
Message-ID: 
Date: Fri, 26 Sep 2025 10:17:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
To: Grygorii Strashko 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Jason Andryuk ,
 "xen-devel@lists.xenproject.org" 
References: <20250925195558.519568-1-grygorii_strashko@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: <20250925195558.519568-1-grygorii_strashko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.09.2025 21:55, Grygorii Strashko wrote:
> From: Grygorii Strashko 
> 
> The LAPIC LVTx registers have two RO bits:
> - all: Delivery Status (DS) bit 12
> - LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
>   This bit is reserved for other LVTx regs with RAZ/WI access type (MMIO), while
>   WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bits
>   (MBZ access type).

Question is what the behavior is for writing the r/o (but not reserved) bits.
I wasn't able to find any statement in the SDM.

> and the current vLAPIC implementations allows guest to write to these RO bits.
> 
> The Delivery Status (DS) is not emulated by Xen - there is no IRQ msg bus, and
> the IRQ is:
> - or accepted at destination and appears as pending
>   (vLAPIC Interrupt Request Register (IRR))
> - or get rejected immediately.
> 
> The Remote IRR Flag (RIR) behavior emulation is not implemented for LINT0/LINT1
> in Xen for now.
> 
> Hence it is definitely wrong to allow guest to write to LVTx regs RO bits,
> fix it by unconditionally cleaning up those bits in vlapic_reg_write().
> 
> Signed-off-by: Grygorii Strashko 

Please also add a Fixes: tag when correcting code.

> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -880,6 +880,7 @@ void vlapic_reg_write(struct vcpu *v, unsigned int reg, uint32_t val)
>          if ( vlapic_sw_disabled(vlapic) )
>              val |= APIC_LVT_MASKED;
>          val &= array_access_nospec(vlapic_lvt_mask, (reg - APIC_LVTT) >> 4);
> +        val &= ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING);

There shouldn't be a 2nd &= here; what needs adding should imo be added to
(really: removed from) vlapic_lvt_mask[]. (Orthogonal to this I wonder whether
guest_wrmsr_x2apic() wouldn't better use that array, too.)

While looking at this, don't we have an issue with CMCI as well?
guest_{rd,wr}msr_x2apic() handle it, but vlapic_reg_write() doesn't. I.e. on
AMD we would fail to deliver #GP when the guest accesses it, while on Intel
we would lose the value written. And we also don't set its mask bit in
vlapic_do_init(). I guess I need to make a patch ...

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 08:22:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 08:22:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131315.1470458 (Exim 4.92)
	(envelope-from )
	id 1v23iZ-0004Gw-ST; Fri, 26 Sep 2025 08:22:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131315.1470458; Fri, 26 Sep 2025 08:22:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v23iZ-0004Gp-PR; Fri, 26 Sep 2025 08:22:15 +0000
Received: by outflank-mailman (input) for mailman id 1131315;
 Fri, 26 Sep 2025 08:22: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 1v23iY-0004Gj-5A
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 08:22:14 +0000
Received: from PH7PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170100009.outbound.protection.outlook.com
 [2a01:111:f403:c107::9])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e632fd19-9ab1-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 10:22:12 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SJ1PR12MB6195.namprd12.prod.outlook.com (2603:10b6:a03:457::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.13; Fri, 26 Sep
 2025 08:22:07 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.011; Fri, 26 Sep 2025
 08:22: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: e632fd19-9ab1-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZfwxKKtJFpENHGTe4sbxsg6qpbTUNTx1N7H81E2Zf4q7KbeS5T4kEgK71CouTYBYwXiHHXYtJ1VzXfwaYQx0NWiCvV/LM3W+M+HQ6Ieqo01JrrBg6Aj0aR67mWm7BO77Vu/9OH/3heZ4c+9/A2Q2WG+Uhib2z6mx95DqVWywp8c+WWFlcVixi1IfrhQlFwv9BZ2MFE7xqcAeCaYu7NqGPTD4UPvdyDTdnSOD15256LZFsCLMdV3W0uaVBjjnCIQob3Qbt06NMNvk1ErkRE6VYg2c8Aih0OhanppYIxgqz62r1tS/18ILXLez1fH1NgZTvwJSadNLnGG3f2aTtU/DKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Paqch4I5Kcn8DfAi0HYDjktgrDAoMBsu+0Mz67qe/Vc=;
 b=Yri0UfMKy//0u9xIG8ChFwEuqYV/h35JNEQwxuRifZ0Q0IZPbvuuqLojuC/v2rK1nQPVfvooAxi/0a1vzNdZHscQa2Bw/yL6ebZ6MtmbaN2YAl6OgqH8t8cvBYUdtmxQTx/B+zUvE+gUDGrxryI4yTt0pd+eHDRgN9k032EXpPNGPD2j0J3uAp+OaoM0Ws5UoQAaUpXkPjWGp25rPJyUoXVPrgAg1iNEzyH/8BKHlYqDN9FhOfqN8EAsTPJZmO8EnNL5EbY/xlxKELAt68/6LwdHQfqh4wUM/5mau+4esEqBnnEXDvMV2RRkjN8Nj23/rchTQlyOxza2UoEv5Q3KBw==
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=Paqch4I5Kcn8DfAi0HYDjktgrDAoMBsu+0Mz67qe/Vc=;
 b=mxotUTmbfmMdGoTBhd1HDaWGjiDUBq63vs05kwjlQpv/Af8G/YzA4BxsTrkWfhx69xKb/cJhCb01FV4AslFLLESUPlwNRJo6rLVNxSBi6Ry0NGssc9bmu6dXzpkLrg268VY+VNsKKiDUDO8s9mFhEm9uOBfFW/Je9QOjX+sbjBo=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "Daniel P. Smith"
	, "xen-devel@lists.xenproject.org"
	, "Andryuk, Jason" ,
	Andrew Cooper , Julien Grall ,
	Stefano Stabellini , Anthony PERARD
	, "Orzel, Michal" ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Oleksii Kurochko
	
Subject: RE: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
Thread-Index:
 AQHcIiYYEaVyPVCsmkah0K573htVM7SN/BaAgBWuJICAAGLSAIAA6DCQgAAq/ICAAADyQIAABM8AgAAQxiA=
Date: Fri, 26 Sep 2025 08:22:07 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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-09-26T08:14:15.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_|SJ1PR12MB6195:EE_
x-ms-office365-filtering-correlation-id: 37e70026-fe1e-4d16-a1e3-08ddfcd5c81b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?QVFjcnNuN05DLzJOMWlSdU81Q2RVcmx4MmpOU0I5V3AvSWIwSkpZMUFoQWZr?=
 =?utf-8?B?Zy9DSjlDaDNBOE1LM0w5VGk2a3dEUFNwdCtUZlBqRjd0UXhMZnpDQ2hZRTVs?=
 =?utf-8?B?RWliWWY0NGhDbVNjUjEvYnlOaENPakRTb3BaSXRMZUFmdWprTE5ybW5xcTIw?=
 =?utf-8?B?MnN6Y0pNWjV2aWdFRUpGT2VCc1Y2enFVR0VlZWxUVW1hWDJzTEhrWW4rVmFI?=
 =?utf-8?B?K2tLdHZBRlplYi9yYjUwWWZBWXFGQXowUnNNWTF2VnZNeWxySFVvZC9tUjN2?=
 =?utf-8?B?dGRNQWoxL2hod2ZyRSt4SExGRElZVEJJTDRXNHZrTnlqN081czM1Z1ZHNW9j?=
 =?utf-8?B?bjRqdTZvL2ZKSVdHZUx2R2kxOENTREJzeU5ETDNmNmtJckUzbldzOEE4azJm?=
 =?utf-8?B?azhsaGhPSWRLLy9pMVVTTjltWVpLY0dSaU1mSEQyWWtDOXplQ0U5U1ZDOGFY?=
 =?utf-8?B?RGVxYUQ3c28xWERnRUw5WnZrWVJqcU1Rc0xjZ3ZwSWdlaDZpYWtjL283TWlK?=
 =?utf-8?B?SUZsb2hySDFNSXhkM2pmWlg0UVhHU250UFQ2ZXdxN0NyR0N4MVpkK1RMeWVG?=
 =?utf-8?B?a1J2UHcrOWdaVXdFcW5FcjkydEViMzRXbTVXRU9VTmxoN3djRXFBWkxvN3Vr?=
 =?utf-8?B?ejM3NEI4SkJDVE1BSWNPbjBHZlcvOUY4dWFmdkNwWjE5OXZFcTJ1MmliYnBJ?=
 =?utf-8?B?MDI4eXBYbXV1M1RxV3YxN3YxZy9LZW9SREdnZ3dvdUIrMFhtR0h5cnZhZ2F0?=
 =?utf-8?B?MXQxa2h3VGtBelZ6NU52RWNQU01FM0JFVGFLSHFxY2tFdE45QytvMW9UdHVs?=
 =?utf-8?B?U0dhUHNzSER1anowSTR5UjQvSisweXIzckxpelppRGQ5L0VpRWlYcHU1NkFy?=
 =?utf-8?B?VFRpdFo0a0F6cSthUytDTEJFVGl1SVpPWFIwZ055Z2Y4dG1ZcGw1cVJVRHQz?=
 =?utf-8?B?cE5TU3htQWpJeUZiMHFBczZzNXBKbGNXbXBZSnV4VlJJaHFpTjR0NXIxanpr?=
 =?utf-8?B?TmE3ZVpzMFNQY0VvNnQzTWg0ZDRCc0JDTk0rZWhQb20vWEl5OW9lQWFDek0v?=
 =?utf-8?B?dmQybWJPTGlsS09VSFBLMDh3NklXZERwcXU0WG5SOC8waitNSGY2aEFKRGFh?=
 =?utf-8?B?N1grTmZsK01MS3YxbWY0SmlsLyt6N3Z0czRmSytsbzRiR2ZIa3R0Z09YNXdD?=
 =?utf-8?B?RVVDUE4vQmVLRVVDWkJPby9kYlJlTnpBTHpJNGJBRHYvck1DWXA2ZHNZVXh5?=
 =?utf-8?B?RDVUZ0c3SnBrT3ZDNS9BSDJtK0hGZXZUVGoyQnNFVVZ2aHB2U3NlZG4rWjdU?=
 =?utf-8?B?bDBuRHFVV2ZoNzJGa21xSDRTTTMxZ3hGSFhpMk85WjBpNWFMbElHVEt3Rmhp?=
 =?utf-8?B?MW9vZVF2cjFIbmRHa1JLdWpBTGxPbUJ4TWVmekEvUEM2bXF4WCs0aFRBaVlo?=
 =?utf-8?B?U2l1bmcyak05QVUxb1VtNWV6cS9ZL01Ec2w0TVBXVmI5VDVsZU1DSUJLVEwz?=
 =?utf-8?B?TmhrR2FUeTJpZU54MEFzbHliWmpmVXNnaUJaQnRVU1NjR3Y0c0dMdklVWHo1?=
 =?utf-8?B?KzZwS3gyT0dkZ1FWKzk2cXBmQmdxNmN3dmp6QjFPR0pRWXM0bDJQK21RWGFF?=
 =?utf-8?B?azJSZU02d1hROVY5aGwwTUZtNFZQN3hPb2FnOEhwYktsWjBzd3daL0hTbXA3?=
 =?utf-8?B?a3lNOVIwazZ4WXY1VmZXZmlsSko4Y1ZtUFhRc3ZUN3hpTmhHWUhubFNremRL?=
 =?utf-8?B?RStZU1BuYm5jVGhBNW9GbWlLL0hHNTV0ZDhCVWxmcDExUlFqeVppQmVGSzVV?=
 =?utf-8?B?K3JPdlV1V04vekwyVE91NTZNSkVEeTlFYlo3RG1qTU5rUFdrczRsS1hRenNP?=
 =?utf-8?B?Q2JtNDBCRVg2RzRpd3JDV2M4UE1KemtxZjh5d0o0TnpudFV3WDFaenJtaVRI?=
 =?utf-8?B?dkNWZ2d0QzhNVGttYnVJL3JnMlY2L2I1bFVhbE5YOHp2NmZtN1NlR09xU1l0?=
 =?utf-8?B?TGp2bkczRUdKbXczdU5pNVhOdENSU1lDQXoxTVBwb0M2ejBabng1OVJWN2J1?=
 =?utf-8?Q?ogCGYb?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TlhhWm9ta3pTOURwdW5YSnRCS0pUNWFwOWVod1pqNEd6cDJYT1ZlVk5lKy9G?=
 =?utf-8?B?SU5nc3RleFlXOVhpUFNWQ2lkcGR2TFM3L0tRYmFpRGZUbVRnay9WR3N4eVhz?=
 =?utf-8?B?UTJJSkZtMHlNaUg5cWpiK1l2ZGRwVU1xNm9jR3FscW1kQXpwdUZCMHpLU09G?=
 =?utf-8?B?NUlxQTNzczRJcWlFa2tKUzI0dmsxRTRXN0xoc1ZPNlA3Q0ptY3BLN2VuZkRO?=
 =?utf-8?B?OXFtOHBUeUFoTVF2VVkzUDlrVHZGbjFFTTY4VC82eGtnSGNWcWswYlpyeUVy?=
 =?utf-8?B?a1BQeXNTbk1QNll6cDdqNWpuWlNadldHV3d2biswbU82aVl6cFJyeFZQemhJ?=
 =?utf-8?B?VUgzd1JHRlE1MlhMRjB3bG9ndW1qKzdNRWdaR09FYy9pMk9USnd1NjNvTUhq?=
 =?utf-8?B?QlkrMEMrV1RyR1dad29XZUJxcmZpUTd6ckZ2allhcEJxSVcwQTRrZWJKL08z?=
 =?utf-8?B?L0JwNWhsT2lhTTY2d1FFdmVOZWg1bG5lL3cwN0NNQ2FSa2pxekcvbkozOUcr?=
 =?utf-8?B?dE5mL0hjQ1VLVW1LYTlGaUdZZHZhL0gvWi82MEpPelR4d3hKWTBhT0wxdExO?=
 =?utf-8?B?ampYbWFCZDNXVEdZL2FUTllpWXdDVWZzUFdRM0VrOE1lcE40MmhwSGxRNE9q?=
 =?utf-8?B?NWRPYTJXYkYvOTExMDc4aUhpUFVndnN0elZpU29xWFRqL1Vxeng0ZjdVL0VO?=
 =?utf-8?B?SkVwWVBhZW1qVEczOFArM0lrRmVCNEErZWtWcUYxckdYOWF6ZVFQMFc3SnIx?=
 =?utf-8?B?eURrUytOMnVpenpsdTlUV2tXa05SVGc0bXJBT05LczZ0RFJUeUkyOE1nTWdv?=
 =?utf-8?B?Q2NOWVRKNWp3aDVEcG9JUGgzOTRiVWJzeUxudWFmazk2bkVvZkZaQ0tyTVdh?=
 =?utf-8?B?MWs5TTcxdkg2Qm5CWTZULy9tbitaeVY5M3h0Tk8rQnJpYmsxYlEzMDk2cmlm?=
 =?utf-8?B?dlNuMEhaQU42K1QyTTM1SmlmS3lVVWVHNWE0c1VDYTVERlpnekI1R0crSkEv?=
 =?utf-8?B?dnVlWHEraVp1ajlMZEY5bVZSQWpkTjRNWnQxb1dyZlF2R0JZNDVvZjY5Q2E3?=
 =?utf-8?B?dXIvZVMyMVZKSzh1ZFVTUTN4YytjUVdTaTNZdm0wN1BRdzIyTERNa3BzMnRa?=
 =?utf-8?B?UWgxL1RqVm1UUStsS1luV1BJcHpsQ2x1SGhjcFUwN0x6OG9qU25JQ1MzS2ZS?=
 =?utf-8?B?MzQzbDMvUklwdTEyZGorVW9VOHhOSDRHbWtkaTB5L2l3NXJvQU9pSkcxVDVP?=
 =?utf-8?B?dUFKWFBSQVg2L0FmUkxqOTBHMHRmSHFkTUJYbWxQZTAzS3ZMMFVCdUZPZ1pj?=
 =?utf-8?B?MWVXNG9LNkFNRmNXS1B3RnIvMlY1SU9GNWtCUlpiRTJqMmR3MG41Z3BRWlZX?=
 =?utf-8?B?Qlhkb1FzVEw1Q3hETERMYlZXNWE2aXdETWlaK0NMSGtKd3phL0ZWa1FSeWpF?=
 =?utf-8?B?Ylp1dVM1ZG51QmZ5a0M0NFBwOXRxT0FaZ0xCRFNMVjJCNytWMlJNSmZFSWhp?=
 =?utf-8?B?Y3JYSER1MGhyZU9qdVR1SG5YakVYVSsxR24relRmVGd6NUduQzVqT2RHdlNo?=
 =?utf-8?B?WmgxS3BHdzZ0aUpJclcyR2hwYkVQcFMvWC9JNDlkWDhGL3NXUzFCWjVjOWFl?=
 =?utf-8?B?Q2ZQN3crRE9FZUdXeldDRStkQ0c4L3Z1dUU3WGtaYTEwcXpoUm8xOHNXeEMz?=
 =?utf-8?B?dTBVS2llbGJDRHpYVnAyN1pSL281YkJPUTlLNmI5VExGcUVNcUJYeWN4cExl?=
 =?utf-8?B?VzVXUDVaa3lOVWx1UEx1KzdQaE9xS2xBQ3A1YmZQNmdJMTZYZktiQXZqcjZ2?=
 =?utf-8?B?bHlGVzlJYnJMRHlQYWxIMlpMNWVQRnRRTy8zOXpMM1NrUDJ6Q05BZ1dZampv?=
 =?utf-8?B?OEsxVkgxVjFPOTJOVmQ3bFNQdFJ5TVJpaG1GbzdlWFZsWXBjcWFNbHJzalFY?=
 =?utf-8?B?WElrYkJZMEtFZ01KM203NENtRUhYV0hyc3FKYjUwNzBBenFDVVpxREgxSHN5?=
 =?utf-8?B?a0pJZDBXYmovOVdlNUNYT2ZIZzB2cXZHWHFKaDJPWmxEOG5qMDVQUTIrMnNR?=
 =?utf-8?B?cFhhSzBtalpRS3VMRUUwTHBGWkVheDg4MHhHMEwwQUxhKzRrSXNsMm1jTGxx?=
 =?utf-8?Q?UvFo=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: 37e70026-fe1e-4d16-a1e3-08ddfcd5c81b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2025 08:22:07.1477
 (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: Y7fc8IYLV+PkOM/BkrOLwHNX/SYAskbrn4lcz4AT9/ierhsNKMIKQncxfY6kiV1IUwmCsj01ai1c8XCpCEcKXw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6195

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAy
MDI1IDM6MTQgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4g
Q2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgRGFuaWVsIFAuIFNtaXRoDQo+IDxk
cHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qu
b3JnOyBBbmRyeXVrLCBKYXNvbg0KPiA8SmFzb24uQW5kcnl1a0BhbWQuY29tPjsgQW5kcmV3IENv
b3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47DQo+IEp1bGllbiBHcmFsbCA8anVsaWVu
QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBB
bnRob255DQo+IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9yemVsLCBNaWNo
YWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsNCj4gUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+OyBPbGVrc2lpIEt1cm9jaGtvDQo+IDxvbGVrc2lpLmt1cm9jaGtvQGdtYWls
LmNvbT4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAxOC8yNl0geGVuL2RvbWN0bDogd3JhcCB4
c21fZ2V0ZG9tYWluaW5mbygpIHdpdGgNCj4gQ09ORklHX01HTVRfSFlQRVJDQUxMUw0KPg0KPiBP
biAyNi4wOS4yMDI1IDA4OjU3LCBQZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4NCj4gPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMjUgMjo1MyBQTQ0KPiA+Pg0K
PiA+PiBPbiAyNi4wOS4yMDI1IDA2OjQxLCBQZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4+Pj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxp
Y2hAc3VzZS5jb20+DQo+ID4+Pj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAyNSAx
MDoyOSBQTQ0KPiA+Pj4+DQo+ID4+Pj4gT24gMjUuMDkuMjAyNSAxMTo0MSwgUGVubnksIFpoZW5n
IHdyb3RlOg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZy
b206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4+Pj4+IFNlbnQ6IFRodXJz
ZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMjUgOTozMCBQTQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE9uIDEw
LjA5LjIwMjUgMDk6MzgsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4+Pj4+IC0tLSBhL3hlbi9p
bmNsdWRlL3hzbS94c20uaA0KPiA+Pj4+Pj4+ICsrKyBiL3hlbi9pbmNsdWRlL3hzbS94c20uaA0K
PiA+Pj4+Pj4+IEBAIC01NSw4ICs1NSw4IEBAIHN0cnVjdCB4c21fb3BzIHsNCj4gPj4+Pj4+PiAg
ICAgIHZvaWQgKCpzZWN1cml0eV9kb21haW5pbmZvKShzdHJ1Y3QgZG9tYWluICpkLA0KPiA+Pj4+
Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dl
dGRvbWFpbmluZm8gKmluZm8pOw0KPiA+Pj4+Pj4+ICAgICAgaW50ICgqZG9tYWluX2NyZWF0ZSko
c3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3Qgc3NpZHJlZik7DQo+ID4+Pj4+Pj4gLSAgICBpbnQg
KCpnZXRkb21haW5pbmZvKShzdHJ1Y3QgZG9tYWluICpkKTsNCj4gPj4+Pj4+PiAgI2lmZGVmIENP
TkZJR19NR01UX0hZUEVSQ0FMTFMNCj4gPj4+Pj4+PiArICAgIGludCAoKmdldGRvbWFpbmluZm8p
KHN0cnVjdCBkb21haW4gKmQpOw0KPiA+Pj4+Pj4+ICAgICAgaW50ICgqZG9tY3RsX3NjaGVkdWxl
cl9vcCkoc3RydWN0IGRvbWFpbiAqZCwgaW50IG9wKTsNCj4gPj4+Pj4+PiAgICAgIGludCAoKnN5
c2N0bF9zY2hlZHVsZXJfb3ApKGludCBvcCk7DQo+ID4+Pj4+Pj4gICAgICBpbnQgKCpzZXRfdGFy
Z2V0KShzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgZG9tYWluICplKTsgQEANCj4gPj4+Pj4+PiAt
MjM0LDcNCj4gPj4+Pj4+PiArMjM0LDExIEBAIHN0YXRpYyBpbmxpbmUgaW50IHhzbV9kb21haW5f
Y3JlYXRlKA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gIHN0YXRpYyBpbmxpbmUgaW50IHhzbV9nZXRk
b21haW5pbmZvKHhzbV9kZWZhdWx0X3QgZGVmLCBzdHJ1Y3QNCj4gPj4+Pj4+PiBkb21haW4NCj4g
Pj4+Pj4+PiAqZCkgIHsNCj4gPj4+Pj4+PiArI2lmZGVmIENPTkZJR19NR01UX0hZUEVSQ0FMTFMN
Cj4gPj4+Pj4+PiAgICAgIHJldHVybiBhbHRlcm5hdGl2ZV9jYWxsKHhzbV9vcHMuZ2V0ZG9tYWlu
aW5mbywgZCk7DQo+ID4+Pj4+Pj4gKyNlbHNlDQo+ID4+Pj4+Pj4gKyAgICByZXR1cm4gLUVPUE5P
VFNVUFA7DQo+ID4+Pj4+Pj4gKyNlbmRpZg0KPiA+Pj4+Pj4+ICB9DQo+ID4+Pj4+Pg0KPiA+Pj4+
Pj4gVGhpcyBpcyBpbiB1c2UgYnkgYSBYZW5zdG9yZSBzeXNjdGwgYW5kIGEgWGVuc3RvcmUgZG9t
Y3RsLiBUaGUNCj4gPj4+Pj4+IHN5c2N0bCBpcyBoZW5jZSBhbHJlYWR5IGJyb2tlbiB3aXRoIHRo
ZSBlYXJsaWVyIHNlcmllcy4gTm93IHRoZQ0KPiA+Pj4+Pj4gZG9tY3RsIGlzIGFsc28gYmVpbmcg
c2NyZXdlZCB1cC4gSSBkb24ndCB0aGluayBNR01UX0hZUEVSQ0FMTFMNCj4gPj4+Pj4+IHJlYWxs
eSBvdWdodCB0byBleHRlbmQgdG8gYW55IG9wZXJhdGlvbnMgYXZhaWxhYmxlIHRvIG90aGVyIHRo
YW4NCj4gPj4+Pj4+IHRoZSBjb3JlDQo+ID4+IHRvb2xzdGFjay4NCj4gPj4+Pj4+IFRoYXQncyB0
aGUgWGVuc3RvcmUgb25lcyBoZXJlLCBidXQgYWxzbyB0aGUgb25lcyB1c2VkIGJ5IHFlbXUNCj4g
Pj4+Pj4+ICh3aGV0aGVyIHJ1biBpbg0KPiA+Pj4+IERvbTAgb3IgYSBzdHViZG9tKS4NCj4gPj4+
Pj4NCj4gPj4+Pj4gTWF5YmUgbm90IG9ubHkgbGltaXRlZCB0byB0aGUgY29yZSB0b29sc3RhY2su
IEluDQo+ID4+Pj4+IGRvbTBsZXNzL2h5cGVybGF1bmNoZWQNCj4gPj4+PiBzY2VuYXJpb3MsIGh5
cGVyY2FsbHMgYXJlIHN0cmljdGx5IGxpbWl0ZWQuIFFFTVUgaXMgYWxzbyBsaW1pdGVkIHRvDQo+
ID4+Pj4gcHZoIG1hY2hpbmUgdHlwZSBhbmQgd2l0aCB2ZXJ5IHJlc3RyaWN0ZWQgZnVuY3Rpb25h
bGl0eSgsIG9ubHkNCj4gPj4+PiBhY3RpbmcgYXMgYSBmZXcgdmlydGlvLXBjaSBkZXZpY2VzIGJh
Y2tlbmQpLiBAQW5kcnl1aywgSmFzb24NCj4gPj4+PiBAU3RhYmVsbGluaSwgU3RlZmFubyBBbSBJ
IHVuZGVyc3RhbmRpbmcgY29ycmVjdGx5IGFuZCB0aG9yb3VnaGx5DQo+ID4+Pj4gYWJvdXQgb3Vy
IHNjZW5hcmlvIGhlcmUgZm9yDQo+ID4+IHVwc3RyZWFtPw0KPiA+Pj4+PiBUcmFja2luZyB0aGUg
Y29kZXMsIGlmIFhlbnN0b3JlIGlzIGNyZWF0ZWQgYXMgYSBzdHViIGRvbWFpbiwgaXQNCj4gPj4+
Pj4gcmVxdWlyZXMNCj4gPj4+PiBnZXRkb21haW5pbmZvLWRvbWN0bCB0byBhY3F1aXJlIHJlbGF0
ZWQgaW5mby4gIFNvcnJ5LCBJIGhhdmVuJ3QNCj4gPj4+PiBmb3VuZCBob3cgaXQgd2FzIGNhbGxl
ZCBpbiBRRU1VLi4uDQo+ID4+Pj4NCj4gPj4+PiBJdCdzIG5vdCAiaXQiOyBpdCdzIGRpZmZlcmVu
dCBvbmVzLiBGaXJzdCBhbmQgZm9yZW1vc3QgSSB3YXMNCj4gPj4+PiB0aGlua2luZyBvZg0KPiA+
Pj4+ICAqIFhFTl9ET01DVExfaW9wb3J0X21hcHBpbmcNCj4gPj4+PiAgKiBYRU5fRE9NQ1RMX21l
bW9yeV9tYXBwaW5nDQo+ID4+Pj4gICogWEVOX0RPTUNUTF9iaW5kX3B0X2lycQ0KPiA+Pj4+ICAq
IFhFTl9ET01DVExfdW5iaW5kX3B0X2lycQ0KPiA+Pj4+IGJ1dCB0aGVyZSBtYXkgYmUgb3RoZXJz
IChhbGJlaXQgcGVyIHRoZSBkdW1teSB4c21fZG9tY3RsKCkgdGhpcyBpcw0KPiA+Pj4+IHRoZSBm
dWxsIHNldCkuIEFzIGEgZ2VuZXJhbCBjcml0ZXJpYSwgYW55dGhpbmcgdXNpbmcgWFNNX0RNX1BS
SVYNCj4gPj4+PiBjaGVja2luZyBjYW4gaW4gcHJpbmNpcGxlIGJlIGNhbGxlZCBieSBxZW11Lg0K
PiA+Pj4+DQo+ID4+Pg0KPiA+Pj4gVW5kZXJzdG9vZC4NCj4gPj4+IEkgYXNzdW1lIHRoYXQgdGhl
eSBhcmUgYWxsIGZvciBkZXZpY2UgcGFzc3Rocm91Z2guIFdlIGFyZSBub3QNCj4gPj4+IGFjY2Vw
dGluZyBkZXZpY2UNCj4gPj4gcGFzc3Rocm91Z2ggdmlhIGNvcmUgdG9vbHN0YWNrIGluIGRvbTBs
ZXNzL2h5cGVybGF1bmNoLWVkIHNjZW5hcmlvcy4NCj4gPj4gSmFzb24gaGFzIGRldmVsb3BlZCBk
ZXZpY2UgcGFzc3Rocm91Z2ggdGhyb3VnaCBkZXZpY2UgdHJlZSB0byBvbmx5DQo+ID4+IGFjY2Vw
dCAic3RhdGljIGNvbmZpZ3VyZWQiIHBhc3N0aHJvdWdoIGluIGRvbTBsZXNzL2h5cGVybGF1bmNo
LWVkDQo+ID4+IHNjZW5hcmlvLCB3aGlsZSBpdCBpcyBzdGlsbCBpbnRlcm5hbCAsIGl0IG1heSBi
ZSB0aGUgb25seSBhY2NlcHQgd2F5DQo+ID4+IHRvIGRvIGRldmljZSBwYXNzdGhyb3VnaCBpbiBk
b20wbGVzcy9oeXBlcmxhdW5jaC1lZCBzY2VuYXJpby4NCj4gPj4NCj4gPj4gUmlnaHQsIGJ1dCBu
byBtYXR0ZXIgd2hhdCB5b3VyIGdvYWxzLCB0aGUgdXBzdHJlYW0gY29udHJpYnV0aW9ucyBuZWVk
DQo+ID4+IHRvIGJlIHNlbGYtIGNvbnNpc3RlbnQuIEkuZS4gbm90IChyaXNrIHRvKSBicmVhayBv
dGhlciBmdW5jdGlvbmFsaXR5Lg0KPiA+PiAoUmVhbGx5IHRoZSBmb3VyIGRvbWN0bC1zIG1lbnRp
b25lZCBhYm92ZSBtaWdodCBiZXR0ZXIgaGF2ZSBiZWVuIHB1dA0KPiA+PiBlbHNld2hlcmUsIGUu
Zy4gYXMgZG0tb3BzLiBNb3ZpbmcgdGhlbSBtYXkgYmUgYW4gb3B0aW9uIGhlcmUuKQ0KPiA+DQo+
ID4gVW5kZXJzdG9vZC4NCj4gPiBJJ2xsIG1vdmUgdGhlbSBhbGwgdG8gdGhlIGRtLW9wcw0KPg0K
PiBCZWZvcmUgeW91IGRvIHNvLCBwbGVhc2UgY29uc2lkZXIgdGhlIGNvbnNlcXVlbmNlcywgdGhv
dWdoIChJIHNhaWQgIm1heSIgZm9yIGENCj4gcmVhc29uKS4gQWxzbyBwbGVhc2UgYWxsb3cgb3Ro
ZXJzIHRvIGNoaW1lIGluLiAoSW4gdGhpcyBjb250ZXh0IEkgbm90aWNlIHRoYXQgc2V2ZXJhbA0K
PiBSRVNUIG1haW50YWluZXJzIHdlcmVuJ3QgZXZlbiBDYy1lZCBoZXJlLCBhbmQgaGVuY2UgbWF5
IG5vdCBoYXZlIHNlZW4gdGhlDQo+IGVhcmxpZXIgZGlzY3Vzc2lvbi4pDQo+DQoNClNvcnJ5LCB3
aGF0IEkgcmVhbGx5IG1lYW4gaXMgdGhhdCBJJ20gZ29pbmcgdG8gaW52ZXN0aWdhdGUgdGhlIGFj
dHVhbCB3b3JrIHJlcXVpcmVkIGZvciBtb3ZpbmcgdGhlc2UgZm91ciBoeXBlcmNhbGxzIHRvIGRt
LW9wcy4gVGhlbiBJIGNvdWxkIGdvIGJhY2sgdG8gdGhlIGRpc2N1c3Npb24gdG8gaGF2ZSBhIGNs
ZWFyZXIgdmlldy4gVG8gYmUgY2xlYXIsIHlvdSBhcmUgc3VnZ2VzdGluZyBBQkkgY2hhbmdlLCBs
aWtlIFhFTl9ET01DVExfaW9wb3J0X21hcHBpbmcgdG8gWEVOX0RNT1BfaW9wb3J0X21hcHBpbmcs
IG9yIG5ldyBBQkkgYWRkZWQ/DQoNCj4gT25lIHRoaW5nIHNlZW1zIHByZXR0eSBjbGVhciB0byBt
ZTogVGhpcyB3b3JrIGxpa2VseSBpc24ndCBnb2luZyB0byBiZSBzdWl0YWJsZSBmb3INCj4gNC4y
MSBhbnltb3JlLiBIZW5jZSB3ZSdyZSBiYWNrIHRvIGNvbnNpZGVyaW5nIGFsdGVybmF0aXZlcyB0
byBhZGRyZXNzIHRoZSBzdGlsbA0KPiBwZW5kaW5nIGJ1aWxkIGlzc3VlLiAoTXkgdGFrZSBvbiBp
dCByZW1haW5zOiBSZXZlcnQgdGhlIHRhaWwgb2YgdGhlIHN5c2N0bCB3b3JrLikNCj4gQWRkaW5n
IE9sZWtzaWkgdG8gQ2MgYXMgd2VsbC4NCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 08:30:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 08:30:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131338.1470468 (Exim 4.92)
	(envelope-from )
	id 1v23qI-00066C-Nx; Fri, 26 Sep 2025 08:30:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131338.1470468; Fri, 26 Sep 2025 08: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 1v23qI-000665-KR; Fri, 26 Sep 2025 08:30:14 +0000
Received: by outflank-mailman (input) for mailman id 1131338;
 Fri, 26 Sep 2025 08: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 1v23qI-00065z-1V
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 08:30:14 +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 0469e81b-9ab3-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 10:30:11 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b29ebf9478bso251886466b.0
 for ; Fri, 26 Sep 2025 01:30:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353e5cfa56sm321229466b.20.2025.09.26.01.30.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 01:30: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: 0469e81b-9ab3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758875411; x=1759480211; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uF2r96MkuC9TA/BXA2HtEMzQkNste8ou7jkvQUOVgPU=;
        b=VNTus8+1AU1u2MIl3rywmK4UaG+mbgl1+OBGRRyKHdTmYXueqRyfzo3kSEQZywPugu
         FRv0EJF+HWXzHqgsQY4T6KnZYTswl8R4TrTCX1KT6gBbUh9UsdLIN19F5Mo3k3lIpWY8
         SFXr2dbwk+uEdTLrA4HZ0iyr/xeQRpZBOBjpT+WFj5Xpcpp4RsBh7TqxCrBoEGmBNM8N
         +tWDmJTzIKAaUNA/AfHJyPVgJZevTFKWDc45vFpGFsWzaFhewMJPcUGJU6EvxKm6um8H
         6FXgj40y3f8/cR9DHdl3PT9VqtzXagZoWoh8aE8J3EXswnpPXFWPaVCVT5vT7sOXsSlf
         iVbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758875411; x=1759480211;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uF2r96MkuC9TA/BXA2HtEMzQkNste8ou7jkvQUOVgPU=;
        b=vAB0rjCiiNO0DEaKGWtmMTCLPHgIe2w51T9024XTI9S1HNgwv0UUpUx4R5/+osQAX4
         qenPg+g9wy3B2iDnXaX70mNDCb7qygomlGxw2+cCziaLKBsusTAbC0a0syPh/AYMXxKr
         kBXAFiu5/6jKPnFm+gXXy9Uwp6qNRPrRoGaCZ4V7TahZsPDZ+XBBJsyppT2mP/iZqncz
         S/Pe3tMfGuR1Vlkd251GRyfELvVOM1bm9YK1dbWnQMbI1CXGqpEozQ2EIBWuX5R5HkE7
         /XFBQADRko9M+SM2mnoGiswWP3Y4BxVJbw9M+HDt009ytdj+Oe5eS8MtrWfGeiEXsODM
         WXxQ==
X-Forwarded-Encrypted: i=1; AJvYcCWIY1LVZ7zQpG1gec3NKtaFa84++60bHsWCatAbId54WaoGVORBfJmqlOG85pQCkob3Z0fPbESLaR4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0kboioV8AWELwGvfkEG2Acp37stOAyE7alfezkXn3i1oG7dsv
	rYh00dSK3OQ4/5fmL8u3wX7F9utmuBIOZRQJARvF74EWBkzCAk8z2W5U8Hd7jg4GqQ==
X-Gm-Gg: ASbGncuNBZMBepIK3VN99LTZ0+ZXasaByArs7rJJy/QuakST8DN1DJRQ99kbAwedkGj
	0VcPpIcGI4KSODibUALUIDIRbywnMQsG+gLMJvRiFBMZg7/BmW4m+dqfC+ytGfGJhb9TzPvJFWb
	9HquIirTLV8IVS3Yg5Zs7lyuEJRe5pxv8Rt1GhixRQVR5++LGSt/tKmTqoN2iNMQrrOUolygWo0
	g/tptQcq0kFuOb4ASu3rOrEdnOK/VStf0KNK3xcL7VAhI9Ft3wkKZdgOru4tj9hYQEPwcbYBm0E
	lKksmiYjN5hj6iPP3Ix5kN8h3Rn3EBulUXtgjnjE2+9rk6qFmwYWaD37JEyyJC6Hu34io9Tw0F0
	o+PFOxVF+fwFf4pC2kusofuual5XEu8J2QmH7YfW0iwjEtUczt7gUAldfaeAq5chpIJdSzuCVyi
	vizV+HyMU=
X-Google-Smtp-Source: AGHT+IFH0U7Id5YCeVpkA1g2SFVwPLKOQ8JbamVFa/WH5+B3uz/I3xoqZcEqpMTAZxQaDUimFCh2xg==
X-Received: by 2002:a17:907:86ab:b0:b04:6cf7:75d4 with SMTP id a640c23a62f3a-b34bcd5959amr655797666b.49.1758875410631;
        Fri, 26 Sep 2025 01:30:10 -0700 (PDT)
Message-ID: 
Date: Fri, 26 Sep 2025 10:30:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" ,
 "Andryuk, Jason" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 "Orzel, Michal" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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.09.2025 10:22, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Friday, September 26, 2025 3:14 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Daniel P. Smith
>> ; xen-devel@lists.xenproject.org; Andryuk, Jason
>> ; Andrew Cooper ;
>> Julien Grall ; Stefano Stabellini ; Anthony
>> PERARD ; Orzel, Michal ;
>> Roger Pau Monné ; Oleksii Kurochko
>> 
>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
>> CONFIG_MGMT_HYPERCALLS
>>
>> On 26.09.2025 08:57, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Friday, September 26, 2025 2:53 PM
>>>>
>>>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich 
>>>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>>>
>>>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich 
>>>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>>>
>>>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>>>      void (*security_domaininfo)(struct domain *d,
>>>>>>>>>                                  struct xen_domctl_getdomaininfo *info);
>>>>>>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>>>> -    int (*getdomaininfo)(struct domain *d);
>>>>>>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>>> +    int (*getdomaininfo)(struct domain *d);
>>>>>>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>>>      int (*sysctl_scheduler_op)(int op);
>>>>>>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>>>> -234,7
>>>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>>>
>>>>>>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>>>> domain
>>>>>>>>> *d)  {
>>>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>>>> +#else
>>>>>>>>> +    return -EOPNOTSUPP;
>>>>>>>>> +#endif
>>>>>>>>>  }
>>>>>>>>
>>>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>>>> really ought to extend to any operations available to other than
>>>>>>>> the core
>>>> toolstack.
>>>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>>>> (whether run in
>>>>>> Dom0 or a stubdom).
>>>>>>>
>>>>>>> Maybe not only limited to the core toolstack. In
>>>>>>> dom0less/hyperlaunched
>>>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>>>> pvh machine type and with very restricted functionality(, only
>>>>>> acting as a few virtio-pci devices backend). @Andryuk, Jason
>>>>>> @Stabellini, Stefano Am I understanding correctly and thoroughly
>>>>>> about our scenario here for
>>>> upstream?
>>>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>>>> requires
>>>>>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't
>>>>>> found how it was called in QEMU...
>>>>>>
>>>>>> It's not "it"; it's different ones. First and foremost I was
>>>>>> thinking of
>>>>>>  * XEN_DOMCTL_ioport_mapping
>>>>>>  * XEN_DOMCTL_memory_mapping
>>>>>>  * XEN_DOMCTL_bind_pt_irq
>>>>>>  * XEN_DOMCTL_unbind_pt_irq
>>>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>>>> checking can in principle be called by qemu.
>>>>>>
>>>>>
>>>>> Understood.
>>>>> I assume that they are all for device passthrough. We are not
>>>>> accepting device
>>>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios.
>>>> Jason has developed device passthrough through device tree to only
>>>> accept "static configured" passthrough in dom0less/hyperlaunch-ed
>>>> scenario, while it is still internal , it may be the only accept way
>>>> to do device passthrough in dom0less/hyperlaunch-ed scenario.
>>>>
>>>> Right, but no matter what your goals, the upstream contributions need
>>>> to be self- consistent. I.e. not (risk to) break other functionality.
>>>> (Really the four domctl-s mentioned above might better have been put
>>>> elsewhere, e.g. as dm-ops. Moving them may be an option here.)
>>>
>>> Understood.
>>> I'll move them all to the dm-ops
>>
>> Before you do so, please consider the consequences, though (I said "may" for a
>> reason). Also please allow others to chime in. (In this context I notice that several
>> REST maintainers weren't even Cc-ed here, and hence may not have seen the
>> earlier discussion.)
>>
> 
> Sorry, what I really mean is that I'm going to investigate the actual work required for moving these four hypercalls to dm-ops. Then I could go back to the discussion to have a clearer view. To be clear, you are suggesting ABI change, like XEN_DOMCTL_ioport_mapping to XEN_DMOP_ioport_mapping, or new ABI added?

Well, merely adding new ABIs wouldn't address the problem, would it? You'd
need to make sure the old ABIs aren't used anymore by up-to-date code, at
which point the old domctl sub-ops could as well go away. A follow-on
question then would be whether retaining the wrappers in libxc is
appropriate; aiui dm-ops are rather intended to be dealt with in
libxendevicemodel. Yet moving things between libraries can (will?) break
consumers of the libraries.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 08:59:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 08:59:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131350.1470477 (Exim 4.92)
	(envelope-from )
	id 1v24I8-0000ku-Pc; Fri, 26 Sep 2025 08:59:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131350.1470477; Fri, 26 Sep 2025 08:59: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 1v24I8-0000kn-Me; Fri, 26 Sep 2025 08:59:00 +0000
Received: by outflank-mailman (input) for mailman id 1131350;
 Fri, 26 Sep 2025 08:58: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 1v24I7-0000kh-FV
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 08:58:59 +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 088781dd-9ab7-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 10:58:56 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6349e3578adso3450510a12.1
 for ; Fri, 26 Sep 2025 01:58:56 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3ae308bsm2621905a12.32.2025.09.26.01.58.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 01:58: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: 088781dd-9ab7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758877136; x=1759481936; 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=Tll720uHDLhbRSVtbVJvGPYb5YUByEDNqKBzBwWkBwE=;
        b=S8MBFSRty3vT9leqQg6GBo6KD69ABxrwpIhfLItgjiEqH5gxcxfjFJJ/T9nAv3FZfO
         tAMF40+f5E4Ym2ZvEBWCc84cXQYDfBKQAeYRwcsWxJVhTyZ2F4d6EOv5/mU3xewDdI2L
         +PyxK9a7moUIedgcPcEopQCPMozOYJK85rMb2YnyOxneLhCOb14k39wIWoziyw1vJHOF
         MqbsHTTVflzaG/YCjzSbhtzHcqxI//0R8aLbyMnv2vUYLYcf9NSsaLo8NmQXyANaSRT8
         qBgMKKpfysGtj8Dskoy2qvg6kYy4qGQSBl/VnHLvt3QIum4Ayaxr/2T2Mzy6ihoPa5Bl
         5X2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758877136; x=1759481936;
        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=Tll720uHDLhbRSVtbVJvGPYb5YUByEDNqKBzBwWkBwE=;
        b=uufFR1BSYPeEbKBWTRc5duvkJMcHj8IytDu3sGtyIzwzohy0J5nVVFZsS7Jyu8RZVK
         xYc1tzh8sQ1CyCylnEhceIa3zuxRYDinpQFal6lNzt1OKAyBkKCS/FJUHWSUMNt3R4Z3
         PzoKdlAbMgeOeDz+Kgq49MII9x+288jAxlzGLM25rzYnSZa47bfGGZwtYBHh9mXJsO90
         lwhTKv17HJZc9oCLC6Is+wbBQRKFd298+PrdBASsLgM1vvbG77IKQNVExUE8Ddp0tsbc
         ctBDaqj6kA1NPGq0M/A3lM7SwzJ2/qjqtysrgsBmiJj9kR85qqdybP56HrlDTnKrBCZE
         n8gg==
X-Forwarded-Encrypted: i=1; AJvYcCXfaCWYOJt3G+tQyjWVcq8UocXyfgv7o8xzJhqlis19oYbxyCTmsFz4T57mcj5gDQdQ3wKkMTjQ9Sg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHabCA8p5gtTij80DuWyCG46fFG+0fELTU/yoAH0kCkc2Cq2+b
	CLNpODMY91g91AjoidBxSYI9Jxkw4PqBJnfiLbKe/+FYMY7ME9QhlQoD
X-Gm-Gg: ASbGnctXV7xme7IcnEARgv98glO2K2+/gZo9PPJNbRLN4aocMHV9zD0btoEZ+5GgyN9
	WvGhAEHn2mhCBKccLnKpByr7+QkSf8V9VZkSjku1470k8d35kM9/wXA3/mAEAp4Crm/Lga9giS+
	gCR1IYvLm6+aJsPOTzZKbR3uwuErnBC831qOpiJ3mU8Y+b62v2BjT2CPQAvdXrcNlmHN1wsPdqD
	P+4ztJCc0cHaon7C3TjJkxa7Mfp3bqdDg4vg9DumIYw04XKFRiG8AWP3YHhz9XPrnZkGNSQWk2c
	Ln2Zerlln1SuGUnhzthBsPn5y7pQjuFQEhORSYSH3xn0zoNgB9dA40m2P7Aelqx9NBdU6Dr0+IL
	gqYcVCoJJFjkRwqkjAEiWBAPw0iECxJpJUoMUVArOr419imTRj1RX1SjNvvVDeGBR9BXGvFw5mS
	ePqWEjtoY=
X-Google-Smtp-Source: AGHT+IE+ILVgLUNgj/mwJQLlwWtihgh5MW/x4L7viljYl21r1liW1gbkeixvn9mBycfWQpOHWCkF1Q==
X-Received: by 2002:aa7:cd67:0:b0:633:d0b7:d6c3 with SMTP id 4fb4d7f45d1cf-6349f9cab40mr4466363a12.5.1758877135297;
        Fri, 26 Sep 2025 01:58:55 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------xXuEtxmw2kSPDrCxIxO0c1JV"
Message-ID: 
Date: Fri, 26 Sep 2025 10:58:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/18] xen/riscv: implement p2m_set_range()
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: 
 <5e325267a792a9a0f4cb387b4e3287d22dc8d173.1758145428.git.oleksii.kurochko@gmail.com>
 <6ee4846e-dd27-4588-aac5-f2fe2937db18@suse.com>
 
 <6b62cf4c-8367-47dc-9911-206c220fb050@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <6b62cf4c-8367-47dc-9911-206c220fb050@suse.com>

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


On 9/26/25 9:07 AM, Jan Beulich wrote:
> On 25.09.2025 22:08, Oleksii Kurochko wrote:
>> On 9/20/25 1:36 AM, Jan Beulich wrote:
>>> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>>>> +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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
>>>> +    if ( root_table_indx >= P2M_ROOT_PAGES )
>>>> +        return NULL;
>>>> +
>>>> +    /*
>>>> +     * The P2M root page table is extended by 2 bits, making its size 16KB
>>>> +     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
>>>> +     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
>>>> +     * only allocates 4KB pages).
>>>> +     *
>>>> +     * To determine which of these four 4KB pages the root_table_indx falls
>>>> +     * into, we divide root_table_indx by
>>>> +     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
>>>> +     */
>>>> +    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);
>>> The subtraction of 1 here feels odd: You're after the root table's
>>> number of entries, i.e. I'd expect you to pass just P2M_ROOT_LEVEL.
>>> And the way P2M_PAGETABLE_ENTRIES() works also suggests so.
>> The purpose of this line is to select the page within the root table, which
>> consists of 4 consecutive pages. However, P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL)
>> returns 2048, so root_table_idx will always be 0 after devision, which is not
>> what we want.
>>
>> As an alternative, P2M_PAGETABLE_ENTRIES(0) could be used, since it always
>> returns 512. Dividing root_table_idx by 512 then yields the index of the page
>> within the root table, which is made up of 4 consecutive pages.
>>
>> Does it make sense now?
> Yes and no. I understand what you're after, but that doesn't make the use of
> P2M_PAGETABLE_ENTRIES() (with an arbitrary level as argument) correct. This
> calculation wants doing by solely using properties of the top level.

Got it, thanks. Then I will use solely properties of the top level.

>>>> +static int p2m_set_entry(struct p2m_domain *p2m,
>>>> +                           gfn_t gfn,
>>>> +                           unsigned long page_order,
>>>> +                           mfn_t mfn,
>>>> +                           p2m_type_t t)
>>> Nit: Indentation.
>>>
>>>> +{
>>>> +    unsigned int level;
>>>> +    unsigned int target = page_order / PAGETABLE_ORDER;
>>>> +    pte_t *entry, *table, orig_pte;
>>>> +    int rc;
>>>> +    /*
>>>> +     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
>>>> +     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
>>>> +     * are still allowed.
>>>> +     */
>>>> +    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
>>>> +    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
>>>> +
>>>> +    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, gfn);
>>>> +    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
>>>> +        {
>>>> +            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
>>>> +            /*
>>>> +             * 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).
>>> I thought I commented on this or something similar already: Calling the
>>> p2m tree "read-only" is imo misleading.
>> I will change then "read-only" to "not allocatable".
> That'll be only marginally better: What's "allocatable"? Why not something
> like "... does not exist and none should be allocated"? Or maybe simply
> omit this part of the comment?

Agree, "allocatable" could be also confusing. Perhaps, just omitting will
be fine.

>
>>>> +    /*
>>>> +     * Free the entry only if the original pte was valid and the base
>>>> +     * is different (to avoid freeing when permission is changed).
>>>> +     *
>>>> +     * If previously MFN 0 was mapped and it is going to be removed
>>>> +     * and considering that during removing MFN 0 is used then `entry`
>>>> +     * and `new_entry` will be the same and p2m_free_subtree() won't be
>>>> +     * called. This case is handled explicitly.
>>>> +     */
>>>> +    if ( pte_is_valid(orig_pte) &&
>>>> +         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
>>>> +          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
>>>> +        p2m_free_subtree(p2m, orig_pte, level);
>>> I continue to fail to understand why the MFN would matter here.
>> My understanding is that if, for the same GFN, the MFN changes fromMFN_1 to
>> MFN_2, then we need to update any references on the page referenced by
>> |orig_pte| to ensure the proper reference counter is maintained for the page
>> pointed to byMFN_1.
>>
>>>    Isn't the
>>> need to free strictly tied to a VALID -> NOT VALID transition? A permission
>>> change simply retains the VALID state of an entry.
>> It covers a case when removing happens and probably in this case we don't need
>> to check specifically for mfn(0) case "mfn_eq(pte_get_mfn(*entry), _mfn(0))",
>> but it would be enough to check that pte_is_valid(entry) instead:
>>     ...
>>     (removing_mapping && !pte_is_valid(entry)))) )
>>
>> Or only check removing_mapping variable as `entry` would be invalided by the
>> code above anyway. So we will get:
>> +    if ( pte_is_valid(orig_pte) &&
>> +         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) || removing_mapping) )
>> +        p2m_free_subtree(p2m, orig_pte, level);
>>
>> Does it make sense now?
> Not really, sorry. Imo the complicated condition indicates that something is
> wrong (or at least inefficient) here.

Then, in the case of aVALID -> VALID transition, where the MFN is changed for the
same PTE, should something be done with the old MFN (e.g., calling|p2m_put_page()|
for it), or can freeing the old MFN be delayed until|domain_relinquish_resources() |is called? If so, wouldn’t that lead to a situation where many old MFNs accumulate
and cannot be re-used until|domain_relinquish_resources()| (or another function that
explicitly frees pages) is invoked?

If we only need to care about theVALID -> NOT VALID transition, doesn’t that mean
|p2m_free_subtree()| should be called only when a removal actually occurs?

~ Oleksii


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



  
    
  
  
    


    

    
On 9/26/25 9:07 AM, Jan Beulich wrote:

    

    

      
On 25.09.2025 22:08, Oleksii Kurochko wrote:


      

        
On 9/20/25 1:36 AM, Jan Beulich wrote:


        

          
On 17.09.2025 23:55, Oleksii Kurochko wrote:


          

            
+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) >> P2M_LEVEL_ORDER(P2M_ROOT_LEVEL);
+    if ( root_table_indx >= P2M_ROOT_PAGES )
+        return NULL;
+
+    /*
+     * The P2M root page table is extended by 2 bits, making its size 16KB
+     * (instead of 4KB for non-root page tables). Therefore, p2m->root is
+     * allocated as four consecutive 4KB pages (since alloc_domheap_pages()
+     * only allocates 4KB pages).
+     *
+     * To determine which of these four 4KB pages the root_table_indx falls
+     * into, we divide root_table_indx by
+     * P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1).
+     */
+    root_table_indx /= P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL - 1);


          

          
The subtraction of 1 here feels odd: You're after the root table's
number of entries, i.e. I'd expect you to pass just P2M_ROOT_LEVEL.
And the way P2M_PAGETABLE_ENTRIES() works also suggests so.


        

        
The purpose of this line is to select the page within the root table, which
consists of 4 consecutive pages. However, P2M_PAGETABLE_ENTRIES(P2M_ROOT_LEVEL)
returns 2048, so root_table_idx will always be 0 after devision, which is not
what we want.

As an alternative, P2M_PAGETABLE_ENTRIES(0) could be used, since it always
returns 512. Dividing root_table_idx by 512 then yields the index of the page
within the root table, which is made up of 4 consecutive pages.

Does it make sense now?


      

      
Yes and no. I understand what you're after, but that doesn't make the use of
P2M_PAGETABLE_ENTRIES() (with an arbitrary level as argument) correct. This
calculation wants doing by solely using properties of the top level.

    

    
Got it, thanks. Then I will use solely properties of the top level.



    

      

        

          

            
+static int p2m_set_entry(struct p2m_domain *p2m,
+                           gfn_t gfn,
+                           unsigned long page_order,
+                           mfn_t mfn,
+                           p2m_type_t t)


          

          
Nit: Indentation.



          

            
+{
+    unsigned int level;
+    unsigned int target = page_order / PAGETABLE_ORDER;
+    pte_t *entry, *table, orig_pte;
+    int rc;
+    /*
+     * A mapping is removed only if the MFN is explicitly set to INVALID_MFN.
+     * Other MFNs that are considered invalid by mfn_valid() (e.g., MMIO)
+     * are still allowed.
+     */
+    bool removing_mapping = mfn_eq(mfn, INVALID_MFN);
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
+
+    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, gfn);
+    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 == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
+        {
+            rc = (rc == P2M_TABLE_MAP_NONE) ? -ENOENT : -ENOMEM;
+            /*
+             * 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).


          

          
I thought I commented on this or something similar already: Calling the
p2m tree "read-only" is imo misleading.


        

        
I will change then "read-only" to "not allocatable".


      

      
That'll be only marginally better: What's "allocatable"? Why not something
like "... does not exist and none should be allocated"? Or maybe simply
omit this part of the comment?

    

    
Agree, "allocatable" could be also confusing. Perhaps, just omitting will
be fine.


    

    

      



      

        

          

            
+    /*
+     * Free the entry only if the original pte was valid and the base
+     * is different (to avoid freeing when permission is changed).
+     *
+     * If previously MFN 0 was mapped and it is going to be removed
+     * and considering that during removing MFN 0 is used then `entry`
+     * and `new_entry` will be the same and p2m_free_subtree() won't be
+     * called. This case is handled explicitly.
+     */
+    if ( pte_is_valid(orig_pte) &&
+         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) ||
+          (removing_mapping && mfn_eq(pte_get_mfn(*entry), _mfn(0)))) )
+        p2m_free_subtree(p2m, orig_pte, level);


          

          
I continue to fail to understand why the MFN would matter here.


        

        
My understanding is that if, for the same GFN, the MFN changes fromMFN_1 to
MFN_2, then we need to update any references on the page referenced by
|orig_pte| to ensure the proper reference counter is maintained for the page
pointed to byMFN_1.



        

          
  Isn't the
need to free strictly tied to a VALID -> NOT VALID transition? A permission
change simply retains the VALID state of an entry.


        

        
It covers a case when removing happens and probably in this case we don't need
to check specifically for mfn(0) case "mfn_eq(pte_get_mfn(*entry), _mfn(0))",
but it would be enough to check that pte_is_valid(entry) instead:
   ...
   (removing_mapping && !pte_is_valid(entry)))) )

Or only check removing_mapping variable as `entry` would be invalided by the
code above anyway. So we will get:
+    if ( pte_is_valid(orig_pte) &&
+         (!mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) || removing_mapping) )
+        p2m_free_subtree(p2m, orig_pte, level);

Does it make sense now?


      

      
Not really, sorry. Imo the complicated condition indicates that something is
wrong (or at least inefficient) here.

    

    
Then, in the case of a VALID -> VALID transition, where the MFN is changed for the
same PTE, should something be done with the old MFN (e.g., calling p2m_put_page()
for it), or can freeing the old MFN be delayed until domain_relinquish_resources()
is called? If so, wouldn’t that lead to a situation where many old MFNs accumulate
and cannot be re-used until domain_relinquish_resources() (or another function that
explicitly frees pages) is invoked?

    
If we only need to care about the VALID -> NOT VALID transition, doesn’t that mean
p2m_free_subtree() should be called only when a removal actually occurs?

~ Oleksii


    

    

  


--------------xXuEtxmw2kSPDrCxIxO0c1JV--


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 09:37:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 09:37:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131371.1470487 (Exim 4.92)
	(envelope-from )
	id 1v24t9-00060u-Ki; Fri, 26 Sep 2025 09:37:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131371.1470487; Fri, 26 Sep 2025 09: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 1v24t9-00060n-Hz; Fri, 26 Sep 2025 09:37:15 +0000
Received: by outflank-mailman (input) for mailman id 1131371;
 Fri, 26 Sep 2025 09:37: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 1v24t8-00060h-JT
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 09:37:14 +0000
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com
 [2607:f8b0:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60e69191-9abc-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 11:37:13 +0200 (CEST)
Received: by mail-pg1-x52c.google.com with SMTP id
 41be03b00d2f7-b5526b7c54eso1234564a12.0
 for ; Fri, 26 Sep 2025 02:37: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: 60e69191-9abc-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758879431; x=1759484231; 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=l25PVufoEze1lltftXdbDqYNubL4UHrPe2LpDNcvXBY=;
        b=f65lQzQpW7ZlRdm3wVTvZO+qOAlJyrXP/Id3K9fMy/FpstSnoJYtPlvKJbSBvwcjQr
         v1L6oLxzyjivbErdYQt1jHdROVE6U3gF/ECF1/aMc6Ql5MY/d8Gf00Y1LGqPgH2PrPGb
         rykw/gd5bmWa70f6pNOqb4umUfvuhIvKXq6JP/mOFgG6e1RvN06R1+Tyj5YT1LecPsbj
         24fgh4evyGVVNh1nVOzfc4nDSbYHD+OqPcP5BAq8P7r3T17PEN0/lKHC2vTdz7S8Zt2C
         RhlUG6KuEg9PCpXBfEMSqhs2JWFH4EzxelvzPfcQiXjulK4MHjEFlBXEdRLU5QvLorRo
         E1Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758879431; x=1759484231;
        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=l25PVufoEze1lltftXdbDqYNubL4UHrPe2LpDNcvXBY=;
        b=Oh2XbrspzYcIXvtu8FtwsWG8IHprfgW7fQgboQ3Qau1OP3grfEgabd0XAq5RIW7PdD
         RYK2bd1P3YyYT09Pwc5C3PrwPYwETuZcI48c3FT+SO7htc54pbH/MQJ4n27vfLt8OmkD
         MgdhPgJNcjr3JL8RzVxgqmS9vXp4n3nc7VzO8hxN+F8z/SuJhy6nTRCVJRHp44FWuOId
         oNLUNd+cq/EtMFjLh5PGhhnXHiPWgGhC35YZAxckqfB252RjRcgB/Lgg7/ONuiK5Gd5h
         iyDC4gMr2i42zh1ij37TV5XDwxN7Qvo9BJwxZ2GIKnY+oHUflYXr8hto8PYo+XUj+1u/
         /bBQ==
X-Gm-Message-State: AOJu0YxIv7SssPOgXgznqP6wT+aYLgY0Tyvqqtxoosz3fesNTWX4Ahrh
	6GCTcu7eFrwdTQ5h0YVTIO9ZaSx//ekeqARuohhhpVQAZTg3+kGBFMX66OV8c3uTZFVyDiW9l8N
	z//IwmHcYQgXcJtlk6nobMDU/zug43qY=
X-Gm-Gg: ASbGnct4EVUxCyGIrxCJykhTUE5cwGF+61J7F+4kiF2v9GciGp3fMdlNLFqX7tRnS3G
	S0CRQZ0/9ZaMbNtorECQpj5wl3HbfWTFy1JVqPAPDxFmm1BDixY2PKwZ8bK9EF2jqLLGwzEXK/W
	6X6z/ROJgXWkQ6T9u1pQZ8+Ebtv2h+JbZeipAjJyYJXtVeEKAmi/Dr52Jny1ifQHREjkiAsqtHW
	KmilvvmZ4ksCqR+hFV+YmXIXQ==
X-Google-Smtp-Source: AGHT+IGvR8SV/U37a8hFNtpHhTlAXy36hymiGG+1KSM38jqu6jDkntFCoeNI1IUJ2lkHyDsjyYW6NJT7Es7Kd9I59R4=
X-Received: by 2002:a17:902:da2d:b0:269:8fa3:c227 with SMTP id
 d9443c01a7336-27ed4a06e11mr63322165ad.8.1758879431129; Fri, 26 Sep 2025
 02:37:11 -0700 (PDT)
MIME-Version: 1.0
References: 
 <9a2c77f3-fbdf-4d8a-8793-7d75f9ffb538@suse.com>
In-Reply-To: <9a2c77f3-fbdf-4d8a-8793-7d75f9ffb538@suse.com>
From: Igor Korkin 
Date: Fri, 26 Sep 2025 12:36:59 +0300
X-Gm-Features: AS18NWBpkFu3A_mdBzBkqIT9gHx5bnplecRr_TC30gGI5cz2NTWt3qPb9Ct8GV4
Message-ID: 
Subject: Re: [Question] Unexpected growth of nr_cpu in `credit` Xen scheduler?
To: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for the answer

The information about xl debug-keys r I will provide soon.

Here is the output of `xl info`:

developer@host:~$ sudo xl info
host                   : host
release                : 6.1.0-38-amd64
version                : #1 SMP PREEMPT_DYNAMIC Debian 6.1.147-1 (2025-08-0=
2)
machine                : x86_64
nr_cpus                : 48
max_cpu_id             : 47
nr_nodes               : 2
cores_per_socket       : 12
threads_per_core       : 2
cpu_mhz                : 2100.002
hw_caps                :
bfebfbff:77fef3ff:2c100800:00000121:0000000f:f3bfbfff:00405f4e:00000100
virt_caps              : pv hvm hvm_directio pv_directio hap shadow
iommu_hap_pt_share vmtrace gnttab-v1 gnttab-v2
total_memory           : 130724
free_memory            : 54067
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 19
xen_extra              : .3-pre
xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p
hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : Tue Jan 30 21:22:03 2024 +0100 git:199f7986eb-dirt=
y
xen_commandline        : placeholder hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1
hpet=3Dlegacy-replacement sched=3Dcredit dom0_mem=3D-54068M,max:-54068M
dom0_max_vcpus=3D48 dom0_vcpus_pin=3D1 force-ept=3D1 ept=3Dad=3D0 max_cstat=
e=3D0
dom0-iommu=3Dpassthrough=3D1 watchdog=3Dforce watchdog_timeout=3D20
spec-ctrl=3Dno no-real-mode edd=3Doff
cc_compiler            : x86_64-linux-gnu-gcc (Debian 12.2.0-14+deb12u1) 12=
.2.0
cc_compile_by          : pkg-xen-devel
cc_compile_domain      : lists.alioth.debian.org
cc_compile_date        : Tue Sep 23 08:15:41 UTC 2025
build_id               : c3666203ea8a9657a1bcf35f963e9371e5cb51dd
xend_config_format     : 4


developer@host:~$ sudo xl cpupool-list
Name               CPUs   Sched     Active   Domain count
Pool-0              48   credit       y


developer@host:~$ sudo dmesg | grep -i hotplug
[    3.167091] smpboot: Allowing 48 CPUs, 0 hotplug CPUs


Thank you!


On Fri, Sep 26, 2025 at 11:04=E2=80=AFAM Juergen Gross  wr=
ote:
>
> On 26.09.25 09:17, Igor Korkin wrote:
> > Hi all,
> >
> > I'm observing a steady and abnormal increase in the `nr_cpu` value
> > reported by the `credit` Xen scheduler
> > (visible via `sudo xl dmesg; sudo xl debug-keys r`).
> >
> >
> > This behavior occurs consistently when the system is subjected to
> > heavy synthetic load (e.g., multiple VMs running stress workloads that
> > fully saturate vCPUs).
> > Over time, `nr_cpu` grows far beyond the actual number of physical or
> > logical CPUs (48 in our case), and this correlates with noticeable
> > performance degradation, especially under high VM density.
>
> Can you please share the related output? Especially one instance of
> the "xl debug-keys r; xl dmesg" before the test is starting, and one
> with the wrong number of cpus in the data.
> > We=E2=80=99re running on a dual-socket x86_64 server (2 =C3=97 12-core =
Intel Xeon
> > Silver 4310 CPUs with Hyper-Threading, total 48 logical CPUs) under
> > Xen 4.19.
> >
> > Is this growth of `nr_cpu` expected in the credit scheduler?
> > If not, it may indicate a bug in CPU accounting or runqueue management
> > that warrants further investigation.
> >
> >
> > Environment details:
> > - xen_version            : 4.19.0-5.25.0.38431
> > - xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32
> > hvm-3.0-x86_32p hvm-3.0-x86_641
> > - xen_scheduler          : credit
> > - Hardware : Dual-socket Intel Xeon Silver 4310 @ 2.10GHz (12
> > cores/socket, HT enabled, 48 logical CPUs)
> > - NUMA nodes : 2
> > - Dom0 kernel : Debian 6.1.147-1 (6.1.0-38-amd64, SMP PREEMPT_DYNAMIC)
> > - nr_cpus                : 48
> > - nr_nodes               : 2
> > - release                : 6.1.0-38-amd64
> > - version                : #1 SMP PREEMPT_DYNAMIC Debian 6.1.147-1 (202=
5-08-02)
> > - machine                : x86_64
> > - nr_nodes               : 2
> > - cores_per_socket       : 12
> > - threads_per_core       : 2
> > - cpu_mhz                : 2100.000
> > - virt_caps              : pv hvm hvm_directio pv_directio hap shadow
> > iommu_hap_pt_share vmtrace gnttab-v1 gnttab-v2
> > - total_memory           : 130724
> > - free_memory            : 54064
> Please share the complete "xl info" output, including the xen command lin=
e.
>
> Are there any cpupools involved? Any cpu hotplug operations?
>
>
> Juergen


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 09:46:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 09:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131383.1470498 (Exim 4.92)
	(envelope-from )
	id 1v251b-0007Zb-E7; Fri, 26 Sep 2025 09:45:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131383.1470498; Fri, 26 Sep 2025 09:45: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 1v251b-0007ZU-AS; Fri, 26 Sep 2025 09:45:59 +0000
Received: by outflank-mailman (input) for mailman id 1131383;
 Fri, 26 Sep 2025 09:45: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 1v251Z-0007ZN-Mx
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 09:45:57 +0000
Received: from PH8PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170120001.outbound.protection.outlook.com
 [2a01:111:f403:c107::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 985db177-9abd-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 11:45:55 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB8187.namprd12.prod.outlook.com (2603:10b6:610:125::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.10; Fri, 26 Sep 2025 09:45:49 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.9160.011; Fri, 26 Sep 2025
 09:45: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: 985db177-9abd-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iDXp5Fh0K51BKR1v8GAqIuiEKsJrWuBK98ii/Igpx2rQBqklH4bEshgyAZVrDk8olbqjZUVrtF+NEpL0U7qSTCyjx7yaBWoGk/1m4DSX4SkU6ddtGngJyvV2X2zOAuRspB3ntfLDpMTh72XVOvLA8nHrsAve0LsdIvaAjRZxo2f5Cc6Vd5fDz2UAWbsMO7S72Vmta3RBD8SvdUm5/GLColWrPK35/FoeHbY7dg71+BiY7G05sOOFOBMJuN4CpEucEYZnCUSqYukldVfdwZQAx2LgiB+X9iEcH2vsPf9gwCD12MeVyetlpF9/VxuK5HtGnnJFq2/fQMVWxW3MqyPeLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=N8ayv8MzhWLcUDGe5sHhGVo9rUojz+kJ07hGrIQs6og=;
 b=uFf563sDTT3u7BYKM3Ir80Fjr33w6hNi+N4kCucYEbGKsjjOFZOBa3xhCMNlQnha56xtHu5TH6pxiAv6xtYxJhTgeKur/vRqdfU/MSUoTd/+5dWSQhIAkZM/BjCUXMa85/udyJbB0stCylURVEGjzuPa6JDDbrVppWTGvZBipwPpROiMUYT+ZTbiarpXdjv6R+6inxIhGZfUveUTKTbbaUIcZQAUCWIFcrqdShRFBpQwYcp8scE8movLniNzBxAc+0PuoFs2v/JJlksvjOQE02zUhPv+EhrfJQkifndNQ1kgVr5UllatK+PrOVQYS4zlM1drPJSC9/HJtUB5L7Peow==
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=N8ayv8MzhWLcUDGe5sHhGVo9rUojz+kJ07hGrIQs6og=;
 b=OzF2IqsPzuu1lwUx+MRIgvHCaxexhRVy6fZIc5rAboyzZwl9f0zAkkmemyv6yDiG6djTDIasFu6ysQmh80SrKB/8p5R7C69BXOE9bTEFApBqqb83Q1xi7VAOUyCF5xNopKiXng16yBzWlnZzyCnL+he/VghykTyjgAMBG739Z4g=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, "Orzel, Michal" , Andrew
 Cooper , Anthony PERARD
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk , Rahul
 Singh , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2 20/26] xen/domctl: wrap iommu-related domctl op with
 CONFIG_MGMT_HYPERCALLS
Thread-Topic: [PATCH v2 20/26] xen/domctl: wrap iommu-related domctl op with
 CONFIG_MGMT_HYPERCALLS
Thread-Index: AQHcIiYdoRXj4d7euECxgRPy0m3CSbSN4o2AgBdh+wA=
Date: Fri, 26 Sep 2025 09:45:49 +0000
Message-ID:
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-21-Penny.Zheng@amd.com>
 <0af66ec5-a53e-4f09-96bd-3cedb7419006@suse.com>
In-Reply-To: <0af66ec5-a53e-4f09-96bd-3cedb7419006@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-09-26T09:03: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_|CH3PR12MB8187:EE_
x-ms-office365-filtering-correlation-id: 211a46ef-9474-4124-feb9-08ddfce179c1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bDBaWmp0N2ZWU3p2dWU4TkRsQW9DZVBQQW1ITENPeFVCRmEwVXdqM1NSUGNK?=
 =?utf-8?B?c2ovUnRMUVlkeHZXUmhhTnVGZ05KbW8xYnJMVHlmNHpFaXpWbFZNLy9HQ0Vz?=
 =?utf-8?B?VlpIVDhCT011MCtOOElBblhCWnNXMXhidFl0T2M1clhDLzg1ZnJuOVdRSWJa?=
 =?utf-8?B?YzFXcWprK3ptUXhYUGw2d3hkV0d5bGU5cXUyRXM4RlQ0TkJ0enJPbDZiOE5B?=
 =?utf-8?B?VUZhUnRhbVpEb0RWbnE1c0tXK2FBS3kycWx2WC9lYktTNXU3SEdXcmh1anFr?=
 =?utf-8?B?TUM1MXBJTTA2bC9NaE8wMUdMMXhKc290V3VLMWg1WWZLQXk5ZW1ZaXVncm56?=
 =?utf-8?B?amVyYldzL3FPWTlCYm9NMUY0Ullaa3ljcEE4OFd6RFJrQ3BubklnU1hvTkU5?=
 =?utf-8?B?dDhqRHBpcEpjN3lqZU1xOEg0ZUg0ZTVnZmxLQUxWZVpWSkVqdnI1NUpDNkdX?=
 =?utf-8?B?TzBkSXI0bk9aWDJpdDhiQkVwNUZWMkxVOWdGMTBCeTE4cFdRSks0Q1g5UUJC?=
 =?utf-8?B?elB3SzlKcTFJT09JczI1dDZ4aXAyTlBOdFFNMXBnMU9WY2RsdVFmRllJUXNQ?=
 =?utf-8?B?Y3hVaHcyOWxDUGRTRnVONkVodElYdjJ2UUdzSzlUSVZPeUdpT25yT1JVdnhM?=
 =?utf-8?B?bVVsQ3l6RnlaM3lVaEMwYXRNbzZXenZGR0RWd05VaHU5M1hDbWp3cVFYN1lR?=
 =?utf-8?B?MVlzUHRZRENoOWFid1l3S216UHpkRXp3djEvb0NEM2IwU2s3TUlmTFAzem1H?=
 =?utf-8?B?LzhYUENmWlREK3pwRURwa3JzcWRBVnd1MjFrQVN4U1M0cTVxMGV2b05CNThU?=
 =?utf-8?B?SGZxbUV5SnRkcG43TU9zWWZRSnppblpNQTB3Q0N6TjVVcHlhU3BGNmhVNjVt?=
 =?utf-8?B?VGwvVzk5dmNubWxzSlVmWW1BS0lCWnk2WUUvNTU2TWVDcGQwK3dpWEI0b1Aw?=
 =?utf-8?B?MXR4ejIxaVNxSzF6VU9TVkx2aWkrUVI2dzV3RG1RcTIySitFSENHanowY09v?=
 =?utf-8?B?Z0VwY2JQUUxCa0JCYTFxOXFTQ3ArOGRNd2NKZTNHRnpyZ1NLWU5uQ3l1V3JS?=
 =?utf-8?B?ZzV4OFBSM0Q1SE9oSnJHbkpGYVNqN05nSDRYbXVOWjIvMDdHMEUzWVhrM01J?=
 =?utf-8?B?ZndxM05GYm5DSDBqbkxJRXZnREl1ZEd3MElxKzZ3ZWxsTUxKa20zZlBqUWo5?=
 =?utf-8?B?MklFLzhUL2hySDV6RnZoVlkzY1lLZloycm5ZUVRnRlJHRXhJSU5wd2I1N3U2?=
 =?utf-8?B?aXV4dnVCc1lPYXBxTC9FWFhVSDlrVGoyV1JReGtnVGQvQTZHaFZlSXF5ZTI4?=
 =?utf-8?B?OXdZUCtlRnhGbVZrUWE4bW9BQ3NydDl0a1pXTVVRSVpsUEFqeWhNak1QVVNj?=
 =?utf-8?B?c1drQ1B4bUl2WDBjcFl0aFpuSmZScVlLNHk1bjlESkdBUkNEb1YzdGVCVVZM?=
 =?utf-8?B?UVF4ekNiK2NSa3o3MENYNWxQUFRzemlKd09IYzRqM0JXMVV3b0Ntak9UZHBB?=
 =?utf-8?B?cXNMcEZnWVM5TTJvZE5uZmdhN2loSnZUMlFacEJZN1RMTkZCM08rbDhnNXVP?=
 =?utf-8?B?ZVhKMEdHM21oRDNhMWxxVGRxdmZFNk5TKzlWUCtaaFM1SGpSOVptQjdCL1pU?=
 =?utf-8?B?ZWhpUVF2b3JwL3d4TXZGcmJWeWlIN0d1YzFXbzQ3RXBpQkNSakZvMWtIcDBT?=
 =?utf-8?B?VUZoZWdvM1VwOVU2bEZrSUJYelpXVE1KYW16cFdJMzVMcjVTZGdYbHQrbk1R?=
 =?utf-8?B?SEpFVWJPSmhyRTRLaDRTNjBxRnVsM0pudjQrS0ozNy9BWmlQRkRsV1FTU01T?=
 =?utf-8?B?ZStlUFc1UWpPZzErUlB2SGdsMGhzZnBQZHIzOGhlZ3lQYnozak9wVEZTOHpI?=
 =?utf-8?B?bGtCWUh2ck5BcXFFZlVSaWRUNVpndHFEdXRweWsxelBaWCs5Q01GK0xBYXl6?=
 =?utf-8?B?SGVubHl2N3FQdTdUc1dzS29BOFVEa0RFRy9rbGpSUTByM2Q3UzVRN2h6dUpU?=
 =?utf-8?Q?K6dWtyWiipB9AV5M0cuKfxFN2PY1Vo=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)(7416014)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WVBISDFmcTVwM1J3cVgyalhYMGlZdndMZzhhNENXMERwWnhaN3gyRXI2cVJ3?=
 =?utf-8?B?aDR5THdKM0RMc1dqKzhJZ0g3bHdEbHNWbEZadnZ5SHpPRkxjSEdkTnRVNkg3?=
 =?utf-8?B?UVRoeFJmRDZ0SU9MNTdnZ08zR0hoMjVtR0d6dGJGaDRmNksxVHI2NVo1MFBG?=
 =?utf-8?B?ZzBzb2NyTkVielkrU3c0ZU1NREFjekYzV1FUQ2U3Uk1kMjcrb2pidS9RbDls?=
 =?utf-8?B?RmdOVUt0Q0RzWEpwTnhzRGdzZ0x5OEF2TmRWNWtuTURQOXlabEpnWituZWEy?=
 =?utf-8?B?NTBEVTM4eGxkblU0U01KZm1kWnV2a0VudnNxWS8rTVBMOW4yUldJaXFheVN6?=
 =?utf-8?B?N05udlFaN1BEbjdyZzdKVlNzVy80ZVMvN3g2WUNZY250MXdkdXBaeWZuY3Mz?=
 =?utf-8?B?TGNqSEYzcitqM3N0bFd0cUFsVTZLN2MrcEF3SHcvcFBrLzhDV1ZsZHFOZ05x?=
 =?utf-8?B?Rm40eDRQVVArYlpLT2hZQVBJaXRlSGpXVlFrb3FqS0dHMWk3SVZvMDZJbWlj?=
 =?utf-8?B?OTNmWjQ3MzlVb0ZZRVI5NHJHdUVLeHJnYklCV1A4Q3dKODFId1IxVUhCekww?=
 =?utf-8?B?a3U1UTdpY1BOd3lHSmI1OWxFRVlCNFdyMGdxV1pQdHlxekdiSmFoV3phS05N?=
 =?utf-8?B?enBGSDg0cTQzanBQd0h4MEErN3VzZ3ptOVFvQ3JRZVo1UGZUUmxIcGtRZjFx?=
 =?utf-8?B?WXpxcEhBZDQ0OE9zVlhhVUp4MnJ6T2J5anJ3bFZ3cUZ5MkZuVURGZGxCazVz?=
 =?utf-8?B?Y3dVR1hnWnNIV2VUNWIrQURXdEVWZVZkd0xuREZacURoR0VMWFNkdE9jcGRO?=
 =?utf-8?B?MGtlMEdYU29PdHJqSTN3RE40dDNzcllNdDRTVlRnWGRvQ2FNM2tVRm95U2ZM?=
 =?utf-8?B?MHVkODlEWnNTYjR0Vlo2eXZmMGpxamh1U2JHOTFRaXB2UnZRNkQvVDAwckha?=
 =?utf-8?B?dU5MNkNiRE1BZHVNQ05ac2xXbFZwL1d4bklWeGd1UUJJS0dMaXY0V1l4Y3Nm?=
 =?utf-8?B?ajdGcGZIcEZtNGFXeG9qNDQvamRsYUk1SUY0ZEg1RE4rNzNyaFVhMXg1UlRn?=
 =?utf-8?B?WTVPUG4wRFRyeGdCc0x0L0puNUZxWTFYS1ZtVEhZWm1uTHN2bWZ6eUxJYkxC?=
 =?utf-8?B?UnUvbUhSb0NudmVEaUZ6cEUxcHlkSVZoTW5HZDduVDI3NDlFVzBtMGNLQWZz?=
 =?utf-8?B?RVVRRVgvYnIyd0NwQlNTd2xpZVlUOFpIcHhSYWFudk9zcEVPNHNFT2xrazJM?=
 =?utf-8?B?ZXIzOUhFZGJaRFB4RjFUc0UxVWlDYnBpQ0F3am52Y0tkY1RaNmsvY0hTZVZj?=
 =?utf-8?B?KytJY1ZwVG9mWEE3OXlCT2ZUa1ZJNDZ2dFI5R2YrZ2hoYzVIanAzbCs3cjBY?=
 =?utf-8?B?MzFiUGdUR2ZpTU1HaGdGS1g1MEF0RW5Lcno0QWRUUGJYL0tlUlJCV21wRTFI?=
 =?utf-8?B?YUtOaTV1KzNPY1NnNW9Tc1d2TXBvSEVBUFd3OFFnRUtSRjZOcitWY010ZEgy?=
 =?utf-8?B?VFJhNEtTMk1oWDZEYXlSVUh0cjlrMnQ3cmxyYTRvNGJNTFJZUWYva3I1V2FK?=
 =?utf-8?B?cXNncTFCWTZqeENHVEZTS2w4L0lUMFZyc2taWlpLemhGVnR6ZFpmTWpjYkNL?=
 =?utf-8?B?Wi9rUXZuNEhwRGorVHNSbnZsaHA5MXhuUXI3YW13R080Vjh6dENNQmlhdlFk?=
 =?utf-8?B?OGltSmlkbHBhZG8vVzVYOXB4RkZVWFM3T244TGgreWozM2poQ1FBSkVEcUUv?=
 =?utf-8?B?N1oxSjFlYUFoY3J4eVcxNHNXSWhiNzZ1ZTlMZUVPby9VSmZDZmRWRXEwQ0kx?=
 =?utf-8?B?b0g2cnlOUVFWTzZLc1RqQWpWL2ZFRHg0NWg1dHRIOFQ3aHZUS0J0ZDhJQmxi?=
 =?utf-8?B?WWNkQm5MN0x0dzFCNy9mbGpJaFdvLzNrN25nMzdJV3JnR2FwaGNSZUdSWkZM?=
 =?utf-8?B?clhxS05nODJKNWhpYkNKV2tLVWRkS3FPYUxLdUdHc0NIaFhhc0UyODZmZXZS?=
 =?utf-8?B?dDNmOGZDayszTW5pRTFOcDMvSUUyZWZqZ2FqY2hZa0lCcVVBbXcvemhiakxt?=
 =?utf-8?B?dVltR05kcXhsU1pSZWN5NVBGa3RiTUR2YXRia1ZpN0xjeHg0THg3dC84T1B4?=
 =?utf-8?Q?FANs=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: 211a46ef-9474-4124-feb9-08ddfce179c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2025 09:45:49.6807
 (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: kmThXqmQ4rtQhJR0FNEYxo4Y3XwthQvhN9sJpA9AS15Wzubt8Wx+eQiaswJ+eV+LIMzmV9CjZrysJSWZ5sSTPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8187

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEs
IDIwMjUgNzo1OSBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K
PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBTdGVmYW5vIFN0YWJlbGxpbmkN
Cj4gPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3Jn
PjsgQmVydHJhbmQgTWFycXVpcw0KPiA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPjsgT3J6ZWws
IE1pY2hhbCA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBBbmRyZXcNCj4gQ29vcGVyIDxhbmRyZXcu
Y29vcGVyM0BjaXRyaXguY29tPjsgQW50aG9ueSBQRVJBUkQNCj4gPGFudGhvbnkucGVyYXJkQHZh
dGVzLnRlY2g+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47DQo+IFZv
bG9keW15ciBCYWJjaHVrIDxWb2xvZHlteXJfQmFiY2h1a0BlcGFtLmNvbT47IFJhaHVsIFNpbmdo
DQo+IDxyYWh1bC5zaW5naEBhcm0uY29tPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3Jn
DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMjAvMjZdIHhlbi9kb21jdGw6IHdyYXAgaW9tbXUt
cmVsYXRlZCBkb21jdGwgb3Agd2l0aA0KPiBDT05GSUdfTUdNVF9IWVBFUkNBTExTDQo+DQo+IE9u
IDEwLjA5LjIwMjUgMDk6MzgsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+IEZ1bmN0aW9uIGlvbW11
X2RvX2RvbWN0bCgpIGlzIHRoZSBtYWluIGVudHJ5IGZvciBhbGwgaW9tbXUtcmVsYXRlZA0KPiA+
IGRvbWN0bC1vcCwgYW5kIHNoYWxsIGJlIHdyYXBwZWQgd2l0aCBDT05GSUdfTUdNVF9IWVBFUkNB
TExTLg0KPiA+IFRyYWNraW5nIGl0cyBjYWxsaW5nIGNoYWluLCB0aGUgZm9sbG93aW5nIGZ1bmN0
aW9ucyBzaGFsbCBhbGwgYmUNCj4gPiB3cmFwcGVkIHdpdGggQ09ORklHX01HTVRfSFlQRVJDQUxM
UzoNCj4gPiAtIGlvbW11X2RvX3BjaV9kb21jdGwNCj4gPiAgIC0gaW9tbXVfZ2V0X2RldmljZV9n
cm91cA0KPiA+ICAgICAtIGFtZF9pb21tdV9ncm91cF9pZC9pbnRlbF9pb21tdV9ncm91cF9pZA0K
PiA+ICAgLSBkZXZpY2VfYXNzaWduZWQNCj4gPiAgIC0gYXNzaWduX2RldmljZQ0KPiA+ICAgICAt
IGludGVsX2lvbW11X2Fzc2lnbl9kZXZpY2UvYW1kX2lvbW11X2Fzc2lnbl9kZXZpY2UNCj4gPiAg
IC0gZGVhc3NpZ25fZGV2aWNlDQo+ID4gICAgIC0gcmVhc3NpZ25fZGV2aWNlX293bmVyc2hpcC9y
ZWFzc2lnbl9kZXZpY2UNCj4gPiAtIGlvbW11X2RvX2R0X2RvbWN0bA0KPiA+ICAgLSBpb21tdV9k
ZWFzc2lnbl9kdF9kZXZpY2UNCj4gPiAgICAgLSBhcm1fc21tdV9yZWFzc2lnbl9kZXYvYXJtX3Nt
bXVfcmVhc3NpZ25fZGV2DQo+ID4gICAgIC0gaXBtbXVfcmVhc3NpZ25fZGV2DQo+ID4gICAgICAg
LSBpcG1tdV9kZWFzc2lnbl9kZXYNCj4gPiAgICAgICAgIC0gaXBtbXVfZGV0YWNoX2Rldg0KPiA+
ICAgLSBkdF9maW5kX25vZGVfYnlfZ3BhdGgNCj4gPiBXcmFwIFhFTl9ET01DVExfYXNzaWduX2Rl
dmljZXt0ZXN0X2Fzc2lnbl9kZXZpY2UsZGVhc3NpZ25fZGV2aWNlLA0KPiA+IGdldF9kZXZpY2Vf
Z3JvdXB9LWNhc2UgdHJhbnNpZW50bHkgd2l0aCBDT05GSUdfTUdNVF9IWVBFUkNBTExTLCBhbmQg
aXQNCj4gPiB3aWxsIGJlIHJlbW92ZWQgd2hlbiBpbnRyb2R1Y2luZyBDT05GSUdfTUdNVF9IWVBF
UkNBTExTIG9uIHRoZSB3aG9sZQ0KPiA+IGRvbWN0bC5jIGluIHRoZSBsYXN0Lg0KPiA+DQo+ID4g
U2lnbmVkLW9mZi1ieTogUGVubnkgWmhlbmcgPFBlbm55LlpoZW5nQGFtZC5jb20+DQo+DQo+IEFw
YXJ0IGZyb20gYWxsIG9mIHRoZSBhYm92ZSBhbm90aGVyIGFzcGVjdCBiZWNvbWVzIGFwcGFyZW50
IGhlcmU6IFNvbWUgY29kZSBpcw0KPiBjYWxsZWQgYXQgYm9vdCB0aW1lIG9ubHkgb25jZSBtYW5h
Z2VtZW50IGh5cGVyY2FsbHMgYXJlIGNvbXBpbGVkIG91dC4gU3VjaCBjb2RlDQo+IHNob3VsZCB0
aGVuIG1vdmUgdG8gLmluaXQudGV4dCwgc28gd2UgbWF5IG5lZWQgdG8gZ2FpbiBzb21ldGhpbmcg
bGlrZQ0KPiBfX2luaXRfb3JfbWdtdC4gSW1vIHRoYXQgd291bGQgd2FudCBkZWFsaW5nIHdpdGgg
cmlnaHQgaGVyZSwgYnV0IEkgY2FuIGltYWdpbmUNCj4gb3BpbmlvbnMgdG8gZGlmZmVyIG9uIHRo
aXMuDQo+DQoNCkxpa2UgaGFuZGxlX2RldmljZSgpIC0+IGlvbW11X2Fzc2lnbl9kdF9kZXZpY2Uo
KSwgb25jZSBNR01UX0hZUEVSQ0FMTFM9biBjb21waWxlZCBvdXQgdG9vbHN0YWNrIHNjZW5hcmlv
LCB3ZSBvbmx5IGhhdmUgdXNhZ2UgYXQgYm9vdCB0aW1lIGZvciBkb20wbGVzcyBvbiBhcm0uIEFu
ZCBhbHNvIHNldF9nbG9iYWxfdmlycV9oYW5kbGVyKCkgaW4gdGhlIHByZXZpb3VzIGNvbW1pdC4u
LiBBbmQgZG9tYWluX2NyZWF0ZSgpL2RvbWFpbl90ZWFyZG93bigpLi4uDQpJIHJlbWVtYmVyZWQg
dGhhdCB3aGVuIGNoZWNraW5nIGVhY2ggc3dpdGNoLWNhc2UtYmxvY2sgdW5kZXIgZG9fZG9tY3Rs
KCksIGZvciBzb21lIG9mIGl0LCB0aGUgcmVmZXJlbmNlcyBjb3VsZCBiZSBzaW1wbHkgZGl2aWRl
ZCBpbnRvIHR3byB3YXlzOiB0b29sc3RhY2sgYW5kIGJvb3QtdGltZS4gSSBzdWdnZXN0IHRvIGRv
IGl0IG9uIGEgZm9sbG93LXVwIHBhdGNoIHNlcmllIHRvIGdvIHRocm91Z2ggZG9fZG9tY3RsKCkg
YWxsIG92ZXIgYWdhaW4uDQoNCj4gRnVydGhlcm1vcmUsIHdoaWxlIGxvb2tpbmcgYXJvdW5kLCBJ
IG5vdGljZWQgdGhhdCB0aGVyZSdzIGR0X292ZXJsYXlfc3lzY3RsKCksIGVudGlyZWx5DQo+IHVu
Z3VhcmRlZCBkZXNwaXRlIHRoZSBlYXJsaWVyIHN5c2N0bCBzZXJpZXMuIFlldCBpZiB0aGF0IHdv
cmsgKGFuZCBNaXNyYSBjaGVja2luZykNCj4gYXNzdW1lZCBPVkVSTEFZX0RUQj1uLCB0aGVuIHRo
ZXJlJ3MgaW9tbXVfcmVtb3ZlX2R0X2RldmljZSgpIHdoaWNoIGlzIG9ubHkNCj4gdXNlZCB3aGVu
IE9WRVJMQVlfRFRCPXkuDQo+DQoNClRoZSB3aG9sZSBmaWxlIGR0LW92ZXJsYXkuYyBpcyBndWFy
ZGVkIGJ5IENPTkZJR19TWVNDVEwsIGFzIGl0IGlzIGNvbXBpbGVkIHVuZGVyIENPTkZJR19PVkVS
TEFZX0RUQiB3aGljaCBkZXBlbmRzIG9uIENPTkZJR19TWVNDVEwuIFNvLCBkdF9vdmVybGF5X3N5
c2N0bCgpIGlzIGd1YXJkZWQuDQogV2hpbGUsICB5ZXMsIEkgZm9yZ290IGlvbW11X3JlbW92ZV9k
dF9kZXZpY2UoKS4NCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 10:15:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 10:15:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131411.1470508 (Exim 4.92)
	(envelope-from )
	id 1v25UN-0003Fe-IK; Fri, 26 Sep 2025 10:15:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131411.1470508; Fri, 26 Sep 2025 10:15: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 1v25UN-0003FX-Em; Fri, 26 Sep 2025 10:15:43 +0000
Received: by outflank-mailman (input) for mailman id 1131411;
 Fri, 26 Sep 2025 10:15: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 1v25UL-0003FL-7Z
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 10:15:41 +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 c09a2921-9ac1-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 12:15:40 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by GVXPR03MB11091.eurprd03.prod.outlook.com (2603:10a6:150:2aa::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.11; Fri, 26 Sep
 2025 10:15:33 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.008; Fri, 26 Sep 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: c09a2921-9ac1-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ORgHvWrk1G1kxq/4cyIEU2/Ik2R5OGKxLNEibf2KJn7V1q1ba2mh+vmTnF/qlbO/Jbxuy0PjRrt4ok9y3XXO/Ms6KJP/qCy4b/AXGWyAu0fsrxJjcYSlF+MFoHAENvpUGvjwf0+Zrepq2f2PKoXg6LuuCU4Oyd6+GleYFV1z9KlFaEpLr1R/V1u9WPZWSHMpVkRRgIzJl47PF/k5mMBUp7+1X6217azUrGRAdAWvqx0s6GHfl93Ox+LlnHz/AoGgX5O+eDj0peHz1VPGOIDpw4ETuavqRv41lR6UDSRjv2Io06tsbxGK6mhTS/ksAHqyBA8BtIe+S79+f/rGW1JNkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kqsp/BiTQvzhn/fc4wT8/PjtXP2QjbmzR8ieVMF8EUo=;
 b=KgUpS+r5817omUBeblvFSfX+L6EPBPm5jVw+pdovLB2olko2/blP4ec25U7gGysXO5tO4wKyfFmFOv9eKWfG3z3gshLmAIJF2m3ee2DeuxuPNn5UetB8LmAxAETwznFmLNuHHJmW9x6ryDuBaplmA84H4ditZBTYP7MqK6z9GkAqWq5MXKfuiV/VXrNx+AKvPW9T0v8ftDkTkKWArjBHzk6oYS7QBOqnBXUOZ7S/OHpKaIHSnBpceZpx2xtPes94rBA1wYJ7qkhqBEYBdgYZ6a18qSG71E/Pxt82TL3Nvcvu1Oq7DxH1OyIdJwIr51kjTwNsTNdunLu2cpEoSt2fqA==
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=kqsp/BiTQvzhn/fc4wT8/PjtXP2QjbmzR8ieVMF8EUo=;
 b=d2zmBbRHkLXsWkgJDQa7MQqyxzv9EsfUk3/MBoTjhF3LLFR/pBUruRW+z34JWVjR0FAIZ1VAIEPpXujJ47j1fkeORYhS8DSEBIfe26iZZuoc6r1JnRJu2h38wk2+MKrSfQajS9k1YBqptL/ANdjt9kJsZmtQUPooIqrj/tvgjiCcl9vQdvnUdzzVmOhp8cHeP1NF5uxlKAi7R4t51OH8JQriQNE5ifuiadNbo0++0Drj+b2WtXyvmTrm7EDySdcdBnuTxHVLlVHiJpSu8ROl/q8Y+QOz3NSJOIBW/HItEm3mPeD8TNbZq423zhPMU6T2vNmpDsm+kx367xo/VTImmA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Fri, 26 Sep 2025 13:15:32 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: mem_sharing: add dependency from
 CONFIG_INTEL_VMX
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 "xen-devel@lists.xenproject.org" ,
 Tamas K Lengyel 
References: <20250925195607.521021-1-grygorii_strashko@epam.com>
 <9cf8925c-87c6-44ec-9d46-f8b0ed30f94a@suse.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <9cf8925c-87c6-44ec-9d46-f8b0ed30f94a@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0074.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:1f::12) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|GVXPR03MB11091:EE_
X-MS-Office365-Filtering-Correlation-Id: eace240b-35c9-4953-2000-08ddfce5a0f7
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?MjM3SDhTS2V4WTJIN1pDZFNyNHU1UC9IbE56UHhabXcrUTRDNVB3MmpKUTVB?=
 =?utf-8?B?TWFCa3N3aFRmVGx6Qm84MnBGeEJ2MSt0eDJmSDB1VW40NlFGaG83T2NySUpt?=
 =?utf-8?B?VjkyU1pSa2Vid3ZJU0FXZVZIRERFZ3Z1eVJyenhpam1MTzZaSlJFeWJabFJQ?=
 =?utf-8?B?aE5PL2M5L2l1UUt5S04vWHRBaTFQYVhqcWxOUTJwdlo5bnNtcUZOUzY1bzNT?=
 =?utf-8?B?Yzk0UGd1V1cxSkZPam56RDVMMmFJVFFYVklCRktkbHNPTDV6VWlYeHFmekF4?=
 =?utf-8?B?L1VxaDFrSS8wdnFzVUJ3cENoc0toK0c4SEtUN0NsTVNnQjVoSkRxNmtpZVFT?=
 =?utf-8?B?RHpkbkovcGRNZkxCY0dXNXFwUE1jL25ZMEthbXRWTWtZbDhyUFp2VnV0WTdI?=
 =?utf-8?B?aUs5bFJYQXBUc1FQVTdQUTVWZGQwM1lYMU9nWE8raHN6Y0plK3ZQekVXRGZV?=
 =?utf-8?B?SlJTSmpVcWZzY1pMTHp1MW5Dd3NyWlRoTDVVU2tzbW5JT3JWY1U3YjhQNDc1?=
 =?utf-8?B?TFNyTEd2N2ExNXh2WDlZcDFlZTdWYWFobmZtY1FTbUY2eUFRLytPR3RhY1Az?=
 =?utf-8?B?QXFia1h0RXY5TUNtT0dRODFBRzZETk9QV0w1ZWhLTkg5TEdpZVNFZnVzakhL?=
 =?utf-8?B?YWtxOTA2eGt4b3BzNndNUGMyZ1h3NlBRSDRmOHZjaUdIV0hCc2cyMGhvNm9Y?=
 =?utf-8?B?WFNLR1BsS05yOS8zOG13TUh5TGNrbFMzWWlpdGZab2N2cTMrNHpRK1FlUEpk?=
 =?utf-8?B?VEEycllYRW1ra1h4MFJySFRwRkpSMm5HRDM3MG1IbVBtcEc0M051UlJFeVdN?=
 =?utf-8?B?RHptTi8xbnR4bk4yQ0tPRlZNeWNFMXFseTBhdENSdEtkQ0hPWnVwU3ZFYU1U?=
 =?utf-8?B?d1A1cWpyVHFOTlRDT1dXckYvRG5nb0Fvd3FHcXp4eFNqenljRWdJUWh4SEZH?=
 =?utf-8?B?aklYOFpuc2VTQmdQekhwNS9KMURXVnRyTTZsRjhQelJ2MndxeDJPdy8vSEEy?=
 =?utf-8?B?Y3BFMDloYXd5ZCswSDVxYmFXN2YrcUlmd1FBRmdFY0k2WXdkdXQxdHFlNTcr?=
 =?utf-8?B?RjVUOE0vbVNVOGJPRHd4SHl3b3V3d3ZEWmx4YnlxbjhweGs1YWNzZnROMlNH?=
 =?utf-8?B?b2tPdGpnZW1Fb3pxaytYTG9HUllZNzVUcFp2ZWFCanNHOVZoZGNpUzBqandn?=
 =?utf-8?B?RzBiSTkvVDl5VWdsUGFxOElUZTZPMnVmSXo2L2N2RU4rVDlISmlIcmd3RllW?=
 =?utf-8?B?ZFBLS1l5SHBLVW1mNVJvT0pQZnI0MmpmTFhwbGdiVjBUUlBORHNXTTMwS2hX?=
 =?utf-8?B?ZVVKVGN0ZmcxK3V6bm56clpiSElkNld2aXpFalY4NFVSZFQ0c2JIOW5sUWJj?=
 =?utf-8?B?V0JiUWtURFpuKzYvQzZQbTVXMXlNanNDMnRMSUhKTU1OQ2FVSUR5S0RuK3hL?=
 =?utf-8?B?WThaSmc0eXBlTHA4NVVNczk2ZTBzWG9OMDRhM3g2bUFsWFp3azlyQTU0azBI?=
 =?utf-8?B?MkVZREFHZG1LY2NjMFJDK0FMU1VqRmtyUkFnUE13N2x3UGxZQWtCYjlOcEJI?=
 =?utf-8?B?L2RvZEJmUXRETFBCWDJSZ0thbDEzOTBPU2U3dlBWWUhYMjd1SjVlcDlQdG9P?=
 =?utf-8?B?eGlrY01hbU5IMk10SzhBN0RvTnFBTTdBZTVRWUtQR1l4Y1hnR1QvOGxOVysz?=
 =?utf-8?B?dmFNSVJ6YkgydStFU2pHUzl5aUNleHliSEFlT3dKenI3VFBxUWNVdEhybnhh?=
 =?utf-8?B?TkM4bE53K05EZ09qdlhkTWVWdW9zRzFac3pNREwxS01hcFdKMFBjd2JvZ1NP?=
 =?utf-8?B?QU4vOHRDQ2drSUhnbm95VlNKVmNaYy8yZDJPTXo3WEZocStSOExxaTkrR3hX?=
 =?utf-8?B?SWJUZHlyWVE4R1kxekkyd1prcXl2NVJPeTNGUVQ3c2R4aWRoMUgybWVTN3Rt?=
 =?utf-8?Q?KRN3jiHHSDldzlYMdxQzUovCpWKIMJaa?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?alJYdGM2RktVc0dkQUNjQ0dpSHFuME9JSXdIUVlDQ2psNTJtd2NRaDZEZWNo?=
 =?utf-8?B?MzR0bG5CMVV3c1JZWWUveHdCUjFoRFFlWFVGa1dmVXlwcjZRZFhtd2YrcUFF?=
 =?utf-8?B?SUlVcVdJWlVIVzhNYVRRY0cyaXV4MnBURWVKODdPSjdVTXF1WUhzQzVTMkVX?=
 =?utf-8?B?dEdqZm1Sdm9pVy9yY1N1aVpNSGxmUEUrb2krSFFIY0tMcERvbWFMb2FRMnRG?=
 =?utf-8?B?OUxxLzhpcjJXWUFxZDFKSW96OXdWUjhqUmEyeDAyZFdVOHFaVC9DSnl0am1v?=
 =?utf-8?B?OCtYOXM3d1NuSkZoOGRBRlQzN3VSQThjdlpSdEg1bkJReXp2M0kvaG1xcU4v?=
 =?utf-8?B?VkQvanp6SlNCbjJwOW9rdXpkd3lCWFVrQVBWUHJuLzNBVFdTaUx1ZHVQSEpD?=
 =?utf-8?B?TW5zZVByWU82VVd5WGt3dGZLRUJzL2R3cy80aGhyQlFabVpvM25PMldPVlU1?=
 =?utf-8?B?KzJuRzBMNStEN3cxQ2MramY3Sm1rK1VTN01YSjVJYmJReXhjK3JWT0NWYUNw?=
 =?utf-8?B?S21yTnNMT2U5RUJMaGdKaXA5WXZ4NnQ5RmtUTUw1V3pBa2wvSkx4d2NBSjhn?=
 =?utf-8?B?a2ZoNG9YbllpZGliNjlpbGc1M3dBTjd1OU5lRDJpYWFyZVZwR29USitlUHNa?=
 =?utf-8?B?QVJmUklGNkhRN1BGRy9mZWFURU1vRkNIUTRNcEN5R2Y1dXBHbitmMkFUbGRm?=
 =?utf-8?B?LzBVaExNMWpsa1ZkRFNVMGRIUE9hVjJXckh5Y1VMMyt1b0ZTVEJBdmRQL0oy?=
 =?utf-8?B?aFdndjZpdVlzTFpDNEJFUFRTYUFsaVM5VWlLRlYxU2RCNVgzblNZR0Y5c3VM?=
 =?utf-8?B?RFJrKytIUnlWL1B2K0d2Q0tkSDRITWVyRUVlQUl3c0xYZktSSngrK2xtUHcy?=
 =?utf-8?B?UWt3TE9zK1Era29KK0ptd0xtbWVRSFByNkN0R2lmWlE0WnNMK0xVc0FsOEd5?=
 =?utf-8?B?WlA3dlZ3SEh4eWVuWTh6YStNRGRIdzZqVythZVN6T2ZKSGhZQzZYVnIzYmw2?=
 =?utf-8?B?Z2k1LzRKVGdOazNJSHRIa3pIb2c3bmNQd2NQa3E3YXRnVGtxNmRTbzQ1MFkv?=
 =?utf-8?B?TjNQQ0ZYS29QaG1MK2N0V2tSWGZVNEtjd0VXUkZLc2FvQ0wxa20zRWlmOWdN?=
 =?utf-8?B?a1ZmUEhmVXNMT0h6RGhiaU0yM0JvMnFjS1o5Zk1uS3dNb28rV2Z3bFVtczJ3?=
 =?utf-8?B?ME40ZnRyOUUyTHEyNEJNRkRBSmMyZjRPM09lUlhCRjJoV0dmOXBKeHo4ZXhZ?=
 =?utf-8?B?R2NTOHY0dWJONW5CYWJ5bVQvQVMxK0hybXFvUUlXZU5BME1zUEppMHZhN3k2?=
 =?utf-8?B?aTFKa28rbjJhc1NUWnpML2x4Nm9FMlMxekxWN3BKU3FYV3RSN1o3NStqMUEz?=
 =?utf-8?B?d01HQnQyTVM1dHU4a2lzUncwU2h1bFdIVzdVSlp0bjV2N1dxWjViNkt3YXhw?=
 =?utf-8?B?SVVVTWpkODdJQ2lqdXBwa0ovd20rVzZoamphZjE5UTZwWVMyMTFBekJWa09y?=
 =?utf-8?B?a0dRU2FVamtwRUxzRGtETlBPbkJ6aU1aZUI4c3hxYlFDMnExdFRIZkZBNmdt?=
 =?utf-8?B?dVJIMWdoVXp2c2lLNTRJa0VDOXBXaDYreXVKNGFJMVBWbnIzd2Q3RmI1Tm5T?=
 =?utf-8?B?dDZGQTU1eVk0eGppU0RGTnNXR0Uwa01qTEppVTJpdEJ6VU9acitUc1lUN3l2?=
 =?utf-8?B?RS9uN2NodHo1TVUxbmdnT0UvWmFMeTA4LzBVazFlL2l2QzB5S1JIVnl5MzhX?=
 =?utf-8?B?akxGMllFcjBwZEYrWGhiVXFJdzZCVHgrOW1xY0U2aFdJSzNJd1ZlaHAxSG1t?=
 =?utf-8?B?Rk9rWEtqQ1Z3VVgrVTduWGtNNUhkdnlMU1dCWHhGM0crMEdRZkkrWWdGL0p1?=
 =?utf-8?B?dHZJSTFzaUhJOWZ5aHhqa1hOcjVieGNuOGtOWGsyazVtUUF6K0V2U1NJNXBI?=
 =?utf-8?B?Qk54TlRrTUNuWkh2bWZqY2F5b2ZCdFZxMlE3VUVDU21iWjJMMEtYU05WOVhS?=
 =?utf-8?B?dEtlMmJXa2JWWlJneTdOeUVPQmQwa08yaDdtQjFiZ2VvUUZwS3FUbTA1TTA3?=
 =?utf-8?B?QWc1eU5xZzl4V0VabnowNElNNTAzNkd1SWRLZkJ3OHhyRmdMMWg5cWZ3Yktp?=
 =?utf-8?B?VGdhZ2dyZHExY0lCTjVhdFl3ZEZkMHc1YjFCdjlrK0dJSDFJZGNRKzU3OUlQ?=
 =?utf-8?B?cmc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eace240b-35c9-4953-2000-08ddfce5a0f7
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2025 10:15:33.6687
 (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: PU3+se7ul9288LSFPBXUmpB+COnRQ40KgYEoEOFfr+S9AksWGDF/EV9IAK59TVRi+JzcsEb0w3nYpqP2k04tIFSPWNNbielt9+9w0JROJzU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11091



On 26.09.25 09:37, Jan Beulich wrote:
> On 25.09.2025 21:56, Grygorii Strashko wrote:
>> From: Grygorii Strashko 
>>
>> According to the commit b66e28226dd9 ("x86/mem_sharing: gate enabling on
>> cpu_has_vmx") the Xen memory sharing support is only possible on platforms
>> with "Intel VT-x" (INTEL_VMX=y) enabled.
>> The same commit is also added runtime check for "cpu_has_vmx" in
>> mem_sharing_control() which blocks access to XENMEM_sharing_ops if
>> !cpu_has_vmx.
>>
>> Hence add dependency from INTEL_VMX for MEM_SHARING Kconfig option.
>>
>> Signed-off-by: Grygorii Strashko 
> 
> Reviewed-by: Jan Beulich 
> 
> You should have Cc-ed Tamas, for being the maintainer of mem-sharing.

Sorry, I relied on add_maintainers.pl script.

> 
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -79,5 +79,6 @@ config MEM_PAGING
>>   
>>   config MEM_SHARING
>>   	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
>> +	depends on INTEL_VMX
>>   
>>   endif
> 
> Wouldn't this want accompanying by replacing the cpu_has_vmx in
> mem_sharing_control() with using_vmx()? The gain in this case may not
> be very high, but it would serve a doc purpose.

There are no benefits. if !INTEL_VMX the whole module will excluded from build,
if INTEL_VMX - it will end up calling "cpu_has_vmx".

What, potentially, might make sense is to move mem sharing code to HVM
x86/mm/mem_sharing.c -> x86/x86/hvm/mm/mem_sharing.c

As it is strictly HVM specific. Just is potential TODO item.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 10:38:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 10:38:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131427.1470518 (Exim 4.92)
	(envelope-from )
	id 1v25qX-0006Cb-ES; Fri, 26 Sep 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 1131427.1470518; Fri, 26 Sep 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 1v25qX-0006CU-BB; Fri, 26 Sep 2025 10:38:37 +0000
Received: by outflank-mailman (input) for mailman id 1131427;
 Fri, 26 Sep 2025 10:38: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 1v25qV-0006CO-T4
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 10:38:36 +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 f39657bc-9ac4-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 12:38:34 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DB8PR03MB6313.eurprd03.prod.outlook.com (2603:10a6:10:13a::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.11; Fri, 26 Sep
 2025 10:38:31 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.008; Fri, 26 Sep 2025
 10:38: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: f39657bc-9ac4-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PXZgIU/6tpieYzlmdtbfFCPxXa/9uz+32e1Q1JM5cN3FtzgqxM+l4ZYO55KvK8msY0fTdj7GUlp7P2cMHTIPF1Bxd/WC6vve7FdtpKNRhwsMH3ivgUFv7k+SBlKLtjAfNecJwHSdSJmYEQmLMGUVOqtDk3wCW5Lb4vJ+0JckMwson6gJh7SHmDqAlujsSIzXtXrUEaVvFcJS1UxgL+5GHkOiwVzOmt9fM8Rx7jEzVvc+1Da0LNDrpczwbFTeQskXtSANjqpwSLwiauPQdCIqyE4LXXsBLycZ8Rcitw0zs/MYmKPZANyeUydOuzJLPdZpZp9aiRWImLd1IjMJeVlk8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2pUm2+0UDQ2Drkum0xrdaLQRYNpNgjevFFTyg4o/+N0=;
 b=BJk3xAMmuQD8/dc9r+Bc8/YOUUjyvNGCMkJN7ufyfqQwg/fJhu9e+0yFXB4pgE5sBrf8Mrk4QDhq68QhHosrlgUpg4NuOsNet+Zq/tUCtA8JL2rYHO5J4qLEMdYL9TlJGJ6QXhtMnA8TBg4r36V693TRN/8yQdHMObgiLvDkIyiGXfipktUPbaiy2N6ryMBTnOsQIEBxA/6w0x3MI5zD9ojKoaZ4SLXX6WGCt9Vjlhk+SHnnT5DhQU8M/1FBNuWZRokA4MNKRe8QkihJztOrJYRxGyTxBrpwEt27LVKFm5u1v0SDydlXUfP/086+S/1gEZ0kgbyeLDhY0AfgIsLdTA==
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=2pUm2+0UDQ2Drkum0xrdaLQRYNpNgjevFFTyg4o/+N0=;
 b=B59dsIwz3zX7dE3TLfqgjP6XKi+Mlh9JYxUSxJF6iECepQDkjXgeNnJRJ8ObPzkQzNUO8GBTnmSg8YHyFuaPuJxH9UaYWOjK7AY+8WMSqX9LQy4NzLUVXQcdM6tTVvI5SMotLOFod41J+KdbxsMBskgTPkatJGQ7KGikcoJWO0qQvBCb+rXgyfiLYY/cALyb+/oPWhH4diG4e+zMCv3q7aDol0xHSGRpqAOh0YZGTK46LzxTylFfeQl/BmtWdoTSJz0hCEyxxi7Uko8n33YmPCKiibEB2Nea127v1doDZgbL4v552ObwprgF89R584NgckqfkSM/QLrluyxS6YcwHQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Fri, 26 Sep 2025 13:38:30 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Jason Andryuk ,
 "xen-devel@lists.xenproject.org" 
References: <20250925195558.519568-1-grygorii_strashko@epam.com>
 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0179.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9f::15) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DB8PR03MB6313:EE_
X-MS-Office365-Filtering-Correlation-Id: eaa834b5-3b0c-4df6-eea9-08ddfce8d649
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?MHEwR0VoaWsrU0RQZDBzdkw0SHQwRzF1MEhZMDBaTFNtSDhnc05DVDJuZzFn?=
 =?utf-8?B?RVVDL0l5bmRpb3VkYlJzd25vRFJCeWVDVVZCT3RESXhPQW50bVJnc0tSSjlB?=
 =?utf-8?B?S0JNZHRoaTNBY0RDZ0haTzVOcEdVQlBuY2xoVU1XSFV6MklOVk8rYlhKcEw3?=
 =?utf-8?B?TlR1R1NmVXdLZ0UwbGkxK3paSGtTR3ZnUkhVZjlaaWZVNzZXN092VVZNZExt?=
 =?utf-8?B?ZW5ab2EvY2c5b2tSdHlYNHBSMU54aGZXMVVSS3RZVkV6ZHpJWnNCbnJvQWRZ?=
 =?utf-8?B?QktHWXdla2FrWWhrNytwZ2YxSFNZU2k4TWt5MFdybkRsTEcwRzdJRmV4SDA5?=
 =?utf-8?B?OFQ1Mkl4aWhpSWxOOW81bWJLTS9vQnZ0dnJVem9yTkpQdFYxYlNLclkvZW1V?=
 =?utf-8?B?SFNualJJOEY4MTZsd3lqbFR2SkNEVGJzVHFIS1hzNFFEYU5HY1FYOFZVWmMy?=
 =?utf-8?B?SnJpVHJpZG04MUdSYW9keDBmRTBwd3labzQvRnlHR2MyalhFSWYyck9HcnFC?=
 =?utf-8?B?R0JEMStBWVlKMFV6aFFyYTVnT0lEYndqTzZXcVpHUm42U1FFd0d5NGl2Nmth?=
 =?utf-8?B?amgwYUZHTHVIUXhYNlpkT2lETWZaV25JOWpiY2UrM1VQak1VZi90UFhlajAy?=
 =?utf-8?B?VWhOcXNwUmV6dW9CZ1A3NTJZek9NRzVVZi9XampVY2dvaEZwNHNXeFllaGxi?=
 =?utf-8?B?NFpDRVFjMExyMjVtQ0c5dUtqSm1RVXRxeFMyWXlkTU9EWU4yZDlLdlpGemlJ?=
 =?utf-8?B?djRDejc0SXppMUM5TzlVTTh5WUx4WElZN0ZwYXhxQ280eG5UbU9XTHVRWVNB?=
 =?utf-8?B?VEtVR0VjY0wycW1ESENCMFZ4TmZRNjMzdkJmTnNaaFFEY3hhQkd6NnlwQVN6?=
 =?utf-8?B?NW5aS1YwVVV3bGNoUzJ2bXlrZSt6UDh1di9PMGtPU3dka05vcEJmaVNFYXla?=
 =?utf-8?B?MFJRbENGOWM2K1N4bXZpbloyNTY0WW5DeEVpL1pBdXo0K1JlZ1lwSlgwMUMy?=
 =?utf-8?B?cXZlOG5MZHYzYzVVc203K2lIZmc4WlJwMU9sZXZJRGdyR1ZKL2d0R20wU3hw?=
 =?utf-8?B?aGd5eWVoaVA3dkdXemZDajhGNUNCQThCUHJvbHc2R3NYREllT21HN2svOGVE?=
 =?utf-8?B?ZEh4TUlKZDRGOFpSZDVjVzMyOTRpZWhUVWZ6WmlyWUl5SWcxcXBWUDluV0pP?=
 =?utf-8?B?MDVhaVo4VEpxN0EwTTRFYzN3aHc0d1hZbUt6WC9tWnNteThSMVJUNExmaldX?=
 =?utf-8?B?aTcvZ0U0RGE4U2QzR1RDOUZ6M2NaK3pQUDVtcTk5YXhJWk5lcFd4dG15VE9m?=
 =?utf-8?B?MEViWjZZakRlem5zMzVtMEhuWnFuaTBjYTAwQUpITUF2OG14NENqZWgrNEVi?=
 =?utf-8?B?ZDdWWm5NZUt1L2JvdHp0bEtoZmlyd20vaHB0b2tCMjlFejNmc0FNQjcyaUVF?=
 =?utf-8?B?NmsxVHBaRlBiK1RqWS9mRlNDa0ZGNzVKZGZxa2dXY1ZGN1lrRWdVTjlSekY2?=
 =?utf-8?B?U0ZnM1JMMlFWblp4anM1NG9wZUcwU0NMdHNET1V2cGJSUjY0czlLOXVoVVZQ?=
 =?utf-8?B?SDVzdktMaEQ2NC9YdWVoYmo5K1RRU2FuRTZPYnpRZlBYdGJDK0JqbnQxVkRj?=
 =?utf-8?B?anl4K1VubExTQTNaTzdYRE5RSTBvN0xPUTJxM0FEZXRXTGx4YW1EZlhtR2hS?=
 =?utf-8?B?bHNaemhNM2hPT05XVW04bDVoRi9TWjdqWEFhZlQrZWdmK2luTkxtSVJHbmkv?=
 =?utf-8?B?Vng2anFDMjE5SnJrZ3EvNnAzZ0hEcVd0WGpMOTNIZlVGYytrdk8zK1Zsem10?=
 =?utf-8?B?NG1JN2Z6dTVaRkt6UlJUdW8zUEszR2tNVjVHNTd1NDVYQit5bDNPcksrakFn?=
 =?utf-8?B?VzBzcXpZVTVKOGNSdU40YnJXUk03Y211SEcveTZYZzNrSW54MG9iQ2U4aE5x?=
 =?utf-8?Q?e6Xl9W7H+S0=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dCs2cmYrbTcrRzdIWll3bm5QSUxBaU9YRzhyenltN2gwWVlXTTdlRENUMHJt?=
 =?utf-8?B?bHk1L0dEOHZUanpJbGd1Q0tHVmJxVVlwNDl6eHBYYkNHTEYxVUQ5ZXJPMk5I?=
 =?utf-8?B?bVd2WU01QUpEcC82VzJMNWxRaWpRUk9wVU00ZklUWWtpTjFmVFA2cmIrYm8r?=
 =?utf-8?B?ZTlUNURnMmd0cWFBaXo0ZXAxMnBIVVZ4S29IM010QjlGVkpHNkQ1MTVGNklS?=
 =?utf-8?B?NnlxdkNXVlFhVHhtZ3hvVXdmQzJ3NG01anNyY2hkK0tmVjRWTFJSSGQxL2dh?=
 =?utf-8?B?L1VyMnNCSXdXRWhUOGNsT08xSEk0eDNma2VxY3lqeUhkSnF0eStlREdjT0gy?=
 =?utf-8?B?VUE5NWNqTGxqbzBXTmtBcXFIdEt2akkxSkQvcXk3VUcrNllQY1c2YXZmRmls?=
 =?utf-8?B?K0EwQkk3dytsNVNvL1JOOUhXVksyMFRRVWF3VC9oQjJhaFAzc0FwVTlxVXFV?=
 =?utf-8?B?UysxMVBFci8yOVM4cGh1TTZaYTZMTk8va08wU2JoSnJpbTlaVzRzZ1JQN2tZ?=
 =?utf-8?B?L2pLOHR2SlJUWTJXcTBVQnhoZ2ZUSVF4eWt6aTZWb1JNZHdETmJORERBbEti?=
 =?utf-8?B?cThDOXM0OFZoWHRhZ2oydnRPSFZhWXZjWDRjeEVWZnpOT1VaTlNIbFJtVGJr?=
 =?utf-8?B?Vlk2N3RFL3NnUVhyd01sVTJuNzlBcWYwWGhqZGI3c2g3YlZUS2pPVHlXaWhs?=
 =?utf-8?B?T084Q01tTW9tZGNEUExvcnNXcDhFYTR6VXMzQWZES3NVTkcrbWxKbWdYS1p6?=
 =?utf-8?B?ejBIN0VrUHhwelNnRE5nQkVIWVpjNVN6UVU2cDZ4Y0M5R3NFL21GN1hsQkZq?=
 =?utf-8?B?WUdwbllmb2NHOGRwS1hIdlByUmVNR3M0cW5HR01VdUpFdWxoQUxTY0dheG5R?=
 =?utf-8?B?TXI1VVFSYUxxaXhiYlk3UllvSk5DOEpsbXRFZk0rVk5xeFg4TzNUSDhBNUho?=
 =?utf-8?B?VlBUSEE5bHpWOUR0d3FrdGlQR21JbHpzVHBIMmtwSmZsWUJsSVB5L3VTSUFJ?=
 =?utf-8?B?ZzZXTk5wS0RkNmFoYzJFQnY1U2VyK2RHcUlmR1pvVEdIWGdMZDFOTkZiamZB?=
 =?utf-8?B?RTArbmpkWG0rYXJ0QnV5RkRzdVllNjlKNXlLd3JLSHhqaXQwNFgzTzZ6VGlp?=
 =?utf-8?B?U3pGeU9rUG5md1NUWDlTTVpEMWM4R3FXMmZLT21pWHk2U1IzRCt5bDZrTzQv?=
 =?utf-8?B?NFkzRVBzc0NnOHpVWERWemRCRXpYSFptTU1aeThNSldRUHNTQ1liYURJUXZv?=
 =?utf-8?B?L1dwUWF0Rko5bFlkMjQycHZGa1JMdlUzTW5YZldBTWRkRDl1aVlFeG96djdB?=
 =?utf-8?B?Nnp0ZjAzcEZxUFdPdjBPeTJCK3RwTEhLdDhPZ1piQXAzOHVvU1RoQzBOTTda?=
 =?utf-8?B?dnlRb0xYUUlpb05Ecmc0WjYwTW40T1JteVVVWFFEbFRma0FOMVNkZ3c3dGRo?=
 =?utf-8?B?VXlQK3gyNlBCcjNDNlhCazhRSjhmM3F4Q1JPQ0NEa3paNTl5S0djSTJDNXVY?=
 =?utf-8?B?VjBydkJtSDgwTW5NemlWRmpHNjJhWWplOG13LzM2aW0xcGZYdVp4eWtkaUZz?=
 =?utf-8?B?VnVCU1JhTW56SkdTQUtxT1dmR0dlK0FSRDRTc21nbnFzbTI2ZWl5OUxrZFhQ?=
 =?utf-8?B?SUpwM3Z5ejZXa0ViV21YaXJLMWJKd2JOcExNT01CMmdsc09IbDE1NXlsV0Q3?=
 =?utf-8?B?cUhua3Z1UG5Gdzd6M0NWa0w0VmsvYzN0SjU1MldlWVNKazBqZEJMVGRQMUJR?=
 =?utf-8?B?RDNEZW11bFFiR2pKUE9jVmoxZU81cDZKQlUvb2hUWk5YdU9MSEJ4dFo3U1dL?=
 =?utf-8?B?UmZUNnBYNGwrdXBreTRPSW5IbTVjOUplMGd4em94ZWpCVld0bWMxd1pXLzVX?=
 =?utf-8?B?NjRJcFBoWEI4ckNaS2p0bEJ3akl2aEZnUmNrK3BWQXVtV092aldqWm50dEQx?=
 =?utf-8?B?QTd5V3d2OW0zc3M1c3lHbGxLV1ZlWEdQUk5sbFU1VHQzeExCL3NZK2tYMTFK?=
 =?utf-8?B?K2xWZERKRW5yMDBrMFBLaXBucUlza2ZrdW42MkNSdnpnNXJFb3lsOEtMRW1a?=
 =?utf-8?B?bTRWditZTWFJVk1DZ2xEMDJ3ZkxaZGEyYS9iSDdkQTZVaFZvNHJiU0VpMDQy?=
 =?utf-8?B?aHNzdUdlYjNBQ0ZYOUJGVk5uQlhOMEswbGw4bHVuRWt2dHBYUlRZTmg1SkRZ?=
 =?utf-8?B?cUE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eaa834b5-3b0c-4df6-eea9-08ddfce8d649
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2025 10:38:31.5949
 (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: JoqkFaOWqehuJoUtmTZer7J6bqs1YwpAjYmPE0U8+jGwgP2JZVMKMpOr2JRjwOdA0TSDHC8x/3buX7hszE0kpNjZ6vearm4Um/Qhv73bJdI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6313



On 26.09.25 11:17, Jan Beulich wrote:
> On 25.09.2025 21:55, Grygorii Strashko wrote:
>> From: Grygorii Strashko 
>>
>> The LAPIC LVTx registers have two RO bits:
>> - all: Delivery Status (DS) bit 12
>> - LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
>>    This bit is reserved for other LVTx regs with RAZ/WI access type (MMIO), while
>>    WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bits
>>    (MBZ access type).
> 
> Question is what the behavior is for writing the r/o (but not reserved) bits.
> I wasn't able to find any statement in the SDM.

Me too. Usually RO/WI on most HW.
For example, LAPIC MMIO "Write" will be ignored (WRMSR will trigger exception).

> 
>> and the current vLAPIC implementations allows guest to write to these RO bits.
>>
>> The Delivery Status (DS) is not emulated by Xen - there is no IRQ msg bus, and
>> the IRQ is:
>> - or accepted at destination and appears as pending
>>    (vLAPIC Interrupt Request Register (IRR))
>> - or get rejected immediately.
>>
>> The Remote IRR Flag (RIR) behavior emulation is not implemented for LINT0/LINT1
>> in Xen for now.
>>
>> Hence it is definitely wrong to allow guest to write to LVTx regs RO bits,
>> fix it by unconditionally cleaning up those bits in vlapic_reg_write().
>>
>> Signed-off-by: Grygorii Strashko 
> 
> Please also add a Fixes: tag when correcting code.

This is veeery old code. Probably
f7c8af3a6476e ("[XEN] HVM: Clean up and simplify vlapic device-model code")
or
50b3cef2eecb0 ("[HVM] Place all APIC registers into one page in native format.")

> 
>> --- a/xen/arch/x86/hvm/vlapic.c
>> +++ b/xen/arch/x86/hvm/vlapic.c
>> @@ -880,6 +880,7 @@ void vlapic_reg_write(struct vcpu *v, unsigned int reg, uint32_t val)
>>           if ( vlapic_sw_disabled(vlapic) )
>>               val |= APIC_LVT_MASKED;
>>           val &= array_access_nospec(vlapic_lvt_mask, (reg - APIC_LVTT) >> 4);
>> +        val &= ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING);
> 
> There shouldn't be a 2nd &= here; what needs adding should imo be added to
> (really: removed from) vlapic_lvt_mask[].

I'll try it.

  (Orthogonal to this I wonder whether
> guest_wrmsr_x2apic() wouldn't better use that array, too.)

WRMSR checks for MBZ. RO bits are not MBZ, so masks are different.

> 
> While looking at this, don't we have an issue with CMCI as well?

I see no APIC_CMCI write emulation. only read.

> guest_{rd,wr}msr_x2apic() handle it, but vlapic_reg_write() doesn't. I.e. on
> AMD we would fail to deliver #GP when the guest accesses it, while on Intel
> we would lose the value written. And we also don't set its mask bit in
> vlapic_do_init(). I guess I need to make a patch ...

Is'n it depends on CMCI capability exposing to guest? (have no idea what's CMCI :)

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 10:53:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 10:53:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131441.1470527 (Exim 4.92)
	(envelope-from )
	id 1v264W-0000Wg-Ie; Fri, 26 Sep 2025 10:53:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131441.1470527; Fri, 26 Sep 2025 10:53: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 1v264W-0000WZ-G6; Fri, 26 Sep 2025 10:53:04 +0000
Received: by outflank-mailman (input) for mailman id 1131441;
 Fri, 26 Sep 2025 10:53: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 1v264U-0000WR-PB
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 10:53:02 +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 f8160cce-9ac6-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 12:53:00 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-b38e5c2e055so55906466b.0
 for ; Fri, 26 Sep 2025 03:53:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3544fd0a54sm349560966b.86.2025.09.26.03.52.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 03:52: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: f8160cce-9ac6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758883980; x=1759488780; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EqYrefFKk4Wrr3Po6mt7vYWqF5p8dKa88zs5EDkhzww=;
        b=X8kFtyN9HXvt3++QIFdNG51v480puUEc7xA10m8TpRwsNsTgiHZ1eSjTXvt02ESltV
         XmlHcIGdHiL/CLzqyfHcvDhVynvapKqSTYAiXAoLGuO3ebOHfeXjDFqrie7A4O+n43wc
         tEnto5ti7mDZa7u4NZqDh5u+NVcLDF/lcbz11ge6njI+JKjNBYhKVCpEekjmFjFFhrVj
         XiFzSMNoZqEkhYLS3lPTujQ4iuHHOMdsROuC7H72cGZRJRIlHFAHSewtBvps5UBy/te5
         WpYNaW1jb9TqTskkTaz3Ys/q9yI8KsQLKqmWcyvXMg0D2q/1IFHeeQv9GoMyganAH7Jf
         yWrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758883980; x=1759488780;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EqYrefFKk4Wrr3Po6mt7vYWqF5p8dKa88zs5EDkhzww=;
        b=MJ3V7PoMNr0fT53W5s/uASYDqsvmxqlu8Iimu/HnujtLylqZrNDSwIfp1X80o/WMvH
         AM5oM9qona49k74MMGbI1KEyPf/XlmqvK85NPyrLXwRVahFqOmDKL6YBNfRt+UYgsg1W
         PbgvgK1mZ7YUMG40j1ooiflry93t6sl5BfdgyfD1qaUDtu1ClnAcUilpktk2VIUpZClY
         vk0ZAB80y35Mr+Pb1ScXIgXAVziQLiJ+kLDAlMDXXyHlg0kzXLo1BdjtS7uhMrjH7U3c
         kI01iE7AgKHPMPvV73vQ7C2eJws6DZe86/gFqyFsR204wTUZSw9yJZB7P1dtb+Rwtt3l
         iDjw==
X-Forwarded-Encrypted: i=1; AJvYcCWea7QVLKbIXbEVwri3rkXm62CGUs9GkSW+B3sK27ZB2/tArASayVGh8Pjp0kdYtm/F6N1XVXcKKvE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/uDk1AChSjLydmZZwpC3hB958a+gOeQ2pAe8iFgbFpxxWgfUC
	FhF1zir5KORhL6AMakbQeiQskMh6WJaRqwRwn10+cAvzaAHbErPC6hJELtmKepY+Yg==
X-Gm-Gg: ASbGncvgb31VUxLO0gCat8mob0lEr7PjQFEMFEfMJ4acxjT0PUDDqZRYS4CUG43YwCt
	UbHSq3cGkNf7YQUycV3KtbErPm6n9nLKz/6U9rgUWwnuhNpR2gdWUyqIrcGcfF8K9/HSDLhI5x+
	Pt7R3YRyJb55n6isMZIs0l04/hKx0Llv6631xkUeXawcJIpse2a2repdvFVBmJNcQ+tyUQRh+av
	almZnZPrdDZM0RF3VJFTUm20uqnIAg4SF4NnkZzioWs4KkZcZisdiyHX17ONXpk55rMSJGMBut5
	uRrc2S3oiAWrwhKEdUVyPKJM+TF+T+vc4jHdDTIvXl6RIhEZORscbcEqWgx0G3KJ+Bx1QsHOUIY
	ycy7+B/1nAj1LYRK7EMgQx2wl9lZBEC+19vWZN8uWDwSk9IAK2YmHsEUfIdw2Ppri+xkO8Zqyi4
	5FQcnJJx+f6G2+qvzIrA==
X-Google-Smtp-Source: AGHT+IFPESowOGbhcCAlni7hquS/57DIFBzYgyaYfbfSMgpdBIjDaMh/2gSBKigD7cWAWzXcENbTDg==
X-Received: by 2002:a17:907:7e91:b0:b2a:dc08:592e with SMTP id a640c23a62f3a-b34bef96395mr628251466b.49.1758883979968;
        Fri, 26 Sep 2025 03:52:59 -0700 (PDT)
Message-ID: <67dd3659-916b-4e64-afe2-e13fdc8d31f0@suse.com>
Date: Fri, 26 Sep 2025 12:52:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
To: Grygorii Strashko 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Jason Andryuk ,
 "xen-devel@lists.xenproject.org" 
References: <20250925195558.519568-1-grygorii_strashko@epam.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.09.2025 12:38, Grygorii Strashko wrote:
> On 26.09.25 11:17, Jan Beulich wrote:
>> On 25.09.2025 21:55, Grygorii Strashko wrote:
>>> From: Grygorii Strashko 
>>>
>>> The LAPIC LVTx registers have two RO bits:
>>> - all: Delivery Status (DS) bit 12
>>> - LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
>>>    This bit is reserved for other LVTx regs with RAZ/WI access type (MMIO), while
>>>    WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bits
>>>    (MBZ access type).
>>
>> Question is what the behavior is for writing the r/o (but not reserved) bits.
>> I wasn't able to find any statement in the SDM.
> 
> Me too. Usually RO/WI on most HW.
> For example, LAPIC MMIO "Write" will be ignored (WRMSR will trigger exception).

My remark was specifically about WRMSR, and what you say here contradicts ...

>>> --- a/xen/arch/x86/hvm/vlapic.c
>>> +++ b/xen/arch/x86/hvm/vlapic.c
>>> @@ -880,6 +880,7 @@ void vlapic_reg_write(struct vcpu *v, unsigned int reg, uint32_t val)
>>>           if ( vlapic_sw_disabled(vlapic) )
>>>               val |= APIC_LVT_MASKED;
>>>           val &= array_access_nospec(vlapic_lvt_mask, (reg - APIC_LVTT) >> 4);
>>> +        val &= ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING);
>>
>> There shouldn't be a 2nd &= here; what needs adding should imo be added to
>> (really: removed from) vlapic_lvt_mask[].
> 
> I'll try it.
> 
>   (Orthogonal to this I wonder whether
>> guest_wrmsr_x2apic() wouldn't better use that array, too.)
> 
> WRMSR checks for MBZ. RO bits are not MBZ, so masks are different.

... what you say here.

>> While looking at this, don't we have an issue with CMCI as well?
> 
> I see no APIC_CMCI write emulation. only read.

guest_wrmsr_x2apic() has

    case APIC_CMCI:

>> guest_{rd,wr}msr_x2apic() handle it, but vlapic_reg_write() doesn't. I.e. on
>> AMD we would fail to deliver #GP when the guest accesses it, while on Intel
>> we would lose the value written. And we also don't set its mask bit in
>> vlapic_do_init(). I guess I need to make a patch ...
> 
> Is'n it depends on CMCI capability exposing to guest?

Yes, that's part of what I was (effectively) saying.

> (have no idea what's CMCI :)

Corrected Machine Check Interrupt.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 11:00:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 11:00:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131454.1470537 (Exim 4.92)
	(envelope-from )
	id 1v26BK-00029b-9a; Fri, 26 Sep 2025 11:00:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131454.1470537; Fri, 26 Sep 2025 11:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v26BK-00029U-6F; Fri, 26 Sep 2025 11:00:06 +0000
Received: by outflank-mailman (input) for mailman id 1131454;
 Fri, 26 Sep 2025 11: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 1v26BI-0001jZ-H4
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 11:00:04 +0000
Received: from CY3PR05CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c112::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f210241b-9ac7-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 13:00:00 +0200 (CEST)
Received: from BL1P221CA0031.NAMP221.PROD.OUTLOOK.COM (2603:10b6:208:5b5::10)
 by MW4PR12MB7483.namprd12.prod.outlook.com (2603:10b6:303:212::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.13; Fri, 26 Sep
 2025 10:53:16 +0000
Received: from BL02EPF0001A105.namprd05.prod.outlook.com
 (2603:10b6:208:5b5:cafe::39) by BL1P221CA0031.outlook.office365.com
 (2603:10b6:208:5b5::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.13 via Frontend Transport; Fri,
 26 Sep 2025 10:53:16 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BL02EPF0001A105.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Fri, 26 Sep 2025 10:53:15 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 03:53:12 -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: f210241b-9ac7-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FhCn9FVLpf2jxWBeuQxGnKRJ17GT+O8pZYkure5pdSpAfamdD8xtjrWcgqnGvfBT1CtP/stf3KwYCQPHGsnWxKy1iHNqHKgFEWxqiGTR1yYEOXuge78jn1ZIasFlIxpHOeminQCMEzADQlXBUZQedFeWGQV42v/B5ymhp+TDt0AXl+tEZXKfEDFUnHb2MuGay2FOZOMttUJUKMpZEXQwv0Ll/9tzHwNNxQHxVuYBKMKGv6xmH5LCpfOkCLDQQZRwW/WVWAtm929VfcRx1Snu/8MsQITW/U0AUsL03G3shYs1H1Kk2tGiu32Tin+fCHoyipstVZu0oM43aZYi7wUznQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HgZS9xNU2xSXn43jLOOcaNzu2abWfRQdW1m6PvTLsPw=;
 b=f4/IPyHgR5YFfu3nwpYsJkHCCJfGZ5lOdJP3GDXbt6mGn3Cr1gapoF3RN8I70kBuIwxJAJW3FwZCR36YSu/6katyF0RrUsvCs7hb7T1ZEEHDjc3TJk00VD1WeSuDeTcLxAHeRxX82AmCRDMfgzhI27UCly5mVl9MCmp97L32lnZRuYMY0Fs4JVHHMiPkSZi1tuaOl0mHQ6cw1FVDW2L+5WY6cAdyIEFGrV090yQM9rOlBdl03D+EhNawfyQjJMgqqp3URyv0ToEBhIp9vc2G1CUROnTeK+IXdKpL/6nxVNZtMGN2x4TpcAJdOtKux1+n7EksvfxR+hc71Oa5uDDwSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=bugseng.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=HgZS9xNU2xSXn43jLOOcaNzu2abWfRQdW1m6PvTLsPw=;
 b=lMv6GpGojnUS6Xc+rCqaP/s1GkL4xAhIyhalaCOwUrZrB4Dsz4NjfziS1eFcgq1QyeILM1A+GEzNozi5VAVVeN5eSeqzz49u8Ali5V73lAYbUFc60MLRu21Km9f6e2eEZR9k2udiEQQycwbUMfC9dORH5G03zaJH/42OVHSU8CU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 26 Sep 2025 12:53:06 +0200
Message-ID: 
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
From: Alejandro Vallejo 
To: Nicola Vetrini , Oleksii Moisieiev
	
CC: , Andrew Cooper
	, Anthony PERARD ,
	Bertrand Marquis , Jan Beulich ,
	Julien Grall , Michal Orzel ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, Volodymyr Babchuk ,
	Xen-devel 
X-Mailer: aerc 0.20.1
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com> <8fd7c0f5d203aa0f13cd8efe5129b6f3@bugseng.com>
In-Reply-To: <8fd7c0f5d203aa0f13cd8efe5129b6f3@bugseng.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A105:EE_|MW4PR12MB7483:EE_
X-MS-Office365-Filtering-Correlation-Id: 9124e682-0ad3-46a2-0d0c-08ddfceae585
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:
	=?utf-8?B?NlpZSjY2SHJsZDdxOWF6OFNrNm1pSllDZmJjK2VPR2Y1ZzBaRlZ6ZDFMMUhv?=
 =?utf-8?B?T2QxZTN2UGN2a0s5djY3SjFBV3Z2Y2JUQnhPU1ZDVGtFcFFIQmE1M0V2YTlE?=
 =?utf-8?B?R0h3aS9xU2pPd2JWVzRUZWVPZVg3NE5UYTlTQm5uSmRYTC9hV012YXhLTTVl?=
 =?utf-8?B?TTArTEJsNXhMTnhZNlpzcGovZWI5T20vUWNOYmpic0pGa0pJdTZUK1lEMEY2?=
 =?utf-8?B?UzhaQzhsaGViNUJqME9OM21OQ3ZCQkJyY2JOVXkxV1lLZGx0cVRHYUtPd2x6?=
 =?utf-8?B?eHBBRElybjF3cmNiWFFCL1hOcG5NUDVIS3NLL1Z5TU1mNStyNHc5MTZSNVYr?=
 =?utf-8?B?MHlEMEJ5SXRzV25iKzNKSmUzRXp3Uk9OWkV5SGE3azRNZUVlR2NIM2x0UmVW?=
 =?utf-8?B?R0pyeXN2RXFzallqVU8zK2djOTJQcFJWaWpzNDM3N0U0dU1UV1l2R0daQVRv?=
 =?utf-8?B?dWMrWWtsYmJvZVBOVlZhcE85ZGFXNm40SkNCZVlMRGh5aElJUFlEeXQxRGdQ?=
 =?utf-8?B?OVlHODQ0ZWFJSWg3MGtkeU83T1p5V0hPV1BYNXlWeWdwdDVxNnVJK2U1cEpJ?=
 =?utf-8?B?T1JEakJVSUpJWTBURzI1Y2hoZERyWElrY3M2UmkrZWgwRmhpV2NOWks3MGRs?=
 =?utf-8?B?aFBCbFVjYldSL2JYd05rdXN3WFJGM2o2M2EwTlhVVitoc0RWNVZCUXc4eE1t?=
 =?utf-8?B?WnJwck1hYnJwakpwLzlOVDlhdXk5bTdCVCtqZE1zaGw5YjlGekQvT1N5Vjdo?=
 =?utf-8?B?OEhhT3l3OGM2bjhGVjNNYXhzekdiS1JMelJucUwyYlcxS2F2bkQ0azNCU29i?=
 =?utf-8?B?R3R0ZWlJY2pTNk93cWFNM1ZQeWxnV3ZNRVZmYkZQRFdSQWtHTURRY2pScVVy?=
 =?utf-8?B?bWdzeGdsRCt1c2NoK2h4SFRvWUlIMWFTMnFZSWtpY3hxK0E5bU1XU1NBS1Jz?=
 =?utf-8?B?YmhOS2JSTkRCTUFheGEwU0dyZWRYSHNMNnFQcFNraVZQVkRBQUZWSGNxbUJz?=
 =?utf-8?B?YzBIS2lKMkxKM05IR1N1bHMyWkt4WlRhVHZzRmtsbWRFSElLcVUrWktkNHV2?=
 =?utf-8?B?MG5RbUlZYnRnVk5RaG1Rbmh4bWxnK0xsYUg4VSsyUnNTTUR4K0hLRlNyRW1x?=
 =?utf-8?B?VENjWDFXNGhXeTZ0aERjQUo5RWd1MTFnMDBFSVpiY25oMmdNSG9kUlJmcmhP?=
 =?utf-8?B?anhhNjNBK1lhdk5Ud0ZMRUN4U1k0Z1dYQzJxRUd2aUYzTC95WitoL1YxT0tT?=
 =?utf-8?B?SHJTU0FsRFZiRFBFYmVQSzlNdi9mV1MzWmRvbkhFU245cU4yQ2pyRDVHelFm?=
 =?utf-8?B?cmRXenhHUzFtV2pHcmxmTGVQUDU2NnJ1dldHYjJIVGVqU1laZE1wRTcreDVY?=
 =?utf-8?B?OUo4bWh1TlNXd1o3MVFCWDZiRjRQVFB3dldPcXBKYVdTRlh4ZlZMK1FSWS9C?=
 =?utf-8?B?RnhSWnJ2dHpNczk5SHNDL0JHVk1XdUNrZlpIcUVpZG9FRE9rYkZYNTZibWtl?=
 =?utf-8?B?TVFhZFhaV2NTSm5wQ1BHUDg1ZFhhbGJoUnlDa0JkS3NubUxrN0JOOW9VV0gx?=
 =?utf-8?B?QnpXaEhkL21iNzVFK1BpU0lnR2VJL1dYcmdHSEFCWlZ3amRKN0lwVmhXcVg5?=
 =?utf-8?B?dEYzOWp1UUttcGxCYnltZGtValF5TWt0Rm9vWXlXa2gxL21EVkwvN0VyZWZq?=
 =?utf-8?B?UEtTU01MRFoydVN4TVFYUXpvTStBZWlsK05KSUdyV241YXozRlNxMkRPdFF1?=
 =?utf-8?B?SnlZR3cxdlBsTTZIc3dDNTdqemtZdy9ib090QWc3YW1rWjMxUGtYL1Z6OExU?=
 =?utf-8?B?Qk9DVWtLS0tSNGR3a05YL3RaU3BBRFJqOW12R0o2STJ1WnZmNnMxS0FPK1hm?=
 =?utf-8?B?eWloM1NjY2dRazBua2huZU9SZSs0Yzg3RmRwSHVXVWtlZEdjaWtWMjUyd2Ft?=
 =?utf-8?B?R2pvU3JuZVFreEpYeS91V0xWSitZSmJkV3VtZGhlZDYxOGNRU1FKcVI2aHE3?=
 =?utf-8?B?a3dHODIrQWJpTVVJRTdBcVQ1eXlGc052V3g4L1hGV3NENjJHQVp1c3RqN3Aw?=
 =?utf-8?B?S3VhNlphdkZhcUNnZ0RLTU02YWUzRUpKQVFBVUZ1SkxJWnh2T0R6V1BCRXh3?=
 =?utf-8?Q?7OiQ=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 10:53:15.9299
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9124e682-0ad3-46a2-0d0c-08ddfceae585
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A105.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7483

On Wed Sep 24, 2025 at 6:06 PM CEST, Nicola Vetrini wrote:
> On 2025-09-24 18:00, Oleksii Moisieiev wrote:
>> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to
>> allow for building Xen without support for booting a regular domain=20
>> (Dom0).
>> This functionality is primarily intended for the ARM architecture.
>>=20
>> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by
>> default for ARM and X86 architecture. This symbol signifies that an
>> architecture has the capability to support a Dom0.
>>=20
>> The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For
>> expert users, this option can be disabled (`CONFIG_EXPERT=3Dy` and no
>> `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0
>> creation code on ARM. This is useful for embedded or dom0less-only
>> scenarios to reduce binary size and complexity.
>>=20
>> The ARM boot path has been updated to panic if it detects a=20
>> non-dom0less
>> configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an=20
>> invalid
>> boot.
>>=20
>> Signed-off-by: Oleksii Moisieiev 
>>=20
>> ---
>>=20
>> Changes in v3:
>> - rephrase error message when dom0less mode wasn't detected while dom0
>> is disabled.
>> - rephrase help message for DOM0_BOOT config option
>> - update DOM0_BOOT dependencies for X86
>>=20
>> Changes in v2:
>> - decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option
>> suggested in ML) because in this case HAS_DOM0LESS should be renamed
>> either.
>> - fix order of HAS_DOM0 config parameter
>> - add HAS_DOM0 option to x86 architecture.
>>=20
>> CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0
>> regular (legacy) domain an optional feature that can be compiled out
>> from the Xen hypervisor build.
>>=20
>> The primary motivation for this change is to enhance modularity and
>> produce a cleaner, more specialized hypervisor binary when a control
>> domain is not needed. In many embedded or dedicated systems, Xen is
>> used in a "dom0less" configuration where guests are pre-configured and
>> launched directly by the hypervisor. In these scenarios, the entire
>> subsystem for booting and managing Dom0 is unnecessary.
>>=20
>> This approach aligns with software quality standards like MISRA C,
>> which advocate for the removal of unreachable or unnecessary code to
>> improve safety and maintainability. Specifically, this change helps=20
>> adhere to:
>>=20
>> MISRA C:2012, Rule 2.2: "There shall be no dead code"
>>=20
>> In a build configured for a dom0less environment, the code responsible
>> for creating Dom0 would be considered "dead code" as it would never be
>> executed. By using the preprocessor to remove it before compilation,
>> we ensure that the final executable is free from this unreachable
>> code. This simplifies static analysis, reduces the attack surface,
>> and makes the codebase easier to verify, which is critical for
>> systems requiring high levels of safety and security.
>>=20
>
> Misra's definition of "dead code" is code that is executed, but can be=20
> removed without changing the behavior of the program, while unreachable=
=20
> code is code that is not executed, so I would cite MISRA C Rule 2.1 ("A=
=20
> project shall not contain unreachable code"), rather that R2.2.
>
>> ---
>>  xen/arch/arm/Kconfig        |  1 +
>>  xen/arch/arm/domain_build.c |  8 ++++++++
>>  xen/arch/arm/setup.c        | 14 ++++++++++----
>>  xen/arch/x86/Kconfig        |  1 +
>>  xen/common/Kconfig          | 11 +++++++++++
>>  5 files changed, 31 insertions(+), 4 deletions(-)
>>=20
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index cf6af68299..336b2ed242 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -17,6 +17,7 @@ config ARM
>>  	select GENERIC_UART_INIT
>>  	select HAS_ALTERNATIVE if HAS_VMAP
>>  	select HAS_DEVICE_TREE_DISCOVERY
>> +	select HAS_DOM0
>>  	select HAS_DOM0LESS
>>  	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
>>  	select HAS_STACK_PROTECTOR
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index fb8fbb1650..62602afc78 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -42,8 +42,10 @@
>>  #include 
>>  #include 
>>=20
>> +#ifdef CONFIG_DOM0_BOOT
>>  static unsigned int __initdata opt_dom0_max_vcpus;
>>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>> +#endif
>>=20
>>  /*
>>   * If true, the extended regions support is enabled for dom0 and
>> @@ -104,6 +106,7 @@ int __init parse_arch_dom0_param(const char *s,=20
>> const char *e)
>>   */
>>  #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>>=20
>> +#ifdef CONFIG_DOM0_BOOT
>>  unsigned int __init dom0_max_vcpus(void)
>>  {
>>      if ( opt_dom0_max_vcpus =3D=3D 0 )
>> @@ -116,6 +119,7 @@ unsigned int __init dom0_max_vcpus(void)
>>=20
>>      return opt_dom0_max_vcpus;
>>  }
>> +#endif
>>=20
>>  /*
>>   * Insert the given pages into a memory bank, banks are ordered by=20
>> address.
>> @@ -1962,6 +1966,7 @@ int __init construct_domain(struct domain *d,=20
>> struct kernel_info *kinfo)
>>      return 0;
>>  }
>>=20
>> +#ifdef CONFIG_DOM0_BOOT
>>  static int __init construct_dom0(struct domain *d)
>>  {
>>      struct kernel_info kinfo =3D KERNEL_INFO_INIT;
>> @@ -1993,6 +1998,7 @@ static int __init construct_dom0(struct domain=20
>> *d)
>>=20
>>      return construct_hwdom(&kinfo, NULL);
>>  }
>> +#endif
>>=20
>>  int __init construct_hwdom(struct kernel_info *kinfo,
>>                             const struct dt_device_node *node)
>> @@ -2046,6 +2052,7 @@ int __init construct_hwdom(struct kernel_info=20
>> *kinfo,
>>      return construct_domain(d, kinfo);
>>  }
>>=20
>> +#ifdef CONFIG_DOM0_BOOT
>>  void __init create_dom0(void)
>>  {
>>      struct domain *dom0;
>> @@ -2103,6 +2110,7 @@ void __init create_dom0(void)
>>=20
>>      set_xs_domain(dom0);
>>  }
>> +#endif /* CONFIG_DOM0_BOOT */
>>=20
>>  /*
>>   * Local variables:
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 7ad870e382..fbb290df60 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -481,12 +481,18 @@ void asmlinkage __init noreturn=20
>> start_xen(unsigned long fdt_paddr)
>>      enable_errata_workarounds();
>>      enable_cpu_features();
>>=20
>> -    /* Create initial domain 0. */
>> -    if ( !is_dom0less_mode() )
>> +    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )

This probably wants inlining in is_dom0less_mode() so every use gets to be
resolved statically.

>> +    {
>> +        /* Create initial domain 0. */
>>          create_dom0();
>> +    }
>>      else
>> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
>> -
>> +    {
>> +        if ( is_dom0less_mode())
>> +            printk(XENLOG_INFO "Xen dom0less mode detected\n");
>> +        else
>> +            panic("Neither dom0 nor dom0less mode was detected,=20

I'd rather have a static check in common code.

BUILD_BUG_ON(!CONFIG_DOM0_BOOT && !CONFIG_DOM0LESS_BOOT);

>> aborting\n");
>> +    }
>>      if ( acpi_disabled )
>>      {
>>          create_domUs();
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> index 3f0f3a0f3a..2aeb361c63 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_DOM0
>>  	select HAS_EHCI
>>  	select HAS_EX_TABLE
>>  	select HAS_FAST_MULTIPLY
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 76f9ce705f..10a8fc8718 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -26,6 +26,14 @@ config DOM0LESS_BOOT
>>  	  Xen boot without the need of a control domain (Dom0), which could=20
>> be
>>  	  present anyway.
>>=20
>> +config DOM0_BOOT
>> +	bool "Dom0 boot support" if EXPERT
>> +	default y
>> +	depends on (ARM && HAS_DOM0 && HAS_DEVICE_TREE_DISCOVERY &&=20
>> DOMAIN_BUILD_HELPERS) || (X86 && HAS_DOM0)

Why not just HAS_DOM0? And why HAS_DEVICE_DISCOVERY and DOMAIN_BUILD_HELPER=
S?

More importantly, why not drop HAS_DOM0 and do "DOM0LESS_BOOT && (X86 || AR=
M)"
instead? Or just HAS_OPTIONAL_DOM0. dom0less is always optional, while dom0=
 is
supported everywhere. HAS_OPTIONAL_DOM0 would signal that a port is capable=
 of
compiling out special dom0 construction logic.

The current dependency list seems off to me.

>> +	help
>> +	  Dom0 boot support enables Xen to boot to the all-powerful domain=20
>> (Dom0).

... or the pvshim, in the current x86 code.

In time we'll probably want to make it so that !DOM0_BOOT && !DOM0LESS_BOOT=
 &&
PV_SHIM means PVSHIM_EXCLUSIVE, which would solve the Kconfig headaches we =
have
with it by making all options additive.

But as things are today, this includes dom0 and the PV shim.

>> +	  If this isn't enabled Xen is expected to boot in dom0less mode=20
>> only.

... or fail to compile (as per my suggestion above) when dom0less isn't
available either.

There's an annoying side effect here. randconfig will be able to create a b=
roken
config. !DOM0_BOOT && !DOM0LESS_BOOT. CI would need adjusting to keep DOM0_=
BOOT
set in randconfig jobs.

I don't have a good solution for that.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 11:12:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 11:12:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131471.1470548 (Exim 4.92)
	(envelope-from )
	id 1v26NQ-00044K-Gl; Fri, 26 Sep 2025 11:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131471.1470548; Fri, 26 Sep 2025 11: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 1v26NQ-00044D-D0; Fri, 26 Sep 2025 11:12:36 +0000
Received: by outflank-mailman (input) for mailman id 1131471;
 Fri, 26 Sep 2025 11:12:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v26NQ-000445-0B
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 11:12:36 +0000
Received: from CY3PR05CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c112::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b14d4b17-9ac9-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 13:12:32 +0200 (CEST)
Received: from PH8P222CA0013.NAMP222.PROD.OUTLOOK.COM (2603:10b6:510:2d7::15)
 by BY5PR12MB4177.namprd12.prod.outlook.com (2603:10b6:a03:201::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.19; Fri, 26 Sep
 2025 11:12:25 +0000
Received: from SN1PEPF0002BA52.namprd03.prod.outlook.com
 (2603:10b6:510:2d7:cafe::31) by PH8P222CA0013.outlook.office365.com
 (2603:10b6:510:2d7::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.21 via Frontend Transport; Fri,
 26 Sep 2025 11:12:25 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Fri, 26 Sep 2025 11:12:25 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 04:12:22 -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: b14d4b17-9ac9-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QDJuvQ77FM2JpoDi+HD1AbBKRm/jV9eulBpJ4DxmFwITyGLM0wIeIojZN90BbFyytid6Goh4SzWiuxyaTv7iI7Tg3YcBsCp7w/oh2PvycigZM27Gw6LNrRGN5cgfuMQ69TKrHqczehVlXARyhl1382WDFT4Aj9vMBVC9xAb+lpwYWVBc6uUjnjcIiQn4Ol5cze+E1Aeq4LNzSJ03ymofR33HBBRKfpVNsWa7qFqR5sTMntYHvQAqY4GgraZZdhNysnCtP9daHAx6nzzezQxxF29Sj4J6RIMcxTyHpCdMIzM7BUD1bfdyaCRHK10CFut4yCOGzRxVQxsuLD208fTcSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fzajiwx0A3guhkdtw7jkMSY57vLA5gqRDVsAbJEPL/4=;
 b=lMpLd6vOfnE2HwwzWNacn62CU5pVDEkvd6t/c6+KQY4gvMOjN6vp9TebfGq2M34mOHsAQdI4PY0HgD2FvU3fxh7OX+lPMB+aX9VkcLDD3f+iuPCHDaXZswFJEdpR8MnvD11kTV8/p2LLRlAzPknZSdG7le+KPmlApH+E7iAfLn9kGs0mctZVYaLA/6x1DUeAemFeouHc1P7WAF0hDZCenQDDp/2eSM/SktOlKKDfraTwQ4Ao50y0oNFqW1nQMIi6PE7SvTdY+kgh3aeHU2KkbJjZxA46sPzCqvtqBonW4577ycmShvDIZu5c66DkadJTcYsv/RcoJG35la8ghKh5+A==
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=fzajiwx0A3guhkdtw7jkMSY57vLA5gqRDVsAbJEPL/4=;
 b=X9mlUAt5500gN5qIz9SqyuAB8QPs6FrMFrWSfEvBcMr2GS/0212aaUm4La375OYEOylYFP8Jad/Xt0Py4UWapH0PZGHd3t9gs5nA6IGq9qCUKxxWRfv9SuQhRuhGX7Lkqf0K16ldoUkaTQJgj0FlAWW7p9I47CIhGm42Dc8chBQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 26 Sep 2025 13:12:20 +0200
Message-ID: 
CC: Andrew Cooper ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx
 regs
From: Alejandro Vallejo 
To: Jan Beulich , Grygorii Strashko
	
X-Mailer: aerc 0.20.1
References: <20250925195558.519568-1-grygorii_strashko@epam.com>
 
 
 <67dd3659-916b-4e64-afe2-e13fdc8d31f0@suse.com>
In-Reply-To: <67dd3659-916b-4e64-afe2-e13fdc8d31f0@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA52:EE_|BY5PR12MB4177:EE_
X-MS-Office365-Filtering-Correlation-Id: 7e9808eb-27dc-4a12-1635-08ddfced92ad
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?UGJzNHZOY2NoYnF3ZnF1V01kVTE3K3Bzd3lkanovd1VWTHNUWEoyWGw4UEtM?=
 =?utf-8?B?cUhmN3JNRitiWlNoOERJUGhTWndaN3pFNnhrdkhGT0ozMDBsMHNiZTZ5dFpS?=
 =?utf-8?B?TXRjckJGSmJSdnFDcWtDdXc5alkvM3pEbmxDaFVXb0lxS2tWVFQzQkpYMDRO?=
 =?utf-8?B?aXh6aXc0WGI2RWlXcHJYVHFzRTdzMlBNTXZIYzNFZFBsVEtNVWp6blQrazdO?=
 =?utf-8?B?dHBHenpqU1JGdHVJK0grRlhxbmV3TjY0bWljQW1GckN0dE9HV0NwRnFwUEI4?=
 =?utf-8?B?Z3pwaEtaakQ0V1grVzBSLzdUQXZKUDczWGVRK2ZVY1I0VVJXSk9UMWhUU0FB?=
 =?utf-8?B?YWFUTjFNMDhXSGVpZmdKbVI4N3kyd0FnVU4xb2NTNit2UlNWZ3dORThFWG90?=
 =?utf-8?B?YTdqTFZ6YkFTajFGdnRWTy8wOFM2NSs4MlhnQzBaNkRXaVk4dDNVaXFWUUg3?=
 =?utf-8?B?WGphVDVSRVoyQWlvSVNlY0x2M0FDYUFTamZHL3hib1dLYk5FWWRweHkzcEpV?=
 =?utf-8?B?dnFFSHE4RHYxVUdJeGR4bmRzTkhWMVNwemZ3L2tZSGdQU2JnRFJMWWl6YUla?=
 =?utf-8?B?NG1XYUowdFZXdmViTHNxa3FtK1NhS1NuTE5zUkdBTFhLbktJcFVMVk1jQVZz?=
 =?utf-8?B?dWQrY3laUEJXcVF6Z0MzYTltMXk0cGZxL1Y3aCtjQThNbVo0WHdyVjBScEpa?=
 =?utf-8?B?dnRaWW04RWt1a2ZRZ3diOFh4RzllY3BqT0NYbi9ja0ZtaWk5c0sxQ2hnOGFD?=
 =?utf-8?B?Y2NMTWhJTDVjNzNYcUlLNVJrZ0h2Z2dENHJrc0UyT1Z1dHl0QlJDYlhvdEZV?=
 =?utf-8?B?dk9USDFreFAyK1d6cWxUS0JNVWR4anRkUWl2aFdIUGdqTXd0bUlaRlJMZUZn?=
 =?utf-8?B?OVUvbkRubktBaXBHVkgycjhNK1p2MTB2cVBLcGwzQ1dobVp2eGluaXFnYW4x?=
 =?utf-8?B?MWJNQndreWN5azgycWtDQThrOWJiUFFMbmhSRWtpaUNKK0RoSlJjaEhJQzZK?=
 =?utf-8?B?dTR6dkYwRWc5THRQaElRdUFSM3llTHNBckt5cXRnNlFWSUcvR2J3WGdOWU45?=
 =?utf-8?B?YUw0a2hVQ2VZdWlsbDJYbnlyeWw0S0wyRGtTQmFXNDBoaVF6dnJ6VjI2bUVo?=
 =?utf-8?B?dUNORXFNY2lZT1BkOHcyZW9yVVg3N0syNGE2Q1BtWDlRQ1orWWd3OUNzUUdP?=
 =?utf-8?B?QUI0UjlreStpQjNITU02bmZtYzU1RUd3V2l0aE9QYmRmTWQ1eWFCenF0MThm?=
 =?utf-8?B?RVJMeWZEQkUzeHl3RDl1cDliZDlKdFlDVDVrRW9mcEc2WHZId21MajJ6VmhV?=
 =?utf-8?B?bFljcXgrcHpSN0haTjU0TTM0bkZML0I5WlB6NmxHTGlRcHMyRmd0Z1YyM3pv?=
 =?utf-8?B?NHMrRDg4ek9FNHRqZ3JRMThwcms1VmZUMmRDWCtYTXdBbVg2QzBRQ1BuOHhH?=
 =?utf-8?B?dnNzM3BqSHFESlNmQWRIN1dxZ1RjbUQzZ0d0T2NqNmRVRDBwNnMxeE1LYVY0?=
 =?utf-8?B?RGFWWCtYUllvbTlFN2d3dVRhUWYrVTRmOGRUZFc1cUJhaDBXNk9URm8wNHJy?=
 =?utf-8?B?VVFyVTNnNDM2c0NKVG5uYU11VFo3M2hFRzUrZDhoajltNzRnRWpiVVE1dkY2?=
 =?utf-8?B?RStXaUI0U2xUeXRuUlJ5NGhzU1AvVkFucTVhb1FnNnJlQUY4bGNzQndLemVl?=
 =?utf-8?B?NHA2V0lWWS9mcjNPUm9PcEJFTG9CZ2JYckdSZHBVVWtZWXdHTEprbkltbmFa?=
 =?utf-8?B?cnl5cmNRSHpBcXljUUd0K01kUWJPdzFNN21UbjNZTXJNNUpsZXN3REtaUlRP?=
 =?utf-8?B?NDY3QXluVDFBWGVDTjRsS0RubzFnNVBpNmxhZ216UC9JN0lWeEZuN1d3TnFu?=
 =?utf-8?B?UWEyQnhWWmlnZTBGYVlmOWtKdjhzZ3dZTlVYSGJPTkJpaGp4bTlRQk5YYVpq?=
 =?utf-8?B?MnUwRFFtNDN2V2tNejdBVHRydWNPRXJOWkFwb29yd3U4U0V4ODNHMHNDbXJk?=
 =?utf-8?B?Vk5laFZWOE1NV1FHYVRSeHdkM1EvMFhLcEZuNmRsdjVDVTllT1dTeFFDR3Nj?=
 =?utf-8?Q?QJKOgS?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 11:12:25.4023
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e9808eb-27dc-4a12-1635-08ddfced92ad
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002BA52.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4177

On Fri Sep 26, 2025 at 12:52 PM CEST, Jan Beulich wrote:
> On 26.09.2025 12:38, Grygorii Strashko wrote:
>> On 26.09.25 11:17, Jan Beulich wrote:
>>> On 25.09.2025 21:55, Grygorii Strashko wrote:
>>>> From: Grygorii Strashko 
>>>>
>>>> The LAPIC LVTx registers have two RO bits:
>>>> - all: Delivery Status (DS) bit 12
>>>> - LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
>>>>    This bit is reserved for other LVTx regs with RAZ/WI access type (M=
MIO), while
>>>>    WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bit=
s
>>>>    (MBZ access type).
>>>
>>> Question is what the behavior is for writing the r/o (but not reserved)=
 bits.
>>> I wasn't able to find any statement in the SDM.
>>=20
>> Me too. Usually RO/WI on most HW.
>> For example, LAPIC MMIO "Write" will be ignored (WRMSR will trigger exce=
ption).
>
> My remark was specifically about WRMSR, and what you say here contradicts=
 ...

Not quite what you're asking, but writing to the X2APIC_ID register does tr=
igger
#GP(0), so one would hope writing to RO bits triggers an exception too rath=
er
than being WI when mixed with RW bits in a register.

Now again, it might not in order to avoid #GP(0) on a race.

Definitely worth running a silly test with wrmsr_safe() to make sure. I cou=
ld
see real hardware going either way.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 11:31:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 11:31:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131493.1470557 (Exim 4.92)
	(envelope-from )
	id 1v26fQ-0006sa-TQ; Fri, 26 Sep 2025 11:31:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131493.1470557; Fri, 26 Sep 2025 11: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 1v26fQ-0006sT-QW; Fri, 26 Sep 2025 11:31:12 +0000
Received: by outflank-mailman (input) for mailman id 1131493;
 Fri, 26 Sep 2025 11:31: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 1v26fP-0006sN-QD
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 11:31:11 +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 4bd69ae2-9acc-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 13:31:08 +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 0873721B3F;
 Fri, 26 Sep 2025 11:31:08 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CEF1F1386E;
 Fri, 26 Sep 2025 11:31:07 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id oHKFMHt51mgVMgAAD6G6ig
 (envelope-from ); Fri, 26 Sep 2025 11:31: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: 4bd69ae2-9acc-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758886268; 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=CgfZTkOg3UTNmDXa9dluiKewI2hBakJjDBZ7pJ3NgXk=;
	b=kvmGIKnQKcGRJuFxwa4kkAh1Osv+y4oFv+ED1kEO6fP/m6ic+rfzroR1znLMEa6fis9tve
	x5b7pR12w67QybUUCbShzr6ICMoVJY1PH6nqZ90ew0YOmm+2j9XmqTkiGHWVjlml5FPcS+
	HW9T79njMNeUP/sRFnqMF2UzRJWK7O4=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1758886268; 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=CgfZTkOg3UTNmDXa9dluiKewI2hBakJjDBZ7pJ3NgXk=;
	b=kvmGIKnQKcGRJuFxwa4kkAh1Osv+y4oFv+ED1kEO6fP/m6ic+rfzroR1znLMEa6fis9tve
	x5b7pR12w67QybUUCbShzr6ICMoVJY1PH6nqZ90ew0YOmm+2j9XmqTkiGHWVjlml5FPcS+
	HW9T79njMNeUP/sRFnqMF2UzRJWK7O4=
From: Juergen Gross 
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	sstabellini@kernel.org
Subject: [GIT PULL] xen: branch for v6.18-rc1
Date: Fri, 26 Sep 2025 13:31:05 +0200
Message-ID: <20250926113107.22638-1-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -3.30

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.18-rc1-tag

xen: branch for v6.18-rc1

It contains the following patches:

- a 3 patch series fixing the migration of a Xen virq to another cpu
  plus some related cleanup work

- a 3 patch series cleaning up Xen-PV mode specific code, resulting in
  removing some of that code in the resulting binary in case
  CONFIG_XEN_PV is not set

- 2 fixes and 1 cleanup patch for suspend handling under Xen


Thanks.

Juergen

 arch/x86/configs/xen.config        |  1 -
 arch/x86/include/asm/xen/page.h    | 14 +++++++-------
 arch/x86/xen/Kconfig               |  7 +------
 arch/x86/xen/enlighten_pv.c        |  2 +-
 arch/x86/xen/mmu.c                 |  2 +-
 arch/x86/xen/p2m.c                 |  4 ++--
 drivers/xen/balloon.c              |  4 ++--
 drivers/xen/events/events_base.c   | 37 +++++++++++++++++++++++++++++--------
 drivers/xen/gntdev-dmabuf.c        |  7 +++----
 drivers/xen/gntdev-dmabuf.h        |  2 +-
 drivers/xen/gntdev.c               | 33 ++++++++++++++-------------------
 drivers/xen/grant-table.c          |  6 +++---
 drivers/xen/manage.c               | 14 ++++++++++++--
 drivers/xen/privcmd.c              | 14 ++++++--------
 drivers/xen/unpopulated-alloc.c    |  4 ++--
 drivers/xen/xenbus/xenbus_client.c |  2 +-
 include/xen/grant_table.h          |  4 ++--
 include/xen/mem-reservation.h      |  4 ++--
 include/xen/xen-ops.h              |  7 ++++---
 include/xen/xen.h                  |  9 ++++++++-
 20 files changed, 101 insertions(+), 76 deletions(-)

Jason Andryuk (3):
      xen/events: Cleanup find_virq() return codes
      xen/events: Return -EEXIST for bound VIRQs
      xen/events: Update virq_to_irq on migration

Juergen Gross (3):
      xen: rework xen_pv_domain()
      xen: replace XENFEAT_auto_translated_physmap with xen_pv_domain()
      drivers/xen/gntdev: use xen_pv_domain() instead of cached value

Lukas Bulwahn (1):
      x86/xen: select HIBERNATE_CALLBACKS more directly

Lukas Wunner (1):
      xen/manage: Fix suspend error path

Marek Marczykowski-Górecki (1):
      xen: take system_transition_mutex on suspend


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 11:34:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 11:34:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131504.1470568 (Exim 4.92)
	(envelope-from )
	id 1v26iS-0007Rw-AH; Fri, 26 Sep 2025 11:34:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131504.1470568; Fri, 26 Sep 2025 11:34: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 1v26iS-0007Rp-7R; Fri, 26 Sep 2025 11:34:20 +0000
Received: by outflank-mailman (input) for mailman id 1131504;
 Fri, 26 Sep 2025 11:34: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 1v26iR-0007Rj-Bf
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 11:34:19 +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 ba71f541-9acc-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 13:34:14 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by DU0PR03MB9850.eurprd03.prod.outlook.com (2603:10a6:10:449::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.13; Fri, 26 Sep
 2025 11:34:10 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.008; Fri, 26 Sep 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: ba71f541-9acc-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eWIpIr+PQdgOuyjL6JXg+wg40RNnQRe9GGLkXc6HalqCsmF6XqDiozbwIuw71DEj4i0La3Ijv8UIdEEbuv2ME+QXmJsPpQIYHWgCojE0ACmPgcBggcigqopfxLEajgxt8CiQKCm5qArfxCN+EYXoahFyisYKh2vnZrSIPXEJzrH0l/Jb7L/7Jcj4WNgENWmhnRWz8ypBrlQeplOBg3KIciA/VbCWd5mDu46EUbBN0ypUi6RfJTKaYg1ReodcFYmjxnzvZv15TnUFPRj6JXWK8XCZ9YZqDElHMFEe0L5fVZvUr4AMUo84wEWl2kzpuI2GEJRDzGzGk15G6Ko4dePfqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lDveB0z0IWUTiwfsPqeUVIxWy6C0/DR8E2pKH/EZrCw=;
 b=mUkSBOoHcdCeuG4mYEBNGXs2C8Mb62b8ytRUG+azaSXk9cY0jeVAD4pH6zle7RHIIIFXEbxYhAgQcuDebHIHsY1mdIyMoVaWpgvxxmptXoVfoNifdfRYClQVaFn35K75dhNGpG9RkIITDa/E0eaGym/kvYlRF56SJd2MQe+C5aaiz8Ubfl07S21op3UJEguCj1FcpZ+jSNgjAE32terf5FT8EJBeHQXjKI8HJsuj8CLHiogmXl5CHo+oJaj57KNMn/0tsgqTqVfA8V51z9Sos2elWv1vbd/4fmui/ylxb1JK2Ttiw1sqMDiJGuJSxGFPyBioaL3hK2RxcTMBexZeqA==
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=lDveB0z0IWUTiwfsPqeUVIxWy6C0/DR8E2pKH/EZrCw=;
 b=pa2G7ErqNCxLToAOlf1Rb2uIj3i/AigGiWP4b7uhvWoz7+Mz7CU2nxuT3BX7cQVJaxvf0RYfpW463rZpcUBevR3Z3csVzNeV4BgR5YxSXRYU54TlYm/a4mXV5wYfQVOou6bQIY6k28Emuj1DQUtplDJDiEZyVkXFbXMNR0lGBGtMWL2NCDFTXMHDyXjCkou0wYagYxG5sESuSmsKsMR+Rf7HL2gTo1N+4/m+EC68f5vApV4lpBSlxXR7E/mED6T39QnlM0+efIlAfIXC79YzEjSCC/RAbyBpbdM1C8DIjjwxC6cJZNpgWLA26pBVzDAw9TToqF/pmCli2VQ5+8XeZQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Fri, 26 Sep 2025 14:34:08 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Jason Andryuk ,
 "xen-devel@lists.xenproject.org" 
References: <20250925195558.519568-1-grygorii_strashko@epam.com>
 
 
 <67dd3659-916b-4e64-afe2-e13fdc8d31f0@suse.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <67dd3659-916b-4e64-afe2-e13fdc8d31f0@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0379.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f7::11) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|DU0PR03MB9850:EE_
X-MS-Office365-Filtering-Correlation-Id: 13117261-a6e2-4269-e3e6-08ddfcf09c57
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?K3ZPSW9BWFhxNFZMamZXdHBSTzUrdFlvS29RWThLd0pGV094c1JxazFZTzBM?=
 =?utf-8?B?RHFUNzRWSVY4RU0zMVlUUmNxRWduQkMwWnQ5WlVqaU1IT2h0R2J3emM2Ly9U?=
 =?utf-8?B?dmc3MlJwQk5zMFpMeXVrUHVZUWFYR0w4WTM4ekExa1NZYjBsdDZ5a0JkRUZ4?=
 =?utf-8?B?MUIwRG9xbzBNTXhEOEszQk5hcDJKTkJ4NEV0QWcrcDhWeXkxYnAzZU05Y05R?=
 =?utf-8?B?WmJZU2dEU2pDWGtPMzhldXZkYkxod1VHWXN2dFJaSnIxNnUyWU9iYVl5WHo5?=
 =?utf-8?B?RW5MS3pMTEZIZ2lOYWtDVEhnQ2ROb3dNYytHakxHdDVHYzBNOW4xM3E3VXFq?=
 =?utf-8?B?WVRSclV2NGsxdjBMeWxQV2lib0xtMEtpRHkrRHMrTU4vRWFoS0p5aEhJNzRJ?=
 =?utf-8?B?UFlCNXc5STVlS3RabWtFT2JadCsxendLWDNQRWUrNWNTUSt3MlBKeTlnWFVR?=
 =?utf-8?B?Q1o5MDVKRVlwV05kOVBJd0h1Z3FQRDFaV0VQSW1jTkQvSk1OSU1GUEhuU1V6?=
 =?utf-8?B?YzRGdUFGaVQxTU1rYTZ6V3RtL0JwMm13SUFDcHNvd1pzRWR3VDlEa2gxcVZW?=
 =?utf-8?B?TFBRblU2TzREOHo4L1VsN2Y0NVZaY29peDNzK094NGUvTys2SVorTHhhVnVD?=
 =?utf-8?B?Q2FMTC9TRWJSaHcvV3U3dkRxZzBxZWs2ZGNkTk1yTzU0L0dSaFVSdjQ1YzhO?=
 =?utf-8?B?eWpWbU83ak5qWGtkMGJVYkFNd1NWV1E2citFMlE4VHdkalhSQUJVMkFJNkRu?=
 =?utf-8?B?UmtISGNzazF4Z0ZFM0JBNnN2ZklMUEhXcXd2WmU0QjllNzZvMU9MY3hyWExC?=
 =?utf-8?B?TkF5NzlYV3o0cjhBNmRldEZvZU51NGx0cFYzRnZKS3U5dFh5R25RVk10N3Nh?=
 =?utf-8?B?NjRPUkthbU44SU9mT3FUYUcyVE5Ic1RxS3JMemZsOEFGcHdrNC8zWDNWQS9j?=
 =?utf-8?B?azVvOHF3VnQzVVhTL1huSEMyTTJKVDdzRmUrWXdoeVZsd2dvK2Nzckl2VkJ4?=
 =?utf-8?B?WS9kWlpPSWhmRXVtYVA4UXYrb1c0WHVWcUV5NEtPU1BvVE5EWlBmOHhDR1VI?=
 =?utf-8?B?Sk5GYnY4bUdBQld3YXRaS2ExWW5DRWhySUhPa0hDTXYyVFpsaW5RQUFtWDM3?=
 =?utf-8?B?bjJPRC9UKzZFbG5DWTl0cEtFUThJei9TSk5JcUlGUG9oODFHdG1wVFZzWC9J?=
 =?utf-8?B?UllHVW84OC9yU0kzTHY3TVV1U04zbjdlSlZoWmdpUW40OEdReGMzdFRLT2hS?=
 =?utf-8?B?NFV1aXFnVmk5Wk9RcjZ2VzlqN3ZvSWJOV2tNTmZsSTZXQU1UUHdzTFY2RThp?=
 =?utf-8?B?QjF0QVRKczdhS3pHVThOYkE3THJQdmhhNVZFMTM4aFF0Wk5nWHdMVEUzNDRz?=
 =?utf-8?B?SDJnWUI3WkZ0REp2ZGl6S0x0N2R1Z1Zod0hNOXYxQS9oSTBNOHE4cFlCZWYv?=
 =?utf-8?B?Z0dxUDAxUFF4T09rc2EzZ2pxOE1HZHN4MHFwNElhb3ZSM0R2V0RFZzhSNEtB?=
 =?utf-8?B?MHYwOTllaVBaV0RhRkhDMWRiTHJJeUpYeTlubUc1L2x3STZJUkNhUlRKMGwx?=
 =?utf-8?B?UWJxYTVSMEZZMHdjQk01RGlRSTc3T3FQV01NWFNITHJ3UElmWHNKWm1hTkc3?=
 =?utf-8?B?VFUvSi9rWUVUZXR2Ykc3bHMxUXJzMHVPSmxzbitBaXU5dTFMbUZFTnMwRTVQ?=
 =?utf-8?B?aE1JS3A2TmFQald6MXRsbjBmMFRqdjRkV1luM01PREZISmpBQ3JMbjk5ck1W?=
 =?utf-8?B?L0VRbTE3ZkxvclFWaGlybUU2Uk1mTHNjWWZ6Slk4QlFtemJoTnB5OVJzMERi?=
 =?utf-8?B?OXA3NFpmWWluaUVyYWFZZUczZXZpNURRMHhkMjY5dEkyekU4dXdlazgzQmJm?=
 =?utf-8?B?ajdzNlhkRFVnVFR3cVNoWld3WmVuU3QwY1FPeFFFdENhZkdWOXNsVnB2cWpj?=
 =?utf-8?Q?5heGnYg7awM=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dUZYNVRWV1M4cWJoOWhFb1ZWQnRLK3VOOFNLam80Y3NYaDgrOWd5ZXRKSFI4?=
 =?utf-8?B?anVNMHpzTnZMb1pvWjRTY1dyOUpHU05VSCtCOGhaOG9QOHB2MmhTeFp0MU1D?=
 =?utf-8?B?QzUwT1RJRVVsZllGV0MxMmlWK0xFeXRJN1M2Y0VYWWlhTy9NM0t2K3BZWk9C?=
 =?utf-8?B?MTJ3blRzZHA3TThnZHBXcjFjb0xJblI4aGNXM3JzTUtPWW9TWWxWaWdORDVG?=
 =?utf-8?B?aFN2RjVyUHh4bVZvUFhnejBSSHhTRGFWYjYreldrZTh1enRRY04vcGhVRGRp?=
 =?utf-8?B?MGM2QXFvN0xydERHMXZGMjNIR3BjRGM2QWNzZGF5bjExZDliWlY1UDM5YThK?=
 =?utf-8?B?T2E5T3kvNUFFMkcvRVB4dWJ1bHZxVVhqUkpGRVJ1NUFEUitEaGlSMUlvekdK?=
 =?utf-8?B?VUZsS3JUQWpNTnFRRnZITlRlcDNVVElkbGl1aWRLYXdKZmVmNS9KdlBFRFlD?=
 =?utf-8?B?dFRVdHg3OVd2NEtEZllIZFlyTlhScEZ6TWlhZVR3MmJwUld1NWR0RzhDTHNV?=
 =?utf-8?B?WU8rdlZ6dDdpY1FWZFFobHQyLy9nbVlic09JZWgzczdEanhuWXY5V0RBcVZh?=
 =?utf-8?B?OGUzUU5mT1RaZldLc1pLUGhwSDVmMmI1WldjTGZwV3NEdXM0Zjl6U2orQ2FU?=
 =?utf-8?B?MzJpREc3bE5kZnZsbW1RR2R5ZzlZRVhzcTV2UDZwdTRvS2I2STh0K1hsSWl0?=
 =?utf-8?B?K1Y2eTNYVzhrcFdtbk1VeUNCSDhrWjQza2xwTEoweVEwVHU0VDBxV3hSdlE5?=
 =?utf-8?B?V3JSOXVpeWNEWXhXUFJhdlZtamRmUE9IQStreE9ZcVF4K1lMeTUxSkFwWGxW?=
 =?utf-8?B?aC9XUGFNS3Q3dFlLNjZ5UVlQQWlLSDh3Z0Flcy8wTWFlU21vUEt6MEdpd0gy?=
 =?utf-8?B?QXJSclluNUZkSHBYZ1ZNSll5MURqMDhVUnF1OFpHNE9ITlQvNklCMDJTVlZE?=
 =?utf-8?B?azlpRUJaVk5iOHA4dEE4TGprcFdLY0lZejVRTUlkWWNDckN3bjlRbjhWQWRt?=
 =?utf-8?B?YW9ZNGRWeGVMRDM3RlZFeStpVlBUSTl0bEpRZFFjNkNMejhLdjMzcGU2VS9F?=
 =?utf-8?B?MTRDa0YwdXdjcERZSWFNaGd5TkswS0tTN0tsWFFvbFcrQTVGQmdKV0N0MFJw?=
 =?utf-8?B?Nld5YUt3b0pRc2ZMSWhTWURLVCtKYWFhZ201bFJhSVQyTE4xaHZtajVtOVNo?=
 =?utf-8?B?NDlPQTAzVVdFemlkaU42YWFMSmJQN0oxSzB0M0NhbXBEVThKdmRKNDV0NjJl?=
 =?utf-8?B?NTV3SmEyTUxaRDkxUEM4dW4rbThZZDhaK0phK1BjamRRdGQxSldiOWZ0RG5I?=
 =?utf-8?B?aDhhS0g0cjlHWFl2TStpZHJ3d3FmUlV1YmdoYSsyVzNWeGYzOFF3V3FTNk84?=
 =?utf-8?B?bEdaNFh6clNnMEhycWVhL3gvQVBsOTNCaEg4Y2x3ZkVCdGVwKzlrVWpvbGtQ?=
 =?utf-8?B?dVRwUGJldG5BRmhqOEtwOUVINWxtN3A2ZlBRK3VvV1ZjK3JwcytPZGxiM0tM?=
 =?utf-8?B?ODI3dDlMQWU1K1N2ZFVkM3E0MDJrcGRBb1N3eVBZTWNYeDlPM2ZqS09mcGlp?=
 =?utf-8?B?Tjl6QkJ3cFpQb0V5eEJXOS9wT0tYK0dVSUJPWklvRmdYWk8rMGNCVSs5YVZP?=
 =?utf-8?B?WUdjaE1rdklnamxRTXBGZjJ1T1NOUVJoSTRFaGF0Q1ZzNVZnL05LaFIrSmcz?=
 =?utf-8?B?NThNUlRRaUdzeW5XakFGdnE0TWViUkNpcXBKamRTYWhTa2lueGhjR1ByaUdX?=
 =?utf-8?B?OVhrUFd0SnNkSnE5cUt2LzUzMjJtdXJSWWVDN0NPTnpaQml3ZzB0ZWg1U2Vw?=
 =?utf-8?B?eCtreTRpYW95dmw4RTBkYW1jUjVpVnQrcGFaNU1zejFZSFRlVElKSGJyZ3Jl?=
 =?utf-8?B?eE4xSjhTOElxbUIyMWNFd3VJamprWWtjMUNsSENBbGdLc1phTnRKUmRjNXZp?=
 =?utf-8?B?MExSODlvM3NRbEoycUpEbElYOXlOOGFKRDJaMmV2ZmY5bW1MSTIvNFMvazhw?=
 =?utf-8?B?bWFvR0FKNERxN05tbXdFWmZMZ1VxTzJoMUtxMFdZdit1bUFnTkVZQjdlM002?=
 =?utf-8?B?Ni9EQjg3UE9GT08rVkRCUVRGWEY2NndmcHJIb1c5Q0V3SmdzejBXMy9IR1dz?=
 =?utf-8?B?MmU1VnY0NjZSb1hKWWZCZW9VSEo2WkZ4OGllN2tneEJqdmJ5NUoxcWtMWkVj?=
 =?utf-8?B?Q1E9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13117261-a6e2-4269-e3e6-08ddfcf09c57
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2025 11:34:10.3272
 (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: HzvT+IuG0dkyUs4BvccZusGm/uqND+2Ex2teSuLYm75IbhbWXzT+Q/VQR44nswKbX5jFOi6qkzryLqQB0es2jgFQWZsqE4kl8zuzzpFjXZI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9850



On 26.09.25 13:52, Jan Beulich wrote:
> On 26.09.2025 12:38, Grygorii Strashko wrote:
>> On 26.09.25 11:17, Jan Beulich wrote:
>>> On 25.09.2025 21:55, Grygorii Strashko wrote:
>>>> From: Grygorii Strashko 
>>>>
>>>> The LAPIC LVTx registers have two RO bits:
>>>> - all: Delivery Status (DS) bit 12
>>>> - LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
>>>>     This bit is reserved for other LVTx regs with RAZ/WI access type (MMIO), while
>>>>     WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bits
>>>>     (MBZ access type).
>>>
>>> Question is what the behavior is for writing the r/o (but not reserved) bits.
>>> I wasn't able to find any statement in the SDM.
>>
>> Me too. Usually RO/WI on most HW.
>> For example, LAPIC MMIO "Write" will be ignored (WRMSR will trigger exception).

Sorry, ignore ^ sentence.

> 
> My remark was specifically about WRMSR, and what you say here contradicts ...

> 
>>>> --- a/xen/arch/x86/hvm/vlapic.c
>>>> +++ b/xen/arch/x86/hvm/vlapic.c
>>>> @@ -880,6 +880,7 @@ void vlapic_reg_write(struct vcpu *v, unsigned int reg, uint32_t val)
>>>>            if ( vlapic_sw_disabled(vlapic) )
>>>>                val |= APIC_LVT_MASKED;
>>>>            val &= array_access_nospec(vlapic_lvt_mask, (reg - APIC_LVTT) >> 4);
>>>> +        val &= ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING);
>>>
>>> There shouldn't be a 2nd &= here; what needs adding should imo be added to
>>> (really: removed from) vlapic_lvt_mask[].
>>
>> I'll try it.
>>
>>    (Orthogonal to this I wonder whether
>>> guest_wrmsr_x2apic() wouldn't better use that array, too.)
>>
>> WRMSR checks for MBZ. RO bits are not MBZ, so masks are different.
> 
> ... what you say here.

Above reflects current code - guest_wrmsr_x2apic() allows valid RO bits,
then vlapic_reg_write() ignores (W/I) them.
That's why masks are different between guest_wrmsr_x2apic and vlapic_reg_write.

> 
>>> While looking at this, don't we have an issue with CMCI as well?
>>
>> I see no APIC_CMCI write emulation. only read.
> 
> guest_wrmsr_x2apic() has
> 
>      case APIC_CMCI:

it will end up calling vlapic_reg_write() which doesn't have case statement for
APIC_CMCI - write ignored.

> 
>>> guest_{rd,wr}msr_x2apic() handle it, but vlapic_reg_write() doesn't. I.e. on
>>> AMD we would fail to deliver #GP when the guest accesses it, while on Intel
>>> we would lose the value written. And we also don't set its mask bit in
>>> vlapic_do_init(). I guess I need to make a patch ...
>>
>> Is'n it depends on CMCI capability exposing to guest?
> 
> Yes, that's part of what I was (effectively) saying.
> 
>> (have no idea what's CMCI :)
> 
> Corrected Machine Check Interrupt.

Looking at:

  #define VLAPIC_VERSION                  0x00050014

which means "Max LVT Entries" = 6 (5+1)

Looking at linux kernel apic.c:
#ifdef CONFIG_X86_MCE_INTEL
	if (maxlvt >= 6) {
		v = apic_read(APIC_LVTCMCI);
		if (!(v & APIC_LVT_MASKED))
			apic_write(APIC_LVTCMCI, v | APIC_LVT_MASKED);
	}
#endif

Which means Xen never really emulated APIC_CMCI, so wouldn't it be correct to just drop APIC_CMCI?
Also, taking into account that it's Intel specific.

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 12:00:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 12:00:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131521.1470578 (Exim 4.92)
	(envelope-from )
	id 1v277R-0003DZ-DF; Fri, 26 Sep 2025 12:00:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131521.1470578; Fri, 26 Sep 2025 12:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v277R-0003DS-AP; Fri, 26 Sep 2025 12:00:09 +0000
Received: by outflank-mailman (input) for mailman id 1131521;
 Fri, 26 Sep 2025 12:00: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 1v277Q-0003D8-9f
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 12:00:08 +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 57a6c605-9ad0-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 14:00:06 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-62fc89cd68bso4121789a12.0
 for ; Fri, 26 Sep 2025 05:00:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353e5d0c70sm352341966b.15.2025.09.26.05.00.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 05:00: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: 57a6c605-9ad0-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758888006; x=1759492806; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=O2imnWOo1AJwHjjUKzWb7gwy3ZnqP7tifsml8SS3l9w=;
        b=BxVm1xqupUeVOZfKhCCL2GGPYshRMRTKWW6QUE8rI1zecA+DOUES67XWvjRWHHEAh4
         N0kDaNQQFQ8D2jOtg43yNVczCCMmq5S7cPyxfqwlNZOxVB8Y9ElXAiFS31luPzXRqGYQ
         Nrz/CH+0Sbip87LrDlLNf7BBYbigUOXVFa033dSDytBujErHZCg+d+uuFvJvsv5RYANJ
         pNJeIkhtJ2LoTTKP4BDdFHpbiabfpJD2KivE00MDKe6z8s8i6uM4jKMsWAKNwDFIzapk
         zOVTbIu02/nKG/Zfk4OaBu0ie2u2vi4aj6qT5PJTQ7+4unfS7pFU8WgzGIRn9NPiQo+M
         POfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758888006; x=1759492806;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=O2imnWOo1AJwHjjUKzWb7gwy3ZnqP7tifsml8SS3l9w=;
        b=dAunuGDfOnm9aPZ5XIg3EylTXZVJ0yhZ3IXG+KzzeEZuR5+LgqZOZJc3rttzoTepxB
         QcrYOJGNzUtV9JLInlecFRSJdFcTbepoaALumdOBcRIc5GcK11k+pdz3Of6P3O4iyTEm
         MjkwKMtOwUUDin+cfw8fk6ioRP6WSuiOL1Q/2L2HWIGtS9gGA5CKcvYjjSP1BgdeirEC
         GXJVJMxOvZFqpkpkD5kALlw4EIi5NqXZOWVcFVD+6d3mgit96NltC0Uq+n9q/xSlZsdm
         gPa62dGVTgQ2X9mXypIzL3/NJAn8TNPBVj5H3w3JXAGyNLUxWWnVKBQBkelRsTkyDs15
         f3Mg==
X-Forwarded-Encrypted: i=1; AJvYcCUEmPArUBI9Ub7P4jFTycfAqHCJ5YH9Q17x4/8AkKwo3lW33MVzTbh4yOXfxK+BQHzeVRxYZNrwg2w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YykVZ0tH0R7Bo0N+wCv35bMNe43T+KjvFFxj7NH9hfd+7ZdxJwg
	XKF2hqzEiL7M3za/GDTOXFWQRdiF8T6IBraznjl3ZACQumkoq0nAqj1ItAfT6OxIGA==
X-Gm-Gg: ASbGncvpem2QNchjcx2+9VNoXnrsX6lKZBL4Bkl/6rfF3RAjvH/D58E+tgcRI15EKul
	I5q4kKVwqpSdjY74/qrbVDSR7WnNImqgJ/oGPXuIQrMb7Yfm4hdVDtV7XCH++UGm+f3msFbMvN9
	egC+xua/kO4JiW0FIngtAHUjwbwXwU1hus+t2ngJ0O/2sCf9CMN63bJhV3T8+VokAmr/nQqfl/q
	FEjuqBHW63YnEzjwKYOSMG5Nrmel0PyEq93M3bOypOx4WOQ5PskUYpk8sEfG6Cpv/9962ormHI5
	MxFQzYX9PxFBRcAVQWfsT4Hj+YKj7ZTurnWO2frwEoeDQMrVg6hajBWnXOTjHuZheKnuAEdJ1Nj
	RY4c0CbgIlltVaRpHx/+z3AlLGS2h/sqVOiGRozjdwUKq79I9bYx1w21wuvvGl6k4pS5dkoGRPG
	JY/4B3bX4=
X-Google-Smtp-Source: AGHT+IHulLe6R0tsWctH1JlmKW0RcYr/838iYlb6y1vj9CBILACBdnzKJ9GkuMu+wMEJoiYTfyGFmw==
X-Received: by 2002:a17:906:c108:b0:b17:ec4a:4f2f with SMTP id a640c23a62f3a-b34bb700989mr842559366b.27.1758888005655;
        Fri, 26 Sep 2025 05:00:05 -0700 (PDT)
Message-ID: <5472d09f-4bce-4aeb-b517-79348923281d@suse.com>
Date: Fri, 26 Sep 2025 14:00:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
To: Grygorii Strashko 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo ,
 Jason Andryuk ,
 "xen-devel@lists.xenproject.org" 
References: <20250925195558.519568-1-grygorii_strashko@epam.com>
 
 
 <67dd3659-916b-4e64-afe2-e13fdc8d31f0@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.09.2025 13:34, Grygorii Strashko wrote:
> On 26.09.25 13:52, Jan Beulich wrote:
>> On 26.09.2025 12:38, Grygorii Strashko wrote:
>>> On 26.09.25 11:17, Jan Beulich wrote:
>>>> On 25.09.2025 21:55, Grygorii Strashko wrote:
>>>> While looking at this, don't we have an issue with CMCI as well?
>>>
>>> I see no APIC_CMCI write emulation. only read.
>>
>> guest_wrmsr_x2apic() has
>>
>>      case APIC_CMCI:
> 
> it will end up calling vlapic_reg_write() which doesn't have case statement for
> APIC_CMCI - write ignored.

Which again is what I had described.

>>>> guest_{rd,wr}msr_x2apic() handle it, but vlapic_reg_write() doesn't. I.e. on
>>>> AMD we would fail to deliver #GP when the guest accesses it, while on Intel
>>>> we would lose the value written. And we also don't set its mask bit in
>>>> vlapic_do_init(). I guess I need to make a patch ...
>>>
>>> Is'n it depends on CMCI capability exposing to guest?
>>
>> Yes, that's part of what I was (effectively) saying.
>>
>>> (have no idea what's CMCI :)
>>
>> Corrected Machine Check Interrupt.
> 
> Looking at:
> 
>   #define VLAPIC_VERSION                  0x00050014
> 
> which means "Max LVT Entries" = 6 (5+1)
> 
> Looking at linux kernel apic.c:
> #ifdef CONFIG_X86_MCE_INTEL
> 	if (maxlvt >= 6) {
> 		v = apic_read(APIC_LVTCMCI);
> 		if (!(v & APIC_LVT_MASKED))
> 			apic_write(APIC_LVTCMCI, v | APIC_LVT_MASKED);
> 	}
> #endif
> 
> Which means Xen never really emulated APIC_CMCI, so wouldn't it be correct to just drop APIC_CMCI?

>From the SDM it's not quite clear to me whether using the LVT count is the
correct / only way to determine whether there's a CMCI LVT entry. To me
it reads more like the MCG_CAP bit is what is the basis. Perhaps based on
that we should conditionally set the LVT count to 6 (AMD) or 7 (Intel).

> Also, taking into account that it's Intel specific.

Another part of what I said I think needs correcting.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 12:03:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 12:03:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131533.1470587 (Exim 4.92)
	(envelope-from )
	id 1v27Ae-0003m0-Q8; Fri, 26 Sep 2025 12:03:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131533.1470587; Fri, 26 Sep 2025 12:03: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 1v27Ae-0003lt-NS; Fri, 26 Sep 2025 12:03:28 +0000
Received: by outflank-mailman (input) for mailman id 1131533;
 Fri, 26 Sep 2025 12:03: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 1v27Ac-0003ld-PE
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 12:03:26 +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 cdc3ec4f-9ad0-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 14:03:24 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-b2e168f0a75so362379166b.0
 for ; Fri, 26 Sep 2025 05:03:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353efa4940sm352496766b.29.2025.09.26.05.03.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 05:03: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: cdc3ec4f-9ad0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1758888204; x=1759493004; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ma1Hov2ctd8oI8wauKK5aOmCv+fPLEpAOmzRhdlE/1M=;
        b=O3+hq34SvIx4AzmcDj0NFfbvkt6hlBCr7X7SmTPHhhrxT7SxEQA9tnsiHMg4Hce2a1
         Ux2M2oTWI5WFHP1Pqxj5rLpX4Hp8ZuvctaL/sVeHQ83CaccTPDlU0aJbbw2ZTLcpWg84
         87EuOJhlyWki1W+EdkfYM0TbwnOTooDLLqxtpAc48+FBoM3yLJDE84cowW6Q1yx1WMx0
         hBVaer9HPjPD/8kK1RAlV361AgnWoFLpT2ef3qJKBzmE3gGOCe6OQLkvLVBVQn/KuuDK
         RKmu8IzYmccRG1bCUjAtE2ESQweXCFa5g9FG+i/cKynDtIbQ7R3r1cZifMdi5m569/FP
         OU7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758888204; x=1759493004;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ma1Hov2ctd8oI8wauKK5aOmCv+fPLEpAOmzRhdlE/1M=;
        b=rC8kS5qptwRfrsYq55W8a78EKzSISmoz9zoVA2NYbzb4RN/5+uQ9acTT2IlAWwRTJh
         8trZc95VWe45F7z59KisQPQLpPAWLLTU0mmH9JX3ScIGuYBbzYQ8q9NETsu888rr/qND
         T6y3+x7fYDVOrLtniSfiYyZBASmWKgOBdZZj7uJmlBh40lQIqz7U/VqRhBrJOCtmprXU
         g5Wk3BYE95o4zPEWVBLDPQQfLQuju3lEDS4f8UcKkz2zVBETLSPCE4mGg0HW9jWoNz4k
         cl4T9Tio0BwD0kUt59FvsQpxYR13rTfdm20gPxSVFSjZaeoQhzYUx2jaVKVDuuYMK1qf
         heRg==
X-Gm-Message-State: AOJu0Yzex31YjrtAaboQkuWC2OGvSRf4ILeYa41T1NDWVhbPGIYk0ttC
	J09ynASqARy6zdxV6nhnfO0lbiR8iAo3EJkwOI2qcJR9BZE/uSbtFyi2mo7GakynEA==
X-Gm-Gg: ASbGncsxq+wrf8o5qgVWcs9KfRMMB1wsOlkrt1TXNLfpU6uhTDC+hhELVtnwWizt5+T
	MF/9Nsjwh/JWWZPf62JJNe5R3rdZVZ4Qw4JtEBSfEDGnsxskjyLEk32s+Q6P4rOVSCKkVIsRkhY
	erDD6UQ+8aDqg7PgCDsPBUsAxNlQFehcUVuDnH2obJFaZ0nr0rNtWTN/QW5jI3Kzz6vg/xHy6+k
	mNZ7cND7DH7rxj4McOi+F3EeS54gk1onXyT/XjkZnpDHGDglQB7g+f9bu3NC2rtNd0q7ESKJkr/
	Qfwwcm/VdM9cyPoxGMozwaavq57mIBhqtSjp+WnUSm3Xr2r9nJedSqlh68VH5v5xLDBMrUR8lCg
	ih+5FYyS0VyxXonmWbWU5Im7DXm/ofV1+6QSF+xUkY4QwakDA7tx7f5aUjNq1GDDc5UJjR9VK9+
	knOpn8BxGKHW5P9q0poA==
X-Google-Smtp-Source: AGHT+IHl0ml7ZLO9YnSCgS3lGe7dKhTImPhdtrcY7y9ArqexLWHoeGTkxhk9wOtRWomXhs+RbFT0sQ==
X-Received: by 2002:a17:907:7b9e:b0:b04:6546:347e with SMTP id a640c23a62f3a-b34baf43cd6mr732608766b.51.1758888203970;
        Fri, 26 Sep 2025 05:03:23 -0700 (PDT)
Message-ID: <5bf0c59c-071d-47f1-b985-5e098f30c042@suse.com>
Date: Fri, 26 Sep 2025 14:03:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm, xen/common: Add Kconfig option to control
 Dom0 boot
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Anthony PERARD ,
 Bertrand Marquis , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 Xen-devel ,
 Nicola Vetrini ,
 Oleksii Moisieiev 
References: <34e1b5036361745db2fde233e0935a568c0ebc90.1758729618.git.oleksii_moisieiev@epam.com>
 <8fd7c0f5d203aa0f13cd8efe5129b6f3@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 26.09.2025 12:53, Alejandro Vallejo wrote:
> On Wed Sep 24, 2025 at 6:06 PM CEST, Nicola Vetrini wrote:
>> On 2025-09-24 18:00, Oleksii Moisieiev wrote:
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -481,12 +481,18 @@ void asmlinkage __init noreturn 
>>> start_xen(unsigned long fdt_paddr)
>>>      enable_errata_workarounds();
>>>      enable_cpu_features();
>>>
>>> -    /* Create initial domain 0. */
>>> -    if ( !is_dom0less_mode() )
>>> +    if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() )
> 
> This probably wants inlining in is_dom0less_mode() so every use gets to be
> resolved statically.
> 
>>> +    {
>>> +        /* Create initial domain 0. */
>>>          create_dom0();
>>> +    }
>>>      else
>>> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
>>> -
>>> +    {
>>> +        if ( is_dom0less_mode())
>>> +            printk(XENLOG_INFO "Xen dom0less mode detected\n");
>>> +        else
>>> +            panic("Neither dom0 nor dom0less mode was detected, 
> 
> I'd rather have a static check in common code.
> 
> BUILD_BUG_ON(!CONFIG_DOM0_BOOT && !CONFIG_DOM0LESS_BOOT);

I'd recommend against this, not the least because of the randconfig aspect
you mention later. We also allow building (x86) Xen with PV=n and HVM=n,
for example.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 12:29:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 12:29:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131559.1470597 (Exim 4.92)
	(envelope-from )
	id 1v27ZQ-0006qz-OT; Fri, 26 Sep 2025 12:29:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131559.1470597; Fri, 26 Sep 2025 12:29: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 1v27ZQ-0006qs-Lt; Fri, 26 Sep 2025 12:29:04 +0000
Received: by outflank-mailman (input) for mailman id 1131559;
 Fri, 26 Sep 2025 12:29: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 1v27ZP-0006qm-PO
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 12:29:03 +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 5fecfc39-9ad4-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 14:28:58 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS2PR03MB9669.eurprd03.prod.outlook.com (2603:10a6:20b:5ea::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.13; Fri, 26 Sep
 2025 12:28:55 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.008; Fri, 26 Sep 2025
 12:28: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: 5fecfc39-9ad4-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Mz/UgKGvXq6ednsMqSl3YteR5Hp9CurAVaF3TNvLfyFATl4qdyRlw+xXeOxA00DpYDJPqqONV4fjVN3jWz941l2QoglrJm4kfFaggi0nDYtSifHWVDA3St+fwfBfZiKvkqzGppozIK5AGBvoLe0dkJlT0BUOU2Pdl0bZ4xfw2wjw64RwrVCuihtuiHiT3IPtccdvpl1CGIidP4s3Gi9FWWr5QtyiceaxDCSzRPjKLlixd0X+Od28CfsDFHBK6z2bWzzIOJURCYnvw0VJBFLLjFq3ADpIVydN2TY7jrsb/LH/DsaeoZi+l2xHruwTn/W0rb7gOsZhIHoI6ubOqkBcYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wq81Y4dULNBPDroSA5Et3rTPoT0k9AJxKviMCWTCA5I=;
 b=IaDH7lSZtOiMjo4m6ImdHceJgU5GJf7rYXfTosx43h4YVT32omhZ29BzDGYT6gEVn/i825E+7tne/kHyViF0SQvH7O+UaTME69LAOmefaLlctRDDjREugVEbFs07TgEGAl1xlA+qgIvqZeyz9mziGXZkO3umz21HngGqYw+3SVjaf9ZeHI2Pv+1ktGfQGdQXeTDsFaWz0sBw6tRM9XfjveU435gfq2L2n85xKzz7ERlxMaFYSnmPonkM0eKZD3kdW50DGnruLIaaqbWYs29kRN27Bi853u5Mqf5zA2l+8ghiSJX96F1OTJUqV2GgtURaITGxXCj8mP5XtJ9UGh/T8Q==
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=Wq81Y4dULNBPDroSA5Et3rTPoT0k9AJxKviMCWTCA5I=;
 b=hXc3jLNBzdyGsf49nI/Cwa15MYcKYSig2LcIMQ9mwSWpAl+UaqSIUgtq0Oecb95+sYIB1QIti7AdmYhzR9cTncE7dAbfuUx2TVNvW5W0UdtCLBoLHMpK2Me/DQbLLlaNjisLSUGe0MhkY6smUprd1C3csBVMWDrHTJgqF1DlNETIx1AGg6021TQBVJAncug+So7dvEvZr2CXBIIIdPsFuKG6nb85mFqUccKFhbnvOQn36kTdw44ImkQIbdi+EwKIXEIj0TJyjqGki+p8uq3GEMkld8VQIba0eQppDIsJeHhW85vebQ/WcxIpWK6oR6SXkymLD0RxvoHCXcxmELBQ1g==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <1650c978-833e-447f-b14c-ef816673d842@epam.com>
Date: Fri, 26 Sep 2025 15:28:53 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN][PATCH] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
To: Alejandro Vallejo ,
 Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jason Andryuk ,
 "xen-devel@lists.xenproject.org" 
References: <20250925195558.519568-1-grygorii_strashko@epam.com>
 
 
 <67dd3659-916b-4e64-afe2-e13fdc8d31f0@suse.com>
 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0344.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ea::7) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AS2PR03MB9669:EE_
X-MS-Office365-Filtering-Correlation-Id: 4b5d6633-2cc1-4f64-9f97-08ddfcf84274
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?b3FsNS8rbTNqQmEyYXJxT2ZTamgxQWRHVjg3UWFReHk1UVNYRHJCNDVHcWth?=
 =?utf-8?B?RTUzWGhPcDd6MTB0cjFRVlVIemF6Ymp3RkFiVXJNWjdWUFJzYWpCL3E5TW1D?=
 =?utf-8?B?eFdkcm1RcDdrZG4vRnNaa3BCYnp0ZFV1YlZNZzZlNGdwaGxObzhrMlJiWkxh?=
 =?utf-8?B?YUw1Mi9HakZkeldOblF3eXVmaUpHWWViOFo2Y0xxM0w0OWdPckJzVFd4ZVZy?=
 =?utf-8?B?U1dDZ09GaGFsRnMvelVZWUdoczNWMm9CcUhYSytrOG9tZEptaFpjS3BIaHh4?=
 =?utf-8?B?OXkrSTh0N3hTRWxzdmQzeG5RbUpYQkQvSFZFbXdtYkxqS0F3c2xXSWxuQ0ts?=
 =?utf-8?B?eDlQR2QvQ00rdHpaaWFwdVozajVodGlTNGJNd0tuUm1mQklENFRQSnhZd1ZU?=
 =?utf-8?B?QXBheEx0OEZ1SnVYWnZwOVRkQnpzb1VrME1YeXVhUTI4amRKQSs5VlVnMjVq?=
 =?utf-8?B?cEpPVk9YVjdHdWRXOTlFSEhNQlltRkZTQU1ab1lZdEFNQVRRMUhxOVZrRnZY?=
 =?utf-8?B?VzMwUFdXZElqanZlUVlCV2F4QXByb2JtVEpwK2wxOUIyRU9NUm9ybmdrYkhx?=
 =?utf-8?B?Y3labGxab29TVTBtR0V0UkJOdWFWWUI3Wk95Qit3N1kzZXZ6WTVyRVh3N1RC?=
 =?utf-8?B?RDFiWU9vVlZCN1hqVDZpZjI5UFVRRHB2TWY5NS9IdE5jQkNLNTF2Uy85TFBj?=
 =?utf-8?B?aDdUK1dzeWRVdkxUYTBsbEpuK0pWZ1BEL1doK0l5KzlaODlRcHlQdDNyL1dM?=
 =?utf-8?B?OWZzeFFKa1VUQXZxM2dpamQ3d09HL0hmMUJZb2k1YjUvOStNZlUzR0ZPaUlp?=
 =?utf-8?B?VFU3Q3lTSHpra1N5ellXNDdSa2pNa2NUVFdFNmc2c0hwS0EyZVF5aXJRb2pt?=
 =?utf-8?B?RWdlMDFQSC8venVzdWtlVmkwZEFvQ2d2MzB1N0lzRXFkUmpJMU1ISVNWYXNs?=
 =?utf-8?B?cjdVbDRnSzdpeXNOMk9ucHE4NWZmMVZPVXZDR1JJOEIya1RPL3dvbXcySmNx?=
 =?utf-8?B?RjdpL1YwR2Y0M2N2MVhoS1o1MkpraEhYWWZ3OHJyWXU1b2RmUlFnRElKNk9K?=
 =?utf-8?B?TjBtbUNGcVZvQ1JCQlVxSHhOOHlxL3Jjemg5czlaaWVkTFVSMloxN3JlbkVW?=
 =?utf-8?B?Q1pLT1RoU3BtZlZNUzJDTlJxR3g1UWdGSnNROVRnTGlmR2RXRWFsZmJuYitv?=
 =?utf-8?B?VmhGWkMvbFNMRnMyeHZ4MXFDSXovYWpxTXMvMXFLdE8wdUN1aGJYTGFDRjBP?=
 =?utf-8?B?ajduWE8zamdkdmhid056ejlIMnh4SHpTTEh4QWRndEMyallHd2FhbjU3R3pJ?=
 =?utf-8?B?dHJTWEF0NHY3L2VHb0VKM0VMNHJ5SkFrcWVNbTVWeitDYVp2NnI5U2poT043?=
 =?utf-8?B?UlhrK3FQeDVJa2Z5ekJHTzBYcXdxYjBKNm9CWGw5YmFPTDFMQTRSTnppcDVt?=
 =?utf-8?B?Z3JsUm1pZCtMcGthYzh1N05qV3dxcmh1dXJvdnVZaGh0WHFBc2hBT2thNlZn?=
 =?utf-8?B?VVFRY3ZkTkdteWhxYklkaFZFZUR0TzdiUDJKdENKb21ZMHNsaUNmMmJnRTdL?=
 =?utf-8?B?czZ0VEdkK0tXanFkTVdQcDh2bFZCZmV3Z0dXYy92S2xpTWJvMUZrSDFGazFU?=
 =?utf-8?B?V281QkF6OUpCVjA4N3ZUbkoyNFlmZGo2Y2MzZHY5bWRhbmZwQld1QmZjNFRj?=
 =?utf-8?B?R3V5Ui9KVFBUK0RINzNkT1lpNVdSNnJLSDcwSVYwY25JQklZdXFQdlNpNWYx?=
 =?utf-8?B?dEF3NkwwdjYzb2pWSXJWc0JhaGYyTzUwMmxOUVNZeXd0Ynl6TXdwS2tMSmZP?=
 =?utf-8?B?Z2NmMG5NMEQ1cmxHcE5KRmhBSEh4WWF6WjRGU3FtL25OcWE0VkxHcnhxY25T?=
 =?utf-8?B?SmoyZ3ZkSTd1RGVicWh6N2F5YWluQ3VPb1luVlNYYVFoRkE9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ODJOenJpSFpUYkhiSTdUaVNHc0ZmT3dzZTRHTnFtTVBZT3BwdE9MZ2RRVUxK?=
 =?utf-8?B?dEIwZHR6VEV5THlIWER0ZjJGeldtWDc5bmczUmlUQjYxN2lxaFd6Z1JnOENW?=
 =?utf-8?B?bUZML3RJekJjVmwrOWxxLzVlTTQ5eXNEb1RHK2wybkplQnFHT1IrS01Cck0z?=
 =?utf-8?B?OHhMbkluYzVmNVUrRnMvYXZoZy9zWVZhQjkvNGFhaHpQSnFzck1mNFNuZVBh?=
 =?utf-8?B?MVY5SmJqdGZ0cmlvL29EQStGRUxEcGFpRVZwQVdzUDFqVS9MenVlZEJQRTZL?=
 =?utf-8?B?NWZFZmRUd0JzUjhHRll1cCtoUW5HTGxPOEFkM2RsT1ZKMExHZWx3MUFtRlZj?=
 =?utf-8?B?NjUxQ2ZGQm5yT002T3I4M3hMeEdBVTNtWUtyZHBzTjN1ODV5UjU4UzVvZ29G?=
 =?utf-8?B?MThsM0ppYUR2cDB5Si8vSWFwRnZIcFN1THZycVVBV2I0SktRSUlLc2JDb05u?=
 =?utf-8?B?NWRiSDJjMUFnMUtHZkpsWnZoSlB3MVYwOXowaXJIOUcyR0dLZ2M4WEFneFIv?=
 =?utf-8?B?UFNzZEtkV2M5RUlJRHRUN1p0SEllbFQrZ09aeE5JMnpTYWt4dGlhWFV5Rk9O?=
 =?utf-8?B?bGVoTTdOOE1wQ29WT09USFJHVm11Z0ZBdERjU1lxcis2L2t2YzRoNi84Sng5?=
 =?utf-8?B?RjhrcFhRZ2pOVjhINUFXbjZsRXZDeEZ3SDlqcCtwL0xRRHU3eEhTbEI3WVZU?=
 =?utf-8?B?TkVJM0FBbGwyTkw3Zm5XOTBFTWU1elZpdXh6Mk0xOGNPRy9RQ0NJcnRIem1v?=
 =?utf-8?B?a0lHajhTajJ2OFRReVRLd3ZLY042RTZYNTd4SnRyb1RtWE1YS1UwNmZWb2Vl?=
 =?utf-8?B?eHBXa29hM0dvVmx0aFA5a2g5SVBUUWZZOE5VazlmMjhscjRLd1pCVTZrc0xu?=
 =?utf-8?B?aGRxOUVPMlZZQ1JLOExPMk5UUDFrUm11YnE4ejh5ZysvR05ES0duR05NNm5a?=
 =?utf-8?B?UTgxaDZwMTJtK1F0OGNQa0QvcEM5T3Y0T3ZUUTNGeTdPb3ZzVmNwZnlNNzRF?=
 =?utf-8?B?c1IzM0hEYnI4S3A3ci8wdVArUE92R2lleTM1SEJsSXplanpHQXY0bmdyQjkv?=
 =?utf-8?B?cUFGbzlKT2xLaGJUVFhMSXUyellkTDEwSGtkS012bWpiYVFTMzBmNnhzVE9Q?=
 =?utf-8?B?YlYwNkNKQjdKcFZ0QTZmeUVwRVpLdkRJRm8vMjl3V2dicjNPckRlcFJtTnFC?=
 =?utf-8?B?ZERhOGhrcllsYXU3TER4ckwxNU1uODZiWUFTSWY1K28rbGZ2djYrbFBMZ2Q4?=
 =?utf-8?B?dmdicGo0QVR5U0ZMZDU0czNtNUdpSGRkNlY4WXFwMUM3cnNOWnE0MU5hRzM3?=
 =?utf-8?B?MjVrbDVlTFlWeVFZOCswZW9CNVJLdFpHT2orS1huQlF2TzgwdkNWTGZYNWZM?=
 =?utf-8?B?QWR3YkZ4SG9KbnNTeURyS1UzSVNjZmVBSDBmUUNzdkpTWmQrNFpDRVBKOWFF?=
 =?utf-8?B?RFNpZnRRa3hHMUVialpLeURQMm1QdDJraEpCM1NXSFFIZkljR3dFczBXQjZu?=
 =?utf-8?B?RkdZRmMwTDBza2cvNXBVWnJsNjRnQ01NMTJnbjQyb3FOUUdZazBUM2k5S254?=
 =?utf-8?B?aHlrbU1IUEs2QWRiSXBIcG5TSzdWSG1NMEVLNWJidEFvYXlrczI4cnFBYkVx?=
 =?utf-8?B?Z05NYVZLT0pvYUFXM2Zsam9MTlZQOEZVYy9kZEI4VE1EZ0p1ZnBQbklPaW16?=
 =?utf-8?B?YUhpKytFSVM5WnQvT1Q4b1FNVFpZNjJTM293Z3djU2d3bzU2cU9lOXFqTC8x?=
 =?utf-8?B?Q2FFNVRIQ0p2QytWU2FyRWZSaHFGcUk1UGdscmRMVnptdVg5Q1BWalQyWHZk?=
 =?utf-8?B?ckdqRXkwckVmZFkzYkRHUjUzcHd2Y3ZGd3ZiOHdWNnR1WEhtblh5MytmQjZo?=
 =?utf-8?B?N0I1UU5KaFZMNzYvcjlRclpDUlN4M3Blck0xaHVmZVhHVWJXT2tNb2NFQzI0?=
 =?utf-8?B?bms5YmlYd2lVc2ZTa0FWK2JVMEpDV1Ntako0RWZsWFFoMDBCc0NFeXNVcU5v?=
 =?utf-8?B?UFlKK0NjN1RoNHlhMVRUZzRvd2d1S00xMWxmV20yUGNKYkJ3WGhRTjlYSHJo?=
 =?utf-8?B?eCtxSDVtZHEwOXhPWm9GalFMUXNYWlpnK0c4dktPZjVBVHVDbHg5MHNQQ0lH?=
 =?utf-8?B?R3g4MWt1NEFkYXcySXFNMUx0Ni9PUzVHa3IvSlVrMlNzamFjWXIzNGJoZjhT?=
 =?utf-8?B?T2c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b5d6633-2cc1-4f64-9f97-08ddfcf84274
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2025 12:28:55.5504
 (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: lsWHvq4urHaZcxslSNIa6W0n6nwjpTteFGJbIyvqUIYSmNMCg95JSkMMCHc3jDCj4xWvhhUR3kR6Lzyz8F1v+PhYS9RX6KWiWmyITq0JK8c=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9669



On 26.09.25 14:12, Alejandro Vallejo wrote:
> On Fri Sep 26, 2025 at 12:52 PM CEST, Jan Beulich wrote:
>> On 26.09.2025 12:38, Grygorii Strashko wrote:
>>> On 26.09.25 11:17, Jan Beulich wrote:
>>>> On 25.09.2025 21:55, Grygorii Strashko wrote:
>>>>> From: Grygorii Strashko 
>>>>>
>>>>> The LAPIC LVTx registers have two RO bits:
>>>>> - all: Delivery Status (DS) bit 12
>>>>> - LINT0/LINT1: Remote IRR Flag (RIR) bit 14.
>>>>>     This bit is reserved for other LVTx regs with RAZ/WI access type (MMIO), while
>>>>>     WRMSR (guest_wrmsr_x2apic()) has appropiate checks for reserved bits
>>>>>     (MBZ access type).
>>>>
>>>> Question is what the behavior is for writing the r/o (but not reserved) bits.
>>>> I wasn't able to find any statement in the SDM.
>>>
>>> Me too. Usually RO/WI on most HW.
>>> For example, LAPIC MMIO "Write" will be ignored (WRMSR will trigger exception).
>>
>> My remark was specifically about WRMSR, and what you say here contradicts ...
> 
> Not quite what you're asking, but writing to the X2APIC_ID register does trigger
> #GP(0), so one would hope writing to RO bits triggers an exception too rather
> than being WI when mixed with RW bits in a register.
> 
> Now again, it might not in order to avoid #GP(0) on a race.
> 
> Definitely worth running a silly test with wrmsr_safe() to make sure. I could
> see real hardware going either way.

I see following code in Linux apic.c

	value = apic_read(APIC_LVT0);
	value &= ~(APIC_MODE_MASK | APIC_SEND_PENDING |
		APIC_INPUT_POLARITY | APIC_LVT_REMOTE_IRR |
		APIC_LVT_LEVEL_TRIGGER | APIC_LVT_MASKED);
	value |= APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING;
	value = SET_APIC_DELIVERY_MODE(value, APIC_MODE_EXTINT);
	apic_write(APIC_LVT0, value);

where RO
#define		APIC_LVT_REMOTE_IRR		(1 << 14)
#define		APIC_SEND_PENDING		(1 << 12)

This means writing to RO bits (at least LVT) doesn't expect to trigger exception and
changing that in guest_wrmsr_x2apic() will break existing guests.

Xen has the similar code [2].

[1] https://github.com/torvalds/linux/blob/4ff71af020ae59ae2d83b174646fc2ad9fcd4dc4/arch/x86/kernel/apic/apic.c#L2251
[2] https://github.com/xen-project/xen/blob/382dd0d166cb85139d86ff26fd96af102ae4fef3/xen/arch/x86/apic.c#L244

-- 
Best regards,
-grygorii



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 13:35:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 13:35:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131594.1470607 (Exim 4.92)
	(envelope-from )
	id 1v28b7-0006vf-FC; Fri, 26 Sep 2025 13:34:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131594.1470607; Fri, 26 Sep 2025 13:34: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 1v28b7-0006vY-CN; Fri, 26 Sep 2025 13:34:53 +0000
Received: by outflank-mailman (input) for mailman id 1131594;
 Fri, 26 Sep 2025 13:34: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 1v28b5-0006vS-SH
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 13:34:52 +0000
Received: from BN8PR05CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c110::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90cd5686-9add-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 15:34:46 +0200 (CEST)
Received: from CH0P221CA0004.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11c::14)
 by IA1PR12MB9530.namprd12.prod.outlook.com (2603:10b6:208:593::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.21; Fri, 26 Sep
 2025 13:34:41 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:610:11c:cafe::bf) by CH0P221CA0004.outlook.office365.com
 (2603:10b6:610:11c::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.11 via Frontend Transport; Fri,
 26 Sep 2025 13:34:41 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9137.12 via Frontend Transport; Fri, 26 Sep 2025 13:34:41 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 26 Sep
 2025 06:34:39 -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: 90cd5686-9add-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=grI3qLNzErFJNJbCFtGWZ48dCYtHZhLYVG4UGqeD4KB1FSMxnDhxzvo9Rkfwid480H5HRGGEJHBA/z0PDHt0V9IULcFIi42tThpGPKsmFb9V6V0DBfcisNnLbywXdYmy4ku5Zm0YTDG1AyXLXrxxq2pj+UPdgei4ZlW+KqzKEjKpinlwFTnv6C0yxAbfc/v7yr6dMu6RaKaKbEo/IouyaS5vLMrLOi9Sec7NC060e8sTeHGBDXoBUeqftobmDCLtrrgspZ+44Q+Sx6xlp81yZQL4y868U+A59deOziPRLPOS4Cg1Ui1AsOSYDlFNGeYl6uPjL2xUubc6A3rWfvAEpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=C9R1bsZg9zFi5SZMiIHOuy0km5G04Yq6pWuw7XLIbIo=;
 b=wQIek832Es7bXtmq0e5dADk3be8BQuM/9O25kMzcaA/7qf1IqpuNoCIAifziW5ZQV2BIpCMp9o3atqTerysp2q0JHz9p1I4SbQgTzauclBKtjMWltFHanW2z4Qcrx27k4ujikvAfg19kYnXyRv0LP80K3czFrnjwidoTr8WxfwAMh/I3+NIZfCn17JLUG9k2eUV/2oZ6Xby5kOqozQcWYIgLJPOw+TFv0cNbydOkx4FKTSQS+wWi0Zij16Cwk4oyilzPKi2Ni4HQZ/5w5ZflJFxNjmUgabbNb3qya2BQFm1pXlE4yDQPQMegrH3psc6zYHTBjeAnvw4WCAg33mn1mg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=C9R1bsZg9zFi5SZMiIHOuy0km5G04Yq6pWuw7XLIbIo=;
 b=HuNYAJYeLbZ9S+N4CE9wcrRCvYaH3OjnoCp7vm1z56S6B8UPIvCVqKUgCbL/B7VRuVatbc6jxGAD4zRFmtOr/chCBg93j7AlpuVR2huPgzd/GsVbomNTtSbzgv0iEVqgbNRWltV0kCPP91/anbAImZvuN1VgAw8ueBgYQpHzOcc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 26 Sep 2025 15:34:38 +0200
Message-ID: 
Subject: Re: [XEN][PATCH v3] x86: make Viridian support optional
From: Alejandro Vallejo 
To: Grygorii Strashko , Jan Beulich
	
CC: Sergiy Kibrik , Andrew Cooper
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Paul Durrant ,
	"xen-devel@lists.xenproject.org" 
X-Mailer: aerc 0.20.1
References: <20250916134114.2214104-1-grygorii_strashko@epam.com>
 
 
 <323babfe-2fe4-45ef-b3f7-fe15739c87da@epam.com>
In-Reply-To: <323babfe-2fe4-45ef-b3f7-fe15739c87da@epam.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|IA1PR12MB9530:EE_
X-MS-Office365-Filtering-Correlation-Id: 31bb692b-f35b-442c-a160-08ddfd017264
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?V2hVaHZwK3FBR2NMWG1tc3h3bVBxSitURElNTFlXNk1OTHhFOTI4Nkd4T1h1?=
 =?utf-8?B?MXJqbFI0UllSUG9NSUw3S1ZJNk9LN2FMLzZaSjkydS9GaW41MThhRmFvakl0?=
 =?utf-8?B?ZFUyV2p5WlozRkwwNnE0eFlQejBzRERHZTFjcndoY0hIMnFJMnVzbDdibTBW?=
 =?utf-8?B?SWt6Z3N6TlBEamFteUpaa0xtV2VoZitHVHM5WGg4bXJZV0FmTXJua0xsemcy?=
 =?utf-8?B?N242cjFIYzM5NDg3Y24zdmd3aVU2aWNVS2xyUGRzRUVSazQxVzk2cGNQSkov?=
 =?utf-8?B?NTNxeFU2OUxSb1daNSt5WEM1Q1ZsVEhqVm5YTnJWcjdmSjRONTBvNUc3cERz?=
 =?utf-8?B?bXhNNW9lVlZQYjdEeUtibmlBMFB4OG1ISjl5ZSs4RVNrVG1SWVUzWCswcVlQ?=
 =?utf-8?B?WmRtRDJuZERUa2l5eStKNlJmUFJkWEFkd2F5eWRaU0RzUDNJSDlwTUhTeGdR?=
 =?utf-8?B?dXQ0Wk1Hbmowczc4b2xpV0xMbFZDdUh5dEc4bDg2VGN2L1l1YmhUYi9GQlZs?=
 =?utf-8?B?NmF3ODVJeGoxWmdqUnk2MFlla05Fall4RzJmQ2pqdjRUcGN5UjYyMWYzMmo5?=
 =?utf-8?B?OGdQVGRVenlXK0FQeFpKOXVjT0JBdElmNC8yWjVVM2RUN1JGb2pJUDFvcEo0?=
 =?utf-8?B?ZGc0MktUdlF3WkhNZlorWVJKUWttYW9GT2xOalpFb3gyMjJadW9oOGZ1MG5D?=
 =?utf-8?B?SytvOHkzT040SkszTWJTcHp0b0pMYUdjdmtWRDZkRXVJVkNMejQ3MEc2QTRF?=
 =?utf-8?B?MnVuV0trVitHZDYyOUduWmFteElBR1lPVFBMWUttSzVBa1U4ZEdkTjJDMFFF?=
 =?utf-8?B?Z1lFZldrazBjN2JSNUtPS1g0a2YwZm00a3JxR1FVT1RrZGYyZkFlaFBzQzVv?=
 =?utf-8?B?SndPNVNjVTd5c3FQMU4yZXA2eHl0dHozS29lV0t1VlNvbGxtNy9taGVtT0d5?=
 =?utf-8?B?WExZb2xGR0YyTWk3bEM2ZVU1bWtFSEg5bGhKVSs3TEZUTXNXMkxoc1ZVUEtS?=
 =?utf-8?B?N1o5U2FtUXZhZTY2YjBVYnZranBGalFDdzluMEpKNi92SWxlZ2ZvclRsckdq?=
 =?utf-8?B?cDYxaWhJYnpaQlJYMkFRaVpaNlVycXFXRDYwOVVqWDYrNEFXN0UwR2dGcGxJ?=
 =?utf-8?B?WlZMajRGeHA5dXBKOHBxa1VocnNYamhBTERzNUd3U2s1RjBOamV6L1RoaUVs?=
 =?utf-8?B?ZHFzdm5ydm9FY3Y3bmJoWUdZRnlCUUZTakZMQ1FlM3NTMExrazdpTWszSnNz?=
 =?utf-8?B?cmhReXNJWVhtcjJsMGY0NEFwTVU5TnJjbkpyeWVXT1o0cTZZb0lqNGhRSlVa?=
 =?utf-8?B?VzJENFdlR0J5T3dnNHNhK2o5bFRoUldUeVdXclpFMkszZ3dpWGlGNXA4aCtT?=
 =?utf-8?B?aEVnQ1hTUlpHQlBodkxKakJTYmRVOFgzNk1hNDRuZlgvUGk1OC8vNkFKU2Rh?=
 =?utf-8?B?RDg5My92NWZMODlrVUJjWXlPQ3VIUDU3c0d1TTI2Qkk1alVzMmVMWW9IaCts?=
 =?utf-8?B?RnBiZ2EzMmI4T3Rqdmh3MVpjVkM0dlZzTmN6M1NpZXZiOFJnSS9sMm01bU0v?=
 =?utf-8?B?TjhIeDBRdUxuUnkxa0hpM2RsVjlmcTFXQU9hOTVuRFp1aVAyYUlYYi9VVW01?=
 =?utf-8?B?b0JETjZBb29JMXlSUndaVkIzWnJkL2thdVR5YU9WOWJ6ZDdTZXlya3FwNm5J?=
 =?utf-8?B?b1VMdEdTRVRuL2pkckJSYURNQ1g0bG9ZcU9aVnJDajd0MkRHUGhnUlZIbGJi?=
 =?utf-8?B?cDUyak9iMUthUzdsMVo3Q216Y0hibTZhZ29XY1RuTFQ5L2JIc2dWRmoxV1hE?=
 =?utf-8?B?RVZzWTEzV2ZqUmlzK0c1Y3FDazhma1RPbEU1R1dYalloMUVCdVlhek1JVmNw?=
 =?utf-8?B?ZzNLa3duSXBMZ1RuTUV3REhjOVBrYlNvcE5EZitQMlNpOUpsbkViM2wwTWl6?=
 =?utf-8?B?ZzI5cDV4RjZON1lzZUN5MUdmZGNTQWpuTmZNaWRoU3o0WDVoVjNJTnFQT2ZV?=
 =?utf-8?B?bGd5eVY5QS91VlhiWkNCTVE1dTI0OVNJWmhwSVRyQmI3MHgwU3psczZiakdL?=
 =?utf-8?B?MkR0TWtoMzF2T0JxUjc4ZUxmQ2tBNVVEdmhhL0xWZU5YaUpHaDUvVHRidmdv?=
 =?utf-8?Q?ohtI=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 26 Sep 2025 13:34:41.1916
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 31bb692b-f35b-442c-a160-08ddfd017264
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9530

On Thu Sep 18, 2025 at 7:13 PM CEST, Grygorii Strashko wrote:
>
>
> On 18.09.25 18:19, Jan Beulich wrote:
>> On 18.09.2025 17:15, Grygorii Strashko wrote:
>>> On 16.09.25 16:41, Grygorii Strashko wrote:
>>>> --- a/xen/arch/x86/hvm/Kconfig
>>>> +++ b/xen/arch/x86/hvm/Kconfig
>>>> @@ -62,6 +62,16 @@ config ALTP2M
>>>>   =20
>>>>    	  If unsure, stay with defaults.
>>>>   =20
>>>> +config HVM_VIRIDIAN
>>>> +	bool "Hyper-V enlightenments for guests" if EXPERT
>>>> +	default y
>>>> +	help
>>>> +	  Support optimizations for Hyper-V guests such as faster hypercalls=
,
>>>> +	  efficient timer and interrupt handling, and enhanced paravirtualiz=
ed
>>>> +	  I/O. This is to improve performance and compatibility of Windows V=
Ms.
>>>> +
>>>> +	  If unsure, say Y.
>>>> +
>>>
>>> Actually there is a question for x86 Experts -
>>> Does it make sense to have HVM_VIRIDIAN enabled without enabled AMD_SVM=
/INTEL_VMX Virtualization extensions?
>>=20
>> It makes as much or as little sense as HVM=3Dy with both of the ones you=
 mention
>> turned off. Iirc Andrew in particular wanted to permit such configuratio=
ns, to
>> allow to prove the (abstract) correctness of building them, even if the
>> resulting hypervisor may be of little use.
>
> I've been thinking about adding "depends on AMD_SVM || INTEL_VMX"
> to cleanly note dependency.

If anything, it would be CONFIG_HVM. Pretty sure one can't sanely implement
minimal viridian fully on PV. Certain extensions assume some degree of hard=
ware
emulation.

> It's very hard to understand dependencies within x86 code :(

They are very sparsely documented, you're not wrong.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 15:33:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 15:33:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131646.1470617 (Exim 4.92)
	(envelope-from )
	id 1v2ARs-0003u9-HB; Fri, 26 Sep 2025 15:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131646.1470617; Fri, 26 Sep 2025 15:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2ARs-0003u2-EU; Fri, 26 Sep 2025 15:33:28 +0000
Received: by outflank-mailman (input) for mailman id 1131646;
 Fri, 26 Sep 2025 15:33: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 1v2ARr-0003tw-Ad
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 15:33:27 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24e41a11-9aee-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 17:33:26 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-63053019880so5068153a12.0
 for ; Fri, 26 Sep 2025 08:33:26 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353efa5048sm381030866b.31.2025.09.26.08.33.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 26 Sep 2025 08:33: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: 24e41a11-9aee-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758900805; x=1759505605; 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=3tojoC0BlLxgsvtmg60KCMv9JAEcKYuTATendxucjxc=;
        b=cEDzjgvya3HnKo3iAKGYzTSKZcgPQ6D+YLUEmM4SfybMaukrzw2RkEGxq14KxVfl+e
         toxr2ZAI9C7LMK7xlsqxpZL9Z8z2bSGft7010D7Jo3jVoybJNIy5qarByHvB+kGikziw
         Tb5iGN2dfoavfs1zle8pNmVh/U3V7/OIez95hDzJfWAtvz8EnOmhRnbLh6xtilZIrUSm
         wKfUBcQQhkiHTjx5b6DnajpTM1I3t5RaG8hmq1qjZJXet8/F1Hz3huCfLHCz2zEsLL8z
         nZ/Bcqcx6DZp2T0BQ2zbJmcR5uDxSSF/oCnphaAzpkZZ3I8MZKsJ+lrUt88d2BCoK98O
         KbAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758900805; x=1759505605;
        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=3tojoC0BlLxgsvtmg60KCMv9JAEcKYuTATendxucjxc=;
        b=gBtV76T6DDFWPWiZe5U81fVJHOJPGZMjvxJ/7zGllB/RidOVKHNf/UqxwsTV+t+M1P
         Tz3b2R88h7uhNbr3qvlUHIoUl8UGbn2kfmPHw8N/WwO/MK1hS/hpbUy7xmmrB3OKTQ8C
         22aiYmpCRXiPlntpLEK1WS/cZ847vToIsG9iHkQyoIpmKWyEFOp2OhDr6ZarNjfPlg3G
         12zGtlMsrS7eacMOWTKEL/O0oeufLjZdXvjmJNwx9bfk9ddonVZJhCMZ2uSKAxFPPf9u
         ZFa45SnIO0zAbJrKuee79k8I1qrRr3m9wfvM7qv+Tu0wRl1PHFqtZbmXpEnPxR6BCbVf
         J+wg==
X-Forwarded-Encrypted: i=1; AJvYcCVS/FYrqPHAbnBz3ZIY8nOZZN5CAxkLfLLhQo5y0e3TmVs7n6kRJctgslEqmizSia2JHLNmAwgVz7Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8nIGFP41FJ/cnQMxJ7nxeW8Laodk4HwmIArigCgzjI1nSa8wy
	xYFmMzm92IJSvRNjSoWIeUMyeNN2iCcXbsrwr8C7LY6ogqn2EAJkE8Y+
X-Gm-Gg: ASbGnctxZV3g0Uxcyt3HSpECS5KbLKn8ZE0EL/PWdaIdgvRkXBi4oDVZ+08+rvA8+g7
	mnHqnpSi6mjV5jTjtZU3jEfD3WoyK8VpBsYYildSF87wOc7H02RojXm9ATOyxIMIl9K/mYg0izl
	EPj4czFTOVn1Leil0wAjcsr+IzmgUdMDB4OaOUPaQOjoB/x3WlCm9ba+4gp6y2FCmKbW4tI/4XZ
	8ew8my/haaGX4PuZ65hYEUtZMcRgyVnvtxo6sjmPSunGabJjm5V73XtHbYXq4bOPVxSiu/x14BT
	4wqaIOmslvn4Mcin1I4YAOfJ6pU5AAvsoCiyShjz5RB98BLx6Kq5HAE+wTiOgq52U2zYSd4HdjI
	6qz+/Ye1yshy50S9W+7QWGkxKH3T3Bn6MuELZCE8g2N213J7QHL7gijz7IpLcji41tRCSgrt0OI
	S9ymFxvk0=
X-Google-Smtp-Source: AGHT+IG0vMPlcMYnYnAoorMYQym2YbNe+38Tm8UPaoGgLk5j1z0xSkkyJQaQdx8Rr5Fv1HaCpux3yA==
X-Received: by 2002:a17:907:9713:b0:b2e:4590:e8ba with SMTP id a640c23a62f3a-b34bd440ee1mr966847466b.40.1758900805325;
        Fri, 26 Sep 2025 08:33:25 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------yIgbcwYEQ24rlZbi1PB2dr0J"
Message-ID: 
Date: Fri, 26 Sep 2025 17:33:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/18] xen/riscv: Implement p2m_free_subtree() and
 related helpers
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: 
 <18ed5517721254a56e992d9cd9bc1a64672eda8a.1758145428.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/20/25 1:57 AM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> @@ -342,11 +354,147 @@ static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
>>       return P2M_TABLE_MAP_NONE;
>>   }
>>   
>> +static void p2m_put_foreign_page(struct page_info *pg)
>> +{
>> +    /*
>> +     * It’s safe to call put_page() here because arch_flush_tlb_mask()
>> +     * will be invoked if the page is reallocated before the end of
>> +     * this loop, which will trigger a flush of the guest TLBs.
>> +     */
>> +    put_page(pg);
>> +}
> What is "this loop" referring to in the comment? There's no loop here.

The loop is inside the caller (p2m_put_2m_superpage()):
      ...
      for ( i = 0; i < P2M_PAGETABLE_ENTRIES(1); i++, pg++ )
          p2m_put_foreign_page(pg);

Agree, that comment is pretty confusing. I am not sure it is necessary to
mention a specific loop — the comment would still be correct without
referring to "this loop". So I will rewrite the comment as:

     /*
      * It’s safe to call put_page() here because arch_flush_tlb_mask()
      * will be invoked if the page is reallocated, which will trigger a
      * flush of the guest TLBs.
      */

>
>> +/* Put any references on the page referenced by pte. */
>> +static void p2m_put_page(const pte_t pte, unsigned int level, p2m_type_t p2mt)
>> +{
>> +    mfn_t mfn = pte_get_mfn(pte);
>> +
>> +    ASSERT(pte_is_valid(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.
>> +     */
>> +    switch ( level )
>> +    {
>> +    case 1:
>> +        return p2m_put_2m_superpage(mfn, p2mt);
>> +
>> +    case 0:
>> +        return p2m_put_4k_page(mfn, p2mt);
>> +
>> +    default:
>> +        assert_failed("Unsupported level");
> I don't think assert_failed() is supposed to be used directly. What's
> wrong with using ASSERT_UNREACHABLE() here?

Nothing, I just wanted to have some custom massage. I am okay with
ASSERT_UNREACHABLE(), anyway it will print where ASSERT occurred.

>
>> --- a/xen/arch/riscv/paging.c
>> +++ b/xen/arch/riscv/paging.c
>> @@ -107,6 +107,14 @@ int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages)
>>       return 0;
>>   }
>>   
>> +void paging_free_page(struct domain *d, struct page_info *pg)
>> +{
>> +    spin_lock(&d->arch.paging.lock);
>> +    page_list_add_tail(pg, &d->arch.paging.freelist);
>> +    ACCESS_ONCE(d->arch.paging.total_pages)++;
> More a question to other REST maintainers than to you: Is this kind of
> use of ACCESS_ONCE() okay? By the wording, one might assume a single
> memory access, yet only x86 can actually carry out an increment (or
> alike) of an item in memory in a single insn.

I thought that ACCESS_ONCE() is more about preventing compiler optimizations
than about ensuring atomicity.

In this specific case, I don’t think ACCESS_ONCE() is really needed since
a spin lock is already being used.


~ Oleksii

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



  
    
  
  
    


    

    
On 9/20/25 1:57 AM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
@@ -342,11 +354,147 @@ static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
     return P2M_TABLE_MAP_NONE;
 }
 
+static void p2m_put_foreign_page(struct page_info *pg)
+{
+    /*
+     * It’s safe to call put_page() here because arch_flush_tlb_mask()
+     * will be invoked if the page is reallocated before the end of
+     * this loop, which will trigger a flush of the guest TLBs.
+     */
+    put_page(pg);
+}


      

      
What is "this loop" referring to in the comment? There's no loop here.

    

    
The loop is inside the caller (p2m_put_2m_superpage()):
     ...
     for ( i = 0; i < P2M_PAGETABLE_ENTRIES(1); i++, pg++ )
         p2m_put_foreign_page(pg);

Agree, that comment is pretty confusing. I am not sure it is necessary to
mention a specific loop — the comment would still be correct without
referring to "this loop". So I will rewrite the comment as:

    /*
     * It’s safe to call put_page() here because arch_flush_tlb_mask()
     * will be invoked if the page is reallocated, which will trigger a
     * flush of the guest TLBs.
     */



    

      



      

        
+/* Put any references on the page referenced by pte. */
+static void p2m_put_page(const pte_t pte, unsigned int level, p2m_type_t p2mt)
+{
+    mfn_t mfn = pte_get_mfn(pte);
+
+    ASSERT(pte_is_valid(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.
+     */
+    switch ( level )
+    {
+    case 1:
+        return p2m_put_2m_superpage(mfn, p2mt);
+
+    case 0:
+        return p2m_put_4k_page(mfn, p2mt);
+
+    default:
+        assert_failed("Unsupported level");


      

      
I don't think assert_failed() is supposed to be used directly. What's
wrong with using ASSERT_UNREACHABLE() here?

    

    
Nothing, I just wanted to have some custom massage. I am okay with
ASSERT_UNREACHABLE(), anyway it will print where ASSERT occurred.

    

      



      

        
--- a/xen/arch/riscv/paging.c
+++ b/xen/arch/riscv/paging.c
@@ -107,6 +107,14 @@ int paging_ret_pages_to_domheap(struct domain *d, unsigned int nr_pages)
     return 0;
 }
 
+void paging_free_page(struct domain *d, struct page_info *pg)
+{
+    spin_lock(&d->arch.paging.lock);
+    page_list_add_tail(pg, &d->arch.paging.freelist);
+    ACCESS_ONCE(d->arch.paging.total_pages)++;


      

      
More a question to other REST maintainers than to you: Is this kind of
use of ACCESS_ONCE() okay? By the wording, one might assume a single
memory access, yet only x86 can actually carry out an increment (or
alike) of an item in memory in a single insn.

    

    
I thought that ACCESS_ONCE() is more about preventing compiler optimizations
than about ensuring atomicity.

In this specific case, I don’t think ACCESS_ONCE() is really needed since
a spin lock is already being used.


~ Oleksii


  


--------------yIgbcwYEQ24rlZbi1PB2dr0J--


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 15:48:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 15:48:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131664.1470627 (Exim 4.92)
	(envelope-from )
	id 1v2Afr-0005dJ-Mw; Fri, 26 Sep 2025 15:47:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131664.1470627; Fri, 26 Sep 2025 15:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2Afr-0005dC-KU; Fri, 26 Sep 2025 15:47:55 +0000
Received: by outflank-mailman (input) for mailman id 1131664;
 Fri, 26 Sep 2025 15:47: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 1v2Afq-0005d6-38
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 15:47:54 +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 29a3b857-9af0-11f0-9d14-b5c5bf9af7f9;
 Fri, 26 Sep 2025 17:47:53 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-b3164978f11so436191466b.3
 for ; Fri, 26 Sep 2025 08:47:53 -0700 (PDT)
Received: from fedora (user-109-243-67-38.play-internet.pl. [109.243.67.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3544fcdd89sm392116266b.79.2025.09.26.08.47.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 26 Sep 2025 08:47: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: 29a3b857-9af0-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758901672; x=1759506472; 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=/Rt00F//oeAyBrfAKD78jVuBtJwtye0ynXNfDUvkFiM=;
        b=e/D0gBj8LVUFE15nH6JY04xuaFSqqiCmu9kXPOd9E6XNwz1MIFRwIHx/Mfy0I7Kd2K
         Wr/QKqNVQBA+cNQcw89J3CIBF5hpG++7G+sQ+OrVQ70B81Tjx2MnbMRIahUwQm5l/Ko/
         zi48ymEoK44ruCUSTaVK+2V2pDRghAT03TABCQ7F36bAf/XtF/tRu4+TOoiK9sdYoaaN
         2NlmPurv+eP6g6baG5QoA7Vzoyu/KYAQDNMXKkbJol13/8ux38eZQz/6REMLC4aaz2W1
         M2VAuBqB8TIAHHNbRC6Lol6NTM/CNKMp8H0tw5vSCcCD01UcbjkONHYn4fHaaKoixKmw
         j9GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758901672; x=1759506472;
        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=/Rt00F//oeAyBrfAKD78jVuBtJwtye0ynXNfDUvkFiM=;
        b=w78h+Q7pZvksI9/Y/a/qBA5jRb2BfLK/w9aUJlvVYLIF/2C4qjb6EJXV5pbXXFka/K
         WphYhvrs358P4TdVEGJ1D9KK7qfSLsVE+KGpog6G3yWy8jbmFKfR1OGLTjMNeea0fIG3
         8FNw413B/5vSPGjVM8iMA0McN688S+m5pZSLBiG6XKgYaK7FO0mDdJtqdXPLV1SvcSzf
         opmP4HGg0tmzIqD1ln+izo8woKH7aFyGp1xsUZMXtLS1UuxketMdrXdz4JFhSFil66zj
         IzpkZn6sbfxBjp8+9ux9Uw08gAMkMOTuIpTKE7J3KAAvvR5+MLMgValJmB4HjxKWGwXy
         J3qw==
X-Gm-Message-State: AOJu0Yy8jvW90S0w18jPpSNo2RCoPX9bnvp06skMxtxzYhZYj12CPoQ4
	5+i6K+IZI9p/QCBG6cUCrUkcqzkLy922GO47hd5lJ7485LfMQQPEvJ0dTeORnIqK
X-Gm-Gg: ASbGnctKSBnlqE688kDGH6eIo0HNfy1yzPo/KLhvd18Rex63ApgUddCzT2q7vBChxd0
	uLovIJiA/oyE0rH/kZCigk2K/rndsR5/L56eZ9s4CuEuB3DPaTdycn7rDvSHd5vaw4tjMUyhitL
	DTOnpfoDEvx7A3H5xJEhARVzvCQhC4SD9aH3h08qh2VGaVmCoFNZIHj1egdvTRe3Lm463ley00E
	Hu/akxLJbSqtAoP52OlrwpdShPsll9hWFPDE9ya8vl8BechHU9dvCx6YK//f8Ysqt7Kr4t5Ln5m
	MY2wWb/iyVf27Y2s3bAHTGF/gJttbYqoyMZp2ed1A5Hv8eHJql/T56+TBWSSqc12AI2YTlzIPzI
	6sUi5+vBR6osag4jBsR0PPOe4n4cSUoShBc2ZLXhL9wbxzZGlP2LvFfLVrHsCcZk=
X-Google-Smtp-Source: AGHT+IHVbHHATGYLWa4GCRLvTVmILv2/7MQh2tE1R8BhPwsXXn6f3oEsZDGGDWn58SmI7jmz3rvUzQ==
X-Received: by 2002:a17:907:9628:b0:afe:be04:5ce2 with SMTP id a640c23a62f3a-b34bc67bdc0mr807195766b.64.1758901672243;
        Fri, 26 Sep 2025 08:47:52 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Community Manager ,
	committers@xenproject.org
Subject: [PATCH v2] CHANGELOG.md: Update for 4.21 release cycle
Date: Fri, 26 Sep 2025 17:47:43 +0200
Message-ID: <1930832802df980a6fe610233265bc238fcfaca4.1758901622.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
---
Chnages in v2:
- Drop the following items:
  - Allow to unflatten DTs.
  - Basic kexec support to Mini-OS for running in PVH mode.
---
 CHANGELOG.md | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ca1b43b940..0afd2eeb4b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
    to the baseline change.
  - Linux based device model stubdomains are now fully supported.
+ - Remove libxenctrl usage from xenstored.
 
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
@@ -38,9 +39,17 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      and 28 (Temperature Probe).
 
  - On Arm:
-    - Ability to enable stack protector
+    - Ability to enable stack protector.
     - GICv3.1 eSPI (Extended Shared Peripheral Interrupts) support for Xen
       and guest domains.
+    - SMMU handling for PCIe passthrough.
+    - R-Car Gen4 PCI host controller support.
+    - SCI SCMI SMC single-agent support.
+    - Initial support for MPU, R82, and R52: reaches the early boot stages.
+
+ - On RISC-V:
+    - Basic UART support and external interrupts (APLIC/IMSIC only) handling
+      for hypervisor mode.
 
 ### Removed
  - On x86:
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Sep 26 16:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 16:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131678.1470638 (Exim 4.92)
	(envelope-from )
	id 1v2B2r-0001R3-Eb; Fri, 26 Sep 2025 16:11:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131678.1470638; Fri, 26 Sep 2025 16: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 1v2B2r-0001Qw-Ak; Fri, 26 Sep 2025 16:11:41 +0000
Received: by outflank-mailman (input) for mailman id 1131678;
 Fri, 26 Sep 2025 16: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 1v2B2q-0001Qq-PM
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 16:11:40 +0000
Received: from BN8PR05CU002.outbound.protection.outlook.com
 (mail-eastus2azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c110::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78ff0807-9af3-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 18:11:35 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by CH2PR03MB5304.namprd03.prod.outlook.com (2603:10b6:610:9a::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.13; Fri, 26 Sep
 2025 16:11:32 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9160.010; Fri, 26 Sep 2025
 16:11: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: 78ff0807-9af3-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ubIRKESjaA5RTPjkQzvmOzN9PMu88JMmnLPSq30PXv6oV2mbtDLDty0+lQ2hfJbMexbGC3KfBKU/eYn48NTAvSh0Foq74oeqcPuVIEEYbedA5jYsaOXAzpeWrCkeIs9w+YgxYFRd86DKDTbh3bSPaqnEpCXZNgVpbaB9TxmrkUgyUpiIpg7K7s37S9DM3I4B6uoQYLliEi50DfEU3KtIm09Ap5GlK4UMGMLTW8154XJ+uvlvgS1spa29rwLhfjhonQRhbLzOUF0O9YIKqyawhE0BDKuALyDa26YkDa5HRzBs090/X5AX0yYoSoOJa6M2r6vAixMY+c46mO5Eu3synA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NfY0RCovz+6I+auipczWgf3mr9J0+m54msDYturNMxQ=;
 b=wvg8Z76n2QWwRX+Pg1f+emVY686e8IWdCSRI32Tv5nBeuT4JDeQfdRjR3tSrzNYF7byg3UsO2WrH+no+nyictr78p4Hira6kWngPLCndUnKEBbqVDs3QsyDhaI1W+9PmpaHpTA5x63x4dWRfYoY9ZfFsQNxT5SCAHO0e3Ag95BF2aCdZ1EjIPk02H2CHvMdmHJS9pxPailxd4j/dbzbnwA8mBgaZiqGLych2sz3wMyeStSkLfZpaoQcI56HF25pyS0ru05Bn03L0c1rlbHO+4OKyy6b0uiXcaD9/DLEkK1g67ib27UjeAEcfxMFjh2+/lM1ito66iB/Nhvbzqlmy+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NfY0RCovz+6I+auipczWgf3mr9J0+m54msDYturNMxQ=;
 b=pAJ/rq7VCpbf7LrZYj2pwFCQ8L5YY7fVKetlpwRBu99otzzZMPc1EnRmkgW9uK2jYPDAJz/7CjxGWjMYyIq5jwW4eVZ0g7IzKYlBvMajO/srs/CPPytRMey+i1JlpKkcCj3Bm31CKO78R0FRO1Nnlqt7EB8F3lOsyoDtpo46kDs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Fri, 26 Sep 2025 18:11:28 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH] MAINTAINERS: add myself as vPCI reviewer
Message-ID: 
References: <20250922183537.8861-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250922183537.8861-1-stewart.hildebrand@amd.com>
X-ClientProxiedBy: MA2P292CA0021.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::13)
 To DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|CH2PR03MB5304:EE_
X-MS-Office365-Filtering-Correlation-Id: fedfd8c9-4bc9-4df5-6d96-08ddfd175b62
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?YzlJQm44U3ZyOE13TnJEWlFrMkU2ZnFkbmowMTZHamxpeFRxZHlpWnFjUHRk?=
 =?utf-8?B?NnhWdzZ5aXNrbndHSVYwVVl4ZXM5QnVYL28xZkV4cy9IM3pUcEg0dnkyKzhF?=
 =?utf-8?B?Z1hXcUF5RmI0U2pvT1V6ME1tRkJlTEhSL1c5dVFSQmFvZS83Q2wxL0JBcjlu?=
 =?utf-8?B?Ti80TmdqMWorUXd4UFVBUVdHNytpZzM0enFjbTZ2anpZVlJ6Y0tFS0VjVXBy?=
 =?utf-8?B?dGVYSUNXRUNuY1RHVy8rd0dYV1pURWtoVTVuclQ4R3JtdHpsbjY0RXRjNTJB?=
 =?utf-8?B?dXN2WGl5bmlWM05jYTNWMVZkZEhjcUs4ZEZEZUFYRTFMR2ZYcGxldURVUWdx?=
 =?utf-8?B?eWtNVVI3L0JyRHZBamgyaGZTN3h1V2JXdUZQTG9NRU03c1hpQ3ptM0hNR1Q0?=
 =?utf-8?B?TWNva2NtTlJvQTFwekowK1dURnRucnlGYnh4RGJ2czNzYzZNbElPUUdHekdY?=
 =?utf-8?B?THZGL2JEWGtXemlnSXQ1UHo5MnRRMDFzWlJxQTYzbzI4MHpubUtwZzRaL2Jv?=
 =?utf-8?B?L1dGQUNTN1ZIM3JNaCt2Y0dsdEJGeE9JNVBJcHFiMnUybXJna1IzaEphYWIx?=
 =?utf-8?B?R3dwTGtsT1FYd2Q4NEJFZjBQdDJEWXlXWEtMY1lWdW53NGtjNWZ5WEVEbm9y?=
 =?utf-8?B?OUN2bGpHM1VKRmREWE5HcDBQSUl0QUNnZ2FqY3JQVDdYdW5HcE1FVGlieitu?=
 =?utf-8?B?a0R0ZVZiV0ZtODNDQUM4bStHYUlpMTQ1SnMxcllVUFF2SFRXdU50d1I4VXAv?=
 =?utf-8?B?MGV3QVRsd1VlOG95bFhTM1YrTG9FUHR4T3pKd2N4V0tJd1FiM1IvOXlMN0J2?=
 =?utf-8?B?RnZ4VDQ5dGY3M3Z4bkFxS3dFT0pvVDd1RklJOEZ4QXdLbzBuZkxRMDhMWUFI?=
 =?utf-8?B?MnJ2MmRCY0o4TzNxK0FzbG5GeFFqTndYM3JLMjRWSE45bklWMktsQWtFNG1m?=
 =?utf-8?B?YlIvbitMU0EvZWVkajlVeWlhTlJReHBUNUkxL1MySDFBcEdFb1dMeVdqRks3?=
 =?utf-8?B?Q05hYUdRMVBSTGE4ZVg5UGwyNFk5amR5eFQvQUt1cjluSkpucHp1ZUtscHJ0?=
 =?utf-8?B?TVp3SnViK2JCanpKNmMzalNmdHBrN0JxaysvbHZ2ZnJnRDVlT3JheWRpZUkr?=
 =?utf-8?B?V01pWG0wdWJybUJVdTg5UmZBckMxY2RlZkw0VmhpaWZJWDF5L0FPNVM2aGI2?=
 =?utf-8?B?TGM3OEFUQ1M0S1FhQzZoUFB3Q0xhM0NvMngvSGNxZFNVV2xxRFNTc2xnK09L?=
 =?utf-8?B?dWFwV0tyenhYVWJoMmpYc01VY29MbUlNaUFPeGhCSUZqQmpoaExIb0plOEt1?=
 =?utf-8?B?QTlNR2VFQkhhYWozL3A2Smw3a1NuVGtVMEFOdXk1TE44S09hS1JGOTUySS82?=
 =?utf-8?B?WGFMSjRoem9VdG9FTjh2YXZDeVJqQU03cWErMEtHUG9XL0NVa1JCV1IxTkpx?=
 =?utf-8?B?bmpJV3E1M2orYjcvWGlDZ1ZMSjIxcUZ5UFlkaXRIR040TzFjRlRCbFA3UHo3?=
 =?utf-8?B?WGltbnNYTlNNeWVZbkFGZVBqaDBpN3k5RkZVRWxRd2x0NGtqYTY3dTFjVnRM?=
 =?utf-8?B?OFZvSGUyMlkvd1owSEdYTXlyc0dRSEtBVGVaWXZvSk1LV2NOb2NKWXhFNWdM?=
 =?utf-8?B?TmE1OTFFRjJWQ2M3cnc5L0daNHNYOHZxcUVvNnBaOGhsRmZKajBkVDJObmVi?=
 =?utf-8?B?OXNLN3NZcXluMUJob2hMa2RkS3BWdm1NTFQwWWw1MDZBNVQzZlZUb2crSkk2?=
 =?utf-8?B?TkFkdTVuNGMyR09KeDVkTzV1NVBnZTBrVDE5d0pHZDR5M3lvdVNMUFF3b1Rm?=
 =?utf-8?B?SXJRaWdLUkdQUytQTTY1ck9MSDJ5elhFT0FOREUwVUErVjcvUUdpWHppa3d2?=
 =?utf-8?B?dzFlNFdQTytJS3Y5MHYyb25COTJualFwNk8yYko3VzByZCtuTFRQT2FTS281?=
 =?utf-8?Q?E5hqq296Ti2AjJ0MlI5UEzbgYLiy0r8Q?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NmQ2YzFDWGxxbG1Oa2p2YkIvWkxsR0Jock1ZaTg4a3cycDlPQy9XWFc4dDZ5?=
 =?utf-8?B?M2JSZEVKcXFOQ08xKzl3dndZNmJ1bHFjOUNoRzYvK1dISS9FZmQvUklpaGc1?=
 =?utf-8?B?WThPWk4wMkNVTlFmbzlKRjdEOXRackd1eS9HUEl1QWFFaFQyclFYRGIvL1hL?=
 =?utf-8?B?SytwaWJ3aHh5NWNCVkNNd3BPR1JVdnl5U1FXdktoQzhvT3BqY3ZVcElocXRh?=
 =?utf-8?B?MFBTUFNiak5rMG9kVjNqdkR2YnYvZnpJSTh2d1JCVUNGTENtZFB5Y20rcCtV?=
 =?utf-8?B?MDZNUnBZZEIxeVBjZU4xTVc0Nm82STB4dXVXZm5YTnJMcEd6SU02TTUvQzBk?=
 =?utf-8?B?cHhBY0FCZzk0bCtjK3lEYnREYTJxSEFGU05PalEwMUN3MDRLUllHb0wvZDRB?=
 =?utf-8?B?TTdBcmdHWkdnazhabStETG5KOENVZ0Z4U0VMRkdBZlNmbm9OdU5ic05XZUxa?=
 =?utf-8?B?UURYMkg0Z3N5bWxjMTY3MldGSW9YOFlna0pMYkdvemdDL05zbVdPKzA3dER1?=
 =?utf-8?B?YVJXbmh1K2ZhMEpqejNGcHdDa0tPNjk2S2xQbG11SVRURkdSRkNQanh1VGM4?=
 =?utf-8?B?VDZFZnFwcjhpcHZrWDYwNmxYU2RPVklNV2tUcGxZSUZlbUVyVElERWcrbGVx?=
 =?utf-8?B?K1QrWjRvNEFDV3hmaWVHNTc4LzRqZE9vMDRYR2JlRGdla2dwdWNQNVhySzJ3?=
 =?utf-8?B?Q3JtNUdBcHB6VW9VVld5MWI1QVBSVFY4QVRFVEZCMm95SUlnS3V2WDZpdkRh?=
 =?utf-8?B?cFJnWjNNVlg4NitiM0IzTjYxTHhIcW5ZMkIzbFRSa0luRkdUOFgwZDJmOEZM?=
 =?utf-8?B?VEhHYU5KU2Y0OWtkbEJQVFhDMmh4cGx1QnVmdll2MUlTbmJWNjEyUXU3Zk1Q?=
 =?utf-8?B?SEZuMXVFS0tBNVZ3d1p0Mi9TeE8rZkZSU1E2MDBMUnBwbE10Vm1vbjFiRzJN?=
 =?utf-8?B?N0dsL3BNcWlBUjBZeXIvaVRiZHAyWnQvdHdhUjFqd3lEbHdmMUNvRnhzREV2?=
 =?utf-8?B?alZYNnVqbVFQay96RFpmd2V6RXAzbWJUVFNjOHpZK3htQUFXUjZXcW54KzJa?=
 =?utf-8?B?UU9yUEFhdzRsSWNNWXBxb3BTSTY1NjBqM2oreGxETVFKTmVWTjNHVTlMNTND?=
 =?utf-8?B?cnNLWWhVWW9ST1l6NHBmOU51Sk5rcTdiVFhlRmhQZWZCRTlOeDdVNUxvemhj?=
 =?utf-8?B?ZTFQRHUyWDQxSHQ4L1FqaytnTzYydEM5eTUzQmVSdURncXArb3pqNDdzd0RG?=
 =?utf-8?B?dUZRcmVRS3lqME0vZVkxenk3SnlmTmxzZ2xya21hcGNCZHhoZkdSN0FSZFZu?=
 =?utf-8?B?VldzSGZmSEZHOHRZZzZqWHA1c3d1d3FyZ3JkMTJOZ2FrVHR6VlRGczFuZmd5?=
 =?utf-8?B?MEw0SDRyY1R6MEt6VlJTZGJucTdNUFJyOStqaTIrTGlPTnQzeGhPVFh1VTBa?=
 =?utf-8?B?V0Rnc2F2OTZLQVR5UGJ4NXoxampsM3ZLTlY4OHJXTUJoeEhWU1pjbU9KTFFt?=
 =?utf-8?B?eThxTXpLdXFmNFA2TUNIN2NjNTZCcUNML2pGVFZnb1ZvMU1SNEprczRzWFB2?=
 =?utf-8?B?NDMwV0RFelFWS1VOVDY4emltMGd2VFBZUndOZDNUU1I5S3FkNDBpWUdpVlUr?=
 =?utf-8?B?WTdpOXRvWVhoWm9JVmsxOVk3dnJ6Y2liTWZIeFB1RG9nRjg2K2Yva0pDd0Jw?=
 =?utf-8?B?c2tLQWdiNE5JY3Jvcnp2NW1zeHhOSVZIOHcvdG9KaHZoOEtDNEpMSkZTdFdY?=
 =?utf-8?B?K1Q5Y21WRkpxa0hBNWZYNlJmbWFIZmVnNm1ZcnEycmJJNTR4L1hxWWcyNlFS?=
 =?utf-8?B?MFpDU2dGMk93dzBSbGNPblBUYjFqK1UwVTVabHdyTXJha3JiWEtEeFltSWR3?=
 =?utf-8?B?d01DdnA0SndVYTVYekFtVTFFdHE0dEE0ZHBlampYMEdaa3lvZEZNRVNqREE2?=
 =?utf-8?B?dW43Qlk3MzF6NEpFWHgrYmJaU2dqSDkxRGo4UVByVjhGcjhFUmdEVERkR2Va?=
 =?utf-8?B?eG1TS3lQaXVDY2lra1ZUWitEYnNsVjFEbWx1dXd2OG81aUQ0b2o4RDNWZFZp?=
 =?utf-8?B?emlFYWZHTTd2TG93U3VPVkNOWGRCNzFub3pTbXJTZUYvMkJtczJXaWtDdFFC?=
 =?utf-8?Q?yFWufKGUjxWMmChNPcl4eiaFY?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fedfd8c9-4bc9-4df5-6d96-08ddfd175b62
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2025 16:11:31.7586
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ft0pyj2OOw4lasKKIMRCnstT4NdpEVegcb8IJaZz38RyzBb5OnJWzl+T2vLZfdW/WJRb7PU2Nr54kV+nYSyv7g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5304

On Mon, Sep 22, 2025 at 02:35:35PM -0400, Stewart Hildebrand wrote:
> I'd like to take a more active role in reviewing vPCI bits.
> 
> Signed-off-by: Stewart Hildebrand 

Sorry, I've been having issues with email.

Acked-by: Roger Pau Monné 

Thanks, Roger.

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 31dbba54bb6f..793561f63f83 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -578,6 +578,7 @@ F:	xen/include/*/vm_event.h
>  
>  VPCI
>  M:	Roger Pau Monné 
> +R:	Stewart Hildebrand 
>  S:	Supported
>  F:	tools/tests/vpci/
>  F:	xen/drivers/vpci/
> 
> base-commit: 656b9ca03bd340715aecf405da63c515afb344a1
> -- 
> 2.51.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri Sep 26 19:24:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Sep 2025 19:24:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1131747.1470648 (Exim 4.92)
	(envelope-from )
	id 1v2E3X-0006KT-4Q; Fri, 26 Sep 2025 19:24:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1131747.1470648; Fri, 26 Sep 2025 19:24: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 1v2E3X-0006KM-1k; Fri, 26 Sep 2025 19:24:35 +0000
Received: by outflank-mailman (input) for mailman id 1131747;
 Fri, 26 Sep 2025 19:24: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 1v2E3V-0006KE-PG
 for xen-devel@lists.xenproject.org; Fri, 26 Sep 2025 19:24:33 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a0ebcd0-9b0e-11f0-9809-7dc792cee155;
 Fri, 26 Sep 2025 21:24: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 29C8D40120;
 Fri, 26 Sep 2025 19:24:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21A8DC4CEF4;
 Fri, 26 Sep 2025 19:24: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: 6a0ebcd0-9b0e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1758914665;
	bh=RMQKJaLaOxBwjX2KvOafC1kD90VnlXjebrcQGGvLz3w=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FdHf6jv+0FREut6yJVNe35HJGNEtuAggH/O5ujRDCsaRxAlGAxqlrRejR7HvQ/lzL
	 KP8UWda4k4n/DLAtJdKfWYrW/B0F4wDb+y1EVFjaiyyw+JddX5Do9ixdoBeapEeW5g
	 dbJNV74C/vVRU4Vem5NTw3qmZ/vIMNI8uFLVqLwTAayE9v70aZcfU5wuXRxYTucDCC
	 l0SSXm+hk5oiDe7f4+15clKBW6B2A/yXnaYthDCiLxNz0efq/emGMzX3m+88Wn1/Pa
	 aDBjsEZpFoA4H2ufmyp8gIHSWGTw/b22ahJfy6CTjwju2Ff5ZlK1k3tnpkrQo5r7xw
	 LDi71IaldMWug==
Date: Fri, 26 Sep 2025 12:24:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Penny, Zheng" 
cc: Jan Beulich , "Huang, Ray" , 
    "Daniel P. Smith" , 
    "xen-devel@lists.xenproject.org" , 
    "Stabellini, Stefano" , 
    "Andryuk, Jason" 
Subject: RE: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: 
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-19-Penny.Zheng@amd.com>  
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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, 25 Sep 2025, Penny, Zheng wrote:
> > -----Original Message-----
> > From: Jan Beulich 
> > Sent: Friday, September 26, 2025 2:53 PM
> > To: Penny, Zheng 
> > Cc: Huang, Ray ; Daniel P. Smith
> > ; xen-devel@lists.xenproject.org; Stabellini,
> > Stefano ; Andryuk, Jason
> > 
> > Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> > CONFIG_MGMT_HYPERCALLS
> >
> > On 26.09.2025 06:41, Penny, Zheng wrote:
> > >> -----Original Message-----
> > >> From: Jan Beulich 
> > >> Sent: Thursday, September 25, 2025 10:29 PM
> > >>
> > >> On 25.09.2025 11:41, Penny, Zheng wrote:
> > >>>> -----Original Message-----
> > >>>> From: Jan Beulich 
> > >>>> Sent: Thursday, September 11, 2025 9:30 PM
> > >>>>
> > >>>> On 10.09.2025 09:38, Penny Zheng wrote:
> > >>>>> --- a/xen/include/xsm/xsm.h
> > >>>>> +++ b/xen/include/xsm/xsm.h
> > >>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> > >>>>>      void (*security_domaininfo)(struct domain *d,
> > >>>>>                                  struct xen_domctl_getdomaininfo *info);
> > >>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
> > >>>>> -    int (*getdomaininfo)(struct domain *d);
> > >>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>> +    int (*getdomaininfo)(struct domain *d);
> > >>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
> > >>>>>      int (*sysctl_scheduler_op)(int op);
> > >>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
> > >>>>> -234,7
> > >>>>> +234,11 @@ static inline int xsm_domain_create(
> > >>>>>
> > >>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
> > >>>>> domain
> > >>>>> *d)  {
> > >>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
> > >>>>> +#else
> > >>>>> +    return -EOPNOTSUPP;
> > >>>>> +#endif
> > >>>>>  }
> > >>>>
> > >>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> > >>>> sysctl is hence already broken with the earlier series. Now the
> > >>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> > >>>> really ought to extend to any operations available to other than the core
> > toolstack.
> > >>>> That's the Xenstore ones here, but also the ones used by qemu
> > >>>> (whether run in
> > >> Dom0 or a stubdom).
> > >>>
> > >>> Maybe not only limited to the core toolstack. In
> > >>> dom0less/hyperlaunched
> > >> scenarios, hypercalls are strictly limited. QEMU is also limited to
> > >> pvh machine type and with very restricted functionality(, only acting
> > >> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> > >> Stefano Am I understanding correctly and thoroughly about our scenario here for
> > upstream?
> > >>> Tracking the codes, if Xenstore is created as a stub domain, it
> > >>> requires
> > >> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
> > >> how it was called in QEMU...
> > >>
> > >> It's not "it"; it's different ones. First and foremost I was thinking
> > >> of
> > >>  * XEN_DOMCTL_ioport_mapping
> > >>  * XEN_DOMCTL_memory_mapping
> > >>  * XEN_DOMCTL_bind_pt_irq
> > >>  * XEN_DOMCTL_unbind_pt_irq
> > >> but there may be others (albeit per the dummy xsm_domctl() this is
> > >> the full set). As a general criteria, anything using XSM_DM_PRIV
> > >> checking can in principle be called by qemu.
> > >>
> > >
> > > Understood.
> > > I assume that they are all for device passthrough. We are not accepting device
> > passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> > developed device passthrough through device tree to only accept "static
> > configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> > internal , it may be the only accept way to do device passthrough in
> > dom0less/hyperlaunch-ed scenario.
> >
> > Right, but no matter what your goals, the upstream contributions need to be self-
> > consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> > mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> > them may be an option here.)
> 
> Understood.
> I'll move them all to the dm-ops

Hi Penny, Jan, I advise against this.

I think it is clear that there are open questions on how to deal with
the safety scenarios. I briefly mentioned some of the issues last week
at Xen Summit. One example is the listdomains hypercall that should be
available to the control domain. We cannot resolve all problems with
this patch series. I think we should follow a simpler plan:

1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
   removing all domctls and sysctls

2) make further adjustments, such as making available the listdomains
   hypercall and/or the hypercalls listed by Jan as a second step after
   it

This is because 1) is already a major improvement that might even be
enough in the simpler deployment scenarios.

So I advise against making this series more complex and instead just
focusing on removing all sysctls and domctls the way it is already
doing. This is regardless of the Xen release schedule.

As it happens, my suggestion would also make it more suitable for 4.21.
At the same time, I realize it is coming later than expected so I
understand if Oleksii and Jan prefer to postpone it after the 4.21
release regardless.


From xen-devel-bounces@lists.xenproject.org Sat Sep 27 17:07:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Sep 2025 17:07:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132086.1470658 (Exim 4.92)
	(envelope-from )
	id 1v2YOP-0001EI-KY; Sat, 27 Sep 2025 17:07:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132086.1470658; Sat, 27 Sep 2025 17:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2YOP-0001E9-FL; Sat, 27 Sep 2025 17:07:29 +0000
Received: by outflank-mailman (input) for mailman id 1132086;
 Sat, 27 Sep 2025 17:07:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v2YOO-0001E3-QF
 for xen-devel@lists.xenproject.org; Sat, 27 Sep 2025 17:07:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v2YOO-00D9gi-1I;
 Sat, 27 Sep 2025 17:07:28 +0000
Received: from [2a02:8012:3a1:0:f879:3927:ec77:bf91]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v2YOO-0027JR-1R;
 Sat, 27 Sep 2025 17:07:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Lq4XnbzL28t+N7ZBxundjN4TJSMnMJ3DyZ2JYgVhkz0=; b=j2PQ8o5IZ6O85ifJUqk8DZ35o0
	Y49oRwMYzf6Ko/hSZ/M2afoM5iAP/dPTDV2AdbMuxw0nZ4wT4kR/yDx4m9mt5/ng5iyLCQnAeehxj
	L2ImmylPN7HN50Jk0APocJpbWrVWXdIfTxUbVnf1oq5a+Pf6bhIPI8nq+Vaih+LXb7ZE=;
Message-ID: <88a73261-4c24-465f-93df-6f9770046982@xen.org>
Date: Sat, 27 Sep 2025 18:07:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksii Kurochko 
References: <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
 <6476dc12-1f9f-4b37-b569-e994bde6bcdb@xen.org>
 <4b1cab53-e2dc-4cd4-86b5-1d1be974d089@epam.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <4b1cab53-e2dc-4cd4-86b5-1d1be974d089@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 24/09/2025 09:54, Oleksii Moisieiev wrote:
> Hi Julien,
> 
> On 22/09/2025 20:42, Julien Grall wrote:
>> (+ Release manager)
>>
>> Hi,
>>
>> On 14/09/2025 14:26, Oleksii Moisieiev wrote:
>>> Move the SCI (System Control and Management Interface) resource cleanup
>>> earlier in the domain_relinquish_resources() sequence to ensure proper
>>> cleanup ordering during domain destruction.
>>>
>>> The SCI cleanup is now performed before TEE (Trusted Execution
>>> Environment)
>>> cleanup rather than after P2M mapping cleanup. This reordering
>>> ensures that
>>> SCI resources are properly released before other subsystems that might
>>> depend on them are torn down.
>>>
>>> This change addresses potential resource cleanup dependencies where SCI
>>> resources need to be released before P2M mappings are cleaned up,
>>> preventing
>>> potential issues during domain destruction on ARM platforms with SCI
>>> support.
>>>
>>> Fixes: e2cc10867b (xen/arm: add generic SCI subsystem, 2025-09-04)
>>
>> I am not sure where you found this syntax. This is not the one we use
>> for Xen. It should be:
>>
>> Fixes:  ("")
>>
>> Where the commit-id is 12 characters. For this patch it should be:
>>
>> Fixes: e2cc10867b63 ("xen/arm: add generic SCI subsystem")
>>
> Got this by using command git show -s --pretty=reference 
> Will fix.
>>>
>>> Signed-off-by: Oleksii Moisieiev 
>>> --->
>>> Changes in v2:
>>> - rearrange enum by placing PROG_sci before PROG_tee
>>> - add "Fixes:" tag
>>>
>>>    xen/arch/arm/domain.c | 11 ++++++-----
>>>    1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index 1a8585d02b..e36719bce4 100644
>>> --- a/xen/arch/arm/domain.c
>>> +++ b/xen/arch/arm/domain.c
>>> @@ -1042,6 +1042,7 @@ static int relinquish_memory(struct domain *d,
>>> struct page_list_head *list)
>>>     */
>>>    enum {
>>>        PROG_pci = 1,
>>> +    PROG_sci,
>>
>> Can you confirm this is fine to release the SCI resources *after* we
>> releases the devices? Does this mean they are not linked somehow? For
>> instance, if a device is re-assigned to another VM, could it fail
>> because the associated (?) SCI resources were not yet released?
>>
>> Cheers,
>>
> This is not an issue for a single-agent. This is because single-agent
> doesn't implement relinquish_resources callback.
> For multiagent implementation relinquish_resources is done by sending
> SCMI_BASE_RESET_AGENT_CONFIGURATION message to the firmware which should
> drop all agent configuration previously done.
> If we start another VM with assigned device system will ask device
> permission from the firmware. And if device is assigned to another agent
> - error should be returned.

Thanks for the details. From what you wrote, I suspect we may need to 
move relinquishing SCI resources earlier. But as we don't have 
multi-agent right now, I will commit as-is and we can revisit.

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Sep 27 19:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Sep 2025 19:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132129.1470668 (Exim 4.92)
	(envelope-from )
	id 1v2aT8-0000KC-Qt; Sat, 27 Sep 2025 19:20:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132129.1470668; Sat, 27 Sep 2025 19:20: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 1v2aT8-0000K5-Ns; Sat, 27 Sep 2025 19:20:30 +0000
Received: by outflank-mailman (input) for mailman id 1132129;
 Sat, 27 Sep 2025 19:20: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 1v2aT7-0000Jz-Rw
 for xen-devel@lists.xenproject.org; Sat, 27 Sep 2025 19:20:29 +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 062737d6-9bd7-11f0-9809-7dc792cee155;
 Sat, 27 Sep 2025 21:20:27 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-634cef434beso1579664a12.1
 for ; Sat, 27 Sep 2025 12:20: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: 062737d6-9bd7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759000827; x=1759605627; 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=BpNpqT8E7PV/s4bEDWlZ98/qvJvoxkZccIvsTmWeJBY=;
        b=lP5Np4evc+xa3X8I56npoMQJmd3k2l1VbtJ5oSZ8O9FwBzCzD/l0lwccaKVaW8YGcM
         vvGYukEfO8JflbHB810oVox/tcRCU9RXGxdaYEYvDNs25qr4b5js6pxoeFjrYXAecSIa
         xYFG6sXG6ghn29wCIlGewt6o6EZpKkcr2+YHuVG0S+kX3Q892yOJ9r1fhtqEivTX+ESc
         HJHtCokU7KWb7YdWirxBFzPHCLh4fP/dlvlN4QHHQC0ZGiGPrVBxZfPWFhYpeAPJjnuh
         3nSmkeyyb/duH3A8WGqfA9bY1/gSfSjKeOL45RQ5wHLaSHzT8Zy1/u+GyKc3U05fh4VC
         7pNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759000827; x=1759605627;
        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=BpNpqT8E7PV/s4bEDWlZ98/qvJvoxkZccIvsTmWeJBY=;
        b=jA7266L/MSJ6Nv3zvAvNDcMucNwB/FFV27Jzm7r2CwMi8WhwoPhCqg6+qAddmRXjPX
         f1vdK96dm297oIWWVPn6e2BXVjF2nLVbMF9UQU0reCL6VfuBLil8rBzTk/Sg6KlEoQ6M
         sf+2Y9r3qgHltcDBl++KLeNkMfBuvYsolakehNVm4RQxPAYYZC8y0xclRP2AUOLV+Hns
         yHySp4jT2cSt9eIlCrf7nX9gIgq+Sn2QUs48PWgZHwXMtn6D4LLLZ75Dbzdg99vCuTVh
         MwWLKHhw8CHx9VlWJxVLAGo86FG8KFfCp83k4SnIVuW7MFHbZEorUT9beQXMQeTs2sWo
         uiDA==
X-Forwarded-Encrypted: i=1; AJvYcCWX6aTI14t4K6XwG/e/KWaweWVUuqp417dXbt1a6gQiKtkl97mXMEKU1y2fJ+cZjbQbtR+s5+3HZx4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywro3rzAT8r6mdUHijO5vmtccOVUdaR1SB+rWeuuMDYAk9K8eNZ
	TGFmMmwIa+1lKSjYHzcDu8bhNZM/xkpkibJ6u1vj3oK6P4/PrgsXKC5O3S6R/U6vEif8MsJyoSx
	ZjunHPW4azKNNaJ+Mfmp0VCqWhPqhR6k=
X-Gm-Gg: ASbGncvrDbTa5OtSh3GS4IntUjnLuOtP8SOGZRD7qab5/4MEHsu/B9LzVSyXNT56Zwq
	5dlS0cfNVJRoWaivITZ154fYn7qM0lTZKzTb8fBeaDh8uRIA4PDn/A4dqsOtkO6KqfG8vFKsGaE
	nZaKjagS8p2N9YMZCRTlB3HWQ7eNi6b53/Teotw1ePr8+sik50bBzn2iyvHEWPENzoiEEEDNtIP
	5VPZ+jXwQNcKn+TBJ4=
X-Google-Smtp-Source: AGHT+IE6MMpG/TRiFXxnrxz1Vvo3fuH5ytNgtdVEgpXL0NxXawEVfUDFtb+tMcdRPN344hi95Su67MTI32H6Ub9xTJM=
X-Received: by 2002:a17:907:7b8b:b0:b3c:5f99:dac7 with SMTP id
 a640c23a62f3a-b3c5fa9674amr74488566b.21.1759000826450; Sat, 27 Sep 2025
 12:20:26 -0700 (PDT)
MIME-Version: 1.0
References:  <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal> 
 <20250923235318.GD2617119@nvidia.com> 
In-Reply-To: 
From: Magnus Lindholm 
Date: Sat, 27 Sep 2025 21:20:15 +0200
X-Gm-Features: AS18NWCUkmopfgQP7FxvlAuimXjc1tmQlQb-89CTajXeb-5Nlye2dR2BnBQqzEg
Message-ID: 
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical address
To: Jason Gunthorpe 
Cc: Leon Romanovsky , Marek Szyprowski , 
	Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

> > Suggest testing the same branch with the alpha patch reverted just to
> > rule out any issue in the core code. If it reproduces suggest to
> > bisect Leon's branch.

Hi again, I've booted up the ES40 again with the kernel build from Leons
branch, it boots up but message log is full off messages like
"EXT4-fs error (device sda4): ext4_find_extent:939: inode
#16257327: comm init: pblk 65114257 bad header/extent:
invalid magic"

The filesystem is broken after just booting with the kernel.
This time fsck did not fix it, I needed to re-install gentoo stage3.
So it's for sure reproducible as well as destructive.  It's not possible to
revert all the commits individually, since this will leave the source tree
in a state where the kernel doesn't build. I've started off by reverting
the following commits:

e78a9d72517a88faa6f16dab4d1c6f966ed378ae
(dma-mapping: remove unused map_page callback)

d459e3b80ad1c81bf596d63d2e3347cf8c7bb0d9
(alpha: Convert mapping routine to rely on physical address)

3cd47242d513050d7a81ac6e7020fd3ef5462ad4
(block-dma: properly take MMIO path)

7950995bef32aa7e5f74699c7d0fdac41d2dad14
 (block-dma: migrate to dma_map_phys instead of map_page)


After reverting the above commits, I'm able to build a working kernel,
that is, no filesystem corruption occurs. I'll take a closer look at this
after the weekend.

Regards

Magnus


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 10:24:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 10:24:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132286.1470678 (Exim 4.92)
	(envelope-from )
	id 1v2oZZ-0007gM-7J; Sun, 28 Sep 2025 10:24:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132286.1470678; Sun, 28 Sep 2025 10:24: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 1v2oZZ-0007gE-2C; Sun, 28 Sep 2025 10:24:05 +0000
Received: by outflank-mailman (input) for mailman id 1132286;
 Sun, 28 Sep 2025 10:24:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2oZX-0007g8-7O
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 10:24:03 +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 3feaefe2-9c55-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 12:24:01 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-62fa0653cd1so5307636a12.0
 for ; Sun, 28 Sep 2025 03:24: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: 3feaefe2-9c55-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759055040; x=1759659840; 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=LcChJkbyyCyxxnYoZ0h2dgScTYQu8ypUACGdGHRDEY8=;
        b=Eur+U2IMhr6rW2pPQuoBzUYI92Dz+dSfHk3J5hMs8M+LDOfyfYECgchiQ6snndyPxp
         rZX5dr0i53dlCCsK5U1tcmJj/aLvW26JIkgSOiZsJcUjQD2BMXjavcwXBrZANhwllzB3
         RnGHDgUAQNzekZrtt/GtQy5JBqwEkY6t1bZHqZ/K2KAIBXwCN1caErAYxADjM/utUd1Y
         +uyzVyltnRrx3aVhnqcSz7cxQtiw3jVssA+1y2oeAodaTDjeYOi9M3kXrgVO7V7gW5Cm
         pRKRjp1DIgDMKc6TBJPuEsLP9oZoHsUgFG/PAFVQkeilV30XUYxsn1HQP5yY2VTmykMr
         j4XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759055040; x=1759659840;
        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=LcChJkbyyCyxxnYoZ0h2dgScTYQu8ypUACGdGHRDEY8=;
        b=LzN6rIsEp1nFvEF67ft6D8olcteGPJU9LH7xTpTcP+Zm6dNU7xkLYQQORcqQC1gHeK
         z0H+4FtMl9CEmxa55ApeuUKBsIijVZ+1EBvpheauRhjDPsKy456T1UYzFiTAWpHzHwoa
         8gfHRsL9JBCIxu/Y7lWJDCJDLPMmh4oh6rCqMJWW5I5iOJHWoij71+FAPPB0XrlV2hb2
         Cryo+Qe7WA3kZ/Sro4Q9OlWJYTEhiVtfHc9bHL/wmpq6fdvjDkA27DRCRM/84jnWPhq5
         tVdjEtHeIWoO5xCrQxvBxdI3AWyGxbHVwc/yC2lixZ2wrNDBZY4VSl+MLmOZIMHSl+dE
         WLDw==
X-Forwarded-Encrypted: i=1; AJvYcCVtolhYzfMQI25dR+sghFhM2Iqu/91t0x6IgYjueikiravjkzTgdgS6tsSGABvstGb4bqb1LWOxXak=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9cF063DvVNmVqzCQSLhRJl/qcC0eMsx8iblqUiVF9+mhjnJzA
	LBBoU0KUIqG5g6H0pPme9yoAmiPtk0lGA/7YfDPJLbuEaT0O1oTbdVY6wm2pHcDubq5C2lbrnAP
	tH+vkB2rvAVW0GrcKBVmLqYaoBihz3fQ=
X-Gm-Gg: ASbGncuAyxpr6ZTDAaXtQoDlXtxdsAnaEgK/mNvZvZpi6e/AlcYKA64uqqMqWdqNpDN
	dqR90gzTm5/tOn8skx5mPgh0D6XqKqWQn+H9TyRRIN7kBESR19CkCfMe1vkfPI3/P2MvExIDCTw
	Grrz68aRff4HB6Ps9+kr3y0Af6Te6H5OSTHhmIBtDBrMlbI34NIW+DjzHA1Gv/LPojVBQmpLBpv
	Ux/o/RQ
X-Google-Smtp-Source: AGHT+IGAq0LbOWTh24q9bLB+mXJC5ix6EL+ilnN7HstffL1oa4ImYTxpRTBcFvmhE8oxPjiGws6tJF6LzW8U7U3nO24=
X-Received: by 2002:a05:6402:606:b0:633:8337:da95 with SMTP id
 4fb4d7f45d1cf-6349fa9f661mr8379897a12.38.1759055040002; Sun, 28 Sep 2025
 03:24:00 -0700 (PDT)
MIME-Version: 1.0
References:  <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal> 
 <20250923235318.GD2617119@nvidia.com> 
 
In-Reply-To: 
From: Magnus Lindholm 
Date: Sun, 28 Sep 2025 12:23:48 +0200
X-Gm-Features: AS18NWC4Nb9W4XCpYP_OV5Q9pNZrLenXw3hzv9kO6uALa6_OupoUAOrEskTs214
Message-ID: 
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical address
To: Jason Gunthorpe 
Cc: Leon Romanovsky , Marek Szyprowski , 
	Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

> After reverting the above commits, I'm able to build a working kernel,
> that is, no filesystem corruption occurs. I'll take a closer look at this
> after the weekend.
>

Short update,  It is enough to revert the following commits, in order to
have a working kernel on alpha:

e78a9d72517a88faa6f16dab4d1c6f966ed378ae
(dma-mapping: remove unused map_page callback)

d459e3b80ad1c81bf596d63d2e3347cf8c7bb0d9
(alpha: Convert mapping routine to rely on physical address)


/Magnus


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 10:54:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 10:54:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132302.1470688 (Exim 4.92)
	(envelope-from )
	id 1v2p2x-00036l-Cs; Sun, 28 Sep 2025 10:54:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132302.1470688; Sun, 28 Sep 2025 10:54: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 1v2p2x-00036e-9t; Sun, 28 Sep 2025 10:54:27 +0000
Received: by outflank-mailman (input) for mailman id 1132302;
 Sun, 28 Sep 2025 10:54: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 1v2p2w-00036Y-2e
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 10:54:26 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7bf53825-9c59-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 12:54:20 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 8337662154;
 Sun, 28 Sep 2025 10:54:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88B2DC4CEF7;
 Sun, 28 Sep 2025 10:54: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: 7bf53825-9c59-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759056858;
	bh=P7S8PfmMkN3lCLtx7ABMG78NQs7Q7Zq/Vrda3oeN91k=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Mi76TWNG7HtOxJ1wO470x2VvF26PVkc0OUNi1F1RmLvGmfrX5GsbtT4ztSWcWdTni
	 FwYt6EmiA9itKcukLOannrDDB26moF9wBf8RU6TCGr/7cNnSu/FGTcUkvY+esiPpjV
	 oDLLLJl0fuYyVanNuHzmOc5s+1VKasRLE9HsLmVxXaiXt6vgjBky/N71dJAy5Uepir
	 CU4p5RSWXOVizbnnPH00WVYjvJCU/KyNrn5gikLy+JzpNEoKRAxowD/z3vbxg6zA5c
	 Ln0RqRBJAFveWdcmsx7QgSb7xt9/rHKWmyrxxdJkXonjrmbRxHKqYef4JoF7gHahEg
	 9RAEVJXjqdX3A==
Date: Sun, 28 Sep 2025 13:54:13 +0300
From: Leon Romanovsky 
To: Magnus Lindholm 
Cc: Jason Gunthorpe ,
	Marek Szyprowski ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical
 address
Message-ID: <20250928105413.GE12165@unreal>
References: 
 <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal>
 
 <20250923235318.GD2617119@nvidia.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Sun, Sep 28, 2025 at 12:23:48PM +0200, Magnus Lindholm wrote:
> > After reverting the above commits, I'm able to build a working kernel,
> > that is, no filesystem corruption occurs. I'll take a closer look at this
> > after the weekend.
> >
> 
> Short update,  It is enough to revert the following commits, in order to
> have a working kernel on alpha:
> 
> e78a9d72517a88faa6f16dab4d1c6f966ed378ae
> (dma-mapping: remove unused map_page callback)
> 
> d459e3b80ad1c81bf596d63d2e3347cf8c7bb0d9
> (alpha: Convert mapping routine to rely on physical address)

Thanks for the effort.

Can you please check the following change instead of reverting the patches?

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index b62d9937d1d3a..3e4f631a1f27d 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -229,6 +229,7 @@ pci_map_single_1(struct pci_dev *pdev, phys_addr_t paddr, size_t size,
 {
        struct pci_controller *hose = pdev ? pdev->sysdata : pci_isa_hose;
        dma_addr_t max_dma = pdev ? pdev->dma_mask : ISA_DMA_MASK;
+       unsigned long offset = offset_in_page(paddr);
        struct pci_iommu_arena *arena;
        long npages, dma_ofs, i;
        dma_addr_t ret;
@@ -287,7 +288,7 @@ pci_map_single_1(struct pci_dev *pdev, phys_addr_t paddr, size_t size,
                arena->ptes[i + dma_ofs] = mk_iommu_pte(paddr);

        ret = arena->dma_base + dma_ofs * PAGE_SIZE;
-       ret += offset_in_page(paddr);
+       ret += offset;

        DBGA2("pci_map_single: [%pa,%zx] np %ld -> sg %llx from %ps\n",
              &paddr, size, npages, ret, __builtin_return_address(0));
~


> 
> 
> /Magnus


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 11:27:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 11:27:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132313.1470698 (Exim 4.92)
	(envelope-from )
	id 1v2pYt-0007KT-OR; Sun, 28 Sep 2025 11:27:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132313.1470698; Sun, 28 Sep 2025 11: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 1v2pYt-0007KM-Ls; Sun, 28 Sep 2025 11:27:27 +0000
Received: by outflank-mailman (input) for mailman id 1132313;
 Sun, 28 Sep 2025 11:27: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 1v2pYs-0007KG-Cc
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 11:27:26 +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 1b1f69b9-9c5e-11f0-9d14-b5c5bf9af7f9;
 Sun, 28 Sep 2025 13:27:24 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-62fca216e4aso8115843a12.0
 for ; Sun, 28 Sep 2025 04:27: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: 1b1f69b9-9c5e-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759058844; x=1759663644; 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=XnTsRVx2LKHSGCofdfP8cBisj0hnUGCd3CLwMZjXxX8=;
        b=NDCrItVj7gyijlPKTEbGaoKqtJjvgBct137cM0ZQjQj0R/OwD+n2UEZ0w/BQeyxYp5
         xvGQNrHoG02g8x0CEkVklk+bru1omInImFEC+0wpeE902WkynY91hbNJfIEinrTcz68R
         dr1AmTOst1y/uHH/gfiSwjJcA1Z2RxAY3GHCeKawBnXHP4QUxdO3SbPTXdDQ8FsywyTU
         pzPxovKJZpOAZ4hJvJratlMUhE2Fbhg7avTSn0IncJWYSTX3HcoSWP239WwJ9U2/KvFA
         pq2G3sz6iHTpe04cMgDACqCjLDYi2pUtVFKkHvNlrXBlLz8RsJjLjS4UUGsoN27OuDM4
         5y/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759058844; x=1759663644;
        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=XnTsRVx2LKHSGCofdfP8cBisj0hnUGCd3CLwMZjXxX8=;
        b=h83QUL2paw69ORm4ryF9ZlKybSV+ddewn7/x6z0H/o0YDsKthCKeMcA/0Uc9yv8Wts
         HQDpWBiQnuZw7u0Xl5fj6MeqN0/NjNvNveQKE0VJSQzkEV0crfKUMntHiw1ozB8mY0zP
         pJdd2HJJarQeOv8y9nEUOcpnSuVqpZ5374VCuHzJoeVYAGTlJhkhDZC1LZFnD7d0DZFC
         xLIo5DMIqvjV008LEeXYXZ+U5eFqro02fTuVjpmnK1ycC2lT9dWdWdmDGNmDgxfaIx43
         SeDFo2TENKnmF8EnK0Gj0KiMxsjftMmT7EjeXeqWDw6LlVVCh8laf0NStcAW5Hj/LrAr
         IALw==
X-Forwarded-Encrypted: i=1; AJvYcCXh+KVXwqbIQNVnY/5iuLOn9ENQ1h1C5NN3K+HEaCsnD2W1XlpAxnuSiaDPzR6VHjVCLl7NoOpew2E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7n1BzSZ0yTzkBTMLDvwdMD+MwbbC610HeF7csOQU8Tdy1V+vd
	pc4QEtgHLf2s4fkAZtiG/LBVtQarjcY/SrwGbSPId6gNug9y3OQRVpvEQC9yb4qwBGVys+YMzh5
	E8l6rpWimyvUUZjUGkt+/08xjbBcm7gA=
X-Gm-Gg: ASbGncufG2sn/yc6WLsZulOU1Dsqg8uDRpGw7e7AYY8bRBA030qmI2TXEepZ7nSNsPw
	ESMYvrfyLmOrullZpm26l5a0eFhJ8El1rq5FXcJhNYS+jj8XPJZYPBOicljE8LYZLlEqWkS/kU9
	gj1FVwJiPcfbqg2xtKoRpHDWp1Q1yFnVU3B+LLAAQ0uB+ZoCW8fVzkgm47lEn8VFm7nmlyk4U7A
	MLYGENWd1a9mnpiap8=
X-Google-Smtp-Source: AGHT+IEbmR6jFZWeOZACTqVTuyroT1qollOj9im3bB2gCUN08/YU89k9vFmzDRRbDuqGeOLmGGtFiulh5CESx8Sm0EE=
X-Received: by 2002:a05:6402:44ce:b0:633:ddd4:4e37 with SMTP id
 4fb4d7f45d1cf-634a331587amr9387899a12.13.1759058843815; Sun, 28 Sep 2025
 04:27:23 -0700 (PDT)
MIME-Version: 1.0
References:  <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal> 
 <20250923235318.GD2617119@nvidia.com> 
 
  <20250928105413.GE12165@unreal>
In-Reply-To: <20250928105413.GE12165@unreal>
From: Magnus Lindholm 
Date: Sun, 28 Sep 2025 13:27:12 +0200
X-Gm-Features: AS18NWDQy06zFzFA0Tb4sMvL6G-ftUfrOQ8ZIU-yy9wPAEd2O_xZFFnSMKmSHdI
Message-ID: 
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical address
To: Leon Romanovsky 
Cc: Jason Gunthorpe , Marek Szyprowski , 
	Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"

> Thanks for the effort.
>
> Can you please check the following change instead of reverting the patches?
>

No problem, happy to assist. I think this did the trick! preliminary
testing shows
that this now works on alpha! I guess the offset information in paddr was lost
by doing "paddr &= PAGE_MASK" before retrieving the offset, well spotted!

I'll keep running the system with some load to make sure there is nothing else
we haven't spotted yet, but so far so good. I'll keep you posted.

Will you be putting out a v2 of this patchset with these updates?

Regards

Magnus Lindholm


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 11:58:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 11:58:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132332.1470707 (Exim 4.92)
	(envelope-from )
	id 1v2q3J-0002tn-57; Sun, 28 Sep 2025 11:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132332.1470707; Sun, 28 Sep 2025 11: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 1v2q3J-0002tg-20; Sun, 28 Sep 2025 11:58:53 +0000
Received: by outflank-mailman (input) for mailman id 1132332;
 Sun, 28 Sep 2025 11:58: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 1v2q3I-0002t0-0E
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 11:58:52 +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 7c485856-9c62-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 13:58: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 5115341742;
 Sun, 28 Sep 2025 11:58:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80A70C4CEF0;
 Sun, 28 Sep 2025 11:58: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: 7c485856-9c62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759060724;
	bh=ckjBiIEK8WR9Yy3qbX0tVHWjgl/Q5LNywAArQuLUpqI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=U3I0kHgXcdhzV3J3cNm+QKWfB7QdY/mTy0ouL3HOv+J3sqJIvuS62SQl+z8PL8YWd
	 qfUAdkBs6D1YVhXVJ6bRrI78Xzyj0CsANEvMURlDviJn8dx5FGPrwxmhdVbcvknSpY
	 WdO4NFZz1RZzNrsKib9CkR4lkxgnoFLn75s77V+99fxEfk9i3VsSTBqugUgy80mDqz
	 s7XhyMEqmiXf1xj53ZxtEanbtM7nq83+tdm/Us5QkUfCxJcUjJXNQqj0gYs2gvwuDO
	 7AiJl/EpeN0s5CHrA/1lJBsV9nH+GOe/f6lIQ8rlBPFFhXVhSL5WKAz8toK1YCzvbK
	 VIIytYUCCbdng==
Date: Sun, 28 Sep 2025 14:58:38 +0300
From: Leon Romanovsky 
To: Magnus Lindholm 
Cc: Jason Gunthorpe ,
	Marek Szyprowski ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/9] alpha: Convert mapping routine to rely on physical
 address
Message-ID: <20250928115838.GF12165@unreal>
References: <0c64474985af55b1aa934b857808068a0e609c6e.1758219787.git.leon@kernel.org>
 
 <20250923171819.GM10800@unreal>
 
 <20250923235318.GD2617119@nvidia.com>
 
 
 
 <20250928105413.GE12165@unreal>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Sun, Sep 28, 2025 at 01:27:12PM +0200, Magnus Lindholm wrote:
> > Thanks for the effort.
> >
> > Can you please check the following change instead of reverting the patches?
> >
> 
> No problem, happy to assist. I think this did the trick! preliminary
> testing shows
> that this now works on alpha! I guess the offset information in paddr was lost
> by doing "paddr &= PAGE_MASK" before retrieving the offset, well spotted!
> 
> I'll keep running the system with some load to make sure there is nothing else
> we haven't spotted yet, but so far so good. I'll keep you posted.
> 
> Will you be putting out a v2 of this patchset with these updates?

Yes, will try to send today. 

Thanks again for your help.

> 
> Regards
> 
> Magnus Lindholm


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 13:52:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 13:52:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132355.1470717 (Exim 4.92)
	(envelope-from )
	id 1v2rpT-0000F2-46; Sun, 28 Sep 2025 13:52:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132355.1470717; Sun, 28 Sep 2025 13:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2rpT-0000Ev-1K; Sun, 28 Sep 2025 13:52:43 +0000
Received: by outflank-mailman (input) for mailman id 1132355;
 Sun, 28 Sep 2025 13:52: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 1v2rpR-0000Eo-QH
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 13:52:42 +0000
Received: from GVXPR05CU001.outbound.protection.outlook.com
 (mail-swedencentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c202::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5dcdc932-9c72-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 15:52:26 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS4PR03MB8747.eurprd03.prod.outlook.com (2603:10a6:20b:576::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.15; Sun, 28 Sep
 2025 13:52:22 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9160.014; Sun, 28 Sep 2025
 13:52: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: 5dcdc932-9c72-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EAGXpCFzDHAdMjRl/h6HLNPPbsU89F3lSBWqYPnhOCjdkBCwuopHhRedmn6urR3TdeuZs+PSmyaHKPYCOfJBM3JIUSeaWma3cjWz60Tt+mty2qn+ti0R+LhaVBHL0xaSGrkDfJODD/ttzJq52DiggbNV5QGmEZxRRdEp424F06jfHtRl7bYaJtVjR1gs6yuqFU9gxbL2mi44dEXGjCwa7MP49bEc5rw6QNh7ARzp0E4reNSDPxAVQqQkZjN9qh0BpG6lPqg1oQRIecdnyo9XGLZYUWBki1IeHOGDcPngJ/Vd0lmpdDJpEFs898A4QanP+df6gd2MA4sUXxKbgazdLA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Vm3h0B2lZdw2WnHnSaF7Rb/RZ1Td/i9c7fzDYnGqY9M=;
 b=xVsczoS+JF31G4yb+YSjY6mjfwQO08aQtKCjdHlSRsr/QEqKzAiYDCB5mpq7VFetUrIHLC7Qwb9HRwGnGek63xQpQI2o1ngXOXh3AL2dRDvN8WX31ZqsXivqmHii1KqvelqCMpYcYzIQGLOOlJ51r3JY7n5cp3Cnyl7okyMoI9tUY1JdwvHHQy189aOuwrTJb0Hbw03MOP23bbFxXXZiNXw/oGAYBABzRlNEXfh/bp546VicE2TGvnGnUujTZTQNuTxqzigEhMhywkFktA6aQnRwE2cNTgXb3klsHZPaV0fmBB3os2H0TY39zPoJQA8JUNbgI5Kb4+6H6ddGVUAWBA==
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=Vm3h0B2lZdw2WnHnSaF7Rb/RZ1Td/i9c7fzDYnGqY9M=;
 b=B1VOJj5Q2qMOaFq+DehEM/ZZ4VfcN1WOB4s1IwmZsmK7E3jBqTIzwSdb2Y0QoPmmUjF0Z5SXhLgQa+wX+MAqKCtbp9DGVdKxJoomWJ/ItCQDRytQAUM6l1lCU4FdkjuuC+o1WoSGKTKUfe7GUKXjUj6BoM3qUf7QSaaUJVyj6R7rQg+UQV6Iu+OkQ1uat8NFDrVdOqddIEVNQQ8DvFIHtefsuixbn7KNZuW1FgjSz9+Z32qCQ0GvOA03CtgbhiZwWK3kMyJHa8+9ExFWRw4psVcZIFtlbO1RDlbhgBoTYowfKgUJTh8grHHYpzv4utE3W5UBnceVuofgnSwOBR3Xkg==
From: Oleksii Moisieiev 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Oleksii Kurochko
	
Subject: Re: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Topic: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Thread-Index: AQHcJXs1K3LqZ5+aqE65C1kspBdxM7SfhaoAgAKQ8gCABUDTAIABW6aA
Date: Sun, 28 Sep 2025 13:52:22 +0000
Message-ID: <557392fd-f676-4aa0-9107-ee48243c336e@epam.com>
References:
 <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
 <6476dc12-1f9f-4b37-b569-e994bde6bcdb@xen.org>
 <4b1cab53-e2dc-4cd4-86b5-1d1be974d089@epam.com>
 <88a73261-4c24-465f-93df-6f9770046982@xen.org>
In-Reply-To: <88a73261-4c24-465f-93df-6f9770046982@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_|AS4PR03MB8747:EE_
x-ms-office365-filtering-correlation-id: 65a909dd-7e1e-49d2-2a14-08ddfe963fa7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?bmVGNFhHZnQ1N1lBbDRWVkdPMEU5bVlMbWhUaDRNSXA0eUZPYUFQODdPZDhN?=
 =?utf-8?B?VjlKYmRJNlJTcVBwL2RLaXAyRzZHckxTeVF3OTY4RzVXY1ppN2xQZHRFV01Y?=
 =?utf-8?B?S0hJNGEveVg3cXZlQlROWGhSRWtmTlJITnlpUWpVOUU4Y2Zrc0F3Smx6dGd0?=
 =?utf-8?B?d3hGUmNBQllocnRUTjVJU0FUeXRTd3NtdkVPK2RZYjJCN2FPNnJtM3RoSkVr?=
 =?utf-8?B?RnJvL0I1NkN0NG9HU3NjZHVJa0ZzNEUyTFR6NWNKUVRTRFBWTFpzR0o0VFJh?=
 =?utf-8?B?c2g2OUkxUE15cHptNXV6MWsvZk15MHpCNFFOQ05uUFo3V0NIbUJUUlFWdmc1?=
 =?utf-8?B?djlyQ2ZPcjRGMW1EYVdUTmZWb1k4SGxYTUpDdUpzVm1lcU96YnpLR1h2NXVU?=
 =?utf-8?B?WFBucFJoRzVhVmtlUXlqMTZJbndqbTgwTGN6anZRTzR6cnB0RnZScWxEV01j?=
 =?utf-8?B?RUc4VXJhSzAvQy84TkcvSkd5R2xWMEQ1R3B5K3ZyckV6RzBFQVB1QWtNRkpB?=
 =?utf-8?B?K1E3VlptNm1kNldiS00zNFZ4cysra2V3eFlmcEZON2lvd2FCSlBkc1d0cWpN?=
 =?utf-8?B?aEN1QWN2VEpNc2xTQnJCMDJsT3FNbWdPeGRFdXN0Nmhzd0ZqemRrc3JhdHBr?=
 =?utf-8?B?TVlVNW5XQUVRU2N6R2wyZmxSSXNiS09FL1dOSkJsL2x5MHliRyt0bTFBTDhs?=
 =?utf-8?B?MWs0N3N0UUJKVFZET1l3NUNOcGZ1RWdXZml5TlB1ZklQZDJHSzJVSUxaV2NZ?=
 =?utf-8?B?cm1scHYyZW9nR1ZzTnBMQzJpUUQ2amNHOG4rWmRQSXFJRWY3WG1XRFVqaGEv?=
 =?utf-8?B?QWp5Vm9lZlYzYi9tRUczQTRkUjMyUTJiYUVJSk9XL1ZnT01TZlhsalFmMW5D?=
 =?utf-8?B?cCtSaE1ROXRtSE1XVVc0SVlqb2RFWFJPMWZNd2hFVVoyZG5hVWpiN1g2eFNm?=
 =?utf-8?B?TmV1TU1qT1Z1eGRPY3hrWlpvSjRIUVpCREhNYmM1TnhLcHdnZjFMaHFqbzQ0?=
 =?utf-8?B?alJ3Sk5pb2lpdTF3K3l0aXdRQnRNOWk3cjFTQXRBZldkdGZWYWlLaEErd2lK?=
 =?utf-8?B?ZlMyQmR0d25ZYzJwaEV6MXJjTEI0UEhPV3RCMmtJK1R2WHdQc1ZUbTY4djkv?=
 =?utf-8?B?UWNxWno5dUJoSHd0VzZCUnNjOEY1R2FuT0NTOHdWeEhqR0Y0Mk1seFpXNG1I?=
 =?utf-8?B?bC9QOU5yQkc2d29ZbmtwREthQVVINEFYZmxCVkdzWjl6cFQzR2ZyZ3FPUnN0?=
 =?utf-8?B?Yk1qR0hBaHJvbGVBUkpGOUxKQ2UvYlpoK2QrMjNNdjFYQmpQZHp0K3RqNXo2?=
 =?utf-8?B?aXVjSmhLd0lXSVVsTTRmN0laV2QreGtmenlMTWlIU1pPWk9UZFJ2NDFyK054?=
 =?utf-8?B?RnJxYkNSSVM2bFQ2NER2MjFoaFBVRTJTUDJsTzFmK1kwMVowQytXUUY2MGZD?=
 =?utf-8?B?WUg1NjQ3ZXRJZkZEU0F4bEJIemZQR0gvNGVLZzNKL284VkpMUVZaTjJ0dGJm?=
 =?utf-8?B?TERqaXVWZDRRaUVHNnZsQTFBS3lEZElEajZ6czRhWnZPN1FvZWZTTnJ4eGd4?=
 =?utf-8?B?L0NtNVQzaFQ1MFZHSWFxMzhRU0tlZGVOWllKL1owVUk2SFpBTVNCQytIUUVS?=
 =?utf-8?B?Z2UxSXZTNXI5WVVpK1dCUE5DOWJpazhyQ0NzMkRqdWNEQ0FNbDdUdlhYSWtV?=
 =?utf-8?B?K2dzNVBVa1ZrR3dYSGJCdlRWaDhSSnNLS1lJUElENU5JbWtxM1hTUFllZE5Z?=
 =?utf-8?B?SkhDQnJsNHBmWXlZSGxLTSs2bHloS3NXdnFSdk1pWUJsR3NLVkFFTElYR0pi?=
 =?utf-8?B?NmRCSVlFK0tWOG1uMEJSVmhxK1lQV2Q5UmJMd09zTXRmekFzWTBtc0pLYkRj?=
 =?utf-8?B?WjVxL0poMm9xZWt2emE1QnJUVERpWTU1VjZOOTd5Z2VGYkZBcHg3UFFweXB2?=
 =?utf-8?B?UlI4eVczTjFLU1hvQ0VqWnFybUdYQXRTcysxcS9iNGpad1FhenhHRlYrRGVE?=
 =?utf-8?B?RitEVlBHM1k0TlpsZDd3ZU5TbHhqK0xkOFdDSytKU3JsWTNDYmpHL25yWWJa?=
 =?utf-8?Q?/+misr?=
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)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TjdUbHNaVHFKYmJXVzdITU9HWVBJdWptMytVVFNjTEY5Q1ZvSENHVDNHOEhh?=
 =?utf-8?B?aFdnQ2R0YUgrNXk4ZktIMTkvRlcvMktKNnp3OXlYYjBpMk5OR0IzMERsV3dY?=
 =?utf-8?B?MVlSTnJhM2kvWkRqdU9sMlkwd1Jla2xkVWxmdytWditxOWtVbUdLS0syYnpL?=
 =?utf-8?B?NjQ4TGpaM0NmNmdIbDAxNVNVOElScUlsb2lyMEE3S05PZEhVbU5nazBybjFC?=
 =?utf-8?B?T0RISXowaE9taE1QRExiREk5amNQUitsN1ZGSjVhY3JuTVZNUkxqSW5zUStv?=
 =?utf-8?B?UEZtS2l4enYvMTA2SUFndjJmUktXV2VYcGg2UXRHTHB5UmFyWFlIRXRkNVEy?=
 =?utf-8?B?U2xaMWVCbkRoNmNMZ1NqZDFZV09hQXV2NFVKSEZYd3hvekFaL0VSdGJUUVFu?=
 =?utf-8?B?eVZTUlpUL2pGVEV0eWdxWmduSld1WEVaRWlWelNmbE0vZlpjWDNqeWY5REFl?=
 =?utf-8?B?REhWeHJZeThRRzQvczh0dkFqRk4wTXRSTEl1TmNUT1dIZXl5S1ZjQVd5eGxE?=
 =?utf-8?B?UmFaNGo1RmFRcXBtZG91MHpxc3p2WVg0VGNKTURBSHZVbTNXYU43WW9qRzFH?=
 =?utf-8?B?QW9SYkgrU0lzdjV0MEhmUVBnd1dYV2lLS2VYU01teDNDWmNBZVI0Tm1MeGFu?=
 =?utf-8?B?Tnk2OEk1bUtYNEFRS0FBRUVVTWlhdm5uRkdYb04xbEV0SXloY2tNNGxIK0hD?=
 =?utf-8?B?aUxKZW1jbVRmN1ovNjZ2WFhjSUVzaGRUWEhnSU4rQytuYm5NNFlCbGYrVzVi?=
 =?utf-8?B?Q21tZ3liMi9MMU90YVlEYWwyNDlhc1FLNkRNYndWKzlKUU02UWFrelpwaWVR?=
 =?utf-8?B?UDYzeFI1NEdjUXhkeEpsVitWOTh5T1dPU0FsWXYyc3N1Tm1uQ0ZPM1FLTWNJ?=
 =?utf-8?B?M1JUSU1Db0xiM1dvYkY0WnZrQk04RFBwbnBMbFF0Mk4vWFNMS1U0dHR2MXRp?=
 =?utf-8?B?eUx0RGFGNFdVNkZoKzZFbis3Mnh0SDg2ZlFHQ0w3ZURuWS9xclhrYVpSRThu?=
 =?utf-8?B?QVNUWlI1aUVhb3IrMXdJSEtGdEwyRkNtd0VYd0dmc2lqR0dHYVhaaGtpUWw4?=
 =?utf-8?B?N0tvWXJzZjFvbGZySXcrcDlzRjV3UFlqQTRZcVlrVnJFREpEUHB1RWtpWlFP?=
 =?utf-8?B?NHlvc2ZmQ0U4eFgyQklWUXVDbGZYbEJRZzcwaG94QlRySHg2dUMzMXp6Y1gv?=
 =?utf-8?B?ZDdoUytUZ2E0d09xQ1JCZE00czFkMTJFb3padHNiaDVWVHVsOHdoWlk1ZnFV?=
 =?utf-8?B?OE5kODhDSzJDWXJLdEtSRlFtSDdwZEcyQmtZQ2ZyYTQyc0JhZExNaEFiWGp4?=
 =?utf-8?B?Um9tNFNRMFN0SjBRTTdEb3BOL2J5Y2JIaVpvbHc5TTJ3OE1SRW5ZcE9HdE15?=
 =?utf-8?B?WXl1REs5NnB3ekk1ZnZiUlNRa3V5N1NubUxJenZXaFJRZXNUaFlFb2wwQTk1?=
 =?utf-8?B?U2RoZFlMOWZvNVdaUk11S1I3Wm0xaGtjZlJBaVQ5VCtwNEk2OVBEVTZuQUk2?=
 =?utf-8?B?MElkTmJ4bWN6bktvcERHQmVTNUV6bGhJUW50bm1aVldqVVUvcm1uNjd4VUpQ?=
 =?utf-8?B?MGxyVFNDa2xEZlN4aHAvTkw3ci9zdGwrdUk1MFhkZE5BY1lBNmNhRWYxRDVP?=
 =?utf-8?B?OEdvVWt6Q3dFMWYvMXMxcFpWMk44cnBnWVRhcmh3cFRMVks4cTJKS3pZUHdv?=
 =?utf-8?B?NHZzN1pyZ093S0RVTEYveHRaSUFQOVRaRnI3UEhjRnZNSXRmQTdvNzJtS0Uz?=
 =?utf-8?B?VkUzdVhIQW1CR09kOE5JTDJLMU1iRnRNTFBRc2dHUlVBRFVJa2ZFc1NMU1pE?=
 =?utf-8?B?bmdweERCaG1FUFk5Y1A0NWFNdGRGZmcva05GMDd4ZWV6MzRtSVJVSm5MTkhF?=
 =?utf-8?B?T3FodEthdmJURzlKU2hpQzhjMHZyQ2pPMXFISlVxUU02b3kvVEFrWE91T0Rs?=
 =?utf-8?B?ekkvMGZLQWF4c0FBend5cGU4M29rcURjb2FyTTV6VnpBbm8rUDd5QUMybmtp?=
 =?utf-8?B?aHlmYnRQR1RoVDNhVTBPdHhvSnMzRlczbTlOZ21pU0RWSzE0L2JZTEtISGdj?=
 =?utf-8?B?SHVKbXdJWnRQcFhIV0lodG1QK0lrdVVudWk5SXJZU2xhb0oyZGJheXNvTWNL?=
 =?utf-8?B?WFVkaVB1bGZCQk5taDNTMnlNZlBnZzd4dFhxakQ1eUJ1c09KUmVXQjNjVGlh?=
 =?utf-8?B?NFE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <36EE86371ADE6043A17545F7D9BA2355@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: 65a909dd-7e1e-49d2-2a14-08ddfe963fa7
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2025 13:52:22.2365
 (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: 0ZMIStpruTptt0JrKjKss55R8NmDtCIGPuV0tP2eN2FcSqaK3pZ+tVtOfxlfwOLid/aUWOkzXfQKjIZQp3w3xVthldCTrtoYPB/gXvsOV+4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8747

DQoNCk9uIDI3LzA5LzIwMjUgMjA6MDcsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4NCj4NCj4gT24g
MjQvMDkvMjAyNSAwOTo1NCwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBIaSBKdWxpZW4s
DQo+Pg0KPj4gT24gMjIvMDkvMjAyNSAyMDo0MiwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+ICgr
IFJlbGVhc2UgbWFuYWdlcikNCj4+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4gT24gMTQvMDkvMjAyNSAx
NDoyNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+Pj4+IE1vdmUgdGhlIFNDSSAoU3lzdGVt
IENvbnRyb2wgYW5kIE1hbmFnZW1lbnQgSW50ZXJmYWNlKSByZXNvdXJjZSANCj4+Pj4gY2xlYW51
cA0KPj4+PiBlYXJsaWVyIGluIHRoZSBkb21haW5fcmVsaW5xdWlzaF9yZXNvdXJjZXMoKSBzZXF1
ZW5jZSB0byBlbnN1cmUgcHJvcGVyDQo+Pj4+IGNsZWFudXAgb3JkZXJpbmcgZHVyaW5nIGRvbWFp
biBkZXN0cnVjdGlvbi4NCj4+Pj4NCj4+Pj4gVGhlIFNDSSBjbGVhbnVwIGlzIG5vdyBwZXJmb3Jt
ZWQgYmVmb3JlIFRFRSAoVHJ1c3RlZCBFeGVjdXRpb24NCj4+Pj4gRW52aXJvbm1lbnQpDQo+Pj4+
IGNsZWFudXAgcmF0aGVyIHRoYW4gYWZ0ZXIgUDJNIG1hcHBpbmcgY2xlYW51cC4gVGhpcyByZW9y
ZGVyaW5nDQo+Pj4+IGVuc3VyZXMgdGhhdA0KPj4+PiBTQ0kgcmVzb3VyY2VzIGFyZSBwcm9wZXJs
eSByZWxlYXNlZCBiZWZvcmUgb3RoZXIgc3Vic3lzdGVtcyB0aGF0IG1pZ2h0DQo+Pj4+IGRlcGVu
ZCBvbiB0aGVtIGFyZSB0b3JuIGRvd24uDQo+Pj4+DQo+Pj4+IFRoaXMgY2hhbmdlIGFkZHJlc3Nl
cyBwb3RlbnRpYWwgcmVzb3VyY2UgY2xlYW51cCBkZXBlbmRlbmNpZXMgd2hlcmUgDQo+Pj4+IFND
SQ0KPj4+PiByZXNvdXJjZXMgbmVlZCB0byBiZSByZWxlYXNlZCBiZWZvcmUgUDJNIG1hcHBpbmdz
IGFyZSBjbGVhbmVkIHVwLA0KPj4+PiBwcmV2ZW50aW5nDQo+Pj4+IHBvdGVudGlhbCBpc3N1ZXMg
ZHVyaW5nIGRvbWFpbiBkZXN0cnVjdGlvbiBvbiBBUk0gcGxhdGZvcm1zIHdpdGggU0NJDQo+Pj4+
IHN1cHBvcnQuDQo+Pj4+DQo+Pj4+IEZpeGVzOiBlMmNjMTA4NjdiICh4ZW4vYXJtOiBhZGQgZ2Vu
ZXJpYyBTQ0kgc3Vic3lzdGVtLCAyMDI1LTA5LTA0KQ0KPj4+DQo+Pj4gSSBhbSBub3Qgc3VyZSB3
aGVyZSB5b3UgZm91bmQgdGhpcyBzeW50YXguIFRoaXMgaXMgbm90IHRoZSBvbmUgd2UgdXNlDQo+
Pj4gZm9yIFhlbi4gSXQgc2hvdWxkIGJlOg0KPj4+DQo+Pj4gRml4ZXM6IDxjb21taXQtaWQ+ICgi
PHBhdGNoLXN1YmplY3Q+IikNCj4+Pg0KPj4+IFdoZXJlIHRoZSBjb21taXQtaWQgaXMgMTIgY2hh
cmFjdGVycy4gRm9yIHRoaXMgcGF0Y2ggaXQgc2hvdWxkIGJlOg0KPj4+DQo+Pj4gRml4ZXM6IGUy
Y2MxMDg2N2I2MyAoInhlbi9hcm06IGFkZCBnZW5lcmljIFNDSSBzdWJzeXN0ZW0iKQ0KPj4+DQo+
PiBHb3QgdGhpcyBieSB1c2luZyBjb21tYW5kIGdpdCBzaG93IC1zIC0tcHJldHR5PXJlZmVyZW5j
ZSA8c2hhPg0KPj4gV2lsbCBmaXguDQo+Pj4+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6IE9sZWtzaWkg
TW9pc2llaWV2IDxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+Pj4gLS0tPg0KPj4+PiBD
aGFuZ2VzIGluIHYyOg0KPj4+PiAtIHJlYXJyYW5nZSBlbnVtIGJ5IHBsYWNpbmcgUFJPR19zY2kg
YmVmb3JlIFBST0dfdGVlDQo+Pj4+IC0gYWRkICJGaXhlczoiIHRhZw0KPj4+Pg0KPj4+PiDCoMKg
IHhlbi9hcmNoL2FybS9kb21haW4uYyB8IDExICsrKysrKy0tLS0tDQo+Pj4+IMKgwqAgMSBmaWxl
IGNoYW5nZWQsIDYgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkNCj4+Pj4NCj4+Pj4gZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW4uYyBiL3hlbi9hcmNoL2FybS9kb21haW4uYw0K
Pj4+PiBpbmRleCAxYTg1ODVkMDJiLi5lMzY3MTliY2U0IDEwMDY0NA0KPj4+PiAtLS0gYS94ZW4v
YXJjaC9hcm0vZG9tYWluLmMNCj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2RvbWFpbi5jDQo+Pj4+
IEBAIC0xMDQyLDYgKzEwNDIsNyBAQCBzdGF0aWMgaW50IHJlbGlucXVpc2hfbWVtb3J5KHN0cnVj
dCBkb21haW4gKmQsDQo+Pj4+IHN0cnVjdCBwYWdlX2xpc3RfaGVhZCAqbGlzdCkNCj4+Pj4gwqDC
oMKgICovDQo+Pj4+IMKgwqAgZW51bSB7DQo+Pj4+IMKgwqDCoMKgwqDCoCBQUk9HX3BjaSA9IDEs
DQo+Pj4+ICvCoMKgwqAgUFJPR19zY2ksDQo+Pj4NCj4+PiBDYW4geW91IGNvbmZpcm0gdGhpcyBp
cyBmaW5lIHRvIHJlbGVhc2UgdGhlIFNDSSByZXNvdXJjZXMgKmFmdGVyKiB3ZQ0KPj4+IHJlbGVh
c2VzIHRoZSBkZXZpY2VzPyBEb2VzIHRoaXMgbWVhbiB0aGV5IGFyZSBub3QgbGlua2VkIHNvbWVo
b3c/IEZvcg0KPj4+IGluc3RhbmNlLCBpZiBhIGRldmljZSBpcyByZS1hc3NpZ25lZCB0byBhbm90
aGVyIFZNLCBjb3VsZCBpdCBmYWlsDQo+Pj4gYmVjYXVzZSB0aGUgYXNzb2NpYXRlZCAoPykgU0NJ
IHJlc291cmNlcyB3ZXJlIG5vdCB5ZXQgcmVsZWFzZWQ/DQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4N
Cj4+IFRoaXMgaXMgbm90IGFuIGlzc3VlIGZvciBhIHNpbmdsZS1hZ2VudC4gVGhpcyBpcyBiZWNh
dXNlIHNpbmdsZS1hZ2VudA0KPj4gZG9lc24ndCBpbXBsZW1lbnQgcmVsaW5xdWlzaF9yZXNvdXJj
ZXMgY2FsbGJhY2suDQo+PiBGb3IgbXVsdGlhZ2VudCBpbXBsZW1lbnRhdGlvbiByZWxpbnF1aXNo
X3Jlc291cmNlcyBpcyBkb25lIGJ5IHNlbmRpbmcNCj4+IFNDTUlfQkFTRV9SRVNFVF9BR0VOVF9D
T05GSUdVUkFUSU9OIG1lc3NhZ2UgdG8gdGhlIGZpcm13YXJlIHdoaWNoIHNob3VsZA0KPj4gZHJv
cCBhbGwgYWdlbnQgY29uZmlndXJhdGlvbiBwcmV2aW91c2x5IGRvbmUuDQo+PiBJZiB3ZSBzdGFy
dCBhbm90aGVyIFZNIHdpdGggYXNzaWduZWQgZGV2aWNlIHN5c3RlbSB3aWxsIGFzayBkZXZpY2UN
Cj4+IHBlcm1pc3Npb24gZnJvbSB0aGUgZmlybXdhcmUuIEFuZCBpZiBkZXZpY2UgaXMgYXNzaWdu
ZWQgdG8gYW5vdGhlciBhZ2VudA0KPj4gLSBlcnJvciBzaG91bGQgYmUgcmV0dXJuZWQuDQo+DQo+
IFRoYW5rcyBmb3IgdGhlIGRldGFpbHMuIEZyb20gd2hhdCB5b3Ugd3JvdGUsIEkgc3VzcGVjdCB3
ZSBtYXkgbmVlZCB0byANCj4gbW92ZSByZWxpbnF1aXNoaW5nIFNDSSByZXNvdXJjZXMgZWFybGll
ci4gQnV0IGFzIHdlIGRvbid0IGhhdmUgDQo+IG11bHRpLWFnZW50IHJpZ2h0IG5vdywgSSB3aWxs
IGNvbW1pdCBhcy1pcyBhbmQgd2UgY2FuIHJldmlzaXQuDQo+DQo+IEFja2VkLWJ5OiBKdWxpZW4g
R3JhbGwgPGpncmFsbEBhbWF6b24uY29tPg0KPg0KVGhhbmtzLiBJJ20gcHJlcGFyaW5nIHBhdGNo
LXNlcmllcyB3aXRoIG11bHRpLWFnZW50IHN1cHBvcnQgYW5kIHdpbGwgc2VlIA0Kd2hlcmUgaXQg
Y291bGQgYmUgbW92ZWQuDQpTaG91bGQgSSBzZW5kIGEgbmV3IHBhdGNoIHdpdGgNCiJGaXhlczog
PGNvbW1pdC1pZD4gKCI8cGF0Y2gtc3ViamVjdD4iKSINCnN5bnRheCBvciBpdCBjYW4gYmUgZml4
ZWQgaW5wbGFjZSBkdXJpbmcgY29tbWl0Pw0KPiBDaGVlcnMsDQo+DQo=


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 14:31:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 14:31:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132371.1470729 (Exim 4.92)
	(envelope-from )
	id 1v2sQh-0005Is-VK; Sun, 28 Sep 2025 14:31:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132371.1470729; Sun, 28 Sep 2025 14:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2sQh-0005Il-QU; Sun, 28 Sep 2025 14:31:11 +0000
Received: by outflank-mailman (input) for mailman id 1132371;
 Sun, 28 Sep 2025 14:31:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2sQg-0005If-7m
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 14:31: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 c205498b-9c77-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 16:31:02 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3ee15b5435bso2071427f8f.0
 for ; Sun, 28 Sep 2025 07:31:02 -0700 (PDT)
Received: from ?IPV6:2003:ca:b74b:a88a:551d:1421:7d53:a1cf?
 (p200300cab74ba88a551d14217d53a1cf.dip0.t-ipconnect.de.
 [2003:ca:b74b:a88a:551d:1421:7d53:a1cf])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc88b0779sm14367637f8f.58.2025.09.28.07.31.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 28 Sep 2025 07:31: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: c205498b-9c77-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1759069861; x=1759674661; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=VYYl4Br8wFeYkCegbu2IFucoAuyBQThZBfj3f4nGCcU=;
        b=XPoEL1RKg4hTIhTqWeOWZJRpRs5qMPAZ1W8axOeA84O8oQicC9z0VWx8c8FmAYPuSe
         yRbkuX6eISSWryoPHXfmaPssPQo7zSM7x3137kVFek3TaFN4SOMUaqOM+0SF0kzOTm5f
         q0R6lgisQEfmtwd4yer5UZh9ZaDlLKbQ8VPnnnbrFCroT79p6Lq0ldcQ6YMyjFSshBPd
         CNf/SDq11LXseqi7q8OqPpK6W4l6KE2b9TZxpDc+uA1BckE8snRUBjscqf43Sx50vfa2
         SI23bEjG7tq2tjHcOXNQx76dA88WCbdFocnAGW3vs6gUP5V6oiu4TJWdLhk1RQVsDel3
         CMTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759069861; x=1759674661;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VYYl4Br8wFeYkCegbu2IFucoAuyBQThZBfj3f4nGCcU=;
        b=PTJnhYCs4ErbDFYeu1qypEN0r6SBbvmDLtCpK6soQZXz3UC4SMtJlc5hs4fnyhGwmu
         qqidbOIIxPLYG3VZXsOnmUwsspHcWNrBvUy2jwtmG6RIvTja3e9gYikkjBhQV6xBLstp
         56jQhE9PMS0gfFHiWk8g8g/ZZTt5kSc2QOx7l9kll+Sdyz4Ni7OUaRC8M2hSKIbR3u3F
         ci3STBEaDcCFXCPu1IwiLpNVYb3U+ehfgSaK/UBS1qvH1/WqwNnpNVnm4SpuRv5Ke8LF
         B+aLQDYDlp9xu6iae+PChsdt6GYduXhl6/L80z7CrLIl9bu2bcVvSQHR3tr+vGHJGdri
         ZFsg==
X-Forwarded-Encrypted: i=1; AJvYcCUOZsgtrIZHttufkDCIFjUtYZ4zUUn/nLhM1lKV5eE5jsNK9CIckXEwUyHu25XKg2rkAoZk6KobjOA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxd7ghN9HAvQ62PVbUArhMr3fwCftnqb5SdlX3W5yScwcjKPojB
	NymVh19NOC0sVDP4LiSp/Y4JzVMnO/ALavxRftcB7bXFuZqVsfQRrgFTpgdEZwx3WQ==
X-Gm-Gg: ASbGnctP7yUlIVkV6BdqBvKOJOzOa85u19H+ElcDRoJeEjNUl7R7VTIMehP1fjDGM2M
	d4kyUkICYJucYAhu/zYvQ1XHEkuft2QKdm4DXMWekpzh0HkPJu9xZqNNc/FsUDPQVMM/+QtCo9c
	AUbqHER2Wddgw+zi+qSwpH8N3Z8ZjPXrZgI+tJJ1zbQLt8otzfPxmUkLwPlDhYGS6tECzzWoPLH
	4oOfPghWmML3uabGx8eH4nEdobZKAemp3NYhLVKhCLiBW4iEr19cnxC3DX+YnWzFmuUfq0vfw17
	J6kR+yadZBMQ70AmZn2DSy5PNB1dRyeiMH6PfpnuIi+bxNlSQAbd4eZYdv2TjMWQ58D+RMQNOC7
	N7yZTlfpdfWW6DDMN5q4HdRPsMZWGtRwKv7ImDjdHqrUjG0rS8h7fCU7ZybXgag3WNw+2HnS47a
	kimUZh/o+xN30/f321qX7nXmavloKmkoyNHwiTS8KDm8v14/G1Axy63aN95Pi1DLPzEYn14E0gq
	jXOBw==
X-Google-Smtp-Source: AGHT+IHg+kzMpMih8hreeb+1rUOQsoqBLbuH/1Ja1pY/EyluJ1OAu0sRDtb18qRWd6lMtiRd2vkAHg==
X-Received: by 2002:a05:6000:2486:b0:3ea:6680:8f97 with SMTP id ffacd0b85a97d-40e42502e25mr12143207f8f.2.1759069861360;
        Sun, 28 Sep 2025 07:31:01 -0700 (PDT)
Message-ID: <97f1d786-b87b-4df0-b514-e40522656a94@suse.com>
Date: Sun, 28 Sep 2025 16:30:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/18] xen/riscv: Implement p2m_free_subtree() and
 related helpers
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: 
 <18ed5517721254a56e992d9cd9bc1a64672eda8a.1758145428.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: 8bit

On 26.09.2025 17:33, Oleksii Kurochko wrote:
> On 9/20/25 1:57 AM, Jan Beulich wrote:
>> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>>> +/* Put any references on the page referenced by pte. */
>>> +static void p2m_put_page(const pte_t pte, unsigned int level, p2m_type_t p2mt)
>>> +{
>>> +    mfn_t mfn = pte_get_mfn(pte);
>>> +
>>> +    ASSERT(pte_is_valid(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.
>>> +     */
>>> +    switch ( level )
>>> +    {
>>> +    case 1:
>>> +        return p2m_put_2m_superpage(mfn, p2mt);
>>> +
>>> +    case 0:
>>> +        return p2m_put_4k_page(mfn, p2mt);
>>> +
>>> +    default:
>>> +        assert_failed("Unsupported level");
>> I don't think assert_failed() is supposed to be used directly. What's
>> wrong with using ASSERT_UNREACHABLE() here?
> 
> Nothing, I just wanted to have some custom massage. I am okay with
> ASSERT_UNREACHABLE(), anyway it will print where ASSERT occurred.

Just fyi, the (kind of) "canonical" way of having a custom message emitted
from an assertion is ASSERT(!"").

Jan


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 14:38:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 14:38:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132382.1470738 (Exim 4.92)
	(envelope-from )
	id 1v2sXo-0005xD-Ju; Sun, 28 Sep 2025 14:38:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132382.1470738; Sun, 28 Sep 2025 14:38: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 1v2sXo-0005x6-H6; Sun, 28 Sep 2025 14:38:32 +0000
Received: by outflank-mailman (input) for mailman id 1132382;
 Sun, 28 Sep 2025 14:38: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 1v2sXn-0005x0-AR
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 14:38:31 +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 cd352e9b-9c78-11f0-9d14-b5c5bf9af7f9;
 Sun, 28 Sep 2025 16:38:30 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3ee15b5435bso2072867f8f.0
 for ; Sun, 28 Sep 2025 07:38:30 -0700 (PDT)
Received: from ?IPV6:2003:ca:b74b:a88a:551d:1421:7d53:a1cf?
 (p200300cab74ba88a551d14217d53a1cf.dip0.t-ipconnect.de.
 [2003:ca:b74b:a88a:551d:1421:7d53:a1cf])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fac4a5e41sm15400339f8f.0.2025.09.28.07.38.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 28 Sep 2025 07:38: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: cd352e9b-9c78-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1759070310; x=1759675110; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9aeZpNNB3AM/ivUXnYLwY+Ge/tWwIuSoY+2XAyCf+Do=;
        b=c/ttDHEo0SSzGGsyMjKnxsa/lNR91mOtIRnmpPW9hjNCvUvpY6CQ8n61Q5d9osF49l
         MyUPLWrJyInE86Ebu2LxKQdfdgsKgWQxl945E9SmL5Zog6DlBVfhiwkmQw73XcnAGKT9
         A/I4GF0v6TtET27V4SDxxlzsOOd3eUz8OsU5wV0zHRlZgAUuNvtIR+ef7Z98fawRLnrt
         i3LJurZZW/WtU6wiYM17eHxK3N3kQKa5Iddig8FnLlsyR8GtiEeknvyN9BA/j4ROFG+E
         CLirWiAhfIgiUS2TReontqjTD7nk3zCXe5TW3rBy5P/2Q8KN9XrkjQHWdLnbEqKt8B10
         jwSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759070310; x=1759675110;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9aeZpNNB3AM/ivUXnYLwY+Ge/tWwIuSoY+2XAyCf+Do=;
        b=OkYmfAZihbaPeKrHhbop9L0ebqn0tH+EuGVzJ0FSyn+6E99/n9gBONrTcLCGChw+4K
         Cf7HvMNVVTisyxZvygctbQIbSTNnbIidBlxjNl4swC3nDc9wKFcPRVMOKh3DGD+7c7GA
         /OmWhRW+YwWFCUJz8AjhOwC6S7Z12wQwfmam2FSgYBSc/0MhRlHFyJqshd6+BmsR7wxC
         bit9cSmbrhlFk2tUZ4sfQ81BYOhCrJ/z8mRX7G0bR9og2oUqrIpsYgZZqiRYai9g5chA
         T1jfNeCPzcHEVzUtmVswVGdXzVnm7tiOKbMnsEMKWHfnRm2gTlU+LmhSjGuARE0yVnjr
         TVcw==
X-Forwarded-Encrypted: i=1; AJvYcCUD/eurvDc0GFqUeGuBwNRjhUolTF6X76dAv8gzx6Dyj8yUGCO5XlkF2oXRNvloStbe2pyKNfzNsgI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwwnWBow0MqZspNtVQcwpv5zGI+SMN/cVV2fqF1q+BmdYjHZp3w
	8GPzgNF5Xktap1/KhTYM2NoXOQo1j41dy53TlJ/eUu8T4EqbTRMWTsuQj63Wuquo9g==
X-Gm-Gg: ASbGnct3mGTj71Sp1onWGuqPhZjn0HDGqTrKqJgIdfDPErrb2YCmilJ/xwS8qnehKhb
	/t9WQK+7n80b/cq4J2k3BCo7s5vQFAS73U1q27spH8fyme4prUrP5f0wZs4evUME3IOfhKUIKVa
	unDVAY8MUlYbEAVv72K7OSP4G3kaLov8hzIGChG2wWm6zTjMpyiJhE9QHaSJFmAY3p7n/FVhy76
	TQg1mMY/RteFPJHnDRWOr1GHLyiZqNpNFEsilz85NJSmeMT1zA4kEBBKF7sId7wfiTS3DDc0ca+
	IEAEbxIYnQAqSG6ovE5Icyp9VDxdMSXIYQFPnoKwQBBSLsr49yS0Gh0pvjUSdPTbOL9aaQBfUmW
	uyV2//vn6NcBiYVXQsL1J5DS02NjAHi32gFt85scZeA3JMSWrI+CnLoR9Pb71Iv0zqfYtdWRr0n
	SJxXuaIqHm1l5b6Po7tmu07TUSsg3XbSiqYs6KwLngG4A+8LuN5NTkZpyg
X-Google-Smtp-Source: AGHT+IGQNs7J7TB/XXzKdpKDFpRYjCWC4Rin7mOPmDUkK4GAq3ANzMWbicFv1LLA6ubzkKuXDKTNlw==
X-Received: by 2002:a05:6000:26c9:b0:3ee:15c6:9a6b with SMTP id ffacd0b85a97d-40e48a5697amr12825355f8f.48.1759070309593;
        Sun, 28 Sep 2025 07:38:29 -0700 (PDT)
Message-ID: <0e72c63c-9a6b-4fd7-848d-8c8d09fc91ef@suse.com>
Date: Sun, 28 Sep 2025 16:38:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: Stefano Stabellini ,
 "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" ,
 "Stabellini, Stefano" ,
 "Andryuk, Jason" 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@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.09.2025 21:24, Stefano Stabellini wrote:
> On Thu, 25 Sep 2025, Penny, Zheng wrote:
>>> -----Original Message-----
>>> From: Jan Beulich 
>>> Sent: Friday, September 26, 2025 2:53 PM
>>> To: Penny, Zheng 
>>> Cc: Huang, Ray ; Daniel P. Smith
>>> ; xen-devel@lists.xenproject.org; Stabellini,
>>> Stefano ; Andryuk, Jason
>>> 
>>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
>>> CONFIG_MGMT_HYPERCALLS
>>>
>>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>>> -----Original Message-----
>>>>> From: Jan Beulich 
>>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>>
>>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Jan Beulich 
>>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>>
>>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>>      void (*security_domaininfo)(struct domain *d,
>>>>>>>>                                  struct xen_domctl_getdomaininfo *info);
>>>>>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>>> -    int (*getdomaininfo)(struct domain *d);
>>>>>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>> +    int (*getdomaininfo)(struct domain *d);
>>>>>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>>      int (*sysctl_scheduler_op)(int op);
>>>>>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>>> -234,7
>>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>>
>>>>>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>>> domain
>>>>>>>> *d)  {
>>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>>> +#else
>>>>>>>> +    return -EOPNOTSUPP;
>>>>>>>> +#endif
>>>>>>>>  }
>>>>>>>
>>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>>> really ought to extend to any operations available to other than the core
>>> toolstack.
>>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>>> (whether run in
>>>>> Dom0 or a stubdom).
>>>>>>
>>>>>> Maybe not only limited to the core toolstack. In
>>>>>> dom0less/hyperlaunched
>>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>>> pvh machine type and with very restricted functionality(, only acting
>>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
>>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
>>> upstream?
>>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>>> requires
>>>>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
>>>>> how it was called in QEMU...
>>>>>
>>>>> It's not "it"; it's different ones. First and foremost I was thinking
>>>>> of
>>>>>  * XEN_DOMCTL_ioport_mapping
>>>>>  * XEN_DOMCTL_memory_mapping
>>>>>  * XEN_DOMCTL_bind_pt_irq
>>>>>  * XEN_DOMCTL_unbind_pt_irq
>>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>>> checking can in principle be called by qemu.
>>>>>
>>>>
>>>> Understood.
>>>> I assume that they are all for device passthrough. We are not accepting device
>>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
>>> developed device passthrough through device tree to only accept "static
>>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
>>> internal , it may be the only accept way to do device passthrough in
>>> dom0less/hyperlaunch-ed scenario.
>>>
>>> Right, but no matter what your goals, the upstream contributions need to be self-
>>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
>>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
>>> them may be an option here.)
>>
>> Understood.
>> I'll move them all to the dm-ops
> 
> Hi Penny, Jan, I advise against this.
> 
> I think it is clear that there are open questions on how to deal with
> the safety scenarios. I briefly mentioned some of the issues last week
> at Xen Summit. One example is the listdomains hypercall that should be
> available to the control domain. We cannot resolve all problems with
> this patch series. I think we should follow a simpler plan:
> 
> 1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
>    removing all domctls and sysctls
> 
> 2) make further adjustments, such as making available the listdomains
>    hypercall and/or the hypercalls listed by Jan as a second step after
>    it

I'm going to be okay-ish with that as long as the help text of the Kconfig
option clearly mentions those extra pitfalls.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:02:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:02:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132400.1470768 (Exim 4.92)
	(envelope-from )
	id 1v2svM-0001oY-0n; Sun, 28 Sep 2025 15:02:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132400.1470768; Sun, 28 Sep 2025 15:02:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2svL-0001oP-Te; Sun, 28 Sep 2025 15:02:51 +0000
Received: by outflank-mailman (input) for mailman id 1132400;
 Sun, 28 Sep 2025 15:02:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2svK-0001Mg-Jm
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:02:50 +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 31c22b9a-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:02:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 108C843240;
 Sun, 28 Sep 2025 15:02:47 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C568C4CEF0;
 Sun, 28 Sep 2025 15:02: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: 31c22b9a-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071766;
	bh=VCOCqFxGPwggSuBDZKXbtlILkoSR1dboXF2jBBkRDQw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Vx025h1O6Widlbf8ZdUWczJlRCdm8t2J75iGS9YkD0Km/lK/Gq6LI2zL+dSoACFz8
	 vd8RLE751IJj5O7tK5pBaCXWBNz8cqNICZqHk6TPLPMahAofsQXTSw49By6IgGes+Z
	 leItKHWydjvkNTD6XXLN8xGmEYfoo0VczIt/YLiG1n94Z+IgStH5O2f5h8HfhDcTiQ
	 RUlO6m75yEL2F46lzosTWw5xsjAXulo0Iaf2bVqvrg5Olbvhf2srEYIDBcV0ZT05BU
	 qi0J4SOvF+E3fgzXxh/Ss2D+jzwLI3i2MlGFrRfKqWNcrkwmK0sjhhVDcGDWHvdeTw
	 D3kMaxocGZcJw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 3/9] parisc: Convert DMA map_page to map_phys interface
Date: Sun, 28 Sep 2025 18:02:23 +0300
Message-ID: <333ec4dabec16d3d913a93780bc6e7ddb5240fcf.1759071169.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Perform mechanical conversion from .map_page to .map_phys callback.

Signed-off-by: Leon Romanovsky 
---
 drivers/parisc/ccio-dma.c  | 25 +++++++++++++------------
 drivers/parisc/sba_iommu.c | 23 ++++++++++++-----------
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index feef537257d0..d45f3634f827 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -773,17 +773,18 @@ ccio_map_single(struct device *dev, void *addr, size_t size,
 
 
 static dma_addr_t
-ccio_map_page(struct device *dev, struct page *page, unsigned long offset,
-		size_t size, enum dma_data_direction direction,
-		unsigned long attrs)
+ccio_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+	      enum dma_data_direction direction, unsigned long attrs)
 {
-	return ccio_map_single(dev, page_address(page) + offset, size,
-			direction);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return ccio_map_single(dev, phys_to_virt(phys), size, direction);
 }
 
 
 /**
- * ccio_unmap_page - Unmap an address range from the IOMMU.
+ * ccio_unmap_phys - Unmap an address range from the IOMMU.
  * @dev: The PCI device.
  * @iova: The start address of the DMA region.
  * @size: The length of the DMA region.
@@ -791,7 +792,7 @@ ccio_map_page(struct device *dev, struct page *page, unsigned long offset,
  * @attrs: attributes
  */
 static void 
-ccio_unmap_page(struct device *dev, dma_addr_t iova, size_t size,
+ccio_unmap_phys(struct device *dev, dma_addr_t iova, size_t size,
 		enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ioc *ioc;
@@ -873,7 +874,7 @@ static void
 ccio_free(struct device *dev, size_t size, void *cpu_addr,
 		dma_addr_t dma_handle, unsigned long attrs)
 {
-	ccio_unmap_page(dev, dma_handle, size, 0, 0);
+	ccio_unmap_phys(dev, dma_handle, size, 0, 0);
 	free_pages((unsigned long)cpu_addr, get_order(size));
 }
 
@@ -1004,7 +1005,7 @@ ccio_unmap_sg(struct device *dev, struct scatterlist *sglist, int nents,
 #ifdef CCIO_COLLECT_STATS
 		ioc->usg_pages += sg_dma_len(sglist) >> PAGE_SHIFT;
 #endif
-		ccio_unmap_page(dev, sg_dma_address(sglist),
+		ccio_unmap_phys(dev, sg_dma_address(sglist),
 				  sg_dma_len(sglist), direction, 0);
 		++sglist;
 		nents--;
@@ -1017,8 +1018,8 @@ static const struct dma_map_ops ccio_ops = {
 	.dma_supported =	ccio_dma_supported,
 	.alloc =		ccio_alloc,
 	.free =			ccio_free,
-	.map_page =		ccio_map_page,
-	.unmap_page =		ccio_unmap_page,
+	.map_phys =		ccio_map_phys,
+	.unmap_phys =		ccio_unmap_phys,
 	.map_sg =		ccio_map_sg,
 	.unmap_sg =		ccio_unmap_sg,
 	.get_sgtable =		dma_common_get_sgtable,
@@ -1072,7 +1073,7 @@ static int ccio_proc_info(struct seq_file *m, void *p)
 			   ioc->msingle_calls, ioc->msingle_pages,
 			   (int)((ioc->msingle_pages * 1000)/ioc->msingle_calls));
 
-		/* KLUGE - unmap_sg calls unmap_page for each mapped page */
+		/* KLUGE - unmap_sg calls unmap_phys for each mapped page */
 		min = ioc->usingle_calls - ioc->usg_calls;
 		max = ioc->usingle_pages - ioc->usg_pages;
 		seq_printf(m, "pci_unmap_single: %8ld calls  %8ld pages (avg %d/1000)\n",
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index fc3863c09f83..8040aa4e6ff4 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -778,17 +778,18 @@ sba_map_single(struct device *dev, void *addr, size_t size,
 
 
 static dma_addr_t
-sba_map_page(struct device *dev, struct page *page, unsigned long offset,
-		size_t size, enum dma_data_direction direction,
-		unsigned long attrs)
+sba_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		enum dma_data_direction direction, unsigned long attrs)
 {
-	return sba_map_single(dev, page_address(page) + offset, size,
-			direction);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return sba_map_single(dev, phys_to_virt(phys), size, direction);
 }
 
 
 /**
- * sba_unmap_page - unmap one IOVA and free resources
+ * sba_unmap_phys - unmap one IOVA and free resources
  * @dev: instance of PCI owned by the driver that's asking.
  * @iova:  IOVA of driver buffer previously mapped.
  * @size:  number of bytes mapped in driver buffer.
@@ -798,7 +799,7 @@ sba_map_page(struct device *dev, struct page *page, unsigned long offset,
  * See Documentation/core-api/dma-api-howto.rst
  */
 static void
-sba_unmap_page(struct device *dev, dma_addr_t iova, size_t size,
+sba_unmap_phys(struct device *dev, dma_addr_t iova, size_t size,
 		enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ioc *ioc;
@@ -914,7 +915,7 @@ static void
 sba_free(struct device *hwdev, size_t size, void *vaddr,
 		    dma_addr_t dma_handle, unsigned long attrs)
 {
-	sba_unmap_page(hwdev, dma_handle, size, 0, 0);
+	sba_unmap_phys(hwdev, dma_handle, size, 0, 0);
 	free_pages((unsigned long) vaddr, get_order(size));
 }
 
@@ -1061,7 +1062,7 @@ sba_unmap_sg(struct device *dev, struct scatterlist *sglist, int nents,
 
 	while (nents && sg_dma_len(sglist)) {
 
-		sba_unmap_page(dev, sg_dma_address(sglist), sg_dma_len(sglist),
+		sba_unmap_phys(dev, sg_dma_address(sglist), sg_dma_len(sglist),
 				direction, 0);
 #ifdef SBA_COLLECT_STATS
 		ioc->usg_pages += ((sg_dma_address(sglist) & ~IOVP_MASK) + sg_dma_len(sglist) + IOVP_SIZE - 1) >> PAGE_SHIFT;
@@ -1085,8 +1086,8 @@ static const struct dma_map_ops sba_ops = {
 	.dma_supported =	sba_dma_supported,
 	.alloc =		sba_alloc,
 	.free =			sba_free,
-	.map_page =		sba_map_page,
-	.unmap_page =		sba_unmap_page,
+	.map_phys =		sba_map_phys,
+	.unmap_phys =		sba_unmap_phys,
 	.map_sg =		sba_map_sg,
 	.unmap_sg =		sba_unmap_sg,
 	.get_sgtable =		dma_common_get_sgtable,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:02:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:02:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132398.1470748 (Exim 4.92)
	(envelope-from )
	id 1v2svI-0001Mu-K9; Sun, 28 Sep 2025 15:02:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132398.1470748; Sun, 28 Sep 2025 15: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 1v2svI-0001Mn-Gi; Sun, 28 Sep 2025 15:02:48 +0000
Received: by outflank-mailman (input) for mailman id 1132398;
 Sun, 28 Sep 2025 15: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 1v2svH-0001Mh-BN
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:02: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 2feeb819-9c7c-11f0-9d14-b5c5bf9af7f9;
 Sun, 28 Sep 2025 17:02:45 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 58F4545F48;
 Sun, 28 Sep 2025 15:02:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81470C116B1;
 Sun, 28 Sep 2025 15:02: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: 2feeb819-9c7c-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071763;
	bh=joV1RJXfMRWLzhpnIVMn+yDni/E+0b2XTKZNLoQGaO4=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=DSOYpsgikSOy8MZ87jPu/KYUDc+l4cdaniO8RKKeI+Ogx+vIbjw3PFXybhxCGiVkL
	 Svbf9LCD/OLSu1+BhYWYUN2NsbU1qvbAJmkVnyM+ehBPWXa1P8Dfsr10VqVfh+CJ3/
	 fK0PydC9i55IUTpcrx/WEa8jZeqt059f7qwZBuoA4bLcGPLmEQkD0cguNeebMBEFKT
	 3RrvQyQn8dehTNH48u0yl6WLA+Tz2ziEbgsKR0IERUfTbFnsVdNo8hdbmtk8QqvVxt
	 7HSong2gEFWSxqgarqeXxYxR/Gye8uoIqVAF8qNmGQXTAkUC6S5UaNNMSjuWnuDC7u
	 prcP+vXzgDPsQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 2/9] MIPS/jazzdma: Provide physical address directly
Date: Sun, 28 Sep 2025 18:02:22 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

MIPS jazz uses physical addresses for mapping pages, so convert
it to get them directly from DMA mapping routine.

Signed-off-by: Leon Romanovsky 
---
 arch/mips/jazz/jazzdma.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/mips/jazz/jazzdma.c b/arch/mips/jazz/jazzdma.c
index c97b089b9902..45fe71aa454b 100644
--- a/arch/mips/jazz/jazzdma.c
+++ b/arch/mips/jazz/jazzdma.c
@@ -521,18 +521,24 @@ static void jazz_dma_free(struct device *dev, size_t size, void *vaddr,
 	__free_pages(virt_to_page(vaddr), get_order(size));
 }
 
-static dma_addr_t jazz_dma_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t size, enum dma_data_direction dir,
-		unsigned long attrs)
+static dma_addr_t jazz_dma_map_phys(struct device *dev, phys_addr_t phys,
+		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	phys_addr_t phys = page_to_phys(page) + offset;
+	if (attrs & DMA_ATTR_MMIO)
+		/*
+		 * This check is included because older versions of the code lacked
+		 * MMIO path support, and my ability to test this path is limited.
+		 * However, from a software technical standpoint, there is no restriction,
+		 * as the following code operates solely on physical addresses.
+		 */
+		return DMA_MAPPING_ERROR;
 
 	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
 		arch_sync_dma_for_device(phys, size, dir);
 	return vdma_alloc(phys, size);
 }
 
-static void jazz_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void jazz_dma_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
@@ -607,8 +613,8 @@ static void jazz_dma_sync_sg_for_cpu(struct device *dev,
 const struct dma_map_ops jazz_dma_ops = {
 	.alloc			= jazz_dma_alloc,
 	.free			= jazz_dma_free,
-	.map_page		= jazz_dma_map_page,
-	.unmap_page		= jazz_dma_unmap_page,
+	.map_phys		= jazz_dma_map_phys,
+	.unmap_phys		= jazz_dma_unmap_phys,
 	.map_sg			= jazz_dma_map_sg,
 	.unmap_sg		= jazz_dma_unmap_sg,
 	.sync_single_for_cpu	= jazz_dma_sync_single_for_cpu,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:02:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:02:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132399.1470758 (Exim 4.92)
	(envelope-from )
	id 1v2svJ-0001aP-Qn; Sun, 28 Sep 2025 15:02:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132399.1470758; Sun, 28 Sep 2025 15: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 1v2svJ-0001aI-N9; Sun, 28 Sep 2025 15:02:49 +0000
Received: by outflank-mailman (input) for mailman id 1132399;
 Sun, 28 Sep 2025 15:02:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2svI-0001Mg-QG
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:02:48 +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 2db117a1-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:02:41 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 60CC46218F;
 Sun, 28 Sep 2025 15:02:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48E12C4CEF0;
 Sun, 28 Sep 2025 15:02: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: 2db117a1-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071759;
	bh=Akj3CON6IBsq+OP9A9OkC5SszLfqcLnpZRG8DGaLpwM=;
	h=From:To:Cc:Subject:Date:From;
	b=TnkMQdRqI3QZ3YV/GCpp5pqPe146ZT+yd8f0yZi5dqhffQqkLDkFNg275CdcBt57r
	 P46/Q8MJggBoVrUATbN4yQz/1RNVzEr4qRwDBK1qefHMrZA7rRP2hz2qDSVWQ0iS7S
	 DGy5cZpbTLZ4famPhxfNn0tm+T9zHJU/CGhwJumTvkSrrah3nVMcJlpks0e7mhTc4w
	 j8HKF/6RRxHmpIgigj7NLyGRrG0vXEG8EvTBOOsy4JlJy5mBhEoqFp+dHa3/mFRG69
	 4FazbdhYoc7M4C8CocEkOrWVODSNfM2PMKHWaItVyJziGeyDxLU2xd+NY5jkkGqhpC
	 h/JiXqu+FTGaw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 0/9] Remove DMA .map_page and .unmap_page callbacks
Date: Sun, 28 Sep 2025 18:02:20 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Changelog:
v1:
 * Fixed wrong offset in alpha conversion patch.
v0: https://lore.kernel.org/all/cover.1758219786.git.leon@kernel.org

Hi,

This series continues following two series:
1. "dma-mapping: migrate to physical address-based API"
https://lore.kernel.org/all/cover.1757423202.git.leonro@nvidia.com
2. "Preparation to .map_page and .unmap_page removal"
Preparation to .map_page and .unmap_page removal

In this series, the DMA .map_page/.unmap_page callbacks are converted to newly
introduced .map_phys/.unmap_phys interfaces. This conversion allows us to reduce
or eliminate (for certain ARCHs) use of struct pages in DMA path.

Thanks

Leon Romanovsky (9):
  alpha: Convert mapping routine to rely on physical address
  MIPS/jazzdma: Provide physical address directly
  parisc: Convert DMA map_page to map_phys interface
  powerpc: Convert to physical address DMA mapping
  sparc64: Use physical address DMA mapping
  x86: Use physical address for DMA mapping
  vdpa: Convert to physical address DMA mapping
  xen: swiotlb: Convert mapping routine to rely on physical address
  dma-mapping: remove unused map_page callback

 arch/alpha/kernel/pci_iommu.c            | 48 +++++++++++-------------
 arch/mips/jazz/jazzdma.c                 | 20 ++++++----
 arch/powerpc/include/asm/iommu.h         |  8 ++--
 arch/powerpc/kernel/dma-iommu.c          | 22 +++++------
 arch/powerpc/kernel/iommu.c              | 14 +++----
 arch/powerpc/platforms/ps3/system-bus.c  | 33 +++++++++-------
 arch/powerpc/platforms/pseries/ibmebus.c | 15 ++++----
 arch/powerpc/platforms/pseries/vio.c     | 21 ++++++-----
 arch/sparc/kernel/iommu.c                | 16 ++++----
 arch/sparc/kernel/pci_sun4v.c            | 16 ++++----
 arch/sparc/mm/io-unit.c                  | 13 +++----
 arch/sparc/mm/iommu.c                    | 46 ++++++++++++-----------
 arch/x86/kernel/amd_gart_64.c            | 19 +++++-----
 drivers/parisc/ccio-dma.c                | 25 ++++++------
 drivers/parisc/sba_iommu.c               | 23 ++++++------
 drivers/vdpa/vdpa_user/iova_domain.c     | 11 +++---
 drivers/vdpa/vdpa_user/iova_domain.h     |  8 ++--
 drivers/vdpa/vdpa_user/vduse_dev.c       | 18 +++++----
 drivers/xen/grant-dma-ops.c              | 20 ++++++----
 include/linux/dma-map-ops.h              |  7 ----
 kernel/dma/mapping.c                     | 12 ------
 kernel/dma/ops_helpers.c                 |  8 +---
 22 files changed, 209 insertions(+), 214 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:02:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:02:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132401.1470778 (Exim 4.92)
	(envelope-from )
	id 1v2svQ-00026H-7c; Sun, 28 Sep 2025 15:02:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132401.1470778; Sun, 28 Sep 2025 15:02: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 1v2svQ-00026A-4X; Sun, 28 Sep 2025 15:02:56 +0000
Received: by outflank-mailman (input) for mailman id 1132401;
 Sun, 28 Sep 2025 15:02: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 1v2svO-0001Mg-47
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:02:54 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 341f5cd3-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:02: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 C0DBC6219A;
 Sun, 28 Sep 2025 15:02:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9EB9C4CEF0;
 Sun, 28 Sep 2025 15:02: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: 341f5cd3-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071770;
	bh=If22SjLGOh/is+v52/ZDiDRnMnCqTEHc+dpMRM0pA2s=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=LAocKRbJbaa97FIPPcaZ9C2Al8lU+DHQdZiPjJKGYtG5Bpk11+lwm3Tqi7A4+qTaw
	 iQ70Bpw0TW3NRd41XhsfDsE99PRxJaEzj9U3/HQLJVS+/xQcYXRfViOEcnd+g8Lr8g
	 xOXUh40eUvXDb1DNt5t6GB30z/eXqiin6CTW6vSxQDDhRFw9GYswOSz6RGlwZRIAQC
	 2ctL1b0csjMfGi3YVKGtGCAn4+8dWOC/oik0SDvI7Gz9EvUZrIGJFbqcfsbEV7ZjeK
	 UKzgbUcboFDm5Iu7CjnXI7xmOHIS+z+B5/YSjpEbRi93B78wqFfgKWaSblWkn37+ti
	 lU2bP2uCwCkzw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 4/9] powerpc: Convert to physical address DMA mapping
Date: Sun, 28 Sep 2025 18:02:24 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Adapt PowerPC DMA to use physical addresses in order to prepare code
to removal .map_page and .unmap_page.

Signed-off-by: Leon Romanovsky 
---
 arch/powerpc/include/asm/iommu.h         |  8 +++---
 arch/powerpc/kernel/dma-iommu.c          | 22 +++++++---------
 arch/powerpc/kernel/iommu.c              | 14 +++++-----
 arch/powerpc/platforms/ps3/system-bus.c  | 33 ++++++++++++++----------
 arch/powerpc/platforms/pseries/ibmebus.c | 15 ++++++-----
 arch/powerpc/platforms/pseries/vio.c     | 21 ++++++++-------
 6 files changed, 60 insertions(+), 53 deletions(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index b410021ad4c6..eafdd63cd6c4 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -274,12 +274,12 @@ extern void *iommu_alloc_coherent(struct device *dev, struct iommu_table *tbl,
 				  unsigned long mask, gfp_t flag, int node);
 extern void iommu_free_coherent(struct iommu_table *tbl, size_t size,
 				void *vaddr, dma_addr_t dma_handle);
-extern dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
-				 struct page *page, unsigned long offset,
-				 size_t size, unsigned long mask,
+extern dma_addr_t iommu_map_phys(struct device *dev, struct iommu_table *tbl,
+				 phys_addr_t phys, size_t size,
+				 unsigned long mask,
 				 enum dma_data_direction direction,
 				 unsigned long attrs);
-extern void iommu_unmap_page(struct iommu_table *tbl, dma_addr_t dma_handle,
+extern void iommu_unmap_phys(struct iommu_table *tbl, dma_addr_t dma_handle,
 			     size_t size, enum dma_data_direction direction,
 			     unsigned long attrs);
 
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 0359ab72cd3b..aa3689d61917 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -93,28 +93,26 @@ static void dma_iommu_free_coherent(struct device *dev, size_t size,
 
 /* Creates TCEs for a user provided buffer.  The user buffer must be
  * contiguous real kernel storage (not vmalloc).  The address passed here
- * comprises a page address and offset into that page. The dma_addr_t
- * returned will point to the same byte within the page as was passed in.
+ * is a physical address to that page. The dma_addr_t returned will point
+ * to the same byte within the page as was passed in.
  */
-static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
-				     unsigned long offset, size_t size,
+static dma_addr_t dma_iommu_map_phys(struct device *dev, phys_addr_t phys,
+				     size_t size,
 				     enum dma_data_direction direction,
 				     unsigned long attrs)
 {
-	return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
-			      size, dma_get_mask(dev), direction, attrs);
+	return iommu_map_phys(dev, get_iommu_table_base(dev), phys, size,
+			      dma_get_mask(dev), direction, attrs);
 }
 
-
-static void dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void dma_iommu_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 				 size_t size, enum dma_data_direction direction,
 				 unsigned long attrs)
 {
-	iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
+	iommu_unmap_phys(get_iommu_table_base(dev), dma_handle, size, direction,
 			 attrs);
 }
 
-
 static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
 			    int nelems, enum dma_data_direction direction,
 			    unsigned long attrs)
@@ -211,8 +209,8 @@ const struct dma_map_ops dma_iommu_ops = {
 	.map_sg			= dma_iommu_map_sg,
 	.unmap_sg		= dma_iommu_unmap_sg,
 	.dma_supported		= dma_iommu_dma_supported,
-	.map_page		= dma_iommu_map_page,
-	.unmap_page		= dma_iommu_unmap_page,
+	.map_phys		= dma_iommu_map_phys,
+	.unmap_phys		= dma_iommu_unmap_phys,
 	.get_required_mask	= dma_iommu_get_required_mask,
 	.mmap			= dma_common_mmap,
 	.get_sgtable		= dma_common_get_sgtable,
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 244eb4857e7f..6b5f4b72ce97 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -848,12 +848,12 @@ EXPORT_SYMBOL_GPL(iommu_tce_table_put);
 
 /* Creates TCEs for a user provided buffer.  The user buffer must be
  * contiguous real kernel storage (not vmalloc).  The address passed here
- * comprises a page address and offset into that page. The dma_addr_t
- * returned will point to the same byte within the page as was passed in.
+ * is physical address into that page. The dma_addr_t returned will point
+ * to the same byte within the page as was passed in.
  */
-dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
-			  struct page *page, unsigned long offset, size_t size,
-			  unsigned long mask, enum dma_data_direction direction,
+dma_addr_t iommu_map_phys(struct device *dev, struct iommu_table *tbl,
+			  phys_addr_t phys, size_t size, unsigned long mask,
+			  enum dma_data_direction direction,
 			  unsigned long attrs)
 {
 	dma_addr_t dma_handle = DMA_MAPPING_ERROR;
@@ -863,7 +863,7 @@ dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
 
 	BUG_ON(direction == DMA_NONE);
 
-	vaddr = page_address(page) + offset;
+	vaddr = phys_to_virt(phys);
 	uaddr = (unsigned long)vaddr;
 
 	if (tbl) {
@@ -890,7 +890,7 @@ dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
 	return dma_handle;
 }
 
-void iommu_unmap_page(struct iommu_table *tbl, dma_addr_t dma_handle,
+void iommu_unmap_phys(struct iommu_table *tbl, dma_addr_t dma_handle,
 		      size_t size, enum dma_data_direction direction,
 		      unsigned long attrs)
 {
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index afbaabf182d0..a223ba777148 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -551,18 +551,20 @@ static void ps3_free_coherent(struct device *_dev, size_t size, void *vaddr,
 
 /* Creates TCEs for a user provided buffer.  The user buffer must be
  * contiguous real kernel storage (not vmalloc).  The address passed here
- * comprises a page address and offset into that page. The dma_addr_t
- * returned will point to the same byte within the page as was passed in.
+ * is physical address to that hat page. The dma_addr_t returned will point
+ * to the same byte within the page as was passed in.
  */
 
-static dma_addr_t ps3_sb_map_page(struct device *_dev, struct page *page,
-	unsigned long offset, size_t size, enum dma_data_direction direction,
-	unsigned long attrs)
+static dma_addr_t ps3_sb_map_phys(struct device *_dev, phys_addr_t phys,
+	size_t size, enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
 	int result;
 	dma_addr_t bus_addr;
-	void *ptr = page_address(page) + offset;
+	void *ptr = phys_to_virt(phys);
+
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
 	result = ps3_dma_map(dev->d_region, (unsigned long)ptr, size,
 			     &bus_addr,
@@ -577,8 +579,8 @@ static dma_addr_t ps3_sb_map_page(struct device *_dev, struct page *page,
 	return bus_addr;
 }
 
-static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
-				    unsigned long offset, size_t size,
+static dma_addr_t ps3_ioc0_map_phys(struct device *_dev, phys_addr_t phys,
+				    size_t size,
 				    enum dma_data_direction direction,
 				    unsigned long attrs)
 {
@@ -586,7 +588,10 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
 	int result;
 	dma_addr_t bus_addr;
 	u64 iopte_flag;
-	void *ptr = page_address(page) + offset;
+	void *ptr = phys_to_virt(phys);
+
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
 	iopte_flag = CBE_IOPTE_M;
 	switch (direction) {
@@ -613,7 +618,7 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
 	return bus_addr;
 }
 
-static void ps3_unmap_page(struct device *_dev, dma_addr_t dma_addr,
+static void ps3_unmap_phys(struct device *_dev, dma_addr_t dma_addr,
 	size_t size, enum dma_data_direction direction, unsigned long attrs)
 {
 	struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
@@ -690,8 +695,8 @@ static const struct dma_map_ops ps3_sb_dma_ops = {
 	.map_sg = ps3_sb_map_sg,
 	.unmap_sg = ps3_sb_unmap_sg,
 	.dma_supported = ps3_dma_supported,
-	.map_page = ps3_sb_map_page,
-	.unmap_page = ps3_unmap_page,
+	.map_phys = ps3_sb_map_phys,
+	.unmap_phys = ps3_unmap_phys,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
 	.alloc_pages_op = dma_common_alloc_pages,
@@ -704,8 +709,8 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
 	.map_sg = ps3_ioc0_map_sg,
 	.unmap_sg = ps3_ioc0_unmap_sg,
 	.dma_supported = ps3_dma_supported,
-	.map_page = ps3_ioc0_map_page,
-	.unmap_page = ps3_unmap_page,
+	.map_phys = ps3_ioc0_map_phys,
+	.unmap_phys = ps3_unmap_phys,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
 	.alloc_pages_op = dma_common_alloc_pages,
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c b/arch/powerpc/platforms/pseries/ibmebus.c
index 3436b0af795e..cad2deb7e70d 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -86,17 +86,18 @@ static void ibmebus_free_coherent(struct device *dev,
 	kfree(vaddr);
 }
 
-static dma_addr_t ibmebus_map_page(struct device *dev,
-				   struct page *page,
-				   unsigned long offset,
+static dma_addr_t ibmebus_map_phys(struct device *dev, phys_addr_t phys,
 				   size_t size,
 				   enum dma_data_direction direction,
 				   unsigned long attrs)
 {
-	return (dma_addr_t)(page_address(page) + offset);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return (dma_addr_t)(phys_to_virt(phys));
 }
 
-static void ibmebus_unmap_page(struct device *dev,
+static void ibmebus_unmap_phys(struct device *dev,
 			       dma_addr_t dma_addr,
 			       size_t size,
 			       enum dma_data_direction direction,
@@ -146,8 +147,8 @@ static const struct dma_map_ops ibmebus_dma_ops = {
 	.unmap_sg           = ibmebus_unmap_sg,
 	.dma_supported      = ibmebus_dma_supported,
 	.get_required_mask  = ibmebus_dma_get_required_mask,
-	.map_page           = ibmebus_map_page,
-	.unmap_page         = ibmebus_unmap_page,
+	.map_phys           = ibmebus_map_phys,
+	.unmap_phys         = ibmebus_unmap_phys,
 };
 
 static int ibmebus_match_path(struct device *dev, const void *data)
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index ac1d2d2c9a88..838e29d47378 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -512,18 +512,21 @@ static void vio_dma_iommu_free_coherent(struct device *dev, size_t size,
 	vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
 }
 
-static dma_addr_t vio_dma_iommu_map_page(struct device *dev, struct page *page,
-                                         unsigned long offset, size_t size,
-                                         enum dma_data_direction direction,
-                                         unsigned long attrs)
+static dma_addr_t vio_dma_iommu_map_phys(struct device *dev, phys_addr_t phys,
+					 size_t size,
+					 enum dma_data_direction direction,
+					 unsigned long attrs)
 {
 	struct vio_dev *viodev = to_vio_dev(dev);
 	struct iommu_table *tbl = get_iommu_table_base(dev);
 	dma_addr_t ret = DMA_MAPPING_ERROR;
 
+	if (attrs & DMA_ATTR_MMIO)
+		return ret;
+
 	if (vio_cmo_alloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl))))
 		goto out_fail;
-	ret = iommu_map_page(dev, tbl, page, offset, size, dma_get_mask(dev),
+	ret = iommu_map_phys(dev, tbl, phys, size, dma_get_mask(dev),
 			direction, attrs);
 	if (unlikely(ret == DMA_MAPPING_ERROR))
 		goto out_deallocate;
@@ -536,7 +539,7 @@ static dma_addr_t vio_dma_iommu_map_page(struct device *dev, struct page *page,
 	return DMA_MAPPING_ERROR;
 }
 
-static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void vio_dma_iommu_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 				     size_t size,
 				     enum dma_data_direction direction,
 				     unsigned long attrs)
@@ -544,7 +547,7 @@ static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
 	struct vio_dev *viodev = to_vio_dev(dev);
 	struct iommu_table *tbl = get_iommu_table_base(dev);
 
-	iommu_unmap_page(tbl, dma_handle, size, direction, attrs);
+	iommu_unmap_phys(tbl, dma_handle, size, direction, attrs);
 	vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
 }
 
@@ -605,8 +608,8 @@ static const struct dma_map_ops vio_dma_mapping_ops = {
 	.free              = vio_dma_iommu_free_coherent,
 	.map_sg            = vio_dma_iommu_map_sg,
 	.unmap_sg          = vio_dma_iommu_unmap_sg,
-	.map_page          = vio_dma_iommu_map_page,
-	.unmap_page        = vio_dma_iommu_unmap_page,
+	.map_phys          = vio_dma_iommu_map_phys,
+	.unmap_phys        = vio_dma_iommu_unmap_phys,
 	.dma_supported     = dma_iommu_dma_supported,
 	.get_required_mask = dma_iommu_get_required_mask,
 	.mmap		   = dma_common_mmap,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:02:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:02:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132404.1470788 (Exim 4.92)
	(envelope-from )
	id 1v2svT-0002P3-Jg; Sun, 28 Sep 2025 15:02:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132404.1470788; Sun, 28 Sep 2025 15: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 1v2svT-0002Ou-GJ; Sun, 28 Sep 2025 15:02:59 +0000
Received: by outflank-mailman (input) for mailman id 1132404;
 Sun, 28 Sep 2025 15:02: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 1v2svS-0001Mg-Pe
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:02: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 371bab67-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:02:56 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1040962199;
 Sun, 28 Sep 2025 15:02:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2C49C4CEF5;
 Sun, 28 Sep 2025 15:02:53 +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: 371bab67-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071775;
	bh=jNtnwWwMV3plKAecUNIdrhRBaM4ED7uOfKosdK+4834=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=q5iYL8J4WbMGQv508j0QZDEfRJ0+7iu0lvJK3NuWtN1V3QOH6cmyo6Kk/sloMCjGJ
	 3opzab96iV6QBOWtv3sEcwe3ixvE9omNE1shesZU9PSudr5AtxFOSo+XfXeHrS3kRm
	 N4PgnJV5qrM/PtIMgPQ1CS8vRmu6FNYaMEtf1Uln3Tgfwxf4/ZiydAtEBi+XdEIyaT
	 tFEnF9SvQ2T9pHurTpXc/xL+PlNqDJ6+SkERg2O08QiR0KVTHkZeHs+oryBHUZdFXG
	 lNYCWoQiMxLiaXDpAfuLbBo4vqWn76vCduW5o0tt6jpMIf/+MzpS5eMBgsF2hYeqvS
	 WZi3vUeeyRjAw==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 1/9] alpha: Convert mapping routine to rely on physical address
Date: Sun, 28 Sep 2025 18:02:21 +0300
Message-ID: <512d4c498103fcfccd8c60ce1982cd961434d30b.1759071169.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Alpha doesn't need struct *page and can perform mapping based on
physical addresses. So convert it to implement new .map_phys callback.

As part of this change, remove useless BUG_ON() as DMA mapping layer
ensures that right direction is provided.

Signed-off-by: Leon Romanovsky 
---
 arch/alpha/kernel/pci_iommu.c | 48 +++++++++++++++--------------------
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index dc91de50f906..3e4f631a1f27 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -224,28 +224,26 @@ static int pci_dac_dma_supported(struct pci_dev *dev, u64 mask)
    until either pci_unmap_single or pci_dma_sync_single is performed.  */
 
 static dma_addr_t
-pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
+pci_map_single_1(struct pci_dev *pdev, phys_addr_t paddr, size_t size,
 		 int dac_allowed)
 {
 	struct pci_controller *hose = pdev ? pdev->sysdata : pci_isa_hose;
 	dma_addr_t max_dma = pdev ? pdev->dma_mask : ISA_DMA_MASK;
+	unsigned long offset = offset_in_page(paddr);
 	struct pci_iommu_arena *arena;
 	long npages, dma_ofs, i;
-	unsigned long paddr;
 	dma_addr_t ret;
 	unsigned int align = 0;
 	struct device *dev = pdev ? &pdev->dev : NULL;
 
-	paddr = __pa(cpu_addr);
-
 #if !DEBUG_NODIRECT
 	/* First check to see if we can use the direct map window.  */
 	if (paddr + size + __direct_map_base - 1 <= max_dma
 	    && paddr + size <= __direct_map_size) {
 		ret = paddr + __direct_map_base;
 
-		DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %ps\n",
-		      cpu_addr, size, ret, __builtin_return_address(0));
+		DBGA2("pci_map_single: [%pa,%zx] -> direct %llx from %ps\n",
+		      &paddr, size, ret, __builtin_return_address(0));
 
 		return ret;
 	}
@@ -255,8 +253,8 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
 	if (dac_allowed) {
 		ret = paddr + alpha_mv.pci_dac_offset;
 
-		DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %ps\n",
-		      cpu_addr, size, ret, __builtin_return_address(0));
+		DBGA2("pci_map_single: [%pa,%zx] -> DAC %llx from %ps\n",
+		      &paddr, size, ret, __builtin_return_address(0));
 
 		return ret;
 	}
@@ -290,10 +288,10 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
 		arena->ptes[i + dma_ofs] = mk_iommu_pte(paddr);
 
 	ret = arena->dma_base + dma_ofs * PAGE_SIZE;
-	ret += (unsigned long)cpu_addr & ~PAGE_MASK;
+	ret += offset;
 
-	DBGA2("pci_map_single: [%p,%zx] np %ld -> sg %llx from %ps\n",
-	      cpu_addr, size, npages, ret, __builtin_return_address(0));
+	DBGA2("pci_map_single: [%pa,%zx] np %ld -> sg %llx from %ps\n",
+	      &paddr, size, npages, ret, __builtin_return_address(0));
 
 	return ret;
 }
@@ -322,19 +320,18 @@ static struct pci_dev *alpha_gendev_to_pci(struct device *dev)
 	return NULL;
 }
 
-static dma_addr_t alpha_pci_map_page(struct device *dev, struct page *page,
-				     unsigned long offset, size_t size,
-				     enum dma_data_direction dir,
+static dma_addr_t alpha_pci_map_phys(struct device *dev, phys_addr_t phys,
+				     size_t size, enum dma_data_direction dir,
 				     unsigned long attrs)
 {
 	struct pci_dev *pdev = alpha_gendev_to_pci(dev);
 	int dac_allowed;
 
-	BUG_ON(dir == DMA_NONE);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
-	dac_allowed = pdev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0; 
-	return pci_map_single_1(pdev, (char *)page_address(page) + offset, 
-				size, dac_allowed);
+	dac_allowed = pdev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0;
+	return pci_map_single_1(pdev, phys, size, dac_allowed);
 }
 
 /* Unmap a single streaming mode DMA translation.  The DMA_ADDR and
@@ -343,7 +340,7 @@ static dma_addr_t alpha_pci_map_page(struct device *dev, struct page *page,
    the cpu to the buffer are guaranteed to see whatever the device
    wrote there.  */
 
-static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void alpha_pci_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 				 size_t size, enum dma_data_direction dir,
 				 unsigned long attrs)
 {
@@ -353,8 +350,6 @@ static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr,
 	struct pci_iommu_arena *arena;
 	long dma_ofs, npages;
 
-	BUG_ON(dir == DMA_NONE);
-
 	if (dma_addr >= __direct_map_base
 	    && dma_addr < __direct_map_base + __direct_map_size) {
 		/* Nothing to do.  */
@@ -429,7 +424,7 @@ static void *alpha_pci_alloc_coherent(struct device *dev, size_t size,
 	}
 	memset(cpu_addr, 0, size);
 
-	*dma_addrp = pci_map_single_1(pdev, cpu_addr, size, 0);
+	*dma_addrp = pci_map_single_1(pdev, virt_to_phys(cpu_addr), size, 0);
 	if (*dma_addrp == DMA_MAPPING_ERROR) {
 		free_pages((unsigned long)cpu_addr, order);
 		if (alpha_mv.mv_pci_tbi || (gfp & GFP_DMA))
@@ -643,9 +638,8 @@ static int alpha_pci_map_sg(struct device *dev, struct scatterlist *sg,
 	/* Fast path single entry scatterlists.  */
 	if (nents == 1) {
 		sg->dma_length = sg->length;
-		sg->dma_address
-		  = pci_map_single_1(pdev, SG_ENT_VIRT_ADDRESS(sg),
-				     sg->length, dac_allowed);
+		sg->dma_address = pci_map_single_1(pdev, sg_phys(sg),
+						   sg->length, dac_allowed);
 		if (sg->dma_address == DMA_MAPPING_ERROR)
 			return -EIO;
 		return 1;
@@ -917,8 +911,8 @@ iommu_unbind(struct pci_iommu_arena *arena, long pg_start, long pg_count)
 const struct dma_map_ops alpha_pci_ops = {
 	.alloc			= alpha_pci_alloc_coherent,
 	.free			= alpha_pci_free_coherent,
-	.map_page		= alpha_pci_map_page,
-	.unmap_page		= alpha_pci_unmap_page,
+	.map_phys		= alpha_pci_map_phys,
+	.unmap_phys		= alpha_pci_unmap_phys,
 	.map_sg			= alpha_pci_map_sg,
 	.unmap_sg		= alpha_pci_unmap_sg,
 	.dma_supported		= alpha_pci_supported,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:03:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:03:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132409.1470798 (Exim 4.92)
	(envelope-from )
	id 1v2svY-0002n7-Rz; Sun, 28 Sep 2025 15:03:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132409.1470798; Sun, 28 Sep 2025 15: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 1v2svY-0002mw-O8; Sun, 28 Sep 2025 15:03:04 +0000
Received: by outflank-mailman (input) for mailman id 1132409;
 Sun, 28 Sep 2025 15:03: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 1v2svX-0001Mg-8I
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:03:03 +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 39751a9e-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:03: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 0216C6218E;
 Sun, 28 Sep 2025 15:03:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A7E5C4CEF0;
 Sun, 28 Sep 2025 15:02: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: 39751a9e-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071779;
	bh=rTsxFZePz2yuX+NtfO2kDwccU3HnGAbQvISKF3+oa1o=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=gLZHsFQQ8HQtfOqWgjtzTUBMSHZQ3R4/SOszE4+XoG4l/f2FLRJbyk9ezRQXXc2h8
	 ONJjl8yAKs3hxu8eNi4l+ERA0I3gjnJVzz0YroJWkBOomuoob/TeHDNUoV+39jEb6I
	 rmjhiT1PTSLErsackYjS82wmKYR5VC0J1GfIDBfN1M8bl4dVJUZKKtkNL9qsVq9J8i
	 z2rb1M+mt3pTqkh1QBhu87GzTbDK00LU0Pp8n65VlnXBK70s7NVf1n/VoKncnswPQE
	 fGBCpVF6nMJFCLyCcZjEduuiExQJxRrhtAfRZpFV+iZrHKlwqoLeHvuBYUekHkubmz
	 Jkaop5Zi+ew4Q==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 6/9] x86: Use physical address for DMA mapping
Date: Sun, 28 Sep 2025 18:02:26 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Perform mechanical conversion from DMA .map_page to .map_phys.

Signed-off-by: Leon Romanovsky 
---
 arch/x86/kernel/amd_gart_64.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 3485d419c2f5..f1ffdc0e4a3a 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -222,13 +222,14 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 }
 
 /* Map a single area into the IOMMU */
-static dma_addr_t gart_map_page(struct device *dev, struct page *page,
-				unsigned long offset, size_t size,
-				enum dma_data_direction dir,
+static dma_addr_t gart_map_phys(struct device *dev, phys_addr_t paddr,
+				size_t size, enum dma_data_direction dir,
 				unsigned long attrs)
 {
 	unsigned long bus;
-	phys_addr_t paddr = page_to_phys(page) + offset;
+
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
 
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
@@ -242,7 +243,7 @@ static dma_addr_t gart_map_page(struct device *dev, struct page *page,
 /*
  * Free a DMA mapping.
  */
-static void gart_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void gart_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 			    size_t size, enum dma_data_direction dir,
 			    unsigned long attrs)
 {
@@ -282,7 +283,7 @@ static void gart_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 	for_each_sg(sg, s, nents, i) {
 		if (!s->dma_length || !s->length)
 			break;
-		gart_unmap_page(dev, s->dma_address, s->dma_length, dir, 0);
+		gart_unmap_phys(dev, s->dma_address, s->dma_length, dir, 0);
 	}
 }
 
@@ -487,7 +488,7 @@ static void
 gart_free_coherent(struct device *dev, size_t size, void *vaddr,
 		   dma_addr_t dma_addr, unsigned long attrs)
 {
-	gart_unmap_page(dev, dma_addr, size, DMA_BIDIRECTIONAL, 0);
+	gart_unmap_phys(dev, dma_addr, size, DMA_BIDIRECTIONAL, 0);
 	dma_direct_free(dev, size, vaddr, dma_addr, attrs);
 }
 
@@ -668,8 +669,8 @@ static __init int init_amd_gatt(struct agp_kern_info *info)
 static const struct dma_map_ops gart_dma_ops = {
 	.map_sg				= gart_map_sg,
 	.unmap_sg			= gart_unmap_sg,
-	.map_page			= gart_map_page,
-	.unmap_page			= gart_unmap_page,
+	.map_phys			= gart_map_phys,
+	.unmap_phys			= gart_unmap_phys,
 	.alloc				= gart_alloc_coherent,
 	.free				= gart_free_coherent,
 	.mmap				= dma_common_mmap,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:03:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:03:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132411.1470808 (Exim 4.92)
	(envelope-from )
	id 1v2svb-00036k-5R; Sun, 28 Sep 2025 15:03:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132411.1470808; Sun, 28 Sep 2025 15:03: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 1v2svb-00036W-10; Sun, 28 Sep 2025 15:03:07 +0000
Received: by outflank-mailman (input) for mailman id 1132411;
 Sun, 28 Sep 2025 15:03: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 1v2svZ-0001Mh-N4
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:03:05 +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 3b78a071-9c7c-11f0-9d14-b5c5bf9af7f9;
 Sun, 28 Sep 2025 17:03: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 58E35443D9;
 Sun, 28 Sep 2025 15:03:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A390C4CEF0;
 Sun, 28 Sep 2025 15:03: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: 3b78a071-9c7c-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071783;
	bh=Ij0uTy1OlJGAg7lnkUtDmxO01shTBaaj+uIPzSERgrU=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=fY7jKenQggaIx2jtjZuB6uQLISTNufTm8rMgGJzO07IYL8vO6GWLJYx3TECVsXMXN
	 wBFOb8xnO78E31d0k727L1YDuVOkZOwLaN14A38UC4OIl5z6NwYopVhauUQgN4uYjd
	 Z1j0Hzf/aow0u91fDEfE2ibxWJkzECaGulmiSQijgWdmZvmBETmsJsFYG01wE9kV2V
	 gMBiAQh0oxrYUoXayv5CaRb11u4XY/2FzJUdgEhJ9m38AxCZiSOdfCYSFId/skTbqm
	 odl03w8FwLQt7lISHmEvTFzKcnJaFoaDlCKkL8sjMV3FOlwH3nlebDL4QRSHUhfx6m
	 R/MlI/Ps05Isg==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 7/9] vdpa: Convert to physical address DMA mapping
Date: Sun, 28 Sep 2025 18:02:27 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Use physical address directly in DMA mapping flow.

Signed-off-by: Leon Romanovsky 
---
 drivers/vdpa/vdpa_user/iova_domain.c | 11 +++++------
 drivers/vdpa/vdpa_user/iova_domain.h |  8 ++++----
 drivers/vdpa/vdpa_user/vduse_dev.c   | 18 ++++++++++--------
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c
index 58116f89d8da..c0ecf01003cd 100644
--- a/drivers/vdpa/vdpa_user/iova_domain.c
+++ b/drivers/vdpa/vdpa_user/iova_domain.c
@@ -396,17 +396,16 @@ void vduse_domain_sync_single_for_cpu(struct vduse_iova_domain *domain,
 	read_unlock(&domain->bounce_lock);
 }
 
-dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
-				 struct page *page, unsigned long offset,
-				 size_t size, enum dma_data_direction dir,
+dma_addr_t vduse_domain_map_phys(struct vduse_iova_domain *domain,
+				 phys_addr_t pa, size_t size,
+				 enum dma_data_direction dir,
 				 unsigned long attrs)
 {
 	struct iova_domain *iovad = &domain->stream_iovad;
 	unsigned long limit = domain->bounce_size - 1;
-	phys_addr_t pa = page_to_phys(page) + offset;
 	dma_addr_t iova = vduse_domain_alloc_iova(iovad, size, limit);
 
-	if (!iova)
+	if (!iova || (attrs & DMA_ATTR_MMIO))
 		return DMA_MAPPING_ERROR;
 
 	if (vduse_domain_init_bounce_map(domain))
@@ -430,7 +429,7 @@ dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
 	return DMA_MAPPING_ERROR;
 }
 
-void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+void vduse_domain_unmap_phys(struct vduse_iova_domain *domain,
 			     dma_addr_t dma_addr, size_t size,
 			     enum dma_data_direction dir, unsigned long attrs)
 {
diff --git a/drivers/vdpa/vdpa_user/iova_domain.h b/drivers/vdpa/vdpa_user/iova_domain.h
index 7f3f0928ec78..7c4546fd856a 100644
--- a/drivers/vdpa/vdpa_user/iova_domain.h
+++ b/drivers/vdpa/vdpa_user/iova_domain.h
@@ -53,12 +53,12 @@ void vduse_domain_sync_single_for_cpu(struct vduse_iova_domain *domain,
 				      dma_addr_t dma_addr, size_t size,
 				      enum dma_data_direction dir);
 
-dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
-				 struct page *page, unsigned long offset,
-				 size_t size, enum dma_data_direction dir,
+dma_addr_t vduse_domain_map_phys(struct vduse_iova_domain *domain,
+				 phys_addr_t phys, size_t size,
+				 enum dma_data_direction dir,
 				 unsigned long attrs);
 
-void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+void vduse_domain_unmap_phys(struct vduse_iova_domain *domain,
 			     dma_addr_t dma_addr, size_t size,
 			     enum dma_data_direction dir, unsigned long attrs);
 
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index 04620bb77203..75aa3c9f83fb 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -834,25 +834,27 @@ static void vduse_dev_sync_single_for_cpu(struct device *dev,
 	vduse_domain_sync_single_for_cpu(domain, dma_addr, size, dir);
 }
 
-static dma_addr_t vduse_dev_map_page(struct device *dev, struct page *page,
-				     unsigned long offset, size_t size,
-				     enum dma_data_direction dir,
+static dma_addr_t vduse_dev_map_phys(struct device *dev, phys_addr_t phys,
+				     size_t size, enum dma_data_direction dir,
 				     unsigned long attrs)
 {
 	struct vduse_dev *vdev = dev_to_vduse(dev);
 	struct vduse_iova_domain *domain = vdev->domain;
 
-	return vduse_domain_map_page(domain, page, offset, size, dir, attrs);
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
+	return vduse_domain_map_phys(domain, phys, size, dir, attrs);
 }
 
-static void vduse_dev_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void vduse_dev_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 				size_t size, enum dma_data_direction dir,
 				unsigned long attrs)
 {
 	struct vduse_dev *vdev = dev_to_vduse(dev);
 	struct vduse_iova_domain *domain = vdev->domain;
 
-	return vduse_domain_unmap_page(domain, dma_addr, size, dir, attrs);
+	return vduse_domain_unmap_phys(domain, dma_addr, size, dir, attrs);
 }
 
 static void *vduse_dev_alloc_coherent(struct device *dev, size_t size,
@@ -896,8 +898,8 @@ static size_t vduse_dev_max_mapping_size(struct device *dev)
 static const struct dma_map_ops vduse_dev_dma_ops = {
 	.sync_single_for_device = vduse_dev_sync_single_for_device,
 	.sync_single_for_cpu = vduse_dev_sync_single_for_cpu,
-	.map_page = vduse_dev_map_page,
-	.unmap_page = vduse_dev_unmap_page,
+	.map_phys = vduse_dev_map_phys,
+	.unmap_phys = vduse_dev_unmap_phys,
 	.alloc = vduse_dev_alloc_coherent,
 	.free = vduse_dev_free_coherent,
 	.max_mapping_size = vduse_dev_max_mapping_size,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:03:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:03:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132422.1470818 (Exim 4.92)
	(envelope-from )
	id 1v2svg-0003ee-CB; Sun, 28 Sep 2025 15:03:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132422.1470818; Sun, 28 Sep 2025 15:03: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 1v2svg-0003eS-8m; Sun, 28 Sep 2025 15:03:12 +0000
Received: by outflank-mailman (input) for mailman id 1132422;
 Sun, 28 Sep 2025 15:03: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 1v2sve-0001Mg-PL
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:03:10 +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 3d9570c5-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:03:08 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id DDA3D45F80;
 Sun, 28 Sep 2025 15:03:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19E28C4CEF0;
 Sun, 28 Sep 2025 15:03: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: 3d9570c5-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071786;
	bh=4MEtXfdS28rAh2K80VhDxfAqakr0Nc2oB0/xCEv8vjk=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=MLl/BjLpSDt9SBh2norJcU2F46F/r6g6h87RuQBYkoAGcZPnCd215FCQzpvgxERCA
	 JoAcWDlpaaGMBeilORD02wS46EGf5rRgJdiyxnTdl/dSUOOThvXNKsn2RYd2BOpQtn
	 z6ab9Oz6SBGmGCyKrwpxkOF/E4FINpdFsv5bLV9vRy30LirIChJsKF36dmPdg/bAIF
	 IwPNo8c23EdJkconmObCTIOoESZ2J20hDLi0fpZt7g0Y3Geyi0wHUvkyVUleo7ZhH3
	 UGMgKulTpskho2dGEbm7PUSwJmGYxd5S4PBVSl8pNrZ4ST3LrqqCETAWzyt5QLfi+Q
	 4J6w++XMD0tWg==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 8/9] xen: swiotlb: Convert mapping routine to rely on physical address
Date: Sun, 28 Sep 2025 18:02:28 +0300
Message-ID: <573fbadd743851838a91a8dbc84b4506cea2192c.1759071169.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Switch to .map_phys callback instead of .map_page.

Signed-off-by: Leon Romanovsky 
---
 drivers/xen/grant-dma-ops.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 29257d2639db..7f76e516fe24 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -163,18 +163,22 @@ static void xen_grant_dma_free_pages(struct device *dev, size_t size,
 	xen_grant_dma_free(dev, size, page_to_virt(vaddr), dma_handle, 0);
 }
 
-static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
-					 unsigned long offset, size_t size,
+static dma_addr_t xen_grant_dma_map_phys(struct device *dev, phys_addr_t phys,
+					 size_t size,
 					 enum dma_data_direction dir,
 					 unsigned long attrs)
 {
 	struct xen_grant_dma_data *data;
+	unsigned long offset = offset_in_page(phys);
 	unsigned long dma_offset = xen_offset_in_page(offset),
 			pfn_offset = XEN_PFN_DOWN(offset);
 	unsigned int i, n_pages = XEN_PFN_UP(dma_offset + size);
 	grant_ref_t grant;
 	dma_addr_t dma_handle;
 
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
 	if (WARN_ON(dir == DMA_NONE))
 		return DMA_MAPPING_ERROR;
 
@@ -190,7 +194,7 @@ static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
 
 	for (i = 0; i < n_pages; i++) {
 		gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
-				pfn_to_gfn(page_to_xen_pfn(page) + i + pfn_offset),
+				pfn_to_gfn(page_to_xen_pfn(phys_to_page(phys)) + i + pfn_offset),
 				dir == DMA_TO_DEVICE);
 	}
 
@@ -199,7 +203,7 @@ static dma_addr_t xen_grant_dma_map_page(struct device *dev, struct page *page,
 	return dma_handle;
 }
 
-static void xen_grant_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+static void xen_grant_dma_unmap_phys(struct device *dev, dma_addr_t dma_handle,
 				     size_t size, enum dma_data_direction dir,
 				     unsigned long attrs)
 {
@@ -242,7 +246,7 @@ static void xen_grant_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
 		return;
 
 	for_each_sg(sg, s, nents, i)
-		xen_grant_dma_unmap_page(dev, s->dma_address, sg_dma_len(s), dir,
+		xen_grant_dma_unmap_phys(dev, s->dma_address, sg_dma_len(s), dir,
 				attrs);
 }
 
@@ -257,7 +261,7 @@ static int xen_grant_dma_map_sg(struct device *dev, struct scatterlist *sg,
 		return -EINVAL;
 
 	for_each_sg(sg, s, nents, i) {
-		s->dma_address = xen_grant_dma_map_page(dev, sg_page(s), s->offset,
+		s->dma_address = xen_grant_dma_map_phys(dev, sg_phys(s),
 				s->length, dir, attrs);
 		if (s->dma_address == DMA_MAPPING_ERROR)
 			goto out;
@@ -286,8 +290,8 @@ static const struct dma_map_ops xen_grant_dma_ops = {
 	.free_pages = xen_grant_dma_free_pages,
 	.mmap = dma_common_mmap,
 	.get_sgtable = dma_common_get_sgtable,
-	.map_page = xen_grant_dma_map_page,
-	.unmap_page = xen_grant_dma_unmap_page,
+	.map_phys = xen_grant_dma_map_phys,
+	.unmap_phys = xen_grant_dma_unmap_phys,
 	.map_sg = xen_grant_dma_map_sg,
 	.unmap_sg = xen_grant_dma_unmap_sg,
 	.dma_supported = xen_grant_dma_supported,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:06:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:06:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132481.1470827 (Exim 4.92)
	(envelope-from )
	id 1v2syc-0005rh-4z; Sun, 28 Sep 2025 15:06:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132481.1470827; Sun, 28 Sep 2025 15:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2syc-0005ra-1S; Sun, 28 Sep 2025 15:06:14 +0000
Received: by outflank-mailman (input) for mailman id 1132481;
 Sun, 28 Sep 2025 15: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 1v2svn-0001Mg-8M
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:03: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 42437926-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:03: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 BF484621A8;
 Sun, 28 Sep 2025 15:03:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1811C116C6;
 Sun, 28 Sep 2025 15:03: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: 42437926-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071794;
	bh=Nw/X8vX+8f0l2pbMmARhDnsF0lUGz2K7mDJQIwz58Is=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=FsaEhpyeGH3xgtFa1Y8w5h7Ts5l82ievUD0lfLRGlqV4tl7HVv9bjHbYliznmCWjs
	 XIswOwbrLhL/lqBZDDpgUGa8gdF4R6bcCbJBPSqa9GRkFwHJMd2nGn9jeZAzizyOfu
	 54DTvGsE/K3wvtVyzMCHvcvGz9R9dmQ3OT+/w0ZCM3FzAhtlqzlY+kCeIKxno1O0Od
	 C1Ih5862x6UMYSCAAaLZ2E1CW3M0tASDzvlC2jUWGNlTgPEIUjab8JpmERGcGq50t3
	 CdD1LnfZcH17lDECmZ4j1WinLIfELZhHuaYwgHhdXOlf+ghx9/qq03uAwI9Cvhcn38
	 JtS6nCcss5SzQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 9/9] dma-mapping: remove unused map_page callback
Date: Sun, 28 Sep 2025 18:02:29 +0300
Message-ID: <27727b8ef9b3ad55a3a28f9622a62561c9988335.1759071169.git.leon@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

After conversion of arch code to use physical address mapping,
there are no users of .map_page() and .unmap_page() callbacks,
so let's remove them.

Signed-off-by: Leon Romanovsky 
---
 include/linux/dma-map-ops.h |  7 -------
 kernel/dma/mapping.c        | 12 ------------
 kernel/dma/ops_helpers.c    |  8 +-------
 3 files changed, 1 insertion(+), 26 deletions(-)

diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index a2ec1566aa27..e0a78991fa8a 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -31,13 +31,6 @@ struct dma_map_ops {
 			void *cpu_addr, dma_addr_t dma_addr, size_t size,
 			unsigned long attrs);
 
-	dma_addr_t (*map_page)(struct device *dev, struct page *page,
-			unsigned long offset, size_t size,
-			enum dma_data_direction dir, unsigned long attrs);
-	void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
-			size_t size, enum dma_data_direction dir,
-			unsigned long attrs);
-
 	dma_addr_t (*map_phys)(struct device *dev, phys_addr_t phys,
 			size_t size, enum dma_data_direction dir,
 			unsigned long attrs);
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 32a85bfdf873..37163eb49f9f 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -171,16 +171,6 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
 	else if (ops->map_phys)
 		addr = ops->map_phys(dev, phys, size, dir, attrs);
-	else if (!is_mmio && ops->map_page) {
-		struct page *page = phys_to_page(phys);
-		size_t offset = offset_in_page(phys);
-
-		/*
-		 * The dma_ops API contract for ops->map_page() requires
-		 * kmappable memory.
-		 */
-		addr = ops->map_page(dev, page, offset, size, dir, attrs);
-	}
 
 	if (!is_mmio)
 		kmsan_handle_dma(phys, size, dir);
@@ -222,8 +212,6 @@ void dma_unmap_phys(struct device *dev, dma_addr_t addr, size_t size,
 		iommu_dma_unmap_phys(dev, addr, size, dir, attrs);
 	else if (ops->unmap_phys)
 		ops->unmap_phys(dev, addr, size, dir, attrs);
-	else
-		ops->unmap_page(dev, addr, size, dir, attrs);
 	trace_dma_unmap_phys(dev, addr, size, dir, attrs);
 	debug_dma_unmap_phys(dev, addr, size, dir);
 }
diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
index 1eccbdbc99c1..20caf9cabf69 100644
--- a/kernel/dma/ops_helpers.c
+++ b/kernel/dma/ops_helpers.c
@@ -76,11 +76,8 @@ struct page *dma_common_alloc_pages(struct device *dev, size_t size,
 	if (use_dma_iommu(dev))
 		*dma_handle = iommu_dma_map_phys(dev, phys, size, dir,
 						 DMA_ATTR_SKIP_CPU_SYNC);
-	else if (ops->map_phys)
-		*dma_handle = ops->map_phys(dev, phys, size, dir,
-					    DMA_ATTR_SKIP_CPU_SYNC);
 	else
-		*dma_handle = ops->map_page(dev, page, 0, size, dir,
+		*dma_handle = ops->map_phys(dev, phys, size, dir,
 					    DMA_ATTR_SKIP_CPU_SYNC);
 	if (*dma_handle == DMA_MAPPING_ERROR) {
 		dma_free_contiguous(dev, page, size);
@@ -102,8 +99,5 @@ void dma_common_free_pages(struct device *dev, size_t size, struct page *page,
 	else if (ops->unmap_phys)
 		ops->unmap_phys(dev, dma_handle, size, dir,
 				DMA_ATTR_SKIP_CPU_SYNC);
-	else if (ops->unmap_page)
-		ops->unmap_page(dev, dma_handle, size, dir,
-				DMA_ATTR_SKIP_CPU_SYNC);
 	dma_free_contiguous(dev, page, size);
 }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:06:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:06:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132487.1470838 (Exim 4.92)
	(envelope-from )
	id 1v2syd-00067C-BT; Sun, 28 Sep 2025 15:06:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132487.1470838; Sun, 28 Sep 2025 15:06: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 1v2syd-000670-8D; Sun, 28 Sep 2025 15:06:15 +0000
Received: by outflank-mailman (input) for mailman id 1132487;
 Sun, 28 Sep 2025 15: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 1v2svi-0001Mg-7N
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:03:14 +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 4017fb86-9c7c-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:03: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 12C966219A;
 Sun, 28 Sep 2025 15:03:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01657C4CEF0;
 Sun, 28 Sep 2025 15:03: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: 4017fb86-9c7c-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759071790;
	bh=WDOUet2h6wKH1CUP8FV6nMSpLTCbpgYokkGnWTBO1ug=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=BZGDDUcPv5ei5QmxE/Cb/GBl9Is3jwf+abjfL/T6FlKKDgd7o0SAAJ3DrLeOOxbT2
	 o0ouvmXHTBwdK2d3X69VTKxsccD2N+rDKl2rOOIbofTG0j98oZmecLqLOsDrfi9I1H
	 +jxiGxFnis3M3/StOQO14SMGRRjYxShVKHrZ+0ivygrgODGeAceIKhswn247oAoqzi
	 oGq1ezgkaJlcv65W0NAA1z/YU0H+tvfjhFduVH/BnAlPtpVXNs+BneD71FIxKPdJ+6
	 6XlbC7ZHDc2DVm8WhA5XUVOgjfQFhKz/s+S4IObV34WfPpto4itSg4V0zn2We7HBNA
	 +tD2qMpibdTNQ==
From: Leon Romanovsky 
To: Marek Szyprowski 
Cc: Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand ,
	Helge Deller ,
	Ingo Molnar ,
	iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang ,
	Juergen Gross ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	Magnus Lindholm 
Subject: [PATCH v1 5/9] sparc64: Use physical address DMA mapping
Date: Sun, 28 Sep 2025 18:02:25 +0300
Message-ID: 
X-Mailer: git-send-email 2.51.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Leon Romanovsky 

Convert sparc architecture DMA code to use .map_phys callback.

Signed-off-by: Leon Romanovsky 
---
 arch/sparc/kernel/iommu.c     | 16 ++++++------
 arch/sparc/kernel/pci_sun4v.c | 16 ++++++------
 arch/sparc/mm/io-unit.c       | 13 +++++-----
 arch/sparc/mm/iommu.c         | 46 ++++++++++++++++++-----------------
 4 files changed, 48 insertions(+), 43 deletions(-)

diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c
index da0363692528..288301d2398a 100644
--- a/arch/sparc/kernel/iommu.c
+++ b/arch/sparc/kernel/iommu.c
@@ -260,9 +260,8 @@ static void dma_4u_free_coherent(struct device *dev, size_t size,
 		free_pages((unsigned long)cpu, order);
 }
 
-static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
-				  unsigned long offset, size_t sz,
-				  enum dma_data_direction direction,
+static dma_addr_t dma_4u_map_phys(struct device *dev, phys_addr_t phys,
+				  size_t sz, enum dma_data_direction direction,
 				  unsigned long attrs)
 {
 	struct iommu *iommu;
@@ -273,13 +272,16 @@ static dma_addr_t dma_4u_map_page(struct device *dev, struct page *page,
 	u32 bus_addr, ret;
 	unsigned long iopte_protection;
 
+	if (attrs & DMA_ATTR_MMIO)
+		goto bad_no_ctx;
+
 	iommu = dev->archdata.iommu;
 	strbuf = dev->archdata.stc;
 
 	if (unlikely(direction == DMA_NONE))
 		goto bad_no_ctx;
 
-	oaddr = (unsigned long)(page_address(page) + offset);
+	oaddr = (unsigned long)(phys_to_virt(phys));
 	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
 	npages >>= IO_PAGE_SHIFT;
 
@@ -383,7 +385,7 @@ static void strbuf_flush(struct strbuf *strbuf, struct iommu *iommu,
 		       vaddr, ctx, npages);
 }
 
-static void dma_4u_unmap_page(struct device *dev, dma_addr_t bus_addr,
+static void dma_4u_unmap_phys(struct device *dev, dma_addr_t bus_addr,
 			      size_t sz, enum dma_data_direction direction,
 			      unsigned long attrs)
 {
@@ -753,8 +755,8 @@ static int dma_4u_supported(struct device *dev, u64 device_mask)
 static const struct dma_map_ops sun4u_dma_ops = {
 	.alloc			= dma_4u_alloc_coherent,
 	.free			= dma_4u_free_coherent,
-	.map_page		= dma_4u_map_page,
-	.unmap_page		= dma_4u_unmap_page,
+	.map_phys		= dma_4u_map_phys,
+	.unmap_phys		= dma_4u_unmap_phys,
 	.map_sg			= dma_4u_map_sg,
 	.unmap_sg		= dma_4u_unmap_sg,
 	.sync_single_for_cpu	= dma_4u_sync_single_for_cpu,
diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
index b720b21ccfbd..d9d2464a948c 100644
--- a/arch/sparc/kernel/pci_sun4v.c
+++ b/arch/sparc/kernel/pci_sun4v.c
@@ -352,9 +352,8 @@ static void dma_4v_free_coherent(struct device *dev, size_t size, void *cpu,
 		free_pages((unsigned long)cpu, order);
 }
 
-static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
-				  unsigned long offset, size_t sz,
-				  enum dma_data_direction direction,
+static dma_addr_t dma_4v_map_phys(struct device *dev, phys_addr_t phys,
+				  size_t sz, enum dma_data_direction direction,
 				  unsigned long attrs)
 {
 	struct iommu *iommu;
@@ -367,13 +366,16 @@ static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
 	dma_addr_t bus_addr, ret;
 	long entry;
 
+	if (attrs & DMA_ATTR_MMIO)
+		goto bad;
+
 	iommu = dev->archdata.iommu;
 	atu = iommu->atu;
 
 	if (unlikely(direction == DMA_NONE))
 		goto bad;
 
-	oaddr = (unsigned long)(page_address(page) + offset);
+	oaddr = (unsigned long)(phys_to_virt(phys));
 	npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
 	npages >>= IO_PAGE_SHIFT;
 
@@ -426,7 +428,7 @@ static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
 	return DMA_MAPPING_ERROR;
 }
 
-static void dma_4v_unmap_page(struct device *dev, dma_addr_t bus_addr,
+static void dma_4v_unmap_phys(struct device *dev, dma_addr_t bus_addr,
 			      size_t sz, enum dma_data_direction direction,
 			      unsigned long attrs)
 {
@@ -686,8 +688,8 @@ static int dma_4v_supported(struct device *dev, u64 device_mask)
 static const struct dma_map_ops sun4v_dma_ops = {
 	.alloc				= dma_4v_alloc_coherent,
 	.free				= dma_4v_free_coherent,
-	.map_page			= dma_4v_map_page,
-	.unmap_page			= dma_4v_unmap_page,
+	.map_phys			= dma_4v_map_phys,
+	.unmap_phys			= dma_4v_unmap_phys,
 	.map_sg				= dma_4v_map_sg,
 	.unmap_sg			= dma_4v_unmap_sg,
 	.dma_supported			= dma_4v_supported,
diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c
index d8376f61b4d0..fab303cc3370 100644
--- a/arch/sparc/mm/io-unit.c
+++ b/arch/sparc/mm/io-unit.c
@@ -142,11 +142,10 @@ nexti:	scan = find_next_zero_bit(iounit->bmap, limit, scan);
 	return vaddr;
 }
 
-static dma_addr_t iounit_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t len, enum dma_data_direction dir,
-		unsigned long attrs)
+static dma_addr_t iounit_map_phys(struct device *dev, phys_addr_t phys,
+		size_t len, enum dma_data_direction dir, unsigned long attrs)
 {
-	void *vaddr = page_address(page) + offset;
+	void *vaddr = phys_to_virt(phys);
 	struct iounit_struct *iounit = dev->archdata.iommu;
 	unsigned long ret, flags;
 	
@@ -178,7 +177,7 @@ static int iounit_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
 	return nents;
 }
 
-static void iounit_unmap_page(struct device *dev, dma_addr_t vaddr, size_t len,
+static void iounit_unmap_phys(struct device *dev, dma_addr_t vaddr, size_t len,
 		enum dma_data_direction dir, unsigned long attrs)
 {
 	struct iounit_struct *iounit = dev->archdata.iommu;
@@ -279,8 +278,8 @@ static const struct dma_map_ops iounit_dma_ops = {
 	.alloc			= iounit_alloc,
 	.free			= iounit_free,
 #endif
-	.map_page		= iounit_map_page,
-	.unmap_page		= iounit_unmap_page,
+	.map_phys		= iounit_map_phys,
+	.unmap_phys		= iounit_unmap_phys,
 	.map_sg			= iounit_map_sg,
 	.unmap_sg		= iounit_unmap_sg,
 };
diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c
index 5a5080db800f..dfcd981fa7ef 100644
--- a/arch/sparc/mm/iommu.c
+++ b/arch/sparc/mm/iommu.c
@@ -181,18 +181,20 @@ static void iommu_flush_iotlb(iopte_t *iopte, unsigned int niopte)
 	}
 }
 
-static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
-		unsigned long offset, size_t len, bool per_page_flush)
+static dma_addr_t __sbus_iommu_map_phys(struct device *dev, phys_addr_t paddr,
+		size_t len, bool per_page_flush, unsigned long attrs)
 {
 	struct iommu_struct *iommu = dev->archdata.iommu;
-	phys_addr_t paddr = page_to_phys(page) + offset;
-	unsigned long off = paddr & ~PAGE_MASK;
+	unsigned long off = offset_in_page(paddr);
 	unsigned long npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
 	unsigned long pfn = __phys_to_pfn(paddr);
 	unsigned int busa, busa0;
 	iopte_t *iopte, *iopte0;
 	int ioptex, i;
 
+	if (attrs & DMA_ATTR_MMIO)
+		return DMA_MAPPING_ERROR;
+
 	/* XXX So what is maxphys for us and how do drivers know it? */
 	if (!len || len > 256 * 1024)
 		return DMA_MAPPING_ERROR;
@@ -202,10 +204,10 @@ static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
 	 * XXX Is this a good assumption?
 	 * XXX What if someone else unmaps it here and races us?
 	 */
-	if (per_page_flush && !PageHighMem(page)) {
+	if (per_page_flush && !PhysHighMem(paddr)) {
 		unsigned long vaddr, p;
 
-		vaddr = (unsigned long)page_address(page) + offset;
+		vaddr = (unsigned long)phys_to_virt(paddr);
 		for (p = vaddr & PAGE_MASK; p < vaddr + len; p += PAGE_SIZE)
 			flush_page_for_dma(p);
 	}
@@ -231,19 +233,19 @@ static dma_addr_t __sbus_iommu_map_page(struct device *dev, struct page *page,
 	return busa0 + off;
 }
 
-static dma_addr_t sbus_iommu_map_page_gflush(struct device *dev,
-		struct page *page, unsigned long offset, size_t len,
-		enum dma_data_direction dir, unsigned long attrs)
+static dma_addr_t sbus_iommu_map_phys_gflush(struct device *dev,
+		phys_addr_t phys, size_t len, enum dma_data_direction dir,
+		unsigned long attrs)
 {
 	flush_page_for_dma(0);
-	return __sbus_iommu_map_page(dev, page, offset, len, false);
+	return __sbus_iommu_map_phys(dev, phys, len, false, attrs);
 }
 
-static dma_addr_t sbus_iommu_map_page_pflush(struct device *dev,
-		struct page *page, unsigned long offset, size_t len,
-		enum dma_data_direction dir, unsigned long attrs)
+static dma_addr_t sbus_iommu_map_phys_pflush(struct device *dev,
+		phys_addr_t phys, size_t len, enum dma_data_direction dir,
+		unsigned long attrs)
 {
-	return __sbus_iommu_map_page(dev, page, offset, len, true);
+	return __sbus_iommu_map_phys(dev, phys, len, true, attrs);
 }
 
 static int __sbus_iommu_map_sg(struct device *dev, struct scatterlist *sgl,
@@ -254,8 +256,8 @@ static int __sbus_iommu_map_sg(struct device *dev, struct scatterlist *sgl,
 	int j;
 
 	for_each_sg(sgl, sg, nents, j) {
-		sg->dma_address =__sbus_iommu_map_page(dev, sg_page(sg),
-				sg->offset, sg->length, per_page_flush);
+		sg->dma_address = __sbus_iommu_map_phys(dev, sg_phys(sg),
+				sg->length, per_page_flush, attrs);
 		if (sg->dma_address == DMA_MAPPING_ERROR)
 			return -EIO;
 		sg->dma_length = sg->length;
@@ -277,7 +279,7 @@ static int sbus_iommu_map_sg_pflush(struct device *dev, struct scatterlist *sgl,
 	return __sbus_iommu_map_sg(dev, sgl, nents, dir, attrs, true);
 }
 
-static void sbus_iommu_unmap_page(struct device *dev, dma_addr_t dma_addr,
+static void sbus_iommu_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 		size_t len, enum dma_data_direction dir, unsigned long attrs)
 {
 	struct iommu_struct *iommu = dev->archdata.iommu;
@@ -303,7 +305,7 @@ static void sbus_iommu_unmap_sg(struct device *dev, struct scatterlist *sgl,
 	int i;
 
 	for_each_sg(sgl, sg, nents, i) {
-		sbus_iommu_unmap_page(dev, sg->dma_address, sg->length, dir,
+		sbus_iommu_unmap_phys(dev, sg->dma_address, sg->length, dir,
 				attrs);
 		sg->dma_address = 0x21212121;
 	}
@@ -426,8 +428,8 @@ static const struct dma_map_ops sbus_iommu_dma_gflush_ops = {
 	.alloc			= sbus_iommu_alloc,
 	.free			= sbus_iommu_free,
 #endif
-	.map_page		= sbus_iommu_map_page_gflush,
-	.unmap_page		= sbus_iommu_unmap_page,
+	.map_phys		= sbus_iommu_map_phys_gflush,
+	.unmap_phys		= sbus_iommu_unmap_phys,
 	.map_sg			= sbus_iommu_map_sg_gflush,
 	.unmap_sg		= sbus_iommu_unmap_sg,
 };
@@ -437,8 +439,8 @@ static const struct dma_map_ops sbus_iommu_dma_pflush_ops = {
 	.alloc			= sbus_iommu_alloc,
 	.free			= sbus_iommu_free,
 #endif
-	.map_page		= sbus_iommu_map_page_pflush,
-	.unmap_page		= sbus_iommu_unmap_page,
+	.map_phys		= sbus_iommu_map_phys_pflush,
+	.unmap_phys		= sbus_iommu_unmap_phys,
 	.map_sg			= sbus_iommu_map_sg_pflush,
 	.unmap_sg		= sbus_iommu_unmap_sg,
 };
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:17:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:17:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132516.1470849 (Exim 4.92)
	(envelope-from )
	id 1v2t9e-0008P5-Bu; Sun, 28 Sep 2025 15:17:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132516.1470849; Sun, 28 Sep 2025 15: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 1v2t9e-0008Oy-8B; Sun, 28 Sep 2025 15:17:38 +0000
Received: by outflank-mailman (input) for mailman id 1132516;
 Sun, 28 Sep 2025 15:17:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2t9a-0008Op-Ve
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:17:36 +0000
Received: from mailrelay-egress4.pub.mailoutpod2-cph3.one.com
 (mailrelay-egress4.pub.mailoutpod2-cph3.one.com [2a02:2350:5:403::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f035aab-9c7e-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:17:28 +0200 (CEST)
Received: from ravnborg.org (2-105-16-150-cable.dk.customer.tdc.net
 [2.105.16.150])
 by mailrelay6.pub.mailoutpod2-cph3.one.com (Halon) with ESMTPSA
 id 3c50089e-9c7e-11f0-840e-494313b7f784;
 Sun, 28 Sep 2025 15:17: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: 3f035aab-9c7e-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1759072648; x=1759677448;
	d=ravnborg.org; s=rsa1;
	h=in-reply-to:content-type:mime-version:references:message-id:subject:cc:to:
	 from:date:from;
	bh=/Q5hJNgUVt5SsKvfCGB08N5MVmcUGqA0PZ6u8vFRIRA=;
	b=XDrJz48OIBYo3Q7svVdb5rADtr4uzPeBqjzvjdBidN0feLc/fG5FyC6+FiXnHOkn55ys5B7oUM9TU
	 wNSnamick0obcSvJhF96XXEZuoST1AXGIm/ETF3M+aEeXyHZD/Uy94xCWNukoXKrPvaVVSyuR/mSdp
	 KB96525b2afYqAiKmysXETY5dzfEWAwGX0eJNU7vM+m4GXoo64rXvhOnauh357csMR2l9engULsyz3
	 5PXk1+lrLbhu0QL4HC7CtjxC4UA5AqK0Qya1KK4CYFDrDKU3YZgpLD4h/rFGJ9D+9noDpVHH5zdKCH
	 rr1+z6bhES67FvuiiyDFZXKzWF0+L1g==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1759072648; x=1759677448;
	d=ravnborg.org; s=ed1;
	h=in-reply-to:content-type:mime-version:references:message-id:subject:cc:to:
	 from:date:from;
	bh=/Q5hJNgUVt5SsKvfCGB08N5MVmcUGqA0PZ6u8vFRIRA=;
	b=2W7jKc5o1qHQ2HRmyzqFqhAdPo7FUm8FqIPGGW/HvkJ0QqhXxxc9Hji379Sr1nafpwrNl2oS4qsP7
	 wU9ELx/Ag==
X-HalOne-ID: 3c50089e-9c7e-11f0-840e-494313b7f784
Date: Sun, 28 Sep 2025 17:17:25 +0200
From: Sam Ravnborg 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org, Magnus Lindholm 
Subject: Re: [PATCH v1 9/9] dma-mapping: remove unused map_page callback
Message-ID: <20250928151725.GA135708@ravnborg.org>
References: 
 <27727b8ef9b3ad55a3a28f9622a62561c9988335.1759071169.git.leon@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27727b8ef9b3ad55a3a28f9622a62561c9988335.1759071169.git.leon@kernel.org>

Hi Leon.

On Sun, Sep 28, 2025 at 06:02:29PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky 
> 
> After conversion of arch code to use physical address mapping,
> there are no users of .map_page() and .unmap_page() callbacks,
> so let's remove them.
> 
> Signed-off-by: Leon Romanovsky 
> ---
>  include/linux/dma-map-ops.h |  7 -------
>  kernel/dma/mapping.c        | 12 ------------
>  kernel/dma/ops_helpers.c    |  8 +-------
>  3 files changed, 1 insertion(+), 26 deletions(-)

It looks like you missed a few sparc32 bits:
mm/iommu.c:
static const struct dma_map_ops sbus_iommu_dma_gflush_ops = {
#ifdef CONFIG_SBUS
        .alloc                  = sbus_iommu_alloc,
        .free                   = sbus_iommu_free,
#endif
        .map_page               = sbus_iommu_map_page_gflush,
        .unmap_page             = sbus_iommu_unmap_page,
        .map_sg                 = sbus_iommu_map_sg_gflush,

mm/io-unit.c:
static const struct dma_map_ops iounit_dma_ops = {
#ifdef CONFIG_SBUS
        .alloc                  = iounit_alloc,
        .free                   = iounit_free,
#endif
        .map_page               = iounit_map_page,
        .unmap_page             = iounit_unmap_page,
        .map_sg                 = iounit_map_sg,

I did not compile test, but from a quick look they need to be updated.

	Sam


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:20:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:20:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132527.1470858 (Exim 4.92)
	(envelope-from )
	id 1v2tCV-0001Sd-N7; Sun, 28 Sep 2025 15:20:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132527.1470858; Sun, 28 Sep 2025 15:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2tCV-0001SW-KW; Sun, 28 Sep 2025 15:20:35 +0000
Received: by outflank-mailman (input) for mailman id 1132527;
 Sun, 28 Sep 2025 15:20:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2tCU-0001SQ-4w
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:20:34 +0000
Received: from mailrelay-egress4.pub.mailoutpod2-cph3.one.com
 (mailrelay-egress4.pub.mailoutpod2-cph3.one.com [2a02:2350:5:403::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id acd3cc4d-9c7e-11f0-9d14-b5c5bf9af7f9;
 Sun, 28 Sep 2025 17:20:33 +0200 (CEST)
Received: from ravnborg.org (2-105-16-150-cable.dk.customer.tdc.net
 [2.105.16.150])
 by mailrelay6.pub.mailoutpod2-cph3.one.com (Halon) with ESMTPSA
 id ab2e7cf9-9c7e-11f0-845a-494313b7f784;
 Sun, 28 Sep 2025 15:20: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: acd3cc4d-9c7e-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1759072832; x=1759677632;
	d=ravnborg.org; s=rsa1;
	h=in-reply-to:content-type:mime-version:references:message-id:subject:cc:to:
	 from:date:from;
	bh=Ghyryt2xK5vvnvf4Q2js9Uw55oy6LtaOfQDvQKr1uy0=;
	b=CtT4iU2T9YA3xTrD4cIA+BE+C15rUkNnZplc587YI58g+wt9Z/k8mKxjom62woRw7fEUsvfTw8Ego
	 OORUvh9fiJQumZdtSymONvY5MMtJ3KJXP3zsnj3KxJxk4Oiw+38jzutzIsRmg9a15NqXsODmCWj0BM
	 /EaEWRy/uNU7FXsutNnhv+ixhqzFL2HZhBJwBMscK6dVEUiiXxvphkGrAHhj1qC784KABlOh0D02mA
	 4cLaxB8a5GgAT75FDK3kfCkRHDAAi479jPbM5IFPQLlR8lLKW/rv/Z+yeGIJUaeXNjpvPYpXFP9UyV
	 lTS7L9y3fNmnKV3eKZ72pOl8CYKOBDg==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1759072832; x=1759677632;
	d=ravnborg.org; s=ed1;
	h=in-reply-to:content-type:mime-version:references:message-id:subject:cc:to:
	 from:date:from;
	bh=Ghyryt2xK5vvnvf4Q2js9Uw55oy6LtaOfQDvQKr1uy0=;
	b=J0+KaShsfwnmVbs3PB0EalU1KScQKZ0oCMj0q/S47VSr8rYDdT1FCDrtDwmZlUzToU5sipbu8KD09
	 RgZbdwtBQ==
X-HalOne-ID: ab2e7cf9-9c7e-11f0-845a-494313b7f784
Date: Sun, 28 Sep 2025 17:20:30 +0200
From: Sam Ravnborg 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Leon Romanovsky ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org, Magnus Lindholm 
Subject: Re: [PATCH v1 9/9] dma-mapping: remove unused map_page callback
Message-ID: <20250928152030.GA136019@ravnborg.org>
References: 
 <27727b8ef9b3ad55a3a28f9622a62561c9988335.1759071169.git.leon@kernel.org>
 <20250928151725.GA135708@ravnborg.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250928151725.GA135708@ravnborg.org>

Hi Leon.

On Sun, Sep 28, 2025 at 05:17:25PM +0200, Sam Ravnborg wrote:
> Hi Leon.
> 
> On Sun, Sep 28, 2025 at 06:02:29PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky 
> > 
> > After conversion of arch code to use physical address mapping,
> > there are no users of .map_page() and .unmap_page() callbacks,
> > so let's remove them.
> > 
> > Signed-off-by: Leon Romanovsky 
> > ---
> >  include/linux/dma-map-ops.h |  7 -------
> >  kernel/dma/mapping.c        | 12 ------------
> >  kernel/dma/ops_helpers.c    |  8 +-------
> >  3 files changed, 1 insertion(+), 26 deletions(-)
> 
> It looks like you missed a few sparc32 bits:

They were included, but the patch is named sparc64,
which is why I missed it.

If you could rename the patch that would be nice.

	Sam


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:28:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:28:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132543.1470869 (Exim 4.92)
	(envelope-from )
	id 1v2tKN-0002k8-MA; Sun, 28 Sep 2025 15:28:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132543.1470869; Sun, 28 Sep 2025 15:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2tKN-0002k1-HU; Sun, 28 Sep 2025 15:28:43 +0000
Received: by outflank-mailman (input) for mailman id 1132543;
 Sun, 28 Sep 2025 15:28: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 1v2tKM-0002jv-Dx
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:28:42 +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 cd08b0f3-9c7f-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:28:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 756A46218E;
 Sun, 28 Sep 2025 15:28:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D567C4CEF0;
 Sun, 28 Sep 2025 15:28: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: cd08b0f3-9c7f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759073315;
	bh=j3dJ7dm9Jex7hj7zDSOs/rnehFATrVSGsSj9oi0KREM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=f1YhjVPKUf7C/0/LxXAZBncp5RteetEhwJWXFm/vEFPUulFmvL8IxH077S1rMLJtr
	 d2ZgZgVpCx6rd1totAk5q+h7xqPmOOTtzW5w30YaKisVYvwJq5gRqIDGRHY5T/f4gQ
	 O0PYgjbB/cH7oJ1jFPBNLr3rGkOI2qMk/87YL11RjncJuK6Qjt9VPe0h+TqS18yZyA
	 BZqpYFUKRf23DvC6/+sd1BLnzDDD/hXAh8aUEZqIXh4WqdIZHr4zt3c9wvIaaQFzw4
	 UZD9hcw+AzQFsbXJe27so0nVBzGtUu2qhqiGBcZy6B5qFDuhtL/1hVaC8gTpWufr4a
	 sdkGg8+AkSuEw==
Date: Sun, 28 Sep 2025 18:28:30 +0300
From: Leon Romanovsky 
To: Sam Ravnborg 
Cc: Marek Szyprowski ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org, Magnus Lindholm 
Subject: Re: [PATCH v1 9/9] dma-mapping: remove unused map_page callback
Message-ID: <20250928152830.GA324804@unreal>
References: 
 <27727b8ef9b3ad55a3a28f9622a62561c9988335.1759071169.git.leon@kernel.org>
 <20250928151725.GA135708@ravnborg.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250928151725.GA135708@ravnborg.org>

On Sun, Sep 28, 2025 at 05:17:25PM +0200, Sam Ravnborg wrote:
> Hi Leon.
> 
> On Sun, Sep 28, 2025 at 06:02:29PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky 
> > 
> > After conversion of arch code to use physical address mapping,
> > there are no users of .map_page() and .unmap_page() callbacks,
> > so let's remove them.
> > 
> > Signed-off-by: Leon Romanovsky 
> > ---
> >  include/linux/dma-map-ops.h |  7 -------
> >  kernel/dma/mapping.c        | 12 ------------
> >  kernel/dma/ops_helpers.c    |  8 +-------
> >  3 files changed, 1 insertion(+), 26 deletions(-)
> 
> It looks like you missed a few sparc32 bits:
> mm/iommu.c:
> static const struct dma_map_ops sbus_iommu_dma_gflush_ops = {
> #ifdef CONFIG_SBUS
>         .alloc                  = sbus_iommu_alloc,
>         .free                   = sbus_iommu_free,
> #endif
>         .map_page               = sbus_iommu_map_page_gflush,
>         .unmap_page             = sbus_iommu_unmap_page,
>         .map_sg                 = sbus_iommu_map_sg_gflush,
> 
> mm/io-unit.c:
> static const struct dma_map_ops iounit_dma_ops = {
> #ifdef CONFIG_SBUS
>         .alloc                  = iounit_alloc,
>         .free                   = iounit_free,
> #endif
>         .map_page               = iounit_map_page,
>         .unmap_page             = iounit_unmap_page,
>         .map_sg                 = iounit_map_sg,
> 
> I did not compile test, but from a quick look they need to be updated.

There were updated, see patch #5.
https://lore.kernel.org/all/bac909dab3c82fc6a7a4f5a31f22bac9a69f7f07.1759071169.git.leon@kernel.org/T/#u

arch/sparc/mm/iommu.c:
  426 static const struct dma_map_ops sbus_iommu_dma_gflush_ops = {
  427 #ifdef CONFIG_SBUS
  428         .alloc                  = sbus_iommu_alloc,
  429         .free                   = sbus_iommu_free,
  430 #endif
  431         .map_phys               = sbus_iommu_map_phys_gflush,
  432         .unmap_phys             = sbus_iommu_unmap_phys,
  433         .map_sg                 = sbus_iommu_map_sg_gflush,
  434         .unmap_sg               = sbus_iommu_unmap_sg,
  435 };

arch/sparc/mm/io-unit.c:
  276 static const struct dma_map_ops iounit_dma_ops = {
  277 #ifdef CONFIG_SBUS
  278         .alloc                  = iounit_alloc,
  279         .free                   = iounit_free,
  280 #endif
  281         .map_phys               = iounit_map_phys,
  282         .unmap_phys             = iounit_unmap_phys,
  283         .map_sg                 = iounit_map_sg,
  284         .unmap_sg               = iounit_unmap_sg,
  285 };

Thanks

> 
> 	Sam
> 


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 15:31:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 15:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132554.1470878 (Exim 4.92)
	(envelope-from )
	id 1v2tMm-0004De-0Q; Sun, 28 Sep 2025 15:31:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132554.1470878; Sun, 28 Sep 2025 15:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2tMl-0004DX-TV; Sun, 28 Sep 2025 15:31:11 +0000
Received: by outflank-mailman (input) for mailman id 1132554;
 Sun, 28 Sep 2025 15:31:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v2tMk-0004DR-Ft
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 15:31:10 +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 2763bed2-9c80-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 17:31: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 7AB1A6218F;
 Sun, 28 Sep 2025 15:31:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33FAEC4CEF5;
 Sun, 28 Sep 2025 15:31: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: 2763bed2-9c80-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759073467;
	bh=lGCIsTrsyWZ8QOPIKq8I5fg/cOuQCrmM7ZcLWOcdn9Q=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=o16pSV0PpKM0QT5VYemmYPv3rNvw+gxL11Fj3yidIo2Gut35r6WcPhG9ZUyHgf10N
	 HDoUvAriBjQKKzLaUqSq/NvZQviTbP6Clkx6YJlm8tmGye4n+XchUKfL6k9zPTRZMV
	 TDipWjxyMkDPns3af7oj7M+e1Jre+95S/Gx9tN+Vm4PlrusP/lU9slnofDh6/ZsSSX
	 kT5XAqaDTqgR+UVNQA8g7H75XmRpBDadQzy2MAo6TwB1QXQn4VdvPL1TspAL2PuX9a
	 zblg3faGha9PBO5W1YWwMCeUXrGEmQnur9K8XOOjy19L+pJZmPK1bf0y+sm4i/+kU3
	 fsu9L2JRJahmg==
Date: Sun, 28 Sep 2025 18:31:03 +0300
From: Leon Romanovsky 
To: Sam Ravnborg 
Cc: Marek Szyprowski ,
	Jason Gunthorpe ,
	Andreas Larsson ,
	Borislav Petkov ,
	Dave Hansen ,
	"David S. Miller" ,
	Geoff Levand , Helge Deller ,
	Ingo Molnar , iommu@lists.linux.dev,
	"James E.J. Bottomley" ,
	Jason Wang , Juergen Gross ,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan ,
	Matt Turner ,
	Michael Ellerman ,
	"Michael S. Tsirkin" ,
	Richard Henderson ,
	sparclinux@vger.kernel.org,
	Stefano Stabellini ,
	Thomas Bogendoerfer ,
	Thomas Gleixner ,
	virtualization@lists.linux.dev, x86@kernel.org,
	xen-devel@lists.xenproject.org, Magnus Lindholm 
Subject: Re: [PATCH v1 9/9] dma-mapping: remove unused map_page callback
Message-ID: <20250928153103.GB324804@unreal>
References: 
 <27727b8ef9b3ad55a3a28f9622a62561c9988335.1759071169.git.leon@kernel.org>
 <20250928151725.GA135708@ravnborg.org>
 <20250928152030.GA136019@ravnborg.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250928152030.GA136019@ravnborg.org>

On Sun, Sep 28, 2025 at 05:20:30PM +0200, Sam Ravnborg wrote:
> Hi Leon.
> 
> On Sun, Sep 28, 2025 at 05:17:25PM +0200, Sam Ravnborg wrote:
> > Hi Leon.
> > 
> > On Sun, Sep 28, 2025 at 06:02:29PM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky 
> > > 
> > > After conversion of arch code to use physical address mapping,
> > > there are no users of .map_page() and .unmap_page() callbacks,
> > > so let's remove them.
> > > 
> > > Signed-off-by: Leon Romanovsky 
> > > ---
> > >  include/linux/dma-map-ops.h |  7 -------
> > >  kernel/dma/mapping.c        | 12 ------------
> > >  kernel/dma/ops_helpers.c    |  8 +-------
> > >  3 files changed, 1 insertion(+), 26 deletions(-)
> > 
> > It looks like you missed a few sparc32 bits:
> 
> They were included, but the patch is named sparc64,
> which is why I missed it.
> 
> If you could rename the patch that would be nice.

Let's see if new version is required.

Thanks

> 
> 	Sam
> 


From xen-devel-bounces@lists.xenproject.org Sun Sep 28 17:36:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Sep 2025 17:36:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132574.1470888 (Exim 4.92)
	(envelope-from )
	id 1v2vJX-0004HX-Kj; Sun, 28 Sep 2025 17:35:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132574.1470888; Sun, 28 Sep 2025 17:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v2vJX-0004HQ-Hs; Sun, 28 Sep 2025 17:35:59 +0000
Received: by outflank-mailman (input) for mailman id 1132574;
 Sun, 28 Sep 2025 17:35: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 1v2vJW-0004HK-3f
 for xen-devel@lists.xenproject.org; Sun, 28 Sep 2025 17:35:58 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9685dbbe-9c91-11f0-9809-7dc792cee155;
 Sun, 28 Sep 2025 19:35:55 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-63486ff378cso7507342a12.0
 for ; Sun, 28 Sep 2025 10:35: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: 9685dbbe-9c91-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759080955; x=1759685755; 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=1hWHgpM/rb70qd87juqmeSrMZFHqG1itquQCJwHGhEk=;
        b=hlsddbpyNfLLmj7YNhTzNdAKO6BZXIszw5PNeP3OHtfnxwwCRNwlaY13U0KKcOlETq
         qE8/B2xCfr8YU7RmfHyCgvQXsRsxwLVDarDBTzD7qZN2LlJtSc2U2KMnIQPNhQeumR0F
         cYHqH7Plx+OnWekLvN7tVyit11DwPw0RJE6dDkBaARIrVIB5jTWTnlXKFPxFTgDYZL1/
         bVd9Dh/aa+aHZlfGIltbHZ78CGUiQDAwmi7nvl+PxpAImhBkONcT25x2E/cznRzf32Gw
         07X27D3xDCyhcW9JUECaw6dxdAke9df/QrbstW78NY5X5Tznjmf/Z3KjLUYulYa51Im4
         3SWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759080955; x=1759685755;
        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=1hWHgpM/rb70qd87juqmeSrMZFHqG1itquQCJwHGhEk=;
        b=CuEmESGrq62/EC8BPeuoz2I+ZeLRjrU6iu8mFyL6gAtqqcBI/si4GqEOfoLnZnKCF2
         53cLx8tITMRYJsfABJO0Ld1UOrGcTuOWP6HQUXArJ7Db5anvQFf2QwbUICnjRL8ViwdQ
         WLAlJadnSFbY25TOrjqjgZ3F+8650mI1ujPhNGWrp1XvGCYB2oWJsnsrLNmeHpQX2UKT
         QCp1AXTa86Hl5zpgWDOxPrKrtefI0AVS0VCUL2Xo7QpvXC/onn0ux9L26mmvhKM7XF8P
         +1qxZ5iFW04OReW3oeOb/Udsi2JF/t9GNHbEATf7OLlANaAWY94SEiee9BEd9BXAjGBn
         s1XA==
X-Forwarded-Encrypted: i=1; AJvYcCW6l35BY+fHJT8VL6PvzA2hNM1w9WOssvAM5auMfqZdof99YJXnk2VzUgP1HtpgfWkJ7Pggm8FsqEo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNIpGkcr5Ujd11yTMaVrEPfWs9wGD12pVZm+zVey4fxfp9YwSk
	p2IThXl6up9O67f4ng8jgaraq2wpO8bHrntpyaDWHw1Qln8Nqqsc/Ql1M+HtOURJbAuPPwTUeJP
	W5e7ppFAAzcr88kWEShijqkCNnFYdRNE=
X-Gm-Gg: ASbGncuq/xpNcFC2wWelKBr/OQIGP0mbRNNbYx/2Mf2cRPNVDC2TUUpwJTiCNsNmyus
	K010lDC8EZoiwnw/KoDmxz7yy88V9R1MG61D3u9OLl+K/gNmfOa9Jz5vt47zkBS6xAta2dt49+y
	U1aPpdlR2urWHWxZUGd6W8HN1zIrdQY4wpQ2BC3ZbrmrW0PLl4rvU5gGpcn/fVzcaKGQKsZk5om
	Bp5NQCsN8uFDKXULHA=
X-Google-Smtp-Source: AGHT+IF4LtUw7v9U/JYoQT0Wh7nzvSFhJ3UqproTerTY3SiJCa0Vl/rRvk3JMudUZqWnlv9RN4X9SRqdzNlv4OAcKN8=
X-Received: by 2002:a05:6402:352:b0:62f:453c:7235 with SMTP id
 4fb4d7f45d1cf-634ce845b9amr4127811a12.15.1759080955040; Sun, 28 Sep 2025
 10:35:55 -0700 (PDT)
MIME-Version: 1.0
References:  <512d4c498103fcfccd8c60ce1982cd961434d30b.1759071169.git.leon@kernel.org>
In-Reply-To: <512d4c498103fcfccd8c60ce1982cd961434d30b.1759071169.git.leon@kernel.org>
From: Magnus Lindholm 
Date: Sun, 28 Sep 2025 19:35:43 +0200
X-Gm-Features: AS18NWBtQV3w4fhUJT0qJjc42RZ2Y4lnsCSX8_2AFcicJQutzVlCWs2uQTVZ_oE
Message-ID: 
Subject: Re: [PATCH v1 1/9] alpha: Convert mapping routine to rely on physical address
To: Leon Romanovsky 
Cc: Marek Szyprowski , Leon Romanovsky , 
	Jason Gunthorpe , Andreas Larsson , Borislav Petkov , 
	Dave Hansen , "David S. Miller" , 
	Geoff Levand , Helge Deller , Ingo Molnar , 
	iommu@lists.linux.dev, 
	"James E.J. Bottomley" , Jason Wang , 
	Juergen Gross , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , 
	Matt Turner , Michael Ellerman , 
	"Michael S. Tsirkin" , Richard Henderson , 
	sparclinux@vger.kernel.org, Stefano Stabellini , 
	Thomas Bogendoerfer , Thomas Gleixner , 
	virtualization@lists.linux.dev, x86@kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 28, 2025 at 5:02=E2=80=AFPM Leon Romanovsky  w=
rote:
>
> From: Leon Romanovsky 
>
> Alpha doesn't need struct *page and can perform mapping based on
> physical addresses. So convert it to implement new .map_phys callback.
>
> As part of this change, remove useless BUG_ON() as DMA mapping layer
> ensures that right direction is provided.

After the changes in v1 this runs fine on Alpha. I've tested this on an
ES40 Alphaserver during load (build kernel and unpack tar files).
The v1 patch fixes the errors seen in the first revision of this patch.

Tested-by: Magnus Lindholm 


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 08:42:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 08:42:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132631.1470897 (Exim 4.92)
	(envelope-from )
	id 1v39T1-0005nm-VS; Mon, 29 Sep 2025 08:42:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132631.1470897; Mon, 29 Sep 2025 08: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 1v39T1-0005nf-SU; Mon, 29 Sep 2025 08:42:43 +0000
Received: by outflank-mailman (input) for mailman id 1132631;
 Mon, 29 Sep 2025 08:42: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 1v39T0-0005nZ-KY
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 08:42:42 +0000
Received: from PH8PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170120001.outbound.protection.outlook.com
 [2a01:111:f403:c107::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 41c12e05-9d10-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 10:42:40 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by CH5PR03MB7814.namprd03.prod.outlook.com (2603:10b6:610:213::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Mon, 29 Sep
 2025 08:42:37 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 08:42: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: 41c12e05-9d10-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=V4E5zaPME3bltlF7dUObGPbHUAcPq8dCdCkzCJY9OhRN5ZkWINBM/gvl+Uqy9K1bl/6P0bBRf9/R6Pe2KEg8Q/qN0o2qO6SUK3q6ITAeG4wjX/K+pWH8GynQWy4HYG4HzrtDu8usynWt8hY7IUL169bEMryb9p3yOclqshyciJYC85Xd/effgiVe3mHQ16FftVS8jCwPT7jhyYsDOueUPIOgxhFwn+Dj45PfynlFzKccbzryZmpItmBjWF/uOQXSxXN+88y6QnNofSpx/YJpeJqtXoUHFWUzOCYCUJb9s2kpfwb0mxT034Sjn2E35kUk8hhu3zAwlSjQ6gMmHZK1jQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JkP8vxyU157c6Jk9+NLX/UXEx2hKaJu27EL6ycjAjIQ=;
 b=D2BKWhOHX6BZlOk4ie19XiyUNA6Tbk70wKPEVUr+/Tsv539BUvmt027Enj/LH+FaC/HiGwXc2aQEETLhVplyZjFhRmwi3mr4uWfFg670LstN0Z/8iZIFBfuvjI/CRxu/pP7TsWQfIf9nggvxEYr0ySp6H4SZYnpBvlwuuUJoVEtCIcT2EzK8yLvGGtXZ8Vh8uLxvRehx8oChA10DYICwcx3MfjibWWevry+fkACthaOtaU+gvzvUJKAtvGqTqukd0UcyoKxBftKF5Xq9MtfFjkAQBcbhWv7VTnLYWS8sRjZqNbgTxE0WPlr8X3tfIwFKzUgbXt4lyXgwRN1ERMscRA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JkP8vxyU157c6Jk9+NLX/UXEx2hKaJu27EL6ycjAjIQ=;
 b=VGF2/Ug6oxo9Y/cOWILukoRo0J2IKrQCSXPknU2acHNY5niIsmh6wz4iZAeRqme9wvHpYGQjSkh+XvSEUfRgq9svXkCL+EHcXJQ+iCOl0gnTa/rifOE9QOBrXh4EmiBjBRQNBGXFFYGej/yfDB4/5pjMERIjWl0zKWq4hz2FHOY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stewart Hildebrand ,
	Jan Beulich ,
	Oleksii Kurochko 
Subject: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X capabilities
Date: Mon, 29 Sep 2025 10:41:49 +0200
Message-ID: <20250929084149.70560-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.51.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: MA4P292CA0009.ESPP292.PROD.OUTLOOK.COM
 (2603:10a6:250:2d::6) To DM6PR03MB5227.namprd03.prod.outlook.com
 (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|CH5PR03MB7814:EE_
X-MS-Office365-Filtering-Correlation-Id: f32c3a1e-788d-4071-c825-08ddff34240d
X-LD-Processed: 335836de-42ef-43a2-b145-348c2ee9ca5b,ExtFwd
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?ek40TlJneWV5d09nYW9VOTZiaVRxUC9od1RKMzdpdEQxQ1RVREZmaVB5UzdL?=
 =?utf-8?B?c1RhdmtEaUc1WWZPc2R1ZWVhdEp6THROcjNtUm9ncjZNZkI0U3FIWWM2MDlv?=
 =?utf-8?B?R1gvV0pzcStWTGpjV3hVU3l6T3VXcEE1OTFYdVd5M3FoN1NTangzYlZwUGJE?=
 =?utf-8?B?b0RxSDFDTVdrL1lycUtndDhvVExEaEJabUduYlB2ZDB1Y20wOEErMXBkUEF5?=
 =?utf-8?B?N0svbUhxdjA0d1cxZThkL0hOR2tMYmdUVVF2c0ZHR295blFxdFRlUVpPSTJJ?=
 =?utf-8?B?MzZFb0h2RkVjRjBvQ2M1WWFTMk1YbHg0S2tnMzVuMnVKNXlEbUZKcHluWFlo?=
 =?utf-8?B?eU9XWm5GVFBZZkg1M203WGg5T0QxQnFlcjNNQkk2cVZYUCs4RUR4T3NucW1D?=
 =?utf-8?B?bWZGUExIYW9DajFSK3hjRmZSLy9hcHBiYzJNeWVVL3piVFFoaVZWb0hnUG9z?=
 =?utf-8?B?S0pzMjNmMzNCL1o0aURobkxhTFBIdDFnSmxQT3JsbkpWRGtyN3NDaWF2aE5U?=
 =?utf-8?B?NENMcndRaGxoMUsyd2c4TVovZXpsUTllUytla3Zub3UwNFZ6VjNweGFmckhj?=
 =?utf-8?B?U1M1SWEwWmkzZmFkREVOT0x2K2sweUdmWE5LdEwrTnJWdmhab0oxYm54OXRk?=
 =?utf-8?B?VTJLMDdpQ0ozcVFETStveHoxWlJvajFqQmprZHdnL1pFNnZ4SCtDQ2hzd3E2?=
 =?utf-8?B?MkJpT3lKeXFFa3pDaWVjUzdJK3N2Nkx0aStsSCtuMHZSckI0UFBBY0N2Ni9x?=
 =?utf-8?B?Q0d1djRZbTQ3Rjg3UHd0VXdMRDR5MHZudzNIc1dzN2xpUXdwN25ML3pTU3ZP?=
 =?utf-8?B?ckhTSkNuNjZPRWlhSUdkSFgwMWR5OURKRU45cU5PTWtxYmQ3QXdaNXpJbXpT?=
 =?utf-8?B?YVhKS2Q1MzZtWENoWGZPckpxaWJYZUJOVFZCN0s3ajExTWNHZlJ2dGFXdS9l?=
 =?utf-8?B?cmMyODNRN2dUczN1bllqbzdMakVFQ2h1MXVnMGF3ZUozYzkvTjN0eEJqbkh1?=
 =?utf-8?B?ejJ5SXA0WGNxZjJIWElxTFBZZE83aTYrcHFvUkZ5djk3Yi9UYThMVi9nWHl6?=
 =?utf-8?B?bXhON20rVjU1MHQwR2IremdLREd4WlhtZGdrZjV5eTdzdnZ5YVlaajB0bGVO?=
 =?utf-8?B?dWY2ZktFSElvc0JBbXJpeVZhc1lGNjhQeUhYOTNpT3pmUkZkaVM0S3pyeU1y?=
 =?utf-8?B?TUFleXBEY25oS1pzZWhkZWUybm5idllTU2M5djQ5aHlzK0ZQbE1IajB2S1M3?=
 =?utf-8?B?TUtaRXF2djU4MnQvME9pY0xWelVGaU5NSlFkd0ljVzFmdU9UYWZ5eWZob01M?=
 =?utf-8?B?K21lM01FV3ZMMkpIVjc4c3g3bUYxdEl5QmVYdlY1V3l1SzN3L0FjeTJGWWZJ?=
 =?utf-8?B?REthVjR1YVlNTU9qRG5pdG1jbFpMbmpHTEZsMWRXMmZqd2F6M0IrZmFMZ0pW?=
 =?utf-8?B?VEhPa3o5bDJjV1EvSm9HYyt3aldkM2V6UWYzSndxL0htckN3SnVLY1ZvT1pV?=
 =?utf-8?B?cndnWWNQL0xQUFRHK2FZS1U3Y0hMZkhoTzVJTDY2cHNPTzZENUlkVUM0YlJw?=
 =?utf-8?B?NytLNGdmVGR2N3dieFd1K3EvaW9NcE5VdlRXMEdYZDdiOWlEWVNMd3FkTjJn?=
 =?utf-8?B?YnU5SGhEZnBhZ1haeHlIanZVVnhRNlVSZFpRREpNbmNmRi8vY2J2YVRhU09n?=
 =?utf-8?B?UzFjQUhGeDhOZlRTaUYzTmR1anJGcUtwMVc3TkdRMzJSS01ubmNFZGRiZHN1?=
 =?utf-8?B?VEQ4eGFJcXdjRmNKN3hvOTNCQUUzV2pYd3U3SWlIblFaY2Mrc1FKdnk1c0hk?=
 =?utf-8?B?MGJMejZ4Tm8xaW8vWjBQUEZjenpIbGpUdUk4OTlQVEIyR1lOaXhUc21vRmNr?=
 =?utf-8?B?V1VhdXVRT0gyS1pJTEZiSkU4ZTFBMTBQQTZTVEhrSFZ2TTQwWk5ZRG14Lytv?=
 =?utf-8?Q?PJtkYlDryEZ+Dx1qyOKnt4uI84cL1Dfp?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZjlSRUhxbjV6a255M21hcTNXYkZLVHdTZDNhQ2RiUTl1R1RoQmpRaXZXMkp5?=
 =?utf-8?B?bkFVZzRqMTkwdDlxaFh2T2FNcXVRS1UvNWhaNjV4dUJXR2FHYzlTeGxHWTJt?=
 =?utf-8?B?TFl3Z3BMK2taM0wrWE00T0hGVlVhNjRIQkY4VUhhWXI0V2tYYlI3QXVEU05r?=
 =?utf-8?B?U3NIMDN2TnlTMkhab0ttYW1CQmpVWUU3T0xhVEdZU21pbkFSVE9YU2xoUHdh?=
 =?utf-8?B?NXQrVVVsd0NLb1J5RldzalFiclQ1NjlJNkFGQ250bW5IZVlOSnFBZ21TNmxs?=
 =?utf-8?B?TmsrWFY0dzZ3SHJjTXFQS3lsbXc0VHV6NmdkUlZpa2QxUFgvT1ZLdDVWdEU3?=
 =?utf-8?B?dzFiMVZ4N1A4TkhHMG5pN1pyakk1cUJsRzJSdmRPcmhXY2lsbVZoZ0RFYWtE?=
 =?utf-8?B?NU1RNWZVR0wwM2ZSb0l5aU9UWGVJaXQyd2IyQk1kSGhxUkR2d1ZUeEdUWWkz?=
 =?utf-8?B?R1Zad3ZhQ282dW9sS2tWRHlKR1B0bVkybG42THVmSU9XTEZteVpxSUI5bHJT?=
 =?utf-8?B?dlBDU2o2VS80VFk3a1VFdmV1VG9odkRqMzRJK0phTlVTSUtZR09aN0R5SjNQ?=
 =?utf-8?B?U0cxbmJTd25PbWYvbjhJNzZmRzNEVkF6RlhJS2x2SS9aWmJlNjNoUUNEOWN4?=
 =?utf-8?B?ZHIrRitxMnlHbDdRWEw4RWtTTmN5ODJ5VGpBUC9PZklNd3BVK0ljMlJxUDdQ?=
 =?utf-8?B?U0EwVFdSOXFVZDVERjhUWTErKzVJTmRuVTRVUVgrRVhTeXJLcTYwb3UrWFFU?=
 =?utf-8?B?S04rQUdleUlyN0k5YnMwUFRsZXU0M0xHdkRnN1lpRUlhSWM4UTNGR2tZcDBh?=
 =?utf-8?B?c2dDcE5xMHNPZDBZcUpKS3Q4TFZRZWl4cE9sZndOZ1Q3dTFJanVMdmRRc0l4?=
 =?utf-8?B?ekpETy9zMlZCY0NrbGRhZmd3SjFmZlFxNVN4TS9HRVJrQlc2eS9FV29jRWls?=
 =?utf-8?B?ZnR1L21FOGcvRzI5ZVdCNGVhbUZCSXpoZ3Z1c0RDb0Fsd010N3AyZmVKbFU3?=
 =?utf-8?B?UHdEbWxPYlFtUndGVzNQbnl5c3NiWi9pVkJnUDhnbjNKeU5iQjl1bGcyZExl?=
 =?utf-8?B?aDZrK3pibE1OdDR1eGZiNkdLMU81cjVzYUUzRFlwY0JkSkY3RVcxZnN4dUhI?=
 =?utf-8?B?TlVlK3UxQmtlZ0VsVVRCL01FTFg1U0NwcmxMcWJEMmlxQUQxL0k2emFtRm40?=
 =?utf-8?B?b3A5TGYrUWRVVXI2eXByZnFaRkZMS3ROZHovbm1sYkR2WFdWcGxNN1JKa0pM?=
 =?utf-8?B?N1cvQ1hSQzdnR3Q4YWEyKzZUcUZxcW5VUWMvcHBLTHBZdlUweU5QNnp2TUNh?=
 =?utf-8?B?MGJXY3B2NVpMczBRQ3V1Y0dqcCs4eURsWjRGQ1FDUWxGTTE3alVXSU9pdjNE?=
 =?utf-8?B?eEFBbDdLcUNqY09DdElvMWtqWnU5RWJrbjcyakRsclhPeW9HOEpZeDlTbnRX?=
 =?utf-8?B?NDMvODRVTzBVZ3NZbklWaXliY3lsRll4VC9zRTNONjNTQmM5bTJYSTE0UlNJ?=
 =?utf-8?B?Znc0YnNTVkFEUWxFbWp0cjRqcTI4dGp3SVl5NVJXR2x4ZWJ4YStienlPNzRY?=
 =?utf-8?B?L0duTnk2WCs3Z3BSYzVXRnNEYzJudlRvaWl2UFUvRUs1cEE2cjRJL0dqVXp2?=
 =?utf-8?B?LzZWMnBzRiszTE1VZ2JZT3lvdlFvWTdvM2FiYWpIRjI3Zm9wUys0SERaeTBM?=
 =?utf-8?B?R1ZJTXVmeHpiblhvSm1GN09EaFB0aEJiRDhwMTlqRm1ORWQ1Mk9IbjFPVkMw?=
 =?utf-8?B?cHdkczdKUFZNYVV5aWdMK2ZnZ0Z3N25aN0pycVJEQmhYN2lNb085WTVoQUJZ?=
 =?utf-8?B?SXd1QXIvbHY5YXpxZ1ZjQ2p2bXZmQkM2RjhqVnRwbURXNnlHM2ZCVGFOVHZR?=
 =?utf-8?B?Z0JGUFdudk1kSCsranNmbzQ5Nk1UbXNUUkFxaWxaZFNndHlOcW1uTDZObmpy?=
 =?utf-8?B?Zm5SMGxUSmUxM0Y3bGRnSWc3OGF3UUwveEg1NlJlOElaN3RmYUgxdStXNUxq?=
 =?utf-8?B?bGprZGpNU0Q0NFZ5ZGVCWXFJdGQrSnlJQzdRSlU1M2F1c0lJL0pXVWo1Z2Fm?=
 =?utf-8?B?VWFOOURGQ0RrOVJIdUpmN0lKTW1LZHJreC95bGFaMkdJZjJLbExERXNOd0o4?=
 =?utf-8?Q?4FfO9e6nOYvN2SUS3ENxS/6bD?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f32c3a1e-788d-4071-c825-08ddff34240d
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2025 08:42:36.8585
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: W9nggHvMQdAjf8T6xsiqYhslRBIjPOwlch0jFWH0i0+OdgwK8Jsewp/ojEFNNZnLdwFFYiBnFT7ekXNa3OFEag==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7814

I've had the luck to come across a PCI card that exposes a MSI-X capability
where the BIR of the vector and PBA tables points at a BAR that has 0 size.

This doesn't play nice with the code in vpci_make_msix_hole(), as it would
still use the address of such empty BAR (0) and attempt to crave a hole in
the p2m.  This leads to errors like the one below being reported by Xen:

d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area

And the device left unable to enable memory decoding due to the failure
reported by vpci_make_msix_hole().

Introduce checking in init_msix() to ensure the BARs containing the MSI-X
tables are usable.  This requires checking that the BIR points to a
non-empty BAR, and the offset and size of the MSI-X tables can fit in the
target BAR.

This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
EPYC 9965 processors.  The broken device is:

22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)

There are multiple of those integrated controllers in the system, all
broken in the same way.

Signed-off-by: Roger Pau Monné 
---
Cc: Stewart Hildebrand 
Cc: Jan Beulich 
Cc: Oleksii Kurochko 

While not strictly a bugfix, I consider this a worthy improvement so that
PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
capabilities.  Hence I think this change should be considered for inclusion
into 4.21.  There a risk of regressing on hardware that was already working
with PVH, but given enough testing that should be minimal.
---
 xen/drivers/vpci/msix.c | 50 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 54a5070733aa..8458955d5bbb 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -675,6 +675,51 @@ static int cf_check init_msix(struct pci_dev *pdev)
     if ( !msix )
         return -ENOMEM;
 
+    msix->tables[VPCI_MSIX_TABLE] =
+        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
+    msix->tables[VPCI_MSIX_PBA] =
+        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
+
+    /* Check that the provided BAR is valid. */
+    for ( i = 0; i < ARRAY_SIZE(msix->tables); i++ )
+    {
+        const char *name = (i == VPCI_MSIX_TABLE) ? "vector" : "PBA";
+        const struct vpci_bar *bars = pdev->vpci->header.bars;
+        unsigned int bir = msix->tables[i] & PCI_MSIX_BIRMASK;
+        unsigned int type;
+        unsigned int offset = msix->tables[i] & ~PCI_MSIX_BIRMASK;
+        unsigned int size =
+            (i == VPCI_MSIX_TABLE) ? max_entries * PCI_MSIX_ENTRY_SIZE
+                                   : ROUNDUP(DIV_ROUND_UP(max_entries, 8), 8);
+
+        if ( bir >= ARRAY_SIZE(pdev->vpci->header.bars) )
+        {
+            printk(XENLOG_ERR "%pp: MSI-X %s table with out of range BIR %u\n",
+                   &pdev->sbdf, name, bir);
+ invalid:
+            xfree(msix);
+            return -ENODEV;
+
+        }
+
+        type = bars[bir].type;
+        if ( type != VPCI_BAR_MEM32 && type != VPCI_BAR_MEM64_LO )
+        {
+            printk(XENLOG_ERR
+                   "%pp: MSI-X %s table at invalid BAR%u with type %u\n",
+                   &pdev->sbdf, name, bir, type);
+            goto invalid;
+        }
+
+        if ( (uint64_t)offset + size > bars[bir].size )
+        {
+            printk(XENLOG_ERR
+                   "%pp: MSI-X %s table offset %#x size %#x outside of BAR%u size %#lx\n",
+                   &pdev->sbdf, name, offset, size, bir, bars[bir].size);
+            goto invalid;
+        }
+    }
+
     rc = vpci_add_register(pdev->vpci, control_read, control_write,
                            msix_control_reg(msix_offset), 2, msix);
     if ( rc )
@@ -686,11 +731,6 @@ static int cf_check init_msix(struct pci_dev *pdev)
     msix->max_entries = max_entries;
     msix->pdev = pdev;
 
-    msix->tables[VPCI_MSIX_TABLE] =
-        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
-    msix->tables[VPCI_MSIX_PBA] =
-        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
-
     for ( i = 0; i < max_entries; i++)
     {
         msix->entries[i].masked = true;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 08:49:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 08:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132648.1470919 (Exim 4.92)
	(envelope-from )
	id 1v39ZC-0006aU-8y; Mon, 29 Sep 2025 08:49:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132648.1470919; Mon, 29 Sep 2025 08: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 1v39ZC-0006ZF-1W; Mon, 29 Sep 2025 08:49:06 +0000
Received: by outflank-mailman (input) for mailman id 1132648;
 Mon, 29 Sep 2025 08:49: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 1v39ZB-0006Tl-A8
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 08:49:05 +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 26940530-9d11-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 10:49:03 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PR3PR03MB6668.eurprd03.prod.outlook.com
 (2603:10a6:102:5f::8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 08:49:00 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 08:49: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: 26940530-9d11-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N8Oc+Ixp0NMk3OqvJZJfPdlMbhPAM8CXVmWMfVkug3OfMr/eQhBTeI3UZFyLF8JeTJRtaZzA/cqSYPHV8o83S5ecfZ+qxNcqgafZ6HQtMB8YTAkPUGpfDuzpz8SAYZ37ynqi3Lj3iUSqVzDsqeCPsOrpE1Zu51q7DG2NX0lFGAMkN2Iav+hKNbljnFmwMIvX8I63khM8XgkfioDvPrXU9vk8TTJFaI8gbvVA+j6mPFOL6pJpJFVxFPP2qjIe0/17nBtvlcia4Lc3YcPHluzp8LkMegyNF7Himfi0ZTuscc9EZHTIugAtlJ/Rc9BJc0eBuZEaTft8dCd5nKhhyzaTyA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=efud+6/iP4lT50/wRtbn/W7+E9nJbLdZ7Frmkpck1hc=;
 b=Xlzp6jq8cvn8IqlYX3oQhWbarcmdyjXA+3OK0xNXMhWC/iba1qZ3+Exizdxg/tienbPwykZoje5/m9zgZHwaFkiQBmBkVLqCEZCE28OXErY8x5Jj6/apuwXjYbnemOc/DTzhblF1b/Gh+HJIKX/K2T+DS1kQkPlYFi17d2ZbybNS3pFLmInhjFVjYuupaEvo1a6kVT+s0rddQ9zGQobOCp6KEDSxdvbu7VnAI2djY8Gc77I2N6qjd/DCdkp7dc7LFUyz2jUPwfeEnKcIExgrRM8y/VNnT5jvvEtupuHOp6ZUD/hhWiNJZGvkh+baJFos+mVA4KoKPSeFceMxVBXOMA==
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=efud+6/iP4lT50/wRtbn/W7+E9nJbLdZ7Frmkpck1hc=;
 b=sGtRmm3+A1PdzFeN2JoPyZE0qWD0knRtxCpLE5LCTPTTON8hfqJdBd4f3nQVOFDnn8235QA+0nIObgS3tBmMN9M/3mh5gc5av6aK4NwiwnyTin0eY2FPae7xgxjWvuqW4daMZVQYvRZA8R4GIGKjcqUvNQk5EIqNoK1RC2yqvFzqbSSVSGy5Aken5Mf5gAFRdliRevelRuUIbSrmm1xm5RSr4dYbPdSEcrkTBELZqhAxrGOq1OhdiAn+KxSuCu1WLSKG5vE2jAkcsELktUtScCMTbyeQyrshPRPnpSCEF0yPchzLzdxxHlW5ML9HlRVH55fsgSQ3l3DFQUdBhWXvWA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v2 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Topic: [PATCH v2 4/4] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Index: AQHcMR3m6aPxOGsuTkamM2L1894cNA==
Date: Mon, 29 Sep 2025 08:49:00 +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_|PR3PR03MB6668:EE_
x-ms-office365-filtering-correlation-id: 5d4ac18e-0618-4d41-93c0-08ddff3508d3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?irkHwfFGjNotZByDglfCeb6Yp/UIHL6Vv1f8orCkmYolX6dWEtFEi1sH0J?=
 =?iso-8859-1?Q?rofJuWUG/c/tuhAN7cHq1UzVT0pn7UZ1sE4ix2jm6/0IcdzJVPFtqjJjVX?=
 =?iso-8859-1?Q?lxnNdREZjorXBFfnU/3pJGYDVwHYHBi80Lt9S7NViaJ0GnLZDfDri/nrMJ?=
 =?iso-8859-1?Q?Kv8LqFrzhaZCszA7OFr8npx7SVhznV24ySi2R6oQEN+jUhcvDGgQvKk4T4?=
 =?iso-8859-1?Q?yPOCBVa+Zj0rBy2MaMEfer39rt3Jo1WhHAYF1RwCnRKagdDHSoReXrkjhN?=
 =?iso-8859-1?Q?r6O/5pUOR7dCh3INVIL6oxsRK716ljHVa/UO54j5s5qMkWYkWE3L5SYsC0?=
 =?iso-8859-1?Q?49IPqIFxSgsm/1be4wFhU5tBjGqfFX39LVaYnyDK14f1+oV7mLA7AQLkyG?=
 =?iso-8859-1?Q?y3QlvVhknPUp5J2giooVZs+jPzMnatyNXw96ZxpQYZfKdbicKl+OKxNVjN?=
 =?iso-8859-1?Q?H+hvnUdBvzRkblpGkrIr9Aeq6zBOUee0Wtf8zjQXxcgKROAmpEGbhN6cZV?=
 =?iso-8859-1?Q?a/iNiGBXx8t0HfftQdsZVtteyadAaRxQvbjr3C0KjfwKhS4BNdxek5oLDp?=
 =?iso-8859-1?Q?nVMEZyB20wK715kv3P2Nnge9uJnTtfdGVjb7GB2XX1WhUprCyOMF3+L9Os?=
 =?iso-8859-1?Q?yC0kGeDFxXMzlPHRCt89Q45xajPLG5GvwsHfESaLggnwdDjgI2VmNrJi9w?=
 =?iso-8859-1?Q?Fw0MCiDvhrsUoX2ysC5KgYGv6kCYwk9ojKgt8/8SgsZM/4By/saB+l3cSH?=
 =?iso-8859-1?Q?rh47+J9SSa1Z3qV4e/iU+L7QVir5Mp91dVIiceap5I6AvPK67yal6eXdg8?=
 =?iso-8859-1?Q?AEe7tvFmJKEAA8ExNDL3nAIw1oE0QtYelyLNXtm/XAEw1Qde4edFyw6sOo?=
 =?iso-8859-1?Q?I11QplWuyWpE2R0gVNKhUk6PsfW8+KjpwbB1Tq9Ngk2UpaPOmkxZ0ZphOd?=
 =?iso-8859-1?Q?S9F52nqtdvszInUveNKoqelRDupZm8dgHogV5sIrE1XIUtV7NMwaqVW53j?=
 =?iso-8859-1?Q?BCluUrMQBvoPYSqE0pnXqQ4HKXS6uSri8ly0xuHjd1wCbWX8l9Zl4KB04F?=
 =?iso-8859-1?Q?L7AHbqbO2iow0qUIqr4eE9rfagYboHscyuMAA0Zu0lwaTeR5Lmz8zLo9Yx?=
 =?iso-8859-1?Q?tbZyGlKKpwiMRI9W1d9Nz5KMQGfkx0hrTeRHXBoZk4Sm2WEPnJU8YjKT/w?=
 =?iso-8859-1?Q?gVSIjTpXHmSqFD8bDvEbFEFy4M3LcA5agCq7eN8R1RRX2/nhq5zfaXy5j3?=
 =?iso-8859-1?Q?+F8MtAMBrDo7fmi+tFOpyfkPD4us+H4SMsNeLmYYCfHQwE+AU+Jan37UaW?=
 =?iso-8859-1?Q?R76C5vWHrasL6aqdrnHkwrLsAT764XDNif7xK0tTGl1EO3r7D6s94G+p0r?=
 =?iso-8859-1?Q?NrCTFdTnspclw9dqtyLaUL9kGvX40jfN6+VztPdwAuBgRqgaauZwU9CDkT?=
 =?iso-8859-1?Q?DPNmIFHXZ8yYIiiMms4whqlA4Esqrf3uL+8uJEDfVsFITNxi8LSoV64iK4?=
 =?iso-8859-1?Q?cqURoFzHtjthlTSuILHswJ4G2KA8G6hZ5yDE93zryIusazhOqobjI+e4sf?=
 =?iso-8859-1?Q?PC3gJyU3mJFHlJHKdr5Myqxjt0Ti?=
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)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?1jA5qmybqX1YTK2jSJ+VoDmboObk31Hocy4kXzhleYLtiHYiVugLZndwd4?=
 =?iso-8859-1?Q?9xHPLGE0WFh0gKzlnf5rp31QqJDEgZUh08OLeS01v86PqysNUvNYK4C2jz?=
 =?iso-8859-1?Q?k1EhLqKpkemYD8XjoNOT9PlxC7lcSWu3Raeyy5gLM9HFnGkNzAd14417zc?=
 =?iso-8859-1?Q?iKCdN/8QEO/ez5QjTN4JYVox+b1kBORvPSvdvlqMsjM1qRzDMQm6++iRDn?=
 =?iso-8859-1?Q?8EWA+eQmL0MAkAd49tuDRE2MEEGn9AthhaNOGXLML//Yc48yphV79Na5hv?=
 =?iso-8859-1?Q?aK6PUM36GhGAXsYw+vt14dX+IDK/9RnQvt6Y1C/QbLziYsnDbpfKMhGbcK?=
 =?iso-8859-1?Q?+r6bBth/XSquPZFl7PdR7grnSrNb35AJzdjVLnS3L7eyao41JtpBT5lo/2?=
 =?iso-8859-1?Q?x2tyZkTfKbyfqfZ9DpOTrG0dTj2jRaaY0AhY29vFPRAuOYb6P0XpSqHsX8?=
 =?iso-8859-1?Q?gTteHu8XTmavt3ygQTD7dGJH6LTAPOwwl3tVltCxMncJovtx61vbbAnTXx?=
 =?iso-8859-1?Q?AfnBwyfhtIPkxMHLUwJvHhFKQGMXLUwNol28Huajn25j22d04FC48zwW30?=
 =?iso-8859-1?Q?NtApJrbLoXRBWR4c+TrGn7LxLXzWtomk3HiO1+tnFzs7HJwtRXJi16SXXO?=
 =?iso-8859-1?Q?pRS6rL59CgSxD6VD6zqY1SgNVGkK3DuuAhvQOh8jGTsAEiH8ybdPoGB4LL?=
 =?iso-8859-1?Q?pfbPCVoXNirXiYijJt8rTh+4bBidZMGMk9n7bX8rRfjDJiQtpvIo+pqeKG?=
 =?iso-8859-1?Q?GiuaC4Njwmrvio08jTv1nTeKjyUfMqvmHY9pnYZZfAH+oPRIEJrRmyFP/A?=
 =?iso-8859-1?Q?JPdxGYHLET9Z+MpqiMpW1USSjF99xODq2hOh18V9yjhWWOgXOakNFk4euC?=
 =?iso-8859-1?Q?sScf54iPTZ4ySwOVAsV9DfX+8L9bMpv5OobsFxHY2X3XSV8sBGB0aUN2IW?=
 =?iso-8859-1?Q?sRKFx5mu4GMQe3i+MNMaHPMmo97kwF0xYmwFl0GTasGr6WmmHsAqSSLv4k?=
 =?iso-8859-1?Q?xIPfBYK1H79yvqiHBt2j8HGvWYNveJUC96bqmRpBcHWb47TaIsZB0AlElU?=
 =?iso-8859-1?Q?Uco74Y5Uf9FFzJT977mK6axXxkdcW1nnPAVim5b/+QcLTDi8UiXB2pNM/B?=
 =?iso-8859-1?Q?lKSoDoJC4haVsjwM1L2rprt1qsq8ZUCoYEpuboul6EW2gV4v4W/WqjmsM9?=
 =?iso-8859-1?Q?1DS9Saaj1PQltDG9JDj4tRYSWKL9dL8rs0EtxbE2fywDzBUEoJ0n7BmZNv?=
 =?iso-8859-1?Q?H928tXSvZ43uyMYstCtcnuzXu1/XgHqGq88kmW1LQ26ZPqQ+zJ3XkqPEj2?=
 =?iso-8859-1?Q?zA2jHsSe6L2m6idBbcL4hn00TAaD4Zzw0qfKv7VmF7+TU2u2lPp7bqBQgP?=
 =?iso-8859-1?Q?kNMefXY7kFZcwBmAz1UBojwmLlk4dXyihkM5q+AtiQMMh29eW0YX3MESbZ?=
 =?iso-8859-1?Q?8vLNtHpD5AePXK89/xIfelW0+klsIxwUMsscEYN/qzJoXDZXUW/UaL/9PD?=
 =?iso-8859-1?Q?meXcXNndnanQcCO2XWG6hPD76Blunaql95IIrqus9TicukSz0jumt6W6y8?=
 =?iso-8859-1?Q?DArdU/SpKgn8anFTnZwRmwFZUAo/HoP2tIH70OmJpyNlEFWdHfW/f6cEaS?=
 =?iso-8859-1?Q?n233ymcYeFjjIrG+jF6F9NqdZwPEL8274Wibr5nPgeROtIEuDfwlhSOQ?=
 =?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: 5d4ac18e-0618-4d41-93c0-08ddff3508d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 08:49:00.2742
 (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: 5rF4a3FCGVAmB9SPb3LCgBEItzcGhooOUPtCQpMnFvyEZ3Knl1XzyLjXdBPu9RJ0ceJD+mIW3gaNy4U/Wpy3JA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6668

With CPU hotplug sysctls implemented on Arm it becomes useful to have a
tool for calling them. Introduce a new congifure option "hptool" to
allow building hptool separately from other migration tools, and enable
it by default.

Signed-off-by: Mykyta Poturai 

v1->v2:
* switch to configure from legacy config
---
 config/Tools.mk.in               |  1 +
 tools/configure                  | 30 ++++++++++++++++++++++++++++++
 tools/configure.ac               |  1 +
 tools/libs/guest/Makefile.common |  4 ++++
 tools/misc/Makefile              |  2 +-
 5 files changed, 37 insertions(+), 1 deletion(-)
 mode change 100755 =3D> 100644 tools/configure

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index e47ac23d11..eb4855d93d 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -49,6 +49,7 @@ CONFIG_LIBNL        :=3D @libnl@
 CONFIG_GOLANG       :=3D @golang@
 CONFIG_PYGRUB       :=3D @pygrub@
 CONFIG_LIBFSIMAGE   :=3D @libfsimage@
+CONFIG_HPTOOL       :=3D @hptool@
=20
 CONFIG_SYSTEMD      :=3D @systemd@
 XEN_SYSTEMD_DIR     :=3D @SYSTEMD_DIR@
diff --git a/tools/configure b/tools/configure
old mode 100755
new mode 100644
index 5abd44e21e..5cf5381c0a
--- a/tools/configure
+++ b/tools/configure
@@ -728,6 +728,7 @@ LD86
 AS86
 ipxe
 LINUX_BACKEND_MODULES
+hptool
 pygrub
 golang
 seabios
@@ -834,6 +835,7 @@ enable_ovmf
 enable_seabios
 enable_golang
 enable_pygrub
+enable_hptool
 with_linux_backend_modules
 enable_ipxe
 with_system_ipxe
@@ -1519,6 +1521,7 @@ Optional Features:
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
   --disable-golang        Disable Go tools (default is ENABLED)
   --disable-pygrub        Disable pygrub (default is ENABLED)
+  --disable-hptool        Disable hptool (default is ENABLED)
   --enable-ipxe           Enable in-tree IPXE, (DEFAULT is off, see also
                           --with-system-ipxe)
   --enable-rombios        Enable ROMBIOS, (DEFAULT is on if ipxe is enable=
d,
@@ -4807,6 +4810,33 @@ pygrub=3D$ax_cv_pygrub
=20
=20
=20
+# Check whether --enable-hptool was given.
+if test ${enable_hptool+y}
+then :
+  enableval=3D$enable_hptool;
+fi
+
+
+if test "x$enable_hptool" =3D "xno"
+then :
+
+    ax_cv_hptool=3D"n"
+
+elif test "x$enable_hptool" =3D "xyes"
+then :
+
+    ax_cv_hptool=3D"y"
+
+elif test -z $ax_cv_hptool
+then :
+
+    ax_cv_hptool=3D"y"
+
+fi
+hptool=3D$ax_cv_hptool
+
+
+
=20
 # Check whether --with-linux-backend-modules was given.
 if test ${with_linux_backend_modules+y}
diff --git a/tools/configure.ac b/tools/configure.ac
index dada1c3b15..3a0644ef89 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -90,6 +90,7 @@ AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
 AX_ARG_DEFAULT_ENABLE([golang], [Disable Go tools])
 AX_ARG_DEFAULT_ENABLE([pygrub], [Disable pygrub])
+AX_ARG_DEFAULT_ENABLE([hptool], [Disable hptool])
=20
 AC_ARG_WITH([linux-backend-modules],
     AS_HELP_STRING([--with-linux-backend-modules=3D"mod1 mod2"],
diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.c=
ommon
index a026a2f662..774b1d5392 100644
--- a/tools/libs/guest/Makefile.common
+++ b/tools/libs/guest/Makefile.common
@@ -25,6 +25,10 @@ OBJS-y       +=3D xg_core.o
 OBJS-$(CONFIG_X86) +=3D xg_core_x86.o
 OBJS-$(CONFIG_ARM) +=3D xg_core_arm.o
=20
+ifneq (,$(filter y,$(CONFIG_MIGRATE)$(CONFIG_HPTOOL)))
+OBJS-y +=3D xg_offline_page.o
+endif
+
 vpath %.c ../../../xen/common/libelf
=20
 LIBELF_OBJS +=3D libelf-tools.o libelf-loader.o
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index c26e544e83..f783f16ae6 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -16,7 +16,7 @@ INSTALL_BIN                    +=3D xencov_split
 INSTALL_BIN +=3D $(INSTALL_BIN-y)
=20
 # Everything to be installed in regular sbin/
-INSTALL_SBIN-$(CONFIG_MIGRATE) +=3D xen-hptool
+INSTALL_SBIN-$(CONFIG_HPTOOL)  +=3D xen-hptool
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-hvmctx
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-lowmemd
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 08:49:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 08:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132647.1470913 (Exim 4.92)
	(envelope-from )
	id 1v39ZC-0006X8-06; Mon, 29 Sep 2025 08:49:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132647.1470913; Mon, 29 Sep 2025 08:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v39ZB-0006W8-Q2; Mon, 29 Sep 2025 08:49:05 +0000
Received: by outflank-mailman (input) for mailman id 1132647;
 Mon, 29 Sep 2025 08:49:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v39ZA-0006Tl-A5
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 08:49:04 +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 26413e27-9d11-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 10:49:03 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PR3PR03MB6668.eurprd03.prod.outlook.com
 (2603:10a6:102:5f::8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 08:48:59 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 08:48: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: 26413e27-9d11-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bBAnWv3gWc2cZ+Ikv6fSV1aNwyI/LMWkDW3p9MsEAuTd1ViLslgKXSdJrKwIHw4HywUdRRhVv4OHaaPoQ6/H8T9/r+3Lo8bqeEGea78G1h1rDg+II0dS1LMMxgfqSRCm6sozTBnk0SVRrWIEuxQn8PlJcl60sOUzC/hYdbkmid3Q8l/AM0wZFZ5c+yIH4U8sxQllSAdMoefjBcweO1r8xMIW+4+bEeduFKT/tu6O30HhUJxkFp8vZU965UUEvhB/fYRK2zzufaZ6GjcsIrUayx/IjlShh4TahpLKzd+vlfnbK6P8e/8ZgEvR3tSkojymc24bAxYCKGuoDchIg8RAjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=B+YYBGRfTXcvGMs4a3ZSmAVsaDxbeSYPy+wB54gO/UM=;
 b=f0pedsujJr4t7HjlwQ/1M2PA8qeyUT7ZDih7qgsA4hqcAexF+n3lqNttyeIH1XY0RFF+dr68e189WZn7ybnoKh22HhfjeFPDAK539pPK/LDRV3Jm3ROB7gEpy0grpVS3OeSb0aYMs7Uo1qydSppe7eMLlHzhyFsc77OOv6o+8sdXHDe7w19GnICLIpBNUHk4y9LxxZD2aNeWUAzWhRwcVtUtjqJ5hvpiTINCueiQ/wX1UWeMnXSVP/VFIxytAqsnveDRz2KfK4bA55z6JNqWnPxr2IiJL8cfmK92meSBGBhABCP7vhKpqSOVXyEAOiCH0GKX5b/qFxAV6rJqSoF/SA==
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=B+YYBGRfTXcvGMs4a3ZSmAVsaDxbeSYPy+wB54gO/UM=;
 b=MfqZFUbOyu8DR3Bkn2sz95vluMJyJpzlWib21nEf5Y56tRH0a4/852YxCPO0gQ5lc7WX+Xc8U/LxI7K6r8CYPEAI+M8VruAVTFHbOE5m5oL2cVV4pY028drWSxvJt69uPseqgcwxT/i6mZxkO8WXE7MRB65KoE2N1Sm7zGIVPdFp3Ne4KdY9a3j52bOswaIOJjdxjH23WVlOGLVDYXMtL944ujgyrmNHvX5K3R0qfCLWpwtkVZP/trKqXjkP0ODHpwwQh03sxPkGuGasbmL6Cos/2Maph60h9DogXyer6Mmbna+04oi8+Iz7DRZ+NTOE6zlLKcs2O4wuRRcY87hmrg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , "Daniel P. Smith"
	
Subject: [PATCH v2 3/4] arm/sysctl: Implement cpu hotplug ops
Thread-Topic: [PATCH v2 3/4] arm/sysctl: Implement cpu hotplug ops
Thread-Index: AQHcMR3mMfDQQg/odk2GMtm9qNuvyw==
Date: Mon, 29 Sep 2025 08:48:59 +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_|PR3PR03MB6668:EE_
x-ms-office365-filtering-correlation-id: 5981a451-28f4-4443-dbc7-08ddff350888
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?cCxKoNfWgtPr16Ym7UINsFK2VmWBWx0seXKM4pTE4PaMjpituZRW+zG4q5?=
 =?iso-8859-1?Q?tenABhHtMLrDw2WxWpFO5IJHBQ+kNXeXaUgXkjSCmA4M+QLCyhDHUfVMFr?=
 =?iso-8859-1?Q?so4vt9SMZd9mazeix8UJs0+om8ZJ6uiFPw8zoFcipcvU5mMInxUSnn9RaY?=
 =?iso-8859-1?Q?Gezn2s3Q8okSqO3MRChxU1Az3MWBTz7/yywDpmsa6+74hDGiZhXN2vrvqI?=
 =?iso-8859-1?Q?GZQqAGUuQxbRPsvc8JrMoNjLAcmwWBnHvifJIELg/54qxjXPLpB/sBowWx?=
 =?iso-8859-1?Q?lox+2keRg6XeneV1XnR609Zel9WBrVJvyNczwOtqIS8+OTL4TQHCx4Swvv?=
 =?iso-8859-1?Q?KDKz/yyGgnGiZT0xpEP2jX7+C1WtvlF09Q3eMqn8wcT8Kbx8Z8jjdUHivs?=
 =?iso-8859-1?Q?rIDDvTeGSiNTCBp/KrKl4924NO+Zk4klNH7MZrS9ZhA4tTrSVvQVAnW3ZE?=
 =?iso-8859-1?Q?PkhCavw4PZz01BSK28j5zEkmzA+6UHWW/0hP+084bbCAfsyO4VUGSZsQIn?=
 =?iso-8859-1?Q?jmy5TLI7Y+VidLLNun57GB93WLwo6cu7kJd2xcQm1sHmdzc676uwc2+/bz?=
 =?iso-8859-1?Q?mw6okI19RBBvsq/ZQcfmJBL+TxlIaEJEy3e3G1kLzhsRdRVLwxdt3v36di?=
 =?iso-8859-1?Q?KAd9rnsN5lF2IF1+arwJg6MWFzsLs0nJ9kGINq2ZHc7hRWZnTMGoqlPj3K?=
 =?iso-8859-1?Q?E+Pr8PajhbHja+9nDItZNVVr4xricnutvg1ZoAzsOvphzvInEA/Q17q/GH?=
 =?iso-8859-1?Q?5QhX9ZvS/u5/OLqWLTjxCdaTB6aD5dB/bvM8H6acb5xBiHuO98FVphNl0G?=
 =?iso-8859-1?Q?NMvnYv+yEkhmx8v7lchNc1fXa9SqazaHysu/SrZhB6M692Ea2egKklOSw+?=
 =?iso-8859-1?Q?Jky5huweRkZeCs7Ok+EMkRHkjs7qiK1FwaVJeCggtSYp9JL+bH4JxiBOPQ?=
 =?iso-8859-1?Q?dyUVVwiMplg5r2vq7h08bzIUE+bwxoS7bTl6q/Ed2rw49cVo4i9ujc/ha7?=
 =?iso-8859-1?Q?m7/zZX1vY3SeEvrYFvPmDq2QVKDv3BanQSdNHtpDMf4kmKrl/6h0Ul9px1?=
 =?iso-8859-1?Q?WB04h1eA/SDuRg6/yQ7n1SpdHLNareQmJCSZk2rtZPyGRfqPsIyDtkpwWM?=
 =?iso-8859-1?Q?JvXX6pOhfDUN05xAed8eqbVDnP8bkWTJ2YEF784haYnyC1E/Y5XAEEjbT6?=
 =?iso-8859-1?Q?kRCPVKSV4OZfWIx8ho7I12zPHkHXbp1e89jzboDr/EhdYQt4ELJ4nvLeEB?=
 =?iso-8859-1?Q?wrskncxNOUpWk8/rXVIKznL9kI5M7X0YKbjrSfYmVDtQXJeMvl7p0chsxo?=
 =?iso-8859-1?Q?x8/KVRzybGwLmHOKQ+ge3i723x2jCm81d14RlXGHF+7tcg+fzsZSoMrmFG?=
 =?iso-8859-1?Q?5kE03fo2/6VTWN1JPhhFddiCZ76NTOlEs5SVAlFT7wNdibqqFv/3FFxvK2?=
 =?iso-8859-1?Q?xlTFs1QJLW5uXC9KRAZBklzRDxGvRhDOfQllVd+s5pxQ4w/BZOz/l6EbU4?=
 =?iso-8859-1?Q?GHVODAKgtmofzqpX4KXOVxBZxgDnrONFj2R0nDPCfOC0ahq30OQrQIXRZo?=
 =?iso-8859-1?Q?bCqAd1sagpNMnBFr+o5FktmXc0dh?=
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)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?OPdvoQbNZb1edgFrTsRrGsNuyUuLYoN2uR7dA/lE6ggDxP6CbHy6XgEeAn?=
 =?iso-8859-1?Q?/oJKbM4lKMwQTKt57+YGgpP5CPSwibL0eBRlBxpGuzRu1SyLu7EHdpn2mS?=
 =?iso-8859-1?Q?oBDpNFi/i9dkMFhKT/3STjOw7krJL7OQHnd6BG3OXvqQiozhc/z53LThRt?=
 =?iso-8859-1?Q?iOQAY4+D0UXeOdhZ+KkWrkEIJZ4eNxgBqyIeNBXCXjTUYEYHs1hJMJli1F?=
 =?iso-8859-1?Q?XktjwrPkhc+HgG5PgI9srfyq8zR8vmEVnIhSJIHUyI3pw2iDcKYUv2bfwL?=
 =?iso-8859-1?Q?Woo1+/NktyeHN986/E3q1Y+RaB9eB17BT7o4mWPg4eiWKLThA4gXk8o4t5?=
 =?iso-8859-1?Q?T3yVBlC2Gqd+amWcSv0+AoxHYftvC7Ur05abbxNIcdaIykgGAeduFUsVNV?=
 =?iso-8859-1?Q?i41GJTyM7IfQcIac1xQYXBizyig1Pp/y7baVzwj0ayYb76D2Nnj1frLe4M?=
 =?iso-8859-1?Q?Zu//1dN8qD1DAcg2FvdOdoElPj49yzuM5+VraAUHVi61kne3NjBHZG3sH4?=
 =?iso-8859-1?Q?gJqlNO+wwfIACpIrgdhdNW38KrPw34v+b6n9YaJFM/MGmBqtZgbz0FSZHU?=
 =?iso-8859-1?Q?yTMQTxI5NUsp2Luh+DAtaXIbY15KtQEKYW7zh2qSBecmptIC3nwEJAZds1?=
 =?iso-8859-1?Q?SIEOgAANntO6T9lTA5pVW9ebfYhsvZg7RqZ0szZzb4zMcmzpIH/qhSWywA?=
 =?iso-8859-1?Q?6NNvZ/FAsV0XqAkJyNuOmtopZZCRTWLz+TyeG+36aOh4XBE5LON7PIzOl5?=
 =?iso-8859-1?Q?WfQSeAAyDvCmTMwAnyyS5LZBBLrv6tkkvuyZ7UA1quF9lcNygdr3ZaNuIa?=
 =?iso-8859-1?Q?l7n2FPvE3hmdbc33Q0qAHA5ln+4a1/CpSTZ6X9lAAf0g9JXq5aOwgjE6sU?=
 =?iso-8859-1?Q?IZwfX1lTgejZJHqfEzXQH81bRsQMl6XnPTWG4G8HDi8fa+iofGalfQWh9m?=
 =?iso-8859-1?Q?ls1vSV0xkP2gHDB/vYYdJzsiR6f8iLDQZzWayOd4ar2RgxQz4EMRJsXisi?=
 =?iso-8859-1?Q?vFE9Z18emvuYAvWquTA42mjaNP9y2SJ7cxMnuTwK52YXTzouuJGKc3y/Af?=
 =?iso-8859-1?Q?M+5wnPhpQICO+sWdew9IgoOdHkqeN51aYyt8DMoU5b+95BUkNdawUcb9c4?=
 =?iso-8859-1?Q?RxiuKM6pP0AEO97EDM/eKyLaNncgWBvabeIwWxHeOdfj1MRGZ5JFjSRT9P?=
 =?iso-8859-1?Q?AXp1K8+vOvlCFKOMGFdd801jb7Dub84ap6gvi/1QggKPCvFsAQzyEyG+Pj?=
 =?iso-8859-1?Q?H29AbWwvQSgrFLFLDU9uXtRiZ88GB+K19SQJR4Z1Hf4zGS55MfkPDmRWDI?=
 =?iso-8859-1?Q?JAri9+Hb+GdhybRU8RT3JvAR03hX5wvl0waqfVHRkYnTlEJ2/S9PEfRjsw?=
 =?iso-8859-1?Q?Ao2xuUUIWr+7tkA+NWATc5G+xSwf9MG/l1EmoPgNt5jt4u5CCFFeZsLpoE?=
 =?iso-8859-1?Q?nAGZphOPbkrPRw1wU1pVp5fHtGcqHla9OH0pi+SXoau6RZW4icwpnkr2v3?=
 =?iso-8859-1?Q?GZyf1Ca5HKSLAUSj8Vlsipoe9Q/c4xjnF/vMm7mCMs4sNpXDRBd6vGlOlO?=
 =?iso-8859-1?Q?0NJ1ywS2/00o69GrOC12E9RhbenFhECt+MRXlzjuN8wZDl/ZBLBEva0I1A?=
 =?iso-8859-1?Q?O6wAFHzDeXjUqgh9Bn072KXHbjXMKGojn6XJz1CFN+rvA453hYdYerKw?=
 =?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: 5981a451-28f4-4443-dbc7-08ddff350888
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 08:48:59.7648
 (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: 7d5rzHhtGAYdp2rUzBKJQR5H3bmaR3ao6K8kSdiIeNd70BhGcQC2W4WlZSjOCBmGwEIbQ6POJWp5iWhG0VOCCw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6668

Implement XEN_SYSCTL_CPU_HOTPLUG_{ONLINE,OFFLINE} calls to allow for
enabling/disabling CPU cores in runtime.

Signed-off-by: Mykyta Poturai 

v1->v2:
* remove SMT ops
* remove cpu =3D=3D 0 checks
* add XSM hooks
* only implement for 64bit Arm
---
 xen/arch/arm/sysctl.c | 45 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 32cab4feff..fecd649db1 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
=20
@@ -23,6 +25,42 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
 }
=20
+#ifdef CONFIG_ARM_64
+static long cpu_up_helper(void *data)
+{
+    unsigned long cpu =3D (unsigned long) data;
+    return cpu_up(cpu);
+}
+
+static long cpu_down_helper(void *data)
+{
+    unsigned long cpu =3D (unsigned long) data;
+    return cpu_down(cpu);
+}
+
+static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
+{
+    int ret;
+
+    switch (hotplug->op) {
+        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
+            ret =3D xsm_resource_plug_core(XSM_HOOK);
+            if ( ret )
+                return ret;
+            return continue_hypercall_on_cpu(0, cpu_up_helper, _p(hotplug-=
>cpu));
+
+        case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
+            ret =3D xsm_resource_unplug_core(XSM_HOOK);
+            if ( ret )
+                return ret;
+            return continue_hypercall_on_cpu(0, cpu_down_helper, _p(hotplu=
g->cpu));
+
+        default:
+            return -EOPNOTSUPP;
+    }
+}
+#endif
+
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -34,6 +72,13 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
         ret =3D dt_overlay_sysctl(&sysctl->u.dt_overlay);
         break;
=20
+/* CPU Hotplug only implemented for 64-bit Arm */
+#ifdef CONFIG_ARM_64
+    case XEN_SYSCTL_cpu_hotplug:
+        ret =3D cpu_hotplug_sysctl(&sysctl->u.cpu_hotplug);
+        break;
+#endif
+
     default:
         ret =3D -ENOSYS;
         break;
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 08:49:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 08:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132646.1470908 (Exim 4.92)
	(envelope-from )
	id 1v39ZB-0006U8-MJ; Mon, 29 Sep 2025 08:49:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132646.1470908; Mon, 29 Sep 2025 08:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v39ZB-0006U1-JE; Mon, 29 Sep 2025 08:49:05 +0000
Received: by outflank-mailman (input) for mailman id 1132646;
 Mon, 29 Sep 2025 08: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 1v39Z9-0006Tl-N2
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 08:49:03 +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 25aa50ae-9d11-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 10:49:02 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PR3PR03MB6668.eurprd03.prod.outlook.com
 (2603:10a6:102:5f::8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 08:48:59 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 08:48: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: 25aa50ae-9d11-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=h2r36sYkvQpsv/7vK2cd/6Rl7lY7fomd+EC3G1t2W1cnCWWCzp0HHG3em2i7BxRWi33F5aSQtUAy+T9VDOjUHPQiQ1k1Uj445zyGJaQqDQIh0lkG3ACy/4OHCtQzwflVnCySe2HQ00HIn2nMAC0Us/BEkWq5BolisUCiVmhtyqEbWrb52pmtnH6mva5mdpf+k69Xr9LzOhLIzFAo8gm/xqykfZ3P43LCdPIL8S7hyc9IodRvnfoQsV90V0Se/FuCBAam/f9wb7A9sbW6PdyuTXObags+yk7MaZhGHfXscGDnfFMT5NzXkFUNeiZwMbcoidlgpnhLZvNnTpInb2YelQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6JebzVSnPshn5VcYXnyU+FoIqiAJQJxUQGCyo25WU9U=;
 b=LlCqopJssBTa5DTtQ/grSjBq6jdys3c4UtCtsCOW38KuUAb6ctSUtienKYo/P9iS1QKhddxpOtl8xQ9SiEaDkG3CDJj7KgSRulBWyhYQPMswDb95h0nTe/Trb+XRwXBYzbh3GoCB3/HDHRU9obGRSKM3HWQLjsrThfhGrdijk1NaItw1+Cm372A/mWuscZCCEzsPPiQdcNoyTWD1TuTMOjtmgM/FB/8MNX9afWN52K2ZetE4SjVokhIChs1+xzszSCaLkr/nmjGuOj5Rr+JVXAwrh1WZDMBw+OeJgErArRTGW1eC8OIhn1XpesDPQg1bZImBLefAKN6yoEGY/SEX9g==
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=6JebzVSnPshn5VcYXnyU+FoIqiAJQJxUQGCyo25WU9U=;
 b=rePkgrTrkRbLZ2xdu2FFIRr8wFB6DzdTeD/Xq3cIZwH86Vi/tNm/1yDAZlHBjaxAi7HdFJ3CRFGl3hWkFEohgs1cdzDl+H0XaOPVdfOnObRXMnc4xC3g3JoIJVTCpXmNOyD91CKln/1U8/MjlNT3ad82qp/e571k0sKrBcROmjQRvpFptX6Jz0yfiwzmErlWYHAJRoUxuq+vOTdjg2HSqyd4DTaiStLkqEc8siavBy5QX/Qt6Gp+VUqM5td6/YwTz6oWcwIYanS5umNYAaovnIw7B/iLirTnU9BHIgG0WPND/43vexkqRV6S1v7MZaSdKocuZIfNx1y1mKouti1vWg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v2 2/4] arm/gic: Use static irqaction
Thread-Topic: [PATCH v2 2/4] arm/gic: Use static irqaction
Thread-Index: AQHcMR3luyMo51OjGE+9JG+sKBjsjw==
Date: Mon, 29 Sep 2025 08:48:59 +0000
Message-ID:
 <7ebd435d510c88e2840ee991f8fd75f25ad66f75.1759135193.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_|PR3PR03MB6668:EE_
x-ms-office365-filtering-correlation-id: 6c3a6d61-4bd6-4675-f7aa-08ddff35084e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?3OQB0cfGPG2Px/wzSKEMhVuLqgtFA3OmDBLIx3CcVN9COL4acWd6FKxXxC?=
 =?iso-8859-1?Q?RjnzM6pG5lIhxArSFcqdSkqkT7luc6IqLM/AeR2gGhpkB106t2QUFdc/T3?=
 =?iso-8859-1?Q?D5JQI96EY5OKphxET3wKhdpPeuJo+HuVlQe/UW5fTbas+Macxn22pEOiNM?=
 =?iso-8859-1?Q?ro/mTtcy7c36Um2jTC5XFwDaFJIcNJp5zz+GOjXREx5QFcqJLM0emxkfWB?=
 =?iso-8859-1?Q?h8bFFyJM4iuz9Fhjb+erxT5oW39BH6OA4yfzNVEPBVpy/olY4tv4/BeOtK?=
 =?iso-8859-1?Q?r2dDfm7gToUoS6N0rctcuA+OTf/7nE5vsGXTXhiGE5GgrUkK5aIO4ULTce?=
 =?iso-8859-1?Q?Eo6u0ZI/iQPjPXvnHlOKmKHJzSieHzLduGGb7l4buExthjE2LWQNwmu0mj?=
 =?iso-8859-1?Q?pBOGnrcXEPYvW6tizIqB1r8RbmsxGQm7HqJne60V9BKKZyRWRGZ2Sz9cTJ?=
 =?iso-8859-1?Q?gsGBcYh4KrSo//OLwDwLjQDamnqjJ8Ky/ZHdvK3U5tgcrRAWEnevOi7zT+?=
 =?iso-8859-1?Q?TZKm/RIOW/hPlJcIeKexjo6jTZ8Pb4M0RceVb7tAgldDdGb1VgYAAkCgH7?=
 =?iso-8859-1?Q?ZpAjfrhkN4sA26H8DGCFk27sGWLzm2I1ucNkeS6V3QuKAV7mK1kVlcIndS?=
 =?iso-8859-1?Q?F5JjcP81hzBjcRchGnH+mwwY9IrCBFmJXgn+Yjt5vsO3LGISV7ddRQ9Pes?=
 =?iso-8859-1?Q?u0bgS8Wp5R2OP4jNwrIminQ3PmTSU68e0koBqOAKR7sJ1FCcBTMPn74bIK?=
 =?iso-8859-1?Q?KiCnXu4tMeN8+ZRZmGnc9TWt7wYfO/Uhc5CNPZDSMlMh4rllm+GjsSup83?=
 =?iso-8859-1?Q?nVl93JwGjcd7t322j6EZXSJIIWWq3hG/op0geN0C6oJAC8uG/g7TMaAjnc?=
 =?iso-8859-1?Q?YkLmUDpyx9Gyf4kVD6CbAtUS4SwE7RYvAti87Fx/RyeF6M3F3Fs/0+fmO4?=
 =?iso-8859-1?Q?OF0BIlVBIbwZ7ArKc5VDqm7Zcg6M6Lhp35mYpr1Y1uRWrMVFH8ix0xtyyL?=
 =?iso-8859-1?Q?hvZ3y63Olu26HI5FhrXZG+iFfk5OKGRMFUjZCnZUeBFvNaRdbhF9yVllFz?=
 =?iso-8859-1?Q?T98zzGUe8xmdhPD8Fty9V+Va5VLphFQkZC5f/lHUXn2JIPzvE0HE2yn/HX?=
 =?iso-8859-1?Q?ZrAm4MqiSdgKZF3PJQkfgdAapM+bpxNQVgH8CAY3JqCBMgDtFdTPPyXk9z?=
 =?iso-8859-1?Q?923Gu4PFuG8C9RysGEiCvburgdUCFNuMaQ7Kk7BH6QuCOmdDkMAYoO2J5q?=
 =?iso-8859-1?Q?rRglYE4C4FQJyM1VE0tS53e7qTQlk2qgbOVeC/lWJdr/WA9lvjwr3kE091?=
 =?iso-8859-1?Q?k+iin09uEuCpFafLesOnEVRq6FrgzbYL2QgyCmSTky/pnQManqEk+zQRLJ?=
 =?iso-8859-1?Q?JmmX5GGW/G0bmRrO+2VSkJq5aJ7yzEU77P/2PYJI1okxU6oJ0hjpljJC9v?=
 =?iso-8859-1?Q?sJ/RP/zYMW3oX+KBqPmET3P6RbmCX68Ym3mZAImITRuGwf2lBYrjzRCjz8?=
 =?iso-8859-1?Q?fV8yfkgusKEipcE1pVcvAK+v43/O50RrF8gxBbHMaIZvz5PVaGXtaoQFTP?=
 =?iso-8859-1?Q?K8T0fpy2yiI/AdbJEFjkrhJgWg/M?=
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)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?1pTaoNY3c2LtaQtjUqMWpp5WKlfnCev2SaLo+D0i2JBa37MoFHuBBQFZod?=
 =?iso-8859-1?Q?/0UHEevthiW1lr2u1lCCVaJODUO99JyQQnUWka6hfLv4Mj3ImCenjFSfcT?=
 =?iso-8859-1?Q?+dAp2//ohBwJPqkduyCL1RkgFkKI8yZkaFUAeQiQSoh6FwdqwxX5oUoKcd?=
 =?iso-8859-1?Q?XTa80JENPj4RtxbeSlirHUL95vrRORLn5Blc6BR6mgYdilCoNnelzJnsDA?=
 =?iso-8859-1?Q?UNH4cEnTarfhFRXYTARnBR7JaNey4IQ8/3QIwMjNadANrXkVzLQx7A80gJ?=
 =?iso-8859-1?Q?giRNpDlSVpis28gz2a1sx4/8xj3JGLeLb6LCf9DNiCGudfaj2qfvHaYbCf?=
 =?iso-8859-1?Q?T2XaNLKGjl4UGNRYgeCBBupLk6xGRIfaprAvpyzsBR9ZbtyDwXS3f0Rt5m?=
 =?iso-8859-1?Q?KTH4CcRZ7O9+Hm1CqBZSUjifwdaj+6u7b/mxQWI0a9DH9M1Urwu6xPiDIU?=
 =?iso-8859-1?Q?+xrN/Fbu5SdwXOQJ41A2kjczqtClGyx8qQWHP7glfmBMXJVHUeOTTjETyH?=
 =?iso-8859-1?Q?tgVptvR0kiYDKmP9wuFm5jDgqe5cLMfLts28YYktUmpgzcFDZ3r9GU+WOE?=
 =?iso-8859-1?Q?kP2u/3BPIpJfL8zTPhQRob0sNOLnm1H62sDkVq7JQ5iJWSIZ/dI8MomeP2?=
 =?iso-8859-1?Q?P7CZ7alJt0mCOfsPzgy8RpguN3y7YSuY0yf+cdgeMdKjYAOEhFa5UlMy2K?=
 =?iso-8859-1?Q?0P04fI4jj9irzdFYZEoMPkNThMhzIix13vlx4nD08Y5lQve5V/S4rCg5vD?=
 =?iso-8859-1?Q?/TdX9cAJidDN+RXXED/RhJCVc47M9q8Ft1AycdrStvmaKWkn8NTnyR9fRv?=
 =?iso-8859-1?Q?xt8tNumRJtCOQQgjsYJofMHyBD6E+7/+IJSlJz4pYD/IvN6SSCUghgVOzP?=
 =?iso-8859-1?Q?AmFgwhrZAax4Gn0eS5S1ivD/MPFZbIl3gkrsPXf7lWIU3TCYMy/ZsHKYnD?=
 =?iso-8859-1?Q?VEOVbiZmERwQHouAH72CjVNJHiSSzDXOnY/3cld1g7VUEB3ov0MEvOPlpt?=
 =?iso-8859-1?Q?WQeTmq/k//N1w5iAkLyXwsPXGvcl4Sfx8zQtf6KyC6AgA4v8NKu85b/PlX?=
 =?iso-8859-1?Q?gtxnSwGc2SJuxHKERtY8g3uUOLv7QXGZdDqzRn6H9zGS4pLFWn5uVCgMjP?=
 =?iso-8859-1?Q?s14ZnBrF0z7bFitckY3rl5wFzTXZ3UeNKFyxaU1UUPpomFR9KgnPCrBntE?=
 =?iso-8859-1?Q?PGhJA25iuxRVeTlA3OgnDg8qP1uUlHBvbix/qnich10tlDtDfF22HCMBb2?=
 =?iso-8859-1?Q?IeuBZXUD60PQhe0mHcMM4MDSmRDE/DBfWqoKIVlI7piun9gLPRRS5zUsXK?=
 =?iso-8859-1?Q?mtEM/FVRpngfnDHzxtNCFpC6OoacCDfq+G+wB2bz+qWm9Q0fv2YWK5qoLH?=
 =?iso-8859-1?Q?nztLuqDejKyJKH+C//TYjDcNZ9xFWkY1d5RIlkhvSza6XLCTTM2jXRo3bv?=
 =?iso-8859-1?Q?bJbZ/KbkxNs4gM4RVfJ1I63Oo5HPzxezi1QrFn1FW9wvwZncPTYPJSPSzN?=
 =?iso-8859-1?Q?G15xKA8nTNmsAOhwf9VwdaY9ybf/lfOJnEC/hd3M1EXsJWykDbPVAhWjnE?=
 =?iso-8859-1?Q?KVQWxi0wbIqevIrerwXAilgzIReit5J30TuSzUaoMMoTGjHXSUUOGsNk9J?=
 =?iso-8859-1?Q?u7TUoG1Y9u2FlCQaFMcE7nApvr8+H+jLY2uJUl7N6taixHjpTUJqjgMQ?=
 =?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: 6c3a6d61-4bd6-4675-f7aa-08ddff35084e
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 08:48:59.4095
 (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: yqekYeG9AGuIpfkO9lUs3EZafykq1YJUGlpQpfqKxGtFv/AIszRB0RELZznOhdZpTEQa6483eHBtLDGB+ygAvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6668

When stopping a core cpu_gic_callback is called in non-alloc
context, which causes xfree in release_irq to fail an assert.

To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.

Signed-off-by: Mykyta Poturai 

v1->v2:
* use percpu actions
---
 xen/arch/arm/gic.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 260ee64cca..ed6853bb32 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -386,10 +386,17 @@ void gic_dump_info(struct vcpu *v)
     gic_hw_ops->dump_state(v);
 }
=20
+DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_maintenance);
+
 void init_maintenance_interrupt(void)
 {
-    request_irq(gic_hw_ops->info->maintenance_irq, 0, maintenance_interrup=
t,
-                "irq-maintenance", NULL);
+    struct irqaction *maintenance =3D &this_cpu(irq_maintenance);
+
+    maintenance->name =3D "irq-maintenance";
+    maintenance->handler =3D maintenance_interrupt;
+    maintenance->dev_id =3D NULL;
+    maintenance->free_on_release =3D 0;
+    setup_irq(gic_hw_ops->info->maintenance_irq, 0, maintenance);
 }
=20
 int gic_make_hwdom_dt_node(const struct domain *d,
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 08:49:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 08:49:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132649.1470938 (Exim 4.92)
	(envelope-from )
	id 1v39ZH-0007FC-HF; Mon, 29 Sep 2025 08:49:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132649.1470938; Mon, 29 Sep 2025 08: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 1v39ZH-0007F3-Dl; Mon, 29 Sep 2025 08:49:11 +0000
Received: by outflank-mailman (input) for mailman id 1132649;
 Mon, 29 Sep 2025 08: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 1v39ZG-0006Tl-4b
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 08:49:10 +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 2525c4df-9d11-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 10:49:01 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GV1PR03MB8109.eurprd03.prod.outlook.com
 (2603:10a6:150:20::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 08:48:58 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 08:48: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: 2525c4df-9d11-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oX4joyaV4qutFshZNFu1LMTgCAs1vo8iif33nLZ0OgBr9uqDrrvn1Z1vWg8cGpe0IYPhd1u//Mh2fot9hwch1RoY5qOhETU99NBU07zDrr41bYl3WxpUcW3T/wvUT69sL/OAA5PBFZ6mwLewQsm1/o0oQyLgS4I4CRUsZF+lS8Bdi4lehtl8BpnEsfH41pMoaqVIJTSYJDZeXUWp4NKCakDksy1XfgX44MZtSduzJ96h/+0ig2b11nt3MV8YufIC0FwwKZzAx3gKOjXG4m9kdnaYy6xkErhWGNsvGtx8e4ar8aFndIoW+j3rltt5hBo9N835iymqoRnd91WA/W2opA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=473GSDVLMpJl1ZQAXxO45hU8uScDcpmMAD2GZKlDRyw=;
 b=O1Ivj3cmCtqSKtHrWai5Qe/M5Buxqh+9dxUawt+d/O+xAg46uLhvZY0gKPH6hZ7AyCG4KKwpKI6LXDU9Uh4PLn3XZtsU5F5PU7nfK+Esku2lCo76TI7ty+dmpRu2isMlD7ua1gmILDdB96CoGEbynQPlYZN47bwYkuXHDDB5qZPMq7Pg3Gzvkubmx8WILvTiuYjdzjv7DGU1/LHZnFc6lPu5ysACpsq/QAnNQXe0ThCakoW6nhdwfVBIhIHV5our+0DbN9ITmueIrOh4CHtXZkweYBYG/riM/aJDueG5TRpNzRjge3hwp12JTiaU9YinmxmEYF2JsDmJUGxbIJBg7g==
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=473GSDVLMpJl1ZQAXxO45hU8uScDcpmMAD2GZKlDRyw=;
 b=JSjjJogXfzgwM6ec8keswL3BEQCq3c8tR4EMxo+ySQsxCUkYzYZiMasC7SdNsRq1niWWDbdH3VNrw0lPbqAsalL2jAFz+fXUK+36eC262mUKBRiPeE3tBK/aTvsiLPvncEkOjqJvXee+Rim1PL2Tu53jofH8KkiEwmqRTN8nCNfzkfB1fABxbz0xuHFfY/LJtdAlyT+vRCxeviRCTHjtnWi2NGk1j2SrivYh8shTGY5QrwvJkIt0L5k30kbxKKyrbtzsY9TWzLNBQUqZ3No3cqTotFlEZsaLP2XQCdLq7bnlwkr0QZCERYdMSp+P6mNWaiqj7j68Lz5ZIa3Q+0tqsw==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , "Daniel P. Smith"
	, Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v2 0/4] Implement CPU hotplug on Arm
Thread-Topic: [PATCH v2 0/4] Implement CPU hotplug on Arm
Thread-Index: AQHcMR3kP6l96o/PGU+srPxQ0vcF3w==
Date: Mon, 29 Sep 2025 08:48:57 +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_|GV1PR03MB8109:EE_
x-ms-office365-filtering-correlation-id: 9a0ebecf-2ed4-439c-78a9-08ddff35072d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?NMIqdK+4QGtqFnu9bytI+sg7n9+C2bteRBKLvtj3dt9/e48cgtHvF//xAW?=
 =?iso-8859-1?Q?qLfSloIZebxXY9LYeTZdNghkcx3Ek4vtD1KuI45pX9pGpEvagJDwhn+wVH?=
 =?iso-8859-1?Q?MKRFYQTKZ8XOBanaOT898qWok98h5kCzDZAKM12YzfCL9l44qQO29TjqOf?=
 =?iso-8859-1?Q?T4itRpoZKZQQzE3wnR3NQ1q49WnPSMd2jAm6+WbAzuMElbTZruomn4poRf?=
 =?iso-8859-1?Q?pvCZZUc7HR6eGD2JO4FUe60HON5xNzSITHqhkOjK7dEUCfXa18btKBcSD/?=
 =?iso-8859-1?Q?vYXOzrlwqsrbU1R0vPp2JmVO62E52oN5MOAHhY/tGi0adfL/nbkmwfthb7?=
 =?iso-8859-1?Q?O5vQyhovTIW13boUbdtggbhCe5xbAJKGfHZTm/UGgt53f1ozvJ+5ceMkol?=
 =?iso-8859-1?Q?GSx5i7D6RZ8KB+0tszzPSKUfRG5MWN4Hl4yL1TyLw6XLVUYbOlufyIKbTk?=
 =?iso-8859-1?Q?u04vQwZrmmWoz65RYOzgw+zz4FxsE1ISG8/DdTUstMXZujLMY7MfcmOPp/?=
 =?iso-8859-1?Q?JbbixfvNl8EBHgtnPeGeUOHTxnu1RQrGmsRPYwOBAJT/5ebrb16PX3w/YD?=
 =?iso-8859-1?Q?Ilq7OiyuMNp+TXLV6XIiZNnjEsCX1Ebb/hUOSdRk50bXTZJ4ztc+bZ6VYz?=
 =?iso-8859-1?Q?Bj5kqkomvU9OTnmcZ0hjyKJFWJL1eDazPY6b7RIoh65doQNwo6VcLeUqoK?=
 =?iso-8859-1?Q?gy/TUxLgTd4ca08WdLJNRUfSfRLe8H7jFmDsXzsJW3ef1GIl/2jBs+rE0p?=
 =?iso-8859-1?Q?35DJ+Fe0bOC0kao/xZAs2wNr3Ufy4md8F3mrjXMI2p0ggPhOaN/WAhEoLY?=
 =?iso-8859-1?Q?NcWX8KU/cA/9+PVDL5oUznVm61d6wMXLmIaW6CHk/urfPBegXhbjA4HMTa?=
 =?iso-8859-1?Q?wxIn5qbf4809Q2kIG2VTCL9UtvzfqpEZPXAx7T06roKIGwax9yD8JQhiI+?=
 =?iso-8859-1?Q?+bpOGpkscaWzil1+1QstYz+U7knMKoyN9hwK9k0dkPdHjlaxNobdZpDJd9?=
 =?iso-8859-1?Q?ALy2DC/aCZWKXzMhmuIpx/UnkPnVTNXipdUQF70lvvrP9xOiAKf1qLTzcg?=
 =?iso-8859-1?Q?RTXl8e3gOoMy6GcSnYP5IokIAiqeKskC1dQGvfcjEMjMdAFzX4OLkTgLHi?=
 =?iso-8859-1?Q?GuCNbV26pn3LbPmNpx4tQ04jCUfrRvgxh944I5mHFR0kftgfhNy+v4W8JW?=
 =?iso-8859-1?Q?VKDT9Fe3+kh0AKSX1vnIj9dQXo3D6tICFbOpSVAdFMejVGSpCC4SUDHJOD?=
 =?iso-8859-1?Q?lGfPjbh7ZN4piUezWXi5L3w91dmURAoPM7w9DILBHVCJLIBzJEEjwKIWZK?=
 =?iso-8859-1?Q?5odRlE3ulZ1TsEF24CiqwQXLYkZVjMF5ucQst6beHaGFIx1bNNaFYljYU+?=
 =?iso-8859-1?Q?A5Bb4okv3FNk6vXRoPN/5+yNntyzH2Ewc641KS5aU7j7OePAdOY7Sjo+y2?=
 =?iso-8859-1?Q?rIvERDYT4/zKZ98gcb1MGeSxO8R1lOwyDTkajCRSyoV4QuKYUZTxgU6j2G?=
 =?iso-8859-1?Q?HrqL/JjtJRTMtEYpWMaGJjlErf1LgDdF3EuRe+qD08FZM5Zq3gViPRL9Ar?=
 =?iso-8859-1?Q?5zNfrZEKQ2Ws/4nrVJqhd0wIkv7S?=
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)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?TrYJ3qoMgr9LjIBgGytWghvVIZR3IzLonscXjD8+QM+kZm5CUmrxtNMjBy?=
 =?iso-8859-1?Q?q/1q1rgF5i28OkTGe2VhuFXVz7WT/6ORr9dkhGHiZbMPU4TpTCu00+F66k?=
 =?iso-8859-1?Q?4OqwOOgQiCGA3qSNaDDOUg1P3jfF/h3BicJF5L7fZ1NnR2SsHtbJYBzyO+?=
 =?iso-8859-1?Q?pc+UYDCZr5BitnBIcQCcqVqilsXRRUJRRIZDi+PID6Os4wY3FHRk1lnM2o?=
 =?iso-8859-1?Q?pMIGsAmxJebS032WYq7DUDncagOcboyX99aLIEy0sO3tKkqxUS1mTZLrv7?=
 =?iso-8859-1?Q?2VLu+dEUSF+YmmUhd1IlgZ+sXklPuFy5PWT4g9rpeBU1i4yQ9cNIqxo5A0?=
 =?iso-8859-1?Q?7C6yzBAhssAGnslIyd8fI0bY9NSqpohLmOF6k7w5rMigFYsghzW02j/IM1?=
 =?iso-8859-1?Q?xFL5s40RXXPGqaSKfoHdW0BEogW649F08BZ9J+94Qqni3Ua/6XG40zAQJr?=
 =?iso-8859-1?Q?abBNwX0hmPd0UTUeMqwl92De1empZ7DzDra4sC14th22vnWWJfUb3q0pjK?=
 =?iso-8859-1?Q?+nRS8R+dZFTqZUsZpiogGsD4vT1wWvzj4v7s2aTG7oOOWUQSVKpVrWfYIx?=
 =?iso-8859-1?Q?crFGauvUwCXJn2du01TcnFYbFHqeWVh+iO9J/I+QeH9x4ReUP0yKVvUEhO?=
 =?iso-8859-1?Q?lO9VzZp8NaIcGrFaUQd8wmXPvJTln5N8kBFaIwUdJkPzsIUoWFwNIDOERW?=
 =?iso-8859-1?Q?UIIujYbUO57/5XUQwMtlscjzsr09jzbsPrxh26yBQPN9hggOixZErOJffY?=
 =?iso-8859-1?Q?BGO2bTJVK6cBeXwBG5D2e8JsKfJeC89UpOAyPrCPxeF8ajW8qZ0BZRjdzg?=
 =?iso-8859-1?Q?kqpUIEMs0+t5erNehECeLxtS18ntt7TkRGY/Yd8Dux4Z4X2gvK3zee/E8r?=
 =?iso-8859-1?Q?hqUyadRyO1WNtCHZLe+T7IOYD5mXPagrbrcCorHDF2hioWnaPFGYUNgcJ3?=
 =?iso-8859-1?Q?O0a+xUSkVQGOodBs0Kv+AInkukiuMnl/AGp0xu7D39gn+oZi2HP4Pxtnt5?=
 =?iso-8859-1?Q?KQEFN5ivHqgPz/js07p/B4/Z38q8RUuONEweDWdtZ8GO0ySZSJqUIbcFWT?=
 =?iso-8859-1?Q?abGFeIdFe59JwuKhIX2dK3XI5WvfxQ8kA5GdN8bGdB7XiJE/JOG+AtWtSM?=
 =?iso-8859-1?Q?Icts1qyB4+g9PtKrAeU3PxSao6opO5NqEBLMPFxoHfAMw3CGvb880ZRyST?=
 =?iso-8859-1?Q?KOp7TsdCyxTvZYoVrPoonu8ecpEV0IDG5zzIQYZQmkKv/ePRK+z2civaep?=
 =?iso-8859-1?Q?HdYKYVsUqayby/aLjk8Hic5RbYUyB6n2cLeA80FZa6RUUAmP9AgfbQn0eN?=
 =?iso-8859-1?Q?Xg8wYz+qlnNKKmkmGZC7dEUASvkIkKGa0p3LazVPo7rJ/Il0lRhNCOIE/A?=
 =?iso-8859-1?Q?3rzw/1I+DGzHeEp9Wp/WgisCCqhifwjsmF+NVKcNray5njU2TIaBOcFQCo?=
 =?iso-8859-1?Q?CBCpO/VTnuNPkKYsWXF/yaiN07DWwNNrh62Tsoh9lBjxas48ep7q8h8tNj?=
 =?iso-8859-1?Q?3Su9NmjaZsU1NL1xShejdlzJHdzRLi/EidfXJX7omh++cilR+UJU6a+Ab/?=
 =?iso-8859-1?Q?NCAM5nPTeaqSjvKaVWqkwGXl7TKo60IVSyh0KeESCXV/coGzHippIemI/N?=
 =?iso-8859-1?Q?hVspg2gwJDAW2Krlffw1u6KY2tjVw6NP4S7WdzAVKdRDaXSdC2GKVjHg?=
 =?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: 9a0ebecf-2ed4-439c-78a9-08ddff35072d
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 08:48:57.5004
 (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: v3twRJYkCuBELluboHSkAFuK4UUqSqaed9HBmee48Npe6gqDYHi/rbr44ynrG+YxDBfr5wUawCHWoxH1SPJmZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8109

This series implements support for CPU hotplug/unplug on Arm. To achieve th=
is,
several things need to be done:

1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented.
2. timer and GIC maintenance interrupts switched to static irqactions to re=
move
the need for freeing them during release_irq.
3. Enabled the build of xen-hptool on Arm.

Tested on QEMU.

v1->v2:
* see individual patches

Mykyta Poturai (4):
  arm/time: Use static irqaction
  arm/gic: Use static irqaction
  arm/sysctl: Implement cpu hotplug ops
  tools: Allow building xen-hptool without CONFIG_MIGRATE

 config/Tools.mk.in               |  1 +
 tools/configure                  | 30 +++++++++++++++++++++
 tools/configure.ac               |  1 +
 tools/libs/guest/Makefile.common |  4 +++
 tools/misc/Makefile              |  2 +-
 xen/arch/arm/gic.c               | 11 ++++++--
 xen/arch/arm/sysctl.c            | 45 ++++++++++++++++++++++++++++++++
 xen/arch/arm/time.c              | 21 ++++++++++++---
 8 files changed, 108 insertions(+), 7 deletions(-)
 mode change 100755 =3D> 100644 tools/configure

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 08:49:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 08:49:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132650.1470947 (Exim 4.92)
	(envelope-from )
	id 1v39ZI-0007Ub-OO; Mon, 29 Sep 2025 08:49:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132650.1470947; Mon, 29 Sep 2025 08: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 1v39ZI-0007UL-LJ; Mon, 29 Sep 2025 08:49:12 +0000
Received: by outflank-mailman (input) for mailman id 1132650;
 Mon, 29 Sep 2025 08:49: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 1v39ZH-0006Tl-4n
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 08:49:11 +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 2a6f8688-9d11-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 10:49:10 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GV1PR03MB8109.eurprd03.prod.outlook.com
 (2603:10a6:150:20::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 08:48:58 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%7]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 08:48: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: 2a6f8688-9d11-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VIC+SMUpVpFQ058+MlrQHlpAUnkPsV1YrrhOpSTpVa/SCJbhlTZMOnDLallxXOoF+w2K8BsKlf02nw0wvurxViR6GYCMMZs/IZ0Sz5AR0M0aX2BLjmd7VTutcJXB/rh04uf9NqahQ19+/pKxBixU+z4pSc3MBUhNlZ+YP2O8JkxUPsQOgCmPwHmRTyavv52VtNtu8i9Nxb+osKjslMceNYF4iP9yN8Ip9t2wyAoeRYf2UA7YV3/fZ12ZolGIcxsyedOacm0Xqxfu4rc5/ygHhNeyHUbzvEhRchGFiuAqiaWyqytmW83RJPZ+T/sL/XMEW/I1aH9nlzllFTSaeRPBCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mlvqfIOXll0zV3I3wUz5HKPWnEIvUQVemZQu4pOgnbA=;
 b=VqXbYCWmzviurdsXdwZhKCqWv4ea4Eiy09mL73fdZgUOTbQP2Ci+LND+x9GNMiI/Wyr+f9cC9hCpjk3e5BzbpksoHm1R65vKF6NEftgiScVjAZ7l3ZLoW+7NHspmeVMEaxqXnEonSp/fZLFqcnfy7gXdu5xMdCNjZvysYHFhL5On2HWQg7tqaOARbweO6h6Pk0eDKk1A19I8D9bFlJewvbaoxQW701dRxws6EgC1vo50yNIJPqVF8skqrLcQ3w4wXJcjIsCmL3q5RMEIWrGXvLWA9qVT5LHRlphSAwo+UhzNmL9e5ntrVr+GvuCT/T38w0Wc7c8hXHEW0uDktlDQMg==
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=mlvqfIOXll0zV3I3wUz5HKPWnEIvUQVemZQu4pOgnbA=;
 b=uM9Kisbeqakx17oToteKvN+R2QjL9NGZAhtzqEVEMyN9vU58s+2rvt4B02hL0pYDFa7CiZSu67arjVdpPy74p3iI+Hby+A2cSZo2P091hcq8/9YfomvzGr5KJEWR+R0hqr9UHwT9BhVkmgFaiM7P/uqU5XiMjPFjlinGXhLpbewFpIT4ycz0mwTXKfbsTstNY+Yo4v/6nevyDrzufONhhYuTahejZlTXKTOU1n9L5z61jxllB/crrKhk2Eg3NPjDv9IKBtwDUeNoxR2RZKFmdLRGAZvib/a9sWgvQwoEUg9VcLZWUvvn3MCNg6kMVYs1AwCtj15C7wPcUb/RL2V8Vg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v2 1/4] arm/time: Use static irqaction
Thread-Topic: [PATCH v2 1/4] arm/time: Use static irqaction
Thread-Index: AQHcMR3lJIHu++c/a0W9h9fGVQkb6w==
Date: Mon, 29 Sep 2025 08:48:58 +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_|GV1PR03MB8109:EE_
x-ms-office365-filtering-correlation-id: ad39107b-f94d-4496-eb9f-08ddff3507f6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?xVjwIQyu++sDU8svLTgPqkUBE7lcE9mPqp3LjxdI7v7ikXaUv5D+Rbv0az?=
 =?iso-8859-1?Q?w3c8aT4bWQPpyu9x3j23YR1s3/DgmXtKkIyQZ8dJkw+2vAYJa1LF0sveWU?=
 =?iso-8859-1?Q?paS7MB8JJ3tV9+0y/TmErTZT9szWPVjUsTENa4pEYygNfXqTIaig16YP88?=
 =?iso-8859-1?Q?Rp+F+JNBJG9GupE22sRbEHwkkUxvPg2638Tx6HowdnxF1wT4p/HRL30B2e?=
 =?iso-8859-1?Q?rvm0XJuVmBtjgIKosrBZS+7jXpYP+1CEegoHCt91AsYr6dPbZfJdBFuik1?=
 =?iso-8859-1?Q?QYQ+8dVx/mUnI9iseE5DQDeaGM3P6fhH32Pg66LGkYIjxsVyOlnSdYg2nP?=
 =?iso-8859-1?Q?XKqZRH0Wy/8ZMo+lZ4uJKzV6+QJ5r/KCYZYQodLl2HjS0t63arsXDLlrk6?=
 =?iso-8859-1?Q?Ui/2YoyJUkZklas6sCuebVCjLcUDytJHuQT9PV2/dfJeZxF8pZlmCd12QF?=
 =?iso-8859-1?Q?p3P2dYlRudrdhCsTYXODYd43o+MO3ePT4P2MgqsOt8+lSsbXIhcHA9iVCC?=
 =?iso-8859-1?Q?AO8++bpZjFr6Mq3lOCLoHNHfhV64rb3Yp5u5L/24N5dTnb72Bgs+dZUyep?=
 =?iso-8859-1?Q?TMxdf2c8igDNH8+6FiFFO7ZPo0zzr0U1n+ORn0Byg0e2mlsBwd6tyJRyzG?=
 =?iso-8859-1?Q?nfDvJDYXpcCc+WhwGbf0r7vtqonltog7tFg8pOn+dvrWzipQJw0YFWc7PR?=
 =?iso-8859-1?Q?UN/dSKK8/UIWuE4zS+XvvGqXrWjdEbiP5jdJkDKLkviXJUJTDwdiO8P93F?=
 =?iso-8859-1?Q?HNdfpYGtNJz63yTjRZN+i4DKWKenGLX4aJrPKeVn4Fay9ApdeYftqImUXX?=
 =?iso-8859-1?Q?UhwGHjmrrEQZBIwvBZI2yASaHrz0eppveL3Jaao/YtK+XLJykoCUQ14w4J?=
 =?iso-8859-1?Q?jh3+WQgHomp4ipXUTpRC3s+fehEJd9+VKaS4VGss1OJjkQDuJrTnZcRixI?=
 =?iso-8859-1?Q?NdSzxQvm8UaJUlm/L85W4Ak02T3+QOK2mcJtzAiDp8IuIJ8AHToOCnLmI3?=
 =?iso-8859-1?Q?rOgrjMA2lt9xeZpAva9WnGvTxCDU3L3bOQ16P2rlhmEdBYYHSt1JY9r+0a?=
 =?iso-8859-1?Q?fKMZ28V84Nr3XjmLYRq4zXXojUvAvg3vtNIRUUuxdQzbCJP3zaKvvYuSFz?=
 =?iso-8859-1?Q?zykm7+FQ4MvFSsQ5ATv1bub/uxtgKwkxpE6PdIXttttC9i6E3iDVsq1AVj?=
 =?iso-8859-1?Q?mBzhdxLI2X3cQ9WKUPm8/jSEZ9LItIqnvWmQG/8fPoBLK5MlBCLR6BRDS4?=
 =?iso-8859-1?Q?PwHPeDBWyK6w4NL6b3Yy2mY09h6bOxIEY93tOsLo6srS2M2NiXvjKcGhKG?=
 =?iso-8859-1?Q?9n2fff62ND0TeBqHmBLjK8XM8mfAPjuGCXWr4+j6qXeKNK64ZJ6P+hULpb?=
 =?iso-8859-1?Q?adnWhO0chZIURiO4aqIumZysyG8VYo16XarB85IuMLsRj/HGc0QfAQS8xd?=
 =?iso-8859-1?Q?HhsRlYAVRmR2wcpEBn7InJvGZtgF8X2X4MeMqHic7u63gWg+XOmbgwdoDf?=
 =?iso-8859-1?Q?Y8CgfeJ+u7+xD/PmbyUNnOgcHJQeauRT9Ys1yiLpmX1eeOKITbcoV5ok8/?=
 =?iso-8859-1?Q?Nbay4kWteivVjRLmZAGfeS0g7rPh?=
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)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Dnx/E+hnqVqsLDZR4JARDSkjz8rRSnFtE63ub3RNBp1BxlRJm4PJeQogEF?=
 =?iso-8859-1?Q?qzVfOYzY2UlEDnqVbgIX0NUWQokkZSJ3goapXdZOCJLtNo92wL+V+yBVL+?=
 =?iso-8859-1?Q?jL2jZ9350OEGNcFB9w5iDkPP7b1etanbDv7AvtMhewN1iJNrsLcQ54G9Q4?=
 =?iso-8859-1?Q?NNbpJ0ZjGRQF9BKcdMqcY1cNfWJlxF1IW2nxH2gfNZFOG2CvI06ypr0vt8?=
 =?iso-8859-1?Q?Lm6fesmFn3XIvkaMlgvqiQi4wFLYwLRaQYl3R/zseW1f/GkIARoCFtdP08?=
 =?iso-8859-1?Q?Ad5vk3KQWtJaXTmJ8oTpPTJI6FXyXnjwujR409t7fRKqWXQs8S5yoL+9hJ?=
 =?iso-8859-1?Q?z7R4BpRJTw5Z2SUt0dWOKSohWIEsniiAlToxHamP5VV+SYuoePrrM9U6vL?=
 =?iso-8859-1?Q?6FQK2mcH6RStSF0N0npk5cuoFak3kCt1VsL7U9dv+oAvPgWhnpniN4+vFd?=
 =?iso-8859-1?Q?bGgvaMTVKAIPVjB463TqoOave+sQgSWeooYP2iALdJCW7rnvUo82Ew55by?=
 =?iso-8859-1?Q?2boYv+4l+OIcgcmgs/R7ZzBsIh306k6EA0MwZabemdCYR2J1vApMnx7VCs?=
 =?iso-8859-1?Q?pnDyVYPdoeRTwP88lzguB8c1aYBExehO+ZNj9IbqUyJQcCAJND8lQi64Zt?=
 =?iso-8859-1?Q?LjKRy0Dbglv6ilfnuBQw+of/ee18otBifDdphp3a/LZYxbfyrq6cHCnv7b?=
 =?iso-8859-1?Q?fqKgTH69RAJ/UgpMfvgSMFDi0tWW65NDRMVtL+OtveAwSNh4zCHnC/zbRz?=
 =?iso-8859-1?Q?Ny/dqEAIXsMYOaycluMIQmSJ+jRhAE+vQsQC8i+5/PsOmkYLJccYbgdRIg?=
 =?iso-8859-1?Q?6wPJjAMX3BKpNmGIeGdKQXyHdWMtaHcKA6mo/b7SoJyt9zxaR0bYESiSUs?=
 =?iso-8859-1?Q?U3s4RbS6kiJCJTshLSQ/G6K579U5YPiecHy0JbOcYvPihtvMQy+TH00Yy3?=
 =?iso-8859-1?Q?TheNOeqVe/Nha/NuNRK3UEXmZ9NEj4yXxHLuCrEdtL2PlBkdch9vwGVdM8?=
 =?iso-8859-1?Q?9vcE/QpqqkXQwEC0urRXu/S2c6+buFYUB3XD3beVkQv01fDdLZnRvN6srb?=
 =?iso-8859-1?Q?B/5ZbI0kyBmvXH44wS0qi8nI98Xr3cfcKIZmikMN6tR4vPBi5kIbGD8wki?=
 =?iso-8859-1?Q?yqBeARPi1ZbjhgCHi/8gMi0ZJ1pQibtTeMZSssngZKpjwTjzwyRbc9CHB0?=
 =?iso-8859-1?Q?9cqo3YGAvQAB4rX79+C2hD5bo7UwJW94hbAwvJ3wDZI5R+z/vK1yEqJZyR?=
 =?iso-8859-1?Q?kwL/ti4kg2BT9NQjimmgKP0/9pXDBUL7C2yc2ABAtRkxx6c61ati9GfV1Q?=
 =?iso-8859-1?Q?vI5o1+/1BEyE9D7hMJ3YXhBrYJb6TwGNzg40k0SqYo21jqJd9pSoXs5oSL?=
 =?iso-8859-1?Q?h479tAVIqjfsEx0D2CkeDoh69H6czO69LRAN5wDJOoNpuXos1nUFwZaPgZ?=
 =?iso-8859-1?Q?QxxH2aQ9tSri6eQgmwUa+8uAsgkCJ2E4P+81K1P8IAY2Yh7nQm/hb/9+pw?=
 =?iso-8859-1?Q?crgoe9hmoQU+INkGJ3ncxLf76EZyAvMkyqAR7fkhxQgdeN3IqK5aZtX3JW?=
 =?iso-8859-1?Q?mZ8dqC8agR7EfhZ8Y46ztPP052YNCpJUXRXlhQPqMqcXBerkTyQB9g+b/k?=
 =?iso-8859-1?Q?u60KP/JwXzvDMak7S5ydvvP5AlHktub+acMqtVz5oe4Ox5zWgdkKIuaA?=
 =?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: ad39107b-f94d-4496-eb9f-08ddff3507f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 08:48:58.2487
 (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: 4QcnLRyvRJN7sVDCidvQasH3mvcnHKyoxO09wEwZK47inFpF6+29OluyfpZqyE0Ytcpot9CZzUkXjk7necmP0Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8109

When stopping a core deinit_timer_interrupt is called in non-alloc
context, which causes xfree in release_irq to fail an assert.

To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.

Signed-off-by: Mykyta Poturai 

v1->v2:
* Use percpu actions
---
 xen/arch/arm/time.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index e74d30d258..59349467de 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -303,9 +303,15 @@ static void check_timer_irq_cfg(unsigned int irq, cons=
t char *which)
            "WARNING: %s-timer IRQ%u is not level triggered.\n", which, irq=
);
 }
=20
+DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_hyp);
+DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_virt);
+
 /* Set up the timer interrupt on this CPU */
 void init_timer_interrupt(void)
 {
+    struct irqaction *hyp_action =3D &this_cpu(irq_hyp);
+    struct irqaction *virt_action =3D &this_cpu(irq_virt);
+
     /* Sensible defaults */
     WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
     /* Do not let the VMs program the physical timer, only read the physic=
al counter */
@@ -314,10 +320,17 @@ void init_timer_interrupt(void)
     WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
     isb();
=20
-    request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt,
-                "hyptimer", NULL);
-    request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt,
-                   "virtimer", NULL);
+    hyp_action->name =3D "hyptimer";
+    hyp_action->handler =3D htimer_interrupt;
+    hyp_action->dev_id =3D NULL;
+    hyp_action->free_on_release =3D 0;
+    setup_irq(timer_irq[TIMER_HYP_PPI], 0, hyp_action);
+
+    virt_action->name =3D "virtimer";
+    virt_action->handler =3D vtimer_interrupt;
+    virt_action->dev_id =3D NULL;
+    virt_action->free_on_release =3D 0;
+    setup_irq(timer_irq[TIMER_VIRT_PPI], 0, virt_action);
=20
     check_timer_irq_cfg(timer_irq[TIMER_HYP_PPI], "hypervisor");
     check_timer_irq_cfg(timer_irq[TIMER_VIRT_PPI], "virtual");
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 09:52:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 09:52:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132707.1470958 (Exim 4.92)
	(envelope-from )
	id 1v3AYj-0000Mk-D7; Mon, 29 Sep 2025 09:52:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132707.1470958; Mon, 29 Sep 2025 09:52: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 1v3AYj-0000Md-9C; Mon, 29 Sep 2025 09:52:41 +0000
Received: by outflank-mailman (input) for mailman id 1132707;
 Mon, 29 Sep 2025 09:52:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3AYh-0000MX-Sk
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 09:52:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3AYh-00GUPl-1g;
 Mon, 29 Sep 2025 09:52:39 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (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 1v3AYh-0048hk-1J;
 Mon, 29 Sep 2025 09:52: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=iMuyQZPdTH+a8RmxJeht35K4zZ8tC1oTItv0gz2XNoM=; b=CBcR0JCQc2lemgtVmLf3m/e6aS
	hD6j60gtJ4Pp7hf2g4oCWNjeTdW2EgK7fAmikIK21uZOEJ4uQdsGEukVse8l6/4MzQeJ8lKL/dP0Y
	Bup+rz3tw+om6VvN9IUvEw2qGI9daGod7Z2HfR7KwtBfck1/uY+KnfitGWGj9pbO2SRo=;
Date: Mon, 29 Sep 2025 11:52:37 +0200
From: Anthony PERARD 
To: Jason Andryuk 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [XEN PATCH 06/11] libxl: convert libxl__json_object_to_yajl_gen
 to libxl__json_object_to_libjsonc_object
Message-ID: 
References: <20250808145602.41716-1-anthony@xenproject.org>
 <20250808145602.41716-7-anthony@xenproject.org>
 <10a60455-a4d2-4c58-8a80-d8b264d27efd@amd.com>
 
 <16e4818f-685c-4c5c-81a8-2dbac86ba0e2@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16e4818f-685c-4c5c-81a8-2dbac86ba0e2@amd.com>

On Sun, Aug 31, 2025 at 10:51:53AM -0400, Jason Andryuk wrote:
> On 2025-08-29 09:56, Anthony PERARD wrote:
> > On Wed, Aug 27, 2025 at 11:37:07AM -0400, Jason Andryuk wrote:
> > > On 2025-08-08 10:55, Anthony PERARD wrote:
> > > > +    case JSON_NUMBER:
> > > > +        *jso_out = json_object_new_string(obj->u.string);
> > > 
> > > Is JSON_NUMBER calling json_object_new_string() correct?  It looks like the
> > > yajl code falls back to a string, so that is okay but surprising.
> > 
> > Yeah, I think that's correct.
> > :-( maybe not. Even if we have these too comments:
> > 
> >      In libxl_internal.h, enum libxl__json_node_type:
> >          /* number is store in string, it's too big to be a long long or a double */
> >          JSON_NUMBER  = (1 << 4),
> > 
> >      In json_callback_number():
> >          /* If the conversion fail, we just store the original string. */
> > 
> > With yajl, we call yajl_gen_number(), which probably write 2^128 as:
> > 
> >      340282366920938463463374607431768211456
> > 
> > but this new json-c generator would write instead:
> > 
> >      "340282366920938463463374607431768211456"
> > 
> > I guess we might be able to replicate the same behavior by using
> > json_object_set_serializer() or json_object_new_double_s() (which use
> > the former). But I don't know if it is worth the effort. I hope we won't
> > have int bigger than 64 bits.
> 
> I didn't check, but I thought uint64_t is the biggest size libxl uses.

Yes, but we also parse json that are produce else where. (could be file
saved by libxl, but also json produced by QEMU)

Anywhy, I investitaged this a bit, and it's very unlikely that a
`JSON_NUMBER` would be created, so it's even less likely that this
`case` would happen. But I've change the call to
`json_object_new_string` by:

    /*
     * Use json_object_new_double_s() to rewrite the number exactly as
     * we parsed it. When generating the JSON string the value `0` will
     * be ignored and `obj->u.string` will be written instead.
     */
    *jso_out = json_object_new_double_s(0, obj->u.string);

That way, we get the same json blob, with both library.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 11:08:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 11:08:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132720.1470968 (Exim 4.92)
	(envelope-from )
	id 1v3BjO-0008U7-FC; Mon, 29 Sep 2025 11:07:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132720.1470968; Mon, 29 Sep 2025 11:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3BjO-0008U0-C2; Mon, 29 Sep 2025 11:07:46 +0000
Received: by outflank-mailman (input) for mailman id 1132720;
 Mon, 29 Sep 2025 11:07:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3BjN-0008Tu-ES
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 11:07: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 85a59671-9d24-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 13:07: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-out2.suse.de (Postfix) with ESMTPS id CE36B3153D;
 Mon, 29 Sep 2025 11:07: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 62D0513782;
 Mon, 29 Sep 2025 11:07: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 2duuFn5o2mjxaAAAD6G6ig
 (envelope-from ); Mon, 29 Sep 2025 11: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: 85a59671-9d24-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759144062; 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=iikqELbpseuYA4fvEYgaaCxqgP1sKetcKtWyVLM4CE4=;
	b=g1Lb1gOQpnwXF+gQVOsXgoeXajCdMoD4C2qYG9jyaRDiyzvbZU37xXXt8XVMc/iZmH9edk
	xMOkw1Jwi2Mp1y50HXuumukZFbh+SBFfuKOroMFu/hzncHTPY6feaomcp5gDGxE+ZGUOj5
	TAovISf9S258+C+GuCU5VF/o184QgWI=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=g1Lb1gOQ
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759144062; 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=iikqELbpseuYA4fvEYgaaCxqgP1sKetcKtWyVLM4CE4=;
	b=g1Lb1gOQpnwXF+gQVOsXgoeXajCdMoD4C2qYG9jyaRDiyzvbZU37xXXt8XVMc/iZmH9edk
	xMOkw1Jwi2Mp1y50HXuumukZFbh+SBFfuKOroMFu/hzncHTPY6feaomcp5gDGxE+ZGUOj5
	TAovISf9S258+C+GuCU5VF/o184QgWI=
Message-ID: <5f6871b5-243c-457f-82f7-47246b6ef6ea@suse.com>
Date: Mon, 29 Sep 2025 13:07:41 +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
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 
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>
 <7047440a-0419-4982-961b-46f9b90a86e9@zytor.com>
 <6eb60b62-bd3a-4a64-9665-fc911cc7d869@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: <6eb60b62-bd3a-4a64-9665-fc911cc7d869@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------PXMgO3JbmBo5moltJRZPfnkF"
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: CE36B3153D
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [-6.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	RCPT_COUNT_TWELVE(0.00)[14];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]
X-Spam-Score: -6.41

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------PXMgO3JbmBo5moltJRZPfnkF
Content-Type: multipart/mixed; boundary="------------SFV1VnAbY3HH96F5ZtO1vdQI";
 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: <5f6871b5-243c-457f-82f7-47246b6ef6ea@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>
 <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@suse.com>
 <7047440a-0419-4982-961b-46f9b90a86e9@zytor.com>
 <6eb60b62-bd3a-4a64-9665-fc911cc7d869@suse.com>
In-Reply-To: <6eb60b62-bd3a-4a64-9665-fc911cc7d869@suse.com>

--------------SFV1VnAbY3HH96F5ZtO1vdQI
Content-Type: multipart/mixed; boundary="------------ct5bAGbTyiqKBNoXLfZDlBc3"

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

T24gMjYuMDguMjUgMTI6MzksIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+IE9uIDI1LjA4LjI1
IDAzOjU0LCBYaW4gTGkgd3JvdGU6DQo+PiBPbiA2LzExLzIwMjUgNTo1OCBBTSwgSnVlcmdl
biBHcm9zcyB3cm90ZToNCj4+PiBJJ20ganVzdCBkb2luZyBhIFYyIG9mIG15IHNlcmllcywg
YnV0IHRoaXMgdGltZSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uYWwNCj4+PiBzdXBwb3J0IG9m
IHRoZSBub24tc2VyaWFsaXppbmcgYW5kIGltbWVkaWF0ZSBmb3Jtcy4gTGV0cyBzZWUgaG93
IHRoaXMgd2lsbA0KPj4+IGxvb2sgbGlrZS4gSSB3aWxsIGRyb3AgdXNpbmcgdGhlIEVBWF9F
RFhfKiBtYWNyb3MsIGJ1dCBkdWUgdG8gdGhlIHJlYXNvbg0KPj4+IG1lbnRpb25lZCBhYm92
ZSBJIHdvbid0IHN3aXRjaCB0byB5b3VyIHZhcmlhbnQgY29tcGxldGVseS4NCj4+DQo+PiBI
aSBKdWVyZ2VuLA0KPj4NCj4+IERvIHlvdSBoYXZlIGFueSB1cGRhdGUgb24gdGhpcz8NCj4g
DQo+IEkndmUgYmVlbiB2ZXJ5IGJ1c3kgd2l0aCBvdGhlciBzdHVmZiAoZG93bnN0cmVhbSwg
c2VjdXJpdHksIC4uLikuDQo+IA0KPiBJbiBiZXR3ZWVuIEkndmUgYmVlbiB3b3JraW5nIG9u
IHRoZSBzZXJpZXMuIEkgaG9wZSB0byBwb3N0IGl0IHNvbWUgdGltZSBpbg0KPiBTZXB0ZW1i
ZXIuDQoNCkkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyB0aGUgbGFzdCB3ZWVrLg0KDQpU
dXJucyBvdXQgdGhpbmdzIGFyZSBhIGxpdHRsZSBiaXQgY29tcGxpY2F0ZWQgZm9yIGFkZGlu
ZyB0aGVtIGludG8gdGhlDQpwYXJhdmlydCBmcmFtZXdvcmssIGVzcGVjaWFsbHkgcmVnYXJk
aW5nIHRoZSBleGNlcHRpb24gZml4dXBzLg0KDQpJIGZpcnN0IHRob3VnaHQgdGhhdCBQZXRl
cidzIHBhdGNoICJ4ODYvZXh0YWJsZTogSW1wbGVtZW50IEVYX1RZUEVfRlVOQ19SRVdJTkQi
DQp3b3VsZCBoZWxwLCBidXQgSSdtIHNlZWluZyBwcm9ibGVtcyB3aXRoIGhpcyBhcHByb2Fj
aCBpbiBjYXNlIG9mIHNoYWRvdyBzdGFjaw0KYmVpbmcgZW5hYmxlZC4gVGhpcyBjYXNlIHdv
dWxkIGF0IGxlYXN0IG5lZWRlZCB0byBiZSBoYW5kbGVkIGluIGhpcyBwYXRjaCwgYXMNCm90
aGVyd2lzZSBzaGFkb3cgc3RhY2sgYW5kIG5vcm1hbCBzdGFjayBjb3VsZCBnZXQgb3V0IG9m
IHN5bmMuDQoNCkZvciB0aGlzIHJlYXNvbiB5b3VyIHBhdGNoIHNlcmllcyB3b24ndCB3b3Jr
IGVhc2lseSwgdG9vLg0KDQpPVE9IIHVzaW5nIHlvdXIgYmFzaWMgaWRlYSBpdCBzZWVtcyB0
byBiZSBwb3NzaWJsZSB0byBzb2x2ZSB0aGUgZml4dXAgcHJvYmxlbQ0Kd2l0aG91dCBuZWVk
aW5nIFBldGVyJ3MgcGF0Y2guIEknbSB3b3JraW5nIG9uIHRoYXQgYXBwcm9hY2ggbm93Lg0K
DQoNCkp1ZXJnZW4NCg==
--------------ct5bAGbTyiqKBNoXLfZDlBc3
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-----

--------------ct5bAGbTyiqKBNoXLfZDlBc3--

--------------SFV1VnAbY3HH96F5ZtO1vdQI--

--------------PXMgO3JbmBo5moltJRZPfnkF
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/Ey8FAmjaaH0FAwAAAAAACgkQsN6d1ii/Ey8t
3gf+K2bpqm9A2Bf+03hK9ezhDmN2XLWIGetjUIte/abiUhznYGBPv1YpcZXn6M4upfVEqKkTu5YL
bzpPdahyj23m3tIEjObgeclxs27XyWuugXs1bC3qYmo+ukRdh9FejTCbKmkEXU0jZZNAdbaC6Zc0
AAYppXjQR0yuMoBCHWhnsCUZCeK9N3DBzNlqdxFEZibJyFfFn5891zS4SFTlUzusAhX2sQKKW9Hy
TUGIYYosZCpz2aZIWVfNTi7/cIqU8kHSga8FsGC2srogDAYTWbHM1fipHwOj2tJkXkrGv5HLzJV1
WZ7KY04cFr8c0oK1Vzzy25tZliSs5YsA8Omog9ksWA==
=BL2H
-----END PGP SIGNATURE-----

--------------PXMgO3JbmBo5moltJRZPfnkF--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132744.1471034 (Exim 4.92)
	(envelope-from )
	id 1v3Cfm-0000C7-QI; Mon, 29 Sep 2025 12:08:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132744.1471034; Mon, 29 Sep 2025 12:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Cfm-0000Bm-IP; Mon, 29 Sep 2025 12:08:06 +0000
Received: by outflank-mailman (input) for mailman id 1132744;
 Mon, 29 Sep 2025 12:08:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfk-0008MS-Uh
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfk-00GXBl-20;
 Mon, 29 Sep 2025 12:08:04 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfk-004JHo-27;
 Mon, 29 Sep 2025 12:08: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=fd7IuQgDa95R64KYB4tblr0/98vW3XrqIHcr4eD97H4=; b=X203g5Yaxw9Ll+3MS5VUb9EOPi
	w5Q0flPWQK2T15TGrMdaV33NAB4xY5urY6whyNrUQ2EvLO0pzsNQ18lYaAs2LlVUMiiewvGOZ0vpf
	iFpihfU64n9aPKFtXy2ADhSU4ioWSLgaVSOytyYFxtZRQHhehyp2gvzm0+MaHXwJZEvk=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Jason Andryuk ,
	Juergen Gross 
Subject: [XEN PATCH v2 6/8] tools/libxenstat: Use json-c when available
Date: Mon, 29 Sep 2025 14:07:54 +0200
Message-ID: <20250929120756.46075-7-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

This is mainly a copy of the existing code in yajl and use json-c
instead.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jason Andryuk 
---

Notes:
    v2:
    - use new $(XEN_JSON_LIBS)

 tools/libs/stat/Makefile      |   2 +-
 tools/libs/stat/xenstat_qmp.c | 126 ++++++++++++++++++++++++++++++++--
 2 files changed, 120 insertions(+), 8 deletions(-)

diff --git a/tools/libs/stat/Makefile b/tools/libs/stat/Makefile
index a968eaff48..3151ee9f12 100644
--- a/tools/libs/stat/Makefile
+++ b/tools/libs/stat/Makefile
@@ -24,7 +24,7 @@ OBJS-$(CONFIG_SunOS) += xenstat_solaris.o
 OBJS-$(CONFIG_NetBSD) += xenstat_netbsd.o
 OBJS-$(CONFIG_FreeBSD) += xenstat_freebsd.o
 
-LDLIBS-y += -lyajl
+LDLIBS-y += $(XEN_JSON_LIBS)
 LDLIBS-$(CONFIG_SunOS) += -lkstat
 LDLIBS += $(LDLIBS-y)
 
diff --git a/tools/libs/stat/xenstat_qmp.c b/tools/libs/stat/xenstat_qmp.c
index 9909b9727e..21e321fffa 100644
--- a/tools/libs/stat/xenstat_qmp.c
+++ b/tools/libs/stat/xenstat_qmp.c
@@ -24,6 +24,10 @@
 
 #include "xenstat_priv.h"
 
+#ifdef HAVE_LIBJSONC
+#include 
+
+#elif defined(HAVE_LIBYAJL)
 #ifdef HAVE_YAJL_YAJL_VERSION_H
 #  include 
 #endif
@@ -32,11 +36,13 @@
 #if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
 #  define HAVE_YAJL_V2 1
 #endif
+#endif
 
 #ifdef HAVE_YAJL_V2
-
 #include 
+#endif
 
+#if defined(HAVE_LIBJSONC) || defined(HAVE_YAJL_V2)
 static unsigned char *qmp_query(int, const char *);
 
 enum query_blockstats {
@@ -76,9 +82,10 @@ enum query_block {
             "type": 'str'
           }]}
 */
-static char *qmp_get_block_image(xenstat_node *node, char *qmp_devname, int qfd)
+static char *qmp_get_block_image(xenstat_node *node, const char *qmp_devname, int qfd)
 {
-	char *tmp, *file = NULL;
+	const char *tmp;
+	char *file = NULL;
 	const char *query_block_cmd = "{ \"execute\": \"query-block\" }";
 	static const char *const qblock[] = {
 		[ QMP_BLOCK_RETURN  ] = "return",
@@ -88,13 +95,56 @@ static char *qmp_get_block_image(xenstat_node *node, char *qmp_devname, int qfd)
 	};
 	const char *ptr[] = {0, 0};
 	unsigned char *qmp_stats;
-	yajl_val info, ret_obj, dev_obj, n;
 	int i;
 
 	if ((qmp_stats = qmp_query(qfd, query_block_cmd)) == NULL)
 		return NULL;
 
+#ifdef HAVE_LIBJSONC
+	json_object *jso;
+	enum json_tokener_error error;
+	jso = json_tokener_parse_verbose((const char *)qmp_stats, &error);
+	free(qmp_stats);
+	if (jso == NULL)
+		return NULL;
+
+	ptr[0] = qblock[QMP_BLOCK_RETURN]; /* "return" */
+	json_object *ret_jso = json_object_object_get(jso, ptr[0]);
+	if (ret_jso == NULL)
+		goto done;
+
+	for (i=0; i
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132739.1470982 (Exim 4.92)
	(envelope-from )
	id 1v3Cfi-0007Sl-0f; Mon, 29 Sep 2025 12:08:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132739.1470982; Mon, 29 Sep 2025 12:08: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 1v3Cfh-0007S2-So; Mon, 29 Sep 2025 12:08:01 +0000
Received: by outflank-mailman (input) for mailman id 1132739;
 Mon, 29 Sep 2025 12:08:00 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfg-0007Ps-8g
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:00 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cff-00GXAq-0J;
 Mon, 29 Sep 2025 12:07:59 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cff-004JHo-09;
 Mon, 29 Sep 2025 12:07: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	Message-ID:Date:Subject:Cc:To:From;
	bh=TU+wA/sAxbsVpGInZfyIKwiXz4Vj5F3tSnBd/r/PMf8=; b=xDFVhAvoijcbp3rwapDHBMCdJJ
	fIE9h0yFs7sD7l0p4oj9HRsQCi8ghYiTRLIHiD/fedNEwMSHXsqlUDHPQ/NQbv0rq5TETzJGMOcii
	cXyPDygZL3sGlvqngMe+0TOqDrRfPBtbYhXrirAhw1RujXTvznzM21e5IoGYbg+cNziI=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Oleksii Kurochko ,
	Stefano Stabellini ,
	Andrew Cooper ,
	Julien Grall ,
	Juergen Gross ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Michal Orzel ,
	Community Manager 
Subject: [XEN PATCH v2 0/8] Allow to build libxl and other tools with json-c instead of yajl
Date: Mon, 29 Sep 2025 14:07:48 +0200
Message-ID: <20250929120756.46075-1-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
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.libxl-libjsonc-v2

changes in v2:
- introduce $(XEN_JSON_LIBS) to have either -lyajl or -ljson-c or both (for a
  short while).
- few more changes detail in each patches.

Hi,

The library YAJL has been unmaintained for several years, without an obvious
fork to pick.

On the other and the library json-c is been maintained and use by several other
project, it's probably already installed on your machine. So this patch series
intend to allow to build the Xen toolstack again json-c, and forgo yajl.

Just in case, YAJL is can still be used.

There's bit of libxl API that exposes YAJL, mainly so it can be used by `xl` to
call libxl_domain_config_gen_json(). It was exposed via the "libxl_json.h"
headers. This functions and others won't be available when libxl is build
against json-c.

Cheers,

Anthony PERARD (8):
  tools/configure: Introduce deps on json-c lib for libxl
  libxl: Convert libxl__json_parse() to use json-c
  libxl: convert libxl__json_object_to_yajl_gen to
    libxl__json_object_to_libjsonc_object
  libxl: libxl__object_to_json() to json-c
  libxl: convert libxl__json_object_to_json() to json_object
  tools/libxenstat: Use json-c when available
  configure: Use json-c by default, fallback to yajl
  Update CHANGELOG and README with dependency on json-c

 CHANGELOG.md                              |   2 +
 README                                    |   2 +-
 config/Tools.mk.in                        |   1 +
 tools/config.h.in                         |   3 +
 tools/configure                           | 136 +++++-
 tools/configure.ac                        |  10 +-
 tools/include/libxl_json.h                |  27 ++
 tools/libs/light/Makefile                 |   6 +-
 tools/libs/light/gentypes.py              | 160 +++++-
 tools/libs/light/idl.py                   |   7 +-
 tools/libs/light/libxl_cpuid.c            | 119 +++++
 tools/libs/light/libxl_internal.h         |  23 +-
 tools/libs/light/libxl_json.c             | 562 +++++++++++++++++++++-
 tools/libs/light/libxl_qmp.c              |  53 ++
 tools/libs/light/libxl_types.idl          |   7 +-
 tools/libs/light/libxl_types_internal.idl |   3 +-
 tools/libs/stat/Makefile                  |   2 +-
 tools/libs/stat/xenstat_qmp.c             | 126 ++++-
 tools/xl/Makefile                         |   2 +-
 tools/xl/xl_info.c                        | 102 +++-
 20 files changed, 1312 insertions(+), 41 deletions(-)

-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132743.1471028 (Exim 4.92)
	(envelope-from )
	id 1v3Cfm-00007n-BK; Mon, 29 Sep 2025 12:08:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132743.1471028; Mon, 29 Sep 2025 12:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Cfm-00007Y-6y; Mon, 29 Sep 2025 12:08:06 +0000
Received: by outflank-mailman (input) for mailman id 1132743;
 Mon, 29 Sep 2025 12:08:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfj-0008DS-V9
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfj-00GXBd-2J;
 Mon, 29 Sep 2025 12:08:03 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfj-004JHo-2M;
 Mon, 29 Sep 2025 12:08: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=7z8q2jx9Z85Tq8/zLDVB0fdB1L9QpzjX78jo8wa3bT0=; b=HLJzgLIkTM1mPA8GjhtyzC+/m4
	0VNpQPeN7gQnNYhhNAzpn3Ws5GxjwgcrgWs7TXCSdFCCGXicnmq6TQkLj+Jr5e0eAE+e1qreco8r3
	V/sz6dP7atBoaUyoaXNkMemnamn4zIIOffbkZBXvLeGuQ/6wnou2x5NlQaI6lBivewPg=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Jason Andryuk ,
	Juergen Gross 
Subject: [XEN PATCH v2 5/8] libxl: convert libxl__json_object_to_json() to json_object
Date: Mon, 29 Sep 2025 14:07:53 +0200
Message-ID: <20250929120756.46075-6-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

But keep the implementation done for YAJL.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jason Andryuk 
---
 tools/libs/light/libxl_json.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/tools/libs/light/libxl_json.c b/tools/libs/light/libxl_json.c
index eeda9c301d..c76ae9f64a 100644
--- a/tools/libs/light/libxl_json.c
+++ b/tools/libs/light/libxl_json.c
@@ -104,10 +104,12 @@ typedef struct libxl__yajl_ctx {
  * YAJL Helper
  */
 
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str)
 {
     return yajl_gen_string(hand, (const unsigned char *)str, strlen(str));
 }
+#endif
 
 #ifdef HAVE_LIBJSONC
 int libxl__enum_gen_jso(json_object **jso_r, const char *str)
@@ -1527,6 +1529,29 @@ char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
 char *libxl__json_object_to_json(libxl__gc *gc,
                                  const libxl__json_object *args)
 {
+#ifdef HAVE_LIBJSONC
+    const char *buf;
+    json_object *root;
+    char *ret = NULL;
+    int rc;
+
+    if (!args)
+        return NULL;
+
+    rc = libxl__json_object_to_json_object(gc, &root, args);
+    if (rc)
+        goto out;
+
+    buf = json_object_to_json_string_ext(root, JSON_C_TO_STRING_PRETTY);
+    if (!buf)
+        goto out;
+
+    ret = libxl__strdup(gc, buf);
+
+out:
+    json_object_put(root);
+    return ret;
+#elif defined(HAVE_LIBYAJL)
     const unsigned char *buf;
     libxl_yajl_length len;
     yajl_gen_status s;
@@ -1554,6 +1579,7 @@ char *libxl__json_object_to_json(libxl__gc *gc,
 out:
     yajl_gen_free(hand);
     return ret;
+#endif
 }
 
 #ifdef HAVE_LIBJSONC
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132745.1471039 (Exim 4.92)
	(envelope-from )
	id 1v3Cfn-0000Fe-4B; Mon, 29 Sep 2025 12:08:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132745.1471039; Mon, 29 Sep 2025 12:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Cfm-0000Er-R9; Mon, 29 Sep 2025 12:08:06 +0000
Received: by outflank-mailman (input) for mailman id 1132745;
 Mon, 29 Sep 2025 12:08:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfl-0008Sd-FG
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfl-00GXBu-14;
 Mon, 29 Sep 2025 12:08:05 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfl-004JHo-1B;
 Mon, 29 Sep 2025 12:08: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" 
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=9LmUJ4zuB4olL3YoOObx5zrJYD33c+ZXbGLTgVb/atI=; b=etrR+Ma3DnJFtNc9fa0KgGf8Wy
	o3eW5hATHhPH20+szrlhm+XcQRrzjX/uvHt9dipP1yk3p86dxvckIhKZJg+MzVHGIitZBnKC4IBgq
	ttdIWQgdw6OqAfoemb5LyWKffJ04WxBeZKgjZV9E0z8ImVT6YpYZBWmqXz8TJLTOrF6g=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
Subject: [XEN PATCH v2 7/8] configure: Use json-c by default, fallback to yajl
Date: Mon, 29 Sep 2025 14:07:55 +0200
Message-ID: <20250929120756.46075-8-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
---
 tools/configure    | 97 +++++++++++++++++++++++++++++-----------------
 tools/configure.ac | 12 +++---
 2 files changed, 69 insertions(+), 40 deletions(-)

diff --git a/tools/configure b/tools/configure
index edd1701b2d..0eb7a0ab6a 100755
--- a/tools/configure
+++ b/tools/configure
@@ -9692,41 +9692,7 @@ fi
 	# Put the nasty error message in config.log where it belongs
 	echo "$libjsonc_PKG_ERRORS" >&5
 
-	as_fn_error $? "Package requirements (json-c) were not met:
-
-$libjsonc_PKG_ERRORS
-
-Consider adjusting the PKG_CONFIG_PATH environment variable if you
-installed software in a non-standard prefix.
-
-Alternatively, you may set the environment variables libjsonc_CFLAGS
-and libjsonc_LIBS to avoid the need to call pkg-config.
-See the pkg-config man page for more details." "$LINENO" 5
-elif test $pkg_failed = untried; then
-     	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: no" >&5
-printf "%s\n" "no" >&6; }
-	{ { printf "%s\n" "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
-printf "%s\n" "$as_me: error: in \`$ac_pwd':" >&2;}
-as_fn_error $? "The pkg-config script could not be found or is too old.  Make sure it
-is in your PATH or set the PKG_CONFIG environment variable to the full
-path to pkg-config.
-
-Alternatively, you may set the environment variables libjsonc_CFLAGS
-and libjsonc_LIBS to avoid the need to call pkg-config.
-See the pkg-config man page for more details.
-
-To get pkg-config, see .
-See \`config.log' for more details" "$LINENO" 5; }
-else
-	libjsonc_CFLAGS=$pkg_cv_libjsonc_CFLAGS
-	libjsonc_LIBS=$pkg_cv_libjsonc_LIBS
-        { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: yes" >&5
-printf "%s\n" "yes" >&6; }
-
-printf "%s\n" "#define HAVE_LIBJSONC 1" >>confdefs.h
-
-fi
-{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
+	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 printf %s "checking for yajl_alloc in -lyajl... " >&6; }
 if test ${ac_cv_lib_yajl_yajl_alloc+y}
 then :
@@ -9772,6 +9738,67 @@ else $as_nop
   as_fn_error $? "Could not find yajl" "$LINENO" 5
 fi
 
+
+elif test $pkg_failed = untried; then
+     	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: no" >&5
+printf "%s\n" "no" >&6; }
+	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
+printf %s "checking for yajl_alloc in -lyajl... " >&6; }
+if test ${ac_cv_lib_yajl_yajl_alloc+y}
+then :
+  printf %s "(cached) " >&6
+else $as_nop
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lyajl  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+char yajl_alloc ();
+int
+main (void)
+{
+return yajl_alloc ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"
+then :
+  ac_cv_lib_yajl_yajl_alloc=yes
+else $as_nop
+  ac_cv_lib_yajl_yajl_alloc=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.beam \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_alloc" >&5
+printf "%s\n" "$ac_cv_lib_yajl_yajl_alloc" >&6; }
+if test "x$ac_cv_lib_yajl_yajl_alloc" = xyes
+then :
+  YAJL_LIBS=-lyajl
+
+
+printf "%s\n" "#define HAVE_LIBYAJL 1" >>confdefs.h
+
+else $as_nop
+  as_fn_error $? "Could not find yajl" "$LINENO" 5
+fi
+
+
+else
+	libjsonc_CFLAGS=$pkg_cv_libjsonc_CFLAGS
+	libjsonc_LIBS=$pkg_cv_libjsonc_LIBS
+        { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: yes" >&5
+printf "%s\n" "yes" >&6; }
+
+printf "%s\n" "#define HAVE_LIBJSONC 1" >>confdefs.h
+
+fi
+
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz" >&5
 printf %s "checking for deflateCopy in -lz... " >&6; }
 if test ${ac_cv_lib_z_deflateCopy+y}
diff --git a/tools/configure.ac b/tools/configure.ac
index bb40b5b3f0..7267d02a04 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -425,11 +425,13 @@ AC_SUBST([ZLIB_LIBS])
 AX_CHECK_EXTFS
 AX_CHECK_PTHREAD
 PKG_CHECK_MODULES([libjsonc], [json-c],
-    [AC_DEFINE([HAVE_LIBJSONC], [1], [Use library json-c])])
-AC_CHECK_LIB([yajl], [yajl_alloc],
-   [AC_SUBST([YAJL_LIBS],[-lyajl])
-    AC_DEFINE([HAVE_LIBYAJL],[1],[Define to 1 if you have the `yajl' library (-lyajl).])],
-    [AC_MSG_ERROR([Could not find yajl])])
+    [AC_DEFINE([HAVE_LIBJSONC], [1], [Use library json-c])],
+    [AC_CHECK_LIB([yajl], [yajl_alloc],
+        [AC_SUBST([YAJL_LIBS],[-lyajl])
+         AC_DEFINE([HAVE_LIBYAJL],[1],[Define to 1 if you have the `yajl' library (-lyajl).])],
+        [AC_MSG_ERROR([Could not find yajl])])
+])
+
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])
 AC_CHECK_HEADER([argp.h], [
 AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags="-largp"])
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132740.1470987 (Exim 4.92)
	(envelope-from )
	id 1v3Cfi-0007X9-A6; Mon, 29 Sep 2025 12:08:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132740.1470987; Mon, 29 Sep 2025 12:08: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 1v3Cfi-0007WN-4y; Mon, 29 Sep 2025 12:08:02 +0000
Received: by outflank-mailman (input) for mailman id 1132740;
 Mon, 29 Sep 2025 12:08:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfh-0007Q3-2M
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfg-00GXB3-2U;
 Mon, 29 Sep 2025 12:08:00 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfg-004JHo-2a;
 Mon, 29 Sep 2025 12:08: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=U48btwyJU9uvDQVplZTudvitSWkJbIw5OvKyUBUKozM=; b=ztZtTQFGGsBFuEkgZBeghumveO
	irYazE1PvvQ+bhmwLWfpa+e+/Hi3ZV1smhGm5n7E+xKFAYMtKgep6MKcSTjigL7yN9lk0bk2F01zn
	p3J6edxwYiSrCQ2vZmPmbkCaTdjL7jAVK6IjcSLnfDnY/Ff9MRH0PiBKGLp5XFEjL7Z4=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Jason Andryuk ,
	Juergen Gross 
Subject: [XEN PATCH v2 2/8] libxl: Convert libxl__json_parse() to use json-c
Date: Mon, 29 Sep 2025 14:07:50 +0200
Message-ID: <20250929120756.46075-3-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

This reuse the "json_callback_*" implemented for the yajl parser as
they don't really need to be changed. It's just awkward to have to
cast between `unsigned char` and `char.`

Replace few strncpy() by memcpy() to let the compiler know we want to
copy the string without the terminating nul, as we are adding it just
after.

Also, it should be possible to keep using YAJL parser when json-c
library isn't available.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jason Andryuk 
---
 tools/include/libxl_json.h    |   4 ++
 tools/libs/light/libxl_json.c | 120 ++++++++++++++++++++++++++++++++--
 2 files changed, 120 insertions(+), 4 deletions(-)

diff --git a/tools/include/libxl_json.h b/tools/include/libxl_json.h
index 3f97267eae..f0b4871e0e 100644
--- a/tools/include/libxl_json.h
+++ b/tools/include/libxl_json.h
@@ -42,6 +42,7 @@ yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p);
 #  define HAVE_YAJL_V2 1
 #endif
 
+#ifdef HAVE_LIBYAJL
 #ifdef HAVE_YAJL_V2
 
 typedef size_t libxl_yajl_length;
@@ -89,5 +90,8 @@ static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
 }
 
 #endif /* !HAVE_YAJL_V2 */
+#else
+typedef size_t libxl_yajl_length;
+#endif /* !HAVE_LIBYAJL */
 
 #endif /* LIBXL_JSON_H */
diff --git a/tools/libs/light/libxl_json.c b/tools/libs/light/libxl_json.c
index 9b8ef2cab9..44ee6e213f 100644
--- a/tools/libs/light/libxl_json.c
+++ b/tools/libs/light/libxl_json.c
@@ -16,7 +16,25 @@
 
 #include 
 
+#ifdef HAVE_LIBJSONC
+#include 
+#define USE_LIBJSONC_PARSER
+#endif
+
+#ifdef HAVE_LIBYAJL
+#  ifndef USE_LIBJSONC_PARSER
+#    define USE_LIBYAJL_PARSER
+#  endif
+#endif
+
+
+#ifdef USE_LIBJSONC_PARSER
+#include 
+#endif
+
+#ifdef USE_LIBYAJL_PARSER
 #include 
+#endif
 #include 
 
 #include "libxl_internal.h"
@@ -25,7 +43,9 @@
 
 typedef struct libxl__yajl_ctx {
     libxl__gc *gc;
+#ifdef USE_LIBYAJL_PARSER
     yajl_handle hand;
+#endif
     libxl__json_object *head;
     libxl__json_object *current;
 #ifdef DEBUG_ANSWER
@@ -33,7 +53,7 @@ typedef struct libxl__yajl_ctx {
 #endif
 } libxl__yajl_ctx;
 
-#ifdef DEBUG_ANSWER
+#if defined(DEBUG_ANSWER) && defined(USE_LIBYAJL_PARSER)
 #if YAJL_VERSION < 20000
 #  define DEBUG_GEN_ALLOC(ctx)                  \
     if ((ctx)->g == NULL) {                     \
@@ -759,7 +779,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
     obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = libxl__zalloc(ctx->gc, len + 1);
-    strncpy(t, s, len);
+    memcpy(t, s, len);
     t[len] = 0;
 
     obj->u.string = t;
@@ -806,7 +826,7 @@ static int json_callback_map_key(void *opaque, const unsigned char *str,
 
     DEBUG_GEN_STRING(ctx, str, len);
 
-    strncpy(t, (const char *) str, len);
+    memcpy(t, (const char *) str, len);
     t[len] = 0;
 
     if (libxl__json_object_is_map(obj)) {
@@ -890,6 +910,7 @@ static int json_callback_end_array(void *opaque)
     return 1;
 }
 
+#ifdef USE_LIBYAJL_PARSER
 static yajl_callbacks callbacks = {
     json_callback_null,
     json_callback_boolean,
@@ -903,28 +924,111 @@ static yajl_callbacks callbacks = {
     json_callback_start_array,
     json_callback_end_array
 };
+#endif
 
 static void yajl_ctx_free(libxl__yajl_ctx *yajl_ctx)
 {
+#ifdef USE_LIBYAJL_PARSER
     if (yajl_ctx->hand) {
         yajl_free(yajl_ctx->hand);
         yajl_ctx->hand = NULL;
     }
+#endif
     DEBUG_GEN_FREE(yajl_ctx);
 }
 
+#ifdef USE_LIBJSONC_PARSER
+static int jso_visiter(json_object *jso,
+                       int flags,
+                       json_object *parent_jso,
+                       const char *jso_key,
+                       size_t *jso_index,
+                       void *userarg)
+{
+    enum json_type type;
+    int r;
+
+    if (jso_key && flags != JSON_C_VISIT_SECOND) {
+        json_callback_map_key(userarg, (const unsigned char*)jso_key, strlen(jso_key));
+    }
+    type = json_object_get_type(jso);
+    switch (type) {
+    case json_type_null:
+        r = json_callback_null(userarg);
+        break;
+    case json_type_boolean:
+        r = json_callback_boolean(userarg, json_object_get_boolean(jso));
+        break;
+    case json_type_int:
+    case json_type_double: {
+        // it might be better to use on of
+        // json_object_get_{int,int64,uint64,double} instead.
+        // but would need to replace json_callback_number().
+        const char *s = json_object_get_string(jso);
+        r = json_callback_number(userarg, s, strlen(s));
+        break;
+    }
+    case json_type_object:
+        if (flags != JSON_C_VISIT_SECOND) {
+            r = json_callback_start_map(userarg);
+        } else {
+            r = json_callback_end_map(userarg);
+        }
+        break;
+    case json_type_array:
+        if (flags != JSON_C_VISIT_SECOND) {
+            r = json_callback_start_array(userarg);
+        } else {
+            r = json_callback_end_array(userarg);
+        }
+        break;
+    case json_type_string: {
+        const char *s = json_object_get_string(jso);
+        const int len = json_object_get_string_len(jso);
+        r = json_callback_string(userarg, (const unsigned char*)s, len);
+        break;
+    }
+    default:
+        /* error */
+        r = 0;
+    }
+    if (r == 0)
+        return JSON_C_VISIT_RETURN_ERROR;
+    return JSON_C_VISIT_RETURN_CONTINUE;
+}
+#endif
+
 libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
 {
+#ifdef USE_LIBYAJL_PARSER
     yajl_status status;
+    unsigned char *str = NULL;
+#endif
     libxl__yajl_ctx yajl_ctx;
     libxl__json_object *o = NULL;
-    unsigned char *str = NULL;
+#ifdef USE_LIBJSONC_PARSER
+    json_object *jso;
+    enum json_tokener_error error;
+
+    jso = json_tokener_parse_verbose(s, &error);
+    if (!jso) {
+        LOG(ERROR, "json-c parse error: %s", json_tokener_error_desc(error));
+        goto out;
+    }
+#endif
 
     memset(&yajl_ctx, 0, sizeof (yajl_ctx));
     yajl_ctx.gc = gc;
 
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
+#ifdef USE_LIBJSONC_PARSER
+    int r = json_c_visit(jso, 0, jso_visiter, &yajl_ctx);
+    if (r < 0) {
+        LOG(ERROR, "json_c_visit failed");
+        goto out;
+    }
+#elif defined(USE_LIBYAJL_PARSER)
     if (yajl_ctx.hand == NULL) {
         yajl_ctx.hand = libxl__yajl_alloc(&callbacks, NULL, &yajl_ctx);
     }
@@ -935,6 +1039,7 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
     status = yajl_complete_parse(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
+#endif
 
     o = yajl_ctx.head;
 
@@ -943,13 +1048,20 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
     yajl_ctx.head = NULL;
 
     yajl_ctx_free(&yajl_ctx);
+#ifdef USE_LIBJSONC_PARSER
+    json_object_put(jso);
+#endif
     return o;
 
 out:
+#ifdef USE_LIBJSONC_PARSER
+    json_object_put(jso);
+#elif defined(USE_LIBYAJL_PARSER)
     str = yajl_get_error(yajl_ctx.hand, 1, (const unsigned char*)s, strlen(s));
 
     LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str);
     yajl_free_error(yajl_ctx.hand, str);
+#endif
     yajl_ctx_free(&yajl_ctx);
     return NULL;
 }
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132742.1471018 (Exim 4.92)
	(envelope-from )
	id 1v3Cfk-0008JI-Qp; Mon, 29 Sep 2025 12:08:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132742.1471018; Mon, 29 Sep 2025 12: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 1v3Cfk-0008J5-M4; Mon, 29 Sep 2025 12:08:04 +0000
Received: by outflank-mailman (input) for mailman id 1132742;
 Mon, 29 Sep 2025 12:08:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfi-0007uC-UR
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfi-00GXBV-2V;
 Mon, 29 Sep 2025 12:08:02 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfi-004JHo-2F;
 Mon, 29 Sep 2025 12:08: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" 
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=QdP8PHqJmogVusHtiO1gc6B5Y6eGFL1T9BNVCi6iVhg=; b=VnZ5rgxsoXfTniZ3rahVpMU6YW
	NA1zXU2iTUkveG8fhMV6Yr3+zxy4sIhQ3iZBPAv16FXLr+prJxVjxRmEh4XJqNyBtgCVSJj+tKulX
	jAn6PbzGPgVl3mJ2mGcvBlvCv7xKmKSBpVv44b5Cz7JaNmYZF/7pJ4FG4Nyx8yHLCOuM=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Jason Andryuk ,
	Juergen Gross 
Subject: [XEN PATCH v2 4/8] libxl: libxl__object_to_json() to json-c
Date: Mon, 29 Sep 2025 14:07:52 +0200
Message-ID: <20250929120756.46075-5-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

- libxl changes:

While doing so, we rename all "*_gen_json" function to "*_gen_jso" as
they have different prototype. All the function pointer are been cast
to (libxl__gen_json_callback) by "gentypes.py" when generating
"*_to_json()" functions.

We also introduce a few more "*_gen_jso" functions for "int" and
"bool" because we can't use json_object_*() functions from json-c
directly like it's done with yajl.

To make the generation of _libxl_types*json.[ch] with both YAJL and
json-c we add "--libjsonc" to gentypes.py so it can generate
functions/types for both.

Also introducing "jsonc_json_gen_fn" in the IDL, to be able to point
to a different function when using json-c.

Also, don't export any of the new *_gen_jso() function, at the cost of
having "_hidden" macro in semi-public headers.

- xl changes:

Also, rework the implementation of printf_info() in `xl` to avoid
using libxl_domain_config_gen_json() which isn't available without
YAJL. The implementation using "json_object" call
libxl_domain_config_to_json() which generate a plain string of JSON,
which we parse to add it to our own json; this avoid a dependency on
the json library used by libxl.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jason Andryuk 
---

Notes:
    v2:
    - Replace construct $(if $(LIBJSONC_LIBS),--libjsonc) by
        $(if $(filter -ljson-c,$(XEN_JSON_LIBS))

 tools/include/libxl_json.h                |  17 ++
 tools/libs/light/Makefile                 |   2 +-
 tools/libs/light/gentypes.py              | 160 ++++++++++-
 tools/libs/light/idl.py                   |   7 +-
 tools/libs/light/libxl_cpuid.c            | 119 ++++++++
 tools/libs/light/libxl_internal.h         |  16 +-
 tools/libs/light/libxl_json.c             | 316 ++++++++++++++++++++++
 tools/libs/light/libxl_types.idl          |   7 +-
 tools/libs/light/libxl_types_internal.idl |   3 +-
 tools/xl/xl_info.c                        | 102 ++++++-
 10 files changed, 729 insertions(+), 20 deletions(-)

diff --git a/tools/include/libxl_json.h b/tools/include/libxl_json.h
index e2ef8151f0..c130e88a5e 100644
--- a/tools/include/libxl_json.h
+++ b/tools/include/libxl_json.h
@@ -28,6 +28,22 @@
 #endif
 #endif
 
+#ifdef HAVE_LIBJSONC
+#ifndef _hidden
+#define _hidden
+#endif
+_hidden int libxl__uint64_gen_jso(json_object **jso_r, uint64_t val);
+_hidden int libxl_defbool_gen_jso(json_object **jso_r, libxl_defbool *p);
+_hidden int libxl_uuid_gen_jso(json_object **jso_r, libxl_uuid *p);
+_hidden int libxl_mac_gen_jso(json_object **jso_r, libxl_mac *p);
+_hidden int libxl_bitmap_gen_jso(json_object **jso_r, libxl_bitmap *p);
+_hidden int libxl_cpuid_policy_list_gen_jso(json_object **jso_r,libxl_cpuid_policy_list *p);
+_hidden int libxl_string_list_gen_jso(json_object **jso_r,libxl_string_list *p);
+_hidden int libxl_key_value_list_gen_jso(json_object **jso_r, libxl_key_value_list *p);
+_hidden int libxl_hwcap_gen_jso(json_object **jso_r, libxl_hwcap *p);
+_hidden int libxl_ms_vm_genid_gen_jso(json_object **jso_r, libxl_ms_vm_genid *p);
+#endif
+#if defined(HAVE_LIBYAJL)
 yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val);
 yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
@@ -40,6 +56,7 @@ yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
                                               libxl_key_value_list *p);
 yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
 yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p);
+#endif
 
 #include <_libxl_types_json.h>
 
diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
index c05d89db33..bc60c46558 100644
--- a/tools/libs/light/Makefile
+++ b/tools/libs/light/Makefile
@@ -226,7 +226,7 @@ testidl.o: $(XEN_INCLUDE)/libxl.h
 # This exploits the 'multi-target pattern rule' trick.
 # gentypes.py should be executed only once to make all the targets.
 _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: libxl_type%.idl gentypes.py idl.py
-	$(PYTHON) gentypes.py libxl_type$(*F).idl __libxl_type$(*F).h __libxl_type$(*F)_private.h \
+	$(PYTHON) gentypes.py $(if $(filter -ljson-c,$(XEN_JSON_LIBS)),--libjsonc) libxl_type$(*F).idl __libxl_type$(*F).h __libxl_type$(*F)_private.h \
 		__libxl_type$(*F)_json.h  __libxl_type$(*F).c
 	$(call move-if-changed,__libxl_type$(*F).h,_libxl_type$(*F).h)
 	$(call move-if-changed,__libxl_type$(*F)_private.h,_libxl_type$(*F)_private.h)
diff --git a/tools/libs/light/gentypes.py b/tools/libs/light/gentypes.py
index 3fe3873242..006bea170a 100644
--- a/tools/libs/light/gentypes.py
+++ b/tools/libs/light/gentypes.py
@@ -256,6 +256,30 @@ def libxl_C_type_member_init(ty, field):
     s += "\n"
     return s
 
+# For json-c gen_jso functions
+def libxl_C_type_gen_jso_map_key(f, parent, indent, scope_object, sub_scope_object):
+    s = ""
+    if isinstance(f.type, idl.KeyedUnion):
+        s += "switch (%s) {\n" % (parent + f.type.keyvar.name)
+        for x in f.type.fields:
+            v = f.type.keyvar.name + "." + x.name
+            s += "case %s:\n" % x.enumname
+            s += "    if (json_object_object_add(%s, \"%s\", %s)) {\n" % (scope_object, v, sub_scope_object)
+            s += "        json_object_put(%s);\n" % (sub_scope_object)
+            s += "        goto out;\n"
+            s += "    }\n"
+            s += "    break;\n"
+        s += "}\n"
+    else:
+        s += "if (json_object_object_add(%s, \"%s\", %s)) {\n" % (scope_object, f.name, sub_scope_object)
+        s += "    json_object_put(%s);\n" % (sub_scope_object)
+        s += "    goto out;\n"
+        s += "}\n"
+    if s != "":
+        s = indent + s
+    return s.replace("\n", "\n%s" % indent).rstrip(indent)
+
+# For YAJL gen_json functions
 def libxl_C_type_gen_map_key(f, parent, indent = ""):
     s = ""
     if isinstance(f.type, idl.KeyedUnion):
@@ -352,6 +376,86 @@ def get_default_expr(f, nparent, fexpr):
 
     return "%s" % fexpr
 
+# For json-c gen_json functions
+def libxl_C_type_gen_jso(ty, v, indent = "    ", parent = None, scope_object = "jso"):
+    s = ""
+    if parent is None:
+        s += "json_object *jso;\n"
+        s += "int rc;\n"
+        sub_scope_object = "jso_sub_1"
+    else:
+        sub_scope_object = "jso_sub_%d" % (1+int(scope_object.removeprefix("jso_sub_")))
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    %s = json_object_new_array_ext(%s);\n" % (scope_object, parent + ty.lenvar.name)
+        s += "    if (!%s)\n" % (scope_object)
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += "        json_object *%s;\n" % (sub_scope_object)
+        # remove some indent, it's over indented at least in one case libxl_vcpu_sched_params_gen_json
+        s += libxl_C_type_gen_jso(ty.elem_type, v+"[i]",
+                                   indent + "    ", parent, sub_scope_object)
+        s += "        if (json_object_array_add(%s, %s)) {\n" % (scope_object, sub_scope_object)
+        s += "            json_object_put(%s);\n" % (sub_scope_object)
+        s += "            goto out;\n"
+        s += "        }\n"
+        s += "    }\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
+        s += "rc = libxl__enum_gen_jso(&%s, %s_to_string(%s));\n" % (scope_object, ty.typename, ty.pass_arg(v, parent is None))
+        s += "if (rc)\n"
+        s += "    goto out;\n"
+    elif isinstance(ty, idl.KeyedUnion):
+        if parent is None:
+            raise Exception("KeyedUnion type must have a parent")
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
+        for f in ty.fields:
+            (nparent,fexpr) = ty.member(v, f, parent is None)
+            s += "case %s:\n" % f.enumname
+            if f.type is not None:
+                s += libxl_C_type_gen_jso(f.type, fexpr, indent + "    ", nparent, scope_object)
+            else:
+                s += "    %s = json_object_new_object();\n" % (scope_object)
+                s += "    if (!%s)\n" % (scope_object)
+                s += "        goto out;\n"
+            s += "    break;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.json_gen_fn is None):
+        s += "%s = json_object_new_object();\n" % (scope_object)
+        s += "if (!%s)\n" % (scope_object)
+        s += "    goto out;\n"
+        for f in [f for f in ty.fields if not f.const and not f.type.private]:
+            (nparent,fexpr) = ty.member(v, f, parent is None)
+            default_expr = get_default_expr(f, nparent, fexpr)
+            s += "if (%s) {\n" % default_expr
+            s += "    json_object *%s = NULL;\n" % (sub_scope_object)
+            s += libxl_C_type_gen_jso(f.type, fexpr, "    ", nparent, sub_scope_object)
+            s += libxl_C_type_gen_jso_map_key(f, nparent, "    ", scope_object, sub_scope_object)
+
+            s += "}\n"
+
+    else:
+        if ty.json_gen_fn is not None:
+            s += "rc = %s(&%s, %s);\n" % (ty.json_gen_fn, scope_object, ty.pass_arg(v, parent is None))
+            s += "if (rc)\n"
+            s += "    goto out;\n"
+
+    if parent is None:
+        s += "*jso_r = jso;\n"
+        s += "return 0;\n"
+        s += "out:\n"
+        s += "json_object_put(jso);\n"
+        s += "return ERROR_FAIL;\n"
+
+    if s != "":
+        s = indent + s
+    return s.replace("\n", "\n%s" % indent).rstrip(indent)
+
+# For YAJL gen_json functions
 def libxl_C_type_gen_json(ty, v, indent = "    ", parent = None):
     s = ""
     if parent is None:
@@ -426,9 +530,9 @@ def libxl_C_type_gen_json(ty, v, indent = "    ", parent = None):
         s = indent + s
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
-def libxl_C_type_to_json(ty, v, indent = "    "):
+def libxl_C_type_to_json(ty, v, indent = "    ", fn_ptr_type="libxl__gen_json_callback", fn_suffix="_gen_json"):
     s = ""
-    gen = "(libxl__gen_json_callback)&%s_gen_json" % ty.typename
+    gen = "(%s)&%s%s" % (fn_ptr_type, ty.typename, fn_suffix)
     s += "return libxl__object_to_json(ctx, \"%s\", %s, (void *)%s);\n" % (ty.typename, gen, ty.pass_arg(v, passby=idl.PASS_BY_REFERENCE))
 
     if s != "":
@@ -589,14 +693,38 @@ def clean_header_define(header_path):
 
 
 if __name__ == '__main__':
+    opt_libjsonc = False
+    if len(sys.argv) == 7:
+        if sys.argv.pop(1) == "--libjsonc":
+            opt_libjsonc = True
     if len(sys.argv) != 6:
         print("Usage: gentypes.py  
   ", file=sys.stderr)
         sys.exit(1)
 
     (_, idlname, header, header_private, header_json, impl) = sys.argv
 
+    # Overwrite `json_gen_fn` for standard types
+    if opt_libjsonc:
+        idl.bool.json_gen_fn = "libxl__boolean_gen_jso"
+        idl.size_t.json_gen_fn = "libxl__int_gen_jso"
+        idl.integer .json_gen_fn = "libxl__int_gen_jso"
+        idl.uint8.json_gen_fn = "libxl__int_gen_jso"
+        idl.uint16.json_gen_fn = "libxl__int_gen_jso"
+        idl.uint32.json_gen_fn = "libxl__int_gen_jso"
+        idl.uint64.json_gen_fn = "libxl__uint64_gen_jso"
+        idl.string.json_gen_fn = "libxl__string_gen_jso"
+
     (builtins,types) = idl.parse(idlname)
 
+    # Overwrite `json_gen_fn` with `jsonc_json_gen_fn` for types from the IDL
+    if opt_libjsonc:
+        for t in builtins:
+            if t.jsonc_json_gen_fn is not None:
+                t.json_gen_fn = t.jsonc_json_gen_fn
+        for t in types:
+            if t.jsonc_json_gen_fn is not None:
+                t.json_gen_fn = t.jsonc_json_gen_fn
+
     print("outputting libxl type definitions to %s" % header)
 
     f = open(header, "w")
@@ -665,7 +793,11 @@ if __name__ == '__main__':
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
     for ty in [ty for ty in types if ty.json_gen_fn is not None]:
-        f.write("%syajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
+        if opt_libjsonc:
+            # Always hide JSON generators base on json-c
+            f.write("%sint %s_gen_jso(json_object **jso_r, %s);\n" % ("_hidden ", ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
+        else:
+            f.write("%syajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
     f.write("""#endif /* %s */\n""" % header_json_define)
@@ -769,15 +901,25 @@ if __name__ == '__main__':
         f.write("\n")
 
     for ty in [t for t in types if t.json_gen_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
-        f.write("{\n")
-        f.write(libxl_C_type_gen_json(ty, "p"))
-        f.write("}\n")
-        f.write("\n")
+        if opt_libjsonc:
+            f.write("int %s_gen_jso(json_object **jso_r, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
+            f.write("{\n")
+            f.write(libxl_C_type_gen_jso(ty, "p"))
+            f.write("}\n")
+            f.write("\n")
+        else:
+            f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
+            f.write("{\n")
+            f.write(libxl_C_type_gen_json(ty, "p"))
+            f.write("}\n")
+            f.write("\n")
 
         f.write("char *%s_to_json(libxl_ctx *ctx, %s)\n" % (ty.typename, ty.make_arg("p")))
         f.write("{\n")
-        f.write(libxl_C_type_to_json(ty, "p"))
+        if opt_libjsonc:
+            f.write(libxl_C_type_to_json(ty, "p", fn_ptr_type="libxl__gen_json_callback", fn_suffix="_gen_jso"))
+        else:
+            f.write(libxl_C_type_to_json(ty, "p", fn_ptr_type="libxl__gen_json_callback", fn_suffix="_gen_json"))
         f.write("}\n")
         f.write("\n")
 
diff --git a/tools/libs/light/idl.py b/tools/libs/light/idl.py
index d7367503b4..61c8e14004 100644
--- a/tools/libs/light/idl.py
+++ b/tools/libs/light/idl.py
@@ -79,6 +79,7 @@ class Type(object):
 
         if self.typename is not None and not self.private:
             self.json_gen_fn = kwargs.setdefault('json_gen_fn', self.typename + "_gen_json")
+            self.jsonc_json_gen_fn = kwargs.setdefault('jsonc_json_gen_fn', self.typename + "_gen_jso")
             self.json_parse_type = kwargs.setdefault('json_parse_type', "JSON_ANY")
             if self.namespace is not None:
                 self.json_parse_fn = kwargs.setdefault('json_parse_fn',
@@ -88,6 +89,7 @@ class Type(object):
                                                        self.typename + "_parse_json")
         else:
             self.json_gen_fn = kwargs.setdefault('json_gen_fn', None)
+            self.jsonc_json_gen_fn = kwargs.setdefault('jsonc_json_gen_fn', None)
             self.json_parse_type = kwargs.setdefault('json_parse_type', None)
             self.json_parse_fn = kwargs.setdefault('json_parse_fn', None)
 
@@ -142,6 +144,7 @@ class Number(Builtin):
         kwargs.setdefault('copy_fn', None)
         kwargs.setdefault('signed', False)
         kwargs.setdefault('json_gen_fn', "yajl_gen_integer")
+        kwargs.setdefault('jsonc_json_gen_fn', "libxl__int_gen_jso")
         kwargs.setdefault('json_parse_type', "JSON_INTEGER")
         # json_parse_fn might be overriden on specific type
         kwargs.setdefault('json_parse_fn', "libxl__int_parse_json")
@@ -290,6 +293,7 @@ void = Builtin("void *", namespace = None)
 bool = Builtin("bool", namespace = None,
                copy_fn=None,
                json_gen_fn = "yajl_gen_bool",
+               jsonc_json_gen_fn = "libxl__boolean_gen_jso",
                json_parse_type = "JSON_BOOL",
                json_parse_fn = "libxl__bool_parse_json",
                autogenerate_json = False)
@@ -301,10 +305,11 @@ integer = Number("int", namespace = None, signed = True)
 uint8 = UInt(8)
 uint16 = UInt(16)
 uint32 = UInt(32)
-uint64 = UInt(64, json_gen_fn = "libxl__uint64_gen_json")
+uint64 = UInt(64, json_gen_fn = "libxl__uint64_gen_json", jsonc_json_gen_fn = "libxl__uint64_gen_jso")
 
 string = Builtin("char *", namespace = None, copy_fn = "libxl_string_copy", dispose_fn = "free",
                  json_gen_fn = "libxl__string_gen_json",
+                 jsonc_json_gen_fn = "libxl__string_gen_jso",
                  json_parse_type = "JSON_STRING | JSON_NULL",
                  json_parse_fn = "libxl__string_parse_json",
                  autogenerate_json = False,
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index f738e17b19..8420b2465f 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -545,6 +545,124 @@ static const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
  * }
  */
 
+#ifdef HAVE_LIBJSONC
+int libxl_cpuid_policy_list_gen_jso(json_object **jso_r, libxl_cpuid_policy_list *pl)
+{
+    libxl_cpuid_policy_list policy = *pl;
+    struct xc_xend_cpuid *cpuid;
+    const struct xc_msr *msr;
+    json_object *jso_outer;
+    json_object *jso_array;
+    int i, j;
+    int r;
+    int rc = ERROR_FAIL;
+
+    jso_outer = json_object_new_object();
+    if (!jso_outer) goto out;
+
+    jso_array = json_object_new_array();
+    if (!jso_array) goto out;
+
+    r = json_object_object_add(jso_outer, "cpuid", jso_array);
+    if (r < 0) {
+        json_object_put(jso_array);
+        goto out;
+    }
+
+    if (policy == NULL || policy->cpuid == NULL) goto empty;
+    cpuid = policy->cpuid;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        json_object *jso_inner;
+        jso_inner = json_object_new_object();
+        if (!jso_inner) goto out;
+
+        r = json_object_array_add(jso_array, jso_inner);
+        if (r < 0) {
+            json_object_put(jso_inner);
+            goto out;
+        }
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                json_object *jso_value = json_object_new_int(cpuid[i].input[j]);
+                if (!jso_value) goto out;
+                r = json_object_object_add(jso_inner, input_names[j], jso_value);
+                if (r < 0) {
+                    json_object_put(jso_value);
+                    goto out;
+                }
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                json_object *jso_value = json_object_new_string_len(cpuid[i].policy[j], 32);
+                if (!jso_value) goto out;
+                r = json_object_object_add(jso_inner, policy_names[j], jso_value);
+                if (r < 0) {
+                    json_object_put(jso_value);
+                    goto out;
+                }
+            }
+        }
+    }
+
+empty:
+
+    jso_array = json_object_new_array();
+    if (!jso_array) goto out;
+
+    r = json_object_object_add(jso_outer, "msr", jso_array);
+    if (r < 0) {
+        json_object_put(jso_array);
+        goto out;
+    }
+
+    if (!policy || !policy->msr) goto done;
+    msr = policy->msr;
+
+    for (i = 0; msr[i].index != XC_MSR_INPUT_UNUSED; i++) {
+        json_object *jso_inner;
+        json_object *jso_value;
+
+        jso_inner = json_object_new_object();
+        if (!jso_inner) goto out;
+
+        r = json_object_array_add(jso_array, jso_inner);
+        if (r < 0) {
+            json_object_put(jso_inner);
+            goto out;
+        }
+
+        jso_value = json_object_new_int(msr[i].index);
+        if (!jso_value) goto out;
+        r = json_object_object_add(jso_inner, "index", jso_value);
+        if (r < 0) {
+            json_object_put(jso_value);
+            goto out;
+        }
+
+        jso_value = json_object_new_string_len(msr[i].policy, 64);
+        if (!jso_value) goto out;
+        r = json_object_object_add(jso_inner, "policy", jso_value);
+        if (r < 0) {
+            json_object_put(jso_value);
+            goto out;
+        }
+    }
+
+done:
+    *jso_r = jso_outer;
+    jso_outer = NULL;
+    rc = 0;
+out:
+    json_object_put(jso_outer);
+    return rc;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                 libxl_cpuid_policy_list *pl)
 {
@@ -630,6 +748,7 @@ yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
 out:
     return s;
 }
+#endif
 
 int libxl__cpuid_policy_list_parse_json(libxl__gc *gc,
                                         const libxl__json_object *o,
diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h
index 5204cb8889..b65e0064b9 100644
--- a/tools/libs/light/libxl_internal.h
+++ b/tools/libs/light/libxl_internal.h
@@ -1993,9 +1993,11 @@ _hidden char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid);
 _hidden int libxl__enum_from_string(const libxl_enum_string_table *t,
                                     const char *s, int *e) NN(2);
 
-_hidden yajl_gen_status libxl__string_gen_json(yajl_gen hand, const char *p);
-
+#ifdef HAVE_LIBJSONC
+typedef int (*libxl__gen_json_callback)(json_object **jso_r, void *);
+#elif defined(HAVE_LIBYAJL)
 typedef yajl_gen_status (*libxl__gen_json_callback)(yajl_gen hand, void *);
+#endif
 _hidden char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
                                     libxl__gen_json_callback gen, void *p);
 
@@ -2084,11 +2086,21 @@ int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
                        void *databuf, size_t datalen,
                        int nfds, int fds[], const char *what);
 
+#ifdef HAVE_LIBJSONC
+_hidden int libxl__enum_gen_jso(json_object **jso_r, const char *str);
+_hidden int libxl__int_gen_jso(json_object **jso_r, int i);
+_hidden int libxl__boolean_gen_jso(json_object **jso_r, bool b);
+_hidden int libxl__string_gen_jso(json_object **jso_r, const char *p);
+#endif
+
+#ifdef HAVE_LIBYAJL
 /* from libxl_json */
 #include 
 
 _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
+_hidden yajl_gen_status libxl__string_gen_json(yajl_gen hand, const char *p);
+#endif
 
 typedef enum {
     JSON_NULL    = (1 << 0),
diff --git a/tools/libs/light/libxl_json.c b/tools/libs/light/libxl_json.c
index 75b383ee14..eeda9c301d 100644
--- a/tools/libs/light/libxl_json.c
+++ b/tools/libs/light/libxl_json.c
@@ -19,12 +19,16 @@
 #ifdef HAVE_LIBJSONC
 #include 
 #define USE_LIBJSONC_PARSER
+#define USE_LIBJSONC_GEN
 #endif
 
 #ifdef HAVE_LIBYAJL
 #  ifndef USE_LIBJSONC_PARSER
 #    define USE_LIBYAJL_PARSER
 #  endif
+#  ifndef USE_LIBJSONC_GEN
+#    define USE_LIBYAJL_GEN
+#  endif
 #endif
 
 
@@ -35,7 +39,9 @@
 #ifdef USE_LIBYAJL_PARSER
 #include 
 #endif
+#ifdef USE_LIBYAJL_GEN
 #include 
+#endif
 
 #include "libxl_internal.h"
 
@@ -103,6 +109,21 @@ yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str)
     return yajl_gen_string(hand, (const unsigned char *)str, strlen(str));
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl__enum_gen_jso(json_object **jso_r, const char *str)
+{
+    if (str) {
+        *jso_r = json_object_new_string(str);
+        if (!*jso_r)
+            return ERROR_FAIL;
+    } else {
+        *jso_r = json_object_new_null();
+    }
+    return 0;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str)
 {
     if (str)
@@ -110,15 +131,28 @@ yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str)
     else
         return yajl_gen_null(hand);
 }
+#endif
 
 /*
  * YAJL generators for builtin libxl types.
  */
+#ifdef HAVE_LIBJSONC
+int libxl_defbool_gen_jso(json_object **jso_r, libxl_defbool *db)
+{
+    *jso_r = json_object_new_string(libxl_defbool_to_string(*db));
+    if (!*jso_r)
+        return ERROR_FAIL;
+    return 0;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
                                        libxl_defbool *db)
 {
     return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
 }
+#endif
 
 int libxl__defbool_parse_json(libxl__gc *gc, const libxl__json_object *o,
                               libxl_defbool *p)
@@ -145,6 +179,16 @@ int libxl__defbool_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl__boolean_gen_jso(json_object **jso_r, bool b)
+{
+    *jso_r = json_object_new_boolean(b);
+    if (!*jso_r)
+        return ERROR_FAIL;
+    return 0;
+}
+#endif
+
 int libxl__bool_parse_json(libxl__gc *gc, const libxl__json_object *o,
                            bool *p)
 {
@@ -156,6 +200,19 @@ int libxl__bool_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_uuid_gen_jso(json_object **jso_r, libxl_uuid *uuid)
+{
+    char buf[LIBXL_UUID_FMTLEN+1];
+    snprintf(buf, sizeof(buf), LIBXL_UUID_FMT, LIBXL_UUID_BYTES((*uuid)));
+    *jso_r = json_object_new_string_len(buf, LIBXL_UUID_FMTLEN);
+    if (!*jso_r)
+        return ERROR_FAIL;
+    return 0;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
@@ -163,6 +220,7 @@ yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
     snprintf(buf, sizeof(buf), LIBXL_UUID_FMT, LIBXL_UUID_BYTES((*uuid)));
     return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUID_FMTLEN);
 }
+#endif
 
 int libxl__uuid_parse_json(libxl__gc *gc, const libxl__json_object *o,
                            libxl_uuid *p)
@@ -173,6 +231,39 @@ int libxl__uuid_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return libxl_uuid_from_string(p, o->u.string);
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_bitmap_gen_jso(json_object **jso_r, libxl_bitmap *bitmap)
+{
+    json_object *jso;
+    int i;
+    int r;
+    int rc = ERROR_FAIL;
+
+    jso = json_object_new_array();
+    if (!jso) goto out;
+
+    libxl_for_each_bit(i, *bitmap) {
+        if (libxl_bitmap_test(bitmap, i)) {
+            json_object *jso_value = json_object_new_int(i);
+            if (!jso_value) goto out;
+            r = json_object_array_add(jso, jso_value);
+            if (r) {
+                json_object_put(jso_value);
+                goto out;
+            }
+        }
+    }
+
+    *jso_r = jso;
+    jso = NULL;
+    rc = 0;
+out:
+    json_object_put(jso);
+    return rc;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
                                       libxl_bitmap *bitmap)
 {
@@ -192,6 +283,7 @@ yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
 out:
     return s;
 }
+#endif
 
 int libxl__bitmap_parse_json(libxl__gc *gc, const libxl__json_object *o,
                             libxl_bitmap *p)
@@ -227,6 +319,42 @@ int libxl__bitmap_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_key_value_list_gen_jso(json_object **jso_r, libxl_key_value_list *pkvl)
+{
+    libxl_key_value_list kvl = *pkvl;
+    json_object *jso;
+    int i;
+
+    jso = json_object_new_object();
+    if (!jso) goto out;
+
+    if (!kvl) goto empty;
+
+    for (i = 0; kvl[i] != NULL; i += 2) {
+        json_object *jso_value;
+        if (kvl[i + 1]) {
+            jso_value = json_object_new_string(kvl[i+1]);
+            if (!jso_value) goto out;
+        } else {
+            jso_value = json_object_new_null();
+        }
+        int r = json_object_object_add(jso, kvl[i], jso_value);
+        if (r) {
+            json_object_put(jso_value);
+            goto out;
+        }
+    }
+empty:
+    *jso_r = jso;
+    return 0;
+out:
+    json_object_put(jso);
+    return ERROR_FAIL;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
                                               libxl_key_value_list *pkvl)
 {
@@ -253,6 +381,7 @@ yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
 out:
     return s;
 }
+#endif
 
 int libxl__key_value_list_parse_json(libxl__gc *gc, const libxl__json_object *o,
                                      libxl_key_value_list *p)
@@ -289,6 +418,39 @@ int libxl__key_value_list_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_string_list_gen_jso(json_object **jso_r, libxl_string_list *pl)
+{
+    libxl_string_list l = *pl;
+    json_object *jso;
+    int i;
+    int rc = ERROR_FAIL;
+
+    jso = json_object_new_array();
+    if (!jso) goto out;
+
+    if (!l) goto empty;
+
+    for (i = 0; l[i] != NULL; i++) {
+        json_object *jso_value = json_object_new_string(l[i]);
+        if (!jso_value) goto out;
+        int r = json_object_array_add(jso, jso_value);
+        if (r) {
+            json_object_put(jso_value);
+            goto out;
+        }
+    }
+empty:
+    *jso_r = jso;
+    jso = NULL;
+    rc = 0;
+out:
+    json_object_put(jso);
+    return rc;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
@@ -309,6 +471,7 @@ yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 out:
     return s;
 }
+#endif
 
 int libxl__string_list_parse_json(libxl__gc *gc, const libxl__json_object *o,
                                   libxl_string_list *p)
@@ -342,12 +505,26 @@ int libxl__string_list_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_mac_gen_jso(json_object **jso_r, libxl_mac *mac)
+{
+    char buf[LIBXL_MAC_FMTLEN+1];
+    snprintf(buf, sizeof(buf), LIBXL_MAC_FMT, LIBXL_MAC_BYTES((*mac)));
+    *jso_r = json_object_new_string_len(buf, LIBXL_MAC_FMTLEN);
+    if (!*jso_r)
+        return ERROR_FAIL;
+    return 0;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *mac)
 {
     char buf[LIBXL_MAC_FMTLEN+1];
     snprintf(buf, sizeof(buf), LIBXL_MAC_FMT, LIBXL_MAC_BYTES((*mac)));
     return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_MAC_FMTLEN);
 }
+#endif
 
 int libxl__mac_parse_json(libxl__gc *gc, const libxl__json_object *o,
                           libxl_mac *p)
@@ -358,6 +535,36 @@ int libxl__mac_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return libxl__parse_mac(libxl__json_object_get_string(o), *p);
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_hwcap_gen_jso(json_object **jso_r, libxl_hwcap *p)
+{
+    json_object *jso;
+    int i;
+    int rc = ERROR_FAIL;
+
+    jso = json_object_new_array();
+    if (!jso) goto out;
+
+    for(i=0; i<4; i++) {
+        json_object *jso_value = json_object_new_int((*p)[i]);
+        if (!jso_value)
+            goto out;
+        int r = json_object_array_add(jso, jso_value);
+        if (r) {
+            json_object_put(jso_value);
+            goto out;
+        }
+    }
+    *jso_r = jso;
+    jso = NULL;
+    rc = 0;
+out:
+    json_object_put(jso);
+    return rc;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand,
                                      libxl_hwcap *p)
 {
@@ -375,6 +582,7 @@ yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand,
 out:
     return s;
 }
+#endif
 
 int libxl__hwcap_parse_json(libxl__gc *gc, const libxl__json_object *o,
                             libxl_hwcap *p)
@@ -397,6 +605,37 @@ int libxl__hwcap_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl_ms_vm_genid_gen_jso(json_object **jso_r, libxl_ms_vm_genid *p)
+{
+    json_object *jso;
+    int i;
+    int rc = ERROR_FAIL;
+
+    jso = json_object_new_array_ext(LIBXL_MS_VM_GENID_LEN);
+    if (!jso) goto out;
+
+    for (i = 0; i < LIBXL_MS_VM_GENID_LEN; i++) {
+        json_object *jso_value = json_object_new_int(p->bytes[i]);
+        if (!jso_value)
+            goto out;
+        int r = json_object_array_add(jso, jso_value);
+        if (r) {
+            json_object_put(jso_value);
+            goto out;
+        }
+    }
+
+    *jso_r = jso;
+    jso = NULL;
+    rc = 0;
+out:
+    json_object_put(jso);
+    return rc;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p)
 {
     yajl_gen_status s;
@@ -414,6 +653,7 @@ yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p)
 
     return yajl_gen_array_close(hand);
 }
+#endif
 
 int libxl__ms_vm_genid_parse_json(libxl__gc *gc, const libxl__json_object *o,
                                   libxl_ms_vm_genid *p)
@@ -436,6 +676,21 @@ int libxl__ms_vm_genid_parse_json(libxl__gc *gc, const libxl__json_object *o,
     return 0;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl__string_gen_jso(json_object **jso_r, const char *p)
+{
+    if (p) {
+        *jso_r = json_object_new_string(p);
+        if (!*jso_r)
+            return ERROR_FAIL;
+    } else {
+        *jso_r = json_object_new_null();
+    }
+    return 0;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl__string_gen_json(yajl_gen hand,
                                        const char *p)
 {
@@ -444,6 +699,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
     else
         return yajl_gen_null(hand);
 }
+#endif
 
 int libxl__string_parse_json(libxl__gc *gc, const libxl__json_object *o,
                              char **p)
@@ -1166,6 +1422,7 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
     return NULL;
 }
 
+#ifdef USE_LIBYAJL_GEN
 static const char *yajl_gen_status_to_string(yajl_gen_status s)
 {
         switch (s) {
@@ -1190,7 +1447,43 @@ static const char *yajl_gen_status_to_string(yajl_gen_status s)
             return "unknown error";
         }
 }
+#endif
 
+#ifdef USE_LIBJSONC_GEN
+char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
+                            libxl__gen_json_callback gen, void *p)
+{
+    const char *buf;
+    char *ret = NULL;
+    json_object *jso = NULL;
+    int rc;
+
+    rc = gen(&jso, p);
+    if (rc)
+        goto out;
+
+    buf = json_object_to_json_string_ext(jso, JSON_C_TO_STRING_PRETTY);
+    if (!buf)
+        goto out;
+    ret = strdup((const char *)buf);
+
+out:
+    json_object_put(jso);
+
+    if (rc) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to convert %s to JSON representation. ",
+                   type);
+    } else if (!ret) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to allocate space for to JSON representation of %s",
+                   type);
+    }
+
+    return ret;
+}
+
+#elif defined(USE_LIBYAJL_GEN)
 char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
                             libxl__gen_json_callback gen, void *p)
 {
@@ -1229,6 +1522,7 @@ char *libxl__object_to_json(libxl_ctx *ctx, const char *type,
 
     return ret;
 }
+#endif
 
 char *libxl__json_object_to_json(libxl__gc *gc,
                                  const libxl__json_object *args)
@@ -1262,6 +1556,17 @@ char *libxl__json_object_to_json(libxl__gc *gc,
     return ret;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl__uint64_gen_jso(json_object **jso_r, uint64_t val)
+{
+    *jso_r = json_object_new_uint64(val);
+    if (!*jso_r)
+        return ERROR_FAIL;
+    return 0;
+}
+#endif
+
+#ifdef HAVE_LIBYAJL
 yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val)
 {
     char *num;
@@ -1282,6 +1587,7 @@ yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val)
 out:
     return s;
 }
+#endif
 
 int libxl__object_from_json(libxl_ctx *ctx, const char *type,
                             libxl__json_parse_callback parse,
@@ -1313,6 +1619,16 @@ int libxl__object_from_json(libxl_ctx *ctx, const char *type,
     return rc;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl__int_gen_jso(json_object **jso_r, int i)
+{
+    *jso_r = json_object_new_int(i);
+    if (!*jso_r)
+        return ERROR_FAIL;
+    return 0;
+}
+#endif
+
 int libxl__int_parse_json(libxl__gc *gc, const libxl__json_object *o,
                           void *p)
 {
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index b53e013a44..d64a573ff3 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -7,9 +7,9 @@ namespace("libxl_")
 
 libxl_defbool = Builtin("defbool", json_parse_type="JSON_STRING", passby=PASS_BY_REFERENCE, copy_fn=None,
                         check_default_fn="libxl__defbool_is_default")
-libxl_domid = Builtin("domid", json_gen_fn = "yajl_gen_integer", json_parse_fn = "libxl__uint32_parse_json",
+libxl_domid = Builtin("domid", json_gen_fn = "yajl_gen_integer", jsonc_json_gen_fn = "libxl__uint64_gen_jso", json_parse_fn = "libxl__uint32_parse_json",
                       json_parse_type = "JSON_INTEGER", autogenerate_json = False, copy_fn=None)
-libxl_devid = Builtin("devid", json_gen_fn = "yajl_gen_integer", json_parse_fn = "libxl__int_parse_json",
+libxl_devid = Builtin("devid", json_gen_fn = "yajl_gen_integer", jsonc_json_gen_fn = "libxl__int_gen_jso", json_parse_fn = "libxl__int_parse_json",
                       json_parse_type = "JSON_INTEGER", autogenerate_json = False, signed = True, init_val="-1",
                       copy_fn=None)
 libxl_uuid = Builtin("uuid", json_parse_type="JSON_STRING", passby=PASS_BY_REFERENCE, check_default_fn="libxl_uuid_is_nil",
@@ -37,7 +37,8 @@ libxl_ms_vm_genid = Builtin("ms_vm_genid", passby=PASS_BY_REFERENCE, check_defau
 # Specific integer types
 #
 
-MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT", json_gen_fn = "libxl__uint64_gen_json")
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT",
+             json_gen_fn = "libxl__uint64_gen_json", jsonc_json_gen_fn = "libxl__uint64_gen_jso")
 
 #
 # Constants / Enumerations
diff --git a/tools/libs/light/libxl_types_internal.idl b/tools/libs/light/libxl_types_internal.idl
index 0425e9b6b0..ab4ee92870 100644
--- a/tools/libs/light/libxl_types_internal.idl
+++ b/tools/libs/light/libxl_types_internal.idl
@@ -1,7 +1,8 @@
 namespace("libxl__")
 hidden(True)
 
-libxl_domid = Builtin("domid", namespace="libxl_", json_gen_fn = "yajl_gen_integer",
+libxl_domid = Builtin("domid", namespace="libxl_",
+                      json_gen_fn = "yajl_gen_integer", jsonc_json_gen_fn = "libxl__uint64_gen_jso",
 		      json_parse_fn = "libxl__uint32_parse_json", json_parse_type = "JSON_INTEGER",
 		      autogenerate_json = False, copy_fn = None)
 
diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
index 83a02f45fe..80a3b25aac 100644
--- a/tools/xl/xl_info.c
+++ b/tools/xl/xl_info.c
@@ -60,6 +60,48 @@ static int maybe_printf(const char *fmt, ...)
     return count;
 }
 
+
+#ifdef HAVE_LIBJSONC
+static int printf_info_one_json(json_object **jso_r, int domid,
+                                libxl_domain_config *d_config)
+{
+    json_object *jso = NULL;
+    json_object *jso_config = NULL;
+    enum json_tokener_error error;
+    char *s = NULL;
+    int r = EXIT_FAILURE;
+
+    s = libxl_domain_config_to_json(ctx, d_config);
+    jso_config = json_tokener_parse_verbose(s, &error);
+    if (!jso_config) {
+        fprintf(stderr, "fail to parse JSON from libxl_domain_config_to_json(): %s\n",
+                json_tokener_error_desc(error));
+        goto out;
+    }
+
+    jso = json_object_new_object();
+    if (domid != -1)
+        json_object_object_add(jso, "domid", json_object_new_int(domid));
+    else
+        json_object_object_add(jso, "domid", json_object_new_null());
+
+
+    json_object_object_add(jso, "config", jso_config);
+    jso_config = NULL;
+
+    *jso_r = jso;
+    jso = NULL;
+    r = EXIT_SUCCESS;
+
+out:
+    free(s);
+    json_object_put(jso);
+    json_object_put(jso_config);
+    return r;
+}
+
+#elif defined(HAVE_LIBYAJL)
+
 static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
                                             libxl_domain_config *d_config)
 {
@@ -95,6 +137,7 @@ static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
 out:
     return s;
 }
+#endif
 
 void printf_info(enum output_format output_format,
                  int domid,
@@ -103,6 +146,27 @@ void printf_info(enum output_format output_format,
     if (output_format == OUTPUT_FORMAT_SXP)
         return printf_info_sexp(domid, d_config, fh);
 
+#ifdef HAVE_LIBJSONC
+    int r;
+    const char *buf;
+    json_object *jso;
+
+    r = printf_info_one_json(&jso, domid, d_config);
+    if (r)
+        goto out;
+
+    buf = json_object_to_json_string_ext(jso, JSON_C_TO_STRING_PRETTY);
+    if (!buf)
+        goto out;
+
+    fputs(buf, fh);
+
+out:
+    json_object_put(jso);
+    flush_stream(fh);
+    return;
+
+#elif defined(HAVE_LIBYAJL)
     const char *buf;
     libxl_yajl_length len = 0;
     yajl_gen_status s;
@@ -132,6 +196,7 @@ void printf_info(enum output_format output_format,
                 "unable to format domain config as JSON (YAJL:%d)\n", s);
 
     flush_stream(fh);
+#endif
 }
 
 static void output_xeninfo(void)
@@ -476,11 +541,20 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
 
     int i, rc;
 
+    const char *buf;
+#ifdef HAVE_LIBJSONC
+    json_object *jso = NULL;
+#elif defined(HAVE_LIBYAJL)
     yajl_gen hand = NULL;
     yajl_gen_status s;
-    const char *buf;
     libxl_yajl_length yajl_len = 0;
+#endif
 
+#ifdef HAVE_LIBJSONC
+    if (default_output_format == OUTPUT_FORMAT_JSON) {
+        jso = json_object_new_array();
+    }
+#elif defined(HAVE_LIBYAJL)
     if (default_output_format == OUTPUT_FORMAT_JSON) {
         hand = libxl_yajl_gen_alloc(NULL);
         if (!hand) {
@@ -493,6 +567,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
             goto out;
     } else
         s = yajl_gen_status_ok;
+#endif
 
     for (i = 0; i < nb_domain; i++) {
         libxl_domain_config_init(&d_config);
@@ -500,16 +575,32 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
                                                  &d_config, NULL);
         if (rc)
             continue;
-        if (default_output_format == OUTPUT_FORMAT_JSON)
+        if (default_output_format == OUTPUT_FORMAT_JSON) {
+#ifdef HAVE_LIBJSONC
+            json_object *jso_value;
+            rc = printf_info_one_json(&jso_value, info[i].domid, &d_config);
+            json_object_array_add(jso, jso_value);
+#elif defined(HAVE_LIBYAJL)
             s = printf_info_one_json(hand, info[i].domid, &d_config);
-        else
+#endif
+        } else
             printf_info_sexp(info[i].domid, &d_config, stdout);
         libxl_domain_config_dispose(&d_config);
+#ifdef HAVE_LIBJSONC
+        if (rc)
+            goto out;
+#elif defined(HAVE_LIBYAJL)
         if (s != yajl_gen_status_ok)
             goto out;
+#endif
     }
 
     if (default_output_format == OUTPUT_FORMAT_JSON) {
+#ifdef HAVE_LIBJSONC
+        buf = json_object_to_json_string_ext(jso, JSON_C_TO_STRING_PRETTY);
+        if (!buf)
+            goto out;
+#elif defined(HAVE_LIBYAJL)
         s = yajl_gen_array_close(hand);
         if (s != yajl_gen_status_ok)
             goto out;
@@ -517,16 +608,21 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain)
         s = yajl_gen_get_buf(hand, (const unsigned char **)&buf, &yajl_len);
         if (s != yajl_gen_status_ok)
             goto out;
+#endif
 
         puts(buf);
     }
 
 out:
     if (default_output_format == OUTPUT_FORMAT_JSON) {
+#ifdef HAVE_LIBJSONC
+        json_object_put(jso);
+#elif defined(HAVE_LIBYAJL)
         yajl_gen_free(hand);
         if (s != yajl_gen_status_ok)
             fprintf(stderr,
                     "unable to format domain config as JSON (YAJL:%d)\n", s);
+#endif
     }
 }
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132741.1471008 (Exim 4.92)
	(envelope-from )
	id 1v3Cfj-00084w-Fb; Mon, 29 Sep 2025 12:08:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132741.1471008; Mon, 29 Sep 2025 12: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 1v3Cfj-00084m-CB; Mon, 29 Sep 2025 12:08:03 +0000
Received: by outflank-mailman (input) for mailman id 1132741;
 Mon, 29 Sep 2025 12:08:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfh-0007T0-W8
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfh-00GXBN-2I;
 Mon, 29 Sep 2025 12:08:01 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfh-004JHo-2O;
 Mon, 29 Sep 2025 12:08: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=j0zZ2dT1fhfsBSW2ysbdrRB/kmY03la1y9qVx0g8+RM=; b=SjVfFDflBZ610y32EMC0u0eAI6
	mK2QfpMRNOXpBwQA3AdvIeCfnJXca8P/ioSjzurE3hO/XjNNSPXR+P415irJRrJ1UsYUb/Z7ej5/l
	zANGZzVHg7GzNSlM697DMa5o8S8IqWiEEMUEP3vs+xeRPkI1M/0tBIGb7cnzez1Ip3JA=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Jason Andryuk ,
	Juergen Gross 
Subject: [XEN PATCH v2 3/8] libxl: convert libxl__json_object_to_yajl_gen to libxl__json_object_to_libjsonc_object
Date: Mon, 29 Sep 2025 14:07:51 +0200
Message-ID: <20250929120756.46075-4-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Convert yajl_gen to json_object from lib json-c.

And make use of it in qmp_prepare_cmd(), which can be compiled with
either lib.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jason Andryuk 
---

Notes:
    v2:
    - In libxl__json_object_to_json_object(), when generating a
      `json_object` from JSON_NUMBER, use json_object_new_double_s() instead
      of json_object_new_string(). This way, the json-c implementation will
      behave like the yajl one when number are bigger than int64, which is
      very unlikely.

 tools/include/libxl_json.h        |   6 ++
 tools/libs/light/libxl_internal.h |   7 +++
 tools/libs/light/libxl_json.c     | 100 ++++++++++++++++++++++++++++++
 tools/libs/light/libxl_qmp.c      |  53 ++++++++++++++++
 4 files changed, 166 insertions(+)

diff --git a/tools/include/libxl_json.h b/tools/include/libxl_json.h
index f0b4871e0e..e2ef8151f0 100644
--- a/tools/include/libxl_json.h
+++ b/tools/include/libxl_json.h
@@ -15,12 +15,18 @@
 #ifndef LIBXL_JSON_H
 #define LIBXL_JSON_H
 
+#ifdef HAVE_LIBJSONC
+#include 
+#endif
+
+#ifdef HAVE_LIBYAJL
 #include 
 #include 
 
 #ifdef HAVE_YAJL_YAJL_VERSION_H
 #  include 
 #endif
+#endif
 
 yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val);
 yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h
index 062123eed4..5204cb8889 100644
--- a/tools/libs/light/libxl_internal.h
+++ b/tools/libs/light/libxl_internal.h
@@ -2234,9 +2234,16 @@ _hidden const libxl__json_object *libxl__json_map_get(const char *key,
  */
 _hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt,
                                                      libxl__json_node_type type);
+#ifdef HAVE_LIBJSONC
+_hidden int libxl__json_object_to_json_object(libxl__gc *gc,
+                                              json_object **jso_out,
+                                              const libxl__json_object *obj);
+#endif
+#ifdef HAVE_LIBYAJL
 _hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
                                                    yajl_gen hand,
                                                    const libxl__json_object *param);
+#endif
 _hidden void libxl__json_object_free(libxl__gc *gc_opt,
                                      libxl__json_object *obj);
 
diff --git a/tools/libs/light/libxl_json.c b/tools/libs/light/libxl_json.c
index 44ee6e213f..75b383ee14 100644
--- a/tools/libs/light/libxl_json.c
+++ b/tools/libs/light/libxl_json.c
@@ -631,6 +631,105 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+#ifdef HAVE_LIBJSONC
+int libxl__json_object_to_json_object(libxl__gc *gc,
+                                      json_object **jso_out,
+                                      const libxl__json_object *obj)
+{
+    int idx = 0;
+    int rc, r;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        *jso_out = json_object_new_null();
+        return 0;
+    case JSON_BOOL:
+        *jso_out = json_object_new_boolean(obj->u.b);
+        if (!*jso_out)
+            return ERROR_NOMEM;
+        return 0;
+    case JSON_INTEGER:
+        *jso_out = json_object_new_int64(obj->u.i);
+        if (!*jso_out)
+            return ERROR_NOMEM;
+        return 0;
+    case JSON_DOUBLE:
+        *jso_out = json_object_new_double(obj->u.d);
+        if (!*jso_out)
+            return ERROR_NOMEM;
+        return 0;
+    case JSON_NUMBER:
+        /*
+         * Use json_object_new_double_s() to rewrite the number exactly as
+         * we parsed it. When generating the JSON string the value `0` will
+         * be ignored and `obj->u.string` will be written instead.
+         */
+        *jso_out = json_object_new_double_s(0, obj->u.string);
+        if (!*jso_out)
+            return ERROR_NOMEM;
+        return 0;
+    case JSON_STRING:
+        *jso_out = json_object_new_string(obj->u.string);
+        if (!*jso_out)
+            return ERROR_NOMEM;
+        return 0;
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+        json_object *map_root = json_object_new_object();
+        json_object *node_value;
+
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
+                break;
+
+            rc = libxl__json_object_to_json_object(gc, &node_value, node->obj);
+            if (rc) {
+                json_object_put(map_root);
+                return rc;
+            }
+
+            r = json_object_object_add(map_root, node->map_key, node_value);
+            if (r < 0) {
+                json_object_put(node_value);
+                json_object_put(map_root);
+                return ERROR_FAIL;
+            }
+        }
+        *jso_out = map_root;
+        return 0;
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+        json_object *array_root = json_object_new_array_ext(obj->u.array->count);
+        json_object *node_value;
+
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
+                break;
+
+            rc = libxl__json_object_to_json_object(gc, &node_value, node);
+            if (rc) {
+                json_object_put(array_root);
+                return rc;
+            }
+            r = json_object_array_add(array_root, node_value);
+            if (r < 0) {
+                json_object_put(node_value);
+                json_object_put(array_root);
+                return ERROR_FAIL;
+            }
+        }
+        *jso_out = array_root;
+        return 0;
+    }
+    case JSON_ANY:
+    default:
+        /* JSON_ANY is not a valid value for obj->type. */
+        return ERROR_FAIL;
+    }
+}
+#endif
+#ifdef HAVE_LIBYAJL
 yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
                                            yajl_gen hand,
                                            const libxl__json_object *obj)
@@ -698,6 +797,7 @@ yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
     abort();
 #undef CONVERT_YAJL_GEN_TO_STATUS
 }
+#endif
 
 
 /*
diff --git a/tools/libs/light/libxl_qmp.c b/tools/libs/light/libxl_qmp.c
index 84740bd4b3..94b6fdb559 100644
--- a/tools/libs/light/libxl_qmp.c
+++ b/tools/libs/light/libxl_qmp.c
@@ -61,7 +61,11 @@
 
 #include 
 
+#ifdef HAVE_LIBJSONC
+#include 
+#elif defined(HAVE_LIBYAJL)
 #include 
+#endif
 
 #include "xen_list.h"
 #include "libxl_internal.h"
@@ -481,13 +485,56 @@ static char *qmp_prepare_cmd(libxl__gc *gc, const char *cmd,
                              const libxl__json_object *args,
                              int id)
 {
+#ifdef HAVE_LIBJSONC
+    json_object *jso = NULL;
+    json_object *jso_value = NULL;
+    /* memory for 'buf' is owned by 'jso' */
+    const char *buf;
+    int rc, r;
+#elif defined(HAVE_LIBYAJL)
     yajl_gen hand = NULL;
     /* memory for 'buf' is owned by 'hand' */
     const unsigned char *buf;
     libxl_yajl_length len;
     yajl_gen_status s;
+#else
+#  error Missing JSON library
+#endif
     char *ret = NULL;
 
+#ifdef HAVE_LIBJSONC
+    jso = json_object_new_object();
+    if (!jso)
+        goto out;
+
+    jso_value = json_object_new_string(cmd);
+    if (!jso_value)
+        goto out;
+    r = json_object_object_add(jso, "execute", jso_value);
+    if (r < 0)
+        goto out;
+    jso_value = json_object_new_int(id);
+    if (!jso_value)
+        goto out;
+    r = json_object_object_add(jso, "id", jso_value);
+    if (r < 0)
+        goto out;
+    /* `jso_value` now part of `jso`, shouldn't free it anymore */
+    jso_value = NULL;
+    if (args) {
+        rc = libxl__json_object_to_json_object(gc, &jso_value, args);
+        if (rc)
+            goto out;
+        r = json_object_object_add(jso, "arguments", jso_value);
+        if (r < 0)
+            goto out;
+        jso_value = NULL;
+    }
+
+    buf = json_object_to_json_string_ext(jso, JSON_C_TO_STRING_PLAIN);
+    ret = libxl__sprintf(gc, "%s\r\n", buf);
+
+#elif defined(HAVE_LIBYAJL)
     hand = libxl_yajl_gen_alloc(NULL);
 
     if (!hand) {
@@ -516,9 +563,15 @@ static char *qmp_prepare_cmd(libxl__gc *gc, const char *cmd,
         goto out;
 
     ret = libxl__sprintf(gc, "%*.*s\r\n", (int)len, (int)len, buf);
+#endif
 
 out:
+#ifdef HAVE_LIBJSONC
+    json_object_put(jso_value);
+    json_object_put(jso);
+#elif defined(HAVE_LIBYAJL)
     yajl_gen_free(hand);
+#endif
     return ret;
 }
 
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132746.1471059 (Exim 4.92)
	(envelope-from )
	id 1v3Cfp-0000us-C4; Mon, 29 Sep 2025 12:08:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132746.1471059; Mon, 29 Sep 2025 12: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 1v3Cfp-0000uK-4s; Mon, 29 Sep 2025 12:08:09 +0000
Received: by outflank-mailman (input) for mailman id 1132746;
 Mon, 29 Sep 2025 12:08:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfn-0000cd-QQ
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cfm-00GXC0-36;
 Mon, 29 Sep 2025 12:08:06 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cfm-004JHo-3A;
 Mon, 29 Sep 2025 12:08: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=raGKb3UCqN0a1TTX8Sfmq9eUg57Dvzpt+gXKdGHPbJI=; b=5ZAMrUM+JRmBDkqjSdk5ESmgoh
	PXqmbfjXnUNkWcKjup4FABeCBm6CoDra1a31szq1/sV+GZeaN/hBmIVPVsaTXbIhqyyweuK7uAS60
	KMh+ArsFUdU5DNZNBnKdkMApVGk4JjGTEjFKfJeSdF70IZlogZ30LaVXAvS4wr3CXs/8=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [XEN PATCH v2 8/8] Update CHANGELOG and README with dependency on json-c
Date: Mon, 29 Sep 2025 14:07:56 +0200
Message-ID: <20250929120756.46075-9-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
Acked-by: Oleksii Kurochko 
---
 CHANGELOG.md | 2 ++
 README       | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7b9518ff08..5c70bc0250 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - Debian Trixie added to CI.  Debian Bullseye retired from CI for RISC-V due
    to the baseline change.
  - Linux based device model stubdomains are now fully supported.
+ - New dependency on library json-c, the toolstack will prefer it to `YAJL`
+   when available.
 
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
diff --git a/README b/README
index 6ee58f7b35..9329f30e13 100644
--- a/README
+++ b/README
@@ -53,7 +53,7 @@ provided by your OS distributor:
     * Development install of Python 2.7 or later (e.g., python-dev)
     * Development install of curses (e.g., libncurses-dev)
     * Development install of uuid (e.g. uuid-dev)
-    * Development install of yajl (e.g. libyajl-dev)
+    * Development install of json-c (e.g. libjson-c-dev) or yajl (e.g. libyajl-dev)
     * Development install of libaio (e.g. libaio-dev) version 0.3.107 or
       greater.
     * Development install of GLib v2.0 (e.g. libglib2.0-dev)
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132738.1470977 (Exim 4.92)
	(envelope-from )
	id 1v3Cfh-0007QG-Pl; Mon, 29 Sep 2025 12:08:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132738.1470977; Mon, 29 Sep 2025 12:08: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 1v3Cfh-0007Q9-Ml; Mon, 29 Sep 2025 12:08:01 +0000
Received: by outflank-mailman (input) for mailman id 1132738;
 Mon, 29 Sep 2025 12:08:00 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Cfg-0007Pr-4u
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:08:00 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Cff-00GXAu-2k;
 Mon, 29 Sep 2025 12:07:59 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (helo=l14.home)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1v3Cff-004JHo-2o;
 Mon, 29 Sep 2025 12:07:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=TkLeJKOy6W2+2/EbdbLvrKVsvOauvUqw0+FWVe+Qo5U=; b=KOPHVlCU3Hqbv1GIBsL7wMjXTv
	EBRaUzQxZQgXdw61BgRWDOGSEIxKG3Ni7e1K4hs2/3tYGMc2TNr7puBHE5jNt9OjjpQNA81Lj18db
	lC+EbSUedTHcoJd4JBhZ2E/r4fk8lkZPJotnr0B/jkn7nix9ZM20Z2njqhgFJclyZL2U=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Juergen Gross 
Subject: [XEN PATCH v2 1/8] tools/configure: Introduce deps on json-c lib for libxl
Date: Mon, 29 Sep 2025 14:07:49 +0200
Message-ID: <20250929120756.46075-2-anthony@xenproject.org>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>
References: <20250929120756.46075-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

To replace yajl.

Introduce XEN_JSON_LIBS variable, to be able to remove "-lyajl" later.

As a first step, the variable will have both or only -lyajl. Then
commit "configure: Use json-c by default, fallback to yajl" will make
a change to only have one or the other once the code is ready to build
with only json-c.

Signed-off-by: Anthony PERARD 
---

Notes:
    v2:
    - Introduce $(XEN_JSON_LIBS) to contain either of -lyajl or -ljson-c or
      both. At first, the variable will have both or only -lyajl, then
      commit "configure: Use json-c by default, fallback to yajl" will make
      a change to only have one or the other.

 config/Tools.mk.in        |   1 +
 tools/config.h.in         |   3 ++
 tools/configure           | 107 +++++++++++++++++++++++++++++++++++++-
 tools/configure.ac        |   6 ++-
 tools/libs/light/Makefile |   4 +-
 tools/xl/Makefile         |   2 +-
 6 files changed, 117 insertions(+), 6 deletions(-)

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index e47ac23d11..0037ad5a64 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -65,6 +65,7 @@ EXTFS_LIBS          := @EXTFS_LIBS@
 CURSES_LIBS         := @CURSES_LIBS@
 TINFO_LIBS          := @TINFO_LIBS@
 ARGP_LDFLAGS        := @argp_ldflags@
+XEN_JSON_LIBS       := @YAJL_LIBS@ @libjsonc_LIBS@
 
 FILE_OFFSET_BITS    := @FILE_OFFSET_BITS@
 
diff --git a/tools/config.h.in b/tools/config.h.in
index fe2a94cfc4..ed0042018d 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -27,6 +27,9 @@
 /* Define to 1 if you have the `fdt' library (-lfdt). */
 #undef HAVE_LIBFDT
 
+/* Use library json-c */
+#undef HAVE_LIBJSONC
+
 /* Define to 1 if you have the `lzma' library (-llzma). */
 #undef HAVE_LIBLZMA
 
diff --git a/tools/configure b/tools/configure
index 5abd44e21e..edd1701b2d 100755
--- a/tools/configure
+++ b/tools/configure
@@ -660,6 +660,9 @@ libnl
 LIBNL3_LIBS
 LIBNL3_CFLAGS
 argp_ldflags
+YAJL_LIBS
+libjsonc_LIBS
+libjsonc_CFLAGS
 PTHREAD_LIBS
 PTHREAD_LDFLAGS
 PTHREAD_CFLAGS
@@ -882,6 +885,8 @@ pixman_CFLAGS
 pixman_LIBS
 libzstd_CFLAGS
 libzstd_LIBS
+libjsonc_CFLAGS
+libjsonc_LIBS
 LIBNL3_CFLAGS
 LIBNL3_LIBS
 SYSTEMD_SLEEP_DIR'
@@ -1633,6 +1638,10 @@ Some influential environment variables:
               C compiler flags for libzstd, overriding pkg-config
   libzstd_LIBS
               linker flags for libzstd, overriding pkg-config
+  libjsonc_CFLAGS
+              C compiler flags for libjsonc, overriding pkg-config
+  libjsonc_LIBS
+              linker flags for libjsonc, overriding pkg-config
   LIBNL3_CFLAGS
               C compiler flags for LIBNL3, overriding pkg-config
   LIBNL3_LIBS linker flags for LIBNL3, overriding pkg-config
@@ -9624,6 +9633,99 @@ printf "%s\n" "$ax_cv_pthread_flags" >&6; }
 
 
 
+
+pkg_failed=no
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for libjsonc" >&5
+printf %s "checking for libjsonc... " >&6; }
+
+if test -n "$libjsonc_CFLAGS"; then
+    pkg_cv_libjsonc_CFLAGS="$libjsonc_CFLAGS"
+ elif test -n "$PKG_CONFIG"; then
+    if test -n "$PKG_CONFIG" && \
+    { { printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists --print-errors \"json-c\""; } >&5
+  ($PKG_CONFIG --exists --print-errors "json-c") 2>&5
+  ac_status=$?
+  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; then
+  pkg_cv_libjsonc_CFLAGS=`$PKG_CONFIG --cflags "json-c" 2>/dev/null`
+		      test "x$?" != "x0" && pkg_failed=yes
+else
+  pkg_failed=yes
+fi
+ else
+    pkg_failed=untried
+fi
+if test -n "$libjsonc_LIBS"; then
+    pkg_cv_libjsonc_LIBS="$libjsonc_LIBS"
+ elif test -n "$PKG_CONFIG"; then
+    if test -n "$PKG_CONFIG" && \
+    { { printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists --print-errors \"json-c\""; } >&5
+  ($PKG_CONFIG --exists --print-errors "json-c") 2>&5
+  ac_status=$?
+  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; then
+  pkg_cv_libjsonc_LIBS=`$PKG_CONFIG --libs "json-c" 2>/dev/null`
+		      test "x$?" != "x0" && pkg_failed=yes
+else
+  pkg_failed=yes
+fi
+ else
+    pkg_failed=untried
+fi
+
+
+
+if test $pkg_failed = yes; then
+   	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: no" >&5
+printf "%s\n" "no" >&6; }
+
+if $PKG_CONFIG --atleast-pkgconfig-version 0.20; then
+        _pkg_short_errors_supported=yes
+else
+        _pkg_short_errors_supported=no
+fi
+        if test $_pkg_short_errors_supported = yes; then
+	        libjsonc_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors --cflags --libs "json-c" 2>&1`
+        else
+	        libjsonc_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs "json-c" 2>&1`
+        fi
+	# Put the nasty error message in config.log where it belongs
+	echo "$libjsonc_PKG_ERRORS" >&5
+
+	as_fn_error $? "Package requirements (json-c) were not met:
+
+$libjsonc_PKG_ERRORS
+
+Consider adjusting the PKG_CONFIG_PATH environment variable if you
+installed software in a non-standard prefix.
+
+Alternatively, you may set the environment variables libjsonc_CFLAGS
+and libjsonc_LIBS to avoid the need to call pkg-config.
+See the pkg-config man page for more details." "$LINENO" 5
+elif test $pkg_failed = untried; then
+     	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: no" >&5
+printf "%s\n" "no" >&6; }
+	{ { printf "%s\n" "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+printf "%s\n" "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "The pkg-config script could not be found or is too old.  Make sure it
+is in your PATH or set the PKG_CONFIG environment variable to the full
+path to pkg-config.
+
+Alternatively, you may set the environment variables libjsonc_CFLAGS
+and libjsonc_LIBS to avoid the need to call pkg-config.
+See the pkg-config man page for more details.
+
+To get pkg-config, see .
+See \`config.log' for more details" "$LINENO" 5; }
+else
+	libjsonc_CFLAGS=$pkg_cv_libjsonc_CFLAGS
+	libjsonc_LIBS=$pkg_cv_libjsonc_LIBS
+        { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: yes" >&5
+printf "%s\n" "yes" >&6; }
+
+printf "%s\n" "#define HAVE_LIBJSONC 1" >>confdefs.h
+
+fi
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 printf %s "checking for yajl_alloc in -lyajl... " >&6; }
 if test ${ac_cv_lib_yajl_yajl_alloc+y}
@@ -9661,9 +9763,10 @@ fi
 printf "%s\n" "$ac_cv_lib_yajl_yajl_alloc" >&6; }
 if test "x$ac_cv_lib_yajl_yajl_alloc" = xyes
 then :
-  printf "%s\n" "#define HAVE_LIBYAJL 1" >>confdefs.h
+  YAJL_LIBS=-lyajl
 
-  LIBS="-lyajl $LIBS"
+
+printf "%s\n" "#define HAVE_LIBYAJL 1" >>confdefs.h
 
 else $as_nop
   as_fn_error $? "Could not find yajl" "$LINENO" 5
diff --git a/tools/configure.ac b/tools/configure.ac
index dada1c3b15..bb40b5b3f0 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -424,7 +424,11 @@ AC_SUBST([ZLIB_CFLAGS])
 AC_SUBST([ZLIB_LIBS])
 AX_CHECK_EXTFS
 AX_CHECK_PTHREAD
-AC_CHECK_LIB([yajl], [yajl_alloc], [],
+PKG_CHECK_MODULES([libjsonc], [json-c],
+    [AC_DEFINE([HAVE_LIBJSONC], [1], [Use library json-c])])
+AC_CHECK_LIB([yajl], [yajl_alloc],
+   [AC_SUBST([YAJL_LIBS],[-lyajl])
+    AC_DEFINE([HAVE_LIBYAJL],[1],[Define to 1 if you have the `yajl' library (-lyajl).])],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])
 AC_CHECK_HEADER([argp.h], [
diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
index b690d92159..c05d89db33 100644
--- a/tools/libs/light/Makefile
+++ b/tools/libs/light/Makefile
@@ -166,7 +166,7 @@ LDLIBS-$(CONFIG_Linux) += -luuid
 LDLIBS-$(CONFIG_Linux) += -lrt
 LDLIBS-$(CONFIG_ARM) += -lfdt
 LDLIBS-y += $(PTHREAD_LIBS)
-LDLIBS-y += -lyajl
+LDLIBS-y += $(XEN_JSON_LIBS)
 LDLIBS += $(LDLIBS-y)
 
 $(OBJS-y) $(PIC_OBJS) $(LIBXL_TEST_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
@@ -246,7 +246,7 @@ libxenlight_test.so: $(PIC_OBJS) $(LIBXL_TEST_OBJS)
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
 
 test_%: test_%.o test_common.o libxenlight_test.so
-	$(CC) $(LDFLAGS) -o $@ $^ $(filter-out %libxenlight.so, $(LDLIBS_libxenlight)) $(LDLIBS_libxentoollog) $(LDLIBS_libxentoolcore) -lyajl $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $^ $(filter-out %libxenlight.so, $(LDLIBS_libxenlight)) $(LDLIBS_libxentoollog) $(LDLIBS_libxentoolcore) $(XEN_JSON_LIBS) $(APPEND_LDFLAGS)
 
 libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxentoollog) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxentoolcore) $(APPEND_LDFLAGS)
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index ad577cdd70..973ff0e1a2 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -33,7 +33,7 @@ $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs i
 all: xl
 
 xl: $(XL_OBJS)
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) $(LDLIBS_libxenutil) $(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) -lyajl $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) $(LDLIBS_libxenutil) $(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(XEN_JSON_LIBS) $(APPEND_LDFLAGS)
 
 .PHONY: install
 install: all
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:10:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:10:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132812.1471068 (Exim 4.92)
	(envelope-from )
	id 1v3Ci8-0004c2-MN; Mon, 29 Sep 2025 12:10:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132812.1471068; Mon, 29 Sep 2025 12: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 1v3Ci8-0004bv-JI; Mon, 29 Sep 2025 12:10:32 +0000
Received: by outflank-mailman (input) for mailman id 1132812;
 Mon, 29 Sep 2025 12:10:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3Ci6-0004bf-T5
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:10:30 +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 4a88eb07-9d2d-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 14:10:29 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-b30ead58e0cso858867666b.0
 for ; Mon, 29 Sep 2025 05:10:30 -0700 (PDT)
Received: from [192.168.8.247] ([212.222.86.216])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3b0c9c9e8esm444875766b.59.2025.09.29.05.10.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 05:10: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: 4a88eb07-9d2d-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1759147829; x=1759752629; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=py42YJLn6IdwAubF9PhPBI066HQ1A8czgq+XUGd6Zkg=;
        b=t6KT66CJvI2typCkZjMCrQMwimBJ25mnKfWvQZeiceHMjAs52gy2HUHsgPaKLwxZfH
         kwVYWGC2IlB+07XsqP5NDVLDO4upusamWAv+nNFwTyiHw7ea5arb3tMH5CILuAYx12da
         SvGQZyXOfz9dGff6gfSTiKtRN2K+957JWBPqY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759147829; x=1759752629;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=py42YJLn6IdwAubF9PhPBI066HQ1A8czgq+XUGd6Zkg=;
        b=OYjznAk2UCt3EcAKSaMaMjbAv4/y0aPuzd+0DtN8WyM/0/r6fqtIwWqlhG5oIHr4lF
         pjAqC0GbVD8f1bql1OZJl0eq9K+2GOtIwv4jm5kBouAbFCegjRl8y3tLPMcFETkrzGea
         eGliRWZjGzjZQRYzprly0wqo1Hw49djDWprIuafG+YkoSBWLF1dfnKdR6T8a+lgJ89CY
         wXmgHZ2y2tXYXa1vjBekaNz7KUWKDAFlh6gQaS0VSu5mOlUDywt7o9BB8BbhoiN2lk0W
         fqPwPhU9AYrNUhtR2HSXriJq9v8iW+s1DSVy9rA1P+LACaFSbd7xrJiH8IW/a1NCv77w
         O5wA==
X-Forwarded-Encrypted: i=1; AJvYcCWyxX9TmTmmpynuLPPt7JK0C/cd9iztipIJ7vO0xypSNaQIGfQ5CMIoG7rPKa1rg2oWaTo9bxW1m7U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzYJFW0BiW1ntoFCVrBgVywpqOIDkPn0FsaCJjvCaheQbJmNvOm
	zclJIrCfoxEX0H6xVc8tbB/Ak24OewliPhIFl1D0bTnptWldEclmJPAyq/Wm7gEcnfQ=
X-Gm-Gg: ASbGnctMxP/AlaQzNslM3C8kTRQ/u6W/WiysOyFaFleuBAlNqWO3eCVRabfpxehPiIL
	IJCiZcZGmiOmlps7dOQLdC+Vl2jEbg1gShvCWaFqZxWfupe5wiSiNZYWcA2FMF5QGSZezNE2JMt
	PNS4yNYzrmJWsY/Z0ILayc3HFWHWf62ogsX9ek/+ODL+NwNPgjUtVwtH1RRQMt8wimq7IdYlfDp
	N3zQMf2SOuf6yh9TPgT1MKUslYgWDGaggBScqcyuJJUdOYD9urIE16V+TGjZ6v4CAl/42ICplai
	hb92o5Lj8d/SSCd16ke2+SYgXTYlzzycTXDuVPd/KGJVPYOV4RhURu9lRdgmO2OIWnGJVTupZQj
	DxGeZtDmKvS9W3cmV+5hDcUmB48oUgj5BlPgsFYE9Eu51MXJqKjCRBrfegmB6
X-Google-Smtp-Source: AGHT+IGz24cXJNjyg6Z+JiXPmlST6oUqRKGRuN+AIYRWFXVQQYlfzNVcmhDbmHtVu88uzZ4SzU8KTA==
X-Received: by 2002:a17:906:7304:b0:b3a:b22e:dd35 with SMTP id a640c23a62f3a-b3ab22ee9c8mr811125166b.2.1759147829346;
        Mon, 29 Sep 2025 05:10:29 -0700 (PDT)
Message-ID: <1ca535e2-ff36-4076-8fc5-701b582a7df3@citrix.com>
Date: Mon, 29 Sep 2025 14:10:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/8] tools/configure: Introduce deps on json-c lib
 for libxl
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Juergen Gross 
References: <20250929120756.46075-1-anthony@xenproject.org>
 <20250929120756.46075-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: <20250929120756.46075-2-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29/09/2025 1:07 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> To replace yajl.
>
> Introduce XEN_JSON_LIBS variable, to be able to remove "-lyajl" later.
>
> As a first step, the variable will have both or only -lyajl. Then
> commit "configure: Use json-c by default, fallback to yajl" will make
> a change to only have one or the other once the code is ready to build
> with only json-c.
>
> Signed-off-by: Anthony PERARD 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:14:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:14:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132828.1471077 (Exim 4.92)
	(envelope-from )
	id 1v3Clm-0005Fo-8r; Mon, 29 Sep 2025 12:14:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132828.1471077; Mon, 29 Sep 2025 12: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 1v3Clm-0005Fh-6I; Mon, 29 Sep 2025 12:14:18 +0000
Received: by outflank-mailman (input) for mailman id 1132828;
 Mon, 29 Sep 2025 12:14: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 1v3Clk-0005Fb-Sx
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:14:16 +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 d08e8790-9d2d-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 14:14:14 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-62ecd3c21d3so8458452a12.0
 for ; Mon, 29 Sep 2025 05:14:14 -0700 (PDT)
Received: from [192.168.8.247] ([212.222.86.216])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3b052e0sm7709713a12.47.2025.09.29.05.14.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 05:14: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: d08e8790-9d2d-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1759148054; x=1759752854; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=V1kO4P4oZ3V4mw5A3Jn0b05sxoswVkZFZubupIVrQ+U=;
        b=cJ6Vrnny/BNFPAaJwvFS65kTGT+J/hNsJtExb0DEmvy13U90ZUFP3x5DJwma2BqoSS
         /1edIgkSjjKVSHlRYzSfYZyvJaigasWKajA2QlKVoLAvMnnIVKB8Maw4iOrSU7ss3SX2
         mYVzLkYu81KzYk8/IUfM8Wy9b7NO2uKJ6n+3c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759148054; x=1759752854;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=V1kO4P4oZ3V4mw5A3Jn0b05sxoswVkZFZubupIVrQ+U=;
        b=qJs5LykLPOGLOCtSCtC5Evyi1BR7ifrw2I64owoCzuqDEv9m7FDSsw7rrQat9KMxCk
         dBWXhA3GOZIpja7TJEdVYUsKgPErHCVD9bPtQqG1TBkRWcOEAScK3LayHJmhnllYRPxh
         l/vjIIm9VSgBlq6+766iEaEmX72v+dVjbMJbrF6HvNaII6YvzWr9jTDElXhPdhuzp+o/
         i1w2Kg/HcW/jP8USzHGmh/9XwhWE9Vo1BC5R33v9oIP3MDbIydKKt0KNolyLjBKD9y/D
         ovn24KZQsELxLVat0C5yNzEDGL8tIZdd7YJFdWrzO4Vs3GgQ9k1edg45WuFyIWyQiAWn
         h5eg==
X-Forwarded-Encrypted: i=1; AJvYcCXSGpT17HiwkZUU/Ar4vWopM9++txcWcYid9qss9lObuQ+NZizq2cDVIuBrtW4v6700ihMlxZ2BCTk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzI2HDpav/CTL4pklLAFsuV3kEN8Ny+t29LYicLFIC0gfDQtWs1
	+aRILAxHuwXhE59FsM4FyUNj0L3XFgzrPv4Ei9img/udBUl0WDXHYRXAl3pzobzfTZs=
X-Gm-Gg: ASbGncvBb/wzQRr+uoFaMpxPOtnOTC5p5330xWKohLwDw6X9gPE5gxBbVSuR703AWLH
	S8UIlfnVeFaKQBtieL8m6t3HXZvRY0k0UIuz5YKCOylbEJBEi4oZTULUNkCBQzPt6j8kcu7eI/p
	uC5+Z8ahdvsQerTyihliqxgUH1vCeywE2YbjF9ygLkZwgWJe3QvBSRLycL5GJznyNcwJ8tumcg7
	epQgTZ/IlmTJsKvalSmm6tAa/Kaj3QK/4NPahhDN6DNUH0DRLYd57A/v2+ycEzkay5r0FVnKlvE
	XeyYdDzRV9Uyp/tJPybDnMDiBZduSfRqaY+MldLR6XzqpnhmfAmBBxTZjBEs05uhTx+hLLBhoLU
	UcnwK8hpPVaXRJ2uH8kMZdRD9aBosLW6JOyzIX31eNOrzv34ZWA==
X-Google-Smtp-Source: AGHT+IEKvBNHlD7v5oc3z7yPLuq/29kbqm0pbiDJLEh4p1+G3JaC3eQ9uycbGd3suXQDWibrCAQcSQ==
X-Received: by 2002:a05:6402:395:b0:62f:4192:ff9f with SMTP id 4fb4d7f45d1cf-6349fa80038mr11255984a12.21.1759148054162;
        Mon, 29 Sep 2025 05:14:14 -0700 (PDT)
Message-ID: <36561c83-f81d-452e-b043-9f4e9e41ef97@citrix.com>
Date: Mon, 29 Sep 2025 14:14:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 7/8] configure: Use json-c by default, fallback to
 yajl
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
References: <20250929120756.46075-1-anthony@xenproject.org>
 <20250929120756.46075-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: <20250929120756.46075-8-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29/09/2025 1:07 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Signed-off-by: Anthony PERARD 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:16:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:16:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132838.1471088 (Exim 4.92)
	(envelope-from )
	id 1v3CnP-0005lj-JA; Mon, 29 Sep 2025 12:15:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132838.1471088; Mon, 29 Sep 2025 12:15: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 1v3CnP-0005lc-Fw; Mon, 29 Sep 2025 12:15:59 +0000
Received: by outflank-mailman (input) for mailman id 1132838;
 Mon, 29 Sep 2025 12:15:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3CnN-0005lP-WB
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:15:57 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0d9a1d71-9d2e-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 14:15:57 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-6349e3578adso8651934a12.1
 for ; Mon, 29 Sep 2025 05:15:57 -0700 (PDT)
Received: from [192.168.8.247] ([212.222.86.216])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a36521c2sm7688750a12.20.2025.09.29.05.15.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 05:15: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: 0d9a1d71-9d2e-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1759148157; x=1759752957; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0uJfdq99ZFSj4Y7ZmIXLFXFPVLt8HZtLsTj6lm3PIkw=;
        b=bfM1QmTu/Jm/c6lBBbBLMe0bNOzQw/PyJ2kf1LbgrnQ+RN3XsZQSGqj4iYKzjP28/n
         5r6aJGMbwrGxX9YLigc1QYefk8gugpZ8r1zqgee+zX0syOLXEO+vk4DFms67oXuHp8+r
         K5/L5rMvVfofd/HQrmmDnDPmwi9mYbE/jW8us=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759148157; x=1759752957;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0uJfdq99ZFSj4Y7ZmIXLFXFPVLt8HZtLsTj6lm3PIkw=;
        b=hLNnlAAP+5I0xVcPwFdxMwzfsXGN0lOjW6EUQXFZY1u8U91t5EY8ZzUzBbxcjIcVdd
         zpJ7NDbAzp5ZJ/Fasgz/upkGpoETkmt1s0V2aE45mQ1fPcNkRhqS/I3DT62zJWdi7Wxv
         Ds9L0luyQswOKzWT/F16HToAmSU0TAbqY+7XcMVZrbT3PZgVetOC4tXd3nk8PCxdz4bO
         Siu9kZEuJCl5CwyoGyEx/un6pDF8mXL8GAKogVguRf6WsjjuJCNE/M+t36Ll34RM+fxd
         larNbrZ2gboi8uBdvHzm+XWsWxY9rRzgUEK6MSlBgAz966WCgNL0M1+A6Yl4kH/xDDD0
         6zDQ==
X-Forwarded-Encrypted: i=1; AJvYcCUbFEguDQwMJLuJFC/SEHXIBPluc0DEfblHuOjq6KQYb7ukiS6abSw+2s1Wr3P3rggHqtYJ2riYHdU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzT9e35atLqY9U1+CAxqEeo7382MUK5b482dqv1k0dFBqpsWBjc
	CTS/vJld2xpceZ3dIxgWlb1GqGuASggCjGBXH6xDf0n8RhljbV0VjRmojICwM012jVM=
X-Gm-Gg: ASbGnctxqI6vXuR49Giu7JB1IsVedPy7Idsa0N7C1Hfeit/knbCfloGD6xgZCbmxkO3
	mYQEBKcr1d14QeIdau0cAofEHVoOClnd2gImt1Q1ovB2la3m96lJa7eTGNMHGASg7CGtr0cVWbO
	RknmvPPr4tS/2VxBzxuN6GJqj1Tt5ZgfUm8D+JLAX/mptYu/q+yMpT1xkeuP+NUpfCmE8+P+EHD
	O5wFRz5eHhFnj974FJdQXg7oP+lUisd7tnDn6bIUOvXVFb+WnWUY1tfHsASkl/ocqePqEghap7U
	cxnDkNmBONUzlTnPDSbrmT1jmufJmbETZmKwNGNjb92JXdxCJgzN99nNetWLeNGycX4OhcHSXNt
	cwhjvj75Uqr0U/Xfe4l4CWgtQ8wdTYmupCPnp9+zDTuj5AqOZUw==
X-Google-Smtp-Source: AGHT+IG+ObOrbFlBdfLKftFP83HBRU6kXRjU/nNZIECrK3tlnMWooBc8R/EonH1/wn4QX3Q0fFqfmw==
X-Received: by 2002:a05:6402:748:b0:629:3f9d:b06c with SMTP id 4fb4d7f45d1cf-6349faa220emr11522403a12.33.1759148156629;
        Mon, 29 Sep 2025 05:15:56 -0700 (PDT)
Message-ID: <14953714-b760-4365-b6bd-5bfd038a145a@citrix.com>
Date: Mon, 29 Sep 2025 14:15:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 8/8] Update CHANGELOG and README with dependency on
 json-c
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20250929120756.46075-1-anthony@xenproject.org>
 <20250929120756.46075-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: <20250929120756.46075-9-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 29/09/2025 1:07 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Signed-off-by: Anthony PERARD 
> Acked-by: Oleksii Kurochko 

Reviewed-by: Andrew Cooper 

Thankyou for doing this.  v2 looks much cleaner.


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 12:36:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 12:36:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132879.1471097 (Exim 4.92)
	(envelope-from )
	id 1v3D7M-0000Hw-5Y; Mon, 29 Sep 2025 12:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132879.1471097; Mon, 29 Sep 2025 12: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 1v3D7M-0000Hp-2w; Mon, 29 Sep 2025 12:36:36 +0000
Received: by outflank-mailman (input) for mailman id 1132879;
 Mon, 29 Sep 2025 12:36: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 1v3D7K-0000Hj-GO
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 12:36:34 +0000
Received: from mail132-16.atl131.mandrillapp.com
 (mail132-16.atl131.mandrillapp.com [198.2.132.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed8d4d53-9d30-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 14:36:32 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4cb0zz09xHzB5pFhv
 for ; Mon, 29 Sep 2025 12:36:31 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 6fa71c65d6dc4ebbb0a9e75aa3c277f5; Mon, 29 Sep 2025 12:36: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: ed8d4d53-9d30-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1759149391; x=1759419391;
	bh=YnSW9gELxUcxloQJ2wKYxscreQekHZqw75K18b2Lbho=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=tRKtT+grGRD7c/odQU2LEoKSB7rhYzUyieCQ39ahD2J75bQPKD1priTmgK6nlh+Kz
	 XGwbKBUtPlh92RSYzg+TOFvR/5qv5ByQSdWsBR7/OTLpV7F7fFSCbuOXReHD4TO/RK
	 oRW5NXp4aAt5n6ADDRAqsQmjjWER/oJ1H7hN5MGXwqexQlD8bZkIazsO4IwOnx6SEF
	 J1+Qqg7/ZDcfmg24DBSH3TvI8a9DJHkNwAxkRXqR8GU5sSz/y92NF07zD4XVElLa7n
	 tbcR+5RK1VyNmaooytsRtZk76uO0khiKJePecckMkmJgKDO/cxgT3ib+G9xFW3aMY+
	 79fWXm8ENRhgQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1759149391; x=1759409891; i=teddy.astie@vates.tech;
	bh=YnSW9gELxUcxloQJ2wKYxscreQekHZqw75K18b2Lbho=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=Tg0g1LnoGgLI0Fvzw9egH0Ox/2EpcBByDwFKo8uQW3WLSDO4TbdzRdCR3xyH84iFf
	 XrBw4BSX6zcvZW7ukHxCjhsjlJhhjtHKxNZwwELQ5kPspsnrWQ/FXo9OEOt457RnVB
	 dEZxTi92FOxIbK4SozFUY5gkz85zEzyd3ivLgF8+6ofui48rUoasM7kAVr/1LTMa15
	 Mut9i2mdGIrghnkSh7baP3Shz95gGFAtDnOSBQtywn9ob+luOkVcaQ7c0izu6PXSLK
	 oYkFxlEOo5nedZOKnNEmLIihOBPDPnRTpdaYIp4KSJpthaRSf12PINNm2+MUSecLKx
	 bgdKIORh83cRg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[PATCH]=20x86/hap:=20Inline=20"flush=5Fvcpu"=20in=20"flush=5Ftlb"?=
X-Mailer: git-send-email 2.51.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1759149389822
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.6fa71c65d6dc4ebbb0a9e75aa3c277f5?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250929:md
Date: Mon, 29 Sep 2025 12:36:30 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

flush_vcpu static function here is only used in one place which is just below
where it is defined. Inline the function to reduce the noise and clarify
what we are doing.

No functional change.

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/mm/hap/hap.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 2f69ff9c7b..407c80afab 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -721,11 +721,6 @@ static pagetable_t cf_check hap_update_cr3(struct vcpu *v, bool noflush)
     return pagetable_null();
 }
 
-static bool flush_vcpu(const struct vcpu *v, const unsigned long *vcpu_bitmap)
-{
-    return !vcpu_bitmap || test_bit(v->vcpu_id, vcpu_bitmap);
-}
-
 /* Flush TLB of selected vCPUs.  NULL for all. */
 static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap)
 {
@@ -742,7 +737,7 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap)
     {
         unsigned int cpu;
 
-        if ( !flush_vcpu(v, vcpu_bitmap) )
+        if ( vcpu_bitmap && !test_bit(v->vcpu_id, vcpu_bitmap) )
             continue;
 
         hvm_asid_flush_vcpu(v);
-- 
2.51.0



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 13:21:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 13:21:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132893.1471108 (Exim 4.92)
	(envelope-from )
	id 1v3DoR-0006Jv-Dq; Mon, 29 Sep 2025 13:21:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132893.1471108; Mon, 29 Sep 2025 13:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3DoR-0006Jo-B0; Mon, 29 Sep 2025 13:21:07 +0000
Received: by outflank-mailman (input) for mailman id 1132893;
 Mon, 29 Sep 2025 13:21:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3DoR-0006Ji-1A
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 13:21:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3DoQ-00GYq3-0R;
 Mon, 29 Sep 2025 13:21:06 +0000
Received: from [2a01:cb15:80df:da00:e2a9:ff82:7bde:38cd] (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 1v3DoQ-004RhK-0H;
 Mon, 29 Sep 2025 13:21: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=sNHZjtNfG2q8oc5l8nFvNB4eU1aaQOodtx2TEvCMTaU=; b=c702pkLnawxSLysLiZBgVUyDTY
	+RAiwJdL0VFsKls4PQoDycU/XHBVBvhWDzG19VtASMUNGqQykVQew9PEBrPTBOBDCdA74I18+SlDB
	iWNmtqDlZmNOq4s5VuItSCzgBOJbERTKMUcNG2F4gsxjRhfx4uW5eP6X9XVE7KkN7i9A=;
Date: Mon, 29 Sep 2025 15:21:04 +0200
From: Anthony PERARD 
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= ,
	Oleksii Kurochko 
Cc: Jason Andryuk , xen-devel@lists.xenproject.org,
	Alejandro Vallejo ,
	Anthony PERARD 
Subject: Re: [PATCH v2 0/3] xenconsole: Add connection flag
Message-ID: 
References: <20250822213946.245307-1-jason.andryuk@amd.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Sep 09, 2025 at 12:18:26PM +0200, Jrgen Gro wrote:
> On 22.08.25 23:39, Jason Andryuk wrote:
> > Add a connection flag to the console interface page so a domain can tell
> > if it is connected or not.  This became a series in v2 to add flag
> > setting to libxenguest.
> > 
> > Jason Andryuk (3):
> >    xenconsole: Add connection flag
> >    libs/guest: Set console page to disconnected
> >    libs/guest: Set console as disconnected on resume
> > 
> >   tools/console/daemon/io.c                |  4 +++
> >   tools/include/xenguest.h                 |  4 +++
> >   tools/libs/guest/xg_dom_arm.c            |  2 +-
> >   tools/libs/guest/xg_dom_boot.c           | 36 ++++++++++++++++++++++++
> >   tools/libs/guest/xg_dom_x86.c            |  6 ++--
> >   tools/libs/guest/xg_sr_restore_x86_hvm.c |  2 +-
> >   tools/libs/guest/xg_sr_restore_x86_pv.c  |  1 +
> >   xen/include/public/io/console.h          | 13 +++++++++
> >   8 files changed, 63 insertions(+), 5 deletions(-)
> > 
> 
> For the series:
> 
> Reviewed-by: Juergen Gross 

For the series:
Acked-by: Anthony PERARD 

Hi Oleksii,
I think this series needs your "release-ack" tag.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 13:30:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 13:30:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132904.1471118 (Exim 4.92)
	(envelope-from )
	id 1v3DxC-0007vE-7J; Mon, 29 Sep 2025 13:30:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132904.1471118; Mon, 29 Sep 2025 13: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 1v3DxC-0007v7-4d; Mon, 29 Sep 2025 13:30:10 +0000
Received: by outflank-mailman (input) for mailman id 1132904;
 Mon, 29 Sep 2025 13: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 1v3DxA-0007v1-Rw
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 13:30:08 +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 69a15753-9d38-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 15:30:06 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-6349e3578adso8806782a12.1
 for ; Mon, 29 Sep 2025 06:30:06 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3629badsm7649720a12.9.2025.09.29.06.30.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 06:30: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: 69a15753-9d38-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759152606; x=1759757406; 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=LoFmK086RkMBGflYJD4fDTytSAuNZZfh2xt7GTMgSbA=;
        b=PyzgD0+yKxLTf97xojphoiSHKnBOJrFfc3+/cWMI9iSq+mpAMBFH56NzI0eD8LyxJl
         10MAEu69dlTaC95QFE2+0czk4iihQbZcBdj4DjAzzpBp5+NYHuQjWGFxDbx36xiythcZ
         qDPTEkLGQFf34jw5zdvI82ETpvfLQtDs8eT9aE9WlLJ1KA0H6TWybmEaBsmlDgn/l3KC
         wLsXVGpJVP8ArRydM7T3KzIIrgzVIZuC+m56rfQJuwVFPf5KAQ4JtHNuV5XznJ9LUuJP
         JWskt8DnISD4HDY09eIS325HrkE0lyN4IynLD6UPJPpPXNIi/xGkz/mxs/6t7Xks38Gb
         zYWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759152606; x=1759757406;
        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=LoFmK086RkMBGflYJD4fDTytSAuNZZfh2xt7GTMgSbA=;
        b=n/kuob1r7J6G6KirjkAmhHVaJDJJaNnMDVJ/P8qOK/Dfh+9xyUf2URefLfUYwtv2FJ
         GHLKrnGKq4asW1dOkhhwHdF1RensUTK4CkT6fBKFw+Z9l6+eJ1UNu2V02sPLNbT9TQqt
         hw56vytDM8xWQo8AgGSC5CkKy88XFKZYXQF8ft+QFYI0i9bqoZ8xoJ3WJkzIPonPMuUH
         Ok73ezwLi/wAi7KQEfxkrJQXARXiDka7bEuWG5lYzC8mZs0/HFQ4ehEjRzpFoN4shQwe
         1qMrqkHs9T+feeLeHnTTWdKjJfUZajAfxoRQq3QiN3QCHjNurtpFTP2bhUYKGuNf3a8w
         jD8g==
X-Forwarded-Encrypted: i=1; AJvYcCVc3tACPts7DEHL+ZLnb/6o61Qtikk8+kkHbot/jkYOvyGdwXYS4wHUKKV9PEvka/ejy3S/HwEUhIM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxuztJgStJW4dWVHfdPAOZGgb0VZpna0mgfIAVAiKvNpBhIWhWv
	Q44vhaalXKkK8qjvU9XUTPj3ROMxKHz6MJ9JPh/h5+EBeq8qT60U24/0
X-Gm-Gg: ASbGncsIP5kKfnvvK1/GGFnygo3wfX1esCEPpujs1ttGnC81CrVG/wlSoGb3bgC+EFL
	47LSCS1QsskNYJ0re4l9i+hmiYD8xTBwA4TOKFu04gBCrkokX6xv3S5FC6dMazlaWAkTTzbrLGo
	TjRNmyPB4tEHVd/3l4fKbT2YyNYi4lQdHe9FdPLbT0fSXmo9s+LS8jNf0wxtm6G3uPW0UqkhUyt
	Yi7SmSyhgYUzIKdVCDM5mgmGgGrERTOzZCqiL3uPvsqnuIYDNOuBuc4/8lfwaemoBrOFZoCtban
	Dd98eBLKZl8+5clEkg4YDqBnQT9vlP1m6wgJUOfu84nZBNX143JkOmRlYTUZJf3dCZFyReZbh49
	X/YLga3yya3NVQ+5FP+ZbrZbf05zQpsuHci02M5EiyNmU4Sr2dANjT+lZJFm4IANbh2eMstX4
X-Google-Smtp-Source: AGHT+IEevMVPMLGDqxiLwJxvtB7nZhJd8AWn12rS6/ydSAyDLV51NTywfn1Cm5j87XnlZr9z65VkIg==
X-Received: by 2002:a05:6402:274c:b0:634:a992:a2 with SMTP id 4fb4d7f45d1cf-634a99206c6mr14756110a12.1.1759152605591;
        Mon, 29 Sep 2025 06:30:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------n2ywK1zf1NJItpgQ7GwXkx16"
Message-ID: <6902c46e-c805-43aa-8753-7b6dc09716ae@gmail.com>
Date: Mon, 29 Sep 2025 15:30:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 12/18] xen/riscv: Implement p2m_pte_from_mfn() and
 support PBMT configuration
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: 
 <4495c8103548447f9a11963574a4cb9e01090e7a.1758145428.git.oleksii.kurochko@gmail.com>
 <7b51f40d-7ac7-460a-891d-afe1d9ab8991@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <7b51f40d-7ac7-460a-891d-afe1d9ab8991@suse.com>

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


On 9/22/25 6:28 PM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> @@ -318,11 +331,87 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_pte)
>>       p2m_write_pte(p, pte, clean_pte);
>>   }
>>   
>> -static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t)
>> +static void p2m_set_permission(pte_t *e, p2m_type_t t)
>>   {
>> -    panic("%s: hasn't been implemented yet\n", __func__);
>> +    e->pte &= ~PTE_ACCESS_MASK;
>> +
>> +    e->pte |= PTE_USER;
>> +
>> +    /*
>> +     * Two schemes to manage the A and D bits are defined:
>> +     *   • The Svade extension: when a virtual page is accessed and the A bit
>> +     *     is clear, or is written and the D bit is clear, a page-fault
>> +     *     exception is raised.
>> +     *   • When the Svade extension is not implemented, the following scheme
>> +     *     applies.
>> +     *     When a virtual page is accessed and the A bit is clear, the PTE is
>> +     *     updated to set the A bit. When the virtual page is written and the
>> +     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
>> +     *     address translation is in use and is not Bare, the G-stage virtual
>> +     *     pages may be accessed or written by implicit accesses to VS-level
>> +     *     memory management data structures, such as page tables.
>> +     * Thereby to avoid a page-fault in case of Svade is available, it is
>> +     * necesssary to set A and D bits.
>> +     */
>> +    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
>> +        e->pte |= PTE_ACCESSED | PTE_DIRTY;
> All of this depending on menvcfg.ADUE anyway, is this really needed? Isn't
> machine mode software responsible for dealing with this kind of page faults
> (just like the hypervisor is reponsible for dealing with ones resulting
> from henvcfg.ADUE being clear)?

In general, I think you are right.

In this case, though, I just wanted to avoid unnecessary page faults for now.
My understanding is that having such faults handled by the hypervisor can indeed
be useful, for example to track which pages are being accessed. However, since we
currently don’t track page usage, handling these traps would only result in
setting the A and D bits and then returning control to the guest.
To avoid this overhead, I chose to set the bits up front.

>
>> +    switch ( t )
>> +    {
>> +    case p2m_map_foreign_rw:
>> +    case p2m_mmio_direct_io:
>> +        e->pte |= PTE_READABLE | PTE_WRITABLE;
>> +        break;
>> +
>> +    case p2m_ram_rw:
>> +        e->pte |= PTE_ACCESS_MASK;
>> +        break;
>> +
>> +    case p2m_invalid:
>> +        e->pte &= ~PTE_VALID;
>> +        break;
>> +
>> +    case p2m_map_foreign_ro:
>> +        e->pte |= PTE_READABLE;
>> +        break;
>> +
>> +    default:
>> +        ASSERT_UNREACHABLE();
>> +        break;
>> +    }
>> +}
>> +
>> +static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
>> +{
>> +    pte_t e = (pte_t) { PTE_VALID };
>> +
>> +    switch ( t )
>> +    {
>> +    case p2m_mmio_direct_io:
>> +        e.pte |= PTE_PBMT_IO;
>> +        break;
> Shouldn't this be limited to the !is_table case (just like you have it ...
>
>> +    default:
>> +        break;
>> +    }
>> +
>> +    pte_set_mfn(&e, mfn);
>> +
>> +    ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK) || mfn_eq(mfn, INVALID_MFN));
>> +
>> +    if ( !is_table )
>> +    {
>> +        p2m_set_permission(&e, t);
> ... here? Or else at least ASSERT(!is_table) up there? Personally I think
> all of this !is_table stuff would best be done here.

Agree, that this should be done only for leaf PTEs.
I think that I will move that inside p2m_set_permissions() where
p2m_mmio_direct_io case is handled.

Thanks.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/22/25 6:28 PM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
@@ -318,11 +331,87 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_pte)
     p2m_write_pte(p, pte, clean_pte);
 }
 
-static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t)
+static void p2m_set_permission(pte_t *e, p2m_type_t t)
 {
-    panic("%s: hasn't been implemented yet\n", __func__);
+    e->pte &= ~PTE_ACCESS_MASK;
+
+    e->pte |= PTE_USER;
+
+    /*
+     * Two schemes to manage the A and D bits are defined:
+     *   • The Svade extension: when a virtual page is accessed and the A bit
+     *     is clear, or is written and the D bit is clear, a page-fault
+     *     exception is raised.
+     *   • When the Svade extension is not implemented, the following scheme
+     *     applies.
+     *     When a virtual page is accessed and the A bit is clear, the PTE is
+     *     updated to set the A bit. When the virtual page is written and the
+     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
+     *     address translation is in use and is not Bare, the G-stage virtual
+     *     pages may be accessed or written by implicit accesses to VS-level
+     *     memory management data structures, such as page tables.
+     * Thereby to avoid a page-fault in case of Svade is available, it is
+     * necesssary to set A and D bits.
+     */
+    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
+        e->pte |= PTE_ACCESSED | PTE_DIRTY;


      

      
All of this depending on menvcfg.ADUE anyway, is this really needed? Isn't
machine mode software responsible for dealing with this kind of page faults
(just like the hypervisor is reponsible for dealing with ones resulting
from henvcfg.ADUE being clear)?

    

    
In general, I think you are right.

    
In this case, though, I just wanted to avoid unnecessary page faults for now.
My understanding is that having such faults handled by the hypervisor can indeed
be useful, for example to track which pages are being accessed. However, since we
currently don’t track page usage, handling these traps would only result in
setting the A and D bits and then returning control to the guest.
To avoid this overhead, I chose to set the bits up front.



    

      



      

        
+    switch ( t )
+    {
+    case p2m_map_foreign_rw:
+    case p2m_mmio_direct_io:
+        e->pte |= PTE_READABLE | PTE_WRITABLE;
+        break;
+
+    case p2m_ram_rw:
+        e->pte |= PTE_ACCESS_MASK;
+        break;
+
+    case p2m_invalid:
+        e->pte &= ~PTE_VALID;
+        break;
+
+    case p2m_map_foreign_ro:
+        e->pte |= PTE_READABLE;
+        break;
+
+    default:
+        ASSERT_UNREACHABLE();
+        break;
+    }
+}
+
+static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table)
+{
+    pte_t e = (pte_t) { PTE_VALID };
+
+    switch ( t )
+    {
+    case p2m_mmio_direct_io:
+        e.pte |= PTE_PBMT_IO;
+        break;


      

      
Shouldn't this be limited to the !is_table case (just like you have it ...



      

        
+    default:
+        break;
+    }
+
+    pte_set_mfn(&e, mfn);
+
+    ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK) || mfn_eq(mfn, INVALID_MFN));
+
+    if ( !is_table )
+    {
+        p2m_set_permission(&e, t);


      

      
... here? Or else at least ASSERT(!is_table) up there? Personally I think
all of this !is_table stuff would best be done here.

    

    
Agree, that this should be done only for leaf PTEs.
I think that I will move that inside p2m_set_permissions() where 
p2m_mmio_direct_io case is handled.

Thanks.

~ Oleksii

  


--------------n2ywK1zf1NJItpgQ7GwXkx16--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 14:07:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 14:07:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132923.1471128 (Exim 4.92)
	(envelope-from )
	id 1v3EWu-0003QW-Up; Mon, 29 Sep 2025 14:07:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132923.1471128; Mon, 29 Sep 2025 14:07: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 1v3EWu-0003QP-Qu; Mon, 29 Sep 2025 14:07:04 +0000
Received: by outflank-mailman (input) for mailman id 1132923;
 Mon, 29 Sep 2025 14:07: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 1v3EWt-0003QJ-Dk
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 14:07:03 +0000
Received: from SA9PR02CU001.outbound.protection.outlook.com
 (mail-southcentralusazlp170130001.outbound.protection.outlook.com
 [2a01:111:f403:c10c::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90f338a1-9d3d-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 16:07:01 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by SA2PR03MB5836.namprd03.prod.outlook.com (2603:10b6:806:117::23) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Mon, 29 Sep
 2025 14:06:57 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 14:06: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: 90f338a1-9d3d-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=L5NQ3hovvNy4r7YEuBi1uhRpSzrrUBzKs/fGRuBNsv/x/uAGfyi2E68S7foDAgZttW9M1wll64rGheMx9XfAF/AFBgOTiqVELBYeRLS3CpprM4NCxdUlW/p471oB1XwuVZtXCSQk228jTSjogIPMMyc/D5UP2g4h7ipWk/zi2JM3xI8KMWW38+BxFG7E6DWXpmKtJTyp3INkHnyL/qanEbZ6TwPXUtkrlTUP7PghUrBID5nbtQigJjxWPyRSQazE8UkMFkDWuXI283FHyJVBWFKJGxOOGVLeFrtNTsYqkoLR4ZPSZWHgLZue72JBuEY0ZwyOWHJHdxhm+RdyEPlhAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Q1G4m2NgbWFk6y6iUxPeTGt/UefIoHwrKolFI+FVtUU=;
 b=WClPhGtOiSgUHn1+3i/ZG61notvZnmOMXtEWKqTuAbVii1keTwi1qFbfzBCdoHydyUILDeXWY98YZg+qCPQW9XMVb2xjYmCfJZiIyBiwOdKPj/jsvhuApP/vz4EyfoVGc1Z5322KbilCEdIJZ4bHaatZad3tI/q9bzPjFMI3BQzqvn1krtrifaxXEbMmZGIJrQGPK3wW746YEsxZYkbVJObFoMyuj1PixkyNDhYgdM1j+enP5TGr1F7MHChwM/Hn8EvY4q74EdlWO0KAX+ioF+w6Fyf7o9SO22eHU1qKA7taW5lw01mE5yQSwCbZ2AED/IdM0NlOUJ03CPaWl4ypQg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Q1G4m2NgbWFk6y6iUxPeTGt/UefIoHwrKolFI+FVtUU=;
 b=T+KSg8dny6sdzNPzSWincRUnzgLjo2xaAvFE20cicqvInPh114m8RFFHOS8S8a5B/vXLGBT/0V2dbhrealEZPzb+dDeGRgEbRUqGqd5SXsxRW8P2pVl9vuUETEci5KE6u7fXyY+J5oXZPcRNzlj6HaveYTcqM+KmCFjrV1fSQfs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Mon, 29 Sep 2025 16:06:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper 
Subject: Re: [PATCH] x86/hap: Inline "flush_vcpu" in "flush_tlb"
Message-ID: 
References: 
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
X-ClientProxiedBy: PA7P264CA0244.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:371::17) To DM6PR03MB5227.namprd03.prod.outlook.com
 (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|SA2PR03MB5836:EE_
X-MS-Office365-Filtering-Correlation-Id: 96100735-61d5-45d2-18b7-08ddff61730f
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?T0E2L2xGMWdZN1JLT0VIcXJSMzlUQnMrK1dPMnV4cjB1eUwxaEVwWlNXejFJ?=
 =?utf-8?B?bUhzWGM1UVp2MWxReldGTUVSQWQzOU1FTVlzRFQxU1BPTFVLZjZ2eDFXbnpl?=
 =?utf-8?B?cllUODl1YzJQZW5wSjE0Nkdjd00xTitwbSsyeHRKRzRCYVcvRVhobUdlcTZC?=
 =?utf-8?B?aG5XVWxxMllpVnJXRmkrSG1mclZCdmdFcnEwZFF3am1iQ0hGYk5NcC9ELy84?=
 =?utf-8?B?c1A4K2oxc1VGRHBYRk0vQW1hRnZGODN6NUdxMkliMDQxMTZLWFBlRXVrUVJT?=
 =?utf-8?B?dERYSERtWWduM1VYNGY3TC92QzdqSFgwajltUUhJUmkxTUhIWFp5QlFRZjEr?=
 =?utf-8?B?OEVYNjdPTnpybnNjMmFnS0lKTm4rWEo3Wis5WGhtSy9TdTFtOExsS0taQWlQ?=
 =?utf-8?B?N3Q4TkcwSEhKTjdOb0Z1UmdTMndhczRjMHd5UkxFUml6V0xYZjhRcUZzaGQx?=
 =?utf-8?B?bTM3bXdrMG5tcVhWMUp6a1JDckdwbzlLV3hYeStqcXQvRWpUNW84QmNFL3I5?=
 =?utf-8?B?QXdPd1BXZitXTmt3dWhaU3U5WlI2N0VtYzREbHlPUXpKMUpMNnFqZlREQm9H?=
 =?utf-8?B?aE02dzJXa0ZRMnlSSGJaOE9PREIrcjJIMDhzcXRYeUFMcWJjY1ovMlhTcWdI?=
 =?utf-8?B?WHNMSkxoU2k2czVTcXVxMFlSMGZpR3RCYmJzeStIZ1o4U0xxb0xCSGtGYVUw?=
 =?utf-8?B?Z2s0ejZYUzBpR1JLVzdEdjZieWVpRSs0ZXRXd3dWTzlaelJVV1NlMHBUZkhr?=
 =?utf-8?B?TU91dFA2YUNQN2FIVWVRYjZIK1VKS2ZCSmxaTFJZYkE4UVFtTFpVWW54bXdE?=
 =?utf-8?B?bWppcnFQazRRWkluWmExU2Z6ZVhLM1QxU0k3VGd5V1lhMWpOaHNCRU1pVXln?=
 =?utf-8?B?YjBVaU0xdGtWR0lvUVdhOVBJWk5vcFNEMVBocHRVK0xGZzlFWDhVb0REbDVz?=
 =?utf-8?B?TldLazhQZVVad3A0R01tYi9nMU9EdU9GZUZROTJuUmdPS012SUJZLzVzSmV5?=
 =?utf-8?B?WWcwK0dyc0xnYjJaTEJ6MnJOd0syRXlSb2tqM214WmFpVG5CcTJPQTJhMlNq?=
 =?utf-8?B?NW5peHowRWY3RUI3NCs0bzFFdzhFN3pSR1E5Ym0vQnBvQlB0ekM5b21ib2F4?=
 =?utf-8?B?ZXdnZnl2OE9ta00xS1lNQkZBWGV3ZHIzL3pzVGZDVFd3ZjRlWHpEQW9aV28x?=
 =?utf-8?B?bGVnRXFQcnhBam10c3pyVUJMakFIZUg5ZU1NWkhHSU8xb3pXZ1M0V0JLSkVB?=
 =?utf-8?B?bVA5UWI1RmxMc2YwNnovb054M2RXSm1tWXJTYmNNdG1rRmJGSTBndThRbEVV?=
 =?utf-8?B?empySDg1aTFDRlNvMWtYMjY2a3plN29SQXNiY2MrdzdhdjB3Qzhacm9oV1dV?=
 =?utf-8?B?ZnlKdVRCeTU3RllhanZyc29lVnVuQVBJTFQ3ZHhhMXFSYmxCOWJQbjFlZkV6?=
 =?utf-8?B?WDdXTEJ4eWQwbDlPeHBCYmJoNnhsb3FIOHdqeS9MWHdHSXdDMnM4cWwxWFNa?=
 =?utf-8?B?b0ZvQS94aGlwaHBZNjQ2MjdjbGFhNS8wT24ycFNUVHdoMUttSWN4cHZEMzdF?=
 =?utf-8?B?TEFlaTlDWmJwcFd5d1RzcW5MbFpWOElXQTVsV2ZJaWFjdFNKWTBtQWRLR2ZT?=
 =?utf-8?B?eUwzTVNFcWlWVkorR0NOMkl4QkZwZGZzTmJvOVJONEg0eU1ETTNvOGFtc2xZ?=
 =?utf-8?B?SHJxbjJiOFhTdzZBSlp2YU5GaVM2WWw1WlhKUnhEU2VtMUFWRnhuVmdkdzRB?=
 =?utf-8?B?S3lFNWgyNDAyZTMyNVJYS2VjamRMUGlBSFh2d1FlbTIyTEFCRjhEQVpVbG1t?=
 =?utf-8?B?UTN2NHhUajhsSVJVOWZqR20rUjRhNThiaE9ZVzhlUWhXdEd2LzRLQlZNWmtI?=
 =?utf-8?B?SjRXUWp3b0xyTmE5VzdxK1VGSVFNWWhWc3BIOFh3UmFKbURobEhjbUd0S0RK?=
 =?utf-8?Q?Aw63bYQNafAI+tEHlJEctFLhP0DT0BrH?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?K2RXeE8zMUdCYUZ1VnlPelZ6WkRuM0RuSlVRUU5WaFJ1TFd0ZlhncEoxaHll?=
 =?utf-8?B?LzBYZm12RFRndXhlSzlmYW12YnVrT0c2S0NOd0xRdkdpcnlnTXdRTWhhNCtt?=
 =?utf-8?B?Um1JWFNCeHROa25zcTlSRzNjZGg4Y3FjVkp1RTZUS0kxdjhuU1pCa29SZXo4?=
 =?utf-8?B?SUVudWx6aFFzSndkZm5aZFNvMEdWM1laN1B5dFdHZ1hQSnNpR3BBNTMvcTE0?=
 =?utf-8?B?eHg2aVNUZ20vZEVqc1RLMEkwbVBONktOQWhwSEhNbENUL2t3N2FBVHhSanNx?=
 =?utf-8?B?d1FGOG0zWUUxTDVOcDl0N04ycVl1Y1h2R2RrY3A0eDZIaWlRVFhTamcrSDN1?=
 =?utf-8?B?bTRuT1ZMRVdMUWxNY01SdVYwbkozTnJqMU00NWdXQ2RoQmMxb1Z0MTJxMFpN?=
 =?utf-8?B?Vml2c0FrdENEUTFtVmw2SXRwWTZqYi9BUlFRNCsrNldHWFJLVHNZUGloVWE4?=
 =?utf-8?B?cXhZdUEySHVYWUlQUFhRMnRMTjFqMHlhSEI0SkNrbyszd2ZWNUwvaXA3cENp?=
 =?utf-8?B?QlZma2JZblA4U1BXK0M5K1NEOEhlUmdYazRxTklKM25LNytJU1RnOTFlWk53?=
 =?utf-8?B?Y2VNVzd6b3piYzlYMmdtTEo3SGMrNTViSDB1amEwQldIQnE3eEZLc29Hekdv?=
 =?utf-8?B?bzNWdTIyTy8wRWQyUDEzM2dnZHNlTXVPK2hLeVZwbCt1Q0NUT0Q2ZGRENHBL?=
 =?utf-8?B?VDlnaHJ6V1lpU2dHWHdBbS9CZk9IaDFidkh3WEJuakFDRGF3cVNnZTZaR3NZ?=
 =?utf-8?B?Q3VSb3hBRmN2Z2kvNnZHTUx1d0lhWTBicXlVeVNmWG50QWcyNWI1MDl0eTRo?=
 =?utf-8?B?di9BQnN0QVpmamVrQU1Jb0FJR2Z1OXlSZGtKdjNSZUxMVXdlWkpuWS9WeU5z?=
 =?utf-8?B?UXRJVTJ5U2ZkOFFPUU5veldTSlhwb1BaeEhuc0hMQnZ1bDJYSlVaRDl4NzNw?=
 =?utf-8?B?ZjRmdW1raUs5bE1xV3RweTlBa1Q3TTkvMlN2NUZUVlZIODZSdnl1TGtXYzJU?=
 =?utf-8?B?WFl0MUNZbThJRi91WlVFTWU4dEFFbTlTbnJTVVlNUVYvMENrd2IySExPeFc3?=
 =?utf-8?B?SEhoZk5jdlpSTmhhVVZ3YVJZRnllamlseHBJYVZmRUJmcDEvcGJVUTd3Wk1a?=
 =?utf-8?B?RzZqTFVLWEJtS2dMMjFCQTJqSERGMGNGMjl5Wk9NaDNjNzBsNkhjME0yd01x?=
 =?utf-8?B?SlFmaXpQNU5haHBKYWM0R3RORFFkamw4aTZDNjdFcVl6VGJhb1c3Q0xIMlU0?=
 =?utf-8?B?Nlc5RW5vWTNZcmRHOHltcGI3QmdBdlBxUGplRGNHQzkza2FGanRTSE0zbnlz?=
 =?utf-8?B?NENpbWtmTDl6SjhHdGNhYXBFd3ZpV05aRVlramFzWWN4TWJtQTVzWUU3V2E3?=
 =?utf-8?B?N1Q0ZjBMK2ozVGFKNjVLVjlibnlXbnIzRklCcXBnNml4QWRTTGRJSWhmK3Va?=
 =?utf-8?B?YVhBSU8rNU9SRVNsQWJYSC9pZmxsdFpWQnZMeGxmbExoUUJBZk1wSG5vMzNy?=
 =?utf-8?B?WWRuQnVWeWNjNDQyVlpxZkYyVm9xOEF1OG5mRHpUeVFTZFBuM1NuSnV4OUdi?=
 =?utf-8?B?VXBOaWRJRmx1ejI2Mm5ocnVhZGJjM2dxSTUxWjZ5NG5aUUE0MUN4NWJ2WHhX?=
 =?utf-8?B?aU01Qld5MTRLRXI2c0hOYzNlajdxSDRqNmVhQTFkQjhNZDJPVkZvNEVvU25v?=
 =?utf-8?B?L3lKR0pNTDVPNWd1V0J4RnRibGR1aGthcjNjNUVoOCs0cEsyV1Brd0RZd2dp?=
 =?utf-8?B?WGZNblQzY1gyNUdITnJlSnpJYmh5RjhPTzMzSjVVSnczczlDZ05NMzRrRS9R?=
 =?utf-8?B?UmZQSVVDOTY2cmxkSjZla3ErdGxwbnBudXZoYjloRDJMUHlJWjVLZG1IUDc3?=
 =?utf-8?B?TjdyaFZ4ODZTVnkvSmhOSWRtdlNTRlRBTzZVRldac29EWFlNQTdLV0NaMktJ?=
 =?utf-8?B?SXpBS1FkLy9mWEVaT0hndDVseFNmRkw1VzIvNERoWmtlQ2dRZ3JSeVFGZXIv?=
 =?utf-8?B?N3JCUkVWRGUxeXN6U1AxdHZlWGtxdVRsQ0I5dEU4Nkl4bERmNWZYdVNVTjd4?=
 =?utf-8?B?eHUyUnIyNHhBUnQvU2owRk5GSmNuVkFtczhiVEo3ZVo4REJPZzVzWDU5d0x4?=
 =?utf-8?Q?lD1NODVnpoKhWQflzXWSBSDSk?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96100735-61d5-45d2-18b7-08ddff61730f
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2025 14:06:56.9596
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: H/iRwamMT7IPctydVOMGosR254Bdz9tz4C89XTva8wbyn4cJ4uUs9v8MJH4/lAYnQfLY20hFmetx72eYGl8Aug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5836

On Mon, Sep 29, 2025 at 12:36:30PM +0000, Teddy Astie wrote:
> flush_vcpu static function here is only used in one place which is just below
> where it is defined. Inline the function to reduce the noise and clarify
> what we are doing.

Did you check that the compiler doesn't inline it already?

It seems like an obvious optimization for the compiler to do.

> No functional change.
> 
> Signed-off-by: Teddy Astie 
> ---
>  xen/arch/x86/mm/hap/hap.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index 2f69ff9c7b..407c80afab 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -721,11 +721,6 @@ static pagetable_t cf_check hap_update_cr3(struct vcpu *v, bool noflush)
>      return pagetable_null();
>  }
>  
> -static bool flush_vcpu(const struct vcpu *v, const unsigned long *vcpu_bitmap)
> -{
> -    return !vcpu_bitmap || test_bit(v->vcpu_id, vcpu_bitmap);

The same construct is used in shadow code also, maybe it would be
helpful to place the flush_vcpu() helper in a common header as static
inline?

OTOH we don't care much for shadow, so it might be simpler to leave
shadow as-is and do the change just for HAP, but would be good to
mention in the commit message why shadow is not adjusted in the same
way.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 14:24:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 14:24:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132934.1471138 (Exim 4.92)
	(envelope-from )
	id 1v3EnK-00065J-8u; Mon, 29 Sep 2025 14:24:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132934.1471138; Mon, 29 Sep 2025 14:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3EnK-00065C-5k; Mon, 29 Sep 2025 14:24:02 +0000
Received: by outflank-mailman (input) for mailman id 1132934;
 Mon, 29 Sep 2025 14:24:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3EnJ-000656-2b
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 14:24:01 +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 ef9ad754-9d3f-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 16:23:57 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-634cdb5ed4bso5116940a12.2
 for ; Mon, 29 Sep 2025 07:23:57 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3af53basm8153889a12.41.2025.09.29.07.23.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 07:23: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: ef9ad754-9d3f-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759155837; x=1759760637; 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=U04Z7yzzaE6hIKAJsqBSoKWQhf5uESKV5oZ4D+OVpmY=;
        b=NypgUortlsXONT1N5R2Iytb4Q7LZdqPrPho94pF6+7SV9hivFAoNuwgORXCAiuRYWN
         /xjqqLSXA5pdxW2HZoFeUBK48qY9K3qTKPquloKgnJP+W0MfFWqSXDFIsU7TKaT1zmHs
         Xmz6iaTY8Ay9YrALO2uyT+jaLvxDFR4V/TWrttYsMyMMtkroNT2gGVbQchxcaVkWoMbn
         5UuE6b6ZRQtyAJjfcr9/lHaA7LEULA2JiLwlFVyVmUeITB+pKrgPT8PC9WiYlX/evoN5
         0hTQCUZuW7kEyE+kyZcMoC1ZR/D0ha78g5GxOXjqvznJfBbZMRpkO2lnsaNuSIQwu7LQ
         o74w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759155837; x=1759760637;
        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=U04Z7yzzaE6hIKAJsqBSoKWQhf5uESKV5oZ4D+OVpmY=;
        b=RpVw+vXwD+Z1xtObNvixEEzQzuAN6suD70GzkwiAT3CJ3CZNk4zKSGkaIhAICOLoqU
         z80Eb4mXQJU4/wxJY5AfHoGTn7IHqPGvCCYFtmDLH6p06G7fzsNJDNYiDJVRmtXof2c+
         yh3Q0KDOD1d1z0j0p3vTfMB/fDXroWOjNYAEtBZE0b7Yjcsj9xJgYsN6rn9AO8v11w+z
         qsQcM1n8u8KzMlgX4teyvKIPSTL/vFDuaaDZjcn4B1cmIwKAhy4eVps2SiyWzAMqFz2f
         9+oVOHQ4NsdpSZeS8B5VFcT3BZVVq5VgLyRrMfF2OAFZXPvoTOaf30rqbxYB23E804to
         xrXQ==
X-Forwarded-Encrypted: i=1; AJvYcCU+vNtoNCbimU7dDjD+lKyRIQc2qnfLi+m23d3PsffzIjNFjdoNiQ+EW8qWPz7QqGB6IQbdcK5s6Mg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzkhns5TEPFN22566oeFP/8418SNqft8VSaNnAwBCtJhF+ywkWa
	Sdn1OmpWzikEWyuoe746dagPRASiITVwthJQop7e/GRoK8BRAX+ml0IT
X-Gm-Gg: ASbGncu3Z5qy0lovXFOn0o9YUYfbTPRFfJgY0/OxawOS2sSlAQRo7xy2RzfdfEMJjRF
	yOI3C+pZpSk0FpYGbN1cVaiuEo6cuvpmIaBPFQiBNr4mbdv4vjGMKMF3oSyP+bRU/rL/MUHhwvW
	uIXm9ky8WV+LZ1HXItSJOZ5znrivlcoG0fSpNLoEExrpXvZx10D5oIB7GxSTd0xVTz1VMI6RInf
	dPdqjzGp0Xo0tI5qfajHXYOTy48YzR2lfQpMnKY2EtY3kbb2qaCyLf+yLwPuxMe/FI1bXxXiANv
	kUyNz5WffEkLOyyBxM/JhHlfdLY1VeQU//2WSo/NeeEKZihEW+C2iO/DPuHuurTrHFbF2JjE6P5
	b5haR8/u3OfBr0IGNswC8O4d3Z43q4OkGzKHR9nQ62HFiLozh9ed4V/p4Aml9myJrU8x5mOFLzl
	uRQJ3OJis=
X-Google-Smtp-Source: AGHT+IGrCzC4MIiHGk4+i5jfy2zEh41CwxYsegV9UEKySlDJ1A776Ip8nj4jZYBFbqrip13b5jydrg==
X-Received: by 2002:a17:907:9815:b0:b30:ea06:af29 with SMTP id a640c23a62f3a-b34b7fbb555mr2030666566b.16.1759155836945;
        Mon, 29 Sep 2025 07:23:56 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------8H0VGdflyirX1eYzMJ7CUBH0"
Message-ID: <98699f1b-0cc5-4e73-9d2e-865f2e3d0b0f@gmail.com>
Date: Mon, 29 Sep 2025 16:23:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 13/18] xen/riscv: implement p2m_next_level()
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: 
 <30a203de44b04a06613aa1f873a072a4594c5bb4.1758145428.git.oleksii.kurochko@gmail.com>
 <0cf7a47f-f852-479a-bfb2-2f723f66c72e@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0cf7a47f-f852-479a-bfb2-2f723f66c72e@suse.com>

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


On 9/22/25 7:35 PM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> 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:
>> - 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 V4:
>>   - make `page` argument of page_to_p2m_table pointer-to-const.
>>   - Move p2m_next_level()'s local variable `ret` to the more narrow space where
>>     it is really used.
>>   - Drop stale ASSERT() in p2m_next_level().
>>   - Stray blank after * in declaration of paging_alloc_page().
> When you deal with comments like this, can you please make sure you
> apply them to at least a patch as a whole, if not the entire series?
> I notice ...
>
>> --- a/xen/arch/riscv/include/asm/paging.h
>> +++ b/xen/arch/riscv/include/asm/paging.h
>> @@ -15,4 +15,6 @@ int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages);
>>   
>>   void paging_free_page(struct domain *d, struct page_info *pg);
>>   
>> +struct page_info * paging_alloc_page(struct domain *d);
> ... there's still a stray blank here. With this dropped:
> Acked-by: Jan Beulich

Thanks.

> I have one other question, though:
>
>> +/*
>> + * Allocate a new page table page with an extra metadata 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;
>> +
>> +    ASSERT(!pte_is_valid(*entry));
> Isn't this going to get in the way of splitting superpages? The caller
> will need to initialize *entry just for this assertion to not trigger.

The superpage splitting function doesn’t use|p2m_create_table()|. It calls
|p2m_alloc_table()|, then fills the table, and finally updates the entry
using|p2m_write_pte()|. So this shouldn’t be an issue.

Ohh, I just noticed, the comment should be updated, since an extra metadata
page is no longer allocated here.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/22/25 7:35 PM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
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:
- 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 <oleksii.kurochko@gmail.com>
---
Changes in V4:
 - make `page` argument of page_to_p2m_table pointer-to-const.
 - Move p2m_next_level()'s local variable `ret` to the more narrow space where
   it is really used.
 - Drop stale ASSERT() in p2m_next_level().
 - Stray blank after * in declaration of paging_alloc_page().


      

      
When you deal with comments like this, can you please make sure you
apply them to at least a patch as a whole, if not the entire series?
I notice ...



      

        
--- a/xen/arch/riscv/include/asm/paging.h
+++ b/xen/arch/riscv/include/asm/paging.h
@@ -15,4 +15,6 @@ int paging_ret_pages_to_freelist(struct domain *d, unsigned int nr_pages);
 
 void paging_free_page(struct domain *d, struct page_info *pg);
 
+struct page_info * paging_alloc_page(struct domain *d);


      

      
... there's still a stray blank here. With this dropped:
Acked-by: Jan Beulich <jbeulich@suse.com>

    

    
Thanks.


    

      
I have one other question, though:



      

        
+/*
+ * Allocate a new page table page with an extra metadata 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;
+
+    ASSERT(!pte_is_valid(*entry));


      

      
Isn't this going to get in the way of splitting superpages? The caller
will need to initialize *entry just for this assertion to not trigger.

    

    
The superpage splitting function doesn’t use p2m_create_table(). It calls
p2m_alloc_table(), then fills the table, and finally updates the entry
using p2m_write_pte(). So this shouldn’t be an issue.

    
Ohh, I just noticed, the comment should be updated, since an extra metadata
page is no longer allocated here.

    
~ Oleksii

  


--------------8H0VGdflyirX1eYzMJ7CUBH0--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 15:22:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 15:22:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132949.1471152 (Exim 4.92)
	(envelope-from )
	id 1v3FhX-0004tB-AN; Mon, 29 Sep 2025 15:22:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132949.1471152; Mon, 29 Sep 2025 15: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 1v3FhX-0004t4-6e; Mon, 29 Sep 2025 15:22:07 +0000
Received: by outflank-mailman (input) for mailman id 1132949;
 Mon, 29 Sep 2025 15: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 1v3FhV-0004sx-Hm
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 15:22:05 +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 0d31830f-9d48-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 17:22:03 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-636255b92c9so3793803a12.3
 for ; Mon, 29 Sep 2025 08:22:03 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634c065a67csm5924635a12.36.2025.09.29.08.22.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 08:22: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: 0d31830f-9d48-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759159323; x=1759764123; 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=eIsCU3Cm50J/BipKlMDBnLRM+CdqhNVX1Oigv3bXu20=;
        b=krLF6ZtmydvVDnXGQy1xSef3MSyFXOTb/xRuxHd7kXjvdQyWjVkHWG74cOAt+FzE3Y
         r2NQvt/QPyLXJ7IOWXvG1hYpSVo2nBfeUNKc4R4rv2wteVnqzer0+nBBPPG+bTO/CEk4
         Mb8j4X50gx4ufQ2vzWu5t12jxEMnj5CId6wSKVUJpnzC/Pgz58/3y8kr5nIaMFpDOIjX
         25XLqP9tftn2c+wcnKLFe3wBkyhpRvWmYGvVFlcmWRPwJ8fVlApJWYwpRnCI8vU2TWmb
         0JfGDXtiDIlVKFHnDpMZXRgKu16n/wPvGj+vPMf2byrfubpDjN5WclasfGufu8ShrWKQ
         cq5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759159323; x=1759764123;
        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=eIsCU3Cm50J/BipKlMDBnLRM+CdqhNVX1Oigv3bXu20=;
        b=XHE4l9z23mP5uLGPZ2SCuPAi+xlEJHBc9y9T0nEsdjWmpG2rDe8jH1Y/VMx0SqXKad
         H69aKD5qYQk7E3Ph0WTygu0gdCVl641LXe9cQy2an5pKDbRtqQCdMHD1xSrswGeYRwHt
         bsyGcn+0c7s0lZW74Ddh/2ieD8iEq9144MV+yoGiibeq/lKnBuMsE6+e7a/gYcWb/rmO
         fFET4ED0EgHGTd3L/jJnH8tPycPtmi8XCW4PtqmSJ06eZRGzxslP8y7V2GuQC8BDCkCQ
         jihAt+b+7FX5s/R4R+at0mxIVtrtYXazvzYAwMJXs8UcnSegdbZ7mxf/Xp1pJYjrMbEG
         4nbQ==
X-Forwarded-Encrypted: i=1; AJvYcCX7JWj9Gr3z4cwJpf2ufj60mWEReAY0gZ63BqBDyUq2RIfJUOEa0YcrKf/npquBo/L7rsorZBdCNAU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzt56O1j3xUAbwQ7LGb0/nqxYI/LE4XEeCTQ7y0NhnVRno8/wpd
	IovHwX7kYePjTdUJjmjFV+392kmhT+a7DfI/W3E43rYD0fnOdcY118Ce
X-Gm-Gg: ASbGnct1SGs+uq/Hga+DTGjOVPOwpel8smiEc4eA82wS7HA9Uxsz0d9Zjt3XkLINW/6
	mUDxuvqXoF1OsgjVHSHnkWaMUYmh5ggdUfEDvQssOLnZNQds8pmluzJnsTxz5DOTaR9zGPcnqT0
	DviLPu9ww92K4HXu54qY21avz30wvDjSZkkZGGVmYtNwnGMJ/Qg5pPK1F7qPTHI5dm3ml+30Sq7
	zzi5rlkvz193gtxPlP29GCOp9QNIowqa/p/qSZtiD2jKKL6AMALmjwTSQzVKv+0+EMtajWJsGX3
	u9WaudnzK36zIW8iKsT3bla/B/iuDIq90saa77Ga372+x8gOe/leuFCJN4UApqHSPgdqX0O2z66
	LWPHV/a3rIi3BmOs7n2aup66aUB64vLM5Ey5oYb0Q4VmxCCOQYI5Ui35hS4bDFogQ/PTcZjbCJj
	oKTbAoiH8=
X-Google-Smtp-Source: AGHT+IG6YEHTN6QJe/iDwYSk7kWQfckza2LegIdjqlIack5JWjG1gk8kWPIN+xHjB2SgyXy2bpZn3g==
X-Received: by 2002:a05:6402:3491:b0:636:2ea0:df62 with SMTP id 4fb4d7f45d1cf-6362ea0e02emr5682885a12.38.1759159322594;
        Mon, 29 Sep 2025 08:22:02 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------ekHcZDyIaLFogqAXAdNV8IOr"
Message-ID: 
Date: Mon, 29 Sep 2025 17:22:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/3] xenconsole: Add connection flag
To: Anthony PERARD , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 
Cc: Jason Andryuk , xen-devel@lists.xenproject.org,
 Alejandro Vallejo ,
 Anthony PERARD 
References: <20250822213946.245307-1-jason.andryuk@amd.com>
  
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/29/25 3:21 PM, Anthony PERARD wrote:
> On Tue, Sep 09, 2025 at 12:18:26PM +0200, Jürgen Groß wrote:
>> On 22.08.25 23:39, Jason Andryuk wrote:
>>> Add a connection flag to the console interface page so a domain can tell
>>> if it is connected or not.  This became a series in v2 to add flag
>>> setting to libxenguest.
>>>
>>> Jason Andryuk (3):
>>>     xenconsole: Add connection flag
>>>     libs/guest: Set console page to disconnected
>>>     libs/guest: Set console as disconnected on resume
>>>
>>>    tools/console/daemon/io.c                |  4 +++
>>>    tools/include/xenguest.h                 |  4 +++
>>>    tools/libs/guest/xg_dom_arm.c            |  2 +-
>>>    tools/libs/guest/xg_dom_boot.c           | 36 ++++++++++++++++++++++++
>>>    tools/libs/guest/xg_dom_x86.c            |  6 ++--
>>>    tools/libs/guest/xg_sr_restore_x86_hvm.c |  2 +-
>>>    tools/libs/guest/xg_sr_restore_x86_pv.c  |  1 +
>>>    xen/include/public/io/console.h          | 13 +++++++++
>>>    8 files changed, 63 insertions(+), 5 deletions(-)
>>>
>> For the series:
>>
>> Reviewed-by: Juergen Gross
> For the series:
> Acked-by: Anthony PERARD
>
> Hi Oleksii,
> I think this series needs your "release-ack" tag.\

It is a little bit too late. But considering that this patch should increase
boot performance (right?) and it is pretty straightforward, I think (IIUC regarding
boot performance) we can consider these patch series to be in 4.21:
  Release-Acked-By: Oleksii Kurochko

~ Oleksii

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



  
    
  
  
    


    

    
On 9/29/25 3:21 PM, Anthony PERARD
      wrote:

    

    

      
On Tue, Sep 09, 2025 at 12:18:26PM +0200, Jürgen Groß wrote:


      

        
On 22.08.25 23:39, Jason Andryuk wrote:


        

          
Add a connection flag to the console interface page so a domain can tell
if it is connected or not.  This became a series in v2 to add flag
setting to libxenguest.

Jason Andryuk (3):
   xenconsole: Add connection flag
   libs/guest: Set console page to disconnected
   libs/guest: Set console as disconnected on resume

  tools/console/daemon/io.c                |  4 +++
  tools/include/xenguest.h                 |  4 +++
  tools/libs/guest/xg_dom_arm.c            |  2 +-
  tools/libs/guest/xg_dom_boot.c           | 36 ++++++++++++++++++++++++
  tools/libs/guest/xg_dom_x86.c            |  6 ++--
  tools/libs/guest/xg_sr_restore_x86_hvm.c |  2 +-
  tools/libs/guest/xg_sr_restore_x86_pv.c  |  1 +
  xen/include/public/io/console.h          | 13 +++++++++
  8 files changed, 63 insertions(+), 5 deletions(-)



        

        
For the series:

Reviewed-by: Juergen Gross <jgross@suse.com>


      

      
For the series:
Acked-by: Anthony PERARD <anthony.perard@vates.tech>

Hi Oleksii,
I think this series needs your "release-ack" tag.\

    

    
It is a little bit too late. But considering that this patch should increase
boot performance (right?) and it is pretty straightforward, I think (IIUC regarding
boot performance) we can consider these patch series to be in 4.21:
 Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii

  


--------------ekHcZDyIaLFogqAXAdNV8IOr--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 15:25:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 15:25:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132964.1471162 (Exim 4.92)
	(envelope-from )
	id 1v3Fl2-0005VR-Sp; Mon, 29 Sep 2025 15:25:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132964.1471162; Mon, 29 Sep 2025 15:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Fl2-0005VJ-Q3; Mon, 29 Sep 2025 15:25:44 +0000
Received: by outflank-mailman (input) for mailman id 1132964;
 Mon, 29 Sep 2025 15:25:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3Fl1-0005V7-Vb
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 15:25:44 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8d5a4b35-9d48-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 17:25:39 +0200 (CEST)
Received: from orviesa006.jf.intel.com ([10.64.159.146])
 by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 29 Sep 2025 08:25:37 -0700
Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24])
 by orviesa006.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 29 Sep 2025 08:25:37 -0700
Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) by
 ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.27; Mon, 29 Sep 2025 08:25:36 -0700
Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by
 ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.27 via Frontend Transport; Mon, 29 Sep 2025 08:25:36 -0700
Received: from SN4PR2101CU001.outbound.protection.outlook.com (40.93.195.55)
 by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.27; Mon, 29 Sep 2025 08:25:36 -0700
Received: from CY5PR11MB6139.namprd11.prod.outlook.com (2603:10b6:930:29::17)
 by CH3PR11MB7868.namprd11.prod.outlook.com (2603:10b6:610:12e::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Mon, 29 Sep
 2025 15:25:30 +0000
Received: from CY5PR11MB6139.namprd11.prod.outlook.com
 ([fe80::7141:316f:77a0:9c44]) by CY5PR11MB6139.namprd11.prod.outlook.com
 ([fe80::7141:316f:77a0:9c44%6]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 15:25: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: 8d5a4b35-9d48-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1759159540; x=1790695540;
  h=date:from:to:cc:subject:message-id:references:
   content-transfer-encoding:in-reply-to:mime-version;
  bh=0yMBbTdrbZsoKnHaFswecQWWVrw035NB0ey/rqgunGY=;
  b=JWeMT4mXDY9/lE8ttQk/KOeZDGZgKHomuplxGjXonimr1fI0ddLmHACo
   y1ATwlDYHTJhnxO1K/VFuf5R3XYGj7crzVJqZZsJ1pWBcJXcADiMoV8Gy
   GyF6oe5BlXaL4VXkYo1P4jw1uwZ6A5N/YTqzQFvPMz/Twrn7GMp3hLJW+
   8dorKeS4YP6dJ08bGDN9izSGOLaXNzYI3ZI0DkAJT8KbG+aqM8ixoV3cq
   n4Kn5oUL1gJmb0wvwE9dzXej16c9fjxhVIqec/8j4cOv0PoBcKUGcu5qO
   sPsV02oqsBj5z42FdUI+/mLCeiLaupJ85bFiXIjmKhNhrghs0JuHInu1S
   A==;
X-CSE-ConnectionGUID: 0ucQ4DsqQma3qUdgjMhfAw==
X-CSE-MsgGUID: klHWdng4QPWocpGTvR8Fuw==
X-IronPort-AV: E=McAfee;i="6800,10657,11568"; a="60615332"
X-IronPort-AV: E=Sophos;i="6.18,301,1751266800"; 
   d="scan'208";a="60615332"
X-CSE-ConnectionGUID: vS2lVLIiSOaesnaX4OriqQ==
X-CSE-MsgGUID: uoeqhmQtRhiBoZ3bnTr8Kg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,301,1751266800"; 
   d="scan'208";a="177387425"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IAwpEE3TeyxfuQRigo3ZFdiwxt3TKU8egDzAdn/7KexEXXMPlkI0iHLcoIHdjPYDxlTTltodtWlkePpAD5nHhITvBtRWdJ9fl7gTa8ver572g9K+Z60GTVfDV3Lcz/dDfrIfE/eASzwb31JYNDIIU5aq7bbxsbspRIZ4GoWfc086A9pOA3IEYCSA20lIsCmuLjngURZFMP3MQo9aRTJxkr4ntyDNqOquYeKWlSp2t2DM/+VZvi2xur1XgM50PjxMNKiK65iwvJM4dwrrPckjSOFyG06v4eaNzq2Ou8SOZe6g0fTBUZp0N6OWX6gAQKxwUBFxfDQBm/TIfTdrQYNU6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=p0lyNX3BUmvGp66jtnY0mXVEFk176o4Cm6HjnAa0dFc=;
 b=Z5LhSpWQae9MRZPSfIY2nZ4Xr4C58nQ+SWYgMWJMlswkLSFVK6RcuQP2X7++EEnGyHSMgpvi6Bnb9aW+3f7s4Tw4NK+gIHLdtiysg9nG6Y79zdKA/RzXu2Nj5najeblC5z/AmbHs1/oyM7hAO7vz1LAyQdI2YYGYPKRo8ac4DVrAlijbS0hTAtygyBy/8oCRPkbD5Oh5kUsdSmSgUp4AQEkKrYT5yTBUHtEFbxIp1IauYZsSs88NjBV7sm9x42uPvDl6gNBbhkE1xwJwflJFVhjQ55HicAm/MtDi32gW+lF2mbBsbp6jfL1oFOKojflhWHhmNoz3+CrelPEXhcH+hw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
Date: Mon, 29 Sep 2025 10:25:26 -0500
From: Lucas De Marchi 
To: Thomas Zimmermann 
CC: , , ,
	, ,
	, ,
	, ,
	, ,
	, ,
	, ,
	, ,
	, ,
	, Matthew Auld ,
	Thomas =?utf-8?Q?Hellstr=C3=B6m?= ,
	"Rodrigo Vivi" 
Subject: Re: [PATCH v6 23/25] drm/xe: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: 
References: <20250821081918.79786-1-tzimmermann@suse.de>
 <20250821081918.79786-24-tzimmermann@suse.de>
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250821081918.79786-24-tzimmermann@suse.de>
X-ClientProxiedBy: SJ0PR03CA0356.namprd03.prod.outlook.com
 (2603:10b6:a03:39c::31) To CY5PR11MB6139.namprd11.prod.outlook.com
 (2603:10b6:930:29::17)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY5PR11MB6139:EE_|CH3PR11MB7868:EE_
X-MS-Office365-Filtering-Correlation-Id: 9a7ce1ba-c1b5-42d1-e603-08ddff6c6cdd
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: =?iso-8859-1?Q?JgDW+n75dUbON4IcrAM9gXBZeut+NEYdDAKyzZMSOy/a+UAuYmOb+aKsvU?=
 =?iso-8859-1?Q?tCxTC3tEevtR3QvGENanInjPLdTlWNlZcnks8+8Qp5gWnFCg1aY/14KpP1?=
 =?iso-8859-1?Q?4qi4d3SdqCXhs2SuIQ5kUf8ocjlXBi3gGUL3N6VtHgZ3QYyHHHmErPXO9f?=
 =?iso-8859-1?Q?gnwyFOh1aZZHuIVZ+jdZvWrAbQoa4X/M9Gx0268kC2MU+4SGTh6fNmstTq?=
 =?iso-8859-1?Q?yuIZugOJky1ADC4PCtssiCS6JwPmw55y6iVWduEskvnd9iqrTsu1yP0t1t?=
 =?iso-8859-1?Q?Ta4WQOWP6vcEv9zsP1a4fQe3Pu6eXuqkSyAo2Sc5nrUn/+TLN8ZCep9kL6?=
 =?iso-8859-1?Q?Q+9Br37abcU7w1/FWFihWz9YZH+HV6y/3XiCh4RGIiYa/XnhQZ/YhScxv2?=
 =?iso-8859-1?Q?5OvuNee3VvQajgQIrlDgY/yQLkGQNrK3uuXLghItw9ByUbiDwyXJuy/ykW?=
 =?iso-8859-1?Q?8TgF9r/OM17ur2r3p+knOkgFxpnV+/XndLk+9xdpOsNz9s+N0gsdCcNoSK?=
 =?iso-8859-1?Q?saksMVF0xvZYRUnGkkPMOSMo3tRhH6+SI2vhqcxS6hcfu0NEB4vMGuZmYf?=
 =?iso-8859-1?Q?z/TbXTR6VOMLmEmK3mllz5S2EHuY7mOZ7ex4f6VYQfBUWLD5h5LbjkVGZT?=
 =?iso-8859-1?Q?oA/a8HFZaVBgyhhsXAdyEMBm39S70+Cqaepit0axuvwgFeIdE1XkBrcz5a?=
 =?iso-8859-1?Q?RflIi0Ebji0+KsOSssR2H24pqCzwhW5eHXNEZwbPLGll2hpmzOGXoHF3Bz?=
 =?iso-8859-1?Q?Lc79hnyc9etauCvWTuwUoozkWAO44Iwe4+shAQgUNpCCGi7CV+coxseyUo?=
 =?iso-8859-1?Q?ywymFa0LuOTuFCn4goljNp4eMb/zKZnPmrrcu0OvktrQ5qosuafP+K2vmv?=
 =?iso-8859-1?Q?8iPf2rIricA/DwxlAShRF3F/2Fy6jMTWNnh6APdQUe1CJTMsgOhiRcd05e?=
 =?iso-8859-1?Q?YW8bF010UdNqsFwUUKnls+91hJ1i6llKjYn1VH3289GExOOE0gLUW+Xn2L?=
 =?iso-8859-1?Q?ZvT1FDXgQFj5EHUdxItCwyxt5yQA3fMcsaE5KRCnTM4N2j08tfaQo/oLXj?=
 =?iso-8859-1?Q?iKjGRZOOTwL9ZDDHVx8AtciEN5dNNotEUKZgMgB6UKtV7qql8ekeDpV18P?=
 =?iso-8859-1?Q?YXSXhQ5S0XP6e79FHqi+Pmw5pozxkkiomhzHrWcDz/qzEoLKtjyTgYSef8?=
 =?iso-8859-1?Q?S3a1oln1tvHgGho0n0pt1hPT0Lgi+/MCITrpuxS8e9Tozz429RqX6HdTGu?=
 =?iso-8859-1?Q?3zHqfcltAvbghVkwYdlHahSiy8WLYK8OTFwek9I9L+azzGQCSLClQqA5z2?=
 =?iso-8859-1?Q?apDFYN5gHs1R8/gZ4tBt2PrLkECT9zChKzIUcbH2adPfX+8usn45OXLA0e?=
 =?iso-8859-1?Q?WAPi8Ou/7jcUgs6Z3PwR+G/RNscLdUey7h8yOCZJTxdjlVml4iiGxZNxSm?=
 =?iso-8859-1?Q?4vuXK9k/zSmZVsXCJz7YXxG+tP4jZjELxTtG8yyHqeBJD0rs+JcQXGh+I0?=
 =?iso-8859-1?Q?rNuG3CeJO2uNuFBAoulLs8?=
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CY5PR11MB6139.namprd11.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: =?iso-8859-1?Q?tf+wSmX7h/PnweaMVgGBvU1wGT0ZB0STuf3BwXg60UfCA3drqBKZRzfS2o?=
 =?iso-8859-1?Q?/ZqyAt8WbVigpR4VfkcYUTV5JH4wmQjVB92GX9SXWnOdvX0yHShHvseWqJ?=
 =?iso-8859-1?Q?eZDiBjN3EnQvVHFuN1lmQZik9qaurcI4cnAmHN7UwET+zC1dYN+2HXw+kN?=
 =?iso-8859-1?Q?jXEQvFnrMgmwyy6xi3lPZ73k1wjUlfMbbCvgoIgfVr/W564ntjQwwWRe9v?=
 =?iso-8859-1?Q?9SfZrG/d253ATx7IpyWYhGRg3uTb+TwBEOFSzEl22OMYITk22ctzjVh+Bm?=
 =?iso-8859-1?Q?ZmtihVqNuZh03gk/k1fqMKCKLbfRrwmbQssAGaXI/ZHufVCNwn+7lmwk0T?=
 =?iso-8859-1?Q?CP9lUSbsgHw1tCLza/3qCGF8b2092Bzlgq+sD3uVfRD9hKAEMSaSW6Fbab?=
 =?iso-8859-1?Q?YZIg6TKncLqE1bwahGeLIKcPJsCoiE5Yg50PikcKh9YkTyPx7mpKz/vJ8H?=
 =?iso-8859-1?Q?oNyK3OObWUrdYNC071IO56fr62hyDlSIaiTjtLTmi5uKhRU8ljuyJ7PL+p?=
 =?iso-8859-1?Q?2RkLhJkCEOtWDU2RdJX6UgjUAsGzAsr2bYznvl/M0gDuGEItNvlZISCO9m?=
 =?iso-8859-1?Q?g5C2rMxSORI3gzgrwgFS9EzItU3VCJcqlr9hDrmJuxoAbk1nSAOvF6fluf?=
 =?iso-8859-1?Q?LAqrEqRdh2HXRC5fTtwfdCmfydp/hO0Yre55Vbww4HojqLu+EHq2WYmUd7?=
 =?iso-8859-1?Q?Qp9c3CoItHfMRMNTfx4O7qO0yi9wimzMAg+R+BmUzmcMQH3Q6MkTr1ayY8?=
 =?iso-8859-1?Q?F8baLI3Zgsj09YIuLO7JCFoxBR9ERxUYi81gE86u2y/jICQeUZbzTwQMGt?=
 =?iso-8859-1?Q?IakF75T0fSagXPQhtVPJwKb+xUlTGNcGGWvGqRgzUTkG/9wIRT5v4QVc98?=
 =?iso-8859-1?Q?SqGxkfewdurHzRIATCiyDv8BlEBusHKEdpX+gY24BZslMJ1YVDWeMkzPDS?=
 =?iso-8859-1?Q?rxBLSQIQ8j3eGiTGDVbqjOzFg8Q1x5cdpIIGYkoo5uUmx5onN623haWiGU?=
 =?iso-8859-1?Q?fSaSkyGTNbRaTHpSj+N+RhvNy4EV1KPhvvwpLVInZekMy4qTpf5ubCmtoj?=
 =?iso-8859-1?Q?5pwOeO5g7k1MAPL/a2rgceK8LoBbN8h7f3NExpmKEjbKu1FiG8uEQ+BMrq?=
 =?iso-8859-1?Q?QiqC8BZNY/+sowidrZ6lROpaxzecQ/h2vkSTDbFWqxZFfmn/zBNgevm6r9?=
 =?iso-8859-1?Q?gDnSYU8NChMM3/5O8rCs4XjqNgoZ9KIXeEs9SyPnjHPVP7yxOsySAO+dU8?=
 =?iso-8859-1?Q?S5qZsL+o3i71xBVpWiILJ0WVOLHghYmdKrvx6MsFWa7yBHyTPrTHh341cw?=
 =?iso-8859-1?Q?M7qCAORFBYr7Af5aAE0uKr9GGokIm9AYeZzpPKwX43CvrDLJEGIns1TzRU?=
 =?iso-8859-1?Q?+Qz5LXGuRr5O9V09fGEAIZZtS7YH0Qi6eWccHvSIeCEtCIqcov7bkMzq8H?=
 =?iso-8859-1?Q?KddXqiHCb+6Rf7yZqvmWQ11P44fhmrrtnnlZiW40JoFSLA2Qh9pFy9cyUq?=
 =?iso-8859-1?Q?z9B1ojp3dThQaNxhHdzpG7gbcdQT1tPzpH+C7Gkc3UHxQBo0zuTEyIWFpi?=
 =?iso-8859-1?Q?39Xm8PFGxEcvySM/nnU4Y3W2CrbOeb0yURH1IAPAZKBi41k9iv+GSveqDc?=
 =?iso-8859-1?Q?jEs7O4tDnTQqR/7eh3t+Ml3LB7BiINHuWC4QScIjbJNUeNzjTVfwJ1cg?=
 =?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a7ce1ba-c1b5-42d1-e603-08ddff6c6cdd
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6139.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2025 15:25:30.8021
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eZARfbdpVMrNRufPMp0vxzwZrI+oykbORRY+0kxlNZv8Erp/UhQ4BBo4LgIufw57mOjduLFIUfwUc6K6PQD0eQggml19NKcmIrHLZQXWOZg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7868
X-OriginatorOrg: intel.com

On Thu, Aug 21, 2025 at 10:17:30AM +0200, 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. 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 Hellstrm" 
>Cc: Rodrigo Vivi 

Acked-by: Lucas De Marchi 

to merge this via drm-misc.

thanks
Lucas De Marchi

>---
> 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 6fea39842e1e..2be7a618165a 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 
>@@ -3130,14 +3131,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.50.1
>


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 15:35:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 15:35:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132978.1471175 (Exim 4.92)
	(envelope-from )
	id 1v3Fu6-0007B3-Pu; Mon, 29 Sep 2025 15:35:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132978.1471175; Mon, 29 Sep 2025 15: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 1v3Fu6-0007Aw-NM; Mon, 29 Sep 2025 15:35:06 +0000
Received: by outflank-mailman (input) for mailman id 1132978;
 Mon, 29 Sep 2025 15:35: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 1v3Fu6-0007Aq-1s
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 15:35:06 +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 de437e75-9d49-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 17:35:03 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-62fb48315ddso8715055a12.2
 for ; Mon, 29 Sep 2025 08:35:03 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3545a98d7fsm946635966b.100.2025.09.29.08.35.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 08:35: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: de437e75-9d49-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759160103; x=1759764903; 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=St7MtK7lqhceGoxH8AAxicUHeyaRpXl1YBow1O0Mb/U=;
        b=kK4ARTDvdj6EBBm9Qx2fQQwaDRqyJL4cAqzr25YnycZf/rwTOSik8o0hKgoJgPdzmg
         Ef0OxvJLq/DZOAJU2s8t9B2ET7+JXA8gvpkDSDzgX3g1tRGcczCJgKz11dZEbzLpIjIX
         Fdrm5SpJbwpdd8tixoJ1Q+tzDHvdp9jETOklKUDn2znC0pi6LPWhtcMa/zMyl2ueHXh6
         24aq1HHibaZZOk5d5i/jkKe1RqZPnxzwUOhrKqj/EK8HJWnDaSxSCO7clGXWxfDLC6+W
         MuxLLweNoxb/+d8UuUS6L0ZgwQS1qJDhFOdVUK45c/m4IRyIOLcK4NcBOg/8no2VjzNo
         4KDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759160103; x=1759764903;
        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=St7MtK7lqhceGoxH8AAxicUHeyaRpXl1YBow1O0Mb/U=;
        b=izhoM5fuROf06CowTBZrtL5ARUafsyjuKxsm+yESCeJsXv1oY8lvrvNoKslCw5mcWP
         RC8cFkyDnB/aCq8QRwCjoVEekV37gZYDWM0h+CpOOx2UutxbiIBZI2BReNrlTTg3rlSH
         cHRw7sA57vNSRz2g9vpjLCqxtCY/Tvn6fKMAhROehKHvUqeAX2fbdn6Jk0GDaZfTDYYb
         sPj4RtM0QiK3CQnb4hoIn+q/F59he4HGsDJgduWwsyxYvzvO1lt3akXISZZ0oADCdfuk
         yV29mSxcOnnjy2PYKn0xzevcQcrzWBJ4aV2AXV1Yhddykc5/Di47UA9k6S256QSXSYi8
         gbOg==
X-Forwarded-Encrypted: i=1; AJvYcCXCjj5/2uy4eEpjTWsIFS2Io6bfvFOSXu5/l0Q6VPC4E2bmhmj/kv+agfdHz9Xfs+VLeDqRJaeB1js=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztepRl9eaAmZi01RSx/uZUS5jSLl2fXbSWk731Y2tV/Tq/OfeM
	0JK3r59jyHVlrdp4EUMdY+L2MPDKKfzQEuK9sCEczr/OOdvbWFxWGLuj
X-Gm-Gg: ASbGncuum7F0YOqdC7M8BWBSps+v+X917y3Ea4uRDwLWQbqRzJD87o6a4w0dV7QvMiS
	DozW0Fw5T3IuMzvCqh53OTjBuhnWxYaghayUeK3v0wzK/tGz7gzlt00IwptWqX2dG0b6V9zAWJk
	dP/JsX7p5EDf95wdmom1vhjiSeXTHtPj7DQIDPxjeg6jbpesYgBHShRuCVIf+32+rbaDQfAQZbr
	xS0n69QeCzLb/Xp7fnIj4xwT8sv39EP0OpilD8dzSt9ZKOTM17w1hZ74aEnNfkcLJrRTNK8djFc
	UFHL9C1AP04ARPl7BsPs92hQZW/wwshaHX3vDRyXFr47dUI+woGAUf3LyUuABJkIrFrRxmeoXyg
	ipwBeAmkky30g/aM4brmBTS3RQfKxbIrrtW0VNgIL5JHwNeb6zt8Iuu+96HJC4pYv0+W+eg2Vuy
	2P6qaboPA=
X-Google-Smtp-Source: AGHT+IED3nY2IeswDKHnxjb2JCmFaDg/GhqWKfgRq1asooCVh8DCSPdOrP2Hs3ymU5m2+wxfqz7sDg==
X-Received: by 2002:a17:906:dc89:b0:b3d:b3fe:27ed with SMTP id a640c23a62f3a-b3db3fe2fa1mr613933866b.57.1759160102850;
        Mon, 29 Sep 2025 08:35:02 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------d6rGK2ExZZTEDgY53x6yI8f5"
Message-ID: 
Date: Mon, 29 Sep 2025 17:35:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 0/8] Allow to build libxl and other tools with
 json-c instead of yajl
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Stefano Stabellini ,
 Andrew Cooper , Julien Grall ,
 Juergen Gross , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Michal Orzel ,
 Community Manager 
References: <20250929120756.46075-1-anthony@xenproject.org>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250929120756.46075-1-anthony@xenproject.org>

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


On 9/29/25 2:07 PM, Anthony PERARD wrote:
> From: Anthony PERARD
>
> Patch series available in this git branch:
> https://xenbits.xenproject.org/git-http/people/aperard/xen-unstable.git br.libxl-libjsonc-v2
>
> changes in v2:
> - introduce $(XEN_JSON_LIBS) to have either -lyajl or -ljson-c or both (for a
>    short while).
> - few more changes detail in each patches.
>
> Hi,
>
> The library YAJL has been unmaintained for several years, without an obvious
> fork to pick.
>
> On the other and the library json-c is been maintained and use by several other
> project, it's probably already installed on your machine. So this patch series
> intend to allow to build the Xen toolstack again json-c, and forgo yajl.

Do we have any plans to drop fallback to yajl in the next release? Or because of
this ...

>
> Just in case, YAJL is can still be used.
>
> There's bit of libxl API that exposes YAJL, mainly so it can be used by `xl` to
> call libxl_domain_config_gen_json(). It was exposed via the "libxl_json.h"
> headers. This functions and others won't be available when libxl is build
> against json-c.

... that some API trying to use API exposed by YAJL we just can't drop support
of yajl?

~ Oleksii


>
> Cheers,
>
> Anthony PERARD (8):
>    tools/configure: Introduce deps on json-c lib for libxl
>    libxl: Convert libxl__json_parse() to use json-c
>    libxl: convert libxl__json_object_to_yajl_gen to
>      libxl__json_object_to_libjsonc_object
>    libxl: libxl__object_to_json() to json-c
>    libxl: convert libxl__json_object_to_json() to json_object
>    tools/libxenstat: Use json-c when available
>    configure: Use json-c by default, fallback to yajl
>    Update CHANGELOG and README with dependency on json-c
>
>   CHANGELOG.md                              |   2 +
>   README                                    |   2 +-
>   config/Tools.mk.in                        |   1 +
>   tools/config.h.in                         |   3 +
>   tools/configure                           | 136 +++++-
>   tools/configure.ac                        |  10 +-
>   tools/include/libxl_json.h                |  27 ++
>   tools/libs/light/Makefile                 |   6 +-
>   tools/libs/light/gentypes.py              | 160 +++++-
>   tools/libs/light/idl.py                   |   7 +-
>   tools/libs/light/libxl_cpuid.c            | 119 +++++
>   tools/libs/light/libxl_internal.h         |  23 +-
>   tools/libs/light/libxl_json.c             | 562 +++++++++++++++++++++-
>   tools/libs/light/libxl_qmp.c              |  53 ++
>   tools/libs/light/libxl_types.idl          |   7 +-
>   tools/libs/light/libxl_types_internal.idl |   3 +-
>   tools/libs/stat/Makefile                  |   2 +-
>   tools/libs/stat/xenstat_qmp.c             | 126 ++++-
>   tools/xl/Makefile                         |   2 +-
>   tools/xl/xl_info.c                        | 102 +++-
>   20 files changed, 1312 insertions(+), 41 deletions(-)
>
--------------d6rGK2ExZZTEDgY53x6yI8f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 9/29/25 2:07 PM, Anthony PERARD
      wrote:

    

    

      
From: Anthony PERARD <anthony.perard@vates.tech>

Patch series available in this git branch:
https://xenbits.xenproject.org/git-http/people/aperard/xen-unstable.git br.libxl-libjsonc-v2

changes in v2:
- introduce $(XEN_JSON_LIBS) to have either -lyajl or -ljson-c or both (for a
  short while).
- few more changes detail in each patches.

Hi,

The library YAJL has been unmaintained for several years, without an obvious
fork to pick.

On the other and the library json-c is been maintained and use by several other
project, it's probably already installed on your machine. So this patch series
intend to allow to build the Xen toolstack again json-c, and forgo yajl.

    

    
Do we have any plans to drop fallback to yajl in the next release? Or because of
this ...


    

      

Just in case, YAJL is can still be used.

There's bit of libxl API that exposes YAJL, mainly so it can be used by `xl` to
call libxl_domain_config_gen_json(). It was exposed via the "libxl_json.h"
headers. This functions and others won't be available when libxl is build
against json-c.

    

    
... that some API trying to use API exposed by YAJL we just can't drop support
of yajl?

~ Oleksii


    


    

    

      

Cheers,

Anthony PERARD (8):
  tools/configure: Introduce deps on json-c lib for libxl
  libxl: Convert libxl__json_parse() to use json-c
  libxl: convert libxl__json_object_to_yajl_gen to
    libxl__json_object_to_libjsonc_object
  libxl: libxl__object_to_json() to json-c
  libxl: convert libxl__json_object_to_json() to json_object
  tools/libxenstat: Use json-c when available
  configure: Use json-c by default, fallback to yajl
  Update CHANGELOG and README with dependency on json-c

 CHANGELOG.md                              |   2 +
 README                                    |   2 +-
 config/Tools.mk.in                        |   1 +
 tools/config.h.in                         |   3 +
 tools/configure                           | 136 +++++-
 tools/configure.ac                        |  10 +-
 tools/include/libxl_json.h                |  27 ++
 tools/libs/light/Makefile                 |   6 +-
 tools/libs/light/gentypes.py              | 160 +++++-
 tools/libs/light/idl.py                   |   7 +-
 tools/libs/light/libxl_cpuid.c            | 119 +++++
 tools/libs/light/libxl_internal.h         |  23 +-
 tools/libs/light/libxl_json.c             | 562 +++++++++++++++++++++-
 tools/libs/light/libxl_qmp.c              |  53 ++
 tools/libs/light/libxl_types.idl          |   7 +-
 tools/libs/light/libxl_types_internal.idl |   3 +-
 tools/libs/stat/Makefile                  |   2 +-
 tools/libs/stat/xenstat_qmp.c             | 126 ++++-
 tools/xl/Makefile                         |   2 +-
 tools/xl/xl_info.c                        | 102 +++-
 20 files changed, 1312 insertions(+), 41 deletions(-)



    

  


--------------d6rGK2ExZZTEDgY53x6yI8f5--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 15:41:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 15:41:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1132991.1471186 (Exim 4.92)
	(envelope-from )
	id 1v3G0V-0000Ne-Fr; Mon, 29 Sep 2025 15:41:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1132991.1471186; Mon, 29 Sep 2025 15:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3G0V-0000NX-C4; Mon, 29 Sep 2025 15:41:43 +0000
Received: by outflank-mailman (input) for mailman id 1132991;
 Mon, 29 Sep 2025 15:41:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3G0T-0000NR-VA
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 15:41:42 +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 c9eeb587-9d4a-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 17:41:39 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-b0418f6fc27so685986766b.3
 for ; Mon, 29 Sep 2025 08:41:39 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353e5d168dsm970071066b.4.2025.09.29.08.41.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 08:41: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: c9eeb587-9d4a-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759160498; x=1759765298; 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=JJJjl9X4f5zstmqMmUJl4SeXx33I5cLkKaLg7u6XmcU=;
        b=QdCHsIxolSMkQGZsIGY0WVB24b+fQTLI6u2htEKI/gvWUvsiD3ekt0XAAuFkFj/flA
         hSm9FNu32PSxF/wnmloW9mam9TIEQLHb//pPZztWwCTJlSqma6BXhfiale9PodVt24Nx
         akUvvC+V4nI7nUUQ/GPKPPnCuaxEACk4Xm4/43oWZrI1oV65drwcDVWvgvgXU90hpj6s
         ZrahgccX2h7Noyxmv1MqOvmc0nTKGgc068N8J8KAu+EJ6dMeiq888y3+rvBbdI7920cx
         kDlo6HX+6dxVmAF+xgdoyULsl8VDflkT5BHcbdjAv+phS7QxoQn5iMm2ZRr5+k5CpvRT
         szQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759160498; x=1759765298;
        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=JJJjl9X4f5zstmqMmUJl4SeXx33I5cLkKaLg7u6XmcU=;
        b=TYlEP8k+29FTc288YwSG5WrfHeankr7TX1+ipr0Bq3xohjDDGYxDxUlUEPd7FIr20u
         IU96mwxygfx0gYr3Mhg5K7XaIZsXjBIOvz95+ZzhRPqKcyZ04+/fODmY0C2DUa9SXxh8
         82UukT1gBXTFjJTNDoMMRWcdyyr2w+IApPtJji1Xg7S3EJ0jMo6XuRKWCoyScNm+j6zr
         J1iBDm/rPtVnGXeknIibkI01PjkZGMVHJBEA+j5v4WZhXy4KJbTPcd2mb3hvITPOg9JD
         ovq9gGjtkSb93dxZ6qDiEodieQXQHCB0D7wJiHw1QBeyqvDEcxDpraitPqvT/O2hlSCJ
         nXow==
X-Forwarded-Encrypted: i=1; AJvYcCVcuvq0FBrujbXBR3r1h5TikFBH6P8NY7HpdvmUz0qHGQGjnD4DfskLkWuRtwzChXoH4Prf96XIjDo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0b6xpNzBDoovwqpUaR/h2QJ+e+JCtbBE9S+ZHgjLLckbVdFWF
	as4RrKPMszhxVsgF9Pj7FQJhrK2m9nqLXhe1to8sUJ9Oz6/UZulocuEq
X-Gm-Gg: ASbGnctHK2TWDdwGo8ZGxoibraEyVExd+gSSxIlcUSZZUdEOIujiedEJ57lwwRqSKDd
	3p0vJqW3GqUS7OVGF0/DJsFXgHZ4nyQwamdU6JsjZg8Hfe3wU0dtDQTcHQGuJx8YQPUwfZlSvpo
	61+00X2WqDF3wc5ZaFLGSpAPzhdhlnguY+0MKrdbqSAk2XII7X4+TmRl1Txd0aaQXGUk/4WEu/s
	9kVdJVenmYu54IGGvUKDaT7XM62VSbhryq6c7oyvzHzErLDhusLYDYOI1nTYNKVsjx8QZ5m2tyw
	oNy0EsM/HyXw0eBp1cCOhACuxT0eWVa64Ju0thDT6P/EDOtohtPi8ZUZoDz+++bkMUqiGOsCemI
	E6sMk+H93VC1Bga7WjnIRkEUWW00TuhpB44t13zbrtb03ymZzO2h29JMjO8ykYG8K7Shfx58Ieg
	RtsxlkOow=
X-Google-Smtp-Source: AGHT+IEI3ZtP4UJcMxmXtVsEmNNvwRnBEhvRevQfIQBU4V/51Gaz9p1mdOZldFWYre3zxjNQI/HNXA==
X-Received: by 2002:a17:907:6093:b0:afe:6c9b:c828 with SMTP id a640c23a62f3a-b34bd93b2e9mr1805028766b.61.1759160498250;
        Mon, 29 Sep 2025 08:41:38 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------X7Xm0A6ykrh0qtygjMNPUvqM"
Message-ID: 
Date: Mon, 29 Sep 2025 17:41:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
To: Jan Beulich , "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Daniel P. Smith" ,
 "xen-devel@lists.xenproject.org" ,
 "Andryuk, Jason" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com>
 <20250910073827.3622177-19-Penny.Zheng@amd.com>
 
 
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@suse.com>
 
 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/26/25 9:14 AM, Jan Beulich wrote:
> On 26.09.2025 08:57, Penny, Zheng wrote:
>>> -----Original Message-----
>>> From: Jan Beulich
>>> Sent: Friday, September 26, 2025 2:53 PM
>>>
>>> On 26.09.2025 06:41, Penny, Zheng wrote:
>>>>> -----Original Message-----
>>>>> From: Jan Beulich
>>>>> Sent: Thursday, September 25, 2025 10:29 PM
>>>>>
>>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Jan Beulich
>>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
>>>>>>>
>>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
>>>>>>>> --- a/xen/include/xsm/xsm.h
>>>>>>>> +++ b/xen/include/xsm/xsm.h
>>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
>>>>>>>>       void (*security_domaininfo)(struct domain *d,
>>>>>>>>                                   struct xen_domctl_getdomaininfo *info);
>>>>>>>>       int (*domain_create)(struct domain *d, uint32_t ssidref);
>>>>>>>> -    int (*getdomaininfo)(struct domain *d);
>>>>>>>>   #ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>> +    int (*getdomaininfo)(struct domain *d);
>>>>>>>>       int (*domctl_scheduler_op)(struct domain *d, int op);
>>>>>>>>       int (*sysctl_scheduler_op)(int op);
>>>>>>>>       int (*set_target)(struct domain *d, struct domain *e); @@
>>>>>>>> -234,7
>>>>>>>> +234,11 @@ static inline int xsm_domain_create(
>>>>>>>>
>>>>>>>>   static inline int xsm_getdomaininfo(xsm_default_t def, struct
>>>>>>>> domain
>>>>>>>> *d)  {
>>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
>>>>>>>>       return alternative_call(xsm_ops.getdomaininfo, d);
>>>>>>>> +#else
>>>>>>>> +    return -EOPNOTSUPP;
>>>>>>>> +#endif
>>>>>>>>   }
>>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
>>>>>>> sysctl is hence already broken with the earlier series. Now the
>>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
>>>>>>> really ought to extend to any operations available to other than the core
>>> toolstack.
>>>>>>> That's the Xenstore ones here, but also the ones used by qemu
>>>>>>> (whether run in
>>>>> Dom0 or a stubdom).
>>>>>> Maybe not only limited to the core toolstack. In
>>>>>> dom0less/hyperlaunched
>>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
>>>>> pvh machine type and with very restricted functionality(, only acting
>>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
>>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
>>> upstream?
>>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
>>>>>> requires
>>>>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
>>>>> how it was called in QEMU...
>>>>>
>>>>> It's not "it"; it's different ones. First and foremost I was thinking
>>>>> of
>>>>>   * XEN_DOMCTL_ioport_mapping
>>>>>   * XEN_DOMCTL_memory_mapping
>>>>>   * XEN_DOMCTL_bind_pt_irq
>>>>>   * XEN_DOMCTL_unbind_pt_irq
>>>>> but there may be others (albeit per the dummy xsm_domctl() this is
>>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
>>>>> checking can in principle be called by qemu.
>>>>>
>>>> Understood.
>>>> I assume that they are all for device passthrough. We are not accepting device
>>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
>>> developed device passthrough through device tree to only accept "static
>>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
>>> internal , it may be the only accept way to do device passthrough in
>>> dom0less/hyperlaunch-ed scenario.
>>>
>>> Right, but no matter what your goals, the upstream contributions need to be self-
>>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
>>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
>>> them may be an option here.)
>> Understood.
>> I'll move them all to the dm-ops
> Before you do so, please consider the consequences, though (I said "may" for a
> reason). Also please allow others to chime in. (In this context I notice that
> several REST maintainers weren't even Cc-ed here, and hence may not have seen
> the earlier discussion.)
>
> One thing seems pretty clear to me: This work likely isn't going to be suitable
> for 4.21 anymore. Hence we're back to considering alternatives to address the
> still pending build issue. (My take on it remains: Revert the tail of the
> sysctl work.) Adding Oleksii to Cc as well.

I agree, the patch series is still quite far from being ready to merge.
So let’s consider it for the next release.

As mentioned in the earlier (related) patch series, reverting the tail of the
sysctl work is still, in my opinion, the best option.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/26/25 9:14 AM, Jan Beulich wrote:

    

    

      
On 26.09.2025 08:57, Penny, Zheng wrote:


      

        

          
-----Original Message-----
From: Jan Beulich <jbeulich@suse.com>
Sent: Friday, September 26, 2025 2:53 PM

On 26.09.2025 06:41, Penny, Zheng wrote:


          

            

              
-----Original Message-----
From: Jan Beulich <jbeulich@suse.com>
Sent: Thursday, September 25, 2025 10:29 PM

On 25.09.2025 11:41, Penny, Zheng wrote:


              

                

                  
-----Original Message-----
From: Jan Beulich <jbeulich@suse.com>
Sent: Thursday, September 11, 2025 9:30 PM

On 10.09.2025 09:38, Penny Zheng wrote:


                  

                    
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -55,8 +55,8 @@ struct xsm_ops {
     void (*security_domaininfo)(struct domain *d,
                                 struct xen_domctl_getdomaininfo *info);
     int (*domain_create)(struct domain *d, uint32_t ssidref);
-    int (*getdomaininfo)(struct domain *d);
 #ifdef CONFIG_MGMT_HYPERCALLS
+    int (*getdomaininfo)(struct domain *d);
     int (*domctl_scheduler_op)(struct domain *d, int op);
     int (*sysctl_scheduler_op)(int op);
     int (*set_target)(struct domain *d, struct domain *e); @@
-234,7
+234,11 @@ static inline int xsm_domain_create(

 static inline int xsm_getdomaininfo(xsm_default_t def, struct
domain
*d)  {
+#ifdef CONFIG_MGMT_HYPERCALLS
     return alternative_call(xsm_ops.getdomaininfo, d);
+#else
+    return -EOPNOTSUPP;
+#endif
 }


                  

                  
This is in use by a Xenstore sysctl and a Xenstore domctl. The
sysctl is hence already broken with the earlier series. Now the
domctl is also being screwed up. I don't think MGMT_HYPERCALLS
really ought to extend to any operations available to other than the core


                

              

            

          

          
toolstack.


          

            

              

                

                  
That's the Xenstore ones here, but also the ones used by qemu
(whether run in


                

              

              
Dom0 or a stubdom).


              

                
Maybe not only limited to the core toolstack. In
dom0less/hyperlaunched


              

              
scenarios, hypercalls are strictly limited. QEMU is also limited to
pvh machine type and with very restricted functionality(, only acting
as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
Stefano Am I understanding correctly and thoroughly about our scenario here for


            

          

          
upstream?


          

            

              

                
Tracking the codes, if Xenstore is created as a stub domain, it
requires


              

              
getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
how it was called in QEMU...

It's not "it"; it's different ones. First and foremost I was thinking
of
 * XEN_DOMCTL_ioport_mapping
 * XEN_DOMCTL_memory_mapping
 * XEN_DOMCTL_bind_pt_irq
 * XEN_DOMCTL_unbind_pt_irq
but there may be others (albeit per the dummy xsm_domctl() this is
the full set). As a general criteria, anything using XSM_DM_PRIV
checking can in principle be called by qemu.



            

            
Understood.
I assume that they are all for device passthrough. We are not accepting device


          

          
passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
developed device passthrough through device tree to only accept "static
configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
internal , it may be the only accept way to do device passthrough in
dom0less/hyperlaunch-ed scenario.

Right, but no matter what your goals, the upstream contributions need to be self-
consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
them may be an option here.)


        

        
Understood.
I'll move them all to the dm-ops


      

      
Before you do so, please consider the consequences, though (I said "may" for a
reason). Also please allow others to chime in. (In this context I notice that
several REST maintainers weren't even Cc-ed here, and hence may not have seen
the earlier discussion.)

One thing seems pretty clear to me: This work likely isn't going to be suitable
for 4.21 anymore. Hence we're back to considering alternatives to address the
still pending build issue. (My take on it remains: Revert the tail of the
sysctl work.) Adding Oleksii to Cc as well.

    

    
I agree, the patch series is still quite far from being ready to merge.
So let’s consider it for the next release.

As mentioned in the earlier (related) patch series, reverting the tail of the
sysctl work is still, in my opinion, the best option.

~ Oleksii

  


--------------X7Xm0A6ykrh0qtygjMNPUvqM--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 15:48:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 15:48:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133006.1471196 (Exim 4.92)
	(envelope-from )
	id 1v3G6o-0001BF-88; Mon, 29 Sep 2025 15:48:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133006.1471196; Mon, 29 Sep 2025 15:48: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 1v3G6o-0001B8-5P; Mon, 29 Sep 2025 15:48:14 +0000
Received: by outflank-mailman (input) for mailman id 1133006;
 Mon, 29 Sep 2025 15:48: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 1v3G6m-0001B2-9m
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 15:48:12 +0000
Received: from mail132-16.atl131.mandrillapp.com
 (mail132-16.atl131.mandrillapp.com [198.2.132.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2ed8934-9d4b-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 17:48:10 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4cb5F46XphzB5pLqG
 for ; Mon, 29 Sep 2025 15:48:08 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ea4cab105dc845f49dbe2a8859fbf753; Mon, 29 Sep 2025 15:48: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: b2ed8934-9d4b-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1759160888; x=1759430888;
	bh=SPPx8ujwQQeJvrG+ILFgUkEMojt7Pt3i1zlrR2kyPVw=;
	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=W+aVuTCYG47ym6rWSiAOhJFcK6g1i+IGCYYDpbKgJOtKcLMPpBpxCZyvdN6lWyZXq
	 3ruabjE7IhA7qqnpg9TeQITNHWyQecIdsZPCXSSxyu3sw3V211afcGA2Tny4gdU7EM
	 M1UUSwk98LBowe19a3i4QsJPJiYC5Ky1Xp3FfHjTLEkXAkeDYIkQFHFluW/lWlO4oT
	 jw9N9E/YszYfZ/70JGrOeWIKExnFxLVGEY12EF7Ssn2pruHrTOfJKibFzzqTzdCRHv
	 AZxMpKmEA06EoADp6Gy5PEWeOy6+1zq2eYYrfv3k8RHPDWAqgcGRTlQaZPoMktiJpI
	 Cz9g/emUI9W9Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1759160888; x=1759421388; i=teddy.astie@vates.tech;
	bh=SPPx8ujwQQeJvrG+ILFgUkEMojt7Pt3i1zlrR2kyPVw=;
	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=th0Wg5lpL5js5ByV3WTpk3adJ1csHVclyoYjQTB7PLIlQmRZOIT2JseNtAUATmmM/
	 NGCs2u3Qr4Nqv+rO0xUbamj0HQeQaZGOHZW3s8vyo/p4ALmuTc+bAPTYWjo5vk9nWB
	 aiNWT2e+iCVvbjJHOcwpluJcuifMKpcphmwAc1eSU4lfDVcAQuD5m17RnBRQrZfS42
	 ReBQywR6EgqgueiDWCAlmi7lQyOtLaCmFswYfkrdEb6p7A3c8cSsDEqV9V5u9C7YWB
	 d5ef/ACq25m33B707zS9zOCstAFQPmEH2jYzhcFvGOmzrTJk4b2UOl/PMN4j13RlaX
	 vCsSWaLhY8cUA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20x86/hap:=20Inline=20"flush=5Fvcpu"=20in=20"flush=5Ftlb"?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1759160887783
Message-Id: <786ad391-c6ce-465d-b7fc-3d3a3e5fec18@vates.tech>
To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Cc: xen-devel@lists.xenproject.org, "Jan Beulich" , "Andrew Cooper" 
References:  
In-Reply-To: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ea4cab105dc845f49dbe2a8859fbf753?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250929:md
Date: Mon, 29 Sep 2025 15:48:08 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 29/09/2025 =C3=A0 16:09, Roger Pau Monn=C3=A9 a =C3=A9crit=C2=A0:
> On Mon, Sep 29, 2025 at 12:36:30PM +0000, Teddy Astie wrote:
>> flush_vcpu static function here is only used in one place which is just =
below
>> where it is defined. Inline the function to reduce the noise and clarify
>> what we are doing.
> 
> Did you check that the compiler doesn't inline it already?
> 
> It seems like an obvious optimization for the compiler to do.
> 

I assume that the compiler already does it, it's mostly meant to be a 
cosmetic change.

>> No functional change.
>>
>> Signed-off-by: Teddy Astie 
>> ---
>>   xen/arch/x86/mm/hap/hap.c | 7 +------
>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
>> index 2f69ff9c7b..407c80afab 100644
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -721,11 +721,6 @@ static pagetable_t cf_check hap_update_cr3(struct v=
cpu *v, bool noflush)
>>       return pagetable_null();
>>   }
>>   
>> -static bool flush_vcpu(const struct vcpu *v, const unsigned long *vcpu_=
bitmap)
>> -{
>> -    return !vcpu_bitmap || test_bit(v->vcpu_id, vcpu_bitmap);
> 
> The same construct is used in shadow code also, maybe it would be
> helpful to place the flush_vcpu() helper in a common header as static
> inline?
> 

maybe, but given the simplicity of the function, it does feel a bit 
excessive it for hap code.

> OTOH we don't care much for shadow, so it might be simpler to leave
> shadow as-is and do the change just for HAP, but would be good to
> mention in the commit message why shadow is not adjusted in the same
> way.

Something like

"We only do this for hap where this function is only used once."

?

> 
> Thanks, Roger.
> 

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Mon Sep 29 15:59:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 15:59:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133018.1471207 (Exim 4.92)
	(envelope-from )
	id 1v3GHJ-0002wG-8c; Mon, 29 Sep 2025 15:59:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133018.1471207; Mon, 29 Sep 2025 15:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3GHJ-0002w9-45; Mon, 29 Sep 2025 15:59:05 +0000
Received: by outflank-mailman (input) for mailman id 1133018;
 Mon, 29 Sep 2025 15:59:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3GHI-0002w3-7x
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 15:59:04 +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 376904bb-9d4d-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 17:59:01 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-634a3327ff7so8854860a12.1
 for ; Mon, 29 Sep 2025 08:59:01 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3b052d4sm7958120a12.48.2025.09.29.08.59.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 08:59:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 376904bb-9d4d-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759161541; x=1759766341; 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=pcEDUDGUfBQH/elHny1dvp2hEud9tsYPhaJYy9TIOXY=;
        b=WjhZD8QH6tQHWtKwKHjVHGCVI/TwPHvvafNbN8gG6ulTqBXFdv/5x46LKmLdJteN97
         yCy7qnCiEcof6JjVmRI8U0n6DVBIsSACdSGafcMa1WQQZ0m5ryFSXhz/H3x0cB7IgsCA
         XBZi7FoUiBAgATNXT1/UDoTi9hR887VVaGtns07EsDm5CwnrmSRblMM4z/USRuXjQen0
         8ULNBo3xa180NYk0T943fL3vUIPCKBr3tQOigVvfG9n9RfANrsi2LvjHRcl6A+Fgokgi
         vmzNRJe55bsj/sfOERiU5lVL/DCz7BTV96znSFxRv5Vtbog/eD/2n18GKGa/jzchUReR
         nAxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759161541; x=1759766341;
        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=pcEDUDGUfBQH/elHny1dvp2hEud9tsYPhaJYy9TIOXY=;
        b=DvnHx0pcWifM8Osf6eUwHscHbMS9h3gcxRA9xsyRP1QIhNVLB3hVwAUBkQN6edtDA6
         bof06HqTkjdw2h83YqAIcXvqV6CyUDOvCZmW/72IEqR9fcS9JrVwWZP4QusqcH22Ji/j
         vSQBej9mGaGP+mbwjMMU0rCn5Pi7fszfTZaHCIgEtvynn6WecbcrlX93a1jIwLOxtIrz
         OajNLL6WG8PrTysOUbQppII3uSnLDyFVycdLP4dIjhtjn0JJqZmI7WMagf/86Spb3MVV
         MLvVCl1FLwGGPBdRzVw/Uco2iRrwjv0swqFqdUM06MQK6u50yfmoM0BUQTlVVUBZf5Xc
         cW6g==
X-Forwarded-Encrypted: i=1; AJvYcCVAU+OscKohLfpMOS/htESCjqRMxmEW96/EZIRd2yhWnMAcnRGLsFs8+yl6BbQJoYC3PQU8ObEq8sk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyClfDjbebWRs70qPSRQrWClUhEBmkcJsbtHnB6EM86dp/IEc49
	+1kVaGNhxnd5KwvuW7nrEf5GHkViWw3YF9qwW9lMcPX80tqpeAvsZYnJ
X-Gm-Gg: ASbGnct9lqIXyxKBFIXSOsbaw4tJyS91B2CleDG6E6CBcjlmXb2O2SVsRhCsFzAdb75
	Kot9BNEgZ5ggIxAmIhpcbDwmThy/kV/rl1NakOnSNMMdulIaudz99DPGu6efqELv0qK7jyd+Xcu
	j06GncPbDoOSBYInEd7R0aAoY5grjyEYIVDzhXb+Gxn3Uka6C3RY2YBbIxA9PZ+gihsjy8zZ7Iz
	YfEWwQbEqj83flbrg3skyuuMeMcFiCOAq/msqFBAAsgdZ6lMf1EghQ2e/TmIh7SS39v6Ur0D+9A
	HN85HqxzLHrxPjXnPLPs6SWyijIyYmuKvfeGuaQ8fh8AUQWKs5Qi/ruPOViK+nmdS6VPmk29c4e
	0rFeXEUWeu6gko01B3Nw/a1BsB8O/KPqFa5qPlbCvMEUIjR36/o+HKn/2KhF913sd7kFN2qGuW9
	nQTK5Vyaw=
X-Google-Smtp-Source: AGHT+IHyxhlzAjhlohvEFWaYE6S88nP+H3FL/qAlcoF2fOCHCCihZI9JyPIsTyOIH23Qq820VzPdTg==
X-Received: by 2002:a05:6402:24c5:b0:634:2538:e563 with SMTP id 4fb4d7f45d1cf-6349f9d1c15mr12923604a12.3.1759161540922;
        Mon, 29 Sep 2025 08:59:00 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------a4FbLeb3lS4WxuKkSWT7Qm1z"
Message-ID: 
Date: Mon, 29 Sep 2025 17:59:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X
 capabilities
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Stewart Hildebrand ,
 Jan Beulich 
References: <20250929084149.70560-1-roger.pau@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250929084149.70560-1-roger.pau@citrix.com>

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


On 9/29/25 10:41 AM, Roger Pau Monne wrote:
> I've had the luck to come across a PCI card that exposes a MSI-X capability
> where the BIR of the vector and PBA tables points at a BAR that has 0 size.
>
> This doesn't play nice with the code in vpci_make_msix_hole(), as it would
> still use the address of such empty BAR (0) and attempt to crave a hole in
> the p2m.  This leads to errors like the one below being reported by Xen:
>
> d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
>
> And the device left unable to enable memory decoding due to the failure
> reported by vpci_make_msix_hole().
>
> Introduce checking in init_msix() to ensure the BARs containing the MSI-X
> tables are usable.  This requires checking that the BIR points to a
> non-empty BAR, and the offset and size of the MSI-X tables can fit in the
> target BAR.
>
> This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
> EPYC 9965 processors.  The broken device is:
>
> 22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
>
> There are multiple of those integrated controllers in the system, all
> broken in the same way.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Stewart Hildebrand
> Cc: Jan Beulich
> Cc: Oleksii Kurochko
>
> While not strictly a bugfix, I consider this a worthy improvement so that
> PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
> capabilities.

Based on your commit description it looks like a bug as without it, for example,
SATA controller can't be used, right?

>   Hence I think this change should be considered for inclusion
> into 4.21.  There a risk of regressing on hardware that was already working
> with PVH, but given enough testing that should be minimal.

We have some PVH tests in Xen’s GitLab CI, but I assume that isn’t enough?

~ Oleksii

> ---
>   xen/drivers/vpci/msix.c | 50 ++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index 54a5070733aa..8458955d5bbb 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -675,6 +675,51 @@ static int cf_check init_msix(struct pci_dev *pdev)
>       if ( !msix )
>           return -ENOMEM;
>   
> +    msix->tables[VPCI_MSIX_TABLE] =
> +        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
> +    msix->tables[VPCI_MSIX_PBA] =
> +        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
> +
> +    /* Check that the provided BAR is valid. */
> +    for ( i = 0; i < ARRAY_SIZE(msix->tables); i++ )
> +    {
> +        const char *name = (i == VPCI_MSIX_TABLE) ? "vector" : "PBA";
> +        const struct vpci_bar *bars = pdev->vpci->header.bars;
> +        unsigned int bir = msix->tables[i] & PCI_MSIX_BIRMASK;
> +        unsigned int type;
> +        unsigned int offset = msix->tables[i] & ~PCI_MSIX_BIRMASK;
> +        unsigned int size =
> +            (i == VPCI_MSIX_TABLE) ? max_entries * PCI_MSIX_ENTRY_SIZE
> +                                   : ROUNDUP(DIV_ROUND_UP(max_entries, 8), 8);
> +
> +        if ( bir >= ARRAY_SIZE(pdev->vpci->header.bars) )
> +        {
> +            printk(XENLOG_ERR "%pp: MSI-X %s table with out of range BIR %u\n",
> +                   &pdev->sbdf, name, bir);
> + invalid:
> +            xfree(msix);
> +            return -ENODEV;
> +
> +        }
> +
> +        type = bars[bir].type;
> +        if ( type != VPCI_BAR_MEM32 && type != VPCI_BAR_MEM64_LO )
> +        {
> +            printk(XENLOG_ERR
> +                   "%pp: MSI-X %s table at invalid BAR%u with type %u\n",
> +                   &pdev->sbdf, name, bir, type);
> +            goto invalid;
> +        }
> +
> +        if ( (uint64_t)offset + size > bars[bir].size )
> +        {
> +            printk(XENLOG_ERR
> +                   "%pp: MSI-X %s table offset %#x size %#x outside of BAR%u size %#lx\n",
> +                   &pdev->sbdf, name, offset, size, bir, bars[bir].size);
> +            goto invalid;
> +        }
> +    }
> +
>       rc = vpci_add_register(pdev->vpci, control_read, control_write,
>                              msix_control_reg(msix_offset), 2, msix);
>       if ( rc )
> @@ -686,11 +731,6 @@ static int cf_check init_msix(struct pci_dev *pdev)
>       msix->max_entries = max_entries;
>       msix->pdev = pdev;
>   
> -    msix->tables[VPCI_MSIX_TABLE] =
> -        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
> -    msix->tables[VPCI_MSIX_PBA] =
> -        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
> -
>       for ( i = 0; i < max_entries; i++)
>       {
>           msix->entries[i].masked = true;
--------------a4FbLeb3lS4WxuKkSWT7Qm1z
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 9/29/25 10:41 AM, Roger Pau Monne
      wrote:

    

    

      
I've had the luck to come across a PCI card that exposes a MSI-X capability
where the BIR of the vector and PBA tables points at a BAR that has 0 size.

This doesn't play nice with the code in vpci_make_msix_hole(), as it would
still use the address of such empty BAR (0) and attempt to crave a hole in
the p2m.  This leads to errors like the one below being reported by Xen:

d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area

And the device left unable to enable memory decoding due to the failure
reported by vpci_make_msix_hole().

Introduce checking in init_msix() to ensure the BARs containing the MSI-X
tables are usable.  This requires checking that the BIR points to a
non-empty BAR, and the offset and size of the MSI-X tables can fit in the
target BAR.

This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
EPYC 9965 processors.  The broken device is:

22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)

There are multiple of those integrated controllers in the system, all
broken in the same way.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Stewart Hildebrand <stewart.hildebrand@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>

While not strictly a bugfix, I consider this a worthy improvement so that
PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
capabilities. 

    

    
Based on your commit description it looks like a bug as without it, for example,
SATA controller can't be used, right?



    

      
 Hence I think this change should be considered for inclusion
into 4.21.  There a risk of regressing on hardware that was already working
with PVH, but given enough testing that should be minimal.

    

    
We have some PVH tests in Xen’s GitLab CI, but I assume that isn’t enough?

~ Oleksii



    

      
---
 xen/drivers/vpci/msix.c | 50 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 54a5070733aa..8458955d5bbb 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -675,6 +675,51 @@ static int cf_check init_msix(struct pci_dev *pdev)
     if ( !msix )
         return -ENOMEM;
 
+    msix->tables[VPCI_MSIX_TABLE] =
+        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
+    msix->tables[VPCI_MSIX_PBA] =
+        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
+
+    /* Check that the provided BAR is valid. */
+    for ( i = 0; i < ARRAY_SIZE(msix->tables); i++ )
+    {
+        const char *name = (i == VPCI_MSIX_TABLE) ? "vector" : "PBA";
+        const struct vpci_bar *bars = pdev->vpci->header.bars;
+        unsigned int bir = msix->tables[i] & PCI_MSIX_BIRMASK;
+        unsigned int type;
+        unsigned int offset = msix->tables[i] & ~PCI_MSIX_BIRMASK;
+        unsigned int size =
+            (i == VPCI_MSIX_TABLE) ? max_entries * PCI_MSIX_ENTRY_SIZE
+                                   : ROUNDUP(DIV_ROUND_UP(max_entries, 8), 8);
+
+        if ( bir >= ARRAY_SIZE(pdev->vpci->header.bars) )
+        {
+            printk(XENLOG_ERR "%pp: MSI-X %s table with out of range BIR %u\n",
+                   &pdev->sbdf, name, bir);
+ invalid:
+            xfree(msix);
+            return -ENODEV;
+
+        }
+
+        type = bars[bir].type;
+        if ( type != VPCI_BAR_MEM32 && type != VPCI_BAR_MEM64_LO )
+        {
+            printk(XENLOG_ERR
+                   "%pp: MSI-X %s table at invalid BAR%u with type %u\n",
+                   &pdev->sbdf, name, bir, type);
+            goto invalid;
+        }
+
+        if ( (uint64_t)offset + size > bars[bir].size )
+        {
+            printk(XENLOG_ERR
+                   "%pp: MSI-X %s table offset %#x size %#x outside of BAR%u size %#lx\n",
+                   &pdev->sbdf, name, offset, size, bir, bars[bir].size);
+            goto invalid;
+        }
+    }
+
     rc = vpci_add_register(pdev->vpci, control_read, control_write,
                            msix_control_reg(msix_offset), 2, msix);
     if ( rc )
@@ -686,11 +731,6 @@ static int cf_check init_msix(struct pci_dev *pdev)
     msix->max_entries = max_entries;
     msix->pdev = pdev;
 
-    msix->tables[VPCI_MSIX_TABLE] =
-        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
-    msix->tables[VPCI_MSIX_PBA] =
-        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
-
     for ( i = 0; i < max_entries; i++)
     {
         msix->entries[i].masked = true;


    

  


--------------a4FbLeb3lS4WxuKkSWT7Qm1z--


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 16:31:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 16:31:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133031.1471216 (Exim 4.92)
	(envelope-from )
	id 1v3Gm4-0008Tq-HA; Mon, 29 Sep 2025 16:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133031.1471216; Mon, 29 Sep 2025 16:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Gm4-0008Tj-Dx; Mon, 29 Sep 2025 16:30:52 +0000
Received: by outflank-mailman (input) for mailman id 1133031;
 Mon, 29 Sep 2025 16:30:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1v3Gm3-0008Td-LE
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 16:30:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1v3Gm3-00Gd6D-0Z;
 Mon, 29 Sep 2025 16:30:51 +0000
Received: from [2a02:8012:3a1:0:4508:987f:45a1:fef]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1v3Gm3-004jZf-0f;
 Mon, 29 Sep 2025 16:30:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=xgfmXV6sYhCbiYwxyUWoWuJpp/DaIQ1Tr62WWco6GOc=; b=BRkvWbsYnefbSo/vjXcNfxhefM
	y9plISOgimOsbHt17BVJ6uNeA1jCWU6U5Rv3MeclggDTya2y7tpVh4uq+SfBw2pEVwvNVIvyEdtK4
	Ifdz75/MX3o3dNsfveBv1VioMJt/8IDq9mxZL1PzJakSaMx300EwV/0kxrl6Kzlw1QFM=;
Message-ID: <9a8f99bb-fbe4-4df5-836f-c00a919aeec0@xen.org>
Date: Mon, 29 Sep 2025 17:30:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Reorder SCI resource cleanup in domain
 destruction
Content-Language: en-GB
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Oleksii Kurochko 
References: <20ec9d9a8533417489a95543c1b72f7f55865c9c.1757856381.git.oleksii_moisieiev@epam.com>
 <6476dc12-1f9f-4b37-b569-e994bde6bcdb@xen.org>
 <4b1cab53-e2dc-4cd4-86b5-1d1be974d089@epam.com>
 <88a73261-4c24-465f-93df-6f9770046982@xen.org>
 <557392fd-f676-4aa0-9107-ee48243c336e@epam.com>
From: Julien Grall 
In-Reply-To: <557392fd-f676-4aa0-9107-ee48243c336e@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 28/09/2025 14:52, Oleksii Moisieiev wrote:
> Thanks. I'm preparing patch-series with multi-agent support and will see
> where it could be moved.
> Should I send a new patch with
> "Fixes:  ("")"
> syntax or it can be fixed inplace during commit?

No need for a new version. I have updated the commit message and committed.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 16:59:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 16:59:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133042.1471226 (Exim 4.92)
	(envelope-from )
	id 1v3HDi-00033N-LP; Mon, 29 Sep 2025 16:59:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133042.1471226; Mon, 29 Sep 2025 16: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 1v3HDi-00033G-Hi; Mon, 29 Sep 2025 16:59:26 +0000
Received: by outflank-mailman (input) for mailman id 1133042;
 Mon, 29 Sep 2025 16: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 1v3HDh-00033A-MN
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 16:59:25 +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 a56aec16-9d55-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 18:59: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 7C2206262B;
 Mon, 29 Sep 2025 16:59:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1199CC4CEF4;
 Mon, 29 Sep 2025 16:59:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a56aec16-9d55-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759165161;
	bh=0uQPHYYTyi2Beocl0K4k1QKQs4jMKduCIOiGNZ+sFME=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lCL0IuY6MledH3wk0ScWqMFCUopl+N9yfLg59AEOTqEwEtQs8qU7u32tRSzd5GZIr
	 8FpFedloWJUY9E05ZjOWzkZhbkoX1xZJOoVx+MOwUSanV6zT+JCzY5C1Va9WyWAeNb
	 u5ubKb5HEviNqZiku8ywkLRYJMl6H7wLFIXdQBw9hc/IOQ7YA/wT/HHlAH8iXraAiR
	 6Cmx5eYndE+24LlSHQ/9c6BfjoiK0NZdpuNbbJ9+RS7GxS80GcVztv/Yb6fz51oLjC
	 sX8CuC56rkIynbRWYb67OdPToT3o7nvIj/4n+Q7yfdppHFXfIBmGvO+5eVhMcyHUnU
	 wNn6NeKrVtUfA==
Date: Mon, 29 Sep 2025 09:59:13 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    "Penny, Zheng" , "Huang, Ray" , 
    "Daniel P. Smith" , 
    "xen-devel@lists.xenproject.org" , 
    "Stabellini, Stefano" , 
    "Andryuk, Jason" 
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: <0e72c63c-9a6b-4fd7-848d-8c8d09fc91ef@suse.com>
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-19-Penny.Zheng@amd.com>  
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@suse.com>   
  <0e72c63c-9a6b-4fd7-848d-8c8d09fc91ef@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 Sep 2025, Jan Beulich wrote:
> On 26.09.2025 21:24, Stefano Stabellini wrote:
> > On Thu, 25 Sep 2025, Penny, Zheng wrote:
> >>> -----Original Message-----
> >>> From: Jan Beulich 
> >>> Sent: Friday, September 26, 2025 2:53 PM
> >>> To: Penny, Zheng 
> >>> Cc: Huang, Ray ; Daniel P. Smith
> >>> ; xen-devel@lists.xenproject.org; Stabellini,
> >>> Stefano ; Andryuk, Jason
> >>> 
> >>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> >>> CONFIG_MGMT_HYPERCALLS
> >>>
> >>> On 26.09.2025 06:41, Penny, Zheng wrote:
> >>>>> -----Original Message-----
> >>>>> From: Jan Beulich 
> >>>>> Sent: Thursday, September 25, 2025 10:29 PM
> >>>>>
> >>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
> >>>>>>> -----Original Message-----
> >>>>>>> From: Jan Beulich 
> >>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
> >>>>>>>
> >>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
> >>>>>>>> --- a/xen/include/xsm/xsm.h
> >>>>>>>> +++ b/xen/include/xsm/xsm.h
> >>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> >>>>>>>>      void (*security_domaininfo)(struct domain *d,
> >>>>>>>>                                  struct xen_domctl_getdomaininfo *info);
> >>>>>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
> >>>>>>>> -    int (*getdomaininfo)(struct domain *d);
> >>>>>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
> >>>>>>>> +    int (*getdomaininfo)(struct domain *d);
> >>>>>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
> >>>>>>>>      int (*sysctl_scheduler_op)(int op);
> >>>>>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
> >>>>>>>> -234,7
> >>>>>>>> +234,11 @@ static inline int xsm_domain_create(
> >>>>>>>>
> >>>>>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
> >>>>>>>> domain
> >>>>>>>> *d)  {
> >>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> >>>>>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
> >>>>>>>> +#else
> >>>>>>>> +    return -EOPNOTSUPP;
> >>>>>>>> +#endif
> >>>>>>>>  }
> >>>>>>>
> >>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> >>>>>>> sysctl is hence already broken with the earlier series. Now the
> >>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> >>>>>>> really ought to extend to any operations available to other than the core
> >>> toolstack.
> >>>>>>> That's the Xenstore ones here, but also the ones used by qemu
> >>>>>>> (whether run in
> >>>>> Dom0 or a stubdom).
> >>>>>>
> >>>>>> Maybe not only limited to the core toolstack. In
> >>>>>> dom0less/hyperlaunched
> >>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
> >>>>> pvh machine type and with very restricted functionality(, only acting
> >>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> >>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
> >>> upstream?
> >>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
> >>>>>> requires
> >>>>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
> >>>>> how it was called in QEMU...
> >>>>>
> >>>>> It's not "it"; it's different ones. First and foremost I was thinking
> >>>>> of
> >>>>>  * XEN_DOMCTL_ioport_mapping
> >>>>>  * XEN_DOMCTL_memory_mapping
> >>>>>  * XEN_DOMCTL_bind_pt_irq
> >>>>>  * XEN_DOMCTL_unbind_pt_irq
> >>>>> but there may be others (albeit per the dummy xsm_domctl() this is
> >>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
> >>>>> checking can in principle be called by qemu.
> >>>>>
> >>>>
> >>>> Understood.
> >>>> I assume that they are all for device passthrough. We are not accepting device
> >>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> >>> developed device passthrough through device tree to only accept "static
> >>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> >>> internal , it may be the only accept way to do device passthrough in
> >>> dom0less/hyperlaunch-ed scenario.
> >>>
> >>> Right, but no matter what your goals, the upstream contributions need to be self-
> >>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> >>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> >>> them may be an option here.)
> >>
> >> Understood.
> >> I'll move them all to the dm-ops
> > 
> > Hi Penny, Jan, I advise against this.
> > 
> > I think it is clear that there are open questions on how to deal with
> > the safety scenarios. I briefly mentioned some of the issues last week
> > at Xen Summit. One example is the listdomains hypercall that should be
> > available to the control domain. We cannot resolve all problems with
> > this patch series. I think we should follow a simpler plan:
> > 
> > 1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
> >    removing all domctls and sysctls
> > 
> > 2) make further adjustments, such as making available the listdomains
> >    hypercall and/or the hypercalls listed by Jan as a second step after
> >    it
> 
> I'm going to be okay-ish with that as long as the help text of the Kconfig
> option clearly mentions those extra pitfalls.

+0


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 17:04:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 17:04:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133057.1471235 (Exim 4.92)
	(envelope-from )
	id 1v3HIf-0004fL-BU; Mon, 29 Sep 2025 17:04:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133057.1471235; Mon, 29 Sep 2025 17:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3HIf-0004fE-8p; Mon, 29 Sep 2025 17:04:33 +0000
Received: by outflank-mailman (input) for mailman id 1133057;
 Mon, 29 Sep 2025 17:04: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 1v3HId-0004f8-TS
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 17:04:31 +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 5bfffeb1-9d56-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 19:04:29 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id A874144F6E;
 Mon, 29 Sep 2025 17:04:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73FAEC4CEF4;
 Mon, 29 Sep 2025 17:04: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: 5bfffeb1-9d56-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759165467;
	bh=PTfUS9dphzeB1S5ixZ54Q1nWox4nNQPxHuDNoIHXjzU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TDo8OHGIUOOzF56rcmzqyVjjoOkzWUIPnSDZd4S9rZHDj+3k7ng94+nUFeWKbiEDQ
	 Z739UszNw1+dfbgzEVwp7xrfO5li1VBAepk2k9IicyPCXH4bKcjimFTcKjvWnwPeWm
	 j4riqOUxcRoNEEleEvaAzVZ+YwRTv2UmuB3Adoghrdh6lADLvVt2D3P9LKytcRRE2j
	 p3vEkw3RZ6GdtsPgZcnFEnMUCfJWtg7BdVmR12i8EytKyonHfYuiWwi3VNQJoUMHNg
	 qihKvvxyz0PgqrHIMj6hk8KxSpNO2z0R/XnFF8847IPSV2Y6m6RfePcsjNiosFigZf
	 ZwQ3MsEfJG0XQ==
Date: Mon, 29 Sep 2025 10:04:25 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stefano Stabellini 
cc: Jan Beulich , "Penny, Zheng" , 
    "Huang, Ray" , 
    "Daniel P. Smith" , 
    "xen-devel@lists.xenproject.org" , 
    "Stabellini, Stefano" , 
    "Andryuk, Jason" 
Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
 CONFIG_MGMT_HYPERCALLS
In-Reply-To: 
Message-ID: 
References: <20250910073827.3622177-1-Penny.Zheng@amd.com> <20250910073827.3622177-19-Penny.Zheng@amd.com>  
 <66b43c3b-c74f-4c18-b91a-bd7b56a62eff@suse.com>   
  <0e72c63c-9a6b-4fd7-848d-8c8d09fc91ef@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, 29 Sep 2025, Stefano Stabellini wrote:
> On Sun, 28 Sep 2025, Jan Beulich wrote:
> > On 26.09.2025 21:24, Stefano Stabellini wrote:
> > > On Thu, 25 Sep 2025, Penny, Zheng wrote:
> > >>> -----Original Message-----
> > >>> From: Jan Beulich 
> > >>> Sent: Friday, September 26, 2025 2:53 PM
> > >>> To: Penny, Zheng 
> > >>> Cc: Huang, Ray ; Daniel P. Smith
> > >>> ; xen-devel@lists.xenproject.org; Stabellini,
> > >>> Stefano ; Andryuk, Jason
> > >>> 
> > >>> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with
> > >>> CONFIG_MGMT_HYPERCALLS
> > >>>
> > >>> On 26.09.2025 06:41, Penny, Zheng wrote:
> > >>>>> -----Original Message-----
> > >>>>> From: Jan Beulich 
> > >>>>> Sent: Thursday, September 25, 2025 10:29 PM
> > >>>>>
> > >>>>> On 25.09.2025 11:41, Penny, Zheng wrote:
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Jan Beulich 
> > >>>>>>> Sent: Thursday, September 11, 2025 9:30 PM
> > >>>>>>>
> > >>>>>>> On 10.09.2025 09:38, Penny Zheng wrote:
> > >>>>>>>> --- a/xen/include/xsm/xsm.h
> > >>>>>>>> +++ b/xen/include/xsm/xsm.h
> > >>>>>>>> @@ -55,8 +55,8 @@ struct xsm_ops {
> > >>>>>>>>      void (*security_domaininfo)(struct domain *d,
> > >>>>>>>>                                  struct xen_domctl_getdomaininfo *info);
> > >>>>>>>>      int (*domain_create)(struct domain *d, uint32_t ssidref);
> > >>>>>>>> -    int (*getdomaininfo)(struct domain *d);
> > >>>>>>>>  #ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>>>>> +    int (*getdomaininfo)(struct domain *d);
> > >>>>>>>>      int (*domctl_scheduler_op)(struct domain *d, int op);
> > >>>>>>>>      int (*sysctl_scheduler_op)(int op);
> > >>>>>>>>      int (*set_target)(struct domain *d, struct domain *e); @@
> > >>>>>>>> -234,7
> > >>>>>>>> +234,11 @@ static inline int xsm_domain_create(
> > >>>>>>>>
> > >>>>>>>>  static inline int xsm_getdomaininfo(xsm_default_t def, struct
> > >>>>>>>> domain
> > >>>>>>>> *d)  {
> > >>>>>>>> +#ifdef CONFIG_MGMT_HYPERCALLS
> > >>>>>>>>      return alternative_call(xsm_ops.getdomaininfo, d);
> > >>>>>>>> +#else
> > >>>>>>>> +    return -EOPNOTSUPP;
> > >>>>>>>> +#endif
> > >>>>>>>>  }
> > >>>>>>>
> > >>>>>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The
> > >>>>>>> sysctl is hence already broken with the earlier series. Now the
> > >>>>>>> domctl is also being screwed up. I don't think MGMT_HYPERCALLS
> > >>>>>>> really ought to extend to any operations available to other than the core
> > >>> toolstack.
> > >>>>>>> That's the Xenstore ones here, but also the ones used by qemu
> > >>>>>>> (whether run in
> > >>>>> Dom0 or a stubdom).
> > >>>>>>
> > >>>>>> Maybe not only limited to the core toolstack. In
> > >>>>>> dom0less/hyperlaunched
> > >>>>> scenarios, hypercalls are strictly limited. QEMU is also limited to
> > >>>>> pvh machine type and with very restricted functionality(, only acting
> > >>>>> as a few virtio-pci devices backend). @Andryuk, Jason @Stabellini,
> > >>>>> Stefano Am I understanding correctly and thoroughly about our scenario here for
> > >>> upstream?
> > >>>>>> Tracking the codes, if Xenstore is created as a stub domain, it
> > >>>>>> requires
> > >>>>> getdomaininfo-domctl to acquire related info.  Sorry, I haven't found
> > >>>>> how it was called in QEMU...
> > >>>>>
> > >>>>> It's not "it"; it's different ones. First and foremost I was thinking
> > >>>>> of
> > >>>>>  * XEN_DOMCTL_ioport_mapping
> > >>>>>  * XEN_DOMCTL_memory_mapping
> > >>>>>  * XEN_DOMCTL_bind_pt_irq
> > >>>>>  * XEN_DOMCTL_unbind_pt_irq
> > >>>>> but there may be others (albeit per the dummy xsm_domctl() this is
> > >>>>> the full set). As a general criteria, anything using XSM_DM_PRIV
> > >>>>> checking can in principle be called by qemu.
> > >>>>>
> > >>>>
> > >>>> Understood.
> > >>>> I assume that they are all for device passthrough. We are not accepting device
> > >>> passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. Jason has
> > >>> developed device passthrough through device tree to only accept "static
> > >>> configured" passthrough in dom0less/hyperlaunch-ed scenario, while it is still
> > >>> internal , it may be the only accept way to do device passthrough in
> > >>> dom0less/hyperlaunch-ed scenario.
> > >>>
> > >>> Right, but no matter what your goals, the upstream contributions need to be self-
> > >>> consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s
> > >>> mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving
> > >>> them may be an option here.)
> > >>
> > >> Understood.
> > >> I'll move them all to the dm-ops
> > > 
> > > Hi Penny, Jan, I advise against this.
> > > 
> > > I think it is clear that there are open questions on how to deal with
> > > the safety scenarios. I briefly mentioned some of the issues last week
> > > at Xen Summit. One example is the listdomains hypercall that should be
> > > available to the control domain. We cannot resolve all problems with
> > > this patch series. I think we should follow a simpler plan:
> > > 
> > > 1) introduce CONFIG_MGMT_HYPERCALLS the way this patch series does,
> > >    removing all domctls and sysctls
> > > 
> > > 2) make further adjustments, such as making available the listdomains
> > >    hypercall and/or the hypercalls listed by Jan as a second step after
> > >    it
> > 
> > I'm going to be okay-ish with that as long as the help text of the Kconfig
> > option clearly mentions those extra pitfalls.
> 
> +0

Ahah I mistyped this :-)

I meant +1 in the sense that I am happy with the idea of kconfig clearly
mentioning the pitfalls.


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 17:38:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 17:38:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133078.1471250 (Exim 4.92)
	(envelope-from )
	id 1v3Hp8-0000aY-Ti; Mon, 29 Sep 2025 17:38:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133078.1471250; Mon, 29 Sep 2025 17:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Hp8-0000aR-QJ; Mon, 29 Sep 2025 17:38:06 +0000
Received: by outflank-mailman (input) for mailman id 1133078;
 Mon, 29 Sep 2025 17:38: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 1v3Hp8-0000aL-7Y
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 17:38:06 +0000
Received: from BL2PR02CU003.outbound.protection.outlook.com
 (mail-eastusazlp17011000f.outbound.protection.outlook.com
 [2a01:111:f403:c100::f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ca63d9c-9d5b-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 19:38:03 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by MN0PR12MB5907.namprd12.prod.outlook.com (2603:10b6:208:37b::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 17:37:59 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 17: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: 0ca63d9c-9d5b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VDMq2CCp47es7DyBodDVrWytMKZpwCQFk2Upq+ibY6VHKMNVJcLlZk1YiCwiWqg5Owbnn6aZe9VxpxbcdwrzEZjql2rsjgi9IOnWU3r+S7vQvsEuakSPIE2FIRsRbS/tXvUxo2vEEFfubGSToS9BX+CHrmrXY9zRQnJcrnCRdhaWeg1Hid5eCfcC/ztb0EGdVJh2hIAxbxUSLry3jPuaCHJbmI6nV/wIcCM6JLSWDzSWVMADLBvklCTeTUBT4+kmyuRQkQe6xT6cxVd+MTCTJhYxhSVEzEydIgE9zBtCDoAwPI2GoEnG24/lbeMoSL+6s0ov/hLiqYDUvHcF4KpK4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oF74VPPHEjE4XwB3q2M/KfcPnKwJHc3I0+qZKMETvzc=;
 b=cVPIKQtrY48PU5KyqdAtcBDW+MBO5Qrz8HtlwkwbBdcxcJnKBVxYlWfPEbuWgSJJf2LNA5Qf4eOTvblsU74xKnG6Tq0s1R9xvQcGgZylofZXwEGKj+AN3DlCb+wL1yeWYaNVxMYwKxt660yeimclFZ9aQEOim66H11/yvk8wYt35atPhLsgtL18ysIYR4Lep+RBpIHpaNviojL8A7Baxsz4G5oBrU2SR58LfzxLL1m5Gy1Wf9wjPfua4x6cbOvKK8UXGYNKa2zU0HoUK5ymiiPyKcCcrvphuPOFZetFMcoE1THwngTFTTLVbmyVdNNr9g4EQUFVF2to1w83n6ZfejQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oF74VPPHEjE4XwB3q2M/KfcPnKwJHc3I0+qZKMETvzc=;
 b=c0FHlgizpouPngbGDaY4VL8cFyf1plkNlhUa6xga9MsMHO1LL37bgsoOzhG9P9uGmtwUmGCYUfe5bSiWzlVFgyZujNB+SelNeb0Jmhed9XwcteD8b8dfyyRQKYFTjeNuhc46+oZaVTNKIsUdej7aymOExNM/MyoINUgeaR2n+34xu2911UpvLW/dyy01XdvpY7cGtyj3Il15wktMQYF4JFtAcOnSPXGKSDdxpGqa2CZiAVdJ6bmTMDHN1xbqup8bRODCLRA8Bx561EzCWSjzwTfcS3Bx4RiCqVCIBPg63ZEp8oymSu47a8NLry8c2cbiqVY77N3hkCLEsRuvRL3S9Q==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Mon, 29 Sep 2025 14:37:55 -0300
From: Jason Gunthorpe 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Leon Romanovsky , iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 3/6] ARM: dma-mapping: Reduce struct page exposure in
 arch_sync_dma*()
Message-ID: <20250929173755.GD2942991@nvidia.com>
References: 
 <2f20069c2b616808c034ba4e75905820b94e0e22.1758203802.git.leon@kernel.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2f20069c2b616808c034ba4e75905820b94e0e22.1758203802.git.leon@kernel.org>
X-ClientProxiedBy: BLAPR03CA0075.namprd03.prod.outlook.com
 (2603:10b6:208:329::20) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|MN0PR12MB5907:EE_
X-MS-Office365-Filtering-Correlation-Id: e67072d2-7f07-4cfb-5634-08ddff7eedbb
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:
	=?us-ascii?Q?tpSBc9tfMjdSjmNhAiZRDTRAak5b7gvEIu1hS5TSV2mXP926e8a/UVjVn4D3?=
 =?us-ascii?Q?nPHjK08pgo3G0wFlCvw0IepJMcXZoLnaqcQZ/V+QozWBJjvH1mVq4gQt8qDs?=
 =?us-ascii?Q?9Sh0HYUJfEc7t4j8oexxXqI5XAH5npPvnl8N2HszXQh9tdY1aDBXtgDuWc5i?=
 =?us-ascii?Q?/uDOLASgMpQiGslQ0Ev2d1xOPgImuysmnO6hk4uYlT58xrFaDrn94vRMlBN+?=
 =?us-ascii?Q?GqcISxIuRNqHFdh15HGFPvsFVHAM1kqlGusRU416xEaFMFtUKLP0eAy/k+Ah?=
 =?us-ascii?Q?bQg2r+bXGt9QsTpNAoj0jtdUXeQeJvtnBV9QrrVdtZuhaazxd/XTVVOx2O0s?=
 =?us-ascii?Q?qMhGOPLPwJkMrfeJH+r8A1uyhxGc9dFwchah5yAFkl3XZWiy1yCvC8JqHhNW?=
 =?us-ascii?Q?JpdsGna+V+HcROgFJLyszqiSt8C1R26LpbldSdULISBFu8/yj3T3kR0KLDd5?=
 =?us-ascii?Q?HhnWv9QADIQ/mAJ+jtzBYDu2YUakz6iJXut4klcCya6dltAT/X9TmQt7NdWl?=
 =?us-ascii?Q?PaO9oLFb9EcmebxftlM6FNUG2xx3KNMmdtRshcfx9UuzrUo1EWbKPgAeLqct?=
 =?us-ascii?Q?3LZOtfMQgv5EoqkdKfZUkaNBdN9f48FPa9XvT3p8zzxAKNg+0qbRMi+r+iRB?=
 =?us-ascii?Q?04kD8rJ7H6i37hHhC1rLRZ/2t4GvHaDgrk58AHCzLSV2NY8OavN9HIGerjyr?=
 =?us-ascii?Q?6aU4SyaXQijxifse6LB/n29PIFovBr8vF2GizomdHoR16Y4GkdMtXYb4EcRl?=
 =?us-ascii?Q?i4vn3DdqMkYkKAcm8Q3wa3mWvVDRRMUFvEISKwfXmr1FsPh2+LbqtBCzevjZ?=
 =?us-ascii?Q?bgYRpJgBJ2/1gGVcF2e5MqAkuzn9VZSd/x0JYlJ2AJ7gn98zun/kwK6MouvJ?=
 =?us-ascii?Q?ZwAD2AyJ9cnK8hLUU+C1XNB77S8r2/vFYP6NdxwhyxsxaWJ4JcL2ZzzCmn3b?=
 =?us-ascii?Q?pfAfbZiLKPdipuVF0JdDtLeot38E9ZlRtm77d9zTQC6UwX1RcIBVaDY2EXab?=
 =?us-ascii?Q?ZO/y7tVUTZOiikK/CbQsvKQfU2RDJKH2TBscK2I4rjVvdc1qFCKsdb50jIvO?=
 =?us-ascii?Q?8aQIuViiYTBaW/XWvGrgv8Fgikp82zbBlUsmR3j7nENgYf3v8Qy5oP8CRiJ2?=
 =?us-ascii?Q?GPUGxSTBheHNMV7wmHEor9Zi/eahIbS2eGr9gHELyjgx+hRWK+/kHh5QwimC?=
 =?us-ascii?Q?OMvL5xsZJX0Xh3rluae9q4iKZCUFrV4S97Giz5/uaJK3NRjoGw6ujQvlVwVW?=
 =?us-ascii?Q?B9G55mXZcAKCwGhK9frdkUJuXGxWE1cQ1TC55aedr6uqCcQ0PFViLN90016N?=
 =?us-ascii?Q?X/+sdCUTh7AuK/19OtwtJWKDl0jVAs9eo/wk/ViKT1bImD205CdsxkQ7pFG0?=
 =?us-ascii?Q?RiqZkc/chsIyjWO0v2kZKJpRlUWr/zTJjBHLEsiTGOpJl1wkDMffyQgeTkfi?=
 =?us-ascii?Q?z2vv6FB19hwj9M/Pzr4P8Joc+WeoKwzA?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.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:
	=?us-ascii?Q?OXqqvf5Wg1hkvjCceFkQsx3qwL0XN8hegrU1q2jK3v3N5wyqGihj3CXVnGpz?=
 =?us-ascii?Q?ZlA59uFHqhDEsrYVOYWGly+BhdVxpJoK5vsxCIPRwWtMr1wgG8vHpBBTwBFn?=
 =?us-ascii?Q?SUE5kCXkgwh4YUJTC7RmgBZUsr2dBr1a3ltjAVws4HchX3WwfCRsFtHtXge/?=
 =?us-ascii?Q?ALRlCU8VHfIrk9WZjaUDdq/ZWq4sB3XZKznAlObtHz5XJzcEBum+kymcblds?=
 =?us-ascii?Q?QOZjlZFiiSYDtdgws668HDXNOrjdwIWjot2M/aVqy9hT1q9cfFN8K1DmJ9wV?=
 =?us-ascii?Q?r0iDVvwqa8kPyZFl/RqgIvgCaxPgT0DL9tyzPiNt6+dJCB9almdMwpMy8zVN?=
 =?us-ascii?Q?bj524rT6MBSYK8H/SeqP2HlhWjjRlwe8uO57jsUXey1XvS8ofhP5S9N25vOJ?=
 =?us-ascii?Q?0VyyZHbCU0X9udZh1wsztzQEsfLwfXkyxZ9c/ge8h49op0Vy6IqpepJ3GBaW?=
 =?us-ascii?Q?IYueIvAMZUoOsrPOiYhQzTpb73OpCAacZoQUnidquFyHTlrR3L164l2wLoUF?=
 =?us-ascii?Q?qqhuEKe0UbJvRU1dy1tU48TYtldPZlORl8LFcnXSG7eKzJJOe5lsAM//SyZI?=
 =?us-ascii?Q?YM/yZKgz14CC9LPPitWsdms7S1R9FebupyUNU3BCYSLoVNSgLUfc+a2GJWAo?=
 =?us-ascii?Q?IxwtIXkOlPWMCk3ZlU6A7e/uroE5aditPmHlRILY/u6Aum/Z6p0qPeU+J/Fn?=
 =?us-ascii?Q?Oae6YCXfCy788MkZjCrYJkNfnAbd8QZdSlOyKckZJRmfCeOTPQsZWlwk7HsV?=
 =?us-ascii?Q?BsUJ63NFEtTJ/IX1RsmNWfM4Rp3L+9dhYF6qGl2kRYobv6V2kj7Si4Zfh1hW?=
 =?us-ascii?Q?FW13bKpNtl3QxYl5hj63hsAGoTpco+WyypWG91mPODjwzhzEMWefS9d4sQ+O?=
 =?us-ascii?Q?+TUkFGoLpnZeeXC7LnEIG53kjA8FvZzTFEQbKhtRFdQKtnU0Rvc7BJhdE1A9?=
 =?us-ascii?Q?OziqaZvQpMP9D36OdcXQ4rAaglS7BZtRGrS3dUcfZQthiQ/1a43yiQ7P0vKK?=
 =?us-ascii?Q?iqZsLwH3XTtl2BQMxrYH6FLZhC27XgUpaT7NeLhI6Lhzu0/PcEi83JU5rMTk?=
 =?us-ascii?Q?W+vfnHd9BbxrVF8ITJuckFJl8JIrxsZkTosC0et6VjgHAjHYSoI0+sEe3rTX?=
 =?us-ascii?Q?cDAxOV3sWJnu40a6Pqc/0q7eg7mvRkkgRcrPSiW1tUB680PNpKE2gl1Mk/7J?=
 =?us-ascii?Q?ibq8kkL7GV4eL9EQ6D2Pm0YxG0QvKGSQ383iSiwSXc06UUQQrS+o8w59B3N2?=
 =?us-ascii?Q?XLYIwLYhL9eKkjms5YC2USlVVWdWTwW6pGNwRwJ+2qAuYFDjZXB82sHZCrGD?=
 =?us-ascii?Q?ADBOHDc477IlQuNPgV7Ogd+XOG3+yfGE30Kry2ojr51SZc1iy9K/IMOK+SJd?=
 =?us-ascii?Q?1U+esNcQ1BmzwOKZUXUOJp+Lm812wtduGxfHFK7EWeddQYO9ljGDQLAw8OPQ?=
 =?us-ascii?Q?PPihGidCyLhXiK6ytg9nbkofrePm+4z7kLPv6a9Qu/Vjw4zO3Vi9eHAmdDul?=
 =?us-ascii?Q?ZjieX1PhWvQeNvnkzrU7L/IMrry1+ct8hEJZOumBrmT6uTuMogLcTQyGgrRh?=
 =?us-ascii?Q?MerEJkZGzY5zr4QGB5XTN0B33/sD5ao+a1Giqtzr?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e67072d2-7f07-4cfb-5634-08ddff7eedbb
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2025 17:37:57.8585
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: PjbfPMXm/K6Pv13Dx14ay3arFUwSi+Hnt6H763AyJRqGyJ4SyYrg7WPr9UdQ3XP8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5907

On Thu, Sep 18, 2025 at 05:09:26PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky 
> 
> As a preparation to changing from .map_page to use .map_phys DMA
> callbacks, convert arch_sync_dma*() functions to use physical addresses
> instead of struct page.
> 
> Signed-off-by: Leon Romanovsky 
> ---
>  arch/arm/mm/dma-mapping.c | 82 +++++++++++++++------------------------
>  1 file changed, 31 insertions(+), 51 deletions(-)

Reviewed-by: Jason Gunthorpe 

Jason


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 17:39:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 17:39:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133085.1471260 (Exim 4.92)
	(envelope-from )
	id 1v3Hqc-00015q-6x; Mon, 29 Sep 2025 17:39:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133085.1471260; Mon, 29 Sep 2025 17:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Hqc-00015j-3h; Mon, 29 Sep 2025 17:39:38 +0000
Received: by outflank-mailman (input) for mailman id 1133085;
 Mon, 29 Sep 2025 17:39: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 1v3Hqb-00015c-4Y
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 17:39:37 +0000
Received: from SJ2PR03CU001.outbound.protection.outlook.com
 (mail-westusazlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c001::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 420b3dc4-9d5b-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 19:39:35 +0200 (CEST)
Received: from PH7PR12MB5757.namprd12.prod.outlook.com (2603:10b6:510:1d0::13)
 by MN0PR12MB5907.namprd12.prod.outlook.com (2603:10b6:208:37b::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 17:39:27 +0000
Received: from PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632]) by PH7PR12MB5757.namprd12.prod.outlook.com
 ([fe80::f012:300c:6bf4:7632%2]) with mapi id 15.20.9160.014; Mon, 29 Sep 2025
 17:39: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: 420b3dc4-9d5b-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mKc/qv1PHUlSvIUO4I+jwJm3cPT6XA/RSAY1rBvYjyMAogQhQdTuXqDhOLaibKU2Ca5DxJQ8Km7uYanbcbTyuHsaU/D93DTWb0LwffJizSwvG7H14BjsEnhKzNcRNcVyYBFRjLV4QJ8fdSdiXKg0aHAIsB8rDE0RAPXv++p8Vg7FNVpoXvKDRcH26djNrkd7ltQlJ7fFrdojTz5f8s4IjV+t7huEzz3JFbcL3iA6XEifAxE0DnG58x8v+JfIB8/2m7XvKqfHoQh+I+NqP0Sw1FuT++/aIINwLYw/c6gXQkiiMGIYr38cpUm1KWymtqEOaXv2m2aofQaJZOAaJeNZPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OtRdpiMoQ/tJHwKBwA1fxlbmM4w3B3EJ5OtppZVIkf8=;
 b=UVATGIIfRig/fYRMucdFAoZHU7QvFa0ONuV3jFRCXxo9AMq74ZQpsm4+sm5aQWTs83HGJlCtDnREnWBFFmE5jG9wGGy2gggPZEzDFMPx7YYpJEkoLjUR0m/LnVNpPuAjI9ixRc+GSg5CrytvHWk0/M6+3I9LJ9W7jLXDoAuDoPvBQBFGzo4zoVXDZ5pxujjB701u+gLfJu6j+N9b2IY5149f4jR/odjeGCCfWo9tmujWpqRQr6qNEocKEhcZM1nSDf9dhtoL+z3l0aOOEU1rM+86Z6Fdq9SU5e0rlf1LsJuVQk9iHI7JYwF7jpARF+p4vXHoRXTHMPuG1pwqHKMneA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OtRdpiMoQ/tJHwKBwA1fxlbmM4w3B3EJ5OtppZVIkf8=;
 b=n5cXzyNvCDy7Px8SNfUf3cmoMpzFp+WqGN5GlTokiNn1ZUR1GRrvcND5z4FOytPgmqJkayuxnD0UqsP8CBQ4Ze1wIBb5V++u5+HhP4dV3TqKBJlLdUrqYvvFhCkfrhn/wOoSWzVGSgeS3KtpFcEs5ZZXxVspDhKK0GbYuYCiQlj33GU1eQ/YadqYsWusblpk8YeQzUKEJOKjo0AEetHNqn/uE38uum6BSKGZbvVnBl3c+JDgmoCz2tozt0Zw1wuLSptorcTzAIYv7nUVLt1N4C6d23AKLlpi3VSpNA+vcvFFC+6HtcwuWFV0mU3V5h7ddKIgTasycaunBk355Fz2Rw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Date: Mon, 29 Sep 2025 14:39:25 -0300
From: Jason Gunthorpe 
To: Leon Romanovsky 
Cc: Marek Szyprowski ,
	Leon Romanovsky , iommu@lists.linux.dev,
	Juergen Gross ,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	Russell King ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 5/6] xen: swiotlb: Switch to physical address mapping
 callbacks
Message-ID: <20250929173925.GE2942991@nvidia.com>
References: 
 <997c0122a24c355b4d7ee353902041a7617f4c9e.1758203802.git.leon@kernel.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <997c0122a24c355b4d7ee353902041a7617f4c9e.1758203802.git.leon@kernel.org>
X-ClientProxiedBy: BL1PR13CA0178.namprd13.prod.outlook.com
 (2603:10b6:208:2bd::33) To PH7PR12MB5757.namprd12.prod.outlook.com
 (2603:10b6:510:1d0::13)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5757:EE_|MN0PR12MB5907:EE_
X-MS-Office365-Filtering-Correlation-Id: 605daae0-2b76-4ed3-34b7-08ddff7f2313
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:
	=?us-ascii?Q?bGzBX2cj3doO9BU9QyqzXAIwDAIogWi/hJkGlkKjl41FPbJmR5hKsYj6x5X9?=
 =?us-ascii?Q?warEZs31R/7kBj5vdtooWW0H3fppFR/bhH5R2UR6pUi2Dd7V1+0LnXqYlzZE?=
 =?us-ascii?Q?ycjAWMHt704VouS8nvg25oPOnfCVerUPi/iyofCUk2Scpsn+r1PKo9NgGYGx?=
 =?us-ascii?Q?WpmyfWmdTt3O9TCatd1110egkbghC7KlnQOlYMB2RDTo0jVWjrvcx8K+Toh+?=
 =?us-ascii?Q?R29GOxDt9MDRXzNsI7zNONNvkjdlDFEcHaDZDxM5TNutac2FXKfxdLuhFMtH?=
 =?us-ascii?Q?3LLzvsB3s8pJX7qCYr/tB7t+mzYyKn1s6SW8aCFxkAiSYtDZ8WjO+VGZzyGe?=
 =?us-ascii?Q?G8IY2teTUUHFNTO4mW3NT0R/XyXGj6wkDAlzRr3ComhwGb6hgomi8uLJXxpI?=
 =?us-ascii?Q?aaVQEutfQYggWHjdNBHCAdX0vx49dLkYSm4aTNDGwmfLlUaUqyPLyg71yhME?=
 =?us-ascii?Q?s3KZ2hT+wIhWXBe+EANv/WreLsW0ohdubuC/rvk9Re9AMMtJfKCalBqZp3Eg?=
 =?us-ascii?Q?9zAMwCYdJEh3mVshs7EEjFpKQKyc76+DuMSoU6e7OS6hKwCmuXuuMY/Q3ZDO?=
 =?us-ascii?Q?POIHElQnxhhguvVQ+XSm+4QqP7I5a5SjjkYiYw3eU20ZrpghWiZrPpm8CZ02?=
 =?us-ascii?Q?+tOx4zoc5PZdLNYUQLEFp+OiFmDgDC8VGqz/k7oT2a1lVk4ukSha4bbtAGL/?=
 =?us-ascii?Q?fcYFHQDowa7+QJfTKlaCEe57KEBLFJkgLxjGBMJZ8pesOx7F6NY8FJx5d0YR?=
 =?us-ascii?Q?afEAb/nKm8q+ojvj3oTVOYi26N5PG91XIOJc2AyKhme25xGKVnSCCX7LhRK9?=
 =?us-ascii?Q?Dk8ZYqpGlS5YfiGGPFVT0x9HHmFoZ8o/oQ2wdAmQBzEtrOVOXrR6nfFfJnVy?=
 =?us-ascii?Q?ya2IvefD8W6hpgaOn0KyXPi7igPSUbitkpSnCs6AUxmYWRvQOlj5grnbxfJ+?=
 =?us-ascii?Q?R9ml+igG1iHoD3KYtXHs7rzmR7T2QxBkHqbqX8nBqGvutbzXeLFSAV4ip14F?=
 =?us-ascii?Q?j6Zo2V/1TnEvLDlwWyfvBxe+4XxoKdgM9UQLcuYfxejHU1yQvltNpaFTfefs?=
 =?us-ascii?Q?+MZCPYi7vnKYHPpVXV3bag+PYr6cKwBCRXQhXGu2TihrA9bs6UtqRXnd/0qm?=
 =?us-ascii?Q?XAVlqLpIzqhJQCvVbVpDTbLtdySCsJkszBz72W0O1y2MtIzfsxjhdhgOCQix?=
 =?us-ascii?Q?1jdHI8RIlPt47b0jAf1yGAVHISW7iOcw1RfmzGTA5j9YpfTuHrZmUEW69UDK?=
 =?us-ascii?Q?UYZnMfAULwNuVdGbHM53oYRMIyo4bbLfCPJzvXtz61OZcWzEzwYZK8NO8ugu?=
 =?us-ascii?Q?VBC/QD6R3rQzRkqnsPcJ2mEx+npiAQUMVUUHwawOH61uXmTnjNvjslkOzaHN?=
 =?us-ascii?Q?hMTzYpcHCMTs3eEhoCBMqvr9rcjKMbhYgYrQk+sx8bLmjHYB9dxMMR47rAuJ?=
 =?us-ascii?Q?7RwWACByhXUqROerjJl3rGMDUrm1ubo6?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5757.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:
	=?us-ascii?Q?7rw8PttBxy94nlK24vGIyBMo2iARMNMsxMaKZNG70lQxEWpMwSo0FxrN28xC?=
 =?us-ascii?Q?Kk7hUJz4HAlL41FkLJuYtBT9nrU/yWYZ1q03Khm07pkNY9x2TuZSgrRy8hFj?=
 =?us-ascii?Q?13jX917d5RNi+JjDClq371iEvDDgwBxMIM6TJoixeRt0Er4ZIWSHL0MrVN1L?=
 =?us-ascii?Q?m4zlEEs/bQKuc3icfoHWnb7zm7KlqjAu4mEG/GcsGVbIFOzjyJtSwfBV+vBW?=
 =?us-ascii?Q?2brXJJKXjSL4VMpMdZacmDJAaSUJTKn7jQFJaAsNLXEG7MGthif7nyhveHqA?=
 =?us-ascii?Q?sU6Eb6Ff54dUKlSZP9QuQqip8/Tf8Dc9UNOdGfeMN1fzGSZETCFHGwuO+sd0?=
 =?us-ascii?Q?bW1Fr11t36rydIkvA/9IUoxE7LxBYSosMln4eDYB5ws76gZ9GqZNBuFfeqYU?=
 =?us-ascii?Q?rMglwCiH18wSvd3b0bD0CVCTPtj4HK1K+207QEAp42dF/a7OuP22i+lND53U?=
 =?us-ascii?Q?cSCGdn9X1wF0oECl/liUExs2MOU4vg7uN0wBj83Wyj98J0YVyZXj4+OcbbFj?=
 =?us-ascii?Q?83sBJewNhhvQSSzdEQw2sts0eK861xB7xZ+SxLH5KKV9flPj6/TLY5R1wMBn?=
 =?us-ascii?Q?oMVonn9vLfL7iwPjt/kOt0S2IYTxMEZ4SMDQHK24Qhw68rIlaO9B6tnvyvjq?=
 =?us-ascii?Q?Xsu9fiW5VNSqxyUteYdI2panohxblwcp/BOI1e7HOcIB6ab/LS5KddiNU5Lq?=
 =?us-ascii?Q?ktj41SxcxTjpBkvAdQfZ0vZWUuTqkCwHpni8AJD0uc0Cr9jYGcySV9X1FHRT?=
 =?us-ascii?Q?gSISzKg/ynhcRWxk87QP1h5yt8ehBt1hJVBhktDUIKOG1dInFEARrU8oMgu0?=
 =?us-ascii?Q?Mdn7LDqFIh0gU/Jz3BMHhEGEz0FcVkzLeLWXkYzQiMDdAAPX837me5Mp/H7b?=
 =?us-ascii?Q?b5XCOdkSA5OfGq0h2F4Lsy0V17qqFSFkOHnIQb+bOKHJfDTptMWWuwOcPMvh?=
 =?us-ascii?Q?XZjpu3NFzMkMjMvHHKpY2GHnWTfDRWR+UJFq8NO07wfIKzqx123cBw7KECvm?=
 =?us-ascii?Q?8vd92TAZbFA7zHfs6A37+BlDUi4FdWWKauwYnh1AnY8z+B4Y501i0CgthIe0?=
 =?us-ascii?Q?vgDGwz+gbZRNCBE0GmNK/TtCf+QBeE+3IaFKf+IkOZJFuWuKKNDX6MWrr6Nn?=
 =?us-ascii?Q?KKvXjZSssDNxlYm4BGkAhGLdQ9xQfvhNCvFHalM4z6p+tFiVPE3f9EHlDDtR?=
 =?us-ascii?Q?oloVJTe3euWx9bF/tjqKPLdJ9dvpF02yQCiDC0mm7JnejSAjyfQ4fayzpUrr?=
 =?us-ascii?Q?w18IGYPPnniFg0EVG0tgt6YJ4EoBBf4QOuUS8InejOwHLZCQWH6dTCd5aWEC?=
 =?us-ascii?Q?wonTGW7DzVB2ztVa5QmrynjJxL0ckjOCUs/ouuhPyOusaSUMkkceFwrZc1er?=
 =?us-ascii?Q?YJhHQyYRDWBPqlHPemX1tbqgTkE/tqJzk2BHzz7vWAaSOibjCZXaN0TTVpZr?=
 =?us-ascii?Q?ph/wmz1blWVkRQaVXCTcE5Fjc+nOER30otwN5Bw85BV9ieXSCAq6eGspr4qz?=
 =?us-ascii?Q?03cqAZcF6Omsc6RgU789hJLY85tPJjId2DKfIntwX08ujHQG1sEtObOOWI9J?=
 =?us-ascii?Q?jb6+Z3t3INWB+/CG5rRWwRUKiXlnGYu1l2SPbWM9?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 605daae0-2b76-4ed3-34b7-08ddff7f2313
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5757.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2025 17:39:27.2572
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: F+hl7cBcv0F7z+opKl0LDt4UKsqiFSGQLrARsSse/0f/CdHu0PKCQxz+f8b4Qj1N
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5907

On Thu, Sep 18, 2025 at 05:09:28PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky 
> 
> Combine resource and page mappings routines to one function
> and remove .map_resource/.unmap_resource callbacks completely.
> 
> Signed-off-by: Leon Romanovsky 
> ---
>  drivers/xen/swiotlb-xen.c | 63 ++++++++++++++++++---------------------
>  1 file changed, 29 insertions(+), 34 deletions(-)

Reviewed-by: Jason Gunthorpe 

Jason


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:08:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133102.1471271 (Exim 4.92)
	(envelope-from )
	id 1v3IHz-0005K5-Fv; Mon, 29 Sep 2025 18:07:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133102.1471271; Mon, 29 Sep 2025 18:07: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 1v3IHz-0005Jy-B5; Mon, 29 Sep 2025 18:07:55 +0000
Received: by outflank-mailman (input) for mailman id 1133102;
 Mon, 29 Sep 2025 18:07:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3IHx-0005Jq-MK
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:07:53 +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 370e2d1f-9d5f-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:07:52 +0200 (CEST)
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20)
 by AS4PR03MB8178.eurprd03.prod.outlook.com (2603:10a6:20b:4e1::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Mon, 29 Sep
 2025 18:07:47 +0000
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 18:07: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: 370e2d1f-9d5f-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qdQdBKITWl2CIakQ7427m3dDltjk4Hi0flKXkpc1ZdVHn75ugaamKblB3aa1hlbJePP+a9nICgVAEyBQynBbKb/NTlhI4cEP29F7gzwzmhbdKSQk2PQJeRGrtIKPRL5rbC0gwy9AV4k8Jh20R4YtU9DkYH8b+90HK0BuO3ZCkYgrJZcSjyPXUk5K+NypHRwdC/bacmnaLJUxtkM4m7ZmQiRUz/2BHn0B8Ak5HaqjzEI/eOUqDrbGwuuBZkOY+/XpL6OsyzMRzmvkPXytVkKWUfBxmRAUe8VlS1obf/z0tUul7+MTYHUwkrQZTzgm9Yi0TzxMZDESC2JSzW9xfVsXhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lmz8ihFsTa28eFIIcZV7gRXPLn+VRuXAh5/gDPWy9GU=;
 b=Cev/IWnJtT719yQHI9XIhXEzrTR5UyfXELP/dXddmCXMmD8otyk4wa2I3WzOdmR4oPKSEvSH14O1g5CxvsJpNCzWnYHxwcSoxm8ng49zSG2hmB4ACjjgKubgThzke3W4Ty+J9A8cXknLOC5y6QvAWuMTxXTeSYkMlHE/u9BLcG1sD4CyfQj7FK2xk7DV5Rk2eKRpNg6KRLDcrf4TM2JrRMmK471lf+EzNtscGbhScV/CuZyQ/Vy4l6R8LyZXO3bTBrOX2nT1YfLC3jkD7v5hxpmXMhBE/Y3+aywbTDnC5yDRN9TqHOKXGNXRcvtmVIUi3gWY8+jJ1AWOXeT/s2F05A==
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=lmz8ihFsTa28eFIIcZV7gRXPLn+VRuXAh5/gDPWy9GU=;
 b=PA8j063y4ZULV5Vz/d3p9xihuC94g6fia9PsVDaNoT+A4VpV639Yl0gRS8ddGy4/kexkFD+Wp6104qPi/R26Zf6XwBO6dlC8Qq79yK3Mv6iiJmJ3UkTXBbL2GlzzqNV99HXiiiV/ddq7s0cnjxZxxEgP93YBIeV3N+7Hhg1KpJDWUQ71RK17jwlz+a17QRO2rwC/mfkDyOuAFScUFOAq5zHO0Q3RTrKEeokbJl/f9RtPxRt3pf/+sGCU55LOWmMydqUjvm5+7QEXDJ6Ce9u6sKC3t+04znVSlAHOiNCJ1TY9FthE52xqvWdHs6fvNzVxZGzm4OXY1Lk4koIG1IqbdA==
From: Oleksandr Tyshchenko 
To: "xen-devel@lists.xenproject.org" 
CC: Michal Orzel , Ayan Kumar Halder ,
	Stefano Stabellini 
Subject: [ImageBuilder] uboot-script-gen: Add ability to configure static
 event channels
Thread-Topic: [ImageBuilder] uboot-script-gen: Add ability to configure static
 event channels
Thread-Index: AQHcMWv1PEvr31auREGXSWhX8dEo6w==
Date: Mon, 29 Sep 2025 18:07:47 +0000
Message-ID: <20250929180746.1881872-1-oleksandr_tyshchenko@epam.com>
Accept-Language: en-US, 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: AM9PR03MB7025:EE_|AS4PR03MB8178:EE_
x-ms-office365-filtering-correlation-id: 35a900cc-a209-48ee-dc19-08ddff831873
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|376014|42112799006|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?gXcB4qqh8Wi9H4+EhryZH9F9+WiZb76qhzjElZxl59aS5fgJWkXxmcfH8n?=
 =?iso-8859-1?Q?Idy2nSCpfUqZm7VzrQjiKGmltU9UzqGvwMfgqXFS3Y+mot7EzhK353S8em?=
 =?iso-8859-1?Q?rjcbUc6fzhK6d2mz8/PbbARjz9BPJwR3/EWOP99tAjaenQajwQDzHil/Oe?=
 =?iso-8859-1?Q?vL1fAN1qj55SOHA/B9lURxaWZnbIgl91dc7BW0pd9J2jwdVaQPKsqv04Tu?=
 =?iso-8859-1?Q?6sLm47mR75ESNMWWAwi07dKDNCc088U4qZSUSXtFJBnF+z3lxxTR9H2FmN?=
 =?iso-8859-1?Q?ssmFjNDfIgjWxOLAGatzn1WaqtwulYRjeMWncb5uYhC9jSq9cB0c8sGF6v?=
 =?iso-8859-1?Q?pwnn1FD8Zr1KW9IFYtKk30wcCos33XpjcSahSwYSof6Bm71rqwYfmh36PS?=
 =?iso-8859-1?Q?SC6ePdSFL0ZJayRFp1DeqtfKSl+mv56zBgo1nWQdiHjPjVHBfj1q/xF/Vf?=
 =?iso-8859-1?Q?1ZRMJJe8UZAHlrd5mMYwE5Lu/k5mzrvSQlGFNJBYtodwzNv1sJ7ZNR95VA?=
 =?iso-8859-1?Q?X5hOU3ejJ+B1EhDs6UqAavdweZXxxLBH1r+TeqTbmIWGu4rceaZyvq3k0a?=
 =?iso-8859-1?Q?aU9r1yJeP42t6Lbio9aaD976yqD39Tw1i/wHcKVwnr5GVz/A6wrBoOjqYH?=
 =?iso-8859-1?Q?I9vqE0SCzfYu2DYXik+6A0MjIXBoqninNZgdohp59WH7NI3oXTozSWqU64?=
 =?iso-8859-1?Q?dkao8si5zXIA4eNsX72APRSCfTGJHtLQCD9hnr5cFz/SjVsztwAcKuqlxV?=
 =?iso-8859-1?Q?gj+Ae3B+MYkDJnCj/8EWId/7M3d/LZN/u76CEc6433BIerihVW7oODyV5M?=
 =?iso-8859-1?Q?jVBaGxoQb/3s0i08LyxMADCOP+JQ2E9TntH0qPJKmVXcCXF5Txf84vKnA3?=
 =?iso-8859-1?Q?ILEAvthNR/ICnbre10hu2fbNMfw06mcWdiT4P0QG1Ge4hBthB3GnNosc/l?=
 =?iso-8859-1?Q?qJsPfnnkCKgQa1eHh4wRw4tazhFizyNlCe33NIRZfN0KXRk5+ALwoRDzWB?=
 =?iso-8859-1?Q?OOeRrUnSWEd0XdJsqcXSXNdSS7NNHTEMmyw2rLrY1cKxtzPInftmyrcPw8?=
 =?iso-8859-1?Q?9KYU8y3iFkrNkdi67o5Y+E4DFzDftPokjt2jB20kc/iYNqIP2uppvH9n9X?=
 =?iso-8859-1?Q?dEYGztHsPnNPosXCeMSBA+bQXVfMQGrdOt+fMyMsdu6lu8AMDpmj67l+Sx?=
 =?iso-8859-1?Q?+sIQsVulORpI80y+Z+yxTMKvWXcdX4/VXtbd7fQiKbJKFh0aJQnOfgK682?=
 =?iso-8859-1?Q?sgoiQve3tHWGCIUD8a/LL5Z1ue1zIZRKeE5+AqK+rEV+a9peUzuVAOT7V6?=
 =?iso-8859-1?Q?eBxUUbj7lMervA5Z660vXJlJN5npsbTCJnctTpZWrEBdXgv70kBGmGYEiU?=
 =?iso-8859-1?Q?/oJz7W5uhEi9OmE/15pR3soHBIu3z1j4pGP+VIYpgfb3pxW1x3awhGJf/U?=
 =?iso-8859-1?Q?smDP7Rb3fUUX44FdA3ifc8PoAn11PldMr0kP2OcCPlVFzvr7DNc+NQ2/F7?=
 =?iso-8859-1?Q?XO8VOF3Nzd5zg1swJkkwtcIk+6z9ueom8VRrfAbU3G0VJZBvB/TSOFxdqO?=
 =?iso-8859-1?Q?W7KTRSkpvouWBIGMybBWZ/rL7UuU?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(42112799006)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?v+EeOO7/Y5ur1PpyQUcH8thdrE7MIKzVQUE2iHWgiXj7YYwG8S8W4bi3L6?=
 =?iso-8859-1?Q?ZWr6JN+2lkF8xy4OslN00bW80Hn0p8eqTiRcgd7jYUdmQGT+MthXi5mLVT?=
 =?iso-8859-1?Q?pYHgsrfccgqlhgbEJsWNkIn7N3hPdGKCCQau00hEEKPBQC3qlDqfw9HLxG?=
 =?iso-8859-1?Q?3ycrnAJKDEFRO6/KBeAn2AfELIwkyPPRsP1XURwLX5cd9xXgZu4ybgsBL8?=
 =?iso-8859-1?Q?rBACJK0U131JqD9CIeXg17bcNN8JB+Z7A0ZiA6JaKHC7DJOxD4Lgl70sm5?=
 =?iso-8859-1?Q?86UMhjrJQjoox0U759o+U4pI9sYUBcgyMDCfFMnnk8KRyqo5Ls3wmupUM/?=
 =?iso-8859-1?Q?k/wDHrVeIKiZHaeBwNfECy+LQq7GagqFFQi5sCXmlt5VviKB6+2k3vO1i5?=
 =?iso-8859-1?Q?QHhQQ96Wmshq94RaMiKLvX/SDs1ufmg0fM46YI2MJ3Zo9eu9tKIQ+3TwgL?=
 =?iso-8859-1?Q?wRR1eRCBWPcL6UUpLpjk2KkI96mRjNznoh69KUyaJ7ldtP34snECbOLuuG?=
 =?iso-8859-1?Q?YjW2VH3dygvb13+/xyU4ZjOV6w3KbGNXSLlVZvuH0mj4HzyJsNAOZn7MZw?=
 =?iso-8859-1?Q?b+3X2KJv++soink06tZYSRsrVrWPzroNdPqpaeLfSGopx/JEJOegVte/JX?=
 =?iso-8859-1?Q?xoiEGxyUzKoVMKNmqWk1cjJqdhi5gbHV2RwYXUMJMOOeJHYg5F6oALaal0?=
 =?iso-8859-1?Q?rWmHKMChdzkC1yx462rr74WG903KxNYBdFZhJN+Jrt32WiOzKe9LxmwY06?=
 =?iso-8859-1?Q?Vqo1TBCkENHEEIvhzxEygC0YSRViweNPvvAAMhA/+MrQsA6UD9k0Ez7jZw?=
 =?iso-8859-1?Q?2cgK4lTMh0ieePuXjxcmhHSOZ7+/9N7me8cBY2tk93qwtYKRQXtLzF1gJm?=
 =?iso-8859-1?Q?kvyCYgUTNT8vdIdOqmS5bIZXgoWHUAnlnGJAJ4vUMSCItZZs79KcwgGlrh?=
 =?iso-8859-1?Q?l4mvSDDWB6k3KwyEnNcJza2qp2mbb2Cgr/g6aqeWaBzUEhtwvIs43LMwvs?=
 =?iso-8859-1?Q?L6qUFh628sV+tUuHqIXiwKo/rusS7ZFcmMh+4YMj22VuljESCOKIPTQt3c?=
 =?iso-8859-1?Q?SrxChbZAIkCGE1Itg1G9ezRHtu3mXtI51ZWDQoVxWAQwpVrdQLKHtfmtiX?=
 =?iso-8859-1?Q?8peKv62eoBGomd30JJlGP4rCuqB1hGKgWOkksedVoGVwMMxJYkREOw+aKP?=
 =?iso-8859-1?Q?mukqaraRiEV2vZkrFlSUKCtYFeFp9JCUKUpuZsgPlKA1sPeGzkf6ihjtFS?=
 =?iso-8859-1?Q?c6mWxGWnV6zGqIZOyN8UXLQZpB54HpmWFsQEJOXIESMqET4s723OEHiGND?=
 =?iso-8859-1?Q?xyErJe+RI+Nllz48pomQecJRC/IP+L3l1vDER+K8hEBCRzszkG9aDRfkOV?=
 =?iso-8859-1?Q?qqXsboxCmh949eptNp/sDJp6wsHARQpb3Z/uWFqCL/3G1p9gcy/PsjYgRx?=
 =?iso-8859-1?Q?LtzDla1P5sBs1HrL5NoFpJpqDj3ub41AFpNt4WNqwUkuWY3I5YVXIeVPw6?=
 =?iso-8859-1?Q?iRYEvVXe813c9LuwKqbdq1R/QCw+UG0ZRtrKwBNn5UPzwEM9+2SeV082UN?=
 =?iso-8859-1?Q?ajxPbuIEn+p8HU+Spl4clNpQ50sbbu3ptkl802ADJCZ2q0wL6nCfQwX6ZG?=
 =?iso-8859-1?Q?I+g2iFhT+OvJSDWqeyhnQx/pXy9bL+58+YeitKRGZmJEczY0IbWtj1jRHo?=
 =?iso-8859-1?Q?fsWUlXoM4nvw6Do+6f0=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: AM9PR03MB7025.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35a900cc-a209-48ee-dc19-08ddff831873
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 18:07:47.1990
 (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: +FFm9pUSSR/p0+1bUHPWvXARdkuGTtR+Bvh69ud3TgXNByUl5UfrA4FDe3usRJX0xr06IVZQ+MbgUNNmKbAJcQXBQ35OMhaHYUE8SeBWkkc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8178

Add DOMU_STATIC_EVTCHNS[number]=3D"local_id local_port remote_id; ..."
configuration file string option specifying the static event channel
definitions for domain.

The build script uses simple IDs to automatically and safely
generate the required unique phandle numbers for the device tree.
The user only needs to define simple numeric IDs and does not need
to manage complex phandle values.

For the following example:
DOMU_STATIC_EVTCHNS[0]=3D"1 10 2; 3 12 4"
DOMU_STATIC_EVTCHNS[1]=3D"2 11 1; 4 13 3"

it generates:
fdt mknod /chosen/domU0 evtchn@1
fdt set /chosen/domU0/evtchn@1 phandle <0xfffffffe>
fdt set /chosen/domU0/evtchn@1 compatible "xen,evtchn-v1"
fdt set /chosen/domU0/evtchn@1 xen,evtchn <10 0xfffffffd>
fdt mknod /chosen/domU0 evtchn@3
fdt set /chosen/domU0/evtchn@3 phandle <0xfffffffc>
fdt set /chosen/domU0/evtchn@3 compatible "xen,evtchn-v1"
fdt set /chosen/domU0/evtchn@3 xen,evtchn <12 0xfffffffb>
...
fdt mknod /chosen/domU1 evtchn@2
fdt set /chosen/domU1/evtchn@2 phandle <0xfffffffd>
fdt set /chosen/domU1/evtchn@2 compatible "xen,evtchn-v1"
fdt set /chosen/domU1/evtchn@2 xen,evtchn <11 0xfffffffe>
fdt mknod /chosen/domU1 evtchn@4
fdt set /chosen/domU1/evtchn@4 phandle <0xfffffffb>
fdt set /chosen/domU1/evtchn@4 compatible "xen,evtchn-v1"
fdt set /chosen/domU1/evtchn@4 xen,evtchn <13 0xfffffffc>

Signed-off-by: Oleksandr Tyshchenko 
---
 README.md                | 21 ++++++++++
 scripts/uboot-script-gen |  7 ++++
 scripts/xen_dt_domu      | 89 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 117 insertions(+)

diff --git a/README.md b/README.md
index 7b68cf5..52ed1f7 100644
--- a/README.md
+++ b/README.md
@@ -218,6 +218,27 @@ Where:
       DOMU_VCPU_HARD_AFFINITY[number,1]=3D"3"
 ```
=20
+- DOMU_STATIC_EVTCHNS[number]=3D"local_id local_port remote_id; ..."
+  if specified, this parameter allows the configuration of static event ch=
annels
+  for inter-domain communication. Each entry in DOMU_STATIC_EVTCHNS[number=
]
+  specifies one or more event channels for a particular domain.
+  The configuration format for each event channel definition is a set of
+  three values:
+    - local_id: A simple, unique integer that identifies the local endpoin=
t of
+      the event channel. This ID must be unique across all domains.
+    - local_port: The numeric port number for the local endpoint.
+    - remote_id: The ID of the corresponding remote endpoint to which this
+      the local port connects.
+
+  Multiple event channel definitions for a single domain can be provided b=
y
+  separating them with a semicolon (;).
+
+  Below is an example that creates two pairs of bidirectional channels bet=
ween
+  two domains:
+  NUM_DOMUS=3D2
+  DOMU_STATIC_EVTCHNS[0]=3D"1 10 2; 3 12 4"
+  DOMU_STATIC_EVTCHNS[1]=3D"2 11 1; 4 13 3"
+
 - DOMU_COLORS[number] specifies the colors (cache coloring) to be used
   for the domain and is in the format startcolor-endcolor
=20
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index 4f92610..003a622 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -428,6 +428,8 @@ function xen_device_tree_editing()
         fi
     fi
=20
+    xen_dt_build_evtchns_map
+
     i=3D0
     while test $i -lt $NUM_DOMUS
     do
@@ -512,6 +514,11 @@ function xen_device_tree_editing()
=20
         xen_dt_domu_add_vcpu_nodes "/chosen/domU$i" $i ${DOMU_VCPUS[$i]}
=20
+        if test "${DOMU_STATIC_EVTCHNS[$i]}"
+        then
+            xen_dt_domu_add_evtchns "/chosen/domU$i" "${DOMU_STATIC_EVTCHN=
S[$i]}"
+        fi
+
         add_device_tree_kernel "/chosen/domU$i" "domU${i}_kernel" ${domU_k=
ernel_addr[$i]} ${domU_kernel_size[$i]} "${DOMU_CMD[$i]}"
         if test "${domU_ramdisk_addr[$i]}"
         then
diff --git a/scripts/xen_dt_domu b/scripts/xen_dt_domu
index 8134896..97c5325 100644
--- a/scripts/xen_dt_domu
+++ b/scripts/xen_dt_domu
@@ -37,3 +37,92 @@ function xen_dt_domu_add_vcpu_nodes()
         fi
     done
 }
+
+declare -A EVTCHN_ID_TO_PHANDLE_MAP
+
+function xen_dt_build_evtchns_map()
+{
+    local i
+    local evtchn_str # The full event channel definition string
+    local def
+    local local_id remote_id id
+    local new_phandle
+
+    for (( i=3D0; i<$NUM_DOMUS; i++ ))
+    do
+        evtchn_str=3D${DOMU_STATIC_EVTCHNS[$i]}
+        if test -z "$evtchn_str"
+        then
+            continue
+        fi
+
+        IFS=3D';' read -ra evtchn_defs <<< "$evtchn_str"
+
+        # Loop over each definition and process both local and remote IDs
+        for def in "${evtchn_defs[@]}"
+        do
+            read -r local_id _ remote_id <<< "$def"
+            if test -z "$local_id" || test -z "$remote_id"
+            then
+                echo "Malformed evtchn definition: '$def'"
+                cleanup_and_return_err
+            fi
+
+            if [[ "$local_id" =3D=3D "$remote_id" ]]
+            then
+                echo "Invalid evtchn definition: '$def'"
+                cleanup_and_return_err
+            fi
+
+            for id in $local_id $remote_id
+            do
+                # If this ID is not already in our map, assign it a new ph=
andle
+                if [[ ! -v EVTCHN_ID_TO_PHANDLE_MAP[$id] ]]
+                then
+                    get_next_phandle new_phandle
+                    EVTCHN_ID_TO_PHANDLE_MAP[$id]=3D$new_phandle
+                    echo "evtchn ID '$id' is assigned phandle '$new_phandl=
e'"
+                fi
+            done
+        done
+    done
+}
+
+function xen_dt_domu_add_evtchns()
+{
+    # $1 - dt path
+    local path=3D$1
+    # $2 - The full event channel definition string
+    local evtchn_str=3D$2
+
+    local def
+    local local_id local_port remote_id
+    local local_phandle remote_phandle
+
+    IFS=3D';' read -ra evtchn_defs <<< "$evtchn_str"
+
+    # Loop over each definition and create a node for it
+    for def in "${evtchn_defs[@]}"
+    do
+        read -r local_id local_port remote_id <<< "$def"
+        if test -z "$local_id" || test -z "$local_port" || test -z "$remot=
e_id"
+        then
+            echo "Malformed evtchn definition: '$def'"
+            cleanup_and_return_err
+        fi
+
+        # Look up the phandles from our globally-populated map
+        local_phandle=3D${EVTCHN_ID_TO_PHANDLE_MAP[$local_id]}
+        remote_phandle=3D${EVTCHN_ID_TO_PHANDLE_MAP[$remote_id]}
+        if test -z "$local_phandle" || test -z "$remote_phandle"
+        then
+            echo "Could not find phandle for evtchn ID '$local_id' or '$re=
mote_id'"
+            cleanup_and_return_err
+        fi
+
+        dt_mknode "${path}" "evtchn@$local_id"
+        dt_set "${path}/evtchn@$local_id" "phandle" "hex" "$local_phandle"
+        dt_set "${path}/evtchn@$local_id" "compatible" "str" "xen,evtchn-v=
1"
+        dt_set "${path}/evtchn@$local_id" "xen,evtchn" "hex" "$local_port =
$remote_phandle"
+    done
+}
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133115.1471290 (Exim 4.92)
	(envelope-from )
	id 1v3IgM-0000wG-Es; Mon, 29 Sep 2025 18:33:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133115.1471290; Mon, 29 Sep 2025 18:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IgM-0000w9-C5; Mon, 29 Sep 2025 18:33:06 +0000
Received: by outflank-mailman (input) for mailman id 1133115;
 Mon, 29 Sep 2025 18:33:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3IgK-0000iD-Sw
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:04 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bbcaa35d-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:33:03 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-46e2e363118so49025485e9.0
 for ; Mon, 29 Sep 2025 11:33:03 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc88b0779sm19057657f8f.58.2025.09.29.11.33.01
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: bbcaa35d-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170783; x=1759775583; darn=lists.xenproject.org;
        h=content-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=o8vf9ta3nqwm/Fyb5G7ZjHvxKsRPPnP+TTAqHaMFdKE=;
        b=BxFF1A6aSFT9Lh5ufG7ZKqr/zqzAHro76dWDLVcVuNzi4LROc/uw9J+3L7AgKk0nk+
         UCB+nAbGe43nut/lMYTYkCSwlVMpAmBDlyQ1xffFBl4ddR6t/Jq4piStF7HzQSxPYjQ1
         V/bcBjImLtDVrg2kYCtpocYyey469IRA5hT6rnmp5BshoxQvMxF8fL9WByfqev+P7/lN
         s/8HRjWc+HddoGog8HL+U8yU7OqYamNa6svgOft8JnJ5/c+rPPLn2N9omt73cepGRgd4
         1rX742C5sRjhqgeIMVqtGNh2EX1NfsPF6jhBkwBLAJgD0SLOXw2hYWPCozN2hhJqphT1
         iSgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170783; x=1759775583;
        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=o8vf9ta3nqwm/Fyb5G7ZjHvxKsRPPnP+TTAqHaMFdKE=;
        b=kovjke9VJCd4vPIz+DpAWOhtRsJp60ZbUJusQP7yMq/YRnPCWWdZPomtQ1FEub7Of2
         v20JVYEPlDwAsoqHUUv2qgZNYLzhDQVnchiV8vmrOhZLILn1AjUD3zsXu4fRAK8H7xH1
         rbDBmhjODsVkFAjlGocBxQTQcaFP5nyXfP0nW77OQZHWX/XcUlad/Z+5WOIWALrEBuGg
         Jfbxa5vTtlIVP8rx3V8V/jTZUbzk4T9w5UH05z9dPkOyMkoIjLtnYVrN8hCGjg1jd0z8
         dTYUWnbPLeB7q0gOuBRxQDkOMWNkk/xEwhgdZKW8jJCe+mdCOxvBnl15JX7wJ6XSzHFJ
         6hrg==
X-Forwarded-Encrypted: i=1; AJvYcCXIt/4eSobyfwv0UCUHxpN/CfVqe+f5f7Sb+h2RdjbzvbXNyp7irGQ/XENpM1Ap7Ez3uI7Mjrr/dv0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwK3QWg5gSwN0fy2U3PZCYxmqnLlb27Cwwy3WCTM5LQ4Om3YwoY
	xIYUCzO09Ck3GW/tTib0oQgRhVCVa438roAb++QXpi4j/z6M1yHo+zT8UN91NIy//lo=
X-Gm-Gg: ASbGnctb3xQnPhl0p5yZNXT2YGRggXtUPcqK5vbUph8Yfo8ZhwWM9s8wgR+Q87ZkglT
	KiXfpIolviWs4QX+fO+c2cpwl4lzpPTvXHBSB9T8LQyTgsbSEqc5R9HNt9v1Bc8mpqcwjOpLUqw
	OruL9NXQuL7rr3MH2dcc7eanabT4Tu3MJ1NENAemOTFjvYwSmH22/weNpzFG+gB22NGoFA0ZoHy
	s7v3gKCjwJ36pHsyRlGRYGIoqAdkAdvSWr1V0bXG80FRtnqFfzwdyxfym/x8elhh7MDvL84f76y
	lUxbLNzUTZOekBMVRps6p2ZbsiArS+oOmq4dITi0eLb93uWEzST885oWClXvyX1fdUnSQCjrexK
	7/kn3rMy8yxFFKGCIHxn+uScFWEwxTjhYqOwOam2hsT2n/2MCMmXmqfGi0L6MOrbtmu7oqxV3GY
	Qph2KrYUk=
X-Google-Smtp-Source: AGHT+IHvn5eYPMtDO5pcLQu1/TqV9ktVhW1E6kH/3j8sdOMbTO5qR8/yD6k9KVyFZbMuU0yLOSpWPQ==
X-Received: by 2002:a05:600c:1508:b0:458:c094:8ba5 with SMTP id 5b1f17b1804b1-46e329b62bcmr112008465e9.12.1759170782675;
        Mon, 29 Sep 2025 11:33:02 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 01/15] docs/devel/loads-stores: Stop mentioning cpu_physical_memory_write_rom()
Date: Mon, 29 Sep 2025 20:32:40 +0200
Message-ID: <20250929183254.85478-2-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Update the documentation after commit 3c8133f9737 ("Rename
cpu_physical_memory_write_rom() to address_space_write_rom()").

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/devel/loads-stores.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index 9471bac8599..f9b565da57a 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -474,7 +474,7 @@ This function is intended for use by the GDB stub and similar code.
 It takes a virtual address, converts it to a physical address via
 an MMU lookup using the current settings of the specified CPU,
 and then performs the access (using ``address_space_rw`` for
-reads or ``cpu_physical_memory_write_rom`` for writes).
+reads or ``address_space_write_rom`` for writes).
 This means that if the access is a write to a ROM then this
 function will modify the contents (whereas a normal guest CPU access
 would ignore the write attempt).
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133114.1471280 (Exim 4.92)
	(envelope-from )
	id 1v3IgJ-0000iQ-8Z; Mon, 29 Sep 2025 18:33:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133114.1471280; Mon, 29 Sep 2025 18:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IgJ-0000iJ-5F; Mon, 29 Sep 2025 18:33:03 +0000
Received: by outflank-mailman (input) for mailman id 1133114;
 Mon, 29 Sep 2025 18:33:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3IgH-0000iD-JH
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:01 +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 b89a6882-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:32:58 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-46e37d6c21eso33440895e9.0
 for ; Mon, 29 Sep 2025 11:32:57 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f76b21sm21984265e9.19.2025.09.29.11.32.55
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:32: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: b89a6882-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170777; x=1759775577; 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=gjcLUmOUJAsFuFPIcikgqMGc8qGXLm4Hg2dBmXJH0DU=;
        b=meIvsQwGc4gZNXGXj3KWvSrqDhZ4CX5WeCucR5ESNGsJrjbEl0qB3FOsBCMRTdDDQa
         DEhRan4xo2qb6KA0wacZpxDdLCVdi9rJPBaBF9zT450T61pFATSQ6axJ+a4BP+UbfSDX
         cwaCM7lCiLJdqUqaIXah+Gc9fMUrDa10U5CAf+sbT7dNfpBKV7ip5qIU7EtWpVMKhX1C
         oWzpHp5j74WCoSpm3OYerEH2zlwKd8AvN0jHy9twe7wPJW8ZU4Qu88qY2Yz1g2fsJZf0
         ibTR9ZPTjLeuexcTfJU0g9rQ8Z/HglDqH+uatSkUqtzu8cWx60ZcKiZBoQM9K6R5JJ/q
         MpYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170777; x=1759775577;
        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=gjcLUmOUJAsFuFPIcikgqMGc8qGXLm4Hg2dBmXJH0DU=;
        b=hSBiiiiaEacoWd+H30/CccrxYWLYIhdPmI9UnkhDa7BN4lcW5llZSvZQ5RhSCPmQHb
         Vs4qWEBMnPFkPNNifIewfrmTT/6LNEPSLJkeGamIbAS4uO50K/bDm4bBVAcDTqlWmAB6
         c2ICU/WxIWo7MjyOZsTbNl344ANkEYX1/2puY6XeeIDfk+JL6wmmY6iqHA4/+waWJo8i
         +unMzdF0HPhIC2LxbRCg/y5Lk8QwgWI2svelFYodhDp5YveNh2rd3uHIFvBbZP6PT6mx
         6oi0hmcbaVQGtUeHoVx2PBMK0ScIIKOU4jadQQKPXahkZfxbpgKR9jd/JvKsSs1TUogk
         crkQ==
X-Forwarded-Encrypted: i=1; AJvYcCU16exZ0M4a9XMG8jnvc8CG8+etAfGlrUi5q6Igm1VUw3A+G0whD3cZRrSbNJahb4yiEFIVmu4tm+M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBQRZcCaDnBydAAIVJiqCYnO0QnQdZOzxQ0fo6KqGj0G/HQq57
	ZglNqrLmaYG8z7+2My/wEFyTYcjVCNqhq2ZgsDHZzj7GZvd0CNgyjb2VBxHDFhBTUGs=
X-Gm-Gg: ASbGncsh6Zh7SB1CC1YLfCyqyZClfU0wP1tAt6B6H+Su2SP7r5/8HObsYLUdfnnRuOE
	zm65V586mocEB8lJnI1HJ7f7AXwd7r/0RiXfBJUPW1+986MFSvFXM5wQm8UGmiq+Yq1akrEZhu3
	ah1+qHRLZwCmHaQWohdJMEbOX9+wN3GSEf/0yt/K3G7boBFeT2+6RhHP6+I/zF2cE0StuKdgLZC
	TpGcAsmYGF29s9TjP/x7VvyE3GgH0kr310pFLHYfs1olqhy4+/UIjahbGXmM1LMXDARWwMtb3rK
	lBTKzTU2FFjasnIuEiDiqvCP7BXmP9Udp3REHhcEc7xgiz6RAEvShFUzApKPvoKbvEI/g4DmKv2
	ZMMtK/9PphKQzaCZaA1XnQft00H7C0kDUAlOoBBAv7XRAkk5+5rofhuJ6dbfbEd2P4kcmJVZ1
X-Google-Smtp-Source: AGHT+IGPwe4k1nSiLo3Q7fXg2P2eLKRZ1aglm2SdrtFWVXuSkGkjq+3L8RzYMElaCZp3EfcaDxFBpg==
X-Received: by 2002:a05:600c:350b:b0:46e:36fa:6b40 with SMTP id 5b1f17b1804b1-46e36fa6c4emr125120035e9.24.1759170777268;
        Mon, 29 Sep 2025 11:32:57 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 00/15] system/physmem: Remove cpu_physical_memory _is_io() and _rw()
Date: Mon, 29 Sep 2025 20:32:39 +0200
Message-ID: <20250929183254.85478-1-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

The cpu_physical_memory API is legacy (see commit b7ecba0f6f6):

  ``cpu_physical_memory_*``
  ~~~~~~~~~~~~~~~~~~~~~~~~~

  These are convenience functions which are identical to
  ``address_space_*`` but operate specifically on the system address space,
  always pass a ``MEMTXATTRS_UNSPECIFIED`` set of memory attributes and
  ignore whether the memory transaction succeeded or failed.
  For new code they are better avoided:
  ...

This series removes:
  - cpu_physical_memory_is_io()
  - cpu_physical_memory_rw()
and start converting some
  - cpu_physical_memory_map()
  - cpu_physical_memory_unmap()
calls.

Based-on: <20250922192940.2908002-1-richard.henderson@linaro.org>
          "system/memory: Split address_space_write_rom_internal"

Philippe Mathieu-Daudé (15):
  docs/devel/loads-stores: Stop mentioning
    cpu_physical_memory_write_rom()
  system/memory: Factor address_space_memory_is_io() out
  target/i386/arch_memory_mapping: Use address_space_memory_is_io()
  hw/s390x/sclp: Use address_space_memory_is_io() in sclp_service_call()
  system/physmem: Remove cpu_physical_memory_is_io()
  system/physmem: Pass address space argument to
    cpu_flush_icache_range()
  target/s390x/mmu: Replace [cpu_physical_memory -> address_space]_rw()
  target/i386/whpx: Replace legacy cpu_physical_memory_rw() call
  target/i386/kvm: Replace legacy cpu_physical_memory_rw() call
  target/i386/nvmm: Inline cpu_physical_memory_rw() in nvmm_mem_callback
  hw/xen/hvm: Inline cpu_physical_memory_rw() in rw_phys_req_item()
  system/physmem: Un-inline cpu_physical_memory_read/write()
  system/physmem: Inline cpu_physical_memory_rw() and remove it
  hw/virtio/vhost: Replace legacy cpu_physical_memory_*map() calls
  hw/virtio/virtio: Replace legacy cpu_physical_memory_map() call

 docs/devel/loads-stores.rst            |  6 ++--
 scripts/coccinelle/exec_rw_const.cocci | 22 --------------
 include/exec/cpu-common.h              | 18 ++---------
 include/system/memory.h                | 12 ++++++++
 hw/core/loader.c                       |  2 +-
 hw/s390x/sclp.c                        | 14 ++++++---
 hw/virtio/vhost.c                      |  6 ++--
 hw/virtio/virtio.c                     | 10 +++---
 hw/xen/xen-hvm-common.c                |  8 +++--
 system/physmem.c                       | 42 ++++++++++++++------------
 target/i386/arch_memory_mapping.c      | 10 +++---
 target/i386/kvm/xen-emu.c              |  4 ++-
 target/i386/nvmm/nvmm-all.c            |  5 ++-
 target/i386/whpx/whpx-all.c            |  7 +++--
 target/s390x/mmu_helper.c              |  6 ++--
 15 files changed, 84 insertions(+), 88 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133116.1471300 (Exim 4.92)
	(envelope-from )
	id 1v3IgR-0001DZ-R3; Mon, 29 Sep 2025 18:33:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133116.1471300; Mon, 29 Sep 2025 18: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 1v3IgR-0001DQ-OH; Mon, 29 Sep 2025 18:33:11 +0000
Received: by outflank-mailman (input) for mailman id 1133116;
 Mon, 29 Sep 2025 18:33:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3IgQ-0000iD-Bw
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:10 +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 bf092008-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:33:08 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-46e2e6a708fso32634665e9.0
 for ; Mon, 29 Sep 2025 11:33:08 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc5602f15sm19310452f8f.39.2025.09.29.11.33.06
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: bf092008-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170788; x=1759775588; darn=lists.xenproject.org;
        h=content-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=rGMp7t36URRQSytZ84th6z88iiyCKyUd2WF0ymWy9Sc=;
        b=bkg76a5r4eVsmU0pu9ZzzVUVDnDKMWB8BiF7gykQDQI4Rb0QrVsg2iEMazeUi3n8NO
         8CuH11s81FtNP66bcG8eGu0wgLDYyZyw87YJRmND338QFCvOZ/gWUWDI2grA/w/GGLWm
         SBcMnr/qyl7j5FNy9MkyLhp7Q3QA4XYyHRZRVV1URqoReAYD8wlH5o7X09ASTscvEog0
         B57Plxi2Xkml8obROdsB+7pK6Ue47Ob7rsmdYqFxu8btO9ENUcoGRp9vK9NOP+5z2sWP
         01WYvawR+BWYnkjxc9fzhhB/7hTC4WyO1Ex3W29jTpMwRGVppYatXuW+ZX18yuMZiXuP
         7p6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170788; x=1759775588;
        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=rGMp7t36URRQSytZ84th6z88iiyCKyUd2WF0ymWy9Sc=;
        b=K1aCXBeGjYPka6u0b+JSRoMZy/2gVpMfCDDZMXoOUqzkpus+vkdQyiEkWUXM+gG87I
         8wPYbbmT/SJ34AnD4WYGoovd3OaGqipzg41Z/AU4lQE5//X4icQtoDpG0nhlUzmRVkUD
         Qu3QX2BaSk4m0UWuWMt77O3RFk78pzuW8zNIClmt7o8A7wBaZSJgW8WkpkkkQ6G/dHXS
         J3BAFHgqFneylDvneuQAbPQu5VP5qSlRmlI1QyhFEvnR2uChn5j1G2Ou0ItQJuxLHU0S
         lsNQ8vRecVHtxlOkKLmRg2VhqQkRBg+Q5CAna1iJQHhT+vIuOx1ukKwt/rQ3Ct+sZZqF
         n0kQ==
X-Forwarded-Encrypted: i=1; AJvYcCUynGZ8iVtCyNxfSmby61XE1J95Be5Qg+iqij2/FrEq31Ta7mlO2W9QVZN8BR79v6zD7shdTe7VqLY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWhLSyxIJ34ostEqaG/L51UXw3VENJblvkGb6MByW9nTED5Lxu
	PNmE0SzssN2TmNL7J/+9arVPNyPeiWhSmYTuUnSnxo25Uj/UM3yta0/Plf6+TbW7GY4=
X-Gm-Gg: ASbGncspl5WQ3FXJsUhI8u8kicxx8PXbf7P6nSKdaitkzqc9CAfIVxca0Z5L9+qth7v
	NlNK7AK+XkD7NmfTETnPMbbEzB56K3xTTuoY4qK2B6G5TKo04XP3k0aM2doMRF5rIKwFESsdyq0
	xfzenu1GTTdhuHe17XiwDrXeUE24gH8QNF6yJ4E3k5D8oSwG5WpMq6aUmO2iGEhs1Z4VECgoh0P
	srfNLWVTqKXxf4NZv05GteV1fj1B7xijp0xcQ8rNr5kyXWYBz8KaVCN7bu9oBZTvCrz49kOSJld
	GY9Afd9zuby5ZDC3rS3KJBIizwm/0iHueX5h4DN4BBNSvGViouiZvMLXOEYbkVmiJM8VzRQmFVO
	sAHBO3zxc/7PdFi/K4Zsgzq5X34QfL0OPxKQFdRNNlM8q+Z8Vum9UGELBF4n5AS6YC8hwzP/U
X-Google-Smtp-Source: AGHT+IHywbu3bHq36g4SNbzTfpiE+7B23z7rbV7w73oeTvg9ANkjyrRL+PYW3W+Y3jHxmFSC/MGdsQ==
X-Received: by 2002:a05:600c:6303:b0:46e:376c:b1f0 with SMTP id 5b1f17b1804b1-46e376cb318mr142020765e9.7.1759170788090;
        Mon, 29 Sep 2025 11:33:08 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 02/15] system/memory: Factor address_space_memory_is_io() out
Date: Mon, 29 Sep 2025 20:32:41 +0200
Message-ID: <20250929183254.85478-3-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Factor address_space_memory_is_io() out of cpu_physical_memory_is_io()
passing the address space and range length as argument.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/system/memory.h | 10 ++++++++++
 system/physmem.c        | 21 ++++++++++++---------
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/include/system/memory.h b/include/system/memory.h
index aa85fc27a10..6cfa22d7a80 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -3029,6 +3029,16 @@ static inline MemoryRegion *address_space_translate(AddressSpace *as,
 bool address_space_access_valid(AddressSpace *as, hwaddr addr, hwaddr len,
                                 bool is_write, MemTxAttrs attrs);
 
+/**
+ * address_space_memory_is_io: check whether an address space range is
+ *                             I/O memory.
+ *
+ * @as: #AddressSpace to be accessed
+ * @addr: address within that address space
+ * @len: length of the area to be checked
+ */
+bool address_space_memory_is_io(AddressSpace *as, hwaddr addr, hwaddr len);
+
 /* address_space_map: map a physical memory region into a host virtual address
  *
  * May map a subset of the requested range, given by and returned in @plen.
diff --git a/system/physmem.c b/system/physmem.c
index 8a8be3a80e2..18b3d38dc0c 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3358,6 +3358,17 @@ bool address_space_access_valid(AddressSpace *as, hwaddr addr,
     return flatview_access_valid(fv, addr, len, is_write, attrs);
 }
 
+bool address_space_memory_is_io(AddressSpace *as, hwaddr addr, hwaddr len)
+{
+    MemoryRegion*mr;
+
+    RCU_READ_LOCK_GUARD();
+    mr = address_space_translate(as, addr, &addr, &len, false,
+                                 MEMTXATTRS_UNSPECIFIED);
+
+    return !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
+}
+
 static hwaddr
 flatview_extend_translation(FlatView *fv, hwaddr addr,
                             hwaddr target_len,
@@ -3754,15 +3765,7 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
 
 bool cpu_physical_memory_is_io(hwaddr phys_addr)
 {
-    MemoryRegion*mr;
-    hwaddr l = 1;
-
-    RCU_READ_LOCK_GUARD();
-    mr = address_space_translate(&address_space_memory,
-                                 phys_addr, &phys_addr, &l, false,
-                                 MEMTXATTRS_UNSPECIFIED);
-
-    return !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
+    return address_space_memory_is_io(&address_space_memory, phys_addr, 1);
 }
 
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133118.1471309 (Exim 4.92)
	(envelope-from )
	id 1v3IgX-0001Wd-19; Mon, 29 Sep 2025 18:33:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133118.1471309; Mon, 29 Sep 2025 18:33:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IgW-0001WP-Uj; Mon, 29 Sep 2025 18:33:16 +0000
Received: by outflank-mailman (input) for mailman id 1133118;
 Mon, 29 Sep 2025 18:33: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 1v3IgV-0001U2-Dm
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:15 +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 c241ef56-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:14 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ece0e4c5faso4274681f8f.1
 for ; Mon, 29 Sep 2025 11:33:14 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb8811ae8sm19065012f8f.19.2025.09.29.11.33.11
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11: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: c241ef56-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170793; x=1759775593; darn=lists.xenproject.org;
        h=content-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=23QTyPjiy3YtVC18SQIGMGuPQmXq870ERJAMX9bHv6E=;
        b=yz9Ho+iW6Hem25yjL6Z5dyrPGX8O43ZKREqA0rfTjODo/DoG02AahpMhJdcVQ/V42Y
         C0rj3lcUzIcDiYG2RWTtwuUotRFGvOiXOtMwgJSJ3b5JPj9vIkXs2fM2qcWQzOOYUf9K
         rHHVL/nnJq8V/QfR8DtZxxYOSiOwE1VoH3h+7o0aLV+j3SMFzeUMvLfDT6Rq93VeWQzV
         6Ea7RplwNpv6wglQbxkgMhN6zapv1sfnd4v5Hqi88wVbdhtglB5iJ8rRcwJfMwUSgqQO
         kzn1WkqrSH/WAY5A7jy9u76iiBCuUgPlFddsa3hKkb2kqR6N94TrluD1mVJ71VgB42SA
         ZB+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170793; x=1759775593;
        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=23QTyPjiy3YtVC18SQIGMGuPQmXq870ERJAMX9bHv6E=;
        b=O4G6VXDKwFxY8nkFwSWn+knRXlx/dw8Oe0G8XOHY701IrqLbYfe/q1ABThPCCWTjTc
         gRJafQ61mtiU8wk0TEyVBDc4jBPka/ZNfCboM/HwnjoyrDxBIc3JZR/bg/4P5tI7O5j2
         W58WX+uzrgTp9/4stGFZeNEXl0VZ+HICvH6zU4smZmSGYF2c1Xtr3AkdtyINP0lrZuob
         FZJSBtvB65zhBXKCaXNVjQ4D35NJznJrnUCL00yqUwG0EVNKe/QR9Kgjey7Kb24Q+YtS
         W9LBpTlboDRMf72m4J0/placJQRI5GPOy7PD9ydSWePBtgiHJGCbe6HMFKe5/rHF5FwJ
         TTcg==
X-Forwarded-Encrypted: i=1; AJvYcCUDRnW5lqXzifjfz0AUNJCo3jvRbxAOKV4LP8Cifp/70CW+f7ort3Lq/Fb9w+Guva8ShX2U72+kAag=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxkv391uu9tnlcrCa2+0j1SlFDO6LY0ScekUzZPkWi9Bxo5KWRN
	TbaNSMAScsq9lXVhNQRuCSS1yko9gb/bDItzsP+bVbrdpx+y7zG/CYid40er7ENjsbA=
X-Gm-Gg: ASbGncvcDljKzIz1d/PKUnOpyg2hf2Te+8z97NOMIlxm7IPra/C2uWx86lcLoMxVA/T
	JZo3sCN1d1M1BGV3G2/nJlwgbn/PiW89RGB5AleKmThPjZ+cn4UgMlURenIObwJPnOIOsa72ZWF
	BJIgRpiflZmVnapiPKqNxTa8hiefN06qCMozlvR5kEpwmL2G2kj+8LE2bj0DHy4OXJeUodxd0Fn
	mXWCVeBLKdzUDmjMCO7hiQrHhB09UNWeRfvc7MOkxdqwig/mpee6FFnorHVRx+7OwdNXV8isKPs
	Qmm/AlWvVwAjj7IXiFYidaE/svYtTr1hNXFMYUw8hh6DPFaIt5iSWWj0sEezRGKTW0+Kc156fM/
	QnOl2CJhEs1r6dRVcdvP8qGz7lG4Fm57XnIN7XzwubqeY+csoBPZf5etq9gcMV8Jf+QNSMGY0nq
	QeKO4vlaQ=
X-Google-Smtp-Source: AGHT+IEcDsohAJY1q22fsASxxAoYQtWlMdbA7XCLoeuebdYNdITcBiYeKjk+UAJn3Z9pxuCxt6ME3A==
X-Received: by 2002:a05:6000:2586:b0:3e7:65a6:dbf with SMTP id ffacd0b85a97d-40e429c9c42mr14229584f8f.6.1759170793465;
        Mon, 29 Sep 2025 11:33:13 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 03/15] target/i386/arch_memory_mapping: Use address_space_memory_is_io()
Date: Mon, 29 Sep 2025 20:32:42 +0200
Message-ID: <20250929183254.85478-4-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since all functions have an address space argument, it is
trivial to replace cpu_physical_memory_is_io() by
address_space_memory_is_io().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/arch_memory_mapping.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/i386/arch_memory_mapping.c b/target/i386/arch_memory_mapping.c
index a2398c21732..d596aa91549 100644
--- a/target/i386/arch_memory_mapping.c
+++ b/target/i386/arch_memory_mapping.c
@@ -35,7 +35,7 @@ static void walk_pte(MemoryMappingList *list, AddressSpace *as,
         }
 
         start_paddr = (pte & ~0xfff) & ~(0x1ULL << 63);
-        if (cpu_physical_memory_is_io(start_paddr)) {
+        if (address_space_memory_is_io(as, start_paddr, 1)) {
             /* I/O region */
             continue;
         }
@@ -65,7 +65,7 @@ static void walk_pte2(MemoryMappingList *list, AddressSpace *as,
         }
 
         start_paddr = pte & ~0xfff;
-        if (cpu_physical_memory_is_io(start_paddr)) {
+        if (address_space_memory_is_io(as, start_paddr, 1)) {
             /* I/O region */
             continue;
         }
@@ -100,7 +100,7 @@ static void walk_pde(MemoryMappingList *list, AddressSpace *as,
         if (pde & PG_PSE_MASK) {
             /* 2 MB page */
             start_paddr = (pde & ~0x1fffff) & ~(0x1ULL << 63);
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_memory_is_io(as, start_paddr, 1)) {
                 /* I/O region */
                 continue;
             }
@@ -142,7 +142,7 @@ static void walk_pde2(MemoryMappingList *list, AddressSpace *as,
              */
             high_paddr = ((hwaddr)(pde & 0x1fe000) << 19);
             start_paddr = (pde & ~0x3fffff) | high_paddr;
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_memory_is_io(as, start_paddr, 1)) {
                 /* I/O region */
                 continue;
             }
@@ -203,7 +203,7 @@ static void walk_pdpe(MemoryMappingList *list, AddressSpace *as,
         if (pdpe & PG_PSE_MASK) {
             /* 1 GB page */
             start_paddr = (pdpe & ~0x3fffffff) & ~(0x1ULL << 63);
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_memory_is_io(as, start_paddr, 1)) {
                 /* I/O region */
                 continue;
             }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133123.1471320 (Exim 4.92)
	(envelope-from )
	id 1v3Igc-0001uj-Bx; Mon, 29 Sep 2025 18:33:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133123.1471320; Mon, 29 Sep 2025 18: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 1v3Igc-0001ua-7Z; Mon, 29 Sep 2025 18:33:22 +0000
Received: by outflank-mailman (input) for mailman id 1133123;
 Mon, 29 Sep 2025 18:33: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 1v3Igb-0000iD-2V
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:21 +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 c56bb365-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:33:19 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-46e3af7889fso27784855e9.2
 for ; Mon, 29 Sep 2025 11:33:19 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc7d3780asm19281036f8f.52.2025.09.29.11.33.17
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: c56bb365-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170799; x=1759775599; darn=lists.xenproject.org;
        h=content-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=P3WGf5UHYCyuY+qdMKaaLuq+dGZ/nmDgi/rxgNJ1Ah4=;
        b=waulXQMdrAHfziQiNraoPlDiPYlPE+ca1viRcMdcCLNPu3uuTZJmJE/dPfRD27NNE/
         4fiKCDPPTZMZO15KbLiz/XaLHg+lquvPvv6JxpXVst3j1Enjg/b8cuhx0k8n8JiqjNik
         o8VmPyAsIwc2qY6O+WipTcImxtaqcV47/r7TrUE+fx8qaiYGU0mc/7IeyxwBRKtQqHvG
         BmdAGree7df165emhsz/rz2wdmtqasgl/6ozl1ieO3es5BHodgk/S6dLII32qP2K0+1W
         orapiO2Wswuh07BCtRZXLePnLt6VEVsOanopkhFkELMH8yCgtNl/sCYBhIxKcdKOg95x
         LABg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170799; x=1759775599;
        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=P3WGf5UHYCyuY+qdMKaaLuq+dGZ/nmDgi/rxgNJ1Ah4=;
        b=V0oEl12WBXbT93nEnKK0Kcs4SY3rjF2a+RU8kmhfHIbNRqW3XoYGJtKopWIKQ8hQqt
         rXLEuWHp778cINV7waBNa+weLMi68Q0Vd40lB/YKywtDkrK6M1Fqxvs4YpZgW3JxvqBc
         oTjnCTKRp9igboC9nqiNAbt0f7v8Grjd0t1K00ZO0jr3xvTYyqbtbpmyXihofLAYLWLi
         eQYwZv0ZttB9Zl2ixB+54hccDK9tDgu5ytFCarIHd1JbUCQCD+4yMuUyS+65xW2SHVIa
         K5GHWmklNPDRQl32UWb1nkcnd4k763nt6g7elrW8BFYbXUcthg5PTNIPXZPSO65Q4Prr
         oqwA==
X-Forwarded-Encrypted: i=1; AJvYcCXQc3M8kGW1UtZupfoYrHzlXQ1xAmYFg6oK1e+vM0chWKxqImdQ121x8YzxRcqlihnrUnybvkEgVtA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJvsjSUJ0u3PL5qPbQhjUi83y7+MqKAWF/hARF4oac0YH1aslt
	10erhcbFa7YPqcWkTMKZgTGwFYmZ9QPauFXtUiH4RALw/81KujMudVn5jf4RoQNE26U=
X-Gm-Gg: ASbGncunfwbHoQDV+dOoSEBz5EKdEs4LIVvY8RqkxV4gtWAwpBhROWU25fNqpaBqtb2
	MVseAlp9WqTkSx0w1Y6BazadDeIEhj9HBxEzxC2kXO4Jm8Kp+2kDZ+5uVew0TaMokg5aAht2ftT
	UKWchTTWJzgf+oQ95y7J6BfZmiZomlPZ2LNOf2NRmmyPya01+GXyANNQ8m4ItHAGuJP3sJGH1jU
	SSzKZenpjjHSBHXJhFDD8+rveED5HJaNGPCQlOzlaAc0quHyUz1uEv99xgKehUqkQ/JsJVEk/gg
	wSPZ9vtRGEXTlRpeRQjSRW0u2PWvQa6tjXaImN/IpSf736kgdy2grC2PKAoTafg4s1y3EdFwtqj
	oXe9+B9zMoUi9GB45xO5PYSStAAdityYZpwgRFciFnRYgITsWqt3hlvC+o38mZlw7joK1QwgbHb
	hp5SWRQbsejSUFcjkg7Q==
X-Google-Smtp-Source: AGHT+IECk0pxJcrABdWnp0wBblgE/rUdgkYk2QyHdrh6Fg0EQMQZuDnjhZ/xllYj8G986Z96HgDgnA==
X-Received: by 2002:a05:600c:1c01:b0:46e:5208:ded3 with SMTP id 5b1f17b1804b1-46e5208e228mr55680385e9.15.1759170798830;
        Mon, 29 Sep 2025 11:33:18 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 04/15] hw/s390x/sclp: Use address_space_memory_is_io() in sclp_service_call()
Date: Mon, 29 Sep 2025 20:32:43 +0200
Message-ID: <20250929183254.85478-5-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When cpu_address_space_init() isn't called during vCPU creation,
its single address space is the global &address_space_memory.

As s390x boards don't call cpu_address_space_init(),
cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.

We can then replace cpu_physical_memory_is_io() by the semantically
equivalent address_space_memory_is_io() call.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/s390x/sclp.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 9718564fa42..c0d8c335b44 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -16,6 +16,7 @@
 #include "qemu/units.h"
 #include "qapi/error.h"
 #include "hw/boards.h"
+#include "system/memory.h"
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/event-facility.h"
 #include "hw/s390x/s390-pci-bus.h"
@@ -301,6 +302,7 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     CPUS390XState *env = &cpu->env;
     SCLPDevice *sclp = get_sclp_device();
     SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
+    AddressSpace *as = cpu_get_address_space(CPU(cpu), 0);
     SCCBHeader header;
     g_autofree SCCB *work_sccb = NULL;
 
@@ -308,7 +310,7 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     if (env->psw.mask & PSW_MASK_PSTATE) {
         return -PGM_PRIVILEGED;
     }
-    if (cpu_physical_memory_is_io(sccb)) {
+    if (address_space_memory_is_io(as, sccb, 1)) {
         return -PGM_ADDRESSING;
     }
     if ((sccb & ~0x1fffUL) == 0 || (sccb & ~0x1fffUL) == env->psa
@@ -317,7 +319,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     }
 
     /* the header contains the actual length of the sccb */
-    cpu_physical_memory_read(sccb, &header, sizeof(SCCBHeader));
+    address_space_read(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                       &header, sizeof(SCCBHeader));
 
     /* Valid sccb sizes */
     if (be16_to_cpu(header.length) < sizeof(SCCBHeader)) {
@@ -330,7 +333,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
      * the host has checked the values
      */
     work_sccb = g_malloc0(be16_to_cpu(header.length));
-    cpu_physical_memory_read(sccb, work_sccb, be16_to_cpu(header.length));
+    address_space_read(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                       work_sccb, be16_to_cpu(header.length));
 
     if (!sclp_command_code_valid(code)) {
         work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
@@ -344,8 +348,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
 
     sclp_c->execute(sclp, work_sccb, code);
 out_write:
-    cpu_physical_memory_write(sccb, work_sccb,
-                              be16_to_cpu(work_sccb->h.length));
+    address_space_write(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                        work_sccb, be16_to_cpu(header.length));
 
     sclp_c->service_interrupt(sclp, sccb);
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133130.1471330 (Exim 4.92)
	(envelope-from )
	id 1v3Igi-0002Sy-Lk; Mon, 29 Sep 2025 18:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133130.1471330; Mon, 29 Sep 2025 18:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Igi-0002Sq-Hi; Mon, 29 Sep 2025 18:33:28 +0000
Received: by outflank-mailman (input) for mailman id 1133130;
 Mon, 29 Sep 2025 18:33: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 1v3Igg-0001U2-F5
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:26 +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 c8bb11f0-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:25 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-46e3cdc1a6aso27634205e9.1
 for ; Mon, 29 Sep 2025 11:33:25 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e59ac769asm2811925e9.4.2025.09.29.11.33.22
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: c8bb11f0-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170804; x=1759775604; darn=lists.xenproject.org;
        h=content-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=VjyCCW7HHI1dG8y1m+qgvriOV7CMEgsHNpX6hQdnX2g=;
        b=n2Lr4ocEkBUzchZUMThYeYkfUdbjxEdsy8/JhkIga8BAF0WvSOm1WN/3/E3K7RkAXL
         qm+88qfTxRMSCz1bOyfcfBf9+mZh2AW0yOxcWVA9o3AD3w62UNFUmcy8d6k3e+CVUQm6
         KRSZCdIwidwvTZUw3wXDKTjcHadYbsERN90GC2x7dlKVn/WHUDYV0FWQEbimx4w6TD6w
         eDEbxpcRd2XOkPOwsxqgnLYoihyE64tXpIYg7zjnpf+X7xd2iiwf4BMbxzRul9ogglYX
         fCelFeKvbj2WiuqjsqUmQ6UCHXkX96L3T27nktQDbNm/7Pg10Bid3OTm7A8IVM+udb6c
         5rzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170804; x=1759775604;
        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=VjyCCW7HHI1dG8y1m+qgvriOV7CMEgsHNpX6hQdnX2g=;
        b=RfCzbWt9lyeQMNvp5Aq2BbbAnE5EieG0Cmu/P6nRrfpui6nnz2w6H2Zo5MStk6YSSl
         nFA/lpIvv+yCPnwCvtnyR0sOYQbZLE3flCUH3taj4jiFxT4jysfHNRzfj+F0EjgeqVHT
         wPUZg9HwVuSkovc4PAv6xfHdxDs14Lh18kh6eNByHFk2Y9C+094KaIeBVp/lCZg4vQfv
         BpHkhhJ9XIYFJue82mhoHH202UbYOOWb08bxtWaGFVvcSacEgKTrkKx40HCEELzFMvY5
         RjEC1w+R+eRdHkHzeKBT/5LaJoiV8ootTd9vfa0/gW5iNhuxwaxpLRlRPNiYb3378b7T
         dTXQ==
X-Forwarded-Encrypted: i=1; AJvYcCVLBYaxtz22fRI+u/Xl9Xc2LmkXHYJze9zdRSTJpNqugwNK4gVPo3umCMFCddcf2TYyTYZYtT+54l8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcQw45Jw6wcGVGBw1rQIFFMBrs2JlhWTy7H0NTMltXRv8JiCUA
	MrNH4DiSlmNUQL6hSZkXreGp0c8PZt+FA+5a7myxidoadyIEFprCWHufhntYBKm8yO8=
X-Gm-Gg: ASbGncu5gD6OfdH8lfQ9RZGiKoTCvEXlyQnT+KVfDQ77oJCdSCrn3fizNg3/9YgWRJn
	on1V7LHQyRq+rb7R9DCKAL8iv4lITcEMmuRy1XEFrbzdyidMBAkL4UL8sUFD9IAwzrIxPelvTga
	WFXdtITVOkHICOzihQNT6UYP2aonTeyQ8P4F1G3loPx5BG7nht9reS3zbjtpVExxv1y2t/hzaw1
	swPXOkx8HerWiaWEd5kmiGKQ8BuK1oLI20sykNhsL4x1zR2d731T+Zo8XDf1SQ+37CO8E/Ha3Te
	IW/GacUBAd2dDQf0rTm9CTirYrVZtA6zPFQiT32ZlrULlawr5rU7OO7knWGtUQpiGYP+mwCVo1I
	aikEcgy8ghe0sl0wo5pXVvYtEAUdMPOLVXg6PqD07nRtTSALjCV/hnTKEt9kUCjHcgFS0JAc7
X-Google-Smtp-Source: AGHT+IHQ2XCQX3HS0p3adUQdcJQXlpyRbo0k/r6XrZhzUXT4d+zZkT16mDlxSIQ19wUJoBTgikwi5g==
X-Received: by 2002:a05:600c:c10b:b0:46e:33ed:bca4 with SMTP id 5b1f17b1804b1-46e58cea408mr12664365e9.15.1759170804364;
        Mon, 29 Sep 2025 11:33:24 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 05/15] system/physmem: Remove cpu_physical_memory_is_io()
Date: Mon, 29 Sep 2025 20:32:44 +0200
Message-ID: <20250929183254.85478-6-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are no more uses of the legacy cpu_physical_memory_is_io()
method. Remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu-common.h | 2 --
 system/physmem.c          | 5 -----
 2 files changed, 7 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e413d8b3079..a73463a7038 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -149,8 +149,6 @@ void *cpu_physical_memory_map(hwaddr addr,
 void cpu_physical_memory_unmap(void *buffer, hwaddr len,
                                bool is_write, hwaddr access_len);
 
-bool cpu_physical_memory_is_io(hwaddr phys_addr);
-
 /* Coalesced MMIO regions are areas where write operations can be reordered.
  * This usually implies that write operations are side-effect free.  This allows
  * batching which can make a major impact on performance when using
diff --git a/system/physmem.c b/system/physmem.c
index 18b3d38dc0c..fd2331c8d01 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3763,11 +3763,6 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
     return 0;
 }
 
-bool cpu_physical_memory_is_io(hwaddr phys_addr)
-{
-    return address_space_memory_is_io(&address_space_memory, phys_addr, 1);
-}
-
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
 {
     RAMBlock *block;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133143.1471340 (Exim 4.92)
	(envelope-from )
	id 1v3Igo-00032a-5c; Mon, 29 Sep 2025 18:33:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133143.1471340; Mon, 29 Sep 2025 18: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 1v3Igo-00032L-2Q; Mon, 29 Sep 2025 18:33:34 +0000
Received: by outflank-mailman (input) for mailman id 1133143;
 Mon, 29 Sep 2025 18: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 1v3Igm-0000iD-TB
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:32 +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 cc042e6e-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:33:30 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-46e37d10ed2so48131645e9.2
 for ; Mon, 29 Sep 2025 11:33:30 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e42eee0b6sm125709405e9.10.2025.09.29.11.33.28
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: cc042e6e-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170810; x=1759775610; darn=lists.xenproject.org;
        h=content-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=PEWvJYylRbkib8yXjJlQ3r1Fc9sZ+i1G3AKqr/Nn6n8=;
        b=GCwt3AlTYFW6tyHaW+MemQnB1CJRubd6bmE14DQO88o9hoMVzkTydUXloKV3CDRjfM
         lUakLoAlMhiCxQBHjr/v2L1z0mMSF+I+rM/bD6yVuVTUkJxLpTk868HHWkqOHCRV5N1x
         P4Wko6mV+Iw3K/pGbsJR/HnUJ2rM0AMYMUZuD6mHbtz23bM5kS+qgafY7C7ZHxN163/7
         X5cRpYwjVR2tc6NO2KY2xwadsN6VHPb2dm7bCDfHrBvMp2no0Zu6XrSpgFmXkDfVWTk2
         2RaJBBf1BQBYGTG5Wm4EzDeJv5c5Dj4jGFbmLjnIM7k6Y/iA+P6KCpazrlvNfURBSMDF
         HANA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170810; x=1759775610;
        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=PEWvJYylRbkib8yXjJlQ3r1Fc9sZ+i1G3AKqr/Nn6n8=;
        b=TqYak0A4D4CCFrzPSV8+7VdIIRy7nHmO5wk+/+w/DiLYZa+TA8cxMKSCXtltIVwCG/
         mQwd4GZKnvNVe16XdEqg+F1ZVWBUMToBr2GmSbvvie/Sqk8MaHGGqq1nEf+yGYB1KqAU
         q6pYPMAV3bywZf69NT/3Cqywi29F6XVqOTw4x4zXBSuR3CdEKd34VmlB4WeblaMBpHFm
         lmbVj+VB3pLqB0iRnKSUpMUez9Mp5+ZiMHzsYeHTt+2XujLgF8qYatxBO+Ms1R6M+ldi
         W0woflHSNSnG2uSL4RQX7JgAbXhxY3Ke1k71R2qp3UIcEgHl2U1rQvmIW1oW67x76Z9b
         IqUg==
X-Forwarded-Encrypted: i=1; AJvYcCUF20FzEM11z3Ykz21S377TxYK1+P1ijtQyyb2diitwNme7vtYUoe245YXz0nCiSWNhPadGeuC5YWs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz84COtTaDLpqc3ZxPi/zPrNxin8oxrbdGKIiY6qQycJGcdUpWY
	Ji9Pz/85x8ro+FBaU9F+JmyCs5P5/8cNnK3uE8kUpQ941FMFQnpew28aW3DdMxe2Kdk=
X-Gm-Gg: ASbGncsnl5oF2IKkpBZStVVL+hvHQjDHNQh1hvyZmRUH7kmS6A96GHg988dJ7REoVzY
	hzbUxFNR67qMbGSftKjideSXgv6v/oMbuhGNqn7VwU0emhWePyli+SOQFTWZLuo9La5+J2pNnBA
	1QvMu1dj+RzFkAsfQAJAVtsocWLzVZgu5EKkG7CuPcek/E3GYG+4V1oBkVB4cLCnK7+suM1BZKS
	y5NRUX+O7m6rcb/hegywZny0iOsnF3lopM8CIyfXJ/1NWPii/+rJGW4I0XqogaFeZ7OgErd/3By
	UXQJtPLxS69lJ5Ovqer/Fwdb+QDBp8OVbQQIrJBZ1atKqjB0TI6I3DhjCCZpEm/CdqJwYeoP2BE
	aBPE3DH1SB4BxaYPdkHFrDGf7NM28xkXIux++HcNH2WgbxDC+WU2arlDrO3EqxLXM+KY3VOsuVZ
	yAu3pmUP8=
X-Google-Smtp-Source: AGHT+IFlycBakp5EkJDN7dbxjK7i5JzbYULjjWcaNxhP9aXTBI6jbDWLO50skO4rhy6UhWAATwe2kg==
X-Received: by 2002:a05:600c:609b:b0:46e:4814:4b6f with SMTP id 5b1f17b1804b1-46e48144bbcmr82071665e9.2.1759170809908;
        Mon, 29 Sep 2025 11:33:29 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 06/15] system/physmem: Pass address space argument to cpu_flush_icache_range()
Date: Mon, 29 Sep 2025 20:32:45 +0200
Message-ID: <20250929183254.85478-7-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rename cpu_flush_icache_range() as address_space_flush_icache_range(),
passing an address space by argument. The single caller, rom_reset(),
already operates on an address space. Use it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu-common.h | 2 --
 include/system/memory.h   | 2 ++
 hw/core/loader.c          | 2 +-
 system/physmem.c          | 5 ++---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index a73463a7038..6c7d84aacb4 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -156,8 +156,6 @@ void cpu_physical_memory_unmap(void *buffer, hwaddr len,
  */
 void qemu_flush_coalesced_mmio_buffer(void);
 
-void cpu_flush_icache_range(hwaddr start, hwaddr len);
-
 typedef int (RAMBlockIterFunc)(RAMBlock *rb, void *opaque);
 
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque);
diff --git a/include/system/memory.h b/include/system/memory.h
index 6cfa22d7a80..00203522ae4 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -2977,6 +2977,8 @@ void address_space_cache_invalidate(MemoryRegionCache *cache,
  */
 void address_space_cache_destroy(MemoryRegionCache *cache);
 
+void address_space_flush_icache_range(AddressSpace *as, hwaddr addr, hwaddr len);
+
 /* address_space_get_iotlb_entry: translate an address into an IOTLB
  * entry. Should be called from an RCU critical section.
  */
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 524af6f14a0..477661a0255 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -1242,7 +1242,7 @@ static void rom_reset(void *unused)
          * that the instruction cache for that new region is clear, so that the
          * CPU definitely fetches its instructions from the just written data.
          */
-        cpu_flush_icache_range(rom->addr, rom->datasize);
+        address_space_flush_icache_range(rom->as, rom->addr, rom->datasize);
 
         trace_loader_write_rom(rom->name, rom->addr, rom->datasize, rom->isrom);
     }
diff --git a/system/physmem.c b/system/physmem.c
index fd2331c8d01..dc458cedc3f 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3214,7 +3214,7 @@ MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
     return MEMTX_OK;
 }
 
-void cpu_flush_icache_range(hwaddr addr, hwaddr len)
+void address_space_flush_icache_range(AddressSpace *as, hwaddr addr, hwaddr len)
 {
     /*
      * This function should do the same thing as an icache flush that was
@@ -3229,8 +3229,7 @@ void cpu_flush_icache_range(hwaddr addr, hwaddr len)
     RCU_READ_LOCK_GUARD();
     while (len > 0) {
         hwaddr addr1, l = len;
-        MemoryRegion *mr = address_space_translate(&address_space_memory,
-                                                   addr, &addr1, &l, true,
+        MemoryRegion *mr = address_space_translate(as, addr, &addr1, &l, true,
                                                    MEMTXATTRS_UNSPECIFIED);
 
         if (!memory_region_supports_direct_access(mr)) {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:33:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:33:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133151.1471350 (Exim 4.92)
	(envelope-from )
	id 1v3Igs-0003OP-EL; Mon, 29 Sep 2025 18:33:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133151.1471350; Mon, 29 Sep 2025 18: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 1v3Igs-0003OG-AV; Mon, 29 Sep 2025 18:33:38 +0000
Received: by outflank-mailman (input) for mailman id 1133151;
 Mon, 29 Sep 2025 18: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 1v3Igq-0001U2-Ij
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:36 +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 cf51b038-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:36 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-46e3cdc1a6aso27635575e9.1
 for ; Mon, 29 Sep 2025 11:33:36 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2a996c03sm236802335e9.3.2025.09.29.11.33.33
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11: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: cf51b038-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170815; x=1759775615; darn=lists.xenproject.org;
        h=content-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=JRsfrHQBMjnrXhlxfeiXrXfyISPq/9LUWh417J9QSAY=;
        b=Fmwo9CfvXaYB/hN0GcuL6pwB0lrzu5OgHkjy5Y/C+InDUhjdrM4/cxoEfYc/YP7XWJ
         dTkRTAEeqzY5sZCVVheJPeIwZUkcvgzD/ebY+9zmI/hnSl86dOhFwevkS6bHnpyy3slB
         Z9rmonKYH3sNQKsFmvyApYlEW2d18y4umIEFVY7RgK6A/oyx+odcnG91ZIPh0D/s++DU
         vzGcBEl6eSIdQt0MbPIGgrK0p+UxDvRSgVBBkEnTU+rlyUzGDj8nOn2ODK3HzYcHUNSg
         xxEybFBSz+I9ephHdp059eyHsikdiyB7NzucVqPLGHl5UGIV60D9b8OFDrtUd3MvNDZg
         IT5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170815; x=1759775615;
        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=JRsfrHQBMjnrXhlxfeiXrXfyISPq/9LUWh417J9QSAY=;
        b=TaX9ry1Hr7DscG8ch24xkE4aAvMFJRS4r+GvnLhPeBzblZrbBHrQuYsv6d48WOo27U
         SlyHoW+nEsYoC49Ch6tg2UjKt/DlvA7dR5vjA8bCOHaCtHYPO4dDgpalGLmgzoFqKToD
         i84KyBWzKtdYu4EI8KBmEBhOr6WvEekkGtEKOXUIgFQHZ1CMO6Axgm+EBDZNbFnCzXhm
         GT8CsyWMpQ/xu9rwZOVXLV+hXTEKbOWhshqn0HNEyOec3rY5NrCzLyxXvvptPqfX4/Y6
         3LR3yHss0wngvPBSz3Uib1BF1rEehnA6sHMl4WckOzV860urd69jP89Ucehs2AQz39Pi
         3lDw==
X-Forwarded-Encrypted: i=1; AJvYcCVkYSs7YDIX/XXTIym2RMGD1FZgPVFeHgEiwEhTTWTI/vcJx67zDPYzbDF/FRaWDW01evEAV+cd6FI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxDfyECbHg716dmgtrM592p5K4rGyWPyDEzg9WTPINHUhyN7AQU
	gLe7SoxioGaV/Wa91V7jss7wE/lFfSauEULIUlaXuoHw9qzXQj5YJt2sJunMcbKT3rs=
X-Gm-Gg: ASbGnct0DRyw9Eo2UVcLwLt9MzWtR86aTjJxwUhxqBJa1BQ/BxzKVvu4CgD4pdIxVjN
	N7YdEIGXBoInFsMX6MLmcr7Uf9uvvok4o50puaQ2RmiE3eMbX2y31kLrJlimptR3qG0uYsR6cor
	CBeCCEDF+XxSZ2B2Cb5Do9e5evJCeba0Y7wbrLOcPKGW4E6YSmSacJEmH5tjRu1G5Suzp0xE8gY
	Xv0JMOi/jptYcuuQ393DJJ4RJu7XYWD61PycYeWwkPJkiMsrOVcxE98jCt/sapxGl6X91EsAaP7
	sMyKDpUnEtunxyZppMbgwXufeBi9sn2g+L/rmPF7ySJyDxG6z+1X5vrejN8QO/LjYq+WcRrsmjF
	qsdizwIC43TrQ8pR5tb+UXnRND16azdEXhatNo24ZXlzsd+Ur+sCMiKASV+6LYmOfyaqR20lO7x
	y7MbX2+y8=
X-Google-Smtp-Source: AGHT+IHnK2dcf5REXjP75RtjLmG0FRF3SPCN5/ScyVADUNX4W97Ctb9XEl/zwwWPFNLidNab3G3GOQ==
X-Received: by 2002:a05:600c:8285:b0:46d:c045:d2bd with SMTP id 5b1f17b1804b1-46e58ac80f9mr17543845e9.8.1759170815433;
        Mon, 29 Sep 2025 11:33:35 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 07/15] target/s390x/mmu: Replace [cpu_physical_memory -> address_space]_rw()
Date: Mon, 29 Sep 2025 20:32:46 +0200
Message-ID: <20250929183254.85478-8-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When cpu_address_space_init() isn't called during vCPU creation,
its single address space is the global &address_space_memory.

As s390x boards don't call cpu_address_space_init(),
cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.

We can then replace cpu_physical_memory_rw() by the semantically
equivalent address_space_rw() call.

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/s390x/mmu_helper.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index 00946e9c0fe..4e2f31dc763 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -23,6 +23,7 @@
 #include "kvm/kvm_s390x.h"
 #include "system/kvm.h"
 #include "system/tcg.h"
+#include "system/memory.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
 #include "hw/hw.h"
@@ -522,6 +523,7 @@ int s390_cpu_pv_mem_rw(S390CPU *cpu, unsigned int offset, void *hostbuf,
 int s390_cpu_virt_mem_rw(S390CPU *cpu, vaddr laddr, uint8_t ar, void *hostbuf,
                          int len, bool is_write)
 {
+    AddressSpace *as = cpu_get_address_space(CPU(cpu), 0);
     int currlen, nr_pages, i;
     target_ulong *pages;
     uint64_t tec;
@@ -545,8 +547,8 @@ int s390_cpu_virt_mem_rw(S390CPU *cpu, vaddr laddr, uint8_t ar, void *hostbuf,
         /* Copy data by stepping through the area page by page */
         for (i = 0; i < nr_pages; i++) {
             currlen = MIN(len, TARGET_PAGE_SIZE - (laddr % TARGET_PAGE_SIZE));
-            cpu_physical_memory_rw(pages[i] | (laddr & ~TARGET_PAGE_MASK),
-                                   hostbuf, currlen, is_write);
+            address_space_rw(as, pages[i] | (laddr & ~TARGET_PAGE_MASK),
+                             MEMTXATTRS_UNSPECIFIED, hostbuf, currlen, is_write);
             laddr += currlen;
             hostbuf += currlen;
             len -= currlen;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133182.1471370 (Exim 4.92)
	(envelope-from )
	id 1v3IjG-0005Ni-1m; Mon, 29 Sep 2025 18:36:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133182.1471370; Mon, 29 Sep 2025 18:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IjF-0005NZ-VN; Mon, 29 Sep 2025 18:36:05 +0000
Received: by outflank-mailman (input) for mailman id 1133182;
 Mon, 29 Sep 2025 18: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 1v3IhN-0001U2-GB
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:34:09 +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 e2e7109f-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:34:08 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-414f48bd785so2659460f8f.1
 for ; Mon, 29 Sep 2025 11:34:08 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab4897bsm234657245e9.17.2025.09.29.11.34.06
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11: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: e2e7109f-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170848; x=1759775648; darn=lists.xenproject.org;
        h=content-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=8IprTsHK83+//o00MiFkngA2W2onv/YPnwzWQKra2w8=;
        b=B1qC8Pa65WojuPUH9YkoSCzr47EcA0CzK9i9qnLsU34vd6+4Y8RpwaK0L1nvzNFjbZ
         h2d8ESpnFW4CMh0ElPv/4N/wK4TsJFhuxUB/jNRgWQTR4JVVshZqTbwV/C/Gi8V5j9sZ
         WQqFhtpW9ww6S8hWWGtCIIlpZstvvp3Rs7Q0KOLrn5Op9T0VzFPC/E1bD5FlS3Liiv6d
         7dbt60E/utGNmn/5OxbbLD9egCWTGv4VtEIZDkNQyAJSCPDI+oJZdquk9JGPXLdjE3tm
         LuMndkin7uBOAW9/tEDHvyYPvrZziIuT6e09vZOAGcIVEUwN0NS54OokkJpndHpkPqi7
         eD3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170848; x=1759775648;
        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=8IprTsHK83+//o00MiFkngA2W2onv/YPnwzWQKra2w8=;
        b=naORXrUOOZZIH60btQzZq5cajyCLYaRk1+tk+5ja2ZU5XRXjfIAmNgcfEzBb7oMmhF
         DsTFceoNrmo3yBVy4WrS7u0aR3WEgR9jFbzyLFwZ8yuuEIs2sYGrAo4wMyfzGxKUPAyg
         YBMbY0vXX+JshWI9uudh0Qy+gs1t7Ux2mGG+2Bt3a6ny0B15shm762VSZp3WBvkBYXWd
         TW1XbNeFz7VV2TSUfXXIPu+kV7qkljQdYuqofSaQ4+p2Ce9GgnAqnL2K5wW0+5LciX4s
         XV6jtlWiNS4Hzs9w/3GujpUd/TdWnwCze4hx/j6e1hP4OBz5gnQ258nZkWu0SRz+dxIp
         2Rxg==
X-Forwarded-Encrypted: i=1; AJvYcCVevjMw1OM0Tryla8JhSOp+ro+1pnN/8wt80mpnfdkaX2nQNy9tv+GsX4/Chn/iw+QzxmRxy0hsImo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2iQv9UG5B+8+Z2hvLsVET6mVw3pAhWVkcE5QoBj4zSo9PMjm9
	2tdI1Y9FtZBYfMU+8sVH+/pfNUazebcr4YQeio9buLsl41zHlVfJ/rRm9WHTwqlD7lo=
X-Gm-Gg: ASbGncvAP2rIFb86RejimQnmeuJ2WsKr3txEOKK3N2CTmqw41Tu4jUQ0INf8acJgKhm
	/3RM/sQf35JaCM8mhDheUwPUu2tWJRseLO5uZjvDUW6AVtgtU8qP/6xheY3QHq6nDFL0v7xfNX9
	AIakgsLSo6asaGastOMRRtZnjoW0lgrq2ua9714sm0pwaKLt8ApWHS5lQjCmZXmbvQX9TB/aMQb
	NlaSdX8lNTI3jvF7jnMfTabivnaz9seMc8lHLOBK+vrRmOdSn3Xzgc0YM7xgpkItA//Blb8X3rn
	PQnDtFStoAqLGUwXVxoxQfwiP0KPcVcT9V3p6WcY4Bh9H3i4J7Jzhxxm8a3O8oE9i2dW3JwzqJb
	hekAoTOXy9rUpv+qGR6guCxtmM6yJ0Mf8z9p7mGHrcHphniGGXvq13PqJPkQ3Kd+s2zgymh9u
X-Google-Smtp-Source: AGHT+IF/C6oWT8UwF1sEc7lk12OQ3847JVrL7Xi1bCnoAAIGAt33I27+pHrZ0wCfK5j980LBTwOBoA==
X-Received: by 2002:a05:6000:1846:b0:3ee:15b4:846c with SMTP id ffacd0b85a97d-40e44682b8dmr16577132f8f.28.1759170848080;
        Mon, 29 Sep 2025 11:34:08 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 13/15] system/physmem: Inline cpu_physical_memory_rw() and remove it
Date: Mon, 29 Sep 2025 20:32:52 +0200
Message-ID: <20250929183254.85478-14-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

After inlining the legacy cpu_physical_memory_rw() in the 2 functions
using it (cpu_physical_memory_read and cpu_physical_memory_write), we
removed all its use: remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/devel/loads-stores.rst            |  4 +---
 scripts/coccinelle/exec_rw_const.cocci | 22 ----------------------
 include/exec/cpu-common.h              |  2 --
 system/physmem.c                       | 13 ++++---------
 4 files changed, 5 insertions(+), 36 deletions(-)

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index f9b565da57a..c906c6509ee 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -460,10 +460,8 @@ For new code they are better avoided:
 
 ``cpu_physical_memory_write``
 
-``cpu_physical_memory_rw``
-
 Regexes for git grep:
- - ``\``
+ - ``\``
 
 ``cpu_memory_rw_debug``
 ~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/scripts/coccinelle/exec_rw_const.cocci b/scripts/coccinelle/exec_rw_const.cocci
index 1a202969519..4c02c94e04e 100644
--- a/scripts/coccinelle/exec_rw_const.cocci
+++ b/scripts/coccinelle/exec_rw_const.cocci
@@ -21,13 +21,6 @@ expression E1, E2, E3, E4, E5;
 + address_space_rw(E1, E2, E3, E4, E5, true)
 |
 
-- cpu_physical_memory_rw(E1, E2, E3, 0)
-+ cpu_physical_memory_rw(E1, E2, E3, false)
-|
-- cpu_physical_memory_rw(E1, E2, E3, 1)
-+ cpu_physical_memory_rw(E1, E2, E3, true)
-|
-
 - cpu_physical_memory_map(E1, E2, 0)
 + cpu_physical_memory_map(E1, E2, false)
 |
@@ -62,18 +55,6 @@ symbol true, false;
 + address_space_write(E1, E2, E3, E4, E5)
 )
 
-// Avoid uses of cpu_physical_memory_rw() with a constant is_write argument.
-@@
-expression E1, E2, E3;
-@@
-(
-- cpu_physical_memory_rw(E1, E2, E3, false)
-+ cpu_physical_memory_read(E1, E2, E3)
-|
-- cpu_physical_memory_rw(E1, E2, E3, true)
-+ cpu_physical_memory_write(E1, E2, E3)
-)
-
 // Remove useless cast
 @@
 expression E1, E2, E3, E4, E5, E6;
@@ -93,9 +74,6 @@ type T;
 + address_space_write_rom(E1, E2, E3, E4, E5)
 |
 
-- cpu_physical_memory_rw(E1, (T *)(E2), E3, E4)
-+ cpu_physical_memory_rw(E1, E2, E3, E4)
-|
 - cpu_physical_memory_read(E1, (T *)(E2), E3)
 + cpu_physical_memory_read(E1, E2, E3)
 |
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6e8cb530f6e..910e1c2afb9 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -131,8 +131,6 @@ void cpu_address_space_init(CPUState *cpu, int asidx,
  */
 void cpu_address_space_destroy(CPUState *cpu, int asidx);
 
-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write);
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
 void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
 void *cpu_physical_memory_map(hwaddr addr,
diff --git a/system/physmem.c b/system/physmem.c
index 5a0ee3b8e58..93e9550338f 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3181,21 +3181,16 @@ MemTxResult address_space_set(AddressSpace *as, hwaddr addr,
     return error;
 }
 
-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write)
-{
-    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
-                     buf, len, is_write);
-}
-
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
 {
-    cpu_physical_memory_rw(addr, buf, len, false);
+    address_space_read(&address_space_memory, addr,
+                       MEMTXATTRS_UNSPECIFIED, buf, len);
 }
 
 void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
 {
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
+    address_space_write(&address_space_memory, addr,
+                        MEMTXATTRS_UNSPECIFIED, buf, len);
 }
 
 /* used for ROM loading : can write in RAM and ROM */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133176.1471360 (Exim 4.92)
	(envelope-from )
	id 1v3IjE-00055S-Qq; Mon, 29 Sep 2025 18:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133176.1471360; Mon, 29 Sep 2025 18:36: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 1v3IjE-00054c-O0; Mon, 29 Sep 2025 18:36:04 +0000
Received: by outflank-mailman (input) for mailman id 1133176;
 Mon, 29 Sep 2025 18:36: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 1v3IhU-0000iD-Ck
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:34: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 e62002a6-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:34:14 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3ee1381b835so4178802f8f.1
 for ; Mon, 29 Sep 2025 11:34:14 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2a7c8531sm237281965e9.0.2025.09.29.11.34.12
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:34: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: e62002a6-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170854; x=1759775654; darn=lists.xenproject.org;
        h=content-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=MBpejQiq0e/vydo49FSQoIaJ0P/BjZpeA7dR40L/9NI=;
        b=BliYw8ObxLx0c2q/rLWRW/7rj/rwztZlcklyFoN5poh9KkHSmpLhlQtuvdVdg/9Fru
         wdXAAKD5LEr84Y+U8jlGNoPUaSVesTvfgB2mED8CpmHX7zMl6tIjEUPDmEc0wwbtiung
         lNts7nCgL/PNjEnMygd/6hvlHimwsX+5/6XepUIo0JWGDj0kDXGRAEzDPf5sPU9weGXk
         JfYbO4mcuDoIYQLPIPSjpwaf/amNKGwmpWwl2352veYY01CPevanVjYdrDAoEVaC294K
         DJwZeymUgIIIyAjOfN+ChrCCYy8vKfp30BC8wHTGGIRwAgQklQXOoNbWW7jlogoo8+a8
         Bjgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170854; x=1759775654;
        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=MBpejQiq0e/vydo49FSQoIaJ0P/BjZpeA7dR40L/9NI=;
        b=nLlghcP4GXq9wyDS5oNMpkfMJSteDpBuxPbWhoq+ORGfOzziVfwR/wc9wvZRKiSGgF
         4QWocVs431IWYSqlfj6QcwDbXeeZvU2vTequuTsVsGbJ24nRa0QCOuV+IIxt72Bnf6px
         dj4EMaCQTSlV7oCRMINOALso1QM+duUAlJXcUqtc0n4S6MA2ef5U48WOgS8Fzo356Vbe
         PQktNcpIjqI9izHTu6gct9i7fyEOIV1EtcFVRTaxmg1IcGqN5mTKpMjey4H/C28ojr6D
         FaerTMt2izDWvLKUEYWzbioFMCCnoYAPlxvoXSToYAQFNDKENdtTgnferfmi3esaA9eZ
         JSjw==
X-Forwarded-Encrypted: i=1; AJvYcCXxkQrXI9fpn+CdzqVDCQq526Ut+lLBpGFS1CQ6fQ+b/WV1p4DEElbWHSmFUob+Hw8JmoX4sVUMzGM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJqDiwGrPPWSxn2Gb0rGP5ACbbWOG6qo9LAA23fMueOi3Fe8WG
	6laUtis7z7EYZQ0QnR+GXMCnoLezrwJ4pg/2fTLU551A0V/IN7ikxbxZ3dVhcg+BpUQ=
X-Gm-Gg: ASbGnctv7vpJZs0R78gVEvqSno2uKxMA9TqCsa5S6Gs38ifR04Rln2Wcwl4mUOTXjn9
	QWjAYaquJHbG6vMZxF0XCshCZbUXsc1E1eMOz/AxtIWQFrszk9nVEO4WAKMdzm0qTYTzvN3DQIS
	GQQmzMDDi1qsrJnJNWOVIe3e1IAJAluPdJA2f/lYtEZKVqwywIr9wDch+/0oT15VfvzGBymGwzz
	JZmokCGXtY2CGbv41KccjnQd+1PK7Jb8i4+p89h72TeI7UoB5tFN1PjUrAoL/MwISxBLpgLgljd
	8gThzzmVy2PhBggBr6jb/C1F/K40Dj60Alke4zqwBkGBHpJieuLI/9jxEujF00EVwMsIicpvPEu
	CwABIRNde3nOzyhxno0hGVtGME+Duw/yZlBSi/BQz3VWNt0LzHL6LjY8Jfeq+GjaS0cS238WSFx
	Eo/gm7GRE=
X-Google-Smtp-Source: AGHT+IGDdDVnNCTQHNmf7VOOiV8zymTG0ZaCom+HQXr9Sc1CkJ/8s/f399s7GfQrqulF9pKPADkmMg==
X-Received: by 2002:a05:6000:22c5:b0:3ec:d78d:8fde with SMTP id ffacd0b85a97d-40e4ce4bademr17302303f8f.44.1759170853668;
        Mon, 29 Sep 2025 11:34:13 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 14/15] hw/virtio/vhost: Replace legacy cpu_physical_memory_*map() calls
Date: Mon, 29 Sep 2025 20:32:53 +0200
Message-ID: <20250929183254.85478-15-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Use VirtIODevice::dma_as address space to convert the legacy
cpu_physical_memory_[un]map() calls to address_space_[un]map().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/virtio/vhost.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 6557c58d12a..890d2bac585 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -27,6 +27,7 @@
 #include "migration/blocker.h"
 #include "migration/qemu-file-types.h"
 #include "system/dma.h"
+#include "system/memory.h"
 #include "trace.h"
 
 /* enabled until disconnected backend stabilizes */
@@ -455,7 +456,8 @@ static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
                               hwaddr *plen, bool is_write)
 {
     if (!vhost_dev_has_iommu(dev)) {
-        return cpu_physical_memory_map(addr, plen, is_write);
+        return address_space_map(vdev->dma_as, addr, plen, is_write,
+                                 MEMTXATTRS_UNSPECIFIED);
     } else {
         return (void *)(uintptr_t)addr;
     }
@@ -466,7 +468,7 @@ static void vhost_memory_unmap(struct vhost_dev *dev, void *buffer,
                                hwaddr access_len)
 {
     if (!vhost_dev_has_iommu(dev)) {
-        cpu_physical_memory_unmap(buffer, len, is_write, access_len);
+        address_space_unmap(vdev->dma_as, buffer, len, is_write, access_len);
     }
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133183.1471376 (Exim 4.92)
	(envelope-from )
	id 1v3IjG-0005QX-Bl; Mon, 29 Sep 2025 18:36:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133183.1471376; Mon, 29 Sep 2025 18:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IjG-0005Pi-5P; Mon, 29 Sep 2025 18:36:06 +0000
Received: by outflank-mailman (input) for mailman id 1133183;
 Mon, 29 Sep 2025 18: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 1v3IhC-0001U2-6k
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33: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 dc36c137-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:57 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-46e384dfde0so51429035e9.2
 for ; Mon, 29 Sep 2025 11:33:57 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb9e1bd14sm20127006f8f.28.2025.09.29.11.33.55
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11: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: dc36c137-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170837; x=1759775637; darn=lists.xenproject.org;
        h=content-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=U9bErLRqv9kjbdzs2kwz9FzL8C8SAPMQ12Esuz3D9Fo=;
        b=gnvR+fdIZooHKgj7wLHK+6Bi6IpBiDx3+6WxyqhRU0GrezC5Z3bk8R07XrqirNWSMs
         LC5IpCxvMh23eSoM3py0Bd52Hz/d6cQjulxcVCvMZa6boTQZWaumgm8yV2Bj39qBVYIv
         +CmFRd17tTA3V11BpZXdvmEJNiGh4TKiQrBjuA0i/aOYP23NTookydPe36r4n4lOMzH/
         d8AMZxwmgi0PequktmEH9usP21D8S0VKOhWw7ns029OTAUbyJoFSDRYyBcXyt49uRsF3
         Zkd/+D+VuKiJZMnCuK4fn5A0Tgu71mVVxlmDDWmhpSKyxN2vubuFBPFC5TEMH7sgYMx1
         PxIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170837; x=1759775637;
        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=U9bErLRqv9kjbdzs2kwz9FzL8C8SAPMQ12Esuz3D9Fo=;
        b=nL6QrLpUyt5hKVBWyTuMxBqcAZsV6QNm3/1PXnZ0saVhIO9e6pqM36JJL81nBkehOz
         Oq+F6XLykYI/N8fDu+mJMF5GBuEYQEnAVjFp0tSk3WXHUzlCgwbH253BVFhnjwPyZsPe
         mkT+R6GJphiM1MuLqSBDcvDm6YPRle3nTh4W2TgfeD00NXp40dLLnt2pPt7NwPrqk5//
         OwOiBOvj70F8Aey2rRWSHdyOXshvHGb7Jr7l/lTjBBcQjDvN7iEcoXoTYqDMj3VtxmY/
         bVTJPRyo1Wr/6zZWsavdJEP+fIL1qkSkldckaz0ld7fzXG8QvKi1M39iGwQPT+jOy7Cy
         681A==
X-Forwarded-Encrypted: i=1; AJvYcCXZZN60bgHwbVn2PCSY0pEdF/NHdJFySxG2eOwIJblQtS72mkgb3/zM2Rxp6+H5wK+dQa0yuyHdjhM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZnbTUhCcduYxXvNNrQrUAE3eGH8qP7KRZoacrsibvWvk5MvET
	q3lae2K7vBIBX5z7ZkfM3SJD78mvy3UlLNjf+INNuqienl59jZHHk8aNFLqXAjC/DMs=
X-Gm-Gg: ASbGncte2lY0gAqumM7a/ooewSp7FBZxf3lJ3T0bmDz2u9x7v+J8e3ia8QucdZqeMTu
	98qoLMjI8MJQe4tmLcX9uK5+Z/ZWhCdZY47zUAJtu9quHhw/lM1lfk4g8fBJ6jHNw47rykpJ5Fh
	/z9qGzUSi77TSUfLat/MP0qjYUxil/g+nF46QhDnb8DfhmS+0Q5eOmJIwlsznN7Znm2ltlEq3gP
	ufqdW7x3E3HUNUjo9R+RemJyE96tR6ZdlufswrEC8AP7/d/gtUwQChArnhwrQm9tW7mBsSB03xD
	VAuFaoemvBcyjRMV+u8SjORY8iKiHG8UVFbFBr6Opk3chSr1rB4NkbyJ4CSZvmIcSgJ57u4zIQs
	3cM+H0xDavFEFZmvembsfGLYnkmC6cgpJ/BnWEus1uENTKcPJ/y+a5tkUMa+uNJEd4GavT9DwMp
	zO2Z7J2BU=
X-Google-Smtp-Source: AGHT+IFV+pWpl9RpYQY3/vKNUQDjfsPx6DQqux2wn16tRZPr0u8FrK0pJwBF+V9pyB/rSvhEdc2qCg==
X-Received: by 2002:a05:600c:4b16:b0:46e:326e:4501 with SMTP id 5b1f17b1804b1-46e329ba996mr129660275e9.10.1759170837108;
        Mon, 29 Sep 2025 11:33:57 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 11/15] hw/xen/hvm: Inline cpu_physical_memory_rw() in rw_phys_req_item()
Date: Mon, 29 Sep 2025 20:32:50 +0200
Message-ID: <20250929183254.85478-12-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_physical_memory_rw() is legacy, replace by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/xen/xen-hvm-common.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index 78e0bc8f644..52e2cce397a 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -12,6 +12,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/boards.h"
 #include "hw/xen/arch_hvm.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "system/system.h"
 #include "system/xen.h"
@@ -279,8 +280,8 @@ static void do_outp(uint32_t addr,
  * memory, as part of the implementation of an ioreq.
  *
  * Equivalent to
- *   cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->size * i,
- *                          val, req->size, 0/1)
+ *   address_space_rw(as, addr + (req->df ? -1 : +1) * req->size * i,
+ *                    attrs, val, req->size, 0/1)
  * except without the integer overflow problems.
  */
 static void rw_phys_req_item(hwaddr addr,
@@ -295,7 +296,8 @@ static void rw_phys_req_item(hwaddr addr,
     } else {
         addr += offset;
     }
-    cpu_physical_memory_rw(addr, val, req->size, rw);
+    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
+                     val, req->size, rw);
 }
 
 static inline void read_phys_req_item(hwaddr addr,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133192.1471390 (Exim 4.92)
	(envelope-from )
	id 1v3IjN-00065h-MW; Mon, 29 Sep 2025 18:36:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133192.1471390; Mon, 29 Sep 2025 18:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IjN-00065V-HY; Mon, 29 Sep 2025 18:36:13 +0000
Received: by outflank-mailman (input) for mailman id 1133192;
 Mon, 29 Sep 2025 18: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 1v3Igw-0001U2-2d
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33: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 d2798b95-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:41 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-42421b1514fso44467f8f.2
 for ; Mon, 29 Sep 2025 11:33:41 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f3d754sm23909085e9.4.2025.09.29.11.33.39
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: d2798b95-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170821; x=1759775621; darn=lists.xenproject.org;
        h=content-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=DbEYNZgIU6LqvkF49qge8kIj2C3i6K2S813tsyxbWwg=;
        b=khWgzdBbP1CktaqF/uejPNCx9iCRhNo9MSSZxK/Xm70o/6Z3Q504TsR+Q+f82xg3No
         lK1U+BbVCLyHazyZ3RHTsZgGkEs3R4O/ClKjuCB/Vug4O18JJ8JcNRPvBO5Vwx2cnNSn
         p10n2Y+VczwCc/XT2tRA0WhYr+wnalpUegiS+SfvNkyxBg8IrsJXcFLIY3v7hSbqzIKF
         gjRYuXz8auiqSzdMQGv/Oliz2FmutLPv/8efQrFXhV7XTg3QOwf7Tpl/ZyBY+ZztgVyT
         o1K55RIYDz9+OsXj66PHKLWMwdNTeUL42tnB3FeVsw7Njzqa8g7Yzdurmn1JoLFOun1V
         m7zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170821; x=1759775621;
        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=DbEYNZgIU6LqvkF49qge8kIj2C3i6K2S813tsyxbWwg=;
        b=dDBPxLftd/sA2Jb1f4OdKh9JaqmqIT37EMDZKuppFrRxCzVLs4cBmSGtgU1hh9dDbs
         FtieOMINFkm65fd3mTWNLXB3aZTk2HD21xczFQODa6Xf+eoqwNESi8LDk+Z8wZ0INz4a
         ihmreJJFSURkyH0EqDDPoJX1oZL6vdYqxMRgu5a8jvRgTAAgZoWNpCc2gf9hm2MrfV96
         3CKIwwUwCLxlNNcypdq4RKgI0/hf5OYqNuK5X4l+x4UOC9AtaoPnrZ1lCFzQG/tznqCt
         ECaBgVIu9Nb2RNdqeTqGidUbxSndzkP2RDAgcRdLb89QJ555oIEyUURtaU9R2vAoWQ8K
         umAg==
X-Forwarded-Encrypted: i=1; AJvYcCWblW1NIPTRPdOuWSc23zcXKknGsyeISmNSBDrzf79Tet0Kjeco2R3li+W4DqQwqCllUBKvU50VPAo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWvbZ+fN2yaBg7CHbVm563D+aOsgYhAxLKUMNp58T54vv6yiKi
	vK7mjDbiCW9Qa/zLEXqypaq0KEinF0E5b9ocl/PNM0JdpxbYLpnk4moyqr/laKvSexU=
X-Gm-Gg: ASbGnctjMp6KJdvF/t12TMrzOMU1Qf38zQM6r6FNVSx46lSbLZRqaTlNijpEAyU0mf/
	SGld6HLx+zhhuHawY/W+sw33PLGXcny9xqj3RvFkYS7rWycLrtYKou4419RJ95YHmqDR0cj5j+4
	58438nRPcscbrAS/9KDgnITwm/ojklm4ISlThFudDVQdGMcvUM3FYdk2Yyh3aViApcuSqhrTfpb
	v3zZNHrMn0HZDk+n3KOgQ0nlN2ga0bOdMUMxE53FUmJ/gk+pbo7QPQ5pvBjyWfevv2FNryjL/Jt
	v5m+xEBcFq8eHM/6oLOLRlV/2GYLeh91y+Nv0PtEPxrCUtyat7TQNaBKirPtTc9A9Nt9nt5c3D3
	uEgOW0xlQgk+wVlsmyxNyCPeXTW0gGc8bwCJYpQYieOX37VtXT/dtL+M3ue1lthEH1zPF/S0oMw
	73ekKyECCPVKFGPMxuPQ==
X-Google-Smtp-Source: AGHT+IHaOBKfpBuD9vwP/E//+ppjcdL0t+dVKZj3FJZtAkNcYom3O6PaZLYCHSxxg6LM7gcPXW/sAQ==
X-Received: by 2002:a05:6000:2c0c:b0:405:3028:1bf2 with SMTP id ffacd0b85a97d-40e4d0372cbmr15214118f8f.62.1759170820742;
        Mon, 29 Sep 2025 11:33:40 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 08/15] target/i386/whpx: Replace legacy cpu_physical_memory_rw() call
Date: Mon, 29 Sep 2025 20:32:47 +0200
Message-ID: <20250929183254.85478-9-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Get the vCPU address space and convert the legacy
cpu_physical_memory_rw() by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/whpx/whpx-all.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/i386/whpx/whpx-all.c b/target/i386/whpx/whpx-all.c
index 2a85168ed51..82ba177c4a5 100644
--- a/target/i386/whpx/whpx-all.c
+++ b/target/i386/whpx/whpx-all.c
@@ -788,8 +788,11 @@ static HRESULT CALLBACK whpx_emu_mmio_callback(
     void *ctx,
     WHV_EMULATOR_MEMORY_ACCESS_INFO *ma)
 {
-    cpu_physical_memory_rw(ma->GpaAddress, ma->Data, ma->AccessSize,
-                           ma->Direction);
+    CPUState *cpu = (CPUState *)ctx;
+    AddressSpace *as = cpu_addressspace(cs, MEMTXATTRS_UNSPECIFIED);
+
+    address_space_rw(as, ma->GpaAddress, MEMTXATTRS_UNSPECIFIED,
+                     ma->Data, ma->AccessSize, ma->Direction);
     return S_OK;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133200.1471400 (Exim 4.92)
	(envelope-from )
	id 1v3IjO-0006PO-W5; Mon, 29 Sep 2025 18:36:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133200.1471400; Mon, 29 Sep 2025 18: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 1v3IjO-0006Ng-R3; Mon, 29 Sep 2025 18:36:14 +0000
Received: by outflank-mailman (input) for mailman id 1133200;
 Mon, 29 Sep 2025 18:36:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Ih7-0001U2-9k
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:53 +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 d904bbf2-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:52 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-46e326e4e99so26057545e9.1
 for ; Mon, 29 Sep 2025 11:33:52 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e59af1975sm3031215e9.3.2025.09.29.11.33.50
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: d904bbf2-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170832; x=1759775632; darn=lists.xenproject.org;
        h=content-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=QtU1C0M8U0OTbHcI2E95ZD2Zrsmz5/OESKETD6NudSM=;
        b=nNTJeVA4KhFLgMwncIWleSYFYtyXR/SZ4APubPoFRihPFYCWhgXGDJ9n1IIXqm9qDu
         WaLmaIScVm/fF/4/CVo0Ukiggcm1Mc1dMlI5J3beWMD9BdVgrC/FecxZ8xhEp9TTH/Mp
         tkhA0jTHjRnY4SpFubFhSpIoY897b+kEHRotFNct5I/gvMyiAlcEdEUIiSlBvucdKst4
         Rn2Ux82WoEr3yAlia4Vgb4LgdSSEHZgPLGT4wjiwn7e7PAf/4xUCYIWbn/nPu153FDi2
         3vRWyNpE+OL3XOfgQXb+oSwucV01Asl7k6vGvuOs2+LyJTXBTC9csYdugqU4eYWtGEFi
         iTjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170832; x=1759775632;
        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=QtU1C0M8U0OTbHcI2E95ZD2Zrsmz5/OESKETD6NudSM=;
        b=GOorQGZO4Dp5ieemCOuM2Q9tTX0YWPVG3rIdtA7UGty4k8t2jPS5foTG791/ixmlEm
         eDzaYJDkOgO3z+lPH2zZpO5Ohx4890OAObsc3f4Hx5hmd80fhp43y8vX/gciwNrTYAz3
         kkg4PHbZ3Ix37PDUOLDgvCbZnnBFJgP6rzHddTxmjxxorM5IjCKwKO7w/mQneZ4zWciZ
         1ql6DpS9wMWfSShJm/4SrZB6/mgcauhpIH3VIevlg5fOi7LmDw3Oa57nz32yrlMzTmfG
         f5K6lCBLL1eWpM4yEzZyK5um/R+brzr4XaAuyhAL9b66ujZVM+8Fl44cRhpCuinLFnZD
         Ao3g==
X-Forwarded-Encrypted: i=1; AJvYcCXx3EgzGjYugW3NBeFjXt5MLd34oCsXu0Ga4YvYWV6fqfvMrcV68aw7GfbQv499y/Cll+USuKjBsJk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0iVp0v09rD/xa5I7KreLhIc4EFlbVAFDJi9Ypvrs3eDU+740Q
	grji2mAEdgyF80WmOjnqKsBqEyaam2spX7d5LlJUDn/VZa9pdutB7/Dtp25wNnjobvI=
X-Gm-Gg: ASbGncuJBIHELD4QmVm7m/W/XmhdrSezezA+Lh936emm7/7Ao6WgvOPppiOSWIYPKcc
	XxWt2Cdfrw0Uy0kE3+9o2pvSjYTHdwARr5u0CQkUws4uA3tZG97l4ZdUJdyW1yoT3Ar1NmTWGLe
	jbpQY8N2QUIL4MYsT3Ljirw8mVPuNUcbIzKO8Uh42PGcMtbULh55YCFKAK5X2l2k8Cz4gZ70hKv
	QmRZ38yDcycp81J38xA4B+05D8nYsxsmkQBqKPUbf2QF7qWVQudF2D3jI3FunoPzXJFYxA1fQxK
	WQhsLXuN0ehjEaii26gOx2a1nHkkdIY+RxlRT/psglEgivoC5fUlMg5NBX2Mnnl0PcLRdvxPouy
	Jcd29bOLro1FG0z+gRnXDqKZhilduYIuhiD8ZnArmPTxJ6FFrzw03nXj6Q4smco2my+t2VHPV
X-Google-Smtp-Source: AGHT+IGjnZG6/qjEBZy5PcjHjXj9r7KBUUors89ckyudEmcNpuheEZ9krTQTynjT1eMge8vskVxhUA==
X-Received: by 2002:a5d:5f83:0:b0:3ea:fb3d:c4d1 with SMTP id ffacd0b85a97d-4241111f6d1mr1595433f8f.18.1759170831738;
        Mon, 29 Sep 2025 11:33:51 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 10/15] target/i386/nvmm: Inline cpu_physical_memory_rw() in nvmm_mem_callback
Date: Mon, 29 Sep 2025 20:32:49 +0200
Message-ID: <20250929183254.85478-11-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/nvmm/nvmm-all.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/nvmm/nvmm-all.c b/target/i386/nvmm/nvmm-all.c
index ed424251673..2e442baf4b7 100644
--- a/target/i386/nvmm/nvmm-all.c
+++ b/target/i386/nvmm/nvmm-all.c
@@ -15,6 +15,7 @@
 #include "accel/accel-ops.h"
 #include "system/nvmm.h"
 #include "system/cpus.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "qemu/main-loop.h"
 #include "qemu/error-report.h"
@@ -516,7 +517,9 @@ nvmm_io_callback(struct nvmm_io *io)
 static void
 nvmm_mem_callback(struct nvmm_mem *mem)
 {
-    cpu_physical_memory_rw(mem->gpa, mem->data, mem->size, mem->write);
+    /* TODO: Get CPUState via mem->vcpu? */
+    address_space_rw(&address_space_memory, mem->gpa, MEMTXATTRS_UNSPECIFIED,
+                     mem->data, mem->size, mem->write);
 
     /* Needed, otherwise infinite loop. */
     current_cpu->vcpu_dirty = false;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133202.1471410 (Exim 4.92)
	(envelope-from )
	id 1v3IjQ-0006kn-CT; Mon, 29 Sep 2025 18:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133202.1471410; Mon, 29 Sep 2025 18: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 1v3IjQ-0006jK-5d; Mon, 29 Sep 2025 18:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1133202;
 Mon, 29 Sep 2025 18: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 1v3IhK-0000iD-0W
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:34:06 +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 df8a541f-9d62-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 20:34:03 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-46e34052bb7so50766285e9.2
 for ; Mon, 29 Sep 2025 11:34:03 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e46de67e1sm103906645e9.6.2025.09.29.11.34.01
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:34: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: df8a541f-9d62-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170843; x=1759775643; darn=lists.xenproject.org;
        h=content-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=LuYVzxDYsV8q8g9d3IDIaYEYUyrQfEG5rj8P4oQ0OGY=;
        b=A76Kp6l0IsB4Z8L+4DQh8WUL3f8eI4biLcjqDiHIpTu39xNSfouWCVLq8JKHvozjaQ
         /tkqas50rbx43U/UJNgEMkZ6URBLO88lI3AMK6xd14SphocnE8bLOGd7ir0zxtnxTykv
         zaq8OwSHzWikMOif+IK5xo0EsDmn6HuHuv5ejb/ueH8X8jJ2x1ZQ10mjHa+SsKm9frH1
         T04grTuEyglJ53/qC3MfhBZHo8CJsutBvw+qZvHv1zskOxtyyAfll66RNuoN1//MQw7r
         w1Hd0611WI5FzQtTrOBiQHQz573Ti/IYmkADF80nCxOyjtTqFtb9q7xRYcp5lvQSWBZh
         FSgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170843; x=1759775643;
        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=LuYVzxDYsV8q8g9d3IDIaYEYUyrQfEG5rj8P4oQ0OGY=;
        b=O0B76h4XRGqSbhzWbM5c/HAYSs119r6aZWMT7fjTEWn8E21T28aeBbGUSqISg+jUUq
         aksy5E2oJbxabS3XngD3pOf+AnC8tnccgf7b7v/xnNVOilG6ZUaG9WTDOfTDXfhcwwBw
         t8JHDMFNVGppp9Fe17ZDtx1mB0xKW3G0uRfOI+24Qk58g3s2rN7AZ2kHOJxv/mBGMUui
         kZdkldriWZDjeM9Hvs70OZJAMj7yTe2HvOCXSXqjYuEht8iSd/kqRga3FpNcY+DGfnjU
         5TrV8A7jSd5P5rz0doD8IBo07UGrQ9rNcSCQhurbLJzTOAmPb2nxzNeRcK6wBHTm4lPi
         aLXQ==
X-Forwarded-Encrypted: i=1; AJvYcCVe3i8gHOAitrtAEw9ph8MWamSoIseAjQMkcuak1qrHhlFI5uNguvvM8C2u4xK/ujh1D3Y0jaIlmtI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywjzg3daSNqsgKf1nwmusbRDBuCUxcKH+VGna7r2t0EbCgOE0su
	VbsZ3079Vn7uYfoO1W2q6SlE2xLSx2yy3DBbA0jM63gAem46oaZ47mr+8Zy3gc0/E1A=
X-Gm-Gg: ASbGncsn3g02bK7JEbOOsa8UhPPTvppxYVlnCrT06I+2sd4UjgeiDPipOgpDoUTbOH+
	xctanpi/bcKYp/8X00QXlE30LSbMPTBYsPn/DnMZxf4UBPuibC8pBx0B8CgDxEGAF1Ydupw963R
	jdG5kaSTe6BOY7jVPO59DStavKGvugXmGSAcyAuXwo1HKAX367FJjomzxfLhh78nit2BnYeJrE4
	waNu1CQAgsEAv3Kpk/7vruIrir9prBsyPadhYNqaNBjo0i83I9kXpW+QVckkV/tJeMVwB8PqpL7
	cDAYIDp5++58r1aow0qbZBaClmj3EE42AViTC5q+zboZVeoK3B2d0Rz9Ax1Av8XnPd/Owg1j2hf
	1ru/P7GOXRjXD6YvZEkKIm1sNM28zctuP8ihkYggDlM/zOi5npJNo7J49oJySF0plx9/nf2SvAi
	Y/j17OXHDFerpvi9hE4w==
X-Google-Smtp-Source: AGHT+IHxkSBKZz9UIKJGJ2MuyS+JOGfRYnVKVs7Y+XK907wXLr+RITSG6kYiNQobFw2cPjU7tACI6g==
X-Received: by 2002:a05:600c:a47:b0:45d:e6b6:55fe with SMTP id 5b1f17b1804b1-46e32a32b56mr143974255e9.34.1759170842607;
        Mon, 29 Sep 2025 11:34:02 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 12/15] system/physmem: Un-inline cpu_physical_memory_read/write()
Date: Mon, 29 Sep 2025 20:32:51 +0200
Message-ID: <20250929183254.85478-13-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Un-inline cpu_physical_memory_read() and cpu_physical_memory_write().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu-common.h | 12 ++----------
 system/physmem.c          | 10 ++++++++++
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6c7d84aacb4..6e8cb530f6e 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -133,16 +133,8 @@ void cpu_address_space_destroy(CPUState *cpu, int asidx);
 
 void cpu_physical_memory_rw(hwaddr addr, void *buf,
                             hwaddr len, bool is_write);
-static inline void cpu_physical_memory_read(hwaddr addr,
-                                            void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, buf, len, false);
-}
-static inline void cpu_physical_memory_write(hwaddr addr,
-                                             const void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
-}
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
 void *cpu_physical_memory_map(hwaddr addr,
                               hwaddr *plen,
                               bool is_write);
diff --git a/system/physmem.c b/system/physmem.c
index dc458cedc3f..5a0ee3b8e58 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3188,6 +3188,16 @@ void cpu_physical_memory_rw(hwaddr addr, void *buf,
                      buf, len, is_write);
 }
 
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
+{
+    cpu_physical_memory_rw(addr, buf, len, false);
+}
+
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
+{
+    cpu_physical_memory_rw(addr, (void *)buf, len, true);
+}
+
 /* used for ROM loading : can write in RAM and ROM */
 MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
                                     MemTxAttrs attrs,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133210.1471420 (Exim 4.92)
	(envelope-from )
	id 1v3IjR-000798-NU; Mon, 29 Sep 2025 18:36:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133210.1471420; Mon, 29 Sep 2025 18:36: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 1v3IjR-00078u-DE; Mon, 29 Sep 2025 18:36:17 +0000
Received: by outflank-mailman (input) for mailman id 1133210;
 Mon, 29 Sep 2025 18:36: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 1v3IhZ-0001U2-7G
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:34:21 +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 e96d1105-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:34:19 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-46e52279279so10850945e9.3
 for ; Mon, 29 Sep 2025 11:34:19 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc6de90desm19572933f8f.47.2025.09.29.11.34.17
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:34: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: e96d1105-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170859; x=1759775659; darn=lists.xenproject.org;
        h=content-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=+R20KfaeepivX48ztS5Qk+Utu4Wf2nP4nwxC8R0e4a4=;
        b=Y9+30Hkz4HHQfdraVyqByB/w2vXuPn5+NgKp75yXarQCOItV4arzp+UljZnDb2r+wk
         uOtH/8hu/grT1nFpqIw+vFiwHI66+1xxDeIBp+BiypFmu7fl4twgnT7Be6RNDX0hfYmN
         ozT4+xQSVKySdSGZ/7GW8hE8d/qVVEM/aFXgnRDlmqZQeGw9LTrIQU1MoKlYQbXKINw9
         pehIP/lffCEoWF+8z5b7ovpOdmT73pFJXYXHpPblQxyh+dJoK2R7mHqwIhaeQSPD/doG
         PRnlOMpbtAG0puLc6U/46RgN6ueuqHt25FygtxeZKkCY3DT2Hwl+V1BACy/GZAfDDlZ+
         A98Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170859; x=1759775659;
        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=+R20KfaeepivX48ztS5Qk+Utu4Wf2nP4nwxC8R0e4a4=;
        b=HBt/UqifR5AuGk3jA0Yx3dzY/w6l9sRG7niKwT3Y/39olE80Jy2rqVFV4CiW9ZOO66
         Akv120kaE8skmJYAjYe3Vzeg8t7iKfNOO72RN9kGukpc/On6YfDKv+/+HDuY2YEY2psc
         xq8grKwErZC9Rgg8rWdTa0ulN4YUItqE36gyMYQ4Yv3ftBMkqz5KUVUXOaxqOWBLddmN
         h4+1dsOGHYYPmLIMWxtrk8QBrgrcQG3vG7FzdqyyWP9ok2fy3WZsaDQz75yKWbkkoxU0
         7JcKUKcOfC20XUktUMC1RXFRul5tRl9F8LpGk0FWGXtTecXcKD0IqqboJcLGetKLJbU6
         omPg==
X-Forwarded-Encrypted: i=1; AJvYcCUM0eD5DrHj8qohU4credFtCl1j9Ohtu01W7gqv8DIyevge4puOWhzwKxo1bu2PHxkqckAELoIMqLE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy3ccE60tPD6cdNenC3g2VfXA46eiqp92TM4F/8wDyRErp3Ud7Y
	E8YIlAiRlPJVzrjK4o/+P6ct4NHjkfiu2274aBFe5UZSZW8q0lMm4sGDDjuMHZ6KvRI=
X-Gm-Gg: ASbGncsbacjyyi8UPlOO2zqObZstwhMhNtJFBDL//BlwrTDVyfkS7oV9QoTFIrmz2bs
	+pxSApQ+YVYj4hH8Q6Rm429MBAiH3SnFUIj75o6KvIjkl4PfC2QvyILL1XJDe0vMv8k3UVZm1nW
	aLz9mTdB85zhiG6q0+cCziAv5r0d0iJBie1cUnD8sAQRIaAxf5b8UBMW9XAazXIBQlX7571ypNT
	Da3pmgQ/8US5p/wSgZdwDp0MiEchdvBdhRRALNN/YJrXdjav4bffnuSC0PioiJxMbcai5toyupB
	gP120Sc/o7BEWVHOQbhR3VpUB2nS92GMK3T3bgcgR2Y3b7Ds7wR5s0yOmHAyv8rM88AqchtkklG
	26Dzob9U+4yLU9OkTn+LhYukTywSFhGOOGN8+LmHy5i2TO6NfYBvqsDznkG9sBDNNu6cS4ZiB3V
	94EV0E/SY=
X-Google-Smtp-Source: AGHT+IESuOr/9kkTMP61JEo78aO/qu+Se16k4y0bZLp5zO2vT4tUYcRGwPC2KF7trcFZOrvkB6y8nA==
X-Received: by 2002:a05:600c:5491:b0:46e:345d:dfde with SMTP id 5b1f17b1804b1-46e345de049mr203777245e9.16.1759170859187;
        Mon, 29 Sep 2025 11:34:19 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 15/15] hw/virtio/virtio: Replace legacy cpu_physical_memory_map() call
Date: Mon, 29 Sep 2025 20:32:54 +0200
Message-ID: <20250929183254.85478-16-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Propagate VirtIODevice::dma_as to virtqueue_undo_map_desc()
in order to replace the legacy cpu_physical_memory_unmap()
call by address_space_unmap().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/virtio/virtio.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 9a81ad912e0..1ed3aa6abab 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -31,6 +31,7 @@
 #include "hw/qdev-properties.h"
 #include "hw/virtio/virtio-access.h"
 #include "system/dma.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "virtio-qmp.h"
 
@@ -1622,7 +1623,8 @@ out:
  * virtqueue_unmap_sg() can't be used).  Assumes buffers weren't written to
  * yet.
  */
-static void virtqueue_undo_map_desc(unsigned int out_num, unsigned int in_num,
+static void virtqueue_undo_map_desc(AddressSpace *as,
+                                    unsigned int out_num, unsigned int in_num,
                                     struct iovec *iov)
 {
     unsigned int i;
@@ -1630,7 +1632,7 @@ static void virtqueue_undo_map_desc(unsigned int out_num, unsigned int in_num,
     for (i = 0; i < out_num + in_num; i++) {
         int is_write = i >= out_num;
 
-        cpu_physical_memory_unmap(iov->iov_base, iov->iov_len, is_write, 0);
+        address_space_unmap(as, iov->iov_base, iov->iov_len, is_write, 0);
         iov++;
     }
 }
@@ -1832,7 +1834,7 @@ done:
     return elem;
 
 err_undo_map:
-    virtqueue_undo_map_desc(out_num, in_num, iov);
+    virtqueue_undo_map_desc(vdev->dma_as, out_num, in_num, iov);
     goto done;
 }
 
@@ -1982,7 +1984,7 @@ done:
     return elem;
 
 err_undo_map:
-    virtqueue_undo_map_desc(out_num, in_num, iov);
+    virtqueue_undo_map_desc(vdev->dma_as, out_num, in_num, iov);
     goto done;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:36:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:36:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133220.1471429 (Exim 4.92)
	(envelope-from )
	id 1v3IjV-0007fF-E0; Mon, 29 Sep 2025 18:36:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133220.1471429; Mon, 29 Sep 2025 18: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 1v3IjV-0007f2-AT; Mon, 29 Sep 2025 18:36:21 +0000
Received: by outflank-mailman (input) for mailman id 1133220;
 Mon, 29 Sep 2025 18:36:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Ih1-0001U2-95
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:33:47 +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 d5b891ee-9d62-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:33:46 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-46e42deffa8so40586345e9.0
 for ; Mon, 29 Sep 2025 11:33:46 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab48c28sm234491505e9.18.2025.09.29.11.33.44
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 11:33: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: d5b891ee-9d62-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759170826; x=1759775626; darn=lists.xenproject.org;
        h=content-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=onCfEhinWarPReSMP2g+nvBYz1NYywUR3fuXcFIYVYM=;
        b=T72BL611RshT3+AuRgAhGKtatD4dP8JlCUuT7U4KADuQ89zb45T3x6jgsSuTuLjnRB
         L6/OVBaAqR7BdycTxi4XhMzzwKSP5F0N5gMpqUXsA++PaDJujZGRqgeCMAHKuvjvmKfg
         u9fUleJfidSaUiVmaDBg+xIAGnr5f0yP5tSgQdoluWnuW4ABgruT7hPtBwEwlsea8cYn
         bYIvUSthyE3JzD/fAIbIj7G7mehg6qP1yX4NJdQz3q+2oHseIWEreQU6jcxfMqrnxrfq
         ojuw9hKG4MxlAEtyp9HStJAyRg9CNwvAB602DcNFek/Vka4ZRMi08nltGqV8No4LJyZw
         0geg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759170826; x=1759775626;
        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=onCfEhinWarPReSMP2g+nvBYz1NYywUR3fuXcFIYVYM=;
        b=viuT0hCRXbnPJcU2iOjMsLJhnQxerMB9sG+lqYowLqDTQD2Bv03JLZmKpYy6xY52i3
         Gn3fdkmjvrVnKGH94eVoMjKIJBaNX/qAf9H6QNXOE1VMNY2JYnXqyOEfuj1ep0LFKorj
         ldYAjXUms4f9MzR0ZT9vYBQvXs1kGlzQTjhOv2r+RozAqQffeYob9XCZ3/1ViYDZpUGL
         TCF//h2kjAJU8Fc++FAVCsgls8hVGGjO2JyCF9BAjpRp82vvmEC/8GhFzxwEvQrElCJW
         dp3fcQg0YdnCfo+6QgHWYKJ449dxo0pGHz4t/x69WRPX+xePeIKzdLyt0RaEDXbMXqhU
         Ib0A==
X-Forwarded-Encrypted: i=1; AJvYcCVY+p+XyDXLhYtFRqyfKM3fXewW441csFoKC6nWzVFqbhQnvLOko6m/F0CMJsVg9KLsX8O/oAp6tRc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyS7xUf3eMRjLAdTnU4Eo/Fx/INawMBF4xWY9Tn5ONZBXJ0dVr6
	B6lbpi83r1XT0r1ngNpsrfmdrVbT5WummpozxLXWG33frVfbMk158QSbegI9PSL+apY=
X-Gm-Gg: ASbGnctdglo6+f9gl9CiznW2YkiGVYe713xjkEeaYxQofqtUeU6ZB+rVBEnRE49Gey9
	enfB5zHGgWIfkGLBxbQKzTMKlQJBEmQN2idKy3kdIqGacbUwr1LEz030z/H0l3jJ1YZPTPUPQdS
	spt+wzWD3XNEKvt/NUXfJmRWB7h5ljBEefvxx3MwfbOoOsvGHg6dTeIdSRGsxm4zgDZNI4VMLaQ
	KUOpUXlDNgClD7vYStVlz8ZmUm1/+2OgIUq1k2hYiUhTx0P0owflOuFhQEyJonemoDt3MGW3jz/
	BtjSP5MxLq60JawzsQ0I1ABLQgBwlqhiyV99qSUplGOEVisIE+SbiDtO+2bKGpeQ2UKrT8/EkxY
	ueiArfuKQB6uD1HYuZ3bZ1CAdsIINkktaS0n2hf1LrBHNDzaGTPQKsE2kw3QPsS1fWrJqrGRb
X-Google-Smtp-Source: AGHT+IGY3Rr3VyTE3S7oem5ZxfcOaYJ6i/vEMLPbvgnpiGprZwacrZ9bUpREdcpvLgXehTAMtkJc6Q==
X-Received: by 2002:a05:600c:348f:b0:46e:447d:858e with SMTP id 5b1f17b1804b1-46e447d8828mr94281545e9.28.1759170826202;
        Mon, 29 Sep 2025 11:33:46 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: Peter Maydell ,
	qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Richard Henderson ,
	Stefano Garzarella ,
	Reinoud Zandijk ,
	David Hildenbrand ,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Sunil Muthuswamy ,
	"Michael S. Tsirkin" ,
	David Woodhouse ,
	kvm@vger.kernel.org,
	Eric Farman ,
	Zhao Liu ,
	xen-devel@lists.xenproject.org,
	Paul Durrant ,
	Christian Borntraeger ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Halil Pasic ,
	Jason Herne ,
	Marcelo Tosatti ,
	Thomas Huth ,
	Anthony PERARD ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Peter Xu ,
	Matthew Rosato 
Subject: [PATCH 09/15] target/i386/kvm: Replace legacy cpu_physical_memory_rw() call
Date: Mon, 29 Sep 2025 20:32:48 +0200
Message-ID: <20250929183254.85478-10-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250929183254.85478-1-philmd@linaro.org>
References: <20250929183254.85478-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Get the vCPU address space and convert the legacy
cpu_physical_memory_rw() by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/kvm/xen-emu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index 284c5ef6f68..52de0198343 100644
--- a/target/i386/kvm/xen-emu.c
+++ b/target/i386/kvm/xen-emu.c
@@ -21,6 +21,7 @@
 #include "system/address-spaces.h"
 #include "xen-emu.h"
 #include "trace.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 
 #include "hw/pci/msi.h"
@@ -75,6 +76,7 @@ static bool kvm_gva_to_gpa(CPUState *cs, uint64_t gva, uint64_t *gpa,
 static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
                       bool is_write)
 {
+    AddressSpace *as = cpu_addressspace(cs, MEMTXATTRS_UNSPECIFIED);
     uint8_t *buf = (uint8_t *)_buf;
     uint64_t gpa;
     size_t len;
@@ -87,7 +89,7 @@ static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
             len = sz;
         }
 
-        cpu_physical_memory_rw(gpa, buf, len, is_write);
+        address_space_rw(as, gpa, MEMTXATTRS_UNSPECIFIED, buf, len, is_write);
 
         buf += len;
         sz -= len;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:43:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:43:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133281.1471459 (Exim 4.92)
	(envelope-from )
	id 1v3IqB-0002tG-Ko; Mon, 29 Sep 2025 18:43:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133281.1471459; Mon, 29 Sep 2025 18:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IqB-0002t1-I4; Mon, 29 Sep 2025 18:43:15 +0000
Received: by outflank-mailman (input) for mailman id 1133281;
 Mon, 29 Sep 2025 18:43: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 1v3IqA-0002RY-5C
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:43:14 +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 276a20b5-9d64-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:43:13 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by VI1PR03MB6591.eurprd03.prod.outlook.com (2603:10a6:800:19f::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 18:43:11 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 18:43: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: 276a20b5-9d64-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I1VpH4Qm+FEb5QOr7cUjFDh3Pk0CPB9V1zXCNEeGNrAACs9V7SO7ZvuvUTWwnanyGD8r8qdlmCWL9GjNtBPg819W/f1N2VO899Ik4D7x7BZ1QnuroN8xaeqjMrqFHNYdLAk/Bq8R20+A/mDEGD4++0GcGJVeUPvPwJKbCRAt6fpQqcEInTt55j37QlUDscjxHJcWLCdx+8422z/y7oyyQVBYjSuabuaFeb6mqqEi0S0LSUONtvIii2VFWjDwaoCxOCeDs3AhMyhOelmUnvRrEoUPMTNp7cAMdjB03f91i71qKuInNnR2OQk7se/+gs6kWmOxJlPAs4ieCMb6O0z2iA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1x3ib5+D29JOj///4+abaLXCnrAt2rgzaFpirzRaK68=;
 b=VHVcXgkplPS2WCM6KJ17Neuqxm9Iq4WocYvpF+ANwBSC3n63HLTVvkarysPmHCeV5tndigrzm00kEBo3TQ7JxYCZfPzmKQKLIsgpJJdTIhil6z1R1Op8sv/JGpKrdGVJrj70rwC1fDgBoN79tc2XX+c3cEZtNNDwo6mAPIHlQjM7uNzW3I0/XYNgv3OJWo845L19L0vYfmnrWRkExatUbUw6rlZX9NvGl0Xc1z/j1NWF80V3V7kpUf6Bdc3Sj7o1FyBzi5zMG6Kc353hmm1+V0qJ8+44grj99/ZZ8Id0UZdjq1H2pVB13HVw0kBOwCeryCUp+0i5rh6gfjMta9hqeQ==
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=1x3ib5+D29JOj///4+abaLXCnrAt2rgzaFpirzRaK68=;
 b=t8BtFzcNuC2V4oAPDnbltYzZzqcGraJBiobXYENbHqY3tWi2MLMtdSK30AaFD6mo+60yQhX4ol/bLGNt9cjDoi0l4Si0A1ajlifKyIkoRZhEhoGWfnd9eiq4/z9gqscbUDxIxI/QRXpaxT2Y/tzkV4rvaWTjVauaSclcI1a4+xtWaoEJNr/Pgl5InoQ3rI0vA8yQKLbEysXQC/01EcmRApfQZ+Bj7y8YNybz8crydq0WlG1jq/vx57LtYlirZ32nq31657wwhDSG5nrjNxshL6vZV5HEjUFRlvq72c1wWmqySASvPPNIR2csMeuym/Fezy2DZt5QRaLIwuSUuBoFcg==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v4 2/2] arm/gic_v3: address violations of MISRA C Rule 2.1
Thread-Topic: [PATCH v4 2/2] arm/gic_v3: address violations of MISRA C Rule
 2.1
Thread-Index: AQHcMXDoriceWLTjBkO+YV17n/oK0w==
Date: Mon, 29 Sep 2025 18:43:11 +0000
Message-ID:
 <54fd67f0f993aca28d1447502f29cec6fde8816f.1759168391.git.dmytro_prokopchuk1@epam.com>
References: 
In-Reply-To: 
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: GV2PR03MB9572:EE_|VI1PR03MB6591:EE_
x-ms-office365-filtering-correlation-id: c9bd9a01-893c-46e9-7e8f-08ddff880aca
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|42112799006|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?o3hxlwVNd3bdGevRKfeNLkw5gVmxXXOv32D0QwtnD/oIkJg3H1zvN+99+V?=
 =?iso-8859-1?Q?JYGOfAln7OLRqSoIWSOFjI6U7NsUjfdCOEe1ui+3+DCvr0hfhZbxT2RI0Z?=
 =?iso-8859-1?Q?wFpxtroarDo/vK385eaDhTMMuceBppVGNbHrKkgPPpeZzyVYf/f0exfxw3?=
 =?iso-8859-1?Q?CoWUW4PMYIEnw5ZFW5SYxtd8zqFzpgQKT34iOcXVrI1lajaQe6ofq7VDwH?=
 =?iso-8859-1?Q?QdJeGH4NLevzD16rMXmVwxEoz5NreKAv6fSSmjjCNKFTAUeK/IDkkTfo4I?=
 =?iso-8859-1?Q?j9kxBQ3D4BO5ccuC78SJfFfqpqN0jyrCIgsaaCO8+uaStxi4Ck0gSQSXIn?=
 =?iso-8859-1?Q?6Xbu+x4C2QMkQr6EaONQK3eMC+yHX0q1EqybkZ620EU4x7G/CXXGtzwHJ3?=
 =?iso-8859-1?Q?ztDixrtM+s0bi+M8p4EzjiXzfVTPBGg1dN9axnocnRY2j7ktpEYbWYlN1o?=
 =?iso-8859-1?Q?GIYwHAhkBdRU3qpmlZn0BDr0RUIWjc8ftp6YoBQtbgdawBkoR0SRScASAD?=
 =?iso-8859-1?Q?Db1Ki+XtDaQKcqxMV/OTmsTZWasLkduIIsvo4lhmRs9p2DbpIwdOaBqUOY?=
 =?iso-8859-1?Q?w85b3Lcbydvo6KnNwMLVoCS6AuIANkgl42d8LmMPJgtW2vAzFJK9fML7HT?=
 =?iso-8859-1?Q?dZCpZlgG7GqmrRylDPsQIZEjzJSSff8Svps2Kah4KdQ/R4Wi66BrLSH0jw?=
 =?iso-8859-1?Q?LiGxHWSuqP92UVoSZ4B4KRzkDDWZKEunRNuGfpduYNY5wUBBdyJM8LhKFl?=
 =?iso-8859-1?Q?cH3XqIib0vbZc3cFAmwZfz+YMqFO68MX9canVxlGEq5LpPUT6LbwqSFGfl?=
 =?iso-8859-1?Q?fjOVxbkSKQyPUpIlm8b6a5ukinzC/6duq7iR/TCveW+QWRP+YTDd5+dOvL?=
 =?iso-8859-1?Q?irv2bRMwoxDT+kqqcVCh3ZB98WoVgn36Xy9VtMHh9NVzFpYpuKxlsCTBDc?=
 =?iso-8859-1?Q?idW4tSJ/VJWU4OCGjCLgDPiz4blZJuHrBx2YFtlW/72h0EePg/elb0oTTL?=
 =?iso-8859-1?Q?Y8oue2UoRrg1IesSXEE05cGRHYEamlXySE7+fa2TuPbtp7YdrfAMfRHkzz?=
 =?iso-8859-1?Q?SHQbCBAtpjpNQyRWz3VB8aqNovCOvmxgezzLruhvlpwTsGZrI1LWPzNZUY?=
 =?iso-8859-1?Q?2nRv3GjD3A2wWpxgZ0JIqUo9Q3ExowtdjTgBP/HfFPVwT4meywBRlr9ZLp?=
 =?iso-8859-1?Q?T3oshw8pZTEdPyWW9/ywOW8n5bAhtUWRVHs5CFao4U00ywq837CenNvWFJ?=
 =?iso-8859-1?Q?vkx1T0IhP3oCBZ3rgWN9s+eIdDCmN3Nkq6moku7c9tN04JLj4ejkpPjYCF?=
 =?iso-8859-1?Q?531cNp5LD4ActkV0aUh52/QvM5cGNqHqmG7HZq4xPzvbZMVCAAO2b4ANJd?=
 =?iso-8859-1?Q?egVmJ8LfqLN6mxyiVWfklnkIdkvA501ADuL/HRA9WocWGgF3Ylg8RdBnKo?=
 =?iso-8859-1?Q?3So15EnciSN6i2942qZxHCH/EeiQ4BJquYnU/+YCAwTVHCMmjCmU5+CrWO?=
 =?iso-8859-1?Q?yIWvCOV+vM/0mEu4Pu498nh/+H+FKhasd7Hp2FXCzyNcig1jJHeIfm8RV9?=
 =?iso-8859-1?Q?B2blL+nvFdW1/ku7s4XbMg8AyzUg?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(42112799006)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?FwGBflgsTYBLRPPYp2pgGdCfWolT0Pod0serOejYOjoYsfdqMLp9A0Irkt?=
 =?iso-8859-1?Q?tifL5lgrVZd3B6l/X37QUagzvysCQpmfICuY+kNTwAwR1SWrkQMJT9z8qA?=
 =?iso-8859-1?Q?6G3VE5mF84lr2EWi27Adk3VNiE4GLjI1vXOh2I0BqYn2S1/qdWFnnWpP39?=
 =?iso-8859-1?Q?x2styyJDSETkKEIV2NSdBmc8nA2lAhoL4svPjWlM71tO5rrCvpIvQysJFn?=
 =?iso-8859-1?Q?/DGPCnS+jlCLZvQBJBSVA486sFookDEG5gHAhCSjBTgBo+aiI8wTLlQvi2?=
 =?iso-8859-1?Q?y0sFfXqJjQcKQ+mKqdkZtray9Z2AQHKqQ3ar781Am0DZmHOUbiZWO5aMQ9?=
 =?iso-8859-1?Q?xO1iZRzN0gDfTxOMnbDg8cqWgr3JPGu9OmJcsAWElLh8u0l8NnvXA6/im0?=
 =?iso-8859-1?Q?+4KsXNVBvCGzAE9TN/r1JpD1Ri5ju7C5rbKE779ZrJ8mqEkt0AWuLfXKY1?=
 =?iso-8859-1?Q?zIgpPubU2WxBQTXsv4ZBWHgG/lwBV7TQHN8Ou02pJkSJ04SBjZxYfYFIQ4?=
 =?iso-8859-1?Q?jBnzZ+VSjGqicS8W6t9WmGYi5rchijAADC/asuLF9df0ca7jPvxj4G23a/?=
 =?iso-8859-1?Q?QZhmJBYct90SmaJhdj2xvsPzrqd2Un/UeyTNy2GElfpxF54yrIlApDtisS?=
 =?iso-8859-1?Q?+FyOzUUZo05bScbSohWGr2I/rU4kHIKuD92xs9e4Alus0QOH7Dwq88u/wD?=
 =?iso-8859-1?Q?Zxa76Mx/W36rGKaljDGIe2FZEMFUXDaZiEF8GaSKjWkO7divYtggJOImGy?=
 =?iso-8859-1?Q?7ajQnKSbGNkx2IamLNYgo2HdMRzeGbpjJQX/vchdIRPguyQ8KuxTjBdhFM?=
 =?iso-8859-1?Q?t5PLSAl/0TfHaAKoJSbKIUl4XPd2qDNxNMxcnWEmeU/7hUCl0cgkHO4e3e?=
 =?iso-8859-1?Q?rc72XVhNM1tVdc9K14B/YZ+KshRjKyu8Mgc9TaHVrRdkvyTv1BUCB8Ar9b?=
 =?iso-8859-1?Q?BBU8n9YlS0bh/7ug57UhRJ9fTupMg0tNfhw5225LtzbHH3/94YGuxYu2xT?=
 =?iso-8859-1?Q?OBHETA7I+T5lnIQdBYD9ZfOqvTU1QPm1qCLjTOQC/IhacxG4JkIhqoe/Pu?=
 =?iso-8859-1?Q?XvUfYpnEQe0Cf3mIbLrbbR+dg0DP6RcJ5tXQOO+2+MkMSY+QIznOxAjx9Z?=
 =?iso-8859-1?Q?A25PsSOfCYKzGPNrUzm2FI3CgbX6e5C4RQa9tIM6Xh8pTvCVpxuzdd4wMz?=
 =?iso-8859-1?Q?H2EcCbvq5WsBGeaOROckuCFW0rpaH8CtEeEGmofgCVZGsBaJikeGyfAHv0?=
 =?iso-8859-1?Q?6h34TovGppz/RY3cP9sNdUdbgycEoQpzb9e14q+Ynv8pvCxtqha93sFyN2?=
 =?iso-8859-1?Q?950gKPWQNsWtpDBffOfI9AfKICRO1UJH7GSiwYR0t3Zcu5e2Bvm4uRceFs?=
 =?iso-8859-1?Q?wt8o7pwZG0218JlgcwOfUmNsv1A8wzC0GXlr1g8+aizBzmQr1PkR1S1Ycf?=
 =?iso-8859-1?Q?kNHTqBpwT6e0Wqs8Yd3Px1aNucuBnTngqDk4v+twaXMGU+/82igrRjxe0+?=
 =?iso-8859-1?Q?bmeRAGYfi6T5XIWRZfFVks4cb5hhVFZzmgHJmyheyqMqaKHI9K9RWnjN3U?=
 =?iso-8859-1?Q?J1VxPyeg+LRPRvsKPjE+yCwkI3zGx08n9U+VvPrViBmxvwy9/Ez2Kcy13f?=
 =?iso-8859-1?Q?OANFG74xRcfRLAE87lFqNNic9Tna986CAq1Rr3AaeQvw8NvZ/ZpooCkw?=
 =?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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c9bd9a01-893c-46e9-7e8f-08ddff880aca
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 18:43:11.7610
 (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: ofs8By1ykWQPb8OI+53c0Erd37Ai12AtHKQe8KiaWvND30/mtKj4N6rLf9reybSMgFKEBwxQfRgUESjJgYtVGjMhffwcBNI6CGcfQZkfSpM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6591

MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
In certain build configuration the following 'gicv3_its_setup_collection()'
function is defined as inline and contains the macro 'BUG()'. This resulted
in violation due to the function became non-returning.

To ensure compliance with MISRA C Rule 2.1 remove inline function and its
'BUG()'-based unreachable code. Provide unconditional function declaration
for 'gicv3_its_setup_collection()'. Rely on the compiler's DCE to remove
unused function calls, and use the 'gicv3_its_host_has_its()' predicate,
which always returns false when 'CONFIG_HAS_ITS' is disabled, to statically
resolve conditional branches:
    if ( gicv3_its_host_has_its() )
    {
        ...
        ret =3D gicv3_its_setup_collection(smp_processor_id());
        if ( ret )
            return ret;
    }

Signed-off-by: Dmytro Prokopchuk 
---
 xen/arch/arm/include/asm/gic_v3_its.h | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/a=
sm/gic_v3_its.h
index 0737e67aa6..fc5a84892c 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -131,6 +131,8 @@ struct host_its {
     unsigned int flags;
 };
=20
+/* Map a collection for this host CPU to each host ITS. */
+int gicv3_its_setup_collection(unsigned int cpu);
=20
 #ifdef CONFIG_HAS_ITS
=20
@@ -160,9 +162,6 @@ int gicv3_its_init(void);
 void gicv3_set_redist_address(paddr_t address, unsigned int redist_id);
 uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta);
=20
-/* Map a collection for this host CPU to each host ITS. */
-int gicv3_its_setup_collection(unsigned int cpu);
-
 /* Initialize and destroy the per-domain parts of the virtual ITS support.=
 */
 int vgic_v3_its_init_domain(struct domain *d);
 void vgic_v3_its_free_domain(struct domain *d);
@@ -256,12 +255,6 @@ static inline void gicv3_set_redist_address(paddr_t ad=
dress,
 {
 }
=20
-static inline int gicv3_its_setup_collection(unsigned int cpu)
-{
-    /* We should never get here without an ITS. */
-    BUG();
-}
-
 static inline int vgic_v3_its_init_domain(struct domain *d)
 {
     return 0;
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:43:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:43:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133279.1471440 (Exim 4.92)
	(envelope-from )
	id 1v3Iq9-0002Rm-90; Mon, 29 Sep 2025 18:43:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133279.1471440; Mon, 29 Sep 2025 18:43: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 1v3Iq9-0002Re-4p; Mon, 29 Sep 2025 18:43:13 +0000
Received: by outflank-mailman (input) for mailman id 1133279;
 Mon, 29 Sep 2025 18:43: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 1v3Iq8-0002RY-FU
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:43:12 +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 262342c5-9d64-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:43:11 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by VI1PR03MB6591.eurprd03.prod.outlook.com (2603:10a6:800:19f::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 18:43:07 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 18:43: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: 262342c5-9d64-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bRmsnyb24Pb/nP5ib2DBrYcL+jI0hrc/db+mRE7yJ1sEu2fSR3DbAQrnhes09ARgW1Z6Mnww5k195xSCTHq+p5KruFogRnX8yUJVWiRG5/K2KTzOYD9sXuNvVYUxpLF/O5g/vhJqfb0jPU8wI7d3etckCPduhdg4PQXbH9YGKZhgpVifxeLShdJKRkEdthVx4u3/ZMcbp1FKXKyoNquEu8mh3+8LghbFXMyCFfMwRAnUNOcdUT+nZPmZbk++UiVqY9Dp5V3xPuvNpm1qCmmyGwGyYkkZmap2J2HPuMynva0LkdwlywRklHOyZiwk4wd9oDw9SukT9PQJcV2aUElMkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hod+ok9gZQR1VO7WzKktcs4SVPap/lHUMu0mmJGz44A=;
 b=VjlJOYMPCExB50b1Ta1t73ootM3QUHYDlsspeQAsirzqS6wZSelAIDobAV5/dNG5P7aV6slvoc9O9Fzww2cYxNxlGaOWQ1hWCGrIVQqMjWUPL13GQ2m9yHzMMh7d9Kfh18K0b1HOyIxnAWfh/dUZyaCF8jbjr9XBWzrqfVwVCNgEoM0vlGxzj0B2n+7fLXG4SN96VuyxOwUUG1yYpFCNNfVFwFnDPitqgpAF4BnyZZnBgrKD9Yiu+YA7NXhhC85IJr/r4U3Y6uvP4dStX4AIL1Onl6scciHqTsIIOfxpntujpuxa2Y1IRKE5YteJlld1gIT3+Sv17mxRUKIbTsuNjg==
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=hod+ok9gZQR1VO7WzKktcs4SVPap/lHUMu0mmJGz44A=;
 b=EEOrNc2QwZfULMSMrhWIp+mmJXnYxZduzIxny3zZaUFIUKXAZQlZ6OH8YpRw+/F5qIf14Idv+oQ4elMIuE9aF6DfKJOnJi82n9yHrFQkv2hY5cvj+/CkxHVxV0YlNh7tf4fKQ42QPyD21VPmK7WXfh8N+im3pU2txLIyZNrvo6wQpzsBcaJOTWJIilZbywMQclnt2yjmVscpCqzioQqEFrh2S0QTo2AQR+gLcVXHFqonF+uim7fa7oWNSYVT/iySozZxJaRGWNTcZhsyqf8SSs/yl7KI3Bsk7ZF+S5oBiXZ3UQc8An5dZCmBR74VeqB7azlDh6cIvHML5Xy9pYQqOQ==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v4 0/2] arm: address violations of MISRA C Rule 2.1
Thread-Topic: [PATCH v4 0/2] arm: address violations of MISRA C Rule 2.1
Thread-Index: AQHcMXDlieIVRZL5wEWYCDA6Feaxaw==
Date: Mon, 29 Sep 2025 18:43:07 +0000
Message-ID: 
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: GV2PR03MB9572:EE_|VI1PR03MB6591:EE_
x-ms-office365-filtering-correlation-id: d08c9c6d-946b-40ac-9146-08ddff880838
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|42112799006|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?9z7bwdNGMfum5ioMaa1lPNwBxM/MGCrhu2HbofnFXBoGtdUcGOj+VpTEBM?=
 =?iso-8859-1?Q?ClEY1dlfGTAH7KmASkcKOb9C71aqhUX9TMaItXjOS8LUp9kfSFwZl/QsZC?=
 =?iso-8859-1?Q?TxyEV1BsBKTZjU0/oyfP9YE6et4Q4BoVsOoNY2L768xMuz1KUqmUdh/OH/?=
 =?iso-8859-1?Q?bQ0XS6OS/ZCX0PMaLI8f/FiQHHyVrXt0UgoUSrmofo/2UwddJKsJY+A7b4?=
 =?iso-8859-1?Q?PkCI30zp15eJyMH3HZ+hhtPwXO6fny36eMYfsiYtOUf699kUrisvgpDJQZ?=
 =?iso-8859-1?Q?HVS9v9rHB58/BMZx+ispR8psPSGmInN8NY5Vc8YGIfqPP1Sced0Ez51JYw?=
 =?iso-8859-1?Q?pNkEYsQw4D+BWU4fTeNF+mK7GigDKgdDrVK/TqOPFxCs9N0GkKU0dEHrOi?=
 =?iso-8859-1?Q?cSe94XNbtUdOe3HdhaMrmXihxOnbJ4IpImtMW+77jxMPsmQS/T3UvShGMg?=
 =?iso-8859-1?Q?AjlohEzGRcVq429rS8Pv2C7LrYlTbgVL06vocso1VhDVMt9npzp9fSB7fE?=
 =?iso-8859-1?Q?j9iBAyiJTuk11pfRcIetX36Cu5H7x4I2csSxmiximicH6QWK78rBdlXO0k?=
 =?iso-8859-1?Q?3Vkw8miXhgqZTOwZ9AjDPiFXyQjx7EgYc8TIaPTx7wMuhxnfWwNNqVlhFZ?=
 =?iso-8859-1?Q?7TZMdTBOCGA7+HZlf8EmCjtw+/+mga2UU5gzCqntLEDOx3CKrMJByi9fHy?=
 =?iso-8859-1?Q?2cTWMXSHkyHhJFYIK/w5VQcp3dJUA//NQ0XJkkg0pJ08KAr1x5seai3WnK?=
 =?iso-8859-1?Q?we6/pG/V0dSuyFIa7tRPmKcqMyyQQSA1h81Lep8QH4PePk/X7tJZgmhxCa?=
 =?iso-8859-1?Q?wP65Y/Y689GOYmZ3Ik+wQ7pfQ/tcIFFzcvtSOyy8Q28WQoJIIbm6drgD/1?=
 =?iso-8859-1?Q?ydBDh1LbihLPrq1E1eaO6lvfmsd4oHE2oQYZRf9c2nst0U4Taw4I8YEIhP?=
 =?iso-8859-1?Q?8dMIxa6PQj66iGERxLxSBz4s6emq7u44990/VCYNT5ZqJLZjhDwyz+HYLR?=
 =?iso-8859-1?Q?BncjmjPbF+RMqVrZkPoxPnSx+rPBFomHB/6iHgYJQ2Lj9mw/VlrOWHVJVn?=
 =?iso-8859-1?Q?74a7S5ZItISpvKEvRc1AGwVWKp0E5Ynaji2QxohG0P4h1TkGS9SQLxIdS2?=
 =?iso-8859-1?Q?Q6sJHEwdeoAFLH4vwADd773hvBs9WBPMjjGbeAgJILAjI2gNP393vygRA8?=
 =?iso-8859-1?Q?s8tOhp//xbSJVWoJ9ZNVdrYayk7G1Bdo2xULZGGRjQRr2HBLQHC1nasEBX?=
 =?iso-8859-1?Q?sIZ8nTud8qgmXjOhyyeIYgrq9N8Sdy0P4EafH9a9HRmwLGvUx2F8ng364G?=
 =?iso-8859-1?Q?ng4jK2U9VjTuqddMu+3Va9SyURYKrMm08Io1F8r6/biwJiDXmxPKxcXEza?=
 =?iso-8859-1?Q?H9CyOuQnSU4U3zFseh7tJFMBmWdlUQuQFmqXVKRku3WDBirPLT0HCJugC8?=
 =?iso-8859-1?Q?QYVfxLOzTASldSRun+vrNu1Agx/ghLPE5Pgbi7JBZ/EYFpDhdoFFsh3kTf?=
 =?iso-8859-1?Q?Cqw34IT2ImizOip6L4iD0W9npAH1JWVzacnJufVrvLNg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(42112799006)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?/Q0xIKKy6HccjeAReA/+/psE6/wO1C0708ZmDbhRkYpTMftFd2xTGQNF5+?=
 =?iso-8859-1?Q?F0HzrvdzQdjOpqKR76LKDNG5B2jUvw90O1Ou8nad17lF/RvDTkIzLAY8xc?=
 =?iso-8859-1?Q?yWu6qHnHEzEV4BDswl/WzB2HVIFgGDAHjYdYhUHBzYvdz2COq5TIW63vPu?=
 =?iso-8859-1?Q?xGDZR6rMcbEU+BjK05BI2oZ8SbQ2MYGJQAnmfJCgZ37luP763fydbiH1CN?=
 =?iso-8859-1?Q?jUMMKcpDXX9k/FsRM6hgnEcr5fZGiBYTCHdTGFruauQYRfK/d0ugYV87+Y?=
 =?iso-8859-1?Q?MU442QUtd4zKd/Wos0nodrDMvFEXXaY9hgRdvExPLk/kUUpfmxE0Um9Q9A?=
 =?iso-8859-1?Q?pCNjV52jvzbUwLseV/hwPOVTyUfbmrR/7CY+lBiZaaQOhMwBdlkfRlzD3S?=
 =?iso-8859-1?Q?TcXbiQHHQnOF5jyBp4SkMofkv4Pu0ggiwzDcLKx1mQsyWi4ZLNMuvUb7GG?=
 =?iso-8859-1?Q?VAtYSphrO5LhIZqsb155v8cEV6MkyDABJo8HoTohJJbLkYpLr1J48FPRFm?=
 =?iso-8859-1?Q?mskM/4BUz3KJFwtXLGJi5Bf93s5rydxZPDEg/bhqSD4AQ81BMIwfrrypT6?=
 =?iso-8859-1?Q?/mdPxGmvTt/jUE5vqzJwszsN0ivlBm4orJEkwDgOzcg7WhnhK9YLDv+Hh/?=
 =?iso-8859-1?Q?W0YOI8P2tbAKRrYxidGwmbQTaIKJAjr6c1s196+V9xzBLc24ax7qX+CR1a?=
 =?iso-8859-1?Q?UXTemohX/GlvaR+09bNQJhR+D8HO55yOLXTuXIE/GeGtwV+QPVoGc5Jz4p?=
 =?iso-8859-1?Q?HPm3WVenSoRoLvYY17OZ/8RQOcsi+00LSZtqF7nrlVsKlUFhkr63hqkO+Z?=
 =?iso-8859-1?Q?EAWrV3SdWGIKSwgR/UlsE3z5Sw9TE6TyfaZS5NjejJ9IupXZwarld5j77A?=
 =?iso-8859-1?Q?OkYTeC2+PqzijylO7Loxy9SlTg6cWYwbGZaqIFSAOsMfMYYbXlWUhM01S/?=
 =?iso-8859-1?Q?gbhgoXNoDQcBXicvEZPDKeUy2LDqzsukrXbMRww3dN2nExaIFZde83/2Fj?=
 =?iso-8859-1?Q?I7/0jhjY96aRWQTQZlslNT9mja0IroskZqR1i2aUGbV0icYUUGp1lCdbhK?=
 =?iso-8859-1?Q?4wkzGXaePKDK2QLsasNdwifwheeeLAeVYcqymkAdfRMQjzWKtbFmEJZHVC?=
 =?iso-8859-1?Q?GVoWnAPzGfcA+62rd2Y7vPmLG3Jw0NOv3AxcGdzGNDRqiJV9TlyydJSVs2?=
 =?iso-8859-1?Q?zv+GVu3mxmbMWFAUA77NvflVqbVK1mW26IvYIpnWBw0m2ba6DjuffgMQLW?=
 =?iso-8859-1?Q?y/452qVe2Ju18X0GUQIpAwEcppUM8v5UY/G9wghaZwV2dfM5aLCpfpvEQR?=
 =?iso-8859-1?Q?b4yUKFdZrfZH1YrjGeDSldKxAc7CGQsRP6kCbRWeGfd4tQ9KY0T1PrybR4?=
 =?iso-8859-1?Q?BWZAMSK40Z081GMCtk7g+u8xBqNs/CtRztuGr7EkYS+8rSq5/66lKfoJVI?=
 =?iso-8859-1?Q?yrWTCLlZhp44f9/cl7/MTmFcXwgY1Bo8sdnFW8NpypiY9WUdoekwkBKbTt?=
 =?iso-8859-1?Q?xg/I6x1Dac/I3/CTjYDwAh3hM5+N6JpKxTtlc5yM3WNuRL7XVSZFsk8lfc?=
 =?iso-8859-1?Q?S9MiTnTMFT5j65YZBPEW7N9yKCgH9kRA5RSkiGAj971MFvxY1gxfLJ5X2B?=
 =?iso-8859-1?Q?StHX59nV2k07zS1xkl2YqLqePdpXv14HyX9t0lgRwRBDcvhJiMMjpXwA?=
 =?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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d08c9c6d-946b-40ac-9146-08ddff880838
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 18:43:07.4502
 (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: 4cJtBteXleGUYvFOecHa+VROdtm+TY4O2LbPHqIRzoz9COZ2YRxX9vqC9MOn/QKIZF3hlsFUnbrucO5VOergIYDDXCMXAwEVf9sdYcddYuc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6591

This patch series consists of two patches that were received by dividing PA=
TCH v3.

Link to v3:
https://patchew.org/Xen/620eb8fe22204e204cb471e93d2ea789f879d854.1758744144=
.git.dmytro._5Fprokopchuk1@epam.com/

Changes in v4:
- PATCH v3 was divided in two separate patches
- added notes about predicates which end up as constants

Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2070317153

Dmytro Prokopchuk (2):
  arm/acpi: address violations of MISRA C Rule 2.1
  arm/gic_v3: address violations of MISRA C Rule 2.1

 xen/arch/arm/include/asm/domain_build.h |  9 ---------
 xen/arch/arm/include/asm/gic_v3_its.h   | 11 ++---------
 2 files changed, 2 insertions(+), 18 deletions(-)

--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 18:43:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 18:43:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133280.1471449 (Exim 4.92)
	(envelope-from )
	id 1v3IqA-0002fM-EX; Mon, 29 Sep 2025 18:43:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133280.1471449; Mon, 29 Sep 2025 18:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3IqA-0002fF-BN; Mon, 29 Sep 2025 18:43:14 +0000
Received: by outflank-mailman (input) for mailman id 1133280;
 Mon, 29 Sep 2025 18:43:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3Iq9-0002RY-4v
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 18:43:13 +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 26bafb6b-9d64-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 20:43:12 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by VI1PR03MB6591.eurprd03.prod.outlook.com (2603:10a6:800:19f::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 18:43:09 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 18:43: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: 26bafb6b-9d64-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xmbVklRYnxgqAnZywy8U6vHbD3jB8K0RHa6Bgpr12e/c5DrZy2nTrVkAk/v/Di8X9uha7dksWi0/ReOFRXsdz3BqcPYThWyu3qcKrnuTBm22hKtdo73lihwlYvMsc46WkBiXv+bvIEg+FJ5rDxLL8Kx+rFO4EU5+7Lr1bOIAdueogagPwW+6Q1at7e65XouVarhT+CerukxeQ3jHCEQzbdyfD1rnTbYllmxC9NBGm4ygm2Ay14ZjVqxN6E3W/PkRS4NeaQTJkuBNvA2du8cojDoD0pxlMQ27bEMjC+geyhrqMZruh2SJ9dMxukFYwVZVdiVzt5Rq4XAVsn3oNvAooQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jZWjebV7wz+BOSCoJoGNDtDTi2eO9j0uBNtCQOaT6JI=;
 b=aHDe35JPDw6G13SOA2TSmP2fqJmAevhHRmoqHidMTkNwzgX3iiOMroEKqOud5jz0A7XpoZOcTvy4E+bMY6AWIw8kyL4vBZglPAg5tsk/kj7RzgrrpDQIeMiR6EVAXa+4OQQ5Qsl4nqv8b71pqNZ7pCIdD4crnAhKgPyIg3G0QfalsFmzvRz1jiaNhgekFEMnMR/D4p1k3S5S4LKA8GMWZ6KX4gHboIsCm7oAr8Z2dNv6X5VhLTBesSKmpSnp46cpOCSJjhxw5ucra/NOMKwUjVpRi/i0DgsE3eIqRsJ5zzCOM/CyL02kZm9jqYXg05TlAOMcdaFunlueLctq2z1m8w==
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=jZWjebV7wz+BOSCoJoGNDtDTi2eO9j0uBNtCQOaT6JI=;
 b=ZGEtlQmXsNmsz2ntR1HSO1ADlrddResFrKiR6Lcygh6ExQcL4wVy3sItG7opatJrc+msdjRjNZ1/d3njUlQ1prtJ4Tc+bGBFqasnG2TEaqb24IEqR/13ASTi/UV+ax4cmpG91yyiasJF39tOGMrVJzTT53aS26i8C2LCczg3dCrb7kZzPetAHjIyHmasqW1EWNBo57fd9G213Fm1uQI7JDLw1rGltc+ppFGQExfmk7cx8n5r3PXvomy5KVtkA2TeJuo19dq0QU0+dkabeuCAXkkvITtRiL9Y+TkZxEr/MF1mihWlWWZALxhadqGobrOJR7FShlOEkqivv0awwt1lXg==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v4 1/2] arm/acpi: address violations of MISRA C Rule 2.1
Thread-Topic: [PATCH v4 1/2] arm/acpi: address violations of MISRA C Rule 2.1
Thread-Index: AQHcMXDmBSS0MiCg4katDMcviU0Eww==
Date: Mon, 29 Sep 2025 18:43:09 +0000
Message-ID:
 <53f0ef3aa8a3ac07bd5ac431ca940e1351e931b6.1759168391.git.dmytro_prokopchuk1@epam.com>
References: 
In-Reply-To: 
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: GV2PR03MB9572:EE_|VI1PR03MB6591:EE_
x-ms-office365-filtering-correlation-id: 3d4130e2-bb69-4819-e743-08ddff880931
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|42112799006|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?8HUrCkuYqvq82BB9/IGKT4budJ2hw/z/W/vbF73oP+trjpOBzCLpXt05/R?=
 =?iso-8859-1?Q?7vdXCJh/vU5wjwYxzpccYEqd151iR0439l0Vug7NYxwZRlSJ/dmBcysa7Z?=
 =?iso-8859-1?Q?lPzQEjIZxSgqJOP4eWGmRMqLABKNY40aFc/NAf4mcULfJ7GCIZV1DKqpW2?=
 =?iso-8859-1?Q?SYN6ODTX1qun6ia8UdU0hsEADGfwmTjXkSE05bpLT1sh7Awa3xSl0Yyy+k?=
 =?iso-8859-1?Q?rZEkAWY/gfuUQpozPutySMAoVk8+DWbjl9knbQYBX/zOH1KkEB3GehOy4E?=
 =?iso-8859-1?Q?dZDT370gRSRegp9H7ErXm536sJ/5rOrQoS7Qp2UXC8gJ41aJXk0yX8PyLL?=
 =?iso-8859-1?Q?5oCsovBWvWUqGYECH/i8YGfNDE1xg4QF9yMDHHyRMqt6Tw4PoNd+2ehBBD?=
 =?iso-8859-1?Q?1aJrXk//mWu/IkQAfLLUHisocMFUTS62zt17r2iV8mtZe9+Q8srXxC0pw9?=
 =?iso-8859-1?Q?DufZW2bRDMgo2EkClSeSVAiREZuZK/pXGmZjQPxpWx+uDX+UiqaLQB0FBD?=
 =?iso-8859-1?Q?FB4hcG/MC/quCpQ7B4FoD6stdS5TvdpLekNnNc/2Iuq324FZeO+6SlFAu+?=
 =?iso-8859-1?Q?gcqhTaQe4JhhpGwyaH59eujJ1d0c8O7dQGsyVmsBoQ/JLDTFHg4nzFXbuH?=
 =?iso-8859-1?Q?fGBBKqQg0BuA/kOpAUnFTu05dH2PUGrZ5c7hhgOveVby5geig2PxpBYOWv?=
 =?iso-8859-1?Q?MQv1fanVTcJFbBlnVVB1Pw1ag9HtketcuRXkbSN3hUQLxbyGnr8iwbivEP?=
 =?iso-8859-1?Q?dcFObVZo4IAqyyDjbD6xQAZgSz9P6FDSuYvbRy6a6W18OkeN3PSyghebQ0?=
 =?iso-8859-1?Q?xCZB5p3Eaaal6ki/41N9XZ73zo9QXXp/nri8ei/Qe6d1gTlCpR6J2EpLX0?=
 =?iso-8859-1?Q?OLffFH3lvjKuZBvAmEa551jaCUaChd9GyD3SOQd90NCyFnaGdNz5CLwbVW?=
 =?iso-8859-1?Q?tgHUA3l3KuPkW1C8p0qXjMTEIujC4mCA+/slCcddWB43C5s3JBdocfT825?=
 =?iso-8859-1?Q?k2VUTYtM1R+l6M9keO4nPtV7VDT5cafamU81Nm/PwSODtFHacDOlj8oKlv?=
 =?iso-8859-1?Q?kWbPVIbrMf2tZiNwChlzYoW4Ufx+BGLhVoAPjWt1xrnTmUSu7s27rNIQe+?=
 =?iso-8859-1?Q?7FfO8MWO3uxWTns2Lksw81Rcxwn/XBBZJANilRVG4Ganxz5s6jOj9x81Er?=
 =?iso-8859-1?Q?kwZVBZfuGUD7j6ajDrJC0+VJ1QCf7gM4rS5axSTcSYqNlUpPRpL23NXFLJ?=
 =?iso-8859-1?Q?4IwQebWk/m1GIZSry5G/rTQKQuzaXYVA3DESGD2CaCx0dJcHSgaLrw1wCi?=
 =?iso-8859-1?Q?PT2oKVKq9yTV9rJnClKWOcz5wyQqCwmClFQlGWLpbIralIVdN+4S2yDixc?=
 =?iso-8859-1?Q?AxFbrowIRZJ6xs/Htl6FqsD9Bo8gEABmk8asnhja4ycX0vDp//uOgKKtG6?=
 =?iso-8859-1?Q?qZDZxK9KqW6AYB/HLoRiuWz5wAe8WcrYhwvaCFYeMfIFJCUhCuhS0K4vWv?=
 =?iso-8859-1?Q?AvEGKc9YRBQwRTzNzwyJ1P+x/p6yDplsjnkpw3M4NuV1h/msl4Jq7BPxVj?=
 =?iso-8859-1?Q?btNAj8AdHC9zyRqbQWSDQ4LzYjL4?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(42112799006)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?VfhNWAkqv/RmzIYSzuS5XZBExtmQ7RawC+voW331dOH8tHQ330q8q1zKHf?=
 =?iso-8859-1?Q?w+GErSET8xygUelaspWA8YrEB8ldJJXJ7GFg8eSV+aME+JZU8+QatJPnt/?=
 =?iso-8859-1?Q?o+iaVvdxUidCTNxBaRpQ4M25ibmVtuPOfCfeldQRGhdcHzKsKZ/QWelgKa?=
 =?iso-8859-1?Q?/s7Spgjjky0/jg8jkIeWyWfJvvfS5b7mgVEhKRLHek9V/4iKaBrp/kkZ+4?=
 =?iso-8859-1?Q?Y8QZbgou3zdjGNxrsGx+471OhK7y9BCl32ce80oCqO9y62bAn2vIUD3igH?=
 =?iso-8859-1?Q?7WMbvL6h4uur6HybU3SmwJHniln7nIMbLVg91SRV1kMOYuww3k2soLEntK?=
 =?iso-8859-1?Q?oRMLHSTb32GGb9NYt3+Y08slrSypC7JQEpXI4UYY4CvOe1bHpKTqmAwtOD?=
 =?iso-8859-1?Q?SSbdEVRCsKpYvpkX3sGN+M9o65hiQY8sxbk4JXEW2D3mH3xY7JWP2OEFzA?=
 =?iso-8859-1?Q?4JXrDhlLsWBPpieAttPP/5ogoJXh08Y9F9JVQkTALsia0iwYOncYgKpSFL?=
 =?iso-8859-1?Q?sGjuXlkHktVYj7OMQ86iP5KFe975wlYib7zxK7WouFqWNotQkTr6dtA2cb?=
 =?iso-8859-1?Q?iIrwPwY0TKYy126vUgUOeQCgaLjLaNgUJlCufT+NFrvPP/XG4VsKd8xrPL?=
 =?iso-8859-1?Q?nlJjmnM04SvDF8U3rb6/GnDpbLZXHlGzeaHXTzMG6+Dx342tgDGnjy9mLU?=
 =?iso-8859-1?Q?4MDRHtmrKGwLudh61PA9+MF35b5qywPbKI3xJI3fxDzoWGMiUM+sHWVBNy?=
 =?iso-8859-1?Q?Or8Gq84Qyir9ZHVMVbVJvU7S71IZQH764D7m5RpjOshPQqYqsik1TXye7R?=
 =?iso-8859-1?Q?Hexg+G2OjSY9QjvpkCRLee0C14lHQO8f8mWMCPVNNgwVJxPM3tEgliiSle?=
 =?iso-8859-1?Q?sIcCMqGxciGJEieHMTaVg8wokc9duZLUFy1z6fai+2cz8kEY+c3DHy6pUK?=
 =?iso-8859-1?Q?jVd/9bysODFlX7GIIn1UAUFioLdGpkXVWQ3JgtiTRpfbpPZGQ7xSqZdWNz?=
 =?iso-8859-1?Q?aGxCNSbZ5g/vIGR9seQXOBGk9DKJIntfBPoJATKjX85cFrq4qtOlz/5scq?=
 =?iso-8859-1?Q?NMNdDgWqdPxmBJBCmyfzuAqwODCl0vbcJLNAUFHCwn+61o17b9k2eU6yWk?=
 =?iso-8859-1?Q?Q+GhclotObhgKwqBL/xKenzH7iM1+2A6t3Vw6gJMKb2uwscNqY5Tyomb9b?=
 =?iso-8859-1?Q?hHNH7dOERR8IwKsw79IZpzn9M9OX1L0AuNkMeU/sjWnQNJSxgkM2KJD2zC?=
 =?iso-8859-1?Q?wbLskPlcX+a99csQ7sVUT1Pp+pOlaR10L8IpeKWzIDa8udEAUdBbxdfSC8?=
 =?iso-8859-1?Q?XCVvhUf4uHhhNmwdmLZI7MzL+kgNN0bVU5D3oyse/4OOTycEtMKEbusV2n?=
 =?iso-8859-1?Q?MRnrq3ZhuUlSQGQcxO9Vo6CLXDrcynP/V9PK+8VVN4VacwWmC0sIyE3ZcO?=
 =?iso-8859-1?Q?zl1hxdD+WHuiC3ankDeJOC/5sTy057peBYaaKuq4fN0CN8aouzQWzR+UDc?=
 =?iso-8859-1?Q?ktqkGfd9gtGtZVa+Z8dgkRTnou4AexG2jYcjA7XPc9J0ePNBRE3uslveQO?=
 =?iso-8859-1?Q?pzuLUeQVJc4Mb3SYmDVdPX1nGrLBkNd99nuJ8rDZ551xYvBxkHb9l3YOXv?=
 =?iso-8859-1?Q?L6QAK23PXTGYmp5nNzQoA2WSPlDTZM5yZR973/uMeFVnixYWpfaVln3w?=
 =?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: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d4130e2-bb69-4819-e743-08ddff880931
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 18:43:09.1352
 (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: p4kiydLYRMqissRc8SYkvtqg2ZVtp6FR+kTqSdS/TYhXWZ6DTnZ0Fckpu92IoK8PueJHAF/5Pcm1B577aXHBLwbJKIGykwG43Q/kwbDs4Ck=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6591

MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
In certain build configuration the following function 'prepare_acpi()' is
defined as inline function and contains the macro 'BUG()'. This resulted
in violation due to the function became non-returning.

To ensure compliance with MISRA C Rule 2.1 remove inline function and its
'BUG()'-based unreachable code. Provide unconditional function declaration
for 'prepare_acpi()'. Rely on the compiler's DCE to remove unused function
calls and use the compile-time constant predicate 'acpi_disabled', defined
as true when 'CONFIG_ACPI' is disabled, to statically resolve conditional
branches:
    if ( acpi_disabled )
    {
        ...
    }
    else
        rc =3D prepare_acpi(d, kinfo);

Signed-off-by: Dmytro Prokopchuk 
---
 xen/arch/arm/include/asm/domain_build.h | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include=
/asm/domain_build.h
index c6fec3168c..6674dac5e2 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -15,16 +15,7 @@ void evtchn_allocate(struct domain *d);
 void set_interrupt(gic_interrupt_t interrupt, unsigned int irq,
                    unsigned int cpumask, unsigned int level);
=20
-#ifndef CONFIG_ACPI
-static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo=
)
-{
-    /* Only booting with ACPI will hit here */
-    BUG();
-    return -EINVAL;
-}
-#else
 int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
-#endif
=20
 int add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data);
=20
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 19:39:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 19:39:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133344.1471471 (Exim 4.92)
	(envelope-from )
	id 1v3JiZ-000350-T6; Mon, 29 Sep 2025 19:39:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133344.1471471; Mon, 29 Sep 2025 19:39: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 1v3JiZ-00034t-OT; Mon, 29 Sep 2025 19:39:27 +0000
Received: by outflank-mailman (input) for mailman id 1133344;
 Mon, 29 Sep 2025 19:39: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 1v3JiY-00033Y-EN
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 19:39: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 00d48e92-9d6c-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 21:39:24 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-46e3cdc1a6aso28169615e9.1
 for ; Mon, 29 Sep 2025 12:39:24 -0700 (PDT)
Received: from [192.168.101.81] ([217.65.134.12])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e59abdde8sm3726925e9.2.2025.09.29.12.39.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 12:39: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: 00d48e92-9d6c-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1759174764; x=1759779564; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=B6d4sRolAyHHh0+NKbkmnD5c3XSjQ9m4SuLVmyGF7Xs=;
        b=I/T/5sVqumrUl7qcAOtqJKCYP1d35MtjH1VM1WZykMXikweTCbwiGVxe/Xqz2e1+jO
         XpUWkQ3pP1ZYcdkYK1wjuri95xXksJhb1cpISg3wbVjoDbQq8X98TZX1rJuar8OSJ50A
         5PEPYD8tR2KrjkhMekcUJ6DyfcokdEMlWlmDc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759174764; x=1759779564;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B6d4sRolAyHHh0+NKbkmnD5c3XSjQ9m4SuLVmyGF7Xs=;
        b=PbMwhOnckRiZM5ybEklBxWEbFx3/SeUrCyv9gKy0xM5HzZ/iCfwNEqFHg+P4LphJh2
         06iowCsOHVaoHEYBc1ShkniEB+GMPUviugl3hzondlUx9gE24Ldkn0oGkjs2YV2QXXMp
         ocrPsVo+6iax6/0WMFDQJx6AqVQ0K0d876X5YGqIL9EPvgjrn/Ng9vBgcyfm9uZHFTsW
         69ZSHSQOonRjgZx7QWjQEqeFrnH2PMTHJeoJKxL29QW2tcyYMZGqeiHycRFkPzBD+1X3
         g8eW+A2zDCGVxkcsdNVituaXo7G1CFNtycxvtMzA859hmgmEhWWnT8mA3CRQhXDTFKJR
         gujA==
X-Forwarded-Encrypted: i=1; AJvYcCVRmEFaZ6vwSE2H8fndFwgXkPkbBXJUzY+TITv7j58nCTZa+aoiQr1000p9y0GjyAq95KU8E+58zpc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzozUOwZcGrEUgAPdZUAMU+4RODkJGPxvf+GJOnaD4K9EhK7Iiw
	UhMPbug4++NCkhN/hd4dpgVt1G3rFrHUEvEb8gqySGFuUk2lSqN/LArfDMBIH+j1KNg=
X-Gm-Gg: ASbGncvNo/NSEo9Pf0NYdgWhsZCssDT8ONSZmyXH0jaW13UQUYdQ+pef+uEq8ViqnEg
	RViDm77qfUX12YA4Au93viLEhyNZkIVztssslu7Nl8oP3sYvPs1ANRz8i+Wm7F9OSRfkcZT69+R
	ec4ttac3RFnwcukwcG5kJcCvsL/Z2j75722huh/hm01LHJFdzAXJ8QOwSenLmzh6w7VC2wPwRvQ
	95eDf4nk3lK9ce7N56hVjTCWKXLBvecD8pLbpMPYYBV0cNzO9jTugfVPssPoCMT8EPMqJgAihC8
	vhEsVVKWDj71CJg/ZDcY2iXxnY3EnOV3aP7DKvtJLKpRGEuifWskPpYPvy/3MMHEPFnPa9gdTkq
	bUR/7+wimslhMEtx6M3JQVgY9eh+ppPDCpoisRSxgXBNAzqgYOw==
X-Google-Smtp-Source: AGHT+IGbc1FrwtGRqd9+Qt82VBloU79OFkbKdf+sjeDd4eRS/8HSYy2qGbSgZEUWIGLc8YfBAbTQ9Q==
X-Received: by 2002:a05:600c:8b2a:b0:46e:5019:69e0 with SMTP id 5b1f17b1804b1-46e58aabf99mr15338755e9.5.1759174763948;
        Mon, 29 Sep 2025 12:39:23 -0700 (PDT)
Message-ID: <45afdc14-7337-4786-b3ff-e3c07a6b5f71@citrix.com>
Date: Mon, 29 Sep 2025 21:39:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hap: Inline "flush_vcpu" in "flush_tlb"
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , Andrew Cooper
 , =?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 29/09/2025 1:36 pm, Teddy Astie wrote:
> flush_vcpu static function here is only used in one place which is just below
> where it is defined. Inline the function to reduce the noise and clarify
> what we are doing.
>
> No functional change.
>
> Signed-off-by: Teddy Astie 

Have you read the commit message introducing this pattern?  It's
11d9e114b53045e5f2009a26dad1d0d0f7df441e for reference.

The compiler will do the sensible thing.  What matters is the cognitive
complexity of the source code.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 19:53:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 19:53:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133355.1471484 (Exim 4.92)
	(envelope-from )
	id 1v3Jvk-0007rF-0r; Mon, 29 Sep 2025 19:53:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133355.1471484; Mon, 29 Sep 2025 19: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 1v3Jvj-0007r8-TI; Mon, 29 Sep 2025 19:53:03 +0000
Received: by outflank-mailman (input) for mailman id 1133355;
 Mon, 29 Sep 2025 19:53: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 1v3Jvi-0007r2-J2
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 19:53:02 +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 e690c9cf-9d6d-11f0-9d14-b5c5bf9af7f9;
 Mon, 29 Sep 2025 21:53: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 BAC8648A65;
 Mon, 29 Sep 2025 19:52:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1256C4CEF4;
 Mon, 29 Sep 2025 19:52: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: e690c9cf-9d6d-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759175578;
	bh=yaK3NWvIhH77kqF52JIxXBhOidWQDdPna23D7prhFhM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=XUUiKRNWX29jDkKYRGlHSBtLNcH4tyJnzhfzyfRp28OsOX4Le3cYNNPfWjndrx/F/
	 z/OYZIkUN0a/qBkb544LVneoJvwIxiC/1dpp3q99Hxz7o9e/EDwG3XQkHbBLveh/Aa
	 xKwx4PAEomPwedTFNeNjp8kEnEaFOa4KPiN8p7fOGLP0GMEYUDVOeavlAQEVTW89+t
	 HSir27mROUHMIZfdSQ9TFo5ZZ8yKTZCezQ4ixO8mU7CEKjAS0ONOmQV/61jaQHUYjM
	 aZDrGxQE+O5zMc/dMOf4ahEjvgiULeF0F5fbIS40unpaKvMj63I1J+nu4ya0pQTHwo
	 8RaIL12015sVw==
Date: Mon, 29 Sep 2025 12:52:56 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksandr Tyshchenko 
cc: "xen-devel@lists.xenproject.org" , 
    Michal Orzel , Ayan Kumar Halder , 
    Stefano Stabellini , sstabellini@kernel.org
Subject: Re: [ImageBuilder] uboot-script-gen: Add ability to configure static
 event channels
In-Reply-To: <20250929180746.1881872-1-oleksandr_tyshchenko@epam.com>
Message-ID: 
References: <20250929180746.1881872-1-oleksandr_tyshchenko@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, 29 Sep 2025, Oleksandr Tyshchenko wrote:
> Add DOMU_STATIC_EVTCHNS[number]="local_id local_port remote_id; ..."
> configuration file string option specifying the static event channel
> definitions for domain.
> 
> The build script uses simple IDs to automatically and safely
> generate the required unique phandle numbers for the device tree.
> The user only needs to define simple numeric IDs and does not need
> to manage complex phandle values.
> 
> For the following example:
> DOMU_STATIC_EVTCHNS[0]="1 10 2; 3 12 4"
> DOMU_STATIC_EVTCHNS[1]="2 11 1; 4 13 3"
> 
> it generates:
> fdt mknod /chosen/domU0 evtchn@1
> fdt set /chosen/domU0/evtchn@1 phandle <0xfffffffe>
> fdt set /chosen/domU0/evtchn@1 compatible "xen,evtchn-v1"
> fdt set /chosen/domU0/evtchn@1 xen,evtchn <10 0xfffffffd>
> fdt mknod /chosen/domU0 evtchn@3
> fdt set /chosen/domU0/evtchn@3 phandle <0xfffffffc>
> fdt set /chosen/domU0/evtchn@3 compatible "xen,evtchn-v1"
> fdt set /chosen/domU0/evtchn@3 xen,evtchn <12 0xfffffffb>
> ...
> fdt mknod /chosen/domU1 evtchn@2
> fdt set /chosen/domU1/evtchn@2 phandle <0xfffffffd>
> fdt set /chosen/domU1/evtchn@2 compatible "xen,evtchn-v1"
> fdt set /chosen/domU1/evtchn@2 xen,evtchn <11 0xfffffffe>
> fdt mknod /chosen/domU1 evtchn@4
> fdt set /chosen/domU1/evtchn@4 phandle <0xfffffffb>
> fdt set /chosen/domU1/evtchn@4 compatible "xen,evtchn-v1"
> fdt set /chosen/domU1/evtchn@4 xen,evtchn <13 0xfffffffc>

I'd like to make an alternative suggestion. The user specifies triplets:
DOMU_STATIC_EVTCHNS[0]="local-id remote-domid remote-id

To generate the example above:

DOMU_STATIC_EVTCHNS[0]="10 1 11; 12 1 13"
DOMU_STATIC_EVTCHNS[1]="11 0 10; 13 0 12"

I think this is better because it doesn't require to invent (useless)
unique numbers as references. Instead, it focuses on the data that
actually matters to the user: the event channel IDs at both ends and
the domains involved. These are things the user must know anyway.

The only catch with this suggesion is the definition of "remote-domid":
in reality the DOMU array index is not the domid in dom0less so we would
have to clarify. Maybe we could define it as remote-domain-index or
something like that.

What do you think?


In ImageBuilder so far we have not used separators like ';' here but I
think it does improve readability so I would keep it.


> Signed-off-by: Oleksandr Tyshchenko 
> ---
>  README.md                | 21 ++++++++++
>  scripts/uboot-script-gen |  7 ++++
>  scripts/xen_dt_domu      | 89 ++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 117 insertions(+)
> 
> diff --git a/README.md b/README.md
> index 7b68cf5..52ed1f7 100644
> --- a/README.md
> +++ b/README.md
> @@ -218,6 +218,27 @@ Where:
>        DOMU_VCPU_HARD_AFFINITY[number,1]="3"
>  ```
>  
> +- DOMU_STATIC_EVTCHNS[number]="local_id local_port remote_id; ..."
> +  if specified, this parameter allows the configuration of static event channels
> +  for inter-domain communication. Each entry in DOMU_STATIC_EVTCHNS[number]
> +  specifies one or more event channels for a particular domain.
> +  The configuration format for each event channel definition is a set of
> +  three values:
> +    - local_id: A simple, unique integer that identifies the local endpoint of
> +      the event channel. This ID must be unique across all domains.
> +    - local_port: The numeric port number for the local endpoint.
> +    - remote_id: The ID of the corresponding remote endpoint to which this
> +      the local port connects.
> +
> +  Multiple event channel definitions for a single domain can be provided by
> +  separating them with a semicolon (;).
> +
> +  Below is an example that creates two pairs of bidirectional channels between
> +  two domains:
> +  NUM_DOMUS=2
> +  DOMU_STATIC_EVTCHNS[0]="1 10 2; 3 12 4"
> +  DOMU_STATIC_EVTCHNS[1]="2 11 1; 4 13 3"
> +
>  - DOMU_COLORS[number] specifies the colors (cache coloring) to be used
>    for the domain and is in the format startcolor-endcolor
>  
> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> index 4f92610..003a622 100755
> --- a/scripts/uboot-script-gen
> +++ b/scripts/uboot-script-gen
> @@ -428,6 +428,8 @@ function xen_device_tree_editing()
>          fi
>      fi
>  
> +    xen_dt_build_evtchns_map
> +
>      i=0
>      while test $i -lt $NUM_DOMUS
>      do
> @@ -512,6 +514,11 @@ function xen_device_tree_editing()
>  
>          xen_dt_domu_add_vcpu_nodes "/chosen/domU$i" $i ${DOMU_VCPUS[$i]}
>  
> +        if test "${DOMU_STATIC_EVTCHNS[$i]}"
> +        then
> +            xen_dt_domu_add_evtchns "/chosen/domU$i" "${DOMU_STATIC_EVTCHNS[$i]}"
> +        fi
> +
>          add_device_tree_kernel "/chosen/domU$i" "domU${i}_kernel" ${domU_kernel_addr[$i]} ${domU_kernel_size[$i]} "${DOMU_CMD[$i]}"
>          if test "${domU_ramdisk_addr[$i]}"
>          then
> diff --git a/scripts/xen_dt_domu b/scripts/xen_dt_domu
> index 8134896..97c5325 100644
> --- a/scripts/xen_dt_domu
> +++ b/scripts/xen_dt_domu
> @@ -37,3 +37,92 @@ function xen_dt_domu_add_vcpu_nodes()
>          fi
>      done
>  }
> +
> +declare -A EVTCHN_ID_TO_PHANDLE_MAP
> +
> +function xen_dt_build_evtchns_map()
> +{
> +    local i
> +    local evtchn_str # The full event channel definition string
> +    local def
> +    local local_id remote_id id
> +    local new_phandle
> +
> +    for (( i=0; i<$NUM_DOMUS; i++ ))
> +    do
> +        evtchn_str=${DOMU_STATIC_EVTCHNS[$i]}
> +        if test -z "$evtchn_str"
> +        then
> +            continue
> +        fi
> +
> +        IFS=';' read -ra evtchn_defs <<< "$evtchn_str"
> +
> +        # Loop over each definition and process both local and remote IDs
> +        for def in "${evtchn_defs[@]}"
> +        do
> +            read -r local_id _ remote_id <<< "$def"
> +            if test -z "$local_id" || test -z "$remote_id"
> +            then
> +                echo "Malformed evtchn definition: '$def'"
> +                cleanup_and_return_err
> +            fi
> +
> +            if [[ "$local_id" == "$remote_id" ]]
> +            then
> +                echo "Invalid evtchn definition: '$def'"
> +                cleanup_and_return_err
> +            fi
> +
> +            for id in $local_id $remote_id
> +            do
> +                # If this ID is not already in our map, assign it a new phandle
> +                if [[ ! -v EVTCHN_ID_TO_PHANDLE_MAP[$id] ]]
> +                then
> +                    get_next_phandle new_phandle
> +                    EVTCHN_ID_TO_PHANDLE_MAP[$id]=$new_phandle
> +                    echo "evtchn ID '$id' is assigned phandle '$new_phandle'"
> +                fi
> +            done
> +        done
> +    done
> +}
> +
> +function xen_dt_domu_add_evtchns()
> +{
> +    # $1 - dt path
> +    local path=$1
> +    # $2 - The full event channel definition string
> +    local evtchn_str=$2
> +
> +    local def
> +    local local_id local_port remote_id
> +    local local_phandle remote_phandle
> +
> +    IFS=';' read -ra evtchn_defs <<< "$evtchn_str"
> +
> +    # Loop over each definition and create a node for it
> +    for def in "${evtchn_defs[@]}"
> +    do
> +        read -r local_id local_port remote_id <<< "$def"
> +        if test -z "$local_id" || test -z "$local_port" || test -z "$remote_id"
> +        then
> +            echo "Malformed evtchn definition: '$def'"
> +            cleanup_and_return_err
> +        fi
> +
> +        # Look up the phandles from our globally-populated map
> +        local_phandle=${EVTCHN_ID_TO_PHANDLE_MAP[$local_id]}
> +        remote_phandle=${EVTCHN_ID_TO_PHANDLE_MAP[$remote_id]}
> +        if test -z "$local_phandle" || test -z "$remote_phandle"
> +        then
> +            echo "Could not find phandle for evtchn ID '$local_id' or '$remote_id'"
> +            cleanup_and_return_err
> +        fi
> +
> +        dt_mknode "${path}" "evtchn@$local_id"
> +        dt_set "${path}/evtchn@$local_id" "phandle" "hex" "$local_phandle"
> +        dt_set "${path}/evtchn@$local_id" "compatible" "str" "xen,evtchn-v1"
> +        dt_set "${path}/evtchn@$local_id" "xen,evtchn" "hex" "$local_port $remote_phandle"
> +    done
> +}
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 19:55:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 19:55:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133366.1471494 (Exim 4.92)
	(envelope-from )
	id 1v3JyU-0008PS-D1; Mon, 29 Sep 2025 19:55:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133366.1471494; Mon, 29 Sep 2025 19:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3JyU-0008PL-9k; Mon, 29 Sep 2025 19:55:54 +0000
Received: by outflank-mailman (input) for mailman id 1133366;
 Mon, 29 Sep 2025 19:55: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 1v3JyS-0008PF-SQ
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 19:55:52 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130006.outbound.protection.outlook.com
 [2a01:111:f403:c201::6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c86f93a-9d6e-11f0-9809-7dc792cee155;
 Mon, 29 Sep 2025 21:55:50 +0200 (CEST)
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com (2603:10a6:150:da::5)
 by DB9PR03MB8774.eurprd03.prod.outlook.com (2603:10a6:10:3c6::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Mon, 29 Sep
 2025 19:55:46 +0000
Received: from GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e]) by GV2PR03MB9572.eurprd03.prod.outlook.com
 ([fe80::edd1:842f:9b14:509e%5]) with mapi id 15.20.9160.015; Mon, 29 Sep 2025
 19:55:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c86f93a-9d6e-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=S9+maWaf1WGlCYm/Q08OV0rxcQQFJ7zH3qPIDd3zQaycN1AY587r7pJEw0c1yPEKE2R/Qm9ddb1ae3rLhxbxdq/ojBMQvvylqDR54/LSrdCtRLBnT0k223eXs1h7Lxv9U/JxvBjROxW7uMm+1EpphRTIqQ6OmTlMmLMwgZTCojidZ3apZ72iA/+YIuEbzTzQlQF4/40MwSUDfqmS9sE62FDTHGYhKs77oqCFWLezW/9MdMhP08mybGLdhZwp5FBgKogBcBHDv+HL3/EAc/NFPQbV+PazZbb90iy4B+raMkr6VJVhz3+ZlOUD7UBxuwOSbYBPqCJ/y/HQkzQf/RZcNg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PDNpMY8JYLJcz1TcoJVtdxvjvaqDkSl07G6GkIo5MQ8=;
 b=g0bh9CsHyA34mL4Z2y6rTsquDzwzaFE8WL/mvoYywcho+ql9WmvfJOrAZgvrpqN1qj38coO9swpyhxtl2qFq/UGXG9nU+s5fgeDxxAZoyIqZSDlSjKty2sF3kOy9KKOSab7vJBW8q3zC4aM81sad+/zRAZz+eEy1sPSP3P36oBJhpC7eTkyPsUgfXm68iw1qbBxajDd+xQn6ceLcNPtxZpzSPPhXTFf4k2Ru5sAIgjMWD0XOtkQ9WhpKv/koAdTNmgv0xY3alsBB/YCijvfDUHJHwGC2dVqcMJg9sm7K3BBIwMAcBv2qIYt4DQEGd6NDT+HlEQPRzWDlr1SJ6EGtEA==
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=PDNpMY8JYLJcz1TcoJVtdxvjvaqDkSl07G6GkIo5MQ8=;
 b=ZqAuTs1VobQOAqO5JnHPBKIHwH9gFsmuKHj9xlBRqLKcqQ976I/jt98dghOBPWnCp3gu2dDPU2PmqPCnsE60jZUGE7gYYtWsJRxCTHERqALHhxLRpNR7jllWdmjnrGkcvD5kzXY/MutQpooRWimuhwD3f5Y0WRQsUQ4H010uKZSpYRw/bYJuvRRbLFnNaBjQLRpQSNxrpTz/KL13tblMlOQF4Bwvf1sl9cWPMDBauVjHhDuEnsvcV/hWpzudUqkJ32v9i3/+rbEN/DYO4YkYQkETsL0v0Khb5lhdaihJ9r5wwqx00UEow1k3aH4hcXyog9cPrhXvaomrFW7UsQ1Yaw==
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 , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: [PATCH] arm/gic_v3: fix MISRA C R2.1 violations in gicv3_do_LPI()
Thread-Topic: [PATCH] arm/gic_v3: fix MISRA C R2.1 violations in
 gicv3_do_LPI()
Thread-Index: AQHcMXsLUvRxhyKkhUuhWVAohL+E7Q==
Date: Mon, 29 Sep 2025 19:55:46 +0000
Message-ID:
 
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: GV2PR03MB9572:EE_|DB9PR03MB8774:EE_
x-ms-office365-filtering-correlation-id: ffba5b74-e953-4808-c61c-08ddff922e3a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?OEL/kmJSMXs4wt2f1iyHQt2iY7PqnunzoLqYIwfLNCAMhfGdh9ffpLSE4f?=
 =?iso-8859-1?Q?VGHyaOn7MRApTHT3OQzXVjCvGHuSTOyABUppEQhdC/u5vBdsf/MOz7nuzl?=
 =?iso-8859-1?Q?/kLM+l0yAe5TvKIhcImmzrVXyaMYE6xywSGqsZ7O5RcolhxNH3ZzoLIj+I?=
 =?iso-8859-1?Q?7MPePyQhh/eTBTSZeatzwgPwvY+NeRZ578G7yA1lFkmjkfnct6yzDJiCbN?=
 =?iso-8859-1?Q?oFFy0r5N4qY2Chqmr3TZB08UfLlr75WT9B8UMy79pLJJlOJfPbSf8HOwwe?=
 =?iso-8859-1?Q?58aGmcmoDzxTefBk+wZFxf6RKm7wPJFwzJ9CrnBEEa+pYTHTeGhUx9zXND?=
 =?iso-8859-1?Q?2ZnNCA6q1ttvk1VbO0UCCIAh8NP25JQqLgyv9oLNh+wMfDmreNUtOU7PK/?=
 =?iso-8859-1?Q?9RoYnFX3+dmVN7NL8QxP9kN1DDkxcz2OzSPSC5f/KV8zqZVtK6N/uOCGjp?=
 =?iso-8859-1?Q?n0Lnax2uC8aTTcmsbFH6lcdg716PFZTaquAgEhNlvxYTxRl/9OVnSlkaiA?=
 =?iso-8859-1?Q?bhXjwhiVJu9iGIWcqmC+PEpzDLCNcMinqy2sOSwNfqzV+DVNiiXgOy0CZo?=
 =?iso-8859-1?Q?7WUvYNhVd/EPkFLGgQUEdUEz89Kv0hzb9pEkKS9hnwZB4rZhzSttuX4jkY?=
 =?iso-8859-1?Q?tTW52sqtQ+Xx9sTL5aN0/H9v360egSPyJX2s1bOyuxnGzV22Kcm14qUuar?=
 =?iso-8859-1?Q?2LhtzgoJgG+GkuVEMj4+g3ZXuLyidH4VtZ4CKD+KdUdv018JNbCsaEXI9Y?=
 =?iso-8859-1?Q?r68J4CtET1PGHA4NCVnHbNCS+HHSYCserxJL7C+yJiMv/ViM3bPEgOVsCB?=
 =?iso-8859-1?Q?H9cycgGMuE6XwxtlaRJXiP++AdXrNR1dLA5R+RdA79nZ5+MU9wnG8UmpoV?=
 =?iso-8859-1?Q?fSabFhVHcXU2BhCAcnOXHysZLI7I7lIf1eRn340uDYcTSsXcgIal1yLNd1?=
 =?iso-8859-1?Q?2nGA7fPesJ21PyR20LOP3nzU0WPFtw0d37wWIDIFnY+P+YA4/SAFbwp8jb?=
 =?iso-8859-1?Q?IJphu5ekLhbPdQ8zNGgPYg92FUEJ0cMsWBn7f65+hOlfdifUbDtVmHwZOs?=
 =?iso-8859-1?Q?a/yaj6SF7FrPPlGQncB357RS/sVuGPFqnjTOmYPnA14IpZxJK7I0rcP2/1?=
 =?iso-8859-1?Q?PTYD05LxbQE113e84hfKx6Vl1elAGXVjOYSq9ACKKrgz+W8muXAHWQivnv?=
 =?iso-8859-1?Q?FwqqwvOy234pYuvFYsBGdNXTQ16EuHF4QNEc4y/GBqv6nlF0gJM/3+g5N3?=
 =?iso-8859-1?Q?io0clMk92ToDhJH0ZHWnwviD+VsodWYhANmjqdt8mJcLTmTGolp4L36TlU?=
 =?iso-8859-1?Q?v2Ol/owxQwvNVibMSXPnUZFp3ogHdHJrHL8UMZ/dhbV6l8PSNeJL6FyBtV?=
 =?iso-8859-1?Q?wVHCZQDFIJB0rvMPGrio5b0daaSj5lHM8QzOrEHtybPZ/+ZHmfu+oe4Wrm?=
 =?iso-8859-1?Q?9NKWbClcwGvxVJCswP8nUfo+tu7k3FxK+iDOtAkcvPGik6gjHMp/euLANR?=
 =?iso-8859-1?Q?2Dl0vhr7l/IwQTojm8mmMPBdkprQqnPFkiSGDE6U/ejw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB9572.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?cK5NZtJmwGtIgdwNL9eBFpJRv781rfgXUXmZARwvFMWioYV+tKwD4D/Z8G?=
 =?iso-8859-1?Q?ZOvlfQ6jZVkTzmSFpWYS8V0c/zz+LO9uZImWYwuG7YrNx56ytoIqu6xOK9?=
 =?iso-8859-1?Q?atUyg17k/0zSIvjenHVvOTGY5b3YzjqoOYZMrQWxKJqPgv9wjoUPkSvYZO?=
 =?iso-8859-1?Q?+a5bP4gePjejM8gQAeymgIvLx3xh8yxasR9HE5h4H5rtOJHA3Qz2JTvCeQ?=
 =?iso-8859-1?Q?Q5KZX6wKQP7qP8Sc1qAl105Kc+wJUbLR++MMuCOL6lrFkUTC+FsArjqjh+?=
 =?iso-8859-1?Q?z9LtAg8nTjOluLQrIYbr5mUSdOWZL1Qx+VY7SjcWxaLjpimWNKpn+/X0Ez?=
 =?iso-8859-1?Q?hOeydb8Xz+M1ChrWpO6yAwY4ybH35g8PfPaxzGc6D0VMfRLFqk8GkpqfPD?=
 =?iso-8859-1?Q?eCQgYN+4hn/pjJ0VrLAVyR1LxFSTP2zYQBHmsaqFkNc6iz8OgmNiDd+EZr?=
 =?iso-8859-1?Q?SzaEBavL0cYlQN8144etK+Ll+q+4WX/ITROw/38uMH8eKhBLdO66mrJ5bI?=
 =?iso-8859-1?Q?cHhCNMS5GRaVfgAy5N3BwZLDdOuYLAg6iBchE3hp19DsCKdVyuS5YR+IcH?=
 =?iso-8859-1?Q?bSHrzlXEBJbJYGa3Qg225PWmbe7YkOjs5stFKat31llFEwlwuYSXJd+kvG?=
 =?iso-8859-1?Q?+61JFFg+XLsePyr7u82pjJECxYMK76DFBQMUrylRcp2/62j9aCVJb9dr/p?=
 =?iso-8859-1?Q?cxH+IE1dkphOHuOvGsBIt6PeThI1PqKQAXb/ytQNaVfCUouoh0ZgfhTADu?=
 =?iso-8859-1?Q?W5nIJ8nTYQJ06cQi4t/ZPoA23spOFXYjgZqlPDB4qPKj86mDWgcIPQij0s?=
 =?iso-8859-1?Q?6jyuTAQ/YQ+su0BJ0STTH24yQ+topjh8ppckWUUaCa8mvQWEKOAdI+qRJn?=
 =?iso-8859-1?Q?aVk7C/MsrSRxKhTbgBnlBlp7MIxy8+EZOxM3dsVw3S54oVqtVX2iD7y3tA?=
 =?iso-8859-1?Q?9YHCcVDBLbDwlb6F8Dg4FdyyfwSA+BFsb7QrEB0gqqIMrCR7VOhVcXYJX6?=
 =?iso-8859-1?Q?yeXx4F00ClJL7HPxk//73FmbRuDQ9Mllk8KSwmaSA9omSVx0j/he/s5agk?=
 =?iso-8859-1?Q?5N5bOu2zItJQJYCoZ+Hxs6AtxwlyW731x0gVYpuKrt1qMpGx0npQ19uly+?=
 =?iso-8859-1?Q?rT0u/dPWX63bHHC5sJa9aby5RHKlOcDhVIaal5aKjZHS+BVHSAJXAjxCdX?=
 =?iso-8859-1?Q?w3QBGPN/Le/v93e5BExSP9HBymMN0RqWx0z26LJkgsyuD+Vpw7HDM1g0p7?=
 =?iso-8859-1?Q?bKipO6OgcgRIxQPYuDbD5ZLXlZ3/E4WSMgrDDPsNjmyxljt/quXAAlTdol?=
 =?iso-8859-1?Q?gnwnrayYNct/R8mlaLnME+7yFuBqB8MlibeDIqGLzP6bE/tlUydK18Zev/?=
 =?iso-8859-1?Q?3wIkO3BUBeCeZYDJGounkPrNsQv5kHHVcxhMA2+3qruhoc7Nvd6TPyA1td?=
 =?iso-8859-1?Q?vGOpkrxSx6YpfzgjRV5VASX9wB7+iBSrhYS2dV30V8lh1Ofhr2kSdkdaaa?=
 =?iso-8859-1?Q?0cdsONaiysbm+ODEpszearX2hePtxs1OccG+wqxOZF8mU8AuEKnH2Iapve?=
 =?iso-8859-1?Q?5bzAlesCAkdH15fJQIcfXqQlNq6PKcu34p3pqSPYQm1XDveTPNARzhnRx5?=
 =?iso-8859-1?Q?ruX7XpCaOyx1PayvbwLQnIV9dcX64SbRPG1ey2mFCPkbI0F7V58hNp+A?=
 =?iso-8859-1?Q?=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GV2PR03MB9572.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ffba5b74-e953-4808-c61c-08ddff922e3a
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2025 19:55:46.2008
 (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: gKj6Hz4T0VCVWJ+APjhTAhv2pnyK9tPpURZDV9osPS1W13Y3Y7/ChhrVN1IdSwf1jUurV/lUJTEo14BHnqIoNi5vWmDYOGyaYvGzZmXOZ6E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB8774

The function 'gicv3_do_LPI()' violates MISRA C 2012 Rule 2.1, which states:
"A project shall not contain unreachable code." This is due to the use of
the 'BUG()' macro, which causes the function to never return.

This behavior is intentional and safe within the specific build configurati=
on
defined by 'CONFIG_HAS_ITS'. The 'BUG()' macro handles irrecoverable error
conditions where LPIs must not occur without an ITS enabled.

A SAF comment has been added to document the justification for this violati=
on,
stating that it is safe within the context of the Xen project.

Signed-off-by: Dmytro Prokopchuk 
---
Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2070455717
---
 docs/misra/safe.json                  | 8 ++++++++
 xen/arch/arm/include/asm/gic_v3_its.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 3584cb90c6..4c227c1e8b 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -124,6 +124,14 @@
         },
         {
             "id": "SAF-15-safe",
+            "analyser": {
+                "eclair": "MC3A2.R2.1"
+            },
+            "name": "Rule 2.1: Unreachable code",
+            "text": "It is safe because the BUG() macro is intentionally u=
sed to terminate execution when LPIs are enabled without an ITS."
+        },
+        {
+            "id": "SAF-16-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/a=
sm/gic_v3_its.h
index fc5a84892c..672dae7ac3 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -229,6 +229,7 @@ static inline unsigned int vgic_v3_its_count(const stru=
ct domain *d)
     return 0;
 }
=20
+/* SAF-15-safe */
 static inline void gicv3_do_LPI(unsigned int lpi)
 {
     /* We don't enable LPIs without an ITS. */
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 23:36:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 23:36:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133389.1471507 (Exim 4.92)
	(envelope-from )
	id 1v3NPX-0006Dq-Hy; Mon, 29 Sep 2025 23:36:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133389.1471507; Mon, 29 Sep 2025 23: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 1v3NPX-0006Dj-FL; Mon, 29 Sep 2025 23:36:03 +0000
Received: by outflank-mailman (input) for mailman id 1133389;
 Mon, 29 Sep 2025 23:36: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 1v3NPW-0006CC-Re
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 23:36:03 +0000
Received: from DM1PR04CU001.outbound.protection.outlook.com
 (mail-centralusazlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c111::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ddcd957-9d8d-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 01:35:59 +0200 (CEST)
Received: from BY5PR13CA0021.namprd13.prod.outlook.com (2603:10b6:a03:180::34)
 by IA1PR12MB8465.namprd12.prod.outlook.com (2603:10b6:208:457::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 23:35:56 +0000
Received: from SJ1PEPF00001CDF.namprd05.prod.outlook.com
 (2603:10b6:a03:180:cafe::9a) by BY5PR13CA0021.outlook.office365.com
 (2603:10b6:a03:180::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9182.13 via Frontend Transport; Mon,
 29 Sep 2025 23:35:57 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Mon, 29 Sep 2025 23:35:55 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Mon, 29 Sep
 2025 16:35:54 -0700
Received: from satlexmb07.amd.com (10.181.42.216) 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, 29 Sep
 2025 18:35:53 -0500
Received: from [172.18.5.186] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 29 Sep 2025 16:35:53 -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: 0ddcd957-9d8d-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=quGm0Up4sswlM/KECgcKMfgcxyHJyaShtbBEXM0PP3BFsWvPyDxIYuZCMtw8VDgJOeao6SHneaJmBi2o75lLhmPX/9FOA5tHR86FWeuwWf7ntIK93m3t2SaTbZcf5YLyWDxWa/+hAb2g7kqZ5ZR5DIGxehzxCa8nyAPuhmJFIRlUlAHwygu3ByuvEa3O60locukcghcxO54xbpzUMxHR0iPwnJoyurWCmqpV0ao9Qh9m63he15iw/rotM+xLrDMuqSlrV8aBqJSp+Lf6hpWKyMgnr3P+iaZqeI7NU/aajkMFuFF6S85b6RcHbXYswIs8jDgvWffw7SkdfgPw8PFMuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zkoHx2+S4uq+k0vWI6JD8rvHdJk0kuS9TDnXqa8RXu8=;
 b=KuXAutHiCzeOqa0KcDeyN7wVBGhc4E8E4ubJeVh6segvYD1K3cf490KvDeOkUZ493LHuOJwqVarH5yEfOUPounjoos9gPKus85h6jM0sMWO72bJA+I+s6E6wJ+fieGIaiB+onl2afwHcFFpFxFD16zxiWGUl7lrBRG7ijSmgy1eBv+5ON7zD+YzI9fmr8KxBwkqXqWBN4ugj0BAn1f2cp/biFitKAOP+l6UZWUUYmcuz0Vl7nPxupKr58H+w8/6+9zHYGnULTxbSmiS4AE+krqDJMbqkqeZvZe9FWhM/T6FZu5McK6L122bHA4gAnE09o7wPMdGDyX20K/4aGPodkw==
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=zkoHx2+S4uq+k0vWI6JD8rvHdJk0kuS9TDnXqa8RXu8=;
 b=JcLPFLSb4KO1rxwuqM60ucGtKlr1f9vj/YC7knErXSm/Th8XOckPwNetLg3wmOyGGw+Uy29Wn4sM37+PTrs/H3F3hL1fH8cUZetw5QBflpTQqzb5EwFN63pQXyXAhu62Ny9siaUMqpLfm8bXr5FRs/zXP+jqrnzmEhH+Srurb6c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: 
Date: Mon, 29 Sep 2025 19:35:53 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21 1/2] x86/AMD: avoid REP MOVSB for Zen3/4
To: Teddy Astie , Jan Beulich ,
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Oleksii Kurochko
	
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com>
 <6bcaa5b7-4e34-40c9-85e6-48a0a5869b86@suse.com>
 <485889ed-2820-4bb3-b450-88553dbb719e@vates.tech>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <485889ed-2820-4bb3-b450-88553dbb719e@vates.tech>
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: SJ1PEPF00001CDF:EE_|IA1PR12MB8465:EE_
X-MS-Office365-Filtering-Correlation-Id: 4b228253-cd85-423c-cfea-08ddffb0efa3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YTFuZ0ptT0REOVNCZ3N1MW1mMEdjdVNVeE9rejlIMXRvYjUxT00zN3QwelJF?=
 =?utf-8?B?U1d6MW9MY3JuSENTTGxHYTVZbXY0ZGg3OGtRaHloNXZtVGlxT0JDNXNMM3RT?=
 =?utf-8?B?bjQ2aEJnYmw1Y2J0VXc5V0dUdHVadzFYc1RhS1JxNmJ1V0dXWGp6alBlbVps?=
 =?utf-8?B?MTl3T3RHbEppSWk2NFM2dzdNRlhCbk1WRnJjMHJZTFk4SWNER2QrR0NKeEQw?=
 =?utf-8?B?K25IaDdYYVM2YzNENWxVaHZHU1lGdjgycjliajNSZVQ0YXdCY2d3ZThlNDAz?=
 =?utf-8?B?eHFvYUtQejQva0xaa3duczA2ZDNNYlROTUFXK011WVljN0hQdEkzZkJ4K1FD?=
 =?utf-8?B?RDdOeUEydm9GMklMUldKZi9KWHVZdmd4RzlPV21DWnlwYXB2dHRMbTE0LzJL?=
 =?utf-8?B?OTBXL3hwcndpdzR3WDREbW4rbUxuZlNoY0xjeXU4d1dFRG1hK3ZtRU9lZnMw?=
 =?utf-8?B?WjN0Z3h2ek5LdVkxcVFUNzJxbDJFUi9ST0F1NVhUYlBBbnNaeVR3VmJsSkhE?=
 =?utf-8?B?NzNUNnJnT0xvZVJiYThnSzh4aGpCSGZrS0J0amgxQjBwc2ZkWGJCTng4WmhM?=
 =?utf-8?B?ODB3MFJOSjRINGpNV2l6K1BUOXhuZlZzUUUrODBvdHVoVGV4b3I2Vm1peXMy?=
 =?utf-8?B?NGhtYmhGNnFUbHVyQWNWMzI3N01scitlNkVaV3RpcXI3K05YTU1qVkVqczBK?=
 =?utf-8?B?QmJmM2N6ZjhMYVMwL2JhSkt6Uk9mUG9aQ25CLzFtYU1tRlZRYnpkRTl4akMr?=
 =?utf-8?B?MCtxVVVRbFhlWE5Rc1l0WnZxcnFmbG4raHAwWHNidlhhTE10QnFwa2FGMzlP?=
 =?utf-8?B?VTNWclBRWHVKSmlDOXRyUXJTdzg1N3pjREN3UnFGNmQ4UWUxWFBobkJUeCtm?=
 =?utf-8?B?MTBhUVlnd1crYzZ4OE5rL3hESk1xenlBWDI5alJlS2tlVURvNzBrMEVZY0tZ?=
 =?utf-8?B?VFZhaTFCTXJHcHFQVlFISFJPOFhxNjFyeVo1enB5UnVlTklvR2ZZODJvbjRP?=
 =?utf-8?B?dDFDbnpqZWpzYXNESDRTdEo5QWJ6UzVzWVNjTDFQVU8vcmxVaCtnRFZFd1pM?=
 =?utf-8?B?K3NHWmFZMDJFYlNxQXNDVzlyOXVQWXJscmhqQWhyd3lmZUU3WUNzNWRlVit0?=
 =?utf-8?B?UGlhY2l3bDgrb2dlb2FZaHRxaTB2SlpiSWJ4SEk4SmQ0MFN0ckNWMHlXVWZC?=
 =?utf-8?B?SlI4Zm0yQWQzZWxzUjZINm9yampJRVI0eHh6V0xEQkx1L2NxZHo5a1Ryb0Ir?=
 =?utf-8?B?MytoWVJjNEFYM3hjV1JodXlQbk52NUJGVysxSmt4eXNzN2xkR0l0Ty9FdUZM?=
 =?utf-8?B?b1YweFJ2VTNtSkhublN3enA4NCt2cjFNQjBzenNOUGVOMXhTV01EMkszNWE1?=
 =?utf-8?B?UDY4RkJ1ME1MZVdYL0lvYjNLdFlZTTNkRHh5Slovd1h1VGx3Q2JqdmcvNFAv?=
 =?utf-8?B?eHAvb1RDZXZKWDZZTjNUS3l5c09mR3ByRWo1Y1BJcktFZmlkWW83YXJnMWRQ?=
 =?utf-8?B?OGpvN2l0cHhpdFhTSGZPbSt3S2x6QnI4Qk5DNWZJLys1bnRUbjllL3NncFNx?=
 =?utf-8?B?c2pKR2szczV5M0lPNE9CNSt6ME9zNzN6bXdzNjFiUnF4akR3K2x1enVXRnVH?=
 =?utf-8?B?cUFBa3RCUGtNTkgyVUhUMFlRZmJRYTd1VFhWaXlkTDREYkZKR21qdTVLZHJE?=
 =?utf-8?B?YVAvemhvM1RFL1lxclcvc1BLZlJ2dkJRV3hhL0RpZjJuUUhldEkxc281bWFx?=
 =?utf-8?B?TXZDNnZ0Tzk2VlRmYlNvRjhTRkwwQ3ErcjN5QzBtRVhHTWZoZlRwVkZ3Ykxl?=
 =?utf-8?B?UXJpTktEbmNOVU1lYVNHWUxCdkRhb0Y3c0x0VzJISXlSTVJrR2dvN0tvYVF3?=
 =?utf-8?B?U09ud01sTXhxeThmVnI3Vk5OWEJLNVFPUGRNU3NHZHRwZTRROEk0WVJNb1N2?=
 =?utf-8?B?Z2ZTWFlxU25RODdTNlQ4RVg4ZzVZM3l6bWJMZVBmbTVwZ21XdFZnNFYyaWhH?=
 =?utf-8?B?Ulc2T2lpT1VqekpiVTcraVRYbmI3MkxZK0ZOV3d3c05jZk1PNzFESDh0bndm?=
 =?utf-8?B?cXlpOEhZYkUrV3UvLzhPd0tUYUErMnM2OSsrNTBNdjl1QmNDVFVyWTNuS2pN?=
 =?utf-8?Q?5b1Q=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 29 Sep 2025 23:35:55.4951
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b228253-cd85-423c-cfea-08ddffb0efa3
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CDF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8465

On 2025-09-25 08:18, Teddy Astie wrote:
> Le 25/09/2025 à 12:48, Jan Beulich a écrit :
>> Along with Zen2 (which doesn't expose ERMS), both families reportedly
>> suffer from sub-optimal aliasing detection when deciding whether REP MOVSB
>> can actually be carried out the accelerated way. Therefore we want to
>> avoid its use in the common case (memset(), copy_page_hot()).
> 
> s/memset/memcpy (memset probably uses rep stosb which is not affected IIUC)
> 
>>
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Jan Beulich 

With Teddy's suggested change:

Reviewed-by: Jason Andryuk 

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Mon Sep 29 23:36:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Sep 2025 23:36:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133393.1471518 (Exim 4.92)
	(envelope-from )
	id 1v3NPs-0006iF-Pn; Mon, 29 Sep 2025 23:36:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133393.1471518; Mon, 29 Sep 2025 23: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 1v3NPs-0006i6-MW; Mon, 29 Sep 2025 23:36:24 +0000
Received: by outflank-mailman (input) for mailman id 1133393;
 Mon, 29 Sep 2025 23:36: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 1v3NPr-0006dW-Vn
 for xen-devel@lists.xenproject.org; Mon, 29 Sep 2025 23:36:24 +0000
Received: from CY7PR03CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170100005.outbound.protection.outlook.com
 [2a01:111:f403:c112::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b2c5f83-9d8d-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 01:36:22 +0200 (CEST)
Received: from PH7P221CA0026.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:32a::21)
 by IA1PR12MB7663.namprd12.prod.outlook.com (2603:10b6:208:424::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Mon, 29 Sep
 2025 23:36:15 +0000
Received: from SN1PEPF000397B2.namprd05.prod.outlook.com
 (2603:10b6:510:32a:cafe::a8) by PH7P221CA0026.outlook.office365.com
 (2603:10b6:510:32a::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9137.20 via Frontend Transport; Mon,
 29 Sep 2025 23:36:15 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SN1PEPF000397B2.mail.protection.outlook.com (10.167.248.56) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Mon, 29 Sep 2025 23:36:14 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Mon, 29 Sep
 2025 16:36:12 -0700
Received: from satlexmb07.amd.com (10.181.42.216) 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, 29 Sep
 2025 18:36:12 -0500
Received: from [172.18.5.186] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Mon, 29 Sep 2025 16:36:11 -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: 1b2c5f83-9d8d-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CHoxdNpi2lHkCSUPPhQHKBfEZgSz2rdnUsk8xZlequs+C9rTJ8yf9Xas6yRWToHZ9qyn+4+ptyyWmzWciwkpp90vo7Hq0DIpusf5QZ/UH8MDGYd8vT5pJNI9CKH9ZoPdZv+rFYUeQysc+yxf3eBOBgpUliNS6rrOj82sgVVa/45vOxhrtxPRpakvkbItVwpBjS9HklQwP31cCgKrxZnbIZbZAn6/E+2AbOp7KY3Jm+KMYpYip42Ob1nJY+fGX0M660XiI7cnqbQfGeU0hNNTQI2pfkU8OsfRmgylfBZbIrynMoFciKfATSkwSSQp3dgiE4vuyBbF82fOeFKslWep8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zrvGxInsz7lDVevik18YGd1tnHZPsAU+GrVZlq+lKU0=;
 b=uJoMkU/MVNXXTXoG4g76uixS1gLF/lT4NElndemAUAgLPUGpGsrJM+vQzwL/i2gsqVxIwQ4uvQVmUAGAB5srSf+ZM7VmYEGQbo6/HUFwuXUd51LAX3Qch0OBXWMww9SXmPHiYaqhrNjrQ6MPkvMNF39apWdzF8dzdasx3yTBUmcssGTmTxeex71q9aTpAgTS44VfDqCPCafqZ8t43Fn1S18JL/rGvllFwbjSx8BWB7pSwelzfEKZsvAhX65pYmKrh9woXTtMzpnCGgidbh1vT89H8zBUmHgA/PTiJf3x0ysRt4UGnFbzd4QiiWE9u+APZ3y+sydR1J+bRHFt0zR+Jg==
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=zrvGxInsz7lDVevik18YGd1tnHZPsAU+GrVZlq+lKU0=;
 b=yVwPXvEQvvYivEi/R5GTK8ebKebcHhX5/ZqXOmMrwFoiFS0Ji2UECwjrhv1tQtb6p8OJjlGAIdVk+UlTyB0+WrUq/LcZ3KzP7RrYKnlFjNz7w5E1USHyEeDgPvYKbYh4/W9dee7fM5OsKpdMZFPuXa0yZMA5fgLzUg40KvwTHuk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <1439ec29-4319-43d0-b4ff-0eb5bfe9405b@amd.com>
Date: Mon, 29 Sep 2025 19:36:10 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86: guard synthetic feature and bug enumerators
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com>
 <48dcc0e0-2772-49b9-9383-5bf69f922053@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <48dcc0e0-2772-49b9-9383-5bf69f922053@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: SN1PEPF000397B2:EE_|IA1PR12MB7663:EE_
X-MS-Office365-Filtering-Correlation-Id: 251839ad-2d34-483e-3e04-08ddffb0fb0e
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?bUV1Y0pleUNiZU9McGwwT1hKUncrZHZRT3VRTGE0eVNBcldnUHpPVzZ6bnMr?=
 =?utf-8?B?WE9iZCtlNjlZMEZWdGFPU3RDWENPZ1M1ajFZaG5PNzFFRU4zU0ZJNWNaL1VQ?=
 =?utf-8?B?aVJjV2gxSFVrelREdWV0UkJGTXBMc0h5NDR4eVVWSUZhdWY5S2p1VzVFYks0?=
 =?utf-8?B?dVFha09ibzB2N1VQdlJ6eWpwcU8yQmtzWlFXeUZXSUZJRlBKNmQ4eGtOaURu?=
 =?utf-8?B?MENwRGQwWG03SmtwYUpWTGlvWkFza2xSWm85NURWbmQycUhRdlU1RDVRcW5v?=
 =?utf-8?B?aXpKakFjWExmK1RBNE5zWU5NQmIrREFHSzlFRUJKci9KTWN0QldqMlpVQUJ6?=
 =?utf-8?B?SGZ4cmhTeEd6RHRUSFRIUENMc2d3NW5zRmhqVnhtZHVYTzM2WEZ3U1l5YktK?=
 =?utf-8?B?SDRDR3huWG1lMUMvSy9FSlVnYUVlbDZaemswcDdJenREVkxibmNaZ1hsb2py?=
 =?utf-8?B?M1pqUVZkcFFYQUpZalprZXUxUGRxdnZkUlRoUTVnM3JaYmxLL0lzZUpCNXlu?=
 =?utf-8?B?SzRMSURvT29Gd0ExM25nSWZvYUd6ckNsakMyR2ZMczhpblVjbnJqeWFZNEtD?=
 =?utf-8?B?Mkt6MHl1S0gxN3BMU3ExNjdPQjZ3aGRYQnBmYWFqakdYVVZMbkk5UUdiaWRy?=
 =?utf-8?B?cFdjb0xNL2Q0UzJlSDJ2WktRQ1l5Q2x6aUY3bkxRRnVwOVJPTXpLSlpFSFhP?=
 =?utf-8?B?THM3Z01VVFFwcjNRNEtCcDhacnVYN0psSExZamg5UnZ3T0VUWHdmTzNTZnhV?=
 =?utf-8?B?M295Z1REWjFxVHNmNUlJVlFYMjNCb3pSYTBmb0dBRFl5alNyMUtQbmFQa3FQ?=
 =?utf-8?B?Sk44N2FBczllazZuSHE5NEdsM1BROTF6ai9BZnI4QmlNUmRHOGFUczhZU3VX?=
 =?utf-8?B?VXo4OFVseWE2UFJjdU1zUUxqWVZickJEN3FsbkZQck03Mmg3cEZVcnBwQ2Mr?=
 =?utf-8?B?ejVFdS9oSUswa1FDUDNSaUFza3g0OEJoaSsxTVZXdVM2ajVTc0FJN24rMDZm?=
 =?utf-8?B?cGI5NEkydTNpb0JuakVjbG5zMUx5ck1Iekp2YTB2b0h0aWRDenA3WGFscnFX?=
 =?utf-8?B?bnl5ZVNyOEJML2lhSGhMRWVsWlFMZXNXQWJZVkJXYnpCeCthalRJWWpXaHB6?=
 =?utf-8?B?V0lreG9NZXBLUFpNNXJJd1Nya2s5bnB6ckt3L3dXTkh6T1dlSzNjV0NrN3VT?=
 =?utf-8?B?dVZucTRzNDB1eWMzVllPQUhFWlN6VU5mK0VVbmtQdDJUa3NHQWl5dDZtRDlF?=
 =?utf-8?B?U0dxVFNHeU9pdWN0MG9lQmZYY1k3Ym9KYU5KQ2RjOXJ1dEFiUkhwK1YrR01N?=
 =?utf-8?B?Y1BsRkRNMEsya1o4VTV5ek1VOENNdUppRXRodHhFNjVHUmZsVTdBci9mQ3RM?=
 =?utf-8?B?cG05NlZrbTh6MThyZGZhaEhCeTdCbnRiZkVQb0c0RnBSdlJvbXYybkxITjdL?=
 =?utf-8?B?eEtKMzRDb0x3RSs1SWs1M2lQeFFmV2FYODJjQkZhUVZGeWwwWmRDMDZ5V3d3?=
 =?utf-8?B?Y1Y4T1d2N2NnWnlsTG9CbDF2elF4N1lvMmYxa0Q4M3gyRkZrQlA4eVFiZ1pp?=
 =?utf-8?B?WUNHZnRIOTRReWdqT3dFYXlrcGFKdUV1T0pqekxvaytjZGg4TXh1NGtPTE9p?=
 =?utf-8?B?Q2xubjRoMmJnVyszSXVTaWlUbjdianQxQzc3dTFuWFpCNEUxdDdkbjNLaVlj?=
 =?utf-8?B?dVE5ZjBpVWNkd2lOanl4NUJkZlNxUUNxWkkxbzQwcFV0NWs1aWhQcTRUYng0?=
 =?utf-8?B?U3RwY08wRmJpcEF0Yi9LbkVwNzJubnV2MW4yZlZPamg5aE4zVFMxUW1Id05i?=
 =?utf-8?B?UVh2OWhFVmhOdXNXMUViaUV4VkQ2b2wyb1hnR2g3SFNzTnk0VDRjbmd1eEdM?=
 =?utf-8?B?SiswaXFSOGJvMVh0QTVBckwvYjdkbFEwaGFXcldDUm9XRnhFdVV2aFQ4YUdZ?=
 =?utf-8?B?c1VYVG8rVlZGOFRQTjRwTnAyeGhwZzM2RTIvbTZIZHhsczFwMTVBQ3E4OVFQ?=
 =?utf-8?B?Nmd6Njc4aWFDaW5nbGlRMGlvbElSMStYbWpZN0xoWHBENFBURTFQNnFZc2sy?=
 =?utf-8?B?RU84NGN3bndJV3RMcXhyZ3lucGpURVQ3RHpxK2JFMFowSjJ3Z2ZwV0gzUXlY?=
 =?utf-8?Q?O7HE=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb08.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: 29 Sep 2025 23:36:14.7125
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 251839ad-2d34-483e-3e04-08ddffb0fb0e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000397B2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7663

On 2025-09-25 06:48, Jan Beulich wrote:
> While adding new enumerators one may overlook the (rare) need to bump
> X86_NR_{SYNTH,BUG}. Guard against that happening by adding respective
> checking. The use of BUILD_BUG_ON_ZERO(), however, entails a number of
> other changes, as the expansion may not appear in the assembly produced.
> Furthermore inputs to file-scope asm() are only supported in gcc15 (or
> newer).
> 
> No difference in generated code (debug info, however, grows quite a bit).
> 
> An implication from the changes is that users of the alternatives patching
> macros may not use unnamed asm() input operands anymore, as the "injected"
> new operands would break numbering expectations.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/include/asm/alternative.h
> +++ b/xen/arch/x86/include/asm/alternative.h
> @@ -70,12 +70,12 @@ extern void alternative_instructions(voi
>                       alt_repl_len(n2)) "-" alt_orig_len)
>   
>   #define ALTINSTR_ENTRY(feature, num)                                    \
> -        " .if (" STR(feature & ~ALT_FLAG_NOT) ") >= " STR(NCAPINTS * 32) "\n" \
> +        " .if (%c" #feature " & " STR(~ALT_FLAG_NOT) ") >= " STR(NCAPINTS * 32) "\n" \
>           " .error \"alternative feature outside of featureset range\"\n" \
>           " .endif\n"                                                     \
>           " .long .LXEN%=_orig_s - .\n"             /* label           */ \
>           " .long " alt_repl_s(num)" - .\n"         /* new instruction */ \
> -        " .word " STR(feature) "\n"               /* feature bit     */ \
> +        " .word %c" #feature "\n"                 /* feature bit     */ \
>           " .byte " alt_orig_len "\n"               /* source len      */ \
>           " .byte " alt_repl_len(num) "\n"          /* replacement len */ \
>           " .byte " alt_pad_len "\n"                /* padding len     */ \
> @@ -127,14 +127,14 @@ extern void alternative_instructions(voi
>    */
>   #define alternative(oldinstr, newinstr, feature)                        \
>       asm_inline volatile (                                               \
> -        ALTERNATIVE(oldinstr, newinstr, feature)                        \
> -        ::: "memory" )
> +        ALTERNATIVE(oldinstr, newinstr, [feat])                         \
> +        :: [feat] "i" (feature) : "memory" )
>   
>   #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
>       asm_inline volatile (                                               \
> -        ALTERNATIVE_2(oldinstr, newinstr1, feature1,                    \
> -                      newinstr2, feature2)                              \
> -        ::: "memory" )
> +        ALTERNATIVE_2(oldinstr, newinstr1, [feat1],                     \
> +                      newinstr2, [feat2])                               \
> +        ::  [feat1] "i" (feature1), [feat2] "i" (feature2) : "memory" )
>   
>   /*
>    * Alternative inline assembly with input.
> @@ -148,14 +148,14 @@ extern void alternative_instructions(voi
>    */
>   #define alternative_input(oldinstr, newinstr, feature, input...)        \
>       asm_inline volatile (                                               \
> -        ALTERNATIVE(oldinstr, newinstr, feature)                        \
> -        :: input )
> +        ALTERNATIVE(oldinstr, newinstr, [feat])                         \
> +        :: [feat] "i" (feature), ## input  )
>   
>   /* Like alternative_input, but with a single output argument */
>   #define alternative_io(oldinstr, newinstr, feature, output, input...)   \
>       asm_inline volatile (                                               \
> -        ALTERNATIVE(oldinstr, newinstr, feature)                        \
> -        : output : input )
> +        ALTERNATIVE(oldinstr, newinstr, [feat])                         \
> +        : output : [feat] "i" (feature), ## input )
>   
>   /*
>    * This is similar to alternative_io. But it has two features and
> @@ -168,9 +168,9 @@ extern void alternative_instructions(voi
>   #define alternative_io_2(oldinstr, newinstr1, feature1, newinstr2,      \
>                            feature2, output, input...)                    \
>       asm_inline volatile (                                               \
> -        ALTERNATIVE_2(oldinstr, newinstr1, feature1,                    \
> -                      newinstr2, feature2)                              \
> -        : output : input )
> +        ALTERNATIVE_2(oldinstr, newinstr1, [feat1],                     \
> +                      newinstr2, [feat2])                               \
> +        : output : [feat1] "i" (feature1), [feat2] "i" (feature2), ## input )
>   
>   /* Use this macro(s) if you need more than one output parameter. */
>   #define ASM_OUTPUT2(a...) a
> --- a/xen/arch/x86/include/asm/cpufeatures.h
> +++ b/xen/arch/x86/include/asm/cpufeatures.h
> @@ -6,9 +6,16 @@
>   /* Number of capability words covered by the featureset words. */
>   #define FSCAPINTS FEATURESET_NR_ENTRIES
>   
> +#if !defined(__ASSEMBLY__) && __GNUC__ >= 15
> +#include 
> +#define X86_CHECK_FEAT_NR(x, n) BUILD_BUG_ON_ZERO((x) / 32 >= X86_NR_ ## n)
> +#else
> +#define X86_CHECK_FEAT_NR(x, n) 0
> +#endif
> +
>   /* Synthetic words follow the featureset words. */
>   #define X86_NR_SYNTH 2
> -#define X86_SYNTH(x) (FSCAPINTS * 32 + (x))
> +#define X86_SYNTH(x) (FSCAPINTS * 32 + (x) + X86_CHECK_FEAT_NR(x, SYNTH))
>   
>   /* Synthetic features */
>   XEN_CPUFEATURE(CONSTANT_TSC,      X86_SYNTH( 0)) /* TSC ticks at a constant rate */
> @@ -47,7 +54,8 @@ XEN_CPUFEATURE(XEN_REP_MOVSB,     X86_SY
>   
>   /* Bug words follow the synthetic words. */
>   #define X86_NR_BUG 1
> -#define X86_BUG(x) ((FSCAPINTS + X86_NR_SYNTH) * 32 + (x))
> +#define X86_BUG(x) ((FSCAPINTS + X86_NR_SYNTH) * 32 + (x) + \
> +                    X86_CHECK_FEAT_NR(x, BUG))
>   
>   #define X86_BUG_FPU_PTRS          X86_BUG( 0) /* (F)X{SAVE,RSTOR} doesn't save/restore FOP/FIP/FDP. */
>   #define X86_BUG_NULL_SEG          X86_BUG( 1) /* NULL-ing a selector preserves the base and limit. */
> --- a/xen/arch/x86/include/asm/cpufeatureset.h
> +++ b/xen/arch/x86/include/asm/cpufeatureset.h
> @@ -12,8 +12,13 @@ enum {
>   };
>   #undef XEN_CPUFEATURE
>   
> +#if __GNUC__ >= 15
> +#define XEN_CPUFEATURE(name, value) asm (".equ X86_FEATURE_" #name ", %c0" \
> +                                         :: "i" (X86_FEATURE_##name));
> +#else
>   #define XEN_CPUFEATURE(name, value) asm (".equ X86_FEATURE_" #name ", " \
>                                            __stringify(value));
> +#endif
>   #include 
>   #include 
>   
> --- a/xen/arch/x86/include/asm/pdx.h
> +++ b/xen/arch/x86/include/asm/pdx.h
> @@ -13,9 +13,9 @@
>       asm_inline goto (                               \
>           ALTERNATIVE(                                \
>               "",                                     \
> -            "jmp %l0",                              \
> -            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
> -        : : : : label )
> +            "jmp %l1",                              \
> +            [feat])                                 \
> +        : : [feat] "i" (ALT_NOT(X86_FEATURE_PDX_COMPRESSION)) : : label )
>   
>   static inline unsigned long pfn_to_pdx(unsigned long pfn)
>   {
> --- a/xen/arch/x86/include/asm/spec_ctrl.h
> +++ b/xen/arch/x86/include/asm/spec_ctrl.h
> @@ -73,7 +73,7 @@ static always_inline void spec_ctrl_new_
>   
>       /* (ab)use alternative_input() to specify clobbers. */
>       alternative_input("", "DO_OVERWRITE_RSB xu=%=", X86_BUG_IBPB_NO_RET,
> -                      : "rax", "rcx");
> +                      "i" (0) : "rax", "rcx");

"i" (0) is to work around the trailing comma in alternative_input() and 
does nothing?

Thanks,
Jason

>   }
>   
>   extern int8_t opt_ibpb_ctxt_switch;
> @@ -163,7 +163,7 @@ static always_inline void __spec_ctrl_en
>        * (ab)use alternative_input() to specify clobbers.
>        */
>       alternative_input("", "DO_OVERWRITE_RSB xu=%=", X86_FEATURE_SC_RSB_IDLE,
> -                      : "rax", "rcx");
> +                      "i" (0) : "rax", "rcx");
>   }
>   
>   /* WARNING! `ret`, `call *`, `jmp *` not safe after this call. */
> --- a/xen/arch/x86/include/asm/tsc.h
> +++ b/xen/arch/x86/include/asm/tsc.h
> @@ -29,8 +29,7 @@ static inline uint64_t rdtsc_ordered(voi
>       alternative_io_2("lfence; rdtsc",
>                        "mfence; rdtsc", X86_FEATURE_MFENCE_RDTSC,
>                        "rdtscp",        X86_FEATURE_RDTSCP,
> -                     ASM_OUTPUT2("=a" (low), "=d" (high), "=c" (aux)),
> -                     /* no inputs */);
> +                     ASM_OUTPUT2("=a" (low), "=d" (high), "=c" (aux)));
>   
>       return (high << 32) | low;
>   }
> 
> 



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 02:55:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 02:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133415.1471528 (Exim 4.92)
	(envelope-from )
	id 1v3QW8-0005hd-EN; Tue, 30 Sep 2025 02:55:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133415.1471528; Tue, 30 Sep 2025 02: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 1v3QW8-0005hV-9d; Tue, 30 Sep 2025 02:55:04 +0000
Received: by outflank-mailman (input) for mailman id 1133415;
 Tue, 30 Sep 2025 02: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 1v3QW6-0005hL-UE
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 02:55:02 +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 da318902-9da8-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 04:54:59 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 3A35260357;
 Tue, 30 Sep 2025 02:54:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B33DC4CEF4;
 Tue, 30 Sep 2025 02:54:58 +0000 (UTC)
Received: from [10.30.226.235] (localhost [IPv6:::1])
 by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id
 ADECF39D0C1A; Tue, 30 Sep 2025 02: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: da318902-9da8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1759200898;
	bh=aBszSgASonpZWC82V9x0owSaL1kG0Jo/J08UI3a/8Yo=;
	h=Subject:From:In-Reply-To:References:Date:To:Cc:From;
	b=WBL7Q9yjMnLmk7lBK8dCo+VC97L0GqRx9jBwre5b8Oub9LF9c1YaS1B/UsDttZhdW
	 dMAp0qdhRdX4gsDeyD9Nx+EiVHzlit/+IHCkpgteNIEanOhSELgA7LhNBEhQrumV/U
	 31Qb6pKpDFL8xxyb6z6s03FavvFLbdHsfP9xMoJoajxFXnnpW2Xe3accUv+t1aHU59
	 NklxQmjdrKIRwvyMX74/uAWEZTnM9xKudY0AQwCn1jcx/ou51bxtl2blMGrYpKeyMn
	 7393WzAlE3FFXA6o5ds91FVE1s66KQq3ATWg7Ma0wH0fLvMQBfmsinEWKKqLVWF3BH
	 zxrg/GH3Vmw4w==
Subject: Re: [GIT PULL] xen: branch for v6.18-rc1
From: pr-tracker-bot@kernel.org
In-Reply-To: <20250926113107.22638-1-jgross@suse.com>
References: <20250926113107.22638-1-jgross@suse.com>
X-PR-Tracked-List-Id: 
X-PR-Tracked-Message-Id: <20250926113107.22638-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.18-rc1-tag
X-PR-Tracked-Commit-Id: 9d52b0b41be5b932a0a929c10038f1bb04af4ca5
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: 30d4efb2f5a515a60fe6b0ca85362cbebea21e2f
Message-Id: <175920089129.1805104.16547639794605921099.pr-tracker-bot@kernel.org>
Date: Tue, 30 Sep 2025 02:54:51 +0000
To: Juergen Gross 
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org

The pull request you sent on Fri, 26 Sep 2025 13:31:05 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.18-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/30d4efb2f5a515a60fe6b0ca85362cbebea21e2f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133434.1471558 (Exim 4.92)
	(envelope-from )
	id 1v3RkF-0007Ac-Eh; Tue, 30 Sep 2025 04:13:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133434.1471558; Tue, 30 Sep 2025 04: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 1v3RkF-0007AV-B8; Tue, 30 Sep 2025 04:13:43 +0000
Received: by outflank-mailman (input) for mailman id 1133434;
 Tue, 30 Sep 2025 04:13: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 1v3RkD-0006tq-W8
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:13:41 +0000
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com
 [2a00:1450:4864:20::343])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d9164c8e-9db3-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:13:41 +0200 (CEST)
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-45b4d89217aso34332435e9.2
 for ; Mon, 29 Sep 2025 21:13:41 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f3dbcfsm38006405e9.3.2025.09.29.21.13.38
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:13: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: d9164c8e-9db3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205621; x=1759810421; darn=lists.xenproject.org;
        h=content-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=tJyVnOWNCddCGl/+ypfUNoAsZWxoJ+Iw1ZeRnG+UY2M=;
        b=ACXfFaboSEXrvFZAkO+AUOw52QTW3XvN0agAckRm4Lt4kX6TxN4ZE/Hp6vmLTW32ur
         hWaQbQuxIZ7TFkOlfHAXdzlAKf5sma9x3dkdUaqvtOkSP6eqenxJmDiF0lUrCtDaS5Yi
         EJM4k6IEJNnxLpWhlQ+mA2DPZYIj1erKD84AbmTS9x2EFnIjkI+vpanfLF+P+pnPKdKp
         /J7hwuPCMd8+83DiS9Jq1cfkPJB87oH6+Pf2m7eduiYOJwziRdSQOgN8sYJ9KNUyZ79y
         B7arW6OC5zYANZq0ygvXoKl4tB6QHJDwMnZ8DcV7LRlX7urNeMaOKw6zl3/xQdYiIaZI
         cL5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205621; x=1759810421;
        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=tJyVnOWNCddCGl/+ypfUNoAsZWxoJ+Iw1ZeRnG+UY2M=;
        b=THN2Wz+l2fDwVvyHmla3zZF1mN9tz6aphs9hGtT2kllgXnXIXlsHrdqs7m0aKPXG/4
         ofSvPyKJJ6PFJZT/YFdSC50lOjYNfBLHz4Da7foWSPJE2vFaO9esSEUq9g7jvkCHyiQk
         u5CN7ysSbMSiOdsyxnSz6vFlPIc3XanwJsD050tAZgS7j4BQS81porIMUEXRVSx/h6Ov
         sHIj4tqs9AFDUADsGXIcwq+UfzTMbsQ0GO4btBzsHzKFdo6zZUOPq5cJwTx4+NKRWwtH
         pVOV7I+ygO4tTywrp0v/kb2NcD1hSa5FA3U/sjcfZ+0MLXG9X1RddNWhvvvqgQ4ZhyKP
         QAvg==
X-Forwarded-Encrypted: i=1; AJvYcCUBSE2MQOh7Y0PYIX9N52wCF9+KYohl1cY/SupqrEl2kPKsoCbRj15EdreUswWDAewXFgmdR+ir/Sk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKftsxll2uZZWJ72fNTEK2X3hWrkhy/rWCjN6ECVQTJNQzAXON
	AS1ZYdDzs/3UKCUIF3b6R/xEHPtdk/dbrOPiHbhsy+AT3MP4wK+vAJ+5LvEEBUTCOxQ=
X-Gm-Gg: ASbGncvb2vwDVDritsdLrBJE+N8uzWKTOyn6sN6nOMplrLZ+CWPzDa0OzJC91hDV/AY
	5w8MWgqTSDL7F8yWcKMga3f49WNgfPpZHwVknZenH3UTEu0D93GSKDanPtTtBGfJE1laGYOyMH8
	0K851Jg6ol04XbJKmPudLbMVBcMDgE0ACLo6NeA0WJahwaB7aUrbdUNEViEISh2aBjO5rLGaMD7
	YaNSzVFBPlhAacNXz4Vw53Zua6ZgQWZWAd/rQY8sxDypg6MHc3KGDE80D3uC5R0HRYOYDLHpapt
	I559l5pO0rAugmotW7X3pvPeG25VD+9YIJNRKJYq/AQD3g86tONfnOyXB1ZpPdildwgLW0yUxLl
	sqHTAgu8ef72S89zuwLTLnsDwVfBxYd9TPtYx3+i/W3miQs5umTkCWVGNeFIjo7Q7fkIaQ4tjYX
	nNSpMo85HroXBd4Y7iJzR0
X-Google-Smtp-Source: AGHT+IEBLGmPjHaV6MityTIXBSpNltcXVYjuhb00aWpIbO25PxYLKS/w9T+ltaJf/K1UbWKlm67UDQ==
X-Received: by 2002:a05:600c:4ec6:b0:46c:7097:6363 with SMTP id 5b1f17b1804b1-46e329b441cmr166612445e9.13.1759205620914;
        Mon, 29 Sep 2025 21:13:40 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 02/17] system/memory: Better describe @plen argument of flatview_translate()
Date: Tue, 30 Sep 2025 06:13:10 +0200
Message-ID: <20250930041326.6448-3-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

flatview_translate()'s @plen argument is output-only and can be NULL.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/system/memory.h | 5 +++--
 system/physmem.c        | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/system/memory.h b/include/system/memory.h
index aa85fc27a10..3e5bf3ef05e 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -2992,13 +2992,14 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
  * @addr: address within that address space
  * @xlat: pointer to address within the returned memory region section's
  * #MemoryRegion.
- * @len: pointer to length
+ * @plen_out: pointer to valid read/write length of the translated address.
+ *            It can be @NULL when we don't care about it.
  * @is_write: indicates the transfer direction
  * @attrs: memory attributes
  */
 MemoryRegion *flatview_translate(FlatView *fv,
                                  hwaddr addr, hwaddr *xlat,
-                                 hwaddr *len, bool is_write,
+                                 hwaddr *plen_out, bool is_write,
                                  MemTxAttrs attrs);
 
 static inline MemoryRegion *address_space_translate(AddressSpace *as,
diff --git a/system/physmem.c b/system/physmem.c
index 8a8be3a80e2..2d1697fce4c 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -566,7 +566,7 @@ iotlb_fail:
 
 /* Called from RCU critical section */
 MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
-                                 hwaddr *plen, bool is_write,
+                                 hwaddr *plen_out, bool is_write,
                                  MemTxAttrs attrs)
 {
     MemoryRegion *mr;
@@ -574,13 +574,13 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
     AddressSpace *as = NULL;
 
     /* This can be MMIO, so setup MMIO bit. */
-    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
+    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
                                     is_write, true, &as, attrs);
     mr = section.mr;
 
     if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) {
         hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr;
-        *plen = MIN(page, *plen);
+        *plen_out = MIN(page, *plen_out);
     }
 
     return mr;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133432.1471538 (Exim 4.92)
	(envelope-from )
	id 1v3Rk6-0006gS-0i; Tue, 30 Sep 2025 04:13:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133432.1471538; Tue, 30 Sep 2025 04:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rk5-0006gL-Ta; Tue, 30 Sep 2025 04:13:33 +0000
Received: by outflank-mailman (input) for mailman id 1133432;
 Tue, 30 Sep 2025 04: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 1v3Rk4-0006gD-VF
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:13:33 +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 d1ce8993-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:13:29 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-46e2826d5c6so40782205e9.1
 for ; Mon, 29 Sep 2025 21:13:29 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e5707c1e7sm37549775e9.21.2025.09.29.21.13.27
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:13: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: d1ce8993-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205609; x=1759810409; 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=LfIkfL6gj/tPGL1om2pz6zaZ+tStdg+utOiTzyFtZrQ=;
        b=K7jpT3DjTJD3s99tOHTZPSGFj6ANryua6Ti9qTDQow7a8PcopqsJl3vDO5Jnr0W6Iv
         iqkZsh1cd6ebDtTP8C7siVY3tEP+bzhOowMuXXbcycijdr5GOBqHuJcloxZq0zLLZc2W
         qkMe74XCf3vrMUFBWvlSVvJW7bhhabdiEiIJcsxl3vJf6kGDfwM/N4+PChv0mHSh48s3
         bsDAMJCkmHqF84HmSKzYEMg7078X+E+FP0uLMS1Y/tqWWmqOcOMUyKXfCYP9daR4yPhi
         185wGSz6+0CGEAoR8+p9QQWpVGOwkK58y9TS0iKjAR0oJyyAeoXcFLVjcF1mMeCsA7uv
         uizQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205609; x=1759810409;
        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=LfIkfL6gj/tPGL1om2pz6zaZ+tStdg+utOiTzyFtZrQ=;
        b=lhSPxa3oS/v6sE/QGCNiLPKGNyYrkhQElz9inNceqUAtpImRRnoTgeLCiQcKLyv2Vg
         BUI1Toome8SEJt0rgt5L768lHZXIoV+O0UHns/+NT2zIE/EsOp+AndCPJBPoXA0yDJX+
         S95vS9+0s8JAPbFLIQFpam+NCokmGJS11Q3F8SWJttR/GoQ37/KVEnbJ5xTkmd3cra1c
         9ZaJiJSKb8OZ5rPFn2xbh7rjjr6+yrRlSbVKOrn1sXJBPBMNdREnFcCBNzurV606D3Wj
         di1QZzNF3CIOWtxfMJrOltKQRc60lEOMcZqKRhZEtbaeLrPHePpiaNYL7ToWlmsdoDDF
         6bwA==
X-Forwarded-Encrypted: i=1; AJvYcCVv1U3MA2ZlsUvLtkdrNesZDFiCpFu01Bsjo6kQLsTLNcp6aRiWSW2ZWsRwxBz7wHTRMArIo5rLIRg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwX/Pe2MtcB3HYyRqKQjROCnvfPBzCDJqoMlbeE8cvT4XNmeB56
	+zsyd723+ESg7vCkBcKv6XdLsCFuS3CO5agJqhv1zWyQZmIuoaZ3958Ic4RpbVnKEg8=
X-Gm-Gg: ASbGncvORB92v+H+8MUoU+JgfeWIE+P7j6LIrVaks0lxGqkif9j58qapun0oHRLnySl
	GxPc8QC+wT/0gfacbURlBKfC030aDQLcK9mx0k0lrM2TbwTbDxzMH7dNCysx9pBuO505nz+5d9i
	mb0xyYV/Jyfv+HTzaCK6JnaUTRzI55geOIvG0sS9yf5AkYX2qHJD5OmJ4i8zd8KQu3bmMk3zQC9
	lNs0Kp3rLEgdbUuTdc6z57pXgUo3clkArDZ2+1kLJcHskME9Qx5gIZLKTacFk+BIrwUwEE26Uag
	dz3qojMIPMXlFApAwTwV9e2gccCJgrLSYc8KvZhqdIR3szc1ttFjlhffU78RyjFIUGyby8HNR8y
	0spRW/olRmZHpRCubkXzxnx57AlCDmDSkUAoMFKqwEo2305JhVe4HjShOI+UNQp7nYOk/VrQCE4
	wXNVWKxM+Fa0oQuezIGhPU
X-Google-Smtp-Source: AGHT+IGJB5LpSuDvwMbeYMOlRXcgfKRnczQzMLqCO1F91RV/zBDeRDsDtJpaavO640EWA/h8XFRCSw==
X-Received: by 2002:a05:600c:608d:b0:46e:4f25:aace with SMTP id 5b1f17b1804b1-46e510d28edmr61572215e9.6.1759205608862;
        Mon, 29 Sep 2025 21:13:28 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 00/17] system/physmem: Remove cpu_physical_memory _is_io() and _rw()
Date: Tue, 30 Sep 2025 06:13:08 +0200
Message-ID: <20250930041326.6448-1-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Since v1:
- Removed extra 'len' arg in address_space_is_io (rth)

---

The cpu_physical_memory API is legacy (see commit b7ecba0f6f6):

  ``cpu_physical_memory_*``
  ~~~~~~~~~~~~~~~~~~~~~~~~~

  These are convenience functions which are identical to
  ``address_space_*`` but operate specifically on the system address space,
  always pass a ``MEMTXATTRS_UNSPECIFIED`` set of memory attributes and
  ignore whether the memory transaction succeeded or failed.
  For new code they are better avoided:
  ...

This series removes:
  - cpu_physical_memory_is_io()
  - cpu_physical_memory_rw()
and start converting some
  - cpu_physical_memory_map()
  - cpu_physical_memory_unmap()
calls.

Based-on: <20250922192940.2908002-1-richard.henderson@linaro.org>
          "system/memory: Split address_space_write_rom_internal"

Philippe Mathieu-Daudé (17):
  docs/devel/loads-stores: Stop mentioning
    cpu_physical_memory_write_rom()
  system/memory: Better describe @plen argument of flatview_translate()
  system/memory: Factor address_space_is_io() out
  target/i386/arch_memory_mapping: Use address_space_memory_is_io()
  hw/s390x/sclp: Use address_space_memory_is_io() in sclp_service_call()
  system/physmem: Remove cpu_physical_memory_is_io()
  system/physmem: Pass address space argument to
    cpu_flush_icache_range()
  hw/s390x/sclp: Replace [cpu_physical_memory -> address_space]_r/w()
  target/s390x/mmu: Replace [cpu_physical_memory -> address_space]_rw()
  target/i386/whpx: Replace legacy cpu_physical_memory_rw() call
  target/i386/kvm: Replace legacy cpu_physical_memory_rw() call
  target/i386/nvmm: Inline cpu_physical_memory_rw() in nvmm_mem_callback
  hw/xen/hvm: Inline cpu_physical_memory_rw() in rw_phys_req_item()
  system/physmem: Un-inline cpu_physical_memory_read/write()
  system/physmem: Inline cpu_physical_memory_rw() and remove it
  hw/virtio/vhost: Replace legacy cpu_physical_memory_*map() calls
  hw/virtio/virtio: Replace legacy cpu_physical_memory_map() call

 docs/devel/loads-stores.rst            |  6 ++--
 scripts/coccinelle/exec_rw_const.cocci | 22 ------------
 include/exec/cpu-common.h              | 18 ++--------
 include/system/memory.h                | 16 +++++++--
 hw/core/loader.c                       |  2 +-
 hw/s390x/sclp.c                        | 14 +++++---
 hw/virtio/vhost.c                      |  6 ++--
 hw/virtio/virtio.c                     | 10 +++---
 hw/xen/xen-hvm-common.c                |  8 +++--
 system/physmem.c                       | 48 ++++++++++++++------------
 target/i386/arch_memory_mapping.c      | 10 +++---
 target/i386/kvm/xen-emu.c              |  4 ++-
 target/i386/nvmm/nvmm-all.c            |  5 ++-
 target/i386/whpx/whpx-all.c            |  7 ++--
 target/s390x/mmu_helper.c              |  6 ++--
 15 files changed, 89 insertions(+), 93 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133433.1471547 (Exim 4.92)
	(envelope-from )
	id 1v3RkA-0006uW-6W; Tue, 30 Sep 2025 04:13:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133433.1471547; Tue, 30 Sep 2025 04:13: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 1v3RkA-0006uP-3L; Tue, 30 Sep 2025 04:13:38 +0000
Received: by outflank-mailman (input) for mailman id 1133433;
 Tue, 30 Sep 2025 04:13: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 1v3Rk8-0006tq-Qp
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:13:36 +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 d579bb90-9db3-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:13:35 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-46e5b7dfeb0so907105e9.1
 for ; Mon, 29 Sep 2025 21:13:35 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb89065b5sm20717307f8f.17.2025.09.29.21.13.32
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:13: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: d579bb90-9db3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205615; x=1759810415; darn=lists.xenproject.org;
        h=content-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=I6r7ywVdtgg6puBO7GNeh9QBn+ePwbPPQeAATrRMKjs=;
        b=fVZPoyatAZE+MTsGz82hLPW8a0Gx8jGqMC9oMt118ArZSHvZhmHAbNgx4uGYiGyYZP
         C+o2JDUTR2Aly/f8G8YtihJs2MQGhvxg7bSAbElIDweo3nx6VUPl9Qgz7J5bopEebFEx
         gcNtZZ+fbdh2dLEiLyqrCZZZ0IEx3HKsjny9DeFPqzfh7bRbFY37vnXJtQmA6Vp1wOyB
         Ct+Wke9VSFlBwb5w2aVN59fVs5afq6oPpeNHlP6AmAvw6s42e5uzYumK1hPND6fj7mxy
         daIfAUlfbAdh4e1zkREAB0MykFWbwKU6oedkfXXLdRF40+/jtdi56Ei7HxafbH6OH96K
         0n3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205615; x=1759810415;
        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=I6r7ywVdtgg6puBO7GNeh9QBn+ePwbPPQeAATrRMKjs=;
        b=lZ6TxVscdMyHXY9SofpVGKRj8RBd1qXBLGeecTvK/venXUrHEmapQHq7nc7/5yXts0
         wyKVogujR5YqCpodWi6+PJun4xM41F8vf1KTK1vgWjzXHcHHwOhVrRhCAluMM7saEWwn
         1dpTm0gFwFKrXhAnDLv/RG9Ike5SrkET3/H7jdSZyVyXodItQQG4wbruT3jBt9Vgc9sy
         yHn1U2qtM/iaJBzrxAjp7ARwdP3Lie/17mP65SdQtCzVFda9L5PO/6R7qlV1vuPAcAen
         /KDdmL0Af7reFCjI/im+RDMfpG2FWKyjYgaNuMlyZFHS8rFuf6F890Vi2B6gdqXzSh5W
         MWfQ==
X-Forwarded-Encrypted: i=1; AJvYcCUTfrkXUgzN1L34C4q6IQy4jI78Q+JF3o0t7ybsu8jrNGKaYbQ0w8SIkxCEiiDUkC0y1Gi+SIGzWEY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQEjICHiDU/alQq6JbTdo905cFLQBVpq4PNtoGlyCWzVHR3/6e
	D5n5DrvyQWrLD9WAotAQWZnxXoedc+Fqqa3Y4M5ILVfX1jh01wLQ22c378YB1qpuIkY=
X-Gm-Gg: ASbGncs4x8EDvmDVHaKznAUYZizODYWhi47eBcOzxkm1n0KfgzrXs5iThJ2ECm1ldBn
	mAIGR0FyTzbG+Z7kjoTzVAQjxDHUGt2yG/Z4pbVUh3HAWtooUn6zohs+6FagvM9xOH4X5GcWdnw
	BUYZ0Q7148m36TstqTdOV75cBQACfWScp572zeuqCn0/ZkENKSpk9xMR1byZz+JePijpbhJDDtm
	IF1t7LgF4xPsoi58T6GI/lY5bRKHGOGWBoJQncPdkMRRE9LLPQvvZh2/pzolp3LyrIm95mQSykQ
	2079RJ+UEK0yI4jdFRlqUoWtRAF1JPe8huf02uqE8bmY0nBC/V0NsIp/abbz1tVHA6WJFTJ3n55
	AsOdU85Vqq/z9fc1QHaHPF1fursgyWi1jTcZrKyAW0fC7SDAVwfPIlFOqWSf5Mit/gn6S1TC+te
	1CL8VWW/xgaiuK//cP1XHYjLXcu4tM2/4=
X-Google-Smtp-Source: AGHT+IGBpgGcnWw+C0SOcyJxraGAzm/jw0VAg2sebXTPvNY3JrfVFmYx+CN+ELmzscd2IQVrEVRZAA==
X-Received: by 2002:a5d:5f54:0:b0:403:4b6f:546e with SMTP id ffacd0b85a97d-40e47ee04bfmr14022629f8f.30.1759205614864;
        Mon, 29 Sep 2025 21:13:34 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 01/17] docs/devel/loads-stores: Stop mentioning cpu_physical_memory_write_rom()
Date: Tue, 30 Sep 2025 06:13:09 +0200
Message-ID: <20250930041326.6448-2-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Update the documentation after commit 3c8133f9737 ("Rename
cpu_physical_memory_write_rom() to address_space_write_rom()").

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 docs/devel/loads-stores.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index 9471bac8599..f9b565da57a 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -474,7 +474,7 @@ This function is intended for use by the GDB stub and similar code.
 It takes a virtual address, converts it to a physical address via
 an MMU lookup using the current settings of the specified CPU,
 and then performs the access (using ``address_space_rw`` for
-reads or ``cpu_physical_memory_write_rom`` for writes).
+reads or ``address_space_write_rom`` for writes).
 This means that if the access is a write to a ROM then this
 function will modify the contents (whereas a normal guest CPU access
 would ignore the write attempt).
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:13:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:13:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133437.1471568 (Exim 4.92)
	(envelope-from )
	id 1v3RkM-0007XU-LN; Tue, 30 Sep 2025 04:13:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133437.1471568; Tue, 30 Sep 2025 04:13: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 1v3RkM-0007XN-I8; Tue, 30 Sep 2025 04:13:50 +0000
Received: by outflank-mailman (input) for mailman id 1133437;
 Tue, 30 Sep 2025 04:13: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 1v3RkK-0006gD-Dl
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:13:48 +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 dc2685f6-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:13:46 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3ee1221ceaaso4373187f8f.3
 for ; Mon, 29 Sep 2025 21:13:46 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc56f7badsm20596977f8f.29.2025.09.29.21.13.44
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:13: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: dc2685f6-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205626; x=1759810426; darn=lists.xenproject.org;
        h=content-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=J6XZQA4g1t2k7eXHW7Di/TUkQvEa/xc7WHxCnzJSKoM=;
        b=rvEfaaVf5DZYXnk02ew5puqhy9s9ozh72EXeXMu2qbrNQbdwCrLPTNo0+TSPGZJ7sM
         EQ/aEWBdV9SqJLKmrOOgUJy3swe2haJEsI9u9atJPi+Bir7hGna7CfCz75NP+Nm08XEi
         lOzIgCV1i1ja9BHuAoaQn+NteDTeGHZ4BYCDtj/vh/9cU4TK5YZpvjNjZFrsxxCt4PyY
         EMtU/t5PZfM+MYZFmEtpswkSJTQzo/wRqyHaPWuf54yeE/jKLfTIaShviFLif1j4pWO8
         Rwd8OQ/vTUnf5qAbY8nSiTPVS8nmGJghjwgOiwptzZEEX4WrVOtOSN/R5oaHpmxAPr6u
         wamg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205626; x=1759810426;
        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=J6XZQA4g1t2k7eXHW7Di/TUkQvEa/xc7WHxCnzJSKoM=;
        b=WfieuLb1DJgnXOa22p0fh4qgX/sNGz6YS3khFhn8tESq8il2fNdfUe5xxc6kVhOXl+
         phprWbcgQxfZLC/PtcvKt6kBrgRCCe6ctm3Bd8wHzkkM+/NZhj19iqRse3m44JKif2BS
         be0NJglU3RBu7hwoqd68msVmF2CS6l4ZPlya4cxRxQUH31VbQEeYlcTum6skr+LKFaxK
         YZKBl2l5WmnEoF/RbbVdMKS0k5tMOov3c5RU0Jqnlj/1BHrwpcmasS4rSWpGbNK1HPuu
         /Ka0BaoWueOxd/k1KWSBnW4DqL9OuVNt4+ZBk4HPh8Usj4MpAhwkfdUNDAIS+O+Y44xE
         fvKQ==
X-Forwarded-Encrypted: i=1; AJvYcCXRoGfJOvuxw5SA2GUyzd5vd1KmpG4VrFsqluNWEXBsVASWKRF5Z2H0B6+7BkJhgkEB0Ll5XLWJNDM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxy8pDQc5IDyd3qZq5In3DPW+h9qyetWaNmTYxXbub2KYLxhzBJ
	+bMJ2oVMf8SARbGjkQJkM7X5zGDZ7EwbsyLnZ9GhCXleUDGLnSxrnKEqwIwHqsTaFsA=
X-Gm-Gg: ASbGncsQEZCt0XAPN0lxlEAJveFejIXyQBArbhE+IxSxALWwNYaix8LkhAUSw3J8aE5
	iAmIATNswBaC6r7KlOhh0sQ/u6tooEu68bCSuWKmcu/Yu3HvWicU5j+TUnER0UR9wtsMx8D3pY/
	5PJIeys94jXc0X8tFsKque5zCWNz1p3Hz9X/C1+3FxyBp13QaLQYvxzWlAmJTLyWA4jOGfS+GIo
	Bh2aY8mCeUKXzqq4knlnf+Hs534XwUTuC7JobqIUeB7TFI8fDz6hm2XJ9xgoZvTsXBRFw/leuc0
	JCc3hNKRjkOTggASH6SSJS+on3W3SBHN5L8Hi9bZHOQ9f55qVJmzgWa5rSNKlbNRTB1qrJBzM1B
	cxaqrsc6P2rBKN+rXgujaWeU0SzSIoRIS7jM8/LCjF7USLNgh42xB4B0pkY+6jgoLMcg0BXFrjc
	UeeqVMuMM1Phb0SnPStEf1xbnLRuPov/0XrwohLatZmA==
X-Google-Smtp-Source: AGHT+IH4qhPqaNC0ZqE7vVzxj8tSipzOFCi7y5DLl309Ye1K/9debpwVgj0eZ2sdSCTFy4WRMq+1ZQ==
X-Received: by 2002:a05:6000:2901:b0:3ef:42fe:8539 with SMTP id ffacd0b85a97d-40e47ee0a37mr19502672f8f.25.1759205626154;
        Mon, 29 Sep 2025 21:13:46 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 03/17] system/memory: Factor address_space_is_io() out
Date: Tue, 30 Sep 2025 06:13:11 +0200
Message-ID: <20250930041326.6448-4-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Factor address_space_is_io() out of cpu_physical_memory_is_io().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/system/memory.h |  9 +++++++++
 system/physmem.c        | 21 ++++++++++++---------
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/include/system/memory.h b/include/system/memory.h
index 3e5bf3ef05e..546c643961d 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -3030,6 +3030,15 @@ static inline MemoryRegion *address_space_translate(AddressSpace *as,
 bool address_space_access_valid(AddressSpace *as, hwaddr addr, hwaddr len,
                                 bool is_write, MemTxAttrs attrs);
 
+/**
+ * address_space_is_io: check whether an guest physical addresses
+ *                      whithin an address space is I/O memory.
+ *
+ * @as: #AddressSpace to be accessed
+ * @addr: address within that address space
+ */
+bool address_space_is_io(AddressSpace *as, hwaddr addr);
+
 /* address_space_map: map a physical memory region into a host virtual address
  *
  * May map a subset of the requested range, given by and returned in @plen.
diff --git a/system/physmem.c b/system/physmem.c
index 2d1697fce4c..be8e66dfe02 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3358,6 +3358,17 @@ bool address_space_access_valid(AddressSpace *as, hwaddr addr,
     return flatview_access_valid(fv, addr, len, is_write, attrs);
 }
 
+bool address_space_is_io(AddressSpace *as, hwaddr addr)
+{
+    MemoryRegion *mr;
+
+    RCU_READ_LOCK_GUARD();
+    mr = address_space_translate(as, addr, &addr, NULL, false,
+                                 MEMTXATTRS_UNSPECIFIED);
+
+    return !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
+}
+
 static hwaddr
 flatview_extend_translation(FlatView *fv, hwaddr addr,
                             hwaddr target_len,
@@ -3754,15 +3765,7 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
 
 bool cpu_physical_memory_is_io(hwaddr phys_addr)
 {
-    MemoryRegion*mr;
-    hwaddr l = 1;
-
-    RCU_READ_LOCK_GUARD();
-    mr = address_space_translate(&address_space_memory,
-                                 phys_addr, &phys_addr, &l, false,
-                                 MEMTXATTRS_UNSPECIFIED);
-
-    return !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
+    return address_space_is_io(&address_space_memory, phys_addr);
 }
 
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:13:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:13:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133444.1471578 (Exim 4.92)
	(envelope-from )
	id 1v3RkQ-0007ts-2k; Tue, 30 Sep 2025 04:13:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133444.1471578; Tue, 30 Sep 2025 04: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 1v3RkP-0007tg-Vm; Tue, 30 Sep 2025 04:13:53 +0000
Received: by outflank-mailman (input) for mailman id 1133444;
 Tue, 30 Sep 2025 04:13: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 1v3RkO-0006tq-Kt
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:13:52 +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 df7203a1-9db3-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:13:52 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-46e501a9034so12889255e9.3
 for ; Mon, 29 Sep 2025 21:13:52 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f536a3sm43891685e9.8.2025.09.29.21.13.50
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:13: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: df7203a1-9db3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205631; x=1759810431; darn=lists.xenproject.org;
        h=content-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=jPaFfZE+Vm6W3t7QC31lKwf41cuqTfJ0BWTKMrsHvkU=;
        b=HObH+LjFWxfJ1mUOovyD9dRFY7WD4DrvU/RJf8vy7lFXUQsx0pKT2O27/S8ob+dR7Z
         uJ4shdhhO/fyE3Y9dX25HB/mT/2Ll4uaiEFeuYn6To7p5Jk/4HHLhpbR/maJOC3sCq3a
         9bp6ajSqKrN1789iyCVDR9PEzHdE5tpXiP7Pfe/iv/THrLxh5kGIWRyJzw9M0wfKXPWy
         pqRVIc2Km2BK3XInz2FxhJd47O6BywmjDYsi5XeRwlrnvSgEtWnBrpzK9aVYmVNQyy4n
         nA1dIKYA8RfIYmFpw56tURMzyt9Y/VsM7z9zpZYShfH8kanzH530TOePI/wvJo+0RYU4
         uOYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205631; x=1759810431;
        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=jPaFfZE+Vm6W3t7QC31lKwf41cuqTfJ0BWTKMrsHvkU=;
        b=kagyI9n3BJH2S0+hav5TT7E2ZEeJ9nYiCpbuuYM6lUCx38UalrLE0j3ku4z65oZT+z
         Xcg0nje7Xll/fjXEVlOkZyDCzktgnwg6YT4D2KVbzZOktRpyCPCD/VSUMuDZ8hTji7FW
         vJr47RLyhPNhMVnXKLksrrkGqVJRkiuu+5Yl8JvFZZ4FB9908aZi3qvb5gIKosWur6Gc
         Dw1rvRcsLpC1sZlPNQe223WhHvbCXK7HfErE/haolXfVoAcF/859S4WN3RrOzGZORa1B
         L+CFM71+o8O2bM/FKCb4x+SRS0A9zgqW5HrB155903xtjyXYFWv4rYChZswPH/2Dd2ow
         14CA==
X-Forwarded-Encrypted: i=1; AJvYcCXHhSzu3THq4EZlg/qHWz4ndcLmVN71I+nhLsS7mfYGWJEmZ6QwQeRZ2I29IGULVinfeq4onyDxTBw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWH2BcWmHSVr9zHf3+E1BtZ0wbf26k46h+FUoYOFWUbd6lCnep
	EYjBdUYTeL5qqnE0byZ95S0jGQvdhXzLNy1YpJmITOlkbEfoqzL+7sX30jskvy+q19M=
X-Gm-Gg: ASbGncuxxFlH2EKhhbe2u/40OHL++oLsifBaDeRvTv1rp7i6QSl9qSvrhKwoivKeU3w
	gbIzJNkP1zJW9ToKZuI9krMrfR0tQKtX112Hf63Zq0jUwEhF8lYu926YvVGpf5UYkV2BYEF+0lW
	orPw0G+4CBdPgwqZRU15k214pXHM5QTYKifC64YwJaV+t5hcjJv5fFb2Dd7MKR18EbjU9S1iZEi
	s++Ay6gV633JR3AWie9T0iwujJB1dNJdOhK47hWbTJZYJSh71yMb0abZ2BUymLMVvhQ7HuYimLb
	eGFyazl8Or8EkuEBOBihYME/Y8Kg7MigEeCSfzipn4xtj4Cy74VwfKr0jxH3g1plGy10aWAjUH8
	LIX5RSofS2L6to+9a02ANs4YF7C+U0cOiA4i7YdyNuZU1f887adGvhQZc77t2eZZT4/jmwhR7FQ
	pm47xwsGZE6i3PCZBnHfYybdXDyETGgQ0=
X-Google-Smtp-Source: AGHT+IGcac+YiZIcZSnCrqiaQ5DwkBXJUwHzOeJuSpEQu46EHairXFh+p7pa80eZkns9YIhZ38oTxg==
X-Received: by 2002:a05:600c:444d:b0:45f:2cd5:5086 with SMTP id 5b1f17b1804b1-46e3299f4f3mr172171215e9.3.1759205631445;
        Mon, 29 Sep 2025 21:13:51 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 04/17] target/i386/arch_memory_mapping: Use address_space_memory_is_io()
Date: Tue, 30 Sep 2025 06:13:12 +0200
Message-ID: <20250930041326.6448-5-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since all functions have an address space argument, it is
trivial to replace cpu_physical_memory_is_io() by
address_space_memory_is_io().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/arch_memory_mapping.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/i386/arch_memory_mapping.c b/target/i386/arch_memory_mapping.c
index a2398c21732..560f4689abc 100644
--- a/target/i386/arch_memory_mapping.c
+++ b/target/i386/arch_memory_mapping.c
@@ -35,7 +35,7 @@ static void walk_pte(MemoryMappingList *list, AddressSpace *as,
         }
 
         start_paddr = (pte & ~0xfff) & ~(0x1ULL << 63);
-        if (cpu_physical_memory_is_io(start_paddr)) {
+        if (address_space_is_io(as, start_paddr)) {
             /* I/O region */
             continue;
         }
@@ -65,7 +65,7 @@ static void walk_pte2(MemoryMappingList *list, AddressSpace *as,
         }
 
         start_paddr = pte & ~0xfff;
-        if (cpu_physical_memory_is_io(start_paddr)) {
+        if (address_space_is_io(as, start_paddr)) {
             /* I/O region */
             continue;
         }
@@ -100,7 +100,7 @@ static void walk_pde(MemoryMappingList *list, AddressSpace *as,
         if (pde & PG_PSE_MASK) {
             /* 2 MB page */
             start_paddr = (pde & ~0x1fffff) & ~(0x1ULL << 63);
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_is_io(as, start_paddr)) {
                 /* I/O region */
                 continue;
             }
@@ -142,7 +142,7 @@ static void walk_pde2(MemoryMappingList *list, AddressSpace *as,
              */
             high_paddr = ((hwaddr)(pde & 0x1fe000) << 19);
             start_paddr = (pde & ~0x3fffff) | high_paddr;
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_is_io(as, start_paddr)) {
                 /* I/O region */
                 continue;
             }
@@ -203,7 +203,7 @@ static void walk_pdpe(MemoryMappingList *list, AddressSpace *as,
         if (pdpe & PG_PSE_MASK) {
             /* 1 GB page */
             start_paddr = (pdpe & ~0x3fffffff) & ~(0x1ULL << 63);
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_is_io(as, start_paddr)) {
                 /* I/O region */
                 continue;
             }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:13:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:13:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133448.1471589 (Exim 4.92)
	(envelope-from )
	id 1v3RkV-0008Lw-Cp; Tue, 30 Sep 2025 04:13:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133448.1471589; Tue, 30 Sep 2025 04:13: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 1v3RkV-0008Lp-7o; Tue, 30 Sep 2025 04:13:59 +0000
Received: by outflank-mailman (input) for mailman id 1133448;
 Tue, 30 Sep 2025 04:13: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 1v3RkU-0006tq-0w
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:13:58 +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 e2abb080-9db3-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:13:57 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3fa528f127fso4221194f8f.1
 for ; Mon, 29 Sep 2025 21:13:57 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab31e97sm251610955e9.14.2025.09.29.21.13.55
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:13: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: e2abb080-9db3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205637; x=1759810437; darn=lists.xenproject.org;
        h=content-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=UsPYBf9Y41DYeMpdEdOkBi/mu9mpDrkpGT9A+u43FVY=;
        b=EOltNrgaoPb01blgoG8FhMbkMNs42aJp+3jl6NEtrplaKslDjHAwMKagldcrT0QbO6
         RlDv5ardTLkf/rjliK7D12I3wC2SS5Z+FZKFl6q9ybKoseD31QU47Pl0v3/Iz00bKQjq
         nsQji94mkLt8yN3wqimjvK0Q8uMXS/DZE5mVfrTbnbB51i4YMPGmZuHlayihkKaQzzg6
         3N/to+1Z4HbkxodoNlG+tZyI149VgTHHz6vlki25XMnXYe/XHk204mfg8fURq5l1m2kp
         dBN0Ibo/VZlPe3s1dGZnTNeu69eJ7Kk1omln7lF9P861PJz6Y6RIXNMRcwte4i+YYLFf
         wMNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205637; x=1759810437;
        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=UsPYBf9Y41DYeMpdEdOkBi/mu9mpDrkpGT9A+u43FVY=;
        b=CXf3xF8D7eY3mulRfhvSD9wKI5WB7aaf6Jph5qjT3vsyYQRDEvzlvG4p/y/XlEZtcy
         Y6F2TfYBZfeZLteWz79STyN5JBWtdT+iHgZQdROUmVMAQIfG5mhuR7xzVc+j9yFF8tAl
         urPqUTK4YXMD75QDN5u6IHSZovou02NwGTTUnFCf0YFOq6PkhXC3PlKlt/jVGwSoVxGi
         NFjYeau9PRM4hxx+8IFDa0pd3ukG4daGiHqAdKfz1Ia4vod4PR4KvBASkdof2pk7tx/i
         XN9t3isvzGjKGzuq4jHKjo2T6/dxHT6qNrGsyWTZCVRy4CLIpmNuKSICmm8JCd1Ufv8e
         7ITw==
X-Forwarded-Encrypted: i=1; AJvYcCVwtWr7/jFbO9S+tzx29xXGr+j9d0jpv2ZZlS7w/rbCtIeBp9TXkosZwGkHCUAGzylR/YHWVY5ymCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKV+whCc3WbRuEMnEDkJGETeJNKcWHivzAlyChHLFUBf/4s3ay
	hd8uQQNb5eCSdp6J1sPBFM8jtTGZ8bsppJ2rdZ792ES7n1ljiy92A5S7FU3jMtZBYwc=
X-Gm-Gg: ASbGnctX+PhzVlUT6X/9Wq0UR0wqY0JHaL4fZtuWH+ZfXLjoG5faVUJmZOms16/28J3
	NRBEmAokvTeJYMnce8mfhrGiuRV8SsTnzd0/VxTrOHnOMCz6vb/U8CC/ZYdLle6IjtPH5w74WNK
	CHPQR7vwBP0hQsEo3d+nZPD9k4yM34qLXfgfEZK1B/ksy7WNASd2H3SqIDD75Imtq7OibQKyL8Z
	ywM8TH6Sg0hsUpRWFHkLF4t8G2Od1gZ58yb8vEoYSZ0oZgFDoqsLYpJ1jQ+G4MgxWxaniZMtFyM
	Jup+p0ie+LRdo53vTFnsAr2zcXWGfT7wKwdmwjh03c+gZPi3IV8jd6rugCuEkWgbpNuHnYuQLdo
	Oi5uKsKZI/c1OhsycwCwrnm4M9t2zFt9hxHQi7R7eQiFF++g7WkkgtA80ZwuegcNfdUEIi39TMm
	pWHUywHEBtSoW+7FeBwJKm
X-Google-Smtp-Source: AGHT+IH3He/bgDcAVA0O1uM4KAZUJWAOZ5pxrLV0agMvoc3nOriIeKi2nLWEPRWZf/BAWQ6cyeIFXA==
X-Received: by 2002:a05:6000:40c7:b0:407:d776:4434 with SMTP id ffacd0b85a97d-4241227789emr2285457f8f.30.1759205636900;
        Mon, 29 Sep 2025 21:13:56 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 05/17] hw/s390x/sclp: Use address_space_memory_is_io() in sclp_service_call()
Date: Tue, 30 Sep 2025 06:13:13 +0200
Message-ID: <20250930041326.6448-6-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When cpu_address_space_init() isn't called during vCPU creation,
its single address space is the global &address_space_memory.

As s390x boards don't call cpu_address_space_init(),
cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.

We can then replace cpu_physical_memory_is_io() by the semantically
equivalent address_space_memory_is_io() call.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/s390x/sclp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 9718564fa42..f507b36cd91 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -16,6 +16,7 @@
 #include "qemu/units.h"
 #include "qapi/error.h"
 #include "hw/boards.h"
+#include "system/memory.h"
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/event-facility.h"
 #include "hw/s390x/s390-pci-bus.h"
@@ -301,6 +302,7 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     CPUS390XState *env = &cpu->env;
     SCLPDevice *sclp = get_sclp_device();
     SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
+    AddressSpace *as = cpu_get_address_space(CPU(cpu), 0);
     SCCBHeader header;
     g_autofree SCCB *work_sccb = NULL;
 
@@ -308,7 +310,7 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     if (env->psw.mask & PSW_MASK_PSTATE) {
         return -PGM_PRIVILEGED;
     }
-    if (cpu_physical_memory_is_io(sccb)) {
+    if (address_space_is_io(as, sccb)) {
         return -PGM_ADDRESSING;
     }
     if ((sccb & ~0x1fffUL) == 0 || (sccb & ~0x1fffUL) == env->psa
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:14:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:14:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133460.1471598 (Exim 4.92)
	(envelope-from )
	id 1v3Rkc-0000S7-Lo; Tue, 30 Sep 2025 04:14:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133460.1471598; Tue, 30 Sep 2025 04:14: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 1v3Rkc-0000Rz-HT; Tue, 30 Sep 2025 04:14:06 +0000
Received: by outflank-mailman (input) for mailman id 1133460;
 Tue, 30 Sep 2025 04:14:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Rkb-0006gD-AN
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:05 +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 e638c73c-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:14:03 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-46e2e363118so52025545e9.0
 for ; Mon, 29 Sep 2025 21:14:03 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc6cf3835sm20954191f8f.46.2025.09.29.21.14.00
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e638c73c-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205643; x=1759810443; darn=lists.xenproject.org;
        h=content-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=GJHuzj8i65yKq7/CrLnIUXqdpZj8DIZ6OJzdCMb/6CI=;
        b=NgSRl0JJURpI02GiMygQU/1oYHxfu4MuU5AaAdfcfOb51gVpkYej74DwRgjlygjoyh
         nu5ccUqc6sKCsNhQdAHkqcmyLiVghEhcI7RJwDLBWsoMAGEt4H7JMLmLnVEs8nAfgSm6
         vjLOW3GWEJHaQLeBiB7vaXg9TwwqFDwLrLJzDOzPvJOfQYASBKOQx1SSy3YahPBby4yJ
         pZEPM4pOCeTsGx+gksflyCBsPOBSC0+OAfNbIn6GMak8NmTUBptWxl4QAFcg3ozjjT9V
         L0XP9X9djr9gVmz1QCXu2Hr7eiYapKRKO7MPuk5aV8trmnYD2LK+2ykRW0phQbXJHy08
         Bx7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205643; x=1759810443;
        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=GJHuzj8i65yKq7/CrLnIUXqdpZj8DIZ6OJzdCMb/6CI=;
        b=mjH3AVPmDzWq05RS0cVbaptBwZNxYob8Y/N7F3KoJPf/x5H3Pfq3vEMR/Koix5UAQR
         LFOyy3lmQSUDpCZkn0utcwojJUXKef3bqkVO1//dvAP5xc8CxpGVI0KHiGsroNUzzhoW
         j6oyP2A0TIpznT4PjSAPBjpBF9oXwJLQKs/bhJkf5acX3JjQXJ7RT4uNR4XnJvldQoJb
         E1RerPIV+iVsZlJIrkJooq04OmwG9nOECygKvl3rknu+ZK+Ib5WyUrrtsYDqaDVwbGka
         Pu0ZeGFhbr49qUPYPnsPXn96i7Y+ETn4wciGFuE6zh2+uhNcAMZqCVwVwuusKFzLkn1B
         JZvg==
X-Forwarded-Encrypted: i=1; AJvYcCWd74C/FrkDJtFjJT9DgVFfaevS3We31qw6bKVbp93zSI7Q5fBoKsMZ4lkaDoen9GQC6zc9rWz49Pk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwEscXEb9uwFRCzns7MAe8pPxn2nyzi7QIx/4ktI9DYvYDgZjrW
	0VN5uMGL3Pw4HBVTOuiqztRWXOvf6pAPeKe6AQGqIAl53QRO+m/1tEsJYEBirJ6zxGg=
X-Gm-Gg: ASbGncvcpG5XTzatR+ItKTI1B9HReDG+MFScqHhcT9Ub9hNIh9zfC+s1qg6cGF/K2jH
	C4iYGQggB2IJVPNnakKBple5hyi6HKi7XPDWGRND6kxTSfuOhAS7zVsHCGw3c7hcBaBEpyp/ZId
	0+2kF3CukrkLPIlNxS+oGPAD7YF2hIyXssPSXo94XMoN8FmBJpwoBEchcTRNfedg1y0W9Zp38Ui
	Yn+khahYwvda/fHAsmkAqRsktWZciNS1QKywmM8iKZzLNQMG6cSiC8G4iSId9JAPpiqWOysAeqC
	VDM5uD2Ii9AJdbHgqOj9sPW001fciuk80mDv0JqmTa/qqOWJX7htq28EPbs6FVNaX1yAK7i3e4H
	fRLird6ycOMs8+gYdLTzYkUsxRL+r1r3178l3Dcz4+Hiydal8QjCByt52ZKeeuLBRJ/DdpVhw2U
	vje9h71j6oblT16170I2fEY0P5F7F72D0=
X-Google-Smtp-Source: AGHT+IFzoydC/PtH1+zccfqdIbgaSIsqjwZE3Y6j7iXWudBl2KZiSFlGWhLtg5m0yJ4ctRkRXODKlQ==
X-Received: by 2002:a5d:588c:0:b0:3f9:fd59:7a5f with SMTP id ffacd0b85a97d-40e4a05bf52mr18187688f8f.33.1759205643111;
        Mon, 29 Sep 2025 21:14:03 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 06/17] system/physmem: Remove cpu_physical_memory_is_io()
Date: Tue, 30 Sep 2025 06:13:14 +0200
Message-ID: <20250930041326.6448-7-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are no more uses of the legacy cpu_physical_memory_is_io()
method. Remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 include/exec/cpu-common.h | 2 --
 system/physmem.c          | 5 -----
 2 files changed, 7 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e413d8b3079..a73463a7038 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -149,8 +149,6 @@ void *cpu_physical_memory_map(hwaddr addr,
 void cpu_physical_memory_unmap(void *buffer, hwaddr len,
                                bool is_write, hwaddr access_len);
 
-bool cpu_physical_memory_is_io(hwaddr phys_addr);
-
 /* Coalesced MMIO regions are areas where write operations can be reordered.
  * This usually implies that write operations are side-effect free.  This allows
  * batching which can make a major impact on performance when using
diff --git a/system/physmem.c b/system/physmem.c
index be8e66dfe02..573e5bb1adc 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3763,11 +3763,6 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
     return 0;
 }
 
-bool cpu_physical_memory_is_io(hwaddr phys_addr)
-{
-    return address_space_is_io(&address_space_memory, phys_addr);
-}
-
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
 {
     RAMBlock *block;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133490.1471608 (Exim 4.92)
	(envelope-from )
	id 1v3RmW-0001sS-2H; Tue, 30 Sep 2025 04:16:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133490.1471608; Tue, 30 Sep 2025 04:16: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 1v3RmV-0001sF-UL; Tue, 30 Sep 2025 04:16:03 +0000
Received: by outflank-mailman (input) for mailman id 1133490;
 Tue, 30 Sep 2025 04:16: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 1v3RlH-0006tq-Lv
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:47 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 004b39ac-9db4-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:14:47 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-46e2562e8cbso41430165e9.1
 for ; Mon, 29 Sep 2025 21:14:47 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2a9ac5basm284686015e9.7.2025.09.29.21.14.45
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: 004b39ac-9db4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205687; x=1759810487; darn=lists.xenproject.org;
        h=content-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=U9bErLRqv9kjbdzs2kwz9FzL8C8SAPMQ12Esuz3D9Fo=;
        b=SvzTjNGjToxYRmnX1XsGif8m5i+Rmippesloev6S3qUHzuPYLC6f649MhBanCuGbfH
         Q73cAHfOEE5BQ23PdenGtwqMJal1FPU5mhq4As7PyAHpsN9rgIDwXJdR0TALVgoO5ET6
         E2rt14cPlZTrECszG9vPzdUXnH096zUTYTpkeUgoJSZScP62DIUCKVbUoz9YrtwWsuaR
         lY1G+vZm4+Uoecf4o6TN1qU5rOud4Sor0NrJDdHxwgWdnKYwJVbYvmWFJkRgdDHe6dwf
         1mEtJuEeGEwkTSxkGTcOyGyexlv8hDP1aH0VE5r5aQ5eJV4X3JMFoRI66vQA389RI0nQ
         23CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205687; x=1759810487;
        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=U9bErLRqv9kjbdzs2kwz9FzL8C8SAPMQ12Esuz3D9Fo=;
        b=CLre+0tXs3pO2MuCbC4EVyt+0ptnP7JKhGfREaCjwcIzt6k/rFsHjl8F/MiKDW1gYP
         WYDEXGPK4r7FM8uR+GdAYI4iVQoh57+r2GEHeZfU5L1JXw6salE4ZaCk95HL7KmVg1h0
         12N95K+8viqb5Ltp3T8YHnXYQEI4KuG8Dm611qhLZiOZTDtb3PNInUZ4n8WnCpE2Z+6B
         gXJBfrWeNT58o/+vYIVpSQ0bgnyoZZb8ObhtMIphtow2P9HEM7TWOs7Z48qkdFOUe0nR
         ZGbWwdTDzaAuA9xZzwA/DeiHZVsQ++H58VckoF5Yged/pE9NafrT/8HOzuQiHKjfHYjW
         IocA==
X-Forwarded-Encrypted: i=1; AJvYcCW72ITtAXA00UEM8EIlWc9H0elMfPRYEZLWne/QDaokQVA0hXyln4/2pQ+A1jrUOfDAdMTyfV0aQ7o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3sDk8ZrB6yeFxjnwVhcJfNA+9CRXSXyIFY/i0qRRmU8ST633J
	i7i5LPJmW+rP45Fkh+e+T0r27DtgIABn8Kk7Eiw1M59q0Pb+qkGa9+dbwVMZV8tWw88=
X-Gm-Gg: ASbGncuRvWFg0QuymycVS3rXDRsXf7BRquW4uISIoCjwcDtOzlpMyAUEigzC8d1Kd/L
	7U1PjQrMgyLp4Xge9Xt2UxnOIeZHuxV4I5SXnPGryHEsfgaKS9C2v53CzgLjMjnvyqN93AnFsTH
	I14bxB50QEgNV+2HYatvWeytqSLZjJVVJjZCyOEDNaMVonb603mOadjtUeDBPUOw2HejkGRyCYr
	KLc12ZsKz2oZ+IXfFNsfWhNFY/pwaIFjVljzWA2IEo5SPHK9DQOGiYdoCjN7gTDq4pFoYhX78M1
	U5YMxCidV1pd5Rt3th75m/89mRgXOXb4EgjzRgFNqnHWg3i3xGnTyQfca4fBZTZrP/TQQBwelyH
	qoDLRX/ZbWq38knEmjKQwwAb3sTbF8VY7r/d0jA0Mc0SUbFH7ndrFV5WCLGjtIwx57+MoyJBhqM
	VMWgfMul+jNvcY3jhEjXvx
X-Google-Smtp-Source: AGHT+IGyKmmQIMqQURGJv7gP62rq5JnP7SAE6q2ubqy946YRUlo5uVTz66eDWtBwE0h2GgBG2/uY2w==
X-Received: by 2002:a05:600c:4e43:b0:46e:3f6f:a8ee with SMTP id 5b1f17b1804b1-46e3f6faa76mr119745615e9.13.1759205686721;
        Mon, 29 Sep 2025 21:14:46 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 13/17] hw/xen/hvm: Inline cpu_physical_memory_rw() in rw_phys_req_item()
Date: Tue, 30 Sep 2025 06:13:21 +0200
Message-ID: <20250930041326.6448-14-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_physical_memory_rw() is legacy, replace by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/xen/xen-hvm-common.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index 78e0bc8f644..52e2cce397a 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -12,6 +12,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/boards.h"
 #include "hw/xen/arch_hvm.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "system/system.h"
 #include "system/xen.h"
@@ -279,8 +280,8 @@ static void do_outp(uint32_t addr,
  * memory, as part of the implementation of an ioreq.
  *
  * Equivalent to
- *   cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->size * i,
- *                          val, req->size, 0/1)
+ *   address_space_rw(as, addr + (req->df ? -1 : +1) * req->size * i,
+ *                    attrs, val, req->size, 0/1)
  * except without the integer overflow problems.
  */
 static void rw_phys_req_item(hwaddr addr,
@@ -295,7 +296,8 @@ static void rw_phys_req_item(hwaddr addr,
     } else {
         addr += offset;
     }
-    cpu_physical_memory_rw(addr, val, req->size, rw);
+    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
+                     val, req->size, rw);
 }
 
 static inline void read_phys_req_item(hwaddr addr,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133498.1471617 (Exim 4.92)
	(envelope-from )
	id 1v3RmX-00029Q-7W; Tue, 30 Sep 2025 04:16:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133498.1471617; Tue, 30 Sep 2025 04: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 1v3RmX-00029H-4I; Tue, 30 Sep 2025 04:16:05 +0000
Received: by outflank-mailman (input) for mailman id 1133498;
 Tue, 30 Sep 2025 04: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 1v3RlV-0006gD-0L
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:15:01 +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 07673729-9db4-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:14:59 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3ee130237a8so3873594f8f.0
 for ; Mon, 29 Sep 2025 21:14:59 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb72fbb27sm20526091f8f.4.2025.09.29.21.14.56
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: 07673729-9db4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205699; x=1759810499; darn=lists.xenproject.org;
        h=content-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=FwO23E8zQD3tYxR1qcdfXict3HnZqpkDFtM6ocAlj5I=;
        b=cex1n7YEdI9FmvQ4SFGyQSYpFRswclXa1UlL/IpK7MqsNv83X3hY7Adfpq0XlQ5ofn
         TAT/ZPIeJ6VYuqmztXd/P9VTbK6x6eVbGKM9FZAPNO8W5GlcTw6KFgjU0UFmRNwLCf25
         Cbwjms4PX3SqXKq6vjrSSjHVlMy73QRV2RMMNOQO8osyAB22qASTfzJN80D0WakTnU7T
         jWd4p/96ruQXH3V52xVhh7Tvadj0b1HTLwMyUE3n+LXnWoBs35OnNvutC8PG5UDdwATT
         QyZA3eTq1UI+NDjvh4IaIvArZVQE6iJkpURiZNCw1n4xK9e6GiIWDT1D4ZkNgX9djvxL
         hgwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205699; x=1759810499;
        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=FwO23E8zQD3tYxR1qcdfXict3HnZqpkDFtM6ocAlj5I=;
        b=AmkG8d/3cfWNeBQgNhwfkQuWN6f/BP6/pI4pVMnTXyuP9LpckgJgWtfy09xQGsqcUa
         eDEI0QjInj7zXdi7XL0QxVgxSUYfX9ITHXmflZ3jcbRdQoNa7ImdZ2o+u/8rvBA638fa
         0BOXqueqdNAkA+vEWuHJp12GbHII/ismTkAk85aGhp2g23EwutdS8C8LdgOdh6oH6sJV
         hAY4aUlrRTvuWmEdJ3bN6kSov7LSS1UzT4cZl7waUfer7nQl6R/gP8/09kj2VWX4jO1S
         UdnQLhUTTp2N9h26hyy4bJgAEHdTNM3/ysgRYeyUuj6gcUluVQ9ACjj4YAP/Q65uQQI1
         Oafg==
X-Forwarded-Encrypted: i=1; AJvYcCUu9fDF22VEVzy9JAwuUYGRD4kDosI3oKVCuwBNgg0utIUJWC5sFeiIZY/9mgDK2gtV0XQ5WjU2KGw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YweKjzqT+vEE4tIRfSO3PFHZZblSAJgxvyvWIc0urK1Ijg4djo7
	NGZPDCSpyQ+VcSWhrJ5j7+fb3Te+78ehO/AVYO6cLuXnhXgtgSzUsAjdgOw1EB8lYh8=
X-Gm-Gg: ASbGncslm7cCyuaJLmyi1xG+hgGkphcxM3vEGmqUf/f3VftG0zEV2z1H74ig7GDF7TO
	0AoSMoow+ezDDaGogkIKthByhgeVTaQphevTU9TxwDMGNJRVt9juYV8cxt0vD+a7kPhLywovd3g
	SnEDx5Ty5OFzJ/YYLpzZCHJ1SA1UT/XYhlKTIX67fFN0dNqIl+GOkGUfz544BuO/RoSjK/l0/uu
	NY0B2sTivf2LvyHxzdtbrYun5ZwXPZyEhGboKzTdKEJPJ6P9roVgzNPEPF+u+KK69ROSx6paHVx
	SUud15dTwQp1UHWNVNnKBm5O01GkvTQE+jTlvVm9/SWOOjWFaB06IS4DKsn9SYmFkYyRotbqCsa
	AJXk5LlFJwkIR9IhudVh9b7cDqxCquz1zL/9wB0GRJwIKled5wVEe3ZEMuJ9dsYaWd6SBb+TjSY
	HKlDCma26RS9nTo/UGzKeXcQOPKK7iTfgk3TF/FJz3JQ==
X-Google-Smtp-Source: AGHT+IHQUeMIWrPOvhxUlcXifIoWvE3/8AU9Ob5ucePyts2g6/ZGYEFjge5tsRgBwyw13Vrh3DLZdg==
X-Received: by 2002:a05:6000:430d:b0:3ed:a43d:e8c4 with SMTP id ffacd0b85a97d-40e458a9856mr16110543f8f.6.1759205698778;
        Mon, 29 Sep 2025 21:14:58 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 15/17] system/physmem: Inline cpu_physical_memory_rw() and remove it
Date: Tue, 30 Sep 2025 06:13:23 +0200
Message-ID: <20250930041326.6448-16-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

After inlining the legacy cpu_physical_memory_rw() in the 2 functions
using it (cpu_physical_memory_read and cpu_physical_memory_write), we
removed all its use: remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/devel/loads-stores.rst            |  4 +---
 scripts/coccinelle/exec_rw_const.cocci | 22 ----------------------
 include/exec/cpu-common.h              |  2 --
 system/physmem.c                       | 13 ++++---------
 4 files changed, 5 insertions(+), 36 deletions(-)

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index f9b565da57a..c906c6509ee 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -460,10 +460,8 @@ For new code they are better avoided:
 
 ``cpu_physical_memory_write``
 
-``cpu_physical_memory_rw``
-
 Regexes for git grep:
- - ``\``
+ - ``\``
 
 ``cpu_memory_rw_debug``
 ~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/scripts/coccinelle/exec_rw_const.cocci b/scripts/coccinelle/exec_rw_const.cocci
index 1a202969519..4c02c94e04e 100644
--- a/scripts/coccinelle/exec_rw_const.cocci
+++ b/scripts/coccinelle/exec_rw_const.cocci
@@ -21,13 +21,6 @@ expression E1, E2, E3, E4, E5;
 + address_space_rw(E1, E2, E3, E4, E5, true)
 |
 
-- cpu_physical_memory_rw(E1, E2, E3, 0)
-+ cpu_physical_memory_rw(E1, E2, E3, false)
-|
-- cpu_physical_memory_rw(E1, E2, E3, 1)
-+ cpu_physical_memory_rw(E1, E2, E3, true)
-|
-
 - cpu_physical_memory_map(E1, E2, 0)
 + cpu_physical_memory_map(E1, E2, false)
 |
@@ -62,18 +55,6 @@ symbol true, false;
 + address_space_write(E1, E2, E3, E4, E5)
 )
 
-// Avoid uses of cpu_physical_memory_rw() with a constant is_write argument.
-@@
-expression E1, E2, E3;
-@@
-(
-- cpu_physical_memory_rw(E1, E2, E3, false)
-+ cpu_physical_memory_read(E1, E2, E3)
-|
-- cpu_physical_memory_rw(E1, E2, E3, true)
-+ cpu_physical_memory_write(E1, E2, E3)
-)
-
 // Remove useless cast
 @@
 expression E1, E2, E3, E4, E5, E6;
@@ -93,9 +74,6 @@ type T;
 + address_space_write_rom(E1, E2, E3, E4, E5)
 |
 
-- cpu_physical_memory_rw(E1, (T *)(E2), E3, E4)
-+ cpu_physical_memory_rw(E1, E2, E3, E4)
-|
 - cpu_physical_memory_read(E1, (T *)(E2), E3)
 + cpu_physical_memory_read(E1, E2, E3)
 |
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6e8cb530f6e..910e1c2afb9 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -131,8 +131,6 @@ void cpu_address_space_init(CPUState *cpu, int asidx,
  */
 void cpu_address_space_destroy(CPUState *cpu, int asidx);
 
-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write);
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
 void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
 void *cpu_physical_memory_map(hwaddr addr,
diff --git a/system/physmem.c b/system/physmem.c
index 6d6bc449376..a654b2af2a3 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3181,21 +3181,16 @@ MemTxResult address_space_set(AddressSpace *as, hwaddr addr,
     return error;
 }
 
-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write)
-{
-    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
-                     buf, len, is_write);
-}
-
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
 {
-    cpu_physical_memory_rw(addr, buf, len, false);
+    address_space_read(&address_space_memory, addr,
+                       MEMTXATTRS_UNSPECIFIED, buf, len);
 }
 
 void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
 {
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
+    address_space_write(&address_space_memory, addr,
+                        MEMTXATTRS_UNSPECIFIED, buf, len);
 }
 
 /* used for ROM loading : can write in RAM and ROM */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133499.1471628 (Exim 4.92)
	(envelope-from )
	id 1v3RmY-0002YS-Kk; Tue, 30 Sep 2025 04:16:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133499.1471628; Tue, 30 Sep 2025 04:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3RmY-0002Y4-Hn; Tue, 30 Sep 2025 04:16:06 +0000
Received: by outflank-mailman (input) for mailman id 1133499;
 Tue, 30 Sep 2025 04:16: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 1v3RlN-0006tq-Mx
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:53 +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 03e2d382-9db4-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:14:53 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3ee15505cdeso4203838f8f.0
 for ; Mon, 29 Sep 2025 21:14:53 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-41855fc661esm13064710f8f.45.2025.09.29.21.14.50
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: 03e2d382-9db4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205693; x=1759810493; darn=lists.xenproject.org;
        h=content-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=tDZrJ5n4JJlGtTIDZGasXxs/GbyDfsVnrlhryX3chWg=;
        b=J6pxTyPCIja4+jlJxWtpeDTXBaD/YcUHXHs+PrKTrT3xLGasL8EKv9EIug8OKlGnsX
         L0NX+vEXqTEvHC6OP2FlyqY+QgzkF6sFgvBd1n5G1ElVQEGpxyFN9nzmkGATCaDJgY9b
         euN2z1y25yekC03eJqdBOHGKhzFX5jgsos703ndW3dCMIIceDyikBZlO05nl2c2Xtv9t
         8AUAy0UCA5bhjSofvznNpJwIhdSHmTTaz5ycNPIXv8h/y2j4JI88GV/mOx5V6bUaRdOd
         JjN6Z9fIBGwANfoyZ78FF0Tp1JwE0t8ZDVIEH4S7roYu3IuEpLyZfIHwTizA4yYYSPQJ
         ED2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205693; x=1759810493;
        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=tDZrJ5n4JJlGtTIDZGasXxs/GbyDfsVnrlhryX3chWg=;
        b=rZjZ/sQhXEN4nj1/xRMPI3lTew4mj7EeDeQSaxOMCwtgi+bn4LhY6hFrxPA/5aUCk+
         atAwEuLlyXRD8MQEQSWehBG9YsraPMkecbTov8iFolsDtjgUi+Ded+IV+CMa2uKUp9EN
         qVZzViTqC5VdUZNeHBB3C7J2KvuOGpsiZq65FnAVBpxom5I/vf1pehLpiOJnkhYAjXvp
         RT6a6PoIq+/XPqGMkkcewgCRz8zCLpjr+FsADLWlUf4SbEMlHgBtbjCmOSedx2m1l1p6
         RLVoYioTP1ugwyKjc/NWyjwreGwKR8yL0TsPylEHrfLLvmJ+oLcBl3nXTdzCWuUbH8U7
         SVxg==
X-Forwarded-Encrypted: i=1; AJvYcCV+6QxUvfcCi4y4W1CiluedSjNmFuyjYvW+H7JFgY90MJeJyCXgEvaTDAe/1tqDFcRrBbWdvgka8d8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzl64eaDeSaPUuX+2IaaTRzg7w437NGCW9hmtBlbASFdLirVuSF
	+TlXjymvi+dVKTBWo1lsBBRZTAmziJq5EZ4MmuSEZVC5C82GiBKoeFx1fCTb9FJsiPo=
X-Gm-Gg: ASbGnct0DLr1y0JNd45ZEmaj4pmLdgCzSypJhnbsG1nSvj8Q+IwjKa49gowWHLQSDB1
	OoVMIKLleebKVoSNsX5yAnVLwlRRUE3kNBodaqhuhtYDHSFSyURgiE7cIO8WPp2UK4Dtsm38dZK
	Am3wJYrIQ3fBzHfqHRfmVClY1T8gghvkkJMMiRACuG70HrR/qifzD4XMgJ7PGpaFwQdrj3nBQ9j
	glrrRKbE7r5avsKnIFmJW/eozgxmao78+1+f4lMqu9tMs1/9BM2RXnqBT9PpTdvq0h1kk32nSMa
	M5sewNH2lI0S88ulw7Zsf3cVy+O9VwBcuUVvyUskldHSCHJ1/ja65Bi2In9uQ7YPFPWYK2IeQBC
	neauBQTW7eEjgffDTQsX4wfHooshI5z+bWWL/yqxYt9oeS8wOLt2YMn2RPq++gRv4qRo/WBJ01w
	JYwV7d40elvsgNzyY627rk
X-Google-Smtp-Source: AGHT+IGTcuGp6K4U+VzNJFqsWFt5qmyyMICY36EpMMpwA/c/CYvK54pPvXL/H3Oj0HTHDk8uqyOMBA==
X-Received: by 2002:a05:6000:2901:b0:3e7:617f:8458 with SMTP id ffacd0b85a97d-424116eaebcmr2419836f8f.24.1759205692755;
        Mon, 29 Sep 2025 21:14:52 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 14/17] system/physmem: Un-inline cpu_physical_memory_read/write()
Date: Tue, 30 Sep 2025 06:13:22 +0200
Message-ID: <20250930041326.6448-15-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Un-inline cpu_physical_memory_read() and cpu_physical_memory_write().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu-common.h | 12 ++----------
 system/physmem.c          | 10 ++++++++++
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6c7d84aacb4..6e8cb530f6e 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -133,16 +133,8 @@ void cpu_address_space_destroy(CPUState *cpu, int asidx);
 
 void cpu_physical_memory_rw(hwaddr addr, void *buf,
                             hwaddr len, bool is_write);
-static inline void cpu_physical_memory_read(hwaddr addr,
-                                            void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, buf, len, false);
-}
-static inline void cpu_physical_memory_write(hwaddr addr,
-                                             const void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
-}
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
 void *cpu_physical_memory_map(hwaddr addr,
                               hwaddr *plen,
                               bool is_write);
diff --git a/system/physmem.c b/system/physmem.c
index 70b02675b93..6d6bc449376 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3188,6 +3188,16 @@ void cpu_physical_memory_rw(hwaddr addr, void *buf,
                      buf, len, is_write);
 }
 
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
+{
+    cpu_physical_memory_rw(addr, buf, len, false);
+}
+
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
+{
+    cpu_physical_memory_rw(addr, (void *)buf, len, true);
+}
+
 /* used for ROM loading : can write in RAM and ROM */
 MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
                                     MemTxAttrs attrs,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133501.1471633 (Exim 4.92)
	(envelope-from )
	id 1v3RmZ-0002bb-0i; Tue, 30 Sep 2025 04:16:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133501.1471633; Tue, 30 Sep 2025 04:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3RmY-0002av-Pp; Tue, 30 Sep 2025 04:16:06 +0000
Received: by outflank-mailman (input) for mailman id 1133501;
 Tue, 30 Sep 2025 04:16: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 1v3Rla-0006gD-Tj
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:15:06 +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 0afec4bb-9db4-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:15:05 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-421851bca51so973983f8f.1
 for ; Mon, 29 Sep 2025 21:15:05 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-410f2007372sm20002659f8f.16.2025.09.29.21.15.02
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:15: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: 0afec4bb-9db4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205705; x=1759810505; darn=lists.xenproject.org;
        h=content-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=MBpejQiq0e/vydo49FSQoIaJ0P/BjZpeA7dR40L/9NI=;
        b=CEWYI7sWfgToYfH3zNpYS3Y+8F0dVEJD689lzHHWBgt2kMJlxJTwUbLqrYsPrxGHzK
         gkg+ax1/tA6XFnJrERGORi1hRXLc+go8OKX70Re46URM2qEnytrYis0R2Jp2JAgmZrBf
         JHWA9P6Wzf3/9s2FePXBVirSeimC5iU2g+EVy4IiTs4+VIv1Tclt+yD2Zd/XPJbAV6EX
         ffOo6DvZ/5ftCi35Bxna7AbztCQ+aADOP6PZqWj71MTwFGdrI2wtBFeBtZh0X54hm4t3
         GjIOr22Tpdi873iuIOGvje2M1DktQhcqionkBcFtGG26EjIklp9UHFTKNrcRPXwmwngC
         C1pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205705; x=1759810505;
        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=MBpejQiq0e/vydo49FSQoIaJ0P/BjZpeA7dR40L/9NI=;
        b=xBdZtQXeyCPdb+uMZcFv1OrcITMnk/R1XDyTLbznGCHn7d3R9nG5PexP8D8VRzBy61
         S2KtevPQFO6qEIPkaaGVbvYb2ylJdFFevlXynIhpNYeCtQ+9itwXbDbk4/3a3ZHzYnS7
         jQsFiD8xvuhlb2VHUKqsYSnJvVlfTcvIP8MIP2KEIpI0BkpKRGGEzT5AksawCL3uGr8e
         dOUnM5eu0C4t9H8ErXiNRxbL+XEOTvyEP60ETGVogvadiMaIDWZDugwqR2ne14q5hLFz
         crYCPBwl7qrEdhC2/lKwZladfO9w+P7MXM3CyVDjXdHc0nvIADYpFTfK3rl5DSzlvkW8
         H0uQ==
X-Forwarded-Encrypted: i=1; AJvYcCVTfYy1ka5Qi3iirimemcLO5tNyUWjYR9q/s3vbnQJMa2Tw6WcSAg36dKZjptpDdqsa6KEUmRx3QFc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygKeRi79Jbl69t4q/8Fe9Vs15B1v9VtCxqy9LnDqWRNTd9HsxG
	65E7ZmnZVFiX/f8ZcZDFbm+noa17s7WBu3Q0sg8tSBXDSDkgkHYdfdzB6y6SNRVMorY=
X-Gm-Gg: ASbGnctAvYWEtrInCGO4eRKv2ep7HerPWj6WU0vs4jR1nkdbngLu8PqZbZeJXiV1cR7
	QaLqpANiM8e2B0h8zF6ncVxOf2EWdxGdXnQMntfUjhZ25v4zVY+isnXr1rFyNmU2wYxmqrdUcOL
	eT+7LJV0jFuqRnC+/CdBhU/F5yvjplFcFdbJKqPfz6hMUb33qEhg/UsZCGXY/bsxpfsW2PPvjFF
	3JpPcqO8HloQHcp8P96xZjpwCbr+zbBsIHlkFX5VYrQYVcQIQld5CckeBuefRNOD/u+o6f8rKwB
	3UeL2150xvjs44XFbUeNecbCepfa7Y9gg9JqhNpnEW6t5h8omn42Bck21TOfMmcjkv1AQE9Opwz
	b0mL4h+U3qzuSESkPmMBELNuI0mHBo9AJTYmEz5DpjqvnEFL4qw0vOpWEqP7OPjtywkhbG8ns0T
	ebsWwv6/GejLp3mb/GUTkfGt8s+rjcbrs=
X-Google-Smtp-Source: AGHT+IGgqJ0JuJ77y43D9HwYeERomJh5OkTJMDKGyPclR/IBy8JcemLZxj5L2abT5KLJLVAD5Z41ZA==
X-Received: by 2002:a05:6000:2385:b0:3da:d015:bf84 with SMTP id ffacd0b85a97d-40e481be8a9mr20254181f8f.25.1759205704783;
        Mon, 29 Sep 2025 21:15:04 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 16/17] hw/virtio/vhost: Replace legacy cpu_physical_memory_*map() calls
Date: Tue, 30 Sep 2025 06:13:24 +0200
Message-ID: <20250930041326.6448-17-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Use VirtIODevice::dma_as address space to convert the legacy
cpu_physical_memory_[un]map() calls to address_space_[un]map().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/virtio/vhost.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 6557c58d12a..890d2bac585 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -27,6 +27,7 @@
 #include "migration/blocker.h"
 #include "migration/qemu-file-types.h"
 #include "system/dma.h"
+#include "system/memory.h"
 #include "trace.h"
 
 /* enabled until disconnected backend stabilizes */
@@ -455,7 +456,8 @@ static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
                               hwaddr *plen, bool is_write)
 {
     if (!vhost_dev_has_iommu(dev)) {
-        return cpu_physical_memory_map(addr, plen, is_write);
+        return address_space_map(vdev->dma_as, addr, plen, is_write,
+                                 MEMTXATTRS_UNSPECIFIED);
     } else {
         return (void *)(uintptr_t)addr;
     }
@@ -466,7 +468,7 @@ static void vhost_memory_unmap(struct vhost_dev *dev, void *buffer,
                                hwaddr access_len)
 {
     if (!vhost_dev_has_iommu(dev)) {
-        cpu_physical_memory_unmap(buffer, len, is_write, access_len);
+        address_space_unmap(vdev->dma_as, buffer, len, is_write, access_len);
     }
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133503.1471646 (Exim 4.92)
	(envelope-from )
	id 1v3Rma-0002wt-Ab; Tue, 30 Sep 2025 04:16:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133503.1471646; Tue, 30 Sep 2025 04:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rma-0002v7-5N; Tue, 30 Sep 2025 04:16:08 +0000
Received: by outflank-mailman (input) for mailman id 1133503;
 Tue, 30 Sep 2025 04:16:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Rl7-0006tq-3c
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:37 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f9eac94d-9db3-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:14:36 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-421b93ee372so863903f8f.2
 for ; Mon, 29 Sep 2025 21:14:36 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc72b0aeesm21288982f8f.49.2025.09.29.21.14.32
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: f9eac94d-9db3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205676; x=1759810476; darn=lists.xenproject.org;
        h=content-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=onCfEhinWarPReSMP2g+nvBYz1NYywUR3fuXcFIYVYM=;
        b=qUMVFovuwwEM0MouPOZLAmN8/fXpO51T6uDuWnFsUn9Rd5EaopI0zTwzslaimDS/XI
         fs780cVFN/rvWKwI9lMi8GaWeERy5Ln6qHA9i+mDLF1a6xglCTBCsvM1AizId9yXkXLc
         qc1WtWmmARzoTXteSf1rKe+GSzOEVCTbz5fvUZnas6rAggCDTDg4kUcrpNC3NSDQ5Koa
         U3o71jrYPDLoXz7w0PAcWYEi52d8iKQoT1zouX/bEY9z4MBMktOqTB0Mx4inkTbDubtS
         PHttfarWMkO0fGgr4hhu7oFjKoWG/P1En/yv/g9njv3Bn+Jdg/gkGuwUHtRM9kdkQILz
         MlUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205676; x=1759810476;
        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=onCfEhinWarPReSMP2g+nvBYz1NYywUR3fuXcFIYVYM=;
        b=vBVrpScJR8t8vA5yXCENu+ikKXkcPGm8ELkl4RQAfDL0cpfDJxx9UvgTogfYXiT262
         puLzsLMBIsEqXCN6XEt7rMBXd2aN/8+pxsVALvWF1TZOHYspyEhHsEQi6o5sq5RZfHNV
         me8kK6Ceye0y9t2XGaLMppF/UTqL2qYNaAf3/zcsco6lvtnzOGmQMYadsIOffpShd0Y7
         /LA1tjuzjdJPOjw5UzjRNnXXKoJmEEwb4RnmPiVqxO9QX1eUNhBbQA0GVgZbg61POo7f
         DEf5JwOwqmCc1iBYA5jhoQ2K0Z28i/GqgCkJCxoysletvYHOtf7Ecjlq12RNp1JTRnoK
         ok+g==
X-Forwarded-Encrypted: i=1; AJvYcCVcIlS7h9s4IGvMzVDmSsnPpOzSmr7WUGiQAgh8/fJgzrfL5t/UQpXNvad1yEabfHUBEcft/f3f44U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0Xlu39DPqX2VWL3VC/CDNUBqU3cADn/srUNKUEGHG4dKc1Iig
	KLn3FwzOqonCD7CVXa4d4DPoAL5lTtyt+pr9cFujcnTImmMQQT/+KwIuijXbdZTvfbQ=
X-Gm-Gg: ASbGncsPz+exIPkBSEA3wOlHha1uzYb0KgtsyRPE9OL+4DZmW5K0cJnOlh7c7H4No2h
	ZVoeGLUYR7WamgrUTimieA3NQNEDMsTzczpGx835GP8gZHfjWLWbfFJte/qqupp4gifkC3YWvhj
	m5Eqpiv18ISyytdLK4tqj93bCjJG2lHCG3wKnBXnrqW7kDio8AiA1KOEU9Gpq29qryJtedQjKjB
	pc0vSAeNNFjf5qO60XEOwDRuHiIjw3+DLAXtN0KtASLqBCL+inRp31fx9XqWPvh5/J0bHzWKGXH
	oiZ/RhKI3V0NfpbF+1f0WTq3/VF2HPMlCj56Rp+w2HFR/G9n30BZE1GKiYzJku6+jZ4xjs7T5Lm
	SPKizbbNPamcdfqzVMrkjLhjBr/KJv5KQ4sU9asao22aD80VSUurqG2hzsiPIXXqk58hTmfVoc6
	ssl+Wrp/GSxK8Zm2sriiCVUJ9c48uPz2lHZxTHmb+F/A==
X-Google-Smtp-Source: AGHT+IHXSt4CkpBPH+1BT7FZNZBNpbDyORtYFCRXPSlc1PSaGA5no80rsQKq3Agt1aNkmXQ30vgX3Q==
X-Received: by 2002:a05:6000:2689:b0:424:2158:c1a7 with SMTP id ffacd0b85a97d-4242158c3cbmr1203705f8f.34.1759205675919;
        Mon, 29 Sep 2025 21:14:35 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 11/17] target/i386/kvm: Replace legacy cpu_physical_memory_rw() call
Date: Tue, 30 Sep 2025 06:13:19 +0200
Message-ID: <20250930041326.6448-12-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Get the vCPU address space and convert the legacy
cpu_physical_memory_rw() by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/kvm/xen-emu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index 284c5ef6f68..52de0198343 100644
--- a/target/i386/kvm/xen-emu.c
+++ b/target/i386/kvm/xen-emu.c
@@ -21,6 +21,7 @@
 #include "system/address-spaces.h"
 #include "xen-emu.h"
 #include "trace.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 
 #include "hw/pci/msi.h"
@@ -75,6 +76,7 @@ static bool kvm_gva_to_gpa(CPUState *cs, uint64_t gva, uint64_t *gpa,
 static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
                       bool is_write)
 {
+    AddressSpace *as = cpu_addressspace(cs, MEMTXATTRS_UNSPECIFIED);
     uint8_t *buf = (uint8_t *)_buf;
     uint64_t gpa;
     size_t len;
@@ -87,7 +89,7 @@ static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
             len = sz;
         }
 
-        cpu_physical_memory_rw(gpa, buf, len, is_write);
+        address_space_rw(as, gpa, MEMTXATTRS_UNSPECIFIED, buf, len, is_write);
 
         buf += len;
         sz -= len;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133505.1471652 (Exim 4.92)
	(envelope-from )
	id 1v3Rma-00032M-RD; Tue, 30 Sep 2025 04:16:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133505.1471652; Tue, 30 Sep 2025 04:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rma-00030P-Ht; Tue, 30 Sep 2025 04:16:08 +0000
Received: by outflank-mailman (input) for mailman id 1133505;
 Tue, 30 Sep 2025 04:16:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Rkn-0006gD-Lk
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:17 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed3c61b7-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:14:15 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3f0ae439b56so3186335f8f.3
 for ; Mon, 29 Sep 2025 21:14:15 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-41f00aebdb7sm8027318f8f.57.2025.09.29.21.14.12
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: ed3c61b7-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205655; x=1759810455; darn=lists.xenproject.org;
        h=content-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=cfNLwv+i5cO84zMF6diWkvUfOapkzoMYrwwz0ZMfYgk=;
        b=V0Vm0dmJHbrJsQLbxiIsULltqLBaccvIHkWjB12avgOrsQGJkVPakuzVTMII9JX/gt
         n3i7LHrK5Ph3ultX9jktHyvq7Itn1oq408vljBmvrqOfxbgcFzTwICZX4fiVkwt9Jtwu
         eyi71NSEZz1Vtpk+91kdaM1SefnnmAWczZyh8hcoSQZwUq7AbdmhXR1XmRqPYU5j5GS4
         8ql/HTkL1nO+Zo2PcaARyrpcEoC1ub0T8bin+Nun32ew8Rofrk6yYTXsjXbeX6hLcefl
         G+v+nh6twl1oMszVWn6FezpoWZ46bAZV0Yp3lhVPGFSNhI87VA8KXdNvy33GBK8g4oZr
         Q9gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205655; x=1759810455;
        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=cfNLwv+i5cO84zMF6diWkvUfOapkzoMYrwwz0ZMfYgk=;
        b=SWOC9HgwKgODXZoIr/fEo3KRBkQ1h9rlGMC/CM84nvt81zH49SnY/GnkEY28tnQhim
         QZInCsgMA6bM0Rrw3RAdEVZzx9pdxReCIvzrpnJm0KZ6+BIKqhuCQ+jEY8AokztdNcd5
         rFMEeKPcpZz8GU9NmYNXGtoNXZMFv0JWvvja1ojHDP1OMpxzb2rRNAIcJzzkfUA9SfBo
         gX/2XkdbUQHC6SI2pxQBxMIn4inr9LD//YZrr7cNdFDuOvVXH2+m/cjvq8y5TWNiZWS5
         UOiDQmtHd6wHcjrM5KDIBpEa4RNYlRSSgw2kZ+73lfa63Dzq8OnYI6xxhqkeGNwpuhO0
         Dcvw==
X-Forwarded-Encrypted: i=1; AJvYcCWes5RD/tCZB0DZG24fUymecXUla09ZxirSCWwG4UThUJv1wDTHvWDoremPfvX8CX2V4gP8v0/uk4w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzIKQa7jcnGzAfTMG30+1hSClK5WjGtc+y9goe8NFVqIFUMmrms
	rrSRi21Lb7Qw+lpWWkWIVpjKzZoQUfGPiEWdXNt2UqCOBsrMdRI6lHwfOtEnkNo135w=
X-Gm-Gg: ASbGncu5xj+GpcOqaA0SPjKNpyYLP2HOVgBtI5NH+Ma2ix5oG3uPYKzpiDR0hmyZ/dy
	+KzAtPRomOMFyPzGeBXGvKnVYgs5HsXfmCwSyIe/LxFTdihJSEEeQYC7KfJVznlY6ElLNJyXnQw
	M3MSrQ5nBCtss9IJ69VHeSalgi5sycJ+kkeqQcQSU3T0kE49xI8XGjqgZHjsYAUJeEzU1q/aCbc
	Ag90SOL8ySQJtuffUOMQVP4pzswfe7qKYw6vXzGQzHV27Lrgcmm+au/twyhujnVkXjgU7f29DZG
	ZlH7CrD4PZZoMRYzNzDvkrfstaXlImU8i86ppxxrX6jLCaib5dqYlMXg4CnZHItwqxzBwI6vzk9
	z/jL73OkiCRp1itMiTU5bG5+uxE+E2s8P2kfUMDVJDB2gNLVhc11JfHX//zd5BsWmEAqGzCPa/Q
	/pmcMM3Uv6q81TkOOHUs9F
X-Google-Smtp-Source: AGHT+IHP/zG4X6xn4hUDdclB/D1afSsyjXOgC/ThtRrRCj048iTFTeDxSXkrbhWZePrU5zQ+WKtYTA==
X-Received: by 2002:a05:6000:1848:b0:3eb:8395:e2e0 with SMTP id ffacd0b85a97d-40e4b38923emr16718454f8f.51.1759205654828;
        Mon, 29 Sep 2025 21:14:14 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 08/17] hw/s390x/sclp: Replace [cpu_physical_memory -> address_space]_r/w()
Date: Tue, 30 Sep 2025 06:13:16 +0200
Message-ID: <20250930041326.6448-9-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_physical_memory_read() and cpu_physical_memory_write() are
legacy (see commit b7ecba0f6f6), replace by address_space_read()
and address_space_write().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/s390x/sclp.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f507b36cd91..152c773d1b4 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -319,7 +319,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     }
 
     /* the header contains the actual length of the sccb */
-    cpu_physical_memory_read(sccb, &header, sizeof(SCCBHeader));
+    address_space_read(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                       &header, sizeof(SCCBHeader));
 
     /* Valid sccb sizes */
     if (be16_to_cpu(header.length) < sizeof(SCCBHeader)) {
@@ -332,7 +333,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
      * the host has checked the values
      */
     work_sccb = g_malloc0(be16_to_cpu(header.length));
-    cpu_physical_memory_read(sccb, work_sccb, be16_to_cpu(header.length));
+    address_space_read(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                       work_sccb, be16_to_cpu(header.length));
 
     if (!sclp_command_code_valid(code)) {
         work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
@@ -346,8 +348,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
 
     sclp_c->execute(sclp, work_sccb, code);
 out_write:
-    cpu_physical_memory_write(sccb, work_sccb,
-                              be16_to_cpu(work_sccb->h.length));
+    address_space_write(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                        work_sccb, be16_to_cpu(header.length));
 
     sclp_c->service_interrupt(sclp, sccb);
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133506.1471658 (Exim 4.92)
	(envelope-from )
	id 1v3Rmb-00039d-Gq; Tue, 30 Sep 2025 04:16:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133506.1471658; Tue, 30 Sep 2025 04:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rmb-00038l-35; Tue, 30 Sep 2025 04:16:09 +0000
Received: by outflank-mailman (input) for mailman id 1133506;
 Tue, 30 Sep 2025 04:16:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Rkt-0006gD-1o
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14: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 f0d7c145-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:14:21 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ee13baf2e1so4220066f8f.3
 for ; Mon, 29 Sep 2025 21:14:21 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb74e46bcsm20884752f8f.8.2025.09.29.21.14.18
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0d7c145-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205661; x=1759810461; darn=lists.xenproject.org;
        h=content-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=JRsfrHQBMjnrXhlxfeiXrXfyISPq/9LUWh417J9QSAY=;
        b=HmQDEgd0WLroLb9N28GnwNptCIEWEgi1qt+7DGtYwOs0AymCIuxDUB3KwrhmrW9Vq+
         L+Kwbw5MN+9fd3uHtxJr1hpIp7QmTkNRuLDLTLgZ3ywCl9gz9TZS/hQev0YInkWcDOIl
         BXwaSjXLJ9pRMI7FRVXZJ+zAUy+yA76DhNeEdhFKEm95OYL7+1JDRjR6zUfLq6HIPjJA
         kQcfJbQURI8sM8GkXrrjGr60P8fIkD8GHhIqP6gFtgbnzNuhuaicuS3N7RLJF2UlnwEd
         PYhDABqv1EeOWccjhZyfWWCxYQLwiyZE3EdNoEDnqlHlNTVdyYeqfkKw+1/cstIX30UR
         Xk2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205661; x=1759810461;
        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=JRsfrHQBMjnrXhlxfeiXrXfyISPq/9LUWh417J9QSAY=;
        b=VpqKDAO7gIG+cOedTEefgOIuOxTmnHYDKiq+HMFlzPgQ7ArjJOnzuouKGz/sEhjzZA
         Yn5e+dYy1Ixh5HNbW6GJhDTGFkQCfz8rKvwX7+1XZ+6iC3Ux4FHtCZ88q5Y3qH8mJD8L
         buJ4XVUcT8oMIu28AbkmrD3SxHA4yPw2p86Ojlj6qlA7aEd34zDAPVEzcx18AKtAT9au
         INPzHsaLkMjBUo2p3yd6XOFeSqYPT+ebBjMNdF0ogP7RWIbmf+7fuZPia8p2IQz928Mm
         +4SkDFOEFO8cJgkqavRo7RL8E2YPblAaqC3/WgTDr3ejBhq+Vrq+6YoD1qlb9axutrTF
         AqpA==
X-Forwarded-Encrypted: i=1; AJvYcCVTdjiKXyym8DzfWx+cBqetmIkqFK4O0qyUVW0DNpDJ641YYRXWDWlUqFB+CsoDCrWYYj37DliEZ8E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWCuByY3ZzVNEvqq2GA46NEB0t6FjRn4na2p8gKd41ZrhkUxAa
	oNwjxJPbTWheE9nKQY4RszEnE+iLUfkIM7GEwaFIj6mqz/eJa/YONCW46o0eyjpYtJk=
X-Gm-Gg: ASbGncu66iWtkpyq60BMRlfdw9AwbRs1Qf7F320AkVNAvBrIHYIaqOzK+xSsMgKRLkU
	fb8J4Scj4PdpIX/xfSNXzoHcXZNbcT5KjGAsDJjP07t5xWtqMEtFAYAUJpnYDLu4y2TcGmUExL3
	DLpxR8KqECQj6Ody7h1L9iBggoQdUmacrXgLiWvB5PYbWIknKNd2U6V40JDG6ZO6BTpbT/KRVpQ
	TDMRVSejE4q65wvVpYjlhiHzvJBdncpy6SPa/Vpjl8Gofp5N5dtF4QAGXwOdvb2feWD7SDajxR+
	xZDcglIC0scs2TZZK1K8qbvCuLzel6GIYe0sdLuZsu7E6sre14HNCgiuEGuFGX1ZYOa+R24s3iR
	yiP4ZzARyl1b3Rn88+k+huStB9Xg3U30viRRJmeE/DuK3mw/RgXZ52beLTlO5X6uD38iakkkGBK
	xBzCrxpNf3nT47J82Y2dC6ruClKyDDjhY=
X-Google-Smtp-Source: AGHT+IEAmcRaAQ7y3JKYkZc+1B3lBRPGfbSyTbOeVCtcFaGQrh4be0IXziHu3DKBh/h2DslEMGPKwA==
X-Received: by 2002:a05:6000:2dc9:b0:3eb:c276:a362 with SMTP id ffacd0b85a97d-40e3d69c099mr16747038f8f.0.1759205660946;
        Mon, 29 Sep 2025 21:14:20 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 09/17] target/s390x/mmu: Replace [cpu_physical_memory -> address_space]_rw()
Date: Tue, 30 Sep 2025 06:13:17 +0200
Message-ID: <20250930041326.6448-10-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When cpu_address_space_init() isn't called during vCPU creation,
its single address space is the global &address_space_memory.

As s390x boards don't call cpu_address_space_init(),
cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.

We can then replace cpu_physical_memory_rw() by the semantically
equivalent address_space_rw() call.

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/s390x/mmu_helper.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index 00946e9c0fe..4e2f31dc763 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -23,6 +23,7 @@
 #include "kvm/kvm_s390x.h"
 #include "system/kvm.h"
 #include "system/tcg.h"
+#include "system/memory.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
 #include "hw/hw.h"
@@ -522,6 +523,7 @@ int s390_cpu_pv_mem_rw(S390CPU *cpu, unsigned int offset, void *hostbuf,
 int s390_cpu_virt_mem_rw(S390CPU *cpu, vaddr laddr, uint8_t ar, void *hostbuf,
                          int len, bool is_write)
 {
+    AddressSpace *as = cpu_get_address_space(CPU(cpu), 0);
     int currlen, nr_pages, i;
     target_ulong *pages;
     uint64_t tec;
@@ -545,8 +547,8 @@ int s390_cpu_virt_mem_rw(S390CPU *cpu, vaddr laddr, uint8_t ar, void *hostbuf,
         /* Copy data by stepping through the area page by page */
         for (i = 0; i < nr_pages; i++) {
             currlen = MIN(len, TARGET_PAGE_SIZE - (laddr % TARGET_PAGE_SIZE));
-            cpu_physical_memory_rw(pages[i] | (laddr & ~TARGET_PAGE_MASK),
-                                   hostbuf, currlen, is_write);
+            address_space_rw(as, pages[i] | (laddr & ~TARGET_PAGE_MASK),
+                             MEMTXATTRS_UNSPECIFIED, hostbuf, currlen, is_write);
             laddr += currlen;
             hostbuf += currlen;
             len -= currlen;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133507.1471666 (Exim 4.92)
	(envelope-from )
	id 1v3Rmc-0003O6-B0; Tue, 30 Sep 2025 04:16:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133507.1471666; Tue, 30 Sep 2025 04: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 1v3Rmb-0003LK-TY; Tue, 30 Sep 2025 04:16:09 +0000
Received: by outflank-mailman (input) for mailman id 1133507;
 Tue, 30 Sep 2025 04:16: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 1v3Rki-0006gD-1B
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:12 +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 e99a04a1-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:14:09 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3f0ae439bc3so2702479f8f.1
 for ; Mon, 29 Sep 2025 21:14:09 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e5b69bc0bsm5141855e9.3.2025.09.29.21.14.07
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: e99a04a1-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205649; x=1759810449; darn=lists.xenproject.org;
        h=content-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=uk5+wyHN7CkT7HC+T4CiL8GLFFBvq7A2wJEeem4enV4=;
        b=eWdKJLfb2akGaqL0w5RBNmdQBGpZMIrcpsdg1SO/rsjS4blWeOjCUQ21OXhZV+dRC1
         q+donle6dNBA+YjLvUeunSxgrut1/wH/ugY1GRw+ws6XgQ+B/sJzGAbZhDWT0Y15AJmC
         Xw+nqTlUPKU19Oh3CY+gRZb2rmEGgerytEBm5FebAhJcHGh9OEqm2LrlCrCjE9BZFrs5
         Ywvv/jllfm+naevyepYz5xtobfguexr9xxa+lTsF5EhfqTM2+PXIrlqPOCcA/017jQ/j
         FuxYDqOsDj4RdHy+/I5ZWHbnT1AaU6brFbnJU/4iqP1L1dWhBWDgR+wHVj6Z40TfKlDK
         MqoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205649; x=1759810449;
        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=uk5+wyHN7CkT7HC+T4CiL8GLFFBvq7A2wJEeem4enV4=;
        b=psmpZcKfxd6uOX9MN4cUK1+9Ig4jwtpXI872qFh8e2yvx5aXTMpxNPzqptDXh2336j
         vZQT/B2wFdK680Br91jOP9zM7oqKIkk+rSShde0ZeI7UwQ6mX5glGCcfTWNBSpUL4hfx
         WLbOyC6ZhkTvlh+k6fMXcUvJnuVepLIt9/6AB6YhJpw8tFRiLKn1JPp9zHoozd9LjSdb
         6BMB6gXPMBchWJ/wI+azbudihaBxuEALKJ9XqIdSJxEBKn6DYW8KEqVxw+M/YlVaLv4s
         8sNPdG0dTRC/fZp55rl2kKlVdejDFwY+C+KyvkELnYK6t1vfvK9gtWzkFyT7FrAaQMaA
         Mq/Q==
X-Forwarded-Encrypted: i=1; AJvYcCUK9bhMb0JksMX7zVfMbfOBd7T/uHuGm/1x1y8+gCxEWV6tvCSia3aWLRyL1EWubfsQ4e1SWLpr2RA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysXyb/D1kO+C2hnqxWBliazXpIPJ1VcAzlfdDeLTS8j/gHftVu
	vPNex9EpEYz7+gLv6JyB352UlaLR/Z23+5uf7xL+xYY2mYSuQQ6UcaZCykvJduyHo3I=
X-Gm-Gg: ASbGncu8Rv4kYZqq8IeulPQFWeTOMmBYSgzOFsKpmbXpP4FSkng+fZ8wDcCC4Z3+Fun
	td3B4OJtp098Kvy00zG5FBALlovSKf5Y71FhTQxdk451BXI4i3b9jgVfVMgIar5gelryFzNqz9h
	ThgPewwALNbPz5bV5WL41B8FfIKNsjjA2NLsARSEBjiwmqf/s4spQsoWCMmZAOWP54SzrJVKEuD
	OMIQmwo7E8nyoMdZ0IDCU4xZnt9W5qau/A01RfHF7QMVx6PBT4EAY7yKlp94WgxQhHKAH+HQpUb
	mDeiv98UenLYoIrNYyXWKpLmMLU7C4/w5S3+mxe799WJVzgio2YXNkolbUH4rlsEEa34LJ3Ig96
	TANgMqFaCylL0+d/yvXE39NY4/1J6CLmo0WBrVA6OyXS/KF/NN+0ukP9yExLvLOVWeLv+e/iHxB
	Mjg7uozcKsQBORM96r8XAWXRcDUWGgze0=
X-Google-Smtp-Source: AGHT+IHVwaY6Q4s0F84QmaOmJAx4BK9ueW3Bbg0HpiOJvzkr7RtDJkQ0plXWj1SaEJLGINz1Ov7KPQ==
X-Received: by 2002:a05:6000:3101:b0:3eb:5e99:cbbc with SMTP id ffacd0b85a97d-40e458a9394mr12531634f8f.9.1759205648705;
        Mon, 29 Sep 2025 21:14:08 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 07/17] system/physmem: Pass address space argument to cpu_flush_icache_range()
Date: Tue, 30 Sep 2025 06:13:15 +0200
Message-ID: <20250930041326.6448-8-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rename cpu_flush_icache_range() as address_space_flush_icache_range(),
passing an address space by argument. The single caller, rom_reset(),
already operates on an address space. Use it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu-common.h | 2 --
 include/system/memory.h   | 2 ++
 hw/core/loader.c          | 2 +-
 system/physmem.c          | 5 ++---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index a73463a7038..6c7d84aacb4 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -156,8 +156,6 @@ void cpu_physical_memory_unmap(void *buffer, hwaddr len,
  */
 void qemu_flush_coalesced_mmio_buffer(void);
 
-void cpu_flush_icache_range(hwaddr start, hwaddr len);
-
 typedef int (RAMBlockIterFunc)(RAMBlock *rb, void *opaque);
 
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque);
diff --git a/include/system/memory.h b/include/system/memory.h
index 546c643961d..dfea90c4d6b 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -2977,6 +2977,8 @@ void address_space_cache_invalidate(MemoryRegionCache *cache,
  */
 void address_space_cache_destroy(MemoryRegionCache *cache);
 
+void address_space_flush_icache_range(AddressSpace *as, hwaddr addr, hwaddr len);
+
 /* address_space_get_iotlb_entry: translate an address into an IOTLB
  * entry. Should be called from an RCU critical section.
  */
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 524af6f14a0..477661a0255 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -1242,7 +1242,7 @@ static void rom_reset(void *unused)
          * that the instruction cache for that new region is clear, so that the
          * CPU definitely fetches its instructions from the just written data.
          */
-        cpu_flush_icache_range(rom->addr, rom->datasize);
+        address_space_flush_icache_range(rom->as, rom->addr, rom->datasize);
 
         trace_loader_write_rom(rom->name, rom->addr, rom->datasize, rom->isrom);
     }
diff --git a/system/physmem.c b/system/physmem.c
index 573e5bb1adc..70b02675b93 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3214,7 +3214,7 @@ MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
     return MEMTX_OK;
 }
 
-void cpu_flush_icache_range(hwaddr addr, hwaddr len)
+void address_space_flush_icache_range(AddressSpace *as, hwaddr addr, hwaddr len)
 {
     /*
      * This function should do the same thing as an icache flush that was
@@ -3229,8 +3229,7 @@ void cpu_flush_icache_range(hwaddr addr, hwaddr len)
     RCU_READ_LOCK_GUARD();
     while (len > 0) {
         hwaddr addr1, l = len;
-        MemoryRegion *mr = address_space_translate(&address_space_memory,
-                                                   addr, &addr1, &l, true,
+        MemoryRegion *mr = address_space_translate(as, addr, &addr1, &l, true,
                                                    MEMTXATTRS_UNSPECIFIED);
 
         if (!memory_region_supports_direct_access(mr)) {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133509.1471672 (Exim 4.92)
	(envelope-from )
	id 1v3Rmc-0003VU-SZ; Tue, 30 Sep 2025 04:16:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133509.1471672; Tue, 30 Sep 2025 04: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 1v3Rmc-0003T3-Fd; Tue, 30 Sep 2025 04:16:10 +0000
Received: by outflank-mailman (input) for mailman id 1133509;
 Tue, 30 Sep 2025 04:16: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 1v3Rl1-0006gD-2n
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:31 +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 f5a3da19-9db3-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:14:29 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-46e3a50bc0fso35640445e9.3
 for ; Mon, 29 Sep 2025 21:14:29 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb89fb19fsm21119525f8f.21.2025.09.29.21.14.24
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: f5a3da19-9db3-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205669; x=1759810469; darn=lists.xenproject.org;
        h=content-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=DbEYNZgIU6LqvkF49qge8kIj2C3i6K2S813tsyxbWwg=;
        b=izft0kXPG8+lY2AhHFMPIt8Un8AF4FWb78ynbnWcga3TWcqxss+VMu6KXARK5elnvc
         CGvKuKHGhD7QevC2ohhm8GzwaYLTtOpgzE1IcMnSQeiX8uuxNHq3JVBsHsap9Ux1ImA6
         zLkCo5i7X8KvGIVIX9aF50k71tlVudbmG9qMfNEMsPZDKKt8bhPCcTb9Y5CC7W9VkcWi
         AzVKa+X4vx/bjNY7OZXqE3mKOOdYewIaw9f4L0ArWHQoI8DVqI8kcHzmsN8H/sjlCVRP
         Mio/li2HeTgy1OP53GMMuQ+CwELTUaXfIksUShxndJceouF8goDE7kY6jSfX/spUYtDJ
         8Yig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205669; x=1759810469;
        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=DbEYNZgIU6LqvkF49qge8kIj2C3i6K2S813tsyxbWwg=;
        b=XZi5/0OXeV2voQY1YRkhA3p7sBihHUyw8+L0bq658l8KOvwN89DjMw8Ew0+bdB5lPj
         PAkBZHySlvbf0SYPwAu6MpWwQTtsu8eU6cgnh0JrgciUAkU/OKUNBiv3cxVnmrCtpBoh
         LkgK097n/tKTxTgGw0hRKuaUoh0ks06Wl+h0wU0eDFjmet4i0AH84BSFORWz5qq1UXTS
         qTeyRYinBf06L39aZadGy1Ba9evR0BYqDz4phDll/yYcc7rRfxl8ezW5HogmqKazJ0fR
         zebmMSktTNPd3LA4bzJthX/evz+jlYj67zo3KDXWnwNHfJCSDDvy8CYCc50PMQdTYcak
         Rpmg==
X-Forwarded-Encrypted: i=1; AJvYcCXQWymrfQmF1eVy5Zo6rzxSgkK68RqjWdyFgzh1m2T7OFmS4wJa3QwQDU6i/nP2VJo6pqBDeUWcCyQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcRX743oKDLJJeRbEAep2L/UjasiufKGULKfKq1SfnFz8xVlni
	1q3OV6uTAizVPGExP2ib2kVlJpwQegbaL9HQjmv3Ch0ZLjspynb3Cm2kt+HkKvn2oeo=
X-Gm-Gg: ASbGncvG5iFFbuPZympcGasXPTPWK5ux1MLbVWEtAtkJ5JSkxTu5IHXwSU+ef/Wboj6
	Dp/Q+05r+o+75XPHizGTxbnrGQsqVUpjUK3n3+GYDPOA8skj25pO+q9PUcGxu0ypPINEtcGjZM1
	MzHRWOTV+Zjek4x/KMtS6fUJdcDskLuoLJNj4pA58BGW3vlisKD+KKu6CRsrHkcgl0kGycJJi1s
	R5uhYkphKGEnFNFmDisqqJqkJKhmFNSO1DzIiUU5Oyy134EAtLY/xqAvVUNsEuXTdUiGC+SKeza
	N6jiHCGZYrGcs54rgFGgOsO6/A6BU7C36i32AucItdFtCIYiAPdnLvh5uDGEmJW7donl51N0Sqc
	Qr5UW+2I2rRBwuKYMUCLtE5Y7bGdmgT75fXTRmYop6bLwcbfqlCNilI6PuJRcRVGmx0rGfv9drx
	3lD3MatbrXHEmWFMAHGmKAU+Ysa7mAnCw=
X-Google-Smtp-Source: AGHT+IGQV+zsO38iVKo0msrSbqnR/OPqPQnfcFKxd1s907Qhohb0/U7DrOdOWLv1d/ID8PieNnQk2g==
X-Received: by 2002:a05:600c:871a:b0:46e:477a:f3dd with SMTP id 5b1f17b1804b1-46e477af5c1mr75062075e9.36.1759205669015;
        Mon, 29 Sep 2025 21:14:29 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 10/17] target/i386/whpx: Replace legacy cpu_physical_memory_rw() call
Date: Tue, 30 Sep 2025 06:13:18 +0200
Message-ID: <20250930041326.6448-11-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Get the vCPU address space and convert the legacy
cpu_physical_memory_rw() by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/whpx/whpx-all.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/i386/whpx/whpx-all.c b/target/i386/whpx/whpx-all.c
index 2a85168ed51..82ba177c4a5 100644
--- a/target/i386/whpx/whpx-all.c
+++ b/target/i386/whpx/whpx-all.c
@@ -788,8 +788,11 @@ static HRESULT CALLBACK whpx_emu_mmio_callback(
     void *ctx,
     WHV_EMULATOR_MEMORY_ACCESS_INFO *ma)
 {
-    cpu_physical_memory_rw(ma->GpaAddress, ma->Data, ma->AccessSize,
-                           ma->Direction);
+    CPUState *cpu = (CPUState *)ctx;
+    AddressSpace *as = cpu_addressspace(cs, MEMTXATTRS_UNSPECIFIED);
+
+    address_space_rw(as, ma->GpaAddress, MEMTXATTRS_UNSPECIFIED,
+                     ma->Data, ma->AccessSize, ma->Direction);
     return S_OK;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133511.1471681 (Exim 4.92)
	(envelope-from )
	id 1v3Rme-0003ic-3m; Tue, 30 Sep 2025 04:16:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133511.1471681; Tue, 30 Sep 2025 04:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rmd-0003ds-Bj; Tue, 30 Sep 2025 04:16:11 +0000
Received: by outflank-mailman (input) for mailman id 1133511;
 Tue, 30 Sep 2025 04:16:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Rlf-0006tq-2Q
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:15:11 +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 0e420c34-9db4-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:15:10 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-46e4473d7f6so23421625e9.1
 for ; Mon, 29 Sep 2025 21:15:10 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f3dcacsm39499115e9.2.2025.09.29.21.15.08
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:15: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: 0e420c34-9db4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205710; x=1759810510; darn=lists.xenproject.org;
        h=content-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=+R20KfaeepivX48ztS5Qk+Utu4Wf2nP4nwxC8R0e4a4=;
        b=Xv/gr6yTwLqgOvpmNTYhf6c5qNvdYAuPM3joeK0qrz+7BS224EumNMIVaA643XzCVO
         GG46/6S1kESHKDT1E0fhOvboy4rQHgqNGw755pOwG+TGdIsejYMlNjqiIT7aiSKDOSc2
         9RMm9j32JEAqryvE/lvQaDyY+Xh0x6HjJFbniZky2lp69f6BgjrN3uMfu9Mj6zI8ecRe
         2lTBjGO6JdJY3sWqUvJERdlhTt5rZ3hPRPvKTyQrNxAwfAtXTkW5oAl3SIoZ/yXadWEh
         Z0fqPBaPKE1+T8nky1I1IIYhzDIq1NDpPEXfZgwCWbz4X6ViuW3B44xTBw+bPtu32kc/
         v0RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205710; x=1759810510;
        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=+R20KfaeepivX48ztS5Qk+Utu4Wf2nP4nwxC8R0e4a4=;
        b=ozE65R/mE/tyyDZZUxN2pPhZpejUoB1rth+g58cEEHzmCSbkKexI/K1ihohX0DK7eC
         1vJW05jkOBmkBpm5j5EFfvLsi/DT/BbMVwor5p/u3zSD4yM9p/SmfUcV06P429HXbpAo
         m7PJ4WCD35JH8ochyDSsb/QoiTtEYuKAYUbBxsNm9/BH/KBYYKbxAtvoL3OyImOvOgfN
         CELN99pTiImD+NnkeDRXoV8yPkqd0fCzZdJwxVS9YuQObBQndJzu9IB1rRUbsJ2gD++P
         A8Dh+iXP5WsM0ZaOh8JVsOqrHI2IENDtP/psZGbgfaUjwR4YIRuLSLccA5YEdrgqwt+3
         E6vQ==
X-Forwarded-Encrypted: i=1; AJvYcCX4IoVIq+6Ku+NUyX1iiDfma29y//JHLavP9hmyxJIvU7hVTZw2fbIcAPn81ENjyntm9KHt+ciMx68=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtNOMod29coQopMbQBAOOcGvRP2RfUa8e3xMSNVGqsa4Kg6gCk
	/+QSh0k05U5tWwCrjw+cb9n1MO99MAD2y8mxJznOShhXeotbw7+gDHvJMLNU17VXs38=
X-Gm-Gg: ASbGncvAbAn3iQ0r/9CEYAgC7ag5vTqJlTtJKvSvi7EJ7QGFpFVW9EcTaRzI8TLLW51
	6BSwQDGheksLvDnM+R7VvaLdFjGtUhmGCZ5BHoGegiY/bf/8dcSRLcokHVq4u17XHfcakLjkaCR
	f4T6CXZdaTajBuPPmSBPtvgqSnJg6IMRNq4FO50nKceSW3IFai8f+3X7P1PGi9MrvCigA42hkcR
	Y/VMRtz9NcrwXcHzPq+GxRp63SFGODRvqKqU+Ty1v5chtkPQC7+iZ6EZXULBmWPtVPWt6gZtXel
	zYcx9Q1GIqO/Oen+8kCaWYaE+h1I62EOBLCM+AI0rC5YL/rG/I+g4pLLflphNkxs0DFT72b91Ed
	oisw0AdQEmjj5Vpaaxvxqmjo7mil9+3NJm8QZ10D7jZP74Ld0pzOQN7NwfbfRBIGzRuBB0SKZDg
	KmFxElVHWKdJkbK8YnXD2aTRVOFJQYsQY=
X-Google-Smtp-Source: AGHT+IEUJE1IYP/kfT6NPYb+xEkszrcjL4tSyyPjenIF9G8p6iMdA3UofkAUQEEOCpstatyYsaodDw==
X-Received: by 2002:a05:600c:5290:b0:46e:394b:4991 with SMTP id 5b1f17b1804b1-46e394b4b1emr152224145e9.11.1759205710145;
        Mon, 29 Sep 2025 21:15:10 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 17/17] hw/virtio/virtio: Replace legacy cpu_physical_memory_map() call
Date: Tue, 30 Sep 2025 06:13:25 +0200
Message-ID: <20250930041326.6448-18-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Propagate VirtIODevice::dma_as to virtqueue_undo_map_desc()
in order to replace the legacy cpu_physical_memory_unmap()
call by address_space_unmap().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/virtio/virtio.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 9a81ad912e0..1ed3aa6abab 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -31,6 +31,7 @@
 #include "hw/qdev-properties.h"
 #include "hw/virtio/virtio-access.h"
 #include "system/dma.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "virtio-qmp.h"
 
@@ -1622,7 +1623,8 @@ out:
  * virtqueue_unmap_sg() can't be used).  Assumes buffers weren't written to
  * yet.
  */
-static void virtqueue_undo_map_desc(unsigned int out_num, unsigned int in_num,
+static void virtqueue_undo_map_desc(AddressSpace *as,
+                                    unsigned int out_num, unsigned int in_num,
                                     struct iovec *iov)
 {
     unsigned int i;
@@ -1630,7 +1632,7 @@ static void virtqueue_undo_map_desc(unsigned int out_num, unsigned int in_num,
     for (i = 0; i < out_num + in_num; i++) {
         int is_write = i >= out_num;
 
-        cpu_physical_memory_unmap(iov->iov_base, iov->iov_len, is_write, 0);
+        address_space_unmap(as, iov->iov_base, iov->iov_len, is_write, 0);
         iov++;
     }
 }
@@ -1832,7 +1834,7 @@ done:
     return elem;
 
 err_undo_map:
-    virtqueue_undo_map_desc(out_num, in_num, iov);
+    virtqueue_undo_map_desc(vdev->dma_as, out_num, in_num, iov);
     goto done;
 }
 
@@ -1982,7 +1984,7 @@ done:
     return elem;
 
 err_undo_map:
-    virtqueue_undo_map_desc(out_num, in_num, iov);
+    virtqueue_undo_map_desc(vdev->dma_as, out_num, in_num, iov);
     goto done;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133517.1471704 (Exim 4.92)
	(envelope-from )
	id 1v3Rmh-0004bE-Kn; Tue, 30 Sep 2025 04:16:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133517.1471704; Tue, 30 Sep 2025 04:16:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rmg-0004a5-St; Tue, 30 Sep 2025 04:16:14 +0000
Received: by outflank-mailman (input) for mailman id 1133517;
 Tue, 30 Sep 2025 04:16: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 1v3Rm3-0006tq-FB
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:15:35 +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 1cbf9552-9db4-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:15:35 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3ee130237a8so3873877f8f.0
 for ; Mon, 29 Sep 2025 21:15:35 -0700 (PDT)
Received: from [192.168.69.221] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb89fb2fcsm22030581f8f.22.2025.09.29.21.15.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 21:15: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: 1cbf9552-9db4-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205734; x=1759810534; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+gM01wdk2UseDL4pB4Fgwz3uSs5dQf4zrjZtOq7eYBI=;
        b=rwtv5pavX2EDdtqvo0dMFC05NB43px9OYAWyAcU3V76E6ZXLK3QcaN5CUshWPEKFV8
         yLoac8rpQmYlQ2Aw+8KNaktaFsl74CePNq502svqhPZFZZuqjdiI2LdZwNo1ND/3J4Jk
         ZcQwJV2WC0dx3ExGA283/MW2r96yjKluQzG6Th5GJpAFO4knxgOc3hf0pC+9eI2L8ieU
         GHJPTt4evrkDhGo2F/J876e0gYlkGAfDXcPicC8Yp1gOdV7rwfccAvCKE8tJgxxAvXCl
         Xvca6v5gwO1RAaxx+MyhohaV4ZguF3WUFsLM4nVyOp4Pq1d0yJ/WGOzP5RYE5KEBd1Vf
         yRBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205734; x=1759810534;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+gM01wdk2UseDL4pB4Fgwz3uSs5dQf4zrjZtOq7eYBI=;
        b=abMVVNA5TWU80jEr0Ko6630pCGRfK6j+UqcVtdOAoiL3EokgkPvbXfvsYfZm6JUI4U
         4Mtmi20n3eXs4UVeE16AvEpOafaxBmxBWV2akUaUXrBH4rNYHUzdhDsdCCPsVi3anhNX
         Y2Bkj2e8dM0Xrs8+f6L4FVxTuCgHkBxTnMMoz1wJmfMAk1JZwhUND+dikadq15QI1McR
         N5cie0zIKExbHr5G6KH6lM+QatdMxmdvxSQeaVuGNeep8OdCsEf2D9bLru1z3zCI+q0Q
         T+IMVJE+dUkNNNMcy9R5XK/KwMsVYrc/Xyhq20BxgMvjj0Wikuqk3qMcKnvUXk4KhRGu
         iUoQ==
X-Forwarded-Encrypted: i=1; AJvYcCVzb9VjKQ/H2nVKCiza/LIJUf8unTWZbT/+d+RjJZ+RNupQKdfE7UsMAMO7XCc96SfUQgJLUIEIZLU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0bFfyxKIx9t7xKthlO7xrwJP6wGhLnrnArqTb9aKeb0qWuUjP
	MTE+gMULE9cDs8omvejpzj175E7P1RWjJt3LPyyaSoSysllB2sWz+tUefmhQkboWTiA=
X-Gm-Gg: ASbGncvNhah5sEtJ4Ejhd5zNNJ3TAmc2piNUIEnxcqoJVkFoW+AJHe35XSRcR11rwZL
	8idKYa0YpkRuVJrOFbBZC5pGCs1ukIF7fa3NQd2LYZmuASQ3IejCI1zNSEX4hD3CLvayyoGAMi5
	UBzB4LhInC/lMJ7iqI9fuQ6YF51F2sLiDXRR5kh4I9uBbuDyhasCPNnjqttIMVsSMUaiv85LYOS
	CZVZWCQ/OndWnhEFDwEGH9ZOp4L2J3V1mIOwXwbdwnCJ/QtoObtLRUGOiAje1sJIiLnIpjL3ceE
	vyumylXdsd9fLXrp9zrDj5qBN94p2T2Xd96HlGCNYLK6haXkM7HNGGy4UrtVg5JUHCcWjABBroo
	JEOQB+dg2kpKcS154b3k0snqdCCVZFt2IXPjZ7MEbRBqlhd9ZItqdeovsUZaPWigu5dxO6hfxgs
	Oivk/cNPsf/5PSEO16dZzl1io8
X-Google-Smtp-Source: AGHT+IG3+NO8caXmgDpmIXUT4U2a38OsXEUMyu+A/7GxYYPazyV8IqumGfAwZ8JxEPW+ODAlASvvgw==
X-Received: by 2002:a5d:5888:0:b0:3ec:dd16:fc16 with SMTP id ffacd0b85a97d-40e4bd186aamr16627860f8f.43.1759205734391;
        Mon, 29 Sep 2025 21:15:34 -0700 (PDT)
Message-ID: <95145136-7d86-4fb0-a93e-f23af9622ea6@linaro.org>
Date: Tue, 30 Sep 2025 06:15:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/17] system/physmem: Pass address space argument to
 cpu_flush_icache_range()
Content-Language: en-US
To: qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 Thomas Huth , qemu-s390x@nongnu.org,
 "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-8-philmd@linaro.org>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <20250930041326.6448-8-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/9/25 06:13, Philippe Mathieu-Daudé wrote:
> Rename cpu_flush_icache_range() as address_space_flush_icache_range(),
> passing an address space by argument. The single caller, rom_reset(),
> already operates on an address space. Use it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Richard Henderson 

> ---
>   include/exec/cpu-common.h | 2 --
>   include/system/memory.h   | 2 ++
>   hw/core/loader.c          | 2 +-
>   system/physmem.c          | 5 ++---
>   4 files changed, 5 insertions(+), 6 deletions(-)



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:16:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:16:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133524.1471716 (Exim 4.92)
	(envelope-from )
	id 1v3Rmk-0005Fw-PL; Tue, 30 Sep 2025 04:16:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133524.1471716; Tue, 30 Sep 2025 04:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Rmk-0005Ef-EI; Tue, 30 Sep 2025 04:16:18 +0000
Received: by outflank-mailman (input) for mailman id 1133524;
 Tue, 30 Sep 2025 04:16:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3RlC-0006tq-FG
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:14:42 +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 fd2839b9-9db3-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:14:42 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-46e30ef74b0so37706015e9.0
 for ; Mon, 29 Sep 2025 21:14:42 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e4ab0bf62sm98607665e9.9.2025.09.29.21.14.39
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Mon, 29 Sep 2025 21:14: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: fd2839b9-9db3-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759205681; x=1759810481; darn=lists.xenproject.org;
        h=content-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=QtU1C0M8U0OTbHcI2E95ZD2Zrsmz5/OESKETD6NudSM=;
        b=RoKdLh6ipvmHaQwd4kHXnJHj2+nO4HEKbbbM911eR6EDlVh+5b/0U3MNy2AHcHE9j8
         y3FgXKvGSS28bL7lybM0dTsKJgqs7oJrNtb3BXW46aQjYho6sZOpKFIxAS89O10av6Fa
         xtGYHk3c23IITr94wESZHN8v1e9sxiUKAhGktUHtqGZQAfKeiPmLBmgloIIphSvhUexl
         HUxSk1LM9NUo3c5qKhQYFeZl/BOQF44qdZwJsyP2ces4J9+NjuftDZ4K7Io7OJnsrteS
         0MW5+phjmfB1ouDmT1TllD2msTq0X+BdtazLBeyBeEW8O3SktBTBsXS4GsJZC4gP4XmL
         XzjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759205681; x=1759810481;
        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=QtU1C0M8U0OTbHcI2E95ZD2Zrsmz5/OESKETD6NudSM=;
        b=FV26vjIi4j8fUS8eMWnEE6RW2x9d0Hvh5nWhc6CvzykMr8aJ9F2BCikiETjuNqPWVC
         ujhV8Q1XpP9G4rYSaM/z84fdAUM/IUTo2HMKHUDB8SQJvlYu9ilZj4pGyijM8N7pI75l
         SrPcgTAV6V4/1WITdbQlD1PwObTM2TufjayR8xA5OWnvuhBvLGFe05E9nhsxVWz1bEyj
         /jRGtrMsIud9yZWwOIPgsyTcHjbRI1UG8do2wMxkb14D2uC0N+MNoQkuTfOw+stgMvxE
         fl9s89ZeATrsj825fLm2cXV/kxFUaPhqZIxQ8Vy47XNCuYZU1oAjId6DdgMR77PAaiyQ
         Cv1Q==
X-Forwarded-Encrypted: i=1; AJvYcCWBH+9dkElga6eKuQKG12glYs0I5eqG8PTdlT7wMBsP2Gf1BLXhwxjWtriuCT4jc4mbeCa1DjasO3A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+Nh2rPdXRArWRlPyfK+Irvc+qlyg1JYON9o9rFMSs+T3Iw54q
	EFmWCezA6KWLr2HXxTu3BOkos+3MlAU3/YA4A8Pwf1/0HOrnt5jHWrEqeZErp4IIuq4=
X-Gm-Gg: ASbGnctQBT1vwIRek5RYCHqxN7/1txaJ6WYNfd+Rw+3gsurKc+SpdxcDwMmYDOsTvjN
	ydWbC7F7+Yh/kJhUpku+gxqDZ9VVhSkSgnl0hwNp6meoLxkTPw7Mb2BopjfzAIGRIYVnLZWaxrv
	LbLWBB6EzHn5YHW1KUuTWOAxaQdRr975NzU0JDXNFbrisS5sOan8GouTEPLUbpB0/JJkuPNwy8S
	HwkXlS3qKYf/YkBy24ekE+ZvDz85CWDjU6yCzZDTIuNv6cMamsniTTrpAqHuO9QWBp3FE8ZMU3C
	dLzWpKaSBYp5P2jhMJpgDyRnj82xekilp+NfHYxsc4JizXLWxFsazqccZqweUB1aGIFgmDNJ0m/
	R3efAfWhFfB9EyfBRMG5s/Z4vEX2aDdmLBpykuvkUkdPnAYyrVU5U/ZPSGWr83YBYBOMpb9zDFl
	mvMRtMexaY3ncJbrN5I++O
X-Google-Smtp-Source: AGHT+IGUG79kearmVn7+9qugGuIF+Iaatq5RHrgppUdDi9qlZIXdMZGH9YdXisC+M3CCPhGM+TJyoQ==
X-Received: by 2002:a05:600c:a00c:b0:46e:41b0:f0cb with SMTP id 5b1f17b1804b1-46e41b0f464mr152474875e9.25.1759205681405;
        Mon, 29 Sep 2025 21:14:41 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Jason Herne ,
	Stefano Stabellini ,
	Stefano Garzarella ,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini ,
	Ilya Leoshkevich ,
	Anthony PERARD ,
	Paul Durrant ,
	Eric Farman ,
	Marcelo Tosatti ,
	Halil Pasic ,
	Matthew Rosato ,
	Reinoud Zandijk ,
	Zhao Liu ,
	David Woodhouse ,
	Christian Borntraeger ,
	Sunil Muthuswamy ,
	kvm@vger.kernel.org,
	"Michael S. Tsirkin" ,
	Peter Xu ,
	Thomas Huth ,
	qemu-s390x@nongnu.org,
	"Edgar E. Iglesias" ,
	Richard Henderson ,
	David Hildenbrand 
Subject: [PATCH v2 12/17] target/i386/nvmm: Inline cpu_physical_memory_rw() in nvmm_mem_callback
Date: Tue, 30 Sep 2025 06:13:20 +0200
Message-ID: <20250930041326.6448-13-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930041326.6448-1-philmd@linaro.org>
References: <20250930041326.6448-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/nvmm/nvmm-all.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/nvmm/nvmm-all.c b/target/i386/nvmm/nvmm-all.c
index ed424251673..2e442baf4b7 100644
--- a/target/i386/nvmm/nvmm-all.c
+++ b/target/i386/nvmm/nvmm-all.c
@@ -15,6 +15,7 @@
 #include "accel/accel-ops.h"
 #include "system/nvmm.h"
 #include "system/cpus.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "qemu/main-loop.h"
 #include "qemu/error-report.h"
@@ -516,7 +517,9 @@ nvmm_io_callback(struct nvmm_io *io)
 static void
 nvmm_mem_callback(struct nvmm_mem *mem)
 {
-    cpu_physical_memory_rw(mem->gpa, mem->data, mem->size, mem->write);
+    /* TODO: Get CPUState via mem->vcpu? */
+    address_space_rw(&address_space_memory, mem->gpa, MEMTXATTRS_UNSPECIFIED,
+                     mem->data, mem->size, mem->write);
 
     /* Needed, otherwise infinite loop. */
     current_cpu->vcpu_dirty = false;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:42:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:42:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133655.1471728 (Exim 4.92)
	(envelope-from )
	id 1v3SC4-0007Rm-Ap; Tue, 30 Sep 2025 04:42:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133655.1471728; Tue, 30 Sep 2025 04: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 1v3SC4-0007Rf-87; Tue, 30 Sep 2025 04:42:28 +0000
Received: by outflank-mailman (input) for mailman id 1133655;
 Tue, 30 Sep 2025 04:42: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 1v3SC2-0007R6-7F
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:42:26 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d929a01a-9db7-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:42:20 +0200 (CEST)
Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com
 [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-475-U0GkLpl8Mc2yP93URxHw2Q-1; Tue, 30 Sep 2025 00:42:17 -0400
Received: by mail-ej1-f69.google.com with SMTP id
 a640c23a62f3a-b4544f46392so18836066b.0
 for ; Mon, 29 Sep 2025 21:42:17 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3e89655b09sm359039666b.77.2025.09.29.21.42.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 21:42: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: d929a01a-9db7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759207339;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=tvxLjB/EsvBZ5htouvq/q3x83R6wXLK+5or1QrTnakw=;
	b=NZcrNuNDEV+RiCbVuGjddgcNeoRWmtrnQalgxte8aZZDS5gPkEefYEchJWGNDnIij1pL0m
	831tnulTVCoXPK/o73TeIApKtRUTTXsWKV93dekAyhC12aXGQPKZjEWPNkmAmKTzmtXiMJ
	QWOSnBXXFX9Ghpk1MueW081ZQygjecM=
X-MC-Unique: U0GkLpl8Mc2yP93URxHw2Q-1
X-Mimecast-MFC-AGG-ID: U0GkLpl8Mc2yP93URxHw2Q_1759207337
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759207337; x=1759812137;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tvxLjB/EsvBZ5htouvq/q3x83R6wXLK+5or1QrTnakw=;
        b=PbUYUzKvddUSZAGWRkRMiUYLsKwSfeUyI0zBkobBZjgKkv9oWcuVrRd9PzRawjcGq4
         BHsIr80k2UkIdxwYuVHUihxIDlD93hnhSR/dykkn1U8toCLWZe4Px4U2VWx9LdhwzHWc
         L/JSZaTkR1BUQiCH1iGAvdbpB5hjdkQbr8z45SMB8M4DAQb8/DJSsaG8f0iy9UHWLHx2
         9t15UPsDb4FkvNk9glQFArP50716PE8U41X/BW1Dq+Fqcrk4cjlrN1uhN4vNwI13XluR
         vXCOGhw40hCZ3vxencJ6Im1X7YbAuFPqZ5Z/+Hy/yBRQ4VCI2SW6wdO6C92sAXli5yBW
         vFcg==
X-Forwarded-Encrypted: i=1; AJvYcCU90BsLFOA83/co2A4EHW1sfWwTSFWOwWQW9IqcPXEugDB9yXbs2JeMpIVSRurogfcdlWSw0wB4vqw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHaZDa+qgmOkjy1C+3tj68zHkD9CjGlNMtGn7TS3XhVW3SE4Op
	KfIYoN+RCaFwlTJMNBvxuCsCQgBlnwmUh2pskoUz1H/shaWuHH/6y7ds8jXekI+cvEvRKkcJaEz
	+7YzRNtafcGnoxSNjf+KNxs4sd0dpL1TYCjiTdDOSuAf0Djd80kvvsYLVp7es93ZsL1nF
X-Gm-Gg: ASbGncvlF08atln7/fWiAyJ1yPeFZdvA4DieGmvpPMlVNWcPZCho9nqDM64jox9f+3G
	tiOanbvJBppn20VJ4ArZbafBmU4EhwqcnUkRMKGr0axHhpwoyvAxwjIMLwuiKdJY4fysNBL/c1C
	rDicfB3cjCSWCbjHqsMP2iP3ZCdeSHT8fCMfRUGUGeSwetZOS7WMeCUdUzAuCmi0Q6FYN8NQM0P
	MjJGj/+4RWd1nBGfXMs9Ihif8Yhfcurmqqi6bjtaQIoyhamKpa3KGGke/KuL7szY9zzBlmHyN8u
	29fhCq03hBnDeMi11374FgI2giTpunNj5SfleDsiRWuEV7qvLlGbNPrZSRj96tH3SDXO5+vNgtZ
	w69utNyA05w==
X-Received: by 2002:a17:906:55d3:b0:b3a:875c:294f with SMTP id a640c23a62f3a-b3a875c2f2bmr943874566b.10.1759207336654;
        Mon, 29 Sep 2025 21:42:16 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IE05FwuhQMGeXmbqCfNb5OYa/tRq8eoNKOW/kmksbVHWw0wqxA34cy3qT6OjHD0nk6wgB/ziw==
X-Received: by 2002:a17:906:55d3:b0:b3a:875c:294f with SMTP id a640c23a62f3a-b3a875c2f2bmr943870066b.10.1759207336259;
        Mon, 29 Sep 2025 21:42:16 -0700 (PDT)
Message-ID: <69b0255a-b6b5-46da-9940-ce1f2a18c2e6@redhat.com>
Date: Tue, 30 Sep 2025 06:42:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/17] target/s390x/mmu: Replace [cpu_physical_memory
 -> address_space]_rw()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-10-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930041326.6448-10-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: tvwIQrXzG72lNeD8gaQjUhHE_AYTXa4oh6W9Ddda400_1759207337
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
> When cpu_address_space_init() isn't called during vCPU creation,
> its single address space is the global &address_space_memory.
> 
> As s390x boards don't call cpu_address_space_init(),
> cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.
> 
> We can then replace cpu_physical_memory_rw() by the semantically
> equivalent address_space_rw() call.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

Reviewed-by: Thomas Huth 



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133665.1471738 (Exim 4.92)
	(envelope-from )
	id 1v3SDU-00083P-LI; Tue, 30 Sep 2025 04:43:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133665.1471738; Tue, 30 Sep 2025 04: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 1v3SDU-00083I-IO; Tue, 30 Sep 2025 04:43:56 +0000
Received: by outflank-mailman (input) for mailman id 1133665;
 Tue, 30 Sep 2025 04:43: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 1v3SDU-000820-2M
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:43:56 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 11cf0fed-9db8-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:43:55 +0200 (CEST)
Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com
 [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-130-z5IfX0vNPmatJzJdkvgsrw-1; Tue, 30 Sep 2025 00:43:50 -0400
Received: by mail-ej1-f69.google.com with SMTP id
 a640c23a62f3a-b2e9e07a887so499932466b.0
 for ; Mon, 29 Sep 2025 21:43:50 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a36521c2sm9027477a12.20.2025.09.29.21.43.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 21: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: 11cf0fed-9db8-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759207434;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=IFA/ZKajMt+npZXBOLV5WlPV0wIgh0I4dBfqL+bGAaY=;
	b=IkNvnnzKLxYfJQ8OkhhEVL2PgIHfYhfakc4eAneiT5Mm4DBQpxiutPWIot4RaQ4OYWVI/D
	3spKpHtvGV4u/Eqzr4HH/oaxdkZblY/OGTxFDTG5cjcvr5NKUYNIGLpFSW2jfu4ePgpNlQ
	Jb8L/vlQSJw/5GLUmzbuCMcK8fDnG/k=
X-MC-Unique: z5IfX0vNPmatJzJdkvgsrw-1
X-Mimecast-MFC-AGG-ID: z5IfX0vNPmatJzJdkvgsrw_1759207429
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759207429; x=1759812229;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=IFA/ZKajMt+npZXBOLV5WlPV0wIgh0I4dBfqL+bGAaY=;
        b=HUHx+1BZ2Hm1lgKHheF5kGn9kNrGXAF6UwDLvfY7gJW1TYxtSfxbGTvtBXOvP/vAQv
         d5htEuQGsysDW8Bw0ePsdbyxiPL0r4bRZb8hTMkaaFn7qczmHvdfjvolAi45HFhcSG/q
         Gp2dWK8g+g9Wjz52bp1O9v7vqLHiBBbb4ulJIm67HLlRGIuHTa7j7VfWgAFPJHjHoh8N
         QChW0+z5Uxd5A948/vDQGHaWyoO1IYPWVrQzFdKqnyVSXJcmXUrWRHs5ttksJnWJDtxR
         aIdyoUXmSqlPM8njmTQLnGzZf6EA6kE8Cfu7Qwkles6Xq/ZF4kPd8a/BBcZZxPasceAf
         a2rw==
X-Forwarded-Encrypted: i=1; AJvYcCUN9qPZhJgjGQUDRPc9Gma44yLqqESP+Q1aQP8w+AAmzIOzfWrcxdunVfqndyoc3fXSN8NfQ5dkke8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwXvWFfiKjxzTMYPey8qlkIvS3+Q/ng2nAZrD2tMlVCuVXFeL4z
	XAlSqkmaRXT7TPRflJtxXgE/MrbR5LhDkOEqgfGS2CmI7+C48nqEiIh2WAfKCcYcuXsVY4DlKDU
	RwoGpRzJZkLfNSiwc6n5imz6hPliCQXKq+DRzYw32dvdKpSyFXUzS/7/LuEvqOakTkkVI
X-Gm-Gg: ASbGncuQnYk/mjHF5s27HOeAx1sZzGdLKn2qLmrPvBYngNiEpuM1xgcvqtgeI8sLSA8
	McR2JYYxJgh+LnuR4gaxo8t7seyg64o93kP7cDZxF8DfBAPuzZcHWtTZpB9d0zRYvn03SLTwhlx
	Of9pd1j73drlwoNNznzB8xhHHH24qbIKYiUVysTOhh4AVS9Fewwxsha2UJ1fTiOVFvLRrh52P8c
	6zQPft6vMq2g54/vGWlZPZIWWE5otTE5E+2xJcEI5YrDYImF8FQMNpn7HettJGKDKMTn+PRiDvE
	DPgHaByqCJipYCTxmZDOuVKNVGmS6qD1v4SoZZN84YtF6lSuQX9pCc9irYRbv6X3hHKiA96YMMT
	zfW2ByLFwTQ==
X-Received: by 2002:a17:906:b0b:b0:b3b:8158:48d4 with SMTP id a640c23a62f3a-b3b8176d599mr705917466b.13.1759207429311;
        Mon, 29 Sep 2025 21:43:49 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEEEN+aLuKNT3JrbnL9wHpSrGyIpOBnWD9C8+mIEIuRXFAWmiOmVNhLUOh/8RrbMdmxUy1frA==
X-Received: by 2002:a17:906:b0b:b0:b3b:8158:48d4 with SMTP id a640c23a62f3a-b3b8176d599mr705914066b.13.1759207428915;
        Mon, 29 Sep 2025 21:43:48 -0700 (PDT)
Message-ID: <7e8d3fcf-3ec3-4209-8f7f-93c210690f73@redhat.com>
Date: Tue, 30 Sep 2025 06:43:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] hw/s390x/sclp: Use address_space_memory_is_io()
 in sclp_service_call()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-6-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930041326.6448-6-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 5MATJHppJQoioGO6TpplBdZV7nK0WSt7uEkOxyuY5z0_1759207429
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
> When cpu_address_space_init() isn't called during vCPU creation,
> its single address space is the global &address_space_memory.
> 
> As s390x boards don't call cpu_address_space_init(),
> cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.
> 
> We can then replace cpu_physical_memory_is_io() by the semantically
> equivalent address_space_memory_is_io() call.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

Reviewed-by: Thomas Huth 



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:47:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:47:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133674.1471748 (Exim 4.92)
	(envelope-from )
	id 1v3SGy-0000w6-3Y; Tue, 30 Sep 2025 04:47:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133674.1471748; Tue, 30 Sep 2025 04: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 1v3SGy-0000vz-0U; Tue, 30 Sep 2025 04:47:32 +0000
Received: by outflank-mailman (input) for mailman id 1133674;
 Tue, 30 Sep 2025 04: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 1v3SGx-0000vt-6E
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:47:31 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 910c4c9a-9db8-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 06:47:29 +0200 (CEST)
Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com
 [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-664-TlmEGcJIPiSVWIJNUBIYPA-1; Tue, 30 Sep 2025 00:47:24 -0400
Received: by mail-ed1-f69.google.com with SMTP id
 4fb4d7f45d1cf-634c48a0ce7so4429191a12.1
 for ; Mon, 29 Sep 2025 21:47:24 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b40f9d0a652sm192717466b.33.2025.09.29.21.47.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 21:47: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: 910c4c9a-9db8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759207648;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=F0CpCpGLryTSVfViexSV8x0K3iUnfmatiqDW29KVp44=;
	b=dWWEejV87MAuObRRkV3UQrW27oVnJmmT4fU6pXQs0nWFOHc9aHzezPY78dm6dDHptYB0TZ
	KhsQYq303k6mdl8cAuS+WuGRGfOQ5lA8BIJJivAeiw4pjN0Yk+84knXBBbrNfjYbQyYnMx
	fXOrECJd30uoBhVEeDEjzo3G/5l/7nY=
X-MC-Unique: TlmEGcJIPiSVWIJNUBIYPA-1
X-Mimecast-MFC-AGG-ID: TlmEGcJIPiSVWIJNUBIYPA_1759207643
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759207643; x=1759812443;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=F0CpCpGLryTSVfViexSV8x0K3iUnfmatiqDW29KVp44=;
        b=wFHJ5QsebQlHJ8h/tY4tFZJa2L3AdQfiQx+o3IOyIdxbObygguPI5NZ76GdeXZL/AB
         y8Ntp5P9crEv+GH6x1VO1LzXIkpRK2h4B6leoYvB0JRRCUh3sG8OrymjbT9a3ENT0mNK
         2MzigvOfnXrbt+G4j9J8e3GxPY0Bza6oUz9LZWo9G6ChCyl74Y3D3TN5gllAJtANyl0+
         ZSbrNemjTx/AecN9UWwVdWR4NykaoQTTwSdzkViyUI5Z42vuEHoo0UuE8AeJIa9tLWXs
         3duezb+KVU4M7wLYDUXT1ATi4eCtEwN3KEtVJaQP4T9GA4VgOazYzSSq1mPZM8qh+NDS
         PJjA==
X-Forwarded-Encrypted: i=1; AJvYcCXIdFZNi3Kgu1oz69ZZapZqBei7HcDD3YPKpSUdk1rFFXFvsa3tyjKRDQAzNNgRUmZ0GavLX+W3MHU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFtryZllxw6GBHgIugJnU3yBxns9ioh23JBQ4vtyNlJnrqHgqz
	ZRFrYyjROTS6NlOhb4POoDBiKPir48Q08cA5+f0kMtK8OZe0h2ACtcNMSQP4edxpe59CbilFvzi
	E70CF4AeHlEb1+popz7LqfRDrPBNI8w4uiJR375xym2+vRtPVZRA37+KNn9hJyI9drc3/
X-Gm-Gg: ASbGnctg1pdEaoEXbNXkAo9wDM7f7wU+2MFe9ACwThUfCz/It6OzSggsupjptxW9lt9
	xQkNqL5mNb5zRoGMirkKUg/izceRNb1kEp/81cZJomRxX96l/BSwI49gqFaqLOXBWen9PmXsfaW
	0q9Bts6MKrIfACxP7vWHCKz2YORid0uUfntt6YFmkyKMVOA7K95qTe18iphYvg5IfVEsPYz+0qn
	ricbmbNoQr305Nn13fdooB7zq9hQDQ4ckK0OKcY3NDxZuPIm+6VfJ0mAbRGJpAW1ve6EX82lH5C
	sKzxLy1I6yFQvLuBr4H4/4UprkkvkvuHDEtSWM8mVaSmX05A/j/dvqeSNUq0ECY5uv98Rl5QQm/
	Rdac2tL1wGA==
X-Received: by 2002:a17:907:6e90:b0:b04:2a50:3c1b with SMTP id a640c23a62f3a-b34bc9720fcmr2205354066b.53.1759207643438;
        Mon, 29 Sep 2025 21:47:23 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGrEv+SaLvycPTTXjkfI3gAv2L4ih/JXeTcfurbaylseRmIiY1ztu3a3eE7D6ASNch/ayHT8g==
X-Received: by 2002:a17:907:6e90:b0:b04:2a50:3c1b with SMTP id a640c23a62f3a-b34bc9720fcmr2205350566b.53.1759207643038;
        Mon, 29 Sep 2025 21:47:23 -0700 (PDT)
Message-ID: <64065767-95b1-4dcf-b02e-e2f1d2033c8d@redhat.com>
Date: Tue, 30 Sep 2025 06:47:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] hw/s390x/sclp: Replace [cpu_physical_memory ->
 address_space]_r/w()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-9-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930041326.6448-9-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 4Re8dlLC0TPRN7X-7KJegUQE4LCols43JOGPRhvWHjw_1759207643
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
> cpu_physical_memory_read() and cpu_physical_memory_write() are
> legacy (see commit b7ecba0f6f6), replace by address_space_read()
> and address_space_write().
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

Reviewed-by: Thomas Huth 



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 04:52:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 04:52:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133685.1471758 (Exim 4.92)
	(envelope-from )
	id 1v3SLG-0003ed-KT; Tue, 30 Sep 2025 04:51:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133685.1471758; Tue, 30 Sep 2025 04: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 1v3SLG-0003eW-Ga; Tue, 30 Sep 2025 04:51:58 +0000
Received: by outflank-mailman (input) for mailman id 1133685;
 Tue, 30 Sep 2025 04: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 1v3SLF-0003eQ-2Y
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 04:51:57 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 303142e2-9db9-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 06:51:56 +0200 (CEST)
Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com
 [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-5-5hgfkuoeNqaAq-H2P-7gGw-1; Tue, 30 Sep 2025 00:51:51 -0400
Received: by mail-ed1-f70.google.com with SMTP id
 4fb4d7f45d1cf-634a73b5966so3801025a12.3
 for ; Mon, 29 Sep 2025 21:51:50 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3b02ccbsm8861868a12.45.2025.09.29.21.51.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 21: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: 303142e2-9db9-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759207914;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=+Ec7IP8RaNea+ekLtnS8GreYVm0zDgRXajLAUnWqjpM=;
	b=L3yXiruhB8dh7q9ai78RWEYDJbkGeRKze84nR3M49W0zPGiu8KT0ru/rKM03wVrBs9H1RY
	JggUb77FHv5DzeFWawDM3b6qb5kTR44VVB+Az8rKY0izTi/eoNsEMbZfYJwv7CcquPgFFg
	YNTaqkeXMDYvEclujfL0bZfYbqnQrM0=
X-MC-Unique: 5hgfkuoeNqaAq-H2P-7gGw-1
X-Mimecast-MFC-AGG-ID: 5hgfkuoeNqaAq-H2P-7gGw_1759207910
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759207910; x=1759812710;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+Ec7IP8RaNea+ekLtnS8GreYVm0zDgRXajLAUnWqjpM=;
        b=gtP0MM7A7ApKukFEdladk3kitVpFU/U+r0MPN1GlNIeZdlYZUBpHv2SGQL+H7YGmUg
         rVwUtCLGXqWpB5Rt/+oGUf5tlLSHVDX/Pvmsb9cKYUrY60ioFEv+lscuo3U3ofkpX6k4
         ZuC+4eCcErIvXEibqTi7BIiGeZdMT9zW3mSe+TUjsKasbjbj+x6Jwyzer1hKQj06lS/m
         BcqIZ4silsc8iaP9rIWjEBtYLmqNen0VZQSFPT0sJAsAkkU1SrDQnHZJCQgeVLamDnyi
         dKgouJWjGK+sKqLPJgHKS9OsS3/b+Ils5YV+uLDexROC1xcCJNqxHJVpzjOP+6W3zqG2
         6+iA==
X-Forwarded-Encrypted: i=1; AJvYcCXbAVtbOyjR/9NNJGyFu2kFj6M/ErMjL77wOV5J+oIQyNH5Dd4K4+DJxusruKYxCT2win7McmVBLMM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywjj4u7/WvvMhx7fK27BZXbM0e0tWEdzQ9XEPQsYq0hV7VsMPVx
	B2f6PbVOsWrxxFovl0LkvKIbzM5fhbq/N0e+Wv47krPWNt22D0gtQC6zd1yPrg15WR1phSCRwtg
	ov1EYKpCSjKNjdXXu/PgHT7VnzXcfsPhvlEQ+GSp7Xs7iIrk8V/rxBv9LCMTowoW19g7e
X-Gm-Gg: ASbGnct7NnAsYlhdBcLXaypKELxH6VhfY76p8NimhHixlYNYgtJ3GJuhVBUlEk5jZ3A
	7MBoLD0q0JXCU+Dv0nHg2bWwgU5s3l7EvFQJX6BCvEtB77DMY6wo8Speu4Y5TggBv+MLEVr2nQr
	7GBQggAExt7c719Nzh6IJHwHbGDAJdEs9TcHh3ukBEo40v5LiZTxM8YFpsyoUiUVWINkDNYcqDK
	LgWl4v6EjAuA1+mX5iHKAUXHDmtYSwRI5SZJn3KPSV8uj43tvD8CWAMY3/kZZLaBrLJIus4p/2P
	R2rcS5LCOH460R+QTEqGWQkoUlUmHsurTq/Z+e6+TKLOdDW0dVKDYdeX/L1lfiS++gz6XJKK3P2
	KD/qLI/mdRA==
X-Received: by 2002:a05:6402:26d3:b0:634:bff3:25d8 with SMTP id 4fb4d7f45d1cf-634bff32630mr11889987a12.30.1759207909948;
        Mon, 29 Sep 2025 21:51:49 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEiKyEPXuUeN9dycrzKBPNvTY+be/FSVas+XL6RlQgrJhdSMc3jVU2nKqcyK2u2Vo+ShPjxzw==
X-Received: by 2002:a05:6402:26d3:b0:634:bff3:25d8 with SMTP id 4fb4d7f45d1cf-634bff32630mr11889951a12.30.1759207909548;
        Mon, 29 Sep 2025 21:51:49 -0700 (PDT)
Message-ID: <22ff756a-51a2-43f4-8fe1-05f17ff4a371@redhat.com>
Date: Tue, 30 Sep 2025 06:51:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/17] system/memory: Better describe @plen argument of
 flatview_translate()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-3-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930041326.6448-3-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: _quMjsbvIEsUeRIYCOlcC66bX8XqWkQwePfqzwk7u8I_1759207910
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
> flatview_translate()'s @plen argument is output-only and can be NULL.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>   include/system/memory.h | 5 +++--
>   system/physmem.c        | 6 +++---
>   2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/include/system/memory.h b/include/system/memory.h
> index aa85fc27a10..3e5bf3ef05e 100644
> --- a/include/system/memory.h
> +++ b/include/system/memory.h
> @@ -2992,13 +2992,14 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
>    * @addr: address within that address space
>    * @xlat: pointer to address within the returned memory region section's
>    * #MemoryRegion.
> - * @len: pointer to length
> + * @plen_out: pointer to valid read/write length of the translated address.
> + *            It can be @NULL when we don't care about it.
>    * @is_write: indicates the transfer direction
>    * @attrs: memory attributes
>    */
>   MemoryRegion *flatview_translate(FlatView *fv,
>                                    hwaddr addr, hwaddr *xlat,
> -                                 hwaddr *len, bool is_write,
> +                                 hwaddr *plen_out, bool is_write,
>                                    MemTxAttrs attrs);
>   
>   static inline MemoryRegion *address_space_translate(AddressSpace *as,
> diff --git a/system/physmem.c b/system/physmem.c
> index 8a8be3a80e2..2d1697fce4c 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -566,7 +566,7 @@ iotlb_fail:
>   
>   /* Called from RCU critical section */
>   MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
> -                                 hwaddr *plen, bool is_write,
> +                                 hwaddr *plen_out, bool is_write,
>                                    MemTxAttrs attrs)
>   {
>       MemoryRegion *mr;
> @@ -574,13 +574,13 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
>       AddressSpace *as = NULL;
>   
>       /* This can be MMIO, so setup MMIO bit. */
> -    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
> +    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
>                                       is_write, true, &as, attrs);
>       mr = section.mr;
>   
>       if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) {
>           hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr;
> -        *plen = MIN(page, *plen);
> +        *plen_out = MIN(page, *plen_out);

There is no check for a NULL pointer here, so plen_out must *not* be NULL?
Or did I miss something?

  Thomas


>       }
>   
>       return mr;



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 05:00:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 05:00:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133700.1471768 (Exim 4.92)
	(envelope-from )
	id 1v3STR-00076b-II; Tue, 30 Sep 2025 05:00:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133700.1471768; Tue, 30 Sep 2025 05:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3STR-00076U-EW; Tue, 30 Sep 2025 05:00:25 +0000
Received: by outflank-mailman (input) for mailman id 1133700;
 Tue, 30 Sep 2025 05: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 1v3STP-00076O-SL
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 05:00:23 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5dc89bf2-9dba-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 07:00:22 +0200 (CEST)
Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com
 [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-251--tRg7vbRNpus1nQvU_A70A-1; Tue, 30 Sep 2025 01:00:19 -0400
Received: by mail-ed1-f69.google.com with SMTP id
 4fb4d7f45d1cf-61d31626b01so5072119a12.0
 for ; Mon, 29 Sep 2025 22:00:18 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3d277598bdsm449199366b.3.2025.09.29.22.00.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 22:00: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: 5dc89bf2-9dba-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759208420;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=3xiFBQZdSxrBR3BZG3caEthJ8AMJq39BtL8Q95119s8=;
	b=SBHh2B1ehjS1OsE30nl6CgD3k6znH4lD99OSLoKnvcnIf9e9c1WAJOKrdSIyCWxt5DlAC4
	FHObzVciICIGkrhnu278WtHBGjTshpuyFloJQFT1BvO0bD/Q5PKawlizcYcLxKF0puBNuX
	wJ/j3yeSn2EagKkoORldU9/IuLIw8wU=
X-MC-Unique: -tRg7vbRNpus1nQvU_A70A-1
X-Mimecast-MFC-AGG-ID: -tRg7vbRNpus1nQvU_A70A_1759208418
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759208418; x=1759813218;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3xiFBQZdSxrBR3BZG3caEthJ8AMJq39BtL8Q95119s8=;
        b=bN5eVhI8fV/EDMoJFbuQIBFZBLnpQD9FsYYnI6WMxMH9UAXgIcvNXo8FG3+LDJyFzf
         PCI0L3cnBGM3Hyf91z1br9gtQYKm7H/iubQ5QWjJ/USE4BnVZcfhQ0PDYP3pgc/PZmqW
         cT/uHmUUqVAlWT/PWDAiRgXb0KRQeVvC5coDW9pACafc5i9uYjvzoh9ytr5uMt7gUrgP
         iQfqWZNTgAyNiAd2wFvHUog5oV1f+Ysbdb1Pz0lKqC+Fmaf1zxH5tQz9Xgbb7+Q4nz/2
         7f17YYL5xlstIPDCqmKtApRnRk+TlQtRF3GxCsdBVqUlZQe1+DSaa2Sda+FPtlTUBard
         hVcg==
X-Forwarded-Encrypted: i=1; AJvYcCWmB3tRGyhfUVpYgZOM9Cug3HLW4qycE7lVCYBqjN3fbR6BlGnO8PxPErqBeNqOYEN4WJTUhoDf9sI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMAweozXIEvZmWbzMWbPX8PT8DZm+MlOq/3G6UDcnaDaSWa2UM
	wirb8K3026dUHdq0brt94zHj+j4ivDrbr1dY6PA5aodgAEMZxNJrTubRNJ6S5qwQbdvYYedp9vY
	lHPpwv0R+UaE6FZkrgP1U+kGEEGOUFJUwRooFwKNpSd3q8ID2Bm1tmFkgNlzjlQ6NOzUD
X-Gm-Gg: ASbGncuXyCTahfnEycGhlNkdqAdjUutuY4e5xRJpXiE+CaqKzj0ZJo1WHXLMLazJg4R
	3mZo7I5trplee1Tyf2hkgWfgp/ebImgyhoVSl/frwzQRNXYBHCfh428JNyF0zvzvnZeVwHVuzO0
	7f1KN4mhiBpYL6qo7WnC1Te1RGwKkYzJfqhQfIDt/RDpGWeIFdSZh8mKgUojoTuoxYa/bwRnylP
	JPF2LzFxk4DW5/V6Aw33xa9KBHe+rQ5nxARO4tUx42gwmbUGH6xJNDymD5HAb2OXkZlSQqt5ch5
	zjWP+XpT9VfzIhzj0te+eD2xOnNnhvZegcpbMfwlnf9Kbsfea9aIydCVza2RpQN2g6apaoeZsAh
	Phjra/TCB1w==
X-Received: by 2002:a17:907:3da6:b0:b3e:f987:d6a8 with SMTP id a640c23a62f3a-b3ef987d997mr637744366b.44.1759208416626;
        Mon, 29 Sep 2025 22:00:16 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHa8KgJhbAbV0RRCkwD4pI/pD3HkfND1iGeihF86L8+aCZePSj+3WOJ+3YXP8Jeay5jFXCoTA==
X-Received: by 2002:a17:907:3da6:b0:b3e:f987:d6a8 with SMTP id a640c23a62f3a-b3ef987d997mr637742166b.44.1759208416253;
        Mon, 29 Sep 2025 22:00:16 -0700 (PDT)
Message-ID: <6c7d7a37-c7e1-44af-839f-7d6d01fc843f@redhat.com>
Date: Tue, 30 Sep 2025 07:00:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] system/memory: Factor address_space_is_io() out
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-4-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930041326.6448-4-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: Ab_Aoyl0h2ot4E2viPxZxiJvsjn1gCbc3Th8C2JQL4w_1759208418
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
> Factor address_space_is_io() out of cpu_physical_memory_is_io().
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---

Reviewed-by: Thomas Huth 



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 05:03:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 05:03:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133710.1471778 (Exim 4.92)
	(envelope-from )
	id 1v3SVv-0007yc-Um; Tue, 30 Sep 2025 05:02:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133710.1471778; Tue, 30 Sep 2025 05: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 1v3SVv-0007yV-Qo; Tue, 30 Sep 2025 05:02:59 +0000
Received: by outflank-mailman (input) for mailman id 1133710;
 Tue, 30 Sep 2025 05:02: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 1v3SVu-0007yO-8H
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 05:02:58 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9bdd89f-9dba-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 07:02:56 +0200 (CEST)
Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com
 [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-17-Uz6QhTx1OgWxMCIGnMY9BA-1; Tue, 30 Sep 2025 01:02:51 -0400
Received: by mail-ej1-f71.google.com with SMTP id
 a640c23a62f3a-afcb72a8816so521739666b.0
 for ; Mon, 29 Sep 2025 22:02:51 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b353efb88ebsm1061296766b.32.2025.09.29.22.02.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 29 Sep 2025 22: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: b9bdd89f-9dba-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759208575;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=bL+RjxGqhOdRGXNtIbLqiRsKj/Y3K4D3P43i5DVXnfw=;
	b=KDyi3tqoWpmkeEg0L7vUIl7hkOAiZ1lu9q6VBujRrzg0CQFQaN/I30aMrlTfEa5wkwSJuC
	tTQ7ev9/5N1DzxlAeOu7s2Nx0iaaHcD3B4cjeIlNQOv4/0CzHXMsCx4mYpnvgbuyO3w00K
	jUanIPvvXrrt9uACGvtNBC+EYHZnDCg=
X-MC-Unique: Uz6QhTx1OgWxMCIGnMY9BA-1
X-Mimecast-MFC-AGG-ID: Uz6QhTx1OgWxMCIGnMY9BA_1759208570
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759208570; x=1759813370;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=bL+RjxGqhOdRGXNtIbLqiRsKj/Y3K4D3P43i5DVXnfw=;
        b=tS5oQGtG5H8AvDe+Ms7gsuTqrzbZwHJMmnjRd7gt3ubKthUWVLaK+t5rtdiHTgs7sD
         /ueehSjMWJjGaqfbOhyM+JhHF2KgAod/fFlXX14FgEgqVU04gRtf8A3QJPUjNrnUKmAr
         bQq5WRDy86Q4sLnPTVRmI1N3F8jm5foJfKxxwXjw7Ggr68Akcs/JTrFgGOf4IXhZB0qE
         OF/WuVdnCDeYr3Fwxze+8Tc6jY+BAkQYjYk58DevPIgp8cuO01LLGmfvit0sUxcJl0ok
         VQqxLpto+hpBnEmk2PQGs8fitpUpTdU/cEkiYopAOPpSHwbsAd2zwgxjxyp2FASLH3iE
         yeKA==
X-Forwarded-Encrypted: i=1; AJvYcCUROMTjU98iJJtJeHdDI4AG857IF//jAO7CDPAb0lL9aFoiGVxvqvMpUQPUUrD+ZOxTVjsKFFzUvvY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwuZstutDbj7hUVSOFQomNvtjXciIuhzH7yOZpk0UIVAZqLs74F
	9K6yNZfKhoffv/dwGQ3/hv8/qwrD4n8afPHweiuk0XWqN3TUbODeezDQHtp//oqp7sdAe0ayCHZ
	jUQ2MGOCwDHjwRT4s66zb7nDzw2TIkaKd0ZUApc8MN2Cb1Ou7IR9PEHHgnSKg0jwzv3UW
X-Gm-Gg: ASbGncvV42zmxz0Ey5ebudQNKiVFZHSBUbc3BVaQwxADqe57VOuPzjg5+K6uDyrIbMP
	iJ6UWZd+atHRen/lH1He8MuKPIXb0+52CvCdtDAuK3y13ZHH+C2yj9fg+sNGdhtMV1EUuQG0rt7
	YCPsC1CzYkXCWf+1KDm+p7DDE6KRybbrBeYK+d23P1DstsiQ8Rbd3miJttEHCed+JoY0LrIO8j/
	eB02++FwI+Q9tKKZ6WovtIUbnnwWtR+zYORyjR7lk41lr0HceAfcCMiZFr1J/Z6gOMXoVc/++vc
	b/6IJ5jYIMZ1j2giyLQgN9PNg6v6FM4zvI74xJ0kPpgaJB4UZmHnKki5hzN3770lhb/mLXNfco7
	yENOCOOPRQQ==
X-Received: by 2002:a17:906:f5a0:b0:b41:a571:21b0 with SMTP id a640c23a62f3a-b41a5712270mr236497566b.39.1759208570369;
        Mon, 29 Sep 2025 22:02:50 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFxIe1/gUAycFtpVQcR4b+NsqR4Pre+MyQnotThndZ321+xPzQyp6FkW4vxaOLRMNcnkRphAA==
X-Received: by 2002:a17:906:f5a0:b0:b41:a571:21b0 with SMTP id a640c23a62f3a-b41a5712270mr236492866b.39.1759208569870;
        Mon, 29 Sep 2025 22:02:49 -0700 (PDT)
Message-ID: <193cd8a8-2c4c-4c2c-af22-622b74c332ee@redhat.com>
Date: Tue, 30 Sep 2025 07:02:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/17] system/physmem: Un-inline
 cpu_physical_memory_read/write()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-15-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930041326.6448-15-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: qSedsP2layODZu98HrgFL-kZdUVQALWgbLJAlInIdno_1759208570
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
> Un-inline cpu_physical_memory_read() and cpu_physical_memory_write().

What's the reasoning for this patch?

  Thomas

> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>   include/exec/cpu-common.h | 12 ++----------
>   system/physmem.c          | 10 ++++++++++
>   2 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
> index 6c7d84aacb4..6e8cb530f6e 100644
> --- a/include/exec/cpu-common.h
> +++ b/include/exec/cpu-common.h
> @@ -133,16 +133,8 @@ void cpu_address_space_destroy(CPUState *cpu, int asidx);
>   
>   void cpu_physical_memory_rw(hwaddr addr, void *buf,
>                               hwaddr len, bool is_write);
> -static inline void cpu_physical_memory_read(hwaddr addr,
> -                                            void *buf, hwaddr len)
> -{
> -    cpu_physical_memory_rw(addr, buf, len, false);
> -}
> -static inline void cpu_physical_memory_write(hwaddr addr,
> -                                             const void *buf, hwaddr len)
> -{
> -    cpu_physical_memory_rw(addr, (void *)buf, len, true);
> -}
> +void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
> +void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
>   void *cpu_physical_memory_map(hwaddr addr,
>                                 hwaddr *plen,
>                                 bool is_write);
> diff --git a/system/physmem.c b/system/physmem.c
> index 70b02675b93..6d6bc449376 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -3188,6 +3188,16 @@ void cpu_physical_memory_rw(hwaddr addr, void *buf,
>                        buf, len, is_write);
>   }
>   
> +void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
> +{
> +    cpu_physical_memory_rw(addr, buf, len, false);
> +}
> +
> +void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
> +{
> +    cpu_physical_memory_rw(addr, (void *)buf, len, true);
> +}
> +
>   /* used for ROM loading : can write in RAM and ROM */
>   MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
>                                       MemTxAttrs attrs,



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:04:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:04:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133725.1471788 (Exim 4.92)
	(envelope-from )
	id 1v3UP9-00089l-6e; Tue, 30 Sep 2025 07:04:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133725.1471788; Tue, 30 Sep 2025 07:04: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 1v3UP9-00089e-3h; Tue, 30 Sep 2025 07:04:07 +0000
Received: by outflank-mailman (input) for mailman id 1133725;
 Tue, 30 Sep 2025 07:04: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 1v3UP8-00089Y-Gr
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:04:06 +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 a6763701-9dcb-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 09:04: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 9380133739;
 Tue, 30 Sep 2025 07:04: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 A628E13A3F;
 Tue, 30 Sep 2025 07:03:59 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id hWSkJt+A22hxRwAAD6G6ig
 (envelope-from ); Tue, 30 Sep 2025 07:03: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: a6763701-9dcb-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215840; 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=si4gFV/3dYwzZCgZLBa+slIGVpI7ADvTkoM2AqYWyic=;
	b=lI//7GrWbrtZpvnC/P8xTiWG1bJbDcWhKotPPRdZuKz3ngnIcX30ietrtLWvmP1jskQdao
	4gLwLF/Cd8MQo3TpAPNLdCbc/gpChj8LWOhneF7676sm6d/4WczGF/pjpomj3dkTdfHv3r
	z05U8sTyMyF8jumPIDaPESgjn69G6tU=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="lI//7GrW"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215840; 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=si4gFV/3dYwzZCgZLBa+slIGVpI7ADvTkoM2AqYWyic=;
	b=lI//7GrWbrtZpvnC/P8xTiWG1bJbDcWhKotPPRdZuKz3ngnIcX30ietrtLWvmP1jskQdao
	4gLwLF/Cd8MQo3TpAPNLdCbc/gpChj8LWOhneF7676sm6d/4WczGF/pjpomj3dkTdfHv3r
	z05U8sTyMyF8jumPIDaPESgjn69G6tU=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-coco@lists.linux.dev,
	kvm@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	llvm@lists.linux.dev
Cc: xin@zytor.com,
	Juergen Gross ,
	"Kirill A. Shutemov" ,
	Dave Hansen ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	"H. Peter Anvin" ,
	Sean Christopherson ,
	Paolo Bonzini ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Andy Lutomirski ,
	Peter Zijlstra ,
	Nathan Chancellor ,
	Nick Desaulniers ,
	Bill Wendling ,
	Justin Stitt 
Subject: [PATCH v2 00/12] x86/msr: Inline rdmsr/wrmsr instructions
Date: Tue, 30 Sep 2025 09:03:44 +0200
Message-ID: <20250930070356.30695-1-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[33];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	MIME_TRACE(0.00)[0:+];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	FREEMAIL_CC(0.00)[zytor.com,suse.com,kernel.org,linux.intel.com,linutronix.de,redhat.com,alien8.de,google.com,microsoft.com,oracle.com,lists.xenproject.org,broadcom.com,infradead.org,gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:mid,suse.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[lkml];
	DKIM_TRACE(0.00)[suse.com:+];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Queue-Id: 9380133739
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -1.51

When building a kernel with CONFIG_PARAVIRT_XXL the paravirt
infrastructure will always use functions for reading or writing MSRs,
even when running on bare metal.

Switch to inline RDMSR/WRMSR instructions in this case, reducing the
paravirt overhead.

In order to make this less intrusive, some further reorganization of
the MSR access helpers is done in the first 5 patches.

The next 5 patches are converting the non-paravirt case to use direct
inlining of the MSR access instructions, including the WRMSRNS
instruction and the immediate variants of RDMSR and WRMSR if possible.

Patch 11 removes the PV hooks for MSR accesses and implements the
Xen PV cases via calls depending on X86_FEATURE_XENPV, which results
in runtime patching those calls away for the non-XenPV case.

Patch 12 is a final little cleanup patch.

This series has been tested to work with Xen PV and on bare metal.

This series is inspired by Xin Li, who used a similar approach, but
(in my opinion) with some flaws. Originally I thought it should be
possible to use the paravirt infrastructure, but this turned out to be
rather complicated, especially for the Xen PV case in the *_safe()
variants of the MSR access functions.

Changes since V1:
- Use Xin Li's approach for inlining
- Several new patches

Juergen Gross (9):
  coco/tdx: Rename MSR access helpers
  x86/sev: replace call of native_wrmsr() with native_wrmsrq()
  x86/kvm: Remove the KVM private read_msr() function
  x86/msr: minimize usage of native_*() msr access functions
  x86/msr: Move MSR trace calls one function level up
  x86/msr: Use the alternatives mechanism for WRMSR
  x86/msr: Use the alternatives mechanism for RDMSR
  x86/paravirt: Don't use pv_ops vector for MSR access functions
  x86/msr: Reduce number of low level MSR access helpers

Xin Li (Intel) (3):
  x86/cpufeatures: Add a CPU feature bit for MSR immediate form
    instructions
  x86/opcode: Add immediate form MSR instructions
  x86/extable: Add support for immediate form MSR instructions

 arch/x86/coco/tdx/tdx.c               |   8 +-
 arch/x86/hyperv/ivm.c                 |   2 +-
 arch/x86/include/asm/cpufeatures.h    |   1 +
 arch/x86/include/asm/fred.h           |   2 +-
 arch/x86/include/asm/kvm_host.h       |  10 -
 arch/x86/include/asm/msr.h            | 409 +++++++++++++++++++-------
 arch/x86/include/asm/paravirt.h       |  67 -----
 arch/x86/include/asm/paravirt_types.h |  13 -
 arch/x86/include/asm/sev-internal.h   |   7 +-
 arch/x86/kernel/cpu/scattered.c       |   1 +
 arch/x86/kernel/kvmclock.c            |   2 +-
 arch/x86/kernel/paravirt.c            |   5 -
 arch/x86/kvm/svm/svm.c                |  16 +-
 arch/x86/kvm/vmx/vmx.c                |   4 +-
 arch/x86/lib/x86-opcode-map.txt       |   5 +-
 arch/x86/mm/extable.c                 |  39 ++-
 arch/x86/xen/enlighten_pv.c           |  24 +-
 arch/x86/xen/pmu.c                    |   5 +-
 tools/arch/x86/lib/x86-opcode-map.txt |   5 +-
 19 files changed, 383 insertions(+), 242 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:04:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:04:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133729.1471797 (Exim 4.92)
	(envelope-from )
	id 1v3UPW-0008WL-Dt; Tue, 30 Sep 2025 07:04:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133729.1471797; Tue, 30 Sep 2025 07:04: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 1v3UPW-0008WE-Aw; Tue, 30 Sep 2025 07:04:30 +0000
Received: by outflank-mailman (input) for mailman id 1133729;
 Tue, 30 Sep 2025 07:04: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 1v3UPV-0008Ue-0d
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:04:29 +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 b35477d6-9dcb-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 09:04:26 +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 1F3561F7F0;
 Tue, 30 Sep 2025 07:04: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 724E513A3F;
 Tue, 30 Sep 2025 07:04: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 PKpCGveA22iWRwAAD6G6ig
 (envelope-from ); Tue, 30 Sep 2025 07:04: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: b35477d6-9dcb-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215864; 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=Gb/490BwBT2pJb8VyiYCDqR7oVEXLp6PItp8lOXpG+8=;
	b=cLHyrL958OTnlFYNDsyhvs5Jx8YJsVXY3jgWesU9DwMy3sVcFdlCJ6ofnheGWYTCoTixda
	XBUj2VZxq9APW9dl7AuCDkHiLj3C8xTaZ/QlrTEdbQkGzHMAjdnP1F3UOSoDrfCLpbglhW
	660NgLMHkoojRmT5xYEh5UQk2nCGC1w=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=cLHyrL95
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215864; 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=Gb/490BwBT2pJb8VyiYCDqR7oVEXLp6PItp8lOXpG+8=;
	b=cLHyrL958OTnlFYNDsyhvs5Jx8YJsVXY3jgWesU9DwMy3sVcFdlCJ6ofnheGWYTCoTixda
	XBUj2VZxq9APW9dl7AuCDkHiLj3C8xTaZ/QlrTEdbQkGzHMAjdnP1F3UOSoDrfCLpbglhW
	660NgLMHkoojRmT5xYEh5UQk2nCGC1w=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org,
	kvm@vger.kernel.org
Cc: xin@zytor.com,
	Juergen Gross ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Sean Christopherson ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 04/12] x86/msr: Minimize usage of native_*() msr access functions
Date: Tue, 30 Sep 2025 09:03:48 +0200
Message-ID: <20250930070356.30695-5-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930070356.30695-1-jgross@suse.com>
References: <20250930070356.30695-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%];
	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_RATELIMITED(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];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[20];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FROM_EQ_ENVFROM(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,suse.com:email,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Queue-Id: 1F3561F7F0
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01

In order to prepare for some MSR access function reorg work, switch
most users of native_{read|write}_msr[_safe]() to the more generic
rdmsr*()/wrmsr*() variants.

For now this will have some intermediate performance impact with
paravirtualization configured when running on bare metal, but this
is a prereq change for the planned direct inlining of the rdmsr/wrmsr
instructions with this configuration.

The main reason for this switch is the planned move of the MSR trace
function invocation from the native_*() functions to the generic
rdmsr*()/wrmsr*() variants. Without this switch the users of the
native_*() functions would lose the related tracing entries.

Note that the Xen related MSR access functions will not be switched,
as these will be handled after the move of the trace hooks.

Signed-off-by: Juergen Gross 
Acked-by: Sean Christopherson 
Acked-by: Wei Liu 
---
 arch/x86/hyperv/ivm.c      |  2 +-
 arch/x86/kernel/kvmclock.c |  2 +-
 arch/x86/kvm/svm/svm.c     | 16 ++++++++--------
 arch/x86/xen/pmu.c         |  4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
index ade6c665c97e..202ed01dc151 100644
--- a/arch/x86/hyperv/ivm.c
+++ b/arch/x86/hyperv/ivm.c
@@ -327,7 +327,7 @@ int hv_snp_boot_ap(u32 apic_id, unsigned long start_ip, unsigned int cpu)
 	asm volatile("movl %%ds, %%eax;" : "=a" (vmsa->ds.selector));
 	hv_populate_vmcb_seg(vmsa->ds, vmsa->gdtr.base);
 
-	vmsa->efer = native_read_msr(MSR_EFER);
+	rdmsrq(MSR_EFER, vmsa->efer);
 
 	vmsa->cr4 = native_read_cr4();
 	vmsa->cr3 = __native_read_cr3();
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ca0a49eeac4a..b6cd45cce5fe 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -196,7 +196,7 @@ static void kvm_setup_secondary_clock(void)
 void kvmclock_disable(void)
 {
 	if (msr_kvm_system_time)
-		native_write_msr(msr_kvm_system_time, 0);
+		wrmsrq(msr_kvm_system_time, 0);
 }
 
 static void __init kvmclock_init_mem(void)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 1bfebe40854f..105d5c2aae46 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -393,12 +393,12 @@ static void svm_init_erratum_383(void)
 		return;
 
 	/* Use _safe variants to not break nested virtualization */
-	if (native_read_msr_safe(MSR_AMD64_DC_CFG, &val))
+	if (rdmsrq_safe(MSR_AMD64_DC_CFG, &val))
 		return;
 
 	val |= (1ULL << 47);
 
-	native_write_msr_safe(MSR_AMD64_DC_CFG, val);
+	wrmsrq_safe(MSR_AMD64_DC_CFG, val);
 
 	erratum_383_found = true;
 }
@@ -558,9 +558,9 @@ static int svm_enable_virtualization_cpu(void)
 		u64 len, status = 0;
 		int err;
 
-		err = native_read_msr_safe(MSR_AMD64_OSVW_ID_LENGTH, &len);
+		err = rdmsrq_safe(MSR_AMD64_OSVW_ID_LENGTH, &len);
 		if (!err)
-			err = native_read_msr_safe(MSR_AMD64_OSVW_STATUS, &status);
+			err = rdmsrq_safe(MSR_AMD64_OSVW_STATUS, &status);
 
 		if (err)
 			osvw_status = osvw_len = 0;
@@ -2032,7 +2032,7 @@ static bool is_erratum_383(void)
 	if (!erratum_383_found)
 		return false;
 
-	if (native_read_msr_safe(MSR_IA32_MC0_STATUS, &value))
+	if (rdmsrq_safe(MSR_IA32_MC0_STATUS, &value))
 		return false;
 
 	/* Bit 62 may or may not be set for this mce */
@@ -2043,11 +2043,11 @@ static bool is_erratum_383(void)
 
 	/* Clear MCi_STATUS registers */
 	for (i = 0; i < 6; ++i)
-		native_write_msr_safe(MSR_IA32_MCx_STATUS(i), 0);
+		wrmsrq_safe(MSR_IA32_MCx_STATUS(i), 0);
 
-	if (!native_read_msr_safe(MSR_IA32_MCG_STATUS, &value)) {
+	if (!rdmsrq_safe(MSR_IA32_MCG_STATUS, &value)) {
 		value &= ~(1ULL << 2);
-		native_write_msr_safe(MSR_IA32_MCG_STATUS, value);
+		wrmsrq_safe(MSR_IA32_MCG_STATUS, value);
 	}
 
 	/* Flush tlb to evict multi-match entries */
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 8f89ce0b67e3..d49a3bdc448b 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -323,7 +323,7 @@ static u64 xen_amd_read_pmc(int counter)
 		u64 val;
 
 		msr = amd_counters_base + (counter * amd_msr_step);
-		native_read_msr_safe(msr, &val);
+		rdmsrq_safe(msr, &val);
 		return val;
 	}
 
@@ -349,7 +349,7 @@ static u64 xen_intel_read_pmc(int counter)
 		else
 			msr = MSR_IA32_PERFCTR0 + counter;
 
-		native_read_msr_safe(msr, &val);
+		rdmsrq_safe(msr, &val);
 		return val;
 	}
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:05:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:05:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133744.1471808 (Exim 4.92)
	(envelope-from )
	id 1v3UQA-0000hM-Ro; Tue, 30 Sep 2025 07:05:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133744.1471808; Tue, 30 Sep 2025 07:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3UQA-0000hF-Nc; Tue, 30 Sep 2025 07:05:10 +0000
Received: by outflank-mailman (input) for mailman id 1133744;
 Tue, 30 Sep 2025 07:05:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3UQ9-0008Ue-Np
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:05:09 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cc1f23ff-9dcb-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 09:05:07 +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 D78EA1F898;
 Tue, 30 Sep 2025 07:05: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 59B8813A3F;
 Tue, 30 Sep 2025 07:05: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 1I8fFCCB22jcRwAAD6G6ig
 (envelope-from ); Tue, 30 Sep 2025 07:05: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: cc1f23ff-9dcb-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215905; 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/gRu11gXgbmlZdLI3CmLMHqbiCSOdJDjKieoXm17Zs=;
	b=J4PQvC04B+PSPU5Qn0kbYDejEXysFawQCmfnFZpkuz+0XUVkV1HqUqBG3Il0Wo6kN6BnOg
	sajF6F2Ud8w6aYGOQkXNNJKhdJO1QQAPMKxREUCCe+yVhUdjy4ehAUGNrj9auqwNXf2E5c
	6TfBk+rIMkHcYuJlw6RXmLfymsIsER8=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=BlbtgpeX
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215904; 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/gRu11gXgbmlZdLI3CmLMHqbiCSOdJDjKieoXm17Zs=;
	b=BlbtgpeXbLF5152uqQWV0JAAKoFLaMKHAq6+2yypXHAlf+7CTkYb7c8skwiJxhzxfURFNY
	Mn+g8IuOXIJ+0XuhbydgFKILHbP8IRRGpTJsPFn/fTxM8Qdr4d+NYbJP6tntvKOL2tHQAT
	KCDiguuQTp2eUWCmNph/s5SLlhCYHVQ=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev
Cc: xin@zytor.com,
	Juergen Gross ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR access functions
Date: Tue, 30 Sep 2025 09:03:55 +0200
Message-ID: <20250930070356.30695-12-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930070356.30695-1-jgross@suse.com>
References: <20250930070356.30695-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: D78EA1F898
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
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)[];
	FUZZY_RATELIMITED(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];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[15];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FROM_EQ_ENVFROM(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:dkim,suse.com:mid,suse.com:email]
X-Spam-Score: -3.01

Instead of using the pv_ops vector for RDMSR/WRMSR related functions,
use a more explicit approach allowing to inline the RDMSR/WRMSR
instructions directly when not running as a Xen PV guest.

By using cpu_feature_enabled(X86_FEATURE_XENPV) for the Xen PV case
the related calls to Xen specific code will be statically disabled via
runtime patching.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 arch/x86/include/asm/msr.h            | 57 ++++++++++++++++++++++-----
 arch/x86/include/asm/paravirt.h       | 45 ---------------------
 arch/x86/include/asm/paravirt_types.h | 13 ------
 arch/x86/kernel/paravirt.c            |  5 ---
 arch/x86/xen/enlighten_pv.c           | 20 ++++------
 arch/x86/xen/pmu.c                    |  1 +
 6 files changed, 57 insertions(+), 84 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index cc592611e333..d42cd2c19818 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -290,24 +290,22 @@ static __always_inline void native_wrmsr(u32 msr, u32 low, u32 high)
 	native_wrmsrq(msr, (u64)high << 32 | low);
 }
 
-static inline u64 native_read_msr(u32 msr)
+static __always_inline u64 native_read_msr(u32 msr)
 {
 	return native_rdmsrq(msr);
 }
 
-static inline int native_read_msr_safe(u32 msr, u64 *val)
+static __always_inline int native_read_msr_safe(u32 msr, u64 *val)
 {
 	return __rdmsr(msr, val, EX_TYPE_RDMSR_SAFE) ? -EIO : 0;
 }
 
-/* Can be uninlined because referenced by paravirt */
-static inline void notrace native_write_msr(u32 msr, u64 val)
+static __always_inline void native_write_msr(u32 msr, u64 val)
 {
 	native_wrmsrq(msr, val);
 }
 
-/* Can be uninlined because referenced by paravirt */
-static inline int notrace native_write_msr_safe(u32 msr, u64 val)
+static __always_inline int native_write_msr_safe(u32 msr, u64 val)
 {
 	return __wrmsrq(msr, val, EX_TYPE_WRMSR_SAFE) ? -EIO : 0;
 }
@@ -325,8 +323,49 @@ static inline u64 native_read_pmc(int counter)
 	return EAX_EDX_VAL(val, low, high);
 }
 
-#ifdef CONFIG_PARAVIRT_XXL
-#include 
+#ifdef CONFIG_XEN_PV
+#include 
+
+static __always_inline u64 read_msr(u32 msr)
+{
+	if (cpu_feature_enabled(X86_FEATURE_XENPV))
+		return xen_read_msr(msr);
+
+	return native_rdmsrq(msr);
+}
+
+static __always_inline int read_msr_safe(u32 msr, u64 *p)
+{
+	if (cpu_feature_enabled(X86_FEATURE_XENPV))
+		return xen_read_msr_safe(msr, p);
+
+	return native_read_msr_safe(msr, p);
+}
+
+static __always_inline void write_msr(u32 msr, u64 val)
+{
+	if (cpu_feature_enabled(X86_FEATURE_XENPV))
+		xen_write_msr(msr, val);
+	else
+		native_wrmsrq(msr, val);
+}
+
+static __always_inline int write_msr_safe(u32 msr, u64 val)
+{
+	if (cpu_feature_enabled(X86_FEATURE_XENPV))
+		return xen_write_msr_safe(msr, val);
+
+	return native_write_msr_safe(msr, val);
+}
+
+static __always_inline u64 rdpmc(int counter)
+{
+	if (cpu_feature_enabled(X86_FEATURE_XENPV))
+		return xen_read_pmc(counter);
+
+	return native_read_pmc(counter);
+}
+
 #else
 static __always_inline u64 read_msr(u32 msr)
 {
@@ -353,7 +392,7 @@ static __always_inline u64 rdpmc(int counter)
 	return native_read_pmc(counter);
 }
 
-#endif	/* !CONFIG_PARAVIRT_XXL */
+#endif	/* !CONFIG_XEN_PV */
 
 /*
  * Access to machine-specific registers (available on 586 and better only)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index dc297f62b935..45f47b7d9f56 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -175,51 +175,6 @@ static inline void __write_cr4(unsigned long x)
 	PVOP_VCALL1(cpu.write_cr4, x);
 }
 
-static inline u64 paravirt_read_msr(u32 msr)
-{
-	return PVOP_CALL1(u64, cpu.read_msr, msr);
-}
-
-static inline void paravirt_write_msr(u32 msr, u64 val)
-{
-	PVOP_VCALL2(cpu.write_msr, msr, val);
-}
-
-static inline int paravirt_read_msr_safe(u32 msr, u64 *val)
-{
-	return PVOP_CALL2(int, cpu.read_msr_safe, msr, val);
-}
-
-static inline int paravirt_write_msr_safe(u32 msr, u64 val)
-{
-	return PVOP_CALL2(int, cpu.write_msr_safe, msr, val);
-}
-
-static __always_inline u64 read_msr(u32 msr)
-{
-	return paravirt_read_msr(msr);
-}
-
-static __always_inline int read_msr_safe(u32 msr, u64 *p)
-{
-	return paravirt_read_msr_safe(msr, p);
-}
-
-static __always_inline void write_msr(u32 msr, u64 val)
-{
-	paravirt_write_msr(msr, val);
-}
-
-static __always_inline int write_msr_safe(u32 msr, u64 val)
-{
-	return paravirt_write_msr_safe(msr, val);
-}
-
-static __always_inline u64 rdpmc(int counter)
-{
-	return PVOP_CALL1(u64, cpu.read_pmc, counter);
-}
-
 static inline void paravirt_alloc_ldt(struct desc_struct *ldt, unsigned entries)
 {
 	PVOP_VCALL2(cpu.alloc_ldt, ldt, entries);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 37a8627d8277..0d03e658ea8f 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -90,19 +90,6 @@ struct pv_cpu_ops {
 	void (*cpuid)(unsigned int *eax, unsigned int *ebx,
 		      unsigned int *ecx, unsigned int *edx);
 
-	/* Unsafe MSR operations.  These will warn or panic on failure. */
-	u64 (*read_msr)(u32 msr);
-	void (*write_msr)(u32 msr, u64 val);
-
-	/*
-	 * Safe MSR operations.
-	 * Returns 0 or -EIO.
-	 */
-	int (*read_msr_safe)(u32 msr, u64 *val);
-	int (*write_msr_safe)(u32 msr, u64 val);
-
-	u64 (*read_pmc)(int counter);
-
 	void (*start_context_switch)(struct task_struct *prev);
 	void (*end_context_switch)(struct task_struct *next);
 #endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index ab3e172dcc69..240eeb1beab5 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -129,11 +129,6 @@ struct paravirt_patch_template pv_ops = {
 	.cpu.read_cr0		= native_read_cr0,
 	.cpu.write_cr0		= native_write_cr0,
 	.cpu.write_cr4		= native_write_cr4,
-	.cpu.read_msr		= native_read_msr,
-	.cpu.write_msr		= native_write_msr,
-	.cpu.read_msr_safe	= native_read_msr_safe,
-	.cpu.write_msr_safe	= native_write_msr_safe,
-	.cpu.read_pmc		= native_read_pmc,
 	.cpu.load_tr_desc	= native_load_tr_desc,
 	.cpu.set_ldt		= native_set_ldt,
 	.cpu.load_gdt		= native_load_gdt,
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 26bbaf4b7330..df653099c567 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1160,15 +1160,16 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
 	}
 }
 
-static int xen_read_msr_safe(u32 msr, u64 *val)
+int xen_read_msr_safe(u32 msr, u64 *val)
 {
 	int err = 0;
 
 	*val = xen_do_read_msr(msr, &err);
 	return err;
 }
+EXPORT_SYMBOL(xen_read_msr_safe);
 
-static int xen_write_msr_safe(u32 msr, u64 val)
+int xen_write_msr_safe(u32 msr, u64 val)
 {
 	int err = 0;
 
@@ -1176,20 +1177,23 @@ static int xen_write_msr_safe(u32 msr, u64 val)
 
 	return err;
 }
+EXPORT_SYMBOL(xen_write_msr_safe);
 
-static u64 xen_read_msr(u32 msr)
+u64 xen_read_msr(u32 msr)
 {
 	int err = 0;
 
 	return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
 }
+EXPORT_SYMBOL(xen_read_msr);
 
-static void xen_write_msr(u32 msr, u64 val)
+void xen_write_msr(u32 msr, u64 val)
 {
 	int err;
 
 	xen_do_write_msr(msr, val, xen_msr_safe ? &err : NULL);
 }
+EXPORT_SYMBOL(xen_write_msr);
 
 /* This is called once we have the cpu_possible_mask */
 void __init xen_setup_vcpu_info_placement(void)
@@ -1225,14 +1229,6 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = {
 
 		.write_cr4 = xen_write_cr4,
 
-		.read_msr = xen_read_msr,
-		.write_msr = xen_write_msr,
-
-		.read_msr_safe = xen_read_msr_safe,
-		.write_msr_safe = xen_write_msr_safe,
-
-		.read_pmc = xen_read_pmc,
-
 		.load_tr_desc = paravirt_nop,
 		.set_ldt = xen_set_ldt,
 		.load_gdt = xen_load_gdt,
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index d49a3bdc448b..d0dea950cd4f 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -370,6 +370,7 @@ u64 xen_read_pmc(int counter)
 	else
 		return xen_intel_read_pmc(counter);
 }
+EXPORT_SYMBOL(xen_read_pmc);
 
 int pmu_apic_update(uint32_t val)
 {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:05:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:05:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133745.1471818 (Exim 4.92)
	(envelope-from )
	id 1v3UQG-0000xd-2I; Tue, 30 Sep 2025 07:05:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133745.1471818; Tue, 30 Sep 2025 07:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3UQF-0000xU-Vp; Tue, 30 Sep 2025 07:05:15 +0000
Received: by outflank-mailman (input) for mailman id 1133745;
 Tue, 30 Sep 2025 07:05: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 1v3UQE-00089Y-Iy
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:05: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 cfcec0f3-9dcb-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 09:05: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-out2.suse.de (Postfix) with ESMTPS id A05161FB9F;
 Tue, 30 Sep 2025 07:05:10 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 4D06413A3F;
 Tue, 30 Sep 2025 07:05:10 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id kk1UESaB22jlRwAAD6G6ig
 (envelope-from ); Tue, 30 Sep 2025 07:05: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: cfcec0f3-9dcb-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215910; 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=DWVg40kg3cCGlbRyjRUpQT7gp/Qt5+z4LTlGPsiGrXQ=;
	b=GRVg5tr0HEd/zfji2Am9gUzCqwhy/P7cpZ0YqMKn1p2vm/K6PZjvE/xKZ+HTt1e5zEfSPv
	LOjQd5/AGoxOsinDK3vohhJW6ExL1IshA4USHZvyAShs1Vinh0d0R9nNWByddY4+O84CE8
	iDnY1/zxQYKvD6WCT3sUZxg9Y/4NvRc=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1759215910; 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=DWVg40kg3cCGlbRyjRUpQT7gp/Qt5+z4LTlGPsiGrXQ=;
	b=GRVg5tr0HEd/zfji2Am9gUzCqwhy/P7cpZ0YqMKn1p2vm/K6PZjvE/xKZ+HTt1e5zEfSPv
	LOjQd5/AGoxOsinDK3vohhJW6ExL1IshA4USHZvyAShs1Vinh0d0R9nNWByddY4+O84CE8
	iDnY1/zxQYKvD6WCT3sUZxg9Y/4NvRc=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: xin@zytor.com,
	Juergen Gross ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 12/12] x86/msr: Reduce number of low level MSR access helpers
Date: Tue, 30 Sep 2025 09:03:56 +0200
Message-ID: <20250930070356.30695-13-jgross@suse.com>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930070356.30695-1-jgross@suse.com>
References: <20250930070356.30695-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];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	RCPT_COUNT_SEVEN(0.00)[11];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -2.80

Some MSR access helpers are redundant now, so remove the no longer
needed ones.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/msr.h  | 14 ++------------
 arch/x86/xen/enlighten_pv.c |  4 ++--
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index d42cd2c19818..43924d8a3d66 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -290,21 +290,11 @@ static __always_inline void native_wrmsr(u32 msr, u32 low, u32 high)
 	native_wrmsrq(msr, (u64)high << 32 | low);
 }
 
-static __always_inline u64 native_read_msr(u32 msr)
-{
-	return native_rdmsrq(msr);
-}
-
 static __always_inline int native_read_msr_safe(u32 msr, u64 *val)
 {
 	return __rdmsr(msr, val, EX_TYPE_RDMSR_SAFE) ? -EIO : 0;
 }
 
-static __always_inline void native_write_msr(u32 msr, u64 val)
-{
-	native_wrmsrq(msr, val);
-}
-
 static __always_inline int native_write_msr_safe(u32 msr, u64 val)
 {
 	return __wrmsrq(msr, val, EX_TYPE_WRMSR_SAFE) ? -EIO : 0;
@@ -369,7 +359,7 @@ static __always_inline u64 rdpmc(int counter)
 #else
 static __always_inline u64 read_msr(u32 msr)
 {
-	return native_read_msr(msr);
+	return native_rdmsrq(msr);
 }
 
 static __always_inline int read_msr_safe(u32 msr, u64 *p)
@@ -379,7 +369,7 @@ static __always_inline int read_msr_safe(u32 msr, u64 *p)
 
 static __always_inline void write_msr(u32 msr, u64 val)
 {
-	native_write_msr(msr, val);
+	native_wrmsrq(msr, val);
 }
 
 static __always_inline int write_msr_safe(u32 msr, u64 val)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index df653099c567..277e053cf3dd 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1097,7 +1097,7 @@ static u64 xen_do_read_msr(u32 msr, int *err)
 	if (err)
 		*err = native_read_msr_safe(msr, &val);
 	else
-		val = native_read_msr(msr);
+		val = native_rdmsrq(msr);
 
 	switch (msr) {
 	case MSR_IA32_APICBASE:
@@ -1156,7 +1156,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
 		if (err)
 			*err = native_write_msr_safe(msr, val);
 		else
-			native_write_msr(msr, val);
+			native_wrmsrq(msr, val);
 	}
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:23:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:23:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133776.1471836 (Exim 4.92)
	(envelope-from )
	id 1v3Ui8-0004pj-Ko; Tue, 30 Sep 2025 07:23:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133776.1471836; Tue, 30 Sep 2025 07: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 1v3Ui8-0004pc-IF; Tue, 30 Sep 2025 07:23:44 +0000
Received: by outflank-mailman (input) for mailman id 1133776;
 Tue, 30 Sep 2025 07: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 1v3Ui7-0004pW-Cz
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:23:43 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6473e0b5-9dce-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 09:23:42 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-46e33b260b9so8578215e9.2
 for ; Tue, 30 Sep 2025 00:23:42 -0700 (PDT)
Received: from [192.168.69.221] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f3dbcfsm44146575e9.3.2025.09.30.00.23.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 00: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: 6473e0b5-9dce-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759217022; x=1759821822; 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=itVX7tgCqZhn3DDR7jTxWGvfg+OOdlBPano0M6bAsBg=;
        b=rkG3kk5u/JNk6Ha7ilL6KadpTBrAjyI9aUFQqIMZbZD7+i2IDOKbl88nls9d37VzVk
         tloXS2ng0kks1Vur9v8oOKuZm/nG1OFLKMheJAMKGW3dJBRHItyjdRQJe0vXnY0EfOJH
         MTN5TQ+Y06GmEXL106UHix+wl7pApMuAwTvZGEj3WKjt6niFqUlW0yzjlWyH3PIfPRkg
         6MCifRkIEt7WjICGZPavELSF9sll/NM28A6L67nWY6awkgykXPa9CmgvIs+bktDfJuOl
         68wgtc+rUErW7gO9dcO7C1HdBxsONPXZE2+nDp+QVYPXi8qkghde1xVw/SWGsOGT2fAd
         6rzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759217022; x=1759821822;
        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=itVX7tgCqZhn3DDR7jTxWGvfg+OOdlBPano0M6bAsBg=;
        b=cfrMR0YvzpvAnsw3Ivq2MNg4qaEqBUMXeC+rDxIxCF+Zqm3rAdGACVlAaDXdqYVm17
         BTB1JeGazuhed5Tb49Gm6KO7mcQ7DDAt/tsMYlmoZDEsjjtYx+8KGizw+yGaEkAOhwtq
         r00AUuGBTjcypecKZ7FBtfLAu8ePGLQKC/QVp/DrFa+R++Hw1ObaeX7fFVMyf3BYqFjR
         i2Bcu8TWiR5zJrqcIM8beOEI/v+Kq7WzdP9sntlHYc7U3tydo8TjEMy9E3XBbC/RG70y
         Qr3nHEJWoeoMsUDkDm1JwlLV25Ik3ZkJPe/KWLmsbLJftGX4VNP0W1NZpGUqbzFTKcBO
         0kyw==
X-Forwarded-Encrypted: i=1; AJvYcCUyE/pbL23/UqelfmuFEohUZ1xreJl0jXsfsjWEwt1/73Id5HhU81WEGgNkdL5+LPy9AD0Adig1odo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyl+8rqOo9Oeuv6AOy1dCgna29suWGJ/AApY70VS+T/gm/OkGpd
	Is+kS8D34kqml5be6RH0y8SwtdFYxjMx99iR8xJOMSxy/qq73wb2qMLpdecuz412sak=
X-Gm-Gg: ASbGncsG43W38NN0PGmkJCq8q7XZZN0Dbnf6UZ/+yAsqjGzHWk36cRJ7vH57K/nOIFn
	KDyb0msq+LBZidp7j3K9OGtp6/59HzgHEgX3gt/ub3X8cOedwY5Q5v4V+oACpZsOJBUZiaemThx
	TNZzdDFBt9Yx+Dkqg3HE5YuyrdApUqNITmFjhaEpSAskHclltS+AUlVw5PN3eR0q6EuHvzkXSvl
	2JZdpZkMx9cUTe2p+uQuECq0Dahlna04s0lkjnPmYiptUQ4drTiB0w2b0QuMzL/VbeaV9oMkgVk
	myowes5z1P1UswGO3MQoHnxJ9GOIfcS+mYeLdL8f5cMe7ZnnGf/U3laqgNSjg8TKI/r2Oi2jrVF
	9qCTGqMPlwqRGciaTmtlraiWOsdnZjDbYB/OVtaty646PdhDfsi5NR5a6Jmlus8TWPwPyg+eLeh
	DfO+rGCqqveVr8lw==
X-Google-Smtp-Source: AGHT+IHvY4Ey9R8Ex4kFK/h9CrX/gZMo0TkG92UrmsqICbzAXLN4hHP/QkaUH3LOu+37Fvfb480y1w==
X-Received: by 2002:a05:600c:4e4a:b0:46e:4b79:551 with SMTP id 5b1f17b1804b1-46e4b7906ecmr109670425e9.31.1759217021708;
        Tue, 30 Sep 2025 00:23:41 -0700 (PDT)
Message-ID: <61c31076-5330-426a-9c28-b2400bec44f6@linaro.org>
Date: Tue, 30 Sep 2025 09:23:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/17] system/physmem: Un-inline
 cpu_physical_memory_read/write()
To: Thomas Huth , qemu-devel@nongnu.org,
 Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-15-philmd@linaro.org>
 <193cd8a8-2c4c-4c2c-af22-622b74c332ee@redhat.com>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <193cd8a8-2c4c-4c2c-af22-622b74c332ee@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/9/25 07:02, Thomas Huth wrote:
> On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
>> Un-inline cpu_physical_memory_read() and cpu_physical_memory_write().
> 
> What's the reasoning for this patch?

Remove cpu_physical_memory_rw() in the next patch without having
to inline the address_space_read/address_space_write() calls in
"exec/cpu-common.h".

Maybe better squashing both together?

> 
>   Thomas
> 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   include/exec/cpu-common.h | 12 ++----------
>>   system/physmem.c          | 10 ++++++++++
>>   2 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
>> index 6c7d84aacb4..6e8cb530f6e 100644
>> --- a/include/exec/cpu-common.h
>> +++ b/include/exec/cpu-common.h
>> @@ -133,16 +133,8 @@ void cpu_address_space_destroy(CPUState *cpu, int 
>> asidx);
>>   void cpu_physical_memory_rw(hwaddr addr, void *buf,
>>                               hwaddr len, bool is_write);
>> -static inline void cpu_physical_memory_read(hwaddr addr,
>> -                                            void *buf, hwaddr len)
>> -{
>> -    cpu_physical_memory_rw(addr, buf, len, false);
>> -}
>> -static inline void cpu_physical_memory_write(hwaddr addr,
>> -                                             const void *buf, hwaddr 
>> len)
>> -{
>> -    cpu_physical_memory_rw(addr, (void *)buf, len, true);
>> -}
>> +void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
>> +void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr 
>> len);
>>   void *cpu_physical_memory_map(hwaddr addr,
>>                                 hwaddr *plen,
>>                                 bool is_write);
>> diff --git a/system/physmem.c b/system/physmem.c
>> index 70b02675b93..6d6bc449376 100644
>> --- a/system/physmem.c
>> +++ b/system/physmem.c
>> @@ -3188,6 +3188,16 @@ void cpu_physical_memory_rw(hwaddr addr, void 
>> *buf,
>>                        buf, len, is_write);
>>   }
>> +void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
>> +{
>> +    cpu_physical_memory_rw(addr, buf, len, false);
>> +}
>> +
>> +void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
>> +{
>> +    cpu_physical_memory_rw(addr, (void *)buf, len, true);
>> +}
>> +
>>   /* used for ROM loading : can write in RAM and ROM */
>>   MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
>>                                       MemTxAttrs attrs,
> 



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:25:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:25:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133787.1471847 (Exim 4.92)
	(envelope-from )
	id 1v3Ujg-0005Ld-0N; Tue, 30 Sep 2025 07:25:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133787.1471847; Tue, 30 Sep 2025 07:25: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 1v3Ujf-0005LW-SP; Tue, 30 Sep 2025 07:25:19 +0000
Received: by outflank-mailman (input) for mailman id 1133787;
 Tue, 30 Sep 2025 07:25: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 1v3Uje-0005KE-Ao
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:25:18 +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 9d4e9eb8-9dce-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 09:25:17 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3f0134ccc0cso3772947f8f.1
 for ; Tue, 30 Sep 2025 00:25:17 -0700 (PDT)
Received: from [192.168.69.221] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc5602f15sm21415396f8f.39.2025.09.30.00.25.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 00: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: 9d4e9eb8-9dce-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759217117; x=1759821917; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:references:cc:to:from
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=KXfoHJKzAEoZlm7EIBN8HZ0wCcnvYyoGTCHOMSnDlqg=;
        b=Pb0tDXA0Q3Zo+SI4fhbQ9aLJS2kRIBODKtmt1idn2d8s5SEf+F/m5A3w6HZRBAOoC4
         qNicizJj+aHYkuRAhvmRBaInzU3vlIoCavXKSRjlMBp+8xesBa8zJTYDzCR/nMgRguir
         ca6gHApPS0F/WkeIcj9UG8klyYvwg8A4icRGF8Pkubjc7wUBdhO1MVC3ToqCTIV9ZtFW
         w6MQ73S3cjQZ2uYSMnlvZXACXL7PDK7AVjWJjR0bnVZFDsES44tbqRyKiPx3bAHBokTf
         uyc7Ui4dogyTBIagMY/LW+aaHUxU457xcWgqj9kQs1SokJaekbXUAefYXWXYPz+brA13
         E60A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759217117; x=1759821917;
        h=content-transfer-encoding:in-reply-to:references:cc:to:from
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=KXfoHJKzAEoZlm7EIBN8HZ0wCcnvYyoGTCHOMSnDlqg=;
        b=EePaaKLdbJMY9u5ubqzVPDOvdI6Dp9kZm04SwvCxHbVXtFOP+P5eCz91T+o1vvgY/d
         4e3BbnfbB7/P4YSDyDX1iadm/x+psr133n/izBdCa23pLDcHEf/eA9KurhDX2s7C4ZTf
         pQekX2kAnM+mS+ycOObMXpvIQbp2aSxTf0YJdyg+CQxz2Yb2gqZJMw0df9+r3R9GTy2S
         a79AF7LM71nYY0SDq1opbZ6eOr74nxMrJcm6yqn9khXAgEDVpbURvyX2BQYoA4SdXAm5
         n+P6S+NtXyLr4t0sJTpIa0Ta1wCAmHZ/lpzKeTKNdk+xxMKcflkmXY5Qun2uutxTqPvp
         gcog==
X-Forwarded-Encrypted: i=1; AJvYcCWPTjZ31qkCdKKe4V47M8jBV2Gc9rTJmf8BeLSbKHVlaWAHL1luBZN0RTfXBN4UWMynPUcfGHOHl94=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdCHsOyjvkvtN8gTQ1Ido0SuZ50Vp1A9xEBRfV+eGoO/t/AECB
	8yiJuHm/l51e4Nfjrb3SsQrIQ58TO/IrbLTuy4dfLStkp3+kEJvPJy90itaoXJbyWiU=
X-Gm-Gg: ASbGncuYikutFv4Xvruw8fZ/m6XMnT+En7JIVQg8Q/gdCevgd0hKk/wlyFbl5GwhxtG
	gITg+ZVBsCX80WTiZUrd0yXl11znf9pvpGHQzOOHB8mO2INrq0IAJuPvZ1WKMIfZfkjoNi99YHs
	PIZDvQnUxnDzH2bv5cMfKCl8ZS/NS9nfhcRe7RfhanzVR1Itx62E0R7Pw8dMJD/ywhjvuLhSmSh
	Cnf0S4F2GM135Fo5JtDnWiCF1pXPKCkxYpIa+SQGTJuztA0rz+drqS0kwlUKdtzOZiMnIvYtihZ
	jqeR8jdZk9UYGpl9YlxFYi+OOu+1IvzpnfXbQt3Y4SkSVJZplsaGZ0hgoVJDg0jM4R6XQWjtDLP
	NNip7PO3UB28t/au+imaYE7U59hXQo8r9InG5PtsX8SWShsn7UsXS0urgOZMPF1+vyxREJBjUgp
	HBsRr/h9SO5S4yJkcCZ1VM/4/6
X-Google-Smtp-Source: AGHT+IEGShYXZImSoJS6MrCCwqqS6lghItgATnZgdwGJCwRUeVTX2I6q+QeiUjF2A7MJ30GqrUAwEw==
X-Received: by 2002:adf:e646:0:b0:415:b650:a775 with SMTP id ffacd0b85a97d-415b650aca7mr8753025f8f.0.1759217116998;
        Tue, 30 Sep 2025 00:25:16 -0700 (PDT)
Message-ID: <04098b7f-c9bd-4531-87f1-2ea26d4a2a53@linaro.org>
Date: Tue, 30 Sep 2025 09:25:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/17] system/physmem: Un-inline
 cpu_physical_memory_read/write()
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
To: Thomas Huth , qemu-devel@nongnu.org,
 Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-15-philmd@linaro.org>
 <193cd8a8-2c4c-4c2c-af22-622b74c332ee@redhat.com>
 <61c31076-5330-426a-9c28-b2400bec44f6@linaro.org>
In-Reply-To: <61c31076-5330-426a-9c28-b2400bec44f6@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/9/25 09:23, Philippe Mathieu-Daudé wrote:
> On 30/9/25 07:02, Thomas Huth wrote:
>> On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
>>> Un-inline cpu_physical_memory_read() and cpu_physical_memory_write().
>>
>> What's the reasoning for this patch?
> 
> Remove cpu_physical_memory_rw() in the next patch without having
> to inline the address_space_read/address_space_write() calls in
> "exec/cpu-common.h".
> 
> Maybe better squashing both together?

That would be:

-- >8 --
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6c7d84aacb4..910e1c2afb9 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -131,18 +131,8 @@ void cpu_address_space_init(CPUState *cpu, int asidx,
   */
  void cpu_address_space_destroy(CPUState *cpu, int asidx);

-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write);
-static inline void cpu_physical_memory_read(hwaddr addr,
-                                            void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, buf, len, false);
-}
-static inline void cpu_physical_memory_write(hwaddr addr,
-                                             const void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
-}
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
  void *cpu_physical_memory_map(hwaddr addr,
                                hwaddr *plen,
                                bool is_write);
diff --git a/system/physmem.c b/system/physmem.c
index 70b02675b93..a654b2af2a3 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3181,11 +3181,16 @@ MemTxResult address_space_set(AddressSpace *as, 
hwaddr addr,
      return error;
  }

-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write)
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
  {
-    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
-                     buf, len, is_write);
+    address_space_read(&address_space_memory, addr,
+                       MEMTXATTRS_UNSPECIFIED, buf, len);
+}
+
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
+{
+    address_space_write(&address_space_memory, addr,
+                        MEMTXATTRS_UNSPECIFIED, buf, len);
  }

  /* used for ROM loading : can write in RAM and ROM */
---


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:39:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:39:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133804.1471856 (Exim 4.92)
	(envelope-from )
	id 1v3Uwp-0007wy-5j; Tue, 30 Sep 2025 07:38:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133804.1471856; Tue, 30 Sep 2025 07:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Uwp-0007wr-2W; Tue, 30 Sep 2025 07:38:55 +0000
Received: by outflank-mailman (input) for mailman id 1133804;
 Tue, 30 Sep 2025 07:38: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 1v3Uwn-0007wl-VF
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:38:53 +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 82e1f413-9dd0-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 09:38:52 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3f0ae439b56so3272313f8f.3
 for ; Tue, 30 Sep 2025 00:38:52 -0700 (PDT)
Received: from [192.168.69.221] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc5602efdsm22464734f8f.34.2025.09.30.00.38.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 00:38: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: 82e1f413-9dd0-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759217932; x=1759822732; 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=qE2E68kg55lkWKGNUPUbXEU5stTPqSQmthsm27d4faI=;
        b=qYT9/Ti6kdEBs0fWf+e3tCR3MnshPbHf8Y56HV77AY9zFKECTWI0DQzOGjEsol4VZe
         +UpnopCvrPg9yJZqZntH+WVNZ1pQFqbPX822Pas8EmW3BZokr+GBict8sK0sbMjhrZPX
         wz3iBzTsxX4ptrJiP1BLjMWfP/v3WCXdwKq1VW1K+Kolg0drWQ8BVTzyszbb6osWZtML
         2wMLuyIpZDqIyC3jxFYpH8fMDTN/W8zj7Tk2SyHwq0Y23HegjOJ/mK3tKzkCutGA9L6l
         T3Fnu8Mp4lqgToKmnYKOe2bri4w2bnSotCTEqrIrdIfH/rATPQXka+SrpI747Y5P/39H
         QEdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759217932; x=1759822732;
        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=qE2E68kg55lkWKGNUPUbXEU5stTPqSQmthsm27d4faI=;
        b=Udbijg/fCbxTyteajJG/HH5QLNHxO3lspEoqNhcNISxJWzIASsPrOrXeimHaHgsmES
         uXpal37OGrpfLFyDfYPCuLPBLaK1fnEU3pBB7n0vDnvO4b8HnjSmr7Urd1+fbxRGMbMf
         vUXMoUQjbcGDUOGz3hHu01Oxo6fdBhKQ4ovfs0v4Hb9PMlzdBHZnTkdoHglD2/KETxfh
         V1mXZ433uEaENg7HY642xLcOhnBdhd3Tvq6qIMIuqrdGo/dHprMArOifhflURbMetV0J
         AQZQlFJCSQ1gNeTWwL0Vv5tuoXUYlwooT8dXvj5UJAG7dyNRZ+sR99VdCvvfroNa3C0F
         pmsQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4iqxFFnbatlAJlOEZyZEy/uet7WDWzobcGwZ4ROCIYcUGGbDqwRHuo3tRbRHZXZJBjrPSufjnEgo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzymrWhjLzz4Ham4ih7F71+W3T23FbCirZzBZn1bmeHWylGKN4c
	ynGk2MbwNmBFJaza3KAvqpKmI39b7t3MAmdBRiw9bb0uKAjBMqfBBOu/+kHzmUAi10s=
X-Gm-Gg: ASbGncsceehSztGWqTMNLK72R6EIqDRGBFjNg5Jxe4Uazofe/r60rME+nleMy55H0bM
	aP18xk4ZLgDCziwuC0J5w2wdYz7SlLJHS/RENgJgabX2umcAm1Wqz4d7AJQCy5bvOEvggiKphEc
	qcFvrSKlndNFE67uYc42pMQxAcj62qtSisivpLdfLs8R+3131JSmgQKnRtE4yDBSO9XcaPzSQRA
	FJgZQYFbN1wl7k/bHvSU0kUwlBUofInp/T/F9De9Oe8xY/dwLPkksV+lihXFJet8Mm7ucQSw29X
	XNuuYauGeNJQ+j1sYEIhWDNsTgLUoKJTfiAnPk9MlknuDYAFe1o3p1UujSLE21r9O9l0t0YdtJT
	njjQad+rS1ybIYi+Ifx49qwwCZO2SOZ5m1/c7WGyV0P3uQLQC4A1lMDX71rwxywvCDrrcfNnmB+
	PF4bdx2ryq+KfDf0THM3wHSho3
X-Google-Smtp-Source: AGHT+IE+CAzuCcPF3rL8oHgsDWK0spr1fitX6ekcCdqYoQO8jnWYejdEAIaIwc3jMgWkxQsuV9mqBA==
X-Received: by 2002:a05:6000:2f87:b0:3e9:2fea:6795 with SMTP id ffacd0b85a97d-40e4b389223mr19891217f8f.53.1759217931688;
        Tue, 30 Sep 2025 00:38:51 -0700 (PDT)
Message-ID: 
Date: Tue, 30 Sep 2025 09:38:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/17] hw/virtio/vhost: Replace legacy
 cpu_physical_memory_*map() calls
To: qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 Thomas Huth , qemu-s390x@nongnu.org,
 "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-17-philmd@linaro.org>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <20250930041326.6448-17-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/9/25 06:13, Philippe Mathieu-Daudé wrote:
> Use VirtIODevice::dma_as address space to convert the legacy
> cpu_physical_memory_[un]map() calls to address_space_[un]map().
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>   hw/virtio/vhost.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 6557c58d12a..890d2bac585 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -27,6 +27,7 @@
>   #include "migration/blocker.h"
>   #include "migration/qemu-file-types.h"
>   #include "system/dma.h"
> +#include "system/memory.h"
>   #include "trace.h"
>   
>   /* enabled until disconnected backend stabilizes */
> @@ -455,7 +456,8 @@ static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
>                                 hwaddr *plen, bool is_write)
>   {
>       if (!vhost_dev_has_iommu(dev)) {
> -        return cpu_physical_memory_map(addr, plen, is_write);
> +        return address_space_map(vdev->dma_as, addr, plen, is_write,
> +                                 MEMTXATTRS_UNSPECIFIED);
>       } else {
>           return (void *)(uintptr_t)addr;
>       }
> @@ -466,7 +468,7 @@ static void vhost_memory_unmap(struct vhost_dev *dev, void *buffer,
>                                  hwaddr access_len)
>   {
>       if (!vhost_dev_has_iommu(dev)) {
> -        cpu_physical_memory_unmap(buffer, len, is_write, access_len);
> +        address_space_unmap(vdev->dma_as, buffer, len, is_write, access_len);
>       }
>   }
>   

Forgot to squash:

-- >8 --
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 890d2bac585..acd359bdb3f 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -456,7 +456,7 @@ static void *vhost_memory_map(struct vhost_dev *dev, 
hwaddr addr,
                                hwaddr *plen, bool is_write)
  {
      if (!vhost_dev_has_iommu(dev)) {
-        return address_space_map(vdev->dma_as, addr, plen, is_write,
+        return address_space_map(dev->vdev->dma_as, addr, plen, is_write,
                                   MEMTXATTRS_UNSPECIFIED);
      } else {
          return (void *)(uintptr_t)addr;
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? y
@@ -468,7 +468,8 @@ static void vhost_memory_unmap(struct vhost_dev 
*dev, void *buffer,
                                 hwaddr access_len)
  {
      if (!vhost_dev_has_iommu(dev)) {
-        address_space_unmap(vdev->dma_as, buffer, len, is_write, 
access_len);
+        address_space_unmap(dev->vdev->dma_as, buffer, len, is_write,
+                            access_len);
      }
  }

---


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 07:41:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 07:41:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133815.1471865 (Exim 4.92)
	(envelope-from )
	id 1v3Uyy-00010S-Gj; Tue, 30 Sep 2025 07:41:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133815.1471865; Tue, 30 Sep 2025 07:41: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 1v3Uyy-00010L-Dv; Tue, 30 Sep 2025 07:41:08 +0000
Received: by outflank-mailman (input) for mailman id 1133815;
 Tue, 30 Sep 2025 07:41: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 1v3Uyw-00010F-OQ
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 07:41:06 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0bbcd70-9dd0-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 09:41:03 +0200 (CEST)
Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com
 [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-56-eOXQavCVNVWF5ZW6csUQqQ-1; Tue, 30 Sep 2025 03:41:00 -0400
Received: by mail-wr1-f71.google.com with SMTP id
 ffacd0b85a97d-3ece14b9231so3831028f8f.0
 for ; Tue, 30 Sep 2025 00:41:00 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb74e46bcsm21596535f8f.8.2025.09.30.00.40.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 00: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: d0bbcd70-9dd0-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759218062;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=j5g55fSIVioaOkOGMYUBzd3ThDPmNzBRB7wmsPOA2xg=;
	b=S0VcLOF/oVWuyu2Ss9n/DeHy9bFPoMX9pSpTNcF2RY+F6zoZhdJxIXWWRDjbNXPxOAuJVu
	EdnfSCNc3XSzq10rH1b37Fhw88mnZt+HZCe2rd4pS1sFZ99n24b+2iFbHwvXvz2+eYhPtE
	FtcxHweIklSRHz4sK+Sq93YgpC5RlwA=
X-MC-Unique: eOXQavCVNVWF5ZW6csUQqQ-1
X-Mimecast-MFC-AGG-ID: eOXQavCVNVWF5ZW6csUQqQ_1759218060
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759218059; x=1759822859;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=j5g55fSIVioaOkOGMYUBzd3ThDPmNzBRB7wmsPOA2xg=;
        b=wBv2ZQoWQx68dT8EpENMQczttSs/cShdHVgpDiAGkb55ri+phLbvq2wLv9++8biaAS
         mvSpZxR1hAJlM18dH6ObpZ3oGDjtufBzx7lHdqFF5q7i+Bb5Z4grfKbh0vLjkCEUW8T7
         0nVER40JgQk2PH9Pnnvz++8zLJqoR5kdkrpBlhiNTdDoetEwe0+aEqShBiMfpGDqIlyV
         fcyE8/3jIWBx/I2K/Zdg6hZK0x+X4m4Li7l0KG60NM8fHfhABgPfgNT0So8hjXV5zQW2
         wY3Nf1QL7Qa/a21l+Fl22M3HyX2QO4E9vf5GiMfmldCqguFzLesYIg3lNXi1zJn2uRTu
         pv0g==
X-Forwarded-Encrypted: i=1; AJvYcCVLoBOnuVsUqCOLOKNXOgUhtqz6ovlDXKxovCTeIV/PexBCmASoi9hoOHecNgByHd3RcAfeSE3I6LY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyK68d7NeJ/271Iv4loNpW8YlUWrew8lsnn0hupRy+VjpnOHdWc
	G3ziQqJMA0MGYopb30u9v0yDJcEvGWq9Tw2Go4wsEIhTQIfqsNofLxKyM2cqjLXfD1K7ABKaYpL
	yfX9L9gS9UQwrQiBF3Vz+OF19/qhBc9FcHvtUZ+Rj/PMBmiz2pzDIySSC6yQ6ysdmL1SW
X-Gm-Gg: ASbGncs8gvaSz7t5m4cHWZltfhQOY3jZ43V9ayuyangniHwcjvLU6YGgaqUghyaSGJs
	mQ3Or7INj5/j5CMxx74Kj7DDZxEVtWeN8+/KEC0rLzuna7OvSti1TBaHszvqEJQUUAjLli4juxh
	/hIAxSB32GVUjbfLAhSrQbLM7MRrIBw4Tdzaco7knCXxuvFL7bYbwyKcV+zm/5F6NaJb8ff6KhY
	1bDjsnq/QRYpqH7IV42g0femoGvu7iVVrZsWLtUvQ2UeKyvSTe+YtkxR/+//5bfxp9Bd0Gi9Pqi
	OU5okIMRfEKdEjb5HZ9SKElutXEitF+ZwyiRomiyQwWguo0OJ6cq1YQKmmQ1bV9pjuvBnR9WB3v
	xsLaSvGutsA==
X-Received: by 2002:a05:6000:2512:b0:3e7:610b:85f6 with SMTP id ffacd0b85a97d-40e4ece56f9mr18746547f8f.39.1759218059504;
        Tue, 30 Sep 2025 00:40:59 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFtAakQVSr7pX6RBy8gWI/wBsZCTYsWc4ZTAkgkXM7gzrLE/6RH/bVKOjbcCuughEeAm/sEXA==
X-Received: by 2002:a05:6000:2512:b0:3e7:610b:85f6 with SMTP id ffacd0b85a97d-40e4ece56f9mr18746511f8f.39.1759218059101;
        Tue, 30 Sep 2025 00:40:59 -0700 (PDT)
Message-ID: 
Date: Tue, 30 Sep 2025 09:40:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/17] system/physmem: Un-inline
 cpu_physical_memory_read/write()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Jason Herne ,
 Stefano Stabellini ,
 Stefano Garzarella , xen-devel@lists.xenproject.org,
 Paolo Bonzini , Ilya Leoshkevich ,
 Anthony PERARD , Paul Durrant ,
 Eric Farman , Marcelo Tosatti ,
 Halil Pasic , Matthew Rosato ,
 Reinoud Zandijk , Zhao Liu ,
 David Woodhouse ,
 Christian Borntraeger ,
 Sunil Muthuswamy , kvm@vger.kernel.org,
 "Michael S. Tsirkin" , Peter Xu ,
 qemu-s390x@nongnu.org, "Edgar E. Iglesias" ,
 Richard Henderson ,
 David Hildenbrand 
References: <20250930041326.6448-1-philmd@linaro.org>
 <20250930041326.6448-15-philmd@linaro.org>
 <193cd8a8-2c4c-4c2c-af22-622b74c332ee@redhat.com>
 <61c31076-5330-426a-9c28-b2400bec44f6@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <61c31076-5330-426a-9c28-b2400bec44f6@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: zXpwkDwHjcSZRGyC1YGwdishO7HPDVobwM2L7QDhzcg_1759218060
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 09.23, Philippe Mathieu-Daudé wrote:
> On 30/9/25 07:02, Thomas Huth wrote:
>> On 30/09/2025 06.13, Philippe Mathieu-Daudé wrote:
>>> Un-inline cpu_physical_memory_read() and cpu_physical_memory_write().
>>
>> What's the reasoning for this patch?
> 
> Remove cpu_physical_memory_rw() in the next patch without having
> to inline the address_space_read/address_space_write() calls in
> "exec/cpu-common.h".
> 
> Maybe better squashing both together?

Either squash them, or provide a proper patch description here, but just 
repeating the patch title as description without giving a reasoning is just 
confusing for the reviewers.

  Thomas



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:21:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133830.1471889 (Exim 4.92)
	(envelope-from )
	id 1v3VcE-0007aq-7D; Tue, 30 Sep 2025 08:21:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133830.1471889; Tue, 30 Sep 2025 08:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VcE-0007ZJ-26; Tue, 30 Sep 2025 08:21:42 +0000
Received: by outflank-mailman (input) for mailman id 1133830;
 Tue, 30 Sep 2025 08:21: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 1v3VcD-0007Nn-1f
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:21:41 +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 7da6eb91-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:21:40 +0200 (CEST)
Received: by mail-wr1-x442.google.com with SMTP id
 ffacd0b85a97d-3f44000626bso3412264f8f.3
 for ; Tue, 30 Sep 2025 01:21:40 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb72fb1a3sm22070432f8f.10.2025.09.30.01.21.38
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:21: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: 7da6eb91-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220500; x=1759825300; darn=lists.xenproject.org;
        h=content-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=g6Y+9YynyQUWZr+3xZXfGIWc6Jhbj4AT6sZ58oDn40Q=;
        b=Y+cM7YYeLTxfQkqKS2tGafYM6ACeJL+5PwfoYXtJvCjlfoIMGKEdpb3xw4rI9JfvwV
         TZhmcVCz0WZmFjmEs6HN31nEu60M9XrIFy7R4qiKpbfqfXU6abVQY7iqw5OnqqyKq/21
         NiHL1x4v3rJEgbgJd1ErF0lOtTnq/3teCHJzgc23ZQUeo+ScJr8gSMUS35bfoL66L7Lx
         zlGU6s98FZtAAqNteP+H9LMFUDnSUGSDcrd7AARTQNqgce3V3VoLI3+zgrK+h2/kpQ7M
         /fmkR0OztvcIaMrEEqLNKg4XC1oj/2TXNgrq8CvAovUp/6gyrJZY2TkqEBi9aRajO+7I
         UR5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220500; x=1759825300;
        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=g6Y+9YynyQUWZr+3xZXfGIWc6Jhbj4AT6sZ58oDn40Q=;
        b=cfdZ5eSGtrsGd3C6KuPMN6YFp8vGDVYqlPMFCsURDrG02rT4AaYNEfeWkoiUvGi8WG
         vlt0PNlFwvWIf5S6Ls5/sBe6mi1K6FUPtRYfKB9SDNBKIbISo4DwT58VUaWDnjhj7JKY
         PYlgO5meUqUPp5F9UGm3L+kqlvcozkyec5GKReWQSWlIuPykUpJBHZ2PrDHqK6zBqPzo
         5ElwLLzFsA0wt+YiBbktKPYgIW8aorMBKZage8h6omyZXFy8/lR6clSMdQe34B3/odnX
         CXA6VoxKO24Ph/7LJV8eIg7lQRjaw2ta9taLarTHm90fNmFgeyyHFcBTBMoAXjIaWe4Y
         XBiQ==
X-Forwarded-Encrypted: i=1; AJvYcCVGW2YeVGD+EV41LobJFQbX62997gaC619aPkNjtg2ESNoHZxGtD8/xNZ2PsD+eaXg5IGaP8+hwlUM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzI8J7Y6SIWs0lZH/PLsEs7ZUqgyyfk/99OS6Ud8fChSeneB4aA
	e5JucdrWkjKDINdy5k0jg1SXhVGK1z6Ekw9ET6BEgEfjkiivBekCNwq1WbjloHdqEMo=
X-Gm-Gg: ASbGncu+8Jqs9p41sZnKrwd2S2o12XvXk7a3bOGka0fUorY/aLnIaJ9kuwq5DPQvTog
	b5AQToqbKnw37nRYvO1bAc/mqdaKeYbZnp8cDCXpJ2Zswa/LbU93PIBWNWZfN3L3rjM8Qxa9EsG
	DIwhrjElIvFMjtyxQ5DkSVy3WJNI14Q5j8WNotllAnvfxg2wxqTG1p9jofruu6TOvtsvBzsI9IV
	cxlSk9ClOq3BqpEzGMGrmBMkx58HfMSLRIn7RPxyEbGqRTU5zI5/7cnLYWvKvQzBjWgSNXQb3j8
	0iv0ZiXnKF+jIHeNmjrk2PqrzXSNn162utoIsqSZPrOOo59DEIUFunxZt8l2lVsWXYAiZ4gsgKZ
	cj9mO2Z0pq7xKO4/INKG3dugO70+LloQBUetLYzdbM8KBLqZY8pQAfhK2pKaMIkBex6tWFyLrNI
	yisFY7a+jr7we7jlRAqkxX
X-Google-Smtp-Source: AGHT+IEvqZbVxTkOzuE7/OdSy85DpVZk0C8frEdFACso26c6+h9s7puUVSPKjShsswhtViU8Ba02iA==
X-Received: by 2002:a05:6000:18a7:b0:3e9:d0a5:e436 with SMTP id ffacd0b85a97d-40e437371acmr19688375f8f.23.1759220499859;
        Tue, 30 Sep 2025 01:21:39 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 02/18] system/memory: Better describe @plen argument of flatview_translate()
Date: Tue, 30 Sep 2025 10:21:09 +0200
Message-ID: <20250930082126.28618-3-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

flatview_translate()'s @plen argument is output-only and can be NULL.

When Xen is enabled, only update @plen_out when non-NULL.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/system/memory.h | 5 +++--
 system/physmem.c        | 9 +++++----
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/system/memory.h b/include/system/memory.h
index aa85fc27a10..3e5bf3ef05e 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -2992,13 +2992,14 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
  * @addr: address within that address space
  * @xlat: pointer to address within the returned memory region section's
  * #MemoryRegion.
- * @len: pointer to length
+ * @plen_out: pointer to valid read/write length of the translated address.
+ *            It can be @NULL when we don't care about it.
  * @is_write: indicates the transfer direction
  * @attrs: memory attributes
  */
 MemoryRegion *flatview_translate(FlatView *fv,
                                  hwaddr addr, hwaddr *xlat,
-                                 hwaddr *len, bool is_write,
+                                 hwaddr *plen_out, bool is_write,
                                  MemTxAttrs attrs);
 
 static inline MemoryRegion *address_space_translate(AddressSpace *as,
diff --git a/system/physmem.c b/system/physmem.c
index 8a8be3a80e2..86422f294e2 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -566,7 +566,7 @@ iotlb_fail:
 
 /* Called from RCU critical section */
 MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
-                                 hwaddr *plen, bool is_write,
+                                 hwaddr *plen_out, bool is_write,
                                  MemTxAttrs attrs)
 {
     MemoryRegion *mr;
@@ -574,13 +574,14 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
     AddressSpace *as = NULL;
 
     /* This can be MMIO, so setup MMIO bit. */
-    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
+    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
                                     is_write, true, &as, attrs);
     mr = section.mr;
 
-    if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) {
+    if (xen_enabled() && plen_out && memory_access_is_direct(mr, is_write,
+                                                             attrs)) {
         hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr;
-        *plen = MIN(page, *plen);
+        *plen_out = MIN(page, *plen_out);
     }
 
     return mr;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:21:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133829.1471880 (Exim 4.92)
	(envelope-from )
	id 1v3VcD-0007RA-PW; Tue, 30 Sep 2025 08:21:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133829.1471880; Tue, 30 Sep 2025 08:21: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 1v3VcD-0007Q9-K6; Tue, 30 Sep 2025 08:21:41 +0000
Received: by outflank-mailman (input) for mailman id 1133829;
 Tue, 30 Sep 2025 08:21: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 1v3VcB-0007Nm-SF
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:21:39 +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 7a6cdbe9-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:21:35 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3ee64bc6b85so4950395f8f.3
 for ; Tue, 30 Sep 2025 01:21:35 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb74e46bcsm21770765f8f.8.2025.09.30.01.21.33
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:21: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: 7a6cdbe9-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220495; x=1759825295; darn=lists.xenproject.org;
        h=content-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=I6r7ywVdtgg6puBO7GNeh9QBn+ePwbPPQeAATrRMKjs=;
        b=gyS8IQ83XQePL0dmCrxB+R3Bmw9kUZDIfcsteCVOK8lm6GRlqlmiw+Mf7C0Hz4I55t
         ylbLgBdrh2JNCagOn0TJVnkcvwIQYzkrza5CkyTlLmEwcdi2gDaEQ7ngmjpfkt2hhdB6
         SdEOejxAzSy8xMTTbQibEhl9MgIw4rrgRKMCceHyhlUt8cycWE8XLW0OY4i2JeIIddC6
         8jxyPu4x1Qtm8w1iWQ/rVhKB/pqcQMGqN4Iek6paE5U7P2vmI8/PdlpjTpfPjIXKYZlR
         WEDCwYVIhhTljiE7qIz6xgLk0hbvQ9Bxv/JuWZvuyVY+ygHnUuwAYsklPAGV1qubJSsX
         U4Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220495; x=1759825295;
        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=I6r7ywVdtgg6puBO7GNeh9QBn+ePwbPPQeAATrRMKjs=;
        b=DE91NMU7iWi6eyGvKkr9MCaPg6bBol+QPSdbldESQ1qoSW8JrdqUB4KzsDtMJAA4IW
         R6pdAv42CIVug8HErxivmeR5kGMTkkmBfTkIjvY77cR4NvGpbfw0jm18g8LoV4se1vph
         G+UvcFC9oRHWYTaNUcjo7ZOteQ//nKrlY+zNqnyTfJBjoUYlHQzuA/yI+9Rr6HyMN8+e
         8CpbFR71WcjFZCO5VOyANQDIYXqtSXFaZQtrO7jbl3ih3GiGD0Fl/MmH1LdunhjNsz2L
         XySksmSwGz5PGYQO6pv0g+4T7ftkTSr4mhToXM3xxfAC0rvHJdQztPy/wy13atmgYMzv
         ApeQ==
X-Forwarded-Encrypted: i=1; AJvYcCU2L2ueVekOZ7zkzZOc/DdIzyTUPVB+FgVdKrXFuSyEUdCkNAp7GqafVN4ckoA9bWEIKDYIv54Y2Uk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOQgC2pCXWPuPzcrYgheJrqK01vloJpCoIdVjXVOEDAcZdnjto
	mRFPCqcR/svm8/3aR2kw+6cqIce2CPYLLRHGXKrAnZ/eZtP+0ADqvGdLaiV1RQ/biZk=
X-Gm-Gg: ASbGncv2LJ9yqlPCu21VYJw+gPGrK1CB6LMXNezDFKEU3RVlMiMvMlEUzQTw6C3jdLX
	TQMXxo3S/6JUALD6PURcTEKF7iB10wQBxewzokqqmcbvHZy1zwIv05cBREq017a3GYckXBzHxGt
	Kj6dcuiVVimBngimIjl9OuYrM/kguaBlrjkRY70ftQ4I7KPlYrnQ+g3xunwALOfKQaVgYP+9DDx
	VouVSJy/Ei3m2P950zlb8HW/p2Y9bW7AVN9fvDUixTurJTl+JlIqVzfq/M7YBTFET3VXgb72Y+q
	LF3oHW40a4kmSBAVCsVchYJn+YQ+4wLLx88NBE4HCeRMboVik2wMvQ4Efrnlww4NPcrDsc/Nlsy
	pMN3rRksr10us8wReYgYrjfjlrfUlYptEd7PaRn0evOb5d62rq+yhjblA68cYHy/TaADXNEHCT4
	1BsDkwfDjnNYO7bVgNxOBB6JX6dFa86h4=
X-Google-Smtp-Source: AGHT+IFpI3GL5cse+8n+ih1oF0AV0V9hqADSW+14D/yEjGe7vAb5o0N9WY3TIiFao6rN6HuitLNGGw==
X-Received: by 2002:a05:6000:2089:b0:3eb:5245:7c1f with SMTP id ffacd0b85a97d-40e429c9c58mr19095049f8f.2.1759220494580;
        Tue, 30 Sep 2025 01:21:34 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 01/18] docs/devel/loads-stores: Stop mentioning cpu_physical_memory_write_rom()
Date: Tue, 30 Sep 2025 10:21:08 +0200
Message-ID: <20250930082126.28618-2-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Update the documentation after commit 3c8133f9737 ("Rename
cpu_physical_memory_write_rom() to address_space_write_rom()").

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 docs/devel/loads-stores.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index 9471bac8599..f9b565da57a 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -474,7 +474,7 @@ This function is intended for use by the GDB stub and similar code.
 It takes a virtual address, converts it to a physical address via
 an MMU lookup using the current settings of the specified CPU,
 and then performs the access (using ``address_space_rw`` for
-reads or ``cpu_physical_memory_write_rom`` for writes).
+reads or ``address_space_write_rom`` for writes).
 This means that if the access is a write to a ROM then this
 function will modify the contents (whereas a normal guest CPU access
 would ignore the write attempt).
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:21:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133831.1471906 (Exim 4.92)
	(envelope-from )
	id 1v3VcK-00087F-DR; Tue, 30 Sep 2025 08:21:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133831.1471906; Tue, 30 Sep 2025 08:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VcK-000878-AP; Tue, 30 Sep 2025 08:21:48 +0000
Received: by outflank-mailman (input) for mailman id 1133831;
 Tue, 30 Sep 2025 08:21: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 1v3VcI-0007Nn-Ee
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:21:46 +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 80e55687-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:21:46 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-46b303f7469so38468355e9.1
 for ; Tue, 30 Sep 2025 01:21:45 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e5c3cad50sm8272675e9.3.2025.09.30.01.21.43
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:21: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: 80e55687-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220505; x=1759825305; darn=lists.xenproject.org;
        h=content-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=uVuWODNllLBcWHkHdEzk+20qcWtQ6YA1oYWBzMhXpCQ=;
        b=oigqoUBh0Kir4Us1OzG1+OnIJdK5wmw/a9qhXj5kjyJCs5G9IlrhRS7vKrDoPU9wY8
         Jj9jsGGShHfKuVNxLbokezI2AFcvbSdk8rhKLSNk8Ocf6E3QzAp005zVfg/Xqcpbofje
         c4CGAJZg6ny7f6U4Qe1D0RKc4KuiTv7pLHTWWoT7S9BHJTDT/xod+ijb81nfkRplWTJi
         IS3IXfmEH3tNY4d65xgPRQ7FAgZlKAjaDiyVJP1e2BWjuQqWwKuZfAbHSsrg6dn6T/cp
         UNUybVYx7CFroUn/mpiFaUtgj0aX4VvaJt6Z6lbhfwG+g6ZNQAVPO0tNT4o2MiVyr1jz
         KoUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220505; x=1759825305;
        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=uVuWODNllLBcWHkHdEzk+20qcWtQ6YA1oYWBzMhXpCQ=;
        b=OYAtEYRnmo7fdvvYR7y51kPqDt+uoBUaNvCSOpHyjqV0AcyX7OkgKyga3R/+dXIZT+
         oIo/cVhyH9bqb7Dt/u+k5RPet7O+siosOpGWVd5B5LOi6EyNdwCJMtyHCTAyDZA+o9F/
         7tgFLyLitLCQTTjiC9ON7YekIeL4vDx1cKYUjCR5KTW7O5QKB1yYEX5PwQ2l9q2KboTP
         sf12InpHReMMRmI6nP0ErRDA1vtLMbcw8wu9U+O1Z2ozyNdFz1s8ZF22xwCKS9w95eoA
         Ib/c74mMONA3+Ul+HnIvHlohmkIrKN/kT7n8/UZc+ohNrdaiBX1yLLxzhcgGXMAkeMzR
         B+gw==
X-Forwarded-Encrypted: i=1; AJvYcCUDrl7Ztkck6WStfB3tNw4AbmuXb3Cr+N/dogrVQj5lsoiE3edvsaST7+88MuSlZ3aj04o9MNPlBXI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJ5rYrOiS8i8GXCXxmtPlTfAKoeGa3wUcDM62HbvH0zkGOFH/0
	JZkNKMaN86N3NimYiDXRArk/XVPuNO+gglQqEcrzRZ1sDfp2d5Ty8r09WfxOlklHd5c=
X-Gm-Gg: ASbGncvEMZG92zz9unm7X0z5JVoEJ73Ani/vLBJPLWuyAClOvxxXrp6GlnwOGorplA7
	D/7mxDGAR0LatTjrnuIOYiTQ8O5Rwa8Dwe3EFNqYf3fIRxPZE+mVgMA07Ukt2UQfdE1i6vmgOO/
	dbjaxJm+PAprGvzeTL+vF4Ecz04/IyeCvK5yi8MO7zoUp7JrCPcEXjFMJE5m6HTXyCW+jGHmeRB
	DFguTgaMtyop+h0OGoXvQxsSODQgKQyW5n7c42MDGmdwDWBUaVGA9BKgRVbkJNlktODPMgUfBSy
	DSH28ZYjP/1i3kPhHfNnAGPvb0dMVSFHo3uMNeVbZ2xpELJtUUeSLhUBLHrVT8qyuXfcE7Af6iP
	S6JtQlRAlfrLOg2m+E1Hr5aTNC1KBeAZi++VeMhU0B52oW7NI7t4LIiReTXAy7TqgpPbY8s2XkK
	2KI4E+l/d1MiMImt2UY/QuPRa3yV6+fZY=
X-Google-Smtp-Source: AGHT+IEnN1+Dj0G5eE22oo/LVcWK6MF1t2TvnNSxkl29p00iMJks8dqgYIqx9W0IIiNQ+maQ1TKmXg==
X-Received: by 2002:a05:600c:1e85:b0:45d:d5df:ab2d with SMTP id 5b1f17b1804b1-46e32a03456mr188255845e9.26.1759220505370;
        Tue, 30 Sep 2025 01:21:45 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 03/18] system/memory: Factor address_space_is_io() out
Date: Tue, 30 Sep 2025 10:21:10 +0200
Message-ID: <20250930082126.28618-4-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Factor address_space_is_io() out of cpu_physical_memory_is_io().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
---
 include/system/memory.h |  9 +++++++++
 system/physmem.c        | 21 ++++++++++++---------
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/include/system/memory.h b/include/system/memory.h
index 3e5bf3ef05e..546c643961d 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -3030,6 +3030,15 @@ static inline MemoryRegion *address_space_translate(AddressSpace *as,
 bool address_space_access_valid(AddressSpace *as, hwaddr addr, hwaddr len,
                                 bool is_write, MemTxAttrs attrs);
 
+/**
+ * address_space_is_io: check whether an guest physical addresses
+ *                      whithin an address space is I/O memory.
+ *
+ * @as: #AddressSpace to be accessed
+ * @addr: address within that address space
+ */
+bool address_space_is_io(AddressSpace *as, hwaddr addr);
+
 /* address_space_map: map a physical memory region into a host virtual address
  *
  * May map a subset of the requested range, given by and returned in @plen.
diff --git a/system/physmem.c b/system/physmem.c
index 86422f294e2..84d7754ccab 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3359,6 +3359,17 @@ bool address_space_access_valid(AddressSpace *as, hwaddr addr,
     return flatview_access_valid(fv, addr, len, is_write, attrs);
 }
 
+bool address_space_is_io(AddressSpace *as, hwaddr addr)
+{
+    MemoryRegion *mr;
+
+    RCU_READ_LOCK_GUARD();
+    mr = address_space_translate(as, addr, &addr, NULL, false,
+                                 MEMTXATTRS_UNSPECIFIED);
+
+    return !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
+}
+
 static hwaddr
 flatview_extend_translation(FlatView *fv, hwaddr addr,
                             hwaddr target_len,
@@ -3755,15 +3766,7 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
 
 bool cpu_physical_memory_is_io(hwaddr phys_addr)
 {
-    MemoryRegion*mr;
-    hwaddr l = 1;
-
-    RCU_READ_LOCK_GUARD();
-    mr = address_space_translate(&address_space_memory,
-                                 phys_addr, &phys_addr, &l, false,
-                                 MEMTXATTRS_UNSPECIFIED);
-
-    return !(memory_region_is_ram(mr) || memory_region_is_romd(mr));
+    return address_space_is_io(&address_space_memory, phys_addr);
 }
 
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:21:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133828.1471876 (Exim 4.92)
	(envelope-from )
	id 1v3VcD-0007OU-Gc; Tue, 30 Sep 2025 08:21:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133828.1471876; Tue, 30 Sep 2025 08:21: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 1v3VcD-0007ON-Dg; Tue, 30 Sep 2025 08:21:41 +0000
Received: by outflank-mailman (input) for mailman id 1133828;
 Tue, 30 Sep 2025 08:21: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 1v3VcB-0007Nn-E6
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:21: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 773d3e50-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:21:29 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-46e3af7889fso31676175e9.2
 for ; Tue, 30 Sep 2025 01:21:29 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab31f1dsm257244235e9.13.2025.09.30.01.21.27
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:21: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: 773d3e50-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220489; x=1759825289; 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=YvhoIhSsQDGRzJiqmuuLIQQZhU1t8TAbJtfU17YXnRc=;
        b=CmJEbr26SXJ88WCjc2yFgqTlkUa1LiUGCPFnCXDE5b4qpQGLrE9KYyfCi48ulS9+Di
         3aj9S/p1hMKM2mYVMuGm+C8x7PMAjjZmByLpBHl4E4JHLpk7oxZ/Z2+pLKMv09jqGhQm
         KZfJUh84ajeWz6wOmmuaCDD1l7auUB7YtbJMArW3Us6FV4ppr9hDpGStBxNsJl8ShqQD
         l1+7wah+6AfO6zJYmF8SjnBRnqXd3+Q5VidlxHqibxaPnJjMn4FTNAeayhNEW8PfUpje
         Zl7N/IiCx/vquFwA/2BTd32GGDmO88+Xmd9Kqit550CnNEMoOzrJwA5vLpfUj1W/9qiE
         1Ngg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220489; x=1759825289;
        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=YvhoIhSsQDGRzJiqmuuLIQQZhU1t8TAbJtfU17YXnRc=;
        b=LoQuukdXrKej9zU15W4wEeTOyc3DC+7gLQsUHHfojuM7czbjU/xo39q3vADAMfmeYH
         AaZX6ufbxj8WA25giLpP8t1grW5XrfE0qDwdKwOUXFWKSx1TThSFrDPR/PKi+guU94pB
         GmM3qecql+2JbIWQesdNvMJTr64hb8yIqxwwFwOuYdmciFTOjUcFG5Ehz4NbRCq6T+z0
         nW45AhcTpve9+4/i8Lj2HjJBblJYqg+avQoQnY5oQFJiYEAjyD2PaWinb47os2BbyQ50
         bXhDThVbHjIhj1zFu2xVak1jS0sojOCMf50zVMGkUVvRAit+i8Kqaeeb+567v7gvoSwq
         z5aQ==
X-Forwarded-Encrypted: i=1; AJvYcCUNEZ2CIRh0fKe1VXqAx9jrZxObtYHCxD7HnmavJgWCdUZmbdsczXxiO6cEOAd6xTzKyBthSc5X67g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNyUowp14oAu4/ttrjv8hEtXjLl8UUlPPZv+9TBnWC4nQQNi6c
	fszVQnoCw2eGqZktzwaPj1NjH0Dy3yS0/73cQOQr4dthEMjsGJ21Kj6Kr2BCakWsmBQ=
X-Gm-Gg: ASbGnct65jDNXH6G/yVwrMIX46rBPmL94Vq5aohhKqHyeyFlgsIi7Q7W+ZeMX0mG+c2
	x2u9JEHADApBEc2UYoXUTjmbU+Cd93cnZS+BwnQ3MHMItpaFiYDd4jQtqRReCHeKgmRsaJQJ9kf
	LMlCYgNCmyrXS7hQ2nQGG4Gw4oooy2gmQ6kjU9Ds6DE9SmrvjpbOVknbg2wO2S07dqBHOmTGp44
	CCCZ66x8ceNyRcAsGnQ0CmSt9O4wh2dP+PlALPFqnEf1XuitW/zMi3b5V+gWwU/I9YiDrsb1bo0
	eud1/g6Bc0RxuTrwSVjAU8dOIWIQNW1F3ia2ta2DM4B4ZdFN31snTUsAiKj4C+6yTieJvOLz8gR
	DZlwmQBYNbQ9p6H2Pgsl0o0wYKvRUQS8Ems5Gupk8rKGtwUOMzKwTnK08ZIs9+hPRd61xuDE2LC
	sW8Y/7roFRTUt/7/4pZ6JZ
X-Google-Smtp-Source: AGHT+IH0LOZYhQvlCCwRE6HguOW9UpuwkFMjTOLA/D/C2ktVUpzuFK1TrAy7o+BecbtxQsJYTDH8eA==
X-Received: by 2002:a05:600c:8209:b0:46e:376a:c9db with SMTP id 5b1f17b1804b1-46e376acfbbmr166369605e9.26.1759220489083;
        Tue, 30 Sep 2025 01:21:29 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 00/18] system/physmem: Remove cpu_physical_memory _is_io() and _rw()
Date: Tue, 30 Sep 2025 10:21:07 +0200
Message-ID: <20250930082126.28618-1-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Since v1:
- Removed extra 'len' arg in address_space_is_io (rth)
Since v2:
- Fixed vhost change
- Better describe cpu_physical_memory_rw() removal (thuth)

---

The cpu_physical_memory API is legacy (see commit b7ecba0f6f6):

  ``cpu_physical_memory_*``
  ~~~~~~~~~~~~~~~~~~~~~~~~~

  These are convenience functions which are identical to
  ``address_space_*`` but operate specifically on the system address space,
  always pass a ``MEMTXATTRS_UNSPECIFIED`` set of memory attributes and
  ignore whether the memory transaction succeeded or failed.
  For new code they are better avoided:
  ...

This series removes:
  - cpu_physical_memory_is_io()
  - cpu_physical_memory_rw()
and start converting some
  - cpu_physical_memory_map()
  - cpu_physical_memory_unmap()
calls.

Based-on: <20250922192940.2908002-1-richard.henderson@linaro.org>
          "system/memory: Split address_space_write_rom_internal"

Philippe Mathieu-Daudé (18):
  docs/devel/loads-stores: Stop mentioning
    cpu_physical_memory_write_rom()
  system/memory: Better describe @plen argument of flatview_translate()
  system/memory: Factor address_space_is_io() out
  target/i386/arch_memory_mapping: Use address_space_memory_is_io()
  hw/s390x/sclp: Use address_space_memory_is_io() in sclp_service_call()
  system/physmem: Remove cpu_physical_memory_is_io()
  system/physmem: Pass address space argument to
    cpu_flush_icache_range()
  hw/s390x/sclp: Replace [cpu_physical_memory -> address_space]_r/w()
  target/s390x/mmu: Replace [cpu_physical_memory -> address_space]_rw()
  target/i386/whpx: Replace legacy cpu_physical_memory_rw() call
  target/i386/kvm: Replace legacy cpu_physical_memory_rw() call
  target/i386/nvmm: Inline cpu_physical_memory_rw() in nvmm_mem_callback
  hw/xen/hvm: Inline cpu_physical_memory_rw() in rw_phys_req_item()
  system/physmem: Un-inline cpu_physical_memory_read/write()
  system/physmem: Avoid cpu_physical_memory_rw when is_write is constant
  system/physmem: Remove legacy cpu_physical_memory_rw()
  hw/virtio/vhost: Replace legacy cpu_physical_memory_*map() calls
  hw/virtio/virtio: Replace legacy cpu_physical_memory_map() call

 docs/devel/loads-stores.rst            |  6 +--
 scripts/coccinelle/exec_rw_const.cocci | 22 -----------
 include/exec/cpu-common.h              | 18 +--------
 include/system/memory.h                | 16 +++++++-
 hw/core/loader.c                       |  2 +-
 hw/s390x/sclp.c                        | 14 ++++---
 hw/virtio/vhost.c                      |  7 +++-
 hw/virtio/virtio.c                     | 10 +++--
 hw/xen/xen-hvm-common.c                |  8 ++--
 system/physmem.c                       | 51 ++++++++++++++------------
 target/i386/arch_memory_mapping.c      | 10 ++---
 target/i386/kvm/xen-emu.c              |  4 +-
 target/i386/nvmm/nvmm-all.c            |  5 ++-
 target/i386/whpx/whpx-all.c            |  7 +++-
 target/s390x/mmu_helper.c              |  6 ++-
 15 files changed, 92 insertions(+), 94 deletions(-)

-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:21:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:21:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133834.1471915 (Exim 4.92)
	(envelope-from )
	id 1v3VcP-0008U6-Km; Tue, 30 Sep 2025 08:21:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133834.1471915; Tue, 30 Sep 2025 08: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 1v3VcP-0008Tv-Hx; Tue, 30 Sep 2025 08:21:53 +0000
Received: by outflank-mailman (input) for mailman id 1133834;
 Tue, 30 Sep 2025 08: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 1v3VcN-0007Nn-QA
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:21:51 +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 841659e9-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:21:51 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3c68ac7e18aso3798086f8f.2
 for ; Tue, 30 Sep 2025 01:21:51 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc5602f15sm21609359f8f.39.2025.09.30.01.21.49
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01: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: 841659e9-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220511; x=1759825311; darn=lists.xenproject.org;
        h=content-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=jPaFfZE+Vm6W3t7QC31lKwf41cuqTfJ0BWTKMrsHvkU=;
        b=mG0+b/VURtvrMm/lC9C4YR0fWETRSotoiXmjoEiR8HEpQfE0oGlzA6p34Yi1/fvw3T
         f8uBL3+UbGwfacsykLe82zJIZEGi76RE2352SNv3IFB1SkKTHaT+J10Tr+r6ijo1OXvp
         v1OjuWmO2aW0xCqayOsYgYl3R5JMCHbvuuQYNiwVN0N+BFkJCaG2CNHPEGi7zXssZ2jO
         eaVGyf7KBxfzQ/qwVefJletBVUZMr7jQLHWzXqhFDgFioV4JRdOerxaJ9+Aqk/gqBfKA
         kd4sof/eSGiAAlQrBWy9HFksct1Kj9sLGWK3iD9XmMu/MIT00dgA8jS9jYtf2qX8TPvX
         K2lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220511; x=1759825311;
        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=jPaFfZE+Vm6W3t7QC31lKwf41cuqTfJ0BWTKMrsHvkU=;
        b=VSFybwbKHWv65+0Vhk5LuvH2FtTbS4olcw4rvpeDl3F7PsN//157zZemEPNrIJ+2qt
         nkFCYC/prMeikmZd3Uz+11MfJieUFGY8sZmnjyV9+ZgBaxMLlVSDyngklOKDIEdDwZeR
         zF2MEQDvyGzcVLvEEyB46dCT2WmsfpCKOq1f98tfJU4FEw8NrQlmbksHM1Ty6OD4+RrL
         7jSbCSmM9vZjW1yy+U9MGWj0p3kcWUXpNJVSZTIBYIeM23D9cGa5zdgKaI8RmGewRKLd
         XJ90v7BaLD9wfkUH7hh7rygSz3W9LDxxzeacAlomm3rfXB1w7d5Q2WLh05DnrBhQ1Prk
         u9YA==
X-Forwarded-Encrypted: i=1; AJvYcCUeU1vVRWDgZ4WGJRpC36tR5Hu5vmlDIe38cF7BsfPBt5xawJmWisvA9ydQ2jSsEcV5bgz7CU2aCcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDLp+pyETzZuOS/71cVhAiUNNPrMlkLdMeFeeqwx9k7L6xwWyh
	nEK5yMFa2DVVIK+MqX32y7qAVGV72VWajemB5YfTKGyCJdzFqeZ7gDVa4ZuUe3LoyHw=
X-Gm-Gg: ASbGnct7/zH0guN24g3BI/v87zOHuRQkOlhbryG9ei5AKnI+Hh6wOthYJ6Dr/MhB+9H
	5EqqanQBPa/CwuaVYCjOmAdKBVqRpx4scgFsQCIyz/mqCGHoLYG6TDzP3LUPPRwetutxZGR0yIR
	9GQfHt46QPP+MhlgJTIexw5fNAbV7xUt1Ypa6altSjP8JAgFPnh6jktM5nXcBnQI3pyoe+QxAbu
	tAzekf9fpDI9LfVKzcWrgVXkr/fefb4mPtRIcxPFeE1iIdVxn++5Fx0z6GLtZWHtZzvZL2+SV4x
	DgSSYUY26xEYEakG4PEilKoStWBH/Xb53AVReoVGpQzl2GEBz6LJJLMULpFBFbwXJ0MJjqzJfxo
	zO1XWKgvdvfnSDgH+6TnPWUVCr/lXaJ889n9ss3wIaIDcPxLUsglufIgJdbYx8Laz0W8l1HW6bC
	hyrSUtWRX/weBxo7xTr02u
X-Google-Smtp-Source: AGHT+IEB8eNGO8ibaj4OUUkCL1Gk/lot4nZRiwg5YPnw3XMPBC9mULq1peqy0gUd0OsdrauuTBslPQ==
X-Received: by 2002:a05:6000:2511:b0:3d8:3eca:a978 with SMTP id ffacd0b85a97d-40e44682229mr16305754f8f.21.1759220510700;
        Tue, 30 Sep 2025 01:21:50 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 04/18] target/i386/arch_memory_mapping: Use address_space_memory_is_io()
Date: Tue, 30 Sep 2025 10:21:11 +0200
Message-ID: <20250930082126.28618-5-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since all functions have an address space argument, it is
trivial to replace cpu_physical_memory_is_io() by
address_space_memory_is_io().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/arch_memory_mapping.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/i386/arch_memory_mapping.c b/target/i386/arch_memory_mapping.c
index a2398c21732..560f4689abc 100644
--- a/target/i386/arch_memory_mapping.c
+++ b/target/i386/arch_memory_mapping.c
@@ -35,7 +35,7 @@ static void walk_pte(MemoryMappingList *list, AddressSpace *as,
         }
 
         start_paddr = (pte & ~0xfff) & ~(0x1ULL << 63);
-        if (cpu_physical_memory_is_io(start_paddr)) {
+        if (address_space_is_io(as, start_paddr)) {
             /* I/O region */
             continue;
         }
@@ -65,7 +65,7 @@ static void walk_pte2(MemoryMappingList *list, AddressSpace *as,
         }
 
         start_paddr = pte & ~0xfff;
-        if (cpu_physical_memory_is_io(start_paddr)) {
+        if (address_space_is_io(as, start_paddr)) {
             /* I/O region */
             continue;
         }
@@ -100,7 +100,7 @@ static void walk_pde(MemoryMappingList *list, AddressSpace *as,
         if (pde & PG_PSE_MASK) {
             /* 2 MB page */
             start_paddr = (pde & ~0x1fffff) & ~(0x1ULL << 63);
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_is_io(as, start_paddr)) {
                 /* I/O region */
                 continue;
             }
@@ -142,7 +142,7 @@ static void walk_pde2(MemoryMappingList *list, AddressSpace *as,
              */
             high_paddr = ((hwaddr)(pde & 0x1fe000) << 19);
             start_paddr = (pde & ~0x3fffff) | high_paddr;
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_is_io(as, start_paddr)) {
                 /* I/O region */
                 continue;
             }
@@ -203,7 +203,7 @@ static void walk_pdpe(MemoryMappingList *list, AddressSpace *as,
         if (pdpe & PG_PSE_MASK) {
             /* 1 GB page */
             start_paddr = (pdpe & ~0x3fffffff) & ~(0x1ULL << 63);
-            if (cpu_physical_memory_is_io(start_paddr)) {
+            if (address_space_is_io(as, start_paddr)) {
                 /* I/O region */
                 continue;
             }
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:21:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:21:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133841.1471926 (Exim 4.92)
	(envelope-from )
	id 1v3VcT-0000Qv-Ub; Tue, 30 Sep 2025 08:21:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133841.1471926; Tue, 30 Sep 2025 08:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VcT-0000Qk-Qb; Tue, 30 Sep 2025 08:21:57 +0000
Received: by outflank-mailman (input) for mailman id 1133841;
 Tue, 30 Sep 2025 08:21:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3VcT-0007Nn-4t
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:21:57 +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 87494397-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:21:56 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-46e2e6a708fso36248755e9.0
 for ; Tue, 30 Sep 2025 01:21:56 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f65290sm44620345e9.13.2025.09.30.01.21.54
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01: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: 87494397-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220516; x=1759825316; darn=lists.xenproject.org;
        h=content-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=TmN6KZRBDFIwLcWnEVDqbz1WHRvv8u+lRYP5Aq5aiQ8=;
        b=Ae14vR7/JPhbxTl8racrKMnzXpba7ajvr0ekXTb9hzMu4IctZDkBAOr6vRYPyBStn7
         47wbUiYVrPugbEaK4Qpc6m5MAJfwmnE/nOLyRpdG/3jFJOLS8LNTRIfsfC1Ou4aIYVtj
         sgwySGDNSYT3NMv2ZDQHoYasUiMflZ4X5GUe8thvEJP0SI6jk3wXDZ2FeT8BErCTRKJt
         KMb7Yzgze+sbJBjQj5HItt/Vm5Asb8tFfZFbbwH7M2xP8+e+QQvu2AewEg+FEFQw174C
         wVwZMVKcAcc6I0Fe8f/OMeDFKOn2mbWmDBMRTE8fFkPcMNLgjcRqyszD+uVD2i8B8+Ip
         MD9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220516; x=1759825316;
        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=TmN6KZRBDFIwLcWnEVDqbz1WHRvv8u+lRYP5Aq5aiQ8=;
        b=HurSdeEQGng3G27bjnGZcysbVyYcK4K1ToxuTWDzlQ6L/wQcj+1+rv6A9KAVMQGrtL
         e6/vF0a9mhh73xK/EtJIzQN3BefQ426/j/jL8ZShFWQ6fUh4EML6KcoPuUOq7RW8LXcd
         mUld6Ww2I3C1beUw19Mp5KHbwGuOhyruZKSdPikRo2rya3W81N4nwcHp8ij3xWyDPFwd
         +RSGECghc+kbqieVhf2ztb8ktzs1tNVRj5oEgHfc0R6d8YQ4FmNpEjkw1ODUOONeUejN
         yeIVoMUUloBRw1Ft2qtjhNFOrOW85ro6mnAM1o+GEFDY2KAMIELz2/6INuTFmtfzetWu
         ZJnA==
X-Forwarded-Encrypted: i=1; AJvYcCXef4yNFiHpnBikLdU9BIn5IF8jBRoE0gQ+rinmFIQW27L9+6bYgV14d9hdqZD+HzLHZCofcvaDF7E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzyje0AmrYxRaW5hX4G5S7I0E7ggomSn5tlm3H9zvu0zX24eiBc
	F3P+Z3v0aMG1qC2aa1Btbkchl/PqG/6fJgzPTmD10Og3qQ5RlxeO/ddGbus0704eTZ4=
X-Gm-Gg: ASbGncuqJbH7wkXq01IPPqCc5mqd1a3x4msKHq6ngeUo0OUClqdbc8DQ5LxTm3d9spR
	GWr05sMC9qbPpf39DxbPgNDdQIGMKWFm6A4VT1E8xayXu5SfUiykyWRZsB+GltYg8wmLh46HIs/
	702yhq9iPzhV8WLOrbV4larqQGsd/sJiCfzDZDHlmhmEnb8dvCVRyXTTyX1QFCpJyqo5Qr84IZM
	xwYoxKl/FJpvyiEnwA9tLRrd+m9Jlu3gq+0KWFQJp7B3aso9RKsaEOwa51J9Iq2HIaw9/JsAjEr
	8Cnj0wG5D7IJNde/WBf1ILDob7gAiCvVZmM/5vzMiLbNUBeZbjSsvsCRnPlflSHkdf4pD6o5iA3
	Apd8s+68XM6PxHvL+yd87WDkxDYjRXvgKeZjAXSciECbMYwVdfmmfyjrP/nNLxpSqBcUFQDY641
	g7VSAhkwt4Af/7uM608en7z9vQz7/Fcno=
X-Google-Smtp-Source: AGHT+IFRoVQqdg8pFriDfOKg6AJHeYajBA5OHZoOOnjeKEw77YQUzMpfQKsIByPubJl8mIXC2txRhQ==
X-Received: by 2002:a05:600c:8b16:b0:468:7f92:5a80 with SMTP id 5b1f17b1804b1-46e329fbd2bmr146354195e9.27.1759220516099;
        Tue, 30 Sep 2025 01:21:56 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 05/18] hw/s390x/sclp: Use address_space_memory_is_io() in sclp_service_call()
Date: Tue, 30 Sep 2025 10:21:12 +0200
Message-ID: <20250930082126.28618-6-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When cpu_address_space_init() isn't called during vCPU creation,
its single address space is the global &address_space_memory.

As s390x boards don't call cpu_address_space_init(),
cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.

We can then replace cpu_physical_memory_is_io() by the semantically
equivalent address_space_memory_is_io() call.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
---
 hw/s390x/sclp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 9718564fa42..f507b36cd91 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -16,6 +16,7 @@
 #include "qemu/units.h"
 #include "qapi/error.h"
 #include "hw/boards.h"
+#include "system/memory.h"
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/event-facility.h"
 #include "hw/s390x/s390-pci-bus.h"
@@ -301,6 +302,7 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     CPUS390XState *env = &cpu->env;
     SCLPDevice *sclp = get_sclp_device();
     SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
+    AddressSpace *as = cpu_get_address_space(CPU(cpu), 0);
     SCCBHeader header;
     g_autofree SCCB *work_sccb = NULL;
 
@@ -308,7 +310,7 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     if (env->psw.mask & PSW_MASK_PSTATE) {
         return -PGM_PRIVILEGED;
     }
-    if (cpu_physical_memory_is_io(sccb)) {
+    if (address_space_is_io(as, sccb)) {
         return -PGM_ADDRESSING;
     }
     if ((sccb & ~0x1fffUL) == 0 || (sccb & ~0x1fffUL) == env->psa
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:22:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:22:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133853.1471937 (Exim 4.92)
	(envelope-from )
	id 1v3Vcb-00017z-G0; Tue, 30 Sep 2025 08:22:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133853.1471937; Tue, 30 Sep 2025 08:22: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 1v3Vcb-000171-AY; Tue, 30 Sep 2025 08:22:05 +0000
Received: by outflank-mailman (input) for mailman id 1133853;
 Tue, 30 Sep 2025 08:22: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 1v3VcZ-0007Nm-OK
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22: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 8a696d84-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:22:02 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3f0ae439b56so3302790f8f.3
 for ; Tue, 30 Sep 2025 01:22:02 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fac4a5e41sm22972926f8f.0.2025.09.30.01.22.00
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01: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: 8a696d84-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220521; x=1759825321; darn=lists.xenproject.org;
        h=content-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=rlQqoXg6at6m3NCWUmLz6YxBYJSCTlYqTL2bdBtbhz0=;
        b=aCqALJArECxjIi6VpSWLtjAGn5iXR3I1ZRNnK1fFpf4L45np3+8XqigkkzuUHn3hW0
         zA8J9tOT+IHFBf8DN9ynl5hjEaYTypeu7lywEKt+vqH+/HnTfloKIa2oLa+3nfH2qPbB
         ynL5Ejl7A/sfvAWbFWimwzqwBkEfq7XzMp9WVUdZzwHGgebT8MzqS8EK6xpAsFvb5bBz
         elGwurk2TQOvsnMGhCFJVPgJSTvWsyS7+ABbCV9lCxA83oLvf85+EbGJPCfdBqjCz5Tw
         Y1gulr6LmnctvlTOkAY5XvyBxt4f0mFZPIy9PKMM6O32Q+BtWXsqFzrgKNSU52QoepU3
         33bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220521; x=1759825321;
        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=rlQqoXg6at6m3NCWUmLz6YxBYJSCTlYqTL2bdBtbhz0=;
        b=JX+1vkdiYpbHAcYpTr9XxetBjG/h9Ftoci3IXN3PABs263H1iOBpWlP9VlQ8xk/EBy
         lpofyhzb3tNGueeeL1k6K5e8rj9/tX0MqpKgsBNjqfciQ9WtzY0XgDngUSdojiOa2hlL
         rE4azQxYXLVTMSgMCTF9q9LAqqOnVud4r5ICcyhAKkF6MEAq0YVO9OgwkU5T4jXz5eJz
         MI4UnrUfIfk2qrdRHf6A4VGj+gDPlNXNW07XI01SRPTWvSAIV2yLwdi5CbnhATrN480Q
         4wHwJMPQy4Z/i2huxMyl1Yhmx7KIyZz+wx+FrV1g3bTyygvSv+nRe6IGIAYRXbbf+kwt
         IY/A==
X-Forwarded-Encrypted: i=1; AJvYcCWGCDgmZ5XzgRYzmvdrJNypjS1awIOJon68Ary30c4+EpCFwqXuiPi0JSmz912HEkO+u96vTg8bho0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxl+Xu7+K05/5Egxq2Ut+0J7WHl9ZzaCtu2jNv+wUCtFU8x+1mP
	7soNy80xuLrYU9Fn9kMe8Vku8XBfsIuEw3iHxh7bUokb5qMip3d6nDgyNbk22U5hBr0=
X-Gm-Gg: ASbGncvSc5AkQqtWNdvYprZarT4PWP2qp/OZXOfomd1aMIFysQVJNqT+moiAinqVfJG
	e++i48BwVUK+n6go5C73r69rxKOXnTC6eyi81Wk/gS0IdzkHvdnmUMEigbjn3FM9rd0jQe8xE1j
	o8+H1PCP2/3z5a2OYASTe3TDMWrZUzlyTM9rsJygpY8XcWGLd0ZSh1U375f3CPxN8hh5faoSE/U
	/uTK/sJo45+tWhM55NmI1/FDCJXtOvcgbp3WJ7GqVVfRjBC6aurdyl6pHnu0q7DeiXABbQo4a5/
	yKGz0AnWwaKMw29otjRhY+LkkbnxfWA0jZxIY+xj1aZFJswIXnIO/WPUU7OyOT4cSS6+Hw8TWlM
	SxYk2qFQnprXA1u3p7+/q08jD4eU3cv/2mBE67PrIikThWD2CPL7G2lTK2lDztADp/twrlLmui3
	EIRHTguzGXZurpBcKFE+9A8V1MhDmJ72Y=
X-Google-Smtp-Source: AGHT+IGxp9mmy7B4YaVXtK8axEEppjEFlOJUhOlUxG1XXBFZ2PBviuJyAi3OzbI29QHLpWomSM6JGg==
X-Received: by 2002:a05:6000:22c2:b0:3e7:ff32:1ab with SMTP id ffacd0b85a97d-40e4b294f33mr14571301f8f.50.1759220521460;
        Tue, 30 Sep 2025 01:22:01 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 06/18] system/physmem: Remove cpu_physical_memory_is_io()
Date: Tue, 30 Sep 2025 10:21:13 +0200
Message-ID: <20250930082126.28618-7-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are no more uses of the legacy cpu_physical_memory_is_io()
method. Remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 include/exec/cpu-common.h | 2 --
 system/physmem.c          | 5 -----
 2 files changed, 7 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e413d8b3079..a73463a7038 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -149,8 +149,6 @@ void *cpu_physical_memory_map(hwaddr addr,
 void cpu_physical_memory_unmap(void *buffer, hwaddr len,
                                bool is_write, hwaddr access_len);
 
-bool cpu_physical_memory_is_io(hwaddr phys_addr);
-
 /* Coalesced MMIO regions are areas where write operations can be reordered.
  * This usually implies that write operations are side-effect free.  This allows
  * batching which can make a major impact on performance when using
diff --git a/system/physmem.c b/system/physmem.c
index 84d7754ccab..dff8bd5bab7 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3764,11 +3764,6 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
     return 0;
 }
 
-bool cpu_physical_memory_is_io(hwaddr phys_addr)
-{
-    return address_space_is_io(&address_space_memory, phys_addr);
-}
-
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
 {
     RAMBlock *block;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:22:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:22:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133866.1471946 (Exim 4.92)
	(envelope-from )
	id 1v3Vch-0001nz-Mp; Tue, 30 Sep 2025 08:22:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133866.1471946; Tue, 30 Sep 2025 08:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Vch-0001nq-H3; Tue, 30 Sep 2025 08:22:11 +0000
Received: by outflank-mailman (input) for mailman id 1133866;
 Tue, 30 Sep 2025 08:22: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 1v3Vcg-0007Nm-31
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22: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 8dabc4a3-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:22:07 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3ee64bc6b90so3554851f8f.0
 for ; Tue, 30 Sep 2025 01:22:07 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc6921bcfsm23056408f8f.43.2025.09.30.01.22.05
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: 8dabc4a3-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220527; x=1759825327; darn=lists.xenproject.org;
        h=content-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=YkYmQo8nriy/yGfh4HWmKxNmJbyJBkEcEbiWP0BNxvs=;
        b=dNxCbGWbONCGtrKZUodXj6K1M4g6+5J8ZprI9GH3rCZ5/GIsijAuZsw4hEuF/2olLF
         q0UeB8RsY9hYrG/wJa2DomCym4XFYDvkLx34/1Ecv746CNTuNWv8xqR6WM/uKeCMogo8
         fDSO/1ku1HsBGjVdToADxNVB2ATJG8YDyaSUXCZ9fIzC9QMEiXCv4VkNloQ1jS2UX1gn
         5AoBoyS+63azvRpM6IGdzbGAX/SzUpBlFWtAo7RHWGtDHG1AhQocV1PLfsT9JFC0zvWC
         Ow3c0IhX1Bnt1Jxds33/dbKYkoTDJSV+BRnHadouZE6DLheIFzdd1GSYn7gQPJGVdaRx
         kL5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220527; x=1759825327;
        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=YkYmQo8nriy/yGfh4HWmKxNmJbyJBkEcEbiWP0BNxvs=;
        b=FhGyJVtNv9By/IgE/ASKWJR7J889IZ4SBGV/JRu/pcO3we7tyPu7BtlcVWWAgMu/5Z
         vbcje32pnfZPYJvBOqunlk52JF4Ywg4HtzJe9gs7W1kmhtgS+9JvHnbbEo7Og3ToDC2D
         D2T4+8/nhfLiDUjEzjOkj0wAjJ1p1LlBJ1vRMiVcfzpR2OF4xEDAKZoa10Yp5K2yzpcg
         Qg7NZUEbk3mo2ElIkuHeilkqjv75YA1N3eHkfT5zWiKrVHSaKl+ToK3JDT8eKtlHX/B7
         /6hnmpkdk8FyNerdyzub4BlBXiAzb8W1B3FpivpMDWZR1Z8X7fJdtgcXbSe6c7+gaEpL
         NKgw==
X-Forwarded-Encrypted: i=1; AJvYcCV99CW27X1yQxYWx93zXMQRfMf1s298X8yWzXM2hc5LgXbi1xfXuwW2k6mDhROKk02RIOy3tCiD5C8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDP0h8/ue4iYI7JVchzkL7RzF9y6FIS/f9ddF09KdUolVTN+Fi
	s724Uk0gOgv3BPbRN4Er2Fyy/9DPUyq2cb5Y5FmiHuPoKJmXgpgrKwtyjVGumCpsG7E=
X-Gm-Gg: ASbGncstcq66Ve8yge6MhsvBKuVHL9AL+jdQMOhCkCswD+UCRBdqp8iYPkhrqKQ/6w3
	i/czrNnzZLgnsiEbVx9/faMtHbhqDJ01tgnFa10061All+WIbjJe5QdHvums6BfVW1zaPnrfmQN
	v6Ce4h1O6zjkrFCECa/eDrljKC+3/ALwEiaPv8BqeJQ5FlZ6CT9/nqrOD49JrBCkNfxXqY7tMM+
	JAFpo0xGGNBDOS5zwzqifA2nTcKAr8w+VzJfAqhd27MUUEQYOSRPOgNb0kgUkYzcmtlWK07fqf2
	SYTXDpxeJBVADyVxmpDDUKwfqhOnXoJZF9OZ/tjiKKwPORQ93ysYCI5rL6PbqysOx3O6/kezZBA
	ChSeEzhsSUpjKQkTZPS1CehZwj6qvhhm2Y7XYCd7rQfBzaVo6UoUqUnW041JOa1EOy/2ucj5sXD
	joXfyvHf0kfE0mSO9yqXHOc4OCK4/Dg61M8t0CpjbmqQ==
X-Google-Smtp-Source: AGHT+IHzRQHYpgb/DyIfYTEXGiArYWqeYdxWvyGmM8w8s+84+M4R5T3PN9QeVLlNgQQ0W4P8WfSxtg==
X-Received: by 2002:a05:6000:26c9:b0:3d2:9cbf:5b73 with SMTP id ffacd0b85a97d-40e46515110mr15910423f8f.6.1759220526791;
        Tue, 30 Sep 2025 01:22:06 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 07/18] system/physmem: Pass address space argument to cpu_flush_icache_range()
Date: Tue, 30 Sep 2025 10:21:14 +0200
Message-ID: <20250930082126.28618-8-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rename cpu_flush_icache_range() as address_space_flush_icache_range(),
passing an address space by argument. The single caller, rom_reset(),
already operates on an address space. Use it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 include/exec/cpu-common.h | 2 --
 include/system/memory.h   | 2 ++
 hw/core/loader.c          | 2 +-
 system/physmem.c          | 5 ++---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index a73463a7038..6c7d84aacb4 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -156,8 +156,6 @@ void cpu_physical_memory_unmap(void *buffer, hwaddr len,
  */
 void qemu_flush_coalesced_mmio_buffer(void);
 
-void cpu_flush_icache_range(hwaddr start, hwaddr len);
-
 typedef int (RAMBlockIterFunc)(RAMBlock *rb, void *opaque);
 
 int qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque);
diff --git a/include/system/memory.h b/include/system/memory.h
index 546c643961d..dfea90c4d6b 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -2977,6 +2977,8 @@ void address_space_cache_invalidate(MemoryRegionCache *cache,
  */
 void address_space_cache_destroy(MemoryRegionCache *cache);
 
+void address_space_flush_icache_range(AddressSpace *as, hwaddr addr, hwaddr len);
+
 /* address_space_get_iotlb_entry: translate an address into an IOTLB
  * entry. Should be called from an RCU critical section.
  */
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 524af6f14a0..477661a0255 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -1242,7 +1242,7 @@ static void rom_reset(void *unused)
          * that the instruction cache for that new region is clear, so that the
          * CPU definitely fetches its instructions from the just written data.
          */
-        cpu_flush_icache_range(rom->addr, rom->datasize);
+        address_space_flush_icache_range(rom->as, rom->addr, rom->datasize);
 
         trace_loader_write_rom(rom->name, rom->addr, rom->datasize, rom->isrom);
     }
diff --git a/system/physmem.c b/system/physmem.c
index dff8bd5bab7..e0c2962251a 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3215,7 +3215,7 @@ MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
     return MEMTX_OK;
 }
 
-void cpu_flush_icache_range(hwaddr addr, hwaddr len)
+void address_space_flush_icache_range(AddressSpace *as, hwaddr addr, hwaddr len)
 {
     /*
      * This function should do the same thing as an icache flush that was
@@ -3230,8 +3230,7 @@ void cpu_flush_icache_range(hwaddr addr, hwaddr len)
     RCU_READ_LOCK_GUARD();
     while (len > 0) {
         hwaddr addr1, l = len;
-        MemoryRegion *mr = address_space_translate(&address_space_memory,
-                                                   addr, &addr1, &l, true,
+        MemoryRegion *mr = address_space_translate(as, addr, &addr1, &l, true,
                                                    MEMTXATTRS_UNSPECIFIED);
 
         if (!memory_region_supports_direct_access(mr)) {
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:24:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:24:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133889.1471957 (Exim 4.92)
	(envelope-from )
	id 1v3Vew-0003AZ-4Z; Tue, 30 Sep 2025 08:24:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133889.1471957; Tue, 30 Sep 2025 08:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Vev-0003AS-W7; Tue, 30 Sep 2025 08:24:29 +0000
Received: by outflank-mailman (input) for mailman id 1133889;
 Tue, 30 Sep 2025 08:24: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 1v3Veu-0003AM-Pi
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:24:28 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0d490e7-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:24:27 +0200 (CEST)
Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com
 [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-63-oZVi3mpgOxWe_Q2VeIHfEQ-1; Tue, 30 Sep 2025 04:24:25 -0400
Received: by mail-wm1-f71.google.com with SMTP id
 5b1f17b1804b1-46e35baddc1so35011305e9.2
 for ; Tue, 30 Sep 2025 01:24:24 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e56f536a3sm53104865e9.8.2025.09.30.01.24.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 01: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: e0d490e7-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759220666;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=UBV7yT9H1ZhgWn+VIgi65bhiZQpS7FeEIVePaxqLk1w=;
	b=P7FC1/va0pG2/jxqw+/tsB83YiVafUQa4usUlz8KwjAWNdlZIHWz9+TSsPmlfxPstS5f/j
	ZOXTwCZCfM1KHYadAF2nlMNf3zcAaGymgxjJb570iAaQza6GJiJdea1loF0VIBTPKosGFB
	UAP7QE0v0NbmsOAJF1ws2/rJ7ImU1dU=
X-MC-Unique: oZVi3mpgOxWe_Q2VeIHfEQ-1
X-Mimecast-MFC-AGG-ID: oZVi3mpgOxWe_Q2VeIHfEQ_1759220663
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220663; x=1759825463;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=UBV7yT9H1ZhgWn+VIgi65bhiZQpS7FeEIVePaxqLk1w=;
        b=cVgpg1Qxb8NlKgfzqRfHKtmP9LQHmBsR1VPWAKg9aW97RHjVYloCMdNSm02zYbQt5r
         GUBuIRgqna+rhSKk8+ZVB+15+4ChjsqVxYLk6L2PNEaYZtPOHeiNOl7bObgVJdmktjoR
         Xrws2VArXRMlAKMBiel1hwFpm5f/8alnBYODeqGHmSrjLF++n/wVk7x2TQfbHixooRps
         iCg+LIDXiFnDQIfpW57507e3/ift06TPhs+G9P83MA93JCcfTEnaggbAanwXpuMKdfYv
         ZpPhxThdnU8Yzk0EjmhGXHQ55prOq5Jg+KKBlxZGZ3KBH4JGQI4NqxhSxIxwUk3UN12Z
         1Ung==
X-Forwarded-Encrypted: i=1; AJvYcCX9qo8gw1HwjC5yVS+odsJ0pj9zp79fJKHrmSgCKKylTRoqKHPGgMpOZ3rRgzKFlqlj7UQS5t654Xs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKMd/Tizh1bubKsUwdMFHmbUt8D+yYk+ASo/kSH30qJrU+b94d
	WHuOB5wPLPE4fVxyz99VrCIUPiHRboKuYCb8Yk/edTLafF8ac/zBdUXYP21yzoQGqlW2fDinQ3a
	LT4bQ6y1VX5yqZo+Ozw9gNgLliACpdHQf1itNcuKHBOVZUYpr+e74nEdTca7l0/lCKN53
X-Gm-Gg: ASbGnctHK9ntt9Kh527E8Y59DuNUdZfEFiP3YxVHZSLt4MfAKTep7VHyRySQ/mNI+7J
	aNnIDzIdqGZJXNTBs+oCm9LLt5JWlUCa5LeVXv981h26/OiuK59gAzdGrbfKh0HkxQR311pH0iS
	aliciKEPNLwNOW2xWqikIkhE1/w7HwmYRDGmgDd9Vs/tyXPTBHJWGrWrTpKI7Vmd0vr5mxEJHtd
	vwU0HRUwxMmoGE9kDJ4dQY2SNkbSkjWuaiYYAsLBx4AqtIFhBKHbkBFZDWPu+JTTOHAzWdp9U70
	qiLCyWkN4zl2evBqfA7qA48d7RJjHVB4cyt4ogx/n8X+nHdUgy0FshyKxuOBgcFltdtNTxnCawQ
	eJbPt3g7H+g==
X-Received: by 2002:a05:600c:a4c:b0:46e:2861:9eb2 with SMTP id 5b1f17b1804b1-46e329a4931mr225420405e9.8.1759220663287;
        Tue, 30 Sep 2025 01:24:23 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGP1j7w6YQfPOaARZMgzdiehUJ10arFfO1DEIi9uwI/uwm5ShlL/vhcbx6Iz07lCciB2GZFhg==
X-Received: by 2002:a05:600c:a4c:b0:46e:2861:9eb2 with SMTP id 5b1f17b1804b1-46e329a4931mr225419995e9.8.1759220662830;
        Tue, 30 Sep 2025 01:24:22 -0700 (PDT)
Message-ID: <525dd07f-ae64-4ba7-b3ec-b9fcd86aa8a5@redhat.com>
Date: Tue, 30 Sep 2025 10:24:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/18] system/memory: Better describe @plen argument of
 flatview_translate()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Marcelo Tosatti ,
 Ilya Leoshkevich , Reinoud Zandijk ,
 Peter Xu , Zhao Liu ,
 David Hildenbrand , Halil Pasic ,
 kvm@vger.kernel.org, "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org, Stefano Garzarella ,
 David Woodhouse ,
 Sunil Muthuswamy ,
 Richard Henderson ,
 Stefano Stabellini ,
 Matthew Rosato , qemu-s390x@nongnu.org,
 Paul Durrant , "Michael S. Tsirkin" ,
 Christian Borntraeger ,
 Anthony PERARD , Jason Herne
 , Paolo Bonzini ,
 Eric Farman 
References: <20250930082126.28618-1-philmd@linaro.org>
 <20250930082126.28618-3-philmd@linaro.org>
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: <20250930082126.28618-3-philmd@linaro.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: dxCpSZa0Uh_2EY4pzUpLhhbHcm4e58BNE-W78GiwhoY_1759220663
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 10.21, Philippe Mathieu-Daudé wrote:
> flatview_translate()'s @plen argument is output-only and can be NULL.
> 
> When Xen is enabled, only update @plen_out when non-NULL.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>   include/system/memory.h | 5 +++--
>   system/physmem.c        | 9 +++++----
>   2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/include/system/memory.h b/include/system/memory.h
> index aa85fc27a10..3e5bf3ef05e 100644
> --- a/include/system/memory.h
> +++ b/include/system/memory.h
> @@ -2992,13 +2992,14 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
>    * @addr: address within that address space
>    * @xlat: pointer to address within the returned memory region section's
>    * #MemoryRegion.
> - * @len: pointer to length
> + * @plen_out: pointer to valid read/write length of the translated address.
> + *            It can be @NULL when we don't care about it.
>    * @is_write: indicates the transfer direction
>    * @attrs: memory attributes
>    */
>   MemoryRegion *flatview_translate(FlatView *fv,
>                                    hwaddr addr, hwaddr *xlat,
> -                                 hwaddr *len, bool is_write,
> +                                 hwaddr *plen_out, bool is_write,
>                                    MemTxAttrs attrs);
>   
>   static inline MemoryRegion *address_space_translate(AddressSpace *as,
> diff --git a/system/physmem.c b/system/physmem.c
> index 8a8be3a80e2..86422f294e2 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -566,7 +566,7 @@ iotlb_fail:
>   
>   /* Called from RCU critical section */
>   MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
> -                                 hwaddr *plen, bool is_write,
> +                                 hwaddr *plen_out, bool is_write,
>                                    MemTxAttrs attrs)
>   {
>       MemoryRegion *mr;
> @@ -574,13 +574,14 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
>       AddressSpace *as = NULL;
>   
>       /* This can be MMIO, so setup MMIO bit. */
> -    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
> +    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
>                                       is_write, true, &as, attrs);
>       mr = section.mr;
>   
> -    if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) {
> +    if (xen_enabled() && plen_out && memory_access_is_direct(mr, is_write,
> +                                                             attrs)) {
>           hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr;
> -        *plen = MIN(page, *plen);
> +        *plen_out = MIN(page, *plen_out);
>       }

My question from the previous version is still unanswered:

https://lore.kernel.org/qemu-devel/22ff756a-51a2-43f4-8fe1-05f17ff4a371@redhat.com/

  Thomas



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133906.1471971 (Exim 4.92)
	(envelope-from )
	id 1v3VgS-0003nT-OF; Tue, 30 Sep 2025 08:26:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133906.1471971; Tue, 30 Sep 2025 08:26: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 1v3VgS-0003ml-IU; Tue, 30 Sep 2025 08:26:04 +0000
Received: by outflank-mailman (input) for mailman id 1133906;
 Tue, 30 Sep 2025 08:26: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 1v3VdR-0007Nn-Lv
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:57 +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 ab487156-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:22:57 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-46e3ea0445fso21834835e9.1
 for ; Tue, 30 Sep 2025 01:22:57 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab31f1dsm257299105e9.13.2025.09.30.01.22.54
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01: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: ab487156-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220576; x=1759825376; darn=lists.xenproject.org;
        h=content-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+NTzU/IHsRou1TdenwZChnEmNZiK1YgxaNrzj3kN60=;
        b=BewCbPvddGEl84F+zw1T1AFIzSZbcz8oWJzP+5sAYRrVApHPAZGlAa+MHeu+tl5no2
         DSeWPgAjTDbUJCNZakYhkl32EFM6YRc5i95Q8VzpmHlBjCoBy5YFkuMt1wbZNJNPS22y
         xB3BGwy6n2gSbSerL1rueG0f9fvrDfFbnqKddejp3ARpVTrb2BalGsG28uU2VmNCztbm
         NZXpl95qSRNM9SvQ0zAKIN/wKlgZy8aOUZfwPwo8Wp8sCh0UUgXiQ3khTTb69OYLM0FF
         ceCiCWPYdiHeu+ibASkDf/4ocs3KVxpF+LKSWH43DcUS9zX4uo6ueZlfxvjKmJXVwWpc
         9aRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220576; x=1759825376;
        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+NTzU/IHsRou1TdenwZChnEmNZiK1YgxaNrzj3kN60=;
        b=PrfUaLVvWnoWdoVq3qmFSHuTKNn6S0ZUvaIsRUvy7S0B9TbS8sa+HqLBTBfBdvfcQr
         8ohMC5ZqczvEESU3v5C2QEKcqnRihPEg5AImcxKVapjmMnfwd0mM2MzQifn6qvE6eHDH
         G3wWKvgncHxNogaRYKFj6dPSY6In/S/GlvpQqBXYH7SNofPGUxN+X+DZOjA5L2X0ZbLp
         2P2haWjagReZUcsF8/VmsMU3MoDRKNVs34XNFDcUjflWRCyfi2pF2a6zRjKngTwIcjP0
         wHNH39H4yLba9bksOcsdY4U+YRPNCT19VCCXCqnHWAkxLUfMPC8c+AbsC5ik/5CqjkCF
         xAPw==
X-Forwarded-Encrypted: i=1; AJvYcCVFWiVPffj+6ex32mGqalTDoVwntB45YZasCkErjgKmZOZo7ds9DG8RRFYJCPvxQPzFN0UatcwwJ7c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcLPNFhhcCDbkXZ/Fj0g9XLpsMVLabGaG9W3C2dcHObjqMb4ZE
	1C6SXdFIdC6qo0EZge42/xJ4SWdqvM/K1EDY5PxjBOYTgoQxtHWtRWy1nXbk4y/ah5E=
X-Gm-Gg: ASbGnct0ICyd8geCS5W5ROKnqGzxdiuVzvAqvbtHGmts6lKxrxdjw3G85IBSmyRqBR1
	7UQTyWwCyJavkQbchhXLQ6y5srcnO5ryc2RDGnIEa5T0h0OKP2ZA5DLxu6ALlHe1YvF42Y+zKP/
	vEPJQ6QXNbW3QwJr6jw4yFib1k9zHsE8TBd0bsxZeboOPwjGrdkovU5gkTZTWbediTDh00IPSyc
	AP27pfr55iHvJuymxSAWgCrSnB3GEIl6sXAPs/Cd3o15CMkRdkfw09W6S8hJ7XwDZbojOtKZ++0
	V2C+8tz0yEtMJEzq1ZyMwpzJOuQCrr0HJkSvnliGhKS5kUFy+WidK2oIXIgQsCgJQgU/TzuAmFH
	9wbCJh6JGb4rnH8f50Xpt28J1Mwsut1vdU8bdG8A1vANbMULgo5BXJuphUxUljHOFpJadT/ZTXK
	9p9/S9sJWp1aVNuvMv6XiO
X-Google-Smtp-Source: AGHT+IF6MOWO4c82B+adWYsw2taxPQCQZ7xaYbsT9FR7waxJpKF5wSL8PK2fRqDT9d11Kh1Y1Hd+uw==
X-Received: by 2002:a05:6000:2509:b0:40d:86d8:a180 with SMTP id ffacd0b85a97d-40e4a71159emr18168445f8f.20.1759220576446;
        Tue, 30 Sep 2025 01:22:56 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 16/18] system/physmem: Remove legacy cpu_physical_memory_rw()
Date: Tue, 30 Sep 2025 10:21:23 +0200
Message-ID: <20250930082126.28618-17-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The legacy cpu_physical_memory_rw() method is no more used,
remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/devel/loads-stores.rst            |  4 +---
 scripts/coccinelle/exec_rw_const.cocci | 10 ----------
 include/exec/cpu-common.h              |  2 --
 system/physmem.c                       |  7 -------
 4 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index f9b565da57a..c906c6509ee 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -460,10 +460,8 @@ For new code they are better avoided:
 
 ``cpu_physical_memory_write``
 
-``cpu_physical_memory_rw``
-
 Regexes for git grep:
- - ``\``
+ - ``\``
 
 ``cpu_memory_rw_debug``
 ~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/scripts/coccinelle/exec_rw_const.cocci b/scripts/coccinelle/exec_rw_const.cocci
index 35ab79e6d74..4c02c94e04e 100644
--- a/scripts/coccinelle/exec_rw_const.cocci
+++ b/scripts/coccinelle/exec_rw_const.cocci
@@ -21,13 +21,6 @@ expression E1, E2, E3, E4, E5;
 + address_space_rw(E1, E2, E3, E4, E5, true)
 |
 
-- cpu_physical_memory_rw(E1, E2, E3, 0)
-+ cpu_physical_memory_rw(E1, E2, E3, false)
-|
-- cpu_physical_memory_rw(E1, E2, E3, 1)
-+ cpu_physical_memory_rw(E1, E2, E3, true)
-|
-
 - cpu_physical_memory_map(E1, E2, 0)
 + cpu_physical_memory_map(E1, E2, false)
 |
@@ -81,9 +74,6 @@ type T;
 + address_space_write_rom(E1, E2, E3, E4, E5)
 |
 
-- cpu_physical_memory_rw(E1, (T *)(E2), E3, E4)
-+ cpu_physical_memory_rw(E1, E2, E3, E4)
-|
 - cpu_physical_memory_read(E1, (T *)(E2), E3)
 + cpu_physical_memory_read(E1, E2, E3)
 |
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6e8cb530f6e..910e1c2afb9 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -131,8 +131,6 @@ void cpu_address_space_init(CPUState *cpu, int asidx,
  */
 void cpu_address_space_destroy(CPUState *cpu, int asidx);
 
-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write);
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
 void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
 void *cpu_physical_memory_map(hwaddr addr,
diff --git a/system/physmem.c b/system/physmem.c
index 51abc4cae96..000bde90c2e 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3182,13 +3182,6 @@ MemTxResult address_space_set(AddressSpace *as, hwaddr addr,
     return error;
 }
 
-void cpu_physical_memory_rw(hwaddr addr, void *buf,
-                            hwaddr len, bool is_write)
-{
-    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
-                     buf, len, is_write);
-}
-
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
 {
     address_space_read(&address_space_memory, addr,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133902.1471967 (Exim 4.92)
	(envelope-from )
	id 1v3VgS-0003j0-G3; Tue, 30 Sep 2025 08:26:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133902.1471967; Tue, 30 Sep 2025 08:26: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 1v3VgS-0003it-AP; Tue, 30 Sep 2025 08:26:04 +0000
Received: by outflank-mailman (input) for mailman id 1133902;
 Tue, 30 Sep 2025 08:26: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 1v3VdW-0007Nn-TQ
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:23:02 +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 ae7d968a-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:23:02 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3ee13baf2e1so4389325f8f.3
 for ; Tue, 30 Sep 2025 01:23:02 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb72fb21esm21742490f8f.7.2025.09.30.01.23.00
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:23: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: ae7d968a-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220582; x=1759825382; darn=lists.xenproject.org;
        h=content-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=72P8ycFgSBQVWBZ3tJbVWDsHTvBRP8LSmdHVD/So9uo=;
        b=BwcWYdnAKol/338lhKXf71n0HYv/xU94CMdkDxqXQ0rueCgSfaYVxwOxa8ge8uBXQm
         BuM1JwJE95+vpAEunhQWk/5x/8HfyUYZh815h4wmMO7SyoFGvWTEgOQdrDZsXCDbJg3P
         QjRyk4iyh6j+3MpeAABeqa+xHc9XL4PLopalad6OSI9k5l/PFK99STiRK6O6fvUqTkSb
         gYAZoGFjqiKXJ8T37BH338F9ta16n+iC2HE7P6gwqmpu/ptjcRwIUwjPN4ikvwtOGziB
         mN6UXSUxgVJugZZHAecCsaU7aR4w02bEW5BS50FsoDB//u2kETXy83rhEfmS4D/zcurj
         SWCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220582; x=1759825382;
        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=72P8ycFgSBQVWBZ3tJbVWDsHTvBRP8LSmdHVD/So9uo=;
        b=hMdrsqCqfM3cZ+8CPT/W9Q3TnGjdU7pflbYeQRDuampeZGIvJMXF45L5PH8W7ffBT7
         MikaCLhhs2m6uYv7YEkQHP1rCqeqL8ocD0WjCKxNY/zUf4mrxmG/kc1mHFYxg4oFbF4s
         HeYzPNlb7KDGALq/a9jUhJmluUgga0rBOlJkHNG4TbjCaNNt0KyC5tPaHdL/3elOtcRy
         NJtBqtilbSg+uRRLfPYqQWENc69U+8t7wQNKkpTn9tWN1R/hUMNjx6womBwnVgaGJUS8
         uiV+qjFJiWj5ccO2HTlgdWiEPe1ETiSSQojVWioU0/7UbvJPlCw5L2/HxKJOaUWH28ai
         VUeQ==
X-Forwarded-Encrypted: i=1; AJvYcCXibgvEnR7Pj2N0u/5ChTHvMGPltFUhYl48o4aTbyn1SZVkQl+N29CUjOqHtoW4D9FI1GHS7OVoO5M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEChA3/AV5csHtsdg+Wxqx/fa6sj/qt+mOTRCiZ1u2AAKlurlI
	pGChnFufQNgco7OFKh10uJxFuWTvXqrcCWpdeGgnM4vWnk2BFzQMhECa4VwW7SZsntA=
X-Gm-Gg: ASbGncuvtE1mXmMQxQDqHIHukiQbqesDt+GX2h58JwAzDeu0hbZ03gxJlax03sL2IYB
	uYGmo0zwJgWcWbxDSSjnndw0udYOqsOafQXRAaucT6/iEN72VQI7l19ToDTfGQ+oXIrsgJBEWy1
	3O+ZTYiJjIAEdKylE8IWqnFa+QObzQJnY6fV4LCmm2ce7KQVt/BDZdakukIN3kTb7RzZhWP6iWK
	emm4qvnqKluRubq/D+GKZxS8cKG8k9BuTNdRpoF5FY7V8OZXeNuI62qmQf8GiJKU8stwMFw6SNY
	IUshi6g8oHPdcPIjgXp4KOq0yG4W/5SdRiAN1eqM75LeyiwkmB3KBQaUgl+U+plEjCI8VIgnbyS
	GRDqVz2DM5jQHI3vrSPMzATRILXBOOw8Lx4MHqb6FbOIHH5o/IepOzwbWILEVdcu4b/lTp5A28v
	3Q2fFIWvy/a/DILec/nxG9
X-Google-Smtp-Source: AGHT+IG0fDZU6KltrERn3higtjD7tJ2dh/0k92N8Tps8ggqNo2HbrRNaueeSukMTmfKt9k8lWLLnpA==
X-Received: by 2002:a05:6000:3101:b0:3e7:492f:72b4 with SMTP id ffacd0b85a97d-40e4be0c940mr16811180f8f.42.1759220581872;
        Tue, 30 Sep 2025 01:23:01 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 17/18] hw/virtio/vhost: Replace legacy cpu_physical_memory_*map() calls
Date: Tue, 30 Sep 2025 10:21:24 +0200
Message-ID: <20250930082126.28618-18-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Use VirtIODevice::dma_as address space to convert the legacy
cpu_physical_memory_[un]map() calls to address_space_[un]map().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/virtio/vhost.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 6557c58d12a..efa24aee609 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -27,6 +27,7 @@
 #include "migration/blocker.h"
 #include "migration/qemu-file-types.h"
 #include "system/dma.h"
+#include "system/memory.h"
 #include "trace.h"
 
 /* enabled until disconnected backend stabilizes */
@@ -455,7 +456,8 @@ static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
                               hwaddr *plen, bool is_write)
 {
     if (!vhost_dev_has_iommu(dev)) {
-        return cpu_physical_memory_map(addr, plen, is_write);
+        return address_space_map(dev->vdev->dma_as, addr, plen, is_write,
+                                 MEMTXATTRS_UNSPECIFIED);
     } else {
         return (void *)(uintptr_t)addr;
     }
@@ -466,7 +468,8 @@ static void vhost_memory_unmap(struct vhost_dev *dev, void *buffer,
                                hwaddr access_len)
 {
     if (!vhost_dev_has_iommu(dev)) {
-        cpu_physical_memory_unmap(buffer, len, is_write, access_len);
+        address_space_unmap(dev->vdev->dma_as, buffer, len, is_write,
+                            access_len);
     }
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133908.1471985 (Exim 4.92)
	(envelope-from )
	id 1v3VgU-0004Fe-4j; Tue, 30 Sep 2025 08:26:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133908.1471985; Tue, 30 Sep 2025 08:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VgU-0004FM-17; Tue, 30 Sep 2025 08:26:06 +0000
Received: by outflank-mailman (input) for mailman id 1133908;
 Tue, 30 Sep 2025 08:26: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 1v3VdG-0007Nn-OR
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:46 +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 a4c5f684-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:22:46 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-42420c7de22so444382f8f.1
 for ; Tue, 30 Sep 2025 01:22:46 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc7e2bf35sm21817486f8f.53.2025.09.30.01.22.44
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: a4c5f684-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220565; x=1759825365; darn=lists.xenproject.org;
        h=content-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=LWuKL8TfgkuOIExpLDHpPzfjXl06+qaviUFlhAaNsvY=;
        b=ZfJeGKkHj97EFIMEfRaAn/oip33tclmZINqzMONSMtAxocjkes8yfJMf7vVlRtL3Mw
         oFaZCR6Svt74yNWxtHvLhWbK3sRawOaLBuneJv0Czpi4SZ6JxdvuhiNSA2Qe0tlQJRWc
         dgWQRYDBf/96MJncZzDYumRFnSc4USDlUMPv2NiGD0zq84JlzGLucwxCiW2diXScf/y+
         ObwKV3XkVE1GTjjkfh/h62f7CiaCLgOb1CWSX+6cXMgJrBGE6JZF7HV8+EXCX2Q6VPQ9
         q1yKtp9YLGex3kDtKVyfFin9MqGV5FnJeoU0eWVX3xMz2I3R1a9ZDConwuGfkPRSr4CM
         JJTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220565; x=1759825365;
        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=LWuKL8TfgkuOIExpLDHpPzfjXl06+qaviUFlhAaNsvY=;
        b=b+fOSP+c19MnW8/zpb5CLi7GvGUtDzr1ndIhnw/GskI0XekLaUsdG0D2Il9f/wak+y
         6dax1V7BLvETZACOaLSzOcnfcaYFWMbgDNUoC5PMloCKGI5aLMjCk+NHM197Gzv5+iRT
         rpYOxeSJtJJlXCKRTENKvf5PPEwQcTo/SRHqKRf10AEjZIhTXC9MYcHFSbXLR9y6nOgn
         aYc6Wgqi+TxWPF67KYcVZNc8ovD2kk2zr4oFSg+v3wGkiEJV9mLaGtk8rOQ+xCVY4x60
         kKPmNA+qGogBsZGWdZ22S0SSu1HUaQxu01vqUCxZhDFm7PIScsystxt/xGmvTbA4NuAk
         GP/Q==
X-Forwarded-Encrypted: i=1; AJvYcCXvMeBvWEo7ZW3QGG2hs2jdqmyWf/zylpBgANey/WNqafuOX06RON6P+cU3BJUzM6aMA6FvJp1kqKc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx90sqH0D8U4VF2cnvkh/MimV4L9/N6oK9tKIJj+o6j7faHf61z
	P+S+rVqiDgotJQ/iduZMjRXif18S8YxfUNPe02ZFd/eXFeG9aNluOIpIC9DKSGdfcT8=
X-Gm-Gg: ASbGnctiB6Rl+VAbz3K8Ww2kPIluIZvBnj/C0GHj9JhEVGZ3Mjg04spRmQ5s1oGNyce
	PY521XtBTnrGefdiUvd9sv0UCQYNV6FBvOsiP6qSXWKWaH49wkdhesQ1ZymIr0VzgJV4qlEsSoB
	jCyS+TSfCDbBrUhaTyNfLAkfudJqlxdFpMhVA+T63MKcPneWNzLYn2VKOA9ooE9NQ/rVzAC9htj
	0Ulu4MzafisV3hxCb9dwKGzVnPz9CNzfVF+I6xQ11Kajrl+LCBYEQPtwqEsCZlAROHlWuX06djR
	4+a8KRLsEIDCFgfsNqzEm4s80vfwmVxxqhEWP+dmJg12OPxmNIZT/GyIEej6mKtXcH5QK5sORKP
	qHIqswSBHGo3Nt6+N82FGpyTIDNuAplU+FvbCERYLfLKPWr1BHRkvBZDwuAATt8lOpzTfpIGsQ3
	us/K3M4QeCbovaTfMGm4Zy
X-Google-Smtp-Source: AGHT+IHE0WytwIozDLwCH/1E/tGTnOI9D8efEv7Y9aQk+zHE6qo+2lNsAzNshhN1K4J4d9d9Usou1Q==
X-Received: by 2002:a05:6000:240c:b0:3dc:1473:18bd with SMTP id ffacd0b85a97d-40e497c348dmr17529188f8f.3.1759220565490;
        Tue, 30 Sep 2025 01:22:45 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 14/18] system/physmem: Un-inline cpu_physical_memory_read/write()
Date: Tue, 30 Sep 2025 10:21:21 +0200
Message-ID: <20250930082126.28618-15-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In order to remove cpu_physical_memory_rw() in a pair of commits,
and due to a cyclic dependency between "exec/cpu-common.h" and
"system/memory.h", un-inline cpu_physical_memory_read() and
cpu_physical_memory_write() as a prerequired step.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/cpu-common.h | 12 ++----------
 system/physmem.c          | 10 ++++++++++
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 6c7d84aacb4..6e8cb530f6e 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -133,16 +133,8 @@ void cpu_address_space_destroy(CPUState *cpu, int asidx);
 
 void cpu_physical_memory_rw(hwaddr addr, void *buf,
                             hwaddr len, bool is_write);
-static inline void cpu_physical_memory_read(hwaddr addr,
-                                            void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, buf, len, false);
-}
-static inline void cpu_physical_memory_write(hwaddr addr,
-                                             const void *buf, hwaddr len)
-{
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
-}
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len);
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len);
 void *cpu_physical_memory_map(hwaddr addr,
                               hwaddr *plen,
                               bool is_write);
diff --git a/system/physmem.c b/system/physmem.c
index e0c2962251a..033285fe812 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3189,6 +3189,16 @@ void cpu_physical_memory_rw(hwaddr addr, void *buf,
                      buf, len, is_write);
 }
 
+void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
+{
+    cpu_physical_memory_rw(addr, buf, len, false);
+}
+
+void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
+{
+    cpu_physical_memory_rw(addr, (void *)buf, len, true);
+}
+
 /* used for ROM loading : can write in RAM and ROM */
 MemTxResult address_space_write_rom(AddressSpace *as, hwaddr addr,
                                     MemTxAttrs attrs,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133910.1471993 (Exim 4.92)
	(envelope-from )
	id 1v3VgU-0004JG-GU; Tue, 30 Sep 2025 08:26:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133910.1471993; Tue, 30 Sep 2025 08:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VgU-0004Ip-9Z; Tue, 30 Sep 2025 08:26:06 +0000
Received: by outflank-mailman (input) for mailman id 1133910;
 Tue, 30 Sep 2025 08:26: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 1v3Vcv-0007Nn-U1
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:25 +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 97b59117-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:22:24 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-46e2562e8cbso43193775e9.1
 for ; Tue, 30 Sep 2025 01:22:24 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab31e97sm259738545e9.14.2025.09.30.01.22.22
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: 97b59117-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220544; x=1759825344; darn=lists.xenproject.org;
        h=content-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=DbEYNZgIU6LqvkF49qge8kIj2C3i6K2S813tsyxbWwg=;
        b=K3by3MACOnbj8zhQ0YluEb7+VUlAcWWTRqW6nBXfxKRC92F7V7OHt2beSN4l4McyTA
         DVJg0SN3XsDQ1XwJGbq69mJdjH/5yvkG82rGVcZsUsDiaVqFK9ok5DxK+m6FXhHqIxUP
         jVUcH/gbrAeketQGXgMHklgEYlJNW20KELCLnD9j1/ttTJ83DJcb28/Bjxmu0tpPjpoF
         fmtNLsfCizrPT1pNgp1g3L04Qd9hnQ3a1vERWVQX6OkDMpECnq8I9UhUidNKi8TwjMhV
         OfgcDRYV5wSw68sbsjip+lBVDr0a1U7O7UsDmjs+xUtdsMQtKvxLindrI0UQT1V6BCjv
         dMJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220544; x=1759825344;
        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=DbEYNZgIU6LqvkF49qge8kIj2C3i6K2S813tsyxbWwg=;
        b=Xd8uFT+zMDIzkgmvuU0pXhb9YIOViiAjXD6Y3ot1kB8x8rb0Ge7p1TTMDn+ff38whw
         yJR9oDcR5QQ2FWrKp+5cYYKAbEmSKeXk7LuVEDz0bWCM2VN4c690M/6jDaYVON6tLlc3
         cuMRCeJJ8NbpzFl8arAPsXl89Cax3AyFfgWbfD5cMqcSZQOVORKzjLHF0GXgQw0hJi3z
         7EYo5fO2WYjkIXqvNucV161PLcJkuifw/6AgNKSkyiQN83MaFtBmrKkisFkypCTalIo0
         KCEy2nCpoWgJnTiStZMyJ6g4uxJgLi9a4tPKrwj87nWoxTkDouReYhkqeVOw4RsTXYtD
         AV8A==
X-Forwarded-Encrypted: i=1; AJvYcCXbXxWn4JQeuenEzz+vTHF6I/YClh7q4R7584SI6TMCrcKO/GD/KZJ5QjskH1cyMnP4uPNHph68dzQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxG1+gmIeNhk9k0ly/lnphcLaOH9Tl8XcUVfWlBwC4o39CO8oDI
	h1/JCJhAEcfWsUsXoeOgeaLjyuhsRpamZl19TKIRuq6tKaCwEIwMF3BZF2EAAQMGX4g=
X-Gm-Gg: ASbGncvU8KzlfTFX3CRBMdY6fFtC90sXNkhkhg3hTBny9XS5k4mRi1hqQE6WQkBY8D7
	iBQXEQi83lmNNUpRzzQ9j+hAejiM3BDlqsY3wo7draZnOb/sZWSsGjYdOJBCM8WinDkvpTfganB
	0hNxnQkaehsW4hjfDca93j55ouT/aJNQyXXmcTSoZARBtOV+HUDPBB0ycGJQg7nSI2IYAMQkRSr
	urVJaO/jWPKk8WGeCIyC8ro9OdOI5qorOc3hDm24tJklPYfUGF/8NeE2ydo9MFNp1aNc6B1L2zK
	o4h9WI0K0u3zb1UW586zaPiZW+xeHc25pAM2x57DhfC4QmKpd15u6TCkcIioDLU2BoGrovcmLjU
	FHhazUw+a5VHvaou8U3GLLJ8dyOA6ychstUw0zHJiwZneXJVr7dS4vRWcD7+aX2UYgblpp+/d6n
	/DDMFPoaN8u8S8LlxmimLBuCL3P9MSpl8=
X-Google-Smtp-Source: AGHT+IHMDbDhZ1qtfUqSvwy3OGcigy6OI6LXsB/syBvCuQ6w6sDdxi+R3qorHEXGNas+XOrL9i5DRg==
X-Received: by 2002:a05:600c:4fca:b0:46e:4ac4:b7b8 with SMTP id 5b1f17b1804b1-46e4ac4ba51mr119307915e9.25.1759220543603;
        Tue, 30 Sep 2025 01:22:23 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 10/18] target/i386/whpx: Replace legacy cpu_physical_memory_rw() call
Date: Tue, 30 Sep 2025 10:21:17 +0200
Message-ID: <20250930082126.28618-11-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Get the vCPU address space and convert the legacy
cpu_physical_memory_rw() by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/whpx/whpx-all.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/i386/whpx/whpx-all.c b/target/i386/whpx/whpx-all.c
index 2a85168ed51..82ba177c4a5 100644
--- a/target/i386/whpx/whpx-all.c
+++ b/target/i386/whpx/whpx-all.c
@@ -788,8 +788,11 @@ static HRESULT CALLBACK whpx_emu_mmio_callback(
     void *ctx,
     WHV_EMULATOR_MEMORY_ACCESS_INFO *ma)
 {
-    cpu_physical_memory_rw(ma->GpaAddress, ma->Data, ma->AccessSize,
-                           ma->Direction);
+    CPUState *cpu = (CPUState *)ctx;
+    AddressSpace *as = cpu_addressspace(cs, MEMTXATTRS_UNSPECIFIED);
+
+    address_space_rw(as, ma->GpaAddress, MEMTXATTRS_UNSPECIFIED,
+                     ma->Data, ma->AccessSize, ma->Direction);
     return S_OK;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133912.1471997 (Exim 4.92)
	(envelope-from )
	id 1v3VgU-0004PC-TV; Tue, 30 Sep 2025 08:26:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133912.1471997; Tue, 30 Sep 2025 08:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VgU-0004Nw-Kn; Tue, 30 Sep 2025 08:26:06 +0000
Received: by outflank-mailman (input) for mailman id 1133912;
 Tue, 30 Sep 2025 08:26: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 1v3VdN-0007Nm-71
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:53 +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 a7f9bd95-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:22:51 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3f0134ccc0cso3832225f8f.1
 for ; Tue, 30 Sep 2025 01:22:51 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-41855fc661esm13882477f8f.45.2025.09.30.01.22.49
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01: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: a7f9bd95-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220571; x=1759825371; darn=lists.xenproject.org;
        h=content-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=v5u2B/lBOO+ZT0vBm0zXHtehU3SXYck4J+kjqZup+Gg=;
        b=awB4yGMJ8RK5hj/xpKCvMXzqVagZ1MtHZMipLtt/5JsP8xSjsr9+k2W+MseYj5UInP
         eMh+icZLHPvinrfDLEbYgXm4kiqH0EHBd69y5qdhXRQ7hZs2cMYrHeEMsEDQfikBcK4X
         TLstJSfCZEMz4j+oKeR45m1QMiY00h5n/bLKAwbiLyrLfaIYB/e5cYt21vDxOWW8NTDg
         Urqy65zYUYwBFJenM414YVoxUuDaEM99bDlmUzMM2lIPft0ELUGjr/IyQBtt5jap2Uxj
         /0woNtM/V2Od5+1rhZFfFvbi1ZzY1uI4vaeNcVsCybiqzC0osgQcnTjRrAblVxEgQbam
         swdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220571; x=1759825371;
        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=v5u2B/lBOO+ZT0vBm0zXHtehU3SXYck4J+kjqZup+Gg=;
        b=skmEL4flF0ahDTZo7IRsOHSYVF9GxkowOJaww1iFunUB0AMPuxhFpvDm4ODXkiS1yd
         /gc6cXxHPkoSvqfmkLfP5tW4i7nOHOgW093ONzsxnbn8LFkGFj4GzNs3BeTnYwx+5EEp
         uyur/TR0R2+0tF845plu0ljt1NTSq4eePsDzP4FIGj1nrKRYDZIg4HGw4KSvAA/naLuO
         oAHmZhcJscd2H+046Lp8UaviWe1krcYBJSbQ6cUdMKSrtHWNnmUdtuJBbQRZfD/GC81W
         jfU0uV20o5AFMaunaya3bWRUvzHxhNDAaY2i3Zbi9hCOEY9UBzwO1Z957ocS408d9M0B
         bKGg==
X-Forwarded-Encrypted: i=1; AJvYcCVsHXL3iq562iJKw6oLzTywBmrboo9ZElozBRGsP6XUSrRPzmuGPsC1QpwOzLHk022oBgIF1wgN23I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTaWdsca5kjAcku4cEb30yR/YmRf8ryKfL5T1Kk0aKTPERWi8g
	dLmV3cfiRibMP+uDmd/8S1wXc1c+NjP598l0bHpIeteMxbdCbaPJpngQ8kSHXZ4FX6o=
X-Gm-Gg: ASbGnct1DojOcN5YzNYCTty3RN7nJGEAkTqUjiBW5nNRlQgv31I4CHF4am1mKDN7wZR
	m0/boOmJLBSzIlmAoPZfIZNB2AAQVorkbZtNNYxfVs5iOLlLAD5O9Vkx9B1ZyY7A2INqhSwBzsx
	9B0rKX1gDfQjqmO/L7MvsMGpLYHA0Ql5tXGwHqM6uJuvt7ylxdLPAUeVrWa0Sc0PYso90AUoHjd
	tNgcGG2XqKWNcJiQ8pYgATh6LO+Imiblxv9QZ4Q3OKAsGZnjAh8gH4umx93vRKvPnaK/FNV8DNp
	cyLWBWB2zLnkVB4FLd0i2+M/tAsGxZ6K0QWfJxHqzLp0uZ3lWJjmnzQtQWBqPgw8McBToIzZqZu
	LHYPnD1lM4DpKHvZ6/XyIRD0Nw3fPpurOTrvpBgJJ9MewohOdGertlTAnKLczDuvob7rqq23oLt
	3WDa85FedEdEOiSqDSwfr6
X-Google-Smtp-Source: AGHT+IF27z6BNMVinFPf1IUIruLrE/uTdfyqnRZ7rQ19Ax6aGtKGHkRUD8xTP4t1vKCXsfORDSUoIQ==
X-Received: by 2002:a05:6000:2507:b0:403:e61e:82e6 with SMTP id ffacd0b85a97d-40e4b1a07admr17394709f8f.46.1759220571045;
        Tue, 30 Sep 2025 01:22:51 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 15/18] system/physmem: Avoid cpu_physical_memory_rw when is_write is constant
Date: Tue, 30 Sep 2025 10:21:22 +0200
Message-ID: <20250930082126.28618-16-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Following the mechanical changes of commit adeefe01671 ("Avoid
cpu_physical_memory_rw() with a constant is_write argument"),
replace:

 - cpu_physical_memory_rw(, is_write=false) -> address_space_read()
 - cpu_physical_memory_rw(, is_write=true)  -> address_space_write()

Signed-off-by: Philippe Mathieu-Daudé 
---
 scripts/coccinelle/exec_rw_const.cocci | 12 ------------
 system/physmem.c                       |  6 ++++--
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/scripts/coccinelle/exec_rw_const.cocci b/scripts/coccinelle/exec_rw_const.cocci
index 1a202969519..35ab79e6d74 100644
--- a/scripts/coccinelle/exec_rw_const.cocci
+++ b/scripts/coccinelle/exec_rw_const.cocci
@@ -62,18 +62,6 @@ symbol true, false;
 + address_space_write(E1, E2, E3, E4, E5)
 )
 
-// Avoid uses of cpu_physical_memory_rw() with a constant is_write argument.
-@@
-expression E1, E2, E3;
-@@
-(
-- cpu_physical_memory_rw(E1, E2, E3, false)
-+ cpu_physical_memory_read(E1, E2, E3)
-|
-- cpu_physical_memory_rw(E1, E2, E3, true)
-+ cpu_physical_memory_write(E1, E2, E3)
-)
-
 // Remove useless cast
 @@
 expression E1, E2, E3, E4, E5, E6;
diff --git a/system/physmem.c b/system/physmem.c
index 033285fe812..51abc4cae96 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3191,12 +3191,14 @@ void cpu_physical_memory_rw(hwaddr addr, void *buf,
 
 void cpu_physical_memory_read(hwaddr addr, void *buf, hwaddr len)
 {
-    cpu_physical_memory_rw(addr, buf, len, false);
+    address_space_read(&address_space_memory, addr,
+                       MEMTXATTRS_UNSPECIFIED, buf, len);
 }
 
 void cpu_physical_memory_write(hwaddr addr, const void *buf, hwaddr len)
 {
-    cpu_physical_memory_rw(addr, (void *)buf, len, true);
+    address_space_write(&address_space_memory, addr,
+                        MEMTXATTRS_UNSPECIFIED, buf, len);
 }
 
 /* used for ROM loading : can write in RAM and ROM */
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133919.1472016 (Exim 4.92)
	(envelope-from )
	id 1v3VgZ-0005HL-BO; Tue, 30 Sep 2025 08:26:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133919.1472016; Tue, 30 Sep 2025 08:26:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3VgZ-0005Gy-64; Tue, 30 Sep 2025 08:26:11 +0000
Received: by outflank-mailman (input) for mailman id 1133919;
 Tue, 30 Sep 2025 08:26:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Vdd-0007Nm-B0
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:23:09 +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 b197e6de-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:23:07 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-46e4473d7f6so24843515e9.1
 for ; Tue, 30 Sep 2025 01:23:07 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc82f2965sm21484653f8f.55.2025.09.30.01.23.05
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:23: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: b197e6de-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220587; x=1759825387; darn=lists.xenproject.org;
        h=content-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=+R20KfaeepivX48ztS5Qk+Utu4Wf2nP4nwxC8R0e4a4=;
        b=XsLGFzWQTOCJYDfyRB1ZDBDRURr/nK7iRq+id4fav97QU/FyV44/btlMMGnv9IGtw+
         UhgDRpOlZv4aZDxGfQtR/seRHmYD3ei0P8fh59PwyCiZUrc6sbEA5hcY8EqabSheI9PG
         LVeISu8DHegvqU8w/JbvUDLnQzjFeCSs52sAPh1vMgSMOi10IX2sLNTi/spPr9q6Dqzn
         poQpGfvfGo8YgSbCIEynUQ0Y8JKOQdfNfvxovXxGV/FskzPhOzTW5Gbce5kSmguNvaNb
         6y34WRMg9DaMBZ2C1phR9LBhd6xF1aP0kAb4uu71MA6ZQy9fnAxM5WAu2yasAfiwQpAP
         55ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220587; x=1759825387;
        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=+R20KfaeepivX48ztS5Qk+Utu4Wf2nP4nwxC8R0e4a4=;
        b=QalbMQ5CSoRONE+Wb0KlbQFr+jD0QIYnTqIO+ytw0GzH9+GTF3nWHtnP247TACyaZE
         WiA0FG3cHdo73Tb3skYV4NQC3smG4dCxeYb+zeaaYyLM8aR3eqXHupNboL4t8eIIhiKl
         Hid4XbNLQSz1fZ2N0i0FvdVGvf3vVW7Hrs2Dw8sy54ZuQb9Cily8T/wuv0svvMGdw6Su
         vD2K60QXmlhPhDsQjlmGlpVtUTsRaNEZ0LHL7niegBqv8iKfSaZEujXdUPuJR8YsvS09
         FhyYBvCmkB/UbfNWLClkTxC7iBZYG7TOJcC80150CR5KHGdlZNw7YUnFOjHU7so1ITWi
         r3cw==
X-Forwarded-Encrypted: i=1; AJvYcCXVNkJ0n08NBo9wLu1krtlwuTGKD0okPHC3aLi7MLF0KDOoLcPl2SQ0d5s/OHXPp+Ro+jj10t1z1No=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKg/ZrOxQPW2+HJOpe/OqzH7pZe9cMRTOALFJI12NNAg1x2iA9
	FcUNpuzFdFrWhzqcRmngPujNZHXeDAlTIR2OnIFfPfVmskv500pOrKEBcbzr3uM6jJE=
X-Gm-Gg: ASbGncuGcEaD6R7E3fYVqiTY3sJ4H8w56YwnmSe2+2s/NQGCyPwPebClANBny+Kof+H
	ubTYz+BHyaT4BnakvQhLqlkXrnKpTvF72qjaA5cGBRZAZ46wL5RGf8SERzkYJ5RZq84V8TSVCzx
	o+3sLuVbncIIVWB1Ek969yu/Gi2DwK1F3Bkr8PTof7WlpjppKl1UGq4NKFzAv0q0Ffa+s7GBxWR
	aLFvv8P7cB5RG/rSYLRpTdwdQs2pRgtExHGtK7cc1R+5hNISp1SMa+cOIWx4LSWjQJn4ou4ZiP8
	+COrhB0EL36MPxzicFald7MjHztp760pHouJfOk4VzI709uhnFNsVFkjSWhGZ82sbi/JNZvmH53
	5OayJ96I6mEN+MjQwkCIrPwoFzL+NoZ7DwxiU3zcKw5fQEHOA/qkSy+p3aAeaGWlIS0kxzXQBzy
	PPTO21GOBb7E5EWJNEqd9iatp4N6u5bUc=
X-Google-Smtp-Source: AGHT+IGvdNJkPsXhO7mhTBAmSS24HJr1NcQFoKlHMGEeSQcfQp9VTD/G8Mg1Kg5Mqclxy+K9+gFIZw==
X-Received: by 2002:a05:600c:4e8c:b0:46e:477a:16cc with SMTP id 5b1f17b1804b1-46e477a1b4emr94534015e9.24.1759220587242;
        Tue, 30 Sep 2025 01:23:07 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 18/18] hw/virtio/virtio: Replace legacy cpu_physical_memory_map() call
Date: Tue, 30 Sep 2025 10:21:25 +0200
Message-ID: <20250930082126.28618-19-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Propagate VirtIODevice::dma_as to virtqueue_undo_map_desc()
in order to replace the legacy cpu_physical_memory_unmap()
call by address_space_unmap().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/virtio/virtio.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 9a81ad912e0..1ed3aa6abab 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -31,6 +31,7 @@
 #include "hw/qdev-properties.h"
 #include "hw/virtio/virtio-access.h"
 #include "system/dma.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "virtio-qmp.h"
 
@@ -1622,7 +1623,8 @@ out:
  * virtqueue_unmap_sg() can't be used).  Assumes buffers weren't written to
  * yet.
  */
-static void virtqueue_undo_map_desc(unsigned int out_num, unsigned int in_num,
+static void virtqueue_undo_map_desc(AddressSpace *as,
+                                    unsigned int out_num, unsigned int in_num,
                                     struct iovec *iov)
 {
     unsigned int i;
@@ -1630,7 +1632,7 @@ static void virtqueue_undo_map_desc(unsigned int out_num, unsigned int in_num,
     for (i = 0; i < out_num + in_num; i++) {
         int is_write = i >= out_num;
 
-        cpu_physical_memory_unmap(iov->iov_base, iov->iov_len, is_write, 0);
+        address_space_unmap(as, iov->iov_base, iov->iov_len, is_write, 0);
         iov++;
     }
 }
@@ -1832,7 +1834,7 @@ done:
     return elem;
 
 err_undo_map:
-    virtqueue_undo_map_desc(out_num, in_num, iov);
+    virtqueue_undo_map_desc(vdev->dma_as, out_num, in_num, iov);
     goto done;
 }
 
@@ -1982,7 +1984,7 @@ done:
     return elem;
 
 err_undo_map:
-    virtqueue_undo_map_desc(out_num, in_num, iov);
+    virtqueue_undo_map_desc(vdev->dma_as, out_num, in_num, iov);
     goto done;
 }
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133927.1472025 (Exim 4.92)
	(envelope-from )
	id 1v3Vga-0005Y7-Oj; Tue, 30 Sep 2025 08:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133927.1472025; Tue, 30 Sep 2025 08: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 1v3Vga-0005XX-F7; Tue, 30 Sep 2025 08:26:12 +0000
Received: by outflank-mailman (input) for mailman id 1133927;
 Tue, 30 Sep 2025 08:26:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Vd0-0007Nn-3c
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:30 +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 9af227d8-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:22:29 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-414f48bd785so3014676f8f.1
 for ; Tue, 30 Sep 2025 01:22:29 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e572683ccsm47008715e9.22.2025.09.30.01.22.27
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: 9af227d8-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220549; x=1759825349; darn=lists.xenproject.org;
        h=content-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=onCfEhinWarPReSMP2g+nvBYz1NYywUR3fuXcFIYVYM=;
        b=RxVpL7qLL8PYghUwO/br8zSWEQWLfhI7d4h5YPZIRCeqwON/I7XR118p31OjUKY7pu
         frcU/IQXQM5ZnGdADBh08rET3vKBZkfEExeXD84/fwQh5241Ld6QgQSDcxioq/YNSNSS
         Hmys58SlzN2lao3ltj132CUAstK/cb1p6iijO4/MgZrJ2vH98Lks5CQ+IghHu/GEEEjf
         yagr0sx2YWdWgHmr8h3T1sZIBogJeQgT0XCYJ/O+JCrsJ57XBXykExtf/nXRsZPwxITu
         AZMeRe6OCNONQKl2G9c2r2RzmPubEjWkh8NW2B7QvIgR+iLImKbbOp0xjv0aEnajp/YJ
         BmTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220549; x=1759825349;
        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=onCfEhinWarPReSMP2g+nvBYz1NYywUR3fuXcFIYVYM=;
        b=GrcpUapFCJiyGy/Si2qgpyRh0IlFFtPoDTR6WeAIbhPJTBk05r0w96840ChG9a5DoM
         wajvSaLzWj2KbNLTObgTns3SRHhiXJuWNQNd+HIT5sgKUpwDjXoJI83fWgZyWGb+j8F+
         CjLodZ8CNYKK+Buvfw6BWI7xvWVrU07WQhkbjADH4Blub0jrjw+YyZwDehY6nS0OYc5j
         pN9LTRFRRzNggmUC3L5msE5NzMOPAjWQkk4ZjQoplYtz2H5uvsl64iOteHK006FRoyTe
         rjOJdDbLjLGrD5AY34ETPxIFm0tOegI6Ln0EbitagGmdu8pjG8KjAohRoBUmPUjvHAQF
         p4iw==
X-Forwarded-Encrypted: i=1; AJvYcCW5smS2CyxhdhLWSStz2u60+TLtyQfjQx9SJYnKctKMPqAKME0ufG3yX3pOR/3CCu8hxxfUZdhwPNY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxLiSPaYAemMkzdcxakYPC4R33y4yx5fdxKLES55/aFXsZt21CT
	hszW+9hqV5ykAaQz4k/dp9qp/CLyNvdABgl6/IU4TNBDpqS2tE62Cw0jsvYut+TBEzA=
X-Gm-Gg: ASbGncuUom1knNDIzNEuxuDE6OYNwBNsCpM+mpnjl25kA5JDjdWFWzVJ8Go/aVhTJ30
	v3BtX3CvF5puCqQ2jEF/vPNErvnvJk1JEknYZs2hPs/IMHwBgv46B+Pz4dylx7bapP+oVOcZbnU
	ZwI9QYozDuOEss3KZ+0VAMd1UhTg3JUR/xlZn+kTgNM/I9DkF+QpC2u9nY+pFKrdEqLbFBe1ghZ
	HTcSmunNi4ulqHW4rdTwivrzmuasDWFxuvuq6vRgg6YTrkYPpuUKgp+wuuHqO4aJUzfXviSRtD3
	ibmhOhNTfYpCfEkVCgvLpfX/HkKW+RmxksKo0Zt4xGbE7CbCmIuvrAJrvLPRw8x3ts72b4gI+wL
	IkxstfEL9acdvvdaDH8X0tBOPnn/yiSyAb9ryRCeUWwMhsCE2a3jmBDpFk+OhFP3eimHBw30W32
	43S9EYdkcAYpEphtODOqBKeV2OrNBbfTA=
X-Google-Smtp-Source: AGHT+IGEB7zt4QY7wj3rTZFjv9pmOMXqLorCZDEnNJaXiQGRhxTkEhGFSRSSrKDdM5xt6JNSxZxslA==
X-Received: by 2002:a05:6000:18a7:b0:3e9:d0a5:e436 with SMTP id ffacd0b85a97d-40e437371acmr19690967f8f.23.1759220549024;
        Tue, 30 Sep 2025 01:22:29 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 11/18] target/i386/kvm: Replace legacy cpu_physical_memory_rw() call
Date: Tue, 30 Sep 2025 10:21:18 +0200
Message-ID: <20250930082126.28618-12-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Get the vCPU address space and convert the legacy
cpu_physical_memory_rw() by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/kvm/xen-emu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index 284c5ef6f68..52de0198343 100644
--- a/target/i386/kvm/xen-emu.c
+++ b/target/i386/kvm/xen-emu.c
@@ -21,6 +21,7 @@
 #include "system/address-spaces.h"
 #include "xen-emu.h"
 #include "trace.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 
 #include "hw/pci/msi.h"
@@ -75,6 +76,7 @@ static bool kvm_gva_to_gpa(CPUState *cs, uint64_t gva, uint64_t *gpa,
 static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
                       bool is_write)
 {
+    AddressSpace *as = cpu_addressspace(cs, MEMTXATTRS_UNSPECIFIED);
     uint8_t *buf = (uint8_t *)_buf;
     uint64_t gpa;
     size_t len;
@@ -87,7 +89,7 @@ static int kvm_gva_rw(CPUState *cs, uint64_t gva, void *_buf, size_t sz,
             len = sz;
         }
 
-        cpu_physical_memory_rw(gpa, buf, len, is_write);
+        address_space_rw(as, gpa, MEMTXATTRS_UNSPECIFIED, buf, len, is_write);
 
         buf += len;
         sz -= len;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133930.1472033 (Exim 4.92)
	(envelope-from )
	id 1v3Vgb-0005ps-Vk; Tue, 30 Sep 2025 08:26:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133930.1472033; Tue, 30 Sep 2025 08:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Vgb-0005pc-PB; Tue, 30 Sep 2025 08:26:13 +0000
Received: by outflank-mailman (input) for mailman id 1133930;
 Tue, 30 Sep 2025 08:26:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3VdB-0007Nn-Kt
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:41 +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 a1971d11-9dd6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 10:22:40 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3ecde0be34eso3285326f8f.1
 for ; Tue, 30 Sep 2025 01:22:40 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab4897bsm257449245e9.17.2025.09.30.01.22.38
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: a1971d11-9dd6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220560; x=1759825360; darn=lists.xenproject.org;
        h=content-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=U9bErLRqv9kjbdzs2kwz9FzL8C8SAPMQ12Esuz3D9Fo=;
        b=EEHPjFd5YP/c1It0p0gAQmYOFqqn6Yici7VxcUYzqFhfKEn2b5XrzE952uEr8fk/lU
         wvznNQJcxYgiVbM/2nDu5jMyLmjuHxS20DA1JEy8/L02IWvmlSkmvrPrAFuGDt3F5W3B
         Pm6sYbmCg2GFNqIV6+Wy02uDGrEB/y8Vlq+LnUNhR6B7+ojbpPmYrbZbRSQDA/kKQHCz
         5vjrQy0xFhQJTihxk7Mh4cwVATDiGxLtEnp4k931QkmYEu0LkaGRn53oD5AeDa+k7XGu
         Qf3GD99p3oRVo56QI9GoU+humhq9yqcs8I3OUfHMRWY+88k1cpnj574MFdxDW5Ci0MNx
         EsNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220560; x=1759825360;
        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=U9bErLRqv9kjbdzs2kwz9FzL8C8SAPMQ12Esuz3D9Fo=;
        b=f31LaguS1YrW957NZGHZ4s1BwYROyP7456b+xKif3Estb/rINHDzDV3BvohB0ifby1
         jfaf7iNcsEyskcvy+V9tLXtfld8T6RwB3PkMucDu7HJ2n4dCGfenAvgtaO2gBebrpcrs
         ZNQabtjTgRwa+DFSHuZwfPD71c0MFKKBoztxTI44RI6pUlqVnqi6gjDWEi6panPPJKpw
         Z55XqfxfvJzN+Cy0Tdn+6VnjHZOaKmL8D7SmrUTt1JPb5ghGu8LWH35r14fB3JPRqhYT
         tAnlOr13KeTU4llxhrBO4vwCAnPnOmCmmGYckT9ULVYxi1h+HbioJUWCBXEldUu2qKpa
         6Yxw==
X-Forwarded-Encrypted: i=1; AJvYcCXKT8hUgDoOySATjQT5V2VgE89UaB8tqDkb+rclN18Kd5AI6/AzJpDz4vxmtWaXNeXkaeyAZuNeI/A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxs2iCm8TZ0rzJ//eCgWl7u+JMivATe2ukEFuGas6EATe1XczI0
	ITIW+mpjoI2FzYaXrve4pEOuCpMFEi40HlRzXqFhAyzBfQBVu1GW65/6iCz+CbSdISQ=
X-Gm-Gg: ASbGncu1kOT6UbXMo6wZW8PjYSZQPJF7vc0xteJEf3x/a7cHVRJgDYbXi2l7nt8Ioe5
	eb1/b4V6zFNmO+Yfgd7MZmPWVEjRXqlO6Y08mxv9cgfO/viYf8ZIZP6vHmF+VOOM0SvLvP6nLp6
	xy0TxM5MFzgS9Sz/ad0qAAAXVNs138UW2Le8abTtoObs5N5oS5do5FhfQBSAK4tk8/gIUonERV5
	251Yrhep/6gEmhjTXWH9HSAqNl/ZFZS4goq/5AEAL1mXOIhVkUKmhnbnlR/wK749zQPbVpzHbL4
	coGy7scQjlnBvxsuU1Z+ImoYMWjsYTy7IFudNuvqekP+6agrSXglVhiPGPccjc5pXKXaDJKRHy6
	/hpmvSt4WQn3U1SVg/v2VqLSUHZekka/ctu0xHtGwUYajtjODLY2W6GgTbnmVWq3AhxGszubMw3
	ebOUa6WiqwfkmUMSt1NX1oZAzqUT+YuLc=
X-Google-Smtp-Source: AGHT+IFKquQgcsAUg0Wckpi3Q1uVvpKK2LWW0oi9N9Q9t0bhLrHk1BTizML0eTatl5XEnZE1L5+HFQ==
X-Received: by 2002:a05:6000:40c7:b0:407:d776:4434 with SMTP id ffacd0b85a97d-4241227789emr2953961f8f.30.1759220560163;
        Tue, 30 Sep 2025 01:22:40 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 13/18] hw/xen/hvm: Inline cpu_physical_memory_rw() in rw_phys_req_item()
Date: Tue, 30 Sep 2025 10:21:20 +0200
Message-ID: <20250930082126.28618-14-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_physical_memory_rw() is legacy, replace by address_space_rw().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/xen/xen-hvm-common.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index 78e0bc8f644..52e2cce397a 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -12,6 +12,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/boards.h"
 #include "hw/xen/arch_hvm.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "system/system.h"
 #include "system/xen.h"
@@ -279,8 +280,8 @@ static void do_outp(uint32_t addr,
  * memory, as part of the implementation of an ioreq.
  *
  * Equivalent to
- *   cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->size * i,
- *                          val, req->size, 0/1)
+ *   address_space_rw(as, addr + (req->df ? -1 : +1) * req->size * i,
+ *                    attrs, val, req->size, 0/1)
  * except without the integer overflow problems.
  */
 static void rw_phys_req_item(hwaddr addr,
@@ -295,7 +296,8 @@ static void rw_phys_req_item(hwaddr addr,
     } else {
         addr += offset;
     }
-    cpu_physical_memory_rw(addr, val, req->size, rw);
+    address_space_rw(&address_space_memory, addr, MEMTXATTRS_UNSPECIFIED,
+                     val, req->size, rw);
 }
 
 static inline void read_phys_req_item(hwaddr addr,
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133941.1472046 (Exim 4.92)
	(envelope-from )
	id 1v3Vge-0006I0-8u; Tue, 30 Sep 2025 08:26:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133941.1472046; Tue, 30 Sep 2025 08:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3Vge-0006Ho-4c; Tue, 30 Sep 2025 08:26:16 +0000
Received: by outflank-mailman (input) for mailman id 1133941;
 Tue, 30 Sep 2025 08:26: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 1v3Vcr-0007Nm-4e
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:21 +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 94701ed8-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:22:18 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-46e4f2696bdso31581035e9.0
 for ; Tue, 30 Sep 2025 01:22:18 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb871c811sm21599810f8f.15.2025.09.30.01.22.16
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: 94701ed8-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220538; x=1759825338; darn=lists.xenproject.org;
        h=content-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=2kEeDKj/VliAI89NHWLpYrYcoI7vlOg/a8aX+CJnHKA=;
        b=lfW1GHFZ4K9+Z1nAe/QhLaTxvPBOdoWoMTno6KJZ856BGI7l6BZN4JFDNMm5OQMmWX
         txsEpl9yGsmbUzNFLq+6XwgnHH2UsmxIZabAbMD5kIC0SelSJA3fNtri1KJhiYqnKnEi
         +QCga/eDtKe3ePKGNFGSK99/3xCzI8SqkcfJJxx1DiJItfaxT2Xl0LMoB3deOImNdeft
         /xOe9JzDppZO2p/z3DHZ+TR71hXV1HFDR2uFWV1BAo1pR7Obgh6zHy4yjkFx715Le8mH
         1SbU7Xe5uelKS2ca7jlp2txHW4gKCzjfxCGR2gzzUHDTAqt1JpjdlyzSIVrZs/BN87/J
         PTvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220538; x=1759825338;
        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=2kEeDKj/VliAI89NHWLpYrYcoI7vlOg/a8aX+CJnHKA=;
        b=iPgrQ0UCminCcA1C+hxRd8fEtCB/JU7OghTy0sk4r+gO2Gx+AkRhsv6hW2It8mEVpt
         0iJ+P6lb/ywrO80O+jkbSwbno8HlXsjeOm9XXFN3TCmbc/MX0pEQpqXZVP0TySCy7X2B
         D2pnrWdSgJEWg/A/+TDirJINpBHruK+oJYyuKwVuq1sd2z9N6gaWjKU0HXmPZNlGLe1S
         Zt06jffrFSGDH0EpB6DikmrONPzo0TV4IWai0W8BABoCyGyapO4mBpFG6HYoahlA/npc
         qPF8wR1DrwD/2bFeTHv8PxrqxS4XPvvXFBISD1Je44OneqdMHOeYbukRhZJi5b0/fv6w
         9QQA==
X-Forwarded-Encrypted: i=1; AJvYcCUj7/JpQhjpBOkDY/wW9V9kRgxaHx5l/P2ZVvs73VsMLjgBbGqnJ+ltitLyEBRPoCmaY3C5xzEz4mE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQ1PiERUF82uNfuX6WqQOsvUHXshWtCNgNwkFohWs7OeINB/Bk
	mpK5n+X/Ucw8ktGz+jbJ7ZSUNinAFZYwhQHE1RQm0nHHpj7X77LffNmNuPGvZqjeXfE=
X-Gm-Gg: ASbGncvP0t24frZENPnJaDaSwwxuCifqjmDjWzpZSD9GQwEF0kA/R6e+lT82t7ZG9mZ
	rLnX7KnWUm62YzG1xcTqHEQg+BNSLf+6Un9bWeHfI4KCrCC+C4Cpl3FazCDBm4TGRKfMC8x2GyP
	7X4fvkGnkdTtgmeQttJuJfGk2fNO/CHzZeuHte8YZyAQrcWJHOLNUnl1NZIqFXn2RYSG6jSakSO
	D7n4P4bAT1dkxn64PR8F9LjUWlL6rztiWyYdL6FsaiOnE1QLZi1KsAEmf+6lh53PFKQX1icsihx
	q0jk9fPcFkZt+MDuQwJQUvZLXvl7rlYOvwtECyMxXfebHmudxR6G9/tOiK3Fa51qC2SmI6I7tA7
	amn/8+oM5c6K9uksinxPNaQUU7k3dqt6/IQuAl2u5gcC2Uhe0+6Fn07pwmt3lxaZjEuh/PjqBUs
	uExphBK835+IZ74D9HI0qECu5xQnlV0PQ=
X-Google-Smtp-Source: AGHT+IE8kOnIri7d9kIT89vkssg0QjxuyhNQyNkBu4zqQAFaAaCY/pGZVE1XfJtvAVhQrg/vBoJaIA==
X-Received: by 2002:a05:600c:1386:b0:46e:1b89:77f1 with SMTP id 5b1f17b1804b1-46e329e28f8mr169270875e9.9.1759220538270;
        Tue, 30 Sep 2025 01:22:18 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 09/18] target/s390x/mmu: Replace [cpu_physical_memory -> address_space]_rw()
Date: Tue, 30 Sep 2025 10:21:16 +0200
Message-ID: <20250930082126.28618-10-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When cpu_address_space_init() isn't called during vCPU creation,
its single address space is the global &address_space_memory.

As s390x boards don't call cpu_address_space_init(),
cpu_get_address_space(CPU(cpu), 0) returns &address_space_memory.

We can then replace cpu_physical_memory_rw() by the semantically
equivalent address_space_rw() call.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
---
 target/s390x/mmu_helper.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index 00946e9c0fe..4e2f31dc763 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -23,6 +23,7 @@
 #include "kvm/kvm_s390x.h"
 #include "system/kvm.h"
 #include "system/tcg.h"
+#include "system/memory.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
 #include "hw/hw.h"
@@ -522,6 +523,7 @@ int s390_cpu_pv_mem_rw(S390CPU *cpu, unsigned int offset, void *hostbuf,
 int s390_cpu_virt_mem_rw(S390CPU *cpu, vaddr laddr, uint8_t ar, void *hostbuf,
                          int len, bool is_write)
 {
+    AddressSpace *as = cpu_get_address_space(CPU(cpu), 0);
     int currlen, nr_pages, i;
     target_ulong *pages;
     uint64_t tec;
@@ -545,8 +547,8 @@ int s390_cpu_virt_mem_rw(S390CPU *cpu, vaddr laddr, uint8_t ar, void *hostbuf,
         /* Copy data by stepping through the area page by page */
         for (i = 0; i < nr_pages; i++) {
             currlen = MIN(len, TARGET_PAGE_SIZE - (laddr % TARGET_PAGE_SIZE));
-            cpu_physical_memory_rw(pages[i] | (laddr & ~TARGET_PAGE_MASK),
-                                   hostbuf, currlen, is_write);
+            address_space_rw(as, pages[i] | (laddr & ~TARGET_PAGE_MASK),
+                             MEMTXATTRS_UNSPECIFIED, hostbuf, currlen, is_write);
             laddr += currlen;
             hostbuf += currlen;
             len -= currlen;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133949.1472056 (Exim 4.92)
	(envelope-from )
	id 1v3Vgh-0006oC-3O; Tue, 30 Sep 2025 08:26:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133949.1472056; Tue, 30 Sep 2025 08:26: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 1v3Vgg-0006md-Oq; Tue, 30 Sep 2025 08:26:18 +0000
Received: by outflank-mailman (input) for mailman id 1133949;
 Tue, 30 Sep 2025 08:26: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 1v3Vcp-0007Nm-41
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:19 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9155b3cd-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:22:13 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-46e42deffa8so47193365e9.0
 for ; Tue, 30 Sep 2025 01:22:13 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e5c4dd9e4sm7814745e9.10.2025.09.30.01.22.10
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: 9155b3cd-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220533; x=1759825333; darn=lists.xenproject.org;
        h=content-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=8QFdShgwZbpOIuoiHkRuMdwMlUbV145lKXZsf/3KvUE=;
        b=NwL/kfbewah3Lc3tgY1eciku0lX97KGreL8vii1VmWd+3/wr5tbA3vMa3MEEMnaS85
         e0WubKOQd+WLTQJo4FiXgfXrCVMxF8k/H6watxUHGs1hlkvlP0DDDtJfZx0KnNxDgry+
         bB36RWaPNhddA3B/wsmQa24/ZYUgIDBFI9xDMqmCZormiM+N6yXoxbjmvZUoHOdhk7tB
         h5O27zG4WV9zvTYScm/e039cR8mkAbGbdhRxbDBANH8pmBkqPW3MWi1jDFer4b9QbJER
         wNpkVr08A9qGS2npRTMxRT7r/KrUeFvhMJxIiCsM5ojw8xU8IPpoLxv49jSvXOIsMvn3
         yYFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220533; x=1759825333;
        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=8QFdShgwZbpOIuoiHkRuMdwMlUbV145lKXZsf/3KvUE=;
        b=GHXYC6gUFzT7epSqBppbosRcIVcrln4y2mULVqo+32e7FGe23ufOBfnBlgSEPA9tIH
         8wCydvawdmS59kZQURyQ1yrvUTZsLVC51Z7Wxn8cpt6fU6Qh1Qk4AIMPX1f7ffHHXPBk
         2L7aUwDKA3c3neQdbp523MLvvii60QX+8pavRiSNgqO5bgDa4anh3jvGfWfqbZ+FumES
         BKwgNmze56orL++tCGdEEt0Q9v881dScL6InIY/RUCbJK2sOfB+Vt2uDghD+5RKeS2Ld
         EgK2ELpRBM9MF91yaI0maDOCuVAVFVQSeCLskKAgU5TyKeJ4Rth/v871pI6/XI/mUZ5M
         dFrw==
X-Forwarded-Encrypted: i=1; AJvYcCVyXmjfdCCCRFSAn6hE03WBOZ+sAZU5rHi0iIPbChKovpTKyfthzHkF9Q42EL2LM8eU4B/zdfWuntY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgUHDumzU5jVTAJmXOiPR48b8U+HA4r2I1SEIORDlHiCviqhkt
	M/xs4HqNWWygNjQ5ZFX7G8IhwLQC5yaiEsatbf82OaTJMZdT0BhNN7mQYqW//z4RF1Y=
X-Gm-Gg: ASbGncvP8fM8ssERGyOpLQ/mZZEDVq6ZogpV5Q5O3r3b9RHcllAvzeTMMrXyKMWMJhr
	WfEhMEFqZUPeAHBkN7pgGH9odzTSsizA6qkfjTQFVRaXs8/pHCX5LzYfvQS0zezJXwWRTbVk8RM
	6JHAqdf1pF8g9LhMIipDYL6scFrQLp5qXQJd8TE7RsgG70pAFcFeadpCnlWyY8IrIt7OnW6emp7
	Z/878Hiydra80Du+kW9X0OrjDmf9cfnS5SodAoZAc0pximqBIy2IByL3gGfJlcoi7oOobEFCgic
	X7B/3XrfzYACTQZJYy+j8yIydPuQaSNZpSn8eTQ/KzV7REKdHCfbm5wXe/P8X78t1alNqpTSXsK
	RxEbH3xFadtf45o+96DbEWEOAm6CiNFSc992GLpXGntF5wjVzzBGWdB0A1URXC7B/h7HE4MLgGV
	gpvndQeBjDTLi25Le1UwiinNJFlAr7tRCPvDcORFWlFw==
X-Google-Smtp-Source: AGHT+IGBMYpWSXfOX3el6uig3+R7ujcKxPeYiLaNhqcFnuUIbzB/w07fZP+NVrmJYAyBxxupmR40fA==
X-Received: by 2002:a05:600c:1d14:b0:46e:432f:32ab with SMTP id 5b1f17b1804b1-46e432f395cmr126597005e9.33.1759220532938;
        Tue, 30 Sep 2025 01:22:12 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 08/18] hw/s390x/sclp: Replace [cpu_physical_memory -> address_space]_r/w()
Date: Tue, 30 Sep 2025 10:21:15 +0200
Message-ID: <20250930082126.28618-9-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cpu_physical_memory_read() and cpu_physical_memory_write() are
legacy (see commit b7ecba0f6f6), replace by address_space_read()
and address_space_write().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
---
 hw/s390x/sclp.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f507b36cd91..152c773d1b4 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -319,7 +319,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
     }
 
     /* the header contains the actual length of the sccb */
-    cpu_physical_memory_read(sccb, &header, sizeof(SCCBHeader));
+    address_space_read(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                       &header, sizeof(SCCBHeader));
 
     /* Valid sccb sizes */
     if (be16_to_cpu(header.length) < sizeof(SCCBHeader)) {
@@ -332,7 +333,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
      * the host has checked the values
      */
     work_sccb = g_malloc0(be16_to_cpu(header.length));
-    cpu_physical_memory_read(sccb, work_sccb, be16_to_cpu(header.length));
+    address_space_read(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                       work_sccb, be16_to_cpu(header.length));
 
     if (!sclp_command_code_valid(code)) {
         work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
@@ -346,8 +348,8 @@ int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
 
     sclp_c->execute(sclp, work_sccb, code);
 out_write:
-    cpu_physical_memory_write(sccb, work_sccb,
-                              be16_to_cpu(work_sccb->h.length));
+    address_space_write(as, sccb, MEMTXATTRS_UNSPECIFIED,
+                        work_sccb, be16_to_cpu(header.length));
 
     sclp_c->service_interrupt(sclp, sccb);
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:26:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:26:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1133960.1472066 (Exim 4.92)
	(envelope-from )
	id 1v3Vgj-0007OP-RN; Tue, 30 Sep 2025 08:26:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1133960.1472066; Tue, 30 Sep 2025 08: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 1v3Vgj-0007Nx-HG; Tue, 30 Sep 2025 08:26:21 +0000
Received: by outflank-mailman (input) for mailman id 1133960;
 Tue, 30 Sep 2025 08: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 1v3Vd6-0007Nm-Jl
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:22:36 +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 9e04926c-9dd6-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:22:34 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-46e52279279so14718645e9.3
 for ; Tue, 30 Sep 2025 01:22:34 -0700 (PDT)
Received: from localhost.localdomain (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fb74e46bcsm21775814f8f.8.2025.09.30.01.22.32
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 30 Sep 2025 01:22: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: 9e04926c-9dd6-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759220554; x=1759825354; darn=lists.xenproject.org;
        h=content-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=QtU1C0M8U0OTbHcI2E95ZD2Zrsmz5/OESKETD6NudSM=;
        b=btkaxKle6qF/ovKjiGQ9wY2p1NyTjGlhcKZIT4HUSFB/5stuQuAyytPlWH0PNgC2tG
         va+MiOuTIc8vyLC3B4xqPTeIrOBNoNt3Rfx6pqfgswmp1uGQ9lE7tlU1QDPKWkVgRJEX
         G+lA7yo8oKD786ssLnijCzOC9loxrH303xJ6IpMeCV9Jo1yoF6M2LG29mwQ67e9aNDiN
         0Kfe+sjdNqtLScP5S62urALa63yemJdsXX6d7S58vJnTquaT2BnZdsKfwKpJfr7EGLhE
         2Ck6D9klD++sTnPzcdjiYmDcftYZgAlth8Y7o7sFvNA0nY3AafUB5kXtc9v6BToHZrgn
         wVHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759220554; x=1759825354;
        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=QtU1C0M8U0OTbHcI2E95ZD2Zrsmz5/OESKETD6NudSM=;
        b=w7sfMN5PK2kGGVaQXYZ1PQrMVk0SLkVFs4sNLMRrcRDcN/TiyHkECQDlxR8dieBpPS
         QJoEoVMlL0Ei5Ak/lBzyQIdkaAaBbgfnWISXADQx+xIUrLjriAxA45Rk1qhznWGt6wE+
         ZcV79pbOxKuspF1Jao3gK24qbSzQ/uZwqkaBFggs1kkUedKJkH1WwYoXOhl8ja+C6QaS
         rF2OSyQRZ3foOKgrQzZriVTzMlzjIxATo0SXSnYtKqxC9caRiHfAMwM6GFwgi4PY1qG0
         ZKmOyjmHtxXWNT07zZPdwBcV06h6YpOe4/dhFeDYZUANPdZ3N13Yb6DUmYnueNl34buw
         NUjg==
X-Forwarded-Encrypted: i=1; AJvYcCWQn7J6DUALMXcm6QD2Ik4ZDLbg4DqelREFSX0Qxo+3iqBCWT4FFaMINs18+mq7Khfn7MYOluyPlOk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzvIEW1Ma5rylneO3MrGMwkDhoZgMRl/m+kzXUvyd80RvCmVt+p
	Odqt7cyFeCpIQH+bUi/Xn2SF5hV08UbYd4eKSIZLuxKw3ThELy9AbB5j1ubewXE8W1stb3eNacl
	4sFkgzExZDA==
X-Gm-Gg: ASbGncurI1V6BDtisA0J6nO+ZUC+Bj++zeIXBrH0/wK/el5V567M7sJKstd3CAivmhR
	xhD42bJDp4MTijAVB+FXXSrqEkzyp52n+ek4QnUsHQ76CO5qJblx+mzHUPqF9NCjxg9XsLegzyB
	lCg2mB0WcR45mOgu1As3xQ1YVAqCfm6DoUi3/UqQ/IOXvpAMlLtu8Ib3QhQ27ifwOJE8TGjC6Gp
	JDKYESC8xFx3jIgq8G/j39tLLkbotrXW3TSE7RQEhDFzb8fVWWjvZcRH0Cxm6sz49V3kJEFgwL7
	iGZcntjiDAY9s3eYTJcww0BTNB1FOwCPEAkP/ayDe4Gc8ESmD8pYatR3MaegypQXMCYM7yezhWq
	gCIHtLxYe9VRdEneFSnOC42Iu5QG4imihPWIdNrtcdrT8Ou8rd+75tGcWEypjbP6baBeLFC1yJs
	b3rTBB6QmIEIuU6HoDlPmQkDq2DvPZMgU=
X-Google-Smtp-Source: AGHT+IHFPJkofYr79h9pu+6ONde86qKMR3dCMR8GX+HG+gEgb0uWvZOFxlaIJxTQ7PTY8pGPvnTorQ==
X-Received: by 2002:a05:600c:81e:b0:46e:1a14:a81b with SMTP id 5b1f17b1804b1-46e32a1a396mr111982275e9.36.1759220554357;
        Tue, 30 Sep 2025 01:22:34 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org,
	Peter Maydell 
Cc: Marcelo Tosatti ,
	Ilya Leoshkevich ,
	Reinoud Zandijk ,
	Peter Xu ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Zhao Liu ,
	David Hildenbrand ,
	Halil Pasic ,
	kvm@vger.kernel.org,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org,
	Stefano Garzarella ,
	David Woodhouse ,
	Sunil Muthuswamy ,
	Richard Henderson ,
	Stefano Stabellini ,
	Matthew Rosato ,
	qemu-s390x@nongnu.org,
	Paul Durrant ,
	"Michael S. Tsirkin" ,
	Christian Borntraeger ,
	Anthony PERARD ,
	Jason Herne ,
	Paolo Bonzini ,
	Thomas Huth ,
	Eric Farman 
Subject: [PATCH v3 12/18] target/i386/nvmm: Inline cpu_physical_memory_rw() in nvmm_mem_callback
Date: Tue, 30 Sep 2025 10:21:19 +0200
Message-ID: <20250930082126.28618-13-philmd@linaro.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250930082126.28618-1-philmd@linaro.org>
References: <20250930082126.28618-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/nvmm/nvmm-all.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/nvmm/nvmm-all.c b/target/i386/nvmm/nvmm-all.c
index ed424251673..2e442baf4b7 100644
--- a/target/i386/nvmm/nvmm-all.c
+++ b/target/i386/nvmm/nvmm-all.c
@@ -15,6 +15,7 @@
 #include "accel/accel-ops.h"
 #include "system/nvmm.h"
 #include "system/cpus.h"
+#include "system/memory.h"
 #include "system/runstate.h"
 #include "qemu/main-loop.h"
 #include "qemu/error-report.h"
@@ -516,7 +517,9 @@ nvmm_io_callback(struct nvmm_io *io)
 static void
 nvmm_mem_callback(struct nvmm_mem *mem)
 {
-    cpu_physical_memory_rw(mem->gpa, mem->data, mem->size, mem->write);
+    /* TODO: Get CPUState via mem->vcpu? */
+    address_space_rw(&address_space_memory, mem->gpa, MEMTXATTRS_UNSPECIFIED,
+                     mem->data, mem->size, mem->write);
 
     /* Needed, otherwise infinite loop. */
     current_cpu->vcpu_dirty = false;
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:31:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:31:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134024.1472076 (Exim 4.92)
	(envelope-from )
	id 1v3Vm2-0002Pd-Bv; Tue, 30 Sep 2025 08:31:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134024.1472076; Tue, 30 Sep 2025 08:31: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 1v3Vm2-0002PW-8Q; Tue, 30 Sep 2025 08:31:50 +0000
Received: by outflank-mailman (input) for mailman id 1134024;
 Tue, 30 Sep 2025 08:31:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3Vm0-0002PQ-Em
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:31:48 +0000
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com
 [2a00:1450:4864:20::344])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1087660-9dd7-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:31:36 +0200 (CEST)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-45b4d89217aso35954915e9.2
 for ; Tue, 30 Sep 2025 01:31:36 -0700 (PDT)
Received: from [192.168.69.221] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc749b8f9sm21268471f8f.50.2025.09.30.01.31.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 01:31: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: e1087660-9dd7-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759221096; x=1759825896; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EPblYzRdSvAbjbwbh03+CbSDEcFIuNHCFm6Gcm76lBw=;
        b=QKJt49tYg51cPQwlczJeIUMj0IhdqXMc8ysLHdfast/7ojucV7ZkTMCqr0OiriZ4z1
         SDWz1+Fpt3n+nnwMpjxmUktL61c2Yq90biClOtEQv6CiKc+pWAbUfEUyjuYrodRjR6Dg
         6IInt8qp8A4G9iAfYbOCzQz93w9eYe6Lp37dtKTvW669WkUXyxdXTZxEnaOwZecPzeyK
         lPMG0If2RRXf9id2RuGyKXVs2tWUyoWz0q/kV8HmzlFOiDiIShS8V/racjr41ni+W4pN
         UWQZxURvX0rwgS2VbUCOYR3kzufEEq1u3WNcQehcjCuZTUjtfPoQ1mtsgTuGi5/TP3rj
         IygA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759221096; x=1759825896;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EPblYzRdSvAbjbwbh03+CbSDEcFIuNHCFm6Gcm76lBw=;
        b=PuvAssfas3diFpWWF+/8LCUvSxfNUCQryLUR3TjcNPvCR3tgyJcuyKTkluXgzQv33H
         ueqIncoDLK1dUNy628VAo6XHawCbGcUAFoZsH7y0YDgK+corKClq4Q2gXOJBCytGeAA5
         vJkzKWpd/41wg20pkpU+cuxrWjK6uyxfcMSAROVe5Mea5K3GpVJdI0SS3orDl1reu6SS
         +F8jK6ukAfuCaXv4ggoI+NkO5P+b0vXQFdC9poGykyL/q8ljW1dwcS02AVxh+QEWFOdD
         UgCCBVF5ff37KkeaaGXEMhijGO1dJb78TgA2RWGfPtr7zgFacdULQS6CMOn6xduYGik5
         w83g==
X-Forwarded-Encrypted: i=1; AJvYcCWPu8ZbJfTKamDjTuZNLrHGrCThO32hbcpIGHBAe7Z/+Fhn1hacpPf59ddOXLslifhXGW87yMDwp38=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yywle6BrqmRMLL3Wm5JTwjGzWE1svFaNwhpdv5mKmotyoZrgs81
	jyQRvRba+XBORri6lDSMQIeDfuSl3xO9MY7xYMBsQjt2TWTd7FPvdN8kWhMlpvBGRdQ=
X-Gm-Gg: ASbGncsP0QA1FJJav2vuVT90Vu/N7CL0Pa4pr5OIF0Ni2STit/IgAze4MXVdUscO5KP
	sc2Og609upMbH07zcE6eQQRWd65xhkQ+06tCdTZQSE3WNyLXv2ko2uuXXgKNyfO7w0XYAlZKMF7
	gKKorpdVFbMV9Wws68BKDxczH6P/7HE4U3FGQKxQ2iu8BSnFjI5jOQzqedipIE0U8XcmykIFDN/
	cf+C2TRQRJ6JCYOlMQSFCRUdsGjITwkVgAUkVmJCHSKkWuQSOWFapVX7VgJYFs5mKa2U3IhIsYv
	6HCkQrVjLeR9rZWL4pvWgmNXh6ZwosXDTnucv3Zln5/WUVvRvWe0qSTu1fxlXRB34/acZEbenwa
	UTO7rxbDLAvKB7YSiN33o5XjKm8Q7OetOCymh9EF9E1cxiPrcrqOWkOztGsWfV0wgQex2OJE+vk
	OiitPcunfnJPsDyQ==
X-Google-Smtp-Source: AGHT+IF0LgtI7pDkBA/eYAeHLSMtAuwN7D6X/YI2HPPLpuFu6atvuEp5p5mznrjKdUvD2ZsGu34EiA==
X-Received: by 2002:a05:6000:2385:b0:405:8ef9:ee6e with SMTP id ffacd0b85a97d-40e4a8f9b38mr19131448f8f.25.1759221095990;
        Tue, 30 Sep 2025 01:31:35 -0700 (PDT)
Message-ID: 
Date: Tue, 30 Sep 2025 10:31:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/18] system/memory: Better describe @plen argument of
 flatview_translate()
Content-Language: en-US
To: Thomas Huth , qemu-devel@nongnu.org,
 Peter Maydell , Peter Xu 
Cc: Marcelo Tosatti ,
 Ilya Leoshkevich , Reinoud Zandijk ,
 Zhao Liu , David Hildenbrand ,
 Halil Pasic , kvm@vger.kernel.org,
 "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org, Stefano Garzarella ,
 David Woodhouse ,
 Sunil Muthuswamy ,
 Richard Henderson ,
 Stefano Stabellini ,
 Matthew Rosato , qemu-s390x@nongnu.org,
 Paul Durrant , "Michael S. Tsirkin" ,
 Christian Borntraeger ,
 Anthony PERARD , Jason Herne
 , Paolo Bonzini ,
 Eric Farman 
References: <20250930082126.28618-1-philmd@linaro.org>
 <20250930082126.28618-3-philmd@linaro.org>
 <525dd07f-ae64-4ba7-b3ec-b9fcd86aa8a5@redhat.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <525dd07f-ae64-4ba7-b3ec-b9fcd86aa8a5@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Thomas,

On 30/9/25 10:24, Thomas Huth wrote:
> On 30/09/2025 10.21, Philippe Mathieu-Daudé wrote:
>> flatview_translate()'s @plen argument is output-only and can be NULL.
>>
>> When Xen is enabled, only update @plen_out when non-NULL.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   include/system/memory.h | 5 +++--
>>   system/physmem.c        | 9 +++++----
>>   2 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/system/memory.h b/include/system/memory.h
>> index aa85fc27a10..3e5bf3ef05e 100644
>> --- a/include/system/memory.h
>> +++ b/include/system/memory.h
>> @@ -2992,13 +2992,14 @@ IOMMUTLBEntry 
>> address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
>>    * @addr: address within that address space
>>    * @xlat: pointer to address within the returned memory region 
>> section's
>>    * #MemoryRegion.
>> - * @len: pointer to length
>> + * @plen_out: pointer to valid read/write length of the translated 
>> address.
>> + *            It can be @NULL when we don't care about it.
>>    * @is_write: indicates the transfer direction
>>    * @attrs: memory attributes
>>    */
>>   MemoryRegion *flatview_translate(FlatView *fv,
>>                                    hwaddr addr, hwaddr *xlat,
>> -                                 hwaddr *len, bool is_write,
>> +                                 hwaddr *plen_out, bool is_write,
>>                                    MemTxAttrs attrs);
>>   static inline MemoryRegion *address_space_translate(AddressSpace *as,
>> diff --git a/system/physmem.c b/system/physmem.c
>> index 8a8be3a80e2..86422f294e2 100644
>> --- a/system/physmem.c
>> +++ b/system/physmem.c
>> @@ -566,7 +566,7 @@ iotlb_fail:
>>   /* Called from RCU critical section */
>>   MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr 
>> *xlat,
>> -                                 hwaddr *plen, bool is_write,
>> +                                 hwaddr *plen_out, bool is_write,
>>                                    MemTxAttrs attrs)
>>   {
>>       MemoryRegion *mr;
>> @@ -574,13 +574,14 @@ MemoryRegion *flatview_translate(FlatView *fv, 
>> hwaddr addr, hwaddr *xlat,
>>       AddressSpace *as = NULL;
>>       /* This can be MMIO, so setup MMIO bit. */
>> -    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
>> +    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
>>                                       is_write, true, &as, attrs);
>>       mr = section.mr;
>> -    if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) {
>> +    if (xen_enabled() && plen_out && memory_access_is_direct(mr, 
>> is_write,
>> +                                                             attrs)) {
>>           hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) 
>> - addr;
>> -        *plen = MIN(page, *plen);
>> +        *plen_out = MIN(page, *plen_out);
>>       }
> 
> My question from the previous version is still unanswered:
> 
> https://lore.kernel.org/qemu- 
> devel/22ff756a-51a2-43f4-8fe1-05f17ff4a371@redhat.com/

This patches
- checks for plen not being NULL
- describes it as
   "When Xen is enabled, only update @plen_out when non-NULL."
- mention that in the updated flatview_translate() documentation
   "It can be @NULL when we don't care about it." as documented for
   the flatview_do_translate() callee in commit d5e5fafd11b ("exec:
   add page_mask for flatview_do_translate")

before:

   it was not clear whether we can pass plen=NULL without having
   to look at the code.

after:

   no change when plen is not NULL, we can pass plen=NULL safely
   (it is documented).

I shouldn't be understanding your original question, do you mind
rewording it?

Thanks,

Phil.


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:38:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:38:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134080.1472093 (Exim 4.92)
	(envelope-from )
	id 1v3Vsf-00040K-21; Tue, 30 Sep 2025 08:38:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134080.1472093; Tue, 30 Sep 2025 08: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 1v3Vse-00040D-Vg; Tue, 30 Sep 2025 08:38:40 +0000
Received: by outflank-mailman (input) for mailman id 1134080;
 Tue, 30 Sep 2025 08:38: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 1v3Vsc-0003zr-VO
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:38:40 +0000
Received: from casper.infradead.org (unknown [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da64eddf-9dd8-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:38:36 +0200 (CEST)
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]
 helo=noisy.programming.kicks-ass.net)
 by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
 id 1v3VsR-00000007vQP-2C9S; Tue, 30 Sep 2025 08:38:29 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
 id AAEA6300328; Tue, 30 Sep 2025 10:38: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: da64eddf-9dd8-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=3jlHGCv3KKfepny4/+8UDRH2Uchjm+ncAKZLjXBzPQE=; b=C8bP7++u/b5qMJnayCP05rlwX6
	siikOCS3dkib6Z13ktiKs0qkiKKxo2bs+qW2uD3E8MRuWp0Z0O4yRe2q3dJLi4I+/62oKlQOFt6JN
	esxZ861tBA7iWNxDXxOMa/7XA5jCPzTltJyqgGOSJC+5yvI90tXMXShLvSZIWZxHilpv9ZLOj6yvu
	FeknuqLFJe3UINMVdw17fYcqyoQLLavUTX4++UMaXmTpPptEmPfIe34/71CY0kDQhWW0eHM/zmqE+
	8FjOPvfqXZJ4BLRL7ZhjGC3PpCaXO//hmkJfr/x1YOeswxG0IQYA27jtiDzRwAC535u0407ggWCUC
	1+cRSFkA==;
Date: Tue, 30 Sep 2025 10:38:27 +0200
From: Peter Zijlstra 
To: Juergen Gross 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev, xin@zytor.com,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
Message-ID: <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250930070356.30695-12-jgross@suse.com>

On Tue, Sep 30, 2025 at 09:03:55AM +0200, Juergen Gross wrote:

> +static __always_inline u64 read_msr(u32 msr)
> +{
> +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> +		return xen_read_msr(msr);
> +
> +	return native_rdmsrq(msr);
> +}
> +
> +static __always_inline int read_msr_safe(u32 msr, u64 *p)
> +{
> +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> +		return xen_read_msr_safe(msr, p);
> +
> +	return native_read_msr_safe(msr, p);
> +}
> +
> +static __always_inline void write_msr(u32 msr, u64 val)
> +{
> +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> +		xen_write_msr(msr, val);
> +	else
> +		native_wrmsrq(msr, val);
> +}
> +
> +static __always_inline int write_msr_safe(u32 msr, u64 val)
> +{
> +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> +		return xen_write_msr_safe(msr, val);
> +
> +	return native_write_msr_safe(msr, val);
> +}
> +
> +static __always_inline u64 rdpmc(int counter)
> +{
> +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> +		return xen_read_pmc(counter);
> +
> +	return native_read_pmc(counter);
> +}

Egads, didn't we just construct giant ALTERNATIVE()s for the native_
things? Why wrap that in a cpu_feature_enabled() instead of just adding
one more case to the ALTERNATIVE() ?


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 08:55:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 08:55:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134091.1472103 (Exim 4.92)
	(envelope-from )
	id 1v3W8x-0007OL-DM; Tue, 30 Sep 2025 08:55:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134091.1472103; Tue, 30 Sep 2025 08: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 1v3W8x-0007OE-Ad; Tue, 30 Sep 2025 08:55:31 +0000
Received: by outflank-mailman (input) for mailman id 1134091;
 Tue, 30 Sep 2025 08:55:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1v3W8v-0007O8-UN
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 08:55:30 +0000
Received: from PH8PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170120001.outbound.protection.outlook.com
 [2a01:111:f403:c107::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34d5486f-9ddb-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 10:55:27 +0200 (CEST)
Received: from CH0P221CA0044.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::27)
 by DS4PR12MB9770.namprd12.prod.outlook.com (2603:10b6:8:29d::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Tue, 30 Sep
 2025 08:55:21 +0000
Received: from CH2PEPF00000148.namprd02.prod.outlook.com
 (2603:10b6:610:11d:cafe::d6) by CH0P221CA0044.outlook.office365.com
 (2603:10b6:610:11d::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.17 via Frontend Transport; Tue,
 30 Sep 2025 08:55:21 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Tue, 30 Sep 2025 08:55:20 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 30 Sep
 2025 01:55:19 -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: 34d5486f-9ddb-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=p9SuBl/PWld8ImCc9X3apqkYG6YAVEVkz1MD3mP1wFFnmMb4N26UYtIRk2RpzYTe49vH7xSVGw3BacKG8gB3DphnpktM2D+i191glt2OsSJLrc/SLQ3F+IRBhy98k4jIfkJR2rKeLwotdShboeHQEGR9W7tThG/GhMyxrSvyrITfzTGByMw8wubFGn+m6zYbTBjJPBSuDl/MtKx1c+6zYc0a2uLLXwJd4u1Ejer3eDrOvT32ly+WDiRQtAkg0KwNfDvERWXRBHP15eflFH0UMCKKhzGtre/VL46n7cQStEH4Vh9vb8XZ7cdzQrpdu5XWrJbErjQc+HRVEie8+VxjEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bAx8haWI7p1pYSrwBHbKjbUmVBh/DmnbTbeE0nc1dSY=;
 b=HfgIISIXlcdm+09dEKIq59XuSzrpwNsdsSWRCl228SgCiuIXr3j5QUXy0SNYckHkKsXZ5RIZA6LxFJLYoJcPFceAkE2W8126SCyDXJ0ii/yd9N0KUBFzGElvcRLzlclqtQmTA55hNKnX5j9NOV4DYX7+OfCVTf9piqUDIdI31445HO0V6W+kbe2gF8WBxoQwZqdr6DquqaaVbBAPKwdI4vlJvJGRZqHIIWvo4aM7CFm3CY+HEqD18bYN1PC6v4ADaFmr+1cATfxOKWDdjc8IVQ2c+dDq7uFKoAQnYEemiXrMkI8AXMtLcaGiSQ5dbACkYN3MQ9l+tJAV3aj8HbOR8w==
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=bAx8haWI7p1pYSrwBHbKjbUmVBh/DmnbTbeE0nc1dSY=;
 b=Vu+HKyMHHhXY5yg14w1Q2PIUMxiNjSswqCH+kwTj6VkaTrol6Fp4u26khB2XY6TDpiz3TLr9BG8kIABkKmpNSg9ieGOwLbN2R0P+FVM48VAdG2POWtRkv7FBVCaqKxngdKQGWQzTOQbtNInXc9uAy+64BWj0MkJdd+lGGUS24+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=satlexmb07.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	
Subject: [XTF PATCH] x86: Remove Xen as a hard requirement to run XTF.
Date: Tue, 30 Sep 2025 10:54:06 +0200
Message-ID: <20250930085412.1643-1-alejandro.garciavallejo@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000148:EE_|DS4PR12MB9770:EE_
X-MS-Office365-Filtering-Correlation-Id: 738a2211-d07f-43bd-5ea1-08ddffff1621
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?VfeEe/7pK6iVZQuspNDQwxmtPufGEEM8vDe20oSkSKl0PVyrdB4qJ7cXLWM3?=
 =?us-ascii?Q?5xfQe6hKSOk7Eiy4vGbcUxHrZZda4Lnfd8sm+qS0KcF5FlfuNrO9Ev7gG170?=
 =?us-ascii?Q?bB4nMoPihbuGQ+2T02N9AoP+nO+DRSVKZVt6+gSAA4GCZo937w9ueHT7roVI?=
 =?us-ascii?Q?Oljnrr0Ra1MmUmlTDIWbs9IYF5ps70ItR2Cuc3y2SxIdMQ7h5gFCo1c/yIcJ?=
 =?us-ascii?Q?yvowrrIk4atrUFx+p7y0PK7/0M+mZQgNzlT3ti28PgiA9AZt1jv3Ag2+AYpT?=
 =?us-ascii?Q?XQ86/kM3Z7sKVJgvn5AtJrDenubnxRZVYc96NeU19Mf1gb+atdq15oxx2x3W?=
 =?us-ascii?Q?d7bLqiwLhkttuFx2bKmCiRotRBOg1UqKi0f9LP5RUfRXxDhP1HBJrFiq7QNA?=
 =?us-ascii?Q?dkOYIuq50GbIJTD9lSQuMBlNiaEkoQxXmg03vANHw5Fi4T3kAqVOkSmsZ+GQ?=
 =?us-ascii?Q?PaEmnHsGFBG0VJG+71/3xpOFFAdr9R/VF9+wCFw8rUWGfqRRITKRolceQCPt?=
 =?us-ascii?Q?+nLhf7eDKt/YAP1dDUmYgx5YCp+F5wjXZ9tfvtpRpOtW6Htgo4VTYNqvytPt?=
 =?us-ascii?Q?WG0j+K0dbsWOTgZVtEPB742jxtT8g4AFv8r4+Po5WeQVjFQRaS4Obh3LZO8C?=
 =?us-ascii?Q?sICdFgiE7Flhd2al00wpXINQ4h+13leRCFwwL11Xm5tXQsCAlvU6VXOZsXZM?=
 =?us-ascii?Q?72qdlle6jNTazMfTvx1pli2CHQiWlT322UoCUcgSnqnmUkyWf9Wr0gzwZZ/a?=
 =?us-ascii?Q?DUgr0vbik0Uv6XH0Jq/Lp0pkRThMyxkcH3Vv1uA5dvjXRz0QQfPa+AtbcqPF?=
 =?us-ascii?Q?m9Z4a/etars/3N2xmet7b8lzjXTIayIFsR+Wru/+GtpJQL9gFFzlrMpgpCCy?=
 =?us-ascii?Q?FIUmqi3wVXQRYaUqYATho+CslmQs/N8QGYrLK/OdtS+kwQ7L+SACflB/pqIt?=
 =?us-ascii?Q?8tnFtN/ivFxupluyy01R5jsugN1dsrFXpOHzYVHYKVQ8RMs2fqANUMBD6/oW?=
 =?us-ascii?Q?WeWkHsQ5dcjuxbzuaiXkZ7LtjiHCV6M5tASZQsmkB0ZZCOZBsvUk30NdEeI5?=
 =?us-ascii?Q?zzhD7GXbS8/aaGavyvaRoMGYKrO2te7V41Xpnr2V3snYv+pRh+J1xXhhHDXy?=
 =?us-ascii?Q?KTmgK8aozqbdDdlyniVapqdol5eDNFSyiqnoSa4/ZRaJUdrl7ZrPypu56tyK?=
 =?us-ascii?Q?zJIQEm+vVJaWB0vK30CuSg2iQ0QYCIM40hEdjkfs/5ZyriidFzbJnrUTcU+A?=
 =?us-ascii?Q?2Y2QIhV7oj+uKV5pdqSC3SgDuTNh1oefSbwnJovRE/PRcclRlRk79FFEdFWk?=
 =?us-ascii?Q?gF9BxvwwpgnNPQ9eAs4ER/SZs6plz7n57V1pA5usVyY+l3By5mfUQ226k2AT?=
 =?us-ascii?Q?9399H/SkodvFlKsM8hhJgnUueiCAhyLqqhL8l8zUgyZg+oNj+Itwc0aoSEKO?=
 =?us-ascii?Q?TcynkTX0dtc9VOdJUD7h225EEjl+imiqSsOP7ElQyvwiAnsUpctqrumYuYLy?=
 =?us-ascii?Q?EjoovKT1W5XwbQ5n6NXawVzZ2KeA/TwBts3b8mghrdXMEdi84u2YGeGvV0ks?=
 =?us-ascii?Q?gJNIM92O/NGE+m/pk6g=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 30 Sep 2025 08:55:20.8983
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 738a2211-d07f-43bd-5ea1-08ddffff1621
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000148.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9770

If Xen isn't detected on CPUID, then:

 * Skip setting up Xenbus/PV-console/shared_info/hypercalls/qemu-debug.
 * Register COM1 as an output callback.

This patch enables running XTF on QEMU-TCG/KVM out of the box. And a
minor tweaks to set up baud rate make it work on real hardware too.

Signed-off-by: Alejandro Vallejo 
---
I tested PV and HVM still run fine under Xen, and I did account for
viridian-enlightened guests, though I didn't test them.

---
 arch/x86/setup.c | 68 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 55 insertions(+), 13 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 2ac212e..6172c7e 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -31,6 +31,8 @@ const char environment_description[] = ENVIRONMENT_DESCRIPTION;
 
 shared_info_t shared_info __page_aligned_bss;
 
+static bool has_xen_hypervisor;
+
 static void collect_cpuid(cpuid_count_fn_t cpuid_fn)
 {
     unsigned int tmp, eax, ebx, ecx, edx, addr = 0;
@@ -243,11 +245,19 @@ static void map_shared_info(void)
         panic("Failed to map shared_info: %d\n", rc);
 }
 
+static void pio_write(uint16_t port, const char *buf, size_t len)
+{
+    asm volatile("rep; outsb" : "+S" (buf), "+c" (len) : "d" (port));
+}
+
 static void qemu_console_write(const char *buf, size_t len)
 {
-    asm volatile("rep outsb"
-                 : "+S" (buf), "+c" (len)
-                 : "d" (0x12));
+    pio_write(0x12, buf, len);
+}
+
+static void com1_console_write(const char *buf, size_t len)
+{
+    pio_write(0x3f8, buf, len);
 }
 
 static void xen_console_write(const char *buf, size_t len)
@@ -255,12 +265,41 @@ static void xen_console_write(const char *buf, size_t len)
     hypercall_console_write(buf, len);
 }
 
+static bool detect_xen_runtime(void)
+{
+    uint32_t eax, ebx, ecx, edx;
+
+    /* PV tests always run under Xen */
+    if ( IS_DEFINED(CONFIG_PV) )
+        return true;
+
+    /* HVM tests may additionally run on non-Xen hypervisors or baremetal */
+    cpuid_count(0x40000000, 0, &eax, &ebx, &ecx, &edx);
+    if (  ebx == XEN_CPUID_SIGNATURE_EBX &&
+          ecx == XEN_CPUID_SIGNATURE_ECX &&
+          edx == XEN_CPUID_SIGNATURE_EDX )
+        return true;
+
+    /* Viridian guests have the Xen leaves higher up, so check there too */
+    cpuid_count(0x40000100, 0, &eax, &ebx, &ecx, &edx);
+    return ebx == XEN_CPUID_SIGNATURE_EBX &&
+           ecx == XEN_CPUID_SIGNATURE_ECX &&
+           edx == XEN_CPUID_SIGNATURE_EDX;
+}
+
 void arch_setup(void)
 {
-    if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
-        register_console_callback(qemu_console_write);
+    has_xen_hypervisor = detect_xen_runtime();
+
+    if ( has_xen_hypervisor )
+    {
+        if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
+            register_console_callback(qemu_console_write);
 
-    register_console_callback(xen_console_write);
+        register_console_callback(xen_console_write);
+    }
+    else
+        register_console_callback(com1_console_write);
 
     collect_cpuid(IS_DEFINED(CONFIG_PV) ? pv_cpuid_count : cpuid_count);
 
@@ -268,15 +307,18 @@ void arch_setup(void)
 
     arch_init_traps();
 
-    init_hypercalls();
-
-    if ( !is_initdomain() )
+    if ( has_xen_hypervisor )
     {
-        setup_pv_console();
-        setup_xenbus();
-    }
+        init_hypercalls();
 
-    map_shared_info();
+        if ( !is_initdomain() )
+        {
+            setup_pv_console();
+            setup_xenbus();
+        }
+
+        map_shared_info();
+    }
 }
 
 int arch_get_domid(void)

base-commit: 0cbf4c35b06b2b285fc325b8458132e844c5cf0e
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 09:00:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 09:00:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134106.1472114 (Exim 4.92)
	(envelope-from )
	id 1v3WDx-0001CE-79; Tue, 30 Sep 2025 09:00:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134106.1472114; Tue, 30 Sep 2025 09:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3WDx-0001C2-2A; Tue, 30 Sep 2025 09:00:41 +0000
Received: by outflank-mailman (input) for mailman id 1134106;
 Tue, 30 Sep 2025 09:00: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 1v3WDw-0001Bu-1p
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 09:00:40 +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 eeacc2c9-9ddb-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 11:00:38 +0200 (CEST)
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com (2603:10a6:150:7d::13)
 by GVXPR03MB8355.eurprd03.prod.outlook.com (2603:10a6:150:6b::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.15; Tue, 30 Sep
 2025 09:00:34 +0000
Received: from GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9]) by GV2PR03MB8678.eurprd03.prod.outlook.com
 ([fe80::4eb:3e7b:1ffa:25f9%5]) with mapi id 15.20.9160.011; Tue, 30 Sep 2025
 09:00: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: eeacc2c9-9ddb-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nicP4ObvVUz/7CHq+HfD7Xe145JxKqFU9h6Xkpi2/ktDuyg+OdnNpzp4UkuIUb1MOH0bRst0S8B/LAnCtT6U0LqWu3hTqfwn4xzMDvUGTQmaAf2Zxyiu1suVtHMx/Nx2GbmIGLfEqxxv6okmoI/Hge3M1ogkz0wh/m/PlXZya1c2T/GP5VW07d5eBqUT1GEobSsymYcXAbWrW9vRaqyedhgrqVNOWLgs9peJ+C4PXB/8QpXoQFwp5ipn1LgnPXqVkQktoxP5+XdH/QRuPWKiNEBMi5ojd32Vqwnatn5VZ7ZVjEFfljWk2ReAd+ThWHrsc6Mx8zF1CigfDMo1om06ww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BFDzkKqY89WZ9WlQEsOA8Ysu8vAKoVMEirhGZphyT70=;
 b=QvitvyUPk7QC5mfcgzEDQKgWai7lYE4Gva5hiKI3Pus1lyaUOBX9qRov1zLRSTqlMp4Gq/yvsb2qfg4RcYNezaLvTxvSqTBXXTEqzmeYrX0jRmRXNj1aS8m3osc/2Yc81WY9MQi/29g6uDWC/GA3yoQ8jvPyfAGejh9315faI92y3GLWyMPCFny69wQB61R6hUVQNdWgltOfxi800fcpxD7bzn+0HPFb3pTM2oIB8JO1VJbXkH3bz77Kim+mD+J9IsGNA8z0r3eOo8UK7QmEMLSpH+m6FfXOq1giBb2+qX6z7dSW2YzFL4XuivkTwwFgwmaQODB/aGzNqHg81jzktA==
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=BFDzkKqY89WZ9WlQEsOA8Ysu8vAKoVMEirhGZphyT70=;
 b=vKQRlfP4cRo0M4oOsBncPc2NddzVqVxyT+1egqH46SY5PctEU2YXZ+leCKAi8/cuZDn1a/6JkZOUspa8OvgoZKsqLyz9j6bORJCQ6MfQc89lNasrjzYMb2rMnCTTX4QW5YnGWS978naXoFWRLGftxLrrlWdANNb7uvcRe9iuBYq4gpgctkpL9E1iEaAXcsDmDWUd6qLKmsrG5BGbsrzjRO0DMy0uXMITfPBChSF1AyD6wbivYuiYN5mSdH5V0ZJLxKk8yO+3N4jZL9LTNWcF5aceI3jhdMCcl+o6VmMCVpUY2/yb2gVxunQho25W0U1X4TmqTTPi17BIzajATWkCDQ==
From: Leonid Komarianskyi 
To: "xen-devel@lists.xenproject.org" 
CC: Leonid Komarianskyi , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Julien Grall 
Subject: [PATCH] xen/arm: gicv3: initialize eSPI unconditionally
Thread-Topic: [PATCH] xen/arm: gicv3: initialize eSPI unconditionally
Thread-Index: AQHcMeiurviqZe6kVka5vaTVVpQMKQ==
Date: Tue, 30 Sep 2025 09:00:33 +0000
Message-ID:
 <70927412079d26973fda7025b99c566e03217aa7.1759222404.git.leonid_komarianskyi@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV2PR03MB8678:EE_|GVXPR03MB8355:EE_
x-ms-office365-filtering-correlation-id: 49b992f3-b3ac-4ae0-5698-08ddffffd099
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?UiejbuSgViRFuMUsrX2h9txIujTS5nSt5aMkrcDjMYhBxiJon7S2Ro5BVN?=
 =?iso-8859-1?Q?RxTRjlTwTFDw5fx2qPpv7feXHreZiNlND3/zRliXrPN25iCTizkb96EI9p?=
 =?iso-8859-1?Q?CTqvsDzhI7TjmFiwRGg+getulvMm25JCzV9S5trUjb9q5duycf891NGgOv?=
 =?iso-8859-1?Q?8ZUvevUJt74enkGe6AMCi/68AhtUvwK9O4N65364bedAgsEb+CgWhz3iEE?=
 =?iso-8859-1?Q?DYBhOkztShDnczYArxylU31sJn5IW32JXSjsJVX7OnXSJNRTry5mXhDIqr?=
 =?iso-8859-1?Q?y55Hh7P5q103M9LNKO4OEM3IXDXDZ20XPseJfT36MLp8lMyM015V4SAfuK?=
 =?iso-8859-1?Q?wIdHxBnmongQYaEpzA9yHRbOv0tzu09z9iQB9ulysghh5oO/xum2jlPzWt?=
 =?iso-8859-1?Q?OJq4fkCp/9w895Ece6843qThsXeeOf8yIYWdvksSR/O/iPo3yIoR+RwuQD?=
 =?iso-8859-1?Q?eESkpTzQznizVR4HF+pgvWUWhYBiM5kzYwVPNMA1OJivPSJ3V8g9m66JqS?=
 =?iso-8859-1?Q?Scc4s+B5Ay9TyoHs0BnN7KOGbJt39zUznNIXCUA3aR+utAGNanQFkYFxTZ?=
 =?iso-8859-1?Q?4QNHQ5a7v/9gjDVjKbFVzyDImad4XfDhwMJK62ZOGFmMWNfzlmi+V3ZwEo?=
 =?iso-8859-1?Q?TiFEM3hPrM7+4wLZGfzFLpEZtpasUdh6U60nL5k0S16bFxg6bwV8iBrntG?=
 =?iso-8859-1?Q?SPL/cvmsyPXFnvVPtmTvchMPD6E9bEF9wf3jSVD01J3WFIHX/wwkS7ZsSX?=
 =?iso-8859-1?Q?MjQ01kf0UQY7aPMu+k8OYL8D+slW2GWN+TEIzOBSUVhwOaa9kSWy4VCXlQ?=
 =?iso-8859-1?Q?033i2C/bIAtHkjaSA+jQ7WnHsd4nSKbJnUQPkRStVi022IqqbFmHoFAfbk?=
 =?iso-8859-1?Q?SRO1ZDFV9eCdX9BKGwhIO8GXB+3gXC/eijXp2/3tzGqXWeriwDtjXS+OhN?=
 =?iso-8859-1?Q?aFEn85cNr5q2Fdp47bFXDR9inQOSKLeY8QMUQA33A93EmqrlLL4ugtPsEd?=
 =?iso-8859-1?Q?iKDjiFdzwK45PhcRxxgSO52Jbli4I8rB05vEkn4nAC/j/n6wiyxXH8muRy?=
 =?iso-8859-1?Q?0eFhv4KxxI7BjkLk9rwmpb65tn2yWunNCP1iTrqjp60hLtD+2lI7vk/9K6?=
 =?iso-8859-1?Q?/vi9SsvYNIdhnfqLiIs6qLLHrC6ALAv0w4lV4xPEospHUhneMU6SNKjpfH?=
 =?iso-8859-1?Q?mMjm7rr9mBtD/sGVu4qDj7IT+guvmwdM9Qrl8mHvXEpmUU5N+EQHY+S/6f?=
 =?iso-8859-1?Q?Y2EPj3V6itqc/X3k5gH8AOz3rofov2npRRkjUWI8ekwrhADdimwoFqqSmx?=
 =?iso-8859-1?Q?EJ7PWn95VM5N9L5+cVCGj1P3pGs6NFJ33KXGv4ZMEDhs3QflwV+9qI6Q7s?=
 =?iso-8859-1?Q?9Z2MpDrDEEwm4eeN4HIPHeu63xq0w+nP7SMJ4iN6eVzRvxWPFkehHhx5pk?=
 =?iso-8859-1?Q?ocKWGdizye3782lz9YTFfUNjK/dSV1PwbDXrechh3F1Vnyf11XZvmImgJ/?=
 =?iso-8859-1?Q?/ANyehHI7HcGj8veBNwP3iiNgHY4gl6YeSC5zO2ko0tu+7tNEjZe2GpMJ1?=
 =?iso-8859-1?Q?NKCOenRflXMWWpjflU9IG10xOzoa?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV2PR03MB8678.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qH4B+q9bORXJPfcqiAjsRiwH/xQ552HMeDMk2lpAkd9pu4G2R5SEsnCg9B?=
 =?iso-8859-1?Q?+pyx3regW9LimFNPQq31MlzOc56508os75r9XwgSCXqNXLXQ/94eshwtKE?=
 =?iso-8859-1?Q?/ODPRsajAzc4F1oJWM9GPj9YjwwwzSAYjvy3F7JiRHFNqa08J6m/9z3Eky?=
 =?iso-8859-1?Q?FP/YoNAMG/04XU28EVKrpGU1GOVYMl2u5BaNIwBQ5m4Iv443ydVP49tgox?=
 =?iso-8859-1?Q?bT4ypH+qWVzYQNTTxf8Y+lB4Eq5sKicQ08XssOt0yBvQSFwRRwXIJXA7wf?=
 =?iso-8859-1?Q?hiPpeyF9xjPNkYfvDfpEHGDb1vUPUoogdWMnMTKmg2u6IkJ0giiG202Y63?=
 =?iso-8859-1?Q?Nl/ox4EPz+tqImaGaFf+ISkdTh9xOkAQ/AH4oBOeXXE60uMxWnI7h4Tb0u?=
 =?iso-8859-1?Q?UFB02nXetVBh8s6iOWDF1l4FPFHFY/zkjyOzYFVEr02UuUwrPB6btDJ/uo?=
 =?iso-8859-1?Q?YBSBkywf9fXTILy60aU6L3KQjt0MbBHjF/9yiB6nJ+hVLZNBRDoBZ71oBp?=
 =?iso-8859-1?Q?XdtdkV7NoAfGmoaWAy8i1O35FEAT2NK1XjtquveRl0GfYbaOHHx0P7F+Eu?=
 =?iso-8859-1?Q?qVdDYSx6+/h8Axa7srofG6r13gd+S99vpRyndLUoXFoR/ceNkeEr17ypS6?=
 =?iso-8859-1?Q?6lCssLKcdG2ylbDEHhcPjAzlcfX2Hq7MGMR6SyL2FR2CRftD/8hVuKZGdv?=
 =?iso-8859-1?Q?JD/q0u8Qxti0Zp+1QkyfSAwmEEGRtdVZ0haeJXRNnJ4ihTmPe7EAEAM3Uk?=
 =?iso-8859-1?Q?YZvF0KfmLGLryQs4L38c8p5CdY9QpqJGOFaaPj6avXPNpG/oE1g5Rg4qB0?=
 =?iso-8859-1?Q?6QzJNsR6NuU1ceBLDJMseQV1cylNjw7qRYYg6V5/Ygx4JOJp69aT9Uf3bZ?=
 =?iso-8859-1?Q?3dQH4EJnBrdAPFBxr62eg3jwp69aSPT0LQyCegrywss1kZhySnSZKax33c?=
 =?iso-8859-1?Q?+fF+LIWJhxadzIGmdzePDAj/mCgHFrkv9WHCoaZnE7nitgUg/+65dJey2X?=
 =?iso-8859-1?Q?4P8O0Y0WGeCtR8UFohWbBGYRR2TA7lfXXq6NJzhSdI1JYBHEM4vv7ZLGEk?=
 =?iso-8859-1?Q?n+xV0UErxNKPPYVnbObUk8LE+5nlzfOFi7H9yKLZ6OgAQGuOUmJ6K3WlgK?=
 =?iso-8859-1?Q?Fm5rDa7TQgbANOdr/C5APIyLklQXQ046drK6w2Eh3gsFSQmx/jezPLf9Tc?=
 =?iso-8859-1?Q?p+2ywd4WMqaIAw7f1pnNmzIfiTeUboG5UAhb0+C1IjqdzPsn2pDODCK4nF?=
 =?iso-8859-1?Q?b4T6VzT/j5gH1w/+2wiet4AiFKefBmt6yFHmDva76FhYzQ0sIydcg+AkS/?=
 =?iso-8859-1?Q?k0cb1S4MzNca8IjtPTTpIBDfjuTCJJY0bAmp5NPEtxKvicycJzHi50q0Hv?=
 =?iso-8859-1?Q?CPY6ywfpMYFWsJDlAOcIIvir1Bo4JMPUY0SwcewCfrBvg5Mhq1GoXfW+2H?=
 =?iso-8859-1?Q?OKNiLFcPSwNS/fnWgGH/CgpqmSd4xnH3wrunloGTMmSNCooL/4cXLgSCk8?=
 =?iso-8859-1?Q?xDd3AjpzaytHskCA+04qJPes1QgnmDuxi7R/D/j9EpEHutNURMRBWTm7KX?=
 =?iso-8859-1?Q?pTN+9Y5lfU4fWpe6DSqy8lfh2RmRZslw0KFB1rU9NJpNg31GfPiMEQ953/?=
 =?iso-8859-1?Q?gpqzWKlWSRYBbr+2kAhnTSXQ9iwyKHEqi8Ersz0Ac6oSpETx9EH8D7sS1a?=
 =?iso-8859-1?Q?Kux7JbgZwO4nz5tbh1g=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: GV2PR03MB8678.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 49b992f3-b3ac-4ae0-5698-08ddffffd099
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2025 09:00:33.7617
 (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: RN0f5z+CWkk8pFENtQH6Vo0EsF2OJsKv1zIuH/yZESK8b5tUAfmaTKR2uQwiIB6tzgElUDEJaHI3T+3ERQd/e0XAbK86ksGs6Mb9229YOgA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB8355

Since the firmware may initialize eSPIs before Xen, and without
CONFIG_GICV3_ESPI enabled, Xen would not reinitialize them properly
during boot. In such cases, once the GIC is re-enabled in Xen,
interrupts may be received that cannot be handled.

To ensure proper operation on hardware with eSPI feature, even when the eSP=
I
config is disabled, gicv3_dist_espi_common_init() should be invoked
regardless of whether CONFIG_GICV3_ESPI is enabled or not. This will not
affect hardware without eSPI support, as the function checks if the
hardware supports eSPIs by reading the GICD_TYPER.ESPI field (using
GICD_TYPER_ESPIS_NUM macro), which indicates whether the extended SPI
range is supported. If the hardware does not support eSPI, the function
will not perform any actions.

There are no functional changes for setups where CONFIG_GICV3_ESPI=3Dy.

Signed-off-by: Leonid Komarianskyi 
Suggested-by: Julien Grall 

---
This is a follow-up patch related to the discussion:
https://lore.kernel.org/xen-devel/820704d0-4047-4f02-a058-01daba2765f1@xen.=
org/

Since the idea for the patch was proposed by Julien, I added
Suggested-by, if Julien does not mind.
---
 xen/arch/arm/gic-v3.c                  | 32 ++++++++++++++------------
 xen/arch/arm/include/asm/gic_v3_defs.h |  2 --
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index bc07f97c16..19457bff76 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -699,17 +699,32 @@ unsigned int gic_number_espis(void)
     return gic_hw_ops->info->nr_espi;
 }
=20
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity)
+{
+    unsigned int i;
+
+    for ( i =3D 0; i < gicv3_info.nr_espi; i++ )
+        writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * 8)=
;
+}
+#else
+
+static void __init gicv3_dist_espi_init_aff(uint64_t affinity) { }
+#endif
+
 static void __init gicv3_dist_espi_common_init(uint32_t type)
 {
     unsigned int espi_nr, i;
=20
     espi_nr =3D min(1024U, GICD_TYPER_ESPIS_NUM(type));
+#ifdef CONFIG_GICV3_ESPI
     gicv3_info.nr_espi =3D espi_nr;
+#endif
     /* The GIC HW doesn't support eSPI, so we can leave from here */
-    if ( gicv3_info.nr_espi =3D=3D 0 )
+    if ( espi_nr =3D=3D 0 )
         return;
=20
-    printk("GICv3: %u eSPI lines\n", gicv3_info.nr_espi);
+    if ( IS_ENABLED(CONFIG_GICV3_ESPI) )
+        printk("GICv3: %u eSPI lines\n", espi_nr);
=20
     /* The configuration for eSPIs is similar to that for regular SPIs */
     for ( i =3D 0; i < espi_nr; i +=3D 16 )
@@ -729,19 +744,6 @@ static void __init gicv3_dist_espi_common_init(uint32_=
t type)
         writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + (i / 32) * =
4);
 }
=20
-static void __init gicv3_dist_espi_init_aff(uint64_t affinity)
-{
-    unsigned int i;
-
-    for ( i =3D 0; i < gicv3_info.nr_espi; i++ )
-        writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * 8)=
;
-}
-#else
-static void __init gicv3_dist_espi_common_init(uint32_t type) { }
-
-static void __init gicv3_dist_espi_init_aff(uint64_t affinity) { }
-#endif
-
 static void __init gicv3_dist_init(void)
 {
     uint32_t type;
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/=
asm/gic_v3_defs.h
index c373b94d19..4b90627df6 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -63,7 +63,6 @@
 #define GICD_IROUTERnE               (0x8000)
 #define GICD_IROUTERnEN              (0x9FFC)
=20
-#ifdef CONFIG_GICV3_ESPI
 #define GICD_TYPER_ESPI_SHIFT        8
 #define GICD_TYPER_ESPI_RANGE_SHIFT  27
 #define GICD_TYPER_ESPI_RANGE_MASK   (0x1F)
@@ -73,7 +72,6 @@
 #define GICD_TYPER_ESPIS_NUM(typer)    \
         (((typer) & GICD_TYPER_ESPI) ? \
         GICD_TYPER_ESPI_RANGE((typer) >> GICD_TYPER_ESPI_RANGE_SHIFT) : 0)
-#endif
=20
 /* Common between GICD_PIDR2 and GICR_PIDR2 */
 #define GIC_PIDR2_ARCH_MASK         (0xf0)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 09:02:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 09:02:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134117.1472124 (Exim 4.92)
	(envelope-from )
	id 1v3WG9-0001kW-IM; Tue, 30 Sep 2025 09:02:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134117.1472124; Tue, 30 Sep 2025 09: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 1v3WG9-0001kP-FZ; Tue, 30 Sep 2025 09:02:57 +0000
Received: by outflank-mailman (input) for mailman id 1134117;
 Tue, 30 Sep 2025 09:02: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 1v3WG8-0001kJ-1W
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 09:02:56 +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 3fc5ca55-9ddc-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 11:02:53 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-61cc281171cso11645291a12.0
 for ; Tue, 30 Sep 2025 02:02:53 -0700 (PDT)
Received: from ?IPV6:2003:e5:873f:400:7b4f:e512:a417:5a86?
 (p200300e5873f04007b4fe512a4175a86.dip0.t-ipconnect.de.
 [2003:e5:873f:400:7b4f:e512:a417:5a86])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b3c40d9ced1sm557968466b.80.2025.09.30.02.02.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 02:02: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: 3fc5ca55-9ddc-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1759222973; x=1759827773; 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=LtMOHW+53F0W8gofi/abbzsPPcLlqTFKatap2a1mWHc=;
        b=d+Mp5vPuyIM2NRTC5R3tCemFnPCNzpTb3JLdPGgHdrZMD1K6wzGyg+8JMa6mq0hevA
         JCf2o7XfT22kxBj1aSL6KZ0ONcJzDC62kUIEmSLqlEDNu9sU0UWq8PL2ijreioKzLFif
         DtWXkRN2h7CGKQaLDoYKFgZ+tYF3XTRZeD4yoNyoAlazvoPtL9jGaNrvasg7XnYjqC9d
         MPiKiJ+6Gv2oHDBzWDc7wXTc0Ve1WCSQjrXe3p5UL2XQ6ekOPDNOCOrxLE3Hs1mof9EW
         6zwbezGL3pQtXVD/I9xxkGrTvT15cr3ujgWs1fAwfEeqOK+HXnfHUToeqrpnnFtXpgvC
         J7rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759222973; x=1759827773;
        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=LtMOHW+53F0W8gofi/abbzsPPcLlqTFKatap2a1mWHc=;
        b=f8wVYY/zHOJOFrga3GJU+1VbICDN4BRfV/dfIoGLhqOO7K5mLBo21VwdMW6QIcwfCQ
         P8hUTeJzZkOLjKz6JG9FgCm4zxIC3ocSNr+1p9vjgQhZOu96UmZYQjPCwNcJspOoKERV
         joX6DaMvruEFg/k1fxqVtEVG+tr4P/PNLyvEKMuScTcnudi9zSoZoqkCS4p4wU+rQOY7
         /55KxpZZy8iCCY0DrlPJL2wrGa1cLlRHGxvbol3nvendl/9RYiAtsB+xZKAZmAzsrgRw
         WvMHkjQoa441ItvV+ZqpoCvEleKb32BNsF9DfQynE/OoNhR0Jbckf2GdK2VUjety7QWj
         LFlw==
X-Forwarded-Encrypted: i=1; AJvYcCXc7Sf6TFzHfBiB+5+qJJzfT+ynBYX6q6s6GcaqdfJberBycBSbInRvKreCgd47emziCBRCrI5B8Cs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpN9NdLxSOeanoX5/Qn1Rv5K9z09AreCcJvakM0B69+842jMZj
	LT4wSOA5OQralEPXvRgngwvZ2XSg2zBuSqqkhM9aXnfz1o3K1jL2Seq1Bij8vuPqyNc=
X-Gm-Gg: ASbGncv0vtL5amEUa1hvd7guifoyucF3t3SaLwQKcmNyyvriMkhRJURSg8sv85Vy55H
	dNbV06yjmfjpuAU9zyps6lSnbuzwo8BpW1pMS/tWREC95WZxJ3ww/zo9/lAkLMFjyqKyOipsh6D
	6fequ+7hQOAbxKA1xMMfjr2YxmHre3iOuUqkXjduWy6dyPoeB4S07QftOpBjnusU2REKhecTtUk
	6sTLCD9YAa3zzRaaK6F0v2tGPQxta7dlcpu81hJuXMG0jJS8WGsOpxT2jlijWqJ1ekSuBYrUtyS
	58dR5ZVCjT7l5T5OXLmioDzduPUJ6frNX6J0eVftU5Skm+2YBOYMyouK2DiEd1AC7QHn015Kr8E
	dO7lzuaLYjJD5zgzcoIs3+QNblEyFJW6oEIkTLNgx9P4QxJyhfpkJR8lsimsZsaG4kmiQM+hfeZ
	qaLZU6fQ7/LN1eH8QaQ8Yjr+u4JuoUu2+nODFeihMxWFpS6Qo8+hmRfMjJZ2rxC2xpiYk4
X-Google-Smtp-Source: AGHT+IEhBcJxRX85g9uAkfqQnAOM8ZX84eGYiI6CL0xWr5Dy3J8XRMl2kqQOdaPWOVnka4EPHeMGbA==
X-Received: by 2002:a17:907:d7c1:b0:b3a:ecc1:7774 with SMTP id a640c23a62f3a-b3aecc183bamr1092767766b.53.1759222973125;
        Tue, 30 Sep 2025 02:02:53 -0700 (PDT)
Message-ID: <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
Date: Tue, 30 Sep 2025 11:02:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, xin@zytor.com,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" , Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.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: <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------EDjdRPJRmmUK5bP0S1o6gxj8"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------EDjdRPJRmmUK5bP0S1o6gxj8
Content-Type: multipart/mixed; boundary="------------SnAjFPsvrro8lhJGEyYEiJll";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, xin@zytor.com,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" , Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
Message-ID: <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
In-Reply-To: <20250930083827.GI3245006@noisy.programming.kicks-ass.net>

--------------SnAjFPsvrro8lhJGEyYEiJll
Content-Type: multipart/mixed; boundary="------------dMBscmw5LmvOz0wWFtddEw66"

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

T24gMzAuMDkuMjUgMTA6MzgsIFBldGVyIFppamxzdHJhIHdyb3RlOg0KPiBPbiBUdWUsIFNl
cCAzMCwgMjAyNSBhdCAwOTowMzo1NUFNICswMjAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K
PiANCj4+ICtzdGF0aWMgX19hbHdheXNfaW5saW5lIHU2NCByZWFkX21zcih1MzIgbXNyKQ0K
Pj4gK3sNCj4+ICsJaWYgKGNwdV9mZWF0dXJlX2VuYWJsZWQoWDg2X0ZFQVRVUkVfWEVOUFYp
KQ0KPj4gKwkJcmV0dXJuIHhlbl9yZWFkX21zcihtc3IpOw0KPj4gKw0KPj4gKwlyZXR1cm4g
bmF0aXZlX3JkbXNycShtc3IpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgX19hbHdheXNf
aW5saW5lIGludCByZWFkX21zcl9zYWZlKHUzMiBtc3IsIHU2NCAqcCkNCj4+ICt7DQo+PiAr
CWlmIChjcHVfZmVhdHVyZV9lbmFibGVkKFg4Nl9GRUFUVVJFX1hFTlBWKSkNCj4+ICsJCXJl
dHVybiB4ZW5fcmVhZF9tc3Jfc2FmZShtc3IsIHApOw0KPj4gKw0KPj4gKwlyZXR1cm4gbmF0
aXZlX3JlYWRfbXNyX3NhZmUobXNyLCBwKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIF9f
YWx3YXlzX2lubGluZSB2b2lkIHdyaXRlX21zcih1MzIgbXNyLCB1NjQgdmFsKQ0KPj4gK3sN
Cj4+ICsJaWYgKGNwdV9mZWF0dXJlX2VuYWJsZWQoWDg2X0ZFQVRVUkVfWEVOUFYpKQ0KPj4g
KwkJeGVuX3dyaXRlX21zcihtc3IsIHZhbCk7DQo+PiArCWVsc2UNCj4+ICsJCW5hdGl2ZV93
cm1zcnEobXNyLCB2YWwpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgX19hbHdheXNfaW5s
aW5lIGludCB3cml0ZV9tc3Jfc2FmZSh1MzIgbXNyLCB1NjQgdmFsKQ0KPj4gK3sNCj4+ICsJ
aWYgKGNwdV9mZWF0dXJlX2VuYWJsZWQoWDg2X0ZFQVRVUkVfWEVOUFYpKQ0KPj4gKwkJcmV0
dXJuIHhlbl93cml0ZV9tc3Jfc2FmZShtc3IsIHZhbCk7DQo+PiArDQo+PiArCXJldHVybiBu
YXRpdmVfd3JpdGVfbXNyX3NhZmUobXNyLCB2YWwpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0
aWMgX19hbHdheXNfaW5saW5lIHU2NCByZHBtYyhpbnQgY291bnRlcikNCj4+ICt7DQo+PiAr
CWlmIChjcHVfZmVhdHVyZV9lbmFibGVkKFg4Nl9GRUFUVVJFX1hFTlBWKSkNCj4+ICsJCXJl
dHVybiB4ZW5fcmVhZF9wbWMoY291bnRlcik7DQo+PiArDQo+PiArCXJldHVybiBuYXRpdmVf
cmVhZF9wbWMoY291bnRlcik7DQo+PiArfQ0KPiANCj4gRWdhZHMsIGRpZG4ndCB3ZSBqdXN0
IGNvbnN0cnVjdCBnaWFudCBBTFRFUk5BVElWRSgpcyBmb3IgdGhlIG5hdGl2ZV8NCj4gdGhp
bmdzPyBXaHkgd3JhcCB0aGF0IGluIGEgY3B1X2ZlYXR1cmVfZW5hYmxlZCgpIGluc3RlYWQg
b2YganVzdCBhZGRpbmcNCj4gb25lIG1vcmUgY2FzZSB0byB0aGUgQUxURVJOQVRJVkUoKSA/
DQoNClRoZSBwcm9ibGVtIEkgZW5jb3VudGVyZWQgd2l0aCB1c2luZyBwdl9vcHMgd2FzIHRv
IGltcGxlbWVudCB0aGUgKl9zYWZlKCkNCnZhcmlhbnRzLiBUaGVyZSBpcyBubyBzaW1wbGUg
d2F5IHRvIGRvIHRoYXQgdXNpbmcgQUxURVJOQVRJVkVfPG4+KCksIGFzDQppbiB0aGUgWGVu
IFBWIGNhc2UgdGhlIGNhbGwgd2lsbCByZW1haW4sIGFuZCBJIGRpZG4ndCBmaW5kIGEgd2F5
IHRvDQpzcGVjaWZ5IGEgc2FuZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgY2FsbC1zaXRlIGFu
ZCB0aGUgY2FsbGVkIFhlbiBmdW5jdGlvbg0KdG8gcmV0dXJuIHRoZSBlcnJvciBpbmRpY2F0
b3IuIFJlbWVtYmVyIHRoYXQgYXQgdGhlIGNhbGwgc2l0ZSB0aGUgbWFpbg0KaW50ZXJmYWNl
IGlzIHRoZSBvbmUgb2YgdGhlIFJETVNSL1dSTVNSIGluc3RydWN0aW9ucy4gVGhleSBsYWNr
IGFuIGVycm9yDQppbmRpY2F0b3IuDQoNCkluIFhpbidzIHNlcmllcyB0aGVyZSB3YXMgYSBw
YXRjaCB3cml0dGVuIGluaXRpYWxseSBieSB5b3UgdG8gc29sdmUgc3VjaA0KYSBwcm9ibGVt
IGJ5IGFkZGluZyB0aGUgX0FTTV9FWFRBQkxFX0ZVTkNfUkVXSU5EKCkgZXhjZXB0aW9uIHRh
YmxlIG1ldGhvZC4NCkkgdGhpbmsgdGhpcyBpcyBhIGRlYWQgZW5kLCBhcyBpdCB3aWxsIGJy
ZWFrIHdoZW4gdXNpbmcgYSBzaGFkb3cgc3RhY2suDQoNCkFkZGl0aW9uYWxseSBJIGZvdW5k
IGEgcmF0aGVyIHVnbHkgaGFjayBvbmx5IHRvIGF2b2lkIHJlLWl0ZXJhdGluZyBtb3N0IG9m
DQp0aGUgYmFyZSBtZXRhbCBBTFRFUk5BVElWRSgpIGZvciB0aGUgcGFyYXZpcnQgY2FzZS4g
SXQgaXMgcG9zc2libGUsIGJ1dCB0aGUNCmJhcmUgbWV0YWwgY2FzZSBpcyBnYWluaW5nIG9u
ZSBhZGRpdGlvbmFsIEFMVEVSTkFUSVZFIGxldmVsLCByZXN1bHRpbmcgaW4NCnBhdGNoaW5n
IHRoZSBvcmlnaW5hbCBpbnN0cnVjdGlvbiB3aXRoIGFuIGlkZW50aWNhbCBjb3B5IGZpcnN0
Lg0KDQpBbm90aGVyIGJlbmVmaXQgb2YgbXkgYXBwcm9hY2ggaXMgdGhlIGRyb3BwaW5nIG9m
ICIjaW5jbHVkZSA8YXNtL3BhcmF2aXJ0Lmg+Ig0KZnJvbSBtc3IuaCwgd2hpY2ggaXMgbWFr
aW5nIGxpZmUgYSBsaXR0bGUgYml0IGVhc2llci4NCg0KDQpKdWVyZ2VuDQo=
--------------dMBscmw5LmvOz0wWFtddEw66
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-----

--------------dMBscmw5LmvOz0wWFtddEw66--

--------------SnAjFPsvrro8lhJGEyYEiJll--

--------------EDjdRPJRmmUK5bP0S1o6gxj8
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/Ey8FAmjbnLwFAwAAAAAACgkQsN6d1ii/Ey8j
Ngf/VhebFnmOYuETy4RiRDShiplntQglNhvDrVEDyiRLy20bM8s5hGdcLlc5Ssv2N8wntccp4htO
cF31CpnEhQS88HO7CbdPODQ8YKH1jlN8O00AsgRcnllqRgkpv83VzAGMyqyjHiAhCYsoDdrO3Kfk
kgj30NsD+ftCgYzYmd1MwMQ0k0XcjRQ5mBLspsF3XtSUJKQwrhyP+5y6OBQnMmzWSbHncqrAdpGi
CC9OZfIq3E6H9GbKVkVBul4kSjewsKQGXlpZTaE95Bsq2oKjR4aElYvfPqRqSKhroCdcNjZDRQJp
0jFNZkvzBmshvDti9g0rJCROakm32uq0FwPmlX6PhA==
=CfFP
-----END PGP SIGNATURE-----

--------------EDjdRPJRmmUK5bP0S1o6gxj8--


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 09:15:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 09:15:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134132.1472133 (Exim 4.92)
	(envelope-from )
	id 1v3WSB-0003wa-NL; Tue, 30 Sep 2025 09:15:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134132.1472133; Tue, 30 Sep 2025 09:15: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 1v3WSB-0003wT-Kl; Tue, 30 Sep 2025 09:15:23 +0000
Received: by outflank-mailman (input) for mailman id 1134132;
 Tue, 30 Sep 2025 09: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 1v3WSB-0003wN-9j
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 09:15:23 +0000
Received: from PH8PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170120001.outbound.protection.outlook.com
 [2a01:111:f403:c107::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fcc1a45d-9ddd-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 11:15:21 +0200 (CEST)
Received: from BYAPR06CA0005.namprd06.prod.outlook.com (2603:10b6:a03:d4::18)
 by CH3PR12MB8547.namprd12.prod.outlook.com (2603:10b6:610:164::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 09:15:15 +0000
Received: from SJ5PEPF00000209.namprd05.prod.outlook.com
 (2603:10b6:a03:d4:cafe::c3) by BYAPR06CA0005.outlook.office365.com
 (2603:10b6:a03:d4::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.17 via Frontend Transport; Tue,
 30 Sep 2025 09:15:14 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ5PEPF00000209.mail.protection.outlook.com (10.167.244.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Tue, 30 Sep 2025 09:15:14 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 30 Sep
 2025 02:15:02 -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: fcc1a45d-9ddd-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=T7nLHrrutVTHLScnZ5tBRTP0qfdDUPnunC/uSX2+bN8xXTMw5poLJHmIiKY8igkbAZBOFnmhZ06lWfcQ53CntgQq+H0sr7w0ITBPCBmPbH8fBIbjuNV+Kh0ZX35cXzasl6W0AdEsgfbZRvPGl3erUmiRAaVQbZZBOXHGm3DAKQ5a+MfRUUlpOrcyjTRefMdju/+lFDNSc+NBeKuKFrj7nlC10OF99VBb5kjKQYkM5D/rXWxk7I+/2YgA+nvksQjOJHLEDjSRRY+M7iNtHJEnSjU6d3h0RVOJyieak1uDuliSF0zFbwREjCKR1LaMFKd5f1oeZ+wvVddvAO1WnJk9sg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2AreZ7zKG8bk3F4BWT7SaaEX5dBp9i0cOavKWQdYOCY=;
 b=Sdc7Frjt2CCr2EMyZv58JifYEjbIJZA4dB1HRqUD0364N4AtyxKCUY2rlrMbjvP7OiMN4R5Z0CjYC4kDFA14KamYWE7rMAtu34J+LG8eJNMQ+Lc6n9HvAM6jylTtAgG+Gnj2B1+fJ1AcBYFxczaGMLCfSyeM/N1BMukdxq9VPkZ3LsIKy5U1szzhoJ8u/OBfpYmzFI7oJyMUeA5OlXfEfYBzbp1uHcZ4yN6l7cmrbna2BC1r02Fbv59lyApX/NY0UgQ7pnBqd8oLVbSqmvelQlkj+xk2wnplL2cX7uBfK4Y0Kh6dEeNbl7wggyv17VD3Q9aPai9Nd8KeN957GCJJrQ==
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=2AreZ7zKG8bk3F4BWT7SaaEX5dBp9i0cOavKWQdYOCY=;
 b=pfWXJOz8ci4uWuX5VtQDOeLPjjW9ni7eOOjgv318sj20QVHnHd1T6F1nyZXVSuHHkmER9SpYDL4P4ANxZ63gzUnIpyu+HUtDo5LaxdhAL3UOOBErKEG8Ixh1ZNdC1gnXAT8D0vKSTd8+FBVrDoj0wRjYyn+xwl3AQeYErqfglIA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 30 Sep 2025 11:15:01 +0200
Message-ID: 
CC: Stewart Hildebrand , Jan Beulich
	, Oleksii Kurochko , Xen-devel
	
Subject: Re: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X
 capabilities
From: Alejandro Vallejo 
To: Roger Pau Monne , 
X-Mailer: aerc 0.20.1
References: <20250929084149.70560-1-roger.pau@citrix.com>
In-Reply-To: <20250929084149.70560-1-roger.pau@citrix.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF00000209:EE_|CH3PR12MB8547:EE_
X-MS-Office365-Filtering-Correlation-Id: 21724ccc-0a37-4c5c-9b28-08de0001dd9b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|30052699003|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Ri9idThCdGNsaFZodDdidFpKZ1ZnQkYzeFJQaHgwRGFTeGphYWZCRUFpM2RW?=
 =?utf-8?B?REhVRjFxWVJNNU1TRVg1VmZ1MUpnOTVlaVFYdlM2VWdaTUtkVkc1N3hUVW9q?=
 =?utf-8?B?dWJTbjVGRWxPVWthKyt5aHc2RHhMT2JaT1RIaGJXK0lMUmVyNXFDQStRMlYw?=
 =?utf-8?B?bi9tckNOdkc3QXo2MWhSRWx6SU9hMHZueS96eklDU0hjUnFJMXIzekt5NTJ4?=
 =?utf-8?B?MUp6Ni9IM2JQNkJMK2pMMWZFTFRmSXNKeG9FN1doTFBYSmJTOWhrMHNHTjg2?=
 =?utf-8?B?Zm1GSG1uQXcwbE5QTXVUY2Y1UVBNWEU5UVUrL0c3UDNIazFMRVJRekRabGFG?=
 =?utf-8?B?T2p3Y1ROYmlJbmMxTjdLdE92RGs5cExaNC94am1vSFNtSm9tQ1hYNm1hRktr?=
 =?utf-8?B?dFk2c1VVUUtDTFRidDlXMjdtbVRFL2ZVTndkYXZUOVN4MTN0TlozOXdGMTJw?=
 =?utf-8?B?YUUyTGRlVlRuSWViOFE3bStST0tDK1Q4TmsvZWFJaUxnU2JQSEk1N09EZHBT?=
 =?utf-8?B?SGFJOE9taFhRK20yMk5KQ0ZLQ3AxTXFrS2p1VE43dTRMMWpuMzVzNG5mUXFn?=
 =?utf-8?B?OG4rdlhLeVFidzlqTEhIWloxNVZzTGpOVHdhTDdqNGk4YXpYZlpFOHlBZkRR?=
 =?utf-8?B?MzFSM0RMYUpwbThsdWdabFU0aXUzSUZnZk95WHRMSUtkYWt6bHZCcm01WTlj?=
 =?utf-8?B?STlFMzNDYUp2Y2orY2ZWeERseXBVUkRVeWNoMTFKdzM0YXBQaVBGT2pjVTU0?=
 =?utf-8?B?clBXczJ5YXBZUVZVVXVVSmYwdHB4bjhVdnl1ek8xUTJkNW9JTkp2TTR2N3dr?=
 =?utf-8?B?RFRMK3I2ZHJjMXhZK1lqM1hvN2xQbFptTFY5RVVkb0Z3U1lTUFpZSTZlMGFq?=
 =?utf-8?B?cFozbFpTeEdDaTNWSEFMYkUyeGJpN0VKNmMxc1VFU2xLUEJrdVpkSFI3L0Mx?=
 =?utf-8?B?bXN3emFJMWp3alVPK2hkN1crMVJROVJVcUdtc2tmekFsOW55dzVoNDZxOFJp?=
 =?utf-8?B?K09ITW0zWFcyMStzZDZqRWdkU2hBei80bFFBWnlzNXJJQWNjR0cySG9sL2Fs?=
 =?utf-8?B?T29EYjJsVThhVjhrZ1BtU083YUExRlNaenFsb28rcENkOXBQNG5ybEUwWWhw?=
 =?utf-8?B?QTZ5eHd1OTh0bVN4K2NHMDcyc2Fna3J6eU9TWm4wYk5Ud2ZGUXdoczlZQ09Z?=
 =?utf-8?B?QysrdHVYZDkvOWR0OGJtMmtDU3NKRGNYa0RBTEltWlZWTzQxUmY3RTlZb3Bo?=
 =?utf-8?B?bnFId0RKMGwzR3lrZUtTZStNc20vOGxxVUJmTXFKcmNyekJKQUhpV3JtdUJy?=
 =?utf-8?B?d1hxcFBoOU5lMGtxUmE1RDJRbE82Qkd4YVI1THNMeU9WMjZKMjM4L1ZtWnAx?=
 =?utf-8?B?MlJjT1pnOXV4NXdVczhVMUh3TGZQOUx5a1grVjQ0RUxjYUkzbXpMNG5UMkhG?=
 =?utf-8?B?eEFtOTNaMHQrS2k2TnVDT3BpMjZ6dzBpRzRjb3o3S3htdUx0bWpocWdXaW4v?=
 =?utf-8?B?SXQ0T3NCcTcrWUR4eUl0cnBLc2gvM2tnemtXNStBNnErck5NWVJTd1g2bTJQ?=
 =?utf-8?B?MlJMVGVPYWFyWTBLZnpSMmZMZXEzTUlVaHE5ajlCdDVsd3NKbVo2RXhTNXlu?=
 =?utf-8?B?ZC95YS9IalR1SlJ1S2FjbldXd053VXdhc1V3WEljNWk4WGt3UGttc0pMWnFs?=
 =?utf-8?B?dHRHV3ZnOUpmdjIyWkQ3TENZMkJ4elJWNHNkNVlWUXVINVlmbk5Wb01uZk1q?=
 =?utf-8?B?WUJuL3N3VWhTcHZWV3dlNXhLOHNDL3ZZVTNGc2p2R3JWa3hjN0diUUVJUm9k?=
 =?utf-8?B?UjlqMDlvRHkxZkdockNQNHNIdlJTaXhlZXR2SVpBMTRuWVFuQTF5bUtDWFpl?=
 =?utf-8?B?SlBtYlFMSEdubS9oUEU4ODRxRHNJa1dwYkpSM1E3aHRxTmkvLzZ1ZHFaNnBO?=
 =?utf-8?B?S0xLSFRCdDRzZFNJaExWU0hXelNMS2dkS0lWNmZibTk4c2N2dStMWVM4dnFT?=
 =?utf-8?B?dzcySmw0YWlHTkR0V3BoTVJOUUMzRnhKWGo4d1IxREtiL1IwbXdCLytWYWpS?=
 =?utf-8?B?SjUxOFY2YXNCK09NUm5ITjlFbWV1NkFmMG9BV0ZlQ0IvV0dwNEo2VElFQXhw?=
 =?utf-8?Q?GyKE=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(30052699003)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2025 09:15:14.4771
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 21724ccc-0a37-4c5c-9b28-08de0001dd9b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF00000209.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8547

On Mon Sep 29, 2025 at 10:41 AM CEST, Roger Pau Monne wrote:
> I've had the luck to come across a PCI card that exposes a MSI-X capabili=
ty
> where the BIR of the vector and PBA tables points at a BAR that has 0 siz=
e.
>
> This doesn't play nice with the code in vpci_make_msix_hole(), as it woul=
d
> still use the address of such empty BAR (0) and attempt to crave a hole i=
n
> the p2m.  This leads to errors like the one below being reported by Xen:
>
> d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers=
 MSIX MMIO area
>
> And the device left unable to enable memory decoding due to the failure
> reported by vpci_make_msix_hole().
>
> Introduce checking in init_msix() to ensure the BARs containing the MSI-X
> tables are usable.  This requires checking that the BIR points to a
> non-empty BAR, and the offset and size of the MSI-X tables can fit in the
> target BAR.
>
> This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
> EPYC 9965 processors.  The broken device is:
>
> 22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Cont=
roller [AHCI mode] (rev 93)
>
> There are multiple of those integrated controllers in the system, all
> broken in the same way.
>
> Signed-off-by: Roger Pau Monn=C3=A9 
> ---
> Cc: Stewart Hildebrand 
> Cc: Jan Beulich 
> Cc: Oleksii Kurochko 
>
> While not strictly a bugfix, I consider this a worthy improvement so that
> PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
> capabilities.  Hence I think this change should be considered for inclusi=
on
> into 4.21.  There a risk of regressing on hardware that was already worki=
ng
> with PVH, but given enough testing that should be minimal.
> ---
>  xen/drivers/vpci/msix.c | 50 ++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index 54a5070733aa..8458955d5bbb 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -675,6 +675,51 @@ static int cf_check init_msix(struct pci_dev *pdev)
>      if ( !msix )
>          return -ENOMEM;
> =20
> +    msix->tables[VPCI_MSIX_TABLE] =3D
> +        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
> +    msix->tables[VPCI_MSIX_PBA] =3D
> +        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
> +
> +    /* Check that the provided BAR is valid. */
> +    for ( i =3D 0; i < ARRAY_SIZE(msix->tables); i++ )
> +    {
> +        const char *name =3D (i =3D=3D VPCI_MSIX_TABLE) ? "vector" : "PB=
A";
> +        const struct vpci_bar *bars =3D pdev->vpci->header.bars;
> +        unsigned int bir =3D msix->tables[i] & PCI_MSIX_BIRMASK;
> +        unsigned int type;
> +        unsigned int offset =3D msix->tables[i] & ~PCI_MSIX_BIRMASK;
> +        unsigned int size =3D
> +            (i =3D=3D VPCI_MSIX_TABLE) ? max_entries * PCI_MSIX_ENTRY_SI=
ZE
> +                                   : ROUNDUP(DIV_ROUND_UP(max_entries, 8=
), 8);
> +
> +        if ( bir >=3D ARRAY_SIZE(pdev->vpci->header.bars) )
> +        {
> +            printk(XENLOG_ERR "%pp: MSI-X %s table with out of range BIR=
 %u\n",
> +                   &pdev->sbdf, name, bir);

Would it be worth adding something here such that a device vendor testing t=
heir
hardware under Xen can trivially grep for device bugs?

Something akin to "[Firmware bug]" on Linux, like "[Device bug]" or some su=
ch.

It would also let anyone not very knowledgeable about PCI know that a devic=
e
they own is being unreasonable. Same below in the other XENLOG_ERR messages=
.

> + invalid:
> +            xfree(msix);
> +            return -ENODEV;
> +
> +        }
> +
> +        type =3D bars[bir].type;
> +        if ( type !=3D VPCI_BAR_MEM32 && type !=3D VPCI_BAR_MEM64_LO )
> +        {
> +            printk(XENLOG_ERR
> +                   "%pp: MSI-X %s table at invalid BAR%u with type %u\n"=
,
> +                   &pdev->sbdf, name, bir, type);
> +            goto invalid;
> +        }
> +
> +        if ( (uint64_t)offset + size > bars[bir].size )
> +        {
> +            printk(XENLOG_ERR
> +                   "%pp: MSI-X %s table offset %#x size %#x outside of B=
AR%u size %#lx\n",
> +                   &pdev->sbdf, name, offset, size, bir, bars[bir].size)=
;
> +            goto invalid;
> +        }
> +    }
> +
>      rc =3D vpci_add_register(pdev->vpci, control_read, control_write,
>                             msix_control_reg(msix_offset), 2, msix);
>      if ( rc )
> @@ -686,11 +731,6 @@ static int cf_check init_msix(struct pci_dev *pdev)
>      msix->max_entries =3D max_entries;
>      msix->pdev =3D pdev;
> =20
> -    msix->tables[VPCI_MSIX_TABLE] =3D
> -        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
> -    msix->tables[VPCI_MSIX_PBA] =3D
> -        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
> -
>      for ( i =3D 0; i < max_entries; i++)
>      {
>          msix->entries[i].masked =3D true;



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 09:18:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 09:18:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134144.1472145 (Exim 4.92)
	(envelope-from )
	id 1v3WVO-00051H-5i; Tue, 30 Sep 2025 09:18:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134144.1472145; Tue, 30 Sep 2025 09:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3WVO-00051A-1n; Tue, 30 Sep 2025 09:18:42 +0000
Received: by outflank-mailman (input) for mailman id 1134144;
 Tue, 30 Sep 2025 09:18: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 1v3WVN-00050o-Fd
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 09:18:41 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 726c5a50-9dde-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 11:18:38 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-14-eGh-4caqPFyvt59zP3-dFQ-1; Tue, 30 Sep 2025 05:18:35 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-46e36f9c651so45041005e9.3
 for ; Tue, 30 Sep 2025 02:18:35 -0700 (PDT)
Received: from [192.168.0.7] (ltea-047-064-114-056.pools.arcor-ip.net.
 [47.64.114.56]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-46e2ab6a514sm260322475e9.22.2025.09.30.02.18.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 02:18: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: 726c5a50-9dde-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1759223917;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=d3jiynPnEzxxv2oRAoAk1Ku5mtXrOi1sVDTTsgV+r60=;
	b=a+dyQP0nYTMjk/34CFtYyx990HGPl3Af7YYZrHacBxLB+NrpatnBtbl6vsXw8qndG7sQtx
	QZzIC4ak1s4aSapyyx0+lPffTT7ryKiSchkgdW6ulyG0o+UiUXo/itjgdKas7hCgiU8LWq
	85bK5uucRALykBOJj14ZumsRSuHnRXs=
X-MC-Unique: eGh-4caqPFyvt59zP3-dFQ-1
X-Mimecast-MFC-AGG-ID: eGh-4caqPFyvt59zP3-dFQ_1759223914
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759223914; x=1759828714;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :from:references:cc:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=d3jiynPnEzxxv2oRAoAk1Ku5mtXrOi1sVDTTsgV+r60=;
        b=RSmM/uu6VgFMJD1y7EwzT6DFGMlfpjsNNJqO/XD6FsmnDqQLTm1hVITWCaqy5ztn2M
         99ZlGekyps3LCcvL+blSaUMA7JIUFAVuKRMq304xJrZGwDJYffUzcMvFZiMOxjGsy8hG
         FgnyrqkYTIXL9UqezpMcAi3XBcCajb13Ew8ona5CODU0QJI3thOs9M984zwmcEXQTKSa
         2eq/DbN3uy1mhnSkwODJ3OusOacv8Ov1cKlb0KVEly0N5D8Gt5kiy+OgindPGqA41xot
         icmn/1bzaCcENmGbLlufUiMz0ZkqZesWUEb5TCeeZsC9t5d2mMEZ2+N2CtLNirIRqg+d
         PhEQ==
X-Forwarded-Encrypted: i=1; AJvYcCUkUWWIAUOLZTJJUCS5FpX0FAbz09phT7nMSeGeZR2D7w0xzvtTfYIN+YxnT6N0voPbdq1gtxJqLN4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmaZ7ch1msJvc6mi3gL7ULTP+8aBC1hxHW2INB8KQ+jzHW5wjt
	ZXF3dX4pji8WOC3JtuiLnUftuooEG93b7CZWx1CyPkEtvqDKmDGjS47ifZLvLMeTjOxcHCwWTFt
	UjR2LHcsTuH/byFVVFAYuwvPs21Iack0ELvA8NhqDX3xvuFyseBJlStIwvj+hYiZQfnHe
X-Gm-Gg: ASbGncsvOGL7BqRSO6ym7mwuINpKYvFmI2ZuF9fJjBrJC0zSgXjmWDkpRFHZ/Fy7C5M
	QSppFKdgQB8IK1o2apDMGfPcwdmMtJBsftnUoaP74OtmjVLlY0c6CZmGn//oJUV3tQJuecEvH9U
	/7NUYmX/jlcSWtYMewpO4WIxjsQntUNVH5VE/6MtYkCotITpvA0zENS+vXkIvjnAFVwDOfVLsBf
	3E3gFIEdHOv30EaegL2fmrA8wVYuUCtvzXjsdg02Wre5nq1Nll+uryA6efOiqaFI7fw5U7M1vbg
	+UieQO9u76Ko3OSEwRUag4U8oaVZz8Ybsykq1678yLp4Bzq5kd2IFcdWdFwthz3jBHTsPiTrW6S
	AO3ys5U6AtQ==
X-Received: by 2002:a05:600c:4e52:b0:46e:4499:ba30 with SMTP id 5b1f17b1804b1-46e51fa6a03mr62469345e9.30.1759223913932;
        Tue, 30 Sep 2025 02:18:33 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEHA7zZRePx4N9OF9Phbhrr1b0KhGDD1FpkIOIr+WZAiVdK6e9WSFSf5gyO0we3QGfFVloHyA==
X-Received: by 2002:a05:600c:4e52:b0:46e:4499:ba30 with SMTP id 5b1f17b1804b1-46e51fa6a03mr62468955e9.30.1759223913515;
        Tue, 30 Sep 2025 02:18:33 -0700 (PDT)
Message-ID: <9993b187-7b44-4f9b-801d-fdfa6b309362@redhat.com>
Date: Tue, 30 Sep 2025 11:18:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/18] system/memory: Better describe @plen argument of
 flatview_translate()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell ,
 Peter Xu 
Cc: Marcelo Tosatti ,
 Ilya Leoshkevich , Reinoud Zandijk ,
 Zhao Liu , David Hildenbrand ,
 Halil Pasic , kvm@vger.kernel.org,
 "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org, Stefano Garzarella ,
 David Woodhouse ,
 Sunil Muthuswamy ,
 Richard Henderson ,
 Stefano Stabellini ,
 Matthew Rosato , qemu-s390x@nongnu.org,
 Paul Durrant , "Michael S. Tsirkin" ,
 Christian Borntraeger ,
 Anthony PERARD , Jason Herne
 , Paolo Bonzini ,
 Eric Farman 
References: <20250930082126.28618-1-philmd@linaro.org>
 <20250930082126.28618-3-philmd@linaro.org>
 <525dd07f-ae64-4ba7-b3ec-b9fcd86aa8a5@redhat.com>
 
From: Thomas Huth 
Autocrypt: addr=thuth@redhat.com; keydata=
 xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU
 yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2
 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW
 tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O
 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81
 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW
 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH
 gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr
 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ
 zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0
 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW
 AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK
 QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX
 EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV
 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD
 eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k
 ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq
 zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG
 tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6
 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7
 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN
 BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4
 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa
 +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH
 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K
 gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/
 WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ
 VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq
 knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV
 cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB
 X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM
 AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn
 ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k
 fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS
 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK
 cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV
 ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17
 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD
 oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs
 IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a
 yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn
In-Reply-To: 
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: vzGkMg7xoheZQoPNFNuEVq2eNJ3mHW3xrR1KYgYQulo_1759223914
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/09/2025 10.31, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
> 
> On 30/9/25 10:24, Thomas Huth wrote:
>> On 30/09/2025 10.21, Philippe Mathieu-Daudé wrote:
>>> flatview_translate()'s @plen argument is output-only and can be NULL.
>>>
>>> When Xen is enabled, only update @plen_out when non-NULL.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>   include/system/memory.h | 5 +++--
>>>   system/physmem.c        | 9 +++++----
>>>   2 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/system/memory.h b/include/system/memory.h
>>> index aa85fc27a10..3e5bf3ef05e 100644
>>> --- a/include/system/memory.h
>>> +++ b/include/system/memory.h
>>> @@ -2992,13 +2992,14 @@ IOMMUTLBEntry 
>>> address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
>>>    * @addr: address within that address space
>>>    * @xlat: pointer to address within the returned memory region section's
>>>    * #MemoryRegion.
>>> - * @len: pointer to length
>>> + * @plen_out: pointer to valid read/write length of the translated address.
>>> + *            It can be @NULL when we don't care about it.
>>>    * @is_write: indicates the transfer direction
>>>    * @attrs: memory attributes
>>>    */
>>>   MemoryRegion *flatview_translate(FlatView *fv,
>>>                                    hwaddr addr, hwaddr *xlat,
>>> -                                 hwaddr *len, bool is_write,
>>> +                                 hwaddr *plen_out, bool is_write,
>>>                                    MemTxAttrs attrs);
>>>   static inline MemoryRegion *address_space_translate(AddressSpace *as,
>>> diff --git a/system/physmem.c b/system/physmem.c
>>> index 8a8be3a80e2..86422f294e2 100644
>>> --- a/system/physmem.c
>>> +++ b/system/physmem.c
>>> @@ -566,7 +566,7 @@ iotlb_fail:
>>>   /* Called from RCU critical section */
>>>   MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat,
>>> -                                 hwaddr *plen, bool is_write,
>>> +                                 hwaddr *plen_out, bool is_write,
>>>                                    MemTxAttrs attrs)
>>>   {
>>>       MemoryRegion *mr;
>>> @@ -574,13 +574,14 @@ MemoryRegion *flatview_translate(FlatView *fv, 
>>> hwaddr addr, hwaddr *xlat,
>>>       AddressSpace *as = NULL;
>>>       /* This can be MMIO, so setup MMIO bit. */
>>> -    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
>>> +    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
>>>                                       is_write, true, &as, attrs);
>>>       mr = section.mr;
>>> -    if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) {
>>> +    if (xen_enabled() && plen_out && memory_access_is_direct(mr, is_write,
>>> +                                                             attrs)) {
>>>           hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - 
>>> addr;
>>> -        *plen = MIN(page, *plen);
>>> +        *plen_out = MIN(page, *plen_out);
>>>       }
>>
>> My question from the previous version is still unanswered:
>>
>> https://lore.kernel.org/qemu- 
>> devel/22ff756a-51a2-43f4-8fe1-05f17ff4a371@redhat.com/
> 
> This patches
> - checks for plen not being NULL
> - describes it as
>    "When Xen is enabled, only update @plen_out when non-NULL."
> - mention that in the updated flatview_translate() documentation
>    "It can be @NULL when we don't care about it." as documented for
>    the flatview_do_translate() callee in commit d5e5fafd11b ("exec:
>    add page_mask for flatview_do_translate")
> 
> before:
> 
>    it was not clear whether we can pass plen=NULL without having
>    to look at the code.
> 
> after:
> 
>    no change when plen is not NULL, we can pass plen=NULL safely
>    (it is documented).
> 
> I shouldn't be understanding your original question, do you mind
> rewording it?

Ah, you've updated the patch in v3 to include a check for plen_out in the 
if-statement! It was not there in v2. Ok, this should be fine now:

Reviewed-by: Thomas Huth 

I just re-complained since you did not respond to my mail in v2, and when I 
looked at the changelog in your v3 cover letter, you did not mention the 
modification here, so I blindly assumed that this patch was unchanged.

  Thomas



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 10:04:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 10:04:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134160.1472153 (Exim 4.92)
	(envelope-from )
	id 1v3XDV-0003O1-9D; Tue, 30 Sep 2025 10:04:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134160.1472153; Tue, 30 Sep 2025 10:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3XDV-0003Nu-6b; Tue, 30 Sep 2025 10:04:17 +0000
Received: by outflank-mailman (input) for mailman id 1134160;
 Tue, 30 Sep 2025 10:04: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 1v3XDT-0003Nn-3x
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 10:04:16 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d094ff83-9de4-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 12:04:13 +0200 (CEST)
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]
 helo=noisy.programming.kicks-ass.net)
 by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
 id 1v3XDI-00000009k3g-2ECK; Tue, 30 Sep 2025 10:04:05 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
 id 3AE8B300220; Tue, 30 Sep 2025 12:04: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: d094ff83-9de4-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=MWKfGHqfQoXIoK2fr1DCRttNg7EHyA3c10MmVnFnCAg=; b=MTCvNJVWJBWdqU/OOjC3FdgGUj
	S9PS2pOsDZGrhIS/9a+YND5J88eADzGtxSWVvcA6Wsn0e/5M4jhPP+6I6+2BcS/+uMP5xpzMUydhJ
	ytAGsrd3YGFfj1dDkK8Z6PFftkOzZFsZ4Jrak8NkDKTv8XNT4hrKbb9HDEFZrU7gv0l5uBlb7Ce/H
	uQ02gzpHBuasGSJLVXmsifPugnt/bFZUGE6QtKMe4YI28R22olde3vgZ/l+PpGTjvjjof7m/5s35q
	Nuu8pY44EpRfS8UcSLYvEETcuGS7fVJlfAY8jbjRtrqiw5cNX1s5ZMO/MWmTNQ37r82UtV6U02nBi
	XA97nfbg==;
Date: Tue, 30 Sep 2025 12:04:04 +0200
From: Peter Zijlstra 
To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	virtualization@lists.linux.dev, xin@zytor.com,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
Message-ID: <20250930100404.GK4067720@noisy.programming.kicks-ass.net>
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
 <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="OKKMZZxPhdskK4Hh"
Content-Disposition: inline
In-Reply-To: <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>


--OKKMZZxPhdskK4Hh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 30, 2025 at 11:02:52AM +0200, J=FCrgen Gro=DF wrote:
> On 30.09.25 10:38, Peter Zijlstra wrote:
> > On Tue, Sep 30, 2025 at 09:03:55AM +0200, Juergen Gross wrote:
> >=20
> > > +static __always_inline u64 read_msr(u32 msr)
> > > +{
> > > +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> > > +		return xen_read_msr(msr);
> > > +
> > > +	return native_rdmsrq(msr);
> > > +}
> > > +
> > > +static __always_inline int read_msr_safe(u32 msr, u64 *p)
> > > +{
> > > +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> > > +		return xen_read_msr_safe(msr, p);
> > > +
> > > +	return native_read_msr_safe(msr, p);
> > > +}
> > > +
> > > +static __always_inline void write_msr(u32 msr, u64 val)
> > > +{
> > > +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> > > +		xen_write_msr(msr, val);
> > > +	else
> > > +		native_wrmsrq(msr, val);
> > > +}
> > > +
> > > +static __always_inline int write_msr_safe(u32 msr, u64 val)
> > > +{
> > > +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> > > +		return xen_write_msr_safe(msr, val);
> > > +
> > > +	return native_write_msr_safe(msr, val);
> > > +}
> > > +
> > > +static __always_inline u64 rdpmc(int counter)
> > > +{
> > > +	if (cpu_feature_enabled(X86_FEATURE_XENPV))
> > > +		return xen_read_pmc(counter);
> > > +
> > > +	return native_read_pmc(counter);
> > > +}
> >=20
> > Egads, didn't we just construct giant ALTERNATIVE()s for the native_
> > things? Why wrap that in a cpu_feature_enabled() instead of just adding
> > one more case to the ALTERNATIVE() ?
>=20
> The problem I encountered with using pv_ops was to implement the *_safe()
> variants. There is no simple way to do that using ALTERNATIVE_(), as
> in the Xen PV case the call will remain, and I didn't find a way to
> specify a sane interface between the call-site and the called Xen function
> to return the error indicator. Remember that at the call site the main
> interface is the one of the RDMSR/WRMSR instructions. They lack an error
> indicator.

Would've been useful Changelog material that I suppose.

> In Xin's series there was a patch written initially by you to solve such
> a problem by adding the _ASM_EXTABLE_FUNC_REWIND() exception table method.
> I think this is a dead end, as it will break when using a shadow stack.

No memories, let me go search. I found this:

  https://patchwork.ozlabs.org/project/linux-ide/patch/20250331082251.31712=
76-12-xin@zytor.com/

That's the other Peter :-)

Anyway, with shadowstack you should be able to frob SSP along with SP in
the exception context. IIRC the SSP 'return' value is on the SS itself,
so a WRSS to that field can easily make the whole CALL go away.

> Additionally I found a rather ugly hack only to avoid re-iterating most of
> the bare metal ALTERNATIVE() for the paravirt case. It is possible, but t=
he
> bare metal case is gaining one additional ALTERNATIVE level, resulting in
> patching the original instruction with an identical copy first.

OTOH the above generates atrocious crap code :/

You get that _static_cpu_has() crud, which is basically a really fat
jump_label (because it needs to include the runtime test) and then the
code for both your xen thing and the alternative.

/me ponders things a bit..

> Remember that at the call site the main interface is the one of the
> RDMSR/WRMSR instructions. They lack an error indicator.

This, that isn't true.

Note how ex_handler_msr() takes a reg argument and how that sets that
reg to -EIO. See how the current native_read_msr_safe() uses that:

  _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %[err])

(also note how using _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_*_SAFE) like you
do, will result in reg being 0 or ax. Scribbling your 0 return value)

It very explicitly uses @err as error return value. So your call would
return eax:edx and take ecx to be the msr, but there is nothing stopping
us from then using say ebx for error return, like:

	int err =3D 0;

	asm_inline(
		"1:\n"
		ALTERNATIVE("ds rdmsr",
			    "call xen_rdmsr", XENPV)
		"2:\n"

		_ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %%ebx)

		: "a" (ax), "d" (dx), "+b" (err)
		: "c" (msr));

	return err;

Hmm?

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

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

iQIzBAABCgAdFiEEv3OU3/byMaA0LqWJdkfhpEvA5LoFAmjbqxQACgkQdkfhpEvA
5LrlWxAAqulZs4pOHvRqUmLabha0Md6Falt3RnNmeNOe0ALy2IX0BKsPFMKwZYVd
RepAgPRzqFQT/TXPVN1Xl1b0Untty0TDZraoLeUUEKdPnc6yqXlSSZIqO+ObLM/9
h9SikaadckG2IhydaxD61jeW4ZWSUjR7zcFz+NcYVDtegIrz/WoO04k9EwFEUrB1
eLqiXc2m9OwMxbLPlSp0ux881Pwyvu5qmcfbuvh0bZcQq+3LADuNGcofbJe0V5Ug
0eWvoe+35N+ntv/2vgaObV/ksZhg0bLvQDjO86e/Wka4wGwSCiOrAQFj2mMfKe+w
Ax/dZd4LpysGV/tlk3PwbkLED06yfQzIwoOKc51kmJ7IonSYeaS/nTcQaPdjbaJZ
N9FMdJ6zCZx64QZXW6ytZCpsVaiHleFBOug6SGRYkf8IdDzRZB0O4yrp1WVLs6w5
qLzmrFQkGvNGURUqvy1T9pCX+vzZg4tSGxsFTlGObeLclvhQCr1SCignk8HYpcc8
LGR2C1AbBXZQVzBwF9qhqPFPKANp5baq5BkyFZVOUIqkZfMZaW0fAVsidwC60Df2
Tz/891/zvYOMZZqi672Ci1Qz2MwSu2twj9MdWoMs1z+pvVHAhi4MDRXqKf3yrdW3
bIsP9gLuPAb9JjkMtUQ+0BmBPNc+o67KwijHXDiaoGkXtpU698I=
=NBbB
-----END PGP SIGNATURE-----

--OKKMZZxPhdskK4Hh--


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 10:13:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 10:13:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134176.1472164 (Exim 4.92)
	(envelope-from )
	id 1v3XMA-00054H-8B; Tue, 30 Sep 2025 10:13:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134176.1472164; Tue, 30 Sep 2025 10:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3XMA-00054A-4T; Tue, 30 Sep 2025 10:13:14 +0000
Received: by outflank-mailman (input) for mailman id 1134176;
 Tue, 30 Sep 2025 10:13: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 1v3XM8-000544-M4
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 10:13:12 +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 11997018-9de6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 12:13:11 +0200 (CEST)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-46e504975dbso17661535e9.1
 for ; Tue, 30 Sep 2025 03:13:11 -0700 (PDT)
Received: from [192.168.69.221] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-40fc5603365sm22687164f8f.37.2025.09.30.03.13.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 03:13: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: 11997018-9de6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759227191; x=1759831991; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5Fmj4kPweqGagopkTjTJLhrAbweIQr5nzSW5aUdudZo=;
        b=zIupjAi+sQkuk41MBnZwKhtvxPy3IWjK4aF+LMZLih+98pW8IVC06qzTI9zL78X0vf
         AtV5WjEeO5y3TmbSAG8uDcX7V3gAWVeg/4GUbiS4+/aRcPt4LMLlRvCy1P+Q8aDTfi8I
         FS1TZ9g3h+z/jYlZDP0x3txDKy41qkmxFbabUOLjbzLxFCYQGuuby4KX2fc8cepOuSM1
         rdfRujs76oyPnCb5Iw9PRpGjw/ud4S3uQNfajfbsH70HsEp7n3ghWoMhekmyqKMn7bdo
         heuXKtlUw6fOQO1aQNoWTNngW82R3wdVB+hI4ICBNdcsl+sdXQhTyBykGumncv+cNyKQ
         swbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759227191; x=1759831991;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5Fmj4kPweqGagopkTjTJLhrAbweIQr5nzSW5aUdudZo=;
        b=rsGmhgEfoXjmHXO2sevKjaCXGSGcLEPNkoXCQNky4g66nZVF7QloNTmp7wDaRz04ev
         Ho0Cybtri1Yt6WUU5+PNJUmTRRPA0i4hShTP4awNs2WCSsIqDz8aIadBhHXQ054kd/Zl
         gWV564UfpQGaN08vqpqR9b6W6ZxITDXGElRIo0XB1ddAzTgvH6wugxBlYDtmYaX9dI/v
         erSpoVzNoSQFkqjF2sWxNj6cNEvD1YUFNE5dUa6UXMM92Lis0BGrqD7xkGCqSMe7Rjjt
         3igLj9b3gKTbm97MR1ZAGBfNoeJyrtmpk9X6KpiffMBOfGPo7ILAYuxYwyEVHQcJHSuj
         Ye4g==
X-Forwarded-Encrypted: i=1; AJvYcCWs+DDm437cbLuM8pZcWuoLb9ir5+z4Ybmm1SvTaG+IkywRPszREkh407KGyw7lurqjKUgGyxL/RIs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8G8QjjlaPX46bTsM5ktYo1sCn1CiT1hf2sSPPZAPuOXgEdek3
	nR7qQAhfbPhGJt1eb2XaPNDfUV3j+rNqZlYe/zHBECaU/ImKmkTwkql2u+EDK0/OY+w=
X-Gm-Gg: ASbGnctzv372SPQSJ9kYzX7XZuKNMLPnS556KbXlQV01EizCsHSKde6IFMVgNF24Lit
	LdiWpXZCrQTN0PMUAQTgvWQz1uVvK68ngvZ8YL0NUf8PI5mLlociuVlRxzenIusHVCabQEZaNWI
	dygZqQEyrQ1QdiB3TTiyQrOfYlb2HXOF3X67ag5/G+/tU6ZJvzQzr/C08qAfKyScGzZamPpOmsW
	SzH2MG2xBheEjrKo46QaF19td+Y1ibwz1RmLT9nA4hm+8Ir9zjaR198MvhWpdcYw4eUo6jm3Cw2
	hCeWFb2Kr9nvMkErModxG7WtJRZSvW4TnyEMcJ8NSbnmu1bQMW32nOMK/3MtCN5vy+YbkPQkqKz
	HIBmztbOZHNEMEKdiaPcKqH5IOY2HkSA++br8865eyut0o755aeW+EVrYvQSBmc/hv8q2fGD5/1
	UdyiT/KY4ZVXSr0hJLexCM9H8a
X-Google-Smtp-Source: AGHT+IF+rnMcicNbR48yOpulUbrNdTkYdf+ObbjrIr9iaYQ/1taKuu6ICTWxB4B00uV+sYRmcLDB+g==
X-Received: by 2002:a05:600c:444e:b0:46e:1a5e:211 with SMTP id 5b1f17b1804b1-46e329f66f1mr159958645e9.21.1759227190642;
        Tue, 30 Sep 2025 03:13:10 -0700 (PDT)
Message-ID: <75cc454b-94d2-45e1-a766-71e6b2d62ac9@linaro.org>
Date: Tue, 30 Sep 2025 12:13:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/18] system/memory: Better describe @plen argument of
 flatview_translate()
Content-Language: en-US
To: Thomas Huth , qemu-devel@nongnu.org,
 Peter Maydell , Peter Xu 
Cc: Marcelo Tosatti ,
 Ilya Leoshkevich , Reinoud Zandijk ,
 Zhao Liu , David Hildenbrand ,
 Halil Pasic , kvm@vger.kernel.org,
 "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org, Stefano Garzarella ,
 David Woodhouse ,
 Sunil Muthuswamy ,
 Richard Henderson ,
 Stefano Stabellini ,
 Matthew Rosato , qemu-s390x@nongnu.org,
 Paul Durrant , "Michael S. Tsirkin" ,
 Christian Borntraeger ,
 Anthony PERARD , Jason Herne
 , Paolo Bonzini ,
 Eric Farman 
References: <20250930082126.28618-1-philmd@linaro.org>
 <20250930082126.28618-3-philmd@linaro.org>
 <525dd07f-ae64-4ba7-b3ec-b9fcd86aa8a5@redhat.com>
 
 <9993b187-7b44-4f9b-801d-fdfa6b309362@redhat.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <9993b187-7b44-4f9b-801d-fdfa6b309362@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 30/9/25 11:18, Thomas Huth wrote:
> On 30/09/2025 10.31, Philippe Mathieu-Daudé wrote:
>> Hi Thomas,
>>
>> On 30/9/25 10:24, Thomas Huth wrote:
>>> On 30/09/2025 10.21, Philippe Mathieu-Daudé wrote:
>>>> flatview_translate()'s @plen argument is output-only and can be NULL.
>>>>
>>>> When Xen is enabled, only update @plen_out when non-NULL.
>>>>
>>>> Signed-off-by: Philippe Mathieu-Daudé 
>>>> ---
>>>>   include/system/memory.h | 5 +++--
>>>>   system/physmem.c        | 9 +++++----
>>>>   2 files changed, 8 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/include/system/memory.h b/include/system/memory.h
>>>> index aa85fc27a10..3e5bf3ef05e 100644
>>>> --- a/include/system/memory.h
>>>> +++ b/include/system/memory.h
>>>> @@ -2992,13 +2992,14 @@ IOMMUTLBEntry 
>>>> address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
>>>>    * @addr: address within that address space
>>>>    * @xlat: pointer to address within the returned memory region 
>>>> section's
>>>>    * #MemoryRegion.
>>>> - * @len: pointer to length
>>>> + * @plen_out: pointer to valid read/write length of the translated 
>>>> address.
>>>> + *            It can be @NULL when we don't care about it.
>>>>    * @is_write: indicates the transfer direction
>>>>    * @attrs: memory attributes
>>>>    */
>>>>   MemoryRegion *flatview_translate(FlatView *fv,
>>>>                                    hwaddr addr, hwaddr *xlat,
>>>> -                                 hwaddr *len, bool is_write,
>>>> +                                 hwaddr *plen_out, bool is_write,
>>>>                                    MemTxAttrs attrs);
>>>>   static inline MemoryRegion *address_space_translate(AddressSpace *as,
>>>> diff --git a/system/physmem.c b/system/physmem.c
>>>> index 8a8be3a80e2..86422f294e2 100644
>>>> --- a/system/physmem.c
>>>> +++ b/system/physmem.c
>>>> @@ -566,7 +566,7 @@ iotlb_fail:
>>>>   /* Called from RCU critical section */
>>>>   MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr 
>>>> *xlat,
>>>> -                                 hwaddr *plen, bool is_write,
>>>> +                                 hwaddr *plen_out, bool is_write,
>>>>                                    MemTxAttrs attrs)
>>>>   {
>>>>       MemoryRegion *mr;
>>>> @@ -574,13 +574,14 @@ MemoryRegion *flatview_translate(FlatView *fv, 
>>>> hwaddr addr, hwaddr *xlat,
>>>>       AddressSpace *as = NULL;
>>>>       /* This can be MMIO, so setup MMIO bit. */
>>>> -    section = flatview_do_translate(fv, addr, xlat, plen, NULL,
>>>> +    section = flatview_do_translate(fv, addr, xlat, plen_out, NULL,
>>>>                                       is_write, true, &as, attrs);
>>>>       mr = section.mr;
>>>> -    if (xen_enabled() && memory_access_is_direct(mr, is_write, 
>>>> attrs)) {
>>>> +    if (xen_enabled() && plen_out && memory_access_is_direct(mr, 
>>>> is_write,
>>>> +                                                             attrs)) {
>>>>           hwaddr page = ((addr & TARGET_PAGE_MASK) + 
>>>> TARGET_PAGE_SIZE) - addr;
>>>> -        *plen = MIN(page, *plen);
>>>> +        *plen_out = MIN(page, *plen_out);
>>>>       }
>>>
>>> My question from the previous version is still unanswered:
>>>
>>> https://lore.kernel.org/qemu- 
>>> devel/22ff756a-51a2-43f4-8fe1-05f17ff4a371@redhat.com/
>>
>> This patches
>> - checks for plen not being NULL
>> - describes it as
>>    "When Xen is enabled, only update @plen_out when non-NULL."
>> - mention that in the updated flatview_translate() documentation
>>    "It can be @NULL when we don't care about it." as documented for
>>    the flatview_do_translate() callee in commit d5e5fafd11b ("exec:
>>    add page_mask for flatview_do_translate")
>>
>> before:
>>
>>    it was not clear whether we can pass plen=NULL without having
>>    to look at the code.
>>
>> after:
>>
>>    no change when plen is not NULL, we can pass plen=NULL safely
>>    (it is documented).
>>
>> I shouldn't be understanding your original question, do you mind
>> rewording it?
> 
> Ah, you've updated the patch in v3 to include a check for plen_out in 
> the if-statement! It was not there in v2. Ok, this should be fine now:
> 
> Reviewed-by: Thomas Huth 
> 
> I just re-complained since you did not respond to my mail in v2, and 
> when I looked at the changelog in your v3 cover letter, you did not 
> mention the modification here, so I blindly assumed that this patch was 
> unchanged.

Ah I see... OK I'll try to be more explicit in my respins.

Thanks for your review!

Phil.


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 10:43:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 10:43:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134188.1472174 (Exim 4.92)
	(envelope-from )
	id 1v3XpS-0000gF-DO; Tue, 30 Sep 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 1134188.1472174; Tue, 30 Sep 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 1v3XpS-0000g8-Ap; Tue, 30 Sep 2025 10:43:30 +0000
Received: by outflank-mailman (input) for mailman id 1134188;
 Tue, 30 Sep 2025 10:43:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1v3XpQ-0000fx-Lg
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 10:43:28 +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 4ba5b930-9dea-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 12:43:26 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-62ec5f750f7so8559146a12.3
 for ; Tue, 30 Sep 2025 03:43:26 -0700 (PDT)
Received: from ?IPV6:2003:e5:873f:400:7b4f:e512:a417:5a86?
 (p200300e5873f04007b4fe512a4175a86.dip0.t-ipconnect.de.
 [2003:e5:873f:400:7b4f:e512:a417:5a86])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-636361773a6sm4497761a12.6.2025.09.30.03.43.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 03:43: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: 4ba5b930-9dea-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1759229006; x=1759833806; 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=RB0qYt5b5QDXjhC4b6AM5ldFgAgUmpY232wNN6bJqe0=;
        b=gTNKfSYMYfOCABRWaJLaUhpVODLPUyq8adzJqzWGtd8+GZ8788wrr9F0t1MKnj2k9K
         YO0MZaTFzmlvYNsTIpDd+2iI6I/hC9Vd8IjvC9hdDL2QbZYAKYOV6dx+K6Knbj1swyMQ
         f2lLVn9nEtxv6N80w3WFvICto0uocutr5ux0jjHmUkR16bQ2kuVkDDabtsjWzbDmfWdC
         IXUb2o6a7m4oYP+lFrl5eVRT1NK4vWffxaqE0xYJLf+4sgfoVtU4mTqTiUkhFHkWWYbd
         8heY8x4yeiRC4H9ZXu/RUa4jDQTIbgryYOh0W7mVsPq/SWMjQ2bgZ4U4IPVj5wDcGmXi
         JvCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759229006; x=1759833806;
        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=RB0qYt5b5QDXjhC4b6AM5ldFgAgUmpY232wNN6bJqe0=;
        b=PlArOLRvoVlxFKCv0KAJtLwqgsRw/DUUVUsqniGMy+3nZ1PEfaklysjM7IqCwMpx2C
         gUkHPGfHFf7U7jY6BHuTgD7vcZVNLCiyj3mftgs1ohnaKvhSQiBaFRQUbPRpnSynGXIl
         kluWUFI5ScxYQJcJYwZ5bqbSZ9caHkz23CubzErkgWFrt08G5NIiJRL8R9ta2txmQoCP
         TpRs2MGx1DsU4SGH3IV2LOH/8CWo5q0pIjq+jXaB43oDOnJOy6etZG8zuB+h91v/Z3rR
         w6O3V0vnLQO+//4iCZ5i+rXoV6h9fVnd9joAkZgbs7XsY5HvqkDqtzPre8D368y5kIJs
         cLIw==
X-Forwarded-Encrypted: i=1; AJvYcCW0JQbxCcGk7c2LRKO1pX1MGzgkN4yeO24UNvkunsQzVp5XRov8x152OIUpAQdjudEJ387SI/cR/DQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyo+5IBXwfKQ3fOglQ8/WQbgnmG4TTGsVk+23iSbuO6N0NfEyRu
	yxrNX7XHpRNjZzNCDMws5qFvoiI6/f5skyJvwmni+h/H8woQgwVsAyrlk72aD1loF0k=
X-Gm-Gg: ASbGnctc3jjkT3K+NDjPq1H/pLZ3jAfnf91WPOcRRykEnUKI4D9ICyKSJIuaadfr7l0
	fR5NxQpUZNFLwnnPvUwqXMGZ+Nh84kLeKcVuYoDO4TchgJWM+pGIqyIqnh2bx1ju8XTQdTTEtSJ
	Ua4lpCso3WpsDM4ZfyJh+Xfj19pEB9wgAi7SyKmck5b3/luY9561i1nBhsy6baozWlZ5d1lX2jX
	l85oi4ZvSK9Qziei+0R8r3K7HuXPE1Uh0slZjaX/ovJllv14ohYRja0H7395qNok8OCNXkxmYS3
	B+4E+4DrPACBqvmPrYawoNTSeLm/XqIjbbOqJgDL06noo/EIJw9GQEh+/kJo2K46wtRniTaj05T
	SE7rAvMOK/V+wLHGVPhXwmKPnpZZxU/dUyN5uoVSCuUAigSQyv4MYm2FOb2tcavbnmB3u3QQHX2
	knFo2k1sDodbACDAQRojbowV6zVJCpmQp39JIypCopMoLF9urHgrFuIC2sCE+xg4/BTNSd3I1ks
	kiLBKU=
X-Google-Smtp-Source: AGHT+IFoB6ZUUTPKr7sfETP2ZASQesBVMNfbsYpHO4UTgJXela1OGRUFljxnCYySfeW7+T6l2opvLA==
X-Received: by 2002:a05:6402:2109:b0:636:740:e4f8 with SMTP id 4fb4d7f45d1cf-6360740ef79mr9923703a12.18.1759229006040;
        Tue, 30 Sep 2025 03:43:26 -0700 (PDT)
Message-ID: 
Date: Tue, 30 Sep 2025 12:43:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, xin@zytor.com,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" , Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
 <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
 <20250930100404.GK4067720@noisy.programming.kicks-ass.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: <20250930100404.GK4067720@noisy.programming.kicks-ass.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Qe0zjUS29flF23TwXpTKjQKv"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Qe0zjUS29flF23TwXpTKjQKv
Content-Type: multipart/mixed; boundary="------------MO6SwkMMEKwBe0hiYG7210uG";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, xin@zytor.com,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" , Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
 <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
 <20250930100404.GK4067720@noisy.programming.kicks-ass.net>
In-Reply-To: <20250930100404.GK4067720@noisy.programming.kicks-ass.net>

--------------MO6SwkMMEKwBe0hiYG7210uG
Content-Type: multipart/mixed; boundary="------------uJZRcyqOhLjfs71u70ZapZ0Y"

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

T24gMzAuMDkuMjUgMTI6MDQsIFBldGVyIFppamxzdHJhIHdyb3RlOg0KPiBPbiBUdWUsIFNl
cCAzMCwgMjAyNSBhdCAxMTowMjo1MkFNICswMjAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0K
Pj4gT24gMzAuMDkuMjUgMTA6MzgsIFBldGVyIFppamxzdHJhIHdyb3RlOg0KPj4+IE9uIFR1
ZSwgU2VwIDMwLCAyMDI1IGF0IDA5OjAzOjU1QU0gKzAyMDAsIEp1ZXJnZW4gR3Jvc3Mgd3Jv
dGU6DQo+Pj4NCj4+Pj4gK3N0YXRpYyBfX2Fsd2F5c19pbmxpbmUgdTY0IHJlYWRfbXNyKHUz
MiBtc3IpDQo+Pj4+ICt7DQo+Pj4+ICsJaWYgKGNwdV9mZWF0dXJlX2VuYWJsZWQoWDg2X0ZF
QVRVUkVfWEVOUFYpKQ0KPj4+PiArCQlyZXR1cm4geGVuX3JlYWRfbXNyKG1zcik7DQo+Pj4+
ICsNCj4+Pj4gKwlyZXR1cm4gbmF0aXZlX3JkbXNycShtc3IpOw0KPj4+PiArfQ0KPj4+PiAr
DQo+Pj4+ICtzdGF0aWMgX19hbHdheXNfaW5saW5lIGludCByZWFkX21zcl9zYWZlKHUzMiBt
c3IsIHU2NCAqcCkNCj4+Pj4gK3sNCj4+Pj4gKwlpZiAoY3B1X2ZlYXR1cmVfZW5hYmxlZChY
ODZfRkVBVFVSRV9YRU5QVikpDQo+Pj4+ICsJCXJldHVybiB4ZW5fcmVhZF9tc3Jfc2FmZSht
c3IsIHApOw0KPj4+PiArDQo+Pj4+ICsJcmV0dXJuIG5hdGl2ZV9yZWFkX21zcl9zYWZlKG1z
ciwgcCk7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK3N0YXRpYyBfX2Fsd2F5c19pbmxpbmUg
dm9pZCB3cml0ZV9tc3IodTMyIG1zciwgdTY0IHZhbCkNCj4+Pj4gK3sNCj4+Pj4gKwlpZiAo
Y3B1X2ZlYXR1cmVfZW5hYmxlZChYODZfRkVBVFVSRV9YRU5QVikpDQo+Pj4+ICsJCXhlbl93
cml0ZV9tc3IobXNyLCB2YWwpOw0KPj4+PiArCWVsc2UNCj4+Pj4gKwkJbmF0aXZlX3dybXNy
cShtc3IsIHZhbCk7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK3N0YXRpYyBfX2Fsd2F5c19p
bmxpbmUgaW50IHdyaXRlX21zcl9zYWZlKHUzMiBtc3IsIHU2NCB2YWwpDQo+Pj4+ICt7DQo+
Pj4+ICsJaWYgKGNwdV9mZWF0dXJlX2VuYWJsZWQoWDg2X0ZFQVRVUkVfWEVOUFYpKQ0KPj4+
PiArCQlyZXR1cm4geGVuX3dyaXRlX21zcl9zYWZlKG1zciwgdmFsKTsNCj4+Pj4gKw0KPj4+
PiArCXJldHVybiBuYXRpdmVfd3JpdGVfbXNyX3NhZmUobXNyLCB2YWwpOw0KPj4+PiArfQ0K
Pj4+PiArDQo+Pj4+ICtzdGF0aWMgX19hbHdheXNfaW5saW5lIHU2NCByZHBtYyhpbnQgY291
bnRlcikNCj4+Pj4gK3sNCj4+Pj4gKwlpZiAoY3B1X2ZlYXR1cmVfZW5hYmxlZChYODZfRkVB
VFVSRV9YRU5QVikpDQo+Pj4+ICsJCXJldHVybiB4ZW5fcmVhZF9wbWMoY291bnRlcik7DQo+
Pj4+ICsNCj4+Pj4gKwlyZXR1cm4gbmF0aXZlX3JlYWRfcG1jKGNvdW50ZXIpOw0KPj4+PiAr
fQ0KPj4+DQo+Pj4gRWdhZHMsIGRpZG4ndCB3ZSBqdXN0IGNvbnN0cnVjdCBnaWFudCBBTFRF
Uk5BVElWRSgpcyBmb3IgdGhlIG5hdGl2ZV8NCj4+PiB0aGluZ3M/IFdoeSB3cmFwIHRoYXQg
aW4gYSBjcHVfZmVhdHVyZV9lbmFibGVkKCkgaW5zdGVhZCBvZiBqdXN0IGFkZGluZw0KPj4+
IG9uZSBtb3JlIGNhc2UgdG8gdGhlIEFMVEVSTkFUSVZFKCkgPw0KPj4NCj4+IFRoZSBwcm9i
bGVtIEkgZW5jb3VudGVyZWQgd2l0aCB1c2luZyBwdl9vcHMgd2FzIHRvIGltcGxlbWVudCB0
aGUgKl9zYWZlKCkNCj4+IHZhcmlhbnRzLiBUaGVyZSBpcyBubyBzaW1wbGUgd2F5IHRvIGRv
IHRoYXQgdXNpbmcgQUxURVJOQVRJVkVfPG4+KCksIGFzDQo+PiBpbiB0aGUgWGVuIFBWIGNh
c2UgdGhlIGNhbGwgd2lsbCByZW1haW4sIGFuZCBJIGRpZG4ndCBmaW5kIGEgd2F5IHRvDQo+
PiBzcGVjaWZ5IGEgc2FuZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgY2FsbC1zaXRlIGFuZCB0
aGUgY2FsbGVkIFhlbiBmdW5jdGlvbg0KPj4gdG8gcmV0dXJuIHRoZSBlcnJvciBpbmRpY2F0
b3IuIFJlbWVtYmVyIHRoYXQgYXQgdGhlIGNhbGwgc2l0ZSB0aGUgbWFpbg0KPj4gaW50ZXJm
YWNlIGlzIHRoZSBvbmUgb2YgdGhlIFJETVNSL1dSTVNSIGluc3RydWN0aW9ucy4gVGhleSBs
YWNrIGFuIGVycm9yDQo+PiBpbmRpY2F0b3IuDQo+IA0KPiBXb3VsZCd2ZSBiZWVuIHVzZWZ1
bCBDaGFuZ2Vsb2cgbWF0ZXJpYWwgdGhhdCBJIHN1cHBvc2UuDQo+IA0KPj4gSW4gWGluJ3Mg
c2VyaWVzIHRoZXJlIHdhcyBhIHBhdGNoIHdyaXR0ZW4gaW5pdGlhbGx5IGJ5IHlvdSB0byBz
b2x2ZSBzdWNoDQo+PiBhIHByb2JsZW0gYnkgYWRkaW5nIHRoZSBfQVNNX0VYVEFCTEVfRlVO
Q19SRVdJTkQoKSBleGNlcHRpb24gdGFibGUgbWV0aG9kLg0KPj4gSSB0aGluayB0aGlzIGlz
IGEgZGVhZCBlbmQsIGFzIGl0IHdpbGwgYnJlYWsgd2hlbiB1c2luZyBhIHNoYWRvdyBzdGFj
ay4NCj4gDQo+IE5vIG1lbW9yaWVzLCBsZXQgbWUgZ28gc2VhcmNoLiBJIGZvdW5kIHRoaXM6
DQo+IA0KPiAgICBodHRwczovL3BhdGNod29yay5vemxhYnMub3JnL3Byb2plY3QvbGludXgt
aWRlL3BhdGNoLzIwMjUwMzMxMDgyMjUxLjMxNzEyNzYtMTIteGluQHp5dG9yLmNvbS8NCj4g
DQo+IFRoYXQncyB0aGUgb3RoZXIgUGV0ZXIgOi0pDQoNCk9oLCBteSBiYWQsIHNvcnJ5LiA6
LSkNCg0KPiBBbnl3YXksIHdpdGggc2hhZG93c3RhY2sgeW91IHNob3VsZCBiZSBhYmxlIHRv
IGZyb2IgU1NQIGFsb25nIHdpdGggU1AgaW4NCj4gdGhlIGV4Y2VwdGlvbiBjb250ZXh0LiBJ
SVJDIHRoZSBTU1AgJ3JldHVybicgdmFsdWUgaXMgb24gdGhlIFNTIGl0c2VsZiwNCj4gc28g
YSBXUlNTIHRvIHRoYXQgZmllbGQgY2FuIGVhc2lseSBtYWtlIHRoZSB3aG9sZSBDQUxMIGdv
IGF3YXkuDQoNClllYWgsIGJ1dCBiZWluZyBhYmxlIHRvIGF2b2lkIGFsbCBvZiB0aGF0IGRh
bmNlIHdvdWxkbid0IGJlIHRvbyBiYWQgZWl0aGVyLg0KDQo+PiBBZGRpdGlvbmFsbHkgSSBm
b3VuZCBhIHJhdGhlciB1Z2x5IGhhY2sgb25seSB0byBhdm9pZCByZS1pdGVyYXRpbmcgbW9z
dCBvZg0KPj4gdGhlIGJhcmUgbWV0YWwgQUxURVJOQVRJVkUoKSBmb3IgdGhlIHBhcmF2aXJ0
IGNhc2UuIEl0IGlzIHBvc3NpYmxlLCBidXQgdGhlDQo+PiBiYXJlIG1ldGFsIGNhc2UgaXMg
Z2FpbmluZyBvbmUgYWRkaXRpb25hbCBBTFRFUk5BVElWRSBsZXZlbCwgcmVzdWx0aW5nIGlu
DQo+PiBwYXRjaGluZyB0aGUgb3JpZ2luYWwgaW5zdHJ1Y3Rpb24gd2l0aCBhbiBpZGVudGlj
YWwgY29weSBmaXJzdC4NCj4gDQo+IE9UT0ggdGhlIGFib3ZlIGdlbmVyYXRlcyBhdHJvY2lv
dXMgY3JhcCBjb2RlIDovDQoNClllcy4NCg0KPiBZb3UgZ2V0IHRoYXQgX3N0YXRpY19jcHVf
aGFzKCkgY3J1ZCwgd2hpY2ggaXMgYmFzaWNhbGx5IGEgcmVhbGx5IGZhdA0KPiBqdW1wX2xh
YmVsIChiZWNhdXNlIGl0IG5lZWRzIHRvIGluY2x1ZGUgdGhlIHJ1bnRpbWUgdGVzdCkgYW5k
IHRoZW4gdGhlDQo+IGNvZGUgZm9yIGJvdGggeW91ciB4ZW4gdGhpbmcgYW5kIHRoZSBhbHRl
cm5hdGl2ZS4NCg0KU2VlaW5nIGJvdGggdmFyaWFudHMgd291bGQgbWFrZSBpdCBlYXNpZXIg
dG8gZGVjaWRlLCBJIGd1ZXNzLg0KDQo+IA0KPiAvbWUgcG9uZGVycyB0aGluZ3MgYSBiaXQu
Lg0KPiANCj4+IFJlbWVtYmVyIHRoYXQgYXQgdGhlIGNhbGwgc2l0ZSB0aGUgbWFpbiBpbnRl
cmZhY2UgaXMgdGhlIG9uZSBvZiB0aGUNCj4+IFJETVNSL1dSTVNSIGluc3RydWN0aW9ucy4g
VGhleSBsYWNrIGFuIGVycm9yIGluZGljYXRvci4NCj4gDQo+IFRoaXMsIHRoYXQgaXNuJ3Qg
dHJ1ZS4NCj4gDQo+IE5vdGUgaG93IGV4X2hhbmRsZXJfbXNyKCkgdGFrZXMgYSByZWcgYXJn
dW1lbnQgYW5kIGhvdyB0aGF0IHNldHMgdGhhdA0KPiByZWcgdG8gLUVJTy4gU2VlIGhvdyB0
aGUgY3VycmVudCBuYXRpdmVfcmVhZF9tc3Jfc2FmZSgpIHVzZXMgdGhhdDoNCj4gDQo+ICAg
IF9BU01fRVhUQUJMRV9UWVBFX1JFRygxYiwgMmIsIEVYX1RZUEVfUkRNU1JfU0FGRSwgJVtl
cnJdKQ0KPiANCj4gKGFsc28gbm90ZSBob3cgdXNpbmcgX0FTTV9FWFRBQkxFX1RZUEUoMWIs
IDJiLCBFWF9UWVBFXypfU0FGRSkgbGlrZSB5b3UNCj4gZG8sIHdpbGwgcmVzdWx0IGluIHJl
ZyBiZWluZyAwIG9yIGF4LiBTY3JpYmJsaW5nIHlvdXIgMCByZXR1cm4gdmFsdWUpDQo+IA0K
PiBJdCB2ZXJ5IGV4cGxpY2l0bHkgdXNlcyBAZXJyIGFzIGVycm9yIHJldHVybiB2YWx1ZS4g
U28geW91ciBjYWxsIHdvdWxkDQo+IHJldHVybiBlYXg6ZWR4IGFuZCB0YWtlIGVjeCB0byBi
ZSB0aGUgbXNyLCBidXQgdGhlcmUgaXMgbm90aGluZyBzdG9wcGluZw0KPiB1cyBmcm9tIHRo
ZW4gdXNpbmcgc2F5IGVieCBmb3IgZXJyb3IgcmV0dXJuLCBsaWtlOg0KPiANCj4gCWludCBl
cnIgPSAwOw0KPiANCj4gCWFzbV9pbmxpbmUoDQo+IAkJIjE6XG4iDQo+IAkJQUxURVJOQVRJ
VkUoImRzIHJkbXNyIiwNCj4gCQkJICAgICJjYWxsIHhlbl9yZG1zciIsIFhFTlBWKQ0KPiAJ
CSIyOlxuIg0KPiANCj4gCQlfQVNNX0VYVEFCTEVfVFlQRV9SRUcoMWIsIDJiLCBFWF9UWVBF
X1JETVNSX1NBRkUsICUlZWJ4KQ0KPiANCj4gCQk6ICJhIiAoYXgpLCAiZCIgKGR4KSwgIiti
IiAoZXJyKQ0KPiAJCTogImMiIChtc3IpKTsNCj4gDQo+IAlyZXR1cm4gZXJyOw0KPiANCj4g
SG1tPw0KDQpPaCwgaW5kZWVkLg0KDQpMZXQgbWUgdHJ5IHRoYXQgYW5kIHdlIGNhbiBjaG9v
c2UgdGhlIGxlc3MgZXZpbC4gOi0pDQoNCg0KSnVlcmdlbg0K
--------------uJZRcyqOhLjfs71u70ZapZ0Y
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-----

--------------uJZRcyqOhLjfs71u70ZapZ0Y--

--------------MO6SwkMMEKwBe0hiYG7210uG--

--------------Qe0zjUS29flF23TwXpTKjQKv
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/Ey8FAmjbtE0FAwAAAAAACgkQsN6d1ii/Ey/F
Wwf/WJOrBM6l0KctiSZXfPxyAVz7Y/KfXcHiWmWbh3r15Ml4P9c5SriRck4+1ZNyDHTjpJqxuW+V
5o0V0U9d15MIlc4Y3DG/WW1zU3SHaEY09GY0cs3msFpo15nmFCcyBkXBkHg69Y31d+kuUJvAmJVs
GnVzrwyc9dv/+IjvKt3q/fHpLuLi479emvZfu/N0uu+8d2VAiVUS7GR9atv9zMDl7MyqHFo1bDU0
KFck8rebX+E3IpdcnQWa0XI5lc9ZrGO0FPWy5slNIHji7WEVhFMbdkjwLG3lOdzwbOvY/YSeX5SV
z1mDUwq37oseNVJ3s/9tRX9+WRhTqYzWHdFR3+bYaA==
=tsHn
-----END PGP SIGNATURE-----

--------------Qe0zjUS29flF23TwXpTKjQKv--


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 11:14:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 11:14:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134203.1472184 (Exim 4.92)
	(envelope-from )
	id 1v3YJZ-0004hZ-O2; Tue, 30 Sep 2025 11:14:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134203.1472184; Tue, 30 Sep 2025 11: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 1v3YJZ-0004hS-LK; Tue, 30 Sep 2025 11:14:37 +0000
Received: by outflank-mailman (input) for mailman id 1134203;
 Tue, 30 Sep 2025 11: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 1v3YJY-0004hK-8Q
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 11:14:36 +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 a4af18b1-9dee-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 13:14:34 +0200 (CEST)
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20)
 by DU5PR03MB10443.eurprd03.prod.outlook.com (2603:10a6:10:529::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 11:14:31 +0000
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9160.015; Tue, 30 Sep 2025
 11:14: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: a4af18b1-9dee-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a2Rh4jyAixlqgiWxkuzDU0bOzYW9504fPVi6HZZZ3eXPQilskEVfxZHG55F3V0t3XQP+wvQZR8KOl7/pGe0DJ+5CHi/V4J6eSp/R5mrufYfcHNW1cdpMWkDXAnp82B9505p+g1ctvBXwBnJuUjXt23Z43gEnoCv75lMabqGdwUF/Hqv9UJSc/ZaaUj16iOnRAft75/MbXfEiwgBbmOyHPkRn35eDAza+EUp9IdgiDxDr6udN8MLSJjvLlEJF6iDQA2HRHzg2NdmVd+uYZrr144fyEUCmVLUnKxPDqzpDxQQq5AmqrN1rRdicvImO/b8QwpoJjf0aKKiW8rcDd32wTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=65wjWuXOlos3TOjUeQMwqMqa73uDqsM0o+Naw9dYmjA=;
 b=lv4CdCCbqm/0fqoZDl6xMrqm2W7HBNp22CDUwEEpobby2KjZyeBrtyZUu1mhYu6jHBm8aqbYARjq8t4hLKRu+zwapPuNtJ6gLRw/2zhK7QSJzboHIbrJ9NDFv0/oUv6MSdbHnK/QuvHfbqsPxOHoR375+R1MmmUwuctVJc3NsuKzRtfHZQ+k2j5RNzoPfFD+bZckktQS4vRPg8yYLaJvPJFjRWpRcTkTIyvH1l+XNLllNDNw5muWKt+N5347IBxAL/H5KbnWLS4NepfnbaQmxypTI9PSsLFmOogtlPfnCwD7M8O9CM2vc039q3c+6x/Y7z9DT1nzeWMxqYKRYyCk5Q==
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=65wjWuXOlos3TOjUeQMwqMqa73uDqsM0o+Naw9dYmjA=;
 b=hK4Vvin6ZpmBtmrDc3ZjidgEoeCiwYLkAqRvBUw0Ysp4ygf44qCdqCnBP6pH/Tt0c9VdUypseyDL4EJLXflkK7R9otrFj5ISs649z70WLy/IEHBxPG/5jDl31oYbD6wt5rUqsv5zORP4dhObHJygjFUsj6ualxAP7ggb9fNc7LgwNIwmpbBhJkGVlZT1nqzy6iUh7IXsxzzx7I2gQ1wcQ1i7RMKPu4OHdJQGDfHgE23v/yo2altSm6fua893fyZuQjbkS0pCplONfMZk42CM+eXOeIq1OWCRz0+QQW7b5170/odNcNnoM1mOwxFzIkSJYr5bIUDEeI4R6OgfUHTC1Q==
From: Oleksandr Tyshchenko 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Michal
 Orzel , Ayan Kumar Halder , Stefano
 Stabellini 
Subject: Re: [ImageBuilder] uboot-script-gen: Add ability to configure static
 event channels
Thread-Topic: [ImageBuilder] uboot-script-gen: Add ability to configure static
 event channels
Thread-Index: AQHcMWv1PEvr31auREGXSWhX8dEo67SqknQAgAEBdwA=
Date: Tue, 30 Sep 2025 11:14:30 +0000
Message-ID: <562778be-c915-4122-a0b4-5c99c0ff726c@epam.com>
References: <20250929180746.1881872-1-oleksandr_tyshchenko@epam.com>
 
In-Reply-To:
 
Accept-Language: en-US, 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: AM9PR03MB7025:EE_|DU5PR03MB10443:EE_
x-ms-office365-filtering-correlation-id: 54bb312a-9767-49de-3f25-08de00128739
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|42112799006|376014|1800799024|366016|38070700021;
x-microsoft-antispam-message-info:
 =?utf-8?B?aEJOVmhRbTdQTk9UcUUzNDNOSU1iOHRSMG1renMxbEkxQlJSbzduaWVaYmZL?=
 =?utf-8?B?Nlkzd1ltbjZ2cUVhVU11NllFZng1U2RxZm1Qa1owMHVncWxFQ1pwZ1VtMng1?=
 =?utf-8?B?ZjAvN09NYWM0NjhTa2hodzhqdFdIZmc5TE1Ya0Jna2JaYUN5dk9LK3ZLQ1RZ?=
 =?utf-8?B?V2xneHZabzF4bVdVZzJZbSs4R2hwK1dCaTMrdlpvZlRKWUxFUkx4aXArUVV5?=
 =?utf-8?B?M3JaTmMxblZvU1IveVpiTXRORkFRb1d5QkcrSm9vYlJiMXNVQkh2MTZTZ0Rq?=
 =?utf-8?B?N0RkOUFuRVlTdVhnaDhkZ3pBWlRRWGUwRFhoZFpJbGV1Z05OZ1JUd2taTTNL?=
 =?utf-8?B?Mk4zdXlkRnMzUEF4K2YyNVE2Y3F6Ly84SXR2T2plK29jNy9lT0JxaFNmd2Ra?=
 =?utf-8?B?RUZYdUN1alAwYW94cXc1cENWbmhoUTUyUFkwa0xWR1FpVkhaZTNIY1UvRi9E?=
 =?utf-8?B?UGYrY3IzR0J2WmZIV2o4QWZpN1lBNGp1ZGlSUmZqMXBKRldrOTFLcFlzaGMr?=
 =?utf-8?B?MFhPc01uY2NkQzdFTkM1TzFlVk45a3hEcjFDMHJaQjhVL29mbG8yQVRIRHNX?=
 =?utf-8?B?UE5xZlFjODd1bmUvRnozVmJGN041Uzc3YUFCVXMrVjRNOVpYVDZNakhZeEFG?=
 =?utf-8?B?Tm9FY1RhQUJRZzVCbzVNN3JTQkE4dCtYL1BZYWJqZFVwQUpZZEJCdDBYRSs0?=
 =?utf-8?B?dWxPZG9JZUJJWVM5SVVpODhyZmdDWXliKzdyanc0S0ZsOHlPUC91clptbXN1?=
 =?utf-8?B?eCs5a1gxZk81RzhKNWtaOGptNUhMUDVPbE54N3VtWDF6ZFlxNDBVNXRPdW1S?=
 =?utf-8?B?WWVmalZpUm0wUERzUEJJb2NjSDJwUWR2SXMvcmltNEw5TStMUXNZbEZXMnd4?=
 =?utf-8?B?WlpEVUVjV0NDNWw4TTYwbWEyMUwxRTRVNlhINWRsTjRsaldqWFAxN0QwTzVE?=
 =?utf-8?B?WVRNRDJFSExrdE4zNzVidTliMDZRWk8wTmNyWU41S3lSZzJsU1VMb1o5R25E?=
 =?utf-8?B?QzVxb0hDMzF6MytGaU9seW1Kd0RnWjNrV2drRFpicUlhbVpORjNZN3VOUU8v?=
 =?utf-8?B?N2xlSkRFb1dJR0ZMZm4vS1JCUHhtK3F3U21POVM4TU1PODZabU1yN3Y3eW1s?=
 =?utf-8?B?SFFDenJIYmpqR3Q2V0U4UktTbHRPSndXQnlYWklQM0RpeTB6MFUyT3FYdGlC?=
 =?utf-8?B?YjlwQnpCa1AwSDJQZHpSaXhqM25YRW5TdC9hVU4wL21lNDhDR2ZXWXVyYzhN?=
 =?utf-8?B?NkR3YlEyM2M2ejVsSlg1ZjJ3dGJJeXFrbnlTOHo3Y1JEK0J4NnIxb0N0MDRD?=
 =?utf-8?B?WmowZVBCZy9Iby9IN3dZbldSL0I4anJUM09ZbWlSdlVUTHZJTENTR2FlZWFm?=
 =?utf-8?B?WXpOSlcwNUUyUWtsNUpEOXAzVHhDYTduS0FaS0ZNYnRwWXE2SndZTlRXcmVj?=
 =?utf-8?B?cDRacmc1bjVIZkoyRTI0SWVObEhCcHB4b0dZaWhubzcxb3FYQlRtTWViWlpp?=
 =?utf-8?B?bHZxeVo1UGFBM3J2T2piV0R2MEVsUGdjdW5lM2FrY2pZa3JwNXNOQW5aazF3?=
 =?utf-8?B?ZXMzS2o3NjdLT3UrdUQyRVc3TmlxV1I4V1JsMlVJbEJJcFR2WTZPQUZKY2FD?=
 =?utf-8?B?aFozZkpEYVpmbHI4RktKOU9lWFNMcis1bEk1VktSRUJBTE1IM2VURTJxTE8r?=
 =?utf-8?B?RUh0UmFTVkNiL2RrY0cxOTlTMWVpSW1kM05xSERhb2xZeWxpRk1GYTdITXRs?=
 =?utf-8?B?OERHNlBaZUp6aWYrMTJRSzE5M0FzN0Ewb2tTN0IyOGhHcDdGTEQ5NlRFcWZL?=
 =?utf-8?B?cWJGSUdkU3pzUElkcld3VndnT254ZHIzazJNYmJDcXJqQVNhd0ZXMkFCTS9E?=
 =?utf-8?B?ZTZTRkNzMTFjTFVzZU9QVklMcUtBRnRhYTA0MDFCNHRUVjlUM25BdVVYUTZP?=
 =?utf-8?B?Yngzdmt5S3dHSitpZmtMclNXVE9GcjcvSHYraG9sSXM5ZHpzaTVSU1NLY2F2?=
 =?utf-8?B?ejVLa244WWN5VUVRMHZXaTBWNDhnOFA5NDBuUkJVRGgxMVVodzJHQVg3UVc3?=
 =?utf-8?Q?YrYybL?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NFNMd2t1VnpScnVWQ09pTlFKeE9lNzVYYlJVRUdFcXcwUldNRFVmQ1piRjJ0?=
 =?utf-8?B?V2hSYlVBV0RRenQ5b1lnczVHM1RZVGE0Ynp5Ly9DNVM3Mm9VRWFmbnB3Wmlt?=
 =?utf-8?B?SWJpbmpJeHVIUE1PWkdQQ0RkMnFtMVFDMHVPN3E5NWVZWEswTHF2aHN4YnZR?=
 =?utf-8?B?cjVvanZtdEduZlppSzc0QVkwOVR5eTZxRHovNTBoOW0rTlE0aTlSTEdLVUJG?=
 =?utf-8?B?cFo0MkJjN1I0WlFIZ1d2N1hYYWl5ZFJOMWJCdHFMNmQrbjIyM0szbkJySndn?=
 =?utf-8?B?elI2a0c4eHhJS2xoVys3L3pCcTBpTkNHMGFkSjFUWFAyYnRHNmtpYjh4ODcy?=
 =?utf-8?B?NXorRGFwTkhNK2cvZWVsYWlPNUk3MFBmMjVmMCsxd3krYkNPWEpvRW9GK3Vs?=
 =?utf-8?B?K0VEeXluek52eUhQbDlLcGlyejB0TFo5c1lJbFpSdWNKbmVXc0hkNmw5S015?=
 =?utf-8?B?ZDFUK1BDa3RXdXZTZmpLQnB1OGhzSXRyWFZheGtqQ1hYRTZkeVE2d29oR2pE?=
 =?utf-8?B?NWZUOXp5b1NjRTl2L2hZWWcwVHBCZ1JrREJ3dXczM1JrRVhFUGFBSXF4anM0?=
 =?utf-8?B?QnoxWFJmWU14eVJIaXZxZkNGNTh1bFdQdVErdmdyNjlVN2R6YlZSVVpKRDRH?=
 =?utf-8?B?RVFhT0tDNktqZEkyYkxoeVJiZTB4YjRhUTFKUExmSUpiS0RIV21KaWxiL3dS?=
 =?utf-8?B?T0JVZmhYRC9IdXp5VmNHUFNlTzF5NUM1RXZ3YkxJaUFtSlZqT0FwMU00dHgy?=
 =?utf-8?B?M3p1UkN2M0JUaVRjOS82dTZSeHoyZVRYQjhTUS9EaXU4a0MzVzZJTVZTWUJ5?=
 =?utf-8?B?ViszdkJ4ZHlmdTlva09JTndsdzNnbGc2Sld2SmUzazFvWnliMTZhL283bDBa?=
 =?utf-8?B?SUxjMjRnQXp1TXdqZVR0elZjQ2RqZk9RbHRJRVZMVXVwV1hSckQxb01kNVow?=
 =?utf-8?B?SE5xak5DYWsyUFRCTEJQMldqS1dUbFNGZ2VsVWJoajRrODFwRlAzWGEwQVNa?=
 =?utf-8?B?c1krQWQwMUk3ei92WnZiZFFEaG9LbVRDb1VpQnpJU0ZhSjZiQ3VpTXFVbmNm?=
 =?utf-8?B?RzBpeGpYRFNXRDVmMEF0dXdIQzdWNHdnWlh3RUhYLzUwT01DZXQxQytaMWkr?=
 =?utf-8?B?VURqRkx2WEhPZURLU2NzVE5mL3YvTjJGRmhQRkNNVER2NjZJdkRnczFGQlRE?=
 =?utf-8?B?QUNkNUtKT2Q5YnAySCtiT3RGazV2SWk5NDNMZURMYTdaSUxxWG1CaGhRUlB6?=
 =?utf-8?B?Z1lhNHczb0dRNGZSZjRmR2xmdEhaN3NOZEF2R0JpczFDd3VDWWZ1MXlUWVp0?=
 =?utf-8?B?UWNoVzkwM29Da0FUR01ISGtIL1pRd3VSeEh5cStSeWhiTGFCazgrMHhXbVJP?=
 =?utf-8?B?cUZzVThRQzU3TDRkNDRFWXRXbE9mdHFzdVkzUjlvNGsrNENZRVhOaHQra1dP?=
 =?utf-8?B?WWRYUTNSb2dHTnFpKzEvMzJOZkZSTXVWL0MwQ1kzSHVGU2FFbG05clcyZkox?=
 =?utf-8?B?aDRRQWFGRnRBMnUyNUxXSU9KSUxhRExoQkY3U29rQVJ0aFVML2xPRU9TdWhp?=
 =?utf-8?B?STN3bzlxelFueEc1Qll4RTdXb05wR0p1S2s2bGUyZzZRZnBYVlNoRkVZWlJM?=
 =?utf-8?B?K0JCdVFIc1JnL3krdzNFMjZWUkdNbGxPa3RDZEFvbCtEM1ByKzdJUFNjYmox?=
 =?utf-8?B?bW1XUUtqZU93aDVpSGlWN1hjem9ZRTRITXp1cTF3QzExZUJ4dGlUdXJyaTRT?=
 =?utf-8?B?dm5tSXpkZTBPYkdVaGdMWmhPOFhmWWNnVHM5QlJoS1N6WWNDNnkzUUVST0px?=
 =?utf-8?B?Y1N0TlE0S2tQNFVlOUh6QWk3ZW5yUzBNU1pCT3ZKZ2tuTzBlSnVudFdHOVBK?=
 =?utf-8?B?TVZDRFdCaVVUWm9obEp3N3REYXdLY2paOU84QWRaeHpsTnBlWTdYQU1uT3B2?=
 =?utf-8?B?SURsclhFbnhtZ2FURUc3Sk9lakRMbmxKWjY2aUt3akdqVWQxR1BPdFVsaWwv?=
 =?utf-8?B?NlVLbk1YSkljZ0FmdGtwR21wZmI0OVlvSW9oRGRnN2tUZnVCZ05rbDZ5Mk9y?=
 =?utf-8?B?MGgxSXRmUldKWmd1VVFydWF6UVB6elByUHJ3ejdTbzFPWUVFdmY1OGlOMms2?=
 =?utf-8?B?Vmo3TjZWWFR5N3dZelhpU2YybWM1cW5uTXg1R2lKelBrMjVOMzYranlLT3N2?=
 =?utf-8?Q?6Q4YXkk9gvZ9bYe/vYh6jw4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <48E21748DECE694B96D819D90F6751A1@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: AM9PR03MB7025.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54bb312a-9767-49de-3f25-08de00128739
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2025 11:14:31.0284
 (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: uTXzH5m4NAWBcON5D/IPYR+FJaLjENVyeFA2FEz5YqhL+beFGMnNhwgUEOlXI5bnn/y3kfM5FHp1n0EoiOaKOEOEGuxEVkcCU9b0rTVD40Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10443

DQoNCk9uIDI5LjA5LjI1IDIyOjUyLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQoNCkhlbGxv
IFN0ZWZhbm8NCg0KPiBPbiBNb24sIDI5IFNlcCAyMDI1LCBPbGVrc2FuZHIgVHlzaGNoZW5rbyB3
cm90ZToNCj4+IEFkZCBET01VX1NUQVRJQ19FVlRDSE5TW251bWJlcl09ImxvY2FsX2lkIGxvY2Fs
X3BvcnQgcmVtb3RlX2lkOyAuLi4iDQo+PiBjb25maWd1cmF0aW9uIGZpbGUgc3RyaW5nIG9wdGlv
biBzcGVjaWZ5aW5nIHRoZSBzdGF0aWMgZXZlbnQgY2hhbm5lbA0KPj4gZGVmaW5pdGlvbnMgZm9y
IGRvbWFpbi4NCj4+DQo+PiBUaGUgYnVpbGQgc2NyaXB0IHVzZXMgc2ltcGxlIElEcyB0byBhdXRv
bWF0aWNhbGx5IGFuZCBzYWZlbHkNCj4+IGdlbmVyYXRlIHRoZSByZXF1aXJlZCB1bmlxdWUgcGhh
bmRsZSBudW1iZXJzIGZvciB0aGUgZGV2aWNlIHRyZWUuDQo+PiBUaGUgdXNlciBvbmx5IG5lZWRz
IHRvIGRlZmluZSBzaW1wbGUgbnVtZXJpYyBJRHMgYW5kIGRvZXMgbm90IG5lZWQNCj4+IHRvIG1h
bmFnZSBjb21wbGV4IHBoYW5kbGUgdmFsdWVzLg0KPj4NCj4+IEZvciB0aGUgZm9sbG93aW5nIGV4
YW1wbGU6DQo+PiBET01VX1NUQVRJQ19FVlRDSE5TWzBdPSIxIDEwIDI7IDMgMTIgNCINCj4+IERP
TVVfU1RBVElDX0VWVENITlNbMV09IjIgMTEgMTsgNCAxMyAzIg0KPj4NCj4+IGl0IGdlbmVyYXRl
czoNCj4+IGZkdCBta25vZCAvY2hvc2VuL2RvbVUwIGV2dGNobkAxDQo+PiBmZHQgc2V0IC9jaG9z
ZW4vZG9tVTAvZXZ0Y2huQDEgcGhhbmRsZSA8MHhmZmZmZmZmZT4NCj4+IGZkdCBzZXQgL2Nob3Nl
bi9kb21VMC9ldnRjaG5AMSBjb21wYXRpYmxlICJ4ZW4sZXZ0Y2huLXYxIg0KPj4gZmR0IHNldCAv
Y2hvc2VuL2RvbVUwL2V2dGNobkAxIHhlbixldnRjaG4gPDEwIDB4ZmZmZmZmZmQ+DQo+PiBmZHQg
bWtub2QgL2Nob3Nlbi9kb21VMCBldnRjaG5AMw0KPj4gZmR0IHNldCAvY2hvc2VuL2RvbVUwL2V2
dGNobkAzIHBoYW5kbGUgPDB4ZmZmZmZmZmM+DQo+PiBmZHQgc2V0IC9jaG9zZW4vZG9tVTAvZXZ0
Y2huQDMgY29tcGF0aWJsZSAieGVuLGV2dGNobi12MSINCj4+IGZkdCBzZXQgL2Nob3Nlbi9kb21V
MC9ldnRjaG5AMyB4ZW4sZXZ0Y2huIDwxMiAweGZmZmZmZmZiPg0KPj4gLi4uDQo+PiBmZHQgbWtu
b2QgL2Nob3Nlbi9kb21VMSBldnRjaG5AMg0KPj4gZmR0IHNldCAvY2hvc2VuL2RvbVUxL2V2dGNo
bkAyIHBoYW5kbGUgPDB4ZmZmZmZmZmQ+DQo+PiBmZHQgc2V0IC9jaG9zZW4vZG9tVTEvZXZ0Y2hu
QDIgY29tcGF0aWJsZSAieGVuLGV2dGNobi12MSINCj4+IGZkdCBzZXQgL2Nob3Nlbi9kb21VMS9l
dnRjaG5AMiB4ZW4sZXZ0Y2huIDwxMSAweGZmZmZmZmZlPg0KPj4gZmR0IG1rbm9kIC9jaG9zZW4v
ZG9tVTEgZXZ0Y2huQDQNCj4+IGZkdCBzZXQgL2Nob3Nlbi9kb21VMS9ldnRjaG5ANCBwaGFuZGxl
IDwweGZmZmZmZmZiPg0KPj4gZmR0IHNldCAvY2hvc2VuL2RvbVUxL2V2dGNobkA0IGNvbXBhdGli
bGUgInhlbixldnRjaG4tdjEiDQo+PiBmZHQgc2V0IC9jaG9zZW4vZG9tVTEvZXZ0Y2huQDQgeGVu
LGV2dGNobiA8MTMgMHhmZmZmZmZmYz4NCj4gDQo+IEknZCBsaWtlIHRvIG1ha2UgYW4gYWx0ZXJu
YXRpdmUgc3VnZ2VzdGlvbi4gVGhlIHVzZXIgc3BlY2lmaWVzIHRyaXBsZXRzOg0KPiBET01VX1NU
QVRJQ19FVlRDSE5TWzBdPSJsb2NhbC1pZCByZW1vdGUtZG9taWQgcmVtb3RlLWlkDQo+IA0KPiBU
byBnZW5lcmF0ZSB0aGUgZXhhbXBsZSBhYm92ZToNCj4gDQo+IERPTVVfU1RBVElDX0VWVENITlNb
MF09IjEwIDEgMTE7IDEyIDEgMTMiDQo+IERPTVVfU1RBVElDX0VWVENITlNbMV09IjExIDAgMTA7
IDEzIDAgMTIiDQoNCkkgZ3Vlc3MgYnkgc2F5aW5nIGxvY2FsLWlkIGFuZCByZW1vdGUtaWQgaGVy
ZSB5b3UganVzdCBtZWFudCBsb2NhbCBhbmQgDQpyZW1vdGUgZXZlbnQgY2hhbm5lbHMsIHJpZ2h0
PyBJZiBzbywgSSB3b3VsZCB1c2UgbG9jYWxfcG9ydCBhbmQgcmVtb3RlX3BvcnQuDQoNCg0KPiAN
Cj4gSSB0aGluayB0aGlzIGlzIGJldHRlciBiZWNhdXNlIGl0IGRvZXNuJ3QgcmVxdWlyZSB0byBp
bnZlbnQgKHVzZWxlc3MpDQo+IHVuaXF1ZSBudW1iZXJzIGFzIHJlZmVyZW5jZXMuIEluc3RlYWQs
IGl0IGZvY3VzZXMgb24gdGhlIGRhdGEgdGhhdA0KPiBhY3R1YWxseSBtYXR0ZXJzIHRvIHRoZSB1
c2VyOiB0aGUgZXZlbnQgY2hhbm5lbCBJRHMgYXQgYm90aCBlbmRzIGFuZA0KPiB0aGUgZG9tYWlu
cyBpbnZvbHZlZC4gVGhlc2UgYXJlIHRoaW5ncyB0aGUgdXNlciBtdXN0IGtub3cgYW55d2F5Lg0K
PiANCj4gVGhlIG9ubHkgY2F0Y2ggd2l0aCB0aGlzIHN1Z2dlc2lvbiBpcyB0aGUgZGVmaW5pdGlv
biBvZiAicmVtb3RlLWRvbWlkIjoNCj4gaW4gcmVhbGl0eSB0aGUgRE9NVSBhcnJheSBpbmRleCBp
cyBub3QgdGhlIGRvbWlkIGluIGRvbTBsZXNzIHNvIHdlIHdvdWxkDQo+IGhhdmUgdG8gY2xhcmlm
eS4gTWF5YmUgd2UgY291bGQgZGVmaW5lIGl0IGFzIHJlbW90ZS1kb21haW4taW5kZXggb3INCj4g
c29tZXRoaW5nIGxpa2UgdGhhdC4NCg0KSSBzZWUsIHllcyByZW1vdGUtZG9tYWluLWluZGV4IHNv
dW5kcyBjbGVhci4NCg0KDQo+IA0KPiBXaGF0IGRvIHlvdSB0aGluaz8NCg0KSSB0aGluaywgaXQg
aXMgYSBncmVhdCBhcHByb2FjaC4gSSB3aWxsIHRyeSB0byBpbXBsZW1lbnQgd2hhdCB5b3Ugc3Vn
Z2VzdGVkLg0KDQoNCj4gDQo+IA0KPiBJbiBJbWFnZUJ1aWxkZXIgc28gZmFyIHdlIGhhdmUgbm90
IHVzZWQgc2VwYXJhdG9ycyBsaWtlICc7JyBoZXJlIGJ1dCBJDQo+IHRoaW5rIGl0IGRvZXMgaW1w
cm92ZSByZWFkYWJpbGl0eSBzbyBJIHdvdWxkIGtlZXAgaXQuDQoNCm9rDQoNCltzbmlwXQ==


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 12:10:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 12:10:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134223.1472194 (Exim 4.92)
	(envelope-from )
	id 1v3ZBy-0004H3-4M; Tue, 30 Sep 2025 12:10:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134223.1472194; Tue, 30 Sep 2025 12: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 1v3ZBx-0004Gw-UI; Tue, 30 Sep 2025 12:10:49 +0000
Received: by outflank-mailman (input) for mailman id 1134223;
 Tue, 30 Sep 2025 12: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 1v3ZBw-0004Gq-Ae
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 12:10:48 +0000
Received: from PH0PR06CU001.outbound.protection.outlook.com
 (mail-westus3azlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c107::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7e6f90cd-9df6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 14:10:47 +0200 (CEST)
Received: from BYAPR07CA0054.namprd07.prod.outlook.com (2603:10b6:a03:60::31)
 by CYXPR12MB9388.namprd12.prod.outlook.com (2603:10b6:930:e8::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.18; Tue, 30 Sep
 2025 12:10:40 +0000
Received: from SJ5PEPF000001F2.namprd05.prod.outlook.com
 (2603:10b6:a03:60:cafe::47) by BYAPR07CA0054.outlook.office365.com
 (2603:10b6:a03:60::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.17 via Frontend Transport; Tue,
 30 Sep 2025 12:10:40 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Tue, 30 Sep 2025 12:10:40 +0000
Received: from localhost (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 30 Sep
 2025 05:10:39 -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: 7e6f90cd-9df6-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bbwA2LS2DSQFN6qd6/yGX1kCyL5rLd72jdwlsp4HQsRYtBm68s5G+DhlvhJsF8rJ6T5ZnpPIeX3jyG/eRVr7jkvOAUiGI7Zj0au71WwFIkB/QgXgWfaYCsH8rN9NwYTyDHh9SNFk4Wz25gxIJtA8Fi1C/RJ0UwZNKBFOL/IB/xFt+qkrMYuUBoyzbh0YpvIOV4iWE51ws4xf5aLMJh97dA3sDsqVYlzoqoAp1jwnPbF0RgB/CI5POwwXrswK+/8B5+M5NIsoWACsKNTjYwKxvMYHnuvtMNnBX10i4KAx2NdhsFcrKiFsfvYr+yF0Up1m0tEJPt4wUByG0i3FoY4byg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=C5BjB6WmfOKtawsjUtZVDnZSAImvsiUyn+Twwdywo2E=;
 b=Uiaui52hDSIkg4blT3TXtdqmmMHem7OMDmrUg6TPzarZFYyvBLmSU6muVUJGXkZBcT+TYHtnJq3Y7+d0rGJP9P2nZeTfExExRYKS3tHri1gOessByurwBYgslCaCxtso56u9Qy6kg1Q5cHA6x3kmEy/ia/UqTq8cCXtgvY0bI3FFoRFniTCMIeqtvCsEpH0GguM6S6wn2GneE23CNMepPj37nOkHFbew+eeFyYBzWr7n86lMxSnwyLbHfAoUR27qBssBI5ICaKSe+DkJOQBRRZeF2U7cE9Vm6zejQY+GYEjz9hpc2Vug800CE10ZP+G551ZDkIRp4xrJjZ+L/Duosg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=C5BjB6WmfOKtawsjUtZVDnZSAImvsiUyn+Twwdywo2E=;
 b=5BsaQ8Dl7zN/aCGGuRfUxyjK11NwJnpba1PCrWldY09uCTNdfIIHWdDfQ2+bGL6RZ741AH4wFI+N0ba9BBO8GpQ+vuUkdFk1M48oMtaMwqf5no8yUFUFnAo5orj5cklda9R4TgcZW6hw9DoETNVFFdQIQWY7efhBLBJlCnBBh5s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 30 Sep 2025 14:10:37 +0200
Message-ID: 
Subject: Re: [XEN][PATCH] x86/hvm: revise "cpu_has_vmx" usage for
 !CONFIG_INTEL_VMX case
From: Alejandro Vallejo 
To: Grygorii Strashko ,
	"xen-devel@lists.xenproject.org" 
CC: Jan Beulich , Andrew Cooper
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	
X-Mailer: aerc 0.20.1
References: <20250924101417.229108-1-grygorii_strashko@epam.com>
In-Reply-To: <20250924101417.229108-1-grygorii_strashko@epam.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F2:EE_|CYXPR12MB9388:EE_
X-MS-Office365-Filtering-Correlation-Id: c4cc4599-6bd6-4825-b25f-08de001a5f9f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SytFblRYTGhYampHbTdvK2xaVUdXdTN0V0JjWmZHTWNmWTVEd1lPWWVCOUwv?=
 =?utf-8?B?bG5zYmNyWFU4eUhCdEpDTjZEdkxiWmpPOTJ6YWRtN2FnU0lFa1UwQis4RlhQ?=
 =?utf-8?B?OW1HU3ZVcktJK29laGkxVHFKTnZDZkhBaWNtdjBreldmQVU1TlFXWldhNm1n?=
 =?utf-8?B?R3dJc0Z0SUZySFkrSGpWNE5UWEJaSUhJZHFORkVHTFdzYzAzSnNkTkdOQ0t0?=
 =?utf-8?B?WVY0aVBEdHh2TTNsVWZmVFRpQU9kYUdkQjRpWmJyemdJMHF4akZMQWlkR0sv?=
 =?utf-8?B?b3NXUXNlM05hV05VRTNYWERRdHpuUjBOS3dnK0xhN2JDRzE1L0lHbis2Mm5N?=
 =?utf-8?B?d0U4MHlvWFNKSVJUQkh2WFRMWEk5VFBoRUVQVW52WXhUQnNuWHFSZStENENJ?=
 =?utf-8?B?VDU2MGtHZkwzNW1JTVpQV2V6NkZvS04ySVV0S2FlZkxVZUhPeWc0MDdZejlz?=
 =?utf-8?B?UDVrMC9vZWFQZm1QQzFOMHZ2ekhkWUtueUhtWHBuZEVxc0ExV1ozRUtvWndr?=
 =?utf-8?B?ZU5ieHV1K2k2Y0ZrTkh3TzR6RE83VVhEekE3dGR0bVZZZkhyakpUZzRjRTRm?=
 =?utf-8?B?eEtLWmhLREJuQTFOL0ZkU0FtS1dFUTNueTRjTWN6VDFxTWh5MytwT1dyaHhN?=
 =?utf-8?B?Y2hWeTA5UU5PYkxXTEYzYWN6V3JMZmVqemVlWk9DRXZSWXYwRFExTDdXbHFY?=
 =?utf-8?B?RktDanh5NlgzK2J3bVN6R3JRclNuUG9kc25vWk1oa0hnYVpKdG1aREw0SzBj?=
 =?utf-8?B?RWM1bmZZZ1FMOEpWTUx6OFFESEpiL3h4bnhGVUlOTE1nVy9VU3czdzZITlJ2?=
 =?utf-8?B?aC8zQkNML0xFRGU1NTBKb2lJWE1QN0F2MEc5cVU2Y0FTWUZ2c3RrZ05TanZF?=
 =?utf-8?B?NjFJeU9pVURwLzBudWR3eHRsYkFZdVl3Zmh4L1orS2QzOXplMFMwOVg3bDgy?=
 =?utf-8?B?OVZ0MTlvUldCWmRLMUVQYU1YUkc4SlZHUlIwSVRtRm5BT1p0V0ZxeUFoSUZn?=
 =?utf-8?B?SGluVnd6eVBRK1BrTjNHMGdhK0RjL0MxVy9adXBlVHQ0YnpZQXJjYTBybHFM?=
 =?utf-8?B?OFlpOUo1MlhtZGJYTmlUSnpFcW1nbTM3ZlhOMjZXcytoYUdDQ0pFMGtQMWww?=
 =?utf-8?B?cmFJamdxcVNnNVllK29qQXlTTUNCeDdFR3BVV1g4dG8yb2o4OHBoZ2ZzRFNa?=
 =?utf-8?B?MFI0TnZwL2lQb0kzeG5IdHE5c3hjc2JGS1QrMU9aOEVkTmRnQ2ZDSTZuN1Jx?=
 =?utf-8?B?Q3ZRYldsZmJ0RE4wenM5R2N4NzUrekM3dFJ0eWw0clp5akc2RklnTTJ6cC83?=
 =?utf-8?B?aXBCVkFvWGliZU9Vd1UxdndFMElEa0wrampDbFdIaHdSdm1zWGlVT3NqMy81?=
 =?utf-8?B?WVpkZ0VsVDArNm1ockQ3aVZwdmRSbVdUbGVYT2ttYUpiWVZ3Sm5TREhFT0lM?=
 =?utf-8?B?SWpRblRnTVRNYWtTWlVqVXRCK2pySXJGSlpoc0w3eXhXVlhxb2VFQ0lIaFpl?=
 =?utf-8?B?R2hJU2xIV0Q3aCtJVTJ3akNoU1lIMnF3STEraHZVZGlqbTl5OENEZG96aktl?=
 =?utf-8?B?aFczTkxkV3JtYXBLemloZjdPMURkMVNKaGY0VVlRa0IzdnFMSXBKRndMSGRY?=
 =?utf-8?B?MVR4eTd1UndNSjRHbWdRa0ZFVW0wS21VN25YRmpEdTk2RzNVQWgzRUo0Z2hH?=
 =?utf-8?B?QnBTUTEyempEdm8yL0tjbnNiNWlXNEFwS09XVGo5d0p4R1F3cytJQjRwM0Zl?=
 =?utf-8?B?cmtTOGhURENsWS9UMDliWEE1WXVxdEVpSFRmcWxiVHY3SC8zaW5ObVc2REs3?=
 =?utf-8?B?dXBGR3dWY2ZCOXE5TkdXM0RXOXBnZWZCMmFHWVQ5aE5Bbkw3ejFKcGVFK3Fx?=
 =?utf-8?B?RWsyZ1JCYnBSOGE4Y24rK0ExUnZIamNpU3VHL3B0ZG82aUFaR0M4b2FhNEQ1?=
 =?utf-8?B?VDZkcC9MenNGTXJIeDBpbDN3UytVNlhIbVp1T25zRlYxWmJmTnlHc0lLczN1?=
 =?utf-8?B?R1JYN29LZnkxVG9ISFdOYWZPOEhhTWlYL2ZnQU5USnlaTmRibjRKZlM3MkJy?=
 =?utf-8?B?WVB5MjJPREtUQkFjWHhnMkttZ0JCaVFOSmd0UUtWV1MwNmVFQ0N1VElWTzY5?=
 =?utf-8?Q?kyzg=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2025 12:10:40.5312
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c4cc4599-6bd6-4825-b25f-08de001a5f9f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9388

On Wed Sep 24, 2025 at 12:14 PM CEST, Grygorii Strashko wrote:
> From: Grygorii Strashko 
>
> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") t=
he
> HVM Intel VT-x support can be disabled, but it still keeps VMX
> code partially built-in. Particularly in HVM code there are two places:
>
> 1) hvm/dom0_build.c
>  dom0_construct_pvh()->pvh_populate_p2m()
>     ...
>     if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) =
)
>     {
>         ...
>         [unreachable for !cpu_has_vmx case]
>         rc =3D pvh_setup_vmx_realmode_helpers(d);
>
> pvh_setup_vmx_realmode_helpers() allocates memory and configures
>  HVM_PARAM_VM86_TSS_SIZED
>  HVM_PARAM_IDENT_PT
>
> 2) hvm/hvm.c
>  hvm_set_param()
>     ...
>     case HVM_PARAM_IDENT_PT:
>
>         if ( !paging_mode_hap(d) || !cpu_has_vmx )
>         {
>             d->arch.hvm.params[index] =3D value;
>             break;
>         }
>         [unreachable for !cpu_has_vmx case]
>         ...

nit: These (1) and (2) are rather large for a commit message. I wouldn't mi=
nd
if they went away and the rest of the commit message was adjusted to make i=
t
a bit leaner.

Either way, with or without this change...

>
> Hence HVM_PARAM_IDENT_PT/HVM_PARAM_VM86_TSS_SIZED are used only by VMX co=
de
> above code become unreachable in !cpu_has_vmx case and can be optimazed
> when !CONFIG_INTEL_VMX.
>
> Replace "cpu_has_vmx" with using_vmx() to account !CONFIG_INTEL_VMX and a=
llow
> compiler DCE to optimize code.
>
> Signed-off-by: Grygorii Strashko 

... Reviewed-by: Alejandro Vallejo 

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 12:11:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 12:11:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134230.1472204 (Exim 4.92)
	(envelope-from )
	id 1v3ZCT-0004ic-GV; Tue, 30 Sep 2025 12:11:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134230.1472204; Tue, 30 Sep 2025 12:11: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 1v3ZCT-0004iV-BX; Tue, 30 Sep 2025 12:11:21 +0000
Received: by outflank-mailman (input) for mailman id 1134230;
 Tue, 30 Sep 2025 12:11: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 1v3ZCS-0004Gq-1f
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 12:11:20 +0000
Received: from mail132-16.atl131.mandrillapp.com
 (mail132-16.atl131.mandrillapp.com [198.2.132.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b0bc642-9df6-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 14:11:07 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-16.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4cbcN96f75zB5pQln
 for ; Tue, 30 Sep 2025 12:11:05 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b5a69f1d6e7546c9a4382d1862fc4234; Tue, 30 Sep 2025 12:11: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: 8b0bc642-9df6-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1759234265; x=1759504265;
	bh=83ZLDzu48SQMzbwyIInIAjLwAJRjMElgY51Xi1AYFGc=;
	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=ywsTRpx+e76zfRkAKwD25i3fPgVWP/5uj/d4M/J57hBjszUJA5QZ/0VYe3gNAQCjX
	 2UUEohPqQ+zsZUTkD+NwvSvTTksjKfccfGwcKX5aNeonNJufGitM8DLyqOmaAM3Hp1
	 a3my5/WR+lAaf4oNKj9LYzjF8aoBEXVVhQQM/dmXLXmqg5PmRhYneGw+M1qFyHkiyg
	 aVRFZLbVJgyT4pakvH8hoqr8b6fZKwb0VVpDQKTZTV9/D7a4gHe27V1FrVmsCF9Lz9
	 fsT4lMk8YGP517rkxrUCDi43eLqbYq+notCE36duL3Qegamb4ozV3dtleGApeIiUDc
	 QLaHTrfPIHfuw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1759234265; x=1759494765; i=teddy.astie@vates.tech;
	bh=83ZLDzu48SQMzbwyIInIAjLwAJRjMElgY51Xi1AYFGc=;
	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=WshO0K/7YlVHWTh9XOXQqfCh/zCSjX9C6HsKHyrIKL00A24G3VWT//wQ5EzStGfsT
	 RQzYnCczBwnHA3E4aWEhXEmW5vTM1GPwqY6uhsra/+4y3VLMgNiSEfSyVeya3zht82
	 J27h3LiGH/5NJqYEqDZNE/jxnponiZ98Uv71Oa9SiV+j7JEAZk6GhTZ7fTqp5nh3PT
	 8pA3qJE1h/dlEYuldpfUfohTRU5NwK7MrBkTGps+kQYMfwkNAXBDuNf/XELweFRaAL
	 5nSMyCcdJYK++ZaZ6iLqTW6jCn+4l3SJX2aJgixjInDkzUe5TPtKZ26/zizo4Pwg2b
	 0ppGIXvfKN87A==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20x86/hap:=20Inline=20"flush=5Fvcpu"=20in=20"flush=5Ftlb"?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1759234264943
Message-Id: 
To: "Andrew Cooper" , xen-devel@lists.xenproject.org
Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
References:  <45afdc14-7337-4786-b3ff-e3c07a6b5f71@citrix.com>
In-Reply-To: <45afdc14-7337-4786-b3ff-e3c07a6b5f71@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.b5a69f1d6e7546c9a4382d1862fc4234?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250930:md
Date: Tue, 30 Sep 2025 12:11:05 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 29/09/2025 =C3=A0 21:41, Andrew Cooper a =C3=A9crit=C2=A0:
> On 29/09/2025 1:36 pm, Teddy Astie wrote:
>> flush_vcpu static function here is only used in one place which is just =
below
>> where it is defined. Inline the function to reduce the noise and clarify
>> what we are doing.
>>
>> No functional change.
>>
>> Signed-off-by: Teddy Astie 
> 
> Have you read the commit message introducing this pattern?=C2=A0 It's
> 11d9e114b53045e5f2009a26dad1d0d0f7df441e for reference.
> 

Yes, and while it makes sense in shadow paging code where we use it 
multiples times; it sounds to me a bit too much here to have such 
function just used once.

> The compiler will do the sensible thing.=C2=A0 What matters is the cognit=
ive
> complexity of the source code.
> 
> ~Andrew
> 

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Tue Sep 30 12:46:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 12:46:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134248.1472214 (Exim 4.92)
	(envelope-from )
	id 1v3ZkY-0000id-96; Tue, 30 Sep 2025 12:46:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134248.1472214; Tue, 30 Sep 2025 12: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 1v3ZkY-0000iW-5O; Tue, 30 Sep 2025 12:46:34 +0000
Received: by outflank-mailman (input) for mailman id 1134248;
 Tue, 30 Sep 2025 12:46: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 1v3ZkX-0000iQ-5J
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 12:46:33 +0000
Received: from CY3PR05CU001.outbound.protection.outlook.com
 (mail-westcentralusazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c112::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c2eb421-9dfb-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 14:46:30 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by BY1PR03MB7899.namprd03.prod.outlook.com (2603:10b6:a03:5b7::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.16; Tue, 30 Sep
 2025 12:46:27 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9182.013; Tue, 30 Sep 2025
 12:46: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: 7c2eb421-9dfb-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xNh5Dd3QIaDxaTyrQRCaRDENMgnQ1HnVA9YECJKT9Uv7nbAhoL83EkzCNRKKK1v/AHwxymjBuxjC7V6TDXNRP/tKYZ5w0UlE4/p/THVo/NiBBs2CzVGSUmhyg0FjCGkAnHgB5F3gNTO6/ynm+L7vPH+gtLBqSWgDTh4xqhUFPgNbAjnHq+sOOIaTio+nq6pLFgdBPFjswgmbTX4ymugttDWrMUx+kTxjQlGsf9/t3Rzv6TEjoIw6IFOao4B8bMnZpov7SuAZTjOJ9Gd2l4VydNxlnVUyD/H4kkoNQSQUkw/eo+E226GBk4d/R8Gt60pU0PQky2WQgJ5yho4LlBmV3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+wkdnTpNqw2KP2OXyslMwiuzgi1mnibIijhJNskeqd4=;
 b=MtHvUlUIoHGJxHKDmAxuHzmwfo3lOHEUpuM3FOEmJjSP8NIFSaUweUxPMLnROOkSLYUWi/n/oCv627zdLfGN0acWAIsNGmlZHIiAvBudyzhUTigFJbaR4AGx3J7uxGFw1YKcwJCekhPF0f0gz0SfqY47UU0tcWn0ZgMlkfQJZQ+lq19aWWykNmblU6t4ctQrLzFK0SvJBXhMEJFASB7+MaV1pOGk+H7NtZxSYIBuXJAU7SQd9ddyP/UcTf7y14/7XLGX/XmAp20RnDyDxgoYlOIE/2dxThOPEEcyhHzaqdjnrdz1QFJJa3yq2jd129blIvieldYDGjA8H9dScLECHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+wkdnTpNqw2KP2OXyslMwiuzgi1mnibIijhJNskeqd4=;
 b=SHHJmM8mIEYhPnH/6r2x4k91eMeaJZFf4nUg1HBj8EqMeJyx3mA0bZnUzukUJ8Hzz5Hs8FmjtF+OQp8YMkBq+zGb88OQw3FgIJOeYgrtUAl63hsRlScgbCSYdpXP6DfBiCQDOcyprx4EVwFFkianeIC6VHJMKHT54GKGiuXBFFo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Tue, 30 Sep 2025 14:46:23 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Oleksii Kurochko 
Cc: xen-devel@lists.xenproject.org,
	Stewart Hildebrand ,
	Jan Beulich 
Subject: Re: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X
 capabilities
Message-ID: 
References: <20250929084149.70560-1-roger.pau@citrix.com>
 
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-ClientProxiedBy: MA2P292CA0030.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::7)
 To DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|BY1PR03MB7899:EE_
X-MS-Office365-Filtering-Correlation-Id: c010cef2-f598-40c0-c46b-08de001f5f01
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?dEwrQXNzYzliN21KK2dLMkZXTmpZT3lkYWovVU5yYVFwRE9GUmxZQVIyWUVX?=
 =?utf-8?B?NjBLK29CYW5zNXl0WUdCbkpDdDR5KzVEenVkbmxDVFhkYWE2a2czZUgzM3A2?=
 =?utf-8?B?dDF6d1ZRclFxeWJ3b2lOeUZoTXp5OWFvTkpTUzBUTmVqQ1EwZkVtUjZGdWlm?=
 =?utf-8?B?N1dLRC85UVU0VHdDM1FWSTZwd3lLZVpOTEFxalRHSk96L0ZzZDMxVjdyZk9K?=
 =?utf-8?B?eTR3dXVRclBXN3hpd0VhckZGUjM2OGRwTlBZczRkRHVoS2RITjNabFhlTkJK?=
 =?utf-8?B?VG9uTlFidmJsK3d6K2dLV2l4dVhWRHBQVDN5d2ZYVnFmMWdLblcwZG5scW5P?=
 =?utf-8?B?ajNRNU1Ob1Fra0lMc1pZalg3Y2I1Z1BHNnN4UnFDWUpGQW9YNG0vMmNjNW51?=
 =?utf-8?B?Y0RneTBRWmRzcjNLOFFlZ2lWYlpmV1Vxdmdva3p1bWc5dXBMN01PcW14RDhI?=
 =?utf-8?B?dysva3pIVUoyb3Q0K3RKUWNLOVZzb21BMHV2N0RkdThhSkZvaEcrb2hPM29R?=
 =?utf-8?B?RG5kRkVraDFqY1dpcnd5YkhmT0s0dk4yNThvdkd6MUk3eThDQWFPcTdyVEVQ?=
 =?utf-8?B?UjUyV3R1RXp3TFdocEtmNW90aHdnOEVaQmdGM2tzdVVWZHdWQ2FDNFVLSC9s?=
 =?utf-8?B?dkRTWHVoOHV4Uk45S3BLVkQwdWp4YnpUYVB4TTFlMTJCZFFQUDR1VmNqQWpE?=
 =?utf-8?B?TUJjUy81UTZXNy9Od0JwMDAwRG5xQjRIZ1F2MnAwTGljSk5kd1p6cHhtdndX?=
 =?utf-8?B?OUh6a242VEJZaThPeXVEUDNTWFEweVM4OEtQbzNTQ2xVSEZOZFNZeVBnaTFm?=
 =?utf-8?B?TmRDVzQyYmhuNmxkNVdSNnNqNmRJZDRqdUkxa3ZiRXkrVWdob2UzRkhoMEo2?=
 =?utf-8?B?UzZPNU4xTTNVZzJyYy81OVVOMWNxbUNWc1I4YjdHYW8vQzNWd2s3MVZuV0xT?=
 =?utf-8?B?Yy91QnlQUzZ1bXJQYUc1VnFFK2JEN3ZLV3kvRDJPak1QeUh1d3YvM2k3U0ZU?=
 =?utf-8?B?am9CdVFJQ3lPc3dOUC9pTWxuWDZvdzN2WEFzbGo3NzZFWlczQlQ1RDNCZkdv?=
 =?utf-8?B?WGlNeDVWM0xZVTFONitlWWRZRDljQXQvNXlCTlA1QTRlbDhqYXltMzZYUVR3?=
 =?utf-8?B?TEpwTjF1RSs2bzYvQ1R0aWhadXh6MU9PTG91c2JzL3NMR3dBSUVWOUdMVjJm?=
 =?utf-8?B?SEk0YkY3OFNreGJuWWRUc2VPNDFrajR2a0dJWE8xaDJSZ0xaMUh6QTc4WlFv?=
 =?utf-8?B?UGdkZzhFNlE2RWwyb25XTU0wdjFrS0c1V3FqVHZqYUdLTjFjMys1b0ptQUVK?=
 =?utf-8?B?NCtFMzNDTWpzMFBuVWVkYW5QcVh5blBpbFhVNzFNdkxCMmd2WUdwN2lNdkJv?=
 =?utf-8?B?SkRZblY4U3lEZC9UNE9SSERLbXpaL0FOVk9tdlcvQXpVTGhWRGtWN1FCOWxT?=
 =?utf-8?B?QVlDTHVIU0NXdWZjNUNrV1E1VnNKcmYyalNCUVJFYnlQY08rdWJDY2QvWWpM?=
 =?utf-8?B?ZzQ4WVhqcFdoSHVqLzJodHpKN3VFRldLcGZ3dE9Iay9nTGxJdEo3YW90SmZT?=
 =?utf-8?B?dDJUQ2dsUWlqbFljY1hVYXYzcEsvSVk1eGpqRW9oZDArTWduVnFvNk8vL1R5?=
 =?utf-8?B?bi9UMExvWjBmNHpvWEw3bUdrTU5VYTU5d00zZy92eE9CVlAwVDAzRGwwSGs2?=
 =?utf-8?B?U2dWSVBQc25lRmpoRUY4QzFHRmtWVzZIR01kRlRlVnZGWVFpeDJSWDhIWExR?=
 =?utf-8?B?dzRuL0d0TDY1ekNIRjF3ODQxZC9JY0FJWTNUZEFFUXZPUFF2MTVYWlo1SHVy?=
 =?utf-8?B?WHptOFF3OExhd3JIekZ2Zk9VS0JHSGtOaGpoTWhtQzlqbFVUemlTRnd6U0li?=
 =?utf-8?B?eVpGckhnYnNJSExRcGgzSm9JYThrVlRKbFFaN3ZtelRTVG1vbFhKd3lXWTI5?=
 =?utf-8?Q?EiNGy2hsugQ6L/ZsiHsnSM1V/qpjErvn?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QWQyNy9SVnhCcERta0NFR3dHOXhNTWRaTEtQd2tjRDZjTk85N2w0bWdOVG5H?=
 =?utf-8?B?WnFpMVB5NStVN1NqdWIzQ1gvUzRMUWJvTFhNaGVxUUhOT01hdks1UDIvdWNp?=
 =?utf-8?B?Ri9qRUMrTWl6d3pQNUVYRm5tclVNaWN0Z2V4VGJPMDRwZ3l3Z2t4cVNxNG5i?=
 =?utf-8?B?TjZreERiS2EzT3pSek40aVExUlRpZitkT0NLREhCODlhQjJtSzFYQTZmaTlG?=
 =?utf-8?B?UzNKTXhsY0dRS3E0SnE0bkRDMy9Pc0trL1hENWVCeDluV1dsTGh6REFqK1Ew?=
 =?utf-8?B?VlVlS1o0bUVYblVaUlNTUXRDc3BzRDlQc216ZDBSQmgwQlFCQWVtekVLSTUr?=
 =?utf-8?B?RkVqeDRsSTlkRy9qaTBKandOQ2NjK2xPTWRoWjZrSWtOL0tUMzlvZ21takdo?=
 =?utf-8?B?VnZIdkYzVkwwY0txaWg4RXA3SUpGUTg2QTVvblBuSjFhWExSbDg5RDNUY2Fl?=
 =?utf-8?B?U2c2enNCbUx3Qk9sUUNtQnBIbnZVc2hlZ0YwcS9NRnZnQTh0WFJyZm5YdGw0?=
 =?utf-8?B?Szg2SVFFNzZIa0VYODV3RDZUeVBoSWtZOGlnQ2htTlZRMGtyUGtvb2VhdEVE?=
 =?utf-8?B?R3VEMkVjZmFXOXFaYjRpc2M1Zi9HTFVVdENvT2puanpyeW1RYlVFM1BkYW9p?=
 =?utf-8?B?L004M3NUdkJDa2xxaW45eUJqQ3YxRGlERzgwVzZJMStWODhldElXbDdmQld0?=
 =?utf-8?B?eHdhSmJ2OUtSNlhPdUpxOUt4TEw3aVNBaHVFbU5zVWw2UU85bGgxZitGdmRJ?=
 =?utf-8?B?NzJXUmpWZnhHbXltYlJBdFd5dFAvbmkweVNMdjhqU0tuSWk2Q01Xd1Q1T1BX?=
 =?utf-8?B?K2pUMkJ2L2hiOWFHaU9HZStsTGxFdUE5S0hpTjNjNE1QWjJEcUJaZmVtUXVU?=
 =?utf-8?B?bjRCcCtuZ1pRaW9CZVZneWo3VDRld0dJQkNLWmpGSGpIMFV0bklEV2lvdVg2?=
 =?utf-8?B?ZHBOdVMrVUMrdFZvZmlXbkxrUWVwMXhma3gycTE1Tnhsd3NIbDVOZmpJWmRy?=
 =?utf-8?B?MU8wZXZndk1KOEM5WjVQRlZoQ2d1c0d6NldvTlJyQnhOQ01yVDlNQmdSbkF2?=
 =?utf-8?B?VVRmMWhOOHM2OC95K1NpRGVSM3dockxsRmFqak1VSU84bEl4a2E5WXlBRUl1?=
 =?utf-8?B?K0tzclFnbHg4bUFNSm1FR2htY29aQ254Smw0bHhPdjkyNEk2bU4yRjhnZzFO?=
 =?utf-8?B?VFM3U0RZSkxPaGkrZ2FTMVlHdElBNkRBV2xSVjhDUTRZUlBqMERjYU9kUHQ5?=
 =?utf-8?B?aXgvaGRYdCtObmZaS2JmUzR4b1pzbVB2K3BHYWxOaUFsV3c5VkFmZDRtNHNX?=
 =?utf-8?B?T1J1SDhuTSsvdlFMb0hlV3NWbGs2UzlPM1U3VG5NS3VyUFh2OVAwWlpRc1My?=
 =?utf-8?B?Vm1CR3l3djFEeStua3ZUM0ZUbUpKdUFWMW1EU0lyT1NHRzNPTHpnamU0NnJz?=
 =?utf-8?B?YWYrMUtialBlVGdSZmpaVjd4RHRuaGhheFh5VjMvaFFuWFBzQW1aRVJ2alQr?=
 =?utf-8?B?Z2ZsdGtRL0g0akZqVG9BeGZOaXpscnMxa0lPaTJFOS9zM05HYVRUUktaV25z?=
 =?utf-8?B?RlNtOXdKZm9NS2Z5eWpGMDYxbnV3c3hsN0xHbG54cEQxUERZTy8rVENHYm9Y?=
 =?utf-8?B?Zmw3TzB4TTRaUXFMZFdpMlhaeEtnQ1lpY3BvZ1ZubDdKU2k5OGNscnRMZjF1?=
 =?utf-8?B?empXbU5XeC9OVUkrUG8rYml4TVZyL0pGZ0lqdU55dGdGVTk1cktKZ0trWGJN?=
 =?utf-8?B?eThvYVJFRURBZE5zcUIreUY3SWVkVlN0TXhDZEI4WVpvZXVQYTMwbndaSEhu?=
 =?utf-8?B?VjhSbi9RZXNUYmsrblhXbXpjdldBWFIvOEtBMDMxTERzc3Byci9UT0VYdXhH?=
 =?utf-8?B?RzE5b1pwU2RDaHp6SG82Vk1YYkxCVDhGVFhXbktReUJRb2dEdm1vL1lLUUt0?=
 =?utf-8?B?dW9QeG9lS3ZDa29hdFA2ZHRvSFE0K0tTTTFkQWFqK2JabUhyZTVYM2N4TmFV?=
 =?utf-8?B?VG9MdTBUSEV0S045eUVxSHljR21NSTBQbGcyVVVtcFB3Q0EzbUR6VW1MSGVp?=
 =?utf-8?B?R2xRS3Y3eWRLdVFBRkZadE1obnh5U1FCNUNCZ3FGY1kyV25iSEtrYng3RGhh?=
 =?utf-8?Q?WSaduE7vES+RlWYFE9bHw0ANA?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c010cef2-f598-40c0-c46b-08de001f5f01
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2025 12:46:27.3771
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hEc38emNt+C4xcBefF5T+JUnR34D8CUVWU4dwGxJdVA2v/r/Hj+n3UoCW4/j+AwoIpuFaFu0toJHyE/t92vnrg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB7899

On Mon, Sep 29, 2025 at 05:59:00PM +0200, Oleksii Kurochko wrote:
> 
> On 9/29/25 10:41 AM, Roger Pau Monne wrote:
> > I've had the luck to come across a PCI card that exposes a MSI-X capability
> > where the BIR of the vector and PBA tables points at a BAR that has 0 size.
> > 
> > This doesn't play nice with the code in vpci_make_msix_hole(), as it would
> > still use the address of such empty BAR (0) and attempt to crave a hole in
> > the p2m.  This leads to errors like the one below being reported by Xen:
> > 
> > d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
> > 
> > And the device left unable to enable memory decoding due to the failure
> > reported by vpci_make_msix_hole().
> > 
> > Introduce checking in init_msix() to ensure the BARs containing the MSI-X
> > tables are usable.  This requires checking that the BIR points to a
> > non-empty BAR, and the offset and size of the MSI-X tables can fit in the
> > target BAR.
> > 
> > This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
> > EPYC 9965 processors.  The broken device is:
> > 
> > 22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
> > 
> > There are multiple of those integrated controllers in the system, all
> > broken in the same way.
> > 
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Stewart Hildebrand
> > Cc: Jan Beulich
> > Cc: Oleksii Kurochko
> > 
> > While not strictly a bugfix, I consider this a worthy improvement so that
> > PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
> > capabilities.
> 
> Based on your commit description it looks like a bug as without it, for example,
> SATA controller can't be used, right?
> 
> >   Hence I think this change should be considered for inclusion
> > into 4.21.  There a risk of regressing on hardware that was already working
> > with PVH, but given enough testing that should be minimal.
> 
> We have some PVH tests in Xen’s GitLab CI, but I assume that isn’t enough?

It's a very specific controller, which we don't seem to have any
examples of in the lab.  The model is in the commit message.  Without
this fix the device doesn't work as expected when used in PVH dom0
mode.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 12:52:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 12:52:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134259.1472223 (Exim 4.92)
	(envelope-from )
	id 1v3ZqA-0002Fi-Rd; Tue, 30 Sep 2025 12:52:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134259.1472223; Tue, 30 Sep 2025 12:52: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 1v3ZqA-0002Fb-Oz; Tue, 30 Sep 2025 12:52:22 +0000
Received: by outflank-mailman (input) for mailman id 1134259;
 Tue, 30 Sep 2025 12:52: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 1v3Zq9-0002FV-2I
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 12:52:21 +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 4cea2bed-9dfc-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 14:52:20 +0200 (CEST)
Received: from DB3PR0302MB8919.eurprd03.prod.outlook.com
 (2603:10a6:10:435::21) by DB9PR03MB9856.eurprd03.prod.outlook.com
 (2603:10a6:10:45c::5) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 12:52:16 +0000
Received: from DB3PR0302MB8919.eurprd03.prod.outlook.com
 ([fe80::ce88:43f9:c971:9584]) by DB3PR0302MB8919.eurprd03.prod.outlook.com
 ([fe80::ce88:43f9:c971:9584%6]) with mapi id 15.20.9160.015; Tue, 30 Sep 2025
 12:52: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: 4cea2bed-9dfc-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mhPhcZKlklOxzwfg6A/dstcNIIQvOkeZWib/J79FgQ7+teW8JOyE4RLHSF3L/itGQl3yI1yDluL+1lUFWvaADO7xTf68T8oPZAU4iVceaLQtzkXuMom9QDaZOrogf87BcwgUgwuGsQb9Q+mt0qX6v4Jp3yAUSimmr1iim4NE40JGC4h29U8YFHr6eWgA2vjkAOBLZqou1cqd8H1NQ+qFuEyS9c95p1kMLn0TKGXz5O8F7qDgrp+lZ+e4Hw5CpXr5ons5md4Wl33MAOE4Y0h4P2pUH1FIDw7DAlGu7+DorMEKJ4Wp6c5+QGlezQi+HV6rowISPvw6zR2I6I/boqDUWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Erjrl30noscaX2lqT9hvXNNxAk5ztrLaiZs6au1Q5qk=;
 b=o9CEUkJml1eFKcn168hNaSubzOHLgeYxwXBUWF8KutZ0kG8LBf7rkh1Ap+XJ2N75BsYF8PbCHiOUTnmJFIyqo02DD5TCfXUbwjaBo1rur2+AdLnCr1X4U/a/ZzvWhuK0l2XWY4UPBLecPbG1o2MQVvUY38kOOszDudMk6I4TQWGCwXHhsCuUbCrwASSGcuW8x7mAurX4Wvz/BxaSd3HW12fdnsUFDEoNg4rYNvHQQEwDpMotX8ACtk2HghHp1P1i8SjgR52WQakzlY1pvZphb4RW6vTFCTPKGETloK+OtWwIsYnNeqNqezTUhMx4KyTQPj8S/Yc6E1EfE/suefKzcQ==
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=Erjrl30noscaX2lqT9hvXNNxAk5ztrLaiZs6au1Q5qk=;
 b=H5oFQNXAv09364nMVjI1WVehzjvyYT0tEOd6EUKC1Sd5A85Ln7NOABG4Ft0mDpyS5WuzVYo0qENdiFzTq3uS7txEeaq2jEr2ymbzL495EwWdXkGntwpEMLSNSfhzfy3TgRAGudR+y/VBsmUajLkmIR1RTdJbMc7p4Itjc/MSftTyE1Ke4XR7jCXChb8OoDcNIPs5aPrBAduGaZe9rkzWh9BVVDxGNOQZ9E1ru9KVMW7VXo22EML+mMcLfCftjqj0yYAZW3Y0tg2TdsDAzHTW67gOQwmWISObjzXkoo3gGV4oqVhWTWxjXZBbfx7Du5fmSEcvcLQiN6G5k35yGDAt/Q==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Sergiy Kibrik , Jan Beulich ,
	Andrew Cooper , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Paul Durrant , Alejandro Vallejo
	, Grygorii Strashko
	
Subject: [PATCH v5] x86: make Viridian support optional
Thread-Topic: [PATCH v5] x86: make Viridian support optional
Thread-Index: AQHcMgkMkZmHuEXP5EqWMA+gnbZsPg==
Date: Tue, 30 Sep 2025 12:52:16 +0000
Message-ID: <20250930125215.1087214-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DB3PR0302MB8919:EE_|DB9PR03MB9856:EE_
x-ms-office365-filtering-correlation-id: f13d7852-36d5-4df1-45e8-08de00202f73
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?HaeB7Kmcm4pWSTiXt1CfPY5KkITcz+hq23LWlq41s36pq7eZ9x2YKZKHFd?=
 =?iso-8859-1?Q?goqssOCvopDK1t6tcWatJi80T44a7Ft/goqD4tdiiSpqYVC9QVWVxDK+P7?=
 =?iso-8859-1?Q?wW/pEWpB2d/3e7ndtRN2X6lkkHNI+20dTFcd3Hlbjp3zsRqWlKL6a5AfPR?=
 =?iso-8859-1?Q?KvYmS5qTr2g1kHbD/VRTfNPLHY3zZlSiwEFaHEToTx77UYygoEGvugTOlL?=
 =?iso-8859-1?Q?wjAHdx0/eAgJ51F+g3PQuwdQXz+aDH61/Ik4s1uycXO8a/NZO1rimJ+KqX?=
 =?iso-8859-1?Q?skGQGIeUayTVosSHLewy0Io4SATQ+4ATGlGQ5lELo1UAJ4f6t6R8juSoMF?=
 =?iso-8859-1?Q?oGh5LodFFwdNiB5F/iM7eL49dir4X56fvR+6WKXEEdbbM5fL8k0ON+2CfM?=
 =?iso-8859-1?Q?7Q7KbBH7kQri71oWL8nzNjlUzP7+yMCI/ebIzqrLIfC8VgA1uiEbWOP6BX?=
 =?iso-8859-1?Q?O6qXII92SyJpJ0Pt2DeSI8lnWGAjn4WELVe2kdyo03sOgoFSjIPP+JEEiF?=
 =?iso-8859-1?Q?qlpjQx5QsLTtCvIB0I60LvuudLPhJyL68tCMDwot+mXqSApXjDYPx5+nGd?=
 =?iso-8859-1?Q?8kJ45IfPpeFlI/Q8T/dm4rz7OP96ftf9mLj/L6IBWQmAvYjw5MpluTzhdp?=
 =?iso-8859-1?Q?99+v8JaVWxkkj0LD32rGMq8+2oGe0uHwMXIrb8qxkpcGgFV6ykaIMJDY9A?=
 =?iso-8859-1?Q?h3IdSov1PG3s8JgkmmQlejLhaE4f+hk9NsDqcfM42YLveR9UHwd9kM1kVK?=
 =?iso-8859-1?Q?SH+ctA8SCmq47Wi+1QemPYPx8M9+RCzoc6fcyb+eRZmYcKZKCqtNvAh94M?=
 =?iso-8859-1?Q?VGhLOgTfHorUuAGwlfifJslruJdMvaE04IDxQvg0eg/kmshHPV9CW3EE5D?=
 =?iso-8859-1?Q?iB+NM88OnRX6AM2mCL+mhAlwQ0EWBminFKd5aGuCOO/1EDl2BgBPUnuTi/?=
 =?iso-8859-1?Q?StqaYLiWULhaLyIQBxz+YppfxVVTB5b8gu4IVtc6YMxNzgx6EJNWrLBkan?=
 =?iso-8859-1?Q?NUjPdvqMDV9rHgRs/AlMB4hSe/VSLB2zCBS9qbspuLR4JZxRdRxf4hgN9v?=
 =?iso-8859-1?Q?FjHH78/5MTf22mTRGpe5rGTEa5XvUURRcJrwwaqot/8rApJ4Q13Y+rUH30?=
 =?iso-8859-1?Q?gdFYEP8ZBv1bVs3F/Pyag1TsUKnn9Q1SFJIZiiWgxi3BVcEE7G3SqrMC2J?=
 =?iso-8859-1?Q?bSXS5rLm23Y1k993VErLoOlwNvveX4GIRHxRO8FEYa33wbz1I5LtfmArdS?=
 =?iso-8859-1?Q?wjI8gP44CjFXRPoqreAxJoinsQvEh7J0a+/cxZu+PzzdGAKUjuH3xwFg+D?=
 =?iso-8859-1?Q?R5oiKPzUVgSNKFNc7jMeIl05JBTrqczqzTQh+AGFHFlZixS49pR2vBuHeB?=
 =?iso-8859-1?Q?kMdzUCpwhFpierJE8nyz7TfKlJFUpUWGLWKn/o8FL4ikyw2iwKQ8tg2jzs?=
 =?iso-8859-1?Q?nQr5/iVWbrMGOYOOAnY0zgN3ZPz9LxhnFLM8vWG7mb0KWh/qBKpLIeMFTE?=
 =?iso-8859-1?Q?CMfCkYBR4dRSypPV67id+R?=
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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?N25PxKQ+9bi8uiSdwEzLH9MDzq4VHx5gt1VpkmM+d6yaeVp2DB9kj7AQtV?=
 =?iso-8859-1?Q?hF05w3twkd+ptNWVxpoj9hAc6YEtvmmr+QuLlveakMeyu5tdKiynRlsL3K?=
 =?iso-8859-1?Q?GnjUqLR4gXEzd7cJxb1oXHAR2cJwiBkYxw2d7uzuWxjwTNef1nGk5BDyYX?=
 =?iso-8859-1?Q?NloqgJ85Tv8gQ8nElArdFCsYwyhUaWpS8wcc1lztNaHEkLCS0LcpFQ5Xzh?=
 =?iso-8859-1?Q?qCpfZF2JH+C99QXf4nVG3Tx8iVD9Endk1HwemXGJJ/q/0b6YXnp0avbNrt?=
 =?iso-8859-1?Q?ou5Rpmg3cvzDSwSyahzQM3tfEapOuHL8Qi51csGlnxpDZHfY1pm/YIXONZ?=
 =?iso-8859-1?Q?+YJUWRZzkm5hcQx5leyLoNiY59j8VAOAyDwzuAtijCnA+cO0eNOv5AQjfb?=
 =?iso-8859-1?Q?GaQwzhjPDF8zc0O2V73RZCAFZURZzFdYKWEJu2jn1xb48MYT18COYPQxMD?=
 =?iso-8859-1?Q?KtlD+oWhBDyKh9xDpIsc6tjFv5tHNABCwPXhQ95WNVrGA8ZcnzXzeKuxsH?=
 =?iso-8859-1?Q?P5Ys4ZEcKU2pIvn0oLcjkZLh3mDXPQSqwlG3v+3coIgMMkSZJuyLi5obFh?=
 =?iso-8859-1?Q?WPJimpg7Rpl1MqBCLxIaYaYQ+ORnKfWNQXRF5chuO3Aeua18xt1r56H/MM?=
 =?iso-8859-1?Q?RByqCt/rFZ5pAHMM+PFAQA5iqN1sOnTuvyvaAtxSfHw+mYlfyUe1CcxCC2?=
 =?iso-8859-1?Q?UXsMHuC+9GqZiKCUEq4TinHDjax8uOL1am70wDOcTaHNpqWmUH/EJkt036?=
 =?iso-8859-1?Q?JcOFo2CFTLQTBPPH3vegS/PBRmSephn/HHab8w1D1k4/qYWz4+QeoOOaOd?=
 =?iso-8859-1?Q?5Fll2Fngngu2w/HY2CKT96pzjzN8DeBG06e8ysbIvESKWaxRGMpb76J/WP?=
 =?iso-8859-1?Q?Ug8LRM9/GQAD3PuOYDu8mxvi7uHglUV2pRTTYmRMcVJ4lY4gSmBqSVUlhy?=
 =?iso-8859-1?Q?IFQYE4YWjM0kN8wAQmQbNRqRxBae+qOixRbOiIVXok/lxoNTLxEJXIDu5K?=
 =?iso-8859-1?Q?BVrPkHbVUjsnH80X8bXAKWcO1PP7Tma5uBZaq1E2uZ3SqM/27nOOUnyAut?=
 =?iso-8859-1?Q?Tl7QqC5kQXSbNb4W1s53DV/y7XtNax1EBhfrKL4plNRwsp5rvNpZaLath3?=
 =?iso-8859-1?Q?TQSXECBpmHkbpbuezQ9T8H5/GK6XjD+ictNlpvEqJ2n41+DfsDuhlhgHPh?=
 =?iso-8859-1?Q?3hUuWrdEBeo5By/vnt4U5etunrfRG6EACF5VV8vfIm9YiX75xJ4SebEwOW?=
 =?iso-8859-1?Q?OpT1mF9q//f069axkQlaUdIFgw+OE2awIEbKVnbYTSSl7InzNtwm2C+igJ?=
 =?iso-8859-1?Q?rmVIuZD+sE667+iK6V665+1Y4XTWfDv1MIbbMs3J4GWY2p6jYN/MiUItMH?=
 =?iso-8859-1?Q?+pEnnsUh8tkxLhMcblwiS17q7SD39RsQtUNrpj8/mdNzVtuuCKXQlWQdiR?=
 =?iso-8859-1?Q?WXJIaEn+EEdzccNc82W9Vw/BxJ95WU8xmNmGY2UiofXS3CjAUThX2T7bJk?=
 =?iso-8859-1?Q?qCOj766GBt5ITwMQe+0ZaIuhz42hM0Drq9eTT4VrBAoJxMQDIh1XuQ0xKY?=
 =?iso-8859-1?Q?N6lAaLYl+rEXldKdRjkF+aChSWNl0zU61KEl387fveZkVVdDm83T1MOkAp?=
 =?iso-8859-1?Q?Ykf73eKUH9jue/jkyCcC5AhIc2yfqWK1aOipl2PSLa9p8rbJFHwvk0ug?=
 =?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: DB3PR0302MB8919.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f13d7852-36d5-4df1-45e8-08de00202f73
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2025 12:52:16.7950
 (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: XJwfTBjiD9z7CTQDU2L1Kymyhl9siplppupoz/wbJV20pim2BsJv0fSHTZKpykkP6+OmR3AtjD4GkYsZxA7wAKyI1gHCAyGtlltu+ssgOhE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9856

From: Sergiy Kibrik 

Add config option VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related mac=
ros.
Having this option may be beneficial by reducing code footprint for systems
that are not using Hyper-V.

[grygorii_strashko@epam.com: fixed NULL pointer deref in
viridian_save_domain_ctxt()]
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Grygorii Strashko 
---
changes in v5:
- drop "depends on AMD_SVM || INTEL_VMX"
- return -EILSEQ from viridian_load_x() if !VIRIDIAN

changes in v4:
- s/HVM_VIRIDIAN/VIRIDIAN
- add "depends on AMD_SVM || INTEL_VMX"
- add guard !is_viridian_vcpu() checks in viridian_load_vcpu_ctxt/viridian_=
load_domain_ctxt

changes in v3:
- fixed NULL pointer deref in viridian_save_domain_ctxt() reported for v2,
  which caused v2 revert by commit 1fffcf10cd71 ("Revert "x86: make Viridia=
n
  support optional"")

v4: https://patchwork.kernel.org/project/xen-devel/patch/20250919163139.282=
1531-1-grygorii_strashko@epam.com/
v3: https://patchwork.kernel.org/project/xen-devel/patch/20250916134114.221=
4104-1-grygorii_strashko@epam.com/
v2: https://patchwork.kernel.org/project/xen-devel/patch/20250321092633.398=
2645-1-Sergiy_Kibrik@epam.com/

 xen/arch/x86/hvm/Kconfig              | 10 ++++++++++
 xen/arch/x86/hvm/Makefile             |  2 +-
 xen/arch/x86/hvm/hvm.c                | 27 ++++++++++++++++++---------
 xen/arch/x86/hvm/viridian/viridian.c  | 14 ++++++++++----
 xen/arch/x86/hvm/vlapic.c             | 11 +++++++----
 xen/arch/x86/include/asm/hvm/domain.h |  2 ++
 xen/arch/x86/include/asm/hvm/hvm.h    |  3 ++-
 xen/arch/x86/include/asm/hvm/vcpu.h   |  2 ++
 8 files changed, 52 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index 5cb9f2904255..928bb5662b89 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -62,6 +62,16 @@ config ALTP2M
=20
 	  If unsure, stay with defaults.
=20
+config VIRIDIAN
+	bool "Hyper-V enlightenments for guests" if EXPERT
+	default y
+	help
+	  Support optimizations for Hyper-V guests such as faster hypercalls,
+	  efficient timer and interrupt handling, and enhanced paravirtualized
+	  I/O. This is to improve performance and compatibility of Windows VMs.
+
+	  If unsure, say Y.
+
 config MEM_PAGING
 	bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED
 	depends on VM_EVENT
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 6ec2c8f2db56..736eb3f966e9 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_AMD_SVM) +=3D svm/
 obj-$(CONFIG_INTEL_VMX) +=3D vmx/
-obj-y +=3D viridian/
+obj-$(CONFIG_VIRIDIAN) +=3D viridian/
=20
 obj-y +=3D asid.o
 obj-y +=3D dm.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 23bd7f078a1d..95a80369b9b8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -701,9 +701,12 @@ int hvm_domain_initialise(struct domain *d,
     if ( hvm_tsc_scaling_supported )
         d->arch.hvm.tsc_scaling_ratio =3D hvm_default_tsc_scaling_ratio;
=20
-    rc =3D viridian_domain_init(d);
-    if ( rc )
-        goto fail2;
+    if ( is_viridian_domain(d) )
+    {
+        rc =3D viridian_domain_init(d);
+        if ( rc )
+            goto fail2;
+    }
=20
     rc =3D alternative_call(hvm_funcs.domain_initialise, d);
     if ( rc !=3D 0 )
@@ -739,7 +742,8 @@ void hvm_domain_relinquish_resources(struct domain *d)
     if ( hvm_funcs.nhvm_domain_relinquish_resources )
         alternative_vcall(hvm_funcs.nhvm_domain_relinquish_resources, d);
=20
-    viridian_domain_deinit(d);
+    if ( is_viridian_domain(d) )
+        viridian_domain_deinit(d);
=20
     ioreq_server_destroy_all(d);
=20
@@ -1643,9 +1647,12 @@ int hvm_vcpu_initialise(struct vcpu *v)
          && (rc =3D nestedhvm_vcpu_initialise(v)) < 0 ) /* teardown: neste=
dhvm_vcpu_destroy */
         goto fail5;
=20
-    rc =3D viridian_vcpu_init(v);
-    if ( rc )
-        goto fail6;
+    if ( is_viridian_domain(d) )
+    {
+        rc =3D viridian_vcpu_init(v);
+        if ( rc )
+            goto fail6;
+    }
=20
     rc =3D ioreq_server_add_vcpu_all(d, v);
     if ( rc !=3D 0 )
@@ -1675,13 +1682,15 @@ int hvm_vcpu_initialise(struct vcpu *v)
  fail2:
     hvm_vcpu_cacheattr_destroy(v);
  fail1:
-    viridian_vcpu_deinit(v);
+    if ( is_viridian_domain(d) )
+        viridian_vcpu_deinit(v);
     return rc;
 }
=20
 void hvm_vcpu_destroy(struct vcpu *v)
 {
-    viridian_vcpu_deinit(v);
+    if ( is_viridian_domain(v->domain) )
+        viridian_vcpu_deinit(v);
=20
     ioreq_server_remove_vcpu_all(v->domain, v);
=20
diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridi=
an/viridian.c
index c0be24bd2210..1212cc418728 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_ctxt(
 {
     const struct domain *d =3D v->domain;
     const struct viridian_domain *vd =3D d->arch.hvm.viridian;
-    struct hvm_viridian_domain_context ctxt =3D {
-        .hypercall_gpa =3D vd->hypercall_gpa.raw,
-        .guest_os_id =3D vd->guest_os_id.raw,
-    };
+    struct hvm_viridian_domain_context ctxt =3D {};
=20
     if ( !is_viridian_domain(d) )
         return 0;
=20
+    ctxt.hypercall_gpa =3D vd->hypercall_gpa.raw;
+    ctxt.guest_os_id =3D vd->guest_os_id.raw,
+
     viridian_time_save_domain_ctxt(d, &ctxt);
     viridian_synic_save_domain_ctxt(d, &ctxt);
=20
@@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt(
     struct viridian_domain *vd =3D d->arch.hvm.viridian;
     struct hvm_viridian_domain_context ctxt;
=20
+    if ( !is_viridian_domain(d) )
+        return -EILSEQ;
+
     if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) !=3D 0 )
         return -EINVAL;
=20
@@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt(
     struct vcpu *v;
     struct hvm_viridian_vcpu_context ctxt;
=20
+    if ( !is_viridian_domain(d) )
+        return -EILSEQ;
+
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL )
     {
         dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 993e972cd71e..79697487ba90 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -426,7 +426,8 @@ void vlapic_EOI_set(struct vlapic *vlapic)
      * priority vector and then recurse to handle the lower priority
      * vector.
      */
-    bool missed_eoi =3D viridian_apic_assist_completed(v);
+    bool missed_eoi =3D has_viridian_apic_assist(v->domain) &&
+                      viridian_apic_assist_completed(v);
     int vector;
=20
  again:
@@ -442,7 +443,7 @@ void vlapic_EOI_set(struct vlapic *vlapic)
      * NOTE: It is harmless to call viridian_apic_assist_clear() on a
      *       recursion, even though it is not necessary.
      */
-    if ( !missed_eoi )
+    if ( has_viridian_apic_assist(v->domain) && !missed_eoi )
         viridian_apic_assist_clear(v);
=20
     vlapic_clear_vector(vector, &vlapic->regs->data[APIC_ISR]);
@@ -1360,7 +1361,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
      * If so, we need to emulate the EOI here before comparing ISR
      * with IRR.
      */
-    if ( viridian_apic_assist_completed(v) )
+    if ( has_viridian_apic_assist(v->domain) &&
+         viridian_apic_assist_completed(v) )
         vlapic_EOI_set(vlapic);
=20
     isr =3D vlapic_find_highest_isr(vlapic);
@@ -1373,7 +1375,8 @@ int vlapic_has_pending_irq(struct vcpu *v)
     if ( isr >=3D 0 &&
          (irr & 0xf0) <=3D (isr & 0xf0) )
     {
-        viridian_apic_assist_clear(v);
+        if ( has_viridian_apic_assist(v->domain) )
+            viridian_apic_assist_clear(v);
         return -1;
     }
=20
diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/a=
sm/hvm/domain.h
index 333501d5f2ac..95d9336a28f0 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -111,7 +111,9 @@ struct hvm_domain {
     /* hypervisor intercepted msix table */
     struct list_head       msixtbl_list;
=20
+#ifdef CONFIG_VIRIDIAN
     struct viridian_domain *viridian;
+#endif
=20
     /*
      * TSC value that VCPUs use to calculate their tsc_offset value.
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/=
hvm/hvm.h
index f02183691ea6..7312cdd878e1 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -510,7 +510,8 @@ hvm_get_cpl(struct vcpu *v)
     (has_hvm_params(d) ? (d)->arch.hvm.params[HVM_PARAM_VIRIDIAN] : 0)
=20
 #define is_viridian_domain(d) \
-    (is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
+    (IS_ENABLED(CONFIG_VIRIDIAN) && \
+     is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
=20
 #define is_viridian_vcpu(v) \
     is_viridian_domain((v)->domain)
diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm=
/hvm/vcpu.h
index 924af890c5b2..9ed9eaff3bc5 100644
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -176,7 +176,9 @@ struct hvm_vcpu {
     /* Pending hw/sw interrupt (.vector =3D -1 means nothing pending). */
     struct x86_event     inject_event;
=20
+#ifdef CONFIG_VIRIDIAN
     struct viridian_vcpu *viridian;
+#endif
 };
=20
 #endif /* __ASM_X86_HVM_VCPU_H__ */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 12:57:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 12:57:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134274.1472233 (Exim 4.92)
	(envelope-from )
	id 1v3ZvS-0002zM-I9; Tue, 30 Sep 2025 12:57:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134274.1472233; Tue, 30 Sep 2025 12: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 1v3ZvS-0002zF-FT; Tue, 30 Sep 2025 12:57:50 +0000
Received: by outflank-mailman (input) for mailman id 1134274;
 Tue, 30 Sep 2025 12: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 1v3ZvQ-0002z4-Vb
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 12:57:48 +0000
Received: from DM5PR21CU001.outbound.protection.outlook.com
 (mail-centralusazlp170110009.outbound.protection.outlook.com
 [2a01:111:f403:c111::9])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0e83cc60-9dfd-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 14:57:45 +0200 (CEST)
Received: from DM6PR03MB5227.namprd03.prod.outlook.com (2603:10b6:5:247::22)
 by IA1PR03MB8310.namprd03.prod.outlook.com (2603:10b6:208:5b2::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 12:57:42 +0000
Received: from DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2]) by DM6PR03MB5227.namprd03.prod.outlook.com
 ([fe80::c9a0:563d:c344:aec2%5]) with mapi id 15.20.9182.013; Tue, 30 Sep 2025
 12: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" 
X-Inumbo-ID: 0e83cc60-9dfd-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M7y/IH80GKiOJU4s6gHeL2dPAYFLFvJkJsldP7qUhamkXp9FQpgbTXZFjgollYpa3qkQkgBzFUZyJEd/STHJBkM4gEuysK12lYMkz3RV/FqdiSL6ruMHaI8P/pxLlVmVdvcMviOc9W4rUn1xMTEmrlQ7Td7LULRlIUNtVwfCjzJ5uHBjKZm+RPBYjwMOQwTPrJww2LxlIEe95UgMbO0WFDyMinldY7KCcaCbtolopmxQqJviR9/wB3YXEd9W0DLYnEruZGnzEWY1H2RBGP/z519VrPmxUJQHBQg69xB5L8Nm0hQQipTVJxYRdayzpkkJFzrDnm2ZMKvKGIrJfVHaIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=u6nRTq4CBt+gGSBE+Yylg8cVhwqC9lTnCeCl7vO/9p8=;
 b=CEhzDq0tgxq4MnBeHluQov+D09/5Rab8gmZ24U2ZX8kp4v1zdGSLI4fe7rJRzY4zDga5EfLrZDkvJsUgsdG0Q09IAzYhYwHnATJPpInbwiEfBtjDPRcUPGoitF2SCtT8jz/QyscITKn2GRxHdfTwn53XVyDKy3GiCBO/7PWU04oSRHBOEeXsl7VgohIL9iYu4pYyYLY++q5nxXVoXaRreByM39Cw9da9HSG2SVLDsQ9J8Hc7gfcAjpm8RlUUImoHaDTJAfdG4tPqke3lvbmqi3m+XMpEyUu2+cAfkuzAQCbsQ0k/Ny5ZfbYcWRFA4RpWCyEyGtEE6li3AyWRUwd5fg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=u6nRTq4CBt+gGSBE+Yylg8cVhwqC9lTnCeCl7vO/9p8=;
 b=JEXffMlOcjegUvfCNcNT9mFj1F8CIN83zf9iqnl4iuiCfs6JJUk9GMRjH05K2vBBSBq/aW6VHe02zKEYtqYwC7G4Tn+HBolsjn7YNxVmt2TA3TcSd4Ymuphyw0/h6hDahS/QZgb4srThCur3r5/V1e5+G5TE6u5tvlkKy1gDAZA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Date: Tue, 30 Sep 2025 14:57:38 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Stewart Hildebrand ,
	Jan Beulich ,
	Oleksii Kurochko ,
	Xen-devel 
Subject: Re: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X
 capabilities
Message-ID: 
References: <20250929084149.70560-1-roger.pau@citrix.com>
 
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-ClientProxiedBy: MA3P292CA0016.ESPP292.PROD.OUTLOOK.COM
 (2603:10a6:250:47::10) To DM6PR03MB5227.namprd03.prod.outlook.com
 (2603:10b6:5:247::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM6PR03MB5227:EE_|IA1PR03MB8310:EE_
X-MS-Office365-Filtering-Correlation-Id: dd4aabbb-a2b4-418e-987e-08de0020f17a
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?LzlEVktYdE5GVjZUMjJ0Q3F4bHJ1aGY2UDRBenJYSkZab0d2SENSM1VDbzky?=
 =?utf-8?B?ZVN0TmlqRjhFTkFvQ3VHbm5BS3RSMHczVWc3dDdHWFhaMHFpRTZieHB3UGF5?=
 =?utf-8?B?OXBRb3lnaGhrcnpGMkE0ME10dVZwRFNzVWozSk5LTTUza3JTOGN1czdXNDl4?=
 =?utf-8?B?UUNNSVVtODF3a2doRklvdWU5ay93a1J4TFVUQUFiWUg3S211SmZaZU9HazE3?=
 =?utf-8?B?V2hqbHFSc0IzLytrbSsvUXV5L0R6dUlZOHB2MjhxT0xWTDZJdEtuSjlxNjNq?=
 =?utf-8?B?ZzFPWTBxSWdPdWwyeGIwRWtPYjR0TU5xVWtNV0dJUWxseVNscVFaalpNamJt?=
 =?utf-8?B?ditBQTUwd0JNQVdUNm95TnUzL3hPVDVJenZqVnlQNWJFeWpGTTNpVXA0S1Ji?=
 =?utf-8?B?QmY3QytubjJqRWhRcDN6dnhyY1pwY29VQkpLTVAyMkoyV0pybFk3ZFY0bG42?=
 =?utf-8?B?YzlmNldnL2RITWhCQzFPbWF1K0d6TzFDc3AxTnlPMVZEcmlaTldYU090M05u?=
 =?utf-8?B?UklDRlpRYmdRUEgwalJka1VqdERZc0ZtR2xXUGxqYmxFTGY3Z2JSZTNVWmhK?=
 =?utf-8?B?MHY4aU1MalFFMlZERjlvbnRPMVlvdWZKVWxKTThPUTdTdkd5TGlETnJmdzZr?=
 =?utf-8?B?WmZVMGRnT1owcmZNdERRRVA0T0diYkNKYmlZUCtYZlR6OVdXeGdGaHAzMmRx?=
 =?utf-8?B?SlNmM05IZzljejFjU3VCSlBzcVNrUzFya2twV2lwU1FUSVIyQXVkNDJGdmJk?=
 =?utf-8?B?Sk40TTR3Zi9PaVBobHBOOFNyM3BmZ1gxTmxNZ1NTMHNKWjZIQUVSMFdVQ1JY?=
 =?utf-8?B?d2FMOThDdGczS2t2azJCV000cURidnpNaEtsRTFOK1BKUkovVWVvUkZIU05v?=
 =?utf-8?B?SS94eDVMeWRodzZ5SU9EYzNVdEZVRlBGeEFPRm5IcVo4Y2NRTW00bGEwUW5W?=
 =?utf-8?B?YXdNd2o4enlPQk5qbmtIaTZBVFhUUlZwOHlvaC82Mm8waW5DT0R1ZVpKWlBZ?=
 =?utf-8?B?SDR5TXhOVDRXaU4zRmVNcEFzclVSWU12L2w1SGh0R3lnVUg3djYwcHhGbzJa?=
 =?utf-8?B?cUpmZzJ2bUhlalI3NDdjR1dxaG1TTy9yc05UQzF2VTdMcXY2eU9Ta3VIbkl1?=
 =?utf-8?B?Z1hDajVYdTBRTFAvK1RmUFJFQzVZR0tvUmlPUGFsbHdtZXZ3cWdZNTdCUndJ?=
 =?utf-8?B?VnVBV1hJL250UG5ybHJ1NUtzZlFvQk5WNU1icy9vMWJGMUo1VU5nNzU1R25I?=
 =?utf-8?B?WndmYmxrMGx2YVBqaFZPUTF3MjlRM2J0Uk9aaFo5MC9xeStnbHlyYUt0bUVm?=
 =?utf-8?B?VDk1eENvTEdKSWR2N1QzdEJINkdRdGRTcTAvaTI0NTA1MWVFeDY1eForeFZz?=
 =?utf-8?B?Q1hudTNQRlNQT3psR0p2V3VWTDhycCtnaGxMbUo2OHdaYUwyTDJzbHQ4WC81?=
 =?utf-8?B?RVRoWlZvWnFyUm9nUkpDRTh4ZHkvWmE3RWxvYUxocVlvRWVteTdpZzhQMU9r?=
 =?utf-8?B?MXBEMHF4TWdvMEx4SWU5c2g1ZVo1dmNNOWxiSHlkYitQWVBlZmt1bU5uRTRL?=
 =?utf-8?B?MGsxUXN5d3FwS1dsTXJaZEduRWd1aEhOaGdYTHpVTGVJVnNvcGhOSTJlbVRR?=
 =?utf-8?B?YklYeEs0YjdXaTV6dU5BS1hmVE9KUXczYTZaanV1Y2JLZlA5VGNxQnBseFNC?=
 =?utf-8?B?cmV0QVRNa3RiUTBIOGsrUUtTaVI5OFd1bFJvNTdpTmJieTIvWHY5eDhLOEpP?=
 =?utf-8?B?UFRDU1BKUUdGNFptMnJXdWxEdS9pUzhWOWtnNGduc2RDeDR0bHRyZURFTHVu?=
 =?utf-8?B?ZC9lUWhQMTF0cDFZRGhyRHFiV3ZVb1BVRVN3WCtiRUpWLzcwdEFQdVhaUVBt?=
 =?utf-8?B?TU1GR2ZINHhIaklacHNzYzJIL2ZDRDExNzJPa1Y3Q1BjZXBQRlRjcVhTeGc1?=
 =?utf-8?Q?T8Bzd7cWz1C6FILr6AHFX/g3dPavlDnI?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR03MB5227.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QzBoQ3JQYXhhZlhoWGdLUVlXVkpiZndyWkpqNnBPbThOLzVGMzFzeXArMUYw?=
 =?utf-8?B?eCtnQ25KLzdYT0YwV1kvVkNUNGdVTVFVbENVWmNqd0hZWVFud1lIVkxaQ2p2?=
 =?utf-8?B?clUwMXVub0ZMckFQNXl4ZGh2Q0hqdWNHblJJd01Uczg5VXlDWkVmQkE5cHJv?=
 =?utf-8?B?elp5M0JZYndxSm41MDVXK2pqV3h2OXZHcGNjV1preUczNytKaVhzelptNjZS?=
 =?utf-8?B?UWF0VENmaU13bUlUckFjSG5iYkpSbXRKLzFuV2VFZVFLQ0lncHJUN0JYcmE5?=
 =?utf-8?B?MXk2aTBRQzY3SXErUzEwRTQycmxESHFJcTZkRDJ1b255MVFzV3BYSjVXTWNS?=
 =?utf-8?B?N2VFVnR6QmdOUFhHU0NLekQ0QjV6cUhZa2JlNzJ3OVFQanRMNVZSNTFGUHFR?=
 =?utf-8?B?YlFJYXhyWHpjYVY4MHoxcXdmSFpnSXUvU0twczJiZjBjU2VNMVd3cjV4cnB4?=
 =?utf-8?B?N2dZQ3FQL1VTenRKRWg5WlA5TDlocG9CZnZ6Y3dmaVJZV3ZseFFiRTh6WTZP?=
 =?utf-8?B?Z0ducDMvMnBMN09vVTQ0Y0MyYXVCbThmQjYwUlhuWHBrMEF1T21waTQ1aXVa?=
 =?utf-8?B?V3JiWThJQ0JXYmZVY2hrK2NKNXVDTUZHU3p0ODRDb01UczluaVoyZUxBOGw3?=
 =?utf-8?B?eXQ2dFBDRFpKOVB2UUYvbFRMWUU2RWprQk5haXMrZFB0ejhRTkxFWGp6b1pF?=
 =?utf-8?B?T0tzVjRJOExUTkliZ3cyZkFZaERaT2VrbjFuRWlxUUp3VFF5ckR0NzkvVkt3?=
 =?utf-8?B?OGVqYnZjcS9weG9lcHUrcE9VZ1RuY2wySTdFQklRMUNwcWlJNG1rOG1hK0pL?=
 =?utf-8?B?QzFsM1JnTTBoQWZsTGg5cGdrT2NvS1RydmhvSzFQQmFEM09DaEhkVkEwTkpC?=
 =?utf-8?B?M1RkQ1hEM0hSMEw5WnZWNlV2em95K3VROTlYbkM2NU1ZU1JlczNhTHRuU0c3?=
 =?utf-8?B?bUU5QjhxYWlEQ1BDN05nNzJSc3h2cFFFcGpPS080ZnRHVVNsZlJJd3ZyVkg3?=
 =?utf-8?B?c2dzdXlwQmdvNnhBMW9pTHJFZWU4YjRVMEFiMjZXWW1JMmNjN3J1b2xVVTZi?=
 =?utf-8?B?aFNaL0pXeTU3bG9HaFZ6RDdpQnBhSnJGdXZtMlo5R1doT0JuNjRKdytkYkpr?=
 =?utf-8?B?SEpLVDJtUG9hcEs0b2hnVkNVV20rL0NWbFBobVN2OW9HNEsySEYxRmJBOGEv?=
 =?utf-8?B?UkgxS3o5NTcrbFg1aWtMbnhCczFIZG5vOUlzTktrb1pjVXA1S3JITTZtUXRt?=
 =?utf-8?B?RXJWalBSVHJzeWRueWNSVTBwdk00cmFBbCtwNU9xNjlUaUwzV2JWWm5RSk9M?=
 =?utf-8?B?NFl2RW1saHlTSkR2b3Vxcm93NU5hV3V4TkdYZjNqZzc3eE8yaTVLVFFRTEV2?=
 =?utf-8?B?aUNyc0JHUXAyQ2NqMWNtd21VWmprc2NVbFIrbkMwVk5xVEJTeVVEd1V1MFQv?=
 =?utf-8?B?WFc4RWVHa0l2bkxuN1hXSWZpaXpOU1FXdXV0eDdRbXlWZmlrWXRhOGliaXl1?=
 =?utf-8?B?SURNQ0x5RUJVUjBNb2NQY0tEcG9obEVLRzE3Y00xYXoxK2dIYjdyTnJKQmZO?=
 =?utf-8?B?V0xUSDcwV1pMSldZeU12em9EY2FoTzFUUVRXQ1FmNm9ucVZaRUFTdUZuQktC?=
 =?utf-8?B?cnc1emNCbVZENUpQU3VQRm0wMUxRNUw4Z3JobnQ3Z2EzUGtBNHdkQW9kenlq?=
 =?utf-8?B?S1A1a3BhOEFCUmNZUCtHa0E4U2F3bkphNXZwVXh1L3dKL2RKbEVwSTBMdXow?=
 =?utf-8?B?cm9xSHVjSll5azJIQmRiaHg0a0hZMHRTMHkvNDUrM0JQcHhSOUxJSUZTMi9C?=
 =?utf-8?B?amZpUW1yVnBUSE9JM1dHdXZMUVZlOFBVbElGcnRZN3lyV1IxbmVZUTFpNVlE?=
 =?utf-8?B?S2NnWE5kWGdBd21aM2lZN3g3eTdzVVhFUkxRdlo5djhmOXdtc0FXVDgwODZu?=
 =?utf-8?B?czZMRmgyMVk0SkxmRHkzejhPZ3N1TFhGekFEY0I0dTRLc0xyUWhwdzZJdnRJ?=
 =?utf-8?B?eCtoam9YQmE1OHo3KytXVnRjMHZxZWNFNzI1U0dOL3FIVVg2dG5jRWkzdXhJ?=
 =?utf-8?B?UE5YV3ZJdHU0OWpYSi9XakNmVkhaVW44azMxdWN5aEF3bXlhVitsTlpjemds?=
 =?utf-8?Q?wozQMvQIfFiSAHnbpOC4Li90E?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd4aabbb-a2b4-418e-987e-08de0020f17a
X-MS-Exchange-CrossTenant-AuthSource: DM6PR03MB5227.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2025 12:57:42.5444
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1qHURzGQiMclGyGu1Afb6LsQLg8ZHfKGUXsmvpyECEKhsaQmvsSSQBfzuiVSHX6QRMJbhcQNVYIJNjBHUzoc8g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8310

On Tue, Sep 30, 2025 at 11:15:01AM +0200, Alejandro Vallejo wrote:
> On Mon Sep 29, 2025 at 10:41 AM CEST, Roger Pau Monne wrote:
> > I've had the luck to come across a PCI card that exposes a MSI-X capability
> > where the BIR of the vector and PBA tables points at a BAR that has 0 size.
> >
> > This doesn't play nice with the code in vpci_make_msix_hole(), as it would
> > still use the address of such empty BAR (0) and attempt to crave a hole in
> > the p2m.  This leads to errors like the one below being reported by Xen:
> >
> > d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
> >
> > And the device left unable to enable memory decoding due to the failure
> > reported by vpci_make_msix_hole().
> >
> > Introduce checking in init_msix() to ensure the BARs containing the MSI-X
> > tables are usable.  This requires checking that the BIR points to a
> > non-empty BAR, and the offset and size of the MSI-X tables can fit in the
> > target BAR.
> >
> > This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
> > EPYC 9965 processors.  The broken device is:
> >
> > 22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
> >
> > There are multiple of those integrated controllers in the system, all
> > broken in the same way.
> >
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Stewart Hildebrand 
> > Cc: Jan Beulich 
> > Cc: Oleksii Kurochko 
> >
> > While not strictly a bugfix, I consider this a worthy improvement so that
> > PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
> > capabilities.  Hence I think this change should be considered for inclusion
> > into 4.21.  There a risk of regressing on hardware that was already working
> > with PVH, but given enough testing that should be minimal.
> > ---
> >  xen/drivers/vpci/msix.c | 50 ++++++++++++++++++++++++++++++++++++-----
> >  1 file changed, 45 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> > index 54a5070733aa..8458955d5bbb 100644
> > --- a/xen/drivers/vpci/msix.c
> > +++ b/xen/drivers/vpci/msix.c
> > @@ -675,6 +675,51 @@ static int cf_check init_msix(struct pci_dev *pdev)
> >      if ( !msix )
> >          return -ENOMEM;
> >  
> > +    msix->tables[VPCI_MSIX_TABLE] =
> > +        pci_conf_read32(pdev->sbdf, msix_table_offset_reg(msix_offset));
> > +    msix->tables[VPCI_MSIX_PBA] =
> > +        pci_conf_read32(pdev->sbdf, msix_pba_offset_reg(msix_offset));
> > +
> > +    /* Check that the provided BAR is valid. */
> > +    for ( i = 0; i < ARRAY_SIZE(msix->tables); i++ )
> > +    {
> > +        const char *name = (i == VPCI_MSIX_TABLE) ? "vector" : "PBA";
> > +        const struct vpci_bar *bars = pdev->vpci->header.bars;
> > +        unsigned int bir = msix->tables[i] & PCI_MSIX_BIRMASK;
> > +        unsigned int type;
> > +        unsigned int offset = msix->tables[i] & ~PCI_MSIX_BIRMASK;
> > +        unsigned int size =
> > +            (i == VPCI_MSIX_TABLE) ? max_entries * PCI_MSIX_ENTRY_SIZE
> > +                                   : ROUNDUP(DIV_ROUND_UP(max_entries, 8), 8);
> > +
> > +        if ( bir >= ARRAY_SIZE(pdev->vpci->header.bars) )
> > +        {
> > +            printk(XENLOG_ERR "%pp: MSI-X %s table with out of range BIR %u\n",
> > +                   &pdev->sbdf, name, bir);
> 
> Would it be worth adding something here such that a device vendor testing their
> hardware under Xen can trivially grep for device bugs?
> 
> Something akin to "[Firmware bug]" on Linux, like "[Device bug]" or some such.
> 
> It would also let anyone not very knowledgeable about PCI know that a device
> they own is being unreasonable. Same below in the other XENLOG_ERR messages.

We could add indeed.  I don't think we haven't done so in the past.
If we go that route I would suggest that I add a:

#define DEVICE_BUG_PREFIX "[Device bug] "

in lib.h or similar, to make sure we use the same prefix uniformly.
TBH I think vendors care little about the output of Xen, as long as it
boots.

The downside of this is that it makes those messages longer, which
will require more time to print if using a slow UART.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 13:03:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 13:03:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134297.1472244 (Exim 4.92)
	(envelope-from )
	id 1v3a0k-0004XY-5n; Tue, 30 Sep 2025 13:03:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134297.1472244; Tue, 30 Sep 2025 13:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3a0k-0004XR-2r; Tue, 30 Sep 2025 13:03:18 +0000
Received: by outflank-mailman (input) for mailman id 1134297;
 Tue, 30 Sep 2025 13:03: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 1v3a0i-0004XL-M5
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 13:03:16 +0000
Received: from mail177-10.suw61.mandrillapp.com
 (mail177-10.suw61.mandrillapp.com [198.2.177.10])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d312ca74-9dfd-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 15:03:15 +0200 (CEST)
Received: from pmta14.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail177-10.suw61.mandrillapp.com (Mailchimp) with ESMTP id
 4cbdXK3qgsz5Qnvdr
 for ; Tue, 30 Sep 2025 13:03:13 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 a5137b709c9c4a2688812d9ae99bb066; Tue, 30 Sep 2025 13:03: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: d312ca74-9dfd-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1759237393; x=1759507393;
	bh=nVkUW10tz1ndJ3cdjbzVv4cAu+37K8/HQfBTRvus01M=;
	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=hKoKaSFZUVjOc/UJ6Sgi8vSn2m64q86YsOceznV5j/sl2ppIOP2SfMKk/Chsy2JRB
	 MaU4uoaMaZsO8wrS8K7wt5C4652e5r4BrluWxUxBFC6u6cTn0HxY4+riX6JGSS1Ny0
	 PAHvs1/xWLIUvX0FW1vSf0RtPHDgcB9PmRWGgp4iAIfajG/FpUO5RzM2c3M/dSjMO3
	 keuYKQnk+XIM1Uhnq2qP1+VSbjT//cz82a3kW8OmVz0nLcH9U5Y4VRDjUMhgUOT2qP
	 QFAGKk01NGuO9DLyEIFAyhlbDPZtB+BZ6EO9JSimhE22eKloxLar7qzGTLVhWZmjkI
	 rVCGTCgOPPDdw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1759237393; x=1759497893; i=teddy.astie@vates.tech;
	bh=nVkUW10tz1ndJ3cdjbzVv4cAu+37K8/HQfBTRvus01M=;
	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=SZ1S/S57VNtVZU63KjN8yLaoXVlnM5Ge3f3L8QQHNtan3By6T58StBdhNcvcuPAOf
	 c8AW5VzC1Lnj0EU0x4uod+kyFQFG4TfS/KvFwIiNvCrhP0BU0JQDwc2xp2toTP7OrQ
	 K6D20cvCb66+Dxcf1yGTZ7LddN6hfSTpKpDELHOoOa8Uv2LuumRaoia7KZ2z/cLAoy
	 2QRyObhs6MA/4ZEYWyFSA5XzFkgBKISYntGlNrC0QZnE0YYL9ZOibWMTOnypauxNda
	 SHZxgmQ32k94zQwhfDeDtxyOMctZGd0+PyuvrTkaE/DkFwKB4PePVHgS+GlxweuUid
	 szTeRKYvH35qg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20for-4.21=201/2]=20x86/AMD:=20avoid=20REP=20MOVSB=20for=20Zen3/4?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1759237392193
Message-Id: <6f211ab0-b671-4ea6-88e9-f5cf7fe27a63@vates.tech>
To: "Jan Beulich" 
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Oleksii Kurochko" , xen-devel@lists.xenproject.org
References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com> <6bcaa5b7-4e34-40c9-85e6-48a0a5869b86@suse.com> <485889ed-2820-4bb3-b450-88553dbb719e@vates.tech> <446909d8-f446-42f0-a236-47d5d64ea908@suse.com>
In-Reply-To: <446909d8-f446-42f0-a236-47d5d64ea908@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.a5137b709c9c4a2688812d9ae99bb066?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250930:md
Date: Tue, 30 Sep 2025 13:03:13 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 25/09/2025 =C3=A0 15:02, Jan Beulich a =C3=A9crit=C2=A0:
> On 25.09.2025 14:18, Teddy Astie wrote:
>> Le 25/09/2025 =C3=A0 12:48, Jan Beulich a =C3=A9crit=C2=A0:
>>> Along with Zen2 (which doesn't expose ERMS), both families reportedly
>>> suffer from sub-optimal aliasing detection when deciding whether REP MO=
VSB
>>> can actually be carried out the accelerated way. Therefore we want to
>>> avoid its use in the common case (memset(), copy_page_hot()).
>>
>> s/memset/memcpy (memset probably uses rep stosb which is not affected II=
UC)
> 
> Oops, yes.
> 
>>> Reported-by: Andrew Cooper 
>>> Signed-off-by: Jan Beulich 
>>> ---
>>> Question is whether merely avoiding REP MOVSB (but not REP MOVSQ) is go=
ing
>>> to be good enough.
>>
>> This probably wants to be checked with benchmarks of rep movsb vs rep
>> movsq+b (current non-ERMS algorithm). If the issue also occurs with rep
>> movsq, it may be preferable to keep rep movsb even considering this issu=
e.
> 
> Why? Then REP MOVSB is 8 times slower than REP MOVSQ.
> 

It doesn't match my observations while quickly benching rep movsb vs rep 
movsq+b (fallback) with varying alignments/sizes on Zen3/4 (Ryzen and EPYC)=
.

It's very sensitive to size and aligment, but in many (but not all) 
cases, rep movsb is significantly faster than rep movsq+b. The worst 
cases (mentioned bug) are much slower in both cases, though rep movsq+b 
tend to perform better in these cases.

So unfortunately it's not as simple as rep movsb being (almost) always 
slower, especially with the varied copy sizes and aligments that does 
grant_copy. That's what I would prefer having more data to have a better 
picture.

>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -1386,6 +1386,10 @@ static void cf_check init_amd(struct cpu
>>>    
>>>    =09check_syscfg_dram_mod_en();
>>>    
>>> +=09if (c =3D=3D &boot_cpu_data && cpu_has(c, X86_FEATURE_ERMS)
>>> +=09    && c->family !=3D 0x19 /* Zen3/4 */)
>>> +=09=09setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
>>> +
>>
>> May it be fixed through a (future ?) microcode update, especially since
>> rep movs is microcoded on these archs ?
> 
> I don't know, but I also don't expect that to happen.
> 
> Jan
> 

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Tue Sep 30 15:24:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 15:24:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134323.1472254 (Exim 4.92)
	(envelope-from )
	id 1v3cD7-0004G6-Q0; Tue, 30 Sep 2025 15:24:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134323.1472254; Tue, 30 Sep 2025 15:24: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 1v3cD7-0004Fz-Ma; Tue, 30 Sep 2025 15:24:13 +0000
Received: by outflank-mailman (input) for mailman id 1134323;
 Tue, 30 Sep 2025 15:24: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 1v3cD6-0004Fq-EC
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 15:24:12 +0000
Received: from SJ2PR03CU001.outbound.protection.outlook.com
 (mail-westusazlp170120002.outbound.protection.outlook.com
 [2a01:111:f403:c001::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 809f29dd-9e11-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 17:24:08 +0200 (CEST)
Received: from DS7P220CA0059.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:224::11) by
 BL3PR12MB6523.namprd12.prod.outlook.com (2603:10b6:208:3bf::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 15:23:58 +0000
Received: from DS2PEPF0000343A.namprd02.prod.outlook.com
 (2603:10b6:8:224:cafe::5) by DS7P220CA0059.outlook.office365.com
 (2603:10b6:8:224::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9160.18 via Frontend Transport; Tue,
 30 Sep 2025 15:23:58 +0000
Received: from satlexmb07.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_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Tue, 30 Sep 2025 15:23:57 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Tue, 30 Sep
 2025 08:23:54 -0700
Received: from satlexmb07.amd.com (10.181.42.216) 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, 30 Sep
 2025 10:23:54 -0500
Received: from [172.18.5.186] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Tue, 30 Sep 2025 08:23:54 -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: 809f29dd-9e11-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=A2/o68SE1sKweYuDVAC2fB0UaXRri7uM3Ioe9iAdYTyrZFC7y/7d4A3vzjkB+I7gvOzmMtXz3q601ygCDeaNE3Rc0EHUP56fLjzwnKArIqHZiZtwn5hBLwpBWpDXoZHEsfsUVJH0SZZXjomi6q1cHtlmrVX96rW85KSBjqdGEgb7h4+NgumdHEmwqaxfF3x4Ph/oEICBtuHDzE/QOpiFmmT0cAWCvB9drQ8Xp/c/yHOJbxpSRdVZy3YIOZZvBv6fld6esg9IHW2HdD1U907pGV4u7wkGATCt/GS1UNOk0McuvYdLodOj+rb61zijW+9XBbJlBPa+M80ig0obEHyFHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=c8+avBMTWF8BDTJ8mn4H08nFm+VIipi6dSyO1jFkMWE=;
 b=RjjfM/IZ9xJMw7t0XTEdrQ9+ClGi9bUZxha1Byb3TWmp1qgzBqZbJFUwYOAtzzSv8HeiTF9zH+8OrB6OO4urEHiQffRT3ZuIyneIGQlPI0E3R/C7M43zx1jUn2NJtYypyr3e2MDJFYJxTBEpL5RUIpzLVSwYvZAV3fuvrJrUghj0IUwf9dM1wTjU7lanxd8pH4v9Qn3raVzHMp7rFmYOyplpego/iXyPt0CQW9dpkTzG3KLo/Vt2Oe4mxF0L6wKys7+Wxg4Cv1vegN23HSNBKCNYv4fiRjP/Zgfr9YVfub4ur/9FwicdDAX5S/l+4pfWyudNn4fGL0FfvRVBHb19jQ==
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=c8+avBMTWF8BDTJ8mn4H08nFm+VIipi6dSyO1jFkMWE=;
 b=VrjKTcUJX/tL5SEV+/Q6VK1yVfS2zqD8Cw1EARFlMNVqQ6E6ROC7gzlJMjYMgLzzC+vxeoHA3BItsowCMpQIaBLN1XS9qZzC/i154nvSxiGK4RC5Q3Hc8lekbMkfH5LkGggsfbWCbE8Vs47n3NW+h+sECUj2/mpi638ZxRVTroQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <1db69ecb-98a4-4135-aa9f-4cbb8bfb6d7f@amd.com>
Date: Tue, 30 Sep 2025 11:23:56 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 1/8] tools/configure: Introduce deps on json-c lib
 for libxl
To: Anthony PERARD , 
CC: Anthony PERARD , Juergen Gross
	
References: <20250929120756.46075-1-anthony@xenproject.org>
 <20250929120756.46075-2-anthony@xenproject.org>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250929120756.46075-2-anthony@xenproject.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF0000343A:EE_|BL3PR12MB6523:EE_
X-MS-Office365-Filtering-Correlation-Id: 9c2e105d-ef17-4f29-f3b7-08de00356029
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?cEJwWHFXUGdidEpXcUZXVS9FSS9GZ2RPUzd4Tm1QRDZ5VDcwNVhHNm1PVi9C?=
 =?utf-8?B?Q2FLRlVuVkZQcWNOcHFsN3BVSTJ4VjBmTGMvQW5wSkRseUc4WURvT0dFV1Zq?=
 =?utf-8?B?eWgvL3ozeGlXV2tDM1BxL1R0b2dUakNGSzF1V2tOOHBhNit0THZER0gzUlR0?=
 =?utf-8?B?eWduUWJxc0Z1WEdCWENHb0QvUFJCNWpDVHZJU0RTcGY3c3B3YmhnaTRpUnhl?=
 =?utf-8?B?UWN6NUlmcWIyTituKzIwWkhKN2VsdGMzbWpaNENFUEZYb1JkRk15N2VDUUlU?=
 =?utf-8?B?NGoxNDJKNXY0RnAvV1BEN1ZHa1BUTnlCWktYM281UU5QcEJYeVRoYU9NU1d3?=
 =?utf-8?B?OEw3alhSMHl5dFFPVFpHcVpTTXlnd3BvaUx5ZUM5VVdpRzZSak0vNmRjVVYr?=
 =?utf-8?B?L3VuY0xoMUxPY0hLd2prSUk5cEhLVVZXRzRqMS9iQlgveU1Yb3g0S3VnQjBO?=
 =?utf-8?B?YVRQT1g0WjhWbUZpU3pYc3RaZHZEdzJxTWpZZ3N4M2tZR2lhSklmay9NWGJI?=
 =?utf-8?B?dS9veHdraFl4VTh0NWEwRTZpdjdzUXJTMzVxclphQjF3N3BIRkFUb216QTlx?=
 =?utf-8?B?S21QUUk0RHZsMkRFZGxBUEJvWUlOU0J3RW4zT1hFMUNDcFBERXJKdFdvL00w?=
 =?utf-8?B?ZUd1UlZCa3JMaXBjV0NGNi8vRXRuNXg4VStFK0QrUnJ5S1UxUnZiOHlaL1ZP?=
 =?utf-8?B?c3BHS0xIVS9pRElzcVNsOUQwQTRvbE9NY0hoK0pESWdsYlM2V2owbkVKSFN6?=
 =?utf-8?B?bVhqVzNqVW9aY1JJOVJpamwxcktrZ25qREE3TUw0TWhIWEtGMEFYNVd6TEpM?=
 =?utf-8?B?RWJTL1pyV2gzTFZaRVlmbnRRU0E1cWlqeFJUZXcyTGxlcjZJNFIrUlRKbFhD?=
 =?utf-8?B?NU1HR1dwaDlzYmtsaG8ycXh0WjkwR1JDTUpwaUlYOEtPd2ZrRjhCc1Y5WGt0?=
 =?utf-8?B?TUNWRlA0M2YrbmRkajhpbWtxS1VkTjNidXBmbDB1NnhZY2lDdXBCalVxeCtm?=
 =?utf-8?B?dEZWcEVwWUN3WGRaMU5VRmtaQTlxTDgvaUplYnFpUWxIRmZHSkVoRXFmbFhN?=
 =?utf-8?B?aURoNlJGZ25ramw2V0k4SFZhaVNuSXUrNXBRSXpGbTJqT2psY0haWDh2a04y?=
 =?utf-8?B?M1FyeVZ1aFhlMnNpSzdmS2F0UVJFU3ZIa2s0a2pJUEZscnBYVXN3UnVJaWdU?=
 =?utf-8?B?L01lSWgvMktiNHFKZlY5ZmMwYVRHalo4REhVa2FPVW9FU1ZSdTg0eVkyUEFE?=
 =?utf-8?B?QlBwandwUWhwcGNHSU4yVUlLOXFJV0s0eXN4SUw3K3I3SkE2S0VjTUdqdjE4?=
 =?utf-8?B?OXJZdG90aEtpU29GSzgvWkxSTDFyTnpYZGZVSGpWb01XQzNsMDNOZGRKN29S?=
 =?utf-8?B?dDMyYTU2N0l2VTE0RGZUN1NicUxPaEVyUkhBZm80Tkt3eFlpMW5POFo0Ykxx?=
 =?utf-8?B?a091MVozbk80ZGhRYmJodUgyODMyNlhwbTVoWEVKZWNFa2Q1TDRDclE3S3lL?=
 =?utf-8?B?K3crYWZzazl3R0grSDgrSkwvU0hGdTFxTld1NUtvMys2M3czQXZ0eHpLSFZM?=
 =?utf-8?B?Y1lOZTRoUmVnRWdHYlZla040U042TSsxSjdFS3Nqc2pqQis5dnJwbnc2S05T?=
 =?utf-8?B?ell4Rk1FRklHWnlqYjJocFZwckZoQUlYemFCZmpFM3lCUExEVUw4SjU2MEZL?=
 =?utf-8?B?WUNrWmdiWkN5Q2ZOYVdQWU1tWDFxL215MnZrVm5HanZqWkFiWHdVS29BcG5v?=
 =?utf-8?B?ZWhLcld2Z1hiQkNDQi9uejkxNUFiRzgvTzgyL0dxWEdsbkRUTkcyS2ZScHov?=
 =?utf-8?B?dHpiN0MzemptdU1oWW8rNEZmcGhRdEVIZy9vWjlnZFB4dmw2Y2RCc3AweEZi?=
 =?utf-8?B?My9pSHJES1diMU5MZ1o2ekdUMURnWjc5bzh0UHJMbjBZNGE0NGk1MXdBanNi?=
 =?utf-8?B?ejF6clBEanFnQUhQT2ZBeDdEL29ZWGRnYWMvMktoZWMrQ2tza2VRRkhncXJW?=
 =?utf-8?B?QkJUcTQwTGtodW9URUxRdGE2UWZWc2paNTUwdEVNZEU4ODNNcThuY3REbVEx?=
 =?utf-8?B?UEE2OGtuMWY1ZHc4U0JXcDQrdldxZFpCUTNtUkJUSjBTbStRZnFNMGoyTm9n?=
 =?utf-8?Q?DLz4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 30 Sep 2025 15:23:57.9094
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c2e105d-ef17-4f29-f3b7-08de00356029
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6523

On 2025-09-29 08:07, Anthony PERARD wrote:
> From: Anthony PERARD 
> 
> To replace yajl.
> 
> Introduce XEN_JSON_LIBS variable, to be able to remove "-lyajl" later.
> 
> As a first step, the variable will have both or only -lyajl. Then
> commit "configure: Use json-c by default, fallback to yajl" will make
> a change to only have one or the other once the code is ready to build
> with only json-c.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Jason Andryuk 

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 15:37:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 15:37:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134339.1472264 (Exim 4.92)
	(envelope-from )
	id 1v3cQ1-0005zF-0s; Tue, 30 Sep 2025 15:37:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134339.1472264; Tue, 30 Sep 2025 15:37: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 1v3cQ0-0005z8-UB; Tue, 30 Sep 2025 15:37:32 +0000
Received: by outflank-mailman (input) for mailman id 1134339;
 Tue, 30 Sep 2025 15:37: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 1v3cPy-0005z2-So
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 15:37:31 +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 5fc20b27-9e13-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 17:37:29 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-62fc0b7bf62so9070436a12.2
 for ; Tue, 30 Sep 2025 08:37:29 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-634a3ae3080sm10224554a12.34.2025.09.30.08.37.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 08:37: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: 5fc20b27-9e13-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759246649; x=1759851449; 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=fuMyB6rXhVK0PZTSNrISLSFJ6oW2z4Pi9ijtTa3093s=;
        b=SUaUG5uFjuG23yd/8uR1jkpcnJ5AgUgWV8jozF9l0ojKI/ePO3gn8mwBoish3b9Nln
         KG6yE/H7MrFUNPnNOMnfQuqOotSvpGx7myZB+bhiS4ijRv2TPRC0K3S8SmqzIMc2UdYx
         Cv7l/2FTjaXu1oGlM3PIRoZNEVZWrQtIWnw3i8n/sKiueELeq9zvXsuj+PKdMtR55UMG
         v3bP2Myl8a94w6o6lDO7154ScA8nBz3xQ0Yg2oRE6vAJg/rm3b16IZjIAEGX9kZC2KNS
         E9jXol7zT7ts6oGxoxwUF/snUoTP1PtwliuSgp7sF0im3wRgiKzG047iQdXi9bbH2UFM
         QDmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759246649; x=1759851449;
        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=fuMyB6rXhVK0PZTSNrISLSFJ6oW2z4Pi9ijtTa3093s=;
        b=CkR1UB4xuD1QBTiesS+GfescZ+VfSGMlmeGnbd0CecHPFDQ7zjFdGbUvj58/05GOBs
         axvbTn5m0d+6m5f0Dc3CJkVxAqcyQsb3T4pX4ixlJ3LWqM5Q/YVKimKACq5l3gFKvGFb
         h40VY1hwJ8LX4F/AnRmWec09F1DU3pNPy2GSJBtzRZL25z7l+mjP1bZ0KeYQTmLrRndR
         rUZPFOnC3sjl39UgXH7j+ySKqBgIPy/9HYARdgFuInum08VSe/GWPY7nT4JNbk7+G61L
         VbqgVqJrxwN1ganW7fwj5Z3PQYWVeHgD7h3H1nmsnJQ3KYpttP1fAr8l9eC4Hgmdcv1W
         w37w==
X-Forwarded-Encrypted: i=1; AJvYcCVJ2Plt1SioQTD6KGD9ha9UF4PKF2KjcBHkglYbpjF+mrs76DO6sP7UEbOnDuTSsEyjyoXGy4BQDNE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzgThW8Vw/uLpIZv/EL5OmSEADMHUXYilAkPsoU1is6OlD6Pd2
	euvN4F58fW040y+ejcO3zz+5XSMktpNuH3yJlZFrh7XI6uqGNw5rtq6j
X-Gm-Gg: ASbGncuujhwUx3BXHM0HyMdWRImaEciFKyuKF3v6LAWvZXI8f8wNbSBrRuBBouDA4LC
	s10tR6++M/un9PsbYB8ifW+ay2SeDL/BZPUxsPCV84e5mIS+NIVtxsvn3E+POGTSMRmHYdAUY3d
	J35Lqw7HpwLWD8v97NcBd6WqHXLKTNhlWZFy55uTVmz+MixPdWwh3en821Q7B1S4abn6gqWLAdh
	sX13stVGwg/rakbgEMJ6pSaBfZf55gIDloKfluesvaHadwbg4ipTv3HkeTDCYSHxCxnGyxOxw+y
	0t7on5dhUqYIshgAXT1TDxPGhAPF5Iv1Gy/nGY+Zaahg2eumQTuDnEveh7IQyMBFOiCZfkGIoo8
	RfP03BSPlI18QaZDs2zK5i+IVd9ELdBb739QiwoqWN1ZbyQTEeHltW0wiRWSlrooMVzFTb0+iWM
	a+SIhkWgWiwQAwr8GtYdAv
X-Google-Smtp-Source: AGHT+IFPDKcoUyqOCgUkLYGUoDNbhv85t3FajzvRctj2MdnQP3aXtlMZP9zpIUFQS0rKgiLoAXfgcw==
X-Received: by 2002:a05:6402:4402:b0:634:4e0:8360 with SMTP id 4fb4d7f45d1cf-63678bbacc4mr359560a12.2.1759246647860;
        Tue, 30 Sep 2025 08:37:27 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------pqLEyfA0yoXTd9U4TL07n00L"
Message-ID: <577daeb5-d43f-4172-9a3b-2062c01b8d45@gmail.com>
Date: Tue, 30 Sep 2025 17:37:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v4 17/18] xen/riscv: add support of page lookup by GFN
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: 
 <5065d9f1552fd940cc19087d8e00a0fa3519e66c.1758145428.git.oleksii.kurochko@gmail.com>
 <854ff53f-5af0-43bf-83b0-8e1e1e0deefc@suse.com>
Content-Language: en-US
In-Reply-To: <854ff53f-5af0-43bf-83b0-8e1e1e0deefc@suse.com>

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


On 9/22/25 10:46 PM, Jan Beulich wrote:
> On 17.09.2025 23:55, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/p2m.c
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -978,3 +978,189 @@ int map_regions_p2mt(struct domain *d,
>>   
>>       return rc;
>>   }
>> +
>> +
> Nit: No double blank lines please.
>
>> +/*
>> + * p2m_get_entry() should always return the correct order value, even if an
>> + * entry is not present (i.e. the GFN is outside the range):
>> + *   [p2m->lowest_mapped_gfn, p2m->max_mapped_gfn]).    (1)
>> + *
>> + * This ensures that callers of p2m_get_entry() can determine what range of
>> + * address space would be altered by a corresponding p2m_set_entry().
>> + * Also, it would help to avoid cost page walks for GFNs outside range (1).
>> + *
>> + * Therefore, this function returns true for GFNs outside range (1), and in
>> + * that case the corresponding level is returned via the level_out argument.
>> + * Otherwise, it returns false and p2m_get_entry() performs a page walk to
>> + * find the proper entry.
>> + */
>> +static bool check_outside_boundary(gfn_t gfn, gfn_t boundary, bool is_lower,
>> +                                   unsigned int *level_out)
>> +{
>> +    unsigned int level;
>> +
>> +    if ( (is_lower && gfn_x(gfn) < gfn_x(boundary)) ||
>> +         (!is_lower && gfn_x(gfn) > gfn_x(boundary)) )
> I understand people write things this way, but personally I find it confusing
> to read. Why not simply use a conditional operator here (and again below):
>
>      if ( is_lower ? gfn_x(gfn) < gfn_x(boundary)
>                    : gfn_x(gfn) > gfn_x(boundary) )

I am okay with both options. If you think the second one is more readable then I
will use it.

>> +    {
>> +        for ( level = P2M_ROOT_LEVEL; level; level-- )
>> +        {
>> +            unsigned long mask = PFN_DOWN(P2M_LEVEL_MASK(level));
> Don't you need to accumulate the mask to use across loop iterations here
> (or calculate it accordingly)? Else ...
>
>> +            if ( (is_lower && ((gfn_x(gfn) & mask) < gfn_x(boundary))) ||
>> +                 (!is_lower && ((gfn_x(gfn) & mask) > gfn_x(boundary))) )
> ... here you'll compare some middle part of the original GFN against the
> boundary.

Agree, accumulation of the mask should be done here.

>> +            {
>> +                *level_out = level;
>> +                return true;
>> +            }
>> +        }
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> +/*
>> + * Get the details of a given gfn.
>> + *
>> + * If the entry is present, the associated MFN will be returned and the
>> + * p2m type of the mapping.
>> + * 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)
>> +{
>> +    unsigned int level = 0;
>> +    pte_t entry, *table;
>> +    int rc;
>> +    mfn_t mfn = INVALID_MFN;
>> +    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
>> +
>> +    ASSERT(p2m_is_locked(p2m));
>> +
>> +    if ( valid )
>> +        *valid = false;
> Wouldn't you better similarly set *t to some "default" value?

I think it makes sense. I will set it to p2m_invalid.

>> +    if ( check_outside_boundary(gfn, p2m->lowest_mapped_gfn, true, &level) )
>> +        goto out;
>> +
>> +    if ( check_outside_boundary(gfn, p2m->max_mapped_gfn, false, &level) )
>> +        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, false, level, &table, offsets[level]);
>> +        if ( (rc == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
>> +            goto out_unmap;
> Getting back P2M_TABLE_MAP_NOMEM here is a bug, not really a loop exit
> condition.

Oh, I agree. With the second argument set to|false|,|rc = P2M_TABLE_MAP_NOMEM|
will never be returned, so it can simply be dropped.


>
>> +        if ( rc != P2M_TABLE_NORMAL )
>> +            break;
>> +    }
>> +
>> +    entry = table[offsets[level]];
>> +
>> +    if ( pte_is_valid(entry) )
>> +    {
>> +        if ( t )
>> +            *t = p2m_get_type(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(P2M_LEVEL_ORDER(level), UL) - 1));
> May want to assert that the respective bits of "mfn" are actually clear
> before this calculation.

ASSERT(!(mfn & (BIT(P2M_LEVEL_ORDER(level), UL) - 1)));
Do you mean something like that?

I am not 100% sure that there is really need for that as page-fault exception
is raised if the PA is insufficienlty aligned:
  Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv39 supports
  2 MiB megapages and 1 GiB gigapages, each of which must be virtually and
  physically aligned to a boundary equal to its size. A page-fault exception is
  raised if the physical address is insufficiently aligned.

>
>> +        if ( valid )
>> +            *valid = pte_is_valid(entry);
>> +    }
>> +
>> + out_unmap:
>> +    unmap_domain_page(table);
>> +
>> + out:
>> +    if ( page_order )
>> +        *page_order = P2M_LEVEL_ORDER(level);
>> +
>> +    return mfn;
>> +}
>> +
>> +static mfn_t p2m_lookup(struct p2m_domain *p2m, gfn_t gfn, p2m_type_t *t)
>> +{
>> +    mfn_t mfn;
>> +
>> +    p2m_read_lock(p2m);
>> +    mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL);
> Seeing the two NULLs here I wonder: What use is the "valid" parameter of that
> function?

`valid` parameter isn't really needed anymore. It was needed when I had a copy
of `valid` bit with real (in PTE) valid bit set to 0 to track which one pages
are used.
I will drop `valid` parameter.

> And what use is the function here when it doesn't also return the
> order?

It could be used for gfn_to_mfn(), but p2m_get_entry() could be used too, just
not need to forget to wrap by p2m_read_(un)lock() each time when p2m_get_entry()
is used. Probably, it makes sense to put p2m_read_(un)lock() inside p2m_get_entry().
I think we can leave only p2m_get_entry() and drop p2m_lookup().

>   IOW I'm not sure having this helper is actually worthwhile. This is
> even more so that ...
>> +    p2m_read_unlock(p2m);
>> +
>> +    return mfn;
>> +}
>> +
>> +struct page_info *p2m_get_page_from_gfn(struct p2m_domain *p2m, gfn_t gfn,
>> +                                        p2m_type_t *t)
>> +{
>> +    struct page_info *page;
>> +    p2m_type_t p2mt = p2m_invalid;
>> +    mfn_t mfn;
>> +
>> +    p2m_read_lock(p2m);
>> +    mfn = p2m_lookup(p2m, gfn, t);
> ... there's a locking problem here: You cannot acquire a read lock in a
> nested fashion - that's a recipe for a deadlock when between the first
> acquire and the 2nd acquire attempt another CPU tries to acquire the
> lock for writing (which will result in no further readers being allowed
> in). It wasn't all that long ago that in the security team we actually
> audited the code base for the absence of such a pattern.

Oh, missed such case. Thanks for explanation and review.

~ Oleksii

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



  
    
  
  
    


    

    
On 9/22/25 10:46 PM, Jan Beulich wrote:

    

    

      
On 17.09.2025 23:55, Oleksii Kurochko wrote:


      

        
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -978,3 +978,189 @@ int map_regions_p2mt(struct domain *d,
 
     return rc;
 }
+
+


      

      
Nit: No double blank lines please.



      

        
+/*
+ * p2m_get_entry() should always return the correct order value, even if an
+ * entry is not present (i.e. the GFN is outside the range):
+ *   [p2m->lowest_mapped_gfn, p2m->max_mapped_gfn]).    (1)
+ *
+ * This ensures that callers of p2m_get_entry() can determine what range of
+ * address space would be altered by a corresponding p2m_set_entry().
+ * Also, it would help to avoid cost page walks for GFNs outside range (1).
+ *
+ * Therefore, this function returns true for GFNs outside range (1), and in
+ * that case the corresponding level is returned via the level_out argument.
+ * Otherwise, it returns false and p2m_get_entry() performs a page walk to
+ * find the proper entry.
+ */
+static bool check_outside_boundary(gfn_t gfn, gfn_t boundary, bool is_lower,
+                                   unsigned int *level_out)
+{
+    unsigned int level;
+
+    if ( (is_lower && gfn_x(gfn) < gfn_x(boundary)) ||
+         (!is_lower && gfn_x(gfn) > gfn_x(boundary)) )


      

      
I understand people write things this way, but personally I find it confusing
to read. Why not simply use a conditional operator here (and again below):

    if ( is_lower ? gfn_x(gfn) < gfn_x(boundary)
                  : gfn_x(gfn) > gfn_x(boundary) )

    

    
I am okay with both options. If you think the second one is more readable then I
will use it.



    

      

        
+    {
+        for ( level = P2M_ROOT_LEVEL; level; level-- )
+        {
+            unsigned long mask = PFN_DOWN(P2M_LEVEL_MASK(level));


      

      
Don't you need to accumulate the mask to use across loop iterations here
(or calculate it accordingly)? Else ...



      

        
+            if ( (is_lower && ((gfn_x(gfn) & mask) < gfn_x(boundary))) ||
+                 (!is_lower && ((gfn_x(gfn) & mask) > gfn_x(boundary))) )


      

      
... here you'll compare some middle part of the original GFN against the
boundary.

    

    
Agree, accumulation of the mask should be done here.



    

      

        
+            {
+                *level_out = level;
+                return true;
+            }
+        }
+    }
+
+    return false;
+}
+
+/*
+ * Get the details of a given gfn.
+ *
+ * If the entry is present, the associated MFN will be returned and the
+ * p2m type of the mapping.
+ * 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)
+{
+    unsigned int level = 0;
+    pte_t entry, *table;
+    int rc;
+    mfn_t mfn = INVALID_MFN;
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
+
+    ASSERT(p2m_is_locked(p2m));
+
+    if ( valid )
+        *valid = false;


      

      
Wouldn't you better similarly set *t to some "default" value?

    

    
I think it makes sense. I will set it to p2m_invalid.


    

      

        
+    if ( check_outside_boundary(gfn, p2m->lowest_mapped_gfn, true, &level) )
+        goto out;
+
+    if ( check_outside_boundary(gfn, p2m->max_mapped_gfn, false, &level) )
+        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, false, level, &table, offsets[level]);
+        if ( (rc == P2M_TABLE_MAP_NONE) || (rc == P2M_TABLE_MAP_NOMEM) )
+            goto out_unmap;


      

      
Getting back P2M_TABLE_MAP_NOMEM here is a bug, not really a loop exit
condition.

    

    
Oh, I agree. With the second argument set to false, rc = P2M_TABLE_MAP_NOMEM
will never be returned, so it can simply be dropped.




    

      



      

        
+        if ( rc != P2M_TABLE_NORMAL )
+            break;
+    }
+
+    entry = table[offsets[level]];
+
+    if ( pte_is_valid(entry) )
+    {
+        if ( t )
+            *t = p2m_get_type(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(P2M_LEVEL_ORDER(level), UL) - 1));


      

      
May want to assert that the respective bits of "mfn" are actually clear
before this calculation.

    

    
ASSERT(!(mfn & (BIT(P2M_LEVEL_ORDER(level), UL) - 1)));
Do you mean something like that?

I am not 100% sure that there is really need for that as page-fault exception
is raised if the PA is insufficienlty aligned:
 Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv39 supports
 2 MiB megapages and 1 GiB gigapages, each of which must be virtually and
 physically aligned to a boundary equal to its size. A page-fault exception is
 raised if the physical address is insufficiently aligned.


    

      



      

        
+        if ( valid )
+            *valid = pte_is_valid(entry);
+    }
+
+ out_unmap:
+    unmap_domain_page(table);
+
+ out:
+    if ( page_order )
+        *page_order = P2M_LEVEL_ORDER(level);
+
+    return mfn;
+}
+
+static mfn_t p2m_lookup(struct p2m_domain *p2m, gfn_t gfn, p2m_type_t *t)
+{
+    mfn_t mfn;
+
+    p2m_read_lock(p2m);
+    mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL);


      

      
Seeing the two NULLs here I wonder: What use is the "valid" parameter of that
function? 

    

    
`valid` parameter isn't really needed anymore. It was needed when I had a copy
of `valid` bit with real (in PTE) valid bit set to 0 to track which one pages
are used.
I will drop `valid` parameter.



    

      
And what use is the function here when it doesn't also return the
order?

    

    
It could be used for gfn_to_mfn(), but p2m_get_entry() could be used too, just
not need to forget to wrap by p2m_read_(un)lock() each time when p2m_get_entry()
is used. Probably, it makes sense to put p2m_read_(un)lock() inside p2m_get_entry().
I think we can leave only p2m_get_entry() and drop p2m_lookup().



    

      
 IOW I'm not sure having this helper is actually worthwhile. This is
even more so that ...


    

    

      

        
+    p2m_read_unlock(p2m);
+
+    return mfn;
+}
+
+struct page_info *p2m_get_page_from_gfn(struct p2m_domain *p2m, gfn_t gfn,
+                                        p2m_type_t *t)
+{
+    struct page_info *page;
+    p2m_type_t p2mt = p2m_invalid;
+    mfn_t mfn;
+
+    p2m_read_lock(p2m);
+    mfn = p2m_lookup(p2m, gfn, t);


      

      
... there's a locking problem here: You cannot acquire a read lock in a
nested fashion - that's a recipe for a deadlock when between the first
acquire and the 2nd acquire attempt another CPU tries to acquire the
lock for writing (which will result in no further readers being allowed
in). It wasn't all that long ago that in the security team we actually
audited the code base for the absence of such a pattern.

    

    
Oh, missed such case. Thanks for explanation and review.

~ Oleksii


  


--------------pqLEyfA0yoXTd9U4TL07n00L--


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 15:40:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 15:40:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134350.1472274 (Exim 4.92)
	(envelope-from )
	id 1v3cSU-0007IN-EK; Tue, 30 Sep 2025 15:40:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134350.1472274; Tue, 30 Sep 2025 15:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3cSU-0007Hv-9X; Tue, 30 Sep 2025 15:40:06 +0000
Received: by outflank-mailman (input) for mailman id 1134350;
 Tue, 30 Sep 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 1v3cSS-0006vF-E0
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 15:40:04 +0000
Received: from BYAPR05CU005.outbound.protection.outlook.com
 (mail-westusazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c000::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ba101e8a-9e13-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 17:40:02 +0200 (CEST)
Received: from BL1PR13CA0448.namprd13.prod.outlook.com (2603:10b6:208:2c3::33)
 by PH8PR12MB6961.namprd12.prod.outlook.com (2603:10b6:510:1bc::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 15:39:58 +0000
Received: from BL02EPF0001A0FE.namprd03.prod.outlook.com
 (2603:10b6:208:2c3:cafe::d5) by BL1PR13CA0448.outlook.office365.com
 (2603:10b6:208:2c3::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9182.10 via Frontend Transport; Tue,
 30 Sep 2025 15:39:58 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BL02EPF0001A0FE.mail.protection.outlook.com (10.167.242.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.9160.9 via Frontend Transport; Tue, 30 Sep 2025 15:39:57 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 30 Sep
 2025 08:39:57 -0700
Received: from [172.18.5.186] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend
 Transport; Tue, 30 Sep 2025 08:39:56 -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: ba101e8a-9e13-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OPTJhLXcESIrOKdyr3LpwmhGAX3o8AnWvO6uJpTMjIGuPl0+onpvy0YdlVCd+IispaV2QRW073HV4eVWb7CN0I8P1CSq6CrftjfZgssUXgROyKK2ydtdNfJyjUof0wvcmztLc6Y+sEZ6AeNBiVkHrS1tAGfckZ9srTPijR68lOUjxmEAaWTMxHWGwF0WZK2prG4zwN0xMSOUZh54YMCSif/xOlUjG60apQDFHkjAHqAJQDAGQ5TRCoITNtdZdrlkpGDC6rMuAaX8UtXjVahM28O1vub+XjR+h/ifX6TfvGFsLpZ60+N1aQyFZIj27PnbowYQ/Yhvaw/URXOr0N4xsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sz9XH8Ox/al+ntoeOLZ0s/yoMY/BogCr6FnNBjGIFN0=;
 b=QoliXGaIY7DtB7dh0OyYR4eEMXYUsYFqok/f79Uf65NVxMhIhDdqBRDwPSSDJ+Bkotox83saB/M9p4Ib8EZl3EJRK/LfDTvIlFXCLcBCef1yXwb0E3J7iqOhnc42cR6/q1uiZ7fzOD52owQZxTHJgB1JvL2cuk2IXe7OKWk6pmvGNZ9NWlzb26iVCtjnwA5sMVLr9vCZEis+EoFNdoVOTr/z3YWP6Votj+P+SiHs/8c/k0zXGlt7ggkkNgADbzyZbLD0fag5IF1GmUtK9Qtaa1SO98so821HhIRPzjsZkifHYQvFkYV8P04dAe9Zont4l5QW6qoslV+ma3GlYAwn4g==
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=sz9XH8Ox/al+ntoeOLZ0s/yoMY/BogCr6FnNBjGIFN0=;
 b=5HIVZls5YXleBCUBsAxBtx2JwwEjT1KgfdEGXsakwb0W6hRKbfBzD6WXkYxXGPeUd4lfBidWZHpXrAcADCK5LD6gI4YcoRog/l9Qmd2X97GFvDKXp9Zn3QAkpqDExk3WuuGXsO1I3WF58y04XfiCVT7NFMdhjSlQFZWCThbuXco=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <5df3df3e-d3a6-4b84-a724-0edb1ce6324d@amd.com>
Date: Tue, 30 Sep 2025 11:39:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2 7/8] configure: Use json-c by default, fallback to
 yajl
To: Anthony PERARD , 
CC: Anthony PERARD 
References: <20250929120756.46075-1-anthony@xenproject.org>
 <20250929120756.46075-8-anthony@xenproject.org>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250929120756.46075-8-anthony@xenproject.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FE:EE_|PH8PR12MB6961:EE_
X-MS-Office365-Filtering-Correlation-Id: ca193ce6-21ab-4534-db1a-08de00379c4e
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?Q1pXK2lKSWxjdVpNYXV3Y0thd1BjelJ3U3RNM2laQTR1Z3kwTCtiTit6K0hn?=
 =?utf-8?B?dytEeVBiaXlrTENHSyt0NWtTNnRuMjJGdE5yL2swRkNqU1J0OEFJYllDSTZy?=
 =?utf-8?B?M2xVYUEzanhQL3NUYTFaMS94Y1MyZUxDV1QyY2FpOG1HenZJL1JleVkwMmZ1?=
 =?utf-8?B?VVdqZHUyaGNFL2NwdWJrSW1HVXhzQTU1Yk43T3c2cFp6NXRmd0ZWUXJkbDl2?=
 =?utf-8?B?U3JVamNjQXdPR2hJM1hrc3ArSkxOR0plM2N3ZmJXR2sySU9VSENqY1VvbXA1?=
 =?utf-8?B?dWtqWTIwN3Z4RU82RXlwU0hJam1tVjdXNTRsSWJ0ZXZjUnNwK09rNU9pUmxo?=
 =?utf-8?B?VTVuMFZHYTY3aXJkdjBNK1pQQ1RRdmxtKzAwZDgzenlrbWJOTlVFajlHOVRQ?=
 =?utf-8?B?NTg1VWQwVmk1QzA2cHk5QVpVWmFEZys2NUtMS0FiYUtLY1RRMEorTVRhMUlC?=
 =?utf-8?B?bFlZbDFqeEFTRm5QWjZtbmZBUy9XSHo3bXdTZkE1eFFxajRmWXI4QS9rMzdE?=
 =?utf-8?B?Tm5nQmkxSGx4S0VRTFM0cno1cDdUS1Q4V0RFUWZVZ3g0ckw5YjZrQmhSRm1T?=
 =?utf-8?B?SXliY1dGUEVOWDFGNHNzN04rNkFpSzhyNXlWNTkveUtQeFFxY1NhNmNmMGF5?=
 =?utf-8?B?ekJiUzAxcGJHcjQxYVJTRDg1Q3FwUjNjSGhDKzNyV2g1NU1YcVBQRjJ6NDZ4?=
 =?utf-8?B?RVZWQ2wwaXJic3NIY2VoU0VhOVplekx2SlZVU05nSCs1U05sMy9SUkdSZW5I?=
 =?utf-8?B?VWxLdXUxTCs1MFhWQis3VTdJQ1NxOENMWVJBNmZEZXZiUXNJbUh3NUlxRC80?=
 =?utf-8?B?RXNJUTJoVitzSFMydnZtTEhmTWdXcXlRNXdETHFCaTc1TGZXbmYwVHB3VUYw?=
 =?utf-8?B?NjdqcWd5NFRDWGgrcE5hZFlrbkkwVGZUTlJGaHJtOE9OaWhaY3pGK2xOMXBR?=
 =?utf-8?B?aVcrYVdsTHlpUkp0TDVFWS9iMlVCMG05S1c5K3JRV0RrRTZIeHduVFE3dEYy?=
 =?utf-8?B?dEkzUk96Z3RXQkZzaC9UUHJQUC93ejNsZzNCSnZKSHdncERkUDdDTitwZnY0?=
 =?utf-8?B?UFAvWHNseUlLMTVUTW8xUU5GRlhOc1JKN0tEZ3NGMlUxUm1NcG1LeWNITWxk?=
 =?utf-8?B?bUlXSFY2MHRXeFhFeStWRmlQTGZnUTZXU0tsVlJTSDNHaitwS29xSHZwZ085?=
 =?utf-8?B?MTdWV3IzcHNQdStqOFBBRE5lbUdBMmhneSt5bGR1NklJcXpHZytib0NERFdS?=
 =?utf-8?B?MWlrcEZlNTA1WkU0bWttOXR5STVsem9DZFh6SlFtaUh0WTlsQjU1RWZLL0ll?=
 =?utf-8?B?bHNLRERXM2hydVdpckNxSE1ERmJqL3hmOFNweVNJektjVlZyM2QxQmhlbC83?=
 =?utf-8?B?U3R5S3FyR0RpeHF0RjM1MDlraDRwdjdkK0poL2g0bVR6VnRMN0tyVVlHMDRO?=
 =?utf-8?B?MzhJbTZqZVl3NzNOYXFod29JT1Q4WEVMUjYvZms0c2Nra2EyMVNONXFrdkEr?=
 =?utf-8?B?NndCQ1VpTGpvekwyeHcxOEhLTkt5cFZHaC9VdElraG5DdjJTVXc2SmsrZ1RR?=
 =?utf-8?B?Y0dwMXJBdGgvLzhOenFNZGZGWVFNVlRMaGtmUDM4Vk1iak5oUXNSOWhGVXh3?=
 =?utf-8?B?cUQ2TmUzK2xpT3VuSUxDY1k4SU0zNkMrS0NBaG9MYkJkcHJVak93VndFczZJ?=
 =?utf-8?B?OG9zZDRVVkZlU29EdHZESXhxeHovdDhmM1dpMUdjK1dzLzArZkZBRHljZEk3?=
 =?utf-8?B?cVNBb1lxTzlwMWRpWjhvVWZaMG54NkMvV2ZLaW5PaW5QMFAwbm1NSmRYT3lh?=
 =?utf-8?B?ODFoQzJvMFpkQTBTZGZmQ2FyRE43dEJMQTZ3SGxLRS9iVUhSNCsxeU1Hek9R?=
 =?utf-8?B?ZXlwZ0VmL2RlKzhCdnhpWkJuT2pyQXhJRUVkK3Zaa2FxdG4rZnFneWswQ1lR?=
 =?utf-8?B?ZWxqYzRPUUphODZCY2tsZ3ljTXlsWVVFd2toU3NnQituQnhTaUY0QUZuUk9n?=
 =?utf-8?B?bkNnZGVMWGZ5SytaQ0JZdVJxalJBU1R0Ylk3SVJtUlpuTFowVm5ZTmd0bkZm?=
 =?utf-8?B?TS9QSzBiY0xDVVpnSVhwOFk3Q0ZjbENaeVUzakhqdjRFdWNCekJHNG9vb2wy?=
 =?utf-8?Q?gAX8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:satlexmb07.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: 30 Sep 2025 15:39:57.7757
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ca193ce6-21ab-4534-db1a-08de00379c4e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A0FE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6961

On 2025-09-29 08:07, Anthony PERARD wrote:
> From: Anthony PERARD 
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Jason Andryuk 

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 15:50:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 15:50:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134367.1472284 (Exim 4.92)
	(envelope-from )
	id 1v3ccg-0000ma-Fr; Tue, 30 Sep 2025 15:50:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134367.1472284; Tue, 30 Sep 2025 15: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 1v3ccg-0000mT-Cg; Tue, 30 Sep 2025 15:50:38 +0000
Received: by outflank-mailman (input) for mailman id 1134367;
 Tue, 30 Sep 2025 15: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 1v3ccf-0000mN-L0
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 15:50:37 +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 3426e015-9e15-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 17:50:35 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-6318855a83fso11551732a12.2
 for ; Tue, 30 Sep 2025 08:50:35 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-67-38.play-internet.pl.
 [109.243.67.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-b400709f036sm367795966b.35.2025.09.30.08.50.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 08: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: 3426e015-9e15-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759247435; x=1759852235; 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=odH/q2GSGoLrrbzqk1O5I44g4duKuQG3XTNgt+lVlzo=;
        b=SgPNF8oxUaBRXzaarg8pCSqFnUDRonIwh7k+fiXhdwmJ7fWOt4Lt6xegcjh8MjRVIP
         FrO9r+Gm37v0NBhkaA53iv4n1hG9u2UMuHBIMi9KjCelZdPUliGxXCsTfS4d+wF5Nysu
         WxDjFzNial3zWgyoGHyX2NrUQsrePIqaYGrd/kfE3Tk+S7LtnzaTjKTxzG0lUa0P7Q0x
         a4DOaZ7w6Rx4yQlKGt5OrBwK6os7yVNrW6hhmfwtmnMztWc7YA9jabkZjpo+itCPH756
         ue8gD+W9X5HX/gUHE3kBMqsV7PnWWF9yxdH5JMSIEhX+RDG9WADUSOBjM9CJAPL9V99m
         DNfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759247435; x=1759852235;
        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=odH/q2GSGoLrrbzqk1O5I44g4duKuQG3XTNgt+lVlzo=;
        b=X58gbOFrmb+dzrZwu0AjJZl2rU+YIaB10PldPTuWwIbcWRdoSX3gfDTyjCtsseC9md
         uATV3mWG75+ydwO382RZls0vcxc8q2RmHApJ1nik8Hs24Fkd4nNqn/5jJcjDJsXWRZV7
         wA2o9KO4x4FB7bsrUQJxFPzGkziE0BIpLrKPQpYWin32uFEFbSRh7z2kyh5qlGiuPO/+
         JsA62z+1Ev2jhpcPM8c0hxCdg1RA8vy9JUu1vIyUy/0LNorwuMMmwuLsxOh/HZjQL7ND
         2Q9iMKDWmsjkMLtpeBdEjyGEZMS+9MYxJ63fmMEYSmPVbLq1fYvhRVsPPB0ihc/pIdGA
         eqtA==
X-Gm-Message-State: AOJu0Yzq09sxqHizrQhHN2rmjICk7/ky/zbczOKx09HHbt3iTMH+GYcW
	WWRJ4wNoWmeScNnBM3xZ7bbMrU3gfSuEbGQAb9kkUaELCb4dmCHK3zit
X-Gm-Gg: ASbGncvfOzyvmLTbC7nOPqj5SleikY/wk1OLv81dk67K9Imt/jswXPeOiR5pX7Ru0fG
	FvBSZbIRKqiLDRo2omkfAFMktIjqkf3TFtUIaaHhaHDI5Q6B2WM3LsrGi2+iDuA/5yKaNI4xUpz
	fZlUOpCNHWmYGVAkPY63dgbOyaCb/Di/QUtyexbxfridhZ2pMyrTu2xWTjNHxybBE/Ob5WoRL6o
	F3EYflYRZe8sH5iQ6klcwSnA5CoXnXG14XLKVOpzi/4TcYygfhrUm7rbe6DYhg+6Gcej5OoiNhx
	SOe2sPpHRgdHKnUzJHvAXl3d4nXgUuTx/VZXITANRIbnjUAhON2/rqAICWDkuDQk94vGCf5n05h
	DGinIGC4y1CSKQtSxXxA8dKc2Gq1E5gwv9k+nIPkSdPwRd7KkHBkhiIGahFq909YAEKSO9NL5gJ
	eeJ51lzuOhYhpmxCY2r3TG
X-Google-Smtp-Source: AGHT+IF6j++ao7mg+MEo2yPj1tSxFY9nd56GYOgI53dtEc4XMCzaE0bHH8iObyoMejB+GLhoX2HyxQ==
X-Received: by 2002:a17:907:9724:b0:b3e:1400:6cab with SMTP id a640c23a62f3a-b46e585cd82mr10862266b.17.1759247434791;
        Tue, 30 Sep 2025 08:50:34 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------r5uiVIgilOaa4Ja1F0UjuQvz"
Message-ID: 
Date: Tue, 30 Sep 2025 17:50:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X
 capabilities
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org,
 Stewart Hildebrand ,
 Jan Beulich 
References: <20250929084149.70560-1-roger.pau@citrix.com>
  
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 9/30/25 2:46 PM, Roger Pau Monné wrote:
> On Mon, Sep 29, 2025 at 05:59:00PM +0200, Oleksii Kurochko wrote:
>> On 9/29/25 10:41 AM, Roger Pau Monne wrote:
>>> I've had the luck to come across a PCI card that exposes a MSI-X capability
>>> where the BIR of the vector and PBA tables points at a BAR that has 0 size.
>>>
>>> This doesn't play nice with the code in vpci_make_msix_hole(), as it would
>>> still use the address of such empty BAR (0) and attempt to crave a hole in
>>> the p2m.  This leads to errors like the one below being reported by Xen:
>>>
>>> d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
>>>
>>> And the device left unable to enable memory decoding due to the failure
>>> reported by vpci_make_msix_hole().
>>>
>>> Introduce checking in init_msix() to ensure the BARs containing the MSI-X
>>> tables are usable.  This requires checking that the BIR points to a
>>> non-empty BAR, and the offset and size of the MSI-X tables can fit in the
>>> target BAR.
>>>
>>> This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
>>> EPYC 9965 processors.  The broken device is:
>>>
>>> 22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
>>>
>>> There are multiple of those integrated controllers in the system, all
>>> broken in the same way.
>>>
>>> Signed-off-by: Roger Pau Monné
>>> ---
>>> Cc: Stewart Hildebrand
>>> Cc: Jan Beulich
>>> Cc: Oleksii Kurochko
>>>
>>> While not strictly a bugfix, I consider this a worthy improvement so that
>>> PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
>>> capabilities.
>> Based on your commit description it looks like a bug as without it, for example,
>> SATA controller can't be used, right?
>>
>>>    Hence I think this change should be considered for inclusion
>>> into 4.21.  There a risk of regressing on hardware that was already working
>>> with PVH, but given enough testing that should be minimal.
>> We have some PVH tests in Xen’s GitLab CI, but I assume that isn’t enough?
> It's a very specific controller, which we don't seem to have any
> examples of in the lab.  The model is in the commit message.  Without
> this fix the device doesn't work as expected when used in PVH dom0
> mode.

Thanks for the explanation.

I think we should consider to have this in 4.21 as it is still a fix of bogus
behavior:
  Released-Acked-By: Oleksii Kurochko

~ Oleksii

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



  
    
  
  
    


    

    
On 9/30/25 2:46 PM, Roger Pau Monné
      wrote:

    

    

      
On Mon, Sep 29, 2025 at 05:59:00PM +0200, Oleksii Kurochko wrote:


      

        
On 9/29/25 10:41 AM, Roger Pau Monne wrote:


        

          
I've had the luck to come across a PCI card that exposes a MSI-X capability
where the BIR of the vector and PBA tables points at a BAR that has 0 size.

This doesn't play nice with the code in vpci_make_msix_hole(), as it would
still use the address of such empty BAR (0) and attempt to crave a hole in
the p2m.  This leads to errors like the one below being reported by Xen:

d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area

And the device left unable to enable memory decoding due to the failure
reported by vpci_make_msix_hole().

Introduce checking in init_msix() to ensure the BARs containing the MSI-X
tables are usable.  This requires checking that the BIR points to a
non-empty BAR, and the offset and size of the MSI-X tables can fit in the
target BAR.

This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
EPYC 9965 processors.  The broken device is:

22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)

There are multiple of those integrated controllers in the system, all
broken in the same way.

Signed-off-by: Roger Pau Monné<roger.pau@citrix.com>
---
Cc: Stewart Hildebrand<stewart.hildebrand@amd.com>
Cc: Jan Beulich<jbeulich@suse.com>
Cc: Oleksii Kurochko<oleksii.kurochko@gmail.com>

While not strictly a bugfix, I consider this a worthy improvement so that
PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
capabilities.


        

        
Based on your commit description it looks like a bug as without it, for example,
SATA controller can't be used, right?



        

          
  Hence I think this change should be considered for inclusion
into 4.21.  There a risk of regressing on hardware that was already working
with PVH, but given enough testing that should be minimal.


        

        
We have some PVH tests in Xen’s GitLab CI, but I assume that isn’t enough?


      

      
It's a very specific controller, which we don't seem to have any
examples of in the lab.  The model is in the commit message.  Without
this fix the device doesn't work as expected when used in PVH dom0
mode.

    

    
Thanks for the explanation.

I think we should consider to have this in 4.21 as it is still a fix of bogus
behavior:
 Released-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii


  


--------------r5uiVIgilOaa4Ja1F0UjuQvz--


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 17:44:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 17:44:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134393.1472294 (Exim 4.92)
	(envelope-from )
	id 1v3eOx-0005v5-7e; Tue, 30 Sep 2025 17:44:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134393.1472294; Tue, 30 Sep 2025 17:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1v3eOx-0005uy-4H; Tue, 30 Sep 2025 17:44:35 +0000
Received: by outflank-mailman (input) for mailman id 1134393;
 Tue, 30 Sep 2025 17:44: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 1v3eOv-0005ur-TK
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 17:44:34 +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 1e90c530-9e25-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 19:44:31 +0200 (CEST)
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com (2603:10a6:20b:2d7::20)
 by VI1PR03MB6269.eurprd03.prod.outlook.com (2603:10a6:800:13c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.17; Tue, 30 Sep
 2025 17:44:24 +0000
Received: from AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b]) by AM9PR03MB7025.eurprd03.prod.outlook.com
 ([fe80::bdd:3097:e48c:6c4b%5]) with mapi id 15.20.9160.015; Tue, 30 Sep 2025
 17: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" 
X-Inumbo-ID: 1e90c530-9e25-11f0-9809-7dc792cee155
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EaeKvMcYk+RttFjx6vdlsKRn9ng2n949mWuLDIwYOGh1R300L6DLtl8oOLvCkAKu/AVfpMidiy9RP+putACDt+AQVNBWPfIVtoiwaSSHtnVpkafGuDZTwTyevG2S5Gd+eK9EAcY/ATLBpawYj+9b4SHHlWAlM/8gtPS/ry39eCHPa5c/ErDEFwg0HWgC20gchPzucTqm+YqOK1VYwtmvretdOhnJexXsNkFQ1ajItut6spH5LfyyskeXRCQcXfHyw4ULdvZqAWTl/Pm1+fl+p/XxkutCTX4AJGN5e7Ror3xbU4Jc5crsPCge0hBxdZTfXl/l3FnQ33wxDaYkzklhDQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=detDOakbFZyYY+f8Axm7fNQyZuXhP3koC2LbQJDRUq8=;
 b=dNs+K+yWFp7wLxtcnFj15IZj38R/QO/vQ5w6fycZN6OEUolfLmWU8mm0AP8GX/PO9aNfzkvf7j891kL+79/k5jQcen+23juNAD7r1/dRX18CBf7dNki7c4+Xl9UmBYV4gKqjLMTPL0JqiT0//Mr7hf4EwyQXKGJjitzs8MXamS5Z+JZzLolm6aB7EMvg/FST0SeXr/9mGjJg3m7VDCUFJZ5Ni8vO7L4oYEQlTDadoOTV9hDTOyqC5tVJz6/JREgGP9jxkDv9PLlyaY/OXw87nUtzIZSI+I4VjGimEGL5kp3iqeKQcSVivHbnSZoeTmMyiYfsjysBBw9Bg93VheeOxg==
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=detDOakbFZyYY+f8Axm7fNQyZuXhP3koC2LbQJDRUq8=;
 b=PkMUYpyxQdtDAkiYgSOHI6Df/Ukju1lWDUxpzufhxyCVSCVsRlFyoZB35tdMfUs+rx0kqGya1okhBQbrfCe5Xo8GohjjiRQ9SWA/ANsN13OWuVVo5fgHQRqjmbMRCfoHrfbLnNthCID3e50kile0+9ehQmaBw+acG9gAAtZpV6UjEnv0Jj95nl5sUwDCKFKYBHoIDOvlX0nicap+wvYRRbMcFuYMIq5AdrsH4BVXVJBpzgDhzBnlMEHaiIaGx6CmX02azoBWQH65t+V3rlOeBEIwEuEE2pPh5/iaydIhH+chBDGJ+fi9gNqTgSIPZNyoEncJjkOuMeSn73wIe5REyg==
From: Oleksandr Tyshchenko 
To: "xen-devel@lists.xenproject.org" 
CC: Michal Orzel , Ayan Kumar Halder ,
	Stefano Stabellini 
Subject: [ImageBuilder][PATCH V2] uboot-script-gen: Add ability to configure
 static event channels
Thread-Topic: [ImageBuilder][PATCH V2] uboot-script-gen: Add ability to
 configure static event channels
Thread-Index: AQHcMjHccr4/QgJ2+kWZ37s9cExJRg==
Date: Tue, 30 Sep 2025 17:44:24 +0000
Message-ID: <20250930174421.2329608-1-oleksandr_tyshchenko@epam.com>
Accept-Language: en-US, 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: AM9PR03MB7025:EE_|VI1PR03MB6269:EE_
x-ms-office365-filtering-correlation-id: 4696c420-4b99-4ccd-c987-08de0048fea3
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|376014|1800799024|366016|42112799006|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?bx87LPqElIoclIcw8H9E0cAyS6ezoNZKsWhx8BKv4AuNB5TeZlWNzSb0e0?=
 =?iso-8859-1?Q?fjC8EUeWcPWDv5zu8wnRt8zOBKzH9k+TUiXCmQf9v1uck0pzvVEGqP5wsQ?=
 =?iso-8859-1?Q?qCLhK7B0WzqniAitBbIhQIH10FRIAFXW9e2B9vQCYNoGypuswi8jZ/EBdy?=
 =?iso-8859-1?Q?B9dnfxfdyG8EcZOZJOJ34wg3edGOYh4+/gKRZpGeSmm7GuE+kImN5D3e1f?=
 =?iso-8859-1?Q?2iWMK52L85DnYC8Cn1bNLcnfl1+xScFANFBoAOT/e2Zl1AKeVGyIjE3XWY?=
 =?iso-8859-1?Q?1YzuZe0GrJkbsYJNEhZRY9U6es67g/L0CBXu/Nv4EiQH3YlGR8QzxSsGZ6?=
 =?iso-8859-1?Q?43+6ix3rW2RlGVlBpD83k5zlYZ1Lx/qgLZ59dhkXwQrDJqPrgiQIjDpYbY?=
 =?iso-8859-1?Q?8IRngDQ3Y6l0B7TLhUgkM+LDrNGMh1KZp4lVL9wCcS9Bjeki0NmtaXa1bh?=
 =?iso-8859-1?Q?6wDtORYUdp3pvg+Gy5Qab330QWcxnPuxxYD3u4zjyRyYrPPftitJBIjOQF?=
 =?iso-8859-1?Q?hRqZwu4grMCzS2nIFnN8skukSVvw0JTBtKSv4ciFwCf91weMgGpSOyA3BN?=
 =?iso-8859-1?Q?JSv16FHq6r1WSQwMuZzzV+/d1twB4gKaurD7isC0wilxDQq7fbCnwYphNZ?=
 =?iso-8859-1?Q?u/tQY6thH132egUCSW9hFuxuIiz6HtpWinx03OJW/AxsB7PHZTvsK8mbuE?=
 =?iso-8859-1?Q?nIg7yw1wBz5fPA7/xCfoeFOoco1p9pDUKiv1X9LwFccEqQaUtczo51YSUb?=
 =?iso-8859-1?Q?Py6ZxaG7N1+AO7ruUuAEgtn1CRZfEzBFkRYuV/YXoJZzv0nRAiF9ElRhf7?=
 =?iso-8859-1?Q?vdMio/dauI5NjNJznp35Kyfi6LGv9RQkjNm13s71GBaQukH3rOc0XR88of?=
 =?iso-8859-1?Q?hTRbH2otCKQPSa1tTCdEn7SfjSFBwnff77zspjFq2B6vsEcCApOdwYKfOH?=
 =?iso-8859-1?Q?1kMChppXywGokYAfkx454CoLE74HiATPWiFRDsNesjedI8xilDxh5tARFN?=
 =?iso-8859-1?Q?r4AKhEyO8/T4tB2EyIAOG+UA+EWhPEGTXSucaLRytAH8t0Jd2+D0z2+tst?=
 =?iso-8859-1?Q?C/9FKfTaklTvRzMsr/pGiuC6ixhFmNRrE9hXwx7E35wR8tN/M9rctVzoI4?=
 =?iso-8859-1?Q?JjBHdRu8z7kvljxo4lMG1C4FqV1O2e7Qj5wKVXW2MP7KI2V8E1n84x7mjl?=
 =?iso-8859-1?Q?cK6ro4IbQUbY4ipEn5qAOApJ2a7XauZlhTVhTyyhF48Y7UBmzF96L3UoB0?=
 =?iso-8859-1?Q?93rxFxZfbMeBI9HDCU8MHWtADZfAa/JkzJtRkOVmK29tjcYsLsPOZlgp6z?=
 =?iso-8859-1?Q?jJkPGUmbdg9CS3gfPirys993q5rMv9nWLynxJToUVcRWkRFtLxbtyczVtz?=
 =?iso-8859-1?Q?ZlCfxdg+pza3ycQePSNFuOBcEmTtgomHroI7RYAcO9KLvk2dDXHqcai2Xk?=
 =?iso-8859-1?Q?fY5dN+FyIDeUGN2wnIHHg4J2ulQrqJ5gStXa1s3VBK8rrIfr3cem0XapwZ?=
 =?iso-8859-1?Q?jE9DCK2AkjUA4G/Oq073QMUp31R1Kxo5eVRkgX1StsDA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR03MB7025.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(42112799006)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?AeIg3I8uwG+4Cx/zItwahrFMbMC2pzntXTn7Gzs2Fgln2OkkwqZANRyG5c?=
 =?iso-8859-1?Q?LdJ6BKcCx+J/7uCmKP6JeozWvVbSqITkmDzHRdK0TrkMdW7/R28U06LK4V?=
 =?iso-8859-1?Q?LbZ0CS8C7dGaSK3rUhLU7H5xUeU3czKmQ5wNzfcwSO02Z/j8WTynwlQMZK?=
 =?iso-8859-1?Q?r8rwAcbj/HaReHp6TORTNljdZ3+OEPRdeB2jbGiS7mCcEaMThhQfGnrQMJ?=
 =?iso-8859-1?Q?821WaHs8MJfzfxzHANf6fY0shuBQGniYtFYIk+0cZQ1W8vl0n0ta3i+57U?=
 =?iso-8859-1?Q?t/BGig939D8J1jkflF1Awh46K73X6iEmYm5QV6E6bQWFdb2fX60RjRYyTD?=
 =?iso-8859-1?Q?ITo5hABdMZXu+VqssiZJZl5U1RsqXZ4U5wAZ8bReeibGBAS344r3zZLDxf?=
 =?iso-8859-1?Q?Be+jQTW2T4nJ/hUg0+spfbSEAYNtC645WZHlHzrEvDjx6/wQxAO1HeUVVG?=
 =?iso-8859-1?Q?5ZT7gxO+oia3E+TDjsrbihldlcL/hY2ynRrk3KjRNQPTTdJBEnHrUZsgPR?=
 =?iso-8859-1?Q?EKbYbgB5xz0XVCdm/fhTWdA0Ad4X1FmPjyQiJYNmbe6IlKL42jQUF34Z+w?=
 =?iso-8859-1?Q?lnbzqDBoyrFErapsR0S4WZyNxSiKOy0gIuh22+eLk2fF8jZMgqCs+OEuZh?=
 =?iso-8859-1?Q?mZ3/Hfnbw/jvKZ8ApN01wkaWFXypYgYwBSVpOMvDz1Qde16NBhjmlPxeOy?=
 =?iso-8859-1?Q?GqYnbhqKM0mn9XrUF/CXqyhFZteo5FkbZtd6ZqaphIi5R1ywK4kCSGGRSP?=
 =?iso-8859-1?Q?/VYw4gVN/CMTGTwZSNBeKN0NlX6fVumBg3quU3TbNvzO99gCpVHB8oPdx5?=
 =?iso-8859-1?Q?Azedj2D3N5i4iakwDfo5Sb0m4cx5q7SxhqGTvfGi9fTJYVwfjQzP/Bzl+l?=
 =?iso-8859-1?Q?7ga4jIJCZIdJPhuhqa+22uMyWsTDaBjaU5om28/bYwU5JWRUMW69Z3ngtt?=
 =?iso-8859-1?Q?rMGOpDWZT/RPjqPYMREOgDuPXpR0bKpC17sbkqlDlOMqXc68U96N/0nSvs?=
 =?iso-8859-1?Q?0k5vYdBOQ9a9MIQePXp6uHkRJkbGyNkcX0LMguuc+Jm+Xau41dYpPvPo8F?=
 =?iso-8859-1?Q?AT+5i47baOoTbVGuvch8eXhtou51Ba+khs7sJ0caD4Chgfv5eAEWDW/Dcy?=
 =?iso-8859-1?Q?2Ma3GIqKh6K9kScoydBlPx3+m1PZdXfN0UwnpjlTpbfYM4DbJ/X9bGxq8+?=
 =?iso-8859-1?Q?CPNLpuhL3Bi3SruSuQ3u+xDMLkJv8n6TtIwCAUrku/oZb6881L7ZXLI4Ta?=
 =?iso-8859-1?Q?Lz2QCYV4YVWGhAMoHZ3nRFcsFAhl8QCdYrJ5hxsXU6xVNPUWC/MdkOM5xR?=
 =?iso-8859-1?Q?w0Z7Z9UcN5Ebyxx/1SGEBG6AH+Kxhk3ffBuA9tiKpjHdicZnSm8B9J0s4K?=
 =?iso-8859-1?Q?d8ceNpcEp4anIk6zL+LiwtOKNuGGOx1CwLuaNalE8DaTLH/2A4Qeg/NDuv?=
 =?iso-8859-1?Q?L8NjVl9L37h1PrXuNBIFygfMkpH0kLlzmjcwhbHSR0EI4wtYrigaWSoJwJ?=
 =?iso-8859-1?Q?re0cZq2hTQO1kXLgIjhhkx9DwVMBZrTrqKsrzqoxCPYh+mLr3uQjCA8jga?=
 =?iso-8859-1?Q?QwFGrY2gMi9YkZXz+zuxmN5ZafRpbRx8OJRwHmtsAGBv1AOJPSYP874pHH?=
 =?iso-8859-1?Q?aAgI9H/UjV6w+yIIBduQBLFWhRRRzNbx6ph7TQg/of3YmbpsMgJZjcaqVS?=
 =?iso-8859-1?Q?UpFod9YyUB6X/gNbnR4=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: AM9PR03MB7025.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4696c420-4b99-4ccd-c987-08de0048fea3
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2025 17:44:24.2309
 (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: A5zNPwW5EuHdkdbZ83xNpVatyLJody826OF5sTmkowo/pTKd7dW40hGCWf3YKmhbAb3O8Z5g6iC1LOOYz5tgN5+UZl3CKncb8vUxDEElnrQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6269

Add DOMU_STATIC_EVTCHNS[number]=3D"local_port remote_dom_idx remote_port; .=
.."
configuration file string option specifying the static event channel
definitions for domain.

For the following example:
DOMU_STATIC_EVTCHNS[0]=3D"10 1 11; 12 1 13"
DOMU_STATIC_EVTCHNS[1]=3D"11 0 10; 13 0 12"

it generates:
fdt mknod /chosen/domU0 evtchn@10
fdt set /chosen/domU0/evtchn@10 phandle <0xfffffffe>
fdt set /chosen/domU0/evtchn@10 compatible "xen,evtchn-v1"
fdt set /chosen/domU0/evtchn@10 xen,evtchn <10 0xfffffffd>
fdt mknod /chosen/domU0 evtchn@12
fdt set /chosen/domU0/evtchn@12 phandle <0xfffffffc>
fdt set /chosen/domU0/evtchn@12 compatible "xen,evtchn-v1"
fdt set /chosen/domU0/evtchn@12 xen,evtchn <12 0xfffffffb>
...
fdt mknod /chosen/domU1 evtchn@11
fdt set /chosen/domU1/evtchn@11 phandle <0xfffffffd>
fdt set /chosen/domU1/evtchn@11 compatible "xen,evtchn-v1"
fdt set /chosen/domU1/evtchn@11 xen,evtchn <11 0xfffffffe>
fdt mknod /chosen/domU1 evtchn@13
fdt set /chosen/domU1/evtchn@13 phandle <0xfffffffb>
fdt set /chosen/domU1/evtchn@13 compatible "xen,evtchn-v1"
fdt set /chosen/domU1/evtchn@13 xen,evtchn <13 0xfffffffc>

Signed-off-by: Oleksandr Tyshchenko 
---
  V2:
   - completely rework based on Stefano-s suggestion at:
     https://patchew.org/Xen/20250929180746.1881872-1-oleksandr._5Ftyshchen=
ko@epam.com/
---
---
 README.md                |  21 ++++++++
 scripts/uboot-script-gen |   7 +++
 scripts/xen_dt_domu      | 103 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 131 insertions(+)

diff --git a/README.md b/README.md
index 7b68cf5..2efac97 100644
--- a/README.md
+++ b/README.md
@@ -218,6 +218,27 @@ Where:
       DOMU_VCPU_HARD_AFFINITY[number,1]=3D"3"
 ```
=20
+- DOMU_STATIC_EVTCHNS[number]=3D"local_port remote_dom_idx remote_port; ..=
."
+  if specified, this parameter allows the configuration of static event ch=
annels
+  for inter-domain communication. Each entry in DOMU_STATIC_EVTCHNS[number=
]
+  specifies one or more event channels for a particular domain.
+  The configuration format for each event channel definition is a set of
+  three values:
+    - local_port: The numeric port number for the local domain's endpoint.
+      This value must be unique within current domain.
+    - remote_dom_idx: The array index of the remote domain (e.g., if
+      connecting to DomU1, this would be `1`).
+    - remote_port: The numeric port number for the remote domain's endpoin=
t.
+
+  Multiple event channel definitions for a single domain can be provided b=
y
+  separating them with a semicolon (;).
+
+  Below is an example that creates two pairs of bidirectional channels bet=
ween
+  two domains:
+  NUM_DOMUS=3D2
+  DOMU_STATIC_EVTCHNS[0]=3D"10 1 11; 12 1 13"
+  DOMU_STATIC_EVTCHNS[1]=3D"11 0 10; 13 0 12"
+
 - DOMU_COLORS[number] specifies the colors (cache coloring) to be used
   for the domain and is in the format startcolor-endcolor
=20
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index 4f92610..e319de8 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -428,6 +428,8 @@ function xen_device_tree_editing()
         fi
     fi
=20
+    xen_dt_build_evtchns_map
+
     i=3D0
     while test $i -lt $NUM_DOMUS
     do
@@ -512,6 +514,11 @@ function xen_device_tree_editing()
=20
         xen_dt_domu_add_vcpu_nodes "/chosen/domU$i" $i ${DOMU_VCPUS[$i]}
=20
+        if test "${DOMU_STATIC_EVTCHNS[$i]}"
+        then
+            xen_dt_domu_add_evtchns "/chosen/domU$i" "$i" "${DOMU_STATIC_E=
VTCHNS[$i]}"
+        fi
+
         add_device_tree_kernel "/chosen/domU$i" "domU${i}_kernel" ${domU_k=
ernel_addr[$i]} ${domU_kernel_size[$i]} "${DOMU_CMD[$i]}"
         if test "${domU_ramdisk_addr[$i]}"
         then
diff --git a/scripts/xen_dt_domu b/scripts/xen_dt_domu
index 8134896..45891b3 100644
--- a/scripts/xen_dt_domu
+++ b/scripts/xen_dt_domu
@@ -37,3 +37,106 @@ function xen_dt_domu_add_vcpu_nodes()
         fi
     done
 }
+
+declare -A EVTCHN_ENDPOINT_TO_PHANDLE_MAP
+
+function xen_dt_build_evtchns_map()
+{
+    local def
+    local local_dom_idx
+    local local_port remote_dom_idx remote_port
+    local new_phandle
+    local local_key remote_key
+
+    for (( local_dom_idx=3D0; local_dom_idx<$NUM_DOMUS; local_dom_idx++ ))
+    do
+        local evtchn_str=3D${DOMU_STATIC_EVTCHNS[$local_dom_idx]}
+        if test -z "$evtchn_str"
+        then
+            continue
+        fi
+
+        IFS=3D';' read -ra evtchn_defs <<< "$evtchn_str"
+
+        # Loop over each definition and process both endpoints of the conn=
ection
+        for def in "${evtchn_defs[@]}"
+        do
+            read -r local_port remote_dom_idx remote_port <<< "$def"
+            if test -z "$local_port" || test -z "$remote_dom_idx" || test =
-z "$remote_port"
+            then
+                echo "Malformed evtchn definition: '$def' in DOMU_STATIC_E=
VTCHNS[$local_dom_idx]"
+                cleanup_and_return_err
+            fi
+
+            # Define keys for both endpoints of the connection
+            local_key=3D"$local_dom_idx,$local_port"
+            remote_key=3D"$remote_dom_idx,$remote_port"
+
+            if [[ "$local_key" =3D=3D "$remote_key" ]]; then
+                echo "Invalid evtchn definition: '$def' in DOMU_STATIC_EVT=
CHNS[$local_dom_idx]"
+                cleanup_and_return_err
+            fi
+
+            # For each key, if it is not already in our map, assign it a n=
ew phandle
+            if [[ ! -v EVTCHN_ENDPOINT_TO_PHANDLE_MAP[$local_key] ]]
+            then
+                get_next_phandle new_phandle
+                EVTCHN_ENDPOINT_TO_PHANDLE_MAP[$local_key]=3D$new_phandle
+                echo "Local endpoint '$local_key' is assigned phandle '$ne=
w_phandle'"
+            fi
+
+            if [[ ! -v EVTCHN_ENDPOINT_TO_PHANDLE_MAP[$remote_key] ]]
+            then
+                get_next_phandle new_phandle
+                EVTCHN_ENDPOINT_TO_PHANDLE_MAP[$remote_key]=3D$new_phandle
+                echo "Remote endpoint '$remote_key' is assigned phandle '$=
new_phandle'"
+            fi
+        done
+    done
+}
+
+function xen_dt_domu_add_evtchns()
+{
+    # $1 - dt path
+    local path=3D$1
+    # $2 - index of the current domain
+    local local_dom_idx=3D$2
+    # $3 - full event channel definition string
+    local evtchn_str=3D$3
+
+    local def
+    local local_port remote_dom_idx remote_port
+    local local_phandle remote_phandle
+    local local_key remote_key
+
+    IFS=3D';' read -ra evtchn_defs <<< "$evtchn_str"
+
+    # Loop over each definition and create a node for it
+    for def in "${evtchn_defs[@]}"
+    do
+        read -r local_port remote_dom_idx remote_port <<< "$def"
+        if test -z "$local_port" || test -z "$remote_dom_idx" || test -z "=
$remote_port"
+        then
+            echo "Malformed evtchn definition: '$def' in DOMU_STATIC_EVTCH=
NS[$local_dom_idx]"
+            cleanup_and_return_err
+        fi
+
+        # Re-create the keys for both endpoints of the connection to look =
up the phandles
+        local_key=3D"$local_dom_idx,$local_port"
+        remote_key=3D"$remote_dom_idx,$remote_port"
+
+        local_phandle=3D${EVTCHN_ENDPOINT_TO_PHANDLE_MAP[$local_key]}
+        remote_phandle=3D${EVTCHN_ENDPOINT_TO_PHANDLE_MAP[$remote_key]}
+
+        if test -z "$local_phandle" || test -z "$remote_phandle"
+        then
+            echo "Could not find phandle for endpoint '$local_key' or '$re=
mote_key'"
+            cleanup_and_return_err
+        fi
+
+        dt_mknode "${path}" "evtchn@$local_port"
+        dt_set "${path}/evtchn@$local_port" "phandle" "hex" "$local_phandl=
e"
+        dt_set "${path}/evtchn@$local_port" "compatible" "str" "xen,evtchn=
-v1"
+        dt_set "${path}/evtchn@$local_port" "xen,evtchn" "hex" "$local_por=
t $remote_phandle"
+    done
+}
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 19:06:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 19:06:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134417.1472304 (Exim 4.92)
	(envelope-from )
	id 1v3ffg-0006uk-M1; Tue, 30 Sep 2025 19:05:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134417.1472304; Tue, 30 Sep 2025 19: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 1v3ffg-0006ud-IV; Tue, 30 Sep 2025 19:05:56 +0000
Received: by outflank-mailman (input) for mailman id 1134417;
 Tue, 30 Sep 2025 19:05: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 1v3fff-0006uV-L4
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 19:05:55 +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 7d24f4af-9e30-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 21:05:54 +0200 (CEST)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS8PR03MB7239.eurprd03.prod.outlook.com (2603:10a6:20b:2eb::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9160.18; Tue, 30 Sep
 2025 19:05:51 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%3]) with mapi id 15.20.9160.017; Tue, 30 Sep 2025
 19:05: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: 7d24f4af-9e30-11f0-9d14-b5c5bf9af7f9
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PdyKFbaiCe0PIlGq5XH8wlOdti9Gl2Bmb5YcLAfM3O1QVRmOMlahVU0qevf3eT/vmw4SLRiS6U36zUVLWhhZnVwAHEimtPPX5X4APVhAg51gzQC45xK7XTFjOdQYXzMQ6OwiiTt52pFlps/aHQbpxZEV8xUDlPaxKPBvXXoTPr92plMV0fywVuF63ux2UzkT7yk/g8uIGz0rDDC+F9JpChnRHqydlZ3vy5q7iu6AVqGnlgw72UjtOM7AvSoc9t2WVimghNTv79861I5o++bMC6Ari7NNWbVIA+Hrr0bsVOiXholeGSjHFcxanLDILPM3npsKQwjhvoaQn11wXcf1FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xkjywitQPGHlxL5NC+7pvJYzTtJ5iqsyPdqmyOf2JRI=;
 b=nD51BzQC0TrhQxJIlSY2wFa0gpmtjBJzCS0JN6C5osfJeZeHqvH7Ys9JfRLWnj5UZ0mFz639qmxa6KhMScCwct3J4fPL0LGKzUfsya0cBX/7b5TLWHzcxpnHUTldl+XaR7gLu2Mr6djihnJPl82M9l9uMFkZYRYFnSU6L81WH6PE2K6KtudWM+eHWQ1m7fvK5PCNWxHvIFRezQDPQ9q7chK4Zyler+eZDeXp3ef6oNwtmSKuIBHqeOYTQR2ymnmWNnQ25K58LxSE619ftRaFEMvxSxYNnELQgvD8RmGMYNDxarKTS3V7psEs8s0esBgwgKGmFYaemqX8JVQgjp73lA==
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=xkjywitQPGHlxL5NC+7pvJYzTtJ5iqsyPdqmyOf2JRI=;
 b=Pyd5yYZUdQsq/gN6986qhAn1+fFkpl2GDhpJkFSwgsGvSoqnKskvE1gDQ4pdnd2Or7Ic2RmTKpTaFJze7YddiP/+rxQnWy5oHPrWwFSqTp/CR4PhqvYB7StmF94tGhm4YFEruLk42LEiDe7Q5EcGcYejoxiRsR8YrxgytmO3Gh2n/6Z5Fe09r04DULQWRSnXBwTKJI8MqVpJv9iZqQ++v/QQL1E4Ce/RpxhBDSwbdNRwwFb+LqLLLmEJ6NkvzlOWsV84i2DLX3Ar8JFpx+K63y+5cPpr7kVa9IhVD5wdn1A6Ebw3LCAvj4uPn3SZqHGFMyQ8tfSKifKmqVIXnmdowQ==
From: Grygorii Strashko 
To: "xen-devel@lists.xenproject.org" 
CC: Grygorii Strashko , Jan Beulich
	, Andrew Cooper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alejandro Vallejo
	
Subject: [PATCH v2] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
Thread-Topic: [PATCH v2] x86/hvm: vlapic: fix RO bits emulation in LVTx regs
Thread-Index: AQHcMj09noDu3viL50aVl0iuVQpwow==
Date: Tue, 30 Sep 2025 19:05:51 +0000
Message-ID: <20250930190550.1166875-1-grygorii_strashko@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR03MB8907:EE_|AS8PR03MB7239:EE_
x-ms-office365-filtering-correlation-id: 8545e7b3-2dcb-4ae4-9b7b-08de00545fa5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?RmdCp1QKrbh2UkhvT+jFW9yfqoSBgQM/2YOwvIXkT0xO6C3BnTkOF+lXjM?=
 =?iso-8859-1?Q?Mv5Ni/FuqMwydhkEUyMk/T6syITraGV8su/BlA6ltVs0InKu/ZGpiBwo1K?=
 =?iso-8859-1?Q?ry4WtgF3fkUk1TEwtDml0tL8KPRA46F4N3upVn1+ODerPWmYOaufMZgwpZ?=
 =?iso-8859-1?Q?YWlYc2UR99M5KwzDv5w0eb1ZYlLDhipIGKS7x+PzYEddIuJKFeTPb05pqu?=
 =?iso-8859-1?Q?A6eoKQoHXXSHniX6CV29dwlmfQf97eZOu+3jrmVSlcun6EFVVMbXMvlpgZ?=
 =?iso-8859-1?Q?yUJT+A9dSgJdWdBHzHRw3HDtDjC0STxT8TvEsVVkYTQficHoUdaZvTBnH8?=
 =?iso-8859-1?Q?sQGLOxTwPQ5Pfm2JAo0OPql8TEIhsnSrelFo3+aSHheswD7TRudNN1yVBc?=
 =?iso-8859-1?Q?DtMNWP+f228Jt6Q45EykpYO2TF9NVT0lHVOFA7SolKmYGtrA8i2rDxupui?=
 =?iso-8859-1?Q?c8bBTtpkboot4r3LK7MjpKSXwmRPdgmgwA2gUJ8HG97t1wq8dP+DbnLfEv?=
 =?iso-8859-1?Q?3qP64OlBHOHThnruEfhLObTixrVbce6TTiWbPegLiHjvvR8Da9OI5AWqdb?=
 =?iso-8859-1?Q?3Rw1u1LieMr2kzAU/tKWCRBDBmAEeRAuWKUe9H5P0R96gQ5ChjcAsrPkS2?=
 =?iso-8859-1?Q?z2lPk4iOnXkBtVEeCKlAktta22x9S/VKLvq9ZUFaQ1A8FJ6zWH1ajc/C/p?=
 =?iso-8859-1?Q?htjsOwp8MrlYy+tonp1kgBa+vIumlvQGwY135P+f8WWFDnedFGLKUU0H31?=
 =?iso-8859-1?Q?Pxjuu/f0TFaNlyic2GzObAq/7goBH47XLFWf3TeATO3rsM9M1jlSbfW/ZX?=
 =?iso-8859-1?Q?mECuurcfkQsXmQuUkzm+nzVxLma6YpamTpR7uRyO23ZtNfkepERjM/t2xR?=
 =?iso-8859-1?Q?K38eIE2KPCpybul5udUgmIFaedH9vQB5ZwTSUpwlO+SxuDmMWRMGivls7c?=
 =?iso-8859-1?Q?Hx0n4tq2wtMWfKoNmCXzIcz/cFN8M4b75yngGxIT1qR+OnQ6rpHHWTkrr+?=
 =?iso-8859-1?Q?MrkyXhXzWXGkEAsIo4Tsafg4JH17i35MHDV5RgE3cMxHQH5HyLEfI80z5e?=
 =?iso-8859-1?Q?Rmw2XDzIMDWriUqdLg4QcmYiCaLDTsm/mxX9kduCCOsgZiYFwWFQsH4Ja+?=
 =?iso-8859-1?Q?as2jVzSUzJnwmpQaPdksnyAZQ417wh77ob8lQzoJMGMV9m2kY9qRqQYN+u?=
 =?iso-8859-1?Q?IkpoPLeBeh51iFPhJQcwQ8hQYqw+vJolDkfAlPcmhoaRiw1rtQ5lySaG3+?=
 =?iso-8859-1?Q?op5ZWqpPegwkWq66t+wTS4J1BDtcRCTImj9FTOlGuGh/KEkOB+TTh11cuT?=
 =?iso-8859-1?Q?9oqLLJstCbCcZMrDAzYbm4e7FgVI0duVdLQYzoHZlrXr8yanF9QGeACQe1?=
 =?iso-8859-1?Q?kaaUalyTYfxBxwd2kYUKTMnCJ4WeXobEImO0POabuHGNiAu/nWGKuqe6gj?=
 =?iso-8859-1?Q?SzAGUPKYytebCqAp2h7aUUtcys2wAjgaayRh3OYz6IPhdmcLPh0VqNmUqN?=
 =?iso-8859-1?Q?8Tc7ls2GUL9MhlOMBSa1/RR2BJmRhuSV72TXY/aYgKTA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?/uouuOS1Wbo5nZ6iWwgsaE4f7pAFBpyIQ4LdmNGaGSlB/GSR6NPISRGR+g?=
 =?iso-8859-1?Q?5MdWC+fvecEEjo18DCIcgrH0lZ9xHHxaxtJqf/A4h35z42p6PklHeBtRpV?=
 =?iso-8859-1?Q?9uO3DpzW+XY8oo3JlCP4OYuqdFDaJRZaCvSo9HcP/AZlf+tPkGq3hXGuDm?=
 =?iso-8859-1?Q?2JozDjU5Rrd3p9gFynW/wJ8CkqFjoj/3/Ibg0fXFm5hTO8r02BQi14Bo7s?=
 =?iso-8859-1?Q?/zcpjHWscjBwcfL1lbNt0HNFkJEMMLrAlqboJdsJRzDKxEE6eZ5bkZY1Hh?=
 =?iso-8859-1?Q?a5AaZmpIPPYFTUGNd4qhAQXxe+Gf2WzGB36wAEfuwaqZptU6ShljPek+IY?=
 =?iso-8859-1?Q?bJ5vjsat6CTcvbQXr0a+OE2kc6gTgWf3hAKXxz1aApHceZ8dE50mawv61d?=
 =?iso-8859-1?Q?H0KCgD3tjU0sVqbKXSmEXSkabYrLkXcljz94XNvFkKhn3ba+hd1cPtv597?=
 =?iso-8859-1?Q?byAdT/21ExdKaEwcZB1x+yL7sP1oY6bWrbQY0ajprSm3XayXUDkg1BVz2o?=
 =?iso-8859-1?Q?JvfOFss9TCNtPzXCcu+drHTkC6TrvL17ggWPooerl+AUgP1VI1spRGLmYa?=
 =?iso-8859-1?Q?4zGdPDPCE2HbJTdsvJ+XkVgy0CdisQ+gAvpIzMSHYindiRtXba2nqFLkCV?=
 =?iso-8859-1?Q?N88sQLb3c9+w+7/gnrQG4fwIbN0TTCU2eeHz3OyAKjn/Xx9p/yOP6no6cl?=
 =?iso-8859-1?Q?pSk+Mg9WjqoMx91uI0WNnANqJZQwHmEZ83h6E2KegWxcfEDX1NoIRONuyH?=
 =?iso-8859-1?Q?fm1NC6LPEOY3ydqy3yrc3SQ2ydKzHuNmEQTQb5qFe274KtXVy/C2xkNYap?=
 =?iso-8859-1?Q?CJW3TaTOEpXYQDqu8hCnjKmO5MHILiNCKnnqLqQPed8z8HzOa0Uxll8jcD?=
 =?iso-8859-1?Q?zJlrbvmqEqrGrNABAAsdDRZ3BTOZ5B9ibtLBYNxdTgSixvgLeEEE5hnVR1?=
 =?iso-8859-1?Q?cDyIABZ3livoIUCUvAl9GXotsE4vqm+9C+twq/kv/aokOiNw+wgV6Erv7f?=
 =?iso-8859-1?Q?6cjMHqH5JzKiHovA3qSRiaisLCaqwJwZKn/lutsXXleP+Qy0Tn0dGKLpHl?=
 =?iso-8859-1?Q?WXflm1DonlAwSMNmBDxZz2/0575F9s9gi2LsKjsDBeXkjHUjnWY+jQfADO?=
 =?iso-8859-1?Q?YJnbhmP9ATdoWb9YuVmMKBWjjr4YDJ0+3g9nYuZuTazve6+9kuLhFvPXU+?=
 =?iso-8859-1?Q?ha6DIRTKJfvp4gHAw85e6zkTe7OS6MhEhehIGM0eZy5w6yWkOyZP7iEaiE?=
 =?iso-8859-1?Q?OGyobhD1qrW+FKUI4JfhXPGIOdt+0WqA/Qvam5L07f/0KZ5dDUe4s+PZKF?=
 =?iso-8859-1?Q?Cc0iGAE3PgM5WQDPEjPmRnjNo38XhI7uFV8sXn2hFJq7V63QeeDMPDqNwK?=
 =?iso-8859-1?Q?kSKM4x/zexSX5n9iJCn5PBpHk2zjDWWhuOdJbAtLKoMZm7EJ4BQrqTOkI3?=
 =?iso-8859-1?Q?0/stpN67MXDm996mMNkVQ+awWoXGXjkJF7J2SINXRc9jhzsItZBLXBH2z4?=
 =?iso-8859-1?Q?joj88v3o2wrbGu57x8bxbGacOdi/zgeexJUo6axeMKPrkE/j8a3eNhx9fl?=
 =?iso-8859-1?Q?vVxgNkpYSfXqhouPXRO+nQlhG35LcLw6xoHdVwxoeRb+gbhSz5QBJN+P83?=
 =?iso-8859-1?Q?HNy3Z7F+jl06Xq6OLMfC3Pa7QdeF8K7JWIPn69wJolXFxbAoWdUnyAtg?=
 =?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: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8545e7b3-2dcb-4ae4-9b7b-08de00545fa5
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2025 19:05:51.4605
 (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: IRH3kv/RY9DGJUseVbWWt+UwzGGxEGrdcXW9fbetR+tNlzKtDS8eBITgrhnvbWXrEwgJ44KALctSg/DrWSvz94YR9ALYi8Y086D7WBUN9IA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7239

From: Grygorii Strashko 

The LAPIC LVTx registers have two RO bits:
- all: Delivery Status (DS) bit 12
- LINT0/LINT1: Remote IRR Flag (RIR) bit 14.

The Delivery Status (DS) is not emulated by Xen - there is no IRQ msg bus,
and the IRQ is:
- or accepted at destination and appears as pending
  (vLAPIC Interrupt Request Register (IRR))
- or get rejected immediately.

The Remote IRR Flag (RIR) behavior emulation is not implemented for
LINT0/LINT1 in Xen for now.

The current vLAPIC implementations allows guest to write to these RO bits.

The vLAPIC LVTx registers write happens in vlapic_reg_write() which expect
to implement "Write ignore" access type for RO bits by applying masks from
vlapic_lvt_mask[], but vlapic_lvt_mask[] contains incorrect masks which
allows writing to RO fields.

Hence it is definitely wrong to allow guest to write to LVTx regs RO bits,
fix it by fixing LVTx registers masks in vlapic_lvt_mask[].

In case of WRMSR (guest_wrmsr_x2apic()) access to LVTx registers, the SDM
clearly defines access type for "Reserved" bits as RsvdZ (Non-zero writes
to reserved bits should cause #GP exception), but contains no statements
for RO bits except that they are not "Reserved". So, guest_wrmsr_x2apic()
now uses different masks (than vlapic_reg_write()) for checking LVTx
registers values for "Reserved" bit settings, which include RO bits and
do not cause #GP exception.

Fixes: d1bd157fbc9b ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Grygorii Strashko 
---
Changes in v2:
- masks fixed in vlapic_lvt_mask[]
- commit msg reworded

v1: https://patchwork.kernel.org/project/xen-devel/patch/20250925195558.519=
568-1-grygorii_strashko@epam.com/
 xen/arch/x86/hvm/vlapic.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 79697487ba90..2ecba8163f48 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -44,15 +44,17 @@
 static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =3D
 {
      /* LVTT */
-     LVT_MASK | APIC_TIMER_MODE_MASK,
+     (LVT_MASK | APIC_TIMER_MODE_MASK) & ~APIC_SEND_PENDING,
      /* LVTTHMR */
-     LVT_MASK | APIC_DM_MASK,
+     (LVT_MASK | APIC_DM_MASK) & ~APIC_SEND_PENDING,
      /* LVTPC */
-     LVT_MASK | APIC_DM_MASK,
-     /* LVT0-1 */
-     LINT_MASK, LINT_MASK,
+     (LVT_MASK | APIC_DM_MASK) & ~APIC_SEND_PENDING,
+     /* LVT0 */
+     LINT_MASK & ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING),
+     /* LVT1 */
+     LINT_MASK & ~(APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING),
      /* LVTERR */
-     LVT_MASK
+     LVT_MASK & ~APIC_SEND_PENDING,
 };
=20
 #define vlapic_lvtt_period(vlapic)                              \
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 19:20:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 19:20:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134437.1472313 (Exim 4.92)
	(envelope-from )
	id 1v3fu6-0001EI-0n; Tue, 30 Sep 2025 19:20:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134437.1472313; Tue, 30 Sep 2025 19: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 1v3fu5-0001EB-Ua; Tue, 30 Sep 2025 19:20:49 +0000
Received: by outflank-mailman (input) for mailman id 1134437;
 Tue, 30 Sep 2025 19: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 1v3fu4-0001DT-N3
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 19:20:48 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8fba6d8f-9e32-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 21:20:46 +0200 (CEST)
Received: from [IPV6:2601:646:8081:9484:3373:e8bd:aaa4:7c23]
 ([IPv6:2601:646:8081:9484:3373:e8bd:aaa4:7c23])
 (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 58UJJc0q376069
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Tue, 30 Sep 2025 12:19:38 -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: 8fba6d8f-9e32-11f0-9809-7dc792cee155
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 58UJJc0q376069
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025092201; t=1759259981;
	bh=5jKsWr8QEv1dE0BHGjK4jG5jy4dVCkN+HP+b8pZLYWY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=KmHeNLZj/n0P3Bx95LFzhVuxLXrHMsWLMMJ2Gm4H8FNamSlw/ykdibwr0KiTsB1Hx
	 kimmmjaE4PQNu82809DGZ+bXQB5PtFK+1BIkP2kit+wX/G9oZjCTGQQ4NBn3eyeroN
	 igAJ5wylIhFE9616RLBxQ4fa1M/81mz3016d0y5QrZzka0FJXVai2ABAi7s6qurIZU
	 UCt7L6g9U8v2bHT5kR3usV/nGI4JUG2MRe34f5yvbCfc1Wc8a+J7TpEqXyLIfbRGUg
	 AzbRtlbso5/anwJIMETPoxFJcMs4aRnGHHmG/oIvBJHSwcgPCKq+EsfPpQlRB7rZB1
	 WCrrEfyQwfYwQ==
Message-ID: <1412c7a5-8961-4949-b09e-7b9d080ce9bf@zytor.com>
Date: Tue, 30 Sep 2025 12:19:33 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 00/12] x86/msr: Inline rdmsr/wrmsr instructions
To: Juergen Gross , linux-kernel@vger.kernel.org,
        x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org,
        linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
        llvm@lists.linux.dev
Cc: xin@zytor.com, "Kirill A. Shutemov" ,
        Dave Hansen ,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Sean Christopherson ,
        Paolo Bonzini ,
        "K. Y. Srinivasan" ,
        Haiyang Zhang , Wei Liu ,
        Dexuan Cui ,
        Vitaly Kuznetsov ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org, Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Andy Lutomirski ,
        Peter Zijlstra ,
        Nathan Chancellor
 ,
        Nick Desaulniers ,
        Bill Wendling ,
        Justin Stitt 
References: <20250930070356.30695-1-jgross@suse.com>
Content-Language: en-US, sv-SE
From: "H. Peter Anvin" 
In-Reply-To: <20250930070356.30695-1-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 2025-09-30 00:03, Juergen Gross wrote:
> When building a kernel with CONFIG_PARAVIRT_XXL the paravirt
> infrastructure will always use functions for reading or writing MSRs,
> even when running on bare metal.
> 
> Switch to inline RDMSR/WRMSR instructions in this case, reducing the
> paravirt overhead.
> 
> In order to make this less intrusive, some further reorganization of
> the MSR access helpers is done in the first 5 patches.
> 
> The next 5 patches are converting the non-paravirt case to use direct
> inlining of the MSR access instructions, including the WRMSRNS
> instruction and the immediate variants of RDMSR and WRMSR if possible.
> 
> Patch 11 removes the PV hooks for MSR accesses and implements the
> Xen PV cases via calls depending on X86_FEATURE_XENPV, which results
> in runtime patching those calls away for the non-XenPV case.
> 
> Patch 12 is a final little cleanup patch.
> 
> This series has been tested to work with Xen PV and on bare metal.
> 
> This series is inspired by Xin Li, who used a similar approach, but
> (in my opinion) with some flaws. Originally I thought it should be
> possible to use the paravirt infrastructure, but this turned out to be
> rather complicated, especially for the Xen PV case in the *_safe()
> variants of the MSR access functions.
> 

Looks good to me.

(I'm not at all surprised that paravirt_ops didn't do the job. Both I and Xin
had come to the same conclusion.)


Reviewed-by: H. Peter Anvin (Intel) 


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 19:50:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 19:50:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134459.1472324 (Exim 4.92)
	(envelope-from )
	id 1v3gMN-0004WW-6G; Tue, 30 Sep 2025 19:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134459.1472324; Tue, 30 Sep 2025 19: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 1v3gMN-0004W2-2x; Tue, 30 Sep 2025 19:50:03 +0000
Received: by outflank-mailman (input) for mailman id 1134459;
 Tue, 30 Sep 2025 19:50: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 1v3gML-0004HC-G7
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 19:50:01 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4618111-9e36-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 21:49:58 +0200 (CEST)
Received: from [IPV6:2601:646:8081:9484:3373:e8bd:aaa4:7c23]
 ([IPv6:2601:646:8081:9484:3373:e8bd:aaa4:7c23])
 (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 58UJnQA9386545
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Tue, 30 Sep 2025 12:49:26 -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: a4618111-9e36-11f0-9809-7dc792cee155
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 58UJnQA9386545
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025092201; t=1759261768;
	bh=dNL6gt2iTdh66H47BLI0CoB/8tRPotODaDlCai0q5ho=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=WiyLGMbm41DpWdoeFYmeIGVkzQksa98mG1NxGVlgSKXuYKU94ud4wLZ7uWpxfPuEy
	 agrf020XSbTAABlOgFng9j8R0aUTAlhh8N4AbNkK7OtFKM4XBL5T+bw8rH0Ior1O36
	 d8xSMWC+DmFRLEoRqjd1FCcA+EXGAfQpkXVgBdxyyHwULfVwwtSo44n43XvsC2wxxq
	 oOahoknddZ6uUCoCZm5exOA58kIYDTgqNEKDhxGWaVkGHkjjb/cIU7HqkYJstxgGZA
	 kj7y8CQwndjMAtLhfHU/20MMHxiiTw5jxddwRlYgxkm3lHpT9lSXQZ+ZCErnA5CJh3
	 20RtYF/Dy2WRA==
Message-ID: 
Date: Tue, 30 Sep 2025 12:49:21 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
        Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev, xin@zytor.com,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
 <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
 <20250930100404.GK4067720@noisy.programming.kicks-ass.net>
 
Content-Language: en-US, sv-SE
From: "H. Peter Anvin" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 2025-09-30 03:43, Jürgen Groß wrote:
>>
>>> In Xin's series there was a patch written initially by you to solve such
>>> a problem by adding the _ASM_EXTABLE_FUNC_REWIND() exception table method.
>>> I think this is a dead end, as it will break when using a shadow stack.
>>
>> No memories, let me go search. I found this:
>>
>>    https://patchwork.ozlabs.org/project/linux-ide/
>> patch/20250331082251.3171276-12-xin@zytor.com/
>>
>> That's the other Peter :-)
> 
> Oh, my bad, sorry. :-)

Yes, you would have to patch both the stack and the shadow stack.

BUT: in the end it really doesn't really buy much. The only thing that
benefits is Xen, but it is fairly easy for Xen (my original POC did this) to
filter out the quite few MSRs that they do special dispatch for (plus the
variable case), and then they can just use the native code including the
benefit of using WRMSRNS and immediates.

The other approach that I also came up with looks like this:

/* Native code (non-immediate): trap point at +7 */

   0:   48 89 c2                mov    %rax,%rdx
   3:   48 c1 ea 20             shr    $0x20,%rdx
   7:   0f 01 c6                wrmsrns
   a:

/* Native code (immediate): trap point at +0 */

   0:   36 c4 e7 7a f6 c0 xx    ds wrmsrns %rax,$XX
        xx xx xx
   a:

/* Xen code, stub sets CF = 1 on failure */

   0:   e8 xx xx xx xx          call   asm_xen_pv_wrmsr
   5:   73 03                   jnc    0xa
   7:   0f 0b                   ud2
   9:   90                      nop
   a:

The trap point even ends up in the same place! UD2 can be any 1-, 2-, or
3-byte trapping instruction.

> 
>>> Additionally I found a rather ugly hack only to avoid re-iterating most of
>>> the bare metal ALTERNATIVE() for the paravirt case. It is possible, but the
>>> bare metal case is gaining one additional ALTERNATIVE level, resulting in
>>> patching the original instruction with an identical copy first.
>>
>> OTOH the above generates atrocious crap code :/
> 
> Yes.

Please don't generate crap code -- that's exactly The Wrong Thing. I didn't
actually look at the output code; I honestly didn't think that that would even
be an issue.

If it is REALLY evil, then do something like shell script to generate the code
instead...

(One big problem here is that cpp doesn't understand colons as separators...)

	-hpa



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 19:59:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 19:59:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134475.1472334 (Exim 4.92)
	(envelope-from )
	id 1v3gVp-0005wc-1K; Tue, 30 Sep 2025 19:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134475.1472334; Tue, 30 Sep 2025 19: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 1v3gVo-0005wV-Ul; Tue, 30 Sep 2025 19:59:48 +0000
Received: by outflank-mailman (input) for mailman id 1134475;
 Tue, 30 Sep 2025 19: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 1v3gVn-0005w6-Jx
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 19:59:47 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0256c294-9e38-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 21:59:46 +0200 (CEST)
Received: from [IPV6:2601:646:8081:9484:3373:e8bd:aaa4:7c23]
 ([IPv6:2601:646:8081:9484:3373:e8bd:aaa4:7c23])
 (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 58UJxGxQ388770
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Tue, 30 Sep 2025 12:59:16 -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: 0256c294-9e38-11f0-9d14-b5c5bf9af7f9
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 58UJxGxQ388770
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025092201; t=1759262357;
	bh=GUDfo0ggb2Kf0OLA6XTPKyaZ5hpYV0SrMLjTdCbuESQ=;
	h=Date:Subject:From:To:Cc:References:In-Reply-To:From;
	b=QaNz4Je2UXuQTSWaK4KMZazVcUDgrcjdxPf7vCTlHy0S5KlindalLZY9iSdbN0LPO
	 dZb78UBGhBI6zN+vsilEaxZSxAvZBA+b2DzFqnhlIs+P7vKdM8tGRUo3+SmH+ShgM7
	 b4ebKEuKD7ubKHHtEaatmx3ExNblsR56/PR+F2q18PSsag/YCLricKcIsLGhYsD8fm
	 +3Bi3bmpb/VjsC+tI1oc2MfG6eB2Odcjqkxn6QEL3QbDHW/e4z7LKSf4okznFo2Wwy
	 Y0OorC4QkeM6DrHa7SK6xfWjFIfjwzCLKSxx7dd3XM+E31C01/RFVTptacurWTbYs0
	 oHt+fMunsTYzg==
Message-ID: <2ca6c68f-16a7-402f-adb0-327583695d4a@zytor.com>
Date: Tue, 30 Sep 2025 12:59:11 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
From: "H. Peter Anvin" 
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
        Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev, xin@zytor.com,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250930070356.30695-1-jgross@suse.com>
 <20250930070356.30695-12-jgross@suse.com>
 <20250930083827.GI3245006@noisy.programming.kicks-ass.net>
 <1541b670-8b29-42a5-a58d-34d85197751d@suse.com>
 <20250930100404.GK4067720@noisy.programming.kicks-ass.net>
 
 
Content-Language: en-US, sv-SE
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 2025-09-30 12:49, H. Peter Anvin wrote:
> 
> /* Xen code, stub sets CF = 1 on failure */
> 
>    0:   e8 xx xx xx xx          call   asm_xen_pv_wrmsr
>    5:   73 03                   jnc    0xa
>    7:   0f 0b                   ud2
>    9:   90                      nop
>    a:
> 
> The trap point even ends up in the same place! UD2 can be any 1-, 2-, or
> 3-byte trapping instruction.
> 

You can, of course, also simply have a conditional jump, at the expense of
making the whole alternative block one byte longer:

  0:   e8 xx xx xx xx          call   asm_xen_pv_wrmsr
  5:   0f 82 xx xx xx xx       jc     wrmsr_failed

	-hpa



From xen-devel-bounces@lists.xenproject.org Tue Sep 30 20:28:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 20:28:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134486.1472343 (Exim 4.92)
	(envelope-from )
	id 1v3gx1-0001W2-3m; Tue, 30 Sep 2025 20:27:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134486.1472343; Tue, 30 Sep 2025 20:27: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 1v3gx1-0001Vv-1B; Tue, 30 Sep 2025 20:27:55 +0000
Received: by outflank-mailman (input) for mailman id 1134486;
 Tue, 30 Sep 2025 20:27: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 1v3gwz-0001Vn-Qj
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 20:27:53 +0000
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com
 [2607:f8b0:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed9ed82c-9e3b-11f0-9809-7dc792cee155;
 Tue, 30 Sep 2025 22:27:48 +0200 (CEST)
Received: by mail-pf1-x42e.google.com with SMTP id
 d2e1a72fcca58-78127433a32so3229311b3a.1
 for ; Tue, 30 Sep 2025 13:27:48 -0700 (PDT)
Received: from [192.168.0.4] ([71.212.157.132])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-78102b64a87sm14613842b3a.69.2025.09.30.13.27.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 30 Sep 2025 13: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: ed9ed82c-9e3b-11f0-9809-7dc792cee155
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1759264067; x=1759868867; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/mRpoLgFc8U26Jlg/SSZYXO8nFhlzFTCTlSmEDP24rk=;
        b=P9Wety39JmWmVQloW6Znucv+G9QERvFTWe5aXdAGOhIKPSEmv9YaOQk52CU0zn9uel
         yOoze12NXK1mZuFHgboQhhPLaD7FGID73s7GErj6WMbgvAM5tskwFy6AzsrCpOmCLF+i
         C75McjVm3McY1sYfWQcr52bCx2jFAdTRfOzmD3/tR6XU/R+DerXnfdfUw3BfgVB2Fe74
         sfsRqtXWNe3GXZ8wJJpAObhp+jozOPd3F5J3nWFVyHmTwjUTcNcqIbVCIF9lO4snQtIy
         hxD28XQKfo5pWzGKb4G3ZrajaCjXpuH3s5yjqjwOXS3N80Dt0U01M+1evWrWW0dtO7ai
         ThWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759264067; x=1759868867;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/mRpoLgFc8U26Jlg/SSZYXO8nFhlzFTCTlSmEDP24rk=;
        b=BiCIREJd/6Ya/1+peoJzwZ1M7OJGzLs/dkZ/6c9+v6/r7Dl2OIYVYDTb70VorWSIH0
         H2f/56kKtz2jPJGInG8VEOi/aXLEnn0J7EVZ1LMAa3O+LVxCkA7TQBL+ZUIdZgw+UWCR
         d02XxlQv1pNrr5kz0qaIOPzfkpEOI59txDzSLIxRedfqxw5VnHN2rjAryDpKDDMUx87N
         F01zEviFEGtdNbgo9TWRNKbvbKOIySZtovHWR69TyuCGZfwgFSzCueK1LJ0epPJ07b+S
         V3ml0VctH4+uJGQNI6k85VQHD4I5YiH0ngqBNRKc3zlMnqf6qdgROQ1ai3lVz1xXt34w
         ZaLA==
X-Forwarded-Encrypted: i=1; AJvYcCVPZXIMbBPYKekdWJzb3PGV9D6yTM4TmvCf1djTNQJCrTrp5DoDAPWPoi8XITdLWDWosuqrzc7Yl/w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy017Oz+u4NshJv60qbX0sc74S6zp5EgsQfnr2Hj9bi+9GiwG+/
	1fEogByWsXMGFMhTT3U9PvwAQOqdTmrMUs5OJio65XK1h1xz/6yBQ9esEk+wcgowjMU=
X-Gm-Gg: ASbGncvMrBP6OQKYP0LJe7B/kdWtQsHXNYm5ZzFjkSYeHj9lAlhj3BXMP68KckoNgOA
	ZPa3czjoBmpdQNc9NliR48kLipoz1CbZD+bB0MlIOVF+tCLOrO+3flK1VpwrMiM7oRuk/nDq6Md
	rsSyyBWTpKa+YnhZw5cOmU26YtM7fD/C6i1n5qHwTZvyz6W1hPAhKBYGHbubICMZkW7+VYfJ/Tc
	VHeREH16yknMmG15Rw0+y8YR1diOOsSuSjDwYytTmhta9e8yOdbmtP3UJkI4zFKQUXHcMok+gd6
	ldBLa+WJBSJAa42cqfX4nQXfBgQ9/pDaF19G3TY+951p1rgLvxmFaA1isN/zD3G2QNGa67bbIaN
	mIYAx8gE9oEgxRYI9YkRD5Vs7ECWkWPSlLGAogV7eqaldJl9DJSrwp0J7HTIrVAH/WsK59Ao=
X-Google-Smtp-Source: AGHT+IGHwGdaI9/7x3FSGjAll2aiAsXQ51koCXbRJnhtoa+Tb/JHj9ZGjhNKi09HfL4J9l5mVWb8dA==
X-Received: by 2002:a05:6a00:1146:b0:781:2320:5a33 with SMTP id d2e1a72fcca58-78af3ffe1e5mr846993b3a.9.1759264066784;
        Tue, 30 Sep 2025 13:27:46 -0700 (PDT)
Message-ID: <429e61aa-a9af-4a97-a549-d7d782e34fe5@linaro.org>
Date: Tue, 30 Sep 2025 13:27:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 14/18] system/physmem: Un-inline
 cpu_physical_memory_read/write()
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org, Peter Maydell 
Cc: Marcelo Tosatti ,
 Ilya Leoshkevich , Reinoud Zandijk ,
 Peter Xu , Zhao Liu ,
 David Hildenbrand , Halil Pasic ,
 kvm@vger.kernel.org, "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org, Stefano Garzarella ,
 David Woodhouse ,
 Sunil Muthuswamy ,
 Stefano Stabellini ,
 Matthew Rosato , qemu-s390x@nongnu.org,
 Paul Durrant , "Michael S. Tsirkin" ,
 Christian Borntraeger ,
 Anthony PERARD , Jason Herne
 , Paolo Bonzini ,
 Thomas Huth , Eric Farman 
References: <20250930082126.28618-1-philmd@linaro.org>
 <20250930082126.28618-15-philmd@linaro.org>
From: Richard Henderson 
Content-Language: en-US
In-Reply-To: <20250930082126.28618-15-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 9/30/25 01:21, Philippe Mathieu-Daudé wrote:
> In order to remove cpu_physical_memory_rw() in a pair of commits,
> and due to a cyclic dependency between "exec/cpu-common.h" and
> "system/memory.h", un-inline cpu_physical_memory_read() and
> cpu_physical_memory_write() as a prerequired step.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>   include/exec/cpu-common.h | 12 ++----------
>   system/physmem.c          | 10 ++++++++++
>   2 files changed, 12 insertions(+), 10 deletions(-)

Reviewed-by: Richard Henderson 

r~


From xen-devel-bounces@lists.xenproject.org Tue Sep 30 21:29:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Sep 2025 21:29:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1134505.1472354 (Exim 4.92)
	(envelope-from )
	id 1v3hu0-0000fz-79; Tue, 30 Sep 2025 21:28:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1134505.1472354; Tue, 30 Sep 2025 21:28: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 1v3hu0-0000fs-4L; Tue, 30 Sep 2025 21:28:52 +0000
Received: by outflank-mailman (input) for mailman id 1134505;
 Tue, 30 Sep 2025 21:28: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 1v3htz-0000fm-6r
 for xen-devel@lists.xenproject.org; Tue, 30 Sep 2025 21:28:51 +0000
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 72e0f7ce-9e44-11f0-9d14-b5c5bf9af7f9;
 Tue, 30 Sep 2025 23:28:48 +0200 (CEST)
Received: from orviesa004.jf.intel.com ([10.64.159.144])
 by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 30 Sep 2025 14:28:47 -0700
Received: from lkp-server01.sh.intel.com (HELO 2f2a1232a4e4) ([10.239.97.150])
 by orviesa004.jf.intel.com with ESMTP; 30 Sep 2025 14:28:42 -0700
Received: from kbuild by 2f2a1232a4e4 with local (Exim 4.96)
 (envelope-from ) id 1v3htn-0002Ul-2E;
 Tue, 30 Sep 2025 21:28: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: 72e0f7ce-9e44-11f0-9d14-b5c5bf9af7f9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1759267730; x=1790803730;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:in-reply-to;
  bh=zfIdBcB/dpjzaEpep4X7eK5CAcnmsMfVWj/01hovLLc=;
  b=cZI+eqaPY6bQiU/lvCJehuzOYwQvH7j2D8GYv1pqf7nF4vgGm5G5GLIk
   g01lYWB+ITPsmGZPM+6ZuHx+1bEQHEqmhTclJrEOwT3NGK2EqqY8wGCQ/
   +S3gq7ZNgSqBKKQQvpn6oqcYjU2oFgFZ/rZqMYr7A2CN1ugglUNiXlxtT
   qxmm017J/hrusNycMY52MHl0o2dLhHnWBOibCVS/la/rtp3VAwc/+ZFLY
   To0ygqdmnJ77jkW1sxCx8SXWbJjOLJnMnUkuUDU3yeyNDQhZpk+qoRqVJ
   jsKS2JLaEqaKMBrxjzPnERhcT0oVt30u9tp9lOExT8S5U2KC/wDttdgzJ
   g==;
X-CSE-ConnectionGUID: CqfjEh4jTKCN69mj0NSpLw==
X-CSE-MsgGUID: dBtD9cpBRmiLZB6lXmmh8w==
X-IronPort-AV: E=McAfee;i="6800,10657,11569"; a="61702276"
X-IronPort-AV: E=Sophos;i="6.18,305,1751266800"; 
   d="scan'208";a="61702276"
X-CSE-ConnectionGUID: q10CyoJ6SJ+/5NU0nmLg9A==
X-CSE-MsgGUID: 8gjwNvBERwyFySIzgmzpQg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,305,1751266800"; 
   d="scan'208";a="182917958"
Date: Wed, 1 Oct 2025 05:27:40 +0800
From: kernel test robot 
To: Juergen Gross , linux-kernel@vger.kernel.org,
	x86@kernel.org, virtualization@lists.linux.dev
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev, xin@zytor.com,
	Juergen Gross ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
 access functions
Message-ID: <202510010555.InsgYDTd-lkp@intel.com>
References: <20250930070356.30695-12-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250930070356.30695-12-jgross@suse.com>

Hi Juergen,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/x86/core]
[also build test ERROR on linus/master v6.17]
[cannot apply to kvm/queue kvm/next tip/master kvm/linux-next tip/auto-latest next-20250929]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Juergen-Gross/coco-tdx-Rename-MSR-access-helpers/20250930-150753
base:   tip/x86/core
patch link:    https://lore.kernel.org/r/20250930070356.30695-12-jgross%40suse.com
patch subject: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR access functions
config: x86_64-buildonly-randconfig-001-20251001 (https://download.01.org/0day-ci/archive/20251001/202510010555.InsgYDTd-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251001/202510010555.InsgYDTd-lkp@intel.com/reproduce)

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 
| Closes: https://lore.kernel.org/oe-kbuild-all/202510010555.InsgYDTd-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/asm-offsets.c:9:
   In file included from include/linux/crypto.h:18:
   In file included from include/linux/slab.h:16:
   In file included from include/linux/gfp.h:7:
   In file included from include/linux/mmzone.h:22:
   In file included from include/linux/mm_types.h:16:
   In file included from include/linux/uprobes.h:18:
   In file included from include/linux/timer.h:6:
   In file included from include/linux/ktime.h:25:
   In file included from include/linux/jiffies.h:10:
   In file included from include/linux/time.h:60:
   In file included from include/linux/time32.h:13:
   In file included from include/linux/timex.h:67:
   In file included from arch/x86/include/asm/timex.h:6:
   In file included from arch/x86/include/asm/tsc.h:11:
>> arch/x86/include/asm/msr.h:327:10: fatal error: 'asm/xen/msr.h' file not found
     327 | #include 
         |          ^~~~~~~~~~~~~~~
   1 error generated.
   make[3]: *** [scripts/Makefile.build:182: arch/x86/kernel/asm-offsets.s] Error 1 shuffle=3471495288
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1282: prepare0] Error 2 shuffle=3471495288
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:248: __sub-make] Error 2 shuffle=3471495288
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:248: __sub-make] Error 2 shuffle=3471495288
   make: Target 'prepare' not remade because of errors.


vim +327 arch/x86/include/asm/msr.h

   325	
   326	#ifdef CONFIG_XEN_PV
 > 327	#include 
   328	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki